[要約] RFC 3579は、RADIUS（Remote Authentication Dial In User Service）を使用してEAP（Extensible Authentication Protocol）をサポートするための仕様です。このRFCの目的は、ネットワーク上のユーザーの認証と認可を強化するために、EAPをRADIUSと統合することです。
Network Working Group B. Aboba
Request for Comments: 3579 Microsoft
Updates: 2869 P. Calhoun
Category: Informational Airespace
September 2003
RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)
RADIUS（リモート認証ダイヤルインユーザサービス）拡張認証プロトコル（EAP）のサポート
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティに関する情報を提供します。インターネット規格はあらゆる種類の標準を指定していません。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット社会（2003）。全著作権所有。
Abstract
概要
This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method-specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802.
この文書は、複数の認証メカニズムをサポートする認証フレームワークであるExtensible Authentication Protocol（EAP）のリモート認証ダイヤル（RADIUS）サポートを定義しています。提案された方式では、ネットワークアクセスサーバ（NAS）は、EAP - メッセージ属性内にカプセル化されたRADIUSサーバとの間でEAPパケットを転送する。これには、RADIUSサーバ上にある方法固有のコードを必要とせずに、NASがEAP認証方法をサポートできるという利点があります。EAPが元々PPPで使用するために開発されている間、IEEE 802でも使用中です。
This document updates RFC 2869.
この文書はRFC 2869を更新します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. RADIUS Support for EAP . . . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Overview. . . . . . . . . . . . . . . . . . . . 5
2.2. Invalid Packets. . . . . . . . . . . . . . . . . . . . . 9
2.3. Retransmission . . . . . . . . . . . . . . . . . . . . . 10
2.4. Fragmentation. . . . . . . . . . . . . . . . . . . . . . 10
2.5. Alternative uses . . . . . . . . . . . . . . . . . . . . 11
2.6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . 11
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Message-Authenticator. . . . . . . . . . . . . . . . . . 16
3.3. Table of Attributes. . . . . . . . . . . . . . . . . . . 18
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
4.1. Security Requirements. . . . . . . . . . . . . . . . . . 19
4.2. Security Protocol. . . . . . . . . . . . . . . . . . . . 20
4.3. Security Issues. . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 30
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1. Normative References . . . . . . . . . . . . . . . . . . 30
6.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A - Examples. . . . . . . . . . . . . . . . . . . . . . . 34
Appendix B - Change Log. . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property Statement. . . . . . . . . . . . . . . . . . 44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 46
The Remote Authentication Dial In User Service (RADIUS) is an authentication, authorization and accounting protocol used to control network access. RADIUS authentication and authorization is specified in [RFC2865], and RADIUS accounting is specified in [RFC2866]; RADIUS over IPv6 is specified in [RFC3162].
ユーザーサービス（RADIUS）のリモート認証ダイヤルは、ネットワークアクセスを制御するために使用される認証、許可および会計プロトコルです。[RFC2865]にRADIUS認証と許可が指定され、RADIUSアカウンティングが[RFC2866]に指定されています。[RFC3162]では、IPv6の半径が指定されています。
The Extensible Authentication Protocol (EAP), defined in [RFC2284], is an authentication framework which supports multiple authentication mechanisms. EAP may be used on dedicated links, switched circuits, and wired as well as wireless links.
[RFC2284]で定義されている拡張認証プロトコル（EAP）は、複数の認証メカニズムをサポートする認証フレームワークです。EAPは、専用のリンク、スイッチディング回路、および有線、および無線リンクで使用できます。
To date, EAP has been implemented with hosts and routers that connect via switched circuits or dial-up lines using PPP [RFC1661]. It has also been implemented with bridges supporting [IEEE802]. EAP encapsulation on IEEE 802 wired media is described in [IEEE8021X].
これまでに、EAPは、PPP [RFC1661]を使用して、スイッチ付き回線またはダイヤルアップラインを介して接続するホストとルータで実装されています。また、Bridgesをサポートしている[IEEE802]を使用して実装されています。IEEE 802有線メディア上のEAPカプセル化は[IEEE8021X]に記載されています。
RADIUS attributes are comprised of variable length Type-Length-Value 3-tuples. New attribute values can be added without disturbing existing implementations of the protocol. This specification describes RADIUS attributes supporting the Extensible Authentication Protocol (EAP): EAP-Message and Message-Authenticator. These attributes now have extensive field experience. The purpose of this document is to provide clarification and resolve interoperability issues.
RADIUS属性は、可変長タイプ長値3タプルで構成されています。プロトコルの既存の実装を妨げることなく、新しい属性値を追加できます。この仕様では、拡張認証プロトコル（EAP）をサポートするRADIUS属性（EAP-MESSAGE）とメッセージオーセンティケータが記述されています。これらの属性には、豊富なフィールドエクスペリエンスがあります。この文書の目的は、明確化と相互運用性の問題を解決することです。
As noted in [RFC2865], a Network Access Server (NAS) that does not implement a given service MUST NOT implement the RADIUS attributes for that service. This implies that a NAS that is unable to offer EAP service MUST NOT implement the RADIUS attributes for EAP. A NAS MUST treat a RADIUS Access-Accept requesting an unavailable service as an Access-Reject instead.
[RFC2865]に記載されているように、特定のサービスを実装していないネットワークアクセスサーバー（NAS）は、そのサービスのRADIUS属性を実装してはなりません。これは、EAPサービスを提供できないNASがEAPのRADIUS属性を実装してはいけません。NASは、使用不可のサービスをアクセス拒否として要求するRADIUSアクセスを扱う必要があります。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書では、仕様の要件を表すためにいくつかの単語が使用されています。これらの言葉は多くのことがよくあります。「必須」、「必須」、「必要ではない」、「しない」、「推奨する」、「推奨する」、「5月」、および「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、[RFC2119]に記載されているように解釈されること。
This document frequently uses the following terms:
この文書は頻繁に以下の条件を使用します。
authenticator The end of the link requiring the authentication. Also known as the Network Access Server (NAS) or RADIUS client. Within IEEE 802.1X terminology, the term Authenticator is used.
認証者認証を必要とするリンクの終わり。ネットワークアクセスサーバ（NAS）またはRADIUSクライアントとも呼ばれます。IEEE 802.1Xの用語では、「オーセンティケータ」という用語が使用されます。
peer The other end of the point-to-point link (PPP), point-to-point LAN segment (IEEE 802.1X) or wireless link, which is being authenticated by the authenticator. In IEEE 802.1X, this end is known as the Supplicant.
Point-to-Point Link（PPP）、ポイントツーポイントLANセグメント（IEEE 802.1X）またはAuthenticatorによって認証されている無線リンクのもう一方の端。IEEE 802.1Xでは、この目的はサプリカントとして知られています。
authentication server An authentication server is an entity that provides an authentication service to an authenticator (NAS). This service verifies from the credentials provided by the peer, the claim of identity made by the peer; it also may provide credentials allowing the peer to verify the identity of the authentication server. Within this document it is assumed that the NAS operates as a pass-through, forwarding EAP packets between the RADIUS server and the EAP peer.
認証サーバー認証サーバーは、認証サービス（NAS）に認証サービスを提供するエンティティです。このサービスは、ピアによって提供される認証情報、ピアによって行われた身元の主張から検証されます。また、同輩が認証サーバーのIDを検証できるようにする認証情報を提供することもできます。この文書内では、NASがパススルーとして動作し、RADIUSサーバとEAPピア間のEAPパケットを転送すると仮定する。
Therefore the RADIUS server operates as an authentication server.
したがって、RADIUSサーバは認証サーバとして動作します。
silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
これを静かに破棄すると、実装はそれ以上の処理なしにパケットを破棄します。実装は、静止して破棄されたパケットの内容を含め、エラーをログ記録する機能を提供する必要があります。統計カウンタでイベントを記録する必要があります。
displayable message This is interpreted to be a human readable string of characters, and MUST NOT affect operation of the protocol. The message encoding MUST follow the UTF-8 transformation format [RFC2279].
表示可能メッセージこれは、人間の読みやすい文字列であると解釈され、プロトコルの動作に影響を与えてはなりません。メッセージエンコードはUTF-8変換フォーマット[RFC2279]に従わなければなりません。
Network Access Server (NAS) The device providing access to the network. Also known as the Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client.
ネットワークアクセスサーバー（NAS）ネットワークへのアクセスを提供するデバイス。オーセンティケータ（IEEE 802.1XまたはEAPの用語）またはRADIUSクライアントとしても知られています。
service The NAS provides a service to the user, such as IEEE 802 or PPP.
サービスNASは、IEEE 802またはPPPなどのユーザーにサービスを提供します。
session Each service provided by the NAS to a peer constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended. A peer may have multiple sessions in parallel or series if the NAS supports that, with each session generating a separate start and stop accounting record.
セッションNASからピアが提供する各サービスはセッションを構成し、セッションの開始は、サービスが最初に提供され、サービスが終了したポイントとして定義されたセッションの終わりが定義されています。NASがそれをサポートしている場合、ピアは複数のセッションを並列またはシリーズにし、各セッションは別々の開始および停止アカウンティングレコードを生成します。
The Extensible Authentication Protocol (EAP), described in [RFC2284], provides a standard mechanism for support of additional authentication methods without the NAS to be upgraded to support each new method. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos [RFC1510], Public Key [RFC2716], One Time Passwords [RFC2284], and others.
[RFC2284]で説明されている拡張認証プロトコル（EAP）は、新しいメソッドをサポートするためにアップグレードされるNASを使用せずに追加の認証方法をサポートするための標準メカニズムを提供します。EAPを使用することで、スマートカード、Kerberos [RFC1510]、公開鍵[RFC2716]、1回のパスワード[RFC2284]など、多数の認証方式のサポートを追加することができます。
One of the advantages of the EAP architecture is its flexibility. EAP is used to select a specific authentication mechanism. Rather than requiring the NAS to be updated to support each new authentication method, EAP permits the use of an authentication server implementing authentication methods, with the NAS acting as a pass-through for some or all methods and peers.
EAPアーキテクチャの利点の1つはその柔軟性です。EAPは特定の認証メカニズムを選択するために使用されます。NASを新しい認証方法ごとにサポートするように更新するのではなく、EAPは認証方法を実装する認証サーバの使用を許可し、NASは一部のメソッドおよびピアのパススルーとして実行されます。
A NAS MAY authenticate local peers while at the same time acting as a pass-through for non-local peers and authentication methods it does not implement locally. A NAS implementing this specification is not required to use RADIUS to authenticate every peer. However, once the NAS begins acting as a pass-through for a particular session, it can no longer perform local authentication for that session.
NASはローカルピアを認証し、同時にローカルピア以外のピアおよび認証方法として実行されるのと同時に、ローカルに実装されていない。この仕様を実装するNASは、半径を使用して各ピアを認証する必要はありません。ただし、NASが特定のセッションのパススルーとして機能すると、そのセッションのローカル認証を実行できなくなります。
In order to support EAP within RADIUS, two new attributes, EAP-Message and Message-Authenticator, are introduced in this document. This section describes how these new attributes may be used for providing EAP support within RADIUS.
RADIUS内のEAPをサポートするために、このドキュメントでは2つの新しい属性、EAP-MESSAGE、およびメッセージオーセンティケータが導入されています。このセクションでは、RADIUS内でEAPサポートを提供するためにこれらの新しい属性を使用できる方法について説明します。
In RADIUS/EAP, RADIUS is used to shuttle RADIUS-encapsulated EAP Packets between the NAS and an authentication server.
RADIUS / EAPでは、NASと認証サーバ間のRADIUSカプセル化EAPパケットをシャトルバスするためにRADIUSが使用されます。
The authenticating peer and the NAS begin the EAP conversation by negotiating use of EAP. Once EAP has been negotiated, the NAS SHOULD send an initial EAP-Request message to the authenticating peer. This will typically be an EAP-Request/Identity, although it could be an EAP-Request for an authentication method (Types 4 and greater). A NAS MAY be configured to initiate with a default authentication method. This is useful in cases where the identity is determined by another means (such as Called-Station-Id, Calling-Station-Id and/or Originating-Line-Info); where a single authentication method is required, which includes its own identity exchange; where identity hiding is desired, so that the identity is not requested until after a protected channel has been set up.
認証ピアとNASはEAPの使用を交渉することによってEAP会話を開始します。EAPがネゴシエートされると、NASは認証ピアに初期のEAP要求メッセージを送信する必要があります。これは通常EAP-REQUEST / IDになりますが、認証方法（タイプ4以上）のEAP-REQUESTです。NASは、デフォルトの認証方法で開始するように構成されてもよい。これは、アイデンティティが別の手段（呼び出し局ID、呼び出し局 - IDおよび/または発信元情報）によって決定される場合に役立ちます。単一の認証方法が必要な場合は、独自のID Exchangeを含みます。アイデンティティ隠蔽が望まれる場合、保護されたチャネルが設定された後まで識別が要求されない。
The peer replies with an EAP-Response. The NAS MAY determine from the Response that it should proceed with local authentication. Alternatively, the NAS MAY act as a pass-through, encapsulating the EAP-Response within EAP-Message attribute(s) sent to the RADIUS server within a RADIUS Access-Request packet. If the NAS sends an EAP-Request/Identity message as the initial packet, the peer responds with an EAP-Response/Identity. The NAS may determine that the peer is local and proceed with local authentication. If no match is found against the list of local users, the NAS encapsulates the EAP-Response/Identity message within an EAP-Message attribute, enclosed within an Access-Request packet.
ピアはEAP応答で返信します。NASは、それがローカル認証を進めるべき応答から決定することができる。あるいは、NASは、RADIUSアクセス要求パケット内でRADIUSサーバ内で送信されたEAP - メッセージ属性内でEAP応答を通過するパススルーとして機能してもよい。NASが初期パケットとしてEAP要求/ IDメッセージを送信した場合、ピアはEAP応答/ IDで応答します。NASは、ピアがローカルであると判断し、ローカル認証を進めることができます。ローカルユーザのリストに対して一致が見つからない場合、NASは、アクセス要求パケット内で囲まれたEAP - メッセージ属性内のEAP対応/識別メッセージをカプセル化する。
On receiving a valid Access-Request packet containing EAP-Message attribute(s), a RADIUS server compliant with this specification and wishing to authenticate with EAP MUST respond with an Access-Challenge packet containing EAP-Message attribute(s). If the RADIUS server does not support EAP or does not wish to authenticate with EAP, it MUST respond with an Access-Reject.
EAP-MESSAGE属性を含む有効なアクセス要求パケットを受信すると、この仕様に準拠し、EAPでの認証を希望するRADIUSサーバーは、EAP-MESSAGE属性を含むアクセスチャレンジパケットで応答する必要があります。RADIUSサーバがEAPをサポートしていないか、EAPで認証したくない場合は、Access-Rejectで応答する必要があります。
EAP-Message attribute(s) encapsulate a single EAP packet which the NAS decapsulates and passes on to the authenticating peer. The peer then responds with an EAP-Response packet, which the NAS encapsulates within an Access-Request containing EAP-Message attribute(s). EAP is a 'lock step' protocol, so that other than the initial Request, a new Request cannot be sent prior to receiving a valid Response.
EAP-Message属性（S）NASがカプセル化して認証ピアに渡す単一のEAPパケットをカプセル化します。ピアはEAP-Responseパケットで応答します。これは、NASがEAP-Message属性を含むアクセス要求内にカプセル化する。EAPは「ロックステップ」プロトコルであるため、最初の要求以外に、有効な応答を受信する前に新しい要求を送信できません。
The conversation continues until either a RADIUS Access-Reject or Access-Accept packet is received from the RADIUS server. Reception of a RADIUS Access-Reject packet MUST result in the NAS denying access to the authenticating peer. A RADIUS Access-Accept packet successfully ends the authentication phase. The NAS MUST NOT "manufacture" a Success or Failure packet as the result of a timeout. After a suitable number of timeouts have elapsed, the NAS SHOULD instead end the EAP conversation.
RADIUSサーバからRADIUSアクセスリジェクトまたはアクセス許可パケットが受信されるまで会話は続行されます。RADIUSアクセスリジェクトパケットの受信は、認証ピアへのアクセスを拒否するNASをもたらす必要があります。RADIUS Access-Acceptパケットは認証フェーズを正常に終了します。NASは、タイムアウトの結果として成功または失敗パケットを「製造」してはいけません。適切な数のタイムアウトが経過した後、NASは代わりにEAP会話を終了する必要があります。
Using RADIUS, the NAS can act as a pass-through for an EAP conversation between the peer and authentication server, without needing to implement the EAP method used between them. Where the NAS initiates the conversation by sending an EAP-Request for an authentication method, it may not be required that the NAS fully implement the EAP method reflected in the initial EAP-Request. Depending on the initial method, it may be sufficient for the NAS to be configured with the initial packet to be sent to the peer, and for the NAS to act as a pass-through for subsequent messages. Note that since the NAS only encapsulates the EAP-Response in its initial Access-Request, the initial EAP-Request within the authentication method is not available to the RADIUS server. For the RADIUS server to be able to continue the conversation, either the initial EAP-Request is vestigial, so that the RADIUS server need not be aware of it, or the relevant information from the initial EAP-Request (such as a nonce) is reflected in the initial EAP-Response, so that the RADIUS server can obtain it without having received the initial EAP-Request.
RADIUSを使用して、NASは、それらの間で使用されるEAPメソッドを実装する必要なしに、ピアと認証サーバー間のEAP会話のパススルーとして機能することができます。認証方法のEAP要求を送信してNASが会話を開始する場合、NASが最初のEAP要求に反映されたEAPメソッドを完全に実装する必要がないかもしれません。初期メソッドに応じて、NASがピアに送信される最初のパケットと共に構成され、その後のメッセージのパススルーとして機能するためには、NASが構成されていてもよい。 NASは初期アクセス要求でEAP応答のみをカプセル化するだけなので、認証方法内の初期のEAP-RequestはRADIUSサーバでは利用できません。 RADIUSサーバが会話を継続できるようにするには、最初のEAP-RequestのいずれかがveStigialです。そのため、RADIUSサーバーはITを認識する必要があります。初期のEAP応答に反映されているので、RADIUSサーバは初期のEAP要求を受信せずにそれを取得することができます。
Where the initial EAP-Request sent by the NAS is for an authentication Type (4 or greater), the peer MAY respond with a Nak indicating that it would prefer another authentication method that is not implemented locally. In this case, the NAS SHOULD send Access-Request encapsulating the received EAP-Response/Nak. This provides the RADIUS server with a hint about the authentication method(s) preferred by the peer, although it does not provide information on the Type of the original Request. It also provides the server with the Identifier used in the initial EAP-Request, so that Identifier conflicts can be avoided.
NASによって送信された初期のEAP要求が認証タイプ（4以上）の場合、ピアはNAKで応答することができ、それがローカルに実装されていない別の認証方法を好むことを示すことを示す。この場合、NASは受信したEAP-Response / NAKをカプセル化するアクセス要求を送信する必要があります。これにより、Peerによって優先される認証方法についてのヒントを持つRADIUSサーバーが提供されますが、元の要求の種類に関する情報は提供されていません。また、最初のEAP要求で使用されている識別子をサーバーに提供しているため、識別子の競合を回避できます。
In order to evaluate whether the alternatives preferred by the authenticating peer are allowed, the RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). This allows the RADIUS server to determine the peer identity, so as to be able to retrieve the associated authentication policy. Alternatively, an EAP-Request for an authentication method (Type 4 or greater) could be sent. Since the RADIUS server may not be aware of the Type of the initial EAP-Request, it is possible for the RADIUS server to choose an unacceptable method, and for the peer to respond with another Nak.
認証ピアによって優先される代替案が許可されているかどうかを評価するために、RADIUSサーバは通常、EAP - 要求/ IDをカプセル化するEAP - MESSAGE属性を含むアクセスチャレンジで応答する（タイプ1）。これにより、RADIUSサーバは、関連付けられた認証ポリシーを取得できるように、ピア識別情報を決定することができます。あるいは、認証方法（タイプ4以上）のEAP要求を送信することができる。RADIUSサーバは初期EAP要求の種類を認識していない可能性があるため、RADIUSサーバは許容できない方法を選択し、ピアが他のNAKで応答することが可能である。
In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. Since RADIUS proxies are assumed to act as a pass-through, they cannot be expected to parse an EAP-Response/Identity encapsulated within EAP-Message attribute(s). If the NAS initially sends an EAP-Request for an authentication method, and the peer identity cannot be determined from the EAP-Response, then the User-Name attribute SHOULD be determined by another means. As noted in [RFC2865] Section 5.6, it is recommended that Access-Requests use the value of the Calling-Station-Id as the value of the User-Name attribute.
EAP非EAP対応RADIUSプロキシをアクセス要求パケットを転送することを許可するために、NASが最初にピアにEAP-Request / Identityメッセージを送信した場合、NASはEAPの型データフィールドの内容をコピーする必要があります。ピアからユーザ名属性に受信された応答/ IDは、後続のアクセス要求ごとにUSER-NAME属性のEAP-RESPOND / IDの型データフィールドを含める必要があります。RADIUSプロキシはパススルーとして機能すると想定されているので、EAP-MESSAGE属性内にカプセル化されたEAP応答/ IDを解析することは期待できません。NASが最初に認証方法のEAP-Requestを送信し、ピアIDをEAP-RESPONSERTから決定できない場合は、ユーザー名属性を別の手段で決定する必要があります。[RFC2865]セクション5.6に記載されているように、access-requestsは、呼び出し側atist-idの値をuser-name属性の値として使用することをお勧めします。
Having the NAS send the initial EAP-Request packet has a number of advantages:
NASを送信すると、最初のEAP要求パケットにはいくつかの利点があります。
[1] It saves a round trip between the NAS and RADIUS server.
[1] NASとRADIUSサーバー間の往復の往復を保存します。
[2] An Access-Request is only sent to the RADIUS server if the authenticating peer sends an EAP-Response, confirming that it supports EAP. In situations where peers may be EAP unaware, initiating a RADIUS Access-Request on a "carrier sense" or "media up" indication may result in many authentication exchanges that cannot complete successfully. For example, on wired networks [IEEE8021X] Supplicants typically do not initiate the 802.1X conversation with an EAPOL-Start. Therefore an IEEE 802.1X-enabled bridge may not be able to determine whether the peer supports EAP until it receives a Response to the initial EAP-Request.
[2] Access-Requestは、認証ピアがEAP-Responseを送信した場合にのみRADIUSサーバーに送信されます。ピアがEAWでない状況では、「キャリアセンス」または「メディアアップ」のRADIUSアクセス要求を開始すると、正常に完了できない多くの認証交換が発生する可能性があります。たとえば、有線ネットワークでは、サプリカントは通常、EAPOL-STARTとの802.1X会話を開始しません。したがって、IEEE 802.1X対応ブリッジは、ピアが最初のEAP要求に対する応答を受信するまでEAPをサポートするかどうかを判断できない場合があります。
[3] It allows some peers to be authenticated locally.
[3] 一部のピアをローカルに認証できます。
Although having the NAS send the initial EAP-Request packet has substantial advantages, this technique cannot be universally employed. There are circumstances in which the peer identity is already known (such as when authentication and accounting is handled based on Called-Station-Id, Calling-Station-Id and/or Originating-Line-Info), but where the appropriate EAP method may vary based on that identity.
NASが初期のEAP要求パケットを送信させることはかなりの利点を有するが、この技術は普遍的に採用されない。ピアアイデンティティが既に知られている状況がある（認証およびアカウンティングが呼び出されたステーションID、呼び出しステーション-IDおよび/または発信回線情報に基づいて処理される場合など）、しかし適切なEAPメソッドができる場合そのアイデンティティに基づいてさまざまです。
Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server.
初期のEAP要求パケットを認証ピアに送信するのではなく、ピアの存在を検出すると、NASはEAP-STARTを表すEAP-MESSION属性を含むRADIUSサーバーにアクセス要求パケットを送信することができます。RADIUSサーバは通常、EAP - 要求/ IDをカプセル化するEAP-Message属性を含むアクセスチャレンジで応答します（タイプ1）。ただし、認証方法（4型以上）のEAP要求もサーバーによって送信される可能性があります。
EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). The Calling-Station-Id SHOULD be included in the User-Name attribute. This may result in a RADIUS Access-Request being sent by the NAS to the RADIUS server without first confirming that the peer supports EAP. Since this technique can result in a large number of uncompleted RADIUS conversations, in situations where EAP unaware peers are common, or where peer support for EAP cannot be determined on initial contact (e.g. [IEEE8021X] Supplicants not initiating the conversation with an EAPOL-Start) it SHOULD NOT be employed by default.
EAP-STARTは、長さ2のEAP-MESSAGE属性を送信することによって示されます（データなし）。呼び出し側局IDは、user-name属性に含める必要があります。これにより、ピアがEAPをサポートしていることを確認することなく、RADIUSアクセス要求がNASによってRADIUSサーバに送信される可能性があります。このテクニックは、EAP未計数ピアが共通の状況で、またはEAPのピアサポートが初期連絡先で決定できない状況では、多数の未完成のRADIUS会話をもたらす可能性があるため、またはEAPOL-STARTとの会話を開始していない[IEEE8021X]サプリカント）デフォルトでは使用しないでください。
For proxied RADIUS requests, there are two methods of processing. If the domain is determined based on the Calling-Station-Id, Called-Station-Id and/or Originating-Line-Info, the RADIUS server may proxy the initial RADIUS Access-Request/EAP-Start. If the realm is determined based on the peer identity, the local RADIUS server MUST respond with a RADIUS Access-Challenge including an EAP-Message attribute encapsulating an EAP-Request/Identity packet. The response from the authenticating peer SHOULD be proxied to the final authentication server.
RADIUSリクエストをプロキシした場合、処理方法は2つあります。ドメインが呼び出し側の局（登録）ID、呼び出し元情報および/または発信元情報に基づいて決定された場合、RADIUSサーバは初期RADIUS access-request / EAP-STARTをプロキシすることができます。レルムがピアIDに基づいて決定された場合、ローカルRADIUSサーバーは、EAP-REQUEST / IDパケットをカプセル化するEAP-MESSAGE属性を含むRADIUSアクセスチャレンジで応答する必要があります。認証ピアからの応答は、最終認証サーバーにプロキシされるべきです。
If an Access-Request is sent to a RADIUS server which does not support the EAP-Message attribute, then an Access-Reject MUST be sent in response. On receiving an Access-Reject, the NAS MUST deny access to the authenticating peer.
アクセス要求がEAP-MESSAGE属性をサポートしていないRADIUSサーバーに送信された場合、アクセスできに応答してアクセス拒否を送信する必要があります。アクセス拒否を受信すると、NASは認証ピアへのアクセスを拒否しなければなりません。
While acting as a pass-through, the NAS MUST validate the EAP header fields (Code, Identifier, Length) prior to forwarding an EAP packet to or from the RADIUS server. On receiving an EAP packet from the peer, the NAS checks the Code (2) and Length fields, and matches the Identifier value against the current Identifier, supplied by the RADIUS server in the most recently validated EAP-Request. On receiving an EAP packet from the RADIUS server (encapsulated within an Access-Challenge), the NAS checks the Code (1) and Length fields, then updates the current Identifier value. Pending EAP Responses that do not match the current Identifier value are silently discarded by the NAS.
パススルーとして機能している間、NASは、EAPパケットをRADIUSサーバに転送する前にEAPヘッダフィールド（コード、識別子、長さ）を検証する必要があります。ピアからEAPパケットを受信すると、NASはコード（2）と長さのフィールドをチェックし、最後に検証されたEAP-RequestでRADIUSサーバーによって提供される現在の識別子と識別子の値と一致します。RADIUSサーバからEAPパケットを受信する（アクセスチャレンジ内でカプセル化されている）、NASはコード（1）と長さフィールドをチェックしてから、現在の識別子値を更新します。現在の識別子値と一致しない保留中のEAP応答は、NASによって静かに破棄されます。
Since EAP method fields (Type, Type-Data) are typically not validated by a NAS operating as a pass-through, despite these checks it is possible for a NAS to forward an invalid EAP packet to or from the RADIUS server. A RADIUS server receiving EAP-Message attribute(s) it does not understand SHOULD make the determination of whether the error is fatal or non-fatal based on the EAP Type. A RADIUS server determining that a fatal error has occurred MUST send an Access-Reject containing an EAP-Message attribute encapsulating EAP-Failure.
EAPメソッドフィールド（type、type-data）は通常パススルーとして動作するNASによって検証されていないため、これらのチェックにもかかわらず、NASが無効なEAPパケットをRADIUSサーバーに転送することが可能です。EAP-Message属性を受信するRADIUSサーバーは、エラーがEAPタイプに基づいて致命的または非致命的であるかどうかを判断する必要があります。致命的なエラーが発生したと判断したRADIUSサーバーは、EAP-Message属性をカプセル化したEAP-障害を含むアクセスリジェクトを送信する必要があります。
A RADIUS server determining that a non-fatal error has occurred MAY send an Access-Challenge to the NAS including EAP-Message attribute(s) as well as an Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid EAP Packet (Ignored)". The Access-Challenge SHOULD encapsulate within EAP-Message attribute(s) the most recently sent EAP-Request packet (including the same Identifier value). On receiving such an Access-Challenge, a NAS implementing previous versions of this specification will decapsulate the EAP-Request and send it to the peer, which will retransmit the EAP-Response.
致命的でないエラーが発生したと判断したRADIUSサーバは、EAP - MESSAGE属性を含むNASにアクセスチャレンジを送信することができ、誤差因子属性[RFC3576]（rfc3576]（DECIMAL）「無効なEAP」パケット（無視されます）」アクセスチャレンジは、最後に送信されたEAP要求パケット（同じ識別子値を含む）のEAP-Message属性内にカプセル化する必要があります。このようなアクセスチャレンジを受信すると、この仕様の以前のバージョンを実装するNASはEAP要求をカプセル化し、それをピアに送信します。これにより、EAP応答を再送信します。
A NAS compliant with this specification, on receiving an Access-Challenge with an Error-Cause attribute of value 202 (decimal) SHOULD discard the EAP-Response packet most recently transmitted to the RADIUS server and check whether additional EAP-Response packets have been received matching the current Identifier value. If so, a new EAP-Response packet, if available, MUST be sent to the RADIUS server within an Access-Request, and the EAP-Message attribute(s) included within the Access-Challenge are silently discarded. If no EAP-Response packet is available, then the EAP-Request encapsulated within the Access-Challenge is sent to the peer, and the retransmission timer is reset.
この仕様書に準拠したNASは、誤差因数202（10進数）の誤差属性を有するアクセスチャレンジを受信すると、最後にRADIUSサーバに送信されたEAP応答パケットを破棄し、追加のEAP応答パケットが受信されたかどうかをチェックする必要があります。現在の識別子値を一致させる。もしそうであれば、利用可能な新しいEAP応答パケットは、アクセス要求内でRADIUSサーバに送信されなければならず、アクセスチャレンジ内に含まれるEAP - メッセージ属性は静かに破棄される。EAP-Response Packetが使用可能な場合は、アクセスチャレンジ内にカプセル化されているEAP-Requestがピアに送信され、再送タイマーがリセットされます。
In order to provide protection against Denial of Service (DoS) attacks, it is advisable for the NAS to allocate a finite buffer for EAP packets received from the peer, and to discard packets according to an appropriate policy once that buffer has been exceeded. Also, the RADIUS server is advised to permit only a modest number of invalid EAP packets within a single session, prior to terminating the session with an Access-Reject. By default a value of 5 invalid EAP packets is recommended.
サービス拒否（DOS）攻撃に対する保護を提供するために、NASがピアから受信したEAPパケットの有限バッファを割り当て、バッファが超過した後に適切なポリシーに従ってパケットを破棄することが推奨されます。また、RADIUSサーバは、セッションをアクセス拒否で終了する前に、単一のセッション内の無効なEAPパケットのうちの適切な数だけを許可することをお勧めします。デフォルトでは、5の無効なEAPパケットの値が推奨されます。
As noted in [RFC2284], if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit.
[RFC2284]で説明されているように、認証ピアとNAS（またはその逆）の間の遷移でEAPパケットが失われると、NASは再送信されます。
It may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the RADIUS server. This can be accomplished by inclusion of Session-Timeout attribute within the Access-Challenge packet.
特定の場合に再送戦略と認証タイムアウトを調整する必要があるかもしれません。たとえば、トークンカードが使用されているときに、ユーザーがカードを見つけてトークンに入ることを可能にするために追加の時間が必要になることがあります。NASは通常必要なパラメータに関する知識を持たないので、これらはRADIUSサーバによって提供される必要がある。これは、アクセスチャレンジパケット内にsession-timeout属性を含めることによって達成できます。
If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout is used to set the EAP retransmission timer for that EAP Request, and that Request alone. Once the EAP-Request has been sent, the NAS sets the retransmission timer, and if it expires without having received an EAP-Response corresponding to the Request, then the EAP-Request is retransmitted.
EAP-MESSAGEを含むアクセスチャレンジパケットにセッションタイムアウトが存在する場合、セッションタイムアウトの値は、そのEAP要求のEAP RESTRASSMISSION TIMER、およびその要求のみを設定するために使用されます。EAP要求が送信されると、NASは再送信タイマを設定し、要求に対応するEAP応答を受信せずに期限切れになると、EAP-REQUESTが再送信されます。
Using the EAP-Message attribute, it is possible for the RADIUS server to encapsulate an EAP packet that is larger than the MTU on the link between the NAS and the peer. Since it is not possible for the RADIUS server to use MTU discovery to ascertain the link MTU, the Framed-MTU attribute may be included in an Access-Request packet containing an EAP-Message attribute so as to provide the RADIUS server with this information. A RADIUS server having received a Framed-MTU attribute in an Access-Request packet MUST NOT send any subsequent packet in this EAP conversation containing EAP-Message attributes whose values, when concatenated, exceed the length specified by the Framed-MTU value, taking the link type (specified by the NAS-Port-Type attribute) into account. For example, as noted in [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 802.11, the RADIUS server may send an EAP packet as large as Framed-MTU minus four (4) octets, taking into account the additional overhead for the IEEE 802.1X Version (1), Type (1) and Body Length (2) fields.
EAP-MESSAGE属性を使用して、RADIUSサーバーは、NASとピアとの間のリンク上のMTUよりも大きいEAPパケットをカプセル化することが可能です。 RADIUSサーバがMTUディスカバリを使用してリンクMTUを確認することは不可能であるため、フレームメッセージ属性をこの情報に提供するようにEAP - MESSAGE属性を含むアクセス要求パケットに含めることができる。アクセス要求パケット内のフレーム化されたMTU属性を受信したRADIUSサーバは、その値が連結されたときに、その値がフレームMTU値で指定された長さを超えるEAP - メッセージ属性を含むこのEAP会話で任意のEAP会話を送信してはなりません。リンクタイプ（NAS-PORT-TYPE属性で指定）をアカウントにします。たとえば、[RFC3580]で述べたように、IEEE 802.11のNASポートタイプの値については、RADIUSサーバは、追加を考慮して、Framed-MTUマイナス4オクテットと同じ大きさのEAPパケットを送信することができます。 IEEE 802.1Xバージョン（1）のオーバーヘッド、（1）とボディ長（2）フィールド。
Currently the conversation between security servers and the RADIUS server is often proprietary because of lack of standardization. In order to increase standardization and provide interoperability between RADIUS vendors and security vendors, it is recommended that RADIUS- encapsulated EAP be used for this conversation.
現在、セキュリティサーバーとRADIUSサーバー間の会話は、標準化が不足しているため独自のものです。RADIUSベンダーとセキュリティベンダ間の標準化を高め、相互運用性を提供するためには、この会話にRADIUSカプセル化EAPを使用することをお勧めします。
This has the advantage of allowing the RADIUS server to support EAP without the need for authentication-specific code within the RADIUS server. Authentication-specific code can then reside on a security server instead.
これには、RADIUSサーバがRADIUSサーバ内の認証固有のコードを必要とせずにEAPをサポートできるという利点があります。その後、認証固有のコードは代わりにセキュリティサーバー上にあります。
In the case where RADIUS-encapsulated EAP is used in a conversation between a RADIUS server and a security server, the security server will typically return an Access-Accept message without inclusion of the expected attributes currently returned in an Access-Accept. This means that the RADIUS server MUST add these attributes prior to sending an Access-Accept message to the NAS.
RADIUSサーバとセキュリティサーバとの間の会話でRADIUSカプセル化されたEAPが使用される場合、セキュリティサーバは通常、現在アクセス許可に返されている予想される属性を含めることなくアクセス受信メッセージを返す。つまり、RADIUSサーバは、アクセス許可メッセージをNASに送信する前にこれらの属性を追加する必要があることを意味します。
In EAP, each session has its own unique Identifier space. RADIUS server implementations MUST be able to distinguish between EAP packets with the same Identifier existing within distinct sessions, originating on the same NAS. For this purpose, sessions can be distinguished based on NAS and session identification attributes. NAS identification attributes include NAS-Identifier, NAS-IPv6-Address and NAS-IPv4-Address. Session identification attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id, Called-Station-Id, Calling-Station-Id and Originating-Line-Info.
EAPでは、各セッションには独自の識別スペースがあります。RADIUSサーバ実装は、同じNASで発信された、異なるセッション内の同じ識別子を持つEAPパケットを区別できなければなりません。この目的のために、セッションは、NASおよびセッション識別属性に基づいて区別できます。NAS識別属性には、NAS識別子、NAS-IPv6-AddressおよびNAS-IPv4アドレスが含まれます。セッション識別属性には、ユーザー名、NASポート、NAS-Port-Type、NAS-Port-ID、呼び出されたステーションID、呼び出し元の局ID、および発信元情報が含まれます。
Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time.
EAPはピアツーピアプロトコルであるため、独立した認証と同時認証が逆方向に行われます。両方のピアは認証機として機能し、同時に認証することができます。
However, role reversal is not supported by this specification. A RADIUS server MUST respond to an Access-Request encapsulating an EAP-Request with an Access-Reject. In order to avoid retransmissions by the peer, the Access-Reject SHOULD include an EAP-Response/Nak packet indicating no preferred method, encapsulated within EAP-Message attribute(s).
ただし、役割の反転はこの仕様ではサポートされていません。RADIUSサーバは、アクセス要求をアクセス拒否してEAP-Requestをカプセル化するアクセス要求に応答する必要があります。ピアによる再送信を回避するために、アクセス拒否は、EAP - MESSAGE属性内にカプセル化されていない優先メソッドを示すEAP応答/ NAKパケットを含むべきである。
The NAS MUST make its access control decision based solely on the RADIUS Packet Type (Access-Accept/Access-Reject). The access control decision MUST NOT be based on the contents of the EAP packet encapsulated in one or more EAP-Message attributes, if present.
NASは、RADIUSパケットタイプのみに基づいてアクセス制御決定を行わなければならない（アクセス承認/アクセス拒否）。アクセス制御の決定は、存在する場合、1つまたは複数のEAPメッセージ属性でカプセル化されたEAPパケットの内容に基づいてはならない。
Access-Accept packets SHOULD have only one EAP-Message attribute in them, containing EAP Success; similarly, Access-Reject packets SHOULD have only one EAP-Message attribute in them, containing EAP Failure.
Access-Acceptパケットには、EAPの成功を含むEAP-Message属性が1つだけです。同様に、アクセスリジェクトパケットは、EAP障害を含むEAP-MESSAGE属性を1つだけ持つ必要があります。
Where the encapsulated EAP packet does not match the result implied by the RADIUS Packet Type, the combination is likely to cause confusion, because the NAS and peer will arrive at different conclusions as to the outcome of the authentication.
カプセル化されたEAPパケットがRADIUSパケットタイプによって暗示された結果と一致しない場合、NASとピアは認証の結果について異なる結論に到着するため、組み合わせは混乱を引き起こす可能性があります。
For example, if the NAS receives an Access-Reject with an encapsulated EAP Success, it will not grant access to the peer. However, on receiving the EAP Success, the peer will be lead to believe that it authenticated successfully.
たとえば、NASがカプセル化されたEAP成功を持つアクセス拒否を受信した場合、ピアへのアクセスを許可しません。ただし、EAPの成功を受けると、ピアは正常に認証されたと信じることになります。
If the NAS receives an Access-Accept with an encapsulated EAP Failure, it will grant access to the peer. However, on receiving an EAP Failure, the peer will be lead to believe that it failed authentication. If no EAP-Message attribute is included within an Access-Accept or Access-Reject, then the peer may not be informed as to the outcome of the authentication, while the NAS will take action to allow or deny access.
NASがカプセル化されたEAP障害を伴うアクセス許可を受信した場合、ピアへのアクセスを許可します。ただし、EAP障害を受けると、ピアは認証に失敗したと信じることになります。アクセス承認またはアクセス拒否内にEAP-MESSAGE属性が含まれていない場合は、PERは認証の結果について知らされない場合がありますが、NASはアクセスを許可または拒否するアクションを実行します。
As described in [RFC2284], the EAP Success and Failure packets are not acknowledged, and these packets terminate the EAP conversation. As a result, if these packets are encapsulated within an Access-Challenge, no response will be received, and therefore the NAS will send no further Access-Requests to the RADIUS server for the session. As a result, the RADIUS server will not indicate to the NAS whether to allow or deny access, while the peer will be informed as to the outcome of the authentication.
[RFC2284]で説明されているように、EAPの成功と障害パケットは確認されず、これらのパケットはEAPの会話を終了します。その結果、これらのパケットがアクセスチャレンジ内にカプセル化されている場合、応答は受信されず、したがって、NASはセッションのRADIUSサーバにそれ以上のアクセス要求を送信しません。その結果、RADIUSサーバは、アクセスを許可または拒否するかどうかをNASに示すことはありませんが、ピアは認証の結果について知らされます。
To avoid these conflicts, the following combinations SHOULD NOT be sent by a RADIUS server:
これらの競合を回避するために、以下の組み合わせはRADIUSサーバによって送信されるべきではありません。
Access-Accept/EAP-Message/EAP Failure
Access-Accept/no EAP-Message attribute
Access-Accept/EAP-Start
Access-Reject/EAP-Message/EAP Success
Access-Reject/no EAP-Message attribute
Access-Reject/EAP-Start
Access-Challenge/EAP-Message/EAP Success
Access-Challenge/EAP-Message/EAP Failure
Access-Challenge/no EAP-Message attribute
Access-Challenge/EAP-Start
Since the responsibility for avoiding conflicts lies with the RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to correct contradictory messages that it receives. This behavior, originally mandated within [IEEE8021X], will be deprecated in the future.
競合を回避する責任はRADIUSサーバーと存在するため、受信した矛盾するメッセージを修正するために、NASはEAPパケットを「製造」してはなりません。この現象は、もともと[IEEE8021x]内で義務付けられていますが、将来非課金されます。
A RADIUS Access-Accept or Access-Reject packet may contain EAP-Message attribute(s). In order to ensure the correct processing of RADIUS packets, the NAS MUST first process the attributes, including the EAP-Message attribute(s), prior to processing the Accept/Reject indication.
RADIUSアクセス許容またはアクセス拒否パケットには、EAP - MESSAGE属性を含めることができる。RADIUSパケットの正しい処理を確実にするために、ACCEPT / REJECT表示を処理する前に、NASは最初にEAP-MESSAGE属性を含む属性を処理する必要があります。
The Reply-Message attribute, defined in [RFC2865], Section 5.18, indicates text which may be displayed to the peer. This is similar in concept to EAP Notification, defined in [RFC2284]. When sending a displayable message to a NAS during an EAP conversation, the RADIUS server MUST encapsulate displayable messages within EAP-Message/EAP-Request/Notification attribute(s). Reply-Message attribute(s) MUST NOT be included in any RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an Access-Accept or Access-Reject packet.
[RFC2865]、セクション5.18で定義されている応答メッセージ属性は、ピアに表示される可能性があるテキストを示しています。[RFC2284]で定義されているEAP通知の概念と同様です。EAP会話中に表示可能メッセージをNASに送信すると、RADIUSサーバは、EAP - MESSAGE / EAP要求/通知属性内で表示可能メッセージをカプセル化する必要があります。応答メッセージ属性は、EAP-MESSAGE属性を含む任意のRADIUSメッセージに含めてはいけません。EAP-message / EAP-Request /通知は、アクセス許可またはアクセス拒否パケット内に含めるべきではありません。
In some existing implementations, a NAS receiving Reply-Message attribute(s) copies the Text field(s) into the Type-Data field of an EAP-Request/Notification packet, fills in the Identifier field, and sends this to the peer. However, several issues arise from this:
いくつかの既存の実装形態では、応答メッセージ属性を受信したNASは、テキストフィールドをEAP要求/通知パケットの型データフィールドにコピーし、識別子フィールドに記入し、これをピアに送信する。ただし、これからいくつかの問題が発生します。
[1] Unexpected Responses. On receiving an EAP-Request/Notification, the peer will send an EAP-Response/Notification, and the NAS will pass this on to the RADIUS server, encapsulated within EAP-Message attribute(s). However, the RADIUS server may not be expecting an Access-Request containing an EAP-Message/EAP-Response/Notification attribute.
[1] 予期せぬ反応EAP要求/通知を受信すると、ピアはEAP-Response /通知を送信し、NASはEAP-MESSAGE属性内にカプセル化されたRADIUSサーバーにこれを渡します。ただし、RADIUSサーバーは、EAP-MESSAGE / EAP-RESPORT / NOTIONS属性を含むアクセス要求を期待していない可能性があります。
For example, consider what happens when a Reply-Message is included within an Access-Accept or Access-Reject packet with no EAP-Message attribute(s) present. If the value of the Reply-Message attribute is copied into the Type-Data of an EAP-Request/Notification and sent to the peer, this will result in an Access-Request containing an EAP-Message/EAP-Response/Notification attribute being sent by the NAS to the RADIUS server. Since an Access-Accept or Access-Reject packet terminates the RADIUS conversation, such an Access-Request would not be expected, and could be interpreted as the start of another conversation.
たとえば、存在するEAP-MESSAGE属性が存在しないアクセス許可またはアクセス拒否パケット内に応答メッセージが含まれているときに何が起こるかを検討してください。reply-message属性の値がEAP-Request /通知のタイプデータにコピーされ、ピアに送信された場合、これはEAP-MESSAGE / EAP応答/通知属性を含むアクセス要求になります。RADIUSサーバにNASによって送信されます。アクセス許可またはアクセス拒否パケットがRADIUS会話を終了するので、そのようなアクセス要求は予想されず、別の会話の開始として解釈される可能性がある。
[2] Identifier conflicts. While the EAP-Request/Notification is an EAP packet containing an Identifier field, the Reply-Message attribute does not contain an Identifier field. As a result, a NAS receiving a Reply-Message attribute and wishing to translate this to an EAP-Request/Notification will need to choose an Identifier value. It is possible that the chosen Identifier value will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation, potentially causing confusion between a new packet and a retransmission.
[2] 識別子の競合EAP-REQUEST /通知は識別子フィールドを含むEAPパケットですが、応答メッセージ属性に識別子フィールドが含まれていません。その結果、応答メッセージ属性を受信し、これをEAP要求/通知に翻訳することを希望するNASは、識別子値を選択する必要があります。選択された識別子値が、EAP会話内の別のパケットに対してRADIUSサーバによって選択された値と競合する可能性があり、新しいパケットと再送信との間で混乱を引き起こす可能性がある。
To avoid these problems, a NAS receiving a Reply-Message attribute from the RADIUS server SHOULD silently discard the attribute, rather than attempting to translate it to an EAP Notification Request.
これらの問題を回避するために、RADIUSサーバからREPLY - MESSAGE属性を受信したNASは、EAP通知要求に変換しようとするのではなく、属性を静的に破棄する必要があります。
The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in Access-Request packets, and either NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address attributes MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name attribute was included in an Access-Request, the RADIUS server MUST include the User-Name attribute in subsequent Access-Accept packets. Without the User-Name attribute, accounting and billing becomes difficult to manage. The User-Name attribute within the Access-Accept packet need not be the same as the User-Name attribute in the Access-Request.
NASポートまたはNAS-Port-ID属性は、アクセス要求パケットのNASによって含める必要があり、NAS ID、NAS-IPアドレスまたはNAS-IPv6アドレス属性のいずれかを含める必要があります。EAP-NAWAREプロキシによるアクセス応答の転送を許可するために、user-name属性がアクセス要求に含まれていた場合、RADIUSサーバは後続のアクセス許可パケットにUSER-NAME属性を含める必要があります。ユーザー名属性がないと、会計と請求は管理が困難になります。access-acceptパケット内のuser-name属性は、アクセス要求内のuser-name属性と同じである必要はありません。
Description
description
This attribute encapsulates EAP [RFC2284] packets so as to allow the NAS to authenticate peers via EAP without having to understand the EAP method it is passing through.
この属性は、EAP [RFC2284]パケットをカプセル化して、NASが通過しているEAPメソッドを理解しなくてもEAPを介してピアを認証できるようにします。
The NAS places EAP messages received from the authenticating peer into one or more EAP-Message attributes and forwards them to the RADIUS server within an Access-Request message. If multiple EAP-Message attributes are contained within an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. The RADIUS server can return EAP-Message attributes in Access-Challenge, Access-Accept and Access-Reject packets.
NASは、認証ピアから受信したEAPメッセージを1つ以上のEAPメッセージ属性に配置し、それらをアクセス要求メッセージ内でRADIUSサーバに転送する。複数のEAP - メッセージ属性がアクセス要求またはアクセスチャレンジパケット内に含まれている場合、それらは順番になければならず、それらはアクセス要求またはアクセスチャレンジパケット内の連続した属性でなければならない。RADIUSサーバは、アクセスチャレンジ、アクセス許可、およびアクセス拒否パケットでEAP-Message属性を返すことができます。
When RADIUS is used to enable EAP authentication, Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets SHOULD contain one or more EAP-Message attributes. Where more than one EAP-Message attribute is included, it is assumed that the attributes are to be concatenated to form a single EAP packet.
RADIUSを使用してEAP認証、アクセス要求、アクセスチャレンジ、アクセス許可、およびアクセスリジェクトパケットには、1つ以上のEAPメッセージ属性を含める必要があります。複数のEAP-message属性が含まれている場合、属性を連結して単一のEAPパケットを形成すると仮定する。
Multiple EAP packets MUST NOT be encoded within EAP-Message attributes contained within a single Access-Challenge, Access-Accept, Access-Reject or Access-Request packet.
複数のEAPパケットは、単一のアクセスチャレンジ、アクセス許可、アクセス拒否またはアクセス要求パケット内に含まれるEAP-Message属性内にエンコードされてはいけません。
It is expected that EAP will be used to implement a variety of authentication methods, including methods involving strong cryptography. In order to prevent attackers from subverting EAP by attacking RADIUS/EAP, (for example, by modifying EAP Success or EAP Failure packets) it is necessary that RADIUS provide per-packet authentication and integrity protection.
EAPは、強い暗号化を含む方法を含む、さまざまな認証方法を実装するために使用されることが予想されます。RADIUS / EAPを攻撃して攻撃者がEAPを縮小するのを防ぐために（たとえば、EAP成功またはEAP障害パケットを変更することによって）半径はパケットごとの認証と完全性保護を提供する必要があります。
Therefore the Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute.
したがって、message-authenticator属性を使用して、EAP-Message属性を含むすべてのアクセス要求、アクセスチャレンジ、アクセス許可、およびアクセスリジェクトパケットを保護する必要があります。
Access-Request packets including EAP-Message attribute(s) without a Message-Authenticator attribute SHOULD be silently discarded by the RADIUS server. A RADIUS server supporting the EAP-Message attribute MUST calculate the correct value of the Message-Authenticator and MUST silently discard the packet if it does not match the value sent. A RADIUS server not supporting the EAP-Message attribute MUST return an Access-Reject if it receives an Access-Request containing an EAP-Message attribute.
message-authenticator属性を持たないEAP-MESSAGE属性を含むアクセス要求パケットは、RADIUSサーバーによって黙って破棄されるべきです。EAP-MESSAGE属性をサポートするRADIUSサーバーは、メッセージオーセンティケータの正しい値を計算し、送信された値と一致しない場合はパケットを静的に破棄する必要があります。EAP-MESSAGE属性をサポートしていないRADIUSサーバーは、EAP-MESSAGE属性を含むアクセス要求を受信した場合にアクセスリジェクトを返す必要があります。
Access-Challenge, Access-Accept, or Access-Reject packets including EAP-Message attribute(s) without a Message-Authenticator attribute SHOULD be silently discarded by the NAS. A NAS supporting the EAP-Message attribute MUST calculate the correct value of the Message-Authenticator and MUST silently discard the packet if it does not match the value sent.
Message-Authenticator属性を持たないEAP-Message属性を含むアクセスチャレンジ、アクセス許可、またはアクセス拒否パケットは、NASによって静かに破棄されるべきです。EAP-MESSAGE属性をサポートするNASは、メッセージオーセンティケータの正しい値を計算し、送信された値と一致しない場合はパケットを静的に破棄する必要があります。
A summary of the EAP-Message attribute format is shown below. The fields are transmitted from left to right.
EAP-MESSAGE属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
79 for EAP-Message
79 EAP-Messageの場合
Length
長さ
>= 3
> = 3
String
ストリング
The String field contains an EAP packet, as defined in [RFC2284]. If multiple EAP-Message attributes are present in a packet their values should be concatenated; this allows EAP packets longer than 253 octets to be transported by RADIUS.
[String]フィールドには[RFC2284]で定義されているEAPパケットが含まれています。複数のEAPメッセージ属性がパケットに存在する場合、それらの値は連結されるべきです。これにより、253オクテットより長いEAPパケットを半径で転送することができます。
Description
description
This attribute MAY be used to authenticate and integrity-protect Access-Requests in order to prevent spoofing. It MAY be used in any Access-Request. It MUST be used in any Access-Request, Access-Accept, Access-Reject or Access-Challenge that includes an EAP-Message attribute.
この属性は、スプーフィングを防ぐためにアクセス要求を認証および整合性保護するために使用されます。それは任意のアクセス要求で使用されるかもしれません。EAP-MESSAGE属性を含む任意のアクセス要求、アクセス許可、アクセス拒否またはアクセスチャレンジで使用する必要があります。
A RADIUS server receiving an Access-Request with a Message-Authenticator attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.
Message-Authenticator属性を持つアクセス要求を受信したRADIUSサーバーは、メッセージオーセンティケータの正しい値を計算し、それが送信された値と一致しない場合はパケットを静的に破棄しなければなりません。
A RADIUS client receiving an Access-Accept, Access-Reject or Access-Challenge with a Message-Authenticator attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.
Message-Authenticator属性を持つアクセス許可、アクセス拒否、またはアクセスチャレンジを受信したRADIUSクライアントは、メッセージオーセンティケータの正しい値を計算し、送信された値と一致しない場合はパケットをサイレントに破棄しなければなりません。
This attribute is not required in Access-Requests which include the User-Password attribute, but is useful for preventing attacks on other types of authentication. This attribute is intended to thwart attempts by an attacker to setup a "rogue" NAS, and perform online dictionary attacks against the RADIUS server. It does not afford protection against "offline" attacks where the attacker intercepts packets containing (for example) CHAP challenge and response, and performs a dictionary attack against those packets offline.
この属性は、user-password属性を含むアクセス要求では必要ありませんが、他の種類の認証に対する攻撃を防ぐのに役立ちます。この属性は、攻撃者が「Rogue」NASを設定し、RADIUSサーバーに対するオンライン辞書攻撃を実行することによる試行を妨げることを目的としています。攻撃者が（たとえば）CHAPのチャレンジと応答を含むパケットを傍受し、オフラインにするパケットに対する辞書攻撃を実行する「オフライン」攻撃に対する保護はありません。
A summary of the Message-Authenticator attribute format is shown below. The fields are transmitted from left to right.
メッセージオーセンティケータ属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
80 for Message-Authenticator
Message-Authenticator用の80
Length
長さ
18
18.
String
ストリング
When present in an Access-Request packet, Message-Authenticator is an HMAC-MD5 [RFC2104] hash of the entire Access-Request packet, including Type, ID, Length and Authenticator, using the shared secret as the key, as follows.
アクセス要求パケットに存在する場合、Message-Authenticatorは、次のように、タイプ、ID、長さ、およびオーセンティケータを含む、Access-Requestパケット全体のHMAC-MD5 [RFC2104]ハッシュです。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
Message-Authenticator = HMAC-MD5（タイプ、識別子、長さ、要求オーセンティケータ、属性）
When the message integrity check is calculated the signature string should be considered to be sixteen octets of zero.
メッセージ整合性チェックが計算されると、署名文字列はゼロの16オクテットと見なされるべきです。
For Access-Challenge, Access-Accept, and Access-Reject packets, the Message-Authenticator is calculated as follows, using the Request-Authenticator from the Access-Request this packet is in reply to:
アクセスチャレンジ、アクセス許可、およびアクセス拒否パケットの場合、メッセージオーセンティケータは次のように計算されます。このパケットは次のように返信します。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
Message-Authenticator = HMAC-MD5（タイプ、識別子、長さ、要求オーセンティケータ、属性）
When the message integrity check is calculated the signature string should be considered to be sixteen octets of zero. The shared secret is used as the key for the HMAC-MD5 message integrity check. The Message-Authenticator is calculated and inserted in the packet before the Response Authenticator is calculated.
メッセージ整合性チェックが計算されると、署名文字列はゼロの16オクテットと見なされるべきです。共有秘密は、HMAC-MD5メッセージ整合性チェックのキーとして使用されます。メッセージオーセンティケータは、応答オーセンティケータが計算される前に計算され、パケットに挿入される。
The following table provides a guide to which attributes may be found in packets including EAP-Message attribute(s), and in what quantity. The EAP-Message and Message-Authenticator attributes specified in this document MUST NOT be present in an Accounting-Request. If a table entry is omitted, the values found in [RFC2548], [RFC2865], [RFC2868], [RFC2869] and [RFC3162] should be assumed.
次の表は、EAP-MESSAGE属性を含むパケットに、およびどの倍数で見つかるのかを示すガイドを示しています。このドキュメントで指定されているEAP-MESSAGEおよびMESSAGE-Authenticatorの属性は、アカウンティング要求に存在してはいけません。テーブルエントリを省略すると、[RFC2548]、[RFC2865]、[RFC2868]、[RFC2869]、[RFC2869]、[RFC3162]で見つかった値を想定してください。
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
0 0 0 0 2 User-Password [Note 1]
0 0 0 0 3 CHAP-Password [Note 1]
0 0 0 0 18 Reply-Message
0 0 0 0 60 CHAP-Challenge
0 0 0 0 70 ARAP-Password [Note 1]
0 0 0 0 75 Password-Retry
1+ 1+ 1+ 1+ 79 EAP-Message [Note 1]
1 1 1 1 80 Message-Authenticator [Note 1]
0-1 0 0 0 94 Originating-Line-Info [Note 3]
0 0 0-1 0-1 101 Error-Cause [Note 2]
Request Accept Reject Challenge # Attribute
[Note 1] An Access-Request that contains either a User-Password or CHAP-Password or ARAP-Password or one or more EAP-Message attributes MUST NOT contain more than one type of those four attributes. If it does not contain any of those four attributes, it SHOULD contain a Message-Authenticator. If any packet type contains an EAP-Message attribute it MUST also contain a Message-Authenticator. A RADIUS server receiving an Access-Request not containing any of those four attributes and also not containing a Message-Authenticator attribute SHOULD silently discard it.
[注1]ユーザーパスワードまたはCHAPパスワード、またはARAPパスワード、または1つ以上のEAP-MESSAGE属性のいずれかを含むアクセス要求は、これらの4つの属性の複数のタイプを含んではいけません。これら4つの属性のいずれも含まれていない場合は、メッセージオーセンティケータを含める必要があります。任意のパケットタイプがEAP-MESSAGE属性を含む場合、メッセージオーセンティケータも含まなければなりません。これらの4つの属性のいずれかを含まず、Message-Authenticator属性を含まないアクセス要求を受信したRADIUSサーバは、静かに破棄する必要があります。
[Note 2] The Error-Cause attribute is defined in [RFC3576].
[注2] [RFC3576]でエラー原因属性が定義されています。
[Note 3] The Originating-Line-Info attribute is defined in [NASREQ].
[注3]発信枠info属性は[NASREQ]で定義されています。
The following table defines the meaning of the above table entries.
次の表は、上記の表エントリの意味を定義しています。
0 This attribute MUST NOT be present. 0+ Zero or more instances of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present. 1 Exactly one instance of this attribute MUST be present. 1+ One or more of these attributes MUST be present.
0この属性は存在してはいけません。0この属性の0個以上のインスタンスが存在する可能性があります。0 - 1 0またはこの属性の1つのインスタンスが存在する場合があります。1正確にこの属性の1つのインスタンスがある必要があります。1これらの属性の1つ以上が存在している必要があります。
RADIUS/EAP is used in order to provide authentication and authorization for network access. As a result, both the RADIUS and EAP portions of the conversation are potential targets of an attack. Threats are discussed in [RFC2607], [RFC2865], and [RFC3162]. Examples include:
RADIUS / EAPは、ネットワークアクセスの認証と許可を提供するために使用されます。その結果、会話の半径とEAP部分の両方が攻撃の潜在的な目標である。[RFC2607]、[RFC2865]、[RFC3162]で脅威について説明します。例としては、以下が含まれます。
[1] An adversary may attempt to acquire confidential data and identities by snooping RADIUS packets.
[1] 敵対者は、RADIUSパケットをスヌーピングして機密データと身元を取得しようとする可能性があります。
[2] An adversary may attempt to modify packets containing RADIUS messages.
[2] 敵対者は、RADIUSメッセージを含むパケットを変更しようとする可能性があります。
[3] An adversary may attempt to inject packets into a RADIUS conversation.
[3] 敵対者は、半径会話にパケットを注入しようとする可能性があります。
[4] An adversary may launch a dictionary attack against the RADIUS shared secret.
[4] 敵対者は、RADIUS共有秘密に対する辞書攻撃を開始することがあります。
[5] An adversary may launch a known plaintext attack, hoping to recover the key stream corresponding to a Request Authenticator.
[5] 敵対者は、要求オーセンティケータに対応するキーストリームを回復することを望んで、既知の平文攻撃を起動することができる。
[6] An adversary may attempt to replay a RADIUS exchange.
[6] 敵対者はRADIUS交換を再生しようとする可能性があります。
[7] An adversary may attempt to disrupt the EAP negotiation, in order to weaken the authentication, or gain access to peer passwords.
[7] 認証を解消するために、敵対者はEAPネゴシエーションを中断したり、ピアパスワードにアクセスすることを試みることがあります。
[8] An authenticated NAS may attempt to forge NAS or session identification attributes,
[8] 認証されたNASは、NASまたはセッション識別の属性を偽造しようとする可能性があります。
[9] A rogue (unauthenticated) NAS may attempt to impersonate a legitimate NAS.
[9] 不正な（認証されていない）NASは正当なNASを偽装しようとする可能性があります。
[10] An attacker may attempt to act as a man-in-the-middle.
[10] 攻撃者は、中間のマンのように機能しようとするかもしれません。
To address these threats, it is necessary to support confidentiality, data origin authentication, integrity, and replay protection on a per-packet basis. Bi-directional authentication between the RADIUS client and server also needs to be provided. There is no requirement that the identities of RADIUS clients and servers be kept confidential (e.g., from a passive eavesdropper).
これらの脅威に対処するためには、パケットごとに機密性、データ原点認証、整合性、および再生保護をサポートする必要があります。RADIUSクライアントとサーバー間の双方向認証も提供する必要があります。RADIUSクライアントおよびサーバのアイデンティティを機密保持（例えば、受動盗聴者から）に保たれることは要件はない。
To address the security vulnerabilities of RADIUS/EAP, implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management.
RADIUS / EAPのセキュリティの脆弱性に対処するために、この仕様の実装は、鍵管理のためのIKE [RFC2409]と共にIPsec [RFC2401]をサポートする必要があります。NULL以外の変換を伴うIPsec ESP [RFC2406]をサポートし、NULL以外の暗号化変換を使用したIPsec ESPを使用して、パケットごとの機密保持、認証、整合性、および再生保護を提供する必要があります。IKEは鍵管理に使用する必要があります。
Within RADIUS [RFC2865], a shared secret is used for hiding of attributes such as User-Password, as well as in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Response Authenticator.
RADIUS [RFC2865]内では、共有秘密が、ユーザーパスワードなどの属性の隠蔽、ならびに応答オーセンティケータの計算に使用されます。RADIUS Accounting [RFC2866]では、共有秘密は要求オーセンティケータと応答オーセンティケータの両方の計算に使用されます。
Since in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication, only use of IPsec ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPSEC AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret.
RADIUSでは共有秘密が機密性を提供するために使用されているので、整合性保護と認証だけでなく、NULL以外の変換を伴うIPsec ESPの使用のみが、RADIUSアプリケーション層のセキュリティを代入するのに十分なセキュリティサービスを提供できます。したがって、IPSec AHまたはESP NULLが使用されている場合、通常はRADIUS共有秘密を設定する必要があります。
Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed. However, a RADIUS server that cannot know whether incoming traffic is IPsec-protected MUST be configured with a non-null RADIUS shared secret.
RADIUSがIPSec ESPを介してNULL以外の変換で実行されている場合、NASとRADIUSサーバー間のシークレットは構成されていない可能性があります。この場合、ゼロ長の共有秘密を想定する必要があります。ただし、着信トラフィックがIPsec-Protectedかどうかを知ることができないRADIUSサーバーは、NULL以外のRADIUS共有秘密で構成する必要があります。
When IPsec ESP is used with RADIUS, per-packet authentication, integrity and replay protection MUST be used. 3DES-CBC MUST be supported as an encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be offered as a preferred encryption transform if supported. HMAC-SHA1-96 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be used as the encryption transform.
IPsec ESPが半径、パケットごとの認証、整合性および再生保護を使用する必要があります。3DES-CBCは暗号化変換としてサポートされている必要があり、AES-CBCをサポートする必要があります。AES-CBCは、サポートされている場合、好ましい暗号化変換として提供する必要があります。HMAC-SHA1-96は認証変換としてサポートされている必要があります。DES-CBCは暗号化変換として使用しないでください。
A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812".
IPsec対応のRADIUSクライアントの典型的なIPSecポリシーは、「私から任意の宛先ポートUDP 1812にIPSecを開始する」です。これにより、RADIUSトラフィックを送信する前に、IPsec SAをRADIUSクライアントによって設定します。クライアントによって連絡されたいくつかのRADIUSサーバがIPSecをサポートしていない場合は、より細かい方針が必要になります。
For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept IPsec, from any to me, destination port 1812". This causes the RADIUS server to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS clients connecting to an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec.
IPsec対応のRADIUSサーバーの場合、典型的なIPSecポリシーは「IPSecを任意のIPSecに受け入れます」と宛先ポート1812 "です。これにより、RADIUSサーバはIPSecの使用を受け入れる（必要とされない）。IPsec対応のRADIUSサーバーに接続するすべてのRADIUSクライアントにIPSecを必要とするのは適切ではないかもしれません。
Where IPsec is used for security, and no RADIUS shared secret is configured, it is important that the RADIUS client and server perform an authorization check. Before enabling a host to act as a RADIUS client, the RADIUS server SHOULD check whether the host is authorized to provide network access. Similarly, before enabling a host to act as a RADIUS server, the RADIUS client SHOULD check whether the host is authorized for that role.
IPSecがセキュリティに使用され、RADIUS共有シークレットが設定されていない場合は、RADIUSクライアントとサーバーが許可検査を実行することが重要です。ホストがRADIUSクライアントとして機能することを可能にする前に、RADIUSサーバはホストがネットワークアクセスを提供することを許可されているかどうかを確認する必要があります。同様に、ホストがRADIUSサーバとして機能することを可能にする前に、RADIUSクライアントはホストがその役割に対して許可されているかどうかを確認する必要があります。
RADIUS servers can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS clients. Alternatively, if a separate Certification Authority (CA) exists for RADIUS clients, then the RADIUS server can configure this CA as a trust anchor [RFC3280] for use with IPsec.
RADIUSサーバーは、IPアドレス（事前共有キーを持つIKE Agressiveモードの場合）またはRADIUSクライアントのFQDN（証明書認証）で構成できます。あるいは、RADIUSクライアントに別の認証局（CA）が存在する場合、RADIUSサーバは、IPSecで使用するための信頼アンカー[RFC3280]としてこのCAを設定できます。
Similarly, RADIUS clients can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS servers. Alternatively, if a separate CA exists for RADIUS servers, then the RADIUS client can configure this CA as a trust anchor for use with IPsec.
同様に、RADIUSクライアントは、RADIUSサーバのIPアドレス（事前共有キーを持つIKE積極型モードの場合）またはFQDNS（証明書認証用）で構成できます。あるいは、RADIUSサーバに別のCAが存在する場合、RADIUSクライアントはIPsecで使用するための信頼アンカーとしてこのCAを設定できます。
Since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, certificate policies need to apply to all uses of IPsec on RADIUS clients and servers. In IPsec deployments supporting only certificate authentication, a management station initiating an IPsec-protected telnet session to the RADIUS server would need to obtain a certificate chaining to the RADIUS client CA. Issuing such a certificate might not be appropriate if the management station was not authorized as a RADIUS client.
SSL / TLSとは異なり、IKEは証明書ポリシーをポートごとに設定できないため、証明書ポリシーはRADIUSクライアントとサーバー上のすべての使用方法に適用する必要があります。証明書認証のみをサポートするIPsecデプロイメントでは、RADIUSサーバーへのIPsec保護されたTelnetセッションを開始する管理ステーションは、RADIUSクライアントCAへの証明書を取得する必要があります。管理ステーションがRADIUSクライアントとして許可されていない場合、そのような証明書を発行することは適切ではないかもしれません。
Where RADIUS clients may obtain their IP address dynamically (such as an Access Point supporting DHCP), IKE Main Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this requires use of a group pre-shared key; instead, Aggressive Mode SHOULD be used. IKEv2, a work in progress, may address this issue in the future. Where RADIUS client addresses are statically assigned, either Aggressive Mode or Main Mode MAY be used. With certificate authentication, Main Mode SHOULD be used.
RADIUSクライアントがIPアドレスを動的に（DHCPをサポートするアクセスポイントなど）を取得できる場合は、プリシェアードキー[RFC2409]を持つIKEメインモードを使用しないでください。代わりに、積極的なモードを使用する必要があります。進行中の作業であるIKEV2は、将来この問題に対処するかもしれません。RADIUSクライアントアドレスが静的に割り当てられている場合は、積極的なモードまたはメインモードのいずれかを使用できます。証明書認証では、メインモードを使用する必要があります。
Care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so that group pre-shared keys are still a practical necessity. As a result, the ID_FQDN identity payload SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. This approach also has other advantages, since it allows the RADIUS server and client to configure themselves based on the fully qualified domain name of their peers.
積極的なモードでも事前共有キーをマッピングできるようにするには、IKEフェーズ1のIDペイロード選択では注意が必要です。ID_IPv4_addrまたはid_ipv6_addr識別ペイロードが使用され、アドレスが動的に割り当てられている場合、鍵へのIDのマッピングは不可能であるため、グループ事前共有キーは依然として実用的な必要性です。その結果、ID_FQDN IDペイロードは、事前共有キーとIPアドレスと共に積極的なモードが使用され、IPアドレスが動的に割り当てられている状況で採用されるべきです。このアプローチには、RADIUSサーバーとクライアントが自分のピアの完全修飾ドメイン名に基づいて自分自身を設定できるため、他の利点もあります。
Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so that RADIUS exchanges requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also advisable where quality of service considerations dictate different handling RADIUS conversations. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983].
IPsecでは、セキュリティサービスはIPsec SAの粒度で交渉されているので、既存のIPSec SASと交渉されたセキュリティサービスのセットを必要とするRADIUS交換は、新しいIPsec SAを交渉する必要があります。また、サービス品質の考慮事項が異なる処理RADIUS会話を指示する場合にも、別々のIPsec SASもお勧めします。異なるサービス品質を同じIPSec SAによって処理される接続に適用しようとすると、並べ替え、再生ウィンドウの外側に落ちる可能性があります。問題については、[RFC2983]を参照してください。
This section provides more detail on the vulnerabilities identified in Section 4.1., and how they may be mitigated. Vulnerabilities include:
このセクションでは、セクション4.1で識別された脆弱性、およびそれらがどのように軽減されるかについて詳しく説明します。脆弱性は次のとおりです。
Privacy issues Spoofing and hijacking Dictionary attacks Known plaintext attacks Replay attacks Negotiation attacks Impersonation Man in the middle attacks Separation of authenticator and authentication server Multiple databases
プライバシーの問題のなりすましとハイジャック辞書攻撃既知の平文攻撃攻撃攻撃攻撃交渉攻撃中期攻撃のマン認証者と認証サーバーの複数データベースの分離
Since RADIUS messages may contain the User-Name attribute as well as NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on RADIUS traffic may be able to determine the geographic location of peers in real time. In wireless networks, it is often assumed that RADIUS traffic is physically secure, since it typically travels over the wired network and that this limits the release of location information.
RADIUSメッセージにNAS-IPアドレスまたはNAS ID属性がNAS-IPアドレスまたはNAS識別子の属性を含めることができるため、RADIUSトラフィック上でスヌーピングしている攻撃者はリアルタイムでピアの地理的位置を決定することができます。無線ネットワークでは、通常は有線ネットワークを介して移動しているため、RADIUSトラフィックは物理的に安全であり、これが場所情報のリリースを制限することがしばしば想定されています。
However, it is possible for an authenticated attacker to spoof ARP packets [RFC826] so as to cause diversion of RADIUS traffic onto the wireless network. In this way an attacker may obtain RADIUS packets from which it can glean peer location information, or which it can subject to a known plaintext or offline dictionary attack. To address these vulnerabilities, implementations of this specification SHOULD use IPsec ESP with non-null transform and per-packet encryption, authentication, integrity and replay protection to protect both RADIUS authentication [RFC2865] and accounting [RFC2866] traffic, as described in Section 4.2.
ただし、ARPパケット[RFC826]が、RADIUSトラフィックをワイヤレスネットワーク上に転送するように偽装した攻撃者が可能です。このようにして、攻撃者はそれが集光ピア位置情報を集めることができる、またはそれが既知の平文またはオフライン辞書の攻撃を受けることができる半径パケットを得ることができる。これらの脆弱性に対処するために、この仕様書の実装は、4.2節で説明されているように、RADIUS認証[RFC2865]とアカウンティング[RFC2866]トラフィックの両方を保護するために、非NULL変換およびパケットごとの暗号化、認証、整合性、および再生保護を使用してIPsec ESPを使用する必要があります。。
Access-Request packets with a User-Password attribute establish the identity of both the user and the NAS sending the Access-Request, because of the way the shared secret between the NAS and RADIUS server is used. Access-Request packets with CHAP-Password or EAP-Message attributes do not have a User-Password attribute. As a result, the Message-Authenticator attribute SHOULD be used in Access-Request packets that do not have a User-Password attribute, in order to establish the identity of the NAS sending the request.
ユーザーパスワード属性を持つアクセス要求パケットは、NASサーバーとRADIUSサーバー間の共有秘密が使用されているため、ユーザーとアクセス要求を送信するNASの両方のIDを確立します。chap-passwordまたはEAP-Message属性を持つアクセス要求パケットには、ユーザーパスワード属性がありません。その結果、メッセージを送信するNASのIDを確立するために、message-authenticator属性をuser-password属性を持たないアクセス要求パケットで使用する必要があります。
An attacker may attempt to inject packets into the conversation between the NAS and the RADIUS server, or between the RADIUS server and the security server. RADIUS [RFC2865] does not support encryption other than attribute hiding. As described in [RFC2865], only Access-Reply and Access-Challenge packets are integrity protected. Moreover, the per-packet authentication and integrity protection mechanism described in [RFC2865] has known weaknesses [MD5Attack], making it a tempting target for attackers looking to subvert RADIUS/EAP.
攻撃者は、NASとRADIUSサーバー間の会話にパケットを注入しようとするか、RADIUSサーバーとセキュリティサーバーの間で攻撃します。RADIUS [RFC2865]は、属性隠蔽以外の暗号化をサポートしていません。[RFC2865]に記載されているように、アクセス応答およびアクセスチャレンジパケットのみが保護されているだけです。さらに、[RFC2865]に記載されているパケットごとの認証および完全性保護機構は、既知の弱点[MD5atCack]を有し、攻撃者がRADIUS / EAPを覆すことを検討するための魅力的なターゲットになっています。
To provide stronger security, the Message-Authenticator attribute MUST be used in all RADIUS packets containing an EAP-Message attribute. Implementations of this specification SHOULD use IPsec ESP with non-null transform and per-packet encryption, authentication, integrity and replay protection, as described in Section 4.2.
強力なセキュリティを提供するために、message-authenticator属性は、EAP-MESSAGE属性を含むすべてのRADIUSパケットで使用する必要があります。この仕様の実装は、セクション4.2で説明されているように、非ヌル変換およびパケットごとの暗号化、認証、整合性、および再生保護を使用してIPsec ESPを使用する必要があります。
The RADIUS shared secret is vulnerable to offline dictionary attack, based on capture of the Response Authenticator or Message-Authenticator attribute. In order to decrease the level of vulnerability, [RFC2865] recommends:
RADIUS共有秘密は、応答オーセンティケータまたはMessage-Authenticator属性のキャプチャに基づいて、オフライン辞書攻撃に対して脆弱です。脆弱性のレベルを下げるために、[RFC2865]をお勧めします。
The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. It is preferred that the secret be at least 16 octets.
秘密（クライアントとRADIUSサーバー間で共有されているパスワード）は、少なくとも選択されたパスワードとして、少なくとも大きく、不正なことです。秘密が少なくとも16オクテットであることが好ましい。
The risk of an offline dictionary attack can be further reduced by employing IPsec ESP with non-null transform in order to encrypt the RADIUS conversation, as described in Section 4.2.
セクション4.2で説明されているように、半径会話を暗号化するために、非ヌル変換でIPSec ESPを使用することで、オフライン辞書攻撃のリスクをさらに低減できます。
Since EAP [RFC2284] does not support PAP, the RADIUS User-Password attribute is not used to carry hidden user passwords within RADIUS/EAP conversations. The User-Password hiding mechanism, defined in [RFC2865] utilizes MD5, defined in [RFC1321], in order to generate a key stream based on the RADIUS shared secret and the Request Authenticator. Where PAP is in use, it is possible to collect key streams corresponding to a given Request Authenticator value, by capturing RADIUS conversations corresponding to a PAP authentication attempt, using a known password. Since the User-Password is known, the key stream corresponding to a given Request Authenticator can be determined and stored.
EAP [RFC2284]はPAPをサポートしていないため、RADIUS User-Password属性はRADIUS / EAP会話内の隠しユーザーパスワードを伝送するために使用されません。[RFC2865]で定義されているユーザーパスワードの非表示メカニズムは、RADIUS共有秘密とリクエストオーセンティケータに基づくキーストリームを生成するために、[RFC1321]で定義されているMD5を利用します。PAPが使用されている場合、既知のパスワードを使用して、PAP認証の試行に対応するRADIUS会話をキャプチャすることによって、特定の要求オーセンティケータ値に対応するキーストリームを収集することが可能である。ユーザパスワードは知られているので、所与の要求オーセンティケータに対応するキーストリームを決定して記憶することができる。
Since the key stream may have been determined previously from a known plaintext attack, if the Request Authenticator repeats, attributes encrypted using the RADIUS attribute hiding mechanism should be considered compromised. In addition to the User-Password attribute, which is not used with EAP, this includes attributes such as Tunnel-Password [RFC2868, section 3.5] and MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes [RFC2548, section 2.4], which include a Salt field as part of the hiding algorithm.
キーストリームは既知の平文攻撃から以前に決定されている可能性があるため、要求オーセンティケータが繰り返されると、RADIUS属性隠蔽メカニズムを使用して暗号化された属性は侵害されるべきであると見なされるべきです。EAPでは使用されていないUSER-Password属性に加えて、これには、トンネルパスワード[RFC2868、セクション3.5]、MS-MPPE-Send-KeyおよびMS-MPPE-RECVキー属性などの属性が含まれています[RFC2548、隠蔽アルゴリズムの一部として塩分畑を含むセクション2.4。
To avoid this, [RFC2865], Section 3 advises:
これを回避するために、[RFC2865]、セクション3はアドバイスします。
Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness.
異種地理的地域のサーバーで認証するために同じ秘密が使用される可能性があるので、要求オーセンティケータフィールドは世界的な一意性と時間的な一意性を示します。
Where the Request Authenticator repeats, the Salt field defined in [RFC2548], Section 2.4 does not provide protection against compromise. This is because MD5 [RFC1321], rather than HMAC-MD5 [RFC2104], is used to generate the key stream, which is calculated from the 128-bit RADIUS shared secret (S), the 128-bit Request Authenticator (R), and the Salt field (A), using the formula b(1) = MD5(S + R + A). Since the Salt field is placed at the end, if the Request Authenticator were to repeat on a network where PAP is in use, then the salted keystream could be calculated from the User-Password keystream by continuing the MD5 calculation based on the Salt field (A), which is sent in the clear.
要求オーセンティケータが繰り返される場合、[RFC2548]で定義されているSALTフィールドは、セクション2.4は妥協に対して保護を提供しません。これは、HMAC-MD5 [RFC2104]ではなくMD5 [RFC1321]が、128ビットRADIUS Shared Secret（S）、128ビット要求オーセンティケータ（R）から計算されるキーストリームを生成するために使用されるためです。式B（1）= MD5（SRA）を用いて、塩分野（A）。SALTフィールドは最後に配置されているので、PAPが使用中のネットワーク上でリクエストオーセンティケータが繰り返された場合、SALTフィールドに基づいてMD5計算を続けることによって塩漬けキーストリームをユーザーパスワードキーストリームから計算することができます（a）。これは明確に送信されます。
Even though EAP does not support PAP authentication, a security vulnerability can still exist where the same RADIUS shared secret is used for hiding User-Password as well as other attributes. This can occur, for example, if the same RADIUS proxy handles authentication requests for both EAP and PAP.
EAPがPAP認証をサポートしていなくても、同じRADIUS Shared Secretがユーザーパスワードと他の属性を隠すために使用されるセキュリティの脆弱性が存在する可能性があります。これは、たとえば、同じRADIUSプロキシがEAPとPAPの両方に対して認証要求を処理する場合に発生する可能性があります。
The threat can be mitigated by protecting RADIUS with IPsec ESP with non-null transform, as described in Section 4.2. Where RADIUS shared secrets are configured, the RADIUS shared secret used by a NAS supporting EAP MUST NOT be reused by a NAS utilizing the User-Password attribute, since improper shared secret hygiene could lead to compromise of hidden attributes.
セクション4.2で説明されているように、非ヌル変換でRADIUSをヌル以外の変換で保護することで、脅威を軽減できます。RADIUS共有秘密が設定されている場合、不適切な共有秘密衛生が隠れた属性の侵害をもたらす可能性があるため、EAPをサポートするNASで使用されているRADIUS共有秘密は、ユーザーパスワード属性を使用しているNASによって再利用されてはいけません。
The RADIUS protocol provides only limited support for replay protection. RADIUS Access-Requests include liveness via the 128-bit Request Authenticator. However, the Request Authenticator is not a replay counter. Since RADIUS servers may not maintain a cache of previous Request Authenticators, the Request Authenticator does not provide replay protection.
RADIUSプロトコルは、再生保護のための限られたサポートのみを提供します。RADIUSアクセス要求には、128ビット要求オーセンティケータを介したLIVISIVESが含まれます。ただし、要求オーセンティケータは再生カウンタではありません。RADIUSサーバは以前の要求オーセンティケータのキャッシュを維持しない可能性があるため、リクエストオーセンティケータは再生保護を提供しません。
RADIUS accounting [RFC2866] does not support replay protection at the protocol level. Due to the need to support failover between RADIUS accounting servers, protocol-based replay protection is not sufficient to prevent duplicate accounting records. However, once accepted by the accounting server, duplicate accounting records can be detected by use of the the Acct-Session-Id [RFC2866, section 5.5] and Event-Timestamp [RFC2869, section 5.3] attributes.
RADIUSアカウンティング[RFC2866]は、プロトコルレベルでの再生保護をサポートしていません。RADIUSアカウンティングサーバー間のフェイルオーバーをサポートする必要があるため、プロトコルベースの再生保護は、重複したアカウンティングレコードを防ぐのに十分ではありません。ただし、会計サーバーによって受け入れられたら、acct-session-id [RFC2866、セクション5.5]、およびevent-timestamp [RFC2869、セクション5.3]属性を使用して、重複したアカウンティングレコードを検出できます。
Unlike RADIUS authentication, RADIUS accounting does not use the Request Authenticator as a nonce. Instead, the Request Authenticator contains an MD5 hash calculated over the Code, Identifier, Length, and request attributes of the Accounting Request packet, plus the shared secret. The Response Authenticator also contains an MD5 hash calculated over the Code, Identifier and Length, the Request Authenticator field from the Accounting-Request packet being replied to, the response attributes and the shared secret.
RADIUS認証とは異なり、RADIUSアカウンティングは要求オーセンティケータをNONCEとして使用しません。代わりに、要求オーセンティケータには、アカウンティング要求パケットのコード、識別子、長さ、および要求属性に加えて、共有秘密が計算されたMD5ハッシュが含まれています。応答オーセンティケータは、コード、識別子および長さで計算されたMD5ハッシュ、録音要求パケットからの要求オーセンティケータフィールド、応答属性と共有秘密に渡されたMD5ハッシュを含みます。
Since the Accounting Response Authenticator depends in part on the Accounting Request Authenticator, it is not possible to replay an Accounting-Response unless the Request Authenticator repeats. While it is possible to utilize EAP methods such as EAP TLS [RFC2716] which include liveness checks on both sides, not all EAP messages will include liveness so that this provides incomplete protection.
アカウンティングレスポンスオーセンティケータは、アカウンティング要求オーセンティケータに部分的に依存するため、要求オーセンティケータが繰り返されない限り、アカウンティング応答を再生することはできません。両側でのLivessチェックを含むEAP TLS [RFC2716]のようなEAPメソッドを利用することは可能です。これにより、不完全な保護が可能になるため、すべてのEAPメッセージには活性が含まれません。
Strong replay protection for RADIUS authentication and accounting can be provided by enabling IPsec replay protection with RADIUS, as described in Section 4.2.
RADIUS認証および会計の強力な再生保護は、セクション4.2で説明されているように、RADIUSを使用してIPSecの再生保護を有効にすることで提供できます。
In a negotiation attack a rogue NAS, tunnel server, RADIUS proxy or RADIUS server attempts to cause the authenticating peer to choose a less secure authentication method. For example, a session that would normally be authenticated with EAP would instead be authenticated via CHAP or PAP; alternatively, a connection that would normally be authenticated via a more secure EAP method such as EAP-TLS [RFC2716] might be made to occur via a less secure EAP method, such as MD5-Challenge. The threat posed by rogue devices, once thought to be remote, has gained currency given compromises of telephone company switching systems, such as those described in [Masters].
交渉攻撃では、不正なNAS、Tunnel Server、RADIUS ProxyまたはRADIUSサーバーが認証ピアに安全性の低い認証方法を選択させようとします。たとえば、EAPでは通常認証されるセッションは、代わりにCHAPまたはPAPを介して認証されます。あるいは、EAP-TLS [RFC2716]のようなより安全なEAPメソッドを介して認証される接続は、MD5チャレンジなどの安全なEAPメソッドを介して発生するようになります。不正な機器によって提起された脅威は、一度リモートであると考えられている、[マスターズ]に記載されているもののような電話会社の交換システムの妥協の通貨を獲得しました。
Protection against negotiation attacks requires the elimination of downward negotiations. The RADIUS exchange may be further protected by use of IPsec, as described in Section 4.2. Alternatively, where IPsec is not used, the vulnerability can be mitigated via implementation of per-connection policy on the part of the authenticating peer, and per-peer policy on the part of the RADIUS server. For the authenticating peer, authentication policy should be set on a per-connection basis. Per-connection policy allows an authenticating peer to negotiate a strong EAP method when connecting to one service, while negotiating a weaker EAP method for another service.
交渉攻撃に対する保護は、下向き交渉の排除を必要とします。RADIUS Exchangeは、セクション4.2で説明されているように、IPSecを使用することによってさらに保護されてもよい。あるいは、IPSecが使用されていない場合、認証ピアの一部で、Aserキーを経て、RADIUSサーバの一部にピアごとのポリシーの実装を介して脆弱性を軽減できます。認証ピアの場合、認証ポリシーは接続ごとに設定されます。接続ごとのポリシーでは、認証ピアが1つのサービスに接続するときに強力なEAPメソッドをネゴシエートできますが、別のサービスのための弱いEAPメソッドをネゴシエーションします。
With per-connection policy, an authenticating peer will only attempt to negotiate EAP for a session in which EAP support is expected. As a result, there is a presumption that an authenticating peer selecting EAP requires that level of security. If it cannot be provided, it is likely that there is some kind of misconfiguration, or even that the authenticating peer is contacting the wrong server. Should the NAS not be able to negotiate EAP, or should the EAP-Request sent by the NAS be of a different EAP type than what is expected, the authenticating peer MUST disconnect. An authenticating peer expecting EAP to be negotiated for a session MUST NOT negotiate a weaker method, such as CHAP or PAP. In wireless networks, the service advertisement itself may be spoof-able, so that an attacker could fool the peer into negotiating an authentication method suitable for a less secure network.
接続ごとのポリシーでは、認証ピアはEAPサポートが予想されるセッションのEAPをネゴシエートしようとします。その結果、EAPを選択する認証ピアがそのレベルのセキュリティを必要とするという推定があります。提供できない場合は、ある種の誤構成がある場合、または認証ピアが間違ったサーバーに連絡している可能性があります。NASがEAPをネゴシエートできない場合、またはNASによって送信されたEAP-Requestが予想されるものとは異なるEAPタイプである場合は、認証ピアが切断されなければなりません。EAPがセッションのためにネゴシエートされることを期待している認証ピアは、CHAPやPAPなどの弱いメソッドをネゴシエートしてはなりません。無線ネットワークでは、サービス広告自体がスプーフ可能である可能性があるので、攻撃者は、より少ない安全なネットワークに適した認証方法を交渉するためにピアを欺くことができる。
For a NAS, it may not be possible to determine whether a peer is required to authenticate with EAP until the peer's identity is known. For example, for shared-uses NASes it is possible for one reseller to implement EAP while another does not. Alternatively, some peer might be authenticated locally by the NAS while other peers are authenticated via RADIUS. In such cases, if any peers of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every session. This avoids forcing a peer to support more than one authentication type, which could weaken security.
NASの場合、ピアのIDがわかるまで、ピアがEAPで認証する必要があるかどうかを判断することはできません。たとえば、Shared-Asse-Naseの場合、1つのリセラーが別のリセラーがEAPを実装していない可能性があります。あるいは、いくつかのピアはNASによってローカルに認証され、他のピアは半径を介して認証されます。そのような場合、NASのピアがEAPを実行する必要がある場合、NASはセッションごとにEAPをネゴシエートしようとしなければなりません。これにより、ピアが複数の認証タイプをサポートするようにピアを強制することができ、セキュリティを弱める可能性があります。
If CHAP is negotiated, the NAS will pass the User-Name and CHAP-Password attributes to the RADIUS server in an Access-Request packet. If the peer is not required to use EAP, then the RADIUS server will respond with an Access-Accept or Access-Reject packet as appropriate. However, if CHAP has been negotiated but EAP is required, the RADIUS server MUST respond with an Access-Reject, rather than an Access-Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST refuse to renegotiate authentication, even if the renegotiation is from CHAP to EAP.
CHAPがネゴシエートされている場合、NASはアクセス要求パケット内のRADIUSサーバにユーザ名とCHAPパスワード属性を渡します。ピアがEAPを使用する必要がない場合、RADIUSサーバは必要に応じてアクセス許可またはアクセス拒否パケットで応答します。ただし、CHAPがネゴシエートされているがEAPが必要な場合、RADIUSサーバはアクセスチャレンジ/ EAP - MESSAGE / EAP要求パケットではなく、アクセス拒否で応答する必要があります。認証ピアは、再ネゴシエーションがCHAPからEAPへのものであっても認証の再認証を拒否する必要があります。
If EAP is negotiated but is not supported by the RADIUS proxy or server, then the server or proxy MUST respond with an Access-Reject. In these cases, a PPP NAS MUST send an LCP-Terminate and disconnect the peer. This is the correct behavior since the authenticating peer is expecting EAP to be negotiated, and that expectation cannot be fulfilled. An EAP-capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP had initially been negotiated. Note that problems with a non-EAP capable RADIUS proxy could prove difficult to diagnose, since a peer connecting from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same peer connecting at another location (and encountering an EAP-incapable proxy) might be consistently disconnected.
EAPがネゴシエートされているがRADIUSプロキシまたはサーバでサポートされていない場合、サーバまたはプロキシはアクセス拒否で応答する必要があります。このような場合、PPP NASはLCP終端を送信してピアを切断しなければなりません。認証ピアがEAPを交渉することを期待しているため、これは正しい動作であり、その期待を満たすことはできません。EAPが最初にネゴシエートされていた場合、EAP対応認証ピアは認証プロトコルを再交渉することを拒否しなければなりません。1つの場所から（EAP対応プロキシで）接続するピアがEAPを介して正常に認証でき、同じピアが別の場所に接続できる間、EAP対応のRADIUSプロキシの問題が困難である可能性があることに注意してください。そして、EAP-不可能なプロキシを遭遇する可能性があります。
[RFC2865] Section 3 states:
[RFC2865]セクション3の状態
A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.
RADIUSサーバは、RADIUS UDPパケットの送信元IPアドレスを使用して、どの共有秘密を使用するかを決定する必要があるため、RADIUS要求をプロキシすることができます。
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address attributes may not match the source address. Since the NAS-Identifier attribute need not contain an FQDN, this attribute also may not correspond to the source address, even indirectly, with or without a proxy present.
RADIUS要求がプロキシによって転送されると、NAS-IPアドレスまたはNAS-IPv6アドレス属性はソースアドレスと一致しない可能性があります。NAS-ID属性にはFQDNが含まれていないため、この属性はまた、プロキシが存在する場合でも間接的にさえ、ソースアドレスにも対応していない可能性があります。
As a result, the authenticity check performed by a RADIUS server or proxy does not verify the correctness of NAS identification attributes. This makes it possible for a rogue NAS to forge NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within a RADIUS Access-Request in order to impersonate another NAS. It is also possible for a rogue NAS to forge session identification attributes such as Called-Station-Id, Calling-Station-Id, and Originating-Line-Info.
その結果、RADIUSサーバまたはプロキシによって実行される認証チェックは、NAS識別属性の正当性を検証しない。これにより、別のNASを偽装するために、RADIUSアクセス要求内のNAS - IPアドレス、NAS - IPv6アドレスまたはNAS識別子属性をフォジェットすることが可能になる。ローグNASが、呼び出されたステーションID、呼び出し局ID、および発信元情報などのセッション識別属性を偽造することも可能である。
This could fool the RADIUS server into subsequently sending Disconnect or CoA-Request messages [RFC3576] containing forged session identification attributes to a NAS targeted by an attacker.
これは、RADIUSサーバを、攻撃者のターゲットをターゲットにしたNASに求められたセッション識別属性を含む[RFC3576]を、その後切断またはCOA要求メッセージを送信することができる。
To address these vulnerabilities RADIUS proxies SHOULD check whether NAS identification attributes (NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier) match the source address of packets originating from the NAS. Where a match is not found, an Access-Reject SHOULD be sent, and an error SHOULD be logged.
これらの脆弱性に対処するためにRADIUSプロキシは、NAS識別属性（NAS-IPアドレス、NAS-IPv6アドレス、NAS識別子）がNASから発信されたパケットの送信元アドレスに一致するかどうかを確認する必要があります。一致が見つからない場合は、アクセス不良を送信し、エラーを記録する必要があります。
However, such a check may not always be possible. Since the NAS-Identifier attribute need not correspond to an FQDN, it may not be resolvable to an IP address to be matched against the source address. Also, where a NAT exists between the RADIUS client and proxy, checking the NAS-IP-Address or NAS-IPv6-Address attributes may not be feasible.
しかしながら、そのようなチェックは必ずしも可能ではないかもしれない。NAS識別子属性はFQDNに対応する必要はないため、送信元アドレスと一致するIPアドレスに解決可能ではない可能性があります。また、NATがRADIUSクライアントとプロキシの間に存在する場合は、NAS-IPアドレスまたはNAS-IPv6アドレス属性を確認できない可能性があります。
To allow verification of NAS and session identification parameters,
EAP methods can support the secure exchange of these parameters
between the EAP peer and EAP server. NAS identification attributes
include NAS-IP-Address, NAS-IPv6-Address and Called-Station-Id;
session identification attributes include User-Name and
Calling-Station-Id. The secure exchange of these parameters between
the EAP peer and server enables the RADIUS server to check whether
the attributes provided by the NAS match those provided by the peer;
similarly, the peer can check the parameters provided by the NAS
against those provided by the EAP server. This enables detection of
a rogue NAS.
RADIUS only provides security on a hop-by-hop basis, even where IPsec is used. As a result, an attacker gaining control of a RADIUS proxy could attempt to modify EAP packets in transit. To protect against this, EAP methods SHOULD incorporate their own per-packet integrity protection and authentication mechanisms.
RADIUSは、IPSecが使用されていても、ホップごとにセキュリティを提供します。その結果、RADIUSプロキシを制御する攻撃者は、輸送中のEAPパケットを変更しようとする可能性があります。これを保護するために、EAPメソッドは自分のパケットごとの整合性保護と認証メカニズムを組み込む必要があります。
As noted in [RFC2716], it is possible for the EAP peer and authenticator to mutually authenticate, and derive a Master Session Key (MSK) for a ciphersuite used to protect subsequent data traffic. This does not present an issue on the peer, since the peer and EAP client reside on the same machine; all that is required is for the EAP client module to derive and pass a Transient Session Key (TSK) to the ciphersuite module.
[RFC2716]で述べたように、EAPピアおよびオーセンティケータが相互に認証され、後続のデータトラフィックを保護するために使用される暗号スイートのマスターセッションキー（MSK）を導出することが可能です。ピアクライアントとEAPクライアントは同じマシン上にあるため、これはピア上の問題はありません。必要なのは、EAPクライアントモジュールが暗号セッションキー（TSK）を暗号化モジュールに導き出して渡すことです。
The situation is more complex when EAP is used with RADIUS, since the authenticator and authentication server may not reside on the same host.
オーセンティケータと認証サーバーは同じホスト上に存在しないため、EAPがRADIUSで使用されている場合、状況はより複雑です。
In the case where the authenticator and authentication server reside on different machines, there are several implications for security. First, mutual authentication will occur between the peer and the authentication server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to, using EAP alone.
オーセンティケータと認証サーバが異なるマシンに存在する場合、セキュリティにはいくつかの影響があります。まず、ピアとオーセンティケータ間ではなく、ピアと認証サーバ間で相互認証が行われる。つまり、ピアは、EAP単独を使用して、発話しているNASまたはTunnel ServerのIDを検証できないことを意味します。
As described in Section 4.2, when RADIUS/EAP is used to encapsulate EAP packets, IPsec SHOULD be used to provide per-packet authentication, integrity, replay protection and confidentiality. The Message-Authenticator attribute is also required in RADIUS Access-Requests containing an EAP-Message attribute sent from the NAS or tunnel server to the RADIUS server. Since the Message-Authenticator attribute involves an HMAC-MD5 message integrity check, it is possible for the RADIUS server to verify the integrity of the Access-Request as well as the NAS or tunnel server's identity, even where IPsec is not used. Similarly, Access-Challenge packets containing an EAP-Message attribute sent from the RADIUS server to the NAS are also authenticated and integrity protected using an HMAC-MD5 message integrity check, enabling the NAS or tunnel server to determine the integrity of the packet and verify the identity of the RADIUS server, even where IPsec is not used. Moreover, EAP packets sent using methods that contain their own integrity protection cannot be successfully modified by a rogue NAS or tunnel server.
4.2節で説明されているように、RADIUS / EAPを使用してEAPパケットをカプセル化するときに、パケットごとの認証、整合性、再生保護、および機密性を提供するためにIPsecを使用する必要があります。 message-authenticator属性は、NASまたはTunnel ServerからRADIUSサーバーに送信されたEAP-Message属性を含むRADIUSアクセス要求でも必要です。 message-authenticator属性はHMAC-MD5メッセージの整合性チェックを含みますので、RADIUSサーバーは、IPsecが使用されていない場合でも、アクセス要求の整合性とNASまたはTunnel Serverの識別情報を検証できます。同様に、RADIUSサーバーからNASに送信されたEAP-MESSAGE属性を含むアクセスチャレンジパケットも、HMAC-MD5メッセージ整合性チェックを使用して認証され、NASまたはTunnel Serverがパケットの整合性を判別できるようにします。 IPsecが使用されていない場合でも、RADIUSサーバーの識別情報。さらに、独自のIntegrity Protectionを含むメソッドを使用して送信されたEAPパケットは、不正なNASまたはトンネルサーバーによって正常に変更できません。
The second issue that arises where the authenticator and authentication server reside on separate hosts is that the EAP Master Session Key (MSK) negotiated between the peer and authentication server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the MSK from the authentication server to the NAS or tunnel server that needs it. The specification of the key transport and wrapping mechanism is outside the scope of this document. However, it is expected that the wrapping mechanism will provide confidentiality, integrity and replay protection, and data origin authentication.
オーセンティケータと認証サーバが別々のホスト上に存在する場合に発生する第2の問題は、ピアと認証サーバとの間で交渉されたEAPマスターセッションキー（MSK）がオーセンティケータに送信される必要があることである。したがって、MSKを認証サーバからNASまたはトンネルサーバに送信するためにメカニズムを提供する必要があります。キートランスポートと折り返しメカニズムの仕様は、この文書の範囲外です。ただし、ラッピングメカニズムは機密性、整合性、再生保護、およびデータ原点認証を提供することが予想されます。
In many cases a security server will be deployed along with a RADIUS server in order to provide EAP services. Unless the security server also functions as a RADIUS server, two separate user databases will exist, each containing information about the security requirements for the user. This represents a weakness, since security may be compromised by a successful attack on either of the servers, or their databases. With multiple user databases, adding a new user may require multiple operations, increasing the chances for error. The problems are further magnified in the case where user information is also being kept in an LDAP server. In this case, three stores of user information may exist.
多くの場合、EAPサービスを提供するためにSecurity ServerがRADIUSサーバーと一緒に展開されます。Security ServerがRADIUSサーバーとしても機能しない限り、それぞれがユーザーのセキュリティ要件に関する情報を含む2つの別々のユーザーデータベースが存在します。セキュリティは、いずれかのサーバー、またはデータベースに対する攻撃が成功したことによって危険にさらされる可能性があるため、これは弱さを表します。複数のユーザーデータベースを使用すると、新しいユーザーを追加すると複数の操作が必要な場合があり、エラーのチャンスを増やします。ユーザ情報もLDAPサーバに保持されている場合には、問題がさらに拡大されている。この場合、3枚のユーザ情報が存在する可能性がある。
In order to address these threats, consolidation of databases is recommended. This can be achieved by having both the RADIUS server and security server store information in the same database; by having the security server provide a full RADIUS implementation; or by consolidating both the security server and the RADIUS server onto the same machine.
これらの脅威に対処するために、データベースの統合をお勧めします。これは、RADIUSサーバとセキュリティサーバの両方が同じデータベースに情報を格納することによって達成することができる。セキュリティサーバーを完全なRADIUS実装を提供させることによって。またはセキュリティサーバーとRADIUSサーバーの両方を同じマシンに統合することによって。
This specification does not create any new registries, or define any new RADIUS attributes or values.
この仕様は、新しいレジストリを作成したり、新しいRADIUS属性や値を定義しません。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージ - ダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.およびR. Canetti、「HMAC：メッセージ認証用鍵付きハッシング」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、RFC 2279、1998年1月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284] Blunk、L.およびJ.Vollbrecht、「PPP Extensible Authentication Protocol（EAP）」、RFC 2284、1998年3月。
[RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Atkinson、R.およびS. Kent、1998年11月、RFC 2401、RFC 2401。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.およびR.Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D.およびD. Carrel、「インターネット鍵交換（IKE）」、RFC 2409、1998年11月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486] Aboba、B.およびM.ビーズル、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C、Willens、S.、Rubens、A.およびW.Simpson、「ユーザーサービスのリモート認証ダイヤル（RADIUS）」、RFC 2865、2000年6月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V.およびM. Allman、2000年11月、「TCPの再送信タイマーのコンピューティング」、RFC 2988。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6", RFC 3162, August 2001.
[RFC3162] Aboba、B、Zorn、G.およびD. Mitton、 "Radius and IP6"、RFC 3162、2001年8月。
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]ホームリー、R.、Polk、W.、Ford、W.およびD. Solo、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 3280、2002年4月。
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3576]千葉、M.、Dommety、G.、Eklund、M.、Mitton、D.およびB. Aboba、「ユーザーサービス（RADIUS）の動的認証拡張（RADIUS）」、RFC 3576、2003年7月。
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982.
[RFC826] Plummer、D.、「イーサネットアドレス解決プロトコル」、STD 37、RFC 826、1982年11月。
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510] Kohl、J.およびC. Neuman、「Kerberosネットワーク認証サービス（V5）」、RFC 1510、1993年9月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] SimpSon、W.、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548] Zorn、G.、「マイクロソフトベンダー固有のRADIUS属性」、RFC 2548、1999年3月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B.およびJ.Vollbrecht、「ローミングのプロキシ連鎖および政策実施」、RFC 2607、1999年6月。
[RFC2716] Aboba, B. and D. Simon,"PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716] Aboba、B.およびD. Simon、「PPP EAP TLS認証プロトコル」、RFC 2716、1999年10月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] RFC 2866、2000年6月のRFC2866。
[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867] Zorn、G.、Aboba、B.およびD. Mitton、RFC 2867、2000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868] Zorn、G.、Leifer、D.、Rubens、A.、Shiver、J.、Holdrege、M.およびI。Goyret、「Tunnel Protocol SupportsのためのRADIUS属性」、RFC 2868、2000年6月。
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W。およびP.Calhoun、「Radius Extensions」、RFC 2869、2000年6月。
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、D.「差別化サービスとトンネル」、RFC 2983、2000年10月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580] Congdon、P.、Apoba、B.、Smith、A.、Zorn、G.およびJ. Roese、「IEEE 802.1Xリモート認証ダイヤルインユーザーサービス（RADIUS）使用ガイドライン（RADIUS）使用ガイドライン（RFC 3580、2003年9月）。
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE802]地元およびメトロポリタン地域ネットワークのIEEE規格：概要と建築、ANSI / IEEE STD 802,1990。
[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001.
[IEEE8021X]地元および首都圏ネットワークのIEEE規格：ポートベースのネットワークアクセス制御、IEEE STD 802.1X-2001、2001年6月。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[MD5ATTACK] DOBBERTIN、H。、「最近の攻撃後のMD5の状態」、暗号型Vol.2 No.2、1996年夏。
[Masters] Slatalla, M. and J. Quittner, "Masters of Deception." HarperCollins, New York, 1995.
[マスターズ] Slatalla、M.およびJ.Quittner、「詐欺のマスター」HarperCollins、ニューヨーク、1995年。
[NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", Work in Progress.
[NASREQ] Calhoun、P.ら、「Diameter Network Access Server Application」、進行中の作業。
Appendix A - Examples
付録A - 例
The examples below illustrate conversations between an authenticating peer, NAS, and RADIUS server. The OTP and EAP-TLS protocols are used only for illustrative purposes; other authentication protocols could also have been used, although they might show somewhat different behavior.
以下の例は、認証ピア、NAS、およびRADIUSサーバー間の会話を示しています。OTPおよびEAP-TLSプロトコルは説明の目的でのみ使用されます。他の認証プロトコルも使用されている可能性がありますが、多少異なる動作を示す可能性があります。
Where the NAS sends an EAP-Request/Identity as the initial packet, the exchange appears as follows:
NASが初期パケットとしてEAP要求/ IDを送信する場合、Exchangeは次のように表示されます。
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
In the case where the NAS initiates with an EAP-Request for EAP TLS [RFC2716], and the identity is determined based on the contents of the client certificate, the exchange will appear as follows:
NASがEAP TLS [RFC2716]のEAP-REQUESTで開始され、クライアント証明書の内容に基づいてIDが決定された場合は、次のように表示されます。
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Challenge/
EAP-Message/
EAP-Request/
EAP-Type=EAP-TLS
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Challenge/
EAP-Message/
EAP-Request/
EAP-Type=EAP-TLS
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
In the case where the NAS first sends an EAP-Start packet to the RADIUS server, the conversation would appear as follows:
NASが最初にEAP-STARTパケットをRADIUSサーバーに送信する場合、会話は次のように表示されます。
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Identity (MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
In the case where the NAS initiates with an EAP-Request for EAP TLS [RFC2716], but the peer responds with a Nak, indicating that it would prefer another method not implemented locally on the NAS, the exchange will appear as follows:
NASがEAP TLS [RFC2716]のEAP-REQUESTで開始されている場合、PEARはNASでは別のメソッドが実行されないことを示していることを示していますが、そのExchangeは次のように表示されます。
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=Nak
(Alternative(s))->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Nak ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
In the case where the authenticating peer attempts to authenticate the NAS, the conversation would appear as follows:
認証ピアがNASの認証を試みる場合、会話は次のように表示されます。
Authenticating peer NAS RADIUS Server
------------------- --- -------------
EAP-Request/
Challenge, MD5 ->
RADIUS Access-Request/
EAP-Message/EAP-Request/
Challenge, MD5 ->
<- RADIUS
Access-Reject/
EAP-Message/
EAP-Response/
Nak (no alternative)
<- EAP-Response/Nak (no alternative) EAP-Failure ->
< - EAP対応/ NAK（代替理由）EAP障害 - >
In the case where an invalid EAP Response is inserted by an attacker, the conversation would appear as follows:
無効なEAP応答が攻撃者によって挿入されている場合、会話は次のように表示されます。
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=Foo
EAP-Response/
EAP-Type=Foo ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Foo ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
EAP-Type=Foo
<- EAP-Request/
EAP-Type=Foo
Attacker spoof:
EAP-Response/
EAP-Type=Bar ->
Good guy:
EAP-Response/
EAP-Type=Foo ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Bar ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
EAP-Type=Foo,
Error-Cause="Invalid EAP
Packet (Ignored)"
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Foo ->
<- Access-Accept/
EAP-Message/Success
<- EAP Success
In the case where the client fails EAP authentication, and an error message is sent prior to disconnection, the conversation would appear as follows:
クライアントがEAP認証に失敗し、切断前にエラーメッセージが送信された場合、会話は次のように表示されます。
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Response/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Notification
<- EAP-Request/
Notification
EAP-Response/
Notification ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Notification ->
<- RADIUS
Access-Reject/
EAP-Message/EAP-Failure
<- EAP-Failure
(client disconnected)
In the case that the RADIUS server or proxy does not support EAP-Message, but no error message is sent, the conversation would appear as follows:
RADIUSサーバまたはプロキシがEAP - メッセージをサポートしていない場合は、エラーメッセージが送信されていない場合、会話は次のように表示されます。
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Reject
(User Disconnected)
In the case where the local RADIUS server does support EAP-Message, but the remote RADIUS server does not, the conversation would appear as follows:
ローカルRADIUSサーバーがEAP-MESSAGEをサポートしているがリモートRADIUSサーバが検出しない場合、会話は次のように表示されます。
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/
EAP-Response/
Identity
<- EAP-Request/
Identity
EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Reject (proxied from remote RADIUS server) (User Disconnected)
EAP-Response / Identity（MyID） - > RADIUS ACCESS-REQUEST / EAP-MESSAGE /（MYID） - > < - RADIUS ACCESS-REJECT（リモートRADIUSサーバーからプロキシ）（ユーザー切断）
In the case where PPP is the link and the authenticating peer does not support EAP, but where EAP is required for that user, the conversation would appear as follows:
PPPがリンクで、認証ピアがEAPをサポートしていない場合は、そのユーザーにEAPが必要な場合は、次のように表示されます。
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP NAK-EAP
auth ->
<- PPP LCP Request-CHAP
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)
In the case where PPP is the link, the NAS does not support EAP, but where EAP is required for that user, the conversation would appear as follows:
PPPがリンクである場合、NASはEAPをサポートしませんが、そのユーザーにEAPが必要な場合は、次のように表示されます。
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- PPP LCP Request-CHAP
auth
PP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password ->
PP LCP ACK-CHAP AUTH - > < - PPP CHAPチャレンジPPP CHAP応答 - > RADIUSアクセス要求/ユーザ名、CHAP-Password - >
<- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)
< - RADIUS ACCESS-REJECT < - PPP LCP終端（ユーザー切断）
Appendix B - Change Log
付録B - ログ変更
The following changes have been made from RFC 2869:
以下の変更はRFC 2869から行われています。
A NAS may simultaneously support both local authentication and pass-through; once the NAS enters pass-through mode within a session, it cannot revert back to local authentication. Also EAP is explicitly described as a 'lock step' protocol. (Section 2).
NASは、ローカル認証とパススルーの両方を同時にサポートすることがあります。セッション内でNASがパススルーモードに入ると、ローカル認証に戻ることはできません。また、EAPは「ロックステップ」プロトコルとして明示的に説明されています。（第2節）。
The NAS may initiate with an EAP-Request for an authentication Type. If the Request is NAK'd, the NAS should send an initial Access-Request with an EAP-Message attribute containing an EAP-Response/Nak.
NASは、認証タイプのEAP要求で開始される可能性があります。要求がNAK'Dの場合、NASはEAP-Response / NAKを含むEAP-MESSAGE属性を使用して最初のアクセス要求を送信する必要があります。
The RADIUS server may treat an invalid EAP Response as a non-fatal error (Section 2.2)
RADIUSサーバは無効なEAP応答を致命的でないエラーとして扱うことがあります（セクション2.2）。
For use with RADIUS/EAP, the Password-Retry (Section 2.3) and Reply-Message (2.6.5) attributes are deprecated.
RADIUS / EAPで使用するには、パスワード再試行（セクション2.3）と応答メッセージ（2.6.5）属性が推奨されません。
Each EAP session has a unique Identifier space (Section 2.6.1).
各EAPセッションには一意の識別子スペースがあります（セクション2.6.1）。
Role reversal is not supported (Section 2.6.2).
役割の逆転はサポートされていません（セクション2.6.2）。
Message combinations (e.g. Access-Accept/EAP-Failure) that conflict are discouraged (Section 2.6.3).
競合が推奨されるメッセージの組み合わせ（例えば、アクセス承認/ EAP障害）。
Only a single EAP packet may be encapsulated within a RADIUS message (Section 3.1).
RADIUSメッセージ内にカプセル化されてもよいし、単一のEAPパケットのみがカプセル化されてもよい（セクション3.1）。
An Access-Request lacking explicit authentication as well as a Message- Authenticator attribute SHOULD be silently discarded (Section 3.3).
明示的な認証とMessage-Authenticator属性を欠いているアクセス要求は、黙って破棄されるべきです（セクション3.3）。
The Originating-Line-Info attribute is supported (Section 3.3).
発信元-info属性がサポートされています（セクション3.3）。
IPsec ESP with non-null transform SHOULD be used and the usage model is described in detail (Section 4.2).
NULL以外の変換を伴うIPsec ESPを使用し、使用モデルについて詳しく説明します（セクション4.2）。
Additional discussion of security vulnerabilities (Section 4.1) and potential fixes (Section 4.3).
セキュリティ上の脆弱性（4.1項）と潜在的な修正に関する追加の議論（セクション4.3）。
Separated normative (Section 6.1) and informative (Section 6.2) references.
規範（6.1節）と有益な（6.2節）参照。
Added additional examples (Appendix A): a NAS initiating with an EAP-Request for an authentication Type; attempted role reversal.
追加の例を追加しました（付録A）：認証タイプのEAP-Requestで開始するNAS。ロールのリバースを試みました。
Intellectual Property Statement
知的財産ステートメント
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
この文書に記載されているテクノロジの実装または使用に関連すると主張される可能性がある、またはそのような権利の下でのライセンスの使用に関連すると主張される可能性がある、またはそのような権利の下にある範囲内である可能性があると主張される可能性がある、IETFは、あるいはその他の権利の使用に関連している可能性がある、またはその他の権利の有効性または範囲に関する役割を果たしていません。利用可能です。それは、そのような権利を特定するために努力をしたことを表していません。標準トラックおよび標準関連のマニュアルにおける権利に関するIETFの手順に関する情報は、BCP-11にあります。公開可能な権利の特許請求の課題および利用可能なライセンスの保証、またはこの仕様書の実装者またはユーザによるそのような独自の権利を使用するための一般的なライセンスまたは許可を得るための試みの結果を得ることができる。IETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、著作権、特許または特許出願、またはこの規格を実践することが要求される可能性がある技術をカバーする可能性のある他の独自の権利を注意するように興味のある当事者を勧めます。IETFエグゼクティブディレクターに情報を取り扱ってください。
Acknowledgments
謝辞
Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco Systems, Jari Arkko of Ericsson and Ashwin Palekar, Tim Moore and Narendra Gidwani of Microsoft for useful discussions of this problem space. The authors would also like to acknowledge Tony Jeffree, Chair of IEEE 802.1 for his assistance in resolving RADIUS/EAP issues in IEEE 802.1X-2001.
Dave DawsonとKarl FoxのAscend、Cisco SystemsのGlen ZornのGlen Zorn、Ericsson and Ashwin PalekarのJari Arkko、Tim Moore、MicrosoftのNarendra Gidwani。著者らはまた、IEEE 802.1X-2001におけるRADIUS / EAP問題の解決における彼の支援のために、Tony Jeffreeを承認したいと考えています。
Authors' Addresses
著者の住所
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation 1つのMicrosoft Way Redmond、WA 98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Pat R. Calhoun Airespace 110 Nortech Parkway San Jose, California, 95134 USA
パットR. Calhoun Airespace 110 Nortech Parkway San Jose、カリフォルニア、95134 USA
Phone: +1 408 635 2023
Fax: +1 408 635 2020
EMail: pcalhoun@airespace.com
Full Copyright Statement
完全著作権宣言
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット社会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書と翻訳はコピーされている可能性があり、他の文書にはコピーされ、その実装を説明するか、またはその実装を説明するか、またはその実装を支援することができ、コピーされ、公開され、分散され、すべての種類の制限なしに準備、コピー上記の著作権通知とこの段落がそのようなすべてのコピーや派生的な作品に含まれているとしました。ただし、この文書自体は、インターネット規格を開発するために必要な場合を除き、インターネット社会や他のインターネット組織への参照を削除するなど、著作権社会やその他のインターネット組織への参照を除去することはできません。インターネット標準プロセスに従う必要があるか、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた権限は永続的であり、インターネット社会やその後継者または担当者によって取り消されません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本明細書に含まれる情報は、「現状」ベースで提供されており、インターネット社会とインターネットエンジニアリングのタスクフォースは、本明細書の情報の使用が含まれないことを含むが、これに限定されない、またはこれに限定されないすべての保証を損なう。特定の目的のための商品性または適合性の権利または黙示的な保証を侵害する。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。