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

[Bernard Aboba (aboba]

> I think that's correct:   RFC 3748 invokes the 802.1x definition in
> which the Authenticator is the entity that "flips the switch"
> controlling port access.  So the CAPWAP (or Wimax NWG) scenario would
> be viewed as including a single authenticator - whose functionality
> happens to be divided between more than one physical box.

RFC 3748 does use this definition, but I'm not clear that in every
CAPWAP scenario that the entity that "flips the switch" is the same entity
that would hold local credentials where no AAA is present.

Maybe we get around this by calling the combination of the lightweight APs
and WLAN switch "the authenticator" without getting into its internal
structure.  This is easier in some ways -- if we don't care how an AP
circuit board is laid out (e.g. does it have two processors? If so, which
one is the "authenticator?") why do we care about the decomposition of a
CAPWAP system?

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

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