Network Working Group M. Euchner
Request for Comments: 4650 September 2006
Category: Standards Track
Network Working Group M. Euchner
Request for Comments: 4650 September 2006
Category: Standards Track
HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)
HMAC认证Diffie Hellman多媒体互联网密钥（MIKEY）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol MIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY.
本文档描述了RFC 3830中定义的多媒体互联网密钥（MIKEY）协议MIKEY的轻量级点对点密钥管理协议变体。特别是，该变体为密钥建立部署了经典的Diffie-Hellman密钥协商协议，该协议具有完美的前向保密性，并结合密钥散列消息认证码，以实现交换的密钥管理消息的相互认证和消息完整性。该协议解决了MIKEY中多媒体密钥管理的安全性和性能限制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Definitions ................................................5
1.2. Abbreviations ..............................................6
1.3. Conventions Used in This Document ..........................7
2. Scenario ........................................................7
2.1. Applicability ..............................................7
2.2. Relation to GKMARCH ........................................8
3. DHHMAC Security Protocol ........................................8
3.1. TGK Re-keying .............................................10
4. DHHMAC Payload Formats .........................................10
4.1. Common Header Payload (HDR) ..............................11
4.2. Key Data Transport Payload (KEMAC) ........................12
4.3. ID Payload (ID) ...........................................12
4.4. General Extension Payload .................................12
5. Security Considerations ........................................13
5.1. Security Environment ......................................13
5.2. Threat Model ..............................................13
5.3. Security Features and Properties ..........................15
5.4. Assumptions ...............................................19
5.5. Residual Risk .............................................20
5.6. Authorization and Trust Model .............................21
6. Acknowledgments ................................................21
7. IANA Considerations ............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
Appendix A. Usage of MIKEY-DHHMAC in H.235 ........................25
1. Introduction ....................................................2
1.1. Definitions ................................................5
1.2. Abbreviations ..............................................6
1.3. Conventions Used in This Document ..........................7
2. Scenario ........................................................7
2.1. Applicability ..............................................7
2.2. Relation to GKMARCH ........................................8
3. DHHMAC Security Protocol ........................................8
3.1. TGK Re-keying .............................................10
4. DHHMAC Payload Formats .........................................10
4.1. Common Header Payload (HDR) ..............................11
4.2. Key Data Transport Payload (KEMAC) ........................12
4.3. ID Payload (ID) ...........................................12
4.4. General Extension Payload .................................12
5. Security Considerations ........................................13
5.1. Security Environment ......................................13
5.2. Threat Model ..............................................13
5.3. Security Features and Properties ..........................15
5.4. Assumptions ...............................................19
5.5. Residual Risk .............................................20
5.6. Authorization and Trust Model .............................21
6. Acknowledgments ................................................21
7. IANA Considerations ............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
Appendix A. Usage of MIKEY-DHHMAC in H.235 ........................25
There is work done in IETF to develop key management schemes. For example, IKE [12] is a widely accepted unicast scheme for IPsec, and the MSEC WG is developing other schemes, addressed to group communication [17], [18]. For reasons discussed below, there is, however, a need for a scheme with low latency, suitable for demanding cases such as real-time data over heterogeneous networks and small interactive groups.
IETF中已经完成了开发密钥管理方案的工作。例如，IKE[12]是一种广泛接受的IPsec单播方案，MSEC WG正在开发其他方案，用于组通信[17]，[18]。然而，出于下面讨论的原因，需要一种低延迟的方案，适合于要求苛刻的情况，例如异构网络和小型交互组上的实时数据。
As pointed out in MIKEY (see [2]), secure real-time multimedia applications demand a particular adequate lightweight key management scheme that takes care to establish dynamic session keys securely and efficiently in a conversational multimedia scenario.
正如MIKEY（见[2]）所指出的，安全的实时多媒体应用程序需要一种特殊的、充分的、轻量级的密钥管理方案，该方案能够在会话多媒体场景中安全有效地建立动态会话密钥。
In general, MIKEY scenarios cover peer-to-peer, simple one-to-many, and small-sized groups. MIKEY in particular describes three key
一般来说，MIKEY场景包括点对点、简单的一对多和小型组。MIKEY特别描述了三个关键问题
management schemes for the peer-to-peer case that all finish their task within one roundtrip:
在一次往返中完成任务的对等案例的管理方案：
- a symmetric key distribution protocol (MIKEY-PS) based on pre-shared master keys
- 基于预共享主密钥的对称密钥分发协议（MIKEY-PS）
- a public-key encryption-based key distribution protocol (MIKEY-PK and reverse-mode MIKEY-RSA-R [33]) assuming a public-key infrastructure with RSA-based (Rivest, Shamir and Adleman) private/public keys and digital certificates
- 一种基于公钥加密的密钥分发协议（MIKEY-PK和反向模式MIKEY-RSA-R[33]），假设公钥基础设施具有基于RSA的（Rivest、Shamir和Adleman）私钥/公钥和数字证书
- a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN) deploying digital signatures and certificates.
- 部署数字签名和证书的Diffie-Hellman密钥协商协议（MIKEY-DHSIGN）。
All of these three key management protocols are designed so that they complete their work within just one roundtrip. This requires depending on loosely synchronized clocks and deploying timestamps within the key management protocols.
所有这三个密钥管理协议的设计都是为了在一次往返中完成它们的工作。这需要依赖于松散同步的时钟，并在密钥管理协议中部署时间戳。
However, it is known [6] that each of the three key management schemes has its subtle constraints and limitations:
然而，众所周知[6]，三种密钥管理方案都有其微妙的约束和限制：
- The symmetric key distribution protocol (MIKEY-PS) is simple to implement; however, it was not intended to scale to support any configurations beyond peer-to-peer, simple one-to-many, and small-size (interactive) groups, due to the need for mutually pre-assigned shared master secrets.
- 对称密钥分配协议（MIKEY-PS）易于实现；但是，由于需要相互预先分配的共享主机密，因此它不打算扩展以支持点对点、简单的一对多和小规模（交互）组之外的任何配置。
Moreover, the security provided does not achieve the property of perfect forward secrecy; i.e., compromise of the shared master secret would render past and even future session keys susceptible to compromise.
此外，所提供的安全性不具备完全前向保密性；i、 例如，泄露共享主密钥会使过去甚至将来的会话密钥容易泄露。
Further, the generation of the session key happens just at the initiator. Thus, the responder has to fully trust the initiator to choose a good and secure session secret; the responder is able neither to participate in the key generation nor to influence that process. This is considered a specific limitation in less trusted environments.
此外，会话密钥的生成只发生在启动器上。因此，响应方必须完全信任发起方选择一个好的、安全的会话密钥；响应者既不能参与密钥生成，也不能影响该过程。在不太可信的环境中，这被认为是一个特定的限制。
- The public-key encryption scheme (MIKEY-PK and MIKEY-RSA-R [33]) depends upon a public-key infrastructure that certifies the private-public keys by issuing and maintaining digital certificates. While such key management schemes provide full scalability in large networked configurations, public-key infrastructures are still not widely available, and, in general, implementations are significantly more complex.
- 公钥加密方案（MIKEY-PK和MIKEY-RSA-R[33]）依赖于公钥基础设施，该基础设施通过颁发和维护数字证书来认证私有公钥。虽然这样的密钥管理方案在大型网络配置中提供了完全的可扩展性，但公钥基础设施仍然不广泛可用，而且总体而言，实现要复杂得多。
Further, additional roundtrips and computational processing might be necessary for each end system in order to ascertain verification of the digital certificates. For example, typical operations in the context of a public-key infrastructure may involve extra network communication handshakes with the public-key infrastructure and with certification authorities and may typically involve additional processing steps in the end systems. These operations would include validating digital certificates (RFC 3029, [24]), ascertaining the revocation status of digital certificates (RFC 2560, [23]), asserting certificate policies, construction of certification path(s) ([26]), requesting and obtaining necessary certificates (RFC 2511, [25]), and management of certificates for such purposes ([22]). Such steps and tasks all result in further delay of the key agreement or key establishment phase among the end systems, which negatively affects setup time. Any extra PKI handshakes and processing are not in the scope of MIKEY, and since this document only deploys symmetric security mechanisms, aspects of PKI, digital certificates, and related processing are not further covered in this document.
此外，为了确定数字证书的验证，每个终端系统可能需要额外的往返和计算处理。例如，公钥基础设施上下文中的典型操作可能涉及与公钥基础设施和与认证机构的额外网络通信握手，并且通常可能涉及终端系统中的附加处理步骤。这些操作包括验证数字证书（RFC 3029，[24]）、确定数字证书的吊销状态（RFC 2560，[23]）、断言证书策略、构建证书路径（[26]）、请求和获取必要的证书（RFC 2511，[25]），以及为此目的的证书管理（[22]）。这些步骤和任务都会导致终端系统之间的密钥协议或密钥建立阶段进一步延迟，从而对设置时间产生负面影响。任何额外的PKI握手和处理不在MIKEY的范围内，并且由于本文档仅部署对称安全机制，因此本文档不进一步介绍PKI、数字证书和相关处理的各个方面。
Finally, as in the symmetric case, the responder depends completely upon the initiator's choosing good and secure session keys.
最后，与对称情况一样，响应者完全依赖于启动器选择良好且安全的会话密钥。
- The third MIKEY-DHSIGN key management protocol deploys the Diffie-Hellman key agreement scheme and authenticates the exchange of the Diffie-Hellman half-keys in each direction by using a digital signature. This approach has the same advantages and deficiencies as described in the previous section in terms of a public-key infrastructure.
- 第三个MIKEY-DHSIGN密钥管理协议部署了Diffie-Hellman密钥协商方案，并通过使用数字签名来验证Diffie-Hellman半密钥在每个方向上的交换。这种方法在公钥基础设施方面具有与上一节所述相同的优点和缺点。
However, the Diffie-Hellman key agreement protocol is known for its subtle security strengths in that it is able to provide full perfect forward secrecy (PFS) and further have to both parties actively involved in session key generation. This special security property (despite the somewhat higher computational costs) makes Diffie-Hellman techniques attractive in practice.
然而，Diffie-Hellman密钥协商协议以其微妙的安全优势而闻名，因为它能够提供完全完美的前向保密（PFS），并且进一步必须让双方积极参与会话密钥生成。这种特殊的安全特性（尽管计算成本较高）使得Diffie-Hellman技术在实践中具有吸引力。
In order to overcome some of the limitations as outlined above, a special need has been recognized for another efficient key agreement protocol variant in MIKEY. This protocol variant aims to provide the capability of perfect forward secrecy as part of a key agreement with low latency without dependency on a public-key infrastructure.
为了克服上面概述的一些限制，我们已经认识到在MIKEY中需要另一种高效的密钥协商协议变体。该协议变体旨在提供完美的前向保密能力，作为密钥协议的一部分，具有低延迟，而不依赖于公钥基础设施。
This document describes a fourth lightweight key management scheme for MIKEY that could somehow be seen as a synergetic optimization between the pre-shared key distribution scheme and the Diffie-Hellman key agreement.
本文档描述了针对MIKEY的第四个轻量级密钥管理方案，该方案可以被视为预共享密钥分发方案和Diffie-Hellman密钥协议之间的协同优化。
The idea of the protocol in this document is to apply the Diffie-Hellman key agreement, but rather than deploy a digital signature for authenticity of the exchanged keying material, it instead uses a keyed-hash for symmetrically pre-assigned shared secrets. This combination of security mechanisms is called the HMAC-authenticated Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC).
本文件中协议的思想是应用Diffie-Hellman密钥协议，但不是部署数字签名以确保交换密钥材料的真实性，而是使用密钥散列来对称地预先分配共享机密。这种安全机制的组合称为HMAC认证的Diffie-Hellman（DH）MIKEY密钥协议（DHHMAC）。
The DHHMAC variant closely follows the design and philosophy of MIKEY and reuses MIKEY protocol payload components and MIKEY mechanisms to its maximum benefit and for best compatibility.
DHHMAC变体严格遵循MIKEY的设计和理念，并重用MIKEY协议有效负载组件和MIKEY机制，以实现最大效益和最佳兼容性。
Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond a point-to-point constellation; thus, both MIKEY Diffie-Hellman protocols do not support group-based keying for any group size larger than two entities.
与MIKEY Diffie-Hellman协议一样，DHHMAC的规模不超过点对点星座；因此，两个MIKEY Diffie-Hellman协议都不支持任何大于两个实体的组大小的基于组的键控。
The definitions and notations in this document are aligned with MIKEY; see [2] sections 1.3 - 1.4.
本文件中的定义和符号与MIKEY一致；参见[2]第1.3-1.4节。
All large integer computations in this document should be understood as being mod p within some fixed group G for some large prime p; see [2] section 3.3. However, the DHHMAC protocol is also applicable generally to other appropriate finite, cyclical groups as well.
本文中的所有大整数计算都应理解为某个大素数p的某个固定群G内的mod p；见[2]第3.3节。然而，DHHMAC协议通常也适用于其他适当的有限循环群。
It is assumed that a pre-shared key s is known by both entities (initiator and responder). The authentication key auth_key is derived from the pre-shared secret s using the pseudo-random function PRF; see [2] sections 4.1.3 and 4.1.5.
假定两个实体（发起方和响应方）都知道预共享密钥。认证密钥auth_密钥是使用伪随机函数PRF从预共享密钥s导出的；参见[2]第4.1.3节和第4.1.5节。
In this text, [X] represents an optional piece of information. Generally throughout the text, X SHOULD be present unless certain circumstances MAY allow X to be optional and not to be present, thereby potentially resulting in weaker security. Likewise, [X, Y] represents an optional compound piece of information where the pieces X and Y either SHOULD both be present or MAY optionally both be absent. {X} denotes zero or more occurrences of X.
在本文中，[X]表示一条可选信息。通常，在全文中，X应该存在，除非某些情况允许X是可选的且不存在，从而可能导致安全性降低。类似地，[X，Y]表示可选的复合信息片段，其中片段X和Y要么都应该存在，要么可以可选地都不存在。{十} 表示零次或多次出现X。
auth_key Pre-shared authentication key, PRF-derived from pre-shared key s. DH Diffie-Hellman DHi Public Diffie-Hellman half key g^(xi) of the Initiator DHr Public Diffie-Hellman half key g^(xr) of the Responder DHHMAC HMAC-authenticated Diffie-Hellman DoS Denial-of-service G Diffie-Hellman group HDR MIKEY common header payload HMAC Keyed Hash Message Authentication Code HMAC-SHA1 HMAC using SHA1 as hash function (160-bit result) IDi Identity of initiator IDr Identity of receiver IKE Internet Key Exchange IPsec Internet Protocol Security MIKEY Multimedia Internet KEYing MIKEY-DHHMAC MIKEY Diffie-Hellman key management protocol using HMAC MIKEY-DHSIGN MIKEY Diffie-Hellman key agreement protocol MIKEY-PK MIKEY public-key encryption-based key distribution protocol MIKEY-PS MIKEY pre-shared key distribution protocol p Diffie-Hellman prime modulus PKI Public-key Infrastructure PRF MIKEY pseudo-random function (see [2] section 4.1.3) RSA Rivest, Shamir, and Adleman s Pre-shared key SDP Session Description Protocol SOI Son-of-IKE, IKEv2 SP MIKEY Security Policy (Parameter) Payload T Timestamp TEK Traffic Encryption Key TGK MIKEY TEK Generation Key, as the common Diffie-Hellman shared secret TLS Transport Layer Security xi Secret, (pseudo) random Diffie-Hellman key of the Initiator xr Secret, (pseudo) random Diffie-Hellman key of the Responder
身份验证密钥预共享身份验证密钥，从预共享密钥派生的PRF。DH Diffie-Hellman DHi Public Diffie-Hellman发起方的DHr Public Diffie-Hellman半密钥g^（xi）响应方的DHr Public Diffie-Hellman半密钥g^（xr）DHHMAC HMAC HMAC认证Diffie-Hellman DoS拒绝服务g Diffie-Hellman组HDR MIKEY公共头有效载荷HMAC键控哈希消息认证码HMAC-SHA1 HMAC使用SHA1作为哈希函数（160位结果）IDi发起方标识IDr接收方标识IKE Internet密钥交换IPsec Internet协议安全MIKEY多媒体Internet密钥MIKEY-DHHMAC MIKEY Diffie Hellman密钥管理协议使用HMAC MIKEY-DHSIGN MIKEY Diffie Hellman密钥协议MIKEY-PK基于公钥加密的密钥分发协议MIKEY-PS MIKEY预共享密钥分发协议p Diffie Hellman素数模PKI公钥基础设施PRF MIKEY伪随机函数（见[2]第4.1.3节）RSA Rivest、Shamir和Adleman预共享密钥SDP会话描述协议IKE的SOI子协议IKEv2 SP MIKEY安全策略（参数）有效载荷T时间戳TEK流量加密密钥TGK MIKEY TEK生成密钥，作为通用Diffie-Hellman共享秘密TLS传输层安全席秘密，（伪）随机Diffie Hellman密钥的启动者XR秘密，（伪）随机Diffie Hellman密钥的响应者
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC) for MIKEY addresses the same scenarios and scope as the other three key management schemes in MIKEY address.
用于MIKEY的HMAC认证Diffie-Hellman密钥协议（DHHMAC）与MIKEY address中的其他三个密钥管理方案具有相同的场景和范围。
DHHMAC is applicable in a peer-to-peer group where no access to a public-key infrastructure can be assumed to be available. Rather, pre- shared master secrets are assumed to be available among the entities in such an environment.
DHHMAC适用于对等组，在该组中，可以假定无法访问公钥基础设施。相反，假定在这样的环境中，预共享的主机密在实体之间可用。
In a pair-wise group, it is assumed that each client will be setting up a session key for its outgoing links with its peer using the DH-MAC key agreement protocol.
在成对组中，假设每个客户端将使用DH-MAC密钥协议协议为其与对等方的传出链路设置会话密钥。
As is the case for the other three MIKEY key management protocols, DHHMAC assumes, at least, loosely synchronized clocks among the entities in the small group.
与其他三个MIKEY密钥管理协议的情况一样，DHHMAC至少假定小组中的实体之间的时钟是松散同步的。
To synchronize the clocks in a secure manner, some operational or procedural means are recommended. MIKEY-DHHMAC does not define any secure time synchronization measures; however, sections 5.4 and 9.3 of [2] provide implementation guidance on clock synchronization and timestamps.
为了以安全的方式同步时钟，建议采用一些操作或程序方法。MIKEY-DHHMAC未定义任何安全时间同步措施；然而，[2]的第5.4节和第9.3节提供了关于时钟同步和时间戳的实施指南。
MIKEY-DHHMAC and the other MIKEY key management protocols are intended for application-level key management and are optimized for multimedia applications with real-time session setup and session management constraints.
MIKEY-DHHMAC和其他MIKEY密钥管理协议用于应用程序级密钥管理，并针对具有实时会话设置和会话管理约束的多媒体应用程序进行了优化。
As the MIKEY-DHHMAC key management protocol terminates in one roundtrip, DHHMAC is applicable for integration into two-way handshake session or call signaling protocols such as
由于MIKEY-DHHMAC密钥管理协议在一次往返中终止，DHHMAC适用于集成到双向握手会话或呼叫信令协议中，如
a) SIP [13] and SDP, where the encoded MIKEY messages are encapsulated and transported in SDP containers of the SDP offer/answer see RFC 3264 [27]) handshake, as described in [4]; and
a) SIP[13]和SDP，其中编码的MIKEY消息被封装并传输在SDP提供/应答的SDP容器中（参见RFC 3264[27]）握手，如[4]所述；和
b) H.323 (see [15]), where the encoded MIKEY messages are transported in the H.225.0 fast start call signaling handshake. Appendix A outlines the usage of MIKEY-DHHMAC within H.235.
b) H.323（见[15]），其中编码的MIKEY消息在H.225.0快速启动呼叫信令握手中传输。附录A概述了H.235中MIKEY-DHHMAC的用法。
MIKEY-DHHMAC is offered as an option to the other MIKEY key management variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-DH-SIGN) for all those cases where DHHMAC has its particular strengths (see section 5).
对于DHHMAC具有其特殊优势的所有情况，MIKEY-DHHMAC作为其他MIKEY密钥管理变体（MIKEY预共享、MIKEY公钥和MIKEY-DH-SIGN）的选项提供（见第5节）。
The Group key management architecture (GKMARCH) [19] describes a generic architecture for multicast security group key management protocols. In the context of this architecture, MIKEY-DHHMAC may operate as a registration protocol; see also [2] section 2.4. The main entities involved in the architecture are a group controller/key server (GCKS), the receiver(s), and the sender(s). Due to the pair-wise nature of the Diffie-Hellman operation and the 1-roundtrip constraint, usage of MIKEY-DHHMAC rules out any deployment as a group key management protocol with more than two group entities. Only the degenerate case with two peers is possible where, for example, the responder acts as the group controller.
组密钥管理体系结构（GKParch）[19]描述了多播安全组密钥管理协议的通用体系结构。在该架构的上下文中，MIKEY-DHHMAC可以作为注册协议运行；另见[2]第2.4节。体系结构中涉及的主要实体是组控制器/密钥服务器（GCKS）、接收方和发送方。由于Diffie-Hellman操作的成对性和1-roundtrip约束，使用MIKEY-DHHMAC排除了将任何部署作为具有两个以上组实体的组密钥管理协议。例如，只有当响应者充当组控制器时，才可能出现具有两个对等方的退化情况。
Note that MIKEY does not provide re-keying in the GKMARCH sense, only updating of the keys by normal unicast messages.
请注意，MIKEY不提供GKMARCH意义上的重新键控，仅通过正常单播消息更新键。
The following figure defines the security protocol for DHHMAC:
下图定义了DHHMAC的安全协议：
Initiator Responder
发起者响应者
I_message = HDR, T, RAND, [IDi], IDr,
{SP}, DHi, KEMAC
-----------------------> R_message = HDR, T,
[IDr], IDi, DHr,
DHi, KEMAC
<----------------------
I_message = HDR, T, RAND, [IDi], IDr,
{SP}, DHi, KEMAC
-----------------------> R_message = HDR, T,
[IDr], IDi, DHr,
DHi, KEMAC
<----------------------
Figure 1: HMAC-authenticated Diffie-Hellman key-based exchange, where xi and xr are (pseudo) randomly chosen, respectively, by the initiator and the responder.
图1：HMAC认证Diffie-Hellman密钥交换，其中席和XR分别是由发起方和响应方随机选择的（伪）。
The DHHMAC key exchange SHALL be done according to Figure 1. The initiator chooses a (pseudo) random value, xi, and sends an HMACed message including g^(xi) and a timestamp to the responder. It is recommended that the initiator SHOULD always include the identity
DHHMAC密钥交换应按照图1进行。发起方选择一个（伪）随机值席席，并向应答者发送包括G^（XI）和时间戳的HMACED消息。建议启动器始终包含标识
payloads IDi and IDr within the I_message; unless the receiver can defer the initiator's identity by some other means, IDi MAY optionally be omitted. The initiator SHALL always include the recipient's identity.
I_消息中的有效载荷IDi和IDr；除非接收器可以通过某些其他方式延迟发起者的身份，否则可以选择性地省略IDi。发起人应始终包括接收人的身份。
The group parameters (e.g., the group G) are a set of parameters chosen by the initiator. Note that like in the MIKEY protocol, both sender and receiver explicitly transmit the Diffie-Hellman group G within the Diffie-Hellman payload DHi or DHr through an encoding (e.g., OAKLEY group numbering; see [2] section 6.4). The actual group parameters g and p, however, are not explicitly transmitted but can be deduced from the Diffie-Hellman group G. The responder chooses a (pseudo) random positive integer, xr, and sends an HMACed message including g^(xr) and the timestamp to the initiator. The responder SHALL always include the initiator's identity IDi regardless of whether the I_message conveyed any IDi. It is RECOMMENDED that the responder SHOULD always include the identity payload IDr within the R_message; unless the initiator can defer the responder's identity by some other means, IDr MAY optionally be left out.
组参数（例如，组g）是由启动器选择的一组参数。注意，与MIKEY协议中一样，发送方和接收方通过编码（例如，OAKLEY组编号；参见[2]第6.4节）在Diffie-Hellman有效载荷DHi或DHr内显式传输Diffie-Hellman组G。然而，实际的组参数g和p没有显式传输，但可以从Diffie-Hellman组g中推导出来。响应者选择一个（伪）随机正整数xr，并向发起方发送一条包含g^（xr）和时间戳的HMACed消息。无论I_消息是否传达了任何IDi，响应者应始终包括发起人的身份IDi。建议响应者始终在R_消息中包含标识有效负载IDr；除非发起者可以通过其他方式延迟响应者的身份，否则IDr可以选择性地被忽略。
Both parties then calculate the TGK as g^(xi * xr).
然后，双方将TGK计算为g^（xi*xr）。
The HMAC authentication provides authentication of the DH half-keys and is necessary to avoid man-in-the-middle attacks.
HMAC身份验证提供DH半密钥的身份验证，是避免中间人攻击所必需的。
This approach is less expensive than digitally signed Diffie-Hellman in that both sides compute one exponentiation and one HMAC first, then one HMAC verification, and finally another Diffie-Hellman exponentiation.
这种方法比数字签名的Diffie-Hellman成本更低，因为双方首先计算一次求幂和一次HMAC，然后是一次HMAC验证，最后是另一次Diffie-Hellman求幂。
With off-line pre-computation, the initial Diffie-Hellman half-key MAY be computed before the key management transaction and thereby MAY further reduce the overall roundtrip delay, as well as the risk of denial-of-service attacks.
通过离线预计算，可在密钥管理事务之前计算初始Diffie-Hellman半密钥，从而可进一步减少总体往返延迟以及拒绝服务攻击的风险。
Processing of the TGK SHALL be accomplished as described in MIKEY [2] section 4.
TGK的处理应按照MIKEY[2]第4节的规定完成。
The computed HMAC result SHALL be conveyed in the KEMAC payload field where the MAC fields holds the HMAC result. The HMAC SHALL be computed over the entire message, excluding the MAC field using auth_key; see also section 4.2.
计算出的HMAC结果应在KEMAC有效载荷字段中传输，其中MAC字段保存HMAC结果。HMAC应在整个消息上计算，不包括使用auth_密钥的MAC字段；另见第4.2节。
TGK re-keying for DHHMAC generally proceeds as described in [2] section 4.5. Specifically, Figure 2 provides the message exchange for the DHHMAC update message.
DHHMAC的TGK重新键控通常按照第4.5节[2]中所述进行。具体而言，图2提供了DHHMAC更新消息的消息交换。
Initiator Responder
发起者响应者
I_message = HDR, T, [IDi], IDr,
{SP}, [DHi], KEMAC
-----------------------> R_message = HDR, T,
[IDr], IDi,
[DHr, DHi], KEMAC
<----------------------
I_message = HDR, T, [IDi], IDr,
{SP}, [DHi], KEMAC
-----------------------> R_message = HDR, T,
[IDr], IDi,
[DHr, DHi], KEMAC
<----------------------
Figure 2: DHHMAC update message
图2:DHHMAC更新消息
TGK re-keying supports two procedures:
TGK重设密钥支持两个过程：
a) True re-keying by exchanging new and fresh Diffie-Hellman half-keys. For this, the initiator SHALL provide a new, fresh DHi, and the responder SHALL respond with a new, fresh DHr and the received DHi.
a) 通过交换新的Diffie-Hellman半键实现真正的重键。为此，发起者应提供新的DHi，响应者应使用新的DHr和收到的DHi进行响应。
b) Non-key related information update without including any Diffie-Hellman half-keys in the exchange. Such a transaction does not change the actual TGK but updates other information such as security policy parameters. To update the non-key related information only, [DHi] and [DHr, DHi] SHALL be left out.
b) 非密钥相关信息更新，交换中不包含任何Diffie-Hellman半密钥。这样的事务不会更改实际的TGK，但会更新其他信息，如安全策略参数。要仅更新非关键相关信息，应省略[DHi]和[DHr，DHi]。
This section specifies the payload formats and data type values for DHHMAC; see also [2] section 6, for a definition of the MIKEY payloads.
本节规定了DHHMAC的有效载荷格式和数据类型值；另见[2]第6节，了解MIKEY有效载荷的定义。
This document does not define new payload formats but re-uses MIKEY payloads for DHHMAC as referenced:
本文件未定义新的有效载荷格式，但重新使用DHHMAC的MIKEY有效载荷，参考如下：
* Common header payload (HDR); see section 4.1 and [2] section 6.1.
* 公共报头有效载荷（HDR）；参见第4.1节和第6.1节[2]。
* SRTP ID sub-payload; see [2] section 6.1.1.
* srtpid子有效载荷；见[2]第6.1.1节。
* Key data transport payload (KEMAC); see section 4.2 and [2] section 6.2.
* 关键数据传输有效载荷（KEMAC）；参见第4.2节和第6.2节[2]。
* DH data payload; see [2] section 6.4.
* DH数据有效载荷；见[2]第6.4节。
* Timestamp payload; see [2] section 6.6.
* 时间戳有效载荷；见[2]第6.6节。
* ID payload; [2] section 6.7.
* ID有效载荷；[2] 第6.7节。
* Security Policy payload (SP); see [2] section 6.10.
* 安全策略有效载荷（SP）；见[2]第6.10节。
* RAND payload (RAND); see [2] section 6.11.
* 兰特有效载荷（兰特）；见[2]第6.11节。
* Error payload (ERR); see [2] section 6.12.
* 错误有效载荷（ERR）；见[2]第6.12节。
* General Extension Payload; see [2] section 6.15.
* 一般扩展有效载荷；见[2]第6.15节。
Referring to [2] section 6.1, the following data types SHALL be used for DHHMAC:
参考[2]第6.1节，DHHMAC应使用以下数据类型：
Data type | Value | Comment
-------------------------------------------------------------
DHHMAC init | 7 | Initiator's DHHMAC exchange message
DHHMAC resp | 8 | Responder's DHHMAC exchange message
Error | 6 | Error message; see [2] section 6.12
Data type | Value | Comment
-------------------------------------------------------------
DHHMAC init | 7 | Initiator's DHHMAC exchange message
DHHMAC resp | 8 | Responder's DHHMAC exchange message
Error | 6 | Error message; see [2] section 6.12
Table 4.1.a
表4.1.a
Note: A responder is able to recognize the MIKEY DHHMAC protocol by evaluating the data type field as 7 or 8. This is how the responder can differentiate between MIKEY and MIKEY DHHMAC.
注意：响应者可以通过将数据类型字段评估为7或8来识别MIKEY DHHMAC协议。这就是响应者如何区分MIKEY和MIKEY DHHMAC。
The next payload field SHALL be one of the following values:
下一有效载荷字段应为以下值之一：
Next payload| Value | Section
----------------------------------------------------------------
Last payload| 0 | -
KEMAC | 1 | section 4.2 and [2] section 6.2
DH | 3 | [2] section 6.4
T | 5 | [2] section 6.6
ID | 6 | [2] section 6.7
SP | 10 | [2] section 6.10
RAND | 11 | [2] section 6.11
ERR | 12 | [2] section 6.12
General Ext.| 21 | [2] section 6.15
Next payload| Value | Section
----------------------------------------------------------------
Last payload| 0 | -
KEMAC | 1 | section 4.2 and [2] section 6.2
DH | 3 | [2] section 6.4
T | 5 | [2] section 6.6
ID | 6 | [2] section 6.7
SP | 10 | [2] section 6.10
RAND | 11 | [2] section 6.11
ERR | 12 | [2] section 6.12
General Ext.| 21 | [2] section 6.15
Table 4.1.b
表4.1.b
Other defined next payload values defined in [2] SHALL not be applied to DHHMAC.
[2]中定义的其他定义的下一有效载荷值不适用于DHHMAC。
In case of a decoding error or of a failed HMAC authentication verification, the responder SHALL apply the Error payload data type.
在解码错误或HMAC认证验证失败的情况下，响应者应应用错误有效载荷数据类型。
DHHMAC SHALL apply this payload for conveying the HMAC result along with the indicated authentication algorithm. When used in conjunction with DHHMAC, KEMAC SHALL not convey any encrypted data; thus, Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set to 0, and Encr data SHALL be left empty. The AES key wrap method (see [16]) SHALL not be applied for DHHMAC.
DHHMAC应将该有效载荷与指定的认证算法一起用于传输HMAC结果。当与DHHMAC一起使用时，KEMAC不得传递任何加密数据；因此，Encr alg应设置为2（空），Encr data len应设置为0，Encr data应保留为空。AES密钥封装方法（见[16]）不适用于DHHMAC。
For DHHMAC, this key data transport payload SHALL be the last payload in the message. Note that the Next payload field SHALL be set to Last payload. The HMAC is then calculated over the entire MIKEY message, excluding the MAC field using auth_key as described in [2] section 5.2, and then stored within the MAC field.
对于DHHMAC，该关键数据传输有效载荷应为消息中的最后一个有效载荷。注意，下一个有效载荷字段应设置为最后一个有效载荷。然后，使用[2]第5.2节所述的auth_密钥对整个MIKEY消息（不包括MAC字段）计算HMAC，然后将其存储在MAC字段中。
MAC alg | Value | Comments
------------------------------------------------------------------
HMAC-SHA-1 | 0 | Mandatory, Default (see [3])
NULL | 1 | Very restricted use; see
| [2] section 4.2.4
MAC alg | Value | Comments
------------------------------------------------------------------
HMAC-SHA-1 | 0 | Mandatory, Default (see [3])
NULL | 1 | Very restricted use; see
| [2] section 4.2.4
Table 4.2.a
表4.2.a
HMAC-SHA-1 is the default hash function that MUST be implemented as part of the DHHMAC. The length of the HMAC-SHA-1 result is 160 bits.
HMAC-SHA-1是默认哈希函数，必须作为DHHMAC的一部分实现。HMAC-SHA-1结果的长度为160位。
For DHHMAC, this payload SHALL only hold a non-certificate-based identity.
对于DHHMAC，该有效载荷应仅持有非基于证书的身份。
For DHHMAC, to avoid bidding-down attacks, this payload SHALL list all key management protocol identifiers of a surrounding encapsulation protocol, such as SDP [4]. The General Extension Payload SHALL be integrity protected with the HMAC using the shared secret.
对于DHHMAC，为了避免拒绝攻击，该有效载荷应列出周围封装协议（如SDP[4]）的所有密钥管理协议标识符。通用扩展有效载荷应通过HMAC使用共享机密进行完整性保护。
Type | Value | Comments SDP IDs | 1 | List of SDP key management IDs (allocated for use in [4]); see also [2] section 6.15.
键入|值|注释SDP ID | 1 | SDP密钥管理ID列表（分配用于[4]）；另见[2]第6.15节。
Table 4.4.a
表4.4.a
This document addresses key management security issues throughout. For a comprehensive explanation of MIKEY security considerations, please refer to MIKEY [2] section 9.
本文档介绍了整个过程中的关键管理安全问题。有关MIKEY安全注意事项的全面解释，请参阅MIKEY[2]第9节。
In addition, this document addresses security issues according to [7], where the following security considerations apply in particular to this document:
此外，本文件根据[7]解决了安全问题，其中以下安全注意事项特别适用于本文件：
The DHHMAC security protocol described in this document focuses primarily on communication security; i.e., the security issues concerned with the MIKEY DHHMAC protocol. Nevertheless, some system security issues are also of interest that are not explicitly defined by the DHHMAC protocol, but that should be provided locally in practice.
本文件中描述的DHHMAC安全协议主要关注通信安全；i、 例如，与MIKEY DHHMAC协议有关的安全问题。尽管如此，DHHMAC协议并未明确定义一些系统安全问题，但在实践中应在本地提供。
The system that runs the DHHMAC protocol entity SHALL provide the capability to generate (pseudo) random numbers as input to the Diffie-Hellman operation (see [8]). Furthermore, the system SHALL be capable of storing the generated (pseudo) random data, secret data, keys, and other secret security parameters securely (i.e., confidential and safe from unauthorized tampering).
运行DHHMAC协议实体的系统应提供生成（伪）随机数作为Diffie-Hellman操作输入的能力（见[8]）。此外，系统应能够安全地存储生成的（伪）随机数据、机密数据、密钥和其他机密安全参数（即，保密且不受未经授权的篡改）。
The threat model, to which this document adheres, covers the issues of end-to-end security in the Internet generally, without ruling out the possibility that MIKEY DHHMAC can be deployed in a corporate, closed IP environment. This also includes the possibility that MIKEY DHHMAC can be deployed on a hop-by-hop basis with some intermediate trusted "MIKEY DHHMAC proxies" involved.
本文档所遵循的威胁模型涵盖了互联网中的端到端安全问题，但不排除MIKEY DHHMAC可以部署在公司封闭IP环境中的可能性。这还包括MIKEY DHHMAC可以逐跳部署，并涉及一些中间受信任的“MIKEY DHHMAC代理”。
Since DHHMAC is a key management protocol, the following security threats are of concern:
由于DHHMAC是一种密钥管理协议，以下安全威胁值得关注：
* Unauthorized interception of plain TGKs: For DHHMAC, this threat does not occur since the TGK is not actually transmitted on the wire (not even in encrypted fashion).
* 未经授权拦截普通TGK：对于DHHMAC来说，这种威胁不会发生，因为TGK实际上不是通过有线传输的（甚至不是以加密方式）。
* Eavesdropping of other, transmitted keying information: DHHMAC protocol does not explicitly transmit the TGK at all. Instead, by using the Diffie-Hellman "encryption" operation, which conceals the secret (pseudo) random values, only partial information (i.e., the DH half-key) for construction of the TGK is transmitted. It is fundamentally assumed that availability of such Diffie-Hellman
* 窃听其他传输的密钥信息：DHHMAC协议根本不显式传输TGK。相反，通过使用隐藏秘密（伪）随机值的Diffie-Hellman“加密”操作，仅传输用于构造TGK的部分信息（即DH半密钥）。从根本上说，假设这种Diffie Hellman的可用性
half-keys to an eavesdropper does not result in any substantial security risk; see 5.4. Furthermore, the DHHMAC carries other data such as timestamps, (pseudo) random values, identification information or security policy parameters; eavesdropping of any such data is not considered to yield any significant security risk.
窃听者的一半密钥不会导致任何重大安全风险；见5.4。此外，DHHMAC携带诸如时间戳、（伪）随机值、标识信息或安全策略参数等其他数据；窃听任何此类数据不会产生任何重大安全风险。
* Masquerade of either entity: This security threat must be avoided, and if a masquerade attack would be attempted, appropriate detection means must be in place. DHHMAC addresses this threat by providing mutual peer entity authentication.
* 任何实体的伪装：必须避免这种安全威胁，如果试图进行伪装攻击，必须采取适当的检测手段。DHHMAC通过提供相互对等实体身份验证来解决此威胁。
* Man-in-the-middle attacks: Such attacks threaten the security of exchanged, non-authenticated messages. Man-in-the-middle attacks usually come with masquerade and or loss of message integrity (see below). Man-in-the-middle attacks must be avoided and, if present or attempted, must be detected appropriately. DHHMAC addresses this threat by providing mutual peer entity authentication and message integrity.
* 中间人攻击：此类攻击威胁交换的、未经身份验证的消息的安全。中间人攻击通常带有伪装和/或消息完整性丢失（见下文）。必须避免中间人攻击，如果存在或试图进行攻击，必须进行适当的检测。DHHMAC通过提供相互对等实体身份验证和消息完整性来解决此威胁。
* Loss of integrity: This security threat relates to unauthorized replay, deletion, insertion, and manipulation of messages. Although any such attacks cannot be avoided, they must at least be detected. DHHMAC addresses this threat by providing message integrity.
* 完整性丢失：此安全威胁与未经授权的消息重播、删除、插入和操纵有关。尽管无法避免任何此类攻击，但至少必须检测到它们。DHHMAC通过提供消息完整性来解决此威胁。
* Bidding-down attacks: When multiple key management protocols, each of a distinct security level, are offered (such as those made possible by SDP [4]), avoiding bidding-down attacks is of concern. DHHMAC addresses this threat by reusing the MIKEY General Extension Payload mechanism, where all key management protocol identifiers are to be listed within the MIKEY General Extension Payload.
* 竞价拒绝攻击：当提供了多个密钥管理协议（每个协议都具有不同的安全级别）时（例如SDP[4]使之成为可能的协议），避免竞价拒绝攻击是一个值得关注的问题。DHHMAC通过重用MIKEY General Extension有效负载机制来解决此威胁，其中所有密钥管理协议标识符都将列在MIKEY General Extension有效负载中。
Some potential threats are not within the scope of this threat model:
某些潜在威胁不在此威胁模型的范围内：
* Passive and off-line cryptanalysis of the Diffie-Hellman algorithm: Under certain reasonable assumptions (see 5.4, below), it is widely believed that DHHMAC is sufficiently secure and that such attacks are infeasible, although the possibility of a successful attack cannot be ruled out.
* Diffie-Hellman算法的被动和离线密码分析：在某些合理假设下（见下文5.4），人们普遍认为DHHMAC足够安全，此类攻击不可行，尽管无法排除成功攻击的可能性。
* Non-repudiation of the receipt or of the origin of the message: These are not requirements within the context of DHHMAC in this environment, and thus related countermeasures are not provided at all.
* 消息的接收或来源的不可否认性：在这种环境下，这些不是DHHMAC上下文中的要求，因此根本没有提供相关的对策。
* Denial-of-service or distributed denial-of-service attacks: Some considerations are given on some of those attacks, but DHHMAC does not claim to provide full countermeasure against any of those attacks. For example, stressing the availability of the entities is not thwarted by means of the key management protocol; some other local countermeasures should be applied. Further, some DoS attacks are not countered, such as interception of a valid DH- request and its massive instant duplication. Such attacks might at least be countered partially by some local means that are outside the scope of this document.
* 拒绝服务或分布式拒绝服务攻击：对其中一些攻击给出了一些注意事项，但DHHMAC并不声称提供针对这些攻击的完整对策。例如，强调实体的可用性不会受到密钥管理协议的阻碍；应采取其他一些当地对策。此外，一些DoS攻击没有被反击，例如拦截有效的DH请求及其大量的即时复制。这种攻击至少可以通过一些不在本文件范围内的本地手段进行部分反击。
* Identity protection: Like MIKEY, identity protection is not a major design requirement for MIKEY-DHHMAC, either; see [2]. No security protocol is known so far that is able to provide the objectives of DHHMAC as stated in section 5.3, including identity protection within just a single roundtrip. MIKEY-DHHMAC trades identity protection for better security for the keying material and shorter roundtrip time. Thus, MIKEY-DHHMAC does not provide identity protection on its own but may inherit such property from a security protocol underneath that actually features identity protection.
* 身份保护：与MIKEY一样，身份保护也不是MIKEY-DHHMAC的主要设计要求；见[2]。到目前为止，尚不知道能够提供第5.3节所述DHHMAC目标的安全协议，包括仅在一次往返中的身份保护。MIKEY-DHHMAC使用身份保护来提高密钥材料的安全性，缩短往返时间。因此，MIKEY-DHHMAC本身不提供身份保护，但可以从其下的安全协议继承此类属性，该协议实际上具有身份保护功能。
The DHHMAC security protocol (see section 3) and the TGK re-keying security protocol (see section 3.1) provide the option not to supply identity information. This option is only applicable if some other means are available to supply trustworthy identity information; e.g., by relying on secured links underneath MIKEY that supply trustworthy identity information some other way. However, it is understood that without identity information, the MIKEY key management security protocols might be subject to security weaknesses such as masquerade, impersonation, and reflection attacks, particularly in end-to-end scenarios where no other secure means of assured identity information are provided.
DHHMAC安全协议（见第3节）和TGK密钥更新安全协议（见第3.1节）提供了不提供身份信息的选项。此选项仅适用于提供可信身份信息的其他方式；e、 例如，依靠米奇下面的安全链接，以其他方式提供可信的身份信息。然而，可以理解的是，如果没有身份信息，MIKEY密钥管理安全协议可能会受到安全弱点的影响，例如伪装、模拟和反射攻击，特别是在没有提供其他安全的身份信息手段的端到端场景中。
Leaving identity fields optional (if doing so is possible) thus should not be seen as a privacy method, either, but rather as a protocol optimization feature.
因此，将标识字段保留为可选（如果可以的话）也不应视为隐私方法，而应视为协议优化功能。
With the security threats in mind, this document provides the following security features and yields the following properties:
考虑到安全威胁，本文档提供了以下安全功能，并具有以下属性：
* Secure key agreement with the establishment of a TGK at both peers: This is achieved using an authenticated Diffie-Hellman key management protocol.
* 在两个对等点上建立TGK的安全密钥协议：这是使用经过身份验证的Diffie-Hellman密钥管理协议实现的。
* Peer-entity authentication (mutual): This authentication corroborates that the host/user is authentic in that possession of a pre-assigned secret key is proven using keyed HMAC. Authentication occurs on the request and on the response message; thus authentication is mutual.
* 对等实体身份验证（相互）：此身份验证证实主机/用户在使用密钥HMAC证明拥有预先分配的密钥时是真实的。认证发生在请求和响应消息上；因此，身份验证是相互的。
The HMAC computation corroborates for authentication and message integrity of the exchanged Diffie-Hellman half-keys and associated messages. The authentication is absolutely necessary in order to avoid man-in-the-middle attacks on the exchanged messages in transit and, in particular, on the otherwise non-authenticated exchanged Diffie-Hellman half-keys.
HMAC计算确认交换的Diffie-Hellman半密钥和相关消息的身份验证和消息完整性。为了避免中间人攻击传输中的交换消息，特别是未经验证的交换Diffie-Hellman半密钥，身份验证是绝对必要的。
Note: This document does not address issues regarding authorization; this feature is not provided explicitly. However, DHHMAC authentication means support and facilitate realization of authorization means (local issue).
注：本文件不涉及授权相关问题；此功能未明确提供。然而，DHHMAC认证手段支持并促进授权手段的实现（本地问题）。
* Cryptographic integrity check: The cryptographic integrity check is achieved using a message digest (keyed HMAC). It includes the exchanged Diffie-Hellman half-keys but covers the other parts of the exchanged message as well. Both mutual peer entity authentication and message integrity provide effective countermeasures against man-in-the-middle attacks.
* 加密完整性检查：加密完整性检查使用消息摘要（键控HMAC）实现。它包括交换的Diffie-Hellman半键，但也包括交换消息的其他部分。相互对等实体身份验证和消息完整性都为防止中间人攻击提供了有效的对策。
The initiator may deploy a local timer that fires when the awaited response message did not arrive in a timely manner. This is intended to detect deletion of entire messages.
启动器可以部署一个本地计时器，当等待的响应消息没有及时到达时触发。这是为了检测整个消息的删除。
* Replay protection of the messages is achieved using embedded timestamps: In order to detect replayed messages, it is essential that the clocks among initiator and sender be roughly synchronized. The reader is referred to [2] section 5.4, and [2] section 9.3, which provide further considerations and give guidance on clock synchronization and timestamp usage. Should the clock synchronization be lost, end systems cannot detect replayed messages anymore, and the end systems cannot securely establish keying material. This may result in a denial-of-service; see [2] section 9.5.
* 消息的重放保护是使用嵌入的时间戳实现的：为了检测重放的消息，发起方和发送方之间的时钟必须大致同步。读者可参考[2]第5.4节和[2]第9.3节，这两部分提供了进一步的考虑，并就时钟同步和时间戳的使用提供了指导。如果时钟同步丢失，终端系统将无法再检测重播的消息，并且终端系统无法安全地建立密钥材料。这可能导致拒绝服务；见[2]第9.5节。
* Limited DoS protection: Rapid checking of the message digest allows verifying the authenticity and integrity of a message before launching CPU intensive Diffie-Hellman operations or starting other resource consuming tasks. This protects against some denial-of-service attacks: malicious modification of messages and spam attacks with (replayed or masqueraded) messages. DHHMAC probably does not explicitly counter sophisticated distributed, large-scale denial-of-service attacks that compromise system availability, for
* 有限的DoS保护：快速检查消息摘要允许在启动CPU密集型Diffie-Hellman操作或启动其他资源消耗任务之前验证消息的真实性和完整性。这可以防止某些拒绝服务攻击：恶意修改消息和使用（重播或伪装）消息的垃圾邮件攻击。例如，DHHMAC可能不会明确反击危及系统可用性的复杂分布式大规模拒绝服务攻击
example. Some DoS protection is provided by inclusion of the initiator's identity payload in the I_message. This allows the recipient to filter out those (replayed) I_messages that are not targeted for him and to avoid creating unnecessary MIKEY sessions.
实例通过在I_消息中包含启动器的标识负载，可以提供一些DoS保护。这允许收件人过滤掉那些（重播的）不针对他的I_消息，并避免创建不必要的MIKEY会话。
* Perfect-forward secrecy (PFS): Other than the MIKEY pre-shared and public-key-based key distribution protocols, the Diffie-Hellman key agreement protocol features a security property called perfect forward secrecy. That is, even if the long-term pre-shared key is compromised at some point in time, this does not compromise past or future session keys.
* 完美前向保密（PFS）：除了MIKEY预共享和基于公钥的密钥分发协议外，Diffie-Hellman密钥协商协议具有称为完美前向保密的安全特性。也就是说，即使长期预共享密钥在某个时间点被泄露，这也不会泄露过去或将来的会话密钥。
Neither the MIKEY pre-shared nor the MIKEY public-key protocol variants are able to provide the security property of perfect-forward secrecy. Thus, none of the other MIKEY protocols is able to substitute the Diffie-Hellman PFS property.
无论是MIKEY预共享协议还是MIKEY公钥协议变体都不能提供完全前向保密的安全特性。因此，没有任何其他MIKEY协议能够替代Diffie-Hellman PFS属性。
As such, DHHMAC and digitally signed DH provide a far superior security level to that of the pre-shared or public-key-based key distribution protocol in that respect.
因此，DHHMAC和数字签名DH在这方面提供了远高于预共享或基于公钥的密钥分发协议的安全级别。
* Fair, mutual key contribution: The Diffie-Hellman key management protocol is not a strict key distribution protocol per se, in which the initiator distributes a key to its peers. Actually, both parties involved in the protocol exchange are able to contribute to the common Diffie-Hellman TEK traffic generating key equally. This reduces the risk of either party cheating or unintentionally generating a weak session key. This makes the DHHMAC a fair key agreement protocol. One may view this property as an additional distributed security measure that increases security robustness over that of the case where all the security depends just on the proper implementation of a single entity.
* 公平、相互密钥贡献：Diffie-Hellman密钥管理协议本身不是一个严格的密钥分发协议，在该协议中，发起方将密钥分发给其对等方。实际上，参与协议交换的双方都能够平等地为共同的Diffie-Hellman-TEK通信量生成密钥。这降低了任何一方作弊或无意中生成弱会话密钥的风险。这使得DHHMAC成为一个公平的密钥协商协议。人们可以将此属性视为一种额外的分布式安全措施，与所有安全性仅取决于单个实体的正确实现的情况相比，它提高了安全稳健性。
For Diffie-Hellman key agreement to be secure, each party SHALL generate its xi or xr values using a strong, unpredictable pseudo-random generator if a source of true randomness is not available. Further, these values xi or xr SHALL be kept private. It is RECOMMENDED that these secret values be destroyed once the common Diffie-Hellman shared secret key has been established.
对于Diffie-Hellman密钥协议，如果真正的随机性来源不可用，每个方都应该使用强的、不可预测的伪随机生成器生成其席或XR值。此外，这些值席或XR应保持保密。建议在建立公共Diffie-Hellman共享密钥后销毁这些秘密值。
* Efficiency and performance: Like the MIKEY-public key protocol, the MIKEY DHHMAC key agreement protocol securely establishes a TGK within just one roundtrip. Other existing key management techniques, such as IPsec-IKE [12], IPsec-IKEv2 [14], TLS [11], and other schemes, are not deemed adequate in addressing those real-time and security requirements sufficiently; they all use more than a single roundtrip. All the MIKEY key management protocols are able to complete their task of security policy parameter
* 效率和性能：与MIKEY公钥协议一样，MIKEY DHHMAC密钥协议只需一次往返即可安全地建立TGK。其他现有的密钥管理技术，如IPsec IKE[12]、IPsec-IKEv2[14]、TLS[11]和其他方案，在充分满足这些实时和安全需求方面被认为是不够的；它们都使用不止一次往返。所有的MIKEY密钥管理协议都能够完成其安全策略参数的任务
negotiation, including key-agreement or key distribution, in one roundtrip. However, the MIKEY pre-shared and MIKEY public-key protocol are both able to complete their task even in a half-roundtrip when the confirmation messages are omitted.
在一次往返中进行协商，包括密钥协议或密钥分发。但是，即使在省略确认消息的情况下，MIKEY pre-shared和MIKEY public key协议也能够在半个往返过程中完成其任务。
Using HMAC in conjunction with a strong one-way hash function (such as SHA1) may be achieved more efficiently in software than expensive public-key operations. This yields a particular performance benefit of DHHMAC over signed DH or the public-key encryption protocol.
与昂贵的公钥操作相比，在软件中结合使用HMAC和强单向散列函数（例如SHA1）可以更有效地实现。与签名DH或公钥加密协议相比，DHHMAC具有特殊的性能优势。
If a very high security level is desired for long-term secrecy of the negotiated Diffie-Hellman shared secret, longer hash values may be deployed, such as SHA256, SHA384, or SHA512 provide, possibly in conjunction with stronger Diffie-Hellman groups. This is left as for further study.
如果对于协商的Diffie-Hellman共享秘密的长期保密性需要非常高的安全级别，则可以部署更长的散列值，例如SHA256、SHA384或SHA512-provide，可能与更强的Diffie-Hellman组结合使用。这有待进一步研究。
For the sake of improved performance and reduced roundtrip delay, either party may pre-compute its public Diffie-Hellman half-key off-line.
为了提高性能和减少往返延迟，任何一方都可以离线预计算其公共Diffie-Hellman半键。
On the other side and under reasonable conditions, DHHMAC consumes more CPU cycles than the MIKEY pre-shared key distribution protocol. The same might hold true quite likely for the MIKEY public-key distribution protocol (depending on choice of the private and public key lengths). As such, it can be said that DHHMAC provides sound performance when compared with the other MIKEY protocol variants.
另一方面，在合理的条件下，DHHMAC比MIKEY预共享密钥分发协议消耗更多的CPU周期。对于MIKEY公钥分发协议（取决于私钥和公钥长度的选择），情况可能也是如此。因此，与其他MIKEY协议变体相比，DHHMAC可以提供声音性能。
The use of optional identity information (with the constraints stated in section 5.2) and optional Diffie-Hellman half-key fields provides a means to increase performance and shorten the consumed network bandwidth.
使用可选身份信息（第5.2节规定的约束条件）和可选Diffie-Hellman半键字段提供了提高性能和缩短消耗网络带宽的方法。
* Security infrastructure: This document describes the HMAC-authenticated Diffie-Hellman key agreement protocol, which completely avoids digital signatures and the associated public-key infrastructure, as would be necessary for the X.509 RSA public-key-based key distribution protocol or the digitally signed Diffie-Hellman key agreement protocol as described in MIKEY. Public-key infrastructures may not always be available in certain environments, nor may they be deemed adequate for real-time multimedia applications when additional steps are taken for certificate validation and certificate revocation methods with additional roundtrips into account.
* 安全基础设施：本文件描述了HMAC认证的Diffie-Hellman密钥协议协议，该协议完全避免了数字签名和相关的公钥基础设施，这对于基于X.509 RSA公钥的密钥分发协议或数字签名Diffie-Hellman密钥协议协议（如MIKEY中所述）是必要的。在某些环境中，公钥基础设施可能并不总是可用的，如果在考虑额外往返的情况下对证书验证和证书撤销方法采取额外的步骤，也可能认为它们不足以用于实时多媒体应用程序。
DHHMAC does not depend on PKI, nor do implementations require PKI standards. Thus, it is believed to be much simpler than the more complex PKI facilities.
DHHMAC不依赖PKI，实施也不需要PKI标准。因此，它被认为比更复杂的PKI设施简单得多。
DHHMAC is particularly attractive in those environments where provisioning of a pre-shared key has already been accomplished.
DHHMAC在已经完成预共享密钥供应的环境中尤其具有吸引力。
* NAT-friendliness: DHHMAC is able to operate smoothly through firewall/NAT devices as long as the protected identity information of the end entity is not an IP/transport address.
* NAT友好性：只要终端实体的受保护身份信息不是IP/传输地址，DHHMAC就能够通过防火墙/NAT设备顺利运行。
* Scalability: Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not scale to any larger configurations beyond peer-to-peer groups.
* 可扩展性：与MIKEY签名的Diffie-Hellman协议一样，DHHMAC不能扩展到对等组之外的任何更大配置。
This document states a couple of assumptions upon which the security of DHHMAC significantly depends. The following conditions are assumed:
本文件陈述了DHHMAC安全性主要依赖的两个假设。假设以下条件：
* The parameters xi, xr, s, and auth_key are to be kept secret.
* 参数席XI、XR、S和AutoSKY都是保密的。
* The pre-shared key s has sufficient entropy and cannot be effectively guessed.
* 预共享密钥s具有足够的熵，无法有效地猜测。
* The pseudo-random function (PRF) is secure, yields the pseudo-random property, and maintains the entropy.
* 伪随机函数（PRF）是安全的，具有伪随机性，并保持熵。
* A sufficiently large and secure Diffie-Hellman group is applied.
* 应用了足够大且安全的Diffie-Hellman群。
* The Diffie-Hellman assumption holds saying basically that even with knowledge of the exchanged Diffie-Hellman half-keys and knowledge of the Diffie-Hellman group, it is infeasible to compute the TGK or to derive the secret parameters xi or xr. The latter is also called the discrete logarithm assumption. Please see [6], [9], or [10] for more background information regarding the Diffie-Hellman problem and its computational complexity assumptions.
* Diffie-Hellman假设基本上说即使知道交换Diffie-Hellman半密钥和Diffie-Hellman群的知识，计算TGK或导出秘密参数席或XR是不可行的。后者也称为离散对数假设。有关Diffie-Hellman问题及其计算复杂性假设的更多背景信息，请参见[6]、[9]或[10]。
* The hash function (SHA1) is secure; i.e., it is computationally infeasible to find a message that corresponds to a given message digest, or to find two different messages that produce the same message digest.
* 散列函数（SHA1）是安全的；i、 例如，在计算上不可能找到与给定消息摘要相对应的消息，也不可能找到生成相同消息摘要的两条不同消息。
* The HMAC algorithm is secure and does not leak the auth_key. In particular, the security depends on the message authentication property of the compression function of the hash function H when it is applied to single blocks (see [5]).
* HMAC算法是安全的，不会泄漏身份验证密钥。特别地，当哈希函数H应用于单个块时，安全性取决于哈希函数H的压缩函数的消息认证属性（参见[5]）。
* A source capable of producing sufficiently many bits of (pseudo) randomness is available.
* 能够产生足够多的（伪）随机比特的源是可用的。
* The system upon which DHHMAC runs is sufficiently secure.
* DHHMAC运行的系统足够安全。
Although these detailed assumptions are non-negligible, security experts generally believe that all these assumptions are reasonable and that the assumptions made can be fulfilled in practice with little or no expenses.
尽管这些详细的假设是不可忽略的，但安全专家普遍认为，所有这些假设都是合理的，并且所做的假设可以在实践中得到满足，几乎不需要或不需要任何费用。
The mathematical and cryptographic assumptions of the properties of the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the HMAC algorithm, and the SHA1 algorithms have been neither proven nor disproven at this time.
目前，PRF、Diffie-Hellman算法（离散对数假设）、HMAC算法和SHA1算法的数学和密码假设既没有得到证明也没有被推翻。
Thus, a certain residual risk remains, which might threaten the overall security at some unforeseeable time in the future.
因此，仍存在一定的剩余风险，可能在未来不可预见的时间威胁到整体安全。
The DHHMAC would be compromised as soon as any of the listed assumptions no longer hold.
一旦列出的任何假设不再成立，DHHMAC就会受到损害。
The Diffie-Hellman mechanism is a generic security technique that is not only applicable to groups of prime order or of characteristic two. This is because of the fundamental mathematical assumption that the discrete logarithm problem is also a very hard one in general groups. This enables Diffie-Hellman to be deployed also for GF(p)*, for sub-groups of sufficient size, and for groups upon elliptic curves. RSA does not allow such generalization, as the core mathematical problem is a different one (large integer factorization).
Diffie-Hellman机制是一种通用的安全技术，它不仅适用于素数阶或特征二阶的组。这是因为基本的数学假设，即离散对数问题在一般群体中也是一个非常困难的问题。这使得Diffie-Hellman也可以用于GF（p）*、足够大的子组以及椭圆曲线上的组。RSA不允许这种泛化，因为核心数学问题是另一个问题（大整数分解）。
RSA asymmetric keys tend to become increasingly lengthy (1536 bits and more) and thus very computationally intensive. Nevertheless, Elliptic Curve Diffie-Hellman (ECDH) allows key lengths to be cut down substantially (say 170 bits or more) while maintaining at least the security level and providing even more significant performance benefits in practice. Moreover, it is believed that elliptic-curve techniques provide much better protection against side channel attacks due to the inherent redundancy in the projective coordinates. For all these reasons, one may view elliptic-curve-based Diffie-Hellman as being more "future-proof" and robust against potential threats than RSA is. Note that Elliptic Curve Diffie-Hellman variants of MIKEY are defined in [31].
RSA非对称密钥往往变得越来越长（1536位或更多），因此计算量非常大。尽管如此，椭圆曲线Diffie-Hellman（ECDH）允许大幅缩短密钥长度（比如170位或更多），同时至少保持安全级别，并在实践中提供更显著的性能优势。此外，由于投影坐标中固有的冗余性，人们认为椭圆曲线技术提供了更好的保护，以抵抗侧信道攻击。由于所有这些原因，人们可能会认为基于椭圆曲线的Diffie-Hellman比RSA更“经得起未来的考验”，并且对潜在威胁更具鲁棒性。请注意[31]中定义了MIKEY的椭圆曲线Diffie-Hellman变体。
HMAC-SHA1 is a key security mechanism within DHHMAC on which the overall security of MIKEY DHHMAC depends. MIKEY DHHMAC uses HMAC-SHA1 in combination with the classic Diffie-Hellman key agreement scheme. HMAC-SHA1 is a keyed one-way hash function that involves a secret in its computation. DHHMAC applies HMAC-SHA1 for protection of the MIKEY payload. Likewise, the pseudo-random function PRF within MIKEY [2] uses the HMAC-SHA1 mechanism as a key derivation function. While certain attacks have been reported against SHA1 and MD5 (see [29]), with current knowledge (see [29], [30]), no attacks have been reported against the HMAC-SHA1 security mechanism. In fact, [32] proves that HMAC possesses the property of a pseudo-random function PRF assuming solely that the (SHA1) hash function is a pseudo-random function. [32] also provides evidence that HMAC is robust against collision attacks on the underlying hash function. It is believed that MIKEY DHHMAC should be considered secure enough for the time being. Thus, there is no need to change the underlying security mechanism within the MIKEY DHHMAC protocol.
HMAC-SHA1是DHHMAC中的一个关键安全机制，MIKEY DHHMAC的整体安全依赖于此。MIKEY DHHMAC将HMAC-SHA1与经典的Diffie-Hellman密钥协商方案结合使用。HMAC-SHA1是一个键控单向散列函数，其计算中包含一个秘密。DHHMAC使用HMAC-SHA1保护MIKEY有效载荷。同样，MIKEY[2]中的伪随机函数PRF使用HMAC-SHA1机制作为密钥派生函数。据报道，虽然有针对SHA1和MD5的某些攻击（见[29]），但据目前所知（见[29]，[30]），没有针对HMAC-SHA1安全机制的攻击报告。事实上，[32]证明了HMAC具有伪随机函数PRF的性质，假设（SHA1）散列函数是伪随机函数。[32]还提供了证据，证明HMAC对底层哈希函数的冲突攻击具有鲁棒性。据信，米奇·德哈迈克目前应该被认为是足够安全的。因此，无需更改MIKEY DHHMAC协议中的底层安全机制。
It is not recommended to deploy DHHMAC for any other use than that depicted in section 2. Any misapplication might lead to unknown, undefined properties.
不建议将DHHMAC用于第2节所述用途以外的任何其他用途。任何错误应用都可能导致未知、未定义的属性。
Basically, similar remarks on authorization as those stated in [2] section 4.3.2 hold also for DHHMAC. However, as noted before, this key management protocol does not serve full groups.
基本上，与[2]第4.3.2节所述类似的授权说明也适用于DHHMAC。但是，如前所述，此密钥管理协议不服务于整个组。
One may view the pre-established shared secret as yielding some pre-established trust relationship between the initiator and the responder. This results in a much simpler trust model for DHHMAC than would be the case for some generic group key management protocol and potential group entities without any pre-defined trust relationship. In conjunction with the assumption of a shared key, the common group controller simplifies the communication setup of the entities.
可以将预先建立的共享秘密视为在发起方和响应方之间产生某种预先建立的信任关系。这使得DHHMAC的信任模型比某些通用组密钥管理协议和没有任何预定义信任关系的潜在组实体的情况简单得多。结合共享密钥的假设，公共组控制器简化了实体的通信设置。
One may view the pre-established trust relationship through the pre-shared secret as some means for pre-granted, implied authorization. This document does not define any particular authorization means but leaves this subject to the application.
人们可以通过预先共享的秘密将预先建立的信任关系视为预先授予的默示授权的某种手段。本文件未定义任何特定的授权方式，但将此问题留给应用程序处理。
This document incorporates kindly, valuable review feedback from Steffen Fries, Hannes Tschofenig, Fredrick Lindholm, Mary Barnes, and Russell Housley and general feedback by the MSEC WG.
本文件包含Steffen Fries、Hannes Tschofenig、Fredrick Lindholm、Mary Barnes和Russell Housley的善意、有价值的审查反馈以及MSEC工作组的一般反馈。
This document does not define its own new name spaces for DHHMAC, beyond the IANA name spaces that have been assigned for MIKEY; see [2] sections 10 and 10.1 and IANA MIKEY payload name spaces [37].
除了为MIKEY分配的IANA名称空间外，本文件没有为DHHMAC定义自己的新名称空间；参见[2]第10节和第10.1节以及IANA MIKEY有效载荷名称空间[37]。
In order to align Table 4.1.a with Table 6.1.a in [2], IANA is requested to add the following entries to their MIKEY Payload Name Space:
为了使表4.1.a与[2]中的表6.1.a保持一致，请IANA在其MIKEY有效载荷名称空间中添加以下条目：
Data Type Value Reference
--------------- ----- ---------
DHHMAC init 7 RFC 4650
DHHMAC resp 8 RFC 4650
Data Type Value Reference
--------------- ----- ---------
DHHMAC init 7 RFC 4650
DHHMAC resp 8 RFC 4650
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[2] Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[3] NIST, FIBS-PUB 180-2, "Secure Hash Standard", April 1995, http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2withchangenotice.pdf.
[3] NIST，FIBS-PUB 180-2，“安全哈希标准”，1995年4月，http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2 WithChangeNotice.pdf。
[4] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[4] Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[6] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of Applied Cryptography", CRC Press 1996.
[6] A.J.Menezes，P.van Oorschot，S.A.Vanstone：“应用密码学手册”，CRC出版社1996年。
[7] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[7] Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[8] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[8] Eastlake 3rd，D.，Crocker，S.，和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[9] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", Designs, Codes, and Cryptography, Special Issue Public Key Cryptography, Kluwer Academic Publishers, vol. 19, pp. 147-171, 2000. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps.
[9] Ueli M.Maurer，S.Wolf：“Diffie-Hellman协议”，设计、代码和密码学，特刊公钥密码学，Kluwer学术出版社，第19卷，第147-171页，2000年。ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps.
[10] Discrete Logarithms and the Diffie-Hellman Protocol, http://www.crypto.ethz.ch/research/ntc/dldh/.
[10] 离散对数和Diffie-Hellman协议，http://www.crypto.ethz.ch/research/ntc/dldh/.
[11] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[11] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[12] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[12] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[13] 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.
[13] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[14] Kaufman，C.，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[15] ITU-T Recommendation H.235.7: " H.323 Security framework: Usage of the MIKEY Key Management Protocol for the Secure Real Time Transport Protocol (SRTP) within H.235"; 9/2005.
[15] ITU-T建议H.235.7：“H.323安全框架：H.235中安全实时传输协议（SRTP）的MIKEY密钥管理协议的使用”；9/2005.
[16] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[16] Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 33942002年9月。
[17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[17] Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的群体领域”，RFC 3547，2003年7月。
[18] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[18] Harney，H.，Meth，U.，Colegrove，A.，和G.Gross，“GSAKMP：组安全关联密钥管理协议”，RFC 45352006年6月。
[19] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[19] Baugher，M.，Canetti，R.，Dondeti，L.，和F.Lindholm，“多播安全（MSEC）组密钥管理体系结构”，RFC 4046，2005年4月。
[20] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[20] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[21] ITU-T Recommendation H.235.0, " H.323 Security framework: Security framework for H-series (H.323 and other H.245 based) multimedia systems", (09/2005).
[21] ITU-T建议H.235.0，“H.323安全框架：H系列（H.323和其他基于H.245的）多媒体系统的安全框架”（09/2005）。
[22] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[22] Adams，C.，Farrell，S.，Kause，T.，和T.Mononen，“互联网X.509公钥基础设施证书管理协议（CMP）”，RFC 42102005年9月。
[23] 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.
[23] 迈尔斯，M.，安克尼，R.，马尔帕尼，A.，加尔佩林，S.，和C.亚当斯，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC2560，1999年6月。
[24] Adams, C., Sylvester, P., Zolotarev, M., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols", RFC 3029, February 2001.
[24] Adams，C.，Sylvester，P.，Zolotarev，M.，和R.Zuccherato，“互联网X.509公钥基础设施数据验证和认证服务器协议”，RFC 3029，2001年2月。
[25] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[25] Schaad，J.，“Internet X.509公钥基础设施证书请求消息格式（CRMF）”，RFC 4211，2005年9月。
[26] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, September 2005.
[26] Cooper，M.，Dzambasow，Y.，Hesse，P.，Joseph，S.，和R.Nicholas，“互联网X.509公钥基础设施：认证路径构建”，RFC 4158，2005年9月。
[27] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[27] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[37] IANA MIKEY Payload Name Spaces per RFC 3830, see http://www.iana.org/assignments/mikey-payloads.
[37] 根据RFC 3830的IANA MIKEY有效负载名称空间，请参见http://www.iana.org/assignments/mikey-payloads.
[29] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[29] Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[30] Bellovin, S.M. and E.K. Rescorla: "Deploying a New Hash Algorithm", October 2005, http://www.cs.columbia.edu/~smb/papers/new-hash.pdf.
[30] Bellovin，S.M.和E.K.Rescorla：“部署新的哈希算法”，2005年10月，http://www.cs.columbia.edu/~smb/papers/new-hash.pdf。
[31] Milne, A., Blaser, M., Brown, D., and L. Dondetti, "ECC Algorithms For MIKEY", Work in Progress, June 2005.
[31] Milne，A.，Blaser，M.，Brown，D.，和L.Dondetti，“MIKEY的ECC算法”，正在进行的工作，2005年6月。
[32] Bellare, M.: "New Proofs for NMAC and HMAC: Security Without Collision-Resistance", http://eprint.iacr.org/2006/043.pdf, November 2005.
[32] Bellare，M.：“NMAC和HMAC的新证明：无碰撞阻力的安全性”，http://eprint.iacr.org/2006/043.pdf，2005年11月。
[33] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "An additional mode of key Distribution in MIKEY: MIKEY-RSA-R", Work in Progress, August 2006.
[33] Ignjatic，D.，Dondeti，L.，Audet，F.，和P.Lin，“MIKEY中的另一种密钥分发模式：MIKEY-RSA-R”，正在进行的工作，2006年8月。
This appendix provides informative overview how MIKEY-DHHMAC can be applied in some H.323-based multimedia environments. Generally, MIKEY is applicable for multimedia applications including IP telephony. [15] describes various use cases of the MIKEY key management protocols (MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY-DHHMAC) with the purpose to establish TGK keying material among H.323 endpoints. The TGKs are then used for media encryption by applying SRTP [20]. Addressed scenarios include point-to-point with one or more intermediate gatekeepers (trusted or partially trusted) in between.
本附录提供了MIKEY-DHHMAC如何在一些基于H.323的多媒体环境中应用的详细概述。通常，MIKEY适用于多媒体应用，包括IP电话。[15] 描述了MIKEY密钥管理协议（MIKEY-PS、MIKEY-PK、MIKEY-DHSIGN和MIKEY-DHHMAC）的各种用例，目的是在H.323端点之间建立TGK密钥材料。然后通过应用SRTP将TGK用于媒体加密[20]。解决的场景包括点对点，中间有一个或多个中间网关守卫（受信任或部分受信任）。
One particular use case addresses MIKEY-DHHMAC to establish a media connection from an endpoint B calling (through a gatekeeper) to another endpoint A that is located within that same gatekeeper zone. While EP-A and EP-B typically do not share any auth_key a priori, some separate protocol exchange means are achieved outside the actual call setup procedure to establish an auth_key for the time while endpoints are being registered with the gatekeeper; such protocols exist [15] but are not shown in this document. The auth_key between the endpoints is being used to authenticate and integrity protect the MIKEY-DHHMAC messages.
一个特定的用例寻址MIKEY-DHHMAC，以建立从端点B呼叫（通过网守）到位于同一网守区域内的另一端点a的媒体连接。虽然EP-A和EP-B通常事先不共享任何认证密钥，但在实际呼叫建立过程之外实现了一些单独的协议交换手段，以在端点向网守注册时建立认证密钥；此类协议存在[15]，但本文件中未显示。端点之间的auth_密钥用于对MIKEY-DHHMAC消息进行身份验证和完整性保护。
To establish a call, it is assumed that endpoint B has obtained permission from the gatekeeper (not shown). Endpoint B as the caller builds the MIKEY-DHHMAC I_message (see section 3) and sends the I_message encapsulated within the H.323-SETUP to endpoint A. A routing gatekeeper (GK) would forward this message to endpoint B; in case of a non-routing gatekeeper, endpoint B sends the SETUP directly to endpoint A. In either case, H.323 inherent security mechanisms [21] are applied to protect the (encapsulation) message during transfer. This is not depicted here. The receiving endpoint A is able to verify the conveyed I_message and can compute a TGK. Assuming that endpoint A would accept the call, EP-A then builds the MIKEY-DHHMAC R_message and sends the response as part of the CallProceeding-to-Connect message back to the calling endpoint B (possibly through a routing gatekeeper). Endpoint B processes the conveyed R_message to compute the same TGK as the called endpoint A.
要建立呼叫，假定端点B已获得网守的许可（未显示）。端点B作为调用者构建MIKEY-DHHMAC I_消息（参见第3节），并将封装在H.323设置中的I_消息发送到端点A。路由网关守护者（GK）将该消息转发给端点B；对于非路由网守，端点B将设置直接发送到端点a。在任何一种情况下，H.323固有的安全机制[21]都被应用于在传输期间保护（封装）消息。这里没有描述这一点。接收端点A能够验证传送的I_消息，并且能够计算TGK。假设端点A将接受呼叫，EP-A然后构建MIKEY-DHHMAC R_消息，并将响应作为呼叫过程的一部分发送，以将消息连接回呼叫端点B（可能通过路由网守）。端点B处理传递的R_消息以计算与被调用端点A相同的TGK。
1.) EP-B -> (GK) -> EP-A: SETUP(I_fwd_message [, I_rev_message])
2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message
[, R_rev_message])
1.) EP-B -> (GK) -> EP-A: SETUP(I_fwd_message [, I_rev_message])
2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message
[, R_rev_message])
Notes: If it is necessary to establish directional TGKs for full-duplex links in both directions B->A and A->B, then the calling endpoint B instantiates the DHHMAC protocol twice: once in the direction B->A using I_fwd_message and another run
注意：如果有必要在B->A和A->B两个方向上为全双工链路建立定向TGK，则调用端点B实例化DHHMAC协议两次：一次在B->A方向使用I_fwd_消息，另一次运行
in parallel in the direction A->B using I_rev_message. In that case, two MIKEY-DHHMAC I_messages are encapsulated within SETUP (I_fwd_message and I_rev_message) and two MIKEY-DHHMAC R_messages (R_fwd_message and R_rev_message) are encapsulated within CallProceeding-to-CONNECT. The I_rev_message corresponds with the I_fwd_message. Alternatively, the called endpoint A may instantiate the DHHMAC protocol in a separate run with endpoint B (not shown); however, this requires a third handshake to complete.
使用I_rev_消息沿A->B方向平行运行。在这种情况下，两条MIKEY-DHHMAC I_消息封装在设置中（I_-fwd_消息和I_-rev_消息），两条MIKEY-DHHMAC R_消息（R_-fwd_消息和R_-rev_消息）封装在CallProcessing中进行连接。I_rev_消息与I_fwd_消息相对应。或者，被调用的端点A可以在与端点B（未示出）的单独运行中实例化DHHMAC协议；但是，这需要第三次握手才能完成。
For more details on how the MIKEY protocols may be deployed with H.235, please refer to [15].
有关如何使用H.235部署MIKEY协议的更多详细信息，请参阅[15]。
Author's Address
作者地址
Martin Euchner Hofmannstr. 51 81359 Munich, Germany
马丁·欧希纳·霍夫曼斯特。51 81359德国慕尼黑
Phone: +49 89 722 55790
Fax: +49 89 722 62366
EMail: martin_euchner@hotmail.com
Phone: +49 89 722 55790
Fax: +49 89 722 62366
EMail: martin_euchner@hotmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。