RFC5027 日本語訳
5027 Security Preconditions for Session Description Protocol (SDP)Media Streams. F. Andreasen, D. Wing. October 2007. (Format: TXT=37229 bytes) (Updates RFC3312) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Andreasen Request for Comments: 5027 D. Wing Updates: 3312 Cisco Systems Category: Standards Track October 2007
Andreasenがコメントのために要求するワーキンググループF.をネットワークでつないでください: 5027のD.翼のアップデート: 3312年のシスコシステムズカテゴリ: 標準化過程2007年10月
Security Preconditions for
Session Description Protocol (SDP) Media Streams
セキュリティはセッション記述プロトコル(SDP)メディアストリームのためにあらかじめ調整されます。
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully.
このドキュメントはRFCs3312と4032年に説明されたSession記述プロトコル(SDP)前提条件フレームワークのために新しいセキュリティ前提条件を定義します。 セッション設立を遅らせるのにセキュリティ前提条件を使用できますか、またはメディアが安全なメディアストリームのためのセキュリティを流すまで、変更は首尾よく交渉されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Notational Conventions ..........................................2
3. Security Precondition Definition ................................2
4. Examples ........................................................6
4.1. SDP Security Descriptions Example ..........................6
4.2. Key Management Extension for SDP Example ...................9
5. Security Considerations ........................................11
6. IANA Considerations ............................................13
7. Acknowledgements ...............................................13
8. Normative References ...........................................13
9. Informative References .........................................14
1. 序論…2 2. 記号法のコンベンション…2 3. セキュリティは定義をあらかじめ調整します…2 4. 例…6 4.1. SDPセキュリティ記述の例…6 4.2. SDPの例のためのKey Management拡大…9 5. セキュリティ問題…11 6. IANA問題…13 7. 承認…13 8. 標準の参照…13 9. 有益な参照…14
Andreasen & Wing Standards Track [Page 1] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[1ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
1. Introduction
1. 序論
The concept of a Session Description Protocol (SDP) [RFC4566] precondition is defined in [RFC3312] as updated by [RFC4032]. A precondition is a condition that has to be satisfied for a given media stream in order for session establishment or modification to proceed. When a (mandatory) precondition is not met, session progress is delayed until the precondition is satisfied or the session establishment fails. For example, RFC 3312 defines the Quality-of-Service precondition, which is used to ensure availability of network resources prior to establishing (i.e., alerting) a call.
Session記述プロトコル(SDP)[RFC4566]前提条件の概念は[RFC4032]によってアップデートされる[RFC3312]で定義されます。 前提条件はセッション設立か変更が続いて、与えられたメディアストリームのために満たされなければならない状態です。 (義務的)の前提条件が満たされないとき、前提条件が満たされているか、またはセッション設立が行き詰まるまで、セッション進歩は遅れます。 例えば、RFC3312はサービスのQuality前提条件を定義します。(それは、呼び出しを確立する(すなわち、警告している)前にネットワーク資源の有用性を確実にするのに使用されます)。
Media streams can either be provided in cleartext and with no integrity protection, or some kind of media security can be applied, e.g., confidentiality and/or message integrity. For example, the Audio/Video profile of the Real-Time Transfer Protocol (RTP) [RFC3551] is normally used without any security services whereas the Secure Real-time Transport Protocol (SRTP) [SRTP] is always used with security services. When media stream security is being negotiated, e.g., using the mechanism defined in SDP Security Descriptions [SDESC], both the offerer and the answerer [RFC3264] need to know the cryptographic parameters being used for the media stream; the offerer may provide multiple choices for the cryptographic parameters, or the cryptographic parameters selected by the answerer may differ from those of the offerer (e.g., the key used in one direction versus the other). In such cases, to avoid media clipping, the offerer needs to receive the answer prior to receiving any media packets from the answerer. This can be achieved by using a security precondition, which ensures the successful negotiation of media stream security parameters for a secure media stream prior to session establishment or modification.
メディアストリームは、cleartextと保全がなければ、保護、またはある種のメディアセキュリティを適用できるか、そして、例えば、秘密性、そして/または、メッセージの保全であるかもしれません。 例えば、レアル-時間Transferプロトコル(RTP)[RFC3551]のAudio/ビデオプロフィールは少しもセキュリティー・サービスなしで通常使用されますが、Secureレアル-時間Transportプロトコル(SRTP)[SRTP]はセキュリティー・サービスと共にいつも使用されます。 メディアが流れるとき、セキュリティは交渉されています、例えば、SDP Security記述[SDESC]で定義されたメカニズムを使用して、申出人とanswererの両方[RFC3264]がメディアストリームに使用されることで暗号のパラメタを知る必要があります。 申出人が暗号のパラメタに選択式を提供するかもしれませんか、またはanswererによって選択された暗号のパラメタは申出人(例えば一方向対もう片方に使用されるキー)のものと異なるかもしれません。 そのような場合、メディア切り取りを避けるために、申出人は、answererからどんなメディア向けの資料セットも受ける前に答えを受ける必要があります。 セキュリティ前提条件を使用することによって、これを達成できます。(前提条件は安全なメディアのためのストリームセキュリティパラメタがセッション設立か変更の前に流すメディアのうまくいっている交渉を確実にします)。
2. Notational Conventions
2. 記号法のコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Security Precondition Definition
3. セキュリティ前提条件定義
The semantics for a security precondition are that the relevant cryptographic parameters (cipher, key, etc.) for a secure media stream are known to have been negotiated in the direction(s) required. If the security precondition is used with a non-secure media stream, the security precondition is by definition satisfied. A secure media stream is here defined as a media stream that uses some kind of security service (e.g., message integrity,
セキュリティ前提条件のための意味論は安全なメディアストリームのための関連暗号のパラメタ(暗号、キーなど)によって(s)が必要とした方向と交渉されたのが知られているということです。 セキュリティ前提条件が非安全なメディアストリームと共に使用されるなら、セキュリティ前提条件は定義上満たされています。 ある種のセキュリティー・サービスを使用するメディアストリームと定義されて、安全なメディアストリームがここにある、(例えば、メッセージの保全
Andreasen & Wing Standards Track [Page 2] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[2ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
confidentiality, or both), regardless of the cryptographic strength of the mechanisms being used.
秘密性、または両方、)、メカニズムの暗号の強さにかかわらず、使用されます。
As an extreme example of this, Secure RTP (SRTP) using the NULL
encryption algorithm and no message integrity would be considered
a secure media stream whereas use of plain RTP would not. Note
though, that Section 9.5 of [SRTP] discourages the use of SRTP
without message integrity.
NULL暗号化アルゴリズムを使用するSecure RTP(SRTP)にもかかわらず、この、メッセージの保全がない極端な例が考えられるだろうというとき、明瞭なRTPの安全なメディアストリームにもかかわらず、使用はそうしないでしょう。 もっとも、[SRTP]のそのセクション9.5がメッセージの保全なしでSRTPの使用に水をさしていることに注意してください。
Security preconditions do not guarantee that an established media stream will be secure. They merely guarantee that the recipient of the media stream packets will be able to perform any relevant decryption and integrity checking on those media stream packets. Please refer to Section 5 for further security considerations.
セキュリティ前提条件は、確立したメディアストリームが安全になるのを保証しません。 彼らは、メディアの受取人がそれらのメディアにおけるどんな関連復号化も実行できて、保全照合がストリームパケットであるつもりであったならパケットを流すのを単に保証します。 さらなるセキュリティ問題についてセクション5を参照してください。
The security precondition type is defined by the string "sec" and hence we modify the grammar found in RFC 3312 as follows:
セキュリティ前提条件タイプはストリング「秒」までに定義されます、そして、したがって、私たちは以下のRFC3312で見つけられた文法を変更します:
precondition-type = "sec" / "qos" / token
前提条件タイプ=「秒」/"qos"/トークン
RFC 3312 defines support for two kinds of status types, namely segmented and end-to-end. The security precondition-type defined here MUST be used with the end-to-end status type; use of the segmented status type is undefined.
RFC3312はすなわち、区分された状態タイプと終わらせる終わりの2種類のサポートを定義します。 終わりから完了状態へのタイプでここで定義されたセキュリティ前提条件タイプを使用しなければなりません。 区分された状態タイプの使用は未定義です。
A security precondition can use the strength-tag "mandatory", "optional", or "none".
セキュリティ前提条件は強さタグ「義務的で」、「任意」か、または「なにも」を使用できます。
When a security precondition with a strength-tag of "mandatory" is received in an offer, session establishment or modification MUST be delayed until the security precondition has been met, i.e., the relevant cryptographic parameters (cipher, key, etc.) for a secure media stream are known to have been negotiated in the direction(s) required. When a mandatory security precondition is offered, and the answerer cannot satisfy the security precondition (e.g., because the offer was for a secure media stream, but it did not include the necessary parameters to establish the secure media stream keying material for example), the offered media stream MUST be rejected as described in RFC 3312.
申し出で「義務的」の強さタグがあるセキュリティ前提条件を受け取るとき、セキュリティ前提条件が満たされるまで、セッション設立か変更を遅らせなければなりません、すなわち、(s)が必要とした方向と交渉されたのを安全なメディアストリームのための関連暗号のパラメタ(暗号、キーなど)を知っています。 answererが義務的なセキュリティ前提条件を提供して、セキュリティ前提条件を満たすことができないなら(例えば申し出がしかし、安全なメディアが流れるからであるそれは例えば材料を合わせる安全なメディアストリームを証明するために必要なパラメタを含んでいませんでした)、RFC3312で説明されていると提供されたメディアストリームを拒絶しなければなりません。
The delay of session establishment defined here implies that alerting of the called party MUST NOT occur and media for which security is being negotiated MUST NOT be exchanged until the precondition has been satisfied. In cases where secure media and other non-media data is multiplexed on a media stream (e.g., when Interactive Connectivity Establishment [ICE] is being used), the non-media data is allowed to be exchanged prior to the security precondition being satisfied.
ここで定義されたセッション設立の遅れは、被呼者の警告が起こってはいけないのを含意します、そして、前提条件が満たされるまで、セキュリティが交渉されているメディアを交換してはいけません。 安全なメディアと他の非メディアデータがメディアストリームで多重送信される(例えば、Interactive Connectivity特権階級[ICE]はいつ使用されていますか)場合では、非メディアデータは満たされているセキュリティ前提条件の前に交換できます。
Andreasen & Wing Standards Track [Page 3] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[3ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
When a security precondition with a strength-tag of "optional" is received in an offer, the answerer MUST generate its answer SDP as soon as possible. Since session progress is not delayed in this case, the answerer does not know when the offerer is able to process secure media stream packets and hence clipping may occur. If the answerer wants to avoid clipping and delay session progress until he knows the offerer has received the answer, the answerer MUST increase the strength of the security precondition by using a strength-tag of "mandatory" in the answer. Note that use of a mandatory precondition in an offer requires the presence of a SIP "Require" header field containing the option tag "precondition": Any SIP UA that does not support a mandatory precondition will consequently reject such requests (which also has unintended ramifications for SIP forking that are known as the Heterogeneous Error Response Forking Problem (see e.g., [HERFP]). To get around this, an optional security precondition and the SIP "Supported" header field containing the option tag "precondition" can be used instead.
できるだけ早く申し出で「任意」の強さタグがあるセキュリティ前提条件を受け取るとき、answererは、答えがSDPであると生成しなければなりません。 セッション進歩がこの場合遅れないので、answererは、申出人が安全なメディアを処理できるとき、ストリームパケットとしたがって、切り取るのが現れるかもしれないのを知りません。 answererが、切り取るのを避けたがっていて、彼が申出人を知るまで遅れセッション進歩が答えを受けたなら、answererは、答えで「義務的」の強さタグを使用することによって、セキュリティ前提条件の強さを増強しなければなりません。 申し出における義務的な前提条件の使用がオプションタグ「前提条件」を含む「必要SIP」ヘッダーフィールドを存在に要求することに注意してください: その結果、義務的な前提条件をサポートしないどんなSIP UAもそのような要求を拒絶するでしょう。また、どれに、SIP分岐のためのHeterogeneous Error Response Forking Problemとして知られている故意でない分岐がありますか?(例えば、[HERFP]を見てください)(これを迂回するために、代わりにオプションタグ「前提条件」を含むヘッダーフィールドであると「サポートされた」任意のセキュリティ前提条件とSIPは使用できます。
When a security precondition with a strength-tag of "none" is received, processing continues as usual. The "none" strength-tag merely indicates that the offerer supports the following security precondition - the answerer MAY upgrade the strength-tag in the answer as described in [RFC3312].
「なにも」の強さタグがあるセキュリティ前提条件が受け取られているとき、処理はいつものように続きます。 「なにも」強さタグは、申出人が以下のセキュリティ前提条件をサポートするのを単に示します--answererは[RFC3312]で説明されるように答えで強さタグをアップグレードさせるかもしれません。
The direction tags defined in RFC 3312 are interpreted as follows:
RFC3312で定義された方向タグは以下の通り解釈されます:
* send: Media stream security negotiation is at a stage where it is
possible to send media packets to the other party and the other
party will be able to process them correctly from a security point
of view, i.e., decrypt and/or integrity check them as necessary.
The definition of "media packets" includes all packets that make
up the media stream. In the case of Secure RTP for example, it
includes SRTP as well as SRTCP. When media and non-media packets
are multiplexed on a given media stream (e.g., when ICE is being
used), the requirement applies to the media packets only.
* 発信します: そして/または、メディアストリームセキュリティ交渉がすなわち、もう片方へのメディア向けの資料セットにパーティーを送って、パーティーをもう片方に送るのがセキュリティ観点からそれらを正しく処理できるのが、可能であるところに段階である、解読する、保全は必要に応じてそれらをチェックします。 「メディア向けの資料セット」の定義はメディアストリームを作るすべてのパケットを含んでいます。 例えば、Secure RTPの場合では、それはSRTCPと同様にSRTPを含んでいます。 与えられたメディアストリームでメディアと非メディア向けの資料セットを多重送信するとき(例えば、ICEはいつ使用されていますか)、要件はメディア向けの資料セットだけに適用されます。
* recv: Media stream security negotiation is at a stage where it is
possible to receive and correctly process media stream packets
sent by the other party from a security point of view.
* recv: メディアストリームセキュリティ交渉が受信して、セキュリティ観点からストリームパケットが相手で送ったメディアを正しく処理するのが可能であるところに段階であります。
The precise criteria for determining when the other party is able to correctly process media stream packets from a security point of view depend on the secure media stream protocol being used as well as the mechanism by which the required cryptographic parameters are negotiated.
必要な暗号のパラメタが交渉されるメカニズムと同様に使用されることで相手が正しくメディアを処理できるとき、セキュリティ観点からのストリームパケットが安全なメディアストリームによることを決定する正確な評価基準は議定書を作ります。
Andreasen & Wing Standards Track [Page 4] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[4ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
We here provide details for SRTP negotiated through SDP security descriptions as defined in [SDESC]:
私たち、ここで、[SDESC]で定義されるようにSDPセキュリティ記述で交渉されたSRTPのための詳細は提供されます:
* When the offerer requests the "send" security precondition, it
needs to receive the answer before the security precondition is
satisfied. The reason for this is twofold. First, the offerer
needs to know where to send the media. Secondly, in the case
where alternative cryptographic parameters are offered, the
offerer needs to know which set was selected. The answerer does
not know when the answer is actually received by the offerer
(which in turn will satisfy the precondition), and hence the
answerer needs to use the confirm-status attribute [RFC3312].
This will make the offerer generate a new offer showing the
updated status of the precondition.
* 申出人がセキュリティがあらかじめ調整する「発信してください」を要求するとき、それは、セキュリティ前提条件が満たされる前に答えを受ける必要があります。 この理由は二つです。 まず最初に、申出人は、メディアをどこに送るかを知る必要があります。 第二に、代替の暗号のパラメタが提供される場合では、申出人は、どれがセットしたかが選択されたのを知る必要があります。 answererは、答えがいつ実際に申出人(順番に前提条件を満たす)によって受けられるかを知りません、そして、したがって、answererは状態を確認している属性[RFC3312]を使用する必要があります。 これで、申出人は、新しい申し出表示が前提条件のアップデートされた状態であると生成するでしょう。
* When the offerer requests the "recv" security precondition, it
also needs to receive the answer before the security precondition
is satisfied. The reason for this is straightforward: The answer
contains the cryptographic parameters that will be used by the
answerer for sending media to the offerer; prior to receipt of
these cryptographic parameters, the offerer is unable to
authenticate or decrypt such media.
* また、申出人が、"recv"セキュリティがあらかじめ調整されるよう要求するとき、それは、セキュリティ前提条件が満たされる前に答えを受ける必要があります。 この理由は簡単です: 答えは送付メディアにanswererによって申出人に使用される暗号のパラメタを含んでいます。 これらの暗号のパラメタの領収書の前では、申出人は、そのようなメディアを認証するか、または解読することができません。
When security preconditions are used with the Key Management Extensions for the Session Description Protocol (SDP) [KMGMT], the details depend on the actual key management protocol being used.
セキュリティ前提条件がSession記述プロトコル(SDP)[KMGMT]にKey Management Extensionsと共に使用されるとき、詳細は使用される実際のキー管理プロトコルによります。
After an initial offer/answer exchange in which the security precondition is requested, any subsequent offer/answer sequence for the purpose of updating the status of the precondition for a secure media stream SHOULD use the same key material as the initial offer/answer exchange. This means that the key-mgmt attribute lines [KMGMT], or crypto attribute lines [SDESC] in SDP offers, that are sent in response to SDP answers containing a confirm-status field [RFC3312] SHOULD repeat the same data as that sent in the previous SDP offer. If applicable to the key management protocol or SDP security description, the SDP answers to these SDP offers SHOULD repeat the same data in the key-mgmt attribute lines [KMGMT] or crypto attribute lines [SDESC] as that sent in the previous SDP answer.
初期の申し出/答えの後に、セキュリティがあらかじめ調整される交換は要求されて、SHOULDが使用する安全なメディアストリームのための前提条件の状態をアップデートする目的のためのどんなその後の申し出/答え系列も初期の申し出/答え交換と同じ主要な材料です。 これは、主要な管理属性が前のSDPのそんなに送られるのと同じデータが提供する状態を確認している分野[RFC3312]SHOULD反復を含むSDP答えに対応して送られる[KMGMT]、またはSDP申し出における暗号属性系列[SDESC]を裏打ちすることを意味します。 かぎ管理プロトコルかSDPセキュリティ記述に適切であるなら、SDPはそれとしての主要な管理属性における同じデータが裏打ちするSHOULD反復[KMGMT]か暗号属性系列[SDESC]が前のSDP答えで送ったこれらのSDP申し出に一致します。
Of course, this duplication of key exchange during precondition establishment is not to be interpreted as a replay attack. This issue may be solved if, e.g., the SDP implementation recognizes that the key management protocol data is identical in the second offer/answer exchange and avoids forwarding the information to the security layer for further processing.
もちろん、前提条件設立の間の主要な交換のこの複製は反射攻撃として解釈されないことです。 例えば、SDP実装が、かぎ管理プロトコルデータは2番目の申し出/答え交換が同じであると認めて、セキュリティ層に情報を転送するのを避けるなら、この問題はさらなる処理のために解決されるかもしれません。
Andreasen & Wing Standards Track [Page 5] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[5ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
Offers with security preconditions in re-INVITEs or UPDATEs follow the rules given in Section 6 of RFC 3312, i.e.:
セキュリティ前提条件が再INVITEsかUPDATEsにある申し出はRFC3312のセクション6ですなわち、与えられた規則に従います:
"Both user agents SHOULD continue using the old session parameters
until all the mandatory preconditions are met. At that moment,
the user agents can begin using the new session parameters."
「ユーザエージェントSHOULDは、すべての義務的な前提条件が満たされるまでともに、古いセッションパラメタを使用し続けています。」 「その瞬間に、ユーザエージェントは、新しいセッションパラメタを使用し始めることができます。」
At that moment, we furthermore require that user agents MUST start using the new session parameters for media packets being sent. The user agents SHOULD be prepared to process media packets received with either the old or the new session parameters for a short period of time to accommodate media packets in transit. Note that this may involve iterative security processing of the received media packets during that period of time. Section 8 in [RFC3264] lists several techniques to help alleviate the problem of determining when a received media packet was generated according to the old or new offer/answer exchange.
その瞬間に、その上、私たちは、ユーザエージェントが、送られるメディア向けの資料セットに新しいセッションパラメタを使用するのを出発しなければならないのを必要とします。 ユーザエージェントSHOULD、トランジットでメディア向けの資料セットを収容するために短期間の間、古いパラメタか新しいセッションパラメタで受け取られたメディア向けの資料セットを処理するように用意してください。 これがその期間の間容認されたメディア向けの資料セットの繰り返しのセキュリティ処理にかかわるかもしれないことに注意してください。 [RFC3264]のセクション8は、古いか新しい申し出/答え交換に従って容認されたメディア向けの資料セットがいつ生成されたかを決定するという問題を軽減するのを助けるためにいくつかのテクニックを記載します。
4. Examples
4. 例
4.1. SDP Security Descriptions Example
4.1. SDPセキュリティ記述の例
The call flow of Figure 1 shows a basic session establishment using the Session Initiation Protocol [SIP] and SDP security descriptions [SDESC] with security descriptions for the secure media stream (SRTP in this case).
図1の呼び出し流動は、安全なメディアストリーム(この場合、SRTP)に、セキュリティ記述によるSession Initiationプロトコル[SIP]とSDPセキュリティ記述[SDESC]を使用することで基本的なセッション設立を見せています。
A B
B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|----------------(3) PRACK SDP3------------->|
| |
|<-----------(4) 200 OK (PRACK) SDP4---------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
| | |-------------(1) SDP1を招待してください。--------------->|、|、| | <、-、-、-、-、--(2) 183 セッション進歩SDP2--------| | | |----------------(3) PRACK SDP3------------->|、|、| | <、-、-、-、-、-、-、-、-、-、--(4) 200 OK(PRACK)SDP4---------| | | | <、-、-、-、-、-、-、-、-、-、-、-、--(5) 180 鳴ること---------------| | | | | | |
Figure 1: Security Preconditions with SDP Security
Descriptions Example
図1: セキュリティはSDPセキュリティ記述の例であらかじめ調整されます。
Andreasen & Wing Standards Track [Page 6] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[6ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
The SDP descriptions of this example are shown below - we have omitted the details of the SDP security descriptions as well as any SIP details for clarity of the security precondition described here:
この例のSDP記述は以下に示されます--私たちはここで説明されたセキュリティ前提条件の明快のためのどんなSIPの詳細と同様にSDPセキュリティ記述の詳細を省略しました:
SDP1: A includes a mandatory end-to-end security precondition for both the send and receive direction in the initial offer as well as a "crypto" attribute (see [SDESC]), which includes keying material that can be used by A to generate media packets. Since B does not know any of the security parameters yet, the current status (see RFC 3312) is set to "none". A's local status table (see RFC 3312) for the security precondition is as follows:
SDP1: Aが両方のための終わりから終わりへのセキュリティ義務的な前提条件を含んでいる、「暗号」属性([SDESC]を見る)と同様に初期の申し出の方向を送って、受けてください。属性はAによって使用される、メディア向けの資料セットを生成することができる材料を合わせるのを含んでいます。 Bがまだセキュリティパラメタのいずれも知っていないので、現在の状態(RFC3312を見る)は「なにも」に設定されます。 セキュリティ前提条件のためのAの地方の状態テーブル(RFC3312を見る)は以下の通りです:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
方向| 電流| 必要な強さ| 確認します。-----------+----------+------------------+---------- 発信してください。| いいえ| 義務的| recvがありません。| いいえ| 義務的| いいえ
and the resulting offer SDP is:
そして、結果として起こる申し出SDPは以下の通りです。
m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1
a=curr:sec e2e none
a=des:sec mandatory e2e sendrecv
a=crypto:foo...
mがオーディオの20000RTP/SAVPと等しい、0、c、=IN IP4 192.0.2.1a=curr: a=desのいずれも:でない秒の義務的なe2e sendrecv aが暗号と等しい秒のe2e: foo…
SDP2: When B receives the offer and generates an answer, B knows the (send and recv) security parameters of both A and B. From a security perspective, B is now able to receive media from A, so B's "recv" security precondition is "yes". However, A does not know any of B's SDP information, so B's "send" security precondition is "no". B's local status table therefore looks as follows:
SDP2: Bが申し出を受けて、答えを生成すると、Bは、AとB.From aセキュリティ見解の両方の(送って、recvします)セキュリティパラメタ、Bが現在Aからメディアを受け取ることができるのでビーズ"recv"セキュリティ前提条件が「はい」であると知っています。 しかしながら、Aは、したがって、ビーズSDP情報では、ビーズが「発信する」というどんなセキュリティ前提条件も「いいえ」であると知りません。 したがって、ビーズの地方の状態テーブルは以下の通りに見えます:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
方向| 電流| 必要な強さ| 確認します。-----------+----------+------------------+---------- 発信してください。| いいえ| 義務的| recvがありません。| はい| 義務的| いいえ
B requests A to confirm when A knows the security parameters used in the send and receive direction (it would suffice for B to ask for confirmation of A's send direction only) and hence the resulting answer SDP becomes:
Bが、Aがいつパラメタが使用したセキュリティを知るか確認するようAに要求する、方向を送って、受けてください。そうすれば(それはAの確認が方向だけを送るのでBが尋ねるために十分でしょう)、したがって、結果として起こる答えSDPはなります:
m=audio 30000 RTP/SAVP 0
c=IN IP4 192.0.2.4
a=curr:sec e2e recv
a=des:sec mandatory e2e sendrecv
a=conf:sec e2e sendrecv
a=crypto:bar...
mがオーディオの30000RTP/SAVPと等しい、0、c、=IN IP4 192.0.2.4a=curr: 秒のe2e recv a=des: 秒の義務的なe2e sendrecv a=conf: 秒のe2e sendrecv aは暗号と等しいです: バー
Andreasen & Wing Standards Track [Page 7] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[7ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
SDP3: When A receives the answer, A updates its local status table based on the rules in RFC 3312. A knows the security parameters of both the send and receive direction and hence A's local status table is updated as follows:
SDP3: Aが答えを受けるとき、AはRFC3312の規則に基づく地方の状態テーブルをアップデートします。 Aが両方のセキュリティパラメタを知っている、方向を送って、受けてください。そうすれば、したがって、以下の通りAの地方の状態テーブルをアップデートします:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | yes
recv | yes | mandatory | yes
方向| 電流| 必要な強さ| 確認します。-----------+----------+------------------+---------- 発信してください。| はい| 義務的| はいrecv| はい| 義務的| はい
Since B requested confirmation of the send and recv security preconditions, and both are now satisfied, A immediately sends an updated offer (3) to B showing that the security preconditions are satisfied:
以来、Bが確認を要求した、recvセキュリティはあらかじめ調整されます、そして、発信して、両方が現在満足しています、そして、Aはすぐに、セキュリティ前提条件が満たされているのを示すBにアップデートされた申し出(3)を送ります:
m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1
a=curr:sec e2e sendrecv
a=des:sec mandatory e2e sendrecv
a=crypto:foo...
mがオーディオの20000RTP/SAVPと等しい、0、c、=IN IP4 192.0.2.1a=curr: 秒のe2e sendrecv a=des: 秒の義務的なe2e sendrecv aは暗号と等しいです: foo
Note that we here use PRACK [RFC3262] instead of UPDATE [RFC3311] since the precondition is satisfied immediately, and the original offer/answer exchange is complete.
それに注意してください、私たち、ここ、前提条件がすぐに、満たされていて、オリジナルの申し出/答え交換が完全であるので、UPDATE[RFC3311]の代わりにPRACK[RFC3262]を使用してください。
SDP4: Upon receiving the updated offer, B updates its local status table based on the rules in RFC 3312, which yields the following:
SDP4: アップデートされた申し出を受けると、Bは以下をもたらすRFC3312の規則に基づく地方の状態テーブルをアップデートします:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
方向| 電流| 必要な強さ| 確認します。-----------+----------+------------------+---------- 発信してください。| はい| 義務的| recvがありません。| はい| 義務的| いいえ
B responds with an answer (4) that contains the current status of the security precondition (i.e., sendrecv) from B's point of view:
Bはビーズ観点からのセキュリティ前提条件(すなわち、sendrecv)の現在の状態を含む答え(4)で応じます:
m=audio 30000 RTP/SAVP 0
c=IN IP4 192.0.2.4
a=curr:sec e2e sendrecv
a=des:sec mandatory e2e sendrecv
a=crypto:bar...
mがオーディオの30000RTP/SAVPと等しい、0、c、=IN IP4 192.0.2.4a=curr: 秒のe2e sendrecv a=des: 秒の義務的なe2e sendrecv aは暗号と等しいです: バー
B's local status table indicates that all mandatory preconditions have been satisfied, and hence session establishment resumes; B returns a 180 (Ringing) response (5) to indicate alerting.
ビーズの地方の状態テーブルは、すべての義務的な前提条件を満たしてあるのを示します、そして、したがって、セッション設立は再開します。 Bは、警告を示すために180(鳴る)応答(5)を返します。
Andreasen & Wing Standards Track [Page 8] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[8ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
4.2. Key Management Extension for SDP Example
4.2. SDPの例のためのKey Management拡大
The call flow of Figure 2 shows a basic session establishment using the Session Initiation Protocol [SIP] and Key Management Extensions for SDP [KMGMT] with security descriptions for the secure media stream (SRTP in this case):
図2の呼び出し流動はSDP[KMGMT]に安全なメディアストリーム(この場合、SRTP)のためのセキュリティ記述でSession Initiationプロトコル[SIP]とKey Management Extensionsを使用することで基本的なセッション設立を見せています:
A B
B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|----------------(3) PRACK SDP3------------->|
| |
|<-----------(4) 200 OK (PRACK) SDP4---------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
| | |-------------(1) SDP1を招待してください。--------------->|、|、| | <、-、-、-、-、--(2) 183 セッション進歩SDP2--------| | | |----------------(3) PRACK SDP3------------->|、|、| | <、-、-、-、-、-、-、-、-、-、--(4) 200 OK(PRACK)SDP4---------| | | | <、-、-、-、-、-、-、-、-、-、-、-、--(5) 180 鳴ること---------------| | | | | | |
Figure 2: Security Preconditions with Key Management
Extensions for SDP Example
図2: セキュリティはSDPの例のためのKey Management拡大であらかじめ調整されます。
The SDP descriptions of this example are shown below - we show an example use of MIKEY [MIKEY] with the Key Management Extensions, however we have omitted the details of the MIKEY parameters as well as any SIP details for clarity of the security precondition described here:
この例のSDP記述は以下に示されます--しかしながら、私たちはKey Management Extensionsとのマイキー[マイキー]の例の使用を示していて、ここで説明されたセキュリティ前提条件の明快のためのどんなSIPの詳細と同様にマイキーパラメタの詳細を省略しました:
SDP1: A includes a mandatory end-to-end security precondition for both the send and receive direction in the initial offer as well as a "key-mgmt" attribute (see [KMGMT]), which includes keying material that can be used by A to generate media packets. Since B does not know any of the security parameters yet, the current status (see RFC 3312) is set to "none". A's local status table (see RFC 3312) for the security precondition is as follows:
SDP1: Aが両方のための終わりから終わりへのセキュリティ義務的な前提条件を含んでいる、「主要な管理」属性([KMGMT]を見る)と同様に初期の申し出の方向を送って、受けてください。属性はAによって使用される、メディア向けの資料セットを生成することができる材料を合わせるのを含んでいます。 Bがまだセキュリティパラメタのいずれも知っていないので、現在の状態(RFC3312を見る)は「なにも」に設定されます。 セキュリティ前提条件のためのAの地方の状態テーブル(RFC3312を見る)は以下の通りです:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
方向| 電流| 必要な強さ| 確認します。-----------+----------+------------------+---------- 発信してください。| いいえ| 義務的| recvがありません。| いいえ| 義務的| いいえ
Andreasen & Wing Standards Track [Page 9] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[9ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
and the resulting offer SDP is:
そして、結果として起こる申し出SDPは以下の通りです。
m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1
a=curr:sec e2e none
a=des:sec mandatory e2e sendrecv
a=key-mgmt:mikey AQAFgM0X...
mがオーディオの20000RTP/SAVPと等しい、0、c、=IN IP4 192.0.2.1a=curr: a=desのいずれも:でない秒の義務的なe2e sendrecv aが主要な管理と等しい秒のe2e: mikey AQAFgM0X.。
SDP2: When B receives the offer and generates an answer, B knows the (send and recv) security parameters of both A and B. B generates keying material for sending media to A, however, A does not know B's keying material, so the current status of B's "send" security precondition is "no". B does know A's SDP information, so B's "recv" security precondition is "yes". B's local status table therefore looks as follows:
SDP2: Bが申し出を受けて、答えを生成すると、Bは送付メディアのために材料をAに合わせながら、AとBが生成するB.の両方の(送って、recvします)セキュリティパラメタを知っていて、しかしながら、Aは、ビーズが材料を合わせて、したがって、「発信してください」というビーズセキュリティ前提条件の現在の状態が「いいえ」であると知りません。 Bは、AのSDP情報であり、したがって、ビーズ"recv"セキュリティ前提条件が「はい」であると知っています。 したがって、ビーズの地方の状態テーブルは以下の通りに見えます:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
方向| 電流| 必要な強さ| 確認します。-----------+----------+------------------+---------- 発信してください。| いいえ| 義務的| recvがありません。| はい| 義務的| いいえ
B requests A to confirm when A knows the security parameters used in the send and receive direction and hence the resulting answer SDP becomes:
Bが、Aがいつパラメタが使用したセキュリティを知るか確認するようAに要求する、方向を送って、受けてください。そうすれば、したがって、結果として起こる答えSDPはなります:
m=audio 30000 RTP/SAVP 0
c=IN IP4 192.0.2.4
a=curr:sec e2e recv
a=des:sec mandatory e2e sendrecv
a=conf:sec e2e sendrecv
a=key-mgmt:mikey AQAFgM0X...
mがオーディオの30000RTP/SAVPと等しい、0、c、=IN IP4 192.0.2.4a=curr: 秒のe2e recv a=des: 秒の義務的なe2e sendrecv a=conf: 秒のe2e sendrecv aは主要な管理と等しいです: mikey AQAFgM0X.。
Note that the actual MIKEY data in the answer differs from that in the offer; however, we have only shown the initial and common part of the MIKEY value in the above.
答えにおける実際のマイキーデータが申し出においてそれと異なっていることに注意してください。 しかしながら、私たちは上記でマイキー価値の初期的、そして、一般的な一部分を見せるだけでした。
SDP3: When A receives the answer, A updates its local status table based on the rules in RFC 3312. A now knows all the security parameters of both the send and receive direction and hence A's local status table is updated as follows:
SDP3: Aが答えを受けるとき、AはRFC3312の規則に基づく地方の状態テーブルをアップデートします。 Aが今両方のすべてのセキュリティパラメタを知っている、方向を送って、受けてください。そうすれば、したがって、以下の通りAの地方の状態テーブルをアップデートします:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | yes
recv | yes | mandatory | yes
方向| 電流| 必要な強さ| 確認します。-----------+----------+------------------+---------- 発信してください。| はい| 義務的| はいrecv| はい| 義務的| はい
Andreasen & Wing Standards Track [Page 10] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[10ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
Since B requested confirmation of the send and recv security preconditions, and both are now satisfied, A immediately sends an updated offer (3) to B showing that the security preconditions are satisfied:
以来、Bが確認を要求した、recvセキュリティはあらかじめ調整されます、そして、発信して、両方が現在満足しています、そして、Aはすぐに、セキュリティ前提条件が満たされているのを示すBにアップデートされた申し出(3)を送ります:
m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1
a=curr:sec e2e sendrecv
a=des:sec mandatory e2e sendrecv
a=key-mgmt:mikey AQAFgM0X...
mがオーディオの20000RTP/SAVPと等しい、0、c、=IN IP4 192.0.2.1a=curr: 秒のe2e sendrecv a=des: 秒の義務的なe2e sendrecv aは主要な管理と等しいです: mikey AQAFgM0X.。
SDP4: Upon receiving the updated offer, B updates its local status table based on the rules in RFC 3312, which yields the following:
SDP4: アップデートされた申し出を受けると、Bは以下をもたらすRFC3312の規則に基づく地方の状態テーブルをアップデートします:
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
方向| 電流| 必要な強さ| 確認します。-----------+----------+------------------+---------- 発信してください。| はい| 義務的| recvがありません。| はい| 義務的| いいえ
B responds with an answer (4) that contains the current status of the security precondition (i.e., sendrecv) from B's point of view:
Bはビーズ観点からのセキュリティ前提条件(すなわち、sendrecv)の現在の状態を含む答え(4)で応じます:
m=audio 30000 RTP/SAVP 0
c=IN IP4 192.0.2.4
a=curr:sec e2e sendrecv
a=des:sec mandatory e2e sendrecv
a=key-mgmt:mikey AQAFgM0X...
mがオーディオの30000RTP/SAVPと等しい、0、c、=IN IP4 192.0.2.4a=curr: 秒のe2e sendrecv a=des: 秒の義務的なe2e sendrecv aは主要な管理と等しいです: mikey AQAFgM0X.。
B's local status table indicates that all mandatory preconditions have been satisfied, and hence session establishment resumes; B returns a 180 (Ringing) response (5) to indicate alerting.
ビーズの地方の状態テーブルは、すべての義務的な前提条件を満たしてあるのを示します、そして、したがって、セッション設立は再開します。 Bは、警告を示すために180(鳴る)応答(5)を返します。
5. Security Considerations
5. セキュリティ問題
In addition to the general security considerations for preconditions provided in RFC 3312, the following security issues should be considered.
RFC3312に提供された前提条件のための総合証券問題に加えて、以下の安全保障問題は考えられるべきです。
Security preconditions delay session establishment until cryptographic parameters required to send and/or receive media for a media stream have been negotiated. Negotiation of such parameters can fail for a variety of reasons, including policy preventing use of certain cryptographic algorithms, keys, and other security parameters. If an attacker can remove security preconditions or downgrade the strength-tag from an offer/answer exchange, the attacker can thereby cause user alerting for a session that may have no functioning media. This is likely to cause inconvenience to both the offerer and the answerer. Similarly, security preconditions can
メディアストリームのためにメディアを送る、そして/または、受け取るのに必要である暗号のパラメタが交渉されるまで、セキュリティは遅れセッション設立をあらかじめ調整します。 そのようなパラメタの交渉はさまざまな理由で失敗できます、ある暗号アルゴリズム、キー、および他のセキュリティパラメタの使用を防ぐ方針を含んでいて。 その結果、攻撃者がセキュリティ前提条件を取り除くか、または申し出/答え交換から強さタグを格下げできるなら、攻撃者はセッションのためにそれを警告するといるかもしれないユーザに機能しているメディアを全く引き起こさない場合があります。 これは申出人とanswererの両方に不便を引き起こしそうです。 同様に、セキュリティ前提条件はそうすることができます。
Andreasen & Wing Standards Track [Page 11] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[11ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
be used to prevent clipping due to race conditions between an offer/answer exchange and secure media stream packets based on that offer/answer exchange. If an attacker can remove or downgrade the strength-tag of security preconditions from an offer/answer exchange, the attacker can cause clipping to occur in the associated secure media stream.
使用されて、パケットがその申し出/答え交換に基礎づけた申し出/答え交換と安全なメディアストリームの間の競合条件のため切り取るのを防いでください。 攻撃者が申し出/答え交換からセキュリティ前提条件の強さタグを取り除くか、または格下げできるなら、攻撃者は関連安全なメディアストリームで切り取りを現れさせることができます。
Conversely, an attacker might add security preconditions to offers that do not contain them or increase their strength-tag. This in turn may lead to session failure (e.g., if the answerer does not support it), heterogeneous error response forking problems, or a delay in session establishment that was not desired.
逆に、攻撃者は、セキュリティがそれらを含まない申し出にあらかじめ調整されると言い足すか、またはそれらの強さタグを増強するかもしれません。 これは順番にセッション失敗(例えば、answererがそれをサポートしないなら)、問題を分岐させる異種の誤り応答、または望まれていなかったセッション設立の遅れに通じるかもしれません。
Use of signaling integrity mechanisms can prevent all of the above problems. Where intermediaries on the signaling path (e.g., SIP proxies) are trusted, it is sufficient to use only hop-by-hop integrity protection of signaling, e.g., IPSec or TLS. In all other cases, end-to-end integrity protection of signaling (e.g., S/MIME) MUST be used. Note that the end-to-end integrity protection MUST cover not only the message body, which contains the security preconditions, but also the SIP "Supported" and "Require" headers, which may contain the "precondition" option tag. If only the message body were integrity protected, removal of the "precondition" option tag could lead to clipping (when a security precondition was otherwise to be used), whereas addition of the option tag could lead to session failure (if the other side does not support preconditions).
シグナリング保全メカニズムの使用は上の問題のすべてを防ぐことができます。シグナリング経路(例えば、SIPプロキシ)の仲介者が信じられるところでは、ホップごとのシグナリングの保全保護だけを使用するのは例えば十分です。IPSecかTLS。 他のすべての場合では、シグナリング(例えば、S/MIME)の終わりから終わりへの保全保護を使用しなければなりません。 終わりから終わりへの保全保護がメッセージ本体だけをカバーしてはいけなくて、どれがセキュリティを含んでいるかがあらかじめ調整されますが、SIPがヘッダーを「サポートし」て、また「また必要である」と述べてください。(ヘッダーは「前提条件」オプションタグを含むかもしれません)。 唯一のメッセージ本体が保護された保全であるなら、「前提条件」オプションタグの取り外しは、切り取るのに通じるかもしれないでしょうにが(セキュリティ前提条件が使用されているためにそうでなかったときに)、オプションタグの追加はセッション失敗につながるかもしれません(反対側が前提条件を支えないなら)。
As specified in Section 3, security preconditions do not guarantee that an established media stream will be secure. They merely guarantee that the recipient of the media stream packets will be able to perform any relevant decryption and integrity checking on those media stream packets.
セクション3で指定されるように、セキュリティ前提条件は、確立したメディアストリームが安全になるのを保証しません。 彼らは、メディアの受取人がそれらのメディアにおけるどんな関連復号化も実行できて、保全照合がストリームパケットであるつもりであったならパケットを流すのを単に保証します。
Current SDP [RFC4566] and associated offer/answer procedures [RFC3264] allows only a single type of transport protocol to be negotiated for a given media stream in an offer/answer exchange. Negotiation of alternative transport protocols (e.g., plain and secure RTP) is currently not defined. Thus, if the transport protocol offered (e.g., secure RTP) is not supported, the offered media stream will simply be rejected. There is however work in progress to address that. For example, the SDP Capability Negotiation framework [SDPCN] defines a method for negotiating the use of a secure or a non-secure transport protocol by use of SDP and the offer/answer model with various extensions.
[RFC3264]が申し出/答え交換で単独のタイプの与えられたメディアストリームのために交渉されるべきトランスポート・プロトコルだけを許容する現在のSDP[RFC4566]と関連申し出/答え手順。 代替のトランスポート・プロトコル(例えば、明瞭で安全なRTP)の交渉は現在、定義されません。 したがって、提供されたトランスポート・プロトコル(例えば、安全なRTP)がサポートされないと、提供されたメディアストリームは単に拒絶されるでしょう。 しかしながら、それを扱うために、処理中の作業があります。 例えば、SDP Capability Negotiationフレームワーク[SDPCN]はSDPの使用と申し出/答えモデルによる様々な拡大による安全なトランスポート・プロトコルか非安全なトランスポート・プロトコルの使用を交渉するためのメソッドを定義します。
Such a mechanism introduces a number of security considerations in general, however use of SDP Security Preconditions with such a
そのようなメカニズムはしかしながら、一般に、多くのセキュリティ問題、そのようなaとのSDP Security Preconditionsの使用を導入します。
Andreasen & Wing Standards Track [Page 12] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[12ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
mechanism introduces the following security precondition specific security considerations:
メカニズムは以下のセキュリティの前提条件の特定のセキュリティ問題を紹介します:
A basic premise of negotiating secure and non-secure media streams as alternatives is that the offerer's security policy allows for non- secure media. If the offer were to include secure and non-secure media streams as alternative offers, and media for either alternative may be received prior to the answer, then the offerer may not know if the answerer accepted the secure alternative. An active attacker thus may be able to inject malicious media stream packets until the answer (indicating the chosen secure alternative) is received. From a security point of view, it is important to note that use of security preconditions (even with a mandatory strength-tag) would not address this vulnerability since security preconditions would effectively apply only to the secure media stream alternatives. If the non-secure media stream alternative was selected by the answerer, the security precondition would be satisfied by definition, the session could progress and (non-secure) media could be received prior to the answer being received.
申出人の安全保障政策が非安全なメディアのために許容する代替手段が安全で非安全なメディアストリームであるのにもかかわらずの、交渉する根本的な前提。 申し出が代替の申し出として安全で非安全なメディアストリームを含むことであり、答えの前にどちらかの選択肢のためのメディアを受け取るかもしれないなら、申出人は、answererが安全な代替手段を受け入れたかどうかを知らないかもしれません。 その結果、答え(選ばれた安全な代替手段を示す)が受け取られているまで、活発な攻撃者は悪意があるメディアストリームパケットを注入できるかもしれません。 セキュリティ観点から、事実上、前提条件が安全なメディアだけに適用するセキュリティが代替手段を流すのでセキュリティ前提条件(義務的な強さタグがあっても)の使用がこの脆弱性を扱わないことに注意するのは重要です。 非安全なメディアが流れるなら、answererは代替手段を選択しました、そして、定義上セキュリティ前提条件を満たしたでしょう、そして、セッションは進歩をすることができました、そして、受けられる答えの前に(非安全)のメディアを受け取ることができました。
6. IANA Considerations
6. IANA問題
IANA has registered an RFC 3312 precondition type called "sec" with the name "Security precondition". The reference for this precondition type is the current document.
IANAはタイプが名前「セキュリティ前提条件」で「秒」と呼んだRFC3312前提条件を登録しました。 この前提条件タイプの参照は現在のドキュメントです。
7. Acknowledgements
7. 承認
The security precondition was defined in earlier versions of RFC 3312. RFC 3312 contains an extensive list of people who worked on those earlier versions, which are acknowledged here as well. The authors would additionally like to thank David Black, Mark Baugher, Gonzalo Camarillo, Paul Kyzivat, and Thomas Stach for their comments on this document.
セキュリティ前提条件はRFC3312の以前のバージョンで定義されました。 RFC3312はまた、ここで承認されるそれらの以前のバージョンに取り組んだ人々の大規模なリストを含んでいます。 作者はこのドキュメントの彼らのコメントについてさらに、デヴィッドBlack、マークBaugher、ゴンサロ・キャマリロ、ポールKyzivat、およびトーマスStachに感謝したがっています。
8. Normative References
8. 引用規格
[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月。
[RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]キャマリロ、G.(エド)とマーシャル、W.(エド)とJ.ローゼンバーグ、「資源管理とセッション開始プロトコル(一口)の統合」RFC3312(2002年10月)。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
Initiation Protocol (SIP) Preconditions Framework", RFC
4032, March 2005.
[RFC4032]キャマリロとG.とP.Kyzivat、「セッション開始プロトコル(一口)へのアップデートはフレームワークをあらかじめ調整する」RFC4032、2005年3月。
Andreasen & Wing Standards Track [Page 13] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[13ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
[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月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
9. Informative References
9. 有益な参照
[SDESC] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[SDESC] Andreasen、F.、Baugher、M.、およびD.翼、「メディアストリームのためのセッション記述プロトコル(SDP)セキュリティ記述」、RFC4568(2006年7月)。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3551] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[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行進。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT)
Traversal for Multimedia Session Establishment Protocols",
Work in Progress, September 2007.
ローゼンバーグ、[氷]J.、「対話的な接続性設立(氷):」 「マルチメディアセッション設立プロトコルのためのネットワークアドレス変換機構(NAT)縦断のための方法論」、処理中の作業、2007年9月。
[KMGMT] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP)",
RFC 4567, July 2006.
[KMGMT] Arkko、J.、リンドホルム、F.、ジーター、M.、Norrman、K.、およびE.カラーラ、「セッション記述のためのKey Management拡大は(SDP)とリアルタイムのストリーミングのプロトコル(RTSP)について議定書の中で述べます」、RFC4567、2006年7月。
[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月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3262] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3311] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデートメソッド」、RFC3311、2002年10月。
Andreasen & Wing Standards Track [Page 14] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[14ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
[HERFP] Mahy, R., "A Solution to the Heterogeneous Error Response
Forking Problem (HERFP) in the Session Initiation Protocol
(SIP)", Work in Progress, March 2006.
[HERFP]マーイ、R.、「セッション開始プロトコル(一口)の異種の誤り応答分岐問題(HERFP)の解決」が進行中(2006年3月)で働いています。
[SDPCN] Andreasen, F., "SDP Capability Negotiation", Work in
Progress, July 2007.
F.、「SDP能力交渉」という[SDPCN]Andreasenは進歩、2007年7月に働いています。
Authors' Addresses
作者のアドレス
Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, New Jersey 08837 USA
フレミングAndreasenシスコシステムズ, Inc.499Thornall通り、第8Floorエディソン、ニュージャージー08837米国
EMail: fandreas@cisco.com
メール: fandreas@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・Driveダン翼のシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
EMail: dwing@cisco.com
メール: dwing@cisco.com
Andreasen & Wing Standards Track [Page 15] RFC 5027 Security Preconditions October 2007
Andreasenと翼の標準化過程[15ページ]RFC5027セキュリティは2007年10月にあらかじめ調整されます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Andreasen & Wing Standards Track [Page 16]
Andreasenと翼の標準化過程[16ページ]
一覧
スポンサーリンク
