Independent Submission G. Zorn
Request for Comments: 6218 Network Zen
Category: Informational T. Zhang
ISSN: 2070-1721 Advista Technologies
J. Walker
Intel Corporation
J. Salowey
Cisco Systems
April 2011
Independent Submission G. Zorn
Request for Comments: 6218 Network Zen
Category: Informational T. Zhang
ISSN: 2070-1721 Advista Technologies
J. Walker
Intel Corporation
J. Salowey
Cisco Systems
April 2011
Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material
Cisco供应商特定的RADIUS属性，用于交付键控材料
Abstract
摘要
This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors.
本文档定义了一组特定于供应商的RADIUS属性，旨在允许加密密钥材料的安全传输和任何RADIUS消息的强身份验证。这些属性已从Cisco供应商特定空间分配，并由多个供应商实施。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6218.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6218.
IESG Note
IESG注释
The IESG has concluded that this work is related to IETF work done in the RADEXT WG, but this relationship does not prevent publishing. The IESG recommends that the RADEXT WG proceed with the work for an interoperable modern key wrap solution using attributes from the standard space as part of its charter.
IESG得出结论，该工作与RADEXT工作组中完成的IETF工作有关，但这种关系并不妨碍发布。IESG建议RADEXT WG在其章程中使用标准空间中的属性，继续开发可互操作的现代密钥封装解决方案。
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Attributes ......................................................3
3.1. Keying-Material ............................................4
3.2. MAC-Randomizer .............................................9
3.3. Message-Authentication-Code ...............................11
4. Security Considerations ........................................16
5. Contributors ...................................................16
6. Acknowledgements ...............................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Attributes ......................................................3
3.1. Keying-Material ............................................4
3.2. MAC-Randomizer .............................................9
3.3. Message-Authentication-Code ...............................11
4. Security Considerations ........................................16
5. Contributors ...................................................16
6. Acknowledgements ...............................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
This document defines a set of vendor-specific RADIUS Attributes, allocated from the Cisco vendor space, that can be used to securely transfer cryptographic keying material using standard techniques with well-understood security properties. In addition, the Message-Authentication-Code Attribute may be used to provide strong authentication for any RADIUS message, including those used for accounting and dynamic authorization.
本文档定义了一组特定于供应商的RADIUS属性，这些属性是从Cisco供应商空间分配的，可用于使用具有众所周知的安全属性的标准技术安全地传输加密密钥材料。此外，消息身份验证代码属性可用于为任何RADIUS消息提供强身份验证，包括用于记帐和动态授权的消息。
These attributes were designed to provide stronger protection and more flexibility than the currently defined Vendor-Specific MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes in [RFC2548] and the Message-Authenticator Attribute in [RFC3579].
这些属性旨在提供比[RFC2548]中当前定义的特定于供应商的MS MPPE发送密钥和MS MPPE Recv密钥属性以及[RFC3579]中的消息验证器属性更强的保护和更大的灵活性。
Many remote access deployments (for example, deployments utilizing wireless LAN technology) require the secure transmission of cryptographic keying material from a RADIUS [RFC2865] server to a network access point. This material is usually produced as a by-product of an Extensible Authentication Protocol (EAP) [RFC3748] authentication and returned in the Access-Accept message following a
许多远程访问部署（例如，利用无线LAN技术的部署）需要将加密密钥材料从RADIUS[RFC2865]服务器安全传输到网络访问点。此材料通常作为可扩展身份验证协议（EAP）[RFC3748]身份验证的副产品生成，并在访问接受消息中返回
successful authentication process. The keying material is of a form that may be used in virtually any cryptographic algorithm after appropriate processing. These attributes may also be used in other cases where an Authentication, Authorization, and Accounting (AAA) server needs to deliver keying material to a network access point.
成功的身份验证过程。密钥材料的形式可以在经过适当处理后在几乎任何加密算法中使用。这些属性也可用于身份验证、授权和计费（AAA）服务器需要向网络接入点发送密钥材料的其他情况。
Discussion of this document may be directed to the authors.
本文件的讨论可直接向作者进行。
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 subsections describe sub-attributes that are transmitted in RADIUS Attributes of type Vendor-Specific [RFC2865]. The Vendor ID field of the Vendor-Specific Attribute(s) MUST be set to decimal 9 (Cisco). The general format of the attributes is:
以下小节描述了在供应商特定[RFC2865]类型的RADIUS属性中传输的子属性。供应商特定属性的供应商ID字段必须设置为十进制9（Cisco）。属性的一般格式为：
0 1 2 3
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 (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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 (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
26 for Vendor-Specific
26针对特定供应商
Length
长
Length of entire attribute including type and length fields
整个属性的长度，包括类型和长度字段
Vendor ID
供应商ID
4 octets encoding the Cisco Vendor ID of 9
4个八位字节，编码Cisco供应商ID 9
Sub-type
子类型
Attribute sub-type of 1
属性子类型1
Sub-length
子长度
Length of the sub-attribute including the sub-type and sub-length fields
子属性的长度，包括子类型和子长度字段
Value
价值
Value of the sub-attribute
子属性的值
This specification concerns the following sub-attributes:
本规范涉及以下子属性：
o Keying-Material
o 键控材料
o MAC-Randomizer
o MAC随机化器
o Message-Authentication-Code
o 消息身份验证码
Description
描述
This Attribute MAY be used to transfer cryptographic keying material from a RADIUS server to a client.
此属性可用于将加密密钥材料从RADIUS服务器传输到客户端。
It MAY be sent in request messages (e.g., Access-Request, etc.), as well; if the Keying-Material (KM) Attribute is present in a request, it SHOULD be taken as a hint by the server that the client prefers this method of key delivery over others. The server is not obligated to honor the hint, however. When the Keying-Material Attribute is included in a request message, the KM ID, key-encrypting-key (KEK) ID, Lifetime, Initialization Vector (IV), and Key Material Data fields MAY be omitted.
它也可以在请求消息（例如，访问请求等）中发送；如果请求中存在密钥材料（KM）属性，则服务器应将其视为提示，表明客户端更喜欢这种密钥传递方法而不是其他方法。但是，服务器没有义务遵守提示。当密钥材料属性包括在请求消息中时，可以省略KM ID、密钥加密密钥（KEK）ID、生存期、初始化向量（IV）和密钥材料数据字段。
In environments where the Keying-Material Attribute is known to be supported or in cases where the client wants to avoid roll-back attacks, the client MAY be configured to require the use of the Keying-Material Attribute. If the client requires the use of the Keying-Material Attribute for keying material delivery and it is not present in the Access-Accept or Access-Challenge message, the client MAY ignore the message in question and end the user session.
在已知支持键控材质属性的环境中，或者在客户端希望避免回滚攻击的情况下，可以将客户端配置为要求使用键控材质属性。如果客户机需要使用Keying Material属性进行Keying Material delivery，但该属性不在Access Accept或Access Challenge消息中，则客户机可能会忽略相关消息并结束用户会话。
Any packet that contains a Keying-Material Attribute MUST also include the Message-Authentication-Code Attribute.
包含键控材质属性的任何数据包也必须包含消息身份验证代码属性。
Any packet that contains an instance of the Keying-Material Attribute MUST NOT contain an instance of any other attribute (e.g., MS-CHAP-MPPE-Keys [RFC2548], Tunnel-Password [RFC2868], etc.) encapsulating identical keying material.
包含密钥材料属性实例的任何数据包不得包含封装相同密钥材料的任何其他属性（例如MS CHAP MPPE密钥[RFC2548]、隧道密码[RFC2868]等）的实例。
The Keying-Material Attribute MUST NOT be used to transfer long-lived keys (i.e., passwords) between RADIUS servers and clients.
密钥材质属性不得用于在RADIUS服务器和客户端之间传输长寿命密钥（即密码）。
A summary of the Keying-Material Attribute format is shown below. The fields are transmitted from left to right.
关键帧材质属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
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 (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:app-key=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) | Enc Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEK ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KM ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IV (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keying Material Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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 (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:app-key=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) | Enc Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEK ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KM ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IV (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keying Material Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
26 for Vendor-Specific
26针对特定供应商
Length
长
Length of entire attribute including type and length fields
整个属性的长度，包括类型和长度字段
Vendor ID
供应商ID
4 octets encoding the Cisco Vendor ID of 9
4个八位字节，编码Cisco供应商ID 9
Sub-type
子类型
Attribute sub-type of 1
属性子类型1
Sub-length
子长度
Length of the sub-attribute including the sub-type and sub-length fields
子属性的长度，包括子类型和子长度字段
String-ID
字符串ID
The ASCII characters "radius:app-key=" without quotes or null termination
ASCII字符“radius:app key=”不带引号或空终止符
Enc Type
Enc型
The Enc Type field indicates the method used to encrypt the contents of the Data field. This document defines only one value (decimal) for this field:
Enc类型字段表示用于加密数据字段内容的方法。本文档仅为该字段定义一个值（十进制）：
0 AES Key Wrap with 128-bit KEK [RFC3394]
0带128位KEK的AES密钥换行[RFC3394]
Implementations MUST support Enc Type 0 (AES Key Wrap with 128-bit KEK).
实现必须支持Enc类型0（带128位KEK的AES密钥包装）。
Implementation Note
实施说明
A shared secret is used as the key-encrypting-key (KEK) for the AES key wrap algorithm. Implementations SHOULD provide a means to provision a key (cryptographically separate from the normal RADIUS shared secret) to be used exclusively as a KEK.
共享密钥用作AES密钥包裹算法的密钥加密密钥（KEK）。实现应该提供一种方法来提供一个密钥（以加密方式与普通的RADIUS共享密钥分离），该密钥专门用作KEK。
App ID
应用程序ID
The App ID field is 4 octets in length and identifies the type of application for which the key material is to be used. This allows for multiple keys for different purposes to be present in the same message. This document defines two values for the App ID:
应用程序ID字段的长度为4个八位字节，用于标识要使用关键材料的应用程序类型。这允许在同一消息中出现多个用于不同目的的键。本文档为应用程序ID定义了两个值：
0 Reserved
0保留
1 EAP MSK
1 EAP MSK
KEK ID
桶ID
The KEK ID field is 16 octets in length. The combination of the KEK ID and the client and server IP addresses together uniquely identify a key shared between the RADIUS client and server. As a result, the KEK ID need not be globally unique. The KEK ID MUST refer to an encryption key of a type and length appropriate for use with the algorithm specified by the Enc Type field (see above). This key is used to protect the contents of the Data field (below). The KEK ID is a constant that is configured through an out-of-band mechanism. The same value is configured on both the RADIUS client and server. If no KEK ID is configured, then the field is set to 0. If only a single KEK is configured for use between a given RADIUS client and server, then 0 can be used as the default value.
KEK ID字段的长度为16个八位字节。KEK ID与客户端和服务器IP地址的组合共同唯一地标识RADIUS客户端和服务器之间共享的密钥。因此，KEK ID不需要全局唯一。KEK ID必须引用一个加密密钥，该密钥的类型和长度适合与Enc type字段指定的算法一起使用（见上文）。此键用于保护数据字段（以下）的内容。KEK ID是通过带外机制配置的常量。RADIUS客户端和服务器上都配置了相同的值。如果未配置KEK ID，则该字段设置为0。如果在给定的RADIUS客户端和服务器之间只配置了一个KEK，则可以使用0作为默认值。
KM ID
公里ID
The KM ID field is 16 octets in length and contains an identifier for the contents of the Data field. The KM ID MAY be used by communicating parties to identify the material being transmitted. The combination of App ID and KM ID MUST uniquely identify the keying material between the parties utilizing it. The KM ID is assumed to be known to the parties that derived the keying material. If the KM ID is not used, it is set to 0. The KM ID for the EAP Master Session Key (MSK) application is set to 0. Another application that uses the KM ID field can be defined in the future.
KM ID字段长度为16个八位字节，包含数据字段内容的标识符。通信方可使用KM ID来识别传输的材料。App ID和KM ID的组合必须唯一标识使用密钥的各方之间的密钥材料。假定导出键控材料的各方已知KM ID。如果未使用KM ID，则将其设置为0。EAP主会话密钥（MSK）应用程序的KM ID设置为0。将来可以定义另一个使用KM ID字段的应用程序。
Lifetime
一生
The Lifetime field is an integer [RFC2865] representing the period of time (in seconds) for which the keying material is valid.
寿命字段是一个整数[RFC2865]，表示键控材质有效的时间段（以秒为单位）。
Note: Applications using this value SHOULD consider the beginning of the lifetime to be the point in time when the keying material is first used.
注意：使用此值的应用程序应该考虑使用寿命的起始点是使用密钥材料时的时间点。
IV
四,
The length of the IV field depends upon the value of the Enc Type field, but is fixed for any given value thereof. When the value of the Enc Type field is 0 (decimal), the IV field MUST be 8 octets in length (as illustrated above), and the value of the IV field MUST be as specified in [RFC3394]. If the IV for Enc Type 0 does not match [RFC3394], then the receiver MUST NOT use the key material from this attribute.
IV字段的长度取决于Enc类型字段的值，但对于其任何给定值都是固定的。当Enc类型字段的值为0（十进制）时，IV字段的长度必须为8个八位字节（如上所示），并且IV字段的值必须符合[RFC3394]中的规定。如果Enc类型0的IV与[RFC3394]不匹配，则接收器不得使用此属性中的关键材料。
Keying Material Data
键入材料数据
The Keying Material Data field is of variable length and contains the actual encrypted keying material.
密钥材料数据字段长度可变，包含实际加密的密钥材料。
Description
描述
The MAC-Randomizer Attribute MUST be present in any message that includes an instance of the Message-Authentication-Code Attribute. The Random field MUST contain a 32-octet random number that SHOULD satisfy the requirements of [RFC4086].
MAC随机化器属性必须出现在包含消息身份验证代码属性实例的任何消息中。随机场必须包含32个八位随机数，该随机数应满足[RFC4086]的要求。
Implementation Note
实施说明
The Random field MUST be filled in before the Message Authentication Code (MAC) is computed. The MAC-Randomizer Attribute SHOULD be placed at the beginning of the RADIUS message if possible.
在计算消息身份验证码（MAC）之前，必须填写随机场。如果可能，MAC随机化器属性应放在RADIUS消息的开头。
A summary of the MAC-Randomizer Attribute format is shown below. The fields are transmitted from left to right.
MAC随机化器属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
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 (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:random-nonce=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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 (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:random-nonce=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
26 for Vendor-Specific
26针对特定供应商
Length
长
Length of entire attribute including type and length fields
整个属性的长度，包括类型和长度字段
Vendor ID
供应商ID
4 octets encoding the Cisco Vendor ID of 9
4个八位字节，编码Cisco供应商ID 9
Sub-type
子类型
Attribute sub-type of 1
属性子类型1
Sub-length
子长度
Length of the sub-attribute including the sub-type and sub-length fields
子属性的长度，包括子类型和子长度字段
String-ID
字符串ID
The ASCII characters "radius:random-nonce=" without quotes or null termination
ASCII字符“radius:random nonce=”不带引号或空终止符
Random
随机的
This field MUST contain a 32 octet random number that SHOULD satisfy the requirements of [RFC4086].
该字段必须包含32个八位随机数，该随机数应满足[RFC4086]的要求。
Description
描述
This Attribute MAY be used to "sign" messages to prevent spoofing. If it is present in a request, the receiver should take this as a hint that the sender prefers the use of this Attribute for message authentication; the receiver is not obligated to do so, however.
此属性可用于对消息进行“签名”以防止欺骗。如果该属性存在于请求中，则接收方应将其视为发送方倾向于使用该属性进行消息身份验证的提示；然而，接收方没有义务这样做。
The Message-Authentication-Code Attribute MUST be included in any message that contains a Keying-Material Attribute.
任何包含键控材质属性的消息中都必须包含消息身份验证代码属性。
If both the Message-Authentication-Code and Message-Authenticator Attributes are to be included in a message (e.g., for backward compatibility in a network containing both old and new clients), the value of the Message-Authentication-Code Attribute MUST be computed first.
如果消息中同时包含消息认证码和消息认证器属性（例如，为了在包含新旧客户端的网络中向后兼容），则必须首先计算消息认证码属性的值。
If any message is received containing an instance of the Message-Authentication-Code Attribute, the receiver MUST calculate the correct value of the Message-Authentication-Code and silently discard the packet if the computed value does not match the value received.
如果接收到包含消息身份验证码属性实例的任何消息，则接收方必须计算消息身份验证码的正确值，并在计算值与接收到的值不匹配的情况下自动丢弃数据包。
If a received message contains an instance of the MAC-Randomizer Attribute (Section 3.2), the received MAC-Randomizer Attribute SHOULD be included in the computation of the Message-Authentication-Code Attribute sent in the response, as described below.
如果接收到的消息包含MAC随机化器属性的实例（第3.2节），则接收到的MAC随机化器属性应包括在响应中发送的消息认证码属性的计算中，如下所述。
A summary of the Message-Authentication-Code Attribute format is shown below. The fields are transmitted from left to right.
消息身份验证代码属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
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 (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:message-authenticator-code=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) | MAC Type | MAC Key ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd) | MAC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (cont'd) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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 (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:message-authenticator-code=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) | MAC Type | MAC Key ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd) | MAC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (cont'd) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
26 for Vendor-Specific
26针对特定供应商
Length
长
Length of entire attribute including type and length fields
整个属性的长度，包括类型和长度字段
Vendor ID
供应商ID
4 octets encoding the Cisco Vendor ID of 9
4个八位字节，编码Cisco供应商ID 9
Sub-type
子类型
Attribute sub-type of 1
属性子类型1
Sub-length
子长度
Length of the sub-attribute including the sub-type and sub-length fields
子属性的长度，包括子类型和子长度字段
String-ID
字符串ID
The ASCII characters "radius:message-authenticator-code=" without quotes or null termination
ASCII字符“radius:message authenticator code=”不带引号或空终止符
MAC Type
MAC类型
The MAC Type field specifies the algorithm used to create the value in the MAC field. This document defines six values for the MAC Type field:
MAC类型字段指定用于在MAC字段中创建值的算法。本文档为MAC类型字段定义了六个值：
0 HMAC-SHA-1 [FIPS] [RFC2104]
0 HMAC-SHA-1[FIPS][RFC2104]
1 HMAC-SHA-256 [FIPS] [RFC4231]
1 HMAC-SHA-256[FIPS][RFC4231]
2 HMAC-SHA-512 [FIPS] [RFC4231]
2 HMAC-SHA-512[FIPS][RFC4231]
3 CMAC-AES-128 [NIST]
3 CMAC-AES-128[NIST]
4 CMAC-AES-192 [NIST]
4 CMAC-AES-192[NIST]
5 CMAC-AES-256 [NIST]
5 CMAC-AES-256[NIST]
Implementations MUST support MAC Type 0 (HMAC-SHA-1).
实现必须支持MAC类型0（HMAC-SHA-1）。
MAC Key ID
MAC密钥ID
The MAC Key ID field is 16 octets in length and contains an identifier for the key. The combination of the MAC Key ID and the client and server IP addresses together uniquely identify a key shared between the RADIUS client and server. As a result, the MAC Key ID need not be globally unique. The MAC Key ID MUST refer to a key of a type and length appropriate for use with the algorithm specified by the MAC Type field (see above).
MAC密钥ID字段的长度为16个八位字节，包含密钥的标识符。MAC密钥ID与客户端和服务器IP地址的组合共同唯一地标识RADIUS客户端和服务器之间共享的密钥。因此，MAC密钥ID不需要全局唯一。MAC密钥ID必须是一个类型和长度适合与MAC类型字段指定的算法一起使用的密钥（见上文）。
The MAC Key ID is a constant that is configured through an out-of-band mechanism. The same value is configured on both the RADIUS client and server. If no MAC Key ID is configured, then the field is set to 0. If only a single MAC Key ID is configured for use between a given RADIUS client and server, then 0 can be used as the default value.
MAC密钥ID是通过带外机制配置的常量。RADIUS客户端和服务器上都配置了相同的值。如果未配置MAC密钥ID，则该字段设置为0。如果在给定RADIUS客户端和服务器之间只配置了一个MAC密钥ID，则可以使用0作为默认值。
MAC
雨衣
Both the length and value of the MAC field depend upon the algorithm specified by the value of the MAC Type field. If the algorithm specified is HMAC-SHA-1, HMAC-SHA-256, or HMAC-SHA-512, the MAC field MUST be 20, 32, or 64 octets in length, respectively. If the algorithm specified is CMAC-AES-128, CMAC-AES-192, or CMAC-AES-256, the MAC field SHOULD be 64 octets in length. The derivation of the MAC field value for all the algorithms specified in this document is identical, except for the algorithm used. There are differences, however, depending upon whether the MAC is being computed for a request message or a response. These differences are detailed below, with the free variable HASH-ALG representing the actual algorithm used.
MAC字段的长度和值取决于MAC类型字段值指定的算法。如果指定的算法为HMAC-SHA-1、HMAC-SHA-256或HMAC-SHA-512，则MAC字段的长度必须分别为20、32或64个八位字节。如果指定的算法为CMAC-AES-128、CMAC-AES-192或CMAC-AES-256，则MAC字段的长度应为64个八位字节。除所使用的算法外，本文件中规定的所有算法的MAC字段值的推导是相同的。然而，根据是针对请求消息还是响应计算MAC，存在差异。下面将详细介绍这些差异，自由变量HASH-ALG表示实际使用的算法。
Request Messages
请求消息
For requests (e.g., CoA-Request [RFC5176], Accounting-Request [RFC2866], etc.), the value of the MAC field is a hash of the entire packet except the Request Authenticator in the header of the RADIUS packet, using a shared secret as the key, as follows.
对于请求（例如，CoA请求[RFC5176]、记帐请求[RFC2866]等），MAC字段的值是整个分组的散列，除了RADIUS分组报头中的请求验证器之外，使用共享密钥作为密钥，如下所示。
MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes)
where '+' represents concatenation
MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes)
where '+' represents concatenation
The MAC-Randomizer Attribute (Section 3.2) MUST be included in any request in which the Message-Authentication-Code Attribute is used. The Random field of the MAC-Randomizer Attribute MUST be filled in before the value of the MAC field is computed.
MAC随机化器属性（第3.2节）必须包含在使用消息验证码属性的任何请求中。在计算MAC字段的值之前，必须填写MAC随机化器属性的随机场。
If the Message-Authenticator-Code Attribute is included in a client request, the server SHOULD ignore the contents of the Request Authenticator.
如果客户端请求中包含消息验证器代码属性，则服务器应忽略请求验证器的内容。
Implementation Notes
实施说明
When the hash is calculated, both the MAC field of the Message-Authenticator-Code Attribute and the String field of the Message-Authenticator Attribute (if any) MUST be considered to be zero-filled.
计算哈希时，必须将消息验证器代码属性的MAC字段和消息验证器属性的字符串字段（如果有）都视为零填充。
Implementations SHOULD provide a means to provision a key (cryptographically separate from the normal RADIUS shared secret) to be used exclusively in the generation of the Message-Authentication-Code.
实现应该提供一种方法来提供一个密钥（以加密方式与普通RADIUS共享密钥分离），该密钥专门用于生成消息身份验证码。
Response Messages
响应消息
For responses (e.g., CoA-ACK [RFC5176], Accounting-Response [RFC2866], etc.), the value of the MAC field is a hash of the entire packet except the Response Authenticator in the header of the RADIUS packet using a shared secret as the key, as follows.
对于响应（例如，CoA ACK[RFC5176]、记帐响应[RFC2866]等），MAC字段的值是整个分组的散列，除了使用共享密钥作为密钥的RADIUS分组的报头中的响应验证器之外，如下所示。
MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes)
where '+' represents concatenation
MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes)
where '+' represents concatenation
If the request contained an instance of the MAC-Randomizer Attribute and the responder wishes to include an instance of the Message-Authentication-Code Attribute in the corresponding response, then the MAC-Randomizer Attribute from the request MUST be included in the response.
如果请求包含MAC随机化器属性的实例，并且响应者希望在相应的响应中包含消息认证码属性的实例，则来自请求的MAC随机化器属性必须包含在响应中。
If the Message-Authenticator-Code Attribute is included in a server response, the client SHOULD ignore the contents of the Response Authenticator.
如果服务器响应中包含消息验证器代码属性，则客户端应忽略响应验证器的内容。
Implementation Notes
实施说明
When the hash is calculated, both the MAC field of the Message-Authenticator-Code Attribute and the String field of the Message-Authenticator Attribute (if any) MUST be considered to be zero-filled.
计算哈希时，必须将消息验证器代码属性的MAC字段和消息验证器属性的字符串字段（如果有）都视为零填充。
The Message-Authentication-Code Attribute MUST be created and inserted in the packet before the Response Authenticator is calculated.
在计算响应验证器之前，必须创建消息身份验证代码属性并将其插入数据包中。
Implementations SHOULD provide a means to provision a key (cryptographically separate from the normal RADIUS shared secret) to be used exclusively in the generation of the Message-Authentication-Code.
实现应该提供一种方法来提供一个密钥（以加密方式与普通RADIUS共享密钥分离），该密钥专门用于生成消息身份验证码。
It is RECOMMENDED in this memo that two new keys, a key encrypting key and a message authentication key, be shared by the RADIUS client and server. If implemented, these two keys MUST be different from each other and SHOULD NOT be based on a password. These two keys MUST be cryptographically independent of the RADIUS shared secret used in calculating the Response Authenticator [RFC2865], Request Authenticator [RFC2866] [RFC5176], and Message-Authenticator Attribute [RFC3579]; otherwise, if the shared secret is broken, all is lost.
在此备忘录中，建议RADIUS客户端和服务器共享两个新密钥，一个密钥加密密钥和一个消息身份验证密钥。如果实现，这两个密钥必须彼此不同，并且不应基于密码。这两个密钥必须以加密方式独立于计算响应验证器[RFC2865]、请求验证器[RFC2866][RFC5176]和消息验证器属性[RFC3579]时使用的RADIUS共享密钥；否则，如果共享的秘密被打破，所有的都将丢失。
To avoid the possibility of collisions, the same MAC key SHOULD NOT be used with more than 2^(n/2) messages, where 'n' is the length of the MAC value in octets.
为避免冲突的可能性，同一MAC密钥不应用于超过2^（n/2）条消息，其中“n”是MAC值的长度（以八位字节为单位）。
If a packet that contains an instance of the Keying-Material Attribute also contains an instance of another, weaker key transport attribute (e.g., MS-MPPE-Recv-Key [RFC2548]) encapsulating identical keying material, then breaking the weaker attribute might facilitate a known-plaintext attack against the KEK.
如果包含键控材料属性实例的数据包还包含封装相同键控材料的另一较弱密钥传输属性（例如，MS MPPE Recv key[RFC2548]）的实例，则破坏较弱属性可能会促进针对KEK的已知明文攻击。
Hao Zhou, Nancy Cam-Winget, Alex Lam, Paul Funk, and John Fossaceca all contributed to this document.
周昊、南希·金文杰、亚历克斯·林、保罗·芬克和约翰·福萨塞卡都对本文件做出了贡献。
Thanks (in no particular order) to Keith McCloghrie, Kaushik Narayan, Murtaza Chiba, Bill Burr, Russ Housley, David McGrew, Pat Calhoun, Joel Halpern, Jim Schaad, Greg Weber, and Bernard Aboba for useful feedback.
感谢基思·麦克洛赫里、考希克·纳拉扬、木尔塔扎·千叶、比尔·伯尔、罗斯·霍斯利、大卫·麦克格鲁、帕特·卡尔霍恩、乔尔·哈尔佩恩、吉姆·沙阿德、格雷格·韦伯和伯纳德·阿博巴（无特殊顺序）提供有用的反馈。
[FIPS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[FIPS]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-3，2008年10月。
[NIST] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", NIST SP800- 38B, May 2005.
[NIST]Dworkin，M.“分组密码操作模式的建议：认证的CMAC模式”，NIST SP800-38B，2005年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.，和I.Goyret，“隧道协议支持的半径属性”，RFC 28682000年6月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，2002年9月。
[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月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005.
[RFC4231]Nystrom，M.“HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512的标识符和测试向量”，RFC 42312005年12月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 51762008年1月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]Zorn，G.，“微软特定于供应商的半径属性”，RFC 2548，1999年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
Authors' Addresses
作者地址
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
格伦佐恩网络禅宗227/358泰国曼谷Thanon Sanphawut Bang Na 10260
Phone: +66 (0) 87 040 4617
EMail: gwz@net-zen.net
Phone: +66 (0) 87 040 4617
EMail: gwz@net-zen.net
Tiebing Zhang Advista Technologies 5252 Orange Ave., Suite 106 Cypress, CA 90630 US
美国加利福尼亚州赛普拉斯橘子大道5252号106室张铁冰科技有限公司，邮编90630
Phone: +1 (949) 242 0391
EMail: tzhang@advistatech.com
Phone: +1 (949) 242 0391
EMail: tzhang@advistatech.com
Jesse Walker Intel Corporation JF2-55 2111 N.E. 25th Ave. Hillsboro, OR 97214-5961 US
杰西·沃克英特尔公司JF2-55 2111美国希尔斯博罗东北25大道，邮编97214-5961
Phone: +1 (503) 712-1849
EMail: jesse.walker@intel.com
Phone: +1 (503) 712-1849
EMail: jesse.walker@intel.com
Joseph Salowey Cisco Systems 2901 Third Avenue SEA1/6/ Seattle, WA 98121 US
Joseph Salowey Cisco Systems美国华盛顿州西雅图第三大道2901号SEA1/6/98121
Phone: +1 (206) 256-3380
EMail: jsalowey@cisco.com
Phone: +1 (206) 256-3380
EMail: jsalowey@cisco.com