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

[James M Snell <[e-mail]>]

On Tue, Jan 15, 2013 at 6:04 AM, Yoav Nir <[e-mail]> wrote:

>  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.
>
>
There is definitely overlap in the use of the integrity frame. Once http/2
is down the road a bit and I see how things evolve there I hope to work
with PHB to reconcile the two mechanisms.


>  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.
>
>
Correct.. the original use case for my spec was for key negotiation for
encryption of individual spdy frames and establishment authenticated
credentials. It can, however, be leveraged for a broader set of cases but
there are certainly details that would need to be ironed out (not the least
of which is how these manifest within the http/2 framing layer which is
going to take quite some time to figure out)


>  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.
>
>
Agreed. That's something I'll be looking at. The keynego frames themselves
allow for a range of protocols for establishing a key, and multiple keys
can be negotiated for a single session. For instance, we can have a keynego
exchange that authenticates both the client and servers identities and
establishes a shared secret key that is then used to encrypt the individual
frames in the stream. Again tho, this is very preliminary and there are
many details to work out. At this step, I largely just wanted to make sure
people were aware of the draft as the discussion moves forward.


>  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">", should the request to
> 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.
>
>
Agreed.

- James


>  Yoav
> [1] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02
>
>  On Jan 14, 2013, at 11:36 PM, James M Snell <[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
>
>
>