Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 6467 AuthenTec
Category: Informational December 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 6467 AuthenTec
Category: Informational December 2011
ISSN: 2070-1721
Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)
Internet密钥交换版本2（IKEv2）的安全密码框架
Abstract
摘要
This document defines a generic way for Internet Key Exchange version 2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods.
本文档定义了Internet密钥交换版本2（IKEv2）使用任何对称安全密码身份验证方法的通用方法。其他文档中已经指定了多个方法，此文档不会添加任何新方法。本文件规定了在当前连接中使用哪种方法的方法。本文档还提供了在对等方之间传输特定于安全密码身份验证方法的有效负载的通用方法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6467.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6467.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Method Negotiation ..............................................4
3. Generic Secure Password Method Payload ..........................6
4. IKE_AUTH Exchange ...............................................7
5. Security Considerations .........................................9
6. IANA Considerations .............................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
1. Introduction ....................................................2
2. Method Negotiation ..............................................4
3. Generic Secure Password Method Payload ..........................6
4. IKE_AUTH Exchange ...............................................7
5. Security Considerations .........................................9
6. IANA Considerations .............................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
The IPsecME working group was chartered to provide for IKEv2 ([RFC5996]) a symmetric secure password authentication protocol that supports the use of low-entropy shared secrets, and to protect against off-line dictionary attacks without requiring the use of certificates or the Extensible Authentication Protocol (EAP). There are multiple such methods, and the working group was to pick one. Unfortunately, the working group failed to pick one protocol, and there are multiple candidates going forward as separate documents. As each of those older versions of those documents used a different technique to negotiate the use of the method and also used different payload formats, it is very hard to try to make an implementation where multiple such systems could co-exist.
IPSECM工作组被授权为IKEv2（[RFC5996]）提供对称安全密码认证协议，该协议支持使用低熵共享机密，并在不需要使用证书或可扩展认证协议（EAP）的情况下防止离线字典攻击。此类方法有多种，工作组将选择一种。不幸的是，工作组未能选择一项议定书，而且有多个候选国作为单独的文件提出。由于这些文件的每个较旧版本都使用了不同的技术来协商方法的使用，并且使用了不同的有效负载格式，因此很难尝试在多个此类系统共存的情况下实现。
Current document versions ([SPSK-AUTH], [PACE], and [PAKE]) use the method described in this document.
当前文档版本（[SPSK-AUTH]、[PACE]和[PAKE]）使用本文档中描述的方法。
This document describes IKEv2 payload formats that can be used for multiple secure password methods to negotiate and transmit data so each different method can easily co-exist in the same implementation.
本文档描述了IKEv2有效负载格式，可用于多个安全密码方法协商和传输数据，从而使每个不同的方法可以在同一实现中轻松共存。
This document consists of two major parts:
本文件包括两个主要部分：
o How to negotiate which secure password method negotiation is used.
o 如何协商使用哪种安全密码协商方法。
o How to transmit data, between peers, that is specific to secure password methods.
o 如何在对等方之间传输特定于安全密码方法的数据。
The secure password methods are not usually meant to be used in the normal end user (remote access VPN) cases. In such cases, EAP-based authentication works fine, and the asymmetric nature of EAP does not matter. In such scenarios, the authentication is usually backed up with the back-end Authentication, Authorization, and Accounting (AAA) servers and other infrastructure. That is, in such scenarios, neither of the IKEv2 peers really knows the secret, as on one end it is typed in by the user when it is needed, and on the other end it is authenticated by the back-end AAA server.
安全密码方法通常不适用于普通终端用户（远程访问VPN）情况。在这种情况下，基于EAP的身份验证工作正常，EAP的不对称性质并不重要。在这种情况下，身份验证通常由后端身份验证、授权和记帐（AAA）服务器和其他基础架构进行备份。也就是说，在这样的场景中，IKEv2对等方都不知道这个秘密，因为在一端，它是由用户在需要时键入的，而在另一端，它是由后端AAA服务器验证的。
The new secure password methods are meant to be used, for example, in the authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either end can initiate an IKEv2 connection. Note that such a model could also be supported by EAP when an EAP method that can run in symmetric fashion is in use, and the EAP method is directly implemented on both peers and no AAA is in use.
例如，新的安全密码方法将用于两台服务器或路由器之间的身份验证。这些场景通常是对称的：两个对等方都知道共享秘密，不涉及后端身份验证服务器，并且任何一端都可以启动IKEv2连接。请注意，当使用可以以对称方式运行的EAP方法时，EAP也可以支持这种模型，并且EAP方法直接在两个对等方上实现，并且没有使用AAA。
In many cases, each implementation will use only one of the proposed secure password authentication methods but can include support for multiple methods even when only one of them will be used. For example, a general-purpose operating system running IPsec and IKEv2 and supporting secure password authentication methods to protect services provided by the system might need to implement support for several methods. It is then up to the administrator which one is to be used. As the server might need to connect to multiple other servers, each implementing a different set of methods, it may not be possible to pick one method that would serve all cases.
在许多情况下，每个实现将只使用其中一种建议的安全密码身份验证方法，但即使只使用其中一种方法，也可以包括对多种方法的支持。例如，运行IPsec和IKEv2并支持安全密码身份验证方法以保护系统提供的服务的通用操作系统可能需要实现对多种方法的支持。然后由管理员决定使用哪一个。由于服务器可能需要连接到多个其他服务器，每个服务器实现一组不同的方法，因此可能无法选择一个方法来服务所有情况。
The secure password methods mostly keep the existing IKEv2 IKE_SA_INIT exchange and modify the IKE_AUTH authentication step. As those methods do not want to add new round trips, negotiating which of the secure password methods to use needs to happen during the IKE_SA_INIT. As the identity of the other end is only provided inside IKE_AUTH, the responder needs to select the list of supported methods based only on the IP address of the initiator. This could lead to problems if only certain methods would be acceptable for certain identified peers. Fortunately, as the authentication is done based on the secret shared between both peers, the shared secret should be usable in all of the methods; thus, a remote peer usually
安全密码方法大多保留现有的IKEv2 IKE_SA_INIT交换，并修改IKE_AUTH身份验证步骤。由于这些方法不希望添加新的往返，因此需要在IKE_SA_INIT期间协商使用哪种安全密码方法。由于另一端的标识仅在IKE_AUTH中提供，因此响应者需要仅基于启动器的IP地址选择支持的方法列表。如果某些已确定的对等方只能接受某些方法，这可能会导致问题。幸运的是，由于身份验证是基于两个对等方之间共享的秘密进行的，因此共享的秘密应该在所有方法中都是可用的；因此，远程对等方通常
does not need to restrict selection of the method based on the initiator's identity but only based on the supported methods and the administrative policy.
不需要基于发起人的身份限制方法的选择，而只需要基于支持的方法和管理策略。
Also, as the initiator already knows which peer it is connecting with, it can limit which methods it proposes to the other peer. And as secure password methods are meant to be used in symmetric cases, both ends should have similar configuration; i.e., they have the same shared secret and, most likely, also a list of acceptable authentication methods to be used. This could also be interpreted so that there is no need to support method negotiation, as both ends can already see this from the configuration. On the other hand, in most cases, either end does not really care which method is used but is willing to use any secure method that the other end supports. In such cases, the automatic negotiation provides a way to make the configuration easy, i.e., no need to pick one method to be used between the peers.
此外，由于发起方已经知道它正在与哪个对等方连接，它可以限制它向另一个对等方提出的方法。由于安全密码方法将用于对称情况，因此两端应具有相似的配置；i、 例如，它们具有相同的共享秘密，并且很可能还有一个可接受的身份验证方法列表。这也可以解释为不需要支持方法协商，因为两端都可以从配置中看到这一点。另一方面，在大多数情况下，任何一方都不关心使用哪种方法，而是愿意使用另一方支持的任何安全方法。在这种情况下，自动协商提供了一种使配置变得容易的方法，即不需要在对等方之间选择要使用的一种方法。
The reason for using the common IKEv2 payload to transmit, between peers, data that is specific to the secure password method is that the payload type field in the IKEv2 is only an 8-bit field, and 62.5% of the range is already reserved (50% to the private use numbers, and 12.5% to the IKEv1 payload numbers). This leaves 95 usable numbers, out of which 16 are already in use. Initially, it was proposed that five payload type numbers be consumed. Those five new payload types would already represent a 31% increase in the number of currently allocated payload types.
使用公共IKEv2有效载荷在对等方之间传输特定于安全密码方法的数据的原因是，IKEv2中的有效载荷类型字段仅为8位字段，并且已经保留了62.5%的范围（50%为专用编号，12.5%为IKEv1有效载荷编号）。剩下95个可用数字，其中16个已经在使用中。最初，建议使用五个有效载荷类型编号。这五种新的有效负载类型将使当前分配的有效负载类型数量增加31%。
Because all of the methods modify the IKE_AUTH exchange, the negotiation of the secure password method to be used needs to happen during the IKE_SA_INIT exchange. The secure password negotiation exchange would be:
由于所有方法都修改了IKE_AUTH交换，因此在IKE_SA_INIT交换期间需要协商要使用的安全密码方法。安全密码协商交换将是：
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT,
Flags: Initiator, Message ID=0),
SAi1, KEi, Ni, [N(SECURE_PASSWORD_METHODS)] -->
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT,
Flags: Initiator, Message ID=0),
SAi1, KEi, Ni, [N(SECURE_PASSWORD_METHODS)] -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT,
Flags: Response, Message ID=0),
SAr1, KEr, Nr, [CERTREQ],
[N(SECURE_PASSWORD_METHODS)]
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT,
Flags: Response, Message ID=0),
SAr1, KEr, Nr, [CERTREQ],
[N(SECURE_PASSWORD_METHODS)]
If the N(SECURE_PASSWORD_METHODS) Notify payload is missing, then normal IKEv2 authentication methods are used. If the Notify payloads are included, then the negotiation of the secure password methods happens inside those payloads.
如果N（安全密码方法）Notify有效负载丢失，则使用正常的IKEv2身份验证方法。如果包含Notify有效负载，则安全密码方法的协商将在这些有效负载内进行。
As it might be possible that future secure password methods will modify the IKE_AUTH payload in a more substantial way, it is better that as an end result of the negotiation we have exactly one secure password method that will be used. The initiator will know which methods are usable when talking to that responder, so the initiator will send a list of acceptable methods in its IKE_SA_INIT request. The responder will pick exactly one method and put that in its response.
由于未来的安全密码方法可能会以更实质性的方式修改IKE_AUTH有效负载，因此作为协商的最终结果，我们最好只使用一种安全密码方法。发起者在与响应者交谈时会知道哪些方法是可用的，因此发起者将在其IKE_SA_INIT请求中发送可接受方法的列表。响应者将选择一种方法并将其放入响应中。
The secure password methods are identified by the 16-bit IANA-allocated numbers stored in the Notify payload notification data field. If a method supports multiple different password preprocessing methods, each of those may be allocated a separate number from this space, or the method might do its own negotiation of the preprocessing method later. As the initiator has already selected the shared secret it will be using, it will also know which preprocessing it might need, so it should propose only those preprocessing methods suitable for the selected shared secret. This means that it is recommended that separate IANA numbers be allocated for different preprocessing methods.
安全密码方法由存储在Notify payload notification数据字段中的16位IANA分配号码标识。如果一个方法支持多个不同的密码预处理方法，那么每个方法都可以从这个空间中分配一个单独的数字，或者该方法可以在以后对预处理方法进行自己的协商。由于发起者已经选择了它将要使用的共享秘密，它还将知道它可能需要哪些预处理，因此它应该只提出那些适用于所选共享秘密的预处理方法。这意味着建议为不同的预处理方法分配单独的IANA编号。
The actual Notify payload will look like this:
实际的Notify有效负载如下所示：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol ID will be zero, and the SPI Size will also be zero, meaning that the SPI field will be empty. The Notify Message Type will be 16424.
协议ID将为零，SPI大小也将为零，这意味着SPI字段将为空。通知消息类型将为16424。
The Notification Data contains the list of the 16-bit secure password method numbers:
通知数据包含16位安全密码方法编号的列表：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #1 | Secure Password Method #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #1 | Secure Password Method #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The response Notify payload contains exactly one 16-bit secure password method number inside the Notification Data field.
响应通知有效负载在通知数据字段中正好包含一个16位安全密码方法编号。
This payload will contain the data that is specific to the secure password payload. The IKE_AUTH exchanges might have a number of these inside, depending on what is required and specified by the secure password method. As the secure password method is already selected during IKE_SA_INIT, there is no need to repeat the information of the selected secure password method; thus, this payload only contains the method-specific data. As some secure password methods require multiple different payloads, they are assumed to include their method-specific payload type inside the payload -- for example, inside the first octet of the data. However, this is method-specific, and a method is free to format the payload data as it wants.
此有效负载将包含特定于安全密码有效负载的数据。IKE_AUTH Exchange内部可能有许多这样的内容，这取决于安全密码方法所要求和指定的内容。由于在IKE_SA_INIT期间已经选择了安全密码方法，因此无需重复所选安全密码方法的信息；因此，该有效载荷仅包含特定于方法的数据。由于某些安全密码方法需要多个不同的有效负载，因此假定它们在有效负载中包含其方法特定的有效负载类型——例如，在数据的第一个八位组中。然而，这是特定于方法的，方法可以自由地格式化有效负载数据。
The Generic Secure Password Method (GSPM) payload will look like this:
通用安全密码方法（GSPM）有效负载如下所示：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data Specific to the Secure Password Method ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data Specific to the Secure Password Method ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Payload Type for this payload is 49, and the name used in this document is "GSPM payload."
此有效负载的有效负载类型为49，本文档中使用的名称为“GSPM有效负载”
If the method uses payload subtypes (which are specific to the secure password method) inside the GSPM payload, the format will be like this:
如果该方法在GSPM有效负载内使用有效负载子类型（特定于安全密码方法），则格式如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype* | |
+-+-+-+-+-+-+-+-+ +
| |
~ Data Specific to the Secure Password Method ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype* | |
+-+-+-+-+-+-+-+-+ +
| |
~ Data Specific to the Secure Password Method ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* method-specific subtype field
* 方法特定子类型字段
This representation is here only for illustrative purposes; the secure password method will define the exact format of the payload contents.
此表示仅用于说明目的；安全密码方法将定义有效负载内容的确切格式。
As the negotiation takes place during IKE_SA_INIT, the secure password methods may modify the IKE_AUTH exchange if needed. To easily enable implementing multiple methods, it is recommended that IKE_AUTH exchange not be modified unnecessarily. Adding zero, one, or multiple GSPM payloads to each exchange is needed, as is the modification to how the AUTH payload is calculated, but all other changes should be kept minimal.
由于协商在IKE_SA_INIT期间进行，因此安全密码方法可以根据需要修改IKE_AUTH交换。为了方便地实现多种方法，建议不要不必要地修改IKE_AUTH exchange。需要向每个交换添加零、一个或多个GSPM有效负载，以及修改AUTH有效负载的计算方式，但所有其他更改都应保持最小。
The IKE_AUTH exchange should look similar to when EAP is used, meaning that the first request includes IDi, SAi2, TSi, TSr, and some number of GSPM payloads. The response should include IDr and, again, a number of GSPM payloads. There may be multiple exchanges, each consisting of some number of GSPM payloads; finally, when authentication is done, there should be one final exchange where the request includes the AUTH payload (along with some number of GSPM payloads) and the response contains AUTH, SAr2, TSi, TSr, and some number of GSPM payloads. The number of GSPM payloads is up to the secure password method but usually will be less than 3. However, depending on the method, it might be more.
IKE_认证交换应该与使用EAP时类似，这意味着第一个请求包括IDi、SAi2、TSi、TSr和一些GSPM有效负载。响应应包括IDr和若干GSPM有效载荷。可能有多个交换机，每个交换机由一定数量的GSPM有效载荷组成；最后，当完成身份验证时，应该有一个最终交换，其中请求包括身份验证有效负载（以及一些GSPM有效负载），响应包含身份验证、SAr2、TSi、TSr和一些GSPM有效负载。GSPM有效负载的数量取决于安全密码方法，但通常少于3个。但是，根据方法的不同，它可能会更复杂。
The AUTH payload calculation should include all the data that would normally be included, in addition to the extra data needed by the secure password method. The secure password method needs to define how the AUTH payload is calculated.
除了安全密码方法所需的额外数据外，AUTH有效负载计算还应包括通常包括的所有数据。安全密码方法需要定义如何计算身份验证有效负载。
As the AUTH payload calculation is changed, the secure payload method should not use any of the existing authentication method numbers in the AUTH Payload Auth Method field but instead should use the number allocated in this document. This number is meant to be used by all secure password authentication methods.
随着身份验证有效负载计算的更改，安全有效负载方法不应使用身份验证有效负载身份验证方法字段中的任何现有身份验证方法编号，而应使用本文档中分配的编号。此号码用于所有安全密码身份验证方法。
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, [CERTREQ,]
GSPM, [GSPM, ...,]
[IDr,] SAi2,
TSi, TSr} -->
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, [CERTREQ,]
GSPM, [GSPM, ...,]
[IDr,] SAi2,
TSi, TSr} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, [CERT,]
GSPM, [GSPM, ...]}
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, [CERT,]
GSPM, [GSPM, ...]}
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=2),
SK {GSPM, [GSPM, ...,]} -->
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=2),
SK {GSPM, [GSPM, ...,]} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags: Response, Message ID=2), SK {GSPM, [GSPM, ...]} ...
<--HDR（SPIi=xxx，SPIr=yyy，IKE_AUTH，标志：响应，消息ID=2），SK{GSPM，[GSPM，…]}。。。
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=x),
SK {[GSPM, ...,], AUTH} -->
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=x),
SK {[GSPM, ...,], AUTH} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=x),
SK {[GSPM, ...,] AUTH, SAr2,
TSi, TSr}
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=x),
SK {[GSPM, ...,] AUTH, SAr2,
TSi, TSr}
Note that the number of the GSPM payloads and other payloads in each packet will be defined only by the secure password method documentation, and representations in this document are only for illustrative purposes.
注意，每个分组中的GSPM有效载荷和其他有效载荷的数量将仅由安全密码方法文档定义，并且本文档中的表示仅用于说明目的。
As this document does not describe an exact protocol, the security considerations are not relevant. Any secure password method documentation using payload types described here needs to also describe the security properties of the protocol it defines or discusses.
由于本文件未描述确切的协议，因此安全注意事项不相关。使用此处描述的有效负载类型的任何安全密码方法文档还需要描述其定义或讨论的协议的安全属性。
This document allocates one new IKEv2 message type in the "Notify Messages Types - Status Types" registry:
本文档在“通知消息类型-状态类型”注册表中分配一个新的IKEv2消息类型：
16424 SECURE_PASSWORD_METHODS
16424安全密码方法
This document also allocates one new number in the "IKEv2 Authentication Method" registry:
本文档还在“IKEv2身份验证方法”注册表中分配一个新号码：
12 Generic Secure Password Authentication Method
12通用安全密码认证方法
This document also adds one new payload type to the "IKEv2 Payload Types" registry:
本文档还向“IKEv2有效负载类型”注册表添加了一种新的有效负载类型：
49 Generic Secure Password Method GSPM
49通用安全密码方法GSPM
This document creates a new IANA registry -- "IKEv2 Secure Password Methods":
本文档创建了一个新的IANA注册表--“IKEv2安全密码方法”：
0 Reserved
0保留
Values 1-1023 are unassigned. Values 1024-65535 are for private use among mutually consenting parties. Changes and additions to this registry are done by Expert Review.
值1-1023未赋值。值1024-65535供双方同意的各方私用。此注册表的更改和添加由专家评审完成。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[PACE] Kuegler, D. and Y. Sheffer, "Password Authenticated Connection Establishment with IKEv2", Work in Progress, September 2011.
[PACE]Kuegler，D.和Y.Sheffer，“通过IKEv2建立密码验证的连接”，正在进行的工作，2011年9月。
[PAKE] Shin, S. and K. Kobara, "Most Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2", Work in Progress, July 2011.
[PAKE]Shin，S.和K.Kobara，“IKEv2最有效的增强密码认证和密钥交换”，正在进行的工作，2011年7月。
[SPSK-AUTH] Harkins, D., "Secure PSK Authentication for IKE", Work in Progress, July 2011.
[SPSK-AUTH]Harkins，D.，“IKE的安全PSK认证”，正在进行的工作，2011年7月。
Author's Address
作者地址
Tero Kivinen AuthenTec Eerikinkatu 28 HELSINKI FI-00180 Finland
Tero Kivinen AuthenTec Eirikinkatu 28赫尔辛基FI-00180芬兰
EMail: kivinen@iki.fi
EMail: kivinen@iki.fi