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

["Peterson, Jon" <[e-mail]>]

Hi Ben (and the IESG),

We're finally getting to implementing fixes based on IESG review for the acme-authority-token and the related -tnauthlist draft. As a number of ADs supported Ben's discuss and comments, you can find responses to Ben inline below.

On 11/27/21, 5:41 PM, "Benjamin Kaduk via Datatracker" <[e-mail]> wrote:

    Benjamin Kaduk has entered the following ballot position for
    draft-ietf-acme-authority-token-07: Discuss
    
    
    ----------------------------------------------------------------------
    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.

I have added "x5c" to the text there, though I'm not sure why this spec would need to give a comprehensive description of the JWT ecosystem.
    
    (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?

We mean map. Eliminated the place where this was carelessly called an array.
    
    (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.

I think the existing text in 3.3 already addresses this, including the potential use of the nonce, by deferring it to the identifier type profile (see the last paragraph there). I've added some text related to this, but I don't think it requires any change to the behavior described in the document. More:

    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,

That does not seem like a trivial hurdle to me. Short of compromising the target client's ACME account, or their system, what would that vulnerability be?

    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!

That's a big "might." Again, if you can compromise a target's ACME account or something, you already have the power to get the same result. 

Bear in mind as well that Token Authorities will have their own relationships (5.1) with the entities to whom they disperse Authority Tokens, so they aren't just giving these out anonymously or something.

    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.

Sure, as a theoretical matter - it's (hopefully) now better documented at the end of 3.3.
    
    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.

Given the state of implementation, I think it would be okay to say that if a change of algorithm is required, we'll update the specification. I added that to the Sec Cons.
    
    (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.)
    
There is (again, in 5.1) text about the assumed business relationship between a client of this API and the Token Authority. It was not meant to be implied in this document that "token-authority" will be the common usage. Added a "when present" to one of the two places that "token authority" is mentioned.
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    It's surprising to see a new JWT-using protocol that doesn't cite RFC
    8725.
    
Added.

    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?

Broadly, I don't think we saw a need for a registry listing which ACME identifier types (which are already in an IANA registry) happen to be supported by "atc." I think the requirements in 3.1 for tkauth-types make clear the kinds of things that need to be specified for an "atc" usage - as the first paragraph says, "subtypes inherit these requirements", and effectively every ACME identifier type ("tktype") is a subtype of "atc."
    
       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?

I'm sure the thinking behind its naming was minimal, and while I mean "idtype" would perhaps nod more to the ACME Identifier types, I don't think we should try to shift it now.
    
                              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?

Well, in the document that specifies the identifier type. I added a sentence for that. 
    
                       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?

I think the only case where token issuance precedes the challenge are cases where a token with a long expiry is reused over multiple ACME challenges. But I don't think the sentence here expresses (or even implies) order or precedence, just equality of values.
    
       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.]

Again, it is supposed to be slim here, as its really up to the specification for the ACME identifier type to define what goes in "tkvalue".
    
       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.

This binding is the subject of the preceding section (3.3); this text is just loosely paraphrasing.  I'll insert a "see 3.3" at the end of this sentence.
    
    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.

I think we can do a normative RECOMMENDED in 3.3 for using the ACME account fingerprint, and then caveat that by saying the nonce or what have you could be specified by ACME identifier specification for use with "atc". I've plugged that in.
    
       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.)


I've added "boolean" to the sentence about the "ca" element. And as an aside (based on the attempted division anyway) -tnauthlist defines how to populate the "atc" claim of the Authority Token for its use case, whereas -authority-token defines the "atc" claim of the ACME challenge.
    
       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.

Basically, RFC9115 delegation manages the EE certificate that the delegate uses for signing; the reference to delegation here is instead about acquiring an intermediate cert which can in turn issue EE certs (which are potentially managed by RFC9115 or what have you). So related, but only loosely. I added a little text.
    
       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.

This passage is talking about the fact that a given "tktype" (e.g. TnAuthList) can define new claims that appear in the "atc" element. I'm not sure what we'd need to add to the registry itself to publicize what - it is indeed something that would be in the same document that specifies the "atc" usage for a given ACME identifier type. ACME identifier types without an "atc" usage specification would have no need for something in the registry.
    
    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? 

No, I would think "element" entails both key and value - that's clarified now.

    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":'...)

Yeah, it's easier to defer to the other spec for the full example.
    
    Section 7.3
    
    Is there anything to say about what topics the reference for a given
    allocation needs to cover?

There is a reference there to section 3.1, which is where those requirements are supposed to be captured.
    
    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)?

Okay, I added a bit there.
    
    Do we want to give any more guidance on how to set the expiration time
    for (TNAuthList or other) authority tokens?

I think it will end up being pretty specific to the ACME identifier type.
    
    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.

I mean, I don't think there's anything specific to this interface about that general weakness.
    
    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.
    
This seems like something we inherit from the RFC8725 guidance (say, 3.10) ?

    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.

Anything that closely tied to STTIR would belong in -tnauthlist rather than here, I think.
    
       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?

I think that's a reasonable SHOULD, added. 
    
    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.

Most of these nits I implemented.
    
    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.)