Re: [OAUTH-WG] Updated OAuth PoP documents

[Sergey Beryozkin <[e-mail]>]

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:
> Hi John,
> Sorry for a delay,
> On 07/11/14 21:27, John Bradley wrote:
>> Inline.
>> On Nov 7, 2014, at 12:50 PM, Sergey Beryozkin <[e-mail]>
>> wrote:
>>
>>> 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 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 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...
>
>
>> 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.
>>
> thanks for this extra info,
>>
>>>
>>> - 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.)
> 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
>>
>> John B.
>>
>>
>>>
>>> Thanks, Sergey
>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>