[要約] RFC 9257は、TLS 1.3での外部Pre-Shared Key（PSK）の使用に関するガイダンスを提供し、PSKのセキュリティ特性と攻撃への対処方法を示しています。アプリケーションがこれらの前提条件を満たすためのアドバイスや、PSKの使用事例やプロビジョニングプロセスについても議論しています。
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 9257 Vigil Security
Category: Informational J. Hoyland
ISSN: 2070-1721 Cloudflare Ltd.
M. Sethi
Aalto University
C. A. Wood
Cloudflare
July 2022
Guidance for External Pre-Shared Key (PSK) Usage in TLS
TLSでの外部共有キー（PSK）使用法のガイダンス
Abstract
概要
This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used.
このドキュメントは、RFC 8446で定義されている輸送層セキュリティ（TLS）1.3の外部事前共有キー（PSK）の使用ガイダンスを提供します。特定の仮定の下でPSKが提供するTLSセキュリティプロパティをリストし、これらの仮定の違反がどのように違反するかを示しています。攻撃。これらの仮定を満たすのに役立つアプリケーションへのアドバイスが提供されます。このドキュメントでは、PSKのユースケースとプロビジョニングプロセスについても説明します。最後に、外部PSKが使用されているときにTLS 1.3によって提供されないプライバシーとセキュリティプロパティをリストします。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc9257.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9257で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Conventions and Definitions
3. Notation
4. PSK Security Properties
4.1. Shared PSKs
4.2. PSK Entropy
5. External PSKs in Practice
5.1. Use Cases
5.2. Provisioning Examples
5.3. Provisioning Constraints
6. Recommendations for External PSK Usage
6.1. Stack Interfaces
6.1.1. PSK Identity Encoding and Comparison
6.1.2. PSK Identity Collisions
7. Privacy Considerations
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
This document provides guidance on the use of external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 [RFC8446]. This guidance also applies to Datagram TLS (DTLS) 1.3 [RFC9147] and Compact TLS 1.3 [CTLS]. For readability, this document uses the term "TLS" to refer to all such versions.
このドキュメントは、輸送層セキュリティ（TLS）1.3 [RFC8446]での外部の事前共有キー（PSK）の使用に関するガイダンスを提供します。このガイダンスは、データグラムTLS（DTLS）1.3 [RFC9147]およびコンパクトTLS 1.3 [CTLS]にも適用されます。読みやすさのために、このドキュメントでは「TLS」という用語を使用して、そのようなすべてのバージョンを参照します。
External PSKs are symmetric secret keys provided to the TLS protocol implementation as external inputs. External PSKs are provisioned out of band.
外部PSKは、TLSプロトコルの実装に外部入力として提供される対称シークレットキーです。外部PSKはバンドからプロビジョニングされます。
This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions. This document also provides advice for applications in various use cases to help meet these assumptions.
このドキュメントには、特定の仮定の下でPSKが提供するTLSセキュリティプロパティがリストされており、これらの仮定の違反が攻撃にどのようにつながるかを示しています。このドキュメントでは、これらの仮定のコンテキストでのPSKユースケース、プロビジョニングプロセス、およびTLSスタック実装サポートについて説明します。このドキュメントは、これらの仮定を満たすのに役立つさまざまなユースケースでのアプリケーションへのアドバイスも提供します。
There are many resources that provide guidance for password generation and verification aimed towards improving security. However, there is no such equivalent for external PSKs in TLS. This document aims to reduce that gap.
セキュリティの改善を目的としたパスワードの生成と検証のガイダンスを提供する多くのリソースがあります。ただし、TLSの外部PSKに相当するものはありません。このドキュメントは、そのギャップを減らすことを目的としています。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
For purposes of this document, a "logical node" is a computing presence that other parties can interact with via the TLS protocol. A logical node could potentially be realized with multiple physical instances operating under common administrative control, e.g., a server farm. An "endpoint" is a client or server participating in a connection.
このドキュメントの目的のために、「論理ノード」は、他の関係者がTLSプロトコルを介して対話できるコンピューティングの存在です。論理ノードは、一般的な管理制御の下で動作する複数の物理的インスタンス、例えばサーバーファームで実現する可能性があります。「エンドポイント」は、接続に参加するクライアントまたはサーバーです。
The use of a previously established PSK allows TLS nodes to authenticate the endpoint identities. It also offers other benefits, including resistance to attacks in the presence of quantum computers; see Section 4.2 for related discussion. However, these keys do not provide privacy protection of endpoint identities, nor do they provide non-repudiation (one endpoint in a connection can deny the conversation); see Section 7 for related discussion.
以前に確立されたPSKを使用すると、TLSノードがエンドポイントのアイデンティティを認証することができます。また、量子コンピューターの存在下での攻撃に対する抵抗など、他の利点も提供します。関連する議論については、セクション4.2を参照してください。ただし、これらのキーはエンドポイントのアイデンティティのプライバシー保護を提供するものではなく、非repudiationを提供しません（接続中の1つのエンドポイントは会話を否定できます）。関連する議論については、セクション7を参照してください。
PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server and they never switch roles. If this assumption is violated, then the security properties of TLS are severely weakened as discussed below.
PSK認証セキュリティは、1つの基本的なプロパティを暗黙的に想定しています。各PSKは正確に1つのクライアントと1つのサーバーに知られており、役割を切り替えることはありません。この仮定が違反している場合、以下で説明するように、TLSのセキュリティプロパティは著しく弱くなります。
As discussed in Section 5.1, to demonstrate their attack, [AASS19] describes scenarios where multiple clients or multiple servers share a PSK. If this is done naively by having all members share a common key, then TLS authenticates only group membership, and the security of the overall system is inherently rather brittle. There are a number of obvious weaknesses here:
セクション5.1で説明したように、攻撃を実証するために、[AASS19]は、複数のクライアントまたは複数のサーバーがPSKを共有するシナリオについて説明しています。これがすべてのメンバーに共通のキーを共有させることによって素朴に行われた場合、TLSはグループメンバーシップのみを認証し、システム全体のセキュリティは本質的にかなり脆弱です。ここには多くの明らかな弱点があります：
1. Any group member can impersonate any other group member.
1. グループメンバーは、他のグループメンバーになりすますことができます。
2. If a PSK is combined with the result of a fresh ephemeral key exchange, then compromise of a group member that knows the resulting shared secret will enable the attacker to passively read traffic (and actively modify it).
2. PSKが新鮮な一時的なキーエクスチェンジの結果と組み合わされている場合、結果として生じる共有秘密を知っているグループメンバーの妥協により、攻撃者はトラフィックを受動的に読み取ることができます（そして積極的にそれを変更します）。
3. If a PSK is not combined with the result of a fresh ephemeral key exchange, then compromise of any group member allows the attacker to passively read all traffic (and actively modify it), including past traffic.
3. PSKが新鮮な短命のキーエクスチェンジの結果と組み合わされていない場合、グループメンバーの妥協により、攻撃者は過去のトラフィックを含むすべてのトラフィックを受動的に読み取る（そして積極的に変更する）ことができます。
Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described below. Note that a partial mitigation for this class of attack is available: each group member includes the Server Name Indication (SNI) extension [RFC6066] and terminates the connection on mismatch between the presented SNI value and the receiving member's known identity. See [Selfie] for details.
さらに、悪意のある非会員は、以下で説明するように、正直なグループメンバー間の握手を握手して、意図しない方法でそれらを接続することができます。このクラスの攻撃の部分緩和が利用可能であることに注意してください。各グループメンバーには、サーバー名表示（SNI）拡張[RFC6066]が含まれ、提示されたSNI値と受信メンバーの既知のIDとの間の不一致の接続を終了します。詳細については、[自撮り]を参照してください。
To illustrate the rerouting attack, consider three peers, A, B, and C, who all know the PSK. The attack proceeds as follows:
再ルーティング攻撃を説明するには、PSKを知っている3人のピアA、B、およびCを検討してください。攻撃は次のように進行します：
1. A sends a ClientHello to B.
1. a clienthelloをBに送信します
2. The attacker intercepts the message and redirects it to C.
2. 攻撃者はメッセージを傍受し、それをCにリダイレクトします
3. C responds with a second flight (ServerHello, ...) to A.
3. Cは2回目のフライト（ServerHello、...）でAに応答します。
4. A sends a Finished message to B. A has completed the handshake, ostensibly with B.
4. Aは完成したメッセージをBに送信します。Aは、表面上はBで握手を完了しました。
5. The attacker redirects the Finished message to C. C has completed the handshake with A.
5. 攻撃者は、完成したメッセージをCにリダイレクトします。CはAで握手を完了しました。
In this attack, peer authentication is not provided. Also, if C supports a weaker set of ciphersuites than B, cryptographic algorithm downgrade attacks might be possible. This rerouting is a type of identity misbinding attack [Krawczyk] [Sethi]. Selfie attack [Selfie] is a special case of the rerouting attack against a group member that can act as both a TLS server and a client. In the Selfie attack, a malicious non-member reroutes a connection from the client to the server on the same endpoint.
この攻撃では、ピア認証は提供されていません。また、CがBよりも弱い暗号筋のセットをサポートする場合、暗号化アルゴリズムのダウングレード攻撃が可能になる可能性があります。この再ルーティングは、アイデンティティの誤攻撃の一種です[Krawczyk] [sethi]。Selfie Attack [Selfie]は、TLSサーバーとクライアントの両方として機能できるグループメンバーに対する再ルーティング攻撃の特別なケースです。セルフィー攻撃では、悪意のある非会員が同じエンドポイントでクライアントからサーバーへの接続を再ルーティングします。
Finally, in addition to these weaknesses, sharing a PSK across nodes may negatively affect deployments. For example, revocation of individual group members is not possible without establishing a new PSK for all of the members that have not been revoked.
最後に、これらの弱点に加えて、ノード間でPSKを共有すると、展開に悪影響を与える可能性があります。たとえば、個々のグループメンバーの取り消しは、取り消されていないすべてのメンバーに新しいPSKを確立することなく不可能です。
Entropy properties of external PSKs may also affect TLS security properties. For example, if a high-entropy PSK is used, then PSK-only key establishment modes provide expected security properties for TLS, including establishment of the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection. See Appendix E.1 of [RFC8446] for an explanation of these properties. However, these modes lack forward security. Forward security may be achieved by using a PSK-DH mode or by using PSKs with short lifetimes.
外部PSKのエントロピー特性は、TLSセキュリティプロパティにも影響する場合があります。たとえば、高エントロピーPSKを使用する場合、PSKのみのキー設立モードは、ピア間の同じセッションキーの確立、セッションキーの秘密、ピア認証、ダウングレード保護など、TLSの予想されるセキュリティプロパティを提供します。これらの特性の説明については、[RFC8446]の付録E.1を参照してください。ただし、これらのモードには前向きなセキュリティがありません。PSK-DHモードを使用するか、寿命が短いPSKを使用することにより、フォワードセキュリティを実現できます。
In contrast, if a low-entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search attacks, which will reveal the traffic keys. PSK-DH modes are subject to active attacks in which the attacker impersonates one side. The exhaustive search phase of these attacks can be mounted offline if the attacker captures a single handshake using the PSK, but those attacks will not lead to compromise of the traffic keys for that connection because those also depend on the Diffie-Hellman (DH) exchange. Low-entropy keys are only secure against active attack if a Password-Authenticated Key Exchange (PAKE) is used with TLS. At the time of writing, the Crypto Forum Research Group (CFRG) is working on specifying recommended PAKEs (see [CPACE] and [OPAQUE] for the symmetric and asymmetric cases, respectively).
対照的に、低エントロピーPSKを使用する場合、PSKのみの主要な確立モードは、トラフィックキーを明らかにする受動的な徹底的な検索攻撃の対象となります。PSK-DHモードは、攻撃者が片側になりすましているアクティブな攻撃の対象となります。これらの攻撃の徹底的な検索フェーズは、攻撃者がPSKを使用して単一の握手をキャプチャする場合、オフラインにすることができますが、これらの攻撃は、Diffie-Hellman（DH）Exchangeにも依存するため、その接続のトラフィックキーの妥協につながることはありません。。低エントロピーキーは、パスワード認証キーエクスチェンジ（Pake）がTLSで使用される場合にのみ、アクティブな攻撃に対して安全です。執筆時点で、Crypto Forum Research Group（CFRG）は、対称および非対称のケースについてそれぞれ[CPACE]および[不透明]を参照）の指定に取り組んでいます。
PSK ciphersuites were first specified for TLS in 2005. PSKs are now an integral part of the TLS 1.3 specification [RFC8446]. TLS 1.3 also uses PSKs for session resumption. It distinguishes these resumption PSKs from external PSKs that have been provisioned out of band. This section describes known use cases and provisioning processes for external PSKs with TLS.
PSK Ciphersuitesは、2005年にTLS用に最初に指定されました。PSKは現在、TLS 1.3仕様[RFC8446]の不可欠な部分です。TLS 1.3は、セッション再開にもPSKを使用します。これらの再開PSKを、バンドからプロビジョニングされた外部PSKと区別します。このセクションでは、TLSを使用した外部PSKの既知のユースケースとプロビジョニングプロセスについて説明します。
This section lists some example use cases where pairwise external PSKs (i.e., external PSKs that are shared between only one server and one client) have been used for authentication in TLS. There was no attempt to prioritize the examples in any particular order.
このセクションには、TLSの認証に使用されているペアワイズ外部PSK（つまり、1つのサーバーと1つのクライアントの間で共有される外部PSK）が使用されているユースケースの例をリストします。特定の順序で例を優先順位付けする試みはありませんでした。
* Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out of band for communicating with known identities, wherein the identity to use is discovered via a different online protocol.
* バンド外の同期キーとのデバイス間通信。既知のアイデンティティと通信するためにバンドからプロビジョニングされたPSKは、使用するアイデンティティが異なるオンラインプロトコルを介して発見されます。
* Intra-data-center communication. Machine-to-machine communication within a single data center or Point of Presence (PoP) may use externally provisioned PSKs; this is primarily for the purpose of supporting TLS connections with early data. See Section 8 for considerations when using early data with external PSKs.
* DATA内センター通信。単一のデータセンターまたはポイントオブプレゼンス（POP）内のマシン間通信（POP）は、外部からプロビジョニングされたPSKを使用する場合があります。これは主に、初期データとTLS接続をサポートする目的のためです。外部PSKで初期データを使用する場合は、考慮事項についてはセクション8を参照してください。
* Certificateless server-to-server communication. Machine-to-machine communication may use externally provisioned PSKs; this is primarily for the purposes of establishing TLS connections without requiring the overhead of provisioning and managing PKI certificates.
* 証明書のないサーバーからサーバーへの通信。機械間通信は、外部からプロビジョニングされたPSKを使用する場合があります。これは主に、PKI証明書のプロビジョニングと管理のオーバーヘッドを必要とせずにTLS接続を確立する目的です。
* Internet of Things (IoT) and devices with limited computational capabilities. [RFC7925] defines TLS and DTLS profiles for resource-constrained devices and suggests the use of PSK ciphersuites for compliant devices. The Open Mobile Alliance Lightweight Machine-to-Machine (LwM2M) Technical Specification [LwM2M] states that LwM2M servers MUST support the PSK mode of DTLS.
* モノのインターネット（IoT）と計算機能が限られているデバイス。[RFC7925]は、リソース制約のデバイスのTLSプロファイルとDTLプロファイルを定義し、準拠デバイスにPSK Ciphersuitesの使用を提案します。Open Mobile Alliance Lightweight Machine-to-Machine（LWM2M）技術仕様[LWM2M]は、LWM2MサーバーがDTLのPSKモードをサポートする必要があると述べています。
* Securing RADIUS [RFC2865] with TLS. PSK ciphersuites are optional for this use case, as specified in [RFC6614].
* TLSで半径[RFC2865]を保護します。[RFC6614]で指定されているように、PSK Ciphersuitesはこのユースケースでオプションです。
* 3GPP server-to-user equipment authentication. The Generic Authentication Architecture (GAA) defined by 3GPP mentions that TLS PSK ciphersuites can be used between server and user equipment for authentication [GAA].
* 3GPPサーバーからユーザーの機器認証。3GPPで定義された一般的な認証アーキテクチャ（GAA）は、TLS PSK ciphersuitesをサーバーとユーザー機器の間で認証のために使用できると述べています[GAA]。
* Smart Cards. The German electronic Identity (eID) card supports authentication of a card holder to online services with TLS PSK [SmartCard].
* スマートカード。ドイツの電子ID（EID）カードは、TLS PSK [SmartCard]を使用して、カード所有者のオンラインサービスへの認証をサポートしています。
* Quantum resistance. Some deployments may use PSKs (or combine them with certificate-based authentication as described in [RFC8773]) because of the protection they provide against quantum computers.
* 量子抵抗。一部の展開は、量子コンピューターに対して提供される保護のために、PSKを使用する（または[RFC8773]に記載されている証明書ベースの認証と組み合わせる）場合があります。
There are also use cases where PSKs are shared between more than two entities. Some examples below (as noted by Akhmetzyanova, et al. [AASS19]):
PSKが3つ以上のエンティティ間で共有されるユースケースもあります。以下のいくつかの例（Akhmetzyanova、et al。[Aass19]によって述べられているように）：
* Group chats. In this use case, group participants may be provisioned an external PSK out of band for establishing authenticated connections with other members of the group.
* グループチャット。このユースケースでは、グループ参加者は、グループの他のメンバーと認証された接続を確立するために、バンドから外部PSKをプロビジョニングすることができます。
* IoT and devices with limited computational capabilities. Many PSK provisioning examples are possible in this use case. For example, in a given setting, IoT devices may all share the same PSK and use it to communicate with a central server (one key for n devices), have their own key for communicating with a central server (n keys for n devices), or have pairwise keys for communicating with each other (n^2 keys for n devices).
* 計算機能が限られているIoTおよびデバイス。このユースケースでは、多くのPSKプロビジョニングの例が可能です。たとえば、特定の設定では、IoTデバイスはすべて同じPSKを共有し、それを使用してセントラルサーバー（Nデバイスの1つのキー）と通信することができます。、または互いに通信するためのペアワイズキーを持っています（nデバイスのn^2キー）。
The exact provisioning process depends on the system requirements and threat model. Whenever possible, avoid sharing a PSK between nodes; however, sharing a PSK among several nodes is sometimes unavoidable. When PSK sharing happens, other accommodations SHOULD be used as discussed in Section 6.
正確なプロビジョニングプロセスは、システムの要件と脅威モデルに依存します。可能な場合は、ノード間でPSKを共有しないでください。ただし、いくつかのノード間でPSKを共有することは避けられない場合があります。PSK共有が発生する場合、セクション6で説明するように、他の宿泊施設を使用する必要があります。
Examples of PSK provisioning processes are included below.
PSKプロビジョニングプロセスの例を以下に示します。
* Many industrial protocols assume that PSKs are distributed and assigned manually via one of the following approaches: (1) typing the PSK into the devices or (2) using a trust-on-first-use (TOFU) approach with a device completely unprotected before the first login took place. Many devices have a very limited UI. For example, they may only have a numeric keypad or even fewer buttons. When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI.
* 多くの産業プロトコルは、PSKが以下のアプローチのいずれかを介して手動で分布し、手動で割り当てられていると想定しています。（1）PSKをデバイスに入力するか、（2）以前に完全に保護されていないデバイスでTrust-on-First-Use（ToFU）アプローチを使用して（2）最初のログインが行われました。多くのデバイスのUIは非常に限られています。たとえば、数値キーパッドのみまたはボタンが少ない場合があります。豆腐アプローチが適切でない場合、キーを入力するには、制約されたUIで入力する必要があります。
* Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.
* 一部のデバイスでは、帯域外のクラウドベースの同期プロトコルを介してPSKを提供します。
* Some secrets may be baked into hardware or software device components. Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.
* いくつかの秘密は、ハードウェアまたはソフトウェアデバイスコンポーネントに焼き付けられる場合があります。さらに、これが製造時に行われる場合、秘密をラベルに印刷するか、スキャンやインポートを容易にするために資料の請求書に含まれる場合があります。
PSK provisioning systems are often constrained in application-specific ways. For example, although one goal of provisioning is to ensure that each pair of nodes has a unique key pair, some systems do not want to distribute pairwise shared keys to achieve this. As another example, some systems require the provisioning process to embed application-specific information in either PSKs or their identities. Identities may sometimes need to be routable, as is currently under discussion for [EAP-TLS-PSK].
PSKプロビジョニングシステムは、多くの場合、アプリケーション固有の方法で制約されています。たとえば、プロビジョニングの目標の1つは、各ペアのノードが一意のキーペアを持っていることを確認することですが、一部のシステムでは、これを達成するためにペアワイズ共有キーを配布したくありません。別の例として、一部のシステムでは、PSKまたはそのIDのいずれかにアプリケーション固有の情報を埋め込むためにプロビジョニングプロセスが必要です。[EAP-TLS-PSK]の現在議論中のように、アイデンティティはルーティング可能な場合がある場合があります。
Recommended requirements for applications using external PSKs are as follows:
外部PSKを使用したアプリケーションの推奨要件は次のとおりです。
1. Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with an ephemeral key exchange, e.g., by using the "psk_dhe_ke" Pre-Shared Key Exchange Mode in TLS 1.3 for forward secrecy. As discussed in Section 4, low-entropy PSKs (i.e., those derived from less than 128 bits of entropy) are subject to attack and SHOULD be avoided. If only low-entropy keys are available, then key establishment mechanisms such as PAKE that mitigate the risk of offline dictionary attacks SHOULD be employed. Note that no such mechanisms have yet been standardized, and further that these mechanisms will not necessarily follow the same architecture as the process for incorporating external PSKs described in [RFC9258].
1. 各PSKは、少なくとも128ビットのエントロピーから導出され、少なくとも128ビットの長さである必要があり、たとえば「PSK_DHE_KE」を使用して、前方のキーエクスチェンジモードを使用して、前方のキーエクスチェンジモードを使用して、前方のキーエクスチェンジモードと組み合わせる必要があります。秘密。セクション4で説明したように、低エントロピーPSK（つまり、128ビット未満のエントロピーから派生したPSK）は攻撃の対象であり、避けるべきです。低エントロピーキーのみが利用可能な場合、オフライン辞書攻撃のリスクを軽減するPakeなどの重要な確立メカニズムを採用する必要があります。そのようなメカニズムはまだ標準化されていないことに注意してください。さらに、これらのメカニズムは、[RFC9258]に記載されている外部PSKを組み込むプロセスと必ずしも同じアーキテクチャに従うことはないことに注意してください。
2. Unless other accommodations are made to mitigate the risks of PSKs known to a group, each PSK MUST be restricted in its use to at most two logical nodes: one logical node in a TLS client role and one logical node in a TLS server role. (The two logical nodes MAY be the same, in different roles.) Two acceptable accommodations are described in [RFC9258]: (1) exchanging client and server identifiers over the TLS connection after the handshake and (2) incorporating identifiers for both the client and the server into the context string for an external PSK importer.
2. グループに知られているPSKのリスクを軽減するために他の調節が作られていない限り、各PSKは最大2つの論理ノードに使用する必要があります。TLSクライアントの役割の1つの論理ノードとTLSサーバーの役割の1つの論理ノード。（2つの論理ノードは異なる役割で同じである場合があります。）2つの許容可能な調節が[RFC9258]で説明されています：（1）握手後のTLS接続でクライアントとサーバーの識別子を交換し、（2）両方のクライアントの識別子を組み込む外部PSKインポーターのコンテキスト文字列へのサーバー。
3. Nodes SHOULD use external PSK importers [RFC9258] when configuring PSKs for a client-server pair when applicable. Importers make provisioning external PSKs easier and less error-prone by deriving a unique, imported PSK from the external PSK for each key derivation function a node supports. See the Security Considerations of [RFC9258] for more information.
3. ノードは、該当する場合にクライアントサーバーペアにPSKを構成する場合、外部PSKインポーター[RFC9258]を使用する必要があります。輸入業者は、ノードAがサポートする各キー派生関数の外部PSKから一意のインポートされたPSKを導出することにより、外部PSKをより簡単に、より少ないエラーを起こしやすくします。詳細については、[RFC9258]のセキュリティに関する考慮事項を参照してください。
4. Where possible, the main PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated. This prevents an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise, the attacker can recover the main key and then re-run the importer itself.
4. 可能であれば、メインのPSK（インポーターに供給されるもの）は、輸入キーが生成された後に削除する必要があります。これにより、攻撃者が1つのノードの妥協をブートストラップして、任意のノード間の接続を攻撃する機能に妨げられます。それ以外の場合、攻撃者はメインキーを回復してから、インポーター自体を再実行できます。
Most major TLS implementations support external PSKs. Stacks supporting external PSKs provide interfaces that applications may use when configuring PSKs for individual connections. Details about some existing stacks at the time of writing are below.
ほとんどの主要なTLS実装は、外部PSKをサポートしています。外部PSKをサポートするスタックは、個々の接続にPSKを構成するときにアプリケーションが使用できるインターフェイスを提供します。執筆時点での既存のスタックの詳細は以下にあります。
* OpenSSL and BoringSSL: Applications can specify support for external PSKs via distinct ciphersuites in TLS 1.2 and below. Also, they can then configure callbacks that are invoked for PSK selection during the handshake. These callbacks must provide a PSK identity and key. The exact format of the callback depends on the negotiated TLS protocol version, with new callback functions added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support. The PSK length is validated to be between 1-256 bytes (inclusive). The PSK identity may be up to 128 bytes long.
* OpenSSLおよびBoringsSL：アプリケーションは、TLS 1.2以下の明確な暗号を介して外部PSKのサポートを指定できます。また、握手中にPSK選択に呼び出されるコールバックを構成することができます。これらのコールバックは、PSKのIDとキーを提供する必要があります。コールバックの正確な形式は、ネゴシエートされたTLSプロトコルバージョンに依存し、TLS 1.3 [RFC8446] PSKサポートのOpenSSLに特別に追加された新しいコールバック関数が追加されます。PSKの長さは、1〜256バイト（包括的）の間で検証されています。PSKアイデンティティの長さは最大128バイトです。
* mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. Servers must implement callbacks similar to that of OpenSSL. Both PSK identity and key lengths may be between 1-16 bytes long (inclusive).
* MBEDTLS：クライアントアプリケーションは、PSKのIDと値インラインを提供することにより、接続を作成する前にPSKを構成します。サーバーは、OpenSSLのコールバックと同様のコールバックを実装する必要があります。PSKアイデンティティとキーの長さの両方が、長さ1〜16バイト（包括的）の間である場合があります。
* gnuTLS: Applications configure PSK values as either raw byte strings or hexadecimal strings. The PSK identity and key size are not validated.
* GNUTLS：アプリケーションは、PSK値を生のバイト文字列または16進文字列として構成します。PSKアイデンティティとキーサイズは検証されていません。
* wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.
* WolfSSL：Applications OpenSSLと同様のコールバックでPSKを構成します。
Section 5.1 of [RFC4279] mandates that the PSK identity should be first converted to a character string and then encoded to octets using UTF-8. This was done to avoid interoperability problems (especially when the identity is configured by human users). On the other hand, [RFC7925] advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for any operation. When PSK identities are configured manually, it is important to be aware that visually identical strings may, in fact, differ due to encoding issues.
[RFC4279]のセクション5.1は、PSK IDを最初に文字列に変換し、次にUTF-8を使用してオクテットにエンコードすることを義務付けています。これは、相互運用性の問題を回避するために行われました（特に、IDが人間のユーザーによって構成されている場合）。一方、[RFC7925]は、PSK IDの構造化された形式を想定することに対して実装をアドバイスし、操作についてバイバイバイバイバイの比較を推奨します。PSK IDが手動で構成されている場合、視覚的に同一の文字列がエンコードの問題により異なる場合があることに注意することが重要です。
TLS 1.3 [RFC8446] follows the same practice of specifying the PSK identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1> in the specification) that thus is compared on a byte-by-byte basis. [RFC8446] also requires that the PSK identities are at least 1 byte and at the most 65535 bytes in length. Although [RFC8446] does not place strict requirements on the format of PSK identities, note that the format of PSK identities can vary depending on the deployment:
TLS 1.3 [RFC8446]は、PSKアイデンティティを一連の不透明バイト（仕様で不透明なアイデンティティ<1..2^16-1>として表示）として指定するのと同じ慣行に従います。基本。[RFC8446]は、PSKのアイデンティティが少なくとも1バイトで、長さが最大65535バイトであることも必要です。[RFC8446]はPSK IDの形式に厳格な要件を掲載していませんが、PSK IDの形式は展開によって異なる場合があることに注意してください。
* The PSK identity MAY be a user-configured string when used in protocols like Extensible Authentication Protocol (EAP) [RFC3748]. For example, gnuTLS treats PSK identities as usernames.
* PSKアイデンティティは、拡張可能な認証プロトコル（EAP）[RFC3748]などのプロトコルで使用される場合、ユーザーが構成された文字列である場合があります。たとえば、GnutlsはPSK IDをユーザー名として扱います。
* PSK identities MAY have a domain name suffix for roaming and federation. In applications and settings where the domain name suffix is privacy sensitive, this practice is NOT RECOMMENDED.
* PSK IDには、ローミングおよびフェデレーション用のドメイン名接尾辞があります。ドメイン名の接尾辞がプライバシーに敏感なアプリケーションと設定では、このプラクティスは推奨されません。
* Deployments should take care that the length of the PSK identity is sufficient to avoid collisions.
* 展開は、衝突を回避するのに十分なPSKアイデンティティの長さが十分であることに注意する必要があります。
It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity. The TLS stack implementation and sequencing of PSK callbacks influences the application's behavior when identity collisions occur. When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the application's registered callback function before checking the stack's internal session resumption cache. This means that if a PSK identity collision occurs, the application's external PSK usage will typically take precedence over the internal session resumption path.
可能性は低いものの、外部PSKアイデンティティが再開PSKアイデンティティと衝突する可能性があります。PSKコールバックのTLSスタックの実装とシーケンスは、ID衝突が発生したときのアプリケーションの動作に影響します。サーバーがTLS 1.3 ClientHelloでPSK IDを受信すると、一部のTLSスタックは、スタックの内部セッション再開キャッシュをチェックする前に、アプリケーションの登録コールバック関数を実行します。これは、PSK ID衝突が発生した場合、アプリケーションの外部PSK使用量が通常、内部セッション再開パスよりも優先されることを意味します。
Because resumption PSK identities are assigned by the TLS stack implementation, it is RECOMMENDED that these identifiers be assigned in a manner that lets resumption PSKs be distinguished from external PSKs to avoid concerns with collisions altogether.
再開PSK IDはTLSスタックの実装によって割り当てられるため、これらの識別子は、衝突に関する懸念を完全に回避するために、再開PSKを外部PSKと区別できるように割り当てることをお勧めします。
PSK privacy properties are orthogonal to security properties described in Section 4. TLS does little to keep PSK identity information private. For example, an adversary learns information about the external PSK or its identifier by virtue of the identifier appearing in cleartext in a ClientHello. As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire. Depending on the PSK identity, a passive attacker may also be able to identify the device, person, or enterprise running the TLS client or TLS server. An active attacker can also use the PSK identity to suppress handshakes or application data from a specific device by blocking, delaying, or rate-limiting traffic. Techniques for mitigating these risks require further analysis and are out of scope for this document.
PSKプライバシープロパティは、セクション4で説明されているセキュリティプロパティに対して直交しています。TLSは、PSK ID情報を非公開にするためにほとんどありません。たとえば、敵は、ClientHelloのClearTextに表示される識別子のおかげで、外部PSKまたはその識別子に関する情報を学習します。その結果、受動的な敵は、ワイヤー上の同じ外部PSKを使用する2つ以上の接続を2つ以上リンクすることができます。PSKのIDによっては、パッシブ攻撃者は、TLSクライアントまたはTLSサーバーを実行しているデバイス、個人、またはエンタープライズを識別することもできます。アクティブな攻撃者は、PSK IDを使用して、トラフィックをブロック、遅延、またはレート制限することにより、特定のデバイスからの握手またはアプリケーションデータを抑制することもできます。これらのリスクを緩和するための手法では、さらなる分析が必要であり、このドキュメントの範囲外です。
In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers. Specifically, servers can link successive connections that use the same external PSK together. Preventing this type of linkability is out of scope.
ネットワーク内のリンク可能性に加えて、外部PSKはPSKレシーバーによって本質的にリンク可能です。具体的には、サーバーは同じ外部PSKを使用する連続した接続をリンクできます。このタイプのリンク可能性を防ぐことは範囲外です。
Security considerations are provided throughout this document. It bears repeating that there are concerns related to the use of external PSKs regarding proper identification of TLS 1.3 endpoints and additional risks when external PSKs are known to a group.
このドキュメント全体でセキュリティ上の考慮事項が提供されます。TLS 1.3エンドポイントの適切な識別に関する外部PSKの使用に関連する懸念と、外部PSKがグループに知られている場合の追加リスクがあることを繰り返し繰り返します。
It is NOT RECOMMENDED to share the same PSK between more than one client and server. However, as discussed in Section 5.1, there are application scenarios that may rely on sharing the same PSK among multiple nodes. [RFC9258] helps in mitigating rerouting and Selfie-style reflection attacks when the PSK is shared among multiple nodes. This is achieved by correctly using the node identifiers in the ImportedIdentity.context construct specified in [RFC9258]. One solution would be for each endpoint to select one globally unique identifier to use in all PSK handshakes. The unique identifier can, for example, be one of its Media Access Control (MAC) addresses, a 32-byte random number, or its Universally Unique IDentifier (UUID) [RFC4122]. Note that such persistent, global identifiers have privacy implications; see Section 7.
複数のクライアントとサーバーの間で同じPSKを共有することはお勧めしません。ただし、セクション5.1で説明したように、複数のノード間で同じPSKを共有することに依存するアプリケーションシナリオがあります。[RFC9258]は、PSKが複数のノード間で共有されている場合に、再ルーティングとセルフィースタイルの反射攻撃の緩和に役立ちます。これは、[RFC9258]で指定されたImportedIdentity.contextコンストラクトのノード識別子を正しく使用することによって達成されます。1つのソリューションは、各エンドポイントがすべてのPSKハンドシェイクで使用するグローバルに一意の識別子を選択することです。たとえば、一意の識別子は、メディアアクセス制御（MAC）アドレスの1つ、32バイトの乱数、または普遍的に一意の識別子（UUID）[RFC4122]にすることができます。このような永続的なグローバル識別子には、プライバシーの影響があることに注意してください。セクション7を参照してください。
Each endpoint SHOULD know the identifier of the other endpoint with which it wants to connect and SHOULD compare it with the other endpoint's identifier used in ImportedIdentity.context. However, it is important to remember that endpoints sharing the same group PSK can always impersonate each other.
各エンドポイントは、接続したい他のエンドポイントの識別子を把握し、ImportedIdentity.contextで使用される他のエンドポイントの識別子と比較する必要があります。ただし、同じグループPSKを共有するエンドポイントが常に互いになりすます可能性があることを覚えておくことが重要です。
Considerations for external PSK usage extend beyond proper identification. When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that contributes to key diversity between sessions. As a result, when an external PSK is used more than one time, the random number source on the client has a significant role in the protection of the early data.
外部PSK使用に関する考慮事項は、適切な識別を超えて拡張されます。外部PSKで初期のデータが使用される場合、ClientHelloのランダム値は、セッション間の重要な多様性に寄与するエントロピーの唯一のソースです。その結果、外部PSKが複数回使用される場合、クライアントの乱数ソースは、初期データの保護に重要な役割を果たします。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
[RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre-Shared Keys (PSKs) for TLS 1.3", RFC 9258, DOI 10.17487/RFC9258, July 2022, <https://www.rfc-editor.org/info/rfc9258>.
[RFC9258]ベンジャミン、D。およびC. A.ウッド、「TLS 1.3の外部事前共有キー（PSK）のインポート」、RFC 9258、DOI 10.17487/RFC9258、2022年7月、<https：//www.rfc-editor.org/情報/RFC9258>。
[AASS19] Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A. Sokolov, "Continuing to reflect on TLS 1.3 with external PSK", April 2019, <https://eprint.iacr.org/2019/421.pdf>.
[Aass19] Akhmetzyanova、L.、Alekseev、E.、Smyshlyaeva、E.、およびA. Sokolov、「外部PSKとのTLS 1.3を反映し続けています」、2019年4月、<https://eprint.iad.org/20199/421.pdf>。
[CPACE] Abdalla, M., Haase, B., and J. Hesse, "CPace, a balanced composable PAKE", Work in Progress, Internet-Draft, draft-irtf-cfrg-cpace-06, 24 July 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace-06>.
[CPACE] Abdalla、M.、Haase、B。、およびJ. Hesse、「CPACE、バランスの取れた合成可能なPake」、Work in Progress、Internet-Draft、DraftF-CFRG-CPACE-06、2022年7月24日、<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace-06>。
[CTLS] Rescorla, E., Barnes, R., Tschofenig, H., and B. M. Schwartz, "Compact TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-ctls-06, 9 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-06>.
[CTLS] Rescorla、E.、Barnes、R.、Tschofenig、H.、およびB. M. Schwartz、「Compact TLS 1.3」、Work in Progress、Internet-Draft、Draft-ITEF-TLS-CTLS-06、2022年7月9日、<https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-06>。
[EAP-TLS-PSK] Mattsson, J. P., Sethi, M., Aura, T., and O. Friel, "EAP-TLS with PSK Authentication (EAP-TLS-PSK)", Work in Progress, Internet-Draft, draft-mattsson-emu-eap-tls-psk-00, 9 March 2020, <https://datatracker.ietf.org/doc/html/ draft-mattsson-emu-eap-tls-psk-00>.
[EAP-TLS-PSK] Mattsson、J。P.、Sethi、M.、Aura、T。、およびO. Friel、「PSK認証を備えたEAP-TLS（EAP-TLS-PSK）」、進行中の作業、インターネットドラフト、ドラフトマッツソン-EMU-EAP-TLS-PSK-00、2020年3月9日、<https://datatracker.ietf.org/doc/html/ Draft-Mattsson-emu-eap-tls-psk-00>。
[GAA] ETSI, "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; 3G Security; Generic Authentication Architecture (GAA); System description", version 12.0.0, ETSI TR 133 919, October 2014, <https://www.etsi.org/deliver/ etsi_tr/133900_133999/133919/12.00.00_60/ tr_133919v120000p.pdf>.
[GAA] ETSI、「デジタルセルラーテレコミュニケーションシステム（フェーズ2）、ユニバーサルモバイルテレコミュニケーションシステム（UMTS）; LTE; 3Gセキュリティ;ジェネリック認証アーキテクチャ（GAA）;システム説明」、バージョン12.0.0、ETSI TR 133 919、10月2014、<https://www.etsi.org/deliver/ eti_tr/133900_133999/133919/12.00.00_60/TR_133919V120000P.PDF>
[Krawczyk] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols", DOI 10.1007/978-3-540-45146-4_24, 2003, <https://link.springer.com/content/ pdf/10.1007/978-3-540-45146-4_24.pdf>.
[Krawczyk] Krawczyk、H。、「Sigma：認証されたDiffie-Hellmanへの「サインアンドマック」アプローチとIKEプロトコルでのその使用」、DOI 10.1007/978-3-540-45146-4_24、2003、<<https://link.springer.com/content/ pdf/10.1007/978-3-540-45146-4_24.pdf>。
[LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine Technical Specification", version 1.0, February 2017, <http://www.openmobilealliance.org/release/LightweightM2M/ V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf>.
[LWM2M]オープンモバイルアライアンス、「機械技術仕様への軽量マシン」、バージョン1.0、2017年2月、<http://www.openmobilealliance.org/release/lightweightm2m/ v1_0-20170208-a/oma-ts-lightm2m2m-v1_0-20170208-A.PDF>。
[OPAQUE] Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The OPAQUE Asymmetric PAKE Protocol", Work in Progress, Internet-Draft, draft-irtf-cfrg-opaque-09, 6 July 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque-09>.
[Opaque] Bourdrez、D.、Krawczyk、H.、Lewi、K。、およびC. A. Wood、「不透明な非対称Pakeプロトコル」、作業中のインターネットドラフト、ドラフト-ARTF-CFRG-Opaque-09、7月6日7月6日2022、<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque-09>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、DOI 10.17487/RFC2865、2000年6月、<https：//www.rfc-editor.org/info/rfc2865>。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「拡張可能な認証プロトコル（EAP）」、RFC 3748、DOI 10.17487/RFC3748、2004年6月、<https://www.rfc-editor.org/info/rfc3748>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M.、およびR. Salz、「普遍的にユニークな識別子（UUID）URNネームスペース」、RFC 4122、DOI 10.17487/RFC4122、2005年7月、<https：//www.rfc-editor.org/info/rfc4122>。
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <https://www.rfc-editor.org/info/rfc4279>.
[RFC4279] Eronen、P.、ed。およびH. Tschofenig編、「輸送層のセキュリティ（TLS）のための事前共有キーヒルスーツ」、RFC 4279、DOI 10.17487/RFC4279、2005年12月、<https://www.rfc-editor.org/info/RFC42799>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066] EastLake 3rd、D。、「輸送層セキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487/RFC6066、2011年1月、<https://www.rfc-editor.org/info/RFC6066>。
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, <https://www.rfc-editor.org/info/rfc6614>.
[RFC6614] Winter、S.、McCauley、M.、Venaas、S。、およびK. Wierenga、「半径の輸送層セキュリティ（TLS）暗号化」、RFC 6614、DOI 10.17487/RFC6614、2012年5月、<https：//www.rfc-editor.org/info/rfc6614>。
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <https://www.rfc-editor.org/info/rfc7925>.
[RFC7925] Tschofenig、H.、ed。T. Fossati、「モノのインターネットの輸送層セキュリティ（TLS）/データグラムトランスポートレイヤーセキュリティ（DTLS）プロファイル」、RFC 7925、DOI 10.17487/RFC7925、2016年7月、<https：//www.rfc-editor。org/info/rfc7925>。
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key", RFC 8773, DOI 10.17487/RFC8773, March 2020, <https://www.rfc-editor.org/info/rfc8773>.
[RFC8773] Housley、R。、「外部の事前共有キーを使用した証明書ベースの認証用のTLS 1.3拡張」、RFC 8773、DOI 10.17487/RFC8773、2020年3月、<https://www.rfc-editor.org/情報/RFC8773>。
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.
[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/info/rfc9147>。
[Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 with PSK", DOI 10.1007/s00145-021-09387-y, May 2021, <https://eprint.iacr.org/2019/347.pdf>.
[Selfie] Drucker、N。and S. Gueron、「Selfie：Reflections on TLS 1.3 with PSK」、DOI 10.1007/s00145-021-09387-y、2021年5月、<https://eprint.iacr.org/2019/347.pdf>。
[Sethi] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks on Secure Device Pairing and Bootstrapping", DOI 10.1145/3321705.3329813, May 2019, <https://arxiv.org/pdf/1902.07550>.
[Sethi] Sethi、M.、Peltonen、A。、およびT. Aura、「安全なデバイスのペアリングとブートストラップに対する誤攻撃」、DOI 10.1145/3321705.3329813、2019年5月、<https://arxiv.org/pdf/1902.07550>。
[SmartCard]
Bundesamt für Sicherheit in der Informationstechnik,
"Technical Guideline TR-03112-7 eCard-API-Framework -
Protocols", version 1.1.5, April 2015, <https://www.bsi.bu
nd.de/SharedDocs/Downloads/DE/BSI/Publikationen/
TechnischeRichtlinien/TR03112/TR-
03112-api_teil7.pdf?__blob=publicationFile&v=1>.
Acknowledgements
謝辞
This document is the output of the TLS External PSK Design Team, comprised of the following members: Benjamin Beurdouche, Björn Haase, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel, and Russ Housley.
このドキュメントは、次のメンバーで構成されるTLS外部PSK設計チームの出力です。BenjaminBeurdouche、BjörnHaase、Christopher Wood、Colm Maccarthaigh、Eric Rescorla、Jonathan Hoyland、Martin Thomson、Mohamad Badra、Mohit Sethiフリエル、そしてラス・ハウスリー。
This document was improved by high-quality reviews by Ben Kaduk and John Preuß Mattsson.
この文書は、ベン・カドゥクとジョン・プレウ・マッツソンによる高品質のレビューによって改善されました。
Authors' Addresses
著者のアドレス
Russ Housley Vigil Security, LLC Email: housley@vigilsec.com
Russ Housley Vigil Security、LLCメール：housley@vigilsec.com
Jonathan Hoyland Cloudflare Ltd. Email: jonathan.hoyland@gmail.com
Jonathan Hoyland Cloudflare Ltd.メール：jonathan.hoyland@gmail.com
Mohit Sethi Aalto University Email: mohit@iki.fi
Mohit Sethi Aalto University Email：mohit@iki.fi
Christopher A. Wood Cloudflare Email: caw@heapingbits.net
Christopher A. Wood Cloudflareメール：caw@heapingbits.net