Internet Engineering Task Force (IETF)                           S. Shin
Request for Comments: 6628                                     K. Kobara
Category: Experimental                                              AIST
ISSN: 2070-1721                                                June 2012
        
Internet Engineering Task Force (IETF)                           S. Shin
Request for Comments: 6628                                     K. Kobara
Category: Experimental                                              AIST
ISSN: 2070-1721                                                June 2012
        

Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2

IKEv2的高效增强的仅密码身份验证和密钥交换

Abstract

摘要

This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks). The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2).

本文档描述了一种高效的增强型仅密码认证和密钥交换(AugPAKE)协议,其中用户记住低熵密码,其验证器在预期服务器中注册。通常,用户密码是从一小部分字典单词中选择的,攻击者可以通过这些单词执行彻底的搜索(即离线字典攻击)。此处所述的AugPAKE协议可防止被动攻击、主动攻击和离线字典攻击(针对使用被动/主动攻击获得的消息),还可防止服务器泄露(在增强的PAKE安全性的情况下)。此外,本文档描述了如何将AugPAKE协议集成到Internet密钥交换协议版本2(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/rfc6628.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc6628.

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. Keywords ...................................................4
   2. AugPAKE Specification ...........................................4
      2.1. Underlying Group ...........................................4
      2.2. Notation ...................................................5
           2.2.1. Password Processing .................................6
      2.3. Protocol ...................................................7
           2.3.1. Initialization ......................................7
           2.3.2. Actual Protocol Execution ...........................7
   3. Security Considerations .........................................9
      3.1. General Assumptions ........................................9
      3.2. Security against Passive Attacks ..........................10
      3.3. Security against Active Attacks ...........................10
           3.3.1. Impersonation Attacks on User U ....................10
           3.3.2. Impersonation Attacks on Server S ..................11
           3.3.3. Man-in-the-Middle Attacks ..........................11
      3.4. Security against Off-line Dictionary Attacks ..............12
      3.5. Resistance to Server Compromise ...........................12
   4. Implementation Consideration ...................................13
   5. AugPAKE for IKEv2 ..............................................13
      5.1. Integration into IKEv2 ....................................13
      5.2. Payload Formats ...........................................15
           5.2.1. Notify Payload .....................................15
           5.2.2. Generic Secure Password Method Payload .............16
   6. IANA Considerations ............................................16
   7. References .....................................................16
      7.1. Normative References ......................................16
      7.2. Informative References ....................................17
   Appendix A.  Evaluation by PAKE Selection Criteria.................19
        
   1. Introduction ....................................................3
      1.1. Keywords ...................................................4
   2. AugPAKE Specification ...........................................4
      2.1. Underlying Group ...........................................4
      2.2. Notation ...................................................5
           2.2.1. Password Processing .................................6
      2.3. Protocol ...................................................7
           2.3.1. Initialization ......................................7
           2.3.2. Actual Protocol Execution ...........................7
   3. Security Considerations .........................................9
      3.1. General Assumptions ........................................9
      3.2. Security against Passive Attacks ..........................10
      3.3. Security against Active Attacks ...........................10
           3.3.1. Impersonation Attacks on User U ....................10
           3.3.2. Impersonation Attacks on Server S ..................11
           3.3.3. Man-in-the-Middle Attacks ..........................11
      3.4. Security against Off-line Dictionary Attacks ..............12
      3.5. Resistance to Server Compromise ...........................12
   4. Implementation Consideration ...................................13
   5. AugPAKE for IKEv2 ..............................................13
      5.1. Integration into IKEv2 ....................................13
      5.2. Payload Formats ...........................................15
           5.2.1. Notify Payload .....................................15
           5.2.2. Generic Secure Password Method Payload .............16
   6. IANA Considerations ............................................16
   7. References .....................................................16
      7.1. Normative References ......................................16
      7.2. Informative References ....................................17
   Appendix A.  Evaluation by PAKE Selection Criteria.................19
        
1. Introduction
1. 介绍

In the real world, many applications, such as Web mail and Internet banking/shopping/trading, require secure channels between participating parties. Such secure channels can be established by using an authentication and key exchange (AKE) protocol, which allows the involved parties to authenticate each other and to generate a temporary session key. The temporary session key is used to protect the subsequent communications between the parties.

在现实世界中,许多应用程序,如Web邮件和Internet银行/购物/交易,都需要参与方之间的安全通道。这种安全通道可以通过使用认证和密钥交换(AKE)协议来建立,该协议允许相关方相互认证并生成临时会话密钥。临时会话密钥用于保护双方之间的后续通信。

Until now, password-only AKE (called PAKE) protocols have attracted much attention because password-only authentication is very convenient to the users. However, it is not trivial to design a secure PAKE protocol due to the existence of off-line dictionary attacks on passwords. These attacks are possible since passwords are chosen from a relatively-small dictionary that allows for an attacker to perform the exhaustive searches. This problem was brought forth by Bellovin and Merritt [BM92], and many subsequent works have been conducted in the literature (see some examples in [IEEEP1363.2]). A PAKE protocol is said to be secure if the best attack an active attacker can take is restricted to the on-line dictionary attacks, which allows a guessed password to be checked only by interacting with the honest party.

迄今为止,仅密码的AKE(称为PAKE)协议因其对用户非常方便而备受关注。然而,由于对密码的离线字典攻击的存在,设计一个安全的PAKE协议并非易事。这些攻击是可能的,因为密码是从一个相对较小的字典中选择的,允许攻击者执行彻底的搜索。这个问题是由Bellovin和Merritt[BM92]提出的,并且在文献中进行了许多后续工作(参见[IEEEP1363.2]中的一些示例)。如果主动攻击者能够采取的最佳攻击仅限于在线字典攻击,则PAKE协议称为安全协议,在线字典攻击只允许通过与诚实方交互来检查猜测的密码。

An augmented PAKE protocol (e.g., [BM93], [RFC2945], [ISO]) provides extra protection for server compromise in the sense that an attacker, who obtains a password verifier from a server, cannot impersonate the corresponding user without performing off-line dictionary attacks on the password verifier. This additional security is known as "resistance to server compromise". The AugPAKE protocol described in this document is an augmented PAKE, which also achieves measurable efficiency over some previous works (i.e., SRP [RFC2945] and AMP [ISO]). We believe the following (see [SKI10] for the formal security proof): 1) The AugPAKE protocol is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and 2) It provides resistance to server compromise. At the same time, the AugPAKE protocol has similar computational efficiency to the plain Diffie-Hellman key exchange [DH76] that does not provide authentication by itself. Specifically, the user and the server need to compute 2 and 2.17 modular exponentiations, respectively, in the AugPAKE protocol. After excluding pre-computable costs, the user and the server are required to compute only 1 and 1.17 modular exponentiations, respectively. Compared with SRP [RFC2945] and AMP [ISO], the AugPAKE protocol is more efficient 1) than SRP in terms of the user's computational costs and 2) than AMP in terms of the server's computational costs.

扩充的PAKE协议(例如,[BM93]、[RFC2945]、[ISO])为服务器泄露提供了额外的保护,因为攻击者从服务器获得密码验证器,如果不对密码验证器执行离线字典攻击,就无法模拟相应的用户。这种额外的安全性称为“抵抗服务器危害”。本文件中所述的AugPAKE协议是一种增强型PAKE协议,与以前的一些工作(即SRP[RFC2945]和AMP[ISO])相比,它也实现了可测量的效率。我们相信以下内容(参见[SKI10]了解正式的安全性证明):1)AugPAKE协议能够抵御被动攻击、主动攻击和离线字典攻击(针对使用被动/主动攻击获得的消息),2)它能够抵抗服务器泄露。同时,AugPAKE协议具有与普通Diffie-Hellman密钥交换[DH76]相似的计算效率,后者本身不提供身份验证。具体而言,用户和服务器需要在AugPAKE协议中分别计算2和2.17模幂运算。排除预计算成本后,用户和服务器只需分别计算1和1.17模幂运算。与SRP[RFC2945]和AMP[ISO]相比,AugPAKE协议在用户计算成本方面比SRP更有效,在服务器计算成本方面比AMP更有效。

This document also describes how the AugPAKE protocol is integrated into IKEv2 [RFC5996].

本文档还描述了如何将AugPAKE协议集成到IKEv2[RFC5996]中。

1.1. Keywords
1.1. 关键词

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 RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。

2. AugPAKE Specification
2. 奥格帕克规范
2.1. Underlying Group
2.1. 底层组

The AugPAKE protocol can be implemented over the following group.

AugPAKE协议可以通过以下组实现。

o Let p and q be sufficiently large primes such that q is a divisor of ((p - 1) / 2), and every factor of ((p - 1) / 2) are also primes comparable to q in size. This p is called a "secure" prime. By G, we denote a multiplicative subgroup of prime order q over the field GF(p), the integers modulo p. Let g be a generator for the subgroup G so that all the subgroup elements are generated by g. The group operation is denoted multiplicatively (in modulo p).

o 设p和q是足够大的素数,使得q是((p-1)/2)的除数,((p-1)/2)的每一个因子也是与q大小相当的素数。这个p称为“安全”素数。用G表示域GF(p)上的素数阶q的乘法子群,整数模p。设g为子群g的生成器,使所有子群元素都由g生成。群运算用乘法表示(模p)。

By using a secure prime p, the AugPAKE protocol has computational efficiency gains. Specifically, it does not require the order check of elements received from the counterpart party. Note that the groups defined in Discrete Logarithm Cryptography [SP800-56A] and RFC 5114 [RFC5114] are not necessarily the above secure prime groups.

通过使用安全素数p,AugPAKE协议可以提高计算效率。具体而言,它不需要对从对方收到的元件进行订单检查。注意,离散对数加密[SP800-56A]和RFC 5114[RFC5114]中定义的组不一定是上述安全素数组。

Alternatively, one can implement the AugPAKE protocol over the following groups.

或者,可以通过以下组实施AugPAKE协议。

o Let p and q be sufficiently large primes such that p = (2 * q) + 1. This p is called a "safe" prime. By G, we denote a multiplicative subgroup of prime order q over the field GF(p), the integers modulo p. Let g be any element of G other than 1. For example, g = h^2 mod p where h is a primitive element. The group operation is denoted multiplicatively (in modulo p).

o 设p和q是足够大的素数,使得p=(2*q)+1。这个p叫做“安全”素数。用G表示域GF(p)上的素数阶q的乘法子群,整数模p。设g为g的除1以外的任何元素。例如,g=h^2 mod p,其中h是一个基本元素。群运算用乘法表示(模p)。

o Let p and q be sufficiently large primes such that q is a divisor of ((p - 1) / 2). By G, we denote a multiplicative subgroup of prime order q over the field GF(p), the integers modulo p. Let g be a generator for the subgroup G so that all the subgroup elements are generated by g. The group operation is denoted multiplicatively (in modulo p). If p is not a "secure" prime, the AugPAKE protocol MUST perform the order check of received elements.

o 设p和q是足够大的素数,使得q是((p-1)/2)的除数。用G表示域GF(p)上的素数阶q的乘法子群,整数模p。设g为子群g的生成器,使所有子群元素都由g生成。群运算用乘法表示(模p)。如果p不是“安全”素数,则AugPAKE协议必须对接收到的元素执行顺序检查。

2.2. Notation
2.2. 符号

The AugPAKE protocol is a two-party protocol where a user and a server authenticate each other and generate a session key. The following notation is used in this document:

AugPAKE协议是一个双方协议,其中用户和服务器相互验证并生成会话密钥。本文件中使用了以下符号:

U The user's identity (e.g., as defined in [RFC4282]). It is a string in {0,1}^* where {0,1}^* indicates a set of finite binary strings.

U用户身份(如[RFC4282]中的定义)。它是{0,1}^*中的一个字符串,{0,1}^*表示一组有限的二进制字符串。

S The server's identity (e.g., as defined in [RFC4282]). It is a string in {0,1}^*.

S服务器的标识(如[RFC4282]中定义的)。它是{0,1}^*中的字符串。

b = H(a) A binary string a is given as input to a secure one-way hash function H (e.g., SHA-2 family [FIPS180-3]), which produces a fixed-length output b. The hash function H maps {0,1}^* to {0,1}^k, where {0,1}^k indicates a set of binary strings of length k and k is a security parameter.

b=H(a)二进制字符串a作为安全单向散列函数H(例如,SHA-2系列[FIPS180-3])的输入,该函数产生固定长度的输出b。散列函数H将{0,1}^*映射到{0,1}^k,其中{0,1}^k表示长度为k的一组二进制字符串,k是安全参数。

b = H'(a) A binary string a is given as input to a secure one-way hash function H', which maps the input a in {0,1}^* to the output b in Z_q^*, where Z_q^* is a set of positive integers modulo prime q.

b=H'(a)二进制字符串a作为安全单向散列函数H'的输入,该函数将{0,1}^*中的输入a映射到Z_q^*中的输出b,其中Z_q^*是一组模素数q的正整数。

a | b It denotes a concatenation of binary strings a and b in {0,1}^*.

a | b表示{0,1}^*中二进制字符串a和b的串联。

0x A hexadecimal value is shown preceded by "0x".

0x十六进制值前面显示“0x”。

X * Y mod p It indicates a multiplication of X and Y modulo prime p.

它表示X和Y模素数p的乘积。

X = g^x mod p The g^x indicates a multiplication computation of g by x times. The resultant value modulo prime p is assigned to X. The discrete logarithm problem says that it is computationally hard to compute the discrete logarithm x from X, g, and p.

X=g^X mod p g^X表示g乘以X的乘法计算。模素数p的结果值被分配给X。离散对数问题表明,从X、g和p计算离散对数X在计算上很困难。

w The password remembered by the user. This password may be used as an effective password (instead of itself) in the form of H'(0x00 | U | S | w).

w用户记住的密码。此密码可以H'(0x00 | U | S | w)的形式用作有效密码(而不是其本身)。

W The password verifier registered in the server. This password verifier is computed as follows: W = g^w mod p where the user's password w is used itself, or W = g^w' mod p where the effective password w' = H'(0x00 | U | S | w) is used.

W在服务器中注册的密码验证程序。此密码验证器的计算如下:W=g^W mod p,其中用户的密码W本身使用;或W=g^W'mod p,其中使用有效密码W'=H'(0x00 | U | s | W)。

bn2bin(X) It indicates a conversion of a multiple precision integer X to the corresponding binary string. If X is an element over GF(p), its binary representation MUST have the same bit length as the binary representation of prime p.

bn2bin(X)表示将多精度整数X转换为相应的二进制字符串。如果X是GF(p)上的元素,其二进制表示必须与素数p的二进制表示具有相同的位长度。

U -> S: msg It indicates a message transmission that the user U sends a message msg to the server S.

U->S:msg表示用户U向服务器S发送消息msg的消息传输。

U: It indicates a local computation of user U (without any outgoing messages).

U:表示用户U的本地计算(没有任何传出消息)。

2.2.1. Password Processing
2.2.1. 密码处理

The input password MUST be processed according to the rules of the [RFC4013] profile of [RFC3454]. The password SHALL be considered a "stored string" per [RFC3454], and unassigned code points are therefore prohibited. The output SHALL be the binary representation of the processed UTF-8 character string. Prohibited output and unassigned code points encountered in SASLprep pre-processing SHALL cause a failure of pre-processing, and the output SHALL NOT be used with the AugPAKE protocol.

必须根据[RFC3454]的[RFC4013]配置文件的规则处理输入密码。根据[RFC3454],密码应被视为“存储字符串”,因此禁止未分配的代码点。输出应为已处理UTF-8字符串的二进制表示。SASLprep预处理中遇到的禁止输出和未分配代码点应导致预处理失败,且输出不得与AugPAKE协议一起使用。

The following table shows examples of how various character data is transformed by the rules of the [RFC4013] profile.

下表显示了[RFC4013]配置文件规则如何转换各种字符数据的示例。

   #  Input            Output     Comments
   -  -----            ------     --------
   1  I<U+00AD>X       IX         SOFT HYPHEN mapped to nothing
   2  user             user       no transformation
   3  USER             USER       case preserved, will not match #2
   4  <U+00AA>         a          output is NFKC, input in ISO 8859-1
   5  <U+2168>         IX         output is NFKC, will match #1
   6  <U+0007>                    Error - prohibited character
   7  <U+0627><U+0031>            Error - bidirectional check
        
   #  Input            Output     Comments
   -  -----            ------     --------
   1  I<U+00AD>X       IX         SOFT HYPHEN mapped to nothing
   2  user             user       no transformation
   3  USER             USER       case preserved, will not match #2
   4  <U+00AA>         a          output is NFKC, input in ISO 8859-1
   5  <U+2168>         IX         output is NFKC, will match #1
   6  <U+0007>                    Error - prohibited character
   7  <U+0627><U+0031>            Error - bidirectional check
        
2.3. Protocol
2.3. 协议

The AugPAKE protocol consists of two phases: initialization and actual protocol execution. The initialization phase SHOULD be finished in a secure manner between the user and the server, and it is performed all at once. Whenever the user and the server need to establish a secure channel, they can run the actual protocol execution through an open network (i.e., the Internet) in which an active attacker exists.

AugPAKE协议包括两个阶段:初始化和实际协议执行。初始化阶段应该在用户和服务器之间以安全的方式完成,并且一次完成。当用户和服务器需要建立安全通道时,他们可以通过存在活跃攻击者的开放网络(即互联网)运行实际协议执行。

2.3.1. Initialization
2.3.1. 初始化

U -> S: (U, W) The user U computes W = g^w' mod p, where w' is the effective password, and transmits W to the server S. The W is registered in the server as the password verifier of user U. Of course, user U just remembers password w only.

U->S:(U,W)用户U计算W=g^W'mod p,其中W'是有效密码,并将W传输到服务器S。W在服务器中注册为用户U的密码验证器。当然,用户U只记住密码W。

If resistance to server compromise is not necessary and a node needs to act as both initiator and responder, e.g., as a gateway, then the node can store w' instead of W even when it acts as server S. In either case, server S SHOULD NOT store any plaintext passwords.

如果不需要抵抗服务器破坏,并且节点需要同时充当发起方和响应方(例如,作为网关),则节点可以存储w'而不是w,即使它充当服务器S。在任何一种情况下,服务器S都不应存储任何明文密码。

As noted above, this phase SHOULD be performed securely and all at once.

如上所述,此阶段应安全地同时执行。

2.3.2. Actual Protocol Execution
2.3.2. 实际协议执行

The actual protocol execution of the AugPAKE protocol allows the user and the server to share an authenticated session key through an open network (see Figure 1).

AugPAKE协议的实际协议执行允许用户和服务器通过开放网络共享经过身份验证的会话密钥(见图1)。

   +-----------------+                              +------------------+
   |     User U      |                              |  Server S (U,W)  |
   |                 |            (U, X)            |                  |
   |                 |----------------------------->|                  |
   |                 |                              |                  |
   |                 |            (S, Y)            |                  |
   |                 |<-----------------------------|                  |
   |                 |                              |                  |
   |                 |             V_U              |                  |
   |                 |----------------------------->|                  |
   |                 |                              |                  |
   |                 |             V_S              |                  |
   |                 |<-----------------------------|                  |
   |                 |                              |                  |
   +-----------------+                              +------------------+
        
   +-----------------+                              +------------------+
   |     User U      |                              |  Server S (U,W)  |
   |                 |            (U, X)            |                  |
   |                 |----------------------------->|                  |
   |                 |                              |                  |
   |                 |            (S, Y)            |                  |
   |                 |<-----------------------------|                  |
   |                 |                              |                  |
   |                 |             V_U              |                  |
   |                 |----------------------------->|                  |
   |                 |                              |                  |
   |                 |             V_S              |                  |
   |                 |<-----------------------------|                  |
   |                 |                              |                  |
   +-----------------+                              +------------------+
        

Figure 1: Actual Protocol Execution

图1:实际协议执行

U -> S: (U, X) The user U chooses a random element x from Z_q^* and computes its Diffie-Hellman public value X = g^x mod p. The user sends the first message (U, X) to the server S.

U->S:(U,X)用户U从Z_q^*中选择一个随机元素X,并计算其Diffie-Hellman公共值X=g^X mod p。用户将第一条消息(U,X)发送到服务器S。

   S -> U: (S, Y)
      If the received X from user U is 0, 1, or -1 (mod p), server S
      MUST terminate the protocol execution.  Otherwise, the server
      chooses a random element y from Z_q^* and computes Y = (X *
      (W^r))^y mod p where r = H'(0x01 | U | S | bn2bin(X)).  Note that
      X^y * g^(w * r * y) mod p can be computed from y and (w * r * y)
      efficiently using Shamir's trick [MOV97].  Then, server S sends
      the second message (S, Y) to the user U.
        
   S -> U: (S, Y)
      If the received X from user U is 0, 1, or -1 (mod p), server S
      MUST terminate the protocol execution.  Otherwise, the server
      chooses a random element y from Z_q^* and computes Y = (X *
      (W^r))^y mod p where r = H'(0x01 | U | S | bn2bin(X)).  Note that
      X^y * g^(w * r * y) mod p can be computed from y and (w * r * y)
      efficiently using Shamir's trick [MOV97].  Then, server S sends
      the second message (S, Y) to the user U.
        

U -> S: V_U If the received Y from server S is 0, 1, or -1 (mod p), user U MUST terminate the protocol execution. Otherwise, the user computes K = Y^z mod p where z = 1 / (x + (w * r)) mod q and r = H'(0x01 | U | S | bn2bin(X)). Also, user U generates an authenticator V_U = H(0x02 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)). Then, the user sends the third message V_U to the server S.

U->S:V_如果从服务器S接收到的Y是0、1或-1(mod p),则用户U必须终止协议执行。否则,用户计算K=Y^z mod p,其中z=1/(x+(w*r))mod q和r=H'(0x01 | U | S | bn2bin(x))。此外,用户U生成验证器V|U=H(0x02 | U | S | bn2bin(X)| bn2bin(Y)| bn2bin(K))。然后,用户向服务器S发送第三条消息V_。

S -> U: V_S If the received V_U from user U is not equal to H(0x02 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)) where K = g^y mod p, server S MUST terminate the protocol execution. Otherwise, the server generates an authenticator V_S = H(0x03 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)) and a session key SK = H(0x04 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)). Then, server S sends the fourth message V_S to the user U.

S->U:V_S如果从用户U接收的V_不等于H(0x02 | U | S | bn2bin(X)| bn2bin(Y)| bn2bin(K)),其中K=g^Y mod p,服务器S必须终止协议执行。否则,服务器生成验证器V|S=H(0x03 | U | S | bn2bin(X)| bn2bin(Y)| bn2bin(K))和会话密钥SK=H(0x04 | U | S | bn2bin(X)| bn2bin(Y)| bn2bin(K))。然后,服务器S将第四条消息V_S发送给用户U。

U: If the received V_S from server S is not equal to H(0x03 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)), user U MUST terminate the protocol execution. Otherwise, the user generates a session key SK = H(0x04 | U | S | bn2bin(X) | bn2bin(Y) | bn2bin(K)).

U:如果从服务器S接收到的V|S不等于H(0x03 | U | S | bn2bin(X)| bn2bin(Y)| bn2bin(K)),则用户U必须终止协议执行。否则,用户生成会话密钥SK=H(0x04 | U | S | bn2bin(X)| bn2bin(Y)| bn2bin(K))。

In the actual protocol execution, the sequential order of message exchanges is very important to avoid any possible attacks. For example, if the server S sends the second message (S, Y) and the fourth message V_S together, any attacker can easily derive the correct password w with off-line dictionary attacks.

在实际协议执行中,消息交换的顺序对于避免任何可能的攻击非常重要。例如,如果服务器S同时发送第二条消息(S,Y)和第四条消息V_S,则任何攻击者都可以通过离线字典攻击轻松获得正确的密码w。

The session key SK, shared only if the user and the server authenticate each other successfully, MAY be generated by using a key derivation function (KDF) [SP800-108]. After generating SK, the user and the server MUST delete all the internal states (e.g., Diffie-Hellman exponents x and y) from memory.

仅当用户和服务器成功地相互认证时共享的会话密钥SK可以通过使用密钥派生函数(KDF)[SP800-108]生成。生成SK后,用户和服务器必须从内存中删除所有内部状态(例如,Diffie-Hellman指数x和y)。

   For the formal proof [SKI10] of the AugPAKE protocol, we need to
   slightly change the computation of Y (in the above S -> U: (S, Y))
   and K (in the above S -> U: V_S) as follows: Y = (X * (W^r))^y' and K
   = g^y' where y' = H'(0x05 | bn2bin(y)).
        
   For the formal proof [SKI10] of the AugPAKE protocol, we need to
   slightly change the computation of Y (in the above S -> U: (S, Y))
   and K (in the above S -> U: V_S) as follows: Y = (X * (W^r))^y' and K
   = g^y' where y' = H'(0x05 | bn2bin(y)).
        
3. Security Considerations
3. 安全考虑

This section shows why the AugPAKE protocol (i.e., the actual protocol execution) is secure against passive attacks, active attacks, and off-line dictionary attacks, and also provides resistance to server compromise.

本节说明了为什么AugPAKE协议(即,实际协议执行)对被动攻击、主动攻击和离线字典攻击是安全的,并且还提供了对服务器危害的抵抗。

3.1. General Assumptions
3.1. 一般假设

o An attacker is computationally bounded.

o 攻击者在计算上是有界的。

o Any hash functions used in the AugPAKE protocol are secure in terms of pre-image resistance (one-wayness), second pre-image resistance, and collision resistance.

o 在AugPAKE协议中使用的任何哈希函数在预映像抵抗(单向性)、第二预映像抵抗和冲突抵抗方面都是安全的。

3.2. Security against Passive Attacks
3.2. 针对被动攻击的安全性

An augmented PAKE protocol is said to be secure against passive attacks in the sense that an attacker, who eavesdrops the exchanged messages, cannot compute an authenticated session key (shared between the honest parties in the protocol).

扩充PAKE协议被认为是针对被动攻击的安全协议,因为窃听交换消息的攻击者无法计算经过身份验证的会话密钥(在协议中的诚实方之间共享)。

In the AugPAKE protocol, an attacker can get the messages (U, X), (S,Y), V_U, V_S by eavesdropping, and then wants to compute the session key SK. That is, the attacker's goal is to derive the correct K from the obtained messages X and Y, because the hash functions are secure and the only secret in the computation of SK is K = g^y mod p. Note that

在AugPAKE协议中,攻击者可以通过窃听获得消息(U,X),(S,Y),V_,V_S,然后想要计算会话密钥SK。也就是说,攻击者的目标是从获得的消息X和Y中导出正确的K,因为散列函数是安全的,并且SK计算中唯一的秘密是K=g^Y mod p。注意

X = g^x mod p and

X=g^X模p和

   Y =     (X * (W^r))^y = X^y * W^(r * y) = X^y * (g^y)^t = X^y * K^t
        
   Y =     (X * (W^r))^y = X^y * W^(r * y) = X^y * (g^y)^t = X^y * K^t
        

hold where t = w' * r mod q. Though t is determined from possible password candidates and X, the only way for the attacker to extract K from X and Y is to compute X^y. However, the probability for the attacker to compute X^y is negligible in the security parameter for the underlying groups since both x and y are random elements chosen from Z_q^*. Therefore, the AugPAKE protocol is secure against passive attacks.

当t=w'*r模q时保持。虽然t是根据可能的密码候选和X确定的,但攻击者从X和Y中提取K的唯一方法是计算X^Y。但是,攻击者在底层组的安全参数中计算X^y的概率可以忽略不计,因为X和y都是从Z_q^*中选择的随机元素。因此,AugPAKE协议可以抵抗被动攻击。

3.3. Security against Active Attacks
3.3. 针对主动攻击的安全性

An augmented PAKE protocol is said to be secure against active attacks in the sense that an attacker, who completely controls the exchanged messages, cannot compute an authenticated session key (shared with the honest party in the protocol) with the probability better than that of on-line dictionary attacks. In other words, the probability for an active attacker to compute the session key is restricted by the on-line dictionary attacks where it grows linearly to the number of interactions with the honest party.

扩展的PAKE协议被认为是针对主动攻击的安全协议,因为完全控制交换消息的攻击者无法以比在线字典攻击更好的概率计算经过身份验证的会话密钥(与协议中的诚实方共享)。换句话说,主动攻击者计算会话密钥的概率受到在线字典攻击的限制,在线字典攻击与诚实方的交互次数成线性增长。

In the AugPAKE protocol, the user (respectively, the server) computes the session key SK only if the received authenticator V_S (respectively, V_U) is valid. There are three cases to be considered in the active attacks.

在AugPAKE协议中,用户(分别为服务器)仅当接收到的验证器V_S(分别为V_U)有效时才计算会话密钥SK。在主动攻击中有三种情况需要考虑。

3.3.1. Impersonation Attacks on User U
3.3.1. 对用户U的模拟攻击

When an attacker impersonates the user U, the attacker can compute the same SK (to be shared with the server S) only if the authenticator V_U is valid. For a valid authenticator V_U, the attacker has to compute the correct K from X and Y because the hash

当攻击者模拟用户U时,仅当验证器V_有效时,攻击者才能计算相同的SK(与服务器S共享)。对于有效的验证器V_,攻击者必须从X和Y计算正确的K,因为散列

functions are secure. In this impersonation attack, the attacker of course knows the discrete logarithm x of X and guesses a password w'' from the password dictionary. So, the probability for the attacker to compute the correct K is bounded by the probability of w = w''. That is, this impersonation attack is restricted by the on-line dictionary attacks where the attacker can try a guessed password communicating with the honest server S. Therefore, the AugPAKE protocol is secure against impersonation attacks on user U.

功能是安全的。在这种模拟攻击中,攻击者当然知道x的离散对数x,并从密码字典中猜测密码w“”。因此,攻击者计算正确K的概率以w=w“”的概率为界。也就是说,这种模拟攻击受到在线字典攻击的限制,攻击者可以尝试猜测与诚实服务器S通信的密码。因此,AugPAKE协议对用户U的模拟攻击是安全的。

3.3.2. Impersonation Attacks on Server S
3.3.2. 服务器上的模拟攻击

When an attacker impersonates the server S, the attacker can compute the same SK (to be shared with the user U) only if the authenticator V_S is valid. For a valid authenticator V_S, the attacker has to compute the correct K from X and Y because the hash functions are secure. In this impersonation attack, the attacker chooses a random element y and guesses a password w'' from the password dictionary so that

当攻击者模拟服务器时,仅当验证器V_S有效时,攻击者才能计算相同的SK(与用户U共享)。对于有效的验证器V_S,攻击者必须从X和Y计算正确的K,因为散列函数是安全的。在此模拟攻击中,攻击者选择随机元素y并从密码字典中猜测密码w“”,以便

   Y =     (X * (W'^r))^y = X^y * W'^(r * y) = X^y * (g^y)^t'
        
   Y =     (X * (W'^r))^y = X^y * W'^(r * y) = X^y * (g^y)^t'
        

where t' = w'' * r mod q. The probability for the attacker to compute the correct K is bounded by the probability of w = w''. Also, the attacker knows whether the guessed password is equal to w or not by seeing the received authenticator V_U. However, when w is not equal to w'', the probability for the attacker to compute the correct K is negligible in the security parameter for the underlying groups since the attacker has to guess the discrete logarithm x (chosen by user U) as well. That is, this impersonation attack is restricted by the on-line dictionary attacks where the attacker can try a guessed password communicating with the honest user U. Therefore, the AugPAKE protocol is secure against impersonation attacks on server S.

其中t'=w'*r mod q。攻击者计算正确K的概率以w=w“”的概率为界。此外,攻击者通过查看收到的验证器V_知道猜测的密码是否等于w。但是,当w不等于w''时,攻击者在基础组的安全参数中计算正确K的概率可以忽略不计,因为攻击者必须猜测离散对数x(由用户U选择)。也就是说,此模拟攻击受到在线字典攻击的限制,攻击者可以尝试猜测密码与诚实用户U通信。因此,AugPAKE协议对服务器S上的模拟攻击是安全的。

3.3.3. Man-in-the-Middle Attacks
3.3.3. 中间人攻击

When an attacker performs the man-in-the-middle attack, the attacker can compute the same SK (to be shared with the user U or the server S) only if one of the authenticators V_U, V_S is valid. Note that if the attacker relays the exchanged messages honestly, it corresponds to the passive attacks. In order to generate a valid authenticator V_U or V_S, the attacker has to compute the correct K from X and Y because the hash functions are secure. So, the attacker is in the same situation as discussed above. Though the attacker can test two passwords (one with user U and the other with server S), it does not change the fact that this attack is restricted by the on-line dictionary attacks where the attacker can try a guessed password

当攻击者执行中间人攻击时,仅当其中一个验证器V_,V_S有效时,攻击者才能计算相同的SK(与用户U或服务器S共享)。请注意,如果攻击者诚实地转发交换的消息,则它对应于被动攻击。为了生成有效的验证器V_或V_S,攻击者必须从X和Y计算正确的K,因为散列函数是安全的。因此,攻击者的情况与上面讨论的相同。尽管攻击者可以测试两个密码(一个使用用户U,另一个使用服务器S),但这并不会改变这样一个事实,即该攻击受到在线字典攻击的限制,攻击者可以在该攻击中尝试猜测密码

communicating with the honest party. Therefore, the AugPAKE protocol is also secure against man-in-the-middle attacks.

与诚实的一方沟通。因此,AugPAKE协议也可以防止中间人攻击。

3.4. Security against Off-line Dictionary Attacks
3.4. 针对离线字典攻击的安全性

An augmented PAKE protocol is said to be secure against off-line dictionary attacks in the sense that an attacker, who completely controls the exchanged messages, cannot reduce the possible password candidates better than on-line dictionary attacks. Note that in the on-line dictionary attacks, an attacker can test one guessed password by running the protocol execution (i.e., communicating with the honest party).

扩充PAKE协议被认为是针对离线字典攻击的安全协议,因为完全控制交换消息的攻击者无法比在线字典攻击更好地减少可能的密码候选。请注意,在在线字典攻击中,攻击者可以通过运行协议执行(即与诚实方通信)来测试一个猜测的密码。

As discussed in Section 3.2, an attacker in the passive attacks does not compute X^y (and the correct K = g^y mod p) from the obtained messages X, Y. This security analysis also indicates that, even if the attacker can guess a password, the K is derived independently from the guessed password. Next, we consider an active attacker whose main goal is to perform the off-line dictionary attacks in the AugPAKE protocol. As in Section 3.3, the attacker can 1) test one guessed password by impersonating the user U or the server S, or 2) test two guessed passwords by impersonating the server S (to the honest user U) and impersonating the user U (to the honest server S) in the man-in-the-middle attacks. Whenever the honest party receives an invalid authenticator, the party terminates the actual protocol execution without sending any message. In fact, this is important to prevent an attacker from testing more than one password in the active attacks. Since passive attacks and active attacks cannot remove the possible password candidates more efficiently than on-line dictionary attacks, the AugPAKE protocol is secure against off-line dictionary attacks.

如第3.2节所述,被动攻击中的攻击者不会根据获得的消息X,y计算X^y(以及正确的K=g^y mod p)。该安全性分析还表明,即使攻击者能够猜测密码,K也独立于猜测的密码。接下来,我们考虑一个主动攻击者,其主要目标是执行OffPAKE协议中的离线字典攻击。如第3.3节所述,攻击者可以1)通过模拟用户U或服务器S测试一个猜测密码,或2)通过模拟服务器S(对诚实用户U)和模拟用户U(对诚实服务器S)在中间人攻击中测试两个猜测密码。每当诚实的一方收到无效的验证器时,该方就会终止实际的协议执行,而不发送任何消息。事实上,这对于防止攻击者在主动攻击中测试多个密码非常重要。由于被动攻击和主动攻击无法比在线字典攻击更有效地删除可能的候选密码,因此AugPAKE协议可以安全地抵御离线字典攻击。

3.5. Resistance to Server Compromise
3.5. 对服务器危害的抵抗

We consider an attacker who has obtained a (user's) password verifier from a server. In the (augmented) PAKE protocols, there are two limitations [BJKMRSW00]: 1) the attacker can find out the correct password from the password verifier with the off-line dictionary attacks because the verifier has the same entropy as the password; and 2) if the attacker impersonates the server with the password verifier, this attack is always possible because the attacker has enough information to simulate the server. An augmented PAKE protocol is said to provide resistance to server compromise in the sense that the attacker cannot impersonate the user without performing off-line dictionary attacks on the password verifier.

我们考虑攻击者已经从服务器获得了(用户的)密码验证器。在(增强的)PAKE协议中,有两个限制[BJKMRSW00]:1)攻击者可以通过离线字典攻击从密码验证器中找到正确的密码,因为验证器与密码具有相同的熵;2)如果攻击者使用密码验证器模拟服务器,则此攻击始终是可能的,因为攻击者有足够的信息来模拟服务器。据说,一个增强的PAKE协议可以提供对服务器危害的抵抗,即攻击者在不对密码验证器执行离线字典攻击的情况下无法模拟用户。

In order to show resistance to server compromise in the AugPAKE protocol, we consider an attacker who has obtained the password

为了在OujPakes协议中显示出对服务器妥协的抵抗,我们考虑了一个已经获得密码的攻击者。

verifier W and then tries to impersonate the user U without off-line dictionary attacks on W. As a general attack, the attacker chooses two random elements c and d from Z_q^*, and computes

验证器W然后尝试模拟用户U,而不对W进行离线字典攻击。作为一般攻击,攻击者从Z_q^*中选择两个随机元素c和d,并计算

   X =     (g^c) * (W^d) mod p
        
   X =     (g^c) * (W^d) mod p
        

and sends the first message (U, X) to the server S. In order to impersonate user U successfully, the attacker has to compute the correct K = g^y mod p where y is randomly chosen by server S. After receiving Y from the server, the attacker's goal is to find out a value e satisfying Y^e = K mod p. That is,

并向服务器S发送第一条消息(U,X)。为了成功模拟用户U,攻击者必须计算正确的K=g^y mod p,其中y由服务器S随机选择。从服务器接收到y后,攻击者的目标是找出满足y^e=K mod p的值e。就是,

log_g (Y^e) = log_g K mod q

log_g(Y^e)=log_g K mod q

            (c + (w' * d) + (w' * r)) * y * e = y mod q
        
            (c + (w' * d) + (w' * r)) * y * e = y mod q
        
            (c + w' * (d + r)) * e = 1 mod q
        
            (c + w' * (d + r)) * e = 1 mod q
        

where log_g K indicates the logarithm of K to the base g. Since there is no off-line dictionary attacks on W, the above solution is that e = 1 / c mod q and d = -r mod q. However, the latter is not possible since r is determined by X (i.e., r = H'(0x01 | U | S | bn2bin(X))) and H' is a secure hash function. Therefore, the AugPAKE protocol provides resistance to server compromise.

其中log_g K表示K与基g的对数。由于W上没有离线字典攻击,上述解决方案是e=1/c mod q和d=-r mod q。然而,后者是不可能的,因为r由X确定(即r=H’(0x01 | U | S | bn2bin(X)),并且H’是一个安全的散列函数。因此,AugPAKE协议提供了对服务器危害的抵抗。

4. Implementation Consideration
4. 实施考虑

As discussed in Section 3, the AugPAKE protocol is secure against passive attacks, active attacks, and off-line dictionary attacks, and provides resistance to server compromise. However, an attacker in the on-line dictionary attacks can check whether one password (guessed from the password dictionary) is correct or not by interacting with the honest party. Let N be the number of possible passwords within a dictionary. Certainly, the attacker's success probability grows with the probability of (I / N) where I is the number of interactions with the honest party. In order to provide a reasonable security margin, implementation SHOULD take a countermeasure to the on-line dictionary attacks. For example, it would take about 90 years to test 2^(25.5) passwords with a one minute lock-out for 3 failed password guesses (see Appendix A in [SP800-63]).

如第3节所述,AugPAKE协议可抵御被动攻击、主动攻击和离线字典攻击,并可抵抗服务器危害。但是,在线字典攻击中的攻击者可以通过与诚实方交互来检查一个密码(从密码字典猜测)是否正确。设N为字典中可能的密码数。当然,攻击者的成功概率随着(I/N)的概率增加而增加,其中I是与诚实方的交互次数。为了提供合理的安全余量,实现应该对在线字典攻击采取对策。例如,测试2^(25.5)个密码需要大约90年的时间,一分钟锁定3次密码猜测失败(见[SP800-63]中的附录a)。

5. AugPAKE for IKEv2
5. IKEv2的AugPAKE
5.1. Integration into IKEv2
5.1. 集成到IKEv2中

IKE is a primary component of IPsec in order to provide mutual authentication and establish security associations between two peers.

IKE是IPsec的主要组件,用于提供相互身份验证并在两个对等方之间建立安全关联。

The AugPAKE protocol, described in Section 2, can be easily integrated into IKEv2 [RFC5996] as a "weak" pre-shared key authentication method (see Figure 2). This integrated protocol preserves the IKEv2 structure and security guarantees (e.g., identity protection). Note that the AugPAKE protocol can be used in three scenarios for IKEv2: "Security Gateway to Security Gateway Tunnel", "Endpoint-to-Endpoint Transport", and "Endpoint to Security Gateway Tunnel".

第2节中描述的AugPAKE协议可以很容易地集成到IKEv2[RFC5996]中,作为一种“弱”预共享密钥身份验证方法(见图2)。该集成协议保留了IKEv2结构和安全保证(例如,身份保护)。请注意,AugPAKE协议可用于IKEv2的三种场景:“安全网关到安全网关隧道”、“端点到端点传输”和“端点到安全网关隧道”。

    Initiator                               Responder
   -----------                             -----------
        
    Initiator                               Responder
   -----------                             -----------
        

IKE_SA_INIT:

IKE_SA_INIT:

HDR, SAi1, KEi, Ni, N(SECURE_PASSWORD_METHODS) --> <-- HDR, SAr1, KEr, Nr, N(SECURE_PASSWORD_METHODS)

HDR、SAi1、KEi、Ni、N(安全密码方法)-><--HDR、SAr1、KEr、Nr、N(安全密码方法)

IKE_AUTH:

IKE_AUTH:

    HDR, SK {IDi, GSPM(PVi), [IDr,]
             SAi2, TSi, TSr}        -->
                                    <--  HDR, SK {IDr, GSPM(PVr)}
    HDR, SK {AUTHi}                 -->
                                    <--  HDR, SK {AUTHr, SAr2, TSi, TSr}
        
    HDR, SK {IDi, GSPM(PVi), [IDr,]
             SAi2, TSi, TSr}        -->
                                    <--  HDR, SK {IDr, GSPM(PVr)}
    HDR, SK {AUTHi}                 -->
                                    <--  HDR, SK {AUTHr, SAr2, TSi, TSr}
        

Figure 2: AugPAKE into IKEv2

图2:IKEv2中的AugPAKE

The changes from IKEv2 are summarized as follows:

IKEv2的变化总结如下:

o In addition to IKEv2, one round trip is added.

o 除IKEv2外,还增加了一个往返行程。

o The initiator (respectively, the responder) sends an N(SECURE_PASSWORD_METHODS) notification to indicate its willingness to use AugPAKE in the IKE_SA_INIT exchange.

o 发起者(分别是响应者)发送N(安全密码方法)通知,以表明其愿意在IKE_SA_INIT交换中使用AugPAKE。

o The added values GSPM(PVi) and GSPM(PVr) in the IKE_AUTH exchange correspond to X and Y of the AugPAKE protocol in Section 2, respectively.

o IKE_认证交换中的附加值GSPM(PVi)和GSPM(PVr)分别对应于第2节中的AugPAKE协议的X和Y。

o From K (represented as an octet string) derived in Section 2, the AUTH values in the IKE_AUTH exchange are computed as

o 根据第2节中导出的K(表示为八位字节字符串),IKE_AUTH交换中的AUTH值计算为

         AUTHi = prf( prf(K, "AugPAKE for IKEv2"),
         <InitiatorSignedOctets> | GSPM(PVi) | GSPM(PVr) | IDi | IDr)
        
         AUTHi = prf( prf(K, "AugPAKE for IKEv2"),
         <InitiatorSignedOctets> | GSPM(PVi) | GSPM(PVr) | IDi | IDr)
        
         AUTHr = prf( prf(K, "AugPAKE for IKEv2"),
         <ResponderSignedOctets> | GSPM(PVr) | GSPM(PVi) | IDr | IDi)
        
         AUTHr = prf( prf(K, "AugPAKE for IKEv2"),
         <ResponderSignedOctets> | GSPM(PVr) | GSPM(PVi) | IDr | IDi)
        
5.2. Payload Formats
5.2. 有效载荷格式
5.2.1. Notify Payload
5.2.1. 通知有效载荷

The Notify Payload N(SECURE_PASSWORD_METHODS) [RFC6467], indicating a willingness to use AugPAKE in the IKE_SA_INIT exchange, is defined as follows:

通知有效负载N(安全密码方法)[RFC6467]表示愿意在IKE_SA_INIT交换中使用AugPAKE,定义如下:

                        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                       ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

As in [RFC5996], the Protocol ID and SPI Size SHALL be set to zero and, therefore, the SPI field SHALL be empty. The Notify Message Type will be 16424 [RFC6467].

与[RFC5996]中一样,协议ID和SPI大小应设置为零,因此SPI字段应为空。通知消息类型为16424[RFC6467]。

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 (i.e., for AugPAKE here) inside the Notification Data field.

响应Notify有效负载在通知数据字段中正好包含一个16位安全密码方法编号(即,此处适用于AugPAKE)。

5.2.2. Generic Secure Password Method Payload
5.2.2. 通用安全密码方法有效载荷

The Generic Secure Password Method (GSPM) Payload, denoted GSPM(PV) in Section 5.1, is defined as follows:

通用安全密码方法(GSPM)有效载荷,在第5.1节中表示为GSPM(PV),定义如下:

                        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 GSPM Payload Type will be 49 [RFC6467].
        
                        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 GSPM Payload Type will be 49 [RFC6467].
        

Since the GSPM(PV) value is a group element, the encoded octet string is actually used in the "Data Specific to the Secure Password Method" field.

由于GSPM(PV)值是一个组元素,编码的八位字节字符串实际上用于“特定于安全密码方法的数据”字段。

6. IANA Considerations
6. IANA考虑

IANA has assigned value 2 to the method name "AugPAKE" from the "IKEv2 Secure Password Methods" registry in [IKEV2-IANA].

IANA已从[IKEv2-IANA]中的“IKEv2安全密码方法”注册表将值2分配给方法名“AugPAKE”。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[FIPS180-3] Information Technology Laboratory, "Secure Hash Standard (SHS)", NIST FIPS Publication 180-3, October 2008, <http://csrc.nist.gov/publications/fips/ fips180-3/fips180-3_final.pdf>.

[FIPS180-3]信息技术实验室,“安全哈希标准(SHS)”,NIST FIPS出版物180-3,2008年10月<http://csrc.nist.gov/publications/fips/ fips180-3/fips180-3_final.pdf>。

[IKEV2-IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters>.

[IKEV2-IANA]IANA,“互联网密钥交换版本2(IKEV2)参数”<http://www.iana.org/assignments/ikev2-parameters>.

[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月。

[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月。

[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.

[RFC4282]Aboba,B.,Beadles,M.,Arkko,J.,和P.Erenen,“网络访问标识符”,RFC 42822005年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月。

[SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions (Revised)", NIST Special Publication 800-108, October 2009, <http://csrc.nist.gov/publications/ nistpubs/800-108/sp800-108.pdf>.

[SP800-108]Chen,L.“使用伪随机函数进行密钥推导的建议(修订版)”,NIST特别出版物800-108,2009年10月<http://csrc.nist.gov/publications/ nistpubs/800-108/sp800-108.pdf>。

7.2. Informative References
7.2. 资料性引用

[BJKMRSW00] Bellare, M., Jablon, D., Krawczyk, H., MacKenzie, P., Rogaway, P., Swaminathan, R., and T. Wu, "Proposal for P1363 Study Group on Password-Based Authenticated-Key-Exchange Methods", IEEE P1363.2: Password-Based Public-Key Cryptography, Submissions to IEEE P1363.2 , February 2000, <http://grouper.ieee.org/ groups/1363/passwdPK/contributions/p1363-pw.pdf>.

[BJKMRSW00]Bellare,M.,Jablon,D.,Krawczyk,H.,MacKenzie,P.,Rogaway,P.,Swaminathan,R.,和T.Wu,“关于基于密码的认证密钥交换方法的P1363研究小组的提案”,IEEE P1363.2:基于密码的公钥密码术,提交给IEEE P1363.2,2000年2月, <http://grouper.ieee.org/ groups/1363/passwdPK/contributions/p1363 pw.pdf>。

[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-based Protocols Secure against Dictionary Attacks", Proceedings of the IEEE Symposium on Security and Privacy, IEEE Computer Society, 1992.

[BM92]Bellovin,S.和M.Merritt,“加密密钥交换:基于密码的协议防止字典攻击”,IEEE安全和隐私研讨会论文集,IEEE计算机学会,1992年。

[BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: A Password-based Protocol Secure against Dictionary Attacks and Password File Compromise", Proceedings of the 1st ACM Conference on Computer and Communication Security, ACM Press, 1993.

[BM93]Bellovin,S.和M.Merritt,“增强加密密钥交换:防止字典攻击和密码文件泄露的基于密码的协议”,第一届ACM计算机和通信安全会议记录,ACM出版社,1993年。

[DH76] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory Volume IT-22, Number 6, 1976.

[DH76]Diffie,W.和M.Hellman,“密码学的新方向”,IEEE信息论交易卷IT-22,第6期,1976年。

[H10] Harkins, D., "Password-Based Authentication in IKEv2: Selection Criteria and Considerations", Work in Progress, October 2010.

[H10]Harkins,D.,“IKEv2中基于密码的认证:选择标准和注意事项”,正在进行的工作,2010年10月。

[IEEEP1363.2] IEEE P1363.2, "Password-Based Public-Key Cryptography", Submissions to IEEE P1363.2 , <http://grouper.ieee.org/ groups/1363/passwdPK/submissions.html>.

[IEEEP1363.2]IEEE P1363.2,“基于密码的公钥密码术”,提交给IEEE P1363.2<http://grouper.ieee.org/ groups/1363/passwdPK/submissions.html>。

[ISO] ISO/IEC JTC 1/SC 27 11770-4, "Information technology -- Security techniques -- Key management -- Part 4: Mechanisms based on weak secrets", April 2006, <http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=39723>.

[ISO]ISO/IEC JTC 1/SC 27 11770-4,“信息技术——安全技术——密钥管理——第4部分:基于弱机密的机制”,2006年4月<http://www.iso.org/iso/iso_catalogue/catalogue_tc/ 目录\u detail.htm?csnumber=39723>。

[MOV97] Menezes, A., Oorschot, P., and S. Vanstone, "Simultaneous Multiple Exponentiation", in Handbook of Applied Cryptography, CRC Press, 1997.

[MOV97]Menezes,A.,Oorschot,P.,和S.Vanstone,“同时多重求幂”,应用密码学手册,CRC出版社,1997年。

[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.

[RFC2945]Wu,T.,“SRP认证和密钥交换系统”,RFC 29452000年9月。

[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.

[RFC5114]Lepinski,M.和S.Kent,“与IETF标准一起使用的其他Diffie-Hellman组”,RFC 5114,2008年1月。

[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月。

[SKI10] Shin, S., Kobara, K., and H. Imai, "Security Proof of AugPAKE", Cryptology ePrint Archive: Report 2010/334, June 2010, <http://eprint.iacr.org/2010/334>.

[SKI10]Shin,S.,Kobara,K.和H.Imai,“AugPAKE的安全证明”,密码学电子打印档案:报告2010/3342010年6月<http://eprint.iacr.org/2010/334>.

[SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication 800-56A, March 2007, <http://csrc.nist.gov/ publications/nistpubs/800-56A/ SP800-56A_Revision1_Mar08-2007.pdf>.

[SP800-56A]Barker,E.,Johnson,D.,和M.Smid,“使用离散对数加密的成对密钥建立方案的建议(修订版)”,NIST特别出版物800-56A,2007年3月<http://csrc.nist.gov/ 出版物/nistpubs/800-56A/SP800-56A\u修订1\u Mar08-2007.pdf>。

[SP800-63] Burr, W., Dodson, D., and W. Polk, "Electronic Authentication Guideline", NIST Special Publication 800-63 Version 1.0.2, April 2006, <http://csrc.nist.gov/publications/ nistpubs/800-63/SP800-63V1_0_2.pdf>.

[SP800-63]Burr,W.,Dodson,D.,和W.Polk,“电子认证指南”,NIST特别出版物800-63版本1.0.2,2006年4月<http://csrc.nist.gov/publications/ nistpubs/800-63/SP800-63V1\u 0\u 2.pdf>。

Appendix A. Evaluation by PAKE Selection Criteria
附录A.根据PAKE选择标准进行评估

Below is a self-evaluation of the AugPAKE protocol following PAKE selection criteria [H10].

以下是根据PAKE选择标准[H10]对AugPAKE方案的自我评估。

SEC1: AugPAKE is zero knowledge (password) proof. It is secure against passive/active/off-line dictionary attacks. It is also resistant to server-compromise impersonation attacks.

第1条:AugPAKE是零知识(密码)证明。它可以防止被动/主动/离线字典攻击。它还可以抵御服务器入侵模拟攻击。

SEC2: AugPAKE provides Perfect Forward Secrecy (PFS) and is secure against Denning-Sacco attack.

SEC2:AugPAKE提供了完美的前向保密性(PFS),并且能够抵御Denning Sacco攻击。

SEC3: IKEv2 identity protection is preserved.

SEC3:IKEv2身份保护被保留。

SEC4: Any cryptographically secure Diffie-Hellman groups can be used.

SEC4:可以使用任何加密安全的Diffie-Hellman组。

SEC5: The formal security proof of AugPAKE can be found at [SKI10].

SEC5:AugPAKE的正式安全证明可在[SKI10]中找到。

SEC6: AugPAKE can be easily used with strong credentials.

SEC6:AugPAKE可以很容易地与强大的凭证一起使用。

SEC7: In the case of server compromise, an attacker has to perform off-line dictionary attacks while computing modular exponentiation with a password candidate.

SEC7:在服务器受损的情况下,攻击者必须在使用候选密码计算模幂运算时执行离线字典攻击。

SEC8: AugPAKE is secure regardless of the transform negotiated by IKEv2.

SEC8:AugPAKE是安全的,无论IKEv2协商的转换如何。

IPR1: AugPAKE was publicly disclosed on Oct. 2008.

IPR1:AugPAKE于2008年10月公开披露。

IPR2: AIST applied for a patent in Japan on July 10, 2008. AIST would provide royal-free license of AugPAKE.

IPR2:AIST于2008年7月10日在日本申请了专利。AIST将提供AugPAKE的皇家免费许可证。

   IPR3: IPR disclosure (see https://datatracker.ietf.org/ipr/1284/)
        
   IPR3: IPR disclosure (see https://datatracker.ietf.org/ipr/1284/)
        

MISC1: AugPAKE adds one round trip to IKEv2.

杂项1:AugPAKE向IKEv2添加了一次往返。

MISC2: The initiator needs to compute only 2 modular exponentiation computations while the responder needs to compute 2.17 modular exponentiation computations. AugPAKE needs to exchange 2 group elements and 2 hash values. This is almost the same computation/communication costs as the plain Diffie-Hellman (DH) key exchange. If we use a large (e.g., 2048/3072-bits) parent group, the hash size would be relatively small.

MISC2:发起方只需要计算2次模幂运算,而响应方需要计算2.17次模幂运算。AugPAKE需要交换2个组元素和2个哈希值。这与普通Diffie-Hellman(DH)密钥交换的计算/通信成本几乎相同。如果我们使用大的(例如2048/3072位)父组,则散列大小将相对较小。

MISC3: AugPAKE has the same performance for any type of secret.

MISC3:AugPAKE对任何类型的秘密都有相同的性能。

MISC4: Internationalization of character-based passwords can be supported.

杂项4:可以支持基于字符的密码国际化。

MISC5: AugPAKE can be implemented over any ECP (Elliptic Curve Group over GF[P]), EC2N (Elliptic Curve Group over GF[2^N]), and MODP (Modular Exponentiation Group) groups.

MISC5:AugPAKE可以在任意ECP(GF[P]上的椭圆曲线群)、EC2N(GF[2^N]上的椭圆曲线群)和MODP(模幂群)群上实现。

MISC6: AugPAKE has request/response nature of IKEv2.

杂项6:AugPAKE具有IKEv2的请求/响应性质。

MISC7: No additional negotiation is needed.

杂项7:无需额外协商。

MISC8: No Trusted Third Party (TTP) and clock synchronization

MISC8:无可信第三方(TTP)和时钟同步

MISC9: No additional primitive (e.g., Full Domain Hashing (FDH) and/or ideal cipher) is needed.

MISC9:不需要额外的原语(例如,全域哈希(FDH)和/或理想密码)。

MISC10: As above, AugPAKE can be implemented over any ECP/EC2N groups.

杂项10:如上所述,AugPAKE可以在任何ECP/EC2N组上实现。

MISC11: Easy implementation. We already implemented AugPAKE and have been testing in AIST.

杂项11:易于实现。我们已经实现了AugPAKE,并在AIST中进行了测试。

Authors' Addresses

作者地址

SeongHan Shin AIST Central 2, 1-1-1, Umezono Tsukuba, Ibaraki 305-8568 JP

茨城县梅佐诺筑波市城汉新AIST中心2号,1-1-1,邮编305-8568 JP

   Phone: +81 29-861-2670
   EMail: seonghan.shin@aist.go.jp
        
   Phone: +81 29-861-2670
   EMail: seonghan.shin@aist.go.jp
        

Kazukuni Kobara AIST

Kazukuni Kobara AIST

   EMail: kobara_conf@m.aist.go.jp
        
   EMail: kobara_conf@m.aist.go.jp