Network Working Group F. Adrangi
Request for Comments: 4372 Intel
Category: Standards Track A. Lior
Bridgewater Systems
J. Korhonen
Teliasonera
J. Loughney
Nokia
January 2006
Network Working Group F. Adrangi
Request for Comments: 4372 Intel
Category: Standards Track A. Lior
Bridgewater Systems
J. Korhonen
Teliasonera
J. Loughney
Nokia
January 2006
Chargeable User Identity
收费用户身份
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network.
本文档介绍了一种新的远程身份验证拨入用户服务（RADIUS）属性，即付费用户标识。家庭网络可以使用此属性来识别用户，以便在家庭网络之外进行漫游事务。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Motivation .................................................3
1.2. Terminology ................................................4
2. Operation .......................................................5
2.1. Chargeable-User-Identity (CUI) Attribute ...................5
2.2. CUI Attribute ..............................................6
3. Attribute Table .................................................7
4. Diameter Consideration ..........................................7
5. IANA Considerations .............................................7
6. Security Considerations .........................................7
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
1. Introduction ....................................................2
1.1. Motivation .................................................3
1.2. Terminology ................................................4
2. Operation .......................................................5
2.1. Chargeable-User-Identity (CUI) Attribute ...................5
2.2. CUI Attribute ..............................................6
3. Attribute Table .................................................7
4. Diameter Consideration ..........................................7
5. IANA Considerations .............................................7
6. Security Considerations .........................................7
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM and EAP-AKA, can hide the true identity of the user from RADIUS servers outside of the user's home network. In these methods, the User-Name(1) attribute contains an anonymous identity (e.g., @example.com) sufficient to route the RADIUS packets to the home network but otherwise insufficient to identify the user. While this mechanism is good practice in some circumstances, there are problems if local and intermediate networks require a surrogate identity to bind the current session.
一些身份验证方法，包括EAP-PEAP、EAP-TTLS、EAP-SIM和EAP-AKA，可以在用户家庭网络之外的RADIUS服务器上隐藏用户的真实身份。在这些方法中，用户名（1）属性包含一个匿名标识（例如，@example.com），该标识足以将RADIUS数据包路由到家庭网络，但在其他方面不足以识别用户。虽然这种机制在某些情况下是良好的做法，但如果本地和中间网络需要代理身份来绑定当前会话，则会出现问题。
This document introduces an attribute that serves as an alias or handle (hereafter, it is called Chargeable-User-Identity) to the real user's identity. Chargeable-User-Identity can be used outside the home network in scenarios that traditionally relied on User-Name(1) to correlate a session to a user.
本文档介绍了一个属性，该属性用作真实用户身份的别名或句柄（以下称为“付费用户身份”）。在传统上依赖用户名（1）将会话与用户关联的场景中，可在家庭网络之外使用收费用户身份。
For example, local or intermediate networks may limit the number of simultaneous sessions for specific users; they may require a Chargeable-User-Identity in order to demonstrate willingness to pay or otherwise limit the potential for fraud.
例如，本地或中间网络可以限制特定用户的同时会话的数量；他们可能需要付费用户身份，以证明愿意支付或以其他方式限制欺诈的可能性。
This implies that a unique identity provided by the home network should be able to be conveyed to all parties involved in the roaming transaction for correlating the authentication and accounting packets.
这意味着由归属网络提供的唯一身份应当能够被传送到漫游事务中涉及的所有各方，以关联认证和记帐分组。
Providing a unique identity, Chargeable-User-Identity (CUI), to intermediaries, is necessary to fulfill certain business needs. This should not undermine the anonymity of the user. The mechanism provided by this document allows the home operator to meet these business requirements by providing a temporary identity representing the user and at the same time protecting the anonymity of the user.
为中介机构提供唯一的身份，即付费用户身份（CUI），是满足某些业务需求所必需的。这不应破坏用户的匿名性。本文件提供的机制允许家庭运营商通过提供代表用户的临时身份来满足这些业务需求，同时保护用户的匿名性。
When the home network assigns a value to the CUI, it asserts that this value represents a user in the home network. The assertion should be temporary -- long enough to be useful for the external applications and not too long such that it can be used to identify the user.
当家庭网络为CUI指定值时，它会断言该值表示家庭网络中的用户。断言应该是临时的——足够长以便对外部应用程序有用，而不是太长以便可以用来识别用户。
Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance, and IRAP, have been studying mechanisms to provide roaming services, using RADIUS. Missing elements include mechanisms for billing and fraud prevention.
包括WISPr、GSMA、3GPP、Wi-Fi联盟和IRAP在内的多个组织一直在研究使用RADIUS提供漫游服务的机制。缺少的要素包括计费和欺诈预防机制。
The CUI attribute is intended to close operational loopholes in RADIUS specifications that have impacted roaming solutions negatively. Use of the CUI is geared toward EAP methods supporting privacy (such as PEAP and EAP-TTLS), which are, for the most part, recent deployments. A chargeable identity reflecting the user profile by the home network is needed in such roaming scenarios.
CUI属性旨在弥补RADIUS规范中对漫游解决方案产生负面影响的操作漏洞。CUI的使用面向支持隐私的EAP方法（如PEAP和EAP-TTLS），这在很大程度上是最近的部署。在这种漫游场景中，需要一个反映家庭网络的用户配置文件的收费身份。
Some other mechanisms have been proposed in place of the CUI attribute. These mechanisms are insufficient or cause other problems. It has been suggested that standard RADIUS Class(25) or User-Name(1) attributes could be used to indicate the CUI. However, in a complex global roaming environment where there could be one or more intermediaries between the NAS [RFC4282] and the home RADIUS server, the use of aforementioned attributes could lead to problems as described below.
已经提出了一些其他机制来代替CUI属性。这些机制不足或导致其他问题。建议使用标准半径类（25）或用户名（1）属性来指示CUI。然而，在复杂的全局漫游环境中，NAS[RFC4282]和主RADIUS服务器之间可能存在一个或多个中介，使用上述属性可能会导致如下所述的问题。
- On the use of RADIUS Class(25) attribute:
- 关于半径类（25）属性的使用：
[RFC2865] states: "This Attribute is available to be sent by the server to the client in an Access-Accept packet and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported. The client MUST NOT interpret the attribute locally." So RADIUS clients or intermediaries MUST NOT interpret the Class(25) attribute, which precludes determining whether it contains a CUI. Additionally, there could be multiple class attributes in a RADIUS packet, and since the contents of Class(25) attribute is not to be interpreted by clients, this makes it hard for the entities outside the home network to determine which one contains the CUI.
[RFC2865]声明：“此属性可由服务器在访问接受数据包中发送到客户端，如果支持记帐，则客户端应将其作为记帐请求数据包的一部分发送到记帐服务器，而不进行修改。客户端不得在本地解释该属性。”因此，RADIUS客户机或中介机构不得解释Class（25）属性，这会妨碍确定它是否包含CUI。此外，RADIUS数据包中可能有多个类属性，并且由于类（25）属性的内容不由客户端解释，这使得家庭网络之外的实体很难确定哪一个包含CUI。
- On the use of RADIUS User-Name(1) attribute:
- 关于RADIUS用户名（1）属性的使用：
The User-Name(1) attribute included in the Access-Request packet may be used for the purpose of routing the Access-Request packet, and in the process may be rewritten by intermediaries. As a result, a RADIUS server receiving an Access-Request packet relayed by a proxy cannot assume that the User-Name(1) attribute remained unmodified.
包括在接入请求分组中的用户名（1）属性可用于路由接入请求分组的目的，并且在该过程中可由中介重写。因此，接收代理转发的访问请求数据包的RADIUS服务器不能假定用户名（1）属性保持不变。
On the other hand, rewriting of a User-Name(1) attribute sent within an Access-Accept packet occurs more rarely, since a Proxy-State(33) attribute can be used to route the Access-Accept packet without parsing the User-Name(1) attribute. As a result, a RADIUS server cannot assume that a proxy stripping routing information from a User-Name(1) attribute within an Access-Request packet will add this information to a User-Name(1) attribute
另一方面，在访问接受分组内发送的用户名（1）属性的重写发生得更为罕见，因为代理状态（33）属性可用于路由访问接受分组而不解析用户名（1）属性。因此，RADIUS服务器无法假定从访问请求数据包内的用户名（1）属性中剥离路由信息的代理将此信息添加到用户名（1）属性中
included within an Access-Accept packet. The result is that when a User-Name(1) attribute is sent in an Access-Accept packet, it is possible that the Access-Request packet and Accounting-Request packets will follow different paths. Where this outcome is undesirable, the RADIUS client should use the original User-Name(1) in accounting packets. Therefore, another mechanism is required to convey a CUI within an Access-Accept packet to the RADIUS client, so that the CUI can be included in the accounting packets.
包含在访问接受数据包中。结果是，当在接入接受分组中发送用户名（1）属性时，接入请求分组和记帐请求分组可能遵循不同的路径。如果不希望出现这种结果，RADIUS客户端应在记帐数据包中使用原始用户名（1）。因此，需要另一种机制将访问接受数据包中的CUI传送到RADIUS客户端，以便CUI可以包括在记帐数据包中。
The CUI attribute provides a solution to the above problems and avoids overloading RADIUS User-Name(1) attribute or changing the usage of existing RADIUS Class(25) attribute. The CUI therefore provides a standard approach to billing and fraud prevention when EAP methods supporting privacy are used. It does not solve all related problems, but does provide for billing and fraud prevention.
CUI属性提供了上述问题的解决方案，并避免了重载RADIUS用户名（1）属性或更改现有RADIUS类（25）属性的用法。因此，当使用支持隐私的EAP方法时，CUI为计费和欺诈预防提供了标准方法。它不能解决所有相关问题，但提供了计费和欺诈预防。
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]中所述进行解释。
The following acronyms are used:
使用以下首字母缩略词：
3GPP - Third Generation Partnership Project AAA - Authentication, Authorization, and Accounting AKA - Authentication and Key Agreement CUI - Chargeable-User-Identity GSMA - GSM Association IRAP - International Roaming Access Protocols Program NAS - Network Access Server PEAP - Protected Extensible Authentication Protocol SIM - Subscriber Identity Modules TTLS - Tunneled Transport Layer Security WISPr - Wireless ISP Roaming WPA - Wi-Fi Protected Access
3GPP-第三代合作伙伴项目AAA-认证、授权、，和会计AKA-身份验证和密钥协议CUI-收费用户身份GSMA-GSM协会IRAP-国际漫游访问协议计划NAS-网络访问服务器PEAP-受保护的可扩展身份验证协议SIM-用户身份模块TTLS-隧道传输层安全WISPr-无线ISP漫游WPA-受Wi-Fi保护的访问
This document assumes that the RADIUS protocol operates as specified in [RFC2865] and [RFC2866], dynamic authorization as specified in [RFC3576], and the Diameter protocol as specified in [RFC3588].
本文件假设RADIUS协议按照[RFC2865]和[RFC2866]的规定运行，动态授权按照[RFC3576]的规定运行，Diameter协议按照[RFC3588]的规定运行。
The CUI attribute serves as an alias to the user's real identity, representing a chargeable identity as defined and provided by the home network as a supplemental or alternative information to User-Name(1). Typically, the CUI represents the identity of the actual user, but it may also indicate other chargeable identities such as a group of users. RADIUS clients (proxy or NAS) outside the home network MUST NOT modify the CUI attribute.
CUI属性用作用户真实身份的别名，表示家庭网络定义和提供的可收费身份，作为用户名（1）的补充或替代信息。通常，CUI表示实际用户的身份，但也可能表示其他收费身份，如一组用户。家庭网络外部的RADIUS客户端（代理或NAS）不得修改CUI属性。
The RADIUS server (a RADIUS proxy, home RADIUS server) may include the CUI attribute in the Access-Accept packet destined to a roaming partner. The CUI support by RADIUS infrastructure is driven by the business requirements between roaming entities. Therefore, a RADIUS server supporting this specification may choose not to send the CUI in response to an Access-Request packet from a given NAS, even if the NAS has indicated that it supports CUI.
RADIUS服务器（RADIUS代理，家庭RADIUS服务器）可以在目的地为漫游伙伴的访问接受数据包中包括CUI属性。RADIUS基础设施对CUI的支持是由漫游实体之间的业务需求驱动的。因此，支持此规范的RADIUS服务器可以选择不发送CUI，以响应来自给定NAS的访问请求数据包，即使NAS已指示其支持CUI。
If an Access-Accept packet without the CUI attribute was received by a RADIUS client that requested the CUI attribute, then the Access-Accept packet MAY be treated as an Access-Reject.
如果请求CUI属性的RADIUS客户端接收到不带CUI属性的访问接受数据包，则该访问接受数据包可被视为访问拒绝。
If the CUI was included in an Access-Accept packet, RADIUS clients supporting the CUI attribute MUST ensure that the CUI attribute appears in the RADIUS Accounting-Request (Start, Interim, and Stop). This requirement applies regardless of whether the RADIUS client requested the CUI attribute.
如果CUI包含在访问接受数据包中，则支持CUI属性的RADIUS客户端必须确保CUI属性出现在RADIUS记帐请求中（开始、中间和停止）。无论RADIUS客户端是否请求CUI属性，此要求都适用。
RFC 2865 includes the following statements about behaviors of RADIUS client and server with respect to unsupported attributes:
RFC 2865包括以下关于RADIUS客户端和服务器在不支持的属性方面的行为的声明：
- "A RADIUS client MAY ignore Attributes with an unknown Type." - "A RADIUS server MAY ignore Attributes with an unknown Type."
- “RADIUS客户端可以忽略未知类型的属性。”-“RADIUS服务器可以忽略未知类型的属性。”
Therefore, RADIUS clients or servers that do not support the CUI may ignore the attribute.
因此，不支持CUI的RADIUS客户端或服务器可能会忽略该属性。
A RADIUS client requesting the CUI attribute in an Access-Accept packet MUST include within the Access-Request packet a CUI attribute. For the initial authentication, the CUI attribute will include a single NUL character (referred to as a nul CUI). And, during
在访问接受数据包中请求CUI属性的RADIUS客户端必须在访问请求数据包中包含CUI属性。对于初始身份验证，CUI属性将包含单个NUL字符（称为NUL CUI）。而且在
re-authentication, the CUI attribute will include a previously received CUI value (referred to as a non-nul CUI value) in the Access-Accept.
重新身份验证时，CUI属性将在Access Accept中包含以前收到的CUI值（称为非nul CUI值）。
Upon receiving a non-nul CUI value in an Access-Request, the home RADIUS server MAY verify that the value of CUI matches the CUI from the previous Access-Accept. If the verification fails, then the RADIUS server SHOULD respond with an Access-Reject message.
在访问请求中接收到非nul CUI值后，主RADIUS服务器可验证CUI值是否与先前访问接受中的CUI匹配。如果验证失败，RADIUS服务器应以访问拒绝消息响应。
If a home RADIUS server that supports the CUI attribute receives an Access-Request packet containing a CUI (set to nul or otherwise), it MUST include the CUI attribute in the Access-Accept packet. Otherwise, if the Access-Request packet does not contain a CUI, the home RADIUS server SHOULD NOT include the CUI attribute in the Access-Accept packet. The Access-Request may be sent either in the initial authentication or during re-authentication.
如果支持CUI属性的主RADIUS服务器接收到包含CUI的访问请求数据包（设置为nul或其他），则必须在访问接受数据包中包含CUI属性。否则，如果访问请求数据包不包含CUI，则主RADIUS服务器不应在访问接受数据包中包含CUI属性。可以在初始认证中或在重新认证期间发送访问请求。
A NAS that requested the CUI during re-authentication by including the CUI in the Access-Request will receive the CUI in the Access-Accept. The NAS MUST include the value of that CUI in all Accounting Messages.
在重新身份验证期间通过将CUI包括在访问请求中请求CUI的NAS将在访问接受中接收CUI。NAS必须在所有记帐消息中包含该CUI的值。
A summary of the RADIUS CUI attribute is given below.
下面给出了半径CUI属性的摘要。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 89 for Chargeable-User-Identity.
类型：89用于收费用户标识。
Length: >= 3
Length: >= 3
String:
字符串：
The string identifies the CUI of the end-user. This string value is a reference to a particular user. The format and content of the string value are determined by the Home RADIUS server. The binding lifetime of the reference to the user is determined based on business agreements. For example, the lifetime can be set to one billing period. RADIUS entities other than the Home RADIUS server MUST treat the CUI content as an opaque token, and SHOULD NOT perform operations on its content other than a binary equality comparison test, between two instances of CUI. In cases where the
该字符串标识最终用户的CUI。此字符串值是对特定用户的引用。字符串值的格式和内容由主RADIUS服务器确定。对用户的引用的绑定生存期是根据业务协议确定的。例如，可以将生存期设置为一个计费周期。主RADIUS服务器以外的RADIUS实体必须将CUI内容视为不透明标记，并且不应在两个CUI实例之间对其内容执行二进制相等性比较测试以外的操作。如果
attribute is used to indicate the NAS support for the CUI, the string value contains a nul character.
属性用于指示NAS对CUI的支持，字符串值包含nul字符。
The following table provides a guide to which attribute(s) may be found in which kinds of packets, and in what quantity.
下表提供了在哪些类型的数据包中可以找到哪些属性以及数量的指南。
Request Accept Reject Challenge Accounting # Attribute Request 0-1 0-1 0 0 0-1 89 Chargeable-User-Identity
请求接受拒绝质询记帐#属性请求0-10-1 0-1 89计费用户标识
Note: If the Access-Accept packet contains CUI, then the NAS MUST include the CUI in Accounting Requests (Start, Interim, and Stop) packets.
注意：如果Access Accept数据包包含CUI，则NAS必须在记帐请求（启动、临时和停止）数据包中包含CUI。
Diameter needs to define an identical attribute with the same Type value. The CUI should be available as part of the NASREQ application [RFC4005].
直径需要定义具有相同类型值的相同属性。CUI应作为NASREQ应用程序[RFC4005]的一部分提供。
This document uses the RADIUS [RFC2865] namespace; see http://www.iana.org/assignments/radius-types. The IANA has assigned a new RADIUS attribute number for the CUI attribute.
本文档使用RADIUS[RFC2865]名称空间；看见http://www.iana.org/assignments/radius-types. IANA已为CUI属性指定了新的半径属性编号。
CUI 89
崔89
It is strongly recommended that the CUI format used is such that the real user identity is not revealed. Furthermore, where a reference is used to a real user identity, it is recommended that the binding lifetime of that reference to the real user be kept as short as possible.
强烈建议使用的CUI格式不显示真实用户身份。此外，如果引用用于真实用户标识，则建议该引用对真实用户的绑定生存期尽可能短。
The RADIUS entities (RADIUS proxies and clients) outside the home network MUST NOT modify the CUI or insert a CUI in an Access-Accept. However, there is no way to detect or prevent this.
家庭网络外部的RADIUS实体（RADIUS代理和客户端）不得修改CUI或在Access Accept中插入CUI。但是，没有办法检测或防止这种情况。
Attempting theft of service, a man-in-the-middle may try to insert, modify, or remove the CUI in the Access-Accept packets and Accounting packets. However, RADIUS Access-Accept and Accounting packets already provide integrity protection.
试图窃取服务时，中间的人可能会尝试在Access Accept数据包和Accounting数据包中插入、修改或删除CUI。但是，RADIUS访问接受和记帐数据包已经提供了完整性保护。
If the NAS includes CUI in an Access-Request packet, a man-in-the-middle may remove it. This will cause the Access-Accept packet to not include a CUI attribute, which may cause the NAS to reject the session. To prevent such a denial of service (DoS) attack, the NAS SHOULD include a Message-Authenticator(80) attribute within Access-Request packets containing a CUI attribute.
如果NAS在访问请求数据包中包含CUI，则中间的人可以将其删除。这将导致Access Accept数据包不包含CUI属性，这可能会导致NAS拒绝会话。为防止此类拒绝服务（DoS）攻击，NAS应在包含CUI属性的访问请求数据包中包含消息验证器（80）属性。
The authors would like to thank Jari Arkko, Bernard Aboba, David Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith, David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson for their feedback and guidance.
作者要感谢贾里·阿尔科、伯纳德·阿博巴、大卫·纳尔逊、巴尼·沃尔夫、布莱尔·布洛克、萨米·阿拉·卢科、洛萨·雷思、大卫·马里布兰卡、尤金·张、格雷格·韦伯和马克·格雷森的反馈和指导。
[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月。
[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月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005]Calhoun，P.，Zorn，G.，Spence，D.，和D.Mitton，“Diameter网络访问服务器应用”，RFC 4005，2005年8月。
[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月。
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3576]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 35762003年7月。
[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月。
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
Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada
加拿大安大略省渥太华Terry Fox大道303号Avi Lior Bridgewater系统公司K2K 3J1
Phone: +1 613-591-9104
EMail: avi@bridgewatersystems.com
Phone: +1 613-591-9104
EMail: avi@bridgewatersystems.com
Jouni Korhonen Teliasonera Corporation P.O.Box 970 FIN-00051, Sonera Finland
Jouni Korhonen Teliasonera Corporation邮政信箱970 FIN-00051，芬兰索内拉
Phone: +358405344455
EMail: jouni.korhonen@teliasonera.com
Phone: +358405344455
EMail: jouni.korhonen@teliasonera.com
John Loughney Nokia Itamerenkatu 11-13 FIN-00180, Helsinki Finland
John Loughney Nokia Itamerenkatu 11-13 FIN-00180，芬兰赫尔辛基
Phone: +358504836342
EMail: john.loughney@nokia.com
Phone: +358504836342
EMail: john.loughney@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）提供。