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

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 18 Apr 2005 10:19:16 -0700

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Apr 2005 12:09:36 -0700 (PDT)

> Could you please elaborate?

RFC 2607 is the document that specifies RADIUS proxy behavior in roaming
environments.  This document appears compatible with RFC 2607, but it does
specify additional proxy behavior (e.g. sending a Challenge with a hint
instead of Access-Reject).