On Jun 18, 2013, at 7:18 AM, Sam Hartman
<hartmans(_at_)painless-security(_dot_)com>
wrote:
"Black," == Black, David <david(_dot_)black(_at_)emc(_dot_)com> writes:
Black,> The next to last paragraph on p.3 begins with this sentence:
Black,> For these reasons, channel binding MUST be implemented by
Black,> peers, EAP servers and AAA servers in environments where EAP
Black,> authentication is used to access application layer services.
Black,> It appear that this "MUST" requirement applies to all uses
Black,> of EAP, including network access authentication, not just
Black,> application layer access authentication. If so, that's not
Black,> immediately obvious from the text, and an additional
Black,> sentence should be added to make this clearer. If not, the
Black,> above sentence needs to exclude network access
Black,> authentication from that requirement.
I know you're correct that AAA servers and EAP servers need to implement
channel binding for network access in such environments.
I'm not sure whether peers only doing network access SHOULD implement
channel binding or MUST implement channel binding.
Practically speaking, it will be a while before peers implement channel
binding for network access.
The sorts of attacks that result without channel binding are attacks
where a peer thinks it is doing network access authentication but what
it's really doing is helping an attacker access an application.
If all the application access peers support channel binding, then you
could potentially require the eap-lower-layer attribute or similar for
application authentication and work securely in environments where peers
for network access have not been updated yet.
[Joe] I'm trying to get a handle on the attack mechanism here. In this
attack a valid network service is trying to spoof an application service?
Since it knows the MSK it can do this if the channel-binding of the lower-layer
into the EAP conversation is not enforced. If the AAA server always enforces
channel bindings for applications then it will catch the spoofing attempt.
The reverse case may also be an issue where an application service is trying to
spoof a network service. In this case, if the AAA server validates that the
application channel binding is not present then it can prevent the spoofing.
However the server MUST understand channel bindings even if the peers do not.
I think the document did try to capture this in the following sentence:
"If the EAP server is aware that authentication is
for something other than a network service, it too MUST default to
requiring channel binding."
I think we could state this a bit better as something like:
"In environments where EAP is used for applications authentication and network
access authentication all EAP servers MUST understand channel bindings and
require that application bindings MUST be present in application authentication
and that application bindings MUST be absent in network authentication. All
network access EAP peer implementations SHOULD support channel binding to
explicitly identify the reason for authentication. Any new usage of EAP MUST
support channel bindings to prevent confusion with network access usage. "
It's also kind of tempting to stick our head in the sand and just add
the clarification that "yes, we mean network access too."
--Sam