Subject: Re: [OAUTH-WG] Updated OAuth PoP documents

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 07 Nov 2014 15:50:58 +0000

Hi
On 26/06/14 13:42, Hannes Tschofenig wrote:
> Hi all,
>
> I read through three of the OAuth proof-of-possession documents and made
> a few minor changes here and there (mostly editorial & updated references).
>
> Here are the three docs:
> http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
>
> While there are a few open issues I believe that these three documents
> are in fairly good shape.
>
> Is someone willing to do a review?
>
Few comments to
https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:

- it is unclear what the new token_type if any is introduced, for 
example, the section 6 says no new token type is introduced, while the 
symmetric example uses a "pop" value and the assymetric key response 
example says:
"The new token type "public_key" is placed into the 'token_type' parameter"

Is the new type is actually introduced and it is "pop" and the clients 
making the requests to RS should use a "POP"/"pop" scheme ?

http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01

uses "pop" but I'm not 100% sure...

- The assymetric key example suggests that just a JWS-signed access 
token is returned. This implies a client can easily introspect it - 
which is not a big problem in this case - but it leads the client toward 
writing a code that is bound to an access token structure - therefore 
such a client code won't inter-operate with the AS sending a bearer 
token; IMHO the access token structure should absolutely be opaque to 
the clients, i.e, if it is JWT then it must be JWE protected

Thanks, Sergey

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

---

From: John Bradley <[email-masked]>
Date: Fri, 7 Nov 2014 18:27:52 -0300

Inline.
On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin <[email-masked]> wrote:

> - it is unclear what the new token_type if any is introduced, for example, the section 6 says no new token type is introduced, while the symmetric example uses a "pop" value and the assymetric key response example says:
> Is the new type is actually introduced and it is "pop" and the clients making the requests to RS should use a "POP"/"pop" scheme ?
> 

The specs for the client accessing the RS need to define the token type.  

There is likely to be more than one of those, signed message and TLS channel binding.

I am guessing that the channel binding one wouldn't support symmetric proof keys.

Those specs may wind up profiling this spec to limit particular key types etc.

The token_type  in the request is saying give me a token to use over this request method to the RS.

The AS might use the same logic to produce a AT for signed request and TLS.

The other parameters are:
"aud" so that the AS can deal with multiple RS perhaps all with different encryption keys and some using introspection.
"alg" indicating the alg of the proof key "HS256", "RS256", and "ECDSA"  being the current likely options.
(looking at that now I wonder if we also need to say anything about key length/curve,  I hope all of that can be sorted out in registration so some sensible defaults would work for length/curve)

Those being important to any client RS protocol.

> 
> - The assymetric key example suggests that just a JWS-signed access token is returned. This implies a client can easily introspect it - which is not a big problem in this case - but it leads the client toward writing a code that is bound to an access token structure - therefore such a client code won't inter-operate with the AS sending a bearer token; IMHO the access token structure should absolutely be opaque to the clients, i.e, if it is JWT then it must be JWE protected

The intention is not to limit it to just JWS signed JWT, that should be expanded if not clear.

SAML has the same problem with people sniffing tokens, so I agree that the client should be precluded in the spec from doing that.   
Forcing encryption of all the AT may be overkill and have negative performance implications if not required for other reasons.   
Nothing stops the AS and RS from using JWE encrypted JWT.  Given that in the symmetric key case between the AS and RS case a A128CBC-HS256 has AEAD Authenticated encryption so you don't need to sign the JWT separately as an optimization.  (I personally prefer A128CBC-HS256 over HS256 given that the performance hit is small, but that is just me.) 

Requiring encryption is probably overkill.

John B.

---

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

Hi John,
Sorry for a delay,
> There is likely to be more than one of those, signed message and TLS channel binding.
I wonder, should it only be this PoP key distribution spec that would 
use "pop", which is really about getting a regular token 'enhanced' with 
a key. If I have AS returning a bearer token with a response containing 
"token_type":"bearer", then when this AS receives a client token request 
with a "token_type":"pop" it just means the bearer token to be returned 
would have a key parameter bound to it.

Note IMHO it does not matter for the client whether the actual token 
representation is JWT or an index, it is still a "token_type":"bearer" 
as far as the client getting a token response is concerned.
So it won't lead to the proliferation of the new token types.

Something else that I wanted to suggest - can make no much sense but 
here it goes:

Refresh tokens and indeed id_token OIDC tokens are just access token 
response parameters but for them to be included in the response all what 
is needed is for the client to include an extra scope in the redirection 
request... Just a thought...

> Those being important to any client RS protocol.
thanks for this extra info,
> Nothing stops the AS and RS from using JWE encrypted JWT.  Given that in the symmetric key case between the AS and RS case a A128CBC-HS256 has AEAD Authenticated encryption so you don't need to sig…
I'm afraid I'm not following that :-), but given that we do implement 
"A128CBC-HS256 over HS256" now, I will afford asking, are you referring 
here to the case of the PoP key being distributed in a plain form over 
TLS vs being JWE-encrypted with "A128CBC-HS256 over HS256" ?
> Requiring encryption is probably overkill.
I understand, as long as the client treats a JWS sequence as an opaque 
blob, it is fine...

Thanks
Sergey

---

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

By the way, where is the key encryption key is obtained from in a case 
where the POP JWK key is encrypted ? Is it a client public key or some 
key obtained out of band ?

Cheers, Sergey
On 10/11/14 11:02, Sergey Beryozkin wrote:
>>> example, the section 6 says no new token type is introduced, while
>>> the symmetric example uses a "pop" value and the assymetric key
>>> response example says:
>>> Is the new type is actually introduced and it is "pop" and the
>>> clients making the requests to RS should use a "POP"/"pop" scheme ?
>>>
>> "aud" so that the AS can deal with multiple RS perhaps all with
>> different encryption keys and some using introspection.
>> "alg" indicating the alg of the proof key "HS256", "RS256", and
>> "ECDSA"  being the current likely options.
>> (looking at that now I wonder if we also need to say anything about
>> key length/curve,  I hope all of that can be sorted out in
>> registration so some sensible defaults would work for length/curve)
>>
>>> which is not a big problem in this case - but it leads the client
>>> toward writing a code that is bound to an access token structure -
>>> therefore such a client code won't inter-operate with the AS sending
>>> a bearer token; IMHO the access token structure should absolutely be
>>> opaque to the clients, i.e, if it is JWT then it must be JWE protected
>>
>> SAML has the same problem with people sniffing tokens, so I agree that
>> the client should be precluded in the spec from doing that.
>> Forcing encryption of all the AT may be overkill and have negative
>> performance implications if not required for other reasons.
>> Nothing stops the AS and RS from using JWE encrypted JWT.  Given that
>> in the symmetric key case between the AS and RS case a A128CBC-HS256
>> has AEAD Authenticated encryption so you don't need to sign the JWT
>> separately as an optimization.  (I personally prefer A128CBC-HS256
>> over HS256 given that the performance hit is small, but that is just me.)

---

From: John Bradley <[email-masked]>
Date: Mon, 10 Nov 2014 06:56:58 -1000

For sending  JWE symmetric key to the client the Key Encryption Key is client public key provisioned out of band or pushed to the AS in the request.  (The same applies to key agreement)

John B.
On Nov 10, 2014, at 1:05 AM, Sergey Beryozkin <[email-masked]> wrote:

> By the way, where is the key encryption key is obtained from in a case where the POP JWK key is encrypted ? Is it a client public key or some key obtained out of band ?
> 
> Cheers, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 11 Nov 2014 10:47:43 +0000

> For sending  JWE symmetric key to the client the Key Encryption Key is client public key provisioned out of band or pushed to the AS in the request.  (The same applies to key agreement)
Thanks...

I suggested earlier to consider using 'bearer' token type in the token 
response containing a 'key'; probably a bad idea, not sure now (i.e, is 
it still a 'bearer', with a client now holding a PoP key :-)),

may be it should be 'pop' as documents like
http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0
offer.

Speaking of "draft-richer-oauth-signed-http-request" - a colleague of 
mine raised a related question and I wonder, should this document offer 
an *optional* request body hashing as well.

Thanks, Sergey

---

From: Justin Richer <[email-masked]>
Date: Tue, 11 Nov 2014 07:05:07 -1000

It already does offer a body hash, optional like the rest of the parameters

https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00#section-3

(see the “b” parameter)

 — Justin

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

> I suggested earlier to consider using 'bearer' token type in the token response containing a 'key'; probably a bad idea, not sure now (i.e, is it still a 'bearer', with a client now holding a PoP key :-)),
> 
> Speaking of "draft-richer-oauth-signed-http-request" - a colleague of mine raised a related question and I wonder, should this document offer an *optional* request body hashing as well.
> 
> Thanks, Sergey
> 
>> 
>> John B.

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 11 Nov 2014 17:12:20 +0000

Hi Justin

I'm sorry, I've missed it

What is your opinion of having a body optionally wrapped into JWS and 
JWS being sent as a body, as an alternative (while keeping 'b' as an 
option too).
It can allow for streaming, as opposed to calculating the body hash in 
memory...JWS can be calculated dynamically. The key would be the same 
key that calculates the query/etc hash...

Sergey

---

From: John Bradley <[email-masked]>
Date: Tue, 11 Nov 2014 07:16:51 -1000

The token type is about the client RS binding.   It is up to the specs like http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-0 to register the token types.   It may be possable for more than one binding to use the same token type, but that is up to them.

The term "token type" in retrospect may be slightly confusing in that the same AT format, may have multiple token types registered depending on the bindings.

By definition bearer an POP are mutually exclusive types of bindings.

The body hash is an option, but can be quite difficult for implementations in practice.  

John B.

---

From: Justin Richer <[email-masked]>
Date: Tue, 11 Nov 2014 07:22:21 -1000

What you’re talking about is changing the body of your API to be a JWS directly, and that’s fine if your API wants to do things that way. Just define it as part of what your API expects — there are several out there that can do this. But that’s not what this work is about. This work is very explicitly about detaching the signing mechanism from the request itself, so that you don’t *have* to cram everything into a JOSE object directly. This lets you keep a plain JSON/XML/LISP-S-Expressions API and still be able to layer in signing of the request tied to an access token.

 — Justin

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

> What is your opinion of having a body optionally wrapped into JWS and JWS being sent as a body, as an alternative (while keeping 'b' as an option too).
> It can allow for streaming, as opposed to calculating the body hash in memory...JWS can be calculated dynamically. The key would be the same key that calculates the query/etc hash...
> 
> Sergey

---

From: John Bradley <[email-masked]>
Date: Tue, 11 Nov 2014 07:23:30 -1000

Personally I think that sending a JWS as the body is a fine idea, though I would not directly tie that to POP because that are likely validated at different levels.  OAuth should not be in the business of extracting body content from the JWS.

If the RS wants to pass the key for validating the JWS body up to the application, and have the application validate/decrypt the body that would be fine in my opinion.
I think that however would be defined in another extension.

John B.

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 11 Nov 2014 17:30:27 +0000

> What you’re talking about is changing the body of your API to be a JWS directly, and that’s fine if your API wants to do things that way. Just define it as part of what your API expects — there are…
Not sure why you are talking about wrapping the body in JWS as an 
anti-layering idea specific to some API. Perfectly can be managed by 
filters before the body reaches the API.
Note - I'm not going to argue that this is how a body signature should 
be done :-), fine with me for the oauth2 signed-http-request go with an 
optional 'b' hash idea. I'm only saying it is all in memory only as far 
  as the producer is concerned...

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 11 Nov 2014 18:10:46 +0000

Hi John

Sorry for being noisy. I'd like to clarify.
I was not thinking of the application getting a JWS, I was rather 
thinking of doing something similar to GZIP really, where on the wire we 
see a gzipped payload but the application gets the data it understands. 
One filter would validate the 'basic' signature of the headers/URI, the 
other - of the payload while unwrapping JWS.

What I do like about JWS/JWE is that it is neatly structured such that 
it allows for the best-effort streaming of both the payload being 
wrapped and of the JWS/JWS pieces. Hence I offered this idea.

As I said to Justin: I'm fine with it not being considered further, one 
can't expect every proposal being accepted :-)

Thanks for the feedback !
Sergey