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.
マルチメディアインターネットキーイング（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.
この文書は、一般にMIKEYベース文書、並びに定義または定義の過程にあるされているMIKEYのための既存の拡張機能の概要を提供します。これは、より多くのユースケースシナリオと動機に洞察ならびに異なる鍵配布スキームの利点と欠点を提供するために、開発者または建築家のための情報の追加のソースとして意図されています。この文書で説明するユースケースが強くセッション記述プロトコル（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.
鍵の配布は、必要な者に暗号鍵を配布するプロセスについて説明します。 MIKEY [RFC3830]、マルチメディア、インターネットキーイングは、セキュアリアルタイムトランスポートプロトコル[RFC3711]のセキュリティコンテキストの確立のための支援に焦点を当てて定義されています。そのRFC 3830は、それが一般的なアプローチを特徴と鍵配送方式への拡張を可能として、唯一のSRTPのために使用されるように制限されていません。したがって、それはまた、他のプロトコルのためのセキュリティパラメータのネゴシエーションのために使用することができます。
For MIKEY, meanwhile, seven key distribution methods are described:
MIKEYのために、一方で、7つの鍵配布方法が説明されています。
o Symmetric key distribution as defined in [RFC3830] (MIKEY-PSK)
[RFC3830]（MIKEY-PSK）で定義されている対称鍵配布O
o Asymmetric key distribution as defined in [RFC3830] (MIKEY-RSA)
[RFC3830]（MIKEY-RSA）で定義されるように非対称鍵配布O
o Diffie-Hellman key agreement protected by digital signatures as defined in [RFC3830] (MIKEY-DHSIGN)
[RFC3830]（MIKEY-DHSIGN）で定義されているデジタル署名によって保護OのDiffie-Hellman鍵合意
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)
[RFC4650]（MIKEY-DHHMAC）で定義されるように、対称事前共有キーによって保護されたOの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)
[RFC4738]（MIKEY-RSA-R）で定義されるように、帯域内の証明書の提供と（非対称暗号化に基づく）O非対称鍵配布
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.
[RFC3830]で定義された最初の4つのモードのいずれも完全にフィットしないシナリオがあったとして、後者の3つのモードはMIKEYに対する拡張であることに留意されたいです。アルゴリズムの強化とSRTP以外のプロトコルをサポートする新しいペイロードの定義を備えたMIKEYへのさらなる拡張があります。
Algorithm extensions are defined in the following document:
アルゴリズムの拡張は、以下の文書で定義されています。
o Elliptic Curve Cryptography (ECC) algorithms for MIKEY as defined in [MSEC-MIKEY]
[MSEC-MIKEY]で定義されるようMIKEY用O楕円曲線暗号（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]
[RFC4442]で定義されるように、OブートストラップTESLA、時限効率ストリーム損失トレラント認証のための新たなペイロードを定義する（テスラ）プロトコル[RFC4082]
o The Key ID information type for the general extension payload as defined in [RFC4563]
[RFC4563]で定義されるように一般的な拡張ペイロードのキーID情報タイプO
o Open Mobile Alliance (OMA) Broadcast (BCAST) MIKEY General Extension Payload Specification as defined in [RFC4909]
[RFC4909]で定義されるようにオープン・モバイル・アライアンス（OMA）ブロードキャスト（BCAST）MIKEY一般拡張ペイロード仕様O
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.
[RFC4771]で定義されるようにO整合性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の特定のプロトコルの働きに触発されています。これらのプロトコルの働きは、らウィングに詳細に記載されています。 [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.
TEKとパラメータ/ポリシーのセットを含む、セキュリティプロトコル、データのためのSAデータセキュリティ協会情報。
CS Crypto Session, uni- or bidirectional data stream(s), protected by a single instance of a security protocol.
CS暗号化セッション、セキュリティプロトコルの単一のインスタンスによって保護ユニまたは双方向データストリーム（S）。
CSB Crypto Session Bundle, collection of one or more Crypto Sessions, which can have common TGKs (see below) and security parameters.
CSB暗号化セッションバンドル、共通TGKs（下記参照）とセキュリティパラメータを持つことができる1つまたは複数の暗号化セッションのコレクション。
CS ID Crypto Session ID, unique identifier for the CS within a CSB.
CS ID暗号化セッションID、CSB内でCSの一意の識別子。
CSB ID Crypto Session Bundle ID, unique identifier for the CSB.
CSB ID暗号化セッションバンドル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世代キー、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.
TEKトラフィック暗号化キー、CSを保護するためのセキュリティプロトコルで使用されるキーは、（このキーは、セキュリティプロトコルで直接使用することができるか、セキュリティプロトコルに応じて、さらに鍵を導出するために使用することができます）。 TEKは、CSBのTGKから派生しています。
TGK re-keying the process of re-negotiating/updating the TGK (and consequently future TEK(s)).
TGK再交渉/ TGKを更新する（その結果、将来のTEK（S））の処理を再キーイング。
Initiator the initiator of the key management protocol, not necessarily the initiator of the communication.
鍵管理プロトコルの開始、必ずしも通信の開始剤を開始剤。
Responder the responder in the key management protocol.
鍵管理プロトコルで応答レスポンダ。
Salting key a random or pseudo-random (see [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
E（K、M）鍵KとMの暗号化
RAND random value
RANDランダム値
T timestamp
Tのタイムスタンプ
CERTx the certificate of x
xの証明書をCERTx
SIGNx the signature from x using the private key of x
xの秘密鍵を使用して、xから署名をSIGNx
PKx the public key of x
PKX xの公開鍵
IDx the identity of x
xのアイデンティティをIDX
[] an optional piece of information
情報の[]オプションピース
{} zero or more occurrences
{} 0回以上の繰り返し
|| concatenation
||連結
| OR (selection operator)
| OR（選択演算子）
^ exponentiation
^累乗
XOR exclusive or
XOR排他的論理和
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キーデータ転送ペイロード、暗号化されたサブペイロードのセットと、メッセージ認証コード（MAC）を含みます。
V MIKEY Verification Message
V MIKEY検証メッセージ
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プロキシの能力をフォーク。 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.
再書き込みのRequest-URIそれによって明示的ユーザエージェントクライアントに通知することなく、要求の宛先を変更する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についての概要を提供します。 MIKEYは、異種環境でマルチメディアセッションを確保するために暗号コンテキストの設定に焦点を当てています。 MIKEYは、主にピア・ツー・ピア、一対多、および小型の単純な（対話型）グループのために使用されることが意図されます。 MIKEYの1つの目的は、TEK生成キー（TGK）に由来し、セキュリティプロトコル用の入力として使用されるトラフィック暗号化キー（TEK）を含む、セキュリティプロトコルのためのデータセキュリティアソシエーション（SA）を生成することです。
MIKEY supports the possibility of establishing keys and parameters for more than one security protocol (or for several instances of the same security protocol) at the same time. The concept of Crypto Session Bundle (CSB) is used to denote a collection of one or more Crypto Sessions that can have common TGK and security parameters, but that obtain distinct TEKs from MIKEY.
MIKEYは、同時に（または同じセキュリティプロトコルの複数のインスタンスのための）複数のセキュリティプロトコルのためのキーとパラメータを確立する可能性をサポートしています。暗号化セッションバンドル（CSB）の概念は、共通のTGK及びセキュリティパラメータを有することができる1つまたは複数の暗号化セッションのコレクションを表すために使用され、それはMIKEYから別個の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往復して進むことができます。他の方式は、フルラウンドトリップ（例えば、ディフィー・ヘルマンベースのスキーム）を必要とする半往復内に進むことができるMIKEYスキームは、（例えば、事前共有鍵に基づく）が存在することに留意されたいです。イニシエータのメッセージ（I_MESSAGE）の主な目的は、安全な方法でレスポンダへの1つ以上のTGKs（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鍵配布スキームは緩やかに同期したクロックに依存していることに注意してください。クロック同期が使用できない場合、MIKEY（参照[RFC3830]）の再生処理は動作しない可能性があり。これは、MIKEYは、再生処理のためのチャレンジレスポンスメカニズムを使用していないという事実によるものです。代わりに、タイムスタンプは、メッセージキャッシュと一緒に使用されます。このように、必要な同期はどちら側にキャッシュすることができるメッセージの数に依存します。したがって、MIKEYは、デプロイメント環境内のクロック・スキューに応じて、キャッシュサイズを調整することをお勧めします。また、RFC 3830は[ISO_sec_time] ISO時刻同期プロトコルをお勧めします。リプレイ取り扱いが利用できない場合、攻撃者は、彼が両側で異なるTGKsにつながる、以前の盗聴古いメッセージを再生することができるかもしれません。これらはMIKEY（例えば、SRTPまたはTESLA）を利用するアプリケーションに供給されるように、両側は異なるキーに依存してもよく、したがって、互いに通信することができません。 MIKEYで送信タイムスタンプに適用されるフォーマットは、[RFC1305]に記載のNTPフォーマットに一致しなければなりません。そのようなSIPエンドポイントのような他のケースでは、信頼されたアウトバウンドプロキシから時間を導出することにより、クロックの同期が適切であり得ます。
The different MIKEY-related schemes are compared regarding the following criteria:
異なるMIKEY関連のスキームは、以下の基準に関する比較されています。
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.
PKIのサポートがこの方式をサポートする必要がある場合の状態：PKIへの依存、O。 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.
完全転送秘密（PFS）のOの提供は：長期鍵材料を損なうことは以前に長期に由来したセッション鍵を損なわない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を持たないことを意図して、ランダムに選択されます。同じ識別子を選択する複数のソースの確率は低いが、すべての（S）RTP実装を検出し、衝突を解決するために用意されなければなりません。それにもかかわらず、マルチメディア通信フォーク支持シナリオ（セクション5.2を参照）、またはリターゲット（セクション5.3を参照）に衝突が主要いわゆるする2回のパッドを発生し得ます。すなわち、同じ鍵が異なる宛先へのメディアストリームのために使用されます。二つのブランチが（MIKEY鍵の確立に基づいて）同じTEKを有し、SRTPストリームのための同じ32ビットのSSRCを選択した場合に発生します。 SRTP鍵導出は、同じセッション鍵を生成する（入力値が同じであるように）SSRCsが同じであるとしても、パケットごとに同じ初期化ベクトルを導出します。二つの時間パッドは、同じ宛先へのメディアストリームのために起こり得ることに留意されたいです。これは、[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.
鍵管理の非対称的なオプションを使用して、イニシエータは、送信するキーマテリアル（TGKs）を生成し、それが順番に受信者の公開鍵で暗号化された、いわゆるエンベロープキーで暗号化送信します。封筒キー、乱数であるENV-キーは、認証キーとENC-キーを導出するために使用されます。また、エンベロープキーがさらに暗号化セッションを確立するために事前共有キーとして使用することができます。応答メッセージはオプションであり、相互認証やエラー通知のために使用することができます。
Initiator Responder
イニシエータレスポンダ
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オプションでは、双方が共有された秘密に貢献する方法で、イニシエータとレスポンダの間の共有秘密の確立を可能にします。ディフィー・ヘルマン鍵合意は、デジタル署名を使用して認証（および完全性が保護されます）。
Initiator Responder
イニシエータレスポンダ
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, DHi, SIGNi --->
R_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方式のため、必要に応じて事前に証明書を取得する必要がないことです。さらに、それはまた、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に依存していることです。マルチパーティ会議は、ちょうどMIKEY-DHSIGNを使用してサポートされていません。それにもかかわらず、設立のDiffie-Hellmanの秘密は、グループ関連のセキュリティパラメータをブートストラップするために事前共有キーとして機能することができます。また、上述した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節に示した対称鍵暗号化オプションに基づいていますが、NULL暗号化およびNULL認証アルゴリズムで使用されています。それは、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
TGK = g^(xi * yi) TGK = g^(xi * yi)
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鍵の完全性保護のために、[RFC4650]はHMAC SHA-1の使用を義務付け。 Diffie-Hellmanグループについては、[RFC3830]は参照されます。したがって、のDiffie-Hellmanグループ "OAKLEY5" [RFC2412]をサポートするために必須です。 MIKEY内の他のDiffie-Hellmanグループを使用することも可能です。これは、公正、相互鍵合意、完全転送秘密、およびPKIには依存性があるので、このオプションは、また、いくつかの利点を持っているRFC 3830.に応じて新しいマッピングサブペイロードと関連付けられたポリシーのペイロードを定義することによって行うことができ、 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.
この動作モードは、多くのクライアントのための共有秘密がプロビジョニングされている中央の信頼されたサーバーがある展開で効率的な仕組みを提供します。このようなセットアップは、例えば、企業のPBX（構内交換機）、サービスプロバイダプロキシなどは3.1節で説明したプレーンな事前共有鍵暗号ベースのモードとは対照的に可能性があり、このモードでは完全転送秘密を提供していますだけでなく、関係する両当事者の鍵生成に積極的に関与。
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ミーティング中もSAML支援DHのアプローチについてIETF MSECメーリングリストの長い議論がありました。このアイデアは、別の文書として提出されていません。鍵管理アプローチの一般的な要件を満たすために目標とされるようにもかかわらず、議論はここに反映されます。これらの要件は、次のように要約することができます。
5. Provide liveliness tests when involved parties do not have a reliable clock
関係者が信頼できる時計を持っていないとき5.活気テストを提供
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.
要件のすべてを満たすためには、（のDiffie-HellmanキーとSAMLを使用してIDを認証し、ユーザエージェントの（UAの）SIPサーバ署名要素と一緒に鍵確立のための古典的なのDiffie-Hellman鍵合意プロトコルを使用することが提案されましたセキュリティアサーションマークアップ言語[SAML_overview]）アプローチ。ここでは、クライアントの公開のDiffie-Hellmanの資格情報は、SAMLアサーションを形成するために、サーバによって署名されている（以下CREDと呼ばれる）、他のクライアントとの後のセッションのために使用されることができます。この主張は、少なくとも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).
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のラウンドトリップを提案しています。これは、セッションキーで保護されたナンスを、交換することによって達成されます。第二ラウンドトリップはまた、グループ鍵の配布のために使用することができ、またはより強力なセッションキーの弱いDHキーを活用します。第二ラウンドトリップのトリガは、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.
グループキーが提供される場合、RANDは、そのグループ鍵によって置換されるであろうことに留意されたいです。
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.
二往復では、このアプローチはまた、活気のチェックが必要な場合、他のキーの配布方法のすべてのオプションを提供します。第二ラウンドトリップの欠点は、これらのメッセージは、シグナリングプロトコルのコールフローに統合する必要があることです。ストレートフォワードコールでは、1回の往復では、セッションをセットアップするには十分かもしれません。したがって、この第二の往復を交換するために追加のメッセージが必要となります。
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.
このセクションの冒頭で述べた異なる基準に関しては、このアプローチの利点は、公正、相互の鍵合意（両当事者がキーに提供）、および完全転送秘密です。二往復を通じて、同期したクロックへの依存を回避することができます。また、この第二の往復は、グループ鍵の配布を可能にし、従って、主にポイント・ツー・ポイントにもマルチパーティ会議からのスケーラビリティを向上させます。 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）サーバが正常にするUAの2に対してのman-in-the-middle（MITM）攻撃を仕掛けることができます。また、2台のSIPサーバは、どちらかが正常に自分のUAに対する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
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節で述べた非対称鍵配布に比べていくつかの利点を有しています。ここでは、送信者と受信者は、それがマイキーイニシエータメッセージで送信することができるよう、事前に他のピアの証明書を知っている必要はありません（受信機が事前に証明書を知っている場合は、RFC 3830のMIKEY-RSA方式を用いてもよいです） 。したがって、このメッセージの受信側は、セッションパラメータを暗号化し、MIKEYの応答メッセージの一部としてそれらを返送するために、受信した鍵材料を利用することができます。証明書のチェックが署名権限に応じて行うことができます。証明書は、公的に認められた機関によって署名されている場合、証明書の検証には、一般的に知られている認証局の公開鍵を用いて、簡単な方法で行うことができます。他の場合には、追加の工程が必要であってもよいです。欠点は何の完全転送秘密が提供されていないということです。
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で、セッションの招待状は、リターゲットやフォークすることができます。彼らは、キーのネゴシエーションを行うために、複数の往復を必要とするかもしれないように、単一のよく知られたレスポンダをターゲットにイニシエータを必要とMIKEYモードは、ここでは実際的ではありません。レスポンダは、鍵導出のために使用される秘密の材料を生成することを可能にすることによって、このモードでは、効率的な鍵配送方式を可能にします。キーは、ユニキャストの使用事例でCSB-ID及びペイロードRANDから導出されるので、イニシエータは、鍵材料に寄与することができることに留意されたいです。このモードでは、複数のクライアントが知られているサーバーに接続されており、キーをダウンロードしているマルチキャストのシナリオにも便利です。レスポンダの作業負荷が大幅にパブリックキーモードでMIKEYに比べて、これらのシナリオに減少しています。これは、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で使用するために説明したデジタル署名方式への拡張を提案します。これらの拡張機能は、他のECCの実装と標準とMIKEYを揃えるために定義されています。
The motivation for supporting ECC within MIKEY stems from the following advantages:
MIKEY以内に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のような）他の非対称の技術と比較して、同じセキュリティレベルを維持してかなり小さいキーを必要とします。楕円曲線アルゴリズムは、非対称鍵サイズの広範な成長なしのAdvanced Encryption Standard（AES）128、192、および256ビットのキーと一致するセキュリティを提供することができます。
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.
[MSEC-MIKEY]で述べたように、O、実装は、楕円曲線アルゴリズムを大幅他の推奨アルゴリズムよりも性能及びセキュリティ・パー・ビットを向上させることができることを示しています。
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鍵配布方式を高めるために、いくつかのECCベースのメカニズムを提案しています。
o Use of ECC methods extending the Diffie-Hellman key exchange: MIKEY-DHSIGN with ECDSA or ECGDSA
ECDSAまたはECGDSAでMIKEY-DHSIGN：O ECCの方法の使用はのDiffie-Hellman鍵交換を拡張します
o Use of ECC methods extending the Diffie-Hellman key exchange: MIKEY-DHSIGN with ECDH
ECDHとMIKEY-DHSIGN：O ECCの方法の使用はのDiffie-Hellman鍵交換を拡張します
o Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES)
楕円曲線統合暗号化スキーム（MIKEY-ECIES）の使用O
o Use of Elliptic Curve Menezes-Qu-Vanstone Scheme(MIKEY-ECMQV)
楕円曲線メネゼス - ク-Vanstone著スキーム（MIKEY-ECMQV）の使用O
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
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
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の使用は、SRTPは、マルチメディアデータを保護するために適用されるシナリオ、マルチキャスト認証をターゲットに、[RFC4383]に掲載されました。この溶液をTESLAパラメータは、アウトオブバンドメカニズムによって利用可能にされることを前提としています。
[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.
MIKEYは、SRTPを使用して、安全なグループ通信のソースの認証のためTESLAをブートストラップする[RFC4442]はペイロードを指定します。テスラは、ユニキャスト、マルチキャスト、またはブロードキャストを介しMIKEYメッセージを送信することにより、上述のMIKEY鍵管理のアプローチのいずれかを使用してブートストラップすることができます。このアプローチは、SRTPでTESLAの利用に必要なパラメータのペイロードの拡張機能を提供します。パラメータセットは、他の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は、キーの種類はMIKEYメッセージと自分のアイデンティティに関与しているかを特定する必要があります。
[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を使用するようにまた、このRFCはMIKEYは、MBMS設定におけるユニキャストおよびマルチキャスト再鍵プロトコルの両方として機能することを可能にする必要な追加を指定します。
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]はオープン・モバイル・アライアンス（OMA）ブラウザとコンテンツブロードキャスト（BCAST）グループで使用するための新しい一般的な拡張ペイロードタイプを指定します。 OMA BCASTのサービスおよびコンテンツ保護仕様は、特定の放送配信システムでMIKEYで運ばれ、短期キーメッセージと長期キーメッセージのペイロードを使用しています。文書は、新しいペイロードを定義することなく、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に再同期化するために可能性を提供します。新しい整合性の使用は変換信号には、特定のMIKEYペイロードのための新たな定義がなされる必要があります。これらの新しい定義は、新しい整合性パラメータを変換だけでなく、自分自身を変革整合性を備えています。また、文書が異なる整合性の使用量が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拡張子の範囲外です。これは、関連するコンポーネントの構成の問題です。このローカル設定は、マイキーの範囲外でもあります。 MIKEY通信が行われる前に、2つのピアがお互いを認識している場合、一般に、イニシエータは、鍵材料生成の動作モードが有用です。ピアは、公開鍵モードで動作しないことを選択した場合、それは、イニシエータの証明書を拒否することができます。同じことは、独占的にDHモードのいずれかで動作することを選択したピアに適用されます。
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
SIP / SDPで使用される場合、イニシエータは、公開鍵または共有キーモードと同様に、鍵材料を提供するフォワードMIKEYモードは、鍵導出材料は、複数のパーティに配布されますシナリオをフォーク、例えば、一部のコールのシナリオにおける合併症をもたらし得ます。先に述べたように目的地のいくつかは、メッセージを検証するためのリソースを持っていない可能性があり、イニシエータは、セッション招待をドロップする原因となり、これは実用的ではありません。でも、すべての関係者は、受信しマイキーメッセージを解釈するための前提条件をすべて持っている場合には、同じキーを使用してメディアセッションを開始する複数のレスポンダに問題がある可能性があります。 SSRCsは、ほとんどの場合では異なるであろうが、それらは唯一です
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).
32ビット長と2回のパッドの問題の可能性が高いです。これは、2本の枝が（MIKEY鍵の確立に基づいて）同じTEKを持っている場合は2回のパッドが発生したフォークのようなシナリオのサポート（セクションも5.2を参照）またはリターゲット（セクションも5.3を参照）、にし、選択しました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.
以下のリストは、異なるMIKEYモードが使用されるか、またはイニシエータ側で利用可能な鍵材料に応じて、組み合わせることができる方法のアイデアを与えます。
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を必要とするか、Responderが、それは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.
イニシエータは、レスポンダのRSAキーを持っている場合3.、それはTGKを確立するために、RSAモードを使用しています。 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を使用して、彼はResponderが両当事者がエントロピーを提供するべきポリシーを持っていることを知っています。このモードでは、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.
（TLSやIPsecなど）6.ないPSKまたは証明書は、（同様にレスポンダの側で）開始者側で利用できない場合は、より低いレベルのセキュリティは、ユーザーがMIKEYの保護されていないモードを使用することができる場所です。これは、保護されていないモードを使用して、実際にプレーンで交換し、マスターキーを取得するには、プロキシのような中間ノードを可能にしていると考えなければなりません。これは、特に中間ノードが信頼されていない場合には、意図されないことがあります。
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:
利用できる主要材料以外にも、マイキーの異なるモード間で選択することがユースケースに強く依存します。このセクションでは、これらのシナリオで異なるモードの実現可能性を議論するために、専用のシナリオを描いてます。展開インフラならびに暗号強度に影響と要件に関して異なる動作モードの比較は、[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メッセージを送信する前に、被呼者から送信されました。待機ループをキューに入れるとき、または個人用の着信音を提供する場合に、このような状況では、コールセンターのシナリオに通常表示されます。
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.
SIPシグナリングを超える答えが到着する前に初期メディアのシナリオでは、SRTPデータを受信することができます。 1つのメッセージのみを必要とする2つのMIKEYモードは、（3.1節と3.2節）、送信者と受信者の両方が実際に受信/暗号化されたデータを送信する前に、代わりにすべての必要なパラメータを持っているとして、早期のメディア状況でうまく働くに輸送されます。 Diffie-Hellman鍵（3.3節、3.5節、および第3.6節）、または拡張非対称バリアント（3.7節）のいずれかを搭載し、他のモードでは、イニシエータが解読できるようになる前に、応答を待つ必要がある要件に苦しみます入ってくるSRTPメディア。初期メディアを使用しない場合であっても、実際には、メディアがSDPアンサー前に送信されていない場合、換言すれば、同様の問題がSIP / SDPシグナリングがバックその途中で複数のプロキシを横断すると、メディアが到着するという事実から生じてもよいですSDPの答えの前に。この遅延はいえ初期メディアの場合よりも大幅に短くなることが期待されます。
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]を記述するための更なるアプローチがあります。すなわち、一定の前提条件は、音声データの暗号化を有効にするために満たす必要があります。一例では、例えば、暗号化されたメディアが処理される前に必要な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プロキシサーバは、複数の場所にINVITE要求を送ります。これは、SDPの一部であるMIKEYペイロードは、いくつかの（異なる）位置に送信されることも意味します。 MIKEY支持署名が署名を検証できるようにここで受信機シナリオ（3.3節及び3.7節）をフォークに使用することができるモードがあります。対称鍵暗号化による制限だけでなく、非対称鍵暗号化モード（3.1節と3.2節）があります。これは、対称暗号化では、受信者がMIKEYデータを取り扱う前に、対称鍵を所有する必要があるという事実によるものです。送信者がフォークを認識している場合は、非対称MIKEYモードについては、彼はMIKEYエンベロープキーを暗号化するために、右の受信証明書を使用することはできませんので、場所フォークされたINVITE事前に知っていて、ないかもしれません。送信者がフォークに対処するためにINVITEメッセージを同じにいくつかのMIKEYコンテナを含むことができることに注意してください、これは事前に全てのフォークのターゲットの知識を必要とし、また、ターゲット証明書の所持が必要です。このような場合の動作を指定するMIKEYの範囲外です。 MIKEYディフィーヘルマンモードやMIKEY-RSA_R 3.7節では、この問題はありません。送信者がフォークを認識していないシナリオでは、唯一意図受信機は、MIKEYコンテナを復号化することができます。
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.
フォークは、初期メディアと組み合わされた場合、状況は悪化します。完全なラウンドトリップを必要とMIKEYモードは符号付きのDiffie-Hellmanのように、使用される場合、複数の応答は、エンドデバイスをオーバーロードすることができます。 MIKEYセキュリティ前提条件と一緒に署名されたのDiffie-Hellmanモードで使用されている間例では、30件の宛先（グループピックアップ）に分岐されます。ここでは、すべてのターゲットは、送信者のサイトで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モードに応じて、2回のパッドがネゴシエート鍵材料及びSSRCに依存して発生し得ます。複数の受信機が同じSSRCを選ぶ際にRSA-R以外の非のDiffie-Hellmanモードについて、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交換は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.
まず第一に、マイキーのすべてのモードは、共有キー会議をサポートしていません。主の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モードこのセクションで説明したシナリオと一致します。
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
*想定開始剤（任意）RAND値を提供します
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は、通信エンティティ間の重要な情報とセキュリティポリシーを輸送するためにメッセージフォーマットを定義します。これは、使用されるシグナリングプロトコルにこれらのメッセージの埋め込みを定義していません。この定義は、使用されるシグナリングプロトコルに応じて、別の文書で提供されます。それにもかかわらず、MIKEYは、ポート2269に無地UDPまたはTCP上で転送することができます。
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
いくつかのIETF定義のプロトコルは、セッションパラメータを搬送するセッション記述プロトコル（SDP、[RFC4566]）を利用します。例は、セッション開始プロトコル（SIP、[RFC3261]またはゲートウェイコントロールプロトコル（GCP、[RFC5125]）である。SDPの一部としてMIKEYメッセージの輸送は[RFC4567]に記載されている。ここで、
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.
完全MIKEYメッセージは、base64エンコードされたシグナリングプロトコルメッセージのSDP部分の一部として送信されます。いくつかの鍵配布メッセージ一つSDP容器内に輸送することができるように、[RFC4567]は、すべての供給された鍵配信試行に関する完全性保護を含むことに留意されたいです。このように、入札ダウン攻撃が認識されます。 RTSPに関しては、[RFC4567]はMIKEYメッセージの輸送を可能にするヘッダ拡張を定義します。鍵管理の残りの部分はヘッダ拡張を使用して行われている間、ここで、最初のメッセージは、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はまた、SIPと同様の通信セッションを確立するために使用されているH.323のようなITU-Tプロトコルで適用されます。 H.323のために、セキュリティフレームワークが存在し、H.235で定義されています。この枠組みの中で、H.235.7は[H.235.7] H.323の文脈におけるMIKEYとSRTPの使用を記載しています。 SIPとは対照的に、H.323は、ASN.1（抽象構文記法）を使用します。したがって、BASE64としてMIKEY容器を符号化する必要はありません。 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:
MIKEYのほか、セキュリティパラメータの確立を処理するためのいくつかのアプローチが存在します。これは、特定のシナリオでは、いくつかの制限が見られているという事実によるものです。以下のリストは、可能な選択肢についての短い要約を提供し第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 sdescriptionアーリーメディアをサポートして - [翼MMUSIC]は、セキュリティ前提条件が使用されていない初期メディアシナリオに使用できる可能性のある上記のスキームを高めます。
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セキュアRTPのために暗号化された鍵交通 - [マグリュー-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] SRTPセッションを確立するためのRTPヘッダセッション鍵について合意するためのDiffie-Hellman交換のための拡張とパラメータとしてZRTPを定義します。 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と呼ばれる）でMIKEY、ZRTP、およびDTLS-SRTP。メディアセキュリティは、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.
MIKEYとMIKEYの拡張機能については、IANAの登録がなされています。ここだけで、適切なIANA登録へのリンクが不整合を回避するために設けられています。マイキーペイロードのためのIANA登録はhttp://www.iana.org/assignments/mikey-payloadsの下に見つけることができます。これらの登録は、MIKEYベースの登録だけでなく、ペイロードに関するMIKEYの拡張によって行われた登録を含みます。
The IANA registrations for MIKEY port numbers can be found under http://www.iana.org/assignments/port-numbers (search for MIKEY).
MIKEYポート番号のIANA登録は（MIKEYの検索）http://www.iana.org/assignments/port-numbersの下に見つけることができます。
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ベース仕様ならびに拡張の異なる仕様に基づいているように、読者は、特定のセキュリティ問題のために、元の文書と呼ばれます。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、RFC 3830、2004年8月。
[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]マグリュー、D.およびE.レスコラ、「データグラムトランスポート層セキュリティ（DTLS）拡張セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立するために」、進歩、2008年2月に作業。
[BAUGHER] Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Multimedia Sessions", Work in Progress, February 2006.
[BAUGHER] Baugher、M.とD.マグリュー、 "マルチメディアセッションのための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鍵管理プロトコルの使用方法 ""、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 =セキュリティ？ ""、2002 。
[MCGREW-SRTP] McGrew, D., "Encrypted Key Transport for Secure RTP", Work in Progress, March 2007.
[マグリュー-SRTP]マグリュー、D.、 "セキュアRTPのための暗号化キー交通"、進歩、2007年3月に作業。
[MSEC-MIKEY] Milne, A., "ECC Algorithms for MIKEY", Work in Progress, June 2007.
[MSEC-MIKEY]ミルン、A.、 "MIKEYのためのECCアルゴリズム"、進歩、2007年6月に作業。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装"、RFC 1305、1992年3月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]オーマン、H.、 "OAKLEYキー決意プロトコル"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[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.、歌、D.、カネッティ、R.、Tygar、J.、およびB.ブリスコウ、 "時限効率ストリーム損失トレラント認証（テスラ）：マルチキャスト発信元認証は、はじめの変換"、RFC 4082、 2005年6月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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.とE.カララ、RFC 4383、2006年2月「時限効率的なストリーム損失トレラントセキュアリアルタイム転送プロトコル（SRTP）での認証（TESLA）の使用」。
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006.
[RFC4442]フライドポテト、S.および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]カララ、E.、Lehtovirta、V.、およびK. Norrman、RFC 4563、2006年6月 "マルチメディア、インターネットキーイングで一般拡張ペイロード（MIKEY）のためのキーのID情報タイプ"。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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.、リンドホルム、F.、Naslund、M.、Norrman、K.、およびE.カララ、 "鍵管理拡張セッション記述プロトコル（SDP）、リアルタイムストリーミングプロトコル（RTSP）のための"、RFC 4567、2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]アンドレア、F.、Baugher、M.、およびD.翼、 "メディア・ストリームのセッション記述プロトコル（SDP）のセキュリティの説明"、RFC 4568、2006年7月。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC4597]であっても、R.とN.イスマイル、 "会議のシナリオ"、RFC 4597、2006年8月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650] EUCHNER、M.、 "マルチメディアインターネットキーイングのためのHMAC-認証済みのDiffie-Hellmanの（MIKEY）"、RFC 4650、2006年9月。
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006.
[RFC4738] Ignjatic、D.、Dondeti、L.、Audet、F.、およびP.林、 "MIKEY-RSA-R：マルチメディアインターネットキーイング（マイキー）で鍵配布の追加モード"、RFC 4738、2006年11月。
[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は、RFC 4771、2007年1月 "整合性は、セキュアリアルタイム転送プロトコル（SRTP）のためのロールオーバーカウンターを運ぶトランスフォーム"。
[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]、RFC 4909 "オープン・モバイル・アライアンスBCAST LTKM / STKM輸送のためのマルチメディアインターネットキーイング（MIKEY）一般的な拡張ペイロード" Dondeti、L.、キャッスルフォード、D.、およびF.アルトゥング、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]アンドレア、F.とD.ウィング、 "セキュリティの前提条件セッションの記述プロトコル（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.及び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]ウイング、D.、フライドポテト、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]レイモンド、R.とD.ウィング、 "早期メディアのためのセキュリティの説明拡張"、進歩、2005年10月に作業。
[ZIMMERMANN] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, June 2008.
[ZIMMERMANN]ツィンマーマン、P.、ジョンストン、A.、およびJ.カラス、 "ZRTP：セキュアRTPのためのメディアパス鍵合意"、進歩、2008年6月の作業。
Authors' Addresses
著者のアドレス
Steffen Fries Siemens Corporate Technology Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ステファンフライシーメンスコーポレート・テクノロジオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: steffen.fries@siemens.com
メールアドレス：steffen.fries@siemens.com
Dragan Ignjatic Polycom 3605 Gilmore Way Burnaby, BC V5G 4X5 Canada
ドラガンIgnjaticポリコム3605ギルモア・ウェイバーナビー、BC V5G 4×5カナダ
EMail: dignjatic@polycom.com
メールアドレス：dignjatic@polycom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。