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

And now, to correct what I said below.

The intent was to convey the difficulty of MITM when you don't bind the 
ID the application is using to the secure transport.

As 5056 says:

    There may well be an MITM, particularly if either the lower network
    layer provides no authentication or there is no strong connection
    between the authentication or principals used at the application and
    those used at the lower network layer.

But my example leaves the impression that the binding is to the identity 
exchanged in the sasl exchange.  It isn't.  It would be to the ID EPP uses 
to identify the other end of the EPP connection.

Someone who knows this subject better than I would probably be of more use 
explaining things here.

--Sandy

On Wed, 15 Jul 2009, Sandra Murphy wrote:

> (I sent multiple secdir related messages yesterday that were mangled or 
> failed to deliver to the secdir and iesg lists.  You could see an example in 
> Scott's reply to one of the mangled messages.  Here is the unmangled message, 
> to keep us all in sync.  My apologies to the recipients who are seeing this 
> again.)
>
>
>
>> By Transport ID, I would assume the  identifer(s)  associated with the
>> transport level authentication key.
>> For EPP ID I would assume whatever identification is associated with
>> an EPP instance.
>
> In EPP, you do a simple login with user name and password:
> login Bob bobscleartextpassword
>
> The other end checks the password and says "Great to see you, Bob!"
>
> Underneath you have a stronger authentication system running.
> This is based on some transport id, like the ip addr/protocol/port
> or whatever id the secure transport uses.  Lets say the transport
> id is ip addr, say 10.1.0.0 at the end doing the login authentication.
>
>
> 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.
>
> 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.
>
> 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.
>
> --Sandy
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
>