Thanks, Watson. We've published
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-31 with these changes.
-- Mike
-----Original Message-----
From: Watson Ladd <watsonbl...@gmail.com>
Sent: Wednesday, March 17, 2021 6:21 PM
To: Mike Jones <michael.jo...@microsoft.com>
Cc: nat <nat@nat.consulting>; r...@cert.org; sec...@ietf.org; 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
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
> Mike> portions of the draft (and those it depends upon) are not
> Mike> followed, insecure usage can result. That's true of any
> Mike> security draft. If there are additional specific requirements
> Mike> and/or recommendations needed, we'd be glad to add them. If so,
> Mike> please identify them. (Indeed, we're already doing so in
> Mike> 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
