RFC4568 日本語訳
4568 Session Description Protocol (SDP) Security Descriptions forMedia Streams. F. Andreasen, M. Baugher, D. Wing. July 2006. (Format: TXT=107881 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Andreasen
Request for Comments: 4568 M. Baugher
Category: Standards Track D. Wing
Cisco Systems
July 2006
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
Session Description Protocol (SDP) Security Descriptions for Media Streams
Status of This Memo
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.
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.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
Abstract
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.
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.
Table of Contents
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
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
Andreasen, et al. Standards Track [Page 1] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 1] RFC 4568 SDP Security Descriptions July 2006
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
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
Andreasen, et al. Standards Track [Page 2] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 2] RFC 4568 SDP Security Descriptions July 2006
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
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
1. Introduction
1. Introduction
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.
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.
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.
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.
Andreasen, et al. Standards Track [Page 3] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 3] RFC 4568 SDP Security Descriptions July 2006
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.
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.
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, 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.
The "crypto" attribute can be adapted to any media transport, but its precise definition is unique to a particular transport.
The "crypto" attribute can be adapted to any media transport, but its precise definition is unique to a particular transport.
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.
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.
Andreasen, et al. Standards Track [Page 4] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 4] RFC 4568 SDP Security Descriptions July 2006
2. Notational Conventions
2. Notational Conventions
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".
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".
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 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.
The terms 'transport' and 'media transport' are used to mean 'transport protocol' as defined in RFC 4566.
The terms 'transport' and 'media transport' are used to mean 'transport protocol' as defined in RFC 4566.
Explanatory notes are provided in several places throughout the document; these notes are indented three spaces from the surrounding text.
Explanatory notes are provided in several places throughout the document; these notes are indented three spaces from the surrounding text.
3. Applicability
3. Applicability
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 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.
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.
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.
4. SDP "Crypto" Attribute and Parameters
4. SDP "Crypto" Attribute and Parameters
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):
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):
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
Andreasen, et al. Standards Track [Page 5] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 5] RFC 4568 SDP Security Descriptions July 2006
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:
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:
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32
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.
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.
4.1. Tag
4.1. Tag
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).
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).
In the offer/answer model, the tag is a negotiated parameter.
In the offer/answer model, the tag is a negotiated parameter.
4.2. Crypto-Suite
4.2. Crypto-Suite
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.
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.
In the offer/answer model, the crypto-suite is a negotiated parameter.
In the offer/answer model, the crypto-suite is a negotiated parameter.
Andreasen, et al. Standards Track [Page 6] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 6] RFC 4568 SDP Security Descriptions July 2006
4.3. Key Parameters
4.3. Key Parameters
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):
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 = <key-method> ":" <key-info>
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.
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-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 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.
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.
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.
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.
In the offer/answer model, the key parameter is a declarative parameter.
In the offer/answer model, the key parameter is a declarative parameter.
Andreasen, et al. Standards Track [Page 7] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 7] RFC 4568 SDP Security Descriptions July 2006
4.4. Session Parameters
4.4. Session Parameters
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.
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.
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.
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.
4.5. Example
4.5. Example
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.
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.
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
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.
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.
Andreasen, et al. Standards Track [Page 8] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 8] RFC 4568 SDP Security Descriptions July 2006
5. General Use of the crypto Attribute
5. General Use of the crypto Attribute
In this section, we describe the general use of the crypto attribute outside of any transport or key-method specific rules.
In this section, we describe the general use of the crypto attribute outside of any transport or key-method specific rules.
5.1. Use with Offer/Answer
5.1. Use with Offer/Answer
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.
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.
5.1.1. Generating the Initial Offer - Unicast Streams
5.1.1. Generating the Initial Offer - Unicast Streams
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
Andreasen, et al. Standards Track [Page 9] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 9] RFC 4568 SDP Security Descriptions July 2006
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.
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.
For example, in SIP [RFC3261], a "security" precondition as
defined in [sprecon] could solve the above problem.
For example, in SIP [RFC3261], a "security" precondition as defined in [sprecon] could solve the above problem.
5.1.2. Generating the Initial Answer - Unicast Streams
5.1.2. Generating the Initial Answer - Unicast Streams
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.
answererが与えられたユニキャストメディアストリームのために1つ以上の暗号属性で初期の申し出を受けるとき、answererがちょうど提供された暗号属性の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.
answererが他の暗号属性のサポートを示したいなら、SDP Simple Capability Declaration[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つを選択するとき、answerer SHOULDはサポートすることができる中で最も都合のよい暗号属性を選択します、すなわち、リストにおける最初の有効なサポートしている暗号属性、answererの能力と安全保障政策によると。
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.
* answererがメディアに使用するキーは申出人に発信しました。 申し出か答えにおけるどんな方向属性の如何にかかわらずキーを提供しなければならないことに注意してください。
Andreasen, et al. Standards Track [Page 10] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[10ページ]。
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.
その上、答えに交渉されるどんなセッションパラメタも含まなければなりません。 申出人によって提供された宣言的なセッションパラメタは答えに含まれていません。 しかしながら、answererはそれ自身の宣言的なセッションパラメタのセットを提供するかもしれません。
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.
answererがいったん提供された暗号属性の1つを受け入れると、answererは、選択された暗号属性に応じてメディアを申出人に送り始めるかもしれません。 しかしながら、申出人が答えを受けるまで正しくそのようなメディア向けの資料セットを処理できないかもしれないことに注意してください。
5.1.3. Processing of the Initial Answer - Unicast Streams
5.1.3. 初期の答えの処理--ユニキャストストリーム
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個以上のキーを含まなければなりません。(キーはanswererから申出人に送られたメディアに使用されるでしょう)。
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.
上記のどれかが失敗するなら、交渉は失敗しなければなりません。
5.1.4. Modifying the Session
5.1.4. セッションを変更します。
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.
メディアストリームがいったん確立されると、それはいつでも変更されるかもしれません、RFC3264で説明されるように、セクション8。 そのような変更は、再の合わせることを実行するか、または暗号スイートを変えるために例えばセキュリティー・サービスで引き起こされるかもしれません。 メディアがセキュリティを流すなら、ここで定義された総合証券記述を使用するのはまだ望まれていて、これらの新しい申し出/答え交換に暗号属性を含まなければなりません。 手順が同様である、ものはセクション5.1.1、5.1で.2を定義しました、そして、5.1はこの.3通のドキュメントを定義しました、RFC3264(セクション8)に提供された問題を受けることがあります。
5.2. Use Outside Offer/Answer
5.2. 申し出/答えの外における使用
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
また、暗号スイート、暗号化キー、またはセッションパラメタの交渉が全くない申し出/答えの文脈の外に暗号属性を使用できます。 この場合、送付者はストリームのためのセキュリティパラメタを決定します。 交渉メカニズムが全くなくて、送付者がまさに1つの暗号属性を入れなければならなくて、受信機がそれかSHOULD NOTを受け入れなければならないので
Andreasen, et al. Standards Track [Page 11] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[11ページ]。
receive the associated stream. The sender SHOULD select the security description that it deems most secure for its purposes.
関連ストリームを受けてください。 送付者SHOULDは目的のために安全な状態でそれが最も考えるセキュリティ記述を選択します。
5.3. General Backwards Compatibility Considerations
5.3. 一般遅れている互換性問題
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.
申し出/答えモデルでは、answererがanswererが与えられた安全な輸送が(例えば、"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.
セキュリティ記述が申し出/答えモデルの外で使用されるとき、同様の問題は存在しています。 しかし、非交渉されたセキュリティ記述の源には、受信機が暗号属性を無視したという指示が全くありません。
6. SRTP Security Descriptions
6. SRTPセキュリティ記述
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輸送(例えば、"RTP/SAVP"か"RTP/SAVPF")と共にSRTPセキュリティ記述を使用するだけでよいです。 以下は"RTP/SAVP"という[RFC3711]で定義されたプロフィールのためのセキュリティ記述を指定します。 しかしながら、他の安全な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によると、暗号属性をサポートしない終点はそれを無視するでしょう。 そのような終点は正しく特定のメディアストリームを処理しないでしょう。 Offer/答えモデルを使用することによって、申出人とanswererはマルチメディアセッションの始めの前に使用されるために暗号パラメタを交渉できます(セクション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
SRTP仕様にリストアップされた20以上の暗号のパラメタがあります。 これらのパラメタの多くが特定の暗号の変換のための値を修理しました。しかしながら、セッション設立時点で、提供する必要は全く通常ない、ユニーク
Andreasen, et al. Standards Track [Page 12] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[12ページ]。
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パラメタの多くの設定は機能します(PRF)。 したがって、セキュリティセッションのために1セットの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.
* 暗号スイート: 認証変換暗号化と*主要なパラメタを特定します: 材料を合わせるSRTPとパラメタ*セッションパラメタ: 以下のパラメタは定義されます: - KDR: SRTP Key Derivation Rateは擬似ランダム機能がマスターキーに適用されるレートです。 - UNENCRYPTED_SRTP: SRTPメッセージは暗号化されていません。 - UNENCRYPTED_SRTCP: SRTCPメッセージは暗号化されていません。 - UNAUTHENTICATED_SRTP: SRTPメッセージは認証されません。 - FEC_オーダー: SRTPサービスに比例した前進型誤信号訂正(FEC)の注文。 - FEC_キー: FECが流れるとき、FECのマスターKeyを別々のアドレス、そして/または、ポートに送ります。 - 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.
パラメタと彼らの記述[セクション8.2、srtp]に関する全リストのためのSRTP仕様を参照してください。 UNENCRYPTED_SRTCPパラメタに関して、SDPセキュリティ記述の申出人とanswerersは、UNENCRYPTED_SRTCPかすべてのSRTCPメッセージを暗号化することであるデフォルトをくつがえすのにSRTCP E-ビットを使用してはいけません(セクション6.3.2を見てください)。 主要なパラメタ、暗号スイート、および上で見せられたセッションパラメタは以下の小区分で詳細に説明されます。
6.1. SRTP Key Parameter
6.1. SRTPの主要なパラメタ
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セキュリティ記述は以下の説明されるとしての主要な「インライン」のメソッドの使用を定義します。 さらなる研究にはいかなる他の合わせるメソッド(例えば、URL)のSRTPセキュリティ記述の使用もあります。
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).
「インライン」のタイプのキーは材料(マスターキーと塩)とすべての方針がそのマスターキーに関係づけた合わせることを含んでいます、どれくらい長い間それを使用できるか、そして、(生涯)それが入って来るSRTPパケットを特定のマスターキーに関連づけるのに、マスターキー識別子(MKI)を使用するかどうかを含んでいて。 対応する実装は、マスターキーに関連している方針に従って、方針に違反する入って来るパケットを受け入れてはいけません(例えば、マスターキー寿命が期限が切れた後に)。
The key parameter contains one or more cryptographic master keys, each of which MUST be a unique cryptographically random [RFC1750]
主要なパラメタは1個以上の暗号のマスターキーを含んでいます。それはaそれぞれ暗号で無作為の状態でユニークでなければなりません。[RFC1750]
Andreasen, et al. Standards Track [Page 13] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[13ページ]。
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):
全体のSDPメッセージ(すなわち、他のストリームのためのマスターキーを含んでいる)の他のマスターキーに関する値。 各キーは形式に続きます(セクション9.2に公式の定義を提供します):
"inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]
「インライン:」 <キー||塩の>[「|」 生涯]「[「| 」 MKI」: 」 長さ]
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
キー||塩、base64は生涯マスターキー生涯(SRTPの最大番号かこのマスターキーを使用するSRTCPパケット)MKIをコード化しました([RFC3548]を見てください、セクション3): 塩はマスターキーを連結しました、そして、MKIの長さのMKIと長さはSRTPでパケットをさばきます。
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
インライン: 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は、連結された1番目とコード化されたbase64です。 連結されたキーと塩の長さはキーが適用される暗号スイートのそばで決定しています。 長さ(base64から解読された後の)が暗号スイートに指定されたそれに合っていないなら、無効であると問題の暗号属性を考えなければなりません。 各マスターキーと塩が暗号でaであるに違いない、乱数、全体のSDPメッセージにユニークでなければなりません。 キャラクタを水増しして、キーと塩を解読するbase64である、(すなわち、1か2、base64によってコード化されたデータの終わりの「=」) 捨てられます(詳細に関して[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
2番目の分野は最大数のSRTPかSRTCPパケットでそのマスターキーを使用することで測定されるようにマスターキーのOPTIONAL生涯(すなわち、SRTPパケットの数とそれぞれSRTCPパケットの数は生涯より少なくなければならない)です。 値が非ゼロの、そして、陽の10進整数や2(セクション9.2で詳細に関して文法を見る)のパワーのように書かれているかもしれない生涯。 主なゼロを使用してはいけません。 「生涯」値は最大のパケット生存期間を暗号スイートに超えてはいけません。 寿命が大き過ぎるか、またはそうでなければ、無効であるなら、無効であると全体の暗号属性を考えなければなりません。 生涯を省略することによってデフォルトがそれとなく合図されるかもしれない、(生涯分野がaを決して含んでいないことに注意してください。
Andreasen, et al. Standards Track [Page 14] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[14ページ]。
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]):
3番目の分野はいつもしますが、コロン SRTP暗号化キー寿命がデフォルト値であるときに、これは便利です。 長いデシマル値を避ける近道として、生涯の構文で文字通りの「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.
例はコード化されたbase64である30八重奏の主要で連結された塩を示しています: 30八重奏のキー/塩の連結はbase64の4における3コード化で40のキャラクタ(八重奏)に広げられます。
The third field, which is also OPTIONAL, is the Master Key Identifier (MKI) and its byte length.
3番目の分野(また、OPTIONALである)は、Master Key Identifier(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マスターキーに関連しているマスターキー識別子です。 それがビッグエンディアン整数として実際のSRTPパケットで陽の10進整数にコード化されると定義されて、MKIがここにあります。 整数表現に主なゼロを使用してはいけません。 また、MKIを与えるなら、コロンでMKIとMKIの長さを与えて、切り離さなければならない、(「:」、) MKIの長さは10進整数としてバイトで指定されたSRTPパケットのMKI分野のサイズです。 主なゼロを使用してはいけません。 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).
そして、“From"が、SRTPが2つの値に関してマスターキーの生涯を指定するために2番目の特徴を提供すると呼んだ、「」、SRTP一連番号スペース[RFC3711]で定義される。 しかしながら、このSRTP Security記述仕様は、AESマスターキーの寿命が2^48のSRTPパケットであるので、(マスターキーを取り替えるどんな暗号の理由もないことを意味します)指す実用的なポイントアプリケーションのために<が"From"、“To">の特徴であるとサポートしません。 この理由で、主要なアップデートに合図するための2つの手段をサポートする必要は全くありません。 MKIは<"From"(MKIの特徴が、より簡単であるので(<"From"、“To">は加えませんが、MKIは各パケットに追加バイトを加えますが)それを必要とするほんのわずかなアプリケーションのためのこの仕様による“To">)の上で選ばれています。
Andreasen, et al. Standards Track [Page 15] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[15ページ]。
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.
以上のように、主要なパラメタは1個以上のマスターキーを含むことができます。 主要なパラメタが1個以上のマスターキーを含むとき、その主要なパラメタのすべてのマスターキーがMKI値を含まなければなりません。
When using the MKI, the MKI length MUST be the same for all keys in a given crypto attribute.
MKIを使用するとき、すべてのキーに、MKIの長さは与えられた暗号属性で同じであるに違いありません。
6.2. Crypto-Suites
6.2. 暗号スイート
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_| AES_CM_128_| F8_128_| | |HMAC_SHA1_80| HMAC_SHA1_32| HMAC_SHA1_80| +---------------------+-------------+--------------+---------------+ | マスターキーの長さ| 128ビット| 128ビット| 128ビット| | マスター塩の長さ| 112ビット| 112ビット| 112ビット| | SRTP生涯| 2^48のパケット| 2^48のパケット| 2^48のパケット| | SRTCP生涯| 2^31のパケット| 2^31のパケット| 2^31のパケット| | 暗号| AESカウンタ| AESカウンタ| AES F8モード| | | モード| モード| | | 暗号化キー| 128ビット| 128ビット| 128ビット| | Mac| HMAC-SHA1| HMAC-SHA1| HMAC-SHA1| | SRTP authタグ| 80ビット| 32ビット| 80ビット| | SRTCP authタグ| 80ビット| 80ビット| 80ビット| | SRTP auth主要なlen。 | 160ビット| 160ビット| 160ビット| | SRTCP auth主要なlen| 160ビット| 160ビット| 160ビット| +---------------------+-------------+--------------+---------------+
6.2.1. AES_CM_128_HMAC_SHA1_80
6.2.1. AES_CM_128_HMAC_SHA1_80
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].
80ビットの認証タグで、AES_CM_128_HMAC_SHA1_80はSRTPデフォルトAES Counter Mode暗号とHMAC-SHA1通報認証です。 マスターキーの長さは、128ビットであり、デフォルトを持っています。一番になる[39ページ、srtp]どれという最大2つの^48のSRTPパケットか2^31SRTCPパケットの生涯。
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パケットよりはるかに小さい間隔で、簡単で効率的な「再-合わせ」ることを許すのは、RECOMMENDEDです。
Andreasen, et al. Standards Track [Page 16] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[16ページ]。
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でSecurity Considerationsを見る)です。 長さはマスター塩の価値が112ビットです、そして、長さはセッション塩の価値が112ビットです。 擬似ランダム機能(PRF)は128ビットのキー長があるAES Counter Modeを使用するデフォルト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ビット)。 さもなければ、暗号属性は無効であると考えられます。
6.2.2. AES_CM_128_HMAC_SHA1_32
6.2.2. AES_CM_128_HMAC_SHA1_32
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によって解読されたキーと塩の価値の長さは240ビット30の八重奏であるに違いありません。 さもなければ、暗号属性は無効であると考えられます。
6.2.3. F8_128_HMAC_SHA1_80
6.2.3. F8_128_HMAC_SHA1_80
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によって解読されたキーと塩の価値の長さは240ビット30の八重奏であるに違いありません。 さもなければ、暗号属性は無効であると考えられます。
6.2.4. Adding New Crypto-Suite Definitions
6.2.4. 新しい暗号スイート定義を加えます。
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-道のRFCで発行されたSHOULDを変えます。 特定の暗号の変換のために暗号スイート値を定義する方法を例証してください。6.2に通じて.1を区分する、6.2、.3、セクション10で手順に従うIANAにどんな新しい暗号スイートも登録しなければなりません。
6.3. Session Parameters
6.3. セッションパラメタ
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セキュリティ記述は1セットの「セッション」パラメタ、どのOPTIONALLYがSRTPのためにSRTPセッションデフォルトをくつがえすのに使用されるかもしれないか、そして、およびSRTCPストリームを定義します。これらのパラメタはSRTPサービスのためのRTPセッションを構成します。 セッションパラメタは、SRTPの暗号の文脈を証明するためにセッション特殊情報を提供します。
Andreasen, et al. Standards Track [Page 17] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[17ページ]。
6.3.1. KDR=n
6.3.1. KDR=n
KDR specifies the Key Derivation Rate, as described in Section 4.3.1 of [RFC3711].
KDRは.1セクション4.3[RFC3711]で説明されるようにKey Derivation Rateを指定します。
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がセットで10進整数でなければならない、1、2…、24、どれが2^1〜2^24まで2のパワーを指示するか、包括的。 主なゼロを使用してはいけません。 SRTPの主要な派生率は、新しいセッションキーが宣言で与えられたSRTPマスターキー[RFC3711]からどれくらい頻繁に得られるかを制御します。 主要な派生率が指定されないとき(すなわち、KDRパラメタは省略されます)、ただ一つの初期の主要な派生は実行されます[RFC3711]。
In the offer/answer model, KDR is a declarative parameter.
申し出/答えモデルでは、KDRは宣言的なパラメタです。
6.3.2. UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP
6.3.2. UNENCRYPTED_SRTCPとUNENCRYPTED_SRTP
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メッセージが暗号化されています、そして、EビットはすべてのSRTCPメッセージのセット(1)であるに違いない。
6.3.3. UNAUTHENTICATED_SRTP
6.3.3. UNAUTHENTICATED_SRTP
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の使用はNOT RECOMMENDED(Security Considerationsを見る)です。
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.
申し出/答えモデルでは、このパラメタは交渉されます。
Andreasen, et al. Standards Track [Page 18] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[18ページ]。
6.3.4. FEC_ORDER=order
6.3.4. FEC_オーダーはオーダーと等しいです。
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]の使用に合図します。 「オーダー」のための前進型誤信号訂正値は、FEC_SRTPかSRTP_FECです。 FEC_SRTPは、FECがSRTPメディアの送付者と次々とSRTP SRTP処理の前にSRTPメディアの受信機によって適用されると合図します。 FEC_SRTPはデフォルトです。 SRTP_FECは逆の処理です。
In the offer/answer model, FEC_ORDER is a declarative parameter.
申し出/答えモデルでは、FEC_ORDERは宣言的なパラメタです。
6.3.5. FEC_KEY=key-params
6.3.5. FEC_キー=の主要なparams
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 Key Parameterと全く同じ形式で指定されます、そして、マスターキーはSDPの他のすべてのマスターキーと特に、異なっていなければなりません。 FEC_KEY MUST、それが適用されるメディアストリーム(すなわち、「m=」系列)より異なったIP-アドレス、そして/または、ポートにFEC小川を送ったら、指定してください、例えば、RFC2733で説明されるように、セクション11.1。 FEC小川を送るときには、メディアとしてのIP-アドレスとポートがそれが適用するもの、FEC_KEY MUST NOTに流す同じくらいに、指定してください。 FEC_KEYがこの後者の場合で指定されるなら、無効であると問題の暗号属性を考えなければなりません。
In the offer/answer model, FEC_KEY is a declarative parameter.
申し出/答えモデルでは、FEC_KEYは宣言的なパラメタです。
6.3.6. Window Size Hint (WSH)
6.3.6. ウィンドウサイズヒント(WSH)
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、セクション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.
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.
In the offer/answer model, WSH is a declarative parameter.
In the offer/answer model, WSH is a declarative parameter.
Andreasen, et al. Standards Track [Page 19] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 19] RFC 4568 SDP Security Descriptions July 2006
6.3.7. Defining New SRTP Session Parameters
6.3.7. Defining New SRTP Session Parameters
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.
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.
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.
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.
6.4. SRTP Crypto Context Initialization
6.4. SRTP Crypto Context Initialization
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:
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:
* SSRC: Synchronization source * ROC: Roll-over counter for a given SSRC * SEQ: Sequence number for a given SSRC
* SSRC: Synchronization source * ROC: Roll-over counter for a given SSRC * SEQ: Sequence number for a given SSRC
In a unicast session, as defined here, there are three constraints on these values.
In a unicast session, as defined here, there are three constraints on these values.
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.
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.
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
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
Andreasen, et al. Standards Track [Page 20] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 20] RFC 4568 SDP Security Descriptions July 2006
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 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.
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.
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.
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].
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].
6.4.1. Late Binding of One or More SSRCs to a Crypto Context
6.4.1. Late Binding of One or More SSRCs to a Crypto Context
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.
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.
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,
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,
Andreasen, et al. Standards Track [Page 21] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 21] RFC 4568 SDP Security Descriptions July 2006
the crypto context for a secure RTP session using late binding is initially identified by the SDP as
the crypto context for a secure RTP session using late binding is initially identified by the SDP as
<*, address, port>
<*, 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
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
<ssrcX, address, port>
<ssrcX, address, port>
is instantiated subject to the following constraints:
is instantiated subject to the following constraints:
* Media packets are authenticated: authentication MUST succeed;
otherwise, the crypto context is not instantiated.
* Media packets are authenticated: authentication MUST succeed; otherwise, the crypto context is not instantiated.
* Media packets are not authenticated: crypto context is
automatically 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).
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).
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.
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.
6.4.2. Sharing Cryptographic Contexts among Sessions or SSRCs
6.4.2. Sharing Cryptographic Contexts among Sessions or SSRCs
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.
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.
Andreasen, et al. Standards Track [Page 22] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 22] RFC 4568 SDP Security Descriptions July 2006
6.5. Removal of Crypto Contexts
6.5. Removal of Crypto Contexts
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.
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.
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.
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.
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.
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.
7. SRTP-Specific Use of the Crypto Attribute
7. SRTP-Specific Use of the Crypto Attribute
Section 5 describes general use of the crypto attribute, and this section completes it by describing SRTP-specific use.
Section 5 describes general use of the crypto attribute, and this section completes it by describing SRTP-specific use.
7.1. Use with Offer/Answer
7.1. Use with Offer/Answer
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.
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.
7.1.1. Generating the Initial Offer - Unicast Streams
7.1.1. Generating the Initial Offer - Unicast Streams
When the initial offer is generated, the offerer MUST follow the steps in Section 5.1.1, as well as the following steps.
When the initial offer is generated, the offerer MUST follow the steps in Section 5.1.1, as well as the following steps.
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
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
Andreasen, et al. Standards Track [Page 23] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 23] RFC 4568 SDP Security Descriptions July 2006
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.
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.
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.
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.
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.
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.
7.1.2. Generating the Initial Answer - Unicast Streams
7.1.2. Generating the Initial Answer - Unicast Streams
When the initial answer is generated, the answerer MUST follow the steps in Section 5.1.2, as well as the following steps.
When the initial answer is generated, the answerer MUST follow the steps in Section 5.1.2, as well as the following steps.
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.
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.
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.
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.
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.
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.
Andreasen, et al. Standards Track [Page 24] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 24] RFC 4568 SDP Security Descriptions July 2006
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.
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.
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.
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.
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]).
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]).
7.1.3. Processing of the Initial Answer - Unicast Streams
7.1.3. Processing of the Initial Answer - Unicast Streams
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.
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.
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).
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).
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.
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.
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.
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.
7.1.4. Modifying the Session
7.1.4. Modifying the Session
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.
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.
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.
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.
Andreasen, et al. Standards Track [Page 25] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 25] RFC 4568 SDP Security Descriptions July 2006
This requirement applies here as well; however, the following should be noted:
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].
* 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].
* 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].
* 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].
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.).
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.).
Finally, note that if the new offer is rejected, the old crypto parameters remain in place.
Finally, note that if the new offer is rejected, the old crypto parameters remain in place.
Andreasen, et al. Standards Track [Page 26] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 26] RFC 4568 SDP Security Descriptions July 2006
7.1.5. Offer/Answer Example
7.1.5. Offer/Answer Example
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).
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).
Offerer sends:
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
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:
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
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.
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.
Andreasen, et al. Standards Track [Page 27] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 27] RFC 4568 SDP Security Descriptions July 2006
7.2. SRTP-Specific Use Outside Offer/Answer
7.2. SRTP-Specific Use Outside Offer/Answer
Use of SRTP security descriptions outside the offer/answer model is not defined.
Use of SRTP security descriptions outside the offer/answer model is not defined.
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.
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.
7.3. Support for SIP Forking
7.3. Support for SIP Forking
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:
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:
* 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.
* 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.
* Two or more answerers may pick the same SSRC, and hence the SSRC collision problems mentioned earlier may arise.
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:
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:
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].
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].
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.
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.
Andreasen, et al. Standards Track [Page 28] RFC 4568 SDP Security Descriptions July 2006
Andreasen, et al. Standards Track [Page 28] RFC 4568 SDP Security Descriptions July 2006
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
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
7.4. SRTP-Specific Backwards Compatibility Considerations
7.4. SRTP-Specific Backwards Compatibility Considerations
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.
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.
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.
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.
7.5. Operation with KEYMGT= and k= lines
7.5. KEYMGT=とkとの操作は系列と等しいです。
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=keymgt"系列[keymgt]の両方を含むかもしれません。 SDP規則に従って、answererはそれが理解していない属性系列を無視するでしょう。 answererが「=暗号」と"a=keymgt"の両方をサポートするなら、答えは、「=暗号」か"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.
申し出は「=暗号」と「k=」系列[RFC4566]の両方を含むかもしれません。 SDP規則に従って、answererはそれが理解していない属性系列を無視するでしょう。 answererが「=暗号」と「k=」の両方をサポートするなら、答えは、「=暗号」か「k=」のどちらかを含んでいますが、ともに含んではいけません、両方を含んでいるのが未定義であるときに。
8. Security Considerations
8. セキュリティ問題
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セキュリティ記述の保護を確実にする責任です。 したがって、IT IS REQUIRED、アプリケーションは、それ自身のセキュリティー対策(例えば、S/MIMEなどの安全な「マルチ-部品」[smime])を呼び出すか、またはあるいはまた、下層セキュリティー・サービス(例えば、TLSかIPsec)を利用します。 このセキュリティが調整するIT IS REQUIREDは強い通報認証とパケットペイロード暗号化、および有効な反復操作による保護を提供します。
"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
「反復操作による保護」がコミュニケーションチャンネルにメッセージを傍受して、コピーを送付先に提供するほど近づく手段を持っている攻撃者に対して必要です。 うまくいっている反射攻撃はそうするでしょう。
Andreasen, et al. Standards Track [Page 29] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[29ページ]。
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メッセージは、メッセージがSRTPマスターキーの所有者から発したと立証するうまくいっているHMAC保全チェック[RFC3711]に続いて、認証されて、途中で、変更されませんでした。 攻撃者再挿入であるときに、しかしながら、そのような「正統」メッセージを攻撃者は得て、「再演できます」。チャンネルへのパケット。 再演されたパケットはさまざまな悪い影響をセッションに与えることができます、そして、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_32などの)に対して規範的な(AES_CM_128_80などの)デフォルト値であるかを特定します。
8.1. Authentication of Packets
8.1. パケットの認証
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メッセージの保全メカニズムSHOULDを制限するには、使用されてください(SRTP反復操作による保護はいつも可能にされます)。
8.2. Keystream Reuse
8.2. Keystream再利用
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
SRTPセキュリティ記述はSRTPセッションのための設定パラメータを示します。 スイートが定義した暗号へ駆け込むとき、Misconfigured SRTPセッションは彼らの暗号化サービスに対する攻撃に被害を受け易いです。
Andreasen, et al. Standards Track [Page 30] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[30ページ]。
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.
そして、セクション6.2 .1 6.2 .2、6.2 .3。 2つ以上のメディアストリームがAESブロックの同じkeystreamを使用することで暗号化されているとき、SRTP暗号化サービスは"misconfiguredする"です。 送付者と受信機が派生しているセッションキーを共有するとき、SRTPは、セッション関係者のSSRCsが、彼らの対応するkeystreamsをユニークにするのに役立つのを必要とします(SSRC衝突の場合で違反します): SRTP SSRC衝突は同じkeystreamsが使用されていることの時間[RFC3711]、SRTPかSRTCPペイロード暗号化を抜本的に弱めます。 例えば、攻撃者は、SRTPとSRTCPメッセージを集めて、衝突を待つかもしれません。 完全にそれぞれのメディアストリームが両方にそれ自身のユニークなマスターキーを持っているとAES-CMとAES-f8暗号化に対するこの攻撃が避けられる、方向を送って、受けてください。 この仕様がSDPセキュリティ記述の使用をユニキャストポイントツーポイントストリームに制限するのでキーがSRTPホストと、中で使用されたマスターキーの間で共有されない、メディアストリームがユニークであるという当然のことのために方向を送って、受けてください。
8.3. Signaling Authentication and Signaling Encryption
8.3. 認証に合図して、暗号化に合図します。
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の複雑さとコンピュータの費用を被る理由が全くありません。 それらがunauthenticated SDPメッセージで運ばれるとき、多くの場合、SRTP暗号属性とそのパラメタはサービス不能攻撃に被害を受け易いです。 いくつかの場合、RTPストリームの保全か秘密性に感染することができます。 例えば、攻撃者がSRTPストリームのためのUNENCRYPTEDを申し出にはめ込むなら、これは、answererが暗号化されたSRTPメッセージを解読しないのをもたらすかもしれません。 中から、最悪の場合、answerer力自体は、詮索にunencrypted 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.
その結果、IT IS REQUIRED、MIMEの安全な「マルチ-部品」、IPsec、TLS、またはある他のデータ機密保護サービスが、暗号属性(=暗号)を持っているSDPメッセージを伝える要約プロトコルのための通報認証を提供するのに利用されます。 その上、IT IS REQUIRED、マスターキーパラメタ(インライン)がメッセージに現れるときはいつも、要約ペイロードの暗号化は使用されます。 インライン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
SDPメッセージの通信路が発送されたら、SDPメッセージの部分、[IPsec]かTLS SHOULD NOTなどのセキュリティプロトコルを点検する中間システムを通して、セキュリティ記述を暗号化する、そして/または、認証するのに使用されてください。 保護された終わりから終わりが中間システムがどちらもそうすることができるそうであったならSDPセキュリティ記述、「a=暗号」属性SHOULDを含むメッセージの中間システム処理の場合では、セキュリティを変更してください。
Andreasen, et al. Standards Track [Page 31] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[31ページ]。
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.
または、記述、合わせることの材料にアクセスしてください。 したがって各中間システムで終わるセキュリティプロトコルを、ネットワークでつなぐか、または輸送してください、SHOULD NOT。SDPセキュリティ記述を保護するために、使用されます。 SHOULDが暗号化されて認証されたどんな中間システムも変更するか、または点検するSDPメッセージの部分の如何にかかわらず終わりから終わりであることをセキュリティ記述を許容するセキュリティプロトコル: MIMEの安全な「マルチ-部品」は中間システムによって処理されるSDPメッセージの保護のためのRECOMMENDEDです。
9. Grammar
9. 文法
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文法を提供します。
9.1. Generic "Crypto" Attribute Grammar
9.1. ジェネリック「暗号」属性文法
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)
「=暗号:」 タグ1*WSP暗号スイート1*WSP主要なparams*(1*WSPセッション-param)
tag = 1*9DIGIT crypto-suite = 1*(ALPHA / DIGIT / "_")
タグ=1*9DIGIT暗号スイート=1*(アルファ/ケタ/"_")
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
「主要なparam*(「;」主要なparam)主要な主要なparams=paramは主要なメソッドと等しい」:、」 主要なインフォメーションの主要なメソッドは主要なメソッド「インライン」/ext主要なメソッドext=1*(ALPHA / DIGIT /"_")主要なインフォメーション=1*と等しいです(%x21-3A/%x3C-7E)。 目に見える(印刷)は焦げます。 セミコロンを除いて、セッション-paramは1*(VCHAR)と等しいです。 目に見える(印刷)キャラクタ
where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC4234].
WSP、アルファー、DIGIT、およびVCHARが[RFC4234]で定義されるところ。
9.2. SRTP "Crypto" Attribute Grammar
9.2. SRTP「暗号」属性文法
This section provides an Augmented BNF [RFC4234] grammar for the SRTP-specific use of the SDP crypto attribute:
このセクションはSDP暗号属性のSRTP-特定的用法のためにAugmented BNF[RFC4234]に文法を供給します:
crypto-suite = srtp-crypto-suite
key-method = srtp-key-method
key-info = srtp-key-info
session-param = srtp-session-param
暗号スイート=srtp暗号スイート主要なメソッド=srtpの主要なメソッド主要なインフォメーション=srtpの主要なインフォメーションセッション-paramはsrtpセッションparamと等しいです。
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" /
"F8_128_HMAC_SHA1_32" /
srtp暗号スイート=、「AES_CM_128_HMAC_SHA1_32インチ/「F8_128_HMAC_SHA1_32インチ/」
Andreasen, et al. Standards Track [Page 32] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[32ページ]。
"AES_CM_128_HMAC_SHA1_80" /
srtp-crypto-suite-ext
「AES_CM_128_HMAC_SHA1_80インチ/srtp暗号スイートext」
srtp-key-method = "inline"
srtp-key-info = key-salt ["|" lifetime] ["|" mki]
srtpの主要なメソッド=「インライン」srtpの主要なインフォメーションは主要な塩[「|」 生涯]と等しいです。[「|」 mki]
key-salt = 1*(base64) ; binary key and salt values
; concatenated together, and then
; base64 encoded [section 3 of
; RFC3548
主要な塩は1*(base64)と等しいです。 2進のキーと塩の値。 一緒にいて、当時で、連結されます。 base64がコード化した、[3を区分する、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.
寿命は1*(ケタ)と等しいです[「2^」]。 「「2 ^」 mkiはmki-値と等しい」ので、セクション6.1を見てください」 mki-長さmki-値=1*DIGIT mki-長さは1*3DIGITと等しいです。 範囲1。128.
srtp-session-param = kdr /
"UNENCRYPTED_SRTP" /
"UNENCRYPTED_SRTCP" /
"UNAUTHENTICATED_SRTP" /
fec-order /
fec-key /
wsh /
srtp-session-extension
srtpセッションparamはsrtpセッションfec fec kdr/「UNENCRYPTED_SRTP」/「UNENCRYPTED_SRTCP」/「UNAUTHENTICATED_SRTP」/オーダー/キー/wsh/拡張子と等しいです。
kdr = "KDR=" 1*2(DIGIT) ; range 0..24,
; power of two
kdr=「KDR=」1*2(ケタ)。 範囲0。24, ; 2のパワー
fec-order = "FEC_ORDER=" fec-type
fec-type = "FEC_SRTP" / "SRTP_FEC"
fec-key = "FEC_KEY=" key-params
fec-オーダー=「FEC_オーダー=」fec-タイプfec-タイプは「SRTP_FEC」fec主要な=「FEC_キー=」主要な「FEC_SRTP」/paramsと等しいです。
wsh = "WSH=" 2*DIGIT ; minimum value is 64
base64 = ALPHA / DIGIT / "+" / "/" / "="
wshは「WSH=」2*ケタと等しいです。 「最小値はアルファー/ DIGIT /64base64=「+」/です」、/、」 /は「等しいです」。
srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_")
srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC4234]
; first character must not be dash ("-")
1つの*(ALPHA / DIGIT /"_")srtpセッションsrtp暗号スイートext=拡張子が[「-」]1*(VCHAR)と等しいです; 目に見える雑用[RFC4234] まず最初に、キャラクタはダッシュであるはずがありません。("-")
Andreasen, et al. Standards Track [Page 33] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[33ページ]。
10. IANA Considerations
10. IANA問題
10.1. Registration of the "crypto" Attribute
10.1. 「暗号」属性の登録
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
名前を結果と考えてください: 暗号Longフォーム名: メディアのためのセキュリティの記述の暗号の属性は属性のTypeを流します: charsetへのメディアレベルSubject: 目的がありません: セキュリティ記述Appropriate値: セクション4を見てください。
10.2. New IANA Registries and Registration Procedures
10.2. 新しいIANA登録と登録手順
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 Security記述登録を作成しました:
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
: :
SDPセキュリティ記述| +主要なメソッド(10.2では、.1について説明します)| +メディアは輸送(10.2では、.2について説明する)を流します。| + Transport1(例えば、SRTP)| | | Key Methods(例えば、インライン)であるとサポートされた+| | | +暗号スイート| | | +セッションパラメタ| +Transport2: :
10.2.1. Key Method Registry and Registration
10.2.1. 主要なメソッド登録と登録
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のセキュリティの記述の主要なメソッドのための新しい副登録を作成しました。 [RFC2434]規格Actionに従って、IANAの主要なメソッド登録をRFCに記録しなければなりません、そして、文法に応じて、それはセクション9.1で定義された主要なメソッドextに主要なメソッドの名前を供給しなければなりません。
Andreasen, et al. Standards Track [Page 34] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[34ページ]。
10.2.2. Media Stream Transport Registry and Registration
10.2.2. メディアは輸送登録と登録を流します。
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セキュリティ記述メディアStream Transportsのための新しい副登録を作成しました。 このドキュメントのセクション4と5で定義されたRFC2434Standards Actionと手順に従って、IANAメディアストリーム輸送登録を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指示と同様に。
10.3. Initial Registrations
10.3. 初期の登録証明書
10.3.1. Key Method
10.3.1. 主要なメソッド
The following security descriptions key methods are hereby registered:
以下のセキュリティ記述キーメソッドはこれにより登録されます:
inline
インライン
10.3.2. SRTP Media Stream Transport
10.3.2. SRTPメディアは輸送を流します。
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 Security記述メディアStream Transport subregistryを作成しました。 メソッドが支えたキーは「インラインです」。 SRTPのためのSDPセキュリティ記述の参照はこのドキュメントです。
10.3.2.1. SRTP Crypto Suite Registry and Registration
10.3.2.1. SRTP暗号スイート登録と登録
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 Security記述のSRTP輸送の下のSRTP暗号スイートへの新しい副登録を作成しました。 文法に従って、IANA SRTP暗号スイート登録はセクション9.2で定義されたsrtp暗号スイートextのために暗号スイート名を示さなければなりません。
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.
RFC2434Standards Actionに従って、RFCでSRTP暗号スイートの意味論について説明しなければなりません、主要な「インライン」のメソッドの意味論とパラメタのどんな特別な意味論も含んでいて。
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
_80AES_cmのAES_CM_128_HMAC_SHA1_128_HMAC_SHA1_32F8_128_HMAC_SHA1_80
Andreasen, et al. Standards Track [Page 35] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[35ページ]。
The reference for these crypto suites is provided in this document.
本書ではこれらの暗号スイートの参照を提供します。
10.3.2.2. SRTP Session Parameter Registration
10.3.2.2. SRTPセッションパラメタ登録
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 Security記述のSRTP輸送でSRTPセッションパラメタのための新しい副登録を作成しました。 IANA SRTPセッションパラメタ登録はセッションパラメタ名(セクション9.2で定義されるsrtpセッション拡張子)を示さなければなりません。 名前はダッシュキャラクタ(「-」)と共に始まってはいけません。
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.
RFC2434Standards Actionに従って、RFCでパラメタの意味論について説明しなければなりません。 値をパラメタに割り当てることができるなら、また、RFC2434Standards Actionに従って、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_オーダーの_の主要なFEC WSH
The reference for these parameters is this document.
これらのパラメタの参照はこのドキュメントです。
11. Acknowledgements
11. 承認
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ワーキンググループの製品であり、関係者からコメントの利益を得ました。 また、このドキュメントはイギリス女王エリザベッタCararra、アール・カーター、Per Cederqvist、ビル・フォスター、マットハンマー、Cullenジョニングス、ポールKyzivat、デヴィッド・マグリュー、マッツ・ジーター、デーヴ・オラン、ジョナサン・ローゼンバーグ、デーヴSinger、マイク・トーマス、ブライアン・ウィス、およびマグヌスWesterlundとの議論の利益を得ました。
12. Normative References
12. 引用規格
[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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Andreasen, et al. Standards Track [Page 36] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[36ページ]。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、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"、2005年10月のRFC4234。
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC
2828, May 2000.
[RFC2828]Shirey(R.、「インターネットセキュリティ用語集」、FYI36、RFC2828)は2000がそうするかもしれません。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3711] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[RFC1750]イーストレーク3番目、D.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性推薦」RFC1750、1994年12月。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3548]Josefsson、2003年7月のS.、「Base16、Base32、およびBase64データEncodings」RFC3548。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
13. Informative References
13. 有益な参照
[sprecon] Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol Media Streams", Work in
Progress, October 2005.
[sprecon] 「セキュリティはセッション記述プロトコルメディアストリームのためにあらかじめ調整する」というAndreasen、F.、およびD.翼は進歩、2005年10月に機能します。
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002.
[RFC3407] Andreasen、F.、「セッションの記述のプロトコルの(SDP)簡単な能力宣言」、RFC3407、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.、Sixth Usenix Unix Security SymposiumのProceedings、ページの「IPセキュリティー・プロトコルのための問題領域」 1-16と、サンノゼ(カリフォルニア)1996年7月。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
2003年7月の[GDOI]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[kink] Sakane, S., Kamada, K., Thomas, M. and J. Vilhuber,
"Kerberized Internet Negotiation of Keys (KINK)", RFC
4430, March 2006.
[ねじれます] SakaneとS.とKamadaとK.とトーマスとM.とJ.Vilhuber、「キー(もつれ)のKerberizedインターネット交渉」、RFC4430、2006年3月。
Andreasen, et al. Standards Track [Page 37] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[37ページ]。
[ike] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[ike] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[ipsec] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[ipsec] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[maxprate] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)", RFC
3890, September 2004.
[maxprate] Westerlund、M.、「セッション記述プロトコル(SDP)のための輸送の独立している帯域幅修飾語」、RFC3890、2004年9月。
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733, December
1999.
[RFC2733] ローゼンバーグとJ.とH.Schulzrinne、「ジェネリック前進型誤信号訂正のためのRTP有効搭載量形式」、RFC2733、1999年12月。
[s/mime] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[s/パントマイム]、RFC3851、2004年7月。
[pgp/mime] Elkins, M., "MIME Security with Pretty Good Privacy
(PGP)", RFC 2015, October 1996.
[pgp/パントマイム] エルキンズ、M.、「プリティ・グッド・プライバシ(PGP)があるMIMEセキュリティ」、RFC2015、1996年10月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[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.、カラーラ、E.、リンドホルム、F.、ジーター、M.、およびK.Norrman、「セッション記述のためのKey Management拡大は(SDP)とリアルタイムのストリーミングのプロトコル(RTSP)について議定書の中で述べます」、RFC4567、2006年7月。
[mikey] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[mikey] Arkko、J.、カラーラ、E.、リンドホルム、F.、ジーター、M.、およびK.Norrman、「マイキー:」 「マルチメディアインターネットの合わせる」RFC3830、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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、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:」 「インターネットへの多能な安全な主要な交換メカニズム」、ISOCは、ネットワークと分散システムがシンポジウム、サンディエゴ、1996であると機密保護します。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC3312] キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、「資源管理とセッション開始プロトコル(一口)の統合」、RFC3312(2002年10月)。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC2974] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
Andreasen, et al. Standards Track [Page 38] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[38ページ]。
[srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)", work in progress,
October 2003.
[srtpf] 「拡張安全なRTPはRTCPベースのフィードバックのために(RTP/SAVPF)の輪郭を描く」というオット、J.、およびE.カラーラは進歩、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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, September 2002.
[RFC3311] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデートメソッド」、RFC3311、2002年9月。
Andreasen, et al. Standards Track [Page 39] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[39ページ]。
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に情報を含む大部分と対照的になっています。SDPは受信(または、受信と発信)方向のための情報について説明します。 この逆にされた情報の方向性は申し出/答えモデルでメカニズムを使用して、特に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が分岐している状態で、問題をもたらしたでしょうに: 申し出は複数の答えを発生させます、そして、合わせることの材料は指示、かなりの複雑さにつながるだろう値(例えば、生涯)がすべてのanswerers(メディアの送付者)の間で共有されるために持っているパラメタのいくつかを受けて、ことによると釣り銭がいるようにあったか、そして、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):
以下のシナリオでは、私たちがSDPセキュリティ記述が合わせることの材料があったように設計されたなら起こることを分析する、材料(合わせることの材料が材料を合わせる発信である実際のデザインよりむしろ)を合わせながら、受信してください:
Andreasen, et al. Standards Track [Page 40] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[40ページ]。
Scenario A: Non-Forking Case
シナリオ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.)
このシナリオでは、申し出が材料を合わせながら受信を含んでいて、answererは申出人に向かってそれを受けて、データ・パケットを送り始めます。 申し出にただ一つの暗号属性があれば、暗号スイートが使用されていたあいまいさが全くないでしょうに、そして、したがって、入って来るパケットは処理できました。 しかしながら、申し出が複数の代替の暗号属性を含んでいた場合では、申出人は、どれが選ばれたかを知らないでしょう、そして、したがって、答えが戻る前に申出人がパケットを受けるなら、申出人はそれらのパケット(問題1)を処理できないでしょうに。 (しかしながら、MKIの使用はその1つの可能な解決策として示されて、それは1パケットあたり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.
このシナリオでは、アリスは申し出をボブに発生させます(答えは全くまだ戻っていませんでした)。(ボブは、(早くに、)アリスに向かってメディアを送り始めます)。 このシナリオでは、私たちは、また、Scenario Aに遭遇していない(例えば、申し出はただ一つの暗号属性だけを含んでいる)と思います、そして、そのボブは彼のSRTPとSRTCPパケットに1のSynchronization Source(SSRC)値を使用しています。 アリスには、その結果、関連ROC(Over Counterを回転させる)とSEQ(RTP Sequence Number)を含むSSRC1のための暗号文脈があります。 ボブは現在、呼び出しをキャロルに送ります(ボブは答えをまだ発生させていません)。 ここに、ボブはアリスのキーを持っています(時々セキュリティ弱点であるかもしれません)。 交換が続くとき、キャロルは提供された暗号属性とアリスに向かってメディア向けの資料セットを送る始めを含むオリジナルの申し出を得ます。 キャロルがボブのように1のSSRC値を選ぶのは全く起こります。 キャロルがパケットを発生させ始めるとき、RFC3711が「二度のパッド」問題(問題2)を呼ぶものの可能性があります、ROCがアリスとキャロル(問題3)の間で同期している可能性と同様に。 ボブとキャロルが(おそらく)異なったソース輸送アドレスを使用しているのでSSRC再利用がSSRC衝突を構成しないことに注意してください(それはアリスによってまだそういうものとして解釈されているかもしれませんが)。 マスターキーはこの場合ボブとキャロルの間で共有されるでしょう、したがって、RFC3711あたり、アリスがその時二度のパッド問題を避けるためにセッションを残すのは、RECOMMENDEDです。 また、RFC3711が共有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
私たちが再び上のシナリオを考えるなら、申し出(答える)で材料を合わせる今回が材料を合わせる発信(SDPセキュリティ記述で指定されるように)であり、シナリオは代わりに以下の通りに見えます: ボブは再びSSRC1を選びます、そして、ボブはそのように選ぶでしょう。
Andreasen, et al. Standards Track [Page 41] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[41ページ]。
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.
アリス以来アリスの答えを返送する必要性は、ボブの送付キーを学ぶ必要があります。 また、ボブはアリスに向かってメディアを送り始めます(アリスがボブの答えを受けるまで、切り取りは現れるかもしれません)。 ボブは再びまた、SSRC1を使用することで早めのメディアを送り始めるキャロルに呼び出しを送ります。 しかしながら、キャロルは、アリスがキャロルのパケットを処理するように、新しい答え(アリスとキャロルの間の対話のための)を発生させる必要があります。この答えを受けるとき、アリスは新しい申し出/答え交換(セクション7.3で説明されるようにセッションを別の輸送アドレスに動かす)を起こすことができます。 この場合、SSRCsが衝突するかどうかにかかわらず1セッションあたり1個のマスターキーとユニークなkeystreamがあります。
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).
このシナリオでは、アリスが申し出を発生させる、(材料) それが平行なボブとキャロルに分岐させ始める合わせるのを受けてください。 ボブとキャロルはともに、パケット(早めのメディア)をアリスに送り始めます。 ボブとキャロルが異なったSSRCsを選ぶなら、すべてが初めは、すばらしいです。 しかしながら、暗号文脈パラメタの1つはマスターキー生涯です、そして、ボブとキャロルが同じマスターキー(どちらかに知られずに)を共有しているので、それらは彼らがいつ(問題4)をrekeyに必要とするかを知りません。 彼らが同じSSRCを選ぶなら、私たちには、二度のパッド問題が再び(問題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: 申出人は、複数の暗号申し出のどれがanswererによって選ばれたかを知りません。
- Problem 2: SSRC reuse (or SSRC collisions) between multiple
answerers (serial or parallel forking) may lead to
the two-time pad issue.
- 問題2: 複数のanswerers(連続の、または、平行な分岐)の間のSSRC再利用(または、SSRC衝突)は二度のパッド問題につながるかもしれません。
- 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
別々に提案されるようにMKIを使用することによって、問題1を記述できるでしょう。 しかしながら、それはそれぞれのSRTPメディア向けの資料セットに余分な帯域幅を使用するのに結果として生じるでしょう。 問題2が必要性を含意する解決
Andreasen, et al. Standards Track [Page 42] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[42ページ]。
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.
answerer(SSRC再利用かSSRC衝突が起こるセッションを捨てる)とSSRC値を同期させることができること。 問題3はSSRC基礎あたりのaでROC値を同期させることができる必要性を含意します(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友情、例えば、二度のパッドとマスターキー生涯問題のためにセキュリティを取り引きして、SRTPセッションの向こう側にSRTPマスターキーを共有するためにRFC3711規則に違反するでしょう。
Authors' Addresses
作者のアドレス
Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, New Jersey 08837 USA
フレミングAndreasenシスコシステムズ, Inc.499Thornall通り、第8Floorエディソン、ニュージャージー08837米国
EMail: fandreas@cisco.com
メール: fandreas@cisco.com
Mark Baugher 5510 SW Orchid Street Portland, Oregon 97219 USA
マークBaugher5510SWラン通りオレゴン97219ポートランド(米国)
EMail: mbaugher@cisco.com
メール: mbaugher@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・Driveダン翼のシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
EMail: dwing@cisco.com
メール: dwing@cisco.com
Andreasen, et al. Standards Track [Page 43] RFC 4568 SDP Security Descriptions July 2006
Andreasen、他 規格はSDPセキュリティ記述2006年7月にRFC4568を追跡します[43ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Andreasen, et al. Standards Track [Page 44]
Andreasen、他 標準化過程[44ページ]
一覧
スポンサーリンク
