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
<hannes.tschofe...@gmx.net <mailto: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>
>> <mailto: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>
>> <mailto:hannes.tschofe...@gmx.net
<mailto:hannes.tschofe...@gmx.net>>, jric...@mitre.org
<mailto:jric...@mitre.org>
>> <mailto:jric...@mitre.org <mailto:jric...@mitre.org>>,
phil.h...@yahoo.com <mailto:phil.h...@yahoo.com>
>> <mailto:phil.h...@yahoo.com <mailto:phil.h...@yahoo.com>>,
wmi...@yahoo-inc.com <mailto:wmi...@yahoo-inc.com>
>> <mailto: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>
>> <mailto: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 <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
