Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 5705 RTFM, Inc.
Category: Standards Track March 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 5705 RTFM, Inc.
Category: Standards Track March 2010
ISSN: 2070-1721
Keying Material Exporters for Transport Layer Security (TLS)
传输层安全（TLS）的关键材料导出器
Abstract
摘要
A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that.
许多协议希望利用传输层安全性（TLS）来执行密钥建立，但随后将一些密钥材料用于它们自己的目的。本文档描述了允许该操作的一般机制。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/5705.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/5705.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人可能没有授予IETF信托允许的权利
modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
在IETF标准过程之外修改此类材料。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used In This Document . . . . . . . . . . . . . . . 3
3. Binding to Application Contexts . . . . . . . . . . . . . . . . 3
4. Exporter Definition . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used In This Document . . . . . . . . . . . . . . . 3
3. Binding to Application Contexts . . . . . . . . . . . . . . . . 3
4. Exporter Definition . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Note: The mechanism described in this document was previously known as "TLS Extractors" but was changed to avoid a name conflict with the use of the term "Extractor" in the cryptographic community.
注意：本文档中描述的机制以前称为“TLS提取器”，但经过更改以避免与加密社区中术语“提取器”的使用发生名称冲突。
A number of protocols wish to leverage Transport Layer Security (TLS) [RFC5246] or Datagram TLS (DTLS) [RFC4347] to perform key establishment but then use some of the keying material for their own purposes. A typical example is DTLS-SRTP [DTLS-SRTP], a key management scheme for the Secure Real-time Transport Protocol (SRTP) that uses DTLS to perform a key exchange and negotiate the SRTP [RFC3711] protection suite and then uses the DTLS master_secret to generate the SRTP keys.
许多协议希望利用传输层安全性（TLS）[RFC5246]或数据报TLS（DTL）[RFC4347]来执行密钥建立，但随后将一些密钥材料用于自己的目的。一个典型的例子是DTLS-SRTP[DTLS-SRTP]，一种用于安全实时传输协议（SRTP）的密钥管理方案，它使用DTLS执行密钥交换和协商SRTP[RFC3711]保护套件，然后使用DTLS主密钥生成SRTP密钥。
These applications imply a need to be able to export keying material (later called Exported Keying Material or EKM) from TLS/DTLS to an application or protocol residing at an upper layer, and to securely agree on the upper-layer context where the keying material will be used. The mechanism for exporting the keying material has the following requirements:
这些应用意味着需要能够从TLS/DTL将密钥材料（后来称为导出密钥材料或EKM）导出到驻留在上层的应用程序或协议，并在将使用密钥材料的上层上下文上安全地达成一致。导出键控材质的机制具有以下要求：
o Both client and server need to be able to export the same EKM value.
o 客户端和服务器都需要能够导出相同的EKM值。
o EKM values should be indistinguishable from random data to attackers who don't know the master_secret.
o 对于不知道master_机密的攻击者，EKM值应该与随机数据无法区分。
o It should be possible to export multiple EKM values from the same TLS/DTLS association.
o 应该可以从同一TLS/DTLS关联导出多个EKM值。
o Knowing one EKM value should not reveal any useful information about the master_secret or about other EKM values.
o 知道一个EKM值不应泄露有关主密钥或其他EKM值的任何有用信息。
The mechanism described in this document is intended to fulfill these requirements. This mechanism is compatible with all versions of TLS.
本文件中描述的机制旨在满足这些要求。此机制与TLS的所有版本兼容。
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]中所述进行解释。
In addition to using an exporter to obtain keying material, an application using the keying material has to securely establish the upper-layer context where the keying material will be used. The details of this context depend on the application, but it could include things such as algorithms and parameters that will be used with the keys, identifier(s) for the endpoint(s) who will use the keys, identifier(s) for the session(s) where the keys will be used, and the lifetime(s) for the context and/or keys. At a minimum, there should be some mechanism for signaling that an exporter will be used.
除了使用导出器获取键控材料外，使用键控材料的应用程序还必须安全地建立将使用键控材料的上层上下文。此上下文的详细信息取决于应用程序，但它可能包括诸如将与密钥一起使用的算法和参数、将使用密钥的端点的标识符、将使用密钥的会话的标识符以及上下文和/或密钥的生存期等内容。至少，应该有某种机制来表明将使用出口商。
This specification does not mandate a single mechanism for agreeing on such context; instead, there are several possibilities that can be used (and can complement each other). For example:
本规范不要求就此类背景达成一致的单一机制；相反，可以使用多种可能性（并且可以相互补充）。例如：
o Information about the upper-layer context can be included in the optional data after the exporter label (see Section 4).
o 有关上层上下文的信息可以包含在导出器标签后的可选数据中（参见第4节）。
o Information about the upper-layer context can be exchanged in TLS extensions included in the ClientHello and ServerHello messages. This approach is used in [DTLS-SRTP]. The handshake messages are protected by the Finished messages, so once the handshake completes, the peers will have the same view of the information. Extensions also allow a limited form of negotiation: for example, the TLS client could propose several alternatives for some context parameters, and the TLS server could select one of them.
o 有关上层上下文的信息可以在ClientHello和ServerHello消息中包含的TLS扩展中交换。此方法在[DTLS-SRTP]中使用。握手消息由完成的消息保护，因此一旦握手完成，对等方将拥有相同的信息视图。扩展还允许有限形式的协商：例如，TLS客户机可以为某些上下文参数提出几种备选方案，TLS服务器可以选择其中一种。
o The upper-layer protocol can include its own handshake, which can be protected using the keys exported by TLS.
o 上层协议可以包含自己的握手，可以使用TLS导出的密钥对其进行保护。
No matter how the context is agreed, it is required that it has one part that indicates which application will use the exported keys. This part is the disambiguating label string (see Section 4).
无论上下文如何约定，它都需要有一个部分来指示哪个应用程序将使用导出的密钥。这部分是消除歧义的标签字符串（参见第4节）。
It is important to note that just embedding TLS messages in the upper-layer protocol may not automatically secure all the important context information, since the upper-layer messages are not covered by TLS Finished messages.
需要注意的是，仅仅在上层协议中嵌入TLS消息可能不会自动保护所有重要的上下文信息，因为上层消息不包含在TLS完成的消息中。
The output of the exporter is intended to be used in a single scope, which is associated with the TLS session, the label, and the context value.
导出器的输出用于单个作用域，该作用域与TLS会话、标签和上下文值关联。
The exporter takes three input values:
导出器接受三个输入值：
o a disambiguating label string,
o 消除歧义的标签字符串，
o a per-association context value provided by the application using the exporter, and
o 由使用导出器的应用程序提供的每个关联上下文值，以及
o a length value.
o 长度值。
If no context is provided, it then computes:
如果未提供上下文，则计算：
PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random )[length]
PRF（SecurityParameters.master\u secret、label、SecurityParameters.client\u random+SecurityParameters.server\u random）[长度]
If context is provided, it computes:
如果提供了上下文，它将计算：
PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random + context_value_length + context_value )[length]
PRF（SecurityParameters.master\u secret，label，SecurityParameters.client\u random+SecurityParameters.server\u random+context\u value\u length+context\u value）[length]
Where PRF is the TLS Pseudorandom Function in use for the session. The output is a pseudorandom bit string of length bytes generated from the master_secret. (This construction allows for interoperability with older exporter-type constructions which do not use context values, e.g., [RFC5281]).
其中，PRF是用于会话的TLS伪随机函数。输出是一个伪随机位字符串，长度为字节，由master_secret生成。（此构造允许与不使用上下文值的旧导出器类型构造（例如[RFC5281]）进行互操作。
Labels here have the same definition as in TLS, i.e., an ASCII string with no terminating NULL. Label values beginning with "EXPERIMENTAL" MAY be used for private use without registration. All other label
此处的标签具有与TLS中相同的定义，即ASCII字符串，无终止NULL。以“实验”开头的标签值可用于私人用途，无需注册。所有其他标签
values MUST be registered via Specification Required as described by RFC 5226 [RFC5226]. Note that exporter labels have the potential to collide with existing PRF labels. In order to prevent this, labels SHOULD begin with "EXPORTER". This is not a MUST because there are existing uses that have labels which do not begin with this prefix.
必须通过RFC 5226[RFC5226]所述的规范注册值。请注意，出口商标签可能与现有PRF标签发生冲突。为了防止这种情况，标签应以“出口商”开头。这不是必须的，因为存在不以此前缀开头的标签的现有用途。
The context value allows the application using the exporter to mix its own data with the TLS PRF for the exporter output. One example of where this might be useful is an authentication setting where the client credentials are valid for more than one identity; the context value could then be used to mix the expected identity into the keying material, thus preventing substitution attacks. The context value length is encoded as an unsigned, 16-bit quantity (uint16; see [RFC5246], Section 4.4) representing the length of the context value. The context MAY be zero length. Because the context value is mixed with the master_secret via the PRF, it is safe to mix confidential information into the exporter, provided that the master_secret will not be known to the attacker.
上下文值允许使用导出器的应用程序将自己的数据与导出器输出的TLS PRF混合。这可能有用的一个示例是身份验证设置，其中客户端凭据对多个身份有效；然后可以使用上下文值将预期标识混合到键控材料中，从而防止替换攻击。上下文值长度编码为表示上下文值长度的无符号16位数量（uint16；参见[RFC5246]，第4.4节）。上下文的长度可以为零。由于上下文值通过PRF与主密钥混合，因此在攻击者不知道主密钥的情况下，将机密信息混合到导出器中是安全的。
The prime security requirement for exporter outputs is that they be independent. More formally, after a particular TLS session, if an adversary is allowed to choose multiple (label, context value) pairs and is given the output of the PRF for those values, the attacker is still unable to distinguish between the output of the PRF for a (label, context value) pair (different from the ones that it submitted) and a random value of the same length. In particular, there may be settings, such as the one described in Section 4, where the attacker can control the context value; such an attacker MUST NOT be able to predict the output of the exporter. Similarly, an attacker who does not know the master secret should not be able to distinguish valid exporter outputs from random values. The current set of TLS PRFs is believed to meet this objective, provided the master secret is randomly generated.
出口商输出的主要安全要求是它们必须是独立的。更正式地说，在特定TLS会话之后，如果允许对手选择多个（标签、上下文值）对，并为这些值提供PRF输出，则攻击者仍然无法区分（标签、上下文值）对的PRF输出（不同于其提交的）和相同长度的随机值。特别是，可能存在攻击者可以控制上下文值的设置，如第4节所述；此类攻击者必须无法预测导出器的输出。类似地，不知道主密钥的攻击者也不能区分有效的导出器输出和随机值。如果主密钥是随机生成的，那么当前的TLS PRF集被认为能够满足这一目标。
Because an exporter produces the same value if applied twice with the same label to the same master_secret, it is critical that two EKM values generated with the same label not be used for two different purposes -- hence, the requirement for IANA registration. However, because exporters depend on the TLS PRF, it is not a threat to the use of an EKM value generated from one label to reveal an EKM value generated from another label.
由于导出程序使用同一标签对同一主密钥应用两次会产生相同的值，因此使用同一标签生成的两个EKM值不得用于两个不同的目的，这一点至关重要——因此，IANA注册的要求。然而，由于出口商依赖TLS PRF，因此使用一个标签产生的EKM值来显示另一个标签产生的EKM值并不构成威胁。
With certain TLS cipher suites, the TLS master secret is not necessarily unique to a single TLS session. In particular, with RSA key exchange, a malicious party acting as TLS server in one session and as TLS client in another session can cause those two sessions to
对于某些TLS密码套件，TLS主密钥不一定对单个TLS会话唯一。特别是，使用RSA密钥交换，在一个会话中充当TLS服务器，在另一个会话中充当TLS客户端的恶意方可能会导致这两个会话中断
have the same TLS master secret (though the sessions must be established simultaneously to get adequate control of the Random values). Applications using the EKM need to consider this in how they use the EKM; in some cases, requiring the use of other cipher suites (such as those using a Diffie-Hellman key exchange) may be advisable.
具有相同的TLS主密钥（尽管必须同时建立会话以充分控制随机值）。使用EKM的应用需要考虑如何使用EKM；在某些情况下，要求使用其他密码套件（例如使用Diffie-Hellman密钥交换的密码套件）可能是可取的。
Designing a secure mechanism that uses exporters is not necessarily straightforward. This document only provides the exporter mechanism, but the problem of agreeing on the surrounding context and the meaning of the information passed to and from the exporter remains. Any new uses of the exporter mechanism should be subject to careful review.
设计使用导出器的安全机制并不一定简单。本文件仅提供了出口商机制，但在与出口商之间传递的信息的上下文和含义上达成一致的问题仍然存在。出口商机制的任何新用途都应受到仔细审查。
IANA has created a TLS Exporter Label registry for this purpose. The initial contents of the registry are given below:
IANA为此目的创建了TLS出口商标签注册中心。登记册的初步内容如下：
Value Reference Note
----------------------------- --------- ----
client finished [RFC5246] (1)
server finished [RFC5246] (1)
master secret [RFC5246] (1)
key expansion [RFC5246] (1)
client EAP encryption [RFC5216]
ttls keying material [RFC5281]
ttls challenge [RFC5281]
Value Reference Note
----------------------------- --------- ----
client finished [RFC5246] (1)
server finished [RFC5246] (1)
master secret [RFC5246] (1)
key expansion [RFC5246] (1)
client EAP encryption [RFC5216]
ttls keying material [RFC5281]
ttls challenge [RFC5281]
Note: (1) These entries are reserved and MUST NOT be used for the purpose described in RFC 5705, in order to avoid confusion with similar, but distinct, use in RFC 5246.
注：（1）这些条目是保留的，不得用于RFC 5705中描述的目的，以避免与RFC 5246中类似但不同的用途混淆。
Future values are allocated via the RFC 5226 Specification Required policy. The label is a string consisting of printable ASCII characters. IANA MUST also verify that one label is not a prefix of any other label. For example, labels "key" or "master secretary" are forbidden.
未来值通过RFC 5226规范所需策略进行分配。标签是由可打印ASCII字符组成的字符串。IANA还必须验证一个标签不是任何其他标签的前缀。例如，禁止使用“钥匙”或“总秘书”标签。
Thanks to Pasi Eronen for valuable comments and for the contents of the IANA section and Section 3. Thanks to David McGrew for helpful discussion of the security considerations and to Vijay Gurbani and Alfred Hoenes for editorial comments.
感谢Pasi Eronen的宝贵意见以及IANA部分和第3部分的内容。感谢David McGrew对安全考虑的有益讨论，以及Vijay Gurbani和Alfred Hoenes的编辑评论。
[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月。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, February 2009.
[DTLS-SRTP]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，正在进行的工作，2009年2月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，2008年3月。
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5281]Funk，P.和S.Blake Wilson，“可扩展认证协议隧道传输层安全认证协议版本0（EAP-TTLSv0）”，RFC 52812008年8月。
Author's Address
作者地址
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
Eric Rescorla RTFM，Inc.美国加利福尼亚州帕洛阿尔托埃奇伍德大道2064号，邮编94303
EMail: ekr@rtfm.com
EMail: ekr@rtfm.com