[要約] RFC 5027は、SDPメディアストリームのセキュリティの前提条件に関する規格です。このRFCの目的は、SDPメディアストリームのセキュリティを向上させるためのガイドラインを提供することです。
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
セッション説明プロトコル（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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（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.
このドキュメントでは、RFCS 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.
セッション説明プロトコル（SDP）[RFC4566]の概念は、[RFC4032]によって更新された[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.
メディアストリームは、ClearTextで提供され、整合性保護なしで提供されるか、ある種のメディアセキュリティを適用できます。たとえば、機密性やメッセージの整合性を適用できます。たとえば、リアルタイム転送プロトコル（RTP）[RFC3551]のオーディオ/ビデオプロファイルは、通常、セキュリティサービスなしで使用されますが、安全なリアルタイムトランスポートプロトコル（SRTP）[SRTP]は常にセキュリティサービスで使用されます。メディアストリームのセキュリティが交渉されている場合、たとえば、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
セキュリティの前提条件のセマンティクスは、安全なメディアストリームの関連する暗号化パラメーター（暗号、キーなど）が、必要な方向に交渉されたことが知られていることです。セキュリティの前提条件が非セキュアーメディアストリームで使用されている場合、セキュリティの前提条件は定義により満たされます。ここでは、セキュアなメディアストリームは、使用されているメカニズムの暗号化強度に関係なく、何らかのセキュリティサービス（メッセージの整合性、機密性など）を使用するメディアストリームとして定義されます。
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:
セキュリティ前処理タイプは文字列「sec」で定義されるため、RFC 3312で見つかった文法を次のように変更します。
precondition-type = "sec" / "qos" / token
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は、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.
「必須」の筋力タグを含むセキュリティの前提条件がオファーで受信される場合、セキュリティの事前調整が満たされるまでセッションの確立または変更を遅らせる必要があります。つまり、関連する暗号化パラメーター（暗号、キーなど）安全なメディアストリームは、必要な方向に交渉されたことが知られています。必須のセキュリティの前提条件が提供され、応答者がセキュリティの前提条件を満たすことができない場合（たとえば、オファーは安全なメディアストリーム向けであるため、たとえば安全なメディアストリームキーイング素材を確立するために必要なパラメーターを含めなかったため）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は、その結果、そのようなリクエストを拒否します（これには意図しない影響もあります。不均一なエラー応答のフォーキング問題として知られているSIPフォーキングの場合（例：[HERFP]を参照）。これを回避するには、オプションのセキュリティ前提条件とSIPがオプションタグ「Precondition」を含む「サポートされている」ヘッダーフィールドを代わりに使用できます。。
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.
* オファーがセキュリティの前提条件を「送信」する場合、セキュリティの前提条件が満たされる前に回答を受信する必要があります。この理由は2つあります。まず、オファーはメディアをどこに送るかを知る必要があります。第二に、代替の暗号化パラメーターが提供される場合、オファーはどのセットが選択されたかを知る必要があります。応答者は、応答者が実際に受け取った時期（これが前提条件を満たす）を知りません。これにより、オファーが前提条件の更新されたステータスを示す新しいオファーを生成します。
* 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.
セキュリティの前提条件が要求される最初のオファー/回答交換の後、安全なメディアストリームの前提条件のステータスを更新する目的で、その後のオファー/回答シーケンスは、初期オファー/回答交換と同じキーマテリアルを使用する必要があります。これは、SDPオファーのkey-mgmt属性線[kmgmt]、またはsdpオファーの暗号属性線[SDESC]が、確認整数フィールド[RFC3312]を含むSDP回答に応じて送信されることを意味します。以前のSDPオファー。主要な管理プロトコルまたはSDPセキュリティの説明に適用可能な場合、これらのSDPオファーに対するSDPの回答は、以前のSDP回答で送信されたものと同じように、Key-MGMT属性行[KMGMT]またはCrypto属性行[SDESC]で同じデータを繰り返す必要があります。
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.:
REINVITESまたは更新のセキュリティの前提条件を備えたオファーは、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]およびSDPセキュリティ説明[SDESC]を使用した基本的なセッション確立を、安全なメディアストリーム（この場合はSRTP）のセキュリティ説明を使用して示しています。
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は、最初のオファーの送信および受信方向の両方に必須のエンドツーエンドのセキュリティ前処理と、「crypto」属性（[sdesc]を参照）を含みます。メディアパケットを生成します。Bはまだセキュリティパラメーターをまだ知らないため、現在のステータス（RFC 3312を参照）は「NONE」に設定されています。セキュリティの前提条件については、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はAとBの両方の（送信およびRECV）セキュリティパラメーターを知っています。セキュリティの観点から、BはAからメディアを受信できるようになりました。「はい」です。ただし、AはBのSDP情報を知らないため、Bの「セキュリティの前提条件」は「いいえ」です。したがって、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がAの送信方向の確認を要求するだけで十分です）。
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が回答を受信すると、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セキュリティの前提条件の確認を要求し、両方とも満足しているため、Aはすぐに更新されたオファー（3）をBに送信します。
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.
前提条件はすぐに満たされ、元のオファー/回答の交換が完了するため、更新[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は180（リンギング）応答（5）を返し、アラートを示す。
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のコールフローは、セッション開始プロトコル[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]を使用した例を示しますが、Mikeyパラメーターの詳細と、ここで説明するセキュリティの前提条件の明確さの詳細は省略しています。：
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は、最初のオファーでの送信および受信方向の両方の必須のエンドツーエンドセキュリティの前提条件と、「key-mgmt」属性（[kmgmt]を参照）を含みます。aメディアパケットを生成します。Bはまだセキュリティパラメーターをまだ知らないため、現在のステータス（RFC 3312を参照）は「NONE」に設定されています。セキュリティの前提条件については、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の両方の（送信およびRECV）セキュリティパラメーターを知っています。Bの「送信」セキュリティ前提条件の現在のステータスは「いいえ」です。BはAのSDP情報を知っているため、Bの「RECV」セキュリティの前提条件は「はい」です。したがって、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が送信および受信方向で使用されているセキュリティパラメーターを知っていることを確認するようにaを要求します。
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.
答えの実際のマイキーデータは、オファーのそれとは異なることに注意してください。ただし、上記のマイキー値の初期および共通の部分のみを示しています。
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が回答を受信すると、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セキュリティの前提条件の確認を要求し、両方とも満足しているため、Aはすぐに更新されたオファー（3）をBに送信します。
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は180（リンギング）応答（5）を返し、アラートを示す。
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は、「セキュリティの前提条件」という名前で「SEC」と呼ばれる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の以前のバージョンで定義されていました。RFC3312には、以前のバージョンに取り組んだ人々の広範なリストが含まれています。著者はさらに、この文書に関するコメントについて、デビッド・ブラック、マーク・ボーサー、ゴンザロ・カマリロ、ポール・キジバット、トーマス・スタッハに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Camarillo、G.、Ed。、Marshall、W.、ed。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032] Camarillo、G。およびP. Kyzivat、「セッション開始プロトコル（SIP）Preconditions Frameworkの更新」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIATION Protocol」、RFC 3261、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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. Wing、「セッション説明プロトコル（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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（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] Rosenberg、J。、「Interactive Connectivity Indecivity（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.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（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.
[Mikey] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311] Rosenberg、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] Mahy、R。、「セッション開始プロトコル（SIP）における不均一なエラー応答のフォーキング問題（HERFP）の解決策」、2006年3月、作業進行中。
[SDPCN] Andreasen, F., "SDP Capability Negotiation", Work in Progress, July 2007.
[SDPCN] Andreasen、F。、「SDP能力交渉」、2007年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, New Jersey 08837 USA
フレミングアンドレアセンシスコシステムズ499 Thornall Street、8階のエジソン、ニュージャージー08837 USA
EMail: fandreas@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 USA
EMail: dwing@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。