draft-ietf-acme-telephone-00.txt   draft-ietf-acme-telephone-01.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Informational R. Barnes Intended status: Informational R. Barnes
Expires: January 4, 2018 Mozilla Expires: May 3, 2018 Mozilla
July 3, 2017 October 30, 2017
ACME Identifiers and Challenges for Telephone Numbers ACME Identifiers and Challenges for Telephone Numbers
draft-ietf-acme-telephone-00.txt draft-ietf-acme-telephone-01.txt
Abstract Abstract
This document specifies identifiers and challenges required to enable This document specifies identifiers and challenges required to enable
the Automated Certificate Management Environment (ACME) to issue the Automated Certificate Management Environment (ACME) to issue
certificate for telephonoe numbers. certificate for telephonoe numbers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Telephone Number Identifier Type . . . . . . . . . . . . . . 3 3. Telephone Number Identifier Type . . . . . . . . . . . . . . 3
4. Challenges for Telephone Numbers . . . . . . . . . . . . . . 3 4. Challenges for Telephone Numbers . . . . . . . . . . . . . . 3
4.1. Service Provider Validation . . . . . . . . . . . . . . . 4 4.1. Service Provider Validation . . . . . . . . . . . . . . . 4
4.2. Web-Based Telephone Number Routability Validation . . . . 5 4.2. Web-Based Telephone Number Routability Validation . . . . 5
4.3. Advanced Routability Validation . . . . . . . . . . . . . 6 4.3. Advanced Routability Validation . . . . . . . . . . . . . 6
4.4. Authority-Based Validation . . . . . . . . . . . . . . . 6 4.4. Authority-Based Validation . . . . . . . . . . . . . . . 6
4.5. Telephone Number Range Validation . . . . . . . . . . . . 6 4.5. Telephone Number Range Validation . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
ACME [I-D.ietf-acme-acme] is a mechanism for automating certificate ACME [I-D.ietf-acme-acme] is a mechanism for automating certificate
management on the Internet. It enables administrative entities to management on the Internet. It enables administrative entities to
prove effective control over resources like domain names, and prove effective control over resources like domain names, and
automtes the process of generating and issuing certificates. automtes the process of generating and issuing certificates.
The STIR problem statement [RFC7340] identifies the need for Internet The STIR problem statement [RFC7340] identifies the need for Internet
credentials that can attest authority for telephone numbers in order credentials that can attest authority for telephone numbers in order
to detect impersonation, which is currently an enabler for common to detect impersonation, which is currently an enabler for common
attacks associated with illegal robocalling, voicemail hacking, and attacks associated with illegal robocalling, voicemail hacking, and
swatting. These credentials are used to sign PASSporTs swatting. These credentials are used to sign PASSporTs
[I-D.ietf-stir-passport], which may be carried in using protocols [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 such as SIP [I-D.ietf-stir-rfc4474bis] or delivered outside of the
signaling channel of call setup [I-D.rescorla-stir-fallback]. signaling channel of call setup [I-D.ietf-stir-oob]. Currently, the
Currently, the only defined credentials for this purpose are the only defined credentials for this purpose are the certificates
certificates specified in [I-D.ietf-stir-certificates]. specified in [I-D.ietf-stir-certificates].
[I-D.ietf-stir-certificates] describes certificate extensions [I-D.ietf-stir-certificates] describes certificate extensions
suitable for associating telephone numbers with certificates. To suitable for associating telephone numbers with certificates. To
help enable certificate authorities to issue certificates with these help enable certificate authorities to issue certificates with these
extensions, this specification defines extensions to ACME suitable to extensions, this specification defines extensions to ACME suitable to
enable certificate authorities to validate effective control of enable certificate authorities to validate effective control of
numbering resources and to issue corresponding certificates. numbering resources and to issue corresponding certificates.
Note that the aim of the initial challenges specified in this Note that the aim of the initial challenges specified in this
document is not to prove the assignment and delegation of resources document is not to prove the assignment and delegation of resources
skipping to change at page 4, line 40 skipping to change at page 4, line 40
though again, because of the diverse capabilities of the devices though again, because of the diverse capabilities of the devices
involved, different schemes for refreshing the challenge, ones that involved, different schemes for refreshing the challenge, ones that
require less direct user supervision, may be available to some require less direct user supervision, may be available to some
devices and not others. devices and not others.
4.1. Service Provider Validation 4.1. Service Provider Validation
Communications Service Providers (CSPs) can delegate authority over Communications Service Providers (CSPs) can delegate authority over
numbers to their customers, and those CSPs who support ACME can then numbers to their customers, and those CSPs who support ACME can then
help customers to acquire certificates for those numbering resources help customers to acquire certificates for those numbering resources
with ACME. The system of [I-D.barnes-acme-service-provider] for with ACME. The system of [I-D.ietf-acme-service-provider] for
example gives a mechanism that allows service providers to acquire example gives a mechanism that allows service providers to acquire
certificates corresponding to a Service Provider Code (SPC) as certificates corresponding to a Service Provider Code (SPC) as
defined in [I-D.ietf-stir-certificates]. This can permit number defined in [I-D.ietf-stir-certificates]. Once service providers have
certificates for SPCs, those could be leveraged to enable number
acquisition flows compatible with those shown in acquisition flows compatible with those shown in
[I-D.ietf-modern-problem-framework]. [I-D.ietf-modern-problem-framework], by using a token mechanism such
as the one described in [I-D.peterson-acme-authority-token].
type (required, string): The string "spc-delegate-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
contain any characters outside the URL-safe Base64 alphabet and
MUST NOT contain any padding characters ("=").
{
"type": "spc-delegate-00",
}
A client's response to this challenge will contain a token issued by
the CSP at the time of delegation, perhaps a token issued through a
MODERN-like [I-D.ietf-modern-problem-framework] acquisition
interface. The token must contain the delegated telephone number or
number range, the SPC of the CSP, a nonce, the signature of the CSP
with its SPC credential, and a link to a resource where relying
parties can acquire the SPC credential.
[TBD token format] [TBD token type registration and format]
The token must contain the delegated telephone number or number
range, the SPC of the CSP, a nonce, the signature of the CSP with its
SPC credential, and a link to a resource where relying parties can
acquire the SPC credential.
An ACME server supporting the Service Provider Validation for An ACME server supporting the Service Provider Validation for
telephone number certificates must have some way to determine whether telephone number certificates must have some way to determine whether
or not a telephone number falls within a particular SPC. This may or not a telephone number falls within a particular SPC. This may
involve consulting a local or external database that maps SPCs to involve consulting a local or external database that maps SPCs to
TNs. Without this check, CSPs would be able to issue credentials for TNs. Without this check, CSPs would be able to issue credentials for
numbers owned by other CSPs. The order should only be validated if numbers owned by other CSPs. The order should only be validated if
the telephone number in the order actually falls under the SPC that the telephone number in the order actually falls under the SPC that
signed the token. signed the token.
skipping to change at page 7, line 21 skipping to change at page 7, line 11
Future versions of this specification will include registrations for Future versions of this specification will include registrations for
the ACME Identifier type and ACME Challenge type registries here. the ACME Identifier type and ACME Challenge type registries here.
7. Security Considerations 7. Security Considerations
TBD. TBD.
8. Informative References 8. Informative References
[I-D.barnes-acme-service-provider]
Barnes, M. and C. Wendt, "ACME Identifiers and Challenges
for VoIP Service Providers", draft-barnes-acme-service-
provider-01 (work in progress), June 2017.
[I-D.ietf-acme-acme] [I-D.ietf-acme-acme]
Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic
Certificate Management Environment (ACME)", draft-ietf- Certificate Management Environment (ACME)", draft-ietf-
acme-acme-07 (work in progress), June 2017. acme-acme-07 (work in progress), June 2017.
[I-D.ietf-acme-service-provider]
Barnes, M. and C. Wendt, "ACME Identifiers and Challenges
for VoIP Service Providers", draft-ietf-acme-service-
provider-01 (work in progress), July 2017.
[I-D.ietf-acme-star] [I-D.ietf-acme-star]
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Use of Short-Term, Automatically-Renewed (STAR) Fossati, "Use of Short-Term, Automatically-Renewed (STAR)
Certificates to Delegate Authority over Web Sites", draft- Certificates to Delegate Authority over Web Sites", draft-
ietf-acme-star-00 (work in progress), June 2017. ietf-acme-star-00 (work in progress), June 2017.
[I-D.ietf-modern-problem-framework] [I-D.ietf-modern-problem-framework]
Peterson, J. and T. McGarry, "Modern Problem Statement, Peterson, J. and T. McGarry, "Modern Problem Statement,
Use Cases, and Framework", draft-ietf-modern-problem- Use Cases, and Framework", draft-ietf-modern-problem-
framework-02 (work in progress), March 2017. framework-03 (work in progress), July 2017.
[I-D.ietf-stir-certificates] [I-D.ietf-stir-certificates]
Peterson, J. and S. Turner, "Secure Telephone Identity Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir- Credentials: Certificates", draft-ietf-stir-
certificates-14 (work in progress), May 2017. certificates-14 (work in progress), May 2017.
[I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out of Band
Architecture and Use Cases", draft-ietf-stir-oob-00 (work
in progress), July 2017.
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-11 (work in (PASSporT)", draft-ietf-stir-passport-11 (work in
progress), February 2017. progress), February 2017.
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), February 2017. (work in progress), February 2017.
[I-D.rescorla-stir-fallback]
Rescorla, E. and J. Peterson, "STIR Out of Band
Architecture and Use Cases", draft-rescorla-stir-
fallback-02 (work in progress), June 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
<http://www.rfc-editor.org/info/rfc7340>. <https://www.rfc-editor.org/info/rfc7340>.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
 End of changes. 18 change blocks. 
48 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/