Network Working Group F. Andreasen
Request for Comments: 5027 D. Wing
Updates: 3312 Cisco Systems
Category: Standards Track October 2007
Network Working Group F. Andreasen
Request for Comments: 5027 D. Wing
Updates: 3312 Cisco Systems
Category: Standards Track October 2007
Security Preconditions for Session Description Protocol (SDP) Media Streams
会话描述协议（SDP）媒体流的安全先决条件
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully.
本文档为RFCs 3312和4032中描述的会话描述协议（SDP）前提条件框架定义了一个新的安全前提条件。安全先决条件可用于延迟会话建立或修改，直到成功协商安全媒体流的媒体流安全。
Table of Contents
目录
1. Introduction ....................................................2
2. Notational Conventions ..........................................2
3. Security Precondition Definition ................................2
4. Examples ........................................................6
4.1. SDP Security Descriptions Example ..........................6
4.2. Key Management Extension for SDP Example ...................9
5. Security Considerations ........................................11
6. IANA Considerations ............................................13
7. Acknowledgements ...............................................13
8. Normative References ...........................................13
9. Informative References .........................................14
1. Introduction ....................................................2
2. Notational Conventions ..........................................2
3. Security Precondition Definition ................................2
4. Examples ........................................................6
4.1. SDP Security Descriptions Example ..........................6
4.2. Key Management Extension for SDP Example ...................9
5. Security Considerations ........................................11
6. IANA Considerations ............................................13
7. Acknowledgements ...............................................13
8. Normative References ...........................................13
9. Informative References .........................................14
The concept of a Session Description Protocol (SDP) [RFC4566] precondition is defined in [RFC3312] as updated by [RFC4032]. A precondition is a condition that has to be satisfied for a given media stream in order for session establishment or modification to proceed. When a (mandatory) precondition is not met, session progress is delayed until the precondition is satisfied or the session establishment fails. For example, RFC 3312 defines the Quality-of-Service precondition, which is used to ensure availability of network resources prior to establishing (i.e., alerting) a call.
[RFC3312]中定义了会话描述协议（SDP）[RFC4566]先决条件的概念，并由[RFC4032]更新。先决条件是给定媒体流必须满足的条件，以便会话建立或修改继续进行。如果不满足（强制）先决条件，会话进程将延迟，直到满足先决条件或会话建立失败。例如，RFC 3312定义了服务质量先决条件，用于在建立（即，发出警报）呼叫之前确保网络资源的可用性。
Media streams can either be provided in cleartext and with no integrity protection, or some kind of media security can be applied, e.g., confidentiality and/or message integrity. For example, the Audio/Video profile of the Real-Time Transfer Protocol (RTP) [RFC3551] is normally used without any security services whereas the Secure Real-time Transport Protocol (SRTP) [SRTP] is always used with security services. When media stream security is being negotiated, e.g., using the mechanism defined in SDP Security Descriptions [SDESC], both the offerer and the answerer [RFC3264] need to know the cryptographic parameters being used for the media stream; the offerer may provide multiple choices for the cryptographic parameters, or the cryptographic parameters selected by the answerer may differ from those of the offerer (e.g., the key used in one direction versus the other). In such cases, to avoid media clipping, the offerer needs to receive the answer prior to receiving any media packets from the answerer. This can be achieved by using a security precondition, which ensures the successful negotiation of media stream security parameters for a secure media stream prior to session establishment or modification.
媒体流可以以明文形式提供，并且没有完整性保护，或者可以应用某种媒体安全性，例如机密性和/或消息完整性。例如，实时传输协议（RTP）[RFC3551]的音频/视频配置文件通常在没有任何安全服务的情况下使用，而安全实时传输协议（SRTP）[SRTP]始终与安全服务一起使用。当正在协商媒体流安全性时，例如，使用SDP安全描述[SDESC]中定义的机制，提供方和应答方[RFC3264]都需要知道用于媒体流的密码参数；报价人可以为密码参数提供多个选择，或者应答人选择的密码参数可能不同于报价人的密码参数（例如，在一个方向上使用的密钥与在另一个方向上使用的密钥）。在这种情况下，为了避免媒体剪辑，发盘方需要在从应答方接收任何媒体包之前接收应答。这可以通过使用安全先决条件来实现，该先决条件确保在会话建立或修改之前成功协商安全媒体流的媒体流安全参数。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The semantics for a security precondition are that the relevant cryptographic parameters (cipher, key, etc.) for a secure media stream are known to have been negotiated in the direction(s) required. If the security precondition is used with a non-secure media stream, the security precondition is by definition satisfied. A secure media stream is here defined as a media stream that uses some kind of security service (e.g., message integrity,
安全先决条件的语义是，已知安全媒体流的相关加密参数（密码、密钥等）已按照所需的方向协商。如果安全先决条件与非安全媒体流一起使用，则根据定义，安全先决条件满足。安全媒体流在此定义为使用某种安全服务（例如，消息完整性、，
confidentiality, or both), regardless of the cryptographic strength of the mechanisms being used.
机密性，或两者兼而有之），而不考虑所使用机制的加密强度。
As an extreme example of this, Secure RTP (SRTP) using the NULL encryption algorithm and no message integrity would be considered a secure media stream whereas use of plain RTP would not. Note though, that Section 9.5 of [SRTP] discourages the use of SRTP without message integrity.
作为一个极端的例子，使用空加密算法且没有消息完整性的安全RTP（SRTP）将被视为安全的媒体流，而使用普通RTP则不会。但是请注意，[SRTP]第9.5节不鼓励在没有消息完整性的情况下使用SRTP。
Security preconditions do not guarantee that an established media stream will be secure. They merely guarantee that the recipient of the media stream packets will be able to perform any relevant decryption and integrity checking on those media stream packets. Please refer to Section 5 for further security considerations.
安全先决条件不能保证已建立的媒体流是安全的。它们仅仅保证媒体流分组的接收者将能够对这些媒体流分组执行任何相关的解密和完整性检查。有关更多安全注意事项，请参阅第5节。
The security precondition type is defined by the string "sec" and hence we modify the grammar found in RFC 3312 as follows:
安全前提条件类型由字符串“sec”定义，因此我们修改RFC 3312中的语法，如下所示：
precondition-type = "sec" / "qos" / token
precondition-type = "sec" / "qos" / token
RFC 3312 defines support for two kinds of status types, namely segmented and end-to-end. The security precondition-type defined here MUST be used with the end-to-end status type; use of the segmented status type is undefined.
RFC3312定义了对两种状态类型的支持，即分段和端到端。此处定义的安全前提条件类型必须与端到端状态类型一起使用；分段状态类型的使用未定义。
A security precondition can use the strength-tag "mandatory", "optional", or "none".
安全前提条件可以使用强度标记“强制”、“可选”或“无”。
When a security precondition with a strength-tag of "mandatory" is received in an offer, session establishment or modification MUST be delayed until the security precondition has been met, i.e., the relevant cryptographic parameters (cipher, key, etc.) for a secure media stream are known to have been negotiated in the direction(s) required. When a mandatory security precondition is offered, and the answerer cannot satisfy the security precondition (e.g., because the offer was for a secure media stream, but it did not include the necessary parameters to establish the secure media stream keying material for example), the offered media stream MUST be rejected as described in RFC 3312.
当在要约中收到强度标签为“强制性”的安全前提条件时，会话建立或修改必须延迟，直到满足安全前提条件，即已知安全媒体流的相关加密参数（密码、密钥等）已按所需方向协商。当提供强制安全前提条件，且应答者不能满足安全前提条件时（例如，因为提供的是安全媒体流，但不包括建立安全媒体流密钥材料所需的参数），必须按照RFC 3312中的说明拒绝提供的媒体流。
The delay of session establishment defined here implies that alerting of the called party MUST NOT occur and media for which security is being negotiated MUST NOT be exchanged until the precondition has been satisfied. In cases where secure media and other non-media data is multiplexed on a media stream (e.g., when Interactive Connectivity Establishment [ICE] is being used), the non-media data is allowed to be exchanged prior to the security precondition being satisfied.
此处定义的会话建立延迟意味着在满足前提条件之前，不得发出被叫方警报，也不得交换正在协商安全的媒体。在媒体流上复用安全媒体和其他非媒体数据的情况下（例如，当使用交互式连接建立[ICE]时），允许在满足安全前提条件之前交换非媒体数据。
When a security precondition with a strength-tag of "optional" is received in an offer, the answerer MUST generate its answer SDP as soon as possible. Since session progress is not delayed in this case, the answerer does not know when the offerer is able to process secure media stream packets and hence clipping may occur. If the answerer wants to avoid clipping and delay session progress until he knows the offerer has received the answer, the answerer MUST increase the strength of the security precondition by using a strength-tag of "mandatory" in the answer. Note that use of a mandatory precondition in an offer requires the presence of a SIP "Require" header field containing the option tag "precondition": Any SIP UA that does not support a mandatory precondition will consequently reject such requests (which also has unintended ramifications for SIP forking that are known as the Heterogeneous Error Response Forking Problem (see e.g., [HERFP]). To get around this, an optional security precondition and the SIP "Supported" header field containing the option tag "precondition" can be used instead.
当在报价中收到强度标签为“可选”的安全前提条件时，应答者必须尽快生成其应答SDP。由于在这种情况下会话进程没有延迟，应答者不知道提供者何时能够处理安全的媒体流分组，因此可能发生剪辑。如果回答者希望避免剪辑和延迟会话进度，直到他知道报价人已经收到了答案，那么回答者必须通过在答案中使用“强制”的强度标签来增加安全前提条件的强度。请注意，在报价中使用强制先决条件需要存在包含选项标记“Premission”的SIP“Require”标头字段：任何不支持强制先决条件的SIP UA都将因此拒绝此类请求（这也会对SIP分叉产生意外的影响，称为异构错误响应分叉问题（参见[HERFP]）。为了解决这个问题，可以使用可选的安全前提条件和包含选项标记“Premission”的SIP“Supported”头字段。
When a security precondition with a strength-tag of "none" is received, processing continues as usual. The "none" strength-tag merely indicates that the offerer supports the following security precondition - the answerer MAY upgrade the strength-tag in the answer as described in [RFC3312].
当接收到强度标记为“无”的安全前提条件时，处理照常继续。“无”强度标签仅表示报价人支持以下安全前提条件-应答人可以按照[RFC3312]中的说明升级应答中的强度标签。
The direction tags defined in RFC 3312 are interpreted as follows:
RFC 3312中定义的方向标记解释如下：
* send: Media stream security negotiation is at a stage where it is possible to send media packets to the other party and the other party will be able to process them correctly from a security point of view, i.e., decrypt and/or integrity check them as necessary. The definition of "media packets" includes all packets that make up the media stream. In the case of Secure RTP for example, it includes SRTP as well as SRTCP. When media and non-media packets are multiplexed on a given media stream (e.g., when ICE is being used), the requirement applies to the media packets only.
* 发送：媒体流安全协商处于这样一个阶段：可以向另一方发送媒体数据包，而另一方将能够从安全角度正确处理它们，即，根据需要对它们进行解密和/或完整性检查。“媒体分组”的定义包括构成媒体流的所有分组。例如，在安全RTP的情况下，它包括SRTP和SRTCP。当在给定媒体流上复用媒体和非媒体分组时（例如，当使用ICE时），该要求仅适用于媒体分组。
* recv: Media stream security negotiation is at a stage where it is possible to receive and correctly process media stream packets sent by the other party from a security point of view.
* recv：媒体流安全协商处于一个阶段，从安全角度来看，可以接收并正确处理另一方发送的媒体流数据包。
The precise criteria for determining when the other party is able to correctly process media stream packets from a security point of view depend on the secure media stream protocol being used as well as the mechanism by which the required cryptographic parameters are negotiated.
确定另一方何时能够从安全角度正确处理媒体流分组的准确标准取决于所使用的安全媒体流协议以及协商所需密码参数的机制。
We here provide details for SRTP negotiated through SDP security descriptions as defined in [SDESC]:
我们在此提供通过[SDESC]中定义的SDP安全描述协商的SRTP的详细信息：
* When the offerer requests the "send" security precondition, it needs to receive the answer before the security precondition is satisfied. The reason for this is twofold. First, the offerer needs to know where to send the media. Secondly, in the case where alternative cryptographic parameters are offered, the offerer needs to know which set was selected. The answerer does not know when the answer is actually received by the offerer (which in turn will satisfy the precondition), and hence the answerer needs to use the confirm-status attribute [RFC3312]. This will make the offerer generate a new offer showing the updated status of the precondition.
* 当报价人请求“发送”安全先决条件时，需要在满足安全先决条件之前收到答复。原因有两个。首先，报价人需要知道将媒体发送到哪里。其次，在提供备选密码参数的情况下，报价人需要知道选择了哪一组。回答者不知道报价人何时实际收到答复（这反过来将满足前提条件），因此回答者需要使用确认状态属性[RFC3312]。这将使报价人生成一个新报价，显示前提条件的更新状态。
* When the offerer requests the "recv" security precondition, it also needs to receive the answer before the security precondition is satisfied. The reason for this is straightforward: The answer contains the cryptographic parameters that will be used by the answerer for sending media to the offerer; prior to receipt of these cryptographic parameters, the offerer is unable to authenticate or decrypt such media.
* 当报价人请求“recv”安全前提条件时，它还需要在满足安全前提条件之前收到答复。原因很简单：答案包含应答者将用于向报价人发送媒体的密码参数；在收到这些加密参数之前，报价人无法验证或解密此类媒体。
When security preconditions are used with the Key Management Extensions for the Session Description Protocol (SDP) [KMGMT], the details depend on the actual key management protocol being used.
当安全先决条件与会话描述协议（SDP）[KMGMT]的密钥管理扩展一起使用时，详细信息取决于实际使用的密钥管理协议。
After an initial offer/answer exchange in which the security precondition is requested, any subsequent offer/answer sequence for the purpose of updating the status of the precondition for a secure media stream SHOULD use the same key material as the initial offer/answer exchange. This means that the key-mgmt attribute lines [KMGMT], or crypto attribute lines [SDESC] in SDP offers, that are sent in response to SDP answers containing a confirm-status field [RFC3312] SHOULD repeat the same data as that sent in the previous SDP offer. If applicable to the key management protocol or SDP security description, the SDP answers to these SDP offers SHOULD repeat the same data in the key-mgmt attribute lines [KMGMT] or crypto attribute lines [SDESC] as that sent in the previous SDP answer.
在请求安全前提条件的初始要约/应答交换之后，为了更新安全媒体流的前提条件的状态，任何后续要约/应答序列都应使用与初始要约/应答交换相同的密钥材料。这意味着，SDP报价中的密钥管理属性行[KMGMT]或加密属性行[SDESC]在响应包含确认状态字段[RFC3312]的SDP应答时发送，应重复先前SDP报价中发送的相同数据。如果适用于密钥管理协议或SDP安全说明，这些SDP服务的SDP应答应在密钥管理属性行[KMGMT]或加密属性行[SDESC]中重复与先前SDP应答中发送的数据相同的数据。
Of course, this duplication of key exchange during precondition establishment is not to be interpreted as a replay attack. This issue may be solved if, e.g., the SDP implementation recognizes that the key management protocol data is identical in the second offer/answer exchange and avoids forwarding the information to the security layer for further processing.
当然，前提条件建立期间密钥交换的这种重复不能解释为重放攻击。例如，如果SDP实现认识到密钥管理协议数据在第二次提供/应答交换中是相同的，并且避免将信息转发到安全层进行进一步处理，则可以解决该问题。
Offers with security preconditions in re-INVITEs or UPDATEs follow the rules given in Section 6 of RFC 3312, i.e.:
在重新邀请或更新中带有安全先决条件的优惠遵循RFC 3312第6节中给出的规则，即：
"Both user agents SHOULD continue using the old session parameters until all the mandatory preconditions are met. At that moment, the user agents can begin using the new session parameters."
两个用户代理都应继续使用旧的会话参数，直到满足所有必需的先决条件。此时，用户代理可以开始使用新的会话参数
At that moment, we furthermore require that user agents MUST start using the new session parameters for media packets being sent. The user agents SHOULD be prepared to process media packets received with either the old or the new session parameters for a short period of time to accommodate media packets in transit. Note that this may involve iterative security processing of the received media packets during that period of time. Section 8 in [RFC3264] lists several techniques to help alleviate the problem of determining when a received media packet was generated according to the old or new offer/answer exchange.
此时，我们还要求用户代理必须开始为正在发送的媒体包使用新的会话参数。用户代理应准备在短时间内处理使用旧会话参数或新会话参数接收的媒体分组，以适应传输中的媒体分组。注意，这可能涉及在该时间段期间对接收到的媒体分组的迭代安全处理。[RFC3264]中的第8节列出了有助于缓解根据旧的或新的提供/应答交换确定何时生成接收的媒体分组的问题的几种技术。
The call flow of Figure 1 shows a basic session establishment using the Session Initiation Protocol [SIP] and SDP security descriptions [SDESC] with security descriptions for the secure media stream (SRTP in this case).
图1的调用流显示了使用会话启动协议[SIP]和SDP安全描述[SDESC]以及安全媒体流（本例中为SRTP）的安全描述的基本会话建立。
A B
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|----------------(3) PRACK SDP3------------->|
| |
|<-----------(4) 200 OK (PRACK) SDP4---------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|----------------(3) PRACK SDP3------------->|
| |
|<-----------(4) 200 OK (PRACK) SDP4---------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
Figure 1: Security Preconditions with SDP Security Descriptions Example
图1:SDP安全描述示例的安全前提条件
The SDP descriptions of this example are shown below - we have omitted the details of the SDP security descriptions as well as any SIP details for clarity of the security precondition described here:
本示例的SDP描述如下所示-为了明确此处描述的安全前提条件，我们省略了SDP安全描述的细节以及任何SIP细节：
SDP1: A includes a mandatory end-to-end security precondition for both the send and receive direction in the initial offer as well as a "crypto" attribute (see [SDESC]), which includes keying material that can be used by A to generate media packets. Since B does not know any of the security parameters yet, the current status (see RFC 3312) is set to "none". A's local status table (see RFC 3312) for the security precondition is as follows:
SDP1:A包括初始报价中发送和接收方向的强制性端到端安全前提条件以及“加密”属性（参见[SDESC]），其中包括可由A用于生成媒体包的密钥材料。由于B还不知道任何安全参数，因此当前状态（参见RFC 3312）设置为“无”。A的本地状态表（见RFC 3312）的安全前提条件如下：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
and the resulting offer SDP is:
由此产生的报价SDP为：
m=audio 20000 RTP/SAVP 0 c=IN IP4 192.0.2.1 a=curr:sec e2e none a=des:sec mandatory e2e sendrecv a=crypto:foo...
m=音频20000 RTP/SAVP 0 c=IP4 192.0.2.1 a=电流：秒e2e无a=des：秒强制e2e发送记录a=加密：foo。。。
SDP2: When B receives the offer and generates an answer, B knows the (send and recv) security parameters of both A and B. From a security perspective, B is now able to receive media from A, so B's "recv" security precondition is "yes". However, A does not know any of B's SDP information, so B's "send" security precondition is "no". B's local status table therefore looks as follows:
SDP2：当B收到报价并生成应答时，B知道A和B的（发送和接收）安全参数。从安全角度看，B现在能够从A接收媒体，因此B的“接收”安全前提条件为“是”。但是，A不知道B的任何SDP信息，因此B的“发送”安全前提是“否”。因此，B的本地状态表如下所示：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
B requests A to confirm when A knows the security parameters used in the send and receive direction (it would suffice for B to ask for confirmation of A's send direction only) and hence the resulting answer SDP becomes:
B要求A确认A何时知道发送和接收方向中使用的安全参数（B只要求确认A的发送方向就足够了），因此得到的答案SDP为：
m=audio 30000 RTP/SAVP 0 c=IN IP4 192.0.2.4 a=curr:sec e2e recv a=des:sec mandatory e2e sendrecv a=conf:sec e2e sendrecv a=crypto:bar...
m=audio 30000 RTP/SAVP 0 c=IN IP4 192.0.2.4 a=curr:sec e2e recv a=des:sec mandatory e2e sendrecv a=conf:sec e2e sendrecv a=crypto:bar。。。
SDP3: When A receives the answer, A updates its local status table based on the rules in RFC 3312. A knows the security parameters of both the send and receive direction and hence A's local status table is updated as follows:
SDP3：当A收到答案时，A将根据RFC 3312中的规则更新其本地状态表。A知道发送和接收方向的安全参数，因此A的本地状态表更新如下：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | yes
recv | yes | mandatory | yes
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | yes
recv | yes | mandatory | yes
Since B requested confirmation of the send and recv security preconditions, and both are now satisfied, A immediately sends an updated offer (3) to B showing that the security preconditions are satisfied:
由于B要求确认发送和接收安全先决条件，并且现在两者都满足，A立即向B发送更新的报价（3），表明满足了安全先决条件：
m=audio 20000 RTP/SAVP 0 c=IN IP4 192.0.2.1 a=curr:sec e2e sendrecv a=des:sec mandatory e2e sendrecv a=crypto:foo...
m=音频20000 RTP/SAVP 0 c=IP4 192.0.2.1 a=电流：秒e2e发送记录a=des：秒强制e2e发送记录a=加密：foo。。。
Note that we here use PRACK [RFC3262] instead of UPDATE [RFC3311] since the precondition is satisfied immediately, and the original offer/answer exchange is complete.
注意，我们在这里使用PRACK[RFC3262]而不是UPDATE[RFC3311]，因为前提条件立即得到满足，并且原始的报价/应答交换已经完成。
SDP4: Upon receiving the updated offer, B updates its local status table based on the rules in RFC 3312, which yields the following:
SDP4：收到更新的报价后，B将根据RFC 3312中的规则更新其本地状态表，这将产生以下结果：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
B responds with an answer (4) that contains the current status of the security precondition (i.e., sendrecv) from B's point of view:
B以一个答案（4）进行响应，该答案包含B认为的安全前提条件（即sendrecv）的当前状态：
m=audio 30000 RTP/SAVP 0 c=IN IP4 192.0.2.4 a=curr:sec e2e sendrecv a=des:sec mandatory e2e sendrecv a=crypto:bar...
m=audio 30000 RTP/SAVP 0 c=IP4 192.0.2.4 a=curr:sec e2e sendrecv a=des:sec强制e2e sendrecv a=crypto:bar。。。
B's local status table indicates that all mandatory preconditions have been satisfied, and hence session establishment resumes; B returns a 180 (Ringing) response (5) to indicate alerting.
B的本地状态表表明，所有强制性先决条件均已满足，因此会话建立将恢复；B返回180（响铃）响应（5）以指示警报。
The call flow of Figure 2 shows a basic session establishment using the Session Initiation Protocol [SIP] and Key Management Extensions for SDP [KMGMT] with security descriptions for the secure media stream (SRTP in this case):
图2的调用流显示了使用会话启动协议[SIP]和SDP密钥管理扩展[KMGMT]的基本会话建立，以及安全媒体流（本例中为SRTP）的安全描述：
A B
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|----------------(3) PRACK SDP3------------->|
| |
|<-----------(4) 200 OK (PRACK) SDP4---------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|----------------(3) PRACK SDP3------------->|
| |
|<-----------(4) 200 OK (PRACK) SDP4---------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
| |
Figure 2: Security Preconditions with Key Management Extensions for SDP Example
图2:SDP示例的密钥管理扩展的安全先决条件
The SDP descriptions of this example are shown below - we show an example use of MIKEY [MIKEY] with the Key Management Extensions, however we have omitted the details of the MIKEY parameters as well as any SIP details for clarity of the security precondition described here:
该示例的SDP描述如下所示-我们展示了MIKEY[MIKEY]与密钥管理扩展的示例使用，但是为了明确此处描述的安全前提条件，我们省略了MIKEY参数的细节以及任何SIP细节：
SDP1: A includes a mandatory end-to-end security precondition for both the send and receive direction in the initial offer as well as a "key-mgmt" attribute (see [KMGMT]), which includes keying material that can be used by A to generate media packets. Since B does not know any of the security parameters yet, the current status (see RFC 3312) is set to "none". A's local status table (see RFC 3312) for the security precondition is as follows:
SDP1:A包括初始报价中发送和接收方向的强制端到端安全前提条件以及“密钥管理”属性（请参见[KMGMT]），其中包括可由A用于生成媒体包的密钥材料。由于B还不知道任何安全参数，因此当前状态（参见RFC 3312）设置为“无”。A的本地状态表（见RFC 3312）的安全前提条件如下：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
and the resulting offer SDP is:
由此产生的报价SDP为：
m=audio 20000 RTP/SAVP 0 c=IN IP4 192.0.2.1 a=curr:sec e2e none a=des:sec mandatory e2e sendrecv a=key-mgmt:mikey AQAFgM0X...
m=音频20000 RTP/SAVP 0 c=IP4 192.0.2.1 a=电流：秒e2e无a=des：秒强制e2e发送a=密钥管理：mikey AQAFgM0X。。。
SDP2: When B receives the offer and generates an answer, B knows the (send and recv) security parameters of both A and B. B generates keying material for sending media to A, however, A does not know B's keying material, so the current status of B's "send" security precondition is "no". B does know A's SDP information, so B's "recv" security precondition is "yes". B's local status table therefore looks as follows:
SDP2：当B收到报价并生成应答时，B知道A和B的（发送和接收）安全参数。B生成向A发送媒体的密钥材料，但A不知道B的密钥材料，因此B的“发送”安全前提条件的当前状态为“否”。B确实知道A的SDP信息，所以B的“recv”安全前提是“是”。因此，B的本地状态表如下所示：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
B requests A to confirm when A knows the security parameters used in the send and receive direction and hence the resulting answer SDP becomes:
B请求A确认A何时知道在发送和接收方向中使用的安全参数，从而得出的答案SDP变为：
m=audio 30000 RTP/SAVP 0 c=IN IP4 192.0.2.4 a=curr:sec e2e recv a=des:sec mandatory e2e sendrecv a=conf:sec e2e sendrecv a=key-mgmt:mikey AQAFgM0X...
m=audio 30000 RTP/SAVP 0 c=IN IP4 192.0.2.4 a=curr:sec e2e recv a=des:sec mandatory e2e sendrecv a=conf:sec e2e sendrecv a=密钥管理：mikey AQAFgM0X。。。
Note that the actual MIKEY data in the answer differs from that in the offer; however, we have only shown the initial and common part of the MIKEY value in the above.
请注意，答案中的实际MIKEY数据与报价中的数据不同；但是，我们在上面只显示了MIKEY值的初始和公共部分。
SDP3: When A receives the answer, A updates its local status table based on the rules in RFC 3312. A now knows all the security parameters of both the send and receive direction and hence A's local status table is updated as follows:
SDP3：当A收到答案时，A将根据RFC 3312中的规则更新其本地状态表。A现在知道发送和接收方向的所有安全参数，因此A的本地状态表更新如下：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | yes
recv | yes | mandatory | yes
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | yes
recv | yes | mandatory | yes
Since B requested confirmation of the send and recv security preconditions, and both are now satisfied, A immediately sends an updated offer (3) to B showing that the security preconditions are satisfied:
由于B要求确认发送和接收安全先决条件，并且现在两者都满足，A立即向B发送更新的报价（3），表明满足了安全先决条件：
m=audio 20000 RTP/SAVP 0 c=IN IP4 192.0.2.1 a=curr:sec e2e sendrecv a=des:sec mandatory e2e sendrecv a=key-mgmt:mikey AQAFgM0X...
m=音频20000 RTP/SAVP 0 c=IP4 192.0.2.1 a=电流：秒e2e发送记录a=des：秒强制e2e发送记录a=密钥管理：mikey AQAFgM0X。。。
SDP4: Upon receiving the updated offer, B updates its local status table based on the rules in RFC 3312, which yields the following:
SDP4：收到更新的报价后，B将根据RFC 3312中的规则更新其本地状态表，这将产生以下结果：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
B responds with an answer (4) that contains the current status of the security precondition (i.e., sendrecv) from B's point of view:
B以一个答案（4）进行响应，该答案包含B认为的安全前提条件（即sendrecv）的当前状态：
m=audio 30000 RTP/SAVP 0 c=IN IP4 192.0.2.4 a=curr:sec e2e sendrecv a=des:sec mandatory e2e sendrecv a=key-mgmt:mikey AQAFgM0X...
m=音频30000 RTP/SAVP 0 c=IP4 192.0.2.4 a=电流：秒e2e发送记录a=des：秒强制e2e发送记录a=密钥管理：mikey AQAFgM0X。。。
B's local status table indicates that all mandatory preconditions have been satisfied, and hence session establishment resumes; B returns a 180 (Ringing) response (5) to indicate alerting.
B的本地状态表表明，所有强制性先决条件均已满足，因此会话建立将恢复；B返回180（响铃）响应（5）以指示警报。
In addition to the general security considerations for preconditions provided in RFC 3312, the following security issues should be considered.
除了RFC 3312中规定的前提条件的一般安全注意事项外，还应考虑以下安全问题。
Security preconditions delay session establishment until cryptographic parameters required to send and/or receive media for a media stream have been negotiated. Negotiation of such parameters can fail for a variety of reasons, including policy preventing use of certain cryptographic algorithms, keys, and other security parameters. If an attacker can remove security preconditions or downgrade the strength-tag from an offer/answer exchange, the attacker can thereby cause user alerting for a session that may have no functioning media. This is likely to cause inconvenience to both the offerer and the answerer. Similarly, security preconditions can
安全先决条件延迟会话建立，直到为媒体流发送和/或接收媒体所需的加密参数协商完毕。由于各种原因，此类参数的协商可能会失败，包括防止使用某些加密算法、密钥和其他安全参数的策略。如果攻击者可以从提供/应答交换中删除安全先决条件或降级强度标记，则攻击者可能因此导致用户对可能没有正常工作介质的会话发出警报。这可能会给报价人和应答人带来不便。同样，安全先决条件也可以改变
be used to prevent clipping due to race conditions between an offer/answer exchange and secure media stream packets based on that offer/answer exchange. If an attacker can remove or downgrade the strength-tag of security preconditions from an offer/answer exchange, the attacker can cause clipping to occur in the associated secure media stream.
用于防止由于提供/应答交换和基于该提供/应答交换的安全媒体流数据包之间的竞争条件而进行剪辑。如果攻击者可以从提供/应答交换中删除或降级安全先决条件的强度标记，则攻击者可以导致在关联的安全媒体流中发生剪切。
Conversely, an attacker might add security preconditions to offers that do not contain them or increase their strength-tag. This in turn may lead to session failure (e.g., if the answerer does not support it), heterogeneous error response forking problems, or a delay in session establishment that was not desired.
相反，攻击者可能会向不包含安全先决条件的产品添加安全先决条件，或增加其强度标签。这反过来可能会导致会话失败（例如，如果应答者不支持它），异构错误响应分叉问题，或会话建立延迟（这是不希望的）。
Use of signaling integrity mechanisms can prevent all of the above problems. Where intermediaries on the signaling path (e.g., SIP proxies) are trusted, it is sufficient to use only hop-by-hop integrity protection of signaling, e.g., IPSec or TLS. In all other cases, end-to-end integrity protection of signaling (e.g., S/MIME) MUST be used. Note that the end-to-end integrity protection MUST cover not only the message body, which contains the security preconditions, but also the SIP "Supported" and "Require" headers, which may contain the "precondition" option tag. If only the message body were integrity protected, removal of the "precondition" option tag could lead to clipping (when a security precondition was otherwise to be used), whereas addition of the option tag could lead to session failure (if the other side does not support preconditions).
使用信令完整性机制可以防止上述所有问题。如果信令路径上的中介（例如，SIP代理）是可信的，则仅使用信令的逐跳完整性保护（例如，IPSec或TLS）就足够了。在所有其他情况下，必须使用端到端的信令完整性保护（如S/MIME）。请注意，端到端完整性保护不仅必须覆盖包含安全先决条件的消息体，还必须覆盖SIP“受支持”和“需要”头，其中可能包含“先决条件”选项标记。如果只有消息体受到完整性保护，则删除“Premission”选项标记可能会导致剪切（如果要使用安全先决条件），而添加选项标记可能会导致会话失败（如果另一方不支持先决条件）。
As specified in Section 3, security preconditions do not guarantee that an established media stream will be secure. They merely guarantee that the recipient of the media stream packets will be able to perform any relevant decryption and integrity checking on those media stream packets.
如第3节所述，安全先决条件不能保证已建立的媒体流是安全的。它们仅仅保证媒体流分组的接收者将能够对这些媒体流分组执行任何相关的解密和完整性检查。
Current SDP [RFC4566] and associated offer/answer procedures [RFC3264] allows only a single type of transport protocol to be negotiated for a given media stream in an offer/answer exchange. Negotiation of alternative transport protocols (e.g., plain and secure RTP) is currently not defined. Thus, if the transport protocol offered (e.g., secure RTP) is not supported, the offered media stream will simply be rejected. There is however work in progress to address that. For example, the SDP Capability Negotiation framework [SDPCN] defines a method for negotiating the use of a secure or a non-secure transport protocol by use of SDP and the offer/answer model with various extensions.
当前SDP[RFC4566]和相关的提供/应答过程[RFC3264]只允许在提供/应答交换中为给定媒体流协商单一类型的传输协议。目前尚未定义替代传输协议（例如，普通和安全RTP）的协商。因此，如果所提供的传输协议（例如，安全RTP）不受支持，则所提供的媒体流将被简单地拒绝。然而，解决这一问题的工作正在进行中。例如，SDP能力协商框架[SDPCN]定义了通过使用SDP和具有各种扩展的提供/应答模型来协商使用安全或非安全传输协议的方法。
Such a mechanism introduces a number of security considerations in general, however use of SDP Security Preconditions with such a
这种机制通常会引入一些安全注意事项，但是在这种情况下使用SDP安全先决条件
mechanism introduces the following security precondition specific security considerations:
该机制引入了以下安全前提条件特定的安全注意事项：
A basic premise of negotiating secure and non-secure media streams as alternatives is that the offerer's security policy allows for non-secure media. If the offer were to include secure and non-secure media streams as alternative offers, and media for either alternative may be received prior to the answer, then the offerer may not know if the answerer accepted the secure alternative. An active attacker thus may be able to inject malicious media stream packets until the answer (indicating the chosen secure alternative) is received. From a security point of view, it is important to note that use of security preconditions (even with a mandatory strength-tag) would not address this vulnerability since security preconditions would effectively apply only to the secure media stream alternatives. If the non-secure media stream alternative was selected by the answerer, the security precondition would be satisfied by definition, the session could progress and (non-secure) media could be received prior to the answer being received.
作为备选方案协商安全和非安全媒体流的一个基本前提是，报价人的安全策略允许使用非安全媒体。如果报价将包括安全和非安全媒体流作为备选报价，且任一备选方案的媒体可能在答复之前收到，则报价人可能不知道应答人是否接受了安全备选方案。因此，主动攻击者可能能够注入恶意媒体流数据包，直到收到应答（指示选择的安全替代方案）。从安全角度来看，需要注意的是，使用安全先决条件（即使带有强制强度标记）不会解决此漏洞，因为安全先决条件只会有效地应用于安全媒体流备选方案。如果应答者选择了不安全的媒体流备选方案，则根据定义，安全先决条件将得到满足，会话可以进行，并且（不安全的）媒体可以在收到应答之前被接收。
IANA has registered an RFC 3312 precondition type called "sec" with the name "Security precondition". The reference for this precondition type is the current document.
IANA已注册名为“sec”的RFC 3312前提条件类型，名称为“安全前提条件”。此前提条件类型的引用是当前文档。
The security precondition was defined in earlier versions of RFC 3312. RFC 3312 contains an extensive list of people who worked on those earlier versions, which are acknowledged here as well. The authors would additionally like to thank David Black, Mark Baugher, Gonzalo Camarillo, Paul Kyzivat, and Thomas Stach for their comments on this document.
安全前提条件在RFC 3312的早期版本中定义。RFC3312包含一个广泛的列表，其中列出了在这些早期版本上工作的人员，在这里也得到了认可。作者还要感谢David Black、Mark Baugher、Gonzalo Camarillo、Paul Kyzivat和Thomas Stach对本文件的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]Camarillo，G.，Ed.，Marshall，W.，Ed.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032]Camarillo，G.和P.Kyzivat，“会话启动协议（SIP）先决条件框架的更新”，RFC 4032，2005年3月。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[SDESC] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[SDESC]Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 45681006年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[SRTP]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", Work in Progress, September 2007.
[ICE]Rosenberg，J.，“交互式连接建立（ICE）：多媒体会话建立协议的网络地址转换器（NAT）遍历方法”，正在进行的工作，2007年9月。
[KMGMT] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[KMGMT]Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[MIKEY]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“MIKEY:多媒体互联网键控”，RFC 3830，2004年8月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 32622，2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[HERFP] Mahy, R., "A Solution to the Heterogeneous Error Response Forking Problem (HERFP) in the Session Initiation Protocol (SIP)", Work in Progress, March 2006.
[HERFP]Mahy，R.，“会话启动协议（SIP）中异构错误响应分叉问题（HERFP）的解决方案”，正在进行的工作，2006年3月。
[SDPCN] Andreasen, F., "SDP Capability Negotiation", Work in Progress, July 2007.
[SDPCN]Andreasen，F.，“SDP能力谈判”，正在进行的工作，2007年7月。
Authors' Addresses
作者地址
Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, New Jersey 08837 USA
Flemming Andreasen Cisco Systems，Inc.美国新泽西州爱迪生市索纳尔街499号8楼，邮编08837
EMail: fandreas@cisco.com
EMail: fandreas@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.