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

[Joseph Salowey (jsalowey) (jsalowey]

Hi Bernard,

I think this looks better with respect to identifier terminology.
Additional comments and questions in line below: 

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
> Sent: Sunday, June 04, 2006 5:48 PM
> To: bernard_aboba [at] hotmail.com; eap [at] frascone.com
> Subject: Re: [eap] Proposed Resolution to Issue 365: 
> Ambiguous Use ofIdentifier
> 
> Looking over the proposed resolution, I think we can make it 
> moreclear that 
> we are not talking about replacing endpoint addresses with 
> names.  How about 
> this?
> 
> "2.2.2. Authenticator and Peer Identification
> 
> The EAP method conversation is between the EAP peer and server. The
> authenticator identity, if considered at all by the EAP method, is
> treated as an opaque blob for the purposes of Channel Bindings (see
> Section 5.12). However, the authenticator identity is important in
> two other exchanges - the AAA protocol exchange and the Secure
> Association Protocol conversation.
> 
> 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.

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 Secure Association Protocol conversation is between the peer and
> the authenticator. For lower layers which support key caching it
> is particularly important for the EAP peer, authenticator and backend
> server to have a consistent view of the usage scope of the transported
> EAP keying material.  In order to enable this, it is RECOMMENDED
> that the Secure Association Protocol explicitly communicate the
> usage scope of the EAP keying material passed down to the lower
> layer, rather than implicitly assuming that this is defined by
> the authenticator and peer endpoint addresses.
> 
> Since an authenticator may have multiple ports, the scope of the
> authenticator key cache may not be described by a single endpoint
> address.  Similarly, where a peer may have multiple ports and
> sharing of EAP keying material and parameters between peer ports
> of the same link type is allowed, the extent of the peer key cache
> cannot be communicated by using a single endpoint address.
> Instead, it is RECOMMENDED that the EAP peer, authenticator and server
> consistently identify themselves utilizing explicit identifiers that
> SHOULD be  distinct from endpoint addresses or port identifiers
> (e.g. IP or MAC addresses).
> 
> AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
> a mechanism for the identification of AAA clients; since the EAP
> authenticator and AAA client are always co-resident, this mechanism
> is applicable to the identification of EAP authenticators.
> 
> RADIUS [RFC2865] requires that an Access-Request packet contain one
> or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
> attributes. Since a NAS may have more than one IP address, the
> NAS-Identifier attribute is RECOMMENDED for explicit identification
> of the authenticator, both within the AAA protocol exchange and
> the Secure Association Protocol conversation.
> 
> 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?

> Problems which may arise where the peer and
> authenticator implicitly identify themselves using endpoint addresses
> include the following:
> 
> [a] It may not be obvious to the peer which authenticator ports are
> associated with which authenticators.  The EAP peer will be unable
> to determine whether EAP keying material has been shared outside
> its authorized scope, and needs to be considered compromised. The
> EAP peer may also be unable to utilize the authenticator key cache
> in an efficient way.
> 
> [b] It may not be obvious to the authenticator which peer ports are
> associated with which peers. As a result, the authenticator may
> not be able to enable a peer to communicate with it utilizing
> multiple peer ports.
> 
> [c] It may not be obvious to the peer which "virtual authenticator" it
> is communicating with. For example, multiple "virtual
> authenticators" may share a MAC address, but utilize different
> NAS-Identifiers.
> 
> [d] It may not be obvious to the authenticator which "virtual peer" it
> is communicating with. Multiple "virtual peers" may share a MAC
> address, but utilize different Peer-Ids.
> 
> [e] It may not be possible for the EAP peer and server to verify the
> authenticator identity via channel bindings.
> 
> For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which
> utilizes peer and authenticator MAC addresses within the 4-way
> handshake. Problems [b] and [d] do not occur since [IEEE-802.11i]
> only allows a peer to utilize a single port.
> 
> 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?

> [a] Specifying the lower layer parameters used to identify the
> authenticator and peer;
> 
> [b] Communicating the lower layer identities between the peer and
> authenticator within phase 0;
> 
> [c] Communicating the lower layer authenticator identity between the
> authenticator and backend server within the NAS-Identifier
> attribute;
> 

[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?

> [d] Including the lower layer identities within Channel Bindings (if
> supported) in phase 1a, ensuring that they are communicated between
> the EAP peer and server;
> 
> [e] Supporting the integrity-protected exchange of identities within
> phase 2a;
> 
> [f] Utilizing the advertised lower layer identities to enable the peer
> and authenticator to verify that keys are maintained within the
> advertised scope;"
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>