Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 9765 FreeRADIUS
Updates: 2865, 2866, 5176, 6613, 6614, 7360 April 2025
Category: Experimental
ISSN: 2070-1721
This document defines Application-Layer Protocol Negotiation (ALPN) extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an application protocol variant of RADIUS called "RADIUS/1.1". No changes are made to RADIUS/UDP or RADIUS/ TCP. The extensions allow the negotiation of a transport profile where the RADIUS shared secret is no longer used, and all MD5-based packet authentication and attribute obfuscation methods are removed.
このドキュメントでは、半径/TLSおよび半径/DTLSで使用するためのアプリケーション層プロトコル交渉（ALPN）拡張機能を定義します。これらの拡張により、「RADIUS/1.1」と呼ばれる半径のアプリケーションプロトコルバリアントの交渉が可能です。半径/ UDPまたは半径/ TCPに変更は行われません。拡張機能により、RADIUS共有秘密が使用されなくなり、すべてのMD5ベースのパケット認証と属性の難読化方法が削除されなくなった輸送プロファイルの交渉が可能になります。
This document updates RFCs 2865, 2866, 5176, 6613, 6614, and 7360.
このドキュメントは、RFCS 2865、2866、5176、6613、6614、および7360を更新します。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9765.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9765で取得できます。
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. The RADIUS/1.1 Transport Profile for RADIUS
3.1. ALPN Name for RADIUS/1.1
3.2. Operation of ALPN
3.3. Configuration of ALPN for RADIUS/1.1
3.3.1. Using Protocol-Error for Signaling ALPN Failure
3.3.2. Tabular Summary
3.4. Miscellaneous Items
3.5. Session Resumption
4. RADIUS/1.1 Packet and Attribute Formats
4.1. RADIUS/1.1 Packet Format
4.2. The Token Field
4.2.1. Sending Packets
4.2.2. Receiving Packets
5. Attribute Handling
5.1. Obfuscated Attributes
5.1.1. User-Password
5.1.2. CHAP-Challenge
5.1.3. Tunnel-Password
5.1.4. Vendor-Specific Attributes
5.2. Message-Authenticator
5.3. Message-Authentication-Code
5.4. CHAP, MS-CHAP, and Similar Attributes
5.5. Original-Packet-Code
6. Other Considerations When Using ALPN
6.1. Protocol-Error
6.2. Status-Server
6.3. Proxies
7. Other RADIUS Considerations
7.1. Crypto-Agility
7.2. Error-Cause Attribute
7.3. Future Standards
8. Privacy Considerations
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Author's Address
The RADIUS protocol [RFC2865] uses MD5 [RFC1321] to authenticate packets and to obfuscate certain attributes. Additional transport protocols were defined for TCP [RFC6613], TLS [RFC6614], and DTLS [RFC7360]. However, those transport protocols still use MD5 to authenticate individual packets. That is, the shared secret was used along with MD5, even when the RADIUS packets were being transported in (D)TLS. At the time, the consensus of the RADEXT Working Group was that this continued use of MD5 was acceptable. TLS was seen as a simple "wrapper" around RADIUS, while using a fixed shared secret. The intention at the time was to allow the use of (D)TLS while making essentially no changes to the basic RADIUS encoding, decoding, authentication, and packet validation.
RADIUSプロトコル[RFC2865]は、MD5 [RFC1321]を使用してパケットを認証し、特定の属性を難読化します。TCP [RFC6613]、TLS [RFC6614]、およびDTLS [RFC7360]について、追加の輸送プロトコルが定義されました。ただし、これらの輸送プロトコルは、MD5を使用して個々のパケットを認証しています。つまり、RADIUSパケットが（d）TLSで輸送されていた場合でも、共有秘密はMD5とともに使用されました。当時、Radextワーキンググループのコンセンサスは、MD5のこの継続的な使用が許容できることでした。TLSは、固定された共有秘密を使用しながら、半径の周りの単純な「ラッパー」と見なされていました。当時の意図は、基本的な半径エンコード、デコード、認証、およびパケット検証を本質的に変更しない一方で、（d）TLSを使用することを許可することでした。
Issues of MD5 security have been known for decades, most notably in [RFC6151] and in Section 3 of [RFC6421], among others. The reliance on MD5 for security makes it impossible to use RADIUS in secure systems that forbid the use of digest algorithms with known vulnerabilities. For example, FIPS 140 forbids systems from relying on insecure cryptographic methods for security [FIPS-140-3].
MD5セキュリティの問題は何十年もの間、特に[RFC6151]および[RFC6421]のセクション3で、特に[RFC6151]およびセクション3で知られています。セキュリティのためにMD5に依存することにより、既知の脆弱性を備えたダイジェストアルゴリズムの使用を禁止する安全なシステムで半径を使用することは不可能です。たとえば、FIPS 140は、セキュリティのための安全な暗号化方法に依存することを禁止しています[FIPS-140-3]。
While the use of MD5 in RADIUS/TLS has not been proven to be insecure, it has not been proven to be secure. This gap means that it is difficult to use RADIUS in organizations that require the use of systems that have proven security. Those organizations tend to simply ban the use of insecure digests such as MD5 entirely, even if the use of MD5 has no known security impact. While the resulting system might still not be secure, it at least does not contain any known insecurities.
半径/TLSでのMD5の使用は不安定であることが証明されていませんが、安全であることが証明されていません。このギャップは、セキュリティが証明されているシステムの使用を必要とする組織で半径を使用することが困難であることを意味します。これらの組織は、MD5の使用にセキュリティへの影響が既知でなくても、MD5などの不安定な消化物の使用を完全に禁止する傾向があります。結果のシステムはまだ安全ではないかもしれませんが、少なくとも既知の不安は含まれていません。
In addition, the use of MD5 in RADIUS/TLS and RADIUS/DLTS adds no security or privacy over that provided by TLS. In hindsight, the decision of the RADEXT Working Group to retain MD5 for historic RADIUS/TLS was likely wrong. It was an easy decision to make in the short term, but it has caused ongoing problems that this document addresses. The author of this document played a part in that original decision, which is now being corrected by this document.
さらに、半径/TLSおよび半径/DLTでMD5を使用しても、TLSが提供するセキュリティやプライバシーを追加しません。後知恵では、歴史的な半径/TLSのMD5を保持するというRadextワーキンググループの決定は間違っている可能性が高い。短期的には簡単に決定することでしたが、この文書が対処する継続的な問題を引き起こしました。このドキュメントの著者は、このドキュメントによって修正されている当初の決定に関与しています。
This document defines an Application-Layer Protocol Negotiation (ALPN) [RFC7301] extension for RADIUS over (D)TLS that removes the need to use MD5 for (D)TLS, which we call RADIUS/1.1. This specification makes no changes to UDP or TCP transport. The RADIUS/1.1 protocol can be best understood as a transport profile for RADIUS over TLS, rather than a wholesale revision of the RADIUS protocol.
このドキュメントは、（d）TLSにMD5を使用する必要性を削除する（d）TLSの半径のアプリケーション層プロトコル交渉（ALPN）[RFC7301]拡張を定義します。この仕様は、UDPまたはTCPトランスポートに変更を加えません。RADIUS/1.1プロトコルは、半径プロトコルの卸売改訂ではなく、TLS上の半径の輸送プロファイルとして最もよく理解できます。
Systems that implement this transport profile can be more easily verified to be FIPS 140 compliant. A preliminary implementation has shown that only minor code changes are required to support RADIUS/1.1 on top of an existing RADIUS/TLS server implementation. These include:
この輸送プロファイルを実装するシステムは、FIPS 140に準拠するようにより簡単に検証できます。予備的な実装により、既存のRADIUS/TLSサーバーの実装に加えて、半径/1.1をサポートするためにマイナーコードの変更のみが必要であることが示されています。これらには以下が含まれます：
* A method to set the list of supported ALPN protocols before the TLS handshake starts.
* TLSハンドシェイクが開始される前に、サポートされているALPNプロトコルのリストを設定する方法。
* A method to query if ALPN has chosen a protocol (and if yes, which protocol was chosen) after the TLS handshake has completed.
* TLSハンドシェイクが完了した後、ALPNがプロトコルを選択した場合（およびはい、どのプロトコルが選択されたか）かどうかを照会する方法。
* Changes to the packet encoder and decoder, so that the individual packets are not authenticated, and no attribute is encoded with the historic obfuscation methods.
* 個々のパケットが認証されておらず、歴史的な難読化方法でエンコードされる属性はないように、パケットエンコーダーとデコーダーの変更。
That is, the bulk of the ALPN protocol can be left to the underlying TLS implementation. This document discusses the ALPN exchange in detail in order to give simplified descriptions for the reader, and so that the reader does not have to read or understand all of [RFC7301].
つまり、ALPNプロトコルの大部分は、基礎となるTLS実装に任せることができます。このドキュメントでは、読者に簡略化された説明を提供するために、ALPN交換について詳細に説明し、読者が[RFC7301]のすべてを読み取ったり理解したりする必要がないようにします。
The detailed list of changes from historic TLS-based transports to RADIUS/1.1 is as follows:
歴史的なTLSベースのトランスポートから半径/1.1への変更の詳細なリストは次のとおりです。
* ALPN is used for negotiation of this extension.
* ALPNは、この拡張機能の交渉に使用されます。
* TLS 1.3 or later is required.
* TLS 1.3以降が必要です。
* All uses of the RADIUS shared secret have been removed.
* Radius共有秘密のすべての使用が削除されました。
* The now unused Request and Response Authenticator fields have been repurposed to carry an opaque Token that identifies requests and responses.
* 現在使用されていないリクエストと応答の認証装置フィールドは、リクエストと応答を識別する不透明なトークンを運ぶために再利用されています。
* The functionality of the Identifier field has been replaced by the Token field, and the space previously taken by the Identifier field is now reserved and unused.
* 識別子フィールドの機能はトークンフィールドに置き換えられており、識別子フィールドが以前に取得したスペースは現在予約されていないようになりました。
* The Message-Authenticator attribute ([RFC3579], Section 3.2) is not sent in any packet, and is ignored if received.
* Message-authenticator属性（[RFC3579]、セクション3.2）は、パケットに送信されず、受け取った場合は無視されます。
* Attributes such as User-Password, Tunnel-Password, and MS-MPPE keys are sent encoded as "text" ([RFC8044], Section 3.4) or "octets" ([RFC8044], Section 3.5), without the previous MD5-based obfuscation. This obfuscation is no longer necessary, as the data is secured and kept private through the use of TLS.
* ユーザーパスワード、トンネルパスワード、MS-MPPEキーなどの属性は、以前のMD5ベースの肥満なしに、「テキスト」（[RFC8044]、セクション3.4）または「[RFC8044]、セクション3.5）としてエンコードされます。データは確保され、TLSを使用してプライベートに保たれるため、この難読化はもはや必要ありません。
* The conclusion of the efforts stemming from [RFC6421] is that crypto-agility in RADIUS is best done via a TLS wrapper, and not by extending the RADIUS protocol.
* [RFC6421]に由来する努力の結論は、半径の暗号能力は、RADIUSプロトコルを拡張することではなく、TLSラッパーを介して行うのが最適であるということです。
* [RFC5176] is updated to allow the Error-Cause attribute to appear in Access-Reject packets.
* [RFC5176]は、Access-rejectパケットにエラー原因属性が表示されるように更新されます。
The following items are left unchanged from historic TLS-based transports for RADIUS:
次の項目は、半径の歴史的なTLSベースのトランスポートから変更されていません。
* The RADIUS packet header is the same size, and the Code and Length fields ([RFC2865], Section 3) have the same meaning as before.
* RADIUSパケットヘッダーは同じサイズで、コードと長さのフィールド（[RFC2865]、セクション3）は以前と同じ意味を持っています。
* The default 4096-octet packet size from [RFC2865], Section 3 is unchanged, although [RFC7930] can still be leveraged to use larger packets.
* [RFC2865]からのデフォルトの4096-OCTETパケットサイズは、セクション3は変更されていませんが、[RFC7930]を活用して、より大きなパケットを使用することができます。
* All attributes that have simple encodings (that is, attributes that do not use MD5 obfuscation) have the same encoding and meaning as before.
* 単純なエンコーディング（つまり、MD5難読化を使用しない属性）を持つすべての属性には、以前と同じエンコードと意味があります。
* As this extension is a transport profile for one "hop" (client-to-server connection), it does not impact any other connection used by a client or server. The only systems that are aware that this transport profile is in use are the client and server who have negotiated the use of this extension on a particular shared connection.
* この拡張機能は、1つの「ホップ」（クライアント間接続）のトランスポートプロファイルであるため、クライアントまたはサーバーが使用する他の接続には影響しません。このトランスポートプロファイルが使用されていることを認識している唯一のシステムは、特定の共有接続でこの拡張機能の使用を交渉したクライアントとサーバーです。
* This extension uses the same ports (2083/tcp and 2083/udp) that are defined for RADIUS/TLS [RFC6614] and RADIUS/DTLS [RFC7360].
* この拡張は、半径/TLS [RFC6614]および半径/DTLS [RFC7360]に対して定義される同じポート（2083/TCPおよび2083/UDP）を使用します。
A major benefit of this extension is that a server that implements it can also be more easily verified for FIPS 140 compliance. That is, a server can remove all uses of MD5, which means that those algorithms are provably not used for security purposes. In that case, however, the server will not support the Challenge Handshake Authentication Protocol (CHAP) or any authentication method that uses MD5. The choice of which authentication method to accept is always left to the server. This specification does not change any authentication method carried in RADIUS, and does not mandate (or forbid) the use of any authentication method for any system.
この拡張機能の主な利点は、それを実装するサーバーがFIPS 140コンプライアンスについてより簡単に検証できることです。つまり、サーバーはMD5のすべての用途を削除できます。つまり、これらのアルゴリズムはセキュリティ目的で使用されていないことを証明します。ただし、その場合、サーバーはチャレンジハンドシェイク認証プロトコル（CHAP）またはMD5を使用する認証方法をサポートしません。受け入れる認証方法の選択は、常にサーバーに任されています。この仕様は、半径で運ばれる認証方法を変更せず、システムに認証方法を使用することを義務付け（または禁止）しません。
As for proxies, there was never a requirement that proxies implement CHAP or Microsoft CHAP (MS-CHAP) authentication. So far as a proxy is concerned, attributes relating to CHAP and MS-CHAP are simply opaque data that is transported unchanged to the next hop. Therefore, it is possible for a FIPS 140 compliant proxy to transport authentication methods that depend on MD5, so long as that data is forwarded to a server that supports those methods.
プロキシに関しては、プロキシがChapまたはMicrosoft Chap（MS-Chap）認証を実装する要件はありませんでした。プロキシに関する限り、ChapとMS-Chapに関連する属性は、次のホップに変更されていない不透明なデータです。したがって、そのデータがこれらの方法をサポートするサーバーに転送される限り、FIPS 140準拠のプロキシはMD5に依存する認証方法を輸送する可能性があります。
We reiterate that the decision to support (or not support) any authentication method is entirely site local, and is not a requirement of this specification. The contents or meaning of any RADIUS attribute other than the Message-Authenticator (and similar attributes) are not modified. The only change to the Message-Authenticator attribute is that it is no longer used in RADIUS/1.1.
認証方法をサポートする（またはサポートしない）決定は、完全にサイトローカルであり、この仕様の要件ではないことを繰り返します。Message-authenticator（および同様の属性）以外の半径属性の内容または意味は変更されていません。メッセージauthenticator属性の唯一の変更は、半径/1.1ではもはや使用されないことです。
Unless otherwise described in this document, all RADIUS requirements apply to this extension. That is, this specification defines a transport profile for RADIUS. It is not an entirely new protocol, and it defines only minor changes to the existing RADIUS protocol. It does not change the RADIUS packet format, attribute format, etc. This specification is compatible with all RADIUS attributes of the past, present, and future.
このドキュメントで特に説明されていない限り、すべての半径要件はこの拡張機能に適用されます。つまり、この仕様は半径の輸送プロファイルを定義します。これはまったく新しいプロトコルではなく、既存のRADIUSプロトコルのわずかな変更のみを定義します。RADIUSパケット形式、属性形式などを変更しません。この仕様は、過去、現在、および将来のすべての半径属性と互換性があります。
This specification is compatible with existing implementations of RADIUS/TLS and RADIUS/DTLS. Systems that implement this specification can fall back to historic RADIUS/TLS if no ALPN signaling is performed, and the local configuration permits such fallback.
この仕様は、radius/tlsおよびradius/dtlsの既存の実装と互換性があります。この仕様を実装するシステムは、ALPNシグナル伝達が実行されない場合、歴史的な半径/TLSに戻ることができ、ローカル構成によりそのようなフォールバックが許可されます。
This specification is compatible with all existing RADIUS specifications. There is no need for any RADIUS specification to mention this transport profile by name or to make provisions for this specification. This document defines how to transform RADIUS into RADIUS/1.1, and no further discussion of that transformation is necessary.
この仕様は、既存のすべての半径仕様と互換性があります。この輸送プロファイルに名前で言及したり、この仕様の規定を作成するための半径の仕様は必要ありません。このドキュメントでは、半径を半径/1.1に変換する方法を定義しており、その変換のこれ以上の議論は必要ありません。
We note that this document makes no changes to previous RADIUS specifications. Existing RADIUS implementations can continue to be used without modification. Where previous specifications are explicitly mentioned and updated, those updates or changes apply only when the RADIUS/1.1 transport profile is being used.
このドキュメントは、以前の半径仕様に変更を加えないことに注意してください。既存のRADIUS実装は、変更なしで引き続き使用できます。以前の仕様が明示的に言及され、更新されている場合、これらの更新または変更は、RADIUS/1.1トランスポートプロファイルが使用されている場合にのみ適用されます。
In short, when negotiated on a connection, the RADIUS/1.1 transport profile permits implementations to avoid MD5 when authenticating packets or when obfuscating certain attributes.
要するに、接続で交渉した場合、RADIUS/1.1輸送プロファイルは、パケットを認証するとき、または特定の属性を難読化するときにMD5を回避できるように実装を許可します。
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] で説明されているように解釈されます。
The following list describes the terminology and abbreviations that are used in this document.
次のリストでは、このドキュメントで使用されている用語と略語について説明します。
ALPN
alpn
Application-Layer Protocol Negotiation (as defined in [RFC7301]).
アプリケーション層プロトコル交渉（[RFC7301]で定義されている）。
RADIUS
半径
Remote Authentication Dial-In User Service (as defined in [RFC2865], [RFC2866], and [RFC5176], among others).
リモート認証ダイヤルインユーザーサービス（[RFC2865]、[RFC2866]、および[RFC5176]などで定義されています）。
While this protocol can be viewed as "RADIUS/1.0", for simplicity and historical compatibility, we keep the name "RADIUS".
このプロトコルは「Radius/1.0」と見なすことができますが、簡単にして歴史的な互換性を得るために、「Radius」という名前を保持します。
RADIUS/UDP
RADIUS/UDP
RADIUS over the User Datagram Protocol (see [RFC2865], [RFC2866], and [RFC5176], among others).
ユーザーデータグラムプロトコルの半径（[RFC2865]、[RFC2866]、および[RFC5176]などを参照）。
RADIUS/TCP
RADIUS/TCP
RADIUS over the Transmission Control Protocol [RFC6613].
透過制御プロトコルの半径[RFC6613]。
RADIUS/TLS
RADIUS/TLS
RADIUS over Transport Layer Security [RFC6614].
輸送層のセキュリティ上の半径[RFC6614]。
RADIUS/DTLS
RADIUS/DTLS
RADIUS over Datagram Transport Layer Security [RFC7360].
データグラム輸送層のセキュリティ上の半径[RFC7360]。
RADIUS over TLS
TLSの半径
Refers to any RADIUS packets transported over TLS or DTLS. This terminology is used instead of alternatives such as "RADIUS/(D)TLS" or "either RADIUS/TLS or RADIUS/DTLS". This term is generally used when referring to TLS-layer requirements for RADIUS packet transport.
TLSまたはDTLSを介して輸送される半径パケットを指します。この用語は、「半径/（d）TLS」または「半径/TLSまたは半径/DTLS」などの代替品の代わりに使用されます。この用語は、通常、半径パケット輸送のTLS層要件を参照する場合に使用されます。
historic RADIUS/TLS
歴史的な半径/TLS
Refers to RADIUS over (D)TLS (as defined in [RFC6614] and [RFC7360]). This term does not include the protocol defined in this specification.
（d）TLS（[RFC6614]および[RFC7360]で定義されているradius）を指します。この用語には、この仕様で定義されているプロトコルは含まれていません。
RADIUS/1.1
半径/1.1
RADIUS version 1.1, i.e., the transport profile defined in this document. We use RADIUS/1.1 to refer interchangeably to TLS and DTLS transport.
RADIUSバージョン1.1、つまり、このドキュメントで定義されている輸送プロファイル。半径/1.1を使用して、TLSとDTLSトランスポートを交換可能に参照します。
TLS
TLS
Transport Layer Security. Generally, when we refer to TLS in this document, we are referring interchangeably to TLS or DTLS transport.
輸送層のセキュリティ。一般に、このドキュメントでTLSを参照する場合、TLSまたはDTLSトランスポートを互換性があります。
This section describes the ALPN transport profile in detail. It first gives the name used for ALPN, and then describes how ALPN is configured and negotiated by the client and server. It then concludes by discussing TLS issues such as what to do for ALPN during session resumption.
このセクションでは、ALPN輸送プロファイルについて詳しく説明します。最初にALPNに使用される名前を示し、次にALPNがクライアントとサーバーによってどのように構成およびネゴシエーションされるかを説明します。次に、セッション再開中にALPNについて何をすべきかなどのTLSの問題について議論することで終わります。
The ALPN name defined for RADIUS/1.1 is as follows:
半径/1.1で定義されたALPN名は次のとおりです。
"radius/1.1"
「Radius/1.1」
The protocol defined by this specification.
この仕様で定義されたプロトコル。
Where ALPN is not configured or is not received in a TLS connection, systems supporting ALPN MUST NOT use RADIUS/1.1.
ALPNが構成されていないか、TLS接続で受信されない場合、ALPNをサポートするシステムは半径/1.1を使用してはなりません。
Where ALPN is configured, the client signals support by sending ALPN strings listing which protocols it supports. The server can accept one of these proposals and reply with a matching ALPN string, or reject this proposal and not reply with any ALPN string. A full walkthrough of the protocol negotiation is given below.
ALPNが構成されている場合、クライアントは、サポートするプロトコルをリストするALPN文字列を送信することによりサポートを信号します。サーバーは、これらの提案のいずれかを受け入れ、一致するALPN文字列で返信するか、この提案を拒否し、ALPN文字列で返信することはできません。プロトコル交渉の完全なウォークスルーを以下に示します。
Implementations MUST signal ALPN "radius/1.1" in order for it to be used in a connection.
実装は、接続で使用するためにALPN「半径/1.1」を通知する必要があります。
The next step in defining RADIUS/1.1 is to review how ALPN works.
半径/1.1を定義する次のステップは、ALPNの仕組みを確認することです。
In order to provide a high-level description of ALPN for readers who are not familiar with the details of [RFC7301], we provide a brief overview here.
[RFC7301]の詳細に精通していない読者にALPNの高レベルの説明を提供するために、ここで簡単な概要を説明します。
Once a system has been configured to support ALPN, it is negotiated on a per-connection basis as per [RFC7301]. The negotiation proceeds as follows:
システムがALPNをサポートするように構成されたら、[RFC7301]に従って、接続ごとに交渉されます。交渉は次のように進行します。
1) The client sends an ALPN extension in the ClientHello. This extension lists one or more application protocols by name. These names are the protocols that the client is claiming to support.
1) クライアントは、clienthelloでALPN拡張機能を送信します。この拡張機能には、1つ以上のアプリケーションプロトコルが名前でリストされています。これらの名前は、クライアントがサポートすると主張しているプロトコルです。
2) The server receives the extension and validates the application protocol name(s) against the list it has configured.
2) サーバーは拡張機能を受信し、設定したリストに対してアプリケーションプロトコル名を検証します。
If the server finds no acceptable common protocols (ALPN or otherwise), it closes the connection.
サーバーが許容可能な共通プロトコル（ALPNまたはその他）を見つけられない場合、接続を閉じます。
3) Otherwise, the server returns a ServerHello with either no ALPN extension or an ALPN extension containing only one named application protocol, which needs to be one of the names proposed by the client.
3) それ以外の場合、サーバーは、ALPN拡張機能なしまたは1つの指定されたアプリケーションプロトコルのみを含むALPN拡張機能のいずれかでServerHelloを返します。これは、クライアントが提案する名前の1つである必要があります。
If the client did not signal ALPN, or the server does not accept the ALPN proposal, the server does not reply with any ALPN name.
クライアントがALPNに信号を送らなかった場合、またはサーバーがALPNの提案を受け入れない場合、サーバーはALPN名で返信しません。
4) The client receives the ServerHello, validates the received application protocol (if any) against the name(s) it sent, and records which application protocol was chosen.
4) クライアントはServerHelloを受信し、送信した名前に対して受信したアプリケーションプロトコル（もしあれば）を検証し、どのアプリケーションプロトコルが選択されたかを記録します。
This check is necessary in order for the client to both know which protocol the server has selected, and to validate that the protocol sent by the server is one that is acceptable to the client.
このチェックは、クライアントがサーバーが選択したプロトコルを把握し、サーバーから送信されたプロトコルがクライアントに受け入れられるものであることを検証するために必要です。
The next step in defining RADIUS/1.1 is to define how ALPN is configured on the client and server and to give more detailed requirements on its configuration and operation.
RADIUS/1.1を定義する次のステップは、ALPNがクライアントとサーバーで構成されている方法を定義し、その構成と操作に関するより詳細な要件を提供することです。
Clients or servers supporting this specification can do so by extending their TLS configuration through the addition of a new configuration variable, called "Version" here. The exact name given below does not need to be used, but it is RECOMMENDED that administrative interfaces or programming interfaces use a similar name in order to provide consistent terminology. This variable controls how the implementation signals use of this protocol via ALPN.
この仕様をサポートするクライアントまたはサーバーは、ここで「バージョン」と呼ばれる新しい構成変数を追加してTLS構成を拡張することにより、そうすることができます。以下に示す正確な名前を使用する必要はありませんが、一貫した用語を提供するために、管理インターフェイスまたはプログラミングインターフェイスを使用するために同様の名前を使用することをお勧めします。この変数は、実装がALPNを介したこのプロトコルの使用を信号する方法を制御します。
When set, this variable should contain the list of permitted RADIUS versions as numbers, e.g., "1.0" or "1.1". The implementation may allow multiple values in one variable, allow multiple variables, or instead use two configurations for the "minimum" and "maximum" allowed versions. We assume here that there is one variable, which can contain either no value or a list of one or more versions that the current implementation supports. In this specification, the possible values, ALPN strings, and corresponding interpretations are:
設定すると、この変数には、許可された半径バージョンのリスト、たとえば「1.0」または「1.1」としてのリストを含める必要があります。実装は、1つの変数で複数の値を許可したり、複数の変数を許可したり、代わりに「最小」および「最大」許可バージョンに2つの構成を使用したりする場合があります。ここでは、現在の実装がサポートする1つまたは複数のバージョンの値またはリストのいずれかを含めることができる変数が1つあると想定しています。この仕様では、可能な値、ALPN文字列、および対応する解釈は次のとおりです。
+==========+========================+=============================+
| Value | ALPN String(s) | Interpretation |
+==========+========================+=============================+
| unset | | no ALPN strings are sent |
+----------+------------------------+-----------------------------+
| 1.0 | radius/1.0 | require historic RADIUS/TLS |
+----------+------------------------+-----------------------------+
| 1.0, 1.1 | radius/1.0, radius/1.1 | allow either historic |
| | | RADIUS/TLS or RADIUS/1.1 |
+----------+------------------------+-----------------------------+
| 1.1 | radius/1.1 | require RADIUS/1.1 |
+----------+------------------------+-----------------------------+
Table 1
This configuration is also extensible to future RADIUS versions if that extension becomes necessary. New values and ALPN names can simply be added to the list. Implementations can then negotiate the highest version that is supported by both client and server.
この構成は、その拡張機能が必要になった場合、将来のRADIUSバージョンにも拡張可能です。新しい値とALPN名をリストに追加できます。実装は、クライアントとサーバーの両方でサポートされている最高バージョンを交渉できます。
Implementations SHOULD support both historic RADIUS/TLS and RADIUS/1.1. Such implementations MUST set the default value for this configuration variable to "1.0, 1.1". This setting ensures that both versions of RADIUS can be negotiated.
実装は、歴史的な半径/TLと半径/1.1の両方をサポートする必要があります。このような実装は、この構成変数のデフォルト値を「1.0、1.1」に設定する必要があります。この設定により、両方のバージョンのRADIUSが交渉できるようになります。
Implementations MAY support only RADIUS/1.1. In this case, the default value for this configuration variable MUST be "1.1". This behavior is NOT RECOMMENDED, as it is incompatible with historic RADIUS/TLS. This behavior can only be a reasonable default when all (or nearly all) RADIUS clients have been updated to support RADIUS/1.1.
実装は、半径/1.1のみをサポートする場合があります。この場合、この構成変数のデフォルト値は「1.1」でなければなりません。この動作は、歴史的な半径/TLと互換性がないため、推奨されません。この動作は、半径のすべて（またはほぼすべての）クライアントがRADIUS/1.1をサポートするために更新された場合にのみ、合理的なデフォルトになります。
A more detailed definition of the variable and the meaning of the values is given below.
変数のより詳細な定義と値の意味を以下に示します。
Configuration Variable Name
構成変数名
Version
バージョン
For "Value":
「値」のために：
A. If unset, ALPN is not used.
A.解明されていない場合、ALPNは使用されません。
Any connection MUST use historic RADIUS/TLS.
任意の接続は、歴史的な半径/TLSを使用する必要があります。
This variable is included here only for logical completeness. Implementations of this specification SHOULD be configured to always send one or more ALPN strings. This data signals that the implementation is capable of performing ALPN negotiation, even if it is not currently configured to use RADIUS/1.1.
この変数は、論理的な完全性のためにのみここに含まれています。この仕様の実装は、常に1つ以上のALPN文字列を送信するように構成する必要があります。このデータは、実装がALPNネゴシエーションを実行できることを示しています。
Client Behavior
クライアントの動作
The client MUST NOT send any protocol name via ALPN.
クライアントは、ALPNを介してプロトコル名を送信してはなりません。
Server Behavior
サーバーの動作
The server MUST NOT signal any protocol name via ALPN.
サーバーは、ALPNを介してプロトコル名を信号してはなりません。
If the server receives an ALPN name from the client, it MUST NOT close the connection. Instead, it simply does not reply with ALPN and finishes the TLS connection setup as defined for historic RADIUS/TLS.
サーバーがクライアントからALPN名を受信した場合、接続を閉じてはなりません。代わりに、ALPNを使用して返信せず、歴史的な半径/TLSに対して定義されているTLS接続セットアップを完了します。
Note that if a client sends "radius/1.1", the client will see that the server failed to acknowledge this request and will close the connection. For any other client configuration, the connection will use historic RADIUS/TLS.
クライアントが「RADIUS/1.1」を送信すると、クライアントはサーバーがこのリクエストを認めなかったことを確認し、接続を閉じることに注意してください。他のクライアント構成では、接続は歴史的な半径/TLSを使用します。
B. If set to "1.0", "1.0, 1.1", "1.1", or future values:
B.「1.0」、「1.0、1.1」、「1.1」、または将来の値に設定した場合：
Client Behavior
クライアントの動作
The client MUST send the ALPN string(s) associated with the configured version. For example, send "radius/1.0" for "1.0".
クライアントは、構成されたバージョンに関連付けられたALPN文字列を送信する必要があります。たとえば、「1.0」に「radius/1.0」を送信します。
The client will receive either no ALPN response from the server; or it will receive an ALPN response of one version string that MUST match one of the strings it sent; or else they will receive a TLS alert of "no_application_protocol" (120).
クライアントは、サーバーからALPN応答を受け取りません。または、送信した文字列の1つと一致する必要がある1つのバージョン文字列のALPN応答が表示されます。または、「no_application_protocol」（120）のTLSアラートを受け取ります。
If the connection remains open, the client MUST treat the connection as using the matching ALPN version.
接続が開いたままである場合、クライアントは接続を一致するALPNバージョンを使用して扱う必要があります。
Server Behavior
サーバーの動作
If the server receives no ALPN name from the client, it MUST use historic RADIUS/TLS.
サーバーがクライアントからALPN名を受信しない場合、歴史的な半径/TLSを使用する必要があります。
If the server receives one or more ALPN names from the client, it MUST reply with the highest mutually supported version and then use the latest supported version for this connection.
サーバーがクライアントから1つ以上のALPN名を受信した場合、相互にサポートされている最高のバージョンで返信し、この接続に最新のサポートバージョンを使用する必要があります。
If the server receives one or more ALPN names from the client, but none of the names match the versions supported by (or configured on) the server, it MUST reply with a TLS alert of "no_application_protocol" (120), and then it MUST close the TLS connection.
サーバーがクライアントから1つ以上のALPN名を受信しますが、名前がサーバーによってサポートされている（または構成された）バージョンと一致しない場合、「no_application_protocol」（120）のTLSアラートで返信する必要があります。
These requirements for negotiation are not specific to RADIUS/1.1; therefore, they can be used unchanged if any new version of RADIUS is defined.
交渉のためのこれらの要件は、半径/1.1に固有のものではありません。したがって、RADIUSの新しいバージョンが定義されている場合、それらは変更されずに使用できます。
By requiring the default configuration to allow historic RADIUS/TLS, implementations will be able to negotiate both historic RADIUS/TLS connections and also RADIUS/1.1 connections. Any other recommended default setting would prevent either the negotiation of historic RADIUS/TLS or prevent the negotiation of RADIUS/1.1.
歴史的な半径/TLSを許可するためにデフォルトの構成を要求することにより、実装は歴史的な半径/TLS接続と半径/1.1接続の両方をネゴシエートすることができます。その他の推奨されるデフォルト設定は、歴史的な半径/TLSの交渉を防ぐか、半径/1.1の交渉を防ぎます。
Once administrators verify that both ends of a connection support RADIUS/1.1, and that it has been negotiated successfully, the configurations SHOULD be updated to require RADIUS/1.1. The connections should be monitored after this change to ensure that the systems continue to remain connected. If there are connection issues, then the configuration should be reverted to allowing both "radius/1.0" and "radius/1.1" ALPN strings, until the administrator has resolved the connection problems.
管理者が接続の両端がRADIUS/1.1をサポートし、それが正常に交渉されたことを確認したら、半径/1.1を必要とするように構成を更新する必要があります。この変更後に接続を監視して、システムが接続され続けることを確認する必要があります。接続の問題がある場合は、管理者が接続の問題を解決するまで、「RADIUS/1.0」と「RADIUS/1.1」ALPN文字列の両方を許可するように構成を戻す必要があります。
We reiterate that systems implementing this specification, but which are configured with settings that forbid RADIUS/1.1, will behave largely the same as systems that do not implement this specification. The only difference is that clients may send the ALPN name "radius/1.0".
この仕様を実装するシステムを繰り返しますが、半径/1.1を禁止する設定で構成されていることは、この仕様を実装しないシステムとほぼ同じ動作します。唯一の違いは、クライアントがALPN名「RADIUS/1.0」を送信できることです。
Systems implementing RADIUS/1.1 SHOULD NOT be configured by default to forbid that protocol. That setting exists mainly for completeness, and to give administrators the flexibility to control their own deployments.
RADIUS/1.1を実装するシステムは、そのプロトコルを禁止するためにデフォルトで構成するべきではありません。その設定は、主に完全性のために存在し、管理者に独自の展開を制御する柔軟性を提供します。
While [RFC7301] does not discuss the possibility of the server sending a TLS alert of "no_application_protocol" (120) when the client does not use ALPN, this behavior appears to be useful. As such, servers MAY send a TLS alert of "no_application_protocol" (120) when the client does not use ALPN.
[RFC7301]は、クライアントがALPNを使用しない場合、サーバーが「no_application_protocol」（120）のTLSアラートを送信する可能性について議論していませんが、この動作は有用であると思われます。そのため、サーバーは、クライアントがALPNを使用しない場合、「no_application_protocol」（120）のTLSアラートを送信する場合があります。
However, some TLS implementations may not permit an application to send a TLS alert of its choice at a time of its choice. This limitation means that it is not always possible for an application to send the TLS alert as discussed in the previous section. The impact is that an implementation may attempt to connect and then see that the connection fails, but it may not be able to determine why that failure has occurred. Implementers and administrators should be aware that unexplained connection failures may be due to ALPN issues.
ただし、一部のTLS実装では、アプリケーションが選択した時点でTLSアラートを選択することを許可しない場合があります。この制限は、前のセクションで説明したように、アプリケーションがTLSアラートを送信できるとは限らないことを意味します。影響は、実装が接続を試みてから、接続が失敗することを確認しようとするかもしれませんが、その障害が発生した理由を判断できない場合があります。実装者と管理者は、説明のつかない接続の障害がALPNの問題によるものである可能性があることに注意する必要があります。
The server MAY send this alert during the ClientHello if it requires ALPN but does not receive it. That is, there may not always be a need to wait for the TLS connection to be fully established before realizing that no common ALPN protocol can be negotiated.
サーバーは、ALPNが必要であるが受信しない場合、ClientHello中にこのアラートを送信する場合があります。つまり、一般的なALPNプロトコルを交渉できないことを認識する前に、TLS接続が完全に確立されるのを常に待つ必要があるとは限りません。
Where the client does perform signaling via ALPN, and the server determines that there is no compatible application protocol name, then as per [RFC7301], Section 3.2, it MUST send a TLS alert of "no_application_protocol" (120).
クライアントがALPNを介してシグナリングを実行し、サーバーが互換性のあるアプリケーションプロトコル名がないと判断し、[RFC7301]、セクション3.2に従って、「no_application_protocol」（120）のTLSアラートを送信する必要があります。
The server MUST close the connection whether or not the server sent a TLS alert for no compatible ALPN. The above requirements on ALPN apply to both new sessions and to resumed sessions.
サーバーは、サーバーが互換性のあるALPNなしでTLSアラートを送信したかどうかにかかわらず、接続を閉じる必要があります。ALPNに関する上記の要件は、両方の新しいセッションと再開されたセッションに適用されます。
In contrast, there is no need for the client to signal that there are no compatible application protocol names. The client sends zero or more protocol names, and the server responds as above. From the point of view of the client, the list it sent results in either a connection failure or a connection success.
対照的に、クライアントが互換性のあるアプリケーションプロトコル名がないことを信号する必要はありません。クライアントはゼロ以上のプロトコル名を送信し、サーバーは上記のように応答します。クライアントの観点から、送信したリストは、接続の失敗または接続の成功のいずれかになります。
It is RECOMMENDED that the server logs a descriptive error in this situation, so that an administrator can determine why a particular connection failed. The log message SHOULD include information about the other end of the connection, such as the IP address, certificate information, etc. Similarly, when the client receives a TLS alert of "no_application_protocol" (120), it SHOULD log a descriptive error message. Such error messages are critical for helping administrators diagnose connectivity issues.
この状況でサーバーが記述エラーを記述し、管理者が特定の接続が失敗した理由を判断できるようにすることをお勧めします。ログメッセージには、IPアドレス、証明書情報など、接続の反対側に関する情報を含める必要があります。同様に、クライアントが「no_application_protocol」（120）のTLSアラートを受信した場合、説明的なエラーメッセージを記録する必要があります。このようなエラーメッセージは、管理者が接続性の問題を診断するのに役立つために重要です。
When it is not possible to send a TLS alert of "no_application_protocol" (120), then the only remaining method for one party to signal the other is to send application data inside of the TLS tunnel. Therefore, for the situation when one end of a connection determines that it requires ALPN, while the other end does not support ALPN, then the end requiring ALPN MAY send a Protocol-Error packet [RFC7930] inside of the tunnel and then MUST close the connection. If this is done, the Token field of the Protocol-Error packet cannot be copied from any request; therefore, that field MUST be set to all zeros.
「no_application_protocol」（120）のTLSアラートを送信できない場合、一方の当事者が他方の当事者に合図する唯一の残りの方法は、TLSトンネル内にアプリケーションデータを送信することです。したがって、接続の一方の端がALPNが必要であると判断した状況では、もう一方の端はALPNをサポートしていませんが、ALPNを必要とする端はトンネル内にプロトコルエラーパケット[RFC7930]を送信し、接続を閉じる必要があります。これが行われた場合、プロトコルエラーパケットのトークンフィールドをリクエストからコピーすることはできません。したがって、そのフィールドはすべてのゼロに設定する必要があります。
The Protocol-Error packet SHOULD contain a Reply-Message attribute with a textual string describing the cause of the error. The packet SHOULD also contain an Error-Cause attribute, with value 406 (Unsupported Extension). The packet SHOULD NOT contain other attributes.
プロトコルエラーパケットには、エラーの原因を説明するテキスト文字列を持つReply-Message属性を含める必要があります。パケットには、値406（サポートされていない拡張子）のエラー原因属性も含まれている必要があります。パケットには他の属性を含めるべきではありません。
An implementation sending this packet could bypass any RADIUS encoder and simply write this packet as a predefined, fixed set of data to the TLS connection. That process would likely be simpler than trying to call the normal RADIUS packet encoder to encode a reply packet with no corresponding request packet.
このパケットを送信する実装は、任意のRADIUSエンコーダーをバイパスし、このパケットを定義された固定データセットとしてTLS接続に書き込むだけです。このプロセスは、通常のRadiusパケットエンコーダーを呼び出して、対応するリクエストパケットなしで返信パケットをエンコードしようとするよりも簡単です。
As this packet is an unexpected response packet, existing client implementations of RADIUS over TLS will ignore it. They may either log an error and close the connection, or they may discard the packet and leave the connection open. If the connection remains open, the end supporting ALPN will close the connection, so there will be no side effects from sending this packet. Therefore, while using a Protocol-Error packet in this way is unusual, it is both informative and safe.
このパケットは予期しない応答パケットであるため、TLS上のRADIUSの既存のクライアント実装はそれを無視します。エラーを記録して接続を閉じるか、パケットを破棄して接続を開いたままにする場合があります。接続が開いたままである場合、ALPNをサポートするエンドが接続を閉じるため、このパケットの送信による副作用はありません。したがって、この方法でプロトコルエラーパケットを使用することは珍しいことですが、有益で安全です。
The purpose of this packet is not to have the other end of the connection automatically determine what went wrong and fix it. Instead, the packet is intended to be (eventually) seen by an administrator, who can then take remedial action.
このパケットの目的は、接続の反対側に何が間違っているかを自動的に決定して修正しないことです。代わりに、パケットは管理者が（最終的に）見られることを目的としており、管理者は是正措置を講じることができます。
The preceding text gives a large number of recommendations. In order to give a simpler description of the outcomes, a table of possible behaviors for client/server values of the Version variable is given below. The row and column headings are the RADIUS version numbers sent in ALPN (or no ALPN). The contents of the table are the resulting RADIUS version that is negotiated. For clarity, only the RADIUS version numbers have been given, and not the full ALPN strings (e.g., "radius/1.0").
前のテキストは、多数の推奨事項を提供します。結果をより簡単に説明するために、バージョン変数のクライアント/サーバー値の可能性のある動作の表を以下に示します。行と列の見出しは、ALPNで送信された半径バージョン番号（またはALPNなし）です。テーブルの内容は、ネゴシエートされる結果のRADIUSバージョンです。明確にするために、完全なALPN文字列（「RADIUS/1.0」など）ではなく、半径バージョンの数値のみが与えられています。
This table and the names given below are for informational and descriptive purposes only.
このテーブルと以下の名前は、情報および説明のみのためのものです。
+==========+======================================+
| Client | Server |
| +=========+=======+==========+=========+
| | no ALPN | 1.0 | 1.0, 1.1 | 1.1 |
+==========+=========+=======+==========+=========+
| no ALPN | TLS | TLS | TLS | Close-S |
+==========+---------+-------+----------+---------+
| 1.0 | TLS | TLS | TLS | Alert |
+==========+---------+-------+----------+---------+
| 1.0, 1.1 | TLS | TLS | 1.1 | 1.1 |
+==========+---------+-------+----------+---------+
| 1.1 | Close-C | Alert | 1.1 | 1.1 |
+==========+---------+-------+----------+---------+
Table 2: Possible Outcomes for ALPN
表2：ALPNの結果の可能性
The table entries above have the following meaning:
上記のテーブルエントリには、次の意味があります。
Alert
アラート
The client sends ALPN, and the server does not agree to the client's ALPN proposal. The server replies with a TLS alert of "no_application_protocol" (120) and then closes the TLS connection.
クライアントはALPNを送信すると、サーバーはクライアントのALPN提案に同意しません。サーバーは、「no_application_protocol」（120）のTLSアラートで応答し、TLS接続を閉じます。
As the server replies with a TLS alert, the Protocol-Error packet is not used here.
サーバーがTLSアラートで返信するため、プロトコルエラーパケットはここでは使用されません。
Close-C
Close-C
The client sends ALPN, but the server does not respond with ALPN. The client closes the connection.
クライアントはALPNを送信しますが、サーバーはALPNで応答しません。クライアントは接続を閉じます。
As noted in the previous section, the client MAY send a Protocol-Error packet to the server before closing the connection.
前のセクションで述べたように、クライアントは、接続を閉じる前にプロトコルエラーパケットをサーバーに送信する場合があります。
Close-S
Close-S
The client does not send ALPN string(s), but the server requires ALPN. The server closes the connection.
クライアントはALPN文字列を送信しませんが、サーバーにはALPNが必要です。サーバーは接続を閉じます。
As noted in the previous section, the server MAY send a Protocol-Error packet to the client before closing the connection. The server MAY also send a TLS alert of "no_application_protocol" (120) before closing the connection.
前のセクションで述べたように、サーバーは接続を閉じる前にクライアントにプロトコルエラーパケットを送信する場合があります。サーバーは、接続を閉じる前に「no_application_protocol」（120）のTLSアラートを送信することもできます。
TLS
TLS
Historic RADIUS/TLS is used. The client either sends no ALPN string or sends "radius/1.0". The server either replies with no ALPN string or with "radius/1.0". The connection MUST use historic RADIUS/TLS.
歴史的な半径/TLSが使用されます。クライアントは、ALPN文字列を送信しないか、「RADIUS/1.0」を送信します。サーバーは、ALPN文字列なしまたは「RADIUS/1.0」で返信します。接続は、歴史的な半径/TLSを使用する必要があります。
1.1
1.1
The client sends the ALPN string "radius/1.1". The server acknowledges this negotiation with a reply of "radius/1.1", and then RADIUS/1.1 is used.
クライアントは、ALPN文字列「RADIUS/1.1」を送信します。サーバーは、この交渉を「RADIUS/1.1」の返信とともに認め、その後、半径/1.1が使用されます。
Implementations should note that this table may be extended in future specifications. The above text is informative, and does not mandate that only the above ALPN strings are used. The actual ALPN takes place as defined in the preceding sections of this document and in [RFC7301].
実装は、このテーブルが将来の仕様で拡張される可能性があることに注意する必要があります。上記のテキストは有益であり、上記のALPN文字列のみが使用されることを義務付けていません。実際のALPNは、このドキュメントの前のセクションと[RFC7301]で定義されているように発生します。
Implementations of this specification MUST require TLS version 1.3 or later.
この仕様の実装には、TLSバージョン1.3以降が必要です。
The use of the ALPN string "radius/1.0" is technically unnecessary, as it is largely equivalent to not sending any ALPN string. However, that value is useful for RADIUS administrators. A system that sends the ALPN string "radius/1.0" is explicitly signaling that it supports ALPN, but that it is not currently configured to support RADIUS/1.1. That information can be used by administrators to determine which devices are capable of ALPN.
ALPN文字列「RADIUS/1.0」の使用は、ALPN文字列を送信しないこととほぼ同等であるため、技術的には不要です。ただし、その値はRADIUS管理者に役立ちます。ALPN文字列「RADIUS/1.0」を送信するシステムは、ALPNをサポートしていることを明示的に知らせていますが、現在は半径/1.1をサポートするように構成されていないことを示しています。その情報は、管理者が使用して、どのデバイスがALPNが可能かを決定することができます。
The use of the ALPN string "radius/1.0" also permits server implementations to send a TLS alert of "no_application_protocol" (120) when it cannot find a matching ALPN string. Experiments with TLS library implementations suggest that in some cases it is possible to send that TLS alert when ALPN is not used. However, such a scenario is not discussed in [RFC7301] and is likely not universal. As a result, ALPN as defined in [RFC7301] permits servers to send that TLS alert in situations where it would be otherwise forbidden or perhaps unsupported.
ALPN文字列「RADIUS/1.0」の使用により、サーバーの実装は、一致するALPN文字列を見つけることができないときに「no_application_protocol」（120）のTLSアラートを送信できます。TLSライブラリの実装を使用した実験では、ALPNが使用されていない場合にTLSアラートを送信できる場合があることが示唆されています。ただし、このようなシナリオは[RFC7301]で説明されておらず、おそらく普遍的ではありません。その結果、[RFC7301]で定義されているALPNにより、サーバーは、そうでなければ禁止またはおそらくサポートされていない状況で、TLSアラートを送信できます。
Finally, defining ALPN strings for all known RADIUS versions will make it easier to support additional ALPN strings if that functionality is ever needed.
最後に、すべての既知のRADIUSバージョンのALPN文字列を定義することで、その機能が必要な場合は、追加のALPN文字列を簡単にサポートできます。
[RFC7301], Section 3.1 states that ALPN is negotiated on each connection, even if session resumption is used:
[RFC7301]、セクション3.1は、セッション再開が使用されていても、ALPNが各接続で交渉されることを示しています。
When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered.
セッションの再開またはセッションチケット[RFC5077]を使用すると、この拡張機能の以前の内容は無関係であり、新しいハンドシェイクメッセージの値のみが考慮されます。
(Note: RFC 5077 was obsoleted by [RFC8446].)
（注：RFC 5077は[RFC8446]によって廃止されました。）
In order to prevent down-bidding attacks, RADIUS systems that negotiate the "radius/1.1" protocol MUST associate that information with the session ticket and enforce the use of "radius/1.1" on session resumption. That is, if "radius/1.1" was negotiated for a session, both clients and servers MUST behave as if the RADIUS/1.1 variable was set to "require" for that session.
ダウンビディング攻撃を防ぐために、「RADIUS/1.1」プロトコルを交渉するRADIUSシステムは、その情報をセッションチケットに関連付け、セッション再開での「RADIUS/1.1」の使用を実施する必要があります。つまり、「RADIUS/1.1」がセッションのためにネゴシエートされた場合、クライアントとサーバーの両方がそのセッションに「必要」に設定されているかのように動作する必要があります。
A client that is resuming a "radius/1.1" connection MUST advertise only the capability to do "radius/1.1" for the resumed session. That is, even if the client configuration allows historic RADIUS/TLS for new connections, it MUST signal "radius/1.1" when resuming a session that had previously negotiated "radius/1.1".
「RADIUS/1.1」接続を再開しているクライアントは、再開されたセッションの「RADIUS/1.1」のみを行う機能のみを宣伝する必要があります。つまり、クライアントの構成が新しい接続の歴史的な半径/TLSを許可している場合でも、以前に「RADIUS/1.1」を交渉したセッションを再開するときに「半径/1.1」を信号する必要があります。
Similarly, when a server does resumption for a session that had previously negotiated "radius/1.1", if the client attempts to resume the sessions without signaling the use of RADIUS/1.1, the server MUST close the connection. The server MUST send an appropriate TLS error, and also SHOULD log a descriptive message as described above.
同様に、サーバーが以前に「RADIUS/1.1」を交渉したセッションの再開を行うと、クライアントがRADIUS/1.1の使用を知らせることなくセッションを再開しようとする場合、サーバーは接続を閉じる必要があります。サーバーは適切なTLSエラーを送信する必要があり、上記のように記述メッセージを記述する必要があります。
In contrast, there is no requirement for a client or server to force the use of RADIUS/TLS from [RFC6614] on session resumption. Clients are free to signal support for "radius/1.1" on resumed sessions, even if the original session did not negotiate "radius/1.1". Servers are free to accept this request and to negotiate the use of "radius/1.1" for such sessions.
対照的に、セッション再開時に[RFC6614]からの半径/TLSの使用を強制するためのクライアントまたはサーバーが要件はありません。クライアントは、元のセッションで「RADIUS/1.1」と交渉しなかった場合でも、再開されたセッションで「RADIUS/1.1」のサポートを自由に信号します。サーバーは、このリクエストを自由に受け入れ、そのようなセッションで「RADIUS/1.1」の使用を交渉します。
This section describes the application-layer data that is sent inside of (D)TLS when using the RADIUS/1.1 protocol. Unless otherwise discussed herein, the application-layer data is unchanged from historic RADIUS. This protocol is only used when "radius/1.1" has been negotiated by both ends of a connection.
このセクションでは、RADIUS/1.1プロトコルを使用するときに（d）TLS内で送信されるアプリケーション層データについて説明します。ここで特に説明しない限り、アプリケーション層データは歴史的な半径から変更されていません。このプロトコルは、「RADIUS/1.1」が接続の両端によって交渉された場合にのみ使用されます。
When RADIUS/1.1 is used, the RADIUS header is modified from standard RADIUS. While the header has the same size, some fields have different meanings. The Identifier and the Request and Response Authenticator fields are no longer used in RADIUS/1.1. Any operations that depend on those fields MUST NOT be performed. As packet authentication, secrecy, and security are handled by the TLS layer, RADIUS-specific cryptographic primitives are no longer needed or used in RADIUS/1.1.
半径/1.1を使用すると、半径ヘッダーは標準半径から変更されます。ヘッダーのサイズは同じですが、一部のフィールドには意味が異なります。識別子とリクエストと応答の認証機フィールドは、半径/1.1では使用されなくなりました。これらのフィールドに依存する操作は、実行してはなりません。パケット認証、秘密、およびセキュリティがTLSレイヤーによって処理されるため、半径固有の暗号化プリミティブは、半径/1.1ではもはや必要であるか、使用されません。
A summary of the RADIUS/1.1 packet format is shown below. The fields are transmitted from left to right.
半径/1.1パケット形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Reserved-1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reserved-2 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: The RADIUS/1.1 Packet Format
図1：RADIUS/1.1パケット形式
Code
コード
The Code field is one octet and identifies the type of RADIUS packet.
コードフィールドは1つのオクテットで、RADIUSパケットのタイプを識別します。
The meaning of the Code field is unchanged from previous RADIUS specifications.
コードフィールドの意味は、以前の半径の仕様から変更されません。
Reserved-1
予約1
The Reserved-1 field is one octet.
予約済み1フィールドは1オクテットです。
This field was previously used as the "Identifier" in historic RADIUS/TLS. It is now unused, as the Token field replaces it both as the way to identify requests and to associate responses with requests.
このフィールドは、以前は歴史的な半径/TLSの「識別子」として使用されていました。トークンフィールドは、リクエストを識別し、応答をリクエストに関連付ける方法として置き換えるため、現在使用されていません。
When sending packets, the Reserved-1 field MUST be set to zero. The Reserved-1 field MUST be ignored when receiving a packet.
パケットを送信するときは、予約1フィールドをゼロに設定する必要があります。パケットを受け取るときは、予約済み1フィールドを無視する必要があります。
Length
長さ
The Length field is two octets.
長さフィールドは2オクテットです。
The meaning of the Length field is unchanged from previous RADIUS specifications.
長さフィールドの意味は、以前の半径の仕様から変更されません。
Token
トークン
The Token field is four octets and aids in matching requests and replies, as a replacement for the Identifier field. The RADIUS server can detect a duplicate request if it receives the same Token value for two packets on a particular connection.
トークンフィールドは4つのオクテットであり、識別子フィールドの代替品として、リクエストと返信を一致させるのに役立ちます。RADIUSサーバーは、特定の接続上の2つのパケットの同じトークン値を受信した場合、重複した要求を検出できます。
All values are possible for the Token field. Implementations MUST treat the Token as an opaque blob when comparing Token values.
トークンフィールドではすべての値が可能です。実装は、トークン値を比較する際に、トークンを不透明なブロブとして扱う必要があります。
Further requirements are given below in Section 4.2.1 for sending packets and in Section 4.2.2 for receiving packets.
パケットの送信用のセクション4.2.1および受信パケットのセクション4.2.2には、さらに要件があります。
Reserved-2
予約済み2
The Reserved-2 field is twelve (12) octets in length.
予約された2フィールドの長さは12個のオクテットです。
These octets MUST be set to zero when sending a packet.
これらのオクテットは、パケットを送信するときにゼロに設定する必要があります。
These octets MUST be ignored when receiving a packet.
これらのオクテットは、パケットを受け取るときは無視する必要があります。
These octets are reserved for future protocol extensions.
これらのオクテットは、将来のプロトコル拡張用に予約されています。
This section describes in more detail how the Token field is used.
このセクションでは、トークンフィールドの使用方法について詳しく説明します。
The Token field MUST change for every new unique packet that is sent on the same connection. For DTLS transport, it is possible to retransmit duplicate packets, in which case the Token value MUST NOT be changed when a duplicate packet is (re)sent. When the contents of a retransmitted packet change for any reason (such as changing Acct-Delay-Time as discussed in [RFC2866], Section 5.2), the Token value MUST be changed. Note that on reliable transports, packets are never retransmitted; therefore, every new packet that is sent has a unique Token value.
トークンフィールドは、同じ接続で送信されるすべての新しい一意のパケットに対して変更する必要があります。DTLSトランスポートの場合、重複したパケットを再送信することができます。この場合、重複パケットが（再）送信されたときにトークン値を変更しないでください。何らかの理由で再送信パケットの内容が変更された場合（[RFC2866]、セクション5.2で説明されているACCT-Delay-Timeの変更など）、トークン値を変更する必要があります。信頼できるトランスポートでは、パケットが再送信されることはないことに注意してください。したがって、送信されるすべての新しいパケットには、一意のトークン値があります。
We note that in previous RADIUS specifications, the Identifier field could have the same value for different packets on the same connection. For example, Access-Request (Code 1) and Accounting-Request (Code 4) packets could both use ID 3 and still be treated as different packets. This overlap requires that RADIUS clients and servers track the Identifier field, not only on a per-connection basis, but also on a per-Code basis. This behavior adds complexity to implementations.
以前の半径仕様では、識別子フィールドは同じ接続上の異なるパケットに対して同じ値を持つ可能性があることに注意してください。たとえば、Access-Request（コード1）およびAccounting-Request（コード4）パケットは、ID 3を使用しても、異なるパケットとして扱われる可能性があります。このオーバーラップには、RADIUSクライアントとサーバーが識別子フィールドを追跡する必要があります。これは、接続ごとにだけでなく、コードごとにも識別子フィールドを追跡する必要があります。この動作は、実装に複雑さを加えます。
In contrast, the Token values MUST be generated from a 32-bit counter that is unique to each connection. Such a counter SHOULD be initialized to a random value, taken from a random number generator, whenever a new connection is opened. The counter MUST then be incremented for every unique new packet that is sent by the client. Retransmissions of the same packet MUST use the same unchanged Token value. As the Token value is mandated to be unique per packet, a duplicate Token value is the only way that a server can detect duplicate transmissions.
対照的に、各接続に固有の32ビットカウンターからトークン値を生成する必要があります。このようなカウンターは、新しい接続が開かれるたびに、乱数ジェネレーターから取得したランダム値に初期化する必要があります。その後、クライアントが送信するすべてのユニークな新しいパケットに対して、カウンターをインクリメントする必要があります。同じパケットの再送信は、同じ不変のトークン値を使用する必要があります。トークン値はパケットごとに一意であることが義務付けられているため、重複するトークン値は、サーバーが重複する送信を検出できる唯一の方法です。
This counter method ensures that the Tokens are unique and are also independent of any Code value in the RADIUS packet header. This method is mandated because any other method of generating unique and non-conflicting Token values is more complex, with no additional benefit and only the likelihood of increased bugs and interoperability issues. Any other method for generating Token values would require substantially more resources to track outstanding Token values and their associated expiry times. The chance that initial values could potentially cause any confusion by being reused across two connections is one in 2^32, which is acceptable.
このカウンターメソッドは、トークンが一意であり、RADIUSパケットヘッダーのコード値とは無関係であることを保証します。この方法は義務付けられています。これは、一意で紛れないトークン値を生成する他の方法がより複雑であり、追加の利点がなく、バグと相互運用性の問題の増加の可能性のみがあるためです。トークン値を生成する他の方法では、未解決のトークン値とそれに関連する有効時間を追跡するために、かなり多くのリソースが必要になります。初期値が2つの接続で再利用されることで混乱を引き起こす可能性があるという可能性は、2^32の1つであり、許容されます。
The purpose for initializing the Token to a random counter is mainly to aid administrators in debugging systems. If the Token values always used the same sequence, then it would easier for a person to confuse different packets that have the same Token value. By instead starting with a random value, those values are more evenly distributed across the set of allowed values; therefore, they are more likely to be unique.
トークンをランダムなカウンターに初期化する目的は、主に管理者がデバッグシステムを支援することです。トークン値が常に同じシーケンスを使用している場合、人が同じトークン値を持つ異なるパケットを混乱させる方が簡単になります。代わりに、ランダム値から始めることにより、これらの値は許可された値のセット全体でより均等に分布します。したがって、それらはユニークである可能性が高くなります。
As there is no special meaning for the Token, there is no meaning when a counter "wraps" around from a high value back to zero. The originating system can simply continue to increment the Token value without taking any special action in that situation.
トークンには特別な意味がないため、カウンターが高い値からゼロに「ラップ」する場合、意味はありません。発信元のシステムは、その状況で特別な行動をとることなく、単にトークンの値を増やし続けることができます。
Once a RADIUS response to a request has been received and there is no need to track the packet any longer, the Token value can be reused. This reuse happens only when the counter "wraps around" after 2^32 packets have been sent over one connection. This method of managing the counter automatically ensures a long delay (i.e., 2^32 packets) between multiple uses of the same Token value. This large number of packets ensures that the only possible situation where there may be conflict is when a client sends billions of packets a second across one connection, or when a client sends billions of packets without receiving replies. We suggest that such situations are vanishingly rare. The best solution to those situations would be to limit the number of outstanding packets over one connection to a number much lower than billions.
リクエストに対する半径の応答が受信され、パケットを追跡する必要がなくなると、トークン値を再利用できます。この再利用は、2^32のパケットが1つの接続で送信された後にカウンターが「ラップ」した場合にのみ発生します。カウンターを管理するこの方法により、同じトークン値の複数の使用間で長い遅延（つまり、2^32パケット）が自動的に保証されます。この多数のパケットにより、競合がある可能性のある唯一の可能な状況は、クライアントが1つの接続間で数十億個のパケットを送信する場合、またはクライアントが返信を受けずに数十億パケットを送信する場合です。そのような状況は消えてしまうことをお勧めします。これらの状況に対する最良の解決策は、1つの接続で数十億よりもはるかに低い数への未払いのパケットの数を制限することです。
If a RADIUS client has multiple independent subsystems that send packets to a server, each subsystem MAY open a new connection that is unique to that subsystem. There is no requirement that all packets go over one particular connection. That is, despite the use of a 32-bit Token field, RADIUS/1.1 clients are still permitted to open multiple source ports as discussed in [RFC2865], Section 2.5.
RADIUSクライアントにパケットをサーバーに送信する複数の独立したサブシステムがある場合、各サブシステムは、そのサブシステムに固有の新しい接続を開く場合があります。すべてのパケットが特定の接続を介して進むという要件はありません。つまり、32ビットトークンフィールドの使用にもかかわらず、[RFC2865]、セクション2.5で説明したように、半径/1.1クライアントは依然として複数のソースポートを開くことが許可されています。
While multiple connections from client to server are allowed, we reiterate the suggestion of [RFC3539], Section 3.3 that a single connection is preferred to multiple connections. The use of a single connection can improve throughput and latency, while simplifying the client's efforts to determine server status.
クライアントからサーバーへの複数の接続が許可されていますが、[RFC3539]の提案を繰り返します。セクション3.3は、単一の接続が複数の接続よりも優先されることを繰り返します。単一の接続を使用すると、サーバーのステータスを決定するためのクライアントの取り組みを簡素化しながら、スループットとレイテンシを改善できます。
A server that receives RADIUS/1.1 packets MUST perform packet deduplication for all situations where it is required by RADIUS. Where RADIUS does not require deduplication (e.g., TLS transport), the server SHOULD NOT do deduplication. However, DTLS transport is UDP-based, and therefore still requires deduplication.
RADIUS/1.1パケットを受信するサーバーは、RADIUSが必要とするすべての状況に対してパケット重複排除を実行する必要があります。半径が重複排除（TLS輸送など）を必要としない場合、サーバーは重複排除を行うべきではありません。ただし、DTLSトランスポートはUDPベースであるため、重複排除が必要です。
When using RADIUS/1.1, implementations MUST do deduplication only on the Token field, and not on any other field or fields in the packet header. A server MUST treat the Token as being an opaque field with no intrinsic meaning. This requirement makes the receiver behavior independent of the methods by which the Counter is generated.
RADIUS/1.1を使用する場合、実装は、パケットヘッダー内の他のフィールドまたはフィールドでは、トークンフィールドでのみ重複排除を行う必要があります。サーバーは、本質的な意味のない不透明なフィールドとしてトークンを扱う必要があります。この要件により、カウンターが生成される方法とは無関係にレシーバーの動作ができます。
Where Token deduplication is done, it MUST be done on a per-connection basis. If two packets that are received on different connections contain the same Token value, then those packets MUST be treated as distinct (i.e., different) packets. Systems performing deduplication MAY still track the packet Code, Length, and Attributes that are associated with a Token value. If it determines that the sender is reusing Token values for distinct outstanding packets, then an error should be logged, and the connection MUST be closed. There is no way to negotiate correct behavior in the protocol. Either both parties operate normally and can communicate, or one end misbehaves and no communication is possible.
トークン重複排除が行われる場合、それは接続ごとに行う必要があります。異なる接続で受信される2つのパケットに同じトークン値が含まれている場合、それらのパケットは異なる（つまり、異なる）パケットとして扱わなければなりません。重複排除を実行するシステムは、トークン値に関連付けられているパケットコード、長さ、および属性を追跡する場合があります。送信者が異なる未解決のパケットに対してトークン値を再利用していると判断した場合、エラーを記録し、接続を閉じる必要があります。プロトコルで正しい動作を交渉する方法はありません。両方の当事者が正常に動作し、通信することができるか、一方の端の不正行為とコミュニケーションは不可能です。
Once a reply has been sent, a system doing deduplication SHOULD cache the replies as discussed in [RFC5080], Section 2.2.2:
返信が送信されたら、重複排除を行うシステムは、[RFC5080]で説明されているように応答をキャッシュする必要があります。セクション2.2.2：
Each cache entry SHOULD be purged after a period of time. This time SHOULD be no less than 5 seconds, and no more than 30 seconds. After about 30 seconds, most RADIUS clients and end users will have given up on the authentication request. Therefore, there is little value in having a larger cache timeout.
各キャッシュエントリは、一定期間後にパージする必要があります。今回は5秒以上、30秒以内になるはずです。約30秒後、ほとんどのRADIUSクライアントとエンドユーザーは認証リクエストをあきらめます。したがって、より大きなキャッシュタイムアウトを持つことにはほとんど価値がありません。
This change from RADIUS means that the Identifier field is no longer useful for RADIUS/1.1. The Reserved-1 field (previously used as the Identifier) MUST be set to zero when encoding all RADIUS/1.1 packets. Implementations of RADIUS/1.1 that receive packets MUST ignore this field.
半径からのこの変化は、識別子フィールドが半径/1.1にもはや役に立たないことを意味します。すべてのRADIUS/1.1パケットをエンコードする場合、予約1フィールド（以前は識別子として使用されていた）をゼロに設定する必要があります。パケットを受信する半径/1.1の実装は、このフィールドを無視する必要があります。
Most attributes in RADIUS have no special encoding "on the wire", or any special meaning between client and server. Unless discussed in this section, all RADIUS attributes are unchanged in this specification. This requirement includes attributes that contain a tag, as defined in [RFC2868].
RADIUSのほとんどの属性には、「ワイヤー上」の特別なエンコード、またはクライアントとサーバーの間の特別な意味はありません。このセクションで説明しない限り、すべての半径属性はこの仕様では変更されません。この要件には、[RFC2868]で定義されているタグを含む属性が含まれます。
Since the (D)TLS layer provides for connection authentication, integrity checks, and confidentiality, there is no need to hide the contents of an attribute on a hop-by-hop basis. As a result, all attributes defined as being obfuscated via the shared secret no longer have the obfuscation step applied when RADIUS/1.1 is used. Instead, those attributes MUST be encoded using the encoding for the underlying data type, with any encryption / obfuscation step omitted. For example, the User-Password attribute is no longer obfuscated and is instead sent as data type "text".
（d）TLSレイヤーは、接続認証、整合性チェック、および機密性を提供するため、ホップバイホップベースで属性の内容を非表示にする必要はありません。その結果、共有秘密を介して難読化されていると定義されるすべての属性は、半径/1.1を使用するときに難読化ステップを適用しなくなりました。代わりに、これらの属性は、基礎となるデータ型のエンコードを使用してエンコードする必要があり、任意の暗号化 /観測ステップは省略されています。たとえば、ユーザーパスワード属性は難読化されなくなり、代わりにデータ型「テキスト」として送信されます。
There are risks from sending passwords over the network, even when they are protected by TLS. One such risk comes from the common practice of multi-hop RADIUS routing. As all security in RADIUS is on a hop-by-hop basis, every proxy that receives a RADIUS packet can see (and modify) all of the information in the packet. Sites wishing to avoid proxies SHOULD use dynamic peer discovery [RFC7585], which permits clients to make connections directly to authoritative servers for a realm.
TLSによって保護されている場合でも、ネットワークを介してパスワードを送信することでリスクがあります。そのようなリスクの1つは、マルチホップ半径ルーティングの一般的な慣行から生じます。RADIUSのすべてのセキュリティはホップバイホップベースであるため、RADIUSパケットを受信するすべてのプロキシは、パケット内のすべての情報を表示（および変更）できます。プロキシを避けたいサイトは、動的なピアディスカバリー[RFC7585]を使用する必要があります。これにより、クライアントは領域の権威あるサーバーに直接接続することができます。
There are other ways to mitigate these risks. The simplest is to follow the requirements of item (3) from [RFC6614], Section 3.4 and also follow [RFC7360], Section 10.4, which mandates that RADIUS over TLS implementations validate the peer before sending any RADIUS traffic.
これらのリスクを軽減する他の方法があります。最も簡単なのは、[RFC6614]のセクション3.4の項目（3）の要件に従い、[RFC7360]、セクション10.4に従って、TLS実装の半径が半径トラフィックを送信する前にピアを検証することを義務付けることです。
Another way to mitigate these risks is for the system being authenticated to use an authentication protocol that never sends passwords (e.g., an Extensible Authentication Protocol (EAP) method like EAP-pwd [RFC5931]), or one that sends passwords protected by a TLS tunnel (e.g., EAP Tunneled Transport Layer Security (EAP-TTLS) [RFC5281]). The processes to choose and configure an authentication protocol are strongly site dependent, so further discussions of these issues are outside of the scope of this document. The goal here is to ensure that the reader has enough information to make an informed decision.
Another way to mitigate these risks is for the system being authenticated to use an authentication protocol that never sends passwords (e.g., an Extensible Authentication Protocol (EAP) method like EAP-pwd [RFC5931]), or one that sends passwords protected by a TLS tunnel (e.g., EAP Tunneled Transport Layer Security (EAP-TTLS) [RFC5281]).認証プロトコルを選択および構成するプロセスは、サイトに強く依存しているため、これらの問題のさらなる議論は、このドキュメントの範囲外です。ここでの目標は、読者が情報に基づいた決定を下すのに十分な情報を持っていることを確認することです。
We note that as the RADIUS shared secret is no longer used in this specification, it is no longer possible or necessary for any attribute to be obfuscated on a hop-by-hop basis using the previous methods defined for RADIUS.
この仕様では、RADIUS共有秘密が使用されなくなったため、RADIUSで定義された以前のメソッドを使用して、ホップバイホップベースで属性を難読化することは不可能または必要ではないことに注意してください。
The User-Password attribute ([RFC2865], Section 5.2) MUST be encoded the same as any other attribute of data type "string" ([RFC8044], Section 3.5).
ユーザーパスワード属性（[RFC2865]、セクション5.2）は、データ型 "string"（[rfc8044]、セクション3.5）の他の属性と同じようにエンコードする必要があります。
The contents of the User-Password field MUST be at least one octet in length and MUST NOT be more than 128 octets in length. This limitation is maintained from [RFC2865], Section 5.2 for compatibility with historic transports.
ユーザーパスワードフィールドの内容は、少なくとも1オクテットの長さでなければならず、長さ128オクテットを超えてはなりません。この制限は、歴史的輸送との互換性については[RFC2865]、セクション5.2から維持されます。
Note that the User-Password attribute is not of data type "text". The original reason in [RFC2865] was because the attribute was encoded as an opaque and obfuscated binary blob. This document does not change the data type of User-Password, even though the attribute is no longer obfuscated. The contents of the User-Password attribute do not have to be printable text or UTF-8 data as per the definition of the "text" data type in [RFC8044], Section 3.4.
ユーザーパスワード属性はデータ型「テキスト」ではないことに注意してください。[RFC2865]の元の理由は、属性が不透明で難読化されたバイナリブロブとしてエンコードされたためです。このドキュメントは、属性が難読化されなくなっても、ユーザーパスワードのデータ型を変更しません。[RFC8044]、セクション3.4の「テキスト」データ型の定義に従って、ユーザーパスワード属性の内容は、印刷可能なテキストまたはUTF-8データである必要はありません。
However, implementations should be aware that passwords are often printable text, and where the passwords are printable text, it can be useful to store and display them as printable text. Where implementations can process non-printable data in the "text" data type, they MAY use the data type "text" for User-Password.
ただし、パスワードは多くの場合印刷可能なテキストであり、パスワードが印刷可能なテキストである場合、印刷可能なテキストとして保存および表示すると便利であることを実装する必要があります。実装が「テキスト」データ型で印刷できないデータを処理できる場合、ユーザーパスワードのデータ型「テキスト」を使用する場合があります。
[RFC2865], Section 5.3 allows for the CHAP challenge to be taken from either the CHAP-Challenge attribute ([RFC2865], Section 5.40) or the Request Authenticator field. Since RADIUS/1.1 connections no longer use a Request Authenticator field, it is no longer possible to use the Request Authenticator field as the CHAP-Challenge when this transport profile is used.
[RFC2865]、セクション5.3では、Chap-Challenge属性（[RFC2865]、セクション5.40）またはリクエスト認証器フィールドのいずれかからCHAPチャレンジを取得できます。RADIUS/1.1接続はリクエストAuthenticatorフィールドを使用しなくなったため、このトランスポートプロファイルが使用されているときに、Chap-Challengeとしてリクエスト認証機フィールドを使用することはできなくなりました。
Clients that send a CHAP-Password attribute ([RFC2865], Section 5.3) in an Access-Request packet over a RADIUS/1.1 connection MUST also include a CHAP-Challenge attribute ([RFC2865], Section 5.40).
RADIUS/1.1接続を介したAccess-RequestパケットでChap-Password属性（[RFC2865]、セクション5.3）を送信するクライアントには、Chap-Challenge属性（[RFC2865]、セクション5.40）も含まれている必要があります。
Proxies may need to receive Access-Request packets over a non-RADIUS/1.1 transport and then forward those packets over a RADIUS/1.1 connection. In that case, if the received Access-Request packet contains a CHAP-Password attribute but no CHAP-Challenge attribute, the proxy MUST create a CHAP-Challenge attribute in the proxied packet using the contents from the incoming Request Authenticator of the received packet.
プロキシは、非radius/1.1トランスポート上でアクセスリケストパケットを受信し、それらのパケットをRADIUS/1.1接続に転送する必要があります。その場合、受信したAccess-RequestパケットにChap-Password属性が含まれているがChap-Challenge属性が含まれていない場合、プロキシは、受信したパケットの着信要求認証者からのコンテンツを使用して、プロキシパケットにChap-Challenge属性を作成する必要があります。
The Tunnel-Password attribute ([RFC2868], Section 3.5) MUST be encoded the same as any other attribute of data type "string" that contains a tag, such as Tunnel-Client-Endpoint ([RFC2868], Section 3.3). Since the attribute is no longer obfuscated in RADIUS/1.1, there is no need for a Salt field or Data-Length fields as described in [RFC2868], Section 3.5. The textual value of the password can simply be encoded as is.
トンネルパスワード属性（[RFC2868]、セクション3.5）は、トンネルクライアントエンドポイント（[RFC2868]、セクション3.3）などのタグを含むデータ型「文字列」の他の属性と同じようにエンコードする必要があります。属性は半径/1.1で難読化されなくなったため、[RFC2868]、セクション3.5に記載されているように、塩フィールドまたはデータの長さのフィールドは必要ありません。パスワードのテキスト値は、単にそのままエンコードできます。
Note that the Tunnel-Password attribute is not of data type "text". The original reason in [RFC2868] was because the attribute was encoded as an opaque and obfuscated binary blob. We maintain that data type here, even though the attribute is no longer obfuscated. The contents of the Tunnel-Password attribute do not have to be printable text or UTF-8 data as per the definition of the "text" data type in [RFC8044], Section 3.4.
トンネルパスワード属性は、データ型「テキスト」ではないことに注意してください。[RFC2868]の元の理由は、属性が不透明で難読化されたバイナリブロブとしてエンコードされたためです。属性が難読化されなくなったとしても、このデータ型はここで維持します。[RFC8044]、セクション3.4の「テキスト」データ型の定義に従って、トンネルパスワード属性の内容は、印刷可能なテキストまたはUTF-8データである必要はありません。
However, implementations should be aware that passwords are often printable text, and where the passwords are printable text, it can be useful to store and display them as printable text. Where implementations can process non-printable data in the "text" data type, they MAY use the data type "text" for Tunnel-Password.
ただし、パスワードは多くの場合印刷可能なテキストであり、パスワードが印刷可能なテキストである場合、印刷可能なテキストとして保存および表示すると便利であることを実装する必要があります。実装が「テキスト」データ型で印刷できないデータを処理できる場合、トンネルパスワードのデータ型「テキスト」を使用する場合があります。
Any Vendor-Specific attribute that uses similar obfuscation MUST be encoded as per their base data type. Specifically, the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes ([RFC2548], Section 2.4) MUST be encoded as any other attribute of data type "string" ([RFC8044], Section 3.4).
同様の難読化を使用するベンダー固有の属性は、基本データ型に従ってエンコードする必要があります。具体的には、MS-MPPE-センドキーおよびMS-MPPE-RECV-KEY属性（[RFC2548]、セクション2.4）は、データ型「文字列」（[RFC8044]、セクション3.4）の他の属性としてエンコードする必要があります。
The Message-Authenticator attribute ([RFC3579], Section 3.2) MUST NOT be sent over a RADIUS/1.1 connection. That attribute is not used or needed in RADIUS/1.1.
Message-authenticator属性（[RFC3579]、セクション3.2）は、半径/1.1接続を介して送信しないでください。その属性は、半径/1.1で使用または必要はありません。
If the Message-Authenticator attribute is received over a RADIUS/1.1 connection, the attribute MUST be silently discarded or treated as an "invalid attribute", as defined in [RFC6929], Section 2.8. That is, the Message-Authenticator attribute is no longer used to authenticate packets for the RADIUS/1.1 transport. Its existence (or not) in this transport is meaningless.
[RFC6929]で定義されているように、属性は半径/1.1接続で受信される場合、属性は「無効な属性」として静かに破棄または扱わなければなりません。セクション2.8。つまり、Message-Authenticator属性は、RADIUS/1.1トランスポートのパケットを認証するために使用されなくなりました。この輸送におけるその存在（またはそうでない）は無意味です。
A system that receives a Message-Authenticator attribute in a packet MUST treat it as an "invalid attribute" as defined in [RFC6929], Section 2.8. That is, the packet can still be processed, even if the Message-Authenticator attribute is ignored.
パケット内のメッセージauthenticator属性を受信するシステムは、[RFC6929]、セクション2.8で定義されているように、「無効な属性」として扱う必要があります。つまり、メッセージauthenticator属性が無視されている場合でも、パケットを処理できます。
For proxies, the Message-Authenticator attribute has always been defined as being created and consumed on a "hop-by-hop" basis. That is, a proxy that received a Message-Authenticator attribute from a client would never forward that attribute as is to another server. Instead, the proxy would either suppress or recreate the Message-Authenticator attribute in the outgoing request. This existing behavior is leveraged in RADIUS/1.1 to suppress the use of the Message-Authenticator over a RADIUS/1.1 connection.
プロキシの場合、メッセージ-Authenticator属性は常に「ホップバイホップ」ベースで作成および消費されるものとして定義されています。つまり、クライアントからメッセージauthenticator属性を受け取ったプロキシは、他のサーバーにその属性を転送することはありません。代わりに、プロキシは、発信リクエストでメッセージauthenticator属性を抑制または再作成します。この既存の動作は、半径/1.1でレバレッジされており、半径/1.1接続を介したメッセージauthenticatorの使用を抑制します。
A proxy may receive an Access-Request packet over a RADIUS/1.1 connection and then forward that packet over a RADIUS/UDP or a RADIUS/TCP connection. In that situation, the proxy SHOULD add a Message-Authenticator attribute to every Access-Request packet that is sent over an insecure transport protocol.
プロキシは、RADIUS/1.1接続を介してアクセスリクエストパケットを受信し、そのパケットを半径/UDPまたは半径/TCP接続で転送できます。そのような状況では、プロキシは、不安定なトランスポートプロトコルに送信されるすべてのアクセスリケストパケットにメッセージauthenticator属性を追加する必要があります。
The original text in [RFC3579], Section 3.3, Note 1 required that the Message-Authenticator attribute be present for certain Access-Request packets. It also required the use of the Message-Authenticator when the Access-Request packet contained an EAP-Message attribute. Experience has shown that some RADIUS clients never use the Message-Authenticator, even for the situations where its use is suggested.
[RFC3579]の元のテキスト、セクション3.3、注1は、特定のAccess-Requestパケットにメッセージauthenticator属性が存在することを要求しました。また、Access-RequestパケットにEAPメッセージ属性が含まれている場合、メッセージ-Authenticatorの使用も必要でした。経験によると、一部のRADIUSクライアントは、その使用が示唆されている状況であっても、メッセージと告げることを決して使用しないことが示されています。
When the Message-Authenticator attribute is missing from Access-Request packets, it is often possible to trivially forge or replay those packets. As such, it is RECOMMENDED that RADIUS clients always include Message-Authenticator in Access-Request packets when using UDP or TCP transport. As the scope of this document is limited to defining RADIUS/1.1, we cannot mandate that behavior here. Instead, we can note that there are no known negatives to this behavior, and there are definite positives, such as increased security.
メッセージ-Authenticator属性がアクセスリケストパケットから欠落している場合、これらのパケットを簡単に偽造または再生することができることがよくあります。そのため、RADIUSクライアントには、UDPまたはTCPトランスポートを使用する場合、Access-Requestパケットに常にメッセージAuthenticatorを含めることが推奨されます。このドキュメントの範囲は半径/1.1の定義に限定されているため、ここでその動作を義務付けることはできません。代わりに、この動作には既知のネガがなく、セキュリティの増加など、明確なポジティブがあることに注意することができます。
Further issues related to Message-Authenticator are discussed in [DEPRECATE-RADIUS].
メッセージアーセンチケーターに関連するさらなる問題については、[Deprecate-radius]で説明します。
Similarly, the Message-Authentication-Code attribute defined in [RFC6218], Section 3.3 MUST NOT be sent over a RADIUS/1.1 connection. If it is received in a packet, it MUST be treated as an "invalid attribute" as defined in [RFC6929], Section 2.8.
同様に、[rfc6218]で定義されているメッセージauthentication-code属性は、セクション3.3を半径/1.1接続で送信してはなりません。パケットで受信した場合、[RFC6929]で定義されている「無効な属性」として扱わなければなりません。セクション2.8。
As the Message-Authentication-Code attribute is no longer used in RADIUS/1.1, the related MAC-Randomizer attribute ([RFC6218], Section 3.2) MUST NOT be sent over a RADIUS/1.1 connection. If it is received in a packet, it MUST be treated as an "invalid attribute" as defined in [RFC6929], Section 2.8.
Message-authentication-Code属性はRadius/1.1では使用されなくなったため、関連するMac-Randomizer属性（[RFC6218]、セクション3.2）は、RADIUS/1.1接続で送信してはなりません。パケットで受信した場合、[RFC6929]で定義されている「無効な属性」として扱わなければなりません。セクション2.8。
While some attributes such as CHAP-Password depend on insecure cryptographic primitives such as MD5, these attributes are treated as opaque blobs when sent between a RADIUS client and server. The contents of the attributes are not obfuscated, and they do not depend on the RADIUS shared secret. As a result, these attributes are unchanged in RADIUS/1.1.
Chap-Passwordなどのいくつかの属性は、MD5などの不安定な暗号化プリミティブに依存しますが、これらの属性は、RADIUSクライアントとサーバーの間に送信されると不透明なブロブとして扱われます。属性の内容は難読化されておらず、半径の共有秘密に依存しません。その結果、これらの属性は半径/1.1で変更されていません。
Similarly, MS-CHAP depends on MD4, and RADIUS/1.1 does not change the definition of any MS-CHAP attributes. However, MS-CHAP has been broken for decades, as noted in [ASLEAP]. The only appropriate use case for MS-CHAP is when it is protected by a secure transport such as RADIUS/TLS or RADIUS/DTLS, or when it is used for "inner tunnel" authentication methods as with the Protected Extensible Authentication Protocol (PEAP) or TTLS.
同様に、MS-ChapはMD4に依存し、RADIUS/1.1はMS-Chap属性の定義を変更しません。ただし、[ASLEAP]に記載されているように、MS-Chapは何十年も壊れてきました。MS-Chapの唯一の適切なユースケースは、半径/TLSや半径/DTLなどの安全な輸送によって保護されている場合、または保護された拡張認証プロトコル（PEAP）またはTTLSと同様に「内部トンネル」認証方法に使用される場合です。
A server implementing this specification can proxy and authenticate CHAP, MS-CHAP, etc. without any issue. The RADIUS/1.1 protocol changes how RADIUS packets are authenticated and how "secret" data is obfuscated inside of a RADIUS packet. It does not change any authentication method that is transported inside of RADIUS.
この仕様を実装するサーバーは、問題なくchap、ms-chapなどをプロキシおよび認証できます。RADIUS/1.1プロトコルは、RADIUSパケットがどのように認証され、RADIUSパケット内で「秘密」データが難読化されるかを変更します。半径内で輸送される認証方法は変更されません。
[RFC7930], Section 4 defines an Original-Packet-Code attribute. This attribute is needed because otherwise it is impossible to correlate the Protocol-Error response packet with a particular request packet. The definition in [RFC7930], Section 4 describes the reasoning behind this need:
[RFC7930]、セクション4では、元のパケットコード属性を定義します。それ以外の場合は、プロトコルエラー応答パケットを特定のリクエストパケットと相関させることが不可能であるため、この属性が必要です。[RFC7930]の定義では、セクション4では、このニーズの背後にある理由について説明します。
The Original-Packet-Code contains the code from the request that generated the protocol error so that clients can disambiguate requests with different codes and the same ID.
元のパケットコードには、プロトコルエラーを生成したリクエストからコードが含まれているため、クライアントは異なるコードと同じIDでリクエストを明確にすることができます。
This attribute is no longer needed in RADIUS/1.1. The Identifier field is unused, so it impossible for two requests to have the "same" ID. Instead, the Token field permits clients and servers to correlate requests and responses, independent of the Code value being used.
この属性は、半径/1.1では不要になります。識別子フィールドは使用されていないため、2つの要求が「同じ」IDを持つことは不可能です。代わりに、トークンフィールドは、使用されているコード値とは関係なく、クライアントとサーバーがリクエストと応答を相関させることを許可します。
Therefore, the Original-Packet-Code attribute ([RFC7930], Section 4) MUST NOT be sent over a RADIUS/1.1 connection. If it is received in a packet, it MUST be treated as an "invalid attribute" as defined in [RFC6929], Section 2.8.
したがって、元のパケットコード属性（[RFC7930]、セクション4）は、半径/1.1接続で送信してはなりません。パケットで受信した場合、[RFC6929]で定義されている「無効な属性」として扱わなければなりません。セクション2.8。
Most of the differences between RADIUS and RADIUS/1.1 are in the packet header and attribute handling, as discussed above. The remaining issues are a small set of unrelated topics, and are discussed here.
上記のように、半径と半径/1.1の違いのほとんどは、パケットヘッダーと属性処理にあります。残りの問題は、無関係なトピックの小さなセットであり、ここで説明します。
There are a number of situations where a RADIUS server is unable to respond to a request. One situation is where the server depends on a database, and the database is down. While arguably the server should close all incoming connections when it is unable to do anything, this action is not always effective. A client may aggressively try to open new connections or send packets to an unconnected UDP destination where the server is not listening. Another situation where the server is unable to respond is when the server is proxying packets, and the outbound connections are either full or failed.
RADIUSサーバーがリクエストに応答できない状況がいくつかあります。1つの状況は、サーバーがデータベースに依存し、データベースがダウンしている場所です。おそらく、サーバーは何もできないときに着信するすべての接続を閉じる必要がありますが、このアクションは必ずしも効果的ではありません。クライアントは、新しい接続を積極的に開いたり、サーバーがリスニングしていない接続されていないUDP宛先にパケットを送信したりする場合があります。サーバーが応答できない別の状況は、サーバーがパケットをプロキシしている場合、およびアウトバウンド接続が完全または失敗した場合です。
In all RADIUS specifications prior to this one, there is no way for the server to send a client the positive signal that it received a request but is unable to send a response. Instead, the server usually just discards the request, which to the client is indistinguishable from the situation where the server is down. This failure case is made worse by the fact that perhaps some proxied packets succeed while others fail. The client can only conclude then that the server is randomly dropping packets and is unreliable.
これ以前のすべてのRADIUS仕様において、サーバーがクライアントにリクエストを受け取ったが応答を送信できないという正の信号をクライアントに送信する方法はありません。代わりに、サーバーは通常、リクエストを破棄するだけです。クライアントにとっては、サーバーがダウンしている状況と見分けがつかのまりません。この障害のケースは、おそらく一部のプロキシされたパケットが成功し、他のパケットが失敗するという事実によって悪化します。クライアントは、サーバーがランダムにパケットをドロップしており、信頼できないと結論付けることができます。
It would be very useful for servers to signal to clients that they have received a request but are unable to process it. This specification uses the Protocol-Error packet ([RFC7930], Section 4) as that signal. The use of Protocol-Error allows for both hop-by-hop signaling in the case of proxy forwarding errors, and also for end-to-end signaling of server to client. Such signaling should greatly improve the robustness of the RADIUS protocol.
サーバーがクライアントにリクエストを受け取ったが、処理できないことをクライアントに信号を送ることは非常に便利です。この仕様では、プロトコルエラーパケット（[RFC7930]、セクション4）をその信号として使用します。プロトコルエラーを使用すると、プロキシ転送エラーの場合はホップバイホップシグナリング、およびサーバーのクライアントへのエンドツーエンドのシグナリングの両方が可能になります。このようなシグナル伝達は、半径プロトコルの堅牢性を大幅に改善するはずです。
When a RADIUS/1.1 server determines that it is unable to process an Access-Request or Accounting-Request packet, it MUST respond with a Protocol-Error packet containing an Error-Cause attribute. A proxy that cannot forward the packet MUST respond with either 502 (Request Not Routable (Proxy)) or 505 (Other Proxy Processing Error). This requirement is to help distinguish failures in the proxy chain from failures at the final (i.e., home) server.
RADIUS/1.1サーバーが、アクセスリクエストまたは会計レクエストパケットを処理できないと判断した場合、エラー問題属性を含むプロトコルエラーパケットで応答する必要があります。パケットを転送できないプロキシは、502（リクエストロード可能（プロキシ））または505（その他のプロキシ処理エラー）のいずれかで応答する必要があります。この要件は、プロキシチェーンの障害を最終（つまり、ホーム）サーバーでの障害と区別するのに役立つことです。
For a home server, if none of the Error-Cause values match the reason for the failure, then the value 506 (Resources Unavailable) MUST be used.
ホームサーバーの場合、エラー原因値が障害の理由と一致しない場合、値506（リソースが利用できないリソース）を使用する必要があります。
When a RADIUS proxy receives a Protocol-Error reply, it MUST examine the value of the Error-Cause attribute. If there is no Error-Cause attribute, or if its value is something other than 502 (Request Not Routable (Proxy)), 505 (Other Proxy Processing Error), or 506 (Resources Unavailable), then the proxy MUST return the Protocol-Error response packet to the client and include the Error-Cause attribute from the response it received. This process allows for full "end-to-end" signaling of servers to clients.
RADIUSプロキシがプロトコルエラーの応答を受信した場合、エラー原因属性の値を調べる必要があります。エラー原因属性がない場合、またはその値が502（Request Request Not Routable（Proxy））、505（その他のプロキシ処理エラー）、または506（リソースが利用できない）以外のものである場合、プロキシはプロトコルエラー応答パケットをクライアントに返し、受信した応答からのエラー容疑者の属性を含める必要があります。このプロセスにより、クライアントへのサーバーの完全な「エンドツーエンド」シグナリングが可能になります。
In all situations other than those outlined in the preceding paragraph, a client that receives a Protocol-Error reply MUST reprocess the original outgoing packet through the client forwarding algorithm. This requirement includes both clients that originate RADIUS traffic and proxies that see an Error-Cause attribute of 502 (Request Not Routable (Proxy)) or 505 (Other Proxy Processing Error).
前の段落で概説されている状況以外のすべての状況では、プロトコルエラーの返信を受信するクライアントは、クライアント転送アルゴリズムを介して元の発信パケットを再処理する必要があります。この要件には、半径トラフィックを発信するクライアントと、502のエラー原因属性（リクエストはルーティングできない（プロキシ））または505（その他のプロキシ処理エラー）の両方のクライアントが含まれます。
The expected result of this processing is that the client forwards the packet to a different server. Clients MUST NOT forward the packet over the same connection and SHOULD NOT forward it over a different connection to the same server.
この処理の期待される結果は、クライアントがパケットを別のサーバーに転送することです。クライアントは、同じ接続にパケットを転送してはならず、同じサーバーへの別の接続を介して転送しないでください。
This process may continue over multiple connections and multiple servers, until the client either times out the request or fails to find a forwarding destination for the packet. A proxy that is unable to forward a packet MUST reply with a Protocol-Error packet containing an Error-Cause, as defined above. A client that originates packets MUST treat such a request as if it had received no response.
このプロセスは、クライアントがリクエストを計算するか、パケットの転送先を見つけられないまで、複数の接続と複数のサーバーで継続する場合があります。上記で定義したように、パケットを転送できないプロキシは、エラー原因を含むプロトコルエラーパケットを使用して返信する必要があります。パケットを発信するクライアントは、そのような要求を返信しなかったかのように扱う必要があります。
This behavior is intended to improve the stability of the RADIUS protocol by addressing issues first raised in [RFC3539], Section 2.8.
この動作は、[RFC3539]、セクション2.8で最初に提起された問題に対処することにより、半径プロトコルの安定性を改善することを目的としています。
[RFC6613], Section 2.6.5, and by extension [RFC7360], suggest that the Identifier value zero (0) be reserved for use with Status-Server as an application-layer watchdog. This practice MUST NOT be used for RADIUS/1.1, as the Identifier field is not used in this transport profile.
[RFC6613]、セクション2.6.5、およびさらには[RFC7360]は、識別子値ゼロ（0）がアプリケーション層ウォッチドッグとしてステータスサーバーで使用するために予約されることを示唆しています。識別子フィールドはこの輸送プロファイルでは使用されていないため、このプラクティスは半径/1.1に使用してはなりません。
The rationale for reserving one value of the Identifier field was the limited number of Identifiers available (256) and the overlap in Identifiers between Access-Request packets and Status-Server packets. If all 256 Identifier values had been used to send Access-Request packets, then there would be no Identifier value available for sending a Status-Server packet.
識別子フィールドの1つの値を予約するための理論的根拠は、利用可能な識別子の数が限られていること（256）と、アクセスリケストパケットとステータスサーバーパケットの間の識別子のオーバーラップでした。すべての256の識別子値を使用してAccess-Requestパケットを送信した場合、Status-Serverパケットを送信するために利用可能な識別子値はありません。
In contrast, the Token field allows for 2^32 outstanding packets on one RADIUS/1.1 connection. If there is a need to send a Status-Server packet, it is nearly always possible to allocate a new value for the Token field. If instead there are 2^32 outstanding packets for one connection, then it is likely that something has gone catastrophically wrong. In that case, the safest way forward is likely to just close the connection.
対照的に、トークンフィールドは、1つの半径/1.1接続で2^32の顕著なパケットを可能にします。ステータスサーバーパケットを送信する必要がある場合、トークンフィールドに新しい値を割り当てることがほとんど常に可能です。代わりに、1つの接続に2^32の優れたパケットがある場合、何かが壊滅的に間違っている可能性があります。その場合、最も安全な方法は、接続を閉じるだけである可能性があります。
A RADIUS proxy normally decodes and then re-encodes all attributes, including obfuscated ones. A RADIUS proxy will not generally rewrite the content of the attributes it proxies (unless site-local policy requires such a rewrite). While some attributes may be modified due to administrative or policy rules on the proxy, the proxy will generally not rewrite the contents of attributes such as User-Password, Tunnel-Password, CHAP-Password, MS-CHAP-Password, MS-MPPE keys, etc. Therefore, all attributes are transported through a RADIUS/1.1 connection without changing their values or contents.
半径プロキシは通常、難読化された属性を含むすべての属性をデコードし、再エンコードします。RADIUSプロキシは、一般に、プロキシの属性のコンテンツを書き換えません（サイトローカルポリシーがそのような書き換えを必要としない限り）。プロキシに関する管理またはポリシーの規則によりいくつかの属性が変更される場合がありますが、プロキシは一般に、ユーザーパスワード、トンネルパスワード、トンネルパスワード、MS-Chap-Password、MS-MPPEキーなどの属性の内容を書き換えません。
A proxy may negotiate RADIUS/1.1 (or not) with a particular client or clients, and it may negotiate RADIUS/1.1 (or not) with a server or servers it connects to, in any combination. As a result, this specification is fully compatible with all past, present, and future RADIUS attributes.
プロキシは、特定のクライアントまたはクライアントとRadius/1.1（または無関係）をネゴシエートする場合があり、任意の組み合わせで接続するサーバーまたはサーバーでRADIUS/1.1（またはそうでない）を交渉する場合があります。その結果、この仕様は、過去、現在、および将来のすべての半径属性と完全に互換性があります。
This section discusses issues in RADIUS that need to be addressed in order to support ALPN, but which aren't directly part of the RADIUS/1.1 protocol.
このセクションでは、ALPNをサポートするために対処する必要がある半径の問題について説明しますが、RADIUS/1.1プロトコルの一部ではありません。
The crypto-agility requirements of [RFC6421] are addressed in [RFC6614], Appendix C and in [RFC7360], Section 10.1. This specification makes no changes or additions to those specifications. The use of ALPN and the removal of MD5 has no impact on the security or privacy of the protocol.
[RFC6421]の暗号能力要件は、[RFC6614]、付録Cおよび[RFC7360]、セクション10.1で対処されています。この仕様は、それらの仕様に変更や追加を行いません。ALPNの使用とMD5の除去は、プロトコルのセキュリティまたはプライバシーに影響を与えません。
RADIUS/TLS has been widely deployed in at least eduroam ([RFC7593] and [EDUROAM]) and in OpenRoaming [OPENROAMING]. RADIUS/DTLS has seen less adoption, but it is known to be supported in many RADIUS clients and servers.
半径/TLSは、少なくともeduroam（[rfc7593]および[eduroam]）およびopenroaming [openroaming]で広く展開されています。RADIUS/DTLは採用が少なくなっていますが、多くのRADIUSクライアントとサーバーでサポートされていることが知られています。
It is RECOMMENDED that all implementations of historic RADIUS/TLS be updated to support this specification. Where a system already implements RADIUS over TLS, the additional effort to implement this specification is minimal. Once implementations support it, administrators can gain the benefit of it with little or no configuration changes. This specification is backwards compatible with [RFC6614] and [RFC7360]. It is only potentially subject to down-bidding attacks if implementations do not enforce ALPN correctly on session resumption.
この仕様をサポートするために、歴史的半径/TLのすべての実装を更新することをお勧めします。システムがすでにTLSよりも半径を実装している場合、この仕様を実装するための追加の努力は最小限です。実装がサポートされると、管理者は構成変更がほとんどまたはまったく変更されずに利益を得ることができます。この仕様は、[RFC6614]および[RFC7360]と逆方向に互換性があります。実装がセッション再開時にALPNを正しく強制しない場合にのみ、下向きの攻撃を受ける可能性があります。
All crypto-agility needed or used by this specification is implemented in TLS. This specification also removes all cryptographic primitives from the application-layer protocol (RADIUS) being transported by TLS. As discussed in the following section, this specification also bans the development of all new cryptographic or crypto-agility methods in the RADIUS protocol.
この仕様で必要または使用されるすべての暗号特性は、TLSに実装されています。この仕様は、TLSによって輸送されるアプリケーション層プロトコル（RADIUS）からすべての暗号化プリミティブを削除します。次のセクションで説明したように、この仕様では、RADIUSプロトコルのすべての新しい暗号化能力メソッドの開発も禁止されています。
The Error-Cause attribute is defined in [RFC5176]. The "Table of Attributes" section given in [RFC5176], Section 3.6 permits that attribute to appear in CoA-NAK and Disconnect-NAK packets. As no other packet type is listed, the implication is that the Error-Cause attribute cannot appear in any other packet. [RFC7930] also permits Error-Cause to appear in Protocol-Error packets.
エラー（rfc5176]で定義されています。[RFC5176]に記載されている「属性の表」セクション、セクション3.6は、COA-NAKに属性を使用してNAKパケットを切断することを許可します。他のパケットタイプがリストされていないように、その意味は、他のパケットにエラー原因属性が表示されないということです。[RFC7930]は、プロトコルエラーパケットにError-Causeが表示されることも許可しています。
However, [RFC5080], Section 2.6.1 suggests that Error-Cause may appear in Access-Reject packets. No explanation is given for this change from [RFC5176]. There is not even an acknowledgment that this suggestion is a change from any previous specification. We correct that issue here.
ただし、[RFC5080]、セクション2.6.1は、Access-Rejectパケットにエラー原因が表示される可能性があることを示唆しています。[RFC5176]からのこの変更については、説明はありません。この提案は以前の仕様からの変更であるという認識すらありません。ここでその問題を修正します。
This specification updates [RFC5176] to allow the Error-Cause attribute to appear in Access-Reject packets. It is RECOMMENDED that implementations include the Error-Cause attribute in Access-Reject packets where appropriate.
この仕様は、[RFC5176]を更新して、エラー原因属性がアクセス - リジェクトパケットに表示されるようにします。実装には、必要に応じてAccess-Rejectパケットのエラー原因属性を含めることをお勧めします。
That is, the reason for sending the Access-Reject packet (or the Protocol-Error packet) may match a defined Error-Cause value. In that case, it is useful for implementations to send an Error-Cause attribute with that value. This behavior can help RADIUS system administrators debug issues in complex proxy chains.
つまり、Access-rejectパケット（またはプロトコルエラーパケット）を送信する理由は、定義されたエラー原因値と一致する場合があります。その場合、実装がその値でエラー原因属性を送信するのに役立ちます。この動作は、RADIUSシステム管理者が複雑なプロキシチェーンで問題をデバッグするのに役立ちます。
For example, a proxy may normally forward Access-Request packets that contain EAP-Message attributes. The proxy can determine if the contents of the EAP-Message are invalid. One example of an invalid EAP-Message is where the first octet has value larger than 4. In that case, there may be no benefit to forwarding the packet, as the home server will reject it. It may then be possible for the proxy (with the knowledge and consent of involved parties) to immediately reply with an Access-Reject containing an Error-Cause attribute with value 202 (Invalid EAP Packet (Ignored)).
たとえば、プロキシは通常、EAPメッセージ属性を含むアクセスリケストパケットを転送する場合があります。プロキシは、EAPメッセージの内容が無効であるかどうかを判断できます。無効なEAPメッセージの1つの例は、最初のオクテットの値が4を超える場所です。その場合、ホームサーバーが拒否するため、パケットを転送することに利点がない場合があります。その場合、値202（無効なEAPパケット（無視））のエラー原因属性を含むアクセス - reject（無視））を含むアクセス - 抵抗をすぐに返信することが可能になる場合があります。
Another possibility is that a proxy is configured to forward packets for a particular realm, but it has determined that there are no available connections to the next hop for that realm. In that case, it may be possible for the proxy (again, with the knowledge and consent of involved parties) to reply with an Access-Reject containing an Error-Cause attribute with value 502 (Request Not Routable (Proxy)).
別の可能性は、プロキシが特定の領域のパケットを転送するように構成されていることですが、その領域の次のホップに利用可能な接続がないことが判明しました。その場合、Proxy（再び、関係者の知識と同意を得て）が、値502のエラー原因属性を含むAccess-reject（Request Not Routable（Proxy））で返信することが可能かもしれません。
These examples are given only for illustrative and informational purposes. While it is useful to return an informative value for the Error-Cause attribute, proxies can only modify the traffic they forward with the explicit knowledge and consent of all involved parties.
これらの例は、実例と情報の目的のみを目的としています。エラー原因属性の有益な値を返すことは有用ですが、プロキシは、関係者全員の明示的な知識と同意を得て、彼らが転送するトラフィックを変更することのみができます。
Future work may define new attributes, packet types, etc. It is important to be able to do such work without requiring that every new standard mention RADIUS/1.1 explicitly. This document defines RADIUS/1.1 as having functional overlap with legacy RADIUS: the protocol state machine is unchanged, the packet header Code field is unchanged, and the attribute format is largely unchanged. As a result, any new packet Code or attribute defined for RADIUS is explicitly compatible with RADIUS/1.1; the field contents and meanings are identical. The only difference between the two protocols is that obfuscated attributes in RADIUS are not obfuscated in RADIUS/1.1, and this document defines how that mapping is done.
将来の作業では、新しい属性、パケットタイプなどを定義する場合があります。すべての新しい標準がRADIUS/1.1を明示的に言及することを要求することなく、そのような作業を行うことが重要です。このドキュメントでは、RADIUS/1.1がレガシー半径と機能的なオーバーラップを持っていると定義しています。プロトコル状態マシンは変更されておらず、パケットヘッダーコードフィールドは変更されておらず、属性形式はほとんど変化していません。その結果、RADIUSに対して定義された新しいパケットコードまたは属性は、RADIUS/1.1と明示的に互換性があります。フィールドの内容と意味は同一です。2つのプロトコルの唯一の違いは、半径中の難読化された属性が半径/1.1で難読化されていないことです。このドキュメントは、そのマッピングの実行方法を定義しています。
Any future specification only needs to mention RADIUS/1.1 if it adds fields to the RADIUS/1.1 packet header. Otherwise, transport considerations for RADIUS/1.1 are identical to RADIUS over (D)TLS.
将来の仕様は、RADIUS/1.1パケットヘッダーにフィールドを追加する場合にのみRADIUS/1.1に言及する必要があります。それ以外の場合、半径/1.1の輸送に関する考慮事項は、（d）TLSの半径と同一です。
We reiterate that this specification defines a new transport profile for RADIUS. It does not define a completely new protocol. Any future specification that defines a new attribute MUST define it for RADIUS/UDP first, and afterwards those definitions can be applied to this transport profile.
この仕様では、半径の新しい輸送プロファイルを定義することを繰り返します。まったく新しいプロトコルを定義しません。新しい属性を定義する将来の仕様は、最初に半径/UDPに対してそれを定義する必要があり、その後、これらの定義をこの輸送プロファイルに適用できます。
New specifications MAY define new attributes that use the obfuscation methods for User-Password as defined in [RFC2865], Section 5.2 or for Tunnel-Password as defined in [RFC2868], Section 3.5. There is no need for those specifications to describe how those new attributes are transported in RADIUS/1.1. Since RADIUS/1.1 does not use MD5, any obfuscated attributes will by definition be transported as their underlying data type "text" ([RFC8044], Section 3.4) or "string" ([RFC8044], Section 3.5).
新しい仕様は、[RFC2865]、セクション5.2、または[RFC2868]で定義されているトンネルパスワードで定義されているユーザーパスワードの難読化方法を使用する新しい属性を定義する場合があります。これらの仕様は、これらの新しい属性が半径/1.1でどのように輸送されるかを説明する必要はありません。半径/1.1はMD5を使用しないため、難読化された属性は、定義上、基礎となるデータ型「テキスト」（[RFC8044]、セクション3.4）または「文字列」（[RFC8044]、セクション3.5）として輸送されます。
New RADIUS specifications MUST NOT define attributes that can only be transported via RADIUS over TLS. The RADIUS protocol has no way to signal the security requirements of individual attributes. Any existing implementation will handle these new attributes as "invalid attributes" ([RFC6929], Section 2.8) and could forward them over an insecure link. As RADIUS security and signaling is hop-by-hop, there is no way for a RADIUS client or server to even know if such forwarding is taking place. For these reasons and more, it is therefore inappropriate to define new attributes that are only secure if they use a secure transport layer.
新しいRADIUS仕様は、TLSを超える半径のみを介して輸送できる属性を定義してはなりません。RADIUSプロトコルには、個々の属性のセキュリティ要件を通知する方法はありません。既存の実装では、これらの新しい属性を「無効な属性」（[RFC6929]、セクション2.8）として処理し、安全でないリンクに転送できます。RADIUSセキュリティとシグナリングはホップバイホップであるため、RADIUSクライアントまたはサーバーがそのような転送が行われているかどうかさえ知る方法はありません。したがって、これらの理由などのために、安全な輸送層を使用する場合にのみ安全な新しい属性を定義することは不適切です。
The result is that specifications do not need to mention this transport profile or make any special provisions for dealing with it. This specification defines how RADIUS packet encoding, decoding, authentication, and verification are performed when using RADIUS/1.1. So long as any future specification uses the existing schemes for encoding, decoding, etc., that are defined for RADIUS, no additional text in future documents is necessary in order to be compatible with RADIUS/1.1.
その結果、仕様はこの輸送プロファイルに言及したり、それに対処するための特別な規定を作成する必要はありません。この仕様では、半径のエンコード、デコード、認証、および検証がRADIUS/1.1を使用するときにどのように実行されるかを定義します。将来の仕様が半径に対して定義されているエンコード、デコードなどに既存のスキームを使用している限り、RADIUS/1.1と互換性があるために将来のドキュメントの追加テキストは必要ありません。
We note that it is theoretically possible for future standards to define new cryptographic primitives for use with RADIUS/UDP. In that case, those documents would likely have to describe how to transport that data in RADIUS/1.1. We believe that such standards are unlikely to be published, as other efforts in the RADEXT Working Group are forbidding such updates to RADIUS.
将来の基準が半径/UDPで使用する新しい暗号化プリミティブを定義することは理論的には可能であることに注意してください。その場合、これらのドキュメントは、そのデータをRADIUS/1.1で輸送する方法を説明する必要がある可能性があります。Radextワーキンググループでの他の取り組みがRADIUSへの更新を禁止しているため、このような基準が公開される可能性は低いと考えています。
This specification requires secure transport for RADIUS. RADIUS/1.1 has all of the privacy benefits of RADIUS/TLS [RFC6614] and RADIUS/ DTLS [RFC7360] and none of the privacy or security issues of RADIUS/ UDP [RFC2865] or RADIUS/TCP [RFC6613].
この仕様には、半径の安全な輸送が必要です。RADIUS/1.1には、半径/TLS [RFC6614]および半径/DTLS [RFC7360]のすべてのプライバシー利点があり、半径/UDP [RFC2865]または半径/TCP [RFC6613]のプライバシーまたはセキュリティの問題はありません。
The primary focus of this document is addressing security considerations for RADIUS. This specification relies on TLS and associated ALPN for much of its security. We refer the reader to [RFC8446] and [RFC7360] for discussions of the security of those protocols. The discussion in this section is limited to issues unique to this specification.
このドキュメントの主な焦点は、半径のセキュリティ上の考慮事項に対処することです。この仕様は、そのセキュリティの多くに対してTLSと関連するALPNに依存しています。これらのプロトコルのセキュリティの議論については、読者を[RFC8446]および[RFC7360]に紹介します。このセクションの議論は、この仕様に固有の問題に限定されています。
Implementations should rely on the underlying TLS library to perform ALPN version negotiation. That is, implementations should supply a list of permitted ALPN strings to the TLS library, and let it return the negotiated value.
実装は、基礎となるTLSライブラリに依存して、ALPNバージョンのネゴシエーションを実行する必要があります。つまり、実装は、許可されたALPN文字列のリストをTLSライブラリに提供し、交渉値を返すようにする必要があります。
There are few other opportunities for security issues. If an implementation gets ALPN wrong, then the wrong application data will be transported inside of TLS. While RADIUS/1.0 and RADIUS/1.1 share similar packet formats, the protocols are not mutually compatible.
セキュリティ問題の他の機会はほとんどありません。実装がALPNが間違っている場合、間違ったアプリケーションデータがTLS内で輸送されます。RADIUS/1.0およびRADIUS/1.1は同様のパケット形式を共有していますが、プロトコルは相互に互換性がありません。
When an implementation receives the packets for a RADIUS version that is not supported by this connection, it will not be able to process the packets. Implementations can produce log messages indicating that the application-layer data is unexpected and close the connection. In addition, the implementations that see the incorrect application data already have full access to all secrets, passwords, etc. being transported, so any protocol differences do not result in any security issues. Since all of the application data is protected by TLS, there is no possibility for an attacker to obtain any extra data as a result of this misconfiguration.
実装がこの接続でサポートされていないRADIUSバージョンのパケットを受信すると、パケットを処理できません。実装は、アプリケーション層データが予期しないことを示すログメッセージを生成し、接続を閉じることができます。さらに、誤ったアプリケーションデータを確認する実装は、すべての秘密、パスワードなどに完全にアクセスできるように輸送されているため、プロトコルの違いはセキュリティの問題になりません。すべてのアプリケーションデータはTLSによって保護されているため、攻撃者がこの誤解の結果として追加のデータを取得する可能性はありません。
RADIUS/1.0 requests sent over a RADIUS/1.1 connection may be accepted by the RADIUS/1.1 server, as the server will ignore the ID field and try to use portions of the Request Authenticator as a Token. However, the reply from the RADIUS/1.1 server will fail the Response Authenticator validation by the RADIUS/1.0 client. Therefore, the responses will be dropped. The client will generally log these failures, and an administrator will address the issue.
RADIUS/1.0リクエストは、RADIUS/1.1接続を介して送信されたRADIUS/1.1サーバーによって受け入れられる場合があります。サーバーはIDフィールドを無視し、リクエスト認証器の部分をトークンとして使用しようとします。ただし、RADIUS/1.1サーバーからの返信は、RADIUS/1.0クライアントによる応答認証検証に失敗します。したがって、応答は削除されます。クライアントは通常、これらの障害を記録し、管理者は問題に対処します。
RADIUS/1.1 requests sent over a RADIUS/1.0 connection will generally be discarded by the RADIUS/1.0 server, as the packets will fail the Request Authenticator checks. That is, all request packets such as Accounting-Request, CoA-Request, and Disconnect-Request will be discarded by the server. For Access-Request packets containing EAP-Message, the packets will be missing Message-Authenticator and will therefore be discarded by the server. Other Access-Request packets that contain obfuscated attributes such as User-Password will have those attributes decoded to nonsense, thus resulting in Access-Reject responses.
Radius/1.0接続を介して送信されたRADIUS/1.1要求は、通常、RADIUS/1.0サーバーによって破棄されます。つまり、Accounting-Request、CoA-Request、切断リケストなどのすべての要求パケットは、サーバーによって破棄されます。EAPメッセージを含むAccess-Requestパケットの場合、パケットにメッセージAuthenticatorが欠落しているため、サーバーによって破棄されます。ユーザーパスワードなどの難読化された属性を含む他のアクセスリクエストパケットは、それらの属性がナンセンスにデコードされるため、アクセス拒否応答をもたらします。
RADIUS/1.1 Access-Request packets containing non-obfuscated attributes such as CHAP-Password may be accepted by a RADIUS/1.0 server, but the response will contain a Response Authenticator (i.e., MD5 hash) and not a Token that matches the Token in the request. A similar analysis applies for Access-Request packets containing Service-Type = Authorize-Only.
RADIUS/1.1 Access-Requestパケットは、Chap-Passwordなどの非肥大化属性を含むPARTIUS/1.0サーバーによって受け入れられる場合がありますが、応答には、リクエストのトークンと一致するトークンではなく、応答認証器（つまり、MD5ハッシュ）が含まれます。同様の分析は、Service-Type = Authorizeのみを含むアクセスリクエストパケットに適用されます。
In conclusion, any mismatch of versions between client and server will result in most request packets being discarded by the server and all response packets being discarded by the client. Therefore, the two protocols are incompatible and safe from misconfigurations or erroneous implementations.
結論として、クライアントとサーバー間のバージョンの不一致は、ほとんどのリクエストパケットがサーバーによって破棄され、クライアントによってすべての応答パケットが破棄されます。したがって、2つのプロトコルは、誤った採掘または誤った実装から互換性がなく安全です。
IANA has updated the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry with two new entries:
IANAは、「TLSアプリケーションレイヤープロトコルネゴシエーション（ALPN）プロトコルIDS」レジストリを2つの新しいエントリで更新しました。
Protocol:
プロトコル：
RADIUS/1.0
半径/1.0
Identification Sequence:
識別シーケンス：
0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x30 ("radius/1.0")
0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x30（ "radius/1.0"）
Reference:
参照：
RFC 9765
RFC 9765
Protocol:
プロトコル：
RADIUS/1.1
半径/1.1
Identification Sequence:
識別シーケンス：
0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x31 ("radius/1.1")
0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x31（ "radius/1.1"）
Reference:
参照：
RFC 9765
RFC 9765
[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>.
[RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote
Authentication Dial-In User Service (RADIUS)", RFC 6421,
DOI 10.17487/RFC6421, November 2011,
<https://www.rfc-editor.org/info/rfc6421>.
[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>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
DOI 10.17487/RFC6929, April 2013,
<https://www.rfc-editor.org/info/rfc6929>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[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>.
[RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044,
DOI 10.17487/RFC8044, January 2017,
<https://www.rfc-editor.org/info/rfc8044>.
[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>.
[ASLEAP] "asleap - recovers weak LEAP and PPTP passwords", commit
254acab, November 2020,
<https://github.com/joswr1ght/asleap>.
[DEPRECATE-RADIUS]
DeKok, A., "Deprecating Insecure Practices in RADIUS",
Work in Progress, Internet-Draft, draft-ietf-radext-
deprecating-radius-05, 26 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
deprecating-radius-05>.
[EDUROAM] eduroam, "eduroam", <https://eduroam.org>.
[FIPS-140-3]
NIST, "Security Requirements for Cryptographic Modules",
NIST FIPS 140-3, DOI 10.6028/NIST.FIPS.140-3, March 2019,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.140-3.pdf>.
[OPENROAMING]
Wireless Broadband Alliance, "OpenRoaming: One global Wi-
Fi network", <https://wballiance.com/openroaming/>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, DOI 10.17487/RFC2548, March 1999,
<https://www.rfc-editor.org/info/rfc2548>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000,
<https://www.rfc-editor.org/info/rfc2866>.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, DOI 10.17487/RFC2868, June 2000,
<https://www.rfc-editor.org/info/rfc2868>.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539,
DOI 10.17487/RFC3539, June 2003,
<https://www.rfc-editor.org/info/rfc3539>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579,
DOI 10.17487/RFC3579, September 2003,
<https://www.rfc-editor.org/info/rfc3579>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December
2007, <https://www.rfc-editor.org/info/rfc5080>.
[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,
DOI 10.17487/RFC5176, January 2008,
<https://www.rfc-editor.org/info/rfc5176>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
DOI 10.17487/RFC5281, August 2008,
<https://www.rfc-editor.org/info/rfc5281>.
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication
Protocol (EAP) Authentication Using Only a Password",
RFC 5931, DOI 10.17487/RFC5931, August 2010,
<https://www.rfc-editor.org/info/rfc5931>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC6218] Zorn, G., Zhang, T., Walker, J., and J. Salowey, "Cisco
Vendor-Specific RADIUS Attributes for the Delivery of
Keying Material", RFC 6218, DOI 10.17487/RFC6218, April
2011, <https://www.rfc-editor.org/info/rfc6218>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613,
DOI 10.17487/RFC6613, May 2012,
<https://www.rfc-editor.org/info/rfc6613>.
[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>.
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Architecture for Network Roaming", RFC 7593,
DOI 10.17487/RFC7593, September 2015,
<https://www.rfc-editor.org/info/rfc7593>.
[RFC7930] Hartman, S., "Larger Packets for RADIUS over TCP",
RFC 7930, DOI 10.17487/RFC7930, August 2016,
<https://www.rfc-editor.org/info/rfc7930>.
[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>.
Thanks to Bernard Aboba, Karri Huhtanen, Heikki Vatiainen, Alexander Clouter, Michael Richardson, Hannes Tschofenig, Matthew Newton, and Josh Howlett for reviews and feedback.
バーナード・アボバ、カリ・フータネン、ヘイキ・ヴァティアイネン、アレクサンダー・クローター、マイケル・リチャードソン、ハンネス・ツェフェニグ、マシュー・ニュートン、ジョシュ・ハウレットのレビューとフィードバックに感謝します。
Alan DeKok
FreeRADIUS
Email: aland@freeradius.org