Network Working Group J. Arkko
Request for Comments: 3830 E. Carrara
Category: Standards Track F. Lindholm
M. Naslund
K. Norrman
Ericsson Research
August 2004
MIKEY: Multimedia Internet KEYing
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real-time Transport Protocol is described in detail.
この文書は、（ピア・ツー・ピア通信及びグループ通信用の両方）リアルタイムアプリケーションのために使用することができる鍵管理方式が記載されています。具体的には、セキュアリアルタイムトランスポートプロトコルをサポートするためのその使用は詳細に記載されています。
Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols.
リアルタイムのマルチメディア・アプリケーションのセキュリティプロトコルが登場し始めています。これは、これらのプロトコルをサポートするための鍵管理ソリューションの必要性を前倒ししています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Existing Solutions . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.3. Definitions. . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Abbreviations. . . . . . . . . . . . . . . . . . . . . . 6
1.5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 8
2.3. System Overview. . . . . . . . . . . . . . . . . . . . . 8
2.4. Relation to GKMARCH. . . . . . . . . . . . . . . . . . . 10
3. Basic Key Transport and Exchange Methods . . . . . . . . . . . 10
3.1. Pre-shared Key . . . . . . . . . . . . . . . . . . . . . 12
3.2. Public-Key Encryption. . . . . . . . . . . . . . . . . . 13
3.3. Diffie-Hellman Key Exchange. . . . . . . . . . . . . . . 14
4. Selected Key Management Functions. . . . . . . . . . . . . . . 15
4.1. Key Calculation. . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Assumptions. . . . . . . . . . . . . . . . . . . 16
4.1.2. Default PRF Description. . . . . . . . . . . . . 17
4.1.3. Generating keys from TGK . . . . . . . . . . . . 18
4.1.4. Generating keys for MIKEY Messages from
an Envelope/Pre-Shared Key . . . . . . . . . . . 19
4.2 Pre-defined Transforms and Timestamp Formats . . . . . . . 19
4.2.1. Hash Functions . . . . . . . . . . . . . . . . . 19
4.2.2. Pseudo-Random Number Generator and PRF . . . . . 20
4.2.3. Key Data Transport Encryption. . . . . . . . . . 20
4.2.4. MAC and Verification Message Function. . . . . . 21
4.2.5. Envelope Key Encryption. . . . . . . . . . . . . 21
4.2.6. Digital Signatures . . . . . . . . . . . . . . . 21
4.2.7. Diffie-Hellman Groups. . . . . . . . . . . . . . 21
4.2.8. Timestamps . . . . . . . . . . . . . . . . . . . 21
4.2.9. Adding New Parameters to MIKEY . . . . . . . . . 22
4.3. Certificates, Policies and Authorization . . . . . . . . 22
4.3.1. Certificate Handling . . . . . . . . . . . . . . 22
4.3.2. Authorization. . . . . . . . . . . . . . . . . . 23
4.3.3. Data Policies. . . . . . . . . . . . . . . . . . 24
4.4. Retrieving the Data SA . . . . . . . . . . . . . . . . . 24
4.5. TGK Re-Keying and CSB Updating . . . . . . . . . . . . . 25
5. Behavior and Message Handling. . . . . . . . . . . . . . . . . 26
5.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1. Capability Discovery . . . . . . . . . . . . . . 26
5.1.2. Error Handling . . . . . . . . . . . . . . . . . 27
5.2. Creating a Message . . . . . . . . . . . . . . . . . . . 28
5.3. Parsing a Message. . . . . . . . . . . . . . . . . . . . 29
5.4. Replay Handling and Timestamp Usage. . . . . . . . . . . 30
6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Common Header Payload (HDR). . . . . . . . . . . . . . . 32
6.1.1. SRTP ID. . . . . . . . . . . . . . . . . . . . . 35
6.2. Key Data Transport Payload (KEMAC) . . . . . . . . . . . 36
6.3. Envelope Data Payload (PKE). . . . . . . . . . . . . . . 37
6.4. DH Data Payload (DH) . . . . . . . . . . . . . . . . . . 38
6.5. Signature Payload (SIGN) . . . . . . . . . . . . . . . . 39
6.6. Timestamp Payload (T). . . . . . . . . . . . . . . . . . 39
6.7. ID Payload (ID) / Certificate Payload (CERT) . . . . . . 40
6.8. Cert Hash Payload (CHASH). . . . . . . . . . . . . . . . 41
6.9. Ver msg payload (V). . . . . . . . . . . . . . . . . . . 42
6.10. Security Policy Payload (SP) . . . . . . . . . . . . . . 42
6.10.1. SRTP Policy. . . . . . . . . . . . . . . . . . . 44
6.11. RAND Payload (RAND). . . . . . . . . . . . . . . . . . . 45
6.12. Error Payload (ERR). . . . . . . . . . . . . . . . . . . 46
6.13. Key Data Sub-Payload . . . . . . . . . . . . . . . . . . 46
6.14. Key Validity Data. . . . . . . . . . . . . . . . . . . . 48
6.15. General Extension Payload. . . . . . . . . . . . . . . . 50
7. Transport Protocols. . . . . . . . . . . . . . . . . . . . . . 50
8. Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.1. Simple One-to-Many . . . . . . . . . . . . . . . . . . . 51
8.2. Small-Size Interactive Group . . . . . . . . . . . . . . 51
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 52
9.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 52
9.2. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . 54
9.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 55
9.4. Identity Protection. . . . . . . . . . . . . . . . . . . 55
9.5. Denial of Service. . . . . . . . . . . . . . . . . . . . 56
9.6. Session Establishment. . . . . . . . . . . . . . . . . . 56
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 57
10.1. MIME Registration. . . . . . . . . . . . . . . . . . . . 59
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. - MIKEY - SRTP Relation. . . . . . . . . . . . . . . . 63
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 66
There has recently been work to define a security protocol for the protection of real-time applications running over RTP, [SRTP]. However, a security protocol needs a key management solution to exchange keys and related security parameters. There are some fundamental properties that such a key management scheme has to fulfill to serve streaming and real-time applications (such as unicast and multicast), particularly in heterogeneous (mix of wired and wireless) networks.
最近RTP、[SRTP]上で動作するリアルタイムアプリケーションの保護のためのセキュリティプロトコルを定義するための作業が行われています。しかし、セキュリティプロトコルは、交換キーおよび関連するセキュリティパラメータの鍵管理ソリューションを必要とします。このような鍵管理方式は、特に不均一で、（例えば、ユニキャストおよびマルチキャストなど）ストリーミングおよびリアルタイムアプリケーションを提供するためにネットワーク（有線及び無線の組み合わせ）を満たさなければならないいくつかの基本的な特性があります。
This document describes a key management solution that addresses multimedia scenarios (e.g., SIP [SIP] calls and RTSP [RTSP] sessions). The focus is on how to set up key management for secure multimedia sessions such that requirements in a heterogeneous environment are fulfilled.
この文書は、マルチメディアシナリオ（例えば、SIP [SIP]コールとRTSP [RTSP]セッション）アドレス鍵管理ソリューションを記述する。焦点は、異機種環境での要件が満たされていることを、このようなセキュアなマルチメディアセッションのための鍵管理を設定する方法です。
There is work done in the IETF to develop key management schemes. For example, IKE [IKE] is a widely accepted unicast scheme for IPsec, and the MSEC WG is developing other schemes to address group communication [GDOI, GSAKMP]. However, for reasons discussed below, there is a need for a scheme with lower latency, suitable for demanding cases such as real-time data over heterogeneous networks and small interactive groups.
鍵管理スキームを開発するIETFで行われた作業があります。例えば、IKE [IKE]はIPsecのための広く受け入れられているユニキャスト方式であり、そしてMSEC WGは、グループ通信[GDOI、GSAKMP]を対処するための他のスキームを開発しています。しかし、以下に説明する理由のために、異種ネットワーク及び小インタラクティブグループにわたって、リアルタイムデータとしてケースを要求するのに適した低いレイテンシ方式が必要とされています。
An option in some cases might be to use [SDP], as SDP defines one field to transport keys, the "k=" field. However, this field cannot be used for more general key management purposes, as it cannot be extended from the current definition.
SDPは、キー、「K =」フィールドを輸送する一つのフィールドを定義するように、いくつかの場合にはオプションは、[SDP]を使用するかもしれません。それは現在の定義から拡張することはできませんしかし、この分野では、より一般的な鍵管理の目的で使用することはできません。
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
(Data) Security Protocol: the security protocol used to protect the actual data traffic. Examples of security protocols are IPsec and SRTP.
（データ）セキュリティプロトコル：実際のデータトラフィックを保護するために使用するセキュリティプロトコル。セキュリティプロトコルの例としては、IPsecとSRTPです。
Data Security Association (Data SA): information for the security protocol, including a TEK and a set of parameters/policies.
データセキュリティ協会（データSA）：TEKとパラメータ/ポリシーのセットを含む、セキュリティプロトコルのための情報、。
Crypto Session (CS): uni- or bi-directional data stream(s), protected by a single instance of a security protocol. For example, when SRTP is used, the Crypto Session will often contain two streams, an RTP stream and the corresponding RTCP, which are both protected by a single SRTP Cryptographic Context, i.e., they share key data and the bulk of security parameters in the SRTP Cryptographic Context (default behavior in [SRTP]). In the case of IPsec, a Crypto Session would represent an instantiation of an IPsec SA. A Crypto Session can be viewed as a Data SA (as defined in [GKMARCH]) and could therefore be mapped to other security protocols if necessary.
暗号化セッション（CS）：ユニ又は双方向データストリーム（S）、セキュリティプロトコルの単一のインスタンスによって保護。例えば、SRTPが使用される場合、暗号化セッションは、多くの場合、両方の単SRTP暗号コンテキストによって保護された2つのストリーム、RTPストリームおよび対応するRTCPを含むであろう、すなわち、それらは、キーデータとのセキュリティパラメータの大部分を共有しますSRTP暗号コンテキスト（[SRTP]のデフォルトの動作）。 IPsecの場合には、暗号化セッションは、IPsec SAのインスタンスを表すことになります。暗号化セッションデータSAとみなすことができる（[GKMARCH]で定義されるように）、必要に応じて、したがって、他のセキュリティプロトコルにマッピングすることができます。
Crypto Session Bundle (CSB): collection of one or more Crypto Sessions, which can have common TGKs (see below) and security parameters.
暗号化セッションバンドル（CSB）：共通TGKs（下記参照）とセキュリティパラメータを持つことができる1つまたは複数の暗号化セッションのコレクション。
Crypto Session ID: unique identifier for the CS within a CSB.
暗号化セッションID：CSB内でCSの一意の識別子。
Crypto Session Bundle ID (CSB ID): unique identifier for the CSB.
暗号化セッションバンドルID（CSB ID）：CSBの一意の識別子。
TEK Generation Key (TGK): a bit-string agreed upon by two or more parties, associated with CSB. From the TGK, Traffic-encrypting Keys can then be generated without needing further communication.
TEK世代キー（TGK）は：ビット列は、CSBに関連する2つの以上の当事者によって合意されました。 TGKからは、トラフィック暗号化キーは、さらなる通信を必要とせずに生成することができます。
Traffic-Encrypting Key (TEK): the key used by the security protocol to protect the CS (this key may be used directly by the security protocol or may be used to derive further keys depending on the security protocol). The TEKs are derived from the CSB's TGK.
トラフィック暗号化キー（TEK）：CSを保護するためのセキュリティプロトコルで使用されるキーは、（このキーは、セキュリティプロトコルで直接使用することができるか、セキュリティプロトコルに応じて、さらに鍵を導出するために使用することができます）。 TEKは、CSBのTGKから派生しています。
TGK re-keying: the process of re-negotiating/updating the TGK (and consequently future TEK(s)).
TGK再キーイング：再交渉/ TGKを更新する（その結果、将来のTEK（S））のプロセス。
Initiator: the initiator of the key management protocol, not necessarily the initiator of the communication.
イニシエータ：鍵管理プロトコルの開始、必ずしも通信の開始。
Responder: the responder in the key management protocol.
レスポンダ：鍵管理プロトコルで応答。
Salting key: a random or pseudo-random (see [RAND, HAC]) string used to protect against some off-line pre-computation attacks on the underlying security protocol.
キー塩析：基礎となるセキュリティプロトコルにいくつかのオフライン事前計算攻撃から保護するために使用されるランダムまたは擬似ランダム（[RAND、HAC]を参照）文字列。
PRF(k,x): a keyed pseudo-random function (see [HAC]). E(k,m): encryption of m with the key k. PKx: the public key of x [] an optional piece of information {} denotes zero or more occurrences || concatenation | OR (selection operator) ^ exponentiation XOR exclusive or
PRF（K、X）：キー付き疑似ランダム関数（[HAC]参照）。 E（K、M）：鍵KとMの暗号化。 PKX：Xの公開鍵[]情報の任意部分は{}ゼロ以上の出現を意味||連結| OR（選択演算子）^累乗XOR排他的論理和
Bit and byte ordering: throughout the document bits and bytes are indexed, as usual, from left to right, with the leftmost bits/bytes being the most significant.
ビットとバイト順序：文書のビットとバイト全体では、左端のビット/バイトが最も重要なもので、左から右へ、いつものように、インデックス化されています。
AES Advanced Encryption Standard CM Counter Mode (as defined in [SRTP]) CS Crypto Session CSB Crypto Session Bundle DH Diffie-Hellman DoS Denial of Service MAC Message Authentication Code MIKEY Multimedia Internet KEYing PK Public-Key PSK Pre-Shared key RTP Real-time Transport Protocol RTSP Real Time Streaming Protocol SDP Session Description Protocol SIP Session Initiation Protocol SRTP Secure RTP TEK Traffic-encrypting key TGK TEK Generation Key
AESのAdvanced Encryption Standard CMカウンタモード（[SRTP]で定義される）CS暗号化セッションサービスのCSB暗号化セッションバンドルDHのDiffie-HellmanのDoS攻撃拒否MACメッセージ認証コードMIKEYマルチメディア、インターネットイングPK公開鍵PSK事前共有キーRTP実時間トランスポートプロトコルRTSPリアルタイムストリーミングプロトコルSDPセッション記述プロトコルSIPセッション開始プロトコルSRTPセキュアRTP TEKトラフィック暗号化キーTGK TEK世代キー
Section 2 describes the basic scenarios and the design goals for which MIKEY is intended. It also gives a brief overview of the entire solution and its relation to the group key management architecture [GKMARCH].
第2節では、基本的なシナリオとMIKEYが意図されている設計目標について説明します。また、ソリューション全体およびグループ鍵管理アーキテクチャ[GKMARCH]との関係の概要を示します。
The basic key transport/exchange mechanisms are explained in detail in Section 3. The key derivation, and other general key management procedures are described in Section 4.
基本キー輸送/交換機構は、キー導出3節で詳しく説明されており、他の一般的な鍵管理手順はセクション4に記載されています。
Section 5 describes the expected behavior of the involved parties. This also includes message creation and parsing.
第5節では、関係者の期待される動作を説明します。これは、メッセージの作成と解析が含まれています。
All definitions of the payloads in MIKEY are described in Section 6.
マイキーでのペイロードのすべての定義は、第6節で説明されています。
Section 7 deals with transport considerations, while Section 8 focuses on how MIKEY is used in group scenarios.
第輸送配慮した7件のホテル・8節はMIKEYは、グループのシナリオでどのように使用されるかに焦点を当てながら。
The Security Considerations section (Section 9), gives a deeper explanation of important security related topics.
Security Considerations部（第9節）、重要なセキュリティ関連のトピックのより深い説明を与えます。
MIKEY is mainly intended to be used for peer-to-peer, simple one-to-many, and small-size (interactive) groups. One of the main multimedia scenarios considered when designing MIKEY has been the conversational multimedia scenario, where users may interact and communicate in real-time. In these scenarios it can be expected that peers set up multimedia sessions between each other, where a multimedia session may consist of one or more secured multimedia streams (e.g., SRTP streams).
MIKEYは、主にピア・ツー・ピア、一対多、および小型の単純な（対話型）グループのために使用されることが意図されます。 MIKEYを設計する際に考慮主なマルチメディアシナリオの一つは、ユーザーがリアルタイムで対話し、通信することができる会話のマルチメディアシナリオ、となっています。これらのシナリオでは、ピアは、マルチメディアセッションは、1つ以上の保護されたマルチメディアストリーム（例えば、SRTPストリーム）から構成することができる場合に、互いの間のマルチメディアセッションをセットアップすることが期待できます。
peer-to-peer/ many-to-many many-to-many
simple one-to-many (distributed) (centralized)
++++ ++++ ++++ ++++ ++++
|. | |A | |B | |A |---- ----|B |
--| ++++ | |----------| | | | \ / | |
++++ / ++|. | ++++ ++++ ++++ (S) ++++
|A |---------| ++++ \ / |
| | \ ++|B | \ / |
++++ \-----| | \ ++++ / ++++
++++ \|C |/ |C |
| | | |
++++ ++++
Figure 2.1: Examples of the four scenarios: peer-to-peer, simple one-to-many, many-to-many without a centralized server (also denoted as small interactive group), and many-to-many with a centralized server.
図2.1：4つのシナリオの例としては：ピアツーピア、単純な1対多数、（も小さな相互作用性基として示される）、中央サーバなしで多対多、および多対多の集中型サーバと。
We identify in the following some typical scenarios which involve the multimedia applications we are dealing with (see also Figure 2.1).
私たちは（図2.1も参照）を扱っているマルチメディア・アプリケーションを伴う以下のいくつかの典型的なシナリオで識別します。
a) peer-to-peer (unicast), e.g., a SIP-based [SIP] call between two parties, where it may be desirable that the security is either set up by mutual agreement or that each party sets up the security for its own outgoing streams.
セキュリティが相互の合意により設定又は各当事者は、そのためのセキュリティを設定することであるいずれかのことが望ましいかもしれない二者間A）ピア・ツー・ピア（ユニキャスト）、例えば、SIPベースの[SIP]コール、自分の発信ストリーム。
b) simple one-to-many (multicast), e.g., real-time presentations, where the sender is in charge of setting up the security.
b）は、単純な1対多（マルチキャスト）、送信者がセキュリティの設定を担当するなど、リアルタイムのプレゼンテーション、。
c) many-to-many, without a centralized control unit, e.g., for small-size interactive groups where each party may set up the security for its own outgoing media. Two basic models may be used here. In the first model, the Initiator of the group acts as the group server (and is the only one authorized to include new members). In the second model, authorization information to include new members can be delegated to other participants.
C）多対多、集中制御装置なしに、例えば、各当事者は、それ自身の発信メディアのセキュリティを設定することができる小型インタラクティブグループのため。二つの基本的なモデルがここで使用することができます。最初のモデルでは、グループの開始は、グループサーバとして動作（および新しいメンバーを含めることを許可唯一のものです）。第2のモデルでは、新しいメンバーを含むように、認可情報が他の参加者に委任することができます。
d) many-to-many, with a centralized control unit, e.g., for larger groups with some kind of Group Controller that sets up the security.
D）多対多、集中制御装置と、例えば、セキュリティを設定するグループコントローラのいくつかの種類に大きなグループのために。
The key management solutions may be different in the above scenarios. When designing MIKEY, the main focus has been on case a, b, and c. For scenario c, only the first model is covered by this document.
鍵管理ソリューションは、上記のシナリオでも異なっていてもよいです。 MIKEYを設計する際に、主な焦点は、ケースA、B、及びCにされています。シナリオCの、唯一の最初のモデルは、このドキュメントで覆われています。
The key management protocol is designed to have the following characteristics:
鍵管理プロトコルは、次のような特性を持つように設計されています。
* End-to-end security. Only the participants involved in the communication have access to the generated key(s).
*エンドツーエンドのセキュリティ。通信に関与する唯一の参加者は、生成されたキー（複数可）へのアクセス権を持っています。
* Simplicity.
*シンプル。
* Efficiency. Designed to have: - low bandwidth consumption, - low computational workload, - small code size, and - minimal number of roundtrips.
* 効率。持つように設計されている： - 低帯域幅の消費量、 - 低い計算ワークロード、 - 小さなコードサイズ、および - 往復の最小数。
* Tunneling. Possibility to "tunnel"/integrate MIKEY in session establishment protocols (e.g., SDP and RTSP).
*トンネル。 「トンネル」/セッション確立プロトコル（例えば、SDPとRTSP）でMIKEYを統合する可能性。
* Independence from any specific security functionality of the underlying transport.
*基礎となるトランスポートのいずれかの特定のセキュリティ機能から独立。
One objective of MIKEY is to produce a Data SA for the security protocol, including a traffic-encrypting key (TEK), which is derived from a TEK Generation Key (TGK), and used as input for the security protocol.
MIKEYの1つの目的は、TEK生成キー（TGK）に由来し、セキュリティプロトコルのための入力として使用されるトラフィック暗号化キー（TEK）を含む、セキュリティプロトコル用のデータSAを生成することです。
MIKEY supports the possibility of establishing keys and parameters for more than one security protocol (or for several instances of the same security protocol) at the same time. The concept of Crypto Session Bundle (CSB) is used to denote a collection of one or more Crypto Sessions that can have common TGK and security parameters, but which obtain distinct TEKs from MIKEY.
MIKEYは、同時に（または同じセキュリティプロトコルの複数のインスタンスのための）複数のセキュリティプロトコルのためのキーとパラメータを確立する可能性をサポートしています。暗号化セッションバンドル（CSB）の概念は、共通TGK及びセキュリティパラメータを有することができる1つまたは複数の暗号化セッションのコレクションを表すために使用されるが、MIKEYから別個のTEKを得たれます。
The procedure of setting up a CSB and creating a TEK (and Data SA), is done in accordance with Figure 2.2:
CSBを設定し、TEK（およびデータSA）を作成する手順は、図2.2に応じて行われます。
1. A set of security parameters and TGK(s) are agreed upon for the Crypto Session Bundle (this is done by one of the three alternative key transport/exchange mechanisms, see Section 3).
1.暗号化セッションバンドルの合意されたセキュリティパラメータとTGK（S）のセット（これは3つの代替鍵輸送/交換機構のいずれかによって行われ、第3章を参照されたいです）。
2. The TGK(s) is used to derive (in a cryptographically secure way) a TEK for each Crypto Session.
2. TGK（s）は（暗号的に安全な方法で）各暗号化セッションのためのTEKを導出するために使用されます。
3. The TEK, together with the security protocol parameters, represent the Data SA, which is used as the input to the security protocol.
3. TEKは、一緒になって、セキュリティプロトコルパラメータと、セキュリティプロトコルへの入力として使用されるデータSAを表します。
+-----------------+
| CSB |
| Key transport | (see Section 3)
| /exchange |
+-----------------+
| :
| TGK :
v :
+----------+ :
CS ID ->| TEK | : Security protocol (see Section 4)
|derivation| : parameters (policies)
+----------+ :
TEK | :
v v
Data SA
|
v
+-------------------+
| Crypto Session |
|(Security Protocol)|
+-------------------+
Figure 2.2: Overview of MIKEY key management procedure.
図2.2：MIKEY鍵管理手順の概要。
The security protocol can then either use the TEK directly, or, if supported, derive further session keys from the TEK (e.g., see SRTP [SRTP]). It is however up to the security protocol to define how the TEK is used.
セキュリティプロトコルは、直接TEKを使用するか、またはサポートされている場合、TEKからさらにセッションキーを導出するか（例えば、SRTP [SRTP]を参照）。しかしTEKを使用する方法を定義するセキュリティプロトコル次第です。
MIKEY can be used to update TEKs and the Crypto Sessions in a current Crypto Session Bundle (see Section 4.5). This is done by executing the transport/exchange phase once again to obtain a new TGK (and consequently derive new TEKs) or to update some other specific CS parameters.
MIKEYはのTEKと、現在の暗号化セッションのバンドルで暗号化セッションを（4.5節を参照）を更新するために使用することができます。これは、新しいTGKを得る（その結果、新規のTEKを派生）、またはいくつかの他の特定のCSパラメータを更新するために再び輸送/交換フェーズを実行することによって行われます。
The Group key management architecture (GKMARCH) [GKMARCH] describes a general architecture for group key management protocols. MIKEY is a part of this architecture, and can be used as a so-called Registration protocol. The main entities involved in the architecture are the group controller/key server (GCKS), the receiver(s), and the sender(s).
グループ鍵管理アーキテクチャ（GKMARCH）は[GKMARCH]グループ鍵管理プロトコルのための一般的なアーキテクチャを説明しています。 MIKEYは、このアーキテクチャの一部であり、いわゆる登録プロトコルとして使用することができます。アーキテクチャに関与する主エンティティは、グループコントローラ/鍵サーバ（GCKS）、受信機（複数可）、及び送信側（S）です。
In MIKEY, the sender could act as GCKS and push keys down to the receiver(s).
MIKEYにおいて、送信者はGCKSとして作用する可能性があり、受信機（複数可）までキーを押してください。
Note that, for example, in a SIP-initiated call, the sender may also be a receiver. As MIKEY addresses small interactive groups, a member may dynamically change between being a sender and receiver (or being both simultaneously).
例えば、SIPが開始するコールで、送信者は、受信機であってもよいことに留意されたいです。 MIKEY小さなインタラクティブグループをアドレスとして、メンバーが動的送信者と受信者である（または両方同時にである）との間で変化してもよいです。
The following sub-sections define three different methods of transporting/establishing a TGK: with the use of a pre-shared key, public-key encryption, and Diffie-Hellman (DH) key exchange. In the following, we assume unicast communication for simplicity. In addition to the TGK, a random "nonce", denoted RAND, is also transported. In all three cases, the TGK and RAND values are then used to derive TEKs as described in Section 4.1.3. A timestamp is also sent to avoid replay attacks (see Section 5.4).
事前共有鍵、公開鍵暗号化、ディフィー・ヘルマン（DH）鍵交換を使用して、次のサブセクションでは、TGKを確立/輸送の3つの異なる方法を定義します。以下では、簡単のためにユニキャスト通信を前提としています。 TGK、ランダム「ナンス」に加えて、さらに搬送され、RANDを表します。セクション4.1.3に記載したように3つのすべての場合において、TGK及びRAND値は、その後のTEKを導出するために使用されます。タイムスタンプはまた、リプレイ攻撃を（5.4節を参照）を避けるために送信されます。
The pre-shared key method and the public-key method are both based on key transport mechanisms, where the actual TGK is pushed (securely) to the recipient(s). In the Diffie-Hellman method, the actual TGK is instead derived from the Diffie-Hellman values exchanged between the peers.
事前共有鍵方式と公開鍵方式は、両方の実際のTGKは、受信者に（確実に）押されたキーのトランスポートメカニズムに基づいています。ディフィー・ヘルマン法では、実際のTGK代わりにピア間で交換のDiffie-Hellman値から導出されます。
The pre-shared case is, by far, the most efficient way to handle the key transport due to the use of symmetric cryptography only. This approach also has the advantage that only a small amount of data has to be exchanged. Of course, the problematic issue is scalability as it is not always feasible to share individual keys with a large group of peers. Therefore, this case mainly addresses scenarios such as server-to-client and also those cases where the public-key modes have already been used, thus allowing for the "cache" of a symmetric key (see below and Section 3.2).
事前共有の場合は、はるかに、のみによる対称暗号の使用に重要な輸送を処理するための最も効率的な方法です。このアプローチはまた、少量のデータだけを交換しなければならないという利点を有します。ピアの大規模なグループと個々のキーを共有することは常に可能ではないとしてもちろん、問題の問題は、スケーラビリティです。したがって、この場合は主にこれ（下記参照および3.2節）対称キーの「キャッシュ」を可能にし、そのような公開鍵方式が既に使用されているような場合も、サーバ・クライアント間およびなどのシナリオに対応しています。
Public-key cryptography can be used to create a scalable system. A disadvantage with this approach is that it is more resource consuming than the pre-shared key approach. Another disadvantage is that in most cases, a PKI (Public Key Infrastructure) is needed to handle the distribution of public keys. Of course, it is possible to use public keys as pre-shared keys (e.g., by using self-signed certificates). It should also be noted that, as mentioned above, this method may be used to establish a "cached" symmetric key that later can be used to establish subsequent TGKs by using the pre-shared key method (hence, the subsequent request can be executed more efficiently).
公開鍵暗号方式は、スケーラブルなシステムを作成するために使用することができます。このアプローチの欠点は、事前共有キーのアプローチよりも多くのリソースを消費するということです。もう一つの欠点は、ほとんどの場合には、PKI（公開鍵基盤）は、公開鍵の配布を処理するために必要とされることです。もちろん、（自己署名証明書を使用して、例えば）事前共有キーとして公開キーを使用することが可能です。また上述したように、この方法は、後に、事前共有鍵方式を使用して、後続のTGKsを確立するために使用することができる「キャッシュ」対称キーを確立するために使用されてもよいことに留意すべきである（従って、後続の要求を実行することができますより効率的に）。
In general, the Diffie-Hellman (DH) key agreement method has a higher resource consumption (both computationally and in bandwidth) than the previous ones, and needs certificates as in the public-key case. However, it has the advantage of providing perfect forward secrecy (PFS) and flexibility by allowing implementation in several different finite groups.
一般に、ディフィー・ヘルマン（DH）鍵合意方法は、以前のものよりも高いリソース消費（計算及び帯域幅の両方で）を有し、及び公開鍵の場合のように証明書を必要とします。しかし、それはいくつかの異なる有限群での実装を可能にすることにより、完全転送秘密（PFS）および柔軟性を提供するという利点を有します。
Note that by using the DH method, the two involved parties will generate a unique unpredictable random key. Therefore, it is not possible to use this DH method to establish a group TEK (as the different parties in the group would end up with different TEKs). It is not the intention of the DH method to work in this scenario, but to be a good alternative in the special peer-to-peer case.
DHメソッドを使用して、2つの当事者は、独自の予測不可能なランダムなキーを生成することに注意してください。したがって、（グループ内の異なる当事者が異なるのTEKで終わるように）グループTEKを確立するために、このDHメソッドを使用することはできません。このシナリオで動作するようにDH法の意図ではなく、特殊なピア・ツー・ピアの場合には良い代替します。
The following general notation is used:
以下の一般的な表記法が使用されます。
HDR: The general MIKEY header, which includes MIKEY CSB related data (e.g., CSB ID) and information mapping to the specific security protocol used. See Section 6.1 for payload definition.
HDR：使用される特定のセキュリティプロトコルにMIKEY CSBに関するデータ（例えば、CSB ID）と、情報のマッピングを含む一般MIKEYヘッダー。ペイロード定義については、セクション6.1を参照してください。
T: The timestamp, used mainly to prevent replay attacks. See Section 6.6 for payload definition and also Section 5.4 for other timestamp related information.
T：リプレイ攻撃を防ぐために主に使用されるタイムスタンプ、。他のタイムスタンプに関連する情報についても、ペイロードの定義については、セクション6.6および5.4節を参照してください。
IDx: The identity of entity x (IDi=Initiator, IDr=Responder). See Section 6.7 for payload definition.
IDX：エンティティXのID（IDiを=イニシエータ、IDR =レスポンダ）。ペイロード定義については、セクション6.7を参照してください。
RAND: Random/pseudo-random byte-string, which is always included in the first message from the Initiator. RAND is used as a freshness value for the key generation. It is not included in update messages of a CSB. See Section 6.11 for payload definition. For randomness recommendations for security, see [RAND].
RAND：常にイニシエータからの最初のメッセージに含まれているランダム/擬似ランダムバイト列、。 RANDは、鍵生成のための鮮度値として使用されます。それは、CSBの更新メッセージに含まれていません。ペイロード定義については、セクション6.11を参照してください。セキュリティのためのランダムの推奨事項については、[RAND]を参照してください。
SP: The security policies for the data security protocol. See Section 6.10 for payload definition.
SP：データセキュリティプロトコルのセキュリティポリシー。ペイロード定義については、セクション6.10を参照してください。
In this method, the pre-shared secret key, s, is used to derive key material for both the encryption (encr_key) and the integrity protection (auth_key) of the MIKEY messages, as described in Section 4.1.4. The encryption and authentication transforms are described in Section 4.2.
第4.1.4項で説明したように、この方法では、事前共有秘密鍵、Sは、MIKEYメッセージの暗号化（encr_key）および完全性保護（AUTH_KEY）の両方のためのキーマテリアルを導出するために使用されます。暗号化と認証変換は、セクション4.2で説明されています。
Initiator Responder
イニシエータレスポンダ
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
The main objective of the Initiator's message (I_MESSAGE) is to transport one or more TGKs (carried into KEMAC) and a set of security parameters (SPs) to the Responder in a secure manner. As the verification message from the Responder is optional, the Initiator indicates in the HDR whether it requires a verification message or not from the Responder.
イニシエータのメッセージ（I_MESSAGE）の主な目的は、安全な方法でレスポンダへの1つ以上のTGKs（KEMACに搬入）とセキュリティパラメータ（SPS）のセットを搬送することです。レスポンダから確認メッセージがオプションであるように、イニシエータは、レスポンダから確認メッセージかどうかを必要とするかどうかをHDRに示します。
KEMAC = E(encr_key, {TGK}) || MAC
KEMAC = E（encr_key、{} TGK）||マック
The KEMAC payload contains a set of encrypted sub-payloads and a MAC. Each sub-payload includes a TGK randomly and independently chosen by the Initiator (and other possible related parameters, e.g., the key lifetime). The MAC is a Message Authentication Code covering the entire MIKEY message using the authentication key, auth_key. See Section 6.2 for payload definition and Section 5.2 for an exact definition of the MAC calculation.
KEMACペイロードは暗号化されたサブペイロードとMACのセットが含まれています。各サブペイロードは、ランダムにかつ独立して開始剤（および他の可能な関連パラメータ、例えば、キー寿命）によって選択されたTGKを含みます。 MACは、メッセージ認証コードは、認証キー、AUTH_KEYを使用して全体MIKEYメッセージを覆っています。 MAC計算の正確な定義のためのペイロードの定義については、セクション6.2および5.2節を参照してください。
The main objective of the verification message from the Responder is to obtain mutual authentication. The verification message, V, is a MAC computed over the Responder's entire message, the timestamp (the same as the one that was included in the Initiator's message), and the two parties identities, using the authentication key. See also Section 5.2 for the exact definition of the Verification MAC calculation and Section 6.9 for payload definition.
レスポンダからの確認メッセージの主な目的は、相互認証を得ることです。確認メッセージ、Vは、MACは、レスポンダのメッセージ全体にわたって計算される、タイムスタンプ（イニシエータのメッセージに含まれていたものと同じ）、および認証鍵を使用して、2人の当事者のアイデンティティ、。ペイロード定義の検証MAC計算と6.9節の正確な定義については項5.2を参照してください。
The ID fields SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID (otherwise it cannot look up the pre-shared key). For example, this could be the case if the ID is extracted from SIP.
IDフィールドが含まれる必要がありますが、ピアがすでに相手のIDを知っていることを期待することができたときに、彼らは（それ以外の場合は、事前共有キーを調べることはできません）を残すことができます。例えば、これはIDをSIPから抽出された場合場合であってもよいです。
It is MANDATORY to implement this method.
このメソッドを実装するMANDATORYです。
Initiator Responder
イニシエータレスポンダ
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], [IDr], {SP},
KEMAC, [CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
As in the previous case, the main objective of the Initiator's message is to transport one or more TGKs and a set of security parameters to the Responder in a secure manner. This is done using an envelope approach where the TGKs are encrypted (and integrity protected) with keys derived from a randomly/pseudo-randomly chosen "envelope key". The envelope key is sent to the Responder encrypted with the public key of the Responder.
前の場合のように、イニシエータのメッセージの主な目的は、安全な方法でレスポンダへの1つ以上のTGKsおよびセキュリティパラメータのセットを輸送することです。これはTGKsがランダム/擬似ランダムに選択された「エンベロープキー」に由来する鍵で暗号化（及び完全性が保護された）されたエンベロープアプローチを使用して行われます。封筒キーはレスポンダの公開鍵で暗号化されたレスポンダに送信されます。
The PKE contains the encrypted envelope key: PKE = E(PKr, env_key). It is encrypted using the Responder's public key (PKr). If the Responder possesses several public keys, the Initiator can indicate the key used in the CHASH payload (see Section 6.8).
PKE = E（PKR、env_key）：PKEは暗号化されたエンベロープキーが含まれています。これは、レスポンダの公開鍵（PKR）を使用して暗号化されています。 Responderが複数の公開鍵を持っている場合、イニシエータはCHASHペイロードに使用されるキーを示すことができます（6.8節を参照してください）。
The KEMAC contains a set of encrypted sub-payloads and a MAC:
KEMACは暗号化されたサブペイロードとMACのセットが含まれています。
KEMAC = E(encr_key, IDi || {TGK}) || MAC
KEMAC = E（encr_key、IDI || {TGK}）||マック
The first payload (IDi) in KEMAC is the identity of the Initiator (not a certificate, but generally the same ID as the one specified in the certificate). Each of the following payloads (TGK) includes a TGK randomly and independently chosen by the Initiator (and possible other related parameters, e.g., the key lifetime). The encrypted part is then followed by a MAC, which is calculated over the KEMAC payload. The encr_key and the auth_key are derived from the envelope key, env_key, as specified in Section 4.1.4. See also Section 6.2 for payload definition.
KEMACにおける最初のペイロード（IDiとは）イニシエータのアイデンティティ（しない証明書が、一般的に証明書に指定されたものと同じID）です。次ペイロード（TGK）の各々は、ランダムにかつ独立イニシエータ（および可能な他の関連パラメータ、例えば、キー寿命）によって選択されたTGKを含みます。暗号化された部分は、その後KEMACペイロードにわたって計算されたMACが続きます。 encr_keyとAUTH_KEYは、セクション4.1.4で指定された封筒キー、env_key、由来しています。また、ペイロードの定義については、セクション6.2を参照してください。
The SIGNi is a signature covering the entire MIKEY message, using the Initiator's signature key (see also Section 5.2 for the exact definition).
SIGNiは、イニシエータの署名キー（正確な定義についてはセクション5.2を参照）を使用して、全体MIKEYメッセージをカバーする署名です。
The main objective of the verification message from the Responder is to obtain mutual authentication. As the verification message V from the Responder is optional, the Initiator indicates in the HDR whether it requires a verification message or not from the Responder. V is calculated in the same way as in the pre-shared key mode (see also Section 5.2 for the exact definition). See Section 6.9 for payload definition.
レスポンダからの確認メッセージの主な目的は、相互認証を得ることです。レスポンダから確認メッセージVは任意であるように、イニシエータは、レスポンダから確認メッセージかどうかを必要とするかどうかをHDRに示します。 Vは、（正確な定義についてはセクション5.2を参照）事前共有キーモードと同様に計算されます。ペイロード定義については、セクション6.9を参照してください。
Note that there will be one encrypted IDi and possibly also one unencrypted IDi. The encrypted one is used together with the MAC as a countermeasure for certain man-in-the-middle attacks, while the unencrypted one is always useful for the Responder to immediately identify the Initiator. The encrypted IDi MUST always be verified to be equal with the expected IDi.
1暗号化されたIDiと、おそらくも1暗号化されていないIDiとがあることに注意してください。 Responderがすぐにイニシエータを識別するために暗号化されていない1は常に有用であるが暗号化されたものが、特定のman-in-the-middle攻撃のための対策として、MACと一緒に使用されています。暗号化されたIDiとは、常に期待されるIDiをと同等であることが検証されなければなりません。
It is possible to cache the envelope key, so that it can be used as a pre-shared key. It is not recommended for this key to be cached indefinitely (however it is up to the local policy to decide this). This function may be very convenient during the lifetime of a CSB, if a new crypto session needs to be added (or an expired one removed). Then, the pre-shared key can be used, instead of the public keys (see also Section 4.5). If the Initiator indicates that the envelope key should be cached, the key is at least to be cached during the lifetime of the entire CSB.
事前共有キーとして使用することができるように、エンベロープキーをキャッシュすることが可能です。これは、無期限にキャッシュされるこのキーには推奨されません（ただし、それは、これを決定するローカルポリシー次第です）。新しい暗号化セッションを追加する必要があります（または削除された期限切れ1）場合、この関数は、CSBの寿命の間に非常に便利かもしれません。次に、事前共有キーは、（また、セクション4.5を参照）の代わりに公開鍵を、使用することができます。イニシエータは、エンベロープキーがキャッシュされるべきであることを示している場合、キーは、少なくとも全体CSBの存続期間中にキャッシュされます。
The cleartext ID fields and certificate SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID, or can obtain the certificate in some other manner. For example, this could be the case if the ID is extracted from SIP.
平文IDフィールドと証明書が含まれるべきであるが、ピアがすでに相手のIDを知っている、または他のいくつかの方法で証明書を取得することが期待できるとき、彼らは取り残されるかもしれません。例えば、これはIDをSIPから抽出された場合場合であってもよいです。
For certificate handling, authorization, and policies, see Section 4.3.
証明書の処理、承認、およびポリシーについては、4.3節を参照してください。
It is MANDATORY to implement this method.
このメソッドを実装するMANDATORYです。
For a fixed, agreed upon, cyclic group, (G,*), we let g denote a generator for this group. Choices for the parameters are given in Section 4.2.7. The other transforms below are described in Section 4.2.
固定された、合意、環状基、（G、*）のために、我々は、Gがこのグループのために発電機を示すものとします。パラメータの選択肢は、セクション4.2.7に記載されています。以下に他の変換はセクション4.2に記載されています。
This method creates a DH-key, which is used as the TGK. This method cannot be used to create group keys; it can only be used to create single peer-to-peer keys. It is OPTIONAL to implement this method.
この方法は、TGKとして使用されるDHキーを作成します。この方法では、グループキーを作成するために使用することはできません。単一のピア・ツー・ピアの鍵を作成するために使用することができます。このメソッドを実装するオプションです。
Initiator Responder
イニシエータレスポンダ
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],[IDr]
{SP}, DHi, SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi,
DHr, DHi, SIGNr
The main objective of the Initiator's message is to, in a secure way, provide the Responder with its DH value (DHi) g^(xi), where xi MUST be randomly/pseudo-randomly and secretly chosen, and a set of security protocol parameters.
xiが無作為/疑似ランダムと密かに選択され、セキュリティプロトコルの設定されなければならない場合、イニシエータのメッセージの主な目的は、安全な方法で、そのDH値（DHI）G ^（XI）とレスポンダを提供することですパラメーター。
The SIGNi is a signature covering the Initiator's MIKEY message, I_MESSAGE, using the Initiator's signature key (see Section 5.2 for the exact definition).
SIGNiは、イニシエータの署名鍵を（正確な定義についてはセクション5.2を参照）を使用して、イニシエータのMIKEYメッセージ、I_MESSAGEを覆う署名です。
The main objective of the Responder's message is to, in a secure way, provide the Initiator with the Responder's value (DHr) g^(xr), where xr MUST be randomly/pseudo-randomly and secretly chosen. The timestamp that is included in the answer is the same as the one included in the Initiator's message.
レスポンダのメッセージの主な目的は、安全な方法で、XRがランダム/擬似ランダムおよび秘密に選択されなければならないレスポンダの値（DHR）G ^（XR）とイニシエータを提供することです。答えに含まれているタイムスタンプは、イニシエータのメッセージに含まれるものと同じです。
The SIGNr is a signature covering the Responder's MIKEY message, R_MESSAGE, using the Responder's signature key (see Section 5.2 for the exact definition).
SIGNRはレスポンダの署名キー（正確な定義についてはセクション5.2を参照）を使用して、レスポンダのMIKEYメッセージ、R_MESSAGEを覆う署名です。
The DH group parameters (e.g., the group G, the generator g) are chosen by the Initiator and signaled to the Responder. Both parties calculate the TGK, g^(xi*xr) from the exchanged DH-values.
DHグループのパラメータ（例えば、グループG、ジェネレータg）がイニシエータによって選択され、レスポンダにシグナリングされます。両当事者が交換DH値からTGK、G ^（XIの*のXR）を計算します。
Note that this approach does not require that the Initiator has to possess any of the Responder's certificates before the setup. Instead, it is sufficient that the Responder includes its signing certificate in the response.
このアプローチは、イニシエータは、セットアップの前にレスポンダの証明書のいずれかを所有していることを必要としないことに注意してください。その代わりに、Responderが応答でその署名証明書が含まれていることは十分です。
The ID fields and certificate SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID (or can obtain the certificate in some other manner). For example, this could be the case if the ID is extracted from SIP.
IDフィールドと証明書が含まれるべきであるが、ピアがすでに相手のIDを知っている（または他の方法で証明書を取得することができます）ことを期待することができたときに彼らが出て残してもよいです。例えば、これはIDをSIPから抽出された場合場合であってもよいです。
For certificate handling, authorization, and policies, see Section 4.3.
証明書の処理、承認、およびポリシーについては、4.3節を参照してください。
MIKEY manages symmetric keys in two main ways. First, following key transport or key exchange of TGK(s) (and other parameters) as defined by any of the above three methods, MIKEY maintains a mapping between Data SA identifiers and Data SAs, where the identifiers used depend on the security protocol in question, see Section 4.4. Thus, when the security protocol requests a Data SA, given such a Data SA identifier, an up-to-date Data SA will be obtained. In particular, correct keying material, TEK(s), might need to be derived. The derivation of TEK(s) (and other keying material) is done from a TGK and is described in Section 4.1.3.
MIKEYは、主に2つの方法で対称鍵を管理します。上記3つの方法のいずれかによって定義されるように、まず、キー輸送又はTGKの鍵交換（S）は、以下の（および他のパラメータ）、MIKEYは、Data SA識別子及び使用される識別子は、セキュリティプロトコルに依存するデータのSAとの間のマッピングを維持します質問、4.4節を参照してください。セキュリティプロトコルは、データSAを要求するときにこのように、このようなデータSA識別子が与えられると、最新のデータSAが得られます。具体的には、正しい鍵材料、TEK（単数または複数）は、派生する必要があるかもしれません。 TEK（S）（および他のキーイング材料）の導出はTGKから行われ、セクション4.1.3に記載されています。
Second, for use within MIKEY itself, two key management procedures are needed:
第二に、MIKEY自体内で使用するために、二つの重要な管理手順が必要です：
* in the pre-shared case, deriving encryption and authentication key material from a single pre-shared key, and
*事前共有場合は、単一の事前共有鍵から暗号化および認証キーマテリアルを導出し、
* in the public key case, deriving similar key material from the transported envelope key.
*公開鍵場合、輸送封筒キーから同様のキーマテリアルを導出します。
These two key derivation methods are specified in section 4.1.4.
これら二つの鍵導出方法は、セクション4.1.4で指定されています。
All the key derivation functionality mentioned above is based on a pseudo-random function, defined next.
上記すべての鍵導出機能は、次の定義され、擬似ランダム関数に基づいています。
In the following, we define a general method (pseudo-random function) to derive one or more keys from a "master" key. This method is used to derive:
以下では、「マスター」鍵から1つ以上のキーを導出するために一般的な方法（擬似ランダム関数）を定義します。この方法は、導出するために使用されます。
* TEKs from a TGK and the RAND value,
* TGKとRAND値からのTEK、
* encryption, authentication, or salting key from a pre-shared/ envelope key and the RAND value.
*暗号化、認証、または事前共有/封筒キーとRAND値からキーを塩漬け。
We assume that the following parameters are in place:
私たちは、次のパラメータが用意されていることを前提としています。
csb_id : Crypto Session Bundle ID (32-bits unsigned integer) cs_id : the Crypto Session ID (8-bits unsigned integer) RAND : (at least) 128-bit (pseudo-)random bit-string sent by the Initiator in the initial exchange.
csb_id：暗号化セッションバンドルID（32ビットの符号なし整数）cs_id：暗号化セッションID（8ビット符号なし整数）RAND（少なくとも）128ビット（擬似）初期にイニシエータによって送信されたランダムなビット列交換。
The key derivation method has the following input parameters:
鍵導出方法は、以下の入力パラメータがあります。
inkey : the input key to the derivation function inkey_len : the length in bits of the input key label : a specific label, dependent on the type of the key to be derived, the RAND, and the session IDs outkey_len: desired length in bits of the output key.
INKEY：微分関数inkey_lenへ入力キー：特定のラベル、導出されるキーの種類に依存して、RAND、およびセッションID outkey_len：入力キーラベルのビット長のビットで所望の長さ出力キー。
The key derivation method has the following output:
鍵導出方法は、以下の出力があります。
outkey: the output key of desired length.
OUTKEY：所望の長さの出力キー。
Let HMAC be the SHA-1 based message authentication function, see [HMAC] [SHA-1]. Similarly to [TLS], we define:
[HMAC] [SHA-1]を参照して、HMACは、SHA-1ベースのメッセージ認証関数とします。同様に[TLS]に、我々は定義します。
P (s, label, m) = HMAC (s, A_1 || label) || HMAC (s, A_2 || label) || ... HMAC (s, A_m || label) where
P（S、ラベル、M）= HMAC（S、A_1 ||ラベル）|| HMAC（S、A_2 ||ラベル）|| ... HMAC（S、A_M ||ラベル）ここで、
A_0 = label, A_i = HMAC (s, A_(i-1)) s is a key (defined below) m is a positive integer (also defined below).
A_0 =ラベルは、a_iを= HMAC（S、A_（I-1））sは（以下に定義）キーでmは正の整数（下記に定義）です。
Values of label depend on the case in which the PRF is invoked, and values are specified in the following for the default PRF. Thus, note that other PRFs later added to MIKEY MAY specify different input parameters.
ラベルの値は、PRFが呼び出され、値がデフォルトPRFのために、以下に指定されている場合に依存しています。このように、他のPRFは、後で別の入力パラメータを指定するかもしれMIKEYに追加されることに注意してください。
The following procedure describes a pseudo-random function, denoted PRF(inkey,label), based on the above P-function, applied to compute the output key, outkey:
次の手順では、PRF（INKEY、ラベル）を付し、擬似ランダム関数を記述し、上記P-関数に基づいて、出力キー、OUTKEYを計算するために適用されます。
* let n = inkey_len / 256, rounded up to the nearest integer if not already an integer
*、= inkey_len / 256 Nせ既に整数を最も近い整数に切り上げられない場合
* split the inkey into n blocks, inkey = s_1 || ... || s_n, where * all s_i, except possibly s_n, are 256 bits each
* n個のブロックにINKEYを分割し、INKEY = S_1 || ... || S_N、*おそらくS_Nを除くすべてのS_Iは、各256ビットです
* let m = outkey_len / 160, rounded up to the nearest integer if not already an integer
*せM = outkey_len / 160、既に整数を最も近い整数に切り上げられない場合
(The values "256" and "160" equals half the input block-size and full output hash size, respectively, of the SHA-1 hash as part of the P-function.)
（値は「256」と「160」P-機能の一部として、SHA-1ハッシュのそれぞれ半分の入力ブロックサイズと全出力ハッシュサイズを、等しいです。）
Then, the output key, outkey, is obtained as the outkey_len most significant bits of
そして、出力キーは、OUTKEYのoutkey_len最上位ビットとして得られます。
PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ... XOR P(s_n, label, m).
PRF（INKEY、ラベル）= P（S_1、ラベル、M）XOR P（S_2、ラベル、M）XOR ... XOR P（S_N、ラベル、M）。
In the following, we describe how keying material is derived from a TGK, thus assuming that a mapping of the Data SA identifier to the correct TGK has already been done according to Section 4.4.
以下では、我々は、このように正しいTGKにデータSA識別子のマッピングは既にセクション4.4に従って行われたと仮定すると、TGK由来する方法キーイング材料を記載しています。
The key derivation method SHALL be executed using the above PRF with the following input parameters:
鍵導出方法は、以下の入力パラメータと上記PRFを使用して実行されなければなりません。
inkey : TGK inkey_len : bit length of TGK label : constant || cs_id || csb_id || RAND outkey_len : bit length of the output key.
INKEY：TGK inkey_len：TGKラベルのビット長：定数|| cs_id || csb_id || RAND outkey_len：出力キーのビット長。
The constant part of label depends on the type of key that is to be generated. The constant 0x2AD01C64 is used to generate a TEK from TGK. If the security protocol itself does not support key derivation for authentication and encryption from the TEK, separate authentication and encryption keys MAY be created directly for the security protocol by replacing 0x2AD01C64 with 0x1B5C7973 and 0x15798CEF respectively, and outkey_len by the desired key-length(s) in each case.
ラベルの一定の部分が生成されるキーの種類によって異なります。定数0x2AD01C64はTGKからTEKを生成するために使用されます。セキュリティプロトコル自体はTEKから認証および暗号化のための鍵導出をサポートしていない場合は、別の認証および暗号化キーは、それぞれ0x1B5C7973と0x15798CEFと0x2AD01C64を置き換えることにより、セキュリティプロトコルに直接作成され、所望のキー長（Sによりoutkey_lenれるかもしれません） いずれの場合にも。
A salt key can be derived from the TGK as well, by using the constant 0x39A2C14B. Note that the Key data sub-payload (Section 6.13) can carry a salt. The security protocol in need of the salt key SHALL use the salt key carried in the Key data sub-payload (in the pre-shared and public-key case), when present. If that is not sent, then it is possible to derive the salt key via the key derivation function, as described above.
塩キーは定数0x39A2C14Bを用いて、同様にTGKから誘導することができます。鍵データサブペイロード（セクション6.13の）塩を運ぶことができることに留意されたいです。存在する場合、塩のキーを必要とするセキュリティプロトコルは、（事前共有及び公開鍵場合）キーデータサブペイロードで運ば塩キーを使用しなければなりません。それが送信されていない場合、上記のように、鍵導出関数を介し塩鍵を導出することが可能です。
The table below summarizes the constant values, used to generate keys from a TGK.
以下の表はTGKからキーを生成するために使用される定数値をまとめたものです。
constant | derived key from the TGK
--------------------------------------
0x2AD01C64 | TEK
0x1B5C7973 | authentication key
0x15798CEF | encryption key
0x39A2C14B | salting key
Table 4.1.3: Constant values for the derivation of keys from TGK.
表4.1.3：TGKからキーの導出のための定数値。
Note that these 32-bit constant values (listed in the table above) are taken from the decimal digits of e (i.e., 2.7182...), where each constant consists of nine decimal digits (e.g., the first nine decimal digits 718281828 = 0x2AD01C64). The strings of nine decimal digits are not chosen at random, but as consecutive "chunks" from the decimal digits of e.
例えば、最初の9桁718281828 =（各定数は、9桁から成る場合、（上記の表に記載されている）、これらの32ビット定数値はEの桁から取られることに留意されたい（すなわち、2.7182 ...） 0x2AD01C64）。 9桁の文字列がランダムに選ばれていないが、電子の桁から連続する「チャンク」など。
4.1.4. Generating keys for MIKEY messages from an envelope/pre-shared key
4.1.4. 封筒/事前共有キーからMIKEYメッセージ用の鍵を生成します
This derivation is to form the symmetric encryption key (and salting key) for the encryption of the TGK in the pre-shared key and public key methods. This is also used to derive the symmetric key used for the message authentication code in these messages, and the corresponding verification messages. Hence, this derivation is needed in order to get different keys for the encryption and the MAC (and in the case of the pre-shared key, it will result in fresh key material for each new CSB). The parameters for the default PRF are here:
この導出は、事前共有鍵と公開鍵方法でTGKの暗号化に対称暗号鍵（および塩析キー）を形成することです。これは、これらのメッセージにメッセージ認証コードのために使用される対称鍵、および対応する検証メッセージを導出するために使用されます。したがって、この導出は、暗号化とMAC（および事前共有キーの場合には、それはそれぞれの新しいCSBのために新鮮なキーマテリアルになります）ごとに異なる鍵を得るために必要とされています。デフォルトのPRFのためのパラメータはここにあります：
inkey : the envelope key or the pre-shared key inkey_len : the bit length of inkey label : constant || 0xFF || csb_id || RAND outkey_len : desired bit length of the output key.
INKEY：封筒キーまたは事前共有鍵inkey_len：INKEYラベルのビット長：定数|| 0xFFを|| csb_id || RAND outkey_len：出力キーの所望のビット長。
The constant part of label depends on the type of key that is to be generated from an envelope/pre-shared key, as summarized below.
ラベルの一定の部分は、以下に要約されるように、エンベロープ/事前共有鍵から生成されるキーの種類に依存します。
constant | derived key
--------------------------------------
0x150533E1 | encryption key
0x2D22AC75 | authentication key
0x29B88916 | salt key
Table 4.1.4: Constant values for the derivation of keys from an envelope/pre-shared key.
表4.1.4：エンベロープ/事前共有キーからキーの導出用の定数値。
This section identifies default transforms for MIKEY. It is mandatory to implement and support the following transforms in the respective case. New transforms can be added in the future (see Section 4.2.9 for further guidelines).
このセクションでは、MIKEYのデフォルトの変換を識別します。実装し、それぞれの場合には、次の変換をサポートするために必須です。新しい変換は、将来の（さらなるガイドラインについては、セクション4.2.9を参照）に追加することができます。
In MIKEY, it is MANDATORY to implement SHA-1 as the default hash function.
MIKEYでは、デフォルトのハッシュ関数としてSHA-1を実現することは必須です。
A cryptographically secure random or pseudo-random number generator MUST be used for the generation of the keying material and nonces, e.g., [BMGL]. However, which one to use is implementation specific (as the choice will not affect the interoperability).
暗号学的に安全なランダムまたは疑似乱数発生器は、[BMGL]、例えば、鍵材料の生成およびナンスに使用しなければなりません。しかし、そのいずれかを使用するには実装固有の（選択が相互運用性には影響しませんよう）です。
For the key derivations, it is MANDATORY to implement the PRF specified in Section 4.1. Other PRFs MAY be added by writing standard-track RFCs specifying the PRF constructions and their exact use within MIKEY.
キー導出のために、セクション4.1で指定されたPRFを実装するMANDATORYです。その他のPRFは、PRF構造とMIKEY内でのそれらの正確な使用を指定する標準トラックRFCを書き込むことによって追加される場合があります。
The default and mandatory-to-implement key transport encryption is AES in counter mode, as defined in [SRTP], using a 128-bit key as derived in Section 4.1.4, SRTP_PREFIX_LENGTH set to zero, and using the initialization vector
デフォルトと強制的に実装初期化ベクトルを使用して、セクション4.1.4に由来するようSRTP_PREFIX_LENGTHがゼロに設定され、128ビットの鍵を使用して、[SRTP]で定義され、そしてように、カウンタモードでAESある主要な輸送暗号化を
IV = (S XOR (0x0000 || CSB ID || T)) || 0x0000,
IV =（S XOR（0000 || CSB ID || T））|| 0000、
where S is a 112-bit salting key, also derived as in Section 4.1.4, and where T is the 64-bit timestamp sent by the Initiator.
Sはまた、セクション4.1.4のように誘導された112ビット塩析キーは、であり、そしてTは、イニシエータによって送信された64ビットのタイムスタンプがあります。
Note: this restricts the maximum size that can be encrypted to 2^23 bits, which is still enough for all practical purposes [SRTP].
注：これはまだ、すべての実用的な目的の[SRTP]のために十分である2 ^ 23ビットに暗号化することができる最大サイズを制限します。
The NULL encryption algorithm (i.e., no encryption) can be used (but implementation is OPTIONAL). Note that this MUST NOT be used unless the underlying protocols can guarantee security. The main reason for including this is for specific SIP scenarios, where SDP is protected end-to-end. For this scenario, MIKEY MAY be used with the pre-shared key method, the NULL encryption, and NULL authentication algorithm (see Section 4.2.4) while relying on the security of SIP. Use this option with caution!
NULL暗号化アルゴリズム（すなわち、暗号化なし）を使用することができる（ただし、実装はオプションです）。基本的なプロトコルは、セキュリティを保証することができない限り、これを使用してはいけないことに注意してください。これを含めた主な理由は、SDPは、エンドツーエンドの保護されている特定のSIPシナリオのためのものです。 SIPのセキュリティに依存しながら、このシナリオでは、MIKEY（セクション4.2.4を参照）事前共有鍵方式、NULL暗号化、およびNULL認証アルゴリズムと共に使用することができます。このオプションは注意して使用してください！
The AES key wrap function [AESKW] is included as an OPTIONAL implementation method. If the key wrap function is used in the public key method, the NULL MAC is RECOMMENDED to be used, as the key wrap itself will provide integrity of the encrypted content (note though that the NULL MAC SHOULD NOT be used in the pre-shared key case, as the MAC in that case covers the entire message). The 128- bit key and a 64-bit salt, S, are derived in accordance to Section 4.1.4 and the key wrap IV is then set to S.
AES鍵包み機能は[AESKW任意選択の実装方法として含まれます。キーラップ機能は、公開鍵方式で使用されている場合は、キーラップ自体はNULL MACは、事前共有で使用されるべきではないとかかわらず（注暗号化されたコンテンツの完全性を提供しますと、NULL MACは、使用することを推奨しますキーケース、その場合にMAC）がメッセージ全体を覆うように。 128ビットキーと64ビットの塩、S、セクション4.1.4に応じて誘導され、主要な包装IVは、次にSに設定されています
MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1 as the MANDATORY implementation method, see [HMAC]. Authentication keys are derived according to Section 4.1.4. Note that the authentication key size SHOULD be equal to the size of the hash function's output (e.g., for HMAC-SHA-1, a 160-bit authentication key is used) [HMAC].
MIKEYは必須実装方法としてSHA-1 HMACによって生成された160ビットの認証タグを使用して、[HMAC]を参照します。認証キーは、セクション4.1.4に従って導出されています。 [HMAC（例えば、HMAC-SHA-1のため、160ビットの認証キーが使用されている）、認証キーサイズは、ハッシュ関数の出力の大きさに等しくなければならないことに留意されたいです。
The NULL authentication algorithm (i.e., no MAC) can be used together with the NULL encryption algorithm (but implementation is OPTIONAL). Note that this MUST NOT be used unless the underlying protocols can guarantee security. The main reason for including this is for specific SIP scenarios, where SDP is protected end-to-end. For this scenario, MIKEY MAY be used with the pre-shared key method and the NULL encryption and authentication algorithm, while relying on the security of SIP. Use this option with caution!
NULL認証アルゴリズム（即ち、なしMAC）は、NULL暗号化アルゴリズムと一緒に使用することができる（ただし、実装はオプションです）。基本的なプロトコルは、セキュリティを保証することができない限り、これを使用してはいけないことに注意してください。これを含めた主な理由は、SDPは、エンドツーエンドの保護されている特定のSIPシナリオのためのものです。 SIPのセキュリティを頼りながら、このシナリオでは、MIKEYは、事前共有鍵方式とNULL暗号化と認証アルゴリズムで使用されるかもしれません。このオプションは注意して使用してください！
The public key encryption algorithm applied is defined by, and dependent on the certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it is RECOMMENDED to also support RSA OAEP [PSS].
適用される公開鍵暗号アルゴリズムは以下のように定義し、使用する証明書に依存しています。 RSA PKCS＃1、V1.5をサポートするために必須であり、また、RSA OAEP [PSS]をサポートすることをお勧めします。
The signature algorithm applied is defined by, and dependent on the certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it is RECOMMENDED to also support RSA PSS [PSS].
適用される署名アルゴリズムは、によって定義され、そして使用される証明書に依存しています。 RSA PKCS＃1、V1.5をサポートするために必須であり、また、RSA PSS [PSS]をサポートすることをお勧めします。
The Diffie-Hellman key exchange, when supported, uses OAKLEY 5 [OAKLEY] as a mandatory implementation. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are OPTIONAL implementations).
Diffie-Hellman鍵交換は、サポートされている場合、必須の実装としてOAKLEY 5 [OAKLEY]を使用します。 OAKLEY 1及びOAKLEY 2の両方を使用することができる（これらはOPTIONAL実装されています）。
See Section 4.2.9 for the guidelines on specifying a new DH Group to be used within MIKEY.
MIKEY内で使用する新しいDHグループを指定に関するガイドラインについては、セクション4.2.9を参照してください。
The timestamp is as defined in NTP [NTP], i.e., a 64-bit number in seconds relative to 0h on 1 January 1900. An implementation MUST be aware of (and take into account) the fact that the counter will overflow approximately every 136th year. It is RECOMMENDED that the time always be specified in UTC.
タイムスタンプは、NTP [NTP]で定義されるように、すなわち、1月1日1900年に実施を0hに比べ秒で64ビットの数が知っておく（と考慮に入れる）しなければならないカウンタは約すべての136番目をオーバーフローするという事実であります年。時間は常にUTCで指定することをお勧めします。
There are two different parameter sets that can be added to MIKEY. The first is a set of MIKEY transforms (needed for the exchange itself), and the second is the Data SAs.
MIKEYに追加することができる2つの異なるパラメータセットがあります。最初は（交換自体に必要）MIKEY変換の集合であり、2番目はデータSASです。
New transforms and parameters (including new policies) SHALL be added by registering with IANA (according to [RFC2434], see also Section 10) a new number for the concerned payload, and also if necessary, documenting how the new transform/parameter is used. Sometimes it might be enough to point to an already specified document for the usage, e.g., when adding a new, already standardized, hash function.
必要であれば（新しいポリシーを含む）新しい変換およびパラメータは、新しい変換/パラメーターが使用されている方法を文書化、またIANA（[RFC2434]によれば、また、セクション10を参照）と、当該ペイロードの新しい番号を登録することによって添加することSHALL 。新しい、すでに標準化され、ハッシュ関数を追加するとき時には例えば、使用するために、既に指定されたドキュメントを指すように十分かもしれません。
In the case of adding a new DH group, the group MUST be specified in a companion standards-track RFC (it is RECOMMENDED that the specified group use the same format as used in [OAKLEY]). A number can then be assigned by IANA for such a group to be used in MIKEY.
新しいDHグループを追加する場合には、グループはコンパニオン標準トラックRFCで指定する必要があり（それはで使用されるように指定されたグループは、同じ形式を使用することをお勧めします[OAKLEY]）。数はMIKEYで使用されるそのような基のためのIANAによって割り当てられることができます。
When adding support for a new data security protocol, the following MUST be specified:
新しいデータセキュリティプロトコルのサポートを追加すると、次のように指定する必要があります。
* A map sub-payload (see Section 6.1). This is used to be able to map a crypto session to the right instance of the data security protocol and possibly also to provide individual parameters for each data security protocol.
*マップのサブペイロード（6.1節を参照してください）。これは、データ・セキュリティ・プロトコルの正しいインスタンスを暗号化セッションをマッピングすると、おそらく、各データ・セキュリティ・プロトコルの個々のパラメータを提供することができるように使用されます。
* A policy payload, i.e., specification of parameters and supported values.
*ポリシー・ペイロード、すなわち、パラメータとサポートされる値の指定。
* General guidelines of usage.
*使い方の一般的なガイドライン。
Certificate handling may involve a number of additional tasks not shown here, and effect the inclusion of certain parts of the message (c.f. [X.509]). However, the following observations can be made:
証明書処理はここでは示されていない追加のタスクの数を含む、メッセージ（C.F. [X.509]）の特定の部分の包含をもたらすことができます。ただし、以下の観察を行うことができます。
* The Initiator typically has to find the certificate of the Responder in order to send the first message. If the Initiator does not already have the Responder's certificate, this may involve one or more roundtrips to a central directory agent.
*イニシエータは、通常、最初のメッセージを送信するために、レスポンダの証明書を見つける必要があります。イニシエータは、すでにレスポンダの証明書を持っていない場合、これは中央のディレクトリエージェントへの1回のまたは複数のラウンドトリップを含むことができます。
* It will be possible for the Initiator to omit its own certificate and rely on the Responder getting this certificate using other means. However, we only recommend doing this when it is reasonable to expect that the Responder has cached the certificate from a previous connection. Otherwise accessing the certificate would mean additional roundtrips for the Responder as well.
イニシエータが独自の証明書を省略し、Responderは、他の手段を使って、この証明書を取得するに頼るために*それは可能になります。 Responderが前回の接続から証明書をキャッシュしていることを期待するのは合理的であるしかし、我々はこれを行うことをお勧めします。それ以外の場合は、証明書にアクセスするだけでなくResponderのための追加のラウンドトリップを意味します。
* Verification of the certificates using Certificate Revocation Lists (CRLs) [X.509] or protocols such as OCSP [OCSP] may be necessary. All parties in a MIKEY exchange should have a local policy which dictates whether such checks are made, how they are made, and how often they are made. Note that performing the checks may imply additional messaging.
*証明書失効リストを使用して証明書の検証（CRL）の[X.509]又はOCSPなどのプロトコル[OCSP]が必要であってもよいです。 MIKEY交換のすべての当事者は、このようなチェックは、それらが作られ、どのように作られ、どのように頻繁にそれらが作られているかどうかを指示するローカルポリシーを持っている必要があります。チェックを実行すると、追加のメッセージングを暗示していることに注意してください。
In general, there are two different models for making authorization decisions for both the Initiator and the Responder, in the context of the applications targeted by MIKEY:
一般的には、MIKEYの対象となるアプリケーションのコンテキストでは、イニシエータとレスポンダの両方の認可決定を行うための2つの異なるモデルがあります。
* Specific peer-to-peer configuration. The user has configured the application to trust a specific peer.
*具体的なピア・ツー・ピアの設定。ユーザが特定のピアを信用するようにアプリケーションを設定しています。
When pre-shared secrets are used, this is pretty much the only available scheme. Typically, the configuration/entering of the pre-shared secret is taken to mean that authorization is implied.
事前共有秘密が使用される場合、これはかなりのみ利用スキームです。一般的に、事前共有秘密の設定/入力すると、その認証が暗示される意味するものと解釈されます。
In some cases, one could also use this with public keys, e.g., if two peers exchange keys offline and configure them to be used for the purpose of running MIKEY.
いくつかのケースでは、1にも2つのピア交換キーオフラインの場合は、例えば、公開鍵でこれを使用するとMIKEYを実行する目的で使用されるようにそれらを設定することができます。
* Trusted root. The user accepts all peers that prove to have a certificate issued by a specific CA. The granularity of authorization decisions is not very precise in this method.
*信頼されたルート。ユーザは、特定のCAによって発行された証明書を持っていると証明するすべてのピアを受け入れます認可決定の粒度は、この方法では非常に正確ではありません。
In order to make this method possible, all participants in the MIKEY protocol need to configure one or more trusted roots. The participants also need to be capable of performing certificate chain validation, and possibly transfer more than a single certificate in the MIKEY messages (see also Section 6.7).
この方法を可能にするためには、MIKEYプロトコルのすべての参加者は、一つ以上の信頼できるルートを設定する必要があります。参加者は、証明書チェーンの検証を行うことが可能であり、そしておそらくMIKEYメッセージ（セクション6.7も参照）における単一の証明書よりも転送する必要があります。
In practice, a combination of both mentioned methods might be advantageous. Also, the possibility for a user to explicitly exclude a specific peer (or sub-tree) in a trust chain might be needed.
実際には、両方の上述の方法の組み合わせが有利かもしれません。また、明示的に信頼チェーン内の特定のピア（またはサブツリー）を除外するためのユーザーのための可能性が必要になることがあります。
These authorization policies address the MIKEY scenarios a-c of Section 2.1, where the Initiator acts as the group owner and is also the only one that can invite others. This implies that for each Responder, the distributed keys MUST NOT be re-distributed to other parties.
これらの認可ポリシーは、MIKEYシナリオイニシエータは、グループの所有者として機能し、また他の人を招待することができます唯一のものであるセクション2.1、の-Cに取り組みます。これは、各レスポンダのために、分散キーは他の当事者に再分散してはならないことを意味します。
In a many-to-many situation, where the group control functions are distributed (and/or where it is possible to delegate the group control function to others), a means of distributing authorization information about who may be added to the group MUST exist. However, it is out of scope of this document to specify how this should be done.
グループ制御機能が分散されている多対多の状況、（および/または他の人にグループ制御機能を委任することが可能である場合）において、グループに追加されてもよい者に関する認証情報を配信する手段が存在しなければなりません。しかし、これは行われるべき方法を指定するには、この文書の範囲外です。
For any broader communication situation, an external authorization infrastructure may be used (following the assumptions of [GKMARCH]).
任意広い通信状況のために、外部許可インフラストラクチャは、（[GKMARCH]の仮定以下）を使用することができます。
Included in the message exchange, policies (i.e., security parameters) for the Data security protocol are transmitted. The policies are defined in a separate payload and are specific to the security protocol (see also Section 6.10). Together with the keys, the validity period of these can also be specified. For example, this can be done with an SPI (or SRTP MKI) or with an Interval (e.g., a sequence number interval for SRTP), depending on the security protocol.
メッセージ交換に含まれ、データセキュリティプロトコルのポリシー（すなわち、セキュリティパラメータ）が送信されます。ポリシーは別々のペイロードで定義されたセキュリティプロトコルに特定されている（また、セクション6.10を参照）。一緒にキーを使用して、これらの有効期間を指定することもできます。例えば、これは、SPI（またはSRTP MKI）または間隔で行うことができる（例えば、SRTPのシーケンス番号間隔）、セキュリティプロトコルに応じ。
New parameters can be added to a policy by documenting how they should be interpreted by MIKEY and by also registering new values in the appropriate name space in IANA. If a completely new policy is needed, see Section 4.2.9 for guidelines.
新しいパラメータは、彼らがMIKEYでもIANAに適切な名前空間に新しい値を登録することによって解釈されるべきである方法を文書化して、ポリシーに追加することができます。全く新しいポリシーが必要な場合は、ガイドラインについては、セクション4.2.9を参照してください。
The retrieval of a Data SA will depend on the security protocol, as different security protocols will have different characteristics. When adding support for a security protocol to MIKEY, some interface of how the security protocol retrieves the Data SA from MIKEY MUST be specified (together with policies that can be negotiated).
異なるセキュリティプロトコルが異なる特性を有することになるようにデータSAの検索は、セキュリティプロトコルに依存するであろう。 MIKEYのセキュリティプロトコルのサポートを追加する場合、セキュリティプロトコルは、MIKEYからデータSAを取得する方法のいくつかのインタフェースは、（一緒にネゴシエートすることができるポリシーに）指定されなければなりません。
For SRTP, the SSRC (see [SRTP]) is one of the parameters used to retrieve the Data SA (while the MKI may be used to indicate the TGK/TEK used for the Data SA). However, the SSRC is not sufficient. For the retrieval of the Data SA from MIKEY, it is RECOMMENDED that the MIKEY implementation support a lookup using destination network address and port together with SSRC. Note that MIKEY does not send network addresses or ports. One reason for this is that they may not be known in advance. Also, if a NAT exists in-between, problems may arise. When SIP or RTSP is used, the local view of the destination address and port can be obtained from either SIP or RTSP. MIKEY can then use these addresses as the index for the Data SA lookup.
SRTPのために、SSRCは、（[SRTP]を参照）（MKIがデータSAに使用TGK / TEKを示すために使用されてもよい）データSAを取得するために使用されるパラメータの一つです。しかし、SSRCは十分ではありません。 MIKEYからデータSAの検索のためには、MIKEY実装がSSRCと共に宛先ネットワークアドレスとポートを使用してルックアップをサポートすることが推奨されます。 MIKEYは、ネットワークアドレスやポートを送信しないことに注意してください。この理由の一つは、彼らが事前に知られていないことです。 NATが存在する場合にも、インの間、問題が発生する可能性があります。 SIPまたはRTSPを使用した場合、宛先アドレスおよびポートのローカルビューは、SIPまたはRTSPのいずれかから得ることができます。 MIKEYは、[データSA検索用のインデックスとしてこれらのアドレスを使用することができます。
MIKEY provides a means of updating the CSB (e.g., transporting a new TGK/TEK or adding a new Crypto Session to the CSB). The updating of the CSB is done by executing MIKEY again, for example, before a TEK expires, or when a new Crypto Session is added to the CSB. Note that MIKEY does not provide re-keying in the GKMARCH sense, only updating of the keys by normal unicast messages.
MIKEY（例えば、新しいTGK / TEKを輸送またはCSBに新たな暗号化セッションを追加）CSBを更新する手段を提供します。 TEKの有効期限が切れる前に、CSBの更新は、例えば、再びMIKEYを実行することによって行われているか、または新しい暗号化セッションをCSBに追加されたとき。 MIKEYのみ、通常のユニキャストメッセージによってキーの更新、GKMARCHの意味での再入力を提供しないことに注意してください。
When MIKEY is executed again to update the CSB, it is not necessary to include certificates and other information that was provided in the first exchange, for example, all payloads that are static or optionally included may be left out (see Figure 4.1).
MIKEYはCSBを更新するために、再度実行されると、証明書と第一交換に設けられた他の情報を含む必要はないが、例えば、静的または任意に含まれるすべてのペイロードは、（図4.1を参照）は除外されてもよいです。
The new message exchange MUST use the same CSB ID as the initial exchange, but MUST use a new timestamp. A new RAND MUST NOT be included in the message exchange (the RAND will only have effect in the Initial exchange). If desired, new Crypto Sessions are added in the update message. Note that a MIKEY update message does not need to contain new keying material (e.g., new TGK). In this case, the crypto session continues to use the previously established keying material, while updating the new information.
新しいメッセージ交換は、初期の交換と同じCSB IDを使用しなければならないが、新しいタイムスタンプを使用しなければなりません。新しいRANDは（RANDのみ初期交換で効果があります）メッセージ交換に含んではいけません。必要に応じて、新しい暗号化セッションが更新メッセージに追加されます。 MIKEY更新メッセージは、新たな鍵材料（例えば、新しいTGK）を含有する必要はないことに留意されたいです。この場合、暗号化セッションは、新しい情報を更新しながら、以前に確立された鍵素材を使用し続けます。
As explained in Section 3.2, the envelope key can be "cached" as a pre-shared key (this is indicated by the Initiator in the first message sent). If so, the update message is a pre-shared key message with the cached envelope key as the pre-shared key; it MUST NOT be a public key message. If the public key message is used, but the envelope key is not cached, the Initiator MUST provide a new encrypted envelope key that can be used in the verification message. However, the Initiator does not need to provide any other keys.
セクション3.2で説明したように、エンベロープ鍵（これは送信された最初のメッセージのイニシエータにより示される）事前共有キーとして「キャッシュ」することができます。その場合は、更新メッセージは、事前共有キーとしてキャッシュされたエンベロープキーで事前共有キーメッセージです。それは、公開キーメッセージにすることはできません。公開鍵のメッセージが使用されますが、エンベロープキーがキャッシュされていない場合、イニシエータは、確認メッセージで使用することができ、新たな暗号化されたエンベロープキーを提供しなければなりません。しかし、イニシエータは、他のキーを提供する必要はありません。
Figure 4.1 visualizes the update messages that can be sent, including the optional parts. The main difference from the original message is that it is optional to include TGKs (or DH values in the DH method). Also see Section 3 for more details on the specific methods.
図4.1は、オプションの部品を含む送信できる更新メッセージを、可視化します。元のメッセージからの主な違いは、（DH法またはDH値）TGKsを含むように任意であることです。また、特定のメソッドの詳細については、セクション3を参照してください。
By definition, a CSB can contain several CSs. A problem that then might occur is to synchronize the TGK re-keying if an SPI (or similar functionality, e.g., MKI in [SRTP]) is not used. It is therefore RECOMMENDED that an SPI or MKI be used, if more than one CS is present.
定義では、CSBには、いくつかのCSを含めることができます。次に発生する可能性のある問題はSPI場合TGK再キーイングを同期させることである（または類似の機能、例えば、[SRTP]でMKI）が使用されていません。複数のCSが存在する場合したがって、SPIまたはMKIを使用することを推奨されています。
Initiator Responder
イニシエータレスポンダ
Pre-shared key method:
事前共有鍵方式：
I_MESSAGE =
HDR, T, [IDi], [IDr], {SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
Public key method:
公開鍵方式：
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr], {SP},
[KEMAC], [CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
DH method:
DH方法：
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr], {SP},
[DHi], SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi,
[DHr, DHi], SIGNr
Figure 4.1: Update messages.
更新メッセージ：図4.1。
Note that for the DH method, if the Initiator includes the DHi payload, then the Responder MUST include DHr and DHi. If the Initiator does not include DHi, the Responder MUST NOT include DHr or DHi.
イニシエータは、DHIペイロードを含む場合DH法のために、次いでレスポンダはDHR及びDHIを含まなければならないことに留意されたいです。イニシエータはDHIが含まれていない場合は、ResponderはDHRまたはDHIを含んではいけません。
Each message that is sent by the Initiator or the Responder is built by a set of payloads. This section describes how messages are created and also when they can be used.
イニシエータまたはレスポンダによって送信される各メッセージは、ペイロードのセットによって構築されます。このセクションでは、メッセージが作成され、また、それらを使用することができたときにどのように説明しています。
The Initiator indicates the security policy to be used (i.e., in terms of security protocol algorithms). If the Responder does not support it (for some reason), the Responder can together with an error message (indicating that it does not support the parameters), send back its own capabilities (negotiation) to let the Initiator choose a common set of parameters. This is done by including one or more security policy payloads in the error message sent in response (see Section 5.1.2.). Multiple attributes can be provided in sequence in the response. This is done to reduce the number of roundtrips as much as possible (i.e., in most cases, where the policy is accepted the first time, one roundtrip is enough). If the Responder does not accept the offer, the Initiator must go out with a new MIKEY message.
開始剤（すなわち、セキュリティプロトコルのアルゴリズムの観点で）使用されるセキュリティポリシーを示しています。 Responderが（何らかの理由で）それをサポートしていない場合は、Responderは一緒に（それがパラメータをサポートしていないことを示す）エラーメッセージを表示して、イニシエータは、パラメータの共通セットを選択できるように、自身の能力（交渉を）戻って送信することができます。これは、応答で送信されたエラーメッセージの1つまたは複数のセキュリティポリシーのペイロードを含むことによって行われます（5.1.2項を参照してください。）。複数の属性は、応答のシーケンスで提供することができます。これは、（すなわち、ポリシーが最初に認められている多くの場合において、1回の往復で十分である）できるだけラウンドトリップの数を減らすために行われます。 Responderが申し出を受け入れない場合、イニシエータは新しいマイキーメッセージと一緒に外出しなければなりません。
If the Responder is not willing/capable of providing security or the parties simply cannot agree, it is up to the parties' policies how to behave, for example, accepting or rejecting an insecure communication.
Responderがセキュリティを提供するか、当事者が単に同意することはできませんすること/望んでいない場合、それは安全でない通信を受け入れるか拒否、例えば、動作するようにどのように当事者の方針次第です。
Note that it is not the intention of this protocol to have a broad variety of options, as it is assumed that a denied offer should rarely occur.
拒否されたオファーはめったに発生しない必要があることを想定しているとして、オプションの幅広い多様性を持っているために、このプロトコルの意図はないことに注意してください。
In the one-to-many and many-to-many scenarios using multicast communication, one issue is of course that there MUST be a common security policy for all the receivers. This limits the possibility of negotiation.
マルチキャスト通信を使用して1対多および多対多のシナリオでは、1つの問題は、すべての受信機のための共通のセキュリティポリシーが存在しなければならないことはもちろんです。これは、交渉の可能性を制限します。
Due to the key management protocol, all errors SHOULD be reported to the peer(s) by an error message. The Initiator SHOULD therefore always be prepared to receive such a message from the Responder.
鍵管理プロトコルに、すべてのエラーは、エラーメッセージによってピア（複数可）に報告してください。開始剤は、したがって、常にレスポンダからそのようなメッセージを受信するように準備されるべきです。
If the Responder does not support the set of parameters suggested by the Initiator, the error message SHOULD include the supported parameters (see also Section 5.1.1).
レスポンダがイニシエータによって提案されたパラメータのセットをサポートしていない場合、エラーメッセージがサポートされるパラメータを（セクション5.1.1を参照）を含むべきです。
The error message is formed as:
エラーメッセージは次のように形成されています。
HDR, T, {ERR}, {SP}, [V|SIGNr]
HDR、T、{ERR}、{SP}、[V | SIGNR]
Note that if failure is due to the inability to authenticate the peer, the error message is OPTIONAL, and does not need to be authenticated. It is up to local policy to determine how to treat this kind of message. However, if in response to a failed authentication a signed error message is returned, this can be used for DoS purposes (against the Responder). Similarly, an unauthenticated error message could be sent to the Initiator in order to fool the Initiator into tearing down the CSB. It is highly RECOMMENDED that the local policy take this into consideration. Therefore, in case of authentication failure, one recommendation would be not to authenticate such an error message, and when receiving an unauthenticated error message view it only as a recommendation of what may have gone wrong.
障害がピアを認証できないことが原因である場合、エラーメッセージは任意であり、かつ、認証する必要がないことに注意してください。これは、この種のメッセージを処理する方法を決定するために、ローカルポリシー次第です。失敗した認証に応答して署名されたエラーメッセージが返された場合は、これは（レスポンダに対して）DoS攻撃の目的で使用することができます。同様に、認証されていないエラーメッセージがCSBを切断にイニシエータを欺くために、イニシエータに送信することができます。ローカルポリシーは、このことを考慮することを強くお勧めします。そのため、認証失敗の場合には、1つの勧告は、このようなエラーメッセージを認証しないだろう、と認証されていないエラーメッセージを受信した場合にのみ、間違っているかもしれないものの勧告として、それを表示します。
To create a MIKEY message, a Common Header payload is first created. This payload is then followed, depending on the message type, by a set of information payloads (e.g., DH-value payload, Signature payload, Security Policy payload). The defined payloads and the exact encoding of each payload are described in Section 6.
マイキーメッセージを作成するには、共通ヘッダのペイロードが最初に作成されます。このペイロードは、情報ペイロードのセット（例えば、DH-値ペイロード、署名ペイロード、セキュリティポリシーペイロード）により、メッセージの種類に応じて、続いています。定義されたペイロードと、各ペイロードの正確な符号化は、第6章に記載されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +
~ Common Header... ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload 1 ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload x ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MAC/Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.1. MIKEY payload message example. Note that the payloads are byte aligned and not 32-bit aligned.
図5.1。 MIKEYペイロードメッセージ例。ペイロードはバイト整列していない32ビットの整列されていることに注意してください。
The process of generating a MIKEY message consists of the following steps:
MIKEYメッセージを生成するプロセスは、以下のステップから成ります。
* Create an initial MIKEY message starting with the Common Header payload.
*共通ヘッダのペイロードから始まる最初のマイキーメッセージを作成します。
* Concatenate necessary payloads of the MIKEY message (see the exchange definitions for payloads that may be included, and the recommended order).
* MIKEYメッセージ（含まれていてもよいペイロードのための交換の定義を参照して、推奨順序）の必要なペイロードを連結。
* As a last step (for messages that must be authenticated, this also includes the verification message), create and concatenate the MAC/signature payload without the MAC/signature field filled in (if a Next payload field is included in this payload, it is set to Last payload).
*最後のステップとして、（認証されなければならないメッセージのために、これはまた、検証メッセージを含む）、次にペイロードフィールドは、このペイロードに含まれている場合（に充填されたMAC /署名フィールドなしMAC /署名ペイロードを作成して連結し、それ）最終ペイロードに設定されています。
* Calculate the MAC/signature over the entire MIKEY message, except the MAC/Signature field, and add the MAC/signature in the field. In the case of the verification message, the Identity_i || Identity_r || Timestamp MUST directly follow the MIKEY message in the Verification MAC calculation. Note that the added identities and timestamp are identical to those transported in the ID and T payloads.
*は、MAC /署名フィールドを除いて、MAC /全体MIKEYメッセージ上の署名を計算し、そしてフィールドでMAC /署名を追加します。確認メッセージ、Identity_iの場合|| Identity_r ||タイムスタンプは、直接検証MAC計算にMIKEYメッセージに従わなければなりません。加えアイデンティティとタイムスタンプがIDとTペイロードに搬送されたものと同一であることに留意されたいです。
In the public key case, the Key data transport payload is generated by concatenating the IDi with the TGKs. This is then encrypted and placed in the data field. The MAC is calculated over the entire Key data transport payload except the MAC field. Before calculating the MAC, the Next payload field is set to zero.
公開鍵の場合、鍵データトランスポート・ペイロードはTGKsとIDiとを連結することによって生成されます。そして、これは暗号化され、データフィールドに置かれています。 MACはMACフィールドを除いて全体キーデータトランスポートペイロードに対して計算されます。 MACを計算する前に、次のペイロードフィールドはゼロに設定されています。
Note that all messages from the Initiator MUST use a unique timestamp. The Responder does not create a new timestamp, but uses the timestamp used by the Initiator.
イニシエータからのすべてのメッセージは、ユニークなタイムスタンプを使用しなければならないことに注意してください。 Responderは新しいタイムスタンプを作成しますが、イニシエータによって使用されるタイムスタンプを使用していません。
In general, parsing of a MIKEY message is done by extracting payload by payload and checking that no errors occur. The exact procedure is implementation specific; however, for the Responder, it is RECOMMENDED that the following procedure be followed:
一般に、MIKEYメッセージの構文解析は、ペイロードによってペイロードを抽出し、エラーが発生しないことを確認することによって行われます。正確な手順は、実装固有です。しかし、レスポンダのために、次の手順に従うことをお勧めします。
* Extract the Timestamp and check that it is within the allowable clock skew (if not, discard the message). Also check the replay cache (Section 5.4) so that the message is not replayed (see Section 5.4). If the message is replayed, discard it.
*タイムスタンプを抽出し、それが（そうでない場合は、メッセージを破棄）許容クロック・スキューの範囲内であることを確認してください。また、リプレイ・キャッシュ（5.4節）メッセージが再生されないように（5.4節を参照）を確認してください。メッセージが再生される場合は、それを捨てます。
* Extract the ID and authentication algorithm (if not included, assume the default).
*（含まれていない場合は、デフォルトを想定）IDおよび認証アルゴリズムを抽出します。
* Verify the MAC/signature.
* MAC /署名を確認してください。
* If the authentication is not successful, an Auth failure Error message MAY be sent to the Initiator. The message is then discarded from further processing. See also Section 5.1.2 for treatment of errors.
認証が成功しなかった場合*、認証失敗のエラーメッセージは、イニシエータに送ってもよいです。メッセージは、その後、さらなる処理から破棄されます。また、エラーの治療のために、セクション5.1.2を参照してください。
* If the authentication is successful, the message is processed and also added to the replay cache; processing is implementation specific. Note also that only successfully authenticated messages are stored in the replay cache.
認証が成功した場合*、メッセージが処理され、また、リプレイキャッシュに追加されます。処理は実装固有のものです。注意は、その唯一の認証に成功したメッセージは、リプレイ・キャッシュに格納されています。
* If any unsupported parameters or errors occur during the processing, these MAY be reported to the Initiator by sending an error message. The processing is then aborted. The error message can also include payloads to describe the supported parameters.
サポートされていないパラメータまたは処理中にエラーが発生した場合*、これらはエラーメッセージを送信することにより、イニシエータに報告することができます。そして、処理は中止されます。エラーメッセージもサポートされるパラメータを記述するためにペイロードを含めることができます。
* If the processing was successful and in case the Initiator requested it, a verification/response message MAY be created and sent to the Initiator.
処理が成功したと場合にイニシエータがそれを要求した場合*、検証/応答メッセージを作成し、イニシエータに送ってもよいです。
MIKEY does not use a challenge-response mechanism for replay handling; instead, timestamps are used. This requires that the clocks are synchronized. The required synchronization is dependent on the number of messages that can be cached (note though, that the replay cache only contains messages that have been successfully authenticated). If we could assume an unlimited cache, the terminals would not need to be synchronized at all (as the cache could then contain all previous messages). However, if there are restrictions on the size of the replay cache, the clocks will need to be synchronized to some extent. In short, one can in general say that it is a tradeoff between the size of the replay cache and the required synchronization.
MIKEYは、再生処理のためのチャレンジ・レスポンスメカニズムを使用していません。その代わり、タイムスタンプが使用されています。これは、クロックが同期していることが必要です。必要な同期をキャッシュすることができるメッセージの数に依存している（リプレイキャッシュのみ正常に認証されたメッセージが含まれていること、しかし注意してください）。我々は無制限のキャッシュを仮定することができれば（キャッシュは、すべての以前のメッセージが含まれている可能性があるので）、端末は全てで同期する必要はありません。ただし、リプレイ・キャッシュのサイズに制限がある場合に、クロックがある程度に同期する必要があります。要するに、一般的には1缶は、それがリプレイ・キャッシュのサイズと必要な同期との間のトレードオフであることを言います。
Timestamp usage prevents replay attacks under the following assumptions:
タイムスタンプの使用量は、以下の仮定の下でリプレイ攻撃を防ぎます。
* Each host has a clock which is at least "loosely synchronized" with the clocks of the other hosts.
*各ホストは、少なくとも他のホストのクロックに「緩く同期」されたクロックを有しています。
* If the clocks are to be synchronized over the network, a secure network clock synchronization protocol SHOULD be used, e.g., [ISO3].
*クロックは、ネットワーク上で同期させる場合には、安全なネットワーククロック同期プロトコルは、例えば、使用されるべきであり、[ISO3]。
* Each Responder utilizes a replay cache in order to remember the successfully authenticated messages presented within an allowable clock skew (which is set by the local policy).
*各Responderは（ローカルポリシーで設定されている）許容クロック・スキューの中に提示正常に認証メッセージを覚えておくために、リプレイのキャッシュを利用しています。
* Replayed and outdated messages, for example, messages that can be found in the replay cache or which have an outdated timestamp are discarded and not processed.
*リプレイや時代遅れのメッセージは、例えば、時代遅れのタイムスタンプを持つリプレイ・キャッシュ内で見つけることができるメッセージやは破棄され、処理されません。
* If the host loses track of the incoming requests (e.g., due to overload), it rejects all incoming requests until the clock skew interval has passed.
ホストが着信要求（例えば、過負荷による）のトラックを失った場合、クロック・スキュー間隔が経過するまで*、それはすべての着信要求を拒否します。
In a client-server scenario, servers may encounter a high workload, especially if a replay cache is necessary. However, servers that assume the role of MIKEY Initiators will not need to manage any significant replay cache as they will refuse all incoming messages that are not a response to a message previously sent by the server.
クライアント・サーバ・シナリオでは、サーバーは、リプレイキャッシュが必要な場合は特に、高い作業負荷が発生することがあります。彼らは以前にサーバによって送信されたメッセージへの応答ではありませんすべての受信メッセージを拒否しますしかし、MIKEYイニシエータの役割を担うサーバーでは、有意なリプレイのキャッシュを管理する必要はありません。
In general, a client may not expect a very high load of incoming messages and may therefore allow the degree of looseness to be on the order of several minutes to hours. If a (D)DoS attack is launched and the replay cache grows too large, MIKEY MAY dynamically decrease the looseness so that the replay cache becomes manageable. However, note that such (D)DoS attacks can only be performed by peers that can authenticate themselves. Hence, such an attack is very easy to trace and mitigate.
一般的には、クライアントは、受信メッセージの非常に高い負荷を期待していない可能性があるため、緩みの程度は時間に数分のオーダーであることを可能にします。 （D）DoS攻撃が起動し、再実行キャッシュが大きくなりすぎている場合は、リプレイキャッシュが管理可能になるように、MIKEYは、動的に緩みが低下することがあります。しかし、そのような（D）DoS攻撃は、自分自身だけを認証することができるピアによって行うことができることに注意してください。したがって、このような攻撃は、追跡して軽減することは非常に簡単です。
The maximum number of messages that a client will need to cache may vary depending on the capacity of the client itself and the network. The number of expected messages should be taken into account.
クライアントがキャッシュする必要がありますメッセージの最大数は、クライアント自体の容量やネットワークによって異なります。予想されるメッセージの数を考慮に入れるべきです。
For example, assume that we can at most spend 6kB on a replay cache. Assume further that we need to store 30 bytes for each incoming authenticated message (the hash of the message is 20 bytes). This implies that it is possible to cache approximately 204 messages. If the expected number of messages per minute can be estimated, the clock skew can easily be calculated. For example, in a SIP scenario where the client is expected, in the most extreme case, to receive 10 calls per minute, the clock skew needed is then approximately 20 minutes. In a not so extreme setting, where one could expect an incoming call every 5th minute, this would result in a clock skew on the order of 16.5 hours (approx 1000 minutes).
たとえば、私たちはほとんどのリプレイキャッシュに6KBを過ごすことができていることを前提としています。我々は、各着信認証メッセージ（メッセージのハッシュは20バイト）、30のバイトを格納する必要があると仮定する。約204のメッセージをキャッシュすることが可能であることを意味します。分あたりのメッセージ数の期待値を推定することができる場合は、クロック・スキューを容易に算出することができます。例えば、クライアントが期待されているSIPのシナリオでは、最も極端な場合には、毎分10回のコールを受信するために、必要なクロック・スキューは、その後、約20分です。 1は、着信コールごとに5日分を期待できるので、極端ではない設定では、これは16.5時間（約1000年分）の順にクロック・スキューにつながります。
Consider a very extreme case, where the maximum number of incoming messages are assumed to be on the order of 120 messages per minute, and a requirement that the clock skew is on the order of 10 minutes, a 48kB replay cache would be required.
着信メッセージの最大数が毎分120のメッセージのオーダーであると仮定されている非常に極端な場合、およびクロック・スキューは10分程度であるの要件を考慮し、48KB再生キャッシュが必要となります。
Hence, one can note that the required clock skew will depend largely on the setting in which MIKEY is used. One recommendation is to fix a size for the replay cache, allowing the clock skew to be large (the initial clock skew can be set depending on the application in which it is used). As the replay cache grows, the clock skew is decreased depending on the percentage of the used replay cache. Note that this is locally handled, which will not require interaction with the peer (even though it may indirectly effect the peer). However, exactly how to implement such functionality is out of the scope of this document and considered implementation specific.
したがって、一つは必要なクロック・スキューはMIKEYが使用されている設定に大きく依存することに注意することができます。一の推奨は、（最初のクロック・スキューは、それが使用される用途に応じて設定することができる）クロックスキューが大きいできるように、リプレイ・キャッシュのサイズを固定することです。リプレイキャッシュが大きくなるにつれて、クロック・スキューを使用リプレイキャッシュの割合に応じて減少しています。 （それが間接的ピアを行う場合でも）ピアとの相互作用を必要としないであろう、これは局所的に処理されることに留意されたいです。しかし、正確にどのような機能この文書の範囲外であると考えられ、実装の特定を実装します。
In case of a DoS attack, the client will most likely be able to handle the replay cache. A more likely (and serious) DoS attack is a CPU DoS attack where the attacker sends messages to the peer, which then needs to expend resources on verifying the MACs/signatures of the incoming messages.
DoS攻撃の場合、クライアントは、最も可能性が高いリプレイキャッシュを扱うことができるようになります。より多くの可能性（深刻な）DoS攻撃は、攻撃者は、その後、受信メッセージのMACアドレス/署名を検証上のリソースを消費する必要があるピアにメッセージを送るCPU DoS攻撃です。
This section describes, in detail, all the payloads. For all encoding, network byte order is always used. While defining supported types (e.g., which hash functions are supported) the mandatory-to-implement types are indicated (as Mandatory), as well as the default types (note, default also implies mandatory implementation). Support for the other types are implicitly assumed to be optional.
このセクションでは、具体的に、すべてのペイロードを説明しています。すべてのエンコーディングのために、ネットワークバイト順が常に使用されます。 （ハッシュ関数がサポートされ、例えば、）サポートされるタイプを定義しながら、強制的に実装タイプが示されている（必須など）、ならびにデフォルトタイプ（ノートは、デフォルトでも必須の実装を意味します）。他のタイプのサポートは、暗黙のうちに、オプションであると想定されています。
In the following, note that the support for SRTP [SRTP] as a security protocol is defined. This will help us better understand the purpose of the different payloads and fields. Other security protocols MAY be specified for use within MIKEY, see Section 10.
以下に、セキュリティプロトコルとしてSRTP [SRTP]のサポートが定義されていることに注意してください。これは、私たちはより良い別のペイロードとフィールドの目的を理解するのに役立ちます。他のセキュリティプロトコルは、第10章を参照してください、MIKEY内で使用するために指定することができます。
In the following, the sign ~ indicates variable length field.
以下では、記号〜は、可変長フィールドを示します。
The Common Header payload MUST always be present as the first payload in each message. The Common Header includes a general description of the exchange message.
共通ヘッダのペイロードは、常に、各メッセージの最初のペイロードとして存在していなければなりません。共通ヘッダは、交換メッセージの一般的な説明を含みます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload !V! PRF func !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CSB ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! #CS ! CS ID map type! CS ID map info ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* version (8 bits): the version number of MIKEY.
*バージョン（8ビット）：MIKEYのバージョン番号。
version = 0x01 refers to MIKEY as defined in this document.
バージョン= 0x01のこの文書で定義されているMIKEYを指します。
* data type (8 bits): describes the type of message (e.g., public-key transport message, verification message, error message).
*データ型（8ビット）：メッセージのタイプ（例えば、公開鍵トランスポート・メッセージ、確認メッセージ、エラーメッセージ）を記載しています。
Data type | Value | Comment
--------------------------------------
Pre-shared | 0 | Initiator's pre-shared key message
PSK ver msg | 1 | Verification message of a Pre-shared
| | key message
Public key | 2 | Initiator's public-key transport message
PK ver msg | 3 | Verification message of a public-key
| | message
D-H init | 4 | Initiator's DH exchange message
D-H resp | 5 | Responder's DH exchange message
Error | 6 | Error message
Table 6.1.a
表6.1.a
* next payload (8 bits): identifies the payload that is added after this payload.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。
Next payload | Value | Section
------------------------------
Last payload | 0 | -
KEMAC | 1 | 6.2
PKE | 2 | 6.3
DH | 3 | 6.4
SIGN | 4 | 6.5
T | 5 | 6.6
ID | 6 | 6.7
CERT | 7 | 6.7
CHASH | 8 | 6.8
V | 9 | 6.9
SP | 10 | 6.10
RAND | 11 | 6.11
ERR | 12 | 6.12
Key data | 20 | 6.13
General Ext. | 21 | 6.15
Table 6.1.b
テーブル6.1.b
Note that some of the payloads cannot directly follow the header (such as "Last payload", "Signature"). However, the Next payload field is generic for all payloads. Therefore, a value is allocated for each payload. The Next payload field is set to zero (Last payload) if the current payload is the last payload.
ペイロードの一部は、直接（例えば、「最後のペイロード」、「署名」のような）ヘッダに追従できないことに留意されたいです。ただし、次のペイロードフィールドは、すべてのペイロードのための一般的です。したがって、値は、各ペイロードに割り当てられます。現在のペイロードが最後のペイロードである場合には次のペイロードフィールドはゼロ（最終ペイロード）に設定されています。
* V (1 bit): flag to indicate whether a verification message is expected or not (this only has meaning when it is set by the Initiator). The V flag SHALL be ignored by the receiver in the DH method (as the response is MANDATORY).
* V（1ビット）：確認メッセージが期待されているかどうかを示すフラグまたはしない（それがイニシエータによって設定されている場合にのみ意味を持ちます）。 （応答が必須であるように）Vフラグは、DH法に受信機によって無視されます。
V = 0 ==> no response expected V = 1 ==> response expected
V = 0 ==>無応答期待V = 1 ==>応答期待
* PRF func (7 bits): indicates the PRF function that has been/will be used for key derivation.
* PRFのFUNC（7ビット）：/鍵導出のために使用されてきたPRF関数を示しています。
PRF func | Value | Comments
--------------------------------------------------------
MIKEY-1 | 0 | Mandatory (see Section 4.1.2)
Table 6.1.c
テーブル6.1.c
* CSB ID (32 bits): identifies the CSB. It is RECOMMENDED that the CSB ID be chosen at random by the Initiator. This ID MUST be unique between each Initiator-Responder pair, i.e., not globally unique. An Initiator MUST check for collisions when choosing the ID (if the Initiator already has one or more established CSBs with the Responder). The Responder uses the same CSB ID in the response.
* CSB ID（32ビット）：CSBを識別する。 CSB IDはイニシエータによってランダムに選択することを推奨します。このIDは、グローバルに一意でない、すなわち、各イニシエータレスポンダペア間で一意でなければなりません。 （イニシエータが既にレスポンダを有する1つまたは複数の確立のCSBを持っている場合）のIDを選択する際イニシエータは、衝突のためにチェックしなければなりません。 Responderは対応して同じCSB IDを使用しています。
* #CS (8 bits): indicates the number of Crypto Sessions that will be handled within the CBS. Note that even though it is possible to use 255 CSs, it is not likely that a CSB will include this many CSs. The integer 0 is interpreted as no CS included. This may be the case in an initial setup message.
* #CS（8ビット）：CBS内で処理される暗号化セッションの数を示します。それは255件のCSを使用することが可能であっても、CSBは、この多くのCSが含まれる可能性が高いではないことに注意してください。何CSが含まれないように整数0が解釈されます。これは、初期設定のメッセージでケースかもしれません。
* CS ID map type (8 bits): specifies the method of uniquely mapping Crypto Sessions to the security protocol sessions.
* CS IDマップタイプ（8ビット）：一意のセキュリティプロトコルセッションに暗号化セッションをマッピングする方法を指定します。
CS ID map type | Value
-----------------------
SRTP-ID | 0
Table 6.1.d
表6.1.d
* CS ID map info (16 bits): identifies the crypto session(s) for which the SA should be created. The currently defined map type is the SRTP-ID (defined in Section 6.1.1).
* CS IDマップ情報（16ビット）：SAを作成する必要のある暗号化セッション（複数可）を識別する。現在定義されているマップタイプは、SRTP-ID（セクション6.1.1で定義される）です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_1 ! SSRC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_1 (cont) ! ROC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_1 (cont) ! Policy_no_2 ! SSRC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_2 (cont) ! ROC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_2 (cont) ! :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_#CS ! SSRC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!SSRC_#CS (cont)! ROC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_#CS (cont)!
+-+-+-+-+-+-+-+-+
* Policy_no_i (8 bits): The security policy applied for the stream with SSRC_i. The same security policy may apply for all CSs.
* Policy_no_i（8ビット）：SSRC_i有するストリームに適用されるセキュリティポリシー。同じセキュリティポリシーは、すべてのCSSを申請することができます。
* SSRC_i (32 bits): specifies the SSRC that MUST be used for the i-th SRTP stream. Note that it is the sender of the streams that chooses the SSRC. Therefore, it is possible that the Initiator of MIKEY cannot fill in all fields. In this case, SSRCs that are not chosen by the Initiator are set to zero and the Responder fills in these fields in the response message. Note that SRTP specifies requirements on the uniqueness of the SSRCs (to avoid two-time pad problems if the same TEK is used for more than one stream) [SRTP].
* SSRC_i（32ビット）：i番目のSRTPストリームのために使用しなければならないSSRCを指定します。それはSSRCを選ぶストリームの送信者であることに注意してください。したがって、MIKEYのイニシエータは、すべてのフィールドに記入することができない可能性があります。この場合には、イニシエータによって選択されていないSSRCsはゼロに設定され、レスポンダは、応答メッセージにこれらのフィールドを埋めます。そのSRTPがSSRCsの一意性に関する要件を指定注（同じTEKが複数のストリームに対して使用される場合、2回のパッド問題を回避するために）[SRTP]。
* ROC_i (32 bits): Current rollover counter used in SRTP. If the SRTP session has not started, this field is set to 0. This field is used to enable a member to join and synchronize with an already started stream.
* ROC_i（32ビット）：SRTPで使用される現在のロールオーバカウンタ。 SRTPセッションが開始されていない場合、このフィールドは0に設定されているこのフィールドが参加し、すでに開始ストリームと同期するメンバーを有効にするために使用されます。
NOTE: The stream using SSRC_i will also have Crypto Session ID equal to no i (NOT to the SSRC).
注：SSRC_iを使ってストリームもなしI（NOT SSRCへ）への暗号化セッションIDが同じになります。
The Key data transport payload contains encrypted Key data sub-payloads (see Section 6.13 for the definition of the Key data sub-payload). It may contain one or more Key data payloads, each including, for example, a TGK. The last Key data payload has its Next payload field set to Last payload. For an update message (see also Section 4.5), it is allowed to skip the Key data sub-payloads (which will result in the Encr data len being equal to 0).
主なデータ転送ペイロードは暗号化された鍵データサブペイロードを（キーデータサブペイロードの定義については、セクション6.13を参照）が含まれています。それは、それぞれがTGK、例えば、1つ以上のキーデータペイロードを含むことができます。最後のキーデータペイロード最終ペイロードに設定し、その次のペイロードフィールドを持っています。更新メッセージを、（0に等しいlenのENCRデータをもたらす）鍵データサブペイロードをスキップすることが許される（セクション4.5参照）。
Note that the MAC coverage depends on the method used, i.e., pre-shared vs public key, see below.
以下を参照されたい、すなわち、公開キー対事前共有、MACカバレッジが使用される方法に依存することに留意されたいです。
If the transport method used is the pre-shared key method, this Key data transport payload is the last payload in the message (note that the Next payload field is set to Last payload). The MAC is then calculated over the entire MIKEY message following the directives in Section 5.2.
使用するトランスポート方法は、事前共有鍵方式である場合は、このキーのデータ転送ペイロードは（次のペイロードフィールドが最後のペイロードに設定されていることに注意してください）メッセージの最後のペイロードです。 MACは、その後、セクション5.2でディレクティブ次全体MIKEYメッセージに対して計算されます。
If the transport method used is the public-key method, the Initiator's identity is added in the encrypted data. This is done by adding the ID payload as the first payload, which is then followed by the Key data sub-payloads. Note that for an update message, the ID is still sent encrypted to the Responder (this is to avoid certain re-direction attacks) even though no Key data sub-payload is added after.
使用するトランスポート方法は、公開鍵方式である場合には、イニシエータのアイデンティティは暗号化されたデータに追加されます。次いで、これをキーデータサブペイロードが続く最初のペイロードとして、IDペイロードを追加することによって行われます。更新メッセージのためなお、IDはまだキーデータサブペイロードが後に添加されていないにも関わらず（これは特定の再方向攻撃を回避するためである）レスポンダに暗号化されて送信されます。
In the public-key case, the coverage of the MAC field is over the Key data transport payload only, instead of the complete MIKEY message, as in the pre-shared case. The MAC is therefore calculated over the Key data transport payload, except for the MAC field and where the Next payload field has been set to zero (see also Section 5.2).
公開鍵場合には、MACフィールドのカバレッジは、事前共有場合のように、代わりに完全MIKEYメッセージの、唯一の鍵データトランスポート・ペイロード上です。 MACは、したがってMACフィールドを除いて、キーデータのトランスポート・ペイロードにわたって計算され、ここで次ペイロードフィールド（セクション5.2も参照）がゼロに設定されています。
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 alg ! Encr data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Mac alg ! MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for defined values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。定義された値については、セクション6.1を参照してください。
* Encr alg (8 bits): the encryption algorithm used to encrypt the Encr data field.
* ENCR ALG（8ビット）：ENCRデータフィールドを暗号化するために使用される暗号化アルゴリズム。
Encr alg | Value | Comment
-------------------------------------------
NULL | 0 | Very restricted usage, see Section 4.2.3!
AES-CM-128 | 1 | Mandatory; AES-CM using a 128-bit key, see
Section 4.2.3)
AES-KW-128 | 2 | AES Key Wrap using a 128-bit key, see
Section 4.2.3
Table 6.2.a
表6.2.a
* Encr data len (16 bits): length of Encr data (in bytes).
* ENCRデータLEN（16ビット）：（バイト）ENCRデータの長さ。
* Encr data (variable length): the encrypted key sub-payloads (see Section 6.13).
* ENCRデータ（可変長）：暗号化キーのサブペイロード（セクション6.13を参照してください）。
* MAC alg (8 bits): specifies the authentication algorithm used.
* MAC ALG（8ビット）：使用される認証アルゴリズムを指定します。
MAC alg | Value | Comments | Length (bits)
----------------------------------------------------------
NULL | 0 | restricted usage | 0
| | Section 4.2.4 |
HMAC-SHA-1-160 | 1 | Mandatory, | 160
| | Section 4.2.4 |
Table 6.2.b
テーブル6.2.b
* MAC (variable length): the message authentication code of the entire message.
* MAC（可変長）：メッセージ全体のメッセージ認証コード。
The Envelope data payload contains the encrypted envelope key that is used in the public-key transport to protect the data in the Key data transport payload. The encryption algorithm used is implicit from the certificate/public key used.
エンベロープデータペイロードは、キーデータトランスポートペイロード内のデータを保護するため、公開鍵輸送に使用されている暗号化されたエンベロープキーが含まれています。使用される暗号化アルゴリズムを使用する証明書/公開鍵から暗黙的です。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! C ! Data len ! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。値については、セクション6.1を参照してください。
* C (2 bits): envelope key cache indicator (Section 3.2).
* C（2ビット）：キーキャッシュインジケーター（3.2節）を包み込みます。
Cache type | Value | Comments
--------------------------------------
No cache | 0 | The envelope key MUST NOT be cached
Cache | 1 | The envelope key MUST be cached
Cache for CSB | 2 | The envelope key MUST be cached, but only
| | to be used for the specific CSB.
Table 6.3
* Data len (14 bits): the length of the data field (in bytes).
*データLEN（14ビット）：（バイト）データフィールドの長さ。
* Data (variable length): the encrypted envelope key.
※データ（可変長）：暗号化されたエンベロープキー。
The DH data payload carries the DH-value and indicates the DH-group used. Notice that in this sub-section, "MANDATORY" is conditioned upon DH being supported.
DHデータペイロードはDH値を搬送し、使用されるDH-基を表します。 DHを条件とされるこのサブセクションで、「MANDATORY」のことに注意してくださいすることはサポートされています。
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 ! DH-Group ! DH-value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Reserv! KV ! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。値については、セクション6.1を参照してください。
* DH-Group (8 bits): identifies the DH group used.
* DH-グループ（8ビット）：使用されるDHグループを識別する。
DH-Group | Value | Comment | DH Value length (bits)
--------------------------------------|---------------------
OAKLEY 5 | 0 | Mandatory | 1536
OAKLEY 1 | 1 | | 768
OAKLEY 2 | 2 | | 1024
Table 6.4
表6.4
* DH-value (variable length): the public DH-value (the length is implicit from the group used).
* DH値（可変長）：公共のDH値（長さが使用されるグループから暗黙的です）。
* 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 for pre-defined values.
* KV（4ビット）：指定されたキーの有効期間のタイプを示します。これは、SPI（SRTPにおける代替的MKI）を使用して、またはキー（例えば、後者の場合、SRTPは、このキーが有効なインデックスの範囲であろう）が有効である期間を提供することによって行うことができます。事前定義された値については、セクション6.13を参照してください。
* KV data (variable length): This includes either the SPI/MKI or an interval (see Section 6.14). If KV is NULL, this field is not included.
* KVデータ（可変長）：これは、SPI / MKI又は間隔（セクション6.14を参照）のいずれかを含みます。 KVがNULLの場合、このフィールドは含まれていません。
The Signature payload carries the signature and its related data. The signature payload is always the last payload in the PK transport and DH exchange messages. The signature algorithm used is implicit from the certificate/public key used.
署名ペイロードは、署名とその関連データを搬送します。署名ペイロードは常にPK輸送とDH交換メッセージの最後のペイロードです。使用される署名アルゴリズムが使用された証明書/公開鍵から暗黙的です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! S type| Signature len ! Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* S type (4 bits): indicates the signature algorithm applied by the signer.
* S型（4ビット）：署名者によって適用される署名アルゴリズムを示しています。
S type | Value | Comments
-------------------------------------
RSA/PKCS#1/1.5| 0 | Mandatory, PKCS #1 version 1.5 signature
[PSS]
RSA/PSS | 1 | RSASSA-PSS signature [PSS]
Table 6.5
表6.5
* Signature len (12 bits): the length of the signature field (in bytes).
*署名LEN（12ビット）：（バイト）署名フィールドの長さ。
* Signature (variable length): the signature (its formatting and padding depend on the type of signature).
*署名（可変長）：署名（そのフォーマットおよびパディングが署名の種類に依存します）。
The timestamp payload carries the timestamp information.
タイムスタンプペイロードは、タイムスタンプ情報を運びます。
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 ! TS type ! TS value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。値については、セクション6.1を参照してください。
* TS type (8 bits): specifies the timestamp type used.
* TS型（8ビット）：使用されるタイムスタンプの種類を指定します。
TS type | Value | Comments | length of TS value
-------------------------------------|-------------------
NTP-UTC | 0 | Mandatory | 64-bits
NTP | 1 | Mandatory | 64-bits
COUNTER | 2 | Optional | 32-bits
Table 6.6
表6.6
Note: COUNTER SHALL be padded (with leading zeros) to a 64-bit value when used as input for the default PRF.
注：デフォルトPRFのための入力として使用されるとき、カウンタが64ビットの値（先行ゼロで）埋められます。
* TS-value (variable length): The timestamp value of the specified TS type.
* TS-値（可変長）：指定されたTSのタイプのタイムスタンプ値。
Note that the ID payload and the Certificate payload are two completely different payloads (having different payload identifiers). However, as they share the same payload structure, they are described in the same section.
IDペイロードと証明書ペイロードは、2つの完全に異なるペイロードは（異なるペイロード識別子を有する）であることに留意されたいです。それらが同じペイロード構造を共有しかし、それらは同一のセクションに記載されています。
The ID payload carries a uniquely defined identifier.
IDペイロードは一意に定まる識別子を運びます。
The certificate payload contains an indicator of the certificate provided as well as the certificate data. If a certificate chain is to be provided, each certificate in the chain should be included in a separate CERT payload.
証明書ペイロードは、提供された証明書だけでなく、証明書データの指標を含んでいます。証明書チェーンを提供する場合、チェーン内の各証明書は、別個CERTペイロードに含まれるべきです。
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 ! ID/Cert Type ! ID/Cert len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID/Certificate Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。値については、セクション6.1を参照してください。
If the payload is an ID payload, the following values apply for the ID type field:
ペイロードは、IDペイロードである場合、次の値は、IDタイプフィールドに適用されます。
* ID Type (8 bits): specifies the identifier type used.
* IDタイプ（8ビット）：使用される識別子のタイプを指定します。
ID Type | Value | Comments
----------------------------------------------
NAI | 0 | Mandatory (see [NAI])
URI | 1 | Mandatory (see [URI])
Table 6.7.a
表6.7.a
If the payload is a Certificate payload, the following values applies for the Cert type field:
ペイロードは、証明書のペイロードがある場合は、次の値は、証明書のタイプのフィールドに適用されます。
* Cert Type (8 bits): specifies the certificate type used.
*証明書の種類（8ビット）：使用される証明書の種類を指定します。
Cert Type | Value | Comments
----------------------------------------------
X.509v3 | 0 | Mandatory
X.509v3 URL | 1 | plain ASCII URL to the location of the Cert
X.509v3 Sign | 2 | Mandatory (used for signatures only)
X.509v3 Encr | 3 | Mandatory (used for encryption only)
Table 6.7.b
テーブル6.7.b
* ID/Cert len (16 bits): the length of the ID or Certificate field (in bytes).
* ID /証明書LEN（16ビット）：（バイト）IDまたは証明書フィールドの長さ。
* ID/Certificate (variable length): The ID or Certificate data. The X.509 [X.509] certificates are included as a bytes string using DER encoding as specified in X.509.
* ID /証明書（可変長）：IDまたは証明書データ。 X.509 [X.509]証明書はX.509で指定されているDER符号化を使用して、バイト列として含まれています。
The Cert hash payload contains the hash of the certificate used.
証明書のハッシュペイロードが使用される証明書のハッシュが含まれています。
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 ! Hash func ! Hash ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。値については、セクション6.1を参照してください。
* Hash func (8 bits): indicates the hash function that is used (see also Section 4.2.1).
*ハッシュFUNC（8ビット）：（セクション4.2.1を参照）が使用されるハッシュ関数を示しています。
Hash func | Value | Comment | hash length (bits)
-------------------------------------------------
SHA-1 | 0 | Mandatory | 160
MD5 | 1 | | 128
Table 6.8
表6.8
* Hash (variable length): the hash data. The hash length is implicit from the hash function used.
*ハッシュ（可変長）：ハッシュデータ。ハッシュの長さは、使用されるハッシュ関数から暗黙的です。
The Ver msg payload contains the calculated verification message in the pre-shared key and the public-key transport methods. Note that the MAC is calculated over the entire MIKEY message, as well as the IDs and Timestamp (see also Section 5.2).
版のMSGペイロードは、事前共有鍵と公開鍵の搬送方法で算出された検証メッセージを含みます。 MAC全体MIKEYメッセージ、ならびにIDおよびタイムスタンプにわたって計算されることに注意してください（セクション5.2を参照）。
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 ! Auth alg ! Ver data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。値については、セクション6.1を参照してください。
* Auth alg (8 bits): specifies the MAC algorithm used for the verification message. See Section 6.2 for defined values.
*認証ALG（8ビット）：確認メッセージのために使用されるMACアルゴリズムを指定します。定義された値については、セクション6.2を参照してください。
* Ver data (variable length): the verification message data. The length is implicit from the authentication algorithm used.
*版データ（可変長）：検証メッセージデータ。長さは、使用される認証アルゴリズムから暗黙的です。
The Security Policy payload defines a set of policies that apply to a specific security protocol.
セキュリティポリシーのペイロードは、特定のセキュリティプロトコルに適用されるポリシーのセットを定義します。
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 ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。値については、セクション6.1を参照してください。
* Policy no (8 bits): each security policy payload must be given a distinct number for the current MIKEY session by the local peer. This number is used to map a crypto session to a specific policy (see also Section 6.1.1).
*ポリシーない（8ビット）：各セキュリティ・ポリシー・ペイロードは、ローカルピアが現在MIKEYセッションの異なる番号を与えられなければなりません。この数は、特定のポリシーに暗号化セッションをマップするために使用される（セクション6.1.1を参照してください）。
* Prot type (8 bits): defines the security protocol.
* Protの種類（8ビット）：セキュリティプロトコルを定義します。
Prot type | Value |
---------------------------
SRTP | 0 |
Table 6.10
表6.10
* Policy param length (16 bits): defines the total length of the policy parameters for the specific security protocol.
*ポリシーPARAM長（16ビット）：特定のセキュリティプロトコルのポリシーパラメータの全体の長さを規定します。
* Policy param (variable length): defines the policy for the specific security protocol.
*ポリシーPARAM（可変長）：特定のセキュリティプロトコルのためのポリシーを定義します。
The Policy param part is built up by a set of Type/Length/Value fields. For each security protocol, a set of possible types/values that can be negotiated is defined.
ポリシーのparamパートは、タイプ/長さ/値フィールドのセットによって構築されます。各セキュリティプロトコルのために、ネゴシエートすることができる可能種類/値の組が定義されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Type (8 bits): specifies the type of the parameter.
*型（8ビット）：パラメータのタイプを指定します。
* Length (8 bits): specifies the length of the Value field (in bytes).
*長さ（8ビット）（バイト）値フィールドの長さを指定します。
* Value (variable length): specifies the value of the parameter.
*値（可変長）：パラメータの値を指定します。
This policy specifies the parameters for SRTP and SRTCP. The types/values that can be negotiated are defined by the following table:
このポリシーは、SRTPとSRTCPのためのパラメータを指定します。ネゴシエートすることができる種類/値は次の表によって定義されます。
Type | Meaning | Possible values
----------------------------------------------------
0 | Encryption algorithm | see below
1 | Session Encr. key length | depends on cipher used
2 | Authentication algorithm | see below
3 | Session Auth. key length | depends on MAC used
4 | Session Salt key length | see [SRTP] for recommendations
5 | SRTP Pseudo Random Function | see below
6 | Key derivation rate | see [SRTP] for recommendations
7 | SRTP encryption off/on | 0 if off, 1 if on
8 | SRTCP encryption off/on | 0 if off, 1 if on
9 | sender's FEC order | see below
10 | SRTP authentication off/on | 0 if off, 1 if on
11 | Authentication tag length | in bytes
12 | SRTP prefix length | in bytes
Table 6.10.1.a
テーブル6.10.1.a
Note that if a Type/Value is not set, the default is used (according to SRTP's own criteria). Note also that, if "Session Encr. key length" is set, this should also be seen as the Master key length (otherwise, the SRTP default Master key length is used).
タイプ/値が設定されていない場合、デフォルトは（SRTP独自の基準に基づいて）使用されていることに注意してください。 「セッションENCR。キーの長さ」が設定されている場合ということにも注意してください、これはまた、マスターキーの長さ（それ以外の場合は、SRTPデフォルトのマスターキーの長さが使用されている）として見られるべきです。
For the Encryption algorithm, a one byte length is enough. The currently defined possible Values are:
暗号化アルゴリズムの場合は、1バイトの長さは十分です。現在定義されている可能性のある値は以下のとおりです。
SRTP encr alg | Value
---------------------
NULL | 0
AES-CM | 1
AES-F8 | 2
Table 6.10.1.b
テーブル6.10.1.b
where AES-CM is AES in CM, and AES-F8 is AES in f8 mode [SRTP].
AES-CMは、CMにAESであり、AES-F8は、F8モード[SRTP]でAESです。
For the Authentication algorithm, a one byte length is enough. The currently defined possible Values are:
認証アルゴリズムの場合、1バイトの長さは十分です。現在定義されている可能性のある値は以下のとおりです。
SRTP auth alg | Value
---------------------
NULL | 0
HMAC-SHA-1 | 1
Table 6.10.1.c
テーブル6.10.1.c
For the SRTP pseudo-random function, a one byte length is also enough. The currently defined possible Values are:
SRTP擬似ランダム関数の場合は、1つのバイトの長さも十分です。現在定義されている可能性のある値は以下のとおりです。
SRTP PRF | Value
---------------------
AES-CM | 0
Table 6.10.1.d
テーブル6.10.1.d
If FEC is used at the same time SRTP is used, MIKEY can negotiate the order in which these should be applied at the sender side.
FECは、SRTPが使用され、同時に使用する場合は、MIKEYは、これらは、送信者側で適用されるべき順序を交渉することができます。
FEC order | Value | Comments
--------------------------------
FEC-SRTP | 0 | First FEC, then SRTP
Table 6.10.1.e
テーブル6.10.1.e
The RAND payload consists of a (pseudo-)random bit-string. The RAND MUST be independently generated per CSB (note that if the CSB has several members, the Initiator MUST use the same RAND for all the members). For randomness recommendations for security, see [RAND].
RANDペイロードは（擬似）ランダムビット列から成ります。 RANDは、独立してCSB（CSBは、複数のメンバーを持っている場合、イニシエータは、すべてのメンバーに同じRANDを使用しなければならないことに注意）ごとに生成されなければなりません。セキュリティのためのランダムの推奨事項については、[RAND]を参照してください。
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 ! RAND len ! RAND ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。値については、セクション6.1を参照してください。
* RAND len (8 bits): length of the RAND (in bytes). It SHOULD be at least 16.
* RAND LEN（8ビット）（バイト単位）RANDの長さ。それは、少なくとも16であるべきです。
* RAND (variable length): a (pseudo-)randomly chosen bit-string.
* RAND（可変長）：（擬似）ランダムに選択されたビット列。
The Error payload is used to specify the error(s) that may have occurred.
エラーペイロードが発生した可能性のあるエラー（複数可）を指定するために使用されます。
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 ! Error no ! Reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。値については、セクション6.1を参照してください。
* Error no (8 bits): indicates the type of error that was encountered.
*エラーなし（8ビット）：発生したエラーの種類を示していません。
Error no | Value | Comment
-------------------------------------------------------
Auth failure | 0 | Authentication failure
Invalid TS | 1 | Invalid timestamp
Invalid PRF | 2 | PRF function not supported
Invalid MAC | 3 | MAC algorithm not supported
Invalid EA | 4 | Encryption algorithm not supported
Invalid HA | 5 | Hash function not supported
Invalid DH | 6 | DH group not supported
Invalid ID | 7 | ID not supported
Invalid Cert | 8 | Certificate not supported
Invalid SP | 9 | SP type not supported
Invalid SPpar | 10 | SP parameters not supported
Invalid DT | 11 | not supported Data type
Unspecified error | 12 | an unspecified error occurred
Table 6.12
表6.12
The Key data payload contains key material, e.g., TGKs. The Key data payloads are never included in clear, but as an encrypted part of the Key data transport payload.
キーデータペイロードは、鍵材料、例えば、TGKsが含まれています。キーデータペイロードは明らかに含まれていないが、キーデータトランスポートペイロードの暗号化された部分としてん。
Note that a Key data transport payload can contain multiple Key data sub-payloads.
主なデータ転送ペイロードは、複数のキーデータサブペイロードを含むことができることに注意してください。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len (optional) ! Salt data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。値については、セクション6.1を参照してください。
* Type (4 bits): indicates the type of key included in the payload.
*型（4ビット）：ペイロードに含まれるキーの種類を示します。
Type | Value
-----------------
TGK | 0
TGK+SALT | 1
TEK | 2
TEK+SALT | 3
Table 6.13.a
テーブル6.13.a
Note that the possibility of including a TEK (instead of using the TGK) is provided. When sent directly, the TEK can generally not be shared between more than one Crypto Session (unless the Security protocol allows for this, e.g., [SRTP]). The recommended use of sending a TEK, instead of a TGK, is when pre-encrypted material exists and therefore, the TEK must be known in advance.
TEKを含む（代わりのTGKを使用）の可能性が提供されることに留意されたいです。直接送信するとき、TEKは、一般的に、複数の暗号化セッション（セキュリティプロトコルはこれを許可しない限り、例えば、[SRTP]）との間で共有することができません。予め暗号化された材料が存在し、従って、TEKが予め知られていなければならない場合代わりTGKで、TEKを送信する推奨使用です。
* 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 [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).
* KV（4ビット）：指定されたキーの有効期間のタイプを示します。これは、（[SRTP]の場合またはMKI）SPIを使用して実行してもよいし、キーが有効である期間を提供することによって（例えば、後者の場合、SRTPは、このキーはインデックス範囲であろう有効）。
KV | Value | Comments
-------------------------------------------
Null | 0 | No specific usage rule (e.g., a TEK
| | that has no specific lifetime)
SPI | 1 | The key is associated with the SPI/MKI
Interval | 2 | The key has a start and expiration time
| | (e.g., an SRTP TEK)
Table 6.13.b
テーブル6.13.b
Note that when NULL is specified, any SPI or Interval is valid. For an Interval, this means that the key is valid from the first observed sequence number until the key is replaced (or the security protocol is shutdown).
NULLが指定された場合、任意のSPIまたは間隔が有効であることに注意してください。間隔の場合、これはキーが交換された（またはセキュリティプロトコルがシャットダウンされる）まで、鍵は最初の観測されたシーケンス番号から有効であることを意味しています。
* Key data len (16 bits): the length of the Key data field (in bytes). Note that the sum of the overall length of all the Key data payloads contained in a single Key data transport payload (KEMAC) MUST be such that the KEMAC payload does not exceed a length of 2^16 bytes (total length of KEMAC, see Section 6.2).
*キーデータLEN（16ビット）：（バイト）鍵データ・フィールドの長さ。注単一の鍵データトランスポート・ペイロード（KEMAC）に含まれる全てのキーデータペイロードの全体の長さの合計がKEMACペイロードは2 ^ 16バイトKEMACの（全長の長さを超えないようにしなければならないことは、章を参照6.2）。
* Key data (variable length): The TGK or TEK data.
*キーデータ（可変長）：TGKまたはTEKデータ。
* Salt len (16 bits): The salt key length in bytes. Note that this field is only included if the salt is specified in the Type-field.
*塩LEN（16ビット）：バイトで塩キーの長さ。塩は、タイプフィールドで指定されている場合、このフィールドにのみ含まれていることに注意してください。
* Salt data (variable length): The salt key data. Note that this field is only included if the salt is specified in the Type-field. (For SRTP, this is the so-called master salt.)
*塩データ（可変長）：塩キーデータ。塩は、タイプフィールドで指定されている場合、このフィールドにのみ含まれていることに注意してください。 （SRTPの場合、これは、いわゆるマスター塩です。）
* KV data (variable length): This includes either the SPI or an interval (see Section 6.14). If KV is NULL, this field is not included.
* KVデータ（可変長）：これはSPIまたは間隔（セクション6.14を参照）のいずれかを含みます。 KVがNULLの場合、このフィールドは含まれていません。
The Key validity data is not a standalone payload, but part of either the Key data payload (see Section 6.13) or the DH payload (see Section 6.4). The Key validity data gives a guideline of when the key should be used. There are two KV types defined (see Section 6.13), SPI/MKI (SPI) or a lifetime range (interval).
主要有効性データは、スタンドアロンのペイロードが、キーデータペイロードまたはDHペイロード（セクション6.13を参照してください）（セクション6.4を参照）のいずれかの一部ではありません。主要有効性データは、キーを使用する必要があるときの指針を与えます。定義された2つのKVタイプ（セクション6.13を参照）、SPI / MKI（SPI）又は寿命の範囲（間隔）があります。
SPI/MKI
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* SPI Length (8 bits): the length of the SPI (or MKI) in bytes.
* SPI長（8ビット）：バイトでSPI（またはMKI）の長さ。
* SPI (variable length): the SPI (or MKI) value.
* SPI（可変長）：SPI（またはMKI）値。
Interval
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VF Length ! Valid From ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VT Length ! Valid To (expires) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* VF Length (8 bits): length of the Valid From field in bytes.
* VF長（8ビット）：バイトフィールドから有効長。
* Valid From (variable length): sequence number, index, timestamp, or other start value that the security protocol uses to identify the start position of the key usage.
*（可変長）から有効：シーケンス番号、インデックス、タイムスタンプ、またはセキュリティプロトコルは、鍵の使用の開始位置を識別するために使用する他の開始値。
* VT Length (8 bits): length of the Valid To field in bytes.
* VT長（8ビット）：バイトのフィールドに有効の長さ。
* Valid To (variable length): sequence number, index, timestamp, or other expiration value that the security protocol can use to identify the expiration of the key usage.
*（可変長）に有効：シーケンス番号、インデックス、タイムスタンプ、またはセキュリティプロトコルは、鍵の使用の有効期限を識別するために使用できる他の有効期限値。
Note that for SRTP usage, the key validity period for a TGK/TEK should be specified with either an interval, where the VF/VT Length is equal to 6 bytes (i.e., the size of the index), or with an MKI. It is RECOMMENDED that if more than one SRTP stream is sharing the same keys and key update/re-keying is desired, this is handled using MKI rather than the From-To method.
SRTPの使用のために、TGK / TEKのための鍵の有効期間は、VF / VTの長さは6バイト（インデックス即ち、サイズ）、またはMKIと等しい間隔、のいずれかで指定しなければならないことに留意されたいです。複数のSRTPストリームが同じ鍵を共有し、鍵更新/再キーイングが望まれる場合、これはかなり方法から、よりMKIを使用して処理することが推奨されます。
The General extensions payload is included to allow possible extensions to MIKEY without the need for defining a completely new payload each time. This payload can be used in any MIKEY message and is part of the authenticated/signed data part.
一般的な拡張ペイロードは、完全に新しいペイロードを毎回定義を必要とせずにMIKEYに可能な拡張を可能にするために含まれています。このペイロードは任意MIKEYメッセージで使用され、認証/署名されたデータ部分の一部であることができます。
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 ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload.
*次ペイロード（8ビット）：このペイロードの後に追加されたペイロードを識別する。
* Type (8 bits): identifies the type of general payload.
*型（8ビット）：一般的なペイロードのタイプを識別する。
Type | Value | Comments
---------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs (allocated for use in
[KMASDP])
Table 6.15
表6.15
* Length (16 bits): the length in bytes of the Data field.
*長さ（16ビット）：データフィールドのバイト単位の長さ。
* Data (variable length): the general payload data.
*データ（可変長）：一般的なペイロードデータ。
MIKEY MAY be integrated within session establishment protocols. Currently, integration of MIKEY within SIP/SDP and RTSP is defined in [KMASDP]. MIKEY MAY use other transports, in which case how MIKEY is transported over such a transport protocol has to be defined.
MIKEYは、セッション確立プロトコル内に統合されてもよいです。現在、SIP / SDPとRTSP内MIKEYの統合は[KMASDP]で定義されています。 MIKEYが定義されなければならないMIKEYは、このようなトランスポートプロトコルを介して転送される方法の場合に他のトランスポートを使用することができます。
What has been discussed up to now is not limited to single peer-to-peer communication (except for the DH method), but can be used to distribute group keys for small-size interactive groups and simple one-to-many scenarios. Section 2.1. describes the scenarios in the focus of MIKEY. This section describes how MIKEY is used in a group scenario (though, see also Section 4.3 for issues related to authorization).
何今まで説明してきたが（DH法を除く）は、単一のピア・ツー・ピア通信に限定されるものではなく、小型インタラクティブグループと単純な1対多数のシナリオのグループ鍵を配布するために使用することができます。 2.1。マイキーの焦点でシナリオについて説明します。このセクションでは、MIKEYが（ただし、認証に関連する問題については項4.3を参照してください）グループのシナリオで使用されている方法を説明します。
++++
|S |
| |
++++
|
--------+-------------- - -
| | |
v v v
++++ ++++ ++++
|A | |B | |C |
| | | | | |
++++ ++++ ++++
Figure 8.1. Simple one-to-many scenario.
図8.1。シンプルな1対多のシナリオ。
In the simple one-to-many scenario, a server is streaming to a small group of clients. RTSP or SIP is used for the registration and the key management set up. The streaming server acts as the Initiator of MIKEY. In this scenario, the pre-shared key or public key transport mechanism will be appropriate in transporting the same TGK to all the clients (which will result in common TEKs for the group).
シンプルな1対多のシナリオでは、サーバーは、クライアントの小さなグループにストリーミングされます。 RTSPまたはSIPを登録し、設定キー管理のために使用されています。ストリーミングサーバは、MIKEYのイニシエータとして動作します。このシナリオでは、事前共有鍵または公開鍵搬送機構（グループのための共通のTEKをもたらすであろう）すべてのクライアントに同じTGKの輸送に適切であろう。
Note, if the same TGK/TEK(s) should be used by all the group members, the streaming server MUST specify the same CSB_ID and CS_ID(s) for the session to all the group members.
すべてのグループメンバによって使用されるべき同じTGK / TEK（S）場合は、ストリーミングサーバは、すべてのグループメンバーへのセッションのために同じCSB_IDとCS_ID（複数可）を指定しなければなりません。
As the communication may be performed using multicast, the members need a common security policy if they want to be part of the group. This limits the possibility of negotiation.
通信は、マルチキャストを使用して実行されるように、彼らはグループの一部になりたい場合は、メンバーは共通のセキュリティポリシーを必要としています。これは、交渉の可能性を制限します。
Furthermore, the Initiator should carefully consider whether to request the verification message in reply from each receiver, as this may result in a certain load for the Initiator itself as the group size increases.
さらに、イニシエータは、慎重にこのグループのサイズが大きくなるにつれてイニシエータ自体の一定の負荷をもたらすことができるように、各受信機からの応答で確認メッセージを要求するかどうかを検討すべきです。
As described in the overview section, for small-size interactive groups, one may expect that each client will be in charge for setting up the security for its outgoing streams. In these scenarios, the pre-shared key or the public-key transport method is used.
概要セクションで説明したように、小型インタラクティブグループのために、1は、各クライアントがその送信ストリームのセキュリティを設定するための担当になることを期待します。これらのシナリオでは、事前共有鍵または公開鍵輸送方法が使用されます。
++++ ++++
|A | -------> |B |
| | <------- | |
++++ ++++
^ | | ^
| | | |
| | ++++ | |
| --->|C |<--- |
------| |------
++++
Figure 8.2. Small-size group without a centralized controller.
図8.2。集中制御なしの小型群。
One scenario may then be that the client sets up a three-part call, using SIP. Due to the small size of the group, unicast SRTP is used between the clients. Each client sets up the security for its outgoing stream(s) to the others.
1つのシナリオは、その後、SIPを使用して、クライアントは3部構成の呼を設定することも可能。グループのサイズが小さいため、ユニキャストSRTPはクライアントの間で使用されています。各クライアントは他の人への送信ストリーム（S）のためのセキュリティを設定します。
As for the simple one-to-many case, the streaming client specifies the same CSB_ID and CS_ID(s) for its outgoing sessions if the same TGK/TEK(s) is used for all the group members.
同じTGK / TEK（s）は、すべてのグループメンバーのために使用されている場合は、単純な1対多の場合については、ストリーミングクライアントは、その送信セッションのために同じCSB_IDとCS_ID（複数可）を指定します。
Key management protocols based on timestamps/counters and one-roundtrip key transport have previously been standardized, for example ISO [ISO1, ISO2]. The general security of these types of protocols can be found in various articles and literature, c.f. [HAC, AKE, LOA].
タイムスタンプ/カウンタと一往復キー輸送に基づいて、鍵管理プロトコルは、以前の例ISO [ISO1、ISO2]のために、標準化されています。プロトコルのこれらのタイプの一般的なセキュリティは、C.F.、様々な記事や文献に見出すことができます[HAC、AKE、LOA]。
No chain is stronger than its weakest link. If a given level of protection is wanted, then the cryptographic functions protecting the keys during transport/exchange MUST offer a security corresponding to at least that level.
いいえチェーンは、その最も弱いリンクより強力ではありません。保護の特定のレベルが望まれる場合には、輸送/交換中にキーを保護する暗号化機能は、少なくともそのレベルに対応したセキュリティを提供しなければなりません。
For instance, if a security against attacks with a complexity 2^96 is wanted, then one should choose a secure symmetric cipher supporting at least 96 bit keys (128 bits may be a practical choice) for the actual media protection, and a key transport mechanism that provides equivalent protection, e.g., MIKEY's pre-shared key transport with 128 bit TGK, or RSA with 1024 bit keys (which according to [LV] corresponds to the desired 96 bit level, with some margin).
複雑さ2 ^ 96と攻撃に対するセキュリティが望まれる場合、例えば、その一つは、実際のメディア保護のために少なくとも96ビットキーをサポートするセキュア対称暗号（128ビットは実用的な選択であってもよい）、及びキートランスポートを選択してください同等の保護を提供する機構、例えば、（[LV]に記載の余裕と、所望の96ビット・レベルに対応する）、1024ビットのキーを使用して128ビットTGK、またはRSAとMIKEYの事前共有鍵の輸送。
In summary, key size for the key-exchange mechanism MUST be weighed against the size of the exchanged TGK so that it at least offers the required level. For efficiency reasons, one SHOULD also avoid a security overkill, e.g., by not using a public key transport with public keys giving a security level that is orders of magnitude higher than length of the transported TGK. We refer to [LV] for concrete key size recommendations.
それは、少なくとも必要なレベルを提供していますように要約すると、鍵交換メカニズムのためのキーサイズは、交換TGKの大きさを比較検討しなければなりません。効率上の理由から、一つはまた、公開鍵が搬送TGKの長さよりも数桁高いセキュリティレベルを与えると、公開鍵トランスポートを使用しないことによって、例えば、セキュリティの行き過ぎを避けるべきです。我々は、具体的なキーサイズの推奨事項については、[LV]を参照してください。
Moreover, if the TGKs are not random (or pseudo-random), a brute force search may be facilitated, again lowering the effective key size. Therefore, care MUST be taken when designing the (pseudo-) random generators for TGK generation, see [FIPS][RAND].
TGKsは、ランダム（又は擬似ランダム）でない場合また、力まかせ探索を再度有効キーサイズを低下させる、容易にすることができます。 TGK生成のための（擬似）乱数発生器を設計する場合したがって、注意が[FIPS] [RAND]を参照して、注意しなければなりません。
For the selection of the hash function, SHA-1 with 160-bit output is the default one. In general, hash sizes should be twice the "security level", indicating that SHA-1-256, [SHA256], should be used for the default 128-bit level. However, due to the real-time aspects in the scenarios we are treating, hash sizes slightly below 256 are acceptable, as the normal "existential" collision probabilities would be of secondary importance.
ハッシュ関数の選択のために、160ビットの出力を持つSHA-1がデフォルトです。一般に、ハッシュサイズはSHA-1-256、[SHA256]、デフォルトの128ビット・レベルのために使用されるべきであることを示す、二回「セキュリティレベル」であるべきです。しかし、我々が扱っているシナリオでは、リアルタイムの側面に、わずか256以下のハッシュサイズは、通常の「実存」の衝突確率が二次的に重要であろうと、許容されています。
In a Crypto Session Bundle, the Crypto Sessions can share the same TGK as discussed earlier. From a security point of view, to satisfy the criterion in case the TGK is shared, the encryption of the individual Crypto Sessions are performed "independently". In MIKEY, this is accomplished by having unique Crypto Session identifiers (see also Section 4.1) and a TEK derivation method that provides cryptographically independent TEKs to distinct Crypto Sessions (within the Crypto Session Bundle), regardless of the security protocol used.
前述したように暗号化セッションバンドルに、暗号化セッションは、同じTGKを共有することができます。セキュリティの観点から、基準を満たすためにTGKが共有されている場合には、個々の暗号化セッションの暗号化は、「独立して」実行されます。 MIKEYでは、これはユニークな暗号化セッション識別子（セクション4.1を参照）にかかわらず、使用されるセキュリティプロトコルの、（暗号化セッションバンドル内の）別個の暗号化セッションを暗号独立のTEKを提供TEK導出方法を有することによって達成されます。
Specifically, the key derivations, as specified in Section 4.1, are implemented by a pseudo-random function. The one used here is a simplified version of that used in TLS [TLS]. Here, only one single hash function is used, whereas TLS uses two different functions. This choice is motivated by the high confidence in the SHA-1 hash function, and by efficiency and simplicity of design (complexity does not imply security). Indeed, as shown in [DBJ], if one of the two hashes is severely broken, the TLS PRF is actually less secure than as if a single hash had been used on the whole key, as is done in MIKEY.
具体的には、鍵導出は、セクション4.1で指定されるように、擬似ランダム関数によって実現されます。ここで使用されるものは、TLS [TLS]で使用したの簡易版です。 TLSは、2つの異なる関数を使用するのに対し、ここでは、ただ1つのハッシュ関数が使用されます。この選択は、SHA-1ハッシュ関数における高い信頼性によって動機づけされており、設計の効率性とシンプルで（複雑さはセキュリティを意味するものではありません）。 【DBJ]に示すように、2つのハッシュ値のいずれかがひどく破壊された場合MIKEYで行われるように実際に、TLS PRFは、単一のハッシュキー全体で使用されたかのようにより実際により安全です。
In the pre-shared key and public-key schemes, the TGK is generated by a single party (Initiator). This makes MIKEY somewhat more sensitive if the Initiator uses a bad random number generator. It should also be noted that neither the pre-shared nor the public-key scheme provides perfect forward secrecy. If mutual contribution or perfect forward secrecy is desired, the Diffie-Hellman method is to be used. Authentication (e.g., signatures) in the Diffie-Hellman method is required to prevent man-in-the-middle attacks.
事前共有鍵と公開鍵方式では、TGKは、単一の当事者（イニシエータ）によって生成されます。これは、イニシエータが悪い乱数ジェネレータを使用している場合MIKEYはややより敏感になります。また、事前共有もなく、公開鍵方式は完全転送秘密を提供どちらことに留意すべきです。相互寄与または完全転送秘密が所望される場合、ディフィー・ヘルマン法が使用されます。認証は、（例えば、署名）のDiffie-Hellman方式では、man-in-the-middle攻撃を防ぐために必要とされます。
Forward/backward security: if the TGK is exposed, all generated TEKs are compromised. However, under the assumption that the derivation function is a pseudo-random function, disclosure of an individual TEK does not compromise other (previous or later) TEKs derived from the same TGK. The Diffie-Hellman mode can be considered by cautious users, as it is the only one that supports so called perfect forward secrecy (PFS). This is in contrast to a compromise of the pre-shared key (or the secret key of the public key mode), where future sessions and recorded sessions from the past are then also compromised.
前方/後方のセキュリティ：TGKが露出している場合は、生成されたすべてのTEKが侵害されています。しかし、導出関数は、擬似ランダム関数であるという仮定の下で、個々のTEKの開示は同じTGKに由来する他の（前又は後）のTEKを損ないません。それはいわゆる完全転送秘密（PFS）をサポートする唯一のものであるとのDiffie-Hellmanモードは、慎重なユーザーが考えることができます。これは、過去から将来のセッションと記録されたセッションは、その後も侵害された事前共有キー（または公開鍵方式の秘密鍵）、の妥協とは対照的です。
The use of random nonces (RANDs) in the key derivation is of utmost importance to counter off-line pre-computation attacks. Note however that update messages re-use the old RAND. This means that the total effective key entropy (relative to pre-computation attacks) for k consecutive key updates, assuming the TGKs and RAND are each n bits long, is about L = n*(k+1)/2 bits, compared to the theoretical maximum of n*k bits. In other words, a 2^L work effort MAY enable an attacker to get all k n-bit keys, which is better than brute force (except when k = 1). While this might seem like a defect, first note that for a proper choice of n, the 2^L complexity of the attack is way out of reach. Moreover, the fact that more than one key can be compromised in a single attack is inherent to the key exchange problem. Consider for instance a user who, using a fixed 1024-bit RSA key, exchanges keys and communicates during a one or two year lifetime of the public key. Breaking this single RSA key will enable access to all exchanged keys and consequently the entire communication of that user over the whole period.
鍵導出のランダムなナンス（ランズ）の使用は、オフラインで事前計算攻撃に対抗するために最も重要です。しかし、その更新メッセージに注意してください古いRANDを再使用します。これは、総有効鍵エントロピーK連続鍵更新の（相対的に事前計算攻撃）、TGKsを想定し、RANDは、各nビットのに比べて、約L = N *（k + 1）/ 2ビットであり、長であることを意味しますn個の* kビットの理論的な最大値。換言すれば、2 ^ L作業努力が（k = 1の場合を除く）ブルートフォースよりも優れているすべてのk個のnビットの鍵を取得する攻撃を可能にすることができます。これは、nの適切な選択のために、攻撃の2 ^ Lの複雑さは、手の届かない道であることを欠陥、最初のノートのように見えるかもしれませんが。また、複数のキーを単一の攻撃で妥協することができるという事実は、鍵交換の問題に固有のものです。例えば、公開鍵の1または2年の寿命の間に鍵を交換して通信し、固定された1024ビットのRSAキーを使用して、ユーザーを考えてみましょう。この単一のRSA鍵を破ることは、全期間にわたってそのユーザのすべての交換鍵にアクセスし、その結果、全体の通信が可能になります。
All the pre-defined transforms in MIKEY use state-of-the-art algorithms that have undergone large amounts of public evaluation. One of the reasons for using the AES-CM from SRTP [SRTP], is to have the possibility of limiting the overall number of different encryption modes and algorithms, while offering a high level of security at the same time.
マイキーのすべての事前定義された変換は、公共の評価を大量に受けた最先端のアルゴリズムを使用します。 AES-CM SRTP [SRTP]からを使用する理由の一つは、同時に高いレベルのセキュリティを提供しながら、異なる暗号化モードとアルゴリズムの全体的な数を制限する可能性を有することです。
Even if the lifetime of a TGK (or TEK) is not specified, it MUST be taken into account that the encryption transform in the underlying security protocol can in some way degenerate after a certain amount of encrypted data. It is not possible to here state universally applicable, general key lifetime bounds; each security protocol should define such maximum amount and trigger a re-keying procedure before the "exhaustion" of the key. For example, according to SRTP [SRTP] the TEK, together with the corresponding TGK, MUST be changed at least every 2^48 SRTP packet.
TGK（またはTEK）の寿命が指定されていない場合でも、それは暗号化は基本的なセキュリティプロトコルに変換することを考慮しなければならないことができ、暗号化されたデータの一定量の後にいくつかの方法の縮退インチ状態普遍的に適用、一般的なキーの有効期間の境界をここにすることはできません。各セキュリティ・プロトコルは、このような最大量を定義し、キーの「枯渇」の前に再キーイング手続きをトリガしなければなりません。例えば、TEK SRTP [SRTP]によれば、互いに対応TGKと、少なくとも毎に2 ^ 48 SRTPパケットを変更しなければなりません。
Still, the following can be said as a rule of thumb. If the security protocol uses an "ideal" b-bit block cipher (in CBC mode, counter mode, or a feedback mode, e.g., OFB, with full b-bit feedback), degenerate behavior in the crypto stream, possibly useful for an attacker, is (with constant probability) expected to occur after a total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs). For security margin, re-keying MUST be triggered well in advance compared to the above bound. See [BDJR] for more details.
それでも、次のことが経験則として言うことができます。セキュリティプロトコルは、暗号化ストリームにおける縮退動作のためにおそらく有用な（フルBビットフィードバックを有する、例えばCBCモード、カウンタモード、又はフィードバックモード、OFBに）「理想的な」Bビットのブロック暗号を使用している場合攻撃者は、（ランダムIVを使用して）約2 ^（B / 2）暗号化されたBビットブロックの合計後に発生すると予想（一定の確率で）です。セキュリティマージンのために、再キーイングは、上記のバウンドに比べて早めにトリガされなければなりません。詳細については、[BDJR]を参照してください。
For use of a dedicated stream cipher, we refer to the analysis and documentation of said cipher in each specific case.
専用のストリーム暗号の使用のために、私たちはそれぞれの特定のケースでの分析と言っ暗号のマニュアルを参照してください。
The use of timestamps, instead of challenge-responses, requires the systems to have synchronized clocks. Of course, if two clients are not synchronized, they will have difficulties in setting up the security. The current timestamp based solution has been selected to allow a maximum of one roundtrip (i.e., two messages), but still provide a reasonable replay protection. A (secure) challenge-response based version would require at least three messages. For a detailed description of the timestamp and replay handling in MIKEY, see Section 5.4.
代わりに、チャレンジ・レスポンスのタイムスタンプの使用は、同期したクロックを持っているシステムが必要です。 2つのクライアントが同期されていない場合はもちろん、彼らがセキュリティの設定の難しさを持っています。現在のタイムスタンプベースの溶液を1回の往復（すなわち、二つのメッセージ）の最大値を可能にするが、それでも妥当な再生保護を提供するように選択されています。 （安全な）チャレンジ・レスポンスベースのバージョンは、少なくとも3つのメッセージを必要とします。 MIKEYに取り扱い、タイムスタンプと再生の詳細については、5.4節を参照してください。
Practical experiences of Kerberos and other timestamp-based systems indicate that it is not always necessary to synchronize the terminals over the network. Manual configuration could be a feasible alternative in many cases (especially in scenarios where the degree of looseness is high). However, the choice must be made carefully with respect to the usage scenario.
Kerberosおよびその他のタイムスタンプベースのシステムの実用的な経験は、ネットワーク上の端末を同期することは必ずしも必要ではないことを示しています。手動設定は、多くの場合（特に緩みの程度が高いシナリオで）実現可能な選択肢である可能性があります。しかし、選択は使用シナリオに関して慎重になされなければなりません。
User privacy is a complex matter that to some extent can be enforced by cryptographic mechanisms, but also requires policy enforcement and various other functionalities. One particular facet of privacy is user identity protection. However, identity protection was not a main design goal for MIKEY. Such a feature will add more complexity to the protocol and was therefore not chosen to be included. As MIKEY is anyway proposed to be transported over, e.g., SIP, the identity may be exposed by this. However, if the transporting protocol is secured and also provides identity protection, MIKEY might inherit the same feature. How this should be done is for future study.
ユーザーのプライバシーはある程度暗号メカニズムによって強制することができ、複雑な問題ですが、また、政策執行機関や他のさまざまな機能を必要とします。プライバシーの一つの特定の面には、ユーザID保護です。しかし、アイデンティティ保護はMIKEYのための主要な設計目標ではありませんでした。このような特徴は、プロトコルに複雑さを追加し、したがって、含まれるように選択されませんでした。 MIKEYをとにかく上に搬送されることが提案されているように、例えば、SIP、識別は、このことによって露出させることができます。輸送プロトコルを確保しても、アイデンティティ保護を提供している場合は、MIKEYは、同じ機能を継承することがあります。これはどのように行われるべき将来の検討課題です。
This protocol is resistant to Denial of Service attacks in the sense that a Responder does not construct any state (at the key management protocol level) before it has authenticated the Initiator. However, this protocol, like many others, is open to attacks that use spoofed IP addresses to create a large number of fake requests. This may for example, be solved by letting the protocol transporting MIKEY do an IP address validity test. The SIP protocol can provide this using the anonymous authentication challenge mechanism (specified in Section 22.1 of [SIP]).
このプロトコルは、イニシエータを認証した前に、Responderが（鍵管理プロトコルレベルで）どのような状態を構築していないという意味で、サービス妨害攻撃に耐性があります。しかし、このプロトコルは、他の多くのように、偽の多数の要求を作成するために、偽装されたIPアドレスを使用した攻撃に開いています。これは、例えば、MIKEYは、IPアドレスの妥当性検査を行う輸送プロトコルをさせることによって解決すること。 SIPプロトコルは、（[SIP]のセクション22.1で指定された）匿名認証チャレンジ・メカニズムを使用してこれを提供することができます。
It is highly RECOMMENDED to include IDr in the Initiator's message. If not included, its absence can be used for DoS purposes (the largest DoS-impact being on the public key and DH methods), where a message intended for other entities is sent to the target. In fact, the target may verify the signature correctly due to the fact that the Initiator's ID is correct and the message is actually signed by the claimed Initiator (e.g., by re-directing traffic from another session).
非常にイニシエータのメッセージでIDRを含めることをお勧めします。含まれていない場合、その不在は、DOS目的の他のエンティティのために意図されたメッセージをターゲットに送信され、（公開鍵とDH法にある最大のDoS衝撃）のために使用することができます。実際には、ターゲットが原因イニシエータのIDが正しく、メッセージが実際に主張イニシエータ（例えば、別のセッションからの再指向トラフィックによる）によって署名されているという事実を正しく署名を検証することができます。
However, in the public key method, the envelop key and the MAC will ensure that the message is not accepted (still, compared to a normal faked message, where the signature verification would detect the problem, one extra public key decryption is needed to detect the problem in this case).
しかし、公開鍵方式では、エンベロープキー及びMACは、依然として、署名検証が問題を検出するであろう通常の偽造メッセージに比べて、1つの追加の公開鍵暗号解読を検出するために必要とされる（メッセージが受け入れられないことを保証しますこの場合の問題点）。
In the DH method, a message would be accepted (without detecting the error) and a response (and state) would be created for the malicious request.
DH法では、メッセージは、（エラーを検出せずに）受け入れられると応答（状態）が悪意のある要求に対して作成されます。
As also discussed in Section 5.4, the tradeoff between time synchronization and the size of the replay cache may be affected in case of for example, a flooding DoS attack. However, if the recommendations of using a dynamic size of the replay cache are followed, it is believed that the client will in most cases be able to handle the replay cache. Of course, as the replay cache decreases in size, the required time synchronization is more restricted. However, a bigger problem during such an attack would probably be to process the messages (e.g., verify signatures/MACs) due to the computational workload this implies.
また、セクション5.4で議論するように、時間同期及び再生キャッシュのサイズとの間のトレードオフは、例えば、フラッディングDoS攻撃の場合に影響を受ける可能性があります。リプレイ・キャッシュの動的なサイズを使用しての勧告に従っている場合は、そのクライアントは、ほとんどの場合、リプレイのキャッシュを処理することができると考えられています。リプレイキャッシュのサイズが小さくなると当然、必要な時刻同期は、より制限されています。しかし、このような攻撃時の大きな問題は、おそらくこれが意味する計算ワークロードに（例えば、署名/ MACを検証する）メッセージを処理することです。
It should be noted that if the session establishment protocol is insecure, there may be attacks on this that will have indirect security implications on the secured media streams. This however only applies to groups (and is not specific to MIKEY). The threat is that one group member may re-direct a stream from one group member to another. This will have the same implication as when a member tries to impersonate another member, e.g., by changing its IP address. If this is seen as a problem, it is RECOMMENDED that a Data Origin Authentication (DOA) scheme (e.g., digital signatures) be applied to the security protocol.
セッション確立プロトコルが安全ではない場合、セキュリティで保護されたメディアストリームに間接的なセキュリティに影響を持つことになり、この上の攻撃があるかもしれないことに留意すべきです。しかし、これはグループのみに適用されます（とMIKEYに固有ではありません）。脅威は、1人のグループのメンバーが別のグループメンバーからのストリームを再指示することができるということです。この部材は、そのIPアドレスを変更することにより、例えば、他の部材を偽装しようとした場合と同じ意味を有することになります。これが問題視されている場合は、データ発信元認証（DOA）スキーム（例えば、デジタル署名）がセキュリティプロトコルに適用することが推奨されます。
Re-direction of streams can of course be done even if it is not a group. However, the effect will not be the same as compared to a group where impersonation can be done if DOA is not used. Instead, re-direction will only deny the receiver the possibility of receiving (or just delay) the data.
再方向ストリームもちろん、それがグループでない場合でも行うことができます。しかし、効果は、DOAが使用されていない場合に偽装を行うことができる群と比較して同じではないであろう。代わりに、再方向のみ受信機にデータを受信（または単に遅延）の可能性を否定するであろう。
This document defines several new name spaces associated with the MIKEY payloads. This section summarizes the name spaces for which IANA is requested to manage the allocation of values. IANA is requested to record the pre-defined values defined in the given sections for each name space. IANA is also requested to manage the definition of additional values in the future. Unless explicitly stated otherwise, values in the range 0-240 for each name space SHOULD be approved by the process of IETF consensus and values in the range 241-255 are reserved for Private Use, according to [RFC2434].
この文書では、MIKEYペイロードに関連するいくつかの新しい名前空間を定義します。このセクションでは、IANAが値の割り当てを管理するために要求されている名前空間をまとめたもの。 IANAは、それぞれの名前空間の特定のセクションで定義されている事前定義された値を記録することが要求されます。 IANAはまた、将来的に追加の値の定義を管理することが要求されます。特に明記しない限り、各名前空間のための0から240の範囲内の値の範囲241-255でIETFコンセンサスと値のプロセスによって承認されるべきでは[RFC2434]によると、私的使用のために予約されています。
The name spaces for the following fields in the Common header payload (from Section 6.1) are requested to be managed by IANA (in bracket is the reference to the table with the initially registered values):
（セクション6.1からの）共通ヘッダのペイロードにおける次のフィールドの名前空間はIANAによって管理されるように要求されている（括弧内の最初に登録された値を持つテーブルへの参照です）。
* version
* 版
* data type (Table 6.1.a)
*データ型（表6.1.a）
* Next payload (Table 6.1.b)
*次ペイロード（表6.1.b）
* PRF func (Table 6.1.c). This name space is between 0-127, where values between 0-111 should be approved by the process of IETF consensus and values between 112-127 are reserved for Private Use.
* PRFのFUNC（表6.1.c）。この名前空間は、私的使用のために予約されて0から111の間の値がIETFコンセンサスと112から127の間の値のプロセスによって承認されなければならない0〜127の間です。
* CS ID map type (Table 6.1.d)
* CS IDマップタイプ（表6.1.d）
The name spaces for the following fields in the Key data transport payload (from Section 6.2) are requested to be managed by IANA:
（セクション6.2からの）鍵データ転送ペイロード内の次のフィールドの名前空間はIANAによって管理されるように要求されています。
* Encr alg (Table 6.2.a)
* ENCR ALG（表6.2.a）
* MAC alg (Table 6.2.b)
* MAC ALG（表6.2.b）
The name spaces for the following fields in the Envelope data payload (from Section 6.3) are requested to be managed by IANA:
（セクション6.3から）エンベロープデータペイロードにおける次のフィールドの名前空間はIANAによって管理されるように要求されています。
* C (Table 6.3)
* C（表6.3）
The name spaces for the following fields in the DH data payload (from Section 6.4) are requested to be managed by IANA:
（セクション6.4から）DHデータペイロードにおける次のフィールドの名前空間はIANAによって管理されるように要求されています。
* DH-Group (Table 6.4)
* DH-グループ（表6.4）
The name spaces for the following fields in the Signature payload (from Section 6.5) are requested to be managed by IANA:
（セクション6.5から）署名ペイロード内の次のフィールドの名前空間はIANAによって管理されるように要求されています。
* S type (Table 6.5)
* S型（表6.5）
The name spaces for the following fields in the Timestamp payload (from Section 6.6) are requested to be managed by IANA:
（セクション6.6からの）タイムスタンプペイロード内の次のフィールドの名前空間はIANAによって管理されるように要求されています。
* TS type (Table 6.6)
* TSタイプ（表6.6）
The name spaces for the following fields in the ID payload and the Certificate payload (from Section 6.7) are requested to be managed by IANA:
IDペイロード及び（6.7節）からの証明書ペイロード内の次のフィールドの名前空間はIANAによって管理されるように要求されています。
* ID type (Table 6.7.a)
* IDのタイプ（表6.7.a）
* Cert type (Table 6.7.b)
*証明書のタイプ（表6.7.b）
The name spaces for the following fields in the Cert hash payload (from Section 6.8) are requested to be managed by IANA:
（6.8節）から証明書のハッシュペイロードにおける次のフィールドの名前空間はIANAによって管理されるように要求されています。
* Hash func (Table 6.8)
*ハッシュFUNC（表6.8）
The name spaces for the following fields in the Security policy payload (from Section 6.10) are requested to be managed by IANA:
（6.10から）セキュリティポリシーのペイロード内の次のフィールドの名前空間はIANAによって管理されるように要求されています。
* Prot type (Table 6.10)
* Protの種類（表6.10）
For each security protocol that uses MIKEY, a set of unique parameters MAY be registered.
MIKEYを使用する各セキュリティプロトコルのために、ユニークなパラメータのセットを登録しておいてもよいです。
From Section 6.10.1.
セクション6.10.1から。
* SRTP Type (Table 6.10.1.a)
* SRTPタイプ（表6.10.1.a）
* SRTP encr alg (Table 6.10.1.b)
* SRTP ENCR ALG（表6.10.1.b）
* SRTP auth alg (Table 6.10.1.c)
* SRTP AUTH ALG（表6.10.1.c）
* SRTP PRF (Table 6.10.1.d)
* SRTP PRF（表6.10.1.d）
* FEC order (Table 6.10.1.e)
* FEC順（表6.10.1.e）
The name spaces for the following fields in the Error payload (from Section 6.12) are requested to be managed by IANA:
（セクション6.12からの）エラーペイロードにおける次のフィールドの名前空間はIANAによって管理されるように要求されています。
* Error no (Table 6.12)
*エラーがない（表6.12）
The name spaces for the following fields in the Key data payload (from Section 6.13) are requested to be managed by IANA:
（セクション6.13からの）鍵データペイロードにおける次のフィールドの名前空間はIANAによって管理されるように要求されています。
* Type (Table 6.13.a). This name space is between 0-16, which should be approved by the process of IETF consensus.
*タイプ（表6.13.a）。この名前空間はIETF合意のプロセスによって承認されなければならない0-16、間にあります。
* KV (Table 6.13.b). This name space is between 0-16, which should be approved by the process of IETF consensus.
* KV（表6.13.b）。この名前空間はIETF合意のプロセスによって承認されなければならない0-16、間にあります。
The name spaces for the following fields in the General Extensions payload (from Section 6.15) are requested to be managed by IANA:
（セクション6.15からの）一般的な拡張ペイロードの以下のフィールドの名前空間はIANAによって管理されるように要求されています。
* Type (Table 6.15).
*タイプ（表6.15）。
This section gives instructions to IANA to register the application/mikey MIME media type. This registration is as follows:
このセクションでは、アプリケーション/マイキーMIMEメディアタイプを登録するにはIANAに指示を与えます。次のようにこの登録は、次のとおりです。
MIME media type name : application MIME subtype name : mikey Required parameters : none Optional parameters : version version: The MIKEY version number of the enclosed message (e.g., 1). If not present, the version defaults to 1. Encoding Considerations : binary, base64 encoded Security Considerations : see section 9 in this memo Interoperability considerations : none Published specification : this memo
MIMEメディアタイプ名：アプリケーションMIMEサブタイプ名：マイキー必須パラメータ：なしオプションのパラメータ：バージョンバージョン：同封のメッセージのMIKEYバージョン番号（例えば、1）。存在しない場合は、1エンコーディングの考慮事項へのバージョンのデフォルト：バイナリ、base64でエンコードセキュリティの考慮：このメモの相互運用性の考慮にセクション9を参照してください：なし公開された仕様：このメモを
The authors would like to thank Mark Baugher, Ran Canetti, Martin Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov Vatn, Erik Eliasson, and Gerhard Strangar for their valuable feedback.
著者はマークBaugherに感謝したいと思い、カネッティ、マーティンEUCHNER、ステファンのフライドポテト、ピーターBarany、ラスHousley、（彼のグループで）パシアホネン、ロルフブロム、マグヌスウェスター、ヨハンBilien、ジョン・Olov VATN、エリック・エリアソン、と蘭彼らの貴重なフィードバックのためのゲルハルトStrangar。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[NAI] Aboba、B.及びM. Beadles、 "ネットワークアクセス識別子"、RFC 2486、1999年1月。
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[OAKLEY]オーマン、H.、 "OAKLEYキー決意プロトコル"、RFC 2412、1998年11月。
[PSS] PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories, June 14, 2002, www.rsalabs.com
[PSS] PKCS＃1 V2.1 - RSA暗号化規格、RSA研究所、2002年6月14日、www.rsalabs.com
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[SHA-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[SHA-1] NIST、FIPSパブ180-1：1995セキュアハッシュスタンダード4月。
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real Time Transport Protocol", RFC 3711, March 2004.
[SRTP] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイムトランスポートプロトコル"、RFC 3711、2004年3月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[X.509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[X.509] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[AESKW] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AESKW] Schaad、J.とR. Housley氏、 "高度暗号化標準（AES）キーラップアルゴリズム"、RFC 3394、2002年9月。
[AKE] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange Protocols and their use for Building Secure Channels", Eurocrypt 2001, LNCS 2054, pp. 453-474, 2001.
[AKE]カネッティ、R.およびH. Krawczyk、 "鍵交換プロトコルの解析、安全なチャンネルを構築するためのそれらの使用"、EUROCRYPT 2001、LNCS 2054、頁453から474、2001。
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes of Operation", in Proceedings of the 38th Symposium on Foundations of Computer Science, IEEE, 1997, pp. 394-403.
【BDJR]ベラー、M.、デサイ、A.、Jokipii、E.、およびP. Rogaway、「対称暗号化の具体的な分析：動作のDESモードの分析」、第38回シンポジウムにおけるコンピュータの基礎に科学、IEEE、1997年、頁394から403まで。
[BMGL] Hastad, J. and M. Naslund: "Practical Construction and Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt 2001, LNCS. vol 2248, pp. 442-459, 2001.
【BMGL] Hastad、J.とM. Naslund： "Pseduo-ランダムプリミティブの具体的構成および分析"、Asiacrypt 2001、LNCSの議事。巻2248頁442から459、2001。
[DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of MD5", Contribution to ANSI X9F1 WG, 2001.
[DBJ]ジョンソン、D。B.、 "MD5のTLSを使用して理論的セキュリティ懸念"、ANSI X9F1 WG、2001年への貢献。
[FIPS] "Security Requirements for Cryptographic Modules", Federal Information Processing Standard Publications (FIPS PUBS) 140-2, December 2002.
[FIPS] "暗号モジュールのセキュリティ要件"、連邦情報処理標準出版物（FIPS PUBS）140-2、2002年12月。
[GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Group Key Management Architecture", Work in Progress.
[GKMARCH] Baugher、M.、カネッティ、R.、Dondeti、L.、およびF.リンドホルム、 "グループ鍵管理アーキテクチャ"、進行中の作業。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
【GDOI] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and R. Fleischer, "Group Secure Association Key Management Protocol", Work in Progress.
[GSAKMP]ハーニー、H.、Colegrove、A.、ハーダー、E.、メタ、U.、およびR.フライシャーは、進行中で働いて "グループは、協会の鍵管理プロトコルをセキュア"。
[HAC] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC press, 1996.
[HAC]メネゼス、A.、バンOorschot、P.、およびS. Vanstone著、CRCプレス、1996 "応用暗号ハンドブック"。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[ISO1] ISO/IEC 9798-3: 1997, Information technology - Security techniques - Entity authentication - Part 3: Mechanisms using digital signature techniques.
[ISO1] ISO / IEC 9798から3：1997、情報技術 - セキュリティ技術 - エンティティ認証 - 第3部：デジタル署名技術を使用してメカニズム。
[ISO2] ISO/IEC 11770-3: 1997, Information technology - Security techniques - Key management - Part 3: Mechanisms using digital signature techniques.
[ISO2] ISO / IEC 11770から3：1997、情報技術 - セキュリティ技術 - 鍵管理 - 第3部：デジタル署名技術を使用してメカニズム。
[ISO3] ISO/IEC 18014 Information technology - Security techniques - Time-stamping services, Part 1-3.
[ISO3] ISO / IEC 18014情報技術 - セキュリティ技術 - タイムスタンピングサービス、パート1-3。
[KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for SDP and RTSP", Work in Progress.
【KMASDP] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "SDPとRTSPのためのキー管理拡張子"、ProgressのWork。
[LOA] Burrows, Abadi, and Needham, "A logic of authentication", ACM Transactions on Computer Systems 8 No.1 (Feb. 1990), 18-36.
[LOA]バロウズ、アバディ、およびニーダム、 "認証の論理"、コンピュータシステム8第1号（1990年2月）、18-36上のACMトランザクションが。
[LV] Lenstra, A. K. and E. R. Verheul, "Suggesting Key Sizes for Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[LV] Lenstra、A. K.およびE. R. Verheul、 "暗号のための鍵のサイズの提案"、http://www.cryptosavvy.com/suggestions.htm
[NTP] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[NTP]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[RAND] Eastlake, 3rd, D., Crocker, S., and J. Schiller, "Randomness Requirements for Security", RFC 1750, December 1994.
[RAND]イーストレイク、第三、D.、クロッカー、S.、およびJ.シラー、 "セキュリティのためのランダム性の要件"、RFC 1750、1994年12月。
[RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RTSP] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512", http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf
【SHA256] NIST、 "SHA256の説明、SHA-384およびSHA-512"、http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf
[SIP] 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.
[SIP]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコル - バージョン1.0"、RFC 2246、1999年1月。
Appendix A. MIKEY - SRTP Relation
付録A. MIKEY - SRTP関係
The terminology in MIKEY differs from the one used in SRTP as MIKEY needs to be more general, nor is tight to SRTP only. Therefore, it might be hard to see the relations between keys and parameters generated in MIKEY and those used by SRTP. This section provides some hints on their relation.
マイキーでの用語はMIKEYは、より一般的にする必要があるとして、SRTPで使用されるものとは異なり、また唯一のSRTPするタイトです。したがって、キーおよびパラメータMIKEYで生成し、SRTPで使用されているものとの関係を見るのは難しいかもしれません。このセクションでは、彼らの関係にいくつかのヒントを提供します。
MIKEY | SRTP
-------------------------------------------------
Crypto Session | SRTP stream (typically with related SRTCP stream)
Data SA | input to SRTP's crypto context
TEK | SRTP master key
The Data SA is built up by a TEK and the security policy exchanged. SRTP may use an MKI to index the TEK or TGK (the TEK is then derived from the TGK that is associated with the corresponding MKI), see below.
データSAは、TEKによって構築されたセキュリティポリシーを交換しました。 SRTPは、以下を参照、TEK又はTGK（TEKは、対応するMKIに関連付けられTGKから誘導される）インデックスにMKIを使用することができます。
A.1. MIKEY-SRTP Interactions
A.1。 MIKEY-SRTPの相互作用
In the following, we give a brief outline of the interface between SRTP and MIKEY and the processing that takes place. We describe the SRTP receiver side only, the sender side will require analogous interfacing.
以下では、SRTPとMIKEYと場所を取る処理との間のインターフェイスの簡単な概要を与えます。我々は唯一のSRTP受信機側を記述し、送信側は、類似したインタフェースが必要になります。
1. When an SRTP packet arrives at the receiver and is processed, the triple <SSRC, destination address, destination port> is extracted from the packet and used to retrieve the correct SRTP crypto context, hence the Data SA. (The actual retrieval can, for example, be done by an explicit request from the SRTP implementation to MIKEY, or, by the SRTP implementation accessing a "database", maintained by MIKEY. The application will typically decide which implementation is preferred.)
SRTPパケットが受信機に到着し、処理され、三重<SSRC、宛先アドレス、宛先ポート>場合1.データSAは、したがって、パケットから抽出され、正しいSRTP暗号コンテキストを取得するために使用されます。 （実際の検索は、例えばMIKEYにSRTP実装からの明示的な要求により行うことができ、又は、「データベース」をアクセスSRTP実装によって、MIKEYによって維持。アプリケーションは、典型的には、実装が好ましいかを決定します。）
2. If an MKI is present in the SRTP packet, it is used to point to the correct key within the SA. Alternatively, if SRTP's <From, To> feature is used, the ROC||SEQ of the packet is used to determine the correct key.
MKIがSRTPパケットに存在している場合2.、SA内の正しい鍵を指すために使用されます。 SRTPの<から、ために>機能を使用する場合は別の方法として、パケットのROC ||配列は、正しいキーを決定するために使用されます。
3. Depending on whether the key sent in MIKEY (as obtained in step 2) was a TEK or a TGK, there are now two cases.
3. MIKEYで送信キー（ステップ2で得られた）TEK又はTGKであったかどうかに応じて、2つのケースが今あります。
- If the key obtained in step 2 is the TEK itself, it is used directly by SRTP as a master key.
- ステップ2で得られたキーがTEK自体である場合、それはマスターキーとしてSRTPにより直接使用されます。
- If the key instead is a TGK, the mapping with the CS_ID (internal to MIKEY, Section 6.1.1) allows MIKEY to compute the correct TEK from the TGK as described in Section 4.1 before SRTP uses it.
- キーが代わりTGK場合、CS_ID（MIKEY、セクション6.1.1に内蔵）とのマッピングは、セクション4.1で説明したようにSRTPがそれを使用する前に、MIKEYはTGKから正しいTEKを計算することを可能にします。
If multiple TGKs (or TEKs) are sent, it is RECOMMENDED that each TGK (or TEK) be associated with a distinct MKI. It is RECOMMENDED that the use of <From, To> in this scenario be limited to very simple cases, e.g., one stream only.
複数TGKs（またはのTEK）が送信される場合は、各TGK（またはTEK）が異なるMKIに関連付けられていることが推奨されます。このシナリオでは、<へ、から>の使用は、例えば、一つのストリームだけ、と非常に簡単な例を制限されることが推奨されています。
Besides the actual master key, other information in the Data SA (e.g., transform identifiers) will of course also be communicated from MIKEY to SRTP.
実際のマスターキー、データSA内の他の情報（例えば、識別子変換）に加えて、もちろん、MIKEYからSRTPに伝達されます。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Research 02420 Jorvas Finland
ヤリArkkoエリクソン研究02420 Jorvasフィンランド
Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com
電話番号：+358 40 5079256 Eメール：jari.arkko@ericsson.com
Elisabetta Carrara Ericsson Research SE-16480 Stockholm Sweden
エリザベッタカララエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 50877040 EMail: elisabetta.carrara@ericsson.com
電話：+46 8 50877040 Eメール：elisabetta.carrara@ericsson.com
Fredrik Lindholm Ericsson Research SE-16480 Stockholm Sweden
フレドリックリンドホルムエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 58531705 EMail: fredrik.lindholm@ericsson.com
電話：+46 8 58531705 Eメール：fredrik.lindholm@ericsson.com
Mats Naslund Ericsson Research SE-16480 Stockholm Sweden
マッツ・ナズランドエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 58533739 EMail: mats.naslund@ericsson.com
電話：+46 8 58533739 Eメール：mats.naslund@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
カールNorrmanエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 4044502 EMail: karl.norrman@ericsson.com
電話：+46 8 4044502 Eメール：karl.norrman@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。