Network Working Group F. Andreasen
Request for Comments: 5027 D. Wing
Updates: 3312 Cisco Systems
Category: Standards Track October 2007
Security Preconditions for
Session Description Protocol (SDP) Media Streams
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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.
この文書では、正常にネゴシエートされた安全なメディア・ストリームのメディア・ストリーム・セキュリティまで、セッション確立または修正を遅延させるために使用することができるのRFC 3312と4032のセキュリティ前提で説明セッション記述プロトコル（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
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.
[RFC4032]で更新されるセッション記述プロトコルのコンセプト（SDP）[RFC4566]前提条件は、[RFC3312]で定義されています。前提条件は、セッション確立または進行する変形ために所与のメディア・ストリームのために満たさなければならない条件です。 （必須）前提条件が満たされない場合には前提条件が成立しているか、セッション確立が失敗するまで、セッションの進行が遅れています。例えば、RFC 3312は、前（即ち、警告）コールを確立するネットワーク・リソースの可用性を確保するために使用されるサービス品質の前提条件を定義します。
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.
メディアストリームは、いずれかの平文にしていない完全性保護、または適用可能なメディアセキュリティのいくつかの種類、例えば、機密性および/またはメッセージの整合性を持たせることができます。セキュアリアルタイム転送プロトコル（SRTP）[SRTP]は常にセキュリティサービスで使用されているのに対し、例えば、リアルタイム転送プロトコル（RTP）のオーディオ/ビデオプロフィール[RFC3551]は、通常、すべてのセキュリティサービスなしで使用されています。メディアストリームセキュリティがネゴシエートされているとき、例えば、SDPセキュリティ記述[SDESC]、申出と回答両方[RFC3264]で定義されたメカニズムを使用してメディアストリームのために使用される暗号パラメータを知る必要があります。提供者は、暗号化パラメータの複数の選択肢を提供することができる、または回答者によって選択された暗号パラメータは、提供者（例えば、他の対一方向に用いられる鍵）のものと異なっていてもよいです。このような場合には、メディア・クリッピングを避けるために、オファー側は、事前回答から任意のメディアパケットを受信したことに答えを受信する必要があります。これは、セッション確立または修正する前に安全なメディアストリームのメディアストリームのセキュリティパラメータのネゴシエーション成功を保証し、セキュリティの前提条件を使用することによって達成することができます。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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, confidentiality, or both), regardless of the cryptographic strength of the mechanisms being used.
セキュリティの前提条件のためのセマンティクスは、安全なメディアストリームに関連する暗号化パラメータ（暗号キーなど）が必要な方向（S）に交渉されていることが知られているということです。セキュリティの前提条件が非セキュアメディアストリームで使用されている場合は、セキュリティ上の前提条件は、定義によって満たされています。セキュアメディアストリームは、ここに関係なく使用されている機構の暗号強度の、セキュリティサービス（例えば、メッセージの完全性、機密性、または両方）のいくつかの種類を使用してメディアストリームとして定義されます。
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暗号化アルゴリズム及びメッセージ・インテグリティを使用してセキュア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:
セキュリティの前提条件タイプは、文字列「秒」で定義されたので、私たちは次のようにRFC 3312で見つかった文法を修正されています。
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.
RFC 3312は、ステータスタイプの二種類、すなわち、セグメント化及びエンドツーエンドのサポートを定義します。ここで定義されたセキュリティの前提条件タイプは、エンドツーエンドのステータスタイプを使用しなければなりません。セグメント化されたステータスタイプの使用が定義されていません。
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）に交渉されていることが知られています。必須のセキュリティ前提条件が提供され、そして（オファーが安全なメディアストリームのためだったので、例えば、それは例えば鍵材料を安全なメディアストリームを確立するために、必要なパラメータが含まれていなかった）回答は、セキュリティ上の前提条件を満たすことができない場合には、 RFC 3312で説明したように提供されたメディアストリームを拒絶しなければなりません。
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.
ここで定義されたセッション確立の遅れは、着信側の警告が生じてはならないとの前提条件が満たされたまではセキュリティがネゴシエートされているため、メディアを交換してはならないことを意味します。セキュアメディアおよび他の非メディアデータは、メディア・ストリームに多重化されている場合には（例えば、インタラクティブ接続確立に使用されている[ICE]は場合）、非メディアデータは、従来のセキュリティ前提条件に交換することが許可されている満たされます。
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.
「オプション」の強さ - タグ付きセキュリティ前提条件を提供して受信した場合、回答はできるだけ早くその回答SDPを発生させなければなりません。セッションの進行は、この場合には遅延されないので、オファーは、セキュアメディアストリームパケットを処理することができ、従って、起こり得るクリッピングである場合、回答者は知りません。彼はオファー側が答えを受けている知っているまで回答がクリッピングを回避し、セッションの進行を遅らせることを望む場合、回答は答えに「必須」の強さ・タグを使用して、セキュリティの前提条件の強度を増加させる必要があります。オファーに必須の前提条件の使用は、SIPの存在を必要と注意オプションタグ「前提条件」を含むヘッダ・フィールド「必須」：任意のSIP UA必須の前提条件をサポートしていない結果としても悪影響を意図しないたような要求を（拒否しますヘテロジニアスエラー応答フォーク問題（[HERFP]、などを参照のこと）として知られている。これを回避するためにSIPのフォーク、オプションのセキュリティ前提条件とオプションタグ「前提条件」を含む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].
「なし」の強度タグ付きセキュリティ前提条件を受信した場合、処理は通常通り継続します。 [RFC3312]で説明したように回答が答えに強タグをアップグレードできます - 「なし」強タグは単に、オファーは、以下のセキュリティ前提条件をサポートしていることを示しています。
The direction tags defined in RFC 3312 are interpreted as follows:
次のようにRFC 3312で定義された方向タグが解釈されます。
* 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.
*送信：ストリームのセキュリティネゴシエーションは、相手にメディアパケットを送信することが可能であると、他の当事者が、セキュリティの観点から、それらを正しく処理することができるようになります段階にあるメディア、すなわち、解読および/または完全性は、それらをチェックします必要に応じて。 「メディアパケット」の定義は、メディアストリームを構成するすべてのパケットが含まれます。例えばセキュアRTPの場合には、SRTPならびにSRTCPを含みます。メディアおよび非メディアパケットが所与のメディア・ストリーム（例えば、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.
相手が正しくセキュリティの観点からメディアストリームパケットを処理することが可能であるときを決定するための正確な基準が必要な暗号パラメータがネゴシエートされる機構と同様に使用されているセキュアメディアストリームプロトコルに依存します。
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.
オファー側がセキュリティ前提条件を「送信」要求すると、セキュリティの前提条件が満たされる前に*、それが答えを受信する必要があります。この理由は二つあります。まず、オファー側はどこメディアを送信するために知っている必要があります。第二に、代替暗号化パラメータが提供されている場合には、オファー側は、選択されたセットを知っている必要があります。答えは実際に（順番に前提条件を満たします）オファー側で受信したときに回答がわからない、ので、回答は確認-ステータス属性[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」のセキュリティ前提条件を要求すると*、それはまた、セキュリティ上の前提条件が満たされる前に答えを受信する必要があります。その理由は簡単です：答えは、オファーにメディアを送信するため、回答によって使用される暗号化パラメータを含んでいます。前にこれらの暗号パラメータの受信に、オファー側は認証したり、そのようなメディアを復号化することができません。
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.
セキュリティの前提条件は、セッション記述プロトコル（SDP）のためのキー管理の拡張機能[KMGMT]で使用されている場合は、詳細が使用されている実際の鍵管理プロトコルに依存します。
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.
セキュリティの前提条件が要求されている最初のオファー/アンサー交換した後、最初のオファー/アンサー交換と同じ鍵材料を使用すべきで安全なメディアストリームのための前提条件のステータスを更新する目的のために、後続のオファー/アンサーシーケンス。これは、キーMGMT属性行[KMGMT]、または暗号化属性行は、[SDESC]確認-statusフィールド[RFC3312]を含むSDP答えに応答して送信されているSDP申し出、中に送られたものと同じデータを繰り返し必要があることを意味し前のSDPオファー。鍵管理プロトコルまたはSDPセキュリティ記述に該当する場合、これらのSDP申し出へのSDPの回答は、前回のSDPアンサーに送信されているような[SDESC]キーMGMT属性行[KMGMT]または暗号化属性行で同じデータを繰り返す必要があります。
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オファー/アンサー交換に同一であることを認識し、さらなる処理のためにセキュリティ層へ情報を転送回避する場合、この問題を解決することができます。
Offers with security preconditions in re-INVITEs or UPDATEs follow the rules given in Section 6 of RFC 3312, i.e.:
再のINVITEまたは更新のセキュリティ前提条件RFC 3312のセクション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."
「どちらのユーザエージェントは、すべての必須の前提条件が満たされるまで、古いセッションパラメータを使用し続けるべきである。その瞬間、ユーザエージェントは、新たなセッションパラメータを使用して始めることができます。」
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.
その瞬間、私たちはさらに、ユーザエージェントが送信されるメディアパケットのための新たなセッションパラメータを使用して開始しなければならないことが必要です。ユーザエージェントは、古いまたは輸送中にメディアパケットに対応するために、時間の短い期間のための新たなセッションパラメータのいずれかで受信したメディアパケットを処理するために準備する必要があります。これはその期間中に受信したメディアパケットの反復セキュリティ処理を伴うことがあります。 [RFC3264]で第8節は、受信したメディアパケットが古いか新しいオファー/アンサー交換に応じて生成されたときに決定する問題を軽減するためにいくつかの技術を示しています。
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のコールフローは、セッション開始プロトコル[SIP]とセキュアメディアストリーム（ここではSRTP）のセキュリティ記述とSDPセキュリティ記述[SDESC]を使用して、基本的なセッション確立を示します。
A B
B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|----------------(3) PRACK SDP3------------->|
| |
|<-----------(4) 200 OK (PRACK) SDP4---------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
Figure 1: Security Preconditions with SDP Security Descriptions Example
図1：SDPセキュリティ記述の例とセキュリティの前提条件
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記述は以下の通りです - 私たちは、ここで説明したセキュリティ前提条件を明確にするためSDPセキュリティ記述の内容だけでなく、任意の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 "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]参照）、方向を受け取りますメディアパケットを生成します。 Bはまだセキュリティパラメータのいずれかを知らないので、現在の状況は（RFC 3312を参照）を「なし」に設定されています。次のようにAのローカルステータステーブルには、セキュリティの前提条件のためにされた（RFC 3312を参照してください）：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
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...
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が知っている（送信およびRECV）セキュリティの観点から、AとBの両方のセキュリティパラメータは、Bは、今Aからのメディアを受信することが可能であるBさん「RECV」のセキュリティ前提ので、 "yes" です。 Bさんは、セキュリティの前提条件が「ノー」である「送信」のでしかし、Aは、BのSDP情報のいずれかを知りません。次のようにBのローカルステータステーブルは、それゆえになります。
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
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の送信方向の確認を求めるために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...
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は、RFC 3312でルールに基づいて、そのローカルステータステーブルを更新すると、Aは、送信の両方のセキュリティパラメータを知っているし、次のように方向、したがって、Aのローカルステータステーブルが更新される受信します。
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | yes
recv | yes | mandatory | yes
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のセキュリティ前提条件の確認を要求し、そして両方が今満たされているので、すぐにセキュリティの前提条件が満たされていることを示す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...
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は次のように得た、RFC 3312でルールに基づいて、そのローカルステータステーブルを更新します。
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
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は図の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...
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のローカルステータステーブルは、すべての必須の前提条件が満たされたことを示し、従って、セッション確立を再開する。 Bは、（5）警告を示すために180（リンギング）応答を返します。
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のコールフローは、安全なメディアストリーム（この場合はSRTP）のためのセッション開始プロトコル[SIP]およびセキュリティの説明とSDPのためのキー管理の拡張機能[KMGMT]を使用して、基本的なセッション確立を示しています。
A B
B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|----------------(3) PRACK SDP3------------->|
| |
|<-----------(4) 200 OK (PRACK) SDP4---------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
Figure 2: Security Preconditions with Key Management Extensions for SDP Example
図2：SDP例のためのキー管理の拡張機能とセキュリティの前提条件
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記述は以下の通りです - 私たちはキー管理の拡張機能とMIKEY [マイキー]の使用例を示し、しかし、我々はここで説明したセキュリティ前提条件を明確にするためにMIKEYパラメータの詳細だけでなく、任意の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は、送信の両方のために必須のエンドツーエンドのセキュリティの前提条件が含まれており、使用することができ鍵材料を含む初期オファーならびに「キーMGMT」属性（[KMGMT]参照）、方向を受け取りますメディアパケットを生成します。 Bはまだセキュリティパラメータのいずれかを知らないので、現在の状況は（RFC 3312を参照）を「なし」に設定されています。次のようにAのローカルステータステーブルには、セキュリティの前提条件のためにされた（RFC 3312を参照してください）：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
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...
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とB Bの両方の（送信およびRECV）セキュリティパラメータを知っているAにメディアを送信するための鍵材料を生成し、ただし、AはBの鍵材料を知っているので、しませんBのセキュリティ前提条件を「送信」の現在のステータスが「ノー」です。 Bさん「RECV」のセキュリティ前提条件が「はい」であるので、Bは、AのSDP情報を知っているん。次のようにBのローカルステータステーブルは、それゆえになります。
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
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は、送信に使用されるセキュリティパラメータを知ったときに確認し、方向を受け取るために要求し、したがって、その結果、回答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...
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.
答えの実際のMIKEYデータは提供のものと異なることに注意してください。しかし、我々は上記のみでマイキー値の初期と共通部分を示しています。
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は、ルールに基づいて、そのローカル状態テーブルを更新RFC 3312でAは現在の送信の両方のすべてのセキュリティパラメータを知っているし、次のように方向、したがって、Aのローカルステータステーブルが更新される受信します。
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | yes
recv | yes | mandatory | yes
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のセキュリティ前提条件の確認を要求し、そして両方が今満たされているので、すぐにセキュリティの前提条件が満たされていることを示す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...
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は次のように得た、RFC 3312でルールに基づいて、そのローカルステータステーブルを更新します。
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
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は図の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...
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のローカルステータステーブルは、すべての必須の前提条件が満たされたことを示し、従って、セッション確立を再開する。 Bは、（5）警告を示すために180（リンギング）応答を返します。
In addition to the general security considerations for preconditions provided in RFC 3312, the following security issues should be considered.
RFC 3312で提供前提条件のための一般的なセキュリティ上の考慮事項に加えて、次のようなセキュリティ上の問題を考慮すべきです。
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 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.
逆に、攻撃者がそれらを含むか、彼らの強タグを増加させない申し出にセキュリティ前提条件を追加することができます。これは、次に、セッション障害（例えば、回答者がそれをサポートしていない場合）、不均一誤り問題をフォーク応答、または所望されなかったセッション確立の遅延につながる可能性があります。
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.
現在のSDP [RFC4566]及び関連するオファー/アンサー手順[RFC3264]は、トランスポートプロトコルの単一タイプのオファー/アンサー交換における所与のメディア・ストリームのために交渉することを可能にします。別のトランスポートプロトコル（例えば、普通、安全なRTP）の交渉は、現在定義されていません。 （例えば、セキュアRTP）提供されるトランスポートプロトコルがサポートされていない場合したがって、提供されるメディア・ストリームは、単に拒否されます。しかし、それに対処するために進行中であり動作しています。例えば、SDP機能ネゴシエーションフレームワーク[SDPCN]は、セキュア又はSDPおよび種々の拡張子を持つオファー/アンサーモデルを用いて非セキュアトランスポートプロトコルの使用を交渉するための方法を定義します。
Such a mechanism introduces a number of security considerations in general, however use of SDP Security Preconditions with such a mechanism introduces the following security precondition specific security considerations:
このようなメカニズムは、しかし、そのような機構をSDPセキュリティ前提条件を使用し、一般的なセキュリティ上の考慮事項の数を導入し、次のセキュリティ前提特定のセキュリティの考慮事項を紹介します。
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.
代替案として、セキュアと非セキュアなメディアストリームを交渉の基本的な前提は、オファー側のセキュリティポリシーは、セキュリティで保護されていないメディアを可能にすることです。オファーは答えの前に受信することができる代替のいずれかのために安全かつ非セキュアメディアの代替の提供などのストリーム、及びメディアを含めた場合は回答が安全な代替を受け入れた場合、その後の申し出人は知らないかもしれません。活発な攻撃者は、このように（選択された安全な代替物を示す）回答が受信されるまで、悪意のあるメディアストリームパケットを注入することができるかもしれません。セキュリティの観点から、セキュリティ上の前提条件が効果的にのみ安全なメディアストリームの代替にも適用されるため、この脆弱性を解決しません（でも必須強タグ付き）セキュリティ前提条件の使用は注意することが重要です。非セキュアメディアストリームの代替が回答で選択された場合は、セキュリティ上の前提条件が定義によって満足されるだろう、セッションは、メディアが前に受信された答えに受信できた（非セキュア）進行とができます。
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は名前「セキュリティの前提条件」と「秒」と呼ばれるRFC 3312の前提条件タイプが登録されています。この前提条件タイプの参照は、現在のドキュメントです。
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.
前提条件は、RFC 3312 RFC 3312の以前のバージョンで定義されたセキュリティは、ここにも認知されているものを以前のバージョン、に取り組んだ人々の広範なリストが含まれています。著者はさらに、このドキュメントの彼らのコメントのためにデビッド・ブラック、マーク・Baugher、ゴンサロ・カマリロ、ポールKyzivat、とトーマスStachに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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.ローゼンバーグ、RFC 3312、2002年10月 "資源管理とセッション開始プロトコル（SIP）の統合"。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032]キャマリロ、G.とP. Kyzivat、 "セッション開始プロトコル（SIP）前提条件フレームワークへの更新"、RFC 4032、2005年3月。
[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.
[SIP]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[SDESC] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[SDESC]アンドレア、F.、Baugher、M.、およびD.翼、 "メディア・ストリームのセッション記述プロトコル（SDP）のセキュリティの説明"、RFC 4568、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プロフィール"、STD 65、RFC 3551、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] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[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.
[ICE]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：マルチメディアセッション確立プロトコルのためのネットワークアドレス変換（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.、Naslund、M.、Norrman、K.、およびE.カララ、 "鍵管理拡張セッション記述プロトコル（SDP）、リアルタイムストリーミングプロトコル（RTSP）のための"、RFC 4567、2006年7月。
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
【MIKEY] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、RFC 3830、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と、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年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.、「セッション開始プロトコル（SIP）におけるヘテロジニアスエラー応答フォーク問題（HERFP）へのソリューション」、進歩、2006年3月での作業。
[SDPCN] Andreasen, F., "SDP Capability Negotiation", Work in Progress, July 2007.
[SDPCN]アンドレア、F.、 "SDP機能ネゴシエーション"、進歩、2007年7月の作業。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, New Jersey 08837 USA
フレミングAndreasenのシスコシステムズ社499 Thornallストリート、8階エジソン、ニュージャージー08837 USA
EMail: fandreas@cisco.com
メールアドレス：fandreas@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
ダン・ウィングシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: dwing@cisco.com
メールアドレス：dwing@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。