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

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Jan 2013 17:05:31 +0000

Hi

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. 

- The document is missing a list of deficiencies with using Cookies

- Section 2.1 says that TLS protects against replay. Really?  How? It doesn't have a protected counter like IPsec.

- 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.

Nit: HTTP is HyperText **Transfer** Protocol, not **Transport*.  This one is already fixed in Nico's repository.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Jan 2013 10:18:16 -0600

> - 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

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.

> - 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 :)

> - 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 authenticat…

If we can make that work securely, then yes.

> 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
--

---

From: Yoav Nir <[email-masked]>
Date: Fri, 18 Jan 2013 06:18:38 +0000

> - draft-williams-http-rest-auth

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.

> FWIW, I was under a hard deadline when i submitted the -00.

OK. Next deadline is 25-Feb.

> individual records then it's got replay protection :)

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

> 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.

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
> 
> Email secured by Check Point