On Fri, Feb 3, 2023 at 11:09 AM Brian Campbell <bcampbell@xxxxxxxxxxxxxxxx> 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 <joe@xxxxxxxxxxx> wrote:On Fri, Jan 27, 2023 at 3:44 PM Brian Campbell <bcampbell@xxxxxxxxxxxxxxxx> wrote:On Thu, Jan 26, 2023 at 6:40 PM Joseph Salowey <joe@xxxxxxxxxxx> wrote:On Wed, Jan 25, 2023 at 12:21 PM Brian Campbell <bcampbell@xxxxxxxxxxxxxxxx> wrote:On Sun, Jan 22, 2023 at 2:47 PM Joseph Salowey <joe@xxxxxxxxxxx> 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 <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 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 IdentityIn 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 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.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.¶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 NoncesThe 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] ThanksI 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
