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)
On Sat, Jan 21, 2023 at 6:45 AM Brian Campbell <bcampbell@xxxxxxxxxxxxxxxx> wrote:
Hi Joseph,On Fri, Jan 20, 2023 at 6:10 PM Joseph Salowey <joe@xxxxxxxxxxx> 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_jwtWhen 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 materearly 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.
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. 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? Can the DPoP key be the same as the key used for private_key_jwt? How is DPoP bound to the client authentication?
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.
2. Confirmation MethodsIs 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 methodIf 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.
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 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
