A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER)
Author(s): Hadriel Kaplan
This document describes a proposal for providing a database service for authentication information for Caller-ID E.164 numbers, nationally-specific number codes, and email-style names used in communication requests (such as call setup, instant messages). The model proposed uses a...
STIR BOF Group H. Kaplan Internet Draft Intended status: Standards Track July 15, 2013 Expires: January 30, 2013 A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER) draft-kaplan-stir-cider-00 Abstract This document describes a proposal for providing a database service for authentication information for Caller-ID E.164 numbers, nationally-specific number codes, and email-style names used in communication requests (such as call setup, instant messages). The model proposed uses a DNS service as a Registry for cryptographic public-keys. The database service solution is called CIDER. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 15, 2013. Kaplan Expires January 2014 [Page 1] Internet-Draft CIDER July 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction..................................................3 2. CIDER Overview................................................4 3. Terminology...................................................6 3.1. New Terminology..........................................6 4. Background Information........................................8 4.1. Benefits and Drawbacks to Using DNS......................8 4.2. Relation to ITU and National Number Authorities..........9 4.3. Open Numbering Plans....................................10 5. Caller-ID vs. DNS Delegation and Authority Models............11 5.1. Email-style Registries..................................12 5.2. E.164 and Number Code Registries........................12 6. Assignee Roles and Actions...................................13 6.1. Key Agents and Third-Party Private Agents...............14 7. Using CIDER for Caller-ID Verification.......................15 7.1. CIDER DNS Client Requirements...........................15 7.2. Information Needed by the Caller-ID Verifier............16 7.3. Generating the CIDER DNS query..........................16 7.3.1 Query for Email-style Identity 16 7.3.2 Query for E.164-based Identity 16 7.3.3 Query for Number Code-based Identity 17 7.4. Processing the DNS Answer...............................17 8. DNS Binding..................................................18 8.1. Subdomain Namespace.....................................18 8.2. Resource Record Type for Key Storage....................18 8.3. TXT Record Format.......................................18 9. Security Considerations......................................19 9.1. Privacy of Assignee.....................................19 10. Open Issues.................................................19 11. IANA Considerations.........................................20 12. Acknowledgments.............................................20 13. References..................................................20 13.1. Normative References...................................20 Kaplan Expires - January 2014 [Page 2] Internet-Draft CIDER July 2013 13.2. Informative References.................................20 Author's Address.................................................21 Appendix A. Possible Deployment Model...........................21 Appendix B. Requirements for a CAPP Mechanism...................23 1. Introduction For many years the identity of the calling party (i.e., Caller-ID) of voice communications has been made available to the callee, and has been assumed to be generally accurate/reliable. Not only do end users expect this to be the case, but also applications such as calling-name (CNAM) services, call-back services, and voice-mail account access, have depended on the validity of the Caller-ID. Even some forms of call rate-control and Denial-of-Service (DoS) attack prevention between service providers depend on valid Caller- IDs. The ability to spoof Caller-IDs enables numerous fraud and abuse scenarios. Unfortunately, this problem already exists and is exacerbated by the presence of Internet-based calling services. While a small volume of Caller-ID spoofing has occurred for many years on the PSTN, it was infrequent enough to handle through manual investigation, and could be largely ignored as being merely isolated cases. Lately, however, the frequency has increased to a point that national regulators are becoming concerned (e.g., [fcc-doc]), the media have been reporting on it, and service providers themselves have been DoS attacked using invalid Caller-IDs. There are several causes for the increase in Caller-ID spoofing: the decrease in cost for making calls, the large number of inexpensive products capable of generating spoofed Caller-IDs, and the growing number of entry points/paths into the trust network upon which Caller-ID reputability has always depended. Spoofing a Caller-ID is possible because to-date there has been no means to validate a Caller-ID; instead the assumption has been that the received Caller-ID came from trustworthy upstream providers, in a chain-of-trust based on the PSTN model. Some PBXs are also allowed to generate whatever Caller-IDs they wish across PRI circuits, based on the belief that they can be trusted due to the relative cost, complexity, and physical hurdle of getting a PRI trunk. The original assumption of Caller-ID reputability that was based on the PSTN trust model no longer holds. Therefore, in order to keep Caller-IDs valid in a less trustworthy interconnection model, a means of verifying Caller-IDs must be deployed that works with the Kaplan Expires - January 2014 [Page 3] Internet-Draft CIDER July 2013 model. Replacing the current PSTN-style interconnection model itself is not realistic. One approach for verifying Caller-IDs relies on public-key cryptography, whereby the originator signs some information in the call setup message using a private key, and the receiver verifies the signature using the public key. For example the solutions described in [RFC4474], [draft-4474bis], and [draft-ikes]. These approaches are conceptually similar to those employed by [DKIM] and [DMARC], which have been created to address a similar issue for email. Regardless of the solution used, there needs to be a way for: (1) the originator to have a private/public key pair that is trusted by everyone else to prove the originator can claim the Caller-ID (2) any receiver of the originator's message to be able to retrieve the public key the originator used, and (3) the receiver to verify the private key was used to sign for the given Caller-ID This document describes a model for achieving those needs. It does so by using the Domain Name System [DNS], as a database for mapping source identities to public keys with an authority structure. The DNS tree nodes have no direct identifying information - they do not identify the carrier or end-user that was assigned each E.164 number, for example. The general model and architecture is named "CIDER". 2. CIDER Overview At a high-level, CIDER provides a database infrastructure using DNS for storing and retrieving public keys to authenticate source identities in communication messages, for example SIP or XMPP requests. Instead of being told by the message originator where the verifier should get a full certificate and then having the verifier check that the certificate is signed by a common trusted third-party for the specific identity being claimed, CIDER retrieves the public key directly from DNS and relies on the DNS authority model to control authorization of the public keys for source identities. CIDER currently covers three types of identities: international E.164 numbers, nationally-specific number codes, and email-style names. Each type uses a different anchor to its domain name, and thus can be deployed in different ways. The DNS infrastructure used for each may be the public DNS infrastructure, or local private DNS instances populated with the same data. They can even be used in a restricted "federation" model, whereby only specific entities have access to the CIDER data: the public keys and other associated data. Kaplan Expires - January 2014 [Page 4] Internet-Draft CIDER July 2013 For domain-based identities, CIDER follows the [DKIM] model of using each identity domain's DNS zone with a defined node name and key selector to hold the public key. The DKIM "key selector" is called a CIDER "key index" in this document, because it is syntactically different. The subdomain node name prefixed to the source's domain name is also different ("_cidkey" vs. "_domainkey"), and the TXT Resource Record format is more constrained than DKIM's. For E.164 numbers and number codes, CIDER uses a reverse-dotted notation similar to ENUM for the DNS structure. The top of the domain tree hierarchy (the anchor) for the E.164 and number code entries is still TBD - it could be one single root anchor for all country-codes, or it could be a different anchor per country-code or geopolitical region or whatever. In order to simplify discussion and explanation in this document, the domain 'cid.example.org' is used to describe a common top-level anchor domain for both E.164-based and number code-based identity entries. In practice they could be different, with E.164 using 'cid.example.org' and number codes using 'cid.example.net', to have separate authorities for E.164-based numbering vs. number codes. The structure of CIDER's DNS hierarchy for the E.164-based and number-code-based domains follows a reverse-dotted notation of the E.164 numbering format, so that for example the +1 "country-code" would be the subdomain '.1.cid.example.org', whereas that for the +49 German country-code would be '.9.4.cid.example.org'. Nationally-specific number codes would be prefixed with their country-code, so that for example "911" in the North American Numbering Plan country-code 1 would be the domain "18.104.22.168.example.org". The public keys in CIDER's DNS tree nodes have no direct identifying information - they do not identify the carrier or end-user that was assigned each E.164 number. The public keys could be unique per E.164 number entry, or they could be the same public key for all E.164 entries belonging to the same end entity. This is purely an administrative choice of the owner. For example a carrier that is assigned millions of E.164 entries might re-use the same public-key in all of them. Or it can use one public key for every thousand E.164 numbers, or whatever. It's up to the individual end-entities that were assigned the E.164 numbers to decide what to populate their assignee DNS identity entry nodes with. If an organization explicitly desires to make itself known, it can put its name into some to-be-defined DNS Resource Record for its Kaplan Expires - January 2014 [Page 5] Internet-Draft CIDER July 2013 E.164 number identity entry node; such may be the case for corporate 1-800 numbers, for example. The organization can decide, on a number-by-number basis, whether to make itself known or not for that E.164 number in the CIDER DNS tree. It should be noted that although the public key entries installed in the CIDER DNS tree are unique for every E.164 number (or group of numbers), they do not need to be maintained/stored by the organizations that uploaded them. Unlike credentials used with SSL/TLS, for example, the public keys are not transmitted by their servers to client hosts using certificates; rather, the keys are only retrieved by the verifiers when validating the Caller-ID signatures, and that's done through DNS. The signers themselves only need to know the private key, to which the public key is paired to for any given E.164 number. Furthermore, the originators can use the exactly the same private key for every E.164 number they sign for, by uploading the same public key into every E.164 node they are assigned in the CIDER DNS. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". It is assumed the reader is already generally familiar with E.164 numbers, Public-key cryptography concepts, Domain Name System (DNS), and DNS Security (DNSSEC). This document uses the term "identity" instead of "identifier" with regards to verifying source identity. The reason for this is that it is not the syntactic encoding of an E.164 digit string, number code, or email-style name that are being verified - it's the canonical E.164 phone-number, number code, or email-style name that's being verified. In other words CIDER is used for verifying a logical entity, not a specific representation; and the logical entity is not a specific human user or SIP agent/device, but rather a phone-number or number code or email-style name. 3.1. New Terminology Caller-ID: the identity of the originator of a communications request; for example the From header field in a SIP INVITE call setup request or MESSAGE instant message request. Kaplan Expires - January 2014 [Page 6] Internet-Draft CIDER July 2013 E.164 number: a phone number in international E.164 format, which is understood by the originating and receiving entities to represent a globally unique number. This definition includes numbers that are not technically "E.164" numbers, such as toll-free 1-800 numbers in North America. Number code: a nationally-specific number which is not representable as an E.164 number. Examples of number codes include two or three digit emergency service numbers, N11-type numbers in NANP, and inter-carrier common short codes. Email-style name: a 'user@domain' format identifier, for which the user portion is scoped to the domain portion, and the domain portion is a classic, public domain name; removing or changing the domain portion would fundamentally change the identity of the user. Source identity: the E.164 number, number code, or email-style name used for identifying the originator of a message to the receiving user; i.e., the identity used for "Caller-ID". Identity entry: the DNS name entry representing an E.164-based number, nationally-specific number code, or email-style domain name. CIDER Registry: an instance of a DNS hierarchy used for storage and retrieval of public keys for source identities. A CIDER Registry may be for an entire E.164-based country-code tree, or just for portions of one, or just for a single domain name. CIDER Registrar: the organization that owns, manages, and is authoritative for a CIDER Registry. CIDER Assignee: the organization/entity that the CIDER Registrar allows to populate specific identity entries with public key data, can grant/rescind Key Agents, and permanently transfer ("donate") the identity entry to another Assignee. This could be a carrier or service provider for E.164 numbers, for example. Key Agent: an organization/entity that the CIDER Assignee grants access to upload public key data only, for one or more of the Assignee's identity entry nodes. This could be an Enterprise or service provider customer of a carrier, for example. Third-Party Private Agent: an organization/entity that can upload public key data for an identity, but not directly to the Registry - only via a true CIDER Assignee, and thus the Registrar knows nothing about the Third-Party Private Agent. This could be an Enterprise or end-user, for example. Kaplan Expires - January 2014 [Page 7] Internet-Draft CIDER July 2013 4. Background Information 4.1. Benefits and Drawbacks to Using DNS A database model to hold public keys used for caller-id verification could be accessed using a protocol other than DNS. Examples include HTTP, LDAP, or even DIAMETER. CIDER uses DNS for the following reasons: o The DNS architecture has demonstrated massive intrinsic scalability, by allowing branches of the database tree to be run on separate physical servers and separate, independent adminsitration. o The DNS protocol is extremely efficient, with no extra round- trip delays creating connections or resolving hostnames. o The DNS protocol allows tight control over retransmission timers and timeout behavior from the application layer, because it runs on UDP. o The DNS protocol has well-established practice for highly effective geographic redundancy techniques, such as through anycasting because it runs over UDP. o The DNS protocol has well-established and effective caching in local servers, and techniques are available to have local copies of a DNS tree. o The DNS protocol and architecture provide a seamless, global service, but have well-established and highly effective practice for delegation of authority, which is useful for country-code level separation of authority for E.164 numbers and nationally-specific number codes. o The DNS protocol already defines the encoding syntax and semantics for many of the functions needed. o DNS is already used very widely by services employing DKIM for email signing/verification for a similar purpose as would be needed for email-style domain-based caller-id identities. o Some service providers already use DNS for Private ENUM for CNAM, number portability, and communication request routing purposes. o Virtually all clients/hosts have DNS querying capabilities today; and there are many DNS server vendors, including a widely popular open-source implementation (BIND). There are some drawbacks to using DNS, however: o DNS typically uses UDP, so if the query or response are larger than the MTU size between the client and server, fragmentation will occur. The base DNS maximum message size is 512 bytes, but CIDER requires [EDNS0] be used, which allows larger message sizes; so the real issue is for message sizes over ~1460 bytes. The current CIDER entries would not typically be that large, even if DNSSEC is being used. Kaplan Expires - January 2014 [Page 8] Internet-Draft CIDER July 2013 o Deploying a private registry using DNS is more complicated because it runs over UDP and has no defined mechanism to enforce access control on the queries. Private and federated DNS has been deployed, but it usually requires using private IP Addresses and VPN-style access to the servers. o The DNS query model does not support providing a different resource record(s) for different querying agents. In other words, it does not give a different answer depending on who asks the question. There are widely-used work-around behaviors for this today, but they are not standardized. o No changes to the underlying DNS protocol are envisioned. Should they be needed, some members of the IETF treat the DNS protocol, architecture, and its instantiation in the public Internet for domain name resolution, all as one monolithic, inter-dependent usage. Therefore, any changes required of the protocol have to also work for the Internet domain name resolution infrastructure as rooted-in/controlled-by IANA/ICANN. Even if a DNS extension were created for purely private use, the IAB has essentially stated they fear the public domain name infrastructure is so brittle that it would collapse if the extensions were accidentally sent to a public DNS server. [Note: If the STIR Working Group decides future extensions to the DNS protocol would be needed, there is a way to achieve this: we could copy the DNS RFCs into new documents, give the protocol a new name ("NDNS" for "Not DNS"?) and a new default UDP port number other than 53. Such a concept seems silly, but it would give us the same benefits without the drawback of having to worry about "The DNS" collapsing due to a few unexpected bytes in a query packet.] 4.2. Relation to ITU and National Number Authorities A concern has been raised that using E.164 numbers in a DNS hierarchy would be problematic because the ITU should be responsible for delegating E.164 country-codes, and national authorities should be responsible for managing their country-code numbers. The fear is that deploying CIDER without the ITU and national authorities approving and managing it would lead to claims of inappropriate subverting of the E.164 numbering system; or fears that for CIDER to work correctly would require such approval and management. This document section explains why such concerns are either unfounded, or apply equally to any database model used for caller-id verification of E.164 numbers, whether it be DNS or otherwise. With regards to approval, there is already precedent for the IETF to use names defined by other organizations in DNS: the top-level Kaplan Expires - January 2014 [Page 9] Internet-Draft CIDER July 2013 country domain names are based on a list defined by ISO, for example. With regards to subverting the E.164 numbering system, this document makes no claim that a specific CIDER registry, or top domain root for it, is in fact authoritative for the E.164 number space. In fact, although this document uses the term "E.164" to describe the tree structure and assignment model, all that is truly described is how a DNS domain may create subdomain names with Resource Records that could be used by others to retrieve public keys. It is up to the users of the registry/domain to decide whether to believe it represents E.164 numbers, and to use it for identities in call- control scenarios. The same CIDER model could be used, for example, to deploy a public key storage/retrieval mechanism for a private phone-numbering plan; or even digit-based names that have nothing to do with phone numbers, such as Autonomous System numbers or Enterprise OIDs. The CIDER service described in this document does not dictate who will be registrars, although existing authorities and operators might be reasonable candidates. All CIDER needs, however, is for some organization to manage the domain tree for a given E.164-based namespace, to decide what entities get to populate the public key entries for its branch nodes, and for verifiers to use that organization's domain tree for retrieving the public keys and trust them to be correct. In other words, any organization can be the Registrar and create its own CIDER DNS registry with its own domain as the anchor of the tree, and so long as both signers and verifiers use that organization's registry and it is accurate, then CIDER works. This is no different than what occurs for the web-pki model of third-party Certificate Authorities (CAs). If you trust a CA, then you trust that the certificates it signs are for the domain/host names contained in the certificate, even though CAs are not authoritative for DNS domain name assignments. The IETF has a mechanism for tying web-pki certificates to the actual authority of DNS names: DANE is that mechanism; but without DANE verification, the web-pki model is purely based on trusting the CAs to be accurate with regards to domain/host name assignments. Therefore, any caller-id verification model that is not ultimately controlled by the numbering authorities for the E.164 number space would have the same issues as CIDER. 4.3. Open Numbering Plans The E.164 number model is technically an open numbering plan, meaning it does not specify a fixed number of digits. In some countries, the national numbering plan has a fixed number (e.g., Kaplan Expires - January 2014 [Page 10] Internet-Draft CIDER July 2013 North America does), but in others it is left open (e.g., Germany). For CIDER, this has implications if the source identity could be more digits than the CIDER Registrar knows about and has granted upload access to a CIDER Assignee for. For example, in Germany not only is the numbering plan open, but the number assignment model is as well: an Enterprise is given a single phone number, and the Enterprise can then add a variable number of digits at the end for their specific lines/users. For routing purposes, the carriers only need to route on the assigned number portion, and the Enterprise's PBX can route the final leg to the user based on the whole number. If the Enterprise can also claim the longer number sequence as a caller-id, but the CIDER Registrar only has entries for the assigned portion, then verification will fail. This document does not specify a solution to this problem, but leaves it as an open issue to be decided upon. There are at least two potential solutions we can choose from: o CIDER could specify that Assignees can upload information to create subdomains within their assigned E.164 identity entry node. For example, let the Enterprise notify the carrier of the extra digits and their public keys, and the carrier in turn uploads it to the Registry. o We could require the SIP/XMPP/SS7 message information include the number of significant digits to use, so that CIDER is only queried for the assigned number portion; and have the TXT RR for the assigned number indicate that it's an open number. 5. Caller-ID vs. DNS Delegation and Authority Models The concept of delegation and authority is somewhat confusing when referring to CIDER, because the terms are used in two different ways: one is the delegation and authority model of DNS subdomains/zones, and the other is delegation and authority model for caller-id identities and their public keys. CIDER makes a clear distinction between which entities are allowed to provision public keys into specific entries in the CIDER Registry, versus which entities own, control, administer and are authoritative for the DNS domains/zones in the hierarchy of the Registry. In other words, the CIDER Registry is split into two distinct aspects: the entities that own the Registry and thus the DNS domains/zones used to access those public keys, and the entities that are assigned rights to upload public key information for their Kaplan Expires - January 2014 [Page 11] Internet-Draft CIDER July 2013 assigned identity entries in the DNS-based Registry. The former are called "CIDER Registrars", and the latter are "CIDER Assignees". 5.1. Email-style Registries For email-style domain-based identities, CIDER uses the DKIM model of storing and retrieving the public keys from the identity domain's DNS zone. For example, if the source identity is "firstname.lastname@example.org", then the DNS zone "example.com" is used, and thus uses the supplied domain name, to follow the typical DNS delegation and authority model for its contents. Each domain is thus it own CIDER Registrar as well as its own CIDER Assignee, and there is no distinction between the delegation and authority model for DNS versus the caller-id identities and public keys. If a domain owner wishes to allow another entity to use its domain name for caller-id verification, however, the owner can follow the same model as that defined in the next section for E.164 and number code registries. For example, if "example.com" wishes to allow a contracted third-party company to generate calls using "example.com", it can continue to be the CIDER Registrar for "example.com" and make the other company a CIDER Assignee for it as well. 5.2. E.164 and Number Code Registries For E.164 and number codes, the details for delegation and authority are separated. There is a CIDER Registrar which is the DNS authority for domains/zones/nodes, and the Registrar allows CIDER Assignees to upload public keys into specific identity entry nodes representing the E.164/number-codes. While it is tempting to consider using the DNS subdomain delegation model for delegating DNS zones for specific E.164-based ranges or specific numbered entries to the carriers or end users to which the numbers are assigned. CIDER does not depend on such a DNS delegation model, and in fact it is expected such a DNS delegation model will not be used in practice; this is due to both the need to maintain privacy of who the carrier or end-user is for each number, and because the number portability behavior in some national numbering plans would make such a model untenable. For example, from a DNS and DNSSEC perspective, the DNS zone authority for each of the subdomains within 'cid.example.org' (the country-code CIDER Registrars) could be the national numbering plan administrator for each country-code, possibly determined by the ITU to be authoritative for the anchor 'cid.example.org'. Kaplan Expires - January 2014 [Page 12] Internet-Draft CIDER July 2013 Below the country-code level domain, each nation and national number authority can decide how they choose to delegate DNS zone authority, or not to. There is no requirement to delegate out DNS zone authority below the national country-code level whatsoever, nor any prohibition from doing so; the country-code authority can be the DNS authority for the entire E.164 number space of DNS domains/nodes under their country-code level. [Note: for North America, the DNS delegation could be separated by area-codes; to give Canada's area- codes a different authority from those in the USA, for example] In fact, having a single DNS authority might have some advantages: it prevents people from learning how many numbers each carrier has, and it reduces the time for caller-id verification because the DNSSEC authority signing chain is shorter. Since most calls are national calls, the verifying systems can use a local cache of the national numbering administrator's certificate to verify the certificate of most E.164 caller-ids. The important distinction is that it does not matter who manages the CIDER DNS registry for a given country-code - what's important is that the CIDER Registrar allows the entities which are assigned the E.164 numbers (the CIDER Assignees) to upload their public keys into their respective E.164-based nodes. For example the CIDER Registrar can allow a SIP service provider to be the Assignee for a set of the Registry's E.164 entries, so that the service provider can upload the public keys it wishes to use for its caller-ids. From a DNS perspective, however, the Registrar is still the singular authority of the DNS zones/nodes for those E.164- based nodes. The domain tree and its zones/nodes "belong" to the Registrar from a DNS perspective. 6. Assignee Roles and Actions As explained previously, CIDER creates a distinction between the DNS authority (the CIDER Registrar) vs. an entity allowed to upload public keys (the CIDER Assignee). For every identity entry in the DNS tree (i.e., leaf node), the Registry has one and only one CIDER Assignee. The Assignee may be the Registrar itself, as would usually be the case for email-style domain-based identity CIDER Registries for example. For E.164-based identities, the Assignee probably is the service provider/carrier assigned the number by the national numbering authority for the given country-code. The Assignee has controlled access to the Registry for performing the actions it can take. This may be through a web portal, or even via email or fax; if the STIR Working Group decides to continue with Kaplan Expires - January 2014 [Page 13] Internet-Draft CIDER July 2013 CIDER, however, the author strongly recommends that a specific protocol be defined for this purpose in another document: a CIDER Assignee Publishing Protocol (CAPP). For example, CAPP could be either an HTTP/SOAP/XML or HTTP/REST type protocol. CAPP would be useful for DKIM and DNS in general, and as an alternative for Dynamic DNS [DDNS]. Requirements for CAPP are given in Appendix B. An Assignee can add, modify, or remove public key entries from its identity node(s) in the Registry, and thereby affect the available TXT RR entries. Depending on how open numbering assignment is handled (currently an open issue in this document), the Assignee might be able to add, modify, or remove subdomain/additional-digit identities below the one the Registrar granted it access to, if the Registrar allows it. If the Registrar allows it, an Assignee can permanently transfer control of its identity node to another Assignee, which is called "donating" its identity in this document. Such would be the case for number porting in certain countries, for example. An Assignee can also grant/rescind access to Key Agents for its identity entries(s), if the Registrar supports such a model, as described in the next section. 6.1. Key Agents and Third-Party Private Agents One of the use-cases a Caller-ID verification mechanism needs to support is that of enabling a third-party to assert someone else's Caller-ID for outbound calls/communications. An example of this need is outsourced call-centers making calls on behalf of a company, or even a doctor using her personal mobile phone to make calls with her medical office's number as her Caller-ID. CIDER supports this in two ways: by either having the CIDER Registrar support an Assignee and one or more designated Key Agents for the same identity entry, or by having the Registrar only know about the CIDER Assignee and having the third-parties upload their public keys through the Assignee as Third-Party Private Agents. The difference between a Key Agents and Third-Party Private Agents is one of involvement with the Registrar and Registry. If a Registrar supports Key Agents, then the Assignee has to grant this role, and the Registrar has to know about them, have credentials for them, etc. With Third-Party Private Agents, however, the Registrar knows nothing about it - the third-party uploads public keys to the Assignee directly (e.g., using CAPP), which then uploads them to the Registry in the same manner as its own public keys (again using CAPP). Kaplan Expires - January 2014 [Page 14] Internet-Draft CIDER July 2013 From a Caller-ID verifier's perspective - from the data it can view in the retrieved Resource Records - there is no difference between Assignee, Key Agents or Third-Party Private Agents. In fact the verifier can't even discern who the Assignee is. 7. Using CIDER for Caller-ID Verification CIDER specifies a key retrieval mechanism The mechanics of Caller-ID verification that use the key is left for definition by a separate document. One example of such a mechanism is defined in [draft- ikes]. This section defines the information a verifier CIDER client needs in order to retrieve the appropriate public key for a verification mechanism, and how the retrieval is performed. 7.1. CIDER DNS Client Requirements A Caller-ID verifier acting as a CIDER DNS client MUST implement DNS over UDP using [EDNS0] in order to handle message sizes larger than 512 bytes. The client MUST be prepared to receive DNSSEC responses, unknown RRs, etc. If the verifier supports email-style identities, it MUST be able to query DNS servers which resolve public Internet DNS names. If the verifier supports E.164-base identities, it is RECOMMENDED that the client be configurable to use different DNS server(s) for this purpose, separate from the one(s) used for other identity types. The client SHOULD also support being configurable for using a different anchor domain name for this purpose, separately from the one used for number code identities. If the verifier supports number code-based identities, it is RECOMMENDED that the client be configurable to use a different DNS server(s) for this purpose, separate form the one(s) used for other identity types. The client SHOULD also support being configurable for using a different anchor domain name for this purpose, separately from the one used for E.164-based identities. The client MAY be a recursive resolver, but it is strongly RECOMMENDED that it be a stub resolver and allow the DNS servers to resolve on its behalf. Otherwise, it will be difficult to use such a client in access-restricted CIDER deployments, such as private or federated ones. For example if the CIDER Registry is a private one for one or more nations. (see Appendix A) Kaplan Expires - January 2014 [Page 15] Internet-Draft CIDER July 2013 7.2. Information Needed by the Caller-ID Verifier For CIDER to function properly, a Caller-ID verifier needs to know the following information: o The source identity value o The source identity type: domain-based, E.164-based, or number code-based o The public key index value The public key index value identifies which of several possible public keys for a given source identity should be used for verifying the message. The source identity value need not be the whole source identity as a URI or 'user@domain' string - it only needs to be the information used for the CIDER query as defined in the next section. 7.3. Generating the CIDER DNS query In order to generate a CIDER DNS query, the CIDER verifier performs slightly different actions depending on the source identity type, as defined in these sections. 7.3.1 Query for Email-style Identity For an email-style source identity, the verifier CIDER client takes the 'user@domain' string and ignores the "user@" portion. The remaining domain name becomes the base of the DNS query key. The verifier prepends the CIDER public key index value as a subdomain, followed by the subdomain "_cidkey", in front of the domain name. For example, if the source identity being verified is "email@example.com" with a public key index value of 3, the DNS query key becomes "3._cidkey.example.com". The verifier then issues a DNS query with the above query key to the public Internet DNS. 7.3.2 Query for E.164-based Identity For an E.164-based source identity, the verifier CIDER client takes the international E.164 digit string, removes any leading '+' or visual separators, puts dots (".") between each digit, and reverses the order of digits. The verifier then appends the E.164-based CIDER Registrar domain name to the end, and prepends the CIDER public key index value as a subdomain, followed by the subdomain "_cidkey". Kaplan Expires - January 2014 [Page 16] Internet-Draft CIDER July 2013 For example, if the source identity being verified is "+16035551010" with a public key index value of 2, and a CIDER Registrar domain for the country-code 1 of "1.cid.example.org", then the DNS query key becomes "2._cidkey.0.1.0.1.22.214.171.124.0.6.1.cid.example.org". The verifier then issues a DNS query with the above query key to either the public Internet DNS, or to the DNS server provisioned for such a purpose. 7.3.3 Query for Number Code-based Identity For a nationally-specific number code-based source identity, the verifier CIDER client takes the number code digit string, prepends the country-code the number code is nationally-specific for, puts dots (".") between each digit, and reverses the order of digits. The verifier then appends the Number-code CIDER Registrar domain name to the end, and prepends the CIDER public key index value as a subdomain, followed by the subdomain "_cidkey". For example, if the source identity being verified is "911" for the country-code 1, with a public key index value of 2, and a Number- code CIDER Registrar domain of "cid.example.org", then the DNS query key becomes "2._cidkey.126.96.36.199.cid.example.org". The verifier then issues a DNS query with the above query key to either the public Internet DNS, or to the DNS server provisioned for such a purpose. 7.4. Processing the DNS Answer Based on the DNS binding format defined in Section 8, a successful CIDER DNS query will produce a DNS answer with a TXT RR as defined in Section 8.3. The verifier needs to parse the TXT RR, to verify the version is "CIDER1", the key-type is "rsa" or some token the verifier understands, and to base64 decode the public key data. If the version is not "CIDER1", or the key-type is not one the verifier understands, or the public key cannot be decoded or is not of a key size the verifier supports, then the verifier should treat it as a failure. If the public key is empty, the verifier should treat it as a failure. If the DNS answer is 'not found', the verifier should treat it as a failure. If the DNS query times out, the client should try any alternate servers it is provisioned for; if there are no more, it should treat it as a failure. The action to take for a CIDER query failure is dependent on local policy and not defined in this document. Kaplan Expires - January 2014 [Page 17] Internet-Draft CIDER July 2013 8. DNS Binding A binding using DNS TXT records as a key service is hereby defined. All implementations MUST support this binding. 8.1. Subdomain Namespace All CIDER keys are stored in a subdomain named "_cidkey", with a node name of the key index value. Given an email-style source identity of "firstname.lastname@example.org" and a key index of "3", the DNS query will be for "3._cidkey.example.com". Given an E.164 source identity of "16035551010" and a key index of "1", the DNS query will be for "1._cideky.0.1.0.1.188.8.131.52.0.6.1.cid.example.org". Given a nationally-specific number code for "911" in the North-American Numbering Plan region (country-code 1), and a key index of "6", the DNS query will be for "6._cidkey.184.108.40.206.cid.example.org". 8.2. Resource Record Type for Key Storage The DNS Resource Record type used in this specification is a TXT Resource Record (RR). A later extension of this standard may define another RR type. Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace. TXT RRs MUST be unique for a particular key index value; that is, if there are multiple records in an RRset, the results are undefined. 8.3. TXT Record Format The TXT RR used for the CIDER key MUST follow the format specified in this section, in order to provide future extension capability. No whitespace is allowed in this format, and all values are case- sensitive. The format is based on the following ABNF: txt-record = version-param SEMI key-param [ SEMI txt-param ] version-param = "v=" "CIDER1" key-param = key-type SEMI key-data key-type = "k=" ("rsa" / hyphenated-word) key-data = "p=" DQUOTE [ base64 ] DQUOTE The version identifies the TXT record content syntax and semantics, which for this document is defined as "CIDER1". The key-type identifies the CIDER public key's (the "p=" value) type, which for this specification uses the "rsa" key type to indicate that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey [RFC3447] is being used in the key-data's value. Future Kaplan Expires - January 2014 [Page 18] Internet-Draft CIDER July 2013 specifications may define other key types by assigning thi field a different value, but still using the "CIDER1" version. The key-data identifies the CIDER public key value, in base64 encoded form. An empty value (the literal string 'p=""'), means the public key for this index is not usable or has been explicitly revoked as opposed to simply removed. This might be useful if the CIDER DNS authority wishes to prevent use of a specific key index node entry for some time period of time by having an essentially empty TXT RR, as opposed to deleting the entry and re-using it when the next public key is uploaded by the assigned party. 9. Security Considerations The same security considerations as described in [DKIM] apply to CIDER; in particular Sections 8.2, 8.3, 8.4, 8.6, and 8.7 of [DKIM]. 9.1. Privacy of Assignee For E.164-based CIDER Registries, privacy of assignee is a concern. The concern stems from the need to keep the assignee of an E.164 number unknown in general - to prevent simple scripts from being used to walk the CIDER DNS tree and learn what E.164 numbers are assigned to which carrier, for example. An example of why this needs to remain private is that using such knowledge one could learn how many subscribers a publicly-traded mobile provider has gained or lost in a quarter, and be able to buy or sell stock based on such knowledge in advance of the provider's quarterly-reported statements. Such information could be easily learned if only one a few public keys are used by a carrier for all of its numbers in the CIDER Registry. To defend against such abuse, it is strongly RECOMMENDED that assignees only re-use the same public key for a limited number of CIDER entries. For example a large assignee might use the same public key for a thousand or ten thousand of its E.164 numbers. It should be noted that this security concern is not specific to using DNS - any open-access database protocol would be vulnerable to a script querying all entries. Controlled-access databases would be of less concern, but CIDER can also be used in a controlled-access model. 10. Open Issues - How to handle open numbering plan assignment country-codes. Kaplan Expires - January 2014 [Page 19] Internet-Draft CIDER July 2013 11. IANA Considerations This document makes no request of IANA yet. 12. Acknowledgments The general concept of using DNS in an ENUM model for caller-id verification has been discussed in the IETF for many years. Thanks to Dave Crocker for pointing out the DKIM similarities and usage, and for reviewing the draft in detail. Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 13. References 13.1. Normative References [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [DDNS] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC3007, November 2000. [ITU.X660.1997] "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.660, 1997. [RFC3447] Jonsson, J., and Kaliski, B., "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC3447, February 2003. 13.2. Informative References [fcc-doc] http://hraunfoss.fcc.gov/edocs_public/attachmatch/DA-11- 1089A1.doc [draft-ikes] Kaplan, H., "An Identity Key-based and Effective Signature for Origin-Unknown Types", draft-kaplan-stir-ikes- out-00, July 2013. [RFC4474] Peterson, J., and Jennings, C., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC4474, August 2006. [draft-4474bis] Peterson, J., Jennings, C., and Rescorla, E., "Authenticated Identity Management in the Session Initiation Kaplan Expires - January 2014 [Page 20] Internet-Draft CIDER July 2013 Protocol (SIP)", draft-jennings-dispatch-rfc4474bis-00, May 2013. [DKIM] Allman, E., et al, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. Author's Address Hadriel Kaplan Email: email@example.com Appendix A. Possible Deployment Model In order to understand how CIDER could work in the real world, this section provides an example of how CIDER could be deployed in the North American Numbering Plan (NANP). This was chosen for the example because the NANP is one of the most complicated numbering models in the World: it has 24 member countries and territories, full number portability for both fixed and mobile line numbers in certain countries, separate numbering authorities (e.g., CRTC/CNA and NANC/NANPA), and multi-tiered numbering assignment/delegation behavior. Today, the entire +1 NANP is administered by the North American Numbering Plan Administrator (NANPA), but certain functions are handled by separate organizations: the Canadian Number Administrator (CNA) handles certain functions for Canadian area-codes, for example, and the USA and Canada each have a separate administrator for their respective number portability databases. Within each country, numbers are officially assigned in blocks to legally- authorized carriers, who then (unofficially) assign them to their customers: non-carrier service providers, enterprises, and consumers. For the countries in NANP that support number portability, the original carrier "donates" the ported number to another carrier, and the number portability database is updated with a mapping of the ported number to an assigned switch number: the Location Routing Number (LRN). Numbers are not portable across countries within the NANP, and are not portable in certain cases even within a country. One way CIDER could be deployed in the NANP is by having NANPA be the CIDER Registrar for the country-code 1 top domain, and delegate DNS domains for country-specific area-codes to their respective country administrators. For example, NANPA could be the CIDER Registrar for '.1.cid.example.org', but then delegate authority of the DNS subdomains '.220.127.116.11.cid.example.org', Kaplan Expires - January 2014 [Page 21] Internet-Draft CIDER July 2013 '.18.104.22.168.cid.example.org', etc., (representing the Canadian area codes 204, 236, etc.) to the CRTC/CNA if they wish it. Thus the CRTC/CNA would be the CIDER Registrar for those area-code branches of the number tree. An alternative would be to have a private organization be the CIDER Registrar for the +1 country-code using its own domain for the Registry, such as '.1.example.org'. This would only be useful if carriers/service-providers agreed to use this Registry, of course, but this might make sense as a way to get the effort started and eventually transition it over to NANPA. One specific model for who the Registrar could be would be to use the same administrator as that used for number portability. Currently the US-based FCC selects a company to run the NPAC (Number Portability Administration Center) for the US, and the CRTC selects one for Canada; they could contract the CIDER Registrar role to the same companies they contract number portability administration to. This has some obvious benefits, but also some drawbacks with regard to federal regulatory involvement and monopoly-type power/position for the contracted vendor(s). Regardless of whom the Registrar is and what the Registry top domain name is, the officially assigned carriers for numbers would be designated as the Assignees of their respective number identity nodes. They can upload public keys for those number nodes, in order to perform the role of caller-id signers. When they assign numbers to their customers, they could either add them as Key Agents in the Registry, or handle them as Private Agents, as described in Section 6.1. In practice, it's likely they would only add their customers as Key Agents if the "customers" were service providers, but otherwise handle customers as Third-Party Private Agents. When a number is ported from one carrier to another, the Assignee carrier would transfer assignee control by "donating" their identity to the other carrier, as described in Section 6. This would need to occur at the same general time as porting the number in the number portability databases, and would need to take effect within 15 minutes. Having a defined protocol between the Assignee and the Registry, for publishing the keys into identity nodes, would help this process greatly. This would be implemented in the same carrier back-office systems that are used today for number porting, for example. From a DNS query access perspective, it is likely that the CIDER Registry for NANP begin as a private database model. Only authorized entities would be able to query the CIDER Registry, Kaplan Expires - January 2014 [Page 22] Internet-Draft CIDER July 2013 either using IPSEC/VPN-style access, or by having each carrier have a local read-only copy of the CIDER Registry. Most carriers would likely have such local copies of the Registry, in servers they deploy within their core call control network, to reduce verification time and control availability/reliability. All 500 million current NANP numbers instantiated in a CIDER Registry would fit in ~500GB, which even laptops have sufficient storage for. It would only take two or three modern high-end servers to fit it all in *RAM*, let alone hard-drive/flash. For carriers to have local copies of the Registry, they could use [AXFR], [IXFR], and [DNS-NOTIFY]; or a more-efficient protocol could be defined for this purpose. Modern DNS servers offer more than just the legacy DNS-based zone transfer/update protocols, and the newer protocols could be investigated for re-use for CIDER local copying. If each national CIDER Registry is not publicly accessible for DNS querying on the public Internet, this causes some issues for international call scenarios. The goal of CIDER is to enable caller-id verification even for international calls/communications. This is still achievable, however, because there aren't that many country-codes and national numbering plans - there are approximately ~160 such in the World. Therefore, it is reasonable for each national CIDER Registry to have a private, controlled connection to every other national Registry, creating a full mesh of connections. The private connections could be used to either provide server resolution of private DNS queries on behalf of the local nation's carriers' verification clients, or for the local nation's Registrar to itself have a local copy of the CIDER Registry of other nations, using the same protocol mechanics as the carriers use for their local Registry copies. Even 10 Billion number entries in a CIDER Registry read-only database would only consume ~10 Terabytes of storage, which is achievable for reasonable cost today. In practice, each national Registry would likely use a hybrid model: performing DNS queries to nations that are infrequent callers, while having local copies of Registries of frequent calling nations. Appendix B. Requirements for a CAPP Mechanism In order for CIDER to be usable in large scale across many carriers, there needs to be a defined protocol for how CIDER Assignees perform their allowed actions to the Registry. This document describes such a protocol as CIDER Assignee Publishing Protocol (CAPP), and this section gives the requirements for such a protocol, as input to Kaplan Expires - January 2014 [Page 23] Internet-Draft CIDER July 2013 another document to specify the CAPP protocol itself. Some of the requirements are based on the actions described in Section 6. Requirements for CAPP: o It must support the add, modify, and delete actions for CIDER identity node data. o It may only support handling the data in an opaque/blob manner. For example CAPP may only support uploading a TXT RR text string, instead of explicitly handling the public key value, version, and key type as discrete elements. This way it's not specific to CIDER usage. o It should support the add, modify, or delete actions for other DNS Resource Record types, or at least be extensible to do so in the future. This would allow non-CIDER usage, as well as allow extending CIDER for other number mapping use-cases: such as CNAM, number portability, or request routing purposes. o When adding new public key data (or a new TXT RR), it should be possible for the Assignee not to specify the key index (i.e., subnode) value for the new record, and instead for the server to return the new value it allocates. This is useful for Third-Party Private Agent model, where the Third-Party may not know the next available index value to use. o It should support a means of adding new data and returning the new key index value in separate transactions - or at least in some manner that allows for multiple minutes of time to pass between the addition of data and returning of new index value. o When adding new data, it must allow the Assignee to define an expiration time for the data. This is useful for the Third- Party Agent model described in Section 6.1, for example. o It must allow the Assignee to permanently transfer the Assignee role to another party, called "donate" in this document. o It should allow the Assignee to grant/rescind another entity the role of Key Agent for a given identity entry node, permanently or with an expiration time. o It must support an action/transaction model that allows for database atomicity, consistency, isolation, and durability (ACID). o It should provide a means for the Assignee to add or modify multiple identity node entries using one TXT RR (or one public key) in one transaction. This is a useful optimization for carriers that have millions of numbers, and re-use public keys across them. To support ACID more easily, however, this might be done using an indirection model. o It must specify distinct failure and error results, in a machine-consumable fashion. o It must support a means of logging each transaction (action/result) on both the client and server side such that both sides can easily reference the same event; for example by Kaplan Expires - January 2014 [Page 24] Internet-Draft CIDER July 2013 encoding transaction identifiers and timestamps in the CAPP protocol messages. o It must support a means for the Registry server to authenticate a client Assignee; for example using credentials of a username/password digest-challenge model. o It must support a means for the client Assignee to authenticate the Registry server; for example by using TLS server-side certificates. o It must support a means of preventing eavesdropping and repudiation, for example by using TLS. Kaplan Expires - January 2014 [Page 25]