Subject: [OAUTH-WG] status of bearer token redelegation drafts

From: Bas Zoetekouw <[email-masked]>
Date: Mon, 03 Nov 2014 12:02:47 +0100

Hi All,

For a client of ours, I am looking into OAuth token redelegation from
one RS to another.  I've found two drafts that more or less describe the
scenario they want to implement:
https://tools.ietf.org/html/draft-richer-oauth-chain-00 and
http://tools.ietf.org/html/draft-hunt-oauth-chain-01
Could anyone comment on the status of those? 
In particular I'ld be interested in hearing whether anyone is using
either of those specs in practice, and whether there is any progress on
the drafts.

Best regards,
Bas Zoetekouw.
SURFnet.

-- 
Bas Zoetekouw
SURFnet Advanced Services
Tel: +31 30 2305362   Fax: +31 30 2305329
SURFnet -  POBox 19035 -  NL-3501 DA Utrecht - The Netherlands

---

From: Phil Hunt <[email-masked]>
Date: Mon, 3 Nov 2014 12:05:29 -0800

I believe there are now 3 independently written drafts. 

No working group work has been done. 

Maybe it is time for the WG to work on this?

It just doesn't seem to have as much priority as other issues like proof of possession tokens. 

Phil

> On Nov 3, 2014, at 03:02, Bas Zoetekouw <[email-masked]> wrote:
> 
> Hi All,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 3 Nov 2014 21:59:59 +0000

There's a new working group document where this component *could* be captured (and I would argue it should), and that's:

https://tools.ietf.org/wg/oauth/draft-ietf-oauth-token-exchange/

However, at the moment it's more concerned with the semantically-aware assertion swap instead of an opaque token swap. Personally, I think that the syntax should be general (like in my and in Phil's draft) to allow for any kind of input and output token, and if someone wants to standardize an assertion on top of that, they can. Hopefully we can get that clear in the WG as progress continues on this new document.

 -- Justin

On Nov 3, 2014, at 2:54 PM, Ajanta Adhikari <[email-masked]<mailto:[email-masked]>> wrote:

Note sure if I can reply to the mailing list yet so responding directly.
-----------------------------------------------------------------------------------------

Bas,
We (Akamai) came up with a similar design before I read the draft from Justin and Phil. I talked to Justin at IIW about our design choice and he seems to think its in the right direction.
There is a reference to it from our OAUTH scope design session at IIW http://iiw.idcommons.net/OAuth_2_Scope_Design_Discuss_iom

I would be happy to share additional details if you are interested. We do not publish our implementation to public.

Thanks,
Ajanta

On Mon, Nov 3, 2014 at 3:02 AM, Bas Zoetekouw <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Best regards,
Bas Zoetekouw.
SURFnet.

--
Bas Zoetekouw
SURFnet Advanced Services
Tel: +31 30 2305362<tel:%2B31%2030%202305362>   Fax: +31 30 2305329<tel:%2B31%2030%202305329>
SURFnet -  POBox 19035 -  NL-3501 DA Utrecht - The Netherlands

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Bill Mills <[email-masked]>
Date: Tue, 4 Nov 2014 00:07:18 +0000 (UTC)

We need to think about this, and whatever we build in this space should work for POP tokens as well.  I'd love to hear the concrete use cases and problems to be solved.

POP tokens (like OAuth 1.0a) are likely not to be proxyable, so the edge servers really should have a way to get a new credential for accessing other services on behalf of the user.

Another major consideration is that auth servers are frequently not scaled to handle the full edge transaction load, that's part of the point of issuing a longer lived credential by a server that's already done all the expensive policy and DB checks.

I'm not a big fan of a token exchange through the auth server for that reason, as well as the added cost incurred for the network round trips that's being built in.

-bill
      On Monday, November 3, 2014 2:00 PM, "Richer, Justin P." <[email-masked]> wrote:

On Nov 3, 2014, at 2:54 PM, Ajanta Adhikari <[email-masked]> wrote:

Bas,

Thanks,
Ajanta

On Mon, Nov 3, 2014 at 3:02 AM, Bas Zoetekouw <[email-masked]> wrote:

Hi All,

Best regards,
Bas Zoetekouw.
SURFnet.

--
Bas Zoetekouw
SURFnet Advanced Services
Tel: +31 30 2305362   Fax:+31 30 2305329
SURFnet -  POBox 19035 -  NL-3501 DA Utrecht - The Netherlands

---

From: Phil Hunt <[email-masked]>
Date: Mon, 3 Nov 2014 16:30:33 -0800

+1

Phil

> On Nov 3, 2014, at 16:07, Bill Mills <[email-masked]> wrote:
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 05 Nov 2014 10:20:05 +0000

Hi

Code and access token hashes that can be returned in OIDC responses is a 
good idea. I wonder, does it make any sense to have something like that 
supported at the 'bare' OAuth2 level alone to lower the complexity level 
(example, dealing with JWS id_tokens containing an access token hash may 
not be trivial) and just make this OIDC a_hash/c_hash idea generalized ?

For example, a JWK thumbprint [1] idea can be adapted.
Suppose the following is returned to the Client:
{"access_token":"123456", "refresh_token":"654321"}.

The approach at [1] can be applied producing:

{"access_token":"123456", "refresh_token":"654321", 
"thumbprint":"AxTh-Rtyw"}.

Similarly for code responses...

Just an idea...

Sergey

[1] 
http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00#section-3.3

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 06 Nov 2014 12:11:46 +0000

Hi

Does it make sense to consider supporting an access token or code 
wrapping as part of the standard OAuth2 responses ?

For example, if a client has registered its public key with AS then say 
the access token response would contain the regular

{"access_token":"1234345"}

except that "1234345" would actually be a JWE RSA-OAEP wrapped opaque 
token with a client's public key being used. Or a direct key encrypted 
token if the client and the server only share the client secret 
allocated to the client during the registration.

The net result is that only the registered confidential client would be 
able to extract the actual opaque access token. The response would 
actually be

{"access_token":"1234345", wrapped:true}.

I definitely plan to use this approach as a simple mechanism for making 
a safer distribution of mac keys as part of access token responses; but 
IMHO it can be handy for minimizing the possibility of the 
access/refresh tokens or codes being intercepted...

Sergey

---

From: Bill Mills <[email-masked]>
Date: Thu, 6 Nov 2014 18:51:51 +0000 (UTC)

So you're wanting end to end security not relying on TLS?

Have you seen the new draft on protecting codes from interception?  Currently called SPOP but needs a different name.
      On Thursday, November 6, 2014 4:12 AM, Sergey Beryozkin <[email-masked]> wrote:

 Hi

Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 07 Nov 2014 11:12:44 +0000

Hi
> So you're wanting end to end security not relying on TLS?
I was not really thinking about HTTPS vs HTTP in this case. I'm kind of 
in the process of appreciating what JWE/JWS can do and I can't help 
trying to consider it applying at the every possible opportunity :-)
>
> Have you seen the new draft on protecting codes from interception?
>   Currently called SPOP but needs a different name.
>
Do you mean this one:
http://tools.ietf.org/html/draft-ietf-oauth-spop-02
?

Yes I did - it's a different mechanism though, I guess it is of most 
help to the pubic clients, though we do not distinguish in our code, a 
confidential client can use the SPOP mechanism too.

I think the wrapping idea is probably what
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01#ref-10

talks about with respect to distributing a key using a JWE option.
That actually looks interesting; I haven't analyzed it much yet but 
apparently it is tied to the access token being necessarily in a JWT 
format, may be I did not get it right yet.

I guess it just can be interesting even in the TLS case. I believe 
people do not mind doing the extra protection even in the TLS cases.

Or take the implicit grant; if the wrapped access token reaches a client 
which is aware of WebCrypto API then it is probably making this grant 
much more secure...

Sergey

> [email-masked] <mailto:[email-masked]>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 07 Nov 2014 11:13:45 +0000

Sorry all for a certain typo in the text below

Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 07 Nov 2014 11:17:55 +0000

Or if the confidential client does
HTTP Accept: application/jose, why don't

reply with the whole OAuth2 token response JWE or JWS encoded as opposed 
to tweaking individual token response parameters...

may be I'm getting carried away here but I'm getting quite positive and 
even excited about the options JWE/JWS can offer :-).

Sergey

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

---

From: John Bradley <[email-masked]>
Date: Fri, 7 Nov 2014 11:15:13 -0300

You don't need to use JWT access tokens, you could use a opaque token and introspect it.  However JWT access tokens are likely the simplest answer for getting the clients proof key to the RS.

in http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution you can register a secret for the client and encrypt a symmetric key to it, if you want to use symmetric proofs for the RS.

For performance using symmetric proofs to the RS is not a bad option.   

If the client is a server and has appropriate hardware protection for asymmetric keys then using a asymmetric key protected by a HSM is going to be the most secure.

For native public client, they can start the flow with SPOP and when they exchange code and the code verifier get a symmetric proof key for the AT.  

SPOP and Proof of possession for AT are complimentary and used to protect different parts of the flow.

The c_hash and at_hash that we added to the id_token in Connect allow a client to determine if a token delivered in the front channel has been tampered with by the user agent.
(Some AS return at_hash in id_tokens returned from the token endpoint for interoperability, but hat is not required)  

John B

On Nov 7, 2014, at 8:12 AM, Sergey Beryozkin <[email-masked]> wrote:

> I was not really thinking about HTTPS vs HTTP in this case. I'm kind of in the process of appreciating what JWE/JWS can do and I can't help trying to consider it applying at the every possible opportunity :-)
>> 
> Yes I did - it's a different mechanism though, I guess it is of most help to the pubic clients, though we do not distinguish in our code, a confidential client can use the SPOP mechanism too.
> 
> That actually looks interesting; I haven't analyzed it much yet but apparently it is tied to the access token being necessarily in a JWT format, may be I did not get it right yet.
> 
> I guess it just can be interesting even in the TLS case. I believe people do not mind doing the extra protection even in the TLS cases.
> 
> Or take the implicit grant; if the wrapped access token reaches a client which is aware of WebCrypto API then it is probably making this grant much more secure...
> 
> Sergey
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 07 Nov 2014 16:02:21 +0000

Hi John

Many thanks for the clarifications. FYI, I posted some comments re the 
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution to a 
dedicated thread.

I just wonder is it OK to distinguish between bearer and JWT tokens in 
the spec texts referring to the client processing the access token 
responses. As far as the access tokens are concerned JWT token is just a 
data container which can be useful to AS/RS for the purpose of 
representing the relevant info, I'm curious if the client needs to know 
anything about the access_token format/representations at all.

I'm also curious about the option where the whole token responses are 
JWE encrypted even if TLS is used, with the assymetric key cases; thus 
allowing for the key being always in a plain base64 URL encoded form (in 
the case of the key distributions) but also in other cases I guess...We 
will offer this option for our users as an extension but I wonder if 
someone else here would find it useful

Cheers, Sergey

---

From: John Bradley <[email-masked]>
Date: Fri, 7 Nov 2014 17:42:57 -0300

Inline
On Nov 7, 2014, at 1:02 PM, Sergey Beryozkin <[email-masked]> wrote:

> Hi John
> 
> Many thanks for the clarifications. FYI, I posted some comments re the http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution to a dedicated thread.
> 
> I just wonder is it OK to distinguish between bearer and JWT tokens in the spec texts referring to the client processing the access token responses. As far as the access tokens are concerned JWT token is just a data container which can be useful to AS/RS for the purpose of representing the relevant info, I'm curious if the client needs to know anything about the access_token format/representations at all.
> 
The goal is for the AT to continue to be opaque to the Client as they are with bearer tokens.    
The spec contains an example of how to do it with a JWT access token, and is the method I prefer.  Introspection or a combination of introspection and structured token can be used.

Sec 3.2 states that the use of JWT AT is optional.

In some cases real time claim  info from the AT is desired by the RS.   The way I would do that is to send a JWT with the key info so that session setup can be done by the RS quickly, but include a claim that is a reference to information at the AS and introspect that in parallel, that also deals with a problem that occurs if you have multiple AS for one RS.

I don't think that we should go into all the possible options in this spec, perhaps that could be in a implementers guide.

> I'm also curious about the option where the whole token responses are JWE encrypted even if TLS is used, with the assymetric key cases; thus allowing for the key being always in a plain base64 URL encoded form (in the case of the key distributions) but also in other cases I guess...We will offer this option for our users as an extension but I wonder if someone else here would find it useful
> 
If the proof key is JWE encrypted to the client what would be the point of encrypting the token as well?   

I don't think I am quite getting your use case.

Encrypting to the client only works if it has a provisioned asymmetric key pair.  In the symmetric case the client provides it's secret as part of the request to the token endpoint via http BASIC authentication,  so anyone intercepting the https would have that key unless the client is using the JWK assertion flow for authentication (more of an edge case but supported in Connect)

Are you thinking that the client would not use it's key for authentication but the AS would encrypt all or part of the response to the key to prevent man in the middle?

I will admit looking at it now Sec 4.2 needs to be fleshed out around what keys you could use to encrypt the JWE encoded JWK.  I was thinking asymmetric keys but in principal you could use a symmetric key as long as it is not the one used for authenticating the client.

John B.

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 10 Nov 2014 10:45:45 +0000

Hi John,
> The spec contains an example of how to do it with a JWT access token, and is the method I prefer.  Introspection or a combination of introspection and structured token can be used.
Sure, so the way I'd like to look at it is that it is an informative 
content for the AS or token grant implementers, specifically, how a JWT 
can be used to link to a key being distributed, etc.
> Sec 3.2 states that the use of JWT AT is optional.
OK,
> In some cases real time claim  info from the AT is desired by the RS.   The way I would do that is to send a JWT with the key info so that session setup can be done by the RS quickly, but include a…
At this stage I can only say I agree JWT can be a useful token container 
indeed :-)
> I don't think I am quite getting your use case.

Sorry; I was just referring to a possibility of aligning token responses 
with the pure HTTP content negotiation mechanism. IMHO it won't be 
controversial. Consider this for an access token request/response with 
the symmetric POP key:

Accept: application/json

non-TLS

{"access_token":"compactJwsWithJweJwkInside", "key":"jweJwk"}
or TLS:

{"access_token":"compactJwsWithJwkInside", "key":"Jwk"}

vs

Accept: application/jose

non-TLS

JWE-payload

TLS:

JWS payload

with
{"access_token":"plainJwtWithJwkInside", "key":"Jwk"}

being the actual wrapped content in both cases.

As far as the client is concerned its processing model remains 
consistent (i.e, it does not deal with treating specific token response 
parameters as JWK or JWS payloads), with the client filters taking case 
of unwrapping a JOSE payload for the client code to deal with the actual 
data.

> Are you thinking that the client would not use it's key for authentication but the AS would encrypt all or part of the response to the key to prevent man in the middle?
At one point of time I did think that may be a client's own secret would 
be used for the encryption indeed :-), I referred to it earlier as a 
case of the direct encryption, but then realized, and as you pointed out 
that it would indeed make use of that secret as part of the Basic scheme 
risky;

I don't have enough experience to know how realistic is a man in the 
middle attack over HTTPs but I do think that people are generally open 
to the idea of the double protection (meaning that even JWE over TLS 
will work :-))

> I will admit looking at it now Sec 4.2 needs to be fleshed out around what keys you could use to encrypt the JWE encoded JWK.  I was thinking asymmetric keys but in principal you could use a symmet…

Can this extra symmetric key be referred to as a key obtained out of 
band during the registration, or even mentioned as part of the dynamic 
registration process...It's like an extra key distribution, during the 
registration the client gets its secret plus a POP symmetric key

Thanks, Sergey