Re: MACing HTTP requests/responses (Re: Content-Integrity header)

On Wed, Jul 11, 2012 at 2:43 PM, Nico Williams <nico@cryptonector.com> wrote:
> I agree that we need something better, and in particular that we ought
> to have a MAC instead of a plain hash.  The problem with a MAC is:
> whence the key?  Also, what should the MAC be applied to?

The MAC should be applied to the 8-bit clean message content (i.e.
precisely that which is bounded by Content-Length)

If we are talking about Web Services then the key would be established
through some application layer key exchange (TBS).

The key requirement from a performance standpoint as I see it is that
the server has to be able to operate in a stateless fashion which
means using a ticket like approach.


> Using a MAC, having a shared session key, ties into HTTP
> authentication.  We can definitely have a generic MAC for HTTP and say
> that HTTP authentication mechanisms that can should output session
> keys.  And the HTTP authentication would also have to take care of MAC
> algorithm negotiation.  I'd be quite happy with this approach.

I think that there is definitely an opportunity to make use of a
ticket mode to tie the HTTP authentication to the HTTP channel.


> One issue with this approach is: if we always use TLS (but we might
> not), why do the extra session crypto?  What do we gain?  Do we need
> to worry about content re-writing proxies, say, as in some 3G
> networks?  If we always use TLS then it suffices to ensure that a) TLS
> provides confidentiality protection, b) the server cert remains the
> same for the length of the login session, c) we have a unique,
> unpredictable session ID in the headers (what we might call a cookie,
> though we don't want it to be a cookie as such).

TLS is very large, very complex and was engineered from the assumption
that there would be public key credentials on the client. Yes, people
can train it to do other tricks, but doing that is a lot more complex
than doing what we need in HTTP.

In my particular Web Service I am using TLS but still want to have a
transport layer authentication protection because I don't want to do a
TLS public key negotiation on each transaction and I don't want to be
bound to TLS session expiry.

In a large commercial environment the TLS processing is often
completely offloaded onto an accelerator that strips out the TLS and
hands clean IP packets to the Web Service. Another frequent screw case
is TLS proxies like bluecoat devices.


But even in the simplest TLS use case, the TLS security context is
really not exposed to the Web Server or the client in the way you
would need to use it for Web Services authentication in the commonly
used APIs. The problem is that TLS is designed to conceal all the
complexity of crypto from the application. That is why it was called
SSL at the start.


> In one post you talked about sequencing and replay protection for
> chunks.  Adding that to the MAC really gets us close to the MIC token
> features/design from RFCs 1964/4121 (Kerberos GSS mech).  We're
> talking about having a sequence number.  As you say: this isn't
> difficult; we've been doing this for a loooong time in Kerberos land.

Heh, you could use a Kerberos token in my Omnibroker protocol if you
wanted to. But since it is an opaque string of bytes as far as the
client is concerned, well there is no reason to tie it to any one
approach.

People have been using kerberized cookies for years. The problem being
that the cookie is not at all bound to the requests or responses.

> Note that there's no need for sequence numbers to randomized given
> that we have session keys, but sequence number windows add to the
> state to be kept on the server side -- can we tolerate that? Note that
> while session key state might be kept on the client in an encrypted
> state ticket, session number windows cannot safely be kept that way --
> they must be kept locally.  I tend to think that sequencing and replay
> protection are the responsibility of the application -- all it needs
> to do is add a sequence number to the chunks and manage its own
> [per-resource] sequence number windows.

The way I was thinking of helping the application was to provide a
feature that allows Content-Integrity header to specify a key modifier
as well as a ticket. The key used to calculate the MAC would then be
the XOR of the modifier and the authentication key associated with the
ticket.


> Altogether we need: a session key identifier in the headers (this
> should imply algorithm selection), a direction identifier (or separate
> keys for each direction), a sequence number if we need sequencing
> and/or replay detection, what content to MAC, and the MAC itself.

Direction is already implicit in HTTP requests/responses.

I don't think we need sequencing, we do need a modifier capability though.

> Regarding what to MAC: the direction flag (unless we have diff keys
> for each direction), the channel binding for the TLS channel (if we
> have it), the URL?, some subset of headers? and the body.  Note that
> applying the MAC to any headers requires that we say something about
> canonicalization (e.g., "use the headers exactly as sent") and
> canonical order (if a subset of headers) (e.g., "in the relative order
> of appearance").  Header and body content need to be unambiguously
> separated in the MAC input.  Obviously we can't MAC all headers: some
> might be added by proxies, for example.

I don't see the need to MAC any headers for a Web Service application.
Put all the information in the content block.

Otherwise we would have to do the sort of thing that DKIM does to sign
headers and copy them.


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

Received on Wednesday, 11 July 2012 23:08:08 UTC