Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance

[Marsh Ray <[e-mail]>]

Yoav Nir wrote:
> 
> Even that can be further refined. You can freely renegotiate an
> authenticated session, as long as the renegotiation does not involve
> an identity change.

Maybe. What about cases where the sessions are "authenticated" from the
perspective of TLS, but the higher-layer protocols stack on additional
notions of identity?

I seem to recall systems (MS Terminal Services Gateway perhaps?) where a
common client cert is used simply to grant basic access, then some form
of HTTP authentication is used to authenticate which user it is.

TLS does not necessarily know the full extent of "identity" attributed
by higher layers, so you would be allowing any party that can pass the
TLS level auth to MITM the others.

For example, a browser may have several connections to the same set of
servers behind https://ecommerce.example.com/, but you still wouldn't
want to allow a bad guy on one to splice channels between them.

> Obviously, if the first handshake include client authentication, any
> renegotiation that includes the same client cert is fine.

I disagree, I think it subtly violates the assumption of continuity over
the TCP connection.

> If the session is authenticated by the application (as in an HTTPS
> login page) it's also possible to renegotiate with impunity,

Renegotiation (in the absence of draft-rescorla-tls-renegotiate) offers
a point which allows anyone who can pose as one of the parties (perhaps
an anon) to splice in a connection from a third party to the one he is
posing.

This is bad, the HTTPS client-cert renego case.
   A---+---B
   C---+
A-Anonymous Alice
B-Bob
C-Client cert authenticated

These are also bad:

   A---+---B  C---+---B      +---A2 (requires buggy client)
   A---+      C---+      A---+---B

This violates core assumptions even if the same name or "anonymous"
appears at each end of the multiple sessions at play.

- Marsh