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

[Sergey Beryozkin <[e-mail]>]

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):
>
> http://tools.ietf.org/id/draft-richer-oauth-signed-http-request-01.html
>
+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 <[e-mail]
> <mailto:[e-mail]>> 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.
>>
>> 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 <http://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
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     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 <[e-mail]
>>     <mailto:[e-mail]>
>>     >> <mailto:[e-mail] <mailto:[e-mail]>>>
>>     >> *Date:* May 8, 2014 at 18:47:58 PDT
>>     >> *Resent-To:* [e-mail]
>>     <mailto:[e-mail]>
>>     >> <mailto:[e-mail]
>>     <mailto:[e-mail]>>, [e-mail]
>>     <mailto:[e-mail]>
>>     >> <mailto:[e-mail] <mailto:[e-mail]>>,
>>     [e-mail] <mailto:[e-mail]>
>>     >> <mailto:[e-mail] <mailto:[e-mail]>>,
>>     [e-mail] <mailto:[e-mail]>
>>     >> <mailto:[e-mail] <mailto:[e-mail]>>
>>     >> *To:* [e-mail]
>>     <mailto:[e-mail]>
>>     >> <mailto:[e-mail]
>>     <mailto:[e-mail]>>
>>     >> *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.
>>     >>
>>     >
>>     >
>>     > _______________________________________________
>>     > OAuth mailing list
>>     > [e-mail] <mailto:[e-mail]>
>>     > https://www.ietf.org/mailman/listinfo/oauth
>>     >
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>