Subject: RE: [eap] Re: IEEE 802.16e EAP usage modes

From: "Bakshi, Sanjay" <[email-masked]>
Date: Thu, 7 Apr 2005 18:53:29 -0700

Bernard,
Starting a new thread as promised...
Please see my comments below.
Thanks,
sanjay

> Issues that come to my mind are
>    a) MTU discovery
>       For the minimum MTU of 1020 specified in RFC3748 can be used

EAP can't do MTU discovery, per se.  Are you saying that a minimum MTU
of 1020 is always available?
<<sanjay>> Per RFC MTU of 1020 is the minimum that should be supported

>    b) Channel Binding
>       Are there any EAP methods that implement this?

Yes, there are methods that are capable of this.  The EAP peer and
server verify that the "authenticator" they see is offering the same
information to each of them.  For example:

Authenticator MAC address as seen by peer = Called-Station-ID in
                                            Access-Request
SSID as seen by peer                      = SSID in Access-Request
NAS-Identifer as seen by peer             = NAS-Identifier in Request

<<sanjay>> So is it fair to say that channel binding is a way to verify
the identity of the authenticator. It seems it directly does not really
have to do anything with the lower layer used to communicate between
peer and authenticator. Lower layer just happens to have some attributes
such Authenticator MAC that help identify the Authenticator?

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?

Also can you give me examples of EAP-methods that support channel
binding?

> It is not clear to me how Channel Binding is implemented when pass- 
> thru authenticator is in use. This because the Channel (lower
> layer) between peer and pass-thru authenticator is different from the 
> lower layer between pass-thru authenticator and AAA backend that 
> execute the EAP method.

I'm not sure why this would affect Channel bindings.
<<sanjay>> I agree with you.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 10 Apr 2005 10:05:32 -0700 (PDT)

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

Yes.

> 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

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

> 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.