[Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-authority-token-07: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-authority-token-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Let's talk briefly about how JWT issuers are identified.  Section 4
has some text:

   For this ACME Authority Token usage of JWT, the payload of the JWT
   OPTIONALLY contain an "iss" indicating the Token Authority that
   generated the token, if the "x5u" element in the header does not
   already convey that information; typically, this will be the same
   location that appeared in the "token-authority" field of the ACME
   challenge.  [...]

While "iss" is the default way to identify a JWT issuer, the JWT BCP
(RFC 8725, BCP 225) does not make a strong recommendation that it is the
preferred way to do so, with the implication that other ways to identify
the issuer are reasonable.  However, the text here only mentions the
"x5u" element as an alternative to "iss" for identifying the issuer,
which does not seem to be a comprehensive depiction of the JWT
ecosystem.  Issuers could be identified by other X.509 related protected
headers such as "x5c", or in some situations just by the key used for
signing (when that key is accompanied by other configured metadata),
among other things.  So, I don't understand why we call out "x5u"
specifically here and apparently don't allow other ways of identifying
the issuer.

(2) We seem to describe the contents of the "atc" JWT claim as an array
in §4, but the examples show its payload as a JSON map.  Which is
correct?

(3) I'd also like to have a (hopefully brief) discussion about the
properties that we do and do not provide as relates to binding an
authority token to an ACME client.

In particular, in the REST API to the Token Authority, we have the
client provide the fingerprint of its ACME key/identity, but the Token
Authority does not do any validation on that value and is expected to
just include it directly in the issued token.  This means that some
other entity X who is not the legitimate client but knows their key
(fingerprint), and is also authorized to use a given identifier by the
Token Authority, could cause a token to be issued that references the
legitimate client's key.  (Note that X could learn the fingerprint of
the client by, e.g., being a semi-trusted CDN in front of the ACME
server as considered by RFC 8555§10.1.)  That token would then only be
useful by the legitimate client, and so there would need to be some
other vulnerability that lets X trick the client into using that token,
but it still seems that we have broken the chain of custody that would
let us claim that the authority token was generated "based on a request
from the client" (§3.3).  In particular, it seems that (with these
preconditions) we might have a scenario where a client gets issued a
certificate for numbers that it is not actually authorized for!
This weakness does not immediately lead to an obvious vulnerability, as
it requires two additional factors to be exploited -- the attacker must
themselves be authorized at the Token Authority, and there needs to be
some as-yet-unknown mechanism for the attacker to cause the client to
use this new/different token -- but I think we at a minimum need to
document the properties that we don't provide.

We could choose to make the mechanism more complicated and close off
this loophole by requiring proof of possession in the request to the
token authority.  The obvious way to do this robustly would require
another round trip, though, to let the token authority provide a nonce
that the proof of possession is provided over.  Sometimes we can use a
TLS Exporter value to save on that round-trip, but I haven't thought
through very carefully what that would look like here.  The request to
the token authority would probably need to convey the entire public key,
not just the fingerprint, so that the signature could be verified.

There's another risk relating to thumbprints that is probably worth
documenting -- we in effect are hardcoding a dependence on SHA256 for
the fingerprints.  (I'm happy to see that the wire-format of the
thumbprint does identify the hash function used, so a transition
mechansims should be pretty straightforward.)  In light of the BCP 201
guidance for building in algorithm agility, I think we should say that
we are hardcoding SHA256 and SHA256 is believed to still be quite strong
(the SHA-3 contest helped solidify that position), but if a second
preimage attack for SHA256 is found, an issued authority token could be
used with a different ACME account key.  We can also go on to say that
in that event, implementations can migrate to using a different hash
function for the fingerprints due to the in-band hash function
identification in the fingerprint field.  Such a transition would
require a new RFC to actually specify the details of the new behavior,
but would not be very invasive to implementations.

(4) We mention almost in passing that the tkauth-01 challenge type has a
new "token-authority" field that designates a location where a token can
be acquired.  I think we need to have some more explicit discussion of
the semantics of this field and how it's populated, especially in light
of how this document implies that typical usage will include
"token-authority" but the companion document implies that
"token-authority" will not be in common usage.  We definitely need some
discussion of the security considerations of having party X tell the
client to go authenticate to party Y and do some thing; this type of
flow is very prone to enabling phishing attacks where the client gives
party Y credentials that party Y is not supposed to have.  In many cases
it ends up being a de facto requirement that the client is configured
with a specific list of allowed values for "party Y" and must reject
anything not known to be trusted.  (So, in this case, that would have
the client reject any token authority URLs that are not in this
preconfigured allow-list.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's surprising to see a new JWT-using protocol that doesn't cite RFC
8725.

Section 4

   This draft specifies a tkauth-type of "atc" which contains a standard
   JWT token [RFC7519] using a JWS-defined signature string [RFC7515].
   The "atc" tkauth-type MAY be used for any number of different ACME
   identifier types in the ACME challenge.

Is there an authoritative listing anywhere of exactly which identifier
types it can be used with?

In particular, it seems like there is a need for a bit of specification
for how a given identifier type integrates with "atc" usage, and this
document perhaps only covers that integration for TNAuthList and not the
other defined ACME identifier types.  If someone wanted to perform such
an integration in the future (whether for an identifier type that
already exists or some new one), and wrote a new document, how would we
want to associate such a document with the "atc"
registration/specification?

   The JWT payload MUST also contain a new JWT claim, "atc", for
   Authority Token Challenge, which contains three mandatory elements in
   an array: the ATC identifier type ("tktype"), the identifier value
   ("tkvalue"), and the binding ("fingerprint").  The use of "tktype" is
   restricted to the values in the "ACME Identifier Types" registry as
   defined by [RFC8555].  [...]

I'm curious what went into the decision to use the name "tktype" for
this field -- the "tk" prefix seems to correspond to "token" and thus
indiate the generic authority token mechanism.  A "tktype", then, might
seem to be a type of authority token in a straightforward reading.  This
is in contrast with the stated meaning, the identifier type that the
authority token conveys.  Would, say, "tkidtype" be useful here?

                          The "tkvalue" indicates the scope of the
   authority that the token, and its semantics are outside the scope of
   this document.  [...]

Do the semantics of the "tkvalue" contents need to be specified
somewhere else?  In the document that defines the identifier type,
perhaps?  Are the semantics of the identifier types already in the IANA
registry specified somewhere?

                   The identifier type and value are those given in the
   ACME challenge and conveyed to the Token Authority by the ACME
   client.

This seems to presuppose that the ACME challenge exists prior to the
authority token issuance, but elsewhere in the document we allow for
token issuance prior to the creation of the ACME challenge.  How might
these fields be populated in that case?

   Following the example of [I-D.ietf-acme-authority-token-tnauthlist],
   the "tkvalue" identifier type could be the TNAuthList, with a
   "tkvalue" as defined in [RFC8226] that the Token Authority is
   attesting.  [...]

[This is a bit slim on what the encoded tkvalue actually is to be, but
it's probably okay to defer this to the referenced document.  I do have
an open point on that document that we should say what ASN.1 encoding is
used, though.]

   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 specification of how the binding is generated is
   left to the identifier type profile for the Authority Token.  So for
   example:

I really strongly dislike this phrasing of "is assumed to be [...] but
the specification [...] is left to the identifier type profile".  It
seems like a recipe for confusion about what the protocol actually
entails.

It seems like we could probably get away with making "atc" just always
use the account key fingerprint (regardless of identifier type), and if
a different binding is needed, that could get a new authority token
challenge type.  Alternately, we could say that the profile for the
identifier type MUST specify how the binding is computed, and offer the
fingerprint as an example method, but say nothing about "default" or
"assumed to be" -- if it's something that is unequivocally the
responsibility of the profile, then it's clear where to go to find out
what to put there.  On the gripping hand, though, other parts of this
document seem to be written on the assumption that it will always be the
fingerprint.

   Optionally, the "atc" claim may contain a fourth element, "ca".  If
   set to "true", the "ca" element indicates that the Token Authority is

Are the 'ca' contents limited to a boolean value (and should we say so
in the document)?  Or is "true" the only admitted value, with the
element omitted for other cases?  (The text in -tnauthlist that claims
to define the "atc" claim has a bit more detail on this topic.)

   granting permission to issue a certification authority certificate
   rather than an end-entity certificate for the names in question.
   This permits subordinate delegations from the issued certificate.  If

Since the ACME ecosystem already has a native delegation mechanism (RFC
9115), it might be helpful to make some statement about how this
delegation mechanism (doesn't) relate to that one.

   Specifications of "tktype" identifier types may define additional
   optional "atc" elements.

Since the "tktype" identifier types are allocated from a registry
created by RFC 8555 (that accordingly does not mention the ability to
allocate additional "atc" elements), do we want to add a note or
additional reference to the registry to publicize this functionality?
Alternately, perhaps we are really talking about the specification of
the integration of token types with "atc" usage (a "profile", as the
terminology seems to be used in the draft already), which may or may not
be in the same document that specifies the new ACME identifier type.

Section 5.1

   The body of the POST request MUST contain the Authority Token
   Challenge element that the client is requesting the Token Authority
   generate.  In the way, the client proposes the scope of the Authority
   Token it would like to receive from the Token Authority.

To clarify: by "Authority Token Challenge element", we mean the value of
the key/value pair identified by the key "atc"?  So the string '"atc":'
does not appear in the POST body?  I might consider some more prose or
an explicit example, though since this section is in some sense only
providing a template for the API exposed by the Token Authority and not
a full API specification, perhaps there is no need.  (Peeking ahead to
-tnauthlist, I see that the example there refers to "the "atc" JSON
object that should be embedded in the token" and does contain
'"atc":'...)

Section 7.3

Is there anything to say about what topics the reference for a given
allocation needs to cover?

Section 8

Up in §3 we mention the need for a trust relationship between CA and
token authority; is there anything more to say about that here
(including, perhaps, some mention of the consequences if the trust
proves to be misplaced in either direction)?

Do we want to give any more guidance on how to set the expiration time
for (TNAuthList or other) authority tokens?

We might mention that an implementation of a Token Authority REST
interface should avoid side channel leakage (e.g., for whether a given
account ID exists) in its HTTP responses/response codes.

When "x5u" is used to identify the issuer, the security considerations
for referencing remote URLs apply; RFC 3986 does a decent job of
documenting these.

Issuance of CA certificates (e.g., for STIR delegation) has additional
security considerations; we should probably reference the
stir-delegation document here and incorporate those considerations.

   is the fingerprint specified in Section 4).  All Authority Tokens
   must specify an expiry (of the token itself as proof for a CA, as
   opposed to the expiry of the name), and for some application, it may
   make sense of that expiry to be quite short.  Any protocol used to

Should/must the expiration time of the issued certificate be prior to
the expiration time of the authority token used to authorize certificate
issuance?

NITS

I think these are all useful changes, but there's no need to respond if
you disagree -- just go ahead and ignore anything you don't like.

Section 1

   on the Internet.  It enables administrative entities to prove
   effective control over resources like domain names, and automates the
   process of generating and issuing certificates that attest control or
   ownership of those resources.

I'm not sure in what sense ACME really automates "generating"
certificates in addition to automating "issuing" them.  Perhaps one
could say that it automates the process to request a certificate and
that is a new contribution, but I don't think that ACME itself adds much
to something that could be called "generating" a certificate.

   In some cases, proving effective control over an identifier requires
   an attestation from a third party who has authority over the
   resource, for example, an external policy administrator for a
   namespace other than the DNS application ACME was originally designed
   to support.  In order to automate the process of issuing certificates
   for those resources, this specification defines a generic Authority
   Token challenge that ACME servers can issue in order to require
   clients to return such a token.  [...]

Pedantically, I don't think we've defined or described the authority
token yet; the text leading up to this only covers the challenge.  So
writing "such a token" seems premature and we might rather say "return
an Authority Token that authorizes a given issuance".

Section 3

   token could be used as a response to an ACME challenge.  This
   specification, therefore, defines an Authority Token issued by an
   authority over a namespace to an ACME client for delivery to a CA in
   response to a challenge.  Authority over a hierarchical namespace can

Is it for delivery to a CA or to an ACME server?

   described in [I-D.ietf-acme-authority-token-tnauthlist]; in order to
   use "tkauth-01" Validation Method with an ACME Identifier type other
   than "TNAuthList," that identifier type would need to be registered
   separately with IANA. [...]

If this would be a new registration in the "ACME Validation Methods"
registry, I'd suggest "that identifier type would need to be listed in a
new registration in the ACME Validation Methods registry maintained by
IANA".  The current text is easy to misread as saying that the
identifier type itself would need to be registered, e.g., in the ACME
Identifier Types registry.  While that is no doubt true, it doesn't seem
to be the intent of this statement.

Section 3.1

   While Authority Token types do not need to be specific to a
   namespace, every token must carry enough information for a CA to
   determine the name that it will issue a certificate for.  Some types

Maybe s/name that it will issue a certificate for/name for which
certificate issuance is authorized/, since the CA could decide to not
issue for some other reason.

   While nothing precludes use cases where an ACME client is itself a
   Token Authority, an ACME client will typically need a protocol to
   request and retrieve an Authority Token.  The Token Authority will
   require certain information from an ACME client in order to ascertain
   that it is the right entity to request a certificate for a particular
   name.  [...]

Maybe s/the right entity/an authorized entity/, as there could in theory
be more than one?

          The protocols used to request an Authority Token MUST convey
   to the Token Authority the identifier type and value from or what
   will be used in the ACME challenge, [...]

I'm having a bit of trouble making "type and value from or what will be
used in" into a two-branch parallel statement relating to the ACME
challenge.  Possibly s/what/that/ would help things fit (or maybe I'm
just missing the right reading), but I'm not really sure.

   both "example.com" or "example.net".  The advantage of the latter is
   that if, at a later time (but one within the expiry of the JWT), the

This is the first time we mention "JWT", and we have not yet made the
connection that Authority Tokens will be JWTs.

Section 3.3

   different purpose.  To mitigate this, Authority Tokens contain a
   binding signed by a Token Authority; an ACME server can use the

This phrasing suggests that the binding is signed indepenedently of the
JWT itself, which doesn't seem to be the case; maybe something about
"the signture on the Authority Token covers a binding value" instead?

Section 4

   claim manages token freshness.  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.

"with" in "track with" doesn't seem quite right; maybe "when"?
Maybe s/expiry/lifetime/ as well, as "expiry" would typically refer to
the event or time of expiration, as opposed to the entire period of
validity.

   Following the example of [I-D.ietf-acme-authority-token-tnauthlist],
   the "tkvalue" identifier type could be the TNAuthList, with a

Do we want to s/tkvalue/tktype/ here?  The next line goes on to talk
about the actual "tkvalue" contents, so it might help readability to
refer to the named field that holds the type, here.

     "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","fingerprint":

We seem to capitalize it "TNAuthList" in the actual IANA registration
request in the companion document.

Section 5.1

   In order to request an Authority Token from a Token Authority, a
   client sends an HTTPS POST request.  This specification assumes that
   Token Authority URIs are known to clients through preexisting
   business relationships, and that credentials and related
   authentication and authorization for Authority Token acquisition
   encompassed in that relationship.  [...]

There seems to be a missing word or two here, maybe "are encompassed"
and "that the credentials and related [...]".

      POST /at/account/:id/token HTTP/1.1
      Host: authority.example.com
      Content-Type: application/json

Is ":id" intended to be a placeholder for an actual account identifier?
That might be worth mentioning in the prose and/or using a little bit
more markup around.  (draft-ietf-acme-authority-token-tnauthlist does
attempt to put some text in to that effect.)