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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 14 Jul 2009 20:08:32 -0400

Doesn't TLS provide protections for this issue?

-Scott-

 -----Original Message-----
From: 	Sandy Murphy [mailto:[email-masked]]
Sent:	Tuesday, July 14, 2009 07:15 PM Eastern Standard Time
To:	[email-masked]; [email-masked]; [email-masked]; [email-masked]; 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.

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

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 15 Jul 2009 11:13:29 -0400 (Eastern Daylight Time)

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

--Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 15 Jul 2009 11:25:56 -0400 (Eastern Daylight Time)

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:

> 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.)
>
>
>
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
>

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 15 Jul 2009 11:37:27 -0400 (Eastern Daylight Time)

> Doesn't TLS provide protections for this issue?

(a) rfc4930 does not mandate use of TLS as a tranport connection, by 
design (so I don't know why you mention it):

    EPP is intended for use in diverse operating environments where
    transport and security requirements vary greatly.  It is unlikely
    that a single transport or security specification will meet the needs
    of all anticipated operators, so EPP was designed for use in a
    layered protocol environment.  Bindings to specific transport and
    security protocols are outside the scope of this specification.

(b) There are defined channel bindings for TLS.  See the recently 
published draft-altman-tls-channel-bindings-05.txt.  This isn't a free 
ride, however -- note the places where that draft mentions the need to 
modify firmware or software:

    Therefore 'tls-unique' is generally better than 'tls-server-end-
    point'.  However, 'tls-server-end-point' may be used with existing
    TLS server-side proxies ("concentrators") without modification to the
    proxies, whereas 'tls-unique' may require firmware or software
    updates to server-side proxies.  Therefore there may be cases where
    'tls-server-end-point' may interoperate but where 'tls-unique' may
    not.

--Sandy

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 15 Jul 2009 16:46:18 +0100

> design (so I don't know why you mention it):

rfc4934 (binding to TLS over TCP) mandates use of TLS.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 15 Jul 2009 12:15:46 -0400

> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Wednesday, July 15, 2009 11:46 AM
> To: Sandra Murphy
> Cc: Hollenbeck, Scott; [email-masked]; 
> [email-masked]; [email-masked]; Sandy Murphy

As Alexey noted, I mentioned it because there's an EPP specification for
transport over TLS.  4934bis is part of the document set that's being
reviewed for progression to Standard status.  That's why I'm having some
trouble understanding if/how I should address the channel binding risk
comments in 4930bis or one of the other documents.

-Scott-

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 15 Jul 2009 12:35:02 -0500

> Doesn't TLS provide protections for this issue?

Provided you authenticate the server, yes.

> The MITM has another secure authenticated transport connection to

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

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 15 Jul 2009 15:08:07 -0500

On Wed, Jul 15, 2009 at 03:44:04PM -0400, Hollenbeck, Scott wrote:
> > From: Nicolas Williams [mailto:[email-masked]] 
> > Sent: Wednesday, July 15, 2009 1:35 PM
> > To: Hollenbeck, Scott
> > Cc: Sandy Murphy; [email-masked]; 
> > [email-masked]; [email-masked]
> Good, because server authentication is a requirement specified in
> section 9 of 4934bis.

And provided we're talking about a two-party, client-server type of
application.  Specifically, that the username and cleartext password are
not being sent to more than one party and never in cleartext.

Nico
--

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 15 Jul 2009 18:11:35 -0400

> Sent: Wednesday, July 15, 2009 4:08 PM
> To: Hollenbeck, Scott
> > > Cc: Sandy Murphy; [email-masked]; [email-masked]; 
> > > [email-masked]
> And provided we're talking about a two-party, client-server 
> type of application.  Specifically, that the username and 
> cleartext password are not being sent to more than one party 
> and never in cleartext.

That's exactly how it works right now.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 15 Jul 2009 15:44:04 -0400

-Scott-