| RE: Separation of EAP authenticator and AAA client | <– Date –> <– Thread –> |
|
From: Sood, Kapil (kapil.sood |
|
| Date: Wed, 29 Jun 2005 16:39:11 -0400 (EDT) | |
> -----Original Message----- > From: Bernard Aboba [mailto:aboba [at] internaut.com] > Sent: Tuesday, June 28, 2005 9:30 PM > To: Sood, Kapil > Cc: eap [at] frascone.com; Alper Yegin > Subject: RE: [eap] Separation of EAP authenticator and AAA client > > > What is the difference between the EAP Authenticator (which I believe is > > defined above) > > and the 802.1X Authenticator, vis-à-vis 802.11i model? > > Assume a CAPWAP architecture where the lighweight AP handles 802.1X, but > shuttles EAP packets back to the WLAN switch (rather than sending 802.1X > packets to the switch). The WLAN switch holds the local credentials > and/or acts as a AAA client. > > In this situation, wouldn't the lightweight AP be an 802.1X authenticator, > but not an EAP authenticator? If there is no AAA operating (e.g. local > user), the EAP authenticator has to be the entity that holds the local > credentials, because that's where EAP authentication terminates. Yet that > entity is not the lightweight AP, it is the WLAN switch. On the other > hand, the lightweight AP does house the 802.1X port, and it does terminate > the 802.11/802.1X link. [Sood, Kapil] 802.11i mentions an "Authenticator and Authentication Server have established a secure channel", and discussions in 802.11i make it the beneficiary of the PMKs derived between the STA and AS. One interpretation is that this party is the AAA Client/EAP Authenticator. When we split the role of this authenticator, and 802.1X terminator is the end of the 802.1X link, then the EAP packets have to be encapsulated in a different form to be sent to this AAA Client/EAP Authenticator. Since, the EAP protocol has 3 parties for key derivation and distribution, the 3rd party has to be the one that has authenticated itself with the AS, and whose identity should be bound to the derived keys. So, I guess, in this discussion the 802.1X authenticator plays no role in key distribution. > > Does this make sense? The only other way to interpret this would be to > call the lightweight AP an EAP authenticator, and then the WLAN switch > becomes the EAP server in a non-AAA case. [Sood, Kapil] Changing roles of network entities makes functionality obscure, and hence, security analysis problematic! When the WLAN switch does AAA, > the AAA server houses the EAP server, so then I don't know what you would > call the WLAN switch :) [Sood, Kapil] I guess, we would still have to call it the EAP Authenticator, based on my above discussion :)
- Re: RE: Separation of EAP authenticator and AAA client, (continued)
- Message not available
- Re: RE: Separation of EAP authenticator and AAA client Bernard Aboba, June 28 2005
- RE: Separation of EAP authenticator and AAA client Bernard Aboba, June 28 2005
Results generated by Tiger Technologies using MHonArc.