eap Mailing List: RE: Re: IEEE 802.16e EAP usage modes

[Bernard Aboba (aboba]

> <<sanjay>> Per RFC MTU of 1020 is the minimum that should be supported

Yes.

> <<sanjay>> So is it fair to say that channel binding is a way to verify
> the identity of the authenticator.

Channel binding is a way to attempt to satisfy one of the security
requirements (key binding) in a scenario where the lower layer doesn't
provide the required binding.  Authenticator identity is only one element
of the key binding problem.  Others include key lifetime, key scope, and
authorizations.

> Lower layer just happens to have some attributes
> such Authenticator MAC that help identify the Authenticator?

Actually the point was that the Authenticator MAC does not identify the
Authenticator if the Authenticator may have multiple ports.

> Also it seems there is an implicit assumption that for channel binding
> to work as per rfc3748, either the peer needs to know the identity of
> the authenticator up front or an authenticator should be able to
> advertise its identity to securely somehow?

The EAP peer needs to know the Authenticator identity in order to
determine the key scope, for example.  It is better to learn this
information early on, so as to enable more efficient roaming.

As an example, when WLAN switches are implemented, the key cache may
reside on the switch rather than in individual access points.  Where the
WLAN switch acts as the Authenticator, the view of the Authenticator
identity is not synchronized between the EAP peer, server and
authenticator.  As a result, an EAP peer may not know whether a given
Access Point has a AAA-Key in the key cache or not.