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

[Bernard Aboba (aboba]

> 1. Regarding channel binding:  "pure" 802.16e authentication is done
> entirely inside the MAC layer (fundamentally different from 802.1x) and
> all credentials belong to a single Interface/BSId.

EAP is media independent.  The EAP peer and server identities are not
bound to a particular port or MAC address, and so neither are the exported
keys.  Channel binding, if it is to be accomplished, needs to be done
explicitly within the EAP method, AAA protocol and/or Secure Association
Protocol.

> 2. Consequently, for pure 802.16e the Authenticator as well is always
> identified with a particular BSId/Interface.

As described in the EAP key management framework, an EAP authenticator's
identity is not bound to a particular interface by the EAP conversation.
An EAP authenticator can have multiple ports, and where key caching is
supported, an EAP peer cannot necessarily assume that the key scope is
restricted to the particular port on which it connects to the authenticator.
For example, when a WLAN switch is deployed, the key cache may exist on
the switch, not on each individual BSSID.

As a result, if 802.16e supports key caching, and if an authenticator may
have more than one port, then the authenticator identity needs to be made
available to the EAP peer, not just the BSId, so that the peer can
determine the key scope.

I'd also note that an EAP peer can have multiple ports too, so that it
cannot be assumed that the EAP exchange implicitly binds the exported keys
to the interface over which EAP occurred.

> Consequently a
> channel-binding EAP method could use the BSId to enable both the AAA
> Server and peer to affirm the endpoints for the authentication and key
> scope.  (EAP-TTLS has optional support for channel binding BTW).

If an 802.16e authenticator can have multiple ports, then the BSId is not
equivalent to the authenticator identity.  That would imply that the key
scope is undefined on the EAP peer, and that Channel bindings can only
verify the Called-Station-Id, not the NAS-Identifier.

> So basic 16e can support channel binding methods easily.

If an authenticator can have multiple ports, it would not appear to me
that Channel Binding is correctly supported.

> 3. The "Split Authenticator" proposal does seem to introduce issues
> however .... because in that case the authentication is being done
> simultaneously - in effect -  for all BSes using the same centralized
> "back-half" Authenticator.

Yes.  This raises the same issues as were caused by the introduction of
WLAN switches in 802.11.

> I think that's what Sanjay was suggesting
> before (as the BSes aren't really ports on the "back-half" authenticator
> but are Access Controllers with distinct identity and credentials).

Overall, it seems like 802.16e is grappling with some of the issues that
IEEE 802.11i failed to resolve successfully.  That is part of the reason
why the EAP Key Management framework gives fairly detailed advice on the
effects of key caching.