Abstract Current The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is especially useful when the access network does not have a direct roaming relationship with the peer's home network, so that a mediating network, such as a roaming consortium or broker, is used. Proposed 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. Current The mechanism defined in this document is primarily intended for advertising connectivity of access network to a limited number of roaming partners that find such advertisement useful. Proposed 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. 1. Introduction Current As a result, the peer may be unclear about the appropriate Network Access Identity (NAI) to include in an EAP-Response/Identity. Proposed In some cases, the peer may be uncertain which Network Access Identity (NAI) to include in an EAP-Response/Identity. Current This document defines a mechanism that allows the access network to provide identity selection hints, including information about its roaming relationships, to an EAP peer. Proposed 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. Current One possible application for this mechanism is to help an EAP peer in selecting what kind of NAI decoration [rfc2486bis] must be applied to allow proper routing of AAA messages to the home AAA server. If there are several possible mediating networks, the peer can choose which one to use. Proposed 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. Current For example, the peer could decide to use another identity it has, decide to switch to another access network, or attempt to reformat its NAI [rfc2486bis] to assist in proper AAA routing. Proposed For example, the peer could decide to use one of its other identities, decide to switch to another access network, or attempt to reformat its NAI [rfc2486bis] to assist in proper AAA routing. The exact client behaviour will be described by standard bodies using this specification, for example, 3GPP systems interworking with WLANs . Current Section 2 describes the required behavior of implementations of this Specification, as well as the packet format for structuring and presenting identity hint information to an EAP peer. Proposed 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. 1.1 Applicability Current Basic roaming and AAA routing mechanisms are normally sufficient, and the identity hints are typically useful only when there's too much ambiquity to try all client identities and access network combinations efficiently, or when the scale of the roaming associations precludes full automatic connectivity from all access networks to all home networks. 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 the situations mentioned above, a limited number of identity hints can be provided by the mechanism described in this document. Even in this case, for security reasons it is required that the networks that are listed in these hints consent to such advertisements. Proposed 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. Current Even in this case, for security reasons it is required that the networks that are listed in these hints consent to such advertisements. Proposed For security reasons, it is required that the networks listed in these hints consent to such advertisements. 2. Implementation requirements Current If after the local AAA proxy/server sends an EAP-Request/Identity containing an identity hint, the peer responds with an EAP-Response/Identity containing an unknown realm, then the local AAA proxy/server MAY respond immediately with an EAP Failure packet, or it MAY first send an EAP-Notification providing the reason for the failure. Proposed 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 MAY respond immediately with an EAP Failure packet. Alternatively, it MAY first send an EAP-Notification providing the reason for the failure. Current When RADIUS is used, State(24) attribute can be used to achieve this. Proposed When RADIUS is used, the State(24) attribute can be used to achieve this. Current EAP does not support fragmentation of EAP-Request/Identity messages, so that the maximum length of the identity hint information is limited by the link MTU. Proposed 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. 2.1 Packet format Current The Network-Info can contain NAIRealms list in addition to proprietary information. The proprietary information can be placed before or after NAIRealms list. To extract NAIRealms list, an implementation either finds the "NAIRealms=" immediately after the NUL or seeks forward to find ",NAIRealms" somewhere in the string. The realms data ends either at first "," or at the end of the string, whichever comes first. Proposed The Network-Info can contain an NAIRealms list in addition to proprietary information. The proprietary information can be placed before or after NAIRealms list. To extract NAIRealms list, an implementation can either find the "NAIRealms=" immediately after the NUL or seek forward to find ",NAIRealms" somewhere in the string.The realms data ends either at the first "," or at the end of the string, whichever comes first. 4. Security considerations Current Identity hint information is delivered inside an EAP-Request/Identity before the authentication conversation begins, and therefore can be modified by an attacker. Proposed Identity hint information is delivered inside an EAP-Request/Identity before the authentication conversation begins. Therefore, it can be modified by an attacker. Current Unauthenticated hints may result in peers inadvertently revealing additional identities, compromising privacy. Proposed Unauthenticated hints may result in peers inadvertently revealing additional identities, thus compromising privacy. Current Where the identity hint is used to select a mediating network, with existing EAP methods there may not be a way for the home AAA server to verify that the mediating network selected by the peer was actually used. Proposed If the identity hint is used to select a mediating network, existing EAP methods may not provide a way for the home AAA server to verify that the mediating network selected by the peer was actually used. Current For instance, revealing the existence of network that uses a poor authentication method can make it easier for attackers to discover that such network can be accessed. As a result, the consent of the network being advertised in the hints is required before such hints can be sent. Proposed For instance, revealing the existence of a network that uses a weak authentication method can make it easier for attackers to discover that such network is accessible. Therefore, the consent of the network being advertised in the hints is required before such hints can be sent. 6. Appendix - Delivery Options Current Although the delivery options are described in the context of IEEE 802.11 access networks, they are applicable to other access networks that use EAP [RFC3748] for authentication and use the NAI format [rfc2486bis] for identifying users. Proposed Although the delivery options are described in the context of IEEE 802.11 access networks, they are also applicable to other access networks that use EAP [RFC3748] for authentication and use the NAI format [rfc2486bis] for identifying users. Current " Also, the options assume that the AAA protocol in use is RADIUS xref target='RFC2865'/>. Diameter could also be used instead of RADIUS without introducing significant architectural differences. " Proposed " The options assume that the AAA protocol in use is RADIUS . However, Diameter could also be used instead of RADIUS without introducing significant architectural differences. " Current For example, the role of EAP server may be played by the EAP authenticator (where an initial EAP-Request/Identity is sent with an identity hint), or a RADIUS proxy/server (where the NAI Realm is used for forwarding). Proposed For example, the role of EAP server may be played by the EAP authenticator (where an initial EAP-Request/Identity is sent with an identity hint) or a RADIUS proxy/server (where the NAI Realm is used for forwarding).