Subject: [http-auth] HTTP Integrity Header

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 19 Oct 2012 23:23:31 -0400

I have a very, very minimal approach to HTTP Authentication. There are two
parts to the description. Part 1 is now complete, this describes my
proposal for a HTTP Integrity header.

http://tools.ietf.org/html/draft-hallambaker-httpintegrity-01

Part 2 is currently largely in my head but I am working on completing a
second draft which explains the rationale.

The basic idea here is that there are two parts to an authentication
scheme. One part is all the mucking about establishing keys and
identifiers. That has a lot of complexity and there is a lot of need for
variation. In particular the needs of user authentication and Web Service
authentication are very different. There is also a need to engage with and
interact with a huge amount of legacy.

When I look at that problem I conclude that it is not going to be a one
size fits all solution, there will be multiple solutions meeting different
needs. We are not even going to get everyone to agree on a single
framework. It also looks to me to be a problem that is at a different layer
to HTTP. It is out in Web Service or HTML space.

The second problem is how those keys and algorithms and such are applied to
parts of HTTP messages (e.g. the content) and how the resulting
authentication value (MAC, digital signature, etc.) is bundled into the
HTTP space.

Now that is a problem that I think can be addressed in HTTP with a great
deal of generality. And that is what the integrity header does.

This is an example of the header being used in a real Web Service example.

Host: example.com
Cache-Control: no-store
Content-Type: Application/json;charset=UTF-8
Content-Length: 78
Integrity: content=true;
    value=cjkMkfnnYP8JYWZAbRLvtpqImmOK3rsrOT1XcvAgHDk=;
    id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
      j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
      oB29dgs/ei6ieINZtmvXNCm2NUkWA==

{
"TicketRequest": {
"ChallengeResponse": "TctLOG74cwpm26YNpEibcQ=="}}

Note that what we are achieving here is remarkably close to what SOAP plus
WS-Security are meant to do but with a dramatic reduction in complexity.
And only a little of that comes from using JSON instead of XML.
Specifically we avoid the need for:

1) XPATH The scope of the authentication is the HTTP content.

2) Canonicalization: The bits authenticated are the same bits that the
application would see after chunked encoding (or other transfer encoding)
is stripped out.

3) Transformation: There is no need to embed the signature inside an XML
anything because the MAC value goes in a slot that is completely separate
from the data we are signing and is not going to be confusealized.

4) WS-Security: All those options go poof.

5) SOAP: Not needed, the only need for SOAP in most Web Services is to have
a slot for the WS-Security info anyway.

6) Algorithm identifiers: Those are not something that HTTP needs to
understand. They are present in the above message but they are opaque to
the HTTP layer which does not need to understand them.

7) Certificate Paths etc.: Again they can be used but they don't belong at
the HTTP layer. They would be part of SAML or OAUTH or OpenID which might
be leveraging this header as a better way to bind the authentication token
to the HTTP transport than stuffing it into a cookie and hoping that BEAST
or CRIME type approaches can't extract it.

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