Subject: [eap] Proposed Resolution to Issue 365: Ambiguous Use of Identifier

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 03 Jun 2006 19:40:01 -0700

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: [email-masked]
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?

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 04 Jun 2006 17:48:03 -0700

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?

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

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

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.