1 / 25

EREG: an Intelligent Network capability set for User and Infrastructure ENUM

V1.0 30-Jan-04. ETSI 1 st ENUM Workshop Sophia Antipolis, France 24-25 Feb 2004. EREG: an Intelligent Network capability set for User and Infrastructure ENUM. Tony Rutkowski trutkowski@verisign.com VeriSign Switzerland Andrew Newton anewton@verisignlabs.com VeriSign Labs. Outline.

idalia
Download Presentation

EREG: an Intelligent Network capability set for User and Infrastructure ENUM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. V1.0 30-Jan-04 ETSI 1st ENUM Workshop Sophia Antipolis, France 24-25 Feb 2004 EREG: an Intelligent Network capability set for User and Infrastructure ENUM Tony Rutkowski trutkowski@verisign.com VeriSign Switzerland Andrew Newton anewton@verisignlabs.com VeriSign Labs

  2. Outline • Overview of EREG – the ENUM Registry “Intelligent Network” • Reference models and interfaces • Security and authentication • Applications • Policy developments • Activities and status

  3. PSTN Intelligent Network(IN) Capability Sets definable provider relationships and access arrangements protocol suite for discovery and query of distributed subscriber data among telecom providers ENUM Internet Registry Information Service (IRIS) EREG definable provider relationships and access arrangements protocol suite for discovery and query of distributed ENUM registration data among ENUM registries Capability Sets

  4. Internet Registry Information Service (IRIS) • Developed in IETF to provide capability sets existing in telecom Intelligent Network environment • Text based protocol designed to allow registries of Internet resources • to express query and result types specific to their needs • while providing a framework for authentication, structured data, entity references and search continuations • Encompasses the following • a decentralized system using DNS hierarchies where possible for location • built upon standard Internet building blocks • does not impose any informational trees or matrices • may be used with multiple application transports, including BEEP

  5. IRIS Status • Prime focus of CRISP (Cross Registry Information Service Protocol) working group of the IETF • Chaired by April Marine april.marine@nominum.com and George Michaelson ggm@apnic.net • A new specification for use by registries of Internet resources globally • Requirements are done • Protocol selection is done • Now refining IRIS for publication as a standard • Applying what we have learned about operating services over the Internet from the 20 intervening years to the problems of today • Implementation tool sets available as freeware and for plugtest demonstrations

  6. IRIS attributes • XML based • Internationalization • Localization of data tags and content • Identifying contact equivalences • Support of Internationalized Domain Names • Unified Service • Structured queries and results

  7. IRIS General Concepts • Each kind of Internet registry is identified by a registry type • The identifier for a registry type is a URI used within the XML instances to identify the XML schema formally describing the set of queries, results, and entity classes allowed within that type of registry • The structure of these URN's makes no assumptions or restrictions on the type of registries • IRIS may support multiple registry types of disparate or similar nature; it is only a matter of definition • a single registry type may be defined for domain name registries while multiple registry types may be defined for the various IP address registries • A registry information server may handle queries and serve results for multiple registry types • Each registry type that a particular registry operator serves is a registry service instance • IRIS and the XML schema are independent of the registry service maintenance systems • IRIS is a specification for a framework with which these registries can be defined, used, and interoperate • The framework merely specifies the elements for registry identification and the elements which must be used to derive queries and results • Allows a registry type to define its own structure for naming, entities, queries, etc. through the use of XML namespaces and XML schemas • a registry type is identified by the same URI that identifies its XML namespace. • Framework defines certain structures common to all registry types • references to entities, search continuations, entity classes, and more • registry type may declare its own definitions for all of these, or it may mix its derived definitions with the base definitions • IRIS defines two types of referrals, an entity reference and a search continuation • An entity reference indicates specific knowledge about an individual entity • A search continuation allows for distributed searches • Both referrals may span differing registry types and instances • No assumptions or specifications are made about roots, bases, or meshes of entities

  8. IRIS Framework • Registry-Specific :: Defines queries, results, and entity classes of a specific type of registry. Each specific type of registry is identified by a URN • Common-Registry :: Defines base operations and semantics common to all registry types such as referrals, entity references, etc. It also defines the syntaxes for talking about specific registry types. • Application-Transport :: Defines the mechanisms for authentication, message passing, connection and session management, etc. It also defines the URI syntax specific to the application-transport mechanism. However, because of the separation of the layers, other transports can be used and have been defined. Registry-Specific Domain Address etc Common-Registry IRIS Application-Transport [any defined transport]

  9. ENUM Registry Information Service (EREG) • An IRIS implementation developed specifically for infrastructure and user ENUM • Meets requirements in Secs. 10.2,10.4, C.2 of ETSI TS 102 051 V1.1.1 (2002-07), ENUM Administration in Europe • Provides WHOIS/NICNAME equivalent requirements in Sec. 3 of ETSI TS 102 172 V1.1.1 (2003-03), Services and Protocols for Advanced Networks (SPAN); Minimum requirements for interoperability of European ENUM trials • Meets requirements in ETSI TS 101 331 V1.1.1 (2001-08), Telecommunications security; Lawful Interception (LI); Requirements of Law Enforcement Agencies • Allows potential IN-like capabilities such as caller-id or fraud checking

  10. EREG Model EREG Framework Tier 0 Registry Tier 1 Registry Validation function ENUM Registrar Registrant(ENUM End User) ENUM Tier 2Nameserver Provider Applications

  11. EREG Security • Designed for distributed data that occurs in ENUM architectures, with defined methods for finding the right server • Ability to control who gets the info • Critical need for network administration and law enforcement $iris kosters.net Kosters, Mark US $iris –cert fbi.cert kosters.net Kosters, Mark 13121 Fox Shadow Lane Clifton, VA 20124 US 703-948-3362

  12. Authentication and Authorization • Distinction • Authentication – the process used to verify the identity of a user • Authorization – the access policies applied to a user based on authentication • Authentication mechanisms facilitate authorization schemes • Authentication mechanisms • passwords, one-time passwords, digital certificates, references • Authorization schemes • user-based, sequence-based, chain-based, attribute-based, time-based, referee-based

  13. Digital Certificates • Use a branch of mathematics called public key cryptography to conduct authentication. • Used in conjunction with TLS, they also allow for server authentication and session encryption. • Facilitate the following authorization schemes: • user-based • chain-based • attribute-based • time-based

  14. Certificate Chains Authorization can be based on one of the certificates in the chain. • Example: • If the certificate is signed by the “lea CA” • Allow access to all contact data • If the certificate is signed by the “regr CA” • Allow access only to all domain and registrant data

  15. Attributes in Certificates • Information attributes in certificates are cryptographically secure. • Example: • If the “Type” attribute in the certificate equals “LEA” • Allow access to all contact data • If the “Type” attribute in the certificate equals “Registrar” • Allow access only to all domain and registrant data

  16. EREG Referrals • The IRIS protocol allows a server to pass extra information via a client to a referent server. • This information may contain authentication data, thus allowing a referee-based authorization policy.

  17. EREG Navigation of Servers and Data • Navigation of DNS to help find an authoritative server. • Query Distribution with entity references and search continuations. • Relay bags to enable common index servers. • Structured queries and results give clients the knowledge to display relationships.

  18. EREG: query types and elements • <findEnumsByRegistrant> • finds ENUMs by searches on fields associated with a registrant • Allowable search fields include <contactHandle> <commonName>, <organization> <eMail> <sip> <city>, <region>, <postalCode>, <country> • Provides optional <language> elements containing language tags • <findContacts> Query • <findEnumsByHost> Query • Includes host name, host handle, IPv4 address, or IPv6 address of the name server

  19. EREG: enum result elements • <e164Number> • <enumHandle> • <nameServer> • <registrant> • <contact> • <technicalContact> • <administrativeContact> • status • <reservedDelegationStatus> - permanently inactive • <assignedAndActiveStatus> - normal state • <assignedAndInactiveStatus> - new delegation • <assignedAndOnHoldStatus> - dispute • <revokedStatus> - database purge pending • <unspecifiedStatus> • <delegationReference> • <registry> • <registrar> • <initialDelegationDateTime> • <lastRenewalDateTime> • <iris:seeAlso>

  20. EREG: other result types • <host> • <contact> • <registrationAuthority> • <authenticationAuthority> • <iris:lookupEntity> • Error results • <searchTooWide> • <languageNotSupported>

  21. EREG XML Schema

  22. EREG Policy Developments • Operational • EREG provides critical capabilities among providers • to securely maintain the basic services • to troubleshoot • to create new applications and offerings to subscribers such as callerID, fraud detection, etc • EREG allows providers to define policies and contractual obligations among themselves and express them as access rights • EREG can support multiple transport layer options and different subscriber maintenance systems • Governmental • EREG provides capabilities long demanded of communication service providers by national regulators and law enforcement authorities • to maintain authoritative subscriber information • to produce subscriber information quickly upon lawful order • EREG is an open protocol based on XML that is being supported by eGovernment initiatives in Europe and worldwide

  23. Extensive open source software and information available by VeriSign Labs for PlugTests http://iris.verisignlabs.com dregquery

  24. EREG Implementations and Interoperability • Underway at providers and university testbeds - Q2 2004 • Plugtest interoperability demonstrations for EREG in conjunction with infrastructure and user ENUM - Q3 2004

  25. Additional Links and Information • See A. Newton, IRIS - An ENUM Registry (ereg) Type for the Internet Registry Information Service, draft-newton-iris-ereg-01, October 24, 2003 • IETF CRISP Working Group • http://www.ietf.org/html.charters/crisp-charter.html

More Related