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

[Adrangi, Farid (farid.adrangi]

Looks reasonable to me.  Though I don't quite understand the last
comment:

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

Could you please elaborate?

BR,
Farid

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Bernard Aboba
> Sent: Monday, April 18, 2005 9:14 AM
> To: eap [at] frascone.com
> Subject: [eap] [Issue 297] Review of Identity Selection -12
> 
> 
> 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.
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>