Subject: [http-auth] First draft of HTTP Signatures published

From: Manu Sporny <[email-masked]>
Date: Fri, 10 May 2013 14:29:31 -0400

The HTTP Signatures spec is a digital signature mechanism for the HTTP
protocol. It adds origin authentication, message integrity, and replay
resistance to HTTP requests. This is useful for any application that
currently depends on Basic, Digest, OAuth, or OAuth2 authentication when
performing RESTful HTTP calls.

Basically, if a client needs to prove to a server that it sent an
HTTP-based message, it can digitally sign that message. This spec
defines exactly how that happens.

This spec will be used by the Web Payments / PaySwarm / Web Keys work at
W3C. We're going to combine the public/private key-based signature
mechanism defined in HTTP Signatures with the public key infrastructure
system as defined in Web Keys to provide an easy way for nodes on the
Internet to verify their identity to other nodes on the Internet.

The first draft of this spec was just published via the Internet
Engineering Task Force (IETF) earlier today:

http://tools.ietf.org/html/draft-cavage-http-signatures-00

You can also find a datetime-stamped version of the spec here:

https://payswarm.com/specs/ED/http-signatures/2013-05-04/

The latest version of the spec can be found on the PaySwarm specs page:

https://payswarm.com/specs/

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 May 2013 03:37:12 +0000

Hi Manu

The HTTP-Auth working group is chartered to work on a very specific set of documents. OTOH, the WebSec working group is considering adopting a work item for session continuation. Session continuation is supposed to be a replacement for authorizing requests via session cookies. See the problem statement here:

http://tools.ietf.org/html/draft-williams-websec-session-continue-prob-00

If I understand correctly, your draft is aiming to solve that issue. So you might prefer to take your draft there.

Yoav Nir (as co-chair of both groups)

On May 10, 2013, at 9:29 PM, Manu Sporny <[email-masked]> wrote:

> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
> 
> Email secured by Check Point

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 May 2013 14:22:28 +0100

Yoav,

> If I understand correctly, your draft is aiming to solve that issue. So you might prefer to take your draft there.

Fair points. But I do think some discussion of the differences between
Manu's proposal and HOBA on this list might be beneficial before any
conclusion as to IETF WG venue etc are reached.

In  addition I think Manu regards his scheme as a primary user
authentication scheme and not as a session continuation scheme which
again argues for discussing it here.

The above discussion will be more useful when we've posted the rev
of HOBA, which will be in the next few days.

Cheers,
S. (as participant, of course;-)

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 May 2013 15:04:43 +0000

Works for me, especially since WebSec is still a long way from deciding to work on session continuation/management.

Yoav

---

From: Manu Sporny <[email-masked]>
Date: Sun, 12 May 2013 14:15:44 -0400

On 05/11/2013 11:37 PM, Yoav Nir wrote:
> The HTTP-Auth working group is chartered to work on a very specific
> set of documents. OTOH, the WebSec working group is considering
> adopting a work item for session continuation. Session continuation
> is supposed to be a replacement for authorizing requests via session
> cookies. See the problem statement here:
> 
> If I understand correctly, your draft is aiming to solve that issue.
> So you might prefer to take your draft there.

Session management is out-of-scope for the HTTP Signatures spec. It's
true that a session management scheme could be built on top of HTTP
Signatures, but that is a second step. We know that many others are
working on session management right now, and would rather they see if
HTTP Signatures could be useful for them rather than try to shove
session management capabilities into HTTP Signatures.

The HTTP Signatures spec is a fairly simple, straightforward spec as-is.
We'd like to keep it that way. :)

-- manu

---

From: Manu Sporny <[email-masked]>
Date: Sun, 12 May 2013 14:17:43 -0400

On 05/12/2013 09:22 AM, Stephen Farrell wrote:
> Fair points. But I do think some discussion of the differences
> between Manu's proposal and HOBA on this list might be beneficial
> before any conclusion as to IETF WG venue etc are reached.

Agreed.

> again argues for discussing it here.

It's Mark Cavage's scheme. I just happen to believe that it's brilliant
and am willing to put in the time to push it forward in a standards
community. :)

> The above discussion will be more useful when we've posted the rev of
> HOBA, which will be in the next few days.

Looking forward to it. :)

-- manu

---

From: Manu Sporny <[email-masked]>
Date: Sun, 12 May 2013 14:24:18 -0400

On 05/12/2013 11:04 AM, Yoav Nir wrote:
> Works for me, especially since WebSec is still a long way from 
> deciding to work on session continuation/management.

As an aside, the other option is to just do the work at the W3C. I could
fold it into the newly forming Web Payments WG fairly quickly and get it
to REC that way as well (if it's too much of a burden to do it via IETF).

In the end, it doesn't really matter which organization can figure out
how to do the work, as long as we can get it vetted, stabilized, and
published so that implementers can start implementing it more widely.

Keep in mind that we have two organizations that have already
implemented and vetted the specification and are running it in
production: Joyent (corporate stewards of node.js) and Digital Bazaar
(corporate stewards of PaySwarm).

-- manu

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 13 May 2013 11:55:35 +1000

Comments on draft-cavage-http-signatures-00:

1.
Content-Length in the example in section 2.1.2. "Signature String Construction" should be 14, not 15. The content-MD5 value is calculated over 14 bytes.

2.
The string to be signed (section 2.1.2. "Signature String Construction") looks like lines that could be sent in the HTTP request, but they don’t quite match. Lines in an HTTP header end with \r\n, whereas lines in the string to be signed end in \n.

Why bother omitting \n from the last line? It is simpler to end all the lines the same way. It is annoyingly awkward to write files with a text editor that omit a final \n.

3.
The signature is wrong in section 4.1. "Default Test". Unpacking the signature reveals a SHA-256 hash of EBF002A95EC4DDB7A50CCAC009BAA2FE5D1B2604DA7CB871B870CEE21BE85EB9. The SHA-256 has of "date: Thu, 05 Jan 2012 21:31:40 GMT" is 1958B656C09E29824A2BCF03197923BCD9B55370F2FF2118FF4C47AD77513B3F.

4.
The signature is wrong in section 4.2. "All Headers Test". Unpacking the signature reveals a SHA-256 hash of 4E7A038BC9EFAB95AC829AC176659DCE0A7B6DC94F9FAA54375390A5EA8A9B37. The SHA-256 has of all the headers is 1015528C71F9BC3D445B457CA41D8BC884E89275EDDD0F0435BBB13A65B4550D.

5.
The fields that are signed are absolutely crucial in determining the security properties achieved. It is not sufficient for the spec to merely say the choice of fields is "out of scope" in a clause of the "Security Considerations" (section 3.5 "Required Headers to Sign").
The introduction needs to state that: the mechanism signs a *subset* of an HTTP request; recipients need to be pre-configured with the subset they require (and MUST confirm that "headers" includes at least that subset); the body is only protected if a Content-MD5/Digest is signed (and the body hash is checked). Signing just "date" show the originator committed to one HTTP request at about the time of the date value, but gives no protection as to the nature of that request (the query params, path, method, body, or even host etc). One strategy for recipients would be to only pass signed fields on to the next stage of request processing.

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Manu Sporny
> Sent: Saturday, 11 May 2013 4:30 AM
> To: HTTP Auth WG
> Subject: [http-auth] First draft of HTTP Signatures published
> 
> currently depends on Basic, Digest, OAuth, or OAuth2 authentication
> when performing RESTful HTTP calls.
> 
> Basically, if a client needs to prove to a server that it sent an HTTP-
> based message, it can digitally sign that message. This spec defines
> exactly how that happens.
> 
> This spec will be used by the Web Payments / PaySwarm / Web Keys work
> at W3C. We're going to combine the public/private key-based signature

---

From: Mark Cavage <[email-masked]>
Date: Mon, 13 May 2013 10:02:31 -0700

Hi James,

> Content-Length in the example in section 2.1.2. "Signature String Construction" should be 14, not 15. The content-MD5 value is calculated over 14 bytes.

Nice catch, thanks.

> The string to be signed (section 2.1.2. "Signature String Construction") looks like lines that could be sent in the HTTP request, but they don’t quite match. Lines in an HTTP header end with \r\n,…

FWIW, I didn't do \r\n simply because most client libraries (and
developers) understand '\n' as the default.  So thinking of it from
the perspective of the average SDK and engineer, it seemed easier on
people to be only \n.  That said, I'm not really willing to go to the
mat for this one :), so if anybody else agrees \r\n is better, we can
change it.

> Why bother omitting \n from the last line? It is simpler to end all the lines the same way. It is annoyingly awkward to write files with a text editor that omit a final \n.

Because in lots of dynamic languages this is what a "join" call does.
I.e., in Javascript: ['a', 'b', 'c'].join('\n') produces 'a\nb\nc'.
Nobody is going to create the canonicalized string with a text editor,
they're going to do it with code.   Again, I came at this with the
perspective of "what's the easiest to write code for."  This one I'm
less convinced adding a trailing \n (or \r\n) makes anybody's life
easier, simply because the semantics of "sort | join" code in almost
every toolkit is to not have a trailing separator.

> The signature is wrong in section 4.2. "All Headers Test". Unpacking the signature reveals a SHA-256 hash of 4E7A038BC9EFAB95AC829AC176659DCE0A7B6DC94F9FAA54375390A5EA8A9B37. The SHA-256 has of all…

Thanks, there was a rev of the spec based on a security vulnerability
in the original original version, and the examples are still using the
old strings.  Will fix.

> The introduction needs to state that: the mechanism signs a *subset* of an HTTP request; recipients need to be pre-configured with the subset they require (and MUST confirm that "headers" includes…

Yes agreed, we can crisp this up in both the introduction and security
considerations, and add in some more examples with explanations of
"policy choice" for the recipient.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 13 May 2013 13:09:46 -0400

Hi Mark,

I will second the suggestion made by Cyrus Daboo on this list a few 
weeks ago:

> That draft is very similar to the approach we have used in iSchedule 
> (<https://datatracker.ietf.org/doc/draft-desruisseaux-ischedule/>) - 
> which is an HTTP-based calendar and scheduling messaging protocol. We 
> choose to re-use existing email signing technology - DKIM 
> (<http://tools.ietf.org/html/rfc6376>) - primarily because the 
> security model and key management were a good fit for our application. 
> There is also the benefit of code re-use, and working with a protocol 
> that is already deployed and used heavily in the email environment. 
> Also, DKIM was designed with the prospect of being applicable to 
> protocols beyond email technology - and I think with iSchedule we have 
> proven it can work with HTTP. I would definitely urge you to take a 
> serious look at DKIM. There are a number of interesting features there 
> that don't seem to have been addressed in the draft you cited. In 
> particular dealing with both header and body canonicalization (headers 
> are particular problem in HTTP due to intermediaries, caches etc). 

On 05/13/2013 01:02 PM, Mark Cavage wrote:
>>> From:[email-masked]  [mailto:[email-masked]] On
>>> Behalf Of Manu Sporny

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 May 2013 09:57:11 -0400

HTTP Session Continuation is a separate spec but I would like to share as
much as possible between them.

http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt

Early versions of the session continuation mechanism included header
signing. That is a real headache. The only way that I think it can be made
to work reliably is to duplicate the information that you want to sign into
the signing header which is the approach in DKIM.

For HTTP transactions, the only headers that I think should ever be signed
are content meta-data. The reason signing is hard in SMTP and HTTP is that
there is a huge confusion between headers used for routing and headers that
are properly part of the content. This is perhaps a change that could be
made in HTTP/2.

You will find a lot of objections being made of the form 'this will break
when intermediaries change content'. And they will continue to be made no
matter how many times you point out that detecting changes to the content
and rejecting that transaction is the whole objective. So there will need
to be some statement to the effect that the intended behavior is to prevent
all types of content modification.

We don't yet know what the effect of intermediaries is on the request line
and I suspect that as we get into tests we are going to discover that we
have to do some form of canonicalization. For example, I strongly suspect
that we are going to want to combine the Host-Name header and http method
into the request line to make it a canonical url.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 May 2013 10:39:13 -0400

>>>>> "Phillip" == Phillip Hallam-Baker <[email-masked]> writes:
    Phillip> You will find a lot of objections being made of the form 'this will break
    Phillip> when intermediaries change content'. And they will continue to be made no
    Phillip> matter how many times you point out that detecting changes to the content
    Phillip> and rejecting that transaction is the whole objective. So there will need
    Phillip> to be some statement to the effect that the intended
    Phillip> behavior is to prevent 
    Phillip> all types of content modification.

And maybe we need to provide a way for intermediaries to signal their
existence, and for a transitive (but decentralized) trust model to
permit their inclusion.   My impression is that this has worked well in
SIP, although I am aware that it has also thwarted S/MIME-type security
solutions in SIP.

    Phillip> We don't yet know what the effect of intermediaries is on the request line
    Phillip> and I suspect that as we get into tests we are going to discover that we
    Phillip> have to do some form of canonicalization. For example, I strongly suspect
    Phillip> that we are going to want to combine the Host-Name header and http method
    Phillip> into the request line to make it a canonical url.

"http method", as in GET/PUT/POST/DELETE? (Just asking for
clarification)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 May 2013 11:00:00 -0400

> SIP, although I am aware that it has also thwarted S/MIME-type security

That might be useful. But right now I am focused on making sure that bad
things do not happen.

If an intermediary corrupts a message that is a Web Services transaction
message then my desired outcome is that the transaction is aborted. People
keep telling me that it is a requirement to allow random proxies that have
no idea what the Web Service is doing to make random changes to transaction
messages and that the protocol should still work.

If the intermediary is a party to the transaction, that is a totally
different situation.

> "http method", as in GET/PUT/POST/DELETE? (Just asking for

Sorry, the scheme. The method is already in the request line.

-- 
Website: http://hallambaker.com/

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 16 May 2013 23:52:24 +0300

> http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt
 
Regarding session continuation, since many of the proposed authentication
schemes don't seem to have multi-request authentication, should there be
some mechanism to couple authentication into session?

Obviously, how to derive shared secret from authentication is method-
specific, and some methods (e.g. mutual) can yield stronger secrets than
others (e.g. SCRAM), and some can't yield one at all (e.g. Basic).

I note that HOBA spec calls to use cookies (blech). I haven't yet figured
out how mutual deals with concept of "session".

Oh, and I don't think "Just use TLS" really cuts it...

-Ilari

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 May 2013 21:57:43 +0100

On 05/16/2013 09:52 PM, Ilari Liusvaara wrote:
> I note that HOBA spec calls to use cookies (blech).

Yep. But that's because we're aiming to be an easy drop-in
replacement for Basic or web forms. If PHB's session
continuation thing or some equivalent took off, that'd be
great IMO. Bearer tokens are just dangerous.

Cheers,
S.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 May 2013 14:07:53 -0700

> great IMO. Bearer tokens are just dangerous.

More to the point, hoba isn't trying to do anything on the session
continuation front. It mentions cookies because they're pervasive
and HOBA ought to work with them -- or any other session continuation
technique.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 May 2013 07:48:02 -0400

I don't see any reason for the session continuation mechanism to vary
across credential presentation mechanisms. The aim is to have one
continuation mechanism that all the authentication schemes can adopt rather
than proposing slightly different ones.

At root a session continuation mechanism is going to have two key pieces of
information, the session identifier and the secret key. The draft is
designed to support HTML Forms and other legacy mechanisms that don't know
about continuation and so it describes a mechanism to establish the tokens
in HTTP headers.

But there is no reason why HOBA or whatever can't generate the session
identifier and key by themselves. In fact that is exactly what I am doing
in Omnibroker where I generate the session identifier and key using a
connection maintenance Web Service. I'll try to spin that out as a separate
draft since it is a fairly general problem that could be re-used often.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 17 May 2013 23:44:09 +0300

> than proposing slightly different ones.

Well, the idea I had was roughly:

Have an optional mode (server-initiated) where both sides do:

real_session_secret = HMAC-X(shared_secret_from_auth, session_secret_on_wire)

But perhaps this is a bad idea, simpler and sufficient being server being able
to signal implicit session secret (real_session_secret=shared_secret_from_auth).

Then various auth schemes specify how to derive shared_secret_from_auth.

Threat model obviously involves connection (TLS or not) being MITM'd...

Yeah, wouldn't amount to much with schemes like scram or digest, but HOBA or
mutual could do much better at this.

-Ilari