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

From: Jeff Mandin <[email-masked]>
Date: Fri, 08 Apr 2005 15:45:36 +0200

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 <[email-masked]> 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
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

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

---

From: Alper Yegin <[email-masked]>
Date: Fri, 08 Apr 2005 14:13:10 -0700

Hi,

> all credentials belong to a single Interface/BSId.

How are they fundamentally different? I'd appreciate some elaboration.

Thanks

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 8 Apr 2005 14:48:29 -0700 (PDT)

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

> 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

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.

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

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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap