draft-ietf-acme-authority-token-02.txt   draft-ietf-acme-authority-token-03.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: September 12, 2019 iconectiv Expires: September 25, 2019 iconectiv
D. Hancock D. Hancock
C. Wendt C. Wendt
Comcast Comcast
March 11, 2019 March 24, 2019
ACME Challenges Using an Authority Token ACME Challenges Using an Authority Token
draft-ietf-acme-authority-token-02.txt draft-ietf-acme-authority-token-03.txt
Abstract Abstract
Some proposed extensions to the Automated Certificate Management Some proposed extensions to the Automated Certificate Management
Environment (ACME) rely on proving eligibility for certificates Environment (ACME) rely on proving eligibility for certificates
through consulting an external authority that issues a token through consulting an external authority that issues a token
according to a particular policy. This document specifies a generic according to a particular policy. This document specifies a generic
Authority Token challenge for ACME which supports subtype claims for Authority Token challenge for ACME which supports subtype claims for
different identifiers or namespaces that can be defined separately different identifiers or namespaces that can be defined separately
for specific applications. for specific applications.
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 September 12, 2019. This Internet-Draft will expire on September 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 6, line 7 skipping to change at page 6, line 7
narrow scope may periodically be issued. narrow scope may periodically be issued.
For some identifier types, it may be more appropriate to bind the For some identifier types, it may be more appropriate to bind the
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. ATC tkauth-type Registration 4. ATC tkauth-type 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. Here the "ATC" tkauth-type signifies a standard JWT token Challenge. Here the "atc" tkauth-type signifies a standard JWT token
[RFC7519] using a JWS-defined signature string [RFC7515]. This may [RFC7519] using a JWS-defined signature string [RFC7515]. This may
be used for any number of different identifier types given in ACME be used for any number of different identifier types given in ACME
challenges. The "atc" element (defined below) lists the identifier challenges. The "atc" element (defined below) lists the identifier
type used by tokens based on ATC. The use of "ATC" is restricted to 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 JWTs, if non-JWT tokens were desired for ACME challenges, a different
tkauth-type should be defined for them. 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. In the JWT MUST contain a "jti" element, and an "exp" claim. In
addition to helping to manage replay, the "jti" provides a convenient addition to helping to manage replay, the "jti" provides a convenient
way to reliably track with the same "ATC" Authority Token is being way to reliably track with the same "atc" Authority Token is being
used for multiple challenges over time within its set expiry. 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 mandatory elements in Authority Token Challenge, which contains three mandatory elements in
an array: the identifier type, the identifier value, and the binding. an array: the identifier type ("tktype"), the identifier value
The identifier type and value are those given in the ACME challenge ("tkvalue"), and the binding ("fingerprint"). The identifier type
and conveyed to the Token Authority by the ACME client. Following and value are those given in the ACME challenge and conveyed to the
the example of [I-D.ietf-acme-authority-token-tnauthlist], this could Token Authority by the ACME client. Following the example of
be the TNAuthList, as defined in [RFC8226], that the Token Authority [I-D.ietf-acme-authority-token-tnauthlist], the "tkvalue" identifier
is attesting. Practically speaking, that scope may comprise a list type could be the TNAuthList, with a "tkvalue" as defined in
of Service Provider Code elements, telephone number range elements, [RFC8226] that the Token Authority is attesting. Practically
and/or individual telephone numbers. For the purposes of the "ATC" speaking, that scope may comprise a list of Service Provider Code
tkauth-type, the binding is assumed to be a fingerprint of the ACME elements, telephone number range elements, and/or individual
telephone numbers. For the purposes of the "atc" tkauth-type, the
binding "fingerprint" is assumed to be a fingerprint of the ACME
credential for the account used to request the certificate, but the credential for the account used to request the certificate, 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,
"jti":"id6098364921", "jti":"id6098364921",
"atc":{"TnAuthList","F83n2a...avn27DN3==", "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","fingerprint":
"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: "SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50:
9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} } 9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} }
Optionally, the "atc" element may contain a fourth element, "ca". If Optionally, the "atc" element may contain a fourth element, "ca". If
present, the "ca" element indicates that the Token Authority is set to "true", the "ca" element indicates that the Token Authority is
granting permission to issue a certification authority certificate granting permission to issue a certification authority certificate
rather than an end-entity certificate for the names in question. rather than an end-entity certificate for the names in question.
This permits subordinate delegations from the issued certificate. This permits subordinate delegations from the issued certificate.
The "atc" object in the example above would then look like: The "atc" object in the example above would then look like:
"atc":{"TnAuthList","ca","""F83n2a...avn27DN3==", "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","ca":true,
"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50:
9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} } 9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} }
Specifications of "tktype" identifier type may define additional
optional "atc" elements.
5. Acquiring a Token 5. Acquiring a Token
The acquisition of a Authority Token requires a network interface, The acquisition of a Authority Token requires a network interface,
apart from potential use cases where the entity that acts as an ACME apart from potential use cases where the entity that acts as an ACME
client itself also acts as a Token Authority trusted by the ACME client itself also acts as a Token Authority trusted by the ACME
server. Implementations compliant with this specification MUST server. Implementations compliant with this specification MUST
support an HTTPS REST interface for Authority Token acquisition as support an HTTPS REST interface for Authority Token acquisition as
described below, though other interfaces MAY be supported as well. described below, though other interfaces MAY be supported as well.
skipping to change at page 7, line 48 skipping to change at page 7, line 51
In order to request an Authority Token from a Token Authority, a In order to request an Authority Token from a Token Authority, a
client sends an HTTPS POST request. Different services may organize client sends an HTTPS POST request. Different services may organize
their web resources in domain-specific ways, but the resource locator their web resources in domain-specific ways, but the resource locator
should specify the account of the client, an identifier for the should specify the account of the client, an identifier for the
service provider, and finally a locator for the token. service provider, and finally a locator for the token.
POST /at/account/:id/token HTTP/1.1 POST /at/account/:id/token HTTP/1.1
Host: authority.example.com Host: authority.example.com
Content-Type: application/json Content-Type: application/json
The body of the POST request will minimally contain a JSON The body of the POST request will contain the ATC element that the
fingerprint object for the ACME client, for example: client is requesting the Token Authority generate.
{
"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3 \
:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"
}
It is understood if this minimal JSON object is provided that the {
client is requesting the Token Authority to issue a token that "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","ca":false,
attests the entire scope of authority to which the client is "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50:
entitled. The client may also request an AT with some subset of its 9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} }
own authority via an optional "scope" element in this JSON object. }
The way that "scope" is defined will necessarily be specific to the
identifier type. For the TNAuthlist identifier type, for example, an
object requesting an AT with authority for only a single telephone
number might look like:
{ In common use cases, the "tkvalue" in this request is asking that the
"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3 \ Token Authority issue a token that attests the entire scope of
:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3", authority to which the client is entitled. The client may also
"scope":"12125551000" request an AT with some subset of its own authority via the "tkvalue"
} element in the ATC object. The way that "tkvalue" is defined will
necessarily be specific to the identifier type. For the TNAuthlist
identifier type, for example, an object requesting an AT could
request authority for only a single telephone number in a way that is
defined in the TNAuthList specification.
Finally, the JSON object may also contain a optional element "ca" Finally, the JSON object may also contain a optional boolean element
which signifies that the client is requesting that the Token "ca" which signifies that the client is requesting that the Token
Authority issue an AT with the "ca" flag set, as described in Authority issue an AT with the "ca" flag set, as described in
Section 4. Section 4.
After an HTTPS-level challenge to verify the identity of the client After an HTTPS-level challenge to verify the identity of the client
and subsequently making an authorization decision, in the success and subsequently making an authorization decision, in the success
case the Token Authority returns a 200 OK with a body of type case the Token Authority returns a 200 OK with a body of type
"application/json" containing the Authority Token. "application/json" containing the Authority Token.
6. Using an Authority Token in a Challenge 6. Using an Authority Token in a Challenge
skipping to change at page 9, line 19 skipping to change at page 9, line 19
{ {
"status": "pending", "status": "pending",
"identifier": { "identifier": {
"type": "TNAuthList", "type": "TNAuthList",
"value": "F83n2a...avn27DN3==" "value": "F83n2a...avn27DN3=="
}, },
"challenges": [ "challenges": [
{ {
"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 an ATC token from the designated Token Authority (specified acquire an ATC token from the designated Token Authority (specified
in 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".
skipping to change at page 9, line 46 skipping to change at page 9, line 46
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://boulder.example.com/acme/reg/asdf", "kid": "https://boulder.example.com/acme/reg/asdf",
"nonce": "Q_s3MWoqT05TrdkM2MTDcw", "nonce": "Q_s3MWoqT05TrdkM2MTDcw",
"url": "https://boulder.example.com/acme/authz/asdf/0" "url": "https://boulder.example.com/acme/authz/asdf/0"
}), }),
"payload": base64url({ "payload": base64url({
"ATC": "evaGxfADs...62jcerQ" "atc": "evaGxfADs...62jcerQ"
}), }),
"signature": "5wUrDI3eAaV4wl2Rfj3aC0Pp--XB3t4YYuNgacv_D3U" "signature": "5wUrDI3eAaV4wl2Rfj3aC0Pp--XB3t4YYuNgacv_D3U"
} }
The "ATC" field in this response contains the Authority Token. The "atc" field in this response contains the Authority Token.
7. Acknowledgements 7. Acknowledgements
We would like to thank you for your contributions to this problem We would like to thank you for your contributions to this problem
statement and framework. statement and framework.
8. IANA Considerations 8. IANA Considerations
This document requests that the IANA registers a new ACME identifier This document requests that the IANA registers a new ACME identifier
type (per [I-D.ietf-acme-acme]) for the label "atc", for which the type (per [I-D.ietf-acme-acme]) for the label "atc", for which the
reference is [RFCThis]. reference is [RFCThis].
This document further requests that the IANA create a registry for This document further requests that the IANA create a registry for
"token types" as used in these challenges, following the requirements "token types" as used in these challenges, following the requirements
in Section 3.1, pre-populated with the label of "ATC" per Section 4 in Section 3.1, pre-populated with the label of "atc" per Section 4
with a value of [RFCThis]. with a value of [RFCThis].
9. Security Considerations 9. Security Considerations
Per the guidance in [I-D.ietf-acme-acme], ACME transactions MUST use Per the guidance in [I-D.ietf-acme-acme], ACME transactions MUST use
TLS, and similarly the HTTPS REST transactions used to request and TLS, and similarly the HTTPS REST transactions used to request and
acquire authority tokens MUST use TLS. These measures are intended acquire authority tokens MUST use TLS. These measures are intended
to prevent the capture of Authority Tokens by eavesdroppers. to prevent the capture of Authority Tokens by eavesdroppers.
The capture of Authority Tokens by an adversary could enable an The capture of Authority Tokens by an adversary could enable an
skipping to change at page 10, line 50 skipping to change at page 10, line 50
[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-18 (work in progress), (ACME)", draft-ietf-acme-acme-18 (work in progress),
December 2018. December 2018.
[I-D.ietf-acme-authority-token-tnauthlist] [I-D.ietf-acme-authority-token-tnauthlist]
Wendt, C., Hancock, D., Barnes, M., and J. Peterson, Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", draft-ietf- "TNAuthList profile of ACME Authority Token", draft-ietf-
acme-authority-token-tnauthlist-01 (work in progress), acme-authority-token-tnauthlist-02 (work in progress),
October 2018. March 2019.
[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
 End of changes. 21 change blocks. 
58 lines changed or deleted 58 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/