Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02

[Nicolas Williams <[e-mail]>]

On Tue, Jul 14, 2009 at 08:08:32PM -0400, Hollenbeck, Scott wrote:
> Doesn't TLS provide protections for this issue?

Provided you authenticate the server, yes.

>  -----Original Message-----
> From: 	Sandy Murphy [mailto:[e-mail]]
> Sent:	Tuesday, July 14, 2009 07:15 PM Eastern Standard Time
> To:	[e-mail]; [e-mail]; [e-mail]; [e-mail]; Hollenbeck, Scott
> Subject:	Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02
> 
> >A secure authenticThe tie is what is called channel binding.
> 
> OK, obvious blip here.
> 
> A secure authenticated transport connection is established between
> 10.1.0.0 to the other end where the login is being attempted, say
> 10.2.0.0.
> 
> The trouble is that that 10.2.0.0 might be a man in the middle.
> The MITM has another secure authenticated transport connection to
> Bob's host, 10.3.0.0.

If the channel authenticates the server, then there can be no MITM
(assuming the channel's security is not broken).

> Bob sends the "login Bob bobscleartextpassword" over its secure
> transport connection, which ends at the MITM at 10.2.0.0.
> 
> The MITM retransmits the "login Bob bobscleartextpassword" over the
> secure transport connection to 10.1.0.0, impersonating Bob.
> 
> This is possible because there is no tie between the EPP ID of "Bob"
> and the secure transport id of 10.2.0.0.
> 
> The tie is what is called channel binding.

If the channel does not authenticate the server, then yes, you have this
problem, and channel binding is one way to solve it.  But any
authentication mechanism that depends on sending a password in cleartext
(or cleartext equivalent) cannot be used with channel binding.  The
other solution is to have the channel authenticate the server.

> You can look at RFC5056 for more information or at 
> http://www.saunalahti.fi/~asokan/research/mitm.html for another
> discussion with a rather detailed example for PEAP.
> 
> It might be worth pointing out that draft-ietf-sasl-gs2-14 talks
> about Using GSS-API Mechanisms in SASL, and supports channel binding.

I don't know anything about EPP, but it may very well be the case that
an open set of authentication mechanisms would be useful to have in EPP,
in which case I'd recommend SASL or the GSS-API.  Where authentication
mechanisms are used that support channel binding then channel binding
should be used: it allows you to use anon-anon channels, it allows you
to not worry about the strength of authentication infrastructures for
the channels, and it allows you to not have to worry about making sure
that the server ID is equivalent in the channel as in the authentication
mechanism.

Nico
--