Network Working Group D. Harkins
Request for Comments: 2409 D. Carrel
Category: Standards Track cisco Systems
November 1998
Network Working Group D. Harkins
Request for Comments: 2409 D. Carrel
Category: Standards Track cisco Systems
November 1998
The Internet Key Exchange (IKE)
因特网密钥交换（IKE）
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Table Of Contents
目录
1 Abstract........................................................ 2
2 Discussion...................................................... 2
3 Terms and Definitions........................................... 3
3.1 Requirements Terminology...................................... 3
3.2 Notation...................................................... 3
3.3 Perfect Forward Secrecty...................................... 5
3.4 Security Association.......................................... 5
4 Introduction.................................................... 5
5 Exchanges....................................................... 8
5.1 Authentication with Digital Signatures........................ 10
5.2 Authentication with Public Key Encryption..................... 12
5.3 A Revised method of Authentication with Public Key Encryption. 13
5.4 Authentication with a Pre-Shared Key.......................... 16
5.5 Quick Mode.................................................... 16
5.6 New Group Mode................................................ 20
5.7 ISAKMP Informational Exchanges................................ 20
6 Oakley Groups................................................... 21
6.1 First Oakley Group............................................ 21
6.2 Second Oakley Group........................................... 22
6.3 Third Oakley Group............................................ 22
6.4 Fourth Oakley Group........................................... 23
7 Payload Explosion of Complete Exchange.......................... 23
7.1 Phase 1 with Main Mode........................................ 23
7.2 Phase 2 with Quick Mode....................................... 25
8 Perfect Forward Secrecy Example................................. 27
9 Implementation Hints............................................ 27
1 Abstract........................................................ 2
2 Discussion...................................................... 2
3 Terms and Definitions........................................... 3
3.1 Requirements Terminology...................................... 3
3.2 Notation...................................................... 3
3.3 Perfect Forward Secrecty...................................... 5
3.4 Security Association.......................................... 5
4 Introduction.................................................... 5
5 Exchanges....................................................... 8
5.1 Authentication with Digital Signatures........................ 10
5.2 Authentication with Public Key Encryption..................... 12
5.3 A Revised method of Authentication with Public Key Encryption. 13
5.4 Authentication with a Pre-Shared Key.......................... 16
5.5 Quick Mode.................................................... 16
5.6 New Group Mode................................................ 20
5.7 ISAKMP Informational Exchanges................................ 20
6 Oakley Groups................................................... 21
6.1 First Oakley Group............................................ 21
6.2 Second Oakley Group........................................... 22
6.3 Third Oakley Group............................................ 22
6.4 Fourth Oakley Group........................................... 23
7 Payload Explosion of Complete Exchange.......................... 23
7.1 Phase 1 with Main Mode........................................ 23
7.2 Phase 2 with Quick Mode....................................... 25
8 Perfect Forward Secrecy Example................................. 27
9 Implementation Hints............................................ 27
10 Security Considerations........................................ 28
11 IANA Considerations............................................ 30
12 Acknowledgments................................................ 31
13 References..................................................... 31
Appendix A........................................................ 33
Appendix B........................................................ 37
Authors' Addresses................................................ 40
Authors' Note..................................................... 40
Full Copyright Statement.......................................... 41
10 Security Considerations........................................ 28
11 IANA Considerations............................................ 30
12 Acknowledgments................................................ 31
13 References..................................................... 31
Appendix A........................................................ 33
Appendix B........................................................ 37
Authors' Addresses................................................ 40
Authors' Note..................................................... 40
Full Copyright Statement.......................................... 41
ISAKMP ([MSST98]) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges.
ISAKMP（[MSST98]）为身份验证和密钥交换提供了一个框架，但没有定义它们。ISAKMP设计为独立于密钥交换；也就是说，它旨在支持许多不同的密钥交换。
Oakley ([Orm96]) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication).
Oakley（[Orm96]）描述了一系列密钥交换——称为“模式”——并详细介绍了每种交换提供的服务（例如，密钥的完美前向保密、身份保护和身份验证）。
SKEME ([SKEME]) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment.
SKEME（[SKEME]）描述了一种通用密钥交换技术，它提供匿名性、可重复性和快速密钥更新。
This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI.
本文档描述了一种协议，该协议使用部分Oakley和部分SKEME与ISAKMP结合使用，以获得用于ISAKMP的认证密钥材料，并用于其他安全关联，如IETF IPsec DOI的AH和ESP。
This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner.
本备忘录描述了一种混合协议。其目的是以受保护的方式协商安全关联，并为其提供经过身份验证的密钥材料。
Processes which implement this memo can be used for negotiating virtual private networks (VPNs) and also for providing a remote user from a remote site (whose IP address need not be known beforehand) access to a secure host or network.
实现此备忘录的过程可用于协商虚拟专用网络（VPN），也可用于为远程站点的远程用户（其IP地址不需要事先知道）提供对安全主机或网络的访问。
Client negotiation is supported. Client mode is where the negotiating parties are not the endpoints for which security association negotiation is taking place. When used in client mode, the identities of the end parties remain hidden.
支持客户端协商。客户端模式是指协商方不是正在进行安全关联协商的端点。在客户端模式下使用时，终端方的身份保持隐藏。
This does not implement the entire Oakley protocol, but only a subset necessary to satisfy its goals. It does not claim conformance or compliance with the entire Oakley protocol nor is it dependant in any way on the Oakley protocol.
这并没有实现整个Oakley协议，而只是满足其目标所需的子集。它不声称符合或遵守整个Oakley协议，也不以任何方式依赖于Oakley协议。
Likewise, this does not implement the entire SKEME protocol, but only the method of public key encryption for authentication and its concept of fast re-keying using an exchange of nonces. This protocol is not dependant in any way on the SKEME protocol.
同样，这并没有实现整个SKEME协议，而只是实现了用于身份验证的公钥加密方法及其使用nonce交换的快速重设密钥的概念。本协议不以任何方式依赖于SKEME协议。
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97].
本文件中出现的关键词“必须”、“不得”、“必需”、“应该”、“不应该”和“可能”应按照[Bra97]中所述进行解释。
The following notation is used throughout this memo.
本备忘录中使用了以下符号。
HDR is an ISAKMP header whose exchange type is the mode. When writen as HDR* it indicates payload encryption.
HDR是一个ISAKMP头，其交换类型为模式。当写入为HDR*时，表示有效负载加密。
SA is an SA negotiation payload with one or more proposals. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one.
SA是具有一个或多个提案的SA谈判有效负载。发起人可以提供多个谈判方案；响应者必须只使用一个响应。
<P>_b indicates the body of payload <P>-- the ISAKMP generic vpayload is not included.
<P> _b表示有效载荷主体<P>——不包括ISAKMP通用vpayload。
SAi_b is the entire body of the SA payload (minus the ISAKMP generic header)-- i.e. the DOI, situation, all proposals and all transforms offered by the Initiator.
SAi_b是SA有效载荷的整个主体（减去ISAKMP通用头）——即DOI、情况、发起人提供的所有建议和所有转换。
CKY-I and CKY-R are the Initiator's cookie and the Responder's cookie, respectively, from the ISAKMP header.
CKY-I和CKY-R分别是ISAKMP头中发起方的cookie和响应方的cookie。
g^xi and g^xr are the Diffie-Hellman ([DH]) public values of the initiator and responder respectively.
g^xi和g^xr分别是发起方和响应方的Diffie Hellman（[DH]）公共值。
g^xy is the Diffie-Hellman shared secret.
g^xy是Diffie Hellman的共同秘密。
KE is the key exchange payload which contains the public information exchanged in a Diffie-Hellman exchange. There is no particular encoding (e.g. a TLV) used for the data of a KE payload.
KE是密钥交换有效载荷，它包含在Diffie-Hellman交换中交换的公共信息。没有用于KE有效载荷数据的特定编码（例如TLV）。
Nx is the nonce payload; x can be: i or r for the ISAKMP initiator and responder respectively.
Nx是当前有效载荷；对于ISAKMP启动器和响应程序，x可以分别为：i或r。
IDx is the identification payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder respectively during phase one negotiation; or "ui" or "ur" for the user initiator and responder respectively during phase two. The ID payload format for the Internet DOI is defined in [Pip97].
IDx是“x”的标识有效载荷。在第一阶段协商期间，对于ISAKMP发起方和响应方，x可以分别为“ii”或“ir”；或在第二阶段分别为用户发起方和响应方提供“ui”或“ur”。互联网DOI的ID有效负载格式在[Pip97]中定义。
SIG is the signature payload. The data to sign is exchange-specific.
SIG是签名有效负载。要签名的数据是特定于exchange的。
CERT is the certificate payload.
CERT是证书有效负载。
HASH (and any derivitive such as HASH(2) or HASH_I) is the hash payload. The contents of the hash are specific to the authentication method.
HASH（以及任何派生词，如HASH（2）或HASH_I）是HASH负载。哈希的内容特定于身份验证方法。
prf(key, msg) is the keyed pseudo-random function-- often a keyed hash function-- used to generate a deterministic output that appears pseudo-random. prf's are used both for key derivations and for authentication (i.e. as a keyed MAC). (See [KBC96]).
prf（key，msg）是键控伪随机函数——通常是键控哈希函数——用于生成伪随机的确定性输出。prf用于密钥派生和身份验证（即作为密钥MAC）。（见[KBC96]）。
SKEYID is a string derived from secret material known only to the active players in the exchange.
SKEYID是一个字符串，其来源于只有交易中的活跃玩家才知道的秘密材料。
SKEYID_e is the keying material used by the ISAKMP SA to protect the confidentiality of its messages.
SKEYID_e是ISAKMP SA用于保护其消息机密性的密钥材料。
SKEYID_a is the keying material used by the ISAKMP SA to authenticate its messages.
SKEYID_a是ISAKMP SA用于验证其消息的密钥材料。
SKEYID_d is the keying material used to derive keys for non-ISAKMP security associations.
SKEYID_d是用于派生非ISAKMP安全关联密钥的密钥材料。
<x>y indicates that "x" is encrypted with the key "y".
<x> y表示“x”是用密钥“y”加密的。
--> signifies "initiator to responder" communication (requests).
-->表示“发起者到响应者”通信（请求）。
<-- signifies "responder to initiator" communication (replies).
<--表示“响应者到发起人”通信（回复）。
| signifies concatenation of information-- e.g. X | Y is the concatentation of X with Y.
|表示信息的串联——例如，X | Y是X与Y的浓缩。
[x] indicates that x is optional.
[x] 指示x是可选的。
Message encryption (when noted by a '*' after the ISAKMP header) MUST begin immediately after the ISAKMP header. When communication is protected, all payloads following the ISAKMP header MUST be encrypted. Encryption keys are generated from SKEYID_e in a manner that is defined for each algorithm.
消息加密（在ISAKMP头之后用“*”标记时）必须在ISAKMP头之后立即开始。当通信受到保护时，必须对ISAKMP头之后的所有有效负载进行加密。加密密钥是以为每个算法定义的方式从SKEYID_e生成的。
When used in the memo Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key. For PFS to exist the key used to protect transmission of data MUST NOT be used to derive any additional keys, and if the key used to protect transmission of data was derived from some other keying material, that material MUST NOT be used to derive any more keys.
在备忘录中使用时，完美前向保密（PFS）指的是单个密钥的泄露将只允许访问受单个密钥保护的数据的概念。对于PFS，用于保护数据传输的密钥不得用于派生任何其他密钥，如果用于保护数据传输的密钥派生自其他密钥材料，则不得使用该材料派生任何其他密钥。
Perfect Forward Secrecy for both keys and identities is provided in this protocol. (Sections 5.5 and 8).
该协议为密钥和身份提供了完美的前向保密性。（第5.5节和第8节）。
A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their communication.
安全关联（SA）是一组用于保护信息的策略和密钥。ISAKMP SA是协商对等方在此协议中用于保护其通信的共享策略和密钥。
Oakley and SKEME each define a method to establish an authenticated key exchange. This includes payloads construction, the information payloads carry, the order in which they are processed and how they are used.
Oakley和SKEME各自定义了一种方法来建立经过身份验证的密钥交换。这包括有效载荷构造、有效载荷携带的信息、处理顺序以及使用方式。
While Oakley defines "modes", ISAKMP defines "phases". The relationship between the two is very straightforward and IKE presents different exchanges as modes which operate in one of two phases.
Oakley定义了“模式”，而ISAKMP定义了“阶段”。两者之间的关系非常简单，IKE将不同的交换作为两个阶段之一运行的模式。
Phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with which to communicate. This is called the ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode" each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode" MUST ONLY be used in phase 1.
第1阶段是两个ISAKMP对等方建立一个安全的、经过身份验证的信道进行通信。这被称为ISAKMP安全协会（SA）。“主模式”和“攻击模式”分别完成第1阶段的交换。“主模式”和“攻击模式”只能在阶段1中使用。
Phase 2 is where Security Associations are negotiated on behalf of services such as IPsec or any other service which needs key material and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 exchange. "Quick Mode" MUST ONLY be used in phase 2.
第2阶段是代表诸如IPsec或任何其他需要密钥材料和/或参数协商的服务协商安全关联的阶段。“快速模式”完成第2阶段交换。“快速模式”只能在第2阶段使用。
"New Group Mode" is not really a phase 1 or phase 2. It follows phase 1, but serves to establish a new group which can be used in future negotiations. "New Group Mode" MUST ONLY be used after phase 1.
“新集团模式”并非真正的第一阶段或第二阶段。它遵循第一阶段，但用于建立一个新的小组，可用于未来的谈判。“新组模式”只能在第1阶段之后使用。
The ISAKMP SA is bi-directional. That is, once established, either party may initiate Quick Mode, Informational, and New Group Mode Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified by the Initiator's cookie followed by the Responder's cookie-- the role of each party in the phase 1 exchange dictates which cookie is the Initiator's. The cookie order established by the phase 1 exchange continues to identify the ISAKMP SA regardless of the direction the Quick Mode, Informational, or New Group exchange. In other words, the cookies MUST NOT swap places when the direction of the ISAKMP SA changes.
ISAKMP SA是双向的。也就是说，一旦建立，任何一方都可以启动快速模式、信息模式和新的组模式交换。根据基本ISAKMP文档，ISAKMP SA由发起方的cookie和响应方的cookie标识——第1阶段交换中各方的角色决定了哪个cookie是发起方的cookie。第1阶段交换建立的cookie顺序继续标识ISAKMP SA，而不管快速模式交换、信息交换或新组交换的方向如何。换句话说，当ISAKMP SA的方向改变时，cookie不能交换位置。
With the use of ISAKMP phases, an implementation can accomplish very fast keying when necessary. A single phase 1 negotiation may be used for more than one phase 2 negotiation. Additionally a single phase 2 negotiation can request multiple Security Associations. With these optimizations, an implementation can see less than one round trip per SA as well as less than one DH exponentiation per SA. "Main Mode" for phase 1 provides identity protection. When identity protection is not needed, "Aggressive Mode" can be used to reduce round trips even further. Developer hints for doing these optimizations are included below. It should also be noted that using public key encryption to authenticate an Aggressive Mode exchange will still provide identity protection.
通过使用ISAKMP阶段，实现可以在必要时完成非常快速的键控。单个阶段1协商可用于多个阶段2协商。此外，单阶段2协商可以请求多个安全关联。通过这些优化，一个实现可以看到每个SA不到一次往返，以及每个SA不到一次DH求幂。阶段1的“主模式”提供身份保护。当不需要身份保护时，可以使用“攻击模式”进一步减少往返行程。下面包含了执行这些优化的开发人员提示。还应注意的是，使用公钥加密对主动模式交换进行身份验证仍将提供身份保护。
This protocol does not define its own DOI per se. The ISAKMP SA, established in phase 1, MAY use the DOI and situation from a non-ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an implementation MAY choose to restrict use of the ISAKMP SA for establishment of SAs for services of the same DOI. Alternately, an ISAKMP SA MAY be established with the value zero in both the DOI and situation (see [MSST98] for a description of these fields) and in this case implementations will be free to establish security services for any defined DOI using this ISAKMP SA. If a DOI of zero is used for establishment of a phase 1 SA, the syntax of the identity payloads used in phase 1 is that defined in [MSST98] and not from any DOI-- e.g. [Pip97]-- which may further expand the syntax and semantics of identities.
该协议本身并不定义自己的DOI。在阶段1中建立的ISAKMP SA可以使用来自非ISAKMP服务（如IETF IPSec DOI[Pip97]）的DOI和情况。在这种情况下，实现可以选择限制使用ISAKMP SA为同一DOI的服务建立SA。或者，可以在DOI和情境中使用零值建立ISAKMP SA（有关这些字段的描述，请参见[MSST98]），在这种情况下，实现将可以使用此ISAKMP SA为任何定义的DOI自由建立安全服务。如果零DOI用于建立阶段1 SA，则阶段1中使用的身份有效载荷的语法为[MSST98]中定义的语法，而不是来自任何DOI（例如[Pip97]），这可能进一步扩展身份的语法和语义。
The following attributes are used by IKE and are negotiated as part of the ISAKMP Security Association. (These attributes pertain only to the ISAKMP Security Association and not to any Security Associations that ISAKMP may be negotiating on behalf of other services.)
以下属性由IKE使用，并作为ISAKMP安全关联的一部分进行协商。（这些属性仅适用于ISAKMP安全关联，而不适用于ISAKMP可能代表其他服务协商的任何安全关联。）
- encryption algorithm
- 加密算法
- hash algorithm
- 散列算法
- authentication method
- 认证方法
- information about a group over which to do Diffie-Hellman.
- 关于要执行Diffie Hellman的组的信息。
All of these attributes are mandatory and MUST be negotiated. In addition, it is possible to optionally negotiate a psuedo-random function ("prf"). (There are currently no negotiable pseudo-random functions defined in this document. Private use attribute values can be used for prf negotiation between consenting parties). If a "prf" is not negotiation, the HMAC (see [KBC96]) version of the negotiated hash algorithm is used as a pseudo-random function. Other non-mandatory attributes are described in Appendix A. The selected hash algorithm MUST support both native and HMAC modes.
所有这些属性都是强制性的，必须协商。此外，可以选择协商伪随机函数（“prf”）。（本文档中目前没有定义可协商的伪随机函数。私用属性值可用于同意方之间的prf协商）。如果“prf”不是协商，则协商哈希算法的HMAC（参见[KBC96]）版本将用作伪随机函数。附录A中描述了其他非强制性属性。所选哈希算法必须同时支持本机和HMAC模式。
The Diffie-Hellman group MUST be either specified using a defined group description (section 6) or by defining all attributes of a group (section 5.6). Group attributes (such as group type or prime-- see Appendix A) MUST NOT be offered in conjunction with a previously defined group (either a reserved group description or a private use description that is established after conclusion of a New Group Mode exchange).
Diffie-Hellman组必须使用已定义的组描述（第6节）或通过定义组的所有属性（第5.6节）来指定。组属性（如组类型或基本属性——见附录A）不得与先前定义的组（保留组描述或新组模式交换结束后建立的专用描述）一起提供。
IKE implementations MUST support the following attribute values:
IKE实现必须支持以下属性值：
- DES [DES] in CBC mode with a weak, and semi-weak, key check (weak and semi-weak keys are referenced in [Sch96] and listed in Appendix A). The key is derived according to Appendix B.
- CBC模式下的DES[DES]，带有弱和半弱密钥检查（弱和半弱密钥在[Sch96]中引用，并在附录a中列出）。密钥根据附录B导出。
- MD5 [MD5] and SHA [SHA}.
- MD5[MD5]和SHA[SHA}。
- Authentication via pre-shared keys.
- 通过预共享密钥进行身份验证。
- MODP over default group number one (see below).
- 默认组1上的MODP（见下文）。
In addition, IKE implementations SHOULD support: 3DES for encryption; Tiger ([TIGER]) for hash; the Digital Signature Standard, RSA [RSA] signatures and authentication with RSA public key encryption; and MODP group number 2. IKE implementations MAY support any additional encryption algorithms defined in Appendix A and MAY support ECP and EC2N groups.
此外，IKE实现应该支持：用于加密的3DES；老虎（[Tiger]）表示散列；数字签名标准、RSA[RSA]签名和使用RSA公钥加密的身份验证；和MODP组2号。IKE实现可支持附录A中定义的任何其他加密算法，并可支持ECP和EC2N组。
The IKE modes described here MUST be implemented whenever the IETF IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes described here.
每当实现IETF IPsec DOI[Pip97]时，必须实现此处描述的IKE模式。其他内政部可使用此处描述的模式。
There are two basic methods used to establish an authenticated key exchange: Main Mode and Aggressive Mode. Each generates authenticated keying material from an ephemeral Diffie-Hellman exchange. Main Mode MUST be implemented; Aggressive Mode SHOULD be implemented. In addition, Quick Mode MUST be implemented as a mechanism to generate fresh keying material and negotiate non-ISAKMP security services. In addition, New Group Mode SHOULD be implemented as a mechanism to define private groups for Diffie-Hellman exchanges. Implementations MUST NOT switch exchange types in the middle of an exchange.
有两种基本方法用于建立经过身份验证的密钥交换：主模式和主动模式。每个都从短暂的Diffie-Hellman交换生成经过身份验证的密钥材料。必须实施主模式；应实施积极模式。此外，必须将快速模式作为生成新密钥材料和协商非ISAKMP安全服务的机制来实现。此外，应实施新的组模式，作为为Diffie-Hellman交换定义私有组的机制。实现不能在交换中间切换交换类型。
Exchanges conform to standard ISAKMP payload syntax, attribute encoding, timeouts and retransmits of messages, and informational messages-- e.g a notify response is sent when, for example, a proposal is unacceptable, or a signature verification or decryption was unsuccessful, etc.
交换符合标准ISAKMP有效负载语法、属性编码、消息超时和重新传输以及信息性消息——例如，当提案不可接受、签名验证或解密失败等情况下，发送通知响应。
The SA payload MUST precede all other payloads in a phase 1 exchange. Except where otherwise noted, there are no requirements for ISAKMP payloads in any message to be in any particular order.
在第1阶段交换中，SA有效负载必须先于所有其他有效负载。除非另有说明，否则不要求任何消息中的ISAKMP有效载荷按任何特定顺序排列。
The Diffie-Hellman public value passed in a KE payload, in either a phase 1 or phase 2 exchange, MUST be the length of the negotiated Diffie-Hellman group enforced, if necessary, by pre-pending the value with zeros.
在第1阶段或第2阶段交换中，在KE有效负载中传递的Diffie-Hellman公共值必须是协商的Diffie-Hellman组的长度，如有必要，通过使用零预挂起该值来强制执行。
The length of nonce payload MUST be between 8 and 256 bytes inclusive.
nonce有效负载的长度必须介于8到256字节之间（含8到256字节）。
Main Mode is an instantiation of the ISAKMP Identity Protect Exchange: The first two messages negotiate policy; the next two exchange Diffie-Hellman public values and ancillary data (e.g. nonces) necessary for the exchange; and the last two messages authenticate the Diffie-Hellman Exchange. The authentication method negotiated as part of the initial ISAKMP exchange influences the composition of the payloads but not their purpose. The XCHG for Main Mode is ISAKMP Identity Protect.
主模式是ISAKMP身份保护交换的一个实例：前两条消息协商策略；接下来的两个交换Diffie-Hellman公共值和交换所需的辅助数据（例如nonce）；最后两条消息验证Diffie-Hellman交换。作为初始ISAKMP交换的一部分协商的身份验证方法会影响有效负载的组成，但不会影响其用途。主模式的XCHG是ISAKMP身份保护。
Similarly, Aggressive Mode is an instantiation of the ISAKMP Aggressive Exchange. The first two messages negotiate policy, exchange Diffie-Hellman public values and ancillary data necessary for the exchange, and identities. In addition the second message authenticates the responder. The third message authenticates the initiator and provides a proof of participation in the exchange. The XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY NOT be sent under protection of the ISAKMP SA allowing each party to
类似地，主动模式是ISAKMP主动交换的一个实例。前两条消息协商策略、交换Diffie-Hellman公共值和交换所需的辅助数据以及身份。此外，第二条消息对响应者进行身份验证。第三条消息验证启动器并提供参与交换的证明。主动模式的XCHG是ISAKMP主动模式。最终消息可能不会在ISAKMP SA的保护下发送，允许各方
postpone exponentiation, if desired, until negotiation of this exchange is complete. The graphic depictions of Aggressive Mode show the final payload in the clear; it need not be.
如果需要，推迟幂运算，直到交换的协商完成。攻击模式的图形描述以清晰的方式显示最终有效载荷；不必如此。
Exchanges in IKE are not open ended and have a fixed number of messages. Receipt of a Certificate Request payload MUST NOT extend the number of messages transmitted or expected.
IKE中的交换不是开放式的，具有固定数量的消息。证书请求有效负载的接收不得扩展传输或预期的消息数量。
Security Association negotiation is limited with Aggressive Mode. Due to message construction requirements the group in which the Diffie-Hellman exchange is performed cannot be negotiated. In addition, different authentication methods may further constrain attribute negotiation. For example, authentication with public key encryption cannot be negotiated and when using the revised method of public key encryption for authentication the cipher and hash cannot be negotiated. For situations where the rich attribute negotiation capabilities of IKE are required Main Mode may be required.
安全关联协商受攻击模式的限制。由于消息构造要求，无法协商执行Diffie-Hellman交换的组。此外，不同的身份验证方法可能进一步限制属性协商。例如，无法协商使用公钥加密的身份验证，并且在使用修改后的公钥加密方法进行身份验证时，无法协商密码和哈希。对于需要IKE丰富属性协商功能的情况，可能需要主模式。
Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG values for Quick Mode and New Group Mode are defined in Appendix A.
快速模式和新组模式在ISAKMP中没有模拟。附录A中定义了快速模式和新组模式的XCHG值。
Main Mode, Aggressive Mode, and Quick Mode do security association negotiation. Security Association offers take the form of Tranform Payload(s) encapsulated in Proposal Payload(s) encapsulated in Security Association (SA) payload(s). If multiple offers are being made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST take the form of multiple Transform Payloads for a single Proposal Payload in a single SA payload. To put it another way, for phase 1 exchanges there MUST NOT be multiple Proposal Payloads for a single SA payload and there MUST NOT be multiple SA payloads. This document does not proscribe such behavior on offers in phase 2 exchanges.
主模式、攻击模式和快速模式进行安全关联协商。安全关联报价采用封装在安全关联（SA）有效载荷中的提案有效载荷中的转换有效载荷的形式。如果为第1阶段交换（主模式和主动模式）提供多个报价，则必须在单个SA有效载荷中为单个提案有效载荷采用多个转换有效载荷的形式。换句话说，对于阶段1交换，单个SA有效负载不得有多个提案有效负载，也不得有多个SA有效负载。本文件不禁止在第2阶段交易中的报价中出现此类行为。
There is no limit on the number of offers the initiator may send to the responder but conformant implementations MAY choose to limit the number of offers it will inspect for performance reasons.
发起者可以发送给响应者的提供数量没有限制，但是一致性实现可以选择限制出于性能原因将检查的提供数量。
During security association negotiation, initiators present offers for potential security associations to responders. Responders MUST NOT modify attributes of any offer, attribute encoding excepted (see Appendix A). If the initiator of an exchange notices that attribute values have changed or attributes have been added or deleted from an offer made, that response MUST be rejected.
在安全关联协商期间，发起人向响应者提供潜在安全关联的报价。响应者不得修改任何报价的属性，属性编码除外（见附录A）。如果交换的发起人注意到属性值已更改或属性已从提供的报价中添加或删除，则必须拒绝该响应。
Four different authentication methods are allowed with either Main Mode or Aggressive Mode-- digital signature, two forms of authentication with public key encryption, or pre-shared key. The value SKEYID is computed seperately for each authentication method.
主模式或主动模式允许四种不同的身份验证方法—数字签名、使用公钥加密的两种身份验证形式或预共享密钥。对于每个身份验证方法，分别计算SKEYID值。
For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy)
For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I |
CKY-R)
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b |
Nr_b)
For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy)
For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I |
CKY-R)
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b |
Nr_b)
The result of either Main Mode or Aggressive Mode is three groups of authenticated keying material:
主模式或主动模式的结果是三组经过验证的密钥材料：
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
and agreed upon policy to protect further communications. The values of 0, 1, and 2 above are represented by a single octet. The key used for encryption is derived from SKEYID_e in an algorithm-specific manner (see appendix B).
并商定了保护进一步通信的政策。上面的0、1和2的值由一个八位组表示。用于加密的密钥以特定于算法的方式从SKEYID_e中派生（见附录B）。
To authenticate either exchange the initiator of the protocol generates HASH_I and the responder generates HASH_R where:
要对任一交换进行身份验证，协议的发起方生成哈希值，响应方生成哈希值，其中：
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
For authentication with digital signatures, HASH_I and HASH_R are signed and verified; for authentication with either public key encryption or pre-shared keys, HASH_I and HASH_R directly authenticate the exchange. The entire ID payload (including ID type, port, and protocol but excluding the generic header) is hashed into both HASH_I and HASH_R.
对于使用数字签名的身份验证，对HASH_I和HASH_R进行签名和验证；对于使用公钥加密或预共享密钥的身份验证，哈希I和哈希R直接对交换进行身份验证。整个ID有效负载（包括ID类型、端口和协议，但不包括通用头）被散列到哈希_I和哈希_R中。
As mentioned above, the negotiated authentication method influences the content and use of messages for Phase 1 Modes, but not their intent. When using public keys for authentication, the Phase 1 exchange can be accomplished either by using signatures or by using public key encryption (if the algorithm supports it). Following are Phase 1 exchanges with different authentication options.
如上所述，协商认证方法影响第1阶段模式的消息内容和使用，但不影响其意图。当使用公钥进行身份验证时，阶段1交换可以通过使用签名或使用公钥加密（如果算法支持）来完成。以下是具有不同身份验证选项的第1阶段交换。
Using signatures, the ancillary information exchanged during the second roundtrip are nonces; the exchange is authenticated by signing a mutually obtainable hash. Main Mode with signature authentication is described as follows:
使用签名，在第二次往返期间交换的辅助信息是nonce；通过对相互可获得的哈希进行签名来验证交换。签名认证的主要模式描述如下：
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, [ CERT, ] SIG_I -->
<-- HDR*, IDir, [ CERT, ] SIG_R
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, [ CERT, ] SIG_I -->
<-- HDR*, IDir, [ CERT, ] SIG_R
Aggressive mode with signatures in conjunction with ISAKMP is described as follows:
结合ISAKMP的带签名的攻击模式描述如下：
Initiator Responder
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir,
[ CERT, ] SIG_R
HDR, [ CERT, ] SIG_I -->
Initiator Responder
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir,
[ CERT, ] SIG_R
HDR, [ CERT, ] SIG_I -->
In both modes, the signed data, SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively.
在这两种模式中，签名数据SIG_I或SIG_R分别是应用于HASH_I或HASH_R的协商数字签名算法的结果。
In general the signature will be over HASH_I and HASH_R as above using the negotiated prf, or the HMAC version of the negotiated hash function (if no prf is negotiated). However, this can be overridden for construction of the signature if the signature algorithm is tied to a particular hash algorithm (e.g. DSS is only defined with SHA's 160 bit output). In this case, the signature will be over HASH_I and HASH_R as above, except using the HMAC version of the hash algorithm associated with the signature method. The negotiated prf and hash function would continue to be used for all other prescribed pseudo-random functions.
通常，签名将使用协商的prf或协商的哈希函数（如果没有协商prf）的HMAC版本通过上述哈希I和哈希R进行。但是，如果签名算法与特定的哈希算法相关联（例如，DSS仅使用SHA的160位输出定义），则在构造签名时可以覆盖该属性。在这种情况下，除了使用与签名方法相关联的哈希算法的HMAC版本外，签名将如上所述地覆盖哈希I和哈希R。协商的prf和哈希函数将继续用于所有其他规定的伪随机函数。
Since the hash algorithm used is already known there is no need to encode its OID into the signature. In addition, there is no binding between the OIDs used for RSA signatures in PKCS #1 and those used in this document. Therefore, RSA signatures MUST be encoded as a private key encryption in PKCS #1 format and not as a signature in PKCS #1 format (which includes the OID of the hash algorithm). DSS signatures MUST be encoded as r followed by s.
由于所使用的哈希算法是已知的，因此无需将其OID编码到签名中。此外，PKCS#1中用于RSA签名的OID与本文档中使用的OID之间没有约束力。因此，RSA签名必须编码为PKCS#1格式的私钥加密，而不是PKCS#1格式的签名（包括哈希算法的OID）。DSS签名必须编码为r，后跟s。
One or more certificate payloads MAY be optionally passed.
可以选择传递一个或多个证书有效负载。
Using public key encryption to authenticate the exchange, the ancillary information exchanged is encrypted nonces. Each party's ability to reconstruct a hash (proving that the other party decrypted the nonce) authenticates the exchange.
通过使用公钥加密对交换进行身份验证，交换的辅助信息将立即加密。每一方重构散列（证明另一方解密了nonce）的能力验证了交换。
In order to perform the public key encryption, the initiator must already have the responder's public key. In the case where the responder has multiple public keys, a hash of the certificate the initiator is using to encrypt the ancillary information is passed as part of the third message. In this way the responder can determine which corresponding private key to use to decrypt the encrypted payloads and identity protection is retained.
为了执行公钥加密，发起方必须已经拥有响应方的公钥。在响应者具有多个公钥的情况下，启动器用于加密辅助信息的证书的散列作为第三消息的一部分被传递。通过这种方式，响应者可以确定使用哪个对应的私钥来解密加密的有效载荷，并保留身份保护。
In addition to the nonce, the identities of the parties (IDii and IDir) are also encrypted with the other party's public key. If the authentication method is public key encryption, the nonce and identity payloads MUST be encrypted with the public key of the other party. Only the body of the payloads are encrypted, the payload headers are left in the clear.
除了nonce之外，双方的身份（IDii和IDir）也使用另一方的公钥加密。如果身份验证方法是公钥加密，则必须使用另一方的公钥对nonce和identity有效载荷进行加密。只有有效载荷的主体被加密，有效载荷头被保留在空白处。
When using encryption for authentication, Main Mode is defined as follows.
使用加密进行身份验证时，主模式定义如下。
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, [ HASH(1), ]
<IDii_b>PubKey_r,
<Ni_b>PubKey_r -->
HDR, KE, <IDir_b>PubKey_i,
<-- <Nr_b>PubKey_i
HDR*, HASH_I -->
<-- HDR*, HASH_R
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, [ HASH(1), ]
<IDii_b>PubKey_r,
<Ni_b>PubKey_r -->
HDR, KE, <IDir_b>PubKey_i,
<-- <Nr_b>PubKey_i
HDR*, HASH_I -->
<-- HDR*, HASH_R
Aggressive Mode authenticated with encryption is described as follows:
使用加密进行身份验证的主动模式描述如下：
Initiator Responder
----------- -----------
HDR, SA, [ HASH(1),] KE,
<IDii_b>Pubkey_r,
<Ni_b>Pubkey_r -->
HDR, SA, KE, <IDir_b>PubKey_i,
<-- <Nr_b>PubKey_i, HASH_R
HDR, HASH_I -->
Initiator Responder
----------- -----------
HDR, SA, [ HASH(1),] KE,
<IDii_b>Pubkey_r,
<Ni_b>Pubkey_r -->
HDR, SA, KE, <IDir_b>PubKey_i,
<-- <Nr_b>PubKey_i, HASH_R
HDR, HASH_I -->
Where HASH(1) is a hash (using the negotiated hash function) of the certificate which the initiator is using to encrypt the nonce and identity.
其中，散列（1）是证书的散列（使用协商的散列函数），发起方使用该散列来加密nonce和标识。
RSA encryption MUST be encoded in PKCS #1 format. While only the body of the ID and nonce payloads is encrypted, the encrypted data must be preceded by a valid ISAKMP generic header. The payload length is the length of the entire encrypted payload plus header. The PKCS #1 encoding allows for determination of the actual length of the cleartext payload upon decryption.
RSA加密必须以PKCS#1格式编码。虽然只有ID和nonce有效载荷的主体被加密，但加密的数据之前必须有一个有效的ISAKMP通用头。有效负载长度是整个加密有效负载加上报头的长度。PKCS#1编码允许在解密时确定明文有效负载的实际长度。
Using encryption for authentication provides for a plausably deniable exchange. There is no proof (as with a digital signature) that the conversation ever took place since each party can completely reconstruct both sides of the exchange. In addition, security is added to secret generation since an attacker would have to successfully break not only the Diffie-Hellman exchange but also both RSA encryptions. This exchange was motivated by [SKEME].
使用加密进行身份验证提供了一个可否认的交换。没有证据（如数字签名）证明对话曾经发生过，因为每一方都可以完全重建交换的双方。此外，由于攻击者不仅必须成功破解Diffie-Hellman交换，而且还必须成功破解RSA加密，因此机密生成中增加了安全性。这次交流是由[SKEME]推动的。
Note that, unlike other authentication methods, authentication with public key encryption allows for identity protection with Aggressive Mode.
请注意，与其他身份验证方法不同，使用公钥加密的身份验证允许使用攻击模式进行身份保护。
Authentication with Public Key Encryption has significant advantages over authentication with signatures (see section 5.2 above). Unfortunately, this is at the cost of 4 public key operations-- two public key encryptions and two private key decryptions. This authentication mode retains the advantages of authentication using public key encryption but does so with half the public key operations.
使用公钥加密的身份验证比使用签名的身份验证具有显著优势（见上文第5.2节）。不幸的是，这是以4个公钥操作为代价的——两个公钥加密和两个私钥解密。此身份验证模式保留了使用公钥加密进行身份验证的优点，但使用一半的公钥操作即可实现。
In this mode, the nonce is still encrypted using the public key of the peer, however the peer's identity (and the certificate if it is sent) is encrypted using the negotiated symmetric encryption algorithm (from the SA payload) with a key derived from the nonce. This solution adds minimal complexity and state yet saves two costly public key operations on each side. In addition, the Key Exchange payload is also encrypted using the same derived key. This provides additional protection against cryptanalysis of the Diffie-Hellman exchange.
在此模式下，nonce仍然使用对等方的公钥进行加密，但是对等方的身份（以及证书，如果已发送）使用协商对称加密算法（来自SA有效负载）以及从nonce派生的密钥进行加密。此解决方案增加了最小的复杂性和状态，但在每侧节省了两个代价高昂的公钥操作。此外，还使用相同的派生密钥对密钥交换有效负载进行加密。这为Diffie-Hellman交换的密码分析提供了额外的保护。
As with the public key encryption method of authentication (section 5.2), a HASH payload may be sent to identify a certificate if the responder has multiple certificates which contain useable public keys (e.g. if the certificate is not for signatures only, either due to certificate restrictions or algorithmic restrictions). If the HASH
与认证的公钥加密方法（第5.2节）一样，如果响应者有多个包含可用公钥的证书（例如，由于证书限制或算法限制，证书不仅用于签名），则可以发送哈希有效载荷以识别证书。如果散列
payload is sent it MUST be the first payload of the second message exchange and MUST be followed by the encrypted nonce. If the HASH payload is not sent, the first payload of the second message exchange MUST be the encrypted nonce. In addition, the initiator my optionally send a certificate payload to provide the responder with a public key with which to respond.
发送有效负载时，它必须是第二次消息交换的第一个有效负载，并且必须后跟加密的nonce。如果未发送哈希有效负载，则第二次消息交换的第一个有效负载必须是加密的nonce。此外，启动器my还可以选择发送证书有效负载，以向响应者提供用于响应的公钥。
When using the revised encryption mode for authentication, Main Mode is defined as follows.
使用修改后的加密模式进行身份验证时，主模式定义如下。
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, [ HASH(1), ]
<Ni_b>Pubkey_r,
<KE_b>Ke_i,
<IDii_b>Ke_i,
[<<Cert-I_b>Ke_i] -->
HDR, <Nr_b>PubKey_i,
<KE_b>Ke_r,
<-- <IDir_b>Ke_r,
HDR*, HASH_I -->
<-- HDR*, HASH_R
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, [ HASH(1), ]
<Ni_b>Pubkey_r,
<KE_b>Ke_i,
<IDii_b>Ke_i,
[<<Cert-I_b>Ke_i] -->
HDR, <Nr_b>PubKey_i,
<KE_b>Ke_r,
<-- <IDir_b>Ke_r,
HDR*, HASH_I -->
<-- HDR*, HASH_R
Aggressive Mode authenticated with the revised encryption method is described as follows:
使用修改后的加密方法验证的攻击模式描述如下：
Initiator Responder
----------- -----------
HDR, SA, [ HASH(1),]
<Ni_b>Pubkey_r,
<KE_b>Ke_i, <IDii_b>Ke_i
[, <Cert-I_b>Ke_i ] -->
HDR, SA, <Nr_b>PubKey_i,
<KE_b>Ke_r, <IDir_b>Ke_r,
<-- HASH_R
HDR, HASH_I -->
Initiator Responder
----------- -----------
HDR, SA, [ HASH(1),]
<Ni_b>Pubkey_r,
<KE_b>Ke_i, <IDii_b>Ke_i
[, <Cert-I_b>Ke_i ] -->
HDR, SA, <Nr_b>PubKey_i,
<KE_b>Ke_r, <IDir_b>Ke_r,
<-- HASH_R
HDR, HASH_I -->
where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to the symmetric encryption algorithm negotiated in the SA payload exchange. Only the body of the payloads are encrypted (in both public key and symmetric operations), the generic payload headers are left in the clear. The payload length includes that added to perform encryption.
其中散列（1）与第5.2节相同。Ke_i和Ke_r是SA有效负载交换中协商的对称加密算法的密钥。只有有效负载的主体被加密（在公钥和对称操作中），通用有效负载头被保留在空白处。有效负载长度包括为执行加密而添加的长度。
The symmetric cipher keys are derived from the decrypted nonces as follows. First the values Ne_i and Ne_r are computed:
对称密码密钥由解密后的nonce派生而来，如下所示。首先计算值Ne_i和Ne_r：
Ne_i = prf(Ni_b, CKY-I)
Ne_r = prf(Nr_b, CKY-R)
Ne_i = prf(Ni_b, CKY-I)
Ne_r = prf(Nr_b, CKY-R)
The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively in the manner described in Appendix B used to derive symmetric keys for use with the negotiated encryption algorithm. If the length of the output of the negotiated prf is greater than or equal to the key length requirements of the cipher, Ke_i and Ke_r are derived from the most significant bits of Ne_i and Ne_r respectively. If the desired length of Ke_i and Ke_r exceed the length of the output of the prf the necessary number of bits is obtained by repeatedly feeding the results of the prf back into itself and concatenating the result until the necessary number has been achieved. For example, if the negotiated encryption algorithm requires 320 bits of key and the output of the prf is only 128 bits, Ke_i is the most significant 320 bits of K, where
密钥Ke_i和Ke_r然后分别以附录B中所述的方式从Ne_i和Ne_r中获取，用于导出对称密钥以用于协商加密算法。如果协商prf的输出长度大于或等于密码的密钥长度要求，则Ke_i和Ke_r分别从Ne_i和Ne_r的最高有效位导出。如果keu i和keu r的期望长度超过了prf输出的长度，则通过重复地将prf的结果反馈回其自身并连接结果直到达到所需的位数来获得所需的位数。例如，如果协商加密算法需要320位密钥，并且prf的输出仅为128位，则Ke_i是K的最高有效320位，其中
K = K1 | K2 | K3 and
K1 = prf(Ne_i, 0)
K2 = prf(Ne_i, K1)
K3 = prf(Ne_i, K2)
K = K1 | K2 | K3 and
K1 = prf(Ne_i, 0)
K2 = prf(Ne_i, K1)
K3 = prf(Ne_i, K2)
For brevity, only derivation of Ke_i is shown; Ke_r is identical. The length of the value 0 in the computation of K1 is a single octet. Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be discarded after use.
为简洁起见，仅显示了Ke_i的推导；柯尔是一样的。计算K1时，值0的长度是一个八位组。请注意，Ne_i、Ne_r、Ke_i和Ke_r都是短暂的，使用后必须丢弃。
Save the requirements on the location of the optional HASH payload and the mandatory nonce payload there are no further payload requirements. All payloads-- in whatever order-- following the encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the direction.
保存关于可选哈希有效负载和强制nonce有效负载位置的要求—没有进一步的有效负载要求。所有有效载荷——无论以何种顺序——在加密的nonce之后必须根据方向使用keu i或keu r进行加密。
If CBC mode is used for the symmetric encryption then the initialization vectors (IVs) are set as follows. The IV for encrypting the first payload following the nonce is set to 0 (zero). The IV for subsequent payloads encrypted with the ephemeral symmetric cipher key, Ke_i, is the last ciphertext block of the previous payload. Encrypted payloads are padded up to the nearest block size. All padding bytes, except for the last one, contain 0x00. The last byte of the padding contains the number of the padding bytes used, excluding the last one. Note that this means there will always be padding.
如果对称加密使用CBC模式，则初始化向量（IVs）设置如下。用于加密nonce之后的第一个有效负载的IV设置为0（零）。使用临时对称密码密钥keu i加密的后续有效载荷的IV是前一有效载荷的最后一个密文块。加密的有效载荷被填充到最接近的块大小。除最后一个外，所有填充字节都包含0x00。填充的最后一个字节包含使用的填充字节数，不包括最后一个字节。请注意，这意味着将始终存在填充。
A key derived by some out-of-band mechanism may also be used to authenticate the exchange. The actual establishment of this key is out of the scope of this document.
由某些带外机制派生的密钥也可用于验证交换。此密钥的实际建立超出了本文档的范围。
When doing a pre-shared key authentication, Main Mode is defined as follows:
进行预共享密钥身份验证时，主模式定义如下：
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
Aggressive mode with a pre-shared key is described as follows:
具有预共享密钥的主动模式描述如下：
Initiator Responder
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
HDR, HASH_I -->
Initiator Responder
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
HDR, HASH_I -->
When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir. Aggressive Mode allows for a wider range of identifiers of the pre-shared secret to be used. In addition, Aggressive Mode allows two parties to maintain multiple, different pre-shared keys and identify the correct one for a particular exchange.
在主模式下使用预共享密钥身份验证时，密钥只能由对等方的IP地址标识，因为必须在启动器处理IDir之前计算哈希_I。主动模式允许使用更大范围的预共享机密标识符。此外，主动模式允许双方维护多个不同的预共享密钥，并为特定交换识别正确的密钥。
Quick Mode is not a complete exchange itself (in that it is bound to a phase 1 exchange), but is used as part of the SA negotiation process (phase 2) to derive keying material and negotiate shared policy for non-ISAKMP SAs. The information exchanged along with Quick Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST immediately follow the ISAKMP header and a SA payload MUST immediately follow the HASH. This HASH authenticates the message and also provides liveliness proofs.
快速模式本身不是一个完整的交换（因为它绑定到第1阶段交换），而是SA协商过程（第2阶段）的一部分，用于为非ISAKMP SA导出密钥材料并协商共享策略。与快速模式一起交换的信息必须受到ISAKMP SA的保护——即，除ISAKMP头之外的所有有效负载都是加密的。在快速模式下，哈希有效负载必须紧跟在ISAKMP头之后，SA有效负载必须紧跟在哈希之后。该散列对消息进行身份验证，并提供生动性证明。
The message ID in the ISAKMP header identifies a Quick Mode in progress for a particular ISAKMP SA which itself is identified by the cookies in the ISAKMP header. Since each instance of a Quick Mode uses a unique initialization vector (see Appendix B) it is possible to have multiple simultaneous Quick Modes, based off a single ISAKMP SA, in progress at any one time.
ISAKMP标头中的消息ID标识特定ISAKMP SA的正在进行的快速模式，该SA本身由ISAKMP标头中的Cookie标识。由于快速模式的每个实例都使用一个唯一的初始化向量（见附录B），因此基于单个ISAKMP SA，在任何时候都可能有多个同时进行的快速模式。
Quick Mode is essentially a SA negotiation and an exchange of nonces that provides replay protection. The nonces are used to generate fresh key material and prevent replay attacks from generating bogus security associations. An optional Key Exchange payload can be exchanged to allow for an additional Diffie-Hellman exchange and exponentiation per Quick Mode. While use of the key exchange payload with Quick Mode is optional it MUST be supported.
快速模式本质上是SA协商和提供重播保护的nonce交换。nonce用于生成新的密钥材料，并防止重播攻击生成虚假的安全关联。可以交换可选的密钥交换有效负载，以允许额外的Diffie-Hellman交换和每个快速模式的求幂。虽然在快速模式下使用密钥交换有效负载是可选的，但必须支持它。
Base Quick Mode (without the KE payload) refreshes the keying material derived from the exponentiation in phase 1. This does not provide PFS. Using the optional KE payload, an additional exponentiation is performed and PFS is provided for the keying material.
基本快速模式（无KE有效负载）刷新从阶段1中的求幂得到的关键帧材质。这不提供PFS。使用可选的KE有效载荷，执行额外的求幂运算，并为键控材料提供PFS。
The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. If ISAKMP is acting as a client negotiator on behalf of another party, the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptable for the identities specified. If the client identities are not acceptable to the Quick Mode responder (due to policy or other reasons), a Notify payload with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.
除非在快速模式中指定了客户端标识符，否则在快速模式中协商的SA的标识隐式假定为ISAKMP对等方的IP地址，不允许对协议或端口号有任何隐式限制。如果ISAKMP代表另一方担任客户谈判代表，则双方的身份必须先作为IDci传递，然后作为IDcr传递。当地政策将规定是否可接受指定身份的提案。如果快速模式响应程序不接受客户端标识（由于策略或其他原因），则应发送通知消息类型为INVALID-ID-INFORMATION（18）的Notify有效负载。
The client identities are used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers and also to allow for unique and shared SAs with different granularities.
在两个对等方之间存在多个隧道的情况下，客户机标识用于识别通信量并将其定向到适当的隧道，还用于允许具有不同粒度的唯一和共享SA。
All offers made during a Quick Mode are logically related and must be consistant. For example, if a KE payload is sent, the attribute describing the Diffie-Hellman group (see section 6.1 and [Pip97]) MUST be included in every transform of every proposal of every SA being negotiated. Similarly, if client identities are used, they MUST apply to every SA in the negotiation.
快速模式下的所有报价在逻辑上是相关的，并且必须一致。例如，如果发送了KE有效载荷，则描述Diffie-Hellman组的属性（参见第6.1节和[Pip97]）必须包含在正在协商的每个SA的每个提案的每个转换中。类似地，如果使用客户机标识，则它们必须应用于协商中的每个SA。
Quick Mode is defined as follows:
快速模式定义如下：
Initiator Responder
----------- -----------
HDR*, HASH(1), SA, Ni
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->
Initiator Responder
----------- -----------
HDR*, HASH(1), SA, Ni
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->
Where: HASH(1) is the prf over the message id (M-ID) from the ISAKMP header concatenated with the entire message that follows the hash including all payload headers, but excluding any padding added for encryption. HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni, minus the payload header-- is added after M-ID but before the complete message. The addition of the nonce to HASH(2) is for a liveliness proof. HASH(3)-- for liveliness-- is the prf over the value zero represented as a single octet, followed by a concatenation of the message id and the two nonces-- the initiator's followed by the responder's-- minus the payload header. In other words, the hashes for the above exchange are:
其中：哈希（1）是来自ISAKMP头的消息id（M-id）上的prf，该消息id与哈希后面的整个消息连接，包括所有有效负载头，但不包括为加密添加的任何填充。散列（2）与散列（1）相同，只是启动器的nonce（Ni，减去有效负载头）添加在M-ID之后但在完整消息之前。将nonce添加到散列（2）中是为了生动性证明。HASH（3）——对于livelity——是表示为单个八位字节的值0上的prf，后跟消息id和两个nonce的串联（发起方后跟响应方）减去有效负载头。换句话说，上述交换的哈希为：
HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
With the exception of the HASH, SA, and the optional ID payloads, there are no payload ordering restrictions on Quick Mode. HASH(1) and HASH(2) may differ from the illustration above if the order of payloads in the message differs from the illustrative example or if any optional payloads, for example a notify payload, have been chained to the message.
除了散列、SA和可选ID有效负载之外，快速模式上没有有效负载排序限制。如果消息中有效载荷的顺序不同于说明性示例，或者如果任何可选有效载荷（例如通知有效载荷）已链接到消息，则散列（1）和散列（2）可能不同于上图。
If PFS is not needed, and KE payloads are not exchanged, the new keying material is defined as
如果不需要PFS，并且不交换KE有效载荷，则新的键控材料定义为
KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).
KEYMAT=prf（SKEYID|d，协议| SPI | Ni|U b | Nr|b）。
If PFS is desired and KE payloads were exchanged, the new keying material is defined as
如果需要PFS，并且交换了KE有效载荷，则新的键控材料定义为
KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)
KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)
where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman exchange of this Quick Mode.
其中g（qm）^xy是该快速模式的短暂Diffie-Hellman交换的共享秘密。
In either case, "protocol" and "SPI" are from the ISAKMP Proposal Payload that contained the negotiated Transform.
在任何一种情况下，“协议”和“SPI”都来自包含协商转换的ISAKMP建议有效载荷。
A single SA negotiation results in two security assocations-- one inbound and one outbound. Different SPIs for each SA (one chosen by the initiator, the other by the responder) guarantee a different key for each direction. The SPI chosen by the destination of the SA is used to derive KEYMAT for that SA.
单个SA协商会导致两个安全关联——一个入站和一个出站。每个SA的不同SPI（一个由发起方选择，另一个由响应方选择）保证每个方向的密钥不同。SA目的地选择的SPI用于导出该SA的KEYMAT。
For situations where the amount of keying material desired is greater than that supplied by the prf, KEYMAT is expanded by feeding the results of the prf back into itself and concatenating results until the required keying material has been reached. In other words,
对于所需的键控材料量大于prf提供的材料量的情况，可以通过将prf的结果反馈回自身并连接结果来扩展KEYMAT，直到达到所需的键控材料。换句话说,，
KEYMAT = K1 | K2 | K3 | ... where K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) etc.
KEYMAT=K1 | K2 | K3 |。。。其中K1=prf（SKEYID | d，[g（qm）^xy |]协议| SPI | Ni | b | Nr | b）K2=prf（SKEYID | d，K1 |[g（qm）^xy |]协议| SPI Ni | u b | b）K3=prf（SKEYID | d，K2 |[g（qm）^xy |]协议| Ni | b）b）Nr。
This keying material (whether with PFS or without, and whether derived directly or through concatenation) MUST be used with the negotiated SA. It is up to the service to define how keys are derived from the keying material.
该键控材料（无论是否带有PFS，以及是否直接派生或通过连接）必须与协商SA一起使用。由服务定义如何从关键点材质派生关键点。
In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, the exponential (g(qm)^xy) is irretreivably removed from the current state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) continue to protect and authenticate the ISAKMP SA and SKEYID_d continues to be used to derive keys.
在快速模式下的短暂Diffie-Hellman交换的情况下，指数（g（qm）^xy）从当前状态中不可恢复地移除，SKEYID_e和SKEYID_a（源自第1阶段协商）继续保护和验证ISAKMP SA，SKEYID_d继续用于派生密钥。
Using Quick Mode, multiple SA's and keys can be negotiated with one exchange as follows:
使用快速模式，可以通过一次交换协商多个SA和密钥，如下所示：
Initiator Responder
----------- -----------
HDR*, HASH(1), SA0, SA1, Ni,
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA0, SA1, Nr,
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->
Initiator Responder
----------- -----------
HDR*, HASH(1), SA0, SA1, Ni,
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA0, SA1, Nr,
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->
The keying material is derived identically as in the case of a single SA. In this case (negotiation of two SA payloads) the result would be four security associations-- two each way for both SAs.
键控材质的推导方式与单个SA的推导方式相同。在本例中（两个SA有效负载的协商），结果将是四个安全关联——两个SA各有两个。
New Group Mode MUST NOT be used prior to establishment of an ISAKMP SA. The description of a new group MUST only follow phase 1 negotiation. (It is not a phase 2 exchange, though).
在建立ISAKMP SA之前，不得使用新的组模式。新组的描述只能在第1阶段协商之后进行。（但这不是第二阶段交换）。
Initiator Responder
----------- -----------
HDR*, HASH(1), SA -->
<-- HDR*, HASH(2), SA
Initiator Responder
----------- -----------
HDR*, HASH(1), SA -->
<-- HDR*, HASH(2), SA
where HASH(1) is the prf output, using SKEYID_a as the key, and the message-ID from the ISAKMP header concatenated with the entire SA proposal, body and header, as the data; HASH(2) is the prf output, using SKEYID_a as the key, and the message-ID from the ISAKMP header concatenated with the reply as the data. In other words the hashes for the above exchange are:
其中，散列（1）是prf输出，使用SKEYID_a作为密钥，来自ISAKMP报头的消息ID与整个SA提案、正文和报头连接作为数据；散列（2）是prf输出，使用SKEYID_a作为键，来自ISAKMP头的消息ID与应答连接作为数据。换句话说，上述交换的哈希为：
HASH(1) = prf(SKEYID_a, M-ID | SA)
HASH(2) = prf(SKEYID_a, M-ID | SA)
HASH(1) = prf(SKEYID_a, M-ID | SA)
HASH(2) = prf(SKEYID_a, M-ID | SA)
The proposal will specify the characteristics of the group (see appendix A, "Attribute Assigned Numbers"). Group descriptions for private Groups MUST be greater than or equal to 2^15. If the group is not acceptable, the responder MUST reply with a Notify payload with the message type set to ATTRIBUTES-NOT-SUPPORTED (13).
提案将详细说明集团的特征（见附录A“属性分配编号”）。专用组的组说明必须大于或等于2^15。如果组不可接受，则响应者必须使用消息类型设置为ATTRIBUTES-not-SUPPORTED（13）的Notify有效负载进行回复。
ISAKMP implementations MAY require private groups to expire with the SA under which they were established.
ISAKMP实现可能要求私有组与建立它们的SA一起过期。
Groups may be directly negotiated in the SA proposal with Main Mode. To do this the component parts-- for a MODP group, the type, prime and generator; for a EC2N group the type, the Irreducible Polynomial, Group Generator One, Group Generator Two, Group Curve A, Group Curve B and Group Order-- are passed as SA attributes (see Appendix A). Alternately, the nature of the group can be hidden using New Group Mode and only the group identifier is passed in the clear during phase 1 negotiation.
可通过主模式在SA提案中直接协商组。要做到这一点，组件部分——对于MODP组，类型、素数和生成器；对于EC2N群，类型、不可约多项式、群生成器1、群生成器2、群曲线a、群曲线B和群顺序作为SA属性传递（见附录a）。或者，可以使用新的组模式隐藏组的性质，并且在第1阶段协商期间，仅以清除方式传递组标识符。
This protocol protects ISAKMP Informational Exchanges when possible. Once the ISAKMP security association has been established (and SKEYID_e and SKEYID_a have been generated) ISAKMP Information Exchanges, when used with this protocol, are as follows:
此协议尽可能保护ISAKMP信息交换。一旦建立了ISAKMP安全关联（并生成了SKEYID_e和SKEYID_a），当与本协议一起使用时，ISAKMP信息交换如下：
Initiator Responder
----------- -----------
HDR*, HASH(1), N/D -->
Initiator Responder
----------- -----------
HDR*, HASH(1), N/D -->
where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete Payload and HASH(1) is the prf output, using SKEYID_a as the key, and a M-ID unique to this exchange concatenated with the entire informational payload (either a Notify or Delete) as the data. In other words, the hash for the above exchange is:
其中，N/D是ISAKMP Notify有效载荷或ISAKMP Delete有效载荷，哈希（1）是prf输出，使用SKEYIDèa作为密钥，以及与整个信息有效载荷（Notify或Delete）相连的该交换唯一的M-ID作为数据。换句话说，上述交换的哈希为：
HASH(1) = prf(SKEYID_a, M-ID | N/D)
HASH(1) = prf(SKEYID_a, M-ID | N/D)
As noted the message ID in the ISAKMP header-- and used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another phase 2 exchange which generated this informational exchange. The derivation of the initialization vector, used with SKEYID_e to encrypt this message, is described in Appendix B.
如前所述，ISAKMP头中的消息ID（用于prf计算）对此交换是唯一的，并且不得与生成此信息交换的另一阶段2交换的消息ID相同。附录B中描述了与SKEYID_e一起用于加密该消息的初始化向量的推导过程。
If the ISAKMP security association has not yet been established at the time of the Informational Exchange, the exchange is done in the clear without an accompanying HASH payload.
如果在信息交换时尚未建立ISAKMP安全关联，则交换将在清除中完成，而不附带哈希负载。
6 Oakley Groups
6奥克利集团
With IKE, the group in which to do the Diffie-Hellman exchange is negotiated. Four groups-- values 1 through 4-- are defined below. These groups originated with the Oakley protocol and are therefore called "Oakley Groups". The attribute class for "Group" is defined in Appendix A. All values 2^15 and higher are used for private group identifiers. For a discussion on the strength of the default Oakley groups please see the Security Considerations section below.
与IKE协商进行Diffie-Hellman交换的小组。下面定义了四个组（值1到4）。这些团体起源于奥克利协议，因此被称为“奥克利团体”。附录A中定义了“组”的属性类。所有值2^15及更高均用于专用组标识符。有关默认Oakley组的强度的讨论，请参阅下面的安全注意事项部分。
These groups were all generated by Richard Schroeppel at the University of Arizona. Properties of these groups are described in [Orm96].
这些小组都是由亚利桑那大学的Richard Schroeppel发明的。[Orm96]中描述了这些基团的性质。
Oakley implementations MUST support a MODP group with the following prime and generator. This group is assigned id 1 (one).
Oakley实现必须支持具有以下prime和generator的MODP组。此组被分配id 1（一个）。
The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
Its hexadecimal value is
The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
Its hexadecimal value is
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
FFFFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E6 F44C42E9 A63A3620 FFFFFFFFFF FFFFFF
The generator is: 2.
发电机是：2。
IKE implementations SHOULD support a MODP group with the following prime and generator. This group is assigned id 2 (two).
IKE实现应该支持具有以下prime和generator的MODP组。此组被分配id 2（两个）。
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its hexadecimal value is
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its hexadecimal value is
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF
FFFFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E6 F44C42E9 A637ED6B 0BFF5CB6 F406B7 EE386B5A899FA5 AE9F2411 7C4B16 49286651 FFFFFFFFFFFFFFFFFF
The generator is 2 (decimal)
发电机为2（十进制）
IKE implementations SHOULD support a EC2N group with the following characteristics. This group is assigned id 3 (three). The curve is based on the Galois Field GF[2^155]. The field size is 155. The irreducible polynomial for the field is: u^155 + u^62 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b.
IKE实现应该支持具有以下特征的EC2N组。此组被分配id 3（三）。该曲线基于伽罗瓦场GF[2^155]。字段大小为155。场的不可约多项式为：u^155+u^62+1。椭圆曲线的方程是：y^2+xy=x^3+ax^2+b。
Field Size: 155 Group Prime/Irreducible Polynomial: 0x0800000000000000000000004000000000000001 Group Generator One: 0x7b Group Curve A: 0x0 Group Curve B: 0x07338f
字段大小：155组素数/不可约多项式：0x080000000000000004000000000000001组生成器一：0x7b组曲线A:0x0组曲线B:0x07338f
Group Order: 0X0800000000000000000057db5698537193aef944
Group Order: 0X0800000000000000000057db5698537193aef944
The data in the KE payload when using this group is the value x from the solution (x,y), the point on the curve chosen by taking the randomly chosen secret Ka and computing Ka*P, where * is the repetition of the group addition and double operations, P is the curve point with x coordinate equal to generator 1 and the y
使用该组时，KE有效载荷中的数据是来自解（x，y）的值x，通过随机选择的秘密Ka和计算Ka*P选择的曲线上的点，其中*是组加法和双运算的重复，P是x坐标等于生成器1和y的曲线点
coordinate determined from the defining equation. The equation of curve is implicitly known by the Group Type and the A and B coefficients. There are two possible values for the y coordinate; either one can be used successfully (the two parties need not agree on the selection).
根据定义方程确定的坐标。曲线方程由群类型和A、B系数隐式表示。y坐标有两个可能的值；任何一个都可以成功使用（双方无需就选择达成一致）。
IKE implementations SHOULD support a EC2N group with the following characteristics. This group is assigned id 4 (four). The curve is based on the Galois Field GF[2^185]. The field size is 185. The irreducible polynomial for the field is: u^185 + u^69 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b.
IKE实现应该支持具有以下特征的EC2N组。此组被分配id 4（四）。该曲线基于伽罗瓦场GF[2^185]。字段大小为185。场的不可约多项式为：u^185+u^69+1。椭圆曲线的方程是：y^2+xy=x^3+ax^2+b。
Field Size: 185 Group Prime/Irreducible Polynomial: 0x020000000000000000000000000000200000000000000001 Group Generator One: 0x18 Group Curve A: 0x0 Group Curve B: 0x1ee9
字段大小：185组素数/不可约多项式：0x0200000000000000000000000000000002000000000001组生成器一：0x18组曲线A:0x0组曲线B:0x1ee9
Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc
Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc
The data in the KE payload when using this group will be identical to that as when using Oakley Group 3 (three).
使用该组时，KE有效载荷中的数据将与使用Oakley组3（三）时的数据相同。
Other groups can be defined using New Group Mode. These default groups were generated by Richard Schroeppel at the University of Arizona. Properties of these primes are described in [Orm96].
可以使用新组模式定义其他组。这些默认组是由亚利桑那大学的Richard Schroeppel发明的。[Orm96]中描述了这些素数的性质。
This section illustrates how the IKE protocol is used to:
本节说明如何使用IKE协议：
- establish a secure and authenticated channel between ISAKMP processes (phase 1); and
- 在ISAKMP进程之间建立安全且经过认证的通道（第1阶段）；和
- generate key material for, and negotiate, an IPsec SA (phase 2).
- 为IPsec SA生成关键材料并进行协商（第2阶段）。
The following diagram illustrates the payloads exchanged between the two parties in the first round trip exchange. The initiator MAY propose several proposals; the responder MUST reply with one.
下图说明了双方在第一次往返交换中交换的有效载荷。发起人可以提出若干建议；回复者必须用一个回复。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_SA ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ prefered SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ alternate SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_SA ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ prefered SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ alternate SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The responder replies in kind but selects, and returns, one transform proposal (the ISAKMP SA attributes).
响应者以实物形式回复，但选择并返回一个转换建议（ISAKMP SA属性）。
The second exchange consists of the following payloads:
第二次交换由以下有效载荷组成：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_KE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ D-H Public Value (g^xi from initiator g^xr from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ni (from initiator) or Nr (from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_KE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ D-H Public Value (g^xi from initiator g^xr from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ni (from initiator) or Nr (from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The shared keys, SKEYID_e and SKEYID_a, are now used to protect and authenticate all further communication. Note that both SKEYID_e and SKEYID_a are unauthenticated.
共享密钥SKEYID_e和SKEYID_a现在用于保护和验证所有进一步的通信。请注意，SKEYID_e和SKEYID_a均未经身份验证。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_ID and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SIG ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data of the ISAKMP negotiator ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ signature verified by the public key of the ID above ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_ID and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SIG ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data of the ISAKMP negotiator ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ signature verified by the public key of the ID above ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The key exchange is authenticated over a signed hash as described in section 5.1. Once the signature has been verified using the authentication algorithm negotiated as part of the ISAKMP SA, the shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. (For brevity, certificate payloads were not exchanged).
密钥交换通过第5.1节所述的签名哈希进行身份验证。使用作为ISAKMP SA一部分协商的身份验证算法验证签名后，共享密钥SKEYID_e和SKEYID_a可以标记为已验证。（为简洁起见，未交换证书有效载荷）。
The following payloads are exchanged in the first round of Quick Mode with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP negotiators are proxies for other parties which have requested authentication.
以下有效载荷在第一轮快速模式下与ISAKMP SA协商进行交换。在此假设交换中，ISAKMP谈判者是请求认证的其他方的代理。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SA ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ keyed hash of message ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain Of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SA ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ keyed hash of message ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain Of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! AH_SHA | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! AH_MD5 | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of source for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of destination for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! AH_SHA | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! AH_MD5 | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of source for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of destination for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the contents of the hash are described in 5.5 above. The responder replies with a similar message which only contains one transform-- the selected AH transform. Upon receipt, the initiator can provide the key engine with the negotiated security association and the keying material. As a check against replay attacks, the responder waits until receipt of the next message.
其中散列的内容如上文5.5所述。响应者回复一条类似的消息，其中只包含一个转换——所选的AH转换。收到后，发起人可以向密钥引擎提供协商的安全关联和密钥材料。作为对重播攻击的检查，响应者等待直到收到下一条消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ hash data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ hash data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the contents of the hash are described in 5.5 above.
其中散列的内容如上文5.5所述。
This protocol can provide PFS of both keys and identities. The identies of both the ISAKMP negotiating peer and, if applicable, the identities for whom the peers are negotiating can be protected with PFS.
该协议可以提供密钥和身份的PFS。可以使用PFS保护ISAKMP协商对等方的身份以及（如果适用）对等方正在协商的身份。
To provide Perfect Forward Secrecy of both keys and all identities, two parties would perform the following:
为提供密钥和所有身份的完美前向保密，双方将执行以下操作：
o A Main Mode Exchange to protect the identities of the ISAKMP peers. This establishes an ISAKMP SA. o A Quick Mode Exchange to negotiate other security protocol protection. This establishes a SA on each end for this protocol. o Delete the ISAKMP SA and its associated state.
o 用于保护ISAKMP对等方身份的主模式交换。这将建立一个ISAKMP SA。o用于协商其他安全协议保护的快速模式交换。这将在该协议的每一端建立SA。o删除ISAKMP SA及其关联状态。
Since the key for use in the non-ISAKMP SA was derived from the single ephemeral Diffie-Hellman exchange PFS is preserved.
由于在非ISAKMP SA中使用的密钥是从单个瞬时Diffie-Hellman交换派生的，因此保留了PFS。
To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP security association, it in not necessary to do a phase 1 exchange if an ISAKMP SA exists between the two peers. A single Quick Mode in which the optional KE payload is passed, and an additional Diffie-Hellman exchange is performed, is all that is required. At this point the state derived from this Quick Mode must be deleted from the ISAKMP SA as described in section 5.5.
为了仅为非ISAKMP安全关联的密钥提供完美的前向保密性，如果两个对等方之间存在ISAKMP SA，则无需进行阶段1交换。只需要一个单一的快速模式，在该模式下，通过可选的KE有效载荷，并执行额外的Diffie-Hellman交换。此时，必须按照第5.5节所述，从ISAKMP SA中删除由此快速模式衍生的状态。
Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 negotiations extremely quick. As long as the Phase 1 state remains cached, and PFS is not needed, Phase 2 can proceed without any exponentiation. How many Phase 2 negotiations can be performed for a single Phase 1 is a local policy issue. The decision will depend on the strength of the algorithms being used and level of trust in the peer system.
使用单一的ISAKMP第一阶段谈判可以使后续的第二阶段谈判非常迅速。只要阶段1状态保持缓存状态，并且不需要PFS，阶段2就可以继续进行，而不需要任何求幂运算。一个阶段1可以执行多少阶段2谈判是当地政策问题。决策将取决于所使用算法的强度和对等系统中的信任级别。
An implementation may wish to negotiate a range of SAs when performing Quick Mode. By doing this they can speed up the "re-keying". Quick Mode defines how KEYMAT is defined for a range of SAs. When one peer feels it is time to change SAs they simply use the next one within the stated range. A range of SAs can be established by negotiating multiple SAs (identical attributes, different SPIs) with one Quick Mode.
在执行快速模式时，实现可能希望协商一系列SA。通过这样做，他们可以加快“重新键入”。快速模式定义如何为一系列SA定义KEYMAT。当一个同伴觉得是时候改变情景模拟时，他们只需在规定的范围内使用下一个情景模拟。通过使用一种快速模式协商多个SA（相同的属性、不同的SPI），可以建立一系列SA。
An optimization that is often useful is to establish Security Associations with peers before they are needed so that when they become needed they are already in place. This ensures there would be no delays due to key management before initial data transmission. This optimization is easily implemented by setting up more than one Security Association with a peer for each requested Security Association and caching those not immediately used.
通常有用的优化是在需要对等点之前与它们建立安全关联，以便在需要它们时它们已经就位。这确保在初始数据传输之前不会因密钥管理而出现延迟。通过为每个请求的安全关联设置多个对等安全关联并缓存未立即使用的安全关联，可以轻松实现此优化。
Also, if an ISAKMP implementation is alerted that a SA will soon be needed (e.g. to replace an existing SA that will expire in the near future), then it can establish the new SA before that new SA is needed.
此外，如果ISAKMP实施收到即将需要SA的警报（例如，替换将在不久的将来到期的现有SA），则它可以在需要新SA之前建立新SA。
The base ISAKMP specification describes conditions in which one party of the protocol may inform the other party of some activity-- either deletion of a security association or in response to some error in the protocol such as a signature verification failed or a payload failed to decrypt. It is strongly suggested that these Informational exchanges not be responded to under any circumstances. Such a condition may result in a "notify war" in which failure to understand a message results in a notify to the peer who cannot understand it and sends his own notify back which is also not understood.
基本ISAKMP规范描述了协议的一方可能通知另一方某些活动的情况——删除安全关联或响应协议中的某些错误，如签名验证失败或有效负载解密失败。强烈建议在任何情况下都不要回应这些信息交流。这种情况可能会导致“通知战”，在这种情况下，无法理解消息会导致向无法理解消息的对等方发送通知，并将其自己的通知发送回也无法理解的对等方。
This entire memo discusses a hybrid protocol, combining parts of Oakley and parts of SKEME with ISAKMP, to negotiate, and derive keying material for, security associations in a secure and authenticated manner.
整个备忘录讨论了一个混合协议，将Oakley的部分内容和SKEME的部分内容与ISAKMP结合起来，以安全和经过身份验证的方式协商安全关联，并为其派生密钥材料。
Confidentiality is assured by the use of a negotiated encryption algorithm. Authentication is assured by the use of a negotiated method: a digital signature algorithm; a public key algorithm which supports encryption; or, a pre-shared key. The confidentiality and authentication of this exchange is only as good as the attributes negotiated as part of the ISAKMP security association.
通过使用协商加密算法确保机密性。认证通过使用协商方法来保证：数字签名算法；支持加密的公钥算法；或者，预共享密钥。此交换的机密性和身份验证仅与作为ISAKMP安全关联一部分协商的属性相同。
Repeated re-keying using Quick Mode can consume the entropy of the Diffie-Hellman shared secret. Implementors should take note of this fact and set a limit on Quick Mode Exchanges between exponentiations. This memo does not prescribe such a limit.
使用快速模式重复重设密钥会消耗Diffie-Hellman共享秘密的熵。实现者应该注意这一事实，并对求幂之间的快速模式交换设置限制。本备忘录未规定此类限制。
Perfect Forward Secrecy (PFS) of both keying material and identities is possible with this protocol. By specifying a Diffie-Hellman group, and passing public values in KE payloads, ISAKMP peers can establish PFS of keys-- the identities would be protected by SKEYID_e from the ISAKMP SA and would therefore not be protected by PFS. If PFS of both keying material and identities is desired, an ISAKMP peer MUST
通过该协议，密钥材料和身份的完美前向保密（PFS）是可能的。通过指定Diffie-Hellman组，并在KE有效载荷中传递公共值，ISAKMP对等方可以建立密钥的PFS——身份将受到来自ISAKMP SA的SKEYID_e的保护，因此不受PFS的保护。如果需要密钥材料和身份的PFS，则必须有ISAKMP对等方
establish only one non-ISAKMP security association (e.g. IPsec Security Association) per ISAKMP SA. PFS for keys and identities is accomplished by deleting the ISAKMP SA (and optionally issuing a DELETE message) upon establishment of the single non-ISAKMP SA. In this way a phase one negotiation is uniquely tied to a single phase two negotiation, and the ISAKMP SA established during phase one negotiation is never used again.
每个ISAKMP SA仅建立一个非ISAKMP安全关联（例如IPsec安全关联）。密钥和身份的PFS通过在建立单个非ISAKMP SA时删除ISAKMP SA（并可选择发出删除消息）来完成。通过这种方式，第一阶段协商与单一第二阶段协商唯一关联，并且在第一阶段协商期间建立的ISAKMP SA不再使用。
The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator used. Due to these inputs it is difficult to determine the strength of a key for any of the defined groups. The default Diffie-Hellman group (number one) when used with a strong random number generator and an exponent no less than 160 bits is sufficient to use for DES. Groups two through four provide greater security. Implementations should make note of these conservative estimates when establishing policy and negotiating security parameters.
使用此处定义的任何组从Diffie-Hellman交换中导出的密钥的强度取决于组的固有强度、所用指数的大小以及所用随机数生成器提供的熵。由于这些输入，很难确定任何已定义组的键的强度。当与强随机数生成器和不小于160位的指数一起使用时，默认的Diffie-Hellman组（数字1）足以用于DES。第二组到第四组提供了更高的安全性。在建立策略和协商安全参数时，实现应该注意这些保守估计。
Note that these limitations are on the Diffie-Hellman groups themselves. There is nothing in IKE which prohibits using stronger groups nor is there anything which will dilute the strength obtained from stronger groups. In fact, the extensible framework of IKE encourages the definition of more groups; use of elliptical curve groups will greatly increase strength using much smaller numbers.
请注意，这些限制是针对Diffie-Hellman组本身的。IKE中没有任何内容禁止使用更强的群体，也没有任何内容会稀释从更强群体获得的力量。事实上，IKE的可扩展框架鼓励定义更多的组；使用椭圆曲线组将大大提高强度，使用更小的数字。
For situations where defined groups provide insufficient strength New Group Mode can be used to exchange a Diffie-Hellman group which provides the necessary strength. In is incumbent upon implementations to check the primality in groups being offered and independently arrive at strength estimates.
对于定义的组提供的强度不足的情况，可以使用新的组模式来交换提供必要强度的Diffie-Hellman组。在实施过程中，有义务检查所提供组的首要性，并独立得出强度估计。
It is assumed that the Diffie-Hellman exponents in this exchange are erased from memory after use. In particular, these exponents must not be derived from long-lived secrets like the seed to a pseudo-random generator.
假设此交换中的Diffie-Hellman指数在使用后从内存中删除。特别是，这些指数不能从长期存在的秘密中推导出来，比如伪随机发生器的种子。
IKE exchanges maintain running initialization vectors (IV) where the last ciphertext block of the last message is the IV for the next message. To prevent retransmissions (or forged messages with valid cookies) from causing exchanges to get out of sync IKE implementations SHOULD NOT update their running IV until the decrypted message has passed a basic sanity check and has been determined to actually advance the IKE state machine-- i.e. it is not a retransmission.
IKE交换保持运行初始化向量（IV），其中最后一条消息的最后一个密文块是下一条消息的IV。为了防止重传（或带有有效cookie的伪造消息）导致交换失去同步，在解密的消息通过基本的健全性检查并被确定为实际提升了IKE状态机（即，它不是重传）之前，IKE实现不应更新其正在运行的IV。
While the last roundtrip of Main Mode (and optionally the last message of Aggressive Mode) is encrypted it is not, strictly speaking, authenticated. An active substitution attack on the ciphertext could result in payload corruption. If such an attack corrupts mandatory payloads it would be detected by an authentication failure, but if it corrupts any optional payloads (e.g. notify payloads chained onto the last message of a Main Mode exchange) it might not be detectable.
虽然主模式的最后一次往返（以及可选的攻击模式的最后一条消息）是加密的，但严格来说，它不是经过身份验证的。对密文的主动替换攻击可能导致有效负载损坏。如果此类攻击破坏了强制有效载荷，则会通过身份验证失败来检测，但如果它破坏了任何可选有效载荷（例如，链接到主模式交换的最后一条消息上的notify payloads），则可能无法检测到。
This document contains many "magic numbers" to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists.
本文件包含许多由IANA维护的“神奇数字”。本节解释IANA在每个列表中分配额外编号时使用的标准。
Attributes negotiated in this protocol are identified by their class. Requests for assignment of new classes must be accompanied by a standards-track RFC which describes the use of this attribute.
此协议中协商的属性由其类标识。分配新类的请求必须附有标准跟踪RFC，该RFC描述了此属性的使用。
Values of the Encryption Algorithm Class define an encryption algorithm to use when called for in this document. Requests for assignment of new encryption algorithm values must be accompanied by a reference to a standards-track or Informational RFC or a reference to published cryptographic literature which describes this algorithm.
Encryption Algorithm类的值定义了在本文档中调用时要使用的加密算法。分配新加密算法值的请求必须附有对标准跟踪或信息RFC的参考，或对描述此算法的已发布加密文献的参考。
Values of the Hash Algorithm Class define a hash algorithm to use when called for in this document. Requests for assignment of new hash algorithm values must be accompanied by a reference to a standards-track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. Due to the key derivation and key expansion uses of HMAC forms of hash algorithms in IKE, requests for assignment of new hash algorithm values must take into account the cryptographic properties-- e.g it's resistance to collision-- of the hash algorithm itself.
Hash Algorithm类的值定义了在本文档中调用时要使用的哈希算法。分配新哈希算法值的请求必须附有对标准跟踪或信息RFC的引用，或对描述此算法的已发布加密文献的引用。由于在IKE中使用HMAC形式的散列算法的密钥派生和密钥扩展，分配新的散列算法值的请求必须考虑散列算法本身的加密特性，例如它的抗冲突性。
Values of the Group Description Class identify a group to use in a Diffie-Hellman exchange. Values of the Group Type Class define the type of group. Requests for assignment of new groups must be accompanied by a reference to a standards-track or Informational RFC which describes this group. Requests for assignment of new group
Group Description类的值标识要在Diffie-Hellman交换中使用的组。Group Type类的值定义组的类型。分配新组的请求必须附有对描述该组的标准跟踪或信息RFC的参考。分配新组的请求
types must be accompanied by a reference to a standards-track or Informational RFC or by a reference to published cryptographic or mathmatical literature which describes the new type.
类型必须附有对标准跟踪或信息RFC的引用，或对描述新类型的已发布加密或数学文献的引用。
Values of the Life Type Class define a type of lifetime to which the ISAKMP Security Association applies. Requests for assignment of new life types must be accompanied by a detailed description of the units of this type and its expiry.
Life Type类的值定义ISAKMP安全关联适用的生存期类型。分配新生命类型的申请必须附有该类型单位及其有效期的详细说明。
This document is the result of close consultation with Hugo Krawczyk, Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and Jeff Turner. It relies on protocols which were written by them. Without their interest and dedication, this would not have been written.
本文件是与雨果·克劳茨克、道格拉斯·莫汉、希拉里·奥曼、马克·舍特勒、马克·施耐德和杰夫·特纳密切磋商的结果。它依赖于他们编写的协议。如果没有他们的兴趣和献身精神，这本书就不会写成。
Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis, and Elfed Weaver for technical input, encouragement, and various sanity checks along the way.
特别感谢Rob Adams、Cheryl Madson、Derrell Piper、Harry Varnis和Elfed Weaver提供的技术支持、鼓励和一路上的各种精神检查。
We would also like to thank the many members of the IPSec working group that contributed to the development of this protocol over the past year.
我们还要感谢IPSec工作组的许多成员，他们在过去一年中为该协议的制定做出了贡献。
[CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[CAST]Adams，C.，“CAST-128加密算法”，RFC 2144，1997年5月。
[BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr. Dobb's Journal, v. 19, n. 4, April 1994.
[BLOW]Schneier，B.，“河豚加密算法”，Dobb博士期刊，v。19，n。1994年4月4日。
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[DES] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption", American National Standards Institute, 1983.
[DES]ANSI X3.106，“美国信息系统数据链路加密国家标准”，美国国家标准协会，1983年。
[DH] Diffie, W., and Hellman M., "New Directions in Cryptography", IEEE Transactions on Information Theory, V. IT-22, n. 6, June 1977.
[DH]Diffie，W.和Hellman M.，“密码学的新方向”，IEEE信息论交易，V.IT-22，n。1977年6月6日。
[DSS] NIST, "Digital Signature Standard", FIPS 186, National Institute of Standards and Technology, U.S. Department of Commerce, May, 1994.
[DSS]NIST，“数字签名标准”，FIPS 186，美国商务部国家标准与技术研究所，1994年5月。
[IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992
[IDEA]Lai，X.，“分组密码的设计和安全性”，信息处理中的ETH系列，v。康斯坦茨：哈东·高尔·韦拉格，1992年
[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[KBC96]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security.
[SKEME]Krawczyk，H.，“SKEME：一种通用的互联网安全密钥交换机制”，摘自1996年网络和分布式系统安全研讨会IEEE会议录。
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[MSST98]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998.
[Orm96]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard", November 1993.
[PKCS1]RSA实验室，“PKCS#1:RSA加密标准”，1993年11月。
[Pip98] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", RFC 2407, November 1998.
[Pip98]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's Journal, v. 20, n. 1, January 1995.
[RC5]Rivest，R.，“RC5加密算法”，多布博士期刊，v。20，n。1995年1月1日。
[RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, v. 21, n. 2, February 1978.
[RSA]Rivest，R.，Shamir，A.，和Adleman，L.，“获取数字签名和公钥密码系统的方法”，ACM通讯，v。21，n。1978年2月2日。
[Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, and Source Code in C", 2nd edition.
[Sch96]Schneier，B.，“C语言中的应用密码学、协议、算法和源代码”，第二版。
[SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institue of Standards and Technology, U.S. Department of Commerce, May 1994.
[SHA]NIST，“安全哈希标准”，FIPS 180-1，美国商务部国家标准与技术研究所，1994年5月。
[TIGER] Anderson, R., and Biham, E., "Fast Software Encryption", Springer LNCS v. 1039, 1996.
[TIGER]Anderson，R.和Biham，E.，“快速软件加密”，Springer LNCS v。1039, 1996.
This is a list of DES Weak and Semi-Weak keys. The keys come from [Sch96]. All keys are listed in hexidecimal.
这是DES弱键和半弱键的列表。钥匙来自[Sch96]。所有键都列在十六进制中。
DES Weak Keys 0101 0101 0101 0101 1F1F 1F1F E0E0 E0E0 E0E0 E0E0 1F1F 1F1F FEFE FEFE FEFE FEFE
DES弱键0101 0101 0101 1F1F 1F1F E0E0E0E0E0E0E0 1F1F FEFE FEFE FEFE
DES Semi-Weak Keys 01FE 01FE 01FE 01FE 1FE0 1FE0 0EF1 0EF1 01E0 01E0 01F1 01F1 1FFE 1FFE 0EFE 0EFE 011F 011F 010E 010E E0FE E0FE F1FE F1FE
DES半弱键01FE 01FE 01FE 01FE 1FE0 0EF1 0EF1 01E0 01E0 01F1 1FFE 1FFE 0EFE 011F 011F 010E 010E E0FE E0FE F1FE
FE01 FE01 FE01 FE01 E01F E01F F10E F10E E001 E001 F101 F101 FE1F FE1F FE0E FE0E 1F01 1F01 0E01 0E01 FEE0 FEE0 FEF1 FEF1
FE01 FE01 FE01 FE01 FE01 E01F E01F F10E F10E E001 E001 F101 FE1F FE1F FE0E FE0E 1F01 FE01 0E01 0E01 FEE0 FEF1 FEF1
Attribute Assigned Numbers
属性赋值
Attributes negotiated during phase one use the following definitions. Phase two attributes are defined in the applicable DOI specification (for example, IPsec attributes are defined in the IPsec DOI), with the exception of a group description when Quick Mode includes an ephemeral Diffie-Hellman exchange. Attribute types can be either Basic (B) or Variable-length (V). Encoding of these attributes is defined in the base ISAKMP specification as Type/Value (Basic) and Type/Length/Value (Variable).
在第一阶段协商的属性使用以下定义。第二阶段属性在适用的DOI规范中定义（例如，IPsec属性在IPsec DOI中定义），快速模式包括短暂的Diffie-Hellman交换时的组描述除外。属性类型可以是基本（B）或可变长度（V）。这些属性的编码在基本ISAKMP规范中定义为类型/值（基本）和类型/长度/值（变量）。
Attributes described as basic MUST NOT be encoded as variable. Variable length attributes MAY be encoded as basic attributes if their value can fit into two octets. If this is the case, an attribute offered as variable (or basic) by the initiator of this protocol MAY be returned to the initiator as a basic (or variable).
描述为基本的属性不能编码为变量。如果可变长度属性的值可以放入两个八位字节，则可以将其编码为基本属性。如果是这种情况，则此协议的发起方提供的作为变量（或基本）的属性可以作为基本（或变量）返回给发起方。
Attribute Classes
属性类
class value type
-------------------------------------------------------------------
Encryption Algorithm 1 B
Hash Algorithm 2 B
Authentication Method 3 B
Group Description 4 B
Group Type 5 B
Group Prime/Irreducible Polynomial 6 V
Group Generator One 7 V
Group Generator Two 8 V
Group Curve A 9 V
Group Curve B 10 V
Life Type 11 B
Life Duration 12 V
PRF 13 B
Key Length 14 B
Field Size 15 B
Group Order 16 V
class value type
-------------------------------------------------------------------
Encryption Algorithm 1 B
Hash Algorithm 2 B
Authentication Method 3 B
Group Description 4 B
Group Type 5 B
Group Prime/Irreducible Polynomial 6 V
Group Generator One 7 V
Group Generator Two 8 V
Group Curve A 9 V
Group Curve B 10 V
Life Type 11 B
Life Duration 12 V
PRF 13 B
Key Length 14 B
Field Size 15 B
Group Order 16 V
values 17-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties.
值17-16383保留给IANA。价值16384-32767供双方同意的私人使用。
Class Values
阶级价值观
- Encryption Algorithm Defined In DES-CBC 1 RFC 2405 IDEA-CBC 2 Blowfish-CBC 3 RC5-R16-B64-CBC 4 3DES-CBC 5 CAST-CBC 6
- DES-CBC 1 RFC 2405 IDEA-CBC 2河豚CBC 3 RC5-R16-B64-CBC 4 3DES-CBC 5 CAST-CBC 6中定义的加密算法
values 7-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties.
值7-65000保留给IANA。价值65001-65535供双方同意的私人使用。
- Hash Algorithm Defined In MD5 1 RFC 1321 SHA 2 FIPS 180-1 Tiger 3 See Reference [TIGER]
- MD5 1 RFC 1321 SHA 2 FIPS 180-1 Tiger 3中定义的哈希算法见参考文献[Tiger]
values 4-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties.
值4-65000保留给IANA。价值65001-65535供双方同意的私人使用。
- Authentication Method pre-shared key 1 DSS signatures 2 RSA signatures 3 Encryption with RSA 4 Revised encryption with RSA 5
- 身份验证方法预共享密钥1 DSS签名2 RSA签名3使用RSA加密4使用RSA修改加密5
values 6-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties.
值6-65000保留给IANA。价值65001-65535供双方同意的私人使用。
- Group Description default 768-bit MODP group (section 6.1) 1
- 组描述默认768位MODP组（第6.1节）1
alternate 1024-bit MODP group (section 6.2) 2
备用1024位MODP组（第6.2节）2
EC2N group on GP[2^155] (section 6.3) 3
GP[2^155]上的EC2N群（第6.3节）3
EC2N group on GP[2^185] (section 6.4) 4
GP[2^185]上的EC2N群（第6.4节）4
values 5-32767 are reserved to IANA. Values 32768-65535 are for private use among mutually consenting parties.
值5-32767保留给IANA。价值32768-65535供双方同意的私人使用。
- Group Type MODP (modular exponentiation group) 1 ECP (elliptic curve group over GF[P]) 2 EC2N (elliptic curve group over GF[2^N]) 3
- 群型MODP（模幂群）1ecp（GF[P]上的椭圆曲线群）2ec2n（GF[2^N]上的椭圆曲线群）3
values 4-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties.
值4-65000保留给IANA。价值65001-65535供双方同意的私人使用。
- Life Type seconds 1 kilobytes 2
- 生命类型秒1千字节2
values 3-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. For a given "Life Type" the value of the "Life Duration" attribute defines the actual length of the SA life-- either a number of seconds, or a number of kbytes protected.
值3-65000保留给IANA。价值65001-65535供双方同意的私人使用。对于给定的“寿命类型”，“寿命持续时间”属性的值定义SA寿命的实际长度——秒数或受保护的KB数。
- PRF There are currently no pseudo-random functions defined.
- PRF目前没有定义伪随机函数。
values 1-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties.
值1-65000保留给IANA。价值65001-65535供双方同意的私人使用。
- Key Length
- 键长
When using an Encryption Algorithm that has a variable length key, this attribute specifies the key length in bits. (MUST use network byte order). This attribute MUST NOT be used when the specified Encryption Algorithm uses a fixed length key.
使用具有可变长度密钥的加密算法时，此属性以位为单位指定密钥长度。（必须使用网络字节顺序）。当指定的加密算法使用固定长度密钥时，不得使用此属性。
- Field Size
- 字段大小
The field size, in bits, of a Diffie-Hellman group.
Diffie-Hellman组的字段大小（以位为单位）。
- Group Order
- 组顺序
The group order of an elliptical curve group. Note the length of this attribute depends on the field size.
椭圆曲线组的组顺序。请注意，此属性的长度取决于字段大小。
Additional Exchanges Defined-- XCHG values Quick Mode 32 New Group Mode 33
定义的附加交换--XCHG值快速模式32新组模式33
This appendix describes encryption details to be used ONLY when encrypting ISAKMP messages. When a service (such as an IPSEC transform) utilizes ISAKMP to generate keying material, all encryption algorithm specific details (such as key and IV generation, padding, etc...) MUST be defined by that service. ISAKMP does not purport to ever produce keys that are suitable for any encryption algorithm. ISAKMP produces the requested amount of keying material from which the service MUST generate a suitable key. Details, such as weak key checks, are the responsibility of the service.
本附录描述了仅在加密ISAKMP消息时使用的加密详细信息。当服务（如IPSEC转换）利用ISAKMP生成密钥材料时，所有加密算法特定的细节（如密钥和IV生成、填充等）必须由该服务定义。ISAKMP并不打算产生适用于任何加密算法的密钥。ISAKMP生成请求数量的密钥材料，服务必须从中生成合适的密钥。详细信息（如弱密钥检查）由服务负责。
Use of negotiated PRFs may require the PRF output to be expanded due to the PRF feedback mechanism employed by this document. For example, if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces only 8 bytes of output, the output must be expanded three times before being used as the key for another instance of itself. The output of a PRF is expanded by feeding back the results of the PRF into itself to generate successive blocks. These blocks are concatenated until the requisite number of bytes has been acheived. For example, for pre-shared key authentication with DOORAK-MAC as the negotiated PRF:
由于本文件采用PRF反馈机制，使用协商PRF可能需要扩大PRF输出。例如，如果（虚构的）DOORAK-MAC需要24字节的密钥，但只产生8字节的输出，则输出必须扩展三次，然后才能用作自身另一个实例的密钥。PRF的输出通过将PRF的结果反馈到自身以生成连续块来扩展。这些块被连接起来，直到达到所需的字节数。例如，对于使用DOORAK-MAC作为协商PRF的预共享密钥身份验证：
BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b)
BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b)
BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b)
and
SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b)
BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b)
BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b)
and
SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
so therefore to derive SKEYID_d:
因此，要推导SKEYID_d：
BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0)
BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0)
and
SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0)
BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0)
and
SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
Subsequent PRF derivations are done similarly.
后续的PRF推导也是类似的。
Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo-random function into itself, concatenating the results, and taking the highest necessary bits.
用于保护ISAKMP SA的加密密钥以特定于算法的方式从SKEYID_e派生。当SKEYID_e的长度不足以提供算法所需的所有必要的键控材料时，通过将伪随机函数的结果输入到其自身、连接结果并获取所需的最高位来导出密钥。
For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where:
例如，如果（虚构的）算法AKULA需要320位密钥（并且没有弱密钥检查），并且用于生成SKEYID_e的prf只生成120位材料，AKULA的密钥将是Ka的前320位，其中：
Ka = K1 | K2 | K3
and
K1 = prf(SKEYID_e, 0)
K2 = prf(SKEYID_e, K1)
K3 = prf(SKEYID_e, K2)
Ka = K1 | K2 | K3
and
K1 = prf(SKEYID_e, 0)
K2 = prf(SKEYID_e, K1)
K3 = prf(SKEYID_e, K2)
where prf is the negotiated prf or the HMAC version of the negotiated hash function (if no prf was negotiated) and 0 is represented by a single octet. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string.
其中，prf是协商的prf或协商的哈希函数的HMAC版本（如果没有协商prf），0由单个八位组表示。prf的每个结果提供120位材料，总计360位。AKULA将使用360位字符串的前320位。
In phase 1, material for the initialization vector (IV material) for CBC mode encryption algorithms is derived from a hash of a concatenation of the initiator's public Diffie-Hellman value and the responder's public Diffie-Hellman value using the negotiated hash algorithm. This is used for the first message only. Each message should be padded up to the nearest block size using bytes containing 0x00. The message length in the header MUST include the length of the pad since this reflects the size of the ciphertext. Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector.
在阶段1中，CBC模式加密算法的初始化向量（IV material）的材料来自使用协商哈希算法的发起方的公共Diffie-Hellman值和响应方的公共Diffie-Hellman值的串联的哈希。这仅用于第一条消息。应使用包含0x00的字节将每条消息填充到最接近的块大小。标头中的消息长度必须包括pad的长度，因为这反映了密文的大小。后续消息必须使用前一消息中的最后一个CBC加密块作为其初始化向量。
In phase 2, material for the initialization vector for CBC mode encryption of the first message of a Quick Mode exchange is derived from a hash of a concatenation of the last phase 1 CBC output block and the phase 2 message id using the negotiated hash algorithm. The IV for subsequent messages within a Quick Mode exchange is the CBC output block from the previous message. Padding and IVs for subsequent messages are done as in phase 1.
在阶段2中，用于快速模式交换的第一消息的CBC模式加密的初始化向量的材料使用协商的散列算法从最后阶段1 CBC输出块和阶段2消息id的串联的散列中导出。快速模式交换中后续消息的IV是前一消息的CBC输出块。后续消息的填充和IVs操作如第1阶段所示。
After the ISAKMP SA has been authenticated all Informational Exchanges are encrypted using SKEYID_e. The initiaization vector for these exchanges is derived in exactly the same fashion as that for a Quick Mode-- i.e. it is derived from a hash of a concatenation of the last phase 1 CBC output block and the message id from the ISAKMP header of the Informational Exchange (not the message id from the message that may have prompted the Informational Exchange).
ISAKMP SA经过身份验证后，所有信息交换都将使用SKEYID\e进行加密。这些交换的初始化向量的导出方式与快速模式的初始化向量的导出方式完全相同，即，它是从最后一个阶段1 CBC输出块的串联哈希和信息交换的ISAKMP头的消息id中导出的（不是提示信息交换的消息中的消息id）。
Note that the final phase 1 CBC output block, the result of encryption/decryption of the last phase 1 message, must be retained in the ISAKMP SA state to allow for generation of unique IVs for each Quick Mode. Each post- phase 1 exchange (Quick Modes and
请注意，最后一个阶段1 CBC输出块（最后一个阶段1消息的加密/解密结果）必须保留在ISAKMP SA状态，以便为每个快速模式生成唯一的IVs。每个后阶段1交换（快速模式和
Informational Exchanges) generates IVs independantly to prevent IVs from getting out of sync when two different exchanges are started simultaneously.
信息交换）独立生成IVs，以防止两个不同交换同时启动时IVs不同步。
In all cases, there is a single bidirectional cipher/IV context. Having each Quick Mode and Informational Exchange maintain a unique context prevents IVs from getting out of sync.
在所有情况下，都有一个双向密码/IV上下文。让每个快速模式和信息交换保持唯一的上下文，可以防止IVs失去同步。
The key for DES-CBC is derived from the first eight (8) non-weak and non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 8 bytes of the IV material derived above.
DES-CBC的密钥来自SKEYID_e的前八（8）个非弱和非半弱（见附录A）字节。IV是上面派生的IV材质的前8个字节。
The key for IDEA-CBC is derived from the first sixteen (16) bytes of SKEYID_e. The IV is the first eight (8) bytes of the IV material derived above.
IDEA-CBC的密钥来自SKEYID_e的前十六（16）个字节。IV是上面派生的IV材料的前八（8）个字节。
The key for Blowfish-CBC is either the negotiated key size, or the first fifty-six (56) bytes of a key (if no key size is negotiated) derived in the aforementioned pseudo-random function feedback method. The IV is the first eight (8) bytes of the IV material derived above.
Blowfish CBC的密钥是协商密钥大小，或者是在上述伪随机函数反馈方法中导出的密钥的前五十六（56）字节（如果没有协商密钥大小）。IV是上面派生的IV材料的前八（8）个字节。
The key for RC5-R16-B64-CBC is the negotiated key size, or the first sixteen (16) bytes of a key (if no key size is negotiated) derived from the aforementioned pseudo-random function feedback method if necessary. The IV is the first eight (8) bytes of the IV material derived above. The number of rounds MUST be 16 and the block size MUST be 64.
RC5-R16-B64-CBC的密钥是协商的密钥大小，或根据上述伪随机函数反馈方法导出的密钥的前十六（16）个字节（如果没有协商密钥大小）。IV是上面派生的IV材料的前八（8）个字节。轮数必须为16，块大小必须为64。
The key for 3DES-CBC is the first twenty-four (24) bytes of a key derived in the aforementioned pseudo-random function feedback method. 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV is the first eight (8) bytes of the IV material derived above.
3DES-CBC的密钥是上述伪随机函数反馈方法中导出的密钥的前二十四（24）个字节。3DES-CBC是一种使用整个3DES-CBC密钥的第一个、中间和最后八（8）个字节的加密-解密操作。IV是上面派生的IV材料的前八（8）个字节。
The key for CAST-CBC is either the negotiated key size, or the first sixteen (16) bytes of a key derived in the aforementioned pseudo-random function feedback method. The IV is the first eight (8) bytes of the IV material derived above.
CAST-CBC的密钥或者是协商密钥大小，或者是在前述伪随机函数反馈方法中导出的密钥的前十六（16）个字节。IV是上面派生的IV材料的前八（8）个字节。
Support for algorithms other than DES-CBC is purely optional. Some optional algorithms may be subject to intellectual property claims.
对DES-CBC以外的算法的支持完全是可选的。一些可选算法可能受到知识产权要求的约束。
Authors' Addresses
作者地址
Dan Harkins cisco Systems 170 W. Tasman Dr. San Jose, California, 95134-1706 United States of America
Dan Harkins cisco Systems 170 W.Tasman博士，加利福尼亚州圣何塞，美国95134-1706
Phone: +1 408 526 4000
EMail: dharkins@cisco.com
Phone: +1 408 526 4000
EMail: dharkins@cisco.com
Dave Carrel 76 Lippard Ave. San Francisco, CA 94131-2947 United States of America
Dave Carrel 76 Lippard Ave.旧金山，CA 94131-947美利坚合众国
Phone: +1 415 337 8469
EMail: carrel@ipsec.org
Phone: +1 415 337 8469
EMail: carrel@ipsec.org
Authors' Note
作者说明
The authors encourage independent implementation, and interoperability testing, of this hybrid protocol.
作者鼓励这种混合协议的独立实现和互操作性测试。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。