[OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-27.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : The OAuth 2.0 Authorization Framework: JWT Secured 
Authorization Request (JAR)
Authors : Nat Sakimura
  John Bradley
  Michael B. Jones
Filename: draft-ietf-oauth-jwsreq-27.txt
Pages   : 35
Date: 2020-08-19

Abstract:
   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents is not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be signed
   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
   (JWE) so that the integrity, source authentication and
   confidentiality property of the Authorization Request is attained.
   The request can be sent by value or by reference.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-27
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-27

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-27


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] WGLC Review of PAR

[Justin Richer]

I’ve done a full read through of the PAR specification, and here are my notes 
on it.

For additional context, I’ve implemented this specification for both a client 
and a server in a couple of languages. Overall, I think it’s in good shape and 
it makes sense from a developer’s perspective. I’ve got a few comments, some 
small and some that might need more conversation within the WG,



Throughout: Suggest using “credentialed” instead of “confidential” client, as 
introduced in OAuth 2.1 draft.

§1: Suggest the problems list start with changing scopes or swapping client IDs 
as scenarios in the first bullet, ACR is an esoteric use case for many and not 
in OAuth 2 core, either remove it or put it at the end of the bullet.

   Suggest the second bullet note who the information needs to be protected 
from, at least in passing. It’s not clear from this setup why the parameters 
should be confidential, and this is a major motivation for this work.

   Avoid use of phrase “so-called” and just give the name “Request Object”.

   ¶4: Perhaps overly pedantic but I suggest extending: “in exchange for a 
request_uri value usable at the authorization server”.. 

   ¶4/5: Alternatively, suggest combining these paragraphs: “This document 
complements JAR by providing an interoperable way for the client to push its 
authorization request parameters to the authorization server in exchange for a 
request_uri usable at the authorization server. The document further allows the 
client to push request objects as specified in JAR in exchange for a 
request_uri usable at the authorization server.”

¶12: “This is directly utilized” is a little ambiguous into what it’s 
referring to. Would suggest rewording the start as: “This early stage client 
authentication is used by this draft to allow confidential clients…” or 
something of that sort.

¶13: Not only is POST much harder to use, it’s also optional for the AS to 
implement so it can’t be counted on by a client to be available generally. (To 
be honest in retrospect we shouldn’t have included it in OAuth 2.)

§2: Please provide a reference to JWT client assertion auth here (either the 
assertion RFC or OIDC’s definition of the client auth methods mentioned). I 
would also phrase this as direct guidance instead of a note/aside.

§2.1: There’s some potential weirdness about client_id here. Since the authz 
request was designed around not having client authentication, that request 
requires client_id. However, here the client is authenticating, and the 
client_id might be included elsewhere like the Basic header. A developer might 
be curious about whether they need to include them twice.

¶2: Of necessity, this spec mixes parameters in the authorization endpoint 
and token endpoint registries into a single request. Is there any danger of 
conflict between them? The registry holds them in one list but they could 
possibly have different semantics in both places.

¶6: Does the AS really have "the ability to authenticate and authorize 
clients”? I think what we mean here is "the ability to authenticate clients and 
validate client requests”, but I’m not positive of the intent. 

¶7: I’m not sure I buy this example. Even if the clientID is managed 
externally, the association with a set or pattern of allowed redirect URIs is 
still important, and the AS will need to know what that is. I think this 
example could lead an AS developer to (erroneously and dangerously) conclude 
that they don’t have to check any other values in a request, including scope 
and redirect URI. It’s important that DynReg doesn’t alleviate that issue, but 
removal of DynReg doesn’t really change things in that regard. Suggest removing 
example or reworking paragraph.

§2.2: Is “expires_in” required? If so, can an AS decide that a request URI 
doesn’t expire after a certain amount of time? Related, what does a “0” or 
negative value mean, if anything? 

I don’t see why a request URI with unguessable values isn’t a MUST for 
one-time-use, is there a reason?

§2.3: Are the HTTP status codes a normative MAY or just an informative “can” as 
written?

§3: This bit should be normative as follows: "he authorization server MUST take 
the following steps beyond the processing rules…"

Clean up the tenses and voice of the numbered list, which are currently 
inconsistent.

§7.2: The AS should also make sure that the new redirect URI is applicable 
within that client’s domain or policies. So you wouldn’t want a legit-but-rogue 
client registering for someone else’s redirect URI in order to start an attack, 
for example. I think overall we might need better guidance around the redirect 
URI variability feature (which, to be clear, I’m hugely in favor of — but 
OAuth’s assumptions in the client model make this trickier to talk about and 
implement safely, so we need to be extra careful).

§7.3: As above, is there a reason that this isn’t a MUST? It’s a temporary 
credential representing a reque

Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft

[Brian Campbell]

Thanks for the review, Karsten. We'll incorporate your suggestions into the
next revision of the draft.

On Wed, Aug 19, 2020 at 3:41 AM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de> wrote:

> Hi all,
>
> I have two very small suggestions which I also raised as issues on Github:
>
>1. There are no hints in front of example requests/responses if extra
>line breaks are used for display purposes. I think hints such as "(with
>extra line breaks for display purposes only)" should be added to the
>examples. (#64
>)
>2. In section 3 there is a typo in step 2. I think it should be "*Validate
>*the request object signature as specified in JAR
>[I-D.ietf-oauth-jwsreq], section 6.2." instead of "*Validates *the
>...". The imperative is used in step 1, as well. (#65
>)
>
> Best regards;
> Karsten
> On 12.08.2020 00:07, Rifaat Shekh-Yusef wrote:
>
> All,
>
> This is a WGLC on the *Pushed Authorization Requests *document:
> https://www.ietf.org/id/draft-ietf-oauth-par-03.html
>
> Please, take a look and provide feedback on the list by *August 25th.*
>
> Regards,
>  Rifaat & Hannes
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:+49 (0)234 / 54456499
> Web:  https://hackmanit.de | IT Security Consulting, Penetration Testing, 
> Security Training
>
> Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID 
> Connect am 24.09 + 
> 25.09:https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020
>
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
> Christian Mainka, Dr. Marcus Niemietz
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth v.2.1 Readthrough

[Justin Richer]

As promised on the WG call, I’ve gone through the 2.1 document and I’ve made 
some notes and suggestions on my way through. A big thanks to the editors for 
putting this together, and particularly for Aaron who did the early heavy 
lifting on getting a reasonable start on this important work!

But first, a note: I realize that many portions of this are simply copied from 
6749 or related specifications, and I do not fault the editors for that. Even 
so, there are some places where the old language should be updated in this 
draft, since we have an opportunity to fix things and make them more readable 
on our way through. There are also a number of places that are redundant with 
each other as they clearly come from different source documents. A major goal 
of this work is to coalesce these differences into a single and easily 
understandable framework.



§Abstract

I think we should update “interaction between the RO and the HTTP Service” to 
be “the RO and an authorization service” or something like that instead, since 
“the HTTP service” referenced elsewhere in this paragraph is more precisely the 
RS and not the AS, yet the interaction and approval happens at the AS. OAuth 
2.0 allowed the AS and RS to be separate, and 2.1 should go further to admit 
that in a lot of cases today, they are separate. 

There’s been debate on the “replaces and obsoletes” language already, and I 
think there’s a lot of IETF process that we’ll need to sort out to get that 
language right.


§1: We should add a note on password use to this list:

 - Often the resource owner’s password is used with other unrelated services, 
and the additional exposure of sharing the password among components in one 
domain lowers the possible security in other domains where the password is 
shared.


  ¶3/4 can probably be collapsed to read better, and some of the language 
cleaned up. Recommend:

OAuth addresses these issues by introducing an authorization layer and 
separating the role of the client from that of the resource owner. In OAuth, 
the client requests access to resources controlled by the resource owner and 
hosted by the resource server. Instead of using the resource owner's 
credentials to access protected resources, the client obtains an access token - 
a credential representing a specific set of access attributes such as scope and 
lifetime. Access tokens are issued to clients by an authorization server with 
the approval of the resource owner. The client uses the access token to access 
the protected resources hosted by the resource server.

  ¶6: (and throughout document) avoid use of gendered pronouns in favor of 
singular “they” unless needed for clearer reading (such as an Alice and Bob 
scenario)

§1.2: This diagram could use an update to not show the client talking directly 
to the RO in the first step, especially because the ROPC grant has been removed 
here. The way it’s written now makes it look like the user gives something to 
the client which it then trades for a token directly, which doesn’t happen 
quite like that anywhere.

§1.3: Having taught many OAuth 2 classes to hundreds of people over the years, 
I can say with confidence that this definition of “grant” as a credential has 
historically been problematic and confusing to most people. And in particular, 
it doesn’t even really apply to the client credentials flow listed here: there 
is not a separate "credential representing authorization", just the client’s 
own authentication. Suggest new text to more accurately reflect what a “grant” 
is in the OAuth reality:

An authorization grant is a process by which a client obtains authorization 
from a resource owner to obtain an access token to act on that resource owner’s 
behalf. This specification defines...

Changing this would require a consensus call 

§1.3.X: I don’t see why we shouldn’t list the Device Flow here in this spec. 
It’s mentioned as an extension later, but we might as well list it here as a 
known and accepted grant type. 

§1.4: This section should mention introspection explicitly. Recommend rewriting 
the intro to ¶3:

The token make be used by the RS to retrieve the authorization information, or 
the token may self-contain the authorization information in a verifiable manner 
(i.e., a token string consisting of a signed data payload). One example of a 
token retrieval mechanism is Token Introspection [RFC7662], in which the RS 
calls an endpoint on the AS to validate the token presented by the client. One 
example of a structured token …

We may also want to mention CWT (RFC8392) here in passing. 

§1.5: “The string is usually opaque” should be “the string is opaque"

§1.6: this should probably refer to the TLS BCP195 here instead of the RFC and 
version.

§1.8: This should have explicit links to introspection (RFC7662), registration 
(RFC7591, RFC7592), and discovery (RFC8414) inline as they’re given as 
examples, instead of putting them all in the appendix. Perhaps also bring up 
JWTs f

Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

[Joseph Heenan]

I agree with Brian here, I think “typ”:”JWT” should be permitted as well as no 
typ and “typ”: "oauth.authz.req+jwt".

There are other tests we could write for JAR that an OIDC server will fail (for 
example, one that tested the behaviour of passing a value only outside the 
request object - which an OIDC server would process, but one compliant with JAR 
[or FAPI-RW] would ignore the value outside). I don’t see having one more case 
of this as an issue - some servers will not be JAR compliant, and hence would 
fail tests that test JAR-specific behaviour.

I also agree with Brian about requiring AS to reject request objects that have 
a sub that’s a client_id, this doesn’t seem to cause significant 
interoperability concerns as it is hopefully unlikely that any client is doing 
so. I could possibly see an argument for weakening the requirement for an AS to 
reject a request object with sub=client_id to a ’should’ (rather than a must) 
given there is a small chance it could end up breaking an ecosystem, but I’m 
not entirely convinced.

Joseph


> On 17 Aug 2020, at 23:55, Brian Campbell 
>  wrote:
> 
> I might suggest that thinking about it in the context of interoperability 
> would be more meaningful than certification tests. 
> 
> Saying that an AS MUST reject the Request object if it has a typ header and 
> the value of the header is not ‘oauth.authz.req+jwt’ [1] should allow for 
> interoperability with respect to JWT typing between all combinations of 
> existing and updated clients with existing and updated authorization servers. 
> 
> Saying that an AS MUST NOT include a sub with client id as the value would 
> break for an updated authorization server when receiving such a request 
> object JWT. But that's erroneous and potentially dangerous behaviour from the 
> client so I don't know that we need to try and maintain interoperability 
> there. 
> 
> [1] Unfortunately "typ":"JWT" would probably also need to be allowed. As best 
> I understand it "typ":"JWT" basically says "this JWT is a JWT", which isn't 
> useful for explicit typing and I think makes it effectively equivalent to an 
> untyped JWT. I've honestly never understood why one would use "typ":"JWT" but 
> it shows up in a lot of places including examples and explanations on sites 
> like jwt.io  so it seems very likely that it'd just get 
> copied over and show up in some amount of real world request object JWTs. 
> 
> 
> On Sat, Aug 15, 2020 at 10:41 AM Mike Jones 
>  > wrote:
> Answering Filip and Vladirmir’s question about adding normative language 
> around “typ” and “sub”:  Anytime you add a new required feature, you are 
> breaking existing deployments.  Suppose we added the normative requirement 
> “If a ‘typ’ header parameter is present, ASs MUST reject the Request object 
> if its value is not ‘oauth.authz.req+jwt’”.  One could then write a 
> certification test sending the AS a different “typ” value – which to pass, 
> ASs would have to reject the JWT.  Every existing deployment would fail this 
> test!  That’s exactly what we don’t want to have happen.
> 
>  
> 
> Brian asked for security considerations.  The IESG asked for security 
> considerations.  I added them in the PR – working with Nat and John.  They 
> point the way to the future without breaking existing deployments.  That’s as 
> it should be.
> 
>  
> 
>-- Mike
> 
>  
> 
> From: OAuth mailto:oauth-boun...@ietf.org>> On 
> Behalf Of Warren Parad
> Sent: Saturday, August 15, 2020 9:27 AM
> To: Vladimir Dzhuvinov  >
> Cc: oauth mailto:oauth@ietf.org>>
> Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No Objection on 
> draft-ietf-oauth-jwsreq-26: (with COMMENT)
> 
>  
> 
> In the case of
> 
> if the Request Object includes a sub claim with the value of the client_id 
> the AS MUST reject the request
> 
>  
> 
> What would the expectation be in terms of a client_credentials grant?
> 
>  
> 
> From experience, the sub is frequently populated with the client_id value and 
> the client_id is not used. Which would mean breaking for that type of grant 
> wouldn't it?
> 
>  
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. Implement 
> Authress .
> 
>  
> 
>  
> 
> On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov  > wrote:
> 
> +1 to make the "typ" check, as Filip suggested, normative, as existing client 
> and RP deployments with undefined "typ" will not be affected. New deployments 
> should be encouraged to type the JWT, and thus be made safer.
> 
>  
> 
> Regarding the "sub != client_id" check -- could a simple rejection of all 
> JWTs with "sub" present suffice?
> 
> I find it difficult to imagine what else a client could end up setting the 
> "sub" claim to, if it does end up populating it for some reason.
> 
>

Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft

[Karsten Meyer zu Selhausen]

Hi all,

I have two very small suggestions which I also raised as issues on Github:

 1. There are no hints in front of example requests/responses if extra
line breaks are used for display purposes. I think hints such as
"(with extra line breaks for display purposes only)" should be added
to the examples. (#64
)
 2. In section 3 there is a typo in step 2. I think it should be
"*Validate *the request object signature as specified in JAR
[I-D.ietf-oauth-jwsreq], section 6.2." instead of "*Validates *the
...". The imperative is used in step 1, as well. (#65
)

Best regards;
Karsten

On 12.08.2020 00:07, Rifaat Shekh-Yusef wrote:
> All,
>
> This is a WGLC on the *Pushed Authorization Requests *document:
> https://www.ietf.org/id/draft-ietf-oauth-par-03.html
>
> Please, take a look and provide feedback on the list by *August 25th.*
>
> Regards,
>  Rifaat & Hannes
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:  +49 (0)234 / 54456499
Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, 
Security Training

Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect 
am 24.09 + 25.09:
https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
Christian Mainka, Dr. Marcus Niemietz

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth