Internet Engineering Task Force (IETF) D. Kuegler
Request for Comments: 6631 BSI
Category: Experimental Y. Sheffer
ISSN: 2070-1721 Porticor
June 2012
Internet Engineering Task Force (IETF) D. Kuegler
Request for Comments: 6631 BSI
Category: Experimental Y. Sheffer
ISSN: 2070-1721 Porticor
June 2012
Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)
使用Internet密钥交换协议版本2（IKEv2）建立经过密码验证的连接
Abstract
摘要
The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password-authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration.
Internet密钥交换协议版本2（IKEv2）在使用短凭据字符串（即密码）时不允许安全对等身份验证。已经提出了一些将密码认证协议集成到IKE中的建议。本文档提供了密码认证连接建立（PACE）对IKEv2设置的适应性，并演示了这种集成的优点。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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/rfc6631.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6631.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Overview ........................................................5
3. Protocol Sequence ...............................................6
3.1. The IKE_SA_INIT Exchange ...................................6
3.2. The IKE_AUTH Exchange, Round #1 ............................7
3.3. The IKE_AUTH Exchange, Round #2 ............................7
3.4. Public Key Validation ......................................8
3.5. Creating a Long-Term Shared Secret .........................9
3.6. Using the Long-Term Shared Secret .........................11
4. Encrypting and Mapping the Nonce ...............................11
4.1. Encrypting the Nonce ......................................11
4.2. Mapping the Nonce .........................................12
4.2.1. Modular Diffie-Hellman .............................13
4.2.2. Elliptic Curve Diffie-Hellman ......................13
5. Protocol Details ...............................................13
5.1. Password Processing .......................................13
5.2. The SECURE_PASSWORD_METHODS Notification ..................14
5.3. The PSK_PERSIST Notification ..............................15
5.4. The PSK_CONFIRM Notification ..............................15
5.5. The GSPM(ENONCE) Payload ..................................15
5.6. The KE (KEi2/KEr2) Payloads in PACE .......................16
5.7. PACE and Session Resumption ...............................16
6. Security Considerations ........................................16
6.1. Credential Security Assumptions ...........................16
6.2. Vulnerability to Passive and Active Attacks ...............16
6.3. Perfect Forward Secrecy ...................................17
6.4. Randomness ................................................17
6.5. Identity Protection .......................................17
6.6. Denial of Service .........................................17
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Overview ........................................................5
3. Protocol Sequence ...............................................6
3.1. The IKE_SA_INIT Exchange ...................................6
3.2. The IKE_AUTH Exchange, Round #1 ............................7
3.3. The IKE_AUTH Exchange, Round #2 ............................7
3.4. Public Key Validation ......................................8
3.5. Creating a Long-Term Shared Secret .........................9
3.6. Using the Long-Term Shared Secret .........................11
4. Encrypting and Mapping the Nonce ...............................11
4.1. Encrypting the Nonce ......................................11
4.2. Mapping the Nonce .........................................12
4.2.1. Modular Diffie-Hellman .............................13
4.2.2. Elliptic Curve Diffie-Hellman ......................13
5. Protocol Details ...............................................13
5.1. Password Processing .......................................13
5.2. The SECURE_PASSWORD_METHODS Notification ..................14
5.3. The PSK_PERSIST Notification ..............................15
5.4. The PSK_CONFIRM Notification ..............................15
5.5. The GSPM(ENONCE) Payload ..................................15
5.6. The KE (KEi2/KEr2) Payloads in PACE .......................16
5.7. PACE and Session Resumption ...............................16
6. Security Considerations ........................................16
6.1. Credential Security Assumptions ...........................16
6.2. Vulnerability to Passive and Active Attacks ...............16
6.3. Perfect Forward Secrecy ...................................17
6.4. Randomness ................................................17
6.5. Identity Protection .......................................17
6.6. Denial of Service .........................................17
6.7. Choice of Encryption Algorithms ...........................17
6.8. Security Model and Security Proof .........................18
6.9. Long-Term Credential Storage ..............................18
7. IANA Considerations ............................................19
8. Acknowledgments ................................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Appendix A. Protocol Selection Criteria ...........................22
A.1. Security Criteria ..........................................22
A.2. Intellectual Property Criteria .............................22
A.3. Miscellaneous Criteria .....................................22
Appendix B. Password Salting ......................................23
B.1. Solving the Asymmetric Case with Symmetric Cryptography ....24
B.2. Solving the Fully Symmetric Case with Asymmetric
Cryptography ...............................................25
B.3. Generation of a Strong, Long-Term, Shared Secret ...........26
6.7. Choice of Encryption Algorithms ...........................17
6.8. Security Model and Security Proof .........................18
6.9. Long-Term Credential Storage ..............................18
7. IANA Considerations ............................................19
8. Acknowledgments ................................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Appendix A. Protocol Selection Criteria ...........................22
A.1. Security Criteria ..........................................22
A.2. Intellectual Property Criteria .............................22
A.3. Miscellaneous Criteria .....................................22
Appendix B. Password Salting ......................................23
B.1. Solving the Asymmetric Case with Symmetric Cryptography ....24
B.2. Solving the Fully Symmetric Case with Asymmetric
Cryptography ...............................................25
B.3. Generation of a Strong, Long-Term, Shared Secret ...........26
PACE [TR03110] is a security protocol that establishes a mutually authenticated (and encrypted) channel between two parties based on weak (short) passwords. PACE provides strong session keys that are independent of the strength of the password. PACE belongs to a family of protocols often referred to as Zero-Knowledge Password Proof (ZKPP) protocols, all of which amplify weak passwords into strong session keys. This document describes the integration of PACE into IKEv2 [RFC5996] as a new authentication mode, analogous to the existing certificate and Pre-Shared Key (PSK) authentication modes.
PACE[TR03110]是一种安全协议，它基于弱（短）密码在双方之间建立相互认证（和加密）的通道。PACE提供独立于密码强度的强会话密钥。PACE属于一系列协议，通常称为零知识密码证明（ZKPP）协议，所有这些协议都将弱密码放大为强会话密钥。本文档描述了将PACE集成到IKEv2[RFC5996]中作为一种新的身份验证模式，类似于现有的证书和预共享密钥（PSK）身份验证模式。
Some of the advantages of our approach, compared to the existing IKEv2, include the following:
与现有IKEv2相比，我们的方法的一些优点包括：
o The current best practice to implement password authentication in IKE involves certificate-based authentication of the server plus some Extensible Authentication Protocol (EAP) method to authenticate the client. This involves two non-trivial infrastructure components (PKI and EAP/AAA). Moreover, certificate authentication is hard to get right and often depends on unreliable user behavior for its security.
o 在IKE中实现密码身份验证的当前最佳实践包括基于证书的服务器身份验证以及一些可扩展身份验证协议（EAP）方法来对客户端进行身份验证。这涉及两个重要的基础设施组件（PKI和EAP/AAA）。此外，证书认证很难获得正确的认证，并且往往依赖于不可靠的用户行为来保证其安全性。
o Alternatively, native IKEv2 shared secret authentication can be used with passwords. However, this usage is insecure; specifically, it is vulnerable to active attackers.
o 或者，本机IKEv2共享秘密身份验证可以与密码一起使用。然而，这种用法是不安全的；特别是，它容易受到主动攻击者的攻击。
o Some newer EAP methods can be used for mutual authentication and, combined with [RFC5998], can be well integrated into IKEv2. This is certainly an option in some cases, but the current proposal may be simpler to implement.
o 一些较新的EAP方法可用于相互认证，并与[RFC5998]相结合，可以很好地集成到IKEv2中。在某些情况下，这当然是一种选择，但目前的建议可能更容易实施。
Compared to other protocols aiming at similar goals, PACE has several advantages. PACE was designed to allow for a high level of flexibility with respect to cryptographic algorithms; e.g., it can be implemented based on Modular Diffie-Hellman as well as Elliptic Curve Diffie-Hellman without any restrictions on the mathematical group to be used, other than the requirement that the group be cryptographically secure. The protocol itself is also proven to be cryptographically secure [PACEsec]. The PACE protocol is currently used in an international standard for digital travel documents [ICAO].
与其他针对类似目标的协议相比，PACE有几个优点。PACE的设计考虑到密码算法的高度灵活性；e、 例如，它可以基于模块Diffie-Hellman和椭圆曲线Diffie-Hellman来实现，而不需要对要使用的数学组进行任何限制，除非该组是加密安全的。协议本身也被证明是加密安全的[PACEsec]。PACE协议目前用于国际数字旅行证件标准[ICAO]。
The integration aims at keeping IKEv2 unchanged as much as possible; e.g., the mechanisms used to establish Child security associations (SAs) as provided by IKEv2 would be maintained with no change.
整合旨在尽可能保持IKEv2不变；e、 例如，IKEv2提供的用于建立儿童安全协会（SA）的机制将保持不变。
The Password-Authenticated Key Exchange (PAKE) framework document [RFC6467] defines a set of payloads for different types of PAKE methods within IKEv2. This document reuses this framework. Note that the current document is self-contained; i.e., all relevant payloads and semantics are redefined here.
密码认证密钥交换（PAKE）框架文档[RFC6467]为IKEv2中不同类型的PAKE方法定义了一组有效载荷。本文档重用了这个框架。请注意，当前文档是自包含的；i、 这里重新定义了所有相关的有效载荷和语义。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following notation is used in this document:
本文件中使用了以下符号：
E() Symmetric encryption D() Symmetric decryption KA() Key agreement Map() Mapping function Pwd Shared password SPwd Stored password KPwd Symmetric key derived from a password Pwd G Static group generator GE Ephemeral group generator ENONCE Encrypted nonce PKEi Ephemeral public key of the initiator SKEi Ephemeral secret key of the initiator
E（）对称加密D（）对称解密KA（）密钥协议映射（）映射函数Pwd共享密码SPwd存储密码KPwd对称密钥派生自密码Pwd G静态组生成器GE临时组生成器ENONCE加密的nonce PKEi临时公钥启动器SKEi临时密钥启动器的临时密钥
PKEr Ephemeral public key of the responder SKEr Ephemeral secret key of the responder AUTH Authentication payload
PKEr响应者的临时公钥SKEr响应者身份验证有效负载的临时密钥
Any other notation used here is defined in [RFC5996].
此处使用的任何其他符号在[RFC5996]中定义。
At a high level, the following steps are performed by the initiator and the responder. They result in a two-round IKE_AUTH exchange, described in Section 3 below.
在高层，以下步骤由发起方和响应方执行。它们导致两轮IKE_身份验证交换，如下文第3节所述。
1. The initiator randomly and uniformly chooses a nonce s, encrypts the nonce using the password, and sends the ciphertext
1. 发起者随机且统一地选择一个nonce，使用密码加密该nonce，并发送密文
ENONCE = E(KPwd, s)
ENONCE=E（KPwd，s）
to the responder. The responder recovers the plaintext nonce s with the help of the shared password Pwd.
给响应者。响应者在共享密码Pwd的帮助下恢复明文当前值。
2. The nonce s is mapped to an ephemeral generator
2. nonce s映射到临时生成器
GE = G^s * SASharedSecret,
GE=G^s*SASharedSecret，
where G is the generator of the selected Modular Exponential (MODP) group and SASharedSecret is a shared secret that has been generated in the IKE_SA_INIT step.
其中，G是所选模指数（MODP）组的生成器，SASharedSecret是在IKE_SA_INIT步骤中生成的共享秘密。
3. Both the initiator and the responder each calculate an ephemeral key pair
3. 发起方和响应方各自计算一个临时密钥对
(SKEi, PKEi = GE^SKEi) and (SKEr, PKEr=GE^SKEr),
（SKEi，PKEi=GE^SKEi）和（SKEr，PKEr=GE^SKEr），
respectively, based on the ephemeral generator GE, and exchange the public keys.
分别基于瞬时生成器GE，交换公钥。
4. Finally, they compute the shared secret
4. 最后，他们计算共享秘密
PACESharedSecret = PKEi^SKEr = PKEr^SKEi
PACESharedSecret = PKEi^SKEr = PKEr^SKEi
and generate, exchange, and verify the IKE authentication token AUTH using the shared secret PACESharedSecret.
并使用共享密钥PACESharedSecret生成、交换和验证IKE身份验证令牌AUTH。
The encryption function E() must be carefully chosen to prevent dictionary attacks that would otherwise allow an attacker to recover the password. Those restrictions are described in Section 4.1. Details on the mapping function, including the elliptic curve variant, can be found in Section 4.2.
必须仔细选择加密函数E（），以防止字典攻击，否则攻击者将无法恢复密码。第4.1节描述了这些限制。有关映射函数（包括椭圆曲线变量）的详细信息，请参见第4.2节。
To avoid the risks inherent in storing a short password (e.g., the fact that passwords are often reused for different applications), this protocol allows the peers to jointly convert the password into a cryptographically stronger shared secret. This shared secret can then be stored by both peers, in lieu of the original password or its salted variants.
为了避免存储短密码所固有的风险（例如，密码经常被用于不同的应用程序），该协议允许对等方联合将密码转换为加密更强的共享秘密。然后，这一共享秘密可以由两个对等方存储，而不是原始密码或其附加变体。
The protocol consists of three round trips -- an IKE_SA_INIT exchange and a 2-round IKE_AUTH exchange -- as shown in the next figure. An optional Informational exchange may follow (see Section 3.5).
如下图所示，该协议包括三个往返——一个IKE_SA_INIT交换和一个2轮IKE_AUTH交换。随后可能会有一个可选的信息交换（见第3.5节）。
Initiator Responder
--------- ---------
Initiator Responder
--------- ---------
IKE_SA_INIT:
IKE_SA_INIT：
HDR, SAi1, KEi, Ni, N(SECURE_PASSWORD_METHODS) ->
HDR, SAi1, KEi, Ni, N(SECURE_PASSWORD_METHODS) ->
<- HDR, SAr1, KEr, Nr, N(SECURE_PASSWORD_METHODS)
<-HDR、SAr1、KEr、Nr、N（安全密码方法）
IKE_AUTH round #1:
IKE#u AUTH round#1：
HDR, SK{IDi, [IDr,], SAi2,
TSi, TSr, GSPM(ENONCE), KEi2} ->
HDR, SK{IDi, [IDr,], SAi2,
TSi, TSr, GSPM(ENONCE), KEi2} ->
<- HDR, SK{IDr, KEr2}
<- HDR, SK{IDr, KEr2}
IKE_AUTH round #2:
IKE#u AUTH round#2：
HDR, SK{AUTH [, N(PSK_PERSIST)] } ->
HDR, SK{AUTH [, N(PSK_PERSIST)] } ->
<- HDR, SK{AUTH, SAr2, TSi, TSr [, N(PSK_PERSIST)] }
<- HDR, SK{AUTH, SAr2, TSi, TSr [, N(PSK_PERSIST)] }
Figure 1: IKE SA Setup with PACE
图1:IKE SA设置与速度
The initiator sends a SECURE_PASSWORD_METHODS notification that indicates its support of this extension and its wish to authenticate using a password. The following text assumes that the responder sent back a SECURE_PASSWORD_METHODS notification that indicates its preference for PACE.
发起者发送一个安全密码方法通知，表明其支持此扩展并希望使用密码进行身份验证。下面的文本假定响应者发回一个安全的密码方法通知，该通知指示其对速度的偏好。
If PACE was chosen, the algorithms negotiated in SAi1 and SAr1 are also used for the execution of PACE, i.e., the key agreement protocol (Modular Diffie-Hellman or Elliptic Curve Diffie-Hellman), the group to be used, and the encryption algorithm.
如果选择了PACE，则SAi1和SAr1中协商的算法也用于执行PACE，即密钥协商协议（Modular Diffie-Hellman或椭圆曲线Diffie-Hellman）、要使用的组和加密算法。
This is the first part of the PACE authentication of the peers. This exchange MUST NOT be used unless both peers indicated support of this protocol.
这是对等方的PACE身份验证的第一部分。除非两个对等方都表示支持此协议，否则不得使用此交换。
The initiator selects a random nonce s and encrypts it to form ENONCE using the password Pwd, as described in Section 4.1. Then, the initiator maps the nonce to an ephemeral generator GE of the group as described in Section 4.2, chooses randomly and uniformly an ephemeral key pair (SKEi,PKEi) based on the ephemeral generator, and finally generates the payloads GSPM(ENONCE) containing the encrypted nonce and KEi2 containing the ephemeral public key.
如第4.1节所述，发起者选择一个随机的nonce，并使用密码Pwd对其进行加密以形成ENONCE。然后，发起者将nonce映射到第4.2节中描述的组的临时生成器GE，基于临时生成器随机且一致地选择临时密钥对（SKEi，PKEi），并最终生成包含加密nonce的有效载荷GSPM（ENONCE）和包含临时公钥的KEi2。
The responder decrypts the received encrypted nonce s = D(KPwd, ENONCE), performs the mapping, and randomly and uniformly chooses an ephemeral key pair (SKEr,PKEr) based on the ephemeral generator GE. The responder generates the KEr2 payload containing the ephemeral public key.
响应者解密接收到的加密nonce s=D（KPwd，ENONCE），执行映射，并基于临时生成器GE随机且一致地选择临时密钥对（SKEr，PKEr）。响应者生成包含临时公钥的KEr2有效载荷。
The request is equivalent to the IKE_AUTH request in a normal IKEv2 exchange; i.e., any payload that is valid in an IKE_AUTH request is valid (with the same semantics) in this round's request. In particular, certificate-related payloads are allowed, even though their use may not be practical within this mode.
该请求相当于正常IKEv2交换中的IKE_AUTH请求；i、 例如，在IKE_AUTH请求中有效的任何有效负载在本轮请求中都是有效的（具有相同的语义）。特别是，允许使用与证书相关的有效载荷，即使在这种模式下可能不实用。
This is the second part of the PACE authentication of the peers.
这是对等方的PACE身份验证的第二部分。
The initiator and the responder calculate the shared secret PACESharedSecret
发起者和响应者计算共享的秘密步调SharedSecret
PACESharedSecret = KA(SKEi, PKEr, GE) = KA(SKEr, PKEi, GE),
PACESharedSecret=KA（SKEi，PKEr，GE）=KA（SKEr，PKEi，GE），
where KA denotes the Diffie-Hellman key agreement, e.g., (for MODP groups), modular exponentiation. Then, they calculate the authentication tokens AUTHi and AUTHr.
其中KA表示Diffie-Hellman密钥协议，例如，（对于MODP组），模幂运算。然后，它们计算身份验证令牌AUTHi和AUTHr。
The initiator calculates
发起者计算
AUTHi = prf(prf+(Ni | Nr, PACESharedSecret),
<InitiatorSignedOctets> | PKEr)
AUTHi = prf(prf+(Ni | Nr, PACESharedSecret),
<InitiatorSignedOctets> | PKEr)
See Section 2.15 of [RFC5996] for the definition of signed octets.
有符号八位字节的定义见[RFC5996]第2.15节。
The responder calculates
响应者计算
AUTHr = prf(prf+(Ni | Nr, PACESharedSecret),
<ResponderSignedOctets> | PKEi)
AUTHr = prf(prf+(Ni | Nr, PACESharedSecret),
<ResponderSignedOctets> | PKEi)
Both AUTH payloads MUST indicate as their authentication method the Generic Secure Password Authentication Method [RFC6467], whose value is 12. The authentication tokens are exchanged, and each of them MUST be verified by the other party. The behavior when this verification fails is unchanged from [RFC5996].
Both AUTH payloads MUST indicate as their authentication method the Generic Secure Password Authentication Method [RFC6467], whose value is 12. The authentication tokens are exchanged, and each of them MUST be verified by the other party. The behavior when this verification fails is unchanged from [RFC5996].translate error, please retry
Each of the peers MAY generate a long-term credential at this point, after it has verified the opposite peer's identity. The shared secret is
在验证了对方的身份后，每个对等方可以在此时生成长期凭证。共同的秘密是
LongTermSecret = prf(Ni | Nr, "PACE Generated PSK" | PACESharedSecret),
LongTermSecret=prf（Ni | Nr，“速度生成PSK”|速度共享保密），
where the literal string is ASCII-encoded, with no zero terminator. The generated secret MUST be persisted to stable memory before sending the response. See Section 3.5 for more details about this facility.
其中文字字符串是ASCII编码的，没有零终止符。在发送响应之前，必须将生成的秘密保存到稳定内存中。有关该设施的更多详情，请参见第3.5节。
This round's response is equivalent to the IKE_AUTH response in a normal IKEv2 exchange; i.e., any payload that is valid in an IKE_AUTH response is valid (with the same semantics) in the second round's response.
这一轮的响应相当于正常IKEv2交换中的IKE_AUTH响应；i、 例如，在IKE_AUTH响应中有效的任何有效负载在第二轮响应中都是有效的（具有相同的语义）。
Following authentication, all temporary values MUST be deleted by the peers, including in particular s, the ephemeral generator, the ephemeral key pairs, and PACESharedSecret.
在身份验证之后，对等方必须删除所有临时值，尤其包括临时生成器、临时密钥对和PACESharedSecret。
The security of the protocol relies on the entanglement of a weak password with cryptographically strong shared secrets, SASharedSecret and PACESharedSecret, mutually and randomly generated by the initiator and the responder. If an attacker can influence the randomness of those shared secrets, the confidentiality of the password may be directly affected.
协议的安全性依赖于弱密码与加密强共享秘密（SASharedSecret和PACESharedSecret）的纠缠，由发起方和响应方相互随机生成。如果攻击者可以影响这些共享机密的随机性，则密码的机密性可能会直接受到影响。
Implementations MUST therefore verify that the shared secrets SASharedSecret and PACESharedSecret are random elements of the group generated by G to prevent small subgroup attacks. This can be achieved by a validation of the public keys (i.e., KEi, PKEi, and KEr, PKEr).
因此，实现必须验证共享机密SASharedSecret和PACESharedSecret是由G生成的组的随机元素，以防止小型子组攻击。这可以通过验证公钥（即KEi、PKEi和KEr、PKEr）来实现。
First of all, each party MUST check that the public keys PKEi, PKEr, KEi, and KEr differ. Otherwise, it MUST abort the protocol.
首先，各方必须检查公钥PKEi、PKEr、KEi和KEr是否不同。否则，它必须中止协议。
For each received public key PK, the following tests SHOULD be performed. Any failure in the validation MUST be interpreted as an attack, and the protocol SHALL be aborted.
对于每个收到的公钥PK，应执行以下测试。验证中的任何失败都必须解释为攻击，协议应中止。
o Verify that PK is an element of the Diffie-Hellman Group.
o 确认PK是Diffie-Hellman组的一个元素。
* For Modular Diffie-Hellman, check that PK lies within the interval [2,p-2].
* 对于模块化Diffie-Hellman，检查PK是否在区间[2，p-2]内。
* For Elliptic Curve Diffie-Hellman, check that PK is a point on the Elliptic Curve and not the point at infinity.
* 对于椭圆曲线Diffie-Hellman，检查PK是椭圆曲线上的一个点，而不是无穷远处的点。
o Verify that PK is an element of the cryptographic subgroup of order q.
o 验证PK是否是顺序为q的加密子组的元素。
* For Modular Diffie-Hellman, check that PK^q = 1 (mod p).
* 对于模块化Diffie-Hellman，检查PK^q=1（mod p）。
* For Elliptic Curve Diffie-Hellman, check that q * PK = 0.
* 对于椭圆曲线Diffie-Hellman，检查q*PK=0。
Note that for most of the MODP groups, the order q = (p-1)/2. This
applies in particular to the standard groups #2, #5, and #14,
commonly used in IKE. For ECP and MODP groups not based on safe
primes, the order q is explictly stated in the parameters.
Note that for most of the MODP groups, the order q = (p-1)/2. This
applies in particular to the standard groups #2, #5, and #14,
commonly used in IKE. For ECP and MODP groups not based on safe
primes, the order q is explictly stated in the parameters.
As an alternative to the public key validation, the compatible cofactor exponentiation/multiplication may be used, which is often more efficient but requires changes to the implementation of the key agreement. Details on the implementation can be found in [RFC2785] and in [TR03111] for Modular Diffie-Hellman and Elliptic Curve Diffie-Hellman, respectively.
作为公钥验证的替代方案，可以使用兼容的辅因子求幂/乘法，这通常更有效，但需要更改密钥协议的实现。有关实现的详细信息，可分别在[RFC2785]和[TR03111]中找到模块化Diffie-Hellman和椭圆曲线Diffie-Hellman。
To reduce the time that the peers store a hashed password, it is RECOMMENDED that the password be replaced by a dedicated shared secret, according to the method described in this section. See Appendix B for more discussion of the security threats involved.
为了减少对等方存储散列密码的时间，建议根据本节中描述的方法，用专用共享密钥替换密码。有关涉及的安全威胁的更多讨论，请参见附录B。
Both peers generate the value LongTermSecret during round #2 of IKE_AUTH, as shown above. Later on, they exchange a PERSIST_PSK notification. Assume that both peers support this mechanism (e.g., the IKE implementation is able to modify its own credential store). Then, each of the peers, when receiving the notification, permanently
如上图所示，两个对等方在IKE#U AUTH的第2轮中生成值LongTermSecret。稍后，它们交换一个PERSIST_PSK通知。假设两个对等方都支持这种机制（例如，IKE实现能够修改自己的凭证存储）。然后，当接收到通知时，每个对等方将永久地
deletes the stored password and replaces it with LongTermSecret. These credentials are stored in the Peer Authorization Database (PAD) [RFC4301] and are associated with the identity of the opposite peer.
删除存储的密码并将其替换为LongTermSecret。这些凭证存储在对等授权数据库（PAD）[RFC4301]中，并与对方的身份相关联。
This solution is designed as a two-phase commitment, so that failure at any time cannot result in the peers not having any shared secret.
此解决方案设计为两阶段承诺，因此任何时候的失败都不会导致对等方没有任何共享秘密。
Initiator Responder
--------- ---------
Initiator Responder
--------- ---------
IKE_AUTH round #2:
IKE#u AUTH round#2：
HDR, SK{..., N(PSK_PERSIST)} ---------->
Responder computes and stores PSK
HDR, SK{..., N(PSK_PERSIST)} ---------->
Responder computes and stores PSK
<------- HDR, SK{..., N(PSK_PERSIST)}
<------- HDR, SK{..., N(PSK_PERSIST)}
Initiator computes and stores PSK
启动器计算并存储PSK
HDR, SK{N(PSK_CONFIRM)} -------------->
HDR, SK{N(PSK_CONFIRM)} -------------->
Responder deletes the short password
响应程序删除短密码
<-------------- HDR, SK{N(PSK_CONFIRM)}
<-------------- HDR, SK{N(PSK_CONFIRM)}
Initiator deletes the short password
启动器删除短密码
Figure 2: IKE SA Setup with PACE and PSK Generation
图2:PACE和PSK生成的IKE SA设置
In the second round of IKE_AUTH, the initiator MAY send a PSK_PERSIST notification if it wishes to use this mechanism. If the responder agrees, and only after it has authenticated the initiator, it MUST generate a new PSK, save it to stable storage (e.g., to disk), and MUST respond with a PSK_PERSIST notification. Otherwise, it simply does not include the notification in its reply. When receiving the reply, and after authenticating the responder, the initiator MUST also generate the PSK and save it in stable storage.
在IKE_认证的第二轮中，如果发起者希望使用此机制，则可以发送PSK_持久化通知。如果响应者同意，并且仅在对启动器进行身份验证后，它必须生成一个新的PSK，将其保存到稳定存储（例如磁盘），并且必须使用PSK_PERSIST通知进行响应。否则，它只是在答复中不包括通知。当接收到回复并对响应者进行身份验证后，启动器还必须生成PSK并将其保存在稳定存储中。
If the peers have negotiated this mechanism, the initiator MUST send the PSK_CONFIRM notification in an Informational exchange shortly after the IKE SA has been set up. When the responder receives it, it MUST delete the stored short password from its credential database and respond with a PSK_CONFIRM notification. Upon receiving this notification, the initiator deletes its copy of the short password.
如果对等方已协商此机制，则发起方必须在IKE SA设置后不久在信息交换中发送PSK_确认通知。当响应者收到它时，它必须从其凭证数据库中删除存储的短密码，并用PSK_确认通知进行响应。收到此通知后，启动器将删除其短密码副本。
If not saved to persistent storage, the LongTermSecret MUST be deleted when the IKE SA is rekeyed or when it is torn down. It SHOULD be deleted 1 hour after the initial IKE SA has been set up.
如果未保存到持久性存储，则在IKE SA重新设置密钥或拆除时，必须删除LongTermSecret。应在初始IKE SA设置后1小时将其删除。
The LongTermSecret MUST be used as a regular IKE Pre-Shared Key (PSK), rather than with PACE or any other password-based authentication method.
长期机密必须作为常规IKE预共享密钥（PSK）使用，而不是与PACE或任何其他基于密码的身份验证方法一起使用。
Normally, at the completion of this protocol, both peers will have either a shared password or a shared PSK. The protocol is designed so that the peers will have a shared credential, regardless of any protocol failures. However, in some failure cases, the initiator may find itself with both a short password and a PSK for a particular peer. In that case, it MUST first try to authenticate with a password and, upon success, MUST attempt to convert it to a PSK. If password authentication fails, it MUST use the PSK and upon successful setup of the IKE SA MUST permanently delete the password.
通常，在该协议完成时，两个对等方将拥有共享密码或共享PSK。该协议的设计使对等方拥有共享凭证，而不管任何协议故障。但是，在某些故障情况下，启动器可能会发现自己有一个短密码和一个特定对等方的PSK。在这种情况下，它必须首先尝试使用密码进行身份验证，成功后，必须尝试将其转换为PSK。如果密码验证失败，它必须使用PSK，并且在成功设置IKE SA后，必须永久删除密码。
The shared password is not used as is. Instead, it SHOULD be converted into a "stored password" SPwd, so that the plaintext password does not need to be stored for long periods. SPwd is defined as
共享密码未按原样使用。相反，应该将其转换为“存储密码”SPwd，以便不需要长时间存储明文密码。SPwd定义为
SPwd = prf("IKE with PACE", Pwd),
SPwd=prf（“带速度的IKE”，Pwd），
where the literal string consists of ASCII characters with no zero terminator. If the negotiated pseudorandom function (prf) requires a fixed-size key, the literal string is either truncated or padded with zero octets on the right, as needed. Multiple copies of SPwd MAY be stored, if the prf function is not known in advance.
其中，文字字符串由ASCII字符组成，不带零终止符。如果协商伪随机函数（prf）需要固定大小的密钥，则根据需要截断文本字符串或在右侧填充零八位字节。如果事先不知道prf功能，则可以存储SPwd的多个副本。
KPwd = prf+(Ni | Nr, SPwd),
KPwd=prf+（Ni | Nr，SPwd），
where Ni and Nr are the regular IKE nonces, stripped of any headers. If the negotiated prf takes a fixed-length key and the lengths of Ni and Nr do not add up to that length, half the bits must come from Ni and half from Nr, taking the first bits of each. "prf+" is defined in Section 2.13 of [RFC5996]. The length of KPwd is determined by the key length of the negotiated encryption algorithm.
其中Ni和Nr是常规IKE nonce，去掉任何头。如果协商的prf采用固定长度密钥，并且Ni和Nr的长度加起来不等于该长度，则一半的位必须来自Ni，另一半来自Nr，取每个密钥的第一位。[RFC5996]第2.13节定义了“prf+”。KPwd的长度由协商加密算法的密钥长度决定。
A nonce s is randomly selected by the initiator (see Section 6.4 for additional considerations). The length of s MUST be exactly 32 octets.
发起者随机选择一个nonce（其他注意事项见第6.4节）。s的长度必须正好是32个八位字节。
KPwd is now used with the encryption transform to encrypt the nonce:
KPwd现在与加密转换一起用于加密nonce：
ENONCE = E(KPwd, s)
ENONCE=E（KPwd，s）
If an Initialization Vector (IV) is required by the cipher, it MUST be included in the GSPM(ENONCE) payload. It is RECOMMENDED that the IV be chosen both randomly and uniformly distributed, even though this condition is not necessary for the cryptographic security of the protocol.
如果密码需要初始化向量（IV），则必须将其包含在GSPM（ENONCE）有效负载中。建议选择随机且均匀分布的IV，即使该条件对于协议的加密安全不是必需的。
Note: Padding MUST NOT be used when encrypting the nonce. The size of the nonce has been chosen such that it can be encrypted with block ciphers having block sizes of 32, 64, and 128 bits without any padding.
注意：加密nonce时不得使用填充。已选择nonce的大小，以便可以使用块大小为32、64和128位的块密码对其进行加密，而无需任何填充。
If an authenticated encryption cipher [RFC5282] has been negotiated for the IKE SA, it MUST NOT be used as is because such use would be vulnerable to dictionary attacks. Instead, the corresponding unauthenticated mode MUST be used. All Galois/Counter Mode (GCM) and all Counter with CBC-MAC (CCM) encryption algorithms are mapped to the corresponding counter-mode algorithm. For example, if the negotiated encryption algorithm (Transform Type 1) is "AES-GCM with an 8-octet Integrity Check Value (ICV)", then ENCR_AES_CTR (with the same key length) is used to encrypt the nonce. If such a mapping does not exist for a particular cipher, then it MUST NOT be used within the current protocol.
如果已为IKE SA协商经过身份验证的加密密码[RFC5282]，则不得按原样使用，因为这种使用容易受到字典攻击。相反，必须使用相应的未经验证的模式。所有Galois/计数器模式（GCM）和所有带有CBC-MAC（CCM）加密算法的计数器都映射到相应的计数器模式算法。例如，如果协商的加密算法（转换类型1）是“具有8个八位组完整性检查值（ICV）的AES-GCM”，则使用ENCR_AES_CTR（具有相同的密钥长度）加密nonce。如果特定密码不存在这样的映射，则不能在当前协议中使用。
The mapping is based on a second anonymous Diffie-Hellman key agreement protocol to create a shared secret that is used together with the exchanged nonce to calculate a common secret generator of the group.
该映射基于第二个匿名Diffie-Hellman密钥协商协议来创建共享密钥，该共享密钥与交换的nonce一起用于计算组的公共密钥生成器。
While in [TR03110] the generation of the shared secret is part of the mapping, in the setting of IKEv2, a shared secret SASharedSecret has already been generated as part of the IKE_SA_INIT step. Using the notation of [RFC5996],
在[TR03110]中，共享秘密的生成是映射的一部分，而在IKEv2的设置中，作为IKE_SA_INIT步骤的一部分，共享秘密SASharedSecret已经生成。使用[RFC5996]的符号，
SASharedSecret = g^ir
SASharedSecret=g^ir
Let G and GE be the generator of the negotiated Diffie-Hellman group, and the calculated ephemeral generator, respectively. The following subsections describe the mapping for different Diffie-Hellman variants.
设G和GE分别为协商Diffie-Hellman群的生成元和计算的瞬时生成元。以下小节描述了不同Diffie-Hellman变体的映射。
The function Map:G->GE is defined as GE = G^s * SASharedSecret.
函数映射：G->GE被定义为GE=G^s*SASharedSecret。
Note that the protocol will fail if G^s = 1/SASharedSecret. If s is chosen randomly, this event occurs with negligible probability. In implementations that detect such a failure, the initiator SHOULD choose s again.
请注意，如果G^s=1/SASharedSecret，协议将失败。如果随机选择s，则该事件发生的概率可以忽略不计。在检测到此类故障的实现中，启动器应再次选择s。
The function Map:G->GE is defined as GE = s*G + SASharedSecret.
函数映射：G->GE被定义为GE=s*G+SASharedSecret。
Note that the protocol will fail if s*G = -SharedSecret. If s is chosen randomly, this event occurs with negligible probability. In implementations that detect such a failure, the initiator SHOULD choose s again.
请注意，如果s*G=-SharedSecret，协议将失败。如果随机选择s，则该事件发生的概率可以忽略不计。在检测到此类故障的实现中，启动器应再次选择s。
The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHOULD be considered a "stored string" per [RFC3454]; therefore, unassigned code points are prohibited. The output is the binary representation of the processed UTF-8 character string. Prohibited output and unassigned codepoints encountered in SASLprep preprocessing SHOULD cause a preprocessing failure, and the output SHOULD NOT be used. A compliant implementation MUST NOT apply any other form of processing to the input password, other than as described in this section.
输入密码字符串应根据[RFC3454]的[RFC4013]配置文件的规则进行处理。根据[RFC3454]，密码应视为“存储字符串”；因此，禁止未指定的代码点。输出是已处理UTF-8字符串的二进制表示形式。SASLprep预处理中遇到的禁止输出和未分配的代码点应导致预处理失败，并且不应使用该输出。除本节所述之外，符合要求的实现不得对输入密码应用任何其他形式的处理。
See Section 3 of [RFC4013] for examples of SASLprep processing.
SASLprep处理示例见[RFC4013]第3节。
[RFC6467] defines a new type of Notify payload to indicate support for Secure Password Methods (SPMs) in the IKE_SA_INIT exchange. The SPM Notify payload is defined as follows:
[RFC6467]定义了一种新类型的Notify有效负载，以指示在IKE_SA_INIT exchange中支持安全密码方法（SPM）。SPM 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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SECURE_PASSWORD_METHODS Payload Structure
图3:SECURE_PASSWORD_方法有效负载结构
The Protocol ID is zero, and the SPI Size is also zero, indicating that the SPI field is empty. The Notify Message Type is SECURE_PASSWORD_METHODS (value 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 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SECURE_PASSWORD_METHODS Payload Data
图4：安全密码方法有效负载数据
For the current method, the list of proposed methods MUST include the value PACE (1).
对于当前方法，建议方法的列表必须包含值PACE（1）。
This document defines the PSK_PERSIST notification type, whose value is 16425. This notification MUST be sent with no data. However, for future extensibility, the receiver MUST ignore any notification data if such data is present.
本文档定义了PSK_持久化通知类型，其值为16425。此通知必须在没有数据的情况下发送。但是，为了将来的扩展性，如果存在任何通知数据，那么接收方必须忽略这些数据。
This document defines the PSK_CONFIRM notification type, whose value is 16426. This notification MUST be sent with no data. However, for future extensibility, the receiver MUST ignore any notification data if such data is present.
本文件定义了PSK_确认通知类型，其值为16426。此通知必须在没有数据的情况下发送。但是，为了将来的扩展性，如果存在任何通知数据，那么接收方必须忽略这些数据。
This protocol defines the ENONCE (encrypted nonce) payload, which reuses the Generic SPM (GSPM) payload type [RFC6467] (value 49). Its format is as follows:
此协议定义ENONCE（加密的nonce）有效负载，它重用通用SPM（GSPM）有效负载类型[RFC6467]（值49）。其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACE-RESERVED | Initialization Vector |
+-+-+-+-+-+-+-+-+ +
| (optional, length depends on the encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACE-RESERVED | Initialization Vector |
+-+-+-+-+-+-+-+-+ +
| (optional, length depends on the encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: ENONCE Payload Structure
图5:ENONCE有效载荷结构
See Section 4.1 for further details about the encrypted nonce. Note that the protocol -- and in particular this payload's format -- does not support any padding of the encrypted data.
有关加密nonce的更多详细信息，请参见第4.1节。请注意，该协议——特别是该有效负载的格式——不支持加密数据的任何填充。
The PACE-RESERVED field must be sent as zero, and it must be rejected by the receiver if it is not 0.
保留的速度字段必须作为零发送，如果不是0，则接收方必须拒绝该字段。
PACE reuses the Key Exchange (KE) payload for its Diffie-Hellman exchange, with the new payloads being sent within the IKE_AUTH exchange. Since only one Diffie-Hellman group is negotiated, the group denoted by these payloads MUST be identical to the one used in the "regular" KE payloads in IKE_SA_INIT.
PACE为其Diffie-Hellman交换重用密钥交换（KE）有效负载，新的有效负载在IKE_AUTH交换中发送。由于只协商一个Diffie-Hellman组，因此这些有效载荷表示的组必须与IKE_SA_INIT中“常规”KE有效载荷中使用的组相同。
A session resumption [RFC5723] ticket may be requested during the IKE_AUTH exchange. The request MUST be sent in the request of the first round, and any response MUST be sent in the response of the second one.
在IKE_身份验证交换期间，可能会请求会话恢复[RFC5723]票证。请求必须在第一轮的请求中发送，任何响应都必须在第二轮的响应中发送。
PACE should be considered an "authentication method", in the sense of Section 5 of [RFC5723], which means that its use MUST be noted in the protected ticket. The format of the ticket is not standardized; however, it is RECOMMENDED that this indication distinguish between the different secure password authentication methods defined for IKE.
按照[RFC5723]第5节的规定，PACE应被视为一种“认证方法”，这意味着必须在受保护的票据中注明其使用。票面格式不规范；但是，建议此指示区分为IKE定义的不同安全密码身份验证方法。
Note that even if the initial authentication used PACE and its extended IKE_AUTH, session resumption will still include the normal IKE_AUTH exchange.
请注意，即使初始身份验证使用PACE及其扩展的IKE_身份验证，会话恢复仍将包括正常的IKE_身份验证交换。
A major goal of this protocol has been to maintain the level of security provided by IKEv2. What follows is an analysis of this protocol. The reader is referred to [RFC5996] for the generic IKEv2 security considerations.
本协议的一个主要目标是保持IKEv2提供的安全级别。下面是对该协议的分析。读者可参考[RFC5996]了解一般的IKEv2安全注意事项。
This protocol makes no assumption on the strength of the shared credential. Best common practices regarding minimal password length, use of multiple character classes, etc. SHOULD be followed.
此协议不对共享凭证的强度进行假设。应遵循有关最小密码长度、使用多个字符类等的最佳常见做法。
The protocol is secure against both passive and active attackers. See Section 6.8 for a security proof.
该协议对被动和主动攻击者都是安全的。有关安全证明，请参见第6.8节。
While not attacking the cryptography, an attacker can still perform a standard password-guessing attack. To mitigate such attacks, an implementation MUST include standard protections, such as rate-limiting the number of allowed password-guessing attempts, possibly
在不攻击加密的情况下，攻击者仍然可以执行标准的密码猜测攻击。为了减轻此类攻击，实现必须包括标准保护，例如限制允许的密码猜测尝试次数（可能是）
locking identities out after a certain number of failed attempts, etc. Note that the protocol is symmetric; therefore, this guidance applies to client-side implementations as well.
在一定次数的失败尝试后锁定身份，等等。注意协议是对称的；因此，本指南也适用于客户端实现。
The key derivation for the IKE SA and any Child SAs is performed as part of IKEv2 and remains unchanged. It directly follows that perfect forward security is provided independent of the authentication additionally performed by PACE.
IKE SA和任何子SA的密钥派生作为IKEv2的一部分执行，并且保持不变。这直接说明，完美的前向安全性是独立于PACE额外执行的身份验证而提供的。
The security of this protocol depends on the quality generation of random quantities; see Section 5 of [RFC5996] for more details. Specifically, any deviation from randomness of the nonce s might compromise the password. Therefore, it is strongly RECOMMENDED that the initiator pass the raw random material through a strong prf to ensure the statistical qualities of the nonce.
该协议的安全性取决于随机量的生成质量；详见[RFC5996]第5节。具体地说，任何对非随机性的偏离都可能危及密码。因此，强烈建议引发剂将原随机材料通过强prf，以确保nonce的统计质量。
This protocol is identical to IKEv2 in the quality of identity protection it provides. Both peers' identities are secure from passive attackers, and both peers' identities are exposed to active, man-in-the-middle attackers.
该协议在提供身份保护的质量方面与IKEv2相同。两个对等方的身份都是安全的，不会受到被动攻击者的攻击，两个对等方的身份都会受到主动的中间人攻击者的攻击。
We are not aware of any new denial-of-service attack vector enabled by this protocol.
我们不知道任何新的拒绝服务攻击向量启用该协议。
Any transforms negotiated for IKEv2 may be used by this protocol. Please refer to Section 4.1 for the considerations regarding authenticated encryption ("combined mode") algorithms.
本协议可使用为IKEv2协商的任何转换。有关认证加密（“组合模式”）算法的注意事项，请参考第4.1节。
PACE is cryptographically proven secure in [PACEsec] in the model of Bellare, Pointcheval, and Rogaway [BPRmodel]. The setting in which PACE is proven secure is, however, slightly different from the setting used in IKEv2. The differences are described in the following:
在Bellare、Pointcheval和Rogaway[BPRmodel]的模型中，PACE在[PACEsec]中被加密证明是安全的。然而，PACE被证明是安全的设置与IKEv2中使用的设置略有不同。这些差异如下所述：
o Part of the mapping is already performed within IKEv2 before PACE is started. This rearrangement does not affect the proof, as the resulting PACESharedSecret remains close to uniformly distributed in the group generated by G.
o 在PACE开始之前，已经在IKEv2中执行了部分映射。这种重新排列不会影响证明，因为由此产生的PACESharedSecret在G生成的组中保持接近均匀分布。
o The keys for the IKE SA and any Child SAs are already generated within IKEv2 before PACE is started. While those session keys could also be derived in PACE, only the keys for the authentication token are considered in the proof, which explicitly recommends a separate key for this purpose.
o 在PACE开始之前，IKEv2中已经生成了IKE SA和任何子SA的密钥。虽然这些会话密钥也可以在PACE中派生，但在证明中只考虑身份验证令牌的密钥，这明确建议为此使用单独的密钥。
o IKEv2 allows the negotiation of a stream cipher for PACE, while the proven variant always uses a block cipher. The ideal cipher is replaced in the proof by a lazy-sampling technique that is similarly applicable to the stream-cipher-based construction.
o IKEv2允许协商流密码的速度，而经过验证的变体总是使用分组密码。在证明中，理想密码被延迟采样技术取代，该技术同样适用于基于流密码的构造。
The differences in the setting therefore have no impact on the validity of the proof.
因此，环境的差异不会影响证据的有效性。
This protocol does not require that peers store the plaintext password. Instead, the value SPwd SHOULD be stored by both peers.
该协议不要求对等方存储明文密码。相反，SPwd值应由两个对等方存储。
In addition, the protocol allows both peers to replace the password by a crypto-strength shared secret. This solution improves the system's security (since passwords are often used for multiple applications), but at the cost of implementation complexity. In particular, if this optional mechanism is to be used, the credential database would need to be writable by the key management subsystem.
此外，该协议允许两个对等方用加密强度共享秘密替换密码。此解决方案提高了系统的安全性（因为密码通常用于多个应用程序），但以实现复杂性为代价。特别是，如果要使用此可选机制，则凭证数据库需要可由密钥管理子系统写入。
See Appendix B for alternatives to this approach.
有关此方法的替代方案，请参见附录B。
IANA has allocated the following values:
IANA已分配以下值：
o A PACE value of 1 from the "IKEv2 Secure Password Methods" registry [RFC6467].
o “IKEv2安全密码方法”注册表[RFC6467]中的速度值为1。
o A PSK_PERSIST value of 16425 and a PSK_CONFIRM value of 16426 from the "IKEv2 Notify Message Types - Status Types" registry. We note that these notification types are generic and that other password authentication methods may also choose to use them.
o “IKEv2通知消息类型-状态类型”注册表中的PSK_持久值16425和PSK_确认值16426。我们注意到这些通知类型是通用的，其他密码身份验证方法也可以选择使用它们。
We would like to thank Dan Harkins for pointing out a security issue with our use of combined-mode algorithms in a previous version of the protocol. We thank Tero Kivinen for his generic framework document, and for a thorough and fruitful review. Hugo Krawczyk proposed that the password be amplified into a persistent shared secret.
我们要感谢Dan Harkins指出了我们在以前版本的协议中使用组合模式算法的安全问题。我们感谢Tero Kivinen的通用框架文件，并感谢他进行了全面和富有成效的审查。Hugo Krawczyk建议将密码放大为持久的共享秘密。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.
[RFC2785]Zuccherato，R.，“避免针对S/MIME的Diffie-Hellman密钥协商方法的“小子组”攻击的方法”，RFC 27852000年3月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[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月。
[BPRmodel] Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated Key Exchange Secure against Dictionary Attacks", EUROCRYPT 2000, LNCS 1807, pp. 139-155, Springer-Verlag, 2000, <http://www.iacr.org/cryptodb/ archive/2000/EUROCRYPT/18070139.pdf>.
[BPRmodel]Bellare，M.，Pointcheval，D.，和P.Rogaway，“针对字典攻击的认证密钥交换安全”，EUROCRYPT 2000，LNCS 1807，第139-155页，Springer Verlag，2000<http://www.iacr.org/cryptodb/ 归档文件/2000/EUROCRYPT/18070139.pdf>。
[ICAO] ISO/IEC JTC1 SC17 WG3/TF5 for the International Civil Aviation Organization (ICAO), "Supplemental Access Control for Machine Readable Travel Documents", Version 1.01, November 2010.
[ICAO]国际民用航空组织（ICAO）ISO/IEC JTC1 SC17 WG3/TF5，“机器可读旅行证件的补充访问控制”，版本1.01，2010年11月。
[IKEv2-CONS] Harkins, D., "Password-Based Authentication in IKEv2: Selection Criteria and Considerations", Work in Progress, October 2010.
[IKEv2 CONS]Harkins，D.，“IKEv2中基于密码的认证：选择标准和注意事项”，正在进行的工作，2010年10月。
[PACEsec] Bender, J., Fischlin, M., and D. Kuegler, "Security Analysis of the PACE Key-Agreement Protocol", LNCS 5735, pp. 33-48, Springer-Verlag (the extended abstract appeared in Information Security Conference (ISC) 2009), December 2009, <http://eprint.iacr.org/2009/624>.
[PACEsec]Bender，J.，Fischlin，M.，和D.Kuegler，“PACE密钥协议的安全分析”，LNCS 5735，第33-48页，Springer Verlag（扩展摘要出现在2009年信息安全会议（ISC）上），2009年12月<http://eprint.iacr.org/2009/624>.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008.
[RFC5282]Black，D.和D.McGrew，“使用互联网密钥交换第2版（IKEv2）协议的加密有效负载的认证加密算法”，RFC 5282，2008年8月。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[RFC5723]Sheffer，Y.和H.Tschofenig，“互联网密钥交换协议第2版（IKEv2）会话恢复”，RFC 57232010年1月。
[RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010.
[RFC5998]Eronen，P.，Tschofenig，H.，和Y.Sheffer，“IKEv2中仅EAP认证的扩展”，RFC 5998，2010年9月。
[RFC6467] Kivinen, T., "Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)", RFC 6467, December 2011.
[RFC6467]Kivinen，T.，“互联网密钥交换版本2（IKEv2）的安全密码框架”，RFC 6467，2011年12月。
[TR03110] BSI, "TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents, Part 2 - Extended Access Control Version 2 (EACv2), Password Authenticated Connection Establishment (PACE), and Restricted Identification (RI)", Version 2.10, March 2012.
[TR03110]BSI，“TR-03110，机器可读旅行证件的高级安全机制，第2部分-扩展访问控制版本2（EACv2），密码验证连接建立（PACE）和限制性标识（RI）”，版本2.102012年3月。
[TR03111] BSI, "TR-03111, Elliptic Curve Cryptography", Version 1.11, April 2009.
[TR03111]BSI，“TR-03111，椭圆曲线密码术”，版本1.112009年4月。
To support the selection of a password-based protocol for inclusion in IKEv2, a number of criteria are provided in [IKEv2-CONS]. In the following sections, those criteria are applied to the PACE protocol.
为了支持选择基于密码的协议以包含在IKEv2中，[IKEv2 CONS]中提供了许多标准。在以下章节中，这些标准适用于PACE协议。
SEC1: PACE is a zero-knowledge protocol.
PACE是一个零知识协议。
SEC2: The protocol supports perfect forward secrecy and is resistant to replay attacks.
SEC2：该协议支持完美的前向保密性，并且能够抵抗重放攻击。
SEC3: The identity protection provided by IKEv2 remains unchanged.
SEC3:IKEv2提供的身份保护保持不变。
SEC4: Any cryptographically secure Diffie-Hellman group can be used.
SEC4：可以使用任何加密安全的Diffie-Hellman组。
SEC5: The protocol is proven secure in the Bellare-Pointcheval-Rogaway model.
SEC5：该协议在Bellare Pointcheval-Rogaway模型中被证明是安全的。
SEC6: Strong session keys are generated.
SEC6：生成强会话密钥。
SEC7: A transform of the password can be used instead of the password itself.
SEC7：可以使用密码的转换来代替密码本身。
IPR1: The first version of [TR03110] was published on May 21, 2007.
IPR1:2007年5月21日发布了[TR03110]的第一版。
IPR2: BSI has developed PACE aiming to be free of patents. BSI has not applied for a patent on PACE.
IPR2:BSI开发了PACE，旨在实现无专利。BSI尚未就PACE申请专利。
IPR3: The protocol itself is believed to be free of IPR.
IPR3：协议本身被认为是没有知识产权的。
MISC1: One additional exchange is required.
杂项1：需要进行一次额外的交换。
MISC2: The protocol requires the following operations per entity:
杂项2：协议要求每个实体执行以下操作：
* one key derivation from the password,
* 从密码派生出一个密钥，
* one symmetric encryption or decryption,
* 一个对称加密或解密，
* one multi-exponentiation for the mapping,
* 映射的一次多重幂运算，
* one exponentiation for the key pair generation,
* 密钥对生成的一次幂运算，
* one exponentiation for the shared secret calculation, and
* 共享秘密计算的一次幂运算，以及
* two symmetric authentications (generation and verification).
* 两个对称身份验证（生成和验证）。
MISC3: The performance is independent of the type/size of password.
MISC3：性能与密码的类型/大小无关。
MISC4: Internationalization of character-based passwords is supported.
杂项4：支持基于字符的密码国际化。
MISC5: The protocol uses the same group as that negotiated for IKEv2.
MISC5：协议使用与IKEv2协商的组相同的组。
MISC6: The protocol fits into the request/response nature of IKE.
MISC6：该协议符合IKE的请求/响应性质。
MISC7: The password-based symmetric encryption must be additionally negotiated.
杂项7：必须另外协商基于密码的对称加密。
MISC8: Neither trusted third parties nor clock synchronization are required.
杂项8：不需要受信任的第三方或时钟同步。
MISC9: Only general cryptographic primitives are required.
杂项9：仅需要通用加密原语。
MISC10: Any secure variant of Diffie-Hellman (e.g., Modular or Elliptic Curve) can be used.
MISC10：可以使用Diffie-Hellman的任何安全变体（例如，模块化或椭圆曲线）。
MISC11: The protocol can be implemented easily based on existing cryptographic primitives.
MISC11：该协议可以基于现有的加密原语轻松实现。
This protocol requires that passwords not be stored in plaintext. Instead, we store a hash of the password with a fixed hash. This value is then used in the ZKPP protocol, replacing the original password and acting as a "password equivalent". The main benefit of this solution is that a system administrator or an undetermined attacker does not get immediate access to the passwords. We believe this is sufficiently secure for the main usage scenario of the protocol.
该协议要求密码不能以明文形式存储。相反，我们使用固定哈希存储密码的哈希。然后在ZKPP协议中使用该值，替换原始密码并充当“等效密码”。此解决方案的主要好处是，系统管理员或未确定的攻击者无法立即访问密码。我们相信这对于协议的主要使用场景是足够安全的。
However, the common practice of password salting is clearly more powerful, and this appendix presents a few ideas on how password salting can be applied and/or adapted to fit into a symmetric protocol such as IKE. First, let us list the threats that we expect salting to handle, as well as the non-threats:
然而，密码盐析的常见实践显然更强大，本附录介绍了如何应用和/或调整密码盐析以适应对称协议（如IKE）的一些想法。首先，让我们列出我们期望salting处理的威胁以及非威胁：
o The plain password should not be visible to a casual onlooker, as noted above. It is assumed that very often the same password is used for multiple applications, and so a password exposed allows an attacker a starting point for further attacks.
o 如上所述，普通密码不应该被随便的旁观者看到。假设多个应用程序经常使用相同的密码，因此暴露的密码使攻击者可以作为进一步攻击的起点。
o An attacker must not be able to construct lookup tables (such as the famous "rainbow tables") that enable her to discover the plain password.
o 攻击者必须无法构造使其能够发现普通密码的查找表（如著名的“彩虹表”）。
o IKE is a symmetric protocol, in the sense that any of the peers might initiate an IKE exchange to another peer. As a result, all peers must have stored credentials (passwords or password equivalents) that would enable them to set up an IKE exchange. So, an attacker that reaches the credential store would in fact be able to impersonate IKE to another peer. We believe that this reduces, but does not invalidate, the importance of salting, because of the other threats that remain.
o IKE是一种对称协议，从这个意义上讲，任何一个对等方都可以发起到另一个对等方的IKE交换。因此，所有对等方都必须具有存储的凭据（密码或等效密码），以便能够建立IKE交换。因此，到达凭据存储的攻击者实际上能够向另一个对等方模拟IKE。我们认为，这降低了盐渍的重要性，但并没有使其无效，因为还有其他威胁。
Below we present different scenarios and solutions that support password salting in this setting.
下面我们将介绍在此设置中支持密码盐析的不同场景和解决方案。
We assume that each credential is used to authenticate exactly two peers to one another; i.e., (as per the best practice), group credentials are not allowed.
我们假设每个凭证用于相互验证两个对等方；i、 例如，（根据最佳实践），不允许使用组凭据。
Despite the protocol's symmetry, there are use cases that are somewhat asymmetric. Consider the case of an organization that consists of a headquarters and branches, using a hub-and-spoke architecture. Communication sessions can be initiated by the center or by any of the branches, but only the center holds a large credential database.
尽管协议是对称的，但是有些用例是不对称的。考虑由总部和分支组成的组织使用集线器和轮辐架构的情况。通信会话可以由中心或任何分支机构发起，但只有中心拥有大型凭证数据库。
Here it would be possible to use traditional password salting,
在这里可以使用传统的密码加密，
stored password = hash(salt, password),
存储密码=散列（salt，password），
where the hash function is a symmetric hash (e.g., HMAC-SHA-256, using the salt as its key), and the salt is picked at random for each password. The salt would need to be sent in the first exchange of the protocol, regardless of which side initiates the session. Unlike
其中，散列函数是对称散列（例如，HMAC-SHA-256，使用salt作为其密钥），并且针对每个密码随机选取salt。无论哪一方发起会话，salt都需要在协议的第一次交换中发送。不像
the normal use of salted passwords, here it is the stored password, rather than the original password, that is used by the follow-on ZKPP protocol.
盐密码的正常使用，这里是存储的密码，而不是后续ZKPP协议使用的原始密码。
For the fully symmetric case, we propose a salting method based on a commutative one-way function. This is essentially a novel variant of the RSA protocol. Using this solution, all protocol peers can store the password in a salted form.
对于完全对称的情况，我们提出了一种基于交换单向函数的salt方法。这本质上是RSA协议的一个新变体。使用此解决方案，所有协议对等方都可以以盐格式存储密码。
The implementation proposed here requires a composite number n that is common to all peers. The composite number n can be generated by a trusted (third) party as n = p * q, where p and q are strong primes (i.e., p = 2 * p' + 1 and q = 2 * q' + 1, where p' and q' are also primes), and the trusted party promises not to retain a copy of the primes. Alternatively, n can be chosen randomly and tested for "small" prime factors. In the latter case, it is certainly not guaranteed that n is composed of only two primes. While this has the advantage that no one knows the factorization of n, the disadvantage is that n is likely to be significantly easier to factor.
这里提出的实现需要一个对所有对等方通用的复合数字n。可由受信任（第三方）生成组合数n，n=p*q，其中p和q是强素数（即，p=2*p'+1和q=2*q'+1，其中p'和q'也是素数），受信任方承诺不保留素数的副本。或者，可以随机选择n并测试“小”素因子。在后一种情况下，肯定不能保证n只由两个素数组成。虽然这样做的优点是没有人知道n的因式分解，但缺点是n可能更容易因式分解。
Each peer then chooses a public encryption key "e". In a simple implementation, the encryption key is generated randomly by each peer, picking a different value for each of the passwords that it stores.
然后，每个对等方选择一个公共加密密钥“e”。在一个简单的实现中，每个对等方随机生成加密密钥，为其存储的每个密码选择不同的值。
Note that although the pair (n,e) is similar to an RSA public key, the usual rules for generating "e" for the RSA protocol do not apply here, and a random "e" is sufficient. The password is hashed by a symmetric hash function H (e.g., SHA-256). Each peer i stores the two values
注意，尽管该对（n，e）类似于RSA公钥，但是用于生成RSA协议的“e”的常规规则在这里不适用，并且随机的“e”就足够了。密码由对称散列函数H（例如SHA-256）散列。每个对等i存储这两个值
e_i, H(P)^e_i (mod n),
e_i，H（P）^e_i（mod n），
where P is the original password. The values e_i are exchanged by the peers before the ZKPP protocol commences (in IKEv2-PACE, this would be in IKE_SA_INIT), and the following value is used in the ZKPP protocol run that follows, in lieu of the original password:
其中P是原始密码。在ZKPP协议开始之前，对等方交换值e_i（在IKEv2 PACE中，这将在IKE_SA_INIT中），并且在随后的ZKPP协议运行中使用以下值代替原始密码：
H(P) ^ (e_i * e_j) (mod n).
H(P)^(e_i*e_j)(mod n)。
This transformation is used as a salting mechanism only, and the salted values themselves are never sent on the wire.
此转换仅用作一种盐析机制，盐析值本身永远不会发送到导线上。
This scheme can be enhanced by basing the value "e" on each peer's identity (IDi, IDr), e.g., making it a simple hash of the identity. This eliminates the need to send "e" explicitly and additionally binds the identity of the peer with its secret.
该方案可以通过基于每个对等方的身份（IDi、IDr）的值“e”来增强，例如，使其成为身份的简单散列。这消除了显式发送“e”的需要，并且还将对等方的身份与其机密绑定在一起。
An alternative to salting is to store the plain passwords, but only for a short while. As soon as the first IKE SA is set up between two peers, the peers exchange nonces and generate a strong shared secret, based on IKE's SK_d. They now destroy the short password and replace it with the new secret.
另一种替代salt的方法是存储普通密码，但只存储一小段时间。一旦在两个对等方之间建立了第一个IKE SA，对等方就根据IKE的密钥交换当前值并生成强共享秘密。他们现在销毁短密码并用新密码替换。
This method has been added to the current protocol as an optional mechanism.
此方法已作为可选机制添加到当前协议中。
Authors' Addresses
作者地址
Dennis Kuegler Bundesamt fuer Sicherheit in der Informationstechnik (BSI) Postfach 200363 Bonn 53133 Germany
Dennis Kuegler Bundesamt fuer Sicherheit位于德国波恩53133信息技术学院（BSI）Postfach 200363
EMail: dennis.kuegler@bsi.bund.de
EMail: dennis.kuegler@bsi.bund.de
Yaron Sheffer Porticor
亚龙谢弗波蒂科酒店
EMail: yaronf.ietf@gmail.com
EMail: yaronf.ietf@gmail.com