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

[Bernard Aboba (aboba]

> 1. Is Channel Binding a mandatory requirement?
>    Based on my understanding it is not. Please let me if I am wrong.

The Housley Criteria describe the mandatory properties of AAA key
management.  One of those mandatory propreties is binding of the key to
the proper context.  Channel binding is just one way to accomplish this,
but there are other approaches.  In fact, those other approaches (such as
binding within the Secure Association Protocol) may be preferrable
since they work with any EAP method.

> 2. What issues do you see if Authenticator and Peer are separated by a
>    layer 2 switch that changes the EAP lower layer?
>    I know channel binding becomes an issue. Besides that what other
>    issues do you see?

There are a number of potential issues depending on the exact
configuration.  As I understand it, this issue is now under discussion
within CAPWAP, for example.  Overall, the issue is whether the Housley
Criteria are being compromised.

> 3. Also, I was trying to understand the purpose of channel binding?
>    As I understand, it is used for establishing the identity of
>    Authenticator and it uses channel (lower layer) properties mainly
>    because they identify the Authenticator in some way.

The key transported from the AAA server to the authenticator has a
context.  This includes:

* The identity of the parties involved (peer, authenticator, server).
* The key lifetimes.
* The scope of key usage (key cache extent)
* Authorizations (authorized SSID, authorized called-station-id, etc.)

The Housley Criteria require that this context be synchronized between the
EAP peer, server and authenticator.  Channel binding is a mechanism for
achieving key context synchronization between the EAP peer and server.
However, that is not the only way that synchronization can be achieved
between the three parties.

> 4. How does a peer come to know about the attributes, such as Called-
>    Station-Id, NAS-Identifier etc., used for channel binding? It seems
>    to me that they have to configured in the peer via some secure means
>    and cannot be determined via a beacon etc. from the access point or
>    a base station.

The server obtains the Called-Station-Id, NAS-Identifier and other attributes
from the authenticator.  It is the job of the lower layer to
securely provide these attributes to the peer so that the state can be
synchronized between the peer, authenticator and server.  The
information can be transmitted in a Beacon or Probe Response, but it also
needs to be verified in a cryptographically secured handshake (such as the
4-way handshake in 802.11i).

The attributes to be passed between the peer and authenticator need to
be defined within the lower layer, such as within IEs in 802.11. New IEs
can be defined later that may have significant security implications (such
as cost), so extensibility is recommended.  For example, 802.11i allows
additional IEs to be included (and verified) within the 4-way handshake.

Note that there is wide latitude in terms of the format with which the
attributes are exchanged between the authenticator and peer. For example,
the AAA server could send an encrypted token to the NAS that could be
passed to the peer via the lower layer.