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

[Brian Campbell <[e-mail]>]

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.



>
>>
>> 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) .



>
>
>>
>>
>>>
>>>
>>>> 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).




>
>
>>
>>
>>>
>>> 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.



>
>
>>
>>
>>>
>>>
>>>>
>>>>>
>>>>> 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._