[要約] 要約：RFC 5197は、Multimedia Internet KEYing（MIKEY）のさまざまなモードと拡張機能の適用可能性について説明しています。 目的：このRFCの目的は、MIKEYプロトコルの異なるモードと拡張機能の適用範囲を明確にし、その利点と制約を示すことです。
Network Working Group S. Fries
Request for Comments: 5197 Siemens
Category: Informational D. Ignjatic
Polycom
June 2008
On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions
さまざまなマルチメディアインターネットキーイング（Mikey）モードと拡張機能の適用性について
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for real-time applications. In particular, it has been defined focusing on the support of the Secure Real-time Transport Protocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements.
Multimedia Internet Keying（Mikey）は、リアルタイムアプリケーションに使用できる重要な管理プロトコルです。特に、安全なリアルタイム輸送プロトコル（SRTP）のサポートに焦点を当てて定義されています。Mikey自体はRFC 3830内で標準化されており、4つの重要な分布方法を定義しています。さらに、プロトコルの拡張を許可するように定義されています。Mikeyがますます受け入れられると、特に追加の主要な分布方法の観点から、ペイロード強化の観点からも、基本プロトコルの拡張が生じます。
This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session Description Protocol (SDP) answer, forking, and shared key conferencing.
このドキュメントでは、一般的なマイキーベースドキュメントに関する概要と、定義されている、または定義のプロセスにあるマイキーの既存の拡張機能について説明します。これは、開発者または建築家が、ユースケースのシナリオと動機、およびさまざまな主要な配布スキームの利点と欠点についてより多くの洞察を提供するための追加の情報源として意図されています。このドキュメントで説明されているユースケースは、セッションの説明プロトコル（SDP）の回答、フォーキング、および共有された主要会議の前にメディアの中で、主要な管理に課題を提供する専用のSIPコールシナリオに強く関連しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
3. MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Pre-Shared Key (PSK) Protected Distribution . . . . . . . 9
3.2. Public Key Encrypted Key Distribution . . . . . . . . . . 9
3.3. Diffie-Hellman Key Agreement Protected with Digital
Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Unprotected Key Distribution . . . . . . . . . . . . . . . 11
3.5. Diffie-Hellman Key Agreement Protected with Pre-Shared
Secrets . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. SAML-Assisted DH key Agreement . . . . . . . . . . . . . . 12
3.7. Asymmetric Key Distribution with In-Band Certificate
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Further MIKEY Extensions . . . . . . . . . . . . . . . . . . . 16
4.1. ECC Algorithms Support . . . . . . . . . . . . . . . . . . 16
4.1.1. Elliptic Curve Integrated Encryption Scheme
application in MIKEY . . . . . . . . . . . . . . . . . 17
4.1.2. Elliptic Curve Menezes-Qu-Vanstone Scheme
Application in MIKEY . . . . . . . . . . . . . . . . . 17
4.2. New MIKEY Payload for Bootstrapping TESLA . . . . . . . . 17
4.3. MBMS Extensions to the Key ID Information Type . . . . . . 18
4.4. OMA BCAST MIKEY General Extension Payload Specification . 18
4.5. Supporting Integrity Transform Carrying the Rollover
Counter . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Selection and Interworking of MIKEY Modes . . . . . . . . . . 19
5.1. MIKEY and Early Media . . . . . . . . . . . . . . . . . . 21
5.2. MIKEY and Forking . . . . . . . . . . . . . . . . . . . . 22
5.3. MIKEY and Call Transfer/Redirect/Retarget . . . . . . . . 23
5.4. MIKEY and Shared Key Conferencing . . . . . . . . . . . . 23
5.5. MIKEY Mode Summary . . . . . . . . . . . . . . . . . . . . 24
6. Transport of MIKEY Messages . . . . . . . . . . . . . . . . . 24
7. MIKEY Alternatives for SRTP Security Parameter Negotiation . . 25
8. Summary of MIKEY-Related IANA Registrations . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Key distribution describes the process of delivering cryptographic keys to the required parties. MIKEY [RFC3830], the Multimedia Internet Keying, has been defined focusing on support for the establishment of security context for the Secure Real-time Transport Protocol [RFC3711]. Note that RFC 3830 is not restricted to be used for SRTP only, as it features a generic approach and allows for extensions to the key distribution schemes. Thus, it may also be used for security parameter negotiation for other protocols.
For MIKEY, meanwhile, seven key distribution methods are described:
一方、マイキーの場合、7つの重要な分布方法について説明します。
o Symmetric key distribution as defined in [RFC3830] (MIKEY-PSK)
o [RFC3830]で定義されている対称キー分布（Mikey-PSK）
o Asymmetric key distribution as defined in [RFC3830] (MIKEY-RSA)
o [RFC3830]で定義されている非対称キー分布（Mikey-RSA）
o Diffie-Hellman key agreement protected by digital signatures as defined in [RFC3830] (MIKEY-DHSIGN)
o [RFC3830]で定義されているように、デジタル署名によって保護されているdiffie-hellmanキー契約（mikey-dhsign）
o Unprotected key distribution (MIKEY-NULL)
o 保護されていないキーディストリビューション（Mikey-Null）
o Diffie-Hellman key agreement protected by symmetric pre-shared keys as defined in [RFC4650] (MIKEY-DHHMAC)
o [RFC4650]（Mikey-DHHMAC）で定義されている対称的な事前共有キーによって保護されているDiffie-Hellmanキー契約
o Security Assertion Markup Language (SAML) assisted Diffie-Hellman key agreement as defined (not available as a separate document, but discussions are reflected within this document (MIKEY-DHSAML))
o セキュリティアサーションマークアップ言語（SAML）は、定義されたDiffie-Hellmanキー契約を支援しました（別のドキュメントとして利用できませんが、このドキュメントには議論が反映されています（mikey-dhsaml））
o Asymmetric key distribution (based on asymmetric encryption) with in-band certificate provision as defined in [RFC4738] (MIKEY-RSA-R)
o [RFC4738]（Mikey-RSA-R）で定義されているバンド内証明書の提供を備えた非対称キー分布（非対称暗号化に基づく）
Note that the latter three modes are extensions to MIKEY as there have been scenarios where none of the first four modes defined in [RFC3830] fits perfectly. There are further extensions to MIKEY comprising algorithm enhancements and a new payload definition supporting protocols other than SRTP.
後者の3つのモードは、[RFC3830]で定義された最初の4つのモードのいずれも完全に適合しないシナリオがあったため、マイキーの拡張であることに注意してください。アルゴリズムの強化と、SRTP以外のプロトコルをサポートする新しいペイロード定義を含むMikeyにはさらに拡張があります。
Algorithm extensions are defined in the following document:
アルゴリズム拡張機能は、次のドキュメントで定義されています。
o Elliptic Curve Cryptography (ECC) algorithms for MIKEY as defined in [MSEC-MIKEY]
o [MSEC-Mikey]で定義されているMikeyの楕円曲線暗号化（ECC）アルゴリズム
Payload extensions are defined in the following documents:
ペイロード拡張機能は、次のドキュメントで定義されています。
o Bootstrapping TESLA, defining a new payload for the Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol [RFC4082] as defined in [RFC4442]
o [RFC4442]で定義されているように、タイミングの効率的なストリーム損失耐性認証（TESLA）プロトコル[RFC4082]の新しいペイロードを定義するテスラのブートストラップ。
o The Key ID information type for the general extension payload as defined in [RFC4563]
o [RFC4563]で定義されている一般的な拡張ペイロードのキーID情報タイプ
o Open Mobile Alliance (OMA) Broadcast (BCAST) MIKEY General Extension Payload Specification as defined in [RFC4909]
o Open Mobile Alliance（OMA）ブロードキャスト（BCAST）[RFC4909]で定義されているMikey General Extensionペイロード仕様
o Integrity Transform Carrying Roll-over Counter for SRTP as defined in [RFC4771]. Note that this is rather an extension to SRTP and requires MIKEY to carry a new parameter, but is stated here for completeness.
o [RFC4771]で定義されているSRTPの整合性変換ロールオーバーカウンター。これはむしろSRTPの拡張機能であり、Mikeyに新しいパラメーターを運ぶ必要がありますが、完全性についてはここに記載されています。
This document provides an overview about RFC 3830 and the relations to the different extensions to provide a framework when using MIKEY. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are inspired by specific protocol workings of SIP that have proved to be problematic for a general key distribution mechanisms in general. These protocol workings are described in detail in Wing, et al. [SIP-MEDIA] and include the following:
このドキュメントは、RFC 3830に関する概要と、Mikeyを使用するときにフレームワークを提供するためのさまざまな拡張機能との関係を提供します。これは、開発者または建築家が、ユースケースのシナリオと動機、およびさまざまな主要な配布スキームの利点と欠点についてより多くの洞察を提供するための追加の情報源として意図されています。このドキュメントで説明されているユースケースは、一般的な主要な分布メカニズムにとって問題があることが証明されたSIPの特定のプロトコル作業に触発されています。これらのプロトコル作業は、Wingなどで詳細に説明されています。[sip-media]と以下を含めます。
o Early Media (i.e., media that arrives before the SDP answer)
o 初期のメディア（つまり、SDPの回答の前に到着するメディア）
o Forking
o フォーキング
o Call Transfer/Redirect/Retarget
o 転送/リダイレクト/リターゲットを呼び出します
o Shared Key Conferencing
o 共有キー会議
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The following definitions have been taken from [RFC3830]:
次の定義は[RFC3830]から取得されています。
(Data) Security Protocol: the security protocol used to protect the actual data traffic. Examples of security protocols are IPsec and SRTP.
（データ）セキュリティプロトコル：実際のデータトラフィックを保護するために使用されるセキュリティプロトコル。セキュリティプロトコルの例は、IPSECとSRTPです。
Data SA Data Security Association information for the security protocol, including a TEK and a set of parameters/ policies.
データSAデータセキュリティ協会情報セキュリティプロトコルの情報。TEKおよび一連のパラメーター/ポリシーを含む。
CS Crypto Session, uni- or bidirectional data stream(s), protected by a single instance of a security protocol.
セキュリティプロトコルの単一のインスタンスによって保護されているCS Cryptoセッション、統一または双方向データストリーム。
CSB Crypto Session Bundle, collection of one or more Crypto Sessions, which can have common TGKs (see below) and security parameters.
CSB Cryptoセッションバンドル、1つ以上の暗号セッションのコレクション。これには、一般的なTGK（以下を参照）およびセキュリティパラメーターを搭載できます。
CS ID Crypto Session ID, unique identifier for the CS within a CSB.
CS ID CryptoセッションID、CSB内のCSの一意の識別子。
CSB ID Crypto Session Bundle ID, unique identifier for the CSB.
CSB ID CryptoセッションバンドルID、CSBの一意の識別子。
TGK TEK Generation Key, 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.
TGK Tek Generation Keyは、CSBに関連する2つ以上の当事者によって合意されたビットストリングです。TGKから、さらに通信を必要とせずにトラフィックインコリッティングキーを生成できます。
TEK Traffic-Encrypting Key, 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.
CSを保護するためにセキュリティプロトコルで使用されるキーであるTek Traffic-Incryptingキー（このキーは、セキュリティプロトコルによって直接使用されるか、セキュリティプロトコルに応じてさらにキーを導出するために使用できます）。TEKはCSBのTGKに由来しています。
TGK re-keying the process of re-negotiating/updating the TGK (and consequently future TEK(s)).
TGKは、TGKを再交渉/更新するプロセス（およびその結果、将来のTEK（S））を再閉鎖します。
Initiator the initiator of the key management protocol, not necessarily the initiator of the communication.
イニシエーター主要な管理プロトコルのイニシエーターは、必ずしも通信の開始者ではありません。
Responder the responder in the key management protocol.
主要な管理プロトコルのレスポンダーをレスポンダーします。
Salting key a random or pseudo-random (see [RFC4086]) string used to protect against some off-line pre-computation attacks on the underlying security protocol.
塩漬けキーランダムまたは擬似ランダム（[RFC4086]を参照）ストリングの基礎となるセキュリティプロトコルに対するいくつかのオフラインのプレコンピューション攻撃から保護するために使用されます。
HDR the protocol header
HDRプロトコルヘッダー
PRF(k,x) a keyed pseudo-random function
PRF（K、X）キー付き擬似ランダム機能
E(k,m) encryption of m with the key k
キーkとのmの暗号化E（k、m）
RAND random value
T timestamp
CERTx the certificate of x
xの証明書を証明します
SIGNx the signature from x using the private key of x
xの秘密鍵を使用してxからの署名を署名します
PKx the public key of x
IDx the identity of x
idx xのアイデンティティ
[] an optional piece of information
[]オプションの情報
{} zero or more occurrences
{}ゼロ以上の発生
|| concatenation
||連結
| OR (selection operator)
|または（選択オペレーター）
^ exponentiation
^指数
XOR exclusive or
The following definitions have been added to the ones from [RFC3830]:
[RFC3830]の定義には、次の定義が追加されています。
SSRC Synchronization Source Identifier
SSRC同期ソース識別子
KEMAC MIKEY Key Data Transport Payload, containing a set of encrypted sub-payloads and a Message Authentication Code (MAC).
Kemac Mikey Key Data Transport Transport Payload。暗号化されたサブペイロードのセットとメッセージ認証コード（MAC）が含まれています。
V MIKEY Verification Message
vマイキー検証メッセージ
SP Security Parameter
SPセキュリティパラメーター
Forking The ability of a SIP proxy to replicate an incoming request to multiple outgoing requests in order to efficiently find the called party for rendezvous. SIP forking can be done in serial (depth-first search) or in parallel (breadth-first search).
SIPプロキシの能力が、Rendezvousのために呼び出されたパーティーを効率的に見つけるために、複数の発信要求に着信要求を複製する能力を分岐します。SIPフォーキングは、シリアル（深度最初の検索）または並列（幅最初の検索）で実行できます。
Redirect The ability of a SIP proxy to send a final response that redirects the caller to send a request to an alternate location.
SIPプロキシの能力をリダイレクトして、発信者をリダイレクトして別の場所にリクエストを送信する最終的な応答を送信します。
Retarget The ability of a SIP proxy to re-write the Request-URI thereby altering the destination of the request without explicitly notifying the user agent client.
SIPプロキシがリクエストを書き直す能力をリターゲットし、ユーザーエージェントクライアントに明示的に通知することなく、リクエストの宛先を変更します。
This section will provide an overview about MIKEY. MIKEY focuses on the setup of cryptographic context to secure multimedia sessions in a heterogeneous environment. MIKEY is mainly intended to be used for peer-to-peer, simple one-to-many, and small-size (interactive) groups. One objective of MIKEY is to produce a data security association (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対多、および小型（インタラクティブな）グループに使用することを目的としています。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 that obtain distinct TEKs from MIKEY.
Mikeyは、複数のセキュリティプロトコル（または同じセキュリティプロトコルのいくつかのインスタンス）のキーとパラメーターを同時に確立する可能性をサポートしています。Cryptoセッションバンドル（CSB）の概念は、共通のTGKとセキュリティパラメーターを持つことができる1つ以上の暗号セッションのコレクションを示すために使用されますが、マイキーから明確なTEKを取得します。
MIKEY as defined in RFC 3830 may proceed with one roundtrip at most, using a so-called Initiator message for the forward direction and a Responder message for the backward direction. Note that there exist MIKEY schemes that may proceed within a half roundtrip (e.g., based on a pre-shared key), while other schemes require a full roundtrip (e.g., Diffie-Hellman-based schemes). The main objective of the Initiator's message (I_MESSAGE) is to transport one or more TGKs (carried in the KEMAC field) and a set of security parameters (SPs) to the Responder in a secure manner. As the verification message from the Responder is optional for some schemes, the Initiator indicates whether or not it requires a verification message from the Responder.
RFC 3830で定義されているMikeyは、前方方向のいわゆるイニシエーターメッセージと後方方向にレスポンダーメッセージを使用して、せいぜい1つの往復を進めることができます。他のスキームには完全な往復が必要なのは、半往復（例えば、恥ずかしさキーに基づいて）内で進行する可能性のあるマイキースキームが存在することに注意してください（例：diffie-hellmanベースのスキーム）。イニシエーターのメッセージ（i_message）の主な目的は、1つ以上のTGK（KEMACフィールドで運ばれる）とセキュリティパラメーターのセット（SPS）を安全な方法でレスポンダーに輸送することです。レスポンダーからの検証メッセージは一部のスキームでオプションであるため、イニシエーターはレスポンダーからの検証メッセージが必要かどうかを示します。
The focus of the following subsections lies on the key distribution methods as well as the discussion about advantages and disadvantages of the different schemes. Note that the MIKEY key distribution schemes rely on loosely synchronized clocks. If clock synchronization is not available, the replay handling of MIKEY (cf. [RFC3830]) may not work. This is due to the fact that MIKEY does not use a challenge-response mechanism for replay handling; instead, timestamps are used together with message caching. Thus, the required synchronization depends on the number of messages that can be cached on either side. Therefore, MIKEY recommends adjusting the cache size depending on the clock skew in the deployment environment. Moreover, RFC 3830 recommends the ISO time synchronization protocol [ISO_sec_time]. If replay handling is not available, an attacker may be able to replay an older message that he eavesdropped earlier, leading to different TGKs on both sides. As these are fed to the application utilizing MIKEY (e.g., SRTP or TESLA), both sides may rely on different keys and thus may be unable to communicate with each other. The format applied to the timestamps submitted in MIKEY have to match the NTP format described in [RFC1305]. In other cases, such as of a SIP endpoint, clock synchronization by deriving time from a trusted outbound proxy may be appropriate .
次のサブセクションの焦点は、さまざまなスキームの利点と短所に関する議論と同様に、主要な分布方法と議論にあります。Mikey Key Distributionスキームは、ゆるく同期したクロックに依存していることに注意してください。時計同期が利用できない場合、Mikey（[RFC3830]を参照）のリプレイ処理が機能しない場合があります。これは、マイキーがリプレイ処理にチャレンジ応答メカニズムを使用していないという事実によるものです。代わりに、タイムスタンプはメッセージキャッシュと一緒に使用されます。したがって、必要な同期は、両側にキャッシュできるメッセージの数に依存します。したがって、Mikeyは、展開環境の時計のゆがみに応じて、キャッシュサイズを調整することをお勧めします。さらに、RFC 3830は、ISOタイム同期プロトコル[ISO_SEC_TIME]を推奨しています。リプレイの処理が利用できない場合、攻撃者は、彼が以前に盗んだ古いメッセージを再生し、両側に異なるTGKにつながる可能性があります。これらはMikey（SRTPやTeslaなど）を使用してアプリケーションに供給されるため、双方が異なるキーに依存する可能性があるため、互いに通信できない場合があります。Mikeyで提出されたタイムスタンプに適用される形式は、[RFC1305]で説明されているNTP形式と一致する必要があります。他の場合、SIPエンドポイントなど、信頼できるアウトバウンドプロキシから時間を導き出すことによるクロック同期が適切かもしれません。
The different MIKEY-related schemes are compared regarding the following criteria:
次の基準に関して、さまざまなマイキー関連スキームが比較されます。
o Mandatory for implementation: provides information, if RFC 3830 requires the implementation of this scheme.
o 実装に必須：RFC 3830がこのスキームの実装が必要な場合、情報を提供します。
o Scalability: describes the technical feasibility to easily deploy a solution based on the considered scheme.
o スケーラビリティ：考慮されたスキームに基づいてソリューションを簡単に展開する技術的な実現可能性について説明します。
o Dependency on PKI: states if the support of a PKI is required to support this scheme. Note that PKI here relates to PKI services like key generation, distribution, and revocation.
o PKIへの依存：PKIのサポートがこのスキームをサポートする必要があるかどうかを述べます。ここでのPKIは、キー生成、分布、取り消しなどのPKIサービスに関連していることに注意してください。
o Provision of Perfect Forward Secrecy (PFS): describes the support of PFS, which is, according to RFC 4949 [RFC4949], the property that compromising the long-term keying material does not compromise session keys that were previously derived from the long-term material.
o Perfect Forward Secrecy（PFS）の提供：RFC 4949 [RFC4949]によると、PFSのサポートについて説明します。材料。
o Key generation involvement: describes if both or just one of the participants is actively involved in key generation. The option to involve both parties in the key generation is considered here as it addresses several points:
o 主要生成の関与：参加者の両方または1人が主要生成に積極的に関与しているかどうかを説明します。キー世代に両当事者を巻き込むオプションは、いくつかのポイントに対処するため、ここで考慮されます。
* If both sides contribute public entropy, it is ensured that each side can guarantee that keys are fresh to avoid replay attacks.
* 双方が公共のエントロピーに寄与している場合、リプレイ攻撃を避けるために、各側がキーが新鮮であることを保証できることが保証されます。
* Involvement of both sides avoids that one side generates (intentionally or unintentionally) weak (predictable) nonces, which in turn may result in weak keys.
* 双方の関与は、片側が（意図的または意図せずに）弱い（予測可能な）ノンースを生成することを避け、それが弱いキーをもたらす可能性があります。
o Support of group keying: feasibility of the MIKEY option to be used also for group keying, e.g., in conferencing scenarios.
o グループキーイングのサポート：グループキーイング、たとえば会議シナリオにも使用されるマイキーオプションの実現可能性。
If MIKEY is used for SRTP [RFC3711] bootstrapping, it also uses the SSRC to associate security policies with actual sessions. The SSRC identifies the synchronization source. The value is chosen randomly, with the intent that no two synchronization sources within the same SRTP session will have the same SSRC. Although the probability of multiple sources choosing the same identifier is low, all (S)RTP implementations must be prepared to detect and resolve collisions. Nevertheless, in multimedia communication scenarios supporting forking (see Section 5.2) or retargeting (see Section 5.3) collisions may occur leading to so-called two-time pads; i.e., the same key is used for media streams to different destinations. This occurs if two branches have the same TEK (based on the MIKEY key establishment) and choose the same 32-bit SSRC for the SRTP streams. The SRTP key derivation will then produce the same session keys (as the input values are the same) and also derive the same initialization vector per packet, as the SSRCs are the same. Note that two time pads may also occur for media streams to the same destination. This is outlined in [RFC3711].
MikeyがSRTP [RFC3711]ブートストラップに使用されている場合、SSRCを使用してセキュリティポリシーを実際のセッションに関連付けます。SSRCは同期ソースを識別します。値はランダムに選択され、同じSRTPセッション内の2つの同期ソースが同じSSRCを持たないことを目的としています。同じ識別子を選択する複数のソースの確率は低いですが、衝突を検出および解決するためにすべてのRTP実装を準備する必要があります。それにもかかわらず、フォーキング（セクション5.2を参照）またはリターゲティング（セクション5.3を参照）をサポートするマルチメディア通信シナリオでは、いわゆる2回のパッドにつながる衝突が発生する可能性があります。つまり、同じキーがメディアストリームに異なる宛先に使用されます。これは、2つのブランチに同じTEK（Mikeyキー設立に基づいて）を持ち、SRTPストリームに対して同じ32ビットSSRCを選択した場合に発生します。SRTPキー導入は、SSRCが同じであるため、同じセッションキー（入力値が同じ）を生成し、パケットごとに同じ初期化ベクトルを導出します。同じ宛先のメディアストリームでも2つのタイムパッドが発生する可能性があることに注意してください。これは[RFC3711]で概説されています。
This option of the key management uses a pre-shared secret key to derive key material for integrity protection and encryption to protect the actual exchange of key material. Note that the pre-shared secret is agreed upon before the session, e.g., by out-of-band means. The responder message is optional and may be used for mutual authentication (proof of possession of the pre-shared secret) or error signaling.
主要な管理のこのオプションは、事前に共有された秘密の鍵を使用して、整合性保護と暗号化のためにキー資料を導き出し、キーマテリアルの実際の交換を保護します。事前に共有された秘密は、セッションの前に、例えば帯域外の手段によって合意されていることに注意してください。レスポンダーメッセージはオプションであり、相互認証（事前共有秘密の所持の証明）またはエラーシグナル伝達に使用できます。
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
The advantages of this approach lay in the fact that there is no dependency on a PKI (Public Key Infrastructure), the solution consumes low bandwidth and enables high performance, and is all in all a simple straightforward master key provisioning. The disadvantages are that perfect forward secrecy is not provided and key generation is just performed by the Initiator. Furthermore, the approach is not scalable to larger configurations but is acceptable in small-sized groups. Note that according to [RFC3830], this option is mandatory to implement.
このアプローチの利点は、PKI（公開キーインフラストラクチャ）に依存していないという事実にあり、ソリューションは低帯域幅を消費し、高性能を可能にし、すべてが単純なマスターキープロビジョニングであるということです。欠点は、完全なフォワードの秘密が提供されておらず、キー生成がイニシエーターによって実行されることです。さらに、このアプローチは大規模な構成に対してスケーラブルではありませんが、小型グループでは許容されます。[RFC3830]によれば、このオプションは実装することが必須であることに注意してください。
Using the asymmetric option of the key management, the Initiator generates the key material (TGKs) to be transmitted and sends it encrypted with a so-called envelope key, which in turn is encrypted with the receiver's public key. The envelope key, env-key, which is a random number, is used to derive the auth-key and the enc-key. Moreover, the envelope key may be used as a pre-shared key to establish further crypto sessions. The responder message is optional and may be used for mutual authentication or error signaling.
キー管理の非対称オプションを使用して、イニシエーターは、送信されるキーマテリアル（TGK）を生成し、いわゆるエンベロープキーで暗号化され、レシーバーの公開キーで暗号化されます。乱数であるEnvelopeキーであるEnv-Keyは、Auth-KeyとEnc-Keyを導出するために使用されます。さらに、エンベロープキーは、さらなる暗号セッションを確立するための事前共有キーとして使用できます。レスポンダーメッセージはオプションであり、相互認証またはエラーシグナル伝達に使用できます。
Initiator Responder
イニシエーターレスポンダー
I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, KEMAC, [CHASH], PKE, SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V
i_message = hdr、t、rand、[idi | certi]、[idr]、{sp}、kemac、[chash]、pke、signi ---> r_message = [<---] hdr、t、[idr]、v
An advantage of this approach is that it allows the usage of self-signed certificates, which in turn can avoid a full-blown PKI. Note that using self-signed certificates may result in limited scalability and also require additional means for authentication such as exchange of fingerprints of the certificates or similar techniques. The disadvantages comprise the necessity of a PKI for full scalability, the performance of the key generation just by the Initiator, and no provision of perfect forward secrecy. Additionally, the Responder certificate needs to be available in advance at the sender's side. Furthermore, the verification of certificates may not be done in real time. This could be the case in scenarios where the revocation status of certificates is checked through a further component. Depending on the Initiator role, this scheme can also be applied in group-based communication, where a central server distributes the group key protected with the public keys of the associated clients. Note that according to [RFC3830], this option is mandatory to implement.
このアプローチの利点は、自己署名証明書の使用を可能にすることです。これにより、本格的なPKIを回避できます。自己署名証明書を使用すると、スケーラビリティが限られているため、証明書の指紋の交換や同様の手法などの認証手段が必要になる可能性があることに注意してください。欠点は、完全なスケーラビリティのためのPKIの必要性、イニシエーターだけによる主要生成のパフォーマンス、および完全な前進の秘密の提供はないことを構成します。さらに、送信者の側では、レスポンダー証明書を事前に利用できるようにする必要があります。さらに、証明書の検証はリアルタイムで行われない場合があります。これは、証明書の取り消しステータスがさらなるコンポーネントを介してチェックされるシナリオの場合になる可能性があります。イニシエーターの役割に応じて、このスキームは、中央サーバーが関連するクライアントのパブリックキーで保護されているグループキーを配布するグループベースの通信にも適用できます。[RFC3830]によれば、このオプションは実装することが必須であることに注意してください。
The Diffie-Hellman option of the key management enables a shared secret establishment between the Initiator and Responder in a way where both parties contribute to the shared secret. The Diffie-Hellman key agreement is authenticated (and integrity protected) using digital signatures.
キー管理のdiffie-hellmanオプションは、両当事者が共有秘密に貢献する方法で、イニシエーターとレスポンダーの間の共有秘密の確立を可能にします。Diffie-Hellmanキー契約は、デジタル署名を使用して認証（および整合性保護）されます。
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、signi ---> message = <--- hdr、t、[idr | certr]、idi、dhr、dhi、signr
[RFC3830] does mandate the support of RSA as a specific asymmetric algorithm for the signature generation. Additionally, the algorithm used for signature or public key encryption is defined by, and dependent on, the certificate used. Besides the use of X.509v3 certificates, it is mandatory to support the Diffie-Hellman group "OAKLEY5" [RFC2412]. It is also possible to use other Diffie-Hellman groups within MIKEY. This can be done by defining a new mapping sub-payload and the associated policy payload according to [RFC3830]. The advantages of this approach are a fair, mutual key agreement (both parties provide to the key), perfect forward secrecy, and the absence of the need to fetch a certificate in advance as needed for the MIKEY-RSA method depicted above. Moreover, it also provides the option to use self-signed certificates to avoid a PKI deployment. Note that, depending on the security policy, self-signed certificates may not be suitable for every use case.
[RFC3830]は、署名生成の特定の非対称アルゴリズムとしてRSAのサポートを義務付けています。さらに、署名または公開キーの暗号化に使用されるアルゴリズムは、使用される証明書によって定義され、依存します。X.509V3証明書の使用に加えて、Diffie-Hellmanグループ「Oakley5」[RFC2412]をサポートすることが必須です。また、Mikey内の他のDiffie-Hellmanグループを使用することも可能です。これは、[RFC3830]に従って、新しいマッピングサブペイロードと関連するポリシーペイロードを定義することで実行できます。このアプローチの利点は、上記のMikey-RSAメソッドの必要に応じて事前に証明書を取得する必要性があり、上記のMikey-RSA法の必要に応じて証明書を取得する必要性がないため、公正な相互キーの合意（両当事者がキーを提供します）、完全な前方的な秘密、そして不在です。さらに、PKIの展開を回避するために自己署名証明書を使用するオプションも提供します。セキュリティポリシーに応じて、自己署名証明書はすべてのユースケースに適していない場合があることに注意してください。
Negatively to remark is that this approach scales mainly to point-to-point and depends on PKI for full scalability. Multiparty conferencing is not supported using just MIKEY-DHSIGN. Nevertheless, the established Diffie-Hellman-Secret may serve as a pre-shared key to bootstrap group-related security parameter. Furthermore, as for the MIKEY-RSA mode described above, the verification of certificates may not necessarily be done in real time. This could be the case in scenarios where the revocation status of certificates is checked through a further component. Note that, according to [RFC3830], it is optional to implement this scheme.
否定的には、このアプローチは主にポイントツーポイントにスケーリングし、完全なスケーラビリティのためにPKIに依存することです。Multiparty会議は、Mikey-dhsignだけを使用してサポートされていません。それにもかかわらず、確立されたDiffie-Hellman-Secretは、Bootstrapグループ関連のセキュリティパラメーターの事前に共有された鍵として機能する可能性があります。さらに、上記のMikey-RSAモードについては、証明書の検証が必ずしもリアルタイムで行われるとは限りません。これは、証明書の取り消しステータスがさらなるコンポーネントを介してチェックされるシナリオの場合になる可能性があります。[RFC3830]によれば、このスキームを実装することはオプションであることに注意してください。
RFC 3830 also supports a mode to provide a key in an unprotected manner (MIKEY-NULL). This is based on the symmetric key encryption option depicted in Section 3.1 but is used with the NULL encryption and the NULL authentication algorithms. It may be compared with the plain approach in SDP security descriptions [RFC4568]. MIKEY-NULL completely relies on the security of the underlying layer, e.g., provided by TLS. This option should be used with caution as it does not protect the key management.
RFC 3830は、保護されていない方法でキーを提供するモード（Mikey-Null）もサポートしています。これは、セクション3.1に描かれている対称キー暗号化オプションに基づいていますが、ヌル暗号化とヌル認証アルゴリズムで使用されます。SDPセキュリティの説明[RFC4568]の単純なアプローチと比較することができます。Mikey-Nullは、TLSによって提供される基礎となる層のセキュリティに完全に依存しています。このオプションは、主要な管理を保護しないため、注意して使用する必要があります。
Based on the missing cryptographic protection of this method, it is obvious that perfect forward secrecy is not provided. As it is based on the pre-shared secret mode, only the Initiator contributes to the key management. The method itself is highly scalable, but again, without proper protection through an underlying security layer, it is not advisable for use.
この方法の不足している暗号化保護に基づいて、完全な前方秘密が提供されていないことは明らかです。恥ずかしさの秘密モードに基づいているため、イニシエーターのみが主要な管理に寄与します。メソッド自体は非常にスケーラブルですが、繰り返しますが、基礎となるセキュリティ層を介した適切な保護がなければ、使用することはお勧めできません。
This is an additional option, which has been defined in [RFC4650]. In contrast to the method described in Section 3.3, here the Diffie-Hellman key agreement is authenticated (and integrity protected) using a pre-shared secret and keyed hash function.
これは追加のオプションであり、[RFC4650]で定義されています。セクション3.3で説明した方法とは対照的に、ここでは、Diffie-Hellmanキー契約は、事前に共有された秘密とキー付きハッシュ関数を使用して認証（および整合性保護）されます。
Initiator Responder
イニシエーターレスポンダー
I_MESSAGE = HDR, T, RAND, [IDi], IDr, {SP}, DHi, KEMAC ---> R_MESSAGE = <--- HDR, T,[IDr], IDi, DHr, DHi, KEMAC
i_message = hdr、t、rand、[idi]、idr、{sp}、dhi、kemac ---> r_message = <--- hdr、t、[idr]、idi、dhr、dhi、kemac
TGK = g^(xi * yi) TGK = g^(xi * yi)
For the integrity protection of the Diffie-Hellman key agreement, [RFC4650] mandates the use of HMAC SHA-1. Regarding Diffie-Hellman groups, [RFC3830] is referenced. Thus, it is mandatory to support the Diffie-Hellman group "OAKLEY5" [RFC2412]. It is also possible to use other Diffie-Hellman groups within MIKEY. This can be done by defining a new mapping sub-payload and the associated policy payload according to RFC 3830. This option has also several advantages, as there are the fair mutual key agreement, the perfect forward secrecy, and no dependency on a PKI and PKI standards. Moreover, this scheme has a sound performance and reduced bandwidth requirements compared to MIKEY-DH-SIGN and provides a simple and straightforward master key provisioning. The establishment of shared secrets and the lack of support for group keying is a disadvantage.
Diffie-Hellman Key契約の整合性保護のために、[RFC4650]はHMAC SHA-1の使用を義務付けています。diffie-hellmanグループに関しては、[RFC3830]が参照されます。したがって、Diffie-Hellmanグループ「Oakley5」[RFC2412]をサポートすることが必須です。また、Mikey内の他のDiffie-Hellmanグループを使用することも可能です。これは、RFC 3830に従って新しいマッピングサブペイロードと関連するポリシーペイロードを定義することで実行できます。このオプションには、公正な相互の重要な合意、完璧な前方秘密、およびPKIおよびPKIとの依存性がないため、いくつかの利点もあります。PKI標準。さらに、このスキームは、Mikey-DH-Signと比較して、健全なパフォーマンスと帯域幅の要件が低下し、シンプルで簡単なマスターキープロビジョニングを提供します。共有された秘密の確立とグループキーイングへのサポートの欠如は不利です。
This mode of operation provides an efficient scheme in deployments where there is a central trusted server that is provisioned with shared secrets for many clients. Such setups could, for example, be enterprise Private Branch Exchanges (PBXs), service provider proxies, etc. In contrast to the plain pre-shared key encryption-based mode, described in Section 3.1, this mode offers perfect forward secrecy as well as active involvement in the key generation of both parties involved.
この操作モードは、多くのクライアントに共有された秘密でプロビジョニングされている中央信頼できるサーバーがある展開に効率的なスキームを提供します。このようなセットアップは、たとえば、エンタープライズプライベートブランチ交換（PBXS）、サービスプロバイダープロキシなどになる可能性があります。関係する両当事者の主要生成への積極的な関与。
There has been a longer discussion during IETF meetings and also on the IETF MSEC mailing list about a SAML-assisted DH approach. This idea has not been submitted as a separate document. Nevertheless, the discussion is reflected here as it is targeted to fulfill general requirements on key management approaches. Those requirements can be summarized as:
IETFミーティング中に、またIETF MSECメーリングリストでSAML支援DHアプローチに関する議論が長くなりました。このアイデアは、別のドキュメントとして提出されていません。それにもかかわらず、主要な管理アプローチに関する一般的な要件を満たすことを目的としているため、議論はここで反映されています。これらの要件は、次のように要約できます。
1. Mutual authentication of involved parties
1. 関係者の相互認証
2. Both parties involved contribute to the session key generation
2. 関係する両当事者は、セッションキー生成に貢献します
3. Provide perfect forward secrecy
3. 完璧な前方の秘密を提供します
4. Support distribution of group session keys
4. グループセッションキーの分布をサポートします
5. Provide liveliness tests when involved parties do not have a reliable clock
5. 関係者が信頼できる時計を持っていない場合、活気のあるテストを提供する
6. Support of limited parties involved
6. 関係する限定関係者のサポート
To fulfill all of the requirements, it was proposed to use a classic Diffie-Hellman key agreement protocol for key establishment in conjunction with a User Agent's (UA's) SIP server signed element, authenticating the Diffie-Hellman key and the ID using the SAML (Security Assertion Markup Language [SAML_overview]) approach. Here the client's public Diffie-Hellman credentials are signed by the server to form a SAML assertion (referred to as CRED below), which may be used for later sessions with other clients. This assertion needs at least to convey the ID, public DH key, expiry, and the signature from the server. It provides the involved clients with mutual authentication and message integrity of the key management messages exchanged.
すべての要件を満たすために、ユーザーエージェント（UAの）SIPサーバー署名された要素と組み合わせて、キー確立のための古典的なDiffie-Hellmanキー契約プロトコルを使用して、SAMLを使用してDiffie-HellmanキーとIDを認証します（セキュリティアサーションマークアップ言語[saml_overview]）アプローチ。ここでは、クライアントの公開Diffie-Hellman資格がサーバーによって署名され、SAMLアサーション（以下のクレジットと呼ばれる）を形成します。これは、他のクライアントとの後のセッションに使用される場合があります。このアサーションは、少なくともID、パブリックDHキー、有効期限、およびサーバーからの署名を伝える必要があります。交換された主要な管理メッセージの相互認証とメッセージの整合性を、関係するクライアントに提供します。
Initiator Responder
イニシエーターレスポンダー
I_MESSAGE = HDR, T, RAND1, [CREDi], IDr, {SP} ---> R_MESSAGE = <--- HDR, T, [CREDr], IDi, DHr, RAND2, (SP) TGK = HMACx(RAND1|RAND2), where x = g^(xi * xr).
i_message = hdr、t、rand1、[credi]、idr、{sp} ---> r_message = <--- hdr、t、[credr]、idi、dhr、rand2、（sp）tgk = hmacx（rand1 |rand2）、x = g^（xi * xr）。
Additionally, the scheme proposes a second roundtrip to avoid the dependence on synchronized clocks and provide liveliness checks. This is achieved by exchanging nonces, protected with the session key. The second roundtrip can also be used for distribution of group keys or to leverage a weak DH key for a stronger session key. The trigger for the second roundtrip would be handled via SP, the security policy communicated via MIKEY.
さらに、このスキームは、同期されたクロックへの依存を回避し、活気のあるチェックを提供するために、2回目の往復を提案します。これは、セッションキーで保護されているNoncesを交換することによって達成されます。2番目の往復は、グループキーの配布や、より強力なセッションキーの弱いDHキーを活用するためにも使用できます。2回目の往復のトリガーは、SPを介して処理されます。これは、Mikeyを介して伝達されるセキュリティポリシーです。
Initiator Responder
イニシエーターレスポンダー
I_MESSAGE =
HDR, SIGN(ENC(RAND3)) --->
R_MESSAGE =
<--- SIGN(ENC(RAND4))
Note that if group keys are to be provided, RAND would be substituted by that group key.
グループキーが提供される場合、ランドはそのグループキーに置き換えられることに注意してください。
With the second roundtrip, this approach also provides an option for all of the other key distribution methods, when liveliness checks are needed. The drawback of the second roundtrip is that these messages need to be integrated into the call flow of the signaling protocol. In a straight-forward call, one roundtrip may be enough to set up a session. Thus, this second roundtrip would require additional messages to be exchanged.
2番目の往復では、このアプローチは、活気のあるチェックが必要な場合、他のすべての主要な分布方法のオプションも提供します。2番目の往復の欠点は、これらのメッセージをシグナリングプロトコルのコールフローに統合する必要があることです。ストレートフォワードコールでは、セッションをセットアップするのに十分なラウンドトリップで十分かもしれません。したがって、この2回目の往復では、追加のメッセージを交換する必要があります。
Regarding the different criteria discussed in the introduction of this section, the advantages of this approach are a fair, mutual key agreement (both parties provide to the key), and perfect forward secrecy. Through the second roundtrip, the dependency on synchronized clocks can be avoided. Moreover, this second roundtrip enables the distribution of a group key and thus enhances the scalability from mainly point-to-point to also multiparty conferencing. The usage of SAML-assisted DH may decrease the hidden latency cost through the credential validation necessary to be done for the signed DH scheme described in Section 3.3. If the UA received its SAML assertion from its domain's SIP server, it is trusting the server implicitly, thus, it may extend that trust to relying on it to validate the other party's SAML assertion. This eliminates not only the hidden validation latency but also its computational cost to the UA.
このセクションの導入で説明されているさまざまな基準に関して、このアプローチの利点は、公正で相互のキー合意（両当事者がキーを提供する）であり、完全な前進秘密です。2番目の往復により、同期されたクロックへの依存性を回避できます。さらに、この2番目の往復により、グループキーの分布が可能になり、主にポイントツーポイントからマルチパート会議へのスケーラビリティが向上します。SAML支援DHの使用は、セクション3.3で説明されている署名されたDHスキームに対して行われるために必要な資格検証を通じて、隠されたレイテンシコストを削減する可能性があります。UAがドメインのSIPサーバーからSAMLアサーションを受け取った場合、サーバーを暗黙的に信頼しているため、他の当事者のSAMLアサーションを検証するためにその信頼を依存することができます。これにより、隠された検証遅刻だけでなく、UAに対する計算コストも排除されます。
Negatively to remark is that this proposal does have one significant security risk. The UA's SIP server can cheat and create an extra authentication object for the UA where it has the Diffie-Hellman private key. With this, the (SIP) server issuing the SAML assertion can successfully launch a Man-in-the-Middle (MITM) attack against two of its UAs. Also, two SIP servers can collude so that either can successfully launch a MITM attack against their UAs. A UA can block this attack if its Diffie-Hellman key is authenticated by a trustworthy third party and this whole object is signed by the SIP server. Moreover, this approach uses two roundtrips, increasing the necessary bandwidth and also the setup time, which may be crucial for many scenarios. For the credential generation, usually a separate component (server) is necessary, so serverless call setup is not supported.
否定的には、この提案には1つの重大なセキュリティリスクがあることです。UAのSIPサーバーは、diffie-hellmanの秘密鍵を備えたUAの追加の認証オブジェクトをチートして作成できます。これにより、SAMLアサーションを発行する（SIP）サーバーは、2つのUASに対して中間（MITM）攻撃を正常に起動できます。また、2つのSIPサーバーが共謀できるため、UASに対するMITM攻撃を正常に起動できるようになります。Diffie-Hellmanキーが信頼できるサードパーティによって認証され、このオブジェクト全体がSIPサーバーによって署名されている場合、UAはこの攻撃をブロックできます。さらに、このアプローチでは2つの往復を使用して、必要な帯域幅とセットアップ時間を増やします。これは、多くのシナリオにとって重要な場合があります。資格認定の生成の場合、通常は別のコンポーネント（サーバー）が必要なため、サーバーレスコールのセットアップはサポートされていません。
This is an additional option, which has been defined in [RFC4738]. It describes the asymmetric key distribution with optional in-band certificate exchange.
これは追加のオプションであり、[RFC4738]で定義されています。オプションのバンド内証明書交換を備えた非対称キーディストリビューションについて説明します。
Initiator Responder
イニシエーターレスポンダー
I_MESSAGE = HDR, T, [IDi|CERTi], [IDr], {SP}, [RAND], SIGNi ---> R_MESSAGE = <--- HDR, [GenExt(CSB-ID)], T, RAND, [IDr|CERTr], [SP], KEMAC, SIGNr
i_message = hdr、t、[idi | certi]、[idr]、{sp}、[rand]、signi - > r_message = <--- hdr、[genext（csb-d）]、t、rand、[idr | certr]、[sp]、kemac、signr
This option has some advantages compared to the asymmetric key distribution stated in Section 3.2. Here, the sender and receiver do not need to know the certificate of the other peer in advance as it may be sent in the MIKEY Initiator message (if the receiver knows the certificate in advance, RFC 3830's MIKEY-RSA mode may be used instead). Thus, the receiver of this message can utilize the received key material to encrypt the session parameter and send them back as part of the MIKEY responder message. The certificate check may be done depending on the signing authority. If the certificate is signed by a publicly accepted authority, the certificate validation can be done in a straightforward manner, by using the commonly known certificate authority's public key. In the other case, additional steps may be necessary. The disadvantage is that no perfect forward secrecy is provided.
このオプションには、セクション3.2に記載されている非対称キー分布と比較して、いくつかの利点があります。ここでは、送信者とレシーバーは、Mikeyイニシエーターメッセージで送信される可能性があるため、他のピアの証明書を事前に知る必要はありません（受信者が事前に証明書を知っている場合、RFC 3830のMikey-RSAモードを代わりに使用できます）。したがって、このメッセージの受信者は、受信した重要な資料を利用してセッションパラメーターを暗号化し、Mikey Responderメッセージの一部として送信できます。証明書チェックは、署名当局に応じて行うことができます。証明書が公的に受け入れられた当局によって署名されている場合、一般的に既知の証明書当局の公開鍵を使用することにより、証明書の検証は簡単な方法で行うことができます。他のケースでは、追加の手順が必要になる場合があります。欠点は、完全なフォワードの秘密が提供されていないことです。
This mode is meant to provide an easy option for certificate provisioning when PKI is present and/or required. Specifically in SIP, session invitations can be retargeted or forked. MIKEY modes that require the Initiator to target a single well-known Responder may be impractical here as they may require multiple roundtrips to do key negotiation. By allowing the Responder to generate secret material used for key derivation, this mode allows for an efficient key delivery scheme. Note that the Initiator can contribute to the key material since the key is derived from CSB-ID and RAND payloads in unicast use cases. This mode is also useful in multicast scenarios where multiple clients are contacting a known server and are downloading the key. Responder workload is significantly reduced in these scenarios compared to MIKEY in public key mode. This is due to the fact that the RSA asymmetric encryption requires less effort compared to the decryption using the private key (the public key is usually shorter than the private key, hence less performance for encryption compared to decryption). Examples of deployments where this mode can be used are enterprises with PKI, service provider setups where the service provider decides to provision certificates to its users, etc.
このモードは、PKIが存在している、および/または必要なときに証明書のプロビジョニングに簡単なオプションを提供することを目的としています。具体的には、SIPでは、セッションの招待状をリターゲットまたはフォークできます。イニシエーターが単一の有名なレスポンダーをターゲットにする必要があるマイキーモードは、ここでは重要な交渉を行うために複数の往復が必要になる可能性があるため、ここでは非現実的である可能性があります。レスポンダーがキー派生に使用される秘密の素材を生成できるようにすることにより、このモードにより、効率的なキー配信スキームが可能になります。キーはユニキャストユースケースでCSB-IDおよびRANDペイロードから派生しているため、イニシエーターはキー材料に寄与できることに注意してください。このモードは、複数のクライアントが既知のサーバーに連絡し、キーをダウンロードしているマルチキャストシナリオにも役立ちます。これらのシナリオでは、公開キーモードのマイキーと比較して、レスポンダーワークロードが大幅に削減されます。これは、RSAの非対称暗号化が秘密鍵を使用した復号化と比較して少ない労力を必要としないという事実によるものです（通常、公開キーは秘密鍵よりも短く、したがって、復号化と比較して暗号化のパフォーマンスが少なくなります）。このモードを使用できる展開の例は、PKIを持つエンタープライズ、サービスプロバイダーがユーザーに証明書を提供することを決定するエンタープライズなどです。
This section will provide an overview about further MIKEY [RFC3830] extensions for crypto algorithms and generic payload enhancements, as well as enhancements to support the negotiation of security parameters for security protocols other than SRTP. These extensions have been defined in several additional documents.
このセクションでは、暗号アルゴリズムと汎用ペイロード拡張のさらなるMikey [RFC3830]拡張機能と、SRTP以外のセキュリティプロトコルのセキュリティパラメーターの交渉をサポートするための拡張に関する概要について説明します。これらの拡張機能は、いくつかの追加のドキュメントで定義されています。
[MSEC-MIKEY] proposes extensions to the authentication, encryption, and digital signature methods described for use in MIKEY, employing elliptic curve cryptography (ECC). These extensions are defined to align MIKEY with other ECC implementations and standards.
[MSEC-Mikey]は、楕円曲線暗号化（ECC）を使用して、Mikeyで使用するために説明されている認証、暗号化、およびデジタル署名方法の拡張を提案しています。これらの拡張機能は、Mikeyを他のECC実装および標準に合わせるために定義されています。
The motivation for supporting ECC within MIKEY stems from the following advantages:
マイキー内のECCをサポートする動機は、次の利点から生じます。
o ECC modes are more and more added to security protocols.
o ECCモードは、セキュリティプロトコルにますます追加されています。
o ECC support requires considerably smaller keys by keeping the same security level compared to other asymmetric techniques (like RSA). Elliptic curve algorithms are capable of providing security consistent with Advanced Encryption Standard (AES) keys of 128, 192, and 256 bits without extensive growth in asymmetric key sizes.
o ECCサポートには、他の非対称テクニック（RSAなど）と比較して同じセキュリティレベルを維持することにより、かなり小さなキーが必要です。楕円曲線アルゴリズムは、非対称キーサイズで大幅に増加することなく、128、192、および256ビットの高度な暗号化標準（AES）キーと一致するセキュリティを提供することができます。
o As stated in [MSEC-MIKEY], implementations have shown that elliptic curve algorithms can significantly improve performance and security-per-bit over other recommended algorithms.
o [MSEC-Mikey]で述べたように、実装は、楕円曲線アルゴリズムが他の推奨アルゴリズムよりもパフォーマンスとセキュリティを大幅に改善できることを示しています。
These advantages make the usage of ECC especially interesting for embedded devices, which may have only limited performance and storage capabilities.
これらの利点により、ECCの使用は、パフォーマンスとストレージ機能が限られているだけの埋め込みデバイスで特に興味深いものになります。
[MSEC-MIKEY] proposes several ECC-based mechanisms to enhance the MIKEY key distribution schemes:
[MSEC-Mikey]は、Mikey Key Distributionスキームを強化するためのECCベースのメカニズムをいくつか提案しています。
o Use of ECC methods extending the Diffie-Hellman key exchange: MIKEY-DHSIGN with ECDSA or ECGDSA
o diffie-hellmanキーエクスチェンジを拡張するECCメソッドの使用：Mikey-dhsign with ecdsaまたはecgdsa
o Use of ECC methods extending the Diffie-Hellman key exchange: MIKEY-DHSIGN with ECDH
o diffie-hellmanキーエクスチェンジを拡張するECCメソッドの使用：Mikey-dhsign with ecdh
o Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES)
o 楕円曲線統合暗号化スキーム（Mikey-Ecies）の使用
o Use of Elliptic Curve Menezes-Qu-Vanstone Scheme(MIKEY-ECMQV)
o 楕円曲線の使用メネゼス-Qu-vanstoneスキーム（Mikey-ECMQV）
The following subsections will provide more detailed information about the message exchanges for MIKEY-ECIES and MIKEY-ECMQV.
次のサブセクションでは、Mikey-EciesとMikey-Ecmqvのメッセージ交換に関するより詳細な情報を提供します。
The following figure shows the message exchange for the MIKEY-ECIES scheme:
次の図は、Mikey-Eciesスキームのメッセージ交換を示しています。
Initiator Responder
イニシエーターレスポンダー
I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, KEMAC, [CHASH], PKE, SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V
i_message = hdr、t、rand、[idi | certi]、[idr]、{sp}、kemac、[chash]、pke、signi ---> r_message = [<---] hdr、t、[idr]、v
The following figure shows the message exchange for the MIKEY-ECMQV scheme:
次の図は、Mikey-ECMQVスキームのメッセージ交換を示しています。
Initiator Responder
イニシエーターレスポンダー
I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, ECCPTi, SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V
i_message = hdr、t、rand、[idi | certi]、[idr]、{sp}、eccpti、signi ---> r_message = [<---] hdr、t、[idr]、v
TESLA [RFC4082] is a protocol for providing source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead, which scales to large numbers of receivers, and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published in [RFC4383] targeting multicast authentication in scenarios, where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.
Tesla [RFC4082]は、マルチキャストシナリオでソース認証を提供するためのプロトコルです。Teslaは、通信と計算のオーバーヘッドが少ない効率的なプロトコルであり、多数の受信機に拡大し、パケット損失を許容します。テスラは、送信者と受信機の間のゆるい時間同期に基づいています。ソース認証は、メッセージ認証コード（MAC）チェーンを使用することにより、Teslaで実現されます。安全なリアルタイムトランスポートプロトコル（SRTP）内でのTeslaの使用は、[RFC4383]で公開されており、マルチメディアデータを保護するためにSRTPが適用されるシナリオでマルチキャスト認証をターゲットにしています。このソリューションは、テスラパラメーターが帯域外のメカニズムによって利用可能になることを前提としています。
[RFC4442] specifies payloads for MIKEY to bootstrap TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches described above by sending the MIKEY message via unicast, multicast, or broadcast. This approach provides the necessary parameter payload extensions for the usage of TESLA in SRTP. Nevertheless, if the parameter set is also sufficient for other TESLA use cases, it can be applied as well.
[RFC4442]は、SRTPを使用した安全なグループ通信のソース認証のために、MikeyからBootstrap Teslaのペイロードを指定します。テスラは、ユニキャスト、マルチキャスト、またはブロードキャストを介してマイキーメッセージを送信することにより、上記のマイキーキー管理アプローチの1つを使用してブートストラップされる可能性があります。このアプローチは、SRTPでのTeslaの使用に必要なパラメーターペイロード拡張機能を提供します。それにもかかわらず、パラメーターセットで他のテスラユースケースにも十分である場合、同様に適用できます。
This extension specifies a new Type (the Key ID Information Type) for the General Extension Payload. This is used in, e.g., the Multimedia Broadcast/Multicast Service (MBMS) specified in the 3rd Generation Partnership Project (3GPP). MBMS requires the use of MIKEY to convey the keys and related security parameters needed to secure the multimedia that is multicast or broadcast.
この拡張機能は、一般的な拡張ペイロードの新しいタイプ（キーID情報タイプ）を指定します。これは、例えば、第3世代パートナーシッププロジェクト（3GPP）で指定されたマルチメディアブロードキャスト/マルチキャストサービス（MBMS）で使用されます。MBMSは、マルチキャストまたはブロードキャストのマルチメディアを保護するために必要なキーと関連するセキュリティパラメーターを伝えるためにMikeyを使用する必要があります。
One of the requirements that MBMS puts on security is the ability to perform frequent updates of the keys. The rationale behind this is that it will be costly for subscribers to re-distribute the decryption keys to non-subscribers. The cost for re-distributing the keys using the unicast channel should be higher than the cost of purchasing the keys for this scheme to have an effect. To achieve this, MBMS uses a three-level key management, to distribute group keys to the clients, and be able to re-key by pushing down a new group key. MBMS has the need to identify which types of keys are involved in the MIKEY message and their identity.
MBMSがセキュリティにかける要件の1つは、キーの頻繁な更新を実行できることです。この背後にある理論的根拠は、加入者が復号化キーを非補助者に再配布するのに費用がかかるということです。ユニキャストチャネルを使用してキーを再配布するためのコストは、このスキームのキーを購入するコストよりも高くなる必要があります。これを達成するために、MBMSは3階建てのキー管理を使用して、クライアントにグループキーを配布し、新しいグループキーを押し下げることで再キーできるようになります。MBMSには、マイキーメッセージとそのアイデンティティにどのタイプのキーが関与しているかを特定する必要があります。
[RFC4563] specifies a new Type for the General Extension Payload in MIKEY, to identify the type and identity of involved keys. Moreover, as MBMS uses MIKEY both as a registration protocol and a re-key protocol, this RFC specifies the necessary additions that allow MIKEY to function both as a unicast and multicast re-key protocol in the MBMS setting.
[RFC4563]は、関連するキーのタイプとアイデンティティを特定するために、Mikeyの一般的な拡張ペイロードの新しいタイプを指定します。さらに、MBMSはMikeyを登録プロトコルとRekeyプロトコルの両方として使用しているため、このRFCはMBMS設定でのユニキャストとマルチキャストの再キープロトコルの両方としてMikeyが機能できるようにする必要な追加を指定します。
The document [RFC4909] specifies a new general extension payload type for use in the Open Mobile Alliance (OMA) Browser and Content Broadcast (BCAST) group. OMA BCAST's service and content protection specification uses short-term key message and long-term key message payloads that in certain broadcast distribution systems are carried in MIKEY. The document defines a general extension payload to allow possible extensions to MIKEY without defining a new payload. The general extension payload can be used in any MIKEY message and is part of the authenticated or signed data part. Note that only a parameter description is included, but no key information.
ドキュメント[RFC4909]は、Open Mobile Alliance（OMA）ブラウザーおよびコンテンツブロードキャスト（BCAST）グループで使用する新しい一般的な拡張ペイロードタイプを指定します。OMA BCASTのサービスおよびコンテンツ保護仕様では、特定のブロードキャスト配信システムがMikeyで運ばれる短期キーメッセージと長期キーメッセージペイロードを使用します。このドキュメントでは、一般的な拡張ペイロードを定義して、新しいペイロードを定義せずにマイキーに可能な拡張機能を可能にします。一般的な拡張ペイロードは、任意のMikeyメッセージで使用でき、認証されたまたは署名されたデータパーツの一部です。パラメーターの説明のみが含まれているが、重要な情報はないことに注意してください。
The document [RFC4771] defines a new integrity transform for SRTP [RFC3711] providing the option to also transmit the Roll Over Counter (ROC) as part of dedicated SRTP packets. This extension has been defined for use in the 3GPP multicast/broadcast service. While the communicating parties did agree on a starting ROC, in some cases the receiver may not be able to synchronize his ROC with the one used by the sender even if it is signaled to him out of band. Here the new extension provides the possibility for the receiver to re-synchronize to the sender's ROC. To signal the use of the new integrity transform, new definitions for certain MIKEY payloads need to be done. These new definitions comprise the integrity transform itself as well as a new integrity transform parameters. Moreover, the document specifies additional parameter, to enable the usage of different integrity transforms for SRTP and SRTCP.
ドキュメント[RFC4771]は、専用のSRTPパケットの一部としてロールオーバーカウンター（ROC）を送信するオプションを提供するSRTP [RFC3711]の新しい整合性変換を定義します。この拡張機能は、3GPPマルチキャスト/ブロードキャストサービスで使用するために定義されています。通信当事者はスターティングROCに同意しましたが、場合によっては、レシーバーは、バンドから彼に合図されていても、送信者が使用したROCとROCを同期させることができない場合があります。ここで、新しい拡張機能は、受信者が送信者のROCに再同期する可能性を提供します。新しい整合性変換の使用を信号するには、特定のマイキーペイロードの新しい定義を行う必要があります。これらの新しい定義は、整合性変換そのものと新しい整合性変換パラメーターを含みます。さらに、ドキュメントは追加のパラメーターを指定して、SRTPとSRTCPの異なる整合性変換の使用を可能にします。
While MIKEY and its extensions provide a variety of choices in terms of modes of operation, an implementation may choose to simplify its behavior. This can be achieved by operating in a single mode of operation when in the Initiator's role. Where PKI is available and/or required, an implementation may choose, for example, to start all sessions in RSA-R mode, and it would be trivial for it to act as a Responder in public key mode. If envelope keys are cached, it can then also choose to do re-keying in shared key mode. It is outside the scope of MIKEY or MIKEY extensions if the caching of envelope keys is allowed. This is a matter of the configuration of the involved components. This local configuration is also outside the scope of MIKEY. In general, modes of operation where the Initiator generates keying material are useful when two peers are aware of each other before the MIKEY communication takes place. If a peer chooses not to operate in the public key mode, it may reject the certificate of the Initiator. The same applies to peers that choose to operate in one of the DH modes exclusively.
Mikeyとその拡張機能は、動作モードの点でさまざまな選択肢を提供しますが、実装はその動作を簡素化することを選択する場合があります。これは、イニシエーターの役割で単一の動作モードで動作することで実現できます。PKIが利用可能または必要な場合、実装がRSA-Rモードですべてのセッションを開始することを選択する場合があり、公開キーモードのレスポンダーとして機能することは些細なことです。エンベロープキーがキャッシュされている場合、共有キーモードで再キーイングを行うこともできます。エンベロープキーのキャッシュが許可されている場合、マイキーまたはマイキーエクステンションの範囲外です。これは、関係するコンポーネントの構成の問題です。このローカル構成は、Mikeyの範囲外にもあります。一般に、Mikey通信が行われる前に2人のピアが互いに認識している場合、イニシエーターがキーイング材料を生成する操作モードは、キーイング材料を生成することです。ピアが公開キーモードで操作しないことを選択した場合、イニシエーターの証明書を拒否する可能性があります。同じことが、DHモードの1つで独占的に動作することを選択したピアにも当てはまります。
Forward MIKEY modes, where the Initiator provides the key material, like public key or shared key mode when used in SIP/SDP may lead to complications in some call scenarios, for example, forking scenarios where key derivation material gets distributed to multiple parties. As mentioned earlier, this may be impractical as some of the destinations may not have the resources to validate the message and may cause the Initiator to drop the session invitation. Even in the case in which all parties involved have all the prerequisites for interpreting the MIKEY message received, there is a possible problem with multiple Responders starting media sessions using the same key. While the SSRCs will be different in most of the cases, they are only 32 bits long and there is a high probability of a two-time pad problem. This is due to the support of scenarios like forking (see also Section 5.2) or retargeting (see also Section 5.3), where a two-time pad occurs if two branches have the same TEK (based on the MIKEY key establishment) and choose the same 32-bit SSRC for the SRTP streams and transmit SRTP packets. As suggested earlier, forward modes are most useful when the two peers are aware of each other before the communication takes place (as is the case in key renewal scenarios when costly public key operations can be avoided by using the envelope key).
フォワードマイキーモード。イニシエーターは、SIP/SDPで使用される場合の公開キーや共有キーモードなどのキーマテリアルを提供する場合があります。たとえば、キー派生材料が複数の関係者に配布されるシナリオの分岐シナリオなど、いくつかのコールシナリオで合併症につながる可能性があります。前述のように、これはメッセージを検証するためのリソースを持っていない可能性があり、イニシエーターにセッションの招待状をドロップする可能性があるため、これは非現実的である可能性があります。関係するすべての当事者が、受信したMikeyメッセージを解釈するためのすべての前提条件を持っている場合でさえ、同じキーを使用してメディアセッションを開始する複数のレスポンダーに問題があります。SSRCはほとんどの場合に異なりますが、長さはわずか32ビットで、2回のPAD問題の可能性が高くなります。これは、フォーキング（セクション5.2も参照）やリターゲティング（セクション5.3も参照）などのシナリオのサポートによるものです。ここで、2つのブランチに同じTEK（Mikeyキー設立に基づいて）がある場合に2回のパッドが発生し、選択し、SRTPストリームとSRTPパケットを送信するための同じ32ビットSSRC。前述のように、通信が行われる前に2人のピアがお互いを認識している場合、フォワードモードは最も役立ちます（エンベロープキーを使用して、コストのかかる公開キー操作を回避できるキー更新シナリオの場合のように）。
The following list gives an idea how the different MIKEY modes may be used or combined, depending on available key material at the Initiator side.
次のリストは、イニシエーター側で利用可能なキーマテリアルに応じて、さまざまなマイキーモードをどのように使用または組み合わせるかを示しています。
1. If the Initiator has a PSK with the Responder, it uses the PSK mode.
1. イニシエーターにレスポンダーを備えたPSKがある場合、PSKモードを使用します。
2. If the Initiator has a PSK with the Responder, but needs PFS or knows that the Responder has a policy that both parties should provide entropy to the key, then it uses the DH-HMAC mode.
2. イニシエーターがレスポンダーを備えたPSKを持っているが、PFSを必要とするか、レスポンダーに両当事者がキーにエントロピーを提供する必要があるというポリシーがあることを知っている場合、DH-HMACモードを使用します。
3. If the Initiator has the RSA key of the Responder, it uses the RSA mode to establish the TGK. Note that the TGK may be used as PSK together with Option 1 for further key management operations.
3. イニシエーターにレスポンダーのRSAキーがある場合、RSAモードを使用してTGKを確立します。TGKは、さらに重要な管理操作を行うために、オプション1と一緒にPSKとして使用できることに注意してください。
4. If the Initiator does not expect the responder to have his certificate, he may use RSA-R. Using RSA-R, he can provide the Initiator's certificate information in-band to the receiver. Moreover, the Initiator may also provide a random number that can be used by the receiver for key generation. Thus, both parties can be involved in the key management. But as the inclusion of the random number cannot be forced by the Initiator, true PFS cannot be provided. Note that in this mode, after establishing the TGK, it may be used as PSK with other MIKEY modes.
4. イニシエーターがレスポンダーが証明書を持っていることを期待していない場合、彼はRSA-Rを使用することができます。RSA-Rを使用して、彼はイニシエーターの証明書情報を帯域内にレシーバーに提供できます。さらに、イニシエーターは、キー生成にレシーバーが使用できる乱数を提供する場合があります。したがって、両当事者は主要な管理に関与することができます。しかし、乱数を包含することはイニシエーターによって強制されないため、真のPFSを提供することはできません。このモードでは、TGKを確立した後、他のMikeyモードとPSKとして使用できることに注意してください。
5. The Initiator uses DH-SIGN when PFS is required by his policy and he knows that the Responder has a policy that both parties should provide entropy. Note that also in this mode, after establishing the TGK, it may be used as PSK with other MIKEY modes.
5. イニシエーターは、PFSが彼のポリシーで要求されている場合、DH-Signを使用し、レスポンダーが両当事者がエントロピーを提供するというポリシーを持っていることを知っています。また、このモードでは、TGKを確立した後、他のMikeyモードとPSKとして使用できることに注意してください。
6. If no PSK or certificate is available at the Initiator's side (and likewise at the responder's side) but lower-level security (like TLS or IPsec) is in place the user may use the unprotected mode of MIKEY. It has to considered that using the unprotected mode enables intermediate nodes like proxies to actually get the exchanged master key in plain. This may not be intended, especially in cases where the intermediate node is not trusted.
6. PSKまたは証明書がイニシエーター側（および同様にレスポンダー側）に利用可能であるが、低レベルのセキュリティ（TLSやIPSECなど）が導入されていない場合、ユーザーは保護されていないマイキーモードを使用する場合があります。保護されていないモードを使用すると、プロキシなどの中間ノードが実際に交換されたマスターキーをプレーンで取得できるようにすることを考慮する必要があります。これは、特に中間ノードが信頼されていない場合に意図されていない場合があります。
Besides the available key material, choosing between the different modes of MIKEY depends strongly on the use case. This section will depict dedicated scenarios to discuss the feasibility of the different modes in these scenarios. A comparison of the different modes of operation regarding the influences and requirements to the deploying infrastructure as well as the cryptographic strength can be found in [SIP-MEDIA]. The following list provides the most prominent call scenarios and are matter of further discussion:
利用可能な重要な資料に加えて、Mikeyの異なるモードを選択することは、ユースケースに強く依存します。このセクションでは、これらのシナリオのさまざまなモードの実現可能性について説明するための専用のシナリオを描写します。展開インフラストラクチャと暗号化強度に対する影響と要件に関するさまざまな操作モードの比較は、[SIP-Media]にあります。次のリストは、最も顕著なコールシナリオを提供し、さらなる議論の問題です。
o Early Media
o 初期のメディア
o Forking
o フォーキング
o Call Transfer/Redirect/Retarget
o 転送/リダイレクト/リターゲットを呼び出します
o Shared Key Conferencing
o 共有キー会議
The term early media describes two different scenarios. The first one relates to the case where media data are received before the actual SDP signaling answer has been received. This may arise through the different latency on the signaling and media path. This case is often referred to as media before signaling answer. The second scenario describes the case were media data are send from the callee before sending the final SIP 200 OK message. This situation appears usually in call center scenarios, when queuing a waiting loop or when providing personal ring tones.
初期メディアという用語では、2つの異なるシナリオについて説明しています。最初のものは、実際のSDPシグナリングの回答が受信される前にメディアデータが受信される場合に関連しています。これは、信号とメディアパスの異なるレイテンシを通じて発生する可能性があります。このケースは、回答を通知する前にメディアと呼ばれることがよくあります。2番目のシナリオは、最終的なSIP 200 OKメッセージを送信する前に、メディアデータがCalleeから送信されることです。この状況は、通常、コールセンターのシナリオに、待機中のループを列に並べるとき、または個人的なリングトーンを提供するときに表示されます。
In early media scenarios, SRTP data may be received before the answer over the SIP signaling arrives. The two MIKEY modes, which only require one message to be transported (Section 3.1 and Section 3.2), work nicely in early media situations, as both sender and receiver have all the necessary parameters in place before actually sending/ receiving encrypted data. The other modes, featuring either Diffie-Hellman key agreement (Section 3.3, Section 3.5, and Section 3.6) or the enhanced asymmetric variant (Section 3.7), suffer from the requirements that the Initiator has to wait for the response before being able to decrypt the incoming SRTP media. In fact, even if early media is not used, in other words if media is not sent before the SDP answer, a similar problem may arise from the fact that SIP/ SDP signaling has to traverse multiple proxies on its way back and media may arrive before the SDP answer. It is expected that this delay would be significantly shorter than in the case of early media though.
It is worth mentioning here that security descriptions [RFC4568] have basically the same problem as the initiating end needs the SDP answer before it can start decrypting SRTP media.
ここで、セキュリティの説明[RFC4568]には、SRTPメディアの復号化を開始する前に、開始の終了がSDPの回答が必要になるのと基本的に同じ問題があることに言及する価値があります。
To cope with the early media problem, there are further approaches to describe security preconditions [RFC5027]; i.e., certain preconditions need to be met to enable voice data encryption. One example, for instance, is that a scenario where a provisional response, containing the required MIKEY parameter, is sent before encrypted media is processed.
初期のメディアの問題に対処するために、セキュリティの前提条件を説明するためのさらなるアプローチがあります[RFC5027]。つまり、音声データ暗号化を有効にするために、特定の前提条件を満たす必要があります。たとえば、1つの例は、暗号化されたメディアが処理される前に必要なMikeyパラメーターを含む暫定的な応答が送信されるシナリオです。
In SIP forking scenarios, a SIP proxy server sends an INVITE request to more than one location. This means also that the MIKEY payload, which is part of the SDP, is sent to several (different) locations. MIKEY modes supporting signatures may be used in forking scenarios (Section 3.3 and Section 3.7) as here the receiver can validate the signature. There are limitations with the symmetric key encryption as well as the asymmetric key encryption modes (Section 3.1 and Section 3.2). This is due to the fact that in symmetric encryption the recipient needs to possess the symmetric key before handling the MIKEY data. For asymmetric MIKEY modes, if the sender is aware of the forking he may not know in advance to which location the INVITE is forked and thus may not use the right receiver certificate to encrypt the MIKEY envelope key. Note that the sender may include several MIKEY containers into the same INVITE message to cope with forking, but this requires the knowledge of all forking targets in advance and also requires the possession of the target certificates. It is out of the scope of MIKEY to specify behavior in such a case. MIKEY Diffie Hellman modes or MIKEY-RSA_R Section 3.7 do not have this problem. In scenarios where the sender is not aware of forking, only the intended receiver is able to decrypt the MIKEY container.
SIPフォーキングシナリオでは、SIPプロキシサーバーが複数の場所に招待リクエストを送信します。これはまた、SDPの一部であるMikeyペイロードがいくつかの（異なる）場所に送信されることを意味します。署名をサポートするMikeyモードは、レシーバーが署名を検証できるため、シナリオ（セクション3.3およびセクション3.7）のフォーキング（セクション3.3およびセクション3.7）で使用できます。対称キー暗号化と、非対称キー暗号化モードには制限があります（セクション3.1およびセクション3.2）。これは、対称暗号化では、マイキーデータを処理する前に対称キーを所有する必要があるという事実によるものです。非対称Mikeyモードの場合、送信者がフォークを知っている場合、招待状がフォークされている場所を事前に知らない場合があるため、適切なレシーバー証明書を使用してマイキーエンベロープキーを暗号化できない場合があります。送信者は、フォーキングに対処するためにいくつかのマイキーコンテナを同じ招待メッセージに含めることができますが、これにはすべてのフォーキングターゲットの知識が事前に必要であり、ターゲット証明書の所有も必要です。そのような場合の動作を指定するのは、マイキーの範囲外です。Mikey Diffie HellmanモードまたはMikey-RSA_Rセクション3.7にはこの問題はありません。送信者がフォーキングを認識していないシナリオでは、意図したレシーバーのみがマイキーコンテナを復号化できます。
If forking is combined with early media, the situation gets aggravated. If MIKEY modes requiring a full roundtrip are used, like the signed Diffie-Hellman, multiple responses may overload the end device. An example is forking to 30 destinations (group pickup), while MIKEY is used with the signed Diffie-Hellman mode together with security preconditions. Here, every target would answer with a provisional response, leading to 30 signature validations and Diffie-Hellman calculations at the sender's site. This may lead to a prolonged media setup delay.
フォーキングが初期のメディアと組み合わされると、状況は悪化します。署名されたdiffie-hellmanのように、完全な往復を必要とするMikeyモードが使用される場合、複数の応答がエンドデバイスに過負荷になる場合があります。例は、30の目的地（グループピックアップ）への分岐ですが、マイキーは署名されたdiffie-hellmanモードとセキュリティの前提条件とともに使用されます。ここでは、すべてのターゲットが暫定的な応答で応答し、30の署名検証と送信者のサイトでのdiffie-hellmanの計算につながります。これにより、メディアセットアップの長期遅延が発生する可能性があります。
Moreover, depending on the MIKEY mode chosen, a two-time pad may occur in dependence of the negotiated key material and the SSRC. For the non Diffie-Hellman modes other than RSA-R, a two-time pad may occur when multiple receivers pick the same SSRC.
さらに、選択したMikeyモードに応じて、交渉された重要な資料とSSRCの依存性で2回のパッドが発生する場合があります。RSA-R以外の非Diffie-Hellmanモードの場合、複数の受信機が同じSSRCを選択すると、2回のパッドが発生する場合があります。
In a SIP environment, MIKEY exchange is tied to SDP offer/answer and irrespective of the implementation model used for call transfer the same properties and limitations of MIKEY modes apply as in a normal call setup scenario.
SIP環境では、Mikey ExchangeはSDPオファー/回答に関連付けられており、コール転送に使用される実装モデルに関係なく、通常のコールセットアップシナリオと同じプロパティとMikeyモードの制限が適用されます。
In certain SIP scenarios, the functionality of redirect is supported. In redirect scenarios, the call initiator gets a response that the called party for instance has temporarily moved and may be reached at a different destination. The caller can now perform a call establishment with the new destination. Depending on the originally chosen MIKEY mode, the caller may not be able to perform this mode with the new destination. To be more precise, MIKEY-PSK and MIKEY-DHHMAC require a pre-shared secret in advance. MIKEY-RSA requires the knowledge about the target's certificate. Thus, these modes may influence the ability of the caller to initiate a session.
特定のSIPシナリオでは、リダイレクトの機能がサポートされています。リダイレクトシナリオでは、コールイニシエーターは、たとえば、コールパーティーが一時的に移動し、別の目的地で到達する可能性があるという応答を取得します。発信者は、新しい目的地でコール施設を実行できるようになりました。元々選択されたマイキーモードによっては、発信者は新しい宛先でこのモードを実行できない場合があります。より正確には、Mikey-PSKとMikey-DHHMACには事前に事前に共有された秘密が必要です。Mikey-RSAには、ターゲットの証明書に関する知識が必要です。したがって、これらのモードは、発信者がセッションを開始する能力に影響を与える可能性があります。
Another functionality that may be supported in SIP is retargeting. In contrast to redirect, the call initiator does not get a response about the different target. The SIP proxy sends the request to a different target about receiving a redirect response from the originally called target. This most likely will lead to problems when using MIKEY modes requiring a pre-shared key (MIKEY-PSK, MIKEY-DHHMAC) or where the caller used asymmetric key encryption (MIKEY-RSA) because the key management was originally targeted to a different destination.
SIPでサポートされる可能性のある別の機能は、リターゲティングです。リダイレクトとは対照的に、コールイニシエーターは異なるターゲットについての応答を取得しません。SIPプロキシは、元々呼ばれるターゲットからリダイレクト応答を受信することについて、リクエストを別のターゲットに送信します。これは、事前共有キー（Mikey-PSK、Mikey-DHHMAC）を必要とするMikeyモードを使用する場合、または発信者が非対称キー暗号化（Mikey-RSA）を使用した場合、キー管理が元々別の目的地をターゲットにされていたため、問題につながる可能性が最も高くなります。。
First of all, not all modes of MIKEY support shared key conferencing. Mainly the Diffie-Hellman modes cannot be used straight-forward for conferencing as this mechanism results in a pair wise shared secret key. All other modes can be applied in conferencing scenarios by obeying the Initiator and Responder roles; i.e., the half roundtrip modes need to be initiated by the conferencing unit to be able to distribute the conferencing key. The remaining full roundtrip mode, MIKEY RSA-R, will be initiated by the client, while the conferencing unit provides the conferencing key based on the received certificate.
まず第一に、Mikeyサポートのすべてのモードが主要な会議を共有するわけではありません。主に、このメカニズムはペアの共有秘密鍵をもたらすため、diffie-hellmanモードを会議に簡単に使用することはできません。他のすべてのモードは、イニシエーターとレスポンダーの役割に従うことにより、会議シナリオに適用できます。つまり、ハーフラウンドトリップモードは、会議キーを配布できるように、会議ユニットによって開始する必要があります。残りのフルラウンドトリップモードであるMikey RSA-Rはクライアントによって開始され、会議ユニットは受け取った証明書に基づいて会議キーを提供します。
An example conferencing architecture is defined in the IETF's XCON WG. The scope of this working group relates to a mechanism for membership and authorization control, a mechanism to manipulate and describe media "mixing" or "topology" for multiple media types (audio, video, text), a mechanism for notification of conference-related events/changes (for example, a floor change), and a basic floor control protocol. A document describing possible use case scenarios is available in [RFC4597].
会議アーキテクチャの例は、IETFのXCON WGで定義されています。このワーキンググループの範囲は、複数のメディアタイプ（オーディオ、ビデオ、テキスト）のメディアを操作して記述するメディアを操作して記述するメカニズム、および会議関連の通知のメカニズムである、メンバーシップと承認制御のメカニズム、会議関連のメカニズムに関連しています。イベント/変更（たとえば、フロアの変更）、および基本的なフロアコントロールプロトコル。可能なユースケースシナリオを説明するドキュメントは、[RFC4597]で利用できます。
The following two tables summarize the discussion from the previous subsections. The first table matches the scenarios discussed in this section to the different MIKEY modes.
次の2つの表は、以前のサブセクションからの議論を要約しています。最初のテーブルは、このセクションで説明されているシナリオとさまざまなマイキーモードと一致します。
MIKEY Early Secure Retarget Redirect Shared
mode Media Forking Key Conf
---------------------------------------------------------------------
PSK (3.1) Yes Yes*
RSA (3.2) Yes Yes*
DH-SIGN (3.3) Yes* Yes Yes
Unprotected (3.4) Yes
DH-HMAC (3.5)
RSA-R (3.7) Yes Yes Yes Yes
* In centralized conferencing, the media mixer needs to send the MIKEY Initiator message.
* 集中化された会議では、メディアミキサーはマイキーイニシエーターメッセージを送信する必要があります。
The following table maps the MIKEY modes to key management-related properties.
次の表は、Mikeyモードを主要な管理関連のプロパティにマッピングします。
MIKEY Manual Needs PFS Key Generation
mode Keys PKI Involvement
--------------------------------------------------------------
PSK (3.1) Yes No No Initiator
RSA (3.2) No Yes No Initiator
DH-SIGN (3.3) No Yes Yes Both
Unprotected (3.4) No No No Initiator
DH-HMAC (3.5) Yes No Yes Both
RSA-R (3.7) No Yes No Both*
* Assumed the Initiator provides the (optional) RAND value
* イニシエーターが（オプションの）ランド値を提供すると仮定しました
MIKEY defines message formats to transport key information and security policies between communicating entities. It does not define the embedding of these messages into the used signaling protocol. This definition is provided in separate documents, depending on the used signaling protocol. Nevertheless, MIKEY can also be transported over plain UDP or TCP to port 2269.
Mikeyは、コミュニケーションエンティティ間で主要な情報とセキュリティポリシーを輸送するメッセージ形式を定義しています。これらのメッセージの埋め込みを使用しているシグナリングプロトコルに定義しません。この定義は、使用されるシグナル伝達プロトコルに応じて、個別のドキュメントで提供されます。それにもかかわらず、マイキーは、プレーンUDPまたはTCPを介してポート2269に輸送することもできます。
Several IETF-defined protocols utilize the Session Description Protocol (SDP, [RFC4566]) to transport the session parameters. Examples are the Session Initiation Protocol (SIP, [RFC3261] or the Gateway Control Protocol (GCP, [RFC5125]). The transport of MIKEY messages as part of SDP is described in [RFC4567]. Here, the complete MIKEY message is base64 encoded and transmitted as part of the SDP part of the signaling protocol message. Note that as several key distribution messages may be transported within one SDP container, [RFC4567] also comprises an integrity protection regarding all supplied key distribution attempts. Thus, bidding-down attacks will be recognized. Regarding RTSP, [RFC4567] defines header extensions allowing the transport of MIKEY messages. Here, the initial messages uses SDP, while the remaining part of the key management is performed using the header extensions.
いくつかのIETF定義プロトコルは、セッション説明プロトコル（SDP、[RFC4566]）を利用してセッションパラメーターを輸送します。例は、セッション開始プロトコル（SIP、[RFC3261]またはゲートウェイ制御プロトコル（GCP、[RFC5125]）です。SDPの一部としてのマイキーメッセージの輸送は[RFC4567]に記載されています。ここでは、完全なマイキーメッセージはbase64エンコードです。シグナリングプロトコルメッセージのSDP部分の一部として送信されます。1つのSDPコンテナ内でいくつかの重要な分布メッセージが輸送される可能性があるため、[RFC4567]は、供給されたすべての重要な分配試行に関する整合性保護も含まれます。RTSPに関しては、[RFC4567]はマイキーメッセージの輸送を可能にするヘッダー拡張機能を定義します。ここでは、最初のメッセージはSDPを使用し、キー管理の残りの部分はヘッダー拡張機能を使用して実行されます。
MIKEY is also applied in ITU-T protocols like H.323, which is used to establish communication sessions similar to SIP. For H.323, a security framework exists, which is defined in H.235. Within this framework, H.235.7 [H.235.7] describes the usage of MIKEY and SRTP in the context of H.323. In contrast to SIP, H.323 uses ASN.1 (Abstract Syntax Notation). Thus, there is no need to encode the MIKEY container as base64. Within H.323, the MIKEY container is binary encoded.
Mikeyは、H.323のようなITU-Tプロトコルにも適用されます。これは、SIPと同様の通信セッションを確立するために使用されます。H.323の場合、H.235で定義されているセキュリティフレームワークが存在します。このフレームワーク内で、H.235.7 [H.235.7]は、H.323のコンテキストでのMikeyとSRTPの使用について説明しています。SIPとは対照的に、H.323はASN.1を使用します（要約構文表記）。したがって、Mikeyコンテナをbase64としてエンコードする必要はありません。H.323内では、Mikeyコンテナがバイナリエンコードされています。
Besides MIKEY, there exist several approaches to handle the security parameter establishment. This is due to the fact that some limitations in certain scenarios have been seen. Examples are early media and forking situations as described in Section 5. The following list provides a short summary about possible alternatives:
マイキー以外に、セキュリティパラメーターの確立を処理するためのいくつかのアプローチが存在します。これは、特定のシナリオのいくつかの制限が見られたという事実によるものです。例は、セクション5で説明されているように、初期のメディアとフォーキングの状況です。次のリストは、可能な選択肢に関する短い要約を示しています。
o sdescription - [RFC4568] describes a key management scheme, which uses SDP for transport and completely relies on underlying protocol security. For transport, the document defines an SDP attribute transmitting all necessary SRTP parameter in clear. For security, it references TLS and S/MIME. In contrast to MIKEY, the SRTP parameter in the Initiator-to-Responder direction is actually sent in the message from the Initiator to the Responder rather than vice versa. This may lead to problems in early media scenarios.
o sdescription- [RFC4568]は、輸送にSDPを使用し、基礎となるプロトコルセキュリティに完全に依存する重要な管理スキームを説明しています。トランスポートの場合、ドキュメントは、必要なすべてのSRTPパラメーターをクリアに送信するSDP属性を定義します。セキュリティのために、TLSとS/MIMEを参照します。Mikeyとは対照的に、イニシエーターからレスポンダーへの方向のSRTPパラメーターは、実際にイニシエーターからレスポンダーにメッセージで送信されます。これは、初期のメディアシナリオで問題につながる可能性があります。
o sdescription with early media support - [WING-MMUSIC] enhances the above scheme with the possibility to also be usable in early media scenarios, when security preconditions are not used.
o 早期メディアサポートを使用した説明 - [Wing -Music]セキュリティの前提条件が使用されていない初期のメディアシナリオでも使用できる可能性がある上記のスキームが強化されます。
o Encrypted Key Transport for Secure RTP - [MCGREW-SRTP] is an extension to SRTP that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control, and to handle situations caused by SIP forking and early media. It may also be used in conjunction with MIKEY.
o SECURE RTPの暗号化されたキートランスポート - [McGrew -SRTP]は、SRTCP内のSRTPマスターキー、ロールオーバーカウンター、およびその他の情報の安全な輸送を提供するSRTPの拡張です。この施設により、SRTPは最小限の制御を伴う分散型会議のために働き、SIPフォーキングと初期のメディアによって引き起こされる状況を処理できます。また、Mikeyと組み合わせて使用することもできます。
o Diffie-Hellman support in SDP - [BAUGHER] defines a new SDP attribute for exchanging Diffie-Hellman public keys. The attribute is an SDP session-level attribute for describing DH keys, and there is a new media-level parameter for describing public keying material for SRTP key generation.
o SDPのDiffie-Hellmanサポート - [Baugher]は、Diffie-Hellmanのパブリックキーを交換するための新しいSDP属性を定義しています。属性は、DHキーを記述するためのSDPセッションレベルの属性であり、SRTPキー生成の公開キーイング資料を記述するための新しいメディアレベルのパラメーターがあります。
o DTLS-SRTP describing SRTP extensions for DTLS - [AVT-DTLS] describes a method of using DTLS key management for SRTP by using a new extension that indicates that SRTP is to be used for data protection and that establishes SRTP keys.
o DTLSのSRTP拡張機能を記述するDTLS-SRTP - [AVT-DTLS]は、SRTPがデータ保護に使用され、SRTPキーを確立することを示す新しい拡張機能を使用して、SRTPのDTLSキー管理を使用する方法を説明します。
o ZRTP - [ZIMMERMANN] defines ZRTP as RTP header extensions for a Diffie-Hellman exchange to agree on a session key and parameters for establishing SRTP sessions. The ZRTP protocol is completely self-contained in RTP and does not require support in the signaling protocol or assume a PKI.
o ZRTP- [Zimmermann]は、ZRTPをRTPヘッダー拡張機能として定義し、SRTPセッションを確立するためのセッションキーとパラメーターに同意するようにします。ZRTPプロトコルはRTPで完全に自己完結型であり、シグナル伝達プロトコルでのサポートを必要としないか、PKIを想定していません。
There has been a long discussion regarding a preferred key management approach in the IETF coping with the different scenarios and requirements continuously sorting out key management approaches. During IETF 68, three options were considered: MIKEY in an updated version (referred to as MIKEYv2), ZRTP, and DTLS-SRTP. The potential key management protocol for the standards track for media security was voted in favor of DTLS-SRTP. Thus, the reader is pointed to the appropriate resources for further information on DTLS-SRTP [AVT-DTLS]. Note that MIKEY has already been deployed for setting up SRTP security context and is also targeted for use in MBMS applications.
重要な管理アプローチを継続的に整理するさまざまなシナリオと要件に対処するIETFにおける好ましい主要な管理アプローチに関する長い議論がありました。IETF 68では、3つのオプションが考慮されました。更新されたバージョン（MikeyV2と呼ばれる）、ZRTP、およびDTLS-SRTPのMikey。メディアセキュリティの標準トラックの潜在的な主要な管理プロトコルは、DTLS-SRTPに有利に投票されました。したがって、読者は、DTLS-SRTP [AVT-DTLS]の詳細については、適切なリソースを指摘されています。Mikeyは、SRTPセキュリティコンテキストをセットアップするために既に展開されており、MBMSアプリケーションでの使用も対象となっていることに注意してください。
For MIKEY and the extensions to MIKEY, IANA registrations have been made. Here only a link to the appropriate IANA registration is provided to avoid inconsistencies. The IANA registrations for MIKEY payloads can be found under http://www.iana.org/assignments/mikey-payloads. These registrations comprise the MIKEY base registrations as well as registrations made by MIKEY extensions regarding the payload.
マイキーとマイキーへの拡張機能のために、IANA登録が行われました。ここでは、矛盾を避けるために、適切なIANA登録へのリンクのみが提供されます。MikeyペイロードのIANA登録は、http：//www.iana.org/assignments/mikey-payloadsの下にあります。これらの登録では、マイキーベースの登録と、ペイロードに関するマイキーエクステンションによる登録が含まれます。
The IANA registrations for MIKEY port numbers can be found under http://www.iana.org/assignments/port-numbers (search for MIKEY).
Mikeyポート番号のIANA登録は、http：//www.iana.org/assignments/port-numbers（Mikeyの検索）にあります。
This document does not define extensions to existing protocols. It rather provides an overview about the set of MIKEY modes and available extensions and provides information about the applicability of the different modes in different scenarios to support the decision making for network architects regarding the appropriate MIKEY scheme or extension to be used in a dedicated target scenario. Choosing between the different schemes described in this document strongly influences the security of the target system as the different schemes provide different levels of security and also require different infrastructure support.
このドキュメントは、既存のプロトコルへの拡張機能を定義しません。むしろ、Mikeyモードと利用可能な拡張機能のセットに関する概要を提供し、さまざまなシナリオのさまざまなモードの適用性に関する情報を提供して、専用のターゲットシナリオで使用される適切なMikeyスキームまたは拡張機能に関するネットワークアーキテクトの意思決定をサポートします。。このドキュメントで説明されているさまざまなスキームを選択すると、さまざまなスキームがさまざまなレベルのセキュリティを提供し、インフラストラクチャのサポートも必要とするため、ターゲットシステムのセキュリティに強く影響します。
As this document is based on the MIKEY base specification as well as the different specifications of the extensions, the reader is referred to the original documents for the specific security considerations.
このドキュメントは、Mikey Base仕様と拡張機能のさまざまな仕様に基づいているため、読者は特定のセキュリティに関する考慮事項については、元のドキュメントを参照されます。
The authors would like to thank Lakshminath Dondeti for his document reviews and for his guidance.
著者は、Lakshminath Dondetiのドキュメントレビューと彼の指導に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
[AVT-DTLS] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, February 2008.
[AVT-DTLS] McGrew、D。およびE. Rescorla、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのキーを確立するためのキーを確立する」、2008年2月、作業進行中。
[BAUGHER] Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Multimedia Sessions", Work in Progress, February 2006.
[Baugher] Baugher、M。and D. McGrew、「Diffie-Hellmanはマルチメディアセッションと交流する」、2006年2月に進行中の作業。
[H.235.7] ""ITU-T Recommendation H.235.7: Usage of the MIKEY Key Management Protocol for the Secure Real Time Transport Protocol (SRTP) within H.235"", 2005.
[H.235.7] "" ITU-T推奨H.235.7：H.235 "内の安全なリアルタイム輸送プロトコル（SRTP）のMikey Key Management Protocolの使用法、2005年。
[ISO_sec_time] ""ISO/IEC 18014 Information technology - Security techniques - Time-stamping services, Part 1- 3.http://www.oasis-open.org/committees/ documents.php?wg_abbrev=security"", 2002.
[ISO_SEC_TIME] "" ISO/IEC 18014情報技術 - セキュリティテクニック - タイムスタンプサービス、パート1- 3.http：//www.oasis-open.org/committees/ documents.php？wg_abbrev = security "、2002。
[MCGREW-SRTP] McGrew, D., "Encrypted Key Transport for Secure RTP", Work in Progress, March 2007.
[MSEC-MIKEY] Milne, A., "ECC Algorithms for MIKEY", Work in Progress, June 2007.
[MSEC-Mikey] Milne、A。、「MikeyのECCアルゴリズム」、2007年6月、進行中の作業。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装」、RFC 1305、1992年3月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412] Orman、H。、「The Oakley Key Deicination Protocol」、RFC 2412、1998年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082] Perrig、A.、Song、D.、Canetti、R.、Tygar、J。、およびB. Briscoe、「タイミング効率の高いストリーム損失耐性認証（TESLA）：マルチキャストソース認証変換紹介」、RFC 4082、2005年6月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.
[RFC4383] Baugher、M。and E. Carrara、「安全なリアルタイム輸送プロトコル（SRTP）でのタイミングの効率的なストリーム損失耐性認証（TESLA）の使用」、RFC 4383、2006年2月。
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006.
[RFC4442] Fries、S。and H. Tschofenig、「ブートストラップの時限効率的なストリーム損失耐性認証（TESLA）」、RFC 4442、2006年3月。
[RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
[RFC4563] Carrara、E.、Lehtovirta、V。、およびK. Norrman、「マルチメディアインターネットキーイング（Mikey）の一般的な拡張ペイロードの重要なID情報タイプ」、2006年6月、RFC 4563。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567] Arkko、J.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（SDP）およびリアルタイムストリーミングプロトコル（RTSP）のキー管理拡張機能」、RFC4567、2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568] Andreasen、F.、Baugher、M。、およびD. Wing、「セッション説明プロトコル（SDP）メディアストリームのセキュリティ説明」、RFC 4568、2006年7月。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC4597] Even、R。およびN. Ismail、「会議シナリオ」、RFC 4597、2006年8月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650] Euchner、M。、「HMAC-Authenticated Diffie-Hellman for Multimedia Internet Keying（Mikey）」、RFC 4650、2006年9月。
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006.
[RFC4738] Ignjatic、D.、Dondeti、L.、Audet、F。、およびP. Lin、「Mikey-RSA-R：マルチメディアインターネットキーイング（Mikey）のキー分布の追加モード」、RFC 4738、2006年11月。
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC4771] Lehtovirta、V.、Naslund、M。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）のロールオーバーキャリングロールオーバーカウンター」、RFC 4771、2007年1月。
[RFC4909] Dondeti, L., Castleford, D., and F. Hartung, "Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport", RFC 4909, June 2007.
[RFC4909] Dondeti、L.、Castleford、D。、およびF. Hartung、「マルチメディアインターネットキーイング（Mikey）オープンモバイルアライアンスBCAST LTKM/STKM Transportの一般的な拡張ペイロード」、RFC 4909、2007年6月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007.
[RFC5027] Andreasen、F。およびD. Wing、「セッション説明プロトコル（SDP）メディアストリームのセキュリティ前提条件」、RFC 5027、2007年10月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125]テイラー、T。、「RFC 3525の歴史的な再分類」、RFC 5125、2008年2月。
[SAML_overview] Huges, J. and E. Maler, "Security Assertion Markup Language (SAML) 2.0 Technical Overview, Working Draft", 2005.
[saml_overview] Huges、J。and E. Maler、「セキュリティアサーションマークアップ言語（SAML）2.0技術概要、ワーキングドラフト」、2005年。
[SIP-MEDIA] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", Work in Progress, June 2008.
[SIP-Media] Wing、D.、Fries、S.、Tschofenig、H。、およびF. Audet、「メディアセキュリティ管理プロトコルの要件と分析」、2008年6月、進行中の作業。
[WING-MMUSIC] Raymond, R. and D. Wing, "Security Descriptions Extension for Early Media", Work in Progress, October 2005.
[Wing-Mmusic] Raymond、R。and D. Wing、「初期メディアのセキュリティ説明拡張」、2005年10月、進行中の作業。
[ZIMMERMANN] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, June 2008.
[Zimmermann] Zimmermann、P.、Johnston、A。、およびJ. Callas、「ZRTP：Secure RTPのメディアパスキー契約」、2008年6月、作業進行中。
Authors' Addresses
著者のアドレス
Steffen Fries Siemens Corporate Technology Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Steffen Fries Siemens Corporate Technology Otto-Hahn-Ring6 Munich、Bavaria 81739ドイツ
EMail: steffen.fries@siemens.com
Dragan Ignjatic Polycom 3605 Gilmore Way Burnaby, BC V5G 4X5 Canada
ドラガンイグナティックポリコム3605ギルモアウェイバーナビー、BC V5G 4x5カナダ
EMail: dignjatic@polycom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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.
この文書は、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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
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への情報をお問い合わせください。