Internet Engineering Task Force (IETF) M. Groves
Request for Comments: 6509 CESG
Category: Informational February 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Groves
Request for Comments: 6509 CESG
Category: Informational February 2012
ISSN: 2070-1721
MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)
MIKEY-SAKKE:Sakai Kasahara多媒体互联网密钥加密（MIKEY）
Abstract
摘要
This document describes the Multimedia Internet KEYing-Sakai-Kasahara Key Encryption (MIKEY-SAKKE), a method of key exchange that uses Identity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication. MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery.
本文档描述了多媒体互联网密钥Sakai Kasahara密钥加密（MIKEY-SAKKE），这是一种密钥交换方法，使用基于身份的公钥加密（IDPKC）建立共享密钥值和无证书签名以提供源身份验证。MIKEY-SAKKE具有许多理想的功能，包括单工传输、可扩展性、低延迟呼叫设置以及对安全延迟交付的支持。
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 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）的产品。互联网工程指导小组（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/rfc6509.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6509.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................3
1.1. Requirements Terminology ...................................3
2. A New MIKEY Mode: MIKEY-SAKKE ...................................4
2.1. Outline ....................................................4
2.1.1. Parameters ..........................................5
2.1.2. Key Types ...........................................5
2.2. Preparing and Processing MIKEY-SAKKE Messages ..............6
2.2.1. Components of the I_MESSAGE .........................6
2.2.2. Processing the I_MESSAGE ............................7
2.3. Forking and Retargeting ....................................8
2.4. Group Communications .......................................9
2.5. Deferred Delivery ..........................................9
3. Key Management ..................................................9
3.1. Generating Keys from the Shared Secret Value ...............9
3.2. Identifiers ...............................................10
3.3. Key Longevity and Update ..................................11
3.4. Key Delivery ..............................................12
4. Payload Encoding ...............................................12
4.1. Common Header Payload (HDR) ...............................12
4.2. SAKKE Payload .............................................13
4.3. SIGN Payload ..............................................14
4.4. IDR Payload ...............................................14
5. Applicability of MIKEY-SAKKE Mode ..............................14
6. Security Considerations ........................................14
6.1. Forking ...................................................15
6.2. Retargeting ...............................................16
6.3. Group Calls ...............................................16
6.4. Deferred Delivery .........................................16
7. IANA Considerations ............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
Appendix A. Parameters for Use in MIKEY-SAKKE......................20
1. Introduction ....................................................3
1.1. Requirements Terminology ...................................3
2. A New MIKEY Mode: MIKEY-SAKKE ...................................4
2.1. Outline ....................................................4
2.1.1. Parameters ..........................................5
2.1.2. Key Types ...........................................5
2.2. Preparing and Processing MIKEY-SAKKE Messages ..............6
2.2.1. Components of the I_MESSAGE .........................6
2.2.2. Processing the I_MESSAGE ............................7
2.3. Forking and Retargeting ....................................8
2.4. Group Communications .......................................9
2.5. Deferred Delivery ..........................................9
3. Key Management ..................................................9
3.1. Generating Keys from the Shared Secret Value ...............9
3.2. Identifiers ...............................................10
3.3. Key Longevity and Update ..................................11
3.4. Key Delivery ..............................................12
4. Payload Encoding ...............................................12
4.1. Common Header Payload (HDR) ...............................12
4.2. SAKKE Payload .............................................13
4.3. SIGN Payload ..............................................14
4.4. IDR Payload ...............................................14
5. Applicability of MIKEY-SAKKE Mode ..............................14
6. Security Considerations ........................................14
6.1. Forking ...................................................15
6.2. Retargeting ...............................................16
6.3. Group Calls ...............................................16
6.4. Deferred Delivery .........................................16
7. IANA Considerations ............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
Appendix A. Parameters for Use in MIKEY-SAKKE......................20
Multimedia Internet KEYing (MIKEY) [RFC3830] defines a protocol framework for key distribution and specifies key distribution methods using pre-shared keys, RSA, and, optionally, a Diffie-Hellman Key Exchange. Since the original specification, several alternative key distribution methods for MIKEY have been proposed such as [RFC4650], [RFC4738], [RFC6043], and [RFC6267].
多媒体互联网密钥（MIKEY）[RFC3830]定义了密钥分发的协议框架，并指定了使用预共享密钥、RSA和Diffie-Hellman密钥交换（可选）的密钥分发方法。自最初的规范以来，已经提出了几种用于MIKEY的备选密钥分配方法，如[RFC4650]、[RFC4738]、[RFC6043]和[RFC6267]。
This document describes MIKEY-SAKKE, a method for key exchange and source authentication designed for use in IP Multimedia Subsystem (IMS) [3GPP.33.328] Media Plane Security, but with potential for wider applicability. This scheme makes use of a Key Management Service (KMS) as a root of trust and distributor of key material. The KMS provides users with assurance of the authenticity of the peers with which they communicate. Unlike traditional key distribution systems, MIKEY-SAKKE does not require the KMS to offer high availability. Rather, it need only distribute new keys to its users periodically.
本文档描述了MIKEY-SAKKE，一种用于密钥交换和源认证的方法，设计用于IP多媒体子系统（IMS）[3GPP.33.328]媒体平面安全，但具有更广泛的适用性。该方案利用密钥管理服务（KMS）作为信任的根和密钥材料的分发者。KMS为用户提供了与之通信的对等方的真实性保证。与传统的密钥分发系统不同，MIKEY-SAKKE不要求KMS提供高可用性。相反，它只需要定期向用户分发新密钥。
MIKEY-SAKKE consists of an Identity-based Public Key Cryptography (IDPKC) scheme based on that of Sakai and Kasahara [S-K], and a source authentication algorithm that is tailored to use Identifiers instead of certificates. The algorithms behind this protocol are described in [RFC6507] and [RFC6508].
MIKEY-SAKKE包括一个基于身份的公钥加密（IDPKC）方案，该方案基于Sakai和Kasahara[S-K]的方案，以及一个源认证算法，该算法专门用于使用标识符而不是证书。[RFC6507]和[RFC6508]中描述了该协议背后的算法。
The primary motivation for the MIKEY protocol design is the low-latency requirement of real-time communication; hence, many of the defined exchanges finish in one-half to one roundtrip. However, some exchanges, such as those described in [RFC6043] and [RFC6267], have been proposed that extend the latency of the protocol with the intent of providing additional security. MIKEY-SAKKE affords similarly enhanced security, but requires only a single simplex transmission (one-half roundtrip).
MIKEY协议设计的主要动机是实时通信的低延迟要求；因此，许多已定义的交换在一个半对一的往返中完成。然而，已经提出了一些交换，例如[RFC6043]和[RFC6267]中描述的交换，它们延长了协议的延迟，以提供额外的安全性。MIKEY-SAKKE提供了类似的增强安全性，但只需要一个单工传输（半往返）。
MIKEY-SAKKE additionally offers support for scenarios such as forking, retargeting, deferred delivery, and pre-encoded content.
MIKEY-SAKKE还提供对分叉、重定目标、延迟交付和预编码内容等场景的支持。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The proposed MIKEY mode requires a single simplex transmission. The Initiator sends a MIKEY I_MESSAGE containing SAKKE Encapsulated Data and a signature to the intended recipient. The Responder MUST validate the signature. Following signature validation, the Responder processes the Encapsulated Data according to the operations defined in [RFC6508] to derive a Shared Secret Value (SSV). This SSV is used as the TGK (the TEK Generation Key defined in [RFC3830]).
建议的MIKEY模式需要单个单工传输。发起者向目标接收者发送包含SAKKE封装数据和签名的MIKEY I_消息。响应者必须验证签名。签名验证之后，响应者根据[RFC6508]中定义的操作处理封装的数据，以导出共享秘密值（SSV）。该SSV用作TGK（在[RFC3830]中定义的TEK生成密钥）。
A verification message from the Responder (as in pre-shared key mode, for example) is not needed, as the parties are mutually authenticated following processing of the single I_MESSAGE. The notation used for MIKEY messages and their payloads in Figure 1, and in the rest of this document, is defined in [RFC3830].
不需要来自响应者的验证消息（例如，在预共享密钥模式下），因为各方在处理单个I_消息之后相互认证。图1和本文档其余部分中用于MIKEY消息及其有效负载的符号在[RFC3830]中定义。
Initiator Responder
发起者响应者
I_MESSAGE =
HDR, T, RAND, [IDRi], [IDRr], [IDRkmsi], [IDRkmsr],
[CERT], {SP}, SAKKE, SIGN --->
I_MESSAGE =
HDR, T, RAND, [IDRi], [IDRr], [IDRkmsi], [IDRkmsr],
[CERT], {SP}, SAKKE, SIGN --->
Figure 1: MIKEY-SAKKE Unicast Mode
图1:MIKEY-SAKKE单播模式
The Initiator wants to establish a secure media session with the Responder. The Initiator and the Responder trust a third party, the KMS, which provisions them with key material by a secure mechanism. In addition to the public and secret keys corresponding to their Identifier, the KMS MUST provision devices with its KMS Public Key and, where [RFC6507] is used, its KMS Public Authentication Key. A description of all key material used in MIKEY-SAKKE can be found in Section 2.1.2. The Initiator and the Responder do not share any credentials; instead, the Initiator is able to derive the Responder's public Identifier.
发起方希望与响应方建立安全的媒体会话。发起者和响应者信任第三方KMS，KMS通过安全机制向他们提供关键材料。除了与其标识符相对应的公钥和密钥外，KMS还必须为设备提供其KMS公钥，并且在使用[RFC6507]的情况下，还必须提供其KMS公钥认证密钥。有关MIKEY-SAKKE中使用的所有关键材料的说明，请参见第2.1.2节。发起方和响应方不共享任何凭据；相反，发起方能够派生响应方的公共标识符。
Implementations MAY provide support for multiple KMSs. In this case, rather than a single KMS, several different KMSs could be involved, e.g., one for the Initiator and one for the Responder. To allow this, each interoperating KMS MUST provide its users with the KMS public keys for every KMS subscriber domain with which its users communicate. It is not anticipated that large mutually communicating groups of KMSs will be needed, as each KMS only needs to provide its domain of devices with key material once per key period (see Section 3.3) rather than to be active in each call.
实现可以提供对多个KMS的支持。在这种情况下，可能涉及多个不同的KMS，而不是单个KMS，例如，一个用于发起方，另一个用于响应方。为了实现这一点，每个互操作KMS必须为其用户提供其用户与之通信的每个KMS订户域的KMS公钥。预计不会需要大型相互通信的KMS组，因为每个KMS只需要在每个关键时段（见第3.3节）向其设备域提供一次关键材料，而不是在每次呼叫中都处于活动状态。
As MIKEY-SAKKE is based on [RFC3830], the same terminology, processing, and considerations still apply unless otherwise stated. Following [RFC3830], messages are integrity protected and encryption is not applied to entire messages.
由于MIKEY-SAKKE基于[RFC3830]，除非另有说明，否则相同的术语、处理和注意事项仍然适用。[RFC3830]之后，消息受完整性保护，加密不应用于整个消息。
[RFC6508] requires each application to define the set of public parameters to be used by implementations. The parameters in Appendix A SHOULD be used in MIKEY-SAKKE; alternative parameters MAY be subsequently defined; see Section 4.2.
[RFC6508]要求每个应用程序定义实现使用的公共参数集。附录A中的参数应在MIKEY-SAKKE中使用；可随后定义替代参数；见第4.2节。
[RFC6507] requires each application to define the hash function and various other parameters to be used (see Section 4.1 of [RFC6507]). For MIKEY-SAKKE, the P-256 elliptic curve and base point [FIPS186-3] and SHA-256 [FIPS180-3] MUST be used.
[RFC6507]要求每个应用程序定义要使用的哈希函数和各种其他参数（见[RFC6507]第4.1节）。对于MIKEY-SAKKE，必须使用P-256椭圆曲线和基点[FIPS186-3]以及SHA-256[FIPS180-3]。
Users require keys for [RFC6508] and to sign messages. These keys MUST be provided by the users' KMS. It is RECOMMENDED that implementations support the scheme for signatures described in [RFC6507]. Alternatively, RSA signing as defined in [RFC3830] MAY be used.
用户需要[RFC6508]和签名消息的密钥。这些密钥必须由用户的KMS提供。建议实现支持[RFC6507]中描述的签名方案。或者，可以使用[RFC3830]中定义的RSA签名。
SAKKE keys
萨克钥匙
SAKKE requires each user to have a Receiver Secret Key, created by the KMS, and the KMS Public Key. For systems that support multiple KMSs, each user also requires the KMS Public Key of every KMS subscriber domain with which communication is authorized.
SAKKE要求每个用户拥有由KMS创建的接收方密钥和KMS公钥。对于支持多个KMS的系统，每个用户还需要授权通信的每个KMS用户域的KMS公钥。
ECCSI keys
ECCSI密钥
If the Elliptic Curve-based Certificateless Signatures for Identity-based Encryption (ECCSI) signatures are used, each user requires a Secret Signing Key and Public Validation Token, created by the KMS, and the KMS Public Authentication Key. For systems that support multiple KMSs, each user also requires the KMS Public Authentication Key of every KMS subscriber domain with which communication is authorized.
如果使用基于身份加密（ECCSI）签名的基于椭圆曲线的无证书签名，则每个用户都需要KMS创建的秘密签名密钥和公共验证令牌，以及KMS公共身份验证密钥。对于支持多个KMS的系统，每个用户还需要授权通信的每个KMS用户域的KMS公共身份验证密钥。
If instead RSA signatures are to be used, certificates and corresponding private keys MUST be supplied.
如果要使用RSA签名，则必须提供证书和相应的私钥。
Preparation and parsing of MIKEY messages are as described in Sections 5.2 and 5.3 of [RFC3830]. Error handling is described in Section 5.1.2, and replay protection guidelines are in Section 5.4 of [RFC3830]. In the following, we describe the components of MIKEY-SAKKE messages and specify message processing and parsing rules in addition to those in [RFC3830].
MIKEY消息的准备和解析如[RFC3830]第5.2节和第5.3节所述。错误处理在第5.1.2节中有描述，重播保护指南在[RFC3830]的第5.4节中有描述。在下文中，我们将描述MIKEY-SAKKE消息的组件，并指定除[RFC3830]中的组件外的消息处理和解析规则。
MIKEY-SAKKE requires a single simplex transmission (a half roundtrip) to establish a shared TGK. The I_MESSAGE MUST contain the MIKEY Common Header Payload HDR defined in [RFC6043] together with the timestamp payload in order to provide replay protection. The HDR field contains a CSB_ID (Crypto Session Bundle ID) randomly selected by the Initiator. The V bit in the HDR payload MUST be set to '0' and ignored by the Responder, as a response is not expected in this mode. The timestamp payload MUST use TS type NTP-UTC (TS type 0) or NTP (TS type 1) as defined in Section 6.6 of [RFC3830] so that the Responder can determine the Identifiers used by the Initiator (see Section 3.2). It is RECOMMENDED that the time always be specified in UTC.
MIKEY-SAKKE需要一个单工传输（半往返）来建立共享TGK。I_消息必须包含[RFC6043]中定义的MIKEY公共报头有效载荷HDR以及时间戳有效载荷，以便提供重播保护。HDR字段包含启动器随机选择的CSB_ID（加密会话束ID）。HDR有效负载中的V位必须设置为“0”，并由响应程序忽略，因为在此模式下不需要响应。时间戳有效负载必须使用[RFC3830]第6.6节中定义的TS类型NTP-UTC（TS类型0）或NTP（TS类型1），以便响应者可以确定启动器使用的标识符（参见第3.2节）。建议始终以UTC为单位指定时间。
The I_MESSAGE MUST be signed by the Initiator following either the procedure to sign MIKEY messages specified in [RFC3830], or using [RFC6507] as specified in this document. The SIGN payload contains this signature. Thus, the I_MESSAGE is integrity and replay protected. The ECCSI signature scheme [RFC6507] SHOULD be used. If this signature scheme is used, then the Initiator MUST NOT include a CERT payload. To form this signature type, the Initiator requires a Secret Signing Key that is provided by the KMS.
发起者必须按照[RFC3830]中规定的对MIKEY消息进行签名的过程或使用本文档中规定的[RFC6507]对I_消息进行签名。符号有效负载包含此签名。因此，I_消息具有完整性和重播保护。应使用ECCSI签名方案[RFC6507]。如果使用此签名方案，则启动器不得包含证书有效负载。要形成此签名类型，启动器需要KMS提供的秘密签名密钥。
Other signature types defined for use with MIKEY MAY be used. If signature types 0 or 1 (RSA) are used, then the Initiator SHOULD include a CERT payload; in this case, the CERT payload MAY be left out if it is expected that the Responder is able to obtain the certificate in some other manner. If a CERT payload is included, it MUST correspond to the private key used to sign the I_MESSAGE.
可以使用为MIKEY定义的其他签名类型。如果使用签名类型0或1（RSA），则启动器应包括证书有效负载；在这种情况下，如果期望响应者能够以某种其他方式获得证书，则证书有效载荷可能被忽略。如果包含证书有效负载，则它必须与用于签名I_消息的私钥相对应。
The Initiator MUST include a RAND payload in the I_MESSAGE, as this is used to derive session keys.
启动器必须在I_消息中包含RAND有效负载，因为这用于派生会话密钥。
The identities of the Initiator, Responder, the Initiator's KMS (root of trust for authentication of the Initiator), and the Responder's KMS (root of trust for authentication of the Responder) MAY be contained in the IDRi, IDRr, IDRkmsi, and IDRkmsr I_MESSAGEs, respectively. The ID Payload with Role Indicator (IDR) is defined in
发起方、响应方、发起方的KMS（发起方身份验证的信任根）和响应方的KMS（响应方身份验证的信任根）的标识可分别包含在IDRi、IDRr、IDRkmsi和IDRkmsr I_消息中。中定义了具有角色指示器（IDR）的ID有效负载
[RFC6043] and modified in Section 4.4. When used, this payload provides the Identifier for any of the Initiator, the Responder, and their respective KMSs.
[RFC6043]并在第4.4节中进行了修改。使用时，此有效负载为任何启动器、响应程序及其各自的KMS提供标识符。
The ID Role MUST be the Initiator (value 1) for the IDRi payload and Responder (value 2) for the IDRr payload. The Initiator's ID is used to validate signatures [RFC6507]. If included, the IDRi payload MUST contain the URI of the Initiator incorporated in the Identifier used to sign the I_MESSAGE (see Section 3.2). If included, the IDRr payload MUST contain the URI of the Responder incorporated in the Identifier that the Initiator used in SAKKE (see Section 3.2). If included, the ID Role MUST be the Initiator's KMS (value 6) for the IDRkmsi payload and Responder's KMS (value 7) for the IDRkmsr payload and MUST correspond to the KMS used as root of trust for the signature (for the IDRkmsi payload) and the KMS used as the root of trust for the SAKKE key exchange (for the IDRkmsr payload).
ID角色必须是IDRi有效负载的发起方（值1）和IDRr有效负载的响应方（值2）。启动器的ID用于验证签名[RFC6507]。如果包括，IDRi有效负载必须包含用于签署I_消息的标识符中包含的启动器的URI（参见第3.2节）。如果包括，IDRr有效负载必须包含响应者的URI，该URI包含在发起人在SAKKE中使用的标识符中（见第3.2节）。如果包括，ID角色必须是IDRkmsi有效负载的发起方KMS（值6）和IDRkmsr有效负载的响应方KMS（值7），并且必须对应于用作签名信任根的KMS（用于IDRkmsi有效负载）和用作SAKKE密钥交换信任根的KMS（用于IDRkmsr有效负载）。
It is OPTIONAL to include any IDR payloads, as in some user groups Identifiers could be inferred by other means, e.g., through the signaling used to establish a call. Furthermore, a closed user group could rely on only one KMS, whose identity will be understood and need not be included in the signaling.
包括任何IDR有效载荷是可选的，因为在一些用户组中，标识符可以通过其他方式推断，例如，通过用于建立呼叫的信令。此外，封闭用户组可以仅依赖于一个KMS，其身份将被理解并且不需要包括在信令中。
The I_MESSAGE MUST contain a SAKKE payload constructed as defined in Section 4.2.
I_消息必须包含按照第4.2节定义构造的SAKKE有效载荷。
The Initiator MAY also send security policy (SP) payload(s) containing all the security policies that it supports. If the Responder does not support any of the policies included, it SHOULD reply with an error message of type "Invalid SPpar" (Error no. 10). The Responder has the option not to send the error message in MIKEY if a generic session establishment failure indication is deemed appropriate and communicated via other means (see Section 4.1.2 of [RFC4567] for additional guidance).
启动器还可以发送包含其支持的所有安全策略的安全策略（SP）有效负载。如果响应程序不支持包含的任何策略，则应使用类型为“Invalid SPpar”的错误消息（错误号10）进行响应。如果通用会话建立失败指示被认为是合适的，并且通过其他方式进行通信，则响应者可以选择不发送MIKEY中的错误消息（更多指南，请参见[RFC4567]第4.1.2节）。
The Responder MUST process the I_MESSAGE according to the rules specified in Section 5.3 of [RFC3830]. The following additional processing MUST also be applied.
响应者必须根据[RFC3830]第5.3节规定的规则处理I_消息。还必须应用以下附加处理。
* If the Responder does not support the MIKEY-SAKKE mode of operation, or otherwise cannot correctly parse the received MIKEY message, then it SHOULD send an error message "Unsupported message type" (Error no. 13). Error no. 13 is not defined in [RFC3830], and so implementations compliant with [RFC3830] MAY return an "Unspecified error" (Error no. 12).
* 如果响应者不支持MIKEY-SAKKE操作模式，或者无法正确解析收到的MIKEY消息，则应发送错误消息“不支持的消息类型”（错误号13）。[RFC3830]中未定义错误编号13，因此符合[RFC3830]的实现可能会返回“未指定错误”（错误编号12）。
* The Responder MAY compare the IDi payload against his local policy to determine whether he wishes to establish secure communications from the Initiator. If the Responder's policy does not allow this communication, then the Responder MAY respond with an "Auth failure" error (Error no. 0).
* 响应者可以将IDi有效载荷与其本地策略进行比较，以确定他是否希望建立来自发起方的安全通信。如果响应者的策略不允许此通信，则响应者可能会响应“身份验证失败”错误（错误号0）。
* If the Responder supports MIKEY-SAKKE and has determined that it wishes to establish secure communications with the Initiator, then it MUST verify the signature according to the method described in Section 5.2.2 of [RFC6507] if it is of type 2, or according to the certificate used if a signature of type 0 or 1 is used. If the verification of the signature fails, then an "Auth failure" error (Error no. 0) MAY be sent to the Initiator.
* 如果响应方支持MIKEY-SAKKE，并确定其希望与发起方建立安全通信，则必须根据[RFC6507]第5.2.2节中描述的方法验证签名（如果签名类型为2），或者根据使用的证书验证签名（如果签名类型为0或1）。如果签名验证失败，则可能会向启动器发送“身份验证失败”错误（错误号0）。
* If the authentication is successful, then the Responder SHALL process the SAKKE payload and derive the SSV according to the method described in [RFC6508].
* 如果认证成功，则响应者应处理SAKKE有效载荷，并根据[RFC6508]中描述的方法推导SSV。
Where forking is to be supported, Receiver Secret Keys can be held by multiple devices. To facilitate this, the Responder needs to load his Receiver Secret Key into each of his devices that he wishes to receive MIKEY-SAKKE communications. If forking occurs, each of these devices can then process the SAKKE payload, and each can verify the Identifier of the Initiator as they hold the KMS Public Authentication Key. Therefore, the traffic keys could be derived by any of these devices. However, this is the case for any scheme employing simplex transmission, and it is considered that the advantages of this type of scheme are significant for many users. Furthermore, it is for the owner of the Identifier to determine on which devices to allow his Receiver Secret Key to be loaded. Thus, it is anticipated that he would have control over all devices that hold his Receiver Secret Key. This argument also applies to applications such as call centers, in which the security relationship is typically between the call center and the individual calling the center, rather than the particular operative who receives the call.
在支持分叉的情况下，接收器密钥可以由多个设备持有。为了方便这一点，响应者需要将其接收器密钥加载到他希望接收MIKEY-SAKKE通信的每个设备中。如果发生分叉，这些设备中的每一个都可以处理SAKKE负载，并且每个设备都可以在持有KMS公共身份验证密钥时验证启动器的标识符。因此，这些设备中的任何一个都可以导出流量密钥。然而，对于采用单工传输的任何方案都是如此，并且认为这种方案的优点对于许多用户来说是显著的。此外，由标识符的所有者确定允许在哪些设备上加载其接收器密钥。因此，预计他将控制持有其接收器密钥的所有设备。此论点也适用于呼叫中心等应用程序，其中安全关系通常在呼叫中心和呼叫中心的个人之间，而不是接收呼叫的特定操作员之间。
Devices holding the same Receiver Secret Key ought to each hold a different Secret Signing Key corresponding to the same Identifier. This is possible because the Elliptic Curve-based Certificateless Signatures for Identity-based Encryption (ECCSI) scheme allows multiple keys to be generated by KMS for the same Identifier.
持有相同接收方密钥的设备应各自持有对应于相同标识符的不同秘密签名密钥。这是可能的，因为基于椭圆曲线的基于身份加密的无证书签名（ECCSI）方案允许KMS为同一标识符生成多个密钥。
Secure retargeted calls can only be established in the situation where the Initiator is aware of the Identifier of the device to whom the call is being retargeted; in this case, the Initiator ought to initiate a new MIKEY-SAKKE session with the device to whom it has
安全重定目标呼叫只能在发起方知道呼叫重定目标的设备的标识符的情况下建立；在这种情况下，发起者应该启动一个新的MIKEY-SAKKE会话，与它所连接的设备进行会话
been retargeted (if willing to do so). Retargeting an Initiator's call to another device (with a different Identifier) is to be viewed as insecure when the Initiator is unaware that this has occurred, as this prevents authentication of the Responder.
已重新确定目标（如果愿意）。当发起者不知道发生了这种情况时，将发起者的呼叫重新定位到另一个设备（具有不同标识符）将被视为不安全的，因为这会阻止响应者的身份验证。
SAKKE supports key establishment for group communications. The Initiator needs to form an I_MESSAGE for each member in the group, each using the same SSV. Alternatively, a bridge can be used. In this case, the bridge forms an I_MESSAGE for each member of the group. Any member of the group can invite new members directly by forming an I_MESSAGE using the group SSV.
SAKKE支持组通信的密钥建立。发起方需要为组中的每个成员形成一条I_消息，每个成员使用相同的SSV。或者，可以使用桥。在这种情况下，网桥为组中的每个成员形成I_消息。组中的任何成员都可以通过使用组SSV生成I_消息直接邀请新成员。
Deferred delivery / secure voicemail is fully supported by MIKEY-SAKKE. A deferred delivery server that supports MIKEY-SAKKE needs to store the MIKEY-SAKKE I_MESSAGE along with the encrypted data. When the recipient of the voicemail requests his data, the server needs to initiate MIKEY-SAKKE using the stored I_MESSAGE. Thus, the data can be received and decrypted only by a legitimate recipient, who can also verify the Identifier of the sender. This requires no additional support from the KMS, and the deferred delivery server need not be trusted, as it is unable to read or tamper with the messages it receives. Note that the deferred delivery server does not need to fully implement MIKEY-SAKKE merely to store and forward the I_MESSAGE.
MIKEY-SAKKE完全支持延迟交付/安全语音邮件。支持MIKEY-SAKKE的延迟传递服务器需要存储MIKEY-SAKKE I_消息以及加密数据。当语音邮件的收件人请求他的数据时，服务器需要使用存储的I_消息启动MIKEY-SAKKE。因此，数据只能由合法接收者接收和解密，合法接收者还可以验证发送者的标识符。这不需要KMS提供额外的支持，延迟交付服务器也不需要信任，因为它无法读取或篡改接收到的消息。请注意，延迟交付服务器不需要完全实现MIKEY-SAKKE，而只需要存储和转发I_消息。
The deferred delivery message needs to be collected by its recipient before the key period in which it was sent expires (see Section 3.3 for a discussion of key periods). Alternatively, if greater longevity of deferred delivery payloads is to be supported, the Initiator needs to include an I_MESSAGE for each key period during the lifetime of the deferred delivery message, each using the same SSV. In this case, the deferred delivery server needs to forward the I_MESSAGE corresponding to the current key period to the recipient.
延迟传递邮件需要在其发送的关键时段到期之前由收件人收集（有关关键时段的讨论，请参见第3.3节）。或者，如果要支持延长延迟交付有效负载的寿命，则发起方需要在延迟交付消息的生命周期内的每个关键时段包含I_消息，每个关键时段使用相同的SSV。在这种情况下，延迟传递服务器需要将与当前密钥周期对应的I_消息转发给收件人。
Once a MIKEY-SAKKE I_MESSAGE has been successfully processed by the Responder, he will share an authenticated SSV with the Initiator. This SSV is used as the TGK. The keys used to protect application traffic are derived as specified in [RFC3830].
一旦响应者成功处理MIKEY-SAKKE I_消息，他将与发起人共享经过身份验证的SSV。该SSV用作TGK。用于保护应用程序流量的密钥按照[RFC3830]中的规定派生。
One of the primary features and advantages of Identity-Based Encryption (IBE) is that the public keys of users are their Identifiers, which can be constructed by their peers. This removes the need for Public Key or Certificate servers, so that all data transmission per session can take place directly between the peers, and high-availability security infrastructure is not needed. In order for the Identifiers to be constructable, they need to be unambiguously defined. This section defines the format of Identifiers for use in MIKEY-SAKKE.
基于身份的加密（IBE）的主要特征和优点之一是，用户的公钥是他们的标识符，可以由他们的对等方构造。这消除了对公钥或证书服务器的需要，因此每个会话的所有数据传输都可以直接在对等方之间进行，并且不需要高可用性安全基础设施。为了使标识符是可构造的，它们需要明确定义。本节定义了在MIKEY-SAKKE中使用的标识符格式。
If keys are updated regularly, a KMS is able to revoke devices. To this end, every Identifier for use in MIKEY-SAKKE MUST contain a timestamp value indicating the key period for which the Identifier is valid (see Section 3.3). This document uses a year and month format to enforce monthly changes of key material. Further Identifier schemes MAY be defined for communities that require different key longevity.
如果密钥定期更新，KMS可以撤销设备。为此，在MIKEY-SAKKE中使用的每个标识符必须包含一个时间戳值，该时间戳值指示该标识符有效的关键时段（见第3.3节）。本文档使用年和月格式强制每月更改关键材料。可以为需要不同密钥寿命的社区定义进一步的标识符方案。
An Identifier for use in MIKEY-SAKKE MUST take the form of a timestamp formatted as a US-ASCII string [ASCII] and terminated by a null byte, followed by identifying data which relates to the identity of the device or user, also represented by a US-ASCII string and terminated by a null byte.
在MIKEY-SAKKE中使用的标识符必须采用时间戳的形式，时间戳格式为US-ASCII字符串[ASCII]，并以空字节终止，然后标识与设备或用户身份相关的数据，也由US-ASCII字符串表示，并以空字节终止。
For the purposes of this document, the timestamp MUST take the form of a year and month value, formatted according to [ISO8601], with the format "YYYY-MM", indicating a four-digit year, followed by a hyphen "-", followed by a two-digit month.
在本文件中，时间戳必须采用年和月值的形式，根据[ISO8601]进行格式化，格式为“YYYY-MM”，表示四位数的年，后跟连字符“-”，后跟两位数的月。
For the Identifier scheme defined in this document, the identifying data MUST take the form of a constrained "tel" URI. If an alternative URI scheme is to be used to form SAKKE Identifiers, a subsequent RFC MUST define constraints to ensure that the URI can be formed unambiguously. The normalization procedures described in Section 6 of [RFC3986] MUST be used as part of the constraining rules for the URI format. It would also be possible to define Identifier types that used identifying data other than a URI.
对于本文档中定义的标识符方案，标识数据必须采用受约束的“tel”URI的形式。如果要使用替代URI方案来形成SAKKE标识符，则后续RFC必须定义约束，以确保可以明确地形成URI。[RFC3986]第6节中描述的规范化过程必须用作URI格式约束规则的一部分。还可以定义使用URI以外的标识数据的标识符类型。
The restrictions for the "tel" URI scheme [RFC3966] for use in MIKEY-SAKKE Identifiers are as follows:
在MIKEY-SAKKE标识符中使用的“tel”URI方案[RFC3966]的限制如下：
* the "tel" URI for use in MIKEY-SAKKE MUST be formed in global notation,
* 在MIKEY-SAKKE中使用的“tel”URI必须以全局符号表示，
* visual separators MUST NOT be included,
* 不得包括目视分离器，
* the "tel" URI MUST NOT include additional parameters, and
* “tel”URI不得包含其他参数，以及
* the "tel" URI MUST NOT include phone-context parameters.
* “tel”URI不得包含电话上下文参数。
These constraints on format are necessary so that all parties can unambiguously form the "tel" URI.
格式上的这些约束是必要的，这样所有各方都可以明确地形成“tel”URI。
For example, suppose a user's telephone number is +447700900123 and the month is 2011-02, then the user's Identifier is defined as the ASCII string:
例如，假设用户的电话号码为+447700900123，月份为2011-02，则用户的标识符定义为ASCII字符串：
2011-02\0tel:+447700900123\0,
2011-02\0电话：+447700900123\0，
where '\0' denotes the null 8-bit ASCII character 0x00.
其中“\0”表示空的8位ASCII字符0x00。
If included in I_MESSAGE, the IDRi and IDRr payloads MUST contain the URI used to form the Identifier. The value of the month used to form the Identifiers MUST be equal to the month as specified by the data in the timestamp payload.
如果包含在I_消息中，IDRi和IDRr有效负载必须包含用于形成标识符的URI。用于形成标识符的月份的值必须等于时间戳有效负载中的数据指定的月份。
Identifiers for use in MIKEY-SAKKE change regularly in order to force users to regularly update their key material; we term the interval for which a key is valid a "key period". This means that if a device is compromised (and this is reported procedurally), it can continue to communicate with other users for at most one key period. Key
MIKEY-SAKKE中使用的标识符定期更改，以迫使用户定期更新其关键材料；我们将密钥有效的时间间隔称为“密钥周期”。这意味着，如果一个设备被破坏（并按程序报告），它最多可以在一个关键时期内继续与其他用户通信。钥匙
periods SHOULD be indicated by the granularity of the format of the timestamp used in the Identifier. In particular, the Identifier scheme in this document uses monthly key periods. Implementations MUST allow devices to hold two periods' keys simultaneously to allow for differences in system time between the Initiator and Responder.
期间应通过标识符中使用的时间戳格式的粒度来表示。特别是，本文件中的标识符方案使用每月关键时段。实现必须允许设备同时持有两个时段的密钥，以允许启动器和响应程序之间的系统时间差异。
Where a monthly key period applies, it is RECOMMENDED that implementations receive the new key material before the second-to-last day of the old month, commence allowing receipt of calls with the new key material on the second-to-last day of the old month, and continue to allow receipt calls with the old key material on the first and second days of the new month. Devices SHOULD cease to receive calls with key material corresponding to the previous month on the third day of the month; this is to allow compromised devices to be keyed out of the communicating user group.
如果每月关键期适用，建议实施部门在旧月的第二天到最后一天之前收到新的关键材料，并在旧月的第二天到最后一天开始允许接收使用新关键材料的呼叫，并在新月份的第一天和第二天继续允许使用旧的关键材料进行回执呼叫。设备应在当月第三天停止接收上个月关键材料的呼叫；这是为了允许泄露的设备从通信用户组中键入。
KMSs MAY update their KMS Master Secret Keys and KMS Master Secret Authentication Keys. If such an update is not deemed necessary, then the corresponding KMS Public Keys and KMS Public Authentication Keys will be fixed. If KMS keys are to be updated, then this update MUST
KMS可以更新其KMS主密钥和KMS主密钥身份验证密钥。如果认为不需要这样的更新，那么相应的KMS公钥和KMS公钥认证密钥将被修复。如果要更新KMS密钥，则必须执行此更新
occur at the change of a key period, and new KMS Public Key(s) and KMS Public Authentication Key(s) MUST be provided to all users with their user key material.
在密钥周期更改时发生，必须向所有用户提供新的KMS公钥和KMS公钥身份验证密钥及其用户密钥资料。
It is NOT RECOMMENDED for KMSs to distribute multiple key periods' keys simultaneously, as this prevents the periodic change of keys from excluding compromised devices.
不建议KMS同时分发多个密钥周期的密钥，因为这样可以防止密钥的周期性更改排除受损设备。
This document does not seek to restrict the mechanisms by which the necessary key material might be obtained from the KMS. The mechanisms of [RFC5408] are not suitable for this application, as the MIKEY-SAKKE protocol does not require public parameters to be obtained from a server: these are fixed for all users in order to facilitate interoperability and simplify implementation.
本文件并不试图限制从KMS获取必要关键材料的机制。[RFC5408]的机制不适用于此应用程序，因为MIKEY-SAKKE协议不要求从服务器获取公共参数：这些参数对于所有用户都是固定的，以便促进互操作性并简化实现。
The delivery mechanism used MUST provide confidentiality to all secret keys, integrity protection to all keys, and mutual authentication of the device and the KMS.
使用的传递机制必须为所有密钥提供机密性，为所有密钥提供完整性保护，并对设备和KMS进行相互身份验证。
This section describes the new SAKKE payload and also the payloads for which changes have been made compared to [RFC3830]. A detailed description of MIKEY payloads is provided in [RFC3830].
本节描述了新的SAKKE有效载荷，以及与[RFC3830]相比进行了更改的有效载荷。[RFC3830]中提供了MIKEY有效载荷的详细说明。
An additional value is added to the data type and next payload fields.
将向数据类型和下一有效负载字段添加一个附加值。
* Data type (8 bits): describes the type of message.
* 数据类型（8位）：描述消息的类型。
Data type | Value | Comment
-----------------------------------------------
SAKKE msg | 26 | Initiator's SAKKE message
Data type | Value | Comment
-----------------------------------------------
SAKKE msg | 26 | Initiator's SAKKE message
Table 1: Data type (additions)
表1：数据类型（增补）
* Next payload (8 bits): identifies the payload that is added after this payload.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
Next payload | Value | Section
-------------------------------
SAKKE | 26 | 4.2
Next payload | Value | Section
-------------------------------
SAKKE | 26 | 4.2
Table 2: Next payload (additions)
表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 by the Responder in a SAKKE message.
* V（1位）：指示响应消息是否应为（'1'）的标志。它必须设置为“0”，并被SAKKE消息中的响应者忽略。
The SAKKE payload contains the SAKKE Encapsulated Data as defined in [RFC6508].
SAKKE负载包含[RFC6508]中定义的SAKKE封装数据。
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 ! SAKKE params ! ID scheme ! SAKKE data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! SAKKE data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! SAKKE params ! ID scheme ! SAKKE data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! SAKKE data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 3: SAKKE payload
表3:SAKKE有效载荷
* Next payload (8 bits): identifies the payload that is added after this payload.
* 下一个有效负载（8位）：标识在该有效负载之后添加的有效负载。
* SAKKE params (8 bits): indicates the SAKKE parameter set to be used.
* SAKKE参数（8位）：表示要使用的SAKKE参数集。
SAKKE params | Value
------------------------------------------
Parameter Set 1 (See Appendix A) | 1
SAKKE params | Value
------------------------------------------
Parameter Set 1 (See Appendix A) | 1
Table 4: SAKKE params
表4:SAKKE参数
* ID scheme (8 bits): indicates the SAKKE identifier scheme to be used.
* ID方案（8位）：表示要使用的SAKKE标识符方案。
ID scheme | Value
----------------------------------------------------
tel URI with monthly keys (See Section 3.2) | 1
ID scheme | Value
----------------------------------------------------
tel URI with monthly keys (See Section 3.2) | 1
Table 5: ID scheme
表5：身份证制度
* SAKKE data length (16 bits): length of SAKKE data (in bytes).
* SAKKE数据长度（16位）：SAKKE数据的长度（字节）。
* SAKKE data (variable): the SAKKE Encapsulated Data formatted as defined in Section 4 of [RFC6508].
* SAKKE数据（变量）：按照[RFC6508]第4节中的定义格式化的SAKKE封装数据。
To enable use of the ECCSI signature algorithm, which has efficiency benefits for use with Identity-based encryption, we define an additional signature type.
为了能够使用ECCSI签名算法（该算法在使用基于身份的加密时具有效率优势），我们定义了一种额外的签名类型。
* S type (4 bits): indicates the signature algorithm applied by the Signer.
* S类型（4位）：表示签名者应用的签名算法。
S type | Value | Comments
-----------------------------------
ECCSI | 2 | ECCSI signature
S type | Value | Comments
-----------------------------------
ECCSI | 2 | ECCSI signature
Table 6: S type (additions)
表6:S型（增补件）
The IDR payload was defined in [RFC6043], but its definition only provided the facility to identify one KMS per exchange. Since it is possible that different KMSs could be used by the Initiator and Responder, this payload is extended to define an ID Role for the KMS of the Initiator and the KMS of the Responder.
IDR有效负载在[RFC6043]中有定义，但其定义仅提供了识别每个交换机一公里的功能。由于发起方和响应方可能使用不同的KMS，因此扩展此有效负载以定义发起方的KMS和响应方的KMS的ID角色。
* ID Role (8 bits): specifies the sort of identity.
* ID角色（8位）：指定标识的种类。
ID Role | Value
---------------------------------
Initiator's KMS (IDRkmsi) | 6
Responder's KMS (IDRkmsr) | 7
ID Role | Value
---------------------------------
Initiator's KMS (IDRkmsi) | 6
Responder's KMS (IDRkmsr) | 7
Table 7: ID Role (additions)
表7：ID角色（新增）
MIKEY-SAKKE is suitable for use in a range of applications in which secure communications under a clear trust model are needed. In particular, the KMS need not provide high availability, as it is only necessary to provide a periodic refresh of key material. Devices are provided with a high level of authentication, as the KMS acts as a root of trust for both key exchange and signatures.
MIKEY-SAKKE适用于需要在明确信任模型下进行安全通信的一系列应用。特别是，KMS不需要提供高可用性，因为只需要定期更新关键材料。设备具有高级别的身份验证，因为KMS充当密钥交换和签名的信任根。
Unless explicitly stated, the security properties of the MIKEY protocol as described in [RFC3830] apply to MIKEY-SAKKE as well. In addition, MIKEY-SAKKE inherits some properties of Identity-based cryptography. For instance, by concatenating the "date" with the URI to form the Identifier, the need for any key revocation mechanisms is
除非明确说明，[RFC3830]中描述的MIKEY协议的安全属性也适用于MIKEY-SAKKE。此外，MIKEY-SAKKE继承了基于身份的密码学的一些特性。例如，通过将“日期”与URI连接起来以形成标识符，就不需要任何密钥撤销机制
virtually eliminated. It is NOT RECOMMENDED for KMSs to distribute multiple months' keys simultaneously in an IBE system, as this prevents the monthly change of keys from excluding compromised devices.
几乎被淘汰。建议KMS不要在IBE系统中同时分发多个月的密钥，因为这样可以防止每月更换密钥，从而排除受损设备。
The solution proposed provides protection suitable for high-security user groups, but is scalable enough that it could be used for large numbers of users. Traffic keys cannot be derived by any infrastructure component other than the KMS.
提出的解决方案提供了适用于高安全性用户组的保护，但具有足够的可扩展性，可用于大量用户。除了KMS之外，任何基础设施组件都无法派生流量密钥。
The effective security of the public parameters defined in this document is 112 bits, as this is the security offered by the prime p of size 1024 bits used in SAKKE (see Section 7 of [RFC6508]). For similar parameter sizes, MIKEY-SAKKE provides equivalent levels of effective security to other schemes of this type (such as [RFC6267]). For reasons of efficiency and security, it is RECOMMENDED to use a mode of AES-128 [AES] in the traffic application to which MIKEY-SAKKE supplies key material, but users SHOULD be aware that 112 bits of security are offered by the defined public parameters. Following [SP800-57], this choice of security strength is appropriate for use to protect data until 2030.
本文件中定义的公共参数的有效安全性为112位，因为这是SAKKE中使用的1024位素数p提供的安全性（见[RFC6508]第7节）。对于类似的参数大小，MIKEY-SAKKE提供了与此类型的其他方案（如[RFC6267]）同等级别的有效安全性。出于效率和安全性的考虑，建议在MIKEY-SAKKE提供关键材料的流量应用程序中使用AES-128[AES]模式，但用户应注意，定义的公共参数提供了112位安全性。在[SP800-57]之后，这种安全强度选择适用于2030年之前的数据保护。
User identities cannot be spoofed, since the Public Authentication Token is tied to the Identifier of the sender by the KMS. In particular, the Initiator is provided with assurance that nobody other than a holder of the legitimate Receiver Secret Key can process the SAKKE Encapsulated Data, and the signature binds the holder of the Initiator's Secret Signing Key to the I_MESSAGE. Since these keys are provided via a secure channel by the KMS, mutual authentication is provided. This mechanism protects against both passive and active attacks.
不能伪造用户身份，因为KMS将公共身份验证令牌绑定到发送方的标识符。特别地，向发起方提供了除了合法接收方密钥的持有者之外没有人可以处理SAKKE封装的数据的保证，并且签名将发起方的秘密签名密钥的持有者绑定到I_消息。由于KMS通过安全通道提供这些密钥，因此提供了相互认证。此机制可防止被动和主动攻击。
If there were a requirement that a caller remain anonymous from any called parties, then it would be possible to remove the signature from the protocol. A called user could then decide, according to local policy, whether to accept such a secure session.
如果要求调用方保持匿名，则可以从协议中删除签名。然后，被叫用户可以根据本地策略决定是否接受这样一个安全会话。
Where forking is used, the view is taken that it is not necessary for each device to have a separate Receiver Secret Key. Rather, where a user wishes his calls to be forked between his devices, he loads the same Receiver Secret Key onto each of them. This does not compromise his security as he controls each of the devices, and is consistent with the Initiator's expectation that he is authenticated to the owner of the Identifier he selected when initiating the call.
在使用分叉的情况下，认为每个设备不必具有单独的接收器密钥。相反，当用户希望他的呼叫在他的设备之间转移时，他会将相同的接收器密钥加载到每个设备上。这不会影响他的安全性，因为他控制着每个设备，并且与发起者的期望一致，即他在发起呼叫时向他选择的标识符的所有者进行身份验证。
Since the Initiator is made aware by the forwarding server of the change to the Identifier of the Responder, he creates an I_MESSAGE that can only be processed by this legitimate Responder. The Initiator MAY also choose to discontinue the session after checking his local policy.
由于转发服务器使发起方知道响应方标识符的更改，因此发起方创建的I_消息只能由该合法响应方处理。启动器还可以在检查其本地策略后选择中断会话。
Any device that possesses an SSV can potentially provide it securely to any other device using SAKKE. Thus, group calls can either be established by an Initiator, or can be extended to further Responders by any party to whom the original Initiator has sent an I_MESSAGE.
任何拥有SSV的设备都有可能使用SAKKE将其安全地提供给任何其他设备。因此，组呼叫可以由发起方建立，也可以由原始发起方向其发送I_消息的任何一方扩展到其他响应方。
The Initiator in this context MAY be a conference bridge. If a mode of operation in which a bridge has no knowledge of the SSV is needed, the role of the MIKEY-SAKKE Initiator MUST be carried out by one or more of the communicating parties, not by the bridge.
在此上下文中，发起方可以是会议桥。如果需要网桥不知道SSV的操作模式，则MIKEY-SAKKE启动器的角色必须由一个或多个通信方执行，而不是由网桥执行。
Where multi-way communications (rather than broadcast) are needed, the application using the supplied key material MUST ensure that a suitable Initialization Vector (IV) scheme is used in order to prevent cryptovariable re-use.
在需要多路通信（而不是广播）的情况下，使用提供的密钥材料的应用程序必须确保使用合适的初始化向量（IV）方案，以防止加密变量重复使用。
Secure deferred delivery is supported in a manner such that no trust is placed on the deferred delivery server. This is a significant advantage, as it removes the need for secure infrastructure components beyond the KMS.
安全延迟交付的支持方式应确保延迟交付服务器不受信任。这是一个显著的优势，因为它不再需要KMS之外的安全基础设施组件。
This document defines new values for the namespaces Data Type, Next Payload, and S type defined in [RFC3830], and for the ID Role namespace defined in [RFC6043]. The following IANA assignments have been added to the MIKEY Payload registry:
本文档为[RFC3830]中定义的名称空间数据类型、下一个有效负载和S类型以及[RFC6043]中定义的ID角色名称空间定义了新值。以下IANA分配已添加到MIKEY有效负载注册表：
* 26 - Data type (see Table 1)
* 26-数据类型（见表1）
* 26 - Next payload (see Table 2)
* 26-下一有效载荷（见表2）
* 2 - S type (see Table 6)
* 2-S型（见表6）
* ID Role (see Table 7) * 6 - Initiator's KMS (IDRkmsi) * 7 - Responder's KMS (IDRkmsr)
* ID角色（见表7）*6-发起人的KMS（IDRkmsi）*7-响应者的KMS（IDRkmsr）
The SAKKE payload defined in Section 4.2 defines two fields for which IANA has created and now maintains namespaces in the MIKEY Payload registry. These two fields are the 8-bit SAKKE Params field, and the 8-bit ID Scheme field. IANA has recorded the pre-defined values defined in Section 4.2 for each of the two name spaces. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are for Private Use, and the values 0 and 255 are Reserved according to [RFC5226].
第4.2节中定义的SAKKE负载定义了两个字段，IANA已经为这两个字段创建并在MIKEY负载注册表中维护了名称空间。这两个字段是8位SAKKE参数字段和8位ID方案字段。IANA已记录了第4.2节中为两个名称空间中的每个名称空间定义的预定义值。1-239范围内的值应通过所需的规范程序批准，240-254范围内的值供私人使用，0和255值根据[RFC5226]保留。
Initial values for the SAKKE Params registry are given below. Assignments consist of a SAKKE parameters name and its associated value.
SAKKE Params注册表的初始值如下所示。赋值由SAKKE参数名称及其关联值组成。
Value SAKKE params Definition
----- ------------ ----------
0 Reserved
1 Parameter Set 1 See Appendix A
2-239 Unassigned
240-254 Private Use
255 Reserved
Value SAKKE params Definition
----- ------------ ----------
0 Reserved
1 Parameter Set 1 See Appendix A
2-239 Unassigned
240-254 Private Use
255 Reserved
Initial values for the ID scheme registry are given below. Assignments consist of a name of an identifier scheme name and its associated value.
ID方案注册表的初始值如下所示。分配由标识符方案名称及其关联值的名称组成。
Value ID Scheme Definition
----- ------------ ----------
0 Reserved
1 tel URI with monthly keys See Section 3.2
2-239 Unassigned
240-254 Private Use
255 Reserved
Value ID Scheme Definition
----- ------------ ----------
0 Reserved
1 tel URI with monthly keys See Section 3.2
2-239 Unassigned
240-254 Private Use
255 Reserved
[AES] NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, http://www.itl.nist.gov/fipspubs/ by-num.htm.
[AES]NIST，“高级加密标准（AES）”，FIPS PUB 197，2001年11月，http://www.itl.nist.gov/fipspubs/ by-num.htm。
[ASCII] American National Standards Institute, "Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986.
[ASCII]美国国家标准协会，“编码字符集-信息交换用7位美国国家标准代码（7位ASCII）”，ANSI X3.41986。
[FIPS180-3] Federal Information Processing Standards Publication (FIPS PUB) 180-3, "Secure Hash Standard (SHS)", October 2008.
[FIPS180-3]联邦信息处理标准出版物（FIPS PUB）180-3，“安全哈希标准（SHS）”，2008年10月。
[FIPS186-3] Federal Information Processing Standards Publication (FIPS PUB) 186-3, "Digital Signature Standard (DSS)", June 2009.
[FIPS186-3]联邦信息处理标准出版物（FIPS PUB）186-3，“数字签名标准（DSS）”，2009年6月。
[ISO8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:2004(E), International Organization for Standardization, December 2004.
[ISO8601]“数据元和交换格式——信息交换——日期和时间的表示”，ISO 8601:2004（E），国际标准化组织，2004年12月。
[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月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6043, March 2011.
[RFC6043]Mattsson，J.和T.Tian，“MIKEY-TICKET：多媒体互联网密钥分配（MIKEY）中基于票据的密钥分配模式”，RFC 60432011年3月。
[RFC6507] Groves, M., "Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)", RFC 6507, February 2012.
[RFC6507]Groves，M.，“基于椭圆曲线的无证书签名用于基于身份的加密（ECCSI）”，RFC6507，2012年2月。
[RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", RFC 6508, February 2012.
[RFC6508]Groves，M.，“Sakai Kasahara密钥加密（SAKKE）”，RFC 65082012年2月。
[SP800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, March 2007.
[SP800-57]Barker，E.，Barker，W.，Burr，W.，Polk，W.，和M.Smid，“关键管理建议-第1部分：概述（修订）”，NIST特别出版物800-57，2007年3月。
[3GPP.33.328] 3GPP, "IP Multimedia Subsystem (IMS) media plane security", 3GPP TS 33.328 10.0.0, April 2011.
[3GPP.33.328]3GPP，“IP多媒体子系统（IMS）媒体平面安全”，3GPP TS 33.328 10.0.012011年4月。
[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月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650]Euchner，M.“HMAC认证的Diffie Hellman多媒体互联网密钥（MIKEY）”，RFC 46502006年9月。
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006.
[RFC4738]Ignjatic，D.，Dondeti，L.，Audet，F.，和P.Lin，“MIKEY-RSA-R：多媒体互联网密钥分配（MIKEY）中的另一种密钥分配模式”，RFC 4738，2006年11月。
[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月。
[RFC5408] Appenzeller, G., Martin, L., and M. Schertler, "Identity-Based Encryption Architecture and Supporting Data Structures", RFC 5408, January 2009.
[RFC5408]Appenzeller，G.，Martin，L.和M.Schertler，“基于身份的加密体系结构和支持数据结构”，RFC 5408，2009年1月。
[RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6267, June 2011.
[RFC6267]Cakulev，V.和G.Sundaram，“MIKEY-IBAKE：多媒体互联网密钥分配（MIKEY）中基于身份的认证密钥交换（IBAKE）模式”，RFC 6267，2011年6月。
[S-K] Sakai, R., Ohgishi, K., and M. Kasahara, "ID based cryptosystem based on pairing on elliptic curves", Symposium on Cryptography and Information Security - SCIS, 2001.
[S-K]Sakai，R.，Ohgishi，K.，和M.Kasahara，“基于椭圆曲线配对的基于身份的密码系统”，密码学和信息安全研讨会-SCIS，2001年。
[RFC6508] requires each application to define the set of public parameters to be used by implementations. Parameter Set 1 is defined in this appendix. Descriptions of the parameters are provided in Section 2.1 of [RFC6508].
[RFC6508]要求每个应用程序定义实现使用的公共参数集。参数集1在本附录中定义。[RFC6508]第2.1节提供了参数说明。
n = 128
n = 128
p = 997ABB1F 0A563FDA 65C61198 DAD0657A 416C0CE1 9CB48261 BE9AE358 B3E01A2E F40AAB27 E2FC0F1B 228730D5 31A59CB0 E791B39F F7C88A19 356D27F4 A666A6D0 E26C6487 326B4CD4 512AC5CD 65681CE1 B6AFF4A8 31852A82 A7CF3C52 1C3C09AA 9F94D6AF 56971F1F FCE3E823 89857DB0 80C5DF10 AC7ACE87 666D807A FEA85FEB
p=997ABB1F 0A563FDA 65C61198 DAD0657A 416C0CE1 9CB48261 BE9AE358 B3E01A2E F40AAB27 E2FC0F1B 228730D5 31A59CB0 E791B39F F7C88A19 356D27F4 A666A6D0 E26C6487 326B4CD4 512AC5CD 65681CE1 B6FF4A8 31852A82 A7CF3C52 1C09AA 9F94D6AF 56971F FCE3E823 89857DB0 C57 AC66A87 ACE807A
q = 265EAEC7 C2958FF6 99718466 36B4195E 905B0338 672D2098 6FA6B8D6 2CF8068B BD02AAC9 F8BF03C6 C8A1CC35 4C69672C 39E46CE7 FDF22286 4D5B49FD 2999A9B4 389B1921 CC9AD335 144AB173 595A0738 6DABFD2A 0C614AA0 A9F3CF14 870F026A A7E535AB D5A5C7C7 FF38FA08 E2615F6C 203177C4 2B1EB3A1 D99B601E BFAA17FB
q=265EAEC7 C2958FF6 99718466 36B4195E 905B0338 672D2098 6FA6B8D6 2CF8068B BD02AAC9 F8BF03C6 C8A1CC35 4C69672C 39E46CE7 FDF22286 4D5B49FD 299A9B4 389B1921 CC9AD335 144AB173 595A0738 6DABFD2A 0C614AA0 A7F3CF14 870F026A A7E535AB D5A5C7C7 FF38FA08 E2615F6C 2031772B1B35B9B6BF17
Px = 53FC09EE 332C29AD 0A799005 3ED9B52A 2B1A2FD6 0AEC69C6 98B2F204 B6FF7CBF B5EDB6C0 F6CE2308 AB10DB90 30B09E10 43D5F22C DB9DFA55 718BD9E7 406CE890 9760AF76 5DD5BCCB 337C8654 8B72F2E1 A702C339 7A60DE74 A7C1514D BA66910D D5CFB4CC 80728D87 EE9163A5 B63F73EC 80EC46C4 967E0979 880DC8AB EAE63895
Px=53FC09EE 332C29AD 0A79905 3ED9B52A 2B1A2FD6 0AEC69C698B2F204 B6FF7CBF B5EDB6C0 F6CE2308 AB10DB90 30B09E10 43D5F22C DB9DFA55 718BD9E7 406CE890 9760AF76 5DD5BCCB 337C8654 8B72F2E1 A70C339 7A60 DE74 A7C1514D BA667910D D5CF4CC 80728D87 EE916363B73EC 80ECC496E09789
Py = 0A824906 3F6009F1 F9F1F053 3634A135 D3E82016 02990696 3D778D82 1E141178 F5EA69F4 654EC2B9 E7F7F5E5 F0DE55F6 6B598CCF 9A140B2E 416CFF0C A9E032B9 70DAE117 AD547C6C CAD696B5 B7652FE0 AC6F1E80 164AA989 492D979F C5A4D5F2 13515AD7 E9CB99A9 80BDAD5A D5BB4636 ADB9B570 6A67DCDE 75573FD7 1BEF16D7
Py=0A824906 3F6009F1 F9F1F053 3634A135 D3E82016 02990696 3D778D82 1E141178 F5EA69F4 654EC2B9 E7F5E5 F0DE55F6 6B598CCF 9A140B2E 416CFF0C A9E032B9 70DAE117 AD547C6C CAD696B7652FE0 AC6F1E80 164AA989 492D979F C5A4D5F2 13515AD9CB99A9 80AD5B4636 ADB706ADB567ADB757FD7
g = 66FC2A43 2B6EA392 148F1586 7D623068 C6A87BD1 FB94C41E 27FABE65 8E015A87 371E9474 4C96FEDA 449AE956 3F8BC446 CBFDA85D 5D00EF57 7072DA8F 541721BE EE0FAED1 828EAB90 B99DFB01 38C78433 55DF0460 B4A9FD74 B4F1A32B CAFA1FFA D682C033 A7942BCC E3720F20 B9B7B040 3C8CAE87 B7A0042A CDE0FAB3 6461EA46
g=66FC2A43 2B6EA392 148F1586 7D623068 C6A87BD1 FB94C41E 27FABE65 8E015A87 371E9474 4C96FEDA 449AE956 3F8BC446 CBFDA85D 5D00EF57 7072DA8F 541721已被FAED1 828EAB90 B99DFB01 38C78433 55DF0460 B4A9FD74 B4F1A32B CAFAA1FFA D6820C033 A7942BCC E3720F20 B9B7B7B00 3CA002A 6446
Hash = SHA-256 (defined in [FIPS180-3]).
哈希=SHA-256（定义见[FIPS180-3]）。
Author's Address
作者地址
Michael Groves CESG Hubble Road Cheltenham GL51 8HJ UK EMail: Michael.Groves@cesg.gsi.gov.uk
Michael Groves CESG哈勃路切尔滕纳姆GL51 8HJ英国电子邮件：Michael。Groves@cesg.gsi.gov.uk
M. Groves Informational [Page 21]
M.Groves信息[第21页]