Using DNS ENUM

Issue/Topic: Using DNS and ENUM for Identity Management

Conference: IIW10 May 17-19, 2009 this is the complete Complete Set of Notes

Monday – Session 1 - E

Convener: Esther Makaay

Notes-taker(s): Leon Kuunders

Tags: #ENUM #DNS #domain-names

Discussion notes:

The mentioning of ENUM in the title triggered a specific response from some attenders. They were interested in what was going on with ENUM and a summary of the developments in the last two years. However not everyone present had knowledge about the subject, so we started off with a description of Public User ENUM.

With Public User ENUM you can register your telephone number as a domain name. E.g +31 802233445 → 5.4.4.3.3.2.2.0.8.1.3.e164.arpa. With this domainname, you can publish a plethoria of other contact options, e.g. an e-mailaddress, skype account, SIP account, IM, and many more. Telco's are generally not enthousiastic about this, because it changes their monopoly stronghold (you could circumvene PSTN if you know someones SIP-address).

The domain name isn't registered on a first-come-first-serve basis. Only the person or company using the telephone number is allowed to register the number. The registration is periodically validated against the number and its user.

In The Netherlands, we've seen some use cases emerge that were inspired by ENUM, but drift in a different, identity-related direction. The idea was that if you put contact or reachability data into the domain zone, you could also put other kinds of information in the zone. This could be additional information about the phone number (the domain name) or information about the user of that number. You could point to a website-URL containing invoicing information or an employee record (with restricted access).

The next step was to think about different domain names. Because you don't per-se need an ENUM-domain, you can do this with any registered domain name. You could work with employeenumber.idm.company.org and only publish the records on your internal network (many companies work with internal DNS servers). You can run your own 'registry' this way.

You can publish information through the domain name, or point to a data source containing more information, like a database, website or server. Although all information in DNS is public, the data source can have restricted access.

Leon is working on a use case to give employees from different departments (physical and organisational) access to each others work environments by working with their employee numbers in a domain name. Since all departments use MS LDAP, it's easy to put that information into the internal DNS servers. The DNS network is already deployed and in use (big overstacked servers that now hardly see any load). Each department can maintain their own information and decide what to publish.

This, as Dave Crocker pointed out repeatedly, shouldn't be called ENUM anymore. ENUM refers to a set of IETF-protocols that are described in RFC 3761 and anything that deviates from this (especially if it deviates this far) simply isn't ENUM. The definition of ENUM should be very precise and there's already lots of discussion going on about the narrow definition (eg in the E2MD IETF wg). Semantics are important!

The conversation dispersed into a broad range of topics, most of them concerning the technology involved.

• Does a telephone number resolve to a person or a place?
• Use a particular reference mechanism from your records (concepts/schema's)
• Business case based on making your IDM implementations more flexible. Also inspired by Phill Windley's “Digital Identity” fourth level of IDM: integrated IDM, IDM is on the infrastructure level.
• Is this mapping to an IP-addres? DNS is based on a string of names. Traditionally it maps a domain name to an IP address, but a lot of its current usage has to do with pointers that do not (directly) resolve to an IP-adress.
• Why not use XRI (discovery protocol)? Doesn't that solve these issues already? But everything already uses DNS. What's the current penetration of XRI? The main advantage is to use the infrastructure that is already there.
• Is the way you get a result from your DNS server rich enough to uses this actually?
• Are domains and e-mailaddress sufficient as an identifier? Most people have multiple e-mail addresses. Why not use iNames as persistent identifiers?
• XRI, XRD, Webfinger → should ENUM be integrated with these discovery protocols?
• DNS calls on the weblayer is that possible? (Javascript sandbox)
• Does this relate to E2MD discussions? → The telephone carriers are talking about adding attributes as well. (Calling party name, number not in use, attributes needed for handling calls via IP on an infrastructure level.)
• What about security? → DNSSEC!
• What about privacy? This depends on your use case, but you should be aware of the public character of DNS and the possibilities to use internal/private networks (like with private ENUM).
• Telnic works with its own references, is this a standard to follow? Again, depends on the use case. Telnic works with TXT records for labels to go with the contact information (eg work phone, mobile phone), uses extra address and naming fields and works with encrypted records for restricted information (only friends can decrypt).
• How can you make sure the identifiers will be unique? DNS will only work when unicity is guaranteed? Domain names are unique on the internet.
• Not everyone has a domain name. Situations differ across different countries in the world. If you don't 'own' your domain name (or a delegation), then you have no guarantee of the availability of the name as an identifier. Has also to do with the maturity of the internet space (eg in the early days, all websites resided under the providers domain). If there is need and usage for owning your own domain, it will happen.
• How does somebody who does not have your phone number find you? people have telephone numbers, e-mailaddresses, domain names
• Laws about portability of mobile phone numbers. There is not such a thing for e-mail.
• Phone numbers are very public, how do you control access to this? You don't (DNS is public), but it's a voluntary registration. It's different from handing out business cards of course, but the DNS is not a database-lookup system. You cannot do “select * from .com where domain like thisname”. You can only look up records with a domain name, not the other way round.
• It would be possible to shield information by using proxies.
• Validation of regular domain names could be helpful for building trust. Validate the WHOIS credentials of the registrant of a domain name. Is this the same as the ex-tended validating from certificate providers? No, those validations apply to SSL-certificates that are used for websites. Validation of a domain name extends to all use of that domain name (eg with e-mail).

The ideas around using DNS and ENUM are very interesting, but since there's so many technical aspects involved (discovery, identifiers, reference-schemes, pointers, usage), it easily gets over-complex and confusing. In the end it was decided that Esther will (try to) describe the subject in a tight non-technical manner. It should help to simplify the subject if we leave the technology (however interesting) for a later stage.