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 <blair.str...@covata.com> 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 > <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-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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
