draft-ietf-acme-service-provider-00.txt   draft-ietf-acme-service-provider-01.txt 
Network Working Group M. Barnes Network Working Group M. Barnes
Internet-Draft MLB@Realtime Communications Internet-Draft MLB@Realtime Communications
Intended status: Informational C. Wendt Intended status: Informational C. Wendt
Expires: December 22, 2017 Comcast Expires: January 19, 2018 Comcast
June 20, 2017 July 18, 2017
ACME Identifiers and Challenges for VoIP Service Providers ACME Identifiers and Challenges for VoIP Service Providers
draft-ietf-acme-service-provider-00 draft-ietf-acme-service-provider-01
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
certificates for VoIP service providers to support Secure Telephony certificates for VoIP service providers to support Secure Telephony
Identity (STI). Identity (STI).
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 http://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 December 22, 2017. This Internet-Draft will expire on January 19, 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 (http://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
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Identifier for Service Provider Codes . . . . . . . . . . . . 3 3. Identifier for Service Provider Codes . . . . . . . . . . . . 3
4. Challenges for Service Providers . . . . . . . . . . . . . . 3 4. Challenges for Service Providers . . . . . . . . . . . . . . 3
5. TNAuthList Identifier Code and Challenges Example . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5.1. ACME TNAuthList Identifier . . . . . . . . . . . . . . . 6
6.1. ACME TNAuthList Identifier . . . . . . . . . . . . . . . 5 5.2. ACME Service Provider Challenge . . . . . . . . . . . . . 7
6.2. ACME Service Provider Challenge . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
[I-D.ietf-acme-acme] is a mechanism for automating certificate [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
automates the process of generating and issuing certificates. automates 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 the originator of VoIP credentials that can attest authority for the originator of VoIP
calls in order to detect impersonation, which is currently an enabler calls in order to detect impersonation, which is currently an enabler
for common attacks associated with illegal robocalling, voicemail for common attacks associated with illegal robocalling, voicemail
hacking, and swatting. These credentials are used to sign PASSporTs hacking, and swatting. These credentials are used to sign PASSporTs
[I-D.ietf-stir-passport], which can be carried in using protocols [I-D.ietf-stir-passport], which can be carried in using protocols
such as SIP [I-D.ietf-stir-rfc4474bis]. Currently, the only defined such as SIP [I-D.ietf-stir-rfc4474bis]. Currently, the only defined
credentials for this purpose are the certificates specified in credentials for this purpose are the certificates specified in
[I-D.ietf-stir-certificates]. [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 and service provider codes suitable for associating telephone numbers and service provider codes
with certificates. [I-D.peterson-acme-telephone] specifies the ACME with certificates. [I-D.ietf-acme-telephone] specifies the ACME
extensions to enable certification authorities to issue certificates extensions to enable certification authorities to issue certificates
based on telephone numbers. This specification defines extensions to based on telephone numbers. This specification defines extensions to
ACME to enable certification authorities to issue certificates based ACME to enable certification authorities to issue certificates based
on service provider codes. on service provider codes.
2. Overview 2. Overview
The document [SHAKEN_Certificate_Mgmt] provides a framework and model The document [ATIS-1000080] provides a framework and model for using
for using certificates based on service provider codes. In this certificates based on service provider codes. In this model, each
model, each service provider requires only a few certificates, which service provider requires only a few certificates, which are used in
are used in conjunction with a PASSporT that contains additional conjunction with a PASSporT that contains additional information
information attesting to a service provider's knowledge of the attesting to a service provider's knowledge of the originator of the
originator of the call. Further details on the PASSporT extensions call. Further details on the PASSporT extensions for this model are
for this model are provided in the SHAKEN Framework [ATIS-1000074]. provided in the SHAKEN Framework [ATIS-1000074].
In the SHAKEN Certificate Management framework, there is an In the SHAKEN Certificate Management framework [ATIS-1000080], there
administrative entity that is responsible for allocating service is an administrative entity that is responsible for allocating
provider codes. This is referred to as the STI Policy Administrator service provider codes. This is referred to as the STI Policy
(STI-PA). This allows a certification authority to validate that the Administrator (STI-PA). This allows a certification authority to
entity requesting issuance of a certificate is authorized to request validate that the entity requesting issuance of a certificate is
certificates on behalf of the entity that has been assigned a authorized to request certificates on behalf of the entity that has
specific service provider code. A single VoIP service provider can been assigned a specific service provider code. A single VoIP
be allocated multiple service provider codes. A service provider can service provider can be allocated multiple service provider codes. A
choose to use the same certificate for multiple service providers as service provider can choose to use the same certificate for multiple
reflected by the structure of the TN Authorization List certificate service providers as reflected by the structure of the TN
extension defined in [I-D.ietf-stir-certificates]. Authorization List certificate extension defined in
[I-D.ietf-stir-certificates].
The intent of the challenges in this document is not to establish The intent of the challenges in this document is not to establish
that an entity is a valid service provider but rather to provide that an entity is a valid service provider but rather to provide
evidence that an established governance entity has authorized the evidence that an established governance entity has authorized the
entity to provide VoIP services in the network and thus to request entity to provide VoIP services in the network and thus to request
credentials on behalf of the VoIP users in the network. credentials on behalf of the VoIP users in the network.
3. Identifier for Service Provider Codes 3. Identifier for Service Provider Codes
In order to issue certificates for service providers based on service In order to issue certificates for service providers based on service
provider code values, a new ACME identifier type is required for use provider code values, a new ACME identifier type is required for use
in ACME authorization objects. The baseline ACME specification in ACME authorization objects. The baseline ACME specification
defines one type of identifier, for a fully-qualified domain name defines one type of identifier, for a fully-qualified domain name
("dns"). The document [I-D.peterson-acme-telephone] defines an ACME ("dns"). The document [I-D.ietf-acme-telephone] defines an ACME
identifier type for telephone numbers ("tn"). This document defines identifier type for telephone numbers ("tn"). This document defines
a new ACME identifier type for service provider codes ("TNAuthList"). a new ACME identifier type for service provider codes ("TNAuthList").
The "TNAuthList" identifier is the same type that is specified in the The "TNAuthList" identifier is the same type that is specified in the
TN Authorization List certificate extension TN Authorization List certificate extension
[I-D.ietf-stir-certificates] for service provider codes. An example [I-D.ietf-stir-certificates] for service provider codes.
is provided in Section 5.
4. Challenges for Service Providers 4. Challenges for Service Providers
The new "TNAuthList" identifier introduces a slightly different The new "TNAuthList" identifier introduces a slightly different
authorization process. A mechanism is required to allow the service authorization process. A mechanism is required to allow the service
provider to prove it has the authority to request certificates on provider to prove it has the authority to request certificates on
behalf of the entities for whom it is providing VoIP services. behalf of the entities for whom it is providing VoIP services. This
document defines a new ACME challenge type of "spc-token-01" to
The STI-PA in the SHAKEN Certificate Management framework has a support the authorization of service provider code tokens.
secure exchange with the Service Provider in order to provide a
service provider code token that the Service Provider can use for
authorization by the CA when requesting a certificate. The service
provider code token ("spc-token") is a standard JWT token [RFC7519]
using a JWS defined signature string [RFC7515]. Note that further
details on the CA interface to the STI-PA for the authorization are
provided in [SHAKEN_Certificate_Mgmt].
This document defines a new ACME challenges type of "spc-token" to
support the SHAKEN Certificate Management framework. An example of
the use of the "spc-token" for ACME is provided in Section 5.
5. TNAuthList Identifier Code and Challenges Example
The section provides examples of the use of the TNAuthList identifier
as a challenge mechanism.
The following is the response that the ACME client receives when it The following is the response that the ACME client receives when it
sends a GET for the challenges: sends a GET for the challenges in the case of a "TNAuthList"
identifer:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Link: <https://example.com/acme/some-directory>;rel="directory" Link: <https://example.com/acme/some-directory>;rel="directory"
{ {
"status": "pending", "status": "pending",
"identifier": { "identifier": {
"type": "TNAuthList", "type": "TNAuthList",
"value": ["1234-0111"] "value": ["1234-0111"]
}, },
"challenges": [ "challenges": [
{ {
"type": "spc-token", "type": "spc-token-01",
"url": "https://sti-ca.com/authz/asdf/0" "url": "https://sti-ca.com/authz/asdf/0"
"token": "DGyRejmCefe7v4NfDGDKfA" } "token": "DGyRejmCefe7v4NfDGDKfA" }
], ],
} }
The following is the response to the challenge sent by the ACME
client: A client responds to this challenge by providing a service provider
code token. In the SHAKEN Certificate Management framework, the
Service Provider has a secure exchange with the STI-PA to obtain a
service provider code token that can be used for authorization by the
CA when requesting a certificate. The service provider code token is
a standard JWT token [RFC7519] using a JWS defined signature string
[RFC7515].
The service provider code token JWT Protected Header MUST include the
following:
alg: Defines the algorithm used in the signature of the token.
For Service Provider Code tokens, the algorithm MUST be
"ES256".
typ: Set to standard "JWT" value.
x5u: Defines the URL of the certificate of the STI-PA validating
the Service Provider Code.
The service provide code token JWT Payload MUST include the
following:
sub: Service Provider Code value being validated in the form of a
JSON array of ASCII strings.
iat: DateTime value of the time and date the token was issued.
nbf: DateTime value of the starting time and date that the token
is valid.
exp: DateTime value of the ending time and date that the token
expires.
fingerprint: : Fingerprint of the ACME credentials the Service
Provider used to create an account with the CA. The
fingerprint is of the form:
base64url(JWK_Thumbprint(accountKey)).
The "JWK_Thumbprint" step indicates the computation specified
in [RFC7638], using the SHA-256 digest [FIPS180-4]. As noted
in JWA [RFC7518] any prepended zero octets in the JWK object
MUST be stripped before doing the computation.
To respond to a service provider code token challenge, the ACME
client constructs a service provider code authorization ("spc-authz")
using the "token" value provided in the challenge and the service
provider code token ("spcAuthzToken") that has been previously
obtained from the STI-PA. These two values are concatenated and
separated by a "." character as follows:
spcAuthorization = token || '.' || spcAuthzToken
The token for a challenge is a string comprised entirely of
characters in the URL- safe base64 alphabet. The "||" operator
indicates concatenation of strings.
An example of the use of the "spc-token-01" in a challenge response
sent by the ACME client is provided below:
POST /acme/authz/asdf/0 HTTP/1.1 POST /acme/authz/asdf/0 HTTP/1.1
Host: sti-ca.com Host: sti-ca.com
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://sti-ca.com/acme/reg/asdf", "kid": "https://sti-ca.com/acme/reg/asdf",
"nonce": "Q_s3MWoqT05TrdkM2MTDcw", "nonce": "Q_s3MWoqT05TrdkM2MTDcw",
"url": "https://sti-ca.com/acme/authz/asdf/0" "url": "https://sti-ca.com/acme/authz/asdf/0"
}), }),
"payload": base64url({ "payload": base64url({
"type": "spc-token", "spcAuthorization": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"
"keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE"
}), }),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
} }
6. IANA Considerations Upon receiving a response to the challenge, the ACME server
determines the validity of the response. The ACME server MUST verify
that the "token" in the response matches the "token" in the original
challenge. To determine if the "spcAuthzToken" is valid, the server
MUST use the URL in the JWT header in the "spcAuthzToken" to obtain
the certificate associated with the JWT payload. The server MUST
validate the signature and verify the claims. The "sub" field MUST
be a value that is included in the values for the "TN-Auth-List" in
the original challenge. The server MUST verify that the
"fingerprint" field matches the ACME credentials for the ACME client
that created the account with the CA. If the validation is
successful, the "status" in the challenge object is set to "valid".
If any step of the validation process fails, the "status" in the
challenge object MUST be set to "invalid". [Editor's Note: Likely we
should describe specific error responses for the above.]
5. IANA Considerations
This document defines a new ACME Identifier type and ACME Challenge This document defines a new ACME Identifier type and ACME Challenge
type to be registered. type to be registered.
[[ RFC EDITOR: Please replace XXXX above with the RFC number assigned [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned
to this document ]] to this document ]]
6.1. ACME TNAuthList Identifier 5.1. ACME TNAuthList Identifier
This document defines the "TNAuthList" ACME Challenge type in the This document defines the "TNAuthList" ACME Challenge type in the
ACME Identifier Type registry as follows: ACME Identifier Type registry as follows:
+-----------------------+-----------+ +-----------------------+-----------+
| Identifier Type | Reference | | Identifier Type | Reference |
+-----------------------+-----------+ +-----------------------+-----------+
| TNAuthList | RFC XXXX | | TNAuthList | RFC XXXX |
+-----------------------+-----------+ +-----------------------+-----------+
6.2. ACME Service Provider Challenge 5.2. ACME Service Provider Challenge
This document defines the "spc-token" ACME Challenge type in the ACME This document defines the "spc-token-01" ACME Challenge type in the
Challenge Types registry as follows: ACME Challenge Types registry as follows:
+-----------+--------------------+-----------+ +--------------+--------------------+-----------+
| Label | Identifier Type | Reference | | Label | Identifier Type | Reference |
+-----------+--------------------+-----------+ +--------------+--------------------+-----------+
| spc-token | TNAuthList | RFC XXXX | | spc-token-01 | TNAuthList | RFC XXXX |
+-----------+--------------------+-----------+ +--------------+--------------------+-----------+
7. Security Considerations 6. Security Considerations
This document relies on the security considerations established for This document relies on the security considerations established for
the ACME protocol per [I-D.ietf-acme-acme]. The new "TNAuthList" the ACME protocol per [I-D.ietf-acme-acme]. The new "TNAuthList"
identifier and "spc-token" validation challenges introduce a slightly identifier and "spc-token-01" validation challenges introduce a
different authorization process. Although, the challenges still have slightly different authorization process. Although, the challenges
a binding between the account private key and the validation query still have a binding between the account private key and the
made by the server, via the key authorization. validation query made by the server since the fingerprint of the
account key is contained in the service provider code token used for
authorization.
The "spc-token" is initially obtained through a secure exchange The service provider code token is initially obtained through a
between the service provider and the entity in the network that is secure exchange between the service provider and the entity in the
responsible for determining what entities can operate as VoIP service network that is responsible for determining what entities can operate
providers (the STI Policy Administrator). Further details on this as VoIP service providers (the STI Policy Administrator). Further
are provided in [SHAKEN_Certificate_Mgmt]. details on this are provided in [ATIS-1000080].
8. Informative References 7. Informative References
[ATIS-1000074] [ATIS-1000074]
ATIS/SIP Forum NNI Task Group, "Signature-based Handling ATIS/SIP Forum NNI Task Group, "Signature-based Handling
of Asserted information using toKENs (SHAKEN)", January of Asserted information using toKENs (SHAKEN)", January
2017. 2017.
[ATIS-1000080]
ATIS/SIP Forum NNI Task Group, "Signature-based Handling
of Asserted information using toKENs (SHAKEN): Governance
Model and Certificate Management", May 2017.
[FIPS180-4]
Department of Commerce, National, "NIST FIPS 180-4, Secure
Hash Standard", March 2012.
[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-06 (work in progress), March 2017. acme-acme-07 (work in progress), June 2017.
[I-D.ietf-acme-telephone]
Peterson, J. and R. Barnes, "ACME Identifiers and
Challenges for Telephone Numbers", draft-ietf-acme-
telephone-00 (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-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.peterson-acme-telephone]
Peterson, J. and R. Barnes, "ACME Identifiers and
Challenges for Telephone Numbers", draft-peterson-acme-
telephone-00 (work in progress), October 2016.
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc7340>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>. 2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<http://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <http://www.rfc-editor.org/info/rfc7519>.
[SHAKEN_Certificate_Mgmt] [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
ATIS/SIP Forum NNI Task Group, "Signature-based Handling Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
of Asserted information using toKENs (SHAKEN): Governance 2015, <http://www.rfc-editor.org/info/rfc7638>.
Model and Certificate Management", May 2017.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
MLB@Realtime Communications MLB@Realtime Communications
Email: mary.ietf.barnes@gmail.com Email: mary.ietf.barnes@gmail.com
Chris Wendt Chris Wendt
Comcast Comcast
One Comcast Center One Comcast Center
Philadelphia, PA 19103 Philadelphia, PA 19103
US US
Email: chris-ietf@chriswendt.net Email: chris-ietf@chriswendt.net
 End of changes. 30 change blocks. 
91 lines changed or deleted 163 lines changed or added

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