On Fri, Feb 26, 2021 at 12:54 PM Mike Jones <Michael.Jones@xxxxxxxxxxxxx> wrote: > > Thanks again for your review, Watson. My replies to your comments below are prefixed by "Mike>". Thank you for the work on the draft. I've removed places where we agree in the interest of readability, so the result may be more contentious than it ought to be. > > > > > > And now for the thorny issues with this draft. Signatures and > > > > encryption are different. And encrypting a signed blob doesn't mean the signer encrypted it. > > > > Then there are a plethora of methods specified in the draft to > > > > authenticate the blob, which will give different results in > > > > maliciously constructed examples. The security considerations > > > > section should discuss what the encrypted vs signed choices give in > > > > the way of security, and it doesn't. This makes me worry. > > > > > > We don’t expect the encryption to ensure authenticity, that’s what the > > > signatures are used for. > > > > This needs to be very clearly spelled out in the text. Lots of people will not understand this. The wording of section 10.2 is at best ambivalent, with multiple alternatives presented as acceptable. > > > > Mike> After the sentence at 10.2 (b) about symmetric encryption, I propose that we add the following sentence to emphasize the point you're raising: "Note however, that if public key encryption is used, no source authentication is enabled by the encryption, as any party can encrypt content to the public key." 10.2(b) relies on assumptions about key handling that I don't think are necessarily true. 10.2(a) is more foolproof. Can everyone just use that? > > > > <chop> > > > > > > I didn't quite get what is meant by "plethora of methods specified in > > > the draft to authenticate the blob ... " > > > There is a bit of text about authenticating the source (=client) but > > > not much on the blob itself. > > > The discussion around the signature and/or encryption is covered in > > > RFC7519 (JWT), the format that the request object assumes. > > > This is required reading when implementing this spec, so WG thought it > > > is not worth repeating here. > > > Attacks etc. on the signature and encryption are covered in RFC7515 > > > and RFC7516 respectively. > > > > Well, the draft happens to include the following text: > > "The Authorization Server MUST validate the signature of the JSON Web > > Signature [RFC7515] signed Request Object. The signature MUST be > > validated using the key for that "client_id" and the algorithm > > specified in the "alg" Header Parameter." > > > > Shouldn't the key be associated with a single algorithm? How do we ensure that the common attack of telling the server to use hmac to verify the signature doesn't work here? > > > > Mike> Good point. This attack is described in Section 2.1 of RFC 8725 and mitigated by the practices in Sections 3.1 and 3.2 of the same. I propose that we replace the sentence: > > "The signature MUST be validated using the key for that "client_id" and the algorithm specified in the "alg" Header Parameter." > > with: > > "The signature MUST be validated using a key associated with the client and the algorithm specified in the "alg" Header Parameter. If a "kid" Header Parameter is present, the key identified MUST be the key used, and MUST be a key associated with the client. Algorithm verification MUST be performed, as specified in Sections 3.1 and 3.2 of RFC 8725." So I think 3.2 of RFC 8725 imposes requirements on the storage of keys and association with algorithms that have implications for the whole system. Leaving that to a reference is going to be surprising. > > > > > Key management is ignored. This is a very important issue, > > > > especially > > > > > > A lot of ground is covered by RFC 7515, 7516, 7517, 7518, 7519, 7591, > > > and 8414 so this document is not specifically restating them. The problem with pointing to very generic drafts that don't use ths > > > > > > > > > > > considering the potential problems with the reuse of JWT. I'd like > > > > to see a > > > > > > Are you talking about the reuse of the request object by an adversary > > > trying to act as an honest client? > > > Even if it happens, the malicious client does not have the proper > > > client credential so it cannot redeem the code it obtained with the > > > token. It is no different than RFC6749 code grant. Protocols that > > > extend it, such as OpenID Connect, have introduced nonce to prevent > > > the reuse and used JAR (it is called request object there) to further > > > protect tampering and achieve client authentication even in the front > > > channel. > > > > > > > recommendation that keys be separated by intended uses, rather than > > > > limiting particular fields in an ad-hoc manner. > > > > > > Could you kindly elaborate on the "ad-hoc manner" part so that I can > > > understand it more fully? > > > > 10.8, Cross-JWT Confusion discusses avoiding signing certain fields, rather than suggesting good key usage as a solution. > > > > Mike> I propose to add this new paragraph at the end of Section 10.8 to implement your suggestion: > > "Finally, another way to prevent cross-JWT confusion is to use a key management regime in which keys used to sign Request Objects are identifiably distinct from those used for other purposes. Then, if an adversary attempts to repurpose the Request Object in another context, a key mismatch will occur, thwarting the attack." This should be the only way to do it. It's far safer than assuming symmetric key hygiene (in particular, are you sure your own encryptions can't come back). > > > > > > My biggest concern is that these issues are signs that the problem > > > > this draft is trying to solve and the mechanisms to solve it haven't > > > > been analyzed as thoroughly as they should have been. Without that > > > > sort of thorough analysis it's not certain that the mechanisms > > > > actually solve the problem and it's not clear what the > > > > recommendations to implementers have to be to preserve those properties. > > > > > > OAuth JAR, as the name "The OAuth 2.0 Authorization Framework: JWT > > > Secured Authorization Request (JAR)" suggests, is a framework and not > > > a house itself. One such example is FAPI [1] which was formally > > > verified [2]. > > > > "It's possible to use this draft security" I don't think should be enough anymore. Rather it should be impossible to use insecurely. > > > > Mike> The draft describes how to use the mechanism securely. Yes, if portions of the draft (and those it depends upon) are not followed, insecure usage can result. That's true of any security draft. If there are additional specific requirements and/or recommendations needed, we'd be glad to add them. If so, please identify them. (Indeed, we're already doing so in response to your existing specific feedback.) Are all possible choices implementors have when complying with this draft going to end up with secure results? That should mean that there aren't additional requirements or recommendations needed. What sorts of analysis informed this draft? The goal should be that any conforming implementation not be subject to any attack, no matter the combination of options selected. Pointing to a particular secure subset of the draft doesn't help justify the elements not in that subset. > > > > Mike> As for past JWT problems, the JWT BCP [RFC 8725] was written at the request of the IESG to identify and mitigate them - especially in light of JWTs being used for additional use cases, such as STIR secured telephony and securing first-responder services. If you believe that additional generic JWT issues should be discussed and addressed, we could always revise this BCP. But doing so is beyond the scope of this RFC. > > > > > [1] > > > https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md > > > [2] https://arxiv.org/abs/1901.11520 > > > > > > > > > > > Obviously this draft has had a long and tortured history with > > > > multiple reviews, and what I'm suggesting needs to happen is a lot > > > > of work. But it's essential in any security protocol to do this > > > > analysis and be clear about what is, and what is not, protected by the protocol. > > > > > > OAuth JAR is nothing but just another binding to OAuth 2.0. Where > > > RFC6749 binds it to form encoding, it provides two additional bindings: > > > 1) binding to JWT, and > > > 2) binding to the pushed authorization request that is referenced by a URI. > > > It is this simple. As such, it would also inherit some of the > > > shortcomings in RFC6749. However, it is not this document to address > > > them. It should be done by other documents so that the result can be > > > encoded using the mechanisms provided in this document. > > > > This is not a simple matter. JWT has a long and twisted history with some pervasive errors in common libraries, and is a fairly large standard. OAuth 2.0 is also large. Ensuring that the mapping has the right properties is going to be a mess. If the encoding does not respect the semantics we have a serious security issue. If implementors assume the encoding provides properties it does not, we again have a security issue. > > > > Mike> See my previous comments on past JWT implementation errors and the writing of the JWT BCP [RFC 8725] to address these. JWT provides certain properties. OAUTH 2.0 assumes certain properties. Are the properties required by OAUTH 2.0 those provided by this draft's use of JWT? That's independent of generic problems of JWT but very specific. By way of analogy if you use HMAC as a signature scheme you're going to have a bad time, even though HMAC is secure, because its properties are not those of a signature scheme. That's true no matter how much you insist your HMAC implementation is correct. > > > > > It is quite surprising that this fact is not getting appreciated and > > > is taking such a long time to complete. > > > Maybe I should delete all the explanation text and leave it with just > > > the core text. Explanation and justification text for defining > > > additional bindings probably are just distractions now as it is now > > > appreciated and used all over the world unlike when the project was > > > started. > > > > Mike> I would propose that we make only necessary changes to the draft at this point. Let's finish this long-overdue specification! > > > > > > > > > > > > > Sincerely, > > > > Watson Ladd > > > > > > > > > > Thanks again for your detailed comments. > > > > > > Best wishes, > > > > > > -- > > > Nat Sakimura > > > NAT.Consulting LLC > > > > Mike> I now plan to create edits incorporating the proposed resolutions above for review. > > > > Best wishes, > > -- Mike > > > > -- > > Astra mortemque praestare gradatim -- Astra mortemque praestare gradatim -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
