Sam Hartman wrote:
"Charles" == Charles Clancy <clancy@xxxxxxxxxx> writes:
Charles> I don't think I'm convinced that EAP channel bindings are
Charles> doing this binding to the L2 channel. The identity used
Charles> in an EAP channel binding must be bound to the AAA
Charles> security association between the authenticator and the
Charles> peer in order for everything to work, so it would be more
I'm not sure I'd describe the association between the peer and authenticator as an AAA association.
I agree with the rest.
Ah, I mistyped. I meant AAA security association between the
authenticator and EAP server.
Charles> likely a NAS-ID than a MAC address.
>
Are you sure that the binding happens between the mac address and NAS
ID? I don't understand how the peer ever confirms the NAS ID at layer
two unless it also happens to be a MAC address.
This is one of the fundamental issues with EAP channel bindings. The
NAS ID is bound to the AAA security association between the
authenticator and the EAP server. The MAC address is visible to the
client. Thus the peer and EAP server each know a different identity for
the authenticator. Whatever identity is used must be channel-bound to
the AAA security association, otherwise the authenticator could lie to
the EAP server about its identity.
I see two solutions:
1. The NAS ID is broadcast to the peer before EAP authentication (e.g.
in an 802.11 beacon)
2. The EAP server maintains a static mapping between NAS IDs and MAC
addresses, manually binding MAC addresses to AAA security associations
I do agree with you though that EAP channel bindings include the
peer's lower layer identity and the identity of the authenticator that
the peer will later be able to verify.
Right -- but there needs to be some way for the EAP server to know the
authenticator's lower-layer information in such a way that the
authenticator can't lie about its lower-layer information to the EAP server.
Charles> I guess I see EAP channel bindings as an EAP<->AAA
Charles> binding, and the L2 secure association protocol as the
Charles> EAP<->L2 binding.
The L2 secure association protocol cannot be an eap->anything binding:
it does not typically use EAP level identifiers.
It uses EAP keys though. If from a higher layer we know EAP keys could
have only been delivered to a particular EAP/AAA identity, and those
keys are exported to the lower layer, then I'd think you have a binding
from the EAP identity to the EAP keys to the lower-layer keys to the
lower-layer identity.
--
t. charles clancy, ph.d. <> tcc@xxxxxxx <> www.cs.umd.edu/~clancy
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf