[要約] RFC 5705は、Transport Layer Security (TLS) プロトコルにおけるキー素材エクスポーターに関する仕様を定義しています。この文書の目的は、TLS接続から追加のキー素材を安全に導出するための標準的な方法を提供することにあります。これは、例えば、異なるセキュリティプロトコル間でキー素材を共有する場合や、アプリケーションレイヤーでの特定のセキュリティ要件を満たすために利用されます。関連するRFCには、TLSの基本を定義するRFC 5246（TLS 1.2）や、後続のTLSバージョンを扱うRFC 8446（TLS 1.3）などがあります。RFC 5705は、TLSのセキュリティを拡張し、柔軟なキー管理を可能にする重要な役割を果たします。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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 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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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
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（DTLS）[RFC4347]を活用して、重要な確立を実行し、その後、自分の目的にキーイング素材の一部を使用したいと考えています。典型的な例は、DTLS-SRTP [DTLS-SRTP]です。これは、DTLSを使用してキーエクスチェンジを実行し、SRTP [RFC3711]保護スイートを交渉し、DTLSを使用する安全なリアルタイムトランスポートプロトコル（SRTP）の主要な管理スキームです。SRTPキーを生成するMaster_Secret。
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:
これらのアプリケーションは、キーイング材料（後にエクスポートキーイング材料またはEKMと呼ばれる）をTLS/DTLから上層層に存在するアプリケーションまたはプロトコルにエクスポートできる必要があることを意味し、キーイング材料が上層層のコンテキストに安全に同意することを意味します使用されます。キーイング材料をエクスポートするメカニズムには、次の要件があります。
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 EKMの値は、Master_Secretを知らない攻撃者にランダムデータと区別できない必要があります。
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 1つのEKM値を知ることは、Master_Secretまたは他の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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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).
コンテキストがどのように合意されていても、どのアプリケーションがエクスポートキーを使用するかを示す部分が1つあることが必要です。この部分は、曖昧性のあるラベル文字列です（セクション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:
輸出者は3つの入力値を取得します。
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_secret、label、securityparameters.client_random securityparameters.server_random）[length]
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_secret、label、securityparameters.client_random securityparameters.server_random context_value_length context_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 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.
ここのラベルは、TLSと同じ定義、つまり終端nullのないASCII文字列です。「実験」から始まるラベル値は、登録なしでプライベート使用に使用できます。他のすべてのラベル値は、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と輸出入出力を組み合わせることができます。これが役立つ可能性のある場所の1つの例は、クライアントの資格情報が複数のIDに対して有効である認証設定です。次に、コンテキスト値を使用して、予想されるアイデンティティをキーイング材料に組み合わせて、置換攻撃を防ぐことができます。コンテキスト値の長さは、コンテキスト値の長さを表す、署名のない16ビット量（UINT16; [RFC5246]、セクション4.4を参照）としてエンコードされます。コンテキストは長さがゼロになる場合があります。Context値はPRFを介してMaster_Secretと混合されるため、Master_Secretが攻撃者に知られていない場合、機密情報を輸出業者に混ぜることは安全です。
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で説明されているような設定がある場合があります。そのような攻撃者は、輸出者の出力を予測できてはなりません。同様に、マスターシークレットを知らない攻撃者は、有効な輸出者出力をランダム値と区別することができないはずです。Master Secretがランダムに生成された場合、TLS PRFSの現在のセットはこの目的を満たすと考えられています。
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.
輸出者は同じ値を同じラベルで2回適用すると同じ値を生成するため、同じラベルで生成された2つのEKM値を2つの異なる目的に使用しないことが重要です。したがって、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 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暗号スイートを使用すると、TLSマスターシークレットは必ずしも単一のTLSセッションに固有のものではありません。特に、RSA Key Exchangeを使用すると、1つのセッションでTLSサーバーとして機能する悪意のあるパーティー、および別のセッションでTLSクライアントとして、これらの2つのセッションが同じ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 Exporterラベルレジストリを作成しました。レジストリの最初の内容を以下に示します。
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 5246での同様の、しかし明確な使用との混乱を避けるために、RFC 5705で説明されている目的に使用してはなりません。
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は、1つのラベルが他のラベルのプレフィックスではないことを確認する必要があります。たとえば、ラベル「キー」または「マスターセクレタリー」は禁止されています。
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の内容について感謝します。DavidMcGrewは、セキュリティに関する考慮事項について有益な議論をしてくれてありがとう、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、「The Transport Layer Security（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、「Datagram Transport Layer Security（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、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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 5281、2008年8月。
Author's Address
著者の連絡先
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
Eric Rescorla RTFM、Inc。2064 Edgewood Drive Palo Alto、CA 94303 USA
EMail: ekr@rtfm.com