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 < hannes.tschofe...@gmx.net> 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 <blair.str...@covata.com > >> <mailto:blair.str...@covata.com>> > >> *Date:* May 8, 2014 at 18:47:58 PDT > >> *Resent-To:* hannes.tschofe...@gmx.net > >> <mailto:hannes.tschofe...@gmx.net>, jric...@mitre.org > >> <mailto:jric...@mitre.org>, phil.h...@yahoo.com > >> <mailto:phil.h...@yahoo.com>, wmi...@yahoo-inc.com > >> <mailto:wmi...@yahoo-inc.com> > >> *To:* draft-ietf-oauth-v2-http-...@tools.ietf.org > >> <mailto:draft-ietf-oauth-v2-http-...@tools.ietf.org> > >> *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-05section 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
