Subject: [eap] Separation of EAP authenticator and AAA client

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Jun 2005 14:41:09 -0700 (PDT)

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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 28 Jun 2005 14:20:22 -0700

Hi Bernard,

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

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

> except as an opaque blob for channel bindings.  

They do not utilize peer and AAA server identities either.

> However, it is

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?

> key hierarchies on multiple media.

Thanks.

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Jun 2005 21:22:40 -0700 (PDT)

> unless we assume an implicit value (e.g., the MAC address of the 802.11

I think the authenticator identity needs to be explicitly defined.  It
could just be the MAC address but without defining it you get
interoperability problems.

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

EAP methods do export the Peer-ID and the Server-ID, so I'm not sure what
you mean.

> provide the key cache boundary. What do you think?

The lower layer spec needs to explicitly define the key
scope/authenticator identity.  Typically this is either an address of some
kind (e.g. MAC address) or an identifier (NAS-ID).  A port-ID is neither
here nor there -- it doesn't tell the peer if the key derived on port X is
also usable when connecting to port Y.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Jun 2005 21:47:44 -0700 (PDT)

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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 29 Jun 2005 13:55:33 -0700

> interoperability problems.

I agree.

> EAP methods do export the Peer-ID and the Server-ID, so I'm not sure
what

I was thinking that none of these identities are explicitly carried in
EAP headers. Yes, the EAP methods can export the peer and server IDs,
much like the EAP lower layer can export the NAS ID. Btw, the former
ones are used for key scoping. Isn't this related to where we need to
use the NAS ID as well? 

> also usable when connecting to port Y.

If the NAS has multiple ports (like a CAPWAP AC controlling multiple
APs), key cache boundary is the set of all these ports. For that I think
the EAP peer should know the identity of these ports.

I think there is one alternative approach. Even if the NAS does not
convey the list of ports to the EAP peer, the peer may discover them as
it encounters each port. For example, when the peer moves to port Y
(from port X where it had performed the EAP authentication), if the port
Y can convey the associated NAS ID, then the peer can dynamically
discover that it is still within the same key cache boundary.

I prefer the first approach where the NAS explicitly conveys the list of
ports to the EAP peer.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 29 Jun 2005 14:13:35 -0700

Hi Jeff,

> happens to be divided between more than one physical box.

Within the context of the IETF protocols, I perceive this as the "split
NAS". "(EAP) authenticator" and "AAA client" parts of the NAS are on one
(centralized) node. "NAS ports" are on multiple separate nodes.

Alper