[要約] RFC 6267は、マルチメディアインターネットキーイング（MIKEY）におけるIdentity-Based Authenticated Key Exchange（IBAKE）モードのキー配布に関する規格です。このRFCの目的は、IBAKEモードを使用してセキュアなキー交換を実現することです。
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）プロトコルの主要な管理プロトコルバリアントについて説明します。特に、このバリアントは、参加しているクライアントが相互認証を実行し、非対称IDベースの暗号化（IBE）フレームワークのセッションキーを導き出すことができるアイデンティティベースの認証キーエクスチェンジ（IBAKE）フレームワークを利用しています。このプロトコルは、相互認証を提供することに加えて、標準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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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キーエクスチェンジを使用してマルチメディアシナリオに対処するキーディストリビューションソリューションのいくつかのモードについて説明します。HMAC-Authenticated（Hashed Message Authentication Code）Diffie-Hellman [RFC4650]およびMikey-RSA-R [RFC4738]など、Mikeyの複数の拡張が指定されています。
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 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.
このドキュメントでは、KMSが定期的にエンドユーザークライアントと通信する低利用可能性サーバーであるソリューションについて説明します（たとえば、月に1回）。エンドユーザークライアント間のオンライントランザクション（メディアプレーンセキュリティのため）は、IDベースの暗号化（IBE）[BF]に基づいています。エンドユーザークライアント間のこれらのオンライントランザクションにより、相互認証を実行し、外部エンティティ（KMSを含む）に知られていないセッションキーを導き出すことができます。このプロトコルは、外部エンティティに知られていないキーを提供し、エンドユーザークライアントが相互に（メディアプレーンレイヤーで）相互に認証できるようにすることに加えて、完全な前方および後方の秘密を提供します。このプロトコルでは、KMSからクライアントの交換が控えめに使用されます（たとえば、月に1回）。したがって、KMSは高可用性サーバーである必要はなく、特に異なるKMSは相互に通信する必要はありません（オペレーターの境界を越えて）。さらに、IBEが使用されていることを考えると、費用のかかる公開キーインフラストラクチャ（PKI）の必要性と、証明書管理と取り消しのすべての運用コストが排除されます。これは、日付フィールドとパブリックキーを連結することで達成され、それにより、対応するプライベートキーが日付とともに変更され、さらに重要なことに、その日付のプライベートキーの損失による損害を制限することにより、時間になるためにコミュニケーションに関与するエンドポイントを必要としません。同期。日付フィールドの粒度は、セキュリティポリシーと展開シナリオの問題です。たとえば、オペレーターは1日に1つのキーを使用することを選択できます。したがって、KMSは、サブスクリプションサイクルの開始時にサブスクリプションサイクル全体のプライベートキーを発行する場合があります。したがって、発行された証明書が通常期間有効であるPKIシステムとは異なり、それにより有効性を制限するために取り消し手順を必要としますが、このドキュメントで説明されているスキームは、期間の終わりに自動的に期限切れになる期間に縛られたパブリックアイデンティティを使用します。アイデンティティ自体に示されています。公的アイデンティティの自己称賛により、従来のリアルタイムの妥当性の検証と取り消しは必要ありません。たとえば、パブリックアイデンティティが1日に拘束されている場合、1日の終わりに、このピアに発行されたパブリック/プライベートキーペアは、もはや有効ではありません。それにもかかわらず、パブリックキーベースの証明書システムと同様に、指定された有効期限の前にキーを取り消す必要がある場合は、第三者との通信が必要になります。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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暗号化：IDベースの暗号化（IBE）は、公開キーをIDから計算できる公開キー暗号化テクノロジーであり、対応する秘密鍵を公開鍵から計算することができます。[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）xのxの暗号化キーK [x] Pポイント楕円曲線上の乗算、つまり、x [x] xの合計x time k_pubx公開キーの合計でポイントpを追加すると{x}は{x}です。x（x）のゼロ以上の出現xの1つ以上の出現||連結|または（選択オペレーター）
EC Elliptic Curve
EC楕円曲線
ESK Encrypted Secret Key
ESK暗号化されたシークレットキー
HMAC Hashed Message Authentication Code
HMACはメッセージ認証コードをハッシュします
IBE Identity-Based Encryption
IBE IDベースの暗号化
I Initiator
イニシエーター
IBAKE Identity-Based Authenticated Key Exchange
Ibake Identityベースの認証されたキー交換
IDRi Initiator's Identity
IDRIイニシエーターのアイデンティティ
IDRr Responder's Identity
IDRRレスポンダーの身元
KMS Key Management Service
KMSキー管理サービス
K_PR Private Key
K_PR秘密鍵
K_PUB Public Key
K_PUB公開キー
K_SESSION Session Key
K_Sessionセッションキー
MAC Message Authentication Code
Macメッセージ認証コード
MIKEY Multimedia Internet KEYing
マイキーマルチメディアインターネットキーイング
MKI Master Key Identifier
MKIマスターキー識別子
MPK MIKEY Protection Key
MPKマイキー保護キー
PKI Public Key Infrastructure
PKI公開キーインフラストラクチャ
PRF Pseudorandom Function
PRF疑似ランダム関数
R Responder
Rレスポンダー
SK Secret Key
SKシークレットキー
SIP Session Initiation Protocol
SIPセッション開始プロトコル
SPI Security Parameter Index SRTP Secure Realtime Transport Protocol
SPIセキュリティパラメーターインデックスSRTPセキュアリアルタイムトランスポートプロトコル
TEK Traffic Encryption Key
Tekトラフィック暗号化キー
TGK TEK Generation Key
TGK Tek Generation Key
This section describes some of the use case scenarios supported by MIKEY-IBAKE, in addition to regular two-party communication.
このセクションでは、通常の2パーティのコミュニケーションに加えて、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招待メッセージなど）の配信です。これは、単一のユーザーが複数回登録されている場合に発生します。フォーキングの例は、ユーザーがデスクフォン、PCクライアント、モバイルハンドセットがすべて同じパブリックアイデンティティで登録されている場合です。
+---+ +-------+ +---+ +---+
| 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.
セッションリダイレクトには2つの基本的なシナリオがあります。シナリオ1では、機能要素（プロキシなど）が、新しい宛先情報をオリジネーターに渡すことにより、セッションをリダイレクトすることを決定します。その結果、オリジネーターは、プロキシが提供するリダイレクトされた目的地への新しいセッションを開始します。Mikey-Ibakeの場合、これは、オリジネーターがリダイレクトされた目的地のIDとともに新しいセッションを開始することを意味します。このシナリオは、以下の図2に示されています。
+---+ +-------+ +---+ +---+
| 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].
2番目のシナリオでは、プロキシが発信者に通知せずにセッションをリダイレクトすることを決定しました。これは、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モードのほとんどは、2つのピア間の単一（または半分の）往復で構成されています。Mikey-Ibakeは、最大3つの往復で構成されています。最初の往復では、ユーザー（イニシエーターとレスポンダー）がKMSから秘密鍵（s）（k_pr）を取得します。この往復はいつでも実行でき、前述のように、たとえば月に1回（またはサブスクリプションサイクルごとに1回）行われます。2番目と3回目の往復は、イニシエーターとレスポンダーの間です。主要な管理サービスは、最初のラウンドトリップにのみ関与していることに注意してください。図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
<-----------------------------------------------------------
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に示すように、イニシエーター用の1つ、レスポンダー用の1つは、イニシエーターとレスポンダーが資格情報を共有しません。ただし、イニシエーターはレスポンダーのパブリックアイデンティティを知っています。想定される信頼モデルを図4に示します。
+---+ +------+ +------+ +---+
| I | | KMS1 | | KMS2 | | R |
+---+ +------+ +------+ +---+
Pre-established Pre-established
trust relation trust relation
<-----------------> <--------------------->
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メッセージを使用してプライベートキーがどのように取得されるかについての説明が提供されます。HTTPを使用してプライベートキーを取得するための代替方法は、[RFC5408]で説明されています。
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.
イニシエーターは、request_key_initメッセージを送信することにより、KMSから秘密鍵を取得します。request_key_initメッセージには、イニシエーターのパブリックアイデンティティが含まれています（イニシエーターに複数のパブリックアイデンティティがある場合、登録されたすべてのアイデンティティのプライベートキーを要求する場合があります）。Mikey-PSKおよびMikey-RSAモードに）。リクエストが承認されている場合、KMSは要求されたキーを生成し、それらをエンコードし、request_key_respメッセージで返します。この交換は定期的に行われ、イニシエーターがレスポンダーとの安全な接続を確立する必要があるたびに実行する必要はありません。
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_pubr = h1（idrr || date））を生成します。公に。次に、イニシエーターはこの生成された公開キーを使用して[X] P、IDRI、IDRRを暗号化し、この暗号化された情報をI_Message_1メッセージに含め、Responderに送信されます。暗号化は、[RFC5091]および[RFC5408]で指定されているように、アイデンティティベースの暗号化（IBE）です。次に、その日付の秘密鍵を使用して、受信したメッセージをレスポンダーibeデクリプト化し、ランダムyを選択し、[y] p。次に、Responderはi_message_1から取得したイニシエーターのIDを使用して、K_PUBIを使用して、イニシエーターの公開キー（k_pubi = h1（idri || date））およびibe-encrypts（idri、idrr、[x] p、[y] p）を生成します。イニシエーターに送信されたr_message_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_message_1メッセージを受信して排除すると、イニシエーターは受信した[x] pを検証します。この時点で、イニシエーターは[x] [y] pと同じセッションキーを生成できます。検証を成功させると、イニシエーターはI_Message_2メッセージをResponderに送信します。これには、IBE暗号化されたIDRI、IDRRが含まれ、以前に受信しました[Y] p。レスポンダーは、検証としてr_message_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-bakeは[RFC3830]に基づいています。したがって、特に明記されていない限り、同じ用語、処理、および考慮事項がまだ適用されます。i_message/ r_messageで交換されたec diffie-hellman値とキーを含むペイロードは、[RFC5091]および[RFC5408]で指定されているように暗号化され、キーは[RFC3830]で指定されているようにkey_reques_init/ key_request_responceで交換されます。すべての交換において、暗号化は、キーと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.
この交換は、ユーザー（イニシエーターやレスポンダーなど）によって使用され、信頼できるキー管理サービスからプライベートキーを要求します。ユーザーがキーを受信するには、完全な往復が必要です。このメッセージは、ユーザーのIDをKMSに保証する必要があるため、事前共有キーまたは署名に基づいてMacを介して保護されます。開始メッセージrequest_key_initには、[RFC3830]のプレッシャーキー（PSK）とパブリックキー暗号化（PKE）メソッドに対応する2つのバリアントがあります。応答メッセージrequest_key_respは2つのバリアントで同じであり、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_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から1つ以上のプライベートキー（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（Crypto Session Bundle ID）は、[RFC3830]のように割り当てられます。ユーザーは、ヘッダーのCSB IDフィールドに含めるものとします。CS（Crypto Session（S））が処理されないため、ユーザーは＃CSフィールドを「0」に設定するものとします。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.
IDRKMSが含まれます。
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).
最後のペイロードは、認証キー（auth_key）が事前共有キーから導出される検証（v）ペイロードでなければなりません（キー派生仕様については[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がいくつかのパブリックキーを所有している場合、ユーザーはチャッシュペイロードで使用されるキーを示すことができます。
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はrequest_key_respメッセージを送信する必要があります。request_key_initメッセージの予期しないペイロードは無視する必要があります。エラーは[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に設定し、それを受信するユーザーはこのコンテキストでは意味がないため、それを無視するものとします。
The Timestamp type and value SHALL be identical to the one used in the REQUEST_KEY_INIT message.
タイムスタンプの種類と値は、request_key_initメッセージで使用されているものと同一でなければなりません。
KEMAC = E(encr_key, (ID || K_PR))
kemac = e（encr_key、（id || k_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.
MacがVペイロードに含まれているため、KemacペイロードはNull認証アルゴリズムを使用する必要があります。request_key_initメッセージのタイプに応じて、sharedキーまたはエンベロープキーを使用してencr_keyを導出する必要があります。
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）ペイロードでなければなりません。request_key_initメッセージのタイプに応じて、shared pre-sharedキーまたはエンベロープキーのいずれかを使用してauth_keyを導出するものとします。
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を生成するために使用されるdiffie-hellman値を交換します。これらの交換は、楕円曲線diffie-hellman値と秘密キー（SK）がKemacペイロードの代わりにibakeおよびESKペイロードでエンコードされていることを除いて、事前共有キーモードをモデルにします。この交換が正常に完了するには、2つの完全な往復が必要です。メッセージは、セッションのセットアップシグナリング（SIP Inviteなど）に含まれることが好ましいです。
Initiator Responder
イニシエーターレスポンダー
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
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_message_1メッセージには、常にヘッダー（HDR）、タイムスタンプ（T）、およびRANDペイロードを含める必要があります。CSB ID（Crypto Session Bundle ID）は、イニシエーターによってランダムに選択されるものとします。R_Message_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ペイロードには、イニシエーターのIDとEC Diffie-Hellman値（ECCPTI）が含まれており、Responderの公開キー（ENCR_KEY = K_PUBR）を使用してすべて暗号化されました。
IBAKE = E(encr_key, IDRi || ECCPTi || IDRr)
ibake = e（encr_key、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には、意図したResponderの公開キー（ENCR_KEY = k_pubr）を使用して暗号化されたアイデンティティと秘密キー（SK）が含まれています。
ESK = E(encr_key, ID || SK)
esk = e（encr_key、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 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.
i_message_1メッセージの解析は、[RFC3830]のように行われます。受信したメッセージが正しく解析された場合、レスポンダーは受信したIDRRに対応する秘密鍵（K_PRR）を使用して、iBakeペイロードを復号化するものとします。メッセージにESKペイロードが含まれている場合、レスポンダーはSKを復号化し、受信したiBakeペイロードを復号化するために使用します。それ以外の場合、レスポンダーがiBakeペイロードを復号化できない場合、レスポンダーは、次のメッセージ（つまり、R_Message_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_message_1メッセージの対応するフィールドと同一でなければなりません。Vフラグは、i_message_2メッセージが必須であるため、1に設定されます。
The Timestamp type and value SHALL be identical to the one used in the I_MESSAGE_1 message.
タイムスタンプの種類と値は、i_message_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_message_1で受信されたとおりです。IDRRペイロードには、レスポンダーには独自のアイデンティティが含まれます。このIDは、i_message_1メッセージで受信したIDRRペイロードに含まれるIDとは異なる場合があることに注意してください。i_message_1とr_message_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:
ResponderのIbakeペイロードには、I_Message_1（正常に復号化された場合）で受信したイニシエーターのEC Diffie-Hellman値（ECCPTI）、およびResponder（ECCPTR）によって生成されたEC Diffie-Hellman値、および対応するイニシエーターとレスポンダーのアイデンティティが含まれています。Responderがi_message_1で受信したibakeペイロードを復号化できない場合（たとえば、メッセージは対象となるResponderのメールボックスによって受信されます）、Responderには独自のEC Diffie-Hellman値（ECCPTR）のみが含まれます。r_message_1のibakeペイロードは、次のようにイニシエーターの公開キー（つまり、encr_key = p_pubi）を使用して暗号化されます。
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 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.
r_message_1メッセージの解析は、[RFC3830]のように行われます。受信したメッセージが正しく解析されている場合、イニシエーターは、受信したIDRIに対応する秘密鍵を使用して、iBakeペイロードを復号化するものとします。i_message_1で送信されたeccptiが受信したibakeペイロードに存在しない場合（たとえば、レスポンダーが現在オフラインであり、R_message_1がResponderのメールボックスから受信されます）、イニシエーターは次のメッセージ、i_message_2に再びeccptiを含めるものとします。この場合、i_message_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）、およびRANDペイロードを含める必要があります。HDRペイロードのバージョン、PRF FUNC、CSB ID、＃CS、およびCS IDマップタイプフィールドは、R_Message_2メッセージの対応するフィールドと同一でなければなりません。R_Message_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_Message_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:
イニシエーターのiBakeペイロードには、r_message_1でECCPTIが受信されなかった場合、イニシエーターのEC Diffie-Hellman値（ECCPTI）が含まれます。それ以外の場合、eccptiは含まれません。i_message_2のibakeペイロードには、メッセージr_message_1で受信されたResponderのEC Diffie-hellman値だけでなく、イニシエーターとレスポンダーのアイデンティティが含まれます。Ibakeペイロードは、次のように、Responderの公開キー（つまり、encr_key = k_pubr）を使用して暗号化されます。
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）ペイロードを含めることができます。ESKは、R_Message_1がイニシエーターのEC Diffie-Hellman値（ECCPTI）（例えば、延期された配信の場合）を含んでいない場合に含まれます。含まれている場合、次のように、意図した受信者の公開キー（つまりencr_key = k_pub）を使用して暗号化されたイニシエーターのIDおよびイニシエーター生成のシークレットキー（SK）が含まれています。
ESK = E(encr_key, ID || SK)
esk = e（encr_key、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_message_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_message_2メッセージの対応するフィールドと同一でなければなりません。Vフラグは、応答者によって0に設定され、イニシエーターによって無視されます。
The Timestamp type and value SHALL be identical to the one used in the I_MESSAGE_2 message.
タイムスタンプの種類と値は、i_message_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:
InitiatorのEC Diffie-Hellman Value（ECCPTI）をI_Message_2で受信した場合、ResponderにはIBakeペイロードも含まれます。IBAKEペイロードには、イニシエーターのEC Diffie-Hellman値（ECCPTI）と、以前にININITARESの公開鍵（ENCR_KEY = K_PUBI）を使用して暗号化されたI_Message_2で以前に受け取ったイニシエーターのIDを含める必要があります。
IBAKE = E(encr_key, IDRi || ECCPTi)
ibake = e（encr_key、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.
最後のペイロードは、認証キー（auth_key）がセクション5.2で指定されているように導出される検証（v）ペイロードでなければなりません。
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_message_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.
request_key_init/request_key_resp Exchangeで使用されるキーは、[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].
上記のように、セッションキー[x] [y] Pは、交換されたEC diffie-hellman値を使用して生成されます。ここで、xとyはイニシエーターとレスポンダーによってランダムに選択されます。楕円曲線のポイントとしてのセッションキーは、[SEC1]で指定されているように、Octet Stringに変換されます。次に、このOctet String K_Sessionを使用してMPKとTGKを生成します。最後に、[RFC3830]で指定されているように、TGKからトラフィック暗号化キー（TEKなど）が生成されます。
The MPK and TGK are generated from K_SESSION as follows.
MPKとTGKは、次のようにK_Sessionから生成されます。
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_session inkey_len：mpkラベルのビット長：定数||0xff ||0xffffffff ||rand outkey_len：出力キーの目的のビット長（MPKまたはTGK）
The constant depends on the derived key type as summarized below.
定数は、以下に要約されているように、導出されたキータイプに依存します。
+-------------+------------+
| 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メッセージのキーは、イニシエーターとレスポンダーの間で交換されるマイキーメッセージ（つまり、i_messageとr_message）を保護するために使用されます。request_key_init/request_key_resp Exchangeでは、[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_message/r_message ExchangeのMikey Protection Key（MPK）は、セクション5.1で説明されているように生成されます。このMPKは、R_Message_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_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（Crypto Session Bundle）を更新する手段を提供します。たとえば、新しいEC Diffe-Hellman値の輸送や新しい暗号セッションの追加。CSBの更新は、i_message_1/r_message_1の交換を実行することによって行われます。CSBの更新は、イニシエーターまたはレスポンダーのいずれかによって開始される場合があります。
Initiator Responder
イニシエーターレスポンダー
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
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を使用する必要がありますが、新しいタイムスタンプを使用する必要があります。最初の交換で提供された他のペイロードは含まれないでください。新しいランドをメッセージ交換に含めるべきではありません（ランドは最初の交換でのみ効果があります）。
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_message/r_messageメッセージを保護するキーで保護されます。
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 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.
[RFC3830]で説明されているように、すべてのMikey-Ibakeメッセージの認証タグは生成されます。上記のように、MPKはauth_keyの導出に使用されます。V/signペイロードのMac/署名は、Mac/署名フィールド自体を除き、Mikeyメッセージ全体をカバーしています。マッサージにESKペイロードがある場合は、Mac/署名計算から省略されます。関係者のアイデンティティ（ペイロード全体ではなく）は、検証MAC/署名計算でMikeyメッセージに直接従う必要があります。i_message/ r_message Exchangeでは、r_message_1のidrrがi_message_1に表示されるものと同じではない場合があることに注意してください。
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]と比較して変更が行われたペイロードをあまり詳細に説明しています。マイキーペイロード（例：タイムスタンプ（T）ペイロード、RANDペイロードなど）の詳細な説明については、[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 |
+------------------+-------+------------------------------------+
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 |
+--------------+-------+---------------+
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に設定され、開始メッセージの受信者（Responderまたは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暗号化（[RFC5091]および[RFC5408]を参照）を含みます。IBEの詳細については、IBEの詳細については、ResponderのIDとEC Diffie-Hellmanサブペイロード（EC Diffie-Hellmanサブペイロードの定義についてはセクション6.1.4を参照））。1つ以上のEC Diffie-Hellmanサブペイロードとそれに関連するIDが含まれる場合があります。最後のEC Diffie-HellmanまたはIDサブペイロードには、最後のペイロードに次のペイロードフィールドが設定されています。
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を参照）とそれに関連するIDペイロードを暗号化しました。
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]を参照）が含まれています。IBEの詳細については、Secret Keyサブペイロードとその関連アイデンティティ（Secret Keyサブペイロードの定義についてはセクション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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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）を使用して暗号化されたコンテンツを復号化するために使用されます。request_key_respのkemacには、1つ以上のプライベートキーが含まれている必要があります。
o Type (4 bits): indicates the type of key included in the payload.
o タイプ（4ビット）：ペイロードに含まれるキーのタイプを示します。
+------+-------+-------------+
| 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サブペイロードは、明確に含まれることはありませんが、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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+--------------------------------------+-------+
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ビット境界で終了するようにパッドで、Octet String表現でエンコードされています。
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-bakeの場合、このフィールドは無視されます。
o TGK len (16 bits): the length of the TGK (in bytes). For MIKEY-IBAKE this field is ignored.
o TGKレン（16ビット）：TGKの長さ（バイト単位）。Mikey-bakeの場合、このフィールドは無視されます。
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がnullの場合、このフィールドは含まれていません。
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のサブペイロードと同様に、それは明確に含まれることはありませんが、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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+------+-------+
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がnullの場合、このフィールドは含まれていません。
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-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プロトコルは、IDベースの暗号化の使用に依存しています。[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.
主要な管理サービスは安全であり、侵害され、信頼されておらず、独立してまたは共同環境でアクティブな攻撃を開始することはないと想定されています。ただし、悪意のあるインサイダーは、パッシブ攻撃を発射する可能性があります（1つ以上のメッセージ交換をオフラインで復号化することにより）。そのような攻撃を防ぐことは管理者にとって最大の利益ですが、この問題を排除することは困難です。したがって、そのような問題が持続すると想定されているため、プロトコルは参加者を受動的な敵から保護するように設計されています。
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].
すべてのステップで、IDベースの暗号化（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_Message_1）で、暗号化されたペイロードの一部としてIDが使用されなかったと仮定します。さらに、イニシエーターとレスポンダーとの間の会話にアクセスし、積極的にパケットにスヌープしてドロップ/変更する敵が、目的地にルーティングする前に敵対者を想定しています。たとえば、IPソースアドレスと宛先アドレスが敵によって変更できると仮定します。最初のメッセージがイニシエーターによって（レスポンダーに）送信された後、敵はパケットを引き継いでトラップすることができます。次に、敵は、IPソースアドレスを変更して、敵のIPアドレスを含めることができます。レスポンダーは、Ibakeセッションの要求が敵から来たと想定し、Ibakeプロトコルのステップ2（つまり、セクション4.1の図3のR_Message_1）を実行しますが、敵の公開鍵を使用して暗号化します。上記のメッセージは、敵によって（そして敵によってのみ）復号化される可能性があります。特に、2番目のメッセージにはイニシエーターからレスポンダーに送信された課題が含まれているため、敵はイニシエーターによって送信された課題を学びます。これに続いて、敵はイニシエーターと「ふりをする」イニシエーターと会話を続けることができます。この攻撃は、暗号化されたペイロードの一部としてIDが使用される場合、排除されます。要約すると、Exchangeの最後に、イニシエーターとレスポンダーの両方が相互に認証し、セッションキーに同意することができます。
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].
IDベースの暗号化は、メッセージの受信者のみが秘密鍵を使用してメッセージを解読できることを保証することを思い出してください。警告は、メッセージの受信者の秘密鍵を生成したKMSもメッセージを復号化することができます。ただし、KMSは、楕円曲線diffie-hellmanの問題に基づいて[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.
イニシエーターとレスポンダーが2つの異なる主要な管理サービスに属している場合でも、プロトコルが機能することを観察します。特に、暗号化に使用されるパラメーターと、イニシエーターへの暗号化に使用されるパラメーターは、まったく異なり、互いに独立している場合があります。さらに、セッションキー[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プロパティは、キーの完全な秘密を保証します。その他では、1つのセッションキーの偶発的な漏れや、同じイニシエーターとレスポンダーの間の過去または将来のセッションキーを損なうことはありません。
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.
フォーキング機能では、複数の潜在的なレスポンダーがあることを考えると、1つの「一般的なレスポンダー」のアイデンティティ（および対応するパブリックキーおよびプライベートキー）があり、各レスポンダーには一意のアイデンティティ（および対応するパブリックキーとプライベートキー）があることを観察することが重要です。。このフレームワークでは、1人のレスポンダーがイニシエーターからの招待に応答する場合、その独自のアイデンティティを使用して、プロトコルが他のレスポンダーがセッションキーを学習しないことを保証するようにします。
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.
延期された配信機能では、イニシエーターとレスポンダーのメールボックスが相互に認証され、サーバー側の「フィッシング」攻撃を防ぎ、逆にサーバー（最終的には応答者に）イニシエーターの身元を保証します。さらに、メッセージの内容を暗号化するためにイニシエーターが使用するキーは、イニシエーターとサーバーの間で派生したセッションキーから完全に独立しています。最後に、メッセージを暗号化するために使用されるキーは、Responderの公開キーを使用して暗号化されます。これにより、メッセージの内容がメールボックスサーバーに不明のままになります。
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の割り当てがマイキーペイロードレジストリに追加されました（ブラケット内は、登録値を含むテーブルへの参照です）：
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 Payloadレジストリに新しい名前空間を維持します。割り当ては、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
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 Payloadレジストリに新しい名前空間を維持します。割り当ては、キーのタイプとそれに関連する値で構成されています。範囲2〜15の値は、必要な仕様のプロセスによって承認される必要があります。レジストリの最初の内容は次のとおりです。
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ペアリングからのアイデンティティベースの暗号化」、Siam J. of Computing、Vol。32、No。3、pp。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、「Mikey：Multimedia Internet Keying」、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 6043、2011年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：SESSION INTIANIATION Protocol」、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、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650] Euchner、M。、「マルチメディアインターネットキーイング（Mikey）のためのHMAC-Authenticated Diffie-Hellman」、RFC 4650、2006年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 and 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 600 Mountain Ave. 3D-517 Murray Hill、NJ 07974 US
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
Ganapathy Sundaram Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill、NJ 07974 US
Phone: +1 908 582 3209
EMail: ganesh.sundaram@alcatel-lucent.com