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：マルチメディア、インターネットキーイングにおけるキー配布のIDベースの認証鍵交換（IBAKE）モード（MIKEY）
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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鍵交換を記載しています。 MIKEYの複数の拡張子は、HMAC-認証（ハッシュメッセージ認証コード）ディフィー・ヘルマン[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]は、作成、配布、およびリアルタイムで鍵を管理するネットワーク内のキー管理サービス（KMSS）に依存しています。これによって幅広い機能に、キー管理サービスは、オンラインである必要はあり高可用性を維持し、オペレータの境界を越えてネットワーク化されるだろう。
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.
この文書では、KMSSは、定期的に（例えば、1ヶ月に1回）エンドユーザクライアントと通信し、低可用性サーバである、解決策を説明します。 （メディア・プレーンのセキュリティのための）エンドユーザクライアント間のオンライン取引は、IDベース暗号（IBE）[BF]に基づいています。エンドユーザクライアントとの間にこれらのオンライン取引は、それらが相互認証を実行し、（KMSSを含む）任意の外部エンティティに知られていないセッションキーを導出することができます。このプロトコルは、任意の外部エンティティに知られていないキーを提供し、エンドユーザクライアントが相互に（メディア・プレーン層に）互いを認証するために可能にすることに加えて、完全前後機密性を提供します。このプロトコルでは、KMSからクライアントへの交換は控えめに使用されている（例えば、月に一度）。したがって、KMSは、もはや高可用性サーバである必要はありません、そして特に異なるKMSSに（オペレータ境界を越えて）互いに通信する必要はありません。また、IBEが使用されていることを考えると、高価な公開鍵基盤（PKI）と証明書の管理および取消しのすべての運用コストの必要性が解消されます。これは、時間であることを通信に関係するエンドポイントを必要としないが、ちょうどその日に、秘密鍵の紛失による損害を制限する、より重要なのは、日付を変更し、それによって対応する秘密鍵を確保し、日付フィールドと公開鍵を連結することによって達成され、同期。日付フィールドでの粒度は、セキュリティポリシーおよび展開シナリオの問題です。例えば、オペレータは、一日あたり1つのキーを使用することもできますので、KMSは、サブスクリプション・サイクルの始めに全体のサブスクリプション・サイクルのための秘密鍵を発行することができます。したがって、それによって、その有効性を制限するために、失効手続きを必要とする発行された証明書は、通常、一定の期間のために有効であるPKIシステム、とは異なり、このドキュメントで説明するスキームは、自動的に時間間隔の終了時をもって任期満了期限付きパブリックアイデンティティを、使用していますアイデンティティそのものに示しました。パブリックアイデンティティの自己満了で、伝統的なリアルタイムの妥当性の検証と失効が必要とされていません。公共のアイデンティティは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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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）は、公開鍵はアイデンティティから計算することができ、および公開キーから計算することに対応する秘密鍵公開鍵暗号化技術です。 [RFC5091]、[RFC5408]及び[RFC5409] IBEを実装するために必要なアルゴリズムを記述する。
(Media) session: The communication session intended to be secured by the MIKEY-IBAKE provided key(s).
（メディア）セッション：MIKEY-IBAKEによって固定されることを意図通信セッションキー（S）を得ました。
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の暗号、楕円曲線上の[X] P点乗算、すなわち、自身にX回XのK_PUBx公開鍵の合計点Pを追加[x]は、xは{X}任意でありますXの0回以上の繰り返し（x）はxの1回以上の繰り返し||連結| OR（選択演算子）
EC Elliptic Curve
EC楕円曲線
ESK Encrypted Secret Key
ESK暗号化された秘密鍵
HMAC Hashed Message Authentication Code
HMACハッシュメッセージ認証コード
IBE Identity-Based Encryption
IBE IDベース暗号化
I Initiator
Iイニシエータ
IBAKE Identity-Based Authenticated Key Exchange
IBAKEアイデンティティベースの認証鍵交換
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
MIKEYマルチメディアインターネットキーイング
MKI Master Key Identifier
MKIマスターキー識別子
MPK MIKEY Protection Key
MPK MIKEY保護キー
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
SPIセキュリティパラメータインデックス
SRTP Secure Realtime Transport Protocol
SRTPリアルタイム転送プロトコルセキュア
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.
このセクションでは、通常の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 INVITEメッセージ）の配信です。 1人のユーザーが複数回登録されている場合に発生します。ユーザーがすべて同じパブリックアイデンティティに登録卓上電話、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において、機能要素（例えば、プロキシ）を元に新たな宛先情報を渡すことによって、セッションをリダイレクトすることを決定します。その結果、発信者は、プロキシが提供するリダイレクト先への新しいセッションを開始します。マイキー・IBAKEの場合には、これは、発信者がリダイレクト先のアイデンティティとの新しいセッションを開始することを意味します。このシナリオは、以下の図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）を得ます。先に説明したように、この往復は、いつでも行うことができ、月に一度（または一度サブスクリプション・サイクルごとに）、例えば、行われます。第二および第三ラウンドトリップは、イニシエータとレスポンダとの間です。キーマネージメントサービスは、最初のラウンドトリップに関与していることを確認します。図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よりも、いくつかの異なるKMSSが関与することができる、例えば、イニシエータ用と図3イニシエータと資格情報を共有していないレスポンダに示すように、レスポンダーのための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メッセージはイニシエータの公開アイデンティティ（単数または複数）を含む（イニシエータが複数のパブリックアイデンティティを持っている場合、それが登録されているすべての識別のためにプライベートキーを要求することができる）と同様の（事前共有キーまたは署名を介してベースMACを介して保護されています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 ||日付））、生成するレスポンダの公開IDを使用しています公に。その後、イニシエータは、これが[X] P、IDRIとIDRrを暗号化する公開鍵を生成し使用してレスポンダに送信されるI_MESSAGE_1メッセージにこの暗号化情報を含みます。 [RFC5091]及び[RFC5408]で指定されるように暗号化は、識別情報に基づく暗号化（IBE）です。次に、レスポンダ、その日のためにその秘密鍵を用いて受信したメッセージをIBEは、解読ランダムy及び計算する[Y] Pを選択します。次に、レスポンダはイニシエータの公開鍵（例えば、K_PUBi = H1（IDRI ||日付））を生成するI_MESSAGE_1から得られるイニシエータのアイデンティティを使用しK_PUBiを用いたIBE暗号化し（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メッセージをIBE-復号時に、イニシエータは、受信した[X] Pを検証します。この時点で、イニシエータは、[X] [Y] Pと同じセッション鍵を生成することができます。検証が成功すると、イニシエータは、IBE暗号化IDRI含む、レスポンダにI_MESSAGE_2メッセージを送信IDRr、以前[Y] Pを受けました。 Responderは、検証としてイニシエータに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-IBAKEは、[RFC3830]に基づいています。特に明記しない限りので、同じ用語、処理、および考慮事項が適用されます。 [RFC3830]で指定されるようにECのDiffie-Hellman値とキーがI_MESSAGE / R_MESSAGEで交換含むペイロードキーがKEY_REQUES_INIT / KEY_REQUEST_RESPONSEで交換しながらIBEは、[RFC5091]及び[RFC5408]で指定されるように暗号化され、暗号化されています。すべての交換において、暗号化は、キーと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を介して保護されています。開始メッセージREQUEST_KEY_INITは、事前共有鍵（PSK）と[RFC3830]の公開鍵暗号化（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_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（暗号化セッションバンドルID）は、[RFC3830]のように割り当てられます。ユーザーは、ヘッダーのCSB IDフィールドでそれを含めなければなりません。ユーザーは、CS（暗号化セッション（S））以降「0」取り扱わないために#CSフィールドを設定しなければなりません。 [RFC4563]で定義されるようにCS IDマップタイプは、「空のマップ」でなければなりません。
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は、ユーザーの身元が含まれています。ユーザが複数のIDを有することができるので、複数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）は、事前共有鍵（キー派生仕様[RFC3830]のセクション4.1.4を参照）から誘導される検証（V）ペイロードでなければなりません。
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）ペイロードが含まれるべきです。証明書チェーンを提供する場合、チェーン内の各証明書は、別個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 = E（PKkms、env_key）：PKEペイロードは暗号化されたエンベロープキーが含まれています。これは、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は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は0にVフラグを設定するであろうし、それは、この文脈では意味を持たないように、それを受信したユーザは、それを無視します。
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メッセージの種類に応じて、いずれかの事前共有キーまたはエンベロープキーが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メッセージの種類に応じて、いずれかの事前共有キーまたはエンベロープキーが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を生成するために使用されるECのDiffie-Hellman値を交換するためにイニシエータとレスポンダのために使用されます。これらの交換は、楕円曲線のDiffie-Hellman値と秘密鍵（セキュリティーキー）を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（暗号化セッションバンドル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ペイロードは、次のようにレスポンダの公開鍵を（すなわち、encr_key = K_PUBr）を使用して暗号化されたすべてのイニシエータのアイデンティティとECのDiffie-Hellman値（ECCPTi）、およびレスポンダのアイデンティティが含まれています。
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は、アイデンティティが含まれており、秘密鍵（SK）は、意図したレスポンダの公開鍵（すなわち、encr_key = K_PUBr）を使用して暗号化されました。
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
I_MESSAGE_1メッセージの解析は、[RFC3830]のように実施されねばなりません。受信したメッセージが正しく解析されている場合は、ResponderはIBAKEペイロードを復号化するために、受信したIDRrに対応する秘密鍵（K_PRr）を使用しなければなりません。メッセージは、ESKのペイロードが含まれている場合は、ResponderはSKを復号化し、受信したIBAKEペイロードを復号化するためにそれを使用しなければなりません。それ以外の場合は、Responderが解読できない場合
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.
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.
バージョンは、PRFのFUNC、CSB ID、#CS、及びHDRペイロードにおけるCS IDマップタイプフィールドはI_MESSAGE_1メッセージの対応するフィールドと同じでなければなりません。 I_MESSAGE_2メッセージは必須であるとしてVフラグが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ペイロードでは、Responderは、独自のアイデンティティを含まなければなりません。このアイデンティティはI_MESSAGE_1メッセージで受信IDRrペイロードに含まれるアイデンティティとは異なるかもしれないことに留意されたいです。 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:
レスポンダのIBAKEペイロードは、（正常復号されている場合）イニシエータのECのDiffie-Hellman値（ECCPTi）がI_MESSAGE_1で受信含まれ、および開始剤のECのDiffie-Hellman値がレスポンダ（ECCPTr）、ならびに対応するイニシエータとレスポンダのアイデンティティによって生成されました。レスポンダ（例えば、メッセージが意図レスポンダのメールボックスによって受信される）I_MESSAGE_1で受信IBAKEペイロードを復号化できない場合、レスポンダは、独自のECのDiffie-Hellman値（ECCPTr）を含まなければなりません。次のようにR_MESSAGE_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_MESSAGE_1メッセージの解析は、[RFC3830]のように実施されねばなりません。受信したメッセージが正しく解析されている場合は、イニシエータはIBAKEペイロードを復号化するために、受信したIDRIに対応する秘密鍵を使用しなければなりません。 ECCPTiはI_MESSAGE_1に送信した場合、受信しIBAKEペイロードに存在しない（例えば、レスポンダは現在オフラインであるとR_MESSAGE_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_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ペイロードを含まなければなりません。バージョンは、PRFのFUNC、CSB ID、#CS、及びHDRペイロードにおける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:
ECCPTiがR_MESSAGE_1に受信されなかった場合、イニシエータのIBAKEペイロードは、イニシエータのECのDiffie-Hellman値（ECCPTi）を含まなければなりません。それ以外の場合は、ECCPTiは含まれないもの。 I_MESSAGE_2でIBAKEペイロードは、イニシエータのとレスポンダのアイデンティティを含まなければならないだけでなく、レスポンダのECのDiffie-Hellman値は、メッセージR_MESSAGE_1で受け取りました。次のように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）のペイロードを含めることができます。 ESKはR_MESSAGE_1（例えば、遅延配信の場合）イニシエータのECのDiffie-Hellman値（ECCPTi）を含んでいなかった場合に含めなければなりません。含まれている場合、それは次のようにイニシエータのアイデンティティとイニシエータが生成した秘密鍵（SK）が意図した受信者の公開鍵（すなわち、encr_key = K_PUB）を使用して暗号化が含まれます。
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]のように実施されねばなりません。受信したメッセージが正しく解析された場合、レスポンダはIBAKEペイロードを解読するために受信IDRrに対応K_PRrを使用しなければなりません。 ESKを受信した場合、Responderは将来の使用のためにそれを保存するものとし（例えば、レスポンダは、メールボックスで、ユーザーがオンラインになると、ユーザーにキーを転送します）。
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.
バージョンは、PRFのFUNC、CSB ID、#CS、及びHDRペイロードにおける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:
イニシエータのECのDiffie-Hellman値（ECCPTi）がI_MESSAGE_2で受信された場合、レスポンダはまたIBAKEペイロードを含むものとします。次のように含まれている場合、IBAKEペイロードは（ECCPTi）イニシエータのECのDiffie-Hellman値を含まなければならない、とイニシエータのアイデンティティは、以前I_MESSAGE_2で受信し、イニシエータの公開鍵を（すなわち、encr_key = K_PUBi）を使用して暗号化：
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.
最後のペイロードはセクション5.2で指定された認証キー（AUTH_KEY）が導出される検証（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ペイロードが含まれている場合、および、イニシエータはIBAKEペイロードを解読するために受信IDRIに対応K_PRiを使用しなければなりません。
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交換に使用されるキーは、事前共有キーまたは[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は、xとyをランダムイニシエータとレスポンダによって選択された交換ECのDiffie-Hellman値を用いて生成されます。 [SEC1]で指定されたセッション鍵は、楕円曲線上の点として、次にオクテットストリングに変換されます。このオクテット文字列K_SESSIONは、その後MPKとTGKを生成するために使用されます。 [RFC3830]で指定されるように、最終的に、トラフィック暗号化キー（例えば、TEK）をTGKから生成されます。
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：ビットMPKラベルの長さ：：inkey_len K_SESSION定数|| 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メッセージのキーはMIKEYメッセージを保護するために使用されているイニシエータとレスポンダ（すなわち、I_MESSAGEとR_MESSAGE）との間で交換。 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.
5.1節で説明したようにI_MESSAGE / R_MESSAGE交換MIKEY保護キー（MPK）が生成されます。この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（暗号化セッションバンドル）を更新新しい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ペイロードが含まれるべきです。新しいECのDiffie-Hellman値はCSB更新中に交換されている場合は、5.2節で指定され、メッセージがECのDiffie-Hellman値から派生したキーと交換保護されなければなりません。新しいECのDiffie-Hellman値はCSB更新交換中に交換されていない場合はそれ以外の場合は、メッセージが最初の交換で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交換において、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].
このセクションでは、新しいメッセージタイプで使用されているすべてのペイロードを説明していません。これは[RFC3830]と比較してなされたものであり、変更するためのペイロード詳細新しいIBAKE及びESKペイロードおよび以下に詳細に記載されています。 MIKEYペイロード（例えば、タイムスタンプ（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に設定されると開始メッセージ（レスポンダまたは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.
（8ビット）#CS O：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ペイロードは、（ECのDiffie-Hellmanのサブペイロードの定義については6.1.4項を参照）IBEは、イニシエータとレスポンダのアイデンティティとECのDiffie-Hellmanサブペイロード（IBEの詳細については、[RFC5091]と[RFC5408]を参照）、暗号化が含まれ。これは、1つまたは複数のECのDiffie-Hellmanサブペイロードとそれに関連するアイデンティティを含んでいてもよいです。最後のECディフィー・ヘルマンやアイデンティティのサブペイロードは、その次のペイロードフィールドは、最後のペイロードに設定されています。
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データLEN（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は（秘密鍵サブペイロードの定義については、セクション6.1.5を参照）（IBEの詳細については、[RFC5091]と[RFC5408]を参照）秘密鍵サブペイロードとそれに関連するアイデンティティを暗号化が含まれています。
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データLEN（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は、一つ以上の秘密鍵を含まなければなりません。
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ディフィー・ヘルマン（ECCPT）サブペイロードは、以下に定義されたフォーマットを使用します。マイキー・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.
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ビット境界に終了するパディング。
o Auth alg (8 bits): specifies the MAC algorithm used for the verification message. For MIKEY-IBAKE this field is ignored.
O認証ALG（8ビット）：確認メッセージのために使用されるMACアルゴリズムを指定します。 MIKEY-IBAKEの場合、このフィールドは無視されます。
o TGK len (16 bits): the length of the TGK (in bytes). For MIKEY-IBAKE this field is ignored.
（バイト単位）TGKの長さ：TGK LEN（16ビット）O。 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.
入出力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.
入出力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]
入出力KV（4ビット）：指定されたキーの有効期間のタイプを示します。これは、（[RFC3711]の場合またはMKI）SPIを使用して実行してもよいし、キーが有効である期間を提供することによって（例えば、後者の場合、SRTPは、このキーはインデックス範囲であろう有効）。 KV値は、[RFC3830]のセクション6.13と同じです
o Key data len (16 bits): the length of the Key data field (in bytes).
O鍵データLEN（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.
入出力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プロトコルのセキュリティ特性は、同様MIKEY-IBAKEに適用されます。 [RFC5091]、[RFC5408]及び[RFC5409]で指定され、そのようなものとして、そのプロトコルのいくつかのプロパティを継承するように加えて、MIKEY-IBAKEは、基本的な識別情報に基づく暗号化プロトコルに基づいています。例えば、同一性を有する「日付」（公開鍵を導出するために）連結することで、任意のキー失効メカニズムの必要性が事実上排除されます。また、参加者が複数の秘密鍵を取得することを可能にすることによって（例えば、契約の期間）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]はIDベースの暗号化に使用される暗号アルゴリズムへの攻撃について説明します。また、[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）。さらに、イニシエータとレスポンダ間の会話へのアクセス権を持ち、積極的にパケットにスヌープ・ドロップ/宛先にルーティングする前にそれらを変更することができます敵を想定しています。例えば、IPソースアドレスと宛先アドレスは、敵によって改変することができると仮定する。最初のメッセージが（レスポンダ）はイニシエータによって送信された後、敵はパケットを引き継ぐおよびトラップすることができます。次に、敵はレスポンダにそれをルーティングする前に、敵のIPアドレスが含まれるように送信元IPアドレスを変更することができます。 IBAKEセッションの要求を引き受けるであろうレスポンダが敵から来てIBAKEプロトコル（すなわち、セクション4.1で、図3のR_MESSAGE_1）のステップ2を実行するが、敵対者の公開鍵を使って暗号化します。上記メッセージは、敵（とのみ敵による）によって復号することができます。 2番目のメッセージは、レスポンダにイニシエータによって送信されたチャレンジを含んでいるため、特に、敵は今、イニシエータによって送信された課題を学びます。これに続いて、敵がレスポンダする「ふり」イニシエータとの会話を続けることができます。アイデンティティは暗号化されたペイロードの一部として使用されている場合は、この攻撃が排除されます。要約すると、為替の終わりにイニシエータとレスポンダの両方が相互に認証することができ、セッションキーについては同意します。
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。しかし、KMSは、セッション鍵を知ることができない[X] [Y] P所与[X] Pと楕円曲線のDiffie-Hellman問題に基づいて、[Y] P。 KMSからパッシブキーエスクローに対する抵抗性のこの特性は、基本的なIBEの[RFC5091]で提案されたプロトコル、[RFC5408]及び[RFC5409]には適用できません。
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.
フォーク機能では、複数の潜在的なレスポンダがあることを考えると、そこに一つの「共通レスポンダ」同一であることを観察することが重要である（と公開鍵と秘密鍵に対応する）と、各Responderは一意のIDを持っている（と公開鍵と秘密鍵を対応） 。 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.
それがリターゲットレスポンダの公開鍵を使って暗号化されているので、リターゲット機能では、転送サーバは、意図したレスポンダの秘密鍵を学ぶことはありません。リターゲットレスポンダがイニシエータに送信されたメッセージでは、独自のアイデンティティを含んでいるのでさらに、イニシエータはターゲットを変更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ペイロードレジストリに追加されました。
o Data Type (see Table 2)
データ型（表2参照）O
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
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ビットのTypeフィールドを定義し、MIKEYペイロードレジストリに新しい名前空間を維持します。割り当ては、キーと関連する値のタイプから成ります。範囲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.
コンピューティング、VOLのSIAM J.における[BF] Boneh、D.およびM.フランクリン、 "ワイルペアリングからの識別情報に基づく暗号化"、。 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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、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]カララ、E.、Lehtovirta、V.、およびK. Norrman、RFC 4563、2006年6月 "マルチメディア、インターネットキーイングで一般拡張ペイロード（MIKEY）のためのキーのID情報タイプ"。
[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]マットソン、J.およびT.天、 "MIKEY-TICKET：マルチメディアインターネットキーイング（マイキー）で鍵配布のチケットベースモード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年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 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.林、 "MIKEY-RSA-R：マルチメディアインターネットキーイング（マイキー）で鍵配布の追加モード"、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.マーチン、 "IDベース暗号化規格（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]アッペンツェル、G.、マーティン、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]マーティン、L.およびM. Schertler、RFC 5409 "暗号メッセージ構文（CMS）とBoneh-フランクリンとBoneh-Boyenアイデンティティベースの暗号化アルゴリズムを使用する" を、2009年1月。
Authors' Addresses
著者のアドレス
Violeta Cakulev Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
するVioleta Cakulevアルカテル・ルーセント600マウンテンアベニュー3D-517マレーヒル、NJ 07974米国
Phone: +1 908 582 3207 EMail: violeta.cakulev@alcatel-lucent.com
電話：+1 908 582 3207 Eメール：violeta.cakulev@alcatel-lucent.com
Ganapathy Sundaram Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
ガナパシーSundaramアルカテル・ルーセント600マウンテンアベニュー3D-517マレーヒル、NJ 07974米国
Phone: +1 908 582 3209 EMail: ganesh.sundaram@alcatel-lucent.com
電話：+1 908 582 3209 Eメール：ganesh.sundaram@alcatel-lucent.com