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

[Jeff Mandin (jmandin]

Sanjay and Bernard,

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.

2. Consequently, for pure 802.16e the Authenticator as well is always
identified with a particular BSId/Interface.  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).

So basic 16e can support channel binding methods easily.

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

- Jeff


On Apr 8, 2005 3:53 AM, Bakshi, Sanjay <sanjay.bakshi [at] intel.com> wrote:
> 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
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap