[OAUTH-WG] Review of draft-ietf-oauth-jwsreq-06

[Hannes Tschofenig]

Hi Nat, Hi John,

thanks for the work on this document. I have started my review and
wanted to post a few thoughts about the abstract and the introduction.

I have some wording suggestions for the abstract. Here is the current
abstract:

"
   The authorization request in RFC6749 utilizes query parameter
   serialization.  This specification defines the authorization request
   using JWT serialization.  The request is sent by value through
   "request" parameter or by reference through "request_uri" parameter
   that points to the JWT, allowing the request to be optionally signed
   and encrypted.
"

Here is my new proposal:


"
The authorization request in OAuth 2.0 utilizes query parameter
serialization, which means that parameters are encoded in the URI of the
request. This document introduces the ability to send
request parameters in form of a JSON Web Token (JWT) instead, which
allows the request to be signed and encrypted. The request is sent by
value or by reference.

We call the 'JWT Authorization Request' extension JAR.
"

1. Introduction

I would expect the following structure of this section.

 a) A description on how things are done today. Here is a proposal:

"
The OAuth 2.0 specification [RFC 6749] defines the encoding of requests
and responses and in case of the authorization request query parameter
serialization has been chosen. For example, the parameters
'response_type', 'client_id', 'state', and 'redirect_uri' are encoded in
the URI of the request:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
"

 b) Why are we making changes / additions? What is wrong with the
current way of doing things?

Here is a proposal:
"
The encoding in the URI does not allow application layer security with
confidentiality and integrity protection to be used. While TLS is used
to offer communication security between the client and the resource
server, TLS sessions are often terminated prematurely at some middlebox
(such as a load balancer). The use of application layer security
additionally allows requests to be prepared by a third party so that a
client application cannot request more permissions than previously
agreed. This offers an additional degree of privacy protection.
"

The request by reference allows to reduce the over-the-wire overhead.

 c)  What is the solution (at a high level) described in the document?

"
   The parameters "request" and "request_uri" are introduced as
   additional authorization request parameters for the OAuth 2.0
   [RFC6749] flows.  The "request" parameter is a JSON Web Token (JWT)
   [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0
   authorization request parameters.  The JWT [RFC7519] can be passed to
   the authorization endpoint by reference, in which case the parameter
   "request_uri" is used instead of the "request".
"

You may want to explain why you have chosen the JWT format rather than
something else, such as the CBOR format.

I have a few comments regarding the benefits of the . You write:


   There are a few cases that request by reference are useful such as:

   1.  When it is detected that the User Agent does not support long
   URLs: Some extensions may extend the URL.  For example, the
   client might want to send a public key with the request.

[Hannes] I believe what you are trying to say in this section is that
the use of the reference reduces the size of the transmitted request
since the use of application layer security, and public
key cryptography in particular, substantially increases the size.

   2.  Static signature: The client can make a signed Request Object and
   put it at a place that the Authorization Server can access.  This
   may just be done by a client utility or other process, so that
   the private key does not have to reside on the client,
   simplifying programming.

[Hannes] The downside of this approach is that it is vulnerable to reply
protection and the signature only becomes a token. Another downside is
that the developer(?) has to place the JWT at
some server first.

   3.  When the server wants the requests to be cacheable: The
   request_uri may include a SHA-256 hash of the file, as defined in
   FIPS180-2 [FIPS180-2], the server knows if the file has changed
   without fetching it, so it does not have to re-fetch a same file,
   which is a win as well.

[Hannes] I believe that this is a by-product of item #2. I am not sure
what the hash of the file means here.


   4.  When the client wants to simplify the implementation without
   compromising the security.  If the request parameters go through
   the browser, they may be tampered in the browser even if TLS was
   used.  This implies we need to have signature on the request as
   well.  However, if HTTPS "request_uri" was used, it is not going
   to be tampered, thus we now do not have to sign

[OAUTH-WG] OAuth 2.0 Introspection RFC Issues

[Michael Ciarlillo]

Hello all,

I have a couple of comments/issues with the RFC at
https://tools.ietf.org/html/rfc7662.

According to Section 2.1 (Introspection Request) says that "To prevent
token scanning attacks, the endpoint MUST also require some form of
authorization to access this endpoint..." This might make sense for token
introspection requests only coming from Resource Servers, but to many
implementers it makes sense to allow Clients access to the introspection
endpoint since it would serve the same purpose (token validity checking,
particularly for refresh tokens, but also for access tokens, or identity
tokens in OpenID Connect, or possibly other token types in UMA and other
specs). Unfortunately, this means that public clients should be accounted
for in some way, as refresh tokens don't have an explicit requirement in
the OAuth 2.0 spec that they be issued only to Confidential Clients. As
such, many implementers don't feel like the Introspection spec fits well
for Client consumption because of the "MUST" requirement on authentication,
when public clients won't have a Client Secret to authenticate with.
Further, token scanning attacks would not be mitigated for authenticated
callers (be they Resource Servers or Clients).

An example of a real-world implementer discussion talking about this topic
is one I had with Kévin Chalet:
https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pull/159

We are not the only ones who see this as a problem with the spec, and there
do not seem to be many concrete reasons for this endpoint ONLY being for
Resource Servers themselves. Can some insight into why this is the case?
Can the MUST be changed to a SHOULD with the Security Considerations
section expanded to talk about the issue? If not, is there another spec or
draft out there somewhere for OAuth token validity for which the intent is
explicitly client consumption? Any and all feedback on this would be
greatly appreciated as we develop the ASOS middleware project.

Another (small) comment on the spec: Section 2.1 (Introspection Request)
currently says that requests be HTTP POST method requests, however Section
4 (Security Considerations) mentions Authorization Servers explicitly
disallowing the GET method due to server logs. What is the requirement
here? POST with optional GET or explicitly only allowing POST requests?

Sincerely,
Michael Ciarlillo
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues

[Justin Richer]

Hi Michael,

Thanks for the comments. First off, the text of an RFC is fixed and cannot be 
changed. The spec can only be altered with a new document that obsoletes 
RFC7662, which would have to go through the working group process again from 
the very beginning.

Authentication is required but we’re open to how it happens. The introspection 
spec is targeted at resource servers, not clients, since a client can always 
just *use* the token in order to see if it’s valid or not. Why bother with the 
extra round trip to check if the token is good before trying it, since trying 
it will also tell you if the token’s good? The recovery process for a failed 
token is the same in either state. We initially had this written for either 
clients or protected resources, but that’s not how people were using it and 
restricting its focus helped clarify the spec immensely.

ID tokens are a slightly different case as they’re an assertion targeted at the 
client itself, but in those cases an ID token is really meant to be 
self-contained as a JWT, and generally has a short validity period. If you’re 
looking to introspect an old ID token to check an OIDC session status, then you 
might be better served implementing one of the OIDC session spec components for 
that purpose.

Also, we didn’t mandate a specific authentication technology. Most people are 
going to use either client authentication or a specific OAuth token designed 
for this purpose. The latter of these is technically available for public 
clients, but then you have the question of if you want to check the status of 
*that* token too. Still, I think that for any clients (including public ones) 
the right thing to do is just use the token and see if it works. 

To the other comment, HTTP POST is the only defined verb and we’re silent on 
the use of other verbs. That said, many HTTP implementation frameworks don’t 
differentiate between verbs for requests and so a POST with body form 
parameters and a GET with query parameters would come out the same. We don’t 
outright prohibit this behavior, but it’s off-label and there are security 
considerations for its use.

Hope this helps,
 — Justin

> On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo  
> wrote:
> 
> Hello all,
> 
> I have a couple of comments/issues with the RFC at 
> https://tools.ietf.org/html/rfc7662 .
> 
> According to Section 2.1 (Introspection Request) says that "To prevent token 
> scanning attacks, the endpoint MUST also require some form of authorization 
> to access this endpoint..." This might make sense for token introspection 
> requests only coming from Resource Servers, but to many implementers it makes 
> sense to allow Clients access to the introspection endpoint since it would 
> serve the same purpose (token validity checking, particularly for refresh 
> tokens, but also for access tokens, or identity tokens in OpenID Connect, or 
> possibly other token types in UMA and other specs). Unfortunately, this means 
> that public clients should be accounted for in some way, as refresh tokens 
> don't have an explicit requirement in the OAuth 2.0 spec that they be issued 
> only to Confidential Clients. As such, many implementers don't feel like the 
> Introspection spec fits well for Client consumption because of the "MUST" 
> requirement on authentication, when public clients won't have a Client Secret 
> to authenticate with. Further, token scanning attacks would not be mitigated 
> for authenticated callers (be they Resource Servers or Clients).
> 
> An example of a real-world implementer discussion talking about this topic is 
> one I had with Kévin Chalet: 
> https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pull/159
>  
> 
> 
> We are not the only ones who see this as a problem with the spec, and there 
> do not seem to be many concrete reasons for this endpoint ONLY being for 
> Resource Servers themselves. Can some insight into why this is the case? Can 
> the MUST be changed to a SHOULD with the Security Considerations section 
> expanded to talk about the issue? If not, is there another spec or draft out 
> there somewhere for OAuth token validity for which the intent is explicitly 
> client consumption? Any and all feedback on this would be greatly appreciated 
> as we develop the ASOS middleware project.
> 
> Another (small) comment on the spec: Section 2.1 (Introspection Request) 
> currently says that requests be HTTP POST method requests, however Section 4 
> (Security Considerations) mentions Authorization Servers explicitly 
> disallowing the GET method due to server logs. What is the requirement here? 
> POST with optional GET or explicitly only allowing POST requests?
> 
> Sincerely,
> Michael Ciarlillo
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues

[William Denniss]

We had a debate on that MUST at the last IETF, but the spec was too far
along to change. The workaround is to treat the token you are introspecting
as the authentication. With that workaround, the spec is quite usable for
non-confidential clients, even if resource servers were the primary target.

Google currently runs an introspection endpoint of sorts for clients, named
"tokeninfo", and the latest version (v3) is close to the spec (coincidence
- it's a good design pattern). Aimed mostly at debugging use-cases or if
you don't have a JWT decoding library handy.
On Tue, Nov 3, 2015 at 1:43 AM Justin Richer  wrote:

> Hi Michael,
>
> Thanks for the comments. First off, the text of an RFC is fixed and cannot
> be changed. The spec can only be altered with a new document that obsoletes
> RFC7662, which would have to go through the working group process again
> from the very beginning.
>
> Authentication is required but we’re open to how it happens. The
> introspection spec is targeted at resource servers, not clients, since a
> client can always just *use* the token in order to see if it’s valid or
> not. Why bother with the extra round trip to check if the token is good
> before trying it, since trying it will also tell you if the token’s good?
> The recovery process for a failed token is the same in either state. We
> initially had this written for either clients or protected resources, but
> that’s not how people were using it and restricting its focus helped
> clarify the spec immensely.
>
> ID tokens are a slightly different case as they’re an assertion targeted
> at the client itself, but in those cases an ID token is really meant to be
> self-contained as a JWT, and generally has a short validity period. If
> you’re looking to introspect an old ID token to check an OIDC session
> status, then you might be better served implementing one of the OIDC
> session spec components for that purpose.
>
> Also, we didn’t mandate a specific authentication technology. Most people
> are going to use either client authentication or a specific OAuth token
> designed for this purpose. The latter of these is technically available for
> public clients, but then you have the question of if you want to check the
> status of *that* token too. Still, I think that for any clients (including
> public ones) the right thing to do is just use the token and see if it
> works.
>
> To the other comment, HTTP POST is the only defined verb and we’re silent
> on the use of other verbs. That said, many HTTP implementation frameworks
> don’t differentiate between verbs for requests and so a POST with body form
> parameters and a GET with query parameters would come out the same. We
> don’t outright prohibit this behavior, but it’s off-label and there are
> security considerations for its use.
>
> Hope this helps,
>  — Justin
>
> On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo 
> wrote:
>
> Hello all,
>
> I have a couple of comments/issues with the RFC at
> https://tools.ietf.org/html/rfc7662.
>
> According to Section 2.1 (Introspection Request) says that "To prevent
> token scanning attacks, the endpoint MUST also require some form of
> authorization to access this endpoint..." This might make sense for token
> introspection requests only coming from Resource Servers, but to many
> implementers it makes sense to allow Clients access to the introspection
> endpoint since it would serve the same purpose (token validity checking,
> particularly for refresh tokens, but also for access tokens, or identity
> tokens in OpenID Connect, or possibly other token types in UMA and other
> specs). Unfortunately, this means that public clients should be accounted
> for in some way, as refresh tokens don't have an explicit requirement in
> the OAuth 2.0 spec that they be issued only to Confidential Clients. As
> such, many implementers don't feel like the Introspection spec fits well
> for Client consumption because of the "MUST" requirement on authentication,
> when public clients won't have a Client Secret to authenticate with.
> Further, token scanning attacks would not be mitigated for authenticated
> callers (be they Resource Servers or Clients).
>
> An example of a real-world implementer discussion talking about this topic
> is one I had with Kévin Chalet:
> https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pull/159
>
> We are not the only ones who see this as a problem with the spec, and
> there do not seem to be many concrete reasons for this endpoint ONLY being
> for Resource Servers themselves. Can some insight into why this is the
> case? Can the MUST be changed to a SHOULD with the Security Considerations
> section expanded to talk about the issue? If not, is there another spec or
> draft out there somewhere for OAuth token validity for which the intent is
> explicitly client consumption? Any and all feedback on this would be
> greatly appreciated as we develop the ASOS middleware project.
>
> Another (small) comment on the

[OAUTH-WG] Announcing new Identity Events Discussion List (id-event)

[Phil Hunt]

At IETF94, a number of us got together to discuss the emerging event work that 
is emerging in the Identity space:

* OIDF RISC
* OIDC Logout
* SCIM Notify Events
* OAuth Token Revocations
* Consent Events

The Id-Event discussion list is intended to begin discussion around developing 
new IDs (and potentially form a WG) for the purpose of defining a JWT message 
format for Identity Events and to define a possible approach for distribution.

The list was formed after several participants noticed common event 
requirements that have emerged from SCIM provisioning, OIDC (eg. Logout), RISC 
Events (e.g. account suspension, reset, take-over), as well as OAuth2 (e.g. 
token revocations), and consent notification (e.g. consent from a distributes 
OAuth/UMA system).

At this time, the process and route to standardization for identity events has 
not been determined. I expect that to be one of the discussions we will have on 
the list.

The web page for the mailing list is: 

   https://www.ietf.org/mailman/listinfo/id-event 


Regards,

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

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