RFC5197 日本語訳
5197 On the Applicability of Various Multimedia Internet KEYing(MIKEY) Modes and Extensions. S. Fries, D. Ignjatic. June 2008. (Format: TXT=76848 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Fries
Request for Comments: 5197 Siemens
Category: Informational D. Ignjatic
Polycom
June 2008
フライドポテトがコメントのために要求するワーキンググループS.をネットワークでつないでください: 5197年のジーメンスカテゴリ: 情報のD.Ignjatic Polycom2008年6月
On the Applicability of Various Multimedia Internet KEYing (MIKEY)
Modes and Extensions
様々なマルチメディアインターネットの合わせる(マイキー)モードと拡大の適用性に関して
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.
マルチメディアインターネットKeying(マイキー)はリアルタイムのアプリケーションに使用できるかぎ管理プロトコルです。 特に、それは、Secureレアル-時間Transportプロトコル(SRTP)のサポートに焦点を合わせながら、定義されました。 マイキー自身は、RFC3830の中で標準化されて、4つの主要な分配方法を定義します。 そのうえ、それは、プロトコルの拡大を許すために定義されます。 マイキーがますます受け入れるようになるのに従って、ベースプロトコルへの拡大は特に追加主要な分配方法ですが、ペイロード増進で起こります。
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.
このドキュメントはマイキーのための既存の拡大と同様に一般に、マイキー元にした文書に関する概観を提供します。定義されるか、または拡大は定義の途中に定義されました。 使用中の、より多くの洞察を提供する開発者か建築家が異なった主要な分配のために利点と損失と同様にシナリオと動機をケースに入れるので情報の追加源が計画するとき、それは意図します。 ケースが議論した使用は本書では強くSession記述プロトコル(SDP)が答える前に一般に、かぎ管理のためのそれらの中の挑戦にメディアを提供するひたむきなSIP呼び出しシナリオ、分岐、および共有された主要な会議に関連します。
Fries & Ignjatic Informational [Page 1] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[1ページ]のRFC5197マイキーモード適用性2008年6月
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語と定義. . . . . . . . . . . . . . . . . 4 3。 マイキーOverview. . . . . . . . . . . . . . . . . . . . . . . . 7 3.1。 あらかじめ共有されたキー(PSK)は分配. . . . . . . 9 3.2を保護しました。 公開鍵は主要な分配. . . . . . . . . . 9 3.3をコード化しました。 ディフィー-ヘルマンの主要なAgreementはデジタル署名. . . . . . . . . . . . . . . . . . . . . . . . 10 3.4で保護されました。 保護のない主要な分配. . . . . . . . . . . . . . . 11 3.5。 ディフィー-ヘルマンの主要なAgreementはプレ共有秘密キー.123.6で保護されました。 SAMLによって補助されたDH主要なAgreement. . . . . . . . . . . . . . 12 3.7。 証明書交換. . . . . . . . . . . . . . . . . . . . . . . . . 15 4がバンドにある非対称の主要な分配。 さらなるマイキーExtensions. . . . . . . . . . . . . . . . . . . 16 4.1。 ECCアルゴリズムサポート. . . . . . . . . . . . . . . . . . 16 4.1.1。 マイキー. . . . . . . . . . . . . . . . . 17 4.1.2における楕円形のCurve Integrated Encryption Schemeアプリケーション。 楕円曲線メネゼス-Qu-Vanstoneはマイキー. . . . . . . . . . . . . . . . . 17 4.2のアプリケーションを計画します。 テスラ. . . . . . . . 17 4.3を独力で進むための新しいマイキーPayload。 主要なID情報へのMBMS拡張子は.184.4をタイプします。 OMA BCASTマイキーGeneralの拡大有効搭載量仕様. 18 4.5。 保全を支持して、ロールオーバーカウンタ. . . . . . . . . . . . . . . . . . . . . . . . . 19 5を運んで、変形してください。 マイキーModes. . . . . . . . . . 19 5.1を選択と織り込むこと。 マイキーと早めのメディア. . . . . . . . . . . . . . . . . . 21 5.2。 マイキーと分岐. . . . . . . . . . . . . . . . . . . . 22 5.3。 マイキーと呼び出しは、Retarget.235.4に/を移すか、または向け直します。 マイキーと共有された主要な会議. . . . . . . . . . . . 23 5.5。 マイキーモード概要. . . . . . . . . . . . . . . . . . . . 24 6。 マイキーMessages. . . . . . . . . . . . . . . . . 24 7の輸送。 SRTPセキュリティパラメタ交渉. . 25 8のためのマイキーAlternatives。 マイキー-RelatedのIANA登録証明書. . . . . . . . . 26 9の概要。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 26 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 27 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 27 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 27
Fries & Ignjatic Informational [Page 2] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[2ページ]のRFC5197マイキーモード適用性2008年6月
1. Introduction
1. 序論
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.
主要な分配は必要なパーティーの暗号化キーを届ける過程について説明します。 マイキー[RFC3830](MultimediaインターネットKeying)は、Secureレアル-時間Transportプロトコル[RFC3711]のためにセキュリティ文脈の確立のサポートに焦点を合わせながら、定義されました。 RFC3830がSRTPだけに使用されるために制限されないことに注意してください、一般的方法を特徴として、主要な分配計画に拡大を考慮するとき。 したがって、また、それは他のプロトコルのためのセキュリティパラメタ交渉に使用されるかもしれません。
For MIKEY, meanwhile, seven key distribution methods are described:
マイキーに関しては、その間、7つの主要な分配方法が説明されます:
o Symmetric key distribution as defined in [RFC3830] (MIKEY-PSK)
o [RFC3830]で定義される対称鍵分配(マイキー-PSK)
o Asymmetric key distribution as defined in [RFC3830] (MIKEY-RSA)
o [RFC3830]で定義される非対称の主要な分配(マイキー-RSA)
o Diffie-Hellman key agreement protected by digital signatures as
defined in [RFC3830] (MIKEY-DHSIGN)
o [RFC3830]で定義されるようにデジタル署名で保護されたディフィー-ヘルマンの主要な協定(マイキー-DHSIGN)
o Unprotected key distribution (MIKEY-NULL)
o 保護のない主要な分配(マイキー-ヌル)
o Diffie-Hellman key agreement protected by symmetric pre-shared
keys as defined in [RFC4650] (MIKEY-DHHMAC)
o [RFC4650]で定義されるように左右対称のあらかじめ共有されたキーによって保護されたディフィー-ヘルマンの主要な協定(マイキー-DHHMAC)
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 セキュリティAssertion Markup Language(SAML)は定義されるようにディフィー-ヘルマンの主要な協定を促進しました。(別々のドキュメントとして利用可能でないことで、議論だけがこのドキュメント(マイキー-DHSAML)の中に反映されます)
o Asymmetric key distribution (based on asymmetric encryption) with
in-band certificate provision as defined in [RFC4738]
(MIKEY-RSA-R)
o バンドへの[RFC4738]で定義される証明書支給による非対称の主要な分配(非対称の暗号化に基づいています)(マイキー-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.
シナリオが[RFC3830]で定義された最初の4つのモードのいずれも完全に合わないところにあったとき後者の3つのモードがマイキーへの拡大であることに注意してください。 さらに、マイキーへのアルゴリズム増進を包括する拡大とSRTP以外のプロトコルをサポートする新しいペイロード定義があります。
Algorithm extensions are defined in the following document:
アルゴリズム拡大は以下のドキュメントで定義されます:
o Elliptic Curve Cryptography (ECC) algorithms for MIKEY as defined
in [MSEC-MIKEY]
o 中で定義されるマイキーのための楕円形のCurve Cryptography(ECC)アルゴリズム[MSECマイキー]
Fries & Ignjatic Informational [Page 3] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[3ページ]のRFC5197マイキーモード適用性2008年6月
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 Timed Efficient Stream Loss許容性があるAuthentication(テスラ)が定義されるとして議定書を作る[RFC4082]新しいペイロードを定義して、テスラを独力で進みます。[RFC4442]
o The Key ID information type for the general extension payload as
defined in [RFC4563]
o 情報が一般的な拡大ペイロードのために定義されるとしてタイプするKey ID[RFC4563]
o Open Mobile Alliance (OMA) Broadcast (BCAST) MIKEY General
Extension Payload Specification as defined in [RFC4909]
o 中で定義される開いているモバイルAlliance(OMA)放送(BCAST)マイキーExtension有効搭載量Specification司令官[RFC4909]
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のための保全オーバーTransform Carrying Roll Counter。 これがむしろSRTPへの拡大であり、マイキーが新しいパラメタを運ぶのが必要ですが、完全性のためにここに述べられていることに注意してください。
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:
このドキュメントは、マイキーを使用するとき、枠組みを提供するためにRFC3830に関する概観と異なった拡大との関係を提供します。 使用中の、より多くの洞察を提供する開発者か建築家が異なった主要な分配のために利点と損失と同様にシナリオと動機をケースに入れるので情報の追加源が計画するとき、それは意図します。 ケースが議論した使用は一般に、一般的な主要な分配メカニズムに問題が多いと判明したSIPの特定のプロトコル作業で本書では奮い立たせられます。 これらのプロトコル作業はWing、他で詳細に説明されます。 [SIP-メディア]とインクルード、以下:
o Early Media (i.e., media that arrives before the SDP answer)
o 早めのメディア(すなわち、SDPが答える前に到着するメディア)
o Forking
o 分岐します。
o Call Transfer/Redirect/Retarget
o Retargetに転送/再直接の/に電話をしてください。
o Shared Key Conferencing
o 共有された主要な会議
2. Terminology and Definitions
2. 用語と定義
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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です。
Fries & Ignjatic Informational [Page 4] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[4ページ]のRFC5197マイキーモード適用性2008年6月
Data SA Data Security Association information for the security
protocol, including a TEK and a set of parameters/
policies.
TEKと1セットのパラメタ/方針を含んでいて、セキュリティのためのデータSA Data Security Association情報は議定書を作ります。
CS Crypto Session, uni- or bidirectional data stream(s),
protected by a single instance of a security protocol.
CS Crypto Session(uniか双方向のデータ・ストリーム)はセキュリティプロトコルのただ一つの例で保護しました。
CSB Crypto Session Bundle, collection of one or more
Crypto Sessions, which can have common TGKs (see
below) and security parameters.
CSB Crypto Session Bundle、1Cryptoのセッションズの収集。(セッションズは、一般的なTGKs(以下を見る)とセキュリティパラメタを持つことができます)。
CS ID Crypto Session ID, unique identifier for the CS within
a CSB.
CS ID Crypto Session ID、CSBの中のCSに、ユニークな識別子。
CSB ID Crypto Session Bundle ID, unique identifier for the
CSB.
CSB ID Crypto Session Bundle 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(2回以上のパーティーによって同意されたしばらくストリング)はCSBと交際しました。 そして、TGKから、さらなるコミュニケーションを必要としないで、Trafficをコード化しているキーズは発生できます。
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 Trafficをコード化しているKey(セキュリティプロトコルによって使用される、CS(このキーは、直接セキュリティプロトコルによって使用されるか、またはセキュリティプロトコルによる一層のキーを引き出すのに使用されるかもしれない)を保護するキー)。 CSBのTGKからTEKsを得ます。
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.
主要なaに無作為の状態で塩味を付けさせるか、擬似ランダム([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
RANDの無作為の値
Fries & Ignjatic Informational [Page 5] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[5ページ]のRFC5197マイキーモード適用性2008年6月
T timestamp
Tタイムスタンプ
CERTx the certificate of x
CERTxはxの証明書です。
SIGNx the signature from x using the private key of x
SIGNxはxの秘密鍵を使用するxからの署名です。
PKx the public key of x
PKxは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
または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).
1セットのコード化されたサブペイロードとメッセージ立証コード(MAC)を含むKEMAC MIKEY Key Data Transport有効搭載量。
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プロキシがランデブーに関して効率的に被呼者を見つけるために複数の送信する要求に入って来る要求を模写する能力を分岐させます。 シリーズ(深さ-最初の検索)か平行(幅-最初の検索)で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.
Retarget、SIPプロキシがその結果、明らかにユーザエージェントのクライアントに通知しないで要求の目的地を変更しながらRequest-URIを書き直す能力。
Fries & Ignjatic Informational [Page 6] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[6ページ]のRFC5197マイキーモード適用性2008年6月
3. MIKEY Overview
3. マイキーOverview
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.
このセクションはマイキーに関する概観を提供するでしょう。 マイキーは、異機種混在環境におけるマルチメディアセッションを保証するために暗号の文脈のセットアップに焦点を合わせます。 ピアツーピア、多くへの簡単なもの、および小型(インタラクティブ)グループにマイキーが使用されることを主に意図します。 マイキーの1つの目的はセキュリティプロトコルのために、データ機密保護協会(SA)を生産することです、セキュリティプロトコルのために入力されるようにTEK Generation Key(TGK)から得られて、使用されるKey(TEK)をコード化しながらTrafficを含んでいて。
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.
マイキーは同時に1つ以上のセキュリティプロトコル(または同じセキュリティプロトコルのいくつかの例のために)のためのキーとパラメタを確立する可能性を支持します。 Crypto Session Bundle(CSB)の概念は、マイキーから一般的なTGKとしかし、セキュリティパラメタ、それに異なったTEKsを入手させることができる1Cryptoのセッションズの収集を指示するのに使用されます。
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.
RFC3830で定義されるマイキーは高々1つの往復旅行しか続けないかもしれません、逆方向への順方向とResponderメッセージにいわゆるInitiatorメッセージを使用して。 半分往復旅行(例えば、あらかじめ共有されたキーに基づいている)の中で続くかもしれないマイキー計画が存在することに注意してください、他の計画は完全な往復旅行(例えば、ディフィーヘルマンベースの計画)を必要としますが。 Initiatorのメッセージ(I_MESSAGE)の主な目標は安全な方法でセキュリティパラメタ(SPs)の1TGKs(KEMAC分野では、運ばれる)とセットをResponderに輸送することです。 いくつかの計画に、Responderからの検証メッセージが任意であるので、Initiatorは、Responderからそれが検証メッセージを必要とするかどうかを示します。
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
以下の小区分の焦点は異なった計画の利点と損失についての議論と同様に主要な分配方法に位置しています。 主要な分配計画が緩く頼るマイキーが時計を連動させたことに注意してください。 時計であるなら、同期は利用可能でなく、再生はマイキーの取り扱いです。(Cf。 [RFC3830]) 働かないかもしれません。 これはマイキーが再生取り扱いにチャレンジレスポンスメカニズムを使用しないという事実のためです。 代わりに、タイムスタンプはメッセージキャッシュと共に使用されます。 したがって、必要な同期はどちらの側でもキャッシュできるメッセージの数に依存します。 したがって、マイキーは、展開環境における時計斜行に依存するキャッシュサイズを調整することを勧めます。 そのうえ、RFC3830はISO時間同期化プロトコル[ISO_秒_時間]を推薦します。 再生取り扱いが利用可能でないなら、攻撃者は彼が、より早く盗み聞いたというより古いメッセージを再演できるかもしれません、両側の異なったTGKsに通じて。 マイキー(例えば、SRTPかテスラ)を利用するアプリケーションへこれらを供給するので、両側は、異なったキーを当てにして、その結果、交信できないかもしれません。
Fries & Ignjatic Informational [Page 7] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[7ページ]のRFC5197マイキーモード適用性2008年6月
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 .
互い。 マイキーで提出されたタイムスタンプに適用された形式は[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 実現に義務的: RFC3830がこの計画の実現を必要とするなら、情報を提供します。
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 完全な前進の秘密主義(PFS)の支給: PFSのサポートについて説明します。(RFC4949[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 キー生成かかわり合い: 両方かちょうど関係者のひとりが活発にキー生成に伴われるかどうか説明します。 数ポイントを記述するとき、双方にキー生成にかかわるオプションはここで考えられます:
* 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
また、マイキーがSRTP[RFC3711]ブートストラップ法に使用されるなら、それは、実際のセッションに安全保障政策を関連づけるのにSSRCを使用します。 SSRCは同期ソースを特定します。 値は手当たりしだいに選ばれていて、いいえ、同じSRTPセッション中の2つの同期ソースがそうする意図をもって同じSSRCを持ってください。 複数のソースが同じ識別子を選ぶという確率が低いのですが、すべての(S)RTP実現を衝突を検出して、決議するように準備しなければなりません。 それにもかかわらず、マルチメディア通信シナリオで支持であること
Fries & Ignjatic Informational [Page 8] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[8ページ]のRFC5197マイキーモード適用性2008年6月
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].
衝突を分岐するか(セクション5.2を見ます)、または「再-狙」うのが(セクション5.3を見ます)いわゆる二度のパッドに通じながら、起こるかもしれません。 すなわち、同じキーはメディアの流れに異なった目的地に使用されます。 2つのブランチが同じTEK(主要な設立をマイキーに基礎づける)を持って、SRTPの流れのための同じ32ビットのSSRCを選ぶなら、これは起こります。主要な派生がそしてそうするSRTPは同じセッションキーを生産して(入力値が同じであるときに)、また、同じ1パケットあたりの初期化ベクトルを引き出します、SSRCsが同じであるときに。 また、2個の時間パッドがメディアの流れのために同じ目的地に現れるかもしれないことに注意してください。 これは[RFC3711]に概説されています。
3.1. Pre-Shared Key (PSK) Protected Distribution
3.1. あらかじめ共有されたキー(PSK)は分配を保護しました。
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
I_メッセージ=HDR、T、底ならし革、[IDi]、[IDr]、SP、KEMAC--->R_メッセージ=、[<--、]、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(公開鍵基盤)にないという事実にあって、解決策は、低い帯域幅を消費して、高性能を可能にして、全部で可能にします。簡単な簡単なマスターキーの食糧を供給すること。 損失は完全な前進の秘密主義が提供されないで、キー生成がInitiatorによってただ実行されるということです。 その上、アプローチは、より大きい構成にスケーラブルではありませんが、小さいサイズのグループで許容できます。 [RFC3830]に従ってこのオプションが実行するために義務的であることに注意してください。
3.2. Public Key Encrypted Key Distribution
3.2. 公開鍵のコード化された主要な分配
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
かぎ管理の非対称のオプションを使用して、Initiatorは伝えられるために、主要な材料(TGKs)を発生させて、いわゆる封筒キーでコード化されていた状態でそれを送ります。(キーは受信機の公開鍵で順番にコード化されます)。 封筒主要であるのと、env主要(乱数である)は、auth-キーとenc-キーを引き出すのに使用されます。 そのうえ、aがキーをあらかじめ共有したように封筒キーは使用されるかもしれません。
Fries & Ignjatic Informational [Page 9] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[9ページ]のRFC5197マイキーモード適用性2008年6月
establish further crypto sessions. The responder message is optional and may be used for mutual authentication or error signaling.
さらなる暗号セッションを確立してください。 応答者メッセージは、任意であり、互いの認証か誤りシグナリングに使用されるかもしれません。
Initiator Responder
創始者応答者
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC, [CHASH],
PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_メッセージ=HDR、T、底ならし革、[IDi| CERTi]、[IDr]、SP、KEMAC、[CHASH]、PKE、SIGNi--->R_メッセージ=、[<--、]、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を避けることができる自己署名入りの証書の使用法を許容するということです。 自己署名入りの証書を使用するのが限られたスケーラビリティをもたらして、また、証明書の指紋の交換などの認証か同様のテクニックのために追加手段を必要とするかもしれないことに注意してください。 まさしくInitiatorによるキー生成の性能を包括しますが、損失は完全なスケーラビリティのためのPKIの必要性、完全な前進の秘密主義のどんな支給も包括しません。 さらに、Responder証明書は、あらかじめ送付者の側で利用可能である必要があります。 その上、リアルタイムで、証明書の検証をしないかもしれません。 これは証明書の取消し状態がさらなるコンポーネントを通してチェックされるシナリオでそうであるかもしれません。 Initiatorの役割によって、また、グループベースのコミュニケーションでこの計画を適用できます。そこでは、セントラルサーバーが関連クライアントの公開鍵で保護されたグループキーを分配します。 [RFC3830]に従ってこのオプションが実行するために義務的であることに注意してください。
3.3. Diffie-Hellman Key Agreement Protected with Digital Signatures
3.3. デジタル署名で保護されたディフィー-ヘルマンの主要なAgreement
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.
かぎ管理のディフィー-ヘルマンのオプションは双方が共有秘密キーに貢献する方法でInitiatorとResponderの間の共有秘密キー設立を可能にします。 ディフィーヘルマンキー協定は、デジタル署名を使用することで認証されます(保全は保護されました)。
Initiator Responder
創始者応答者
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, DHi, SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr],
IDi, DHr, DHi, SIGNr
I_メッセージ=HDR、T、底ならし革、[IDi| CERTi]、[IDr]、SP、DHi、SIGNi--->R_メッセージ=<。--- HDR、T、[IDr| CERTr]、IDi、DHr、DHi、SIGNr
Fries & Ignjatic Informational [Page 10] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[10ページ]のRFC5197マイキーモード適用性2008年6月
[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証明書の使用以外に、ディフィー-ヘルマングループ「OAKLEY5"[RFC2412]」を支持するのは義務的です。 また、マイキーの中で他のディフィー-ヘルマングループを使用するのも可能です。 [RFC3830]に従って新しいマッピングサブペイロードと関連方針ペイロードを定義することによって、これができます。 このアプローチの利点は、あらかじめ上に表現されたマイキー-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会議は、まさしくマイキー-DHSIGNを使用することでサポートされません。 それにもかかわらず、確立したディフィーヘルマン秘密はグループ関連のセキュリティパラメタを独力で進むあらかじめ共有されたキーとして機能するかもしれません。 その上、上で説明されたマイキー-RSAモードに関して、リアルタイムで、必ず証明書の検証をするかもしれないというわけではありません。 これは証明書の取消し状態がさらなるコンポーネントを通してチェックされるシナリオでそうであるかもしれません。 [RFC3830]に従ってこの体系を実装するのが任意であることに注意してください。
3.4. Unprotected Key Distribution
3.4. 保護のない主要な分配
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.
また、RFC3830は、保護のない方法(マイキー-NULL)でキーを提供するためにモードをサポートします。 これは、セクション3.1に表現された対称鍵暗号化オプションに基づいていますが、NULL暗号化とNULL認証アルゴリズムで使用されます。それはSDPセキュリティ記述[RFC4568]で明瞭なアプローチと比較されるかもしれません。 マイキー-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.
このメソッドのなくなった暗号の保護に基づいて、その完全な前進の秘密保持が提供されないのは、明白です。 プレ共有秘密キーモードに基づいているとき、Initiatorだけがかぎ管理に貢献します。 メソッド自体は非常にスケーラブルですが、基本的なセキュリティ層を通した適切な保護がなければ、使用には、一方、それは賢明ではありません。
Fries & Ignjatic Informational [Page 11] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[11ページ]のRFC5197マイキーモード適用性2008年6月
3.5. Diffie-Hellman Key Agreement Protected with Pre-Shared Secrets
3.5. プレ共有秘密キーで保護されたディフィー-ヘルマンの主要なAgreement
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で説明されたメソッドと対照して、ここで、ディフィーヘルマンキー協定は、プレ共有秘密キーと合わせられたハッシュ関数を使用することで認証されます(保全は保護されました)。
Initiator Responder
創始者応答者
I_MESSAGE =
HDR, T, RAND, [IDi],
IDr, {SP}, DHi, KEMAC --->
R_MESSAGE =
<--- HDR, T,[IDr], IDi,
DHr, DHi, KEMAC
I_メッセージ=HDR、T、底ならし革、[IDi]、IDr、SP、DHi、KEMAC--->R_メッセージ=<。--- HDR、T、[IDr]、IDi、DHr、DHi、KEMAC
TGK = g^(xi * yi) TGK = g^(xi * yi)
TGK=g^(ξ*yi)TGKはg^と等しいです。(ξ*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.
ディフィー-ヘルマンの主要な協定の保全保護のために、[RFC4650]はHMAC SHA-1の使用を強制します。 ディフィー-ヘルマングループに関して、[RFC3830]は参照をつけられます。 したがって、ディフィー-ヘルマングループが「OAKLEY5"[RFC2412]」であるとサポートするのは義務的です。 また、マイキーの中で他のディフィー-ヘルマングループを使用するのも可能です。 RFC3830に従って新しいマッピングサブペイロードと関連方針ペイロードを定義することによって、これができます。 また、このオプションには、いくつかの利点があります、完全な前進の秘密保持がありますが、公正な互いの主要な協定、どんな依存もPKIとPKI規格にないとき。 そのうえ、この体系は、音の性能を持って、マイキー-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.
この運転モードは多くのクライアントのために共有秘密キーで食糧を供給される主要な信じられたサーバがあるところに展開における効率的な体系を提供します。 例えば、そのようなセットアップは企業兵士の支店Exchanges(PBXs)、サービスプロバイダープロキシであるかもしれませんなど。 セクション3.1で説明された明瞭なあらかじめ共有された主要な暗号化ベースのモードと対照して、このモードは双方のかかわったキー生成におけるアクティブなかかわり合いと同様に完全な前進の秘密保持を提供します。
3.6. SAML-Assisted DH key Agreement
3.6. SAMLによって補助されたDH主要なAgreement
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
IETFミーティングとIETF MSECメーリングリストもSAMLによって補助されたDHアプローチに関する、より長い議論がありました。 別々のドキュメントとしてこの考えを提出していません。 それにもかかわらず、一般を実現させるために狙うとき、議論はここに反映されます。
Fries & Ignjatic Informational [Page 12] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[12ページ]のRFC5197マイキーモード適用性2008年6月
requirements on key management approaches. Those requirements can be summarized as:
かぎ管理アプローチに関する要件。 以下としてそれらの要件をまとめることができます。
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.
それは主要な設立に要素であるのに調印されたUserエージェントの(UA)のSIPサーバに関連して古典的なディフィー-ヘルマン主要な協定プロトコルを使用するために提案されました、SAML(セキュリティAssertion Markup Language[SAML_概要])アプローチを使用することでディフィー-ヘルマンキーとIDを認証して要件のすべてを実現させるなら。 ここで、クライアントの公共のディフィー-ヘルマン資格証明書はサーバによって署名されます。(それは、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).
I_メッセージ=HDR、T、RAND1、[CREDi]、IDr、SP--->R_メッセージ=<。--- HDR、T、[CREDr]、IDi、DHr、RAND2、(SP)TGKはHMACx(RAND1| RAND2)(ξ*xr)と等しいです。そこでは、xがg^と等しいです。
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を利用するのに2番目の往復旅行を使用できます。 安全保障政策は、マイキーを通して2番目の往復旅行のための引き金がSPを通して扱われると伝えました。
Fries & Ignjatic Informational [Page 13] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[13ページ]のRFC5197マイキーモード適用性2008年6月
Initiator Responder
創始者応答者
I_MESSAGE =
HDR, SIGN(ENC(RAND3)) --->
R_MESSAGE =
<--- SIGN(ENC(RAND4))
I_は=HDRを通信させて、署名してください(ENC(RAND3))。--->R_メッセージ=<。--- サイン(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.
また、2番目の往復旅行に、このアプローチは他の主要な分配メソッドのすべてのためのオプションを提供します、活気チェックが必要であるときに。 2番目の往復旅行の欠点はこれらのメッセージが、シグナリングプロトコルの呼び出し流動と統合される必要があるということです。 簡単な呼び出しでは、1つの往復旅行が、セッションをセットアップするために十分であるかもしれません。 したがって、この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サーバは、それがディフィー-ヘルマン秘密鍵を持っているUAのために付加的な認証オブジェクトをだまして、作成できます。 これで、SAML主張を発行する(SIP)サーバは首尾よく2UAsに対して中央のMan(MITM)攻撃に着手できます。 また、2つのSIPサーバが、どちらかが首尾よくそれらのUAsに対してMITM攻撃に着手できるように、馴れ合うことができます。 ディフィー-ヘルマンキーが信頼できる第三者によって認証されて、この全体のオブジェクトがSIPサーバによって署名されるなら、UAはこの攻撃を妨げることができます。そのうえ、このアプローチは2つの往復旅行を使用します、必要な帯域幅と準備時間(多くのシナリオに、重要であるかもしれない)も増強して。 資格証明世代において、通常、別々のコンポーネント(サーバ)が必要であるので、serverless呼び出しセットアップはサポートされません。
Fries & Ignjatic Informational [Page 14] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[14ページ]のRFC5197マイキーモード適用性2008年6月
3.7. Asymmetric Key Distribution with In-Band Certificate Exchange
3.7. 証明書交換がバンドにある非対称の主要な分配
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
SIGNi、I_は=HDR、T、[IDi| CERTi]、[IDr]、SP[底ならし革]を通信させます。--->R_メッセージ=<。--- HDR、[GenExt(CSB-ID)]、T、底ならし革、[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に述べられた非対称の主要な分配にいくつかの利点をたとえます。 ここで、マイキーInitiatorメッセージでそれを送るとき(受信機があらかじめ証明書を知っているなら、RFC3830のマイキー-RSAモードは代わりに使用されるかもしれません)、送付者と受信機はあらかじめ、もう片方の同輩の証明書を知る必要はありません。 したがって、このメッセージの受信機は、マイキー応答者メッセージの一部としてセッションパラメタを暗号化して、それらを返送するのに容認された主要な材料を利用できます。 証明書チェックは署名権威により終わるかもしれません。 公的に受け入れられた権威で証明書に署名するなら、正直な態度で証明書合法化ができます、一般的に知られている認証局の公開鍵を使用することによって。 もう片方の場合では、追加ステップが必要であるかもしれません。 不都合はどんな完全な前進の秘密保持も提供しないということです。
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
このモードが、PKIが存在しているとき、証明書の食糧を供給する楽な選択肢を提供することを意味される、そして/または、必要です。 特にSIPでは、セッション招待状は、「再-狙」うか、または分岐できます。 彼らが主要な交渉をするために複数の往復旅行を必要とするかもしれないので、Initiatorが独身のよく知られるResponderを狙うのを必要とするマイキーモードはここで非実用的であるかもしれません。 Responderが主要な派生に使用される秘密の材料を生成するのを許容することによって、このモードは効率的な主要な配送体系を考慮します。 CSB-IDからキーを得て、ユニキャストにおけるRANDペイロードがケースを使用するのでInitiatorが主要な材料に貢献できることに注意してください。 また、このモードも複数のクライアントが知られているサーバに連絡していて、キーをダウンロードしているマルチキャストシナリオで役に立ちます。 公開鍵モードでマイキーと比べて、応答者ワークロードはこれらのシナリオでかなり減少します。 これは秘密鍵を使用することで復号化と比べて、RSAの非対称の暗号化が、より少ない取り組みを必要とするという(通常、公開鍵が秘密鍵より短い、したがって、暗号化のための、より少ない性能が復号化と比較されました)事実のためです。 展開に関する例、どこ
Fries & Ignjatic Informational [Page 15] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[15ページ]のRFC5197マイキーモード適用性2008年6月
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がある企業です、サービスプロバイダーがユーザなどへの支給証明書に決めるサービスプロバイダーセットアップということであるかもしれません。
4. Further MIKEY Extensions
4. さらなるマイキーExtensions
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.
このセクションは、SRTP以外のセキュリティプロトコルのためのセキュリティパラメタの交渉をサポートするために暗号アルゴリズムのための一層のマイキー[RFC3830]拡大と増進と同様にジェネリックペイロード増進に関して概要を提供するでしょう。 これらの拡大はいくつかの追加ドキュメントで定義されました。
4.1. ECC Algorithms Support
4.1. ECCアルゴリズムサポート
[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-マイキー]はメソッドがマイキーにおける使用のために説明した認証、暗号化、およびデジタル署名に拡大を提案します、楕円曲線暗号(ECC)を使って。 これらの拡大は、他の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-マイキー]に述べられているように、実装は、楕円曲線アルゴリズムが他のお勧めのアルゴリズムの上で性能と1ビットあたりのセキュリティをかなり向上させることができるのを示しました。
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-マイキー]はマイキーキー分配体系を高めるために数個のECCベースのメカニズムを提案します:
o Use of ECC methods extending the Diffie-Hellman key exchange:
MIKEY-DHSIGN with ECDSA or ECGDSA
o ディフィー-ヘルマンの主要な交換を広げるECCメソッドの使用: ECDSAかECGDSAとマイキー-DHSIGN
o Use of ECC methods extending the Diffie-Hellman key exchange:
MIKEY-DHSIGN with ECDH
o ディフィー-ヘルマンの主要な交換を広げるECCメソッドの使用: ECDHとマイキー-DHSIGN
Fries & Ignjatic Informational [Page 16] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[16ページ]のRFC5197マイキーモード適用性2008年6月
o Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES)
o 楕円曲線の統合暗号化体系の使用(マイキー-ECIES)
o Use of Elliptic Curve Menezes-Qu-Vanstone Scheme(MIKEY-ECMQV)
o 楕円曲線メネゼス-Qu-Vanstone体系の使用(マイキー-ECMQV)
The following subsections will provide more detailed information about the message exchanges for MIKEY-ECIES and MIKEY-ECMQV.
以下の小区分はマイキー-ECIESとマイキー-ECMQVに交換処理の、より詳細な情報を供給するでしょう。
4.1.1. Elliptic Curve Integrated Encryption Scheme application in MIKEY
4.1.1. マイキーの楕円形のCurve Integrated Encryption Schemeアプリケーション
The following figure shows the message exchange for the MIKEY-ECIES scheme:
以下の図はマイキー-ECIES体系のために交換処理を示しています:
Initiator Responder
創始者応答者
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC,
[CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_メッセージ=HDR、T、底ならし革、[IDi| CERTi]、[IDr]、SP、KEMAC、[CHASH]、PKE、SIGNi--->R_メッセージ=、[<--、]、HDR、T、[IDr]、V
4.1.2. Elliptic Curve Menezes-Qu-Vanstone Scheme Application in MIKEY
4.1.2. マイキーの楕円曲線メネゼス-Qu-Vanstone体系アプリケーション
The following figure shows the message exchange for the MIKEY-ECMQV scheme:
以下の図はマイキー-ECMQV体系のために交換処理を示しています:
Initiator Responder
創始者応答者
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP},
ECCPTi, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_メッセージ=HDR、T、底ならし革、[IDi| CERTi]、[IDr]、SP、ECCPTi、SIGNi--->R_メッセージ=、[<--、]、HDR、T、[IDr]、V
4.2. New MIKEY Payload for Bootstrapping TESLA
4.2. テスラを独力で進むための新しいマイキーPayload
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.
テスラ[RFC4082]は、マルチキャストシナリオで認証をソースに提供するためのプロトコルです。 テスラは、少ないコミュニケーションと計算オーバーヘッドがある効率的なプロトコルであり、また、パケット損失を黙認します。(オーバーヘッドは多くの受信機に比例します)。 テスラは送付者と受信機の間のゆるい時間同期化に基づいています。 ソース認証は、テスラにメッセージ立証コード(MAC)推論を使用することによって、実現されます。 Secureレアル-時間Transportプロトコル(SRTP)の中のテスラの使用は、SRTPがマルチメディアデータを保護するために適用されるシナリオにおけるマルチキャスト認証を狙いながら、[RFC4383]で発行されました。 このソリューションは、テスラパラメタがバンドの外による人工の利用可能なメカニズムであると仮定します。
Fries & Ignjatic Informational [Page 17] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[17ページ]のRFC5197マイキーモード適用性2008年6月
[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.
マイキーが安全なグループコミュニケーションのソース認証のためにSRTPを使用することでテスラを独力で進むように、[RFC4442]はペイロードを指定します。 テスラは、上でユニキャスト、マルチキャスト、または放送でマイキーメッセージを送ることによって説明されたマイキーかぎ管理アプローチの1つを使用することで独力で進まれるかもしれません。 このアプローチはテスラの使用法のための必要なパラメタペイロード拡張子をSRTPに供給します。 それにもかかわらず、また、パラメタセットも他のテスラに十分であるなら、ケースを使用してください、そして、また、それは適用できます。
4.3. MBMS Extensions to the Key ID Information Type
4.3. 主要なID情報タイプへのMBMS拡張子
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.
この拡大は新しいType(Key ID情報Type)を一般Extension有効搭載量に指定します。 これによる使用されていて、例えば、Multimedia Broadcast/マルチキャストService(MBMS)が第3Generation Partnership Project(3GPP)で指定したということです。 パラメタがマルチメディアがそれであると機密保護するために必要とした関連するセキュリティは、MBMSがキーを運ぶためにマイキーの使用を必要として、マルチキャストか放送です。
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]は、かかわったキーのタイプとアイデンティティを特定するためにマイキーで一般Extension有効搭載量に新しいTypeを指定します。 そのうえ、ともに登録プロトコルと再キーが議定書を作るようにMBMSがマイキーを使用するとき、このRFCはユニキャストとマルチキャスト再キーがMBMS設定でともに議定書を作るようにマイキーが機能できる必要な追加を指定します。
4.4. OMA BCAST MIKEY General Extension Payload Specification
4.4. OMA BCASTマイキーGeneralの拡大有効搭載量仕様
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]はオープンのモバイルAlliance(OMA)ブラウザとContent Broadcast(BCAST)グループにおける使用のための新しい一般的な拡大ペイロードタイプを指定します。 OMA BCASTのサービスと満足している保護仕様はマイキーで、ある放送流通制度で運ばれる短期的な主要なメッセージと長期の主要なメッセージペイロードを使用します。 ドキュメントは、新しいペイロードを定義しないで可能な拡大をマイキーに許すために一般的な拡大ペイロードを定義します。 一般的な拡大ペイロードは、どんなマイキーメッセージでも使用できて、認証されたか署名しているデータ部分の一部です。 唯一のパラメータ記述が含まれるのにもかかわらずの、いいえの主要な情報であることに注意してください。
Fries & Ignjatic Informational [Page 18] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[18ページ]のRFC5197マイキーモード適用性2008年6月
4.5. Supporting Integrity Transform Carrying the Rollover Counter
4.5. 保全がロールオーバーカウンタを運ぶ変換であるとサポートします。
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[RFC3711]のためにまた、専用SRTPパケットの一部としてRoll Over Counter(ROC)を伝えるためにオプションを提供しながら、新しい保全変換を定義します。 この拡大は3GPPマルチキャスト/放送サービスにおける使用のために定義されました。 交信パーティーは始めのROCに同意しましたが、それがバンドから彼に合図されても、いくつかの場合、受信機はものが送付者によって使用されている彼のROCを連動させることができないかもしれません。 ここに、新しい拡大は受信機が送付者のROCに再連動する可能性を提供します。 新しい保全変換の使用に合図するために、あるマイキーペイロードのための新しい定義は、する必要があります。 これらの新しい定義は新しい保全変換パラメタと同様に保全変換自体を包括します。 そのうえ、ドキュメントは、SRTPとSRTCPのために異なった保全変換の用法を可能にするために追加パラメタを指定します。
5. Selection and Interworking of MIKEY Modes
5. マイキーModesを選択と織り込むこと
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.
マイキーとその拡大が運転モードでさまざまな選択を提供している間、実装は、振舞いを簡素化するのを選ぶかもしれません。 Initiatorの役割にあるとき、操作の単モードで作動することによって、これを達成できます。 例えば、PKIが利用可能である、そして/または、必要であるところで実装は、RSA-Rモードですべてのセッションに始まるのを選ぶかもしれません、そして、Responderとして公開鍵モードで機能するのは些細でしょう。 また、封筒キーがキャッシュされるなら、それは、共有された主要なモードにおける再の合わせることをするのを選ぶことができます。 封筒キーのキャッシュが許されているなら、マイキーかマイキー拡大の範囲の外にそれはあります。 これはかかわったコンポーネントの構成の問題です。 マイキーの範囲の外にもこの地方の構成はあります。 マイキーコミュニケーションが行われる前に2人の同輩が互いを意識しているとき、一般に、Initiatorが合わせるのが材料であると生成する運転モードは役に立ちます。 同輩が、公開鍵モードで作動しないのを選ぶなら、それはInitiatorの証明書を拒絶するかもしれません。 同じくらいは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
モードをマイキーに送ってください。さもないと、例えば、SIP/SDPで使用されると、共有された主要なモードは、主要な派生の材料が複数のパーティーに分配されるシナリオを分岐させながら、いくつかの呼び出しシナリオにおける複雑さにつながるかもしれません。(そこでは、Initiatorが公開鍵のように主要な材料を供給します)。 先に述べたように、目的地のいくつかがInitiatorにメッセージを有効にするリソースを持たないで、セッション招待を下げさせるかもしれないので、これは非実用的であるかもしれません。 パーティーがかかわったすべてがマイキーメッセージを解釈するためのすべての前提条件を受け取らせる場合ではさえ、複数のRespondersが同じキーを使用することでメディアセッションを始めている起こりうる問題があります。 SSRCsが場合の大部分において異なりますが、それらが異なる、唯一
Fries & Ignjatic Informational [Page 19] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[19ページ]のRFC5197マイキーモード適用性2008年6月
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ビット、二度のパッド問題の高い確率があります。 これは分岐(また、セクション5.2を見る)や「再-狙」い(また、セクション5.3を見る)のようなシナリオのサポートのためです。(そこでは、2つのブランチが同じTEK(主要な設立をマイキーに基礎づける)を持って、SRTPストリームのための同じ32ビットのSSRCを選んで、SRTPパケットを伝えるなら、2時間パッドが現れます)。 コミュニケーションが行われる(封筒キーを使用することによって高価な公開鍵操作を避けることができるとき、主要な更新シナリオでそうであるように)前に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.
以下のリストは異なったマイキーモードがどのように使用されるか、または結合されるかもしれないかという考えを与えます、Initiator側の利用可能な主要な材料によって。
1. If the Initiator has a PSK with the Responder, it uses the PSK
mode.
1. InitiatorにResponderと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. Initiatorが、ResponderとPSKを持っていますが、Responderが双方がエントロピーを提供するべきである方針をキーに持っているのを知っているなら、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. InitiatorにResponderのRSAキーがあるなら、それは、TGKを証明するのにRSAモードを使用します。 TGKがさらなるかぎ管理操作にOption1と共に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. Initiatorが、応答者には彼の証明書があると予想しないなら、彼はRSA-Rを使用するかもしれません。 RSA-Rを使用して、彼は情報が中で括るInitiatorの証明書を受信機に供給できます。そのうえ、また、Initiatorはキー生成に受信機で使用できる乱数を供給するかもしれません。 したがって、双方はかぎ管理にかかわることができます。 しかし、Initiatorが乱数の包含を強制できないので、本当のPFSを提供できません。 TGKを設立した後にこのモードで、それが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が彼の方針によって必要とされるとき、InitiatorはDH-SIGNを使用します、そして、彼はResponderには双方がエントロピーを提供するべきである方針があるのを知っています。 TGKを設立した後にこのモードでも、それが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かどんな証明書もInitiatorの側(そして同様に応答者の側で)で利用可能ではありませんが、低レベルセキュリティ(TLSやIPsecのような)が適所にあるなら、ユーザはマイキーの保護のないモードを使用するかもしれません。 それは保護のないモードが、プロキシのような中間的ノードが実際に平野の中で交換されたマスターキーを手に入れるのを可能にするその使用を考えられるようにします。 これは特に中間的ノードが信じられない場合で意図しないかもしれません。
Fries & Ignjatic Informational [Page 20] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[20ページ]のRFC5197マイキーモード適用性2008年6月
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-メディア]で暗号の強さと同様に展開インフラストラクチャへの影響と要件に関する操作の異なったモードの比較を見つけることができます。 リストが提供する中でもの最も際立つ↓これは、シナリオと呼んで、さらなる議論の問題です:
o Early Media
o 早めのメディア
o Forking
o 分岐します。
o Call Transfer/Redirect/Retarget
o Retargetに転送/再直接の/に電話をしてください。
o Shared Key Conferencing
o 共有された主要な会議
5.1. MIKEY and Early Media
5.1. マイキーと早めのメディア
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番目のシナリオが説明する、訪問される人から、最終的なSIP200OKメッセージを送る前に、発信してください。 提供するとき、待ち輪を列に並ばせるとき、この状況が通常コールセンターシナリオに載っているか、または個人的なリングは調子を変えます。
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データを受け取るかもしれません。 2つのマイキーモード(1つの輸送されるべきメッセージ(セクション3.1とセクション3.2)しか必要としない)が早めのメディア状況でうまく利きます、実際に送付/受信がデータを暗号化する前に送付者と受信機の両方が適所にすべての必要なパラメタを持っているとき。 ディフィーヘルマンキー協定(セクション3.3、セクション3.5、およびセクション3.6)か高められた非対称の異形(セクション3.7)のどちらかを特徴として、他のモードはInitiatorが、できる前の応答が入って来るSRTPメディアを解読するのを待たなければならないという要件が欠点です。 事実上、言い換えれば、SDPが答える前にメディアが送られなく、また早めのメディアが使用されていなくても、同様の問題はSIP/ SDPシグナリングが複数のプロキシを途中に横断し返さなければならなくて、SDPが答える前にメディアが到着するかもしれないという事実から起こるかもしれません。 もっとも、この遅れが早めのメディアに関するケースよりかなり少しであると予想されます。
Fries & Ignjatic Informational [Page 21] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[21ページ]のRFC5197マイキーモード適用性2008年6月
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.
SRTPにメディアを解読し始めることができる前に開始終わりがSDP答えを必要とするとき、セキュリティ記述[RFC4568]には基本的に同じ問題があるとここに言及する価値があります。
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つの例は必要なマイキーパラメタを含んでいて、暫定的な応答が暗号化されたメディアの前に送られるシナリオが処理されるということです。
5.2. MIKEY and Forking
5.2. マイキーと分岐
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要求を1つ以上の位置に送ります。 また、これは、マイキーペイロード(SDPの一部である)が数個の(異なる)の位置に送られることを意味します。 署名をサポートするマイキーモードは受信機がここで署名を有効にすることができるときシナリオ(セクション3.3とセクション3.7)を分岐させる際に使用されるかもしれません。 非対称の主要な暗号化モード(セクション3.1とセクション3.2)と同様に対称鍵暗号化による制限があります。 これは左右対称の暗号化において、受取人が、マイキーデータを扱う前に対称鍵を所有する必要があるという事実のためです。 非対称のマイキーモードによって、送付者が分岐を意識しているなら、彼は、あらかじめ、INVITEがどの位置に股状であり、その結果、マイキー封筒キーを暗号化するのに正しい受信機証明書を使用しないかもしれないかを知らないかもしれません。 送付者が分岐に対処する同じINVITEメッセージに数個のマイキーコンテナを入れるかもしれませんが、これがあらかじめ目標をフォーク状にしながらすべてに関する知識を必要として、また、目標証明書の所持を必要とすることに注意してください。 このような場合には振舞いを指定するために、マイキーの範囲の外にそれはあります。 マイキーディフィーヘルマンモードか_Rセクション3.7がするマイキー-RSAがこの問題を持っていません。 送付者が分岐を意識していないシナリオでは、所定の受信者だけがマイキーコンテナを解読することができます。
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.
分岐が早めのメディアに結合されるなら、状況は怒っています。 完全な往復旅行を必要とするマイキーモードが署名しているディフィー-ヘルマンのように使用されるなら、複数の応答が端末装置を積みすぎるかもしれません。 例は30の目的地(グループピックアップ)に分岐しています、マイキーがセキュリティ前提条件と共に署名しているディフィー-ヘルマンモードで使用されますが。 ここで、あらゆる目標に暫定的な応答で答えるでしょう、送付者のサイトで30の署名合法化とディフィーのヘルマンの計算に通じて。 これは長引いているメディアセットアップ遅れに通じるかもしれません。
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.
そのうえ、選ばれたマイキーモードによって、二度のパッドは交渉された主要な材料とSSRCの依存で現れるかもしれません。 複数の受信機が同じSSRCを選ぶとき、RSA-R以外の非ディフィーのヘルマンモードのために、二度のパッドは現れるかもしれません。
Fries & Ignjatic Informational [Page 22] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[22ページ]のRFC5197マイキーモード適用性2008年6月
5.3. MIKEY and Call Transfer/Redirect/Retarget
5.3. マイキーと呼び出し転送/再直接の/Retarget
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環境で、SDP申し出/答えとマイキーモードの同じ特性と制限が正常な呼び出しセットアップシナリオのように当てはまる呼び出し転送に使用される実装モデルの如何にかかわらずマイキー交換は結ばれます。
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シナリオ、機能性、再直接、サポートされます。 再直接のシナリオでは、呼び出し創始者は、例えば被呼者が一時動かした応答を得て、異なった目的地で連絡されるかもしれません。 訪問者は現在、新しい目的地で呼び出し設立を実行できます。 元々選ばれたマイキーモードによって、訪問者は新しい目的地でこのモードを実行できないかもしれません。 より正確に、なるように、マイキー-PSKとマイキーDHHMACはあらかじめ、プレ共有秘密キーを必要とします。 マイキー-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プロキシは元々呼ばれた目標から再直接の応答を受けることに関する異なった目標に要求を送ります。 かぎ管理が元々異なった目的地に狙ったので、訪問者が非対称の主要な暗号化(マイキーRSA)を使用したところであらかじめ共有されたキー(マイキー-PSK、マイキーDHHMAC)を必要とするマイキーモードを使用するとき、これはたぶん問題を引き起こすでしょう。
5.4. MIKEY and Shared Key Conferencing
5.4. マイキーと共有された主要な会議
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.
まず、すべてではなく、マイキーサポートの方法は主要な会議を共有しました。 1組の結果が教えるこのメカニズムが秘密鍵を共有したので、主に、会議に簡単な状態でディフィー-ヘルマンモードを使用できません。 会議シナリオでInitiatorとResponderの役割に従うことによって、他のすべてのモードを適用できます。 すなわち、半分往復旅行モードは会議ユニットによって開始されて、会議キーを分配できる必要があります。 残っている完全な往復のモード(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]で利用可能です。
Fries & Ignjatic Informational [Page 23] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[23ページ]のRFC5197マイキーモード適用性2008年6月
5.5. MIKEY Mode Summary
5.5. マイキーモード概要
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
マイキーEarly Secure Retarget Redirect SharedモードメディアForking Key Conf--------------------------------------------------------------------- 保護のないPSK(3.1)はい、DH-HMAC(3.5)RSA-R(3.7)はいはいはいはい*RSA(3.2)はいはい*DH-サイン(3.3)はい*はい、はい(3.4)はいはい
* In centralized conferencing, the media mixer needs to send the
MIKEY Initiator message.
* 集結された会議では、メディアミキサーは、マイキーInitiatorメッセージを送る必要があります。
The following table maps the MIKEY modes to key management-related properties.
以下のテーブルは主要な管理関連の特性にマイキーモードを写像します。
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*
マイキーManualはPFS Key GenerationモードキーズPKI Involvementを必要とします。-------------------------------------------------------------- PSK(3.1)はい、いいえいいえ創始者RSA(3.2)いいえ、はいいいえ創始者が、(3.3) どんなはいはいもはいのともに保護のない(3.4)のいいえいいえ創始者DH-HMAC(3.5)はい、いいえいいえ両方でないとDH署名する、いいえのRSA-R(3.7)いいえ、はい両方、*
* Assumed the Initiator provides the (optional) RAND value
* 想定されて、Initiatorは(任意)のRAND値を提供します。
6. Transport of MIKEY Messages
6. マイキーMessagesの輸送
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.
マイキーは、実体を伝えることの間の主要な情報と安全保障政策を輸送するためにメッセージ・フォーマットを定義します。 それはこれらのメッセージの埋め込みを中古のシグナリングプロトコルと定義しません。 中古のシグナリングプロトコルによって、この定義を別々のドキュメントに提供します。 それにもかかわらず、また、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によって定義されたプロトコルが、セッションパラメタを輸送するのに、Session記述プロトコル(SDP、[RFC4566])を利用します。 例はSession Initiationプロトコルです。(プロトコル(GCP、[RFC5125])SDPの一部としてのマイキーメッセージの輸送が説明されるSIP、[RFC3261]またはゲートウェイControl[RFC4567]、ここ。
Fries & Ignjatic Informational [Page 24] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[24ページ]のRFC5197マイキーモード適用性2008年6月
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.
完全なマイキーメッセージはシグナリングプロトコルメッセージのSDP部分の一部としてコード化されて、伝えられたbase64です。 また、いくつかの主要な分配メッセージが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.
また、マイキーはH.323のようなITU-Tプロトコルで適用されます。(H.323は、SIPと同様のコミュニケーションセッションを証明するのに使用されます)。 H.323に関しては、セキュリティフレームワーク(H.235で定義される)は存在しています。 このフレームワークの中では、H.235.7[H.235.7]はH.323の文脈でマイキーとSRTPの使用法を説明します。 SIPと対照して、H.323はASN.1(抽象的なSyntax Notation)を使用します。 したがって、base64としてマイキーコンテナをコード化する必要は全くありません。 H.323の中では、マイキーコンテナはコード化されていた状態で2進です。
7. MIKEY Alternatives for SRTP Security Parameter Negotiation
7. SRTPセキュリティパラメタ交渉のためのマイキーAlternatives
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に参照をつけます。 マイキーと対照して実際にメッセージでむしろInitiatorから応答者への方向によるSRTPパラメタをInitiatorからResponderに送る、逆もまた同様です。 これは早めのメディアシナリオの問題を引き起こすかもしれません。
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--[WING-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 Secure RTPのための暗号化されたKey Transport--[MCGREW-SRTP]はSRTPマスターキー、Rollover Counters、および他の情報の安全な輸送に備えるSRTPへの拡大です、SRTCPの中で。 この施設は、SRTPが最小量のコントロールとの分散会議で働いて、SIP分岐と早めのメディアによって引き起こされた状況を扱うのを可能にします。 また、それはマイキーに関連して使用されるかもしれません。
Fries & Ignjatic Informational [Page 25] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[25ページ]のRFC5197マイキーモード適用性2008年6月
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でのディフィー-ヘルマンのサポート--[BAUGHER]は、ディフィー-ヘルマン公開鍵を交換するために新しい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--ディフィー-ヘルマンの交換がSRTPセッションを確立するためのセッションキーとパラメタに同意するように、[ZIMMERMANN]はRTPヘッダー拡張子と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にありました。 IETF68、threeの間、オプションは考えられました: アップデートされたバージョンのマイキー(MIKEYv2と呼ばれる)、ZRTP、およびDTLS-SRTP。 メディアセキュリティのための標準化過程への潜在的かぎ管理プロトコルはDTLS-SRTPを支持して投票されました。 したがって、読者はDTLS-SRTP[AVT-DTLS]に関する詳細のための適切なリソースに指されています。 マイキーがSRTPセキュリティ文脈をセットアップするために既に配布されて、また、MBMSアプリケーションにおける使用のために狙うことに注意してください。
8. Summary of MIKEY-Related IANA Registrations
8. マイキー-RelatedのIANA登録証明書の概要
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登録へのリンクだけを提供します。 http://www.iana.org/assignments/mikey-payloads の下でマイキーペイロードのためのIANA登録証明書を見つけることができます。 これらの登録証明書はと同様にマイキーベース登録証明書を包括します。
The IANA registrations for MIKEY port numbers can be found under http://www.iana.org/assignments/port-numbers (search for MIKEY).
http://www.iana.org/assignments/port-numbers の下でマイキーポートナンバーのためのIANA登録証明書を見つけることができます(マイキーを捜し求めてください)。
9. Security Considerations
9. セキュリティ問題
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
このドキュメントは既存のプロトコルと拡大を定義しません。 それは、マイキーモードと利用可能な拡大のセットに関してむしろ概要を提供して、決定をサポートするために異なったシナリオの異なったモードの適用性に関して情報を提供します。
Fries & Ignjatic Informational [Page 26] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[26ページ]のRFC5197マイキーモード適用性2008年6月
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.
ひたむきな目標シナリオで使用されるために適切なマイキー体系か拡大に関するネットワーク建築家になること。 本書では強く説明された異なった体系を選ぶと、異なった体系が異なったレベルのセキュリティを提供して、また、異なったインフラ支援を必要とするとき、目標システムのセキュリティに影響を及ぼします。
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.
このドキュメントが拡大に関する規格相違と同様にマイキー基礎仕様に基づいているとき、読者は特定のセキュリティ問題のための正本を参照されます。
10. Acknowledgments
10. 承認
The authors would like to thank Lakshminath Dondeti for his document reviews and for his guidance.
作者は彼のドキュメントレビューと彼の指導についてLakshminath Dondetiに感謝したがっています。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、ジーター、M.、およびK.Norrman、「マイキー:」 「マルチメディアインターネットの合わせる」RFC3830、2004年8月。
11.2. Informative References
11.2. 有益な参照
[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] 「安全なリアルタイムのトランスポート・プロトコル(SRTP)のためにキーを設立するデータグラムトランスポート層セキュリティ(DTLS)拡大」というマグリュー、D.、およびE.レスコラは進行中(2008年2月)で働いています。
[BAUGHER] Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges
for Multimedia Sessions", Work in Progress,
February 2006.
[BAUGHER] 「マルチメディアセッションへのディフィー-ヘルマンExchanges」というBaugher、M.、およびD.マグリューは進歩、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)のためのマイキーKey Managementプロトコルの用法」、」、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_秒_時間] 「「ISO/IEC18014情報技術--セキュリティのテクニック--タイムスタンピングサービス、第1部3. http://www.oasis-open.org/committees/ documents.php--wg_abbrevはセキュリティと等し」」2002。
Fries & Ignjatic Informational [Page 27] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[27ページ]のRFC5197マイキーモード適用性2008年6月
[MCGREW-SRTP] McGrew, D., "Encrypted Key Transport for Secure
RTP", Work in Progress, March 2007.
[MCGREW-SRTP] マグリュー、D.、「暗号化された安全なRTPに、主要な輸送」が進歩、2007年3月に働いています。
[MSEC-MIKEY] Milne, A., "ECC Algorithms for MIKEY", Work in
Progress, June 2007.
[MSECマイキー]ミルン、A.、「マイキーのためのECCアルゴリズム」が進歩、2007年6月に働いています。
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305,
March 1992.
[RFC1305] 工場、D.、「ネットワーク時間プロトコル(バージョン3)仕様、実装」RFC1305、3月1992日
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[RFC2412] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[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.ブリスコウ、「効率的な状態で調節されて、損失許容性がある認証(テスラ)を流してください」 「マルチキャストソース認証変換序論」、RFC4082、2005年6月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[RFC4086]イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[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.カラーラ、「安全なリアルタイムのトランスポート・プロトコル(SRTP)における調節された効率的なストリーム損失許容性がある認証(テスラ)の使用」、RFC4383、2006年2月。
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed
Efficient Stream Loss-Tolerant Authentication
(TESLA)", RFC 4442, March 2006.
[RFC4442] フリーズとS.とH.Tschofenig、「調節された効率的なストリーム損失許容性がある認証(テスラ)を独力で進みます」、RFC4442、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、「(マイキー)を合わせて、主要なID情報は一般拡大有効搭載量のためにマルチメディアインターネットでタイプします」、RFC4563、2006年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
Fries & Ignjatic Informational [Page 28] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[28ページ]のRFC5197マイキーモード適用性2008年6月
[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.、ジーター、M.、Norrman、K.、およびE.カラーラ、「セッション記述のためのKey Management拡大は(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.翼、「メディアストリームのためのセッション記述プロトコル(SDP)セキュリティ記述」、RFC4568(2006年7月)。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
RFC 4597, August 2006.
[RFC4597]、同等である、R.N.イスマイル、「会議シナリオ」RFC4597、8月2006日
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650,
September 2006.
[RFC4650]Euchner、M.、「マルチメディアインターネットへの(マイキー)を合わせるHMACによって認証されたディフィー-ヘルマン」、RFC4650、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.リン、「マイキー-RSA-R:」 「(マイキー)を合わせるマルチメディアインターネットの主要な分配の追加方法」、RFC4738、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.、ジーター、M.、およびK.Norrman、「華麗なる陰謀が安全なリアルタイムのトランスポート・プロトコル(SRTP)のために打ち返す保全変換携帯」、RFC4771(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.、カッスルフォード、D.、およびF.ハルトゥング、「開いているモバイル同盟BCAST LTKM/STKM輸送のために一般拡大有効搭載量を合わせる(マイキー)マルチメディアインターネット」、RFC4909(2007年6月)。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC4949] Shirey、R.、「インターネットセキュリティ用語集、バージョン2インチ、RFC4949、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.翼、「セキュリティはセッション記述プロトコル(SDP)メディアストリームのためにあらかじめ調整する」RFC5027、2007年10月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to
Historic", RFC 5125, February 2008.
[RFC5125]テイラー、T.、「Reclassification、歴史的へのRFC3525、」、RFC5125、2月2008日
[SAML_overview] Huges, J. and E. Maler, "Security Assertion Markup
Language (SAML) 2.0 Technical Overview, Working
Draft", 2005.
[SAML_概要]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.
[一口メディア]は飛んで行きます、D.、フリーズ、S.、Tschofenig、H.、「メディアセキュリティ管理プロトコルの要件と分析」というF.Audetは進行中(2008年6月)で働いています。
Fries & Ignjatic Informational [Page 29] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[29ページ]のRFC5197マイキーモード適用性2008年6月
[WING-MMUSIC] Raymond, R. and D. Wing, "Security Descriptions
Extension for Early Media", Work in Progress,
October 2005.
[翼-MMUSIC] レイモンド、研究開発翼、「早めのメディアのためのセキュリティ記述拡大」は進歩、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.、ジョンストン、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 Polycom3605ギルモアWay、バーナビー、紀元前のV5G4X5カナダ
EMail: dignjatic@polycom.com
メール: dignjatic@polycom.com
Fries & Ignjatic Informational [Page 30] RFC 5197 MIKEY Modes Applicability June 2008
フライドポテトとIgnjaticの情報[30ページ]のRFC5197マイキーモード適用性2008年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Fries & Ignjatic Informational [Page 31]
フリーズとIgnjatic情報です。[31ページ]
一覧
スポンサーリンク
