[要約] RFC 3830は、MIKEY（Multimedia Internet KEYing）プロトコルに関する仕様であり、セキュアなマルチメディア通信のための鍵交換を提供します。その目的は、セキュリティとプライバシーを確保しながら、マルチメディア通信の鍵管理を効率的に行うことです。
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).
Copyright（c）The Internet Society（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がキーを輸送する1つのフィールド、「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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
Data Security Association（Data 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.
Cryptoセッション（CS）：セキュリティプロトコルの単一インスタンスによって保護されている単方方向データストリームまたは双方向データストリーム。たとえば、SRTPを使用する場合、Cryptoセッションには、RTPストリームと対応するRTCPの2つのストリームが含まれることがよくあります。どちらも単一のSRTP暗号化コンテキストによって保護されています。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.
Crypto Session Bundle（CSB）：1つ以上の暗号セッションのコレクション。これには、一般的なTGK（以下を参照）とセキュリティパラメーターを搭載できます。
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.
Cryptoセッションバンドル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 Generation Key（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.
Traffic-Incrypting Key（TEK）：CSを保護するためにセキュリティプロトコルで使用されるキー（このキーは、セキュリティプロトコルによって直接使用されるか、セキュリティプロトコルに応じてさらにキーを導出するために使用できます）。TEKはCSBのTGKに由来しています。
TGK re-keying: the process of re-negotiating/updating the TGK (and consequently future TEK(s)).
TGKの再キーイング：TGKを再交渉/更新するプロセス（およびその結果、将来のTEK）。
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の公開鍵[]オプションの情報{}は、ゼロ以上の発生を意味します||連結|または（選択オペレーター） ^ exponentiation 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高度な暗号化標準CMカウンターモード（[srtp]で定義されている）タイムトランスポートプロトコルRTSPリアルタイムストリーミングプロトコルSDPセッション説明プロトコルSIPセッション開始プロトコルSRTPセキュアRTP TEKトラフィックエンコートキーTGK TGK TEK GENERALキー
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では、マイキーが意図されている基本的なシナリオと設計目標について説明します。また、ソリューション全体の簡単な概要と、グループキー管理アーキテクチャ[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では、マイキーがグループシナリオでどのように使用されるかに焦点を当てています。
The Security Considerations section (Section 9), gives a deeper explanation of important security related topics.
セキュリティ上の考慮事項セクション（セクション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).
マイキーは、主にピアツーピア、シンプルな1対多、および小型（インタラクティブな）グループに使用することを目的としています。Mikeyを設計する際に考慮された主要なマルチメディアシナリオの1つは、ユーザーがリアルタイムで対話して通信できる会話型マルチメディアシナリオです。これらのシナリオでは、ピアがマルチメディアセッションが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) ピアツーピア（ユニキャスト）、たとえば、2つの当事者間の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対Many（マルチキャスト）、たとえば、リアルタイムプレゼンテーション、送信者がセキュリティのセットアップを担当します。
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つの基本モデルを使用できます。最初のモデルでは、グループのイニシエーターはグループサーバーとして機能します（そして、新しいメンバーを含めることが許可された唯一のものです）。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など）に「トンネル」/マイキーを統合する可能性。
* 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 Generation Key（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は、複数のセキュリティプロトコル（または同じセキュリティプロトコルのいくつかのインスタンス）のキーとパラメーターを同時に確立する可能性をサポートしています。Crypto Session Bundle（CSB）の概念は、共通のTGKとセキュリティパラメーターを持つことができるが、Mikeyから異なるTEKを取得できる1つ以上の暗号セッションのコレクションを示すために使用されます。
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のセットは、暗号セッションバンドルで合意されています（これは、3つの代替キートランスポート/交換メカニズムのいずれかによって行われます。セクション3を参照）。
2. The TGK(s) is used to derive (in a cryptographically secure way) a TEK for each Crypto Session.
2. TGKは、各暗号セッションの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は、現在のCryptoセッションバンドルでTeksとCryptoセッションを更新するために使用できます（セクション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）、受信者、および送信者です。
In MIKEY, the sender could act as GCKS and push keys down to the receiver(s).
マイキーでは、送信者は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).
以下のサブセクションは、TGKの輸送/確立の3つの異なる方法を定義します。事前に共有キー、パブリックキー暗号化、およびDiffie-Hellman（DH）キー交換を使用します。以下では、単純さのためにユニキャスト通信を想定しています。TGKに加えて、RANDを示すランダムな「ノンセ」も輸送されます。3つのケースすべてで、セクション4.1.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がレシピエントに（安全に）プッシュされます。diffie-hellmanメソッドでは、実際の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).
パブリックキー暗号化を使用して、スケーラブルなシステムを作成できます。このアプローチの不利な点は、事前に共有される重要なアプローチよりもリソースが消費されることです。もう1つの欠点は、ほとんどの場合、パブリックキーの分布を処理するためにPKI（公開キーインフラストラクチャ）が必要であることです。もちろん、パブリックキーを事前に共有キーとして使用することができます（たとえば、自己署名証明書を使用することで）。また、上記のように、この方法を使用して「キャッシュされた」対称キーを確立するために使用できることに注意してください。より効率的に）。
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.
一般に、diffie-hellman（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つの関係者が一意の予測不可能なランダムキーを生成することに注意してください。したがって、このDHメソッドを使用してグループTEKを確立することはできません（グループのさまざまな当事者が異なるTEKで終わるため）。このシナリオで作業する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 = Initiator、IDR = Responder）。ペイロード定義については、セクション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は、暗号化（ENCR_KEY）とMikeyメッセージの整合性保護（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つ以上のTGK（KEMACに運ばれる）と一連のセキュリティパラメーター（SPS）を安全な方法でレスポンダーに輸送することです。応答者からの検証メッセージはオプションであるため、イニシエーターはHDRで検証メッセージが必要かどうかを示します。
KEMAC = E(encr_key, {TGK}) || MAC
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は、Responderのメッセージ全体で計算されたMACであり、認証キーを使用して、Timestame（イニシエーターのメッセージに含まれているものと同じ）、および両当事者のIDです。検証MAC計算の正確な定義については、ペイロード定義についてはセクション6.9も参照してください。
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.
この方法を実装することは必須です。
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つ以上のTGKとセキュリティパラメーターのセットを安全な方法でレスポンダーに輸送することです。これは、TGKがランダムに選択された「エンベロープキー」から派生したキーを使用して暗号化（および整合性保護）されるエンベロープアプローチを使用して行われます。エンベロープキーは、レスポンダーの公開鍵で暗号化されたレスポンダーに送信されます。
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には、暗号化されたエンベロープキーが含まれています：pke = e（pkr、env_key）。Responderの公開キー（PKR）を使用して暗号化されています。応答者がいくつかのパブリックキーを持っている場合、イニシエーターはチャッシュペイロードで使用されるキーを示すことができます（セクション6.8を参照）。
The KEMAC contains a set of encrypted sub-payloads and a MAC:
Kemacには、暗号化されたサブペイロードのセットとMacが含まれています。
KEMAC = E(encr_key, IDi || {TGK}) || MAC
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です（証明書ではなく、一般に証明書で指定されたIDと同じID）。次のそれぞれのペイロード（TGK）には、イニシエーター（および可能な他の関連パラメーター、たとえば重要な寿命など）によってランダムかつ独立して選択されたTGKが含まれます。次に、暗号化された部品の後にMacが続き、Kemacペイロードで計算されます。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は、イニシエーターの署名キーを使用して、Mikeyメッセージ全体をカバーする署名です（正確な定義についてはセクション5.2も参照）。
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.
暗号化されたIDIが1つ、おそらく1つの暗号化されていないIDIがあることに注意してください。暗号化されたものは、特定の中間攻撃の対策として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.
エンベロープキーをキャッシュして、事前に共有キーとして使用できるようにすることができます。このキーが無期限にキャッシュされることはお勧めしません（ただし、これを決定するのはローカルポリシー次第です）。この関数は、新しい暗号セッションを追加する必要がある場合（または削除された期限が切れた場合）、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.
ClearText IDフィールドと証明書を含める必要がありますが、ピアがすでに相手のIDを知っているか、他の方法で証明書を取得できることが予想される場合に除外される場合があります。たとえば、これは、IDがSIPから抽出された場合に当てはまります。
For certificate handling, authorization, and policies, see Section 4.3.
証明書の処理、承認、およびポリシーについては、セクション4.3を参照してください。
It is MANDATORY to implement this method.
この方法を実装することは必須です。
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
imessage = hdr、to、rand、[idi | certi]、[idr] {sp}、dhi、sogni ---> _message = <--- hdr、t、[idr | certr]、idi、dhr、dhi、sightr
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は、イニシエーターの署名キーを使用して、イニシエーターのマイキーメッセージであるi_messageをカバーする署名です（正確な定義についてはセクション5.2を参照）。
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.
Responderのメッセージの主な目的は、安全な方法で、イニシエーターにResponderの値（DHR）G^（XR）を提供することです。ここで、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は、Responderの署名キーを使用して、ResponderのMikeyメッセージであるR_Messageをカバーする署名です（正確な定義についてはセクション5.2を参照）。
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.
このアプローチでは、設定前にイニシエーターがレスポンダーの証明書を所有する必要がないことに注意してください。代わりに、応答者が応答に署名証明書を含めるだけで十分です。
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（およびその他のパラメーター）のキートランスポートまたはキー交換に続いて、MikeyはデータSA識別子とデータSASのマッピングを維持します。質問、セクション4.4を参照してください。したがって、セキュリティプロトコルがデータSAを要求する場合、そのようなデータSA識別子を考慮して、最新のデータSAが取得されます。特に、正しいキーイング素材であるTek（S）を導き出す必要があるかもしれません。Tek（およびその他のキーイング素材）の派生はTGKから行われ、セクション4.1.3で説明されています。
Second, for use within MIKEY itself, two key management procedures are needed:
第二に、マイキー自体で使用するには、2つの重要な管理手順が必要です。
* 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.
これらの2つの重要な派生方法は、セクション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：Crypto Session Bundle ID（32ビットの非署名整数）CS_ID：Crypto Session ID（8ビットの非署名整数）RAND ：（少なくとも）128ビット（PSEUDO-）最初のイニシエーターが最初のイニシエーターが送信したランダムビットストリング両替。
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：derivation関数の入力キーinkey_len：入力キーラベルのビットの長さ：派生するキーのタイプ、rand、およびセッションIDS 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 = label、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については次のように値が指定されています。したがって、後でMikeyに追加された他のPRFが異なる入力パラメーターを指定する可能性があることに注意してください。
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:
以下の手順では、上記のP機能に基づいて、PRF（Inkey、Label）と記載されている擬似ランダム関数が、出力キーを計算するために適用されます。
* let n = inkey_len / 256, rounded up to the nearest integer if not already an integer
* n = inkey_len / 256とし、まだ整数でない場合は最寄りの整数に丸められます
* split the inkey into n blocks, inkey = s_1 || ... || s_n, where * all s_i, except possibly s_n, are 256 bits each
* inkeyをn blocks、inkey = s_1 ||に分割します... ||s_n、ここで *すべてのs_iは、おそらくs_nを除く、それぞれ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、label）= p（s_1、label、m）xor p（s_2、label、m）xor ... xor p（s_n、label、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識別子の正しいTGKへのマッピングは、セクション4.4に従ってすでに行われていると仮定します。
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からの認証と暗号化のキー派生をサポートしていない場合、0x2AD01C64をそれぞれ0x1B5C7973および0x15798CEFに置き換えることにより、セキュリティプロトコル用に個別の認証と暗号化キーを直接作成できます。） いずれの場合にも。
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.
これらの32ビット定数値（上記の表に記載）は、Eの10進数（つまり、2.7182 ...）から取得されていることに注意してください。各定数は9桁（例えば、最初の9桁718281828 = 718281828 =0x2AD01C64）。9桁の桁の文字列は、ランダムに選択されませんが、eの10進数桁からの連続した「チャンク」として選択されます。
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).
このセクションでは、マイキーのデフォルト変換を識別します。それぞれのケースで次の変換を実装およびサポートすることが必須です。将来、新しい変換を追加できます（さらにガイドラインについては、セクション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を実装することが必須です。他のPRFは、Mikey内でのPRF構造とその正確な使用を指定する標準トラック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
デフォルトおよび補充から実装のキー輸送暗号化は、[srtp]で定義されているように、セクション4.1.4で導出された128ビットキー、srtp_prefix_lengthにゼロに設定され、初期化ベクトルを使用して、カウンターモードのAESです。
IV = (S XOR (0x0000 || CSB ID || T)) || 0x0000,
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のようにも導出され、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].
注：これにより、2^23ビットに暗号化できる最大サイズが制限されますが、これはすべての実用的な目的で十分です[SRTP]。
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シナリオです。このシナリオでは、Mikeyは、SIPのセキュリティに依存している間、事前共有キーメソッド、ヌル暗号化、およびヌル認証アルゴリズム（セクション4.2.4を参照）で使用できます。このオプションを注意して使用してください！
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 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は、HMACによってSHA-1を含む必須実装方法として生成された160ビット認証タグを使用します。[HMAC]を参照してください。認証キーは、セクション4.1.4に従って導出されます。認証キーサイズは、ハッシュ関数の出力のサイズに等しくなければならないことに注意してください（たとえば、HMAC-SHA-1の場合、160ビット認証キーが使用されます）[HMAC]。
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シナリオです。このシナリオでは、Mikeyは、SIPのセキュリティに依存している間、事前共有キーメソッドとヌル暗号化と認証アルゴリズムで使用できます。このオプションを注意して使用してください！
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 Key Exchangeは、サポートされると、Oakley 5 [Oakley]を必須の実装として使用します。Oakley 1とOakley 2の両方を使用できます（ただし、これらはオプションの実装です）。
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]、つまり1900年1月1日の0Hに比べて秒単位で64ビットの数字で定義されています。年。時間を常に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つの異なるパラメーターセットがあります。1つ目はマイキー変換のセット（交換自体に必要）で、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も参照）に登録することにより追加されます。。既に標準化されたハッシュ関数を追加する場合、使用するために既に指定されたドキュメントを指定するだけで十分な場合があります。
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]で使用されるのと同じ形式を使用することをお勧めします）。そのようなグループがマイキーで使用されるために、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:
* 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.
* 通常、イニシエーターは、最初のメッセージを送信するために応答者の証明書を見つける必要があります。イニシエーターがResponderの証明書をまだ持っていない場合、これには中央ディレクトリエージェントへの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.
* イニシエーターが独自の証明書を省略し、他の手段を使用してこの証明書を取得するレスポンダーに依存することが可能になります。ただし、レスポンダーが以前の接続から証明書をキャッシュしたことを期待するのが合理的な場合にのみ、これを行うことをお勧めします。それ以外の場合、証明書にアクセスすることは、レスポンダーのための追加の往復を意味します。
* 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.
* 証明書取消リスト（CRLS）[X.509]またはOCSP [OCSP]などのプロトコルを使用した証明書の検証が必要になる場合があります。Mikey Exchangeのすべての当事者には、そのようなチェックが行われるかどうか、どのように作成されるか、どのくらいの頻度で作られるかを決定するローカルポリシーが必要です。チェックを実行すると、追加のメッセージングが意味する場合があることに注意してください。
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.
場合によっては、これをパブリックキーで使用することもできます。たとえば、2つのピアがオフラインでキーを交換し、マイキーを実行する目的で使用するように構成する場合。
* 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プロトコルのすべての参加者は、1つ以上の信頼できるルーツを構成する必要があります。参加者は、証明書チェーンの検証を実行することもでき、おそらく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.
これらの承認ポリシーは、セクション2.1のMikeyシナリオA-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からデータ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]を参照）は、データSAの取得に使用されるパラメーターの1つです（MKIを使用して、データSAに使用されるTGK/TEKを示すことができます）。ただし、SSRCは十分ではありません。MikeyからのデータSAの取得については、Mikeyの実装がSSRCと一緒に宛先ネットワークアドレスとポートを使用したルックアップをサポートすることをお勧めします。Mikeyはネットワークアドレスやポートを送信しないことに注意してください。この理由の1つは、事前に知られていない可能性があることです。また、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は、CSBを更新する手段を提供します（たとえば、新しいTGK/TEKの輸送やCSBへの新しい暗号セッションの追加）。CSBの更新は、たとえば、TEKの有効期限が切れる前、またはCSBに新しい暗号セッションが追加されたときに、Mikeyを再度実行することによって行われます。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).
CSBを更新するためにMikeyが再度実行された場合、例えば、静的またはオプションの含まれるすべてのペイロードを除外することができる場合、最初の交換で提供された証明書やその他の情報を含める必要はありません（図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を使用する必要がありますが、新しいタイムスタンプを使用する必要があります。新しいランドをメッセージ交換に含めてはなりません（ランドは最初の交換でのみ効果があります）。必要に応じて、更新メッセージに新しい暗号セッションが追加されます。Mikey Updateメッセージには、新しいキーイング素材（新しいTGKなど）を含める必要がないことに注意してください。この場合、Cryptoセッションは、新しい情報を更新しながら、以前に確立されたキーイング素材を引き続き使用しています。
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は、オプションのパーツを含む送信できる更新メッセージを視覚化します。元のメッセージとの主な違いは、TGK（またはDHメソッドにDH値）を含めることがオプションであることです。特定の方法の詳細については、セクション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にはいくつかのCSSを含めることができます。その後発生する可能性のある問題は、SPI（または[SRTP]のMKIなど）が使用されていない場合にTGKを再染色することです。したがって、複数の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
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.
DHメソッドの場合、イニシエーターにDHIペイロードが含まれている場合、レスポンダーにはDHRとDHIを含める必要があることに注意してください。イニシエーターにDHIが含まれていない場合、レスポンダーには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.
イニシエーターは、使用するセキュリティポリシーを示します（つまり、セキュリティプロトコルアルゴリズムの観点から）。レスポンダーがそれをサポートしていない場合（何らかの理由で）、レスポンダーはエラーメッセージ（パラメーターをサポートしていないことを示す）とともに一緒にできます。独自の機能（交渉）を送り返して、イニシエーターにパラメーターの共通セットを選択させることができます。これは、応答して送信されたエラーメッセージに1つ以上のセキュリティポリシーペイロードを含めることによって行われます（セクション5.1.2を参照）。応答で複数の属性を順番に提供できます。これは、可能な限り往復の数を減らすために行われます（つまり、ほとんどの場合、ポリシーが初めて受け入れられる場合、1つの往復で十分です）。レスポンダーがオファーを受け入れない場合、イニシエーターは新しいマイキーメッセージで外出する必要があります。
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.
レスポンダーがセキュリティを提供することができない/能力がない場合、または当事者が単に同意できない場合、それは当事者の政策次第です。たとえば、不安定なコミュニケーションを受け入れるか拒否します。
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).
Responderがイニシエーターによって提案されたパラメーターのセットをサポートしていない場合、エラーメッセージにはサポートされたパラメーターを含める必要があります（セクション5.1.1も参照）。
The error message is formed as:
エラーメッセージは次のように形成されます。
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。マイキーペイロードメッセージの例。ペイロードはバイトアライメントされており、32ビットアラインされていないことに注意してください。
The process of generating a MIKEY message consists of the following steps:
マイキーメッセージを生成するプロセスは、次の手順で構成されています。
* 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).
* マイキーメッセージの必要なペイロードを連結します（含まれる可能性のあるペイロードの交換定義と推奨順序を参照）。
* 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/Signatureフィールドを除き、MAKEYメッセージ全体でMac/署名を計算し、フィールドにMac/署名を追加します。確認メッセージの場合、ID_I ||ID_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.
公開キーの場合、キーデータトランスポートペイロードは、IDIをTGKと連結することにより生成されます。これは、暗号化され、データフィールドに配置されます。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.
イニシエーターからのすべてのメッセージは、一意のタイムスタンプを使用する必要があることに注意してください。レスポンダーは新しいタイムスタンプを作成しませんが、イニシエーターが使用するタイムスタンプを使用します。
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:
一般に、マイキーメッセージの解析は、ペイロードによってペイロードを抽出し、エラーが発生しないことを確認することによって行われます。正確な手順は実装固有です。ただし、応答者の場合は、次の手順に従うことをお勧めします。
* 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.
* 認証が成功しない場合、AUTH障害エラーメッセージがイニシエーターに送信される場合があります。メッセージは、さらなる処理から破棄されます。エラーの治療については、セクション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は、リプレイ処理にチャレンジ応答メカニズムを使用していません。代わりに、タイムスタンプが使用されます。これには、クロックが同期される必要があります。必要な同期は、キャッシュできるメッセージの数に依存します（ただし、リプレイキャッシュには正常に認証されたメッセージのみが含まれていることに注意してください）。無制限のキャッシュを引き受けることができれば、端子をまったく同期する必要はありません（キャッシュに以前のすべてのメッセージが含まれる可能性があるため）。ただし、リプレイキャッシュのサイズに制限がある場合、クロックはある程度同期する必要があります。要するに、一般に、それはリプレイキャッシュのサイズと必要な同期の間のトレードオフであると言うことができます。
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).
* 各レスポンダーは、許容時計スキュー（ローカルポリシーによって設定されている）内で提示された正常に認証されたメッセージを覚えておくために、リプレイキャッシュを使用します。
* 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.
一般に、クライアントは非常に高い負荷の受信メッセージを期待していない場合があり、したがって、緩みの程度が数分から数時間の順になることを許可する場合があります。A（d）DOS攻撃が起動し、リプレイキャッシュが大きくなりすぎると、マイキーは再生キャッシュが管理可能になるように動的にゆるく低下する可能性があります。ただし、そのような（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を費やすことができると仮定します。さらに、受信する認証されたメッセージごとに30バイトを保存する必要があると仮定します（メッセージのハッシュは20バイトです）。これは、約204のメッセージをキャッシュすることが可能であることを意味します。1分あたりのメッセージ数を推定できる場合、クロックスキューを簡単に計算できます。たとえば、クライアントが予想されるSIPシナリオでは、最も極端な場合には、1分あたり10通の通話を受けるために、必要な時計スキューは約20分です。それほど極端ではない環境では、5分ごとに着信コールが予想される可能性があります。
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.
入ってくるメッセージの最大数が1分あたり120のメッセージのオーダーにあると想定される非常に極端なケースと、クロックスキューが10分程度であるという要件を考慮してください。
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.
したがって、必要なクロックスキューは、マイキーが使用される設定に大きく依存することに注意することができます。1つの推奨事項は、リプレイキャッシュのサイズを修正し、クロックスキューを大きくすることです（最初のクロックスキューは、使用されているアプリケーションに応じて設定できます）。リプレイキャッシュが成長すると、使用済みのリプレイキャッシュの割合に応じて、クロックスキューが減少します。これはローカルで処理されていることに注意してください。これは、ピアとの相互作用を必要としません（ピアに間接的に影響を与える可能性がありますが）。ただし、そのような機能を正確に実装する方法は、このドキュメントの範囲外であり、実装固有のものと見なされます。
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攻撃は、攻撃者がピアにメッセージを送信するCPU DOS攻撃であり、その後、着信メッセージのMac/署名を確認するためにリソースを消費する必要があります。
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]のサポートが定義されていることに注意してください。これは、さまざまなペイロードとフィールドの目的をよりよく理解するのに役立ちます。他のセキュリティプロトコルは、Mikey内で使用するために指定される場合があります。セクション10を参照してください。
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ビット）：マイキーのバージョン番号。
version = 0x01 refers to MIKEY as defined in this document.
バージョン= 0x01は、このドキュメントで定義されているマイキーを指します。
* 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
* 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は、各イニシエーターレスポンダーペアの間で一意でなければなりません。つまり、グローバルに一意ではありません。イニシエーターは、IDを選択するときに衝突をチェックする必要があります（イニシエーターがすでに1つ以上の確立されたCSBをレスポンダーに持っている場合）。応答者は、応答で同じ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 CSSを使用することは可能ですが、CSBにこの多くのCSSが含まれる可能性は低いことに注意してください。整数0は、CSが含まれていないと解釈されます。これは、初期セットアップメッセージの場合になる場合があります。
* 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ビット）：ITH SRTPストリームに使用する必要があるSSRCを指定します。SSRCを選択するのは、ストリームの送信者であることに注意してください。したがって、Mikeyのイニシエーターがすべてのフィールドに記入できない可能性があります。この場合、イニシエーターによって選択されていないSSRCはゼロに設定され、応答メッセージのこれらのフィールドにレスポンダーが記入されます。SRTPは、SSRCの一意性に関する要件を指定していることに注意してください（同じTEKが複数のストリームに使用される場合、2回のPAD問題を回避するため）[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を使用したストリームには、no i（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つ以上のキーデータペイロードが含まれる場合があります。最後のキーデータペイロードには、最後のペイロードに次のペイロードフィールドが設定されています。更新メッセージ（セクション4.5も参照）の場合、キーデータサブペイロードをスキップすることができます（これにより、ENCRデータレンが0に等しくなります）。
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ペイロードを最初のペイロードとして追加することによって行われ、その後、キーデータサブペイロードが続きます。更新メッセージの場合、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).
Public-Keyの場合、Macフィールドのカバレッジは、事前に共有された場合のように、完全なマイキーメッセージの代わりに、キーデータトランスポートペイロードのみを超えています。したがって、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データレン（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).
* データレン（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がサポートされていることを条件としていることに注意してください。
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-GROUP（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).
* 署名レン（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-Value（変数長）：指定された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.
証明書のペイロードには、提供された証明書の指標と証明書データが含まれています。証明書チェーンを提供する場合、チェーン内の各証明書は別の証明書ペイロードに含める必要があります。
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.
* CERTタイプ（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/CERT 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.
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 ! 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).
* ハッシュファンク（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).
VER MSGペイロードには、恥ずかしさキーとパブリックキー輸送方法の計算された検証メッセージが含まれています。Macは、IDSとタイムスタンプだけでなく、Mikeyメッセージ全体で計算されていることに注意してください（セクション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.
* AUTH ALG（8ビット）：検証メッセージに使用されるMACアルゴリズムを指定します。定義された値については、セクション6.2を参照してください。
* Ver data (variable length): the verification message data. The length is implicit from the authentication algorithm used.
* Verデータ（変数長）：検証メッセージデータ。長さは、使用される認証アルゴリズムから暗黙的です。
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ビット）：各セキュリティポリシーのペイロードには、地元のピアによる現在のマイキーセッションの明確な番号を指定する必要があります。この番号は、暗号セッションを特定のポリシーにマッピングするために使用されます（セクション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.
* ポリシーパラメーション長（16ビット）：特定のセキュリティプロトコルのポリシーパラメーターの総長さを定義します。
* Policy param (variable length): defines the policy for the specific security protocol.
* ポリシーパラマ（変数長）：特定のセキュリティプロトコルのポリシーを定義します。
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.
ポリシーパラメーションの部分は、タイプ/長さ/値フィールドのセットによって構築されます。各セキュリティプロトコルについて、交渉できる一連の可能なタイプ/値が定義されます。
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.
* ランドレン（8ビット）：ランドの長さ（バイト単位）。少なくとも16でなければなりません。
* RAND (variable length): a (pseudo-)randomly chosen bit-string.
* rand（変数長）：a（pseudo-）ランダムに選択されたビットストリング。
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.
主要なデータペイロードには、TGK、たとえば重要な資料が含まれています。キーデータペイロードは明確に含まれることはありませんが、キーデータトランスポートペイロードの暗号化された部分として含まれます。
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.
（TGKを使用する代わりに）TEKを含める可能性が提供されることに注意してください。直接送信すると、TEKは通常、複数の暗号セッション間で共有できません（セキュリティプロトコルがこれを許可しない限り、[SRTP]など）。TGKの代わりにTEKを送信することを推奨する使用は、事前に暗号化された材料が存在する場合、したがって、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ビット）：指定されたキー妥当性期間のタイプを示します。これは、SPI（または[srtp]の場合はMKI）を使用するか、キーが有効な間隔を提供することによって行われます（例：後者の場合、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).
* キーデータレン（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.
* ソルトレン（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).
主要な有効性データは、スタンドアロンのペイロードではなく、主要なデータペイロード（セクション6.13を参照）またはDHペイロード（セクション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ストリームが同じキーを共有している場合、キーアップデート/再キーイングが必要である場合、これはFROM-To-Toメソッドではなく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.
一般的な拡張機能のペイロードは、毎回完全に新しいペイロードを定義する必要なく、マイキーに可能な拡張機能を可能にするために含まれています。このペイロードは、任意のマイキーメッセージで使用でき、認証/署名されたデータパーツの一部です。
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]で定義されています。マイキーは他の輸送を使用する場合があります。その場合、マイキーがそのような輸送プロトコルを介してどのように輸送されるかを定義する必要があります。
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。マイキーの焦点のシナリオについて説明します。このセクションでは、マイキーがグループシナリオでどのように使用されるかについて説明します（ただし、認可に関連する問題については、セクション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のイニシエーターとして機能します。このシナリオでは、すべてのクライアントに同じTGKを輸送する際に、事前に共有キーまたは公開キーの輸送メカニズムが適切です（グループの共通のTEKになります）。
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を使用する必要がある場合、ストリーミングサーバーはすべてのグループメンバーにセッションに対して同じCSB_IDとCS_ID（S）を指定する必要があります。
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.
概要セクションで説明されているように、小型のインタラクティブなグループの場合、各クライアントが発信ストリームのセキュリティをセットアップするために担当することを期待する場合があります。これらのシナリオでは、事前に共有キーまたはパブリックキー輸送方法が使用されます。
++++ ++++
|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が使用されます。各クライアントは、発信ストリームのセキュリティを他のクライアントに設定します。
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.
単純な1対多くのケースについては、ストリーミングクライアントは、同じTGK/TEKがすべてのグループメンバーに使用される場合、その発信セッションに対して同じCSB_IDとCS_ID（S）を指定します。
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].
タイムスタンプ/カウンターと1つのラウンドトリップのキートランスポートに基づく主要な管理プロトコルは、以前に標準化されています。たとえば、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ビットが実用的な選択）とキートランスポートを選択する必要があります。同等の保護を提供するメカニズム、たとえば、128ビットTGKを備えたマイキーの事前共有キートランスポート、または1024ビットキーを備えたRSA（[LV]によると、ある程度のマージンで目的の96ビットレベルに対応します）。
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].
さらに、TGKがランダム（または擬似ランダム）でない場合、ブルートフォース検索が促進される可能性があり、再び有効なキーサイズを削減します。したがって、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がデフォルトのものです。一般に、ハッシュサイズは「セキュリティレベル」の2倍である必要があり、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]で使用されているものの単純化されたバージョンです。ここでは、1つのハッシュ関数のみが使用されますが、TLSは2つの異なる関数を使用します。この選択は、SHA-1ハッシュ関数に対する高い信頼性と、設計の効率とシンプルさ（複雑さはセキュリティを意味するものではありません）によって動機付けられています。実際、[DBJ]に示されているように、2つのハッシュのうちの1つがひどく壊れている場合、TLS PRFは、マイキーで行われるように、キー全体で1つのハッシュが使用されていたかのように、実際には安全性が低くなります。
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メソッドを使用する必要があります。diffie-hellmanメソッドの認証（署名など）は、中間の攻撃を防ぐために必要です。
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を妥協しません。Diffie-Hellmanモードは、いわゆるPerfect Forward Secrecy（PFS）をサポートする唯一のユーザーであるため、慎重なユーザーが考慮することができます。これは、過去からの将来のセッションと記録されたセッションも損なわれる、恥ずかしさキー（または公開キーモードの秘密の鍵）の妥協とは対照的です。
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）の使用は、オフラインの事前コンピューション攻撃に対抗するために最も重要です。ただし、更新メッセージは古いランドを再利用することに注意してください。これは、TGKとRANDが各Nビットの長さであると仮定して、Kの連続したキーアップデートの総有効キーエントロピー（プレコンピューション攻撃と比較して）は、l = n*（k 1）/2ビットであると仮定することを意味します。n*kビットの理論的最大値。言い換えれば、2^lの作業努力により、攻撃者はすべてのk nビットキーを取得できるようになります。これは、ブルートフォースよりも優れています（k = 1を除く）。これは欠陥のように思えるかもしれませんが、最初にnを適切に選択するためには、攻撃の2^lの複雑さは手の届かないところにあることに注意してください。さらに、1つの攻撃で複数のキーを損なう可能性があるという事実は、キー交換の問題に固有のものです。たとえば、固定された1024ビットRSAキーを使用して、公開キーの1年または2年の寿命の間にキーを交換して通信するユーザーを検討してください。この単一の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.
Mikeyの事前定義されたすべての変換は、大量の公的評価を受けた最先端のアルゴリズムを使用しています。SRTP [SRTP]からAES-CMを使用する理由の1つは、異なる暗号化モードとアルゴリズムの総数を制限し、同時に高レベルのセキュリティを提供する可能性があることです。
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）の寿命が指定されていなくても、基礎となるセキュリティプロトコルの暗号化変換が、ある程度の暗号化されたデータの後に何らかの形で退化できることを考慮する必要があります。ここで、普遍的に適用可能な一般的な主要な生涯の境界を述べることは不可能です。各セキュリティプロトコルは、このような最大額を定義し、キーの「疲労」の前に再キーキング手順をトリガーする必要があります。たとえば、SRTP [SRTP]によると、TEKは、対応する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ビットフィードバックを備えたOFB）、暗号ストリームでの縮退挙動は、おそらく有用です攻撃者は、合計で約2^（b/2）暗号化されたBビットブロック（ランダムIVを使用）の後に発生すると予想される（一定の確率で）。セキュリティマージンの場合、上記のバウンドと比較して、再キーイングをかなり前にトリガーする必要があります。詳細については、[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つの往復（つまり、2つのメッセージ）を許可するように選択されていますが、合理的なリプレイ保護を提供しています。（安全な）チャレンジ応答ベースのバージョンには、少なくとも3つのメッセージが必要です。マイキーでのタイムスタンプとリプレイの処理の詳細な説明については、セクション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.
ユーザーのプライバシーは複雑な問題であり、ある程度暗号化メカニズムによって実施される可能性がありますが、政策執行やその他のさまざまな機能も必要です。プライバシーの特定の側面の1つは、ユーザーID保護です。ただし、アイデンティティ保護はマイキーの主要な設計目標ではありませんでした。このような機能は、プロトコルにより複雑さを増したため、含まれるように選択されませんでした。とにかくマイキーは、たとえばSIPを輸送することが提案されているため、これによって身元が暴露される可能性があります。ただし、輸送プロトコルが保護され、アイデンティティ保護も提供される場合、マイキーは同じ機能を継承する可能性があります。これがどのように行われるべきかは、将来の研究のためです。
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]).
このプロトコルは、レスポンダーがイニシエーターを認証する前に（主要な管理プロトコルレベルで）状態を構築しないという意味で、サービス拒否攻撃に耐性があります。ただし、このプロトコルは、他の多くのプロトコルと同様に、スプーフィングされたIPアドレスを使用して多数の偽リクエストを作成する攻撃に対して開かれています。これは、たとえば、Mikeyを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.
セッションの確立プロトコルが安全でない場合、セキュリティされたメディアストリームに間接的なセキュリティに影響を与える攻撃がある可能性があることに注意する必要があります。ただし、これはグループにのみ適用されます（マイキーに固有のものではありません）。脅威は、あるグループメンバーがあるグループメンバーから別のグループにストリームを再ダイレクトできることです。これは、メンバーが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].
このドキュメントでは、マイキーペイロードに関連付けられたいくつかの新しい名前スペースを定義します。このセクションでは、値の割り当てを管理するようにIANAが要求される名前スペースをまとめたものです。IANAは、各名前空間の指定されたセクションで定義された事前定義された値を記録するように要求されます。IANAは、将来の追加値の定義を管理することも要求されています。明示的に特に述べられていない限り、各名前スペースの範囲0-240の値は、[RFC2434]によると、IETFコンセンサスのプロセスと範囲の範囲241-255の値によって承認される必要があります。
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〜127の間で、0〜111の間の値はIETFコンセンサスのプロセスによって承認されるべきであり、112-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) The name spaces for the following fields in the Envelope data payload (from Section 6.3) are requested to be managed by IANA:
* Mac Alg（表6.2.b）エンベロープデータペイロード（セクション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:
DHデータペイロード（セクション6.4から）の次のフィールドの名前スペースは、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:
CERTハッシュペイロード（セクション6.8から）の次のフィールドの名前スペースは、IANAによって管理されるように要求されます。
* Hash func (Table 6.8)
* ハッシュファン（表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）。この名前のスペースは0〜16の間で、IETFコンセンサスのプロセスによって承認される必要があります。
* 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）。この名前のスペースは0〜16の間で、IETFコンセンサスのプロセスによって承認される必要があります。
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:
このセクションでは、アプリケーション/マイキーマイムメディアタイプを登録するための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必要なパラメーター：なしオプションパラメーター：バージョンバージョン：囲まれたメッセージの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.
著者は、マーク・ボーアー、ラン・カネッティ、マーティン・ユーッフェナー、ステフェン・フライス、ピーター・バラニー、ラス・ヒューズリー、パシー・アホネン（彼のグループ）、ロルフ・ブロム、マグナス・ウェスターランド、ヨハン・ビリエン、ジョン・オロフ・ヴァトン、エリック・エリアソン、、Gerhard Strangarの貴重なフィードバックについて。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「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] Orman、H。、「The Oakley Key Deicination Protocol」、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 Laboratories、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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 Pub 180-1：Secure Hash Standard、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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Realtime Transport Protocol」、RFC 3711、2004年3月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI] Berners-Lee、T.、Fielding、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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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、「Advanced Encryption Standard（AES）Key Lap Algorithm」、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] Canetti、R。およびH. Krawczyk、「キー交換プロトコルの分析と安全なチャネルの構築に使用する」、Eurocrypt 2001、LNCS 2054、pp。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] Bellare、M.、Desai、A.、Jokipii、E。、およびP. Rogaway、「対称暗号化の具体分析：DESモードの分析」、コンピューターの基礎に関する第38回シンポジウムの議事録におけるScience、IEEE、1997、pp。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-Randomness Primitivesの実用的な構築と分析」、Asiacrypt 2001の議事録、LNCS。Vol 2248、pp。442-459、2001。
[DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of MD5", Contribution to ANSI X9F1 WG, 2001.
[DBJ] Johnson、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パブ）140-2、2002年12月。
[GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Group Key Management Architecture", Work in Progress.
[Gkmarch] Baugher、M.、Canetti、R.、Dondeti、L。、およびF. Lindholm、「Group Key Management Architecture」、作業進行中。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[Gdoi] Baugher、M.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、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] Harney、H.、Colegrove、A.、Harder、E.、Meth、U。、およびR. Fleischer、「Group Secure Association Key Management Protocol」、作業進行中。
[HAC] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC press, 1996.
[HAC] Menezes、A.、Van Oorschot、P。、およびS. Vanstone、「Handbook of Applied Cryptography」、CRC Press、1996。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「SDPおよびRTSPの主要な管理拡張機能」、進行中の作業。
[LOA] Burrows, Abadi, and Needham, "A logic of authentication", ACM Transactions on Computer Systems 8 No.1 (Feb. 1990), 18-36.
[LOA] Burrows、Abadi、およびNeedham、「認証の論理」、コンピューターシステムのACMトランザクション8 No.1（1990年2月）、18-36。
[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] Mills、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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S。、およびC. Adams、「X.509インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル」、RFC 2560、1999年6月。
[RAND] Eastlake, 3rd, D., Crocker, S., and J. Schiller, "Randomness Requirements for Security", RFC 1750, December 1994.
[Rand] Eastlake、3rd、D.、Crocker、S。、およびJ. Schiller、「セキュリティのランダム性要件」、RFC 1750、1994年12月。
[RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RTSP] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP] Handley、M。and 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、「SHA-256、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIATION Protocol」、RFC 3261、2002年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「TLSプロトコル -バージョン1.0」、RFC 2246、1999年1月。
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の用語は、Mikeyがより一般的である必要があり、SRTPのみに厳しいものである必要があるため、SRTPで使用されている用語とは異なります。したがって、マイキーで生成されたキーとパラメーターと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はMKIを使用してTEKまたはTGKにインデックスを付けます（TEKは、対応するMKIに関連するTGKから派生します）。以下を参照してください。
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.)
1. SRTPパケットが受信機に到着して処理されると、トリプル<SSRC、宛先アドレス、宛先ポート>がパケットから抽出され、正しいSRTP暗号コンテキスト、したがってデータSAを取得するために使用されます。（たとえば、実際の検索は、SRTP実装からMikeyへの明示的な要求、またはMikeyが維持する「データベース」にアクセスするSRTP実装によって実行できます。通常、アプリケーションはどの実装が優先されるかを決定します。）
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.
2. MKIがSRTPパケットに存在する場合、SA内の正しいキーを指すために使用されます。または、srtpの<from、>機能を使用する場合、パケットのROC || seqを使用して正しいキーを決定します。
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. マイキーで送信されたキー（ステップ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）のマッピングにより、SRTPが使用する前にセクション4.1で説明されているように、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.
複数のTGK（またはTEK）が送信される場合、各TGK（またはTEK）を異なるMKIに関連付けることをお勧めします。このシナリオでの<from、>の使用は、非常に単純なケース、たとえば1つのストリームのみに限定されることをお勧めします。
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
Jari Arkko Ericsson Research 02420 Jorvas Finland
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Elisabetta Carrara Ericsson Research SE-16480 Stockholm Sweden
エリザベッタ・カララ・エリクソン・リサーチSE-16480ストックホルム・スウェーデン
Phone: +46 8 50877040
EMail: elisabetta.carrara@ericsson.com
Fredrik Lindholm Ericsson Research SE-16480 Stockholm Sweden
Fredrik Lindholm Ericsson Research SE-16480ストックホルムスウェーデン
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.com
Mats Naslund Ericsson Research SE-16480 Stockholm Sweden
MATS Naslund Ericsson Research SE-16480 Stockholm Sweden
Phone: +46 8 58533739
EMail: mats.naslund@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
Karl Norrman Ericsson Research SE-16480ストックホルムスウェーデン
Phone: +46 8 4044502
EMail: 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.
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を免除します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。