>> to be an L2 identity. It can be any identity that's meaningful to the >> parties involved, and can serve as the basis for making authorization >> decisions. > > As long as it's cryptographically bound to the L2 channel and that > channel provides suitable protection for the EAP method doing the EAP > channel binding, THEN Sam's observation is correct: "EAP channel > binding" uses what I termed "end-point channel binding" and "EAP > cryptographic binding" uses what I termed "unique channel binding." I don't think I'm convinced that EAP channel bindings are doing this binding to the L2 channel. The identity used in an EAP channel binding must be bound to the AAA security association between the authenticator and the peer in order for everything to work, so it would be more likely a NAS-ID than a MAC address. That's not to say there isn't an L2 binding happening -- but I think it's being performed by the L2 secure association phase that uses the EAP key to derive L2 keys. Then during that handshake, a MAC address may be involved, binding in an L2 identity. I guess I see EAP channel bindings as an EAP<->AAA binding, and the L2 secure association protocol as the EAP<->L2 binding. -- t. charles clancy, ph.d. <> tcc@xxxxxxx <> www.cs.umd.edu/~clancy _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf