eap Mailing List: [Issue 297] Review of Identity Selection -12

[Bernard Aboba (aboba]

Issue 297: Review of Identity Selection -12
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: 4/18/2005
Reference:
Document: IDSEL-12
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

Abstract

"The purpose is to
assist the EAP peer in selecting an appropriate Network Access
Identifier (NAI) when there is no direct roaming relationship between
the access network and the peer's home network.  In this case,
authentication is typically accomplished via a mediating network such
as a roaming consortium or broker.

The mechanism defined in this document is limited in its scalability.
It is intended for access networks that have a small to moderate
number of direct roaming partners."

The hint can be useful in other cases too, no? For example, when
EAP is used on Ethernet, the client receives no indication of what
network it is connected to.

Suggest rewriting to:

"The purpose is to assist the EAP peer in selecting an
appropriate Network Access Identifier (NAI).  This is useful
in situations where the peer does not receive a lower layer
indication of what network it is connecting to, or when a
mediating network (such as a roaming consortium or broker)
is present, so that there is no direct roaming relationship
between the access network and the peer's home network.

Since the mechanism in this document requires the authenticator
to provide a complete network list (rather than allowing the
peer to indicate which networks it is interested in), it
has limited scalability.  The mechanism is therefore intended
for access networks that have a small to moderate number of
direct roaming partners."

Section 1

"   An EAP peer (hereafter, also referred to as the peer) can have
   several sets of credentials, and its home network may have roaming
   relationships with several mediating networks.  In some cases, the
   peer may be uncertain which Network Access Identity (NAI) to include
   in an EAP-Response/Identity.

   The Extensible Authentication Protocol (EAP) is defined in [RFC3748].
   This document defines a mechanism that allows the access network to
   provide an EAP peer with identity selection hints, including
   information about its roaming relationships.  This information is
   sent to the peer in an EAP-Request/Identity message by appending it
   after the displayable message and a NUL character.

   One possible application for this mechanism is to help an EAP peer
   perform NAI decoration [rfc2486bis] to facilitate routing of AAA
   messages to the home AAA server.  If there are several possible
   mediating networks, the peer can use this method to influence which
   one is used."

Again, there are other situations in which the peer may be uncertain about
which NAI to include.  Suggest rewriting to:

"  The Extensible Authentication Protocol (EAP) is defined in [RFC3748].
   An EAP peer (hereafter, also referred to as the peer) may have
   multiple credentials.  Where the lower layer does not provide
   an indication of which network it is connecting to, or where its
   home network may have roaming relationships with several
   mediating networks, the peer may be uncertain which Network
   Access Identity (NAI) to include in an EAP-Response/Identity.

   This document defines a mechanism that allows the access network to
   provide an EAP peer with identity selection hints, including
   information about its roaming relationships.  This information is
   sent to the peer in an EAP-Request/Identity message by appending it
   after the displayable message and a NUL character.

   This mechanism may assist the peer in selecting a credential and
   associated NAI, or in formating the NAI [RFC2486bis] to facilitate
   routing of AAA messages to the home AAA server.  If there are
   several mediating networks available, the peer can influence which
   one is used."

"  Section 2 describes the required behavior of implementations of this
   Specification, including the packet format for structuring and
   presenting identity hint information to an EAP peer."

Suggest rewriting to:

"  Section 2 describes the required behavior of implementations,
   including the format for identity hints."

Section 1.1

"  The identity hints are typically useful only when there's too much
   ambiguity for an access network to determine how to route the AAA
   packet.  This can happen, for instance, when  access networks have
   contracts with multiple roaming consortiums but do not have a full
   list of home networks reachable through them.

   In such scenarios, a limited number of identity hints (e.g., a list
   of roaming partners of the access network) can be provided by the
   mechanism to enable the EAP peer to influence routing of AAA packets.
   The immediate application of the proposed mechanism is in 3GPP
   systems interworking with WLANs [TS 23.234] and [TS 24.234].

   The roaming partner information provided via this mechanism is
   limited by the link layer MTU size.  For example, assuming an average
   of 20 octets per roaming partner / home network information and the
   link layer MTU size of 1096, the approximate number of roaming
   partners that can be advertised would be 50.  The scalability
   limitation imposed by the link layer MTU size should be taken into
   consideration when deploying this solution.

   This document is also related to the general network discovery and
   selection problem described in [netsel-problem].  The proposed
   mechanism described in this document solves only a part of the
   problem in [netsel-problem].  IEEE 802.11 is also looking into more
   comprehensive and long-term solutions for network discovery and
   selection."

I think you also need to mention the implications for handoff latency.
Suggest rewriting to:

"  Identity hints are useful in situations where the peer cannot
   determine which credentials to use, or where there may be multiple
   alternative routes by which an access network can reach a home
   network.  This can occur when access networks support
   multiple roaming consortiums but do not have a full
   list of the home networks reachable through them.

   In such scenarios, identity hints (e.g., a list of roaming
   partners of the access network) can be provided to enable
   the EAP peer to influence route selection, using the NAI
   [RFC2486bis] to specify the desired source route. The
   immediate application of the proposed mechanism is in 3GPP
   systems interworking with WLANs [TS 23.234] and [TS 24.234].

   The number of hints that can be provided by this mechanism is
   limited by the EAP MTU.  For example, assuming 20 octets per
   hint and an EAP MTU of 1096, a maximum of 50 roaming partners
   can be advertised.  Scaling limitations imposed by the EAP MTU
   should be taken into account when deploying this solution.

   Since this mechanism relies on information provided in the
   EAP-Request/Identity packet, it is necessary for the peer to
   select a point of attachment prior to obtaining identity
   hints.  Where there are multiple point of attachment available,
   the mechanism defined in this specification does not allow
   the peer to utilize the identity hints in making a decision
   about which point of attachment to select.  This can require
   the peer to try multiple points of attachment before it finds
   a compatible one, increasing handoff latency.

   This document is related to the general network discovery and
   selection problem described in [netsel-problem].  The proposed
   mechanism described in this document solves only a part of the
   problem in [netsel-problem].  IEEE 802.11 is also looking into more
   comprehensive and long-term solutions for network discovery and
   selection."

Section 1.2

"   Decorated NAI   An NAI with additional information for influencing
                   AAA routing.  Please refer to section 2.7 of
                   [rfc2486bis] for its construction."

Suggest rewriting to:

"   Decorated NAI  An NAI specifying a source route.  See [RFC2486bis]
                   section 2.7 for more information."

Section 2

"  The EAP authenticator MAY send an identity hint to the peer in the
   initial EAP-Request/Identity.  If the identity hint is not sent
   initially (such as when the authenticator does not support this
   specification), then if the local EAP-aware AAA proxy/server
   implementing this specification receives an AAA Request packet with
   an unknown realm, it SHOULD reply with an EAP-Request/Identity
   containing an identity hint.  For example, in case of RADIUS, if the
   EAP-aware RADIUS proxy/server [RFC3579] receives an Access-Request
   packet with an unknown realm in the UserName(1) attribute, then it
   can reply with an EAP-Request/Identity containing an identity hint
   within an Access-Challenge packet.  See "option 3" in the appendix
   for the message flow diagram.

   If the peer responds with an EAP-Response/Identity containing an
   unknown realm after the local AAA proxy/server sends an identity
   hint, then the local AAA proxy/server MUST respond with an EAP
   Failure packet.  The local AAA proxy/server MAY also send an EAP-
   Notification message providing the reason for the failure prior to
   the EAP Failure packet.

   When an Identity hint is sent by a AAA proxy/server, the AAA proxy/
   server MUST be able to determine if an identity hint had previously
   been sent by it to the EAP peer.  When RADIUS is used, the State(24)
   attribute can be used to achieve this.

   As noted in [RFC3748], Section 3.1, the minimum EAP MTU size is 1020
   octets.  EAP does not support fragmentation of EAP-Request/Identity
   messages, so the maximum length of the identity hint information is
   limited by the link MTU."

Existing RADIUS proxies do not look at the contents of EAP packets,
nor are they required to be aware of all the realms that they need
to support.  Typically the realm list configured on the proxy includes
a default route that will be used if the realm is not recognized.
The paragraph above appears to imply that such a default route cannot
be configured, or that RADIUS proxies implementing this specification
need to parse EAP packets.  Suggest rewriting to:


"  The EAP authenticator MAY send an identity hint to the peer in the
   initial EAP-Request/Identity.  If the identity hint is not sent
   initially (such as when the authenticator does not support this
   specification), then the EAP peer may select the wrong NAI.  If
   the local AAA proxy does not have a default route configured,
   then it may find that the User-Name attribute in the request
   contains a realm for which there is no corresponding route.

   As noted in [RFC2607], Section 5.1:

    Proxies are frequently used to implement policy in roaming
    situations.  Proxies implementing policy MAY reply directly to
    Access-Requests without forwarding the request. When replying
    directly to an Access-Request, the proxy MUST reply either with an
    Access-Reject or an Access-Challenge packet. A proxy MUST NOT reply
    directly with an Access-Accept."

   Where no route is found, existing AAA proxies will typically send
   an Access-Reject.   However, where the request contains an EAP-Message
   attribute, AAA proxies implementing this specification should instead
   reply with a Challenge including an identity hint.

   For example, if a RADIUS proxy receives an Access-Request
   with an EAP-Message attribute and a User-Name(1) attribute
   containing an unknown realm, it SHOULD reply with an Access-Challenge
   with an EAP-Message attribute encapsulating an EAP-Request/Identity
   packet containing an identity hint, rather than an Access-Reject.
   See "option 3" in the appendix for the message flow diagram.

   If the peer responds with an EAP-Response/Identity containing an
   unknown realm after the local AAA proxy sends an identity
   hint, then a local AAA proxy/server implementing this specification
   MUST eventually send an Access-Reject containing an EAP-Failure.
   Prior to doing so it MAY send an Access-Challenge containing an
   EAP-Notification, in order to provide an explanation for the failure.
   In order to determine whether an identity hint had been previously
   sent, the State(24) attribute defined in [RFC2865] can be used.

   As noted in [RFC3748], Section 3.1, the minimum EAP MTU size is 1020
   octets.  EAP does not support fragmentation of EAP-Request/Identity
   messages, so the maximum length of the identity hint information is
   limited by the link MTU."

Given that this specification changes AAA proxy behavior, I believe
that it should include "Updates: 2607" in the header.