RFC4567 日本語訳
4567 Key Management Extensions for Session Description Protocol (SDP)and Real Time Streaming Protocol (RTSP). J. Arkko, F. Lindholm, M.Naslund, K. Norrman, E. Carrara. July 2006. (Format: TXT=67693 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Arkko
Request for Comments: 4567 F. Lindholm
Category: Standards Track M. Naslund
K. Norrman
Ericsson
E. Carrara
Royal Institute of Technology
July 2006
Arkkoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4567年のF.リンドホルムカテゴリ: 工科大学2006年7月のロイヤルの標準化過程のジーター・K.NorrmanエリクソンE.M.カラーラ
Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP)
セッション記述プロトコル(SDP)とリアルタイムのストリーミングのプロトコルのためのKey Management拡大(RTSP)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.
Session記述プロトコル(SDP)とレアルTime Streamingプロトコル(RTSP)がメッセージを伝えるように、このドキュメントは一般的な拡大を定義します、かぎ管理プロトコルによって指定されるように、メディアを保証するために。 これらの拡大は、1つ以上のかぎ管理プロトコルによって使用されるためにフレームワークとして提示されます。 そういうものとして、適切なかぎ管理プロトコルで補足となる場合にだけ、彼らの使用は重要です。
General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined.
また、フレームワークがSIPとRTSPと共にどう使用されるべきであるかに関して一般的ガイドラインを与えます。 また、MultimediaインターネットKEYing(マイキー)かぎ管理プロトコルがある用法は定義されます。
Arkko, et al. Standards Track [Page 1] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[1ページ]RFC4567Key Management拡張子とRTSP2006年7月
Table of Contents
目次
1. Introduction ....................................................3
1.1. Notational Conventions .....................................4
2. Applicability ...................................................4
3. Extensions to SDP and RTSP ......................................5
3.1. SDP Extensions .............................................5
3.2. RTSP Extensions ............................................6
4. Usage with SDP, SIP, RTSP, and SAP ..............................7
4.1. Use of SDP .................................................8
4.1.1. General Processing ..................................8
4.1.2. Use of SDP with Offer/Answer and SIP ...............10
4.1.3. Use of SDP with SAP ................................13
4.1.4. Bidding-Down Attack Prevention .....................13
4.2. RTSP Usage ................................................14
5. Example Scenarios ..............................................17
5.1. Example 1 (SIP/SDP) .......................................17
5.2. Example 2 (SDP) ...........................................18
5.3. Example 3 (RTSP) ..........................................18
5.4. Example 4 (RTSP) ..........................................20
6. Adding Further Key Management Protocols ........................21
7. Integration of MIKEY ...........................................22
7.1. MIKEY Interface ...........................................22
8. Security Considerations ........................................23
9. IANA Considerations ............................................25
9.1. SDP Attribute Registration ................................25
9.2. RTSP Registration .........................................26
9.3. Protocol Identifier Registration ..........................26
10. Acknowledgements ..............................................27
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................28
1. 序論…3 1.1. 記号法のコンベンション…4 2. 適用性…4 3. SDPとRTSPへの拡大…5 3.1. SDP拡張子…5 3.2. RTSP拡張子…6 4. SDPがある用法、一口、RTSP、およびSAP…7 4.1. SDPの使用…8 4.1.1. 一般処理…8 4.1.2. 申し出/答えと一口とのSDPの使用…10 4.1.3. SAPとのSDPの使用…13 4.1.4. 下に入札攻撃防止…13 4.2. RTSP用法…14 5. 例のシナリオ…17 5.1. 例1(一口/SDP)…17 5.2. 例2(SDP)…18 5.3. 例3(RTSP)…18 5.4. 例4(RTSP)…20 6. さらなるKey Managementプロトコルを加えます…21 7. マイキーの統合…22 7.1. マイキーインタフェース…22 8. セキュリティ問題…23 9. IANA問題…25 9.1. SDPは登録を結果と考えます…25 9.2. RTSP登録…26 9.3. 識別子登録について議定書の中で述べてください…26 10. 承認…27 11. 参照…27 11.1. 標準の参照…27 11.2. 有益な参照…28
Arkko, et al. Standards Track [Page 2] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[2ページ]RFC4567Key Management拡張子とRTSP2006年7月
1. Introduction
1. 序論
There has recently been work to define a security profile for the protection of real-time applications running over RTP, [SRTP]. However, a security protocol needs a key management solution to exchange keys and security parameters, manage and refresh keys, etc.
最近、RTP、[SRTP]をひくリアルタイムのアプリケーションの保護のためのセキュリティプロフィールを定義するために、仕事がありました。 しかしながら、セキュリティプロトコルは、キーとセキュリティパラメタを交換して、管理して、キーなどをリフレッシュするためにかぎ管理解決を必要とします。
A key management protocol is executed prior to the security protocol's execution. The key management protocol's main goal is to, in a secure and reliable way, establish a security association for the security protocol. This includes one or more cryptographic keys and the set of necessary parameters for the security protocol, e.g., cipher and authentication algorithms to be used. The key management protocol has similarities with, e.g., SIP [SIP] and RTSP [RTSP] in the sense that it negotiates necessary information in order to be able to set up the session.
かぎ管理プロトコルはセキュリティプロトコルの実行の前に実行されます。 かぎ管理プロトコルの第一目的はセキュリティプロトコルのために安全で信頼できる方法でセキュリティ協会を設立することになっています。 これは、使用されるために1個以上の暗号化キーとセキュリティプロトコルのための必要なパラメタ、例えば、暗号と認証アルゴリズムのセットを含んでいます。 セッションをセットアップできるように必要事項を交渉するという意味における管理プロトコルには類似性があるキー、例えば、SIP[SIP]、およびRTSP[RTSP]。
The focus in the following sections is to describe a new SDP attribute and RTSP header extension to support key management, and to show how these can be integrated within SIP and RTSP. The resulting framework is completed by one or more key management protocols, which use the extensions provided.
以下のセクションの焦点は、新しいSDP属性とRTSPヘッダー拡張子についてサポート重要管理に説明して、SIPとRTSPの中でどうこれらを統合できるかを示していることになっています。 結果として起こるフレームワークは1つ以上のかぎ管理プロトコルで完成します。拡大はその使用を提供しました。
Some of the motivations to create a framework with the possibility to include the key management in the session establishment are:
セッション設立におけるかぎ管理を含む可能性で骨組を立てる動機のいくつかは以下の通りです。
* Just as the codec information is a description of how to encode and
decode the audio (or video) stream, the key management data is a
description of how to encrypt and decrypt the data.
* ちょうどコーデック情報がオーディオ(または、ビデオ)ストリームをコード化して、どう解読するかに関する記述であるように、かぎ管理データはデータを暗号化して、どう解読するかに関する記述です。
* The possibility to negotiate the security for the entire multimedia
session at the same time.
* 同時に全体のマルチメディアセッションのためにセキュリティを交渉する可能性。
* The knowledge of the media at session establishment makes it easy
to tie the key management to the multimedia sessions.
* セッション設立のメディアに関する知識で、マルチメディアセッションにかぎ管理を結ぶのは簡単になります。
* This approach may be more efficient than setting up the security
later, as that approach might force extra roundtrips, possibly also
a separate setup for each stream, hence implying more delay to the
actual setup of the media session.
* このアプローチは後でセキュリティをセットアップするより効率的であるかもしれません、そのアプローチが付加的な往復旅行、各ストリームのためのことによるとまた、別々のセットアップを強制するかもしれないとき、したがって、メディアセッションの実際のセットアップにより多くの遅れを含意して。
* The possibility to negotiate keying material end-to-end without
applying end-to-end protection of the SDP (instead, hop-by-hop
security mechanisms can be used, which may be useful if
intermediate proxies need access to the SDP).
* SDP(代わりに、ホップごとのセキュリティー対策(中間的プロキシがSDPへのアクセスを必要とするなら、役に立つかもしれない)を使用できる)の終わりから終わりへの保護を適用しないで物質的な終わりから終わりを合わせながら交渉する可能性。
Arkko, et al. Standards Track [Page 3] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[3ページ]RFC4567Key Management拡張子とRTSP2006年7月
Currently in SDP [SDPnew], there exists one field to transport keys, the "k=" field. However, this is not enough for a key management protocol as there are many more parameters that need to be transported, and the "k=" field is not extensible. The approach used is to extend the SDP description through a number of attributes that transport the key management offer/answer and also to associate it with the media sessions. SIP uses the offer/answer model [OAM] whereby extensions to SDP will be enough. However, RTSP [RTSP] does not use the offer/answer model with SDP, so a new RTSP header is introduced to convey key management data. [SDES] uses the approach of extending SDP, to carry the security parameters for the media streams. However, the mechanism defined in [SDES] requires end-to- end protection of the SDP by some security protocol such as S/MIME, in order to get end-to-end protection. The solution described here focuses only on the end-to-end protection of key management parameters and as a consequence does not require external end-to-end protection means. It is important to note though, and we stress this again, that only the key management parameters are protected.
現在、SDP[SDPnew]では、1つの分野が、キー、「k=」野原を輸送するために存在しています。 しかしながら、輸送される必要があるずっと多くのパラメタがあるとき、かぎ管理プロトコルには、これは十分ではありません、そして、「k=」分野は広げることができません。 使用されるアプローチは、かぎ管理申し出/答えを輸送する多くの属性を通したSDP記述を広げて、また、メディアセッションにそれを関連づけることです。 SIPはSDPへの拡大が十分になる申し出/答えモデル[OAM]を使用します。 しかしながら、RTSP[RTSP]がSDPの申し出/答えモデルを使用しないので、新しいRTSPヘッダーはかぎ管理データを伝えるために紹介されます。 [SDES]はメディアストリームのためのセキュリティパラメタを運ぶためにSDPを広げるアプローチを使用します。しかしながら、[SDES]で定義されたメカニズムはS/MIMEなどの何らかのセキュリティプロトコルで終わりから終わりへのSDPの保護を必要とします、終わりから終わりへの保護を得るために。 かぎ管理パラメタ、結果が終わりから終わりへの保護外部の手段を必要としないとき、ここで説明されたソリューションは終わりから終わりへの保護だけに焦点を合わせます。 それはもっとも、注意するために重要です、そして、私たちは再びこれに圧力を加えます、そして、かぎ管理パラメタだけが保護されます。
The document also defines the use of the described framework together with the key management protocol Multimedia Internet KEYing (MIKEY) [MIKEY].
また、ドキュメントはかぎ管理プロトコルMultimediaインターネットKEYing(マイキー)[マイキー]と共に説明されたフレームワークの使用を定義します。
1.1. Notational Conventions
1.1. 記号法のコンベンション
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Applicability
2. 適用性
[SDES] provides similar cryptographic key distribution capabilities, and it is intended for use when keying material is protected along with the signaling.
[SDES]は同様の暗号化キー分配に能力を提供します、そして、合わせることの材料がシグナリングと共に保護されるとき、それは使用のために意図します。
In contrast, this specification expects endpoints to have preconfigured keys or common security infrastructure. It provides its own security and is independent of the protection of signaling (if any). As a result, it can be applied in environments where signaling protection is not turned on, or used hop-by-hop (i.e., scenarios where the SDP is not protected end-to-end). This specification will, independently of the signaling protection applied, ensure end-to-end security establishment for the media.
対照的に、この仕様は、終点がキーか共通の安全保障インフラストラクチャをあらかじめ設定したと予想します。 それは、それ自身のセキュリティを提供して、(もしあれば)合図する保護から独立しています。 その結果、シグナリング保護がつけられてもいませんし、ホップごとに使用もされない環境(すなわち、SDPが保護された終わりから終わりでないシナリオ)でそれを適用できます。 保護が適用したシグナリングの如何にかかわらず、この仕様はメディアのために終わりから終わりへのセキュリティ設立を確実にするでしょう。
Arkko, et al. Standards Track [Page 4] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[4ページ]RFC4567Key Management拡張子とRTSP2006年7月
3. Extensions to SDP and RTSP
3. SDPとRTSPへの拡大
This section describes common attributes that can be included in SDP or RTSP when an integrated key management protocol is used. The attribute values follow the general SDP and RTSP guidelines (see [SDPnew] and [RTSP]).
このセクションは統合かぎ管理プロトコルが使用されているときSDPかRTSPに含むことができる一般的な属性について説明します。 属性値は一般的なSDPとRTSPガイドラインに従います([SDPnew]と[RTSP]を見てください)。
For both SDP and RTSP, the general method of adding the key management protocol is to introduce new attributes, one identifier to identify the specific key management protocol, and one data field where the key management protocol data is placed. The key management protocol data contains the necessary information to establish the security protocol, e.g., keys and cryptographic parameters. All parameters and keys are protected by the key management protocol.
SDPとRTSPの両方に関しては、かぎ管理プロトコルを加える一般的なメソッドは新しい属性、特定のかぎ管理プロトコルを特定する1つの識別子、およびかぎ管理プロトコルデータが置かれる1つのデータ・フィールドを紹介することです。 かぎ管理プロトコルデータは例えばセキュリティプロトコル、キー、および暗号のパラメタを確立する必要事項を含んでいます。 すべてのパラメタとキーはかぎ管理プロトコルによって保護されます。
The key management data SHALL be base64 [RFC3548] encoded and comply with the base64 grammar as defined in [SDPnew]. The key management protocol identifier, KMPID, is defined as below in Augmented Backus- Naur Form grammar (ABNF) [RFC4234].
かぎ管理データSHALLは[RFC3548]がコード化したbase64であり、[SDPnew]で定義されるようにbase64文法に従います。 かぎ管理プロトコル識別子(KMPID)はAugmentedバッカスナウアForm文法(ABNF)[RFC4234]で以下で定義されます。
KMPID = 1*(ALPHA / DIGIT)
KMPID=1*(アルファー/ケタ)
Values for the identifier, KMPID, are registered and defined in accordance to Section 9. Note that the KMPID is case sensitive, and it is RECOMMENDED that values registered are lowercase letters.
識別子のための値(KMPID)は、一致でセクション9と示されて、定義されます。 KMPIDが大文字と小文字を区別していることに注意してください。そうすれば、示された値が小文字であることはRECOMMENDEDです。
3.1. SDP Extensions
3.1. SDP拡張子
This section provides an ABNF grammar (as used in [SDPnew]) for the key management extensions to SDP.
このセクションはABNF文法([SDPnew]で使用されるように)をSDPへのかぎ管理拡大に提供します。
Note that the new definitions are compliant with the definition of an attribute field, i.e.,
すなわち、新しい定義が属性分野の定義で対応であることに注意してください。
attribute = (att-field ":" att-value) / att-field
「att属性=(attに、」 : 」 att-値をさばきます)/分野
The ABNF for the key management extensions (conforming to the att-field and att-value) are as follows:
かぎ管理拡大(att-分野とatt-値に従う)のためのABNFは以下の通りです:
key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value
「主要な管理属性=キー管理att分野」:、」 主要な管理att価値
key-mgmt-att-field = "key-mgmt"
key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data
主要な管理att分野=「主要な管理」主要な管理att価値=0*1SP prtcl-イド、SP keymgmt-データ
prtcl-id = KMPID
; e.g., "mikey"
prtcl-イドはKMPIDと等しいです。 例えば、"mikey"
Arkko, et al. Standards Track [Page 5] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[5ページ]RFC4567Key Management拡張子とRTSP2006年7月
keymgmt-data = base64
SP = %x20
keymgmt-データ=base64 SP=%x20
where KMPID is as defined in Section 3 of this memo, and base64 is as defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined for KMPID in Section 9.
KMPIDが定義されるとしてあるところに、[SDPnew]がSDPで定義されるようにこのメモ、およびbase64のセクション3に、あります。 Prtcl-イドはセクション9におけるKMPIDのために定義された値のセットについて言及します。
The attribute MAY be used at session level, media level, or at both levels. An attribute defined at media level overrides an attribute defined at session level. In other words, if the media-level attribute is present, the session level attribute MUST be ignored for this media. Section 4.1 describes in detail how the attributes are used and how the SDP is handled in different usage scenarios. The choice of the level depends, for example, on the particular key management protocol. Some protocols may not be able to derive enough key material for all the sessions; furthermore, possibly a different protection to each session could be required. The particular protocol might achieve this only by specifying it at the media level. Other protocols, such as MIKEY, have instead those capabilities (as it can express multiple security policies and derive multiple keys), so it may use the session level.
属性はセッションレベル、メディアレベルにおいて、または、両方のレベルにおいて使用されるかもしれません。 メディアレベルで定義された属性はセッションレベルで定義された属性をくつがえします。 言い換えれば、メディアレベル属性が存在しているなら、このメディアのためにセッションレベル属性を無視しなければなりません。 セクション4.1は詳細であり属性がどのように使用されているか、そして、SDPに異なった用法シナリオでどのように扱われたかを記述します。 例えば、レベルのこの選択は特定のかぎ管理プロトコル次第です。 いくつかのプロトコルはすべてのセッションのための十分な主要な材料を誘導できないかもしれません。 その上、ことによると異なった各セッションまでの保護を必要とすることができました。 特定のプロトコルは、単にメディアレベルでそれを指定することによって、これを実現するかもしれません。 マイキーなどの他のプロトコルにはそれらの能力が代わりにあるので(複数の安全保障政策を言い表して、複数のキーを引き出すことができるとき)、それはセッションレベルを使用するかもしれません。
3.2. RTSP Extensions
3.2. RTSP拡張子
To support the key management attributes, the following RTSP header is defined:
かぎ管理が属性であるとサポートするために、以下のRTSPヘッダーは定義されます:
KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec)
「KeyMgmtは"KeyMgmt"と等しい」:、」 主要な管理仕様0*(「」、主要な管理仕様)
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %x22 URI %x22 ";"]
「主要な管理仕様="prot"は「」 KMPIDと等しいです」」 [「"uri"は「」 %x22URI%x22等しい」;、」、]
where KMPID is as defined in Section 3 of this memo, "base64" as defined in [SDPnew], and "URI" as defined in Section 3 of [RFC3986].
KMPIDがこのメモのセクション3で定義されるようにあるところでは、「[RFC3986]のセクション3で定義される[SDPnew]、および「ユリ」で定義されるbase64"。」です。
The "uri" parameter identifies the context for which the key management data applies, and the RTSP URI SHALL match a (session or media) URI present in the description of the session. If the RTSP aggregated control URI is included, it indicates that the key management message is on session level (and similarly the RTSP media control URI that it applies to the media level). If no "uri" parameter is present in a key-mgmt-spec the specification applies to the context identified by the RTSP request URI.
"uri"パラメタはかぎ管理データが適用される文脈を特定します、そして、RTSP URI SHALLはセッションの記述における現在の(セッションかメディア)URIに合っています。 RTSPがコントロールに集めたならURIが含まれている、それはかぎ管理メッセージがセッションレベルにあるのを示します(同様に、RTSPメディアはそれがメディアレベルに適用するURIを制御します)。 どんな"uri"パラメタも主要な管理仕様に存在していないなら、仕様はRTSP要求URIによって特定された文脈に適用されます。
The KeyMgmt header MAY be used in the messages and directions described in the table below.
KeyMgmtヘッダーは以下のテーブルで説明されたメッセージと方向に使用されるかもしれません。
Arkko, et al. Standards Track [Page 6] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[6ページ]RFC4567Key Management拡張子とRTSP2006年7月
Method | Direction | Requirement --------------------------------------------- DESCRIBE response | S->C | RECOMMENDED SETUP | C->S | REQUIRED SETUP Response | S->C | REQUIRED (error)
メソッド| 方向| 要件--------------------------------------------- DESCRIBE応答| S>C| お勧めのセットアップ| C>S| 必要なセットアップ応答| S>C| 必要です。(誤り)
Note: Section 4.2 describes in detail how the RTSP extensions are used.
以下に注意してください。 セクション4.2は詳細にRTSP拡張子がどう使用されているかを説明します。
We define one new RTSP status code to report error due to any failure during the key management processing (Section 4.2):
私たちはかぎ管理処理(セクション4.2)の間、どんな失敗による誤りも報告するために1つの新しいRTSPステータスコードを定義します:
Status-Code = "463" ; Key management failure
ステータスコード=「463」。 かぎ管理失敗
A 463 response MAY contain a KeyMgmt header with a key management protocol message that further indicates the nature of the error.
463応答はさらに誤りの本質を示すかぎ管理プロトコルメッセージでKeyMgmtヘッダーを含むかもしれません。
4. Usage with SDP, SIP, RTSP, and SAP
4. SDP、一口、RTSP、およびSAPがある用法
This section gives rules and recommendations of how/when to include the defined key management attribute when SIP and/or RTSP are used together with SDP.
このセクションは/SIPであるときに、いつ定義されたかぎ管理属性を含んでいるか、そして、そして/または、RTSPがSDPと共にどう使用されるかに関する規則と推薦を与えます。
When a key management protocol is integrated with SIP/SDP and RTSP, the following general requirements are placed on the key management:
かぎ管理プロトコルがSIP/SDPとRTSPについて統合しているとき、以下の一般的な要件はかぎ管理に置かれます:
* At the current time, it MUST be possible to execute the key
management protocol in at most one request-response message
exchange. Future relaxation of this requirement is possible but
would introduce significant complexity for implementations
supporting multi-roundtrip mechanisms.
* 現在の時間に、ほとんどの1つの要求応答メッセージ交換のときにかぎ管理プロトコルを作るのは可能であるに違いありません。 この要件の将来の緩和は、可能ですが、マルチ往復旅行メカニズムをサポートする実装のために重要な複雑さを導入するでしょう。
* It MUST be possible from the SIP/SDP and RTSP application, using
the key management API, to receive key management data and
information of whether or not a message is accepted.
* それはSIP/SDPとRTSPアプリケーションによって可能であるに違いありません、メッセージを受け入れるかどうかのかぎ管理データと情報を受け取るのにかぎ管理APIを使用して。
The content of the key management messages depends on the key management protocol that is used. However, the content of such key management messages might be expected to be roughly as follows: the key management Initiator (e.g., the offerer) includes the key management data in a first message, containing the media description it should apply to. This data in general consists of the security parameters (including key material) needed to secure the communication, together with the necessary authentication information (to ensure that the message is authentic).
かぎ管理メッセージの内容は使用されたかぎ管理プロトコルによります。 しかしながら、そのようなかぎ管理メッセージの内容はおよそ以下の通りであると予想されるかもしれません: かぎ管理Initiator(例えば、申出人)は最初のメッセージにかぎ管理データを含んでいます、それが申し込むべきであるメディア記述を含んでいて。 一般に、このデータはコミュニケーションを保証するのに必要であるセキュリティパラメタ(主要な材料を含んでいる)から成ります、必要な認証情報(メッセージが確実に正統になるようにする)と共に。
Arkko, et al. Standards Track [Page 7] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[7ページ]RFC4567Key Management拡張子とRTSP2006年7月
At the Responder's side, the key management protocol checks the validity of the key management message, together with the availability of the parameters offered, and then provides the key management data to be included in the answer. This answer may typically authenticate the Responder to the Initiator, and also state if the initial offer was accepted or not. Certain protocols might require the Responder to include a selection of the security parameters that he is willing to support. Again, the actual content of such responses is dependent on the particular key management protocol.
Responderの側では、かぎ管理プロトコルは、パラメタの有用性と共に提供されたかぎ管理メッセージの正当性をチェックして、次に、答えに含まれるようにかぎ管理データを提供します。 初期の申し出を受け入れたなら、この答えは、通常InitiatorへのResponderを認証して、また、状態を認証するかもしれません。 あるプロトコルは、Responderが彼がサポートしても構わないと思っているセキュリティパラメタの品揃えを含んでいるのを必要とするかもしれません。 一方、そのような応答の実際の内容は特定のかぎ管理プロトコルに依存しています。
Section 7 describes a realization of the MIKEY protocol using these mechanisms. Procedures to be used when mapping new key management protocols onto this framework are described in Section 6.
セクション7は、これらのメカニズムを使用することでマイキープロトコルの実現について説明します。新しいかぎ管理プロトコルをこのフレームワークに写像するとき使用されるべき手順はセクション6で説明されます。
4.1. Use of SDP
4.1. SDPの使用
This section describes the processing rules for the different applications that use SDP for the key management.
このセクションはかぎ管理にSDPを使用する異なったアプリケーションのための処理規則について説明します。
4.1.1. General Processing
4.1.1. 一般処理
The processing when SDP is used is slightly different according to the way SDP is transported, and if it uses an offer/answer or announcement. The processing can be divided into four different steps:
SDPが使用されているとき、SDPが輸送される方法と、それが申し出/答えを使用するか、そして、発表に従って、処理はわずかに異なっています。 処理を以下の異なった4ステップに分割できます:
1) How to create the initial offer. 2) How to handle a received offer. 3) How to create an answer. 4) How to handle a received answer.
1) 初期の申し出を作成する方法。 2) 容認された申し出を扱う方法。 3) 答えを作成する方法。 4) 容認された答えを扱う方法。
It should be noted that the last two steps may not always be applicable, as there are cases where an answer cannot or will not be sent back.
最後の2ステップがいつも適切であるかもしれないというわけではないことに注意されるべきです、ケースが答えが戻ることができませんし、返送もされないところにあるとき。
The general processing for creating an initial offer SHALL follow the following actions:
SHALLが続く初期の申し出を作成するために以下の動作を処理する司令官:
* The identifier of the key management protocol used MUST be placed
in the prtcl-id field of SDP. A table of legal protocols
identifiers is maintained by IANA (see Section 9).
* SDPのprtcl-イド分野に使用されるかぎ管理プロトコルに関する識別子を置かなければなりません。 法的なプロトコル識別子のテーブルはIANAによって維持されます(セクション9を見てください)。
Arkko, et al. Standards Track [Page 8] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[8ページ]RFC4567Key Management拡張子とRTSP2006年7月
* The keymgmt-data field MUST be created as follows: the key
management protocol MUST be used to create the key management
message. This message SHALL be base64 encoded [RFC3548] by the SDP
application and then encapsulated in the keymgmt-data attribute.
Note though that the semantics of the encapsulated message is
dependent on the key management protocol that is used.
* 以下の通りでkeymgmt-データ・フィールドを作成しなければなりません: かぎ管理メッセージを作成するのにかぎ管理プロトコルを使用しなければなりません。 このメッセージSHALLはSDPアプリケーションでコード化された[RFC3548]base64であり、次に、keymgmt-データ属性で要約しました。 もっとも、カプセル化されたメッセージの意味論が使用されたかぎ管理プロトコルに依存していることに注意してください。
The general processing for handling a received offer SHALL follow the following actions:
SHALLが続く容認された申し出を扱うために以下の動作を処理する司令官:
* The key management protocol is identified according to the prtcl-id
field. A table of legal protocols identifiers is maintained by
IANA (Section 9).
* prtcl-イド分野に従って、かぎ管理プロトコルは特定されます。 法的なプロトコル識別子のテーブルはIANA(セクション9)によって維持されます。
* The key management data from the keymgmt-data field MUST be
extracted, base64 decoded to reconstruct the original message, and
then passed to the key management protocol for processing. Note
that depending on key management protocol, some extra parameters
might also be requested by the specific API, such as the
source/destination network address/port(s) for the specified media
(however, this will be implementation specific depending on the
actual API). The extra parameters that a key management protocol
might need (other than the ones defined here) MUST be documented,
describing their use, as well as the interaction of that key
management protocol with SDP and RTSP.
* keymgmt-データ・フィールドからのかぎ管理データを抜粋しなければならなくて、base64は処理のためにかぎ管理プロトコルにオリジナルのメッセージを再建するために解読して、次に、通りました。 かぎ管理に頼るのが議定書を作るというメモ、また、いくつかの付加的なパラメタが特定のAPIによって要求されるかもしれません、指定されたメディアのためのソース/送信先ネットワークアドレス/ポートなどのように(しかしながら、実際のAPIによって、これは実装特有になるでしょう)。 かぎ管理プロトコルが必要とするかもしれない(ここで定義されたものを除いて)付加的なパラメタを記録しなければなりません、彼らの使用、およびSDPとRTSPとのそのかぎ管理プロトコルの相互作用について説明して。
* If errors occur, or the key management offer is rejected, the
session SHALL be aborted. Possible error messages are dependent on
the specific session establishment protocol.
* 誤りであるなら起こってください。さもないと、かぎ管理申し出は拒絶されて、セッションはSHALLです。中止されます。 可能なエラーメッセージは特定のセッション設立プロトコルに依存しています。
At this stage, the key management will have either accepted or rejected the offered parameters. This MAY cause a response message to be generated, depending on the key management protocol and the application scenario.
現在のところ、かぎ管理は、提供されたパラメタを受け入れてしまうだろうか、または拒絶してしまうでしょう。 これで、かぎ管理プロトコルとアプリケーションシナリオによって、応答メッセージを生成するかもしれません。
If an answer is to be generated, the following general actions SHALL be performed:
生成されるために、答えはあって、↓これは一般的な動作SHALLです。実行されてください:
* The identifier of the key management protocol used MUST be placed
in the prtcl-id field.
* 使用されるかぎ管理プロトコルに関する識別子をprtcl-イド分野に置かなければなりません。
* The keymgmt-data field MUST be created as follows. The key
management protocol MUST be used to create the key management
message. This message SHALL be base64 encoded [RFC3548] by the SDP
application and then encapsulated in the keymgmt-data attribute.
The semantics of the encapsulated message is dependent on the key
management protocol that is used.
* 以下の通りでkeymgmt-データ・フィールドを作成しなければなりません。 かぎ管理メッセージを作成するのにかぎ管理プロトコルを使用しなければなりません。 このメッセージSHALLはSDPアプリケーションでコード化された[RFC3548]base64であり、次に、keymgmt-データ属性で要約しました。 カプセル化されたメッセージの意味論は使用されたかぎ管理プロトコルに依存しています。
Arkko, et al. Standards Track [Page 9] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[9ページ]RFC4567Key Management拡張子とRTSP2006年7月
The general processing for handling a received answer SHALL follow the following actions:
SHALLが続く容認された答えを扱うために以下の動作を処理する司令官:
* The key management protocol is identified according to the prtcl-id
field.
* prtcl-イド分野に従って、かぎ管理プロトコルは特定されます。
* The key management data from the keymgmt-data field MUST be
extracted, base64 decoded to reconstruct the original message, and
then passed to the key management protocol for processing.
* keymgmt-データ・フィールドからのかぎ管理データを抜粋しなければならなくて、base64は処理のためにかぎ管理プロトコルにオリジナルのメッセージを再建するために解読して、次に、通りました。
* If the key management offer is rejected and the intent is to re-
negotiate it, it MUST be done through another Offer/Answer
exchange. It is RECOMMENDED to NOT abort the session in that case,
but to re-negotiate using another Offer/Answer exchange. For
example, in [SIP], the "security precondition" as defined in
[SPREC] solves the problem for a session initiation. The
procedures in [SPREC] are outside the scope of this document. In
an established session, an additional Offer/Answer exchange using a
re-INVITE or UPDATE as appropriate MAY be used
* 意図がかぎ管理申し出が拒絶されて、それを再交渉することであるなら、別のOffer/答え交換を通してそれをしなければなりません。 それはしかし別のOffer/答え交換を使用することで再交渉するためにその場合セッションを中止しないRECOMMENDEDです。 例えば、[SIP]では、[SPREC]で定義される「セキュリティ前提条件」はセッション開始のための問題を解決します。 このドキュメントの範囲の外に[SPREC]の手順があります。 確立したセッションのときに、再INVITEかUPDATEを使用する追加Offer/答え交換は適宜使用されるかもしれません。
* If errors occur, or the key management offer is rejected and there
is no intent to re-negotiate it, the session SHALL be aborted. If
possible, an error message indicating the failure SHOULD be sent
back.
* 誤りであるなら起こるか、または経営者側が提供するキーは拒絶されます、そして、それを再交渉する意図が全くありません、セッションSHALL。中止されます。 できれば失敗SHOULDが返送されるのを示すエラーメッセージ。
Otherwise, if all the steps are successful, the normal setup proceeds.
さもなければ、すべてのステップがうまくいくなら、通常のセットアップは続きます。
4.1.2. Use of SDP with Offer/Answer and SIP
4.1.2. 申し出/答えと一口とのSDPの使用
This section defines additional processing rules, to the general rules defined in Section 4.1.1, applicable only to applications using SDP with the offer/answer model [OAM] (and in particular SIP).
このセクションは追加処理規則を定義します、セクション4.1.1で定義された総則に、申し出/答えモデル[OAM](そして、特にSIP)があるSDPを使用するアプリケーションだけに適切です。
When an initial offer is created, the following offer/answer-specific procedure SHALL be applied:
初期の申し出が作成されるとき、適用されていて、以下は/答え特有の手順にSHALLを提供します:
* Before creating the key management data field, the list of protocol
identifiers MUST be provided by the SDP application to (each) key
management protocol, as defined in Section 4.1.4 (to defeat
bidding-down attacks).
* かぎ管理データ・フィールドを作成する前に、(それぞれ)のかぎ管理プロトコルへのSDPアプリケーションでプロトコル識別子のリストを提供しなければなりません、セクション4.1.4(下に入札攻撃を破る)で定義されるように。
For a received SDP offer that contains the key management attributes, the following offer/answer-specific procedure SHALL be applied:
主要な管理属性、以下の答え申し出/特有の手順SHALLを含む容認されたSDP申し出には、適用されてください:
Arkko, et al. Standards Track [Page 10] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[10ページ]RFC4567Key Management拡張子とRTSP2006年7月
* Before, or in conjunction with, passing the key management data to
the key management protocol, the complete list of protocol
identifiers from the offer message is provided by the SDP
application to the key management protocol (as defined in Section
4.1.4).
* 通る前かかぎ管理データをかぎ管理プロトコルに通過すること、かぎ管理プロトコルへのSDPアプリケーションで申し出メッセージからのプロトコル識別子に関する全リストを提供します(セクション4.1.4で定義されるように)。
When an answer is created, the following offer/answer-specific procedure SHALL be applied:
答えが作成されるとき、適用されていて、以下は/答え特有の手順にSHALLを提供します:
* If the key management rejects the offer and the intent is to re-
negotiate it, the Answer SHOULD include the cause of failure in an
included message from the key management protocol. The
renegotiation MUST be done through another Offer/Answer exchange
(e.g., using [SPREC]). In an established session, it can also be
done through a re-INVITE or UPDATE as appropriate.
* 意図がかぎ管理が申し出を拒絶して、それを再交渉することであるなら、Answer SHOULDはかぎ管理プロトコルからの含まれているメッセージに失敗の原因を含んでいます。 別のOffer/答え交換(例えば、[SPREC]を使用する)を通して再交渉しなければなりません。 また、確立したセッションのときに、再INVITEかUPDATEを通して適宜それができます。
* If the key management rejects the offer and the session needs to be
aborted, the answerer SHOULD return a "488 Not Acceptable Here"
message, optionally also including one or more Warning headers (a
"306 Attribute not understood" when one of the parameters is not
supported, and a "399 Miscellaneous warning" with arbitrary
information to be presented to a human user or logged; see Section
20.43 in [SIP]). Further details about the cause of failure MAY be
described in an included message from the key management protocol.
The session is then aborted (and it is up to local policy or end
user to decide how to continue).
* かぎ管理が申し出を拒絶して、セッションが、中止される必要があるなら、answerer SHOULDは「ここで許容できない488」メッセージを返します、また、任意に1個以上のWarningヘッダーを含んでいて(パラメタの1つがサポートされないときの「理解されていなかった306Attribute」、および人間のユーザに提示されるべきであるか、または登録されるべき任意の情報がある「399Miscellaneous警告」; [SIP]でセクション20.43を見てください)。 失敗の原因に関する詳細はかぎ管理プロトコルからの含まれているメッセージで説明されるかもしれません。 そして、セッションは中止されます(続く方法を決めるのは、ローカルの方針かエンドユーザ次第です)。
Note that the key management attribute (related to the same key management protocol) MAY be present both at session level and at media level. Consequently, the process SHALL be repeated for each such key management attribute detected. In case the key management processing of any such attribute does not succeed (e.g., authentication failure, parameters not supported, etc.), on either session or media level, the entire session setup SHALL be aborted, including those parts of the session that successfully completed their part of the key management.
かぎ管理属性(同じかぎ管理プロトコルに関連する)がセッションレベルにおいてメディアレベルにおいて存在しているかもしれないことに注意してください。 その結果、そのようなそれぞれの主要な管理属性のために検出されていた状態で繰り返されて、SHALLを処理してください。 どんなそのような属性のかぎ管理処理も(例えば、認証失敗、サポートされなかったパラメタなど)を引き継がないといけないので、全体のセッションセットアップSHALLが中止されて、そんなに首尾よくセッションのそれらの部品を含んでいると、セッションかメディアレベルのどちらかに、それらのかぎ管理の部分は完成しました。
If more than one key management protocol is supported, multiple instances of the key management attribute MAY be included in the initial offer when using the offer/answer model, each transporting a different key management protocol, thus indicating supported alternatives.
申し出/答えモデルを使用するとき、1つ以上のかぎ管理プロトコルがサポートされるなら、かぎ管理属性の複数のインスタンスが初期の申し出に含まれるかもしれません、それぞれ異なったかぎ管理プロトコルを輸送して、その結果、サポートしている代替手段を示します。
If the offerer includes more than one key management protocol attribute at session level (analogous for the media level), these SHOULD be listed in order of preference (the first being the preferred). The answerer selects the key management protocol it wishes to use, and processes only it, on either session or media
申出人が1つ以上のかぎ管理を入れるなら、セッションレベル(メディアレベルにおいて、類似の)における属性について議定書の中で述べてください、これらのSHOULD。好みの順に、記載されてください(1番目が都合のよさであり)。 answererはそれが使用したがっているかぎ管理プロトコルを選択して、セッションかメディアのどちらかにそれだけを処理します。
Arkko, et al. Standards Track [Page 11] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[11ページ]RFC4567Key Management拡張子とRTSP2006年7月
level, or on both, according to where located. If the answerer does not support any of the offerer's suggested key management protocols, the answerer indicates this to the offerer so a new Offer/Answer can be triggered; alternatively, it may return a "488 Not Acceptable Here" error message, whereby the sender MUST abort the current setup procedure.
平らであるか、または位置しているところに従って両方の、オンです。 answererが申出人の提案されたかぎ管理プロトコルのいずれもサポートしないなら、answererは新しいOffer/答えを引き起こすことができるようにこれを申出人に示します。 あるいはまた、それは「ここで許容できない488」エラーメッセージを返すかもしれません。(送付者はそれで現在のセットアップ手順を中止しなければなりません)。
Note that the placement of multiple key management offers in a single message has the disadvantage that the message expands and the computational workload for the offerer will increase drastically. Unless the guidelines of Section 4.1.4 are followed, multiple lines may open up bidding-down attacks. Note also that the multiple-offer option has been added to optimize signaling overhead in case the Initiator knows some key (e.g., a public key) that the Responder has, but is unsure of what protocol the Responder supports. The mechanism is not intended to negotiate options within one and the same protocol.
ただ一つのメッセージにおける、複数のかぎ管理申し出のプレースメントにはメッセージが広くする不都合があって、申出人のためのコンピュータのワークロードが抜本的に増加することに注意してください。 セクション4.1.4のガイドラインが従われていない場合、複数の系列が下に入札攻撃を開けるかもしれません。 複数の申し出オプションにはある注意も、InitiatorがResponderが持っているあるキー(例えば、公開鍵)を知っているといけないのでシグナリングオーバーヘッドを最適化するために加えられますが、Responderがどんなプロトコルをサポートするかに不確かです。 メカニズムが全く同じプロトコルの中でオプションを交渉することを意図しません。
The offerer MUST include the key management data within an offer that contains the media description it applies to.
申出人はそれが申し込むメディア記述を含む申し出の中でかぎ管理データを入れなければなりません。
Re-keying MUST be handled as a new offer, with the new proposed parameters. The answerer treats this as a new offer where the key management is the issue of change. The re-keying exchange MUST be finalized before the security protocol can change the keys. The same key management protocol used in the original offer SHALL also be used in the new offer carrying re-keying. If the new offer carrying re- keying fails (e.g., the authentication verification fails), the answerer SHOULD send a "488 Not Acceptable Here" message, including one or more Warning headers (at least a 306). The offerer MUST then abort the session.
新しい申し出として新しい提案されたパラメタで再の合わせることを扱わなければなりません。 answererはかぎ管理が変化の問題であるところで新しい申し出としてこれを扱います。 セキュリティプロトコルがキーを変えることができる前に再の合わせる交換を成立させなければなりません。 同じかぎ管理プロトコルはオリジナルの申し出にSHALLを使用しました、また、再の合わせることを運ぶ新しい申し出に使用されてください。 再の合わせることを運ぶ新しい申し出が失敗するなら(例えば認証検証は失敗します)、answerer SHOULDは「ここで許容できない488」メッセージを送ります、1個以上のWarningヘッダー(少なくともa306)を含んでいて。 そして、申出人はセッションを中止しなければなりません。
Note that, in multicast scenarios, unlike unicast, there is only a single view of the stream [OAM], hence there MUST be a uniform agreement of the security parameters.
ユニキャストと異なって、マルチキャストシナリオにはストリーム[OAM]のただ一つの視点しかないことに注意して、したがって、セキュリティパラメタの一定の協定があるに違いありません。
After the offer is issued, the offerer SHOULD be prepared to receive media, as the media may arrive prior to the answer. However, this brings issues, as the offerer does not know yet the answerer's choice in terms of, e.g., algorithms, or possibly the key is known. This can cause delay or clipping can occur; if this is unacceptable, the offerer SHOULD use mechanisms outside the scope of this document, e.g., the security preconditions for SIP [SPREC].
申し出が発行された後に、メディアが到着するかもしれないように、申出人SHOULDがメディアを受け取るように準備されて、答えの前に到着してください。 例えば、アルゴリズム、またはことによるとキーがそうです。しかしながら、これは問題をもたらします、申出人がまだanswererの選択を知っていないように知られています。 これが遅れをきたすことができますか、または切り取りは現れることができます。 これが容認できないなら、申出人SHOULDはこのドキュメント(例えば、SIP[SPREC]のためのセキュリティ前提条件)の範囲の外でメカニズムを使用します。
Arkko, et al. Standards Track [Page 12] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[12ページ]RFC4567Key Management拡張子とRTSP2006年7月
4.1.3. Use of SDP with SAP
4.1.3. SAPとのSDPの使用
There are cases where SDP is used without conforming to the offer/answer model; instead, it is a one-way SDP distribution (i.e., without back channel), such as when used with SAP and HTTP.
ケースがSDPが申し出/答えモデルに従わないで使用されるところにあります。 代わりに、それはSAPとHTTPと共に使用されるいつなどの一方向SDP分配(すなわち、戻っているチャンネルのない)であるか。
The processing follows the two first steps of the general SDP processing (see Section 4.1.1). It can be noted that the processing in this case differs from the offer/answer case in that only one key management protocol SHALL be offered (i.e., no negotiation will be possible). This implies that the bidding-down attack is not an issue; therefore, the countermeasure is not needed. The key management protocol used MUST support one-way messages.
処理は一般的なSDP処理の2つの第一歩に続きます(セクション4.1.1を見てください)。 処理がこの場合1つのかぎ管理だけのプロトコルSHALLがある/がケースに答える申し出と提供していた状態で異なっていることに(すなわち、どんな交渉も可能にならないでしょう)注意できます。 これは、下に入札攻撃が問題でないことを含意します。 したがって、対策は必要ではありません。 使用されるかぎ管理プロトコルは一方向メッセージをサポートしなければなりません。
4.1.4. Bidding-Down Attack Prevention
4.1.4. 下に入札攻撃防止
The possibility to support multiple key management protocols may, unless properly handled, introduce bidding-down attacks. Specifically, a man-in-the-middle could "peel off" cryptographically strong offers (deleting the key management lines from the message), leaving only weaker ones as the Responder's choice. To avoid this, the list of identifiers of the proposed key management protocols MUST be authenticated. The authentication MUST be done separately by each key management protocol.
適切に扱われない場合、複数のかぎ管理がプロトコルであるとサポートする可能性は下に入札攻撃を導入するかもしれません。 明確に、中央の男性は暗号で、強い申し出(メッセージからかぎ管理系列を削除する)を「立ち去ることができました」、Responderの選択として、より弱いものだけを残して。 これを避けるために、提案されたかぎ管理プロトコルに関する識別子のリストを認証しなければなりません。 それぞれのかぎ管理プロトコルは別々に認証しなければなりません。
Accordingly, it MUST be specified (in the key management protocol specification itself or in a companion document) how the list of key management protocol identifiers can be processed to be authenticated from the offerer to the answerer by the specific key management protocol. Note that even if only one key management protocol is used, that still MUST authenticate its own protocol identifier.
それに従って、特定のかぎ管理プロトコルによって申出人からanswererまで認証されるためにどうしたらかぎ管理プロトコル識別子のリストを処理できるか指定しなければなりません(かぎ管理プロトコル仕様自体か仲間ドキュメントで)。 1つのかぎ管理プロトコルだけが使用されていても、それがまだそれ自身のプロトコル識別子を認証しなければならないことに注意してください。
The list of protocol identifiers MUST then be given to each of the selected (offered) key management protocols by the application with ";" separated identifiers. All the offered protocol identifiers MUST be included, in the same order as they appear in the corresponding SDP description.
「次に、アプリケーションでそれぞれの選択された(提供する)かぎ管理プロトコルにプロトコル識別子のリストを与えなければならない、」、;、」 切り離された識別子。 対応するSDP記述で同次に含まれているように見えますが、すべての提供されたプロトコル識別子がそうであるに違いありません。
The protocol list can formally be described as
正式にリストを記述できるプロトコル
prtcl-list = KMPID *(";" KMPID)
prtcl-リスト=KMPID*(「」、;、KMPID)
where KMPID is as defined in Section 3.
KMPIDがセクション3で定義されるようにあるところで。
For example, if the offered protocols are MIKEY and two yet-to-be- invented protocols KEYP1, KEYP2, the SDP is:
例えば、提供されたプロトコルがマイキーと2にもかかわらず、未来的に発明されたプロトコルKEYP1、KEYP2であるなら、SDPは以下の通りです。
Arkko, et al. Standards Track [Page 13] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[13ページ]RFC4567Key Management拡張子とRTSP2006年7月
v=0 o=alice 2891092738 2891092738 IN IP4 lost.example.com s=Secret discussion t=0 0 c=IN IP4 lost.example.com a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD... a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD... m=audio 39000 RTP/SAVP 98 a=rtpmap:98 AMR/8000 m=video 42000 RTP/SAVP 31 a=rtpmap:31 H261/90000
IN IP4 lost.example.com秘密の議論t=0 0v=0 o=alice2891092738 2891092738IN IP4 lost.example.com s=c=aは主要な管理と等しいです: mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... aは主要な管理と等しいです: keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD... aは主要な管理と等しいです: keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD…m=オーディオの39000RTP/SAVP98a=rtpmap: 98AMR/8000mはビデオ42000RTP/SAVP31a=rtpmap: 31H261/90000と等しいです。
The protocol list, "mikey;keyp1;keyp2", would be generated from the SDP description and used as input to each specified key management protocol (together with the data for that protocol). Each of the three protocols includes this protocol identifier list in its authentication coverage (according to its protocol specification).
プロトコルリスト、「mikey; keyp1; keyp2"、それぞれの指定されたかぎ管理プロトコル(そのプロトコルのためのデータに伴う)に入力されるようにSDP記述から生成されて、使用されるでしょう」。 それぞれの3つのプロトコルが認証適用範囲(プロトコル仕様通りに)にこのプロトコル名前の並びを含んでいます。
If more than one protocol is supported by the offerer, it is RECOMMENDED that all acceptable protocols are included in the first offer, rather than making single, subsequent alternative offers in response to error messages; see "Security Considerations".
1つ以上のプロトコルが申出人によってサポートされるなら、すべての許容できるプロトコルがエラーメッセージに対応して単一の、そして、その後の代替の申し出をするより最初の申し出にむしろ含まれているのは、RECOMMENDEDです。 「セキュリティ問題」を見てください。
End-to-end integrity protection of the key-mgmt attributes altogether, provided externally to the key management itself, also protects against this bidding-down attack. This is, for example, the case if SIP uses S/MIME [RFC3851] to end-to-end integrity protect the SDP description. However, as this end-to-end protection is not an assumption of the framework, the mechanisms defined in this section SHALL be applied.
また、全体で外部的にかぎ管理自体に提供された主要な管理属性の終わりから終わりへの保全保護はこの下に入札攻撃から守ります。 例えば、終わりから終わりへの保全へのSIP用途S/MIME[RFC3851]がSDP記述を保護するなら、これはそうです。 終わりから終わりへのこの保護がフレームワークの仮定でないのでメカニズムがこのセクションでどのようにSHALLを定義したとしても、適用されてください。
4.2. RTSP Usage
4.2. RTSP用法
RTSP does not use the offer/answer model, as SIP does. This causes some problems, as it is not possible (without modifying RTSP) to send back an answer. To solve this, a new header has been introduced (Section 3.2). This also assumes that the key management also has some kind of binding to the media, so that the response to the server will be processed as required.
RTSPはSIPが使用するように申し出/答えモデルを使用しません。 答えを返送するのが可能でないときに(RTSPを変更することのない)、これはいくつかの問題を引き起こします。 これを解決するために、新しいヘッダーは紹介されました(セクション3.2)。 また、これは、また、かぎ管理がある種の結合をメディアに持っていると仮定します、サーバへの応答が必要に応じて処理されるように。
The server SHALL be the Initiator of the key management exchange for sessions in PLAY mode, i.e., transporting media from server to client. The below text describes the behavior for PLAY mode. For any other mode, the behavior is not defined in this specification.
サーバSHALL、すなわち、PLAYモードにおけるセッションへのかぎ管理交換のInitiatorになってくださいサーバからクライアントまでメディアを輸送しながら。 以下のテキストはPLAYモードのための振舞いについて説明します。 いかなる他のモードにおいても、振舞いはこの仕様に基づき定義されません。
Arkko, et al. Standards Track [Page 14] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[14ページ]RFC4567Key Management拡張子とRTSP2006年7月
To obtain a session description, the client initially contacts the server via a DESCRIBE message. The initial key management message from the RTSP server is sent to the client in the SDP of the 200 OK in response to the DESCRIBE. Note that only one key management protocol SHALL be used per session/media level. A server MAY allow the SDP with key management attribute(s) to be distributed to the client through other means than RTSP, although this is not specified here.
セッション記述を得るために、DESCRIBEメッセージでクライアントは初めは、サーバに連絡します。 DESCRIBEに対応してRTSPサーバからの初期のかぎ管理メッセージを200OKのSDPのクライアントに送ります。 1つのかぎ管理だけのプロトコルSHALLがセッション/メディアレベル単位で使用されることに注意してください。 サーバは、かぎ管理属性があるSDPがRTSP以外の手段でクライアントに分配されるのを許容するかもしれません、これがここで指定されませんが。
The "uri" parameter of the KeyMgmt header is used to indicate for the key management protocol on what context the carried message applies. For key management messages on the SDP session level, the answer MUST contain the RTSP aggregated control URL to indicate this. For key management messages initially on SDP media level, the key management response message in the KeyMgmt header MAY use the RTSP media-level URL. For RTSP sessions not using aggregated control, i.e., no session-level control URI is defined, the key management protocol SHALL only be invoked on individual media streams. In this case also, the key management response SHALL be on individual media streams (i.e., one RTSP key management header per media).
KeyMgmtヘッダーの"uri"パラメタは、かぎ管理プロトコルのために運ばれたメッセージがどんな文脈に適用されるかを示すのに使用されます。 SDPに関するかぎ管理メッセージに関しては、レベル、答えがRTSPを含まなければならないセッションは、これを示すためにコントロールURLに集められました。 初めはSDPメディアレベルでは、KeyMgmtヘッダーのかぎ管理応答メッセージがRTSPメディアレベルURLを使用するかもしれないというかぎ管理メッセージのために。 また、この場合、かぎ管理応答SHALLは個々のメディアストリームのこと(すなわち、1メディアあたり1個のRTSPかぎ管理ヘッダー)です。集められたコントロールを使用しないRTSPセッションのためにすなわち、セッションレベルコントロールURIは全く定義されません、かぎ管理プロトコルSHALL。個々のメディアストリームに単に呼び出されてください。
When responding to the initial key management message, the client uses the new RTSP header (KeyMgmt) to send back an answer. How this is done depends on the usage context:
初期のかぎ管理メッセージに応じるとき、クライアントは、答えを返送するのに、新しいRTSPヘッダー(KeyMgmt)を使用します。 これがどう完了しているかは用法文脈によります:
* Key management protocol responses for the initial establishment of
security parameters for an aggregated RTSP session SHALL be sent in
the first SETUP of the session. This means that if the key
management is declared for the whole session but is set up in non-
aggregated fashion (i.e., one media per RTSP session), each SETUP
MUST carry the same response for the session-level context. When
performing a setup of the second or any subsequent media in an RTSP
session, the same key management parameters as established for the
first media also apply to these setups.
* かぎ管理は送られたコネがセッションの最初のSETUPであったなら集められたRTSPセッションSHALLのためのセキュリティパラメタの当初設定のために応答について議定書の中で述べます。 これは、かぎ管理が全体のセッションのために宣言されますが、非集められたファッション(すなわち、RTSPセッションあたり1つのメディア)で設立されるなら、各SETUP MUSTがセッションレベル文脈のための同じ応答を運ぶことを意味します。 また、RTSPセッションのときに2番目のセットアップかどんなその後のメディアも実行するとき、最初のメディアのために確立されるのと同じかぎ管理パラメタはこれらのセットアップに適用されます。
* Key management responses for the initial establishment of security
parameters for an individual media SHALL only be included in SETUP
for the corresponding media stream.
* 含まれているコネが対応するメディアストリームのためのSETUPであったなら個々のメディアSHALLだけのためのセキュリティパラメタの当初設定のために管理応答を合わせてください。
If a server receives a SETUP message in which it expects a key management message, but none is included, a "403 Forbidden" SHOULD be returned to the client, whereby the current setup MUST be aborted.
サーバがそれがかぎ管理メッセージを予想するSETUPメッセージを受け取りますが、なにも含まれていないなら、「禁じられた403」SHOULDをクライアントに返して、電流がどうしてセットアップされるか中止しなければなりません。
When the server creates an initial SDP message, the procedure SHALL be the same as described in Section 4.1.1.
サーバがセクション4.1で説明される同じくらいが.1であったなら初期のSDPメッセージ、手順SHALLを作成するとき。
Arkko, et al. Standards Track [Page 15] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[15ページ]RFC4567Key Management拡張子とRTSP2006年7月
The client processing of the initial SDP message from the server SHALL follow the same procedures as described in Section 4.1.1, except that, if there is an error, the session is aborted (no error is sent back).
誤りがあればそれを除いて、SHALLが同じ手順に従うサーバからの初期のSDPメッセージのクライアント処理がセクション4.1.1で説明されて、セッションは中止されます(誤りは全く返送されません)。
The client SHALL create the response, using the key management header in RTSP, as follows:
以下の通りRTSPでかぎ管理ヘッダーを使用して、クライアントSHALLは応答を作成します:
* The identifier of the key management protocol used (e.g., MIKEY)
MUST be placed in the "prot" field of the header. The prot values
are maintained by IANA (Section 9).
* 使用されるかぎ管理プロトコル(例えば、マイキー)に関する識別子をヘッダーの"prot"分野に置かなければなりません。 prot値はIANA(セクション9)によって維持されます。
* The keymgmt-data field MUST be created as follows: the key
management protocol MUST be used to create the key management
message. This message SHALL be base64 encoded by the RTSP
application and then encapsulated in the "data" field of the
header. The semantics of the encapsulated message is dependent on
the key management protocol that is used.
* 以下の通りでkeymgmt-データ・フィールドを作成しなければなりません: かぎ管理メッセージを作成するのにかぎ管理プロトコルを使用しなければなりません。 これは中でRTSPアプリケーションでコード化されて、次にカプセル化されたbase64がヘッダーの「データ」分野であったならSHALLを通信させます。 カプセル化されたメッセージの意味論は使用されたかぎ管理プロトコルに依存しています。
* Include, if necessary, the URL to indicate the context in the "uri"
parameter.
* 必要なら、URLを含めて、"uri"パラメタの文脈を示してください。
The server SHALL process a received key management header in RTSP as follows:
サーバSHALLは以下のRTSPで容認されたかぎ管理ヘッダーを処理します:
* The key management protocol is identified according to the "prot"
field.
* "prot"分野に従って、かぎ管理プロトコルは特定されます。
* The key management data from the "data" field MUST be extracted,
base64 decoded to reconstruct the original message, and then passed
to the key management protocol for processing.
* 「データ」分野からのかぎ管理データを抜粋しなければならなくて、base64は処理のためにかぎ管理プロトコルにオリジナルのメッセージを再建するために解読して、次に、通りました。
* If the key management protocol is successful, the processing can
proceed according to normal rules.
* かぎ管理プロトコルがうまくいくなら、正常な規則に従って、処理は続くことができます。
* Otherwise, if the key management fails (e.g., due to authentication
failure or parameter not supported), an error is sent back as the
SETUP response using RTSP error code 463 (see Section 3.2) and the
session is aborted. It is up to the key management protocol to
specify (within the RTSP status code message or through key
management messages) details about the type of error that occurred.
* さもなければ、かぎ管理が行き詰まるなら(例えば、失敗かパラメタがサポートしなかった認証のため)、誤りはSETUP応答としてRTSPエラーコード463を使用することで返送されます、そして、(セクション3.2を見てください)セッションは中止されます。 発生した誤りのタイプに関する詳細を指定するのは(RTSPステータスコードメッセージかかぎ管理メッセージを通して)かぎ管理プロトコルまで達しています。
Re-keying within RTSP is for further study, given that media updating mechanisms within RTSP are unspecified at the time this document was written.
さらなる研究にはRTSPの中の再の合わせることがあります、このドキュメントが書かれたときRTSPの中でメカニズムをアップデートするメディアが不特定であるなら。
Arkko, et al. Standards Track [Page 16] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[16ページ]RFC4567Key Management拡張子とRTSP2006年7月
5. Example Scenarios
5. 例のシナリオ
The following examples utilize MIKEY [MIKEY] as the key management protocol to be integrated into SDP and RTSP.
かぎ管理がSDPとRTSPと統合されるために議定書を作るとき、以下の例はマイキー[マイキー]を利用します。
5.1. Example 1 (SIP/SDP)
5.1. 例1(一口/SDP)
A SIP call is taking place between Alice and Bob. Alice sends an INVITE message consisting of the following offer:
SIP呼び出しはアリスとボブの間の場所を取っています。 アリスは以下から成るのが提供するINVITEメッセージを送ります:
v=0 o=alice 2891092738 2891092738 IN IP4 w-land.example.com s=Cool stuff e=alice@w-land.example.com t=0 0 c=IN IP4 w-land.example.com a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEEoo2pee4hp2 UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0JKpgaVkDaawi9whVBtBt 0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUOSrzKTAv9zV m=audio 49000 RTP/SAVP 98 a=rtpmap:98 AMR/8000 m=video 52230 RTP/SAVP 31 a=rtpmap:31 H261/90000
IN IP4 w-land.example.com alice@w-land.example.com t=0 0クールなv=0 o=alice2891092738 2891092738IN IP4 w-land.example.com s=ものe=c=aは主要な管理と等しいです: mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEEoo2pee4hp2 UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUOSrzKTAv9zV m=オーディオの49000RTP/SAVP98a=rtpmap: 98AMR/8000mはビデオ52230RTP/SAVP31a=rtpmap: 31H261/90000と等しいです。
That is, Alice proposes to set up one audio stream and one video stream that run over SRTP (signaled by the use of the SAVP profile). She uses MIKEY to set up the security parameters for SRTP (Section 7). The MIKEY message contains the security parameters, together with the necessary key material. Note that MIKEY is exchanging the crypto suite for both streams, as it is placed at the session level. Also, MIKEY provides its own security, i.e., when Bob processes Alice's MIKEY message, he will also find the signaling of the security parameters used to secure the MIKEY exchange. Alice's endpoint's authentication information is also carried within the MIKEY message, to prove that the message is authentic. The above MIKEY message is an example of message when the pre-shared method MIKEY is used.
すなわち、アリスは、SRTP(SAVPプロフィールの使用で、合図される)をひく1つのオーディオストリームと1つのビデオストリームをセットアップするよう提案します。 彼女は、SRTP(セクション7)のためのセキュリティパラメタをセットアップするのにマイキーを使用します。 マイキーメッセージは必要な主要な材料と共にセキュリティパラメタを含んでいます。 それがセッションレベルに置かれるとき、マイキーが暗号スイートを両方のストリームと交換していることに注意してください。 また、すなわち、ボブがアリスのマイキーメッセージを処理するとき、マイキーはそれ自身のセキュリティを前提とします、また、彼はセキュリティパラメタのシグナリングが以前はよくマイキー交換を保証していたのがわかるでしょう。 また、アリスの終点の認証情報は、メッセージが正統であると立証するためにマイキーメッセージの中で運ばれます。 上記のマイキーメッセージはあらかじめ共有されたメソッドであるときに、マイキーが使用されているというメッセージに関する例です。
Upon receiving the offer, Bob checks the validity of the received MIKEY message, and, in case of successful verification, he accepts the offer and sends an answer back to Alice (with his authentication information, and, if necessary, also some key material from his side):
申し出を受けると、ボブが受信されたマイキーメッセージの正当性をチェックして、うまくいっている検証の場合に、彼は、申し出を受け入れて、答えをアリスに送り返します(彼の認証情報、および彼の側からの必要なら何らかの主要な材料でも):
v=0 o=bob 2891092897 2891092897 IN IP4 foo.example.com s=Cool stuff e=bob@foo.example.com
クールなv=0o=ボブ2891092897 2891092897のIN IP4 foo.example.com s=ものeは bob@foo.example.com と等しいです。
Arkko, et al. Standards Track [Page 17] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[17ページ]RFC4567Key Management拡張子とRTSP2006年7月
t=0 0 c=IN IP4 foo.example.com a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6gAAAAAJAAAQbWlja2 V5QG1vdXNlLmNvbQABn8HdGE5BMDXFIuGEga+62AgY5cc= m=audio 49030 RTP/SAVP 98 a=rtpmap:98 AMR/8000 m=video 52230 RTP/SAVP 31 a=rtpmap:31 H261/90000
0 0c=IN t=IP4 foo.example.com aは主要な管理と等しいです: mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6gAAAAAJAAAQbWlja2 V5QG1vdXNlLmNvbQABn8HdGE5BMDXFIuGEga+62AgY5ccはm=オーディオの49030RTP/SAVP98a=rtpmapと等しいです: 98AMR/8000mはビデオ52230RTP/SAVP31a=rtpmap: 31H261/90000と等しいです。
Upon receiving the answer, Alice verifies the correctness of it. In case of success, at this point Alice and Bob share the security parameters and the keys needed for a secure RTP communication.
答えを受けると、アリスはそれの正当性について確かめます。 成功の場合には、ここに、アリスとボブは安全なRTPコミュニケーションに必要であるセキュリティパラメタとキーを共有します。
5.2. Example 2 (SDP)
5.2. 例2(SDP)
This example shows what Alice would have done if she wished to protect only the audio stream. She would have placed the MIKEY line at media level for the audio stream only (also specifying the use of the SRTP profile there, SAVP). The semantics of the MIKEY messages is as in the previous case, but applies only to the audio stream.
彼女がオーディオストリームだけを保護したかったなら、この例はアリスがしたことを示しています。 彼女はオーディオストリーム(また、そこでSRTPプロフィールの使用を指定するSAVP)だけのためにメディアレベルにマイキー系列をみなしたでしょう。 マイキーメッセージの意味論は、前がケースに入れるコネとしてありますが、オーディオストリームだけに適用されます。
v=0 o=alice 2891092738 2891092738 IN IP4 w-land.example.com s=Cool stuff e=alice@w-land.example.com t=0 0 c=IN IP4 w-land.example.com m=audio 49000 RTP/SAVP 98 a=rtpmap:98 AMR/8000 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... m=video 52230 RTP/AVP 31 a=rtpmap:31 H261/90000
v=0 o=alice2891092738 2891092738IN IP4 w-land.example.com s=は=オーディオの49000RTP/SAVP98a=rtpmapを0 0c=IN IP4 w-land.example.comものe= alice@w-land.example.com t=m冷やします: 98AMR/8000a=キー管理: mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy…mはビデオ52230RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
Bob would then act as described in the previous example, including the MIKEY answer at the media level for the audio stream (as Alice did).
次に、ボブは前の例で説明されるように行動するでしょう、オーディオストリームのためのメディアレベルでマイキー答えを含んでいて(アリスがそうしたように)。
Note that even if the key management attribute were specified at the session level, the video part would not be affected by this (as a security profile is not used, instead the RTP/AVP profile is signaled).
かぎ管理属性がセッションレベルで指定されたとしても、ビデオ部分がこれで影響を受けないことに注意してください(セキュリティプロフィールが使用されていないので、代わりに、RTP/AVPプロフィールは合図されます)。
5.3. Example 3 (RTSP)
5.3. 例3(RTSP)
A client wants to set up a streaming session and requests a media description from the streaming server.
クライアントはストリーミングサーバからストリーミングのセッションと要求にメディア記述を設定したがっています。
DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
DESCRIBE rtsp://server.example.com/シューシューという音/foo RTSP/1.0
Arkko, et al. Standards Track [Page 18] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[18ページ]RFC4567Key Management拡張子とRTSP2006年7月
CSeq: 312 Accept: application/sdp From: user@example.com
CSeq: 312 受け入れます: アプリケーション/sdp From: user@example.com
The server sends back an OK message including an SDP description, together with the MIKEY message. The MIKEY message contains the necessary security parameters that the server is willing to offer to the client, together with authentication information (to prove that the message is authentic) and the key material. The SAVP profile also signals the use of SRTP for securing the media sessions.
サーバはマイキーメッセージと共にSDP記述を含むOKメッセージを返送します。 マイキーメッセージはサーバが提供しても構わないとクライアントと思っている必要なセキュリティパラメタを含んでいます、認証情報(メッセージが正統であると立証する)と主要な材料と共に。 また、SAVPプロフィールはSRTPのメディアにセッションを保証する使用に合図します。
RTSP/1.0 200 OK CSeq: 312 Date: 23 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 478
RTSP/1.0 200はCSeqを承認します: 312 日付: 1997年1月23日のグリニッジ標準時15時35分6秒のコンテントタイプ: sdp Contentアプリケーション/長さ: 478
v=0 o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com s=Action Movie e=action@movie.example.com t=0 0 c=IN IP4 movie.example.com a=control:rtsp://movie.example.com/action a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... m=audio 0 RTP/SAVP 98 a=rtpmap:98 AMR/8000 a=control:rtsp://movie.example.com/action/audio m=video 0 RTP/SAVP 31 a=rtpmap:31 H261/90000 a=control:rtsp://movie.example.com/action/video
v=0 o=actionmovie2891092738 2891092738IN IP4 movie.example.com s=動作Movie e= action@movie.example.com tはビデオ0RTP/SAVP31a=rtpmap: =が制御する31H261/90000: =が制御する0 0c=IN IP4 movie.example.com: rtsp://movie.example.com/動作=キー管理: mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy…m=オーディオの0RTP/SAVP98a=rtpmap: =が制御する98AMR/8000: rtsp://movie.example.com/動作/オーディオm=rtsp://movie.example.com/動作/ビデオと等しいです。
The client checks the validity of the received MIKEY message, and, in case of successful verification, it accept the message. The client then includes its key management data in the SETUP request going back to the server, the client authentication information (to prove that the message is authentic), and, if necessary, some key material.
クライアントは受信されたマイキーメッセージの正当性をチェックします、そして、うまくいっている検証の場合に、それはメッセージを受け入れます。 そして、クライアントは、サーバ、クライアント認証情報(メッセージが正統であると立証する)、および必要なら何らかの主要な材料に戻りながら、SETUP要求でかぎ管理データを入れます。
SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action";
data="AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6g..."
SETUP rtsp://movie.example.com/動作/オーディオRTSP/1.0CSeq: 313 輸送: RTP/SAVP/UDP; ユニキャスト; クライアント_ポートは3056-3057 keymgmtと等しいです: prot=mikey。 uri=「rtsp://movie.example.com/動作」。 データは「AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6g.」と等しいです。
The server processes the request including checking the validity of the key management header.
サーバはかぎ管理ヘッダーの正当性をチェックするのを含む要求を処理します。
Arkko, et al. Standards Track [Page 19] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[19ページ]RFC4567Key Management拡張子とRTSP2006年7月
RTSP/1.0 200 OK
CSeq: 313
Session: 12345678
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001
RTSP/1.0 200はCSeqを承認します: 313セッション: 12345678 輸送: RTP/SAVP/UDP; ユニキャスト; クライアント_ポートは3056-3057と等しいです。 サーバ_ポートは5000-5001と等しいです。
Note that in this case the key management line was specified at the session level, and the key management information only goes into the SETUP related to the first stream. The "uri" indicates to the server that the context is for the whole aggregated session the key management applies. The RTSP client then proceeds setting up the second media (video) in aggregation with the audio. As the two media are run in aggregation and the key context was established in the first exchange, no more key management messages are needed.
この場合かぎ管理系列がセッションレベルで指定されたことに注意してください。そうすれば、かぎ管理情報は最初のストリームに関連するSETUPに入るだけです。 "uri"は、文脈がかぎ管理が当てはまる全体の集められたセッションの間あるのをサーバに示します。 オーディオで集合における2番目のメディア(ビデオ)を設立するRTSPのクライアントの当時の売り上げ。 2つのメディアがそうように集合に立候補して、主要な文脈は第一交換に確立されました、そして、それ以上のかぎ管理メッセージは全く必要ではありません。
5.4. Example 4 (RTSP)
5.4. 例4(RTSP)
The use of the MIKEY message at the media level would change the previous example as follows.
メディアレベルにおけるマイキーメッセージの使用は以下の前の例を変えるでしょう。
The 200 OK would contain the two distinct SDP attributes for MIKEY at the media level:
200OKはメディアレベルにマイキーのための2つの異なったSDP属性を含んでいるでしょう:
RTSP/1.0 200 OK CSeq: 312 Date: 23 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 561
RTSP/1.0 200はCSeqを承認します: 312 日付: 1997年1月23日のグリニッジ標準時15時35分6秒のコンテントタイプ: sdp Contentアプリケーション/長さ: 561
v=0 o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com s=Action Movie e=action@movie.example.com t=0 0 c=IN IP4 movie.example.com a=control:rtsp://movie.example.com/action m=audio 0 RTP/SAVP 98 a=rtpmap:98 AMR/8000 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAA... a=control:rtsp://movie.example.com/action/audio m=video 0 RTP/SAVP 31 a=rtpmap:31 H261/90000 a=key-mgmt:mikey AQAFgM0AdlABAAAAAAAAAAAAA... a=control:rtsp://movie.example.com/action/video
動作v=0 o=actionmovie2891092738 2891092738IN IP4 movie.example.com s=Movie e= action@movie.example.com tは=が制御する0 0c=IN IP4 movie.example.comと等しいです: rtsp://movie.example.com/動作m=オーディオの0RTP/SAVP98a=rtpmap: =キー管理: mikey AQAFgM0XflABAAAAAAAAAAAAA... a=が制御する98AMR/8000: rtsp://movie.example.com/動作/オーディオmはビデオ0RTP/SAVP31a=rtpmap: =キー管理: mikey AQAFgM0AdlABAAAAAAAAAAAAA... a=が制御する31H261/90000: rtsp://movie.example.com/動作/ビデオと等しいです。
Arkko, et al. Standards Track [Page 20] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[20ページ]RFC4567Key Management拡張子とRTSP2006年7月
Each RTSP header is inserted in the SETUP related to the audio and video separately:
それぞれのRTSPヘッダーは別々にオーディオとビデオに関連するSETUPに挿入されます:
SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio";
data="AQEFgM0XflABAAAAAAAAAAAAA..."
SETUP rtsp://movie.example.com/動作/オーディオRTSP/1.0CSeq: 313 輸送: RTP/SAVP/UDP; ユニキャスト; クライアント_ポートは3056-3057 keymgmtと等しいです: prot=mikey。 uriは「rtsp://movie.example.com/動作/オーディオ」と等しいです。 データは"AQEFgM0XflABAAAAAAAAAAAAA"と等しいです…
and similarly for the video session:
同様である、ビデオセッションのために:
SETUP rtsp://movie.example.com/action/video RTSP/1.0
CSeq: 315
Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video";
data="AQEFgM0AdlABAAAAAAAAAAAAAA..."
SETUP rtsp://movie.example.com/動作/ビデオRTSP/1.0CSeq: 315 輸送: RTP/SAVP/UDP; ユニキャスト; クライアント_ポートは3058-3059 keymgmtと等しいです: prot=mikey。 uri=「rtsp://movie.example.com/動作/ビデオ」。 データは"AQEFgM0AdlABAAAAAAAAAAAAAA"と等しいです…
Note: The "uri" parameter could be excluded from the two SETUP messages in this example.
以下に注意してください。 "uri"パラメタはこの例の2つのSETUPメッセージから除かれるかもしれません。
6. Adding Further Key Management Protocols
6. さらなるKey Managementプロトコルを加えます。
This framework cannot be used with all key management protocols. The key management protocol needs to comply with the requirements described in Section 4. In addition to this, the following needs to be defined:
すべてのかぎ管理プロトコルと共にこのフレームワークを使用できません。 かぎ管理プロトコルは、セクション4で説明される要件に応じる必要があります。 これに加えて、以下は、定義される必要があります:
* The key management protocol identifier to be used as the protocol
identifier should be registered at IANA according to Section 9.
* かぎ管理は、セクション9によると、プロトコル識別子がIANAに登録されるべきであるので使用されるために識別子について議定書の中で述べます。
* The information that the key management needs from SDP and RTSP,
and vice versa, as described in Section 4. The exact API is
implementation specific, but it MUST at least support the exchange
of the specified information.
* かぎ管理がセクション4で説明されるようにSDPとRTSPから逆もまた同様に必要とする情報。 正確なAPIは実装特有ですが、それは指定された情報の交換を少なくともサポートしなければなりません。
* The key management protocol to be added MUST be such that the
processing in Section 4 (describing its interactions with SDP and
RTSP) can be applied. Note in particular, Section 4.1.4 requires
each key management protocol to specify how the list of protocol
identifiers is authenticated inside that key management protocol.
The key management MUST always be given the protocol identifier(s)
of the key management protocol(s) included in the offer in the
correct order as they appear.
* 加えられるべきかぎ管理プロトコルはセクション4(SDPとRTSPとの相互作用について説明します)における処理を適用できるようにものであるに違いありません。 特定の注意、セクション4.1.4は、プロトコル識別子のリストがそのかぎ管理プロトコルでどう認証されるかを指定するためにそれぞれのかぎ管理プロトコルを必要とします。 彼らが現れるように正しいオーダーにおける申し出にかぎ管理プロトコルに関するプロトコル識別子を含んでいる場合、いつもかぎ管理を与えなければなりません。
Finally, it is obviously crucial to analyze possible security implications induced by the introduction of a new key management protocol in the described framework.
最終的に、説明されたフレームワークにおける、新しいかぎ管理プロトコルの導入で引き起こされた可能なセキュリティ含意を分析するのは明らかに重要です。
Arkko, et al. Standards Track [Page 21] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[21ページ]RFC4567Key Management拡張子とRTSP2006年7月
Today, the MIKEY protocol [MIKEY] has adopted the key management extensions to work together with SIP and RTSP (see Section 7). Other protocols MAY use the described attribute and header, e.g., Kerberos [KERB]; however, this is subject to future standardization.
今日、マイキープロトコル[マイキー]は、SIPとRTSPと共に働くためにかぎ管理拡大を採用しました(セクション7を見てください)。 他のプロトコルは説明された属性とヘッダー、例えばケルベロス[KERB]を使用するかもしれません。 しかしながら、これは今後の標準化を受けることがあります。
7. Integration of MIKEY
7. マイキーの統合
[MIKEY] describes a key management protocol for real-time applications (both for peer-to-peer communication and group communication). MIKEY carries the security parameters needed for setting up the security protocol (e.g., SRTP) protecting the media stream. MIKEY can be integrated within SDP and RTSP, following the rules and guidelines described in this document.
[マイキー]はリアルタイムのアプリケーション(ピアツーピアコミュニケーションとグループコミュニケーションのための)のためにかぎ管理プロトコルについて説明します。 マイキーはメディアストリームを保護しながらセキュリティプロトコル(例えば、SRTP)をセットアップするのに必要であるセキュリティパラメタを運びます。 本書では説明された規則とガイドラインに従って、SDPとRTSPの中でマイキーを統合できます。
MIKEY satisfies the requirements described in Section 4. The MIKEY message is formed as defined in [MIKEY], then passed from MIKEY to the SDP application that base64 encodes it, and encapsulates it in the keymgmt-data attribute. The examples in Section 5 use MIKEY, where the semantics of the exchange is also briefly explained.
マイキーはセクション4で説明された要件を満たします。 マイキーメッセージは[マイキー]で定義されるように形成されて、keymgmt-データ属性はその時、マイキーからbase64がそれをコード化して、それをカプセル化するSDPアプリケーションまで終わりました。 また、交換の意味論が簡潔に説明されるところでセクション5の例はマイキーを使用します。
The key management protocol identifier (KMPID) to be used as the protocol identifier SHALL be "mikey" and is registered at IANA; see Section 9 for details.
かぎ管理はプロトコル識別子SHALLが"mikey"であり、IANAに登録されるので使用されるために識別子(KMPID)について議定書の中で述べます。 詳細に関してセクション9を見てください。
The information that the key management needs from SDP and RTSP, and vice versa, follows Section 4. To avoid bidding-down attacks, the directives in Section 4.1.4 are followed. The list of protocol identifiers is authenticated within MIKEY by placing the list in a General Extension Payload (of type "SDP IDs", [MIKEY]), which then automatically will be integrity protected/signed. The receiver SHALL then match the list in the General Extension Payload with the list included in SDP and SHOULD (according to policy) if they differ, or if integrity/signature verification fails, reject the offer.
かぎ管理がSDPとRTSPから逆もまた同様に必要とする情報はセクション4に続きます。 下に入札攻撃を避けるために、セクション4.1.4における指示は続かれています。 次に、どれが自動的に保全であるかはプロトコル識別子のリストがマイキーの中で一般Extension有効搭載量(タイプ「SDP ID」の[マイキー])にリストを置くことによって、認証されて、保護したか、または署名しました。 次に、彼らが異なるか、または保全/署名照合が失敗するなら、受信機SHALLは一般Extension有効搭載量でSDPとSHOULD(方針によると)に含まれているリストにリストを合わせて、廃棄物は提供です。
The server will need to be able to know the identity of the client before creating and sending a MIKEY message. To signal the (MIKEY) identity of the client to the server in the DESCRIBE, it is RECOMMENDED to include the From header field in RTSP. Other methods to establish the identity could be using the IP address or retrieving the identity from the RTSP authentication if used.
サーバは、マイキーメッセージを作成して、送る前にクライアントのアイデンティティを知ることができる必要があるでしょう。 クライアントの(マイキー)のアイデンティティにDESCRIBEのサーバに合図するなら、それはRTSPにFromヘッダーフィールドを含むRECOMMENDEDです。 使用されるなら、アイデンティティを確立する他のメソッドは、IPアドレスを使用するか、またはRTSP認証からアイデンティティを検索することであるかもしれません。
7.1. MIKEY Interface
7.1. マイキーインタフェース
This subsection describes some aspects, which implementers SHOULD consider. If the MIKEY implementation is separate from the SDP/SIP/RTSP, an application programming interface (API) between MIKEY and those protocols is needed with certain functionality (however, exactly what it looks like is implementation dependent).
この小区分はいくつかの局面について説明します。(implementers SHOULDは局面を考えます)。 マイキー実装がSDP/SIP/RTSPから別々であるなら、マイキーとそれらのプロトコルとのアプリケーションプログラミングインターフェース(API)が、ある機能性で必要です(しかしながら、それがまさに何に似ているかは、実装に依存しています)。
Arkko, et al. Standards Track [Page 22] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[22ページ]RFC4567Key Management拡張子とRTSP2006年7月
The following aspects need to be considered:
以下の局面は、考えられる必要があります:
* the possibility for MIKEY to receive information about the sessions
negotiated. This is to some extent implementation dependent. But
it is RECOMMENDED that, in the case of SRTP streams, the number of
SRTP streams is included (and the direction of these). It is also
RECOMMENDED to provide the destination addresses and ports to
MIKEY. When referring to streams described in SDP, MIKEY SHALL
allocate two consecutive numbers for the related Crypto Session
indexes (as each stream can be bi-directional). An example: if the
SDP contains two m lines (specifying whatever direction of the
streams), and MIKEY is at the session level, then MIKEY allocates,
e.g., the Crypto Sessions Identifiers (CS IDs; see [MIKEY]) '1' and
'2' for the first m line, and '3' and '4' for the second m line.
* マイキーが交渉されたおよそセッション情報を受け取る可能性。 これは実装にある程度依存しています。 しかし、SRTPストリームの数がSRTPストリームの場合で含まれているのは(そして、これらの方向)、RECOMMENDEDです。 また、それは送付先アドレスとポートをマイキーに提供するRECOMMENDEDです。 SDPで説明されたストリームについて言及するとき、MIKEY SHALLは関連するCrypto Sessionインデックスの2つの一連番号を割り当てます(それぞれのストリームが双方向であることができるときに)。 例: SDPが2mの系列を含んでいて(ストリームのどんな方向も指定して)、マイキーがセッションレベルにいるなら、2番目のmでマイキーが割り当てるその時、例えば、最初のm系列のためのCryptoセッションズIdentifiers'1'と'2'(CS ID; [マイキー]を見てください)、'3'、および'4'は立ち並んでいます。
* the possibility for MIKEY to receive incoming MIKEY messages and
return a status code from/to the SIP/RTSP application.
* マイキーが/からSIP/RTSPアプリケーションまで入って来るマイキーメッセージを受け取って、ステータスコードを返す可能性。
* the possibility for the SIP or RTSP applications to receive
information from MIKEY. This would typically include the receiving
of the Crypto Session Bundle Identifier (CSB ID; see [MIKEY], to
later be able to identify the active MIKEY session), and the SSRCs
and the rollover counter (ROC; see [SRTP]) for SRTP usage. It is
also RECOMMENDED that extra information about errors can be
received.
* SIPかRTSPアプリケーションがマイキーから情報を受け取る可能性。 これはSRTP用法のためのCrypto Session Bundle Identifierの受信(CSB ID; 見て[マイキー]、後で活発なマイキーセッションを特定できる)、SSRCs、およびロールオーバーカウンタ(ROC; [SRTP]を見る)を通常含んでいるでしょう。 また、誤りに関するその他の情報を受け取ることができるのは、RECOMMENDEDです。
* the possibility for the SIP or RTSP application to receive outgoing
MIKEY messages.
* SIPかRTSPアプリケーションが送信するマイキーメッセージを受け取る可能性。
* the possibility to tear down a MIKEY CSB (e.g., if the SIP session
is closed, the CSB SHOULD also be closed).
* MIKEY CSBを取りこわす可能性、(例えば、終えられたSIPセッション、CSB SHOULDも閉じている、)
8. Security Considerations
8. セキュリティ問題
The framework for transfer of key management data as described here is intended to provide the security parameters for the end-to-end protection of the media session. It is furthermore good practice to secure the session setup (e.g., SDP, SIP, RTSP, SAP). However, it might be that the security of the session setup is not possible to achieve end-to-end, but only hop-by-hop. For example, SIP requires intermediate proxies to have access to part of the SIP message, and sometimes also to the SDP description (cf. [E2M]), although end-to- end confidentiality can hide bodies from intermediaries. General security considerations for the session setup can be found in SDP [SDPnew], SIP [SIP], and RTSP [RTSP]. The framework defined in this memo is useful when the session setup is not protected in an end-to-
ここで説明されるとしてのかぎ管理データの転送のためのフレームワークが終わりから終わりへのメディアセッションの保護のためのセキュリティパラメタを提供することを意図します。 その上、利益がセッションがセットアップ(例えば、SDP、SIP、RTSP、SAP)であると機密保護するために練習されるということです。 しかしながら、セッションセットアップのセキュリティが終わらせる終わりを達成するのにおいて可能であるのではなく、ホップであるだけであることごとのことであるかもしれません。 例えば、SIPは、中間的プロキシがSIPメッセージの一部と、そして、時々SDP記述にもアクセスを持っているのを必要とします。(Cf。 [200万ユーロ]), 終わりから終わりへの秘密性は仲介者からボディーを隠すことができますが。 SDP[SDPnew]、SIP[SIP]、およびRTSP[RTSP]でセッションセットアップのための総合証券問題を見つけることができます。 セッションセットアップが終わりに保護されないとき、このメモで定義されたフレームワークが役に立つ、-、-
Arkko, et al. Standards Track [Page 23] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[23ページ]RFC4567Key Management拡張子とRTSP2006年7月
end fashion, but the media streams need to be end-to-end protected; hence the security parameters (such as keys) are not wanted revealed to or manipulated by intermediaries.
ファッション、しかし、ストリームが保護された終わりから終わりである必要があるメディアを終わらせてください。 したがって、仲介者によって明らかにされるか操られた状態で、セキュリティパラメタ(キーなどの)は欲しくはありません。
The security will also depend on the level of security the key management protocol offers. It follows that, under the assumption that the key management schemes are secure, the SDP can be passed along unencrypted without affecting the key management as such, and the media streams will still be secure even if some attackers gained knowledge of the SDP contents. Further security considerations can be found for each key management protocol (for MIKEY these can be found in [MIKEY]). However, if the SDP messages are not sent integrity protected between the parties, it is possible for an active attacker to change attributes without being detected. As the key management protocol may (indirectly) rely on some of the session information from SDP (e.g., address information), an attack on SDP may have indirect consequences on the key management. Even if the key management protocol does not rely on parameters of SDP and will not be affected by manipulation of these, different denial-of-service (DoS) attacks aimed at SDP may lead to undesired interruption in the setup. See also the attacks described at the end of this section.
また、セキュリティはかぎ管理プロトコルが提供するセキュリティのレベルに依存するでしょう。 かぎ管理体系が安全であるという仮定でSDPを回すことができるのがそういうもののかぎ管理に影響しないで非暗号化されて、何人かの攻撃者がSDPコンテンツに関する知識を獲得したとしてもメディアストリームがまだ安全になっているということになります。 それぞれのかぎ管理プロトコルに関してさらなるセキュリティ問題を見つけることができます(マイキーに関して、[マイキー]でこれらを見つけることができます)。 しかしながら、パーティーの間に保護された保全がSDPメッセージに送られないなら、活発な攻撃者が検出されないで属性を変えるのは、可能です。 かぎ管理プロトコルが(間接的に)SDP(例えば、アドレス情報)からの何らかのセッション情報を当てにするとき、SDPに対する攻撃は間接的な結果をかぎ管理に持っているかもしれません。 かぎ管理プロトコルがSDPのパラメタを当てにしなく、またこれらの操作で影響を受けないでも、SDPを対象にした異なったサービスの否定(DoS)攻撃はセットアップにおける望まれない中断につながるかもしれません。 また、このセクションの端で説明された攻撃を見てください。
The only integrity-protected attribute of the media stream is, in the framework proposed here, the set of key management protocols. For instance, it is possible to (1) swap key management offers across SDP messages, or (2) inject a previous key management offer into a new SDP message. Making the (necessary) assumption that all involved key management protocols are secure, the second attack will be detected by replay protection mechanisms of the key management protocol(s). Making the further assumption that, according to normal best current practice, the production of each key management offer is done with independent (pseudo)random choices (for session keys and other parameters), the first attack will either be detected in the Responder's (now incorrect) verification reply message (if such is used) or be a pure DoS attack, resulting in Initiator and Responder using different keys.
ここで提案されたフレームワークでは、メディアストリームの唯一の保全で保護された属性がかぎ管理プロトコルのセットです。 例えば、(1) スワッピングかぎ管理申し出に、メッセージ、または(2)が新しいSDPメッセージに前のかぎ管理申し出を注ぐのは、SDPの向こう側に可能です。 すべてのかかわったかぎ管理プロトコルが安全であるという(必要)の仮定をして、2番目の攻撃はかぎ管理プロトコルの反復操作による保護メカニズムによって検出されるでしょう。 正常な最も良い現在の習慣に従って独立している(疑似な)無作為の選択(セッションキーと他のパラメタのための)でそれぞれのかぎ管理申し出の生産をするというさらなる仮定をして、最初の攻撃は、Responderの(現在、不正確)の検証応答メッセージ(そのようなものが使用されているなら)に検出されるか、純粋なDoS攻撃になるでしょう、異なったキーを使用することでInitiatorとResponderをもたらして。
It is RECOMMENDED for the identity at the SPD level to be the one authenticated at the key management protocol level. However, this might need to keep into consideration privacy aspects, which are out of scope for this framework.
それはSPDレベルにおけるアイデンティティがかぎ管理プロトコルレベルで認証されたものであるRECOMMENDEDです。 しかしながら、これは、プライバシーが局面であることを考慮に保つ必要があるかもしれません。(このフレームワークのための範囲の外に局面があります)。
The use of multiple key management protocols in the same offer may open up the possibility of a bidding-down attack, as specified in Section 4.1.4. To exclude such possibility, the authentication of the protocol identifier list is used. Note though, that the security level of the authenticated protocol identifier will be as high (or
同じ申し出における複数のかぎ管理プロトコルの使用は下に入札攻撃の可能性を開けるかもしれません、セクション4.1.4で指定されるように。 そのような可能性を除くために、プロトコル名前の並びの認証は使用されています。 またはもっとも、認証のセキュリティー・レベルが識別子について議定書の中で述べるのが、同じくらい高いことに注意してください、(。
Arkko, et al. Standards Track [Page 24] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[24ページ]RFC4567Key Management拡張子とRTSP2006年7月
low), as the "weakest" protocol. Therefore, the offer MUST NOT contain any security protocols (or configurations thereof) weaker than permitted by local security policy.
安値)、「最も弱い」プロトコルとして。 したがって、申し出はローカルの安全保障政策で受入れられるより弱いどんなセキュリティプロトコル(または、それの構成)も含んではいけません。
Note that it is impossible to ensure the authenticity of a declined offer, since even if it comes from the true respondent, the fact that the answerer declines the offer usually means that he does not support the protocol(s) offered, and consequently cannot be expected to authenticate the response either. This means that if the Initiator is unsure of which protocol(s) the Responder supports, we RECOMMEND that the Initiator offers all acceptable protocols in a single offer. If not, this opens up the possibility for a "man-in- the-middle" (MITM) to affect the outcome of the eventually agreed upon protocol, by faking unauthenticated error messages until the Initiator eventually offers a protocol "to the liking" of the MITM. This is not really a security problem, but rather a mild form of denial of service that can be avoided by following the above recommendation. Note also that the declined offer could be the result of an attacker who sits on the path and removes all the key management offers. The bidding-down attack prevention, as described above, would not work in this case (as the answerer receives no key management attribute). Also, here it is impossible to ensure the authenticity of a declined offer, though here the reason is the "peeling-off" attack. It is up to the local policy to decide the behavior in the case that the response declines any security (therefore, there is impossibility of authenticating it). For example, if the local policy requires a secure communication and cannot accept an unsecured one, then the session setup SHALL be aborted.
傾けられた申し出の信憑性を確実にするのが不可能であることに注意してください、本当の応答者から来ても、answererが申し出をお断りするという事実は通常、彼が(s)が提供したプロトコルをサポートしないことを意味して、応答を認証することをその結果期待できないで。 ResponderがどのプロトコルをサポートするかにInitiatorは不確かであるなら、これがそれを意味して、私たちはInitiatorがただ一つの申し出におけるすべての許容できるプロトコルを提供するRECOMMENDです。 そうでなければ、これがaのために可能性を開ける、「中の男性、-、-、中央、Initiatorが結局MITMの「好み」をプロトコルに提供するまで、」 結局プロトコルで見せかけることによって同意されていることの結果に影響する(MITM)はエラーメッセージを非認証しました。 これは本当に警備上の問題ではなく、むしろ上の推薦に続くことによって避けることができる軽症型のサービスの否定です。 また、傾けられた申し出が経路に座っていて、すべてのかぎ管理申し出を取り除く攻撃者の結果であるかもしれないことに注意してください。 上で説明される下に入札攻撃防止はこの場合働いていないでしょう(answererがかぎ管理属性を全く受けないとき)。 また、ここで、傾けられた申し出の信憑性を確実にするのも不可能です、理由はここでの「下に皮」の攻撃ですが。 応答がどんなセキュリティも低下させて(したがって、それを認証する不可能があります)、振舞いについて決めるのはローカルの方針まで達しています。 例えば、ローカルの方針が安全なコミュニケーションを必要として、非機密保護しているものを受け入れることができないなら、セッションはSHALLをセットアップします。中止されます。
9. IANA Considerations
9. IANA問題
9.1. SDP Attribute Registration
9.1. SDP属性登録
The IANA has created a new subregistry for the purpose of key management protocol integration with SDP.
IANAはSDPとのかぎ管理プロトコル統合の目的のために新しい副登録を作成しました。
SDP Attribute Field ("att-field"):
SDPは分野(「att-分野」)を結果と考えます:
Name: key-mgmt-att-field
Long form: key management protocol attribute field
Type of name: att-field
Type of attribute: Media and session level
Purpose: See RFC 4567, Section 3.
Reference: RFC 4567, Section 3.1
Values: See RFC 4567, Sections 3.1 and 9.3.
以下を命名してください。 主要な管理att分野Longは形成します: かぎ管理は名前の属性分野Typeについて議定書の中で述べます: 属性のatt-分野Type: メディアとセッションレベルPurpose: RFC4567、セクション3を見てください。 参照: セクション3.1 RFC4567、値: RFC4567、セクション3.1と9.3を見てください。
Arkko, et al. Standards Track [Page 25] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[25ページ]RFC4567Key Management拡張子とRTSP2006年7月
9.2. RTSP Registration
9.2. RTSP登録
The IANA has created a new subregistry for the purpose of key management protocol integration with RTSP.
IANAはRTSPとのかぎ管理プロトコル統合の目的のために新しい副登録を作成しました。
Following the guidelines of [RTSP], the registration is defined as follows:
[RTSP]のガイドラインに従って、登録は以下の通り定義されます:
Header name: keymgmt
Header syntax: see RFC 4567, Section 3.2
Intended usage: see RFC 4567, Section 3.2
Proxy treatment: Proxies SHALL NOT add, change, or delete the
header. The proxy does not need to read this
header.
Purpose: see RFC 4567, Section 3
ヘッダー名: keymgmt Header構文: セクション3.2 RFC4567、Intended用法を見てください: セクション3.2 RFC4567、Proxy処理を見てください: プロキシSHALL NOTはヘッダーを加えるか、変えるか、または削除します。 プロキシはこのヘッダーを読む必要はありません。 目的: RFC4567、セクション3を見てください。
The RTSP Status-Code "463" (RFC 4567), with the default string "Key management failure", needs to be registered.
デフォルトがあるRTSP Status-コード「463」(RFC4567)は「かぎ管理失敗」、登録されるべき必要性を結びます。
9.3. Protocol Identifier Registration
9.3. プロトコル識別子登録
This document defines one new name space, the "SDP/RTSP key management protocol identifier", associated with the protocol identifier, KMPID, defined in Section 3 to be used with the above registered attributes in SDP and RTSP.
このドキュメントはスペース(プロトコル識別子に関連づけられた「SDP/RTSPかぎ管理プロトコル識別子」KMPID)がSDPとRTSPの上の登録された属性と共に使用されるためにセクション3で定義した1つの新しい名前を定義します。
The IANA has created a new subregistry for the KMPID parameter, with the following registration created initially: "mikey".
以下の登録が初めは作成されている状態で、IANAはKMPIDパラメタのために新しい副登録を作成しました: "mikey"。
Value name: mikey
Long name: Multimedia Internet KEYing
Purpose: Usage of MIKEY with the key-mgmt-att-field
attribute and the keymgmt RTSP header
Reference: Section 7 in RFC 3830
名前を評価してください: mikey Longは以下を命名します。 目的を合わせるマルチメディアインターネット: 主要な管理attフィールド属性とkeymgmt RTSPヘッダーReferenceをもっているマイキーの使用法: セクション7 RFC3830で
Note that this registration implies that the protocol identifier, KMPID, name space will be shared between SDP and RTSP.
この登録が、プロトコル識別子、KMPIDがスペースを命名するのを含意するというメモはSDPとRTSPの間で共有されるでしょう。
Further values may be registered according to the "Specification Required" policy as defined in [RFC2434]. Each new registration needs to indicate the parameter name, and register it with IANA. Note that the parameter name is case sensitive, and it is RECOMMENDED that the name be in lowercase letters. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter and the requested details of interaction between the key management protocol and SDP, as specified in RFC 4567.
「仕様が必要である」という方針に従って、さらなる値は[RFC2434]で定義されるように示されるかもしれません。 各新規登録は、パラメタ名を示して、IANAにそれを登録する必要があります。 パラメタ名が大文字と小文字を区別していて、名前が小文字にあるのが、RECOMMENDEDであることに注意してください。 各新規登録に、登録されたパラメタの意味論とかぎ管理プロトコルとSDPとの相互作用の要求された詳細を指定する永久的で、安定して、公的にアクセス可能なドキュメントが存在するのは、義務的です、RFC4567で指定されるように。
Arkko, et al. Standards Track [Page 26] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[26ページ]RFC4567Key Management拡張子とRTSP2006年7月
New values MUST be registered with IANA. Registrations SHALL include the following information:
新しい値をIANAに示さなければなりません。 登録証明書SHALLは以下の情報を含んでいます:
* Contact: the contact name and email address
* Value name: the name of the value being registered (which MUST
comply with the KMPID as defined in Section 3)
* Long Name: long-form name in English
* Purpose: short explanation of the purpose of the registered name.
* Reference: a reference to the specification (e.g., RFC number)
providing the usage guidelines in accordance to Section 6 (and also
complying to the specified requirements).
* 接触: 連絡名とEメールアドレス*値の名: 登録されて、(セクション3で定義されるようにKMPIDに従わなければなりません) *がNameを切望するということである価値の名前: 長い間、イギリスの*目的における名前を形成してください: 登録名の目的の短い説明。 * 参照: セクション6(また、規定要求事項に応じて)との一致に用法ガイドラインを提供する仕様(例えば、RFC番号)の参照。
10. Acknowledgements
10. 承認
The authors would like to thank Francois Audet, Rolf Blom, Johan Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries, Joerg Ott, Jon Peterson, and Jon-Olov Vatn. A special thanks to Colin Perkins and Magnus Westerlund, who contributed in many sections.
作者はフランソアAudet、ロルフ・ブロム、ジョハンBilien、マグヌス・ブローリン、エリック・エリアソン、マーチンEuchner、ステファン・フリーズ、ヨルク・オット、ジョン・ピーターソン、およびジョン-Olov Vatnに感謝したがっています。 コリン・パーキンスとマグヌスWesterlundのおかげで特別番組。Westerlundは多くのセクションで貢献しました。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[マイキー]Arkko、J.、カラーラ、E.、リンドホルム、F.、ジーター、M.、およびK.Norrman、「マイキー:」 「マルチメディアインターネットの合わせる」RFC3830、2004年8月。
[OAM] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[OAM] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3548]Josefsson、2003年7月のS.、「Base16、Base32、およびBase64データEncodings」RFC3548。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC3986] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
エド[RFC4234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
Arkko, et al. Standards Track [Page 27] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[27ページ]RFC4567Key Management拡張子とRTSP2006年7月
[RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[RTSP]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[SDPnew] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[SDPnew] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[一口] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
11.2. Informative References
11.2. 有益な参照
[E2M] Ono, K. and S. Tachimoto, "Requirements for End-to-Middle
Security for the Session Initiation Protocol (SIP)", RFC
4189, October 2005.
[2EのM] 小野とK.とS.Tachimoto、「セッション開始プロトコル(一口)のための終わりから中央へのセキュリティのための要件」、RFC4189、2005年10月。
[KERB] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[縁石] ヌーマン、C.、ユー、T.、ハートマン、S.、およびK.レイバーン、「ケルベロスネットワーク認証サービス(V5)」、RFC4120 2005年7月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[SDES] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
Andreasen、F.、Baugher、M.、およびD.が翼をつけさせる[SDES]、「メディアストリームのためのセッション記述プロトコル(SDP)セキュリティ記述」、RFC4568(2006年7月)。
[SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security
Preconditions for Session Description Protocol Media
Streams", Work in Progress, October 2005.
[SPREC]Andreasen(「セキュリティはセッション記述プロトコルメディアストリームのためにあらかじめ調整する」F.、Baugher、M.、および翼、D.)は進行中(2005年10月)で働いています。
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[SRTP] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
Arkko, et al. Standards Track [Page 28] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[28ページ]RFC4567Key Management拡張子とRTSP2006年7月
Authors' Addresses
作者のアドレス
Jari Arkko Ericsson 02420 Jorvas Finland
ヤリArkkoエリクソン02420Jorvasフィンランド
Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com
以下に電話をしてください。 +358 40 5079256はメールされます: jari.arkko@ericsson.com
Elisabetta Carrara Royal Institute of Technology Stockholm Sweden
Elisabettaカラーラの王立の工科大学ストックホルムスウェーデン
EMail: carrara@kth.se
メール: carrara@kth.se
Fredrik Lindholm Ericsson SE-16480 Stockholm Sweden
フレドリック・リンドホルム・エリクソンSE-16480ストックホルムスウェーデン
Phone: +46 8 58531705 EMail: fredrik.lindholm@ericsson.com
以下に電話をしてください。 +46 8 58531705 メール: fredrik.lindholm@ericsson.com
Mats Naslund Ericsson Research SE-16480 Stockholm Sweden
Matsジーター・エリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 58533739 EMail: mats.naslund@ericsson.com
以下に電話をしてください。 +46 8 58533739 メール: mats.naslund@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
カール・Norrmanエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 4044502 EMail: karl.norrman@ericsson.com
以下に電話をしてください。 +46 8 4044502 メール: karl.norrman@ericsson.com
Arkko, et al. Standards Track [Page 29] RFC 4567 Key Management Extensions for SDP and RTSP July 2006
Arkko、他 SDPのための標準化過程[29ページ]RFC4567Key Management拡張子とRTSP2006年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Arkko, et al. Standards Track [Page 30]
Arkko、他 標準化過程[30ページ]
一覧
スポンサーリンク
