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

1) AS issues JWT + secret to client.
2) Client decides to access resource, creates the JWT MAC JSON object which contains stuff about the signature and the signature itself.
3) client appends that base64 encoded thing to the JWT

1) Server gets a JWTMAC token, takes apart the JWT part to get the signing key
2) Server looks at the JWTMAC to figure out what all it has to do to create the signature base string 
3) server constructs the SBS computes and checks the sig.

The only hairy bit right now is an arbitrary HTTP header list that may be included in the signature.

No data in the JWTMAC is duplicated from anywhere else.

________________________________
 From: Justin Richer <jricher@mitre.org>
To: William Mills <wmills_92105@yahoo.com> 
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; "oauth@ietf.org" <oauth@ietf.org> 
Sent: Thursday, February 28, 2013 9:08 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt

What I don't quite get is what exactly would be presented and processed at each step. Who needs to know what piece? We don't want to have to push everything into JSON for the signing to take place (that much is clear), and we don't want the client to be pushing the MAC secret to the RS every time (that would make it a lot less secret, after all). But if we can reuse JWT, JWS, and other JOSE mechanisms to make some parts of the MAC pattern easier for programmers, I'm for it.

 -- Justin

On 02/28/2013 08:14 AM, William Mills wrote:

I'm actually advocating that we change MAC to be a JWT extension.
>
>
>
>________________________________
> From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
>To: William Mills <wmills_92105@yahoo.com> 
>Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; "oauth@ietf.org" <oauth@ietf.org> 
>Sent: Thursday, February 28, 2013 2:28 AM
>Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
> 
>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: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
>> To: i-d-announce@ietf.org 
>> Cc: oauth@ietf.org 
>> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>
>
>
>
>
>
>_______________________________________________
OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth 