Network Working Group J. Arkko
Request for Comments: 4567 F. Lindholm
Category: Standards Track M. Naslund
K. Norrman
Ericsson
E. Carrara
Royal Institute of Technology
July 2006
Network Working Group J. Arkko
Request for Comments: 4567 F. Lindholm
Category: Standards Track M. Naslund
K. Norrman
Ericsson
E. Carrara
Royal Institute of Technology
July 2006
Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)
会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.
本文档定义了会话描述协议（SDP）和实时流协议（RTSP）的通用扩展，以按照密钥管理协议的规定承载消息，从而保护媒体安全。这些扩展作为一个框架提供，供一个或多个密钥管理协议使用。因此，它们的使用只有在得到适当的密钥管理协议的补充时才有意义。
General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined.
还提供了关于如何将框架与SIP和RTSP一起使用的一般指南。还定义了多媒体互联网密钥（MIKEY）密钥管理协议的用法。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Notational Conventions .....................................4
2. Applicability ...................................................4
3. Extensions to SDP and RTSP ......................................5
3.1. SDP Extensions .............................................5
3.2. RTSP Extensions ............................................6
4. Usage with SDP, SIP, RTSP, and SAP ..............................7
4.1. Use of SDP .................................................8
4.1.1. General Processing ..................................8
4.1.2. Use of SDP with Offer/Answer and SIP ...............10
4.1.3. Use of SDP with SAP ................................13
4.1.4. Bidding-Down Attack Prevention .....................13
4.2. RTSP Usage ................................................14
5. Example Scenarios ..............................................17
5.1. Example 1 (SIP/SDP) .......................................17
5.2. Example 2 (SDP) ...........................................18
5.3. Example 3 (RTSP) ..........................................18
5.4. Example 4 (RTSP) ..........................................20
6. Adding Further Key Management Protocols ........................21
7. Integration of MIKEY ...........................................22
7.1. MIKEY Interface ...........................................22
8. Security Considerations ........................................23
9. IANA Considerations ............................................25
9.1. SDP Attribute Registration ................................25
9.2. RTSP Registration .........................................26
9.3. Protocol Identifier Registration ..........................26
10. Acknowledgements ..............................................27
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................28
1. Introduction ....................................................3
1.1. Notational Conventions .....................................4
2. Applicability ...................................................4
3. Extensions to SDP and RTSP ......................................5
3.1. SDP Extensions .............................................5
3.2. RTSP Extensions ............................................6
4. Usage with SDP, SIP, RTSP, and SAP ..............................7
4.1. Use of SDP .................................................8
4.1.1. General Processing ..................................8
4.1.2. Use of SDP with Offer/Answer and SIP ...............10
4.1.3. Use of SDP with SAP ................................13
4.1.4. Bidding-Down Attack Prevention .....................13
4.2. RTSP Usage ................................................14
5. Example Scenarios ..............................................17
5.1. Example 1 (SIP/SDP) .......................................17
5.2. Example 2 (SDP) ...........................................18
5.3. Example 3 (RTSP) ..........................................18
5.4. Example 4 (RTSP) ..........................................20
6. Adding Further Key Management Protocols ........................21
7. Integration of MIKEY ...........................................22
7.1. MIKEY Interface ...........................................22
8. Security Considerations ........................................23
9. IANA Considerations ............................................25
9.1. SDP Attribute Registration ................................25
9.2. RTSP Registration .........................................26
9.3. Protocol Identifier Registration ..........................26
10. Acknowledgements ..............................................27
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................28
There has recently been work to define a security profile for the protection of real-time applications running over RTP, [SRTP]. However, a security protocol needs a key management solution to exchange keys and security parameters, manage and refresh keys, etc.
最近有一项工作是定义一个安全配置文件，用于保护通过RTP[SRTP]运行的实时应用程序。然而，安全协议需要密钥管理解决方案来交换密钥和安全参数、管理和刷新密钥等。
A key management protocol is executed prior to the security protocol's execution. The key management protocol's main goal is to, in a secure and reliable way, establish a security association for the security protocol. This includes one or more cryptographic keys and the set of necessary parameters for the security protocol, e.g., cipher and authentication algorithms to be used. The key management protocol has similarities with, e.g., SIP [SIP] and RTSP [RTSP] in the sense that it negotiates necessary information in order to be able to set up the session.
密钥管理协议在执行安全协议之前执行。密钥管理协议的主要目标是以安全可靠的方式为安全协议建立安全关联。这包括一个或多个加密密钥和安全协议的一组必要参数，例如，要使用的密码和认证算法。密钥管理协议与例如SIP[SIP]和RTSP[RTSP]具有相似性，因为它协商必要的信息以便能够建立会话。
The focus in the following sections is to describe a new SDP attribute and RTSP header extension to support key management, and to show how these can be integrated within SIP and RTSP. The resulting framework is completed by one or more key management protocols, which use the extensions provided.
以下各节的重点是描述一个新的SDP属性和RTSP头扩展，以支持密钥管理，并说明如何将它们集成到SIP和RTSP中。生成的框架由一个或多个密钥管理协议完成，这些协议使用提供的扩展。
Some of the motivations to create a framework with the possibility to include the key management in the session establishment are:
创建一个框架并在会话建立中包含密钥管理的一些动机是：
* Just as the codec information is a description of how to encode and decode the audio (or video) stream, the key management data is a description of how to encrypt and decrypt the data.
* 正如编解码器信息是对如何编码和解码音频（或视频）流的描述，密钥管理数据是对如何加密和解密数据的描述。
* The possibility to negotiate the security for the entire multimedia session at the same time.
* 同时协商整个多媒体会话的安全性的可能性。
* The knowledge of the media at session establishment makes it easy to tie the key management to the multimedia sessions.
* 会话建立时对媒体的了解使密钥管理与多媒体会话相结合变得容易。
* This approach may be more efficient than setting up the security later, as that approach might force extra roundtrips, possibly also a separate setup for each stream, hence implying more delay to the actual setup of the media session.
* 这种方法可能比以后设置安全性更有效，因为这种方法可能会强制额外的往返，也可能是每个流的单独设置，因此意味着媒体会话的实际设置会有更多的延迟。
* The possibility to negotiate keying material end-to-end without applying end-to-end protection of the SDP (instead, hop-by-hop security mechanisms can be used, which may be useful if intermediate proxies need access to the SDP).
* 在不应用SDP的端到端保护的情况下端到端协商密钥材料的可能性（相反，可以使用逐跳安全机制，如果中间代理需要访问SDP，这可能很有用）。
Currently in SDP [SDPnew], there exists one field to transport keys, the "k=" field. However, this is not enough for a key management protocol as there are many more parameters that need to be transported, and the "k=" field is not extensible. The approach used is to extend the SDP description through a number of attributes that transport the key management offer/answer and also to associate it with the media sessions. SIP uses the offer/answer model [OAM] whereby extensions to SDP will be enough. However, RTSP [RTSP] does not use the offer/answer model with SDP, so a new RTSP header is introduced to convey key management data. [SDES] uses the approach of extending SDP, to carry the security parameters for the media streams. However, the mechanism defined in [SDES] requires end-to-end protection of the SDP by some security protocol such as S/MIME, in order to get end-to-end protection. The solution described here focuses only on the end-to-end protection of key management parameters and as a consequence does not require external end-to-end protection means. It is important to note though, and we stress this again, that only the key management parameters are protected.
目前在SDP[SDPnew]中，有一个字段可以传输密钥，“k=”字段。但是，这对于密钥管理协议来说是不够的，因为需要传输更多的参数，并且“k=”字段不可扩展。使用的方法是通过传输密钥管理提供/应答的多个属性扩展SDP描述，并将其与媒体会话关联。SIP使用提供/应答模型[OAM]，因此对SDP的扩展就足够了。然而，RTSP[RTSP]不使用SDP的提供/应答模型，因此引入了一个新的RTSP报头来传递密钥管理数据。[SDES]采用扩展SDP的方法，携带媒体流的安全参数。然而，[SDES]中定义的机制需要通过一些安全协议（如S/MIME）对SDP进行端到端保护，以获得端到端保护。这里描述的解决方案只关注关键管理参数的端到端保护，因此不需要外部端到端保护手段。但是，需要注意的是，我们再次强调，只有关键管理参数受到保护。
The document also defines the use of the described framework together with the key management protocol Multimedia Internet KEYing (MIKEY) [MIKEY].
本文件还定义了所述框架以及密钥管理协议多媒体互联网密钥（MIKEY）[MIKEY]的使用。
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]中所述进行解释。
[SDES] provides similar cryptographic key distribution capabilities, and it is intended for use when keying material is protected along with the signaling.
[SDES]提供了类似的加密密钥分发功能，其目的是在密钥材料与信令一起受到保护时使用。
In contrast, this specification expects endpoints to have preconfigured keys or common security infrastructure. It provides its own security and is independent of the protection of signaling (if any). As a result, it can be applied in environments where signaling protection is not turned on, or used hop-by-hop (i.e., scenarios where the SDP is not protected end-to-end). This specification will, independently of the signaling protection applied, ensure end-to-end security establishment for the media.
相反，该规范要求端点具有预配置的密钥或公共安全基础结构。它提供自己的安全性，并且独立于信令保护（如果有）。因此，它可以应用于未启用信令保护的环境中，或逐跳使用（即，SDP未端到端保护的场景）。本规范将独立于所应用的信令保护，确保媒体的端到端安全。
This section describes common attributes that can be included in SDP or RTSP when an integrated key management protocol is used. The attribute values follow the general SDP and RTSP guidelines (see [SDPnew] and [RTSP]).
本节介绍使用集成密钥管理协议时SDP或RTSP中可以包含的常见属性。属性值遵循一般SDP和RTSP指南（请参见[SDPnew]和[RTSP]）。
For both SDP and RTSP, the general method of adding the key management protocol is to introduce new attributes, one identifier to identify the specific key management protocol, and one data field where the key management protocol data is placed. The key management protocol data contains the necessary information to establish the security protocol, e.g., keys and cryptographic parameters. All parameters and keys are protected by the key management protocol.
对于SDP和RTSP，添加密钥管理协议的一般方法是引入新属性、一个标识特定密钥管理协议的标识符和一个放置密钥管理协议数据的数据字段。密钥管理协议数据包含建立安全协议所需的信息，例如密钥和密码参数。所有参数和密钥均受密钥管理协议保护。
The key management data SHALL be base64 [RFC3548] encoded and comply with the base64 grammar as defined in [SDPnew]. The key management protocol identifier, KMPID, is defined as below in Augmented Backus-Naur Form grammar (ABNF) [RFC4234].
密钥管理数据应为base64[RFC3548]编码，并符合[SDPnew]中定义的base64语法。密钥管理协议标识符KMPID在增广巴科斯-诺尔形式语法（ABNF）[RFC4234]中定义如下。
KMPID = 1*(ALPHA / DIGIT)
KMPID = 1*(ALPHA / DIGIT)
Values for the identifier, KMPID, are registered and defined in accordance to Section 9. Note that the KMPID is case sensitive, and it is RECOMMENDED that values registered are lowercase letters.
标识符KMPID的值根据第9节进行注册和定义。请注意，KMPID区分大小写，建议注册的值为小写字母。
This section provides an ABNF grammar (as used in [SDPnew]) for the key management extensions to SDP.
本节为SDP的密钥管理扩展提供ABNF语法（如[SDPnew]中所用）。
Note that the new definitions are compliant with the definition of an attribute field, i.e.,
请注意，新定义符合属性字段的定义，即。，
attribute = (att-field ":" att-value) / att-field
attribute = (att-field ":" att-value) / att-field
The ABNF for the key management extensions (conforming to the att-field and att-value) are as follows:
密钥管理扩展的ABNF（符合att字段和att值）如下所示：
key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value
密钥管理属性=密钥管理附件字段：“密钥管理附件值”
key-mgmt-att-field = "key-mgmt" key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data
密钥管理附件字段=“密钥管理”密钥管理附件值=0*1SP prtcl id SP密钥管理数据
prtcl-id = KMPID ; e.g., "mikey"
prtcl id=KMPID；e、 g.“米奇”
keymgmt-data = base64
SP = %x20
keymgmt-data = base64
SP = %x20
where KMPID is as defined in Section 3 of this memo, and base64 is as defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined for KMPID in Section 9.
其中KMPID定义见本备忘录第3节，base64定义见SDP[SDPnew]。Prtcl id是指第9节中为KMPID定义的一组值。
The attribute MAY be used at session level, media level, or at both levels. An attribute defined at media level overrides an attribute defined at session level. In other words, if the media-level attribute is present, the session level attribute MUST be ignored for this media. Section 4.1 describes in detail how the attributes are used and how the SDP is handled in different usage scenarios. The choice of the level depends, for example, on the particular key management protocol. Some protocols may not be able to derive enough key material for all the sessions; furthermore, possibly a different protection to each session could be required. The particular protocol might achieve this only by specifying it at the media level. Other protocols, such as MIKEY, have instead those capabilities (as it can express multiple security policies and derive multiple keys), so it may use the session level.
该属性可以在会话级别、媒体级别或两个级别上使用。在媒体级别定义的属性覆盖在会话级别定义的属性。换句话说，如果存在媒体级别属性，则必须忽略此媒体的会话级别属性。第4.1节详细描述了如何使用属性，以及在不同的使用场景中如何处理SDP。级别的选择取决于特定的密钥管理协议。某些协议可能无法为所有会话导出足够的密钥材料；此外，可能需要为每个会话提供不同的保护。特定协议可能仅通过在媒体级别指定它来实现这一点。其他协议，如MIKEY，则具有这些功能（因为它可以表示多个安全策略并派生多个密钥），因此它可以使用会话级别。
To support the key management attributes, the following RTSP header is defined:
为支持密钥管理属性，定义了以下RTSP标头：
KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec)
KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec)
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %x22 URI %x22 ";"]
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %x22 URI %x22 ";"]
where KMPID is as defined in Section 3 of this memo, "base64" as defined in [SDPnew], and "URI" as defined in Section 3 of [RFC3986].
其中KMPID如本备忘录第3节所定义，[SDPnew]中定义的“base64”，以及[RFC3986]第3节中定义的“URI”。
The "uri" parameter identifies the context for which the key management data applies, and the RTSP URI SHALL match a (session or media) URI present in the description of the session. If the RTSP aggregated control URI is included, it indicates that the key management message is on session level (and similarly the RTSP media control URI that it applies to the media level). If no "uri" parameter is present in a key-mgmt-spec the specification applies to the context identified by the RTSP request URI.
“uri”参数标识密钥管理数据适用的上下文，RTSP uri应与会话描述中存在的（会话或媒体）uri匹配。如果包含RTSP聚合控制URI，则表示密钥管理消息位于会话级别（与应用于媒体级别的RTSP媒体控制URI类似）。如果密钥管理规范中不存在“uri”参数，则该规范适用于RTSP请求uri标识的上下文。
The KeyMgmt header MAY be used in the messages and directions described in the table below.
KeyMgmt报头可用于下表中描述的消息和方向。
Method | Direction | Requirement
---------------------------------------------
DESCRIBE response | S->C | RECOMMENDED
SETUP | C->S | REQUIRED
SETUP Response | S->C | REQUIRED (error)
Method | Direction | Requirement
---------------------------------------------
DESCRIBE response | S->C | RECOMMENDED
SETUP | C->S | REQUIRED
SETUP Response | S->C | REQUIRED (error)
Note: Section 4.2 describes in detail how the RTSP extensions are used.
注：第4.2节详细描述了如何使用RTSP扩展。
We define one new RTSP status code to report error due to any failure during the key management processing (Section 4.2):
我们定义了一个新的RTSP状态代码，以报告由于密钥管理处理过程中的任何故障而导致的错误（第4.2节）：
Status-Code = "463" ; Key management failure
状态代码=“463”；密钥管理失败
A 463 response MAY contain a KeyMgmt header with a key management protocol message that further indicates the nature of the error.
463响应可包含具有进一步指示错误性质的密钥管理协议消息的密钥管理报头。
This section gives rules and recommendations of how/when to include the defined key management attribute when SIP and/or RTSP are used together with SDP.
本节给出了当SIP和/或RTSP与SDP一起使用时，如何/何时包括定义的密钥管理属性的规则和建议。
When a key management protocol is integrated with SIP/SDP and RTSP, the following general requirements are placed on the key management:
当密钥管理协议与SIP/SDP和RTSP集成时，对密钥管理提出以下一般要求：
* At the current time, it MUST be possible to execute the key management protocol in at most one request-response message exchange. Future relaxation of this requirement is possible but would introduce significant complexity for implementations supporting multi-roundtrip mechanisms.
* 目前，必须能够在最多一次请求-响应消息交换中执行密钥管理协议。未来可以放宽这一要求，但这将为支持多往返机制的实现带来极大的复杂性。
* It MUST be possible from the SIP/SDP and RTSP application, using the key management API, to receive key management data and information of whether or not a message is accepted.
* 必须能够使用密钥管理API从SIP/SDP和RTSP应用程序接收密钥管理数据和消息是否被接受的信息。
The content of the key management messages depends on the key management protocol that is used. However, the content of such key management messages might be expected to be roughly as follows: the key management Initiator (e.g., the offerer) includes the key management data in a first message, containing the media description it should apply to. This data in general consists of the security parameters (including key material) needed to secure the communication, together with the necessary authentication information (to ensure that the message is authentic).
密钥管理消息的内容取决于所使用的密钥管理协议。然而，这类密钥管理消息的内容可能大致如下：密钥管理发起方（例如，要约人）在第一消息中包括密钥管理数据，其中包含它应该应用于的媒体描述。这些数据通常包括确保通信安全所需的安全参数（包括密钥材料）以及必要的身份验证信息（以确保消息的真实性）。
At the Responder's side, the key management protocol checks the validity of the key management message, together with the availability of the parameters offered, and then provides the key management data to be included in the answer. This answer may typically authenticate the Responder to the Initiator, and also state if the initial offer was accepted or not. Certain protocols might require the Responder to include a selection of the security parameters that he is willing to support. Again, the actual content of such responses is dependent on the particular key management protocol.
在响应方，密钥管理协议检查密钥管理消息的有效性以及提供的参数的可用性，然后提供要包含在应答中的密钥管理数据。该答案通常可以向发起者验证响应者，还可以说明初始报价是否被接受。某些协议可能要求响应者选择他愿意支持的安全参数。同样，此类响应的实际内容取决于特定的密钥管理协议。
Section 7 describes a realization of the MIKEY protocol using these mechanisms. Procedures to be used when mapping new key management protocols onto this framework are described in Section 6.
第7节描述了使用这些机制实现MIKEY协议。第6节描述了将新密钥管理协议映射到此框架时要使用的步骤。
This section describes the processing rules for the different applications that use SDP for the key management.
本节介绍使用SDP进行密钥管理的不同应用程序的处理规则。
The processing when SDP is used is slightly different according to the way SDP is transported, and if it uses an offer/answer or announcement. The processing can be divided into four different steps:
根据SDP的传输方式以及SDP是否使用要约/应答或公告，使用SDP时的处理略有不同。处理过程可分为四个不同的步骤：
1) How to create the initial offer. 2) How to handle a received offer. 3) How to create an answer. 4) How to handle a received answer.
1) 如何创建初始报价。2） 如何处理收到的报价。3） 如何创建答案。4） 如何处理收到的答复。
It should be noted that the last two steps may not always be applicable, as there are cases where an answer cannot or will not be sent back.
应注意的是，最后两个步骤可能并不总是适用的，因为在某些情况下，答案无法或不会返回。
The general processing for creating an initial offer SHALL follow the following actions:
创建初始报价的一般处理应遵循以下操作：
* The identifier of the key management protocol used MUST be placed in the prtcl-id field of SDP. A table of legal protocols identifiers is maintained by IANA (see Section 9).
* 所用密钥管理协议的标识符必须放在SDP的prtcl id字段中。IANA维护法律协议标识符表（见第9节）。
* The keymgmt-data field MUST be created as follows: the key management protocol MUST be used to create the key management message. This message SHALL be base64 encoded [RFC3548] by the SDP application and then encapsulated in the keymgmt-data attribute. Note though that the semantics of the encapsulated message is dependent on the key management protocol that is used.
* keymgmt数据字段必须按如下方式创建：必须使用密钥管理协议来创建密钥管理消息。该消息应由SDP应用程序进行base64编码[RFC3548]，然后封装在keymgmt数据属性中。请注意，封装消息的语义取决于所使用的密钥管理协议。
The general processing for handling a received offer SHALL follow the following actions:
处理收到的报价的一般处理应遵循以下操作：
* The key management protocol is identified according to the prtcl-id field. A table of legal protocols identifiers is maintained by IANA (Section 9).
* 密钥管理协议根据prtcl id字段进行标识。IANA维护法律协议标识符表（第9节）。
* The key management data from the keymgmt-data field MUST be extracted, base64 decoded to reconstruct the original message, and then passed to the key management protocol for processing. Note that depending on key management protocol, some extra parameters might also be requested by the specific API, such as the source/destination network address/port(s) for the specified media (however, this will be implementation specific depending on the actual API). The extra parameters that a key management protocol might need (other than the ones defined here) MUST be documented, describing their use, as well as the interaction of that key management protocol with SDP and RTSP.
* 必须提取keymgmt数据字段中的密钥管理数据，对其进行base64解码以重构原始消息，然后将其传递给密钥管理协议进行处理。请注意，根据密钥管理协议，特定API也可能会请求一些额外参数，例如指定媒体的源/目标网络地址/端口（但是，这将取决于实际API的具体实现）。密钥管理协议可能需要的额外参数（此处定义的参数除外）必须记录在案，描述其使用，以及该密钥管理协议与SDP和RTSP的交互作用。
* If errors occur, or the key management offer is rejected, the session SHALL be aborted. Possible error messages are dependent on the specific session establishment protocol.
* 如果出现错误，或者密钥管理提议被拒绝，会话将被中止。可能的错误消息取决于特定的会话建立协议。
At this stage, the key management will have either accepted or rejected the offered parameters. This MAY cause a response message to be generated, depending on the key management protocol and the application scenario.
在此阶段，密钥管理将接受或拒绝提供的参数。这可能导致生成响应消息，具体取决于密钥管理协议和应用程序场景。
If an answer is to be generated, the following general actions SHALL be performed:
如果要生成答案，应执行以下一般操作：
* The identifier of the key management protocol used MUST be placed in the prtcl-id field.
* 所用密钥管理协议的标识符必须放在prtcl id字段中。
* The keymgmt-data field MUST be created as follows. The key management protocol MUST be used to create the key management message. This message SHALL be base64 encoded [RFC3548] by the SDP application and then encapsulated in the keymgmt-data attribute. The semantics of the encapsulated message is dependent on the key management protocol that is used.
* 必须按如下方式创建keymgmt数据字段。必须使用密钥管理协议来创建密钥管理消息。该消息应由SDP应用程序进行base64编码[RFC3548]，然后封装在keymgmt数据属性中。封装消息的语义取决于所使用的密钥管理协议。
The general processing for handling a received answer SHALL follow the following actions:
处理收到的答复的一般处理应遵循以下操作：
* The key management protocol is identified according to the prtcl-id field.
* 密钥管理协议根据prtcl id字段进行标识。
* The key management data from the keymgmt-data field MUST be extracted, base64 decoded to reconstruct the original message, and then passed to the key management protocol for processing.
* 必须提取keymgmt数据字段中的密钥管理数据，对其进行base64解码以重构原始消息，然后将其传递给密钥管理协议进行处理。
* If the key management offer is rejected and the intent is to re-negotiate it, it MUST be done through another Offer/Answer exchange. It is RECOMMENDED to NOT abort the session in that case, but to re-negotiate using another Offer/Answer exchange. For example, in [SIP], the "security precondition" as defined in [SPREC] solves the problem for a session initiation. The procedures in [SPREC] are outside the scope of this document. In an established session, an additional Offer/Answer exchange using a re-INVITE or UPDATE as appropriate MAY be used
* 如果密钥管理提议被拒绝，并且意图重新协商，则必须通过另一个提议/应答交换来完成。在这种情况下，建议不要中止会话，而是使用另一个报价/应答交换重新协商。例如，在[SIP]中，[SPREC]中定义的“安全先决条件”解决了会话启动的问题。[SPREC]中的程序不在本文件范围内。在已建立的会话中，可以使用使用重新邀请或更新（视情况而定）的附加要约/应答交换
* If errors occur, or the key management offer is rejected and there is no intent to re-negotiate it, the session SHALL be aborted. If possible, an error message indicating the failure SHOULD be sent back.
* 如果出现错误，或者密钥管理提议被拒绝，并且没有重新协商的意图，会话将被中止。如果可能，应发回指示故障的错误消息。
Otherwise, if all the steps are successful, the normal setup proceeds.
否则，如果所有步骤都成功，则正常设置将继续进行。
This section defines additional processing rules, to the general rules defined in Section 4.1.1, applicable only to applications using SDP with the offer/answer model [OAM] (and in particular SIP).
本节定义了第4.1.1节中定义的一般规则之外的其他处理规则，仅适用于使用SDP和提供/应答模型[OAM]（尤其是SIP）的应用程序。
When an initial offer is created, the following offer/answer-specific procedure SHALL be applied:
创建初始报价时，应采用以下报价/答复特定程序：
* Before creating the key management data field, the list of protocol identifiers MUST be provided by the SDP application to (each) key management protocol, as defined in Section 4.1.4 (to defeat bidding-down attacks).
* 在创建密钥管理数据字段之前，SDP应用程序必须向（每个）密钥管理协议提供协议标识符列表，如第4.1.4节中所定义（以击败竞价拒绝攻击）。
For a received SDP offer that contains the key management attributes, the following offer/answer-specific procedure SHALL be applied:
对于收到的包含关键管理属性的SDP报价，应采用以下报价/应答特定程序：
* Before, or in conjunction with, passing the key management data to the key management protocol, the complete list of protocol identifiers from the offer message is provided by the SDP application to the key management protocol (as defined in Section 4.1.4).
* 在将密钥管理数据传递给密钥管理协议之前，或与之一起，SDP应用程序向密钥管理协议（如第4.1.4节所定义）提供来自要约消息的协议标识符的完整列表。
When an answer is created, the following offer/answer-specific procedure SHALL be applied:
创建答案时，应采用以下报价/答案特定程序：
* If the key management rejects the offer and the intent is to re-negotiate it, the Answer SHOULD include the cause of failure in an included message from the key management protocol. The renegotiation MUST be done through another Offer/Answer exchange (e.g., using [SPREC]). In an established session, it can also be done through a re-INVITE or UPDATE as appropriate.
* 如果密钥管理拒绝该提议，并且打算重新协商该提议，则答案应包括来自密钥管理协议的包含消息中的失败原因。必须通过另一个报价/应答交换（例如，使用[SPREC]）进行重新协商。在已建立的会话中，还可以根据需要通过重新邀请或更新来完成。
* If the key management rejects the offer and the session needs to be aborted, the answerer SHOULD return a "488 Not Acceptable Here" message, optionally also including one or more Warning headers (a "306 Attribute not understood" when one of the parameters is not supported, and a "399 Miscellaneous warning" with arbitrary information to be presented to a human user or logged; see Section 20.43 in [SIP]). Further details about the cause of failure MAY be described in an included message from the key management protocol. The session is then aborted (and it is up to local policy or end user to decide how to continue).
* 如果密钥管理拒绝该提议，并且会话需要中止，应答者应返回“488此处不可接受”消息，可选地还包括一个或多个警告头（当其中一个参数不受支持时为“306属性未理解”，以及“399杂项警告”向人类用户提供或记录任意信息；见[SIP]第20.43节。关于故障原因的进一步细节可以在来自密钥管理协议的包括消息中描述。然后中止会话（由本地策略或最终用户决定如何继续）。
Note that the key management attribute (related to the same key management protocol) MAY be present both at session level and at media level. Consequently, the process SHALL be repeated for each such key management attribute detected. In case the key management processing of any such attribute does not succeed (e.g., authentication failure, parameters not supported, etc.), on either session or media level, the entire session setup SHALL be aborted, including those parts of the session that successfully completed their part of the key management.
请注意，密钥管理属性（与相同的密钥管理协议相关）可能在会话级别和媒体级别都存在。因此，应针对检测到的每个此类密钥管理属性重复该过程。如果在会话或媒体级别上，任何此类属性的密钥管理处理未成功（例如，身份验证失败、参数不受支持等），则应中止整个会话设置，包括成功完成其密钥管理部分的会话部分。
If more than one key management protocol is supported, multiple instances of the key management attribute MAY be included in the initial offer when using the offer/answer model, each transporting a different key management protocol, thus indicating supported alternatives.
如果支持多个密钥管理协议，则当使用提供/应答模型时，密钥管理属性的多个实例可包括在初始提供中，每个实例传输不同的密钥管理协议，从而指示支持的备选方案。
If the offerer includes more than one key management protocol attribute at session level (analogous for the media level), these SHOULD be listed in order of preference (the first being the preferred). The answerer selects the key management protocol it wishes to use, and processes only it, on either session or media
如果报价人在会话级别（类似于媒体级别）包含多个密钥管理协议属性，则应按优先顺序列出这些属性（第一个为优先）。应答者选择希望使用的密钥管理协议，并在会话或媒体上仅处理该协议
level, or on both, according to where located. If the answerer does not support any of the offerer's suggested key management protocols, the answerer indicates this to the offerer so a new Offer/Answer can be triggered; alternatively, it may return a "488 Not Acceptable Here" error message, whereby the sender MUST abort the current setup procedure.
根据位置，在水平面或两者上。如果应答人不支持报价人建议的任何密钥管理协议，则应答人向报价人表明这一点，以便触发新的报价/应答；或者，它可能返回“488此处不可接受”错误消息，发送方必须中止当前设置过程。
Note that the placement of multiple key management offers in a single message has the disadvantage that the message expands and the computational workload for the offerer will increase drastically. Unless the guidelines of Section 4.1.4 are followed, multiple lines may open up bidding-down attacks. Note also that the multiple-offer option has been added to optimize signaling overhead in case the Initiator knows some key (e.g., a public key) that the Responder has, but is unsure of what protocol the Responder supports. The mechanism is not intended to negotiate options within one and the same protocol.
请注意，在单个消息中放置多个密钥管理提议的缺点是消息会扩展，并且提议者的计算工作量将急剧增加。除非遵循第4.1.4节的指导原则，否则多条线路可能会引发竞价下跌攻击。还请注意，添加了多个提供选项以优化信令开销，以防发起方知道响应方拥有的某些密钥（例如公钥），但不确定响应方支持的协议。该机制不用于在同一协议内协商选项。
The offerer MUST include the key management data within an offer that contains the media description it applies to.
报价人必须在包含其适用的媒体描述的报价中包含密钥管理数据。
Re-keying MUST be handled as a new offer, with the new proposed parameters. The answerer treats this as a new offer where the key management is the issue of change. The re-keying exchange MUST be finalized before the security protocol can change the keys. The same key management protocol used in the original offer SHALL also be used in the new offer carrying re-keying. If the new offer carrying re-keying fails (e.g., the authentication verification fails), the answerer SHOULD send a "488 Not Acceptable Here" message, including one or more Warning headers (at least a 306). The offerer MUST then abort the session.
重新设置密钥必须作为新的报价处理，并提供新的建议参数。回答者将此视为一个新的提议，其中关键管理是变更问题。在安全协议更改密钥之前，必须完成密钥交换。原始报价中使用的相同密钥管理协议也应用于新报价中，并进行重新密钥设置。如果新的报价携带重新键入失败（例如，身份验证失败），应答者应发送“488此处不可接受”消息，包括一个或多个警告标头（至少306）。然后，报价人必须中止会话。
Note that, in multicast scenarios, unlike unicast, there is only a single view of the stream [OAM], hence there MUST be a uniform agreement of the security parameters.
请注意，在多播场景中，与单播不同，流[OAM]只有一个视图，因此必须对安全参数达成一致。
After the offer is issued, the offerer SHOULD be prepared to receive media, as the media may arrive prior to the answer. However, this brings issues, as the offerer does not know yet the answerer's choice in terms of, e.g., algorithms, or possibly the key is known. This can cause delay or clipping can occur; if this is unacceptable, the offerer SHOULD use mechanisms outside the scope of this document, e.g., the security preconditions for SIP [SPREC].
发盘后，发盘人应准备好接受媒体，因为媒体可能会在答复之前到达。然而，这带来了一些问题，因为报价人还不知道应答人在算法方面的选择，或者可能知道密钥。这可能会导致延迟或发生削波；如果这是不可接受的，报价人应使用本文件范围以外的机制，例如SIP[SPREC]的安全先决条件。
There are cases where SDP is used without conforming to the offer/answer model; instead, it is a one-way SDP distribution (i.e., without back channel), such as when used with SAP and HTTP.
在某些情况下，SDP的使用不符合报价/应答模型；相反，它是单向SDP分发（即，没有反向通道），例如与SAP和HTTP一起使用时。
The processing follows the two first steps of the general SDP processing (see Section 4.1.1). It can be noted that the processing in this case differs from the offer/answer case in that only one key management protocol SHALL be offered (i.e., no negotiation will be possible). This implies that the bidding-down attack is not an issue; therefore, the countermeasure is not needed. The key management protocol used MUST support one-way messages.
处理遵循一般SDP处理的前两个步骤（见第4.1.1节）。可以注意到，这种情况下的处理不同于提供/应答情况，因为只应提供一个密钥管理协议（即，不可能进行协商）。这意味着降价攻击不是问题；因此，不需要采取对策。使用的密钥管理协议必须支持单向消息。
The possibility to support multiple key management protocols may, unless properly handled, introduce bidding-down attacks. Specifically, a man-in-the-middle could "peel off" cryptographically strong offers (deleting the key management lines from the message), leaving only weaker ones as the Responder's choice. To avoid this, the list of identifiers of the proposed key management protocols MUST be authenticated. The authentication MUST be done separately by each key management protocol.
除非处理得当，否则支持多个密钥管理协议的可能性可能会引入竞价下降攻击。具体来说，中间人可以“剥离”加密功能强大的服务（从消息中删除密钥管理行），只留下较弱的服务作为响应者的选择。为了避免这种情况，必须对提议的密钥管理协议的标识符列表进行身份验证。每个密钥管理协议都必须单独进行身份验证。
Accordingly, it MUST be specified (in the key management protocol specification itself or in a companion document) how the list of key management protocol identifiers can be processed to be authenticated from the offerer to the answerer by the specific key management protocol. Note that even if only one key management protocol is used, that still MUST authenticate its own protocol identifier.
因此，必须规定（在密钥管理协议规范本身或配套文件中）如何处理密钥管理协议标识符列表，以通过特定密钥管理协议从提供方到应答方进行认证。请注意，即使只使用了一个密钥管理协议，它仍然必须验证自己的协议标识符。
The list of protocol identifiers MUST then be given to each of the selected (offered) key management protocols by the application with ";" separated identifiers. All the offered protocol identifiers MUST be included, in the same order as they appear in the corresponding SDP description.
然后，应用程序必须使用“；”分隔的标识符将协议标识符列表提供给每个选定（提供的）密钥管理协议。必须包括所有提供的协议标识符，其顺序与相应SDP描述中出现的顺序相同。
The protocol list can formally be described as
协议列表可以正式描述为
prtcl-list = KMPID *(";" KMPID)
prtcl-list = KMPID *(";" KMPID)
where KMPID is as defined in Section 3.
其中KMPID的定义见第3节。
For example, if the offered protocols are MIKEY and two yet-to-be-invented protocols KEYP1, KEYP2, the SDP is:
例如，如果提供的协议是MIKEY和两个尚未发明的协议KEYP1、KEYP2，则SDP是：
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=Secret discussion
t=0 0
c=IN IP4 lost.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD...
a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD...
m=audio 39000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 42000 RTP/SAVP 31
a=rtpmap:31 H261/90000
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=Secret discussion
t=0 0
c=IN IP4 lost.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD...
a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD...
m=audio 39000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 42000 RTP/SAVP 31
a=rtpmap:31 H261/90000
The protocol list, "mikey;keyp1;keyp2", would be generated from the SDP description and used as input to each specified key management protocol (together with the data for that protocol). Each of the three protocols includes this protocol identifier list in its authentication coverage (according to its protocol specification).
协议列表“mikey；keyp1；keyp2”将根据SDP描述生成，并用作每个指定密钥管理协议的输入（以及该协议的数据）。三个协议中的每一个都在其身份验证覆盖范围中包含此协议标识符列表（根据其协议规范）。
If more than one protocol is supported by the offerer, it is RECOMMENDED that all acceptable protocols are included in the first offer, rather than making single, subsequent alternative offers in response to error messages; see "Security Considerations".
如果报价人支持一个以上的协议，建议在第一次报价中包括所有可接受的协议，而不是针对错误消息做出单个后续备选报价；见“安全考虑”。
End-to-end integrity protection of the key-mgmt attributes altogether, provided externally to the key management itself, also protects against this bidding-down attack. This is, for example, the case if SIP uses S/MIME [RFC3851] to end-to-end integrity protect the SDP description. However, as this end-to-end protection is not an assumption of the framework, the mechanisms defined in this section SHALL be applied.
密钥管理属性的端到端完整性保护（从外部提供给密钥管理本身）也可以防止这种向下竞价攻击。例如，如果SIP使用S/MIME[RFC3851]来保护SDP描述的端到端完整性，就会出现这种情况。但是，由于这种端到端保护不是框架的假设，因此应采用本节中定义的机制。
RTSP does not use the offer/answer model, as SIP does. This causes some problems, as it is not possible (without modifying RTSP) to send back an answer. To solve this, a new header has been introduced (Section 3.2). This also assumes that the key management also has some kind of binding to the media, so that the response to the server will be processed as required.
RTSP不像SIP那样使用提供/应答模型。这会导致一些问题，因为（在不修改RTSP的情况下）无法发回答案。为了解决这个问题，引入了一个新的标题（第3.2节）。这还假设密钥管理还与媒体有某种绑定，以便根据需要处理对服务器的响应。
The server SHALL be the Initiator of the key management exchange for sessions in PLAY mode, i.e., transporting media from server to client. The below text describes the behavior for PLAY mode. For any other mode, the behavior is not defined in this specification.
服务器应是在播放模式下会话的密钥管理交换的发起方，即，将媒体从服务器传输到客户端。下面的文本描述了播放模式的行为。对于任何其他模式，该行为未在本规范中定义。
To obtain a session description, the client initially contacts the server via a DESCRIBE message. The initial key management message from the RTSP server is sent to the client in the SDP of the 200 OK in response to the DESCRIBE. Note that only one key management protocol SHALL be used per session/media level. A server MAY allow the SDP with key management attribute(s) to be distributed to the client through other means than RTSP, although this is not specified here.
为了获得会话描述，客户机首先通过描述消息与服务器联系。来自RTSP服务器的初始密钥管理消息被发送到200 OK的SDP中的客户端，以响应描述。请注意，每个会话/媒体级别只能使用一个密钥管理协议。服务器可允许通过RTSP以外的其他方式将具有密钥管理属性的SDP分发给客户端，尽管此处未指定。
The "uri" parameter of the KeyMgmt header is used to indicate for the key management protocol on what context the carried message applies. For key management messages on the SDP session level, the answer MUST contain the RTSP aggregated control URL to indicate this. For key management messages initially on SDP media level, the key management response message in the KeyMgmt header MAY use the RTSP media-level URL. For RTSP sessions not using aggregated control, i.e., no session-level control URI is defined, the key management protocol SHALL only be invoked on individual media streams. In this case also, the key management response SHALL be on individual media streams (i.e., one RTSP key management header per media).
KeyMgmt报头的“uri”参数用于指示密钥管理协议所携带的消息应用于什么上下文。对于SDP会话级别上的密钥管理消息，答案必须包含RTSP聚合控制URL以指示这一点。对于最初在SDP媒体级别上的密钥管理消息，KeyMgmt报头中的密钥管理响应消息可以使用RTSP媒体级别URL。对于未使用聚合控制的RTSP会话，即未定义会话级控制URI，只能在单个媒体流上调用密钥管理协议。在这种情况下，密钥管理响应也应在单个媒体流上（即，每个媒体一个RTSP密钥管理报头）。
When responding to the initial key management message, the client uses the new RTSP header (KeyMgmt) to send back an answer. How this is done depends on the usage context:
当响应初始密钥管理消息时，客户端使用新的RTSP头（KeyMgmt）发回应答。如何做到这一点取决于使用上下文：
* Key management protocol responses for the initial establishment of security parameters for an aggregated RTSP session SHALL be sent in the first SETUP of the session. This means that if the key management is declared for the whole session but is set up in non-aggregated fashion (i.e., one media per RTSP session), each SETUP MUST carry the same response for the session-level context. When performing a setup of the second or any subsequent media in an RTSP session, the same key management parameters as established for the first media also apply to these setups.
* 初始建立聚合RTSP会话安全参数的密钥管理协议响应应在会话的第一次设置中发送。这意味着，如果为整个会话声明密钥管理，但以非聚合方式设置（即，每个RTSP会话一个媒体），则每个设置必须为会话级上下文携带相同的响应。在RTSP会话中执行第二个或任何后续介质的设置时，为第一个介质建立的相同密钥管理参数也适用于这些设置。
* Key management responses for the initial establishment of security parameters for an individual media SHALL only be included in SETUP for the corresponding media stream.
* 初始建立单个媒体安全参数的密钥管理响应应仅包括在相应媒体流的设置中。
If a server receives a SETUP message in which it expects a key management message, but none is included, a "403 Forbidden" SHOULD be returned to the client, whereby the current setup MUST be aborted.
如果服务器收到一条安装消息，其中需要一条密钥管理消息，但没有包含任何消息，则应向客户端返回“403禁止”，因此必须中止当前安装。
When the server creates an initial SDP message, the procedure SHALL be the same as described in Section 4.1.1.
当服务器创建初始SDP消息时，程序应与第4.1.1节所述相同。
The client processing of the initial SDP message from the server SHALL follow the same procedures as described in Section 4.1.1, except that, if there is an error, the session is aborted (no error is sent back).
来自服务器的初始SDP消息的客户端处理应遵循第4.1.1节中所述的相同程序，但如果出现错误，则会中止会话（不会发回任何错误）。
The client SHALL create the response, using the key management header in RTSP, as follows:
客户端应使用RTSP中的密钥管理头创建响应，如下所示：
* The identifier of the key management protocol used (e.g., MIKEY) MUST be placed in the "prot" field of the header. The prot values are maintained by IANA (Section 9).
* 所用密钥管理协议的标识符（例如，MIKEY）必须放在报头的“prot”字段中。保护值由IANA维护（第9节）。
* The keymgmt-data field MUST be created as follows: the key management protocol MUST be used to create the key management message. This message SHALL be base64 encoded by the RTSP application and then encapsulated in the "data" field of the header. The semantics of the encapsulated message is dependent on the key management protocol that is used.
* keymgmt数据字段必须按如下方式创建：必须使用密钥管理协议来创建密钥管理消息。该消息应由RTSP应用程序进行base64编码，然后封装在报头的“数据”字段中。封装消息的语义取决于所使用的密钥管理协议。
* Include, if necessary, the URL to indicate the context in the "uri" parameter.
* 如有必要，请在“uri”参数中包含URL以指示上下文。
The server SHALL process a received key management header in RTSP as follows:
服务器应在RTSP中处理接收到的密钥管理头，如下所示：
* The key management protocol is identified according to the "prot" field.
* 密钥管理协议根据“prot”字段进行标识。
* The key management data from the "data" field MUST be extracted, base64 decoded to reconstruct the original message, and then passed to the key management protocol for processing.
* 必须提取“数据”字段中的密钥管理数据，对其进行base64解码以重构原始消息，然后将其传递给密钥管理协议进行处理。
* If the key management protocol is successful, the processing can proceed according to normal rules.
* 如果密钥管理协议成功，则可以按照正常规则进行处理。
* Otherwise, if the key management fails (e.g., due to authentication failure or parameter not supported), an error is sent back as the SETUP response using RTSP error code 463 (see Section 3.2) and the session is aborted. It is up to the key management protocol to specify (within the RTSP status code message or through key management messages) details about the type of error that occurred.
* 否则，如果密钥管理失败（例如，由于身份验证失败或参数不受支持），将使用RTSP错误代码463（参见第3.2节）将错误发送回设置响应，并中止会话。由密钥管理协议指定（在RTSP状态代码消息内或通过密钥管理消息）发生的错误类型的详细信息。
Re-keying within RTSP is for further study, given that media updating mechanisms within RTSP are unspecified at the time this document was written.
鉴于在编写本文档时RTSP中的媒体更新机制尚未明确，因此RTSP中的密钥更新有待进一步研究。
The following examples utilize MIKEY [MIKEY] as the key management protocol to be integrated into SDP and RTSP.
以下示例使用MIKEY[MIKEY]作为密钥管理协议，以集成到SDP和RTSP中。
A SIP call is taking place between Alice and Bob. Alice sends an INVITE message consisting of the following offer:
爱丽丝和鲍勃之间正在进行SIP通话。Alice发送一条邀请消息，包含以下内容：
v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff
e=alice@w-land.example.com
t=0 0
c=IN IP4 w-land.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEEoo2pee4hp2
UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0JKpgaVkDaawi9whVBtBt
0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUOSrzKTAv9zV
m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000
v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff
e=alice@w-land.example.com
t=0 0
c=IN IP4 w-land.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEEoo2pee4hp2
UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0JKpgaVkDaawi9whVBtBt
0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUOSrzKTAv9zV
m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000
That is, Alice proposes to set up one audio stream and one video stream that run over SRTP (signaled by the use of the SAVP profile). She uses MIKEY to set up the security parameters for SRTP (Section 7). The MIKEY message contains the security parameters, together with the necessary key material. Note that MIKEY is exchanging the crypto suite for both streams, as it is placed at the session level. Also, MIKEY provides its own security, i.e., when Bob processes Alice's MIKEY message, he will also find the signaling of the security parameters used to secure the MIKEY exchange. Alice's endpoint's authentication information is also carried within the MIKEY message, to prove that the message is authentic. The above MIKEY message is an example of message when the pre-shared method MIKEY is used.
也就是说，Alice建议设置一个在SRTP上运行的音频流和一个视频流（通过使用SAVP配置文件发出信号）。她使用MIKEY设置SRTP的安全参数（第7节）。MIKEY消息包含安全参数以及必要的密钥材料。请注意，MIKEY正在为这两个流交换加密套件，因为它位于会话级别。此外，MIKEY提供了自己的安全性，即当Bob处理Alice的MIKEY消息时，他还将找到用于保护MIKEY交换的安全参数的信令。Alice端点的身份验证信息也包含在MIKEY消息中，以证明消息是真实的。上述MIKEY消息是使用预共享方法MIKEY时的消息示例。
Upon receiving the offer, Bob checks the validity of the received MIKEY message, and, in case of successful verification, he accepts the offer and sends an answer back to Alice (with his authentication information, and, if necessary, also some key material from his side):
收到报价后，Bob检查收到的MIKEY消息的有效性，如果验证成功，Bob接受报价并向Alice发送回复（包括他的身份验证信息，必要时还包括他方提供的一些关键材料）：
v=0 o=bob 2891092897 2891092897 IN IP4 foo.example.com s=Cool stuff e=bob@foo.example.com
v=0 o=IP4 foo.example.com中的bob 2891092897 2891092897 s=Cool stuff e=bob@foo.example.com
t=0 0
c=IN IP4 foo.example.com
a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6gAAAAAJAAAQbWlja2
V5QG1vdXNlLmNvbQABn8HdGE5BMDXFIuGEga+62AgY5cc=
m=audio 49030 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000
t=0 0
c=IN IP4 foo.example.com
a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6gAAAAAJAAAQbWlja2
V5QG1vdXNlLmNvbQABn8HdGE5BMDXFIuGEga+62AgY5cc=
m=audio 49030 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000
Upon receiving the answer, Alice verifies the correctness of it. In case of success, at this point Alice and Bob share the security parameters and the keys needed for a secure RTP communication.
收到答案后，Alice验证其正确性。如果成功，此时Alice和Bob共享安全RTP通信所需的安全参数和密钥。
This example shows what Alice would have done if she wished to protect only the audio stream. She would have placed the MIKEY line at media level for the audio stream only (also specifying the use of the SRTP profile there, SAVP). The semantics of the MIKEY messages is as in the previous case, but applies only to the audio stream.
这个例子显示了如果Alice只想保护音频流，她会做什么。她会将MIKEY线路仅用于音频流的媒体级别（还指定了SRTP配置文件SAVP的使用）。MIKEY消息的语义与前一种情况相同，但仅适用于音频流。
v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff
e=alice@w-land.example.com
t=0 0
c=IN IP4 w-land.example.com
m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy...
m=video 52230 RTP/AVP 31
a=rtpmap:31 H261/90000
v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff
e=alice@w-land.example.com
t=0 0
c=IN IP4 w-land.example.com
m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy...
m=video 52230 RTP/AVP 31
a=rtpmap:31 H261/90000
Bob would then act as described in the previous example, including the MIKEY answer at the media level for the audio stream (as Alice did).
Bob随后将按照前面的示例中所述进行操作，包括音频流媒体级别的MIKEY应答（正如Alice所做的那样）。
Note that even if the key management attribute were specified at the session level, the video part would not be affected by this (as a security profile is not used, instead the RTP/AVP profile is signaled).
请注意，即使在会话级别指定了密钥管理属性，视频部分也不会受此影响（因为未使用安全配置文件，而是向RTP/AVP配置文件发送信号）。
A client wants to set up a streaming session and requests a media description from the streaming server.
客户端希望设置流式会话，并从流式服务器请求媒体描述。
DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp
From: user@example.com
CSeq: 312
Accept: application/sdp
From: user@example.com
The server sends back an OK message including an SDP description, together with the MIKEY message. The MIKEY message contains the necessary security parameters that the server is willing to offer to the client, together with authentication information (to prove that the message is authentic) and the key material. The SAVP profile also signals the use of SRTP for securing the media sessions.
服务器发回一条OK消息，包括SDP描述以及MIKEY消息。MIKEY消息包含服务器愿意提供给客户端的必要安全参数，以及身份验证信息（以证明消息是真实的）和密钥材料。SAVP配置文件还表示使用SRTP保护媒体会话。
RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 478
RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 478
v=0
o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com
s=Action Movie
e=action@movie.example.com
t=0 0
c=IN IP4 movie.example.com
a=control:rtsp://movie.example.com/action
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy...
m=audio 0 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=control:rtsp://movie.example.com/action/audio
m=video 0 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=control:rtsp://movie.example.com/action/video
v=0
o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com
s=Action Movie
e=action@movie.example.com
t=0 0
c=IN IP4 movie.example.com
a=control:rtsp://movie.example.com/action
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy...
m=audio 0 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=control:rtsp://movie.example.com/action/audio
m=video 0 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=control:rtsp://movie.example.com/action/video
The client checks the validity of the received MIKEY message, and, in case of successful verification, it accept the message. The client then includes its key management data in the SETUP request going back to the server, the client authentication information (to prove that the message is authentic), and, if necessary, some key material.
客户端检查接收到的MIKEY消息的有效性，如果验证成功，则接受该消息。然后，客户机在返回服务器的设置请求中包括其密钥管理数据、客户机身份验证信息（以证明消息是真实的），以及一些密钥材料（如有必要）。
SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action";
data="AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6g..."
SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action";
data="AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6g..."
The server processes the request including checking the validity of the key management header.
服务器处理请求，包括检查密钥管理头的有效性。
RTSP/1.0 200 OK
CSeq: 313
Session: 12345678
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001
RTSP/1.0 200 OK
CSeq: 313
Session: 12345678
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001
Note that in this case the key management line was specified at the session level, and the key management information only goes into the SETUP related to the first stream. The "uri" indicates to the server that the context is for the whole aggregated session the key management applies. The RTSP client then proceeds setting up the second media (video) in aggregation with the audio. As the two media are run in aggregation and the key context was established in the first exchange, no more key management messages are needed.
注意，在这种情况下，密钥管理行是在会话级别指定的，并且密钥管理信息只进入与第一个流相关的设置中。“uri”向服务器指示上下文是密钥管理应用的整个聚合会话的上下文。然后，RTSP客户端继续设置第二媒体（视频）与音频的聚合。由于这两个媒体在聚合中运行，并且密钥上下文是在第一次交换中建立的，因此不需要更多的密钥管理消息。
The use of the MIKEY message at the media level would change the previous example as follows.
在媒体级别使用MIKEY消息将改变前面的示例，如下所示。
The 200 OK would contain the two distinct SDP attributes for MIKEY at the media level:
200 OK将包含MIKEY在媒体级别的两个不同SDP属性：
RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 561
RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 561
v=0
o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com
s=Action Movie
e=action@movie.example.com
t=0 0
c=IN IP4 movie.example.com
a=control:rtsp://movie.example.com/action
m=audio 0 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAA...
a=control:rtsp://movie.example.com/action/audio
m=video 0 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=key-mgmt:mikey AQAFgM0AdlABAAAAAAAAAAAAA...
a=control:rtsp://movie.example.com/action/video
v=0
o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com
s=Action Movie
e=action@movie.example.com
t=0 0
c=IN IP4 movie.example.com
a=control:rtsp://movie.example.com/action
m=audio 0 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAA...
a=control:rtsp://movie.example.com/action/audio
m=video 0 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=key-mgmt:mikey AQAFgM0AdlABAAAAAAAAAAAAA...
a=control:rtsp://movie.example.com/action/video
Each RTSP header is inserted in the SETUP related to the audio and video separately:
每个RTSP头分别插入到与音频和视频相关的设置中：
SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio";
data="AQEFgM0XflABAAAAAAAAAAAAA..."
SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio";
data="AQEFgM0XflABAAAAAAAAAAAAA..."
and similarly for the video session:
同样，对于视频会话：
SETUP rtsp://movie.example.com/action/video RTSP/1.0
CSeq: 315
Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video";
data="AQEFgM0AdlABAAAAAAAAAAAAAA..."
SETUP rtsp://movie.example.com/action/video RTSP/1.0
CSeq: 315
Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video";
data="AQEFgM0AdlABAAAAAAAAAAAAAA..."
Note: The "uri" parameter could be excluded from the two SETUP messages in this example.
注意：在本例中，可以从两条设置消息中排除“uri”参数。
This framework cannot be used with all key management protocols. The key management protocol needs to comply with the requirements described in Section 4. In addition to this, the following needs to be defined:
此框架不能用于所有密钥管理协议。密钥管理协议需要符合第4节中描述的要求。除此之外，还需要定义以下内容：
* The key management protocol identifier to be used as the protocol identifier should be registered at IANA according to Section 9.
* 根据第9节，用作协议标识符的密钥管理协议标识符应在IANA注册。
* The information that the key management needs from SDP and RTSP, and vice versa, as described in Section 4. The exact API is implementation specific, but it MUST at least support the exchange of the specified information.
* 密钥管理需要SDP和RTSP提供的信息，反之亦然，如第4节所述。确切的API是特定于实现的，但它至少必须支持指定信息的交换。
* The key management protocol to be added MUST be such that the processing in Section 4 (describing its interactions with SDP and RTSP) can be applied. Note in particular, Section 4.1.4 requires each key management protocol to specify how the list of protocol identifiers is authenticated inside that key management protocol. The key management MUST always be given the protocol identifier(s) of the key management protocol(s) included in the offer in the correct order as they appear.
* 要添加的密钥管理协议必须能够应用第4节中的处理（描述其与SDP和RTSP的交互）。特别注意，第4.1.4节要求每个密钥管理协议指定如何在该密钥管理协议内验证协议标识符列表。必须始终按照正确的顺序向密钥管理提供报价中包含的密钥管理协议的协议标识符。
Finally, it is obviously crucial to analyze possible security implications induced by the introduction of a new key management protocol in the described framework.
最后，分析在所描述的框架中引入新的密钥管理协议可能带来的安全影响显然至关重要。
Today, the MIKEY protocol [MIKEY] has adopted the key management extensions to work together with SIP and RTSP (see Section 7). Other protocols MAY use the described attribute and header, e.g., Kerberos [KERB]; however, this is subject to future standardization.
今天，MIKEY协议[MIKEY]采用了密钥管理扩展，与SIP和RTSP一起工作（参见第7节）。其他协议可以使用所描述的属性和头，例如Kerberos[KERB]；但是，这将取决于未来的标准化。
[MIKEY] describes a key management protocol for real-time applications (both for peer-to-peer communication and group communication). MIKEY carries the security parameters needed for setting up the security protocol (e.g., SRTP) protecting the media stream. MIKEY can be integrated within SDP and RTSP, following the rules and guidelines described in this document.
[MIKEY]描述了实时应用程序的密钥管理协议（用于点对点通信和组通信）。MIKEY携带设置保护媒体流的安全协议（如SRTP）所需的安全参数。MIKEY可以按照本文档中描述的规则和指南集成到SDP和RTSP中。
MIKEY satisfies the requirements described in Section 4. The MIKEY message is formed as defined in [MIKEY], then passed from MIKEY to the SDP application that base64 encodes it, and encapsulates it in the keymgmt-data attribute. The examples in Section 5 use MIKEY, where the semantics of the exchange is also briefly explained.
MIKEY满足第4节所述的要求。MIKEY消息按照[MIKEY]中的定义形成，然后从MIKEY传递到SDP应用程序，由SDP应用程序base64对其进行编码，并将其封装在keymgmt数据属性中。第5节中的示例使用MIKEY，其中还简要说明了交换的语义。
The key management protocol identifier (KMPID) to be used as the protocol identifier SHALL be "mikey" and is registered at IANA; see Section 9 for details.
用作协议标识符的密钥管理协议标识符（KMPID）应为“mikey”，并在IANA注册；详情见第9节。
The information that the key management needs from SDP and RTSP, and vice versa, follows Section 4. To avoid bidding-down attacks, the directives in Section 4.1.4 are followed. The list of protocol identifiers is authenticated within MIKEY by placing the list in a General Extension Payload (of type "SDP IDs", [MIKEY]), which then automatically will be integrity protected/signed. The receiver SHALL then match the list in the General Extension Payload with the list included in SDP and SHOULD (according to policy) if they differ, or if integrity/signature verification fails, reject the offer.
密钥管理需要SDP和RTSP提供的信息，反之亦然，请参见第4节。为避免竞价拒绝攻击，遵循第4.1.4节中的指令。通过将协议标识符列表放置在通用扩展有效负载（类型为“SDP ID”，[MIKEY]）中，在MIKEY内对该列表进行身份验证，然后该负载将自动进行完整性保护/签名。然后，接收方应将通用扩展有效载荷中的列表与SDP中包含的列表相匹配，并且如果它们不同，或者如果完整性/签名验证失败，则应（根据政策）拒绝报价。
The server will need to be able to know the identity of the client before creating and sending a MIKEY message. To signal the (MIKEY) identity of the client to the server in the DESCRIBE, it is RECOMMENDED to include the From header field in RTSP. Other methods to establish the identity could be using the IP address or retrieving the identity from the RTSP authentication if used.
在创建和发送MIKEY消息之前，服务器需要知道客户端的身份。要在描述中向服务器发送客户端的（MIKEY）标识信号，建议在RTSP中包含From header字段。建立身份的其他方法可以是使用IP地址或从RTSP身份验证中检索身份（如果使用）。
This subsection describes some aspects, which implementers SHOULD consider. If the MIKEY implementation is separate from the SDP/SIP/RTSP, an application programming interface (API) between MIKEY and those protocols is needed with certain functionality (however, exactly what it looks like is implementation dependent).
本节描述了一些实施者应该考虑的方面。如果MIKEY实现与SDP/SIP/RTSP分离，则MIKEY与这些协议之间需要一个应用程序编程接口（API），该接口具有某些功能（但是，它的外观完全取决于实现）。
The following aspects need to be considered:
需要考虑以下方面：
* the possibility for MIKEY to receive information about the sessions negotiated. This is to some extent implementation dependent. But it is RECOMMENDED that, in the case of SRTP streams, the number of SRTP streams is included (and the direction of these). It is also RECOMMENDED to provide the destination addresses and ports to MIKEY. When referring to streams described in SDP, MIKEY SHALL allocate two consecutive numbers for the related Crypto Session indexes (as each stream can be bi-directional). An example: if the SDP contains two m lines (specifying whatever direction of the streams), and MIKEY is at the session level, then MIKEY allocates, e.g., the Crypto Sessions Identifiers (CS IDs; see [MIKEY]) '1' and '2' for the first m line, and '3' and '4' for the second m line.
* MIKEY收到谈判会议信息的可能性。这在某种程度上取决于实现。但建议在SRTP流的情况下，包括SRTP流的数量（以及这些流的方向）。还建议向MIKEY提供目标地址和端口。当参考SDP中描述的流时，MIKEY应为相关加密会话索引分配两个连续的数字（因为每个流可以是双向的）。例如：如果SDP包含两条m线（指定流的任何方向），并且MIKEY处于会话级别，则MIKEY分配，例如，第一条m线的加密会话标识符（CS ID；请参见[MIKEY]）为“1”和“2”，第二条m线的为“3”和“4”。
* the possibility for MIKEY to receive incoming MIKEY messages and return a status code from/to the SIP/RTSP application.
* MIKEY接收传入MIKEY消息并从SIP/RTSP应用程序返回状态代码的可能性。
* the possibility for the SIP or RTSP applications to receive information from MIKEY. This would typically include the receiving of the Crypto Session Bundle Identifier (CSB ID; see [MIKEY], to later be able to identify the active MIKEY session), and the SSRCs and the rollover counter (ROC; see [SRTP]) for SRTP usage. It is also RECOMMENDED that extra information about errors can be received.
* SIP或RTSP应用程序从MIKEY接收信息的可能性。这通常包括接收加密会话包标识符（CSB ID；请参阅[MIKEY]，以便稍后能够识别活动的MIKEY会话），以及用于SRTP使用的SSRC和滚动计数器（ROC；请参阅[SRTP]）。还建议接收有关错误的额外信息。
* the possibility for the SIP or RTSP application to receive outgoing MIKEY messages.
* SIP或RTSP应用程序接收传出MIKEY消息的可能性。
* the possibility to tear down a MIKEY CSB (e.g., if the SIP session is closed, the CSB SHOULD also be closed).
* 拆除MIKEY CSB的可能性（例如，如果SIP会话关闭，CSB也应关闭）。
The framework for transfer of key management data as described here is intended to provide the security parameters for the end-to-end protection of the media session. It is furthermore good practice to secure the session setup (e.g., SDP, SIP, RTSP, SAP). However, it might be that the security of the session setup is not possible to achieve end-to-end, but only hop-by-hop. For example, SIP requires intermediate proxies to have access to part of the SIP message, and sometimes also to the SDP description (cf. [E2M]), although end-to-end confidentiality can hide bodies from intermediaries. General security considerations for the session setup can be found in SDP [SDPnew], SIP [SIP], and RTSP [RTSP]. The framework defined in this memo is useful when the session setup is not protected in an end-to-
此处描述的密钥管理数据传输框架旨在为媒体会话的端到端保护提供安全参数。此外，保护会话设置（例如SDP、SIP、RTSP、SAP）也是一种良好的做法。但是，会话设置的安全性可能无法实现端到端，而只能实现逐跳。例如，SIP要求中间代理访问SIP消息的一部分，有时还需要访问SDP描述（参见[E2M]），尽管端到端机密性可能会对中介隐藏实体。会话设置的一般安全注意事项可以在SDP[SDPnew]、SIP[SIP]和RTSP[RTSP]中找到。当会话设置在结束时不受保护时，此备忘录中定义的框架非常有用-
end fashion, but the media streams need to be end-to-end protected; hence the security parameters (such as keys) are not wanted revealed to or manipulated by intermediaries.
端到端方式，但媒体流需要端到端保护；因此，安全参数（如密钥）不希望被中间人透露或操纵。
The security will also depend on the level of security the key management protocol offers. It follows that, under the assumption that the key management schemes are secure, the SDP can be passed along unencrypted without affecting the key management as such, and the media streams will still be secure even if some attackers gained knowledge of the SDP contents. Further security considerations can be found for each key management protocol (for MIKEY these can be found in [MIKEY]). However, if the SDP messages are not sent integrity protected between the parties, it is possible for an active attacker to change attributes without being detected. As the key management protocol may (indirectly) rely on some of the session information from SDP (e.g., address information), an attack on SDP may have indirect consequences on the key management. Even if the key management protocol does not rely on parameters of SDP and will not be affected by manipulation of these, different denial-of-service (DoS) attacks aimed at SDP may lead to undesired interruption in the setup. See also the attacks described at the end of this section.
安全性还取决于密钥管理协议提供的安全级别。因此，在假设密钥管理方案是安全的情况下，SDP可以不加密地传递，而不会影响密钥管理本身，并且即使一些攻击者知道SDP内容，媒体流仍然是安全的。可以找到每个密钥管理协议的进一步安全注意事项（对于MIKEY，可在[MIKEY]中找到这些注意事项）。但是，如果双方之间发送的SDP消息未受到完整性保护，则活动攻击者可能会在未被检测到的情况下更改属性。由于密钥管理协议可能（间接）依赖于来自SDP的一些会话信息（例如，地址信息），对SDP的攻击可能对密钥管理产生间接影响。即使密钥管理协议不依赖于SDP的参数，并且不会受到这些参数操纵的影响，针对SDP的不同拒绝服务（DoS）攻击也可能导致设置中出现意外中断。另请参见本节末尾描述的攻击。
The only integrity-protected attribute of the media stream is, in the framework proposed here, the set of key management protocols. For instance, it is possible to (1) swap key management offers across SDP messages, or (2) inject a previous key management offer into a new SDP message. Making the (necessary) assumption that all involved key management protocols are secure, the second attack will be detected by replay protection mechanisms of the key management protocol(s). Making the further assumption that, according to normal best current practice, the production of each key management offer is done with independent (pseudo)random choices (for session keys and other parameters), the first attack will either be detected in the Responder's (now incorrect) verification reply message (if such is used) or be a pure DoS attack, resulting in Initiator and Responder using different keys.
在本文提出的框架中，媒体流的唯一完整性保护属性是密钥管理协议集。例如，可以（1）在SDP消息之间交换密钥管理服务，或者（2）将以前的密钥管理服务注入到新的SDP消息中。假设（必要的）所有涉及的密钥管理协议都是安全的，第二次攻击将由密钥管理协议的重播保护机制检测。进一步假设，根据当前的正常最佳实践，每个密钥管理提议的产生是通过独立（伪）随机选择（对于会话密钥和其他参数）完成的，第一次攻击将在响应者的（现在不正确）验证回复消息中检测（如果使用）或者是纯粹的DoS攻击，导致启动器和响应程序使用不同的密钥。
It is RECOMMENDED for the identity at the SPD level to be the one authenticated at the key management protocol level. However, this might need to keep into consideration privacy aspects, which are out of scope for this framework.
建议SPD级别的身份是在密钥管理协议级别进行身份验证的身份。然而，这可能需要考虑隐私方面，这超出了本框架的范围。
The use of multiple key management protocols in the same offer may open up the possibility of a bidding-down attack, as specified in Section 4.1.4. To exclude such possibility, the authentication of the protocol identifier list is used. Note though, that the security level of the authenticated protocol identifier will be as high (or
如第4.1.4节所述，在同一报价中使用多个密钥管理协议可能会引发竞价拒绝攻击。为了排除这种可能性，使用协议标识符列表的身份验证。但是请注意，经过身份验证的协议标识符的安全级别将与
low), as the "weakest" protocol. Therefore, the offer MUST NOT contain any security protocols (or configurations thereof) weaker than permitted by local security policy.
低），作为“最弱”协议。因此，报价不得包含任何弱于本地安全策略允许的安全协议（或其配置）。
Note that it is impossible to ensure the authenticity of a declined offer, since even if it comes from the true respondent, the fact that the answerer declines the offer usually means that he does not support the protocol(s) offered, and consequently cannot be expected to authenticate the response either. This means that if the Initiator is unsure of which protocol(s) the Responder supports, we RECOMMEND that the Initiator offers all acceptable protocols in a single offer. If not, this opens up the possibility for a "man-in-the-middle" (MITM) to affect the outcome of the eventually agreed upon protocol, by faking unauthenticated error messages until the Initiator eventually offers a protocol "to the liking" of the MITM. This is not really a security problem, but rather a mild form of denial of service that can be avoided by following the above recommendation. Note also that the declined offer could be the result of an attacker who sits on the path and removes all the key management offers. The bidding-down attack prevention, as described above, would not work in this case (as the answerer receives no key management attribute). Also, here it is impossible to ensure the authenticity of a declined offer, though here the reason is the "peeling-off" attack. It is up to the local policy to decide the behavior in the case that the response declines any security (therefore, there is impossibility of authenticating it). For example, if the local policy requires a secure communication and cannot accept an unsecured one, then the session setup SHALL be aborted.
请注意，不可能确保被拒绝要约的真实性，因为即使该要约来自真实的响应者，响应者拒绝要约的事实通常意味着他不支持所提供的协议，因此也不能期望对响应进行认证。这意味着，如果发起者不确定响应者支持哪些协议，我们建议发起者在一次提供中提供所有可接受的协议。否则，“中间人”（MITM）就有可能通过伪造未经验证的错误消息来影响最终商定协议的结果，直到发起人最终提供一个“符合MITM要求”的协议。这实际上不是一个安全问题，而是一种轻微的拒绝服务形式，可以通过遵循上述建议来避免。还请注意，拒绝提供可能是由于攻击者坐在路径上并删除所有密钥管理提供的结果。如上所述，竞价拒绝攻击预防在这种情况下不起作用（因为应答者没有收到密钥管理属性）。此外，这里不可能确保被拒绝报价的真实性，尽管这里的原因是“剥离”攻击。在响应拒绝任何安全性的情况下，由本地策略决定行为（因此，无法对其进行身份验证）。例如，如果本地策略需要安全通信且无法接受不安全通信，则会话设置应中止。
The IANA has created a new subregistry for the purpose of key management protocol integration with SDP.
IANA已经创建了一个新的子区域，用于密钥管理协议与SDP的集成。
SDP Attribute Field ("att-field"):
SDP属性字段（“att字段”）：
Name: key-mgmt-att-field Long form: key management protocol attribute field Type of name: att-field Type of attribute: Media and session level Purpose: See RFC 4567, Section 3. Reference: RFC 4567, Section 3.1 Values: See RFC 4567, Sections 3.1 and 9.3.
名称：密钥管理att字段长格式：密钥管理协议属性字段名称类型：att字段属性类型：媒体和会话级别用途：请参阅RFC 4567第3节。参考：RFC 4567，第3.1节值：见RFC 4567，第3.1和9.3节。
The IANA has created a new subregistry for the purpose of key management protocol integration with RTSP.
IANA创建了一个新的子区域，用于与RTSP集成密钥管理协议。
Following the guidelines of [RTSP], the registration is defined as follows:
根据[RTSP]指南，注册定义如下：
Header name: keymgmt Header syntax: see RFC 4567, Section 3.2 Intended usage: see RFC 4567, Section 3.2 Proxy treatment: Proxies SHALL NOT add, change, or delete the header. The proxy does not need to read this header. Purpose: see RFC 4567, Section 3
标题名称：keymgmt标题语法：参见RFC 4567第3.2节预期用途：参见RFC 4567第3.2节代理处理：代理不得添加、更改或删除标题。代理不需要读取此标头。目的：见RFC 4567第3节
The RTSP Status-Code "463" (RFC 4567), with the default string "Key management failure", needs to be registered.
需要注册RTSP状态代码“463”（RFC 4567），默认字符串为“密钥管理失败”。
This document defines one new name space, the "SDP/RTSP key management protocol identifier", associated with the protocol identifier, KMPID, defined in Section 3 to be used with the above registered attributes in SDP and RTSP.
本文档定义了一个新的名称空间“SDP/RTSP密钥管理协议标识符”，该名称空间与第3节中定义的协议标识符KMPID关联，用于SDP和RTSP中的上述注册属性。
The IANA has created a new subregistry for the KMPID parameter, with the following registration created initially: "mikey".
IANA为KMPID参数创建了一个新的子区域，最初创建了以下注册：“mikey”。
Value name: mikey Long name: Multimedia Internet KEYing Purpose: Usage of MIKEY with the key-mgmt-att-field attribute and the keymgmt RTSP header Reference: Section 7 in RFC 3830
值名称：mikey Long name:多媒体互联网键控用途：使用带有key-mgmt-att字段属性和keymgmt-RTSP标头的mikey参考：RFC 3830第7节
Note that this registration implies that the protocol identifier, KMPID, name space will be shared between SDP and RTSP.
请注意，此注册意味着协议标识符KMPID和名称空间将在SDP和RTSP之间共享。
Further values may be registered according to the "Specification Required" policy as defined in [RFC2434]. Each new registration needs to indicate the parameter name, and register it with IANA. Note that the parameter name is case sensitive, and it is RECOMMENDED that the name be in lowercase letters. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter and the requested details of interaction between the key management protocol and SDP, as specified in RFC 4567.
可根据[RFC2434]中定义的“所需规范”政策注册更多值。每次新注册都需要指明参数名称，并向IANA注册。请注意，参数名称区分大小写，建议使用小写字母。对于每个新注册，必须存在一个永久、稳定且可公开访问的文档，该文档指定注册参数的语义以及密钥管理协议和SDP之间交互的请求细节，如RFC 4567中所述。
New values MUST be registered with IANA. Registrations SHALL include the following information:
新值必须向IANA注册。注册应包括以下信息：
* Contact: the contact name and email address * Value name: the name of the value being registered (which MUST comply with the KMPID as defined in Section 3) * Long Name: long-form name in English * Purpose: short explanation of the purpose of the registered name. * Reference: a reference to the specification (e.g., RFC number) providing the usage guidelines in accordance to Section 6 (and also complying to the specified requirements).
* 联系人：联系人姓名和电子邮件地址*值名称：注册的值的名称（必须符合第3节中定义的KMPID）*长名称：英文长格式名称*目的：简短解释注册名称的目的。*参考：参考规范（如RFC编号），根据第6节提供使用指南（并符合规定要求）。
The authors would like to thank Francois Audet, Rolf Blom, Johan Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries, Joerg Ott, Jon Peterson, and Jon-Olov Vatn. A special thanks to Colin Perkins and Magnus Westerlund, who contributed in many sections.
作者要感谢弗朗索瓦·奥德特、罗尔夫·布洛姆、约翰·比林、马格纳斯·布罗林、埃里克·埃利亚松、马丁·欧希纳、史蒂芬·弗里斯、约伯格·奥特、乔恩·彼得森和乔恩·奥洛夫·瓦顿。特别感谢科林·珀金斯和马格努斯·韦斯特隆德，他们在许多方面都做出了贡献。
[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月。
[OAM] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[OAM]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[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月。
[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注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[RFC3548]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC3548，2003年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RTSP]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC 23261998年4月。
[SDPnew] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[SDPnew]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[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月。
[E2M] Ono, K. and S. Tachimoto, "Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)", RFC 4189, October 2005.
[E2M]Ono，K.和S.Tachimoto，“会话启动协议（SIP）的端到端安全要求”，RFC 4189，2005年10月。
[KERB] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[KERB]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[SDES] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[SDES]Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 45681006年7月。
[SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security Preconditions for Session Description Protocol Media Streams", Work in Progress, October 2005.
[SPREC]Andreasen，F.，Baugher，M.，和Wing，D.，“会话描述协议媒体流的安全先决条件”，正在进行的工作，2005年10月。
[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月。
Authors' Addresses
作者地址
Jari Arkko Ericsson 02420 Jorvas Finland
雅丽阿尔科爱立信02420 Jorvas芬兰
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Elisabetta Carrara Royal Institute of Technology Stockholm Sweden
瑞典斯德哥尔摩皇家理工学院Elisabetta Carrara
EMail: carrara@kth.se
EMail: carrara@kth.se
Fredrik Lindholm Ericsson SE-16480 Stockholm Sweden
弗雷德里克·林德霍姆·爱立信SE-16480瑞典斯德哥尔摩
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.com
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.com
Mats Naslund Ericsson Research SE-16480 Stockholm Sweden
Mats Naslund Ericsson Research SE-16480瑞典斯德哥尔摩
Phone: +46 8 58533739
EMail: mats.naslund@ericsson.com
Phone: +46 8 58533739
EMail: mats.naslund@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
卡尔·诺尔曼·爱立信研究所SE-16480瑞典斯德哥尔摩
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.com
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。