Re: [OAUTH-WG] draft-ietf-oauth-v2-http-mac and draft-tschofenig-oauth-hotk re-submitted

[Sergey Beryozkin <[e-mail]>]

Hi Hannes


On 27/02/13 08:54, Hannes Tschofenig wrote:
> Hi Sergey,
>
> good that this issue got clarified.
>
> Regarding:
>
>> By the way, should the server be able to enforce the use of MAC as opposed to having a client preferring it with its audience info ? If the client does not understand it then it does not have the capabilities to work with this specific server.
>
> Currently, the authorization server decides about the use of a certain token type. The audience field is used to allow the client to tell the server which resource  server it wants to talk to. This is of value not only for this specification but also for the bearer token specification. In this specification the resource server uses this audience field for selecting the appropriate key to encrypt the access token. If the client is tricked in sending the access token to a different resource server then that server will not be able to decrypt the access token and will not be able to retrieve the session key. Consequently, it will not be able to impersonate the client towards another resource server.
Thanks for the explanation, I should've read better, 'audience' is a 
useful attribute.

What confused me was this text: "Authorization servers issue MAC Tokens 
based on requests from clients." - it kind of reads to me that the 
clients drive whether it is MAC or some other token type is issued in 
exchange for a grant while I'd expect the AS administrators deciding on 
what sort of token type is used.

As for "MUST" and audience - might it make sense to replace it with 
SHOULD or RECOMMENDED ? I wonder if some issues like port number of 
individual resource servers comprising the bigger resource server 
application, etc, might make it difficult to use 'audience' - not sure 
if it of real concern or not :-)

Thanks, Sergey

>
> Ciao
> Hannes
>
> On Feb 26, 2013, at 2:49 PM, Sergey Beryozkin wrote:
>
>> Hi Again
>> On 26/02/13 12:36, Sergey Beryozkin wrote:
>>> Hi Hannes
>>> On 25/02/13 12:46, Hannes Tschofenig wrote:
>>>> Hi all,
>>>>
>>>> I just submitted an updated version of the
>>>> draft-ietf-oauth-v2-http-mac-03.txt.
>>>>
>>>
>>> It definitely has more interesting content (about architecture, session
>>> keys, etc) - this is really useful IMHO.
>>>
>>> What I'm not really understanding is why a 2-way TLS transport for the
>>> session key is not even considered.
>>> Instead this uber-complex (in the context of this spec, IMHO) JWT thing
>>> is there once again. I appreciate why it may be the case, primarily to
>>> do with reusing the work done around JWT and having some
>>> common/recommended access token representation, but disallowing a basic
>>> bearer token be 'enhanced' with MAC over two-way TLS seems like not
>>> ideal at all IMHO.
>>> To be honest, I'm not sure why would anyone use JWT+MAC instead of just
>>> JWE, in cases when people are really comfortable with doing JWT. I guess
>>> we may be talking now about better security characteristics, but this
>>> will help a very limited audience as compared to a wider one which can
>>> use Bearer+MAC over 2-way TLS, straightforward, very cheap effort to get
>>> started.
>>>
>> Oops, I've misread, I think I did, I was reading a Session Key Transport to Resource Server section [1] where using JWT seems just OK, while a transport to the client section [2] does not enforce the use of JWT.
>>
>> Sorry for a noise :-)
>>
>> By the way, should the server be able to enforce the use of MAC as opposed to having a client preferring it with its audience info ? If the client does not understand it then it does not have the capabilities to work with this specific server.
>>
>> Thanks, Sergey
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.2
>> [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.1
>>
>>> just my 2c
>>> Thanks, Sergey
>>>
>>>> I would like to point out that this is **discussion input** -- not
>>>> agreed content. Anything in the document is subject to change!
>>>> You also may notice that there are a few questions in the writeup.
>>>>
>>>> I was trying to more specific about some of the design aspects that
>>>> folks had proposed during the last few months.
>>>> I have also re-submitted the draft-tschofenig-oauth-hotk, which
>>>> includes a TLS and a JSON-based solution approach.
>>>>
>>>> In general, the open questions still seem to be related to
>>>> * Key distribution: What should be described in a document? What is
>>>> mandatory to implement?
>>>> * Selective header field protection: This is something that was
>>>> brought forward in discussions and I have included a proposal of how
>>>> this could look like.
>>>> * Channel Binding: Functionality is also included to deal with
>>>> man-in-the-middle attacks against TLS. There are, however, two types
>>>> of channel bindings defined in RFC 5929. Are both needed? If not,
>>>> which one should be selected?
>>>> * Integrity protection and data origin authentication in both
>>>> directions: The current writeup allows the protection to be extended
>>>> to messages beyond the initial request. This also offers key
>>>> confirmation by the server and protection of any responses.
>>>>
>>>> Writing the text I also noticed that I do not quite understand how
>>>> nested JWT documents are supposed to look like. For example, how do I
>>>> encrypt the mac_key carried inside the JWT plus add a signature of all
>>>> other fields? Currently, I have just encrypted the entire payload.
>>>>
>>>> I hope to have some discussions prior to the IETF meeting so that we
>>>> have a more fruitful discussion at the face-to-face meeting.
>>>>
>>>> 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
>