RFC 8773 - TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8773.html
タイトル : RFC 8773 - 外部事前共有キーを使用した証明書ベースの認証のためのTLS 1.3拡張
翻訳編集 : 自動生成

[要約] RFC 8773は、TLS 1.3での証明書ベースの認証に外部の事前共有キーを使用するための拡張機能です。その目的は、証明書ベースの認証と事前共有キーを組み合わせることで、より強力なセキュリティを提供することです。

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 8773                                Vigil Security
Category: Experimental                                        March 2020
ISSN: 2070-1721

TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key

外部事前共有キーを使用した証明書ベースの認証のためのTLS 1.3拡張

Abstract

概要

This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK).

このドキュメントでは、サーバーが証明書と外部事前共有キー（PSK）の組み合わせで認証できるようにするTLS 1.3拡張を指定しています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8773.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8773で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

1. Introduction 2. Terminology 3. Motivation and Design Rationale 4. Extension Overview 5. Certificate with External PSK Extension 5.1. Companion Extensions 5.2. Authentication 5.3. Keying Material 6. IANA Considerations 7. Security Considerations 8. Privacy Considerations 9. References 9.1. Normative References 9.2. Informative References Acknowledgments Author's Address

1. はじめに2.用語3.動機と設計の根拠4.拡張の概要5.外部PSK拡張を使用した証明書5.1。コンパニオンエクステンション5.2。認証5.3。キーイングマテリアル6. IANAの考慮事項7.セキュリティの考慮事項8.プライバシーの考慮事項9.参考資料9.1。規範的な参考文献9.2。参考情報謝辞著者のアドレス

1. Introduction

1. はじめに

The TLS 1.3 [RFC8446] handshake protocol provides two mutually exclusive forms of server authentication. First, the server can be authenticated by providing a signature certificate and creating a valid digital signature to demonstrate that it possesses the corresponding private key. Second, the server can be authenticated by demonstrating that it possesses a pre-shared key (PSK) that was established by a previous handshake. A PSK that is established in this fashion is called a resumption PSK. A PSK that is established by any other means is called an external PSK. This document specifies a TLS 1.3 extension permitting certificate-based server authentication to be combined with an external PSK as an input to the TLS 1.3 key schedule.

TLS 1.3 [RFC8446]ハンドシェイクプロトコルは、2つの相互に排他的な形式のサーバー認証を提供します。第1に、サーバーは、署名証明書を提供し、対応する秘密鍵を所有していることを示す有効なデジタル署名を作成することによって認証されます。 2番目に、サーバーは、以前のハンドシェイクによって確立された事前共有キー（PSK）を所有していることを証明することによって認証されます。この方法で確立されたPSKは、再開PSKと呼ばれます。他の方法で確立されたPSKは、外部PSKと呼ばれます。このドキュメントでは、証明書ベースのサーバー認証を外部PSKと組み合わせてTLS 1.3キースケジュールへの入力として許可するTLS 1.3拡張を指定しています。

Several implementors wanted to gain more experience with this specification before producing a Standards Track RFC. As a result, this specification is being published as an Experimental RFC to enable interoperable implementations and gain deployment and operational experience.

いくつかの実装者は、Standards Track RFCを作成する前に、この仕様についてより多くの経験を得たいと考えていました。その結果、この仕様は実験的なRFCとして公開され、相互運用可能な実装を可能にし、展開と運用の経験を得ることができます。

2. Terminology

2. 用語

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Motivation and Design Rationale

3. 動機と設計の根拠

The development of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today, including the digital signature algorithms that are used to authenticate the server in the TLS 1.3 handshake protocol. It is an open question whether or not it is feasible to build a large-scale quantum computer, and if so, when that might happen. However, if such a quantum computer is invented, many of the cryptographic algorithms and the security protocols that use them would become vulnerable.

大規模な量子コンピューターの開発は、TLS 1.3ハンドシェイクプロトコルでサーバーを認証するために使用されるデジタル署名アルゴリズムを含む、今日広く展開されている暗号化アルゴリズムに深刻な課題をもたらすでしょう。大規模な量子コンピューターを構築することが可能であるかどうか、また可能である場合、それがいつ起こるかは未解決の問題です。ただし、このような量子コンピューターが発明された場合、暗号化アルゴリズムとそれらを使用するセキュリティプロトコルの多くが脆弱になります。

The TLS 1.3 handshake protocol employs key agreement algorithms and digital signature algorithms that could be broken by the development of a large-scale quantum computer [TRANSITION]. The key agreement algorithms include Diffie-Hellman (DH) [DH1976] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital signature algorithms include RSA [RFC8017] and the Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS186]. As a result, an adversary that stores a TLS 1.3 handshake protocol exchange today could decrypt the associated encrypted communications in the future when a large-scale quantum computer becomes available.

TLS 1.3ハンドシェイクプロトコルは、大規模な量子コンピューター[TRANSITION]の開発によって破られる可能性がある鍵合意アルゴリズムとデジタル署名アルゴリズムを採用しています。主要な合意アルゴリズムには、Diffie-Hellman（DH）[DH1976]およびElliptic Curve Diffie-Hellman（ECDH）[IEEE1363]が含まれます。デジタル署名アルゴリズムには、RSA [RFC8017]と楕円曲線デジタル署名アルゴリズム（ECDSA）[FIPS186]が含まれます。その結果、今日のTLS 1.3ハンドシェイクプロトコル交換を格納する攻撃者は、大規模な量子コンピューターが利用可能になったときに、関連する暗号化通信を解読する可能性があります。

In the near term, this document describes a TLS 1.3 extension to protect today's communications from the future invention of a large-scale quantum computer by providing a strong external PSK as an input to the TLS 1.3 key schedule while preserving the authentication provided by the existing certificate and digital signature mechanisms.

近い将来、このドキュメントは、TLS 1.3キー拡張への入力として強力な外部PSKを提供することにより、今日の通信を将来の大規模量子コンピューターの発明から保護するTLS 1.3拡張について説明します。証明書およびデジタル署名メカニズム。

4. Extension Overview

4. 拡張の概要

This section provides a brief overview of the "tls_cert_with_extern_psk" extension.

このセクションでは、「tls_cert_with_extern_psk」拡張機能の概要を説明します。

The client includes the "tls_cert_with_extern_psk" extension in the ClientHello message. The "tls_cert_with_extern_psk" extension MUST be accompanied by the "key_share", "psk_key_exchange_modes", and "pre_shared_key" extensions. The client MAY also find it useful to include the "supported_groups" extension. Since the "tls_cert_with_extern_psk" extension is intended to be used only with initial handshakes, it MUST NOT be sent alongside the "early_data" extension. These extensions are all described in Section 4.2 of [RFC8446], which also requires the "pre_shared_key" extension to be the last extension in the ClientHello message.

クライアントは、ClientHelloメッセージに「tls_cert_with_extern_psk」拡張を含めます。「tls_cert_with_extern_psk」拡張には、「key_share」、「psk_key_exchange_modes」、「pre_shared_key」拡張が付随している必要があります。クライアントは、「supported_groups」拡張機能を含めることも役立つ場合があります。「tls_cert_with_extern_psk」拡張は、初期ハンドシェイクでのみ使用することを目的としているため、「early_data」拡張と一緒に送信してはなりません。これらの拡張機能はすべて[RFC8446]のセクション4.2で説明されており、ClientHelloメッセージの最後の拡張機能には「pre_shared_key」拡張機能も必要です。

If the client includes both the "tls_cert_with_extern_psk" extension and the "early_data" extension, then the server MUST terminate the connection with an "illegal_parameter" alert.

クライアントに「tls_cert_with_extern_psk」拡張と「early_data」拡張の両方が含まれている場合、サーバーは「illegal_parameter」アラートで接続を終了する必要があります。

If the server is willing to use one of the external PSKs listed in the "pre_shared_key" extension and perform certificate-based authentication, then the server includes the "tls_cert_with_extern_psk" extension in the ServerHello message. The "tls_cert_with_extern_psk" extension MUST be accompanied by the "key_share" and "pre_shared_key" extensions. If none of the external PSKs in the list provided by the client is acceptable to the server, then the "tls_cert_with_extern_psk" extension is omitted from the ServerHello message.

サーバーが「pre_shared_key」拡張にリストされている外部PSKの1つを使用して証明書ベースの認証を実行する場合、サーバーはServerHelloメッセージに「tls_cert_with_extern_psk」拡張を含めます。「tls_cert_with_extern_psk」拡張には、「key_share」および「pre_shared_key」拡張が付随している必要があります。クライアントから提供されたリスト内のどの外部PSKもサーバーに受け入れられない場合、「tls_cert_with_extern_psk」拡張はServerHelloメッセージから省略されます。

When the "tls_cert_with_extern_psk" extension is successfully negotiated, the TLS 1.3 key schedule processing includes both the selected external PSK and the (EC)DHE shared secret value. (EC)DHE refers to Diffie-Hellman over either finite fields or elliptic curves. As a result, the Early Secret, Handshake Secret, and Master Secret values all depend upon the value of the selected external PSK. Of course, the Early Secret does not depend upon the (EC)DHE shared secret.

「tls_cert_with_extern_psk」拡張が正常にネゴシエートされると、TLS 1.3キースケジュール処理には、選択された外部PSKと（EC）DHE共有秘密値の両方が含まれます。（EC）DHEは、有限体または楕円曲線上のDiffie-Hellmanを指します。その結果、アーリーシークレット、ハンドシェイクシークレット、マスターシークレットの値はすべて、選択した外部PSKの値に依存します。もちろん、初期の秘密は（EC）DHE共有秘密に依存しません。

The authentication of the server and optional authentication of the client depend upon the ability to generate a signature that can be validated with the public key in their certificates. The authentication processing is not changed in any way by the selected external PSK.

サーバーの認証とクライアントのオプションの認証は、証明書の公開鍵で検証できる署名を生成する機能に依存します。認証処理は、選択した外部PSKによって変更されることはありません。

Each external PSK is associated with a single hash algorithm, which is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST be set when the PSK is established, with a default of SHA-256.

各外部PSKは、[RFC8446]のセクション4.2.11で必要な単一のハッシュアルゴリズムに関連付けられています。ハッシュアルゴリズムは、PSKが確立されるときに設定されなければならず、デフォルトはSHA-256です。

5. Certificate with External PSK Extension

5. 外部PSK拡張付きの証明書

This section specifies the "tls_cert_with_extern_psk" extension, which MAY appear in the ClientHello message and ServerHello message. It MUST NOT appear in any other messages. The "tls_cert_with_extern_psk" extension MUST NOT appear in the ServerHello message unless the "tls_cert_with_extern_psk" extension appeared in the preceding ClientHello message. If an implementation recognizes the "tls_cert_with_extern_psk" extension and receives it in any other message, then the implementation MUST abort the handshake with an "illegal_parameter" alert.

このセクションでは、「tls_cert_with_extern_psk」拡張を指定します。これは、ClientHelloメッセージとServerHelloメッセージに表示される場合があります。他のメッセージには表示されません。 "tls_cert_with_extern_psk"拡張は、先行するClientHelloメッセージに "tls_cert_with_extern_psk"拡張が現れない限り、ServerHelloメッセージに現れてはいけません（MUST NOT）。実装が「tls_cert_with_extern_psk」拡張を認識し、それを他のメッセージで受信する場合、実装は「illegal_parameter」アラートでハンドシェイクを中止する必要があります。

The general extension mechanisms enable clients and servers to negotiate the use of specific extensions. Clients request extended functionality from servers with the extensions field in the ClientHello message. If the server responds with a HelloRetryRequest message, then the client sends another ClientHello message as described in Section 4.1.2 of [RFC8446], including the same "tls_cert_with_extern_psk" extension as the original ClientHello message, or aborts the handshake.

一般的な拡張メカニズムにより、クライアントとサーバーは特定の拡張機能の使用について交渉できます。クライアントは、ClientHelloメッセージのextensionsフィールドを使用して、サーバーに拡張機能を要求します。サーバーがHelloRetryRequestメッセージで応答した場合、クライアントは[RFC8446]のセクション4.1.2で説明されているように、元のClientHelloメッセージと同じ「tls_cert_with_extern_psk」拡張を含む別のClientHelloメッセージを送信するか、ハンドシェイクを中止します。

Many server extensions are carried in the EncryptedExtensions message; however, the "tls_cert_with_extern_psk" extension is carried in the ServerHello message. Successful negotiation of the "tls_cert_with_extern_psk" extension affects the key used for encryption, so it cannot be carried in the EncryptedExtensions message. Therefore, the "tls_cert_with_extern_psk" extension is only present in the ServerHello message if the server recognizes the "tls_cert_with_extern_psk" extension and the server possesses one of the external PSKs offered by the client in the "pre_shared_key" extension in the ClientHello message.

多くのサーバーエクステンションがEncryptedExtensionsメッセージに含まれています。ただし、「tls_cert_with_extern_psk」拡張機能はServerHelloメッセージで伝達されます。「tls_cert_with_extern_psk」拡張のネゴシエーションが成功すると、暗号化に使用されるキーに影響が及ぶため、EncryptedExtensionsメッセージで伝達することはできません。したがって、「tls_cert_with_extern_psk」拡張は、サーバーが「tls_cert_with_extern_psk」拡張を認識し、サーバーがClientHelloメッセージの「pre_shared_key」拡張でクライアントが提供する外部PSKの1つを所有している場合、ServerHelloメッセージにのみ存在します。

The Extension structure is defined in [RFC8446]; it is repeated here for convenience.

拡張構造は[RFC8446]で定義されています。便宜上、ここで繰り返します。

     struct {
         ExtensionType extension_type;
         opaque extension_data<0..2^16-1>;
     } Extension;

The "extension_type" identifies the particular extension type, and the "extension_data" contains information specific to the particular extension type.

「extension_type」は特定の拡張タイプを識別し、「extension_data」は特定の拡張タイプに固有の情報を含みます。

This document specifies the "tls_cert_with_extern_psk" extension, adding one new type to ExtensionType:

このドキュメントでは、「tls_cert_with_extern_psk」拡張を指定して、ExtensionTypeに新しいタイプを1つ追加しています。

     enum {
         tls_cert_with_extern_psk(33), (65535)
     } ExtensionType;

The "tls_cert_with_extern_psk" extension is relevant when the client and server possess an external PSK in common that can be used as an input to the TLS 1.3 key schedule. The "tls_cert_with_extern_psk" extension is essentially a flag to use the external PSK in the key schedule, and it has the following syntax:

「tls_cert_with_extern_psk」拡張は、クライアントとサーバーが共通して、TLS 1.3鍵スケジュールへの入力として使用できる外部PSKを所有している場合に関連します。「tls_cert_with_extern_psk」拡張機能は、基本的に、キースケジュールで外部PSKを使用するためのフラグであり、次の構文を使用します。

     struct {
         select (Handshake.msg_type) {
             case client_hello: Empty;
             case server_hello: Empty;
         };
     } CertWithExternPSK;

5.1. Companion Extensions

5.1. コンパニオン拡張

Section 4 lists the extensions that are required to accompany the "tls_cert_with_extern_psk" extension. Most of those extensions are not impacted in any way by this specification. However, this section discusses the extensions that require additional consideration.

セクション4は、「tls_cert_with_extern_psk」拡張に付随する必要のある拡張の一覧です。これらの拡張機能のほとんどは、この仕様の影響を受けません。ただし、このセクションでは、追加の考慮が必要な拡張機能について説明します。

The "psk_key_exchange_modes" extension is defined in of Section 4.2.9 of [RFC8446]. The "psk_key_exchange_modes" extension restricts the use of both the PSKs offered in this ClientHello and those that the server might supply via a subsequent NewSessionTicket. As a result, when the "psk_key_exchange_modes" extension is included in the ClientHello message, clients MUST include psk_dhe_ke mode. In addition, clients MAY also include psk_ke mode to support a subsequent NewSessionTicket. When the "psk_key_exchange_modes" extension is included in the ServerHello message, servers MUST select the psk_dhe_ke mode for the initial handshake. Servers MUST select a key exchange mode that is listed by the client for subsequent handshakes that include the resumption PSK from the initial handshake.

「psk_key_exchange_modes」拡張機能は、[RFC8446]のセクション4.2.9で定義されています。「psk_key_exchange_modes」拡張は、このClientHelloで提供されるPSKと、サーバーが後続のNewSessionTicketを介して提供するPSKの両方の使用を制限します。その結果、「psk_key_exchange_modes」拡張がClientHelloメッセージに含まれている場合、クライアントはpsk_dhe_keモードを含める必要があります。さらに、クライアントは、後続のNewSessionTicketをサポートするためにpsk_keモードを含めることもできます（MAY）。「psk_key_exchange_modes」拡張がServerHelloメッセージに含まれている場合、サーバーは初期ハンドシェイクにpsk_dhe_keモードを選択する必要があります。サーバーは、最初のハンドシェイクからの再開PSKを含む後続のハンドシェイクに対して、クライアントによってリストされている鍵交換モードを選択する必要があります。

The "pre_shared_key" extension is defined in Section 4.2.11 of [RFC8446]. The syntax is repeated below for convenience. All of the listed PSKs MUST be external PSKs. If a resumption PSK is listed along with the "tls_cert_with_extern_psk" extension, the server MUST abort the handshake with an "illegal_parameter" alert.

「pre_shared_key」拡張機能は、[RFC8446]のセクション4.2.11で定義されています。便宜上、構文を以下に繰り返します。リストされているすべてのPSKは外部PSKでなければなりません。「tls_cert_with_extern_psk」拡張とともに再開PSKがリストされている場合、サーバーは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。

     struct {
         opaque identity<1..2^16-1>;
         uint32 obfuscated_ticket_age;
     } PskIdentity;

     opaque PskBinderEntry<32..255>;

     struct {
         PskIdentity identities<7..2^16-1>;
         PskBinderEntry binders<33..2^16-1>;
     } OfferedPsks;

     struct {
         select (Handshake.msg_type) {
             case client_hello: OfferedPsks;
             case server_hello: uint16 selected_identity;
         };
     } PreSharedKeyExtension;

"OfferedPsks" contains the list of PSK identities and associated binders for the external PSKs that the client is willing to use with the server.

「OfferedPsks」には、クライアントがサーバーで使用する予定の外部PSKのPSK IDと関連するバインダーのリストが含まれています。

The identities are a list of external PSK identities that the client is willing to negotiate with the server. Each external PSK has an associated identity that is known to the client and the server; the associated identities may be known to other parties as well. In addition, the binder validation (see below) confirms that the client and server have the same key associated with the identity.

IDは、クライアントがサーバーと交渉しようとする外部PSK IDのリストです。各外部PSKには、クライアントとサーバーが認識している関連付けられたIDがあります。関連するアイデンティティは他の当事者にも知られている可能性があります。さらに、バインダーの検証（以下を参照）は、クライアントとサーバーが同じキーがIDに関連付けられていることを確認します。

The "obfuscated_ticket_age" is not used for external PSKs. As stated in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0, and servers MUST ignore the value.

「obfuscated_ticket_age」は、外部PSKには使用されません。 [RFC8446]のセクション4.2.11で述べたように、クライアントはこの値を0に設定する必要があり（SHOULD）、サーバーはこの値を無視する必要があります（MUST）。

The binders are a series of HMAC [RFC2104] values, one for each external PSK offered by the client, in the same order as the identities list. The HMAC value is computed using the binder_key, which is derived from the external PSK, and a partial transcript of the current handshake. Generation of the binder_key from the external PSK is described in Section 7.1 of [RFC8446]. The partial transcript of the current handshake includes a partial ClientHello up to and including the PreSharedKeyExtension.identities field, as described in Section 4.2.11.2 of [RFC8446].

バインダーは一連のHMAC [RFC2104]値で、クライアントが提供する外部PSKごとに1つ、IDリストと同じ順序です。 HMAC値は、外部PSKから派生したバインダーキーと現在のハンドシェイクの部分的なトランスクリプトを使用して計算されます。外部PSKからのバインダーキーの生成については、[RFC8446]のセクション7.1で説明されています。 [RFC8446]のセクション4.2.11.2で説明されているように、現在のハンドシェイクの部分的なトランスクリプトには、PreSharedKeyExtension.identitiesフィールドまでの部分的なClientHelloが含まれています。

The "selected_identity" contains the index of the external PSK identity that the server selected from the list offered by the client. As described in Section 4.2.11 of [RFC8446], the server MUST validate the binder value that corresponds to the selected external PSK, and if the binder does not validate, the server MUST abort the handshake with an "illegal_parameter" alert.

「selected_identity」には、サーバーがクライアントから提供されたリストから選択した外部PSK IDのインデックスが含まれています。 [RFC8446]のセクション4.2.11で説明されているように、サーバーは選択された外部PSKに対応するバインダー値を検証する必要があり、バインダーが検証されない場合、サーバーは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。

5.2. Authentication

5.2. 認証

When the "tls_cert_with_extern_psk" extension is successfully negotiated, authentication of the server depends upon the ability to generate a signature that can be validated with the public key in the server's certificate. This is accomplished by the server sending the Certificate and CertificateVerify messages, as described in Sections 4.4.2 and 4.4.3 of [RFC8446].

「tls_cert_with_extern_psk」拡張が正常にネゴシエートされた場合、サーバーの認証は、サーバーの証明書の公開鍵で検証できる署名を生成する機能に依存します。これは、[RFC8446]のセクション4.4.2および4.4.3で説明されているように、サーバーがCertificateおよびCertificateVerifyメッセージを送信することで実現されます。

TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server. If certificate-based client authentication is desired, this is accomplished by the client sending the Certificate and CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 of [RFC8446].

TLS 1.3は、PSKが使用されている場合、サーバーがCertificateRequestメッセージを送信することを許可しません。この制限は、「tls_cert_with_extern_psk」拡張がネゴシエートされるときに削除され、クライアントとサーバーの両方で証明書ベースの認証が可能になります。 [RFC8446]のセクション4.4.2および4.4.3で説明されているように、証明書ベースのクライアント認証が必要な場合、これはクライアントがCertificateおよびCertificateVerifyメッセージを送信することによって行われます。

5.3. Keying Material

5.3. キーイングマテリアル

Section 7.1 of [RFC8446] specifies the TLS 1.3 key schedule. The successful negotiation of the "tls_cert_with_extern_psk" extension requires the key schedule processing to include both the external PSK and the (EC)DHE shared secret value.

[RFC8446]のセクション7.1は、TLS 1.3鍵スケジュールを指定しています。「tls_cert_with_extern_psk」拡張のネゴシエーションを成功させるには、外部PSKと（EC）DHE共有秘密値の両方を含めるための鍵スケジュール処理が必要です。

If the client and the server have different values associated with the selected external PSK identifier, then the client and the server will compute different values for every entry in the key schedule, which will lead to the client aborting the handshake with a "decrypt_error" alert.

クライアントとサーバーに、選択した外部PSK識別子に関連付けられた異なる値がある場合、クライアントとサーバーは、キースケジュールのすべてのエントリに対して異なる値を計算します。これにより、クライアントは「decrypt_error」アラートでハンドシェイクを中止します。。

6. IANA Considerations

6. IANAに関する考慮事項

IANA has updated the "TLS ExtensionType Values" registry [IANA] to include "tls_cert_with_extern_psk" with a value of 33 and the list of messages "CH, SH" in which the "tls_cert_with_extern_psk" extension may appear.

IANAは、「TLS ExtensionType Values」レジストリ[IANA]を更新して、「tls_cert_with_extern_psk」に値33と「tls_cert_with_extern_psk」拡張が表示される可能性のあるメッセージ「CH、SH」のリストを含めました。

7. Security Considerations

7. セキュリティに関する考慮事項

The Security Considerations in [RFC8446] remain relevant.

[RFC8446]のセキュリティに関する考慮事項は引き続き関連しています。

TLS 1.3 [RFC8446] does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is offered by the client and accepted by the server. However, TLS 1.3 does not permit an external PSK to be used in the same fashion as a resumption PSK, and this extension does not alter those restrictions. Thus, a certificate MUST NOT be used with a resumption PSK.

TLS 1.3 [RFC8446]は、PSKが使用されている場合、サーバーがCertificateRequestメッセージを送信することを許可しません。この制限は、「tls_cert_with_extern_psk」拡張機能がクライアントによって提供され、サーバーによって受け入れられると削除されます。ただし、TLS 1.3では、外部PSKを再開PSKと同じ方法で使用することは許可されておらず、この拡張機能によってこれらの制限が変更されることはありません。したがって、証明書は再開PSKで使用してはなりません（MUST NOT）。

Implementations must protect the external pre-shared key (PSK). Compromise of the external PSK will make the encrypted session content vulnerable to the future development of a large-scale quantum computer. However, the generation, distribution, and management of the external PSKs is out of scope for this specification.

実装では、外部事前共有キー（PSK）を保護する必要があります。外部PSKの侵害により、暗号化されたセッションコンテンツが、大規模な量子コンピューターの将来の開発に対して脆弱になります。ただし、外部PSKの生成、配布、および管理は、この仕様の範囲外です。

Implementers should not transmit the same content on a connection that is protected with an external PSK and a connection that is not. Doing so may allow an eavesdropper to correlate the connections, making the content vulnerable to the future invention of a large-scale quantum computer.

実装者は、外部PSKで保護されている接続と保護されていない接続で同じコンテンツを送信しないでください。そうすることで、盗聴者が接続を関連付けることができ、コンテンツが将来の大規模な量子コンピューターの発明に対して脆弱になる可能性があります。

Implementations must generate external PSKs with a secure key-management technique, such as pseudorandom generation of the key or derivation of the key from one or more other secure keys. The use of inadequate pseudorandom number generators (PRNGs) to generate external PSKs can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the external PSKs and search the resulting small set of possibilities, rather than brute-force searching the whole key space. The generation of quality random numbers is difficult. [RFC4086] offers important guidance in this area.

実装では、キーの疑似ランダム生成や1つ以上の他の安全なキーからのキーの派生など、安全なキー管理手法を使用して外部PSKを生成する必要があります。不適切な疑似乱数ジェネレータ（PRNG）を使用して外部PSKを生成すると、セキュリティがほとんど、またはまったくなくなる可能性があります。攻撃者は、キースペース全体をブルートフォースで検索するよりも、外部PSKを生成したPRNG環境を再現し、結果の可能性の小さなセットを検索する方がはるかに簡単であることに気付く場合があります。高品質の乱数の生成は困難です。 [RFC4086]は、この分野で重要なガイダンスを提供しています。

If the external PSK is known to any party other than the client and the server, then the external PSK MUST NOT be the sole basis for authentication. The reasoning is explained in Section 4.2 of [K2016]. When this extension is used, authentication is based on certificates, not the external PSK.

外部PSKがクライアントとサーバー以外の当事者に知られている場合、外部PSKが認証の唯一の基盤であってはなりません。推論は、[K2016]のセクション4.2で説明されています。この拡張機能を使用すると、認証は外部PSKではなく証明書に基づいて行われます。

In this extension, the external PSK preserves confidentiality if the (EC)DH key agreement is ever broken by cryptanalysis or the future invention of a large-scale quantum computer. As long as the attacker does not know the PSK and the key derivation algorithm remains unbroken, the attacker cannot derive the session secrets, even if they are able to compute the (EC)DH shared secret. Should the attacker be able compute the (EC)DH shared secret, the forward-secrecy advantages traditionally associated with ephemeral (EC)DH keys will no longer be relevant. Although the ephemeral private keys used during a given TLS session are destroyed at the end of a session, preventing the attacker from later accessing them, these private keys would nevertheless be recoverable due to the break in the algorithm. However, a more general notion of "secrecy after key material is destroyed" would still be achievable using external PSKs, if they are managed in a way that ensures their destruction when they are no longer needed, and with the assumption that the algorithms that use the external PSKs remain quantum-safe.

この拡張では、暗号解読または大規模量子コンピューターの将来の発明によって（EC）DH鍵合意が破られた場合、外部PSKは機密性を保持します。攻撃者がPSKを知らず、鍵導出アルゴリズムが壊れていない限り、攻撃者は（EC）DH共有秘密を計算できたとしても、セッション秘密を導出することはできません。攻撃者が（EC）DH共有シークレットを計算できる場合、従来は一時的な（EC）DHキーに関連付けられていた転送秘密の利点は、もはや関係がなくなります。特定のTLSセッション中に使用された一時的な秘密鍵はセッションの終わりに破棄され、攻撃者が後でそれらにアクセスできないようにしますが、これらの秘密鍵はアルゴリズムの破損により回復可能です。ただし、「主要な資料が破棄された後の機密性」というより一般的な概念は、外部PSKが不要になったときに確実に破棄できるように管理されていて、使用するアルゴリズムが外部PSKは量子安全なままです。

TLS 1.3 key derivation makes use of the HMAC-based Key Derivation Function (HKDF) algorithm, which depends upon the HMAC [RFC2104] construction and a hash function. This extension provides the desired protection for the session secrets, as long as HMAC with the selected hash function is a pseudorandom function (PRF) [GGM1986].

TLS 1.3鍵導出は、HMAC [RFC2104]の構築とハッシュ関数に依存するHMACベースの鍵導出関数（HKDF）アルゴリズムを利用します。この拡張機能は、選択されたハッシュ関数を備えたHMACが疑似ランダム関数（PRF）[GGM1986]である限り、セッションシークレットに必要な保護を提供します。

This specification does not require that the external PSK is known only by the client and server. The external PSK may be known to a group. Since authentication depends on the public key in a certificate, knowledge of the external PSK by other parties does not enable impersonation. Since confidentiality depends on the shared secret from (EC)DH, knowledge of the external PSK by other parties does not enable eavesdropping. However, group members can record the traffic of other members and then decrypt it if they ever gain access to a large-scale quantum computer. Also, when many parties know the external PSK, there are many opportunities for theft of the external PSK by an attacker. Once an attacker has the external PSK, they can decrypt stored traffic if they ever gain access to a large-scale quantum computer, in the same manner as a legitimate group member.

この仕様では、外部PSKがクライアントとサーバーだけに認識されている必要はありません。外部PSKはグループに知られている場合があります。認証は証明書の公開鍵に依存するため、他の当事者による外部PSKの知識は偽装を有効にしません。機密性は（EC）DHからの共有シークレットに依存するため、他の当事者による外部PSKの知識は盗聴を可能にしません。ただし、グループメンバーは、他のメンバーのトラフィックを記録し、大規模な量子コンピューターにアクセスできる場合はそれを復号化できます。また、多くの関係者が外部PSKを知っている場合、攻撃者による外部PSKの盗難の機会が多くあります。攻撃者が外部PSKを取得すると、正当なグループメンバーと同じ方法で、大規模な量子コンピューターにアクセスできれば、保存されたトラフィックを解読できます。

TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are bound to a specific hash function and KDF. By contrast, TLS 1.2 [RFC5246] allows PSKs to be used with any hash function and the TLS 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a PSK for exclusive use with TLS 1.2 and derive another PSK for exclusive use with TLS 1.3 using the mechanism specified in [IMPORT].

TLS 1.3 [RFC8446]は、PSKに対して保守的なアプローチを採用しています。それらは特定のハッシュ関数とKDFにバインドされています。対照的に、TLS 1.2 [RFC5246]では、PSKを任意のハッシュ関数とTLS 1.2 PRFで使用できます。したがって、最も安全なアプローチは、TLS 1.2でのみ、またはTLS 1.3でのみPSKを使用することです。 1つのPSKが与えられると、[IMPORT]で指定されたメカニズムを使用して、TLS 1.2専用のPSKを導出し、TLS 1.3専用の別のPSKを導出できます。

TLS 1.3 [RFC8446] has received careful security analysis, and the following informal reasoning shows that the addition of this extension does not introduce any security defects. This extension requires the use of certificates for authentication, but the processing of certificates is unchanged by this extension. This extension places an external PSK in the key schedule as part of the computation of the Early Secret. In the initial handshake without this extension, the Early Secret is computed as:

TLS 1.3 [RFC8446]は慎重なセキュリティ分析を受けており、次の非公式な推論は、この拡張機能を追加してもセキュリティ上の欠陥が発生しないことを示しています。この拡張では、認証に証明書を使用する必要がありますが、証明書の処理はこの拡張によって変更されていません。この拡張機能は、初期秘密の計算の一部として外部PSKを主要スケジュールに配置します。この拡張のない最初のハンドシェイクでは、アーリーシークレットは次のように計算されます。

Early Secret = HKDF-Extract(0, 0)

初期の秘密= HKDF-Extract（0、0）

With this extension, the Early Secret is computed as:

この拡張により、アーリーシークレットは次のように計算されます。

Early Secret = HKDF-Extract(External PSK, 0)

初期の秘密= HKDF-Extract（外部PSK、0）

Any entropy contributed by the external PSK can only make the Early Secret better; the External PSK cannot make it worse. For these two reasons, TLS 1.3 continues to meet its security goals when this extension is used.

外部のPSKによってもたらされたエントロピーは、アーリーシークレットをより良くするだけです。外部PSKはそれを悪化させることはできません。これらの2つの理由により、TLS 1.3は、この拡張機能を使用しても、引き続きセキュリティ目標を満たします。

8. Privacy Considerations

8. プライバシーに関する考慮事項

Appendix E.6 of [RFC8446] discusses identity-exposure attacks on PSKs. The guidance in this section remains relevant.

[RFC8446]の付録E.6は、PSKに対するID公開攻撃について説明しています。このセクションのガイダンスは引き続き適切です。

This extension makes use of external PSKs to improve resilience against attackers that gain access to a large-scale quantum computer in the future. This extension is always accompanied by the "pre_shared_key" extension to provide the PSK identities in plaintext in the ClientHello message. Passive observation of the these PSK identities will aid an attacker in tracking users of this extension.

この拡張機能は、外部のPSKを利用して、将来大規模な量子コンピューターにアクセスする攻撃者に対する回復力を向上させます。この拡張機能には、常に「pre_shared_key」拡張機能が付いており、ClientHelloメッセージでPSK IDをプレーンテキストで提供します。これらのPSK IDの受動的な監視は、攻撃者がこの拡張機能のユーザーを追跡するのに役立ちます。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。

9.2. Informative References

9.2. 参考引用

[DH1976] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol. 22, No. 6, DOI 10.1109/TIT.1976.1055638, November 1976, <https://ieeexplore.ieee.org/document/1055638>.

[DH1976] Diffie、W。およびM. Hellman、「暗号化の新しい方向性」、IEEE Transactions on Information Theory、Vol。 22、No。6、DOI 10.1109 / TIT.1976.1055638、1976年11月、<https://ieeexplore.ieee.org/document/1055638>。

[FIPS186] NIST, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication (FIPS) 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://doi.org/10.6028/NIST.FIPS.186-4>.

[FIPS186] NIST、「デジタル署名標準（DSS）」、連邦情報処理標準公開（FIPS）186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月、<https://doi.org/10.6028 /NIST.FIPS.186-4>。

[GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to construct random functions", Journal of the ACM, Vol. 33, No. 4, pp. 792-807, DOI 10.1145/6490.6503, August 1986, <https://doi.org/10.1145/6490.6503>.

[GGM1986] Goldreich、O.、Goldwasser、S。、およびS. Micali、「ランダム関数の作成方法」、ACMジャーナル、Vol。 33、No. 4、pp。792-807、DOI 10.1145 / 6490.6503、August 1986、<https://doi.org/10.1145/6490.6503>。

[IANA] IANA, "TLS ExtensionType Values", <https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml>.

[IANA] IANA、「TLS ExtensionType Values」、<https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml>。

[IEEE1363] IEEE, "IEEE Standard Specifications for Public-Key Cryptography", IEEE Std 1363-2000, DOI 10.1109/IEEESTD.2000.92292, August 2000, <https://ieeexplore.ieee.org/document/891000>.

[IEEE1363] IEEE、「IEEE Standard Specifications for Public-Key Cryptography」、IEEE Std 1363-2000、DOI 10.1109 / IEEESTD.2000.92292、August 2000、<https://ieeexplore.ieee.org/document/891000>。

[IMPORT] Benjamin, D. and C. Wood, "Importing External PSKs for TLS", Work in Progress, Internet-Draft, draft-ietf-tls-external-psk-importer-03, 15 February 2020, <https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-03>.

[インポート]ベンジャミン、D.、C。ウッド、「TLSの外部PSKのインポート」、作業中、インターネットドラフト、draft-ietf-tls-external-psk-importer-03、2020年2月15日、<https：/ /tools.ietf.org/html/draft-ietf-tls-external-psk-importer-03>。

[K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3)", CCS '16: Proceedings of the 2016 ACM Communications Security, pp. 1438-50, DOI 10.1145/2976749.2978325, October 2016, <https://dl.acm.org/doi/10.1145/2976749.2978325>.

[K2016] Krawczyk、H。、「鍵交換用の一方的な相互認証コンパイラ（TLS 1.3でのアプリケーションからクライアントへの認証を使用）」、CCS '16：Proceedings of the 2016 ACM Communications Security、pp。1438-50、 DOI 10.1145 / 2976749.2978325、2016年10月、<https://dl.acm.org/doi/10.1145/2976749.2978325>。

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.

[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-editor .org / info / rfc2104>。

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<https：//www.rfc-editor .org / info / rfc4086>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。

[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.

[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J。、およびA. Rusch、「PKCS＃1：RSA Cryptography Specifications Version 2.2」、RFC 8017、DOI 10.17487 / RFC8017、2016年11月、< https://www.rfc-editor.org/info/rfc8017>。

[TRANSITION] Hoffman, P., "The Transition from Classical to Post-Quantum Cryptography", Work in Progress, Internet-Draft, draft-hoffman-c2pq-06, 25 November 2019, <https://tools.ietf.org/html/draft-hoffman-c2pq-06>.

[移行]ホフマン、P。、「古典からポスト量子暗号への移行」、進行中の作業、インターネットドラフト、draft-hoffman-c2pq-06、2019年11月25日、<https://tools.ietf.org / html / draft-hoffman-c2pq-06>。

Acknowledgments

謝辞

Many thanks to Liliya Akhmetzyanova, Roman Danyliw, Christian Huitema, Ben Kaduk, Geoffrey Keating, Hugo Krawczyk, Mirja Kühlewind, Nikos Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee for their review and comments; their efforts have improved this document.

Liliya Akhmetzyanova、Roman Danyliw、Christian Huitema、Ben Kaduk、Geoffrey Keating、Hugo Krawczyk、MirjaKühlewind、Nikos Mavrogiannopoulos、Nick Sullivan、Martin Thomson、Peter Yeeのレビューとコメントに感謝します。彼らの努力はこの文書を改善しました。

Author's Address

著者のアドレス

Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 United States of America

Russ Housley Vigil Security、LLC 516 Dranesville Road Herndon、VA 20170アメリカ合衆国

   Email: housley@vigilsec.com