I guess I could replace the 'Set-Session' mechanism that I set out in my session continuation draft with a scheme that encodes the same information as Set-Cookie attributes. That would then mean that a browser that knows how to do Macs on the session cookie can do so and those that don't will simply send the cookie back and forth as per usual.
It has nice backwards compatibility properties. On Mon, Jul 22, 2013 at 4:02 AM, Trevor Perrin <[email protected]> wrote: > Hi, > > Here's an attempt to combine the benefits of a couple cookie > proposals. I'm curious what people think... > > > "Smart cookies" > ============= > > Rationale > ---------- > The "Origin Cookie" proposal seems a good solution to cookie scoping. > The "ChannelID" proposal seems a good approach to the "bearer token" > problem, but requires on-the-wire TLS changes and a client signature > for all TLS connections. > > Smart cookies combine the benefits of both proposals, and don't > require TLS changes or client signatures. > > Smart cookies are bound to the Origin, and cannot be read or written > from other Origins. Smart cookies are also cryptographically bound to > two TLS connections: > 1) The TLS connection on which the server set the cookie > 2) The TLS connection on which the client is returning the cookie > > This binding is done by a cryptographic "MAC" sent from browser to > server along with each smart cookie. > > > The "smart" attribute > ---------------------- > Smart cookies are set the same way as normal cookies, but have an > additional "smart" attribute: > > Set-Cookie: session=123; secure; smart; > > Smart cookies SHALL only be set from HTTPS connections. The "domain" > attribute MUST be omitted, and the "secure" attribute MUST be present. > > Smart cookies are backwards-compatible. Older browsers ignore the > "smart" attribute, and return it as a regular cookie. A smart cookie > aware browser does two extra things: > > (1) The smart cookie is bound to the Origin that set it. The smart > cookie is only returned to that Origin. The smart cookie can only be > overwritten by that Origin. If a smart cookie is being returned, any > cookies with the same name stored in parent domains are ignored. > > (2) When returning a smart cookie, the browser returns an associated MAC, > e.g. > > Cookie: session=123 > Smart-Cookie-MAC: session=lMVoh17EQNE1Rd6nT+hh6A== > > > MAC calculation > ---------------- > The MAC is calculated as follows: > > - cookie_str: HTTP Request line for cookie ("Cookie: session=123") > - cookie_key: 32 byte secret key derived from the TLS master secret > for the connection on which the server sent the cookie. > - cookie_binding: 32 byte value derived from the TLS master secret > for the connection on which the client is returning the cookie. > > (The key and binding values are derived using RFC 5705 with labels > "smart_cookie_key" and "smart_cookie_binding".) > > MAC = HMAC-SHA256(cookie_key, cookie_binding || cookie_str)[0:16] > > > Key handling > ------------- > The browser can easily calculate the key and binding values for every > TLS connection. For every smart cookie the browser receives in a TLS > connection, the browser stores the connection's cookie_key with the > cookie. For every smart cookie returned to the server in a TLS > connection, the browser uses the cookie's key along with the > connection's binding value to calculate the MAC. > > The cookie_key values are secrets which the browser MUST never send > over the network, or make accessible to javascript. > > > Advertising support > -------------------- > Browsers MUST advertise support for smart cookies in every HTTP > Request with "Smart-Cookies: true". This lets the website allow > legacy clients to use old cookies, while requiring smart cookies for > capable clients so they are protected from cookie forcing. > > > Misc > ----- > * A website can have stateless smart cookies by including the > cookie_key in the cookie, and encrypting the cookie to itself. On > receiving such a cookie, the website will decrypt it, then check its > MAC. > * A website could ignore the MAC values, and just use smart cookies > for their origin-binding properties. > * An attacker who somehow observes a transmitted smart cookie and MAC > can't replay it on a different TLS connection (as it's tied to its > connection's binding value), and can't calculate the MAC for a > different connection without the cookie_key. > > > Trevor > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
