[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/