Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 9813 InkBridge Networks
BCP: 243 July 2025
Category: Best Current Practice
ISSN: 2070-1721
This document provides implementation and operational considerations for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS/TLS (RFC 6614) and RADIUS/DTLS (RFC 7360). The purpose of the document is to help smooth the operational transition from the use of RADIUS/UDP to RADIUS/TLS.
このドキュメントは、半径/TLS（RFC 6614）および半径/DTL（RFC 7360）を備えたTLS Pre-Sharedキー（TLS-PSK）を使用するための実装と運用上の考慮事項を提供します。ドキュメントの目的は、半径/UDPの使用から半径/TLSへの運用上の移行をスムーズにすることです。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPSの詳細については、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/rfc9813.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9813で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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ライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. Justification of PSK
4. General Discussion of PSKs and PSK Identities
4.1. Guidance for PSKs
4.1.1. PSK Requirements
4.1.2. Usability Guidance
4.1.3. Interaction Between PSKs and RADIUS Shared Secrets
4.2. PSK Identities
4.2.1. Security of PSK Identities
4.3. PSK and PSK Identity Sharing
4.4. PSK Lifetimes
5. Guidance for RADIUS Clients
5.1. PSK Identities
5.1.1. PSK Identity Requirements
5.1.2. Usability Guidance
6. Guidance for RADIUS Servers
6.1. Current Practices
6.2. Practices for TLS-PSK
6.2.1. IP Filtering
6.2.2. PSK Authentication
6.2.3. Resumption
6.2.4. Interaction with Other TLS Authentication Methods
7. Privacy Considerations
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Author's Address
The previous specifications "Transport Layer Security (TLS) Encryption for RADIUS" [RFC6614] and "Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS" [RFC7360] defined how (D)TLS can be used as a transport protocol for RADIUS. However, those documents do not provide guidance for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS. This document provides that missing guidance, and gives implementation and operational considerations.
以前の仕様「半径の輸送層セキュリティ（TLS）暗号化」[RFC6614]および「Datagram Transport Layer Security（DTLS）は、半径の輸送層として」[RFC7360] [RFC7360]を定義した方法を定義しました。ただし、これらのドキュメントは、半径でTLS事前共有キー（TLS-PSK）を使用するためのガイダンスを提供していません。このドキュメントは、その欠落ガイダンスを提供し、実装と運用上の考慮事項を提供します。
To clearly distinguish the various secrets and keys, this document uses "shared secret" to mean "RADIUS shared secret", and "Pre-Shared Key (PSK)" to mean "secret keys that are used with TLS-PSK".
さまざまな秘密と鍵を明確に区別するために、このドキュメントでは、「共有秘密」を使用して「Radius共有秘密」を意味し、「TLS-PSKで使用される秘密の鍵」を意味して「恥ずかしさキー（PSK）」を意味します。
The purpose of the document is to help smooth the operational transition from the use of the insecure RADIUS/UDP to the use of the much more secure RADIUS/TLS. While using PSKs is often less preferable to using public or private keys, the operational model of PSKs follows the legacy RADIUS "shared secret" model. As such, it can be easier for implementers and operators to transition to TLS when that transition is offered as a series of small changes.
このドキュメントの目的は、安全でない半径/UDPの使用からはるかに安全な半径/TLSの使用まで、運用上の移行を滑らかにすることです。PSKの使用は、パブリックキーまたはプライベートキーの使用にはあまり好ましくありませんが、PSKの運用モデルはレガシー半径「共有秘密」モデルに従います。そのため、その移行が一連の小さな変更として提供されると、実装者とオペレーターがTLSに移行するのが簡単になります。
TLS-PSK is intended to be used in networks where the addresses of clients and servers are known, as with RADIUS/UDP. This situation is similar to the use case of RADIUS/UDP with shared secrets. TLS-PSK is not suitable for situations where clients dynamically discover servers, as there is no way for the client to dynamically determine which PSK should be used with a new server (or vice versa). In contrast, dynamic discovery [RFC7585] allows for a client or server to authenticate a previously unknown server or client, as the parties can be issued a certificate by a known Certification Authority (CA).
TLS-PSKは、RADIUS/UDPと同様に、クライアントとサーバーのアドレスが知られているネットワークで使用することを目的としています。この状況は、共有された秘密を持つ半径/UDPのユースケースに似ています。TLS-PSKは、クライアントが新しいサーバーでどのPSKを使用するか（またはその逆）を動的に判断する方法がないため、クライアントがサーバーを動的に発見する状況には適していません。対照的に、ダイナミックディスカバリー[RFC7585]により、クライアントまたはサーバーは、既知の認証機関（CA）によって当事者が証明書を発行できるため、以前は未知のサーバーまたはクライアントを認証できます。
TLS-PSKs have the same issue of symmetric information between client and server: both parties know the secret key. A client could, in theory, pretend to be a server. In contrast, certificates are asymmetric, where it is impossible for the parties to assume the other's identity. Further discussion of this topic is contained in Section 4.3.
TLS-PSKには、クライアントとサーバーの間の対称情報の同じ問題があります。両当事者は秘密の鍵を知っています。理論的には、クライアントはサーバーのふりをすることができます。対照的に、証明書は非対称であり、当事者が相手のアイデンティティを想定することは不可能です。このトピックのさらなる議論は、セクション4.3に含まれています。
Unless it is explicitly called out that a recommendation applies to TLS or DTLS alone, each recommendation applies to both TLS and DTLS.
推奨事項がTLSまたはDTLSのみに適用されることが明示的に呼び出されない限り、各推奨はTLSとDTLの両方に適用されます。
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] で説明されているように解釈されます。
External PSK
外部PSK
A PSK (along with a related PSK Identity) that is administratively configured. That is, one that is external to TLS and is not created by the TLS subsystem.
管理的に構成されているPSK（関連するPSK IDとともに）。つまり、TLSの外部であり、TLSサブシステムによって作成されていないものです。
Resumption PSK
再開psk
A PSK (along with a related PSK Identity) that is created by the TLS subsystem and/or application, for use with resumption.
TLSサブシステムおよび/またはアプリケーションによって作成されたPSK（関連するPSKアイデンティティとともに）。
TLS deployments usually rely on certificates in most common uses. However, we recognize that it may be difficult to fully upgrade client implementations to allow for certificates to be used with RADIUS/TLS and RADIUS/DTLS. These upgrades involve not only implementing TLS, but can also require significant changes to administration interfaces and application programming interfaces (APIs) in order to fully support certificates.
TLS展開は通常、最も一般的な用途で証明書に依存しています。ただし、クライアントの実装を完全にアップグレードして、RADIUS/TLSおよびRADIUS/DTLSで証明書を使用できるようにすることが難しい場合があることを認識しています。これらのアップグレードには、TLSを実装するだけでなく、証明書を完全にサポートするために、管理インターフェイスとアプリケーションプログラミングインターフェイス（API）に大幅な変更が必要になる場合があります。
For example, unlike shared secrets, certificates expire. This expiration means that a working system using TLS can suddenly stop working. Managing this expiration can require additional notification APIs on RADIUS clients and servers that were previously not required when shared secrets were used.
たとえば、共有された秘密とは異なり、証明書は期限切れになります。この有効期限は、TLSを使用する作業システムが突然動作を停止できることを意味します。この有効期限を管理するには、共有された秘密が使用されたときに以前は必須ではなかったRADIUSクライアントとサーバーに追加の通知APIが必要になる場合があります。
Certificates also require the use of certification authorities (CAs) and chains of certificates. RADIUS implementations using TLS therefore have to track not just a small shared secret, but also potentially many large certificates. The use of TLS-PSK can therefore provide a simpler upgrade path for implementations to transition from RADIUS shared secrets to TLS.
証明書には、認定当局（CAS）と証明書チェーンの使用も必要です。したがって、TLSを使用したRADIUS実装は、小さな共有秘密だけでなく、潜在的に多くの大きな証明書を追跡する必要があります。したがって、TLS-PSKの使用は、RADIUS共有秘密からTLSに移行するための実装のためのより簡単なアップグレードパスを提供できます。
In terms of ongoing maintenance, it is generally simpler to maintain servers than clients. For one, there are many fewer servers than clients. Servers are also typically less resource constrained, and often run on general-purpose operating systems, where maintenance can be automated using widely available tools.
継続的なメンテナンスに関しては、クライアントよりもサーバーを維持する方が一般的に簡単です。1つは、クライアントよりもサーバーがはるかに少ないことです。また、サーバーは通常、リソースの制約が少なく、多くの場合、一般的なオペレーティングシステムで実行されます。このオペレーティングシステムでは、広く利用可能なツールを使用してメンテナンスを自動化できます。
In contrast, clients are often numerous, resource constrained, and likely to be closed or proprietary systems with limited interfaces. As a result, it can be difficult to update these clients when a root CA expires. The use of TLS-PSK in such an environment may therefore offer management efficiencies.
対照的に、クライアントは多くのものであり、リソースが制約されており、閉鎖されている可能性があるか、インターフェイスが制限されている独自のシステムです。その結果、ルートCAの有効期限が切れたときにこれらのクライアントを更新することは困難です。したがって、このような環境でのTLS-PSKの使用は、管理効率を提供する可能性があります。
Before we define any RADIUS-specific use of PSKs, we must first review the current standards for PSKs, and give general advice on PSKs and PSK Identities.
PSKの半径固有の使用を定義する前に、まずPSKの現在の標準を確認し、PSKとPSKのアイデンティティに関する一般的なアドバイスを提供する必要があります。
The requirements in this section apply to both client and server implementations that use TLS-PSK. Client-specific and server-specific issues are discussed in more detail later in this document.
このセクションの要件は、TLS-PSKを使用するクライアントとサーバーの実装の両方に適用されます。クライアント固有およびサーバー固有の問題については、このドキュメントの後半で詳しく説明します。
We first give requirements for creating and managing PSKs, followed by usability guidance, and then a discussion of RADIUS shared secrets and their interaction with PSKs.
まず、PSKを作成および管理するための要件を示し、それに続いてユーザビリティガイダンスが続き、次にRadius共有秘密とPSKとの相互作用の議論を示します。
Reuse of a PSK in multiple versions of TLS (e.g., TLS 1.2 and TLS 1.3) is considered unsafe (see [RFC8446], Appendix E.7). Where TLS 1.3 binds the PSK to a particular key derivation function (KDF), TLS 1.2 does not. This binding means that it is possible to use the same PSK in different hashes, leading to the potential for attacking the PSK by comparing the hash outputs. While there are no known insecurities, these uses are not known to be secure, and should therefore be avoided. For this reason, an implementation MUST NOT use the same PSK for TLS 1.3 and for earlier versions of TLS. The exact manner in which this requirement is enforced is implementation-specific. One possibility is to have two different PSKs. Another possibility is to forbid the use of TLS versions less than TLS 1.3
TLSの複数のバージョンでのPSKの再利用（たとえば、TLS 1.2およびTLS 1.3）は安全ではないと見なされます（[RFC8446]、付録E.7を参照）。TLS 1.3がPSKを特定のキー導出関数（KDF）に結合する場合、TLS 1.2はそうではありません。この結合は、異なるハッシュで同じPSKを使用することが可能であることを意味し、ハッシュ出力を比較することによりPSKを攻撃する可能性につながります。既知の不安はありませんが、これらの用途は安全であることが知られていないため、避けるべきです。このため、実装では、TLS 1.3およびTLSの以前のバージョンで同じPSKを使用してはなりません。この要件が実施される正確な方法は、実装固有です。1つの可能性は、2つの異なるPSKを持つことです。別の可能性は、TLS 1.3未満のTLSバージョンの使用を禁止することです
[RFC9258] adds a KDF to the import interface of (D)TLS 1.3, which binds the externally provided PSK to the protocol version. That process is preferred to any trust-on-first-use (TOFU) mechanism. In particular, that document:
[RFC9258]は、（d）TLS 1.3のインポートインターフェイスにKDFを追加し、外部から提供されたPSKをプロトコルバージョンに結合します。そのプロセスは、任意の信頼の使用（豆腐）メカニズムよりも優先されます。特に、そのドキュメント：
... describes a mechanism for importing PSKs derived from external PSKs by including the target KDF, (D)TLS protocol version, and an optional context string to ensure uniqueness. This process yields a set of candidate PSKs, each of which are bound to a target KDF and protocol, that are separate from those used in (D)TLS 1.2 and prior versions. This expands what would normally have been a single PSK and identity into a set of PSKs and identities.
...ターゲットKDF、（d）TLSプロトコルバージョン、および一意性を確保するためのオプションのコンテキスト文字列を含めることにより、外部PSKから派生したPSKをインポートするメカニズムを説明します。このプロセスは、それぞれがターゲットKDFとプロトコルにバインドされている候補PSKのセットを生成します。これは、（d）TLS 1.2および以前のバージョンで使用されるものとは別です。これにより、通常、単一のPSKとアイデンティティがPSKとIDのセットに拡大します。
An implementation MUST NOT use the same PSK for TLS 1.3 and for earlier versions of TLS. This requirement prevents reuse of a PSK with multiple TLS versions, which prevents the attacks discussed in [RFC8446], Appendix E.7. The exact manner in which this requirement is enforced is implementation-specific. One possibility is to have two different PSKs. Another possibility is to forbid the use of TLS versions less than TLS 1.3.
実装は、TLS 1.3およびTLSの以前のバージョンに同じPSKを使用してはなりません。この要件は、複数のTLSバージョンを使用したPSKの再利用を防ぎ、[RFC8446]、付録E.7で説明されている攻撃を防ぎます。この要件が実施される正確な方法は、実装固有です。1つの可能性は、2つの異なるPSKを持つことです。別の可能性は、TLS 1.3未満のTLSバージョンの使用を禁止することです。
Implementations MUST follow the directions of [RFC9257], Section 6 for the use of external PSKs in TLS. That document provides extremely useful guidance on generating and using PSKs.
実装は、TLSでの外部PSKを使用するために、[RFC9257]、セクション6の指示に従う必要があります。このドキュメントは、PSKの生成と使用に関する非常に有用なガイダンスを提供します。
Implementations MUST support PSKs of at least 32 octets in length, and SHOULD support PSKs of 64 octets or more. As the PSKs are generally hashed before being used in TLS, the useful entropy of a PSK is limited by the size of the hash output. This output may be 256, 384, or 512 bits in length. Nevertheless, it is good practice for implementations to allow entry of PSKs of more than 64 octets, as the PSK may be in a form other than bare binary data. Implementations that limit the PSK to a maximum of 64 octets are likely to use PSKs that have much less than 512 bits of entropy. That is, a PSK with high entropy may be expanded via some construct (e.g., base32 as seen in Section 4.1.2) in order to make it easier for people to interact with. Where 512 bits of entropy are input to an encoding construct, the output may be larger than 64 octets.
実装は、少なくとも32オクテットの長さのPSKをサポートする必要があり、64オクテット以上のPSKをサポートする必要があります。PSKは一般にTLSで使用される前にハッシュされるため、PSKの有用なエントロピーはハッシュ出力のサイズによって制限されます。この出力は、256、384、または512ビットの長さです。それにもかかわらず、PSKはベアバイナリデータ以外の形式である可能性があるため、64を超えるオクテットのPSKの入力を可能にするための実装のための良い習慣です。PSKを最大64オクテットに制限する実装は、512ビット未満のエントロピーを持つPSKを使用する可能性があります。つまり、人々がやり取りしやすくするために、高いエントロピーを備えたPSKを何らかのコンストラクト（セクション4.1.2に見られるようにBase32など）を介して拡張することができます。512ビットのエントロピーがエンコードコンストラクトに入力されている場合、出力は64オクテットを超える場合があります。
Implementations MUST require that PSKs be at least 16 octets in length. That is, short PSKs MUST NOT be permitted to be used, and PSKs MUST be random. The strength of the PSK is not determined by the length of the PSK, but instead by the number of bits of entropy that it contains. People are not good at creating data with high entropy, so a source of cryptographically secure random numbers MUST be used.
実装では、PSKの長さが少なくとも16オクターであることが必要です。つまり、短いPSKを使用することを許可してはならず、PSKはランダムでなければなりません。PSKの強度は、PSKの長さによってはなく、それに含まれるエントロピーのビット数によって決定されます。人々は高いエントロピーでデータを作成するのが得意ではないため、暗号化された乱数のソースを使用する必要があります。
Where user passwords are generally intended to be remembered and entered by people on a regular basis, PSKs are intended to be entered once, and then automatically saved in a system configuration. As such, due to the limited entropy of passwords, they are not acceptable for use with TLS-PSK, and would only be acceptable for use with a password-authenticated key exchange (PAKE) TLS method [RFC8492]. Implementations MUST therefore support entry and storage of PSKs as undistinguished octets.
ユーザーのパスワードが一般的に定期的に覚えられ、入力されることを意図している場合、PSKは一度入力され、システム構成に自動的に保存されることを目的としています。そのため、パスワードのエントロピーが限られているため、TLS-PSKでの使用には受け入れられず、パスワードを認識したキーエクスチェンジ（Pake）TLSメソッド[RFC8492]でのみ使用できます。したがって、実装は、PSKのエントリとストレージを、無意味なオクテットとしてサポートする必要があります。
We also incorporate by reference the requirements of [RFC7360], Section 10.2 when using PSKs.
また、PSKを使用する場合、[RFC7360]、セクション10.2の要件を参照して組み込みます。
It may be tempting for servers to implement a TOFU policy with respect to clients. Such behavior is NOT RECOMMENDED. When servers receive a connection from an unknown client, they SHOULD log the PSK Identity, source IP address, and any other information that may be relevant. An administrator can then later look at the logs and determine the appropriate action to take.
サーバーがクライアントに関して豆腐ポリシーを実装するのは魅力的かもしれません。そのような動作は推奨されません。サーバーが不明なクライアントから接続を受信した場合、PSK ID、ソースIPアドレス、および関連する可能性のあるその他の情報を記録する必要があります。その後、管理者は後でログを見て、適切なアクションを決定することができます。
PSKs in their purest form are opaque tokens, represented as an undistinguished series of octets. Where PSKs are expected to be managed automatically by scripted methods, this format is acceptable. However, in some cases it is necessary for administrators to share PSKs, in which case human-readable formats may be useful. Implementations SHOULD support entering PSKs as both binary data and via a human-readable form such as hex encoding.
最も純粋な形のPSKは不透明なトークンであり、オクテットの無意味なシリーズとして表されます。PSKがスクリプト化されたメソッドによって自動的に管理されると予想される場合、この形式は許容されます。ただし、場合によっては、管理者がPSKを共有する必要があります。この場合、人間が読み取ることができる場合が役立ちます。実装は、バイナリデータの両方として、およびHEXエンコーディングなどの人間が読めるフォームを介してPSKを入力することをサポートする必要があります。
Implementations SHOULD use a human-readable form of PSKs for interfaces that are intended to be used by people, and SHOULD allow for binary data to be entered via an application programming interface (API). Implementations SHOULD also allow for PSKs to be displayed in the hex encoding mentioned above, so that administrators can manually verify that a particular PSK is being used.
実装では、人が使用することを目的としたインターフェイスには、人間の読み取り可能な形式のPSKを使用し、アプリケーションプログラミングインターフェイス（API）を介してバイナリデータを入力できるようにする必要があります。また、特定のPSKが使用されていることを管理者が手動で確認できるように、上記の16進エンコードにPSKを表示できるようにする必要があります。
When using PSKs, administrators SHOULD use PSKs of at least 24 octets that are generated using a source of cryptographically secure random numbers. Implementers needing a secure random number generator should see [RFC8937] for further guidance. PSKs are not passwords, and administrators should not try to manually create PSKs.
PSKを使用する場合、管理者は暗号化された乱数のソースを使用して生成される少なくとも24オクテットのPSKを使用する必要があります。安全な乱数ジェネレーターを必要とする実装者は、さらなるガイダンスのために[RFC8937]を見る必要があります。PSKはパスワードではなく、管理者は手動でPSKを作成しようとしないでください。
In order to guide implementers and administrators, we give example commands below that generate random PSKs from a locally secure source. While some commands may not work on some systems, one of the commands should succeed. The intent here is to document a concise and simple example of creating PSKs that are both secure and human-manageable. This document does not mandate that the PSKs follow this format or any other format.
実装者と管理者をガイドするために、ローカルで安全なソースからランダムなPSKを生成するコマンドを下に示します。一部のコマンドは一部のシステムでは機能しない場合がありますが、コマンドの1つが成功する必要があります。ここでの意図は、安全で人間が管理できるPSKを作成する簡潔で簡単な例を文書化することです。このドキュメントは、PSKがこの形式またはその他の形式に従うことを義務付けていません。
openssl rand -base64 16
dd if=/dev/urandom bs=1 count=16 | base64
dd if=/dev/urandom bs=1 count=16 | base32
dd if=/dev/urandom bs=1 count=16 | (hexdump -ve '/1 "%02x"' && echo)
Only one of the above commands should be run; there is no need to run all of them. Each command reads 128 bits (16 octets) of random data from a secure source, and encodes it as printable and readable ASCII. This form of PSK will be accepted by any implementation that supports at least 32 octets for PSKs. Larger PSKs can be generated by changing the "16" number to a larger value. The above derivation assumes that the random source returns one bit of entropy for every bit of randomness that is returned. Sources failing that assumption are NOT RECOMMENDED.
上記のコマンドのうち1つのみを実行する必要があります。それらすべてを実行する必要はありません。各コマンドは、安全なソースから128ビット（16オクテット）のランダムデータを読み取り、印刷可能で読み取り可能なASCIIとしてエンコードします。この形式のPSKは、PSKの少なくとも32オクテットをサポートする実装によって受け入れられます。「16」の数値をより大きな値に変更することで、より大きなPSKを生成できます。上記の派生は、ランダムソースが返されるランダム性のすべてのビットに対して1ビットのエントロピーを返すことを前提としています。その仮定が推奨されない情報源。
Any shared secret used for RADIUS/UDP or RADIUS/TLS MUST NOT be used for TLS-PSK.
半径/UDPまたは半径/TLSに使用される共有秘密は、TLS-PSKに使用してはなりません。
It is RECOMMENDED that RADIUS clients and servers track all used shared secrets and PSKs, and then verify that the following requirements all hold true:
RADIUSクライアントとサーバーが使用されているすべての共有秘密とPSKを追跡し、次の要件がすべて真であることを確認することをお勧めします。
* no shared secret is used for more than one RADIUS client
* 複数のRADIUSクライアントに使用される共有秘密はありません
* no PSK is used for more than one RADIUS client
* 複数のRADIUSクライアントに使用されるPSKはありません
* no shared secret is used as a PSK
* 共有秘密はPSKとして使用されていません
Note that the shared secret of "radsec" given in [RFC6614] can be used across multiple clients, as that value is mandated by the specification. The intention here is to recommend best practices for administrators who enter site-local shared secrets.
[RFC6614]に与えられた「RADSEC」の共有秘密は、その値が仕様によって義務付けられているため、複数のクライアントで使用できることに注意してください。ここでの意図は、サイトローカルの共有秘密に入る管理者にベストプラクティスを推奨することです。
There may be use cases for using one shared secret across multiple RADIUS clients. There may similarly be use cases for sharing a PSK across multiple RADIUS clients. Details of the possible attacks on reused PSKs are given in [RFC9257], Section 4.1.
複数のRADIUSクライアントで1つの共有秘密を使用するためのユースケースがある場合があります。同様に、複数のRADIUSクライアントでPSKを共有するためのユースケースがある場合があります。再使用されたPSKに対する可能な攻撃の詳細は、[RFC9257]、セクション4.1に記載されています。
There are no known use cases for using a PSK as a shared secret, or vice versa.
PSKを共有秘密として使用するための既知のユースケースはありません。
Implementations MUST reject configuration attempts that try to use the same value for the PSK and shared secret. To prevent administrative errors, implementations should not have interfaces that confuse PSKs and shared secrets or that allow both PSKs and shared secrets to be entered at the same time. There is too much of a temptation for administrators to enter the same value in both fields, which would violate the limitations given above. Similarly, using a "shared secret" field as a way for administrators to enter PSKs is bad practice. The PSK entry fields need to be labeled as being related to PSKs, and not to shared secrets.
実装は、PSKに同じ値を使用し、共有秘密を使用しようとする構成試みを拒否する必要があります。管理上のエラーを防ぐために、実装には、PSKと共有秘密を混乱させるインターフェイスや、PSKと共有秘密の両方を同時に入力できるインターフェイスがあるべきではありません。管理者が両方のフィールドに同じ値を入力するには、あまりにも多くの誘惑があり、上記の制限に違反します。同様に、管理者がPSKに入る方法として「共有秘密」フィールドを使用することは悪い練習です。PSKエントリフィールドは、PSKに関連しているとラベル付けする必要があり、共有された秘密ではありません。
[RFC4279], Section 5.1 requires that PSK Identities be encoded in UTF-8 format. However, [RFC8446], Section 4.2.11 describes the "Pre-Shared Key Extension" and defines the ticket as an opaque string: "opaque identity<1..2^16-1>;". This PSK is then used in [RFC8446], Section 4.6.1 for resumption.
[RFC4279]、セクション5.1では、PSKのアイデンティティをUTF-8形式でエンコードする必要があります。ただし、[RFC8446]、セクション4.2.11では、「事前共有キーエクステンション」について説明し、チケットを不透明な文字列として定義します：「不透明なアイデンティティ<1..2^16-1>;」。このPSKは[RFC8446]で使用され、セクション4.6.1で再開します。
These definitions appear to be in conflict. This conflict is addressed in [RFC9257], Section 6.1.1, which discusses requirements for encoding and comparison of PSK Identities. Systems MUST follow the directions of [RFC9257], Section 6.1.1 when using or comparing PSK Identities for RADIUS/TLS. Implementations MUST follow the recommendations of [RFC8265] for handling PSK Identity strings.
これらの定義は対立しているようです。この競合は[RFC9257]、セクション6.1.1で対処されています。これは、PSK IDのエンコードと比較の要件について説明しています。radius/TLSにPSK IDを使用または比較する場合、システムは[RFC9257]、セクション6.1.1の指示に従う必要があります。実装は、PSK ID文字列を処理するために[RFC8265]の推奨事項に従う必要があります。
In general, implementers should allow for external PSK Identities to follow [RFC4279] and be UTF-8, while PSK Identities provisioned as part of resumption are automatically provisioned, and therefore follow [RFC8446].
一般に、実装者は外部PSKアイデンティティを[RFC4279]に従い、UTF-8にすることを許可する必要がありますが、再開の一部としてプロビジョニングされたPSK IDは自動的にプロビジョニングされ、したがって[RFC8446]に従います。
Note that the PSK Identity is sent in the clear, and is therefore visible to attackers. Where privacy is desired, the PSK Identity could be either an opaque token generated cryptographically, or perhaps in the form of a Network Access Identifier (NAI) [RFC7542], where the "user" portion is an opaque token. For example, an NAI could be "68092112@example.com". If the attacker already knows that the client is associated with "example.com", then using that domain name in the PSK Identity offers no additional information. In contrast, the "user" portion needs to be both unique to the client and private, so using an opaque token is a more secure approach.
PSKのIDは明確に送信されるため、攻撃者に表示されることに注意してください。プライバシーが必要な場合、PSKアイデンティティは暗号化された不透明なトークンであるか、おそらくネットワークアクセス識別子（NAI）[RFC7542]の形で、「ユーザー」部分は不透明なトークンです。たとえば、NAIは「68092112@example.com」になる可能性があります。攻撃者がクライアントが「Example.com」に関連付けられていることをすでに知っている場合、PSK IDでそのドメイン名を使用することは追加情報を提供しません。対照的に、「ユーザー」部分はクライアントとプライベートに固有のものである必要があるため、不透明なトークンを使用することはより安全なアプローチです。
Implementations MUST support PSK Identities of 128 octets, and SHOULD support longer PSK Identities. We note that while TLS provides for PSK Identities of up to 2^16-1 octets in length, there are few practical uses for extremely long PSK Identities.
実装は、128オクテットのPSKアイデンティティをサポートする必要があり、より長いPSK IDをサポートする必要があります。TLSは、長さが最大2^16-1オクテットのPSKアイデンティティを提供しますが、非常に長いPSK IDの実用的な使用はほとんどないことに注意してください。
It is up to administrators and implementations as to how they differentiate external PSK Identities from session resumption PSK Identities used in TLS 1.3 session tickets. While [RFC9257], Section 6.1.2 suggests the identities should be unique, it offers no concrete steps for how this differentiation may be done.
これは、TLS 1.3セッションチケットで使用されるセッション再開PSKアイデンティティから外部PSKのアイデンティティをどのように区別するかに関する管理者と実装次第です。[RFC9257]が、セクション6.1.2は、アイデンティティが一意であるべきであることを示唆していますが、この差別化がどのように行われるかについての具体的な手順はありません。
One approach could be to have externally provisioned PSK Identities contain an NAI such as what is described above, while session resumption PSK Identities contain large blobs of opaque, encrypted, and authenticated text. It should then be relatively straightforward to differentiate the two types of identities. One is UTF-8, the other is not. One is unauthenticated, the other is authenticated.
1つのアプローチは、外部からプロビジョニングされたPSKアイデンティティに上記のようなNAIを含むことができますが、セッション再開PSKアイデンティティには、不透明、暗号化、および認証されたテキストの大きな塊が含まれています。その後、2種類のアイデンティティを区別するのは比較的簡単です。1つはUTF-8、もう1つはそうではありません。1つは認識されていない、もう1つは認証されています。
Servers MUST assign and/or track session resumption PSK Identities in a way that facilities the ability to distinguish those identities from externally configured PSK Identities, and that enables them to both find and validate the session resumption PSK. See Section 6.2.3 below for more discussion of issues around resumption.
サーバーは、セッションの再開PSK IDを割り当て、および/または追跡する必要があり、それらのアイデンティティを外部構成されたPSKアイデンティティと区別する機能を設備し、セッション再開PSKを見つけて検証できるようにします。再開に関する問題の詳細については、以下のセクション6.2.3を参照してください。
A sample validation flow for TLS-PSK Identities could be performed via the following steps:
TLS-PSK IDのサンプル検証フローは、次の手順で実行できます。
1. PSK Identities provided via an administration interface are enforced to be only UTF-8 on both client and server.
1. 管理インターフェイスを介して提供されるPSK IDは、クライアントとサーバーの両方でUTF-8のみを強制されます。
2. The client treats session tickets received from the server as opaque blobs.
2. クライアントは、サーバーから受け取ったセッションチケットを不透明なブロブとして扱います。
3. When the server issues session tickets for resumption, the server ensures that they are not valid UTF-8.
3. サーバーが再開のためにセッションチケットを発行した場合、サーバーは有効なUTF-8でないことを保証します。
4. One way to do this is to use stateless resumption with a forced non-UTF-8 key_name per [RFC8446], Section 4.6.1, such as by setting one octet to 0x00.
4. これを行う1つの方法は、1オクテットを0x00に設定するなど、強制非UTF-8 key_name、[RFC8446]、セクション4.6.1を使用して、ステートレス再開を使用することです。
5. When receiving TLS, the server receives a Client-Hello containing a PSK, and checks if the identity is valid UTF-8:
5. TLSを受信すると、サーバーはPSKを含むクライアントヘロを受信し、IDが有効であるかどうかを確認します。
5.1. If yes, it searches for a preconfigured client that matches that identity.
5.1. はいの場合、そのアイデンティティに一致する事前に構成されたクライアントを検索します。
5.1.1. If the identity is found, it authenticates the client via PSK.
5.1.1. IDが見つかった場合、PSKを介してクライアントを認証します。
5.1.2. Else, the identity is invalid, and the server closes the connection.
5.1.2. それ以外の場合、IDは無効であり、サーバーは接続を閉じます。
5.2. If not, try resumption, which is usually handled by a TLS library.
5.2. そうでない場合は、通常、TLSライブラリによって処理される再開を試してください。
5.2.1. If the TLS library verifies the session ticket, then resumption has happened, and the connection is established.
5.2.1. TLSライブラリがセッションチケットを検証した場合、再開が行われ、接続が確立されます。
5.2.2. Else, the server ignores the session ticket, and performs a normal TLS handshake with a certificate.
5.2.2. それ以外の場合、サーバーはセッションチケットを無視し、証明書を使用して通常のTLSハンドシェイクを実行します。
This validation flow is only suggested. Other validation methods are possible.
この検証フローは提案されています。他の検証方法が可能です。
We note that the PSK Identity is a field created by the connecting client. Since the client is untrusted until both the identity and PSK have been verified, both of those fields MUST be treated as untrusted. That is, a well-formed PSK Identity is likely to be in UTF-8 format, due to the requirements of [RFC4279], Section 5.1. However, implementations MUST support managing PSK Identities as a set of undistinguished octets.
PSKアイデンティティは、接続クライアントによって作成されたフィールドであることに注意してください。アイデンティティとPSKの両方が検証されるまでクライアントは信頼されていないため、これらのフィールドは両方とも信頼されていないと扱われなければなりません。つまり、[RFC4279]、セクション5.1の要件により、適切に形成されたPSKアイデンティティがUTF-8形式である可能性があります。ただし、実装は、PSKアイデンティティの管理を一連の無意味なオクテットとしてサポートする必要があります。
It is not safe to use a raw PSK Identity to look up a corresponding PSK. The PSK may come from an untrusted source and may contain invalid or malicious data. For example, the identity may:
RAW PSK IDを使用して対応するPSKを検索することは安全ではありません。PSKは、信頼されていないソースから来る場合があり、無効または悪意のあるデータが含まれている場合があります。たとえば、アイデンティティは次のとおりです。
* have an incorrect UTF-8 format,
* 誤ったUTF-8形式があります、
* contain data that forms an injection attack for SQL, the Lightweight Directory Access Protocol (LDAP), Representational State Transfer (REST), or shell meta characters, or
* SQL、Lightweight Directory Access Protocol（LDAP）、表現状態転送（REST）、またはシェルメタ文字の注入攻撃を形成するデータが含まれています。
* contain embedded NUL octets that are incompatible with APIs that expect NUL terminated strings.
* nulが終了した文字列を予想するAPIと互換性のない埋め込まれたnulオクテットが含まれています。
The identity may also be up to 65535 octets long.
アイデンティティは、最大65535オクテットの長さでもあります。
As such, implementations MUST validate the identity prior to it being used as a lookup key. When the identity is passed to an external API (e.g., database lookup), implementations MUST either escape any characters in the identity that are invalid for that API, or else reject the identity entirely. The exact form of any escaping depends on the API, and we cannot document all possible methods here. However, a few basic validation rules are suggested, as outlined below. Any identity that is rejected by these validation rules MUST cause the server to close the TLS connection.
そのため、実装は、ルックアップキーとして使用される前に、IDを検証する必要があります。IDが外部API（データベースルックアップなど）に渡される場合、実装は、そのAPIに対して無効なアイデンティティの文字をエスケープするか、アイデンティティを完全に拒否する必要があります。脱出の正確な形式はAPIに依存し、ここで考えられるすべての方法を文書化することはできません。ただし、以下に概説するように、いくつかの基本的な検証ルールが提案されています。これらの検証ルールによって拒否されたアイデンティティは、サーバーにTLS接続を閉じさせなければなりません。
The suggested validation rules for identities used outside of resumption are as follows:
再開以外で使用されるアイデンティティの推奨検証ルールは次のとおりです。
* Identities MUST be checked to see if they have been provisioned as a resumption PSK. If so, then the session can be resumed, subject to any policies around resumption.
* IDを確認して、再開PSKとしてプロビジョニングされているかどうかを確認する必要があります。もしそうなら、再開に関するポリシーを条件として、セッションを再開することができます。
* Identities longer than a fixed maximum SHOULD be rejected. The limit is implementation dependent, but SHOULD NOT be less than 128, and SHOULD NOT be more than 1024. There is no purpose to allowing extremely long identities, and allowing them does little more than complicate implementations.
* 固定最大値より長いアイデンティティは拒否される必要があります。制限は実装に依存しますが、128を超えてはならず、1024を超えてはなりません。非常に長いアイデンティティを許可する目的はありません。
* Identities configured by administrators SHOULD be in UTF-8 format, and SHOULD be in the NAI format from [RFC7542]. While [RFC8446], Section 4.2.11 defines the PSK Identity as "opaque identity<1..2^16-1>", it is useful for administrators to manage human-readable identities in a recognizable format.
* 管理者によって構成されたアイデンティティは、UTF-8形式である必要があり、[RFC7542]のNAI形式である必要があります。[RFC8446]は、PSKアイデンティティを「不透明なアイデンティティ<1..2^16-1>」と定義していますが、管理者が認識可能な形式で人間の読み取り可能なアイデンティティを管理するのに役立ちます。
This suggestion makes it easier to distinguish TLS-PSK Identities from TLS 1.3 resumption identities. It also allows implementations to more easily filter out unexpected or bad identities, and then to close inappropriate TLS connections.
この提案により、TLS-PSKのアイデンティティをTLS 1.3再開のアイデンティティと区別しやすくなります。また、実装が予期しないアイデンティティまたは悪いアイデンティティをより簡単にフィルタリングし、不適切なTLS接続を閉じることができます。
It is RECOMMENDED that implementations extend these rules with any additional validation that is found to be useful. For example, implementations and/or deployments could both generate PSK Identities in a particular format for passing to client systems, and then also verify that any received identity matches that format. For example, a site could generate PSK Identities that are composed of characters in the local language. The site could then reject identities that contain characters from other languages, even if those characters are valid UTF-8.
実装は、有用であることがわかった追加の検証でこれらのルールを拡張することをお勧めします。たとえば、実装や展開は、クライアントシステムに渡すために特定の形式でPSK IDを生成することができ、受信したIDがその形式と一致することも確認できます。たとえば、サイトは、ローカル言語の文字で構成されるPSKアイデンティティを生成できます。その後、このサイトは、それらの文字が有効なUTF-8であっても、他の言語の文字を含むアイデンティティを拒否できます。
The purpose of these rules is to help administrators and implementers more easily manage systems using TLS-PSK, while also minimizing complexity and protecting from potential attackers' traffic. The rules follow a principle of "discard bad traffic quickly", which helps to improve system stability and performance.
これらのルールの目的は、TLS-PSKを使用して管理者と実装者がシステムをより簡単に管理し、複雑さを最小限に抑え、潜在的な攻撃者のトラフィックから保護できるようにすることです。ルールは、「悪いトラフィックを迅速に廃棄する」という原則に従います。これは、システムの安定性とパフォーマンスを改善するのに役立ちます。
While administrators may desire to share PSKs and/or PSK Identities across multiple systems, such usage is NOT RECOMMENDED. Details of the possible attacks on reused PSKs are given in [RFC9257], Section 4.1.
管理者は、複数のシステムでPSKやPSKのアイデンティティを共有したい場合がありますが、このような使用法は推奨されません。再使用されたPSKに対する可能な攻撃の詳細は、[RFC9257]、セクション4.1に記載されています。
Implementations MUST support the ability to configure a unique PSK and PSK Identity for each possible client-server relationship. This configuration allows administrators desiring security to use unique PSKs for each such relationship. This configuration is also compatible with the practice of administrators who wish to reuse PSKs and PSK Identities where local policies permit.
実装は、可能なクライアントサーバー関係ごとに一意のPSKおよびPSKアイデンティティを構成する機能をサポートする必要があります。この構成により、管理者はセキュリティがそのような関係ごとに一意のPSKを使用することを望んでいます。この構成は、PSKとPSKのIDを再利用したい管理者の実践と互換性があります。
Implementations SHOULD warn administrators if the same PSK Identity and/or PSK is used for multiple client-server relationships.
同じPSK IDおよび/またはPSKが複数のクライアントサーバー関係に使用される場合、実装は管理者に警告する必要があります。
Unfortunately, [RFC9257] offers no guidance on PSK lifetimes other than to note in Section 4.2 that:
残念ながら、[RFC9257]は、セクション4.2に注意する以外のPSKライフタイムに関するガイダンスを提供していません。
Forward security may be achieved by using a PSK-DH mode or by using PSKs with short lifetimes.
PSK-DHモードを使用するか、寿命が短いPSKを使用することにより、フォワードセキュリティを実現できます。
It is RECOMMENDED that PSKs be rotated regularly. We offer no additional guidance on how often this process should occur. Changing PSKs has a non-zero cost. It is therefore up to administrators to determine how best to balance the cost of changing the PSK against the cost of a potential PSK compromise.
PSKを定期的に回転させることをお勧めします。このプロセスが発生する頻度に関する追加のガイダンスは提供されません。PSKの変更にはゼロ以外のコストがあります。したがって、PSKを潜在的なPSK妥協のコストと比較するためのコストのバランスをとるのに最適な方法を決定するのは、管理者次第です。
TLS-PSK MUST use modes such as PSK-DH or ECDHE_PSK [RFC5489] that provide forward secrecy. Failure to use such modes would mean that compromise of a PSK would allow an attacker to decrypt all sessions that had used that PSK.
TLS-PSKは、将来の秘密を提供するPSK-DHやECDHE_PSK [RFC5489]などのモードを使用する必要があります。そのようなモードを使用しないと、PSKの妥協により、攻撃者がそのPSKを使用したすべてのセッションを復号化できるようになります。
As the PSKs are looked up by identity, the PSK Identity MUST also be changed when the PSK changes.
PSKはIDによって検索されるため、PSKが変更されたときにPSKのIDも変更する必要があります。
Servers SHOULD track when a connection was last received for a particular PSK Identity, and SHOULD automatically invalidate credentials when a client has not connected for an extended period of time. This process helps to mitigate the issue of credentials being leaked when a device is stolen or discarded.
サーバーは、特定のPSKアイデンティティの接続が最後に受信されたときに追跡する必要があり、クライアントが長期間接続していない場合に資格情報を自動的に無効にする必要があります。このプロセスは、デバイスが盗まれたり廃棄されたりすると、資格情報が漏れているという問題を軽減するのに役立ちます。
Client implementations MUST allow the use of a Pre-Shared Key (PSK) for RADIUS/TLS. The client implementation can then provide a user interface flag that is "TLS yes / no", and also provide fields that ask for the PSK Identity and PSK itself.
クライアントの実装では、半径/TLSに事前共有キー（PSK）を使用する必要があります。クライアントの実装は、「TLS YES / NO」であるユーザーインターフェイスフラグを提供し、PSK IDとPSK自体を要求するフィールドを提供できます。
For TLS 1.3, implementations MUST support the "psk_dhe_ke" PSK Exchange Mode as discussed in [RFC8446], Section 4.2.9 and in [RFC9257], Section 6. Implementations MUST implement the recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and in [RFC8446], Section 9.1 for TLS 1.3. In order to future-proof these recommendations, we give the following recommendations.
TLS 1.3の場合、実装は[RFC8446]、セクション4.2.9および[RFC9257]、[RFC9257]で説明されている「PSK_DHE_KE」PSK Exchangeモードをサポートする必要があります。これらの推奨事項を将来的に防ぐために、次の推奨事項を提供します。
* Implementations SHOULD use the "Recommended" cipher suites listed in the IANA "TLS Cipher Suites" registry:
* 実装では、IANA "TLS暗号スイート"レジストリにリストされている「推奨される」暗号スイートを使用する必要があります。
- For TLS 1.3, use the "psk_dhe_ke" PSK key exchange mode.
- TLS 1.3の場合、「PSK_DHE_KE」PSKキーエクスチェンジモードを使用します。
- For TLS 1.2 and earlier, use cipher suites that require ephemeral keying.
- TLS 1.2以前には、一時的なキーイングが必要な暗号スイートを使用します。
If a client initiated a connection using a PSK with TLS 1.3 by including the PSK extension, it MUST close the connection if the server did not also select the PSK to continue the handshake.
クライアントがPSK拡張機能を含めることによりTLS 1.3を使用してPSKを使用して接続を開始した場合、サーバーがPSKを選択してハンドシェイクを継続しなかった場合、接続を閉じる必要があります。
This section offers advice on both requirements for PSK Identities and on usability.
このセクションでは、PSK IDの要件と使いやすさの両方に関するアドバイスを提供します。
[RFC6614] is silent on the subject of PSK Identities, which is an issue that we correct here. Guidance is required on the use of PSK Identities, as the need to manage identities associated with PSKs is a new requirement for both Network Access Server (NAS) management interfaces and RADIUS servers.
[RFC6614]は、PSK IDの主題について沈黙しています。これは、ここで修正する問題です。PSKに関連するアイデンティティを管理する必要性は、ネットワークアクセスサーバー（NAS）管理インターフェイスとRADIUSサーバーの両方の新しい要件であるため、PSK IDの使用に関するガイダンスが必要です。
RADIUS systems implementing TLS-PSK MUST support identities as per [RFC4279], Section 5.3 and MUST enable configuring TLS-PSK Identities in management interfaces as per [RFC4279], Section 5.4.
TLS-PSKを実装するRADIUSシステムは、[RFC4279]、セクション5.3に従ってアイデンティティをサポートする必要があり、[RFC4279]、セクション5.4に従って、管理インターフェイスでTLS-PSKアイデンティティの構成を有効にする必要があります。
The historic methods of signing RADIUS packets have not yet been broken, but they are believed to be much less secure than modern TLS. Therefore, when a RADIUS shared secret is used to sign RADIUS/UDP or RADIUS/TCP packets, that shared secret MUST NOT be used with TLS-PSK. If the secrets were to be reused, then an attack on historic RADIUS cryptography could be trivially leveraged to decrypt TLS-PSK sessions.
半径パケットに署名する歴史的な方法はまだ壊れていませんが、最新のTLSよりもはるかに安全性が低いと考えられています。したがって、RADIUS共有秘密を使用して半径/UDPまたは半径/TCPパケットに署名する場合、その共有秘密をTLS-PSKで使用してはなりません。秘密が再利用されると、歴史的な半径の暗号に対する攻撃を、TLS-PSKセッションを復号化するために些細なことに活用される可能性があります。
With TLS-PSK, RADIUS/TLS clients MUST permit the configuration of a RADIUS server IP address or host name, because dynamic server lookups [RFC7585] can only be used if servers use certificates.
TLS-PSKを使用すると、RADIUS/TLSクライアントは、ダイナミックサーバールックアップ[RFC7585]を使用する場合にのみ使用できるため、RADIUSサーバーIPアドレスまたはホスト名の構成を許可する必要があります。
In order to prevent confusion between shared secrets and TLS-PSKs, management interfaces and APIs need to label PSK fields as "PSK" or "TLS-PSK", rather than as "shared secret".
共有秘密とTLS-PSK間の混乱を防ぐために、管理インターフェイスとAPIは、「共有秘密」ではなく、PSKフィールドを「PSK」または「TLS-PSK」にラベル付けする必要があります。
In order to support clients with TLS-PSK, server implementations MUST allow the use of a PSK (TLS-PSK) for RADIUS/TLS.
TLS-PSKでクライアントをサポートするには、サーバーの実装では、radius/TLSにPSK（TLS-PSK）を使用する必要があります。
Systems that act as both client and server at the same time MUST NOT share or reuse PSK Identities between incoming and outgoing connections. Doing so would open up the systems to attack, as discussed in [RFC9257], Section 4.1.
クライアントとサーバーの両方として同時に機能するシステムは、着信と発信接続の間でPSKのアイデンティティを共有または再利用してはなりません。そうすることで、[RFC9257]、セクション4.1で説明されているように、攻撃するシステムが開きます。
For TLS 1.3, implementations MUST support the "psk_dhe_ke" PSK Exchange Mode as discussed in [RFC8446], Section 4.2.9 and in [RFC9257], Section 6. Implementations MUST implement the recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and in [RFC8446], Section 9.1 for TLS 1.3. In order to future-proof these recommendations, we give the following recommendations.
TLS 1.3の場合、実装は[RFC8446]、セクション4.2.9および[RFC9257]、[RFC9257]で説明されている「PSK_DHE_KE」PSK Exchangeモードをサポートする必要があります。これらの推奨事項を将来的に防ぐために、次の推奨事項を提供します。
* Implementations SHOULD use the "Recommended" cipher suites listed in the IANA "TLS Cipher Suites" registry:
* 実装では、IANA "TLS暗号スイート"レジストリにリストされている「推奨される」暗号スイートを使用する必要があります。
- For TLS 1.3, use the "psk_dhe_ke" PSK key exchange mode.
- TLS 1.3の場合、「PSK_DHE_KE」PSKキーエクスチェンジモードを使用します。
- For TLS 1.2 and earlier, use cipher suites that require ephemeral keying.
- TLS 1.2以前には、一時的なキーイングが必要な暗号スイートを使用します。
The following section(s) describe guidance for RADIUS server implementations and deployments. We first give an overview of current practices, and then extend and/or replace those practices for TLS-PSK.
次のセクションでは、RADIUSサーバーの実装と展開に関するガイダンスについて説明します。最初に現在のプラクティスの概要を示し、次にTLS-PSKのこれらのプラクティスを拡張および/または置き換えます。
RADIUS identifies clients by source IP address (see [RFC2865] and [RFC6613]) or by client certificate (see [RFC6614] and [RFC7585]). Neither of these approaches work for TLS-PSK. This section describes current practices and mandates behavior for servers that use TLS-PSK.
RADIUSは、ソースIPアドレス（[RFC2865]および[RFC6613]を参照）またはクライアント証明書（[RFC6614]および[RFC7585]を参照）でクライアントを識別します。これらのアプローチはどちらもTLS-PSKでは機能しません。このセクションでは、現在の慣行について説明し、TLS-PSKを使用するサーバーの動作を義務付けています。
A RADIUS/UDP server is typically configured with a set of information per client, which includes at least the source IP address and shared secret. When the server receives a RADIUS/UDP packet, it looks up the source IP address, finds a client definition, and therefore the shared secret. The packet is then authenticated (or not) using that shared secret.
RADIUS/UDPサーバーは通常、クライアントごとの情報セットで構成されています。これには、少なくともソースIPアドレスと共有シークレットが含まれます。サーバーがRADIUS/UDPパケットを受信すると、ソースIPアドレスを検索し、クライアントの定義を見つけ、したがって共有された秘密を見つけます。パケットは、その共有秘密を使用して認証されます（またはそうでない）。
That is, the IP address is treated as the client's identity, and the shared secret is used to prove the client's authenticity and shared trust. The set of clients forms a logical database "client table" with the IP address as the key.
つまり、IPアドレスはクライアントのIDとして扱われ、共有された秘密はクライアントの信頼性と共有信頼を証明するために使用されます。クライアントのセットは、IPアドレスをキーとして、論理データベース「クライアントテーブル」を形成します。
A server may be configured with additional site-local policies associated with that client. For example, a client may be marked up as being a Wi-Fi Access Point, a VPN concentrator, etc. Different clients may be permitted to send different kinds of requests, where some may send Accounting-Request packets, and other clients may not send accounting packets.
サーバーは、そのクライアントに関連付けられた追加のサイトローカルポリシーで構成される場合があります。たとえば、クライアントは、Wi-Fiアクセスポイント、VPNコンセントレーターなどとしてマークアップされる場合があります。さまざまなクライアントがさまざまな種類のリクエストを送信することを許可される場合があります。
We define practices for TLS-PSK by analogy with the RADIUS/UDP use case and by extending the additional policies associated with the client. The PSK Identity replaces the source IP address as the client identifier. The PSK replaces the shared secret as proof of client authenticity and shared trust. However, systems implementing RADIUS/TLS [RFC6614] and RADIUS/DTLS [RFC7360] MUST still use the shared secret as discussed in those specifications. Any PSK is only used by the TLS layer and has no effect on the RADIUS data that is being transported. That is, the RADIUS data transported in a TLS tunnel is the same no matter if client authentication is done via PSK or by client certificates. The encoding of the RADIUS data is entirely unaffected by the use (or not) of PSKs and client certificates.
RADIUS/UDPユースケースとの類似性により、およびクライアントに関連する追加のポリシーを拡張することにより、TLS-PSKのプラクティスを定義します。PSK IDは、クライアント識別子としてソースIPアドレスを置き換えます。PSKは、クライアントの信頼性と共有信頼の証明として共有された秘密を置き換えます。ただし、RADIUS/TLS [RFC6614]およびRADIUS/DTLS [RFC7360]を実装するシステムは、それらの仕様で説明されているように共有秘密を使用する必要があります。すべてのPSKはTLSレイヤーでのみ使用され、輸送されている半径データには影響しません。つまり、TLSトンネルで輸送されるRADIUSデータは、クライアント認証がPSKを介して行われるか、クライアント証明書で行われていても同じです。RADIUSデータのエンコードは、PSKおよびクライアント証明書の使用（またはそうでない）によって完全に影響を受けません。
In order to securely support dynamic source IP addresses for clients, we also require that servers limit clients based on a network range. The alternative would be to suggest that RADIUS servers allow any source IP address to connect and try TLS-PSK, which could be a security risk. When RADIUS servers do no source IP address filtering, it is easier for attackers to send malicious traffic to the server. An issue with a TLS library or even a TCP/IP stack could permit the attacker to gain unwarranted access. In contrast, when IP address filtering is done, attackers generally must first gain access to a secure network before attacking the RADIUS server.
クライアントの動的なソースIPアドレスを安全にサポートするために、ネットワーク範囲に基づいてサーバーがクライアントを制限することも必要です。別の方法は、RADIUSサーバーがソースIPアドレスを接続してTLS-PSKを試すことを許可することを示唆することです。これはセキュリティリスクになる可能性があります。RADIUSサーバーがソースIPアドレスフィルタリングを行わない場合、攻撃者は悪意のあるトラフィックをサーバーに送信するのが簡単です。TLSライブラリまたはTCP/IPスタックの問題により、攻撃者が不当なアクセスを取得できる可能性があります。対照的に、IPアドレスフィルタリングが完了した場合、攻撃者は通常、RADIUSサーバーを攻撃する前に、まず安全なネットワークにアクセスする必要があります。
Even where dynamic discovery [RFC7585] is not used, the use of TLS-PSK across unrelated organizations requires that those organizations share PSKs. Such sharing makes it easier for a client to impersonate a server, and vice versa. In contrast, when certificates are used, such impersonations are impossible. It is therefore NOT RECOMMENDED to use TLS-PSK across organizational boundaries.
動的発見[RFC7585]が使用されていない場合でも、無関係な組織全体でTLS-PSKを使用すると、それらの組織がPSKを共有する必要があります。このような共有により、クライアントがサーバーになりやすくなり、その逆も同様です。対照的に、証明書が使用される場合、そのようななりすましは不可能です。したがって、組織の境界を越えてTLS-PSKを使用することはお勧めしません。
When TLS-PSK is used in an environment where both client and server are part of the same organization, then impersonations only affect that organization. As TLS offers significant advantages over RADIUS/ UDP, it is RECOMMENDED that organizations use RADIUS/TLS with TLS-PSK to replace RADIUS/UDP for all systems managed within the same organization. While such systems are generally located inside of private networks, there are no known security issues with using TLS-PSK for RADIUS/TLS connections across the public Internet.
TLS-PSKがクライアントとサーバーの両方が同じ組織の一部である環境で使用される場合、なりすましはその組織にのみ影響します。TLSは半径/UDPよりも大きな利点を提供するため、組織は同じ組織内で管理されているすべてのシステムの半径/UDPをTLS-PSKでRADIUS/TLSを使用して使用することをお勧めします。このようなシステムは一般にプライベートネットワーク内にありますが、パブリックインターネット全体で半径/TLS接続にTLS-PSKを使用することに既知のセキュリティの問題はありません。
If a client system is compromised, its complete configuration is exposed to the attacker. Exposing a client certificate means that the attacker can pretend to be the client. In contrast, exposing a PSK means that the attacker cannot only pretend to be the client, but can also pretend to be the server.
クライアントシステムが侵害された場合、その完全な構成は攻撃者にさらされます。クライアント証明書を公開するということは、攻撃者がクライアントのふりをすることができることを意味します。対照的に、PSKを公開するということは、攻撃者がクライアントのふりをすることはできないだけでなく、サーバーのふりをすることができることを意味します。
The main benefit of TLS-PSK, therefore, is that its operational processes are similar to that used for managing RADIUS/UDP, while gaining the increased security of TLS. However, it is still beneficial for servers to perform IP address filtering, in order to further limit their exposure to attacks.
したがって、TLS-PSKの主な利点は、その運用プロセスが、TLSのセキュリティの増加を獲得しながら、半径/UDPの管理に使用されるプロセスと類似していることです。ただし、攻撃への露出をさらに制限するために、サーバーがIPアドレスフィルタリングを実行することは依然として有益です。
A server supporting this specification MUST perform IP address filtering on incoming connections. There are few reasons for a server to have a default configuration that allows connections from any source IP address.
この仕様をサポートするサーバーは、着信接続でIPアドレスフィルタリングを実行する必要があります。サーバーがソースIPアドレスからの接続を許可するデフォルトの構成を持つ理由はほとんどありません。
A TLS-PSK server MUST be configurable with a set of "allowed" network ranges from which clients are permitted to connect. Any connection from outside of the allowed range(s) MUST be rejected before any PSK Identity is checked. It is RECOMMENDED that servers support IP address filtering even when TLS-PSK is not used.
TLS-PSKサーバーは、クライアントが接続できる「許可された」ネットワーク範囲のセットで構成可能でなければなりません。許可された範囲の外側からの接続は、PSK IDがチェックされる前に拒否する必要があります。TLS-PSKが使用されていない場合でも、サーバーはIPアドレスフィルタリングをサポートすることをお勧めします。
The "allowed" network ranges could be implemented as a global list, or one or more network ranges could be tied to a client or clients. The intent here is to allow connections to be filtered by source IP address and to allow clients to be limited to a subset of network addresses. The exact method and representation of that filtering is up to an implementation.
「許可された」ネットワーク範囲はグローバルリストとして実装できます。または、1つ以上のネットワーク範囲をクライアントまたはクライアントに結び付けることができます。ここでの意図は、ソースIPアドレスによって接続をフィルタリングできるようにし、クライアントがネットワークアドレスのサブセットに制限できるようにすることです。そのフィルタリングの正確な方法と表現は、実装次第です。
Conceptually, the set of IP addresses and ranges, along with permitted clients and their credentials, form a logical "client table" that the server uses to both filter and authenticate clients. The client table should contain information such as allowed network ranges, PSK Identity and associated PSK, credentials for another TLS authentication method, or flags that indicate that the server should require a client certificate.
概念的には、IPアドレスと範囲のセットは、許可されたクライアントとその資格情報とともに、サーバーがクライアントをフィルタリングおよび認証する両方に使用する論理的な「クライアントテーブル」を形成します。クライアントテーブルには、許可されたネットワーク範囲、PSKアイデンティティ、関連するPSK、別のTLS認証方法の資格情報、またはサーバーがクライアント証明書を必要とすることを示すフラグなどの情報を含める必要があります。
Once a server receives a connection, it checks the source IP address against the list of all allowed IP addresses or ranges in the client table. If none match, the connection MUST be rejected. That is, the connection MUST be from an authorized source IP address.
サーバーが接続を受信すると、クライアントテーブルのすべての許可されたIPアドレスまたは範囲のリストに対してソースIPアドレスをチェックします。一致しない場合、接続を拒否する必要があります。つまり、接続は承認されたソースIPアドレスからのものでなければなりません。
Once a connection has been established, the server MUST NOT process any application data inside of the TLS tunnel until the client has been authenticated. Instead, the server normally receives a TLS-PSK Identity from the client. The server then uses this identity to look up the client in the client table. If there is no matching client, the server MUST close the connection. The server then also checks if this client definition allows this particular source IP address. If the source IP address is not allowed, the server MUST close the connection.
接続が確立されると、サーバーはクライアントが認証されるまでTLSトンネル内のアプリケーションデータを処理してはなりません。代わりに、サーバーは通常、クライアントからTLS-PSK IDを受信します。その後、サーバーはこのIDを使用して、クライアントテーブルでクライアントを検索します。一致するクライアントがない場合、サーバーは接続を閉じる必要があります。また、サーバーは、このクライアント定義により、この特定のソースIPアドレスが許可されているかどうかも確認します。ソースIPアドレスが許可されていない場合、サーバーは接続を閉じる必要があります。
Where the server does not receive TLS-PSK from the client, it proceeds with another authentication method such as client certificates. Such requirements are discussed elsewhere, most notably in [RFC6614] and [RFC7360].
サーバーがクライアントからTLS-PSKを受信しない場合、クライアント証明書などの別の認証方法で進行します。このような要件は、特に[RFC6614]および[RFC7360]で、他の場所で議論されています。
An implementation may perform two independent IP address lookups: first to check if the connection is allowed at all, and second to check if the connection is authorized for this particular client. One or both checks may be used by a particular implementation. The two sets of IP addresses can overlap, and implementations SHOULD support that capability.
実装は、2つの独立したIPアドレス検索を実行する場合があります。最初に接続が許可されているかどうかを確認し、次にこの特定のクライアントに対して接続が承認されているかどうかを確認します。一方または両方のチェックは、特定の実装で使用できます。IPアドレスの2つのセットが重複する可能性があり、実装はその機能をサポートする必要があります。
Depending on the implementation, one or more clients may share a list of allowed network ranges. Alternately, the allowed network ranges for two clients can overlap only partially, or not at all. All of these possibilities MUST be supported by the server implementation.
実装に応じて、1つ以上のクライアントが許可されたネットワーク範囲のリストを共有する場合があります。あるいは、2つのクライアントの許可されたネットワークの範囲は、部分的にのみオーバーラップするか、まったくオーバーラップできます。これらの可能性はすべて、サーバーの実装によってサポートされている必要があります。
For example, a RADIUS server could be configured to accept connections from a source network of 192.0.2.0/24 or 2001:DB8::/32. The server could therefore discard any TLS connection request that comes from a source IP address outside of that network. In that case, there is no need to examine the PSK Identity or to find the client definition. Instead, the IP source filtering policy would deny the connection before any TLS communication had been performed.
たとえば、192.0.2.0/24または2001：db8 ::/32のソースネットワークからの接続を受け入れるようにRADIUSサーバーを構成できます。したがって、サーバーは、そのネットワークの外側のソースIPアドレスから生じるTLS接続要求を破棄できます。その場合、PSKのIDを調べたり、クライアントの定義を見つけたりする必要はありません。代わりに、TLS通信が実行される前に、IPソースフィルタリングポリシーは接続を拒否します。
As some clients may have dynamic IP addresses, it is possible for one PSK Identity to appear at different source IP addresses over time. In addition, as there may be many clients behind one NAT gateway, there may be multiple RADIUS clients using one public IP address. RADIUS servers MUST support multiple PSK Identifiers at one source IP address.
一部のクライアントは動的なIPアドレスを持っている可能性があるため、1つのPSK IDが時間の経過とともに異なるソースIPアドレスに表示される可能性があります。さらに、1つのNATゲートウェイの背後に多くのクライアントがいる可能性があるため、1つのパブリックIPアドレスを使用して複数のRADIUSクライアントがいる場合があります。RADIUSサーバーは、1つのソースIPアドレスで複数のPSK識別子をサポートする必要があります。
That is, a server needs to support multiple different clients within one network range, multiple clients behind a NAT, and one client having different IP addresses over time. All of those use cases are common and necessary.
つまり、サーバーは、1つのネットワーク範囲内で複数の異なるクライアント、NATの背後にある複数のクライアント、および1つのクライアントが時間の経過とともに異なるIPアドレスを持っているサポートする必要があります。これらのユースケースはすべて一般的で必要です。
The following section describes these requirements in more detail.
次のセクションでは、これらの要件について詳しく説明します。
Once the source IP address has been verified to be allowed for this particular client, the server authenticates the TLS connection via the PSK taken from the client definition. If the PSK is verified, the server then accepts the connection and proceeds with RADIUS/TLS as per [RFC6614].
この特定のクライアントにソースIPアドレスを許可するように検証されたら、サーバーはクライアント定義から取得したPSKを介してTLS接続を認証します。PSKが検証されている場合、サーバーは接続を受け入れ、[RFC6614]に従って半径/TLSで進行します。
If the PSK is not verified, then the server MUST close the connection. While TLS provides for fallback to other authentication methods such as client certificates, there is no reason for a client to be configured simultaneously with multiple authentication methods.
PSKが検証されていない場合、サーバーは接続を閉じる必要があります。TLSは、クライアント証明書などの他の認証方法へのフォールバックを提供しますが、クライアントが複数の認証方法と同時に構成される理由はありません。
A client MUST use only one authentication method for TLS. An authentication method is either TLS-PSK, client certificates, or some other method supported by TLS.
クライアントは、TLSに1つの認証方法のみを使用する必要があります。認証方法は、TLS-PSK、クライアント証明書、またはTLSでサポートされるその他の方法のいずれかです。
That is, client configuration is relatively simple: use a particular set of credentials to authenticate to a particular server. While clients may support multiple servers and fail-over or load-balancing, that configuration is generally orthogonal to the choice of which credentials to use.
つまり、クライアントの構成は比較的単純です。特定のクレデンシャルセットを使用して、特定のサーバーに認証します。クライアントは複数のサーバーとフェールオーバーまたは負荷バランスをサポートする場合がありますが、その構成は一般に、どの資格情報を使用するかを選択するための直交です。
It is NOT RECOMMENDED that servers enable resumption for sessions that use TLS-PSK. There are few practical benefits to supporting resumption and many complexities.
サーバーがTLS-PSKを使用するセッションの再開を有効にすることは推奨されません。再開をサポートするための実際的な利点と多くの複雑さはほとんどありません。
However, some systems will need to support both TLS-PSK and other TLS-based authentication methods such as certificates, while also supporting session resumption. It is therefore vital for servers to be able to distinguish the use case of TLS-PSK with preconfigured identities from TLS-PSK that is being used for resumptions.
ただし、一部のシステムでは、TLS-PSKおよび証明書などの他のTLSベースの認証方法の両方をサポートする必要がありますが、セッション再開もサポートする必要があります。したがって、サーバーが、繰り返しに使用されているTLS-PSKの事前に設定されたアイデンティティを使用して、TLS-PSKのユースケースを区別できることが重要です。
The above discussion of PSK Identities is complicated by the use of PSKs for resumption in TLS 1.3. A server that receives a PSK Identity via TLS typically cannot query the TLS layer to see if this identity is for a resumed session (which is possibly for another TLS authentication method), or is instead a static pre-provisioned identity. This confusion complicates server implementations.
PSKアイデンティティの上記の議論は、TLS 1.3で再開するためにPSKを使用することにより複雑になります。TLSを介してPSKアイデンティティを受信するサーバーは、通常、TLSレイヤーを照会して、このアイデンティティが再開されたセッション（おそらく別のTLS認証メソッド用）であるか、代わりに静的な事前に解決されたアイデンティティであるかを確認することはできません。この混乱は、サーバーの実装を複雑にします。
One way for a server to tell the difference between the two kinds of identities is via construction. Identities used for resumption can be constructed via a fixed format, such as what is recommended by [RFC8446], Section 4.6.1. A static pre-provisioned identity could be in the format of an NAI, as given in [RFC7542]. An implementation could therefore examine the incoming identity and determine from the identity alone what kind of authentication was being performed.
サーバーが2種類のアイデンティティの違いを示す1つの方法は、構築によるものです。再開に使用されるアイデンティティは、[RFC8446]、セクション4.6.1で推奨されるなど、固定形式で構築できます。[RFC7542]に示されているように、静的な事前に生成されたアイデンティティは、NAIの形式である可能性があります。したがって、実装は、着信のアイデンティティを調べ、アイデンティティのみからどのような認証が実行されているかを判断することができます。
An alternative way for a server to distinguish the two kinds of identities is to maintain two tables. One table would contain static identities, as the logical client table described above. Another table could be the table of identities handed out for resumption. The server would then look up any PSK Identity in one table, and if it is not found, query the other one. Either an identity would be found in a table, in which case it can be authenticated, or the identity would not be found in either table, in which case it is unknown, and the server MUST close the connection.
サーバーが2種類のアイデンティティを区別する別の方法は、2つのテーブルを維持することです。上記の論理クライアントテーブルのように、1つのテーブルには静的なアイデンティティが含まれます。別のテーブルは、再開のために配られたアイデンティティのテーブルです。サーバーは、1つのテーブルでPSK IDを検索し、見つけられない場合はもう1つのテーブルを照会します。アイデンティティがテーブルにあります。その場合、認証されることができます。または、どちらのテーブルでもアイデンティティが見つかりません。その場合は不明であり、サーバーは接続を閉じる必要があります。
As suggested in [RFC8446], TLS-PSK peers MUST NOT store resumption PSKs or tickets (and associated cached data) for longer than 604800 seconds (7 days), regardless of the PSK or ticket lifetime.
[RFC8446]で示唆されているように、TLS-PSKピアは、PSKやチケットの寿命に関係なく、再開PSKまたはチケット（および関連するキャッシュデータ）を604800秒（7日間）以上保存してはなりません。
Since resumption in TLS 1.3 uses PSK Identities and keys, it is NOT RECOMMENDED to permit resumption of sessions when TLS-PSK is used. The use of resumption offers additional complexity with minimal additional benefits.
TLS 1.3の再開はPSKのアイデンティティとキーを使用しているため、TLS-PSKを使用する場合、セッションの再開を許可することはお勧めしません。再開の使用は、追加の利点を最小限に抑えて追加の複雑さを提供します。
Where resumption is allowed with TLS-PSK, systems MUST cache data during the initial full handshake sufficiently enough to allow authorization decisions to be made during resumption. If the cached data cannot be retrieved securely, resumption MUST NOT be done. Instead, the system MUST perform a full handshake.
TLS-PSKで再開が許可されている場合、システムは、再開中に許可の決定を行うことができるように、最初の完全な握手中に十分に十分に握手してデータをキャッシュする必要があります。キャッシュされたデータを安全に取得できない場合、再開する必要はありません。代わりに、システムは完全な握手を実行する必要があります。
The data that needs to be cached is typically information such as the original PSK Identity, along with any policies associated with that identity.
キャッシュする必要があるデータは、通常、元のPSKアイデンティティなどの情報と、そのIDに関連するポリシーです。
Information from the original TLS exchange (e.g., the original PSK Identity) as well as related information (e.g., source IP addresses) may change between the initial full handshake and resumption. This change creates a "time-of-check time-of-use" (TOCTOU) security vulnerability. A malicious or compromised client could supply one set of data during the initial authentication and a different set of data during resumption, potentially allowing them to obtain access that they should not have.
元のTLS交換（元のPSKアイデンティティなど）および関連情報（例：ソースIPアドレス）からの情報は、最初の完全な握手と再開の間に変化する場合があります。この変更により、「使用時間」（使用時間」（Toctou）セキュリティの脆弱性が生成されます。悪意のあるまたは侵害されたクライアントは、最初の認証中に1つのデータセットと再開中に異なるデータセットを提供し、潜在的にそれらが持っていないアクセスを取得できる可能性があります。
If any authorization or policy decisions were made with information that has changed between the initial full handshake and resumption, and if changes may lead to a different decision, such decisions MUST be reevaluated. Systems MUST also reevaluate authorization and policy decisions during resumption, based on the information given in the new connection. Servers MAY refuse to perform resumption where the information supplied during resumption does not match the information supplied during the original authentication. If a safe decision is not possible, servers MUST instead continue with a full handshake.
最初の完全な握手と再開の間に変更された情報で許可または政策決定が行われた場合、および変更が異なる決定につながる可能性がある場合、そのような決定は再評価されなければなりません。また、システムは、新しい接続に記載されている情報に基づいて、再開中に承認と政策決定を再評価する必要があります。サーバーは、再開中に提供された情報が元の認証中に提供された情報と一致しない場合、再開を実行することを拒否する場合があります。安全な決定が不可能な場合、サーバーは代わりに完全な握手を続ける必要があります。
When a server supports both TLS-PSK and client certificates, it MUST be able to accept authenticated connections from clients that may use either type of credentials, perhaps even from the same source IP address and at the same time. That is, servers are required to both authenticate the client and also to filter clients by source IP address. These checks both have to match in order for a client to be accepted.
サーバーがTLS-PSKとクライアント証明書の両方をサポートする場合、おそらく同じソースIPアドレスから、同時に、いずれかのタイプの資格情報を使用する可能性のあるクライアントから認証された接続を受け入れることができなければなりません。つまり、サーバーは、クライアントの認証と、ソースIPアドレスでクライアントをフィルタリングするために必要です。これらのチェックは、クライアントを受け入れるためには両方とも一致する必要があります。
We make no changes to [RFC6614] and [RFC7360].
[RFC6614]および[RFC7360]に変更はありません。
The primary focus of this document is addressing security considerations for RADIUS.
このドキュメントの主な焦点は、半径のセキュリティ上の考慮事項に対処することです。
Previous specifications discuss security considerations for TLS-PSK in detail. We refer the reader to Appendix E.7 of [RFC8446], [RFC9257], and [RFC9258]. Those documents are newer than [RFC6614] and [RFC7360], and therefore raise issues that were not considered during the initial design of RADIUS/TLS and RADIUS/DTLS.
以前の仕様は、TLS-PSKのセキュリティに関する考慮事項を詳細に説明しています。読者に[RFC8446]、[RFC9257]、および[RFC9258]の付録E.7を紹介します。これらのドキュメントは[RFC6614]および[RFC7360]よりも新しいため、半径/TLSおよび半径/DTLの初期設計中に考慮されなかった問題を引き起こします。
Using TLS-PSK across the wider Internet for RADIUS can have different security considerations than for other protocols. For example, if TLS-PSK was for client/server communication with HTTPS, then having a PSK be exposed or broken could affect one user's traffic. In contrast, RADIUS contains credentials and personally identifiable information (PII) for many users. As a result, an attacker being able to see inside of a TLS-PSK connection for RADIUS would result in substantial amounts of PII being leaked, possibly including passwords.
RADIUSに対してより広いインターネットを介してTLS-PSKを使用すると、他のプロトコルとは異なるセキュリティ上の考慮事項があります。たとえば、TLS-PSKがHTTPSとのクライアント/サーバー通信用である場合、PSKを露出または壊れさせると、1人のユーザーのトラフィックに影響を与える可能性があります。対照的に、RADIUSには、多くのユーザーの資格情報と個人識別可能な情報（PII）が含まれています。その結果、攻撃者が半径のTLS-PSK接続の内部を見ることができると、おそらくパスワードを含め、かなりの量のPIIが漏れています。
When modes providing forward secrecy are used (e.g., ECDHE_PSK as seen in [RFC5489] and [RFC8442]), such attacks are limited to future sessions, and historical sessions are still secure.
前方の秘密を提供するモードが使用される場合（たとえば、[RFC5489]および[RFC8442]に見られるECDHE_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>.
[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>.
[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>.
[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>.
[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a
Transport Layer for RADIUS", RFC 7360,
DOI 10.17487/RFC7360, September 2014,
<https://www.rfc-editor.org/info/rfc7360>.
[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>.
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 8265,
DOI 10.17487/RFC8265, October 2017,
<https://www.rfc-editor.org/info/rfc8265>.
[RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood,
"Guidance for External Pre-Shared Key (PSK) Usage in TLS",
RFC 9257, DOI 10.17487/RFC9257, July 2022,
<https://www.rfc-editor.org/info/rfc9257>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for
Transport Layer Security (TLS)", RFC 5489,
DOI 10.17487/RFC5489, March 2009,
<https://www.rfc-editor.org/info/rfc5489>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613,
DOI 10.17487/RFC6613, May 2012,
<https://www.rfc-editor.org/info/rfc6613>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for
RADIUS/TLS and RADIUS/DTLS Based on the Network Access
Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October
2015, <https://www.rfc-editor.org/info/rfc7585>.
[RFC8442] Mattsson, J. and D. Migault, "ECDHE_PSK with AES-GCM and
AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2", RFC 8442,
DOI 10.17487/RFC8442, September 2018,
<https://www.rfc-editor.org/info/rfc8442>.
[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>.
[RFC8492] Harkins, D., Ed., "Secure Password Ciphersuites for
Transport Layer Security (TLS)", RFC 8492,
DOI 10.17487/RFC8492, February 2019,
<https://www.rfc-editor.org/info/rfc8492>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/info/rfc8937>.
[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>.
Thanks to the many reviewers in the RADEXT Working Group for positive feedback.
Radextワーキンググループの多くのレビュアーに、肯定的なフィードバックをしてくれてありがとう。
Alan DeKok
InkBridge Networks
Email: alan.dekok@inkbridge.io