eap Mailing List: Separation of EAP authenticator and AAA client

[Bernard Aboba (aboba]

> >I understand that collocating otherwise separable entities is not likely
> >to be an issue. I was asking if we require (assume) the EAP
> >authenticator and the AAA client be on the same node.
>
> I do not think so.  In fact, in the CAPWAP architecture, it is not clear
> that they will be on the same host.

I think that the EAP authenticator and AAA client exist on the
same host in all cases.  However, it is possible that the 802.1X
authenticator and EAP authenticator may exist on different hosts.

For example, in "split MAC" architectures, 802.1X may be terminated on
the lightweight AP, but the EAP packet still needs to be forwarded to
the switch for encapsulation in RADIUS.

An "EAP authenticator" is the entity that identifies itself as the
authenticator to the EAP peer (at the lower layer), and proves possession
of keying material derived by the EAP peer and server, thereby binding
that key material to the claim of identity.

A "AAA client" is an entity which identifies itself as such to the AAA
server, and can present credentials to prove that claim of identity.
In RADIUS, the most appropriate attribute for this purpose is NAS-Identifier,
since a single authenticator can have multiple IP addresses associated with it 
(e.g.
NAS-IP-Address and NAS-IPv6-Address assigned to the same authenticator, or
even multiple NAS-IP-Address attributes for one authenticator).  To ensure
synchronization between all parties, the authenticator identity claimed by
the EAP authenticator lower layer MUST be the same as that claimed by the
AAA client in the NAS-Identifier attribute.

So we have said that the "EAP authenticator" and "AAA client" are claiming
the same identity (albeit to different parties), and also obtain
possession of keying material from the EAP server.

As we have discussed in EAP WG, the EAP peer and server are the principals
in an EAP conversation, and they do not utilize the authenticator identity
except as an opaque blob for channel bindings.  However, it is
nevertheless important for the lower layer to obtain the authenticator
identity and make sure that the EAP peer and authenticator are in sync
with respect to it.  This is important in order to define the key cache
boundaries within the lower layer.

The EAP peer and server push down the exported parameters to the lower
layer (MSK, EMSK, IV, Peer-ID, Server-ID, Session-ID, Key_Lifetime).
However, for the purposes of the lower layer, the scope of the key
cache is defined by the media (NAS-Port-Type) and the
authenticator identity (NAS-Identifier).

As discussed at IETF 62, the EAP layer does not cache exported
parameters, and a lower layer cannot allow keying material
exported by the EAP method to move outside the key scope as defined by
NAS-Port-Type and NAS-Identifier, in order to prevent cascading
vulnerabilities.  For example, if media A uses a suspect ciphersuite,
allowing recovery of exported parameters, this should not lead to the
compromise of a conversation occuring on media B.

This implies that a lower layer key cache cannot share keying material
with another media.  If an EAP conversation occurs over media A, then
the key cache on media B cannot obtain exported parameters
from that conversation.

The exception is sharing between AAA and lower layer on the EAP
authenticator.  It is the responsibilty of the lower layer on the
authenticator to request that the AAA client obtain just enough
information from the EAP server to for adherence to the "principle of
equivalence".  That is, the EAP and subsequent lower layer
conversation MUST occur the same way, regardless of whether a AAA
server is present.

Replication of the EMSK between the EAP server and authenticator is
prohibited, so that if a AAA client asks for the EMSK, the AAA server
MUST NOT send it.  However, the AAA client can ask for an AMSK and
the AAA server can calculate and send that instead.  In existing
AAA implementations, neither the AAA client or server maintains a cache
of exported parameters.

Some examples:

a. In IEEE 802.11i, the key hierarchy depends only on the MSK and
Key_Lifetime (sent in the Session-Timeout attribute) and does
not involve the EMSK, IV, Peer-ID, Server-ID, or Session-ID
exported by the EAP method.  Therefore the AAA client only needs to obtain
the MSK and Key_Lifetime from the EAP server to maintain the "principle of
equivalence".  IEEE 802.11i does not require the AAA server to
maintain a key cache. Note that the Key_Lifetime is not transmitted to the
EAP peer in 802.11i, so that not all state is correctly replicated.

b. In IEEE 802.16eD7, the key hierarchy depends on the MSK as well as the
Session-ID, so these parameters would need to be requested by the AAA
client. IEEE 802.16eD7 does not require a AAA server key cache either.

c. In pre-emptive keying proposals, it is assumed that the AAA server
maintains a key cache, and also that it may utilize that cache to enable
handoffs between media.  While in principle a NAS supporting
pre-emptive keying could request that the AAA server maintain a
cache, the same exported keying material cannot be at the root of
key hierarchies on multiple media.