Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

[Deepak Tiwari <[e-mail]>]

please unsubscribe my email id from your records.

On Thu, Mar 18, 2021 at 11:29 PM Mike Jones <Michael.Jones=
[e-mail]> wrote:

> Thanks, Watson.  We've published
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-31 with these changes.
>
>                                 -- Mike
>
> -----Original Message-----
> From: Watson Ladd <[e-mail]>
> Sent: Wednesday, March 17, 2021 6:21 PM
> To: Mike Jones <[e-mail]>
> Cc: nat <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Secdir last call review of draft-ietf-oauth-jwsreq-30
>
> On Wed, Mar 17, 2021 at 2:47 PM Mike Jones <[e-mail]>
> 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' <[e-mail]>; Nat Sakimura
> > <[e-mail]>; Roman Danyliw <[e-mail]>
> > Cc: secdir <[e-mail]>; IETF oauth WG <[e-mail]>;
> > [e-mail]; [e-mail]
> > 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 <[e-mail]>
> > Sent: Tuesday, December 15, 2020 9:01 PM
> > To: Nat Sakimura <[e-mail]>
> > Cc: secdir <[e-mail]>; IETF oauth WG <[e-mail]>;
> > [e-mail]; [e-mail]
> > Subject: [EXTERNAL] Re: Secdir last call review of
> > draft-ietf-oauth-jwsreq-30
> >
> >
> >
> > On Sat, Oct 31, 2020 at 6:13 AM Nat Sakimura <[e-mail]> 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
> >
> > > <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 

Regards,

*Deepak Tiwari|* Software Engineer
Intigate Technologies Pvt. Ltd. | www.intigate.co.in
Ist Floor, A-119
Sector-63
Noida (U.P.) 201301