>>>>> "Bernard" == Bernard Aboba <[email protected]> writes:
> 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."
Bernard> [BA] The server's job is not only to verify that the
Bernard> channel binding is consistent, but also that it is correct.
Bernard> It is possible for the NAS to lie to both the peer and the
Bernard> server, in which case the channel binding
Bernard> info would be consistent with the AAA information, but both
Bernard> would be wrong. For example, in the SSID case,
Bernard> the NAS/AP could advertise an incorrect SSID, as well as
Bernard> including that incorrect SSID in the AAA conversation
Bernard> (e.g. spoofed Called-Station-Id).
You're absolutely right.
I hesitate to use the term correct, because for a variety of reasons,
some of which you point out below, the EAP server may not actually have
enough data to make that determination.
draft-ietf-emu-chbind talks about making sure that the channel binding
data is consistent with what is reported by AAA and with a channel
binding database.
I think the draft does a good job of explaining both the value and
limitations of this approach.
I'm happy to pick whatever term we want for this sort of check, provided
that it does not imply that the EAP server will always be able to
evaluate correctness of the channel binding.
Consider the example I gave the other day with a client trying to
determine if it was connecting to the home corporate network. The EAP
server was never in a position to determine whether an advertized SSID
other than the corporate SSID was correct. All it knew was whether the
NAS was part of the corporate domain. It could determine whether the
client's understanding about this one claim (as inferred from the SSID)
was consistent with its understanding about the NAS. However it could
not assert correctness of channel binding.
I think understanding this limitation of channel binding is important to
understanding how they can effectively be used.
Bernard also brought up the point that an attacker can terminate a
tunnel early and rewrite the channel bindings. I need to redo my
analysis of tunnel attacks on channel binding: I was thinking mostly of
attackers creating a new tunnel, not of attackers acting as a
man-in-the-middle.
I think that as Bernard suggests, constraints on what server
certificates are accepted will be sufficient, but since I didn't
consider the correct attack surface, I need to rethink.
we seem to be in agreement that crypto binding is a sufficient defense.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
