Subject: Re: [Emu] Channel Binding: tunneled methods

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 29 Jun 2010 14:35:56 -0700

Sam Hartman said:

"Unfortunately, it's never that simple.  Channel binding data is a

statement from the client to the EAP server about the client's

understanding of the entity the client is authenticating to/the

environment that the client is gaining access to.  the EAP server's job

is to verify that the channel binding is consistent and if not, reject

the access request."

[BA] The server's job is not only to verify that the channel binding is
consistent, but also that it is correct.

It is possible for the NAS to lie to both the peer and the server, in which
case the channel binding

info would be consistent with the AAA information, but both would be wrong.
For example, in the SSID case,

the NAS/AP could advertise an incorrect SSID, as well as including that
incorrect SSID in the AAA conversation

(e.g. spoofed Called-Station-Id).  

If the AAA server were more than one hop away from the NAS, and an AP

that could legitimately assert that SSID were using the same proxy as the
rogue AP/NAS, then unless the proxy

performed a check and noted the inconsistency, there is no way for the AAA
server to figure this out.  The

problem is that the first hop proxy is typically within the same
administrative domain as the rogue AP/NAS. 

As a result, it can be difficult for channel bindings to provide protection
in situations where both

the NAS and the first hop proxy are controlled by the attacker. 

"This is not a practical attack.  I'm not sure there are particularly

practical attacks in this space.  However, I think we have an obligation

to specify constraints such that the system is secure.  Here are

examples of constraints that would be sufficient."

[BA] Assuming that crypto-binding is used, then this attack can be thwarted.
If not, then it might

be possible, depending on the peer policy.  First hop proxies can terminate
virtually any existing EAP 

tunnel method.  The only real protection against this is crypto-binding as
well as constraints 

imposed by the peer on what server certificates will be accepted.  

For example, if the peer is connecting to SSID "example", then it might
expect the server certificate to 

chain to the "example.com" trust anchor.  If there are no such constraints,
and crypto-binding isn't 

required by the client, then a first hop proxy controlled by an attacker
could terminate the EAP tunnel, 

rewrite the channel bindings, and then re-tunnel the inner method. 

"I'm not sure whether an attacker can turn one of the TLS-related methods
into another." 

If two TLS-related methods use the same key derivation label, then this is
possible.