Proposed Resolution to Issue 322: Authenticator Architecture

The text of Issue 322 is enclosed below.   The proposed
resolution is to 
replace Section 2.4 with the following:

2.4.  Authenticator Architecture

   This specification does not impose constraints on the
architecture of
   the EAP authenticator or peer.  Any of the authenticator
   architectures described in [RFC4118] can be used.  For
example, it is
   possible for multiple base stations and a
"controller" (e.g. WLAN
   switch) to comprise a single EAP authenticator.  In such
a situation,
   the "base station identity" is irrelevant to
the EAP method
   conversation, except perhaps as an opaque blob to be used
in Channel
   Bindings.  Many base stations can share the same
authenticator
   identity.  As a result, lower layers need to identify EAP
peers and
   authenticators unambiguously, without incorporating
implicit
   assumptions about peer and authenticator architectures.

   It should be understood that an EAP authenticator or
peer:

   [a] may contain one or more physical or logical ports;
   [b] may advertise itself as one or more
"virtual"
       authenticators or peers;
   [c] may utilize multiple CPUs;
   [d] may support clustering services for load balancing or
failover.

   Both the EAP peer and authenticator may have more than
one physical
   or logical port.  A peer may simultaneously access the
network via
   multiple authenticators, or via multiple physical or
logical ports on
   a given authenticator.  Similarly, an authenticator may
offer network
   access to multiple peers, each via a separate physical or
logical
   port.  When a single physical authenticator advertises
itself as
   multiple "virtual authenticators",  it is
possible for a single
   physical port to belong to multiple "virtual
authenticators".  The
   situation is illustrated in Figure 5.

                               +-+-+-+-+
                               | EAP   |
                               | Peer  |
                               +-+-+-+-+
                                 | | |  Peer Ports
                                /  |  \
                               /   |   \
                              /    |    \
                             /     |     \
                            /      |      \
                           /       |       \
                          /        |        \
                         /         |         \
                      | | |      | | |      | | |
Authenticator Ports
                    +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                    |       |  |       |  |       |
                    | Auth. |  | Auth. |  | Auth. |
                    |       |  |       |  |       |
                    +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                         \         |         /
                          \        |        /
                           \       |       /
             EAP over AAA   \      |      /
               (optional)    \     |     /
                              \    |    /
                               \   |   /
                                \  |  /
                               +-+-+-+-+
                               |  EAP  |
                               |Server |
                               +-+-+-+-+

   Figure 5:  Relationship between EAP peer, authenticator
and server

2.4.1.  Authenticator Identification

   The EAP method conversation is between the EAP peer and
server, as
   identified by the Peer-ID and Server-ID.  The
authenticator identity,
   if considered at all by the EAP method, is treated as an
opaque blob
   for the purposes of Channel bindings.  However, the
Secure
   Association Protocol conversation is between the peer and
the
   authenticator, and therefore the authenticator and peer
identities
   are relevant to that exchange, and define the scope of
use of the EAP
   keying material passed down to the lower layer.

   Since an authenticator may have multiple ports, the
authenticator
   identifiers 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.

   Where the peer and authenticator identify themselves
within the lower
   layer using a port identifier such as a link layer
address, this
   creates a number of problems:

[1]  It may not be obvious to the peer which authenticator
ports are
     associated with which authenticators.

[2]  It may not be obvious to the authenticator which peer
ports are
     associated with which peers.

[3]  It may not be obvious to the peer which "virtual
authenticator" it
     is communicating with.

[4]  It may not be obvious to the authenticator which
"virtual peer" it
     is communicating with.

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

     From the point of view of the AAA 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 AAA server detects use of EAP keying
material and
     parameters outside the scope defined by the
NAS-Identifier, the
     keying material MUST be considered compromised.

------------------------------------------------------------
--------------------------------------------------
Issue 322: Authenticator Architecture
Submitter name: Joe Salowey
Submitter email address: jsaloweycisco.com
Date Submitted: December 1, 2005
Reference:
Document: Keying-08
Comment type: T
Priority: 1
Section: 2.4
Rationale/Explanation of issue:

There is a lot of discussion about authenticator
architecture which
probably should be pulled into a separate section on
authenticator
architecture.

Requested change:

Move the description of authenticator architecture to its
own section

____________________________________________________________
_____
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 322: Authenticator Architecture

Thread: Proposed Resolution to Issue 322: Authenticator Architecture