Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt

[John Bradley <[e-mail]>]

The communication between AS and RS is not direct it is through the client in this case.   If TLS covers all the connections and is sufficient you probably don't need MAC:)

If you were to send the symmetric key in the JWT unencrypted than there is no real point in signing anything as any one intercepting the request can just sign a new one.

For symmetric keys being distributed through the access token the key needs to be encrypted to the intended RS to provide value.

John B.

On 2013-02-28, at 2:37 AM, Antonio Sanso <[e-mail]> wrote:

> Hi Hannes,
> 
> apologies if I do the same question again but there is still one point that is a little obscure to me.
> 
> As long I did understand the situation for MAC is the following one.
> 
> The communication between the client and the authentication server must be https but this is not true for the communication between authentication server and resource server.
> Hence the need of this key exchange.
> 
> Is it correct? Should be the case why we do not have the same problem in the JWT Bearer case? Is because in that case https is as well mandatory between authentication server and resource server?
> 
> Thanks a lot and regards
> 
> Antonio
> 
> 
> On Feb 28, 2013, at 11:28 AM, Hannes Tschofenig wrote:
> 
>> Hi Bill, 
>> 
>> I believe you are misreading the document. In draft-ietf-oauth-v2-http-mac the client still uses the MAC when it accesses a protected resource. 
>> The only place where the JWT comes into the picture is with the description of the access token. This matters from a key distribution point of view. The session key for the MAC is included in the encrypted JWT. The JWT is encrypted by the authorization server and decrypted by the resource server. 
>> 
>> Information about how header fields get included in the MAC is described in Section 5.
>> 
>> The nonce isn't killed it is just called differently: seq-nr. The stuff in the original MAC specification actually wasn't a nonce (from the semantic point of view). 
>> The extension parameter is there implicitly by allowing additional header fields to be included in the MAC computation.
>> 
>> I need to look at the port number field again. 
>> 
>> Ciao
>> Hannes
>> 
>> On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>> 
>>> Just read the draft quickly.  
>>> 
>>> Since we're now leaning on JWT do we need to include the token in this?  Why not just make an additional "Envelope MAC" thing and have the signature include the 3 JWT parts in the signature base string?  That object then just becomes a JSON container for the kid, timestamp, signature method, signature etc. That thing then is a 4th base64 encoded JSON thing in the auth header.
>>> 
>>> How header fields get included in the signature needs definition.
>>> 
>>> Why did you kill the port number, nonce, and extension parameter out of the signature base string?
>>> 
>>> The BNF appears to have no separators between values.
>>> 
>>> -bill
>>> 
>>> 
>>> From: "[e-mail]" <[e-mail]>
>>> To: [e-mail] 
>>> Cc: [e-mail] 
>>> Sent: Monday, February 25, 2013 4:46 AM
>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>>> 
>>>   Title          : OAuth 2.0 Message Authentication Code (MAC) Tokens
>>>   Author(s)      : Justin Richer
>>>                         William Mills
>>>                         Hannes Tschofenig
>>>   Filename        : draft-ietf-oauth-v2-http-mac-03.txt
>>>   Pages          : 26
>>>   Date            : 2013-02-25
>>> 
>>> Abstract:
>>> This specification describes how to use MAC Tokens in HTTP requests
>>> to access OAuth 2.0 protected resources.  An OAuth client willing to
>>> access a protected resource needs to demonstrate possession of a
>>> crytographic key by using it with a keyed message digest function to
>>> the request.
>>> 
>>> The document also defines a key distribution protocol for obtaining a
>>> fresh session key.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03
>>> 
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth