On Monday 10 December 2007 11:33 am, Tony Finch wrote: > On Mon, 10 Dec 2007, Justin Karneges wrote: > > I don't understand this talk about the SASL negotiation being attacked by > > a MITM when it is taking place over TLS. There is brief mention of Bob > > possibly not having a certificate or Alice not trusting Bob's CA. Does > > this mean the channel binding problem only affects > > anonymous/unauthenticated TLS? > > From the client's perspective, yes. However in normal SASL-over-TLS > scenarios the client is not authenticated to the server by TLS - after > all, that's why you are doing SASL. So the server wants to be sure that it > is talking directly to the client that it is authenticating, so it uses > channel binding to force the authentication to fail if the client is > bogus. The key is that you can't be sure that you have proper *mutual* > authentication if the privacy layer isn't bound to the authentication > layer.
Hmm.. This would indicate a security hole in almost all uses of HTTPS. Usually the server (e.g. a bank) is authenticated with TLS, and then the client authenticates itself using an HTML form over the TLS connection. However, the HTML form auth (usually some plaintext mechanism) is not "bound" to TLS. Is this really a problem? Charlie can't login as Alice: Charlie <--- TLS ---> Bob (Charlie doesn't have Alice's credentials to use in the HTML form.) Charlie can't MITM attack: Alice <--- TLS ---> Charlie <--- TLS ---> Bob (Alice initiates TLS, doesn't get Bob, and so she rejects the session. The second TLS channel between Charlie and Bob has no relevance.) Where's the problem? Is it that Alice might stupidly (or maliciously?) confuse Bob into thinking Charlie is her, by passing her credentials through Charlie even though Charlie is not Bob? That's a wholly different problem IMO. -Justin
