Subject: RE: [eap] RE: Separation of EAP authenticator and AAA client

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Wed, 29 Jun 2005 13:18:30 -0500

> 
> For example, if I put a big black box around a CAPWAP system 
> of lightweight APs and WLAN switches, could you tell the 
> difference between that and separate APs that utilize 
> clustering to appear as one "authenticator"?  Assuming that 
> both systems utilize a single NAS-ID attribute with RADIUS, 
> and advertise that ID on the link layer side and keep the key 
> cache consistent with that view, I don't see how a peer could 
> tell the difference.  Note that both systems could utilize 
> multiple NAS-IP-Address and NAS-IPv6-Address attributes (even 
> a single AP could have multiple IP addresses;  one IPv4 & one 
> IPv6 for a dual stack host, or more of both IPv4 and IPv6 
> addresses if the AP is a member of multiple VLANs).
> 

If the EAP authenticator has multiple 802.1x authenticators attached to it (as is the case when a WLAN switch is connected to multiple APs), who is defining the interface between the two? IETF is defining the security of the EAP system (for the EAP peer, authenticator and server) and IEEE has defined 802.1x elements (supplicant and authenticator). Good security can be provided when the 802.1x supplicant and EAP peer are the same and the two authenticators are the same. But, when there is no longer a 1-to-1 relationship between the two authenticators, how is proper security ensured? It seems like today, this interface is handled in a proprietary fashion. Could it be that the level of security provided by the EAP method gets compromised in some way when these elements have a 1-to-many mapping? 

Thanks,
Vidya

> > Tangentially: if we did begin to decompose the authenticator  the 
> > 802.16e secure association protocol would most naturally 
> seem to take 
> > place in the "EAP lower layer" since it is based on the 
> port specific 
> > AK rather than the PMK.
> 
> I think it is definitely in the "lower layer" even if we 
> don't decompose it :)
> 
> > But if any entity can simply claim to belong to the same 
> Authenticator 
> > (ie. "NAS-ID") I'm not sure how much has been gained.
> 
> The advertisement of the NAS-ID by the authenticator is 
> largely a key cache efficiency issue.  A bogus NAS-ID 
> advertisement can induce a peer to utilize a key in a 
> conversation that it otherwise would not expose to potential 
> attack.  However, that can happen without a NAS-ID (e.g. in 
> 802.11i, a peer can advertise a PMKID that is not in the APs 
> cache, and if the AP selected that PMKID, the peer would 
> attempt to complete a 4-way handshake with it (and fail).
> 
> If the NAS claims a bogus NAS-ID to the peer, then this can 
> be discovered via Channel Bindings.  If the NAS claims a 
> bogus NAS-ID to AAA, then the AAA proxy can figure that out. 
> _______________________________________________
> 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: "Sood, Kapil" <[email-masked]>
Date: Wed, 29 Jun 2005 13:38:58 -0700

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Tuesday, June 28, 2005 9:30 PM
> To: Sood, Kapil
> Cc: [email-masked]; 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 :)