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

[Sood, Kapil (kapil.sood]

Are we explaining a new terminology that does not exist in the 3748?  As per 
this:

authenticator
      The end of the link initiating EAP authentication.  The term
      authenticator is used in [IEEE-802.1X], and has the same meaning
      in this document.

   peer
      The end of the link that responds to the authenticator.  In
      [IEEE-802.1X], this end is known as the Supplicant.

What is the difference between the EAP Authenticator (which I believe is 
defined above) and the 802.1X Authenticator, vis-à-vis 802.11i model?

If EAP peer and 802.1X supplicant are the same, then in your explanation below, 
the definition of EAP Authenticator is suggesting what is done by the 802.1X 
authenticator.

The definition of each will have drastic impacts on how people view the keys to 
be bound (or, not bound), and hence, on the overall security of the EAP-based 
systems.

Best Regards,
 
Kapil.
503.264.3759

-----Original Message-----
From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On 
Behalf Of Bernard Aboba
Sent: Monday, June 27, 2005 2:41 PM
To: eap [at] frascone.com
Cc: Alper Yegin
Subject: [eap] Separation of EAP authenticator and AAA client

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