IRIS: an Intelligent Network capability set for Next Generation Networks

1. V0.5 24-Sep-14 IRIS: an Intelligent Network capability set for Next Generation Networks Dennis Amari damari@verisign.com VeriSign Tony Rutkowski trutkowski@verisign.com VeriSign Andrew Newton anewton@verisignlabs.com VeriSign Labs

2. Outline • Overview of IRIS “Intelligent Network” capabilities • 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 NGN Internet Registry Information Service (IRIS) EREG IRIS schema (E.164 numbers/ENUM) definable provider relationships and access arrangements protocol suite for discovery and secure query of distributed ENUM registration data among ENUM registries Other schema (SIP addresses, instant message addresses, ...) 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 – ITU-T • Contribution introduced in Question E/17 Rapporteur meeting 8-12 November 2004 in Orlando Florida, collaboratively with JTC1/SC6 • Contributions introduced in SG 11 and SG13 meetings in December • Contributions introduced in SG2 and SG4 meetings in February • SG2 established correspondence group to consider E.FIND service recommendation • SG4 added expanded work in Q1 rapporteur’s group to encompass use and “rapid resolution” of ITU Carrier Codes (ICCs) as an administratively authenticated “global NGN provider code” • Contributions introduced in the current SG17 meeting • D10 focusses on implementation of rapid resolution platform to facilitate directory discovery • D15 focusses on implementation of directory platform as X.FIND based on work of IETF CRISP Working Group to develop IRIS

6. IRIS Status - IETF • 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

7. 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

8. IRIS General Concepts • Each kind of NGN 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 any NGN service • 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.

9. IRIS General Concepts • 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

10. 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]

11. 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

12. IRIS 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

13. 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

14. 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

15. 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

16. 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

17. IRIS 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.

18. IRIS Navigation of Servers and Data • Navigation of DNS to help find an authoritative server. • Query Distribution with entity references and search continuations. • Structured queries and results give clients the knowledge to display relationships

19. EREG schema: 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

20. EREG schema: 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>

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

22. Thank You! Tony Rutkowski trutkowski@verisign.com VeriSign Andrew Newton anewton@verisignlabs.com VeriSign Labs Dennis Amari damari@verisign.com VeriSign