- From: Nico Williams <nico@cryptonector.com>
- Date: Wed, 11 Jul 2012 13:43:27 -0500
- To: Phillip Hallam-Baker <hallam@gmail.com>
- Cc: ietf-http-wg@w3.org
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