Re: [websec] draft-williams-websec-session-continue-prob-00

[Yoav Nir <[e-mail]>]

Hi James

I've now read your draft. It looks to solve the same kind of problem as PHB's integrity draft [1], although that one currently uses HTTP/1 syntax.

The protocol you propose binds a key to a session (or "KEY-ID") and this allows to integrity protect both requests and responses. It also allows the client to bind specific requests to specific sessions, which is one of the requirements in the session-continue draft. Integrity protection of the requests (an possibly responses) is definitely a key component of any solution to make sessions secure. It doesn't help to authenticate just the fact that there is a request, if we then allow a proxy to rewrite the entire content of the request.

What's missing for me is a binding of that key-id to an authenticated identity. Identities can be authenticated multiple ways. There's the user certificate in TLS, Some better or worse HTTP schemes (everything from Basic to ZKPPs), two-factor methods using some side-channel (such as instant messaging to mobile phones), and even HTTP forms, whether they are the insecure kind we use today or something with browser-based encryption. I think it would be a worthy goal to have all of these bind somehow to the key-id.

The other thing that's missing, but should probably be in a separate document (that I think we're not ready to start yet) is a specification of client behavior, meaning when should the client use the same session id (or "key id") for different requests. For example, if I have gmail open in one browser tab, and in another tab I have a site, where teh HTML says "<img src="mail.google.com/imgs/yellow_arrow.gif<http://mail.google.com/imgs/yellow_arrow.gif>">", should the request to mail.google.com<http://mail.google.com> use the same key id that I am using with GMail?  The one that is bound to my identity? With the current cookie mechanism, the answer is yes. If we define a new session mechanism, we can re-think this.

Yoav
[1] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02

On Jan 14, 2013, at 11:36 PM, James M Snell <[e-mail]<mailto:[e-mail]>> wrote:

Hello,

Just jumped over here from the http list per Yoav Nir's request for feedback with regards to the draft-williams-websec-session-continue-prob draft.

Overall I think the draft is a good start. There definitely does need to be more of an explanation as to why the existing cookie-based mechanism is bad.

As far as more forward looking feedback is concerned, I wanted to point to the In-Session Key Negotiation draft I wrote as input to the ongoing http/2 discussion

  http://tools.ietf.org/html/draft-snell-httpbis-keynego-00

This draft introduces a new (currently experimental) bidirectional key-negotiation sub-protocol within spdy/http2 for the negotiation of secure keys and can be used for the establishment of authenticated and unauthenticated sessions. (Note that I'm just making sure folks know about this draft as it is relevant to the discussion)... Running down through the list of requirements stated by the websec-session-continue-prob draft it covers a good deal of the issues.

- James