Network Working Group J. Arkko
Request for Comments: 3830 E. Carrara
Category: Standards Track F. Lindholm
M. Naslund
K. Norrman
Ericsson Research
August 2004
Network Working Group J. Arkko
Request for Comments: 3830 E. Carrara
Category: Standards Track F. Lindholm
M. Naslund
K. Norrman
Ericsson Research
August 2004
MIKEY: Multimedia Internet KEYing
多媒体互联网键控
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real-time Transport Protocol is described in detail.
本文档描述了一种可用于实时应用程序（用于对等通信和组通信）的密钥管理方案。特别地，详细描述了其用于支持安全实时传输协议的用途。
Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols.
实时多媒体应用的安全协议已经开始出现。这就需要一个密钥管理解决方案来支持这些协议。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Existing Solutions . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.3. Definitions. . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Abbreviations. . . . . . . . . . . . . . . . . . . . . . 6
1.5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 8
2.3. System Overview. . . . . . . . . . . . . . . . . . . . . 8
2.4. Relation to GKMARCH. . . . . . . . . . . . . . . . . . . 10
3. Basic Key Transport and Exchange Methods . . . . . . . . . . . 10
3.1. Pre-shared Key . . . . . . . . . . . . . . . . . . . . . 12
3.2. Public-Key Encryption. . . . . . . . . . . . . . . . . . 13
3.3. Diffie-Hellman Key Exchange. . . . . . . . . . . . . . . 14
4. Selected Key Management Functions. . . . . . . . . . . . . . . 15
4.1. Key Calculation. . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Assumptions. . . . . . . . . . . . . . . . . . . 16
4.1.2. Default PRF Description. . . . . . . . . . . . . 17
4.1.3. Generating keys from TGK . . . . . . . . . . . . 18
4.1.4. Generating keys for MIKEY Messages from
an Envelope/Pre-Shared Key . . . . . . . . . . . 19
4.2 Pre-defined Transforms and Timestamp Formats . . . . . . . 19
4.2.1. Hash Functions . . . . . . . . . . . . . . . . . 19
4.2.2. Pseudo-Random Number Generator and PRF . . . . . 20
4.2.3. Key Data Transport Encryption. . . . . . . . . . 20
4.2.4. MAC and Verification Message Function. . . . . . 21
4.2.5. Envelope Key Encryption. . . . . . . . . . . . . 21
4.2.6. Digital Signatures . . . . . . . . . . . . . . . 21
4.2.7. Diffie-Hellman Groups. . . . . . . . . . . . . . 21
4.2.8. Timestamps . . . . . . . . . . . . . . . . . . . 21
4.2.9. Adding New Parameters to MIKEY . . . . . . . . . 22
4.3. Certificates, Policies and Authorization . . . . . . . . 22
4.3.1. Certificate Handling . . . . . . . . . . . . . . 22
4.3.2. Authorization. . . . . . . . . . . . . . . . . . 23
4.3.3. Data Policies. . . . . . . . . . . . . . . . . . 24
4.4. Retrieving the Data SA . . . . . . . . . . . . . . . . . 24
4.5. TGK Re-Keying and CSB Updating . . . . . . . . . . . . . 25
5. Behavior and Message Handling. . . . . . . . . . . . . . . . . 26
5.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1. Capability Discovery . . . . . . . . . . . . . . 26
5.1.2. Error Handling . . . . . . . . . . . . . . . . . 27
5.2. Creating a Message . . . . . . . . . . . . . . . . . . . 28
5.3. Parsing a Message. . . . . . . . . . . . . . . . . . . . 29
5.4. Replay Handling and Timestamp Usage. . . . . . . . . . . 30
6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Existing Solutions . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.3. Definitions. . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Abbreviations. . . . . . . . . . . . . . . . . . . . . . 6
1.5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 8
2.3. System Overview. . . . . . . . . . . . . . . . . . . . . 8
2.4. Relation to GKMARCH. . . . . . . . . . . . . . . . . . . 10
3. Basic Key Transport and Exchange Methods . . . . . . . . . . . 10
3.1. Pre-shared Key . . . . . . . . . . . . . . . . . . . . . 12
3.2. Public-Key Encryption. . . . . . . . . . . . . . . . . . 13
3.3. Diffie-Hellman Key Exchange. . . . . . . . . . . . . . . 14
4. Selected Key Management Functions. . . . . . . . . . . . . . . 15
4.1. Key Calculation. . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Assumptions. . . . . . . . . . . . . . . . . . . 16
4.1.2. Default PRF Description. . . . . . . . . . . . . 17
4.1.3. Generating keys from TGK . . . . . . . . . . . . 18
4.1.4. Generating keys for MIKEY Messages from
an Envelope/Pre-Shared Key . . . . . . . . . . . 19
4.2 Pre-defined Transforms and Timestamp Formats . . . . . . . 19
4.2.1. Hash Functions . . . . . . . . . . . . . . . . . 19
4.2.2. Pseudo-Random Number Generator and PRF . . . . . 20
4.2.3. Key Data Transport Encryption. . . . . . . . . . 20
4.2.4. MAC and Verification Message Function. . . . . . 21
4.2.5. Envelope Key Encryption. . . . . . . . . . . . . 21
4.2.6. Digital Signatures . . . . . . . . . . . . . . . 21
4.2.7. Diffie-Hellman Groups. . . . . . . . . . . . . . 21
4.2.8. Timestamps . . . . . . . . . . . . . . . . . . . 21
4.2.9. Adding New Parameters to MIKEY . . . . . . . . . 22
4.3. Certificates, Policies and Authorization . . . . . . . . 22
4.3.1. Certificate Handling . . . . . . . . . . . . . . 22
4.3.2. Authorization. . . . . . . . . . . . . . . . . . 23
4.3.3. Data Policies. . . . . . . . . . . . . . . . . . 24
4.4. Retrieving the Data SA . . . . . . . . . . . . . . . . . 24
4.5. TGK Re-Keying and CSB Updating . . . . . . . . . . . . . 25
5. Behavior and Message Handling. . . . . . . . . . . . . . . . . 26
5.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1. Capability Discovery . . . . . . . . . . . . . . 26
5.1.2. Error Handling . . . . . . . . . . . . . . . . . 27
5.2. Creating a Message . . . . . . . . . . . . . . . . . . . 28
5.3. Parsing a Message. . . . . . . . . . . . . . . . . . . . 29
5.4. Replay Handling and Timestamp Usage. . . . . . . . . . . 30
6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Common Header Payload (HDR). . . . . . . . . . . . . . . 32
6.1.1. SRTP ID. . . . . . . . . . . . . . . . . . . . . 35
6.2. Key Data Transport Payload (KEMAC) . . . . . . . . . . . 36
6.3. Envelope Data Payload (PKE). . . . . . . . . . . . . . . 37
6.4. DH Data Payload (DH) . . . . . . . . . . . . . . . . . . 38
6.5. Signature Payload (SIGN) . . . . . . . . . . . . . . . . 39
6.6. Timestamp Payload (T). . . . . . . . . . . . . . . . . . 39
6.7. ID Payload (ID) / Certificate Payload (CERT) . . . . . . 40
6.8. Cert Hash Payload (CHASH). . . . . . . . . . . . . . . . 41
6.9. Ver msg payload (V). . . . . . . . . . . . . . . . . . . 42
6.10. Security Policy Payload (SP) . . . . . . . . . . . . . . 42
6.10.1. SRTP Policy. . . . . . . . . . . . . . . . . . . 44
6.11. RAND Payload (RAND). . . . . . . . . . . . . . . . . . . 45
6.12. Error Payload (ERR). . . . . . . . . . . . . . . . . . . 46
6.13. Key Data Sub-Payload . . . . . . . . . . . . . . . . . . 46
6.14. Key Validity Data. . . . . . . . . . . . . . . . . . . . 48
6.15. General Extension Payload. . . . . . . . . . . . . . . . 50
7. Transport Protocols. . . . . . . . . . . . . . . . . . . . . . 50
8. Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.1. Simple One-to-Many . . . . . . . . . . . . . . . . . . . 51
8.2. Small-Size Interactive Group . . . . . . . . . . . . . . 51
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 52
9.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 52
9.2. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . 54
9.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 55
9.4. Identity Protection. . . . . . . . . . . . . . . . . . . 55
9.5. Denial of Service. . . . . . . . . . . . . . . . . . . . 56
9.6. Session Establishment. . . . . . . . . . . . . . . . . . 56
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 57
10.1. MIME Registration. . . . . . . . . . . . . . . . . . . . 59
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. - MIKEY - SRTP Relation. . . . . . . . . . . . . . . . 63
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 66
6.1. Common Header Payload (HDR). . . . . . . . . . . . . . . 32
6.1.1. SRTP ID. . . . . . . . . . . . . . . . . . . . . 35
6.2. Key Data Transport Payload (KEMAC) . . . . . . . . . . . 36
6.3. Envelope Data Payload (PKE). . . . . . . . . . . . . . . 37
6.4. DH Data Payload (DH) . . . . . . . . . . . . . . . . . . 38
6.5. Signature Payload (SIGN) . . . . . . . . . . . . . . . . 39
6.6. Timestamp Payload (T). . . . . . . . . . . . . . . . . . 39
6.7. ID Payload (ID) / Certificate Payload (CERT) . . . . . . 40
6.8. Cert Hash Payload (CHASH). . . . . . . . . . . . . . . . 41
6.9. Ver msg payload (V). . . . . . . . . . . . . . . . . . . 42
6.10. Security Policy Payload (SP) . . . . . . . . . . . . . . 42
6.10.1. SRTP Policy. . . . . . . . . . . . . . . . . . . 44
6.11. RAND Payload (RAND). . . . . . . . . . . . . . . . . . . 45
6.12. Error Payload (ERR). . . . . . . . . . . . . . . . . . . 46
6.13. Key Data Sub-Payload . . . . . . . . . . . . . . . . . . 46
6.14. Key Validity Data. . . . . . . . . . . . . . . . . . . . 48
6.15. General Extension Payload. . . . . . . . . . . . . . . . 50
7. Transport Protocols. . . . . . . . . . . . . . . . . . . . . . 50
8. Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.1. Simple One-to-Many . . . . . . . . . . . . . . . . . . . 51
8.2. Small-Size Interactive Group . . . . . . . . . . . . . . 51
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 52
9.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 52
9.2. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . 54
9.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 55
9.4. Identity Protection. . . . . . . . . . . . . . . . . . . 55
9.5. Denial of Service. . . . . . . . . . . . . . . . . . . . 56
9.6. Session Establishment. . . . . . . . . . . . . . . . . . 56
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 57
10.1. MIME Registration. . . . . . . . . . . . . . . . . . . . 59
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. - MIKEY - SRTP Relation. . . . . . . . . . . . . . . . 63
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 66
There has recently been work to define a security protocol for the protection of real-time applications running over RTP, [SRTP]. However, a security protocol needs a key management solution to exchange keys and related security parameters. There are some fundamental properties that such a key management scheme has to fulfill to serve streaming and real-time applications (such as unicast and multicast), particularly in heterogeneous (mix of wired and wireless) networks.
最近有一项工作是定义一个安全协议，用于保护在RTP上运行的实时应用程序[SRTP]。然而，安全协议需要密钥管理解决方案来交换密钥和相关安全参数。这种密钥管理方案必须满足一些基本特性，以服务于流式和实时应用（如单播和多播），特别是在异构（有线和无线混合）网络中。
This document describes a key management solution that addresses multimedia scenarios (e.g., SIP [SIP] calls and RTSP [RTSP] sessions). The focus is on how to set up key management for secure multimedia sessions such that requirements in a heterogeneous environment are fulfilled.
本文档描述了一个密钥管理解决方案，该解决方案解决了多媒体场景（例如SIP[SIP]呼叫和RTSP[RTSP]会话）。重点是如何为安全的多媒体会话设置密钥管理，以满足异构环境中的需求。
There is work done in the IETF to develop key management schemes. For example, IKE [IKE] is a widely accepted unicast scheme for IPsec, and the MSEC WG is developing other schemes to address group communication [GDOI, GSAKMP]. However, for reasons discussed below, there is a need for a scheme with lower latency, suitable for demanding cases such as real-time data over heterogeneous networks and small interactive groups.
IETF中有开发密钥管理方案的工作。例如，IKE[IKE]是IPsec广泛接受的单播方案，MSEC WG正在开发其他方案来解决组通信[GDOI，GSAKMP]。然而，出于下面讨论的原因，需要一种具有较低延迟的方案，该方案适用于要求较高的情况，例如异构网络上的实时数据和小型交互组。
An option in some cases might be to use [SDP], as SDP defines one field to transport keys, the "k=" field. However, this field cannot be used for more general key management purposes, as it cannot be extended from the current definition.
在某些情况下，一个选项可能是使用[SDP]，因为SDP定义了一个字段来传输密钥，“k=”字段。但是，此字段不能用于更一般的密钥管理目的，因为它不能从当前定义扩展。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
(Data) Security Protocol: the security protocol used to protect the actual data traffic. Examples of security protocols are IPsec and SRTP.
（数据）安全协议：用于保护实际数据流量的安全协议。安全协议的例子有IPsec和SRTP。
Data Security Association (Data SA): information for the security protocol, including a TEK and a set of parameters/policies.
数据安全关联（Data SA）：安全协议的信息，包括TEK和一组参数/策略。
Crypto Session (CS): uni- or bi-directional data stream(s), protected by a single instance of a security protocol. For example, when SRTP is used, the Crypto Session will often contain two streams, an RTP stream and the corresponding RTCP, which are both protected by a single SRTP Cryptographic Context, i.e., they share key data and the bulk of security parameters in the SRTP Cryptographic Context (default behavior in [SRTP]). In the case of IPsec, a Crypto Session would represent an instantiation of an IPsec SA. A Crypto Session can be viewed as a Data SA (as defined in [GKMARCH]) and could therefore be mapped to other security protocols if necessary.
加密会话（CS）：由单一安全协议实例保护的单向或双向数据流。例如，当使用SRTP时，加密会话通常包含两个流，一个RTP流和相应的RTCP，它们都受单个SRTP加密上下文保护，即它们共享SRTP加密上下文中的密钥数据和大部分安全参数（在[SRTP]中的默认行为）。在IPsec的情况下，加密会话将表示IPsec SA的实例化。加密会话可以被视为数据SA（如[GKParch]中所定义），因此如果需要，可以映射到其他安全协议。
Crypto Session Bundle (CSB): collection of one or more Crypto Sessions, which can have common TGKs (see below) and security parameters.
加密会话包（CSB）：一个或多个加密会话的集合，可以具有通用TGK（见下文）和安全参数。
Crypto Session ID: unique identifier for the CS within a CSB.
加密会话ID：CSB中CS的唯一标识符。
Crypto Session Bundle ID (CSB ID): unique identifier for the CSB.
加密会话包ID（CSB ID）：CSB的唯一标识符。
TEK Generation Key (TGK): 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.
TEK生成密钥（TGK）：由两方或多方商定的与CSB相关的位字符串。从TGK，无需进一步通信即可生成流量加密密钥。
Traffic-Encrypting Key (TEK): 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.
响应者：密钥管理协议中的响应者。
Salting key: a random or pseudo-random (see [RAND, HAC]) string used to protect against some off-line pre-computation attacks on the underlying security protocol.
satting key：一个随机或伪随机（参见[RAND，HAC]）字符串，用于防止对底层安全协议的一些离线预计算攻击。
PRF(k,x): a keyed pseudo-random function (see [HAC]). E(k,m): encryption of m with the key k. PKx: the public key of x [] an optional piece of information {} denotes zero or more occurrences || concatenation | OR (selection operator) ^ exponentiation XOR exclusive or
PRF（k，x）：一个键控伪随机函数（见[HAC]）。E（k，m）：使用密钥k对m进行加密。PKx:x[]的公钥可选信息{}表示零次或多次出现| | |串联|或（选择运算符）^求幂异或异或
Bit and byte ordering: throughout the document bits and bytes are indexed, as usual, from left to right, with the leftmost bits/bytes being the most significant.
位和字节排序：在整个文档中，位和字节通常是从左到右索引的，最左边的位/字节是最重要的。
AES Advanced Encryption Standard CM Counter Mode (as defined in [SRTP]) CS Crypto Session CSB Crypto Session Bundle DH Diffie-Hellman DoS Denial of Service MAC Message Authentication Code MIKEY Multimedia Internet KEYing PK Public-Key PSK Pre-Shared key RTP Real-time Transport Protocol RTSP Real Time Streaming Protocol SDP Session Description Protocol SIP Session Initiation Protocol SRTP Secure RTP TEK Traffic-encrypting key TGK TEK Generation Key
AES高级加密标准CM计数器模式（定义见[SRTP]）CS Crypto Session CSB Crypto Session Bundle DH Diffie Hellman DoS拒绝服务MAC消息身份验证码MIKEY多媒体互联网密钥PK公钥PSK预共享密钥RTP实时传输协议RTSP实时流协议SDP会话描述协议SIP会话启动协议SRTP安全RTP TEK流量加密密钥TGK TEK生成密钥
Section 2 describes the basic scenarios and the design goals for which MIKEY is intended. It also gives a brief overview of the entire solution and its relation to the group key management architecture [GKMARCH].
第2节描述了MIKEY的基本场景和设计目标。它还简要概述了整个解决方案及其与集团密钥管理体系结构的关系[3]。
The basic key transport/exchange mechanisms are explained in detail in Section 3. The key derivation, and other general key management procedures are described in Section 4.
第3节详细解释了基本的密钥传输/交换机制。第4节描述了密钥派生和其他一般密钥管理过程。
Section 5 describes the expected behavior of the involved parties. This also includes message creation and parsing.
第5节描述了相关方的预期行为。这还包括消息创建和解析。
All definitions of the payloads in MIKEY are described in Section 6.
第6节描述了MIKEY中有效载荷的所有定义。
Section 7 deals with transport considerations, while Section 8 focuses on how MIKEY is used in group scenarios.
第7节讨论了交通方面的考虑，而第8节则侧重于如何在团体场景中使用MIKEY。
The Security Considerations section (Section 9), gives a deeper explanation of important security related topics.
安全注意事项部分（第9节）对重要的安全相关主题进行了更深入的解释。
MIKEY is mainly intended to be used for peer-to-peer, simple one-to-many, and small-size (interactive) groups. One of the main multimedia scenarios considered when designing MIKEY has been the conversational multimedia scenario, where users may interact and communicate in real-time. In these scenarios it can be expected that peers set up multimedia sessions between each other, where a multimedia session may consist of one or more secured multimedia streams (e.g., SRTP streams).
MIKEY主要用于点对点、简单的一对多和小型（交互式）群组。设计MIKEY时考虑的主要多媒体场景之一是对话式多媒体场景，用户可以实时交互和交流。在这些场景中，可以期望对等方在彼此之间建立多媒体会话，其中多媒体会话可以由一个或多个安全多媒体流（例如，SRTP流）组成。
peer-to-peer/ many-to-many many-to-many
simple one-to-many (distributed) (centralized)
++++ ++++ ++++ ++++ ++++
|. | |A | |B | |A |---- ----|B |
--| ++++ | |----------| | | | \ / | |
++++ / ++|. | ++++ ++++ ++++ (S) ++++
|A |---------| ++++ \ / |
| | \ ++|B | \ / |
++++ \-----| | \ ++++ / ++++
++++ \|C |/ |C |
| | | |
++++ ++++
peer-to-peer/ many-to-many many-to-many
simple one-to-many (distributed) (centralized)
++++ ++++ ++++ ++++ ++++
|. | |A | |B | |A |---- ----|B |
--| ++++ | |----------| | | | \ / | |
++++ / ++|. | ++++ ++++ ++++ (S) ++++
|A |---------| ++++ \ / |
| | \ ++|B | \ / |
++++ \-----| | \ ++++ / ++++
++++ \|C |/ |C |
| | | |
++++ ++++
Figure 2.1: Examples of the four scenarios: peer-to-peer, simple one-to-many, many-to-many without a centralized server (also denoted as small interactive group), and many-to-many with a centralized server.
图2.1：四种场景的示例：点对点、简单的一对多、多对多，无需集中式服务器（也称为小型交互组），以及多对多集中式服务器。
We identify in the following some typical scenarios which involve the multimedia applications we are dealing with (see also Figure 2.1).
我们在以下几个典型场景中确定了我们正在处理的多媒体应用程序（另请参见图2.1）。
a) peer-to-peer (unicast), e.g., a SIP-based [SIP] call between two parties, where it may be desirable that the security is either set up by mutual agreement or that each party sets up the security for its own outgoing streams.
a) 点对点（单播），例如，双方之间基于SIP的[SIP]呼叫，其中可能希望通过相互协议设置安全性，或者希望各方为其自己的传出流设置安全性。
b) simple one-to-many (multicast), e.g., real-time presentations, where the sender is in charge of setting up the security.
b) 简单的一对多（多播），例如，实时演示，其中发送者负责设置安全性。
c) many-to-many, without a centralized control unit, e.g., for small-size interactive groups where each party may set up the security for its own outgoing media. Two basic models may be used here. In the first model, the Initiator of the group acts as the
c) 多对多，没有集中控制单元，例如，对于小型交互组，其中各方可以为自己的传出媒体设置安全。这里可以使用两种基本模型。在第一个模型中，组的发起人充当
group server (and is the only one authorized to include new members). In the second model, authorization information to include new members can be delegated to other participants.
组服务器（并且是唯一授权包含新成员的服务器）。在第二个模型中，包含新成员的授权信息可以委托给其他参与者。
d) many-to-many, with a centralized control unit, e.g., for larger groups with some kind of Group Controller that sets up the security.
d) 多对多，带有集中控制单元，例如，对于具有某种设置安全性的组控制器的较大组。
The key management solutions may be different in the above scenarios. When designing MIKEY, the main focus has been on case a, b, and c. For scenario c, only the first model is covered by this document.
在上述场景中，密钥管理解决方案可能不同。在设计MIKEY时，主要关注案例a、b和c。对于场景c，本文档仅介绍第一个模型。
The key management protocol is designed to have the following characteristics:
密钥管理协议设计为具有以下特征：
* End-to-end security. Only the participants involved in the communication have access to the generated key(s).
* 端到端安全。只有参与通信的参与者才能访问生成的密钥。
* Simplicity.
* 简单
* Efficiency. Designed to have: - low bandwidth consumption, - low computational workload, - small code size, and - minimal number of roundtrips.
* 效率设计有：-低带宽消耗，-低计算工作量，-小代码大小，和-最小的往返次数。
* Tunneling. Possibility to "tunnel"/integrate MIKEY in session establishment protocols (e.g., SDP and RTSP).
* 隧道。“隧道”/将MIKEY集成到会话建立协议（例如SDP和RTSP）中的可能性。
* Independence from any specific security functionality of the underlying transport.
* 独立于基础传输的任何特定安全功能。
One objective of MIKEY is to produce a Data 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的一个目标是为安全协议生成数据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 which obtain distinct TEKs from MIKEY.
MIKEY支持同时为多个安全协议（或同一安全协议的多个实例）建立密钥和参数。Crypto Session Bundle（CSB）的概念用于表示一个或多个加密会话的集合，这些会话可以具有公共TGK和安全参数，但可以从MIKEY获得不同的TEK。
The procedure of setting up a CSB and creating a TEK (and Data SA), is done in accordance with Figure 2.2:
建立CSB和创建TEK（和数据SA）的程序按照图2.2进行：
1. A set of security parameters and TGK(s) are agreed upon for the Crypto Session Bundle (this is done by one of the three alternative key transport/exchange mechanisms, see Section 3).
1. 为加密会话捆绑包商定了一组安全参数和TGK（由三种备选密钥传输/交换机制之一完成，见第3节）。
2. The TGK(s) is used to derive (in a cryptographically secure way) a TEK for each Crypto Session.
2. TGK用于为每个加密会话派生（以加密安全的方式）TEK。
3. The TEK, together with the security protocol parameters, represent the Data SA, which is used as the input to the security protocol.
3. TEK与安全协议参数一起表示数据SA，该数据SA用作安全协议的输入。
+-----------------+
| CSB |
| Key transport | (see Section 3)
| /exchange |
+-----------------+
| :
| TGK :
v :
+----------+ :
CS ID ->| TEK | : Security protocol (see Section 4)
|derivation| : parameters (policies)
+----------+ :
TEK | :
v v
Data SA
|
v
+-------------------+
| Crypto Session |
|(Security Protocol)|
+-------------------+
+-----------------+
| CSB |
| Key transport | (see Section 3)
| /exchange |
+-----------------+
| :
| TGK :
v :
+----------+ :
CS ID ->| TEK | : Security protocol (see Section 4)
|derivation| : parameters (policies)
+----------+ :
TEK | :
v v
Data SA
|
v
+-------------------+
| Crypto Session |
|(Security Protocol)|
+-------------------+
Figure 2.2: Overview of MIKEY key management procedure.
图2.2:MIKEY密钥管理程序概述。
The security protocol can then either use the TEK directly, or, if supported, derive further session keys from the TEK (e.g., see SRTP [SRTP]). It is however up to the security protocol to define how the TEK is used.
然后，安全协议可以直接使用TEK，或者，如果支持，从TEK派生进一步的会话密钥（例如，参见SRTP[SRTP]）。然而，如何使用TEK取决于安全协议。
MIKEY can be used to update TEKs and the Crypto Sessions in a current Crypto Session Bundle (see Section 4.5). This is done by executing the transport/exchange phase once again to obtain a new TGK (and consequently derive new TEKs) or to update some other specific CS parameters.
MIKEY可用于更新当前加密会话包中的TEK和加密会话（见第4.5节）。这是通过再次执行传输/交换阶段来实现的，以获得新的TGK（从而派生新的TEK）或更新一些其他特定的CS参数。
The Group key management architecture (GKMARCH) [GKMARCH] describes a general architecture for group key management protocols. MIKEY is a part of this architecture, and can be used as a so-called Registration protocol. The main entities involved in the architecture are the group controller/key server (GCKS), the receiver(s), and the sender(s).
组密钥管理体系结构（GKARCH）[GKARCH]描述了组密钥管理协议的通用体系结构。MIKEY是该体系结构的一部分，可以用作所谓的注册协议。体系结构中涉及的主要实体是组控制器/密钥服务器（GCKS）、接收方和发送方。
In MIKEY, the sender could act as GCKS and push keys down to the receiver(s).
在MIKEY中，发送方可以充当GCK并将按键向下推到接收方。
Note that, for example, in a SIP-initiated call, the sender may also be a receiver. As MIKEY addresses small interactive groups, a member may dynamically change between being a sender and receiver (or being both simultaneously).
注意，例如，在SIP发起的呼叫中，发送方也可以是接收方。当MIKEY处理小型交互组时，一个成员可能会在发送者和接收者之间动态变化（或同时同时成为发送者和接收者）。
The following sub-sections define three different methods of transporting/establishing a TGK: with the use of a pre-shared key, public-key encryption, and Diffie-Hellman (DH) key exchange. In the following, we assume unicast communication for simplicity. In addition to the TGK, a random "nonce", denoted RAND, is also transported. In all three cases, the TGK and RAND values are then used to derive TEKs as described in Section 4.1.3. A timestamp is also sent to avoid replay attacks (see Section 5.4).
以下小节定义了传输/建立TGK的三种不同方法：使用预共享密钥、公钥加密和Diffie-Hellman（DH）密钥交换。在下文中，为了简单起见，我们假设单播通信。除TGK外，还传输随机“nonce”（表示为RAND）。在所有三种情况下，TGK和RAND值用于推导第4.1.3节所述的TEK。还发送时间戳以避免重播攻击（参见第5.4节）。
The pre-shared key method and the public-key method are both based on key transport mechanisms, where the actual TGK is pushed (securely) to the recipient(s). In the Diffie-Hellman method, the actual TGK is instead derived from the Diffie-Hellman values exchanged between the peers.
预共享密钥方法和公钥方法都基于密钥传输机制，其中实际的TGK被（安全地）推送到接收方。在Diffie-Hellman方法中，实际的TGK由对等方之间交换的Diffie-Hellman值导出。
The pre-shared case is, by far, the most efficient way to handle the key transport due to the use of symmetric cryptography only. This approach also has the advantage that only a small amount of data has to be exchanged. Of course, the problematic issue is scalability as it is not always feasible to share individual keys with a large group of peers. Therefore, this case mainly addresses scenarios such as server-to-client and also those cases where the public-key modes have already been used, thus allowing for the "cache" of a symmetric key (see below and Section 3.2).
由于仅使用对称加密，预共享情况是迄今为止处理密钥传输的最有效方式。这种方法还具有只需交换少量数据的优点。当然，问题在于可伸缩性，因为与大量对等方共享单个密钥并不总是可行的。因此，本案例主要解决服务器到客户端以及已经使用公钥模式的情况，从而允许对称密钥的“缓存”（见下文和第3.2节）。
Public-key cryptography can be used to create a scalable system. A disadvantage with this approach is that it is more resource consuming than the pre-shared key approach. Another disadvantage is that in most cases, a PKI (Public Key Infrastructure) is needed to handle the
公钥加密技术可用于创建可扩展的系统。这种方法的一个缺点是，它比预共享密钥方法消耗更多的资源。另一个缺点是，在大多数情况下，需要PKI（公钥基础设施）来处理
distribution of public keys. Of course, it is possible to use public keys as pre-shared keys (e.g., by using self-signed certificates). It should also be noted that, as mentioned above, this method may be used to establish a "cached" symmetric key that later can be used to establish subsequent TGKs by using the pre-shared key method (hence, the subsequent request can be executed more efficiently).
公钥的分发。当然，可以使用公钥作为预共享密钥（例如，通过使用自签名证书）。还应注意，如上所述，该方法可用于建立“缓存的”对称密钥，该对称密钥稍后可用于通过使用预共享密钥方法建立后续tgk（因此，后续请求可更有效地执行）。
In general, the Diffie-Hellman (DH) key agreement method has a higher resource consumption (both computationally and in bandwidth) than the previous ones, and needs certificates as in the public-key case. However, it has the advantage of providing perfect forward secrecy (PFS) and flexibility by allowing implementation in several different finite groups.
通常，Diffie-Hellman（DH）密钥协商方法比以前的方法具有更高的资源消耗（计算和带宽），并且与公钥情况一样需要证书。然而，它的优点是允许在几个不同的有限组中实现，从而提供了完美的前向保密性（PFS）和灵活性。
Note that by using the DH method, the two involved parties will generate a unique unpredictable random key. Therefore, it is not possible to use this DH method to establish a group TEK (as the different parties in the group would end up with different TEKs). It is not the intention of the DH method to work in this scenario, but to be a good alternative in the special peer-to-peer case.
请注意，通过使用DH方法，两个相关方将生成唯一的不可预测随机密钥。因此，不可能使用此DH方法建立集团TEK（因为集团中的不同方最终将拥有不同的TEK）。DH方法的目的不是在这种情况下工作，而是在特殊的点对点情况下成为一种很好的替代方案。
The following general notation is used:
使用以下通用符号：
HDR: The general MIKEY header, which includes MIKEY CSB related data (e.g., CSB ID) and information mapping to the specific security protocol used. See Section 6.1 for payload definition.
HDR：通用MIKEY头，包括MIKEY CSB相关数据（如CSB ID）和映射到所用特定安全协议的信息。有效载荷定义见第6.1节。
T: The timestamp, used mainly to prevent replay attacks. See Section 6.6 for payload definition and also Section 5.4 for other timestamp related information.
T：时间戳，主要用于防止重播攻击。有效载荷定义见第6.6节，其他时间戳相关信息见第5.4节。
IDx: The identity of entity x (IDi=Initiator, IDr=Responder). See Section 6.7 for payload definition.
IDx：实体x的标识（IDi=Initiator，IDr=Responder）。有效载荷定义见第6.7节。
RAND: Random/pseudo-random byte-string, which is always included in the first message from the Initiator. RAND is used as a freshness value for the key generation. It is not included in update messages of a CSB. See Section 6.11 for payload definition. For randomness recommendations for security, see [RAND].
RAND：随机/伪随机字节字符串，它始终包含在来自启动器的第一条消息中。RAND用作密钥生成的新鲜度值。它不包括在CSB的更新消息中。有效载荷定义见第6.11节。有关安全性的随机性建议，请参见[RAND]。
SP: The security policies for the data security protocol. See Section 6.10 for payload definition.
SP：数据安全协议的安全策略。有效载荷定义见第6.10节。
In this method, the pre-shared secret key, s, is used to derive key material for both the encryption (encr_key) and the integrity protection (auth_key) of the MIKEY messages, as described in Section 4.1.4. The encryption and authentication transforms are described in Section 4.2.
在该方法中，如第4.1.4节所述，预共享密钥s用于导出MIKEY消息的加密（加密密钥）和完整性保护（认证密钥）的密钥材料。第4.2节描述了加密和身份验证转换。
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 main objective of the Initiator's message (I_MESSAGE) is to transport one or more TGKs (carried into KEMAC) and a set of security parameters (SPs) to the Responder in a secure manner. As the verification message from the Responder is optional, the Initiator indicates in the HDR whether it requires a verification message or not from the Responder.
发起方消息（I_消息）的主要目的是以安全的方式将一个或多个TGK（携带到KEMAC）和一组安全参数（SP）传输到响应方。由于来自响应者的验证消息是可选的，因此启动器在HDR中指示是否需要来自响应者的验证消息。
KEMAC = E(encr_key, {TGK}) || MAC
KEMAC = E(encr_key, {TGK}) || MAC
The KEMAC payload contains a set of encrypted sub-payloads and a MAC. Each sub-payload includes a TGK randomly and independently chosen by the Initiator (and other possible related parameters, e.g., the key lifetime). The MAC is a Message Authentication Code covering the entire MIKEY message using the authentication key, auth_key. See Section 6.2 for payload definition and Section 5.2 for an exact definition of the MAC calculation.
KEMAC有效载荷包含一组加密子有效载荷和MAC。每个子有效载荷包括由发起方随机和独立选择的TGK（以及其他可能的相关参数，例如密钥寿命）。MAC是一种消息身份验证码，使用身份验证密钥auth_key覆盖整个MIKEY消息。有效载荷定义见第6.2节，MAC计算的准确定义见第5.2节。
The main objective of the verification message from the Responder is to obtain mutual authentication. The verification message, V, is a MAC computed over the Responder's entire message, the timestamp (the same as the one that was included in the Initiator's message), and the two parties identities, using the authentication key. See also Section 5.2 for the exact definition of the Verification MAC calculation and Section 6.9 for payload definition.
来自响应者的验证消息的主要目标是获得相互认证。验证消息V是使用身份验证密钥对响应者的整个消息、时间戳（与启动器消息中包含的时间戳相同）和双方身份进行计算的MAC。验证MAC计算的准确定义见第5.2节，有效载荷定义见第6.9节。
The ID fields SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID (otherwise it cannot look up the pre-shared key). For example, this could be the case if the ID is extracted from SIP.
应该包括ID字段，但如果可以预期对等方已经知道另一方的ID（否则它无法查找预共享密钥），则可以忽略这些字段。例如，如果从SIP中提取ID，则可能会出现这种情况。
It is MANDATORY to implement this method.
必须执行此方法。
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
As in the previous case, the main objective of the Initiator's message is to transport one or more TGKs and a set of security parameters to the Responder in a secure manner. This is done using an envelope approach where the TGKs are encrypted (and integrity protected) with keys derived from a randomly/pseudo-randomly chosen "envelope key". The envelope key is sent to the Responder encrypted with the public key of the Responder.
与前一种情况一样，发起方消息的主要目的是以安全的方式将一个或多个TGK和一组安全参数传输给响应方。这是使用信封方法完成的，其中TGK使用从随机/伪随机选择的“信封密钥”派生的密钥进行加密（和完整性保护）。信封密钥被发送到使用响应者公钥加密的响应者。
The PKE contains the encrypted envelope key: PKE = E(PKr, env_key). It is encrypted using the Responder's public key (PKr). If the Responder possesses several public keys, the Initiator can indicate the key used in the CHASH payload (see Section 6.8).
PKE包含加密的信封密钥：PKE=E（PKr，env_-key）。它使用响应者的公钥（PKr）进行加密。如果响应者拥有多个公钥，则发起者可以指示CHASH有效载荷中使用的密钥（参见第6.8节）。
The KEMAC contains a set of encrypted sub-payloads and a MAC:
KEMAC包含一组加密子有效载荷和MAC：
KEMAC = E(encr_key, IDi || {TGK}) || MAC
KEMAC = E(encr_key, IDi || {TGK}) || MAC
The first payload (IDi) in KEMAC is the identity of the Initiator (not a certificate, but generally the same ID as the one specified in the certificate). Each of the following payloads (TGK) includes a TGK randomly and independently chosen by the Initiator (and possible other related parameters, e.g., the key lifetime). The encrypted part is then followed by a MAC, which is calculated over the KEMAC payload. The encr_key and the auth_key are derived from the envelope key, env_key, as specified in Section 4.1.4. See also Section 6.2 for payload definition.
KEMAC中的第一个有效负载（IDi）是启动器的标识（不是证书，但通常与证书中指定的标识相同）。以下每个有效载荷（TGK）包括由发起方随机独立选择的TGK（以及可能的其他相关参数，例如密钥寿命）。加密部分之后是MAC，该MAC通过KEMAC有效载荷进行计算。根据第4.1.4节的规定，encr_密钥和auth_密钥源自信封密钥env_密钥。有效载荷定义另见第6.2节。
The SIGNi is a signature covering the entire MIKEY message, using the Initiator's signature key (see also Section 5.2 for the exact definition).
SIGNi是使用发起者的签名密钥覆盖整个MIKEY消息的签名（具体定义参见第5.2节）。
The main objective of the verification message from the Responder is to obtain mutual authentication. As the verification message V from the Responder is optional, the Initiator indicates in the HDR whether it requires a verification message or not from the Responder. V is calculated in the same way as in the pre-shared key mode (see also Section 5.2 for the exact definition). See Section 6.9 for payload definition.
来自响应者的验证消息的主要目标是获得相互认证。由于来自响应者的验证消息V是可选的，因此启动器在HDR中指示是否需要来自响应者的验证消息。V的计算方法与预共享密钥模式中的计算方法相同（具体定义参见第5.2节）。有效载荷定义见第6.9节。
Note that there will be one encrypted IDi and possibly also one unencrypted IDi. The encrypted one is used together with the MAC as a countermeasure for certain man-in-the-middle attacks, while the unencrypted one is always useful for the Responder to immediately identify the Initiator. The encrypted IDi MUST always be verified to be equal with the expected IDi.
请注意，将有一个加密的IDi，也可能有一个未加密的IDi。加密的一个与MAC一起用作某些中间人攻击的对策，而未加密的一个总是有助于响应者立即识别发起方。必须始终验证加密的IDi是否与预期的IDi相同。
It is possible to cache the envelope key, so that it can be used as a pre-shared key. It is not recommended for this key to be cached indefinitely (however it is up to the local policy to decide this). This function may be very convenient during the lifetime of a CSB, if a new crypto session needs to be added (or an expired one removed). Then, the pre-shared key can be used, instead of the public keys (see also Section 4.5). If the Initiator indicates that the envelope key should be cached, the key is at least to be cached during the lifetime of the entire CSB.
可以缓存信封密钥，以便将其用作预共享密钥。不建议无限期地缓存此密钥（但这取决于本地策略）。如果需要添加新的加密会话（或删除过期的会话），此函数在CSB的生命周期内可能非常方便。然后，可以使用预共享密钥，而不是公钥（另见第4.5节）。如果启动器指示应缓存信封密钥，则至少应在整个CSB的生存期内缓存该密钥。
The cleartext ID fields and certificate SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID, or can obtain the certificate in some other manner. For example, this could be the case if the ID is extracted from SIP.
应该包括明文ID字段和证书，但是当可以预期对等方已经知道另一方的ID，或者可以通过其他方式获得证书时，可以忽略这些字段和证书。例如，如果从SIP中提取ID，则可能会出现这种情况。
For certificate handling, authorization, and policies, see Section 4.3.
有关证书处理、授权和策略，请参阅第4.3节。
It is MANDATORY to implement this method.
必须执行此方法。
For a fixed, agreed upon, cyclic group, (G,*), we let g denote a generator for this group. Choices for the parameters are given in Section 4.2.7. The other transforms below are described in Section 4.2.
对于固定的、约定的循环群（G，*），我们让G表示该群的生成元。第4.2.7节给出了参数的选择。下面的其他转换在第4.2节中描述。
This method creates a DH-key, which is used as the TGK. This method cannot be used to create group keys; it can only be used to create single peer-to-peer keys. It is OPTIONAL to implement this method.
此方法创建一个DH密钥，用作TGK。此方法不能用于创建组密钥；它只能用于创建单个对等密钥。实现此方法是可选的。
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
The main objective of the Initiator's message is to, in a secure way, provide the Responder with its DH value (DHi) g^(xi), where xi MUST be randomly/pseudo-randomly and secretly chosen, and a set of security protocol parameters.
发起人的消息的主要目的是以安全的方式，向应答者提供其DH值（DHI）G^（席），其中席必须随机/伪随机地和秘密地选择，以及一组安全协议参数。
The SIGNi is a signature covering the Initiator's MIKEY message, I_MESSAGE, using the Initiator's signature key (see Section 5.2 for the exact definition).
SIGNi是使用发起人的签名密钥覆盖发起人的MIKEY消息、I_消息的签名（具体定义见第5.2节）。
The main objective of the Responder's message is to, in a secure way, provide the Initiator with the Responder's value (DHr) g^(xr), where xr MUST be randomly/pseudo-randomly and secretly chosen. The timestamp that is included in the answer is the same as the one included in the Initiator's message.
响应者消息的主要目的是以安全的方式向启动器提供响应者的值（DHr）g^（xr），其中xr必须随机/伪随机并秘密选择。应答中包含的时间戳与启动器消息中包含的时间戳相同。
The SIGNr is a signature covering the Responder's MIKEY message, R_MESSAGE, using the Responder's signature key (see Section 5.2 for the exact definition).
SIGNr是使用响应者的签名密钥覆盖响应者的MIKEY消息R_消息的签名（具体定义见第5.2节）。
The DH group parameters (e.g., the group G, the generator g) are chosen by the Initiator and signaled to the Responder. Both parties calculate the TGK, g^(xi*xr) from the exchanged DH-values.
DH组参数（例如，组g、生成器g）由发起方选择，并通过信号发送给响应方。双方根据交换的DH值计算TGK，g^（xi*xr）。
Note that this approach does not require that the Initiator has to possess any of the Responder's certificates before the setup. Instead, it is sufficient that the Responder includes its signing certificate in the response.
请注意，这种方法不要求启动器在设置之前必须拥有任何响应者的证书。相反，响应者在响应中包含其签名证书就足够了。
The ID fields and certificate SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID (or can obtain the certificate in some other manner). For example, this could be the case if the ID is extracted from SIP.
应该包括ID字段和证书，但是当可以预期对等方已经知道另一方的ID（或者可以以其他方式获得证书）时，可以忽略这些字段和证书。例如，如果从SIP中提取ID，则可能会出现这种情况。
For certificate handling, authorization, and policies, see Section 4.3.
有关证书处理、授权和策略，请参阅第4.3节。
MIKEY manages symmetric keys in two main ways. First, following key transport or key exchange of TGK(s) (and other parameters) as defined by any of the above three methods, MIKEY maintains a mapping between Data SA identifiers and Data SAs, where the identifiers used depend on the security protocol in question, see Section 4.4. Thus, when the security protocol requests a Data SA, given such a Data SA identifier, an up-to-date Data SA will be obtained. In particular,
MIKEY主要通过两种方式管理对称密钥。首先，按照上述三种方法中的任何一种，在TGK（和其他参数）的密钥传输或密钥交换之后，MIKEY维护数据SA标识符和数据SA之间的映射，其中所使用的标识符取决于所讨论的安全协议，见第4.4节。因此，当安全协议请求数据SA时，给定这样的数据SA标识符，将获得最新的数据SA。特别地，
correct keying material, TEK(s), might need to be derived. The derivation of TEK(s) (and other keying material) is done from a TGK and is described in Section 4.1.3.
可能需要导出正确的键控材料TEK。TEK（和其他键控材料）的推导由TGK完成，并在第4.1.3节中描述。
Second, for use within MIKEY itself, two key management procedures are needed:
其次，为了在MIKEY内部使用，需要两个关键的管理程序：
* in the pre-shared case, deriving encryption and authentication key material from a single pre-shared key, and
* 在预共享情况下，从单个预共享密钥派生加密和认证密钥材料，以及
* in the public key case, deriving similar key material from the transported envelope key.
* 在公钥情况下，从传输的信封密钥派生类似的密钥材料。
These two key derivation methods are specified in section 4.1.4.
第4.1.4节规定了这两种关键推导方法。
All the key derivation functionality mentioned above is based on a pseudo-random function, defined next.
上面提到的所有密钥派生功能都基于下面定义的伪随机函数。
In the following, we define a general method (pseudo-random function) to derive one or more keys from a "master" key. This method is used to derive:
在下文中，我们定义了一种通用方法（伪随机函数）来从“主”密钥导出一个或多个密钥。此方法用于推导：
* TEKs from a TGK and the RAND value,
* TGK的TEK和兰特价值，
* encryption, authentication, or salting key from a pre-shared/ envelope key and the RAND value.
* 预共享/信封密钥和RAND值的加密、身份验证或加密密钥。
We assume that the following parameters are in place:
我们假设以下参数已到位：
csb_id : Crypto Session Bundle ID (32-bits unsigned integer) cs_id : the Crypto Session ID (8-bits unsigned integer) RAND : (at least) 128-bit (pseudo-)random bit-string sent by the Initiator in the initial exchange.
csb_id:加密会话束id（32位无符号整数）cs_id:初始交换中启动器发送的加密会话id（8位无符号整数）RAND:（至少）128位（伪）随机位字符串。
The key derivation method has the following input parameters:
键派生方法具有以下输入参数：
inkey : the input key to the derivation function inkey_len : the length in bits of the input key label : a specific label, dependent on the type of the key to be derived, the RAND, and the session IDs outkey_len: desired length in bits of the output key.
inkey：派生函数的输入键inkey_len：输入键标签的位长度：特定标签，取决于要派生的键的类型、RAND和会话ID outkey_len：输出键的所需位长度。
The key derivation method has the following output:
键派生方法具有以下输出：
outkey: the output key of desired length.
输出键：所需长度的输出键。
Let HMAC be the SHA-1 based message authentication function, see [HMAC] [SHA-1]. Similarly to [TLS], we define:
假设HMAC是基于SHA-1的消息身份验证函数，请参见[HMAC][SHA-1]。与[TLS]类似，我们定义：
P (s, label, m) = HMAC (s, A_1 || label) || HMAC (s, A_2 || label) || ... HMAC (s, A_m || label) where
P（s，label，m）=HMAC（s，A|1 | label）| HMAC（s，A|2 | label）|。。。HMAC（s，A|m |标签），其中
A_0 = label, A_i = HMAC (s, A_(i-1)) s is a key (defined below) m is a positive integer (also defined below).
A_0=标签，A_i=HMAC（s，A_（i-1））s是键（定义如下）m是正整数（定义如下）。
Values of label depend on the case in which the PRF is invoked, and values are specified in the following for the default PRF. Thus, note that other PRFs later added to MIKEY MAY specify different input parameters.
label的值取决于调用PRF的情况，下面为默认PRF指定了值。因此，请注意，后来添加到MIKEY的其他PRF可能会指定不同的输入参数。
The following procedure describes a pseudo-random function, denoted PRF(inkey,label), based on the above P-function, applied to compute the output key, outkey:
以下过程描述了基于上述P函数的伪随机函数，表示为PRF（inkey，label），用于计算输出密钥outkey：
* let n = inkey_len / 256, rounded up to the nearest integer if not already an integer
* 设n=inkey_len/256，如果不是整数，则四舍五入到最接近的整数
* split the inkey into n blocks, inkey = s_1 || ... || s_n, where * all s_i, except possibly s_n, are 256 bits each
* 将inkey拆分为n个块，inkey=s|u 1 | | |……|s_n，其中*所有s_i，可能除了s_n之外，每个都是256位
* let m = outkey_len / 160, rounded up to the nearest integer if not already an integer
* 设m=outkey_len/160，如果不是整数，则四舍五入到最接近的整数
(The values "256" and "160" equals half the input block-size and full output hash size, respectively, of the SHA-1 hash as part of the P-function.)
（值“256”和“160”分别等于作为P函数一部分的SHA-1散列的输入块大小和完整输出散列大小的一半。）
Then, the output key, outkey, is obtained as the outkey_len most significant bits of
然后，获得输出密钥outkey作为输出密钥的最高有效位
PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ... XOR P(s_n, label, m).
PRF（inkey，label）=P（s_1，label，m）XOR P（s_2，label，m）XOR。。。XOR P（s_n，label，m）。
In the following, we describe how keying material is derived from a TGK, thus assuming that a mapping of the Data SA identifier to the correct TGK has already been done according to Section 4.4.
在下文中，我们将描述如何从TGK导出键控材料，从而假设已根据第4.4节将数据SA标识符映射到正确的TGK。
The key derivation method SHALL be executed using the above PRF with the following input parameters:
密钥推导方法应使用上述PRF和以下输入参数执行：
inkey : TGK inkey_len : bit length of TGK label : constant || cs_id || csb_id || RAND outkey_len : bit length of the output key.
inkey:TGK inkey|len:TGK标签的位长度：常量| | cs|u id | | csb|u id | | RAND outkey|len:输出键的位长度。
The constant part of label depends on the type of key that is to be generated. The constant 0x2AD01C64 is used to generate a TEK from TGK. If the security protocol itself does not support key derivation for authentication and encryption from the TEK, separate authentication and encryption keys MAY be created directly for the security protocol by replacing 0x2AD01C64 with 0x1B5C7973 and 0x15798CEF respectively, and outkey_len by the desired key-length(s) in each case.
标签的常量部分取决于要生成的键的类型。常数0x2AD01C64用于从TGK生成TEK。如果安全协议本身不支持从TEK进行身份验证和加密的密钥派生，则可以通过分别用0x1B5C7973和0x15798CEF替换0x2AD01C64，以及在每种情况下用所需密钥长度替换outkey_len，直接为安全协议创建单独的身份验证和加密密钥。
A salt key can be derived from the TGK as well, by using the constant 0x39A2C14B. Note that the Key data sub-payload (Section 6.13) can carry a salt. The security protocol in need of the salt key SHALL use the salt key carried in the Key data sub-payload (in the pre-shared and public-key case), when present. If that is not sent, then it is possible to derive the salt key via the key derivation function, as described above.
也可以使用常量0x39A2C14B从TGK派生salt密钥。请注意，关键数据子有效载荷（第6.13节）可携带盐。需要salt密钥的安全协议应使用密钥数据子有效载荷（在预共享和公钥情况下）中携带的salt密钥（如果存在）。如果未发送，则可以通过密钥派生函数派生salt密钥，如上所述。
The table below summarizes the constant values, used to generate keys from a TGK.
下表总结了用于从TGK生成键的常量值。
constant | derived key from the TGK
--------------------------------------
0x2AD01C64 | TEK
0x1B5C7973 | authentication key
0x15798CEF | encryption key
0x39A2C14B | salting key
constant | derived key from the TGK
--------------------------------------
0x2AD01C64 | TEK
0x1B5C7973 | authentication key
0x15798CEF | encryption key
0x39A2C14B | salting key
Table 4.1.3: Constant values for the derivation of keys from TGK.
表4.1.3：从TGK导出键的常量值。
Note that these 32-bit constant values (listed in the table above) are taken from the decimal digits of e (i.e., 2.7182...), where each constant consists of nine decimal digits (e.g., the first nine decimal digits 718281828 = 0x2AD01C64). The strings of nine
请注意，这些32位常量值（上表中列出）取自e的十进制数字（即2.7182…），其中每个常量由九个十进制数字组成（例如，前九个十进制数字718281828=0x2AD01C64）。九弦
decimal digits are not chosen at random, but as consecutive "chunks" from the decimal digits of e.
十进制数字不是随机选择的，而是从e的十进制数字中连续选择的“块”。
4.1.4. Generating keys for MIKEY messages from an envelope/pre-shared key
4.1.4. 从信封/预共享密钥生成MIKEY消息的密钥
This derivation is to form the symmetric encryption key (and salting key) for the encryption of the TGK in the pre-shared key and public key methods. This is also used to derive the symmetric key used for the message authentication code in these messages, and the corresponding verification messages. Hence, this derivation is needed in order to get different keys for the encryption and the MAC (and in the case of the pre-shared key, it will result in fresh key material for each new CSB). The parameters for the default PRF are here:
这个推导是为了在预共享密钥和公钥方法中形成用于TGK加密的对称加密密钥（和satting密钥）。这还用于派生这些消息中用于消息身份验证代码的对称密钥以及相应的验证消息。因此，为了获得加密和MAC的不同密钥，需要进行这种推导（在预共享密钥的情况下，它将为每个新的CSB生成新的密钥材料）。默认PRF的参数如下：
inkey : the envelope key or the pre-shared key inkey_len : the bit length of inkey label : constant || 0xFF || csb_id || RAND outkey_len : desired bit length of the output key.
inkey：信封密钥或预共享密钥inkey|len：inkey标签的位长度：常量| | 0xFF | | csb|U id | RAND outkey|len：输出密钥的所需位长度。
The constant part of label depends on the type of key that is to be generated from an envelope/pre-shared key, as summarized below.
标签的常量部分取决于要从信封/预共享密钥生成的密钥类型，如下所述。
constant | derived key
--------------------------------------
0x150533E1 | encryption key
0x2D22AC75 | authentication key
0x29B88916 | salt key
constant | derived key
--------------------------------------
0x150533E1 | encryption key
0x2D22AC75 | authentication key
0x29B88916 | salt key
Table 4.1.4: Constant values for the derivation of keys from an envelope/pre-shared key.
表4.1.4：从信封/预共享密钥派生密钥的常量值。
This section identifies default transforms for MIKEY. It is mandatory to implement and support the following transforms in the respective case. New transforms can be added in the future (see Section 4.2.9 for further guidelines).
本节确定MIKEY的默认变换。在各自的情况下，必须实现并支持以下转换。将来可以添加新的转换（有关更多指南，请参见第4.2.9节）。
In MIKEY, it is MANDATORY to implement SHA-1 as the default hash function.
在MIKEY中，必须实现SHA-1作为默认哈希函数。
A cryptographically secure random or pseudo-random number generator MUST be used for the generation of the keying material and nonces, e.g., [BMGL]. However, which one to use is implementation specific (as the choice will not affect the interoperability).
加密安全的随机数或伪随机数生成器必须用于生成密钥材料和nonce，例如[BMGL]。但是，使用哪一个是特定于实现的（因为选择不会影响互操作性）。
For the key derivations, it is MANDATORY to implement the PRF specified in Section 4.1. Other PRFs MAY be added by writing standard-track RFCs specifying the PRF constructions and their exact use within MIKEY.
对于关键衍生产品，必须实施第4.1节中规定的PRF。可以通过编写标准轨道RFC来添加其他PRF，指定PRF结构及其在MIKEY中的确切用途。
The default and mandatory-to-implement key transport encryption is AES in counter mode, as defined in [SRTP], using a 128-bit key as derived in Section 4.1.4, SRTP_PREFIX_LENGTH set to zero, and using the initialization vector
按照[SRTP]中的定义，默认且强制实施密钥传输加密的是计数器模式下的AES，使用第4.1.4节中导出的128位密钥，SRTP_前缀_长度设置为零，并使用初始化向量
IV = (S XOR (0x0000 || CSB ID || T)) || 0x0000,
IV = (S XOR (0x0000 || CSB ID || T)) || 0x0000,
where S is a 112-bit salting key, also derived as in Section 4.1.4, and where T is the 64-bit timestamp sent by the Initiator.
其中S是112位的盐析键，也如第4.1.4节中所述，其中T是启动器发送的64位时间戳。
Note: this restricts the maximum size that can be encrypted to 2^23 bits, which is still enough for all practical purposes [SRTP].
注意：这将可加密的最大大小限制为2^23位，这对于所有实际用途仍然足够[SRTP]。
The NULL encryption algorithm (i.e., no encryption) can be used (but implementation is OPTIONAL). Note that this MUST NOT be used unless the underlying protocols can guarantee security. The main reason for including this is for specific SIP scenarios, where SDP is protected end-to-end. For this scenario, MIKEY MAY be used with the pre-shared key method, the NULL encryption, and NULL authentication algorithm (see Section 4.2.4) while relying on the security of SIP. Use this option with caution!
可以使用空加密算法（即不加密）（但实现是可选的）。请注意，除非基础协议能够保证安全性，否则不得使用此选项。包含此内容的主要原因是针对特定的SIP场景，其中SDP受到端到端的保护。在这种情况下，MIKEY可以与预共享密钥方法、空加密和空身份验证算法一起使用（参见第4.2.4节），同时依赖SIP的安全性。小心使用此选项！
The AES key wrap function [AESKW] is included as an OPTIONAL implementation method. If the key wrap function is used in the public key method, the NULL MAC is RECOMMENDED to be used, as the key wrap itself will provide integrity of the encrypted content (note though that the NULL MAC SHOULD NOT be used in the pre-shared key case, as the MAC in that case covers the entire message). The 128- bit key and a 64-bit salt, S, are derived in accordance to Section 4.1.4 and the key wrap IV is then set to S.
AES密钥封装函数[AESKW]作为可选实现方法包括在内。如果在公钥方法中使用密钥换行功能，建议使用空MAC，因为密钥换行本身将提供加密内容的完整性（注意，在预共享密钥的情况下不应使用空MAC，因为这种情况下的MAC覆盖整个消息）。根据第4.1.4节导出128位密钥和64位salt S，然后将密钥换行IV设置为S。
MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1 as the MANDATORY implementation method, see [HMAC]. Authentication keys are derived according to Section 4.1.4. Note that the authentication key size SHOULD be equal to the size of the hash function's output (e.g., for HMAC-SHA-1, a 160-bit authentication key is used) [HMAC].
MIKEY使用HMAC生成的160位身份验证标记，并将SHA-1作为强制实现方法，请参见[HMAC]。认证密钥根据第4.1.4节导出。注意，认证密钥大小应等于散列函数输出的大小（例如，对于HMAC-SHA-1，使用160位认证密钥）[HMAC]。
The NULL authentication algorithm (i.e., no MAC) can be used together with the NULL encryption algorithm (but implementation is OPTIONAL). Note that this MUST NOT be used unless the underlying protocols can guarantee security. The main reason for including this is for specific SIP scenarios, where SDP is protected end-to-end. For this scenario, MIKEY MAY be used with the pre-shared key method and the NULL encryption and authentication algorithm, while relying on the security of SIP. Use this option with caution!
空身份验证算法（即无MAC）可以与空加密算法一起使用（但实现是可选的）。请注意，除非基础协议能够保证安全性，否则不得使用此选项。包含此内容的主要原因是针对特定的SIP场景，其中SDP受到端到端的保护。在这种情况下，MIKEY可以与预共享密钥方法以及空加密和身份验证算法一起使用，同时依赖于SIP的安全性。小心使用此选项！
The public key encryption algorithm applied is defined by, and dependent on the certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it is RECOMMENDED to also support RSA OAEP [PSS].
应用的公钥加密算法由定义，并取决于所使用的证书。必须支持RSA PKCS#1，v1.5，建议还支持RSA OAEP[PSS]。
The signature algorithm applied is defined by, and dependent on the certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it is RECOMMENDED to also support RSA PSS [PSS].
应用的签名算法由定义，并取决于所使用的证书。必须支持RSA PKCS#1，v1.5，建议还支持RSA PSS[PSS]。
The Diffie-Hellman key exchange, when supported, uses OAKLEY 5 [OAKLEY] as a mandatory implementation. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are OPTIONAL implementations).
Diffie-Hellman密钥交换在得到支持时，使用OAKLEY 5[OAKLEY]作为强制实现。OAKLEY 1和OAKLEY 2都可以使用（但它们是可选的实现）。
See Section 4.2.9 for the guidelines on specifying a new DH Group to be used within MIKEY.
有关指定在MIKEY内部使用的新DH组的指南，请参见第4.2.9节。
The timestamp is as defined in NTP [NTP], i.e., a 64-bit number in seconds relative to 0h on 1 January 1900. An implementation MUST be aware of (and take into account) the fact that the counter will overflow approximately every 136th year. It is RECOMMENDED that the time always be specified in UTC.
时间戳如NTP[NTP]中所定义，即相对于1900年1月1日的0h，以秒为单位的64位数字。实现必须了解（并考虑）计数器大约每136年溢出一次的事实。建议始终以UTC为单位指定时间。
There are two different parameter sets that can be added to MIKEY. The first is a set of MIKEY transforms (needed for the exchange itself), and the second is the Data SAs.
有两个不同的参数集可以添加到MIKEY。第一个是一组MIKEY变换（交换本身需要），第二个是数据SAs。
New transforms and parameters (including new policies) SHALL be added by registering with IANA (according to [RFC2434], see also Section 10) a new number for the concerned payload, and also if necessary, documenting how the new transform/parameter is used. Sometimes it might be enough to point to an already specified document for the usage, e.g., when adding a new, already standardized, hash function.
新的转换和参数（包括新策略）应通过向IANA注册（根据[RFC2434]，另见第10节）相关有效载荷的新编号来添加，如有必要，还应记录如何使用新的转换/参数。有时，指向已经指定的文档就足够了，例如，在添加新的、已经标准化的哈希函数时。
In the case of adding a new DH group, the group MUST be specified in a companion standards-track RFC (it is RECOMMENDED that the specified group use the same format as used in [OAKLEY]). A number can then be assigned by IANA for such a group to be used in MIKEY.
在添加新DH组的情况下，必须在配套标准轨道RFC中指定该组（建议指定组使用与[OAKLEY]中使用的格式相同的格式）。然后IANA可以为MIKEY中使用的此类组分配一个编号。
When adding support for a new data security protocol, the following MUST be specified:
添加对新数据安全协议的支持时，必须指定以下内容：
* A map sub-payload (see Section 6.1). This is used to be able to map a crypto session to the right instance of the data security protocol and possibly also to provide individual parameters for each data security protocol.
* map子有效载荷（见第6.1节）。这用于将加密会话映射到数据安全协议的正确实例，也可能用于为每个数据安全协议提供单独的参数。
* A policy payload, i.e., specification of parameters and supported values.
* 策略有效负载，即参数和支持值的规范。
* General guidelines of usage.
* 一般使用指南。
Certificate handling may involve a number of additional tasks not shown here, and effect the inclusion of certain parts of the message (c.f. [X.509]). However, the following observations can be made:
证书处理可能涉及许多此处未显示的附加任务，并影响包含消息的某些部分（c.f.[X.509]）。但是，可以进行以下观察：
* The Initiator typically has to find the certificate of the Responder in order to send the first message. If the Initiator does not already have the Responder's certificate, this may involve one or more roundtrips to a central directory agent.
* 发起方通常必须找到响应方的证书才能发送第一条消息。如果发起者还没有响应者的证书，这可能涉及到一个或多个到中央目录代理的往返。
* It will be possible for the Initiator to omit its own certificate and rely on the Responder getting this certificate using other means. However, we only recommend doing this when it is reasonable to expect that the Responder has cached the certificate
* 发起者可能会忽略自己的证书，而依赖于响应者使用其他方式获取此证书。但是，我们仅建议在合理预期响应者缓存了证书时执行此操作
from a previous connection. Otherwise accessing the certificate would mean additional roundtrips for the Responder as well.
从以前的连接。否则，访问证书也将意味着响应者的额外往返。
* Verification of the certificates using Certificate Revocation Lists (CRLs) [X.509] or protocols such as OCSP [OCSP] may be necessary. All parties in a MIKEY exchange should have a local policy which dictates whether such checks are made, how they are made, and how often they are made. Note that performing the checks may imply additional messaging.
* 可能需要使用证书撤销列表（CRL）[X.509]或协议（如OCSP[OCSP]）验证证书。MIKEY交易所的所有各方都应制定当地政策，规定是否进行此类检查、检查方式以及检查频率。请注意，执行检查可能意味着额外的消息传递。
In general, there are two different models for making authorization decisions for both the Initiator and the Responder, in the context of the applications targeted by MIKEY:
一般来说，在MIKEY针对的应用程序的上下文中，有两种不同的模型用于为发起方和响应方做出授权决策：
* Specific peer-to-peer configuration. The user has configured the application to trust a specific peer.
* 特定的对等配置。用户已将应用程序配置为信任特定对等方。
When pre-shared secrets are used, this is pretty much the only available scheme. Typically, the configuration/entering of the pre-shared secret is taken to mean that authorization is implied.
当使用预共享机密时，这几乎是唯一可用的方案。通常，预共享秘密的配置/输入被认为意味着隐含授权。
In some cases, one could also use this with public keys, e.g., if two peers exchange keys offline and configure them to be used for the purpose of running MIKEY.
在某些情况下，还可以将其用于公钥，例如，如果两个对等方脱机交换密钥，并将其配置为用于运行MIKEY。
* Trusted root. The user accepts all peers that prove to have a certificate issued by a specific CA. The granularity of authorization decisions is not very precise in this method.
* 受信任的根。用户接受所有证明拥有特定CA颁发的证书的对等方。在这种方法中，授权决策的粒度不是很精确。
In order to make this method possible, all participants in the MIKEY protocol need to configure one or more trusted roots. The participants also need to be capable of performing certificate chain validation, and possibly transfer more than a single certificate in the MIKEY messages (see also Section 6.7).
为了使此方法成为可能，MIKEY协议中的所有参与者都需要配置一个或多个受信任根。参与者还需要能够执行证书链验证，并可能在MIKEY消息中传输多个证书（另请参见第6.7节）。
In practice, a combination of both mentioned methods might be advantageous. Also, the possibility for a user to explicitly exclude a specific peer (or sub-tree) in a trust chain might be needed.
实际上，上述两种方法的结合可能是有利的。此外，用户可能需要明确排除信任链中的特定对等方（或子树）。
These authorization policies address the MIKEY scenarios a-c of Section 2.1, where the Initiator acts as the group owner and is also the only one that can invite others. This implies that for each Responder, the distributed keys MUST NOT be re-distributed to other parties.
这些授权策略解决了第2.1节的MIKEY场景a-c，其中发起人作为组所有者，也是唯一可以邀请其他人的人。这意味着对于每个响应者，分发的密钥不得重新分发给其他方。
In a many-to-many situation, where the group control functions are distributed (and/or where it is possible to delegate the group control function to others), a means of distributing authorization information about who may be added to the group MUST exist. However, it is out of scope of this document to specify how this should be done.
在多对多的情况下，如果组控制功能是分布式的（和/或可以将组控制功能委托给其他人），则必须存在一种分发授权信息的方法，该授权信息涉及哪些人可以添加到组中。然而，指定如何进行这项工作超出了本文件的范围。
For any broader communication situation, an external authorization infrastructure may be used (following the assumptions of [GKMARCH]).
对于任何更广泛的通信情况，可使用外部授权基础设施（根据[GKMARCH]的假设）。
Included in the message exchange, policies (i.e., security parameters) for the Data security protocol are transmitted. The policies are defined in a separate payload and are specific to the security protocol (see also Section 6.10). Together with the keys, the validity period of these can also be specified. For example, this can be done with an SPI (or SRTP MKI) or with an Interval (e.g., a sequence number interval for SRTP), depending on the security protocol.
包括在消息交换中，传输数据安全协议的策略（即安全参数）。这些策略在单独的有效负载中定义，并且特定于安全协议（另请参见第6.10节）。与钥匙一起，还可以指定这些钥匙的有效期。例如，这可以通过SPI（或SRTP MKI）或间隔（例如，SRTP的序列号间隔）来完成，具体取决于安全协议。
New parameters can be added to a policy by documenting how they should be interpreted by MIKEY and by also registering new values in the appropriate name space in IANA. If a completely new policy is needed, see Section 4.2.9 for guidelines.
通过记录MIKEY应如何解释新参数，并在IANA的适当名称空间中注册新值，可以将新参数添加到策略中。如果需要全新的政策，请参见第4.2.9节的指南。
The retrieval of a Data SA will depend on the security protocol, as different security protocols will have different characteristics. When adding support for a security protocol to MIKEY, some interface of how the security protocol retrieves the Data SA from MIKEY MUST be specified (together with policies that can be negotiated).
数据SA的检索将取决于安全协议，因为不同的安全协议将具有不同的特征。向MIKEY添加对安全协议的支持时，必须指定安全协议如何从MIKEY检索数据SA的一些接口（以及可以协商的策略）。
For SRTP, the SSRC (see [SRTP]) is one of the parameters used to retrieve the Data SA (while the MKI may be used to indicate the TGK/TEK used for the Data SA). However, the SSRC is not sufficient. For the retrieval of the Data SA from MIKEY, it is RECOMMENDED that the MIKEY implementation support a lookup using destination network address and port together with SSRC. Note that MIKEY does not send network addresses or ports. One reason for this is that they may not be known in advance. Also, if a NAT exists in-between, problems may arise. When SIP or RTSP is used, the local view of the destination address and port can be obtained from either SIP or RTSP. MIKEY can then use these addresses as the index for the Data SA lookup.
对于SRTP，SSRC（参见[SRTP]）是用于检索数据SA的参数之一（而MKI可用于指示用于数据SA的TGK/TEK）。然而，SSRC是不够的。为了从MIKEY检索数据SA，建议MIKEY实现支持使用目标网络地址和端口以及SSRC进行查找。请注意，MIKEY不发送网络地址或端口。其中一个原因是他们可能事先不知道。此外，如果NAT介于两者之间，则可能会出现问题。使用SIP或RTSP时，可以从SIP或RTSP获取目标地址和端口的本地视图。然后，MIKEY可以使用这些地址作为数据SA查找的索引。
MIKEY provides a means of updating the CSB (e.g., transporting a new TGK/TEK or adding a new Crypto Session to the CSB). The updating of the CSB is done by executing MIKEY again, for example, before a TEK expires, or when a new Crypto Session is added to the CSB. Note that MIKEY does not provide re-keying in the GKMARCH sense, only updating of the keys by normal unicast messages.
MIKEY提供了更新CSB的方法（例如，传输新的TGK/TEK或向CSB添加新的加密会话）。CSB的更新是通过再次执行MIKEY来完成的，例如，在TEK过期之前，或者在CSB中添加新的加密会话时。请注意，MIKEY不提供GKMARCH意义上的重新键控，仅通过正常单播消息更新键。
When MIKEY is executed again to update the CSB, it is not necessary to include certificates and other information that was provided in the first exchange, for example, all payloads that are static or optionally included may be left out (see Figure 4.1).
当再次执行MIKEY以更新CSB时，无需包含在第一次交换中提供的证书和其他信息，例如，可以忽略所有静态或可选包含的有效载荷（见图4.1）。
The new message exchange MUST use the same CSB ID as the initial exchange, but MUST use a new timestamp. A new RAND MUST NOT be included in the message exchange (the RAND will only have effect in the Initial exchange). If desired, new Crypto Sessions are added in the update message. Note that a MIKEY update message does not need to contain new keying material (e.g., new TGK). In this case, the crypto session continues to use the previously established keying material, while updating the new information.
新消息交换必须使用与初始交换相同的CSB ID，但必须使用新的时间戳。消息交换中不得包含新的RAND（RAND仅在初始交换中有效）。如果需要，将在更新消息中添加新的加密会话。请注意，MIKEY更新消息不需要包含新的键控材料（例如，新的TGK）。在这种情况下，加密会话继续使用先前建立的密钥材料，同时更新新信息。
As explained in Section 3.2, the envelope key can be "cached" as a pre-shared key (this is indicated by the Initiator in the first message sent). If so, the update message is a pre-shared key message with the cached envelope key as the pre-shared key; it MUST NOT be a public key message. If the public key message is used, but the envelope key is not cached, the Initiator MUST provide a new encrypted envelope key that can be used in the verification message. However, the Initiator does not need to provide any other keys.
如第3.2节所述，信封密钥可以作为预共享密钥“缓存”（由发送的第一条消息中的启动器指示）。如果是，则更新消息是预共享密钥消息，其中缓存的信封密钥作为预共享密钥；它不能是公钥消息。如果使用了公钥消息，但未缓存信封密钥，则启动器必须提供可在验证消息中使用的新加密信封密钥。但是，启动器不需要提供任何其他密钥。
Figure 4.1 visualizes the update messages that can be sent, including the optional parts. The main difference from the original message is that it is optional to include TGKs (or DH values in the DH method). Also see Section 3 for more details on the specific methods.
图4.1显示了可以发送的更新消息，包括可选部分。与原始消息的主要区别在于，包含TGK（或DH方法中的DH值）是可选的。有关具体方法的更多详细信息，请参见第3节。
By definition, a CSB can contain several CSs. A problem that then might occur is to synchronize the TGK re-keying if an SPI (or similar functionality, e.g., MKI in [SRTP]) is not used. It is therefore RECOMMENDED that an SPI or MKI be used, if more than one CS is present.
根据定义，CSB可以包含多个CSs。如果未使用SPI（或类似功能，例如[SRTP]中的MKI），则可能出现的问题是同步TGK重设密钥。因此，如果存在多个CS，建议使用SPI或MKI。
Initiator Responder
发起者响应者
Pre-shared key method:
预共享密钥方法：
I_MESSAGE =
HDR, T, [IDi], [IDr], {SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_MESSAGE =
HDR, T, [IDi], [IDr], {SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
Public key method:
公钥方法：
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr], {SP},
[KEMAC], [CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr], {SP},
[KEMAC], [CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
DH method:
DH方法：
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr], {SP},
[DHi], SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi,
[DHr, DHi], SIGNr
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr], {SP},
[DHi], SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi,
[DHr, DHi], SIGNr
Figure 4.1: Update messages.
图4.1：更新消息。
Note that for the DH method, if the Initiator includes the DHi payload, then the Responder MUST include DHr and DHi. If the Initiator does not include DHi, the Responder MUST NOT include DHr or DHi.
请注意，对于DH方法，如果启动器包括DHi有效负载，则响应程序必须包括DHr和DHi。如果发起者不包括DHi，则响应者不得包括DHr或DHi。
Each message that is sent by the Initiator or the Responder is built by a set of payloads. This section describes how messages are created and also when they can be used.
发起者或响应者发送的每条消息都由一组有效负载构建。本节介绍如何创建消息以及何时可以使用消息。
The Initiator indicates the security policy to be used (i.e., in terms of security protocol algorithms). If the Responder does not support it (for some reason), the Responder can together with an error message (indicating that it does not support the parameters), send back its own capabilities (negotiation) to let the Initiator
启动器指示要使用的安全策略（即，在安全协议算法方面）。如果响应程序不支持它（出于某种原因），响应程序可以连同一条错误消息（指示它不支持参数）一起发回它自己的功能（协商），让启动器
choose a common set of parameters. This is done by including one or more security policy payloads in the error message sent in response (see Section 5.1.2.). Multiple attributes can be provided in sequence in the response. This is done to reduce the number of roundtrips as much as possible (i.e., in most cases, where the policy is accepted the first time, one roundtrip is enough). If the Responder does not accept the offer, the Initiator must go out with a new MIKEY message.
选择一组常用参数。这是通过在响应中发送的错误消息中包含一个或多个安全策略有效载荷来实现的（参见第5.1.2节）。响应中可以按顺序提供多个属性。这样做是为了尽可能减少往返次数（即，在大多数情况下，如果第一次接受该政策，一次往返就足够了）。如果响应者不接受提议，发起者必须发出新的MIKEY消息。
If the Responder is not willing/capable of providing security or the parties simply cannot agree, it is up to the parties' policies how to behave, for example, accepting or rejecting an insecure communication.
如果响应者不愿意/无法提供安全性，或者双方无法达成一致，则由双方的政策决定如何行为，例如，接受或拒绝不安全的通信。
Note that it is not the intention of this protocol to have a broad variety of options, as it is assumed that a denied offer should rarely occur.
请注意，本议定书的目的不是要有多种选择，因为假定拒绝要约很少发生。
In the one-to-many and many-to-many scenarios using multicast communication, one issue is of course that there MUST be a common security policy for all the receivers. This limits the possibility of negotiation.
在使用多播通信的一对多和多对多场景中，一个问题当然是必须为所有接收器制定一个通用的安全策略。这限制了谈判的可能性。
Due to the key management protocol, all errors SHOULD be reported to the peer(s) by an error message. The Initiator SHOULD therefore always be prepared to receive such a message from the Responder.
根据密钥管理协议，所有错误都应通过错误消息报告给对等方。因此，发起者应始终准备好接收来自响应者的此类消息。
If the Responder does not support the set of parameters suggested by the Initiator, the error message SHOULD include the supported parameters (see also Section 5.1.1).
如果响应程序不支持启动器建议的参数集，则错误消息应包括支持的参数（另请参见第5.1.1节）。
The error message is formed as:
错误消息的格式为：
HDR, T, {ERR}, {SP}, [V|SIGNr]
HDR, T, {ERR}, {SP}, [V|SIGNr]
Note that if failure is due to the inability to authenticate the peer, the error message is OPTIONAL, and does not need to be authenticated. It is up to local policy to determine how to treat this kind of message. However, if in response to a failed authentication a signed error message is returned, this can be used for DoS purposes (against the Responder). Similarly, an unauthenticated error message could be sent to the Initiator in order to fool the Initiator into tearing down the CSB. It is highly RECOMMENDED that the local policy take this into consideration. Therefore, in case of authentication failure, one recommendation would be not to authenticate such an error message, and when
请注意，如果失败是由于无法对对等方进行身份验证，则错误消息是可选的，不需要进行身份验证。如何处理此类信息取决于当地政策。但是，如果在响应失败的身份验证时返回一条已签名的错误消息，则此消息可用于DoS目的（针对响应者）。类似地，可以向启动器发送未经验证的错误消息，以欺骗启动器拆除CSB。强烈建议当地政策考虑到这一点。因此，在身份验证失败的情况下，一个建议是不要对此类错误消息进行身份验证
receiving an unauthenticated error message view it only as a recommendation of what may have gone wrong.
收到未经验证的错误消息时，仅将其视为可能出现错误的建议。
To create a MIKEY message, a Common Header payload is first created. This payload is then followed, depending on the message type, by a set of information payloads (e.g., DH-value payload, Signature payload, Security Policy payload). The defined payloads and the exact encoding of each payload are described in Section 6.
要创建MIKEY消息，首先创建一个公共头有效负载。然后，根据消息类型，该有效载荷之后是一组信息有效载荷（例如，DH值有效载荷、签名有效载荷、安全策略有效载荷）。第6节描述了定义的有效载荷和每个有效载荷的精确编码。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +
~ Common Header... ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload 1 ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload x ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MAC/Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +
~ Common Header... ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload 1 ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload x ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MAC/Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.1. MIKEY payload message example. Note that the payloads are byte aligned and not 32-bit aligned.
图5.1。MIKEY有效负载消息示例。请注意，有效负载是字节对齐的，而不是32位对齐的。
The process of generating a MIKEY message consists of the following steps:
生成MIKEY消息的过程包括以下步骤：
* Create an initial MIKEY message starting with the Common Header payload.
* 创建一个初始MIKEY消息，从公共头有效负载开始。
* Concatenate necessary payloads of the MIKEY message (see the exchange definitions for payloads that may be included, and the recommended order).
* 连接MIKEY消息的必要有效负载（请参阅exchange定义，了解可能包含的有效负载以及建议的顺序）。
* As a last step (for messages that must be authenticated, this also includes the verification message), create and concatenate the MAC/signature payload without the MAC/signature field filled in
* 作为最后一步（对于必须进行身份验证的消息，这还包括验证消息），创建并连接MAC/签名有效负载，而不填写MAC/签名字段
(if a Next payload field is included in this payload, it is set to Last payload).
（如果此有效负载中包含下一个有效负载字段，则将其设置为最后一个有效负载）。
* Calculate the MAC/signature over the entire MIKEY message, except the MAC/Signature field, and add the MAC/signature in the field. In the case of the verification message, the Identity_i || Identity_r || Timestamp MUST directly follow the MIKEY message in the Verification MAC calculation. Note that the added identities and timestamp are identical to those transported in the ID and T payloads.
* 计算整个MIKEY消息的MAC/签名（MAC/签名字段除外），并在字段中添加MAC/签名。对于验证消息，在验证MAC计算中，标识| i | |标识| r | |时间戳必须直接跟随MIKEY消息。请注意，添加的标识和时间戳与ID和T有效负载中传输的标识和时间戳相同。
In the public key case, the Key data transport payload is generated by concatenating the IDi with the TGKs. This is then encrypted and placed in the data field. The MAC is calculated over the entire Key data transport payload except the MAC field. Before calculating the MAC, the Next payload field is set to zero.
在公钥情况下，通过将IDi与TGKs连接起来生成密钥数据传输有效负载。然后对其进行加密并放置在数据字段中。MAC是在除MAC字段之外的整个密钥数据传输有效载荷上计算的。在计算MAC之前，下一个有效负载字段设置为零。
Note that all messages from the Initiator MUST use a unique timestamp. The Responder does not create a new timestamp, but uses the timestamp used by the Initiator.
请注意，来自启动器的所有消息都必须使用唯一的时间戳。响应程序不创建新的时间戳，而是使用启动器使用的时间戳。
In general, parsing of a MIKEY message is done by extracting payload by payload and checking that no errors occur. The exact procedure is implementation specific; however, for the Responder, it is RECOMMENDED that the following procedure be followed:
通常，对MIKEY消息的解析是通过逐个有效负载提取有效负载并检查没有错误发生来完成的。具体程序是具体实施的；但是，对于响应者，建议遵循以下程序：
* Extract the Timestamp and check that it is within the allowable clock skew (if not, discard the message). Also check the replay cache (Section 5.4) so that the message is not replayed (see Section 5.4). If the message is replayed, discard it.
* 提取时间戳并检查它是否在允许的时钟偏移范围内（如果不在，则丢弃消息）。同时检查重播缓存（第5.4节），以便不重播消息（见第5.4节）。如果消息被重播，则丢弃它。
* Extract the ID and authentication algorithm (if not included, assume the default).
* 提取ID和身份验证算法（如果未包含，则假定为默认值）。
* Verify the MAC/signature.
* 验证MAC/签名。
* If the authentication is not successful, an Auth failure Error message MAY be sent to the Initiator. The message is then discarded from further processing. See also Section 5.1.2 for treatment of errors.
* 如果身份验证未成功，则可能会向启动器发送身份验证失败错误消息。然后从进一步处理中丢弃该消息。关于错误的处理，另见第5.1.2节。
* If the authentication is successful, the message is processed and also added to the replay cache; processing is implementation specific. Note also that only successfully authenticated messages are stored in the replay cache.
* 如果认证成功，则处理消息并将其添加到重播缓存中；处理是特定于实现的。还请注意，只有经过成功身份验证的消息才会存储在replay缓存中。
* If any unsupported parameters or errors occur during the processing, these MAY be reported to the Initiator by sending an error message. The processing is then aborted. The error message can also include payloads to describe the supported parameters.
* 如果在处理过程中出现任何不受支持的参数或错误，可以通过发送错误消息向启动器报告这些参数或错误。然后中止处理。错误消息还可以包括描述支持的参数的有效载荷。
* If the processing was successful and in case the Initiator requested it, a verification/response message MAY be created and sent to the Initiator.
* 如果处理成功并且发起人请求，则可创建验证/响应消息并发送给发起人。
MIKEY does not use a challenge-response mechanism for replay handling; instead, timestamps are used. This requires that the clocks are synchronized. The required synchronization is dependent on the number of messages that can be cached (note though, that the replay cache only contains messages that have been successfully authenticated). If we could assume an unlimited cache, the terminals would not need to be synchronized at all (as the cache could then contain all previous messages). However, if there are restrictions on the size of the replay cache, the clocks will need to be synchronized to some extent. In short, one can in general say that it is a tradeoff between the size of the replay cache and the required synchronization.
MIKEY不使用质询-响应机制进行重播处理；而是使用时间戳。这要求时钟同步。所需的同步取决于可缓存的消息数（但请注意，replay缓存仅包含已成功验证的消息）。如果我们可以假设一个无限缓存，那么终端根本不需要同步（因为缓存可以包含所有以前的消息）。但是，如果重播缓存的大小受到限制，则需要在一定程度上同步时钟。简言之，通常可以说这是重播缓存大小和所需同步之间的折衷。
Timestamp usage prevents replay attacks under the following assumptions:
在以下假设下，使用时间戳可防止重播攻击：
* Each host has a clock which is at least "loosely synchronized" with the clocks of the other hosts.
* 每个主机都有一个至少与其他主机的时钟“松散同步”的时钟。
* If the clocks are to be synchronized over the network, a secure network clock synchronization protocol SHOULD be used, e.g., [ISO3].
* 如果要通过网络同步时钟，则应使用安全的网络时钟同步协议，例如[ISO3]。
* Each Responder utilizes a replay cache in order to remember the successfully authenticated messages presented within an allowable clock skew (which is set by the local policy).
* 每个响应者利用重播缓存来记住在允许的时钟偏差（由本地策略设置）内显示的成功认证的消息。
* Replayed and outdated messages, for example, messages that can be found in the replay cache or which have an outdated timestamp are discarded and not processed.
* 重播和过期的消息，例如，可以在重播缓存中找到的消息或具有过期时间戳的消息将被丢弃而不进行处理。
* If the host loses track of the incoming requests (e.g., due to overload), it rejects all incoming requests until the clock skew interval has passed.
* 如果主机失去对传入请求的跟踪（例如，由于过载），它将拒绝所有传入请求，直到时钟偏移间隔过去。
In a client-server scenario, servers may encounter a high workload, especially if a replay cache is necessary. However, servers that assume the role of MIKEY Initiators will not need to manage any significant replay cache as they will refuse all incoming messages that are not a response to a message previously sent by the server.
在客户机-服务器场景中，服务器可能会遇到高工作负载，特别是在需要重播缓存的情况下。但是，承担MIKEY启动器角色的服务器将不需要管理任何重要的重播缓存，因为它们将拒绝所有不是对服务器先前发送的消息的响应的传入消息。
In general, a client may not expect a very high load of incoming messages and may therefore allow the degree of looseness to be on the order of several minutes to hours. If a (D)DoS attack is launched and the replay cache grows too large, MIKEY MAY dynamically decrease the looseness so that the replay cache becomes manageable. However, note that such (D)DoS attacks can only be performed by peers that can authenticate themselves. Hence, such an attack is very easy to trace and mitigate.
一般来说，客户机可能不希望收到很高的传入消息负载，因此可能允许松散程度在几分钟到几小时之间。如果发起（D）DoS攻击，且重播缓存增长过大，MIKEY可能会动态减少松动，以便重播缓存变得可管理。但是，请注意，此类（D）DoS攻击只能由能够自我验证的对等方执行。因此，这种攻击很容易跟踪和缓解。
The maximum number of messages that a client will need to cache may vary depending on the capacity of the client itself and the network. The number of expected messages should be taken into account.
客户端需要缓存的最大消息数可能因客户端本身和网络的容量而异。应考虑预期消息的数量。
For example, assume that we can at most spend 6kB on a replay cache. Assume further that we need to store 30 bytes for each incoming authenticated message (the hash of the message is 20 bytes). This implies that it is possible to cache approximately 204 messages. If the expected number of messages per minute can be estimated, the clock skew can easily be calculated. For example, in a SIP scenario where the client is expected, in the most extreme case, to receive 10 calls per minute, the clock skew needed is then approximately 20 minutes. In a not so extreme setting, where one could expect an incoming call every 5th minute, this would result in a clock skew on the order of 16.5 hours (approx 1000 minutes).
例如，假设我们最多可以在重播缓存上花费6kB。进一步假设我们需要为每个传入的经过身份验证的消息存储30个字节（消息的散列为20个字节）。这意味着可以缓存大约204条消息。如果可以估计每分钟的预期消息数，则可以很容易地计算时钟偏移。例如，在SIP场景中，在最极端的情况下，客户端预期每分钟接收10个呼叫，那么所需的时钟偏移大约为20分钟。在不太极端的情况下，每5分钟就有一个来电，这将导致时钟偏移16.5小时（约1000分钟）。
Consider a very extreme case, where the maximum number of incoming messages are assumed to be on the order of 120 messages per minute, and a requirement that the clock skew is on the order of 10 minutes, a 48kB replay cache would be required.
考虑一个非常极端的情况，其中传入消息的最大数目被假定为每分钟120个消息的顺序，并且要求时钟偏移量为10分钟的顺序，需要48 kb重放高速缓存。
Hence, one can note that the required clock skew will depend largely on the setting in which MIKEY is used. One recommendation is to fix a size for the replay cache, allowing the clock skew to be large (the initial clock skew can be set depending on the application in which it is used). As the replay cache grows, the clock skew is decreased depending on the percentage of the used replay cache. Note that this is locally handled, which will not require interaction with the peer (even though it may indirectly effect the peer). However, exactly how to implement such functionality is out of the scope of this document and considered implementation specific.
因此，可以注意到，所需的时钟偏移在很大程度上取决于使用MIKEY的设置。一个建议是固定replay缓存的大小，允许时钟偏移较大（初始时钟偏移可以根据使用它的应用程序进行设置）。随着replay缓存的增长，时钟偏移将根据使用的replay缓存的百分比而减小。请注意，这是本地处理的，不需要与对等方交互（即使它可能间接影响对等方）。但是，如何实现这些功能不在本文档的范围内，并且被认为是特定于实现的。
In case of a DoS attack, the client will most likely be able to handle the replay cache. A more likely (and serious) DoS attack is a CPU DoS attack where the attacker sends messages to the peer, which then needs to expend resources on verifying the MACs/signatures of the incoming messages.
在DoS攻击的情况下，客户端最有可能处理重播缓存。更可能（也是更严重）的DoS攻击是CPU DoS攻击，攻击者向对等方发送消息，然后对等方需要花费资源来验证传入消息的MAC/签名。
This section describes, in detail, all the payloads. For all encoding, network byte order is always used. While defining supported types (e.g., which hash functions are supported) the mandatory-to-implement types are indicated (as Mandatory), as well as the default types (note, default also implies mandatory implementation). Support for the other types are implicitly assumed to be optional.
本节详细描述了所有有效载荷。对于所有编码，始终使用网络字节顺序。在定义支持的类型（例如，支持哪些散列函数）时，将指示实现类型的强制类型（作为强制类型），以及默认类型（注意，默认也意味着强制实现）。对其他类型的支持隐式假定为可选。
In the following, note that the support for SRTP [SRTP] as a security protocol is defined. This will help us better understand the purpose of the different payloads and fields. Other security protocols MAY be specified for use within MIKEY, see Section 10.
在下文中，请注意，已定义了对作为安全协议的SRTP[SRTP]的支持。这将帮助我们更好地理解不同有效载荷和字段的用途。其他安全协议可指定在MIKEY内使用，见第10节。
In the following, the sign ~ indicates variable length field.
在下文中，符号~表示可变长度字段。
The Common Header payload MUST always be present as the first payload in each message. The Common Header includes a general description of the exchange message.
公共报头有效负载必须始终作为每条消息中的第一个有效负载存在。公共标头包括交换消息的一般说明。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload !V! PRF func !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CSB ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! #CS ! CS ID map type! CS ID map info ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload !V! PRF func !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CSB ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! #CS ! CS ID map type! CS ID map info ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* version (8 bits): the version number of MIKEY.
* 版本（8位）：MIKEY的版本号。
version = 0x01 refers to MIKEY as defined in this document.
版本=0x01指本文件中定义的MIKEY。
* data type (8 bits): describes the type of message (e.g., public-key transport message, verification message, error message).
* 数据类型（8位）：描述消息的类型（例如，公钥传输消息、验证消息、错误消息）。
Data type | Value | Comment
--------------------------------------
Pre-shared | 0 | Initiator's pre-shared key message
PSK ver msg | 1 | Verification message of a Pre-shared
| | key message
Public key | 2 | Initiator's public-key transport message
PK ver msg | 3 | Verification message of a public-key
| | message
D-H init | 4 | Initiator's DH exchange message
D-H resp | 5 | Responder's DH exchange message
Error | 6 | Error message
Data type | Value | Comment
--------------------------------------
Pre-shared | 0 | Initiator's pre-shared key message
PSK ver msg | 1 | Verification message of a Pre-shared
| | key message
Public key | 2 | Initiator's public-key transport message
PK ver msg | 3 | Verification message of a public-key
| | message
D-H init | 4 | Initiator's DH exchange message
D-H resp | 5 | Responder's DH exchange message
Error | 6 | Error message
Table 6.1.a
表6.1.a
* next payload (8 bits): identifies the payload that is added after this payload.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
Next payload | Value | Section
------------------------------
Last payload | 0 | -
KEMAC | 1 | 6.2
PKE | 2 | 6.3
DH | 3 | 6.4
SIGN | 4 | 6.5
T | 5 | 6.6
ID | 6 | 6.7
CERT | 7 | 6.7
CHASH | 8 | 6.8
V | 9 | 6.9
SP | 10 | 6.10
RAND | 11 | 6.11
ERR | 12 | 6.12
Key data | 20 | 6.13
General Ext. | 21 | 6.15
Next payload | Value | Section
------------------------------
Last payload | 0 | -
KEMAC | 1 | 6.2
PKE | 2 | 6.3
DH | 3 | 6.4
SIGN | 4 | 6.5
T | 5 | 6.6
ID | 6 | 6.7
CERT | 7 | 6.7
CHASH | 8 | 6.8
V | 9 | 6.9
SP | 10 | 6.10
RAND | 11 | 6.11
ERR | 12 | 6.12
Key data | 20 | 6.13
General Ext. | 21 | 6.15
Table 6.1.b
表6.1.b
Note that some of the payloads cannot directly follow the header (such as "Last payload", "Signature"). However, the Next payload field is generic for all payloads. Therefore, a value is allocated for each payload. The Next payload field is set to zero (Last payload) if the current payload is the last payload.
请注意，一些有效负载不能直接跟随标头（例如“最后一个有效负载”、“签名”）。但是，下一个有效载荷字段是所有有效载荷的通用字段。因此，为每个有效负载分配一个值。如果当前有效负载是最后一个有效负载，则下一个有效负载字段设置为零（最后一个有效负载）。
* V (1 bit): flag to indicate whether a verification message is expected or not (this only has meaning when it is set by the Initiator). The V flag SHALL be ignored by the receiver in the DH method (as the response is MANDATORY).
* V（1位）：指示是否需要验证消息的标志（仅当启动器设置验证消息时才有意义）。在DH方法中，接收器应忽略V标志（因为响应是强制性的）。
V = 0 ==> no response expected
V = 1 ==> response expected
V = 0 ==> no response expected
V = 1 ==> response expected
* PRF func (7 bits): indicates the PRF function that has been/will be used for key derivation.
* PRF func（7位）：表示已/将用于密钥派生的PRF函数。
PRF func | Value | Comments
--------------------------------------------------------
MIKEY-1 | 0 | Mandatory (see Section 4.1.2)
PRF func | Value | Comments
--------------------------------------------------------
MIKEY-1 | 0 | Mandatory (see Section 4.1.2)
Table 6.1.c
表6.1.c
* CSB ID (32 bits): identifies the CSB. It is RECOMMENDED that the CSB ID be chosen at random by the Initiator. This ID MUST be unique between each Initiator-Responder pair, i.e., not globally unique. An Initiator MUST check for collisions when choosing the ID (if the Initiator already has one or more established CSBs with the Responder). The Responder uses the same CSB ID in the response.
* CSB ID（32位）：标识CSB。建议启动器随机选择CSB ID。此ID在每个启动器-响应程序对之间必须是唯一的，即不是全局唯一的。启动器在选择ID时必须检查冲突（如果启动器已与响应程序建立了一个或多个CSB）。响应程序在响应中使用相同的CSB ID。
* #CS (8 bits): indicates the number of Crypto Sessions that will be handled within the CBS. Note that even though it is possible to use 255 CSs, it is not likely that a CSB will include this many CSs. The integer 0 is interpreted as no CS included. This may be the case in an initial setup message.
* #CS（8位）：表示将在CBS内处理的加密会话数。注意，即使可以使用255个CSs，CSB也不可能包含这么多CSs。整数0被解释为不包含CS。初始设置消息中可能存在这种情况。
* CS ID map type (8 bits): specifies the method of uniquely mapping Crypto Sessions to the security protocol sessions.
* CS ID映射类型（8位）：指定将加密会话唯一映射到安全协议会话的方法。
CS ID map type | Value
-----------------------
SRTP-ID | 0
CS ID map type | Value
-----------------------
SRTP-ID | 0
Table 6.1.d
表6.1.d
* CS ID map info (16 bits): identifies the crypto session(s) for which the SA should be created. The currently defined map type is the SRTP-ID (defined in Section 6.1.1).
* CS ID映射信息（16位）：标识应为其创建SA的加密会话。当前定义的地图类型为SRTP-ID（定义见第6.1.1节）。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_1 ! SSRC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_1 (cont) ! ROC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_1 (cont) ! Policy_no_2 ! SSRC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_2 (cont) ! ROC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_2 (cont) ! :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_#CS ! SSRC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!SSRC_#CS (cont)! ROC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_#CS (cont)!
+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_1 ! SSRC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_1 (cont) ! ROC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_1 (cont) ! Policy_no_2 ! SSRC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_2 (cont) ! ROC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_2 (cont) ! :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_#CS ! SSRC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!SSRC_#CS (cont)! ROC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_#CS (cont)!
+-+-+-+-+-+-+-+-+
* Policy_no_i (8 bits): The security policy applied for the stream with SSRC_i. The same security policy may apply for all CSs.
* Policy_no_i（8位）：应用于具有SSRC_i的流的安全策略。相同的安全策略可能适用于所有CSs。
* SSRC_i (32 bits): specifies the SSRC that MUST be used for the i-th SRTP stream. Note that it is the sender of the streams that chooses the SSRC. Therefore, it is possible that the Initiator of MIKEY cannot fill in all fields. In this case, SSRCs that are not chosen by the Initiator are set to zero and the Responder fills in these fields in the response message. Note that SRTP specifies requirements on the uniqueness of the SSRCs (to avoid two-time pad problems if the same TEK is used for more than one stream) [SRTP].
* SSRC_i（32位）：指定必须用于第i个SRTP流的SSRC。请注意，选择SSRC的是流的发送方。因此，MIKEY的发起人可能无法填写所有字段。在这种情况下，发起者未选择的SSRC设置为零，响应者在响应消息中填写这些字段。注意，SRTP规定了SSRC唯一性的要求（如果同一TEK用于多个流，则避免两次pad问题）[SRTP]。
* ROC_i (32 bits): Current rollover counter used in SRTP. If the SRTP session has not started, this field is set to 0. This field is used to enable a member to join and synchronize with an already started stream.
* ROC_i（32位）：SRTP中使用的当前翻转计数器。如果SRTP会话尚未启动，则此字段设置为0。此字段用于使成员能够加入已启动的流并与之同步。
NOTE: The stream using SSRC_i will also have Crypto Session ID equal to no i (NOT to the SSRC).
注意：使用SSRC_i的流的加密会话ID也将等于no i（不是SSRC）。
The Key data transport payload contains encrypted Key data sub-payloads (see Section 6.13 for the definition of the Key data sub-payload). It may contain one or more Key data payloads, each including, for example, a TGK. The last Key data payload has its Next payload field set to Last payload. For an update message (see also Section 4.5), it is allowed to skip the Key data sub-payloads (which will result in the Encr data len being equal to 0).
密钥数据传输有效载荷包含加密密钥数据子有效载荷（密钥数据子有效载荷的定义见第6.13节）。它可以包含一个或多个关键数据有效载荷，每个有效载荷包括例如TGK。最后一个密钥数据有效负载的下一个有效负载字段设置为最后一个有效负载。对于更新消息（另见第4.5节），允许跳过关键数据子有效载荷（这将导致Encr数据len等于0）。
Note that the MAC coverage depends on the method used, i.e., pre-shared vs public key, see below.
请注意，MAC覆盖率取决于所使用的方法，即预共享与公钥，见下文。
If the transport method used is the pre-shared key method, this Key data transport payload is the last payload in the message (note that the Next payload field is set to Last payload). The MAC is then calculated over the entire MIKEY message following the directives in Section 5.2.
如果使用的传输方法是预共享密钥方法，则此密钥数据传输有效负载是消息中的最后一个有效负载（请注意，下一个有效负载字段设置为最后一个有效负载）。然后，根据第5.2节中的指令，在整个MIKEY消息上计算MAC。
If the transport method used is the public-key method, the Initiator's identity is added in the encrypted data. This is done by adding the ID payload as the first payload, which is then followed by the Key data sub-payloads. Note that for an update message, the ID is still sent encrypted to the Responder (this is to avoid certain re-direction attacks) even though no Key data sub-payload is added after.
如果使用的传输方法是公钥方法，则会在加密数据中添加启动器的标识。这是通过添加ID有效载荷作为第一个有效载荷来完成的，然后是关键数据子有效载荷。请注意，对于更新消息，即使之后未添加密钥数据子有效负载，ID仍会加密发送到响应程序（这是为了避免某些重定向攻击）。
In the public-key case, the coverage of the MAC field is over the Key data transport payload only, instead of the complete MIKEY message, as in the pre-shared case. The MAC is therefore calculated over the Key data transport payload, except for the MAC field and where the Next payload field has been set to zero (see also Section 5.2).
在公钥情况下，MAC字段的覆盖范围仅覆盖密钥数据传输有效载荷，而不是像预共享情况那样覆盖完整的MIKEY消息。因此，除了MAC字段和下一个有效载荷字段已设置为零（另见第5.2节）之外，在关键数据传输有效载荷上计算MAC。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Encr alg ! Encr data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Mac alg ! MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Encr alg ! Encr data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Mac alg ! MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for defined values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。定义值见第6.1节。
* Encr alg (8 bits): the encryption algorithm used to encrypt the Encr data field.
* Encr alg（8位）：用于加密Encr数据字段的加密算法。
Encr alg | Value | Comment
-------------------------------------------
NULL | 0 | Very restricted usage, see Section 4.2.3!
AES-CM-128 | 1 | Mandatory; AES-CM using a 128-bit key, see
Section 4.2.3)
AES-KW-128 | 2 | AES Key Wrap using a 128-bit key, see
Section 4.2.3
Encr alg | Value | Comment
-------------------------------------------
NULL | 0 | Very restricted usage, see Section 4.2.3!
AES-CM-128 | 1 | Mandatory; AES-CM using a 128-bit key, see
Section 4.2.3)
AES-KW-128 | 2 | AES Key Wrap using a 128-bit key, see
Section 4.2.3
Table 6.2.a
表6.2.a
* Encr data len (16 bits): length of Encr data (in bytes).
* Encr数据长度（16位）：Encr数据的长度（字节）。
* Encr data (variable length): the encrypted key sub-payloads (see Section 6.13).
* Encr数据（可变长度）：加密密钥子有效载荷（见第6.13节）。
* MAC alg (8 bits): specifies the authentication algorithm used.
* MAC alg（8位）：指定使用的身份验证算法。
MAC alg | Value | Comments | Length (bits)
----------------------------------------------------------
NULL | 0 | restricted usage | 0
| | Section 4.2.4 |
HMAC-SHA-1-160 | 1 | Mandatory, | 160
| | Section 4.2.4 |
MAC alg | Value | Comments | Length (bits)
----------------------------------------------------------
NULL | 0 | restricted usage | 0
| | Section 4.2.4 |
HMAC-SHA-1-160 | 1 | Mandatory, | 160
| | Section 4.2.4 |
Table 6.2.b
表6.2.b
* MAC (variable length): the message authentication code of the entire message.
* MAC（可变长度）：整个消息的消息身份验证代码。
The Envelope data payload contains the encrypted envelope key that is used in the public-key transport to protect the data in the Key data transport payload. The encryption algorithm used is implicit from the certificate/public key used.
信封数据有效载荷包含加密的信封密钥，该密钥在公钥传输中用于保护密钥数据传输有效载荷中的数据。所使用的加密算法来自所使用的证书/公钥。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! C ! Data len ! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! C ! Data len ! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见第6.1节。
* C (2 bits): envelope key cache indicator (Section 3.2).
* C（2位）：信封密钥缓存指示器（第3.2节）。
Cache type | Value | Comments
--------------------------------------
No cache | 0 | The envelope key MUST NOT be cached
Cache | 1 | The envelope key MUST be cached
Cache for CSB | 2 | The envelope key MUST be cached, but only
| | to be used for the specific CSB.
Table 6.3
Cache type | Value | Comments
--------------------------------------
No cache | 0 | The envelope key MUST NOT be cached
Cache | 1 | The envelope key MUST be cached
Cache for CSB | 2 | The envelope key MUST be cached, but only
| | to be used for the specific CSB.
Table 6.3
* Data len (14 bits): the length of the data field (in bytes).
* 数据长度（14位）：数据字段的长度（字节）。
* Data (variable length): the encrypted envelope key.
* 数据（可变长度）：加密的信封密钥。
The DH data payload carries the DH-value and indicates the DH-group used. Notice that in this sub-section, "MANDATORY" is conditioned upon DH being supported.
DH数据有效载荷携带DH值并指示使用的DH组。请注意，在本小节中，“强制性”以支持DH为条件。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! DH-Group ! DH-value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Reserv! KV ! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! DH-Group ! DH-value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Reserv! KV ! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见第6.1节。
* DH-Group (8 bits): identifies the DH group used.
* DH组（8位）：标识使用的DH组。
DH-Group | Value | Comment | DH Value length (bits)
--------------------------------------|---------------------
OAKLEY 5 | 0 | Mandatory | 1536
OAKLEY 1 | 1 | | 768
OAKLEY 2 | 2 | | 1024
DH-Group | Value | Comment | DH Value length (bits)
--------------------------------------|---------------------
OAKLEY 5 | 0 | Mandatory | 1536
OAKLEY 1 | 1 | | 768
OAKLEY 2 | 2 | | 1024
Table 6.4
表6.4
* DH-value (variable length): the public DH-value (the length is implicit from the group used).
* DH值（可变长度）：公共DH值（长度是所用组的隐式长度）。
* KV (4 bits): indicates the type of key validity period specified. This may be done by using an SPI (alternatively an MKI in SRTP) or by providing an interval in which the key is valid (e.g., in the latter case, for SRTP this will be the index range where the key is valid). See Section 6.13 for pre-defined values.
* KV（4位）：表示指定的密钥有效期类型。这可以通过使用SPI（或者SRTP中的MKI）或通过提供密钥有效的间隔（例如，在后一种情况下，对于SRTP，这将是密钥有效的索引范围）来实现。有关预定义值，请参见第6.13节。
* KV data (variable length): This includes either the SPI/MKI or an interval (see Section 6.14). If KV is NULL, this field is not included.
* KV数据（可变长度）：包括SPI/MKI或间隔（见第6.14节）。如果KV为空，则不包括该字段。
The Signature payload carries the signature and its related data. The signature payload is always the last payload in the PK transport and DH exchange messages. The signature algorithm used is implicit from the certificate/public key used.
签名有效载荷携带签名及其相关数据。签名有效负载始终是PK传输和DH交换消息中的最后一个有效负载。所使用的签名算法来自所使用的证书/公钥。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! S type| Signature len ! Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! S type| Signature len ! Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* S type (4 bits): indicates the signature algorithm applied by the signer.
* S类型（4位）：表示签名者应用的签名算法。
S type | Value | Comments
-------------------------------------
RSA/PKCS#1/1.5| 0 | Mandatory, PKCS #1 version 1.5 signature
[PSS]
RSA/PSS | 1 | RSASSA-PSS signature [PSS]
S type | Value | Comments
-------------------------------------
RSA/PKCS#1/1.5| 0 | Mandatory, PKCS #1 version 1.5 signature
[PSS]
RSA/PSS | 1 | RSASSA-PSS signature [PSS]
Table 6.5
表6.5
* Signature len (12 bits): the length of the signature field (in bytes).
* 签名长度（12位）：签名字段的长度（字节）。
* Signature (variable length): the signature (its formatting and padding depend on the type of signature).
* 签名（可变长度）：签名（其格式和填充取决于签名的类型）。
The timestamp payload carries the timestamp information.
时间戳有效负载携带时间戳信息。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! TS type ! TS value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! TS type ! TS value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见第6.1节。
* TS type (8 bits): specifies the timestamp type used.
* TS类型（8位）：指定使用的时间戳类型。
TS type | Value | Comments | length of TS value
-------------------------------------|-------------------
NTP-UTC | 0 | Mandatory | 64-bits
NTP | 1 | Mandatory | 64-bits
COUNTER | 2 | Optional | 32-bits
TS type | Value | Comments | length of TS value
-------------------------------------|-------------------
NTP-UTC | 0 | Mandatory | 64-bits
NTP | 1 | Mandatory | 64-bits
COUNTER | 2 | Optional | 32-bits
Table 6.6
表6.6
Note: COUNTER SHALL be padded (with leading zeros) to a 64-bit value when used as input for the default PRF.
注：当用作默认PRF的输入时，计数器应填充（带前导零）至64位值。
* TS-value (variable length): The timestamp value of the specified TS type.
* TS值（可变长度）：指定TS类型的时间戳值。
Note that the ID payload and the Certificate payload are two completely different payloads (having different payload identifiers). However, as they share the same payload structure, they are described in the same section.
注意，ID有效负载和证书有效负载是两个完全不同的有效负载（具有不同的有效负载标识符）。然而，由于它们共享相同的有效载荷结构，因此在同一节中对它们进行了描述。
The ID payload carries a uniquely defined identifier.
ID有效负载携带唯一定义的标识符。
The certificate payload contains an indicator of the certificate provided as well as the certificate data. If a certificate chain is to be provided, each certificate in the chain should be included in a separate CERT payload.
证书有效负载包含所提供证书的指示器以及证书数据。如果要提供证书链，则链中的每个证书都应包含在单独的证书有效负载中。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! ID/Cert Type ! ID/Cert len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID/Certificate Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! ID/Cert Type ! ID/Cert len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID/Certificate Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见第6.1节。
If the payload is an ID payload, the following values apply for the ID type field:
如果有效负载是ID有效负载，则以下值适用于ID类型字段：
* ID Type (8 bits): specifies the identifier type used.
* ID类型（8位）：指定使用的标识符类型。
ID Type | Value | Comments
----------------------------------------------
NAI | 0 | Mandatory (see [NAI])
URI | 1 | Mandatory (see [URI])
ID Type | Value | Comments
----------------------------------------------
NAI | 0 | Mandatory (see [NAI])
URI | 1 | Mandatory (see [URI])
Table 6.7.a
表6.7.a
If the payload is a Certificate payload, the following values applies for the Cert type field:
如果有效负载是证书有效负载，则以下值适用于证书类型字段：
* Cert Type (8 bits): specifies the certificate type used.
* 证书类型（8位）：指定使用的证书类型。
Cert Type | Value | Comments
----------------------------------------------
X.509v3 | 0 | Mandatory
X.509v3 URL | 1 | plain ASCII URL to the location of the Cert
X.509v3 Sign | 2 | Mandatory (used for signatures only)
X.509v3 Encr | 3 | Mandatory (used for encryption only)
Cert Type | Value | Comments
----------------------------------------------
X.509v3 | 0 | Mandatory
X.509v3 URL | 1 | plain ASCII URL to the location of the Cert
X.509v3 Sign | 2 | Mandatory (used for signatures only)
X.509v3 Encr | 3 | Mandatory (used for encryption only)
Table 6.7.b
表6.7.b
* ID/Cert len (16 bits): the length of the ID or Certificate field (in bytes).
* ID/Cert len（16位）：ID或证书字段的长度（字节）。
* ID/Certificate (variable length): The ID or Certificate data. The X.509 [X.509] certificates are included as a bytes string using DER encoding as specified in X.509.
* ID/证书（可变长度）：ID或证书数据。X.509[X.509]证书使用X.509中指定的DER编码作为字节字符串包含。
The Cert hash payload contains the hash of the certificate used.
证书哈希有效负载包含所用证书的哈希。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Hash func ! Hash ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Hash func ! Hash ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见第6.1节。
* Hash func (8 bits): indicates the hash function that is used (see also Section 4.2.1).
* 哈希函数（8位）：表示使用的哈希函数（另见第4.2.1节）。
Hash func | Value | Comment | hash length (bits)
-------------------------------------------------
SHA-1 | 0 | Mandatory | 160
MD5 | 1 | | 128
Hash func | Value | Comment | hash length (bits)
-------------------------------------------------
SHA-1 | 0 | Mandatory | 160
MD5 | 1 | | 128
Table 6.8
表6.8
* Hash (variable length): the hash data. The hash length is implicit from the hash function used.
* 哈希（可变长度）：哈希数据。哈希长度是所用哈希函数的隐式长度。
The Ver msg payload contains the calculated verification message in the pre-shared key and the public-key transport methods. Note that the MAC is calculated over the entire MIKEY message, as well as the IDs and Timestamp (see also Section 5.2).
Ver msg有效负载在预共享密钥和公钥传输方法中包含计算出的验证消息。请注意，MAC是在整个MIKEY消息以及ID和时间戳上计算的（另请参见第5.2节）。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Auth alg ! Ver data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Auth alg ! Ver data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见第6.1节。
* Auth alg (8 bits): specifies the MAC algorithm used for the verification message. See Section 6.2 for defined values.
* Auth alg（8位）：指定用于验证消息的MAC算法。定义值见第6.2节。
* Ver data (variable length): the verification message data. The length is implicit from the authentication algorithm used.
* 版本数据（可变长度）：验证消息数据。长度是所使用的身份验证算法的隐式长度。
The Security Policy payload defines a set of policies that apply to a specific security protocol.
安全策略负载定义了一组应用于特定安全协议的策略。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见第6.1节。
* Policy no (8 bits): each security policy payload must be given a distinct number for the current MIKEY session by the local peer. This number is used to map a crypto session to a specific policy (see also Section 6.1.1).
* 策略编号（8位）：本地对等方必须为当前MIKEY会话为每个安全策略有效负载指定一个不同的编号。此编号用于将加密会话映射到特定策略（另请参见第6.1.1节）。
* Prot type (8 bits): defines the security protocol.
* 保护类型（8位）：定义安全协议。
Prot type | Value |
---------------------------
SRTP | 0 |
Prot type | Value |
---------------------------
SRTP | 0 |
Table 6.10
表6.10
* Policy param length (16 bits): defines the total length of the policy parameters for the specific security protocol.
* 策略参数长度（16位）：定义特定安全协议的策略参数的总长度。
* Policy param (variable length): defines the policy for the specific security protocol.
* 策略参数（可变长度）：定义特定安全协议的策略。
The Policy param part is built up by a set of Type/Length/Value fields. For each security protocol, a set of possible types/values that can be negotiated is defined.
策略参数部分由一组类型/长度/值字段组成。对于每个安全协议，定义了一组可以协商的可能类型/值。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Type (8 bits): specifies the type of the parameter.
* 类型（8位）：指定参数的类型。
* Length (8 bits): specifies the length of the Value field (in bytes).
* 长度（8位）：指定值字段的长度（字节）。
* Value (variable length): specifies the value of the parameter.
* 值（可变长度）：指定参数的值。
This policy specifies the parameters for SRTP and SRTCP. The types/values that can be negotiated are defined by the following table:
此策略指定SRTP和SRTCP的参数。可协商的类型/值由下表定义：
Type | Meaning | Possible values
----------------------------------------------------
0 | Encryption algorithm | see below
1 | Session Encr. key length | depends on cipher used
2 | Authentication algorithm | see below
3 | Session Auth. key length | depends on MAC used
4 | Session Salt key length | see [SRTP] for recommendations
5 | SRTP Pseudo Random Function | see below
6 | Key derivation rate | see [SRTP] for recommendations
7 | SRTP encryption off/on | 0 if off, 1 if on
8 | SRTCP encryption off/on | 0 if off, 1 if on
9 | sender's FEC order | see below
10 | SRTP authentication off/on | 0 if off, 1 if on
11 | Authentication tag length | in bytes
12 | SRTP prefix length | in bytes
Type | Meaning | Possible values
----------------------------------------------------
0 | Encryption algorithm | see below
1 | Session Encr. key length | depends on cipher used
2 | Authentication algorithm | see below
3 | Session Auth. key length | depends on MAC used
4 | Session Salt key length | see [SRTP] for recommendations
5 | SRTP Pseudo Random Function | see below
6 | Key derivation rate | see [SRTP] for recommendations
7 | SRTP encryption off/on | 0 if off, 1 if on
8 | SRTCP encryption off/on | 0 if off, 1 if on
9 | sender's FEC order | see below
10 | SRTP authentication off/on | 0 if off, 1 if on
11 | Authentication tag length | in bytes
12 | SRTP prefix length | in bytes
Table 6.10.1.a
表6.10.1.a
Note that if a Type/Value is not set, the default is used (according to SRTP's own criteria). Note also that, if "Session Encr. key length" is set, this should also be seen as the Master key length (otherwise, the SRTP default Master key length is used).
请注意，如果未设置类型/值，则使用默认值（根据SRTP自己的标准）。还请注意，如果设置了“会话加密密钥长度”，则还应将其视为主密钥长度（否则，将使用SRTP默认主密钥长度）。
For the Encryption algorithm, a one byte length is enough. The currently defined possible Values are:
对于加密算法，一个字节的长度就足够了。当前定义的可能值为：
SRTP encr alg | Value
---------------------
NULL | 0
AES-CM | 1
AES-F8 | 2
SRTP encr alg | Value
---------------------
NULL | 0
AES-CM | 1
AES-F8 | 2
Table 6.10.1.b
表6.10.1.b
where AES-CM is AES in CM, and AES-F8 is AES in f8 mode [SRTP].
其中AES-CM是CM中的AES，AES-F8是F8模式[SRTP]中的AES。
For the Authentication algorithm, a one byte length is enough. The currently defined possible Values are:
对于身份验证算法，一个字节的长度就足够了。当前定义的可能值为：
SRTP auth alg | Value
---------------------
NULL | 0
HMAC-SHA-1 | 1
SRTP auth alg | Value
---------------------
NULL | 0
HMAC-SHA-1 | 1
Table 6.10.1.c
表6.10.1.c
For the SRTP pseudo-random function, a one byte length is also enough. The currently defined possible Values are:
对于SRTP伪随机函数，一个字节的长度也足够了。当前定义的可能值为：
SRTP PRF | Value
---------------------
AES-CM | 0
SRTP PRF | Value
---------------------
AES-CM | 0
Table 6.10.1.d
表6.10.1.d
If FEC is used at the same time SRTP is used, MIKEY can negotiate the order in which these should be applied at the sender side.
如果在使用SRTP的同时使用FEC，MIKEY可以协商在发送方应用这些协议的顺序。
FEC order | Value | Comments
--------------------------------
FEC-SRTP | 0 | First FEC, then SRTP
FEC order | Value | Comments
--------------------------------
FEC-SRTP | 0 | First FEC, then SRTP
Table 6.10.1.e
表6.10.1.e
The RAND payload consists of a (pseudo-)random bit-string. The RAND MUST be independently generated per CSB (note that if the CSB has several members, the Initiator MUST use the same RAND for all the members). For randomness recommendations for security, see [RAND].
RAND有效载荷由（伪）随机位字符串组成。RAND必须根据CSB独立生成（请注意，如果CSB有多个成员，则启动器必须对所有成员使用相同的RAND）。有关安全性的随机性建议，请参见[RAND]。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! RAND len ! RAND ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! RAND len ! RAND ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见第6.1节。
* RAND len (8 bits): length of the RAND (in bytes). It SHOULD be at least 16.
* RAND len（8位）：RAND的长度（以字节为单位）。它至少应该是16。
* RAND (variable length): a (pseudo-)randomly chosen bit-string.
* RAND（可变长度）：一个（伪）随机选择的位字符串。
The Error payload is used to specify the error(s) that may have occurred.
错误有效负载用于指定可能已发生的错误。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Error no ! Reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Error no ! Reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见第6.1节。
* Error no (8 bits): indicates the type of error that was encountered.
* 错误编号（8位）：指示遇到的错误类型。
Error no | Value | Comment
-------------------------------------------------------
Auth failure | 0 | Authentication failure
Invalid TS | 1 | Invalid timestamp
Invalid PRF | 2 | PRF function not supported
Invalid MAC | 3 | MAC algorithm not supported
Invalid EA | 4 | Encryption algorithm not supported
Invalid HA | 5 | Hash function not supported
Invalid DH | 6 | DH group not supported
Invalid ID | 7 | ID not supported
Invalid Cert | 8 | Certificate not supported
Invalid SP | 9 | SP type not supported
Invalid SPpar | 10 | SP parameters not supported
Invalid DT | 11 | not supported Data type
Unspecified error | 12 | an unspecified error occurred
Error no | Value | Comment
-------------------------------------------------------
Auth failure | 0 | Authentication failure
Invalid TS | 1 | Invalid timestamp
Invalid PRF | 2 | PRF function not supported
Invalid MAC | 3 | MAC algorithm not supported
Invalid EA | 4 | Encryption algorithm not supported
Invalid HA | 5 | Hash function not supported
Invalid DH | 6 | DH group not supported
Invalid ID | 7 | ID not supported
Invalid Cert | 8 | Certificate not supported
Invalid SP | 9 | SP type not supported
Invalid SPpar | 10 | SP parameters not supported
Invalid DT | 11 | not supported Data type
Unspecified error | 12 | an unspecified error occurred
Table 6.12
表6.12
The Key data payload contains key material, e.g., TGKs. The Key data payloads are never included in clear, but as an encrypted part of the Key data transport payload.
关键数据有效载荷包含关键材料，例如TGK。密钥数据有效载荷从不包含在clear中，而是作为密钥数据传输有效载荷的加密部分。
Note that a Key data transport payload can contain multiple Key data sub-payloads.
请注意，密钥数据传输有效负载可以包含多个密钥数据子有效负载。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len (optional) ! Salt data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len (optional) ! Salt data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。数值见第6.1节。
* Type (4 bits): indicates the type of key included in the payload.
* 类型（4位）：指示有效负载中包含的密钥类型。
Type | Value
-----------------
TGK | 0
TGK+SALT | 1
TEK | 2
TEK+SALT | 3
Type | Value
-----------------
TGK | 0
TGK+SALT | 1
TEK | 2
TEK+SALT | 3
Table 6.13.a
表6.13.a
Note that the possibility of including a TEK (instead of using the TGK) is provided. When sent directly, the TEK can generally not be shared between more than one Crypto Session (unless the Security protocol allows for this, e.g., [SRTP]). The recommended use of sending a TEK, instead of a TGK, is when pre-encrypted material exists and therefore, the TEK must be known in advance.
注意，提供了包括TEK（而不是使用TGK）的可能性。直接发送时，TEK通常不能在多个加密会话之间共享（除非安全协议允许，例如[SRTP]）。发送TEK而不是TGK的建议用途是当存在预加密材料时，因此必须提前知道TEK。
* KV (4 bits): indicates the type of key validity period specified. This may be done by using an SPI (or MKI in the case of [SRTP]) or by providing an interval in which the key is valid (e.g., in the latter case, for SRTP this will be the index range where the key is valid).
* KV（4位）：表示指定的密钥有效期类型。这可以通过使用SPI（或[SRTP]情况下的MKI）或通过提供密钥有效的间隔（例如，在后一种情况下，对于SRTP，这将是密钥有效的索引范围）来实现。
KV | Value | Comments
-------------------------------------------
Null | 0 | No specific usage rule (e.g., a TEK
| | that has no specific lifetime)
SPI | 1 | The key is associated with the SPI/MKI
Interval | 2 | The key has a start and expiration time
| | (e.g., an SRTP TEK)
KV | Value | Comments
-------------------------------------------
Null | 0 | No specific usage rule (e.g., a TEK
| | that has no specific lifetime)
SPI | 1 | The key is associated with the SPI/MKI
Interval | 2 | The key has a start and expiration time
| | (e.g., an SRTP TEK)
Table 6.13.b
表6.13.b
Note that when NULL is specified, any SPI or Interval is valid. For an Interval, this means that the key is valid from the first observed sequence number until the key is replaced (or the security protocol is shutdown).
请注意，当指定NULL时，任何SPI或间隔都是有效的。对于间隔，这意味着密钥从第一个观察到的序列号开始有效，直到密钥被替换（或安全协议被关闭）。
* Key data len (16 bits): the length of the Key data field (in bytes). Note that the sum of the overall length of all the Key data payloads contained in a single Key data transport payload (KEMAC) MUST be such that the KEMAC payload does not exceed a length of 2^16 bytes (total length of KEMAC, see Section 6.2).
* 密钥数据长度（16位）：密钥数据字段的长度（字节）。请注意，单个密钥数据传输有效载荷（KEMAC）中包含的所有密钥数据有效载荷的总长度之和必须确保KEMAC有效载荷不超过2^16字节的长度（KEMAC总长度，见第6.2节）。
* Key data (variable length): The TGK or TEK data.
* 关键数据（可变长度）：TGK或TEK数据。
* Salt len (16 bits): The salt key length in bytes. Note that this field is only included if the salt is specified in the Type-field.
* Salt len（16位）：以字节为单位的Salt密钥长度。请注意，只有在类型字段中指定了盐时，才包括此字段。
* Salt data (variable length): The salt key data. Note that this field is only included if the salt is specified in the Type-field. (For SRTP, this is the so-called master salt.)
* Salt数据（可变长度）：Salt键数据。请注意，只有在类型字段中指定了盐时，才包括此字段。（对于SRTP，这就是所谓的主盐。）
* KV data (variable length): This includes either the SPI or an interval (see Section 6.14). If KV is NULL, this field is not included.
* KV数据（可变长度）：包括SPI或间隔（见第6.14节）。如果KV为空，则不包括该字段。
The Key validity data is not a standalone payload, but part of either the Key data payload (see Section 6.13) or the DH payload (see Section 6.4). The Key validity data gives a guideline of when the key should be used. There are two KV types defined (see Section 6.13), SPI/MKI (SPI) or a lifetime range (interval).
密钥有效性数据不是独立的有效载荷，而是密钥数据有效载荷（见第6.13节）或DH有效载荷（见第6.4节）的一部分。钥匙有效性数据给出了何时使用钥匙的指南。定义了两种KV类型（见第6.13节）、SPI/MKI（SPI）或寿命范围（间隔）。
SPI/MKI
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SPI/MKI
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* SPI Length (8 bits): the length of the SPI (or MKI) in bytes.
* SPI长度（8位）：SPI（或MKI）的长度，以字节为单位。
* SPI (variable length): the SPI (or MKI) value.
* SPI（可变长度）：SPI（或MKI）值。
Interval
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VF Length ! Valid From ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VT Length ! Valid To (expires) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interval
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VF Length ! Valid From ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VT Length ! Valid To (expires) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* VF Length (8 bits): length of the Valid From field in bytes.
* VF长度（8位）：有效起始字段的长度（字节）。
* Valid From (variable length): sequence number, index, timestamp, or other start value that the security protocol uses to identify the start position of the key usage.
* Valid From（可变长度）：序列号、索引、时间戳或安全协议用于标识密钥使用起始位置的其他起始值。
* VT Length (8 bits): length of the Valid To field in bytes.
* VT长度（8位）：有效To字段的长度（字节）。
* Valid To (variable length): sequence number, index, timestamp, or other expiration value that the security protocol can use to identify the expiration of the key usage.
* 有效到（可变长度）：序列号、索引、时间戳或安全协议可用于标识密钥使用过期的其他过期值。
Note that for SRTP usage, the key validity period for a TGK/TEK should be specified with either an interval, where the VF/VT Length is equal to 6 bytes (i.e., the size of the index), or with an MKI. It is RECOMMENDED that if more than one SRTP stream is sharing the same keys and key update/re-keying is desired, this is handled using MKI rather than the From-To method.
请注意，对于SRTP使用，TGK/TEK的密钥有效期应使用间隔（其中VF/VT长度等于6字节（即索引的大小）或MKI指定。建议如果多个SRTP流共享相同的密钥，并且需要密钥更新/重设密钥，则使用MKI而不是From-To方法来处理。
The General extensions payload is included to allow possible extensions to MIKEY without the need for defining a completely new payload each time. This payload can be used in any MIKEY message and is part of the authenticated/signed data part.
包括通用扩展有效负载，以允许对MIKEY进行可能的扩展，而无需每次定义一个全新的有效负载。此有效负载可用于任何MIKEY消息，并且是经过身份验证/签名的数据部分的一部分。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after this payload.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
* Type (8 bits): identifies the type of general payload.
* 类型（8位）：标识一般有效负载的类型。
Type | Value | Comments
---------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs (allocated for use in
[KMASDP])
Type | Value | Comments
---------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs (allocated for use in
[KMASDP])
Table 6.15
表6.15
* Length (16 bits): the length in bytes of the Data field.
* 长度（16位）：数据字段的字节长度。
* Data (variable length): the general payload data.
* 数据（可变长度）：一般有效负载数据。
MIKEY MAY be integrated within session establishment protocols. Currently, integration of MIKEY within SIP/SDP and RTSP is defined in [KMASDP]. MIKEY MAY use other transports, in which case how MIKEY is transported over such a transport protocol has to be defined.
MIKEY可以集成在会话建立协议中。目前，在SIP/SDP和RTSP中集成MIKEY的定义见[KMASDP]。MIKEY可以使用其他传输，在这种情况下，必须定义MIKEY如何通过这种传输协议传输。
What has been discussed up to now is not limited to single peer-to-peer communication (except for the DH method), but can be used to distribute group keys for small-size interactive groups and simple one-to-many scenarios. Section 2.1. describes the scenarios in the focus of MIKEY. This section describes how MIKEY is used in a group scenario (though, see also Section 4.3 for issues related to authorization).
到目前为止，讨论的内容不仅限于单个对等通信（DH方法除外），还可用于为小型交互组和简单的一对多场景分发组密钥。第2.1节。描述MIKEY重点关注的场景。本节描述了MIKEY如何在组场景中使用（不过，有关授权的问题，请参见第4.3节）。
++++
|S |
| |
++++
|
--------+-------------- - -
| | |
v v v
++++ ++++ ++++
|A | |B | |C |
| | | | | |
++++ ++++ ++++
++++
|S |
| |
++++
|
--------+-------------- - -
| | |
v v v
++++ ++++ ++++
|A | |B | |C |
| | | | | |
++++ ++++ ++++
Figure 8.1. Simple one-to-many scenario.
图8.1。简单的一对多场景。
In the simple one-to-many scenario, a server is streaming to a small group of clients. RTSP or SIP is used for the registration and the key management set up. The streaming server acts as the Initiator of MIKEY. In this scenario, the pre-shared key or public key transport mechanism will be appropriate in transporting the same TGK to all the clients (which will result in common TEKs for the group).
在简单的一对多场景中，服务器流式传输到一小群客户端。RTSP或SIP用于注册和密钥管理设置。流媒体服务器充当MIKEY的启动器。在这种情况下，预共享密钥或公钥传输机制将适用于将相同的TGK传输到所有客户端（这将导致组的公共TEK）。
Note, if the same TGK/TEK(s) should be used by all the group members, the streaming server MUST specify the same CSB_ID and CS_ID(s) for the session to all the group members.
注意，如果所有组成员都应使用相同的TGK/TEK，则流媒体服务器必须为所有组成员的会话指定相同的CSB_ID和CS_ID。
As the communication may be performed using multicast, the members need a common security policy if they want to be part of the group. This limits the possibility of negotiation.
由于可以使用多播执行通信，因此如果成员想要成为组的一部分，则他们需要公共安全策略。这限制了谈判的可能性。
Furthermore, the Initiator should carefully consider whether to request the verification message in reply from each receiver, as this may result in a certain load for the Initiator itself as the group size increases.
此外，发起者应该仔细考虑是否从每个接收器应答请求的验证消息，因为这可能导致作为组大小增加的发起人自身的特定负载。
As described in the overview section, for small-size interactive groups, one may expect that each client will be in charge for setting up the security for its outgoing streams. In these scenarios, the pre-shared key or the public-key transport method is used.
如概述部分所述，对于小型交互组，可以预期每个客户端将负责为其传出流设置安全性。在这些场景中，使用预共享密钥或公钥传输方法。
++++ ++++
|A | -------> |B |
| | <------- | |
++++ ++++
^ | | ^
| | | |
| | ++++ | |
| --->|C |<--- |
------| |------
++++
++++ ++++
|A | -------> |B |
| | <------- | |
++++ ++++
^ | | ^
| | | |
| | ++++ | |
| --->|C |<--- |
------| |------
++++
Figure 8.2. Small-size group without a centralized controller.
图8.2。没有集中控制器的小型组。
One scenario may then be that the client sets up a three-part call, using SIP. Due to the small size of the group, unicast SRTP is used between the clients. Each client sets up the security for its outgoing stream(s) to the others.
一种情况可能是客户端使用SIP建立一个由三部分组成的调用。由于组的规模较小，在客户端之间使用单播SRTP。每个客户端为其发送到其他客户端的流设置安全性。
As for the simple one-to-many case, the streaming client specifies the same CSB_ID and CS_ID(s) for its outgoing sessions if the same TGK/TEK(s) is used for all the group members.
对于简单的一对多情况，如果对所有组成员使用相同的TGK/TEK，则流式客户端为其传出会话指定相同的CSB_ID和CS_ID。
Key management protocols based on timestamps/counters and one-roundtrip key transport have previously been standardized, for example ISO [ISO1, ISO2]. The general security of these types of protocols can be found in various articles and literature, c.f. [HAC, AKE, LOA].
基于时间戳/计数器和一个往返密钥传输的密钥管理协议以前已经标准化，例如ISO[ISO1，ISO2]。这些类型协议的一般安全性可以在各种文章和文献中找到，c.f.[HAC，AKE，LOA]。
No chain is stronger than its weakest link. If a given level of protection is wanted, then the cryptographic functions protecting the keys during transport/exchange MUST offer a security corresponding to at least that level.
没有一条链条比它最薄弱的一环更牢固。如果需要给定的保护级别，则在传输/交换期间保护密钥的加密功能必须提供至少与该级别对应的安全性。
For instance, if a security against attacks with a complexity 2^96 is wanted, then one should choose a secure symmetric cipher supporting at least 96 bit keys (128 bits may be a practical choice) for the actual media protection, and a key transport mechanism that provides equivalent protection, e.g., MIKEY's pre-shared key transport with 128 bit TGK, or RSA with 1024 bit keys (which according to [LV] corresponds to the desired 96 bit level, with some margin).
例如，如果需要针对复杂度为2^96的攻击的安全性，则应选择支持至少96位密钥（128位可能是实际选择）的安全对称密码进行实际媒体保护，以及提供等效保护的密钥传输机制，例如。，MIKEY使用128位TGK的预共享密钥传输，或使用1024位密钥的RSA（根据[LV]对应于所需的96位级别，有一定的余量）。
In summary, key size for the key-exchange mechanism MUST be weighed against the size of the exchanged TGK so that it at least offers the required level. For efficiency reasons, one SHOULD also avoid a
总之，密钥交换机制的密钥大小必须与交换的TGK的大小进行权衡，以便它至少提供所需的级别。出于效率原因，还应避免
security overkill, e.g., by not using a public key transport with public keys giving a security level that is orders of magnitude higher than length of the transported TGK. We refer to [LV] for concrete key size recommendations.
安全性过高，例如，不使用公钥传输，公钥的安全级别比传输的TGK的长度高几个数量级。我们参考[LV]了解具体的键尺寸建议。
Moreover, if the TGKs are not random (or pseudo-random), a brute force search may be facilitated, again lowering the effective key size. Therefore, care MUST be taken when designing the (pseudo-) random generators for TGK generation, see [FIPS][RAND].
此外，如果tgk不是随机的（或伪随机的），则可以促进蛮力搜索，再次降低有效密钥大小。因此，在设计用于TGK生成的（伪）随机生成器时必须小心，请参见[FIPS][RAND]。
For the selection of the hash function, SHA-1 with 160-bit output is the default one. In general, hash sizes should be twice the "security level", indicating that SHA-1-256, [SHA256], should be used for the default 128-bit level. However, due to the real-time aspects in the scenarios we are treating, hash sizes slightly below 256 are acceptable, as the normal "existential" collision probabilities would be of secondary importance.
对于哈希函数的选择，具有160位输出的SHA-1是默认值。通常，散列大小应该是“安全级别”的两倍，这表示默认128位级别应该使用SHA-1-256[SHA256]。然而，由于我们正在处理的场景中的实时性，哈希大小稍微低于256是可以接受的，因为正常的“存在”冲突概率是次要的。
In a Crypto Session Bundle, the Crypto Sessions can share the same TGK as discussed earlier. From a security point of view, to satisfy the criterion in case the TGK is shared, the encryption of the individual Crypto Sessions are performed "independently". In MIKEY, this is accomplished by having unique Crypto Session identifiers (see also Section 4.1) and a TEK derivation method that provides cryptographically independent TEKs to distinct Crypto Sessions (within the Crypto Session Bundle), regardless of the security protocol used.
在加密会话捆绑包中，加密会话可以共享前面讨论的相同TGK。从安全性的角度来看，为了在共享TGK的情况下满足标准，各个加密会话的加密“独立”执行。在MIKEY中，这是通过具有唯一的加密会话标识符（另请参见第4.1节）和TEK派生方法来实现的，该方法为不同的加密会话（在加密会话捆绑包中）提供加密独立的TEK，而不考虑使用的安全协议。
Specifically, the key derivations, as specified in Section 4.1, are implemented by a pseudo-random function. The one used here is a simplified version of that used in TLS [TLS]. Here, only one single hash function is used, whereas TLS uses two different functions. This choice is motivated by the high confidence in the SHA-1 hash function, and by efficiency and simplicity of design (complexity does not imply security). Indeed, as shown in [DBJ], if one of the two hashes is severely broken, the TLS PRF is actually less secure than as if a single hash had been used on the whole key, as is done in MIKEY.
具体而言，第4.1节中规定的密钥派生由伪随机函数实现。这里使用的是TLS[TLS]中使用的简化版本。这里只使用一个散列函数，而TLS使用两个不同的函数。这种选择的动机是对SHA-1哈希函数的高度信任，以及设计的效率和简单性（复杂性并不意味着安全性）。事实上，如[DBJ]所示，如果两个散列中的一个被严重破坏，那么TLS PRF实际上不如在整个密钥上使用单个散列那样安全，就像在MIKEY中所做的那样。
In the pre-shared key and public-key schemes, the TGK is generated by a single party (Initiator). This makes MIKEY somewhat more sensitive if the Initiator uses a bad random number generator. It should also be noted that neither the pre-shared nor the public-key scheme provides perfect forward secrecy. If mutual contribution or perfect forward secrecy is desired, the Diffie-Hellman method is to be used. Authentication (e.g., signatures) in the Diffie-Hellman method is required to prevent man-in-the-middle attacks.
在预共享密钥和公钥方案中，TGK由一方（发起方）生成。如果启动器使用错误的随机数生成器，这会使MIKEY更加敏感。还应注意的是，无论是预共享还是公钥方案都不能提供完美的前向保密性。如果需要相互贡献或完全前向保密，则应使用Diffie-Hellman方法。Diffie-Hellman方法中的身份验证（例如签名）是防止中间人攻击所必需的。
Forward/backward security: if the TGK is exposed, all generated TEKs are compromised. However, under the assumption that the derivation function is a pseudo-random function, disclosure of an individual TEK does not compromise other (previous or later) TEKs derived from the same TGK. The Diffie-Hellman mode can be considered by cautious users, as it is the only one that supports so called perfect forward secrecy (PFS). This is in contrast to a compromise of the pre-shared key (or the secret key of the public key mode), where future sessions and recorded sessions from the past are then also compromised.
前向/后向安全性：如果TGK暴露，则所有生成的TEK都会被破坏。然而，在推导函数是伪随机函数的假设下，单个TEK的公开不会损害从相同TGK推导的其他（先前或之后）TEK。谨慎的用户可以考虑Diffie-Hellman模式，因为它是唯一支持所谓的完美前向保密（PFS）的模式。这与预共享密钥（或公钥模式的秘密密钥）的泄露形成对比，在这种情况下，将来的会话和过去记录的会话也会被泄露。
The use of random nonces (RANDs) in the key derivation is of utmost importance to counter off-line pre-computation attacks. Note however that update messages re-use the old RAND. This means that the total effective key entropy (relative to pre-computation attacks) for k consecutive key updates, assuming the TGKs and RAND are each n bits long, is about L = n*(k+1)/2 bits, compared to the theoretical maximum of n*k bits. In other words, a 2^L work effort MAY enable an attacker to get all k n-bit keys, which is better than brute force (except when k = 1). While this might seem like a defect, first note that for a proper choice of n, the 2^L complexity of the attack is way out of reach. Moreover, the fact that more than one key can be compromised in a single attack is inherent to the key exchange problem. Consider for instance a user who, using a fixed 1024-bit RSA key, exchanges keys and communicates during a one or two year lifetime of the public key. Breaking this single RSA key will enable access to all exchanged keys and consequently the entire communication of that user over the whole period.
在密钥推导中使用随机nonce（RANDs）对于抵抗离线预计算攻击至关重要。但是请注意，更新消息重新使用旧的RAND。这意味着，与n*k比特的理论最大值相比，假设tgk和RAND各为n比特长，k个连续密钥更新的总有效密钥熵（相对于计算前攻击）约为L＝n*（k+1）/2比特。换句话说，一个2^L的工作可能使攻击者获得所有k n位密钥，这比暴力（k=1时除外）要好。虽然这似乎是一个缺陷，但首先要注意的是，对于n的正确选择，攻击的2^L复杂性是无法达到的。此外，在一次攻击中可以泄露多个密钥的事实是密钥交换问题固有的。例如，使用一个固定的1024位RSA密钥的用户，在公钥的一年或两年寿命期间交换密钥并进行通信。打破这个单一的RSA密钥将允许访问所有交换的密钥，从而在整个时间段内访问该用户的整个通信。
All the pre-defined transforms in MIKEY use state-of-the-art algorithms that have undergone large amounts of public evaluation. One of the reasons for using the AES-CM from SRTP [SRTP], is to have the possibility of limiting the overall number of different encryption modes and algorithms, while offering a high level of security at the same time.
MIKEY中的所有预定义转换都使用经过大量公开评估的最先进算法。使用SRTP[SRTP]中的AES-CM的原因之一是有可能限制不同加密模式和算法的总数，同时提供高级别的安全性。
Even if the lifetime of a TGK (or TEK) is not specified, it MUST be taken into account that the encryption transform in the underlying security protocol can in some way degenerate after a certain amount of encrypted data. It is not possible to here state universally applicable, general key lifetime bounds; each security protocol should define such maximum amount and trigger a re-keying procedure before the "exhaustion" of the key. For example, according to SRTP [SRTP] the TEK, together with the corresponding TGK, MUST be changed at least every 2^48 SRTP packet.
即使未指定TGK（或TEK）的生存期，也必须考虑到，在一定数量的加密数据之后，基础安全协议中的加密转换可能以某种方式退化。这里不可能说明普遍适用的通用密钥生存期界限；每个安全协议都应该定义这样的最大数量，并在密钥“耗尽”之前触发一个重新设置密钥的过程。例如，根据SRTP[SRTP]，TEK以及相应的TGK必须至少每2^48个SRTP数据包更改一次。
Still, the following can be said as a rule of thumb. If the security protocol uses an "ideal" b-bit block cipher (in CBC mode, counter mode, or a feedback mode, e.g., OFB, with full b-bit feedback), degenerate behavior in the crypto stream, possibly useful for an attacker, is (with constant probability) expected to occur after a total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs). For security margin, re-keying MUST be triggered well in advance compared to the above bound. See [BDJR] for more details.
不过，以下几点可以说是经验法则。如果安全协议使用“理想”b位分组密码（在CBC模式、计数器模式或反馈模式下，例如OFB，具有完全b位反馈），则在总共大约2^（b/2）个加密b位块（使用随机IVs）之后，预计会发生加密流中可能对攻击者有用的退化行为（以恒定概率）。对于安全余量，与上述界限相比，必须提前触发重设密钥。有关更多详细信息，请参见[BDJR]。
For use of a dedicated stream cipher, we refer to the analysis and documentation of said cipher in each specific case.
对于专用流密码的使用，我们参考每个特定情况下所述密码的分析和文档。
The use of timestamps, instead of challenge-responses, requires the systems to have synchronized clocks. Of course, if two clients are not synchronized, they will have difficulties in setting up the security. The current timestamp based solution has been selected to allow a maximum of one roundtrip (i.e., two messages), but still provide a reasonable replay protection. A (secure) challenge-response based version would require at least three messages. For a detailed description of the timestamp and replay handling in MIKEY, see Section 5.4.
使用时间戳而不是质询响应要求系统具有同步时钟。当然，如果两个客户端不同步，它们将难以设置安全性。已选择当前基于时间戳的解决方案，以允许最多一次往返（即两条消息），但仍提供合理的重播保护。基于（安全）质询响应的版本至少需要三条消息。有关MIKEY中时间戳和重播处理的详细说明，请参见第5.4节。
Practical experiences of Kerberos and other timestamp-based systems indicate that it is not always necessary to synchronize the terminals over the network. Manual configuration could be a feasible alternative in many cases (especially in scenarios where the degree of looseness is high). However, the choice must be made carefully with respect to the usage scenario.
Kerberos和其他基于时间戳的系统的实际经验表明，并不总是需要通过网络同步终端。在许多情况下（特别是在松动程度较高的情况下），手动配置可能是一种可行的选择。但是，必须根据使用场景仔细选择。
User privacy is a complex matter that to some extent can be enforced by cryptographic mechanisms, but also requires policy enforcement and various other functionalities. One particular facet of privacy is user identity protection. However, identity protection was not a main design goal for MIKEY. Such a feature will add more complexity to the protocol and was therefore not chosen to be included. As MIKEY is anyway proposed to be transported over, e.g., SIP, the identity may be exposed by this. However, if the transporting protocol is secured and also provides identity protection, MIKEY might inherit the same feature. How this should be done is for future study.
用户隐私是一个复杂的问题，在某种程度上可以通过加密机制强制执行，但也需要策略强制执行和各种其他功能。隐私的一个特殊方面是用户身份保护。然而，身份保护并不是MIKEY的主要设计目标。这样的功能将增加协议的复杂性，因此未选择将其包括在内。由于无论如何都建议通过SIP传输MIKEY，因此身份可能会由此暴露。但是，如果传输协议是安全的，并且还提供身份保护，MIKEY可能会继承相同的功能。如何做到这一点有待于将来的研究。
This protocol is resistant to Denial of Service attacks in the sense that a Responder does not construct any state (at the key management protocol level) before it has authenticated the Initiator. However, this protocol, like many others, is open to attacks that use spoofed IP addresses to create a large number of fake requests. This may for example, be solved by letting the protocol transporting MIKEY do an IP address validity test. The SIP protocol can provide this using the anonymous authentication challenge mechanism (specified in Section 22.1 of [SIP]).
该协议能够抵抗拒绝服务攻击，因为响应者在对启动器进行身份验证之前不会构造任何状态（在密钥管理协议级别）。然而，与其他许多协议一样，该协议也容易受到攻击，这些攻击使用伪造的IP地址来创建大量虚假请求。例如，这可以通过让传输MIKEY的协议进行IP地址有效性测试来解决。SIP协议可以使用匿名身份验证质询机制（在[SIP]第22.1节中指定）提供此功能。
It is highly RECOMMENDED to include IDr in the Initiator's message. If not included, its absence can be used for DoS purposes (the largest DoS-impact being on the public key and DH methods), where a message intended for other entities is sent to the target. In fact, the target may verify the signature correctly due to the fact that the Initiator's ID is correct and the message is actually signed by the claimed Initiator (e.g., by re-directing traffic from another session).
强烈建议在启动器消息中包含IDr。如果未包括在内，则其缺失可用于DoS目的（DoS对公钥和DH方法的最大影响），其中发送给其他实体的消息到目标。事实上，目标可以正确地验证签名，因为发起方的ID是正确的，并且消息实际上是由声称的发起方签名的（例如，通过重新定向来自另一会话的通信量）。
However, in the public key method, the envelop key and the MAC will ensure that the message is not accepted (still, compared to a normal faked message, where the signature verification would detect the problem, one extra public key decryption is needed to detect the problem in this case).
然而，在公钥方法中，信封密钥和MAC将确保消息不被接受（仍然，与普通伪造消息相比，签名验证将检测问题，在这种情况下，需要一个额外的公钥解密来检测问题）。
In the DH method, a message would be accepted (without detecting the error) and a response (and state) would be created for the malicious request.
在DH方法中，将接受消息（不检测错误），并为恶意请求创建响应（和状态）。
As also discussed in Section 5.4, the tradeoff between time synchronization and the size of the replay cache may be affected in case of for example, a flooding DoS attack. However, if the recommendations of using a dynamic size of the replay cache are followed, it is believed that the client will in most cases be able to handle the replay cache. Of course, as the replay cache decreases in size, the required time synchronization is more restricted. However, a bigger problem during such an attack would probably be to process the messages (e.g., verify signatures/MACs) due to the computational workload this implies.
如第5.4节所述，例如，在发生泛洪DoS攻击的情况下，时间同步和重播缓存大小之间的权衡可能会受到影响。但是，如果遵循使用动态大小的replay缓存的建议，则相信客户端在大多数情况下都能够处理replay缓存。当然，随着replay缓存大小的减小，所需的时间同步会受到更多限制。然而，由于这意味着计算工作量，在此类攻击期间更大的问题可能是处理消息（例如，验证签名/MAC）。
It should be noted that if the session establishment protocol is insecure, there may be attacks on this that will have indirect security implications on the secured media streams. This however only applies to groups (and is not specific to MIKEY). The threat is
应当注意，如果会话建立协议不安全，则可能存在对该协议的攻击，这将对安全媒体流产生间接的安全影响。但是，这仅适用于团体（而不是特定于MIKEY）。威胁是
that one group member may re-direct a stream from one group member to another. This will have the same implication as when a member tries to impersonate another member, e.g., by changing its IP address. If this is seen as a problem, it is RECOMMENDED that a Data Origin Authentication (DOA) scheme (e.g., digital signatures) be applied to the security protocol.
一个组成员可以将流从一个组成员重新定向到另一个组成员。这与成员试图模拟另一个成员（例如，通过更改其IP地址）时具有相同的含义。如果这被视为一个问题，建议将数据源身份验证（DOA）方案（例如，数字签名）应用于安全协议。
Re-direction of streams can of course be done even if it is not a group. However, the effect will not be the same as compared to a group where impersonation can be done if DOA is not used. Instead, re-direction will only deny the receiver the possibility of receiving (or just delay) the data.
当然，即使不是一个组，也可以重新定向流。但是，与不使用DOA时可以进行模拟的组相比，效果将不同。相反，重定向只会拒绝接收器接收（或延迟）数据的可能性。
This document defines several new name spaces associated with the MIKEY payloads. This section summarizes the name spaces for which IANA is requested to manage the allocation of values. IANA is requested to record the pre-defined values defined in the given sections for each name space. IANA is also requested to manage the definition of additional values in the future. Unless explicitly stated otherwise, values in the range 0-240 for each name space SHOULD be approved by the process of IETF consensus and values in the range 241-255 are reserved for Private Use, according to [RFC2434].
本文档定义了几个与MIKEY有效负载相关的新名称空间。本节总结了请求IANA管理值分配的名称空间。IANA被要求记录给定章节中为每个名称空间定义的预定义值。IANA还被要求在将来管理附加值的定义。除非另有明确规定，否则每个名称空间0-240范围内的值应通过IETF协商一致程序批准，241-255范围内的值根据[RFC2434]保留供私人使用。
The name spaces for the following fields in the Common header payload (from Section 6.1) are requested to be managed by IANA (in bracket is the reference to the table with the initially registered values):
公共标头有效载荷（第6.1节）中以下字段的名称空间要求由IANA管理（括号中是对具有初始注册值的表的引用）：
* version
* 版本
* data type (Table 6.1.a)
* 数据类型（表6.1.a）
* Next payload (Table 6.1.b)
* 下一有效载荷（表6.1.b）
* PRF func (Table 6.1.c). This name space is between 0-127, where values between 0-111 should be approved by the process of IETF consensus and values between 112-127 are reserved for Private Use.
* PRF func（表6.1.c）。该名称空间在0-127之间，其中0-111之间的值应通过IETF协商一致的过程批准，112-127之间的值保留供私人使用。
* CS ID map type (Table 6.1.d)
* CS ID地图类型（表6.1.d）
The name spaces for the following fields in the Key data transport payload (from Section 6.2) are requested to be managed by IANA:
关键数据传输有效载荷（第6.2节）中以下字段的名称空间要求由IANA管理：
* Encr alg (Table 6.2.a)
* 附件alg（表6.2.a）
* MAC alg (Table 6.2.b)
* MAC alg（表6.2.b）
The name spaces for the following fields in the Envelope data payload (from Section 6.3) are requested to be managed by IANA:
信封数据有效载荷（第6.3节）中以下字段的名称空间由IANA管理：
* C (Table 6.3)
* C（表6.3）
The name spaces for the following fields in the DH data payload (from Section 6.4) are requested to be managed by IANA:
DH数据有效载荷（第6.4节）中以下字段的名称空间要求由IANA管理：
* DH-Group (Table 6.4)
* DH组（表6.4）
The name spaces for the following fields in the Signature payload (from Section 6.5) are requested to be managed by IANA:
签名有效载荷（第6.5节）中以下字段的名称空间要求由IANA管理：
* S type (Table 6.5)
* S型（表6.5）
The name spaces for the following fields in the Timestamp payload (from Section 6.6) are requested to be managed by IANA:
IANA要求管理时间戳有效负载（第6.6节）中以下字段的名称空间：
* TS type (Table 6.6)
* TS类型（表6.6）
The name spaces for the following fields in the ID payload and the Certificate payload (from Section 6.7) are requested to be managed by IANA:
请求IANA管理ID有效负载和证书有效负载（第6.7节）中以下字段的名称空间：
* ID type (Table 6.7.a)
* ID类型（表6.7.a）
* Cert type (Table 6.7.b)
* 证书类型（表6.7.b）
The name spaces for the following fields in the Cert hash payload (from Section 6.8) are requested to be managed by IANA:
证书哈希有效载荷（第6.8节）中以下字段的名称空间要求由IANA管理：
* Hash func (Table 6.8)
* 哈希函数（表6.8）
The name spaces for the following fields in the Security policy payload (from Section 6.10) are requested to be managed by IANA:
安全策略有效负载（第6.10节）中以下字段的名称空间要求由IANA管理：
* Prot type (Table 6.10)
* 保护类型（表6.10）
For each security protocol that uses MIKEY, a set of unique parameters MAY be registered.
对于使用MIKEY的每个安全协议，可以注册一组唯一的参数。
From Section 6.10.1.
参见第6.10.1节。
* SRTP Type (Table 6.10.1.a)
* SRTP类型（表6.10.1.a）
* SRTP encr alg (Table 6.10.1.b)
* SRTP encr alg（表6.10.1.b）
* SRTP auth alg (Table 6.10.1.c)
* SRTP认证alg（表6.10.1.c）
* SRTP PRF (Table 6.10.1.d)
* SRTP PRF（表6.10.1.d）
* FEC order (Table 6.10.1.e)
* FEC订单（表6.10.1.e）
The name spaces for the following fields in the Error payload (from Section 6.12) are requested to be managed by IANA:
错误有效负载（第6.12节）中以下字段的名称空间由IANA管理：
* Error no (Table 6.12)
* 错误号（表6.12）
The name spaces for the following fields in the Key data payload (from Section 6.13) are requested to be managed by IANA:
关键数据有效载荷（第6.13节）中以下字段的名称空间要求由IANA管理：
* Type (Table 6.13.a). This name space is between 0-16, which should be approved by the process of IETF consensus.
* 类型（表6.13.a）。该名称空间介于0-16之间，应通过IETF协商一致的过程进行批准。
* KV (Table 6.13.b). This name space is between 0-16, which should be approved by the process of IETF consensus.
* KV（表6.13.b）。该名称空间介于0-16之间，应通过IETF协商一致的过程进行批准。
The name spaces for the following fields in the General Extensions payload (from Section 6.15) are requested to be managed by IANA:
请求IANA管理通用扩展有效负载（第6.15节）中以下字段的名称空间：
* Type (Table 6.15).
* 类型（表6.15）。
This section gives instructions to IANA to register the application/mikey MIME media type. This registration is as follows:
本节指导IANA注册应用程序/mikey MIME媒体类型。本次登记如下：
MIME media type name : application MIME subtype name : mikey Required parameters : none Optional parameters : version version: The MIKEY version number of the enclosed message (e.g., 1). If not present, the version defaults to 1. Encoding Considerations : binary, base64 encoded Security Considerations : see section 9 in this memo Interoperability considerations : none Published specification : this memo
MIME媒体类型名称：应用程序MIME子类型名称：mikey必需参数：无可选参数：版本版本：所附消息的mikey版本号（例如，1）。如果不存在，则版本默认为1。编码注意事项：二进制、base64编码的安全注意事项：参见本备忘录第9节互操作性注意事项：未发布规范：本备忘录
The authors would like to thank Mark Baugher, Ran Canetti, Martin Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov Vatn, Erik Eliasson, and Gerhard Strangar for their valuable feedback.
作者要感谢马克·鲍格尔、兰·卡内蒂、马丁·欧希纳、史蒂芬·弗里斯、彼得·巴拉尼、罗斯·霍斯利、帕西·阿霍宁（及其团队）、罗尔夫·布洛姆、马格努斯·维斯特隆德、约翰·比林、乔恩·奥洛夫·瓦顿、埃里克·埃利亚松和格哈德·斯特兰加提供的宝贵反馈。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[NAI]Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[OAKLEY]Orman，H.，“OAKLEY密钥确定协议”，RFC 2412，1998年11月。
[PSS] PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories, June 14, 2002, www.rsalabs.com
[PSS]PKCS#1 v2.1-RSA加密标准，RSA实验室，2002年6月14日，www.rsalabs.com
[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月。
[SHA-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[SHA-1]NIST，FIPS PUB 180-1：安全哈希标准，1995年4月。
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real Time Transport Protocol", RFC 3711, March 2004.
[SRTP]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议”，RFC 37112004年3月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[X.509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[X.509]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[AESKW] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AESKW]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，2002年9月。
[AKE] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange Protocols and their use for Building Secure Channels", Eurocrypt 2001, LNCS 2054, pp. 453-474, 2001.
[AKE]Canetti，R.和H.Krawczyk，“密钥交换协议及其用于构建安全通道的分析”，Eurocrypt 2001，LNCS 2054，第453-4742001页。
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes of Operation", in Proceedings of the 38th Symposium on Foundations of Computer Science, IEEE, 1997, pp. 394-403.
[BDJR]Bellare，M.，Desai，A.，Jokipii，E.，和P.Rogaway，“对称加密的具体分析：DES操作模式的分析”，载于第38届计算机科学基础研讨会论文集，IEEE，1997年，第394-403页。
[BMGL] Hastad, J. and M. Naslund: "Practical Construction and Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt 2001, LNCS. vol 2248, pp. 442-459, 2001.
[BMGL]Hastad，J.和M.Naslund：“伪随机原语的实际构造和分析”，《亚洲加密会议录》，2001年，LNCS。第2248卷，第442-459页，2001年。
[DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of MD5", Contribution to ANSI X9F1 WG, 2001.
[DBJ]Johnson，D.B.，“TLS使用MD5的理论安全问题”，对ANSI X9F1工作组的贡献，2001年。
[FIPS] "Security Requirements for Cryptographic Modules", Federal Information Processing Standard Publications (FIPS PUBS) 140-2, December 2002.
[FIPS]“加密模块的安全要求”，联邦信息处理标准出版物（FIPS PUBS）140-22002年12月。
[GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Group Key Management Architecture", Work in Progress.
[GKParch]Baugher，M.，Canetti，R.，Dondeti，L.，和F.Lindholm，“集团密钥管理架构”，正在进行中。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[GDOI]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and R. Fleischer, "Group Secure Association Key Management Protocol", Work in Progress.
[GSAKMP]Harney，H.，Colegrove，A.，Harder，E.，Meth，U.，和R.Fleischer，“组安全关联密钥管理协议”，工作正在进行中。
[HAC] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC press, 1996.
[HAC]Menezes，A.，van Oorschot，P.，和S.Vanstone，“应用密码学手册”，CRC出版社，1996年。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[ISO1] ISO/IEC 9798-3: 1997, Information technology - Security techniques - Entity authentication - Part 3: Mechanisms using digital signature techniques.
[ISO1]ISO/IEC 9798-3:1997，信息技术-安全技术-实体认证-第3部分：使用数字签名技术的机制。
[ISO2] ISO/IEC 11770-3: 1997, Information technology - Security techniques - Key management - Part 3: Mechanisms using digital signature techniques.
[ISO2]ISO/IEC 11770-3:1997，信息技术-安全技术-密钥管理-第3部分：使用数字签名技术的机制。
[ISO3] ISO/IEC 18014 Information technology - Security techniques - Time-stamping services, Part 1-3.
[ISO3]ISO/IEC 18014信息技术-安全技术-时间戳服务，第1-3部分。
[KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for SDP and RTSP", Work in Progress.
[KMASDP]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“SDP和RTSP的密钥管理扩展”，正在进行中。
[LOA] Burrows, Abadi, and Needham, "A logic of authentication", ACM Transactions on Computer Systems 8 No.1 (Feb. 1990), 18-36.
[LOA]Burrows、Abadi和Needham，“身份验证的逻辑”，计算机系统上的ACM交易8第1期（1990年2月），18-36。
[LV] Lenstra, A. K. and E. R. Verheul, "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[LV] Lenstra, A. K. and E. R. Verheul, "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[NTP] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[NTP]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC13051992年3月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[RAND] Eastlake, 3rd, D., Crocker, S., and J. Schiller, "Randomness Requirements for Security", RFC 1750, December 1994.
[RAND]Eastlake，3rd，D.，Crocker，S.，和J.Schiller，“安全的随机性要求”，RFC 1750，1994年12月。
[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月。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",
http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf
[SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",
http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf
[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月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议-版本1.0”，RFC 2246，1999年1月。
The terminology in MIKEY differs from the one used in SRTP as MIKEY needs to be more general, nor is tight to SRTP only. Therefore, it might be hard to see the relations between keys and parameters generated in MIKEY and those used by SRTP. This section provides some hints on their relation.
MIKEY中的术语与SRTP中使用的术语不同，因为MIKEY需要更为通用，也不仅仅限于SRTP。因此，可能很难看到MIKEY中生成的键和参数与SRTP使用的键和参数之间的关系。本节提供了有关它们之间关系的一些提示。
MIKEY | SRTP
-------------------------------------------------
Crypto Session | SRTP stream (typically with related SRTCP stream)
Data SA | input to SRTP's crypto context
TEK | SRTP master key
MIKEY | SRTP
-------------------------------------------------
Crypto Session | SRTP stream (typically with related SRTCP stream)
Data SA | input to SRTP's crypto context
TEK | SRTP master key
The Data SA is built up by a TEK and the security policy exchanged. SRTP may use an MKI to index the TEK or TGK (the TEK is then derived from the TGK that is associated with the corresponding MKI), see below.
数据SA由TEK建立，并交换安全策略。SRTP可使用MKI对TEK或TGK进行索引（TEK随后从与相应MKI相关联的TGK中派生），见下文。
In the following, we give a brief outline of the interface between SRTP and MIKEY and the processing that takes place. We describe the SRTP receiver side only, the sender side will require analogous interfacing.
下面，我们将简要介绍SRTP和MIKEY之间的接口以及发生的处理。我们仅描述SRTP接收方，发送方将需要类似的接口。
1. When an SRTP packet arrives at the receiver and is processed, the triple <SSRC, destination address, destination port> is extracted from the packet and used to retrieve the correct SRTP crypto context, hence the Data SA. (The actual retrieval can, for example, be done by an explicit request from the SRTP implementation to MIKEY, or, by the SRTP implementation accessing a "database", maintained by MIKEY. The application will typically decide which implementation is preferred.)
1. 当SRTP数据包到达接收器并被处理时，从该数据包中提取三重<SSRC，目的地地址，目的地端口>，并用于检索正确的SRTP加密上下文，从而获得数据SA。（例如，实际检索可以通过SRTP实现向MIKEY发出显式请求来完成，或者通过SRTP实现访问MIKEY维护的“数据库”来完成。应用程序通常会决定首选哪个实现。）
2. If an MKI is present in the SRTP packet, it is used to point to the correct key within the SA. Alternatively, if SRTP's <From, To> feature is used, the ROC||SEQ of the packet is used to determine the correct key.
2. 如果SRTP数据包中存在MKI，则它用于指向SA中的正确密钥。或者，如果使用SRTP的<From，To>特性，则使用数据包的ROC | | SEQ来确定正确的密钥。
3. Depending on whether the key sent in MIKEY (as obtained in step 2) was a TEK or a TGK, there are now two cases.
3. 根据MIKEY中发送的密钥（在步骤2中获得）是TEK还是TGK，现在有两种情况。
- If the key obtained in step 2 is the TEK itself, it is used directly by SRTP as a master key.
- 如果在步骤2中获得的密钥是TEK本身，则SRTP直接将其用作主密钥。
- If the key instead is a TGK, the mapping with the CS_ID (internal to MIKEY, Section 6.1.1) allows MIKEY to compute the correct TEK from the TGK as described in Section 4.1 before SRTP uses it.
- 如果密钥是TGK，则具有CS_ID的映射（MIKEY内部，第6.1.1节）允许MIKEY在SRTP使用之前根据TGK计算正确的TEK，如第4.1节所述。
If multiple TGKs (or TEKs) are sent, it is RECOMMENDED that each TGK (or TEK) be associated with a distinct MKI. It is RECOMMENDED that the use of <From, To> in this scenario be limited to very simple cases, e.g., one stream only.
如果发送多个TGK（或TEK），建议每个TGK（或TEK）与不同的MKI相关联。建议在此场景中使用<From，To>，仅限于非常简单的情况，例如，仅一个流。
Besides the actual master key, other information in the Data SA (e.g., transform identifiers) will of course also be communicated from MIKEY to SRTP.
除了实际的主密钥之外，数据SA中的其他信息（例如，变换标识符）当然也将从MIKEY传送到SRTP。
Authors' Addresses
作者地址
Jari Arkko Ericsson Research 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 Ericsson Research SE-16480 Stockholm Sweden
Elisabetta Carrara Ericsson Research SE-16480瑞典斯德哥尔摩
Phone: +46 8 50877040
EMail: elisabetta.carrara@ericsson.com
Phone: +46 8 50877040
EMail: elisabetta.carrara@ericsson.com
Fredrik Lindholm Ericsson Research SE-16480 Stockholm Sweden
Fredrik Lindholm Ericsson Research 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 (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。