eap Mailing List: Re: Proposed Resolution to Issue 365: Ambiguous Use ofIdentifier

[Bernard Aboba (bernard_aboba]

> > The AAA conversation is between the EAP authenticator and the backend
> > authentication server. From the point of view of the backend
> > authentication server, EAP keying material and parameters are
> > transported to the EAP authenticator identified by the NAS-Identifier
> > attribute. Since an EAP authenticator MUST NOT share EAP keying
> > material or parameters with another party, if the EAP peer or backend
> > authentication server detects use of EAP keying material and
> > parameters outside the scope defined by the NAS-Identifier, the
> > keying material MUST be considered compromised.
> >
>
> [Joe] The section should clarify that the keying material refers to keys
> derived from the EAP MSK that are transmitted to the authenticator.

Why are the considerations different for EMSK derived keys?  The AAA server 
still has to know who the keys are being sent to, or they can't be delivered 
(e.g. a proxy could be in the path).  The NAS-Identifier attribute tells the 
AAA server who that destination is.

> Is it possible for an authenticator to be distributed across several
> devices?  If so then the NAS identifiers may not be the best choice in
> these cases.  Also what should be used in the Security association
> protocol if there is no AAA client (collocated authenticator)?

The authenticator can only be distributed if the peer and server see it as a 
single entity, so that there is no indication that the keying material has 
been shared outside of the legal scope, which is defined by the 
NAS-Identifier.  If the keys are passed among entities that are identified 
as distinct authenticators, then the peer and server will detect that the 
keys have been compromised.

For example, it's ok for an authenticator's ports to be identified by 
distinct MAC addresses or IP addresses. Since an authenticator can have 
multiple ports. use of a different port authenticator doesn't imply a 
different authenticator.  But if multiple authenticators with different 
NAS-Identifiers possess the same key, then that indicates that those keys 
have been compromised.

> > It is possible for problems to arise in situations where the
> > backend server identifies itself differently to the EAP peer
> > and authenticator (e.g. where the Server-Id and backend authentication
> > server identity differ).
>
> [Joe] It would seem that currently they almost always differ since the
> back end server is identified by the IP address to the authenticator and
> by the EAP method to the peer.  What problems are you referring to?

The issue arises in situations where an entity needs to retrieve a key from 
the AAA server.  Since all AAA servers can't be assumed to share a key 
cache, the specific server on which the key resides needs to be identified.

A peer cannot ask an authenticator to retrieve a key unless it can provide 
both the Key Name and the server from which it needs to be retrieved.  In 
effect, the Peer-Id and Server-Id need to be part of the Key Name.

However, an authenticator cannot retrieve a key from the server if it has no 
way of mapping the Server-Id to a server that it recognizes.

In Diameter, server can be identified by name, since Diameter supports 
DNS-based service location as well as certificate authentication 
(altSubjectName).   So if the Server-Id is an FQDN, then the Diameter client 
can reach that server.

In RADIUS servers are identified only by IP address.  So presumably a RADIUS 
server would need to resolve the Server-Id FQDN to an IP address to figure 
out which server to make the key request to.  If the Server-Id and AAA 
server FQDN are different then the message may not be deliverable.

This issue is not purely academic -- it will come up in the EAPEXT BOF at 
IETF 66.


> > The following steps enable lower layer identities to be securely
> > verified by all parties:
> >
> [Joe] What does lower layer identities mean in this case?  Does this
> mean peer, authenticator and port identities?

I assume that we're talking about peer and authenticator identities.  
Comments below.

> > [a] Specifying the lower layer parameters used to identify the
> > authenticator and peer;

It is possible to uniquely identify an authenticator in multiple ways.  For 
example, a MAC address could be used, as long as it was associated with the 
entire authenticator and not just a port of it.

> > [b] Communicating the lower layer identities between the peer and
> > authenticator within phase 0;

If this is not done, then the peer may not know the authenticator scope.

> > [c] Communicating the lower layer authenticator identity between the
> > authenticator and backend server within the NAS-Identifier
> > attribute;

So whatever authenticator identity is chosen to be sent to the peer also 
needs to be sent to the backend server.

> [Joe] Is this necessary or desirable?  If the AAA server does not
> already what the NAS-ID associated with the NAS, is it OK for the NAS to
> assert this?  If the NAS can assert whatever it wants why are we
> bothering to do channel bindings?

RADIUS REQUIRES the NAS to identify itself, using NAS-Identifier, 
NAS-IPv6-Address or NAS-IPv4-Address.   However, if the NAS has more than 
one IP address, NAS-Identifier makes the most sense, regardless of any EAP 
considerations.   If there is a proxy present, then the proxy needs to 
validate the NAS-Identifier; by the time it gets to the AAA server, it is 
not possible to validate it.