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

[Joseph Salowey (jsalowey) (jsalowey]

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
> Sent: Sunday, June 11, 2006 8:32 PM
> To: Joseph Salowey (jsalowey); eap [at] frascone.com
> Subject: RE: [eap] Proposed Resolution to Issue 365: 
> Ambiguous Use ofIdentifier
> 
> > > 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.
> 

[Joe] I agree that the scope of EMSK derived keys must be defined,
however the details of how they are scoped is undefined.  How they are
distributed is undefined.  This will likely be defined on an application
by application basis.  NAS identifier will probably be appropriate for
some.  Others may not use a AAA protocol for key distribution or have a
scope that is larger, smaller or unrelated to a NAS.  I don't think this
document should put too many constraints on EMSK usage. 

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

[Joe] This seems somewhat arbitrary to me.  A peer could see multiple
AAA clients as the same authenticator entity if an attribute other than
the NAS-ID is used as the authenticator identity.  It seems that we may
be overloading NAS identifier.  

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

[Joe] It seems that this issue is somewhat out of scope of this document
since key caching in AAA is not currently defined.  

> 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.
> 
[Joe] OK, sounds interesting. 

> 
> > > 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.
> 
[Joe] the question still remains; If no-one is going to validate that
the NAS-Identifier actually is within scope of the authenticator then
why bother to use it channel bindings?