Internet Engineering Task Force (IETF) V. Cakulev
Request for Comments: 6267 G. Sundaram
Category: Informational Alcatel Lucent
ISSN: 2070-1721 June 2011
Internet Engineering Task Force (IETF) V. Cakulev
Request for Comments: 6267 G. Sundaram
Category: Informational Alcatel Lucent
ISSN: 2070-1721 June 2011
MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)
MIKEY-IBAKE：多媒体互联网密钥分配（MIKEY）中基于身份的认证密钥交换（IBAKE）模式
Abstract
摘要
This document describes a key management protocol variant for the Multimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service. In particular, this variant utilizes Identity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework. This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy.
本文档描述了多媒体互联网密钥（MIKEY）协议的密钥管理协议变体，该协议依赖于可信密钥管理服务。特别地，该变体利用基于身份的认证密钥交换（IBAKE）框架，该框架允许参与的客户端在基于身份的非对称加密（IBE）框架中执行相互认证并派生会话密钥。该协议除了提供相互认证外，还消除了标准IBE中常见的密钥托管问题，并提供了完美的前向和后向保密性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6267.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6267.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Definitions and Notation . . . . . . . . . . . . . . . . . 4
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Retargeting . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Deferred Delivery . . . . . . . . . . . . . . . . . . . . 7
4. MIKEY-IBAKE Protocol Description . . . . . . . . . . . . . . . 7
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Message Exchanges and Processing . . . . . . . . . . . . . 10
4.2.1. REQUEST_KEY_INIT/REQUEST_KEY_RESP Message Exchange . . 10
4.2.2. I_MESSAGE/R_MESSAGE Message Exchanges . . . . . . . . 12
5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Generating Keys from the Session Key . . . . . . . . . . . 17
5.2. Generating Keys for MIKEY Messages . . . . . . . . . . . . 17
5.3. CSB Update . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Generating MAC and Verification Message . . . . . . . . . 18
6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Common Header Payload (HDR) . . . . . . . . . . . . . . . 19
6.1.1. IBAKE Payload . . . . . . . . . . . . . . . . . . . . 20
6.1.2. Encrypted Secret Key (ESK) Payload . . . . . . . . . . 21
6.1.3. Key Data Sub-Payload . . . . . . . . . . . . . . . . . 21
6.1.4. EC Diffie-Hellman Sub-Payload . . . . . . . . . . . . 22
6.1.5. Secret Key Sub-Payload . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. General Security Considerations . . . . . . . . . . . . . 24
7.2. IBAKE Protocol Security Considerations . . . . . . . . . . 25
7.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.4. Retargeting . . . . . . . . . . . . . . . . . . . . . . . 26
7.5. Deferred Delivery . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Definitions and Notation . . . . . . . . . . . . . . . . . 4
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Retargeting . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Deferred Delivery . . . . . . . . . . . . . . . . . . . . 7
4. MIKEY-IBAKE Protocol Description . . . . . . . . . . . . . . . 7
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Message Exchanges and Processing . . . . . . . . . . . . . 10
4.2.1. REQUEST_KEY_INIT/REQUEST_KEY_RESP Message Exchange . . 10
4.2.2. I_MESSAGE/R_MESSAGE Message Exchanges . . . . . . . . 12
5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Generating Keys from the Session Key . . . . . . . . . . . 17
5.2. Generating Keys for MIKEY Messages . . . . . . . . . . . . 17
5.3. CSB Update . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Generating MAC and Verification Message . . . . . . . . . 18
6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Common Header Payload (HDR) . . . . . . . . . . . . . . . 19
6.1.1. IBAKE Payload . . . . . . . . . . . . . . . . . . . . 20
6.1.2. Encrypted Secret Key (ESK) Payload . . . . . . . . . . 21
6.1.3. Key Data Sub-Payload . . . . . . . . . . . . . . . . . 21
6.1.4. EC Diffie-Hellman Sub-Payload . . . . . . . . . . . . 22
6.1.5. Secret Key Sub-Payload . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. General Security Considerations . . . . . . . . . . . . . 24
7.2. IBAKE Protocol Security Considerations . . . . . . . . . . 25
7.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.4. Retargeting . . . . . . . . . . . . . . . . . . . . . . . 26
7.5. Deferred Delivery . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . . 29
The Multimedia Internet Keying (MIKEY) [RFC3830] specification describes several modes of key distribution solution that address multimedia scenarios using pre-shared keys, Public Keys, and optionally a Diffie-Hellman key exchange. Multiple extensions of MIKEY have been specified, such as HMAC-Authenticated (Hashed Message Authentication Code) Diffie-Hellman [RFC4650] and MIKEY-RSA-R [RFC4738].
多媒体互联网密钥（MIKEY）[RFC3830]规范描述了几种密钥分发解决方案模式，这些解决方案使用预共享密钥、公钥和Diffie-Hellman密钥交换来解决多媒体场景。已经指定了MIKEY的多个扩展，例如HMAC认证（哈希消息认证码）Diffie Hellman[RFC4650]和MIKEY-RSA-R[RFC4738]。
To address deployment scenarios in which security systems serve a large number of users, a key management service is often preferred. With such a service in place, it would be possible for a user to request credentials for any other user when they are needed. Some proposed solutions [RFC6043] rely on Key Management Services (KMSs) in the network that create, distribute, and manage keys in a real time. Due to this broad functionality, key management services would have to be online, maintain high availability, and be networked across operator boundaries.
为了解决安全系统为大量用户提供服务的部署场景，通常首选密钥管理服务。有了这样的服务，用户可以在需要时为任何其他用户请求凭据。一些建议的解决方案[RFC6043]依赖于网络中的密钥管理服务（KMS），该服务可实时创建、分发和管理密钥。由于这一广泛的功能，关键管理服务必须在线，保持高可用性，并跨运营商边界联网。
This document describes a solution in which KMSs are low-availability servers that communicate with end-user clients periodically (e.g., once a month). The online transactions between the end-user clients (for media plane security) are based on Identity-Based Encryption (IBE) [BF]. These online transactions between the end-user clients allow them to perform mutual authentication and derive a session key not known to any external entity (including KMSs). This protocol, in addition to providing keys not known to any external entity and allowing for end-user clients to mutually authenticate each other (at the media plane layer), provides perfect forward and backward secrecy. In this protocol, the KMS-to-client exchange is used sparingly (e.g., once a month); hence, the KMS is no longer required to be a high-availability server, and in particular different KMSs don't have to communicate with each other (across operator boundaries). Moreover, given that an IBE is used, the need for costly Public Key Infrastructure (PKI) and all the operational costs of certificate management and revocation are eliminated. This is achieved by concatenating Public Keys with a date field, thereby ensuring corresponding Private Keys change with the date and, more importantly, limiting the damage due to loss of a Private Key to just that date while not requiring endpoints involved in communication to be time synchronized. The granularity in the date field is a matter of security policy and deployment scenario. For instance, an operator may choose to use one key per day and hence the KMS may issue Private Keys for a whole subscription cycle at the beginning of a subscription cycle. Therefore, unlike in the PKI systems, where issued certificate is typically valid for period of time thereby requiring revocation procedures to limit their validity, the scheme
本文档描述了一种解决方案，其中KMS是低可用性服务器，定期（例如，每月一次）与最终用户客户端通信。最终用户客户端之间的在线交易（用于媒体平面安全）基于基于身份的加密（IBE）[BF]。最终用户客户端之间的这些在线事务允许它们执行相互身份验证并派生任何外部实体（包括KMS）都不知道的会话密钥。该协议除了提供任何外部实体都不知道的密钥并允许最终用户客户端（在媒体平面层）相互验证之外，还提供了完美的前向和后向保密性。在该协议中，KMS到客户端的交换很少使用（例如，每月一次）；因此，KMS不再需要成为高可用性服务器，特别是不同的KMS不必相互通信（跨越运营商边界）。此外，由于使用了IBE，因此不需要昂贵的公钥基础设施（PKI）以及证书管理和吊销的所有操作成本。这是通过将公钥与日期字段连接起来实现的，从而确保相应的私钥随日期而变化，更重要的是，将私钥丢失造成的损坏限制在该日期，同时不要求通信中涉及的端点进行时间同步。日期字段中的粒度取决于安全策略和部署场景。例如，运营商可以选择每天使用一个密钥，因此KMS可以在订阅周期开始时为整个订阅周期颁发私钥。因此，与PKI系统不同的是，在PKI系统中，颁发的证书通常在一段时间内有效，因此需要撤销程序来限制其有效性
described in this document uses time-bound public identities, which automatically expire 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 is 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 like 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.
本文档中描述的使用有时间限制的公共标识，该标识在标识本身所指示的时间跨度结束时自动过期。随着公共身份的自失效，不再需要传统的实时有效性验证和撤销。例如，如果公共标识绑定到某一天，那么在一天结束时，颁发给该对等方的公钥/私钥对将不再有效。然而，与基于公钥的证书系统一样，如果需要在指定的到期时间之前撤销密钥，则需要与第三方通信。
Additionally, various call scenarios are securely supported -- this includes secure forking, retargeting, deferred delivery and pre-encoded content.
此外，还安全地支持各种呼叫场景，包括安全分叉、重定目标、延迟交付和预编码内容。
MIKEY is widely used in the 3GPP community. This specification is intended primarily for use with 3GPP media security, but it may also be applicable in Internet applications.
MIKEY广泛应用于3GPP社区。本规范主要用于3GPP媒体安全，但也可能适用于互联网应用。
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]中所述进行解释。
IBE Encryption: Identity-Based Encryption (IBE) is a Public-Key encryption technology that allows a Public Key to be calculated from an identity, and the corresponding Private Key to be calculated from the Public Key. [RFC5091], [RFC5408], and [RFC5409] describe algorithms required to implement the IBE.
IBE加密：基于身份的加密（Identity-Based Encryption，IBE）是一种公钥加密技术，它允许根据身份计算公钥，并根据公钥计算相应的私钥。[RFC5091]、[RFC5408]和[RFC5409]描述了实现IBE所需的算法。
(Media) session: The communication session intended to be secured by the MIKEY-IBAKE provided key(s).
（媒体）会话：由MIKEY-IBAKE提供的密钥保护的通信会话。
E(k, x) Encryption of x with the key k [x]P Point multiplication on an elliptic curve, i.e., adding a point P to itself total of x times K_PUBx Public Key of x [x] x is optional {x} Zero or more occurrences of x (x) One or more occurrences of x || Concatenation | OR (selection operator)
E（k，x）在椭圆曲线上使用密钥k[x]P点乘对x进行加密，即，将一个点P添加到其自身x乘以x[x]x的k_PUBx公钥是可选的{x}x的零次或多次出现x（x）的一次或多次出现x | |串联|或（选择运算符）
EC Elliptic Curve
椭圆曲线
ESK Encrypted Secret Key
ESK加密密钥
HMAC Hashed Message Authentication Code
HMAC哈希消息身份验证码
IBE Identity-Based Encryption
基于身份的加密
I Initiator
I发起人
IBAKE Identity-Based Authenticated Key Exchange
基于身份的认证密钥交换
IDRi Initiator's Identity
IDRi启动器的标识
IDRr Responder's Identity
IDRr响应者的身份
KMS Key Management Service
密钥管理服务
K_PR Private Key
K_PR私钥
K_PUB Public Key
公开密钥
K_SESSION Session Key
K_会话密钥
MAC Message Authentication Code
MAC消息认证码
MIKEY Multimedia Internet KEYing
MIKEY多媒体互联网键控
MKI Master Key Identifier
主密钥标识符
MPK MIKEY Protection Key
MIKEY保护密钥
PKI Public Key Infrastructure
公钥基础设施
PRF Pseudorandom Function
伪随机函数
R Responder
应答器
SK Secret Key
密钥
SIP Session Initiation Protocol
SIP会话启动协议
SPI Security Parameter Index
安全参数索引
SRTP Secure Realtime Transport Protocol
安全实时传输协议
TEK Traffic Encryption Key
TEK流量加密密钥
TGK TEK Generation Key
TGK-TEK生成密钥
This section describes some of the use case scenarios supported by MIKEY-IBAKE, in addition to regular two-party communication.
本节描述了MIKEY-IBAKE支持的一些用例场景，以及常规的双方通信。
Forking is the delivery of a request (e.g., SIP INVITE message) to multiple endpoints. This happens when a single user is registered more than once. An example of forking is when a user has a desk phone, PC client, and mobile handset all registered with the same public identity.
分叉是将请求（例如SIP INVITE消息）传递到多个端点。当单个用户多次注册时，就会发生这种情况。分叉的一个例子是，当用户有一台台式电话、PC客户端和移动电话，所有这些都以相同的公共身份注册时。
+---+ +-------+ +---+ +---+
| A | | PROXY | | B | | C |
+---+ +-------+ +---+ +---+
Request
-------------------->
Request
-------------------->
Request
------------------------------------->
+---+ +-------+ +---+ +---+
| A | | PROXY | | B | | C |
+---+ +-------+ +---+ +---+
Request
-------------------->
Request
-------------------->
Request
------------------------------------->
Figure 1: Forking
图1：分叉
Retargeting is a scenario in which a functional element decides to redirect the session to a different destination. This decision to redirect a session may be made for different reasons by a number of different functional elements and at different points in the establishment of the session.
重定目标是一种场景，其中功能元素决定将会话重定向到不同的目标。在会话建立的不同阶段，许多不同的职能部门可能出于不同的原因做出重定向会话的决定。
There are two basic scenarios of session redirection. In scenario one, a functional element (e.g., Proxy) decides to redirect the session by passing the new destination information to the originator. As a result, the originator initiates a new session to the redirected destination provided by the Proxy. For the case of MIKEY-IBAKE, this means that the originator will initiate a new session with the identity of the redirected destination. This scenario is depicted in Figure 2 below.
会话重定向有两种基本场景。在场景一中，功能元素（例如代理）决定通过将新的目的地信息传递给发起人来重定向会话。因此，发起人向代理提供的重定向目的地发起新会话。对于MIKEY-IBAKE，这意味着发起者将使用重定向目的地的标识启动新会话。此场景如下图2所示。
+---+ +-------+ +---+ +---+
| A | | PROXY | | B | | C |
+---+ +-------+ +---+ +---+
Request
-------------------->
Request
-------------------->
Redirect
<--------------------
Redirect
<-------------------
Request
---------------------------------------------------------->
+---+ +-------+ +---+ +---+
| A | | PROXY | | B | | C |
+---+ +-------+ +---+ +---+
Request
-------------------->
Request
-------------------->
Redirect
<--------------------
Redirect
<-------------------
Request
---------------------------------------------------------->
Figure 2: Retargeting
图2：重定目标
In the second scenario, a proxy decides to redirect the session without informing the originator. This is a common scenario specified in SIP [RFC3261].
在第二个场景中，代理决定重定向会话，而不通知发起人。这是SIP[RFC3261]中指定的常见场景。
Deferred delivery is a type of service such that the session content cannot be delivered to the destination at the time that it is being sent (e.g., the destination user is not currently online). Nevertheless, the sender expects the network to deliver the message as soon as the recipient becomes available. A typical example of deferred delivery is voicemail.
延迟交付是一种服务类型，使得会话内容在发送时无法交付到目标（例如，目标用户当前不在线）。然而，发送方希望网络在接收方可用时立即传递消息。延迟交付的一个典型例子是语音邮件。
Most of the previously defined MIKEY modes consist of a single (or half) roundtrip between two peers. MIKEY-IBAKE consists of up to three roundtrips. In the first roundtrip, users (Initiator and Responder) obtain their Private Key(s) (K_PR) from the KMS. This roundtrip can be performed at anytime and, as explained earlier, takes place, for example, once a month (or once per subscription cycle). The second and the third roundtrips are between the Initiator and the Responder. Observe that the Key Management Service is only involved in the first roundtrip. In Figure 3, a conceptual signaling diagram for the MIKEY-IBAKE mode is depicted.
以前定义的大多数MIKEY模式都由两个对等方之间的一次（或半次）往返组成。MIKEY-IBAKE最多包含三次往返。在第一次往返中，用户（发起者和响应者）从KMS获得他们的私钥（K_PR）。此往返可以在任何时候执行，如前所述，例如每月执行一次（或每个订阅周期执行一次）。第二次和第三次往返在发起方和响应方之间。请注意，密钥管理服务仅涉及第一次往返。在图3中，描述了MIKEY-IBAKE模式的概念信令图。
+---+ +------+ +------+ +---+
| I | | KMS1 | | KMS2 | | R |
+---+ +------+ +------+ +---+
REQUEST_KEY_INIT REQUEST_KEY_INIT
------------------> <----------------------
REQUEST_KEY_RESP REQUEST_KEY_RESP
<------------------ ---------------------->
I_MESSAGE_1
----------------------------------------------------------->
R_MESSAGE_1
<-----------------------------------------------------------
I_MESSAGE_2
----------------------------------------------------------->
R_MESSAGE_2
<-----------------------------------------------------------
+---+ +------+ +------+ +---+
| I | | KMS1 | | KMS2 | | R |
+---+ +------+ +------+ +---+
REQUEST_KEY_INIT REQUEST_KEY_INIT
------------------> <----------------------
REQUEST_KEY_RESP REQUEST_KEY_RESP
<------------------ ---------------------->
I_MESSAGE_1
----------------------------------------------------------->
R_MESSAGE_1
<-----------------------------------------------------------
I_MESSAGE_2
----------------------------------------------------------->
R_MESSAGE_2
<-----------------------------------------------------------
Figure 3: Example Message Exchange
图3：消息交换示例
The Initiator (I) wants to establish a secure media session with the Responder (R). The Initiator and the Responder trust a third party, the Key Management Service (KMS), with which they both have, or can establish, shared credentials. These pre-established trust relations are used by a user (i.e., Initiator and Responder) to obtain Private Keys. Rather than a single KMS, several different KMSs may be involved, e.g., one for the Initiator and one for the Responder as shown in Figure 3. The Initiator and the Responder do not share any credentials; however, the Initiator knows the Responder's public identity. The assumed trust model is illustrated in Figure 4.
发起方（I）希望与响应方（R）建立安全的媒体会话。发起方和响应方信任第三方密钥管理服务（KMS），它们都拥有或可以建立共享凭据。用户（即发起方和响应方）使用这些预先建立的信任关系来获取私钥。与单个KMS不同，可能涉及多个不同的KMS，例如，一个用于发起方，一个用于响应方，如图3所示。发起方和响应方不共享任何凭据；但是，发起者知道响应者的公共身份。假定的信任模型如图4所示。
+---+ +------+ +------+ +---+
| I | | KMS1 | | KMS2 | | R |
+---+ +------+ +------+ +---+
Pre-established Pre-established
trust relation trust relation
<-----------------> <--------------------->
+---+ +------+ +------+ +---+
| I | | KMS1 | | KMS2 | | R |
+---+ +------+ +------+ +---+
Pre-established Pre-established
trust relation trust relation
<-----------------> <--------------------->
Security association based on mutual authentication
performed during MIKEY-IBAKE exchange
<---------------------------------------------------------->
Security association based on mutual authentication
performed during MIKEY-IBAKE exchange
<---------------------------------------------------------->
Figure 4: Trust Model
图4：信任模型
Below, a description of how Private Keys are obtained using MIKEY messages is provided. An alternative way for obtaining Private Keys using HTTP is described in [RFC5408].
下面介绍如何使用MIKEY消息获取私钥。[RFC5408]中描述了使用HTTP获取私钥的替代方法。
The Initiator obtains Private Key(s) from the KMS by sending a REQUEST_KEY_INIT message. The REQUEST_KEY_INIT message includes Initiator's public identity(s) (if the Initiator has more than one public identity, it may request Private Keys for every identity registered) and is protected via a MAC based on a pre-shared key or via a signature (similar to the MIKEY-PSK and MIKEY-RSA modes). If the request is authorized, the KMS generates the requested keys, encodes them, and returns them in a REQUEST_KEY_RESP message. This exchange takes place periodically and does not need to be performed every time an Initiator needs to establish a secure connection with a Responder.
发起方通过发送请求密钥初始化消息从KMS获取私钥。REQUEST_KEY_INIT消息包括发起方的公共标识（如果发起方具有多个公共标识，则它可以为每个注册的标识请求私钥），并通过基于预共享密钥的MAC或签名（类似于MIKEY-PSK和MIKEY-RSA模式）进行保护。如果请求得到授权，KMS将生成请求的密钥，对它们进行编码，并在请求密钥响应消息中返回它们。此交换定期进行，不需要每次启动器需要与响应程序建立安全连接时都执行。
The Initiator next chooses a random x and computes [x]P, where P is a point on elliptic curve E known to all users. The Initiator uses the Responder's public identity to generate the Responder's Public Key (e.g., K_PUBr=H1(IDRr||date)), where Hi is hash function known to all users, and the granularity in date is a matter of security policy and known publicly. Then the Initiator uses this generated Public Key to encrypt [x]P, IDRi and IDRr and includes this encrypted information in an I_MESSAGE_1 message, which is sent to the Responder. The encryption is Identity-Based Encryption (IBE) as specified in [RFC5091] and [RFC5408]. In turn, the Responder IBE-decrypts the received message using its Private Key for that date, chooses random y and computes [y]P. Next, the Responder uses Initiator's identity obtained from I_MESSAGE_1 to generate Initiator's Public Key (e.g., K_PUBi=H1(IDRi||date)) and IBE-encrypts (IDRi, IDRr, [x]P, [y]P) using K_PUBi, and includes it in R_MESSAGE_1 message sent to the Initiator. At this point, the Responder is able to generate the session key as [x][y]P. This session key is then used to generate TGK as specified in Section 5.1.
发起者接下来选择一个随机的x并计算[x]P，其中P是所有用户都知道的椭圆曲线E上的一个点。发起者使用响应者的公共身份生成响应者的公钥（例如，K|u PUBr=H1（IDRr | | date）），其中Hi是所有用户都知道的哈希函数，日期的粒度是安全策略的问题，是公开的。然后，发起方使用该生成的公钥加密[x]P、IDRi和IDRr，并将该加密信息包含在发送给响应方的I_消息_1消息中。加密是[RFC5091]和[RFC5408]中规定的基于身份的加密（IBE）。反过来，响应者IBE使用其在该日期的私钥解密接收到的消息，选择随机y并计算[y]P。接下来，响应者使用从I_消息_1获得的启动器身份来生成启动器的公钥（例如，K_PUBi=H1（IDRi | date）），IBE使用K_PUBi加密（IDRi，IDRr，[x]P，[y]P），并将其包含在发送给启动器的R_消息_1消息中。此时，响应者能够以[x][y]P的形式生成会话密钥。然后使用该会话密钥生成第5.1节中规定的TGK。
Upon receiving and IBE-decrypting an R_MESSAGE_1 message, the Initiator verifies the received [x]P. At this point, the Initiator is able to generate the same session key as [x][y]P. Upon successful verification, the Initiator sends I_MESSAGE_2 message to the Responder, including IBE-encrypted IDRi, IDRr and previously received [y]P. The Responder sends a R_MESSAGE_2 message to the Initiator as verification.
在接收到R_消息_1并对其进行IBE解密后，发起方将验证收到的[x]P。此时，发起方能够生成与[x][y]P相同的会话密钥。验证成功后，发起方将向响应方发送I_消息_2消息，包括IBE加密的IDRi、IDRr和以前收到的[y]P.响应方向发起方发送一条R_消息_2消息作为验证。
The above described is the most typical use case; in Section 3, some alternative use cases are discussed.
上述是最典型的用例；在第3节中，讨论了一些替代用例。
MIKEY-IBAKE is based on [RFC3830]; therefore, the same terminology, processing, and considerations still apply unless otherwise stated. Payloads containing EC Diffie-Hellman values and keys exchanged in I_MESSAGE/R_MESSAGE are IBE encrypted as specified in [RFC5091] and [RFC5408], while the keys exchanged in KEY_REQUES_INIT/ KEY_REQUEST_RESPONSE are encrypted as specified in [RFC3830]. In all exchanges, encryption is only applied to the payloads containing keys and EC Diffie-Hellman values and not to the entire messages.
MIKEY-IBAKE基于[RFC3830]；因此，除非另有说明，否则相同的术语、处理和注意事项仍然适用。包含EC Diffie Hellman值和I_消息/R_消息中交换的密钥的有效载荷按照[RFC5091]和[RFC5408]中的规定进行IBE加密，而按照[RFC3830]中的规定对密钥请求/密钥请求/响应中交换的密钥进行加密。在所有交换中，加密只应用于包含密钥和EC Diffie-Hellman值的有效负载，而不应用于整个消息。
This exchange is used by a user (e.g., Initiator or Responder) to request Private Keys from a trusted Key Management Service, with which the user has pre-shared credentials. A full roundtrip is required for a user to receive keys. As this message must ensure the identity of the user to the KMS, it is protected via a MAC based on a pre-shared key or via a signature. The initiation message REQUEST_KEY_INIT comes in two variants corresponding to the pre-shared key (PSK) and Public-Key encryption (PKE) methods of [RFC3830]. The response message REQUEST_KEY_RESP is the same for the two variants and SHALL be protected by using the pre-shared/envelope key indicated in the REQUEST_KEY_INIT message.
用户（例如，发起方或响应方）使用此交换从可信密钥管理服务请求私钥，用户与该服务具有预共享凭据。用户需要完整的往返才能接收密钥。由于此消息必须确保用户对KMS的身份，因此它通过基于预共享密钥的MAC或签名进行保护。初始化消息请求_KEY_INIT有两种变体，分别对应于[RFC3830]的预共享密钥（PSK）和公钥加密（PKE）方法。响应消息REQUEST_KEY_RESP对于这两种变体是相同的，应使用REQUEST_KEY_INIT消息中指示的预共享/信封密钥进行保护。
Initiator/Responder KMS
发起方/响应方KMS
REQUEST_KEY_INIT_PSK = ---->
HDR, T, RAND, (IDRi/r),
IDRkms, [IDRpsk], [KEMAC], V <---- REQUEST_KEY_RESP =
HDR, T, [IDRi/r], [IDRkms],
KEMAC, V
REQUEST_KEY_INIT_PSK = ---->
HDR, T, RAND, (IDRi/r),
IDRkms, [IDRpsk], [KEMAC], V <---- REQUEST_KEY_RESP =
HDR, T, [IDRi/r], [IDRkms],
KEMAC, V
REQUEST_KEY_INIT_PKE = ---->
HDR, T, RAND, (IDRi/r),
{CERTi/r}, IDRkms, <---- REQUEST_KEY_RESP =
[KEMAC], [CHASH], HDR, T, [IDRi/r], [IDRkms],
PKE, SIGNi/r KEMAC, V
REQUEST_KEY_INIT_PKE = ---->
HDR, T, RAND, (IDRi/r),
{CERTi/r}, IDRkms, <---- REQUEST_KEY_RESP =
[KEMAC], [CHASH], HDR, T, [IDRi/r], [IDRkms],
PKE, SIGNi/r KEMAC, V
The main objective of the REQUEST_KEY_INIT message is for a user to request one or more Private Keys (K_PR) from the KMS. The user may request a K_PR for each public identity it possesses, as well as for multiple dates.
REQUEST_KEY_INIT消息的主要目的是让用户从KMS请求一个或多个私钥（K_PR）。用户可以为其拥有的每个公共身份以及多个日期请求K_PR。
The REQUEST_KEY_INIT message MUST always include the Header (HDR), Timestamp (T), and RAND payloads. The CSB ID (Crypto Session Bundle ID) SHALL be assigned as in [RFC3830]. The user SHALL include it in the CSB ID field of the Header. The user SHALL set the #CS field to '0' since CS (Crypto Session(s)) SHALL NOT be handled. The CS ID map type SHALL be the "Empty map" as defined in [RFC4563].
REQUEST_KEY_INIT消息必须始终包括头（HDR）、时间戳（T）和RAND有效负载。CSB ID（加密会话包ID）应按照[RFC3830]中的规定进行分配。用户应将其包含在标题的CSB ID字段中。用户应将#CS字段设置为“0”，因为不应处理CS（加密会话）。CS ID映射类型应为[RFC4563]中定义的“空映射”。
IDRi/r contains the identity of the user. Since the user may have multiple identities, multiple IDRi/r fields may appear in the message.
IDRi/r包含用户的标识。由于用户可能具有多个身份，消息中可能会出现多个IDRi/r字段。
IDRkms SHALL be included.
应包括IDRKM。
The KEMAC payload SHALL be used only when the user needs to use specific keys. Otherwise, this payload SHALL NOT be used.
仅当用户需要使用特定钥匙时，方可使用KEMAC有效载荷。否则，不得使用该有效载荷。
The IDRpsk payload MAY be used to indicate the pre-shared key used.
IDRpsk有效载荷可用于指示所使用的预共享密钥。
The last payload SHALL be a Verification (V) payload where the authentication key (auth_key) is derived from the pre-shared key (see Section 4.1.4 of [RFC3830] for key derivation specification).
最后一个有效载荷应为验证（V）有效载荷，其中认证密钥（auth_密钥）源自预共享密钥（密钥推导规范见[RFC3830]第4.1.4节）。
The certificate (CERT) payload SHOULD be included. If a certificate chain is to be provided, each certificate in the chain MUST be included in a separate CERT payload.
应包括证书（CERT）有效负载。如果要提供证书链，则链中的每个证书必须包含在单独的证书有效负载中。
The PKE payload contains the encrypted envelope key: PKE = E(PKkms, env_key). It is encrypted using the KMS's Public Key (PKkms). If the KMS possesses several Public Keys, the user can indicate the key used in the CHASH payload.
PKE有效负载包含加密的信封密钥：PKE=E（PKkms，env_-key）。它使用KMS的公钥（PKkms）进行加密。如果KMS拥有多个公钥，则用户可以指示CHASH有效载荷中使用的密钥。
SIGNi/r is a signature covering the entire MIKEY message, using the Initiator's signature key.
SIGNi/r是使用发起者的签名密钥覆盖整个MIKEY消息的签名。
If the KMS can verify the integrity of the received message and the message can be correctly parsed, the KMS MUST check the Initiator's authorization. If the Initiator is authorized to receive the requested Private Key(s), the KMS MUST send a REQUEST_KEY_RESP message. Unexpected payloads in the REQUEST_KEY_INIT message SHOULD be ignored. Errors are handled as described in [RFC3830].
如果KMS可以验证接收到的消息的完整性，并且消息可以正确解析，则KMS必须检查启动器的授权。如果启动器被授权接收请求的私钥，KMS必须发送请求密钥响应消息。应忽略请求\密钥\初始化消息中的意外有效负载。按照[RFC3830]中的说明处理错误。
The version, PRF func and CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL be identical to the corresponding fields in the REQUEST_KEY_INIT message. The KMS SHALL set the V flag to 0 and the user receiving it SHALL ignore it as it has no meaning in this context.
HDR有效载荷中的版本、PRF func和CSB ID、#CS和CS ID映射类型字段应与REQUEST_KEY_INIT消息中的相应字段相同。KMS应将V标志设置为0，接收V标志的用户应忽略该标志，因为它在本上下文中没有任何意义。
The Timestamp type and value SHALL be identical to the one used in the REQUEST_KEY_INIT message.
时间戳类型和值应与请求\密钥\初始化消息中使用的时间戳类型和值相同。
KEMAC = E(encr_key, (ID || K_PR))
KEMAC=E（encr|U键，（ID|K|U PR））
The KEMAC payload SHOULD use the NULL authentication algorithm, as a MAC is included in the V payload. Depending on the type of REQUEST_KEY_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the encr_key.
KEMAC有效载荷应使用空认证算法，因为MAC包含在V有效载荷中。根据请求密钥初始化消息的类型，应使用预共享密钥或信封密钥来导出encr密钥。
The last payload SHALL be a Verification (V) payload. Depending on the type of REQUEST_KEY_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the auth_key.
最后一个有效载荷应为验证（V）有效载荷。根据请求密钥初始化消息的类型，应使用预共享密钥或信封密钥来派生验证密钥。
If the Initiator/Responder can correctly parse the received message, the received session information SHOULD be stored. Otherwise, the Initiator/Responder SHOULD silently discard the message and abort the protocol.
如果发起方/响应方能够正确解析接收到的消息，则应存储接收到的会话信息。否则，发起方/响应方应自动放弃消息并中止协议。
This exchange is used for Initiator and Responder to mutually authenticate each other and to exchange EC Diffie-Hellman values used to generate TGK. These exchanges are modeled after the pre-shared key mode, with the exception that the Elliptic Curve Diffie-Hellman values and Secret Keys (SKs) are encoded in IBAKE and ESK payloads instead of a KEMAC payload. Two full roundtrips are required for this exchange to successfully complete. The messages are preferably included in the session setup signaling (e.g., SIP INVITE).
此交换用于启动器和响应程序相互验证，并交换用于生成TGK的EC Diffie-Hellman值。这些交换按照预共享密钥模式建模，但椭圆曲线Diffie-Hellman值和密钥（SKs）编码在IBAKE和ESK有效载荷中，而不是KEMAC有效载荷中。要成功完成此交换，需要两次完整往返。消息优选地包括在会话设置信令（例如，SIP INVITE）中。
Initiator Responder
发起者响应者
I_MESSAGE_1 = ---->
HDR, T, RAND, IDRi, IDRr,
IBAKE, [ESK] <---- R_MESSAGE_1 =
HDR, T, IDRi,
IDRr, IBAKE
I_MESSAGE_1 = ---->
HDR, T, RAND, IDRi, IDRr,
IBAKE, [ESK] <---- R_MESSAGE_1 =
HDR, T, IDRi,
IDRr, IBAKE
I_MESSAGE_2 = ---->
HDR, T, RAND, IDRi, IDRr,
IBAKE, [ESK] <---- R_MESSAGE_2 =
HDR, T, [IDRi], [IDRr],
[IBAKE], V
I_MESSAGE_2 = ---->
HDR, T, RAND, IDRi, IDRr,
IBAKE, [ESK] <---- R_MESSAGE_2 =
HDR, T, [IDRi], [IDRr],
[IBAKE], V
The I_MESSAGE_1 message MUST always include the Header (HDR), Timestamp (T), and RAND payloads. The CSB ID (Crypto Session Bundle ID) SHALL be randomly selected by the Initiator. As the R_MESSAGE_1 message is mandatory, the Initiator indicates with the V flag that a verification message is expected.
I_消息_1消息必须始终包括标头（HDR）、时间戳（T）和随机有效载荷。CSB ID（加密会话包ID）应由启动器随机选择。由于R_消息_1消息是必需的，因此启动器使用V标志指示需要验证消息。
The IDRi and IDRr payloads SHALL be included.
应包括IDRi和IDRr有效载荷。
The IBAKE payload contains Initiator's Identity and EC Diffie-Hellman values (ECCPTi), and Responder's Identity all encrypted using Responder's Public Key (i.e., encr_key = K_PUBr) as follows:
IBAKE有效载荷包含启动器的标识和EC Diffie Hellman值（ECCPTi），以及使用响应者公钥（即encr_Key=K_PUBr）加密的响应者标识，如下所示：
IBAKE = E(encr_key, IDRi || ECCPTi || IDRr)
IBAKE=E（加密密钥，IDRi | | | ECCPTi | IDRr）
Optionally, Encrypted Secret Key (ESK) payload MAY be included. If included, ESK contains an identity and a Secret Key (SK) encrypted using intended Responder's Public Key (i.e., encr_key = K_PUBr).
可选地，可以包括加密密钥（ESK）有效载荷。如果包括ESK，则ESK包含使用预期响应者的公钥（即encr_Key=K_PUBr）加密的身份和密钥（SK）。
ESK = E(encr_key, ID || SK)
ESK=E（encr|U键，ID|SK）
The parsing of I_MESSAGE_1 message SHALL be done as in [RFC3830]. If the received message is correctly parsed, the Responder SHALL use the Private Key (K_PRr) corresponding to the received IDRr to decrypt the IBAKE payload. If the message contains ESK payload, the Responder SHALL decrypt the SK and use it to decrypt the received IBAKE payload. Otherwise, if the Responder is not able to decrypt the
I_消息_1消息的解析应按照[RFC3830]进行。如果接收到的消息被正确解析，响应者应使用与接收到的IDRr相对应的私钥（K_PRr）来解密IBAKE有效载荷。如果消息包含ESK有效载荷，响应者应解密SK并使用其解密接收到的IBAKE有效载荷。否则，如果响应程序无法解密
IBAKE payload, the Responder SHALL indicate it to the Initiator by including only its own EC Diffie-Hellman value (ECCPTr) in the next message (i.e., R_MESSAGE_1) it sends to the Initiator.
对于有效载荷，响应方应通过在其发送给发起方的下一条消息（即R_消息_1）中仅包含其自身的EC Diffie Hellman值（ECCPTr）来向发起方指示有效载荷。
If the received message cannot be correctly parsed, the Responder SHOULD silently discard the message and abort the protocol.
如果无法正确解析接收到的消息，响应者应自动放弃该消息并中止协议。
The version, PRF func, CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL be identical to the corresponding fields in the I_MESSAGE_1 message. The V flag SHALL be set to 1 as I_MESSAGE_2 message is mandatory.
HDR有效载荷中的版本、PRF func、CSB ID、#CS和CS ID映射类型字段应与I#U消息#1消息中的相应字段相同。V标志应设置为1，因为I_消息_2消息是强制性的。
The Timestamp type and value SHALL be identical to the one used in the I_MESSAGE_1 message.
时间戳类型和值应与I_消息_1消息中使用的时间戳类型和值相同。
The IDRi and IDRr payloads SHALL be included. The IDRi payload SHALL be as received in the I_MESSAGE_1. In the IDRr payload, the Responder SHALL include its own identity. Note that this identity might be different from the identity contained in the IDRr payload received in I_MESSAGE_1 message. The IDRr payloads of I_MESSAGE_1 and R_MESSAGE_1 will be different in the case of forking, retargeting, and deferred delivery.
应包括IDRi和IDRr有效载荷。IDRi有效载荷应与I_消息_1中接收的相同。在IDRr有效载荷中，响应者应包括自己的身份。请注意，此标识可能与I_MESSAGE_1消息中接收的IDRr有效负载中包含的标识不同。在分叉、重定目标和延迟传递的情况下，I_消息_1和R_消息_1的IDRr有效负载将不同。
The Responder's IBAKE payload contains the Initiator's EC Diffie-Hellman value (ECCPTi) received in I_MESSAGE_1 (if successfully decrypted), and the Initiator's EC Diffie-Hellman value generated by the Responder (ECCPTr), as well as corresponding Initiator and Responder's identities. If the Responder is unable to decrypt the IBAKE payload received in I_MESSAGE_1 (e.g., the message is received by the intended Responder's mailbox), the Responder SHALL include only its own EC Diffie-Hellman value (ECCPTr). The IBAKE payload in R_MESSAGE_1 is encrypted using Initiator's Public Key (i.e., encr_key = P_PUBi) as follows:
响应者的IBAKE有效负载包含I_消息_1中接收到的启动器的EC Diffie Hellman值（ECCPTi）（如果成功解密），以及响应者生成的启动器的EC Diffie Hellman值（ECCPTr），以及相应的启动器和响应者的标识。如果响应者无法解密I_消息_1中接收的IBAKE有效载荷（例如，该消息由预期响应者的邮箱接收），响应者应仅包括其自身的EC Diffie Hellman值（ECCPTr）。R_消息_1中的IBAKE有效负载使用启动器的公钥（即encr_Key=P_PUBi）进行加密，如下所示：
IBAKE = E(encr_key, IDRi || {ECCPTi} || IDRr || ECCPTr)
IBAKE = E(encr_key, IDRi || {ECCPTi} || IDRr || ECCPTr)
The parsing of R_MESSAGE_1 message SHALL be done as in [RFC3830]. If the received message is correctly parsed, the Initiator shall use the Private Key corresponding to the received IDRi to decrypt the IBAKE payload. If the ECCPTi sent in I_MESSAGE_1 is not present in the received IBAKE payload (e.g., the Responder is currently offline and the R_MESSAGE_1 is received from Responder's mailbox), the Initiator
R_消息_1消息的解析应按照[RFC3830]进行。如果正确解析接收到的消息，则发起方应使用与接收到的IDRi相对应的私钥来解密IBAKE有效负载。如果在I_消息_1中发送的ECCPTi在接收到的IBAKE有效负载中不存在（例如，响应者当前处于脱机状态，并且从响应者的邮箱接收到R_消息_1），则发起方
SHALL include ECCPTi again in the next message, I_MESSAGE_2. In this case, I_MESSAGE_2 SHALL also contain an ESK payload encrypted using the intended recipient's K_PUB.
应在下一条消息I_消息2中再次包含ECCPTi。在这种情况下，I_消息_2还应包含使用预期收件人的K_PUB加密的ESK有效负载。
If the received message cannot be correctly parsed, the Initiator SHOULD silently discard the message and abort the protocol.
如果无法正确解析接收到的消息，则发起程序应自动放弃该消息并中止协议。
The I_MESSAGE_2 message MUST always include the Header (HDR), Timestamp (T), and RAND payloads. The version, PRF func, CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL be identical to the corresponding fields in the R_MESSAGE_2 message. As the R_MESSAGE_2 message is mandatory, the Initiator indicates with the V flag that a verification message is expected.
I_MESSAGE_2消息必须始终包括头（HDR）、时间戳（T）和随机有效载荷。HDR有效载荷中的版本、PRF func、CSB ID、#CS和CS ID映射类型字段应与R#U消息_2消息中的相应字段相同。由于R_消息_2消息是必需的，因此启动器使用V标志指示需要验证消息。
The IDRi and IDRr payloads SHALL be included. The IDRr payload SHALL be the same as the IDRr payload received in the R_MESSAGE_1.
应包括IDRi和IDRr有效载荷。IDRr有效载荷应与R_消息_1中接收到的IDRr有效载荷相同。
The Initiator's IBAKE payload SHALL contain the Initiator's EC Diffie-Hellman value (ECCPTi) if the ECCPTi was not received in R_MESSAGE_1. Otherwise, ECCPTi SHALL NOT be included. The IBAKE payload in I_MESSAGE_2 SHALL contain the Initiator's and Responder's identities as well as Responder's EC Diffie-Hellman value received in message R_MESSAGE_1. IBAKE payload SHALL be encrypted using Responder's Public Key (i.e., encr_key = K_PUBr) as follows:
如果在R_消息_1中未收到ECCPTi，则启动器的IBAKE有效载荷应包含启动器的EC Diffie Hellman值（ECCPTi）。否则，不包括ECCPTi。I_消息_2中的IBAKE有效载荷应包含发起者和响应者的身份以及在消息R_消息_1中接收到的响应者的EC Diffie Hellman值。IBAKE有效载荷应使用响应者的公钥（即encr_Key=K_PUBr）进行加密，如下所示：
IBAKE = E(encr_key, IDRi || {ECCPTi} || IDRr || ECCPTr)
IBAKE = E(encr_key, IDRi || {ECCPTi} || IDRr || ECCPTr)
Optionally, Encrypted Secret Key (ESK) payload can be included. ESK SHALL be included in case R_MESSAGE_1 did not contain Initiator's EC Diffie-Hellman value (ECCPTi) (e.g., in the case of deferred delivery). If included, it contains an Initiator's identity and Initiator-generated Secret Key (SK) encrypted using intended recipient Public Key (i.e., encr_key = K_PUB) as follows:
可选地，可以包括加密密钥（ESK）有效负载。如果R_报文_1不包含发起者的EC Diffie-Hellman值（ECCPTi）（例如，在延迟交付的情况下），则应包含ESK。如果包括，它包含启动器的身份和启动器生成的密钥（SK），使用预期收件人公钥（即encr_Key=K_PUB）加密，如下所示：
ESK = E(encr_key, ID || SK)
ESK=E（encr|U键，ID|SK）
The parsing of the I_MESSAGE_2 message SHALL be done as in [RFC3830]. If the received message is correctly parsed, the Responder shall use the K_PRr corresponding to the received IDRr to decrypt the IBAKE payload. If an ESK is received, the Responder SHALL store it for future use (e.g., the Responder is a mailbox and will forward the key to the user once the user is online).
I_消息_2消息的解析应按照[RFC3830]进行。如果接收到的消息被正确解析，响应者应使用与接收到的IDRr相对应的K_PRr对IBAKE有效载荷进行解密。如果收到ESK，响应者应将其存储起来以备将来使用（例如，响应者是一个邮箱，一旦用户联机，就会将密钥转发给用户）。
If the received message cannot be correctly parsed, the Responder SHOULD silently discard the message and abort the protocol.
如果无法正确解析接收到的消息，响应者应自动放弃该消息并中止协议。
The version, PRF func, CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL be identical to the corresponding fields in the I_MESSAGE_2 message. The V flag SHALL be set to 0 by the Responder and ignored by the Initiator.
HDR有效载荷中的版本、PRF func、CSB ID、#CS和CS ID映射类型字段应与I#U消息_2消息中的相应字段相同。V标志应由响应者设置为0，并由发起人忽略。
The Timestamp type and value SHALL be identical to the one used in the I_MESSAGE_2 message.
时间戳类型和值应与I_消息_2消息中使用的时间戳类型和值相同。
The IDRi and IDRr payloads SHOULD be included.
应包括IDRi和IDRr有效载荷。
If Initiator's EC Diffie-Hellman value (ECCPTi) was received in I_MESSAGE_2, the Responder SHALL also include the IBAKE payload. If included, the IBAKE payload SHALL contain Initiator's EC Diffie-Hellman value (ECCPTi), and the Initiator's identity previously received in I_MESSAGE_2, encrypted using Initiator's Public Key (i.e., encr_key = K_PUBi) as follows:
如果在I_消息_2中接收到发起方的EC Diffie Hellman值（ECCPTi），则响应方还应包括IBAKE有效载荷。如果包含，IBAKE有效载荷应包含启动器的EC Diffie Hellman值（ECCPTi）和先前在I_消息_2中接收到的启动器身份，使用启动器的公钥（即encr_Key=K_PUBi）加密，如下所示：
IBAKE = E(encr_key, IDRi || ECCPTi)
IBAKE=E（加密密钥，IDRi | | ECCPTi）
The last payload SHALL be a Verification (V) payload where the authentication key (auth_key) is derived as specified in Section 5.2.
最后一个有效载荷应为验证（V）有效载荷，其中验证密钥（auth_密钥）是根据第5.2节的规定推导的。
The parsing of R_MESSAGE_2 message SHALL be done as in [RFC3830]. If the received message is correctly parsed, and if it contains the IBAKE payload, the Initiator SHALL use the K_PRi corresponding to the received IDRi to decrypt the IBAKE payload.
R_消息_2消息的解析应按照[RFC3830]进行。如果接收到的消息被正确解析，并且如果它包含IBAKE有效载荷，则发起方应使用与接收到的IDRi相对应的K_PRi来解密IBAKE有效载荷。
If the received message cannot be correctly parsed, the Initiator SHOULD silently discard the message and abort the protocol.
如果无法正确解析接收到的消息，则发起程序应自动放弃该消息并中止协议。
The keys used in REQUEST_KEY_INIT/REQUEST_KEY_RESP exchange are derived from the pre-shared key or the envelope key as specified in [RFC3830]. As crypto sessions are not handled in this exchange, further keying material (i.e., TEKs) for this message exchange SHALL NOT be derived.
请求密钥初始化/请求密钥响应交换中使用的密钥源自[RFC3830]中规定的预共享密钥或信封密钥。由于加密会话不在本次交换中处理，因此不应衍生出本次消息交换的进一步密钥材料（即TEK）。
As stated above, the session key [x][y]P is generated using exchanged EC Diffie-Hellman values, where x and y are randomly chosen by the Initiator and Responder. The session key, as a point on an elliptic curve, is then converted into octet string as specified in [SEC1]. This octet string K_SESSION is then used to generate MPK and TGK. Finally, the traffic encryption keys (e.g., TEK) are generated from TGK as specified in [RFC3830].
如上所述，使用交换的EC-Diffie-Hellman值生成会话密钥[x][y]P，其中x和y由发起方和响应方随机选择。会话密钥作为椭圆曲线上的一个点，然后按照[SEC1]中的规定转换为八位字节字符串。然后使用这个八位组字符串K_会话生成MPK和TGK。最后，根据[RFC3830]中的规定，从TGK生成流量加密密钥（例如TEK）。
The MPK and TGK are generated from K_SESSION as follows.
MPK和TGK由K_会话生成，如下所示。
inkey : K_SESSION inkey_len : bit length of the MPK label : constant || 0xFF || 0xFFFFFFFF || RAND outkey_len : desired bit length of the output key (MPK or TGK)
inkey:K|U会话inkey|len:MPK标签的位长度：常量| | 0xFF | | 0xFFFFFF | | RAND outkey|len：输出键（MPK或TGK）的所需位长度
The constant depends on the derived key type as summarized below.
该常数取决于派生键类型，如下所述。
+-------------+------------+
| Derived Key | Constant |
+-------------+------------+
| MPK | 0x220E99A2 |
| TGK | 0x1F4D675B |
+-------------+------------+
+-------------+------------+
| Derived Key | Constant |
+-------------+------------+
| MPK | 0x220E99A2 |
| TGK | 0x1F4D675B |
+-------------+------------+
Table 1: Constants for Key Derivation
表1：键派生的常数
The constants are taken from the decimal digits of e as described in [RFC3830].
常数取自[RFC3830]中所述的e的十进制数字。
The keys for MIKEY messages are used to protect the MIKEY messages exchanged between the Initiator and Responder (i.e., I_MESSAGE and R_MESSAGE). In the REQUEST_KEY_INIT/REQUEST_KEY_RESP exchange, the key derivation SHALL be done exactly as in [RFC3830].
MIKEY消息的密钥用于保护发起方和响应方之间交换的MIKEY消息（即i_消息和R_消息）。在REQUEST_KEY_INIT/REQUEST_KEY_RESP交换中，密钥推导应完全按照[RFC3830]中的要求进行。
MIKEY Protection Key (MPK) for I_MESSAGE/R_MESSAGE exchange is generated as described in Section 5.1. This MPK is then used to derive keys to protect R_MESSAGE_2 message.
I_消息/R_消息交换的MIKEY保护密钥（MPK）如第5.1节所述生成。然后，该MPK用于派生密钥以保护R_消息\u 2消息。
inkey : MPK inkey_len : bit length of the MPK label : constant || 0xFF || csb_id || RAND outkey_len : desired bit length of the output key
inkey:MPK inkey|len:MPK标签的位长度：常量| | 0xFF | | csb|U id | RAND outkey|len：输出键的所需位长度
where the constants are as defined in [RFC3830].
其中常数如[RFC3830]中所定义。
Similar to [RFC3830], MIKEY-IBAKE provides means for updating the CSB (Crypto Session Bundle), e.g., transporting new EC Diffe-Hellman values or adding new crypto sessions. The CSB updating is done by executing the exchange of I_MESSAGE_1/R_MESSAGE_1. The CSB updating MAY be started by either the Initiator or the Responder.
与[RFC3830]类似，MIKEY-IBAKE提供了更新CSB（加密会话包）的方法，例如，传输新的EC Diffe Hellman值或添加新的加密会话。CSB更新是通过执行I_消息_1/R_消息_1的交换来完成的。CSB更新可由发起方或响应方启动。
Initiator Responder
发起者响应者
I_MESSAGE_1 = ---->
HDR, T, [IDRi], [IDRr],
[IBAKE] <---- R_MESSAGE_1 =
HDR, T, [IDRi], [IDRr],
[IBAKE], V
I_MESSAGE_1 = ---->
HDR, T, [IDRi], [IDRr],
[IBAKE] <---- R_MESSAGE_1 =
HDR, T, [IDRi], [IDRr],
[IBAKE], V
Responder Initiator
应答器启动器
I_MESSAGE_1 = ---->
HDR, T, [IDRr], [IDRi],
[IBAKE] <---- R_MESSAGE_1 =
HDR, T, [IDRi], [IDRr],
[IBAKE], V
I_MESSAGE_1 = ---->
HDR, T, [IDRr], [IDRi],
[IBAKE] <---- R_MESSAGE_1 =
HDR, T, [IDRi], [IDRr],
[IBAKE], V
The new message exchange MUST use the same CSB ID as the initial exchange, but MUST use a new Timestamp. Other payloads that were provided in the initial exchange SHOULD NOT be included. New RANDs MUST NOT be included in the message exchange (the RANDs will only have effect in the initial exchange).
新消息交换必须使用与初始交换相同的CSB ID，但必须使用新的时间戳。初始交换中提供的其他有效载荷不应包括在内。消息交换中不得包含新的RAND（RAND仅在初始交换中有效）。
IBAKE payload with new EC Diffie-Hellman values SHOULD be included. If new EC Diffie-Hellman values are being exchanged during CSB updating, messages SHALL be protected with keys derived from EC Diffie-Hellman values exchanged as specified in Section 5.2. Otherwise, if new EC Diffie-Hellman values are not being exchanged during CSB update exchange, messages SHALL be protected with the keys that protected the I_MESSAGE/R_MESSAGE messages in the initial exchange.
应包括具有新EC Diffie-Hellman值的IBAKE有效载荷。如果在CSB更新期间交换新的EC Diffie-Hellman值，则应使用根据第5.2节规定交换的EC Diffie-Hellman值派生的密钥保护消息。否则，如果在CSB更新交换期间没有交换新的EC Diffie-Hellman值，则应使用在初始交换中保护I_消息/R_消息的密钥来保护消息。
The authentication tag in all MIKEY-IBAKE messages is generated as described in [RFC3830]. As described above, the MPK is used to derive the auth_key. The MAC/Signature in the V/SIGN payloads covers the entire MIKEY message, except the MAC/Signature field itself and if there is an ESK payload in the massage it SHALL be omitted from MAC/Signature calculation. The identities (not whole payloads) of
所有MIKEY-IBAKE消息中的身份验证标签均按照[RFC3830]中的说明生成。如上所述，MPK用于导出auth_密钥。V/SIGN有效载荷中的MAC/签名覆盖整个MIKEY消息，MAC/签名字段本身除外，如果消息中存在ESK有效载荷，则应将其从MAC/签名计算中忽略。的身份（不是全部有效载荷）
the involved parties MUST directly follow the MIKEY message in the Verification MAC/Signature calculation. Note that in the I_MESSAGE/ R_MESSAGE exchange, IDRr in R_MESSAGE_1 MAY not be the same as that appearing in I_MESSAGE_1.
相关方必须在验证MAC/签名计算中直接遵循MIKEY消息。请注意，在I_消息/R_消息交换中，R_消息_1中的IDRr可能与I_消息_1中出现的IDRr不同。
This section does not describe all the payloads that are used in the new message types. It describes in detail the new IBAKE and ESK payloads and in less detail the payloads for which changes has been made compared to [RFC3830]. For a detailed description of the MIKEY payloads (e.g., Timestamp (T) payload, RAND payload, etc.), see [RFC3830]. For the description of IDR payload as well as for the definition of additional PRF functions and encryption algorithms not defined in [RFC3830], see [RFC6043].
本节不描述新消息类型中使用的所有有效负载。它详细描述了新的IBAKE和ESK有效载荷，并与[RFC3830]相比，对已进行更改的有效载荷进行了较不详细的描述。有关MIKEY有效载荷（例如，时间戳（T）有效载荷、兰德有效载荷等）的详细说明，请参阅[RFC3830]。有关IDR有效载荷的说明以及[RFC3830]中未定义的其他PRF函数和加密算法的定义，请参阅[RFC6043]。
For the Common Header Payload, new values are added to the data type and the next payload namespaces.
对于公共头有效负载，将向数据类型和下一个有效负载名称空间添加新值。
o Data type (8 bits): describes the type of message.
o 数据类型（8位）：描述消息的类型。
+------------------+-------+------------------------------------+
| Data Type | Value | Comment |
+------------------+-------+------------------------------------+
| REQUEST_KEY_PSK | 19 | Request Private Keys message (PSK) |
| REQUEST_KEY_PKE | 20 | Request Private Keys message (PKE) |
| REQUEST_KEY_RESP | 21 | Response Private Keys message |
| I_MESSAGE_1 | 22 | First Initiator's message |
| R_MESSAGE_1 | 23 | First Responder's message |
| I_MESSAGE_2 | 24 | Second Initiator's message |
| R_MESSAGE_2 | 25 | Second Responder's message |
+------------------+-------+------------------------------------+
+------------------+-------+------------------------------------+
| Data Type | Value | Comment |
+------------------+-------+------------------------------------+
| REQUEST_KEY_PSK | 19 | Request Private Keys message (PSK) |
| REQUEST_KEY_PKE | 20 | Request Private Keys message (PKE) |
| REQUEST_KEY_RESP | 21 | Response Private Keys message |
| I_MESSAGE_1 | 22 | First Initiator's message |
| R_MESSAGE_1 | 23 | First Responder's message |
| I_MESSAGE_2 | 24 | Second Initiator's message |
| R_MESSAGE_2 | 25 | Second Responder's message |
+------------------+-------+------------------------------------+
Table 2: Data Type (Additions)
表2：数据类型（新增）
o Next payload (8 bits): identifies the payload that is added after this payload.
o 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
+--------------+-------+---------------+
| Next Payload | Value | Section |
+--------------+-------+---------------+
| IBAKE | 22 | Section 6.1.1 |
| ESK | 23 | Section 6.1.2 |
| SK | 24 | Section 6.1.5 |
| ECCPT | 25 | Section 6.1.4 |
+--------------+-------+---------------+
+--------------+-------+---------------+
| Next Payload | Value | Section |
+--------------+-------+---------------+
| IBAKE | 22 | Section 6.1.1 |
| ESK | 23 | Section 6.1.2 |
| SK | 24 | Section 6.1.5 |
| ECCPT | 25 | Section 6.1.4 |
+--------------+-------+---------------+
Table 3: Next Payload (Additions)
表3：下一个有效载荷（增加）
o V (1 bits): flag to indicate whether or not a response message is expected (this only has meaning when it is set in an initiation message). If a response is required, the V flag SHALL always be set to 1 in the initiation messages and the receiver of the initiation message (Responder or KMS) SHALL ignore it.
o V（1位）：指示是否预期响应消息的标志（仅当在启动消息中设置时才有意义）。如果需要响应，则启动消息中的V标志应始终设置为1，且启动消息的接收者（响应者或KMS）应忽略该标志。
o #CS (8 bits): indicates the number of crypto sessions that will be handled within the CSB. It SHALL be set to 0 in the Request Key exchange, as crypto sessions SHALL NOT be handled.
o #CS（8位）：表示将在CSB内处理的加密会话数。在请求密钥交换中应将其设置为0，因为不应处理加密会话。
o CS ID map type (8 bits): specifies the method of uniquely mapping crypto sessions to the security protocol sessions. In the Request Key exchange, the CS ID map type SHALL be the "Empty map" (defined in [RFC4563]) as crypto sessions SHALL NOT be handled.
o CS ID映射类型（8位）：指定将加密会话唯一映射到安全协议会话的方法。在请求密钥交换中，CS ID映射类型应为“空映射”（在[RFC4563]中定义），因为不应处理加密会话。
The IBAKE payload contains IBE encrypted (see [RFC5091] and [RFC5408] for details about IBE) Initiator and Responder's Identities and EC Diffie-Hellman Sub-Payloads (see Section 6.1.4 for the definition of EC Diffie-Hellman Sub-Payload). It may contain one or more EC Diffie-Hellman Sub-Payloads and their associated identities. The last EC Diffie-Hellman or Identity Sub-Payload has its Next payload field set to Last payload.
IBAKE有效载荷包含IBE加密（有关IBE的详细信息，请参见[RFC5091]和[RFC5408]）启动器和响应者的身份以及EC Diffie-Hellman子有效载荷（EC Diffie-Hellman子有效载荷的定义，请参见第6.1.4节）。它可能包含一个或多个EC Diffie-Hellman子有效载荷及其相关标识。最后一个EC Diffie-Hellman或Identity子有效载荷将其下一个有效载荷字段设置为最后一个有效载荷。
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 ! Encr data len ! Encr data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr 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 ! Encr data len ! Encr data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Next payload (8 bits): identifies the payload that is added after this payload.
o 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
o Encr data len (16 bits): length of Encr data (in bytes).
o Encr数据长度（16位）：Encr数据的长度（字节）。
o Encr data (variable length): the IBE encrypted EC Diffie-Hellman Sub-Payloads (see Section 6.1.4) and their associated Identity payloads.
o Encr数据（可变长度）：IBE加密的EC Diffie-Hellman子有效载荷（见第6.1.4节）及其相关标识有效载荷。
The Encrypted Secret Key payload contains IBE encrypted (see [RFC5091] and [RFC5408] for details about IBE) Secret Key Sub-Payload and its associated identity (see Section 6.1.5 for the definition of the Secret Key Sub-Payload).
加密密钥有效载荷包含IBE加密（有关IBE的详细信息，请参阅[RFC5091]和[RFC5408]）密钥子有效载荷及其相关标识（有关密钥子有效载荷的定义，请参阅第6.1.5节）。
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 ! Encr data len ! Encr data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr 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 ! Encr data len ! Encr data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Next payload (8 bits): identifies the payload that is added after this payload.
o 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
o Encr data len (16 bits): length of Encr data (in bytes).
o Encr数据长度（16位）：Encr数据的长度（字节）。
o Encr data (variable length): the encrypted secret key Sub-Payloads (see Section 6.1.5).
o Encr数据（可变长度）：加密密钥子有效载荷（见第6.1.5节）。
For the key data Sub-Payload, a new type of key is defined. The Private Key (K_PR) is used to decrypt the content encrypted using the corresponding Public Key (K_PUB). KEMAC in the REQUEST_KEY_RESP SHALL contain one or more Private Keys.
对于密钥数据子有效载荷，定义了一种新类型的密钥。私钥（K_PR）用于解密使用相应公钥（K_PUB）加密的内容。请求密钥响应中的KEMAC应包含一个或多个私钥。
o Type (4 bits): indicates the type of key included in the payload.
o 类型（4位）：指示有效负载中包含的密钥类型。
+------+-------+-------------+
| Type | Value | Comments |
+------+-------+-------------+
| K_PR | 7 | Private Key |
+------+-------+-------------+
+------+-------+-------------+
| Type | Value | Comments |
+------+-------+-------------+
| K_PR | 7 | Private Key |
+------+-------+-------------+
Table 4: Key Data Type (Additions)
表4：关键数据类型（增补）
The EC Diffie-Hellman (ECCPT) Sub-Payload uses the format defined below. The EC Diffie-Hellman Sub-Payload in MIKEY-IBAKE is never included in clear, but as an encrypted part of the IBAKE payload.
EC Diffie-Hellman（ECCPT）子有效载荷使用以下定义的格式。MIKEY-IBAKE中的EC Diffie-Hellman子负载从未包含在clear中，而是作为IBAKE负载的加密部分。
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 ! ECC Curve ! ECC Point ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Auth alg ! TGK len ! Reserv! KV !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ! ECC Curve ! ECC Point ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Auth alg ! TGK len ! Reserv! KV !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 of [RFC3830] for values.
o 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见[RFC3830]第6.1节。
o ECC curve (8 bits): identifies the ECC curve used.
o ECC曲线（8位）：标识使用的ECC曲线。
+--------------------------------------+-------+
| ECC Curve | Value |
+--------------------------------------+-------+
| ECPRGF192Random / P-192 / secp192r1 | 1 |
| EC2NGF163Random / B-163 / sect163r2 | 2 |
| EC2NGF163Koblitz / K-163 / sect163k1 | 3 |
| EC2NGF163Random2 / none / sect163r1 | 4 |
| ECPRGF224Random / P-224 / secp224r1 | 5 |
| EC2NGF233Random / B-233 / sect233r1 | 6 |
| EC2NGF233Koblitz / K-233 / sect233k1 | 7 |
| ECPRGF256Random / P-256 / secp256r1 | 8 |
| EC2NGF283Random / B-283 / sect283r1 | 9 |
| EC2NGF283Koblitz / K-283 / sect283k1 | 10 |
| ECPRGF384Random / P-384 / secp384r1 | 11 |
| EC2NGF409Random / B-409 / sect409r1 | 12 |
| EC2NGF409Koblitz / K-409 / sect409k1 | 13 |
| ECPRGF521Random / P-521 / secp521r1 | 14 |
| EC2NGF571Random / B-571 / sect571r1 | 15 |
| EC2NGF571Koblitz / K-571 / sect571k1 | 16 |
+--------------------------------------+-------+
+--------------------------------------+-------+
| ECC Curve | Value |
+--------------------------------------+-------+
| ECPRGF192Random / P-192 / secp192r1 | 1 |
| EC2NGF163Random / B-163 / sect163r2 | 2 |
| EC2NGF163Koblitz / K-163 / sect163k1 | 3 |
| EC2NGF163Random2 / none / sect163r1 | 4 |
| ECPRGF224Random / P-224 / secp224r1 | 5 |
| EC2NGF233Random / B-233 / sect233r1 | 6 |
| EC2NGF233Koblitz / K-233 / sect233k1 | 7 |
| ECPRGF256Random / P-256 / secp256r1 | 8 |
| EC2NGF283Random / B-283 / sect283r1 | 9 |
| EC2NGF283Koblitz / K-283 / sect283k1 | 10 |
| ECPRGF384Random / P-384 / secp384r1 | 11 |
| EC2NGF409Random / B-409 / sect409r1 | 12 |
| EC2NGF409Koblitz / K-409 / sect409k1 | 13 |
| ECPRGF521Random / P-521 / secp521r1 | 14 |
| EC2NGF571Random / B-571 / sect571r1 | 15 |
| EC2NGF571Koblitz / K-571 / sect571k1 | 16 |
+--------------------------------------+-------+
Table 5: Elliptic Curves
表5：椭圆曲线
o ECC point (variable length): ECC point data, padded to end on a 32-bit boundary, encoded in octet string representation.
o ECC点（可变长度）：ECC点数据，填充到32位边界上，以八位字符串表示编码。
o Auth alg (8 bits): specifies the MAC algorithm used for the verification message. For MIKEY-IBAKE this field is ignored.
o Auth alg（8位）：指定用于验证消息的MAC算法。对于MIKEY-IBAKE，此字段被忽略。
o TGK len (16 bits): the length of the TGK (in bytes). For MIKEY-IBAKE this field is ignored.
o TGK len（16位）：TGK的长度（以字节为单位）。对于MIKEY-IBAKE，此字段被忽略。
o KV (4 bits): indicates the type of key validity period specified. This may be done by using an SPI (alternatively an MKI in SRTP) or by providing an interval in which the key is valid (e.g., in the latter case, for SRTP this will be the index range where the key is valid). See Section 6.13 of [RFC3830] for pre-defined values.
o KV（4位）：表示指定的密钥有效期类型。这可以通过使用SPI（或者SRTP中的MKI）或通过提供密钥有效的间隔（例如，在后一种情况下，对于SRTP，这将是密钥有效的索引范围）来实现。预定义值见[RFC3830]第6.13节。
o KV data (variable length): This includes either the SPI/MKI or an interval (see Section 6.14 of [RFC3830]). If KV is NULL, this field is not included.
o KV数据（可变长度）：包括SPI/MKI或间隔（见[RFC3830]第6.14节）。如果KV为空，则不包括该字段。
Secret Key payload is included as a Sub-Payload in Encrypted Secret Key payload. Similar to EC Diffie-Hellman Sub-Payload, it is never included in clear, but as an encrypted part of the ESK payload.
密钥有效载荷作为子有效载荷包含在加密密钥有效载荷中。与EC Diffie-Hellman子负载类似，它从未包含在clear中，而是作为ESK负载的加密部分。
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 ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Next payload (8 bits): identifies the payload that is added after this payload.
o 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
o Type (4 bits): indicates the type of the key included in the payload.
o 类型（4位）：指示有效负载中包含的密钥类型。
+------+-------+
| Type | Value |
+------+-------+
| SK | 1 |
+------+-------+
+------+-------+
| Type | Value |
+------+-------+
| SK | 1 |
+------+-------+
Table 6: Secret Key Types
表6：密钥类型
o KV (4 bits): indicates the type of key validity period specified. This may be done by using an SPI (or MKI in the case of [RFC3711]) or by providing an interval in which the key is valid (e.g., in the latter case, for SRTP this will be the index range where the key is valid). KV values are the same as in Section 6.13 of [RFC3830]
o KV（4位）：表示指定的密钥有效期类型。这可以通过使用SPI（或[RFC3711]情况下的MKI）或通过提供密钥有效的间隔（例如，在后一种情况下，对于SRTP，这将是密钥有效的索引范围）来实现。KV值与[RFC3830]第6.13节中的值相同
o Key data len (16 bits): the length of the Key data field (in bytes).
o 密钥数据长度（16位）：密钥数据字段的长度（字节）。
o Key data (variable length): The SK data.
o 密钥数据（可变长度）：SK数据。
o KV data (variable length): This includes either the SPI or an interval. If KV is NULL, this field is not included.
o KV数据（可变长度）：这包括SPI或间隔。如果KV为空，则不包括该字段。
Unless explicitly stated, the security properties of the MIKEY protocol as described in [RFC3830] apply to MIKEY-IBAKE as well. In addition, MIKEY-IBAKE is based on the basic Identity-Based Encryption protocol, as specified in [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 KMS are also reduced without any reduction in security.
除非明确说明，[RFC3830]中所述的MIKEY协议的安全属性也适用于MIKEY-IBAKE。此外，MIKEY-IBAKE基于[RFC5091]、[RFC5408]和[RFC5409]中规定的基本基于身份的加密协议，因此继承了该协议的一些属性。例如，通过将“日期”与标识连接（以派生公钥），实际上不需要任何密钥撤销机制。此外，通过允许参与者获取多个私钥（例如，在合同期限内），KMS的可用性要求也在不降低任何安全性的情况下降低。
The MIKEY-IBAKE protocol relies on the use of Identity-Based Encryption. [RFC5091] describes attacks on the cryptographic algorithms used in Identity-Based Encryption. In addition, [RFC5091] provides recommendations for security parameters for described IBE algorithms.
MIKEY-IBAKE协议依赖于基于身份的加密。[RFC5091]描述了对基于身份的加密中使用的加密算法的攻击。此外，[RFC5091]为所述IBE算法的安全参数提供了建议。
It is assumed that the Key Management Services are secure, not compromised, trusted, and will not engage in launching active attacks independently or in a collaborative environment. However, 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 attacks, it is hard to eliminate this problem. Hence, it is assumed that such problems will persist, and hence the protocols are designed to protect participants from passive adversaries.
假定密钥管理服务是安全的、不受损害的、受信任的，并且不会独立或在协作环境中发起主动攻击。但是，任何恶意内幕人士都可能发起被动攻击（通过解密一个或多个脱机消息交换）。虽然防止此类攻击符合管理员的最佳利益，但很难消除此问题。因此，假设此类问题将持续存在，因此协议旨在保护参与者免受被动对手的攻击。
For the basic IBAKE protocol, from a cryptographic perspective, the following security considerations apply.
对于基本IBAKE协议，从加密角度来看，以下安全注意事项适用。
In every step, Identity-Based Encryption (IBE) is used with the recipient's Public Key. This guarantees that only the intended recipient of the message can decrypt the message [BF].
在每个步骤中，基于身份的加密（IBE）都与收件人的公钥一起使用。这保证了只有消息的预期收件人才能解密消息[BF]。
Next, the use of identities within the encrypted payload is intended to eliminate some basic reflection attacks. For instance, suppose identities were not used as part of the encrypted payload, in the first step of the IBAKE protocol (i.e., I_MESSAGE_1 of Figure 3 in Section 4.1). Furthermore, assume an adversary who has access to the conversation between Initiator and Responder and can actively snoop into 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 adversary's IP address, before routing it onto the Responder. The Responder will assume the request for an IBAKE session came from the adversary and will execute step 2 of the IBAKE protocol (i.e., R_MESSAGE_1 of Figure 3 in Section 4.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 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 Initiator and Responder can mutually authenticate each other and agree on a session key.
接下来，在加密有效载荷中使用身份旨在消除一些基本反射攻击。例如，假设在IBAKE协议的第一步中，身份未被用作加密有效负载的一部分（即，第4.1节图3中的i_消息_1）。此外，假设有一个对手可以访问发起方和响应方之间的对话，并且可以主动窥探数据包并在将它们路由到目的地之前丢弃/修改它们。例如，假设对手可以修改IP源地址和目标地址。发起方（向响应方）发送第一条消息后，对手可以接管并捕获数据包。接下来，敌方可以修改IP源地址以包括敌方的IP地址，然后再将其路由到响应方。响应者将假定IBAKE会话的请求来自对手，并将执行IBAKE协议的步骤2（即第4.1节图3的R_消息_1），但使用对手的公钥对其进行加密。上述消息可由对手解密（且仅由对手解密）。特别是，由于第二条消息包括发起者发送给响应者的质询，因此对手现在将学习发起者发送的质询。在此之后，对手可以“假装”是响应者与发起人进行对话。如果将身份用作加密负载的一部分，则此攻击将被消除。总之，在交换结束时，发起方和响应方都可以相互验证对方，并就会话密钥达成一致。
Recall that Identity-Based Encryption guarantees that only the recipient of the message can decrypt the message using the Private Key. The caveat being, the KMS that generated the Private Key of recipient of message can decrypt the message as well. However, the KMS cannot learn the session key [x][y]P given [x]P and [y]P based on the Elliptic Curve Diffie-Hellman problem. This property of resistance to passive key escrow from the KMS is not applicable to the basic IBE protocols proposed in [RFC5091], [RFC5408], and [RFC5409].
回想一下，基于身份的加密保证只有邮件的收件人可以使用私钥解密邮件。需要注意的是，生成消息接收方私钥的KMS也可以解密消息。然而，基于椭圆曲线Diffie-Hellman问题，KMS无法学习给定[x]P和[y]P的会话密钥[x][y]P。这种抵抗来自KMS的被动密钥托管的特性不适用于[RFC5091]、[RFC5408]和[RFC5409]中提出的基本IBE协议。
Observe that the protocol works even if the Initiator and Responder belong to two different Key Management Services. 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 [x][y]P can be completely different. If such flexibility is desired, then it would be advantageous to add optional extra data to the protocol to exchange the algebraic primitives used in deriving the session key.
对于加密，启动器可以完全不同且彼此独立。此外，用于生成会话密钥[x][y]P的椭圆曲线可以完全不同。如果需要这种灵活性，那么将可选的额外数据添加到协议中以交换用于导出会话密钥的代数原语将是有利的。
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 others, accidental leakage of one session key does not compromise past or future session keys between the same Initiator and Responder.
除了相互认证和抵抗被动托管外，会话密钥交换的Diffie-Hellman属性还保证了密钥的完美保密性。在其他情况下，一个会话密钥的意外泄漏不会影响同一启动器和响应程序之间过去或将来的会话密钥。
In the Forking feature, given that there are multiple potential Responders, it is important to observe that there is one "common Responder" identity (and corresponding Public and Private Keys) and each Responder has a unique identity (and corresponding Public and Private Keys). Observe that, in this framework, if one Responder responds to the invite from the Initiator, it uses its unique identity such that the protocol guarantees that no other Responder learns the session key.
在分叉功能中，鉴于存在多个潜在响应者，必须注意存在一个“公共响应者”身份（以及相应的公钥和私钥），并且每个响应者都有一个唯一的身份（以及相应的公钥和私钥）。注意，在此框架中，如果一个响应者响应来自发起方的邀请，它将使用其唯一标识，这样协议就保证没有其他响应者学习会话密钥。
In the Retargeting feature, the forwarding server does not learn the Private Key of the intended Responder since it is encrypted using the retargeted Responder's Public Key. Additionally, the Initiator will learn that the retargeted Responder answered the phone (and not the intended Responder) since the retargeted Responder includes its own identity in the message sent to the Initiator. This will allow the Initiator to decide whether or not to carry on the conversation. Finally, the session key cannot be discovered by the intended Responder since the random number chosen by the retargeted Responder is not known to the intended Responder.
在重定目标功能中，转发服务器不会学习预期响应者的私钥，因为它是使用重定目标响应者的公钥加密的。此外，发起者将了解到重定目标的响应者接听了电话（而不是预期的响应者），因为重定目标的响应者在发送给发起者的消息中包括其自己的身份。这将允许发起者决定是否继续对话。最后，由于预定响应者不知道重定目标响应者选择的随机数，因此预定响应者无法发现会话密钥。
In the Deferred Delivery feature, the Initiator and the Responder's mailbox will mutually authenticate each other thereby preventing server side "phishing" attacks and conversely guarantees to the server (and eventually to the Responder) the identity of the Initiator. Moreover, the key used by Initiator to encrypt the contents of the message is completely independent from the session key derived between the Initiator and the server. Finally, the key
在延迟传递功能中，发起方和响应方的邮箱将相互验证，从而防止服务器端的“网络钓鱼”攻击，并反过来向服务器（最终向响应方）保证发起方的身份。此外，启动器用于加密消息内容的密钥完全独立于在启动器和服务器之间派生的会话密钥。最后是关键
used to encrypt the message is encrypted using the Responder's Public Key, which allows the contents of the message to remain unknown to the mailbox server.
用于加密的邮件使用响应者的公钥进行加密，该公钥允许邮件内容对邮箱服务器保持未知状态。
This document defines several new values for the namespaces Data Type, Next Payload, and Key Data Type defined in [RFC3830]. The following IANA assignments have been added to the MIKEY Payload registry (in bracket is a reference to the table containing the registered values):
本文档为[RFC3830]中定义的名称空间数据类型、下一个有效负载和键数据类型定义了几个新值。以下IANA分配已添加到MIKEY Payload registry（括号中是对包含注册值的表的引用）：
o Data Type (see Table 2)
o 数据类型（见表2）
o Next Payload (see Table 3)
o 下一有效载荷（见表3）
o Key Data Type (see Table 4)
o 关键数据类型（见表4）
The ECCPT payload defines an 8-bit ECC Curve field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of an ECC curve and its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry are as follows:
ECCPT有效载荷定义了IANA为其创建的8位ECC曲线字段，并将在MIKEY有效载荷注册表中维护一个新的命名空间。指定由ECC曲线及其关联值组成。1-239范围内的值应通过所需的规范程序批准，240-254范围内的值供私人使用，0和255值根据[RFC5226]保留。登记处的初步内容如下：
Value ECC curve
------- ------------------------------------
0 Reserved
1 ECPRGF192Random / P-192 / secp192r1
2 EC2NGF163Random / B-163 / sect163r2
3 EC2NGF163Koblitz / K-163 / sect163k1
4 EC2NGF163Random2 / none / sect163r1
5 ECPRGF224Random / P-224 / secp224r1
6 EC2NGF233Random / B-233 / sect233r1
7 EC2NGF233Koblitz / K-233 / sect233k1
8 ECPRGF256Random / P-256 / secp256r1
9 EC2NGF283Random / B-283 / sect283r1
10 EC2NGF283Koblitz / K-283 / sect283k1
11 ECPRGF384Random / P-384 / secp384r1
12 EC2NGF409Random / B-409 / sect409r1
13 EC2NGF409Koblitz / K-409 / sect409k1
14 ECPRGF521Random / P-521 / secp521r1
15 EC2NGF571Random / B-571 / sect571r1
16 EC2NGF571Koblitz / K-571 / sect571k1
17-239 Unassigned
240-254 Private Use
255 Reserved
Value ECC curve
------- ------------------------------------
0 Reserved
1 ECPRGF192Random / P-192 / secp192r1
2 EC2NGF163Random / B-163 / sect163r2
3 EC2NGF163Koblitz / K-163 / sect163k1
4 EC2NGF163Random2 / none / sect163r1
5 ECPRGF224Random / P-224 / secp224r1
6 EC2NGF233Random / B-233 / sect233r1
7 EC2NGF233Koblitz / K-233 / sect233k1
8 ECPRGF256Random / P-256 / secp256r1
9 EC2NGF283Random / B-283 / sect283r1
10 EC2NGF283Koblitz / K-283 / sect283k1
11 ECPRGF384Random / P-384 / secp384r1
12 EC2NGF409Random / B-409 / sect409r1
13 EC2NGF409Koblitz / K-409 / sect409k1
14 ECPRGF521Random / P-521 / secp521r1
15 EC2NGF571Random / B-571 / sect571r1
16 EC2NGF571Koblitz / K-571 / sect571k1
17-239 Unassigned
240-254 Private Use
255 Reserved
The SK Sub-Payload defines a 4-bit Type field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of a type of key and its associated value. Values in the range 2-15 SHOULD be approved by the process of Specification Required. The initial contents of the registry are as follows:
SK子有效载荷定义了IANA为其创建的4位类型字段，并将在MIKEY有效载荷注册表中维护一个新名称空间。赋值由一类键及其关联值组成。2-15范围内的值应通过所需的规范流程批准。登记处的初步内容如下：
Value Type
------- ---------------
0 Reserved
1 Secret Key (SK)
2-15 Unassigned
Value Type
------- ---------------
0 Reserved
1 Secret Key (SK)
2-15 Unassigned
[BF] Boneh, D. and M. Franklin, "Identity-Based Encryption from the Weil Pairing", in SIAM J. of Computing, Vol. 32, No. 3, pp. 586-615, 2003.
[BF]Boneh，D.和M.Franklin，“来自Weil配对的基于身份的加密”，载于《暹罗计算杂志》，第32卷，第3期，第586-615页，2003年。
[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月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
[RFC4563]Carrara，E.，Lehtovirta，V.，和K.Norrman，“多媒体互联网键控（MIKEY）中通用扩展有效载荷的密钥ID信息类型”，RFC 4563，2006年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6043, March 2011.
[RFC6043]Mattsson，J.和T.Tian，“MIKEY-TICKET：多媒体互联网密钥分配（MIKEY）中基于票据的密钥分配模式”，RFC 60432011年3月。
[SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", September 2000.
[SEC1]高效密码标准组，“椭圆曲线密码术”，2000年9月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650]Euchner，M.“HMAC认证的Diffie Hellman多媒体互联网密钥（MIKEY）”，RFC 46502006年9月。
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006.
[RFC4738]Ignjatic，D.，Dondeti，L.，Audet，F.，和P.Lin，“MIKEY-RSA-R：多媒体互联网密钥分配（MIKEY）中的另一种密钥分配模式”，RFC 4738，2006年11月。
[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 Sundaram Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
美国新泽西州默里山3D-517 Mountain大道600号Ganapathy 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