[要約] RFC 4568は、メディアストリームのセッション記述プロトコル（SDP）セキュリティ記述に関するものであり、セキュリティ関連の情報をSDPに追加するための方法を提供しています。このRFCの目的は、メディアストリームのセキュリティを向上させるための標準化とガイドラインの提供です。
Network Working Group F. Andreasen
Request for Comments: 4568 M. Baugher
Category: Standards Track D. Wing
Cisco Systems
July 2006
Session Description Protocol (SDP) Security Descriptions for 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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message.
このドキュメントでは、ユニキャストメディアストリームのセッション記述プロトコル（SDP）暗号化属性を定義します。この属性は、単一のメッセージまたは往復交換のいずれかでユニキャストメディアストリームのセキュリティを構成するのに役立つ暗号化キーおよびその他のパラメーターを記述します。この属性は、さまざまなSDPメディアトランスポートで使用できます。このドキュメントでは、セキュアリアルタイムトランスポートプロトコル（SRTP）ユニキャストメディアストリームに使用する方法を定義しています。 SDP暗号属性には、SDPメッセージを保護するためのデータセキュリティプロトコルのサービスが必要です。
Table of Contents
目次
1. Introduction ....................................................3
2. Notational Conventions ..........................................5
3. Applicability ...................................................5
4. SDP "Crypto" Attribute and Parameters ...........................5
4.1. Tag ........................................................6
4.2. Crypto-Suite ...............................................6
4.3. Key Parameters .............................................7
4.4. Session Parameters .........................................8
4.5. Example ....................................................8
5. General Use of the crypto Attribute .............................9
5.1. Use with Offer/Answer ......................................9
5.1.1. Generating the Initial Offer - Unicast Streams ......9
5.1.2. Generating the Initial Answer - Unicast Streams ....10
5.1.3. Processing of the Initial Answer - Unicast
Streams ............................................11
5.1.4. Modifying the Session ..............................11
5.2. Use Outside Offer/Answer ..................................11
5.3. General Backwards Compatibility Considerations ............12
6. SRTP Security Descriptions .....................................12
6.1. SRTP Key Parameter ........................................13
6.2. Crypto-Suites .............................................16
6.2.1. AES_CM_128_HMAC_SHA1_80 ............................16
6.2.2. AES_CM_128_HMAC_SHA1_32 ............................17
6.2.3. F8_128_HMAC_SHA1_80 ................................17
6.2.4. Adding New Crypto-Suite Definitions ................17
6.3. Session Parameters ........................................17
6.3.1. KDR=n ..............................................18
6.3.2. UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP .............18
6.3.3. UNAUTHENTICATED_SRTP ...............................18
6.3.4. FEC_ORDER=order ....................................19
6.3.5. FEC_KEY=key-params .................................19
6.3.6. Window Size Hint (WSH) .............................19
6.3.7. Defining New SRTP Session Parameters ...............20
6.4. SRTP Crypto Context Initialization ........................20
6.4.1. Late Binding of One or More SSRCs to a
Crypto Context .....................................21
6.4.2. Sharing Cryptographic Contexts among
Sessions or SSRCs ..................................22
6.5. Removal of Crypto Contexts ................................23
7. SRTP-Specific Use of the Crypto Attribute ......................23
7.1. Use with Offer/Answer .....................................23
7.1.1. Generating the Initial Offer - Unicast Streams .....23
7.1.2. Generating the Initial Answer - Unicast Streams ....24
7.1.3. Processing of the Initial Answer - Unicast
Streams ............................................25
7.1.4. Modifying the Session ..............................25
7.1.5. Offer/Answer Example ...............................27
7.2. SRTP-Specific Use Outside Offer/Answer ....................28
7.3. Support for SIP Forking ...................................28
7.4. SRTP-Specific Backwards Compatibility Considerations ......29
7.5. Operation with KEYMGT= and k= lines .......................29
8. Security Considerations ........................................29
8.1. Authentication of Packets .................................30
8.2. Keystream Reuse ...........................................30
8.3. Signaling Authentication and Signaling Encryption .........31
9. Grammar ........................................................32
9.1. Generic "Crypto" Attribute Grammar ........................32
9.2. SRTP "Crypto" Attribute Grammar ...........................32
10. IANA Considerations ...........................................34
10.1. Registration of the "crypto" Attribute ...................34
10.2. New IANA Registries and Registration Procedures ..........34
10.2.1. Key Method Registry and Registration ..............34
10.2.2. Media Stream Transport Registry and Registration ..35
10.3. Initial Registrations ....................................35
10.3.1. Key Method ........................................35
10.3.2. SRTP Media Stream Transport .......................35
10.3.2.1. SRTP Crypto Suite Registry and
Registration .............................35
10.3.2.2. SRTP Session Parameter Registration ......36
11. Acknowledgements ..............................................36
12. Normative References ..........................................36
13. Informative References ........................................37
Appendix A - Rationale for Keying Material Directionality .........40
The Session Description Protocol (SDP) [RFC4566] describes multimedia sessions, which can be audio, video, whiteboard, fax, modem, and other media streams. Security services such as data origin authentication, integrity, and confidentiality are often needed for those streams. The Secure Real-time Transport Protocol (SRTP) [RFC3711] provides security services for RTP media and is signaled by use of secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an SDP media (m=) line. However, there are no means within SDP itself to configure SRTP beyond using default values. This document specifies a new SDP attribute called "crypto", which is used to signal and negotiate cryptographic parameters for media streams in general, and for SRTP in particular. The definition of the crypto attribute in this document is limited to two-party unicast media streams where each source has a unique cryptographic key; support for multicast media streams or multipoint unicast streams is for further study.
セッション記述プロトコル（SDP）[RFC4566]は、オーディオ、ビデオ、ホワイトボード、ファックス、モデム、その他のメディアストリームなどのマルチメディアセッションを記述します。多くの場合、これらのストリームには、データ発信元認証、整合性、機密性などのセキュリティサービスが必要です。セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]は、RTPメディアにセキュリティサービスを提供し、SDPメディア（m = ）行。ただし、SDP自体には、デフォルト値を使用する以外にSRTPを構成する手段はありません。このドキュメントでは、「crypto」と呼ばれる新しいSDP属性を指定します。これは、メディアストリーム全般、特にSRTPの暗号化パラメーターをシグナリングおよびネゴシエートするために使用されます。このドキュメントの暗号化属性の定義は、各ソースが一意の暗号化キーを持つ2パーティのユニキャストメディアストリームに限定されています。マルチキャストメディアストリームまたはマルチポイントユニキャストストリームのサポートは、今後の検討課題です。
The crypto attribute is defined in a generic way to enable its use with SRTP and any other secure transports that can establish cryptographic parameters with only a single message or in a single round-trip exchange using the offer/answer model [RFC3264]. Extensions to transports other than SRTP, however, is beyond the scope of this document. Each type of secure media transport needs its own specification for the crypto-attribute parameter. These definitions are frequently unique to the particular type of transport and must be specified in a Standards-Track RFC and registered with IANA according to the procedures defined in Section 10. This document defines the security parameters and keying material for SRTP only.
暗号属性は、SRTPおよび他のすべてのセキュアなトランスポートでの使用を可能にする一般的な方法で定義され、単一のメッセージのみで、またはオファー/アンサーモデル[RFC3264]を使用して単一の往復交換で暗号パラメーターを確立できます。ただし、SRTP以外のトランスポートの拡張は、このドキュメントの範囲外です。セキュアメディアトランスポートの各タイプには、crypto-attributeパラメータの独自の仕様が必要です。これらの定義は、特定の種類のトランスポートに固有のものであることが多く、Standards-Track RFCで指定し、セクション10で定義された手順に従ってIANAに登録する必要があります。このドキュメントでは、SRTPのセキュリティパラメータとキー情報のみを定義しています。
It would be self-defeating not to secure cryptographic keys and other parameters at least as well as the data are secured. Data security protocols such as SRTP rely upon a separate key management system to securely establish encryption and/or authentication keys. Key management protocols provide authenticated key establishment (AKE) procedures to authenticate the identity of each endpoint and protect against man-in-the-middle, reflection/replay, connection hijacking, and some denial-of-service attacks [skeme]. Along with the key, an AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE [ike], Secure Multiparts [s/mime, pgp/mime], or TLS [TLS] securely disseminates information describing both the key and the data-security session. AKE is needed because it is pointless to provide a key over a medium where an attacker can snoop the key, alter the definition of the key to render it useless, or change the parameters of the security session to gain unauthorized access to session-related information.
暗号化キーやその他のパラメータを保護せず、少なくともデータを保護することは、自己破滅的です。 SRTPなどのデータセキュリティプロトコルは、暗号化キーや認証キーを安全に確立するために、別のキー管理システムに依存しています。キー管理プロトコルは、各エンドポイントのIDを認証し、中間者攻撃、リフレクション/リプレイ、接続ハイジャック、および一部のサービス拒否攻撃[skeme]から保護するための認証済みキー確立（AKE）手順を提供します。キーとともに、MIKEY [mikey]、GDOI [GDOI]、KINK [kink]、IKE [ike]、Secure Multiparts [s / mime、pgp / mime]、TLS [TLS]などのAKEプロトコルが情報を安全に配布しますキーとデータセキュリティセッションの両方について説明します。 AKEが必要なのは、攻撃者がキーをスヌープしたり、キーの定義を変更して役に立たないようにしたり、セキュリティセッションのパラメーターを変更してセッション関連の情報に不正アクセスしたりする可能性があるメディアでキーを提供しても意味がないためです。 。
SDP, however, was not designed to provide AKE services, and the media security descriptions defined in this document do not add AKE services to SDP. This specification is no replacement for a key management protocol or for the conveyance of key management messages in SDP [keymgt]. The SDP security descriptions defined here are suitable for restricted cases only where IPsec, TLS, or some other encapsulating data-security protocol (e.g., SIP S/MIME) protects the SDP message. This document adds security descriptions to those encrypted and/or authenticated SDP messages through the new SDP "crypto" attribute, which provides the cryptographic parameters of a media stream.
ただし、SDPはAKEサービスを提供するように設計されておらず、このドキュメントで定義されているメディアセキュリティの説明では、AKEサービスをSDPに追加していません。この仕様は、鍵管理プロトコルまたはSDP [keymgt]での鍵管理メッセージの伝達に代わるものではありません。ここで定義されているSDPセキュリティの説明は、IPsec、TLS、またはその他のカプセル化データセキュリティプロトコル（SIP S / MIMEなど）がSDPメッセージを保護する制限されたケースにのみ適しています。このドキュメントでは、メディアストリームの暗号化パラメーターを提供する新しいSDP "crypto"属性を使用して、暗号化または認証されたSDPメッセージにセキュリティの説明を追加します。
The "crypto" attribute can be adapted to any media transport, but its precise definition is unique to a particular transport.
「crypto」属性は任意のメディアトランスポートに適用できますが、その正確な定義は特定のトランスポートに固有です。
In Section 2, we provide notational conventions followed by an applicability statement for the crypto attribute in Section 3. In Section 4, we introduce the general SDP crypto attribute, and in Section 5, we define how it is used with and without the offer/answer model. In Section 6, we define the crypto attribute details needed for SRTP, and in Section 7, we define SRTP-specific use of the attribute with and without the offer/answer model. Section 8 recites security considerations, and Section 9 gives an Augmented-BNF grammar for the general crypto attribute as well as the SRTP-specific use of the crypto attribute. IANA considerations are provided in Section 10.
セクション2では、表記規則に従ってセクション3の暗号属性の適用性ステートメントを示します。セクション4では、一般的なSDP暗号属性を紹介し、セクション5では、オファーの有無に関係なく使用する方法を定義します。回答モデル。セクション6では、SRTPに必要な暗号属性の詳細を定義し、セクション7では、オファー/アンサーモデルの有無にかかわらず、属性のSRTP固有の使用を定義します。セクション8はセキュリティに関する考慮事項を説明し、セクション9は一般的な暗号化属性とSRTP固有の暗号化属性の使用に関するAugmented-BNF文法を示します。 IANAの考慮事項は、セクション10に記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terminology in this document conforms to [RFC2828], "Internet Security Glossary".
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、[RFC2119]で説明されているように解釈されます。 。このドキュメントの用語は、[RFC2828]の「Internet Security Glossary」に準拠しています。
n^r is exponentiation, where n is multiplied by itself r times; n and r are integers. 0..k is an integer range of all integers from 0 through k, inclusive.
n ^ rは指数であり、nはr倍されます。 nとrは整数です。 0..kは、0からkまでのすべての整数の整数範囲です。
The terms 'transport' and 'media transport' are used to mean 'transport protocol' as defined in RFC 4566.
「トランスポート」および「メディアトランスポート」という用語は、RFC 4566で定義されている「トランスポートプロトコル」を意味するために使用されます。
Explanatory notes are provided in several places throughout the document; these notes are indented three spaces from the surrounding text.
説明の注記は、ドキュメント全体のいくつかの場所に提供されています。これらのメモは、周囲のテキストから3スペース字下げされています。
RFC 4567 provides similar cryptographic key distribution capabilities and is intended for use when the signaling is to be confidential and/or integrity-protected separately from the keying material.
RFC 4567は同様の暗号化キー配布機能を提供し、シグナリングが秘密にしたり、完全性を保護したりする場合に、キー情報とは別に使用することを目的としています。
In contrast, this specification carries the keying material within the SDP message, and it is intended for use when the keying material is protected along with the signaling. Implementations MUST employ security mechanisms that provide confidentiality and integrity for the keying material. When this specification is used in the context of SIP [RFC3261], the application SHOULD employ either the SIPS URI or S/MIME to provide protection for the SDP message and the keying material that it contains. The use of transport layer or IP layer security in lieu of the SIPS URI or S/MIME protection is NOT RECOMMENDED since the protection of the SDP message and the keying material that it contains cannot be ensured through all intermediate entities such as SIP proxies.
これとは対照的に、この仕様はSDPメッセージ内にキー情報を伝達し、シグナリングとともにキー情報が保護されている場合に使用することを目的としています。実装では、キーイングマテリアルの機密性と整合性を提供するセキュリティメカニズムを採用する必要があります。この仕様がSIP [RFC3261]のコンテキストで使用される場合、アプリケーションはSIPS URIまたはS / MIMEのいずれかを使用して、SDPメッセージとそれに含まれるキー情報を保護する必要があります（SHOULD）。 SIPS URIやS / MIME保護の代わりにトランスポート層またはIP層のセキュリティを使用することはお勧めしません。SDPメッセージとそれに含まれるキー情報の保護は、SIPプロキシなどのすべての中間エンティティを通じて保証できるわけではないためです。
A new media-level SDP attribute called "crypto" describes the cryptographic suite, key parameters, and session parameters for the preceding unicast media line. The "crypto" attribute MUST only appear at the SDP media level (not at the session level). The "crypto" attribute follows the format (see Section 9.1 for the formal ABNF grammar):
「crypto」と呼ばれる新しいメディアレベルのSDP属性は、前述のユニキャストメディアラインの暗号スイート、キーパラメータ、およびセッションパラメータを記述します。 「crypto」属性は、SDPメディアレベルでのみ（セッションレベルではなく）出現する必要があります。 「crypto」属性は次の形式に従います（正式なABNF文法についてはセクション9.1を参照）：
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
The fields tag, crypto-suite, key-params, and session-params are described in the following sub-sections. The values of each of these fields is case-insensitive, unless otherwise noted. However, implementers are encouraged to use the actual case shown in this document and any extensions to it. Note that per normal SDP rules, the "crypto" attribute name itself is case-sensitive. Below, we show an example of the crypto attribute for the "RTP/SAVP" transport, i.e., the secure RTP extension to the Audio/Video Profile [RFC3711]. In the following, newlines are included for formatting reasons only:
tag、crypto-suite、key-params、およびsession-paramsの各フィールドについては、次のサブセクションで説明します。特に明記しない限り、これらの各フィールドの値は大文字と小文字を区別しません。ただし、実装者は、このドキュメントに示されている実際のケースとそれに対する拡張機能を使用することをお勧めします。通常のSDPルールでは、「crypto」属性名自体は大文字と小文字が区別されることに注意してください。以下に、「RTP / SAVP」トランスポートの暗号属性の例を示します。つまり、オーディオ/ビデオプロファイル[RFC3711]へのセキュアなRTP拡張です。以下では、改行はフォーマット上の理由でのみ含まれています。
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32
The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined by the text starting with "inline:", and session-params is omitted.
暗号スイートはAES_CM_128_HMAC_SHA1_80で、key-paramsは「inline：」で始まるテキストで定義され、session-paramsは省略されます。
The tag is a decimal number used as an identifier for a particular crypto attribute (see Section 9.1 for details); leading zeroes MUST NOT be used. The tag MUST be unique among all crypto attributes for a given media line. It is used with the offer/answer model to determine which of several offered crypto attributes were chosen by the answerer (see Section 5.1).
タグは、特定の暗号属性の識別子として使用される10進数です（詳細については、セクション9.1を参照してください）。先行ゼロは使用してはなりません（MUST NOT）。タグは、特定のメディアラインのすべての暗号属性の中で一意でなければなりません。オファー/アンサーモデルと共に使用され、提供された暗号属性のうち、アンサーによって選択されたものを決定します（セクション5.1を参照）。
In the offer/answer model, the tag is a negotiated parameter.
オファー/アンサーモデルでは、タグは交渉されたパラメーターです。
The crypto-suite field is an identifier that describes the encryption and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for the transport in question (see Section 9.1 for details). The possible values for the crypto-suite parameter are defined within the context of the transport, i.e., each transport defines a separate namespace for the set of crypto-suites. For example, the crypto-suite "AES_CM_128_HMAC_SHA1_80" defined within the context "RTP/SAVP" transport applies to Secure RTP only; the string may be reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a separate definition would be needed.
暗号スイートフィールドは、問題のトランスポートの暗号化および認証アルゴリズム（AES_CM_128_HMAC_SHA1_80など）を説明する識別子です（詳細については、セクション9.1を参照してください）。 crypto-suiteパラメータの可能な値は、トランスポートのコンテキスト内で定義されます。つまり、各トランスポートは、crypto-suiteのセットの個別の名前空間を定義します。たとえば、コンテキスト「RTP / SAVP」トランスポート内で定義された暗号スイート「AES_CM_128_HMAC_SHA1_80」は、Secure RTPにのみ適用されます。文字列は別のトランスポート（「RTP / SAVPF」[srtpf]など）に再利用できますが、別の定義が必要になります。
In the offer/answer model, the crypto-suite is a negotiated parameter.
オファー/アンサーモデルでは、暗号スイートは交渉されたパラメーターです。
The key-params field provides one or more sets of keying material for the crypto-suite in question. The field consists of a method indicator followed by a colon, and the actual keying information as shown below (the formal grammar is provided in Section 9.1):
key-paramsフィールドは、問題の暗号スイートのキー情報の1つ以上のセットを提供します。このフィールドは、メソッドインジケータとそれに続くコロン、および以下に示す実際のキー情報で構成されます（正式な文法はセクション9.1で提供されます）。
key-params = <key-method> ":" <key-info>
Keying material might be provided by different means from that for key-params; however, this is out of scope. Only one method is defined in this document, namely, "inline", which indicates that the actual keying material is provided in the key-info field itself. There is a single name space for the key-method, i.e., the key-method is transport independent. New key-methods (e.g., use of a URL) may be defined in a Standards-Track RFC in the future. Although the key-method itself may be generic, the accompanying key-info definition is specific not only to the key-method, but also to the transport in question. Key-info encodes keying material for a crypto suite, which defines that keying material. New key methods MUST be registered with the IANA according to the procedures defined in Section 10.2.1.
キー情報は、key-paramsとは異なる方法で提供される場合があります。ただし、これは範囲外です。このドキュメントでは、「インライン」という1つのメソッドのみが定義されています。これは、実際のキー情報がキー情報フィールド自体に提供されていることを示しています。キーメソッドには単一の名前空間があります。つまり、キーメソッドはトランスポートに依存しません。新しいキー方式（URLの使用など）は、Standards-Track RFCで将来定義される可能性があります。キーメソッド自体は一般的なものでもかまいませんが、付随するキー情報の定義は、キーメソッドだけでなく、問題のトランスポートにも固有です。 Key-infoは、暗号スイートのキー情報をエンコードします。これにより、そのキー情報が定義されます。セクション10.2.1で定義されている手順に従って、新しいキーメソッドをIANAに登録する必要があります。
Key-info is defined as a general octet string (see Section 9.1 for details); further transport and key-method specific syntax and semantics MUST be provided in a Standards-Track RFC for each combination of transport and key-method that uses it; definitions for SRTP are provided in Section 6. Note that such definitions are provided within the context of both a particular transport (e.g., "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will register the list of supported key methods for each transport.
key-infoは、一般的なオクテット文字列として定義されます（詳細については、セクション9.1を参照してください）。トランスポートとキーメソッド固有の構文とセマンティクスは、それを使用するトランスポートとキーメソッドの組み合わせごとに、Standards-Track RFCで提供する必要があります。 SRTPの定義はセクション6で提供されています。このような定義は、特定のトランスポート（「RTP / SAVP」など）と特定のキー方式（「インライン」など）の両方のコンテキスト内で提供されることに注意してください。 IANAは、各トランスポートでサポートされている主要なメソッドのリストを登録します。
When multiple keys are included in the key parameters, it MUST be possible to determine which of the keys is being used in a given media packet by a simple inspection of the media packet received; a trial-and-error approach between the possible keys MUST NOT be performed.
キーパラメータに複数のキーが含まれている場合、受信したメディアパケットを簡単に検査することで、特定のメディアパケットで使用されているキーを判別できる必要があります。可能なキー間で試行錯誤のアプローチを実行してはなりません。
For SRTP, this could be achieved by use of Master Key Identifiers (MKI) [RFC3711]. Use of <"From, "To"> values are not supported in SRTP security descriptions for reasons explained in Section 6.1, below.
SRTPの場合、これはマスターキー識別子（MKI）[RFC3711]を使用することで実現できます。以下のセクション6.1で説明する理由により、SRTPセキュリティの説明では、<"From、" To ">値の使用はサポートされていません。
In the offer/answer model, the key parameter is a declarative parameter.
オファー/アンサーモデルでは、主要なパラメーターは宣言型パラメーターです。
Session parameters are specific to a given transport and use of them is OPTIONAL in the security descriptions framework, where they are just defined as general character strings. If session parameters are to be used for a given transport, then transport-specific syntax and semantics MUST be provided in a Standards-Track RFC; definitions for SRTP are provided in Section 6.
セッションパラメータは特定のトランスポートに固有であり、それらの使用はセキュリティ記述フレームワークではオプションであり、一般的な文字列として定義されるだけです。特定のトランスポートにセッションパラメータを使用する場合は、トランスポート固有の構文とセマンティクスをStandards-Track RFCで提供する必要があります。 SRTPの定義については、セクション6で説明します。
In the offer/answer model, session parameters may be either negotiated or declarative; the definition of specific session parameters MUST indicate whether they are negotiated or declarative. Negotiated parameters apply to data sent in both directions, whereas declarative parameters apply only to media sent by the entity that generated the SDP. Thus, a declarative parameter in an offer applies to media sent by the offerer, whereas a declarative parameter in an answer applies to media sent by the answerer.
オファー/アンサーモデルでは、セッションパラメータは交渉または宣言のいずれかです。特定のセッションパラメータの定義は、それらが交渉されているか宣言的であるかを示さなければなりません。ネゴシエートされたパラメーターは両方向に送信されるデータに適用されますが、宣言的パラメーターはSDPを生成したエンティティによって送信されたメディアにのみ適用されます。したがって、オファーの宣言パラメータはオファー側から送信されたメディアに適用されますが、回答の宣言型パラメータはアンサー側から送信されたメディアに適用されます。
This example shows use of the crypto attribute for the "RTP/SAVP" media transport type (as defined in Section 5). The "a=crypto" line is actually one long line; it is shown as two lines due to page formatting.
この例は、「RTP / SAVP」メディアトランスポートタイプ（セクション5で定義）の暗号属性の使用を示しています。 「a = crypto」行は実際には1つの長い行です。ページの書式設定により、2行で表示されます。
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 161.44.17.12/127
t=2873397496 2873404696
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=application 32416 udp wb
a=orient:portrait
This SDP message describes three media streams, two of which use the "RTP/SAVP" transport. Each has a crypto attribute for the "RTP/SAVP" transport. These secure-RTP specific descriptions are defined in Section 6.
このSDPメッセージは3つのメディアストリームを記述し、そのうちの2つは「RTP / SAVP」トランスポートを使用します。それぞれに「RTP / SAVP」トランスポートの暗号属性があります。これらのRTP固有の説明は、セクション6で定義されています。
In this section, we describe the general use of the crypto attribute outside of any transport or key-method specific rules.
このセクションでは、トランスポートまたはキーメソッド固有のルールの外側での暗号属性の一般的な使用について説明します。
The general offer/answer rules for the crypto attribute are in addition to the rules specified in RFC 3264, which MUST be followed, unless otherwise noted. RFC 3264 defines operation for both unicast and multicast streams; the sections below describe operation for two-party unicast streams only, since support for multicast streams (and multipoint unicast streams) is for further study.
クリプト属性の一般的なオファー/アンサールールは、RFC 3264で指定されているルールに追加されており、特に明記されていない限り従う必要があります。 RFC 3264は、ユニキャストストリームとマルチキャストストリームの両方の動作を定義しています。マルチキャストストリーム（およびマルチポイントユニキャストストリーム）のサポートは今後の検討課題であるため、以下のセクションでは2パーティのユニキャストストリームのみの操作について説明します。
When generating an initial offer for a unicast stream, there MUST be one or more crypto attributes present for each media stream for which security is desired. Each crypto attribute for a given media stream MUST contain a unique tag.
ユニキャストストリームの最初のオファーを生成するときは、セキュリティが必要な各メディアストリームに1つ以上の暗号属性が存在している必要があります。特定のメディアストリームの各暗号属性には、一意のタグを含める必要があります。
The ordering of multiple "a=crypto" lines is significant: the most preferred crypto line is listed first. Each crypto attribute describes the crypto-suite, key(s), and possibly session parameters offered for the media stream. In general, a "more preferred" crypto-suite SHOULD be cryptographically stronger than a "less preferred" crypto-suite.
複数の「a = crypto」行の順序は重要です。最も優先される暗号行が最初にリストされます。各暗号属性は、暗号スイート、キー、および場合によってはメディアストリームに提供されるセッションパラメータを記述します。一般に、「優先度の高い」暗号スイートは、「優先度の低い」暗号スイートよりも暗号学的に強力である必要があります（SHOULD）。
The crypto-suite always applies to media in the directions supported by the media stream (e.g., send and receive). The key(s), however, apply to data packets (e.g., SRTP and SRTCP packets) that will be sent by the same party that generated the SDP. That is, each endpoint determines its own transmission keys and sends those keys, in SDP, to the other endpoint.
暗号スイートは常に、メディアストリームでサポートされている方向（送信や受信など）のメディアに適用されます。ただし、キーは、SDPを生成したのと同じパーティによって送信されるデータパケット（SRTPパケットやSRTCPパケットなど）に適用されます。つまり、各エンドポイントは独自の送信キーを決定し、それらのキーをSDPで他のエンドポイントに送信します。
This is done for consistency. Also, in the case of SRTP, for example, secure RTCP will still be flowing in both the send and receive direction for a unidirectional stream.
これは一貫性を保つために行われます。また、たとえばSRTPの場合、セキュアなRTCPは、一方向ストリームの送信方向と受信方向の両方で引き続き流れます。
The inline parameter conveys the keying material used by an endpoint to encrypt the media streams transmitted by that endpoint. The same keying material is used by the recipient to decrypt those streams.
インラインパラメータは、エンドポイントが送信するメディアストリームを暗号化するためにエンドポイントが使用するキーイングマテリアルを伝達します。受信者はこれらのストリームを復号化するために同じキー情報を使用します。
The offer may include session parameters. There are no general offer rules for the session parameters; instead, specific rules may be provided as part of the transport-specific definitions of any session parameters.
オファーにはセッションパラメータが含まれる場合があります。セッションパラメータの一般的なオファールールはありません。代わりに、特定のルールを、セッションパラメータのトランスポート固有の定義の一部として提供できます。
When issuing an offer, the offerer MUST be prepared to support media security in accordance with any of the crypto attributes included in the offer. There are, however, two problems associated with this. First of all, the offerer does not know which key the answerer will be using for media sent to the offerer. Second, the offerer may not be able to deduce which of the offered crypto attributes were accepted. Since media may arrive prior to the answer, delay or clipping can occur. If this is unacceptable to the offerer, the offerer SHOULD use a mechanism outside the scope of this document to prevent the above problem.
オファーを発行する場合、オファーに含まれる暗号属性のいずれかに従って、メディアのセキュリティをサポートする準備を提供する必要があります。ただし、これに関連する2つの問題があります。まず第一に、提供者は、提供者に送信されるメディアに応答者が使用するキーを知りません。第二に、提供者は、提供された暗号属性のどれが受け入れられたかを推測できない場合があります。メディアは回答の前に到着する可能性があるため、遅延またはクリッピングが発生する可能性があります。これが提供者に受け入れられない場合、提供者はこのドキュメントの範囲外のメカニズムを使用して、上記の問題を回避する必要があります（SHOULD）。
For example, in SIP [RFC3261], a "security" precondition as defined in [sprecon] could solve the above problem.
たとえば、SIP [RFC3261]では、[sprecon]で定義されている「セキュリティ」前提条件で上記の問題を解決できます。
When the answerer receives the initial offer with one or more crypto attributes for a given unicast media stream, the answerer MUST either accept exactly one of the offered crypto attributes, or the offered stream MUST be rejected.
回答者が特定のユニキャストメディアストリームの1つ以上の暗号属性を持つ最初のオファーを受信した場合、回答者は提供された暗号属性の1つだけを受け入れるか、提供されたストリームを拒否する必要があります。
If the answerer wishes to indicate support for other crypto attributes, those can be listed by use of the SDP Simple Capability Declaration [RFC3407] extensions.
回答者が他の暗号属性のサポートを示したい場合は、SDP単純機能宣言[RFC3407]拡張を使用してそれらをリストできます。
Only crypto attributes that are valid can be accepted; valid attributes do not violate any of the general rules defined for security descriptions, nor any specific rules defined for the transport and key-method in question. When selecting one of the valid crypto attributes, the answerer SHOULD select the most preferred crypto attribute it can support, i.e., the first valid supported crypto attribute in the list, according to the answerer's capabilities and security policies.
有効な暗号属性のみを受け入れることができます。有効な属性は、セキュリティの説明に定義されている一般的なルールや、問題のトランスポートとキーメソッドに定義されている特定のルールに違反していません。有効な暗号属性の1つを選択する場合、回答者は、サポートできる最も好ましい暗号属性、つまり、回答者の機能とセキュリティポリシーに従って、リストで最初にサポートされる有効な暗号属性を選択する必要があります（SHOULD）。
If there are one or more crypto attributes in the offer, but none of them are valid or none of the valid ones are supported, the offered media stream MUST be rejected.
オファーに1つ以上の暗号属性があるが、それらのいずれも有効でないか、有効なものがサポートされていない場合、提供されたメディアストリームは拒否される必要があります。
When an offered crypto attribute is accepted, the crypto attribute in the answer MUST contain the following:
提供された暗号属性が受け入れられる場合、回答の暗号属性には以下が含まれている必要があります。
* The tag and crypto-suite from the accepted crypto attribute in the offer (the same crypto-suite MUST be used in the send and receive direction).
* オファーで受け入れられた暗号属性からのタグと暗号スイート（送信と受信の方向で同じ暗号スイートを使用する必要があります）。
* The key(s) the answerer will be using for media sent to the offerer. Note that a key MUST be provided, irrespective of any direction attributes in the offer or answer.
* 回答者が提供者に送信するメディアに使用するキー。オファーまたはアンサーの方向属性に関係なく、キーを提供する必要があることに注意してください。
Furthermore, any session parameters that are negotiated MUST be included in the answer. Declarative session parameters provided by the offerer are not included in the answer; however, the answerer may provide its own set of declarative session parameters.
さらに、ネゴシエートされるセッションパラメータはすべて回答に含める必要があります。提供者が提供する宣言的なセッションパラメータは回答に含まれていません。ただし、応答側は独自の宣言型セッションパラメータのセットを提供できます。
Once the answerer has accepted one of the offered crypto attributes, the answerer MAY begin sending media to the offerer in accordance with the selected crypto attribute. Note, however, that the offerer may not be able to process such media packets correctly until the answer has been received.
回答者が提供された暗号属性の1つを受け入れると、回答者は選択された暗号属性に従って提供者にメディアを送信し始めることができます。ただし、回答を受信するまで、提供者はそのようなメディアパケットを正しく処理できない場合があることに注意してください。
When the offerer receives the answer, the offerer MUST verify that one of the initially offered crypto suites and its accompanying tag were accepted and echoed in the answer. Also, the answer MUST include one or more keys, which will be used for media sent from the answerer to the offerer.
提案者が回答を受け取ったら、提供者は最初に提供された暗号スイートの1つとそれに付随するタグが受け入れられ、回答にエコーされたことを確認する必要があります。また、回答には1つ以上のキーを含める必要があります。これは、回答者から提供者に送信されるメディアに使用されます。
If the offer contained any mandatory negotiated session parameters (see Section 6.3.7), the offerer MUST verify that said parameters are included in the answer and support them. If the answer contains any mandatory declarative session parameters, the offerer MUST be able to support those.
オファーに必須の交渉済みセッションパラメータが含まれている場合（セクション6.3.7を参照）、オファー者は、上記のパラメータが回答に含まれていることを確認してサポートする必要があります。回答に必須の宣言型セッションパラメータが含まれている場合、提供者はそれらをサポートできる必要があります。
If any of the above fails, the negotiation MUST fail.
上記のいずれかが失敗した場合、ネゴシエーションは失敗する必要があります。
Once a media stream has been established, it MAY be modified at any time, as described in RFC 3264, Section 8. Such a modification MAY be triggered by the security service, e.g., in order to perform a re-keying or change the crypto-suite. If media stream security using the general security descriptions defined here is still desired, the crypto attribute MUST be included in these new offer/answer exchanges. The procedures are similar to those defined in Section 5.1.1, 5.1.2, and 5.1.3 of this document, subject to the considerations provided in RFC 3264, Section 8.
メディアストリームが確立されると、RFC 3264のセクション8に記載されているように、いつでも変更できます。このような変更は、セキュリティサービスによってトリガーされる場合があります（たとえば、再キーの実行や暗号の変更など）。 -スイート。ここで定義された一般的なセキュリティの説明を使用したメディアストリームセキュリティが引き続き必要な場合は、これらの新しいオファー/アンサー交換に暗号属性を含める必要があります。手順は、このドキュメントのセクション5.1.1、5.1.2、および5.1.3で定義されたものと同様ですが、RFC 3264のセクション8で提供される考慮事項に従います。
The crypto attribute can also be used outside the context of offer/answer where there is no negotiation of the crypto suite, cryptographic key, or session parameters. In this case, the sender determines security parameters for the stream. Since there is no negotiation mechanism, the sender MUST include exactly one crypto attribute, and the receiver MUST either accept it or SHOULD NOT receive the associated stream. The sender SHOULD select the security description that it deems most secure for its purposes.
暗号属性は、暗号スイート、暗号鍵、またはセッションパラメータのネゴシエーションがないオファー/アンサーのコンテキストの外でも使用できます。この場合、送信者はストリームのセキュリティパラメータを決定します。ネゴシエーションメカニズムがないため、送信者は厳密に1つの暗号属性を含める必要があり、受信者はそれを受け入れるか、関連するストリームを受信してはなりません（SHOULD NOT）。送信者は、その目的のために最も安全であると考えるセキュリティ記述を選択する必要があります（SHOULD）。
In the offer/answer model, it is possible that the answerer supports a given secure transport (e.g., "RTP/SAVP") and accepts the offered media stream, but that the answerer does not support the crypto attribute defined in this document and hence ignores it. The offerer can recognize this situation by seeing an accepted media stream in the answer that does not include a crypto line. In that case, the security negotiation defined here MUST fail.
オファー/アンサーモデルでは、アンサーが特定のセキュアトランスポート（例：「RTP / SAVP」）をサポートし、提供されたメディアストリームを受け入れるが、アンサーがこのドキュメントで定義されている暗号化属性をサポートしないため、それを無視します。オファーは、暗号化回線を含まない応答で受け入れられたメディアストリームを確認することで、この状況を認識できます。その場合、ここで定義されたセキュリティネゴシエーションは失敗する必要があります。
Similar issues exist when security descriptions are used outside the offer/answer model. But the source of a non-negotiated security description has no indication that the receiver has ignored the crypto attribute.
セキュリティの説明がオファー/アンサーモデルの外部で使用される場合にも、同様の問題が存在します。ただし、ネゴシエーションされていないセキュリティの説明のソースには、受信者が暗号属性を無視したことが示されていません。
In this section, we provide definitions for security descriptions for SRTP media streams. In the next section, we define how to use SRTP security descriptions with and without the offer/answer model.
このセクションでは、SRTPメディアストリームのセキュリティの説明の定義を示します。次のセクションでは、オファー/アンサーモデルがある場合とない場合のSRTPセキュリティ記述の使用方法を定義します。
SRTP security descriptions MUST only be used with the SRTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security descriptions for the "RTP/SAVP" profile, defined in [RFC3711]. However, it is expected that other secure RTP profiles (e.g., "RTP/SAVPF") can use the same descriptions, which are in accordance with the SRTP protocol specification [RFC3711].
SRTPセキュリティの説明は、SRTPトランスポートでのみ使用する必要があります（「RTP / SAVP」または「RTP / SAVPF」など）。以下は、[RFC3711]で定義されている「RTP / SAVP」プロファイルのセキュリティの説明を指定します。ただし、他の安全なRTPプロファイル（たとえば、「RTP / SAVPF」）は、SRTPプロトコル仕様[RFC3711]に準拠している同じ記述を使用できると予想されます。
There is no assurance that an endpoint is capable of configuring its SRTP service with a particular crypto attribute parameter, but SRTP guarantees minimal interoperability among SRTP endpoints through the default SRTP parameters [RFC3711]. More capable SRTP endpoints support a variety of parameter values beyond the SRTP defaults, and these values can be configured by the SRTP security descriptions defined here. An endpoint that does not support the crypto attribute will ignore it according to the SDP. Such an endpoint will not correctly process the particular media stream. By using the Offer/Answer model, the offerer and answerer can negotiate the crypto parameters to be used before commencement of the multimedia session (see Section 7.1).
エンドポイントが特定の暗号属性パラメーターを使用してSRTPサービスを構成できるという保証はありませんが、SRTPはデフォルトのSRTPパラメーター[RFC3711]を通じてSRTPエンドポイント間の最小限の相互運用性を保証します。より有能なSRTPエンドポイントは、SRTPのデフォルト以外のさまざまなパラメーター値をサポートします。これらの値は、ここで定義されているSRTPセキュリティの説明で構成できます。暗号属性をサポートしないエンドポイントは、SDPに従ってそれを無視します。このようなエンドポイントは、特定のメディアストリームを正しく処理しません。オファー/アンサーモデルを使用することにより、オファー側とアンサー側は、マルチメディアセッションの開始前に使用する暗号化パラメータをネゴシエートできます（セクション7.1を参照）。
There are over twenty cryptographic parameters listed in the SRTP specification. Many of these parameters have fixed values for particular cryptographic transforms. At the time of session establishment, however, there is usually no need to provide unique settings for many of the SRTP parameters, such as salt length and pseudo-random function (PRF). Thus, it is possible to simplify the list of parameters by defining "cryptographic suites" that fix a set of SRTP parameter values for the security session. This approach is followed by the SRTP security descriptions, which uses the general security description parameters as follows:
SRTP仕様には、20を超える暗号化パラメータがリストされています。これらのパラメータの多くには、特定の暗号化変換用の固定値があります。ただし、セッションの確立時には、通常、ソルト長や疑似ランダム関数（PRF）などのSRTPパラメータの多くに固有の設定を提供する必要はありません。したがって、セキュリティセッションのSRTPパラメータ値のセットを修正する「暗号スイート」を定義することにより、パラメータのリストを簡略化することが可能です。このアプローチの後には、次のような一般的なセキュリティの説明パラメータを使用するSRTPセキュリティの説明が続きます。
* crypto-suite: Identifies the encryption and authentication transforms. * key parameter: SRTP keying material and parameters * session parameters: The following parameters are defined: - KDR: The SRTP Key Derivation Rate is the rate at which a pseudo-random function is applied to a master key. - UNENCRYPTED_SRTP: SRTP messages are not encrypted. - UNENCRYPTED_SRTCP: SRTCP messages are not encrypted. - UNAUTHENTICATED_SRTP: SRTP messages are not authenticated. - FEC_ORDER: Order of forward error correction (FEC) relative to SRTP services. - FEC_KEY: Master Key for FEC when the FEC stream is sent to a separate address and/or port. - WSH: Window Size Hint. - Extensions: Extension parameters can be defined.
* crypto-suite：暗号化と認証の変換を識別します。 *鍵パラメーター：SRTP鍵材料とパラメーター*セッションパラメーター：次のパラメーターが定義されています。-KDR：SRTP鍵導出率は、擬似ランダム関数がマスター鍵に適用される速度です。 -UNENCRYPTED_SRTP：SRTPメッセージは暗号化されません。 -UNENCRYPTED_SRTCP：SRTCPメッセージは暗号化されません。 -UNAUTHENTICATED_SRTP：SRTPメッセージは認証されません。 -FEC_ORDER：SRTPサービスに関連する前方誤り訂正（FEC）の順序。 -FEC_KEY：FECストリームが別のアドレスやポートに送信される場合のFECのマスターキー。 -WSH：ウィンドウサイズのヒント。 -拡張：拡張パラメータを定義できます。
Please refer to the SRTP specification for a complete list of parameters and their descriptions [Section 8.2, srtp]. Regarding the UNENCRYPTED_SRTCP parameter, offerers and answerers of SDP security descriptions MUST NOT use the SRTCP E-bit to override UNENCRYPTED_SRTCP or the default, which is to encrypt all SRTCP messages (see Section 6.3.2). The key parameter, the crypto-suite, and the session parameters shown above are described in detail in the following subsections.
パラメータとその説明の完全なリストについては、SRTP仕様を参照してください[セクション8.2、srtp]。 UNENCRYPTED_SRTCPパラメータに関して、SDPセキュリティ記述の提供者と回答者は、SRTCP Eビットを使用してUNENCRYPTED_SRTCPまたはすべてのSRTCPメッセージを暗号化するデフォルトをオーバーライドしてはなりません（セクション6.3.2を参照）。上記のキーパラメータ、暗号スイート、およびセッションパラメータについては、次のサブセクションで詳しく説明します。
SRTP security descriptions define the use of the "inline" key method as described in the following. Use of any other keying method (e.g., URL) for SRTP security descriptions is for further study.
SRTPセキュリティの説明では、以下で説明する「インライン」キー方式の使用を定義しています。 SRTPセキュリティの説明に他のキーイング方法（URLなど）を使用することは、今後の検討課題です。
The "inline" type of key contains the keying material (master key and salt) and all policy related to that master key, including how long it can be used (lifetime) and whether it uses a master key identifier (MKI) to associate an incoming SRTP packet with a particular master key. Compliant implementations obey the policies associated with a master key and MUST NOT accept incoming packets that violate the policy (e.g., after the master key lifetime has expired).
「インライン」タイプのキーには、キー情報（マスターキーとソルト）と、そのマスターキーに関連するすべてのポリシーが含まれます。これには、キーの使用期間（ライフタイム）と、マスターキー識別子（MKI）を使用して特定のマスターキーを持つ着信SRTPパケット。準拠した実装は、マスターキーに関連付けられたポリシーに従い、ポリシーに違反する着信パケットを受け入れてはなりません（たとえば、マスターキーの有効期限が切れた後など）。
The key parameter contains one or more cryptographic master keys, each of which MUST be a unique cryptographically random [RFC1750] value with respect to other master keys in the entire SDP message (i.e., including master keys for other streams). Each key follows the format (the formal definition is provided in Section 9.2):
keyパラメーターには、1つ以上の暗号化マスターキーが含まれます。それぞれのキーは、SDPメッセージ全体（つまり、他のストリームのマスターキーを含む）の他のマスターキーに対して、暗号的にランダムな[RFC1750]の一意の値である必要があります。各キーは次の形式に従います（正式な定義はセクション9.2で提供されます）。
"inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]
key||salt concatenated master key and salt, base64 encoded (see [RFC3548], Section 3) lifetime master key lifetime (max number of SRTP or SRTCP packets using this master key) MKI:length MKI and length of the MKI field in SRTP packets
key || salt連結マスターキーとソルト、base64エンコード（[RFC3548]、セクション3を参照）ライフタイムマスターキーライフタイム（このマスターキーを使用するSRTPまたはSRTCPパケットの最大数）MKI：length MKIおよびSRTPのMKIフィールドの長さパケット
The following definition provides an example for AES_CM_128_HMAC_SHA1_80:
次の定義は、AES_CM_128_HMAC_SHA1_80の例を示しています。
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4
The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the parameter is the cryptographic master key appended with the master salt; the two are first concatenated and then base64 encoded. The length of the concatenated key and salt is determined by the crypto-suite for which the key applies. If the length (after being decoded from base64) does not match that specified for the crypto-suite, the crypto attribute in question MUST be considered invalid. Each master key and salt MUST be a cryptographically random number and MUST be unique to the entire SDP message. When base64 decoding the key and salt, padding characters (i.e., one or two "=" at the end of the base64-encoded data) are discarded (see [RFC3548] for details). Base64 encoding assumes that the base64 encoding input is an integral number of octets. If a given crypto-suite requires the use of a concatenated key and salt with a length that is not an integral number of octets, said crypto-suite MUST define a padding scheme that results in the base64 input being an integral number of octets. For example, if the length defined were 250 bits, then 6 padding bits would be needed, which could be defined to be the last 6 bits in a 256 bit input.
パラメーターの最初のフィールド（ "d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj"）は、マスターソルトが付加された暗号化マスターキーです。 2つは最初に連結され、次にbase64でエンコードされます。連結されたキーとソルトの長さは、キーが適用される暗号スイートによって決定されます。長さが（base64からデコードされた後）暗号スイートに指定されたものと一致しない場合、問題の暗号属性は無効と見なされなければなりません（MUST）。各マスターキーとソルトは、暗号化された乱数である必要があり、SDPメッセージ全体で一意である必要があります。 base64がキーとソルトをデコードするとき、パディング文字（つまり、base64でエンコードされたデータの最後にある1つまたは2つの「=」）は破棄されます（詳細は[RFC3548]を参照）。 Base64エンコーディングは、base64エンコーディング入力がオクテットの整数であると想定しています。特定の暗号スイートが、オクテットの整数ではない長さの連結キーとソルトの使用を必要とする場合、その暗号スイートは、base64入力がオクテットの整数となるパディングスキームを定義する必要があります。たとえば、定義された長さが250ビットの場合、6つのパディングビットが必要になります。これは、256ビット入力の最後の6ビットになるように定義できます。
The second field is the OPTIONAL lifetime of the master key as measured in maximum number of SRTP or SRTCP packets using that master key (i.e., the number of SRTP packets and the number of SRTCP packets each have to be less than the lifetime). The lifetime value MAY be written as a non-zero, positive decimal integer or as a power of 2 (see the grammar in Section 9.2 for details); leading zeroes MUST NOT be used. The "lifetime" value MUST NOT exceed the maximum packet lifetime for the crypto-suite. If the lifetime is too large or otherwise invalid, then the entire crypto attribute MUST be considered invalid. The default MAY be implicitly signaled by omitting the lifetime (note that the lifetime field never includes a colon, whereas the third field always does). This is convenient when the SRTP cryptographic key lifetime is the default value. As a shortcut to avoid long decimal values, the syntax of the lifetime allows using the literal "2^", which indicates "two to the power of". The example above shows a case where the lifetime is specified as 2^20. The following example, which is for the AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default for the lifetime field, which means that SRTP's and SRTCP's default values will be used (see [RFC3711]):
2番目のフィールドは、マスターキーを使用するSRTPまたはSRTCPパケットの最大数で測定されるマスターキーのオプションのライフタイムです（つまり、SRTPパケットの数とSRTCPパケットの数はそれぞれライフタイムよりも短くする必要があります）。ライフタイム値は、0以外の正の10進整数または2の累乗として書き込むことができます（詳細については、セクション9.2の文法を参照してください）。先行ゼロは使用してはなりません（MUST NOT）。 「ライフタイム」値は、クリプトスイートの最大パケットライフタイムを超えてはなりません。ライフタイムが長すぎるか、それ以外の場合は無効である場合、暗号属性全体が無効であると見なされる必要があります。デフォルトは、ライフタイムを省略することで暗黙的に通知される場合があります（3番目のフィールドには常にコロンが含まれるのに対し、ライフタイムフィールドにはコロンが含まれないことに注意してください）。これは、SRTP暗号鍵の有効期間がデフォルト値である場合に便利です。長い10進値を避けるためのショートカットとして、存続期間の構文では、「2の累乗」を示すリテラル「2 ^」を使用できます。上記の例は、ライフタイムが2 ^ 20に指定されている場合を示しています。次の例は、AES_CM_128_HMAC_SHA1_80暗号スイートの場合で、ライフタイムフィールドのデフォルトがあります。つまり、SRTPとSRTCPのデフォルト値が使用されます（[RFC3711]を参照）。
inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2|1066:4
インライン：YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2 | 1066：4
The example shows a 30-octet key and concatenated salt that is base64 encoded: The 30-octet key/salt concatenation is expanded to 40 characters (octets) by the three-in-four encoding of base64.
この例は、30オクテットのキーとbase64エンコードされた連結ソルトを示しています。30オクテットのキー/ソルト連結は、base64のスリーインフォーエンコーディングによって40文字（オクテット）に拡張されます。
The third field, which is also OPTIONAL, is the Master Key Identifier (MKI) and its byte length.
オプションでもある3番目のフィールドは、マスターキー識別子（MKI）とそのバイト長です。
"MKI" is the master key identifier associated with the SRTP master key. The MKI is here defined as a positive decimal integer that is encoded as a big-endian integer in the actual SRTP packets; leading zeroes MUST NOT be used in the integer representation. If the MKI is given, then the length of the MKI MUST also be given and separated from the MKI by a colon (":"). The MKI length is the size of the MKI field in the SRTP packet, specified in bytes as a decimal integer; leading zeroes MUST NOT be used. If the MKI length is not given or its value exceeds 128 (bytes), then the entire crypto attribute MUST be considered invalid. The substring "1:4" in the first example assigns to the key a master key identifier of 1 that is 4 bytes long, and the second example assigns a 4-byte master key identifier of 1066 to the key. One or more master keys with their associated MKI can be initially defined, and then later updated, or deleted and new ones defined.
「MKI」は、SRTPマスターキーに関連付けられたマスターキー識別子です。ここでMKIは、実際のSRTPパケットでビッグエンディアン整数としてエンコードされる正の10進整数として定義されます。整数表現で先行ゼロを使用してはなりません（MUST NOT）。 MKIを指定する場合は、MKIの長さも指定して、MKIとコロン（ "："）で区切る必要があります。 MKI長は、SRTPパケットのMKIフィールドのサイズで、10進整数としてバイト単位で指定されます。先行ゼロは使用してはなりません（MUST NOT）。 MKIの長さが指定されていない場合、またはその値が128（バイト）を超える場合は、暗号属性全体が無効であると見なす必要があります。最初の例の部分文字列「1：4」は、4バイト長の1のマスターキー識別子をキーに割り当て、2番目の例は、1066の4バイトマスターキー識別子をキーに割り当てます。 MKIが関連付けられた1つ以上のマスターキーを最初に定義してから、後で更新または削除して、新しいキーを定義できます。
SRTP offers a second feature for specifying the lifetime of a master key in terms of two values, called "From" and "To," which are defined on the SRTP sequence number space [RFC3711]. This SRTP Security Descriptions specification, however, does not support the <"From", "To"> feature since the lifetime of an AES master key is 2^48 SRTP packets, which means that there is no cryptographic reason to replace a master key for practical point-to-point applications. For this reason, there is no need to support two means for signaling key update. The MKI is chosen over <"From", "To"> by this specification for the very few applications that need it since the MKI feature is simpler (though the MKI adds additional bytes to each packet, whereas <"From", "To"> does not).
SRTPは、SRTPシーケンス番号スペース[RFC3711]で定義されている「From」と「To」という2つの値でマスターキーのライフタイムを指定するための2番目の機能を提供します。ただし、このSRTP Security Descriptions仕様では、AESマスターキーの有効期間が2 ^ 48 SRTPパケットであるため、<"From"、 "To">機能はサポートされていません。つまり、マスターキーを置き換える暗号的な理由はありません。実用的なポイントツーポイントアプリケーション。このため、キーの更新を通知する2つの手段をサポートする必要はありません。 MKI機能はより単純なので、MKIはこの仕様により、必要な非常に少数のアプリケーションのために<"From"、 "To">よりも選択されます（MKIは各パケットに追加のバイトを追加しますが、<"From"、 "To ">はしません）。
As mentioned above, the key parameter can contain one or more master keys. When the key parameter contains more than one master key, all the master keys in that key parameter MUST include an MKI value.
上記のように、keyパラメータには1つ以上のマスターキーを含めることができます。鍵パラメーターに複数のマスター鍵が含まれている場合、その鍵パラメーター内のすべてのマスター鍵にMKI値を含める必要があります。
When using the MKI, the MKI length MUST be the same for all keys in a given crypto attribute.
MKIを使用する場合、MKIの長さは、指定された暗号属性のすべてのキーで同じでなければなりません。
The SRTP crypto-suites define the encryption and authentication transforms to be used for the SRTP media stream. The SRTP specification has defined three crypto-suites, which are described further in the following subsections in the context of the SRTP security descriptions. The table below provides an overview of the crypto-suites and their parameters:
SRTP暗号スイートは、SRTPメディアストリームに使用される暗号化および認証変換を定義します。 SRTP仕様では3つの暗号スイートが定義されています。これについては、SRTPセキュリティの説明に関連して、次のサブセクションで詳しく説明します。次の表に、暗号スイートとそのパラメーターの概要を示します。
+---------------------+-------------+--------------+---------------+
| |AES_CM_128_ | AES_CM_128_ | F8_128_ |
| |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 |
+---------------------+-------------+--------------+---------------+
| Master key length | 128 bits | 128 bits | 128 bits |
| Master salt length | 112 bits | 112 bits | 112 bits |
| SRTP lifetime | 2^48 packets| 2^48 packets | 2^48 packets |
| SRTCP lifetime | 2^31 packets| 2^31 packets | 2^31 packets |
| Cipher | AES Counter | AES Counter | AES F8 Mode |
| | Mode | Mode | |
| Encryption key | 128 bits | 128 bits | 128 bits |
| MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 |
| SRTP auth. tag | 80 bits | 32 bits | 80 bits |
| SRTCP auth. tag | 80 bits | 80 bits | 80 bits |
| SRTP auth. key len. | 160 bits | 160 bits | 160 bits |
| SRTCP auth. key len.| 160 bits | 160 bits | 160 bits |
+---------------------+-------------+--------------+---------------+
AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher and HMAC-SHA1 message authentication with an 80-bit authentication tag. The master-key length is 128 bits and has a default lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first [Page 39, srtp].
AES_CM_128_HMAC_SHA1_80は、80ビット認証タグを使用したSRTPのデフォルトのAESカウンターモード暗号およびHMAC-SHA1メッセージ認証です。マスターキーの長さは128ビットで、デフォルトのライフタイムは最大で2 ^ 48 SRTPパケットまたは2 ^ 31 SRTCPパケットのいずれか早い方です[ページ39、srtp]。
SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first. However, it is RECOMMENDED that automated key management allow easy and efficient rekeying at intervals far smaller than 2^31 packets given today's media rates or even HDTV media rates.
SRTPは、2 ^ 48 SRTPパケットまたは2 ^ 31 SRTCPパケットのいずれか早い方を許可します。ただし、自動キー管理により、今日のメディアレートまたはHDTVメディアレートの場合でも、2 ^ 31パケットよりもはるかに小さい間隔で簡単かつ効率的な鍵の再生成が可能になることをお勧めします。
The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP and SRTCP authentication key lengths are 160 bits (see Security Considerations in Section 8). The master salt value is 112 bits in length and the session salt value is 112 bits in length. The pseudo-random function (PRF) is the default SRTP pseudo-random function that uses AES Counter Mode with a 128-bit key length.
SRTPおよびSRTCP暗号化キーの長さは128ビットです。 SRTPおよびSRTCP認証キーの長さは160ビットです（セクション8のセキュリティに関する考慮事項を参照）。マスターソルト値の長さは112ビットであり、セッションソルト値の長さは112ビットです。疑似ランダム関数（PRF）は、128ビットのキー長でAESカウンターモードを使用するデフォルトのSRTP疑似ランダム関数です。
The length of the base64-decoded key and salt value for this crypto-suite MUST be 30 characters (i.e., 240 bits); otherwise, the crypto attribute is considered invalid.
この暗号スイートのbase64でデコードされたキーとソルト値の長さは30文字（つまり、240ビット）でなければなりません。それ以外の場合、crypto属性は無効と見なされます。
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except that the authentication tag is 32 bits.
この暗号スイートは、認証タグが32ビットであることを除いて、AES_CM_128_HMAC_SHA1_80と同じです。
The length of the base64-decoded key and salt value for this crypto-suite MUST be 30 octets i.e., 240 bits; otherwise, the crypto attribute is considered invalid.
この暗号スイートのbase64でデコードされたキーとソルト値の長さは、30オクテット、つまり240ビットである必要があります。それ以外の場合、crypto属性は無効と見なされます。
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except that the cipher is F8 [RFC3711].
この暗号スイートは、暗号がF8 [RFC3711]であることを除いて、AES_CM_128_HMAC_SHA1_80と同じです。
The length of the base64-decoded key and salt value for this crypto-suite MUST be 30 octets, i.e., 240 bits; otherwise the crypto attribute is considered invalid.
この暗号スイートのbase64で復号化されたキーとソルト値の長さは、30オクテット、つまり240ビットである必要があります。それ以外の場合、暗号属性は無効と見なされます。
If new transforms are added to SRTP, new definitions for those transforms SHOULD be given for the SRTP security descriptions and published in a Standards-Track RFC. Sections 6.2.1 through 6.2.3 illustrate how to define crypto-suite values for particular cryptographic transforms. Any new crypto-suites MUST be registered with IANA following the procedures in Section 10.
SRTPに新しいトランスフォームが追加された場合、それらのトランスフォームの新しい定義をSRTPセキュリティの説明に指定し、Standards-Track RFCで公開する必要があります（SHOULD）。セクション6.2.1から6.2.3は、特定の暗号化変換の暗号スイート値を定義する方法を示しています。新しい暗号スイートは、セクション10の手順に従ってIANAに登録する必要があります。
SRTP security descriptions define a set of "session" parameters, which OPTIONALLY may be used to override SRTP session defaults for the SRTP and SRTCP streams. These parameters configure an RTP session for SRTP services. The session parameters provide session-specific information to establish the SRTP cryptographic context.
SRTPセキュリティ記述は、一連の「セッション」パラメータを定義します。これは、オプションで、SRTPおよびSRTCPストリームのSRTPセッションのデフォルトを上書きするために使用できます。これらのパラメーターは、SRTPサービスのRTPセッションを構成します。セッションパラメータは、SRTP暗号コンテキストを確立するためのセッション固有の情報を提供します。
KDR specifies the Key Derivation Rate, as described in Section 4.3.1 of [RFC3711].
[RFC3711]のセクション4.3.1で説明されているように、KDRは鍵導出率を指定します。
The value n MUST be a decimal integer in the set {1,2,...,24}, which denotes a power of 2 from 2^1 to 2^24, inclusive; leading zeroes MUST NOT be used. The SRTP key derivation rate controls how frequently a new session key is derived from an SRTP master key(s) [RFC3711] given in the declaration. When the key derivation rate is not specified (i.e., the KDR parameter is omitted), a single initial key derivation is performed [RFC3711].
値nは、セット{1,2、...、24}の10進整数である必要があります。これは、2 ^ 1から2 ^ 24までの2の累乗を表します。先行ゼロは使用してはなりません（MUST NOT）。 SRTPキーの導出率は、宣言で指定されたSRTPマスターキー[RFC3711]から新しいセッションキーが導出される頻度を制御します。鍵導出率が指定されていない場合（つまり、KDRパラメーターが省略されている場合）、単一の初期鍵導出が実行されます[RFC3711]。
In the offer/answer model, KDR is a declarative parameter.
オファー/アンサーモデルでは、KDRは宣言的なパラメーターです。
SRTP and SRTCP packet payloads are encrypted by default. The UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the default behavior of the crypto-suites with which they are used:
SRTPおよびSRTCPパケットのペイロードは、デフォルトで暗号化されています。 UNENCRYPTED_SRTCPおよびUNENCRYPTED_SRTPセッションパラメータは、それらが使用される暗号スイートのデフォルトの動作を変更します。
* UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not encrypted.
* UNENCRYPTED_SRTCPは、SRTCPパケットペイロードが暗号化されていないことを示します。
* UNENCRYPTED_SRTP signals that the SRTP packet payloads are not encrypted.
* UNENCRYPTED_SRTPは、SRTPパケットペイロードが暗号化されていないことを示します。
In the offer/answer model, these parameters are negotiated. If UNENCRYPTED_SRTCP is signaled for the session, then the SRTCP E bit MUST be clear (0) in all SRTCP messages. If the default is used, all SRTCP messages are encrypted, and the E bit MUST be set (1) on all SRTCP messages.
オファー/アンサーモデルでは、これらのパラメーターがネゴシエートされます。 UNENCRYPTED_SRTCPがセッションに対して通知される場合、SRTCP EビットはすべてのSRTCPメッセージでクリア（0）である必要があります。デフォルトが使用されている場合、すべてのSRTCPメッセージが暗号化され、すべてのSRTCPメッセージでEビットを設定（1）する必要があります。
SRTP and SRTCP packet payloads are authenticated by default. The UNAUTHENTICATED_SRTP session parameter signals that SRTP messages are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT RECOMMENDED (see Security Considerations).
SRTPおよびSRTCPパケットペイロードは、デフォルトで認証されます。 UNAUTHENTICATED_SRTPセッションパラメータは、SRTPメッセージが認証されていないことを示します。 UNAUTHENTICATED_SRTPの使用は推奨されていません（セキュリティに関する考慮事項を参照）。
The SRTP specification requires use of message authentication for SRTCP, but not for SRTP [RFC3711].
SRTP仕様では、SRTCPにはメッセージ認証を使用する必要がありますが、SRTP [RFC3711]には必要ありません。
In the offer/answer model, this parameter is negotiated.
オファー/アンサーモデルでは、このパラメーターはネゴシエートされます。
FEC_ORDER signals the use of forward error correction for the RTP packets [RFC2733]. The forward error correction values for "order" are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied before SRTP processing by the sender of the SRTP media and after SRTP processing by the receiver of the SRTP media; FEC_SRTP is the default. SRTP_FEC is the reverse processing.
FEC_ORDERは、RTPパケットの前方誤り訂正の使用を通知します[RFC2733]。 「order」の前方誤り訂正値はFEC_SRTPまたはSRTP_FECです。 FEC_SRTPは、SRTPメディアの送信者によるSRTP処理の前、およびSRTPメディアの受信者によるSRTP処理の後にFECが適用されることを通知します。 FEC_SRTPがデフォルトです。 SRTP_FECは逆の処理です。
In the offer/answer model, FEC_ORDER is a declarative parameter.
オファー/アンサーモデルでは、FEC_ORDERは宣言的なパラメーターです。
FEC_KEY signals the use of separate master key(s) for a Forward Error Correction (FEC) stream. The master key(s) are specified with the exact same format as the SRTP Key Parameter defined in Section 6.1, and the semantic rules are the same - in particular, the master key(s) MUST be different from all other master key(s) in the SDP. An FEC_KEY MUST be specified when the FEC stream is sent to a different IP-address and/or port than the media stream to which it applies (i.e., the "m=" line), e.g., as described in RFC 2733, Section 11.1. When an FEC stream is sent to the same IP-address and port as the media stream to which it applies, an FEC_KEY MUST NOT be specified. If an FEC_KEY is specified in this latter case, the crypto attribute in question MUST be considered invalid.
FEC_KEYは、Forward Error Correction（FEC）ストリーム用の個別のマスターキーの使用を通知します。マスターキーは、セクション6.1で定義されたSRTPキーパラメータとまったく同じ形式で指定され、セマンティックルールは同じです-特に、マスターキーは他のすべてのマスターキーとは異なる必要があります）SDP内。 FEC_KEYは、FECストリームが適用されるメディアストリーム（つまり、「m =」行）とは異なるIPアドレスまたはポート、あるいはその両方に送信される場合に指定する必要があります。 。 FECストリームが、それが適用されるメディアストリームと同じIPアドレスとポートに送信される場合、FEC_KEYを指定してはなりません（MUST NOT）。この後者のケースでFEC_KEYが指定されている場合、問題の暗号属性は無効と見なされなければなりません（MUST）。
In the offer/answer model, FEC_KEY is a declarative parameter.
オファー/アンサーモデルでは、FEC_KEYは宣言的なパラメーターです。
SRTP defines the SRTP-WINDOW-SIZE [RFC3711, Section 3.3.2] parameter to protect against replay attacks. The minimum value is 64 [RFC3711]; however, this value may be considered too low for some applications (e.g., video).
SRTPは、SRTP-WINDOW-SIZE [RFC3711、Section 3.3.2]パラメータを定義して、リプレイアタックから保護します。最小値は64 [RFC3711]です。ただし、この値は、一部のアプリケーション（ビデオなど）では低すぎると見なされる場合があります。
The Window Size Hint (WSH) session parameter provides a hint for how big this window should be to work satisfactorily (e.g., based on sender knowledge of the number of packets per second). However, there might be enough information given in SDP attributes like "a=maxprate" [maxprate] and the bandwidth modifiers to allow a receiver to derive the parameter satisfactorily. Consequently, this value is only considered a hint to the receiver of the SDP that MAY choose to ignore the value provided. The value is a decimal integer; leading zeroes MUST NOT be used.
ウィンドウサイズヒント（WSH）セッションパラメータは、このウィンドウが十分に機能するための大きさのヒントを提供します（たとえば、1秒あたりのパケット数に関する送信者の知識に基づく）。ただし、「a = maxprate」[maxprate]のようなSDP属性と帯域幅修飾子で指定された十分な情報があれば、レシーバーがパラメーターを適切に導出できます。したがって、この値は、提供された値を無視することを選択する可能性があるSDPの受信者へのヒントとのみ見なされます。値は10進整数です。先行ゼロは使用してはなりません（MUST NOT）。
In the offer/answer model, WSH is a declarative parameter.
オファー/アンサーモデルでは、WSHは宣言的なパラメーターです。
New SRTP session parameters for the SRTP security descriptions can be defined in a Standards-Track RFC and registered with IANA according to the registration procedures defined in Section 10.
SRTPセキュリティ記述の新しいSRTPセッションパラメータは、Standards-Track RFCで定義し、セクション10で定義された登録手順に従ってIANAに登録できます。
New SRTP session parameters are by default mandatory. A newly defined SRTP session parameter that is prefixed with the dash character ("-"), however, is considered optional and MAY be ignored. If an SDP crypto attribute is received with an unknown session parameter that is not prefixed with a "-" character, that crypto attribute MUST be considered invalid.
新しいSRTPセッションパラメータは、デフォルトでは必須です。ただし、ダッシュ文字（ "-"）が前に付いた新しく定義されたSRTPセッションパラメータはオプションと見なされ、無視される場合があります。 「-」文字が前に付いていない不明なセッションパラメータを使用してSDP暗号属性を受信した場合、その暗号属性は無効であると見なす必要があります。
In addition to the various SRTP parameters defined above, there are three pieces of information that are critical to the operation of the default SRTP ciphers:
上記で定義したさまざまなSRTPパラメータに加えて、デフォルトのSRTP暗号の操作に重要な3つの情報があります。
* SSRC: Synchronization source * ROC: Roll-over counter for a given SSRC * SEQ: Sequence number for a given SSRC
* SSRC：同期ソース* ROC：特定のSSRCのロールオーバーカウンター* SEQ：特定のSSRCのシーケンス番号
In a unicast session, as defined here, there are three constraints on these values.
ここで定義するユニキャストセッションでは、これらの値に3つの制約があります。
The first constraint is on the SSRC, which makes an SRTP keystream unique from other participants. As explained in SRTP, the keystream MUST NOT be reused on two or more different pieces of plaintext. Keystream reuse makes the ciphertext vulnerable to cryptanalysis. One vulnerability is that known-plaintext fields in one stream can expose portions of the reused keystream, and this could further expose more plaintext in other streams. Since all current SRTP encryption transforms use keystreams, key sharing is a general problem [RFC3711]. SRTP mitigates this problem by including the SSRC of the sender in the keystream. But SRTP does not solve this problem in its entirety because the Real-time Transport Protocol has SSRC collisions, which although very rare [RFC3550] are quite possible. During a collision, two or more SSRCs that share a master key will have identical keystreams for overlapping portions of the RTP sequence number space. SRTP Security Descriptions avoid keystream reuse by making unique master keys REQUIRED for the sender and receiver of the security description. Thus, the first constraint is satisfied.
最初の制約はSSRCにあり、SRTPキーストリームを他の参加者から一意にします。 SRTPで説明されているように、キーストリームは2つ以上の異なるプレーンテキストで再利用してはなりません（MUST NOT）。キーストリームの再利用により、暗号文は暗号解読に対して脆弱になります。 1つの脆弱性は、1つのストリームの既知の平文フィールドが再利用されたキーストリームの一部を公開する可能性があることです。これにより、他のストリームでさらに平文が公開される可能性があります。現在のすべてのSRTP暗号化トランスフォームはキーストリームを使用しているため、キー共有は一般的な問題です[RFC3711]。 SRTPは、送信者のSSRCをキーストリームに含めることでこの問題を軽減します。しかし、SRTPはこの問題を完全には解決しません。これは、リアルタイムトランスポートプロトコルにSSRCの衝突があるためです。これは非常にまれですが[RFC3550]可能です。衝突中に、マスターキーを共有する2つ以上のSSRCは、RTPシーケンス番号スペースの重複部分に対して同一のキーストリームを持ちます。 SRTPセキュリティ記述では、セキュリティ記述の送信者と受信者に一意のマスターキーを必須にすることで、キーストリームの再利用を回避します。したがって、最初の制約が満たされます。
Also note that there is a second problem with SSRC collisions: the SSRC is used to identify the crypto context and thereby the cipher, key, ROC, etc. to process incoming packets. In case of SSRC collisions, crypto context identification becomes ambiguous and correct packet processing may not occur. Furthermore, if an RTCP BYE packet is to be sent for a colliding SSRC, that packet may also have to be secured. In a (unicast) point-to-multipoint scenario, this can be problematic for the same reasons, i.e., it is not known which of the possible crypto contexts to use. Note that these problems are not unique to the SDP security descriptions; any use of SRTP needs to consider them.
また、SSRCの衝突には2つ目の問題があることに注意してください。SSRCは、暗号コンテキストを識別するために使用されるため、暗号、鍵、ROCなどを使用して着信パケットを処理します。 SSRC衝突の場合、暗号コンテキストの識別があいまいになり、正しいパケット処理が行われない可能性があります。さらに、衝突しているSSRCに対してRTCP BYEパケットが送信される場合、そのパケットも保護する必要がある場合があります。 （ユニキャスト）ポイントツーマルチポイントシナリオでは、これは同じ理由で問題となる可能性があります。つまり、どの暗号コンテキストを使用するか不明です。これらの問題はSDPセキュリティの説明に固有のものではないことに注意してください。 SRTPを使用する場合は、それらを考慮する必要があります。
The second constraint is that the ROC MUST be zero at the time that each SSRC commences sending packets. Thus, there is no concept of a "late joiner" in SRTP security descriptions, which are constrained to be unicast and pairwise. The ROC and SEQ form a "packet index" in the default SRTP transforms and the ROC is consistently set to zero at session commencement, according to this document.
2つ目の制約は、各SSRCがパケットの送信を開始する時点でROCがゼロである必要があることです。したがって、SRTPのセキュリティ記述には、ユニキャストおよびペアワイズに制限されている「遅延ジョイナー」の概念はありません。このドキュメントによると、ROCとSEQはデフォルトのSRTP変換で「パケットインデックス」を形成し、セッションの開始時にROCは常にゼロに設定されます。
The third constraint is that the initial value of SEQ SHOULD be chosen to be within the range of 0..2^15-1; this avoids an ambiguity when packets are lost at the start of the session. If it is at the start of a session, an SSRC source might randomly select a high sequence-number value and put the receiver in an ambiguous situation: if initial packets are lost in transit up to the point that the sequence number wraps (i.e., exceeds 2^16-1), then the receiver might not recognize that its ROC needs to be incremented. By restricting the initial SEQ to the range of 0..2^15-1, SRTP packet-index determination will find the correct ROC value, unless all the first 2^15 packets are lost (which seems, if not impossible, rather unlikely). See Section 3.3.1 of the SRTP specification regarding packet-index determination [RFC3711].
3番目の制約は、SEQの初期値が0..2 ^ 15-1の範囲内になるように選択する必要があることです。これにより、セッションの開始時にパケットが失われた場合のあいまいさが回避されます。セッションの開始時の場合、SSRCソースは高いシーケンス番号の値をランダムに選択して、あいまいな状況にする可能性があります。最初のパケットがシーケンス番号が折り返す点までの転送中に失われた場合（つまり、 2 ^ 16-1）を超える場合、受信者はROCをインクリメントする必要があることを認識しない可能性があります。最初のSEQを0..2 ^ 15-1の範囲に制限することにより、最初の2 ^ 15パケットがすべて失われない限り、SRTPパケットインデックスの決定は正しいROC値を見つけます（不可能ではないとしても、そうではないようです） ）。パケットインデックスの決定については、SRTP仕様のセクション3.3.1 [RFC3711]を参照してください。
The packet index, therefore, depends on the SSRC, the SEQ of an incoming packet, and the ROC, which is an SRTP crypto context variable. Thus, SRTP has a big security dependency on SSRC uniqueness.
したがって、パケットインデックスは、SSRC、着信パケットのSEQ、およびSRTP暗号コンテキスト変数であるROCに依存します。したがって、SRTPはSSRCの一意性に大きなセキュリティ依存関係を持っています。
Given the above constraints, unicast SRTP crypto contexts can be established without the need to negotiate SSRC values in the SRTP security descriptions. Instead, an approach called "late binding" is RECOMMENDED by this specification. When a packet arrives, the SSRC that is contained in it can be bound to the crypto context at the time of session commencement (i.e., SRTP packet arrival) rather than at the time of session signaling (i.e., receipt of an SDP). With the arrival of the packet containing the SSRC, all the data items needed for the SRTP crypto context are held by the receiver. (Note that the ROC value by definition is zero; if non-zero values were to be supported, additional signaling would be required.) In other words, the crypto context for a secure RTP session using late binding is initially identified by the SDP as
上記の制約がある場合、SRTPセキュリティの説明でSSRC値をネゴシエートする必要なく、ユニキャストSRTP暗号コンテキストを確立できます。代わりに、「遅延バインディング」と呼ばれるアプローチは、この仕様で推奨されています。パケットが到着すると、それに含まれるSSRCは、セッションシグナリング時（つまり、SDPの受信時）ではなく、セッション開始時（つまり、SRTPパケットの到着時）に暗号コンテキストにバインドできます。 SSRCを含むパケットが到着すると、SRTP暗号コンテキストに必要なすべてのデータ項目が受信者によって保持されます。 （定義によりROC値はゼロであることに注意してください。ゼロ以外の値がサポートされる場合、追加のシグナリングが必要になります。）つまり、遅延バインディングを使用するセキュアRTPセッションの暗号コンテキストは、最初にSDPによって次のように識別されます。
<*, address, port>
where '*' is a wildcard SSRC, "address" is the local receive address from the "c=" line, and "port" is the local receive port from the "m=" line. When the first packet arrives with ssrcX in its SSRC field, the crypto context
ここで、「*」はワイルドカードSSRC、「address」は「c =」行からのローカル受信アドレス、「port」は「m =」行からのローカル受信ポートです。最初のパケットがSSRCフィールドにssrcXとともに到着すると、暗号コンテキスト
<ssrcX, address, port>
<ssrcX、アドレス、ポート>
is instantiated subject to the following constraints:
次の制約に従ってインスタンス化されます。
* Media packets are authenticated: authentication MUST succeed; otherwise, the crypto context is not instantiated.
* メディアパケットが認証されます。認証は成功する必要があります。そうでない場合、暗号コンテキストはインスタンス化されません。
* Media packets are not authenticated: crypto context is automatically instantiated.
* メディアパケットは認証されません。暗号コンテキストが自動的にインスタンス化されます。
Note that use of late binding when there is no authentication of the SRTP media packets is subject to numerous security attacks, and that consequently it is NOT RECOMMENDED (of course, this can be said for unauthenticated SRTP in general).
SRTPメディアパケットの認証がない場合にレイトバインディングを使用すると、多数のセキュリティ攻撃の対象となるため、推奨されないことに注意してください（もちろん、これは一般に認証されていないSRTPについて言えることです）。
Note that use of late binding without authentication will result in the creation of local state as a result of receiving a packet from any unknown SSRC. UNAUTHENTICATED_SRTP, therefore, is NOT RECOMMENDED because it invites easy denial-of-service attack. In contrast, late binding with authentication does not suffer from this weakness.
認証なしでレイトバインディングを使用すると、不明なSSRCからパケットを受信した結果としてローカル状態が作成されることに注意してください。 UNAUTHENTICATED_SRTPは、簡単なサービス拒否攻撃を招くため、お勧めできません。対照的に、認証との遅延バインディングは、この弱点の影響を受けません。
With the constraints and procedures described above, it is not necessary to explicitly signal the SSRC, ROC, and SEQ for a unicast RTP session. So there are no a=crypto parameters for signaling SSRC, ROC, or SEQ. Thus, multiple SSRCs from the same entity will share a=crypto parameters when late binding is used. Multiple SSRCs from the same entity arise due to either multiple sources (microphones, cameras, etc.) or RTP payloads requiring SSRC multiplexing within that same session. SDP also allows multiple RTP sessions to be defined in the same media description ("m="); these RTP sessions will also share the a=crypto parameters. An application that uses a=crypto in this way serially shares a master key among RTP sessions or SSRCs and MUST replace the master key when the aggregate number of packets among all SSRCs approaches 2^31 packets. SSRCs that share a master key MUST be unique from one another.
上記の制約と手順を使用すると、ユニキャストRTPセッションのSSRC、ROC、およびSEQを明示的にシグナリングする必要はありません。したがって、SSRC、ROC、またはSEQをシグナリングするためのa = cryptoパラメータはありません。したがって、レイトバインディングが使用される場合、同じエンティティからの複数のSSRCはa = cryptoパラメーターを共有します。同じエンティティからの複数のSSRCは、複数のソース（マイク、カメラなど）またはRTPペイロードが同じセッション内でのSSRC多重化を必要とするために発生します。 SDPでは、同じメディア記述（ "m ="）で複数のRTPセッションを定義することもできます。これらのRTPセッションは、a = cryptoパラメータも共有します。この方法でa = cryptoを使用するアプリケーションは、RTPセッションまたはSSRC間でマスターキーをシリアルに共有し、すべてのSSRC間のパケットの総数が2 ^ 31パケットに近づいたときにマスターキーを置き換える必要があります。マスターキーを共有するSSRCは、互いに一意である必要があります。
The mechanism defined above addresses the issue of creating crypto contexts. However, in practice, session participants may want to remove crypto contexts prior to session termination. Since a crypto context contains information that cannot automatically be recovered (e.g., ROC), it is important that the sender and receiver agree on when a crypto context can be removed, and perhaps more importantly when it cannot.
上記で定義されたメカニズムは、暗号コンテキストの作成の問題に対処します。ただし、実際には、セッションの参加者は、セッションの終了前に暗号コンテキストを削除したい場合があります。暗号コンテキストには、自動的に復元できない情報（ROCなど）が含まれているため、送信者と受信者が暗号コンテキストをいつ削除できるかについて合意することが重要です。
Even when late binding is used for a unicast stream, the ROC is lost and cannot be recovered automatically (unless it is zero) once the crypto context is removed.
ユニキャストストリームにレイトバインディングが使用されている場合でも、暗号化コンテキストが削除されると、ROCは失われ、（ゼロでない限り）自動的に回復することはできません。
We resolve this problem as follows. When SRTP security descriptions are being used, crypto-context removal MUST follow the same rules as SSRC removal from the member table [RFC3550]; note that this can happen as the result of an SRTCP BYE packet or a simple time-out due to inactivity. Inactive session participants that wish to ensure their crypto contexts are not timed out MUST thus send SRTCP packets at regular intervals.
この問題は次のように解決します。 SRTPセキュリティ記述が使用されている場合、暗号コンテキストの削除は、メンバーテーブルからのSSRC削除[RFC3550]と同じルールに従う必要があります。これは、SRTCP BYEパケットの結果として、または非アクティブによる単純なタイムアウトの結果として発生する可能性があることに注意してください。したがって、暗号化コンテキストがタイムアウトしないようにする非アクティブなセッション参加者は、定期的にSRTCPパケットを送信する必要があります。
Section 5 describes general use of the crypto attribute, and this section completes it by describing SRTP-specific use.
セクション5では、crypto属性の一般的な使用法について説明します。このセクションでは、SRTP固有の使用法について説明して、属性を完成させます。
In this section, we describe how the SRTP security descriptions are used with the offer/answer model to negotiate cryptographic capabilities and communicate SRTP master keys. The rules defined below complement the general offer/answer rules defined in Section 5.1, which MUST be followed, unless otherwise specified. Note that the rules below define unicast operation only; support for multicast and multipoint unicast streams is for further study.
このセクションでは、オファー/アンサーモデルでSRTPセキュリティ記述を使用して、暗号化機能をネゴシエートし、SRTPマスターキーを通信する方法について説明します。以下に定義されている規則は、特に指定されていない限り、セクション5.1で定義されている一般的なオファー/アンサー規則を補足するものです。以下のルールはユニキャスト操作のみを定義することに注意してください。マルチキャストおよびマルチポイントユニキャストストリームのサポートは、今後の検討課題です。
When the initial offer is generated, the offerer MUST follow the steps in Section 5.1.1, as well as the following steps.
最初のオファーが生成されると、オファー者はセクション5.1.1のステップと以下のステップに従う必要があります。
For each unicast media line (m=) using the secure RTP transport where the offerer wants to specify cryptographic parameters, the offerer MUST provide at least one valid SRTP security description ("a=crypto" line), as defined in Section 6. If the media stream includes Forward
安全なRTPトランスポートを使用する各ユニキャストメディアライン（m =）について、オファー提供者が暗号パラメータを指定する場合、オファー提供者は、セクション6で定義されているように、少なくとも1つの有効なSRTPセキュリティ記述（ "a = crypto"ライン）を提供する必要があります。メディアストリームにはForwardが含まれます
Error Correction with a different IP-address and/or port from that of the media stream itself, an FEC_KEY parameter MUST be included, as described in Section 6.3.5.
セクション6.3.5で説明されているように、メディアストリーム自体のIPアドレスやポートとは異なるエラー修正には、FEC_KEYパラメータを含める必要があります。
The inline parameter conveys the SRTP master key used by an endpoint to encrypt the SRTP and SRTCP streams transmitted by that endpoint. The same key is used by the recipient to decrypt those streams. However, the receiver MUST NOT use that same key for the SRTP or SRTCP packets that it sends to the session because the default SRTP cipher and mode is insecure when the master key is reused across distinct SRTP streams.
インラインパラメータは、エンドポイントによって送信されるSRTPおよびSRTCPストリームを暗号化するためにエンドポイントによって使用されるSRTPマスターキーを伝達します。受信者はこれらのストリームを復号化するために同じキーを使用します。ただし、マスターキーが個別のSRTPストリームで再利用される場合、デフォルトのSRTP暗号とモードは安全ではないため、セッションに送信するSRTPまたはSRTCPパケットに同じキーを使用しないでください。
The offerer MAY include one or more other SRTP session parameters, as defined in Section 6.3. Note, however, that if any SRTP session parameters are included that are not known to the answerer, but that are nonetheless mandatory (see Section 6.3.6), the negotiation will fail if the answerer does not support them.
セクション6.3で定義されているように、提供者は1つ以上の他のSRTPセッションパラメータを含めることができます。ただし、回答者には知られていないが必須であるSRTPセッションパラメータが含まれている場合（セクション6.3.6を参照）、回答者がサポートしていない場合、ネゴシエーションは失敗します。
When the initial answer is generated, the answerer MUST follow the steps in Section 5.1.2, as well as the following steps.
最初の回答が生成されると、回答者はセクション5.1.2の手順と以下の手順に従う必要があります。
For each unicast media line that uses the secure RTP transport and contains one or more "a=crypto" lines in the offer, the answerer MUST either accept one (and only one) of the crypto lines for that media stream, or it MUST reject the media stream. Only "a=crypto" lines that are considered valid SRTP security descriptions, as defined in Section 6, can be accepted. Furthermore, all parameters (crypto-suite, key parameter, and mandatory session parameters) MUST be acceptable to the answerer in order for the offered media stream to be accepted. Note that if the media stream includes Forward Error Correction with a different IP-address and/or port from that of the media stream itself, an FEC_KEY parameter MUST be included, as described in Section 6.3.5.
安全なRTPトランスポートを使用し、オファーに「a = crypto」行が1つ以上含まれている各ユニキャストメディア回線について、回答者はそのメディアストリームの暗号化回線の1つ（および1つだけ）を受け入れるか、拒否する必要がありますメディアストリーム。セクション6で定義されているように、有効なSRTPセキュリティ記述と見なされる「a = crypto」行のみを受け入れることができます。さらに、提供されたメディアストリームが受け入れられるためには、すべてのパラメーター（暗号スイート、キーパラメーター、および必須のセッションパラメーター）が回答者に受け入れられる必要があります。メディアストリーム自体とは異なるIPアドレスまたはポート、あるいはその両方の転送エラー訂正がメディアストリームに含まれている場合は、セクション6.3.5で説明されているように、FEC_KEYパラメータを含める必要があります。
When the answerer accepts an SRTP unicast media stream with a crypto line, the answerer MUST include one or more master keys appropriate for the selected crypto algorithm; the master key(s) included in the answer MUST be different from those in the offer.
回答者が暗号化回線を含むSRTPユニキャストメディアストリームを受け入れる場合、回答者は選択した暗号化アルゴリズムに適した1つ以上のマスターキーを含める必要があります。回答に含まれるマスターキーは、オファーのマスターキーとは異なる必要があります。
When the master key(s) are not shared between the offerer and answerer, SSRC collisions between the offerer and answerer will not lead to keystream reuse, and hence SSRC collisions do not necessarily have to be prevented.
マスターキーが提供者と回答者の間で共有されていない場合、提供者と回答者の間のSSRC衝突はキーストリームの再利用につながらないため、必ずしもSSRC衝突を防止する必要はありません。
If Forward Error Correction to a separate IP-address and/or port is included, the answer MUST include an FEC_KEY parameter, as described in Section 6.3.5.
セクション6.3.5で説明されているように、別のIPアドレスやポートへのForward Error Correctionが含まれている場合、回答にはFEC_KEYパラメータを含める必要があります。
Declarative session parameters may be added to the answer as usual; however, the answerer SHOULD NOT add any mandatory session parameter (see Section 6.3.6) that might be unknown to the offerer.
宣言的なセッションパラメータを通常どおり回答に追加できます。ただし、回答者は、提供者に知られていない可能性がある必須のセッションパラメータ（セクション6.3.6を参照）を追加してはなりません（SHOULD NOT）。
If the answerer cannot find any valid crypto line that it supports, or if its configured policy prohibits any cryptographic key parameter (e.g., key length) or cryptographic session parameter (e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it is able to successfully negotiate use of SRTP by other means outside the scope of this document (e.g., by use of MIKEY [mikey]).
回答者がサポートする有効な暗号化回線を見つけられない場合、または構成されたポリシーが暗号化キーパラメーター（たとえば、キーの長さ）または暗号化セッションパラメーター（たとえば、KDR、FEC_ORDER）を禁止している場合、メディアストリームを拒否する必要があります。このドキュメントの範囲外のその他の手段（MIKEY [mikey]の使用など）でSRTPの使用を正常にネゴシエートできます。
When the offerer receives the answer, it MUST perform the steps in Section 5.1.3, as well as the following steps for each SRTP media stream it offered with one or more crypto lines in it.
オファーを受け取ったオファーは、セクション5.1.3の手順と、1つまたは複数の暗号ラインが含まれるSRTPメディアストリームごとに次の手順を実行する必要があります。
If the media stream was accepted and it contains a crypto line, it MUST be checked that the crypto line is valid according to the constraints specified in Section 6 (including any FEC constraints).
メディアストリームが受け入れられ、暗号化ラインが含まれている場合、暗号化ラインがセクション6で指定された制約（FEC制約を含む）に従って有効であることを確認する必要があります。
If the offerer either does not support or is not willing to honor one or more of the SRTP parameters in the answer, the offerer MUST consider the crypto line invalid.
提案者が回答の1つ以上のSRTPパラメータをサポートしていないか、それを受け入れる意思がない場合、提案者は暗号ラインを無効と見なさなければなりません（MUST）。
If the crypto line is not valid, or the offerer's configured policy prohibits any cryptographic key parameter (e.g., key length) or cryptographic session parameter, the SRTP security negotiation MUST be deemed to have failed.
暗号ラインが無効である場合、または提供者の構成されたポリシーが暗号キーパラメータ（たとえば、キーの長さ）または暗号セッションパラメータを禁止している場合、SRTPセキュリティネゴシエーションは失敗したと見なす必要があります。
When a media stream using the SRTP security descriptions has been established and a new offer/answer exchange is performed, the offerer and answerer MUST follow the steps in Section 5.1.4, as well as the following steps.
SRTPセキュリティ記述を使用するメディアストリームが確立され、新しいオファー/アンサー交換が実行された場合、オファー側とアンサー側は、セクション5.1.4の手順と以下の手順に従う必要があります。
When modifying the session, all negotiated aspects of the SRTP media stream can be modified. For example, a new crypto suite can be used or a new master key can be established. As described in RFC 3264, when a new offer/answer exchange is made, there will be a window of time where the offerer and the answerer must be prepared to receive media according to both the old and new offer/answer exchange.
セッションを変更すると、SRTPメディアストリームのすべてのネゴシエートされた側面を変更できます。たとえば、新しい暗号スイートを使用したり、新しいマスターキーを確立したりできます。 RFC 3264に記載されているように、新しいオファー/アンサー交換が行われるとき、新旧のオファー/アンサー交換の両方に従ってメディアを受信する準備が必要な時間帯があります。
This requirement applies here as well; however, the following should be noted:
この要件はここにも適用されます。ただし、次の点に注意してください。
* When authentication is not being used, it may not be possible for either the offerer or answerer to determine if a given packet is encrypted according to the old or new offer/answer exchange. RFC 3264 defines a couple of techniques to address this problem, e.g., changing the payload types used and/or the transport addresses. Note, however, that a change in transport addresses may have an impact on quality of service as well as on firewall and NAT traversal. The SRTP security descriptions use the MKI to deal with this (which adds a few bytes to each SRTP packet), as described in Section 6.1. For further details on the MKI, please refer to [RFC3711].
* 認証が使用されていない場合、提供者と回答者のどちらも、特定のパケットが新旧のオファー/アンサー交換に従って暗号化されているかどうかを判別できない可能性があります。 RFC 3264は、この問題に対処するためのいくつかの手法を定義しています。たとえば、使用されるペイロードタイプやトランスポートアドレスを変更します。ただし、トランスポートアドレスの変更は、サービス品質だけでなく、ファイアウォールやNATトラバーサルにも影響を与える可能性があることに注意してください。セクション6.1で説明されているように、SRTPセキュリティ記述はMKIを使用してこれを処理します（これにより、各SRTPパケットに数バイトが追加されます）。 MKIの詳細については、[RFC3711]を参照してください。
* If the answerer changes its master key, the offerer will not be able to process packets secured via this master key until the answer is received. This could be addressed by using a security "precondition" [sprecon].
* 回答者がマスターキーを変更すると、提供者は回答を受信するまで、このマスターキーを介して保護されたパケットを処理できなくなります。これは、セキュリティの「前提条件」[sprecon]を使用することで対処できます。
If the offerer includes an IP address and/or port that differs from that used previously for a media stream (or FEC stream), the offerer MUST include a new master key with the offer (and in so doing, it will be creating a new crypto context where the ROC is set to zero). Similarly, if the answerer includes an IP address and/or port that differs from that used previously for a media stream (or FEC stream), the answerer MUST include a new master key with the answer (and hence create a new crypto context with the ROC set to zero). The reason for this is that when the answerer receives an offer or the offerer receives an answer with an updated IP address and/or port, it is not possible to determine if the other side has access to the old crypto context parameters (and in particular the ROC). For example, if one side is a decomposed media gateway, or if a SIP back-to-back user agent is involved, it is possible that the media endpoint changed and no longer has access to the old crypto context. By always requiring a new master key in this case, the answerer/offerer will know that the ROC is zero for this offer/answer, and any key lifetime constraints will trivially be satisfied too. Another consideration here applies to media relays; if the relay changes the media endpoint on one side transparently to the other side, the relay cannot operate as a simple packet reflector but will have to actively engage in SRTP packet processing and transformation (i.e., decryption and re-encryption, etc.).
メディアストリーム（またはFECストリーム）に以前に使用されたものとは異なるIPアドレスやポートが提供者に含まれている場合、提供者は新しいマスターキーを提供に含める必要があります（そうすることで、新しいマスターキーが作成されますROCがゼロに設定されている暗号コンテキスト）。同様に、以前にメディアストリーム（またはFECストリーム）に使用されたものとは異なるIPアドレスやポートが回答者に含まれている場合、回答者は回答に新しいマスターキーを含める必要があります（したがって、 ROCはゼロに設定されます）。これは、回答者がオファーを受け取ったとき、または提供者が更新されたIPアドレスやポートを使用して回答を受け取ったときに、相手側が古い暗号コンテキストパラメータにアクセスできるかどうかを判断できないためです（特にROC）。たとえば、一方が分解されたメディアゲートウェイである場合、またはSIPバックツーバックユーザーエージェントが関係している場合、メディアエンドポイントが変更され、古い暗号コンテキストにアクセスできなくなる可能性があります。この場合、常に新しいマスターキーを要求することで、回答者/提供者はこのオファー/アンサーのROCがゼロであることを認識し、キーの有効期間の制約も簡単に満たされます。ここでのもう1つの考慮事項は、メディアリレーに適用されます。リレーが一方の側のメディアエンドポイントを透過的にもう一方の側に変更する場合、リレーは単純なパケットリフレクターとして動作できませんが、SRTPパケットの処理と変換（つまり、復号化と再暗号化など）に積極的に関与する必要があります。
Finally, note that if the new offer is rejected, the old crypto parameters remain in place.
最後に、新しいオファーが拒否された場合、古い暗号化パラメーターはそのまま残ります。
In this example, the offerer supports two crypto suites (f8 and AES). The a=crypto line is actually one long line, although it is shown as two lines in this document due to page formatting. The f8 example shows two inline parameters; as explained in Section 6.1, there may be one or more key (i.e., inline) parameters in a crypto attribute. In this way, multiple keys are offered to support key rotation using a Master Key Identifier (MKI).
この例では、提供者は2つの暗号スイート（f8とAES）をサポートしています。 a = crypto行は実際には1つの長い行ですが、ページの書式設定のため、このドキュメントでは2行として示されています。 f8の例は、2つのインラインパラメータを示しています。セクション6.1で説明したように、暗号属性には1つ以上のキー（つまり、インライン）パラメータがある場合があります。このように、マスターキー識別子（MKI）を使用したキーローテーションをサポートするために複数のキーが提供されます。
Offerer sends:
提供者は送信します：
v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=crypto:2 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
FEC_ORDER=FEC_SRTP
Answerer replies:
回答者の返信：
v=0
o=jill 25690844 8070842634 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=homer@example.com (Homer Simpson)
c=IN IP4 168.2.17.11
t=2873397526 2873405696
m=audio 32640 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
In this case, the session would use the AES_CM_128_HMAC_SHA1_80 crypto suite for the RTP and RTCP traffic. If F8_128_HMAC_SHA1_80 were selected by the answerer, there would be two inline keys associated with the SRTP cryptographic context. One key has an MKI value of 1 and the second has an MKI of 2.
この場合、セッションはRTPおよびRTCPトラフィックにAES_CM_128_HMAC_SHA1_80暗号スイートを使用します。 F8_128_HMAC_SHA1_80が回答者によって選択された場合、SRTP暗号化コンテキストに関連付けられた2つのインラインキーがあります。 1つのキーのMKI値は1で、2番目のキーのMKI値は2です。
Use of SRTP security descriptions outside the offer/answer model is not defined.
オファー/アンサーモデル外でのSRTPセキュリティ記述の使用は定義されていません。
Use of SRTP security descriptions outside the offer/answer model could have been defined for sendonly media streams; however, there would not be a way to indicate the key to use for SRTCP by the receiver of said media stream.
オファー/アンサーモデル以外のSRTPセキュリティ記述の使用は、sendonlyメディアストリームに対して定義されている可能性があります。ただし、前記メディアストリームの受信者がSRTCPに使用するキーを示す方法はありません。
As mentioned earlier, the security descriptions defined here do not support multicast media streams or multipoint unicast streams. However, in the SIP protocol, it is possible to receive several answers to a single offer due to the use of forking (see [SIP]). Receiving multiple answers leads to a couple of problems for the SRTP security descriptions:
前述のように、ここで定義されているセキュリティの説明は、マルチキャストメディアストリームまたはマルチポイントユニキャストストリームをサポートしていません。ただし、SIPプロトコルでは、フォークを使用するため、1つのオファーに対して複数の回答を受け取ることができます（[SIP]を参照）。複数の回答を受け取ると、SRTPセキュリティの説明でいくつかの問題が発生します。
* Different answerers may choose different ciphers, keys, etc.; however, there is no way for the offerer to associate a particular incoming media packet with a particular answer.
* 回答者が異なれば、異なる暗号、鍵などを選択できます。ただし、提供者が特定の着信メディアパケットを特定の回答に関連付ける方法はありません。
* Two or more answerers may pick the same SSRC, and hence the SSRC collision problems mentioned earlier may arise.
* 2人以上の回答者が同じSSRCを選択する可能性があるため、前述のSSRC衝突の問題が発生する可能性があります。
As stated earlier, the above point-to-multipoint cases are outside the scope of the SDP security descriptions. However, there are still ways of supporting SIP forking, e.g., by changing the multipoint scenario resulting from SIP forking into multiple two-party unicast cases. This can be done as follows:
前述のように、上記のポイントツーマルチポイントのケースは、SDPセキュリティの説明の範囲外です。ただし、SIPフォークから生じるマルチポイントシナリオを複数の2パーティユニキャストケースに変更するなど、SIPフォークをサポートする方法はまだあります。これは次のように実行できます。
For each answer received beyond the initial answer, issue a new offer to that particular answerer using a new receive transport address (IP address and port); note that this requires support for the SIP UPDATE method [RFC3311]. Also, to ensure that two media sessions are not inadvertently established prior to the UPDATE being processed by one of them, use security preconditions [sprecon].
最初の回答を超えて受け取った回答ごとに、新しい受信トランスポートアドレス（IPアドレスとポート）を使用して、その特定の回答者に新しいオファーを発行します。これには、SIP UPDATEメソッド[RFC3311]のサポートが必要であることに注意してください。また、2つのメディアセッションがUPDATEのいずれかによって処理される前に、誤って2つのメディアセッションが確立されないようにするには、セキュリティの前提条件[sprecon]を使用します。
Finally, note that all SIP User Agents that received the offer will know the key(s) being proposed by the initial offer. If the offerer wants to ensure security with respect to all other User Agents that may have received the offer, a new offer/answer exchange with a new key needs to be performed with the answerer as well. Note that the offerer cannot determine whether a single or multiple SIP User Agents received the offer, since intermediate forking proxies may only forward a single answer to the offerer.
最後に、オファーを受け取ったすべてのSIPユーザーエージェントは、最初のオファーによって提案されているキーを知っていることに注意してください。オファーを受け取った可能性のある他のすべてのユーザーエージェントに関してセキュリティを確保したい場合は、新しいキーとの新しいオファー/アンサー交換も、アンサーで実行する必要があります。中間分岐プロキシはオファーを1つの回答しか転送できないため、オファーが単一または複数のSIPユーザーエージェントがオファーを受信したかどうかを判断できないことに注意してください。
The above description is intended to suggest one possible way of supporting SIP forking. There are many details missing and it should not be considered a normative specification. Alternative approaches may also be possible
上記の説明は、SIPフォークをサポートする1つの可能な方法を提案することを目的としています。多くの詳細が欠落しており、規範的な仕様と見なすべきではありません。別のアプローチも可能かもしれません
It is possible that the answerer supports the SRTP transport and accepts the offered media stream, but that it does not support the crypto attribute defined here. The offerer can recognize this situation by seeing an accepted SRTP media stream in the answer that does not include a crypto line. In that case, the security negotiation defined here MUST be deemed to have failed.
応答側がSRTPトランスポートをサポートし、提供されたメディアストリームを受け入れることは可能ですが、ここで定義されている暗号化属性はサポートしていません。提供者は、暗号化回線を含まない応答で受け入れられたSRTPメディアストリームを確認することで、この状況を認識できます。その場合、ここで定義されたセキュリティネゴシエーションは失敗したと見なされます。
Also, if a media stream with a given SRTP transport (e.g., "RTP/SAVP") is sent to a device that does not support SRTP, that media stream will be rejected.
また、SRTPトランスポート（「RTP / SAVP」など）が指定されたメディアストリームがSRTPをサポートしていないデバイスに送信された場合、そのメディアストリームは拒否されます。
An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt]. Per SDP rules, the answerer will ignore attribute lines that it does not understand. If the answerer supports both "a=crypto" and "a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt", but not both, as including both is undefined.
オファーには、「a = crypto」と「a = keymgt」の両方の行を含めることができます[MAY]。 SDPルールに従って、解答者は理解できない属性行を無視します。回答者が「a = crypto」と「a = keymgt」の両方をサポートしている場合、回答には「a = crypto」または「a = keymgt」のいずれかを含める必要があります。
An offer MAY include both "a=crypto" and "k=" lines [RFC4566]. Per SDP rules, the answerer will ignore attribute lines it does not understand. If the answerer supports both "a=crypto" and "k=", the answer MUST include either "a=crypto" or "k=" but not both, as including both is undefined.
オファーには、「a = crypto」と「k =」の両方の行が含まれる場合があります[RFC4566]。 SDPルールに従って、解答者は理解できない属性行を無視します。回答者が "a = crypto"と "k ="の両方をサポートしている場合、回答には "a = crypto"または "k ="のいずれかを含める必要があります。両方を含めることは定義されていないためです。
Like all SDP messages, SDP messages containing security descriptions are conveyed in an encapsulating application protocol (e.g., SIP, MGCP). It is the responsibility of the encapsulating protocol to ensure the protection of the SDP security descriptions. Therefore, IT IS REQUIRED that the application invoke its own security mechanisms (e.g., secure multiparts such as S/MIME [smime]) or, alternatively, utilize a lower-layer security service (e.g., TLS or IPsec). IT IS REQUIRED that this security service provide strong message authentication and packet-payload encryption, as well as effective replay protection.
すべてのSDPメッセージと同様に、セキュリティの説明を含むSDPメッセージは、カプセル化アプリケーションプロトコル（SIP、MGCPなど）で伝達されます。 SDPセキュリティ記述の保護を確実にするのは、カプセル化プロトコルの責任です。したがって、アプリケーションは独自のセキュリティメカニズム（S / MIME [smime]などの安全なマルチパート）を呼び出すか、または下位層のセキュリティサービス（TLSやIPsecなど）を利用する必要があります。このセキュリティサービスは、強力なメッセージ認証とパケットペイロードの暗号化、および効果的なリプレイ保護を提供する必要があります。
"Replay protection" is needed against an attacker that has enough access to the communications channel to intercept messages and to deliver copies to the destination. A successful replay attack will cause the recipient to perform duplicate processing on a message; the attack is worse when the duped recipient sends a duplicate reply to the initiator. Replay protections are not found in S/MIME or in the other secure-multiparts standard, PGP/MIME. S/MIME and PGP/MIME, therefore, need to be augmented with some replay-protection mechanism that is appropriate to the encapsulating application protocol (e.g., SIP, MGCP). Three common ways to provide replay protection are to place a sequence number in the message, to use a timestamp, or for the receiver to keep a hash of the message to be compared with incoming messages. There typically needs to be a replay "window" and some policy for keeping state information from previous messages in a "replay table" or list.
「リプレイ保護」は、メッセージを傍受し、コピーを宛先に配信するために通信チャネルに十分にアクセスできる攻撃者に対して必要です。リプレイ攻撃が成功すると、受信者はメッセージに対して重複した処理を実行します。だまされた受信者が開始者に重複した応答を送信すると、攻撃はさらに悪化します。リプレイ保護は、S / MIMEまたは他のセキュアマルチパート標準であるPGP / MIMEにはありません。したがって、S / MIMEおよびPGP / MIMEは、カプセル化するアプリケーションプロトコル（SIP、MGCPなど）に適した再生保護メカニズムで補強する必要があります。再生保護を提供する3つの一般的な方法は、メッセージにシーケンス番号を配置すること、タイムスタンプを使用すること、または受信者が着信メッセージと比較するメッセージのハッシュを保持することです。通常、再生「ウィンドウ」と、「再生テーブル」またはリストに以前のメッセージの状態情報を保持するためのポリシーが必要です。
The discussion that follows uses "message authentication" and "message confidentiality" in a manner consistent with SRTP [RFC3711]. "Message confidentiality" means that only the holder of the secret decryption key can access the plain-text content of the message. The decryption key is the same key as the encryption key, using SRTP counter mode and f8 encryption transforms, which are vulnerable to message tampering and need SRTP message authentication to detect such tampering. "Message authentication" and "message integrity validation" generally mean the same thing in IETF security standards: an SRTP message is authenticated following a successful HMAC integrity check [RFC3711], which proves that the message originated from the holder of an SRTP master key and was not altered en route. Such an "authentic" message, however, can be captured by an attacker and "replayed" when the attacker re-inserts the packet into the channel. A replayed packet can have a variety of bad effects on the session, and SRTP uses the extended sequence number to detect replayed SRTP packets [RFC3711].
以下の議論では、SRTP [RFC3711]と一貫した方法で「メッセージ認証」と「メッセージ機密性」を使用します。 「メッセージの機密性」とは、秘密の復号化キーの所有者のみがメッセージの平文コンテンツにアクセスできることを意味します。復号化キーは、SRTPカウンターモードとf8暗号化トランスフォームを使用する暗号化キーと同じキーであり、メッセージの改ざんに対して脆弱であり、そのような改ざんを検出するにはSRTPメッセージ認証が必要です。 「メッセージ認証」と「メッセージ整合性検証」は、IETFセキュリティ標準で一般的に同じことを意味します。SRTPメッセージは、HTP整合性チェック[RFC3711]が成功した後に認証され、SRTPマスターキーの所有者と途中で変更されていません。ただし、このような「本物の」メッセージは攻撃者によってキャプチャされ、攻撃者がパケットをチャネルに再挿入したときに「再生」される可能性があります。再生されたパケットはセッションにさまざまな悪影響を与える可能性があり、SRTPは拡張シーケンス番号を使用して再生されたSRTPパケットを検出します[RFC3711]。
The SRTP specification identifies which services and features are default values that are normative-to-implement (such as AES_CM_128_80) versus normative-to-use (such as AES_CM_128_32).
SRTP仕様では、実装に規範的であるデフォルト値（AES_CM_128_80など）と使用に規範的である（AES_CM_128_32など）のデフォルト値となるサービスと機能を特定しています。
Security descriptions as defined herein signal security services for RTP packets. RTP messages are vulnerable to a variety of attacks, such as replay and forging. To limit these attacks, SRTP message integrity mechanisms SHOULD be used (SRTP replay protection is always enabled).
ここで定義されているセキュリティの説明は、RTPパケットのセキュリティサービスを示します。 RTPメッセージは、リプレイや偽造などのさまざまな攻撃に対して脆弱です。これらの攻撃を制限するには、SRTPメッセージ整合性メカニズムを使用する必要があります（SRTPリプレイ保護は常に有効です）。
SRTP security descriptions signal configuration parameters for SRTP sessions. Misconfigured SRTP sessions are vulnerable to attacks on their encryption services when running the crypto suites defined in Sections 6.2.1, 6.2.2, and 6.2.3. An SRTP encryption service is "misconfigured" when two or more media streams are encrypted using the same keystream of AES blocks. When senders and receivers share derived session keys, SRTP requires that the SSRCs of session participants serve to make their corresponding keystreams unique, which is violated in the case of SSRC collision: SRTP SSRC collision drastically weakens SRTP or SRTCP payload encryption during the time that identical keystreams are used [RFC3711]. An attacker, for example, might collect SRTP and SRTCP messages and await a collision. This attack on the AES-CM and AES-f8 encryption is avoided entirely when each media stream has its own unique master key in both the send and receive direction. This specification restricts use of SDP security description to unicast point-to-point streams so that keys are not shared between SRTP hosts, and the master keys used in the send and receive direction for a given media stream are unique.
SRTPセキュリティ記述は、SRTPセッションの構成パラメータを通知します。誤って構成されたSRTPセッションは、セクション6.2.1、6.2.2、および6.2.3で定義された暗号スイートを実行しているときに、暗号化サービスに対する攻撃に対して脆弱です。 2つ以上のメディアストリームがAESブロックの同じキーストリームを使用して暗号化されている場合、SRTP暗号化サービスは「誤設定」されます。送信者と受信者が派生セッションキーを共有する場合、SRTPは、セッション参加者のSSRCが対応するキーストリームを一意にするように機能することを要求します。これは、SSRC衝突の場合に違反します。キーストリームが使用されます[RFC3711]。たとえば、攻撃者はSRTPおよびSRTCPメッセージを収集し、衝突を待つ可能性があります。 AES-CMおよびAES-f8暗号化に対するこの攻撃は、各メディアストリームに送信方向と受信方向の両方で独自のマスターキーがある場合、完全に回避されます。この仕様は、SDPセキュリティ記述の使用をポイントツーポイントストリームのユニキャストに制限するため、キーはSRTPホスト間で共有されず、特定のメディアストリームの送受信方向で使用されるマスターキーは一意です。
There is no reason to incur the complexity and computational expense of SRTP, however, when its key establishment is exposed to unauthorized parties. In most cases, the SRTP crypto attribute and its parameters are vulnerable to denial-of-service attacks when they are carried in an unauthenticated SDP message. In some cases, the integrity or confidentiality of the RTP stream can be compromised. For example, if an attacker sets UNENCRYPTED for the SRTP stream in an offer, this could result in the answerer's not decrypting the encrypted SRTP messages. In the worst case, the answerer might itself send unencrypted SRTP and leave its data exposed to snooping.
ただし、SRTPのキーの確立が無許可のパーティに公開されている場合は、SRTPの複雑さと計算上の費用が発生する理由はありません。ほとんどの場合、SRTP暗号属性とそのパラメーターは、認証されていないSDPメッセージで伝送される場合、サービス拒否攻撃に対して脆弱です。場合によっては、RTPストリームの整合性または機密性が損なわれる可能性があります。たとえば、攻撃者がオファーのSRTPストリームにUNENCRYPTEDを設定すると、暗号化されたSRTPメッセージが解読されなくなる可能性があります。最悪の場合、回答者自身が暗号化されていないSRTPを送信し、そのデータがスヌーピングにさらされる可能性があります。
Thus, IT IS REQUIRED that MIME secure multiparts, IPsec, TLS, or some other data security service be used to provide message authentication for the encapsulating protocol that carries the SDP messages having a crypto attribute (a=crypto). Furthermore, IT IS REQUIRED that encryption of the encapsulating payload be used whenever a master key parameter (inline) appears in the message. Failure to encrypt the SDP message containing an inline SRTP master key renders the SRTP authentication or encryption service useless in practically all circumstances. Failure to authenticate an SDP message that carries SRTP parameters renders the SRTP authentication or encryption service useless in most practical applications.
したがって、MIMEセキュアマルチパート、IPsec、TLS、またはその他のデータセキュリティサービスを使用して、暗号化属性（a = crypto）を持つSDPメッセージを運ぶカプセル化プロトコルのメッセージ認証を提供する必要があります。さらに、マスターキーパラメーター（インライン）がメッセージに表示される場合は常に、カプセル化ペイロードの暗号化を使用する必要があります。インラインSRTPマスターキーを含むSDPメッセージの暗号化に失敗すると、SRTP認証または暗号化サービスが事実上すべての状況で役に立たなくなります。 SRTPパラメータを含むSDPメッセージの認証に失敗すると、SRTP認証または暗号化サービスがほとんどの実用的なアプリケーションで使用できなくなります。
When the communication path of the SDP message is routed through intermediate systems that inspect parts of the SDP message, security protocols such as [IPsec] or TLS SHOULD NOT be used for encrypting and/or authenticating the security description. In the case of intermediate-system processing of a message containing SDP security descriptions, the "a=crypto" attributes SHOULD be protected end-to-end so that the intermediate system can neither modify the security description nor access the keying material. Network or transport security protocols that terminate at each intermediate system, therefore, SHOULD NOT be used for protecting SDP security descriptions. A security protocol SHOULD allow the security descriptions to be encrypted and authenticated end-to-end independently of the portions of the SDP message that any intermediate system modifies or inspects: MIME secure multiparts are RECOMMENDED for the protection of SDP messages that are processed by intermediate systems.
SDPメッセージの通信経路がSDPメッセージの一部を検査する中間システムを経由する場合、[IPsec]やTLSなどのセキュリティプロトコルは、セキュリティの説明の暗号化や認証に使用してはなりません（SHOULD NOT）。 SDPセキュリティ記述を含むメッセージの中間システム処理の場合、「a = crypto」属性をエンドツーエンドで保護して、中間システムがセキュリティ記述を変更したり、キー情報にアクセスしたりできないようにする必要があります。したがって、各中間システムで終了するネットワークまたはトランスポートのセキュリティプロトコルは、SDPセキュリティ記述の保護には使用しないでください。セキュリティプロトコルは、中間システムが変更または検査するSDPメッセージの部分とは無関係に、セキュリティ記述をエンドツーエンドで暗号化および認証できるようにする必要があります（SHOULD）。システム。
In this section, we first provide the ABNF grammar for the generic crypto attribute, and then we provide the ABNF grammar for the SRTP-specific use of the crypto attribute.
このセクションでは、最初に一般的な暗号属性のABNF文法を提供し、次に暗号属性のSRTP固有の使用のためのABNF文法を提供します。
The ABNF grammar for the crypto attribute is defined below:
暗号属性のABNF文法を以下に定義します。
"a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
*(1*WSP session-param)
tag = 1*9DIGIT
crypto-suite = 1*(ALPHA / DIGIT / "_")
key-params = key-param *(";" key-param)
key-param = key-method ":" key-info
key-method = "inline" / key-method-ext
key-method-ext = 1*(ALPHA / DIGIT / "_")
key-info = 1*(%x21-3A / %x3C-7E) ; visible (printing) chars
; except semi-colon
session-param = 1*(VCHAR) ; visible (printing) characters
where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC4234].
ここで、WSP、ALPHA、DIGIT、およびVCHARは[RFC4234]で定義されています。
This section provides an Augmented BNF [RFC4234] grammar for the SRTP-specific use of the SDP crypto attribute:
このセクションでは、SDP暗号属性のSRTP固有の使用のための拡張BNF [RFC4234]文法を提供します。
crypto-suite = srtp-crypto-suite key-method = srtp-key-method key-info = srtp-key-info session-param = srtp-session-param
crypto-suite = srtp-crypto-suite key-method = srtp-key-method key-info = srtp-key-info session-param = srtp-session-param
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / "F8_128_HMAC_SHA1_32" /
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / "F8_128_HMAC_SHA1_32" /
"AES_CM_128_HMAC_SHA1_80" / srtp-crypto-suite-ext
"AES_CM_128_HMAC_SHA1_80" / srtp-crypto-suite-ext
srtp-key-method = "inline" srtp-key-info = key-salt ["|" lifetime] ["|" mki]
srtp-key-method = "インライン" srtp-key-info = key-salt ["|"寿命] ["|" mki]
key-salt = 1*(base64) ; binary key and salt values
; concatenated together, and then
; base64 encoded [section 3 of
; RFC3548
lifetime = ["2^"] 1*(DIGIT) ; see section 6.1 for "2^"
mki = mki-value ":" mki-length
mki-value = 1*DIGIT
mki-length = 1*3DIGIT ; range 1..128.
srtp-session-param = kdr / "UNENCRYPTED_SRTP" / "UNENCRYPTED_SRTCP" / "UNAUTHENTICATED_SRTP" / fec-order / fec-key / wsh / srtp-session-extension
srtp-session-param = kdr / "UNENCRYPTED_SRTP" / "UNENCRYPTED_SRTCP" / "UNAUTHENTICATED_SRTP" / fec-order / fec-key / wsh / srtp-session-extension
kdr = "KDR=" 1*2(DIGIT) ; range 0..24,
; power of two
fec-order = "FEC_ORDER=" fec-type
fec-type = "FEC_SRTP" / "SRTP_FEC"
fec-key = "FEC_KEY=" key-params
wsh = "WSH=" 2*DIGIT ; minimum value is 64
base64 = ALPHA / DIGIT / "+" / "/" / "="
srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_")
srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC4234]
; first character must not be dash ("-")
The IANA has registered a new SDP attribute as follows:
IANAは、次のように新しいSDP属性を登録しました。
Attribute name: crypto Long form name: Security description cryptographic attribute for media streams Type of attribute: Media-level Subject to charset: No Purpose: Security descriptions Appropriate values: See Section 4
属性名：暗号長い形式名：メディアストリームのセキュリティの説明暗号化属性属性のタイプ：メディアレベル文字セットの対象：いいえ目的：セキュリティの説明適切な値：セクション4を参照
The following sub-sections define a new IANA registry with associated sub-registries to be used for the SDP security descriptions. The IANA has created an SDP Security Description registry as shown below and further described in the following sections:
次のサブセクションでは、SDPセキュリティの説明に使用されるサブレジストリが関連付けられた新しいIANAレジストリを定義します。 IANAは、以下に示すように、さらに次のセクションで説明するように、SDPセキュリティ記述レジストリを作成しました。
SDP Security Descriptions
|
+- Key Methods (described in 10.2.1)
|
+- Media Stream Transports (described in 10.2.2)
|
+- Transport1 (e.g., SRTP)
| |
| +- Supported Key Methods (e.g., inline)
| |
| +- crypto suites
| |
| +- session parameters
|
+- Transport2
: :
The IANA has created a new subregistry for SDP security description key methods. An IANA key method registration MUST be documented in an RFC in accordance with the [RFC2434] Standards Action, and it MUST provide the name of the key method in accordance with the grammar for key-method-ext defined in Section 9.1.
IANAは、SDPセキュリティ記述キーメソッド用の新しいサブレジストリを作成しました。 IANA鍵メソッド登録は、[RFC2434]標準アクションに従ってRFCに文書化する必要があり、セクション9.1で定義されているkey-method-extの文法に従って鍵メソッドの名前を提供する必要があります。
The IANA has created a new subregistry for SDP security description Media Stream Transports. An IANA media stream transport registration MUST be documented in an RFC in accordance with the RFC 2434 Standards Action and the procedures defined in Sections 4 and 5 of this document. The registration MUST provide the name of the transport and a list of supported key methods.
IANAは、SDPセキュリティ記述Media Stream Transportsの新しいサブレジストリを作成しました。 IANAメディアストリームトランスポート登録は、RFC 2434標準アクションと、このドキュメントのセクション4と5で定義されている手順に従って、RFCで文書化されている必要があります。登録では、トランスポートの名前とサポートされている主要なメソッドのリストを提供する必要があります。
In addition, each new media stream transport registry must contain a crypto-suite registry and a session parameter registry, as well as IANA instructions for how to populate these registries.
さらに、新しい各メディアストリームトランスポートレジストリには、暗号スイートレジストリとセッションパラメータレジストリ、およびこれらのレジストリを設定する方法に関するIANA指示が含まれている必要があります。
The following security descriptions key methods are hereby registered:
これにより、次のセキュリティ記述キーメソッドが登録されます。
inline
列をなして
The IANA has created an SDP Security Description Media Stream Transport subregistry for "SRTP". The key methods supported is "inline". The reference for the SDP security description for SRTP is this document.
IANAは、「SRTP」用のSDPセキュリティ記述メディアストリームトランスポートサブレジストリを作成しました。サポートされている主要なメソッドは「インライン」です。 SRTPのSDPセキュリティ記述のリファレンスはこのドキュメントです。
The IANA has created a new subregistry for SRTP crypto suites under the SRTP transport of the SDP Security Descriptions. An IANA SRTP crypto suite registration MUST indicate the crypto suite name in accordance with the grammar for srtp-crypto-suite-ext defined in Section 9.2.
IANAは、SDPセキュリティ記述のSRTPトランスポートの下にSRTP暗号スイートの新しいサブレジストリを作成しました。 IANA SRTP暗号スイート登録は、セクション9.2で定義されたsrtp-crypto-suite-extの文法に従って暗号スイート名を示さなければなりません（MUST）。
The semantics of the SRTP crypto suite MUST be described in an RFC in accordance with the RFC 2434 Standards Action, including the semantics of the "inline" key-method and any special semantics of parameters.
SRTP暗号スイートのセマンティクスは、「インライン」キー方式のセマンティクスとパラメーターの特別なセマンティクスを含め、RFC 2434標準アクションに従ってRFCに記述されている必要があります。
The following SRTP crypto suites are hereby registered:
これにより、次のSRTP暗号スイートが登録されます。
AES_CM_128_HMAC_SHA1_80 AES_CM_128_HMAC_SHA1_32 F8_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_80 AES_CM_128_HMAC_SHA1_32 F8_128_HMAC_SHA1_80
The reference for these crypto suites is provided in this document.
これらの暗号スイートのリファレンスは、このドキュメントで提供されています。
The IANA has created a new subregistry for SRTP session parameters under the SRTP transport of the SDP Security Descriptions. An IANA SRTP session parameter registration MUST indicate the session parameter name (srtp-session-extension as defined in Section 9.2); the name MUST NOT begin with the dash character ("-").
IANAは、SDPセキュリティ記述のSRTPトランスポートの下にSRTPセッションパラメータの新しいサブレジストリを作成しました。 IANA SRTPセッションパラメータ登録は、セッションパラメータ名（セクション9.2で定義されているsrtp-session-extension）を示さなければならない（MUST）。名前はダッシュ文字（ "-"）で始めてはいけません。
The semantics of the parameter MUST be described in an RFC in accordance with the RFC 2434 Standards Action. If values can be assigned to the parameter, then the format and possible values that can be assigned MUST be described in the RFC in accordance with the RFC 2434 Standards Action as well. Also, it MUST be specified whether the parameter is declarative or negotiated in the offer/answer model.
パラメータのセマンティクスは、RFC 2434標準アクションに従ってRFCに記述されている必要があります。パラメータに値を割り当てることができる場合は、RFC 2434標準アクションに従って、割り当てることができる形式と可能な値をRFCに記載する必要があります。また、パラメーターが宣言的であるか、オファー/アンサーモデルで交渉されるかを指定する必要があります。
The following SRTP session parameters are hereby registered:
これにより、次のSRTPセッションパラメータが登録されます。
KDR UNENCRYPTED_SRTP UNENCRYPTED_SRTCP UNAUTHENTICATED_SRTP FEC_ORDER FEC_KEY WSH
KDR UNENCRYPTED_SRTP UNENCRYPTED_SRTCP UNAUTHENTICATED_SRTP FEC_ORDER FEC_KEY WSH
The reference for these parameters is this document.
これらのパラメータのリファレンスはこのドキュメントです。
This document is a product of the IETF MMUSIC working group and has benefited from comments from its participants. This document also benefited from discussions with Elisabetta Cararra, Earl Carter, Per Cederqvist, Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer, Mike Thomas, Brian Weis, and Magnus Westerlund.
このドキュメントはIETF MMUSICワーキンググループの製品であり、その参加者からのコメントの恩恵を受けています。このドキュメントは、エリザベッタカララ、アールカーター、パーセダークヴィスト、ビルフォスター、マットハマー、カレンジェニングス、ポールキジバット、デビッドマクルー、マットナスランド、デイブオラン、ジョナサンローゼンバーグ、デイブシンガー、マイクトーマス、ブライアンワイス、マグナスウェスタールンド。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[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月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 4234、2005年10月。
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[RFC2828] Shirey、R。、「インターネットセキュリティ用語集」、FYI 36、RFC 2828、2000年5月。
[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月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake 3rd、D.、Crocker、S。、およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[RFC3548] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 3548、2003年7月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[sprecon] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol Media Streams", Work in Progress, October 2005.
[sprecon] Andreasen、F。およびD. Wing、「Session Description Protocol Media Streamsのセキュリティ前提条件」、Work in Progress、2005年10月。
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002.
[RFC3407] Andreasen、F。、「Session Description Protocol（SDP）Simple Capability Declaration」、RFC 3407、2002年10月。
[Bellovin] Bellovin, S., "Problem Areas for the IP Security Protocols," in Proceedings of the Sixth Usenix Unix Security Symposium, pp. 1-16, San Jose, CA, July 1996.
[Bellovin] Bellovin、S。、「Proceedings of the Sixth Usenix Unix Security Symposium、pp。1-16、San Jose、CA、July 1996」の「IPセキュリティプロトコルの問題領域」。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[GDOI]バウアーM.、ワイスB.、ハードジョノT.、およびH.ハーニー、「解釈のグループドメイン」、RFC 3547、2003年7月。
[kink] Sakane, S., Kamada, K., Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
[kink] Sakane、S.、Kamada、K.、Thomas、M. and J. Vilhuber、 "Kerberized Internet Negotiation of Keys（KINK）"、RFC 4430、March 2006。
[ike] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[ike] Kaufman、C。、「インターネットキーエクスチェンジ（IKEv2）プロトコル」、RFC 4306、2005年12月。
[ipsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[ipsec] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[maxprate] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[maxprate] Westerlund、M。、「Session Description Protocol（SDP）のトランスポート非依存帯域幅修飾子」、RFC 3890、2004年9月。
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[RFC2733] Rosenberg、J。およびH. Schulzrinne、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 2733、1999年12月。
[s/mime] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[s / mime] Ramsdell、B。、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.1 Message Specification」、RFC 3851、2004年7月。
[pgp/mime] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[pgp / mime] Elkins、M。、「Pretty Good Privacy（PGP）によるMIMEセキュリティ」、RFC 2015、1996年10月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[keymgt] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[keymgt] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M.、and K. Norrman、 "Key Management Extensions for Session Description Protocol（SDP）and Real Time Streaming Protocol（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.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「MIKEY：Multimedia Internet KEYing」、RFC 3830、2004年8月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[skeme] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for the Internet", ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996.
[skeme] Krawczyk、H。、「SKEME：A Versatile Secure Key Exchange Mechanism for the Internet」、ISOC Secure Networks and Distributed Systems Symposium、San Diego、1996。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「Integration of Resource Management and Session Initiation Protocol（SIP）」、RFC 3312、2002年10月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、2000年10月。
[srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003.
[srtpf] Ott、J。およびE. Carrara、「RTCPベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、2003年10月に進行中。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002.
[RFC3311] Rosenberg、J。、「セッション開始プロトコル（SIP）UPDATEメソッド」、RFC 3311、2002年9月。
Appendix A - Rationale for Keying Material Directionality
付録A-マテリアルの方向性をキーイングする根拠
SDP security descriptions define the keying material for the sending direction, which is included in the SDP. Thus, the key that is carried in an SDP message is a decryption key for the receiver of that SDP message. This is in contrast to the majority of information included in SDP, which describes information for the receiving (or receiving and sending) direction. This reversed information directionality generates some challenges with using the mechanism in the offer/answer model and in particular with SIP, where early media and forking require special consideration (as described in Section 7.3). There are however good reasons for why this was done, which can be summarized as follows:
SDPセキュリティ記述は、SDPに含まれている送信方向のキー情報を定義します。したがって、SDPメッセージで伝送されるキーは、そのSDPメッセージの受信者の復号化キーです。これは、受信（または受信と送信）方向の情報を記述するSDPに含まれる大部分の情報とは対照的です。この情報の方向性が逆になると、オファー/アンサーモデルのメカニズムを使用して、特にSIPでいくつかの課題が発生します。SIPでは、初期のメディアとフォークに特別な考慮が必要です（7.3で説明）。ただし、これが行われたのには正当な理由があり、次のように要約できます。
First of all, there is the general security philosophy of letting the entity that sends traffic decide what key to use for protecting it. SRTP uses counter mode, which is secure when counters do not overlap among senders who share a master key; the surest way to avoid counter overlap is for each endpoint to generate its own master key. Secondly, if SDP security descriptions had been designed to keep the normal SDP information directionality, it would have resulted in problems with supporting early media and SIP forking: If an offer generates multiple answers and the keying material was for the receive direction, some of the parameter values (e.g. lifetime) would have to be shared between all the answerers (senders of media), which would lead to considerable complexity, possibly requiring changes or extensions to SRTP. Other problems were discovered as well, which we describe further below.
まず、トラフィックを送信するエンティティに、それを保護するために使用するキーを決定させるという一般的なセキュリティの考え方があります。 SRTPはカウンターモードを使用します。これは、マスターキーを共有する送信者間でカウンターが重複しない場合に安全です。カウンタのオーバーラップを回避する最も確実な方法は、各エンドポイントが独自のマスターキーを生成することです。次に、SDPセキュリティ記述が通常のSDP情報の方向性を維持するように設計されていた場合、初期のメディアとSIPフォークのサポートに問題が発生することになります。オファーが複数の回答を生成し、キー情報が受信方向である場合、パラメータ値（ライフタイムなど）はすべての回答者（メディアの送信者）間で共有する必要があり、かなり複雑になり、SRTPの変更または拡張が必要になる可能性があります。他の問題も発見されましたが、これについては以下で詳しく説明します。
In the following scenarios, we analyze what would occur if SDP security descriptions had been designed so that the keying material was the receive keying material (rather than its actual design, where the keying material is the sending keying material): Scenario A: Non-Forking Case
次のシナリオでは、SDPセキュリティ記述がキーイングマテリアルが受信キーイングマテリアルになるように設計された場合に発生することを分析します（実際の設計ではなく、キーイングマテリアルは送信キーイングマテリアルです）：シナリオA：非フォークケース
In this scenario, the offer includes the receiving keying material, the answerer receives it and starts sending data packets towards the offerer. If there was a single crypto attribute in the offer, there would be no ambiguity about which crypto suite was being used and, hence, the incoming packet could be processed. However, in the case where the offer included multiple alternative crypto-attributes, the offerer would not know which one was chosen, and hence, if the offerer received packets before the answer came back, the offerer would be unable to process those packets (problem 1). (Use of the MKI has been suggested as one possible solution to that, however it incurs a per-packet overhead.)
このシナリオでは、オファーに受信キーイングマテリアルが含まれ、アンサーがそれを受信して、データパケットをオファーャーに向けて送信し始めます。オファーに単一の暗号属性があった場合、どの暗号スイートが使用されているかについての曖昧さはなく、したがって、着信パケットを処理できます。ただし、オファーに複数の代替暗号属性が含まれている場合、提供者はどちらが選択されたかを認識しないため、回答が返される前に提供者がパケットを受信した場合、提供者はそれらのパケットを処理できません（問題） 1）。 （MKIの使用はその解決策の1つとして提案されていますが、パケットごとのオーバーヘッドが発生します。）
Scenario B: Serial Forking Case
シナリオB：シリアル分岐のケース
In this scenario, Alice generates an offer to Bob, who starts sending (early) media towards Alice (no answer returned yet). In this scenario, we assume we aren't also encountering Scenario A (e.g., the offer includes only a single crypto-attribute) and that Bob is using a Synchronization Source (SSRC) value of 1 for his SRTP and SRTCP packets. Alice thus has a crypto-context for SSRC 1, including the associated ROC (Roll Over Counter) and SEQ (RTP Sequence Number). Bob now forwards the call to Carol (Bob still has not generated an answer). At this point, Bob has Alice's key, which sometimes might be a security weakness. As the exchange proceeds, Carol gets the original offer, including the offered crypto-attribute and starts sending media packets towards Alice. It just so happens that Carol chooses an SSRC value of 1, as did Bob. When Carol starts generating packets, there is a potential for what RFC 3711 calls a "two-time pad" issue (problem 2), as well as the potential for the ROC to be out of sync between Alice and Carol (problem 3). Note that since Bob and Carol are (presumably) using different source transport addresses, the SSRC reuse does not constitute an SSRC collision (although it may still be interpreted as such by Alice). Per RFC 3711, since the master key would be shared between Bob and Carol in this case, it is RECOMMENDED that Alice leave the session at that point in order to avoid the two-time pad issue. It should also be noted that RFC 3711 recommends against sharing SRTP master keys, which forking may accidentally introduce when the keying material is for the receiving direction.
このシナリオでは、アリスはボブにオファーを生成します。ボブはアリスに向けて（初期）メディアの送信を開始します（まだ返答はありません）。このシナリオでは、シナリオA（たとえば、オファーに含まれる暗号属性は1つのみ）も発生しておらず、ボブはSRTPパケットとSRTCPパケットに同期ソース（SSRC）値1を使用していると想定しています。したがって、アリスは、関連するROC（ロールオーバーカウンター）とSEQ（RTPシーケンス番号）を含むSSRC 1の暗号コンテキストを持っています。これで、ボブはコールをキャロルに転送します（ボブはまだ応答を生成していません）。この時点で、ボブはアリスの鍵を持っています。これは、セキュリティ上の弱点となる場合があります。交換が進むと、キャロルは提供された暗号属性を含む元のオファーを取得し、アリスへのメディアパケットの送信を開始します。たまたま、キャロルがボブと同様にSSRC値1を選択します。 Carolがパケットの生成を開始すると、RFC 3711が「2タイムパッド」の問題と呼ぶ可能性（問題2）と、ROCがAliceとCarolの間で同期しなくなる可能性（問題3）があります。ボブとキャロルは（おそらく）異なるソーストランスポートアドレスを使用しているため、SSRCの再利用はSSRC衝突を構成しないことに注意してください（ただし、アリスによって解釈される可能性があります）。 RFC 3711によると、この場合、マスターキーはボブとキャロルの間で共有されるため、2回のパッド問題を回避するために、アリスがその時点でセッションを離れることをお勧めします。また、RFC 3711はSRTPマスターキーの共有を推奨していないことにも注意してください。SRTPマスターキーは、キーイング素材が受信方向のものである場合に、フォークによって誤って導入される可能性があります。
If we consider the above scenario again, but this time with keying material in the offer (and answer) being the sending keying material (as specified by SDP security descriptions), the scenario instead looks as follows: Bob again chooses SSRC 1, and Bob will need to send back an answer to Alice, since Alice needs to learn Bob's sending key. Bob also starts sending media towards Alice (clipping may occur until Alice receives Bob's answer). Bob again forwards the call to Carol who also starts sending early media using SSRC 1. However, Carol needs to generate a new answer (for the dialog between Alice and Carol) in order for Alice to process Carol's packets . Upon receiving this answer, Alice can initiate a new offer/answer exchange (to move the session to another transport address as described in Section 7.3). In this case, there is one master key per session and a unique keystream regardless of whether or not SSRCs collide.
上記のシナリオをもう一度検討しますが、今回はオファー（および回答）のキー情報が（SDPセキュリティの説明で指定されている）送信キー情報である場合、シナリオは代わりに次のようになります。ボブは再びSSRC 1を選択し、ボブはアリスはボブの送信キーを学習する必要があるため、アリスに回答を返信する必要があります。ボブはまた、アリスへのメディアの送信を開始します（アリスがボブの回答を受け取るまでクリッピングが発生する可能性があります）。ボブは再びコールをキャロルに転送し、キャロルもSSRC 1を使用して初期メディアの送信を開始します。ただし、アリスがキャロルのパケットを処理するためには、キャロルが（アリスとキャロルの間のダイアログ用に）新しい応答を生成する必要があります。この回答を受信すると、アリスは新しいオファー/アンサー交換を開始できます（セクション7.3で説明されているように、セッションを別のトランスポートアドレスに移動します）。この場合、SSRCが衝突するかどうかに関係なく、セッションごとに1つのマスターキーと一意のキーストリームがあります。
Scenario C: Parallel Forking Case
シナリオC：並列分岐のケース
In this scenario, Alice generates an offer (with receive keying material) that gets forked to Bob and Carol in parallel. Bob and Carol both start sending packets (early media) to Alice. If Bob and Carol choose different SSRCs, everything is fine initially. However, one of the crypto context parameters is the master key lifetime, and since Bob and Carol are sharing the same master key (unbeknownst to either), they do not know when they need to rekey (problem 4). If they choose the same SSRC, we have the two-time pad problem again (problem 2).
このシナリオでは、アリスはボブとキャロルに並行してフォークされるオファー（受信キーイングマテリアル付き）を生成します。ボブとキャロルの両方がアリスにパケット（初期メディア）の送信を開始します。ボブとキャロルが異なるSSRCを選択する場合、最初はすべて問題ありません。ただし、暗号化コンテキストパラメーターの1つはマスターキーの有効期間であり、ボブとキャロルは同じマスターキーを共有しているため（どちらも不明）、キーを再生成する必要があるタイミングがわかりません（問題4）。彼らが同じSSRCを選択すると、2回パッドの問題が再び発生します（問題2）。
In summary, if keying material were for the receive direction, we would have the following problems:
要約すると、キーイング素材が受信方向のものである場合、次の問題が発生します。
- Problem 1: Offerer does not know which of multiple crypto offers was chosen by answerer.
- 問題1：提供者は、複数の暗号オファーのどれが回答者によって選択されたかを知りません。
- Problem 2: SSRC reuse (or SSRC collisions) between multiple answerers (serial or parallel forking) may lead to the two-time pad issue.
- 問題2：複数のアンサー（シリアルまたはパラレル分岐）間でのSSRCの再利用（またはSSRCの衝突）により、2回のパッド問題が発生する可能性があります。
- Problem 3: Part of the crypto context parameters (specifically the ROC) is not communicated but derived, and if we allow multiple entities to use the same SSRC (sequentially), the ROC can be wrong.
- 問題3：暗号化コンテキストパラメーターの一部（具体的にはROC）は通信されませんが派生します。複数のエンティティが同じSSRCを（連続して）使用できるようにすると、ROCが間違っている可能性があります。
- Problem 4: All crypto contexts that share a master key need to maintain a shared set of counters (master key lifetime), and if we allow for multiple entities on different platforms to share a master key, we would need a mechanism to synchronize these counters.
- 問題4：マスターキーを共有するすべての暗号化コンテキストは、カウンターの共有セット（マスターキーの有効期間）を維持する必要があり、異なるプラットフォーム上の複数のエンティティがマスターキーを共有できるようにする場合、これらのカウンターを同期するメカニズムが必要になります。 。
Problem 1 could be addressed by using the MKI as proposed separately; however, it would result in using extra bandwidth for each SRTP media packet. Solving problem 2 implies a need for being able to synchronize SSRC values with the answerer (or abandon the session when SSRC reuse or SSRC collisions occur). Problem 3 implies a need for being able to synchronize ROC values on a per SSRC basis (or abandon the session when SSRC reuse occurs). Problem 4 could be solved by having the offerer (Alice, i.e., the entity receiving media) determine how many packets have actually been generated by the total set of senders to Alice and, hence, be the one to initiate the rekeying. In the case of packet losses, etc. this is not foolproof, but in practice it could probably be addressed by use of a reasonable safety margin.
問題1は、別途提案されているMKIを使用することで対処できます。ただし、SRTPメディアパケットごとに追加の帯域幅が使用されます。問題2を解決するには、SSRC値を回答者と同期できる（またはSSRCの再利用またはSSRCの衝突が発生したときにセッションを放棄する）必要があることを意味します。問題3は、ROC値をSSRCごとに同期する（またはSSRCの再利用が発生したときにセッションを放棄する）必要があることを意味します。問題4は、提供者（アリス、つまりメディアを受信するエンティティ）が、アリスへの送信者の合計セットによって実際に生成されたパケットの数を判断し、鍵の再生成を開始することで解決できます。パケット損失などの場合、これは完全なものではありませんが、実際には、妥当な安全マージンを使用することでおそらく対処できます。
In conclusion, it would be expected from an offer/answer and SIP point of view to have the offer (and answer) keying material be the receive keying material; however, doing so would trade security for SIP friendliness, e.g., two-time pad and master key lifetime issues, and violate the RFC 3711 rule for sharing an SRTP master key across SRTP sessions.
結論として、オファー/アンサーおよびSIPの観点から、オファー（およびアンサー）キーイング資料を受信キーイング資料にすることが期待されます。ただし、これを行うと、SIPとの親和性（2回のパッドとマスターキーの有効期間の問題など）とセキュリティが犠牲になり、SRTPセッション間でSRTPマスターキーを共有するためのRFC 3711規則に違反します。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, New Jersey 08837 USA
Flemming Andreasen Cisco Systems、Inc. 499 Thornall Street、8th Floor Edison、New Jersey 08837 USA
EMail: fandreas@cisco.com
Mark Baugher 5510 SW Orchid Street Portland, Oregon 97219 USA
Mark Baugher 5510 SW Orchid Street Portland、Oregon 97219 USA
EMail: mbaugher@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 Internet Society (2006).
Copyright（C）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、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 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。