RE: Separation of EAP authenticator and AAA client
From: Sood, Kapil (kapil.soodintel.com)
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 :)


Results generated by Tiger Technologies using MHonArc.