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

On Jan 17, 2013, at 6:18 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Mon, Jan 14, 2013 at 17:05, Yoav Nir <ynir@checkpoint.com> wrote:
>> I've shown this draft to a co-worker of mine (not on this list), and asked for a review. Here's some comments:
>> 
>> - Overall, this is an interesting problem.
> 
> There's been quite a few proposals now to solve it all before we
> identified this as worth treating as a problem separate from others:
> 
> - draft-hammer-oauth-v2-mac-token
> - draft-hallambaker-httpintegrity
> - draft-williams-http-rest-auth
> - and several others

Yes, but those are not all solving the same issue. Some are for user authentication while others are for per-request MAC. You might be able to delegate either or both of these functions to the TLS layer (if present), so there's a lot of variation here.

> There's also been a number of recent mentions of this in the context
> of CRIME in the HTTPbis WG list.
> 
>> - The document is missing a list of deficiencies with using Cookies
> 
> Well, for me CRIME is enough :)  But sure, I'll flesh that out a bit.
> FWIW, I was under a hard deadline when i submitted the -00.

OK. Next deadline is 25-Feb.

>> - Section 2.1 says that TLS protects against replay. Really?  How? It doesn't have a protected counter like IPsec.
> 
> If you try to replay a handshake it won't work: the server will almost
> certainly pick different nonces and, if relevant, DH keys, so the
> Finished message exchange will fail.
> 
> If you try to replay a TLS record layer message... TLS will detect
> that too because of its use of sequence numbers.  See RFC5246, search
> for "sequence"; see section 6.2.3 in particular.  Search also for
> "replay".  This is also true of DTLS.
> 
> If you can neither replay handshakes, entire connections, nor
> individual records then it's got replay protection :)

You're right. I forgot about the seq_num field.

>> - Will the resulting protocol support a transition from authenticated session to authenticated session for purposes such as re-authenticating after a specified time, or moving from weak authentication to strong authentication for high-value transactions.
> 
> If we can make that work securely, then yes.

I think it can be done. You can have a key for the unauthenticated session, that's either secure (D-H or TLS extractor without a MitM) or insecure (server assigns a key). Then you can mix in the key with the calculation of the key to the authenticated session. In the insecure case, an attacker could authenticate and continue someone else's session, but they can only do it once, since calculating a new key would invalidate the old key. So someone could hijack your amazon.com shopping cart right before the checkout. Come to think of it, this attack could be mounted physically at a supermarket, but in either case, it's pretty low-value.

>> Nit: HTTP is HyperText **Transfer** Protocol, not **Transport*.  This one is already fixed in Nico's repository.
> 
> There were some instances of one and some of the other.  It was just
> me being sloppy as I hurried to meet a hard deadline.
> 
> Thanks!
> 
> Nico
> --
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
> 
> Email secured by Check Point