Subject: [eap] Proposed Resolution to Issue 322: Authenticator Architecture

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 05 Mar 2006 20:30:03 -0800

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Mar 2006 09:31:41 +0200

Looks good to me. --Jari

Bernard Aboba wrote:

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