On Wed, Mar 17, 2021 at 2:47 PM Mike Jones <michael.jo...@microsoft.com> wrote: > > I’ve created the pull request > https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/14/ applying the > proposed changes below to the draft. Unless suggestions for changes are > received, we’ll merge this and publish -31 to address Watson’s comments.
I think these changes as addres my concerns. I wish that we could further restrict to a known-good, easily implementable profile, but we can't get everything we want. Sincerely, Watson Ladd > > > > -- Mike > > > > From: Mike Jones > Sent: Friday, February 26, 2021 12:55 PM > To: 'Watson Ladd' <watsonbl...@gmail.com>; Nat Sakimura <nat@nat.consulting>; > Roman Danyliw <r...@cert.org> > Cc: secdir <sec...@ietf.org>; IETF oauth WG <oauth@ietf.org>; > last-c...@ietf.org; draft-ietf-oauth-jwsreq....@ietf.org > Subject: Re: Secdir last call review of draft-ietf-oauth-jwsreq-30 > > > > Thanks again for your review, Watson. My replies to your comments below are > prefixed by "Mike>". > > > > -----Original Message----- > From: Watson Ladd <watsonbl...@gmail.com> > Sent: Tuesday, December 15, 2020 9:01 PM > To: Nat Sakimura <nat@nat.consulting> > Cc: secdir <sec...@ietf.org>; IETF oauth WG <oauth@ietf.org>; > last-c...@ietf.org; draft-ietf-oauth-jwsreq....@ietf.org > Subject: [EXTERNAL] Re: Secdir last call review of draft-ietf-oauth-jwsreq-30 > > > > On Sat, Oct 31, 2020 at 6:13 AM Nat Sakimura <nat@nat.consulting> wrote: > > > > > > Hi Watson, > > > > > > Thanks very much for the review. I thought I have sent my response > > > earlier, which I actually did not. It was sitting in my draft box. I > > > apologize for it. > > > > My apologies for missing it in my inbox for a number of months. > > > > > > My responses inline: > > > > > > On Sat, Sep 26, 2020 at 9:46 AM Watson Ladd via Datatracker > > > <nore...@ietf.org> wrote: > > > > > > > > Reviewer: Watson Ladd > > > > Review result: Serious Issues > > > > > > > > I generated this review of this document as part of the security > > > > directorate's ongoing effort to review all IETF documents being > > > > processed by the IESG. These comments were written with the intent > > > > of improving security requirements and considerations in IETF > > > > drafts. Comments not addressed in last call may be included in AD > > > > reviews during the IESG review. Document editors and WG chairs should > > > treat these comments just like any other last call comments. > > > > > > > > Two minor issues: On page 4, "This offers an additional degree of > > > > privacy protection." should be reworded. I don't think it makes > > > > sense in context, where authenticity was discussed. > > > > > > > > > In the course of the edit, explanation about two distinct privacy > > > benefits was collated in one sentence and has become very difficult to > > > parse. > > > > > > What it is trying to express as privacy benefits are the following. > > > > > > 1) The authorization request content is sent to the AS in the > > > backchannel so it will not be exposed through the browser to the eyes > > > of an active or passive outsider observing what is going on in the > > > browser. In the RFC6749 framework case, the authorization request > > > goes through the browser redirect and it could leak to the adversary > > > via WPAD/PAC Attack, referrer, browser history, etc. Also, if the > > > browser was infected by an adversary controlled malware, the content > > > can be sniffed by the adversary. In the case of JAR, it does not > > > happen. This is one privacy benefit it is trying to explain. > > > > > > 2) The location that the authorization request is getting pushed to > > > does not have to be the AS. A trusted third party that examines the > > > content for the conformance to the collection minimization principle > > > may act as the party that accepts the authorization request and issues > > > the request_uri. AS can then just evaluate the domain part of > > > request_uri to evaluate that the authorization request is conformant > > > to this principle. This is another privacy benefit from the point of > > > view of the individual user. > > > > I'm fine with any fix to the sentence that makes sense. Don't think we need > to insert the above but I very much appreciate the explanation. > > > > Mike> Given that its meaning is fairly inscrutable, and that the two benefits > described by Nat above are partially related to paragraphs other than the one > with the privacy statement, I propose that we simply delete the sentence > "This offers an additional degree of privacy protection." from this paragraph. > > > > > > It took me a while to understand what the by reference method is: > > > > maybe the intro should say via URL instead of by reference. > > > > > > > > > request_uri can be URL or a handle such as URN. That is why the "by > > > reference" word is being used, per the suggestion of the WG. > > > > I'm fine with that, just noting my confusion. > > > > Mike> Understood. I looked at ways to possibly move the "by reference" text > that follows in a few paragraphs earlier to possibly make this clearer, but > it would mess up the logical flow of the Introduction. Unless you have a > better suggestion, I propose that we leave this as-is. > > > > > > 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." > > > > <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." > > > > > > Looking at the cited reference for attacks, I see the fix is to > > > > include information about which IPD was used by the RP. But the > > > > draft before us doesn't mandate that. It's not clear than how the > > > > cited attack is prevented by the draft. Saying that the > > > > communication through the user-agent is subject to > > > > > > The mention of mix-up attack was introduced after the Last call by one > > > of the comment. It just added it in the sentence with a reference. I > > > am ok to remove it. > > > > That works for me. > > > > Mike> I will remove the mix-up attack reference in the next draft. > > > > > Having said that, the heart of mix-up attack is that the combination > > > of the client believes that it is communicating with the > > > attacker-controlled AS (AAS) while it in-fact is talking to Honest AS > > > (HAS), AND HAS unable to find out that the client is thinking that it > > > is talking to AAS not him. > > > > > > OAuth JAR seems to mitigate it in two ways: > > > > > > a) Use request_uri which is hosted by the AS. Then, if the client is > > > thinking that it is talking to the AAS, then it will push it to AAS > > > and when the user is redirected to HAS, HAS will find out that the > > > request_uri is not created by herself and return an error, making the > > > mix-up attack fail. > > > > > > b) Include `aud` in the request. Then, when the HAS will find that the > > > request was minted to AAS and not her. So, it will result in an error, > > > making the mix-up attack fail. > > > > If the draft mandates doing this it addresses the attack and the sentence can > stay. > > > > Mike> The draft mandates use of "aud" but it does not mandate that the > request_uri be hosted by the AS. Therefore, I think we should remove the > mix-up attack reference. > > > > > So, I added mix-up attack to the sentence thinking the commenter's > > > request to add it is fine, but I am fine with removing it. > > > > > > > manipulation, and this prevents it, ignores that the attacker in > > > > that position sees a lot more. The user-agent as resource owner > > > > modifying the requested resources is a very funny sort of attack: > > > > can't they do what they want with the resources since they control the > > > access? > > > > > > If the client is in the browser, yes. > > > But in the mainstream case, the client is not in the browser but the > > > web-server that the browser is communicating with and the resource > > > access happens without being mediated by the browser. > > > > My concern on this point is resolved. > > > > Mike> Thanks > > > > > > 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. > > > > > > > > > > > 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." > > > > > > Then we have section 11. What section 11 introduces is an entire new > > > > dramatis personae, the Trust Framework Provider, with no prior > > > > discussion of what it is or a reference to where it is defined and a > > > > good number of statements about how it works that aren't really clear > > > what they mean from the document to me. > > > > > > Trust Framework Provider first appears in 5.2.1. > > > At the time of writing the related text, it was a pretty well-known > > > concept. In the United State, it was part of its National Strategy > > > (NSTIC) and internationally, it was even taken up at WEF Davos > > > meeting. It is quite surprising that such a mainstream concept faded > > > into obscurity so quickly. The reason for introducing it was to a) > > > justify request_uri as some WG members wanted it to be removed, b) > > > justify that requst_uri to be served from a different domain. Now that > > > people appreciate it, e.g., it can be seen from PAR, the justification > > > for a) probably is no longer required. A full explanation for b) would > > > probably be a much longer text but I doubt if it belongs to this > > > document. I am fine with removing the reference to Trust framework > > > etc. as long as the capability to push the authorization request to a > > > place other than the client or the authorization server is not > > > removed. > > > > Let's remove the text then, but keep the capability. > > > > Mike> I propose to remove uses of the term "Trust Framework Provider" and > instead replace them by the more generic term "trusted third-party service". > > > > > > 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.) > > > > 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. > > > > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
