Network Working Group F. Adrangi
Request for Comments: 4284 V. Lortz
Category: Informational Intel
F. Bari
Cingular Wireless
P. Eronen
Nokia
January 2006
Network Working Group F. Adrangi
Request for Comments: 4284 V. Lortz
Category: Informational Intel
F. Bari
Cingular Wireless
P. Eronen
Nokia
January 2006
Identity Selection Hints for the Extensible Authentication Protocol (EAP)
可扩展身份验证协议（EAP）的标识选择提示
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
IESG Note:
IESG注：
EAP Identity Selection was developed by 3GPP. Documentation is provided as information to the Internet community. The EAP WG has verified that this specification is compatible with EAP as defined in RFC 3748. Required 3GPP client behavior is described in 3GPP TS 24.234.
EAP身份选择由3GPP开发。文档作为信息提供给互联网社区。EAP工作组已验证本规范与RFC 3748中定义的EAP兼容。3GPP TS 24.234中描述了所需的3GPP客户端行为。
Abstract
摘要
The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. 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 there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.
RFC 3748中定义了可扩展身份验证协议（EAP）。本文档定义了一种机制，允许接入网络向EAP对等方提供身份选择提示——响应身份验证器的链接的末端。目的是帮助EAP对等方选择适当的网络访问标识符（NAI）。这在对等方未接收到其连接到的网络的较低层指示的情况下，或者在接入网络和对等方的家庭网络之间没有直接漫游关系的情况下非常有用。在后一种情况下，认证通常通过中介网络（如漫游联盟或代理）完成。
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.
本文档中定义的机制在可扩展性方面受到限制。它适用于具有少量到中等数量的直接漫游伙伴的接入网络。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Relationship with Other Specifications .....................3
1.2. Applicability ..............................................3
1.3. Terminology ................................................4
2. Implementation Requirements .....................................4
2.1. Packet Format ..............................................5
3. Security Considerations .........................................6
4. Acknowledgements ................................................7
5. Appendix - Delivery Options .....................................8
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
1. Introduction ....................................................2
1.1. Relationship with Other Specifications .....................3
1.2. Applicability ..............................................3
1.3. Terminology ................................................4
2. Implementation Requirements .....................................4
2.1. Packet Format ..............................................5
3. Security Considerations .........................................6
4. Acknowledgements ................................................7
5. Appendix - Delivery Options .....................................8
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
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 of which Network Access Identifier (NAI) to include in an EAP-Response/Identity.
可扩展身份验证协议（EAP）在[RFC3748]中定义。EAP对等方（以下也称为对等方）可以具有多个凭证。如果较低层不提供其连接到哪个网络的指示，或者其归属网络可能与多个中介网络具有漫游关系，则对等方可能不确定要包括在EAP响应/标识中的哪个网络接入标识符（NAI）。
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.
本文档定义了一种机制，允许接入网络向EAP对等方提供身份选择提示，包括有关其漫游关系的信息。该信息通过在可显示消息和NUL字符后追加，在EAP请求/标识消息中发送给对等方。
This mechanism may assist the peer in selecting a credential and associated NAI, or in formatting the NAI [RFC4282] to facilitate routing of Authentication, Authorization, and Accounting (AAA) messages to the home AAA server. If there are several mediating networks available, the peer can influence which one is used.
该机制可协助对等方选择凭证和相关联的NAI，或格式化NAI[RFC4282]，以便于将认证、授权和记帐（AAA）消息路由到家庭AAA服务器。如果有多个中介网络可用，则对等方可以影响使用哪个中介网络。
Exactly how the selection is made by the peer depends largely on the peer's local policy and configuration, and is outside the scope of this document. 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 [RFC4282] to assist in proper AAA routing. The exact client behavior is described by standard bodies using this specification such as 3GPP [TS-24.234].
对等方做出选择的具体方式在很大程度上取决于对等方的本地策略和配置，不在本文档的范围内。例如，对等方可以决定使用其其他身份之一，决定切换到另一个接入网络，或者尝试重新格式化其NAI[RFC4282]，以帮助正确的AAA路由。使用本规范（如3GPP[TS-24.234]）的标准机构描述了确切的客户端行为。
Section 2 describes the required behavior of implementations, including the format for identity hints.
第2节描述了实现所需的行为，包括标识提示的格式。
This document specifies behavior of Remote Authentication Dial-In User Service (RADIUS) proxies that handle EAP messages. This includes the specification of the behavior of proxies in response to an unknown realm within the User-Name(1) attribute of an Access-Request containing one or more EAP-Message attributes. This document, if used in a scenario requiring NAI "decoration" as specified in [RFC4282], assumes a source-routing model for determination of the roaming relationship path, and therefore affects the behavior of RADIUS proxies in roaming situations.
本文档指定处理EAP消息的远程身份验证拨入用户服务（RADIUS）代理的行为。这包括指定代理响应包含一个或多个EAP消息属性的访问请求的用户名（1）属性中的未知领域的行为。如果在[RFC4282]中规定的需要NAI“修饰”的场景中使用此文档，则假定源路由模型用于确定漫游关系路径，因此会影响漫游情况下RADIUS代理的行为。
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 [RFC4282] 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].
在这种情况下，可以提供身份提示（例如，接入网络的漫游伙伴的列表）以使EAP对等方能够使用NAI[RFC4282]来指定所需的源路由来影响路由选择。建议机制的直接应用是在与wlan[TS-23.234]和[TS-24.234]互通的3GPP系统中。
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.
此机制可以提供的提示数量受EAP MTU的限制。例如，假设每个提示20个八位字节，EAP MTU为1096，则最多可以公布50个漫游伙伴。部署此解决方案时，应考虑EAP MTU施加的扩展限制。
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 points 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. In roaming situations, this can require the peer to try multiple points of attachment before it finds a compatible one, increasing handoff latency.
由于该机制依赖于EAP请求/身份分组中提供的信息，因此对等方必须在获得身份提示之前选择连接点。当存在多个可用的连接点时，本规范中定义的机制不允许对等方利用身份提示来决定选择哪个连接点。在漫游情况下，这可能需要对等方在找到兼容的连接点之前尝试多个连接点，从而增加切换延迟。
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
本文档涉及[netsel problem]中描述的一般网络发现和选择问题。本文中描述的拟议机制仅解决了[netsel问题]中的部分问题。IEEE 802.11也在研究更多
comprehensive and long-term solutions for network discovery and selection.
全面、长期的网络发现和选择解决方案。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
NAI Network Access Identifier [RFC4282].
NAI网络访问标识符[RFC4282]。
Decorated NAI An NAI specifying a source route. See [RFC4282] Section 2.7 for more information.
修饰NAI指定源路由的NAI。有关更多信息，请参见[RFC4282]第2.7节。
NAI Realm Realm portion of an NAI [RFC4282].
NAI领域NAI的领域部分[RFC4282]。
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(1) attribute in the request contains a realm for which there is no corresponding route.
EAP认证器可以在初始EAP请求/标识中向对等方发送标识提示。如果最初未发送标识提示（例如认证器不支持此规范时），则EAP对等方可能选择错误的NAI。如果本地AAA代理没有配置默认路由，那么它可能会发现请求中的用户名（1）属性包含一个没有相应路由的域。
As noted in [RFC2607], Section 5.1:
如[RFC2607]第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.
如果找不到路由，现有AAA代理通常会发送访问拒绝。但是，当请求包含EAP消息属性时，实现此规范的AAA代理应该使用包含标识提示的质询进行响应。
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.
例如，如果RADIUS代理接收到具有EAP消息属性和包含未知领域的用户名（1）属性的访问请求，则它应使用包含标识提示的EAP请求/标识数据包的EAP消息属性（而不是访问拒绝）来答复访问质询。有关消息流图，请参见附录中的“选项3”。
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.
如果在本地AAA代理发送标识提示后，对等方使用包含未知领域的EAP响应/标识进行响应，则实现此规范的本地AAA代理/服务器最终必须发送包含EAP故障的访问拒绝。在执行此操作之前，它可能会发送包含EAP通知的访问质询，以提供失败的解释。为了确定以前是否发送过标识提示，可以使用[RFC2865]中定义的状态（24）属性。
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.
如[RFC3748]第3.1节所述，EAP MTU的最小大小为1020个八位字节。EAP不支持EAP请求/标识消息的分段，因此标识提示信息的最大长度受链接MTU的限制。
The identity hint information is placed after the displayable string and a NUL character in the EAP-Request/Identity. The following ABNF [RFC4234] defines an NAIRealms attribute for presenting the identity hint information. The attribute's value consists of a set of realm names separated by a semicolon.
标识提示信息放在EAP请求/标识中的可显示字符串和NUL字符之后。以下ABNF[RFC4234]定义了一个NAIREAMS属性，用于显示标识提示信息。该属性的值由一组用分号分隔的领域名称组成。
identity-request-data = [ displayable-string ] %x00 [ Network-Info ]
identity-request-data = [ displayable-string ] %x00 [ Network-Info ]
displayable-string = *CHAR
displayable-string = *CHAR
Network-Info = "NAIRealms=" realm-list
Network-Info =/ 1*OCTET ",NAIRealms=" realm-list
Network-Info =/ "NAIRealms=" realm-list "," 1*OCTET
Network-Info =/ 1*OCTET ",NAIRealms=" realm-list "," 1*OCTET
Network-Info = "NAIRealms=" realm-list
Network-Info =/ 1*OCTET ",NAIRealms=" realm-list
Network-Info =/ "NAIRealms=" realm-list "," 1*OCTET
Network-Info =/ 1*OCTET ",NAIRealms=" realm-list "," 1*OCTET
realm-list = realm / ( realm-list ";" realm )
领域列表=领域/（领域列表“；”领域）
The "OCTET" and "CHAR" rules are defined in [RFC4234] and the "realm" rule is defined in [RFC4282].
“八位字节”和“字符”规则在[RFC4234]中定义，“领域”规则在[RFC4282]中定义。
A sample hex dump of an EAP-Request/Identity packet is shown below.
EAP请求/标识数据包的十六进制转储示例如下所示。
01 ; Code: Request 00 ; Identifier: 0 00 3f ; Length: 63 octets 01 ; Type: Identity 48 65 6c 6c 6f 21 00 4e ; "Hello!\0NAIRealms=example.com;mnc014. 41 49 52 65 61 6c 6d 73 ; mcc310.3gppnetwork.org" 3d 65 78 61 6d 70 6c 65 2e 63 6f 6d 3b 6d 6e 63 30 31 34 2e 6d 63 63 33 31 30 2e 33 67 70 70 6e 65 74 77 6f 72 6b 2e 6f 72 67
01 ; 代码：请求00；标识符：0 00 3f；长度：63个八位组01；类型：标识48 65 6c 6c 6f 21 00 4e；“你好！\0nairams=example.com；mnc014.41495265616c6d73；mcc310.3gppnetwork.org”3d 6578616d706c652e636f6d3b6d6e6331342e6d6333302e3367706e65746f726b6f7267
The Network-Info can contain an NAIRealms list in addition to proprietary information. The proprietary information can be placed before or after the NAIRealms list. To extract the 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.
除了专有信息外，网络信息还可以包含NAIRALMS列表。专有信息可以放在NAIREAMS列表之前或之后。要提取NAIRALMS列表，实现可以在NUL之后立即查找“NAIRALMS=”或在字符串中的某处查找“NAIRALMS”。域数据在第一个“，”或字符串末尾结束，以先到者为准。
Identity hint information is delivered inside an EAP-Request/Identity before the authentication conversation begins. Therefore, it can be modified by an attacker. The NAIRealms attribute therefore MUST be treated as a hint by the peer. That is, the peer must treat the hint as an unreliable indication
身份提示信息在认证对话开始之前在EAP请求/身份中传递。因此，攻击者可以对其进行修改。因此，对等方必须将nairams属性视为提示。也就是说，对等方必须将该提示视为不可靠的指示
Unauthenticated hints may result in peers inadvertently revealing additional identities, thus compromising privacy. Since the EAP-Response/Identity is sent in the clear, this vulnerability already exists. This vulnerability can be addressed via method-specific identity exchanges.
未经验证的提示可能会导致对等方无意中透露其他身份，从而损害隐私。由于EAP响应/标识以明文形式发送，因此此漏洞已经存在。可以通过方法特定的身份交换来解决此漏洞。
Similarly, in a situation where the peer has multiple identities to choose from, an attacker can use a forged hint to convince the peer to choose an identity bound to a weak EAP method. Requiring the use of strong EAP methods can protect against this. A similar issue already exists with respect to unprotected link-layer advertisements such as 802.11 SSIDs.
类似地，在对等方有多个标识可供选择的情况下，攻击者可以使用伪造提示说服对等方选择绑定到弱EAP方法的标识。要求使用强EAP方法可以防止这种情况。对于未受保护的链路层播发（如802.11 SSID），已经存在类似的问题。
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.
如果标识提示用于选择中介网络，则现有EAP方法可能无法为家庭AAA服务器提供验证对等方选择的中介网络是否已实际使用的方法。
Any information revealed either from the network or client sides before authentication has occurred can be seen as a security risk. For instance, revealing the existence of a network that uses a weak authentication method can make it easier for attackers to discover that such a network is accessible. Therefore, the consent of the network being advertised in the hints is required before such hints can be sent.
在进行身份验证之前，从网络或客户端泄露的任何信息都可能被视为安全风险。例如，暴露使用弱身份验证方法的网络的存在可以使攻击者更容易发现此类网络是可访问的。因此，在发送此类提示之前，需要在提示中通告的网络的同意。
The authors would especially like to thank Jari Arkko, Bernard Aboba, and Glen Zorn for their help in scoping the problem, and for reviewing the document in progress and suggesting improvements to it. The authors would also like to acknowledge and thank Adrian Buckley, Blair Bullock, Jose Puthenkulam, Johanna Wild, Joe Salowey, Marco Spini, Simone Ruffino, Mark Grayson, Mark Watson, and Avi Lior for their support, feedback, and guidance during the various stages of this work.
作者特别要感谢Jari Arkko、Bernard Aboba和Glen Zorn在确定问题范围方面的帮助，感谢他们审查了正在进行的文件并提出了改进建议。作者还想感谢阿德里安·巴克利、布莱尔·布洛克、何塞·普滕库拉姆、约翰娜·怀尔德、乔·萨洛维、马可·斯皮尼、西蒙娜·鲁菲诺、马克·格雷森、马克·沃森和阿维·利奥在这项工作的各个阶段所给予的支持、反馈和指导。
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 [RFC4282] for identifying users.
尽管在IEEE 802.11接入网络的上下文中描述了交付选项，但它们也适用于使用EAP[RFC3748]进行身份验证并使用NAI格式[RFC4282]识别用户的其他接入网络。
The options assume that the AAA protocol in use is RADIUS [RFC2865]. However, Diameter [RFC3588] could also be used instead of RADIUS without introducing significant architectural differences.
这些选项假定使用的AAA协议是RADIUS[RFC2865]。但是，也可以使用直径[RFC3588]代替半径，而不会引入显著的架构差异。
The main difference amongst the options is which entity in the access network creates the EAP-Request/Identity. For example, the role of the 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 NAIRealm is used for forwarding).
这些选项之间的主要区别在于接入网络中的哪个实体创建EAP请求/标识。例如，EAP服务器的角色可以由EAP验证器（其中初始EAP请求/标识与标识提示一起发送）或RADIUS代理/服务器（其中nairam用于转发）扮演。
The RADIUS proxy/server acts only on the RADIUS User-Name(1) attribute and does not have to parse the EAP-Message attribute.
RADIUS代理/服务器仅作用于RADIUS用户名（1）属性，不必解析EAP消息属性。
Option 1: Initial EAP-Request/Identity from the access point
选项1：来自接入点的初始EAP请求/标识
In typical IEEE 802.11 wireless LANs, the initial EAP-Request/ Identity is sent by the access point (i.e., EAP authenticator). In the simplest case, the identity hint information is simply included in this request, as shown below.
在典型的IEEE 802.11无线LAN中，初始EAP请求/标识由接入点（即EAP认证器）发送。在最简单的情况下，标识提示信息仅包含在该请求中，如下所示。
EAP Access Point local RADIUS home RADIUS
Peer proxy/server server
| 1. EAP | | |
| Request/Identity | | |
| (NAIRealms) | | |
|<------------------| | |
| 2. EAP | | |
| Response/Identity| | |
|------------------>| | |
| | 3. Access-Request | |
| | (EAP | |
| | Response/Identity)| |
| |------------------->| |
| | | 4. Access-Request |
| | | (EAP |
| | | Response/Identity) |
| | |------------------->|
| | | |
|<-------------------EAP conversation ----------------------->|
EAP Access Point local RADIUS home RADIUS
Peer proxy/server server
| 1. EAP | | |
| Request/Identity | | |
| (NAIRealms) | | |
|<------------------| | |
| 2. EAP | | |
| Response/Identity| | |
|------------------>| | |
| | 3. Access-Request | |
| | (EAP | |
| | Response/Identity)| |
| |------------------->| |
| | | 4. Access-Request |
| | | (EAP |
| | | Response/Identity) |
| | |------------------->|
| | | |
|<-------------------EAP conversation ----------------------->|
Current access points do not support this mechanism, so other options may be preferable. This option can also require configuring the identity hint information in a potentially large number of access points, which may be problematic if the information changes often.
当前的接入点不支持此机制，因此其他选项可能更可取。此选项还可能需要在大量访问点中配置标识提示信息，如果信息经常更改，则可能会出现问题。
Option 2: Initial EAP-Request/Identity from the local RADIUS proxy/ server
选项2：来自本地RADIUS代理/服务器的初始EAP请求/标识
This is similar to Option 1, but the initial EAP-Request/Identity is created by the local RADIUS proxy/server instead of the access point. Once a peer associates with an access network AP using IEEE 802.11 procedures, the AP sends an EAP-Start message [RFC3579] within a RADIUS Access-Request. The access network RADIUS server can then send the EAP-Request/Identity containing the identity hint information.
这与选项1类似，但初始EAP请求/标识由本地RADIUS代理/服务器而不是访问点创建。一旦对等方使用IEEE 802.11过程与接入网络AP关联，AP将在RADIUS接入请求中发送EAP启动消息[RFC3579]。然后，接入网RADIUS服务器可以发送包含标识提示信息的EAP请求/标识。
EAP Access Point local RADIUS home RADIUS
Peer proxy/server server
| | 1. Access-Request | |
| | (EAP-Start) | |
| |------------------->| |
| | 2. Access-Challenge| |
| | (EAP | |
| | Request/Identity | |
| | with NAIRealms) | |
| |<-------------------| |
| 3. EAP | | |
| Request/Identity | | |
| (NAIRealms) | | |
|<------------------| | |
| 4. EAP | | |
| Response/Identity | | |
|------------------>| | |
| | 5. Access-Request | |
| | (EAP | |
| | Response/Identity) | |
| |------------------->| |
| | | 6. Access-Request |
| | | (EAP |
| | | Response/Identity) |
| | |------------------->|
| | | |
|<------------------- EAP conversation ---------------------->|
EAP Access Point local RADIUS home RADIUS
Peer proxy/server server
| | 1. Access-Request | |
| | (EAP-Start) | |
| |------------------->| |
| | 2. Access-Challenge| |
| | (EAP | |
| | Request/Identity | |
| | with NAIRealms) | |
| |<-------------------| |
| 3. EAP | | |
| Request/Identity | | |
| (NAIRealms) | | |
|<------------------| | |
| 4. EAP | | |
| Response/Identity | | |
|------------------>| | |
| | 5. Access-Request | |
| | (EAP | |
| | Response/Identity) | |
| |------------------->| |
| | | 6. Access-Request |
| | | (EAP |
| | | Response/Identity) |
| | |------------------->|
| | | |
|<------------------- EAP conversation ---------------------->|
This option can work with current access points if they support the EAP-Start message.
如果当前接入点支持EAP启动消息，则此选项可用于当前接入点。
Option 3: Subsequent EAP-Request/Identity from local RADIUS proxy/ server
选项3：来自本地RADIUS代理/服务器的后续EAP请求/标识
In the third option, the access point sends the initial EAP-Request/ Identity without any hint information. The peer then responds with an EAP-Response/Identity, which is forwarded to the local RADIUS proxy/server. If the RADIUS proxy/server cannot route the message based on the identity provided by the peer, it sends a second EAP-Request/Identity containing the identity hint information.
在第三个选项中，接入点发送初始EAP请求/标识，而不发送任何提示信息。然后，对等方使用EAP响应/标识进行响应，该响应/标识被转发到本地RADIUS代理/服务器。如果RADIUS代理/服务器无法根据对等方提供的标识路由消息，它将发送第二个包含标识提示信息的EAP请求/标识。
EAP Access Point local RADIUS home RADIUS
Peer proxy/server server
| | | |
| 1. EAP | | |
| Request/Identity | | |
| (w/o NAIRealms) | | |
|<------------------| | |
| 2. EAP | | |
| Response/Identity | | |
|------------------>| | |
| | 3. Access-Request | |
| | (EAP | |
| | Response/Identity) | |
| |------------------->| |
| | 4. Access-Challenge| |
| | (EAP | |
| | Request/Identity | |
| | with NAIRealms) | |
| |<-------------------| |
| 5. EAP | | |
| Request/Identity | | |
| (NAIRealms) | | |
|<------------------| | |
| 6. EAP | | |
| Response/Identity | | |
|------------------>| | |
| | 7. Access-Request | |
| | (EAP | |
| | Response/Identity) | |
| |------------------->| |
| | | |
======================Failure due to unknown realm=============
| | | |
| | 7a. Access-Reject | |
| | (EAP-Failure) | |
| |<-------------------| |
| 7b. EAP | | |
| Failure | | |
|<------------------| | |
================================================================
| | | |
| | | 8. Access-Request |
| | | (EAP |
| | | Response/Identity) |
| | |------------------->|
| | | |
|<-------------------- EAP conversation --------------------->|
EAP Access Point local RADIUS home RADIUS
Peer proxy/server server
| | | |
| 1. EAP | | |
| Request/Identity | | |
| (w/o NAIRealms) | | |
|<------------------| | |
| 2. EAP | | |
| Response/Identity | | |
|------------------>| | |
| | 3. Access-Request | |
| | (EAP | |
| | Response/Identity) | |
| |------------------->| |
| | 4. Access-Challenge| |
| | (EAP | |
| | Request/Identity | |
| | with NAIRealms) | |
| |<-------------------| |
| 5. EAP | | |
| Request/Identity | | |
| (NAIRealms) | | |
|<------------------| | |
| 6. EAP | | |
| Response/Identity | | |
|------------------>| | |
| | 7. Access-Request | |
| | (EAP | |
| | Response/Identity) | |
| |------------------->| |
| | | |
======================Failure due to unknown realm=============
| | | |
| | 7a. Access-Reject | |
| | (EAP-Failure) | |
| |<-------------------| |
| 7b. EAP | | |
| Failure | | |
|<------------------| | |
================================================================
| | | |
| | | 8. Access-Request |
| | | (EAP |
| | | Response/Identity) |
| | |------------------->|
| | | |
|<-------------------- EAP conversation --------------------->|
This option does not require changes to existing NASes, so it may be preferable in many environments.
此选项不需要更改现有NASE，因此在许多环境中可能更可取。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607]Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[netsel-problem] Arkko, J. and B. Aboba, "Network Discovery and Selection Problem", Work in Progress, October 2005.
[netsel问题]Arkko，J.和B.Aboba，“网络发现和选择问题”，正在进行的工作，2005年10月。
[TS-23.234] 3GPP TS 23.234 V6.6.0, "3GPP System to Wireless Local Area Network (WLAN) interworking; System description (Release 6)", September 2005.
[TS-23.234]3GPP TS 23.234 V6.6.0，“3GPP系统到无线局域网（WLAN）互通；系统说明（第6版）”，2005年9月。
[TS-24.234] 3GPP TS 24.234 V6.4.0, "3GPP System to Wireless Local Area Network (WLAN) interworking; User Equipment (UE) to network protocols; Stage 3 (Release 6)", September 2005.
[TS-24.234]3GPP TS 24.234 V6.4.0，“3GPP系统到无线局域网（WLAN）互通；用户设备（UE）到网络协议；第3阶段（第6版）”，2005年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
Authors' Addresses
作者地址
Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA
Farid Adrangi Intel Corporation 2111美国希尔斯堡第25大道东北，邮编：97124
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Victor Lortz Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA
维克多·洛茨英特尔公司美国希尔斯伯勒第25大道东北2111号，邮编：97124
Phone: +1 503-264-3253
EMail: victor.lortz@intel.com
Phone: +1 503-264-3253
EMail: victor.lortz@intel.com
Farooq Bari Cingular Wireless 7277 164th Avenue N.E. Redmond, WA 98052 USA
法鲁克巴里Cingular无线7277美国华盛顿州雷德蒙东北164大街，邮编：98052
Phone: +1 425-580-5526
EMail: farooq.bari@cingular.com
Phone: +1 425-580-5526
EMail: farooq.bari@cingular.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰
EMail: pasi.eronen@nokia.com
EMail: pasi.eronen@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。