Internet Engineering Task Force (IETF) J. Mattsson
Request for Comments: 6043 Ericsson
Category: Informational T. Tian
ISSN: 2070-1721 ZTE
March 2011
Internet Engineering Task Force (IETF) J. Mattsson
Request for Comments: 6043 Ericsson
Category: Informational T. Tian
ISSN: 2070-1721 ZTE
March 2011
MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
MIKEY-TICKE：多媒体互联网密钥分配（MIKEY）中基于票据的密钥分配模式
Abstract
摘要
The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing. Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session.
多媒体互联网密钥（MIKEY）规范描述了一种用于实时应用的密钥管理方案。在本文档中，我们注意到当前定义的MIKEY模式不足以解决围绕集中式密钥管理服务构建的部署场景。对此类部署的兴趣正在增加。因此，定义了一组在此类场景中工作良好的新MIKEY模式。新模式使用可信密钥管理服务和票证概念，类似于Kerberos中的概念。新模式还支持许多现有应用程序使用的功能，其中在通信会话开始时可能不知道另一个端点的确切身份。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6043.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6043.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................4
2.1. Definitions and Notation ...................................5
2.2. Abbreviations ..............................................6
2.3. Payloads ...................................................6
3. Design Considerations ...........................................7
4. MIKEY-TICKET ....................................................9
4.1. Overview ...................................................9
4.1.1. Modes ..............................................12
4.2. Exchanges .................................................13
4.2.1. Ticket Request .....................................13
4.2.2. Ticket Transfer ....................................16
4.2.3. Ticket Resolve .....................................19
5. Key Management Functions .......................................23
5.1. Key Derivation ............................................23
5.1.1. Deriving Forked Keys ...............................25
5.1.2. Deriving Keys from an Envelope Key/PSK/MPK .........26
5.1.3. Deriving Keys from a TGK/GTGK ......................27
5.2. CSB Updating ..............................................28
5.3. Ticket Reuse ..............................................29
5.4. Error Handling ............................................29
5.5. MAC/Signature Coverage ....................................30
6. Payload Encoding ...............................................31
6.1. Common Header Payload (HDR) ...............................31
6.1.1. The GENERIC-ID Map Type ............................33
6.2. Key Data Transport Payload (KEMAC) ........................34
6.2.1. Key Data Sub-Payload ...............................35
6.3. Timestamp Payload (T) .....................................36
6.4. Timestamp Payload with Role Indicator (TR) ................36
6.5. ID Payload (ID) ...........................................37
6.6. ID Payload with Role Indicator (IDR) ......................37
1. Introduction ....................................................4
2. Terminology .....................................................4
2.1. Definitions and Notation ...................................5
2.2. Abbreviations ..............................................6
2.3. Payloads ...................................................6
3. Design Considerations ...........................................7
4. MIKEY-TICKET ....................................................9
4.1. Overview ...................................................9
4.1.1. Modes ..............................................12
4.2. Exchanges .................................................13
4.2.1. Ticket Request .....................................13
4.2.2. Ticket Transfer ....................................16
4.2.3. Ticket Resolve .....................................19
5. Key Management Functions .......................................23
5.1. Key Derivation ............................................23
5.1.1. Deriving Forked Keys ...............................25
5.1.2. Deriving Keys from an Envelope Key/PSK/MPK .........26
5.1.3. Deriving Keys from a TGK/GTGK ......................27
5.2. CSB Updating ..............................................28
5.3. Ticket Reuse ..............................................29
5.4. Error Handling ............................................29
5.5. MAC/Signature Coverage ....................................30
6. Payload Encoding ...............................................31
6.1. Common Header Payload (HDR) ...............................31
6.1.1. The GENERIC-ID Map Type ............................33
6.2. Key Data Transport Payload (KEMAC) ........................34
6.2.1. Key Data Sub-Payload ...............................35
6.3. Timestamp Payload (T) .....................................36
6.4. Timestamp Payload with Role Indicator (TR) ................36
6.5. ID Payload (ID) ...........................................37
6.6. ID Payload with Role Indicator (IDR) ......................37
6.7. Cert Hash Payload (CHASH) .................................38
6.8. RAND Payload with Role Indicator (RANDR) ..................38
6.9. Error Payload (ERR) .......................................39
6.10. Ticket Policy Payload (TP) / Ticket Payload (TICKET) .....39
7. Transport Protocols ............................................43
8. Pre-Encrypted Content ..........................................43
9. Group Communication ............................................44
9.1. Key Forking ...............................................45
10. Signaling between Different KMSs ..............................45
11. Adding New Ticket Types to MIKEY-TICKET .......................46
12. Security Considerations .......................................47
12.1. General ..................................................47
12.2. Key Forking ..............................................48
12.3. Denial of Service ........................................49
12.4. Replay ...................................................49
12.5. Group Key Management .....................................50
13. Acknowledgements ..............................................50
14. IANA Considerations ...........................................50
15. References ....................................................53
15.1. Normative References .....................................53
15.2. Informative References ...................................53
Appendix A. MIKEY Base Ticket ....................................55
A.1. Components of the Ticket Data .............................55
A.2. Key Derivation ............................................56
A.2.1. Deriving Keys from a TPK ..............................56
A.2.2. Deriving MPKi and MPKr ................................57
A.3. Ticket Header Payload (THDR) ..............................57
Appendix B. Alternative Use Cases ................................58
B.1. Compatibility Mode ........................................58
6.7. Cert Hash Payload (CHASH) .................................38
6.8. RAND Payload with Role Indicator (RANDR) ..................38
6.9. Error Payload (ERR) .......................................39
6.10. Ticket Policy Payload (TP) / Ticket Payload (TICKET) .....39
7. Transport Protocols ............................................43
8. Pre-Encrypted Content ..........................................43
9. Group Communication ............................................44
9.1. Key Forking ...............................................45
10. Signaling between Different KMSs ..............................45
11. Adding New Ticket Types to MIKEY-TICKET .......................46
12. Security Considerations .......................................47
12.1. General ..................................................47
12.2. Key Forking ..............................................48
12.3. Denial of Service ........................................49
12.4. Replay ...................................................49
12.5. Group Key Management .....................................50
13. Acknowledgements ..............................................50
14. IANA Considerations ...........................................50
15. References ....................................................53
15.1. Normative References .....................................53
15.2. Informative References ...................................53
Appendix A. MIKEY Base Ticket ....................................55
A.1. Components of the Ticket Data .............................55
A.2. Key Derivation ............................................56
A.2.1. Deriving Keys from a TPK ..............................56
A.2.2. Deriving MPKi and MPKr ................................57
A.3. Ticket Header Payload (THDR) ..............................57
Appendix B. Alternative Use Cases ................................58
B.1. Compatibility Mode ........................................58
Key management systems are either based on negotiation and exchange directly between peers (e.g., Diffie-Hellman-based schemes), pre-distribution of user credentials (shared secrets/certificates), or availability of a trusted Key Management Service (KMS). The modes described in the Multimedia Internet KEYing (MIKEY) specification [RFC3830] and its extensions [RFC4650] [RFC4738] are all variants of the first two alternatives.
密钥管理系统要么基于对等方之间的直接协商和交换（例如，基于Diffie-Hellman的方案）、用户凭证（共享机密/证书）的预分发，要么基于可信密钥管理服务（KMS）的可用性。多媒体互联网键控（MIKEY）规范[RFC3830]及其扩展[RFC4650][RFC4738]中描述的模式都是前两个备选方案的变体。
In security systems serving a large number of users, a solution based on a key management service is often preferred. With such a service in place, there is no need to pre-distribute credentials that directly can be used to establish security associations between peers for protected communication, as users can request such credentials when needed. Solutions based on a trusted key management service also scale well when the number of users grows.
在为大量用户服务的安全系统中，通常首选基于密钥管理服务的解决方案。有了这样的服务，就不需要预先分发可直接用于在对等方之间建立安全关联以进行受保护通信的凭据，因为用户可以在需要时请求此类凭据。当用户数量增加时，基于可信密钥管理服务的解决方案也能很好地扩展。
This document introduces a set of new MIKEY modes that go under the common name MIKEY-TICKET. The new modes support a ticket concept, similar to that in Kerberos [RFC4120], which is used to identify and deliver keys. A high-level outline of MIKEY-TICKET as defined herein is that the Initiator requests keys and a ticket from the KMS and sends the ticket to the Responder. The ticket contains a reference to the keys, or the enveloped keys. The Responder then sends the ticket to the KMS, which returns the appropriate keys.
本文档介绍了一组新的MIKEY模式，其通用名称为MIKEY-TICKET。新模式支持票证概念，类似于Kerberos[RFC4120]中的票证概念，用于识别和传递密钥。本文定义的MIKEY-TICKET的高级概要是发起方从KMS请求密钥和票据，并将票据发送给响应方。票证包含对钥匙或封装钥匙的引用。然后，响应者将票据发送到KMS，KMS返回相应的密钥。
MIKEY-TICKET is primarily designed to be used for media plane security in the 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS) [3GPP.33.328]. This implies that some extensions to the basic Kerberos concept are needed. For instance, the Initiator may not always know the exact identity of the Responder when the communication with the key management server is initiated.
MIKEY-TICKET主要设计用于第三代合作伙伴项目（3GPP）IP多媒体子系统（IMS）[3GPP.33.328]中的媒体平面安全。这意味着需要对基本Kerberos概念进行一些扩展。例如，当启动与密钥管理服务器的通信时，发起方可能并不总是知道响应方的确切身份。
This document defines a signaling framework enabling peers to request, transfer, and resolve various Ticket Types using a key management service. A default Ticket Type is also defined. To allow the use of 256-bit keys for users with high security requirements, additional encryption, authentication, and pseudorandom functions are defined. And to eliminate the limitations with the existing SRTP-ID map type, a new CS ID map type called GENERIC-ID is defined.
本文档定义了一个信令框架，使对等方能够使用密钥管理服务请求、传输和解析各种票据类型。还定义了默认票证类型。为了允许具有高安全性要求的用户使用256位密钥，定义了额外的加密、身份验证和伪随机函数。为了消除现有SRTP-ID映射类型的限制，定义了一种称为GENERIC-ID的新CS-ID映射类型。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Definitions of terms and notation will, unless otherwise stated, be as defined in [RFC3830].
除非另有说明，否则术语和符号的定义应符合[RFC3830]的定义。
Forking: The delivery of a request to multiple endpoints (multiple devices owned by a single user or multiple users).
分叉：将请求传递到多个端点（单个用户或多个用户拥有的多个设备）。
Key forking: When used in conjunction with forking, key forking refers to the process of modifying keys, making them cryptographically unique for each responder targeted by the forking.
密钥分叉：当与分叉一起使用时，密钥分叉指的是修改密钥的过程，使密钥在密码上对于分叉所针对的每个响应者都是唯一的。
(Media) session: The communication session intended to be secured by the MIKEY-TICKET provided key(s).
（媒体）会话：由MIKEY-TICKET提供的密钥保护的通信会话。
Session information: Information related to the security protocols used to protect the media session: keys, salts, algorithms, etc.
会话信息：与用于保护媒体会话的安全协议相关的信息：密钥、盐、算法等。
Ticket: A Kerberos-like object used to identify and deliver keys over an untrusted network.
票证：类似Kerberos的对象，用于在不受信任的网络上标识和传递密钥。
Ticket Data: Ticket part with information intended only for the party that resolves the ticket (e.g., keys).
票证数据：包含信息的票证部分，仅用于解决票证的一方（如钥匙）。
Ticket Request: Exchange used by the Initiator to request keys and a ticket from a trusted KMS.
票证请求：发起人用于从受信任的KMS请求密钥和票证的交换。
Ticket Transfer: Exchange used to transfer the ticket as well as session information from the Initiator to the Responder.
票证传输：用于将票证和会话信息从发起方传输到响应方的交换。
Ticket Resolve: Exchange used by the Responder to request the KMS to return the keys encoded in a ticket.
票证解析：响应者用于请求KMS返回票证中编码的密钥的交换。
Ticket Policy: Policy for ticket generation and resolution, authorized applications, key derivation, etc.
票证策略：用于票证生成和解析、授权应用程序、密钥派生等的策略。
Ticket Type: Defines ticket format and processing. May further have subtype and version.
票证类型：定义票证格式和处理。可能还有子类型和版本。
Solid arrows (----->) indicate mandatory messages.
Dashed arrows (- - ->) indicate optional messages.
Solid arrows (----->) indicate mandatory messages.
Dashed arrows (- - ->) indicate optional messages.
E(k, p) Encryption of p with the key k PKx Public Key of entity x k' The forked key k [p] p is optional {p} Zero or more occurrences of p (p) One or more occurrences of p
E（k，p）使用实体x k'的密钥k PKx公钥对p进行加密分叉密钥k[p]p是可选的{p}p的零次或多次出现p（p）的一次或多次出现p
|| Concatenation | OR (selection operator)
||串联|或（选择运算符）
3GPP: 3rd Generation Partnership Project AAA: Authentication, Authorization, and Accounting ACL: Access Control List AES: Advanced Encryption Standard CA: Certification Authority CS: Crypto Session CSB: Crypto Session Bundle IMS: IP Multimedia Subsystem GTGK: Group TGK HMAC: Hash-based Message Authentication Code KMS: Key Management Service MAC: Message Authentication Code MIKEY: Multimedia Internet KEYing NSPS: National Security and Public Safety MKI: Master Key Identifier MPK: MIKEY Protection Key NTP: Network Time Protocol PET: Privacy Enhancing Technologies PK: Public Key PRF: Pseudorandom Function PRNG: Pseudorandom Number Generator PSK: Pre-Shared Key RTSP: Real Time Streaming Protocol SDP: Session Description Protocol SHA: Secure Hash Algorithm SIP: Session Initiation Protocol SPI: Security Parameters Index SRTP: Secure Realtime Transport Protocol TEK: Traffic Encryption Key TGK: TEK Generation Key TPK: Ticket Protection Key UTC: Coordinated Universal Time
3GPP：第三代合作伙伴项目AAA：认证、授权、，和记帐ACL:访问控制列表AES:高级加密标准CA:证书颁发机构CS:加密会话CSB:加密会话包IMS:IP多媒体子系统GTGK:组TGK HMAC:基于哈希的消息身份验证代码KMS:密钥管理服务MAC:消息身份验证代码MIKEY:多媒体互联网密钥NSPS:国家安全和公共安全MKI:主密钥标识符MPK:MIKEY保护密钥NTP:网络时间协议PET:隐私增强技术PK:公钥PRF:伪随机函数PRNG:伪随机数生成器PSK:预共享密钥RTSP:实时流协议SDP:会话描述协议SHA:安全哈希算法SIP:会话启动协议SPI:安全参数索引SRTP:安全实时传输协议TEK:流量加密密钥TGK:TEK生成密钥TPK:票证保护密钥UTC:协调世界时
CERTx: Certificate of entity x CHASH: Hash of the certificate used HDR: Common Header payload ID: Identity payload IDRx: Identifier for entity x IDRpsk: Identifier for pre-shared key IDRapp: Identifier for application/service KEMAC: Key data transport payload
CERTx:Certificate of entity x CHASH:Hash of Certificate使用HDR:Common Header payload ID:Identity payload IDRx:Identity x IDRpsk:Identifier for entity x IDRpsk:Identifier for pre-shared key IDRapp:Identifier for application/service KEMAC:key data transport payload
PKE: Encrypted envelope key RAND: RAND payload RANDRx: Random value generated by entity x SIGNx: Signature created using entity x's private key SP: Security Policy payload T: Timestamp payload TRy: Timestamp payload with role indicator y THDR: Ticket Header payload TICKET: Ticket payload TP: Ticket Policy payload V: Verification payload
PKE：加密信封密钥RAND:RAND payload RANDRx:entity x生成的随机值SIGNx:Signature使用entity x的私钥创建SP:Security Policy payload T:Timestamp payload TRy:Timestamp payload with role indicator y THDR:Ticket Header payload Ticket:Ticket payload TP:Ticket Policy payload V:Verification payload
where x is in the set {i, r, kms} (Initiator, Responder, KMS) and y is in the set {i, s, e, r} (time of Issue, Start time, End time, Rekeying interval).
其中，x在集合{i，r，kms}（发起方，响应方，kms）中，y在集合{i，s，e，r}（发出时间，开始时间，结束时间，重新键入间隔）中。
The IDR, RANDR, TR, TICKET, and TP payloads are defined in Section 6. Note that in [RFC3830], there is defined both a V payload (carrying the authentication tag) and a V flag in the HDR payload (indicating whether or not a response message is expected).
第6节定义了IDR、RANDR、TR、TICKET和TP有效载荷。注意，在[RFC3830]中，在HDR有效载荷中定义了V有效载荷（携带认证标签）和V标志（指示是否期望响应消息）。
As mentioned in the introduction, none of the previously defined MIKEY modes are based on a KMS. The pre-shared key method and the public-key encryption method defined in [RFC3830] are examples of systems based on pre-distribution of user credentials. The Diffie-Hellman method [RFC3830] is an example of a system based on negotiation and exchange directly between peers.
如引言中所述，之前定义的所有MIKEY模式都不是基于KMS的。[RFC3830]中定义的预共享密钥方法和公钥加密方法是基于用户凭证预分发的系统示例。Diffie-Hellman方法[RFC3830]是基于对等点之间直接协商和交换的系统示例。
In some situations, a request may be delivered to multiple endpoints. The endpoints may be multiple devices owned by a single user (e.g., mobile phone, fixed phone, and computer), or multiple users (e.g., IT-support@example.com, a group of users where only one is supposed to answer). In the following, the term "forking" will be used to describe all such cases. One example of delivery to multiple endpoints is forking and retargeting in SIP [RFC3261]. To prevent any form of eavesdropping, only the endpoint that answers should get access to the session keys. The naive application of [RFC3830] where all endpoints share the same pre-shared/private key is not secure when it comes to forking, as all endpoints get access to the session keys. Conversely, having per-user unique pre-shared keys/ certificates creates more fundamental problems with forking, as the initiator does not know which pre-shared key/certificate to use at session initiation. SIP-signaled media protection is described in [RFC5479] and the applicability of different MIKEY modes is discussed in [RFC5197].
在某些情况下，请求可能会传递到多个端点。端点可以是由单个用户（例如，移动电话、固定电话和计算机）或多个用户（例如，IT）拥有的多个设备-support@example.com，一组用户，其中只有一个应该回答）。在下文中，术语“分叉”将用于描述所有此类情况。SIP[RFC3261]中的一个交付到多个端点的示例是分叉和重定目标。为了防止任何形式的窃听，只有应答的端点才能访问会话密钥。[RFC3830]中所有端点共享相同的预共享/私钥的幼稚应用程序在分叉时并不安全，因为所有端点都可以访问会话密钥。相反，拥有每个用户唯一的预共享密钥/证书会产生更基本的分叉问题，因为启动器不知道在会话启动时使用哪个预共享密钥/证书。[RFC5479]中描述了SIP信号媒体保护，并在[RFC5197]中讨论了不同MIKEY模式的适用性。
In security systems serving a large number of users, a solution based on a key management service is often preferred. With such a service in place, there is no need to pre-distribute credentials that directly can be used to establish security associations between peers for protected communication, as users can request such credentials when needed. In many applications, e.g., National Security and Public Safety (NSPS), the controlling organization wants to enforce policies on the use of keys. A trusted KMS fits these applications well, as it makes it easier to enforce policies centrally. Solutions based on a trusted KMS also scale well when the number of users grows. A KMS based on symmetric keys has particular advantages, as symmetric key algorithms are generally much less computationally intensive than asymmetric key algorithms.
在为大量用户服务的安全系统中，通常首选基于密钥管理服务的解决方案。有了这样的服务，就不需要预先分发可直接用于在对等方之间建立安全关联以进行受保护通信的凭据，因为用户可以在需要时请求此类凭据。在许多应用中，例如国家安全和公共安全（NSPS），控制组织希望强制执行密钥使用政策。受信任的KMS非常适合这些应用程序，因为它使集中实施策略更加容易。当用户数量增加时，基于可信KMS的解决方案也能很好地扩展。基于对称密钥的KMS具有特殊的优势，因为对称密钥算法通常比非对称密钥算法计算量小得多。
Systems based on a KMS require a signaling mechanism that allows peers to retrieve other peers' credentials. A convenient way to implement such a signaling scheme is to use a ticket concept, similar to that in Kerberos [RFC4120] to identify and deliver keys. The ticket can be forwarded in the signaling associated with the session setup. The initiator requests a ticket from the KMS and sends the ticket to the responder. The responder forwards the ticket to the KMS, which returns the corresponding keys.
基于KMS的系统需要一种信令机制，允许对等方检索其他对等方的凭证。实现这种信令方案的一种方便方法是使用票证概念，类似于Kerberos[RFC4120]中的票证概念来识别和传递密钥。票证可以在与会话设置相关联的信令中转发。发起方从KMS请求票证，并将票证发送给响应方。响应者将票据转发给KMS，KMS返回相应的密钥。
It should be noted that Kerberos does not require that the responder also contact the KMS. However, in order to support also the aforementioned forking scenarios, it becomes necessary that the ticket is not bound to the exact identity (or credentials) of the responder until the final responder becomes fully determined. Group and forking communication scenarios can also be improved from access control point of view if authorization to access the keys can be enforced with higher granularity at the responder side. The mechanism specified in this document is useful for any system where the initial message may be transferred to arbitrarily many potential responders and where the set of responders may change at any time. In addition to being able to meet the requirements just described, the mechanism specified in this document also supports group key management.
应该注意，Kerberos不要求响应者也联系KMS。然而，为了支持上述分叉场景，在最终响应者完全确定之前，票据不必绑定到响应者的确切身份（或凭证）。如果可以在响应方以更高的粒度强制执行访问密钥的授权，那么从访问控制的角度来看，还可以改进组和分叉通信场景。本文件中规定的机制适用于任何系统，其中初始消息可传输至任意多个潜在响应者，且响应者集可随时更改。除了能够满足刚才描述的要求外，本文档中指定的机制还支持组密钥管理。
The ticket can contain a reference to keys held by the key management system or it can hold the keys itself. In the latter case, the ticket needs to be confidentiality and integrity protected (enveloped). In the following, the term "encoded keys" will be used to describe both cases as well as keys derived from such keys.
票据可以包含对密钥管理系统持有的密钥的引用，也可以包含密钥本身。在后一种情况下，票据需要保密和完整性保护（封装）。在下文中，术语“编码密钥”将用于描述这两种情况以及从这些密钥派生的密钥。
By using different Ticket Types and ticket policies, some allowing the initiator or responder to create or resolve the tickets without assistance from the KMS, a wide range of different security levels
通过使用不同的票证类型和票证策略，一些允许发起者或响应者在没有KMS协助的情况下创建或解析票证，这些票证具有广泛的不同安全级别
and use cases can be supported. This has a number of advantages, as it offers a framework that is flexible enough to satisfy users with a broad range of security and functional needs.
并且可以支持用例。这有很多优点，因为它提供了一个足够灵活的框架，可以满足用户广泛的安全和功能需求。
The use of a ticket-based system may also help in the handling of keys for deferred delivery of end-to-end protected content to currently offline users. Such scenarios exclude all key management schemes that are based on some type of direct online negotiation between peers (e.g., Diffie-Hellman-based schemes) as the responder cannot rely on contacting the initiator to get access to keys.
使用基于票据的系统还可以帮助处理密钥，以便将端到端受保护的内容延迟交付给当前脱机用户。此类场景排除了基于对等方之间某种类型的直接在线协商的所有密钥管理方案（例如，基于Diffie-Hellman的方案），因为响应方无法依靠联系发起方来访问密钥。
At the same time, it is also important to be aware that (centralized) key management services may introduce a single point of (security) failure. The security requirements on the implementation and protection of the KMS may therefore, in high-security applications, be more or less equivalent to the requirements of an AAA (Authentication, Authorization, and Accounting) server or a Certification Authority (CA).
同时，还必须注意，（集中式）密钥管理服务可能会导致单点（安全）故障。因此，在高安全性应用中，对KMS的实现和保护的安全要求可能或多或少等同于AAA（认证、授权和记帐）服务器或证书颁发机构（CA）的要求。
All previously defined MIKEY modes consist of a single (or half) round trip between two peers. MIKEY-TICKET differs from these modes as it consists of up to three different round trips (Ticket Request, Ticket Transfer, and Ticket Resolve) involving three parties (Initiator, Responder, and KMS). Since the number of round trips and order of messages may vary, MIKEY-TICKET is actually the common name for a set of modes, all revolving around a ticket concept. The third party, the KMS, is only involved in some of the MIKEY exchanges and not at all in the resulting secure media session. The Ticket Request and Ticket Resolve exchanges are meant to be used in combination with the Ticket Transfer exchange and not on their own. In Figure 1, the signaling for the full three round-trip MIKEY-TICKET mode is depicted.
所有先前定义的MIKEY模式都由两个对等方之间的一次（或半次）往返组成。MIKEY-TICKE与这些模式不同，因为它最多包含三个不同的往返（票证请求、票证转移和票证解析），涉及三方（发起方、响应方和KMS）。由于往返次数和消息顺序可能不同，MIKEY-TICKET实际上是一组模式的通用名称，所有模式都围绕着一个TICKET概念。第三方KMS只参与了部分MIKEY交流，而根本不参与由此产生的安全媒体对话。票证请求和票证解析交换旨在与票证转账交换结合使用，而不是单独使用。在图1中，描述了全三个往返MIKEY-TICKET模式的信令。
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
REQUEST_INIT
-------------------------------->
REQUEST_RESP
<--------------------------------
TRANSFER_INIT
---------------------------------------------------------------->
RESOLVE_INIT
<--------------------------------
RESOLVE_RESP
-------------------------------->
TRANSFER_RESP
<----------------------------------------------------------------
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
REQUEST_INIT
-------------------------------->
REQUEST_RESP
<--------------------------------
TRANSFER_INIT
---------------------------------------------------------------->
RESOLVE_INIT
<--------------------------------
RESOLVE_RESP
-------------------------------->
TRANSFER_RESP
<----------------------------------------------------------------
Figure 1: Full three round-trip signaling
图1：全三个往返信号
The Initiator (I) wants to establish a secure media session with the Responder (R). The Initiator and the Responder do not share any credentials; instead, they trust a third party, the KMS, with which they both have or can establish shared credentials. These pre-established trust relations are used to establish a security association between I and R. The assumed trust model is illustrated in Figure 2.
发起方（I）希望与响应方（R）建立安全的媒体会话。发起方和响应方不共享任何凭据；相反，他们信任第三方KMS，他们都拥有或可以建立共享凭证。这些预先建立的信任关系用于在I和R之间建立安全关联。假定的信任模型如图2所示。
Pre-established trust relation Pre-established trust relation
<------------------------------> <------------------------------>
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
<--------------------------------------------------------------->
Security association based on ticket
Pre-established trust relation Pre-established trust relation
<------------------------------> <------------------------------>
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
<--------------------------------------------------------------->
Security association based on ticket
Figure 2: Trust model
图2：信任模型
Note that rather than a single KMS, multiple KMSs may be involved, e.g., one for the Initiator and one for the Responder; this is discussed in Section 10.
注意，与单个KMS不同，可能涉及多个KMS，例如，一个用于发起方，一个用于响应方；第10节对此进行了讨论。
The Initiator requests keys and a ticket (encoding the same keys) from the KMS by sending a REQUEST_INIT message. The REQUEST_INIT message includes session information (e.g., identities of the authorized responders) and is integrity protected by a MAC based on a pre-shared key or by a signature (similar to the pre-shared key and public-key encryption modes in [RFC3830]). If the request is authorized, the KMS generates the requested keys, encodes them in a ticket, and returns the keys and the ticket in a REQUEST_RESP
启动器通过发送请求初始化消息从KMS请求密钥和票证（编码相同的密钥）。请求_INIT消息包括会话信息（例如，授权响应者的身份），并且由基于预共享密钥或签名的MAC保护完整性（类似于[RFC3830]中的预共享密钥和公钥加密模式）。如果请求得到授权，KMS将生成请求的密钥，将其编码到票证中，并在请求响应中返回密钥和票证
message. The Ticket Request exchange is OPTIONAL (depending on the Ticket Type), and MAY be omitted if the Initiator can create the ticket without assistance from the KMS (see mode 3 of Section 4.1.1).
消息票证请求交换是可选的（取决于票证类型），如果发起者可以在没有KMS协助的情况下创建票证，则可以省略该请求交换（参见第4.1.1节的模式3）。
The Initiator next includes the ticket in a TRANSFER_INIT message, which is sent to the Responder. The TRANSFER_INIT message is protected by a MAC based on an MPK (MIKEY Protection Key) encoded in the ticket. If the Responder finds the Ticket Policy and session security policies acceptable, the Responder forwards the ticket to the KMS. This is done with a RESOLVE_INIT message, which asks the KMS to return the keys encoded in the ticket. The RESOLVE_INIT message is protected by a MAC based on a pre-shared key (between Responder and KMS) or by a signature. The Ticket Resolve exchange is OPTIONAL (depending on the Ticket Policy), and SHOULD only be used when the Responder is unable to resolve the ticket without assistance from the KMS (see mode 2 of Section 4.1.1).
发起者接下来在发送给响应者的TRANSFER_INIT消息中包含票据。TRANSFER_INIT消息由MAC根据票据中编码的MPK（MIKEY保护密钥）进行保护。如果响应者发现票证策略和会话安全策略可接受，则响应者将票证转发给KMS。这是通过RESOLVE_INIT消息完成的，该消息要求KMS返回票据中编码的密钥。RESOLVE_INIT消息由基于预共享密钥（在响应者和KMS之间）的MAC或签名保护。票证解析交换是可选的（取决于票证策略），仅当响应者在没有KMS协助的情况下无法解析票证时才应使用（参见第4.1.1节的模式2）。
The KMS resolves the ticket. If the Responder is authorized to receive the keys encoded in the ticket, the KMS retrieves the keys and other information. If key forking is used, the keys are modified (bound to the Responder) by the KMS, see Section 5.1.1. The keys and additional information are then sent in a RESOLVE_RESP message to the Responder. The Responder then sends a TRANSFER_RESP message to the Initiator as verification. The TRANSFER_RESP message might include information used for further key derivation.
KMS解决了这个问题。如果响应者被授权接收票据中编码的密钥，KMS将检索密钥和其他信息。如果使用钥匙分叉，KMS会修改钥匙（绑定到响应者），请参见第5.1.1节。然后，密钥和其他信息以RESOLVE_RESP消息的形式发送给响应者。然后，响应者向启动器发送一条传输响应消息作为验证。TRANSFER_RESP消息可能包含用于进一步密钥派生的信息。
The use case and signaling described above is the full three round-trip mode, but other modes are allowed, see Section 4.1.1. Pre-encrypted content is discussed in Section 8, group communication is discussed in Section 9, and signaling between different KMSs is discussed in Section 10. An alternative use case is discussed in Appendix B.
上述用例和信号是完整的三种往返模式，但允许使用其他模式，见第4.1.1节。第8节讨论预加密内容，第9节讨论组通信，第10节讨论不同KMS之间的信令。附录B中讨论了一个替代用例。
The session keys are normally generated/supplied by the KMS (encoded in the ticket), but in certain use cases (see Section 8) the session key may be supplied by the Initiator or Responder (sent in a separate KEMAC protected with keys derived from the MPK).
会话密钥通常由KMS生成/提供（编码在票据中），但在某些使用情况下（见第8节），会话密钥可能由启动器或响应者提供（在单独的KEMAC中发送，并由MPK衍生的密钥保护）。
MIKEY-TICKET offers a framework that is flexible enough to satisfy users with a broad range of security and functional needs. The framework consists of the three exchanges for which different Ticket Types can be defined. The ticket consists of a Ticket Policy as well as Ticket Data. The Ticket Policy contains information intended for all parties involved, whereas the Ticket Data is only intended for the party that resolves the ticket. The Ticket Data could be a reference to information (keys, etc.) stored by the key management service, it could contain all the information itself, or it could be a combination of the two alternatives. The format of the Ticket Data
MIKEY-TICKET提供了一个足够灵活的框架，可以满足用户广泛的安全和功能需求。该框架由三个可定义不同票证类型的交换组成。票证由票证策略和票证数据组成。票证策略包含适用于所有相关方的信息，而票证数据仅适用于解决票证的一方。票证数据可以是对密钥管理服务存储的信息（密钥等）的引用，它可以包含所有信息本身，也可以是两个备选方案的组合。票证数据的格式
depends on the Ticket Type signaled in the Ticket Policy. The Ticket Data corresponding to the default Ticket Type, called MIKEY base ticket, is defined in Appendix A and requirements regarding new Ticket Types are given in Section 11.
取决于票证策略中指示的票证类型。与默认票证类型（称为MIKEY基本票证）对应的票证数据在附录A中定义，关于新票证类型的要求在第11节中给出。
As MIKEY-TICKET is based on [RFC3830], the same terminology, processing, and considerations still apply unless otherwise stated. Just like in [RFC3830], the messages are integrity protected and encryption is only applied to the keys and not to the entire messages.
由于MIKEY-TICKET基于[RFC3830]，除非另有说明，否则相同的术语、处理和注意事项仍然适用。与[RFC3830]一样，消息受完整性保护，加密仅应用于密钥，而不应用于整个消息。
Depending on the Ticket Type and the Ticket Policy, some of the exchanges might be optional or not used at all, see Figure 3. If the ticket protection is based on a key known only by the KMS, both the Initiator and the Responder have to contact the KMS to request/ resolve tickets (mode 1). If the key used to protect the ticket is shared between the KMS and the Responder, the Ticket Resolve exchange can be omitted (similar to Kerberos), as the Responder can resolve the ticket without assistance from the KMS (mode 2).
根据票证类型和票证策略，一些交换可能是可选的，或者根本不使用，见图3。如果票据保护基于仅由KMS知道的密钥，则发起方和响应方必须联系KMS以请求/解决票据（模式1）。如果用于保护票据的密钥在KMS和响应者之间共享，则可以省略票据解析交换（类似于Kerberos），因为响应者可以在没有KMS协助的情况下解析票据（模式2）。
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
Ticket Request
(1) <------------------------------> Ticket Transfer
<------------------------------------------------------------->
<------------------------------>
Ticket Resolve
Ticket Request
(2) <------------------------------> Ticket Transfer
<------------------------------------------------------------->
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
Ticket Request
(1) <------------------------------> Ticket Transfer
<------------------------------------------------------------->
<------------------------------>
Ticket Resolve
Ticket Request
(2) <------------------------------> Ticket Transfer
<------------------------------------------------------------->
Ticket Transfer
(3) <------------------------------------------------------------->
<------------------------------>
Ticket Resolve
Ticket Transfer
(3) <------------------------------------------------------------->
<------------------------------>
Ticket Resolve
Ticket Transfer
(4) <------------------------------------------------------------->
Ticket Transfer
(4) <------------------------------------------------------------->
Figure 3: Modes
图3：模式
If the key protecting the ticket is shared between the Initiator and the KMS, the Ticket Request exchange can be omitted (similar to the Otway-Rees protocol [Otway-Rees]), as the Initiator can create the ticket without assistance from the KMS (mode 3). If the key
如果在发起方和KMS之间共享保护票据的密钥，则可以省略票据请求交换（类似于Otway Rees协议[Otway Rees]），因为发起方可以创建票据而无需KMS的协助（模式3）。如果钥匙
protecting the ticket is shared between the Initiator and the Responder, both the Ticket Request and Ticket Resolve exchanges can be omitted (mode 4). This can be seen as a variation of the pre-shared key method of [RFC3830] with a mutual key-freshness guarantee.
保护票据在发起方和响应方之间共享，票据请求和票据解析交换都可以省略（模式4）。这可以看作是[RFC3830]的预共享密钥方法的一种变体，具有互密钥新鲜度保证。
In modes 1 and 2, the Ticket Request exchange can be omitted if the tickets and the corresponding keys are distributed from the KMS to the Initiator in some other way. In addition, as tickets may be reused (see Section 5.3), a single Ticket Request exchange may be followed by several Ticket Transfer exchanges.
在模式1和2中，如果票证和相应密钥以某种其他方式从KMS分发给启动器，则可以省略票证请求交换。此外，由于车票可以重复使用（见第5.3节），一次车票请求交换之后可能会进行多次车票转账交换。
This exchange is used by the Initiator to request keys and a ticket from a trusted KMS with which the Initiator has pre-shared credentials. The request contains information (e.g., participant identities, etc.) describing the session the ticket is intended to protect. A full round trip is required for the Initiator to receive the ticket. The initial message REQUEST_INIT comes in two variants. The first variant corresponds to the pre-shared key (PSK) method of [RFC3830].
启动器使用此交换从受信任的KMS请求密钥和票证，启动器与该KMS具有预共享凭据。请求包含描述票证要保护的会话的信息（例如，参与者身份等）。发起者需要一个完整的往返行程才能收到票据。初始消息请求_INIT有两种变体。第一种变体对应于[RFC3830]的预共享密钥（PSK）方法。
Initiator KMS
启动器KMS
REQUEST_INIT_PSK = ---->
HDR, T, RANDRi, [IDRi],
[IDRkms], TP, <---- REQUEST_RESP =
[IDRpsk], V HDR, T, [IDRkms],
TICKET, KEMAC, V
REQUEST_INIT_PSK = ---->
HDR, T, RANDRi, [IDRi],
[IDRkms], TP, <---- REQUEST_RESP =
[IDRpsk], V HDR, T, [IDRkms],
TICKET, KEMAC, V
The second variant corresponds to the public-key (PK) method of [RFC3830].
第二种变体对应于[RFC3830]的公钥（PK）方法。
Initiator KMS
启动器KMS
REQUEST_INIT_PK = ---->
HDR, T, RANDRi, [IDRi],
{CERTi}, [IDRkms], TP, <---- REQUEST_RESP =
[CHASH], PKE, SIGNi HDR, T, [IDRkms],
TICKET, KEMAC, V
REQUEST_INIT_PK = ---->
HDR, T, RANDRi, [IDRi],
{CERTi}, [IDRkms], TP, <---- REQUEST_RESP =
[CHASH], PKE, SIGNi HDR, T, [IDRkms],
TICKET, KEMAC, V
As the REQUEST_INIT message MUST ensure the identity of the Initiator to the KMS, it SHALL be integrity protected by a MAC based on a pre-shared key or by a signature. The response message REQUEST_RESP is the same for the two variants and SHALL be protected using the pre-shared/envelope key indicated in the REQUEST_INIT message.
As the REQUEST_INIT message MUST ensure the identity of the Initiator to the KMS, it SHALL be integrity protected by a MAC based on a pre-shared key or by a signature. The response message REQUEST_RESP is the same for the two variants and SHALL be protected using the pre-shared/envelope key indicated in the REQUEST_INIT message.translate error, please retry
In addition to the ticket, the Initiator receives keys, which it does not already know. The ticket contains both session information and information needed to resolve the ticket later, see Section 6.10.
除了票证之外，发起方还接收它还不知道的密钥。票证包含会话信息和稍后解决票证所需的信息，请参见第6.10节。
The REQUEST_INIT message MUST always include the Header (HDR), Timestamp (T), and RANDRi payloads.
REQUEST_INIT消息必须始终包括头（HDR）、时间戳（T）和RANDRi有效负载。
In HDR, the CSB ID (Crypto Session Bundle ID) SHALL be assigned as in [RFC3830]. The V flag MUST be set to '1' but SHALL be ignored by the KMS as a response is MANDATORY. As Crypto Sessions (CSs) SHALL NOT be handled, the #CS MUST be set to '0' and the CS ID map type SHALL be the "Empty map" as defined in [RFC4563].
在HDR中，应按照[RFC3830]中的规定分配CSB ID（加密会话捆绑ID）。V标志必须设置为“1”，但KMS应忽略，因为响应是强制性的。由于不应处理加密会话（CSs），因此#CS必须设置为“0”，CS ID映射类型应为[RFC4563]中定义的“空映射”。
IDRi contains the identity of the Initiator. This identity SHOULD be included in the granted Ticket Policy.
IDRi包含启动器的标识。此标识应包含在授予的票证策略中。
IDRkms contains the identity of the KMS. It SHOULD be included, but it MAY be left out when it can be expected that the KMS has a single identity.
IDRkms包含KMS的标识。它应该包括在内，但当可以预期KMS具有单一身份时，它可能被忽略。
The Ticket Policy payload (TP) contains the desired Ticket Policy. It includes for instance, the ticket's validity period, the number of requested keys, and the identities of authorized responders (see Section 6.10).
票证策略有效负载（TP）包含所需的票证策略。例如，它包括票据的有效期、请求密钥的数量和授权响应者的身份（见第6.10节）。
The IDRi payload SHOULD be included but MAY be left out when it can be expected that the KMS can identify the Initiator by other means.
应包括IDRi有效载荷，但当可以预期KMS可以通过其他方式识别启动器时，可以忽略IDRi有效载荷。
The IDRpsk payload is used to indicate the pre-shared key used. It MAY be omitted if the KMS can find the pre-shared key by other means.
IDRpsk有效负载用于指示使用的预共享密钥。如果KMS可以通过其他方式找到预共享密钥，则可以省略该步骤。
The last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from the pre-shared key shared by the Initiator and the KMS (see Section 5.1.2 for key derivation specification). The MAC SHALL cover the entire REQUEST_INIT_PSK message as well as the identities of the involved parties (see Section 5.5 for the exact definition).
最后一个有效载荷应为验证有效载荷（V），其中认证密钥（auth_密钥）是从启动器和KMS共享的预共享密钥中派生出来的（密钥派生规范见第5.1.2节）。MAC应涵盖整个请求初始化PSK消息以及相关方的身份（具体定义见第5.5节）。
The identity IDRi and certificate CERTi SHOULD be included, but they MAY be left out when it can be expected that the KMS can obtain the certificate in some other manner. If a certificate chain is to be provided, each certificate in the chain SHOULD be included in a
应包括标识IDRi和证书CERTi，但如果可以预期KMS可以通过其他方式获得证书，则可以忽略它们。如果要提供证书链，则链中的每个证书都应包含在
separate CERT payload. The Initiator's certificate MUST come first. Each following certificate MUST directly certify the one preceding it.
单独的证书有效载荷。发起者的证书必须放在第一位。下列证书必须直接证明其前面的证书。
PKE contains the encrypted envelope key: PKE = E(PKkms, env_key). It is encrypted using the KMS's public key (PKkms). If the KMS possesses several public keys, the Initiator can indicate the key used in the CHASH payload.
PKE包含加密的信封密钥：PKE=E（PKkms，env_-key）。它使用KMS的公钥（PKkms）进行加密。如果KMS拥有多个公钥，则启动器可以指示CHASH有效负载中使用的密钥。
SIGNi is a signature covering the entire REQUEST_INIT_PK message, using the Initiator's signature key (see Section 5.5 for the exact definition).
SIGNi是使用发起人的签名密钥覆盖整个请求初始化PK消息的签名（具体定义见第5.5节）。
If the KMS can verify the integrity of the received message and the message can be correctly parsed, the KMS MUST check the Initiator's authorization. If the Initiator is authorized to receive the requested ticket, possibly with a modified Ticket Policy, the KMS MUST send a REQUEST_RESP message. Unexpected payloads in the REQUEST_INIT message SHOULD be ignored. Errors are handled as described in Section 5.4.
如果KMS可以验证接收到的消息的完整性，并且消息可以正确解析，则KMS必须检查启动器的授权。如果发起者被授权接收请求的票证（可能使用修改的票证策略），KMS必须发送请求响应消息。应忽略请求_INIT消息中的意外有效负载。错误的处理如第5.4节所述。
The version, PRF func and CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL be identical to the corresponding fields in the REQUEST_INIT message. The V flag has no meaning in this context. It SHALL be set to '0' by the KMS and ignored by the Initiator.
HDR有效载荷中的版本、PRF func和CSB ID、#CS和CS ID映射类型字段应与请求初始化消息中的相应字段相同。V标志在此上下文中没有任何意义。KMS应将其设置为“0”，并由启动器忽略。
If one of the NTP timestamp types is used, the KMS SHALL generate a fresh timestamp value (unlike [RFC3830]), which may be used for clock synchronization. If the COUNTER timestamp type (see Section 6.6 of [RFC3830]) is used, the timestamp value MAY be equal to the one in the REQUEST_INIT message.
如果使用NTP时间戳类型之一，KMS应生成新的时间戳值（与[RFC3830]不同），该值可用于时钟同步。如果使用计数器时间戳类型（参见[RFC3830]第6.6节），则时间戳值可能等于请求_INIT消息中的值。
The TICKET payload carries the granted Ticket Policy and the Ticket Data (see Section 6.10). As the KMS decides which Ticket Policy to use, this may not be the same Ticket Policy as the Initiator requested. The Ticket Type and the Ticket Data depend on the granted Ticket Policy.
票证有效载荷携带已授予的票证策略和票证数据（参见第6.10节）。由于KMS决定使用哪种票证策略，这可能与启动器请求的票证策略不同。票证类型和票证数据取决于授予的票证策略。
The KEMAC payload SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. Depending on the type of REQUEST_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the encr_key (and salt_key). Depending on the encryption algorithm, the salting key may go into the IV (see [RFC3830]). If the TP payload in the REQUEST_INIT message does not
KEMAC有效载荷应使用空认证算法，因为MAC包含在V有效载荷中。根据请求初始化消息的类型，应使用预共享密钥或信封密钥导出encr_密钥（和salt_密钥）。根据加密算法，satting密钥可能进入IV（参见[RFC3830]）。如果请求_INIT消息中的TP有效负载没有
contain a KEMAC, it is RECOMMENDED that the KMS's default KEMAC include a single TGK. The KEMAC SHALL include an MPK (MIKEY Protection Key), MPKi, used as a pre-shared key to protect the messages in the Ticket Transfer exchange. If key forking (see Section 5.1.1) is used (determined by the Ticket Policy) a second MPK, MPKr, SHALL be included in the KEMAC. Then, MPKi SHALL be used to protect the TRANSFER_INIT message and MPKr SHALL be used to verify the TRANSFER_RESP message. The KEMAC is hence constructed as follows:
如果包含KEMAC，建议KMS的默认KEMAC包含一个TGK。KEMAC应包括一个MPK（MIKEY保护密钥），即MPKi，用作预共享密钥，以保护票据传输交换中的信息。如果使用钥匙分叉（见第5.1.1节）（由票证政策决定），KEMAC中应包括第二个MPK，即MPKr。然后，应使用MPKi保护TRANSFER_INIT消息，并使用MPKr验证TRANSFER_RESP消息。因此，KEMAC的结构如下：
KEMAC = E(encr_key, MPKi || [MPKr] || {TEK|TGK|GTGK})
KEMAC = E(encr_key, MPKi || [MPKr] || {TEK|TGK|GTGK})
The last payload SHALL be a Verification payload (V). Depending on the type of REQUEST_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the auth_key. The MAC SHALL cover the entire REQUEST_RESP message as well as the REQUEST_INIT message (see Section 5.5 for the exact definition).
最后一个有效载荷应为验证有效载荷（V）。根据请求初始化消息的类型，应使用预共享密钥或信封密钥来派生验证密钥。MAC应涵盖整个请求响应消息以及请求初始化消息（具体定义见第5.5节）。
If the Initiator can verify the integrity of the received message and the message can be correctly parsed, the ticket and the associated session information SHALL be stored. Unexpected payloads in the REQUEST_RESP message SHOULD be ignored. Errors are handled as described in Section 5.4.
如果发起者能够验证接收到的消息的完整性，并且消息能够正确解析，则应存储票据和相关会话信息。应忽略请求响应消息中的意外有效负载。错误的处理如第5.4节所述。
Before using the received ticket, the Initiator MUST check that the granted Ticket Policy is acceptable. If not, the Initiator SHALL discard and MAY send a new REQUEST_INIT message suggesting a different Ticket Policy than before.
在使用收到的票证之前，发起人必须检查授予的票证策略是否可接受。否则，发起者应放弃，并可发送新的请求初始化消息，建议与以前不同的票证策略。
This exchange is used to transfer a ticket as well as session information from the Initiator to a Responder. The exchange is modeled after the pre-shared key mode [RFC3830], but instead of a pre-shared key, an MPK encoded in the ticket is used. The session keys are also encoded in the TICKET payload, but in some use cases (see Section 8) they need to be sent in a separate KEMAC payload. The session information may be sent from the Initiator to the Responder (similar to [RFC3830]) or from the Responder to the Initiator (similar to [RFC4738]). As the motive for this exchange is to setup a shared secret key between Initiator and Responder, the Responder cannot check the authenticity of the message before the ticket is resolved (by KMS or Responder). A full round trip is required if Responder key confirmation and freshness guarantee are needed.
此交换用于将票据以及会话信息从发起方传输到响应方。交换按照预共享密钥模式[RFC3830]进行建模，但使用票据中编码的MPK代替预共享密钥。会话密钥也在票据有效载荷中编码，但在某些用例中（参见第8节），它们需要在单独的KEMAC有效载荷中发送。会话信息可以从发起方发送到响应方（类似于[RFC3830]），或者从响应方发送到发起方（类似于[RFC4738]）。由于此交换的目的是在发起方和响应方之间设置共享密钥，因此响应方无法在票据解析（由KMS或响应方）之前检查消息的真实性。如果需要响应者密钥确认和新鲜度保证，则需要全程往返。
Initiator Responder
发起者响应者
TRANSFER_INIT = ---->
HDR, T, RANDRi, [IDRi],
[IDRr], {SP}, TICKET, < - - TRANSFER_RESP =
[KEMAC], V HDR, T, [RANDRr],
[IDRr], [RANDRkms],
{SP}, [KEMAC], V
TRANSFER_INIT = ---->
HDR, T, RANDRi, [IDRi],
[IDRr], {SP}, TICKET, < - - TRANSFER_RESP =
[KEMAC], V HDR, T, [RANDRr],
[IDRr], [RANDRkms],
{SP}, [KEMAC], V
The TRANSFER_INIT message MUST always include the Header (HDR), Timestamp (T), and RANDRi payloads.
TRANSFER_INIT消息必须始终包括标头（HDR）、时间戳（T）和RANDRi有效负载。
In HDR, the CSB ID (Crypto Session Bundle ID) SHALL be assigned as in [RFC3830]. The value of the V flag SHALL agree with the F flag in the Ticket Policy and it SHALL be ignored by the Responder.
在HDR中，应按照[RFC3830]中的规定分配CSB ID（加密会话捆绑ID）。V标志的值应与票证政策中的F标志一致，且响应者应忽略该标志。
The IDRi and IDRr payloads SHOULD be included, but IDRi MAY be left out if the Responder can identify the Initiator by other means, and IDRr MAY be left out when it can be expected that the Responder has a single identity.
应包括IDRi和IDRr有效载荷，但如果响应者可以通过其他方式识别启动器，则IDRi可能被忽略，并且当可以预期响应者具有单个标识时，IDRr可能被忽略。
Multiple SP payloads MAY be used both to indicate supported security policies for a specific crypto session (similar to [RFC4738]) and to specify security policies for different crypto sessions (similar to [RFC3830]).
多个SP有效负载既可用于指示特定加密会话支持的安全策略（类似于[RFC4738]），也可用于指定不同加密会话的安全策略（类似于[RFC3830]）。
The ticket payload (see Section 6.10) contains the Ticket Policy (see Section 6.10), Ticket Data (the default ticket type is defined in Appendix A), and Initiator Data. The Ticket Policy contains information intended for all parties involved, whereas the Ticket Data is only intended for the party that resolves the ticket. The Ticket Type provided in the Ticket Data is indicated in the Ticket Policy. The Initiator Data authenticates the Initiator when key forking (I flag) is used.
票证有效载荷（见第6.10节）包含票证策略（见第6.10节）、票证数据（默认票证类型在附录A中定义）和启动器数据。票证策略包含适用于所有相关方的信息，而票证数据仅适用于解决票证的一方。票证数据中提供的票证类型在票证策略中指示。使用密钥分叉（I标志）时，启动器数据对启动器进行身份验证。
The KEMAC payload is handled in the same way as if it were sent in a later CSB update (see Section 5.2), with the only difference that the encr_key is always derived from MPKi and therefore accessible by all responders authorized to resolve the ticket. Initiator-specified keys MAY be used if the Initiator has pre-encrypted content and specific TEKs (Traffic Encryption Keys) need to be used (see Section 8). If indicated by the Ticket Policy (L flag), a KEMAC payload SHALL NOT be included.
KEMAC有效载荷的处理方式与在随后的CSB更新中发送的方式相同（见第5.2节），唯一的区别是encr_密钥始终来自MPKi，因此所有授权解决票据的响应者都可以访问该密钥。如果启动器具有预加密内容，并且需要使用特定TEK（流量加密密钥），则可以使用启动器指定的密钥（参见第8节）。如果票证政策（L标志）指示，则不应包括KEMAC有效载荷。
The last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from the MPKi (see Section 5.1.2 for key derivation specification). The MAC SHALL cover the entire TRANSFER_INIT message as well as the identities of the involved parties (see Section 5.5 for the exact definition).
最后一个有效载荷应为验证有效载荷（V），其中认证密钥（auth_密钥）源自MPKi（密钥推导规范见第5.1.2节）。MAC应涵盖整个传输初始化消息以及相关方的身份（具体定义见第5.5节）。
As the Initiator and Responder do not have any pre-shared keys, the Responder cannot check the authenticity of the message before the ticket is resolved. The Responder SHALL however check that both the Ticket Policy and the security policies are acceptable. If they are not, the Responder SHALL reject without contacting the KMS. This is an early reject mechanism to avoid unnecessary KMS signaling when the Responder can conclude from the information at hand that it will not accept the connection. After the ticket has been resolved, the parsing of the TRANSFER_INIT message continues. Unexpected payloads in the TRANSFER_INIT message SHOULD be ignored. Errors are handled as described in Section 5.4. If the F flag in the Ticket Policy is set, the Responder MUST send a TRANSFER_RESP message.
由于发起方和响应方没有任何预共享密钥，因此响应方无法在解析票据之前检查消息的真实性。但是，响应者应检查票证政策和安全政策是否可接受。如果没有，响应者应在不联系KMS的情况下拒绝。这是一种早期拒绝机制，当响应者可以从手头的信息推断它将不接受连接时，可以避免不必要的KMS信令。解析票据后，继续解析TRANSFER_INIT消息。应忽略TRANSFER_INIT消息中的意外有效负载。错误的处理如第5.4节所述。如果在票证策略中设置了F标志，则响应者必须发送传输响应消息。
The version, PRF func and CSB ID fields in the HDR payload SHALL be identical to the corresponding fields in the TRANSFER_INIT message. The V flag has no meaning in this context. It SHALL be set to '0' by the Responder and ignored by the Initiator. The Responder SHALL update the CS ID map info so that each crypto session has exactly one security policy indicated. The Responder MUST provide Session Data (at least for SRTP) and SPI for each crypto session for which the Initiator has not supplied Session Data and SPI. If needed, the Responder MAY update Session Data and SPI provided by the Initiator. If the Responder adds crypto sessions, the #CS SHALL be updated.
HDR有效载荷中的版本、PRF func和CSB ID字段应与TRANSFER_INIT消息中的相应字段相同。V标志在此上下文中没有任何意义。响应者应将其设置为“0”，发起者将其忽略。响应者应更新CS ID映射信息，以便每个加密会话都有一个指定的安全策略。响应方必须为发起方未提供会话数据和SPI的每个加密会话提供会话数据（至少针对SRTP）和SPI。如果需要，响应者可以更新发起方提供的会话数据和SPI。如果响应者添加加密会话，则应更新#CS。
If one of the NTP timestamp types is used, the Responder SHALL generate a fresh timestamp value (unlike [RFC3830]). If the COUNTER timestamp type (see Section 6.6 of [RFC3830]) is used, the timestamp value MAY be equal to the one in the TRANSFER_INIT message.
如果使用一种NTP时间戳类型，响应者应生成一个新的时间戳值（与[RFC3830]不同）。如果使用计数器时间戳类型（参见[RFC3830]第6.6节），则时间戳值可能等于TRANSFER_INIT消息中的值。
If indicated by the Ticket Policy (G flag), the Responder SHALL generate a fresh (pseudo-)random byte string RANDRr. RANDRr is used to produce Responder freshness guarantee in key derivations.
如果由票证策略（G标志）指示，响应者应生成一个新的（伪）随机字节字符串RANDRr。RANDRr用于在关键衍生产品中产生响应者新鲜度保证。
If the Responder receives an IDRr payload in the RESOLVE_RESP message, the same identity MUST be sent in an IDRr payload in the TRANSFER_RESP message. The identity sent in the IDRr payload in the
如果响应者在RESOLVE_RESP消息中接收到IDRr有效负载，则必须在TRANSFER_RESP消息中的IDRr有效负载中发送相同的标识。在中的IDRr有效负载中发送的标识
TRANSFER_RESP message (e.g., user1@example.com) MAY differ from the one sent in the IDRr payload in the TRANSFER_INIT message (e.g., IT-support@example.com).
传输响应消息（例如。，user1@example.com)可能与传输初始化消息中IDRr有效负载中发送的内容不同（例如-support@example.com).
If the Responder receives a RANDRkms payload in the RESOLVE_RESP message, the same RAND MUST be sent in a RANDRkms payload in the TRANSFER_RESP message.
如果响应者在RESOLVE_RESP消息中收到RANDRkms有效负载，则必须在TRANSFER_RESP消息中的RANDRkms有效负载中发送相同的RAND。
The Responder MAY provide additional Security Policy payloads. The Responder SHOULD NOT resend SP payloads, which the Initiator supplied.
响应者可以提供额外的安全策略有效负载。响应程序不应重新发送启动器提供的SP有效负载。
The KEMAC payload SHALL be handled exactly as if it was sent in a later CSB update, see Section 5.2. Responder-specified keys MAY be used if Responder has pre-encrypted content and specific TEKs (Traffic Encryption Keys) need to be used (see Section 8). If indicated by the Ticket Policy (M flag), a KEMAC payload SHALL NOT be included.
KEMAC有效载荷的处理应与在随后的CSB更新中发送的一样，见第5.2节。如果响应者有预加密的内容，并且需要使用特定的TEK（流量加密密钥），则可以使用响应者指定的密钥（参见第8节）。如果票证政策（M标志）指示，则不应包括KEMAC有效载荷。
The last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from MPKi or MPKr' (depending on if key forking is used). The MAC SHALL cover the entire TRANSFER_RESP message as well as the TRANSFER_INIT message (see Section 5.5 for the exact definition).
最后一个有效载荷应为验证有效载荷（V），其中认证密钥（auth_密钥）源自MPKi或MPKr’（取决于是否使用密钥分叉）。MAC应涵盖整个传输响应消息以及传输初始化消息（具体定义见第5.5节）。
If the Initiator can verify the integrity of the received message and the message can be correctly parsed, the Initiator MUST check that any Responder-generated security policies are acceptable. If not, the Initiator SHALL discard and MAY send a new TRANSFER_INIT message to indicate supported security policies. Unexpected payloads in the TRANSFER_RESP message SHOULD be ignored. Errors are handled as described in Section 5.4.
如果启动器可以验证所接收消息的完整性，并且消息可以正确解析，则启动器必须检查任何响应程序生成的安全策略是否可接受。否则，发起方应放弃，并可发送新的传输初始化消息，以指示支持的安全策略。应忽略传输响应消息中的意外有效负载。错误的处理如第5.4节所述。
This exchange is used by the Responder to request that the KMS return the keys encoded in a ticket. The KMS does not need to be the same KMS that originally issued the ticket, see Section 10. A full round trip is required for the Responder to receive the keys. The Ticket Resolve exchange is OPTIONAL (depending on the Ticket Policy), and SHOULD only be used when the Responder is unable to resolve the ticket without assistance from the KMS. The initial message RESOLVE_INIT comes in two variants (independent from the used REQUEST_INIT variant). The first variant corresponds to the pre-shared key (PSK) method of [RFC3830].
响应者使用此交换请求KMS返回票证中编码的密钥。KMS不需要与最初签发车票的KMS相同，见第10节。响应者需要一个完整的往返行程来接收钥匙。票证解析交换是可选的（取决于票证策略），仅当响应者在没有KMS帮助的情况下无法解析票证时才应使用。初始消息RESOLVE_INIT有两种变体（独立于使用的请求_INIT变体）。第一种变体对应于[RFC3830]的预共享密钥（PSK）方法。
Responder KMS
应答器KMS
RESOLVE_INIT_PSK = ---->
HDR, T, RANDRr, [IDRr],
[IDRkms], TICKET, <---- RESOLVE_RESP
[IDRpsk], V HDR, T, [IDRkms], KEMAC,
[IDRr], [RANDRkms], V
RESOLVE_INIT_PSK = ---->
HDR, T, RANDRr, [IDRr],
[IDRkms], TICKET, <---- RESOLVE_RESP
[IDRpsk], V HDR, T, [IDRkms], KEMAC,
[IDRr], [RANDRkms], V
The second variant corresponds to the public-key (PK) method of [RFC3830].
第二种变体对应于[RFC3830]的公钥（PK）方法。
Responder KMS
应答器KMS
RESOLVE_INIT_PK = ---->
HDR, T, RANDRr, [IDRr],
{CERTr}, [IDRkms], TICKET, <---- RESOLVE_RESP
[CHASH], PKE, SIGNr HDR, T, [IDRkms], KEMAC,
[IDRr], [RANDRkms], V
RESOLVE_INIT_PK = ---->
HDR, T, RANDRr, [IDRr],
{CERTr}, [IDRkms], TICKET, <---- RESOLVE_RESP
[CHASH], PKE, SIGNr HDR, T, [IDRkms], KEMAC,
[IDRr], [RANDRkms], V
As the RESOLVE_INIT message MUST ensure the identity of the Responder to the KMS, it SHALL be protected by a MAC based on a pre-shared key or by a signature. The response message RESOLVE_RESP is the same for the two variants and SHALL be protected by using the pre-shared/ envelope key indicated in the RESOLVE_INIT message.
由于RESOLVE_INIT消息必须确保KMS响应者的身份，因此它应受到基于预共享密钥的MAC或签名的保护。两种变体的响应消息RESOLVE_RESP相同，应使用RESOLVE_INIT消息中指示的预共享/信封密钥进行保护。
Upon receiving the RESOLVE_INIT message, the KMS verifies that the Responder is authorized to resolve the ticket based on ticket and KMS policies. The KMS extracts the session information from the ticket and returns this to the Responder. Since the KMS resolved the ticket, the Responder is assured of the integrity of the Ticket Policy, which contains the identity of the peer that requested or created the ticket. If key forking is used (I flag), the Responder is also assured that the peer that requested or created the ticket also sent the TRANSFER_INIT message. The Responder can complete the session information it got from the Initiator with the additional session information received from the KMS.
收到RESOLVE_INIT消息后，KMS验证响应者是否有权根据票证和KMS策略解析票证。KMS从票据中提取会话信息，并将其返回给响应者。由于KMS解析了票证，因此响应者可以确保票证策略的完整性，该策略包含请求或创建票证的对等方的身份。如果使用了密钥分叉（I标志），响应者还可以确保请求或创建票据的对等方也发送了TRANSFER_INIT消息。响应者可以使用从KMS接收到的附加会话信息来完成从启动器获得的会话信息。
The RESOLVE_INIT message MUST always include the Header (HDR), Timestamp (T), and RANDRr payloads.
RESOLVE_INIT消息必须始终包括标头（HDR）、时间戳（T）和RANDRr有效负载。
The CSB ID (Crypto Session Bundle ID) SHALL be assigned as in [RFC3830]. The V flag MUST be set to '1' but SHALL be ignored by the KMS as a response is MANDATORY. As crypto sessions SHALL NOT be handled, the #CS MUST be set to '0' and the CS ID map type SHALL be the "Empty map" as defined in [RFC4563].
CSB ID（加密会话包ID）应按照[RFC3830]中的规定进行分配。V标志必须设置为“1”，但KMS应忽略，因为响应是强制性的。由于不应处理加密会话，#CS必须设置为“0”，CS ID映射类型应为[RFC4563]中定义的“空映射”。
IDRkms SHOULD be included, but it MAY be left out when it can be expected that the KMS has a single identity.
应包括IDRkms，但当可以预期KMS具有单一标识时，可以将其忽略。
The TICKET payload contains the Ticket Policy and Ticket Data that the Responder wants to have resolved.
票证有效负载包含响应者希望解析的票证策略和票证数据。
IDRr contains the identity of the Responder. IDRr SHOULD be included, but it MAY be left out when it can be expected that the KMS can identify the Responder in some other manner.
IDRr包含响应者的标识。应包括IDRr，但当可以预期KMS可以以其他方式识别响应者时，可以忽略IDRr。
The IDRpsk payload is used to indicate the pre-shared key used. It MAY be omitted if the KMS can find the pre-shared key by other means.
IDRpsk有效负载用于指示使用的预共享密钥。如果KMS可以通过其他方式找到预共享密钥，则可以省略该步骤。
The last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from the pre-shared key shared by the Responder and the KMS. The MAC SHALL cover the entire RESOLVE_INIT_PSK message as well as the identities of the involved parties (see Section 5.5 for the exact definition).
最后一个有效载荷应为验证有效载荷（V），其中认证密钥（auth_密钥）源自响应者和KMS共享的预共享密钥。MAC应涵盖整个RESOLVE_INIT_PSK消息以及相关方的身份（具体定义见第5.5节）。
The identity IDRr and certificate CERTr SHOULD be included, but they MAY be left out when it can be expected that the KMS can obtain the certificate in some other manner. If a certificate chain is to be provided, each certificate in the chain SHOULD be included in a separate CERT payload. The Responder's certificate MUST come first. Each following certificate MUST directly certify the one preceding it.
应该包括标识IDRr和证书CERTr，但如果可以预期KMS可以通过其他方式获得证书，则可以忽略它们。如果要提供证书链，则链中的每个证书都应包含在单独的证书有效负载中。响应者的证书必须放在第一位。下列证书必须直接证明其前面的证书。
PKE contains the encrypted envelope key: PKE = E(PKkms, env_key). It is encrypted using PKkms. If the KMS possesses several public keys, the Responder can indicate the key used in the CHASH payload.
PKE包含加密的信封密钥：PKE=E（PKkms，env_-key）。它是使用PKkms加密的。如果KMS拥有多个公钥，则响应者可以指示CHASH有效载荷中使用的密钥。
SIGNr is a signature covering the entire RESOLVE_INIT_PK message, using the Responder's signature key (see Section 5.5 for the exact definition).
SIGNr是使用响应者的签名密钥覆盖整个RESOLVE_INIT_PK消息的签名（有关确切定义，请参见第5.5节）。
If the KMS can verify the integrity of the received message, the message can be correctly parsed, and the Responder is authorized to resolve the ticket, the KMS MUST send a RESOLVE_RESP message. If key forking is used (I flag), the KMS SHALL also verify the integrity of the Initiator Data field in the TICKET payload. Unexpected payloads in the RESOLVE_INIT message SHOULD be ignored. Errors are handled as described in Section 5.4.
如果KMS可以验证接收到的消息的完整性，消息可以正确解析，并且响应者有权解析票据，则KMS必须发送一条resolve_RESP消息。如果使用密钥分叉（I标志），KMS还应验证票据有效载荷中启动器数据字段的完整性。应忽略RESOLVE_INIT消息中意外的有效负载。错误的处理如第5.4节所述。
The version, PRF func and CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL be identical to the corresponding fields in the RESOLVE_INIT message. The V flag has no meaning in this context. It SHALL be set to '0' by the KMS and ignored by the Responder.
HDR有效载荷中的版本、PRF func和CSB ID、#CS和CS ID映射类型字段应与RESOLVE_INIT消息中的相应字段相同。V标志在此上下文中没有任何意义。KMS应将其设置为“0”，并由响应者忽略。
If one of the NTP timestamp types is used, the KMS SHALL generate a fresh timestamp value (unlike [RFC3830]), which may be used for clock synchronization. If the COUNTER timestamp type (see Section 6.6 of [RFC3830]) is used, the timestamp value MAY be equal to the one in the RESOLVE_INIT message.
如果使用NTP时间戳类型之一，KMS应生成新的时间戳值（与[RFC3830]不同），该值可用于时钟同步。如果使用计数器时间戳类型（参见[RFC3830]第6.6节），则时间戳值可能等于RESOLVE_INIT消息中的值。
The KEMAC payload SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. Depending on the type of RESOLVE_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the encr_key (and salt_key). Depending on the encryption algorithm, the salting key may go into the IV (see [RFC3830]). The KEMAC SHALL include an MPK (MPKi), used as a pre-shared key to protect the messages in the Ticket Transfer exchange. The KEMAC is hence constructed as follows:
KEMAC有效载荷应使用空认证算法，因为MAC包含在V有效载荷中。根据RESOLVE_INIT消息的类型，应使用预共享密钥或信封密钥导出encr_密钥（和salt_密钥）。根据加密算法，satting密钥可能进入IV（参见[RFC3830]）。KEMAC应包括一个MPK（MPKi），用作预共享密钥，以保护票证传输交换中的信息。因此，KEMAC的结构如下：
KEMAC = E(encr_key, MPKi || [MPKr'] || {TEK|TGK|GTGK})
KEMAC = E(encr_key, MPKi || [MPKr'] || {TEK|TGK|GTGK})
If key forking (see Section 5.1.1) is used (determined by the I flag in the Ticket Policy), a second MPK (MPKr') SHALL be included in the KEMAC. Then, MPKi SHALL be used to verify the TRANSFER_INIT message and MPKr' SHALL be used to protect the TRANSFER_RESP message. The KMS SHALL also fork the MPKr and the TGKs. The modifier used to derive the forked keys SHALL be included in the IDRr and RANDRkms payloads, where IDRr is the identity of the endpoint that answered and RANDRkms is a fresh (pseudo-)random byte string generated by the KMS. The reason that the KMS MAY adjust the Responder's identity is so that it matches an identity encoded in the ticket.
如果使用钥匙分叉（见第5.1.1节）（由票据政策中的I标志确定），KEMAC中应包含第二个MPK（MPKr'）。然后，应使用MPKi验证传输初始化消息，并使用MPKr'保护传输响应消息。KMS还应将MPKr和TGK分开。用于派生分叉键的修饰符应包含在IDRr和RANDRkms有效载荷中，其中IDRr是应答端点的标识，RANDRkms是KMS生成的新（伪）随机字节字符串。KMS可以调整响应者的身份的原因是，使其与票据中编码的身份匹配。
The last payload SHALL be a Verification payload (V). Depending on the type of RESOLVE_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the auth_key. The MAC SHALL cover the entire RESOLVE_RESP message as well as the RESOLVE_INIT message (see Section 5.5 for the exact definition).
最后一个有效载荷应为验证有效载荷（V）。根据RESOLVE_INIT消息的类型，应使用预共享密钥或信封密钥来派生验证密钥。MAC应涵盖整个RESOLVE_RESP消息以及RESOLVE_INIT消息（具体定义见第5.5节）。
If the Responder can verify the integrity of the received message and the message can be correctly parsed, the Responder MUST verify the TRANSFER_INIT message with the MPKi received from the KMS. If key forking is used, the Responder SHALL also verify that the MAC field in the V payload in the TRANSFER_INIT message is identical to the MAC
如果响应者可以验证接收到的消息的完整性，并且消息可以正确解析，则响应者必须使用从KMS接收的MPKi验证TRANSFER_INIT消息。如果使用密钥分叉，响应者还应验证TRANSFER_INIT消息中V有效载荷中的MAC字段是否与MAC相同
field in the Vi payload in the Initiator Data field in the TICKET payload. Unexpected payloads in the RESOLVE_RESP message SHOULD be ignored. Errors are handled as described in Section 5.4.
票据有效载荷中启动器数据字段中Vi有效载荷中的字段。应忽略RESOLVE_RESP消息中意外的有效负载。错误的处理如第5.4节所述。
For all messages in the Ticket Request and Ticket Resolve exchanges, the keys used to protect the MIKEY messages are derived from a pre-shared key or an envelope key. As crypto sessions SHALL NOT be handled, further keying material (i.e., TEKs) does not have to be derived.
对于票证请求和票证解析交换中的所有消息，用于保护MIKEY消息的密钥来自预共享密钥或信封密钥。由于不应处理加密会话，因此不必导出进一步的密钥材料（即TEK）。
In the Ticket Transfer exchange, the keys used to protect the MIKEY messages are derived from an MPK. If key forking is used, the KMS and the Initiator SHALL fork the MPKr and the TGKs (encoded in the ticket) based on a modifier, and different MPKs (MPKi and MPKr') SHALL be used to protect the TRANSFER_INIT and TRANSFER_RESP messages. In addition, the Responder MAY generate a RAND used to give Responder key freshness guarantee.
在票证传输交换中，用于保护MIKEY消息的密钥来自MPK。如果使用密钥分叉，KMS和发起者应基于修饰符分叉MPKr和TGK（编码在票据中），并应使用不同的MPK（MPKi和MPKr'）来保护传输初始化和传输响应消息。此外，响应者可以生成用于向响应者密钥新鲜度保证的RAND。
The key hierarchy and its dependencies on TRANSFER_INIT message contents for the case without key forking and RANDRr are illustrated in Figure 4. The KEMAC shown is the KEMAC sent from the KMS to the Initiator and the Responder. The illustrated key derivations are done by the Initiator and the Responder.
图4说明了在没有密钥分叉和RANDRr的情况下，密钥层次结构及其对TRANSFER_INIT消息内容的依赖关系。所示KEMAC是从KMS发送给发起方和响应方的KEMAC。所示的密钥派生由发起方和响应方完成。
+------+------------------+-----+------+
KEMAC | MPKi |..................| TGK | SALT |
+--+---+------------------+--+--+--+---+
| MPKi | |
v | |
CSB ID ----- auth_key ------ | |
+---------->| PRF |------------>| AUTH | | |
| ----- ------ | |
| ^ MAC | | |
| | RAND v | |
+--+--+------+----+---+--+--------+--+---+ | |
TRANSFER_INIT | HDR |......| RANDRi |..| TICKET |..| V | | |
+--+--+------+----+---+--+--------+--+---+ | |
| | RAND | |
| v | |
| CS ID ----- TGK | |
+---------->| PRF |<---------------------+ |
----- |
| TEK SALT |
v v
---------------------------------------
| Security Protocol, e.g., SRTP |
---------------------------------------
+------+------------------+-----+------+
KEMAC | MPKi |..................| TGK | SALT |
+--+---+------------------+--+--+--+---+
| MPKi | |
v | |
CSB ID ----- auth_key ------ | |
+---------->| PRF |------------>| AUTH | | |
| ----- ------ | |
| ^ MAC | | |
| | RAND v | |
+--+--+------+----+---+--+--------+--+---+ | |
TRANSFER_INIT | HDR |......| RANDRi |..| TICKET |..| V | | |
+--+--+------+----+---+--+--------+--+---+ | |
| | RAND | |
| v | |
| CS ID ----- TGK | |
+---------->| PRF |<---------------------+ |
----- |
| TEK SALT |
v v
---------------------------------------
| Security Protocol, e.g., SRTP |
---------------------------------------
Figure 4: Key hierarchy without key forking and RANDRr
图4：没有密钥分叉和RANDRr的密钥层次结构
The key hierarchy and its dependencies on TRANSFER_RESP message contents for the case with key forking and RANDRr are illustrated in Figure 5. The KEMAC shown is the KEMAC sent from the KMS to the Initiator. MOD is the modifier (IDRr, RANDRkms). The two key derivations that produce forked keys are done by the Initiator and the KMS, and the remaining two key derivations are done by the Initiator and the Responder. The random value RANDRi from the TRANSFER_INIT message is used as input to the derivation of the auth_key and may be used as input to the derivation of the TEK, but this is omitted from the figure. The protection of the TRANSFER_INIT message is done as in Figure 4.
图5说明了具有密钥分叉和RANDRr的情况下的密钥层次结构及其对TRANSFER_RESP消息内容的依赖关系。所示KEMAC是从KMS发送给发起人的KEMAC。MOD是修饰符（IDRr、RANDRkms）。生成分叉密钥的两个密钥派生由发起方和KMS完成，其余两个密钥派生由发起方和响应方完成。TRANSFER_INIT消息中的随机值RANDRi用作auth_密钥派生的输入，也可用作TEK派生的输入，但图中省略了这一点。TRANSFER_INIT消息的保护如图4所示。
+------+--------------------------+-----+------+
KEMAC | MPKr |..........................| TGK | SALT |
+--+---+--------------------------+--+--+--+---+
| MPKr | |
v | |
----- MPKr' | |
| PRF |-------+ TGK | |
----- | | |
^ v | |
CSB ID | ----- auth_key ------ | |
+---------)------>| PRF |--------->| AUTH | | |
| | ----- ------ | |
| | ID Data ^ MAC | | |
| | RAND | RAND v | |
+--+--+---+--+--+---+---+----+----------+---+ | |
TRANSFER_RESP | HDR |...| MOD |...| RANDRr |..........| V | | |
+--+--+---+--+--+---+---+----+----------+---+ | |
| | | RAND v |
| | | ID Data ----- |
| +----------)------------------>| PRF | |
| | RAND ----- |
| v | |
| CS ID ----- TGK' | |
+---------------->| PRF |<------------------+ |
----- |
| TEK SALT |
v v
---------------------------------------
| Security Protocol, e.g., SRTP |
---------------------------------------
+------+--------------------------+-----+------+
KEMAC | MPKr |..........................| TGK | SALT |
+--+---+--------------------------+--+--+--+---+
| MPKr | |
v | |
----- MPKr' | |
| PRF |-------+ TGK | |
----- | | |
^ v | |
CSB ID | ----- auth_key ------ | |
+---------)------>| PRF |--------->| AUTH | | |
| | ----- ------ | |
| | ID Data ^ MAC | | |
| | RAND | RAND v | |
+--+--+---+--+--+---+---+----+----------+---+ | |
TRANSFER_RESP | HDR |...| MOD |...| RANDRr |..........| V | | |
+--+--+---+--+--+---+---+----+----------+---+ | |
| | | RAND v |
| | | ID Data ----- |
| +----------)------------------>| PRF | |
| | RAND ----- |
| v | |
| CS ID ----- TGK' | |
+---------------->| PRF |<------------------+ |
----- |
| TEK SALT |
v v
---------------------------------------
| Security Protocol, e.g., SRTP |
---------------------------------------
Figure 5: Key hierarchy with key forking and RANDRr
图5：具有密钥分叉和RANDRr的密钥层次结构
The labels in the key derivations SHALL NOT include entire RANDR payloads, only the fields RAND length and RAND from the corresponding payload.
关键衍生产品中的标签不应包括整个RANDR有效载荷，仅包括对应有效载荷的RAND length和RAND字段。
When key forking is used (determined by the I flag in the Ticket Policy), the MPKr and TGKs (encoded in the ticket) SHALL be forked. The TEKs and GTGKs (Group TGKs), however, SHALL NOT be forked. This key forking is done by the KMS and the Initiator using the PRF (Pseudorandom Function) indicated in the Ticket Policy. The parameters for the PRF are:
当使用密钥分叉（由票据政策中的I标志确定）时，MPKr和TGK（票据中编码的）应分叉。但是，TEKs和GTGKs（TGKs组）不得分叉。密钥分叉由KMS和启动器使用票证策略中指示的PRF（伪随机函数）完成。PRF的参数包括：
inkey: : MPKr or TGK inkey_len : bit length of the inkey label : constant || 0xFF || 0xFFFFFFFF || 0x00 || length ID Data || ID Data || length RANDRkms || RANDRkms outkey_len : desired bit length of the outkey (MPKr', TGK') SHALL be equal to inkey_len
inkey:：MPKr或TGK inkey|len:inkey标签的位长度：常量| 0xFF | 0xFFFFFF | 0x00 |长度ID数据| ID数据|长度RANDRkms | RANDRkms outkey| len:outkey（MPKr'，TGK'）的所需位长度应等于inkey|len
where the ID Data field is taken from the IDRr payload sent in the RESOLVE_RESP and TRANSFER_RESP messages. Length ID Data is the length of the ID Data field in bytes as a 16-bit unsigned integer. Length RANDRkms is the length of RANDRkms in bytes as an 8-bit unsigned integer. The constant depends on the derived key type as summarized below.
其中，ID数据字段取自RESOLVE_RESP和TRANSFER_RESP消息中发送的IDRr有效负载。Length ID Data是ID数据字段的长度，以字节为单位，为16位无符号整数。Length RANDRkms是RANDRkms的长度，以字节为单位，为8位无符号整数。该常数取决于派生键类型，如下所述。
Derived key | Constant
------------+-----------
MPKr' | 0x2B288856
TGK' | 0x1512B54A
Derived key | Constant
------------+-----------
MPKr' | 0x2B288856
TGK' | 0x1512B54A
Table 5.1: Constants for forking key derivation
表5.1：分叉键派生的常数
The constants are taken from the decimal digits of e as described in [RFC3830].
常数取自[RFC3830]中所述的e的十进制数字。
This derivation is used to form the keys used to protect the MIKEY messages. For the Ticket Request and Ticket Resolve exchanges, the keys used to protect the MIKEY messages are derived from a pre-shared key or an envelope key. For the Ticket Transfer exchange, the keys are derived from an MPK. If key forking is used, different MPKs (MPKi and MPKr') SHALL be used to protect the TRANSFER_INIT and TRANSFER_RESP messages. The initial messages SHALL be protected with keys derived using the following parameters:
此派生用于形成用于保护MIKEY消息的密钥。对于票证请求和票证解析交换，用于保护MIKEY消息的密钥来自预共享密钥或信封密钥。对于票据转账交换，密钥来自MPK。如果使用密钥分叉，应使用不同的MPK（MPKi和MPKr'）来保护传输初始化和传输响应消息。初始信息应使用使用以下参数导出的密钥进行保护：
inkey: : pre-shared key, envelope key, or MPKi inkey_len : bit length of the inkey label : constant || 0xFF || CSB ID || 0x01 || length RANDRi || [RANDRi] || length RANDRr || [RANDRr] outkey_len : desired bit length of the outkey (encr_key, auth_key, salt_key)
inkey:：预共享密钥、信封密钥或MPKi inkey|len:inkey标签的位长度：常量| | 0xFF | | CSB ID | | 0x01 | | length RANDRi | |[RANDRi]| length RANDRr |[RANDRr]outkey|[RANDRr]outkey|所需的位长度（encr|u key、auth|u key、salt|u key）
The response messages SHALL be protected with keys derived using the following parameters:
响应信息应使用使用以下参数导出的密钥进行保护：
inkey: : pre-shared key, envelope key, MPKi, or MPKr' inkey_len : bit length of the inkey label : constant || 0xFF || CSB ID || 0x02 || length RANDRi || [RANDRi] || length RANDRr || [RANDRr] outkey_len : desired bit length of the outkey (encr_key, auth_key, salt_key)
inkey:：预共享密钥、信封密钥、MPKi或MPKr'inkey|len:inkey标签的位长度：常量| 0xFF | CSB ID | 0x02 | length RANDRi |[RANDRi]| length RANDRr |[RANDRr]outkey| leng:outkey的所需位长度（加密密钥、认证密钥、盐密钥）
The constant depends on the derived key type as defined in Section 4.1.4 of [RFC3830]. The 32-bit CSB ID field is taken from the HDR payload. RANDRi SHALL be included in the derivation of keys used to protect the Ticket Request and Ticket Transfer exchanges. RANDRr SHALL be included in the derivation of keys used to protect the Ticket Resolve exchange and in the derivation of keys used to protect TRANSFER_RESP if the Ticket Policy determines that it shall be present in the TRANSFER_RESP message (G flag). Length RANDRi is the length of RANDRi in bytes as an 8-bit unsigned integer, and Length RANDRr is the length of RANDRr in bytes as an 8-bit unsigned integer. If RANDRi is omitted, length RANDRi SHALL be 0 and if RANDRr is omitted, length RANDRr SHALL be 0. Note that at least one of RANDRi and RANDRr is always used.
该常数取决于[RFC3830]第4.1.4节中定义的衍生密钥类型。32位CSB ID字段取自HDR有效负载。RANDRi应包含在用于保护票证请求和票证转账交换的密钥推导中。RANDRr应包含在用于保护票证解析交换的密钥的派生中，以及用于保护传输响应的密钥的派生中，前提是票证策略确定其应出现在传输响应消息（G标志）中。Length RANDRi是以字节为单位的8位无符号整数的RANDRi长度，Length RANDRr是以字节为单位的8位无符号整数的RANDRr长度。如果省略RANDRi，则长度RANDRi应为0，如果省略RANDRr，则长度RANDRr应为0。请注意，始终至少使用RANDRi和RANDRr中的一个。
This only affects the Ticket Transfer exchange. In the following, we describe how keying material is derived from a TGK/GTGK. If key forking is used, any TGK encoded in the ticket SHALL be forked, and the forked key TGK' SHALL be used. The key derivation method SHALL be executed using the PRF indicated in the HDR payload. The parameters for the PRF are:
这只会影响票务转账交换。在下文中，我们将介绍如何从TGK/GTGK导出键控材料。如果使用钥匙分叉，则应分叉车票中编码的任何TGK，并使用分叉钥匙TGK'。密钥推导方法应使用HDR有效载荷中指示的PRF执行。PRF的参数包括：
inkey: : TGK, TGK', or GTGK inkey_len : bit length of the inkey label : constant || CS ID || 0xFFFFFFFF || 0x03 || length RANDRi || [RANDRi] || length RANDRr || [RANDRr] outkey_len : desired bit length of the outkey (TEK, encr_key, auth_key, salt_key)
inkey:：TGK，TGK'，或GTGK inkey|len:inkey标签的位长度：常量| | CS ID | | 0xffffff | | 0x03 | | length RANDRi | |[RANDRi]| length RANDRr |[RANDRr]outkey|[RANDRr]outkey|：outkey的所需位长度（TEK、encr|key、auth|u key、salt|key）
The constant depends on the derived key type as defined in Section 4.1.3 of [RFC3830]. If a salting key is present in the key data sub-payload, a security protocol in need of a salting key SHALL use this salting key and a new salting key SHALL NOT be derived. The 8-bit CS ID field is given by the CS ID map info field in the HDR payload. RANDRi SHALL be included if the Ticket Policy determines that it shall be used (H flag). RANDRr SHALL be included if the Ticket Policy determines that it shall be present in the TRANSFER_RESP message (G flag). Length RANDRi is the length of RANDRi in bytes as an 8-bit unsigned integer, and Length RANDRr is the length of RANDRr
该常数取决于[RFC3830]第4.1.3节中定义的衍生密钥类型。如果密钥数据子有效载荷中存在盐析密钥，则需要盐析密钥的安全协议应使用该盐析密钥，并且不得派生新的盐析密钥。8位CS ID字段由HDR有效负载中的CS ID map info字段给出。如果票证政策决定使用RANDRi（H标志），则应包括RANDRi。如果票证政策确定其应出现在传输响应消息（G标志）中，则应包括RANDRr。Length RANDRi是以字节为单位的8位无符号整数的RANDRi长度，Length RANDRr是RANDRr的长度
in bytes as an 8-bit unsigned integer. If RANDRi or RANDRr is omitted the corresponding length SHALL be 0. Note that at least one of RANDRi and RANDRr MUST be used.
以字节为单位，表示为8位无符号整数。如果省略RANDRi或RANDRr，则相应的长度应为0。请注意，必须至少使用RANDRi和RANDRr中的一个。
Similar to [RFC3830], MIKEY-TICKET provides a means of updating the CSB (Crypto Session Bundle), e.g., transporting a new TEK/TGK/GTGK or adding new crypto sessions. The CSB updating is done by executing the Ticket Transfer exchange again, e.g., before a TEK expires or when a new crypto session is needed. The CSB updating can be started by the Initiator:
与[RFC3830]类似，MIKEY-TICKET提供了更新CSB（加密会话包）的方法，例如，传输新的TEK/TGK/GTGK或添加新的加密会话。CSB更新通过再次执行票据转账交换来完成，例如，在TEK到期之前或需要新的加密会话时。CSB更新可由启动器启动：
Initiator Responder
发起者响应者
TRANSFER_INIT = ---->
HDR, T, [IDRi], [IDRr],
{SP}, [KEMAC], V < - - TRANSFER_RESP =
HDR, T, [IDRr],
{SP}, [KEMAC], V
TRANSFER_INIT = ---->
HDR, T, [IDRi], [IDRr],
{SP}, [KEMAC], V < - - TRANSFER_RESP =
HDR, T, [IDRr],
{SP}, [KEMAC], V
The CSB updating can also be started by the Responder:
CSB更新也可以由响应者启动：
Responder Initiator
应答器启动器
TRANSFER_INIT = ---->
HDR, T, [IDRr], [IDRi],
{SP}, [KEMAC], V < - - TRANSFER_RESP =
HDR, T, [IDRi],
{SP}, [KEMAC], V
TRANSFER_INIT = ---->
HDR, T, [IDRr], [IDRi],
{SP}, [KEMAC], V < - - TRANSFER_RESP =
HDR, T, [IDRi],
{SP}, [KEMAC], V
The new message exchange MUST use the same CSB ID as the initial exchange but MUST use new timestamps. The crypto sessions negotiation (#CS field, CS ID map info field, and SP payloads) are handled as in the initial exchange. In the TRANSFER_INIT message the V flag SHALL be used to indicate whether or not a response message is expected. Static payloads such as RANDRi, RANDRr, RANDRkms, and TICKET that were provided in the initial exchange SHOULD NOT be included unless they are needed by a specific use case. New RANDs or TICKETs MUST NOT be included. The reason that new RANDs SHALL NOT be used is that if several TGKs are used, the peers would need to keep track of which RANDs to use for each TGK. This adds unnecessary complexity. Both messages SHALL be protected with the same keys (derived from MPKi or MPKr') that protected the last message (TRANSFER_INIT or TRANSFER_RESP) in the initial exchange.
新消息交换必须使用与初始交换相同的CSB ID，但必须使用新的时间戳。加密会话协商（#CS字段、CS ID映射信息字段和SP有效负载）的处理方式与初始交换相同。在TRANSFER_INIT消息中，应使用V标志指示是否需要响应消息。除非特定用例需要，否则不应包括在初始交换中提供的静态有效负载，如RANDRi、RANDRr、RANDRkms和TICKET。新的兰德或门票不得包括在内。不应使用新RAND的原因是，如果使用多个TGK，对等方需要跟踪每个TGK使用的RAND。这增加了不必要的复杂性。两条消息应使用相同的密钥（源自MPKi或MPKr）进行保护，该密钥保护初始交换中的最后一条消息（TRANSFER_INIT或TRANSFER_RESP）。
New keying material MAY be sent in a KEMAC payload. If indicated by the Ticket Policy (L and M flags), KEMAC payloads SHALL NOT be included. In the TRANSFER_RESP message, a session key MUST be provided for each crypto session. The KEMAC SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. The encr_key (and salt_key) SHALL be derived from the MPK (MPKi or MPKr'). Depending on the encryption algorithm, the salting key may go into the IV (see [RFC3830]). If a new TGK is exchanged, it SHALL NOT be forked. The KEMAC is hence constructed as follows:
新的键控材料可通过KEMAC有效载荷发送。如果票证政策（L和M标志）规定，则不包括KEMAC有效载荷。在TRANSFER_RESP消息中，必须为每个加密会话提供会话密钥。KEMAC应使用空认证算法，因为MAC包含在V有效载荷中。encr_键（和salt_键）应源自MPK（MPKi或MPKr'）。根据加密算法，satting密钥可能进入IV（参见[RFC3830]）。如果更换了新的TGK，则不得将其分叉。因此，KEMAC的结构如下：
KEMAC = E(encr_key, (TEK|TGK|GTGK))
KEMAC=E（encr|U键，（TEK|TGK|GTGK））
MIKEY-TICKET includes features aiming to offload the KMS from receiving ticket requests. One such feature is that tickets may be reused. This means that a user may request a ticket for media sessions with another user and then under the ticket's validity period use this ticket to protect several media sessions with that user.
MIKEY-TICKE包括一些旨在减轻KMS接收票证请求的功能。其中一个特点是门票可以重复使用。这意味着用户可以请求与另一用户的媒体会话的票证，然后在票证的有效期内使用该票证来保护与该用户的多个媒体会话。
When reusing a ticket that has been used in a previous Ticket Transfer exchange, a new Ticket Transfer exchange is executed. The new exchange MUST use a new CSB ID, a new timestamp, and new RANDs (RANDRi, RANDRr). If the Responder has resolved the ticket before, the Responder does not need to resolve the ticket again. In that case, the same modifier (IDRr, RANDRkms) SHALL be used. If the Ticket Policy forbids reuse (J flag), the ticket MUST NOT be reused. Note that such reuse cannot be detected by a stateless KMS. When group keys are used, ticket reuse leaves the Initiator responsible to ensure that group membership has not changed since the ticket was last used. (Otherwise, unauthorized responders may gain access to the group communication.) Thus, if group dynamics are difficult to verify, the Initiator SHOULD NOT initiate ticket reuse.
重新使用以前的票证转账交换中使用的票证时，将执行新的票证转账交换。新的交换必须使用新的CSB ID、新的时间戳和新的RAND（RANDRi，RANDRr）。如果响应者之前已解析了票据，则响应者无需再次解析票据。在这种情况下，应使用相同的改性剂（IDRr、RANDRkms）。如果票据政策禁止重用（J标志），则不得重用票据。请注意，无状态KMS无法检测到这种重用。当使用组密钥时，票据重用让启动器负责确保自上次使用票据后，组成员身份未发生更改。（否则，未经授权的响应者可能会访问组通信。）因此，如果组动态难以验证，则发起人不应启动票据重用。
When key forking is used, only the user that requested the ticket has access to the encoded master keys (MPKr, TGKs). Because of this, no one else can initiate a Ticket Transfer exchange using the ticket.
当使用密钥分叉时，只有请求票据的用户才能访问编码的主密钥（MPKr、TGK）。因此，其他任何人都不能使用票证发起票证转账交换。
If a fatal error occurs during the parsing of a message, the message SHOULD be discarded, and an Error message SHOULD be sent to the other party (Initiator, Responder, KMS). If a failure is due to the inability to authenticate the peer, the message SHALL be discarded, the Error message is OPTIONAL, and the caveats in Section 5.1.2 of [RFC3830] apply. Error messages may be used to report errors in both initial and response messages, but not in Error messages.
如果在解析消息期间发生致命错误，则应丢弃该消息，并将错误消息发送给另一方（发起方、响应方、KMS）。如果故障是由于无法对对等方进行身份验证造成的，则应丢弃该消息，错误消息是可选的，并且[RFC3830]第5.1.2节中的警告适用。错误消息可用于报告初始消息和响应消息中的错误，但不能报告错误消息中的错误。
In the Ticket Request and Ticket Resolve exchanges, the Error message MAY be authenticated with a MAC or a signature. The Error message is hence constructed as follows:
在票证请求和票证解析交换中，可以使用MAC或签名对错误消息进行身份验证。因此，错误消息的构造如下：
Error message = HDR, T, (ERR), [V|SIGNx]
错误消息=HDR，T，（ERR），[V | SIGNx]
where x is in the set {i, r, kms} (Initiator, Responder, KMS). Unexpected payloads in the Error message SHOULD be ignored.
其中x在集合{i，r，kms}（发起方，响应方，kms）中。应忽略错误消息中意外的有效负载。
In the Ticket Transfer exchange, the Error message MAY be authenticated with a MAC. If the suggested security policies are not supported, the Error message SHOULD include the supported parameters. The Error message is hence constructed as follows:
在票证传输交换中，可以使用MAC对错误消息进行身份验证。如果不支持建议的安全策略，则错误消息应包括支持的参数。因此，错误消息的构造如下：
Error message = HDR, T, (ERR), {SP}, [V]
Error message = HDR, T, (ERR), {SP}, [V]
In Error messages, the version, PRF func, and CSB ID fields in the HDR payload SHALL be identical to the corresponding fields in the message where the error occurred. The V field SHALL be set to '0' and be ignored.
在错误消息中，HDR有效载荷中的版本、PRF func和CSB ID字段应与发生错误的消息中的相应字段相同。V字段应设置为“0”并忽略。
If one of the NTP timestamp types is used, a fresh timestamp value SHALL be used. If the COUNTER timestamp type (see Section 6.6 of [RFC3830]) is used, the timestamp value MAY be equal to the one in the message where the error occurred.
如果使用NTP时间戳类型之一，则应使用新的时间戳值。如果使用计数器时间戳类型（见[RFC3830]第6.6节），则时间戳值可能等于发生错误的消息中的值。
The MAC/Signature in the V/SIGN payloads covers the entire Error message, except the MAC/Signature field itself. The auth_key SHALL be the same as in the message where the error occurred.
V/SIGN有效载荷中的MAC/Signature覆盖整个错误消息，MAC/Signature字段本身除外。验证密钥应与发生错误的消息中的密钥相同。
The MAC/Signature in the V/SIGN payloads covers the entire MIKEY message, except the MAC/Signature field itself. For initial messages, the identities (not whole payloads) of the parties involved MUST directly follow the MIKEY message in the Verification MAC/ Signature calculation. In the TRANSFER_INIT message, the MAC SHALL NOT cover the Initiator Data length and Initiator Data fields in the TICKET payload. Note that in the Transfer Exchange, Identity_r in TRANSFER_RESP (e.g., user1@example.com) MAY differ from that appearing in TRANSFER_INIT (e.g., IT-support@example.com). For response messages, the entire initial message (including the MAC/ Signature field) MUST directly follow the MIKEY message in the Verification MAC/Signature calculation (the identities are implicitly covered as they are covered by the initial message's MAC/Signature).
V/SIGN有效载荷中的MAC/Signature覆盖了整个MIKEY消息，MAC/Signature字段本身除外。对于初始消息，在验证MAC/签名计算中，相关方的身份（不是全部有效载荷）必须直接跟随MIKEY消息。在TRANSFER_INIT消息中，MAC不应覆盖票证有效负载中的启动器数据长度和启动器数据字段。请注意，在传输交换中，传输中的标识（例如。，user1@example.com)可能与TRANSFER_INIT中出现的内容不同（例如-support@example.com). 对于响应消息，整个初始消息（包括MAC/签名字段）必须直接跟随验证MAC/签名计算中的MIKEY消息（身份隐式覆盖，因为它们被初始消息的MAC/签名覆盖）。
Message type | MAC/Signature coverage
--------------+--------------------------------------------
REQUEST_INIT | REQUEST_INIT || Identity_i || Identity_kms
REQUEST_RESP | REQUEST_RESP || REQUEST_INIT
TRANSFER_INIT | TRANSFER_INIT || Identity_i || Identity_r
TRANSFER_RESP | TRANSFER_RESP || TRANSFER_INIT
RESOLVE_INIT | RESOLVE_INIT || Identity_r || Identity_kms
RESOLVE_RESP | RESOLVE_RESP || RESOLVE_INIT
Error message | Error message
Message type | MAC/Signature coverage
--------------+--------------------------------------------
REQUEST_INIT | REQUEST_INIT || Identity_i || Identity_kms
REQUEST_RESP | REQUEST_RESP || REQUEST_INIT
TRANSFER_INIT | TRANSFER_INIT || Identity_i || Identity_r
TRANSFER_RESP | TRANSFER_RESP || TRANSFER_INIT
RESOLVE_INIT | RESOLVE_INIT || Identity_r || Identity_kms
RESOLVE_RESP | RESOLVE_RESP || RESOLVE_INIT
Error message | Error message
Table 5.2: MAC/Signature coverage
表5.2：MAC/签名覆盖率
This section does not describe all the payloads that are used in the new message types. It describes in detail the new TR, IDR, RANDR, TP, and TICKET payloads. For the other payloads, only the additions and changes compared to [RFC3830] are described. For a detailed description of the other MIKEY payloads, see [RFC3830]. Note that the fields with variable length are byte aligned and not 32-bit aligned.
本节不描述新消息类型中使用的所有有效负载。它详细描述了新的TR、IDR、RANDR、TP和票证有效载荷。对于其他有效载荷，仅描述了与[RFC3830]相比的添加和更改。有关其他MIKEY有效载荷的详细说明，请参阅[RFC3830]。请注意，具有可变长度的字段是字节对齐的，而不是32位对齐的。
For the Common Header Payload, new values are added to the Data Type, Next Payload, PRF func, and CS ID map type name spaces.
对于公共标头有效负载，将向数据类型、下一个有效负载、PRF func和CS ID映射类型名称空间添加新值。
* Data Type (8 bits): describes the type of message.
* 数据类型（8位）：描述消息的类型。
Data Type | Value | Comment
-----------------+-------+-------------------------------------
REQUEST_INIT_PSK | 11 | Ticket request initial message (PSK)
REQUEST_INIT_PK | 12 | Ticket request initial message (PK)
REQUEST_RESP | 13 | Ticket request response message
| |
TRANSFER_INIT | 14 | Ticket transfer initial message
TRANSFER_RESP | 15 | Ticket transfer response message
| |
RESOLVE_INIT_PSK | 16 | Ticket resolve initial message (PSK)
RESOLVE_INIT_PK | 17 | Ticket resolve initial message (PK)
RESOLVE_RESP | 18 | Ticket resolve response message
Data Type | Value | Comment
-----------------+-------+-------------------------------------
REQUEST_INIT_PSK | 11 | Ticket request initial message (PSK)
REQUEST_INIT_PK | 12 | Ticket request initial message (PK)
REQUEST_RESP | 13 | Ticket request response message
| |
TRANSFER_INIT | 14 | Ticket transfer initial message
TRANSFER_RESP | 15 | Ticket transfer response message
| |
RESOLVE_INIT_PSK | 16 | Ticket resolve initial message (PSK)
RESOLVE_INIT_PK | 17 | Ticket resolve initial message (PK)
RESOLVE_RESP | 18 | Ticket resolve response message
Table 6.1: Data Type (Additions)
表6.1：数据类型（增补）
* Next Payload (8 bits): identifies the payload that is added after this payload.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
Next Payload | Value | Section
-------------+-------+--------
TR | 13 | 6.4
IDR | 14 | 6.6
RANDR | 15 | 6.8
TP | 16 | 6.10
TICKET | 17 | 6.10
Next Payload | Value | Section
-------------+-------+--------
TR | 13 | 6.4
IDR | 14 | 6.6
RANDR | 15 | 6.8
TP | 16 | 6.10
TICKET | 17 | 6.10
Table 6.2: Next Payload (Additions)
表6.2：下一个有效载荷（增加）
* V (1 bit): flag to indicate whether a response message is expected ('1') or not ('0'). It MUST be set to '0' and ignored in all messages except TRANSFER_INIT messages used for CSB updating (see Section 5.2).
* V（1位）：指示响应消息是否应为（'1'）的标志。必须将其设置为“0”，并在除用于CSB更新的TRANSFER_INIT消息之外的所有消息中忽略它（请参见第5.2节）。
* PRF func (7 bits): indicates the PRF function that has been/will be used for key derivation. Besides the PRFs already defined in [RFC3830] the following additional PRF may be used.
* PRF func（7位）：表示已/将用于密钥派生的PRF函数。除了[RFC3830]中已经定义的PRF外，还可以使用以下附加PRF。
PRF func | Value
-----------------+------
PRF-HMAC-SHA-256 | 1
PRF func | Value
-----------------+------
PRF-HMAC-SHA-256 | 1
Table 6.3: PRF func (Additions)
表6.3:PRF func（新增）
The new PRF SHALL be constructed as described in Section 4.1.2 of [RFC3830] with the differences that HMAC-SHA-256 (see Section 6.2) SHALL be used instead of HMAC-SHA-1 and the value 256 SHALL be used instead of 160. This corresponds to the full output length of SHA-256.
新PRF应按照[RFC3830]第4.1.2节所述进行建造，不同之处在于应使用HMAC-SHA-256（见第6.2节）代替HMAC-SHA-1，且应使用256值代替160。这对应于SHA-256的完整输出长度。
* #CS (8 bits): indicates the number of crypto sessions in the CS ID map info.
* #CS（8位）：表示CS ID映射信息中的加密会话数。
* CS ID map type (8 bits): specifies the method of uniquely mapping crypto sessions to the security protocol sessions. In the Ticket Transfer exchange the new GENERIC-ID map type, which is intended to eliminate the limitations with the existing SRTP-ID map type, SHOULD be used. The map type SRTP-ID SHALL NOT be used.
* CS ID映射类型（8位）：指定将加密会话唯一映射到安全协议会话的方法。在票据转账交换中，应使用新的通用ID映射类型，其旨在消除现有SRTP-ID映射类型的限制。不得使用地图类型SRTP-ID。
CS ID map type | Value
----------------------
GENERIC-ID | 2
CS ID map type | Value
----------------------
GENERIC-ID | 2
Table 6.4: CS ID map type (Additions)
表6.4:CS ID地图类型（增补）
* CS ID map info (variable length): identifies and maps the crypto sessions to the security protocol sessions for which security associations should be created.
* CS ID映射信息（可变长度）：标识加密会话并将其映射到应为其创建安全关联的安全协议会话。
For the GENERIC-ID map type, the CS ID map info consists of #CS number of blocks, each mapping policies, session data (e.g., SSRC), and key to a specific crypto session.
对于GENERIC-ID映射类型，CS ID映射信息由#CS块数、每个映射策略、会话数据（如SSRC）和特定加密会话的密钥组成。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CS ID ! Prot type !S! #P ! Ps (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Session Data Length ! Session Data (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CS ID ! Prot type !S! #P ! Ps (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Session Data Length ! Session Data (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* CS ID (8 bits): defines the CS ID to be used for the crypto session.
* CS ID（8位）：定义用于加密会话的CS ID。
* Prot type (8 bits): defines the security protocol to be used for the crypto session. Allowed values are the ones defined for the Prot type field in the SP payload (see Section 6.10 of [RFC3830]).
* 保护类型（8位）：定义用于加密会话的安全协议。允许值是为SP有效负载中的Prot type字段定义的值（参见[RFC3830]第6.10节）。
* S (1 bit): flag that MAY be used by the Session Data.
* S（1位）：会话数据可能使用的标志。
* #P (7 bits): indicates the number of security policies provided for the crypto session. In response messages, #P SHALL always be exactly 1. So if #P = 0 in an initial message, a security profile MUST be provided in the response message. If #P > 0, one of the suggested policies SHOULD be chosen in the response message. If needed (e.g., in group communication, see Section 9), the suggested policies MAY be changed.
* #P（7位）：表示为加密会话提供的安全策略数。在响应消息中，#P应始终精确为1。因此，如果初始消息中的#P=0，则必须在响应消息中提供安全配置文件。如果#P>0，则应在响应消息中选择建议的策略之一。如果需要（例如，在集团通信中，请参见第9节），建议的策略可能会更改。
* Ps (variable length): lists the policies for the crypto session. It SHALL contain exactly #P policies, each having the specified Prot type.
* Ps（可变长度）：列出加密会话的策略。它应准确地包含#P策略，每个策略具有指定的保护类型。
0 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 ! Policy_no_2 ! ... ! Policy_no_#P !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 ! Policy_no_2 ! ... ! Policy_no_#P !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Policy_no_i (8 bits): a policy_no that corresponds to the policy_no of a SP payload. In response messages, the policy_no may refer to a SP payload in the initial message.
* Policy_no_i（8位）：与SP有效负载的Policy_no相对应的Policy_no。在响应消息中，策略号可能在初始消息中引用SP有效负载。
* Session Data Length (16 bits): the length of Session Data (in bytes). For the Prot type SRTP, Session Data MAY be omitted in the initial message (length = 0), but it MUST be provided in the response message.
* 会话数据长度（16位）：会话数据的长度（字节）。对于Prot类型的SRTP，初始消息（长度=0）中可以省略会话数据，但必须在响应消息中提供。
* Session Data (variable length): contains session data for the crypto session. The type of Session Data depends on the specified Prot type. The Session Data for the Prot type SRTP is defined below. The S flag is used to indicate whether the ROC and SEQ fields are provided ('1') or if they are omitted ('0').
* 会话数据（可变长度）：包含加密会话的会话数据。会话数据的类型取决于指定的保护类型。保护类型SRTP的会话数据定义如下。S标志用于指示是否提供ROC和SEQ字段（“1”）或是否省略它们（“0”）。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC (OPTIONAL) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SEQ (OPTIONAL) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC (OPTIONAL) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SEQ (OPTIONAL) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* SSRC (32 bits): specifies the SSRC that MUST be used for the crypto session. Note that unlike [RFC3830], an SSRC field set to '0' has no special meaning.
* SSRC（32位）：指定加密会话必须使用的SSRC。请注意，与[RFC3830]不同，设置为“0”的SSRC字段没有特殊含义。
* ROC (32 bits): current/initial rollover counter. If the session has not started, this field is set to '0'.
* ROC（32位）：当前/初始翻转计数器。如果会话尚未启动，则此字段设置为“0”。
* SEQ (16 bits): current/initial sequence number.
* 序列号（16位）：当前/初始序列号。
* SPI Length (8 bits): the length of SPI (in bytes). SPI MAY be omitted in the initial message (length = 0), but it MUST be provided in the response message.
* SPI长度（8位）：SPI的长度（字节）。SPI可以在初始消息中省略（长度=0），但必须在响应消息中提供。
* SPI (variable length): the SPI (or MKI) corresponding to the session key to (initially) be used for the crypto session. This does not exclude other keys to be used. All keys MUST belong to the crypto session bundle.
* SPI（可变长度）：对应于要（最初）用于加密会话的会话密钥的SPI（或MKI）。这并不排除要使用的其他键。所有密钥必须属于加密会话捆绑包。
For the KEMAC payload, new encryption and authentication algorithms are defined.
对于KEMAC有效载荷，定义了新的加密和认证算法。
* Encr alg (8 bits): the encryption algorithm used to encrypt the Encr data field. Besides the algorithms already defined in [RFC3830], the following additional encryption algorithm may be used.
* Encr alg（8位）：用于加密Encr数据字段的加密算法。除了[RFC3830]中已经定义的算法外，还可以使用以下附加加密算法。
Encr alg | Value | Comment
-----------+-------+---------------------------
AES-CM-256 | 3 | AES-CM using a 256-bit key
Encr alg | Value | Comment
-----------+-------+---------------------------
AES-CM-256 | 3 | AES-CM using a 256-bit key
Table 6.5: Encr alg (Additions)
表6.5:Encr alg（增补）
The new encryption algorithm is defined as described in Section 4.2.3 of [RFC3830] with the only difference being that a 256-bit key SHALL be used.
新加密算法的定义如[RFC3830]第4.2.3节所述，唯一的区别是应使用256位密钥。
* MAC alg (8 bits): specifies the authentication algorithm used. Besides the algorithms already defined in [RFC3830], the following additional authentication algorithm may be used.
* MAC alg（8位）：指定使用的身份验证算法。除了[RFC3830]中已经定义的算法外，还可以使用以下附加认证算法。
MAC alg | Value | Length
-----------------+-------+---------
HMAC-SHA-256-256 | 2 | 256 bits
MAC alg | Value | Length
-----------------+-------+---------
HMAC-SHA-256-256 | 2 | 256 bits
Table 6.6: MAC alg (Additions)
表6.6:MAC alg（增补）
The new authentication algorithm is Hash-based Message Authentication Code (HMAC) [RFC2104] in conjunction with SHA-256 [FIPS.180-3]. It SHALL be used with a 256-bit authentication key.
新的认证算法是基于散列的消息认证码（HMAC）[RFC2104]与SHA-256[FIPS.180-3]的结合。它应与256位认证密钥一起使用。
For the key data sub-payload, new types of keys are defined. The Group TGK (GTGK) is used as a regular TGK, with the difference that it SHALL NOT be forked. It is intended to enable the establishment of a group TGK when key forking is used. The MIKEY Protection Key (MPK) is used to protect the MIKEY messages in the Ticket Transfer exchange. The MPK is used as the pre-shared key in the pre-shared key method of [RFC3830]; however, it is not known by the Responder before the ticket has been resolved.
对于密钥数据子有效载荷，定义了新类型的密钥。TGK组（GTGK）用作常规TGK，不同之处在于不应分叉。其目的是在使用密钥分叉时建立组TGK。MIKEY保护密钥（MPK）用于保护票证传输交换中的MIKEY消息。在[RFC3830]的预共享密钥方法中，MPK用作预共享密钥；但是，在解决问题之前，响应者不知道。
An SPI (or MKI) MUST be specified for each key (see Section 6.13 of [RFC3830]).
必须为每个密钥指定SPI（或MKI）（见[RFC3830]第6.13节）。
* Type (4 bits): indicates the type of key included in the payload.
* 类型（4位）：指示有效负载中包含的密钥类型。
Type | Value | Comments
----------+-------+---------------------
GTGK | 4 | Group TGK
GTGK+SALT | 5 | Group TGK + SALT
MPK | 6 | MIKEY Protection Key
Type | Value | Comments
----------+-------+---------------------
GTGK | 4 | Group TGK
GTGK+SALT | 5 | Group TGK + SALT
MPK | 6 | MIKEY Protection Key
Table 6.7: Key Data Type (Additions)
表6.7：关键数据类型（增补）
For the timestamp payload, a new type of timestamp is defined. The new type is intended to be used when defining validity periods, where fractions of seconds seldom matter. The NTP-UTC-32 string contains four bytes, in the same format as the first four bytes in the NTP timestamp format, defined in [RFC4330]. This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 7 February 2036, the time value will overflow. [RFC4330] describes a procedure to extend the time to 2104 and this procedure is MANDATORY to support.
对于时间戳负载，定义了一种新类型的时间戳。新的类型旨在定义有效期时使用，在有效期中，秒的分数很少起作用。NTP-UTC-32字符串包含四个字节，格式与[RFC4330]中定义的NTP时间戳格式的前四个字节相同。这表示自1900年1月1日0小时起相对于协调世界时（UTC）的秒数。2036年2月7日，时间值将溢出。[RFC4330]描述了将时间延长至2104的程序，该程序是支持的强制性程序。
* TS Type (8 bits): specifies the timestamp type used.
* TS类型（8位）：指定使用的时间戳类型。
TS Type | Value | Length
-----------+-------+--------
NTP-UTC-32 | 3 | 32 bits
TS Type | Value | Length
-----------+-------+--------
NTP-UTC-32 | 3 | 32 bits
Table 6.8: TS Type (Additions)
表6.8:TS类型（增补）
NTP-UTC-32 SHALL be padded to a 64-bit NTP-UTC timestamp (with zeroes in the fractional second part) when a 64-bit timestamp is required (e.g. IV creation in AES-CM-128 and AES-CM-256).
当需要64位时间戳时（如AES-CM-128和AES-CM-256中的IV创建），NTP-UTC-32应填充为64位NTP-UTC时间戳（分数秒部分为零）。
The TR payload uses all the fields from the standard timestamp payload (T) but expands it with a new field describing the role of the timestamp. Whereas the TS Type describes the type of the TS Value, the TS Role describes the meaning of the timestamp itself. The TR payload is intended to eliminate ambiguity when a MIKEY message contains several timestamp payloads (e.g., in the Ticket Policy).
TR有效负载使用标准时间戳有效负载（T）中的所有字段，但使用描述时间戳角色的新字段对其进行扩展。TS类型描述TS值的类型，而TS角色描述时间戳本身的含义。TR有效载荷旨在消除MIKEY消息包含多个时间戳有效载荷时的歧义（例如，在票证策略中）。
0 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 Role ! TS Type ! TS Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 Role ! TS Type ! TS Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* TS Role (8 bits): specifies the sort of timestamp.
* TS角色（8位）：指定时间戳的种类。
TS Role | Value
-------------------------------+------
Time of issue (TRi) | 1
Start of validity period (TRs) | 2
End of validity period (TRe) | 3
Rekeying interval (TRr) | 4
TS Role | Value
-------------------------------+------
Time of issue (TRi) | 1
Start of validity period (TRs) | 2
End of validity period (TRe) | 3
Rekeying interval (TRr) | 4
Table 6.9: TS Role
表6.9:TS角色
For the ID payload, a new ID Type byte string is defined. The byte string type is intended to be used when the ID payload is used to identify a pre-shared key. Contrary to the previously defined ID Types (URI, Network Access Identifier), the byte string does not have any encoding rules.
对于ID有效负载，定义了一个新的ID类型字节字符串。当ID有效负载用于标识预共享密钥时，将使用字节字符串类型。与之前定义的ID类型（URI、网络访问标识符）相反，字节字符串没有任何编码规则。
* ID Type (8 bits): specifies the identifier type used.
* ID类型（8位）：指定使用的标识符类型。
ID Type | Value
------------+------
Byte string | 2
ID Type | Value
------------+------
Byte string | 2
Table 6.10: ID Type (Additions)
表6.10：ID类型（新增）
The IDR payload uses all the fields from the standard identity payload (ID) but expands it with a new field describing the role of the ID payload. Whereas the ID Type describes the type of the ID Data, the ID Role describes the meaning of the identity itself. The IDR payload is intended to eliminate ambiguity when a MIKEY message contains several identity payloads. The IDR payload MUST be used instead of the ID payload in all MIKEY-TICKET messages.
IDR有效负载使用标准标识有效负载（ID）中的所有字段，但使用描述ID有效负载角色的新字段对其进行扩展。ID类型描述ID数据的类型，ID角色描述标识本身的含义。IDR有效载荷旨在消除MIKEY消息包含多个标识有效载荷时的歧义。在所有MIKEY-TICKET消息中，必须使用IDR有效负载，而不是ID有效负载。
0 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 Role ! ID Type ! ID len
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID len (cont) ! ID Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 Role ! ID Type ! ID len
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID len (cont) ! ID Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* ID Role (8 bits): specifies the sort of identity.
* ID角色（8位）：指定标识的种类。
ID Role | Value
------------------------+------
Initiator (IDRi) | 1
Responder (IDRr) | 2
KMS (IDRkms) | 3
Pre-Shared Key (IDRpsk) | 4
Application (IDRapp) | 5
ID Role | Value
------------------------+------
Initiator (IDRi) | 1
Responder (IDRr) | 2
KMS (IDRkms) | 3
Pre-Shared Key (IDRpsk) | 4
Application (IDRapp) | 5
Table 6.11: ID Role
表6.11:ID角色
IDRapp is intended to specify the authorized Application IDs (see Sections 5.1.3 and 6.10)
IDRapp旨在指定授权应用程序ID（见第5.1.3节和第6.10节）
* Hash func (8 bits): indicates the hash function that is used. Besides the hash functions already defined in [RFC3830], the following hash function may be used.
* 哈希函数（8位）：表示使用的哈希函数。除了[RFC3830]中已经定义的哈希函数外，还可以使用以下哈希函数。
Hash func | Value | Hash Length
----------+-------+------------
SHA-256 | 2 | 256 bits
Hash func | Value | Hash Length
----------+-------+------------
SHA-256 | 2 | 256 bits
Table 6.12: Hash func (Additions)
表6.12：哈希函数（增补）
The SHA-256 hash function is defined in [FIPS.180-3].
[FIPS.180-3]中定义了SHA-256哈希函数。
The RANDR payload uses all the fields from the standard RAND payload (RAND) but expands it with a new field describing the role (the generating entity) of the RAND. The RANDR payload is intended to eliminate ambiguity when a MIKEY message contains several RAND payloads.
RANDR有效负载使用标准RAND有效负载（RAND）中的所有字段，但使用一个新字段对其进行扩展，该字段描述RAND的角色（生成实体）。RANDR有效载荷旨在消除MIKEY消息包含多个RAND有效载荷时的歧义。
0 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 Role ! RAND length ! RAND ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 Role ! RAND length ! RAND ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* RAND Role (8 bits): specifies the entity that generated the RAND.
* RAND角色（8位）：指定生成RAND的实体。
RAND Role | Value
-------------------+------
Initiator (RANDRi) | 1
Responder (RANDRr) | 2
KMS (RANDRkms) | 3
RAND Role | Value
-------------------+------
Initiator (RANDRi) | 1
Responder (RANDRr) | 2
KMS (RANDRkms) | 3
Table 6.13: RAND Role
表6.13：兰德公司的作用
For the key data sub-payload, new types of errors are defined.
对于关键数据子负载，定义了新类型的错误。
* Error no (8 bits): indicates the type of error that was encountered.
* 错误编号（8位）：指示遇到的错误类型。
Error no | Value | Comments
---------------+-------+----------------------------
Invalid TICKET | 14 | Ticket Type not supported
Invalid TPpar | 15 | TP parameters not supported
Error no | Value | Comments
---------------+-------+----------------------------
Invalid TICKET | 14 | Ticket Type not supported
Invalid TPpar | 15 | TP parameters not supported
Table 6.14: Error no (Additions)
表6.14：错误编号（增补）
Note that the Ticket Policy payload (TP) and the Ticket Payload (TICKET) are two different payloads (having different payload identifiers). However, as they share much of the payload structure, they are described in the same section.
注意，票据策略有效负载（TP）和票据有效负载（Ticket）是两个不同的有效负载（具有不同的有效负载标识符）。然而，由于它们共享大部分有效载荷结构，因此在同一节中对它们进行了描述。
The Ticket Policy payload contains a desired Ticket Policy and does not include the Ticket Data length, Ticket Data, Initiator Data length, or Initiator Data fields. The ticket payload contains the granted Ticket Policy as well as Ticket Data (the default ticket type is defined in Appendix A). The Ticket Policy contains information intended for all parties involved whereas the Ticket Data is only intended for the party that resolves the ticket. The Ticket Type provided in the Ticket Data is indicated in the Ticket Policy. When key forking is used (I flag), the Initiator Data authenticates the Initiator.
票证策略有效负载包含所需的票证策略，不包括票证数据长度、票证数据、启动器数据长度或启动器数据字段。票证有效负载包含已授予的票证策略以及票证数据（默认票证类型在附录A中定义）。票证策略包含适用于所有相关方的信息，而票证数据仅适用于解决票证的一方。票证数据中提供的票证类型在票证策略中指示。当使用密钥分叉（I标志）时，启动器数据验证启动器。
Note that the flags are not independent: NOT D implies L, G implies F, NOT G implies H, NOT H implies G, I implies E, K implies D, and M implies F. The F flag SHALL be set to '1' when the I flag (key forking) is set to '1' and a TGK is encoded in the ticket.
请注意，标志不是独立的：非D意味着L，G意味着F，非G意味着H，非H意味着G，I意味着E，K意味着D，M意味着F。当I标志（密钥分叉）设置为“1”且TGK编码在票据中时，F标志应设置为“1”。
0 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 ! Ticket Type ! Subtype !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Version ! PRF Func !D!E!F!G!H!I!J!K!L!M!N!O! Res !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! TP Data length ! TP Data ~
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
! Ticket Data length ! Ticket Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initiator Data length ! Initiator Data (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 ! Ticket Type ! Subtype !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Version ! PRF Func !D!E!F!G!H!I!J!K!L!M!N!O! Res !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! TP Data length ! TP Data ~
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
! Ticket Data length ! Ticket Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initiator Data length ! Initiator Data (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Payload (8 bits): identifies the payload that is added after this payload.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
* Ticket Type (16 bits): specifies the Ticket Type used.
* 票证类型（16位）：指定使用的票证类型。
Ticket Type | Value | Comments
------------------+-------+---------------------------
MIKEY Base Ticket | 1 | Defined in Appendix A
3GPP Base Ticket | 2 | Used and specified by 3GPP
Ticket Type | Value | Comments
------------------+-------+---------------------------
MIKEY Base Ticket | 1 | Defined in Appendix A
3GPP Base Ticket | 2 | Used and specified by 3GPP
Table 6.15: Ticket Type
表6.15：车票类型
Subtype = 0x01 and Version = 0x01 refers to MIKEY Base Ticket as defined in this document.
Subtype=0x01和Version=0x01表示本文档中定义的MIKEY基本票证。
* Subtype (8 bits): specifies the ticket subtype used.
* 子类型（8位）：指定使用的票据子类型。
* Version (8 bits): specifies the ticket subtype version used.
* 版本（8位）：指定使用的票证子类型版本。
* PRF Func (7 bits): specifies the PRF that SHALL be used for key forking.
* PRF Func（7位）：指定用于密钥分叉的PRF。
* D (1 bit): flag to indicate whether the ticket was generated by the KMS ('1') or by the Initiator ('0').
* D（1位）：指示票据是由KMS（“1”）还是由启动器（“0”）生成的标志。
* E (1 bit): flag to indicate whether the Ticket Resolve exchange is MANDATORY ('1') or if the Responder MAY resolve the ticket ('0').
* E（1位）：指示票据解析交换是强制的（'1'）还是响应者可以解析票据（'0'）的标志。
* F (1 bit): flag to indicate whether the TRANSFER_RESP message SHALL be sent ('1') or if it SHALL NOT be sent ('0').
* F（1位）：指示传输响应消息是应发送（“1”）还是不应发送（“0”）的标志。
* G (1 bit): flag to indicate whether the Responder SHALL generate RANDRr ('1') or if the Responder SHALL NOT generate RANDRr ('0').
* G（1位）：指示响应者是否应生成RANDRr（'1'）或响应者是否应生成RANDRr（'0'）的标志。
* H (1 bit): flag to indicate whether RANDRi SHALL be used when deriving keys from a TGK/GTGK ('1') or if RANDRi SHALL NOT be used ('0').
* H（1位）：用于指示从TGK/GTGK（“1”）导出密钥时是否应使用RANDRi或不应使用RANDRi（“0”）的标志。
* I (1 bit): flag to indicate whether key forking SHALL be used ('1') or if key forking SHALL NOT be used ('0').
* I（1位）：指示是否应使用钥匙分叉（“1”）或不应使用钥匙分叉（“0”）的标志。
* J (1 bit): flag to indicate whether the ticket MAY be reused ('1') and therefore MAY be cached or if it SHALL NOT be reused ('0').
* J（1位）：指示票据是否可重复使用（“1”）并因此可被缓存的标志，或指示票据是否不应重复使用的标志（“0”）。
* K (1 bit): flag to indicate whether the KMS changed the desired Ticket Policy or the desired KEMAC ('1') or if it did not ('0'). In the TP payload, it SHALL be set to '0' by the Initiator and ignored by the KMS.
* K（1位）：用于指示KMS是否更改了所需的票证政策或所需的KEMAC（“1”）或是否更改了所需的KEMAC（“0”）的标志。在TP有效载荷中，启动器应将其设置为“0”，KMS应忽略该值。
* L (1 bit): flag to indicate whether the Initiator MAY supply session keys ('1') or if the Initiator SHALL NOT supply session keys ('0').
* L（1位）：指示启动器是否可提供会话密钥（“1”）或启动器是否不应提供会话密钥（“0”）的标志。
* M (1 bit): flag to indicate whether the Responder MAY supply session keys ('1') or if the Responder SHALL NOT supply session keys ('0').
* M（1位）：指示响应者是否可提供会话密钥（“1”）或响应者是否不应提供会话密钥（“0”）的标志。
* N (1 bit): flag to indicate whether an Initiator following this specification can initiate a TRANSFER_INIT message using the ticket ('1') or if additional processing is required ('0'). If the flag is set to '0', the Initiator SHOULD follow the processing in the specification of the received Ticket Type.
* N（1位）：指示遵循此规范的启动器是否可以使用票证（“1”）启动TRANSFER_INIT消息或是否需要额外处理（“0”）的标志。如果标志设置为“0”，则启动器应遵循所接收票证类型规范中的处理。
* O (1 bit): flag to indicate whether a Responder following this specification can process a TRANSFER_INIT message containing the ticket ('1') or if additional processing is required ('0'). If the flag is set to '0', the Responder SHOULD follow the processing in the specification of the received Ticket Type.
* O（1位）：指示遵循此规范的响应程序是否可以处理包含票证（“1”）的TRANSFER_INIT消息，或者是否需要额外处理（“0”）的标志。如果标志设置为“0”，则响应者应遵循所接收票证类型规范中的处理。
* Res (5 bits): reserved for future use.
* Res（5位）：保留供将来使用。
* TP Data length (16 bits): length of TP Data (in bytes).
* TP数据长度（16位）：TP数据的长度（字节）。
* TP Data (variable length): The first 8 bits identify the first payload. The rest of TP Data SHALL be constructed of MIKEY payloads. Unexpected payloads in the TP Data SHOULD be ignored.
* TP数据（可变长度）：前8位标识第一个有效负载。TP数据的其余部分应由MIKEY有效载荷构成。应忽略TP数据中意外的有效负载。
TP Data = First Payload, [IDRkms], [IDRi], [TRs], [TRe], [TRr], [KEMAC], {IDRapp}, (IDRr)
TP Data=第一有效载荷[IDRkms]、[IDRi]、[TRs]、[TRr]、[KEMAC]、{IDRapp}，（IDRr）
IDRkms contains the identity of a KMS that can resolve the ticket.
IDRkms包含可以解析票据的KMS的标识。
IDRi contains the identity of the peer that requested or created the ticket.
IDRi包含请求或创建票证的对等方的标识。
TRs is the start of the validity period. TRs SHALL be interpreted as being in the range 1968-2104 as described in [RFC4330]. An omitted TRs means that the validity period has no defined beginning.
TRs是有效期的开始。TRs应解释为在[RFC4330]中所述的1968-2104范围内。省略的TRs表示有效期没有定义的开始。
TRe is the end of the validity period. TRe SHALL be interpreted as being in the range 1968-2104 as described in [RFC4330]. An omitted TRe means that the validity period has no defined end.
TRe是有效期的结束。TRe应解释为在[RFC4330]中所述的1968-2104范围内。省略的TRe表示有效期没有定义的结束。
TRr indicates how often rekeying MUST be done. TS Type SHALL be NTP-UTC-32 and the time between two rekeyings SHALL NOT be longer than the number of seconds in the integer part of the timestamp. How the rekeying is done is implementation specific.
TRr表示必须进行密钥更新的频率。TS类型应为NTP-UTC-32，两次重新键入之间的时间不得超过时间戳整数部分的秒数。如何进行密钥更新是特定于实现的。
The KEMAC payload may be used to indicate the number of requested keys and specify other key information (key type, key length, and KV (key validity) data). The KEMAC payload SHALL use the NULL encryption algorithm and the NULL authentication algorithm, as a MAC is included in the V payload. The KEMAC is hence constructed as follows:
KEMAC有效载荷可用于指示请求钥匙的数量，并指定其他钥匙信息（钥匙类型、钥匙长度和KV（钥匙有效性）数据）。KEMAC有效载荷应使用空加密算法和空认证算法，因为MAC包含在V有效载荷中。因此，KEMAC的结构如下：
KEMAC = {TEK|TGK|GTGK}
KEMAC = {TEK|TGK|GTGK}
The Key Data fields SHALL be set to '0' by the Initiator and ignored by the KMS. The KEMAC SHALL NOT be present in the granted Ticket Policy.
发起者应将关键数据字段设置为“0”，KMS将其忽略。KEMAC不得出现在授予的机票政策中。
IDRapp is an identifier for an authorized application ID. The application IDs are implementation specific. If no IDRapp payloads are supplied, all application IDs are authorized.
IDRapp是授权应用程序ID的标识符。应用程序ID是特定于实现的。如果未提供IDRapp有效负载，则授权所有应用程序ID。
IDRr is the identity of a responder or a group of responders that are authorized to resolve the ticket. If there is more than one responder identity, each responder identity SHALL be included in a separate IDR payload.
IDRr是有权解析票据的响应者或响应者组的标识。如果有多个响应者标识，则每个响应者标识应包含在单独的IDR有效载荷中。
* Ticket Data length (16 bits): the length of the Ticket Data field (in bytes). Not present in the TP payload.
* 票证数据长度（16位）：票证数据字段的长度（字节）。TP有效负载中不存在。
* Ticket Data (variable length): contains the Ticket Data. Not present in the TP payload.
* 票证数据（可变长度）：包含票证数据。TP有效负载中不存在。
* Initiator Data length (16 bits): the length of the Initiator Data field (in bytes). Not present in the TP payload.
* 启动器数据长度（16位）：启动器数据字段的长度（字节）。TP有效负载中不存在。
* Initiator Data (variable length): Not present in the TP payload. SHALL be inserted by the Initiator if and only if key forking is used (I flag). The first 8 bits identifies the first payload. The rest of Initiator Data SHALL be constructed of MIKEY payloads. Unexpected payloads in the Initiator Data SHOULD be ignored.
* 启动器数据（可变长度）：TP有效负载中不存在。当且仅当使用钥匙分叉（I标志）时，发起者应插入。前8位标识第一有效负载。其余启动器数据应由MIKEY有效载荷构成。应忽略启动器数据中的意外有效负载。
Initiator Data = First Payload, Vi, Vr
启动器数据=第一个有效负载，Vi，Vr
The Vi payload SHALL be identical to the V payload in the TRANSFER_INIT message.
Vi有效载荷应与TRANSFER_INIT消息中的V有效载荷相同。
The last payload (Vr) SHALL be a Verification payload where the MAC SHALL cover the entire Initiator Data field except the MAC field itself. The authentication algorithm SHALL be the same as used for the Vi payload. The authentication key (auth_key) SHALL be derived from MPKr (not forked) using the following parameters:
最后一个有效载荷（Vr）应为验证有效载荷，其中MAC应覆盖除MAC字段本身之外的整个启动器数据字段。认证算法应与Vi有效载荷使用的算法相同。认证密钥（auth_密钥）应使用以下参数从MPKr（非分叉）派生：
inkey: : MPKr inkey_len : bit length of the inkey label : constant || 0xFF || 0xFFFFFFFF || 0x04 outkey_len : desired bit length of the outkey (encr_key, auth_key, salt_key)
inkey:：MPKr inkey_len:inkey标签的位长度：常量| | 0xFF | | 0xFFFFFF | | 0x04 outkey_len:outkey的所需位长度（encr|U键、auth|U键、salt_键）
The constant depends on the derived key type as defined in Section 4.1.4 of [RFC3830].
该常数取决于[RFC3830]第4.1.4节中定义的衍生密钥类型。
MIKEY messages are not tied to any specific transport protocols. In [RFC4567], extensions for SDP and RTSP to carry MIKEY messages (and therefore MIKEY-TICKET messages) are defined. The messages in the Ticket Transfer exchange (TRANSFER_INIT, TRANSFER_RESP) are preferably included in the session setup signaling (e.g., SIP INVITE and 200 OK). However, it may not be suitable for the MIKEY-TICKET exchanges that do not establish keying material for media sessions (Ticket Request and Ticket Resolve) to be carried in SDP or RTSP. If SDP or RTSP is not used, the transport protocol needs to be defined. In [3GPP.33.328], it is defined how the Ticket Request and Ticket Resolve exchanges are carried over HTTP.
MIKEY消息不绑定到任何特定的传输协议。在[RFC4567]中，定义了SDP和RTSP传输MIKEY消息（因此也包括MIKEY-TICKE消息）的扩展。票证传输交换（Transfer_INIT、Transfer_RESP）中的消息优选地包括在会话设置信令中（例如，SIP INVITE和200 OK）。但是，它可能不适用于未为SDP或RTSP中的媒体会话（票证请求和票证解析）建立密钥材料的MIKEY-TIKET交换。如果未使用SDP或RTSP，则需要定义传输协议。在[3GPP.33.328]中，定义了票证请求和票证解析交换如何通过HTTP进行。
The default setting is that the KMS supplies the session keys (encoded in the ticket). This is not possible if the content is pre-encrypted (e.g., Video on Demand). In such use cases, the key
默认设置是KMS提供会话密钥（编码在票据中）。如果内容是预加密的（例如，视频点播），则不可能做到这一点。在这样的用例中，关键
exchange is typically reversed and MAY be carried out as follows. The Initiator sends a ticket without encoded session keys to the Responder in a TRANSFER_INIT message. The Responder has access to the TEKs used to protect the requested content, but may not be streaming the content. The Responder includes the TEK in the TRANSFER_RESP message, which is sent to the Initiator.
交换通常是反向的，可以按如下方式进行。发起方在TRANSFER_INIT消息中将不带编码会话密钥的票证发送给响应方。响应者可以访问用于保护请求内容的TEK，但可能不会对内容进行流式传输。响应方将TEK包含在发送给发起方的传输响应消息中。
+---+ +---+
| I | | R |
+---+ +---+
TRANSFER_INIT
---------------------------------------------------------------->
TRANSFER_RESP {KEMAC}
<----------------------------------------------------------------
+---+ +---+
| I | | R |
+---+ +---+
TRANSFER_INIT
---------------------------------------------------------------->
TRANSFER_RESP {KEMAC}
<----------------------------------------------------------------
Figure 6: Distribution of pre-encrypted content
图6：预加密内容的分发
What has been discussed up to now can also be used for group communication. The MIKEY signaling for multi-party sessions can be centralized as illustrated in Figure 7.
到目前为止所讨论的内容也可用于小组交流。多方会话的MIKEY信令可以集中，如图7所示。
+---+ +---+ +---+
| A | | B | | C |
+---+ +---+ +---+
Ticket Transfer
<-------------------------------> Ticket Transfer
<--------------------------------------------------------------->
+---+ +---+ +---+
| A | | B | | C |
+---+ +---+ +---+
Ticket Transfer
<-------------------------------> Ticket Transfer
<--------------------------------------------------------------->
Figure 7: Centralized signaling around party A
图7：甲方周围的集中信令
or decentralized as illustrated in Figure 8.
或分散，如图8所示。
+---+ +---+ +---+
| A | | B | | C |
+---+ +---+ +---+
Ticket Transfer
<-------------------------------> Ticket Transfer
<------------------------------->
+---+ +---+ +---+
| A | | B | | C |
+---+ +---+ +---+
Ticket Transfer
<-------------------------------> Ticket Transfer
<------------------------------->
Figure 8: Decentralized signaling
图8：分散信号
In the decentralized scenario, the identities of B and C SHALL be used in the second Ticket Transfer exchange. Independent of the how the MIKEY signaling is done, a group key may be used as session key.
在分散方案中，B和C的标识应用于第二次票务转账交换。不管MIKEY信令是如何完成的，组密钥可以用作会话密钥。
If a group key is used, the group key and session information may be pushed to all group members (similar to [RFC3830]), or distributed when requested (similar to [RFC4738]). If a TGK/GTGK is used as a group key, the same RANDs MUST be used to derive the session keys in all Ticket Transfer exchanges. Also note caveats with ticket reuse in group communication settings as discussed in Section 5.3.
如果使用了组密钥，则可以将组密钥和会话信息推送到所有组成员（类似于[RFC3830]），或者在请求时分发（类似于[RFC4738]）。如果TGK/GTGK用作组密钥，则必须使用相同的RAND来派生所有票证传输交换中的会话密钥。另请注意第5.3节讨论的组通信设置中的票证重用注意事项。
When key forking is used, only the user that requested the ticket can initiate a Ticket Transfer exchange using that ticket, see Section 5.3. So if a group key is to be distributed, the MIKEY signaling MUST be centralized to the party that initially requested the ticket, or different tickets needs to be used in each Ticket Transfer exchange and the group key needs to be sent in a KEMAC.
当使用钥匙分叉时，只有请求票证的用户才能使用该票证发起票证转账交换，见第5.3节。因此，如果要分发组密钥，则必须将MIKEY信令集中到最初请求票证的一方，或者需要在每个票证转账交换中使用不同的票证，并且组密钥需要在KEMAC中发送。
Another consideration is that different users get different session keys if TGKs (encoded in the ticket) are used.
另一个考虑因素是，如果使用TGK（编码在票据中），不同的用户会获得不同的会话密钥。
A user can in general only be expected to have a trust relation with a single KMS. Different users might therefore use tickets issued by different KMSs using only locally known keys. Thus, if users with trust relations to different KMSs are to be able to establish a secure session with each other, the KMSs involved have to cooperate and there has to be a trust relation between them. The KMSs SHALL be mutually authenticated and signaling between them SHALL be integrity and confidentiality protected. The technical means for the inter-KMS security is however outside the scope of this specification. Under these assumptions, the following approach MAY be used.
通常，用户只能与单个KMS建立信任关系。因此，不同的用户可能只使用本地已知密钥使用不同KMS发行的票据。因此，如果与不同KMS具有信任关系的用户要能够彼此建立安全会话，则所涉及的KMS必须合作，并且它们之间必须存在信任关系。KMS应相互认证，且它们之间的信号应完整且保密。但是，KMS间安全的技术手段不在本规范的范围内。在这些假设下，可采用以下方法。
+---+ +---+ +-------+ +-------+
| I | | R | | KMS R | | KMS I |
+---+ +---+ +-------+ +-------+
TRANSFER_INIT
--------------------> RESOLVE_INIT
- - - - - - - - - - -> RESOLVE_INIT
- - - - - - - - - - ->
RESOLVE_RESP
RESOLVE_RESP <- - - - - - - - - - -
TRANSFER_RESP < - - - - - - - - - -
<--------------------
+---+ +---+ +-------+ +-------+
| I | | R | | KMS R | | KMS I |
+---+ +---+ +-------+ +-------+
TRANSFER_INIT
--------------------> RESOLVE_INIT
- - - - - - - - - - -> RESOLVE_INIT
- - - - - - - - - - ->
RESOLVE_RESP
RESOLVE_RESP <- - - - - - - - - - -
TRANSFER_RESP < - - - - - - - - - -
<--------------------
Figure 9: Routing of resolve messages
图9：解析消息的路由
If the Responder cannot directly resolve a ticket, the ticket SHOULD be included in a RESOLVE_INIT message sent to a KMS. If the Responder does not have a shared credential with the KMS that issued the ticket (KMS I) or if the Responder does not know which KMS issued the ticket, the Responder SHOULD send the RESOLVE_INIT message to one of the Responder's trusted KMSs (KMS R). If KMS R did not issue the ticket, KMS R would normally be unable to directly resolve the ticket and must hence ask another KMS to resolve it (typically the issuing KMS).
如果响应者无法直接解析票证，则该票证应包含在发送给KMS的resolve_INIT消息中。如果响应者与发出票据的KMS（KMS I）没有共享凭证，或者响应者不知道是哪个KMS发出票据，则响应者应将RESOLVE_INIT消息发送到响应者的一个受信任KMS（KMS R）。如果KMS R没有发出票据，则KMS R通常无法直接解析票据，因此必须请求其他KMS解析票据（通常是发出票据的KMS）。
The signaling between different KMSs MAY be done with a Ticket Resolve exchange as illustrated in Figure 9. The IDRr and TICKET payloads from the previous RESOLVE_INIT message SHOULD be reused. Note that IDRr cannot be used to look up the pre-shared key/ certificate.
不同KMS之间的信令可以通过票证解析交换完成，如图9所示。应重用来自上一个RESOLVE_INIT消息的IDRr和票证有效载荷。请注意，IDRr不能用于查找预共享密钥/证书。
The Ticket Data (in the TICKET payload) could be a reference to information (keys, etc.) stored by the key management service, it could contain all the information itself, or it could be a combination of the two alternatives. For systems serving many users, it is not ideal to use the reference-only ticket approach as this would force the key management service to keep state of all issued tickets that are still valid. Tickets may carry many different types of information helping to enforce usage policies. The policies may be group policies or per-user policies.
票证数据（在票证有效载荷中）可以是对密钥管理服务存储的信息（密钥等）的引用，它可以包含所有信息本身，也可以是两个备选方案的组合。对于服务于许多用户的系统，使用仅参考票证方法并不理想，因为这将迫使密钥管理服务保持所有已发行票证的状态，这些票证仍然有效。票证可能包含许多不同类型的信息，有助于实施使用策略。策略可以是组策略或每用户策略。
Tickets may either be transparent, meaning they can be resolved without contacting the KMS that generated them, or opaque, meaning that the original KMS must be contacted. The ticket information SHOULD typically be integrity protected and certain fields need confidentiality protection, in particular, the keys if explicitly included. Other types of information may also require confidentiality protection due to privacy reasons. In mode 2 (see Section 4.1.1), it may be preferable to include several encrypted ticket protection keys (similar to Secure/Multipurpose Internet Mail Extensions (S/MIME)) as this may allow multiple peers to resolve the ticket.
票证可以是透明的，这意味着它们可以在不联系生成它们的KMS的情况下解析；也可以是不透明的，这意味着必须联系原始KMS。票证信息通常应受到完整性保护，某些字段需要保密保护，特别是明确包含的密钥。由于隐私原因，其他类型的信息也可能需要保密保护。在模式2（见第4.1.1节）中，最好包括多个加密的票证保护密钥（类似于安全/多用途互联网邮件扩展（S/MIME）），因为这可能允许多个对等方解析票证。
The Ticket Data MUST include information so that the resolving party can retrieve an encoded KEMAC. It MUST also be possible to verify the integrity of the TICKET payload. It is RECOMMENDED that future specifications use the recommended payload order and do not add any additional payloads or processing. New Ticket Types SHOULD NOT change the processing for the Responder. If a new Ticket Type
票据数据必须包含信息，以便解析方能够检索编码的KEMAC。还必须能够验证票据有效负载的完整性。建议将来的规范使用建议的有效负载顺序，不要添加任何额外的有效负载或处理。新的票证类型不应改变响应者的处理。如果是新的票证类型
requires additional processing, it MUST be indicated in the Ticket Policy (N and O flags). New specifications MUST specify which modes are supported and if any additional security considerations apply.
需要额外处理，必须在票证策略中指明（N和O标志）。新规范必须指定支持哪些模式，以及是否应用了任何其他安全注意事项。
Unless otherwise stated, the security considerations in [RFC3830] still apply and contain notes on the security properties of the MIKEY protocol, key derivation functions, and other components. As some security properties depend on the specific Ticket Type, only generic security considerations concerning the MIKEY-TICKET framework are discussed.
除非另有说明，[RFC3830]中的安全注意事项仍然适用，并包含有关MIKEY协议、密钥派生函数和其他组件的安全属性的说明。由于某些安全属性取决于特定的票证类型，因此仅讨论有关MIKEY-TICKE框架的一般安全注意事项。
This specification includes a large number of optional features, which adds complexity to the general case. Protocol designers are strongly encouraged to establish strict profiles defining MIKEY-TICKET options (e.g., exchanges or message fields) that SHOULD or MUST be supported. Such profiles should preclude unexpected consequences from compliant implementations with wildly differing option sets.
该规范包括大量可选特性，这增加了一般情况的复杂性。强烈鼓励协议设计者建立严格的配置文件，定义应该或必须支持的MIKEY-TICKET选项（例如，交换或消息字段）。这样的配置文件应该能够防止使用不同选项集的兼容实现带来意外后果。
In addition to the Ticket Policy, the KMS MAY have its own set of policies (authorized key lengths, algorithms, etc.) that in some way are shared with the peers. The KMS MAY also provide keying material to authorized intermediate nodes performing various network functions (e.g., transcoding services, recording services, conference bridges). The key management service can enforce end-to-end security by only distributing the keys to authorized end-users. As in [RFC3830], the user identities are not confidentiality protected. If user privacy is needed, some kind of Privacy Enhancing Technologies (PET) like anonymous or temporary credentials MAY be used.
除了票证策略外，KMS可能有自己的策略集（授权密钥长度、算法等），以某种方式与对等方共享。KMS还可以向执行各种网络功能（例如，转码服务、记录服务、会议网桥）的授权中间节点提供密钥材料。密钥管理服务可以通过仅将密钥分发给授权的最终用户来实施端到端安全性。与[RFC3830]一样，用户身份不受保密保护。如果需要用户隐私，可以使用某种隐私增强技术（PET），如匿名或临时凭证。
In the standard MIKEY modes [RFC3830], the keys are generated by the Initiator (or by both peers in the Diffie-Hellman scheme). If a bad PRNG (Pseudorandom Number Generator) is used, this is likely to make any key management protocol sensitive to different kinds of attacks, and MIKEY is no exception. As the choice of the PRNG is implementation specific, the easiest (and often bad) choice is to use the PRNG supplied by the operating system. In MIKEY-TICKET's default mode of operation, the key generation is mostly done by the KMS, which can be assumed to be less likely to use a bad random number generator. All keys (including keys used to protect the ticket) MUST have adequate strength/length, i.e., 128 bits or more.
在标准MIKEY模式[RFC3830]中，密钥由发起方（或Diffie-Hellman方案中的两个对等方）生成。如果使用坏的PRNG（伪随机数生成器），这可能会使任何密钥管理协议对不同类型的攻击敏感，MIKEY也不例外。由于PRNG的选择是特定于实现的，因此最简单（通常是错误的）选择是使用操作系统提供的PRNG。在MIKEY-TICKET的默认操作模式下，密钥生成主要由KMS完成，可以假设KMS不太可能使用坏随机数生成器。所有密钥（包括用于保护票据的密钥）必须具有足够的强度/长度，即128位或更多。
The use of random nonces (RANDs) in the key derivation is of utmost importance to counter offline pre-computation attacks and other generic attacks. A key of length n, using RANDs of length r, has effective key entropy of (n + r) / 2 against a birthday attack. Therefore, the sum of the lengths of RANDRi and RANDRr MUST at least be equal to the size of the longest pre-shared key/envelope key/MPK/ TGK/GTGK, RANDRkms MUST at least be as long as the longest MPKr/TGK, and the RAND in the MIKEY base ticket MUST at least be as long as the longest of TPK and MPK.
在密钥推导中使用随机nonce（RANDs）对于抵抗离线预计算攻击和其他一般攻击至关重要。长度为n的密钥使用长度为r的随机数，其有效密钥熵为（n+r）/2，可抵御生日攻击。因此，RANDRi和RANDRr的长度之和必须至少等于最长的预共享密钥/信封密钥/MPK/TGK/GTGK的大小，RANDRkms必须至少与最长的MPKr/TGK一样长，并且MIKEY基本票证中的RAND必须至少与TPK和MPK中最长的长度一样长。
Note that the CSB Updating messages reuse the old RANDs. This means that the total effective key entropy (relative to pre-computation attacks) for k consecutive key updates, assuming the TGKs are each n bits long, is still no more than n bits. In other words, the time and memory needed by an attacker to get all k n-bit keys are proportional to 2^n. While this might seem like a defect, this is in practice (for all reasonable values of k) not better than brute force, which on average requires k * 2^(n-1) work (even if different RANDs would be used). A birthday attack would only require 2^(n/2) work, but would need access to 2^(n/2) sessions protected with equally many different keys using a single pair of RANDs. This is, for typical values of n, clearly totally infeasible. The success probability of such an attack can be controlled by limiting the number of updates correspondingly. As stated in [RFC3830], the fact that more than one key can be compromised in a single attack is inherent to any solution using secret- or public-key algorithms. An attacker always gets access to all the exchanged keys by doing an exhaustive search on the pre-shared key/envelope key/MPK. This requires 2^m work, where m is the effective size of the key.
请注意，CSB更新消息重用旧RAND。这意味着，对于k个连续密钥更新（假设tgk每个长度为n比特），总有效密钥熵（相对于计算前攻击）仍然不超过n比特。换句话说，攻击者获取所有k n位密钥所需的时间和内存与2^n成正比。虽然这似乎是一个缺陷，但实际上（对于所有合理的k值），这并不比蛮力好，蛮力平均需要k*2^（n-1）功（即使使用不同的rand）。生日攻击只需要2^（n/2）个工作，但需要使用一对RAND访问2^（n/2）个会话，这些会话由相同数量的不同密钥保护。对于n的典型值，这显然是完全不可行的。通过相应地限制更新的数量，可以控制此类攻击的成功概率。如[RFC3830]所述，在一次攻击中可以泄露多个密钥这一事实是使用秘密或公钥算法的任何解决方案所固有的。攻击者总是通过对预共享密钥/信封密钥/MPK进行彻底搜索来访问所有交换的密钥。这需要2^m的功，其中m是键的有效大小。
As the Responder MAY generate a RAND, the Ticket Transfer exchange can provide mutual freshness guarantee for all derived keys.
由于响应者可以生成RAND，票证传输交换可以为所有派生密钥提供相互新鲜性保证。
The new algorithms PRF-HMAC-SHA-256, AES-CM-256, and HMAC-SHA-256-256 use 256-bit keys and offer a higher security level than the previously defined algorithms. If one of the 256-bit algorithms are supported, the other two algorithms SHALL also be supported. The 256-bit algorithms SHOULD be used together, and they SHALL NOT be mixed with algorithms using key sizes less than 256 bits. If session keys (TEK/TGK/GTGK) longer than 128 bits are used, 128-bit algorithms SHALL NOT be used.
新算法PRF-HMAC-SHA-256、AES-CM-256和HMAC-SHA-256-256使用256位密钥，提供比先前定义的算法更高的安全级别。如果支持256位算法中的一种，则还应支持其他两种算法。256位算法应一起使用，不得与密钥大小小于256位的算法混合使用。如果使用的会话密钥（TEK/TGK/GTGK）超过128位，则不得使用128位算法。
In some situations, the TRANSFER_INIT message may be delivered to multiple endpoints. For example, when a Responder is registered on several devices (e.g., mobile phone, fixed phone, and computer) or when an invite is being made to addresses of the type
在某些情况下，TRANSFER_INIT消息可能会传递到多个端点。例如，当响应者在多个设备（例如，移动电话、固定电话和计算机）上注册时，或者当向该类型的地址发出邀请时
IT-support@example.com, a group of users where only one is supposed to answer. The Initiator may not even always know exactly who the authorized group members are. To prevent all forms of eavesdropping, entities other than the endpoint that answers MUST NOT get access to the session keys.
它-support@example.com，一组用户，其中只有一个应该回答。发起人甚至可能并不总是确切知道授权组成员是谁。为了防止所有形式的窃听，除应答端点之外的实体不得访问会话密钥。
When key forking is not used, keys are accessible by everyone that can resolve the ticket. When key forking is used, some keys (MPKr and TGKs encoded in the ticket) are modified, making them cryptographically unique for each responder targeted by the forking. As only the Initiator and the KMS have access to the master TGKs, it is infeasible for anyone else to derive the session keys.
当不使用密钥分叉时，可以解决问题的每个人都可以访问密钥。当使用密钥分叉时，一些密钥（票据中编码的MPKr和TGK）会被修改，使它们在加密上对于分叉所针对的每个响应者都是唯一的。由于只有发起者和KMS可以访问主TGK，因此任何其他人都无法派生会话密钥。
When key forking is used, some keys (MPKi and TEKs and GTGK encoded in the ticket) are still accessible by everyone that can resolve the ticket and should be used with this in mind. This also concerns session keys transferred in a KEMAC in the first TRANSFER_INIT (as they are protected with MPKi).
当使用密钥分叉时，一些密钥（票证中编码的MPKi、TEK和GTGK）仍然可以被所有能够解析票证的人访问，并且应该记住这一点。这还涉及在第一次传输初始化时在KEMAC中传输的会话密钥（因为它们受MPKi保护）。
This protocol is resistant to denial-of-service attacks against the KMS in the sense that it does not construct any state (at the key management protocol level) before it has authenticated the Initiator or Responder. Since the Responder, in general, cannot verify the validity of a TRANSFER_INIT message without first contacting the KMS, denial of service may be launched against the Responder and/or the KMS via the Responder. Typical prevention methods such as rate-limiting and ACL (Access Control List) capability SHOULD therefore be implemented in the KMS as well as the clients. If something in the signaling is suspicious, the Responder SHOULD abort before attempting a RESOLVE_INIT with the KMS. The types and amount of prevention needed depends on how critical the system is and may vary depending on the Ticket Type.
该协议能够抵抗针对KMS的拒绝服务攻击，因为在对发起方或响应方进行身份验证之前，它不会构造任何状态（在密钥管理协议级别）。由于响应者通常无法在未首先联系KMS的情况下验证TRANSFER_INIT消息的有效性，因此可通过响应者针对响应者和/或KMS发起拒绝服务。因此，应在KMS和客户端中实施典型的预防方法，如速率限制和ACL（访问控制列表）功能。如果信号中有可疑内容，响应者应在尝试与KMS进行解析初始化之前中止。所需预防的类型和数量取决于系统的重要性，并且可能因票据类型而异。
In a replay attack, an attacker may intercept and later retransmit the whole or part of a MIKEY message, attempting to trick the receiver (Responder or KMS) into undesired operations, e.g., leading to a lack of key freshness. MIKEY-TICKET implements several mechanisms to prevent and detect such attacks. Timestamps together with a replay cache efficiently stop the replay of entire MIKEY messages. Parts of the received messages (or their hashes) can be saved in the replay cache until their timestamp is outdated. To prevent replay attacks, the sender's (Initiator or Responder) and the receiver's (Responder or KMS) identity is always (explicitly or implicitly) included in the MAC/Signature calculation.
在重播攻击中，攻击者可能会截获并稍后重新传输全部或部分MIKEY消息，试图诱使接收器（响应者或KMS）进行不希望的操作，例如，导致密钥不新鲜。MIKEY-TICKET实现了几种机制来防止和检测此类攻击。时间戳和重播缓存有效地阻止了整个MIKEY消息的重播。部分接收到的消息（或其散列）可以保存在replay缓存中，直到其时间戳过期。为了防止重播攻击，MAC/签名计算中始终（显式或隐式）包括发送方（发起方或响应方）和接收方（响应方或KMS）的标识。
An attacker may also attempt to replay a ticket by inserting it into a new MIKEY message. A possible scenario is that Alice and Bob first communicate based on a ticket, which an attacker Mallory intercepts. Later, Mallory (acting as herself) invites Bob by inserting the ticket into her own TRANSFER_INIT message. If key forking is used, such replays will always be detected when Bob has resolved the ticket. If key forking is not used, such replays will be detected unless Mallory has knowledge of the MPKi. And if Mallory has knowledge of the MPKi (i.e., she is authorized to resolve the ticket) and key forking is not used, there is no attack. For the reasons explained above, it is RECOMMENDED to use key forking.
攻击者还可能试图通过将票据插入新的MIKEY消息来重播票据。一种可能的情况是Alice和Bob首先基于一张票据进行通信，攻击者Mallory截获了该票据。后来，Mallory（扮演她自己）邀请Bob将票证插入她自己的TRANSFER_INIT消息中。如果使用了密钥分叉，当Bob解析票据时，将始终检测到此类回放。如果不使用密钥分叉，除非Mallory知道MPKi，否则将检测到此类回放。如果Mallory知道MPKi（即，她有权解决问题），并且没有使用密钥分叉，则不会发生攻击。出于上述原因，建议使用钥匙分叉。
In a group scenario, only authorized group members must have access to the keys. In some situation, the communication may be initiated by the Initiator using a group identity and the Initiator may not even know exactly who the authorized group members are. Moreover, group membership may change over time due to leaves/joins. In such a situation, it is foremost the responsibility of the KMS to reject ticket resolution requests from unauthorized responders, implying that the KMS needs to be able to map an individual's identity (carried in the RESOLVE_INIT message) to group membership (where the group identity is carried in the ticket).
在组方案中，只有授权的组成员才能访问密钥。在某些情况下，通信可由发起方使用组标识发起，并且发起方甚至可能不确切知道授权组成员是谁。此外，由于离开/加入，组成员资格可能会随着时间的推移而改变。在这种情况下，KMS的首要责任是拒绝来自未经授权响应者的票证解析请求，这意味着KMS需要能够将个人身份（包含在RESOLVE_INIT消息中）映射到组成员身份（其中组身份包含在票证中）。
As noted, reuse of tickets, which bypasses the KMS, is NOT RECOMMENDED when the Initiator is not fully ensured about group membership status.
如前所述，当启动器无法完全确保组成员身份状态时，不建议重用绕过KMS的票据。
The authors would like to thank Fredrik Ahlqvist, Rolf Blom, Yi Cheng, Lakshminath Dondeti, Vesa Lehtovirta, Fredrik Lindholm, Mats Naslund, Karl Norrman, Oscar Ohlsson, Brian Rosenberg, Bengt Sahlin, Wei Yinxing, and Zhu Yunwen for their support and valuable comments.
作者要感谢Fredrik Ahlqvist、Rolf Blom、Yi Cheng、Lakshminath Dondeti、Vesa Lehtovirta、Fredrik Lindholm、Mats Naslund、Karl Norrman、Oscar Ohlsson、Brian Rosenberg、Bengt Sahlin、Wei Yinxing和朱云文的支持和宝贵评论。
This document defines several new values for the namespaces Data Type, Next Payload, PRF func, CS ID map type, Encr alg, MAC alg, TS Type, ID Type, Hash func, Error no, and Key Data Type defined in [RFC3830]. The following IANA assignments were added to the MIKEY Payload registry (in parentheses is a reference to the table containing the registered values):
本文档为[RFC3830]中定义的名称空间数据类型、下一个有效负载、PRF func、CS ID映射类型、Encr alg、MAC alg、TS Type、ID Type、Hash func、错误号和密钥数据类型定义了几个新值。以下IANA分配已添加到MIKEY Payload注册表（括号中是对包含注册值的表的引用）：
o Data Type (see Table 6.1)
o 数据类型（见表6.1）
o Next Payload (see Table 6.2)
o 下一有效载荷（见表6.2）
o PRF func (see Table 6.3)
o PRF func（见表6.3）
o CS ID map type (see Table 6.4)
o CS ID地图类型（见表6.4）
o Encr alg (see Table 6.5)
o 附件alg（见表6.5）
o MAC alg (see Table 6.6)
o MAC alg（见表6.6）
o TS Type (see Table 6.7)
o TS类型（见表6.7）
o ID Type (see Table 6.9)
o ID类型（见表6.9）
o Hash func (see Table 6.11)
o 散列函数（见表6.11）
o Error no (see Table 6.13)
o 错误号（见表6.13）
o Key Data Type (see Table 6.14)
o 关键数据类型（见表6.14）
The TR payload defines an 8-bit TS Role field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of a TS Role name and its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are Reserved for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry are as follows:
TR有效负载定义了IANA为其创建的8位TS角色字段，并将在MIKEY有效负载注册表中维护一个新名称空间。分配由TS角色名称及其关联值组成。1-239范围内的值应通过所需的规范程序批准，240-254范围内的值保留供私人使用，0和255值根据[RFC5226]保留。登记处的初步内容如下：
Value TS Role
------- ------------------------------
0 Reserved
1 Time of issue (TRi)
2 Start of validity period (TRs)
3 End of validity period (TRe)
4 Rekeying interval (TRr)
5-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
Value TS Role
------- ------------------------------
0 Reserved
1 Time of issue (TRi)
2 Start of validity period (TRs)
3 End of validity period (TRe)
4 Rekeying interval (TRr)
5-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
The IDR payload defines an 8-bit ID Role field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of an ID Role name and its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are Reserved for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry are as follows:
IDR有效负载定义了IANA已为其创建的8位ID角色字段，并将在MIKEY有效负载注册表中维护一个新名称空间。分配由ID角色名称及其关联值组成。1-239范围内的值应通过所需的规范程序批准，240-254范围内的值保留供私人使用，0和255值根据[RFC5226]保留。登记处的初步内容如下：
Value ID Role
------- -----------------------
0 Reserved
1 Initiator (IDRi)
2 Responder (IDRr)
3 KMS (IDRkms)
4 Pre-Shared Key (IDRpsk)
5 Application (IDRapp)
6-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
Value ID Role
------- -----------------------
0 Reserved
1 Initiator (IDRi)
2 Responder (IDRr)
3 KMS (IDRkms)
4 Pre-Shared Key (IDRpsk)
5 Application (IDRapp)
6-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
The RANDR payload defines an 8-bit RAND Role field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of a RAND Role name and its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are Reserved for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry are as follows:
RANDR有效负载定义了IANA为其创建的8位RAND角色字段，并将在MIKEY有效负载注册表中维护一个新名称空间。分配由RAND角色名称及其关联值组成。1-239范围内的值应通过所需的规范程序批准，240-254范围内的值保留供私人使用，0和255值根据[RFC5226]保留。登记处的初步内容如下：
Value RAND Role
------- ------------------
0 Reserved
1 Initiator (RANDRi)
2 Responder (RANDRr)
3 KMS (RANDRkms)
4-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
Value RAND Role
------- ------------------
0 Reserved
1 Initiator (RANDRi)
2 Responder (RANDRr)
3 KMS (RANDRkms)
4-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
The TP/TICKET payload defines a 16-bit Ticket Type field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of a Ticket Type name and its associated value. Values in the range 1-61439 SHOULD be approved by the process of Specification Required, values in the range 61440- 65534 are Reserved for Private Use, and the values 0 and 65535 are Reserved according to [RFC5226]. The initial contents of the registry are as follows:
TP/TICKET有效负载定义了IANA为其创建的16位TICKET类型字段，并将在MIKEY有效负载注册表中维护一个新名称空间。分配由票证类型名称及其关联值组成。1-61439范围内的值应通过所需的规范流程批准，61440-65534范围内的值保留供私人使用，0和65535范围内的值根据[RFC5226]保留。登记处的初步内容如下：
Value Ticket Type
----------- -----------------
0 Reserved
1 MIKEY base ticket
2 3GPP base ticket
3-61439 Unassigned
61440-65534 Reserved for Private Use
65535 Reserved
Value Ticket Type
----------- -----------------
0 Reserved
1 MIKEY base ticket
2 3GPP base ticket
3-61439 Unassigned
61440-65534 Reserved for Private Use
65535 Reserved
[FIPS.180-3] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008, <http://csrc.nist.gov/publications/fips/ fips180-3/fips180-3_final.pdf>.
[FIPS.180-3]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-3，2008年10月<http://csrc.nist.gov/publications/fips/ fips180-3/fips180-3_final.pdf>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 4330，2006年1月。
[RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
[RFC4563]Carrara，E.，Lehtovirta，V.，和K.Norrman，“多媒体互联网键控（MIKEY）中通用扩展有效载荷的密钥ID信息类型”，RFC 4563，2006年6月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567]Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006.
[RFC4738]Ignjatic，D.，Dondeti，L.，Audet，F.，和P.Lin，“MIKEY-RSA-R：多媒体互联网密钥分配（MIKEY）中的另一种密钥分配模式”，RFC 4738，2006年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[3GPP.33.328] 3GPP, "IP Multimedia Subsystem (IMS) media plane security", 3GPP TS 33.328 9.3.0, December 2010.
[3GPP.33.328]3GPP，“IP多媒体子系统（IMS）媒体平面安全”，3GPP TS 33.328 9.3.012010年12月。
[Otway-Rees] Otway, D., and O. Rees, "Efficient and Timely Mutual Authentication", ACM SIGOPS Operating Systems Review v.21 n.1, p.8-10, January 1987.
[Otway-Rees]Otway，D.和O.Rees，“高效及时的相互认证”，ACM SIGOPS操作系统评论v.21 n.1，第8-10页，1987年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650]Euchner，M.“HMAC认证的Diffie Hellman多媒体互联网密钥（MIKEY）”，RFC 46502006年9月。
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions", RFC 5197, June 2008.
[RFC5197]Fries，S.和D.Ignjatic，“关于各种多媒体互联网键控（MIKEY）模式和扩展的适用性”，RFC 51972008年6月。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
[RFC5479]Wing，D.，Fries，S.，Tschofenig，H.，和F.Audet，“媒体安全管理协议的要求和分析”，RFC 5479，2009年4月。
The MIKEY base ticket MAY be used in any of the modes described in Section 4.1.1. The Ticket Data SHALL be constructed of MIKEY payloads and SHALL be protected by a MAC based on a pre-shared Ticket Protection Key (TPK). The parties that shares the TPK depends on the mode. Unexpected payloads in the Ticket Data SHOULD be ignored.
MIKEY基本票可用于第4.1.1节所述的任何模式。票证数据应由MIKEY有效载荷构成，并由基于预共享票证保护密钥（TPK）的MAC进行保护。共享TPK的各方取决于模式。应忽略票证数据中意外的有效载荷。
Ticket Data = THDR, T, RAND, KEMAC, [IDRpsk], V
票证数据=泰铢、泰铢、兰特、凯末克、[IDRpsk]，伏
The Ticket Data MUST always begin with a Ticket Header payload (THDR). The ticket header is a new payload type; for the definition, see Appendix A.3.
票据数据必须始终以票据头有效载荷（THDR）开始。票据头是一种新的有效载荷类型；有关定义，请参见附录A.3。
T is a timestamp containing the time of issue or a counter. It MAY be used in the IV (Initialization Vector) formation (e.g., Section 4.2.3 of [RFC3830]).
T是包含发出时间或计数器的时间戳。它可用于IV（初始化向量）形成（例如，[RFC3830]第4.2.3节）。
RAND is used as input to the key derivation function when keys are derived from the TPK and the MPK (see Appendices A.2.1 and A.2.2).
从TPK和MPK中导出密钥时，RAND用作密钥导出函数的输入（见附录A.2.1和A.2.2）。
The KEMAC payload SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. The encryption key (encr_key) and salting key (salt_key) SHALL be derived from the TPK (see Appendix A.2.1). Depending on the encryption algorithm, the salting key be used in the IV creation (see Section 4.2.3 of [RFC3830]). If CSB ID is needed in the IV creation it SHALL be set to '0xFFFFFFFF'. The KEMAC is hence constructed as follows:
KEMAC有效载荷应使用空认证算法，因为MAC包含在V有效载荷中。加密密钥（encr_密钥）和加密密钥（salt_密钥）应来自TPK（见附录A.2.1）。根据加密算法，可以在IV创建中使用salting密钥（参见[RFC3830]第4.2.3节）。如果IV创建中需要CSB ID，则应将其设置为“0xFFFFFF”。因此，KEMAC的结构如下：
KEMAC = E(encr_key, MPK || {TEK|TGK|GTGK})
KEMAC = E(encr_key, MPK || {TEK|TGK|GTGK})
MPKi and MPKr are derived from the MPK as defined in Appendix A.2.2.
MPKi和MPKr源自附录A.2.2中定义的MPK。
IDRpsk contains an identifier that enables the KMS/Responder to retrieve the TPK. It MAY be omitted when the TPK can be retrieved anyhow.
IDRpsk包含一个标识符，使KMS/响应程序能够检索TPK。当无论如何都可以检索TPK时，可以省略它。
The last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from the TPK. The MAC SHALL be calculated over the entire TICKET payload except the Next Payload field (in the TICKET payload), the Initiator Data length field, the Initiator Data field, and the MAC field itself.
最后一个有效载荷应为验证有效载荷（V），其中认证密钥（auth_密钥）来自TPK。除了下一个有效载荷字段（在票据有效载荷中）、启动器数据长度字段、启动器数据字段和MAC字段本身之外，应在整个票据有效载荷上计算MAC。
The labels in the key derivations SHALL NOT include entire RAND payloads, only the fields RAND length and RAND from the corresponding payload.
关键衍生产品中的标签不应包括整个RAND有效载荷，仅包括对应有效载荷的RAND length和RAND字段。
In the following, we describe how keying material is derived from a TPK. The key derivation method SHALL be executed using the PRF indicated in the Ticket Policy. The parameters for the PRF are:
在下文中，我们将介绍如何从TPK派生键控材料。密钥推导方法应使用票证政策中指示的PRF执行。PRF的参数包括：
inkey: : TPK inkey_len : bit length of the inkey label : constant || 0xFF || 0xFFFFFFFF || 0x05 || length RAND || RAND outkey_len : desired bit length of the outkey (encr_key, auth_key, salt_key)
inkey:：TPK inkey|len:inkey标签的位长度：常量| | 0xFF | | 0xFFFFFF | | 0x05 | |长度RAND | | RAND outkey| len:outkey的所需位长度（encr|u键、auth|u键、salt|键）
Length RAND is the length of RAND in bytes as an 8-bit unsigned integer. The constants are as defined in Section 4.1.4 of [RFC3830]. The key derivation and its dependencies on Ticket Data contents when AES-CM is used are illustrated in Figure 10. The key derivation is done by the party that creates the ticket (KMS or Initiator) and by the party that resolves the ticket (KMS or Responder). The encryption key and the IV are used to encrypt the KEMAC.
Length RAND是RAND的长度，以字节为单位，为8位无符号整数。常数定义见[RFC3830]第4.1.4节。使用AES-CM时，密钥派生及其对票据数据内容的依赖关系如图10所示。密钥派生由创建票证的一方（KMS或发起方）和解析票证的一方（KMS或响应方）完成。加密密钥和IV用于加密KEMAC。
----- auth_key ------
----- TPK | |----------------------->| AUTH |
| TPK |----------->| | encr_key ------
----- | PRF |--------------------+ |
^ +-->| | salt_key | |
: | | |----------------+ | |
: | ----- | | |
: | v | |
identify : RAND | TS value ---- | | MAC
: | +------------>| IV | | |
: | | ---- | |
: | | IV | | |
: | | v v v
Ticket +---+----+---+--+---+---+-+-+------------+-------+---+---+
Data | IDRpsk |...| RAND |...| T |............| KEMAC |...| V |
+--------+---+------+---+---+------------+-------+---+---+
----- auth_key ------
----- TPK | |----------------------->| AUTH |
| TPK |----------->| | encr_key ------
----- | PRF |--------------------+ |
^ +-->| | salt_key | |
: | | |----------------+ | |
: | ----- | | |
: | v | |
identify : RAND | TS value ---- | | MAC
: | +------------>| IV | | |
: | | ---- | |
: | | IV | | |
: | | v v v
Ticket +---+----+---+--+---+---+-+-+------------+-------+---+---+
Data | IDRpsk |...| RAND |...| T |............| KEMAC |...| V |
+--------+---+------+---+---+------------+-------+---+---+
Figure 10: Deriving keys from a TPK
图10：从TPK派生键
In the following, we describe how MPKi and MPKr are derived from the MPK in the KEMAC payload. The key derivation method SHALL be executed using the PRF indicated in the Ticket Policy. The parameters for the PRF are:
在下文中，我们将介绍如何从KEMAC有效载荷中的MPK推导MPKi和MPKr。密钥推导方法应使用票证政策中指示的PRF执行。PRF的参数包括：
inkey: : MPK inkey_len : bit length of the inkey label : constant || 0xFF || 0xFFFFFFFF || 0x06 || length RAND || RAND outkey_len : desired bit length of the outkey (MPKi, MPKr) SHALL be equal to inkey_len
inkey:：MPK inkey|len:inkey标签的位长度：常量| | 0xFF | | 0xFFFFFF | | 0x06 | |长度RAND | | RAND outkey| len:outkey（MPKi，MPKr）的所需位长度应等于inkey|len
Length RAND is the length of RAND in bytes as an 8-bit unsigned integer. The constant depends on the derived key type as summarized below.
Length RAND是RAND的长度，以字节为单位，为8位无符号整数。该常数取决于派生键类型，如下所述。
Derived key | Constant
------------+-----------
MPKi | 0x220E99A2
MPKr | 0x1F4D675B
Derived key | Constant
------------+-----------
MPKi | 0x220E99A2
MPKr | 0x1F4D675B
Table A.1: Constants for MPK key derivation
表A.1:MPK密钥推导常数
The constants are taken from the decimal digits of e as described in [RFC3830].
常数取自[RFC3830]中所述的e的十进制数字。
The ticket header payload contains an indicator of the next payload as well as implementation-specific data.
票据头有效负载包含下一个有效负载的指示器以及特定于实现的数据。
0 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 ! THDR Data length ! THDR Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 ! THDR Data length ! THDR Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Payload (8 bits): identifies the payload that is added after this payload.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
* THDR Data length (16 bits): the length of the THDR Data field (in bytes).
* THDR数据长度（16位）：THDR数据字段的长度（字节）。
* THDR Data (variable length): implementation specific data that SHOULD be ignored if it is not expected.
* THDR数据（可变长度）：特定于实现的数据，如果不需要，则应忽略这些数据。
MIKEY-TICKET can be used to define a Ticket Type compatible with [RFC3830] or any other half-round-trip key management protocol. The Initiator requests and gets a ticket from the KMS where the Ticket Data is a [RFC3830] message protected with a pre-shared key (KMS-Responder) or with the Responder's certificate. The Ticket Data is then sent to the Responder according to [RFC3830]. In this way, the Initiator can communicate with a Responder that only supports [RFC3830] and with whom the Initiator do not have any shared credentials.
MIKEY-TICKET可用于定义与[RFC3830]或任何其他半往返密钥管理协议兼容的票据类型。发起方从KMS请求并获取票证，其中票证数据是受预共享密钥（KMS响应方）或响应方证书保护的[RFC3830]消息。然后根据[RFC3830]将票据数据发送给响应者。通过这种方式，发起方可以与仅支持[RFC3830]且发起方没有任何共享凭据的响应方通信。
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
REQUEST_INIT
-------------------------------->
REQUEST_RESP
<--------------------------------
3830 MIKEY
---------------------------------------------------------------->
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
REQUEST_INIT
-------------------------------->
REQUEST_RESP
<--------------------------------
3830 MIKEY
---------------------------------------------------------------->
Figure 11: Compatibility mode
图11：兼容性模式
Authors' Addresses
作者地址
John Mattsson Ericsson AB SE-164 80 Stockholm Sweden
John Mattsson Ericsson AB SE-164 80瑞典斯德哥尔摩
Phone: +46 10 71 43 501
EMail: john.mattsson@ericsson.com
Phone: +46 10 71 43 501
EMail: john.mattsson@ericsson.com
Tian Tian ZTE Corporation 4F, RD Building 2, Zijinghua Road Yuhuatai District, Nanjing 210012 P.R. China
中国南京市雨花台区紫荆华路2号路4楼中兴通讯股份有限公司210012
Phone: +86-025-5287-7867
EMail: tian.tian1@zte.com.cn
Phone: +86-025-5287-7867
EMail: tian.tian1@zte.com.cn