Subject: [Emu] How does cryptographic binding work

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Sep 2010 13:11:48 -0400

So, this paper makes it clear that I don't understand some of this stuff
as well as I thought I did.  No surprise there; it's complicated and
this has not been my primary area of focus. so let's see if I can be
educated.

In the part of the world I'm familiar with, we address this problem by
authenticating the identity of the outer tunnel as part of the inner
tunnel.  For example for a TLS-based tunnel we might hash the TLS finish
message into the inner method.  We don't even try to do anything with
plaintext password methods: there's no point you're just kidding
yourself.  We do try and do something with things like SCRAM (think
mschapv2 roughly).  We're typically using the tunnel in order to fight
against dictionary attacks mounted by observers or to provide session
security later.

If I'm reading this paper right that's not what we're doing here in EAP.
We're taking some quantity from the inner method and binding to that?

What's the rationale for that?

---

From: Joe Salowey <[email-masked]>
Date: Wed, 01 Sep 2010 16:38:29 -0700

The basic reason for this is that EAP methods have a well defined mechanism
to output key material. There hasn't been a mechanism to import data into a
method, channel bindings may change this.

Key generating EAP methods export an MSK.  The MSK is then mixed with key
material extracted from the TLS keying material to form a combined key.
This combined key is then used in a MAC calculation on some data sent within
the tunnel.  The details vary depending on the method.  Typically the MSK
exported from the tunnel method also have the inner method MSK mixed in with
the TLS key material.

There are cases with some EAP methods where data from the TLS tunnel has
been used directly in the inner method.  This behavior causes differences
between the way the method behaves inside the tunnel and outside the tunnel,
which may complicate implementations in many cases.

EAP tunnel methods typically do not try to do any binding with plaintext
basic PAP-like password exchanges.

Hope this helps to clarify things.

Joe

On 9/1/10 10:11 AM, "Sam Hartman" <[email-masked]> wrote:

> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Sep 2010 19:56:32 -0400

>>>>> "Joe" == Joe Salowey <[email-masked]> writes:

    Joe> The basic reason for this is that EAP methods have a well
    Joe> defined mechanism to output key material. There hasn't been a
    Joe> mechanism to import data into a method, channel bindings may
    Joe> change this.

OK, but I'm not sure this quite gets you the properties you want.

As best I can tell:

* The server wants assurance that if an inner method is somehow lifted
  out of a tunneled exchange, the inner method cannot be used alone or
  in a different tunnel.

* The client wants assurance that it's talking to a consistent server so
  that you only end up having to authenticate the server at one level.

Impersonating peers to servers and impersonating servers to peers both
have value to an attacker in different situations.

I think these are the properties you want (And I think the definition in
RFC 3748 is a bit under specified) and I'm not sure how what you've
described gets that.

---

From: Joe Salowey <[email-masked]>
Date: Wed, 01 Sep 2010 19:51:18 -0700

> OK, but I'm not sure this quite gets you the properties you want.
[Joe] What we wanted from this mechanism was to ensure that the tunnel
endpoints was the same as the inner method endpoints.

>   out of a tunneled exchange, the inner method cannot be used alone or
[Joe] We didn't want to modify the method.  The purpose was to restrict the
method only to the a particular tunnel type, but we wanted to make sure that
the particular instance of method execution wasn't executed in a different
tunnel or without a tunnel.

>   that you only end up having to authenticate the server at one level.
[Joe] For most cases the assumption is that the server is authenticated by
the tunnel method. 

> RFC 3748 is a bit under specified) and I'm not sure how what you've

[Joe]  I'm not sure if I understand the properties you describe, so I'm not
sure if they line up with the goals of making sure the tunnel endpoints are
the same as the inner method endpoints.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 02 Sep 2010 15:19:25 +0200

>   that you only end up having to authenticate the server at one level.

  I have always been unsure as to why clients don't tie credentials to a
server certificate.  Instead, they are usually tied to an SSID.  And
while clients can verify the servers CA, the CA is usually in a global
CA store.

  i.e. the credentials are only associated with an SSID.

  If it were possible to tie user credentials to a server certificate,
then the clients could validate the server before sending the credentials.

  For the attack to work on the client, it requires that the client set
up an anonymous tunnel with the attacker, and send credentials down that
tunnel.  If the client were to associate the credentials with a server
cert, the attack could be detected.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Sep 2010 11:29:26 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Sam Hartman wrote:
    >> * The client wants assurance that it's talking to a consistent
    >> server so that you only end up having to authenticate the server
    >> at one level.

    Alan>   I have always been unsure as to why clients don't tie
    Alan> credentials to a server certificate.  Instead, they are
    Alan> usually tied to an SSID.  And while clients can verify the
    Alan> servers CA, the CA is usually in a global CA store.

Hmm.  Android at least seems to let me pick an expected CA for each SSID
separately.  I don't have EAP here at home so I've not played with the
security.  That presumably means that wpa_supplicant gives you enough
rope under the covers.

I can't help the Windows and mac users:-)