Dennis Amari damari@verisign.com
VeriSign
Tony Rutkowski trutkowski@verisign.com
VeriSign
Andrew Newton anewton@verisignlabs.com
VeriSign Labs
V0.5 12-Apr-20

2
+ 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, ...)

4
+ 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
+ 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
+ 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
+ XML based
+ Internationalization
▪
▪
▪
Localization of data tags and content
Identifying contact equivalences
Support of Internationalized Domain Names
+ Unified Service
▪ Structured queries and results

8
+
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
+ 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
Registry-Specific
Common-Registry
Application-Transport
Domain Address
IRIS
[any defined transport] etc
+ 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.

11
+ 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
+ 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
+ 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
+ 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
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
+ 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
+ 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
+ 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
+ <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
+ <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
+ <host>
+ <contact>
+ <registrationAuthority>
+ <authenticationAuthority>
+ <iris:lookupEntity>
+ Error results
▪
▪
<searchTooWide>
<languageNotSupported>

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