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

From: [email-masked]
Date: Mon, 25 Feb 2013 04:46:42 -0800

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/

---

From: William Mills <[email-masked]>
Date: Wed, 27 Feb 2013 01:12:53 -0800 (PST)

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: "[email-masked]" <[email-masked]>
To: [email-masked] 
Cc: [email-masked] 
Sent: Monday, February 25, 2013 4:46 AM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt

Abstract:

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

---

From: William Mills <[email-masked]>
Date: Wed, 27 Feb 2013 01:18:54 -0800 (PST)

And also...

How would the server mandate a set of header fields requiring signature?  How can the server mandate a signature method or do we just stay with the two options and allow either?  It might want to enforce SA-256?

-bill

________________________________
 From: William Mills <[email-masked]>
To: "[email-masked]" <[email-masked]>; Hannes Tschofenig <[email-masked]> 
Sent: Wednesday, February 27, 2013 1:12 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt

-bill

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Feb 2013 12:28:18 +0200

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

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 28 Feb 2013 10:37:44 +0000

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

---

From: William Mills <[email-masked]>
Date: Thu, 28 Feb 2013 05:14:55 -0800 (PST)

I'm actually advocating that we change MAC to be a JWT extension.

________________________________
 From: Hannes Tschofenig <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Hannes Tschofenig <[email-masked]>; "[email-masked]" <[email-masked]> 
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, 

Ciao
Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 28 Feb 2013 17:04:29 +0000

Hi
> I'm actually advocating that we change MAC to be a JWT extension.
IMHO, having a simpler option, plus, going forward, a possible JWT 
profile (client to RS path) would work better -

Why would JWT completely take over ? May be it should be possible indeed 
to have it as a JWT extension - should it be part of the relevant JWT 
assertion spec, where JWT is used as a possible grant ?

Thanks, Sergey
>
> ------------------------------------------------------------------------
> *From:* Hannes Tschofenig <[email-masked]>
> *To:* William Mills <[email-masked]>
> *Cc:* Hannes Tschofenig <[email-masked]>; "[email-masked]"
> <[email-masked]>
> *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.
>
> 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.
>
>  > 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.
>  >
>  > From: "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
>  > To: [email-masked] <mailto:[email-masked]>
>  > Cc: [email-masked] <mailto:[email-masked]>
>  > [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Thu, 28 Feb 2013 12:08:46 -0500

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:
> 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.
>
> 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).
> 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.
> >

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Feb 2013 09:23:20 -0800

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.

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 28 Feb 2013 17:30:26 +0000

> assertion spec, where JWT is used as a possible grant ?
We are talking about access tokens here I've just realized, looking at 
other emails...still may be JWT assertion spec may be expanded in 
principle...

Sergey

---

From: William Mills <[email-masked]>
Date: Thu, 28 Feb 2013 09:43:42 -0800 (PST)

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 <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Hannes Tschofenig <[email-masked]>; "[email-masked]" <[email-masked]> 
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

            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. 
>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.
>> 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.
>> Why did you kill the port number, nonce, and extension
            parameter out of the signature base string?
>> ftp://ftp.ietf.org/internet-drafts/
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Thu, 28 Feb 2013 09:49:03 -0800 (PST)

The JWT replaces the oauth_token data element in the old MAC stuff.  I just want to take all the other oauth_* variables and stuff them in a separate JSON object and completely kill the "fun with sorting variables" when the oauth_* things can be carried in the query string or header or post body.

________________________________
 From: Sergey Beryozkin <[email-masked]>
To: [email-masked] 
Sent: Thursday, February 28, 2013 9:04 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
 
Hi

Thanks, Sergey
>  > Just read the draft quickly.
>  >
>  > Since we're now leaning on JWT do we need to include the token in
>  >
>  > 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: "[email-masked] <mailto:[email-masked]>"
>  > To: [email-masked] <mailto:[email-masked]>
>  > Cc: [email-masked] <mailto:[email-masked]>
>  > 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
>  > [email-masked] <mailto:[email-masked]>
>  > https://www.ietf.org/mailman/listinfo/oauth
>  >
>  >
>
>
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 28 Feb 2013 12:49:40 -0500

OK, so it still runs the signature over HTTP elements (query, url, 
headers, etc) but all of the structured components are *communicated* 
via a JWT/JOSE structure. That makes sense to me, on the surface at least.

  -- Justin

On 02/28/2013 12:43 PM, William Mills wrote:
> 2) Client decides to access resource, creates the JWT MAC JSON object 
> which contains stuff about the signature and the signature itself.
> *From:* Justin Richer <[email-masked]>
> *Sent:* Thursday, February 28, 2013 9:08 AM
> 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
>
>> <mailto:[email-masked]>
>> <mailto:[email-masked]>
>> *Cc:* Hannes Tschofenig <[email-masked]> 
>> <mailto:[email-masked]>; "[email-masked]" 
>> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>> That object then just becomes a JSON container for the kid, 
>> timestamp, signature method, signature etc. That thing then is a 4th

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 28 Feb 2013 18:02:27 +0000

On 28/02/13 17:49, William Mills wrote:
> The JWT replaces the oauth_token data element in the old MAC stuff. I
> just want to take all the other oauth_* variables and stuff them in a
> separate JSON object and completely kill the "fun with sorting
> variables" when the oauth_* things can be carried in the query string or
> header or post body.
As far as the client accessing RS is concerned, should it be limited to 
using a header, same as for other OAuth2 tokens ?

Cheers, Sergey

> *From:* Sergey Beryozkin <[email-masked]>
> *To:* [email-masked]
> *Sent:* Thursday, February 28, 2013 9:04 AM
>  > *From:* Hannes Tschofenig <[email-masked]
> <mailto:[email-masked]>>
>  > *To:* William Mills <[email-masked]
> <mailto:[email-masked]>>
>  > *Cc:* Hannes Tschofenig <[email-masked]
> <mailto:[email-masked]>>; "[email-masked]
> <mailto:[email-masked]>"
>  > <[email-masked] <mailto:[email-masked]>>
>  > > From: "[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>"
>  > <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked] <mailto:[email-masked]>>
>  > > Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>

---

From: William Mills <[email-masked]>
Date: Thu, 28 Feb 2013 10:06:04 -0800 (PST)

I certainly hope so.

________________________________
 From: Sergey Beryozkin <[email-masked]>
To: William Mills <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Thursday, February 28, 2013 10:02 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt

Cheers, Sergey

>  > I'm actually advocating that we change MAC to be a JWT extension.
>  > ------------------------------------------------------------------------
>  > *From:* Hannes Tschofenig <[email-masked]
>  > *To:* William Mills <[email-masked]
>  > *Cc:* Hannes Tschofenig <[email-masked]
>  > <[email-masked] <mailto:[email-masked]>>
>  > *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: "[email-masked] <mailto:[email-masked]>
>  > <[email-masked] <mailto:[email-masked]>
>  > > To: [email-masked] <mailto:[email-masked]>
>  > > Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > > 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
>  > > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > > https://www.ietf.org/mailman/listinfo/oauth
>  > >
>  > >
>  >
>  >
>  >
>  >
>  >

---

From: Phil Hunt <[email-masked]>
Date: Thu, 28 Feb 2013 10:15:59 -0800

Yes. That is my understanding. 

Phil

Sent from my phone.

On 2013-02-28, at 9:49, Justin Richer <[email-masked]> wrote:

> OK, so it still runs the signature over HTTP elements (query, url, headers, etc) but all of the structured components are *communicated* via a JWT/JOSE structure. That makes sense to me, on the surface at least.
> 
>  -- Justin
> 
>