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

[Alper Yegin (alper.yegin]

Hi Bernard,

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

If we are going to make a distinction between the "EAP lower layer
authenticator" and "EAP authenticator", we'd need to define the
differences, roles, etc.. Btw, note that this is conflicting with the
definition of "authenticator" in RFC3748 which equates the two. 

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

I guess an explicit NAS-ID needs to be carried by the EAP lower layer
unless we assume an implicit value (e.g., the MAC address of the 802.11
AP).

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

They do not utilize peer and AAA server identities either.

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

Unless the NAS ports can convey the NAS-ID to the peer before secure
associations, NAS should also explicitly convey the port IDs in order to
provide the key cache boundary. What do you think?

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

Thanks.

Alper