Re: [Last-Call] Last Call: <draft-ietf-oauth-dpop-12.txt> (OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)) to Proposed Standard

[Joseph Salowey <[e-mail]>]

On Fri, Feb 3, 2023 at 11:09 AM Brian Campbell <[e-mail]>
wrote:

> I'm going to make the subsection header a little more specific with
> "Binding to Client Identity" but otherwise the suggested text is good.
> Thank you!
>
>
[Joe] Thanks.  That sounds better.


> On Thu, Feb 2, 2023 at 9:08 PM Joseph Salowey <[e-mail]> wrote:
>
>>
>>
>> On Fri, Jan 27, 2023 at 3:44 PM Brian Campbell <
>> [e-mail]> wrote:
>>
>>>
>>>
>>> On Thu, Jan 26, 2023 at 6:40 PM Joseph Salowey <[e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jan 25, 2023 at 12:21 PM Brian Campbell <
>>>> [e-mail]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Jan 22, 2023 at 2:47 PM Joseph Salowey <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Hi Brian,
>>>>>>
>>>>>> Thanks for the quick reply. Responses inline:  (I'm also copying
>>>>>> secdir, while this is not a secdir review it might be of interest)
>>>>>>
>>>>>
>>>>> Thanks for noting the addition. Slower reply this time from me.
>>>>> Apologies for that. Among other reasons, I'm having a hard time
>>>>> articulating my thoughts/replies. But I am trying to give meaningful
>>>>> responses.
>>>>>
>>>>>
>>>> [Joe] No problem, thanks for your patience, I realize my main questions
>>>> are somewhat outside the core use case here.  I have a better understanding
>>>> of DPoP now.  Additional responses inline below.
>>>>
>>>
>>> Likewise, thanks for your patience. And also likewise, some continued
>>> responses inline below.
>>>
>>>
>> [Joe] Sorry for the delay.  I included some text to discuss the binding
>> to authentication below.
>>
>>
>>>
>>>
>>>>
>>>>>
>>>>> On Sat, Jan 21, 2023 at 6:45 AM Brian Campbell <
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>> Hi Joseph,
>>>>>>
>>>>>> On Fri, Jan 20, 2023 at 6:10 PM Joseph Salowey <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> These are last call comments for draft-ietf-oauth-dpop-12.
>>>>>>>
>>>>>>> First, I want to thank the authors and participants for working on
>>>>>>> this document, its good to see it and I think it will be very useful.
>>>>>>>
>>>>>>
>>>>>> Thanks! Glad to hear that. I hope it will be useful as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I had a few questions/comments.
>>>>>>>
>>>>>>> 1. Interaction with private_key_jwt
>>>>>>>
>>>>>>> When I first  started to look at the document I got a little
>>>>>>> depressed because it brought up the private_key_jwt authentication
>>>>>>> mechanism which always makes me a bit sad because while it is an
>>>>>>> authentication mechanism of sorts, it's a poor proof-of-possession
>>>>>>> mechanism. It's really a self-signed bearer token that's prone to many of
>>>>>>> the problems described in the objectives section. This seems to be widely
>>>>>>> used as an authentication mechanism especially in cases where an automated
>>>>>>> client talks to a service using a pre-configured public key.  The document
>>>>>>> declares authentication out of scope, but I didn't let myself get too
>>>>>>> despondent, because it seems that DPoP could be used to improve the
>>>>>>> private_key_jwt client authentication mechanism with a better POP.  But
>>>>>>> from the document, I'm not quite sure how as the document focuses more on
>>>>>>> public clients instead of confidential clients (I think that is the right
>>>>>>> terminology).
>>>>>>>
>>>>>>> If I'm reading the document correctly, I think the client could
>>>>>>> include a DPoP Proof JWT header in the token request using the same key
>>>>>>> contained the private_key_jwt. The token service could then evaluate both
>>>>>>> the private_key_jwt JWT and the DPoP proof JWT before issuing an access
>>>>>>> token and refresh tokens to supplement the authentication provided by the
>>>>>>> private_key_jwt with a better PoP.  Is this correct?
>>>>>>>
>>>>>>> If so the document should mention this use case as I think it would
>>>>>>> improve the some common practice.  (I can submit some text if I'm on the
>>>>>>> right track).   If not is there another DPoP mechanism that should be used
>>>>>>> to supplement the private_key_jwt with better PoP?
>>>>>>>
>>>>>>
>>>>>> The DPoP proof JWT and the private_key_jwt JWT ultimately use pretty
>>>>>> similar mechanisms so it's not obvious that DPoP is materially better.
>>>>>> Supplementing the private_key_jwt somehow with DPoP could be done but I
>>>>>> don't believe it'd add much value.
>>>>>>
>>>>>>
>>>>> [Joe] The difference I'm focused on is that DPoP defines the use of
>>>>>> nonce, whereas, to my knowledge, there is no standard way to use a nonce
>>>>>> with private_key_jwt.  The addition of the nonce changes the security
>>>>>> properties a bit.
>>>>>>
>>>>>
>>>>> Yes, the nonce is an optional mechanism defined in DPoP and you are
>>>>> correct that there's no standard way to use a nonce with private_key_jwt.
>>>>> That is FWIW why I tried to use language like "pretty similar" there rather
>>>>> than saying they were the same. More generally though, supplementing client
>>>>> authentication wasn't a goal the WG had with this document. An
>>>>> authorization server could check that the same key was used for
>>>>> private_key_jwt and dpop, which I think is what you are looking for. But
>>>>> that would be specific to the particular implementation/deployment (and
>>>>> need to be documented somehow for interop). There were a nontrivial number
>>>>> of WG participants that thought it was important to allow the keys to be
>>>>> different so the DPoP keys could be more transient or ephemeral-like.
>>>>>
>>>>> [Joe]  I agree that it's good to support ephemeral keys.  I think to
>>>> really address this it would take some cryptographic binding between the
>>>> authentication and the DPoP.  For example, have the auth mechanism sign the
>>>> DPoP message (bind the key and nonce to the authentication then move
>>>> forward with the key).  I can see how this is out of scope of the document,
>>>> but I think it probably should be mentioned in the security
>>>> considerations.  I'll propose some text.
>>>>
>>>
>>> Thank you. Proposed text is very helpful (of course) .
>>>
>>>
>> [Joe] Here is a stab at a security considerations sub-section
>>
>> ## Binding to Identity
>>
>> In cases where DPoP is used with client authentication, it is only bound
>> to authentication by being coincident in the same TLS tunnel.  Since the
>> DPoP proof is not directly cryptographically bound to the authentication,
>> it's possible that the authentication or the DPoP messages were copied into
>> the tunnel.  While including the URI in the DPoP can partially mitigate
>> some of this risk, modifying the authentication mechanism to provide
>> cryptographic binding between authentication  and DPoP could provide better
>> protection.  However, providing additional binding with authentication
>> through the modification of authentication mechanisms or other means is
>> beyond the scope of this specification.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> Using DPoP with/for client authentication to the AS was proposed at
>>>>>>> one point during an interim meeting a while back (
>>>>>>> https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf
>>>>>>> slide 19) but it was more about trying to simplify some redundancy. There
>>>>>>> wasn't sufficient interest in pursuing it at the time anyway.
>>>>>>>
>>>>>>> [Joe] OK, good to know.
>>>>>>
>>>>>>
>>>>>>> OAuth client authentication is not a defined thing for calls to
>>>>>>> resource servers (aka protected resources). As I struggle to find words to
>>>>>>> reply here and reread your question/comment, it seems like maybe that
>>>>>>> (client using something like private_key_jwt making protected resource API
>>>>>>> calls) is the case you are referring to. That's "off-label" use of
>>>>>>> private_key_jwt, which I certainly don't endorse but isn't a defined thing
>>>>>>> and thus not in scope for DPoP to say anything about. Something like the
>>>>>>> client credentials grant with private_key_jwt and DPoP binding the access
>>>>>>> token might be a better and standard supported way of accomplishing the
>>>>>>> automated client to service w/ pre-configured public key case. FWIW.
>>>>>>>
>>>>>>> [Joe] Yea it seems there is a bit of confusion about the use of
>>>>>> private_key_jwt out there (some of it is probably mine).  Here is an
>>>>>> example of what coencerns me -
>>>>>> https://developers.google.com/identity/protocols/oauth2/service-account#httprest
>>>>>> Do you know if its intended usage and perhaps avoiding misusage are defined
>>>>>> anywhere.
>>>>>>
>>>>>
>>>>> There's a lot there but it looks like both use of the bearer JWT grant
>>>>> type (which is similar to private_key_jwt in some respects but more for an
>>>>> automated client talking to a service on-behalf-of a user) and the
>>>>> "Addendum: Service account authorization without OAuth" appears similar to
>>>>> the "off-label" usage described previously.
>>>>>
>>>>>
>>>>>
>>>>>> I think most of this issue is with private_key_jwt and not this
>>>>>> document, although I am a bit confused by some of the DPoP document:
>>>>>>
>>>>>> In section 3, the document says it is "compatible with
>>>>>> private_key_jwt and all other client authentication methods." What does
>>>>>> that compatibility mean?
>>>>>>
>>>>>
>>>>> That might not be the best word choice but it's intended to mean that
>>>>> DPoP can be used alongside any client authentication method and doesn't
>>>>> interact or interfere with client auth. They operate independently of one
>>>>> another.
>>>>>
>>>>>
>>>> [Joe] I think that helps.  I  think the doc should mention that it is
>>>> not directly bound in the security considerations.  They auth and DPoP
>>>> presented within the same secure tunnel so there is some binding, but there
>>>> is still the possibility that one or both of them originated somewhere else
>>>> and was copied into the tunnel.
>>>>
>>>>
>>>>>
>>>>>
>>>>>> Can the DPoP key be the same as the key used for private_key_jwt?
>>>>>>
>>>>>
>>>>> It certainly can be the same key. But it isn't required to be the
>>>>> same.
>>>>>
>>>>>
>>>>>
>>>>>> How is DPoP bound to the client authentication?
>>>>>>
>>>>>
>>>>> It's not.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> At the end of section 5 it has a paragraph that suggests that DPoP
>>>>>> might not be beneficial for redeeming refresh tokens in the case that
>>>>>> client authentication is used.  It seems this might require additional
>>>>>> discussion.  For example, if DPoP uses the same public key as in the
>>>>>> private_key_jwt then binding to the public is already part of the
>>>>>> authentication and it seems that DPoP could strengthen the validation for
>>>>>> redeeming refresh tokens.
>>>>>>
>>>>>
>>>>> That paragraph is trying to say that refresh tokens issued to clients
>>>>> with authentication credentials are not also bound to a DPoP key. Such
>>>>> refresh tokens are bound to the client and its respective authentication.
>>>>> The same public key used in private_key_jwt and DPoP is possible here. But
>>>>> similar to what I tried to articulate in a reply above, that check would be
>>>>> deployment specific and a bit beyond what DPoP specifies.
>>>>>
>>>>>
>>>> [Joe]  I'm still trying to wrap my head around this one.  My main
>>>> problem is around the security of the authentication mechanisms.  It's not
>>>> a DPoP, but DPoP could make things better, however what is really needed is
>>>> to improve the auth mechanisms.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 2.  Confirmation Methods
>>>>>>>>
>>>>>>>> Is the goal of section 6 to define mandatory to implement
>>>>>>>> conformation methods?
>>>>>>>>
>>>>>>>
>>>>>>> The goal is to provide an interoperable way to convey the binding of
>>>>>>> the access token to the DPoP key for both token introspection and JWT
>>>>>>> formated access tokens. That's done with the jkt conformation method
>>>>>>>
>>>>>>>
>>>>>>>> If it is, it should say so.  I think the paragraph might be a
>>>>>>>> little clearer if it used the term key confirmation method in section 6.
>>>>>>>> For example, "Other key confirmation methods, such as those defined in
>>>>>>>> [RFC7800] and [RFC8705] may be used per agreement between the authorization
>>>>>>>> server and the protected resource, but are not detailed in this
>>>>>>>> specification.
>>>>>>>>
>>>>>>>
>>>>>>> The confirmation method in RFC8705 is a hash of a certificate so
>>>>>>> isn't applicable/appropriate in the context of DPoP that's using bare JWK
>>>>>>> formatted keys.
>>>>>>>
>>>>>>>
>>>>>> [Joe] This wasn't clear to me in the document and I don't necessarily
>>>>>> see why it could not be used.  I think you can include a certificate
>>>>>> reference in the DPoP proof header in the JWK field such as x5t#S256.
>>>>>> Perhaps your primary use case is when the client generates a new specific
>>>>>> DPoP key for the current transaction, but it doesn't seem to eliminate
>>>>>> using a pre-configured key pair which leads to some ambiguity.
>>>>>>
>>>>>
>>>>> It's not meant to eliminate the possibility of using pre-configured
>>>>> keys but bare JWK keys would still be used or referenced in this context.
>>>>> Certificates just aren't part of DPoP.
>>>>>
>>>>> [Joe]  My main question is that would this statement:
>>>> "Other methods of associating a public key with an access token are
>>>> possible, per agreement by the authorization server and the protected
>>>> resource, but are beyond the scope of this specification.¶
>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-13#section-6-1>
>>>>
>>>> Does "methods of associating a public key with an access token" mean
>>>> "confirmation method"?  and with agreement could a any cnf mechanisms be
>>>> used including x5t#S256?
>>>>
>>>
>>> Yes it could be cnf.x5t#S256 but there would be a lot of other "beyond
>>> the scope of this specification" stuff needed for it to be workable. Enough
>>> extra that I think a mention of it would cause more confusion than be
>>> helpful.
>>>
>>> That statement in the spec is really meaning to say that a dpop public
>>> key can be associated with an access token in any way that works for, and
>>> is mutually agreed upon, by the AS and RS. It could be a different cnf in a
>>> JWT or the JSON of an introspection response. It could be a column in an
>>> access token table of a shared database. It could be a
>>> field/parameter/member of an integrity protected bit of CBOR or protobuf or
>>> whatever. Etc.
>>>
>>> I get the sense we've been talking past each other on this one though.
>>> I'm not sure how to rectify that but thinking it's better to say it out
>>> loud than just continue the back-and-forth (despite doing just that in the
>>> prior two paragraphs).
>>>
>>>
>>>
>> [Joe]  Thanks, I think I have a better understanding now and this
>> discussion has helped.  I don't think there needs to be any modification of
>> this section.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 3.  Unpredictable Nonces
>>>>>>
>>>>>> The draft does list that unpredictable nonces have advantages in
>>>>>> section 11.2.  I believe it should also mention this as a mitigation in
>>>>>> section 11.4.  I think the document should go further and make
>>>>>> unpredictable nonces a MUST or at least RECOMMENDED.
>>>>>>
>>>>>>
>>>>> I think that text in section 11.2 is intended to be descriptive in
>>>>> saying these nonces are unpredictable and then describing a security
>>>>> benefit of their use. It's not supposed to suggest or allow for some nonces
>>>>> to be predictable. Honestly, I think there was/is just an implicit
>>>>> assumption/requirement that nonces be unpredictable. But we can add an
>>>>> explicit statement somewhere, if you think it's needed?
>>>>>
>>>>>
>>>> [Joe] I think it should have an explicit statement.  THere is some test
>>>> that could lead an implementer to use a timestamp as a nonce (section 4.3,
>>>> section 11.1).
>>>>
>>>
>>> That's a fair point. To try and explain, there's definitely the
>>> assumption that the nonce conveys a time value back to the server. But not
>>> just a raw timestamp. The assumption was also that it'd be protected
>>> somehow with HMAC, AEAD or something.  Anyway, yes, having an explicit
>>> statement would be worthwhile.
>>>
>>>
>>>
>>>>   I think you could add to the description of DPoP-Nonce header is
>>>> sections 8.9.
>>>>
>>>> "In order to ensure that the nonce is unpredictable it should have at
>>>> least xx bits of entropy."  I think 96 is probably a good number for the
>>>> bits of entropy.
>>>>
>>>
>>>  I'll add something to section 8 that's explicit about the nonce needing
>>> to be unpredictable.
>>>
>>>
>>>
>> [Joe] Thanks
>>
>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I may have a few additional editorial comments as I go through the
>>>>>>>> draft that I will pass along.
>>>>>>>>
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>>>> privileged material for the sole use of the intended recipient(s). Any
>>>>>>> review, use, distribution or disclosure by others is strictly prohibited.
>>>>>>> If you have received this communication in error, please notify the sender
>>>>>>> immediately by e-mail and delete the message and any file attachments from
>>>>>>> your computer. Thank you.*
>>>>>>
>>>>>>
>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>> privileged material for the sole use of the intended recipient(s). Any
>>>>> review, use, distribution or disclosure by others is strictly prohibited.
>>>>> If you have received this communication in error, please notify the sender
>>>>> immediately by e-mail and delete the message and any file attachments from
>>>>> your computer. Thank you.*
>>>>
>>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>>
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*