Network Working Group S. Fries
Request for Comments: 5197 Siemens
Category: Informational D. Ignjatic
Polycom
June 2008
Network Working Group S. Fries
Request for Comments: 5197 Siemens
Category: Informational D. Ignjatic
Polycom
June 2008
On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions
各种多媒体互联网键控（MIKEY）模式和扩展的适用性
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for real-time applications. In particular, it has been defined focusing on the support of the Secure Real-time Transport Protocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements.
多媒体互联网密钥（MIKEY）是一种可用于实时应用的密钥管理协议。特别是，它的定义侧重于安全实时传输协议（SRTP）的支持。MIKEY本身在RFC3830中是标准化的，定义了四种密钥分发方法。此外，它的定义允许协议的扩展。随着MIKEY越来越被接受，对基本协议的扩展也随之出现，特别是在额外的密钥分发方法方面，以及在有效负载增强方面。
This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session Description Protocol (SDP) answer, forking, and shared key conferencing.
本文档概述了MIKEY基本文档以及MIKEY的现有扩展，这些扩展已经定义或正在定义中。它的目的是作为开发人员或架构师的额外信息源，以提供对用例场景和动机的更多了解，以及不同密钥分发方案的优缺点。本文档中讨论的用例与专用SIP呼叫场景密切相关，这些场景通常为密钥管理带来挑战，其中包括会话前媒体描述协议（SDP）应答、分叉和共享密钥会议。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
3. MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Pre-Shared Key (PSK) Protected Distribution . . . . . . . 9
3.2. Public Key Encrypted Key Distribution . . . . . . . . . . 9
3.3. Diffie-Hellman Key Agreement Protected with Digital
Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Unprotected Key Distribution . . . . . . . . . . . . . . . 11
3.5. Diffie-Hellman Key Agreement Protected with Pre-Shared
Secrets . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. SAML-Assisted DH key Agreement . . . . . . . . . . . . . . 12
3.7. Asymmetric Key Distribution with In-Band Certificate
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Further MIKEY Extensions . . . . . . . . . . . . . . . . . . . 16
4.1. ECC Algorithms Support . . . . . . . . . . . . . . . . . . 16
4.1.1. Elliptic Curve Integrated Encryption Scheme
application in MIKEY . . . . . . . . . . . . . . . . . 17
4.1.2. Elliptic Curve Menezes-Qu-Vanstone Scheme
Application in MIKEY . . . . . . . . . . . . . . . . . 17
4.2. New MIKEY Payload for Bootstrapping TESLA . . . . . . . . 17
4.3. MBMS Extensions to the Key ID Information Type . . . . . . 18
4.4. OMA BCAST MIKEY General Extension Payload Specification . 18
4.5. Supporting Integrity Transform Carrying the Rollover
Counter . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Selection and Interworking of MIKEY Modes . . . . . . . . . . 19
5.1. MIKEY and Early Media . . . . . . . . . . . . . . . . . . 21
5.2. MIKEY and Forking . . . . . . . . . . . . . . . . . . . . 22
5.3. MIKEY and Call Transfer/Redirect/Retarget . . . . . . . . 23
5.4. MIKEY and Shared Key Conferencing . . . . . . . . . . . . 23
5.5. MIKEY Mode Summary . . . . . . . . . . . . . . . . . . . . 24
6. Transport of MIKEY Messages . . . . . . . . . . . . . . . . . 24
7. MIKEY Alternatives for SRTP Security Parameter Negotiation . . 25
8. Summary of MIKEY-Related IANA Registrations . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
3. MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Pre-Shared Key (PSK) Protected Distribution . . . . . . . 9
3.2. Public Key Encrypted Key Distribution . . . . . . . . . . 9
3.3. Diffie-Hellman Key Agreement Protected with Digital
Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Unprotected Key Distribution . . . . . . . . . . . . . . . 11
3.5. Diffie-Hellman Key Agreement Protected with Pre-Shared
Secrets . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. SAML-Assisted DH key Agreement . . . . . . . . . . . . . . 12
3.7. Asymmetric Key Distribution with In-Band Certificate
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Further MIKEY Extensions . . . . . . . . . . . . . . . . . . . 16
4.1. ECC Algorithms Support . . . . . . . . . . . . . . . . . . 16
4.1.1. Elliptic Curve Integrated Encryption Scheme
application in MIKEY . . . . . . . . . . . . . . . . . 17
4.1.2. Elliptic Curve Menezes-Qu-Vanstone Scheme
Application in MIKEY . . . . . . . . . . . . . . . . . 17
4.2. New MIKEY Payload for Bootstrapping TESLA . . . . . . . . 17
4.3. MBMS Extensions to the Key ID Information Type . . . . . . 18
4.4. OMA BCAST MIKEY General Extension Payload Specification . 18
4.5. Supporting Integrity Transform Carrying the Rollover
Counter . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Selection and Interworking of MIKEY Modes . . . . . . . . . . 19
5.1. MIKEY and Early Media . . . . . . . . . . . . . . . . . . 21
5.2. MIKEY and Forking . . . . . . . . . . . . . . . . . . . . 22
5.3. MIKEY and Call Transfer/Redirect/Retarget . . . . . . . . 23
5.4. MIKEY and Shared Key Conferencing . . . . . . . . . . . . 23
5.5. MIKEY Mode Summary . . . . . . . . . . . . . . . . . . . . 24
6. Transport of MIKEY Messages . . . . . . . . . . . . . . . . . 24
7. MIKEY Alternatives for SRTP Security Parameter Negotiation . . 25
8. Summary of MIKEY-Related IANA Registrations . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Key distribution describes the process of delivering cryptographic keys to the required parties. MIKEY [RFC3830], the Multimedia Internet Keying, has been defined focusing on support for the establishment of security context for the Secure Real-time Transport Protocol [RFC3711]. Note that RFC 3830 is not restricted to be used for SRTP only, as it features a generic approach and allows for extensions to the key distribution schemes. Thus, it may also be used for security parameter negotiation for other protocols.
密钥分发描述将加密密钥传递给所需方的过程。MIKEY[RFC3830]是多媒体互联网密钥，其定义重点是支持安全实时传输协议[RFC3711]的安全上下文的建立。请注意，RFC 3830不限于仅用于SRTP，因为它具有通用方法，并允许扩展密钥分发方案。因此，它也可以用于其他协议的安全参数协商。
For MIKEY, meanwhile, seven key distribution methods are described:
同时，对于MIKEY，描述了七种密钥分配方法：
o Symmetric key distribution as defined in [RFC3830] (MIKEY-PSK)
o [RFC3830]（MIKEY-PSK）中定义的对称密钥分配
o Asymmetric key distribution as defined in [RFC3830] (MIKEY-RSA)
o [RFC3830]（MIKEY-RSA）中定义的非对称密钥分发
o Diffie-Hellman key agreement protected by digital signatures as defined in [RFC3830] (MIKEY-DHSIGN)
o Diffie-Hellman密钥协议受[RFC3830]（MIKEY-DHSIGN）中定义的数字签名保护
o Unprotected key distribution (MIKEY-NULL)
o 未受保护的密钥分发（MIKEY-NULL）
o Diffie-Hellman key agreement protected by symmetric pre-shared keys as defined in [RFC4650] (MIKEY-DHHMAC)
o Diffie-Hellman密钥协议受[RFC4650]（MIKEY-DHHMAC）中定义的对称预共享密钥保护
o Security Assertion Markup Language (SAML) assisted Diffie-Hellman key agreement as defined (not available as a separate document, but discussions are reflected within this document (MIKEY-DHSAML))
o 安全断言标记语言（SAML）辅助定义的Diffie-Hellman密钥协议（不作为单独的文档提供，但讨论反映在本文档中（MIKEY-DHSAML））
o Asymmetric key distribution (based on asymmetric encryption) with in-band certificate provision as defined in [RFC4738] (MIKEY-RSA-R)
o 非对称密钥分发（基于非对称加密），并提供[RFC4738]（MIKEY-RSA-R）中定义的带内证书
Note that the latter three modes are extensions to MIKEY as there have been scenarios where none of the first four modes defined in [RFC3830] fits perfectly. There are further extensions to MIKEY comprising algorithm enhancements and a new payload definition supporting protocols other than SRTP.
请注意，后三种模式是对MIKEY的扩展，因为[RFC3830]中定义的前四种模式都不完全适合。MIKEY还有进一步的扩展，包括算法增强和支持SRTP以外协议的新有效负载定义。
Algorithm extensions are defined in the following document:
算法扩展在以下文档中定义：
o Elliptic Curve Cryptography (ECC) algorithms for MIKEY as defined in [MSEC-MIKEY]
o [MSEC-MIKEY]中定义的用于MIKEY的椭圆曲线密码（ECC）算法
Payload extensions are defined in the following documents:
有效负载扩展在以下文档中定义：
o Bootstrapping TESLA, defining a new payload for the Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol [RFC4082] as defined in [RFC4442]
o 引导特斯拉，为[RFC4442]中定义的定时高效流丢失容忍认证（特斯拉）协议[RFC4082]定义新的有效负载
o The Key ID information type for the general extension payload as defined in [RFC4563]
o [RFC4563]中定义的通用扩展有效负载的密钥ID信息类型
o Open Mobile Alliance (OMA) Broadcast (BCAST) MIKEY General Extension Payload Specification as defined in [RFC4909]
o [RFC4909]中定义的开放移动联盟（OMA）广播（BCAST）MIKEY通用扩展有效负载规范
o Integrity Transform Carrying Roll-over Counter for SRTP as defined in [RFC4771]. Note that this is rather an extension to SRTP and requires MIKEY to carry a new parameter, but is stated here for completeness.
o [RFC4771]中定义的SRTP完整性转换携带滚动计数器。请注意，这是对SRTP的扩展，需要MIKEY携带一个新参数，但为了完整性，这里进行了说明。
This document provides an overview about RFC 3830 and the relations to the different extensions to provide a framework when using MIKEY. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are inspired by specific protocol workings of SIP that have proved to be problematic for a general key distribution mechanisms in general. These protocol workings are described in detail in Wing, et al. [SIP-MEDIA] and include the following:
本文档概述了RFC3830以及与不同扩展的关系，以便在使用MIKEY时提供一个框架。它的目的是作为开发人员或架构师的额外信息源，以提供对用例场景和动机的更多了解，以及不同密钥分发方案的优缺点。本文档中讨论的用例受SIP的特定协议工作的启发，这些工作已被证明对于一般的密钥分发机制是有问题的。Wing等人[SIP-MEDIA]详细描述了这些协议工作，包括以下内容：
o Early Media (i.e., media that arrives before the SDP answer)
o 早期媒体（即在SDP应答之前到达的媒体）
o Forking
o 分叉
o Call Transfer/Redirect/Retarget
o 呼叫转移/重定向/重定目标
o Shared Key Conferencing
o 共享密钥会议
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The following definitions have been taken from [RFC3830]:
以下定义取自[RFC3830]：
(Data) Security Protocol: the security protocol used to protect the actual data traffic. Examples of security protocols are IPsec and SRTP.
（数据）安全协议：用于保护实际数据流量的安全协议。安全协议的例子有IPsec和SRTP。
Data SA Data Security Association information for the security protocol, including a TEK and a set of parameters/ policies.
Data SA安全协议的数据安全关联信息，包括TEK和一组参数/策略。
CS Crypto Session, uni- or bidirectional data stream(s), protected by a single instance of a security protocol.
CS加密会话，单向或双向数据流，受安全协议的单个实例保护。
CSB Crypto Session Bundle, collection of one or more Crypto Sessions, which can have common TGKs (see below) and security parameters.
CSB Crypto Session Bundle，一个或多个Crypto Session的集合，可以具有通用TGK（见下文）和安全参数。
CS ID Crypto Session ID, unique identifier for the CS within a CSB.
CS ID加密会话ID，CSB中CS的唯一标识符。
CSB ID Crypto Session Bundle ID, unique identifier for the CSB.
CSB ID加密会话包ID，CSB的唯一标识符。
TGK TEK Generation Key, a bit-string agreed upon by two or more parties, associated with CSB. From the TGK, Traffic-Encrypting Keys can then be generated without needing further communication.
TGK TEK生成密钥，由两方或多方商定的与CSB相关的位字符串。从TGK，无需进一步通信即可生成流量加密密钥。
TEK Traffic-Encrypting Key, the key used by the security protocol to protect the CS (this key may be used directly by the security protocol or may be used to derive further keys depending on the security protocol). The TEKs are derived from the CSB's TGK.
TEK流量加密密钥，安全协议用于保护CS的密钥（该密钥可由安全协议直接使用，或可用于根据安全协议派生其他密钥）。TEK源于CSB的TGK。
TGK re-keying the process of re-negotiating/updating the TGK (and consequently future TEK(s)).
TGK重新确定重新协商/更新TGK（以及未来TEK）的过程。
Initiator the initiator of the key management protocol, not necessarily the initiator of the communication.
启动器密钥管理协议的启动器，不一定是通信的启动器。
Responder the responder in the key management protocol.
Responder密钥管理协议中的响应程序。
Salting key a random or pseudo-random (see [RFC4086]) string used to protect against some off-line pre-computation attacks on the underlying security protocol.
satting key一种随机或伪随机（参见[RFC4086]）字符串，用于防止对底层安全协议的某些离线预计算攻击。
HDR the protocol header
HDR协议头
PRF(k,x) a keyed pseudo-random function
PRF（k，x）键控伪随机函数
E(k,m) encryption of m with the key k
用密钥k对m进行E（k，m）加密
RAND random value
随机值
T timestamp
时间戳
CERTx the certificate of x
证书
SIGNx the signature from x using the private key of x
SIGNx使用x的私钥从x签名
PKx the public key of x
PKx the public key of xtranslate error, please retry
IDx the identity of x
IDx the identity of xtranslate error, please retry
[] an optional piece of information
[]可选信息
{} zero or more occurrences
{}零次或多次出现
|| concatenation
||串联
| OR (selection operator)
|OR（选择运算符）
^ exponentiation
^指数化
XOR exclusive or
异或异或
The following definitions have been added to the ones from [RFC3830]:
以下定义已添加到[RFC3830]中的定义中：
SSRC Synchronization Source Identifier
同步源标识符
KEMAC MIKEY Key Data Transport Payload, containing a set of encrypted sub-payloads and a Message Authentication Code (MAC).
KEMAC MIKEY密钥数据传输有效载荷，包含一组加密子有效载荷和一个消息认证码（MAC）。
V MIKEY Verification Message
V MIKEY验证消息
SP Security Parameter
SP安全参数
Forking The ability of a SIP proxy to replicate an incoming request to multiple outgoing requests in order to efficiently find the called party for rendezvous. SIP forking can be done in serial (depth-first search) or in parallel (breadth-first search).
分叉SIP代理将传入请求复制到多个传出请求的能力，以便高效地找到要集合的被叫方。SIP分叉可以串行（深度优先搜索）或并行（广度优先搜索）完成。
Redirect The ability of a SIP proxy to send a final response that redirects the caller to send a request to an alternate location.
重定向SIP代理发送最终响应的能力，该响应将调用方重定向到备用位置发送请求。
Retarget The ability of a SIP proxy to re-write the Request-URI thereby altering the destination of the request without explicitly notifying the user agent client.
重定SIP代理重写请求URI的能力，从而在不明确通知用户代理客户端的情况下更改请求的目标。
This section will provide an overview about MIKEY. MIKEY focuses on the setup of cryptographic context to secure multimedia sessions in a heterogeneous environment. MIKEY is mainly intended to be used for peer-to-peer, simple one-to-many, and small-size (interactive) groups. One objective of MIKEY is to produce a data security association (SA) for the security protocol, including a Traffic-Encrypting Key (TEK), which is derived from a TEK Generation Key (TGK), and used as input for the security protocol.
本节将提供有关MIKEY的概述。MIKEY专注于加密上下文的设置，以在异构环境中保护多媒体会话。MIKEY主要用于点对点、简单的一对多和小型（交互式）群组。MIKEY的一个目标是为安全协议生成数据安全关联（SA），包括从TEK生成密钥（TGK）派生的流量加密密钥（TEK），并用作安全协议的输入。
MIKEY supports the possibility of establishing keys and parameters for more than one security protocol (or for several instances of the same security protocol) at the same time. The concept of Crypto Session Bundle (CSB) is used to denote a collection of one or more Crypto Sessions that can have common TGK and security parameters, but that obtain distinct TEKs from MIKEY.
MIKEY支持同时为多个安全协议（或同一安全协议的多个实例）建立密钥和参数。Crypto Session Bundle（CSB）的概念用于表示一个或多个加密会话的集合，这些会话可以具有公共TGK和安全参数，但可以从MIKEY获得不同的TEK。
MIKEY as defined in RFC 3830 may proceed with one roundtrip at most, using a so-called Initiator message for the forward direction and a Responder message for the backward direction. Note that there exist MIKEY schemes that may proceed within a half roundtrip (e.g., based on a pre-shared key), while other schemes require a full roundtrip (e.g., Diffie-Hellman-based schemes). The main objective of the Initiator's message (I_MESSAGE) is to transport one or more TGKs (carried in the KEMAC field) and a set of security parameters (SPs) to the Responder in a secure manner. As the verification message from the Responder is optional for some schemes, the Initiator indicates whether or not it requires a verification message from the Responder.
RFC 3830中定义的MIKEY最多可以进行一次往返，使用所谓的启动器消息进行正向，使用应答器消息进行反向。请注意，存在可以在半往返中进行的MIKEY方案（例如，基于预共享密钥），而其他方案需要全往返（例如，基于Diffie-Hellman的方案）。发起方消息（I_消息）的主要目的是以安全的方式将一个或多个TGK（在KEMAC字段中携带）和一组安全参数（SP）传输给响应方。由于来自响应者的验证消息对于某些方案是可选的，因此启动器指示是否需要来自响应者的验证消息。
The focus of the following subsections lies on the key distribution methods as well as the discussion about advantages and disadvantages of the different schemes. Note that the MIKEY key distribution schemes rely on loosely synchronized clocks. If clock synchronization is not available, the replay handling of MIKEY (cf. [RFC3830]) may not work. This is due to the fact that MIKEY does not use a challenge-response mechanism for replay handling; instead, timestamps are used together with message caching. Thus, the required synchronization depends on the number of messages that can be cached on either side. Therefore, MIKEY recommends adjusting the cache size depending on the clock skew in the deployment environment. Moreover, RFC 3830 recommends the ISO time synchronization protocol [ISO_sec_time]. If replay handling is not available, an attacker may be able to replay an older message that he eavesdropped earlier, leading to different TGKs on both sides. As these are fed to the application utilizing MIKEY (e.g., SRTP or TESLA), both sides may rely on different keys and thus may be unable to communicate with
以下小节的重点在于密钥分配方法以及对不同方案优缺点的讨论。请注意，MIKEY密钥分发方案依赖于松散同步的时钟。如果时钟同步不可用，MIKEY的重播处理（参见[RFC3830]）可能无法工作。这是因为MIKEY没有使用质询-响应机制进行重播处理；相反，时间戳与消息缓存一起使用。因此，所需的同步取决于可以在任意一侧缓存的消息数量。因此，MIKEY建议根据部署环境中的时钟偏差调整缓存大小。此外，RFC3830建议采用ISO时间同步协议[ISO秒时间]。如果重播处理不可用，攻击者可能能够重播他先前窃听的旧消息，从而导致双方的TGK不同。由于使用MIKEY（例如，SRTP或TESLA）将这些密钥馈送至应用程序，双方可能依赖不同的密钥，因此可能无法与用户通信
each other. The format applied to the timestamps submitted in MIKEY have to match the NTP format described in [RFC1305]. In other cases, such as of a SIP endpoint, clock synchronization by deriving time from a trusted outbound proxy may be appropriate .
彼此应用于MIKEY中提交的时间戳的格式必须与[RFC1305]中描述的NTP格式相匹配。在其他情况下，例如SIP端点的情况下，通过从可信出站代理导出时间进行时钟同步可能是合适的。
The different MIKEY-related schemes are compared regarding the following criteria:
根据以下标准比较不同的MIKEY相关方案：
o Mandatory for implementation: provides information, if RFC 3830 requires the implementation of this scheme.
o 强制实施：如果RFC 3830要求实施此方案，则提供信息。
o Scalability: describes the technical feasibility to easily deploy a solution based on the considered scheme.
o 可伸缩性：描述基于所考虑的方案轻松部署解决方案的技术可行性。
o Dependency on PKI: states if the support of a PKI is required to support this scheme. Note that PKI here relates to PKI services like key generation, distribution, and revocation.
o 对PKI的依赖性：说明是否需要支持PKI才能支持此方案。请注意，这里的PKI与密钥生成、分发和撤销等PKI服务相关。
o Provision of Perfect Forward Secrecy (PFS): describes the support of PFS, which is, according to RFC 4949 [RFC4949], the property that compromising the long-term keying material does not compromise session keys that were previously derived from the long-term material.
o 提供完美前向保密（PFS）：描述对PFS的支持，根据RFC 4949[RFC4949]，这是一种特性，即泄露长期密钥材料不会泄露先前从长期材料派生的会话密钥。
o Key generation involvement: describes if both or just one of the participants is actively involved in key generation. The option to involve both parties in the key generation is considered here as it addresses several points:
o 密钥生成参与：描述两个或一个参与者是否积极参与密钥生成。此处考虑让双方参与密钥生成的选项，因为它解决了以下几点：
* If both sides contribute public entropy, it is ensured that each side can guarantee that keys are fresh to avoid replay attacks.
* 如果双方都贡献了公共熵，则可以确保每一方都能保证密钥是新的，以避免重播攻击。
* Involvement of both sides avoids that one side generates (intentionally or unintentionally) weak (predictable) nonces, which in turn may result in weak keys.
* 双方的参与避免了一方（有意或无意地）生成弱（可预测）nonce，这反过来可能导致弱键。
o Support of group keying: feasibility of the MIKEY option to be used also for group keying, e.g., in conferencing scenarios.
o 支持组键控：MIKEY选项也可用于组键控，例如在会议场景中。
If MIKEY is used for SRTP [RFC3711] bootstrapping, it also uses the SSRC to associate security policies with actual sessions. The SSRC identifies the synchronization source. The value is chosen randomly, with the intent that no two synchronization sources within the same SRTP session will have the same SSRC. Although the probability of multiple sources choosing the same identifier is low, all (S)RTP implementations must be prepared to detect and resolve collisions. Nevertheless, in multimedia communication scenarios supporting
如果MIKEY用于SRTP[RFC3711]引导，它还使用SSRC将安全策略与实际会话相关联。SSRC识别同步源。该值是随机选择的，目的是同一SRTP会话中的两个同步源不会具有相同的SSRC。尽管多个源选择同一标识符的概率很低，但所有RTP实现都必须准备好检测和解决冲突。然而，在多媒体通信场景中，支持
forking (see Section 5.2) or retargeting (see Section 5.3) collisions may occur leading to so-called two-time pads; i.e., the same key is used for media streams to different destinations. This occurs if two branches have the same TEK (based on the MIKEY key establishment) and choose the same 32-bit SSRC for the SRTP streams. The SRTP key derivation will then produce the same session keys (as the input values are the same) and also derive the same initialization vector per packet, as the SSRCs are the same. Note that two time pads may also occur for media streams to the same destination. This is outlined in [RFC3711].
分叉（见第5.2节）或重定目标（见第5.3节）碰撞可能会发生，导致所谓的两次焊盘；i、 例如，相同的密钥用于到不同目的地的媒体流。如果两个分支具有相同的TEK（基于MIKEY密钥建立）并为SRTP流选择相同的32位SSRC，则会发生这种情况。然后，SRTP密钥派生将产生相同的会话密钥（因为输入值相同），并且还派生每个分组相同的初始化向量，因为ssrc是相同的。注意，对于到同一目的地的媒体流，也可能出现两个时间焊盘。[RFC3711]对此进行了概述。
This option of the key management uses a pre-shared secret key to derive key material for integrity protection and encryption to protect the actual exchange of key material. Note that the pre-shared secret is agreed upon before the session, e.g., by out-of-band means. The responder message is optional and may be used for mutual authentication (proof of possession of the pre-shared secret) or error signaling.
密钥管理的此选项使用预共享密钥来派生完整性保护的密钥材料，并加密以保护密钥材料的实际交换。注意，预先共享的秘密是在会话之前商定的，例如，通过带外方式。响应者消息是可选的，可用于相互认证（预共享秘密的拥有证明）或错误信令。
Initiator Responder
发起者响应者
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
The advantages of this approach lay in the fact that there is no dependency on a PKI (Public Key Infrastructure), the solution consumes low bandwidth and enables high performance, and is all in all a simple straightforward master key provisioning. The disadvantages are that perfect forward secrecy is not provided and key generation is just performed by the Initiator. Furthermore, the approach is not scalable to larger configurations but is acceptable in small-sized groups. Note that according to [RFC3830], this option is mandatory to implement.
这种方法的优点在于不依赖于PKI（公钥基础设施），解决方案消耗低带宽并实现高性能，而且是一种简单、直接的主密钥供应。缺点是没有提供完美的前向保密性，密钥生成仅由发起方执行。此外，该方法不能扩展到更大的配置，但在小型组中是可以接受的。请注意，根据[RFC3830]，此选项是强制实施的。
Using the asymmetric option of the key management, the Initiator generates the key material (TGKs) to be transmitted and sends it encrypted with a so-called envelope key, which in turn is encrypted with the receiver's public key. The envelope key, env-key, which is a random number, is used to derive the auth-key and the enc-key. Moreover, the envelope key may be used as a pre-shared key to
使用密钥管理的非对称选项，发起者生成要传输的密钥材料（TGK），并用所谓的信封密钥加密发送，信封密钥反过来用接收方的公钥加密。信封密钥env key是一个随机数，用于派生身份验证密钥和enc密钥。此外，信封密钥可被用作发送消息的预共享密钥
establish further crypto sessions. The responder message is optional and may be used for mutual authentication or error signaling.
建立进一步的加密会话。响应者消息是可选的，可用于相互认证或错误信令。
Initiator Responder
发起者响应者
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC, [CHASH],
PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC, [CHASH],
PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
An advantage of this approach is that it allows the usage of self-signed certificates, which in turn can avoid a full-blown PKI. Note that using self-signed certificates may result in limited scalability and also require additional means for authentication such as exchange of fingerprints of the certificates or similar techniques. The disadvantages comprise the necessity of a PKI for full scalability, the performance of the key generation just by the Initiator, and no provision of perfect forward secrecy. Additionally, the Responder certificate needs to be available in advance at the sender's side. Furthermore, the verification of certificates may not be done in real time. This could be the case in scenarios where the revocation status of certificates is checked through a further component. Depending on the Initiator role, this scheme can also be applied in group-based communication, where a central server distributes the group key protected with the public keys of the associated clients. Note that according to [RFC3830], this option is mandatory to implement.
这种方法的一个优点是允许使用自签名证书，这反过来又可以避免全面的PKI。注意，使用自签名证书可能导致有限的可伸缩性，并且还需要额外的身份验证手段，例如证书的指纹交换或类似技术。缺点包括需要PKI以实现完全的可伸缩性、仅由发起方生成密钥的性能以及不提供完美的前向保密性。此外，响应者证书需要在发送方提前提供。此外，证书的验证可能无法实时完成。在通过另一个组件检查证书的吊销状态的场景中可能会出现这种情况。根据启动器角色的不同，此方案也可以应用于基于组的通信中，其中中央服务器分发由关联客户端的公钥保护的组密钥。请注意，根据[RFC3830]，此选项是强制实施的。
The Diffie-Hellman option of the key management enables a shared secret establishment between the Initiator and Responder in a way where both parties contribute to the shared secret. The Diffie-Hellman key agreement is authenticated (and integrity protected) using digital signatures.
密钥管理的Diffie-Hellman选项支持在发起方和响应方之间建立共享秘密，双方都参与共享秘密。Diffie-Hellman密钥协议使用数字签名进行身份验证（并受完整性保护）。
Initiator Responder
发起者响应者
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, DHi, SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr],
IDi, DHr, DHi, SIGNr
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, DHi, SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr],
IDi, DHr, DHi, SIGNr
[RFC3830] does mandate the support of RSA as a specific asymmetric algorithm for the signature generation. Additionally, the algorithm used for signature or public key encryption is defined by, and dependent on, the certificate used. Besides the use of X.509v3 certificates, it is mandatory to support the Diffie-Hellman group "OAKLEY5" [RFC2412]. It is also possible to use other Diffie-Hellman groups within MIKEY. This can be done by defining a new mapping sub-payload and the associated policy payload according to [RFC3830]. The advantages of this approach are a fair, mutual key agreement (both parties provide to the key), perfect forward secrecy, and the absence of the need to fetch a certificate in advance as needed for the MIKEY-RSA method depicted above. Moreover, it also provides the option to use self-signed certificates to avoid a PKI deployment. Note that, depending on the security policy, self-signed certificates may not be suitable for every use case.
[RFC3830]确实要求支持RSA作为签名生成的特定非对称算法。此外，用于签名或公钥加密的算法由所使用的证书定义并依赖于所使用的证书。除了使用X.509v3证书外，还必须支持Diffie-Hellman组“OAKLEY5”[RFC2412]。也可以在MIKEY内部使用其他Diffie-Hellman组。这可以通过根据[RFC3830]定义新的映射子有效负载和相关的策略有效负载来实现。这种方法的优点是公平、相互密钥协议（双方提供密钥）、完美的前向保密性，并且不需要按照上述MIKEY-RSA方法的需要提前获取证书。此外，它还提供了使用自签名证书以避免PKI部署的选项。注意，根据安全策略的不同，自签名证书可能并不适用于所有用例。
Negatively to remark is that this approach scales mainly to point-to-point and depends on PKI for full scalability. Multiparty conferencing is not supported using just MIKEY-DHSIGN. Nevertheless, the established Diffie-Hellman-Secret may serve as a pre-shared key to bootstrap group-related security parameter. Furthermore, as for the MIKEY-RSA mode described above, the verification of certificates may not necessarily be done in real time. This could be the case in scenarios where the revocation status of certificates is checked through a further component. Note that, according to [RFC3830], it is optional to implement this scheme.
值得注意的是，这种方法主要扩展到点对点，并且依赖于PKI实现完全的可伸缩性。仅使用MIKEY-DHSIGN不支持多方会议。然而，已建立的Diffie-Hellman秘密可以用作引导组相关安全参数的预共享密钥。此外，对于上面描述的MIKEY-RSA模式，证书的验证不一定是实时完成的。在通过另一个组件检查证书的吊销状态的场景中可能会出现这种情况。注意，根据[RFC3830]，可选择实施该方案。
RFC 3830 also supports a mode to provide a key in an unprotected manner (MIKEY-NULL). This is based on the symmetric key encryption option depicted in Section 3.1 but is used with the NULL encryption and the NULL authentication algorithms. It may be compared with the plain approach in SDP security descriptions [RFC4568]. MIKEY-NULL completely relies on the security of the underlying layer, e.g., provided by TLS. This option should be used with caution as it does not protect the key management.
RFC3830还支持以不受保护的方式提供密钥的模式（MIKEY-NULL）。这基于第3.1节中描述的对称密钥加密选项，但与空加密和空身份验证算法一起使用。它可以与SDP安全描述[RFC4568]中的普通方法相比较。MIKEY-NULL完全依赖底层的安全性，例如TLS提供的安全性。应谨慎使用此选项，因为它不会保护密钥管理。
Based on the missing cryptographic protection of this method, it is obvious that perfect forward secrecy is not provided. As it is based on the pre-shared secret mode, only the Initiator contributes to the key management. The method itself is highly scalable, but again, without proper protection through an underlying security layer, it is not advisable for use.
基于此方法缺少密码保护，显然无法提供完美的前向保密性。由于它基于预共享秘密模式，因此只有发起方参与密钥管理。该方法本身具有高度可扩展性，但同样，如果没有通过底层安全层进行适当的保护，则不建议使用该方法。
This is an additional option, which has been defined in [RFC4650]. In contrast to the method described in Section 3.3, here the Diffie-Hellman key agreement is authenticated (and integrity protected) using a pre-shared secret and keyed hash function.
这是一个附加选项，已在[RFC4650]中定义。与第3.3节中描述的方法不同，这里Diffie-Hellman密钥协议使用预先共享的秘密和密钥哈希函数进行身份验证（和完整性保护）。
Initiator Responder
发起者响应者
I_MESSAGE =
HDR, T, RAND, [IDi],
IDr, {SP}, DHi, KEMAC --->
R_MESSAGE =
<--- HDR, T,[IDr], IDi,
DHr, DHi, KEMAC
I_MESSAGE =
HDR, T, RAND, [IDi],
IDr, {SP}, DHi, KEMAC --->
R_MESSAGE =
<--- HDR, T,[IDr], IDi,
DHr, DHi, KEMAC
TGK = g^(xi * yi) TGK = g^(xi * yi)
TGK = g^(xi * yi) TGK = g^(xi * yi)
For the integrity protection of the Diffie-Hellman key agreement, [RFC4650] mandates the use of HMAC SHA-1. Regarding Diffie-Hellman groups, [RFC3830] is referenced. Thus, it is mandatory to support the Diffie-Hellman group "OAKLEY5" [RFC2412]. It is also possible to use other Diffie-Hellman groups within MIKEY. This can be done by defining a new mapping sub-payload and the associated policy payload according to RFC 3830. This option has also several advantages, as there are the fair mutual key agreement, the perfect forward secrecy, and no dependency on a PKI and PKI standards. Moreover, this scheme has a sound performance and reduced bandwidth requirements compared to MIKEY-DH-SIGN and provides a simple and straightforward master key provisioning. The establishment of shared secrets and the lack of support for group keying is a disadvantage.
为了保护Diffie-Hellman密钥协议的完整性，[RFC4650]要求使用HMAC SHA-1。关于Diffie-Hellman集团，参考[RFC3830]。因此，必须支持Diffie-Hellman集团“OAKLEY5”[RFC2412]。也可以在MIKEY内部使用其他Diffie-Hellman组。这可以通过根据RFC3830定义新的映射子有效负载和相关联的策略有效负载来实现。此选项还有几个优点，因为存在公平的相互密钥协议、完美的前向保密性，并且不依赖PKI和PKI标准。此外，与MIKEY-DH-SIGN相比，该方案具有良好的性能和较低的带宽要求，并提供了简单而直接的主密钥供应。建立共享秘密和缺乏对组键控的支持是一个缺点。
This mode of operation provides an efficient scheme in deployments where there is a central trusted server that is provisioned with shared secrets for many clients. Such setups could, for example, be enterprise Private Branch Exchanges (PBXs), service provider proxies, etc. In contrast to the plain pre-shared key encryption-based mode, described in Section 3.1, this mode offers perfect forward secrecy as well as active involvement in the key generation of both parties involved.
这种操作模式在部署中提供了一种高效的方案，其中有一个中央受信任服务器，该服务器为许多客户端提供了共享机密。例如，此类设置可以是企业专用分支交换机（PBX）、服务提供商代理等。与第3.1节中描述的基于普通预共享密钥加密的模式相比，该模式提供了完美的前向保密性，并积极参与相关双方的密钥生成。
There has been a longer discussion during IETF meetings and also on the IETF MSEC mailing list about a SAML-assisted DH approach. This idea has not been submitted as a separate document. Nevertheless, the discussion is reflected here as it is targeted to fulfill general
在IETF会议期间以及IETF MSEC邮件列表上，关于SAML辅助DH方法的讨论时间更长。这一想法尚未作为单独文件提交。尽管如此，讨论仍反映在这里，因为它的目标是实现总体目标
requirements on key management approaches. Those requirements can be summarized as:
对关键管理方法的要求。这些要求可概括为：
1. Mutual authentication of involved parties
1. 有关各方的相互认证
2. Both parties involved contribute to the session key generation
2. 参与的双方都为会话密钥的生成做出了贡献
3. Provide perfect forward secrecy
3. 提供完美的前向保密
4. Support distribution of group session keys
4. 支持组会话密钥的分发
5. Provide liveliness tests when involved parties do not have a reliable clock
5. 当相关方没有可靠的时钟时，提供生动性测试
6. Support of limited parties involved
6. 有限参与方的支持
To fulfill all of the requirements, it was proposed to use a classic Diffie-Hellman key agreement protocol for key establishment in conjunction with a User Agent's (UA's) SIP server signed element, authenticating the Diffie-Hellman key and the ID using the SAML (Security Assertion Markup Language [SAML_overview]) approach. Here the client's public Diffie-Hellman credentials are signed by the server to form a SAML assertion (referred to as CRED below), which may be used for later sessions with other clients. This assertion needs at least to convey the ID, public DH key, expiry, and the signature from the server. It provides the involved clients with mutual authentication and message integrity of the key management messages exchanged.
为了满足所有要求，建议使用经典的Diffie-Hellman密钥协商协议与用户代理（UA）的SIP服务器签名元素一起建立密钥，使用SAML（安全断言标记语言[SAML_概述]）方法验证Diffie-Hellman密钥和ID。这里，服务器对客户机的公共Diffie-Hellman凭据进行签名，以形成SAML断言（以下称为CRED），该断言可用于以后与其他客户机的会话。此断言至少需要从服务器传递ID、公钥、到期日和签名。它为相关客户机提供相互身份验证和交换的密钥管理消息的消息完整性。
Initiator Responder
发起者响应者
I_MESSAGE =
HDR, T, RAND1, [CREDi],
IDr, {SP} --->
R_MESSAGE =
<--- HDR, T, [CREDr], IDi, DHr,
RAND2, (SP)
TGK = HMACx(RAND1|RAND2), where x = g^(xi * xr).
I_MESSAGE =
HDR, T, RAND1, [CREDi],
IDr, {SP} --->
R_MESSAGE =
<--- HDR, T, [CREDr], IDi, DHr,
RAND2, (SP)
TGK = HMACx(RAND1|RAND2), where x = g^(xi * xr).
Additionally, the scheme proposes a second roundtrip to avoid the dependence on synchronized clocks and provide liveliness checks. This is achieved by exchanging nonces, protected with the session key. The second roundtrip can also be used for distribution of group keys or to leverage a weak DH key for a stronger session key. The trigger for the second roundtrip would be handled via SP, the security policy communicated via MIKEY.
此外，该方案提出了第二次往返，以避免对同步时钟的依赖，并提供活跃性检查。这是通过交换由会话密钥保护的nonce来实现的。第二次往返也可用于分配组密钥，或利用弱DH密钥来获得更强的会话密钥。第二次往返的触发将通过SP处理，安全策略通过MIKEY传达。
Initiator Responder
发起者响应者
I_MESSAGE =
HDR, SIGN(ENC(RAND3)) --->
R_MESSAGE =
<--- SIGN(ENC(RAND4))
I_MESSAGE =
HDR, SIGN(ENC(RAND3)) --->
R_MESSAGE =
<--- SIGN(ENC(RAND4))
Note that if group keys are to be provided, RAND would be substituted by that group key.
请注意，如果要提供组密钥，RAND将被该组密钥替换。
With the second roundtrip, this approach also provides an option for all of the other key distribution methods, when liveliness checks are needed. The drawback of the second roundtrip is that these messages need to be integrated into the call flow of the signaling protocol. In a straight-forward call, one roundtrip may be enough to set up a session. Thus, this second roundtrip would require additional messages to be exchanged.
对于第二次往返，当需要进行活动性检查时，该方法还为所有其他密钥分发方法提供了一个选项。第二次往返的缺点是，这些消息需要集成到信令协议的呼叫流中。在直接呼叫中，一次往返可能足以建立会话。因此，第二次往返需要交换额外的消息。
Regarding the different criteria discussed in the introduction of this section, the advantages of this approach are a fair, mutual key agreement (both parties provide to the key), and perfect forward secrecy. Through the second roundtrip, the dependency on synchronized clocks can be avoided. Moreover, this second roundtrip enables the distribution of a group key and thus enhances the scalability from mainly point-to-point to also multiparty conferencing. The usage of SAML-assisted DH may decrease the hidden latency cost through the credential validation necessary to be done for the signed DH scheme described in Section 3.3. If the UA received its SAML assertion from its domain's SIP server, it is trusting the server implicitly, thus, it may extend that trust to relying on it to validate the other party's SAML assertion. This eliminates not only the hidden validation latency but also its computational cost to the UA.
关于本节导言中讨论的不同标准，这种方法的优点是公平、相互密钥协议（双方提供密钥）和完美的前向保密性。通过第二次往返，可以避免对同步时钟的依赖。此外，第二次往返支持组密钥的分发，从而增强了从点对点会议到多方会议的可伸缩性。使用SAML辅助DH可以通过对第3.3节所述签名DH方案进行必要的凭证验证来降低隐藏的延迟成本。如果UA从其域的SIP服务器接收到其SAML断言，则它隐式信任该服务器，因此，它可以将该信任扩展到依赖它来验证另一方的SAML断言。这不仅消除了隐藏的验证延迟，还消除了UA的计算成本。
Negatively to remark is that this proposal does have one significant security risk. The UA's SIP server can cheat and create an extra authentication object for the UA where it has the Diffie-Hellman private key. With this, the (SIP) server issuing the SAML assertion can successfully launch a Man-in-the-Middle (MITM) attack against two of its UAs. Also, two SIP servers can collude so that either can successfully launch a MITM attack against their UAs. A UA can block this attack if its Diffie-Hellman key is authenticated by a trustworthy third party and this whole object is signed by the SIP server. Moreover, this approach uses two roundtrips, increasing the necessary bandwidth and also the setup time, which may be crucial for many scenarios. For the credential generation, usually a separate component (server) is necessary, so serverless call setup is not supported.
负面评论是，该提案确实存在一个重大的安全风险。UA的SIP服务器可以欺骗UA并为UA创建一个额外的身份验证对象，其中UA拥有Diffie-Hellman私钥。这样，发出SAML断言的（SIP）服务器就可以成功地对其两个UAs发起中间人（MITM）攻击。此外，两个SIP服务器可以相互勾结，以便其中一个能够成功地对其UAs发起MITM攻击。如果UA的Diffie-Hellman密钥由可信的第三方进行身份验证，并且整个对象由SIP服务器签名，则UA可以阻止此攻击。此外，这种方法使用两次往返，增加了必要的带宽和设置时间，这对于许多场景来说可能是至关重要的。对于凭证生成，通常需要单独的组件（服务器），因此不支持无服务器呼叫设置。
This is an additional option, which has been defined in [RFC4738]. It describes the asymmetric key distribution with optional in-band certificate exchange.
这是一个附加选项，已在[RFC4738]中定义。它描述了具有可选带内证书交换的非对称密钥分发。
Initiator Responder
发起者响应者
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr],
{SP}, [RAND], SIGNi --->
R_MESSAGE =
<--- HDR, [GenExt(CSB-ID)], T,
RAND, [IDr|CERTr], [SP],
KEMAC, SIGNr
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr],
{SP}, [RAND], SIGNi --->
R_MESSAGE =
<--- HDR, [GenExt(CSB-ID)], T,
RAND, [IDr|CERTr], [SP],
KEMAC, SIGNr
This option has some advantages compared to the asymmetric key distribution stated in Section 3.2. Here, the sender and receiver do not need to know the certificate of the other peer in advance as it may be sent in the MIKEY Initiator message (if the receiver knows the certificate in advance, RFC 3830's MIKEY-RSA mode may be used instead). Thus, the receiver of this message can utilize the received key material to encrypt the session parameter and send them back as part of the MIKEY responder message. The certificate check may be done depending on the signing authority. If the certificate is signed by a publicly accepted authority, the certificate validation can be done in a straightforward manner, by using the commonly known certificate authority's public key. In the other case, additional steps may be necessary. The disadvantage is that no perfect forward secrecy is provided.
与第3.2节所述的非对称密钥分配相比，该选项具有一些优势。这里，发送方和接收方不需要预先知道另一对等方的证书，因为它可以在MIKEY发起方消息中发送（如果接收方预先知道证书，则可以使用RFC 3830的MIKEY-RSA模式）。因此，该消息的接收者可以利用接收到的密钥材料来加密会话参数，并将其作为MIKEY应答器消息的一部分发送回。根据签名机构的不同，可以进行证书检查。如果证书由公开接受的机构签名，则可以使用众所周知的证书机构的公钥以简单的方式进行证书验证。在另一种情况下，可能需要额外的步骤。缺点是没有提供完美的前向保密性。
This mode is meant to provide an easy option for certificate provisioning when PKI is present and/or required. Specifically in SIP, session invitations can be retargeted or forked. MIKEY modes that require the Initiator to target a single well-known Responder may be impractical here as they may require multiple roundtrips to do key negotiation. By allowing the Responder to generate secret material used for key derivation, this mode allows for an efficient key delivery scheme. Note that the Initiator can contribute to the key material since the key is derived from CSB-ID and RAND payloads in unicast use cases. This mode is also useful in multicast scenarios where multiple clients are contacting a known server and are downloading the key. Responder workload is significantly reduced in these scenarios compared to MIKEY in public key mode. This is due to the fact that the RSA asymmetric encryption requires less effort compared to the decryption using the private key (the public key is usually shorter than the private key, hence less performance for encryption compared to decryption). Examples of deployments where
此模式旨在在存在和/或需要PKI时提供一个简单的证书设置选项。特别是在SIP中，会话邀请可以重定目标或分叉。要求发起者以单个知名响应者为目标的MIKEY模式在这里可能是不切实际的，因为它们可能需要多次往返来进行密钥协商。通过允许响应者生成用于密钥导出的秘密材料，该模式允许有效的密钥传递方案。请注意，发起者可以对密钥材料做出贡献，因为密钥是从单播用例中的CSB-ID和RAND有效负载派生的。此模式在多播场景中也很有用，其中多个客户端正在联系已知服务器并下载密钥。在这些场景中，与公钥模式下的MIKEY相比，响应者的工作负载显著减少。这是因为与使用私钥的解密相比，RSA非对称加密需要更少的工作（公钥通常比私钥短，因此加密的性能比解密低）。部署示例，其中
this mode can be used are enterprises with PKI, service provider setups where the service provider decides to provision certificates to its users, etc.
此模式可用于具有PKI的企业、服务提供商决定向其用户提供证书的服务提供商设置等。
This section will provide an overview about further MIKEY [RFC3830] extensions for crypto algorithms and generic payload enhancements, as well as enhancements to support the negotiation of security parameters for security protocols other than SRTP. These extensions have been defined in several additional documents.
本节将概述加密算法和通用有效负载增强的进一步MIKEY[RFC3830]扩展，以及支持SRTP以外的安全协议的安全参数协商的增强。这些扩展已在其他几个文档中定义。
[MSEC-MIKEY] proposes extensions to the authentication, encryption, and digital signature methods described for use in MIKEY, employing elliptic curve cryptography (ECC). These extensions are defined to align MIKEY with other ECC implementations and standards.
[MSEC-MIKEY]利用椭圆曲线密码（ECC）对MIKEY中使用的认证、加密和数字签名方法提出了扩展。定义这些扩展是为了使MIKEY与其他ECC实现和标准保持一致。
The motivation for supporting ECC within MIKEY stems from the following advantages:
在MIKEY内部支持ECC的动机来自以下优势：
o ECC modes are more and more added to security protocols.
o ECC模式越来越多地添加到安全协议中。
o ECC support requires considerably smaller keys by keeping the same security level compared to other asymmetric techniques (like RSA). Elliptic curve algorithms are capable of providing security consistent with Advanced Encryption Standard (AES) keys of 128, 192, and 256 bits without extensive growth in asymmetric key sizes.
o 与其他非对称技术（如RSA）相比，ECC支持通过保持相同的安全级别，需要相当小的密钥。椭圆曲线算法能够提供与128、192和256位的高级加密标准（AES）密钥一致的安全性，而不必大量增加非对称密钥大小。
o As stated in [MSEC-MIKEY], implementations have shown that elliptic curve algorithms can significantly improve performance and security-per-bit over other recommended algorithms.
o 如[MSEC-MIKEY]中所述，与其他推荐算法相比，实现表明椭圆曲线算法可以显著提高每比特的性能和安全性。
These advantages make the usage of ECC especially interesting for embedded devices, which may have only limited performance and storage capabilities.
这些优点使得ECC的使用对于嵌入式设备尤其有趣，因为嵌入式设备可能只有有限的性能和存储能力。
[MSEC-MIKEY] proposes several ECC-based mechanisms to enhance the MIKEY key distribution schemes:
[MSEC-MIKEY]提出了几种基于ECC的机制来增强MIKEY密钥分配方案：
o Use of ECC methods extending the Diffie-Hellman key exchange: MIKEY-DHSIGN with ECDSA or ECGDSA
o 使用ECC方法扩展Diffie-Hellman密钥交换：带ECDSA或ECGDSA的MIKEY-DHSIGN
o Use of ECC methods extending the Diffie-Hellman key exchange: MIKEY-DHSIGN with ECDH
o 使用ECC方法扩展Diffie-Hellman密钥交换：带ECDH的MIKEY-DHSIGN
o Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES)
o 椭圆曲线集成加密方案（MIKEY-ECIES）的使用
o Use of Elliptic Curve Menezes-Qu-Vanstone Scheme(MIKEY-ECMQV)
o 椭圆曲线Menezes-Qu-Vanstone格式的应用（MIKEY-ECMQV）
The following subsections will provide more detailed information about the message exchanges for MIKEY-ECIES and MIKEY-ECMQV.
以下小节将提供有关MIKEY-ECIES和MIKEY-ECMQV的消息交换的更详细信息。
The following figure shows the message exchange for the MIKEY-ECIES scheme:
下图显示了MIKEY-ECIES方案的消息交换：
Initiator Responder
发起者响应者
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC,
[CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC,
[CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
The following figure shows the message exchange for the MIKEY-ECMQV scheme:
下图显示了MIKEY-ECMQV方案的消息交换：
Initiator Responder
发起者响应者
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP},
ECCPTi, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP},
ECCPTi, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
TESLA [RFC4082] is a protocol for providing source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead, which scales to large numbers of receivers, and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published in [RFC4383] targeting multicast authentication in scenarios, where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.
TESLA[RFC4082]是一种协议，用于在多播场景中提供源身份验证。TESLA是一种高效的协议，具有较低的通信和计算开销，可以扩展到大量的接收器，并且可以容忍数据包丢失。特斯拉基于发送方和接收方之间的松散时间同步。特斯拉通过使用消息认证码（MAC）链接实现源认证。TESLA在安全实时传输协议（SRTP）中的使用已在[RFC4383]中发布，该协议针对场景中的多播认证，其中SRTP用于保护多媒体数据。该解决方案假设特斯拉参数由带外机制提供。
[RFC4442] specifies payloads for MIKEY to bootstrap TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches described above by sending the MIKEY message via unicast, multicast, or broadcast. This approach provides the necessary parameter payload extensions for the usage of TESLA in SRTP. Nevertheless, if the parameter set is also sufficient for other TESLA use cases, it can be applied as well.
[RFC4442]指定MIKEY引导TESLA使用SRTP对安全组通信进行源身份验证的有效负载。通过通过单播、多播或广播发送MIKEY消息，可以使用上述MIKEY密钥管理方法之一引导TESLA。该方法为在SRTP中使用特斯拉提供了必要的参数有效载荷扩展。然而，如果参数集对于其他特斯拉用例也足够，那么也可以应用它。
This extension specifies a new Type (the Key ID Information Type) for the General Extension Payload. This is used in, e.g., the Multimedia Broadcast/Multicast Service (MBMS) specified in the 3rd Generation Partnership Project (3GPP). MBMS requires the use of MIKEY to convey the keys and related security parameters needed to secure the multimedia that is multicast or broadcast.
此扩展为常规扩展有效负载指定一个新类型（密钥ID信息类型）。例如，在第三代合作伙伴关系项目（3GPP）中指定的多媒体广播/多播服务（MBMS）中使用。MBMS需要使用MIKEY来传输密钥和相关安全参数，以保护多播或广播多媒体的安全。
One of the requirements that MBMS puts on security is the ability to perform frequent updates of the keys. The rationale behind this is that it will be costly for subscribers to re-distribute the decryption keys to non-subscribers. The cost for re-distributing the keys using the unicast channel should be higher than the cost of purchasing the keys for this scheme to have an effect. To achieve this, MBMS uses a three-level key management, to distribute group keys to the clients, and be able to re-key by pushing down a new group key. MBMS has the need to identify which types of keys are involved in the MIKEY message and their identity.
MBMS对安全性的要求之一是能够频繁更新密钥。这背后的基本原理是订阅者将解密密钥重新分发给非订阅者的成本很高。使用单播信道重新分发密钥的成本应高于购买密钥的成本，以使该方案产生效果。为了实现这一点，MBMS使用三级密钥管理，将组密钥分发给客户端，并能够通过按下新的组密钥来重新设置密钥。MBMS需要识别MIKEY消息中涉及的密钥类型及其标识。
[RFC4563] specifies a new Type for the General Extension Payload in MIKEY, to identify the type and identity of involved keys. Moreover, as MBMS uses MIKEY both as a registration protocol and a re-key protocol, this RFC specifies the necessary additions that allow MIKEY to function both as a unicast and multicast re-key protocol in the MBMS setting.
[RFC4563]为MIKEY中的通用扩展有效负载指定一个新类型，以标识所涉及密钥的类型和标识。此外，由于MBMS同时将MIKEY用作注册协议和重设密钥协议，因此此RFC指定了必要的添加，以允许MIKEY在MBMS设置中同时用作单播和多播重设密钥协议。
The document [RFC4909] specifies a new general extension payload type for use in the Open Mobile Alliance (OMA) Browser and Content Broadcast (BCAST) group. OMA BCAST's service and content protection specification uses short-term key message and long-term key message payloads that in certain broadcast distribution systems are carried in MIKEY. The document defines a general extension payload to allow possible extensions to MIKEY without defining a new payload. The general extension payload can be used in any MIKEY message and is part of the authenticated or signed data part. Note that only a parameter description is included, but no key information.
文档[RFC4909]指定了一种新的通用扩展有效负载类型，用于开放移动联盟（OMA）浏览器和内容广播（BCAST）组。OMA BCAST的服务和内容保护规范使用在某些广播分发系统中由MIKEY承载的短期关键消息和长期关键消息有效载荷。该文档定义了一个通用扩展负载，允许在不定义新负载的情况下对MIKEY进行可能的扩展。通用扩展有效负载可用于任何MIKEY消息，并且是经过身份验证或签名的数据部分的一部分。请注意，仅包含参数说明，但不包含关键信息。
The document [RFC4771] defines a new integrity transform for SRTP [RFC3711] providing the option to also transmit the Roll Over Counter (ROC) as part of dedicated SRTP packets. This extension has been defined for use in the 3GPP multicast/broadcast service. While the communicating parties did agree on a starting ROC, in some cases the receiver may not be able to synchronize his ROC with the one used by the sender even if it is signaled to him out of band. Here the new extension provides the possibility for the receiver to re-synchronize to the sender's ROC. To signal the use of the new integrity transform, new definitions for certain MIKEY payloads need to be done. These new definitions comprise the integrity transform itself as well as a new integrity transform parameters. Moreover, the document specifies additional parameter, to enable the usage of different integrity transforms for SRTP and SRTCP.
文件[RFC4771]为SRTP[RFC3711]定义了一个新的完整性转换，提供了也作为专用SRTP数据包的一部分传输滚动计数器（ROC）的选项。该扩展已定义为在3GPP多播/广播服务中使用。虽然通信双方确实同意起始ROC，但在某些情况下，即使在带外向接收方发送信号，接收方也可能无法将其ROC与发送方使用的ROC同步。在这里，新的扩展为接收方重新同步到发送方的ROC提供了可能性。为了表明使用了新的完整性转换，需要对某些MIKEY有效载荷进行新的定义。这些新定义包括完整性转换本身以及新的完整性转换参数。此外，该文档还指定了其他参数，以支持对SRTP和SRTCP使用不同的完整性转换。
While MIKEY and its extensions provide a variety of choices in terms of modes of operation, an implementation may choose to simplify its behavior. This can be achieved by operating in a single mode of operation when in the Initiator's role. Where PKI is available and/or required, an implementation may choose, for example, to start all sessions in RSA-R mode, and it would be trivial for it to act as a Responder in public key mode. If envelope keys are cached, it can then also choose to do re-keying in shared key mode. It is outside the scope of MIKEY or MIKEY extensions if the caching of envelope keys is allowed. This is a matter of the configuration of the involved components. This local configuration is also outside the scope of MIKEY. In general, modes of operation where the Initiator generates keying material are useful when two peers are aware of each other before the MIKEY communication takes place. If a peer chooses not to operate in the public key mode, it may reject the certificate of the Initiator. The same applies to peers that choose to operate in one of the DH modes exclusively.
虽然MIKEY及其扩展在操作模式方面提供了多种选择，但实现可以选择简化其行为。这可以通过在启动器角色下以单一操作模式操作来实现。在PKI可用和/或需要的情况下，实现可能会选择（例如）在RSA-R模式下启动所有会话，而在公钥模式下充当响应者则是微不足道的。如果缓存了信封密钥，它还可以选择在共享密钥模式下重新设置密钥。如果允许缓存信封密钥，则它不在MIKEY或MIKEY扩展的范围内。这是相关组件的配置问题。此本地配置也不在MIKEY的范围内。一般来说，当两个对等方在MIKEY通信发生之前相互了解时，启动器生成键控材料的操作模式是有用的。如果对等方选择不在公钥模式下操作，它可能会拒绝启动器的证书。这同样适用于选择专门在DH模式之一下运行的对等方。
Forward MIKEY modes, where the Initiator provides the key material, like public key or shared key mode when used in SIP/SDP may lead to complications in some call scenarios, for example, forking scenarios where key derivation material gets distributed to multiple parties. As mentioned earlier, this may be impractical as some of the destinations may not have the resources to validate the message and may cause the Initiator to drop the session invitation. Even in the case in which all parties involved have all the prerequisites for interpreting the MIKEY message received, there is a possible problem with multiple Responders starting media sessions using the same key. While the SSRCs will be different in most of the cases, they are only
转发MIKEY模式，其中发起者提供密钥材料，如在SIP/SDP中使用的公钥或共享密钥模式，可能会导致某些呼叫场景的复杂性，例如，密钥派生材料分发给多方的分叉场景。如前所述，这可能是不切实际的，因为某些目的地可能没有验证消息的资源，并且可能导致发起方放弃会话邀请。即使在所有相关方都具备解释收到的MIKEY消息的所有先决条件的情况下，多个响应者使用同一密钥启动媒体会话也可能存在问题。虽然SSRC在大多数情况下会有所不同，但它们只是
32 bits long and there is a high probability of a two-time pad problem. This is due to the support of scenarios like forking (see also Section 5.2) or retargeting (see also Section 5.3), where a two-time pad occurs if two branches have the same TEK (based on the MIKEY key establishment) and choose the same 32-bit SSRC for the SRTP streams and transmit SRTP packets. As suggested earlier, forward modes are most useful when the two peers are aware of each other before the communication takes place (as is the case in key renewal scenarios when costly public key operations can be avoided by using the envelope key).
32位长，很可能出现两次焊盘问题。这是由于支持分叉（另请参见第5.2节）或重定目标（另请参见第5.3节）等场景，其中如果两个分支具有相同的TEK（基于MIKEY密钥建立），并且为SRTP流选择相同的32位SSRC并传输SRTP包，则会出现两次pad。如前所述，当两个对等方在通信发生之前知道彼此时，转发模式最有用（如密钥更新场景中的情况，当使用信封密钥可以避免代价高昂的公钥操作时）。
The following list gives an idea how the different MIKEY modes may be used or combined, depending on available key material at the Initiator side.
下表给出了如何使用或组合不同的MIKEY模式，具体取决于启动器端可用的关键材料。
1. If the Initiator has a PSK with the Responder, it uses the PSK mode.
1. 如果启动器与响应程序有PSK，则使用PSK模式。
2. If the Initiator has a PSK with the Responder, but needs PFS or knows that the Responder has a policy that both parties should provide entropy to the key, then it uses the DH-HMAC mode.
2. 如果发起方与响应方有一个PSK，但需要PFS，或者知道响应方有一个双方都应该向密钥提供熵的策略，那么它使用DH-HMAC模式。
3. If the Initiator has the RSA key of the Responder, it uses the RSA mode to establish the TGK. Note that the TGK may be used as PSK together with Option 1 for further key management operations.
3. 如果发起方拥有响应方的RSA密钥，它将使用RSA模式建立TGK。注意，TGK可与选项1一起用作PSK，用于进一步的密钥管理操作。
4. If the Initiator does not expect the responder to have his certificate, he may use RSA-R. Using RSA-R, he can provide the Initiator's certificate information in-band to the receiver. Moreover, the Initiator may also provide a random number that can be used by the receiver for key generation. Thus, both parties can be involved in the key management. But as the inclusion of the random number cannot be forced by the Initiator, true PFS cannot be provided. Note that in this mode, after establishing the TGK, it may be used as PSK with other MIKEY modes.
4. 如果发起者不希望响应者拥有他的证书，他可以使用RSA-R。使用RSA-R，他可以在频带内向接收器提供发起者的证书信息。此外，发起者还可以提供可由接收器用于密钥生成的随机数。因此，双方都可以参与密钥管理。但由于发起者无法强制包含随机数，因此无法提供真正的PFS。注意，在此模式下，在建立TGK后，它可以与其他MIKEY模式一起用作PSK。
5. The Initiator uses DH-SIGN when PFS is required by his policy and he knows that the Responder has a policy that both parties should provide entropy. Note that also in this mode, after establishing the TGK, it may be used as PSK with other MIKEY modes.
5. 当其策略要求PFS时，发起方使用DH-SIGN，并且他知道响应方有一个双方都应提供熵的策略。请注意，在该模式下，在建立TGK后，它也可以与其他MIKEY模式一起用作PSK。
6. If no PSK or certificate is available at the Initiator's side (and likewise at the responder's side) but lower-level security (like TLS or IPsec) is in place the user may use the unprotected mode of MIKEY. It has to considered that using the unprotected mode enables intermediate nodes like proxies to actually get the exchanged master key in plain. This may not be intended, especially in cases where the intermediate node is not trusted.
6. 如果在发起方一侧（同样在响应方一侧）没有可用的PSK或证书，但存在较低级别的安全性（如TLS或IPsec），则用户可以使用MIKEY的无保护模式。必须考虑的是，使用无保护模式可以使中间节点（如代理）以普通方式实际获取交换的主密钥。这可能不是有意的，尤其是在中间节点不受信任的情况下。
Besides the available key material, choosing between the different modes of MIKEY depends strongly on the use case. This section will depict dedicated scenarios to discuss the feasibility of the different modes in these scenarios. A comparison of the different modes of operation regarding the influences and requirements to the deploying infrastructure as well as the cryptographic strength can be found in [SIP-MEDIA]. The following list provides the most prominent call scenarios and are matter of further discussion:
除了可用的关键材料外，MIKEY的不同模式之间的选择在很大程度上取决于用例。本节将描述专用场景，以讨论这些场景中不同模式的可行性。关于对部署基础设施的影响和要求以及加密强度的不同操作模式的比较，请参见[SIP-MEDIA]。以下列表提供了最突出的通话场景，有待进一步讨论：
o Early Media
o 早期媒体
o Forking
o 分叉
o Call Transfer/Redirect/Retarget
o 呼叫转移/重定向/重定目标
o Shared Key Conferencing
o 共享密钥会议
The term early media describes two different scenarios. The first one relates to the case where media data are received before the actual SDP signaling answer has been received. This may arise through the different latency on the signaling and media path. This case is often referred to as media before signaling answer. The second scenario describes the case were media data are send from the callee before sending the final SIP 200 OK message. This situation appears usually in call center scenarios, when queuing a waiting loop or when providing personal ring tones.
早期媒体一词描述了两种不同的情况。第一个涉及在接收到实际SDP信令应答之前接收媒体数据的情况。这可能是由于信令和媒体路径上的不同延迟引起的。这种情况通常在发出应答信号之前称为媒体。第二个场景描述了在发送最终SIP 200 OK消息之前从被叫方发送媒体数据的情况。这种情况通常出现在呼叫中心场景中，当排队等待环路或提供个人铃声时。
In early media scenarios, SRTP data may be received before the answer over the SIP signaling arrives. The two MIKEY modes, which only require one message to be transported (Section 3.1 and Section 3.2), work nicely in early media situations, as both sender and receiver have all the necessary parameters in place before actually sending/ receiving encrypted data. The other modes, featuring either Diffie-Hellman key agreement (Section 3.3, Section 3.5, and Section 3.6) or the enhanced asymmetric variant (Section 3.7), suffer from the requirements that the Initiator has to wait for the response before being able to decrypt the incoming SRTP media. In fact, even if early media is not used, in other words if media is not sent before the SDP answer, a similar problem may arise from the fact that SIP/ SDP signaling has to traverse multiple proxies on its way back and media may arrive before the SDP answer. It is expected that this delay would be significantly shorter than in the case of early media though.
在早期媒体场景中，SRTP数据可以在SIP信令上的应答到达之前接收。两种MIKEY模式只需要传输一条消息（第3.1节和第3.2节），在早期的媒体环境中工作良好，因为发送方和接收方在实际发送/接收加密数据之前都具备所有必要的参数。其他模式的特点是Diffie-Hellman密钥协议（第3.3节、第3.5节和第3.6节）或增强的非对称变体（第3.7节），其要求启动器必须等待响应才能解密传入的SRTP介质。事实上，即使没有使用早期媒体，换句话说，如果在SDP应答之前没有发送媒体，SIP/SDP信令在返回的过程中必须穿越多个代理，并且媒体可能在SDP应答之前到达，这一事实也可能产生类似的问题。不过，预计这一延迟将比早期媒体的情况短得多。
It is worth mentioning here that security descriptions [RFC4568] have basically the same problem as the initiating end needs the SDP answer before it can start decrypting SRTP media.
这里值得一提的是，安全描述[RFC4568]的问题基本上与发起端在开始解密SRTP媒体之前需要SDP应答的问题相同。
To cope with the early media problem, there are further approaches to describe security preconditions [RFC5027]; i.e., certain preconditions need to be met to enable voice data encryption. One example, for instance, is that a scenario where a provisional response, containing the required MIKEY parameter, is sent before encrypted media is processed.
为了应对早期媒体问题，有更多的方法来描述安全前提[RFC5027]；i、 例如，启用语音数据加密需要满足某些先决条件。例如，一个示例是在处理加密媒体之前发送包含所需MIKEY参数的临时响应的场景。
In SIP forking scenarios, a SIP proxy server sends an INVITE request to more than one location. This means also that the MIKEY payload, which is part of the SDP, is sent to several (different) locations. MIKEY modes supporting signatures may be used in forking scenarios (Section 3.3 and Section 3.7) as here the receiver can validate the signature. There are limitations with the symmetric key encryption as well as the asymmetric key encryption modes (Section 3.1 and Section 3.2). This is due to the fact that in symmetric encryption the recipient needs to possess the symmetric key before handling the MIKEY data. For asymmetric MIKEY modes, if the sender is aware of the forking he may not know in advance to which location the INVITE is forked and thus may not use the right receiver certificate to encrypt the MIKEY envelope key. Note that the sender may include several MIKEY containers into the same INVITE message to cope with forking, but this requires the knowledge of all forking targets in advance and also requires the possession of the target certificates. It is out of the scope of MIKEY to specify behavior in such a case. MIKEY Diffie Hellman modes or MIKEY-RSA_R Section 3.7 do not have this problem. In scenarios where the sender is not aware of forking, only the intended receiver is able to decrypt the MIKEY container.
在SIP分叉方案中，SIP代理服务器向多个位置发送INVITE请求。这也意味着作为SDP一部分的MIKEY有效载荷被发送到多个（不同）位置。支持签名的MIKEY模式可用于分叉场景（第3.3节和第3.7节），因为在这里接收器可以验证签名。对称密钥加密和非对称密钥加密模式都有局限性（第3.1节和第3.2节）。这是因为在对称加密中，接收方需要在处理MIKEY数据之前拥有对称密钥。对于非对称MIKEY模式，如果发送方知道分叉，他可能事先不知道INVITE分叉到哪个位置，因此可能不会使用正确的接收方证书加密MIKEY信封密钥。请注意，发送方可能在同一INVITE消息中包含多个MIKEY容器以处理分叉，但这需要提前了解所有分叉目标，还需要拥有目标证书。在这种情况下指定行为超出了MIKEY的范围。MIKEY Diffie-Hellman模式或MIKEY-RSA\R第3.7节不存在此问题。在发送方不知道分叉的情况下，只有预期的接收方能够解密MIKEY容器。
If forking is combined with early media, the situation gets aggravated. If MIKEY modes requiring a full roundtrip are used, like the signed Diffie-Hellman, multiple responses may overload the end device. An example is forking to 30 destinations (group pickup), while MIKEY is used with the signed Diffie-Hellman mode together with security preconditions. Here, every target would answer with a provisional response, leading to 30 signature validations and Diffie-Hellman calculations at the sender's site. This may lead to a prolonged media setup delay.
如果将分叉与早期媒体相结合，情况就会恶化。如果使用需要完整往返的MIKEY模式，如签名Diffie-Hellman，多个响应可能会使终端设备过载。例如，分岔到30个目的地（团体接送），而MIKEY与签名的Diffie-Hellman模式以及安全前提条件一起使用。在这里，每个目标都会给出一个临时响应，从而在发送者的站点上进行30次签名验证和Diffie-Hellman计算。这可能会导致媒体设置延迟延长。
Moreover, depending on the MIKEY mode chosen, a two-time pad may occur in dependence of the negotiated key material and the SSRC. For the non Diffie-Hellman modes other than RSA-R, a two-time pad may occur when multiple receivers pick the same SSRC.
此外，根据所选择的MIKEY模式，两次pad可能会根据协商的密钥材料和SSRC发生。对于RSA-R以外的非Diffie-Hellman模式，当多个接收机拾取相同的SSRC时，可能会出现两次pad。
In a SIP environment, MIKEY exchange is tied to SDP offer/answer and irrespective of the implementation model used for call transfer the same properties and limitations of MIKEY modes apply as in a normal call setup scenario.
在SIP环境中，MIKEY exchange与SDP提供/应答绑定，无论用于呼叫转移的实现模型如何，MIKEY模式的相同属性和限制适用于正常呼叫设置场景。
In certain SIP scenarios, the functionality of redirect is supported. In redirect scenarios, the call initiator gets a response that the called party for instance has temporarily moved and may be reached at a different destination. The caller can now perform a call establishment with the new destination. Depending on the originally chosen MIKEY mode, the caller may not be able to perform this mode with the new destination. To be more precise, MIKEY-PSK and MIKEY-DHHMAC require a pre-shared secret in advance. MIKEY-RSA requires the knowledge about the target's certificate. Thus, these modes may influence the ability of the caller to initiate a session.
在某些SIP场景中，支持重定向功能。在重定向场景中，呼叫发起方获得一个响应，例如被叫方临时移动了该响应，并且可能到达另一个目的地。呼叫方现在可以使用新的目的地执行呼叫建立。根据最初选择的MIKEY模式，呼叫方可能无法在新目的地上执行此模式。更准确地说，MIKEY-PSK和MIKEY-DHHMAC需要预先共享秘密。MIKEY-RSA需要了解目标的证书。因此，这些模式可能影响调用者发起会话的能力。
Another functionality that may be supported in SIP is retargeting. In contrast to redirect, the call initiator does not get a response about the different target. The SIP proxy sends the request to a different target about receiving a redirect response from the originally called target. This most likely will lead to problems when using MIKEY modes requiring a pre-shared key (MIKEY-PSK, MIKEY-DHHMAC) or where the caller used asymmetric key encryption (MIKEY-RSA) because the key management was originally targeted to a different destination.
SIP中可能支持的另一个功能是重定目标。与重定向相反，调用发起程序不会得到关于不同目标的响应。SIP代理向另一个目标发送关于从最初调用的目标接收重定向响应的请求。当使用需要预共享密钥的MIKEY模式（MIKEY-PSK、MIKEY-DHHMAC）或调用者使用非对称密钥加密（MIKEY-RSA）时，这很可能会导致问题，因为密钥管理最初针对不同的目的地。
First of all, not all modes of MIKEY support shared key conferencing. Mainly the Diffie-Hellman modes cannot be used straight-forward for conferencing as this mechanism results in a pair wise shared secret key. All other modes can be applied in conferencing scenarios by obeying the Initiator and Responder roles; i.e., the half roundtrip modes need to be initiated by the conferencing unit to be able to distribute the conferencing key. The remaining full roundtrip mode, MIKEY RSA-R, will be initiated by the client, while the conferencing unit provides the conferencing key based on the received certificate.
首先，并非所有的MIKEY模式都支持共享密钥会议。主要是Diffie-Hellman模式不能直接用于会议，因为这种机制会导致成对共享密钥。所有其他模式都可以通过遵守发起人和响应人角色在会议场景中应用；i、 例如，半往返模式需要由会议单元启动，以便能够分发会议密钥。剩余的完整往返模式MIKEY RSA-R将由客户端启动，而会议单元将根据收到的证书提供会议密钥。
An example conferencing architecture is defined in the IETF's XCON WG. The scope of this working group relates to a mechanism for membership and authorization control, a mechanism to manipulate and describe media "mixing" or "topology" for multiple media types (audio, video, text), a mechanism for notification of conference-related events/changes (for example, a floor change), and a basic floor control protocol. A document describing possible use case scenarios is available in [RFC4597].
IETF的XCON工作组中定义了一个示例会议架构。该工作组的范围涉及成员资格和授权控制机制、操纵和描述多种媒体类型（音频、视频、文本）的媒体“混合”或“拓扑结构”的机制、会议相关事件/变更通知机制（例如，楼层变更）以及基本楼层控制协议。[RFC4597]中提供了描述可能用例场景的文档。
The following two tables summarize the discussion from the previous subsections. The first table matches the scenarios discussed in this section to the different MIKEY modes.
以下两个表格总结了前几小节的讨论。第一个表将本节讨论的场景与不同的MIKEY模式相匹配。
MIKEY Early Secure Retarget Redirect Shared
mode Media Forking Key Conf
---------------------------------------------------------------------
PSK (3.1) Yes Yes*
RSA (3.2) Yes Yes*
DH-SIGN (3.3) Yes* Yes Yes
Unprotected (3.4) Yes
DH-HMAC (3.5)
RSA-R (3.7) Yes Yes Yes Yes
MIKEY Early Secure Retarget Redirect Shared
mode Media Forking Key Conf
---------------------------------------------------------------------
PSK (3.1) Yes Yes*
RSA (3.2) Yes Yes*
DH-SIGN (3.3) Yes* Yes Yes
Unprotected (3.4) Yes
DH-HMAC (3.5)
RSA-R (3.7) Yes Yes Yes Yes
* In centralized conferencing, the media mixer needs to send the MIKEY Initiator message.
* 在集中式会议中，媒体混合器需要发送MIKEY Initiator消息。
The following table maps the MIKEY modes to key management-related properties.
下表将MIKEY模式映射到与密钥管理相关的属性。
MIKEY Manual Needs PFS Key Generation
mode Keys PKI Involvement
--------------------------------------------------------------
PSK (3.1) Yes No No Initiator
RSA (3.2) No Yes No Initiator
DH-SIGN (3.3) No Yes Yes Both
Unprotected (3.4) No No No Initiator
DH-HMAC (3.5) Yes No Yes Both
RSA-R (3.7) No Yes No Both*
MIKEY Manual Needs PFS Key Generation
mode Keys PKI Involvement
--------------------------------------------------------------
PSK (3.1) Yes No No Initiator
RSA (3.2) No Yes No Initiator
DH-SIGN (3.3) No Yes Yes Both
Unprotected (3.4) No No No Initiator
DH-HMAC (3.5) Yes No Yes Both
RSA-R (3.7) No Yes No Both*
* Assumed the Initiator provides the (optional) RAND value
* 假设启动器提供（可选）RAND值
MIKEY defines message formats to transport key information and security policies between communicating entities. It does not define the embedding of these messages into the used signaling protocol. This definition is provided in separate documents, depending on the used signaling protocol. Nevertheless, MIKEY can also be transported over plain UDP or TCP to port 2269.
MIKEY定义了在通信实体之间传输关键信息和安全策略的消息格式。它没有定义将这些消息嵌入到所使用的信令协议中。该定义在单独的文件中提供，具体取决于所使用的信令协议。尽管如此，MIKEY也可以通过普通UDP或TCP传输到端口2269。
Several IETF-defined protocols utilize the Session Description Protocol (SDP, [RFC4566]) to transport the session parameters. Examples are the Session Initiation Protocol (SIP, [RFC3261] or the Gateway Control Protocol (GCP, [RFC5125]). The transport of MIKEY messages as part of SDP is described in [RFC4567]. Here, the
几个IETF定义的协议利用会话描述协议（SDP，[RFC4566]）来传输会话参数。例如会话启动协议（SIP，[RFC3261]或网关控制协议（GCP，[RFC5125]）。作为SDP一部分的MIKEY消息传输在[RFC4567]中进行了描述。此处
complete MIKEY message is base64 encoded and transmitted as part of the SDP part of the signaling protocol message. Note that as several key distribution messages may be transported within one SDP container, [RFC4567] also comprises an integrity protection regarding all supplied key distribution attempts. Thus, bidding-down attacks will be recognized. Regarding RTSP, [RFC4567] defines header extensions allowing the transport of MIKEY messages. Here, the initial messages uses SDP, while the remaining part of the key management is performed using the header extensions.
完整的MIKEY消息是base64编码的，并作为信令协议消息的SDP部分传输。注意，由于多个密钥分发消息可以在一个SDP容器中传输，[RFC4567]还包括关于所有提供的密钥分发尝试的完整性保护。因此，将识别出对攻击的压制。关于RTSP，[RFC4567]定义了允许传输MIKEY消息的报头扩展。这里，初始消息使用SDP，而密钥管理的其余部分使用报头扩展执行。
MIKEY is also applied in ITU-T protocols like H.323, which is used to establish communication sessions similar to SIP. For H.323, a security framework exists, which is defined in H.235. Within this framework, H.235.7 [H.235.7] describes the usage of MIKEY and SRTP in the context of H.323. In contrast to SIP, H.323 uses ASN.1 (Abstract Syntax Notation). Thus, there is no need to encode the MIKEY container as base64. Within H.323, the MIKEY container is binary encoded.
MIKEY还应用于ITU-T协议，如H.323，用于建立类似于SIP的通信会话。对于H.323，存在一个在H.235中定义的安全框架。在此框架内，H.235.7[H.235.7]描述了H.323上下文中MIKEY和SRTP的用法。与SIP不同，H.323使用ASN.1（抽象语法表示法）。因此，不需要将MIKEY容器编码为base64。在H.323中，MIKEY容器是二进制编码的。
Besides MIKEY, there exist several approaches to handle the security parameter establishment. This is due to the fact that some limitations in certain scenarios have been seen. Examples are early media and forking situations as described in Section 5. The following list provides a short summary about possible alternatives:
除了MIKEY之外，还有几种方法可以处理安全参数的建立。这是因为在某些场景中已经看到了一些限制。例如第5节所述的早期媒体和分叉情况。以下列表简要总结了可能的备选方案：
o sdescription - [RFC4568] describes a key management scheme, which uses SDP for transport and completely relies on underlying protocol security. For transport, the document defines an SDP attribute transmitting all necessary SRTP parameter in clear. For security, it references TLS and S/MIME. In contrast to MIKEY, the SRTP parameter in the Initiator-to-Responder direction is actually sent in the message from the Initiator to the Responder rather than vice versa. This may lead to problems in early media scenarios.
o sdescription-[RFC4568]描述了一种密钥管理方案，该方案使用SDP进行传输，完全依赖于底层协议安全性。对于传输，文档定义了一个SDP属性，以明文形式传输所有必要的SRTP参数。为了安全起见，它引用了TLS和S/MIME。与MIKEY不同，启动器到响应程序方向中的SRTP参数实际上是在消息中从启动器发送到响应程序，而不是相反。这可能会导致早期媒体场景出现问题。
o sdescription with early media support - [WING-MMUSIC] enhances the above scheme with the possibility to also be usable in early media scenarios, when security preconditions are not used.
o 带有早期媒体支持的描述-[WING-MMUSIC]增强了上述方案，在不使用安全前提条件的情况下，也可以在早期媒体场景中使用。
o Encrypted Key Transport for Secure RTP - [MCGREW-SRTP] is an extension to SRTP that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control, and to handle situations caused by SIP forking and early media. It may also be used in conjunction with MIKEY.
o 用于安全RTP的加密密钥传输-[MCGREW-SRTP]是SRTP的扩展，它在SRTCP内提供SRTP主密钥、滚动计数器和其他信息的安全传输。此功能使SRTP能够在控制最少的情况下为分散的会议工作，并处理由SIP分叉和早期媒体引起的情况。它也可以与MIKEY一起使用。
o Diffie-Hellman support in SDP - [BAUGHER] defines a new SDP attribute for exchanging Diffie-Hellman public keys. The attribute is an SDP session-level attribute for describing DH keys, and there is a new media-level parameter for describing public keying material for SRTP key generation.
o SDP中的Diffie-Hellman支持-[BAUGHER]为交换Diffie-Hellman公钥定义了一个新的SDP属性。该属性是用于描述DH密钥的SDP会话级属性，并且有一个新的媒体级参数用于描述用于生成SRTP密钥的公钥材料。
o DTLS-SRTP describing SRTP extensions for DTLS - [AVT-DTLS] describes a method of using DTLS key management for SRTP by using a new extension that indicates that SRTP is to be used for data protection and that establishes SRTP keys.
o 描述DTLS的SRTP扩展的DTLS-SRTP-[AVT-DTLS]描述了一种通过使用新扩展为SRTP使用DTLS密钥管理的方法，该扩展指示SRTP将用于数据保护并建立SRTP密钥。
o ZRTP - [ZIMMERMANN] defines ZRTP as RTP header extensions for a Diffie-Hellman exchange to agree on a session key and parameters for establishing SRTP sessions. The ZRTP protocol is completely self-contained in RTP and does not require support in the signaling protocol or assume a PKI.
o ZRTP-[ZIMMERMANN]将ZRTP定义为Diffie-Hellman交换的RTP头扩展，以商定建立SRTP会话的会话密钥和参数。ZRTP协议在RTP中是完全独立的，不需要信令协议的支持或假定PKI。
There has been a long discussion regarding a preferred key management approach in the IETF coping with the different scenarios and requirements continuously sorting out key management approaches. During IETF 68, three options were considered: MIKEY in an updated version (referred to as MIKEYv2), ZRTP, and DTLS-SRTP. The potential key management protocol for the standards track for media security was voted in favor of DTLS-SRTP. Thus, the reader is pointed to the appropriate resources for further information on DTLS-SRTP [AVT-DTLS]. Note that MIKEY has already been deployed for setting up SRTP security context and is also targeted for use in MBMS applications.
关于IETF中的首选密钥管理方法，已经进行了长时间的讨论，以应对不同的场景和需求，并不断整理密钥管理方法。在IETF 68期间，考虑了三个选项：更新版本中的MIKEY（称为MIKEYv2）、ZRTP和DTLS-SRTP。媒体安全标准轨道的潜在密钥管理协议投票赞成DTLS-SRTP。因此，读者被指向适当的资源以获得关于DTLS-SRTP[AVT-DTLS]的进一步信息。请注意，MIKEY已经部署用于设置SRTP安全上下文，并且也用于MBMS应用程序。
For MIKEY and the extensions to MIKEY, IANA registrations have been made. Here only a link to the appropriate IANA registration is provided to avoid inconsistencies. The IANA registrations for MIKEY payloads can be found under http://www.iana.org/assignments/mikey-payloads. These registrations comprise the MIKEY base registrations as well as registrations made by MIKEY extensions regarding the payload.
对于MIKEY和MIKEY的扩展，IANA注册已经完成。此处仅提供了指向适当IANA注册的链接，以避免不一致。MIKEY有效载荷的IANA注册可以在下找到http://www.iana.org/assignments/mikey-payloads. 这些注册包括MIKEY base注册以及MIKEY extensions就有效载荷进行的注册。
The IANA registrations for MIKEY port numbers can be found under http://www.iana.org/assignments/port-numbers (search for MIKEY).
有关MIKEY端口号的IANA注册，请参见http://www.iana.org/assignments/port-numbers （寻找米奇）。
This document does not define extensions to existing protocols. It rather provides an overview about the set of MIKEY modes and available extensions and provides information about the applicability of the different modes in different scenarios to support the decision
本文档不定义对现有协议的扩展。相反，它提供了有关MIKEY模式集和可用扩展的概述，并提供了有关不同模式在不同场景中的适用性的信息，以支持决策
making for network architects regarding the appropriate MIKEY scheme or extension to be used in a dedicated target scenario. Choosing between the different schemes described in this document strongly influences the security of the target system as the different schemes provide different levels of security and also require different infrastructure support.
为网络架构师提供在专用目标场景中使用的适当MIKEY方案或扩展。在本文档中描述的不同方案之间进行选择会严重影响目标系统的安全性，因为不同的方案提供不同级别的安全性，并且还需要不同的基础设施支持。
As this document is based on the MIKEY base specification as well as the different specifications of the extensions, the reader is referred to the original documents for the specific security considerations.
由于本文档基于MIKEY base规范以及不同的扩展规范，读者可参考原始文档了解具体的安全注意事项。
The authors would like to thank Lakshminath Dondeti for his document reviews and for his guidance.
作者要感谢Lakshminath Dondeti的文件审查和指导。
[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月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[AVT-DTLS] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, February 2008.
[AVT-DTLS]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，正在进行的工作，2008年2月。
[BAUGHER] Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Multimedia Sessions", Work in Progress, February 2006.
[BAUGHER]BAUGHER，M.和D.McGrew，“Diffie Hellman交换多媒体会话”，正在进行的工作，2006年2月。
[H.235.7] ""ITU-T Recommendation H.235.7: Usage of the MIKEY Key Management Protocol for the Secure Real Time Transport Protocol (SRTP) within H.235"", 2005.
[H.235.7]“ITU-T建议H.235.7：H.235中安全实时传输协议（SRTP）的米奇密钥管理协议的使用”，2005年。
[ISO_sec_time] ""ISO/IEC 18014 Information technology - Security techniques - Time-stamping services, Part 1- 3.http://www.oasis-open.org/committees/ documents.php?wg_abbrev=security"", 2002.
ISO/IEC 18014信息技术-安全技术-时间戳服务，第1-3部分。http://www.oasis-open.org/committees/ documents.php？wg_abbrev=security“，2002年。
[MCGREW-SRTP] McGrew, D., "Encrypted Key Transport for Secure RTP", Work in Progress, March 2007.
[MCGREW-SRTP]MCGREW，D.，“安全RTP的加密密钥传输”，正在进行的工作，2007年3月。
[MSEC-MIKEY] Milne, A., "ECC Algorithms for MIKEY", Work in Progress, June 2007.
[MSEC-MIKEY]Milne，A.，“MIKEY的ECC算法”，正在进行的工作，2007年6月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（版本3）规范，实施”，RFC1305，1992年3月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.
[RFC4383]Baugher，M.和E.Carrara，“在安全实时传输协议（SRTP）中使用定时高效流丢失容忍认证（TESLA）”，RFC 4383，2006年2月。
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006.
[RFC4442]Fries，S.和H.Tschofenig，“自举定时高效流丢失容忍认证（TESLA）”，RFC 4442，2006年3月。
[RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
[RFC4563]Carrara，E.，Lehtovirta，V.，和K.Norrman，“多媒体互联网键控（MIKEY）中通用扩展有效载荷的密钥ID信息类型”，RFC 4563，2006年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月。
[RFC4567] 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.
[RFC4567]Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，2006年7月。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC4597]伊恩，R.和N.伊斯梅尔，“会议场景”，RFC4597，2006年8月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650]Euchner，M.“HMAC认证的Diffie Hellman多媒体互联网密钥（MIKEY）”，RFC 46502006年9月。
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006.
[RFC4738]Ignjatic，D.，Dondeti，L.，Audet，F.，和P.Lin，“MIKEY-RSA-R：多媒体互联网密钥分配（MIKEY）中的另一种密钥分配模式”，RFC 4738，2006年11月。
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC4771]Lehtovirta，V.，Naslund，M.，和K.Norrman，“安全实时传输协议（SRTP）的完整性转换携带滚动计数器”，RFC 4771，2007年1月。
[RFC4909] Dondeti, L., Castleford, D., and F. Hartung, "Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport", RFC 4909, June 2007.
[RFC4909]Dondeti，L.，Castleford，D.，和F.Hartung，“开放移动联盟BCAST LTKM/STKM传输的多媒体互联网键控（MIKEY）通用扩展有效载荷”，RFC 49092007年6月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007.
[RFC5027]Andreasen，F.和D.Wing，“会话描述协议（SDP）媒体流的安全先决条件”，RFC 5027，2007年10月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125]Taylor，T.，“将RFC 3525重新分类为历史”，RFC 51252008年2月。
[SAML_overview] Huges, J. and E. Maler, "Security Assertion Markup Language (SAML) 2.0 Technical Overview, Working Draft", 2005.
[SAML_概述]Huges，J.和E.Maler，“安全断言标记语言（SAML）2.0技术概述，工作草案”，2005年。
[SIP-MEDIA] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", Work in Progress, June 2008.
[SIP-MEDIA]Wing，D.，Fries，S.，Tschofenig，H.，和F.Audet，“媒体安全管理协议的要求和分析”，正在进行的工作，2008年6月。
[WING-MMUSIC] Raymond, R. and D. Wing, "Security Descriptions Extension for Early Media", Work in Progress, October 2005.
[WING-MMUSIC]Raymond，R.and D.WING，“早期媒体的安全描述扩展”，正在进行的工作，2005年10月。
[ZIMMERMANN] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, June 2008.
[ZIMMERMANN]ZIMMERMANN，P.，Johnston，A.，和J.Callas，“ZRTP：安全RTP的媒体路径密钥协议”，正在进行的工作，2008年6月。
Authors' Addresses
作者地址
Steffen Fries Siemens Corporate Technology Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Steffen Fries西门子公司技术奥托·哈恩环6德国巴伐利亚州慕尼黑81739
EMail: steffen.fries@siemens.com
EMail: steffen.fries@siemens.com
Dragan Ignjatic Polycom 3605 Gilmore Way Burnaby, BC V5G 4X5 Canada
加拿大不列颠哥伦比亚省本纳比市吉尔摩路3605号德拉根伊格纳蒂克Polycom V5G 4X5
EMail: dignjatic@polycom.com
EMail: dignjatic@polycom.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.