Independent Submission V. Cakulev
Request for Comments: 6539 G. Sundaram
Category: Informational I. Broustis
ISSN: 2070-1721 Alcatel Lucent
March 2012
Independent Submission V. Cakulev
Request for Comments: 6539 G. Sundaram
Category: Informational I. Broustis
ISSN: 2070-1721 Alcatel Lucent
March 2012
IBAKE: Identity-Based Authenticated Key Exchange
IBAKE：基于身份的认证密钥交换
Abstract
摘要
Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure (PKI) to support certificate management. The emerging field of Identity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility. However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol. IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy.
基于公钥方法的密码协议传统上是基于证书和公钥基础设施（PKI）来支持证书管理的。基于身份的加密（IBE）协议的新兴领域允许通过私钥生成器（PKG）简化基础设施需求，同时提供相同的灵活性。然而，IBE方法的一个重要限制是PKG可能最终成为事实上的密钥托管服务器，从而产生不良后果。另一个观察到的缺陷是缺乏通信方的相互认证。本文档规定了基于身份的认证密钥交换（IBAKE）协议。IBAKE不存在密钥托管问题，此外还提供了相互认证以及完美的前向和后向保密性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc6539.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6539.
Independent Submissions Editor Note
独立意见书编者注
This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol. Due to its specialized nature, this document experienced limited review within the Internet Community. Readers of this RFC should carefully evaluate its value for implementation and deployment.
本文档规定了基于身份的认证密钥交换（IBAKE）协议。由于其专业性质，本文件在互联网社区内的审查有限。本RFC的读者应仔细评估其实施和部署价值。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
2.1. IBE: Definition ............................................3
2.2. Abbreviations ..............................................3
2.3. Conventions ................................................4
3. Identity-Based Authenticated Key Exchange .......................5
3.1. Overview ...................................................5
3.2. IBAKE Message Exchange .....................................6
3.3. Discussion .................................................7
4. Security Considerations .........................................9
4.1. General ....................................................9
4.2. IBAKE Protocol ............................................10
5. References .....................................................12
5.1. Normative References ......................................12
5.2. Informative References ....................................12
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
2.1. IBE: Definition ............................................3
2.2. Abbreviations ..............................................3
2.3. Conventions ................................................4
3. Identity-Based Authenticated Key Exchange .......................5
3.1. Overview ...................................................5
3.2. IBAKE Message Exchange .....................................6
3.3. Discussion .................................................7
4. Security Considerations .........................................9
4.1. General ....................................................9
4.2. IBAKE Protocol ............................................10
5. References .....................................................12
5.1. Normative References ......................................12
5.2. Informative References ....................................12
Authenticated key agreements are cryptographic protocols where two or more participants authenticate each other and agree on key material used for securing future communication. These protocols could be symmetric key or asymmetric public-key protocols. Symmetric-key protocols require an out-of-band security mechanism to bootstrap a secret key. On the other hand, public-key protocols traditionally require certificates and a large-scale Public Key Infrastructure (PKI). Clearly, public-key methods are more flexible; however, the requirement for certificates and a large-scale PKI have proved to be challenging. In particular, efficient methods to support large-scale certificate revocation and management have proved to be elusive.
认证密钥协议是一种加密协议，其中两个或多个参与者相互认证，并就用于确保未来通信安全的密钥材料达成一致。这些协议可以是对称密钥或非对称公钥协议。对称密钥协议需要带外安全机制来引导密钥。另一方面，公钥协议传统上需要证书和大规模公钥基础设施（PKI）。显然，公钥方法更加灵活；然而，事实证明，对证书和大规模PKI的要求具有挑战性。特别是，支持大规模证书撤销和管理的有效方法已被证明是难以捉摸的。
Recently, Identity-Based Encryption (IBE) protocols have been proposed as a viable alternative to public-key methods by replacing the PKI with a Private-Key Generator (PKG). However, one significant limitation of IBE methods is that the PKG can end up being a de facto
最近，基于身份的加密（IBE）协议被提出作为公钥方法的可行替代方案，用私钥生成器（PKG）代替PKI。然而，IBE方法的一个重要限制是PKG最终可能成为事实上的
key escrow entity (i.e., an entity that has sufficient information to decrypt communicated data), with undesirable consequences. Another limitation is a lack of mutual authentication between communicating parties. This document specifies an Identity-Based Authenticated Key Encryption (IBAKE) protocol that does not suffer from the key escrow problem and that provides mutual authentication. In addition, the scheme described in this document allows the use of time-bound public identities and corresponding public and private keys, resulting in automatic expiration of private keys at the end of a time span indicated in the identity itself. With the self-expiration of the public identities, the traditional real-time validity verification and revocation procedures used with certificates are not required. For example, if the public identity is bound to one day, then, at the end of the day, the public/private key pair issued to this peer will simply not be valid anymore. Nevertheless, just as with public-key-based certificate systems, if there is a need to revoke keys before the designated expiry time, communication with a third party will be needed. Finally, the protocol also provides forward and backward secrecy of session keys; i.e., a session key produced using IBAKE is always fresh and unrelated to any past or future sessions between the protocol participants.
密钥托管实体（即，具有足够信息以解密通信数据的实体），具有不良后果。另一个限制是通信双方之间缺乏相互认证。本文档指定了一种基于身份的认证密钥加密（IBAKE）协议，该协议不存在密钥托管问题，并提供相互认证。此外，本文档中描述的方案允许使用有时间限制的公共身份以及相应的公钥和私钥，从而导致私钥在身份本身指示的时间跨度结束时自动过期。随着公共身份的自过期，不需要传统的证书实时有效性验证和撤销程序。例如，如果公共标识绑定到某一天，那么在一天结束时，颁发给该对等方的公钥/私钥对将不再有效。然而，与基于公钥的证书系统一样，如果需要在指定的到期时间之前撤销密钥，则需要与第三方通信。最后，该协议还提供会话密钥的前向和后向保密性；i、 例如，使用IBAKE生成的会话密钥始终是新的，并且与协议参与者之间过去或将来的任何会话无关。
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]中所述进行解释。
Identity-Based Encryption (IBE) is a public-key encryption technology that allows a public key to be calculated from an identity and a set of public parameters, and the corresponding private key to be calculated from the public key. The public key can then be used by an Initiator to encrypt messages that the recipient can decrypt using the corresponding private key. The IBE framework is defined in [RFC5091], [RFC5408], and [RFC5409].
基于身份的加密（IBE）是一种公钥加密技术，它允许根据身份和一组公共参数计算公钥，并根据公钥计算相应的私钥。然后，发起者可以使用公钥来加密收件人可以使用相应私钥解密的消息。IBE框架在[RFC5091]、[RFC5408]和[RFC5409]中定义。
EC Elliptic Curve
椭圆曲线
IBE Identity-Based Encryption
基于身份的加密
IBAKE Identity-Based Authenticated Key Exchange
基于身份的认证密钥交换
IDi Initiator's Identity
IDi发起者的身份
IDr Responder's Identity
IDr响应者的身份
K_PUB Public Key
公开密钥
PKG Private-Key Generator
PKG私钥生成器
PKI Public Key Infrastructure
公钥基础设施
o E is an elliptic curve over a finite field F.
o E是有限域F上的椭圆曲线。
o P is a point on E of large prime order.
o P是E上的一个大素数阶点。
o s is a non-zero positive integer. s is a secret stored in a PKG. This is a system-wide secret and not revealed outside the PKG.
o s是非零正整数。s是存储在PKG中的秘密。这是一个全系统的秘密，不会在PKG之外泄露。
o sP is the public key of the system that is known to all participants. sP denotes a point on E, and denotes the point P added to itself s times where addition refers to the group operation on E.
o sP是所有参与者都知道的系统公钥。sP表示E上的一个点，并表示点P加到自身的s次，其中加法指的是E上的群运算。
o H1 is a known hash function that takes a string and assigns it to a point on the elliptic curve, i.e., H1(A) = QA on E, where A is usually based on the identity.
o H1是一个已知的散列函数，它接受字符串并将其分配给椭圆曲线上的一个点，即H1（a）=e上的QA，其中a通常基于标识。
o E(k, A) denotes that A is IBE-encrypted with the key k.
o E（k，A）表示A是用密钥k加密的IBE。
o s||t denotes concatenation of the strings s and t.
o s | | t表示字符串s和t的串联。
o K_PUBx denotes a public key of x.
o K_PUBx表示x的公钥。
IBAKE consists of a three-way exchange between an Initiator and a Responder. In the figure below, a conceptual signaling diagram of IBAKE is depicted.
IBAKE由发起方和响应方之间的三方交换组成。下图描述了IBAKE的概念信令图。
+---+ +---+
| I | | R |
+---+ +---+
+---+ +---+
| I | | R |
+---+ +---+
MESSAGE_1
---------------------------------->
MESSAGE_2
<----------------------------------
MESSAGE_3
---------------------------------->
MESSAGE_1
---------------------------------->
MESSAGE_2
<----------------------------------
MESSAGE_3
---------------------------------->
Figure 1: Example IBAKE Message Exchange
图1:IBAKE消息交换示例
The Initiator (I) and Responder (R) are attempting to mutually authenticate each other and agree on a key using IBAKE. This specification assumes that the Initiator and the Responder trust a third party -- the PKG. Rather than a single PKG, different PKGs may be involved, e.g., one for the Initiator and one for the Responder. The Initiator and the Responder do not share any credentials; however, they know or can obtain each other's public identity (key) as well as the public parameters of each other's PKG. This specification does not make any assumption on when and how the private keys are obtained. However, to complete the protocol described (i.e., to decrypt encrypted messages in the IBAKE protocol exchange), the Initiator and the Responder need to have their respective private keys. The procedures needed to obtain the private keys and public parameters are outside the scope of this specification. The details of these procedures can be found in [RFC5091] and [RFC5408]. Finally, the protocol described in this document relies on the use of elliptic curves. Section 3.3 discusses the choice of elliptic curves. However, how the Initiator and the Responder agree on a specific elliptic curve is left to the application that is leveraging the IBAKE protocol (see [EAP-IBAKE], for example).
发起者（I）和响应者（R）正在尝试使用IBAKE相互验证并同意密钥。本规范假设发起方和响应方信任第三方——PKG。可能涉及不同的PKG，而不是单个PKG，例如，一个用于发起方，一个用于响应方。发起方和响应方不共享任何凭据；但是，他们知道或可以获得彼此的公共身份（密钥）以及彼此PKG的公共参数。本规范未对何时以及如何获得私钥做出任何假设。然而，为了完成所描述的协议（即，解密IBAKE协议交换中的加密消息），发起方和响应方需要拥有各自的私钥。获取私钥和公共参数所需的过程不在本规范的范围内。有关这些程序的详细信息，请参见[RFC5091]和[RFC5408]。最后，本文描述的协议依赖于椭圆曲线的使用。第3.3节讨论了椭圆曲线的选择。但是，发起方和响应方如何在特定椭圆曲线上达成一致，则取决于利用IBAKE协议的应用程序（例如，请参见[EAP-IBAKE]）。
The Initiator chooses a random x. In the first step, the Initiator computes xP (i.e., P, as a point on E, added to itself x times using the addition law on E); encrypts xP, the IDi, and the IDr using the Responder's public key (e.g., K_PUBr=H1(IDr||date)); and includes
发起者选择一个随机的x。在第一步中，发起者计算xP（即，P作为e上的一个点，使用e上的加法定律将其自身加上x次）；使用响应者的公钥（例如K|u PUBr=H1（IDr | date））加密xP、IDi和IDr；包括
this encrypted information in MESSAGE_1 sent to the Responder. In this step, encryption refers to IBE as described in [RFC5091] and [RFC5408].
这是发送给响应者的消息_1中的加密信息。在此步骤中，加密指[RFC5091]和[RFC5408]中所述的IBE。
The Responder, upon receiving the message, IBE-decrypts it using its private key (e.g., a private key for that date), and obtains xP. The Responder further chooses a random y and computes yP. The Responder then IBE-encrypts the Initiator's identity (IDi), its own identity (IDr), xP, and yP using the Initiator's public key (e.g., K_PUBi=H1(IDi||date)). The Responder includes this encrypted information in MESSAGE_2 sent to the Initiator.
响应者在收到消息后，IBE使用其私钥（例如，该日期的私钥）对其进行解密，并获得xP。响应者进一步选择一个随机y并计算yP。然后，响应方IBE使用发起方的公钥（例如K|u PUBi=H1（IDi | |日期））加密发起方的身份（IDi）、自己的身份（IDr）、xP和yP。响应方在发送给发起方的消息_2中包含该加密信息。
The Initiator, upon receiving and IBE-decrypting MESSAGE_2, obtains yP. Subsequently, the Initiator sends MESSAGE_3, which includes the IBE-encrypted IDi, IDr, and yP, to the Responder. At this point, both the Initiator and the Responder are able to compute the same session key as xyP.
发起者在接收到IBE解密消息_2后获得yP。随后，发起方向响应方发送消息_3，其中包括IBE加密的IDi、IDr和yP。此时，发起方和响应方都能够计算与xyP相同的会话密钥。
Initially, the Initiator selects a random x and computes xP; the Initiator MUST use a fresh, random value for x on each run of the protocol. The Initiator then encrypts xP, the IDi, and the IDr using the Responder's public key (e.g., K_PUBr=H1(IDr||date)). The Initiator includes this encrypted information in MESSAGE_1 and sends it to the Responder, as shown below.
最初，发起者选择一个随机x并计算xP；启动器必须在每次运行协议时为x使用一个新的随机值。然后，发起者使用响应者的公钥（例如K|u PUBr=H1（IDr | date））对xP、IDi和IDr进行加密。发起者在消息_1中包含此加密信息，并将其发送给响应者，如下所示。
Initiator ----> Responder
Initiator ----> Responder
MESSAGE_1 = E(K_PUBr, IDi || IDr || xP)
消息1=E（K_PUBr，IDi | IDr | xP）
Upon receiving MESSAGE_1, the Responder SHALL perform the following:
收到消息_1后，响应者应执行以下操作：
o Decrypt the message as specified in [RFC5091] and [RFC5408].
o 按照[RFC5091]和[RFC5408]中的规定解密消息。
o Obtain xP.
o 获得经验。
o Select a random y and compute yP. The Responder MUST use a fresh, random value for x on each run of the protocol.
o 选择一个随机y并计算yP。响应程序必须在每次运行协议时为x使用一个新的随机值。
o Encrypt the Initiator's identity (IDi), its own identity (IDr), xP, and yP using the Initiator's public key (K_PUBi).
o 使用启动器的公钥（K_PUBi）加密启动器的标识（IDi）、自身标识（IDr）、xP和yP。
Responder ----> Initiator
Responder ----> Initiator
MESSAGE_2 = E(K_PUBi, IDi || IDr || xP || yP)
消息|2=E（K|u PUBi，IDi|IDr|xP|yP）
Upon receiving MESSAGE_2, the Initiator SHALL perform the following:
收到消息_2后，发起人应执行以下操作：
o Decrypt the message as specified in [RFC5091] and [RFC5408].
o 按照[RFC5091]和[RFC5408]中的规定解密消息。
o Verify that the received xP is the same as that sent in MESSAGE_1.
o 确认收到的xP与消息_1中发送的xP相同。
o Obtain yP.
o 获得yP。
o Encrypt its own identity (IDi), the Responder's identity (IDr), and yP using the Responder's public key (K_PUBi).
o 使用响应者的公钥（K_PUBi）加密其自身标识（IDi）、响应者标识（IDr）和yP。
Initiator ----> Responder
Initiator ----> Responder
MESSAGE_3 = E(K_PUBr, IDi || IDr || yP)
消息3=E（K_PUBr，IDi | IDr | yP）
Upon receiving MESSAGE_3, the Responder SHALL perform the following:
收到消息_3后，响应者应执行以下操作：
o Decrypt the message as specified in [RFC5091] and [RFC5408].
o 按照[RFC5091]和[RFC5408]中的规定解密消息。
o Verify that the received yP is the same as that sent in MESSAGE_2.
o 确认收到的yP与消息_2中发送的yP相同。
If any of the above verifications fail, the protocol halts; otherwise, following this exchange, both the Initiator and the Responder have authenticated each other and are able to compute xyP as the session key. At this point, both protocol participants MUST discard all intermediate cryptographic values, including x and y. Similarly, both parties MUST immediately discard these values whenever the protocol terminates as a result of a verification failure or timeout.
如果上述任何验证失败，则协议停止；否则，在此交换之后，发起方和响应方都已相互验证，并且能够计算xyP作为会话密钥。此时，两个协议参与者必须放弃所有中间加密值，包括x和y。同样，当协议因验证失败或超时而终止时，双方必须立即丢弃这些值。
Properties of the protocol are as follows:
协议的属性如下所示：
o Immunity from key escrow: Observe that all of the steps in the protocol exchange are encrypted using IBE. So, clearly, the PKG can decrypt all of the exchanges. However, given the assumption that PKGs are trusted and well behaved (e.g., PKGs will not mount an active man-in-the-middle (MitM) attack), they cannot compute the session key. This is because of the hardness of the Elliptic Curve Diffie-Hellman problem. In other words, given xP and yP, it is computationally hard to compute xyP.
o 免于密钥托管：注意协议交换中的所有步骤都是使用IBE加密的。因此，显然，PKG可以解密所有的交换。但是，假设PKG是可信的且行为良好（例如，PKG不会发起主动中间人（MitM）攻击），它们无法计算会话密钥。这是因为椭圆曲线Diffie-Hellman问题的复杂性。换句话说，给定xP和yP，在计算上很难计算xyP。
o Mutually authenticated key agreement: Observe that all of the steps in the protocol exchange are encrypted using IBE. In particular, only the Responder and its corresponding PKG can decrypt the contents of MESSAGE_1 and MESSAGE_3 sent by the Initiator, and similarly only the Initiator and its corresponding
o 相互认证密钥协议：注意协议交换中的所有步骤都是使用IBE加密的。特别是，只有响应者及其对应的PKG可以解密发起方发送的消息_1和消息_3的内容，同样，只有发起方及其对应的PKG可以解密
PKG can decrypt the contents of MESSAGE_2 sent by the Responder. Again, given the assumption made above -- that PKGs are trusted and well behaved (e.g., a PKG will not impersonate a user to which it issued a private key) -- upon receiving MESSAGE_2, the Initiator can verify the Responder's authenticity, since xP could have been sent in MESSAGE_2 only after decryption of the contents of MESSAGE_1 by the Responder. Similarly, upon receiving MESSAGE_3, the Responder can verify the Initiator's authenticity, since yP could have been sent back in MESSAGE_3 only after correct decryption of the contents of MESSAGE_2 by the Initiator. Finally, both the Initiator and the Responder can agree on the same session key. In other words, IBAKE is a mutually authenticated key agreement protocol based on IBE. The hardness of the key agreement protocol relies on the hardness of the Elliptic Curve Diffie-Hellman problem. Thus, in any practical implementation, care should be devoted to the choice of elliptic curve.
PKG可以解密响应者发送的消息_2的内容。同样，考虑到上述假设——PKG是可信的且行为良好（例如，PKG不会模拟其向其颁发私钥的用户）——在收到消息_2时，发起方可以验证响应方的真实性，因为xP只能在响应者解密消息_1的内容后才能在消息_2中发送。类似地，在接收到消息_3时，响应者可以验证发起者的真实性，因为只有在发起者正确解密消息_2的内容之后，yP才可以在消息_3中发送回来。最后，发起方和响应方可以在相同的会话密钥上达成一致。换句话说，IBAKE是一个基于IBE的相互认证密钥协商协议。密钥协商协议的硬度取决于椭圆曲线Diffie-Hellman问题的硬度。因此，在任何实际实现中，都应该注意椭圆曲线的选择。
o Perfect forward and backward secrecy: Since x and y are random, xyP is always fresh and unrelated to any past or future sessions between the Initiator and the Responder.
o 完美的前向和后向保密性：由于x和y是随机的，所以xyP始终是新的，并且与发起方和响应方之间过去或将来的会话无关。
o No passwords: Clearly, the IBAKE protocol does not require any offline exchange of passwords or secret keys between the Initiator and the Responder. In fact, the method is applicable to any two parties communicating for the first time through any communication network. The only requirement is to ensure that both the Initiator and the Responder are aware of each other's public keys and the public parameters of the PKG that generated the corresponding private keys.
o 无密码：显然，IBAKE协议不需要在发起方和响应方之间离线交换密码或密钥。事实上，该方法适用于通过任何通信网络首次通信的任何双方。唯一的要求是确保发起方和响应方都知道对方的公钥以及生成相应私钥的PKG的公共参数。
o PKG availability: Observe that PKGs need not be contacted during an IBAKE protocol exchange, which dramatically reduces the availability requirements on PKGs.
o PKG可用性：请注意，在IBAKE协议交换期间不需要联系PKG，这大大降低了PKG的可用性要求。
o Choice of elliptic curves: This specification relies on the use of elliptic curves for both IBE and Elliptic Curve Diffie-Hellman exchange. When making a decision on the choice of elliptic curves, it is beneficial to choose two different elliptic curves -- a non-supersingular curve for the internal calculations of Elliptic Curve Diffie-Hellman values xP and yP, and a supersingular curve for the IBE encryption/decryption. For the calculations of Elliptic Curve Diffie-Hellman values, it is beneficial to use the curves recommended by NIST [FIPS-186]. These curves make the calculations simpler while keeping the security high. On the other hand, IBE systems are based on bilinear pairings. Therefore, the choice of an elliptic curve for
o 椭圆曲线的选择：本规范依赖于对IBE和椭圆曲线Diffie-Hellman交换使用椭圆曲线。在决定选择椭圆曲线时，最好选择两条不同的椭圆曲线——用于椭圆曲线Diffie-Hellman值xP和yP内部计算的非超奇异曲线和用于IBE加密/解密的超奇异曲线。对于椭圆曲线Diffie-Hellman值的计算，使用NIST推荐的曲线是有益的[FIPS-186]。这些曲线使计算更简单，同时保持较高的安全性。另一方面，IBE系统是基于双线性对的。因此，选择椭圆曲线为
IBE is restricted to a family of supersingular elliptic curves over finite fields of large prime characteristic. The appropriate elliptic curves for IBE are described in [RFC5091].
IBE仅限于有限域上具有大素数特征的超奇异椭圆曲线族。[RFC5091]中描述了IBE的适当椭圆曲线。
o Implementation considerations: An implementation of IBAKE would consist of two primary modules, i.e., point addition operations over a NIST curve, and IBE operations over a supersingular curve. The implementation of both modules only needs to be aware of the following parameters: (a) the full description of the curves that are in use (fixed or negotiated), (b) the public parameters of the PKG used for the derivation of IBE private keys, and (c) the exact public identity of each IBAKE participant. The knowledge of these parameters is sufficient to perform Elliptic Curve Cryptography (ECC) operations in different terminals and produce the same results, independently of the implementation.
o 实施注意事项：IBAKE的实施将包括两个主要模块，即NIST曲线上的点加法运算和超奇异曲线上的IBE运算。两个模块的实现只需要了解以下参数：（a）正在使用的曲线的完整描述（固定或协商），（b）用于衍生IBE私钥的PKG的公共参数，以及（c）每个IBAKE参与者的确切公共身份。这些参数的知识足以在不同的终端上执行椭圆曲线密码（ECC）操作并产生相同的结果，而不依赖于实现。
This document is based on the basic IBE protocol, as specified in [BF], [RFC5091]), [RFC5408], and [RFC5409], and as such inherits some properties of that protocol. For instance, by concatenating the "date" with the identity (to derive the public key), the need for any key revocation mechanisms is virtually eliminated. Moreover, by allowing the participants to acquire multiple private keys (e.g., for duration of contract) the availability requirements on the PKG are also reduced without any reduction in security. The granularity associated with the date is a matter of security policy and as such is a decision made by the PKG administrator. However, the granularity applicable to any given participant should be publicly available and known to other participants. For example, this information can be made available in the same venue that provides "public information" on a PKG server (i.e., P, sP) needed to execute IBE.
本文件基于[BF]、[RFC5091]、[RFC5408]和[RFC5409]中规定的基本IBE协议，因此继承了该协议的一些属性。例如，通过将“日期”与标识连接（以派生公钥），实际上不需要任何密钥撤销机制。此外，通过允许参与者获取多个私钥（例如，在合同期限内），PKG的可用性要求也在不降低任何安全性的情况下降低。与日期关联的粒度是安全策略的问题，因此是PKG管理员做出的决定。但是，适用于任何给定参与者的粒度应公开，并为其他参与者所知。例如，这些信息可以在提供执行IBE所需的PKG服务器（即P、sP）上的“公共信息”的同一地点提供。
Attacks on the cryptographic algorithms used in IBE are outside the scope of this document. It is assumed that any administrator will pay attention to the desired strengths of the relevant cryptographic algorithms based on an up-to-date understanding of the strength of these algorithms from published literature, as well as to known attacks.
对IBE中使用的加密算法的攻击超出了本文档的范围。假设任何管理员都会关注相关密码算法的期望强度，这是基于对已发表文献中这些算法的强度以及已知攻击的最新理解。
It is assumed that the PKGs are secure, not compromised, trusted, and will not engage in launching active attacks independently or in a collaborative environment. Nevertheless, if an active adversary can fool the parties into believing that it is a legitimate PKG, then it can mount a successful MitM attack. Therefore, care should be taken
假定PKG是安全的、不受损害的、受信任的，并且不会独立或在协作环境中发起主动攻击。然而，如果一个积极的对手能够欺骗各方相信它是一个合法的库尔德工人党，那么它就可以发动一次成功的MitM攻击。因此，应谨慎行事
when choosing a PKG. In addition, any malicious insider could potentially launch passive attacks (by decryption of one or more message exchanges offline). While it is in the best interest of administrators to prevent such an issue, it is hard to eliminate this problem. Hence, it is assumed that such problems will persist, and hence the session key agreement protocols are designed to protect participants from passive adversaries.
选择包装时。此外，任何恶意内幕人士都可能发起被动攻击（通过解密一个或多个脱机消息交换）。虽然防止此类问题符合管理员的最佳利益，但很难消除此问题。因此，假设此类问题将持续存在，因此会话密钥协商协议旨在保护参与者免受被动对手的攻击。
It is also assumed that the communication between participants and their respective PKGs is secure. Therefore, in any implementation of the protocols described in this document, administrators of any PKG have to ensure that communication with participants is secure and not compromised.
还假设参与者与其各自PKG之间的通信是安全的。因此，在本文件所述协议的任何实施过程中，任何PKG的管理员都必须确保与参与者的通信是安全的，不会受到损害。
Finally, concatenating the date to the identity ensures that the corresponding private key is applicable only to that date. This serves to limit the damage related to a leakage or compromise of private keys to just that date. This, in particular, eliminates the revocation mechanisms that are typical to various certificate-based public key protocols.
最后，将日期连接到标识可确保相应的私钥仅适用于该日期。这有助于将与私钥泄漏或泄露相关的损坏限制在该日期。这尤其消除了各种基于证书的公钥协议的典型撤销机制。
For the basic IBAKE protocol, from a cryptographic perspective, the following security considerations apply.
对于基本IBAKE协议，从加密角度来看，以下安全注意事项适用。
In every step, IBE is used, with the recipient's public key. This guarantees that only the intended recipient of the message and its corresponding PKG can decrypt the message [BF].
在每一个步骤中，都使用IBE和接收者的公钥。这保证了只有消息的预期收件人及其对应的PKG可以解密消息[BF]。
Next, the use of identities within the encrypted payload is intended to eliminate some basic reflection attacks. For instance, suppose we did not use identities as part of the encrypted payload, in the first step of the IBAKE protocol exchange (i.e., MESSAGE_1 of Figure 1 in Section 3.1). Furthermore, assume that an adversary has access to the conversation between the Initiator and the Responder and can actively snoop packets and drop/modify them before routing them to the destination. For instance, assume that the IP source address and destination address can be modified by the adversary. After the first message is sent by the Initiator (to the Responder), the adversary can take over and trap the packet. Next, the adversary can modify the IP source address to include the adversary's IP address, before routing it on to the Responder. The Responder will assume that the request for an IBAKE session came from the adversary, and will execute step 2 of the IBAKE protocol exchange (i.e., MESSAGE_2 of Figure 1 in Section 3.1) but encrypt it using the adversary's public key. The above message can be decrypted by the adversary (and only by the adversary). In particular, since the second message
接下来，在加密有效载荷中使用身份旨在消除一些基本反射攻击。例如，假设在IBAKE协议交换的第一步中，我们没有使用身份作为加密负载的一部分（即，第3.1节图1中的消息_1）。此外，假设对手可以访问发起方和响应方之间的对话，并且可以在将数据包路由到目的地之前主动嗅探数据包并丢弃/修改数据包。例如，假设对手可以修改IP源地址和目标地址。发起方（向响应方）发送第一条消息后，对手可以接管并捕获数据包。接下来，敌方可以修改IP源地址以包括敌方的IP地址，然后再将其路由到响应方。响应者将假定IBAKE会话的请求来自对手，并将执行IBAKE协议交换的步骤2（即第3.1节图1中的消息_2），但使用对手的公钥对其进行加密。上述消息可由对手解密（且仅由对手解密）。特别是第二条消息
includes the challenge sent by the Initiator to the Responder, the adversary will now learn the challenge sent by the Initiator. Following this, the adversary can carry on a conversation with the Initiator, "pretending" to be the Responder. This attack will be eliminated if identities are used as part of the encrypted payload. In summary, at the end of the exchange, both the Initiator and the Responder can mutually authenticate each other and agree on a session key.
包括发起者发送给响应者的质询，对手现在将学习发起者发送的质询。接下来，对手可以与发起人进行对话，“假装”是响应者。如果将身份用作加密负载的一部分，则此攻击将被消除。总之，在交换结束时，发起方和响应方都可以相互验证对方，并就会话密钥达成一致。
Recall that IBE guarantees that only the recipient of the message can decrypt the message using the private key, with the caveat that the PKG that generated the private key of the recipient of the message can decrypt the message as well. However, the PKG cannot learn the public key xyP given xP and yP, based on the hardness of the Elliptic Curve Diffie-Hellman problem. This property of resistance to passive key escrow from the PKG is not applicable to the basic IBE protocols proposed in [RFC5091]), [RFC5408], and [RFC5409].
回想一下，IBE保证只有消息接收者可以使用私钥解密消息，但要注意的是，生成消息接收者私钥的PKG也可以解密消息。然而，基于椭圆曲线Diffie-Hellman问题的复杂性，PKG无法学习给定xP和yP的公钥xyP。这种抵抗PKG被动密钥托管的特性不适用于[RFC5091]、[RFC5408]和[RFC5409]中提出的基本IBE协议。
Observe that the protocol works even if the Initiator and Responder belong to two different PKGs. In particular, the parameters used for encryption to the Responder and parameters used for encryption to the Initiator can be completely different and independent of each other. Moreover, the elliptic curve used to generate the session key xyP can be completely different and can be chosen during the key exchange. If such flexibility is desired, then it would be required to add optional extra data to the protocol to exchange the algebraic primitives used in deriving the session key.
请注意，即使发起方和响应方属于两个不同的PKG，协议也可以工作。特别是，用于对响应者进行加密的参数和用于对发起方进行加密的参数可以完全不同并且彼此独立。此外，用于生成会话密钥xyP的椭圆曲线可以完全不同，并且可以在密钥交换期间进行选择。如果需要这种灵活性，则需要向协议中添加可选的额外数据，以交换用于导出会话密钥的代数原语。
In addition to mutual authentication and resistance to passive escrow, the Diffie-Hellman property of the session key exchange guarantees perfect secrecy of keys. In other words, accidental leakage of one session key does not compromise past or future session keys between the same Initiator and Responder.
除了相互认证和抵抗被动托管外，会话密钥交换的Diffie-Hellman属性还保证了密钥的完美保密性。换句话说，一个会话密钥的意外泄漏不会影响同一启动器和响应程序之间过去或将来的会话密钥。
[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月。
[BF] Boneh, D. and M. Franklin, "Identity-Based Encryption from the Weil Pairing", in SIAM Journal on Computing, Vol. 32, No. 3, pp. 586-615, 2003.
[BF]Boneh，D.和M.Franklin，“Weil配对中基于身份的加密”，载于《暹罗计算杂志》，第32卷，第3期，第586-615页，2003年。
[EAP-IBAKE] Cakulev, V. and I. Broustis, "An EAP Authentication Method Based on Identity-Based Authenticated Key Exchange", Work in Progress, February 2012.
[EAP-IBAKE]Cakulev，V.和I.Broustis，“基于身份认证密钥交换的EAP认证方法”，正在进行的工作，2012年2月。
[FIPS-186] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS Pub 186-3, June 2009.
[FIPS-186]国家标准与技术研究所，“数字签名标准（DSS）”，FIPS Pub 186-3，2009年6月。
[RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems", RFC 5091, December 2007.
[RFC5091]Boyen，X.和L.Martin，“基于身份的密码标准（IBCS）#1：BF和BB1密码系统的超奇异曲线实现”，RFC 5091，2007年12月。
[RFC5408] Appenzeller, G., Martin, L., and M. Schertler, "Identity-Based Encryption Architecture and Supporting Data Structures", RFC 5408, January 2009.
[RFC5408]Appenzeller，G.，Martin，L.和M.Schertler，“基于身份的加密体系结构和支持数据结构”，RFC 5408，2009年1月。
[RFC5409] Martin, L. and M. Schertler, "Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)", RFC 5409, January 2009.
[RFC5409]Martin，L.和M.Schertler，“使用基于Boneh Franklin和Boneh Boyen身份的加密算法和加密消息语法（CMS）”，RFC 5409，2009年1月。
Authors' Addresses
作者地址
Violeta Cakulev Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
Violeta Cakulev Alcatel-Lucent美国新泽西州默里山3D-517山地大道600号，邮编：07974
Phone: +1 908 582 3207
EMail: violeta.cakulev@alcatel-lucent.com
Phone: +1 908 582 3207
EMail: violeta.cakulev@alcatel-lucent.com
Ganapathy S. Sundaram Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
美国新泽西州默里山3D-517 Mountain Ave 600 Mountain Ave.Ganapathy S.Sundaram Alcatel-Lucent 07974
Phone: +1 908 582 3209
EMail: ganesh.sundaram@alcatel-lucent.com
Phone: +1 908 582 3209
EMail: ganesh.sundaram@alcatel-lucent.com
Ioannis Broustis Alcatel Lucent 600 Mountain Ave. 3D-526 Murray Hill, NJ 07974 US
美国新泽西州默里山3D-526 Mountain Ave.Ioannis Broustis Alcatel-Lucent 600美国
Phone: +1 908 582 3744
EMail: ioannis.broustis@alcatel-lucent.com
Phone: +1 908 582 3744
EMail: ioannis.broustis@alcatel-lucent.com