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 protected]> 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
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 protected]>
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 <[email protected]
>>> <mailto:[email protected]>>
>>> *Date:* May 8, 2014 at 18:47:58 PDT
>>> *Resent-To:* [email protected]
>>> <mailto:[email protected]>, [email protected]
>>> <mailto:[email protected]>, [email protected]
>>> <mailto:[email protected]>, [email protected]
>>> <mailto:[email protected]>
>>> *To:* [email protected]
>>> <mailto:[email protected]>
>>> *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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
