[要約] RFC 7360は、RADIUSのトランスポート層としてDatagram Transport Layer Security（DTLS）を使用するためのガイドラインです。このRFCの目的は、RADIUS通信のセキュリティを向上させるために、DTLSを使用する方法を提案することです。
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 7360 FreeRADIUS
Category: Experimental September 2014
ISSN: 2070-1721
Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS
RADIUSのトランスポート層としてのデータグラムトランスポート層セキュリティ（DTLS）
Abstract
概要
The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems.
RFC 2865で定義されているRADIUSプロトコルでは、RADIUSパケットの認証と暗号化のサポートが制限されています。プロトコルはデータを平文で転送しますが、パケットの一部には難読化されたコンテンツが含まれる場合があります。パケットは攻撃者によって逐語的に再生される可能性があり、クライアント/サーバー認証は固定の共有シークレットに基づいています。このドキュメントでは、これらの問題の修正として、データグラムトランスポート層セキュリティ（DTLS）プロトコルを使用する方法について説明します。また、この提案の実装が現在のRADIUSシステムと共存する方法についても説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7360.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7360で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
1.3. Document Status ............................................5
2. Building on Existing Foundations ................................6
2.1. Changes to RADIUS ..........................................7
2.2. Similarities with RADIUS/TLS ...............................8
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ..............8
3. Interaction with RADIUS/UDP .....................................9
3.1. DTLS Port and Packet Types ................................10
3.2. Server Behavior ...........................................10
4. Client Behavior ................................................11
5. Session Management .............................................12
5.1. Server Session Management .................................12
5.1.1. Session Opening and Closing ........................13
5.2. Client Session Management .................................15
6. Implementation Guidelines ......................................16
6.1. Client Implementations ....................................17
6.2. Server Implementations ....................................18
7. Diameter Considerations ........................................18
8. IANA Considerations ............................................18
9. Implementation Status ..........................................18
9.1. Radsecproxy ...............................................19
9.2. jradius ...................................................19
10. Security Considerations .......................................19
10.1. Crypto-Agility ...........................................20
10.2. Legacy RADIUS Security ...................................21
10.3. Resource Exhaustion ......................................22
10.4. Client-Server Authentication with DTLS ...................22
10.5. Network Address Translation ..............................24
10.6. Wildcard Clients .........................................24
10.7. Session Closing ..........................................25
10.8. Client Subsystems ........................................25
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................27
Acknowledgments ...................................................27
The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], and others has traditionally used methods based on MD5 [RFC1321] for per-packet authentication and integrity checks. However, the MD5 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. As a result, some specifications, such as [RFC5176], have recommended using IPsec to secure RADIUS traffic.
[RFC2865]、[RFC2866]、[RFC5176]などで説明されているRADIUSプロトコルは、パケットごとの認証と整合性チェックにMD5 [RFC1321]に基づく方法を伝統的に使用してきました。ただし、MD5アルゴリズムには、[MD5Attack]や[MD5Break]などの既知の弱点があります。その結果、[RFC5176]などの一部の仕様では、IPsecを使用してRADIUSトラフィックを保護することを推奨しています。
While RADIUS over IPsec has been widely deployed, there are difficulties with this approach. The simplest point against IPsec is that there is no straightforward way for an application to control or monitor the network security policies. That is, the requirement that the RADIUS traffic be encrypted and/or authenticated is implicit in the network configuration, and it cannot be enforced by the RADIUS application.
RADIUS over IPsecは広く導入されていますが、このアプローチには問題があります。 IPsecに対する最も単純な点は、アプリケーションがネットワークセキュリティポリシーを制御または監視する簡単な方法がないことです。つまり、RADIUSトラフィックを暗号化および/または認証するという要件は、ネットワーク構成で暗黙的であり、RADIUSアプリケーションによって強制することはできません。
This specification takes a different approach. We define a method for using DTLS [RFC6347] as a RADIUS transport protocol. This approach has the benefit that the RADIUS application can directly monitor and control the security policies associated with the traffic that it processes.
この仕様は異なるアプローチをとります。 RADIUSトランスポートプロトコルとしてDTLS [RFC6347]を使用する方法を定義します。このアプローチには、RADIUSアプリケーションが処理するトラフィックに関連するセキュリティポリシーを直接監視および制御できるという利点があります。
Another benefit is that RADIUS over DTLS continues to be a UDP-based protocol. The change from RADIUS/UDP is largely to add DTLS support, and make any necessary related changes to RADIUS. This allows implementations to remain UDP based, without changing to a TCP architecture.
別の利点は、RADIUS over DTLSが引き続きUDPベースのプロトコルであることです。 RADIUS / UDPからの変更は、主にDTLSサポートを追加し、RADIUSに必要な関連変更を加えることです。これにより、TCPアーキテクチャに変更することなく、実装をUDPベースのままにすることができます。
This specification does not, however, solve all of the problems associated with RADIUS/UDP. The DTLS protocol does not add reliable or in-order transport to RADIUS. DTLS also does not support fragmentation of application-layer messages, or of the DTLS messages themselves. This specification therefore shares with traditional RADIUS the issues of order, reliability, and fragmentation. These issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS [RFC6614].
ただし、この仕様は、RADIUS / UDPに関連するすべての問題を解決するわけではありません。 DTLSプロトコルは、RADIUSに信頼性の高い、または順序正しいトランスポートを追加しません。 DTLSは、アプリケーション層メッセージの断片化、またはDTLSメッセージ自体の断片化もサポートしていません。したがって、この仕様は、順序、信頼性、および断片化の問題を従来のRADIUSと共有します。これらの問題は、RADIUS / TCP [RFC6613]およびRADIUS / TLS [RFC6614]で処理されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用します。
RADIUS/DTLS This term is a shorthand for "RADIUS over DTLS".
RADIUS / DTLSこの用語は「RADIUS over DTLS」の省略形です。
RADIUS/DTLS client This term refers both to RADIUS clients as defined in [RFC2865] and to Dynamic Authorization clients as defined in [RFC5176] that implement RADIUS/DTLS.
RADIUS / DTLSクライアントこの用語は、[RFC2865]で定義されたRADIUSクライアントと、RADIUS / DTLSを実装する[RFC5176]で定義された動的認証クライアントの両方を指します。
RADIUS/DTLS server This term refers both to RADIUS servers as defined in [RFC2865] and to Dynamic Authorization servers as defined in [RFC5176] that implement RADIUS/DTLS.
RADIUS / DTLSサーバーこの用語は、[RFC2865]で定義されているRADIUSサーバーと、[RFC5176]で定義されているRADIUS / DTLSを実装する動的認証サーバーの両方を指します。
RADIUS/UDP RADIUS over UDP, as defined in [RFC2865].
[RFC2865]で定義されているRADIUS / UDP RADIUS over UDP。
RADIUS/TLS RADIUS over TLS, as defined in [RFC6614].
[RFC6614]で定義されているRADIUS / TLS RADIUS over TLS。
silently discard This means that the implementation discards the packet without further processing.
サイレントに破棄するこれは、実装がそれ以上処理せずにパケットを破棄することを意味します。
In this document, several words are used to signify the requirements of the specification. 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 [RFC2119].
このドキュメントでは、仕様の要件を示すためにいくつかの単語が使用されています。キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This document is an Experimental RFC.
このドキュメントは試験的なRFCです。
It contains one of several approaches to address known cryptographic weaknesses of the RADIUS protocol, such as described in [RFC6614]. This specification does not fulfill all recommendations for an Authentication, Authorization, and Accounting (AAA) transport profile as per [RFC3539]; however, unlike [RFC6614], it is based on UDP and therefore does not have head-of-line blocking issues.
[RFC6614]で説明されているように、RADIUSプロトコルの既知の暗号化の弱点に対処するためのいくつかのアプローチの1つが含まれています。この仕様は、[RFC3539]による認証、承認、アカウンティング（AAA）トランスポートプロファイルのすべての推奨事項を満たしているわけではありません。ただし、[RFC6614]とは異なり、UDPに基づいているため、行頭ブロッキングの問題はありません。
If this specification is indeed selected for advancement to Standards Track, certificate verification options ([RFC6614], Section 2.3, point 2) will need to be refined.
この仕様が確かにスタンダードトラックへの移行のために選択された場合、証明書検証オプション（[RFC6614]、セクション2.3、ポイント2）を調整する必要があります。
Another experimental characteristic of this specification is the question of key management between RADIUS/DTLS peers. RADIUS/UDP only allowed for manual key management, i.e., distribution of a shared secret between a client and a server. RADIUS/DTLS allows manual distribution of long-term proofs of peer identity, by using TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509 certificates in a PKIX infrastructure. It remains to be seen if one of these methods will prevail or if both will find their place in real-life deployments. The authors can imagine pre-shared keys (PSKs) to be popular in small-scale deployments (Small Office, Home Office (SOHO) or isolated enterprise deployments) where scalability is not an issue and the deployment of a Certification Authority (CA) is considered too much of a hassle; however, the authors can also imagine large roaming consortia to make use of PKIX. Readers of this specification are encouraged to read the discussion of key management issues within [RFC6421] as well as [RFC4107].
この仕様の別の実験的特性は、RADIUS / DTLSピア間のキー管理の問題です。 RADIUS / UDPは手動の鍵管理、つまりクライアントとサーバー間の共有シークレットの配布にのみ許可されています。 RADIUS / DTLSでは、TLS-PSK暗号スイートを使用して、ピアIDの長期的な証明を手動で配布できます。 RADIUS / DTLSでは、PKIXインフラストラクチャでX.509証明書を使用することもできます。これらの方法のいずれかが普及するのか、それとも実際の展開で両方がその位置を見つけるのかはまだ分からない。作成者は、事前共有キー（PSK）が、スケーラビリティが問題ではなく、証明機関（CA）の展開が問題ではない小規模な展開（小規模オフィス、ホームオフィス（SOHO）、または独立したエンタープライズ展開）で人気があると想像できます。面倒すぎると考えました。ただし、著者はPKIXを利用するために大きなローミングコンソーシアムを想像することもできます。この仕様の読者は、[RFC6421]および[RFC4107]内の主要な管理問題の説明を読むことをお勧めします。
It has yet to be decided whether this approach is to be chosen for Standards Track. One key aspect to judge whether the approach is usable on a large scale is by observing the uptake, usability, and operational behavior of the protocol in large-scale, real-life deployments.
このアプローチをスタンダードトラックに採用するかどうかはまだ決定されていません。アプローチが大規模で使用可能かどうかを判断するための重要な側面の1つは、実際の大規模な展開におけるプロトコルの取り込み、使いやすさ、および動作の動作を観察することです。
Adding DTLS as a RADIUS transport protocol requires a number of changes to systems implementing standard RADIUS. This section outlines those changes, and defines new behaviors necessary to implement DTLS.
DTLSをRADIUSトランスポートプロトコルとして追加するには、標準RADIUSを実装するシステムにいくつかの変更が必要です。このセクションでは、これらの変更の概要を説明し、DTLSの実装に必要な新しい動作を定義します。
The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and [RFC5176]. Specifically, all of the following portions of RADIUS MUST be unchanged when using RADIUS/DTLS:
RADIUSパケットの形式は、[RFC2865]、[RFC2866]、および[RFC5176]から変更されていません。具体的には、RADIUS / DTLSを使用する場合、RADIUSの以下の部分はすべて変更する必要があります。
* Packet format * Permitted codes * Request Authenticator calculation * Response Authenticator calculation * Minimum packet length * Maximum packet length * Attribute format * Vendor-Specific Attribute (VSA) format * Permitted data types * Calculations of dynamic attributes such as CHAP-Challenge, or Message-Authenticator. * Calculation of "obfuscated" attributes such as User-Password and Tunnel-Password.
* パケット形式*許可されたコード*要求認証システムの計算*応答認証システムの計算*最小パケット長*最大パケット長*属性形式*ベンダー固有属性（VSA）形式*許可されたデータ型* CHAP-Challengeやメッセージなどの動的属性の計算-オーセンティケーター。 * User-PasswordやTunnel-Passwordなどの「難読化された」属性の計算。
In short, the application creates a RADIUS packet via the usual methods, and then instead of sending it over a UDP socket, sends the packet to a DTLS layer for encapsulation. DTLS then acts as a transport layer for RADIUS: hence, the names "RADIUS/UDP" and "RADIUS/DTLS".
つまり、アプリケーションは通常の方法でRADIUSパケットを作成し、UDPソケット経由で送信する代わりに、カプセル化のためにパケットをDTLSレイヤーに送信します。 DTLSは、RADIUSのトランスポート層として機能するため、「RADIUS / UDP」および「RADIUS / DTLS」という名前になります。
The requirement that RADIUS remain largely unchanged ensures the simplest possible implementation and widest interoperability of this specification.
RADIUSがほとんど変更されないという要件により、この仕様の可能な最も単純な実装と幅広い相互運用性が保証されます。
We note that the DTLS encapsulation of RADIUS means that RADIUS packets have an additional overhead due to DTLS. Implementations MUST support sending and receiving encapsulated RADIUS packets of 4096 octets in length, with a corresponding increase in the maximum size of the encapsulated DTLS packets. This larger packet size may cause the packet to be larger than the Path MTU (PMTU), where a RADIUS/UDP packet may be smaller. See Section 5.2, below, for more discussion.
RADIUSのDTLSカプセル化とは、RADIUSパケットにDTLSのために追加のオーバーヘッドがあることを意味することに注意してください。実装は、長さが4096オクテットのカプセル化されたRADIUSパケットの送受信をサポートする必要があり、それに応じてカプセル化されたDTLSパケットの最大サイズが増加します。この大きなパケットサイズにより、RADIUS / UDPパケットが小さいパスMTU（PMTU）よりもパケットが大きくなる場合があります。詳細については、以下のセクション5.2を参照してください。
The only changes made from RADIUS/UDP to RADIUS/DTLS are the following two items:
RADIUS / UDPからRADIUS / DTLSへの唯一の変更は、次の2つの項目です。
(1) The Length checks defined in [RFC2865], Section 3, MUST use the length of the decrypted DTLS data instead of the UDP packet length. They MUST treat any decrypted DTLS data octets outside the range of the Length field as padding and ignore it on reception.
（1）[RFC2865]のセクション3で定義されている長さチェックでは、UDPパケット長ではなく、復号化されたDTLSデータの長さを使用する必要があります。それらは、Lengthフィールドの範囲外の復号化されたDTLSデータオクテットをパディングとして扱い、受信時に無視する必要があります。
(2) The shared secret used to compute the MD5 integrity checks and the attribute encryption MUST be "radius/dtls".
（2）MD5整合性チェックと属性暗号化の計算に使用される共有秘密は、「radius / dtls」でなければなりません。
All other aspects of RADIUS are unchanged.
RADIUSの他のすべての側面は変更されていません。
While this specification can be thought of as RADIUS/TLS over UDP instead of the Transmission Control Protocol (TCP), there are some differences between the two methods. The bulk of [RFC6614] applies to this specification, so we do not repeat it here.
この仕様は、伝送制御プロトコル（TCP）ではなく、RADIUS / TLS over UDPと考えることができますが、2つの方法にはいくつかの違いがあります。 [RFC6614]の大部分はこの仕様に適用されるため、ここでは繰り返さない。
This section explains the differences between RADIUS/TLS and RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as follows:
このセクションでは、[RFC6614]へのセマンティックな「パッチ」として、RADIUS / TLSとRADIUS / DTLSの違いについて説明します。変更点は次のとおりです。
* We replace references to "TCP" with "UDP"
* 「TCP」への参照を「UDP」に置き換えます
* We replace references to "RADIUS/TLS" with "RADIUS/DTLS"
* 「RADIUS / TLS」への参照を「RADIUS / DTLS」に置き換えます
* We replace references to "TLS" with "DTLS"
* 「TLS」への参照を「DTLS」に置き換えます
Those changes are sufficient to cover the majority of the differences between the two specifications. The next section reviews some more detailed changes from [RFC6614], giving additional commentary only where necessary.
これらの変更は、2つの仕様の違いの大部分をカバーするのに十分です。次のセクションでは、[RFC6614]からの詳細な変更点をいくつかレビューし、必要な場合にのみ追加の解説を示します。
This section describes how particular sections of [RFC6614] apply to RADIUS/DTLS.
このセクションでは、[RFC6614]の特定のセクションがRADIUS / DTLSにどのように適用されるかについて説明します。
Section 2.1 applies to RADIUS/DTLS, with the exception that the RADIUS/DTLS port is UDP/2083.
セクション2.1はRADIUS / DTLSに適用されますが、RADIUS / DTLSポートはUDP / 2083です。
Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be pre-configured to use RADIUS/DTLS for a given endpoint.
セクション2.2はRADIUS / DTLSに適用されます。サーバーとクライアントは、特定のエンドポイントでRADIUS / DTLSを使用するように事前構成する必要があります。
Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be interpreted as applying to DTLS session initiation, instead of TCP connection establishment. Item (2) applies, except for the recommendation that implementations "SHOULD" support TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical artifact of RADIUS/TLS, and it does not apply to RADIUS/DTLS. Item (3) applies to RADIUS/DTLS. Item (4) applies, except that the fixed shared secret is "radius/dtls", as described above.
セクション2.3のほとんどは、RADIUS / DTLSにも適用されます。項目（1）は、TCP接続の確立ではなく、DTLSセッションの開始に適用されると解釈されます。項目（2）は、実装「SHOULD」がTLS_RSA_WITH_RC4_128_SHAをサポートするという推奨を除いて、適用されます。この推奨事項は、RADIUS / TLSの歴史的な成果物であり、RADIUS / DTLSには適用されません。項目（3）はRADIUS / DTLSに適用されます。上記のように、固定共有秘密が「radius / dtls」であることを除いて、項目（4）が適用されます。
Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be determined from DTLS parameters, instead of relying solely on the source IP address of the packet.
セクション2.4はRADIUS / DTLSに適用されます。クライアントIDは、パケットの送信元IPアドレスのみに依存するのではなく、DTLSパラメータから決定する必要があります。
Section 2.5 does not apply to RADIUS/DTLS. The relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from RADIUS/UDP.
セクション2.5はRADIUS / DTLSには適用されません。 RADIUS / DTLSのRADIUSパケットコードとUDPポートの関係は、RADIUS / UDPから変更されていません。
Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS.
セクション3.1、3.2、および3.3は、RADIUS / DTLSに適用されます。
Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS packet is encapsulated in one DTLS packet, and there is no "stream" of RADIUS packets inside of a TLS session. Implementors MUST enforce the requirements of [RFC2865], Section 3, for the RADIUS Length field, using the length of the decrypted DTLS data for the checks. This check replaces the RADIUS method of using the Length field from the UDP packet.
セクション3.4の項目（1）は、RADIUS / DTLSには適用されません。各RADIUSパケットは1つのDTLSパケットにカプセル化され、TLSセッション内にRADIUSパケットの「ストリーム」はありません。実装者は、チェックに復号化されたDTLSデータの長さを使用して、[RFC2865]、セクション3の要件をRADIUS長さフィールドに適用する必要があります。このチェックは、UDPパケットからの長さフィールドを使用するRADIUSメソッドを置き換えます。
Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS.
セクション3.4の項目（2）、（3）、（4）、および（5）は、RADIUS / DTLSに適用されます。
Section 4 does not apply to RADIUS/DTLS. Protocol compatibility considerations are defined in this document.
セクション4はRADIUS / DTLSには適用されません。プロトコルの互換性に関する考慮事項は、このドキュメントで定義されています。
Section 6 applies to RADIUS/DTLS.
セクション6はRADIUS / DTLSに適用されます。
Transitioning to DTLS is a process that needs to be done carefully. A poorly handled transition is complex for administrators and potentially subject to security downgrade attacks. It is not sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS has no provisions for protocol negotiation, so simply disabling RADIUS/UDP would result in timeouts, lost traffic, and network instabilities.
DTLSへの移行は、慎重に行う必要があるプロセスです。管理の行き届かない移行は管理者にとって複雑であり、セキュリティのダウングレード攻撃を受ける可能性があります。 RADIUS / UDPを無効にしてRADIUS / DTLSを有効にするだけでは不十分です。 RADIUSにはプロトコルネゴシエーションのプロビジョニングがないため、単にRADIUS / UDPを無効にすると、タイムアウト、トラフィックの損失、ネットワークの不安定性が発生します。
The end result of this specification is that nearly all RADIUS/UDP implementations should transition to using a secure alternative. In some cases, RADIUS/UDP may remain where IPsec is used as a transport, or where implementation and/or business reasons preclude a change.
この仕様の最終結果は、ほとんどすべてのRADIUS / UDP実装が安全な代替の使用に移行することです。場合によっては、RADIUS / UDPは、IPsecがトランスポートとして使用されている場合や、実装やビジネス上の理由により変更ができない場合に残ることがあります。
However, we do not recommend long-term use of RADIUS/UDP outside of isolated and secure networks.
ただし、隔離された安全なネットワークの外部でRADIUS / UDPを長期間使用することはお勧めしません。
This section describes how clients and servers should use RADIUS/DTLS, and how it interacts with RADIUS/UDP.
このセクションでは、クライアントとサーバーがRADIUS / DTLSを使用する方法と、RADIUS / UDPと対話する方法について説明します。
The default destination port number for RADIUS/DTLS is UDP/2083. There are no separate ports for authentication, accounting, and dynamic authorization changes. The source port is arbitrary. The text in [RFC6614], Section 3.4, describes issues surrounding the use of one port for multiple packet types. We recognize that implementations may allow the use of RADIUS/DTLS over non-standard ports. In that case, the references to UDP/2083 in this document should be read as applying to any port used for transport of RADIUS/DTLS traffic.
RADIUS / DTLSのデフォルトの宛先ポート番号はUDP / 2083です。認証、アカウンティング、および動的承認の変更に個別のポートはありません。送信元ポートは任意です。 [RFC6614]のセクション3.4のテキストでは、複数のパケットタイプでの1つのポートの使用に関する問題について説明しています。実装により、非標準ポートでのRADIUS / DTLSの使用が許可される場合があることを認識しています。その場合、このドキュメントのUDP / 2083への参照は、RADIUS / DTLSトラフィックの転送に使用されるすべてのポートに適用されるものとして読む必要があります。
When a server receives packets on UDP/2083, all packets MUST be treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on this port.
サーバーがUDP / 2083でパケットを受信するとき、すべてのパケットはDTLSとして扱われる必要があります。 RADIUS / UDPパケットは、このポートで受け入れてはいけません。
Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. Early versions of this specification permitted this behavior. It is forbidden here, as it depended on behavior in DTLS that may change without notice.
サーバーは、古いRADIUS / UDPポートでDTLSパケットを受け入れてはなりません（MUST NOT）。この仕様の初期のバージョンでは、この動作が許可されていました。通知なしに変更される可能性のあるDTLSの動作に依存していたため、ここでは禁止されています。
Servers MUST authenticate clients. RADIUS is designed to be used by mutually trusted systems. Allowing anonymous clients would ensure privacy for RADIUS/DTLS traffic, but would negate all other security aspects of the protocol.
サーバーはクライアントを認証する必要があります。 RADIUSは、相互に信頼されたシステムで使用されるように設計されています。匿名クライアントを許可すると、RADIUS / DTLSトラフィックのプライバシーは確保されますが、プロトコルの他のすべてのセキュリティ面は無効になります。
As RADIUS has no provisions for capability signaling, there is no way for a server to indicate to a client that it should transition to using DTLS. This action has to be taken by the administrators of the two systems, using a method other than RADIUS. This method will likely be out of band, or manual configuration will need to be used.
RADIUSには機能シグナリングのプロビジョニングがないため、サーバーがクライアントにDTLSの使用に移行する必要があることを示す方法はありません。このアクションは、RADIUS以外の方法を使用して、2つのシステムの管理者が行う必要があります。この方法はおそらく帯域外になるか、手動設定を使用する必要があります。
Some servers maintain a list of allowed clients per destination port. Others maintain a global list of clients that are permitted to send packets to any port. Where a client can send packets to multiple ports, the server MUST maintain a "DTLS Required" flag per client.
一部のサーバーは、宛先ポートごとに許可されたクライアントのリストを保持しています。その他は、任意のポートにパケットを送信することが許可されているクライアントのグローバルリストを維持します。クライアントが複数のポートにパケットを送信できる場合、サーバーはクライアントごとに「DTLS必須」フラグを維持する必要があります。
This flag indicates whether or not the client is required to use DTLS. When set, the flag indicates that the only traffic accepted from the client is over UDP/2083. When packets are received from a client on non-DTLS ports, for which DTLS is required, the server MUST silently discard these packets, as there is no RADIUS/UDP shared secret available.
このフラグは、クライアントがDTLSを使用する必要があるかどうかを示します。設定されている場合、このフラグは、クライアントから受け入れられるトラフィックがUDP / 2083経由のみであることを示します。 DTLSが必要な非DTLSポートでクライアントからパケットを受信すると、RADIUS / UDP共有秘密が利用できないため、サーバーはこれらのパケットをサイレントに破棄する必要があります。
This flag will often be set by an administrator. However, if a server receives DTLS traffic from a client, it SHOULD notify the administrator that DTLS is available for that client. It MAY mark the client as "DTLS Required".
このフラグは多くの場合、管理者によって設定されます。ただし、サーバーがクライアントからDTLSトラフィックを受信する場合は、そのクライアントでDTLSが利用可能であることを管理者に通知する必要があります（SHOULD）。クライアントを「DTLS必須」としてマークする場合があります。
It is RECOMMENDED that servers support the following Perfect Forward Secrecy (PFS) ciphersuites:
サーバーが以下のPerfect Forward Secrecy（PFS）暗号スイートをサポートすることをお勧めします。
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the traffic to downbidding attacks and is NOT RECOMMENDED.
同じクライアントからのRADIUS / UDPおよびRADIUS / DTLSを許可すると、トラフィックがダウンビッド攻撃にさらされるため、推奨されません。
When a client sends packets to the assigned RADIUS/DTLS port, all packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this port.
クライアントが割り当てられたRADIUS / DTLSポートにパケットを送信する場合、すべてのパケットはDTLSでなければなりません。 RADIUS / UDPパケットはこのポートに送信してはいけません。
Clients MUST authenticate themselves to servers via credentials that are unique to each client.
クライアントは、各クライアントに固有の資格情報を介してサーバーに対して自身を認証する必要があります。
It is RECOMMENDED that clients support the following PFS ciphersuites:
クライアントが次のPFS暗号スイートをサポートすることをお勧めします。
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
RADIUS/DTLS clients SHOULD NOT probe servers to see if they support DTLS transport. Instead, clients SHOULD use DTLS as a transport layer only when administratively configured. If a client is configured to use DTLS and the server appears to be unresponsive, the client MUST NOT fall back to using RADIUS/UDP. Instead, the client should treat the server as being down.
RADIUS / DTLSクライアントは、DTLSトランスポートをサポートしているかどうかを確認するためにサーバーをプローブするべきではありません（SHOULD NOT）。代わりに、クライアントは、管理上構成されている場合にのみ、トランスポート層としてDTLSを使用する必要があります（SHOULD）。クライアントがDTLSを使用するように構成されており、サーバーが応答していないように見える場合、クライアントはRADIUS / UDPの使用にフォールバックしてはなりません（MUST NOT）。代わりに、クライアントはサーバーをダウンしているものとして扱う必要があります。
RADIUS clients often had multiple independent RADIUS implementations and/or processes that originate packets. This practice was simple to implement, but the result is that each independent subsystem must independently discover network issues or server failures. It is therefore RECOMMENDED that clients with multiple internal RADIUS sources use a local proxy as described in Section 6.1, below.
RADIUSクライアントには、パケットを発信する複数の独立したRADIUS実装やプロセスが含まれていることがよくあります。この方法は簡単に実装できましたが、その結果、各独立したサブシステムはネットワークの問題やサーバーの障害を個別に検出する必要があります。したがって、以下のセクション6.1で説明するように、複数の内部RADIUSソースを持つクライアントはローカルプロキシを使用することをお勧めします。
Clients may implement "pools" of servers for fail-over or load-balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS servers.
クライアントはフェイルオーバーまたは負荷分散のためにサーバーの「プール」を実装できます。これらのプールでは、RADIUS / UDPサーバーとRADIUS / DTLSサーバーを混在させないでください。
Where [RFC6614] can rely on the TCP state machine to perform session tracking, this specification cannot. As a result, implementations of this specification may need to perform session management of the DTLS session in the application layer. This section describes logically how this tracking is done. Implementations may choose to use the method described here, or another, equivalent method.
[RFC6614]がセッショントラッキングを実行するためにTCPステートマシンに依存できる場合、この仕様はそうではありません。その結果、この仕様の実装では、アプリケーション層でDTLSセッションのセッション管理を実行する必要がある場合があります。このセクションでは、この追跡がどのように行われるかを論理的に説明します。実装では、ここで説明されている方法または別の同等の方法を使用することを選択できます。
We note that [RFC5080], Section 2.2.2, already mandates a duplicate detection cache. The session tracking described below can be seen as an extension of that cache, where entries contain DTLS sessions instead of RADIUS/UDP packets.
[RFC5080]のセクション2.2.2では、重複検出キャッシュがすでに義務付けられていることに注意してください。以下で説明するセッショントラッキングは、キャッシュの拡張と見なすことができ、エントリにはRADIUS / UDPパケットの代わりにDTLSセッションが含まれます。
[RFC5080], Section 2.2.2, describes how duplicate RADIUS/UDP requests result in the retransmission of a previously cached RADIUS/UDP response. Due to DTLS sequence window requirements, a server MUST NOT retransmit a previously sent DTLS packet. Instead, it should cache the RADIUS response packet, and re-process it through DTLS to create a new RADIUS/DTLS packet, every time it is necessary to retransmit a RADIUS response.
[RFC5080]のセクション2.2.2では、RADIUS / UDPリクエストが重複すると、以前にキャッシュされたRADIUS / UDP応答が再送信される方法が説明されています。 DTLSシーケンスウィンドウの要件により、サーバーは以前に送信されたDTLSパケットを再送信してはなりません（MUST NOT）。代わりに、RADIUS応答を再送信する必要があるたびに、RADIUS応答パケットをキャッシュし、DTLSで再処理して新しいRADIUS / DTLSパケットを作成する必要があります。
A RADIUS/DTLS server MUST track ongoing DTLS sessions for each, based on the following 4-tuple:
RADIUS / DTLSサーバーは、次の4タプルに基づいて、それぞれの進行中のDTLSセッションを追跡する必要があります。
* source IP address * source port * destination IP address * destination port
* 送信元IPアドレス*送信元ポート*宛先IPアドレス*宛先ポート
Note that this 4-tuple is independent of IP address version (IPv4 or IPv6).
この4タプルは、IPアドレスのバージョン（IPv4またはIPv6）に依存しないことに注意してください。
Each 4-tuple points to a unique session entry, which usually contains the following information:
それぞれの4タプルは、通常次の情報を含む一意のセッションエントリを指します。
DTLS Session Any information required to maintain and manage the DTLS session.
DTLSセッションDTLSセッションの維持と管理に必要な情報。
Last Traffic A variable containing a timestamp that indicates when this session last received valid traffic. If "Last Traffic" is not used, this variable may not exist.
最終トラフィックこのセッションが最後に有効なトラフィックをいつ受信したかを示すタイムスタンプを含む変数。 「最終トラフィック」を使用しない場合、この変数は存在しない可能性があります。
DTLS Data An implementation-specific variable that may contain information about the active DTLS session. This variable may be empty or nonexistent.
DTLSデータアクティブなDTLSセッションに関する情報を含む可能性のある実装固有の変数。この変数は空であるか、存在しない可能性があります。
This data will typically contain information such as idle timeouts, session lifetimes, and other implementation-specific data.
このデータには通常、アイドルタイムアウト、セッションライフタイム、およびその他の実装固有のデータなどの情報が含まれます。
Session tracking is subject to Denial-of-Service (DoS) attacks due to the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers SHOULD use the stateless cookie tracking technique described in [RFC6347], Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a ClientHello packet has been received with an appropriate Cookie value. Server implementation SHOULD have a way of tracking DTLS sessions that are partially set up. Servers MUST limit both the number and impact on resources of partial sessions.
攻撃者がUDPトラフィックを偽造できるため、セッション追跡はサービス拒否（DoS）攻撃の影響を受けます。 RADIUS / DTLSサーバーは、[RFC6347]のセクション4.2.1で説明されているステートレスCookieトラッキング手法を使用する必要があります（SHOULD）。 DTLSセッションは、ClientHelloパケットが適切なCookie値で受信されるまで追跡されるべきではありません（SHOULD NOT）。サーバーの実装には、部分的に設定されているDTLSセッションを追跡する方法が必要です（SHOULD）。サーバーは、部分セッションの数とリソースへの影響の両方を制限する必要があります。
Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure Alert ([RFC5246], Section 7.2.1) or a fatal TLS Error Alert ([RFC5246], Section 7.2.2) is received. When a session is deleted due to it failing security requirements, the DTLS session MUST be closed, any TLS session resumption parameters for that session MUST be discarded, and all tracking information MUST be deleted.
セッション（4タプルとエントリの両方）は、TLSクロージャアラート（[RFC5246]、セクション7.2.1）または致命的なTLSエラーアラート（[RFC5246]、セクション7.2.2）を受信したときに削除する必要があります。セキュリティ要件が満たされていないためにセッションが削除された場合は、DTLSセッションを閉じなければならず、そのセッションのTLSセッション再開パラメータを破棄しなければならず、すべての追跡情報を削除しなければなりません（MUST）。
Sessions MUST also be deleted when a RADIUS packet fails validation due to a packet being malformed, or when it has an invalid Message-Authenticator or invalid Request Authenticator. There are other cases when the specifications require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying session as described above. There are few reasons to communicate with a Network Access Server (NAS) that is not implementing RADIUS.
パケットの形式が正しくないためにRADIUSパケットが検証に失敗した場合、または無効なメッセージ認証子または無効な要求認証子が含まれている場合も、セッションを削除する必要があります。 DTLSセッションを介して受信したパケットを「サイレントに破棄する」ことが仕様で要求されている他のケースがあります。それらの場合、実装は上記のように基礎となるセッションを削除してもよい（MAY）。 RADIUSを実装していないネットワークアクセスサーバー（NAS）と通信する理由はいくつかあります。
A session MUST be deleted when non-RADIUS traffic is received over it. This specification is for RADIUS, and there is no reason to allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST be deleted when RADIUS traffic fails to pass security checks. There is no reason to permit insecure networks. A session SHOULD NOT be deleted when a well-formed, but "unexpected", RADIUS packet is received over it. Future specifications may extend RADIUS/DTLS, and we do not want to forbid those specifications.
非RADIUSトラフィックが受信された場合、セッションを削除する必要があります。この仕様はRADIUS用であり、RADIUS / DTLSセッションを介して非RADIUSトラフィックを許可する理由はありません。 RADIUSトラフィックがセキュリティチェックに合格しなかった場合は、セッションを削除する必要があります。安全でないネットワークを許可する理由はありません。整形式であるが「予期しない」RADIUSパケットが受信された場合、セッションは削除されるべきではない（SHOULD NOT）。将来の仕様ではRADIUS / DTLSが拡張される可能性があり、これらの仕様を禁止したくありません。
The goal of the above requirements is to ensure security, while maintaining flexibility. Any security-related issue causes the connection to be closed. After the security restrictions have been applied, any unexpected traffic may be safely ignored, as it cannot cause a security issue. There is no need to close the session for unexpected but valid traffic, and the session can safely remain open.
上記の要件の目標は、柔軟性を維持しながらセキュリティを確保することです。セキュリティ関連の問題が発生すると、接続が閉じられます。セキュリティ制限が適用された後は、セキュリティ上の問題を引き起こす可能性がないため、予期しないトラフィックは無視しても安全です。予期しないが有効なトラフィックのためにセッションを閉じる必要はなく、セッションは安全に開いたままにすることができます。
Once a DTLS session is established, a RADIUS/DTLS server SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity between the two servers. A server SHOULD also use watchdog packets from the client to determine that the session is still active.
DTLSセッションが確立されると、RADIUS / DTLSサーバーは、DTLSハートビート[RFC6520]を使用して、2つのサーバー間の接続を決定する必要があります（SHOULD）。サーバーは、クライアントからのウォッチドッグパケットも使用して、セッションがまだアクティブであることを確認する必要があります（SHOULD）。
As UDP does not guarantee delivery of messages, RADIUS/DTLS servers that do not implement an application-layer watchdog MUST also maintain a "Last Traffic" timestamp per DTLS session. The granularity of this timestamp is not critical and could be limited to one-second intervals. The timestamp SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no more than once per interval. The timestamp MUST NOT be updated in other situations.
UDPはメッセージの配信を保証しないため、アプリケーション層ウォッチドッグを実装しないRADIUS / DTLSサーバーは、DTLSセッションごとに「最終トラフィック」タイムスタンプも維持する必要があります。このタイムスタンプの細かさは重要ではなく、1秒間隔に制限される場合があります。タイムスタンプは、有効なRADIUS / DTLSパケットまたはDTLSハートビートの受信時に更新する必要がありますが、間隔ごとに1回だけです。他の状況では、タイムスタンプを更新してはなりません。
When a session has not received a packet for a period of time, it is labeled "idle". The server SHOULD delete idle DTLS sessions after an "idle timeout". The server MAY cache the TLS session parameters, in order to provide for fast session resumption.
セッションが一定期間パケットを受信しなかった場合、「アイドル」というラベルが付けられます。サーバーは、「アイドルタイムアウト」後にアイドルDTLSセッションを削除する必要があります（SHOULD）。サーバーは、高速セッション再開を提供するために、TLSセッションパラメータをキャッシュしてもよい（MAY）。
This session "idle timeout" SHOULD be exposed to the administrator as a configurable setting. It SHOULD NOT be set to less than 60 seconds and SHOULD NOT be set to more than 600 seconds (10 minutes). The minimum useful value for this timer is determined by the application-layer watchdog mechanism defined in the following section.
このセッションの「アイドルタイムアウト」は、構成可能な設定として管理者に公開する必要があります。 60秒未満に設定してはならず（SHOULD NOT）、600秒（10分）より長く設定してはなりません（SHOULD NOT）。このタイマーの有用な最小値は、次のセクションで定義するアプリケーション層のウォッチドッグメカニズムによって決定されます。
RADIUS/DTLS servers SHOULD also monitor the total number of open sessions. They SHOULD have a "maximum sessions" setting exposed to administrators as a configurable parameter. When this maximum is reached and a new session is started, the server MUST either drop an old session in order to open the new one or not create a new session.
RADIUS / DTLSサーバーは、開いているセッションの総数も監視する必要があります（SHOULD）。それらは、構成可能なパラメーターとして管理者に公開される「最大セッション」設定を持つ必要があります。この最大数に達して新しいセッションが開始されると、サーバーは新しいセッションを開くために古いセッションをドロップするか、新しいセッションを作成しないかのいずれかでなければなりません。
RADIUS/DTLS servers SHOULD implement session resumption, preferably stateless session resumption as given in [RFC5077]. This practice lowers the time and effort required to start a DTLS session with a client and increases network responsiveness.
RADIUS / DTLSサーバーは、セッション再開、できれば[RFC5077]で規定されているステートレスセッション再開を実装する必要があります（SHOULD）。これにより、クライアントとのDTLSセッションを開始するために必要な時間と労力が削減され、ネットワークの応答性が向上します。
Since UDP is stateless, the potential exists for the client to initiate a new DTLS session using a particular 4-tuple, before the server has closed the old session. For security reasons, the server MUST keep the old session active until either it has received secure notification from the client that the session is closed or the server decides to close the session based on idle timeouts. Taking any other action would permit unauthenticated clients to perform a DoS attack, by reusing a 4-tuple and thus causing the server to close an active (and authenticated) DTLS session.
UDPはステートレスであるため、サーバーが古いセッションを閉じる前に、クライアントが特定の4タプルを使用して新しいDTLSセッションを開始する可能性があります。セキュリティ上の理由から、サーバーは、セッションが閉じられたというクライアントからの安全な通知を受信するか、サーバーがアイドルタイムアウトに基づいてセッションを閉じることを決定するまで、古いセッションをアクティブに維持する必要があります。その他のアクションを実行すると、認証されていないクライアントが4タプルを再利用してDoS攻撃を実行できるようになり、サーバーがアクティブな（認証された）DTLSセッションを閉じるようになります。
As a result, servers MUST ignore any attempts to reuse an existing 4-tuple from an active session. This requirement can likely be reached by simply processing the packet through the existing session, as with any other packet received via that 4-tuple. Non-compliant, or unexpected packets will be ignored by the DTLS layer.
その結果、サーバーはアクティブなセッションから既存の4タプルを再利用する試みを無視する必要があります。この要件は、その4タプルを介して受信される他のパケットと同様に、既存のセッションを介してパケットを処理するだけで達成できる可能性があります。非準拠または予期しないパケットは、DTLSレイヤーによって無視されます。
The above requirement is mitigated by the suggestion in Section 6.1, below, that the client use a local proxy for all RADIUS traffic. That proxy can then track the ports that it uses and ensure that reuse of 4-tuples is avoided. The exact process by which this tracking is done is outside of the scope of this document.
上記の要件は、クライアントがすべてのRADIUSトラフィックにローカルプロキシを使用するという以下のセクション6.1の提案によって緩和されます。そのプロキシは、使用するポートを追跡し、4タプルの再利用を確実に回避できます。この追跡が行われる正確なプロセスは、このドキュメントの範囲外です。
Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU between the client and server, prior to sending any RADIUS traffic. Once a DTLS session is established, a RADIUS/DTLS client SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity between the two systems. RADIUS/DTLS clients SHOULD also use the application-layer watchdog algorithm defined in [RFC3539] to determine server responsiveness. The Status-Server packet defined in [RFC5997] SHOULD be used as the "watchdog packet" in any application-layer watchdog algorithm.
クライアントは、RADIUSトラフィックを送信する前に、PMTU検出[RFC6520]を使用して、クライアントとサーバー間のPMTUを決定する必要があります（SHOULD）。 DTLSセッションが確立されると、RADIUS / DTLSクライアントは、DTLSハートビート[RFC6520]を使用して、2つのシステム間の接続を決定する必要があります（SHOULD）。 RADIUS / DTLSクライアントは、[RFC3539]で定義されているアプリケーション層ウォッチドッグアルゴリズムを使用してサーバーの応答性を判断する必要もあります（SHOULD）。 [RFC5997]で定義されているStatus-Serverパケットは、任意のアプリケーション層ウォッチドッグアルゴリズムで「ウォッチドッグパケット」として使用する必要があります（SHOULD）。
RADIUS/DTLS clients SHOULD proactively close sessions when they have been idle for a period of time. Clients SHOULD close a session when the DTLS Heartbeat algorithm indicates that the session is no longer active. Clients SHOULD close a session when no traffic other than watchdog packets and (possibly) watchdog responses has been sent for three watchdog timeouts. This behavior ensures that clients do not waste resources on the server by causing it to track idle sessions.
RADIUS / DTLSクライアントは、一定期間アイドル状態になったときに、積極的にセッションを閉じる必要があります（SHOULD）。クライアントは、DTLSハートビートアルゴリズムがセッションがアクティブではなくなったことを示したときに、セッションを閉じる必要があります（SHOULD）。ウォッチドッグパケットと（おそらく）ウォッチドッグ応答以外のトラフィックが3つのウォッチドッグタイムアウトで送信されなかった場合、クライアントはセッションを閉じる必要があります（SHOULD）。この動作により、クライアントはサーバーにアイドルセッションを追跡させることにより、サーバー上のリソースを無駄にしないことが保証されます。
When a client fails to implement both DTLS Heartbeats and watchdog packets, it has no way of knowing that a DTLS session has been closed. Therefore, there is the possibility that the server closes the session without the client knowing. When that happens, the client may later transmit packets in a session, and those packets will be ignored by the server. The client is then forced to time out those packets and then the session, leading to delays and network instabilities.
クライアントがDTLSハートビートとウォッチドッグパケットの両方の実装に失敗した場合、クライアントはDTLSセッションが閉じられたことを知る方法がありません。したがって、クライアントが知らないうちにサーバーがセッションを閉じる可能性があります。その場合、クライアントは後でセッションでパケットを送信する可能性があり、それらのパケットはサーバーによって無視されます。その後、クライアントはそれらのパケットとセッションのタイムアウトを強制され、遅延とネットワークの不安定性を引き起こします。
For these reasons, it is RECOMMENDED that all DTLS sessions be configured to use DTLS Heartbeats and/or watchdog packets.
これらの理由により、すべてのDTLSセッションは、DTLSハートビートやウォッチドッグパケットを使用するように構成することをお勧めします。
DTLS sessions MUST also be deleted when a RADIUS packet fails validation due to a packet being malformed, or when it has an invalid Message-Authenticator or invalid Response Authenticator. There are other cases when the specifications require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying DTLS session.
パケットの形式が正しくないためにRADIUSパケットが検証に失敗した場合、または無効なメッセージ認証または無効な応答認証が含まれている場合も、DTLSセッションを削除する必要があります。 DTLSセッションを介して受信したパケットを「サイレントに破棄する」ことが仕様で要求されている他のケースがあります。それらの場合、実装は基礎となるDTLSセッションを削除してもよい（MAY）。
RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS packets to different servers from the same source socket. This practice causes increased complexity in the client application and increases the potential for security breaches due to implementation issues.
RADIUS / DTLSクライアントは、RADIUS / UDPパケットとRADIUS / DTLSパケットの両方を同じソースソケットから異なるサーバーに送信しないでください。この方法により、クライアントアプリケーションの複雑さが増し、実装の問題によるセキュリティ違反の可能性が高まります。
RADIUS/DTLS clients SHOULD implement session resumption, preferably stateless session resumption as given in [RFC5077]. This practice lowers the time and effort required to start a DTLS session with a server and increases network responsiveness.
RADIUS / DTLSクライアントは、セッション再開、できればステートレスセッション再開を実装する必要があります[RFC5077]。この方法により、サーバーとのDTLSセッションを開始するために必要な時間と労力が削減され、ネットワークの応答性が向上します。
The text above describes the protocol. In this section, we give additional implementation guidelines. These guidelines are not part of the protocol, but they may help implementors create simple, secure, and interoperable implementations.
上記のテキストはプロトコルを説明しています。このセクションでは、追加の実装ガイドラインを示します。これらのガイドラインはプロトコルの一部ではありませんが、実装者がシンプルで安全な相互運用可能な実装を作成するのに役立つ場合があります。
Where a TLS-PSK method is used, implementations MUST support keys of at least 16 octets in length. Implementations SHOULD support key lengths of 32 octets and SHOULD allow for longer keys. The key data MUST be capable of being any value (0 through 255, inclusive). Implementations MUST NOT limit themselves to using textual keys. It is RECOMMENDED that the administration interface allow for the keys to be entered as human-readable strings in hex format.
TLS-PSK方式が使用される場合、実装は少なくとも16オクテットの長さのキーをサポートしなければなりません（MUST）。実装は、32オクテットのキー長をサポートする必要があり（SHOULD）、より長いキーを許可する必要があります（SHOULD）。キーデータは、任意の値（0から255まで）である必要があります。実装は、テキストキーの使用に限定してはなりません。管理インターフェイスでは、キーを16進形式の人間が読める文字列として入力できるようにすることをお勧めします。
When creating keys for use with PSK ciphersuites, it is RECOMMENDED that keys be derived from a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) instead of administrators inventing keys on their own. If managing keys is too complicated, a certificate-based TLS method SHOULD be used instead.
PSK暗号スイートで使用するキーを作成する場合は、管理者が独自にキーを作成するのではなく、暗号的に安全な疑似乱数ジェネレータ（CSPRNG）からキーを取得することをお勧めします。キーの管理が複雑すぎる場合は、代わりに証明書ベースのTLSメソッドを使用する必要があります（SHOULD）。
RADIUS/DTLS clients should use connected sockets where possible. Use of connected sockets means that the underlying kernel tracks the sessions, so that the client subsystem does not need to manage multiple sessions on one socket.
RADIUS / DTLSクライアントは、可能な場合、接続されたソケットを使用する必要があります。接続されたソケットを使用すると、基盤となるカーネルがセッションを追跡するため、クライアントサブシステムは1つのソケットで複数のセッションを管理する必要がありません。
RADIUS/DTLS clients should use a single source (IP + port) when sending packets to a particular RADIUS/DTLS server. Doing so minimizes the number of DTLS session setups. It also ensures that information about the home server state is discovered only once.
RADIUS / DTLSクライアントは、特定のRADIUS / DTLSサーバーにパケットを送信するときに単一のソース（IP +ポート）を使用する必要があります。そうすることで、DTLSセッション設定の数を最小限に抑えることができます。また、ホームサーバーの状態に関する情報が1回だけ検出されるようにします。
In practice, this means that RADIUS/DTLS clients with multiple internal RADIUS sources should use a local proxy that arbitrates all RADIUS traffic between the client and all servers. The proxy should accept traffic only from the authorized subsystems on the client machine and should proxy that traffic to known servers. Each authorized subsystem should include an attribute that uniquely identifies that subsystem to the proxy, so that the proxy can apply origin-specific proxy rules and security policies. We suggest using NAS-Identifier for this purpose.
実際には、これは、複数の内部RADIUSソースを持つRADIUS / DTLSクライアントが、クライアントとすべてのサーバー間のすべてのRADIUSトラフィックを調停するローカルプロキシを使用する必要があることを意味します。プロキシは、クライアントマシン上の承認されたサブシステムからのトラフィックのみを受け入れ、そのトラフィックを既知のサーバーにプロキシする必要があります。承認された各サブシステムには、プロキシに対してそのサブシステムを一意に識別する属性を含める必要があります。これにより、プロキシはオリジン固有のプロキシルールとセキュリティポリシーを適用できます。この目的でNAS-Identifierを使用することをお勧めします。
The local proxy should be able to interact with multiple servers at the same time. There is no requirement that each server have its own unique proxy on the client, as that would be inefficient.
ローカルプロキシは、同時に複数のサーバーと対話できる必要があります。非効率的であるため、各サーバーがクライアント上に独自の一意のプロキシを持っている必要はありません。
The suggestion to use a local proxy means that there is only one process that discovers network and/or connectivity issues with a server. If each client subsystem communicated directly with a server, issues with that server would have to be discovered independently by each subsystem. The side effect would be increased delays in re-routing traffic, error reporting, and network instabilities.
ローカルプロキシを使用するという提案は、サーバーのネットワークや接続の問題を発見するプロセスが1つしかないことを意味します。各クライアントサブシステムがサーバーと直接通信する場合、そのサーバーの問題は、各サブシステムによって個別に検出する必要があります。副作用として、トラフィックの再ルーティングの遅延、エラー報告、およびネットワークの不安定性があります。
Each client subsystem can include a subsystem-specific NAS-Identifier in each request. The format of this attribute is implementation-specific. The proxy should verify that the request originated from the local system, ideally via a loopback address. The proxy MUST then rewrite any subsystem-specific NAS-Identifier to a NAS-Identifier that identifies the client as a whole, or, remove the NAS-Identifier entirely and replace it with NAS-IP-Address or NAS-IPv6-Address.
各クライアントサブシステムは、各要求にサブシステム固有のNAS識別子を含めることができます。この属性の形式は実装固有です。プロキシは、リクエストがローカルシステムから、理想的にはループバックアドレスを介して発信されたことを確認する必要があります。次に、プロキシは、サブシステム固有のNAS-Identifierをクライアント全体を識別するNAS-Identifierに書き換える必要があります。または、NAS-Identifierを完全に削除して、NAS-IP-AddressまたはNAS-IPv6-Addressに置き換えます。
In traditional RADIUS, the cost to set up a new "session" between a client and server was minimal. The client subsystem could simply open a port, send a packet, wait for the response, and then close the port. With RADIUS/DTLS, the connection setup is significantly more expensive. In addition, there may be a requirement to use DTLS in order to communicate with a server, as RADIUS/UDP may not be supported by that server. The knowledge of what protocol to use is best managed by a dedicated RADIUS subsystem, rather than by each individual subsystem on the client.
従来のRADIUSでは、クライアントとサーバーの間に新しい「セッション」を設定するコストは最小限でした。クライアントサブシステムは、単にポートを開いてパケットを送信し、応答を待ってからポートを閉じるだけです。 RADIUS / DTLSを使用すると、接続設定のコストが大幅に高くなります。さらに、RADIUS / UDPがサーバーでサポートされていない可能性があるため、サーバーと通信するためにDTLSを使用する必要がある場合があります。使用するプロトコルの知識は、クライアント上の個々のサブシステムではなく、専用のRADIUSサブシステムによって管理するのが最適です。
RADIUS/DTLS servers should not use connected sockets to read DTLS packets from a client. This recommendation exists because a connected UDP socket will accept packets only from one source IP address and port. This limitation would prevent the server from accepting packets from multiple clients on the same port.
RADIUS / DTLSサーバーは、接続されたソケットを使用してクライアントからDTLSパケットを読み取るべきではありません。接続されたUDPソケットは1つのソースIPアドレスとポートからのパケットのみを受け入れるため、この推奨事項が存在します。この制限により、サーバーは同じポート上の複数のクライアントからのパケットを受け入れることができなくなります。
This specification defines a transport layer for RADIUS. It makes no other changes to the RADIUS protocol. As a result, there are no Diameter considerations.
この仕様は、RADIUSのトランスポート層を定義します。 RADIUSプロトコルに他の変更は加えません。その結果、Diameterに関する考慮事項はありません。
No new RADIUS attributes or packet codes are defined. IANA has updated the "Service Name and Transport Protocol Port Number Registry". The entries corresponding to port service name "radsec", port number "2083", and transport protocol "UDP" have been updated as follows:
新しいRADIUS属性やパケットコードは定義されていません。 IANAは、「Service Name and Transport Protocol Port Number Registry」を更新しました。ポートサービス名「radsec」、ポート番号「2083」、およびトランスポートプロトコル「UDP」に対応するエントリが次のように更新されました。
o Assignee: IESG
o 譲受人：IESG
o Contact: IETF Chair
o 連絡先：IETF議長
o Reference: This document
o 参照：このドキュメント
o Assignment Notes: The UDP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/TLS, prior to issuance of this RFC.
o 割り当てに関する注意：UDPポート2083は、このRFCが発行される前に、RADIUS / TLSの初期実装である "RadSec"のためにIANAによって以前に割り当てられていました。
This section records the status of known implementations of RADIUS/DTLS at the time of writing, and is based on a proposal described in [RFC6982].
このセクションは、執筆時点でのRADIUS / DTLSの既知の実装のステータスを記録し、[RFC6982]で説明されている提案に基づいています。
The description of implementations in this section is intended to assist the IETF in its decision processes in progressing Internet-Drafts to RFCs.
このセクションの実装の説明は、RFCへのインターネットドラフトの進行における決定プロセスにおいてIETFを支援することを目的としています。
Organization: Radsecproxy
組織：Radsecproxy
URL: https://software.uninett.no/radsecproxy/
Maturity: Widely used software based on early versions of this document. The use of the DTLS functionality is not clear.
成熟度：このドキュメントの初期バージョンに基づいて広く使用されているソフトウェア。 DTLS機能の使用は明確ではありません。
Coverage: The bulk of this specification is implemented, based on earlier versions of this document. Exact revisions that were implemented are unknown.
対象範囲：このドキュメントの以前のバージョンに基づいて、この仕様の大部分が実装されています。実装された正確なリビジョンは不明です。
Licensing: Freely distributable with acknowledgment.
ライセンス：謝辞付きで自由に配布できます。
Implementation experience: No comments from implementors.
実装経験：実装者からのコメントはありません。
Organization: Coova
組織：Coova
URL: http://www.coova.org/JRadius/RadSec
Maturity: Production software based on early versions of this document. The use of the DTLS functionality is not clear.
成熟度：このドキュメントの初期バージョンに基づく製品ソフトウェア。 DTLS機能の使用は明確ではありません。
Coverage: The bulk of this specification is implemented, based on earlier versions of this document. Exact revisions that were implemented are unknown.
対象範囲：このドキュメントの以前のバージョンに基づいて、この仕様の大部分が実装されています。実装された正確なリビジョンは不明です。
Licensing: Freely distributable with requirement to redistribute source.
ライセンス：ソースを再配布する必要があるため、自由に配布できます。
Implementation experience: No comments from implementors.
実装経験：実装者からのコメントはありません。
The bulk of this specification is devoted to discussing security considerations related to RADIUS. However, we discuss a few additional issues here.
この仕様の大部分は、RADIUSに関連するセキュリティの考慮事項を説明することに専念しています。ただし、ここではいくつかの追加の問題について説明します。
This specification relies on the existing DTLS, RADIUS/UDP, and RADIUS/TLS specifications. As a result, all security considerations for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the TLS and RADIUS security issues discussed in [RFC6614] also apply to this specification. Most of the security considerations for RADIUS apply to the RADIUS portion of the specification.
この仕様は、既存のDTLS、RADIUS / UDP、およびRADIUS / TLS仕様に依存しています。その結果、DTLSのセキュリティに関するすべての考慮事項は、RADIUS / DTLSのDTLS部分に適用されます。同様に、[RFC6614]で説明されているTLSおよびRADIUSのセキュリティ問題もこの仕様に適用されます。 RADIUSのセキュリティに関する考慮事項のほとんどは、仕様のRADIUS部分に適用されます。
However, many security considerations raised in the RADIUS documents are related to RADIUS encryption and authorization. Those issues are largely mitigated when DTLS is used as a transport method. The issues that are not mitigated by this specification are related to the RADIUS packet format and handling, which is unchanged in this specification.
ただし、RADIUS文書で提起されたセキュリティの考慮事項の多くは、RADIUSの暗号化と承認に関連しています。これらの問題は、DTLSがトランスポート方式として使用される場合に大幅に軽減されます。この仕様で緩和されない問題は、RADIUSパケットのフォーマットと処理に関連していますが、この仕様では変更されていません。
This specification also suggests that implementations use a session tracking table. This table is an extension of the duplicate detection cache mandated in [RFC5080], Section 2.2.2. The changes given here are that DTLS-specific information is tracked for each table entry. Section 5.1.1, above, describes steps to mitigate any DoS issues that result from tracking additional information.
この仕様は、実装がセッション追跡テーブルを使用することも示唆しています。この表は、[RFC5080]のセクション2.2.2で義務付けられている重複検出キャッシュの拡張です。ここでの変更点は、DTLS固有の情報がテーブルエントリごとに追跡されることです。上記のセクション5.1.1では、追加情報の追跡から生じるDoSの問題を軽減する手順について説明しています。
The fixed shared secret given above in Section 2.2.1 is acceptable only when DTLS is used with a non-null encryption method. When a DTLS session uses a null encryption method due to misconfiguration or implementation error, all of the RADIUS traffic will be readable by an observer. Therefore, implementations MUST NOT use null encryption methods for RADIUS/DTLS.
上記のセクション2.2.1で示した固定共有シークレットは、DTLSがnull以外の暗号化方式で使用されている場合にのみ許容されます。設定ミスまたは実装エラーのためにDTLSセッションでnull暗号化方式が使用されている場合、オブザーバーはすべてのRADIUSトラフィックを読み取ることができます。したがって、実装では、RADIUS / DTLSにnull暗号化方式を使用してはなりません（MUST NOT）。
For systems that perform protocol-based firewalling and/or filtering, it is RECOMMENDED that they be configured to permit only DTLS over the RADIUS/DTLS port.
プロトコルベースのファイアウォールやフィルタリングを実行するシステムの場合、RADIUS / DTLSポートを介したDTLSのみを許可するように構成することをお勧めします。
Section 4.2 of [RFC6421] makes a number of recommendations about security properties of new RADIUS proposals. All of those recommendations are satisfied by using DTLS as the transport layer.
[RFC6421]のセクション4.2は、新しいRADIUS提案のセキュリティプロパティに関するいくつかの推奨事項を作成します。これらの推奨事項はすべて、トランスポート層としてDTLSを使用することで満たされます。
Section 4.3 of [RFC6421] makes a number of recommendations about backwards compatibility with RADIUS. Section 3, above, addresses these concerns in detail.
[RFC6421]のセクション4.3は、RADIUSとの下位互換性について多くの推奨事項を示しています。上記のセクション3では、これらの懸念について詳細に説明しています。
Section 4.4 of [RFC6421] recommends that change control be ceded to the IETF, and that interoperability is possible. Both requirements are satisfied.
[RFC6421]のセクション4.4は、変更管理をIETFに譲ることと、相互運用が可能であることを推奨しています。両方の要件が満たされています。
Section 4.5 of [RFC6421] requires that the new security methods apply to all packet types. This requirement is satisfied by allowing DTLS to be used for all RADIUS traffic. In addition, Section 3, above, addresses concerns about documenting the transition from legacy RADIUS to crypto-agile RADIUS.
[RFC6421]のセクション4.5では、新しいセキュリティメソッドをすべてのパケットタイプに適用する必要があります。この要件は、すべてのRADIUSトラフィックにDTLSを使用できるようにすることで満たされます。さらに、上記のセクション3では、レガシーRADIUSから暗号化アジャイルRADIUSへの移行を文書化することに関する懸念に対処しています。
Section 4.6 of [RFC6421] requires automated key management. This requirement is satisfied by using DTLS key management.
[RFC6421]のセクション4.6では、自動キー管理が必要です。この要件は、DTLSキー管理を使用することで満たされます。
We reiterate here the poor security of the legacy RADIUS protocol. We suggest that RADIUS clients and servers implement either this specification or [RFC6614]. New attacks on MD5 have appeared over the past few years, and there is a distinct possibility that MD5 may be completely broken in the near future. Such a break would mean that RADIUS/UDP was completely insecure.
ここでは、レガシーRADIUSプロトコルの不十分なセキュリティについて繰り返し説明します。 RADIUSクライアントとサーバーは、この仕様または[RFC6614]のいずれかを実装することをお勧めします。 MD5に対する新しい攻撃が過去数年にわたって発生しており、MD5が近い将来に完全に破壊される可能性があることは明らかです。このような中断は、RADIUS / UDPが完全に安全でないことを意味します。
The existence of fast and cheap attacks on MD5 could result in a loss of all network security that depends on RADIUS. Attackers could obtain user passwords and possibly gain complete network access. We cannot overstate the disastrous consequences of a successful attack on RADIUS.
MD5に対する高速で安価な攻撃が存在すると、RADIUSに依存するすべてのネットワークセキュリティが失われる可能性があります。攻撃者はユーザーパスワードを入手し、場合によっては完全なネットワークアクセスを取得する可能性があります。 RADIUSへの攻撃の成功による悲惨な結果を誇張することはできません。
We also caution implementors (especially client implementors) about using RADIUS/DTLS. It may be tempting to use the shared secret as the basis for a TLS-PSK method and to leave the user interface otherwise unchanged. This practice MUST NOT be used. The administrator MUST be given the option to use DTLS. Any shared secret used for RADIUS/UDP MUST NOT be used for DTLS. Reusing a shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of the benefits found by using DTLS.
また、RADIUS / DTLSの使用について実装者（特にクライアント実装者）にも注意を促しています。共有シークレットをTLS-PSKメソッドの基礎として使用し、それ以外の場合はユーザーインターフェイスを変更しないようにしたくなるかもしれません。この方法は使用してはなりません。管理者には、DTLSを使用するオプションを与える必要があります。 RADIUS / UDPに使用される共有秘密は、DTLSに使用してはなりません。 RADIUS / UDPとRADIUS / DTLSの間で共有シークレットを再利用すると、DTLSを使用することで得られるすべての利点が失われます。
RADIUS/DTLS client implementors MUST expose a configuration that allows the administrator to choose the ciphersuite. Where certificates are used, RADIUS/DTLS client implementors MUST expose a configuration that allows an administrator to configure all certificates necessary for certificate-based authentication. These certificates include client, server, and root certificates.
RADIUS / DTLSクライアントの実装者は、管理者が暗号スイートを選択できるようにする構成を公開する必要があります。証明書が使用される場合、RADIUS / DTLSクライアントの実装者は、管理者が証明書ベースの認証に必要なすべての証明書を構成できるようにする構成を公開する必要があります。これらの証明書には、クライアント、サーバー、およびルート証明書が含まれます。
TLS-PSK methods are susceptible to dictionary attacks. Section 6, above, recommends deriving TLS-PSK keys from a Cryptographically Secure Pseudorandom Number Generator (CSPRNG), which makes dictionary attacks significantly more difficult. Servers SHOULD track failed client connections by TLS-PSK ID and block TLS-PSK IDs that seem to be attempting brute-force searches of the keyspace.
TLS-PSKメソッドは、辞書攻撃の影響を受けやすくなっています。上記のセクション6では、暗号で保護された疑似乱数ジェネレータ（CSPRNG）からTLS-PSKキーを派生させることを推奨しています。これにより、辞書攻撃が大幅に困難になります。サーバーは、失敗したクライアント接続をTLS-PSK IDで追跡し、キースペースのブルートフォース検索を試みているように見えるTLS-PSK IDをブロックする必要があります（SHOULD）。
The historic RADIUS practice of using shared secrets (here, PSKs) that are minor variations of words is NOT RECOMMENDED, as it would negate all of the security of DTLS.
DTLSのすべてのセキュリティが無効になるため、単語のマイナーバリエーションである共有シークレット（ここではPSK）を使用するというRADIUSの歴史的な慣行は推奨されません。
The use of DTLS allows DoS attacks and resource-exhaustion attacks that were not possible in RADIUS/UDP. These attacks are similar to those described in [RFC6614], Section 6, for TCP.
DTLSを使用すると、RADIUS / UDPでは不可能であったDoS攻撃とリソース枯渇攻撃が可能になります。これらの攻撃は、[RFC6614]のセクション6で説明されているTCPの攻撃に似ています。
Session tracking, as described in Section 5.1, can result in resource exhaustion. Therefore, servers MUST limit the absolute number of sessions that they track. When the total number of sessions tracked is going to exceed the configured limit, servers MAY free up resources by closing the session that has been idle for the longest time. Doing so may free up idle resources that then allow the server to accept a new session.
セクション5.1で説明されているように、セッショントラッキングはリソースを使い果たす可能性があります。したがって、サーバーは追跡するセッションの絶対数を制限する必要があります。追跡されたセッションの合計数が構成された制限を超えると、サーバーは最も長い間アイドル状態であったセッションを閉じることにより、リソースを解放できます（MAY）。これにより、アイドル状態のリソースが解放され、サーバーが新しいセッションを受け入れることができるようになります。
Servers MUST limit the number of partially open DTLS sessions. These limits SHOULD be exposed to the administrator as configurable settings.
サーバーは、部分的に開いているDTLSセッションの数を制限する必要があります。これらの制限は、構成可能な設定として管理者に公開する必要があります（SHOULD）。
We expect that the initial deployment of DTLS will follow the RADIUS/UDP model of statically configured client-server relationships. The specification for dynamic discovery of RADIUS servers is under development, so we will not address that here.
DTLSの初期展開は、静的に構成されたクライアント/サーバー関係のRADIUS / UDPモデルに従うと予想されます。 RADIUSサーバーの動的検出の仕様は開発中であるため、ここでは触れません。
Static configuration of client-server relationships for RADIUS/UDP means that a client has a fixed IP address for a server and a shared secret used to authenticate traffic sent to that address. The server in turn has a fixed IP address for a client and a shared secret used to authenticate traffic from that address. This model needs to be extended for RADIUS/DTLS.
RADIUS / UDPのクライアント/サーバー関係の静的構成は、クライアントがサーバーの固定IPアドレスと、そのアドレスに送信されるトラフィックの認証に使用される共有シークレットを持っていることを意味します。サーバーには、クライアントの固定IPアドレスと、そのアドレスからのトラフィックの認証に使用される共有シークレットがあります。このモデルは、RADIUS / DTLSに拡張する必要があります。
Instead of a shared secret, TLS credentials MUST be used by each party to authenticate the other. The issue of identity is more problematic. As with RADIUS/UDP, IP addresses may be used as a key to determine the authentication credentials that a client will present to a server or which credentials a server will accept from a client. This is the fixed IP address model of RADIUS/UDP, with the shared secret replaced by TLS credentials.
共有シークレットの代わりに、TLSクレデンシャルを使用して、他方を認証する必要があります。アイデンティティの問題はさらに問題です。 RADIUS / UDPと同様に、IPアドレスをキーとして使用して、クライアントがサーバーに提示する認証資格情報、またはサーバーがクライアントから受け入れる資格情報を決定できます。これはRADIUS / UDPの固定IPアドレスモデルであり、共有シークレットがTLSクレデンシャルに置き換えられています。
There are, however, additional considerations with RADIUS/DTLS. When a client is configured with a hostname for a server, the server may present to the client a certificate containing a hostname. The client MUST then verify that the hostnames match. Any mismatch is a security violation, and the connection MUST be closed.
ただし、RADIUS / DTLSには追加の考慮事項があります。クライアントがサーバーのホスト名で構成されている場合、サーバーはホスト名を含む証明書をクライアントに提示する場合があります。次に、クライアントはホスト名が一致することを確認する必要があります。不一致はセキュリティ違反であり、接続を閉じる必要があります。
A RADIUS/DTLS server MAY be configured with a "wildcard" IP address match for clients, instead of a unique fixed IP address for each client. In that case, clients MUST be individually configured with a unique certificate. When the server receives a connection from a client, it MUST determine client identity from the client certificate, and MUST authenticate (or not) the client based on that certificate. See [RFC6614], Section 2.4, for a discussion of how to match a certificate to a client identity.
RADIUS / DTLSサーバーは、各クライアントの一意の固定IPアドレスではなく、クライアントの「ワイルドカード」IPアドレスの一致で構成できます。その場合、クライアントは一意の証明書で個別に構成する必要があります。サーバーがクライアントから接続を受信すると、サーバーはクライアント証明書からクライアントIDを決定しなければならず、その証明書に基づいてクライアントを認証しなければなりません（MUST）。証明書をクライアントIDと照合する方法については、[RFC6614]、セクション2.4をご覧ください。
However, servers SHOULD use IP address filtering to minimize the possibility of attacks. That is, they SHOULD permit clients only from a limited IP address range or ranges. They SHOULD silently discard all traffic from outside of those ranges.
ただし、サーバーは攻撃の可能性を最小限に抑えるためにIPアドレスフィルタリングを使用する必要があります。つまり、制限付きのIPアドレス範囲からのクライアントのみを許可する必要があります（SHOULD）。それらはそれらの範囲の外からのすべてのトラフィックを静かに破棄する必要があります。
Since the client-server relationship is static, the authentication credentials for that relationship must also be statically configured. That is, a client connecting to a DTLS server SHOULD be pre-configured with the server's credentials (e.g., PSK or certificate). If the server fails to present the correct credentials, the DTLS session MUST be closed. Each server SHOULD be pre-configured with sufficient information to authenticate connecting clients.
クライアントとサーバーの関係は静的であるため、その関係の認証資格情報も静的に構成する必要があります。つまり、DTLSサーバーに接続するクライアントは、サーバーの資格情報（PSKや証明書など）で事前に構成する必要があります（SHOULD）。サーバーが正しい資格情報を提示できない場合は、DTLSセッションを閉じる必要があります。各サーバーは、接続しているクライアントを認証するのに十分な情報を事前に設定する必要があります（SHOULD）。
The requirement for clients to be individually configured with a unique certificate can be met by using a private CA for certificates used in RADIUS/DTLS environments. If a client were configured to use a public CA, then it could accept as valid any server that has a certificate signed by that CA. While the traffic would be secure from third-party observers, the server would, however, have unrestricted access to all of the RADIUS traffic, including all user credentials and passwords.
RADIUS / DTLS環境で使用される証明書にプライベートCAを使用することで、クライアントに一意の証明書を個別に構成するという要件を満たすことができます。クライアントがパブリックCAを使用するように構成されている場合、そのCAによって署名された証明書を持つ任意のサーバーを有効なクライアントとして受け入れることができます。トラフィックはサードパーティのオブザーバーから保護されますが、サーバーは、すべてのユーザー資格情報とパスワードを含むすべてのRADIUSトラフィックに無制限にアクセスできます。
Therefore, clients SHOULD NOT be pre-configured with a list of known public CAs by the vendor or manufacturer. Instead, the clients SHOULD start off with an empty CA list. The addition of a CA SHOULD be done only when manually configured by an administrator.
したがって、クライアントは、ベンダーまたは製造元による既知のパブリックCAのリストを事前に構成してはなりません。代わりに、クライアントは空のCAリストで開始する必要があります（SHOULD）。 CAの追加は、管理者が手動で構成した場合にのみ行う必要があります。
This scenario is the opposite of web browsers, where they are pre-configured with many known CAs. The goal there is security from third-party observers, but also the ability to communicate with any unknown site that presents a signed certificate. In contrast, the goal of RADIUS/DTLS is both security from third-party observers and the ability to communicate with only a small set of well-known servers.
このシナリオは、多くの既知のCAで事前に構成されているWebブラウザーの反対です。サードパーティのオブザーバーからのセキュリティだけでなく、署名された証明書を提示する不明なサイトと通信する機能も目標です。対照的に、RADIUS / DTLSの目標は、サードパーティのオブザーバーによるセキュリティと、少数の既知のサーバーとのみ通信する機能の両方です。
This requirement does not prevent clients from using hostnames instead of IP addresses for locating a particular server. Instead, it means that the credentials for that server should be pre-configured on the client, and associated with that hostname. This requirement does suggest that in the absence of a specification for dynamic discovery, clients SHOULD use only those servers that have been manually configured by an administrator.
この要件は、クライアントが特定のサーバーを見つけるためにIPアドレスの代わりにホスト名を使用することを妨げません。代わりに、そのサーバーの資格情報をクライアントで事前に構成し、そのホスト名に関連付ける必要があることを意味します。この要件は、動的検出の指定がない場合、クライアントは管理者が手動で構成したサーバーのみを使用する必要があることを示唆しています。
Network Address Translation (NAT) is fundamentally incompatible with RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the shared secret for the client, and NAT hides many clients behind one source IP address. As a result, RADIUS/UDP clients cannot be located behind a NAT gateway.
ネットワークアドレス変換（NAT）は、基本的にRADIUS / UDPと互換性がありません。 RADIUS / UDPはソースIPアドレスを使用してクライアントの共有シークレットを決定し、NATは1つのソースIPアドレスの背後に多くのクライアントを隠します。その結果、RADIUS / UDPクライアントをNATゲートウェイの背後に配置することはできません。
In addition, port reuse on a NAT gateway means that packets from different clients may appear to come from the same source port on the NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from one source IP/port combination, followed by the reception of a RADIUS/UDP packet from that same source IP/port combination. If this behavior is allowed, then the server would have an inconsistent view of the client's security profile, allowing an attacker to choose the most insecure method.
さらに、NATゲートウェイでのポートの再利用は、異なるクライアントからのパケットがNATの同じ送信元ポートから送信されたように見えることを意味します。つまり、RADIUSサーバーは、1つのソースIP /ポートの組み合わせからRADIUS / DTLSパケットを受信し、その後に同じソースIP /ポートの組み合わせからRADIUS / UDPパケットを受信する場合があります。この動作が許可されると、サーバーはクライアントのセキュリティプロファイルのビューに一貫性を持たなくなり、攻撃者が最も安全でない方法を選択できるようになります。
If more than one client is located behind a NAT gateway, then every client behind the NAT MUST use a secure transport such as TLS or DTLS. As discussed below, a method for uniquely identifying each client MUST be used.
複数のクライアントがNATゲートウェイの背後にある場合、NATの背後にあるすべてのクライアントは、TLSやDTLSなどの安全なトランスポートを使用する必要があります。以下で説明するように、各クライアントを一意に識別する方法を使用する必要があります。
Some RADIUS server implementations allow for "wildcard" clients -- that is, clients with an IPv4 netmask of other than 32 or an IPv6 netmask of other than 128. That practice is not recommended for RADIUS/UDP, as it means multiple clients will use the same shared secret.
一部のRADIUSサーバーの実装では、「ワイルドカード」クライアント（つまり、32以外のIPv4ネットマスクまたは128以外のIPv6ネットマスクを持つクライアント）が許可されています。RADIUS/ UDPでは、複数のクライアントが使用するため、この方法は推奨されません。同じ共有秘密。
The use of RADIUS/DTLS can allow for the safe usage of wildcards. When RADIUS/DTLS is used with wildcards, clients MUST be uniquely identified using TLS parameters, and any certificate or PSK used MUST be unique to each client.
RADIUS / DTLSを使用すると、ワイルドカードを安全に使用できます。 RADIUS / DTLSがワイルドカードと共に使用される場合、クライアントはTLSパラメータを使用して一意に識別される必要があり、使用される証明書またはPSKは各クライアントに対して一意である必要があります。
Section 5.1.1, above, requires that DTLS sessions be closed when the transported RADIUS packets are malformed or fail the authenticator checks. The reason is that the session is expected to be used for transport of RADIUS packets only.
上記のセクション5.1.1では、転送されたRADIUSパケットの形式が正しくない場合、またはオーセンティケーターチェックに失敗した場合、DTLSセッションを閉じる必要があります。その理由は、セッションがRADIUSパケットの転送にのみ使用されることが期待されているためです。
Any non-RADIUS traffic on that session means the other party is misbehaving and is a potential security risk. Similarly, any RADIUS traffic failing authentication vector or Message-Authenticator validation means that two parties do not have a common shared secret, and the session is therefore unauthenticated and insecure.
そのセッションでの非RADIUSトラフィックは、相手が誤動作しており、潜在的なセキュリティリスクであることを意味します。同様に、RADIUSトラフィックが認証ベクトルまたはMessage-Authenticator検証に失敗した場合、2つのパーティに共通の共有シークレットがないため、セッションは認証されておらず、安全ではありません。
We wish to avoid the situation where a third party can send well-formed RADIUS packets that cause a DTLS session to close. Therefore, in other situations, the session SHOULD remain open in the face of non-conformant packets.
第三者がDTLSセッションを閉じる原因となる整形式のRADIUSパケットを送信できる状況を避けたいと考えています。したがって、他の状況では、セッションは適合しないパケットに直面しても開いたままにする必要があります（SHOULD）。
Many traditional clients treat RADIUS as subsystem-specific. That is, each subsystem on the client has its own RADIUS implementation and configuration. These independent implementations work for simple systems, but break down for RADIUS when multiple servers, fail-over, and load-balancing are required. They have even worse issues when DTLS is enabled.
多くの従来のクライアントは、RADIUSをサブシステム固有のものとして扱います。つまり、クライアント上の各サブシステムには、独自のRADIUS実装と構成があります。これらの独立した実装は単純なシステムで機能しますが、複数のサーバー、フェイルオーバー、および負荷分散が必要な場合は、RADIUSで機能しなくなります。 DTLSを有効にすると、さらに悪い問題が発生します。
As noted in Section 6.1, above, clients SHOULD use a local proxy that arbitrates all RADIUS traffic between the client and all servers. This proxy will encapsulate all knowledge about servers, including security policies, fail-over, and load-balancing. All client subsystems SHOULD communicate with this local proxy, ideally over a loopback address. The requirements on using strong shared secrets still apply.
上記のセクション6.1で述べたように、クライアントは、クライアントとすべてのサーバー間のすべてのRADIUSトラフィックを調停するローカルプロキシを使用する必要があります（SHOULD）。このプロキシは、セキュリティポリシー、フェイルオーバー、ロードバランシングなど、サーバーに関するすべての知識をカプセル化します。すべてのクライアントサブシステムは、理想的にはループバックアドレスを介してこのローカルプロキシと通信する必要があります。強力な共有シークレットの使用に関する要件は引き続き適用されます。
The benefit of this configuration is that there is one place in the client that arbitrates all RADIUS traffic. Subsystems that do not implement DTLS can remain unaware of DTLS. DTLS sessions opened by the proxy can remain open for long periods of time, even when client subsystems are restarted. The proxy can do RADIUS/UDP to some servers and RADIUS/DTLS to others.
この構成の利点は、すべてのRADIUSトラフィックを調停する1つの場所がクライアントにあることです。 DTLSを実装しないサブシステムは、DTLSを認識しないままになる可能性があります。プロキシによって開かれたDTLSセッションは、クライアントサブシステムが再起動された場合でも、長時間開いたままになる可能性があります。プロキシは、一部のサーバーに対してRADIUS / UDPを実行し、他のサーバーに対してRADIUS / DTLSを実行できます。
Delegation of responsibilities and separation of tasks are important security principles. By moving all RADIUS/DTLS knowledge to a DTLS-aware proxy, security analysis becomes simpler, and enforcement of correct security becomes easier.
責任の委任とタスクの分離は、重要なセキュリティ原則です。すべてのRADIUS / DTLS知識をDTLS対応プロキシに移動することで、セキュリティ分析が単純になり、正しいセキュリティの実施が容易になります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3539] Aboba、B。およびJ. Wood、「Authentication、Authorization and Accounting（AAA）Transport Profile」、RFC 3539、2003年6月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without Server-Side State」、RFC 5077、2008年1月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080] Nelson、D。およびA. DeKok、「Common Remote Authentication Dial In User Service（RADIUS）Implementation Issues and Suggested Fixes」、RFC 5080、2007年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, August 2010.
[RFC5997] DeKok、A。、「リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルでのステータスサーバーパケットの使用」、RFC 5997、2010年8月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012.
[RFC6520] Seggelmann、R.、Tuexen、M。、およびM. Williams、「Transport Layer Security（TLS）and Datagram Transport Layer Security（DTLS）Heartbeat Extension」、RFC 6520、2012年2月。
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
[RFC6613] DeKok、A。、「RADIUS over TCP」、RFC 6613、2012年5月。
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012.
[RFC6614] Winter、S.、McCauley、M.、Venaas、S.、and K. Wierenga、 "Transport Layer Security（TLS）Encryption for RADIUS"、RFC 6614、May 2012。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]リグニー、C。、「RADIUSアカウンティング」、RFC 2866、2000年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin、S。およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、2005年6月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 5176、January 2008。
[RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, November 2011.
[RFC6421] Nelson、D。、編、「リモート認証ダイヤルインユーザーサービス（RADIUS）の暗号化アジリティ要件」、RFC 6421、2011年11月。
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, July 2013.
[RFC6982] Sheffer、Y。およびA. Farrel、「コードの実行に対する意識の向上：実装ステータスセクション」、RFC 6982、2013年7月。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack] Dobbertin、H。、「最近の攻撃後のMD5のステータス」、CryptoBytes Vol.2 No.2、1996年夏。
[MD5Break] Wang, X. and H. Yu, "How to Break MD5 and Other Hash Functions", EUROCRYPT '05 Proceedings of the 24th annual international conference on Theory and Applications of Cryptographic Techniques, pp. 19-35, ISBN 3-540-25910-4, 2005.
[MD5Break] Wang、X。およびH. Yu、「MD5およびその他のハッシュ関数を壊す方法」、EUROCRYPT '05暗号技術の理論と応用に関する第24回年次国際会議の議事録、pp。19-35、ISBN 3- 540-25910-4、2005。
Acknowledgments
謝辞
Parts of the text in Section 3 defining the Request and Response Authenticators were taken with minor edits from [RFC2865], Section 3.
リクエストおよびレスポンス認証システムを定義するセクション3のテキストの一部は、[RFC2865]、セクション3からのわずかな編集で取得されました。
Author's Address
著者のアドレス
Alan DeKok
The FreeRADIUS Server Project
URI: http://freeradius.org
EMail: aland@freeradius.org