Internet Engineering Task Force (IETF) A. Yegin
Request for Comments: 6786 Samsung
Category: Standards Track R. Cragie
ISSN: 2070-1721 Gridmerge Ltd.
November 2012
Internet Engineering Task Force (IETF) A. Yegin
Request for Comments: 6786 Samsung
Category: Standards Track R. Cragie
ISSN: 2070-1721 Gridmerge Ltd.
November 2012
Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs
加密用于承载网络访问身份验证（PANA）属性值对的协议
Abstract
摘要
This document specifies a mechanism for delivering the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs (AVPs) in encrypted form.
本文档指定了一种机制，用于以加密形式提供用于承载网络访问身份验证（PANA）属性值对（AVP）的协议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc6786.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6786.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Details .........................................................3
3. Encryption Keys .................................................3
4. Encryption-Algorithm AVP ........................................4
4.1. AES128_CTR Encryption Algorithm ............................5
5. Encryption-Encap AVP ............................................6
6. Encryption Policy ...............................................6
6.1. Encryption Policy Specification ............................7
7. Security Considerations .........................................8
7.1. AES-CTR Security Considerations ............................9
8. IANA Considerations .............................................9
8.1. PANA AVP Codes .............................................9
8.2. PANA Encryption-Algorithm AVP Values .......................9
8.3. PANA AVP Codes Encryption Policy ..........................10
9. Acknowledgments ................................................10
10. Normative References ..........................................10
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Details .........................................................3
3. Encryption Keys .................................................3
4. Encryption-Algorithm AVP ........................................4
4.1. AES128_CTR Encryption Algorithm ............................5
5. Encryption-Encap AVP ............................................6
6. Encryption Policy ...............................................6
6.1. Encryption Policy Specification ............................7
7. Security Considerations .........................................8
7.1. AES-CTR Security Considerations ............................9
8. IANA Considerations .............................................9
8.1. PANA AVP Codes .............................................9
8.2. PANA Encryption-Algorithm AVP Values .......................9
8.3. PANA AVP Codes Encryption Policy ..........................10
9. Acknowledgments ................................................10
10. Normative References ..........................................10
PANA [RFC5191] is a UDP-based protocol to perform an Extensible Authentication Protocol (EAP) authentication between a PANA Client (PaC) and a PANA Authentication Agent (PAA).
PANA[RFC5191]是一种基于UDP的协议，用于在PANA客户端（PaC）和PANA身份验证代理（PAA）之间执行可扩展身份验证协议（EAP）身份验证。
Various types of payload are exchanged as part of the network access authentication and authorization. These payloads are carried in PANA Attribute-Value Pairs (AVPs). AVPs can be integrity protected using the AUTH AVP when EAP authentication generates cryptographic keying material. AVPs are transmitted in the clear (i.e., not encrypted).
各种类型的有效负载作为网络访问身份验证和授权的一部分进行交换。这些有效载荷以PANA属性值对（AVP）的形式携带。当EAP身份验证生成加密密钥材料时，可以使用AUTH AVP对AVP进行完整性保护。AVP以明文形式传输（即未加密）。
Certain payload types need to be delivered privately (e.g., network keys, private identifiers, etc.). This document defines a mechanism for applying encryption to selected AVPs.
某些有效负载类型需要私下交付（例如，网络密钥、私人标识符等）。本文档定义了将加密应用于选定AVP的机制。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]中所述进行解释。
This document extends the AVP set defined in Section 8 of [RFC5191] by defining two new AVPs: the Encryption-Algorithm AVP (see Section 4) and the Encryption-Encap AVP (see Section 5). Two new encryption keys, PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY, are defined to encrypt AVPs from the PaC to the PAA and AVPs from the PAA to the PaC, respectively (see Section 3).
本文件通过定义两个新的AVP扩展了[RFC5191]第8节中定义的AVP集：加密算法AVP（见第4节）和加密Encap AVP（见第5节）。定义了两个新的加密密钥，PANA_PAC_ENCR_密钥和PANA_PAA_ENCR_密钥，分别对PAC到PAA的AVP和PAA到PAC的AVP进行加密（参见第3节）。
When encryption is needed, the required algorithm is negotiated as follows: the PAA SHALL send the initial PANA-Auth-Request carrying one or more Encryption-Algorithm AVPs supported by it. The PaC SHALL select one of the algorithms from this AVP, and it SHALL respond with the initial PANA-Auth-Answer carrying one Encryption-Algorithm AVP for the selected algorithm. Once PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY have been generated, a PANA message MAY contain an Encryption-Encap AVP.
当需要加密时，所需的算法协商如下：PAA应发送初始PANA Auth请求，其中包含其支持的一个或多个加密算法AVP。PaC应从该AVP中选择一种算法，并用初始PANA Auth应答进行响应，该应答带有一种针对所选算法的加密算法AVP。生成PANA_PAC_ENCR_密钥和PANA_PAA_ENCR_密钥后，PANA消息可能包含加密Encap AVP。
PANA_PAC_ENCR_KEY is used for encrypting the AVP payload of the Encryption-Encap AVP sent in a PANA message from the PaC to the PAA.
PANA_PAC_ENCR_密钥用于加密加密包AVP的AVP有效载荷，该AVP通过PANA消息从PAC发送至PAA。
PANA_PAC_ENCR_KEY SHALL be computed according to the following formula:
PANA_PAC_ENCR_密钥应根据以下公式计算：
PANA_PAC_ENCR_KEY = prf+(MSK, "IETF PANA PaC Encr" | I_PAR | I_PAN | PaC_nonce | PAA_nonce | Key_ID)
PANA|U PAC|U ENCR|U KEY=prf+（MSK，“IETF PANA PAC ENCR”| I|U PAR | I|U PAN | PAC|U nonce | PAA|U nonce | KEY|U ID）
PANA_PAA_ENCR_KEY is used for encrypting the AVP payload of the Encryption-Encap AVP sent in a PANA message from the PAA to the PaC. PANA_PAA_ENCR_KEY SHALL be computed according to the following formula:
PANA_PAA_ENCR_密钥用于加密加密包AVP的AVP有效载荷，该AVP以PANA消息形式从PAA发送至PaC。PANA_PAA_ENCR_键应根据以下公式计算：
PANA_PAA_ENCR_KEY = prf+(MSK, "IETF PANA PAA Encr" | I_PAR | I_PAN | PaC_nonce | PAA_nonce | Key_ID)
PANA|u PAA|u ENCR|u KEY=prf+（MSK，“IETF PANA PAA ENCR”| I|u PAR | I|u PAN | PaC|u nonce | PAA|unce | KEY|u ID）
In both cases:
在这两种情况下：
- The prf+ function is defined in the Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996].
- prf+功能在Internet密钥交换协议版本2（IKEv2）[RFC5996]中定义。
- The pseudo-random function (PRF) to be used for the prf+ function SHALL be negotiated using the PRF-Algorithm AVP in the initial PANA-Auth-Request and PANA-Auth-Answer exchange with the 'S' (Start) bit set as described in Section 4.1 of [RFC5191].
- 用于PRF+功能的伪随机函数（PRF）应在初始PANA认证请求和PANA认证应答交换中使用PRF算法AVP协商，并使用[RFC5191]第4.1节所述的“S”（开始）位集。
- MSK is the master session key (MSK) generated by the EAP method [RFC3748]. PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY MUST be recalculated whenever a new MSK is generated by the EAP method.
- MSK是EAP方法[RFC3748]生成的主会话密钥（MSK）。每当EAP方法生成新MSK时，必须重新计算PANA_PAC_ENCR_密钥和PANA_PAA_ENCR_密钥。
- "IETF PANA PaC Encr" and "IETF PANA PAA Encr" are the ASCII code representations of the respective non-NULL terminated strings (excluding the double quotes around them).
- “IETF PANA PaC Encr”和“IETF PANA PAA Encr”是各自非空终止字符串（不包括其周围的双引号）的ASCII码表示形式。
- I_PAR and I_PAN are the initial PANA-Auth-Request and PANA-Auth-Answer messages (the PANA header and the following PANA AVPs) with the 'S' (Start) bit set, respectively.
- I_PAR和I_PAN分别是设置了“S”（开始）位的初始PANA身份验证请求和PANA身份验证应答消息（PANA头和以下PANA AVP）。
- PaC_nonce and PAA_nonce are values of the Nonce AVP carried in the first non-initial PANA-Auth-Answer and PANA-Auth-Request messages in the authentication and authorization phase or the first PANA-Auth-Answer and PANA-Auth-Request messages in the re-authentication phase, respectively.
- PaC_nonce和PAA_nonce分别是在身份验证和授权阶段的第一个非初始PANA Auth ANCE和PANA Auth Request消息或在重新身份验证阶段的第一个PANA Auth ANCE和PANA Auth Request消息中携带的nonce AVP值。
- Key_ID is the value of the Key-Id AVP.
- Key_ID是Key ID AVP的值。
The length of PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY depends on the encryption algorithm in use.
PANA_PAC_ENCR_密钥和PANA_PAA_ENCR_密钥的长度取决于使用的加密算法。
The Encryption-Algorithm AVP (AVP code 13) is used for conveying the encryption algorithm to be used with the Encryption-Encap AVP. The AVP value data is of type Unsigned32.
加密算法AVP（AVP代码13）用于传送要与加密包AVP一起使用的加密算法。AVP值数据的类型为Unsigned32。
Only one encryption algorithm identifier AES128_CTR (code 1) is identified by this document. Encryption algorithm identifier values other than 1 are reserved for future use. Future specifications are allowed to extend this list.
本文件仅识别一个加密算法标识符AES128_CTR（代码1）。加密算法标识符值（1除外）保留供将来使用。允许将来的规范扩展此列表。
AES128_CTR: 1
AES128_中心：1
In the absence of an application profile specifying otherwise, all implementations SHALL support AES128_CTR.
在没有应用程序配置文件另有规定的情况下，所有实施应支持AES128\u CTR。
The AES128_CTR encryption algorithm uses the AES-CTR (Counter) mode of operation as specified in [NIST_SP800_38A] using the AES-128 block cipher. The formatting function and counter generation function, as specified in Appendix A of [NIST_SP800_38C], are used with the following parameters:
AES128_CTR加密算法使用AES-128分组密码使用[NIST_SP800_38A]中规定的AES-CTR（计数器）操作模式。[NIST_SP800_38C]附录A中规定的格式化功能和计数器生成功能与以下参数一起使用：
n = 12, q = 3
n=12，q=3
The 12-octet nonce consists of a 4-octet Key-Id, a 4-octet Session ID, and a 4-octet Sequence Number in that order where each 4-octet value is encoded in network byte order. The Session ID and Sequence Number values SHALL be the same as those in the PANA message carrying the key Encryption-Encap AVP. The Key-Id value SHALL be the same as the one used for deriving PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY. The output blocks of the encryption processing are encoded as OctetString data in the Value field of a Encryption-Encap AVP.
12个八位字节的nonce由4个八位字节的密钥Id、4个八位字节的会话Id和4个八位字节的序列号组成，其中每个4个八位字节的值按网络字节顺序编码。会话ID和序列号值应与携带密钥加密Encap AVP的PANA消息中的值相同。密钥Id值应与用于导出PANA_PAC_ENCR_密钥和PANA_PAA_ENCR_密钥的值相同。加密处理的输出块在encryption Encap AVP的值字段中编码为八进制字符串数据。
Note that the first counter block used for encryption is Ctr_1, where "_1" denotes "subscript 1" as described in Appendix A.3 of [NIST_SP800_38C]. For example, given the following:
注意，用于加密的第一个计数器块是Ctr_1，其中“_1”表示[NIST_SP800_38C]附录A.3中所述的“下标1”。例如，考虑到以下情况：
Key-Id = 0x55667788, Session ID = 0xaabbccdd, Sequence Number = 0x11223344
密钥Id=0x55667788，会话Id=0xaabbccdd，序列号=0x11223344
The first counter block used for encryption will be:
用于加密的第一个计数器块将是：
0x0255667788aabbccdd11223344000001
0x0255667788aabbccdd11223344000001
where the initial 0x02 represents the Flags field of the counter block.
其中，初始0x02表示计数器块的标志字段。
The nonce meets the requirement of uniqueness-per-key usage provided that the sequence number does not wrap. Therefore, for the purpose of generating new keys:
如果序列号不换行，则nonce满足每个密钥使用的唯一性要求。因此，为了生成新密钥：
- If Encryption-Encap AVPs are being sent from the PaC to the PAA and the sequence number is about to wrap, the PaC SHALL initiate PANA re-authentication as described in Section 4.3 of [RFC5191].
- 如果加密Encap AVP正从PaC发送到PAA，且序列号即将包装，则PaC应按照[RFC5191]第4.3节所述启动PANA重新认证。
- If Encryption-Encap AVPs are being sent from the PAA to the PaC and the sequence number is about to wrap, the PAA SHALL initiate PANA re-authentication as described in Section 4.3 of [RFC5191].
- 如果从PAA向PaC发送加密Encap AVP，且序列号即将换行，则PAA应按照[RFC5191]第4.3节的规定启动PANA重新认证。
Re-authentication ensures the generation of a new MSK [RFC3748] and thus a new PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY.
重新身份验证可确保生成新的MSK[RFC3748]，从而生成新的PANA_PAC_ENCR_密钥和PANA_PAA_ENCR_密钥。
The Encryption-Encap AVP (AVP code 12) is used to encrypt one or more PANA AVPs. The format of the Encryption-Encap AVP depends on the negotiated encryption algorithm.
Encryption Encap AVP（AVP代码12）用于加密一个或多个PANA AVP。Encryption Encap AVP的格式取决于协商的加密算法。
When the negotiated encryption algorithm identifier is AES128_CTR (code 1), AVP data payload is occupied by the encrypted AVPs.
当协商的加密算法标识符为AES128_CTR（代码1）时，AVP数据有效载荷被加密的AVP占用。
There SHALL be only one Encryption-Encap AVP in a PANA message. All AVPs that require encryption SHALL be encapsulated within the Encryption-Encap AVP.
PANA报文中只能有一个Encryption Encap AVP。所有需要加密的AVP应封装在加密包AVP中。
The Encryption-Encap AVP uses either PANA_PAC_ENCR_KEY or PANA_PAA_ENCR_KEY, and the encryption algorithm negotiated by the Encryption-Algorithm AVP. The Encryption-Encap AVP SHALL only be used if the EAP method generates cryptographic keys (specifically, the MSK [RFC3748]).
Encryption Encap AVP使用PANA_PAC_ENCR_密钥或PANA_PAA_ENCR_密钥，以及加密算法AVP协商的加密算法。仅当EAP方法生成加密密钥（特别是MSK[RFC3748]）时，才应使用Encryption Encap AVP。
The Encryption-Encap AVP MAY be used in a PANA message from the PaC to the PAA when the encryption algorithm has been successfully negotiated and once PANA_PAC_ENCR_KEY has been generated.
加密算法协商成功且生成PANA_PaC_ENCR_密钥后，加密Encap AVP可用于从PaC到PAA的PANA消息中。
The Encryption-Encap AVP MAY be used in a PANA message from the PAA to the PaC when the encryption algorithm has been successfully negotiated and once PANA_PAA_ENCR_KEY has been generated.
当加密算法已成功协商并且一旦生成了PANA_PAA_ENCR_密钥，则可在从PAA到PaC的PANA消息中使用加密Encap AVP。
The Encryption-Encap AVP MAY be used in the very first PANA message carrying the Result-Code AVP set to PANA_Success value and any subsequent message within the same PANA session.
加密Encap AVP可用于携带结果代码AVP设置为PANA_Success value的第一条PANA消息以及同一PANA会话内的任何后续消息。
The specification of any AVP SHOULD state that the AVP either shall or shall not be encrypted using the Encryption-Encap AVP. The specification of an AVP MAY state that the AVP may (or may not) be encrypted using the Encryption-Encap AVP. The specification SHOULD use a table in the format specified in Section 6.1. If the specification of an AVP is silent about whether the AVP shall or shall not be encrypted using the Encryption-Encap AVP, this implies that the AVP MAY be encrypted using the Encryption-Encap AVP.
任何AVP的规范应说明AVP应使用或不应使用Encryption Encap AVP进行加密。AVP的说明书可以说明可以（也可以不）使用加密包AVP对AVP进行加密。规范应使用第6.1节规定格式的表格。如果AVP规范没有说明是否应使用Encryption Encap AVP对AVP进行加密，这意味着可以使用Encryption Encap AVP对AVP进行加密。
This section defines a table format for the specification of whether an AVP shall or shall not be encrypted using the Encryption-Encap AVP.
本节定义了一种表格格式，用于说明是否应使用Encryption Encap AVP对AVP进行加密。
The table uses the following symbols:
该表使用以下符号：
Y: The AVP SHALL be encrypted using the Encryption-Encap AVP. If the AVP is encountered not encrypted using the Encryption-Encap AVP, it SHALL be considered invalid and the message containing the AVP SHALL be discarded.
Y：应使用Encryption Encap AVP对AVP进行加密。如果遇到未使用Encryption Encap AVP加密的AVP，则该AVP将被视为无效，并且包含该AVP的消息将被丢弃。
N: The AVP SHALL NOT be encrypted using the Encryption-Encap AVP. If the AVP is encountered encrypted using the Encryption-Encap AVP, it SHALL be considered invalid and the message containing the AVP SHALL be discarded.
N：不得使用Encryption Encap AVP对AVP进行加密。如果遇到使用Encryption Encap AVP加密的AVP，则视为无效，并丢弃包含AVP的消息。
X: The AVP MAY be encrypted using the Encryption-Encap AVP. If the AVP is encountered either encrypted or not encrypted using the Encryption-Encap AVP, it SHALL be considered valid.
X：可以使用Encryption Encap AVP对AVP进行加密。如果使用Encryption Encap AVP对AVP进行加密或未加密，则视为有效。
The legitimate occurrence of unencrypted AVPs and AVPs after decryption and unencapsulation SHALL be subject to the AVP Occurrence Table (Figure 4 in [RFC5191]).
未加密的AVP和解密和未封装后的AVP的合法出现应以AVP出现表（RFC5191中的图4）为准。
The following table shows the encryption requirements for the existing AVPs defined in [RFC5191]:
下表显示了[RFC5191]中定义的现有AVP的加密要求：
Attribute Name |Enc|
----------------------+---+
AUTH | N |
EAP-Payload | X |
Integrity-Algorithm | N |
Key-Id | N |
Nonce | N |
PRF-Algorithm | N |
Result-Code | N |
Session-Lifetime | X |
Termination-Cause | X |
----------------------+---+
Attribute Name |Enc|
----------------------+---+
AUTH | N |
EAP-Payload | X |
Integrity-Algorithm | N |
Key-Id | N |
Nonce | N |
PRF-Algorithm | N |
Result-Code | N |
Session-Lifetime | X |
Termination-Cause | X |
----------------------+---+
The following table shows the encryption requirements for the AVPs defined in [RFC6345]:
下表显示了[RFC6345]中定义的AVP的加密要求：
Attribute Name |Enc|
----------------------+---+
PaC-Information | N |
Relayed-Message | N |
----------------------+---+
Attribute Name |Enc|
----------------------+---+
PaC-Information | N |
Relayed-Message | N |
----------------------+---+
The following table shows the encryption requirements for the AVPs defined in this document:
下表显示了本文档中定义的AVP的加密要求：
Attribute Name |Enc|
----------------------+---+
Encryption-Algorithm | N |
Encryption-Encap | N |
----------------------+---+
Attribute Name |Enc|
----------------------+---+
Encryption-Algorithm | N |
Encryption-Encap | N |
----------------------+---+
The following table is an example showing the encryption requirements for a newly defined AVP, Example-AVP:
下表是显示新定义的AVP（示例AVP）的加密要求的示例：
Attribute Name |Enc|
----------------------+---+
Example-AVP | Y |
----------------------+---+
Attribute Name |Enc|
----------------------+---+
Example-AVP | Y |
----------------------+---+
The guidance for specifying the encryption requirements for a newly defined AVP is as follows:
为新定义的AVP指定加密要求的指南如下：
Y: If the payload needs privacy against eavesdroppers (e.g., carrying a secret key).
Y：如果有效载荷需要隐私以防窃听者（例如，携带秘密密钥）。
N: If the payload may need to be observed by on-path network elements (i.e., subject to deep packet inspection).
N：如果有效载荷可能需要由路径上的网络元件观察（即，接受深度数据包检查）。
X: If neither concern applies.
X：如果两种担心都不适用。
PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY are secret keys shared between the PaC and the PAA. They SHALL NOT be used for purposes other than those specified in this document. Compromise of these keys would lead to compromise of the secret information protected by these keys.
PANA_PAC_ENCR_密钥和PANA_PAA_ENCR_密钥是PAC和PAA之间共享的密钥。不得将其用于本文件规定以外的目的。这些密钥的泄露将导致受这些密钥保护的机密信息的泄露。
The use of AES-CTR encryption has its own security considerations, which are detailed in the Security Considerations section of [RFC3686]. Specifically:
AES-CTR加密的使用有其自身的安全注意事项，详见[RFC3686]的安全注意事项部分。明确地：
- The nonce specified in Section 4.1 meets the requirement of uniqueness-per-key usage.
- 第4.1节中规定的nonce满足每个密钥使用的唯一性要求。
- Section 4.1 of [RFC5191] states that if the EAP method generates cryptographic keys, an AUTH AVP will always be present in every PANA message after key generation. Therefore, an Encryption-Encap AVP will always be sent in conjunction with an AUTH AVP. This meets the requirement of a companion authentication function.
- [RFC5191]第4.1节规定，如果EAP方法生成加密密钥，则在密钥生成后，每个PANA消息中都将始终存在一个AUTH AVP。因此，加密Encap AVP将始终与身份验证AVP一起发送。这符合附带身份验证功能的要求。
As described in Sections 4 and 5, and following the IANA allocation policy on PANA messages [RFC5872], two PANA AVP codes and one set of AVP values have been registered. An additional encryption policy for AVP codes has also been registered.
如第4节和第5节所述，根据PANA消息的IANA分配策略[RFC5872]，已注册两个PANA AVP代码和一组AVP值。AVP代码的附加加密策略也已注册。
The following AVP codes have been registered in the "AVP Codes" sub-registry of the "Protocol for Carrying Authentication for Network Access (PANA) Parameters" registry:
以下AVP代码已在“承载网络访问认证（PANA）参数协议”注册表的“AVP代码”子注册表中注册：
o A standard AVP code of 12 for the Encryption-Encap AVP.
o 加密Encap AVP的标准AVP代码为12。
o A standard AVP code of 13 for the Encryption-Algorithm AVP.
o 用于加密算法AVP的标准AVP代码为13。
The following AVP values representing the encryption algorithm identifier for the Encryption-Algorithm AVP code have been assigned in the "Encryption-Algorithm (AVP Code 13) AVP Values" sub-registry under the "Protocol for Carrying Authentication for Network Access (PANA) Parameters" registry":
以下代表加密算法AVP代码的加密算法标识符的AVP值已分配到“加密算法（AVP代码13）AVP值”子注册表中的“网络访问认证协议（PANA）参数”注册表下：
o An AVP value of 1 for AES128_CTR.
o AES128_CTR的AVP值为1。
o All other AVP values (0, 2-4294967295) are unassigned.
o 所有其他AVP值（0,2-4294967295）均未分配。
The registration procedures are IETF Review or IESG Approval in accordance with [RFC5872].
根据[RFC5872]，注册程序为IETF审查或IESG批准。
The additional encryption policy defined in Section 6.1 has been added as a column labeled "Enc" in the "AVP Codes" sub-registry and has been applied to all existing AVP codes and those defined in this specification.
第6.1节中定义的附加加密策略已添加为“AVP代码”子注册表中标记为“Enc”的列，并已应用于所有现有AVP代码和本规范中定义的代码。
The authors would like to thank Yoshihiro Ohba, Yasuyuki Tanaka, Adrian Farrel, Brian Carpenter, Yaron Sheffer, Ralph Droms, Stephen Farrell, Barry Leiba, and Sean Turner for their valuable comments.
作者要感谢大贺吉弘、田中靖国、阿德里安·法雷尔、布赖恩·卡彭特、雅伦·谢弗、拉尔夫·德罗姆斯、斯蒂芬·法雷尔、巴里·莱巴和肖恩·特纳的宝贵评论。
[NIST_SP800_38A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", December 2001.
[NIST_SP800_38A]德沃金，M.，“分组密码操作模式的建议：方法和技术”，2001年12月。
[NIST_SP800_38C] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", May 2004.
[NIST_SP800_38C]Dworkin，M.，“分组密码操作模式的建议：认证和保密的CCM模式”，2004年5月。
[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月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
[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月。
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191]Forsberg，D.，Ohba，Y.，Ed.，Patil，B.，Tschofenig，H.，和A.Yegin，“承载网络接入认证（PANA）的协议”，RFC 51912008年5月。
[RFC5872] Arkko, J. and A. Yegin, "IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)", RFC 5872, May 2010.
[RFC5872]Arkko，J.和A.Yegin，“承载网络访问认证（PANA）协议的IANA规则”，RFC 5872，2010年5月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", RFC 6345, August 2011.
[RFC6345]Duffy，P.，Chakrabarti，S.，Cragie，R.，Ohba，Y.，Ed.，和A.Yegin，“承载网络接入认证（PANA）中继元件的协议”，RFC 63452011年8月。
Authors' Addresses
作者地址
Alper Yegin Samsung Istanbul Turkey
土耳其伊斯坦布尔阿尔珀·耶金酒店
EMail: alper.yegin@yegin.org
EMail: alper.yegin@yegin.org
Robert Cragie Gridmerge Ltd. 89 Greenfield Crescent Wakefield, WF4 4WA United Kingdom
Robert Cragie Gridmerge Ltd.89 Greenfield Crescent Wakefield，WF4 4WA英国
EMail: robert.cragie@gridmerge.com
EMail: robert.cragie@gridmerge.com