Subject: [OAUTH-WG] Fwd: HTTP protocol version in MAC signatures

From: Phil Hunt <[email-masked]>
Date: Thu, 8 May 2014 20:47:01 -0700

Fyi

Phil

Begin forwarded message:

> From: Blair Strang <[email-masked]>
> Date: May 8, 2014 at 18:47:58 PDT
> Resent-To: [email-masked], [email-masked], [email-masked], [email-masked]
> To: [email-masked]
> Subject: HTTP protocol version in MAC signatures
> 
> Hi,
> 
> [Not sure if this is the right address to submit this feedback to]
> 
> Looking over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 section 5.2. "MAC Input String", it seems that the HTTP request line is used verbatim during the construction of MAC tokens.
> 
> Since this includes the transport (HTTP/1.1 versus say HTTP/1.0) it seems that HTTP proxies which run different protocol versions on each leg will break signatures. 
> 
> I would recommend removing the HTTP version from the MAC. The transport is inherently a "per hop" type of thing, while request signatures are conceptually "end to end".
> 
> I am not aware of any specific security benefits derived from including the HTTP protocol version in the MAC input string. This may be why AWS version 2 and AWS version 4 signatures do not include it.
> 
> Thanks and regards,
> 
>     Blair.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 12 May 2014 20:02:49 +0200

Hi Phil,
Hi Blair,

this is a good point. I also don't see a reason why the HTTP protocol
version should be included in the keyed message digest (from a security
point of view).

It might, however, be worthwhile to point out that we are exploring
different solution directions, as described in this slide deck
http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx

For this reason it might be interesting to know what AWS implements. Do
you guys have a reference?

Ciao
Hannes

On 05/09/2014 05:47 AM, Phil Hunt wrote:
> Fyi
> 
> Phil
> 
> Begin forwarded message:
> 
>> *From:* Blair Strang <[email-masked]
>> <mailto:[email-masked]>>
>> *Date:* May 8, 2014 at 18:47:58 PDT
>> *Resent-To:* [email-masked]
>> <mailto:[email-masked]>, [email-masked]
>> <mailto:[email-masked]>, [email-masked]
>> <mailto:[email-masked]>, [email-masked]
>> <mailto:[email-masked]>
>> *To:* [email-masked]
>> <mailto:[email-masked]>
>> *Subject:* *HTTP protocol version in MAC signatures*
>>
>> Hi,
>>
>> Looking
>> over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05 section 5.2.
>> "MAC Input String", it seems that the HTTP request line is used
>> verbatim during the construction of MAC tokens.
>>
>> Since this includes the transport (HTTP/1.1 versus say HTTP/1.0) it
>> seems that HTTP proxies which run different protocol versions on each
>> leg will break signatures. 
>>
>> I would recommend removing the HTTP version from the MAC. The
>> transport is inherently a "per hop" type of thing, while request
>> signatures are conceptually "end to end".
>>
>> I am not aware of any specific security benefits derived from
>> including the HTTP protocol version in the MAC input string. This may
>> be why AWS version 2 and AWS version 4 signatures do not include it.
>>
>> Thanks and regards,
>>
>>     Blair.
>>
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Blair Strang <[email-masked]>
Date: Tue, 13 May 2014 16:34:30 +1000

Hi Hannnes,

Yes, so in terms of well-defined specs for HTTP request signing, there is
basically AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff which is
looking a bit abandoned.

The v2 and v4 signing processes for AWS are documented here.
[1] http://docs.aws.amazon.com/general/latest/gr/signature-version-2.html
[2] http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

Looking at the slides you sent, my colleague Scott and I have been working
on something running along the same lines. This has largely been for
internal use, but we have had our eye on a design with general utility.

So far we have been working to clearly define *only* how HTTP requests can
be authenticated using a JWT/JWS, independent of the issues of key
distribution and sessions (an OAuth2 extension is one option for sessions /
key agreement, but there are obviously other ways).

We actually have a spec and proof of concept in progress for JWS based
request signing. We do need some time to clean up the spec for public
consumption, but would you be interested in seeing that?

Thanks,

    Blair.

---- Long form details below here -----

Our view is that request authentication (mac/signature) and the session (or
key agreement) mechanisms needed to support it are largely orthogonal.

We have been working to specify a mechanism for authenticating HTTP
requests using JWT/JWS. (The tokens look just like JWTs, but it is better
to specify on top of JWS).

Our approach was that the client computes a "signature base string" or
"string to sign" in a fashion very similar to AWS v2, while adding header
signing similar to that in AWS v4. This fixes a gap in the OAuth 1.0a HMAC
token spec.

The client then embeds a digest of the "signature base string" in a JWS
signed by the client, along with several other required fields (e.g. a
field identifying the requestor, optional key id, expiry, list of signed
http headers, ...) to authenticate the request.

The nice thing about embedding the request digest in a JWT/JWS signed
payload is that you get all the flexibility of JWS in terms of algorithms.

Also, the implementation also comes out very nice, since you need just
string processing of the request to get a canonical version plus a digest
operation - and the "hard crypto stuff" can be handled by a JWS library.

However, there are some constraints in terms of practicality using the JWS
standard (not insurmountable, but there):

1. RSA - A client with a private key can easily RSA-sign HTTP requests, but
the Authorization: header will be several hundred bytes long due to the
size of the RSA signature. Speed is high, but so is bandwidth required.

2. ECDSA - ECDSA produces much smaller payloads (few hundred bytes) but
requires much more processing effort (order of milliseconds).

3. HMAC - A shared HMAC key will be the most efficient in terms of speed &
storage, but requires additional session establishment dance which is
slightly less elegant than a client using a private key directly.

Request authorisation using a private key directly works well for
server-to-server or "big client" to server, but not so well for mobile with
power and bandwidth constraints. In this case, the approach we are taking
for a client to bootstrap from possession of a private key is to send an
RSA signed request to establish a shared HMAC key, then use HMAC signed
requests.

Thanks & regards,

    Blair.

--
Blair Strang | Senior Security Engineer
Covata | Own Your Data
covata.com

Level 4 156 Clarence Street | Sydney NSW 2000
© 2014 CDHL parent company for all Covata entities

On Tue, May 13, 2014 at 4:02 AM, Hannes Tschofenig <
[email-masked]> wrote:

> >> over http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05section 5.2.

---

From: Justin Richer <[email-masked]>
Date: Tue, 13 May 2014 11:27:47 -0400

Blair,

You’re right in that the MAC draft is effectively abandoned now as the WG has moved on to other signed-token mechanisms. As part of that effort, I’ve put together a JWS-based HTTP request signature mechanism (referenced in Hannes’s presentation):

http://tools.ietf.org/id/draft-richer-oauth-signed-http-request-01.html

This differs from the AWS spec (submitted as an HTTP Auth WG Draft, as I understand it: http://tools.ietf.org/id/draft-cavage-http-signatures-02.html) in that it uses JWS as the signing mechanism (without a custom HTTP header format). There’s still a fair amount of work that needs to be done in order to get it in shape, but I think that these different methods can definitely inform each other.

 — Justin

On May 13, 2014, at 2:34 AM, Blair Strang <[email-masked]> wrote:

> Hi Hannnes,
> 
> Yes, so in terms of well-defined specs for HTTP request signing, there is basically AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff which is looking a bit abandoned.
> 
> Looking at the slides you sent, my colleague Scott and I have been working on something running along the same lines. This has largely been for internal use, but we have had our eye on a design with general utility.
> 
> So far we have been working to clearly define *only* how HTTP requests can be authenticated using a JWT/JWS, independent of the issues of key distribution and sessions (an OAuth2 extension is one option for sessions / key agreement, but there are obviously other ways).
> 
> We actually have a spec and proof of concept in progress for JWS based request signing. We do need some time to clean up the spec for public consumption, but would you be interested in seeing that?
> 
> Thanks,
> 
>     Blair.
> 
> Our view is that request authentication (mac/signature) and the session (or key agreement) mechanisms needed to support it are largely orthogonal.
> 
> We have been working to specify a mechanism for authenticating HTTP requests using JWT/JWS. (The tokens look just like JWTs, but it is better to specify on top of JWS).
> 
> Our approach was that the client computes a "signature base string" or "string to sign" in a fashion very similar to AWS v2, while adding header signing similar to that in AWS v4. This fixes a gap in the OAuth 1.0a HMAC token spec. 
> 
> The client then embeds a digest of the "signature base string" in a JWS signed by the client, along with several other required fields (e.g. a field identifying the requestor, optional key id, expiry, list of signed http headers, ...) to authenticate the request.
> 
> The nice thing about embedding the request digest in a JWT/JWS signed payload is that you get all the flexibility of JWS in terms of algorithms. 
> 
> Also, the implementation also comes out very nice, since you need just string processing of the request to get a canonical version plus a digest operation - and the "hard crypto stuff" can be handled by a JWS library. 
> 
> However, there are some constraints in terms of practicality using the JWS standard (not insurmountable, but there):
> 
> 1. RSA - A client with a private key can easily RSA-sign HTTP requests, but the Authorization: header will be several hundred bytes long due to the size of the RSA signature. Speed is high, but so is bandwidth required.
> 
> 2. ECDSA - ECDSA produces much smaller payloads (few hundred bytes) but requires much more processing effort (order of milliseconds).
> 
> 3. HMAC - A shared HMAC key will be the most efficient in terms of speed & storage, but requires additional session establishment dance which is slightly less elegant than a client using a private key directly.
> 
> Request authorisation using a private key directly works well for server-to-server or "big client" to server, but not so well for mobile with power and bandwidth constraints. In this case, the approach we are taking for a client to bootstrap from possession of a private key is to send an RSA signed request to establish a shared HMAC key, then use HMAC signed requests.
> 
> Thanks & regards,
> 
>     Blair.
> 
> --
> On Tue, May 13, 2014 at 4:02 AM, Hannes Tschofenig <[email-masked]> wrote:
> Hi Phil,
> Hi Blair,
>

---

From: Bill Mills <[email-masked]>
Date: Tue, 13 May 2014 08:33:05 -0700 (PDT)

The MAC draft has been idle for a while, the mindshare has been on POP tokens.  Also we haven't had anyone looking to actively adopt a signed HTTP token profile.  You're solving a real problem and have a need for it, so rekindling this in some form would be good.  I've always maintained that we need a signed token type because we have use cases where we use OAuth 1.0a for Flickr and strategically I'd like to get something in the OAuth 2 framework to replace it.

A POP token could include an encrypted HMAC secret, but I'm not sure if the extra decrypt required at the server kills the benefit of the speed of HMAC.

On Tuesday, May 13, 2014 8:16 AM, Blair Strang <[email-masked]> wrote:
 
Hi Hannnes,

Thanks,

    Blair.

---- Long form details below here -----

Thanks & regards,

    Blair.

Hi Phil,

---

From: Prateek Mishra <[email-masked]>
Date: Tue, 13 May 2014 10:42:00 -0700

I hate to be one of these "lets-be-careful" guys, but I do have to point 
out that the AWS documentation and method being referenced is 
proprietary with its all attendant IP issues.

- prateek
> Hi Hannnes,
>
> Yes, so in terms of well-defined specs for HTTP request signing, there 
> is basically AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff 
> which is looking a bit abandoned.
>
> Looking at the slides you sent, my colleague Scott and I have been 
> working on something running along the same lines. This has largely 
> been for internal use, but we have had our eye on a design with 
> general utility.
>
> So far we have been working to clearly define *only* how HTTP requests 
> can be authenticated using a JWT/JWS, independent of the issues of key 
> distribution and sessions (an OAuth2 extension is one option for 
> sessions / key agreement, but there are obviously other ways).
>
> Our view is that request authentication (mac/signature) and the 
> session (or key agreement) mechanisms needed to support it are largely 
> orthogonal.
>
> requests using JWT/JWS. (The tokens look just like JWTs, but it is 
> better to specify on top of JWS).
>
> "string to sign" in a fashion very similar to AWS v2, while adding 
> header signing similar to that in AWS v4. This fixes a gap in the 
> OAuth 1.0a HMAC token spec.
>
> The client then embeds a digest of the "signature base string" in a 
> JWS signed by the client, along with several other required fields 
> (e.g. a field identifying the requestor, optional key id, expiry, list 
> of signed http headers, ...) to authenticate the request.
>
> string processing of the request to get a canonical version plus a 
> digest operation - and the "hard crypto stuff" can be handled by a JWS 
> library.
>
> However, there are some constraints in terms of practicality using the 
> JWS standard (not insurmountable, but there):
>
> 1. RSA - A client with a private key can easily RSA-sign HTTP 
> requests, but the Authorization: header will be several hundred bytes 
> long due to the size of the RSA signature. Speed is high, but so is 
> bandwidth required.
>
> 2. ECDSA - ECDSA produces much smaller payloads (few hundred bytes) 
> but requires much more processing effort (order of milliseconds).
>
> 3. HMAC - A shared HMAC key will be the most efficient in terms of 
> speed & storage, but requires additional session establishment dance 
> which is slightly less elegant than a client using a private key directly.
>
> server-to-server or "big client" to server, but not so well for mobile 
> with power and bandwidth constraints. In this case, the approach we 
> are taking for a client to bootstrap from possession of a private key 
> is to send an RSA signed request to establish a shared HMAC key, then 
> use HMAC signed requests.
>
> Thanks & regards,
>
>     Blair.
>
> --
> covata.com <http://covata.com/>
>
> On Tue, May 13, 2014 at 4:02 AM, Hannes Tschofenig 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Phil,
>     Hi Blair,
>
>     <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>     >> <mailto:[email-masked]
>     <mailto:[email-masked]>>, [email-masked]
>     <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>,
>     [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]>>
>     > [email-masked] <mailto:[email-masked]>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 14 May 2014 10:31:40 +0100

Hi
On 13/05/14 16:27, Justin Richer wrote:
> Blair,
>
> You’re right in that the MAC draft is effectively abandoned now as the
> WG has moved on to other signed-token mechanisms. As part of that
> effort, I’ve put together a JWS-based HTTP request signature mechanism
> (referenced in Hannes’s presentation):
>
+1 to building a JWS-based solution.

IMHO though it is unfortunate that a MAC solution which can make better 
bearer tokens is not looked at right now and thus it is unavoidable that 
people will come up with several new approaches 'fragmenting' the MAC space.

We actually implemented a HAWK scheme as part of the OAuth2 framework, 
it works, very simple, the session key is expected to be exchanged via a 
2-way TLS as part of the grant to token exchange.

I hope OAuth2 will have its own MAC solution ready too, leading to the 
better interoperability in the OAuth2 space

Cheers, Sergey

> This differs from the AWS spec (submitted as an HTTP Auth WG Draft, as I
> understand it:
> http://tools.ietf.org/id/draft-cavage-http-signatures-02.html) in that
> it uses JWS as the signing mechanism (without a custom HTTP header
> format). There’s still a fair amount of work that needs to be done in
> order to get it in shape, but I think that these different methods can
> definitely inform each other.
>
>   — Justin
>
>
> On May 13, 2014, at 2:34 AM, Blair Strang <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Hi Hannnes,
>>