draft-ietf-acme-authority-token-00.txt   draft-ietf-acme-authority-token-01.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Informational M. Barnes Intended status: Informational M. Barnes
Expires: January 3, 2019 iconectiv Expires: April 25, 2019 iconectiv
D. Hancock D. Hancock
C. Wendt C. Wendt
Comcast Comcast
July 2, 2018 October 22, 2018
ACME Challenges Using an Authority Token ACME Challenges Using an Authority Token
draft-ietf-acme-authority-token-00.txt draft-ietf-acme-authority-token-01.txt
Abstract Abstract
A number of proposed challenges for the Automated Certificate A number of proposed challenges for the Automated Certificate
Management Environment (ACME) effectively rely on an external Management Environment (ACME) effectively rely on an external
authority issuing a token according to a particular policy. This authority issuing a token according to a particular policy. This
document specifies a generic Authority Token challenge for ACME which document specifies a generic Authority Token challenge for ACME which
supports subtype claims for different identifiers or namespaces that supports subtype claims for different identifiers or namespaces that
can be defined separately for specific applications of this Authority can be defined separately for specific applications of this Authority
Token challenge. Token challenge.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 https://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 3, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
3. Challenges for an Authority Token . . . . . . . . . . . . . . 3 3. Challenges for an Authority Token . . . . . . . . . . . . . . 3
3.1. Token Type Requirements . . . . . . . . . . . . . . . . . 4 3.1. Token Type Requirements . . . . . . . . . . . . . . . . . 4
3.2. Authority Token Scope . . . . . . . . . . . . . . . . . . 4 3.2. Authority Token Scope . . . . . . . . . . . . . . . . . . 4
3.3. Binding Challenges . . . . . . . . . . . . . . . . . . . 5 3.3. Binding Challenges . . . . . . . . . . . . . . . . . . . 5
4. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. 'ATC' Token Type . . . . . . . . . . . . . . . . . . . . 7 4.1. 'ATC' Token Type . . . . . . . . . . . . . . . . . . . . 7
5. Acquiring a Token . . . . . . . . . . . . . . . . . . . . . . 8 5. Acquiring a Token . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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
automates the process of generating and issuing certificates. automates the process of generating and issuing certificates.
In some cases, proving effective control over an identifier requires In some cases, proving effective control over an identifier requires
an attestation from a third party who has authority over the an attestation from a third party who has authority over the
resource, for example, an external policy administrator for a resource, for example, an external policy administrator for a
namespace other than the DNS application ACME was originally designed namespace other than the DNS application ACME was originally designed
to support. In order to automate the process of issuing certificates to support. In order to automate the process of issuing certificates
for those resources, this specification defines a generic Authority for those resources, this specification defines a generic Authority
Token challenge that ACME servers can issue in order to require Token challenge that ACME servers can issue in order to require
clients to return such a token. The challenge contains a type clients to return such a token. The challenge contains a type
indication that tells the client what sort of token it needs to indication that tells the client what sort of token it needs to
acquire. It is expected that the Authority Token challenge will be acquire. It is expected that the Authority Token challenge will be
usable for a variety of identifier types. usable for a variety of identifier types.
For example, the system of For example, the system of [I-D.ietf-acme-authority-token-tnauthlist]
[I-D.wendt-acme-authority-token-tnauthlist] provides a mechanism that provides a mechanism that allows service providers to acquire
allows service providers to acquire certificates corresponding to a certificates corresponding to a Service Provider Code (SPC) as
Service Provider Code (SPC) as defined in defined in [I-D.ietf-stir-certificates] by consulting an external
authority responsible for those codes. Furthermore, Communications
[I-D.ietf-stir-certificates] by consulting an external authority Service Providers (CSPs) can delegate authority over numbers to their
responsible for those codes. Furthermore, Communications Service
Providers (CSPs) can delegate authority over numbers to their
customers, and those CSPs who support ACME can then help customers to customers, and those CSPs who support ACME can then help customers to
acquire certificates for those numbering resources with ACME. This acquire certificates for those numbering resources with ACME. This
can permit number acquisition flows compatible with those shown in can permit number acquisition flows compatible with those shown in
[I-D.ietf-modern-problem-framework]. Another, similar example would [I-D.ietf-modern-problem-framework]. Another, similar example would
a mechanism that permits CSPs to delegate authority for particular a mechanism that permits CSPs to delegate authority for particular
telephone numbers to customers, as described in telephone numbers to customers, as described in
[I-D.ietf-acme-telephone]. [I-D.ietf-acme-telephone].
2. Terminology 2. Terminology
skipping to change at page 4, line 47 skipping to change at page 4, line 46
Because the assignment of resources can change over time, Because the assignment of resources can change over time,
demonstrations of authority must be regularly refreshed. Definitions demonstrations of authority must be regularly refreshed. Definitions
of a tkauth-type MUST specify how they manage the freshness of of a tkauth-type MUST specify how they manage the freshness of
authority assignments. Typically, a CA will expect a regular authority assignments. Typically, a CA will expect a regular
refreshing of the token. refreshing of the token.
3.2. Authority Token Scope 3.2. Authority Token Scope
An Authority Token is used to answer a challenge from an ACME server, An Authority Token is used to answer a challenge from an ACME server,
upon a request for the issuance of a certificate. An Token Authority upon a request for the issuance of a certificate. A Token Authority
could grant to a client a Token that has the exact same scope as the could grant to a client a Token that has the exact same scope as the
requested certificate; alternatively, an Authority Token could attest requested certificate; alternatively, an Authority Token could attest
all of resources that the client is eligible to receive certificates to all of the resources that the client is eligible to receive
for, which could be a superset of the scope of the requested certificates for, which could be a superset of the scope of the
certificate. requested certificate.
For example, imagine a case where an Authority for DNS names knows For example, imagine a case where an Authority for DNS names knows
that a client is eligible to receive certificates for "example.com" that a client is eligible to receive certificates for "example.com"
and "example.net". The client asks an ACME server for a certificate and "example.net". The client asks an ACME server for a certificate
for "example.com", the server directs the client to acquire an for "example.com", the server directs the client to acquire an
Authority Token from the Authority. When the client sends an Authority Token from the Authority. When the client sends an
acquisition request (see Section 5) to the Authority, the Authority acquisition request (see Section 5) to the Authority, the Authority
could issue a token scoped just to "example.com", or a token that could issue a token scoped just to "example.com", or a token that
attests the client is eligible to receive certificates for both attests the client is eligible to receive certificates for both
"example.com" or "example.net". The advantage of the latter is that "example.com" or "example.net". The advantage of the latter is that
skipping to change at page 6, line 10 skipping to change at page 6, line 10
Authority Token to a nonce specific to the challenge rather than to Authority Token to a nonce specific to the challenge rather than to
an ACME account fingerprint. Any specification of the use of the an ACME account fingerprint. Any specification of the use of the
nonce for this purpose is left to the identifier type profile for the nonce for this purpose is left to the identifier type profile for the
Authority Token. Authority Token.
4. Registration 4. Registration
This draft registers a tkauth-type of "ATC", for the Authority Token This draft registers a tkauth-type of "ATC", for the Authority Token
Challenge, a JWT usage which is further documented below. Taking the Challenge, a JWT usage which is further documented below. Taking the
identifier example of TNAuthList from identifier example of TNAuthList from
[I-D.wendt-acme-authority-token-tnauthlist], an ACME for this tkauth- [I-D.ietf-acme-authority-token-tnauthlist], an ACME for this tkauth-
type challenge might for example look as follows: type challenge might for example look as follows:
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": {
skipping to change at page 6, line 35 skipping to change at page 6, line 35
{ {
"type": "tkauth-01", "type": "tkauth-01",
"tkauth-type": "ATC", "tkauth-type": "ATC",
"token-authority": "https://authority.example.org/authz", "token-authority": "https://authority.example.org/authz",
"url": "https://boulder.example.com/authz/asdf/0" "url": "https://boulder.example.com/authz/asdf/0"
"token": "IlirfxKKXAsHtmzK29Pj8A" } "token": "IlirfxKKXAsHtmzK29Pj8A" }
], ],
} }
Entities receiving this challenge know that they can, as a proof, Entities receiving this challenge know that they can, as a proof,
acquire a ATC token from the designated Token Authority (specified in acquire an ATC token from the designated Token Authority (specified
the "token-authority" field), and that this authority can provide in the "token-authority" field), and that this authority can provide
tokens corresponding to the identifier type of "TNAuthList". tokens corresponding to the identifier type of "TNAuthList".
Once the ATC has been acquired by the ACME Client, it can be posted Once the ATC has been acquired by the ACME Client, it can be posted
back to the URL given by the ACME challenge. back to the URL given by the ACME challenge.
POST /acme/authz/asdf/0 HTTP/1.1 POST /acme/authz/asdf/0 HTTP/1.1
Host: boulder.example.com Host: boulder.example.com
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
skipping to change at page 7, line 32 skipping to change at page 7, line 32
The "ATC" field in this response contains the Authority Token. The "ATC" field in this response contains the Authority Token.
4.1. 'ATC' Token Type 4.1. 'ATC' Token Type
This specification pre-populates the tkauth-type registry with a type This specification pre-populates the tkauth-type registry with a type
for "ATC". for "ATC".
Here the "ATC" tkauth-type signifies a standard JWT token [RFC7519] Here the "ATC" tkauth-type signifies a standard JWT token [RFC7519]
using a JWS-defined signature string [RFC7515]. This may be used for using a JWS-defined signature string [RFC7515]. This may be used for
any number of different identifier types given in ACME challenges. any number of different identifier types given in ACME challenges.
The "atc" element (defined below) lists the identifier type used by
tokens based on ATC. The use of "ATC" is restricted to JWTs, if non-
JWT tokens were desired for ACME challenges, a different tkauth-type
should be defined for them.
For this ACME Authority Token usage of JWT, the payload of the JWT For this ACME Authority Token usage of JWT, the payload of the JWT
OPTIONALLY contain an "iss" indicating the Token Authority that OPTIONALLY contain an "iss" indicating the Token Authority that
generated the token, if the "x5u" element in the header does not generated the token, if the "x5u" element in the header does not
already convey that information; typically, this will be the same already convey that information; typically, this will be the same
location that appeared in the "token-authority" field of the ACME location that appeared in the "token-authority" field of the ACME
challenge. In order to satisfy the requirement for replay prevention challenge. In order to satisfy the requirement for replay prevention
the JWT MUST contain a "jti" element, and an "exp" claim. the JWT MUST contain a "jti" element, and an "exp" claim. In
addition to helping to manage replay, the "jti" provides a convenient
way to reliably track with the same "ATC" Authority Token is being
used for multiple challenges over time within its set expiry.
The JWT payload must also contain a new JWT claim, "atc", for The JWT payload must also contain a new JWT claim, "atc", for
Authority Token Challenge, which contains three elements in an array: Authority Token Challenge, which contains three elements in an array:
the identifier type, the identifier value, and the binding. The the identifier type, the identifier value, and the binding. The
identifier type and value are those given in the ACME challenge and identifier type and value are those given in the ACME challenge and
conveyed to the Token Authority by the ACME client. Again, following conveyed to the Token Authority by the ACME client. Again, following
the example of [I-D.wendt-acme-authority-token-tnauthlist], this the example of [I-D.ietf-acme-authority-token-tnauthlist], this could
could be the TNAuthList, as defined in [RFC8226], that the Token be the TNAuthList, as defined in [RFC8226], that the Token Authority
Authority is attesting. Practically speaking, that may contain a is attesting. Practically speaking, that may contain a list of
list of Service Provider Code elements, telephone number range Service Provider Code elements, telephone number range elements, and/
elements, and/or individual telephone numbers. For the purposes of or individual telephone numbers. For the purposes of the "ATC"
the "ATC" tkauth-type, the binding is assumed to be a fingerprint of tkauth-type, the binding is assumed to be a fingerprint of the ACME
the ACME credential for the account used to request the certificate, credential for the account used to request the certificate, but the
but the specification of how the binding is generated is left to the specification of how the binding is generated is left to the
identifier type profile for the Authority Token. identifier type profile for the Authority Token.
So for example: So for example:
{ "typ":"JWT", { "typ":"JWT",
"alg":"ES256", "alg":"ES256",
"x5u":"https://authority.example.org/cert"} "x5u":"https://authority.example.org/cert"}
{ {
"iss":"https://authority.example.org/authz", "iss":"https://authority.example.org/authz",
"exp":1300819380, "exp":1300819380,
skipping to change at page 8, line 47 skipping to change at page 9, line 10
the ACME Challenge type registries here. It will also create a the ACME Challenge type registries here. It will also create a
registry for "token types" as used in these challenges, following the registry for "token types" as used in these challenges, following the
requirements in Section 3.1, pre-populated with the value for "ATC" requirements in Section 3.1, pre-populated with the value for "ATC"
per Section 4.1. per Section 4.1.
8. Security Considerations 8. Security Considerations
The capture of Authority Tokens by an adversary could enable an The capture of Authority Tokens by an adversary could enable an
attacker to acquire a certificate from a CA. Therefore, all attacker to acquire a certificate from a CA. Therefore, all
Authority Tokens MUST contain a field that identifies to the CA which Authority Tokens MUST contain a field that identifies to the CA which
ACME client requested the token from the authority. All Authority ACME client requested the token from the authority; here that is the
Tokens must specify an expiry (of the token itself as proof for a CA, fingerprint specified in Section 4.1). All Authority Tokens must
as opposed to the expiry of the name), and for some application, it specify an expiry (of the token itself as proof for a CA, as opposed
may make sense of that expiry to be quite short. Authority Tokens to the expiry of the name), and for some application, it may make
must also contain a binding that will enable a CA to detect a sense of that expiry to be quite short. Any protocol used to
replayed Authority Token. Any protocol used to retrieve Authority retrieve Authority Tokens from an authority MUST use confidentiality
Tokens from an authority MUST use confidentiality to prevent to prevent eavesdroppers from acquiring an Authority Token.
eavesdroppers from acquiring an Authority Token.
More TBD. More TBD.
9. Informative References 9. Informative References
[I-D.ietf-acme-acme] [I-D.ietf-acme-acme]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", draft-ietf-acme-acme-12 (work in progress), April (ACME)", draft-ietf-acme-acme-16 (work in progress),
2018. October 2018.
[I-D.ietf-acme-authority-token-tnauthlist]
Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", draft-ietf-
acme-authority-token-tnauthlist-00 (work in progress),
July 2018.
[I-D.ietf-acme-service-provider] [I-D.ietf-acme-service-provider]
Barnes, M. and C. Wendt, "ACME Identifiers and Challenges Barnes, M. and C. Wendt, "ACME Identifiers and Challenges
for VoIP Service Providers", draft-ietf-acme-service- for VoIP Service Providers", draft-ietf-acme-service-
provider-02 (work in progress), October 2017. provider-02 (work in progress), October 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, "Support for Short-Term, Automatically-Renewed Fossati, "Support for Short-Term, Automatically-Renewed
(STAR) Certificates in Automated Certificate Management (STAR) Certificates in Automated Certificate Management
Environment (ACME)", draft-ietf-acme-star-03 (work in Environment (ACME)", draft-ietf-acme-star-04 (work in
progress), March 2018. progress), October 2018.
[I-D.ietf-acme-telephone] [I-D.ietf-acme-telephone]
Peterson, J. and R. Barnes, "ACME Identifiers and Peterson, J. and R. Barnes, "ACME Identifiers and
Challenges for Telephone Numbers", draft-ietf-acme- Challenges for Telephone Numbers", draft-ietf-acme-
telephone-01 (work in progress), October 2017. telephone-01 (work in progress), October 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-04 (work in progress), March 2018. framework-04 (work in progress), March 2018.
skipping to change at page 10, line 11 skipping to change at page 10, line 26
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.wendt-acme-authority-token-tnauthlist]
Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", draft-wendt-
acme-authority-token-tnauthlist-00 (work in progress),
March 2018.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc7340>. <https://www.rfc-editor.org/info/rfc7340>.
 End of changes. 18 change blocks. 
48 lines changed or deleted 52 lines changed or added

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