eap Mailing List: Proposed Resolution to Issue 322: Authenticator Architecture

[Bernard Aboba (bernard_aboba]

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: jsalowey [at] cisco.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