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

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?

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.

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).

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.
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.

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.

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.

Nico
--

Received on Wednesday, 11 July 2012 18:43:55 UTC