eap Mailing List: RE: RE: Separation of EAP authenticator and AAA client

[Narayanan Vidya-CVN065 (vidya]

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