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

Versions: 00 draft-ietf-acme-telephone

Network Working Group                                        J. Peterson
Internet-Draft                                                   Neustar
Intended status: Informational                                 R. Barnes
Expires: May 4, 2017                                             Mozilla
                                                        October 31, 2016


         ACME Identifiers and Challenges for Telephone Numbers
                  draft-peterson-acme-telephone-00.txt

Abstract

   This document specifies identifiers and challenges required to enable
   the Automated Certificate Management Environment (ACME) to issue
   certificate for telephonoe numbers.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on May 4, 2017.

Copyright Notice

   Copyright (c) 2016 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.




Peterson & Barnes          Expires May 4, 2017                  [Page 1]


Internet-Draft                ACME for TNs                  October 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Telephone Number Identifier Type  . . . . . . . . . . . . . .   3
   4.  Challenges for Telephone Numbers  . . . . . . . . . . . . . .   3
     4.1.  Web-Based Telephone Number Routability Validation . . . .   4
     4.2.  Advanced Routability Validation . . . . . . . . . . . . .   5
     4.3.  Telephone Number Range Validation . . . . . . . . . . . .   5
     4.4.  Authority-Based Validation  . . . . . . . . . . . . . . .   5
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [I-D.ietf-acme-acme] is a mechanism for automating certificate
   management on the Internet.  It enables administrative entities to
   prove effective control over resources like domain names, and
   automtes the process of generating and issuing certificates.

   The STIR problem statement [RFC7340] identifies the need for Internet
   credentials that can attest authority for telephone numbers in order
   to detect impersonation, which is currently an enabler for common
   attacks associated with illegal robocalling, voicemail hacking, and
   swatting.  These credentials are used to sign PASSporTs
   [I-D.ietf-stir-passport], which may be carried in using protocols
   such as SIP [I-D.ietf-stir-rfc4474bis] or delivered outside of the
   signaling channel of call setup [I-D.rescorla-stir-fallback].
   Currently, the only defined credentials for this purpose are the
   certificates specified in [I-D.ietf-stir-certificates].

   [I-D.ietf-stir-certificates] describes certificate extensions
   suitable for associating telephone numbers with certificates.  To
   help enable certificate authorities to issue certificates with these
   extensions, this specification defines extensions to ACME suitable to
   enable certificate authorities to validate effective control of
   numbering resources and to issue corresponding certificates.

   Note that the aim of the initial challenges specified in this
   document is not to prove the assignment and delegation of resources
   in the telephone network: it is instead to establish whether
   Internet-enabled entites have effective control over the devices
   associated with those resources.  Such credentials are not mutually
   exclusive with credentials delegated from national authorities, and
   future versions of this specification will explore issuance of those



Peterson & Barnes          Expires May 4, 2017                  [Page 2]


Internet-Draft                ACME for TNs                  October 2016


   credentials as well.  For the purposes of a call set-up protocol like
   SIP, there may be multiple attestations (for example, multiple SIP
   Identity header fields) signed by different parties.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in [RFC2119].

3.  Telephone Number Identifier Type

   In order to issue certificates for telephone numbers with ACME, a new
   ACME identifier type for telephone numbers is required for use in
   ACME authorization objects.  The baseline ACME specification only
   defines one type of identifier, for a fully-qualified domain name
   ("dns").  This document thus defines a new ACME identifier type for
   telephone numbers ("tn").  This represents a telephone number,
   specifically a number of the type that is specified in the TN
   Authorization List certificate extension of
   [I-D.ietf-stir-certificates] for E164Number.

   {
     "status": "valid",
     "expires": "2015-03-01T14:09:00Z",
     "identifier": {
       "type": "tn",
       "value": "2125551212"
     },
     "challenges": [
       {
         "type": "sms-link-00",
         "status": "valid",
         "validated": "2014-12-01T12:05:00Z",
         "keyAuthorization": "SXQe-2XODaDxNR...vb29HhjjLPSggwiE"
       }
     ]
   }

4.  Challenges for Telephone Numbers

   Proving that a device on the Internet has effective control over a
   telephone number is not as easy as proving control over an Internet
   resources like a DNS zone or a resource on the web.  Issuing
   certificates for telephone numbers is perhaps most closely analogous
   to certificates for email addresses: end user control over an email
   address boils down to the capabilities to read and send email



Peterson & Barnes          Expires May 4, 2017                  [Page 3]


Internet-Draft                ACME for TNs                  October 2016


   associated with that address.  While a user typically has control
   over an email address for a long period of time, control over email
   addresses can change when users leave companies or other
   institutions, and addresses may subsequently end up in the control of
   another party.  Moreover, while it is relatively easy to spoof the
   sender of any email address, as it unfortunately is with telephone
   numbers, it is harder to intercept traffic to a target email address
   or telephone number.

   The likely challenges for proving effective control over a telephone
   number therefore rely largely on routing some kind of secret to the
   telephone number in question and requesting that the receiving device
   play that secret back to the ACME server.  The Short Message Service
   (SMS) provides a key building block for challenges because of its
   ability to route a secret addressed to a telephone number to a user-
   controlled device.  However, because of the diverse capabilities of
   Internet-connected devices that control telephone numbers, an SMS
   could be used in different ways for different challenges.  Some
   devices will be able to interrogate their operating system to learn
   their own telephone number, for example, while others cannot.  Some
   devices will be able to receive a text message and suppress it from
   being rendered to the user, while others cannot.

   Because the assignment of numbering resources can change over time,
   demonstrations of effective control must be regularly refreshed --
   though again, because of the diverse capabilities of the devices
   involved, different schemes for refreshing the challenge, ones that
   require less direct user supervision, may be available to some
   devices and not others.

4.1.  Web-Based Telephone Number Routability Validation

   With web-based telephone number routability validation, the client in
   an ACME transaction proves its control over a telephone number by
   proving that it can receive traffic sent to that number over the
   PSTN.  The ACME server challenges the client to dereference a URL
   containing a token that is sent to the client over SMS.  Typically
   that token will be embedded in a URL that the end user will visit in
   order to be guided to a web resource that will enable account
   creation with the CA.  By allowing a user action to complete the
   challenge, this validation method supports the use of ACME with SMS
   endpoints that do not support automated response to challenges.

      type (required, string): The string "sms-link-00"

      token (required, string): A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 bits of entropy,
      in order to prevent an attacker from guessing it.  It MUST NOT



Peterson & Barnes          Expires May 4, 2017                  [Page 4]


Internet-Draft                ACME for TNs                  October 2016


      contain any characters outside the URL-safe Base64 alphabet and
      MUST NOT contain any padding characters ("=").

   {
     "type": "sms-link-00",
   }

   A client's response to this challenge simply acknowledges that it is
   ready to receive the validation SMS from the server.

   On receiving a response, the server sends an SMS message to the TN
   being validated containing a URL that the client must have a user
   access in order to complete the challenge.  This URL is intended to
   be opened in a web browser so that the user can have an interaction
   with the CA; it is not sufficient for the client to simply send a GET
   request to the URL.

   To validate an "sms-link" challenge, the server verifies that a user
   has visited the URL included in the SMS message and completed any
   steps specified there.

4.2.  Advanced Routability Validation

   Future versions of this specification will explore ways to increase
   the automation of the challenge process when the client device has an
   application capable of creating ACME accounts and requesting
   certificates to be issued.  This will likely follow the token / key-
   authorization pattern of the challenges defined for DNS names, except
   that the token and key authoriation will be passed in SMS instead of
   HTTP, TLS, or DNS.

4.3.  Telephone Number Range Validation

   Future versions of this specification will explore ways to validate
   bulk allocations of telephone numbers such as those used by IP PBXs.

4.4.  Authority-Based Validation

   Future versions of this specification will also explore ways that
   various numbering authorities could attest ownership over numbering
   resources, and ways that the assignees of numbers could coordinate
   with those authorities to satisfy ACME challenges and receive
   certificates.








Peterson & Barnes          Expires May 4, 2017                  [Page 5]


Internet-Draft                ACME for TNs                  October 2016


5.  Acknowledgments

   We would like to thank you for your contributions to this problem
   statement and framework.

6.  IANA Considerations

   Future versions of this specification will include registrations for
   the ACME Identifier type and ACME Challenge type registries here.

7.  Security Considerations

   TBD.

8.  Informative References

   [I-D.ietf-acme-acme]
              Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic
              Certificate Management Environment (ACME)", draft-ietf-
              acme-acme-03 (work in progress), July 2016.

   [I-D.ietf-stir-certificates]
              Peterson, J. and S. Turner, "Secure Telephone Identity
              Credentials: Certificates", draft-ietf-stir-
              certificates-10 (work in progress), October 2016.

   [I-D.ietf-stir-passport]
              Wendt, C. and J. Peterson, "Personal Assertion Token
              (PASSporT)", draft-ietf-stir-passport-09 (work in
              progress), October 2016.

   [I-D.ietf-stir-rfc4474bis]
              Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
              "Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-14
              (work in progress), October 2016.

   [I-D.peterson-modern-teri]
              Peterson, J., "An Architecture and Information Model for
              Telephone-Related Information (TeRI)", draft-peterson-
              modern-teri-01 (work in progress), July 2016.

   [I-D.rescorla-stir-fallback]
              Rescorla, E., "Secure Caller-ID Fallback Mode", draft-
              rescorla-stir-fallback-00 (work in progress), July 2013.






Peterson & Barnes          Expires May 4, 2017                  [Page 6]


Internet-Draft                ACME for TNs                  October 2016


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7340]  Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
              Telephone Identity Problem Statement and Requirements",
              RFC 7340, DOI 10.17487/RFC7340, September 2014,
              <http://www.rfc-editor.org/info/rfc7340>.

Authors' Addresses

   Jon Peterson
   Neustar, Inc.
   1800 Sutter St Suite 570
   Concord, CA  94520
   US

   Email: jon.peterson@neustar.biz


   Richard Barnes
   Mozilla

   Email: rlb@ipv.sx


























Peterson & Barnes          Expires May 4, 2017                  [Page 7]

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