Internet DRAFT - draft-kaplan-stir-cider
draft-kaplan-stir-cider
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
"1.1.9.1.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
"alice@example.com", 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
"alice@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.5.5.5.3.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.1.1.9.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.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 "alice@example.com" 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.5.5.5.3.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.1.1.9.1.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", RFC 3007, 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", RFC 3447, 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)", RFC 4474, 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: hadrielk@yahoo.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 '.4.0.2.1.cid.example.org',
Kaplan Expires - January 2014 [Page 21]
Internet-Draft CIDER July 2013
'.6.3.2.1.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]
