eap Mailing List: Proposed Resolution to Issue 365: Ambiguous Use of Identifier

[Bernard Aboba (bernard_aboba]

The text of Issue 365 is enclosed below.   The proposed resolution is to 
rewrite Section 2.2.1 (now 2.2.2) as follows:

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

  The Secure Association Protocol  conversation is between the peer
  and the authenticator, and the authenticator and peer identities
  used within that exchange define the usage scope of the EAP
  keying material passed down to the lower layer.
  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.

  Since an authenticator may have multiple
  ports, the authenticator identifier used within the Secure
  Association Protocol exchange SHOULD be distinct from any port
  identifier (e.g. MAC 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
  peer identifier used within the Secure Association Protocol
  exchange SHOULD also be distinct from any port identifier.

  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 the unambiguous
  identification of the authenticator, both within the AAA
  protocol exchange the Secure Association Protocol conversation.

  It is RECOMMENDED that the EAP peer, authenticator and server
  use identities consistent between the conversation phases,
  in order to avoid a number of problems.  For example, 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).
  Problems may also arise where the peer
  and authenticator identify themselves within the lower layer
  using a port identifier such as a link layer address. These include
  the following issues:

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

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

[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;"
------------------------------------------------------------------------------------------------------------
Issue 365: Ambiguous Use of Identifier
Submitter name: Joe Salowey
Submitter email address: jsalowey [at] cisco.com
Date Submitted: May 2, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04268.html
Document: KEYING-12
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 2.2.1
Rationale/Explanation of issue:
Ambiguous use of "identifier":

It is not clear in this section what the identifier is and what it is
identifying.

Does this section mean to suggest that lower layer entities identify
themselves using NAS-ID instead of layer addresses?  I'm not sure that
this is a good thing or even really possible.  It seems that lower layer
entities will identify themselves based on something related to lower
layer addresses.  It seems that if a lower layer implements key caching
then it needs an identifier to identify the scope of the cache.  This
identifier can be the NAS-ID.

I'm not quite sure I understand this section, but I think it just needs
to be clearer about what identity is being talked about.

This section does not contain any description of how existing lower
layers deal with authenticator identity.  Are such examples available?