Proposed Resolution to Issue 365: Ambiguous Use of Identifier

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: jsaloweycisco.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?

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

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

Proposed Resolution to Issue 365: Ambiguous Use of Identifier

Thread: Proposed Resolution to Issue 365: Ambiguous Use of Identifier