[要約] RFC 3748は、拡張可能な認証プロトコル（EAP）に関する仕様であり、EAPの目的は、ネットワーク上でのセキュアな認証を可能にすることです。
Network Working Group B. Aboba
Request for Comments: 3748 Microsoft
Obsoletes: 2284 L. Blunk
Category: Standards Track Merit Network, Inc
J. Vollbrecht
Vollbrecht Consulting LLC
J. Carlson
Sun
H. Levkowetz, Ed.
ipUnplugged
June 2004
Extensible Authentication Protocol (EAP)
拡張可能な認証プロトコル（EAP）
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.
このドキュメントでは、複数の認証方法をサポートする認証フレームワークである拡張可能な認証プロトコル（EAP）を定義します。EAPは通常、IPを必要とせずに、ポイントツーポイントプロトコル（PPP）やIEEE 802などのデータリンクレイヤーを直接実行します。EAPは、重複の排除と再送信に対する独自のサポートを提供しますが、下層の順序付け保証に依存しています。断片化はEAP自体内ではサポートされていません。ただし、個々のEAPメソッドはこれをサポートする場合があります。
This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A.
このドキュメントはRFC2284を廃止します。このドキュメントとRFC 2284の間の変更の要約は、付録Aに入手できます。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 6
2. Extensible Authentication Protocol (EAP). . . . . . . . . . . 7
2.1. Support for Sequences . . . . . . . . . . . . . . . . . 9
2.2. EAP Multiplexing Model. . . . . . . . . . . . . . . . . 10
2.3. Pass-Through Behavior . . . . . . . . . . . . . . . . . 12
2.4. Peer-to-Peer Operation. . . . . . . . . . . . . . . . . 14
3. Lower Layer Behavior. . . . . . . . . . . . . . . . . . . . . 15
3.1. Lower Layer Requirements. . . . . . . . . . . . . . . . 15
3.2. EAP Usage Within PPP. . . . . . . . . . . . . . . . . . 18
3.2.1. PPP Configuration Option Format. . . . . . . . . 18
3.3. EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . 19
3.4. Lower Layer Indications . . . . . . . . . . . . . . . . 19
4. EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Request and Response. . . . . . . . . . . . . . . . . . 21
4.2. Success and Failure . . . . . . . . . . . . . . . . . . 23
4.3. Retransmission Behavior . . . . . . . . . . . . . . . . 26
5. Initial EAP Request/Response Types. . . . . . . . . . . . . . 27
5.1. Identity. . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Notification. . . . . . . . . . . . . . . . . . . . . . 29
5.3. Nak . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . 31
5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . 32
5.4. MD5-Challenge . . . . . . . . . . . . . . . . . . . . . 35
5.5. One-Time Password (OTP) . . . . . . . . . . . . . . . . 36
5.6. Generic Token Card (GTC). . . . . . . . . . . . . . . . 37
5.7. Expanded Types. . . . . . . . . . . . . . . . . . . . . 38
5.8. Experimental. . . . . . . . . . . . . . . . . . . . . . 40
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
6.1. Packet Codes. . . . . . . . . . . . . . . . . . . . . . 41
6.2. Method Types. . . . . . . . . . . . . . . . . . . . . . 41
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
7.1. Threat Model. . . . . . . . . . . . . . . . . . . . . . 42
7.2. Security Claims . . . . . . . . . . . . . . . . . . . . 43
7.2.1. Security Claims Terminology for EAP Methods. . . 44
7.3. Identity Protection . . . . . . . . . . . . . . . . . . 46
7.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . 47
7.5. Packet Modification Attacks . . . . . . . . . . . . . . 48
7.6. Dictionary Attacks. . . . . . . . . . . . . . . . . . . 49
7.7. Connection to an Untrusted Network. . . . . . . . . . . 49
7.8. Negotiation Attacks . . . . . . . . . . . . . . . . . . 50
7.9. Implementation Idiosyncrasies . . . . . . . . . . . . . 50
7.10. Key Derivation. . . . . . . . . . . . . . . . . . . . . 51
7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . 53
7.12. Link Layer. . . . . . . . . . . . . . . . . . . . . . . 53
7.13. Separation of Authenticator and Backend Authentication
Server. . . . . . . . . . . . . . . . . . . . . . . . . 54
7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . 55
7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . 55
7.16. Protected Result Indications. . . . . . . . . . . . . . 56
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.1. Normative References. . . . . . . . . . . . . . . . . . 59
9.2. Informative References. . . . . . . . . . . . . . . . . 60
Appendix A. Changes from RFC 2284. . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 67
This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.
このドキュメントでは、複数の認証方法をサポートする認証フレームワークである拡張可能な認証プロトコル（EAP）を定義します。EAPは通常、IPを必要とせずに、ポイントツーポイントプロトコル（PPP）やIEEE 802などのデータリンクレイヤーを直接実行します。EAPは、重複の排除と再送信に対する独自のサポートを提供しますが、下層の順序付け保証に依存しています。断片化はEAP自体内ではサポートされていません。ただし、個々のEAPメソッドはこれをサポートする場合があります。
EAP may be used on dedicated links, as well as switched circuits, and wired as well as wireless links. 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 switches and access points using IEEE 802 [IEEE-802]. EAP encapsulation on IEEE 802 wired media is described in [IEEE-802.1X], and encapsulation on IEEE wireless LANs in [IEEE-802.11i].
EAPは、専用のリンク、切り替え回路、ワイヤレスリンクとワイヤレスリンクで使用できます。これまで、EAPは、PPP [RFC1661]を使用して、スイッチされた回路またはダイヤルアップラインを介して接続するホストとルーターで実装されています。また、IEEE 802 [IEEE-802]を使用して、スイッチとアクセスポイントで実装されています。IEEE 802有線メディアのEAPカプセル化は、[IEEE-802.1x]で説明されており、[IEEE-802.11i]のIEEEワイヤレスLANSのカプセル化が記載されています。
One of the advantages of the EAP architecture is its flexibility. EAP is used to select a specific authentication mechanism, typically after the authenticator requests more information in order to determine the specific authentication method to be used. Rather than requiring the authenticator to be updated to support each new authentication method, EAP permits the use of a backend authentication server, which may implement some or all authentication methods, with the authenticator acting as a pass-through for some or all methods and peers.
EAPアーキテクチャの利点の1つは、その柔軟性です。EAPは、通常、認証機が使用する特定の認証方法を決定するために、より多くの情報を要求した後、特定の認証メカニズムを選択するために使用されます。新しい認証方法をサポートするために認証機を更新するように要求するのではなく、EAPはバックエンド認証サーバーの使用を許可します。。
Within this document, authenticator requirements apply regardless of whether the authenticator is operating as a pass-through or not. Where the requirement is meant to apply to either the authenticator or backend authentication server, depending on where the EAP authentication is terminated, the term "EAP server" will be used.
このドキュメント内では、認証機の要件がパススルーとして動作しているかどうかに関係なく、適用されます。要件が、EAP認証が終了する場所に応じて、認証器またはバックエンド認証サーバーのいずれかに適用することを目的としている場合、「EAPサーバー」という用語が使用されます。
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This document frequently uses the following terms:
このドキュメントは、頻繁に次の用語を使用します。
authenticator The end of the link initiating EAP authentication. The term authenticator is used in [IEEE-802.1X], and has the same meaning in this document.
Authenticator EAP認証を開始するリンクの終わり。認証器という用語は[IEEE-802.1x]で使用されており、このドキュメントでも同じ意味があります。
peer The end of the link that responds to the authenticator. In [IEEE-802.1X], this end is known as the Supplicant.
Authenticatorに応答するリンクの終わりをピアします。[IEEE-802.1X]では、この端はサプリカントとして知られています。
Supplicant The end of the link that responds to the authenticator in [IEEE-802.1X]. In this document, this end of the link is called the peer.
[IEEE-802.1x]で認証器に応答するリンクの終わりをサプリティブします。このドキュメントでは、リンクのこの端はピアと呼ばれます。
backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X].
バックエンド認証サーバーバックエンド認証サーバーは、認証サービスを認証機に提供するエンティティです。使用すると、このサーバーは通常、認証器のEAPメソッドを実行します。この用語は、[IEEE-802.1x]でも使用されます。
AAA Authentication, Authorization, and Accounting. AAA protocols with EAP support include RADIUS [RFC3579] and Diameter [DIAM-EAP]. In this document, the terms "AAA server" and "backend authentication server" are used interchangeably.
AAA認証、承認、および会計。EAPサポートを備えたAAAプロトコルには、RADIUS [RFC3579]および直径[Diam-Eap]が含まれます。このドキュメントでは、「AAAサーバー」と「バックエンド認証サーバー」という用語が同じ意味で使用されます。
Displayable Message This is interpreted to be a human readable string of characters. The message encoding MUST follow the UTF-8 transformation format [RFC2279].
表示可能なメッセージこれは、人間の読み取り可能な文字列であると解釈されます。メッセージエンコーディングは、UTF-8変換形式[RFC2279]に従う必要があります。
EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server.
EAPサーバーEAP認証方法をピアで終了するエンティティ。バックエンド認証サーバーが使用されていない場合、EAPサーバーは認証機の一部です。Authenticatorがパススルーモードで動作する場合、EAPサーバーはバックエンド認証サーバーにあります。
Silently Discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the event, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
これは、実装がさらに処理せずにパケットを破棄することを意味します。この実装は、静かに破棄されたパケットの内容を含むイベントのログを提供する機能を提供する必要があり、統計カウンターにイベントを記録する必要があります。
Successful Authentication In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access by the peer, and the peer decides to use this access. The authenticator's decision typically involves both authentication and authorization aspects; the peer may successfully authenticate to the authenticator, but access may be denied by the authenticator due to policy reasons.
このドキュメントのコンテキストでの認証の成功は、「成功した認証」はEAPメッセージの交換であり、その結果、認証者はピアによるアクセスを許可することを決定し、ピアはこのアクセスを使用することを決定します。認証者の決定には、通常、認証と承認の両方の側面が含まれます。ピアは認証者に正常に認証することができますが、ポリシーの理由により、認証者によってアクセスが拒否される場合があります。
Message Integrity Check (MIC) A keyed hash function used for authentication and integrity protection of data. This is usually called a Message Authentication Code (MAC), but IEEE 802 specifications (and this document) use the acronym MIC to avoid confusion with Medium Access Control.
メッセージ整合性チェック（MIC）データの認証と整合性の保護に使用されるキー付きハッシュ関数。これは通常、メッセージ認証コード（MAC）と呼ばれますが、IEEE 802仕様（およびこのドキュメント）を使用して、中程度のアクセス制御との混乱を避けるために頭字語マイクを使用します。
Cryptographic Separation Two keys (x and y) are "cryptographically separate" if an adversary that knows all messages exchanged in the protocol cannot compute x from y or y from x without "breaking" some cryptographic assumption. In particular, this definition allows that the adversary has the knowledge of all nonces sent in cleartext, as well as all predictable counter values used in the protocol. Breaking a cryptographic assumption would typically require inverting a one-way function or predicting the outcome of a cryptographic pseudo-random number generator without knowledge of the secret state. In other words, if the keys are cryptographically separate, there is no shortcut to compute x from y or y from x, but the work an adversary must do to perform this computation is equivalent to performing an exhaustive search for the secret state value.
暗号化分離2つのキー（xとy）は、プロトコルで交換されたすべてのメッセージを知っている敵が、暗号化の仮定を「破る」ことなくxからyまたはyからxから計算できない場合、「暗号化的に分離」されます。特に、この定義により、敵は、プロトコルで使用されるすべての予測可能なカウンター値と同様に、ClearTextで送信されるすべての非能力に関する知識を持つことができます。暗号化の仮定を破るには、通常、一方向関数を反転させるか、秘密の状態を知らずに暗号化擬似ランダム数ジェネレーターの結果を予測する必要があります。言い換えれば、キーが暗号化的に分離されている場合、Xからyまたはyからxを計算するためのショートカットはありませんが、この計算を実行するために敵がしなければならない作業は、秘密の状態値の徹底的な検索を実行することと同等です。
Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. In existing implementations, a AAA server acting as an EAP server transports the MSK to the authenticator.
EAPピアとサーバーの間で導出され、EAPメソッドによってエクスポートされるマスターセッションキー（MSK）キーイング素材。MSKの長さは少なくとも64オクテットです。既存の実装では、EAPサーバーとして機能するAAAサーバーがMSKを認証機に輸送します。
Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet.
EAPメソッドによってエクスポートされるEAPクライアントとサーバーの間で導出された拡張マスターセッションキー（EMSK）。EMSKの長さは少なくとも64オクテットです。EMSKは、認証者または他の第三者と共有されていません。EMSKは、まだ定義されていない将来の用途のために予約されています。
Result indications A method provides result indications if after the method's last message is sent and received:
結果表示メソッドは、メソッドの最後のメッセージが送信されて受信された場合の結果を示します。
1) The peer is aware of whether it has authenticated the server, as well as whether the server has authenticated it.
1) ピアは、サーバーを認証したかどうか、サーバーが認証されているかどうかを認識しています。
2) The server is aware of whether it has authenticated the peer, as well as whether the peer has authenticated it.
2) サーバーは、ピアを認証したかどうか、およびピアがそれを認証したかどうかを認識しています。
In the case where successful authentication is sufficient to authorize access, then the peer and authenticator will also know if the other party is willing to provide or accept access. This may not always be the case. An authenticated peer may be denied access due to lack of authorization (e.g., session limit) or other reasons. Since the EAP exchange is run between the peer and the server, other nodes (such as AAA proxies) may also affect the authorization decision. This is discussed in more detail in Section 7.16.
アクセスを承認するのに十分な認証が十分である場合、ピアと認証者は、相手がアクセスを提供または受け入れる意思があるかどうかも知るでしょう。これが常にそうであるとは限りません。認証されたピアは、許可の欠如（セッション制限など）またはその他の理由により、アクセスを拒否される場合があります。EAP交換はピアとサーバーの間で実行されるため、他のノード（AAAプロキシなど）も承認決定に影響を与える可能性があります。これについては、セクション7.16で詳しく説明します。
EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED.
EAPは、IPレイヤー接続が利用できない場合があるネットワークアクセス認証で使用するように設計されています。バルクデータ輸送など、他の目的でのEAPの使用は推奨されません。
Since EAP does not require IP connectivity, it provides just enough support for the reliable transport of authentication protocols, and no more.
EAPはIP接続を必要としないため、認証プロトコルの信頼できる輸送に十分なサポートを提供します。
EAP is a lock-step protocol which only supports a single packet in flight. As a result, EAP cannot efficiently transport bulk data, unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960].
EAPは、飛行中の単一のパケットのみをサポートするロックステッププロトコルです。その結果、EAPは、TCP [RFC793]やSCTP [RFC2960]などの輸送プロトコルとは異なり、バルクデータを効率的に輸送することはできません。
While EAP provides support for retransmission, it assumes ordering guarantees provided by the lower layer, so out of order reception is not supported.
EAPは再送信をサポートしていますが、下層層が提供する順序付け保証を想定しているため、注文不能な受信はサポートされていません。
Since EAP does not support fragmentation and reassembly, EAP authentication methods generating payloads larger than the minimum EAP MTU need to provide fragmentation support.
EAPは断片化と再組み立てをサポートしていないため、EAP認証方法は、最小EAP MTUよりも大きいペイロードを生成する断片化サポートを提供する必要があります。
While authentication methods such as EAP-TLS [RFC2716] provide support for fragmentation and reassembly, the EAP methods defined in this document do not. As a result, if the EAP packet size exceeds the EAP MTU of the link, these methods will encounter difficulties.
EAP-TLS [RFC2716]などの認証方法は、断片化と再組み立てのサポートを提供しますが、このドキュメントで定義されているEAPメソッドはそうではありません。その結果、EAPパケットサイズがリンクのEAP MTUを超えると、これらの方法は困難に遭遇します。
EAP authentication is initiated by the server (authenticator), whereas many authentication protocols are initiated by the client (peer). As a result, it may be necessary for an authentication algorithm to add one or two additional messages (at most one roundtrip) in order to run over EAP.
EAP認証はサーバー（Authenticator）によって開始されますが、多くの認証プロトコルはクライアント（PEER）によって開始されます。その結果、EAPを実行するために、認証アルゴリズムが1つまたは2つの追加のメッセージ（最大1つの往復）を追加する必要がある場合があります。
Where certificate-based authentication is supported, the number of additional roundtrips may be much larger due to fragmentation of certificate chains. In general, a fragmented EAP packet will require as many round-trips to send as there are fragments. For example, a certificate chain 14960 octets in size would require ten round-trips to send with a 1496 octet EAP MTU.
証明書ベースの認証がサポートされている場合、証明書チェーンの断片化により、追加の往復の数がはるかに大きくなる可能性があります。一般に、断片化されたEAPパケットは、フラグメントがあるのと同じくらい多くの往復を送信する必要があります。たとえば、サイズの証明書チェーン14960オクテットでは、1496オクテットのEAP MTUで送信するために10回のラウンドトリップが必要です。
Where EAP runs over a lower layer in which significant packet loss is experienced, or where the connection between the authenticator and authentication server experiences significant packet loss, EAP methods requiring many round-trips can experience difficulties. In these situations, use of EAP methods with fewer roundtrips is advisable.
EAPが重要なパケット損失が経験される下層層を越えている場合、または認証サーバーと認証サーバーの接続が重要なパケット損失を経験する場合、多くのラウンドトリップを必要とするEAPメソッドは困難を経験する可能性があります。これらの状況では、より少ない往復でEAPメソッドを使用することをお勧めします。
The EAP authentication exchange proceeds as follows:
EAP認証交換は次のように進行します。
[1] The authenticator sends a Request to authenticate the peer. The Request has a Type field to indicate what is being requested. Examples of Request Types include Identity, MD5-challenge, etc. The MD5-challenge Type corresponds closely to the CHAP authentication protocol [RFC1994]. Typically, the authenticator will send an initial Identity Request; however, an initial Identity Request is not required, and MAY be bypassed. For example, the identity may not be required where it is determined by the port to which the peer has connected (leased lines, dedicated switch or dial-up ports), or where the identity is obtained in another fashion (via calling station identity or MAC address, in the Name field of the MD5-Challenge Response, etc.).
[1] Authenticatorは、ピアを認証するリクエストを送信します。リクエストには、要求されているものを示すタイプフィールドがあります。リクエストタイプの例には、ID、MD5-Challengeなどが含まれます。MD5-Challengeタイプは、CHAP認証プロトコル[RFC1994]に密接に対応しています。通常、Authenticatorは最初のIDリクエストを送信します。ただし、最初のIDリクエストは必要ありません。また、バイパスされる場合があります。たとえば、ピアが接続しているポート（リースライン、専用のスイッチまたはダイヤルアップポート）によって決定される場合、またはアイデンティティが別の方法で取得される場合（ステーションのアイデンティティまたは呼び出しによるアイデンティティまたはMACアドレス、MD5チャレンジ応答の名前フィールドなど）。
[2] The peer sends a Response packet in reply to a valid Request. As with the Request packet, the Response packet contains a Type field, which corresponds to the Type field of the Request.
[2] ピアは、有効なリクエストに応答して応答パケットを送信します。リクエストパケットと同様に、応答パケットには、リクエストのタイプフィールドに対応するタイプフィールドが含まれています。
[3] The authenticator sends an additional Request packet, and the peer replies with a Response. The sequence of Requests and Responses continues as long as needed. 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. The authenticator is responsible for retransmitting requests as described in Section 4.1. After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation. The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer.
[3] Authenticatorは追加のリクエストパケットを送信し、ピアは応答して返信します。リクエストと応答のシーケンスは、必要な限り継続します。EAPは「ロックステップ」プロトコルであるため、最初のリクエスト以外に、有効な応答を受信する前に新しいリクエストを送信することはできません。Authenticatorは、セクション4.1で説明されているように、リクエストを再送信する責任があります。適切な数の再送信の後、AuthenticatorはEAP会話を終了する必要があります。認証者は、再送信時またはピアからの応答を取得できなかったときに、成功または失敗のパケットを送信してはなりません。
[4] The conversation continues until the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests), in which case the authenticator implementation MUST transmit an EAP Failure (Code 4). Alternatively, the authentication conversation can continue until the authenticator determines that successful authentication has occurred, in which case the authenticator MUST transmit an EAP Success (Code 3).
[4] Authenticatorがピアを認証できなくなるまで会話は続きます（1つ以上のリクエストに対する容認できない応答）。その場合、Authenticatorの実装はEAP障害を送信する必要があります（コード4）。あるいは、認証会話は、認証の成功が発生したと判断するまで継続することができます。その場合、認証者はEAPの成功を送信する必要があります（コード3）。
Advantages:
利点：
o The EAP protocol can support multiple authentication mechanisms without having to pre-negotiate a particular one.
o EAPプロトコルは、特定のプロトコルを事前に交渉することなく、複数の認証メカニズムをサポートできます。
o Network Access Server (NAS) devices (e.g., a switch or access point) do not have to understand each authentication method and MAY act as a pass-through agent for a backend authentication server. Support for pass-through is optional. An authenticator 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.
o ネットワークアクセスサーバー（NAS）デバイス（スイッチやアクセスポイントなど）は、各認証方法を理解する必要がなく、バックエンド認証サーバーのパススルーエージェントとして機能する場合があります。パススルーのサポートはオプションです。認証者は地元のピアを認証することができますが、同時に、ローカルではローカルで実装していない認証方法のパススルーとして機能します。
o Separation of the authenticator from the backend authentication server simplifies credentials management and policy decision making.
o Authenticatorをバックエンド認証サーバーから分離すると、資格情報の管理とポリシーの意思決定が簡素化されます。
Disadvantages:
短所：
o For use in PPP, EAP requires the addition of a new authentication Type to PPP LCP and thus PPP implementations will need to be modified to use it. It also strays from the previous PPP authentication model of negotiating a specific authentication mechanism during LCP. Similarly, switch or access point implementations need to support [IEEE-802.1X] in order to use EAP.
o PPPで使用するには、EAPではPPP LCPに新しい認証タイプを追加する必要があるため、使用するにはPPP実装を変更する必要があります。また、LCP中に特定の認証メカニズムを交渉するという以前のPPP認証モデルから迷います。同様に、EAPを使用するために[IEEE-802.1x]をサポートする必要があります。
o Where the authenticator is separate from the backend authentication server, this complicates the security analysis and, if needed, key distribution.
o AuthenticatorがBackEnd Authentication Serverから分離されている場合、これによりセキュリティ分析が複雑になり、必要に応じてキーディストリビューションが複雑になります。
An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, the peer and authenticator MUST utilize only one authentication method (Type 4 or greater) within an EAP conversation, after which the authenticator MUST send a Success or Failure packet.
EAPの会話は、一連の方法を利用する場合があります。これの一般的な例は、IDリクエストに続いて、MD5-Challengeなどの単一のEAP認証方法が続くことです。ただし、PeerとAuthenticatorは、EAP会話内で1つの認証方法（タイプ4以下）のみを使用する必要があります。その後、認証者は成功または失敗パケットを送信する必要があります。
Once a peer has sent a Response of the same Type as the initial Request, an authenticator MUST NOT send a Request of a different Type prior to completion of the final round of a given method (with the exception of a Notification-Request) and MUST NOT send a Request for an additional method of any Type after completion of the initial authentication method; a peer receiving such Requests MUST treat them as invalid, and silently discard them. As a result, Identity Requery is not supported.
ピアが最初のリクエストと同じタイプの応答を送信したら、認証者は特定のメソッドの最終ラウンドを完了する前に別のタイプのリクエストを送信してはなりません（通知のリケストを除く）。初期認証方法が完了した後、あらゆるタイプの追加方法のリクエストを送信しないでください。そのようなリクエストを受け取るピアは、それらを無効として扱い、静かに廃棄する必要があります。その結果、アイデンティティリクリーはサポートされていません。
A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request after an initial non-Nak Response has been sent. Since spoofed EAP Request packets may be sent by an attacker, an authenticator receiving an unexpected Nak SHOULD discard it and log the event.
ピアは、最初の非NAK応答が送信された後、リクエストに返信してNAK（レガシーまたは拡張）を送信してはなりません。攻撃者がスプーフィングしたEAPリクエストパケットは送信される可能性があるため、予期しないNAKを受け取る認証者はそれを破棄してイベントを記録する必要があります。
Multiple authentication methods within an EAP conversation are not supported due to their vulnerability to man-in-the-middle attacks (see Section 7.4) and incompatibility with existing implementations.
EAP会話内の複数の認証方法は、中間攻撃に対する脆弱性（セクション7.4を参照）と既存の実装との互換性のためにサポートされていません。
Where a single EAP authentication method is utilized, but other methods are run within it (a "tunneled" method), the prohibition against multiple authentication methods does not apply. Such "tunneled" methods appear as a single authentication method to EAP. Backward compatibility can be provided, since a peer not supporting a "tunneled" method can reply to the initial EAP-Request with a Nak (legacy or expanded). To address security vulnerabilities, "tunneled" methods MUST support protection against man-in-the-middle attacks.
単一のEAP認証方法が利用されているが、その中に他の方法が実行されている場合（「トンネリング」方法）、複数の認証方法に対する禁止は適用されません。このような「トンネル」メソッドは、EAPに対する単一の認証方法として表示されます。「トンネル」メソッドをサポートしていないピアは、NAK（レガシーまたは拡張）で最初のEAP-Requestに返信できるため、後方互換性を提供できます。セキュリティの脆弱性に対処するために、「トンネル化された」方法は、中間の攻撃に対する保護をサポートする必要があります。
Conceptually, EAP implementations consist of the following components:
概念的には、EAP実装は次のコンポーネントで構成されています。
[a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP, wired IEEE 802 LANs [IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), and TCP [PIC]. Lower layer behavior is discussed in Section 3.
[a] 下層。下層は、ピアと認証者の間でEAPフレームを送信および受信する責任があります。EAPは、PPP、有線IEEE 802 LANS [IEEE-802.1x]、IEEE 802.11ワイヤレスLANS [IEEE-802.11]、UDP（L2TP [RFC2661]およびIKEV2 [IKEV2]）、およびTCP [写真]。下層の動作については、セクション3で説明します。
[b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from the EAP peer and authenticator layers.
[b] EAPレイヤー。EAPレイヤーは、下層を介してEAPパケットを受信および送信し、重複した検出と再送信を実装し、EAPピアおよび認証装置のレイヤーとの間でEAPメッセージを配信および受信します。
[c] EAP peer and authenticator layers. Based on the Code field, the EAP layer demultiplexes incoming EAP packets to the EAP peer and authenticator layers. Typically, an EAP implementation on a given host will support either peer or authenticator functionality, but it is possible for a host to act as both an EAP peer and authenticator. In such an implementation both EAP peer and authenticator layers will be present.
[c] EAPピアおよび認証装置レイヤー。コードフィールドに基づいて、EAPレイヤーは、EAPピアおよび認証装置レイヤーにEAPパケットを着信していることを非難します。通常、特定のホストでのEAP実装は、ピアまたは認証装置の機能をサポートしますが、ホストがEAPピアと認証器の両方として機能する可能性があります。このような実装では、EAPピアレイヤーと認証レイヤーの両方が存在します。
[d] EAP method layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5.
[d] EAPメソッドレイヤー。EAPメソッドは、認証アルゴリズムを実装し、EAPピアレイヤーと認証装置レイヤーを介してEAPメッセージを受信および送信します。断片化サポートはEAP自体によって提供されていないため、これはEAPメソッドの責任であり、セクション5で説明されています。
The EAP multiplexing model is illustrated in Figure 1 below. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it.
EAPマルチプレックスモデルを以下の図1に示します。オンザワイヤの動作がそれと一致している限り、実装がこのモデルに適合するという要件はないことに注意してください。
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP method| EAP method| | EAP method| EAP method|
| Type = X | Type = Y | | Type = X | Type = Y |
| V | | | ^ | |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! Peer layer | | EAP ! Auth. layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! layer | | EAP ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| Lower ! layer | | Lower ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
! !
! Peer ! Authenticator
+------------>-------------+
Figure 1: EAP Multiplexing Model
図1：EAPマルチプレックスモデル
Within EAP, the Code field functions much like a protocol number in IP. It is assumed that the EAP layer demultiplexes incoming EAP packets according to the Code field. Received EAP packets with Code=1 (Request), 3 (Success), and 4 (Failure) are delivered by the EAP layer to the EAP peer layer, if implemented. EAP packets with Code=2 (Response) are delivered to the EAP authenticator layer, if implemented.
EAP内では、コードフィールドはIPのプロトコル番号と同じように機能します。EAP層は、コードフィールドに従ってEAPパケットを着信することを非難すると想定されています。コード= 1（リクエスト）、3（成功）、および4（障害）を備えたEAPパケットを受信したEAPレイヤーによって、実装されている場合、EAPピア層に配信されます。コード= 2（応答）を備えたEAPパケットは、実装されている場合、EAP認証レイヤーに配信されます。
Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP peer and authenticator layers demultiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type. An EAP method implementation on a host may register to receive packets from the peer or authenticator layers, or both, depending on which role(s) it supports.
EAP内では、タイプフィールドは、UDPまたはTCPのポート番号と同じように機能します。EAPピアと認証機のレイヤーは、そのタイプに応じてEAPパケットを着信していることを非難し、そのタイプに対応するEAPメソッドにのみ配信すると想定されています。ホストでのEAPメソッドの実装は、サポートする役割に応じて、ピアまたは認証装置のレイヤーまたはその両方からパケットを受信するために登録する場合があります。
Since EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater), in addition to the Identity method. The Identity Type is discussed in Section 5.1.
EAP認証方法はIDにアクセスすることを希望する場合があるため、実装はIDメソッドに加えて、認証方法（タイプ4以下）にアクセスできるようになります。IDタイプについては、セクション5.1で説明します。
A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response are available to another method. The Notification Type is discussed in Section 5.2.
通知応答は、ピアが通知リクエストを受け取ったことの確認としてのみ使用されますが、それを処理したり、ユーザーにメッセージを表示したりすることはありません。通知要求または応答の内容が別の方法で利用可能であると想定することはできません。通知タイプについては、セクション5.2で説明します。
Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes of method negotiation. Peers respond to an initial EAP Request for an unacceptable Type with a Nak Response (Type 3) or Expanded Nak Response (Type 254). It cannot be assumed that the contents of the Nak Response(s) are available to another method. The Nak Type(s) are discussed in Section 5.3.
NAK（タイプ3）または拡張されたNAK（タイプ254）は、メソッドネゴシエーションの目的で利用されます。ピアは、NAK応答（タイプ3）またはNAK応答の拡張（タイプ254）を使用した容認できないタイプの最初のEAP要求に応答します。NAK応答の内容が別の方法で利用可能であると想定することはできません。NAKタイプについては、セクション5.3で説明します。
EAP packets with Codes of Success or Failure do not include a Type field, and are not delivered to an EAP method. Success and Failure are discussed in Section 4.2.
成功または失敗のコードを備えたEAPパケットには、タイプフィールドが含まれておらず、EAPメソッドには配信されません。成功と失敗については、セクション4.2で説明します。
Given these considerations, the Success, Failure, Nak Response(s), and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods.
これらの考慮事項を考慮して、成功、失敗、NAK応答、および通知リクエスト/応答メッセージを、他のEAPメソッドへの配信に運命づけられたデータを伝達するために使用してはなりません。
When operating as a "pass-through authenticator", an authenticator performs checks on the Code, Identifier, and Length fields as described in Section 4.1. It forwards EAP packets received from the peer and destined to its authenticator layer to the backend authentication server; packets received from the backend authentication server destined to the peer are forwarded to it.
「パススルー認証機」として動作する場合、認証者はセクション4.1で説明されているように、コード、識別子、および長さフィールドのチェックを実行します。ピアから受け取ったEAPパケットを転送し、その認証機レイヤーに向けてバックエンド認証サーバーに運命づけられます。ピアに向けられたバックエンド認証サーバーから受信されたパケットは、それに転送されます。
A host receiving an EAP packet may only do one of three things with it: act on it, drop it, or forward it. The forwarding decision is typically based only on examination of the Code, Identifier, and Length fields. A pass-through authenticator implementation MUST be capable of forwarding EAP packets received from the peer with Code=2 (Response) to the backend authentication server. It also MUST be capable of receiving EAP packets from the backend authentication server and forwarding EAP packets of Code=1 (Request), Code=3 (Success), and Code=4 (Failure) to the peer.
EAPパケットを受け取ったホストは、それに基づいて行動する、ドロップする、または転送することです。転送決定は、通常、コード、識別子、および長さのフィールドの検査のみに基づいています。パススルー認証機の実装は、バックエンド認証サーバーにコード= 2（応答）を使用してピアから受信したEAPパケットを転送できる必要があります。また、バックエンド認証サーバーからEAPパケットを受信し、コード= 1（リクエスト）、コード= 3（成功）、およびコード= 4（障害）のEAPパケットをピアに転送できる必要があります。
Unless the authenticator implements one or more authentication methods locally which support the authenticator role, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. Where the authenticator supports local authentication methods, it MAY examine the Type field to determine whether to act on the packet itself or forward it. Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type.
認証機が認証機の役割をサポートする1つまたは複数の認証方法をローカルで実装しない限り、EAPメソッドレイヤーヘッダーフィールド（タイプ、タイプデータ）は、転送決定の一部として検討されません。Authenticatorがローカル認証方法をサポートする場合、型フィールドを調べて、パケット自体に作用するか転送するかを判断できます。準拠したパススルー認証機の実装は、デフォルトであらゆるタイプのEAPパケットを転送する必要があります。
EAP packets received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the EAP layer and delivered to the peer layer. Therefore, unless a host implements an EAP peer layer, these packets will be silently discarded. Similarly, EAP packets received with Code=2 (Response) are demultiplexed by the EAP layer and delivered to the authenticator layer. Therefore, unless a host implements an EAP authenticator layer, these packets will be silently discarded. The behavior of a "pass-through peer" is undefined within this specification, and is unsupported by AAA protocols such as RADIUS [RFC3579] and Diameter [DIAM-EAP].
code = 1（request）、code = 3（success）、およびcode = 4（故障）で受信したEAPパケットは、EAPレイヤーによって逆限になり、ピア層に配信されます。したがって、ホストがEAPピア層を実装しない限り、これらのパケットは静かに破棄されます。同様に、Code = 2（Response）で受信したEAPパケットは、EAPレイヤーによって非glexexされ、認証装置レイヤーに配信されます。したがって、ホストがEAP認証レイヤーを実装しない限り、これらのパケットは静かに破棄されます。「パススルーピア」の動作は、この仕様内で定義されていないため、RADIUS [RFC3579]や直径[直径]などのAAAプロトコルによってサポートされていません。
The forwarding model is illustrated in Figure 2.
転送モデルを図2に示します。
Peer Pass-through Authenticator Authentication Server
ピアパススルー認証認証サーバー
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | ^ |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
|EAP ! peer| | | +-----------+ | |EAP !Auth.|
| ! | | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|EAP !layer| | EAP !layer| EAP !layer | |EAP !layer|
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP |
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! ! ! !
! ! ! !
+-------->--------+ +--------->-------+
Figure 2: Pass-through Authenticator
図2：パススルー認証器
For sessions in which the authenticator acts as a pass-through, it MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server; the outcome MUST NOT be determined by the contents of an EAP packet sent along with the Accept/Reject indication, or the absence of such an encapsulated EAP packet.
認証者がパススルーとして機能するセッションの場合、バックエンド認証サーバーによって送信された受け入れ/拒否表示のみに基づいて認証の結果を決定する必要があります。結果は、受け入れ/拒否の表示とともに送信されたEAPパケットの内容、またはそのようなカプセル化されたEAPパケットがないことによって決定されてはなりません。
Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both ends of the link may act as authenticators and peers at the same time. In this case, it is necessary for both ends to implement EAP authenticator and peer layers. In addition, the EAP method implementations on both peers must support both authenticator and peer functionality.
EAPはピアツーピアプロトコルであるため、独立した同時認証が逆方向に行われる場合があります（下層の機能に応じて）。リンクの両端は、同時に認証者とピアとして機能する場合があります。この場合、両端がEAP認証器とピア層を実装する必要があります。さらに、両方のピアでのEAPメソッドの実装は、認証機とピア機能の両方をサポートする必要があります。
Although EAP supports peer-to-peer operation, some EAP implementations, methods, AAA protocols, and link layers may not support this. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer and another type for the authenticator. Hosts supporting peer-to-peer operation with such a method would need to be provisioned with both types of credentials.
EAPはピアツーピア操作をサポートしていますが、一部のEAP実装、方法、AAAプロトコル、およびリンクレイヤーはこれをサポートしない場合があります。一部のEAPメソッドは、非対称認証をサポートする場合があり、1つのタイプの資格情報がピアに必要であり、認定者には別のタイプが必要です。このような方法でピアツーピア操作をサポートするホストは、両方のタイプの資格情報をプロビジョニングする必要があります。
For example, EAP-TLS [RFC2716] is a client-server protocol in which distinct certificate profiles are typically utilized for the client and server. This implies that a host supporting peer-to-peer authentication with EAP-TLS would need to implement both the EAP peer and authenticator layers, support both peer and authenticator roles in the EAP-TLS implementation, and provision certificates appropriate for each role.
たとえば、EAP-TLS [RFC2716]は、通常、クライアントとサーバーに異なる証明書プロファイルが利用されるクライアントサーバープロトコルです。これは、EAP-TLSを使用してピアツーピア認証をサポートするホストが、EAPピアレイヤーと認証装置レイヤーの両方を実装し、EAP-TLS実装におけるピアと認証機の両方の役割をサポートし、各役割に適した証明書を提供する必要があることを意味します。
AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM-EAP] only support "pass-through authenticator" operation. As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-Request encapsulating an EAP-Request, Success, or Failure packet with an Access-Reject. There is therefore no support for "pass-through peer" operation.
RADIUS/EAP [RFC3579]やDiameter EAP [Diam-Eap]などのAAAプロトコル[パススルー認証器]操作のみをサポートしています。[RFC3579]セクション2.6.2に記載されているように、RADIUSサーバーは、Access-rejectを使用したEAP-Request、Success、または障害パケットをカプセル化するアクセスリケストに応答します。したがって、「パススルーピア」操作のサポートはありません。
Even where a method is used which supports mutual authentication and result indications, several considerations may dictate that two EAP authentications (one in each direction) are required. These include:
相互認証と結果の表示をサポートする方法が使用されている場合でも、いくつかの考慮事項は、2つのEAP認証（各方向に1つ）が必要であることを決定する場合があります。これらには以下が含まれます：
[1] Support for bi-directional session key derivation in the lower layer. Lower layers such as IEEE 802.11 may only support uni-directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 infrastructure mode, only the Access Point (AP) sends multicast/broadcast traffic. In IEEE 802.11 ad hoc mode, where either peer may send multicast/broadcast traffic, two uni-directional group-key exchanges are required. Due to limitations of the design, this also implies the need for unicast key derivations and EAP method exchanges to occur in each direction.
[1] 下層での双方向セッションキーの派生のサポート。IEEE 802.11などの下層層は、一時的なセッションキーの一方向の派生と輸送のみをサポートする場合があります。たとえば、[IEEE-802.11i]で定義されたグループキーの握手は一方向です。IEEE802.11インフラストラクチャモードでは、アクセスポイント（AP）のみがマルチキャスト/ブロードキャストトラフィックを送信します。いずれかのピアがマルチキャスト/ブロードキャストトラフィックを送信する可能性のあるIEEE 802.11アドホックモードでは、2つの一方向のグループキー交換が必要です。設計の制限により、これはユニキャストキー派生物とEAPメソッド交換が各方向に発生する必要性を意味します。
[2] Support for tie-breaking in the lower layer. Lower layers such as IEEE 802.11 ad hoc do not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur.
[2] 下層でのタイブレイキングのサポート。IEEE 802.11 Ad Hocなどの下層層は、「タイブレイク」をサポートしていません。2つのホストが互いに認証を開始するのは、単一の認証だけで前進するだけです。これは、802.11が双方向のグループキーの握手をサポートしていたとしても、それぞれの方向に1つの認証が依然として発生する可能性があることを意味します。
[3] Peer policy satisfaction. EAP methods may support result indications, enabling the peer to indicate to the EAP server within the method that it successfully authenticated the EAP server, as well as for the server to indicate that it has authenticated the peer. However, a pass-through authenticator will not be aware that the peer has accepted the credentials offered by the EAP server, unless this information is provided to the authenticator via the AAA protocol. The authenticator SHOULD interpret the receipt of a key attribute within an Accept packet as an indication that the peer has successfully authenticated the server.
[3] ピアポリシーの満足度。EAPメソッドは、結果の表示をサポートする場合があり、ピアがEAPサーバーを正常に認証したことをメソッド内でEAPサーバーに示すことができます。また、サーバーがピアを認証したことを示すことができます。ただし、この情報がAAAプロトコルを介して認証機に提供されない限り、パススルー認証者は、PeerがEAPサーバーが提供する資格情報を受け入れたことを認識しません。Authenticatorは、ピアがサーバーを正常に認証したことを示すこととして、受け入れパケット内のキー属性の受領を解釈する必要があります。
However, it is possible that the EAP peer's access policy was not satisfied during the initial EAP exchange, even though mutual authentication occurred. For example, the EAP authenticator may not have demonstrated authorization to act in both peer and authenticator roles. As a result, the peer may require an additional authentication in the reverse direction, even if the peer provided an indication that the EAP server had successfully authenticated to it.
ただし、相互認証が発生したとしても、EAPピアのアクセスポリシーは、最初のEAP交換中に満たされなかった可能性があります。たとえば、EAP Authenticatorは、ピアと認証者の両方の役割で行動する許可を実証していない可能性があります。その結果、ピアがEAPサーバーがそれに対して正常に認証されたことを示している場合でも、ピアは逆方向に追加の認証を必要とする場合があります。
EAP makes the following assumptions about lower layers:
EAPは、下層について次の仮定を立てています。
[1] Unreliable transport. In EAP, the authenticator retransmits Requests that have not yet received Responses so that EAP does not assume that lower layers are reliable. Since EAP defines its own retransmission behavior, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer when EAP is run over a reliable lower layer.
[1] 信頼できない輸送。EAPでは、Authenticatorがまだ応答を受け取っていないリクエストを再送信しているため、EAPが低レイヤーが信頼できると想定していません。EAPは独自の再送信動作を定義するため、EAPが信頼性の高い下層層上で実行される場合、下層とEAP層の両方で再送信が発生する可能性があります（望ましくありませんが）可能です。
Note that EAP Success and Failure packets are not retransmitted. Without a reliable lower layer, and with a non-negligible error rate, these packets can be lost, resulting in timeouts. It is therefore desirable for implementations to improve their resilience to loss of EAP Success or Failure packets, as described in Section 4.2.
EAPの成功と障害パケットは再送信されないことに注意してください。信頼性の高い下層層がなく、無視不可能なエラー率がないため、これらのパケットが失われる可能性があり、その結果、タイムアウトが発生します。したがって、セクション4.2で説明されているように、EAPの成功または障害パケットの喪失に対する回復力を改善することが実装が望ましい。
[2] Lower layer error detection. While EAP does not assume that the lower layer is reliable, it does rely on lower layer error detection (e.g., CRC, Checksum, MIC, etc.). EAP methods may not include a MIC, or if they do, it may not be computed over all the fields in the EAP packet, such as the Code, Identifier, Length, or Type fields. As a result, without lower layer error detection, undetected errors could creep into the EAP layer or EAP method layer header fields, resulting in authentication failures.
[2] 下層エラー検出。EAPは下層が信頼できるとは想定していませんが、下層エラー検出（CRC、チェックサム、マイクなど）に依存しています。EAPメソッドにはマイクが含まれない場合や、コード、識別子、長さ、型フィールドなど、EAPパケット内のすべてのフィールドで計算されない場合があります。その結果、下層エラーの検出がなければ、検出されないエラーがEAPレイヤーまたはEAPメソッドレイヤーヘッダーフィールドに忍び寄ると、認証障害が発生する可能性があります。
For example, EAP TLS [RFC2716], which computes its MIC over the Type-Data field only, regards MIC validation failures as a fatal error. Without lower layer error detection, this method, and others like it, will not perform reliably.
たとえば、EAP TLS [RFC2716]は、MICの検証障害を致命的なエラーと見なすと考えています。下層エラーの検出がなければ、この方法などは、確実に実行されません。
[3] Lower layer security. EAP does not require lower layers to provide security services such as per-packet confidentiality, authentication, integrity, and replay protection. However, where these security services are available, EAP methods supporting Key Derivation (see Section 7.2.1) can be used to provide dynamic keying material. This makes it possible to bind the EAP authentication to subsequent data and protect against data modification, spoofing, or replay. See Section 7.1 for details.
[3] 下層セキュリティ。EAPは、パケットごとの機密性、認証、整合性、リプレイ保護などのセキュリティサービスを提供するために、下位層を必要としません。ただし、これらのセキュリティサービスが利用可能な場合、キー派生をサポートするEAPメソッド（セクション7.2.1を参照）を使用して、動的キーイン材料を提供できます。これにより、EAP認証を後続のデータに結合し、データの変更、スプーフィング、またはリプレイから保護できます。詳細については、セクション7.1を参照してください。
[4] Minimum MTU. EAP is capable of functioning on lower layers that provide an EAP MTU size of 1020 octets or greater.
[4] 最小MTU。EAPは、1020オクテット以上のEAP MTUサイズを提供する下層で機能することができます。
EAP does not support path MTU discovery, and fragmentation and reassembly is not supported by EAP, nor by the methods defined in this specification: Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6), and expanded Nak Response (254) Types.
EAPはPATH MTUの発見をサポートしておらず、断片化と再組み立てはEAPによってサポートされていません。また、この仕様で定義されている方法：ID（1）、通知（2）、NAK応答（3）、MD5-Challenge（4）、ワンタイムパスワード（5）、汎用トークンカード（6）、および拡張NAK応答（254）タイプ。
Typically, the EAP peer obtains information on the EAP MTU from the lower layers and sets the EAP frame size to an appropriate value. Where the authenticator operates in pass-through mode, the authentication server does not have a direct way of determining the EAP MTU, and therefore relies on the authenticator to provide it with this information, such as via the Framed-MTU attribute, as described in [RFC3579], Section 2.4.
通常、EAPピアは下層からEAP MTUに関する情報を取得し、EAPフレームサイズを適切な値に設定します。認証機がパススルーモードで動作する場合、認証サーバーはEAP MTUを決定する直接的な方法を持たないため、framed-mtu属性を介してこの情報を提供するために認証機に依存しています。[RFC3579]、セクション2.4。
While methods such as EAP-TLS [RFC2716] support fragmentation and reassembly, EAP methods originally designed for use within PPP where a 1500 octet MTU is guaranteed for control frames (see [RFC1661], Section 6.1) may lack fragmentation and reassembly features.
EAP-TLS [RFC2716]などのメソッドは断片化と再組み立てをサポートしていますが、元々は1500オクテットMTUがコントロールフレームに対して保証されているPPP内で使用するために設計されたEAPメソッド（[RFC1661]、セクション6.1を参照）には断片化と再組み立ての特徴がない場合があります。
EAP methods can assume a minimum EAP MTU of 1020 octets in the absence of other information. EAP methods SHOULD include support for fragmentation and reassembly if their payloads can be larger than this minimum EAP MTU.
EAPメソッドは、他の情報がない場合、1020オクテットの最小EAP MTUを想定できます。EAPメソッドには、ペイロードがこの最小EAP MTUよりも大きい場合は、断片化と再組み立てのサポートを含める必要があります。
EAP is a lock-step protocol, which implies a certain inefficiency when handling fragmentation and reassembly. Therefore, if the lower layer supports fragmentation and reassembly (such as where EAP is transported over IP), it may be preferable for fragmentation and reassembly to occur in the lower layer rather than in EAP. This can be accomplished by providing an artificially large EAP MTU to EAP, causing fragmentation and reassembly to be handled within the lower layer.
EAPはロックステッププロトコルであり、断片化と再組み立てを処理する際の特定の非効率性を意味します。したがって、下層が断片化と再組み立て（EAPがIPを介して輸送される場合など）をサポートする場合、断片化と再組み立てがEAPではなく下層で発生することが望ましい場合があります。これは、人工的に大きなEAP MTUをEAPに提供することで実現でき、断片化と再組み立てが下層内で処理されます。
[5] Possible duplication. Where the lower layer is reliable, it will provide the EAP layer with a non-duplicated stream of packets. However, while it is desirable that lower layers provide for non-duplication, this is not a requirement. The Identifier field provides both the peer and authenticator with the ability to detect duplicates.
[5] 可能な複製。下層が信頼できる場合、EAPレイヤーに非重複したパケットのストリームを提供します。ただし、下層層が非重複を提供することは望ましいことですが、これは要件ではありません。識別子フィールドは、ピアと認証器の両方に重複を検出する機能を提供します。
[6] Ordering guarantees. EAP does not require the Identifier to be monotonically increasing, and so is reliant on lower layer ordering guarantees for correct operation. EAP was originally defined to run on PPP, and [RFC1661] Section 1 has an ordering requirement:
[6] 注文保証。EAPは、識別子が単調に増加する必要はないため、正しい動作のために下層の順序付け保証に依存しています。EAPはもともとPPPで実行されるように定義されていましたが、[RFC1661]セクション1には順序付け要件があります。
"The Point-to-Point Protocol is designed for simple links which transport packets between two peers. These links provide full-duplex simultaneous bi-directional operation, and are assumed to deliver packets in order."
「ポイントツーポイントプロトコルは、2つのピア間でパケットを輸送する単純なリンク用に設計されています。これらのリンクは、全二重同時の双方向操作を提供し、パケットを順番に配信すると想定されています。」
Lower layer transports for EAP MUST preserve ordering between a source and destination at a given priority level (the ordering guarantee provided by [IEEE-802]).
EAPの下層輸送は、特定の優先レベルでソースと宛先の間の順序付けを保持する必要があります（[IEEE-802]が提供する順序付け保証）。
Reordering, if it occurs, will typically result in an EAP authentication failure, causing EAP authentication to be re-run. In an environment in which reordering is likely, it is therefore expected that EAP authentication failures will be common. It is RECOMMENDED that EAP only be run over lower layers that provide ordering guarantees; running EAP over raw IP or UDP transport is NOT RECOMMENDED. Encapsulation of EAP within RADIUS [RFC3579] satisfies ordering requirements, since RADIUS is a "lockstep" protocol that delivers packets in order.
並べ替えが発生した場合、通常、EAP認証障害が発生し、EAP認証が再実行されます。したがって、並べ替えが可能性が高い環境では、EAP認証障害が一般的であると予想されます。EAPは、順序付け保証を提供する下層層上でのみ実行することをお勧めします。生のIPまたはUDPトランスポートを介してEAPを実行することは推奨されません。半径内のEAPのカプセル化[RFC3579]は、順序付け要件を満たします。これは、RADIUSはパケットを順番に配信する「ロックステップ」プロトコルであるためです。
In order to establish communications over a point-to-point link, each end of the PPP link first sends LCP packets to configure the data link during the Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network-Layer Protocol phase.
ポイントツーポイントリンクで通信を確立するために、PPPリンクの各端は最初にLCPパケットを送信して、リンク確立フェーズでデータリンクを構成します。リンクが確立された後、PPPはネットワーク層プロトコルフェーズに進む前に、オプションの認証フェーズを提供します。
By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication Protocol Configuration Option during the Link Establishment phase.
デフォルトでは、認証は必須ではありません。リンクの認証が必要な場合、実装は、リンク確立フェーズ中に認証プロトコル構成オプションを指定する必要があります。
If the identity of the peer has been established in the Authentication phase, the server can use that identity in the selection of options for the following network layer negotiations.
ピアのIDが認証フェーズで確立されている場合、サーバーは次のネットワークレイヤー交渉のオプションの選択でそのIDを使用できます。
When implemented within PPP, EAP does not select a specific authentication mechanism at the PPP Link Control Phase, but rather postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a "backend" server which actually implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange. The PPP Link Establishment and Authentication phases, and the Authentication Protocol Configuration Option, are defined in The Point-to-Point Protocol (PPP) [RFC1661].
PPP内で実装された場合、EAPはPPPリンク制御フェーズで特定の認証メカニズムを選択せず、認証フェーズまでこれを延期します。これにより、特定の認証メカニズムを決定する前に、認証機がより多くの情報を要求することができます。これにより、PPP認証機が単に認証交換を通過するだけでなく、さまざまなメカニズムを実際に実装する「バックエンド」サーバーの使用も許可します。PPPリンクの確立フェーズと認証フェーズ、および認証プロトコル構成オプションは、ポイントツーポイントプロトコル（PPP）[RFC1661]で定義されています。
A summary of the PPP Authentication Protocol Configuration Option format to negotiate EAP follows. The fields are transmitted from left to right.
EAPをネゴシエートするためのPPP認証プロトコル構成オプション形式の概要。フィールドは左から右に送信されます。
Exactly one EAP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex C227 (PPP EAP).
PPPデータリンクレイヤーフレームの情報フィールドに1つのEAPパケットがカプセル化されており、プロトコルフィールドがタイプHEX C227（PPP EAP）を示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
3
3
Length
長さ
4
4
Authentication Protocol
認証プロトコル
C227 (Hex) for Extensible Authentication Protocol (EAP)
拡張可能な認証プロトコル（EAP）用のC227（六角）
The encapsulation of EAP over IEEE 802 is defined in [IEEE-802.1X]. The IEEE 802 encapsulation of EAP does not involve PPP, and IEEE 802.1X does not include support for link or network layer negotiations. As a result, within IEEE 802.1X, it is not possible to negotiate non-EAP authentication mechanisms, such as PAP or CHAP [RFC1994].
IEEE 802を介したEAPのカプセル化は、[IEEE-802.1x]で定義されています。EAPのIEEE 802カプセル化にはPPPは含まれておらず、IEEE 802.1xにはリンクまたはネットワークレイヤーの交渉のサポートは含まれていません。その結果、IEEE 802.1x内では、PAPやChap [RFC1994]などの非EAP認証メカニズムを交渉することはできません。
The reliability and security of lower layer indications is dependent on the lower layer. Since EAP is media independent, the presence or absence of lower layer security is not taken into account in the processing of EAP messages.
下層指示の信頼性とセキュリティは、下層に依存します。EAPはメディアに依存しないため、下層セキュリティの有無はEAPメッセージの処理で考慮されていません。
To improve reliability, if a peer receives a lower layer success indication as defined in Section 7.2, it MAY conclude that a Success packet has been lost, and behave as if it had actually received a Success packet. This includes choosing to ignore the Success in some circumstances as described in Section 4.2.
信頼性を向上させるために、ピアがセクション7.2で定義されているように下層の成功指示を受け取った場合、成功パケットが失われ、実際に成功パケットを受け取ったかのように振る舞うと結論付けることができます。これには、セクション4.2で説明されている状況によって成功を無視することを選択することが含まれます。
A discussion of some reliability and security issues with lower layer indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless LANs can be found in the Security Considerations, Section 7.12.
PPP、IEEE 802有線ネットワーク、およびIEEE 802.11のワイヤレスLANSにおける下層の適応症に関するいくつかの信頼性とセキュリティの問題に関する議論は、セキュリティの考慮事項、セクション7.12にあります。
After EAP authentication is complete, the peer will typically transmit and receive data via the authenticator. It is desirable to provide assurance that the entities transmitting data are the same ones that successfully completed EAP authentication. To accomplish this, it is necessary for the lower layer to provide per-packet integrity, authentication and replay protection, and to bind these per-packet services to the keys derived during EAP authentication. Otherwise, it is possible for subsequent data traffic to be modified, spoofed, or replayed.
EAP認証が完了した後、ピアは通常、認証機を介してデータを送信および受信します。エンティティを送信するエンティティがEAP認証を正常に完了したのと同じものであるという保証を提供することが望ましいです。これを達成するには、下層がパケットごとの整合性、認証、およびリプレイ保護を提供し、これらのパケットごとのサービスをEAP認証中に導出されたキーに結合する必要があります。それ以外の場合、後続のデータトラフィックを変更、スプーフィング、または再生することが可能です。
Where keying material for the lower layer ciphersuite is itself provided by EAP, ciphersuite negotiation and key activation are controlled by the lower layer. In PPP, ciphersuites are negotiated within ECP so that it is not possible to use keys derived from EAP authentication until the completion of ECP. Therefore, an initial EAP exchange cannot be protected by a PPP ciphersuite, although EAP re-authentication can be protected.
下層のキーイング材料は、それ自体がEAPによって提供されている場合、ciphersuiteの交渉とキーアクティベーションは下層によって制御されます。PPPでは、CiphersuitesはECP内で交渉され、ECPが完了するまでEAP認証から派生したキーを使用することはできません。したがって、EAPの再認証を保護することはできますが、最初のEAP交換はPPP暗号で保護することはできません。
In IEEE 802 media, initial key activation also typically occurs after completion of EAP authentication. Therefore an initial EAP exchange typically cannot be protected by the lower layer ciphersuite, although an EAP re-authentication or pre-authentication exchange can be protected.
IEEE 802メディアでは、初期のキーアクティベーションも通常、EAP認証の完了後に発生します。したがって、初期のEAP交換は通常、下層の衝突器によって保護することはできませんが、EAPの再認証または事前認証交換を保護できます。
A summary of the EAP packet format is shown below. The fields are transmitted from left to right.
EAPパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
コード
The Code field is one octet and identifies the Type of EAP packet. EAP Codes are assigned as follows:
コードフィールドは1オクテットで、EAPパケットのタイプを識別します。EAPコードは次のように割り当てられます。
1 Request 2 Response 3 Success 4 Failure
1リクエスト2応答3成功4失敗
Since EAP only defines Codes 1-4, EAP packets with other codes MUST be silently discarded by both authenticators and peers.
EAPはコード1〜4のみを定義するため、他のコードを持つEAPパケットは、認証者とピアの両方によって静かに廃棄する必要があります。
Identifier
識別子
The Identifier field is one octet and aids in matching Responses with Requests.
識別子フィールドは1つのオクテットであり、リクエストとの対応を一致させるのに役立ちます。
Length
長さ
The Length field is two octets and indicates the length, in octets, of the EAP packet including the Code, Identifier, Length, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored upon reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded.
長さフィールドは2オクテットで、コード、識別子、長さ、およびデータフィールドを含むEAPパケットの長さ、オクテットの長さを示します。長さフィールドの範囲外のオクテットは、データリンクレイヤーパディングとして扱われ、受信時に無視する必要があります。受信したオクテットの数よりも大きい値に設定された長さフィールドのメッセージは、静かに破棄する必要があります。
Data
データ
The Data field is zero or more octets. The format of the Data field is determined by the Code field.
データフィールドはゼロ以上のオクテットです。データフィールドの形式は、コードフィールドによって決定されます。
Description
説明
The Request packet (Code field set to 1) is sent by the authenticator to the peer. Each Request has a Type field which serves to indicate what is being requested. Additional Request packets MUST be sent until a valid Response packet is received, an optional retry counter expires, or a lower layer failure indication is received.
リクエストパケット（1に設定されたコードフィールド）は、認証機によってピアに送信されます。各リクエストには、要求されているものを示すのに役立つタイプフィールドがあります。追加のリクエストパケットは、有効な応答パケットが受信されるか、オプションの再試行カウンターが有効になるか、下層の故障表示が受信されるまで送信する必要があります。
Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The content of the data field is dependent on the Request Type. The peer MUST send a Response packet in reply to a valid Request packet. Responses MUST only be sent in reply to a valid Request and never be retransmitted on a timer.
再送信リクエストは、新しいリクエストと区別するために、同じ識別子値で送信する必要があります。データフィールドのコンテンツは、リクエストタイプに依存します。ピアは、有効なリクエストパケットへの応答で応答パケットを送信する必要があります。応答は、有効なリクエストにのみ返信して送信する必要があり、タイマーで再送信されないでください。
If a peer receives a valid duplicate Request for which it has already sent a Response, it MUST resend its original Response without reprocessing the Request. Requests MUST be processed in the order that they are received, and MUST be processed to their completion before inspecting the next Request.
ピアがすでに応答を送信している有効な複製要求を受け取った場合、リクエストを再処理せずに元の応答を再送信する必要があります。リクエストは、受信する順に処理する必要があり、次のリクエストを検査する前に完了まで処理する必要があります。
A summary of the Request and Response packet format follows. The fields are transmitted from left to right.
リクエストと応答のパケット形式の概要が続きます。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
1 for Request 2 for Response
1リクエスト2の応答の場合
Identifier
識別子
The Identifier field is one octet. The Identifier field MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field.
識別子フィールドは1オクテットです。識別子フィールドは、応答を待っている間にタイムアウトのためにリクエストパケットが再送信される場合と同じでなければなりません。新しい（非再送信）リクエストは、識別子フィールドを変更する必要があります。
The Identifier field of the Response MUST match that of the currently outstanding Request. An authenticator receiving a Response whose Identifier value does not match that of the currently outstanding Request MUST silently discard the Response.
応答の識別子フィールドは、現在未解決のリクエストの識別子と一致する必要があります。識別子値が現在未解決の要求の値と一致しない応答を受信する認証者は、応答を静かに破棄する必要があります。
In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request need only be different from the previous Request, but need not be unique within the conversation. One way to achieve this is to start the Identifier at an initial value and increment it for each new Request. Initializing the first Identifier with a random number rather than starting from zero is recommended, since it makes sequence attacks somewhat more difficult.
新しいリクエストと再送信の間の混乱を避けるために、新しいリクエストごとに選択された識別子値は、前のリクエストとは異なるだけですが、会話内で一意である必要はありません。これを達成する1つの方法は、識別子を初期値で起動し、新しいリクエストごとにインクリメントすることです。シーケンス攻撃がやや困難になるため、ゼロから始まるのではなく、乱数で最初の識別子を初期化することをお勧めします。
Since the Identifier space is unique to each session, authenticators are not restricted to only 256 simultaneous authentication conversations. Similarly, with re-authentication, an EAP conversation might continue over a long period of time, and is not limited to only 256 roundtrips.
識別子スペースは各セッションに固有のものであるため、認証者は256の同時認証会話のみに制限されていません。同様に、再認証により、EAPの会話は長期間にわたって続く可能性があり、256の往復に限定されません。
Implementation Note: The authenticator is responsible for retransmitting Request messages. If the Request message is obtained from elsewhere (such as from a backend authentication server), then the authenticator will need to save a copy of the Request in order to accomplish this. The peer is responsible for detecting and handling duplicate Request messages before processing them in any way, including passing them on to an outside party. The authenticator is also responsible for discarding Response messages with a non-matching Identifier value before acting on them in any way, including passing them on to the backend authentication server for verification. Since the authenticator can retransmit before receiving a Response from the peer, the authenticator can receive multiple Responses, each with a matching Identifier. Until a new Request is received by the authenticator, the Identifier value is not updated, so that the authenticator forwards Responses to the backend authentication server, one at a time.
実装注：認証者は、リクエストメッセージの再送信を担当します。リクエストメッセージが他の場所（バックエンド認証サーバーなど）から取得された場合、これを達成するためには、認証者はリクエストのコピーを保存する必要があります。ピアは、外部のパーティーに渡すなど、何らかの方法で処理する前に、重複するリクエストメッセージを検出および処理する責任があります。認証機は、検証のためにバックエンド認証サーバーに渡すなど、何らかの形で動作する前に、一致しない識別子値で応答メッセージを破棄する責任もあります。認証機はピアから応答を受信する前に再送信できるため、認証器は複数の応答を受信できます。Authenticatorが新しいリクエストを受信するまで、識別子値は更新されないため、Authenticatorはバックエンド認証サーバーに一度に1つずつ応答を転送します。
Length
長さ
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Type-Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored upon reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded.
長さフィールドは2オクテットで、コード、識別子、長さ、タイプ、およびタイプデータフィールドを含むEAPパケットの長さを示します。長さフィールドの範囲外のオクテットは、データリンクレイヤーパディングとして扱われ、受信時に無視する必要があります。受信したオクテットの数よりも大きい値に設定された長さフィールドのメッセージは、静かに破棄する必要があります。
Type
タイプ
The Type field is one octet. This field indicates the Type of Request or Response. A single Type MUST be specified for each EAP Request or Response. An initial specification of Types follows in Section 5 of this document.
タイプフィールドは1オクテットです。このフィールドは、リクエストまたは応答のタイプを示します。EAP要求または応答ごとに、単一のタイプを指定する必要があります。このドキュメントのセクション5には、タイプの初期仕様が続きます。
The Type field of a Response MUST either match that of the Request, or correspond to a legacy or Expanded Nak (see Section 5.3) indicating that a Request Type is unacceptable to the peer. A peer MUST NOT send a Nak (legacy or expanded) in response to a Request, after an initial non-Nak Response has been sent. An EAP server receiving a Response not meeting these requirements MUST silently discard it.
応答のタイプフィールドは、リクエストのタイプのフィールドと一致するか、レガシーまたは拡張されたNAK（セクション5.3を参照）に対応する必要があります。ピアは、最初の非NAK応答が送信された後、要求に応じてNAK（レガシーまたは拡張）を送信してはなりません。これらの要件を満たさない応答を受信するEAPサーバーは、静かに廃棄する必要があります。
Type-Data
タイプデータ
The Type-Data field varies with the Type of Request and the associated Response.
タイプデータフィールドは、リクエストのタイプと関連する応答によって異なります。
The Success packet is sent by the authenticator to the peer after completion of an EAP authentication method (Type 4 or greater) to indicate that the peer has authenticated successfully to the authenticator. The authenticator MUST transmit an EAP packet with the Code field set to 3 (Success). If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests), then after unsuccessful completion of the EAP method in progress, the implementation MUST transmit an EAP packet with the Code field set to 4 (Failure). An authenticator MAY wish to issue multiple Requests before sending a Failure response in order to allow for human typing mistakes. Success and Failure packets MUST NOT contain additional data.
成功パケットは、EAP認証方法（タイプ4以下）が完了した後、Authenticatorによってピアに送信され、ピアが認証機に正常に認証されていることを示します。Authenticatorは、コードフィールドを3（成功）でEAPパケットを送信する必要があります。Authenticatorがピアを認証できない場合（1つ以上のリクエストに対する容認できない応答）、進行中のEAPメソッドの完了に失敗した後、実装はコードフィールドを4（障害）に設定してEAPパケットを送信する必要があります。Authenticatorは、人間のタイピングミスを許可するために、失敗応答を送信する前に複数のリクエストを発行することをお勧めします。成功と失敗のパケットには、追加のデータが含まれてはなりません。
Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point. A peer EAP implementation receiving a Success or Failure packet where sending one is not explicitly permitted MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" Success packet (a Success packet sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending a Success packet prior to conclusion of the EAP method conversation.
指定された方法の指定がその時点でメソッドを明示的に許可しない場合、成功と失敗のパケットをEAP認証器から送信してはなりません。成功または失敗のパケットを受信するピアEAP実装は、それを明示的に許可されていない場合に、それを静かに廃棄する必要があります。デフォルトでは、EAPピアは「缶詰」の成功パケット（接続時にすぐに送信される成功パケット）を静かに廃棄する必要があります。これにより、EAPメソッド会話の終了前に成功パケットを送信することにより、不正な認証者が相互認証をバイパスできないようになります。
Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. See also Section 3.4 for guidance on the processing of lower layer success and failure indications.
実装注：成功と失敗のパケットは認められていないため、認証者によって再送信されず、潜在的に失われる可能性があります。このメモで説明されているように、ピアはこの状況を許可する必要があります。下層の成功と障害の表示の処理に関するガイダンスについては、セクション3.4も参照してください。
As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. EAP methods may implement result indications. After the authenticator sends a failure result indication to the peer, regardless of the response from the peer, it MUST subsequently send a Failure packet. After the authenticator sends a success result indication to the peer and receives a success result indication from the peer, it MUST subsequently send a Success packet.
セクション2.1で説明されているように、EAP会話内で1つのEAP認証方法のみが許可されます。EAPメソッドは、結果の表示を実装する場合があります。認証者がピアからの応答に関係なく、障害結果の表示をピアに送信した後、その後障害パケットを送信する必要があります。Authenticatorが成功結果の表示をピアに送信し、ピアから成功結果の表示を受け取った後、その後成功パケットを送信する必要があります。
On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a failure result indication, or the peer decides that it does not want to continue the conversation, possibly after sending a failure result indication), the peer MUST terminate the conversation and indicate failure to the lower layer. The peer MUST silently discard Success packets and MAY silently discard Failure packets. As a result, loss of a Failure packet need not result in a timeout.
ピアでは、メソッドが失敗した場合（つまり、認証者が障害結果の表示を送信するか、ピアが会話を続けたくないと判断します。会話と下層への失敗を示します。ピアは静かに成功パケットを捨てなければならず、故障パケットを静かに捨てることができます。その結果、障害パケットの損失はタイムアウトになる必要はありません。
On the peer, after success result indications have been exchanged by both sides, a Failure packet MUST be silently discarded. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully.
ピアでは、成功結果の表示が両側によって交換された後、故障パケットを静かに破棄する必要があります。ピアは、EAPの成功が受け取られなかった場合に、EAP成功パケットが失われ、認証が正常に終了したと結論付けます。
If the authenticator has not sent a result indication, and the peer is willing to continue the conversation, the peer waits for a Success or Failure packet once the method completes, and MUST NOT silently discard either of them. In the event that neither a Success nor Failure packet is received, the peer SHOULD terminate the conversation to avoid lengthy timeouts in case the lost packet was an EAP Failure.
認証者が結果の表示を送信しておらず、ピアが会話を続けることをいとわない場合、ピアはメソッドが完了したら成功または失敗のパケットを待ちます。成功も失敗のパケットも受信していない場合、ピアは失われたパケットがEAP失敗である場合に長時間のタイムアウトを避けるために会話を終了する必要があります。
If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet. However, an authenticator MAY omit having the peer authenticate to it in situations where limited access is offered (e.g., guest access). In this case, the authenticator MUST send a Success packet.
ピアが認証者に認証を試み、そうしなかった場合、認証者は失敗パケットを送信する必要があり、成功パケットを送信してアクセスを許可してはなりません。ただし、認証者は、限られたアクセスが提供されている状況で、ピアに認証を取得することを省略する場合があります（ゲストアクセスなど）。この場合、Authenticatorは成功パケットを送信する必要があります。
Where the peer authenticates successfully to the authenticator, but the authenticator does not send a result indication, the authenticator MAY deny access by sending a Failure packet where the peer is not currently authorized for network access.
ピアが認証者に正常に認証を受けるが、認証者が結果の表示を送信しない場合、認証者は、ピアが現在ネットワークアクセスを許可されていない障害パケットを送信することによりアクセスを拒否する場合があります。
A summary of the Success and Failure packet format is shown below. The fields are transmitted from left to right.
成功と失敗のパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
3 for Success 4 for Failure
3成功のために失敗のための4
Identifier
識別子
The Identifier field is one octet and aids in matching replies to Responses. The Identifier field MUST match the Identifier field of the Response packet that it is sent in response to.
識別子フィールドは1つのオクテットであり、応答に対する応答を一致させるのに役立ちます。識別子フィールドは、応答して送信される応答パケットの識別子フィールドと一致する必要があります。
Length
長さ
4
4
Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. By default, where EAP is run over an unreliable lower layer, the EAP retransmission timer SHOULD be dynamically estimated. A maximum of 3-5 retransmissions is suggested.
認証プロセスには多くの場合、ユーザーの入力が含まれるため、再送信戦略と認証タイムアウトを決定する際には、ある程度の注意が必要です。デフォルトでは、EAPが信頼できない下層層上で実行される場合、EAP再送信タイマーを動的に推定する必要があります。最大3〜5回の再送信が提案されています。
When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. The peer may still maintain a timeout value so as to avoid waiting indefinitely for a Request.
信頼性の高い下層層（例えば、[PIC]内のISAKMP/TCPを介したEAP）を介して実行する場合、Authenticatorの再送信タイマーは無限の値に設定する必要があります。ピアは、リクエストを無期限に待つことを避けるために、まだタイムアウト値を維持する場合があります。
Where the authentication process requires user input, the measured round trip times may be determined by user responsiveness rather than network characteristics, so that dynamic RTO estimation may not be helpful. Instead, the retransmission timer SHOULD be set so as to provide sufficient time for the user to respond, with longer timeouts required in certain cases, such as where Token Cards (see Section 5.6) are involved.
認証プロセスにユーザー入力が必要な場合、測定された往復時間は、ネットワーク特性ではなくユーザーの応答性によって決定される可能性があるため、動的なRTO推定は役に立たない場合があります。代わりに、トークンカード（セクション5.6を参照）が関与する場所など、特定のケースで長いタイムアウトが必要な場合、ユーザーが応答するのに十分な時間を提供するために再送信タイマーを設定する必要があります。
In order to provide the EAP authenticator with guidance as to the appropriate timeout value, a hint can be communicated to the authenticator by the backend authentication server (such as via the RADIUS Session-Timeout attribute).
EAP Authenticatorに適切なタイムアウト値に関するガイダンスを提供するために、ヒントをバックエンド認証サーバー（RADIUS Session-Timeout属性など）によって認証器に伝えることができます。
In order to dynamically estimate the EAP retransmission timer, the algorithms for the estimation of SRTT, RTTVAR, and RTO described in [RFC2988] are RECOMMENDED, including use of Karn's algorithm, with the following potential modifications:
EAP再送信タイマーを動的に推定するために、[RFC2988]で説明されているSRTT、RTTVAR、およびRTOの推定のアルゴリズムが推奨されます。
[a] In order to avoid synchronization behaviors that can occur with fixed timers among distributed systems, the retransmission timer is calculated with a jitter by using the RTO value and randomly adding a value drawn between -RTOmin/2 and RTOmin/2. Alternative calculations to create jitter MAY be used. These MUST be pseudo-random. For a discussion of pseudo-random number generation, see [RFC1750].
[a] 分散システム間で固定タイマーで発生する可能性のある同期の動作を回避するために、RTO値を使用して-RTOMIN/2とRTOMIN/2の間に描かれた値をランダムに追加することにより、ジッターで再送信タイマーが計算されます。ジッターを作成するための代替計算を使用する場合があります。これらは疑似ランダムでなければなりません。擬似ランダム数生成の議論については、[RFC1750]を参照してください。
[b] When EAP is transported over a single link (as opposed to over the Internet), smaller values of RTOinitial, RTOmin, and RTOmax MAY be used. Recommended values are RTOinitial=1 second, RTOmin=200ms, and RTOmax=20 seconds.
[b] EAPが（インターネット上ではなく）単一のリンクで輸送される場合、RTOINITIAL、RTOMIN、およびRTOMAXのより小さな値を使用できます。推奨される値は、rtoInitial = 1秒、rtomin = 200ms、rtomax = 20秒です。
[c] When EAP is transported over a single link (as opposed to over the Internet), estimates MAY be done on a per-authenticator basis, rather than a per-session basis. This enables the retransmission estimate to make the most use of information on link-layer behavior.
[c] EAPが単一のリンクで（インターネット上ではなく）輸送される場合、セッションごとではなく、認定ごとに推定値が行われる場合があります。これにより、再送信の見積もりがリンク層動作に関する情報を最大限に活用できるようになります。
[d] An EAP implementation MAY clear SRTT and RTTVAR after backing off the timer multiple times, as it is likely that the current SRTT and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are cleared, they should be initialized with the next RTT sample taken as described in [RFC2988] equation 2.2.
[d] EAPの実装は、現在のSRTTとRTTVARがこの状況では偽物である可能性が高いため、タイマーを複数回支援した後、SRTTとRTTVARをクリアする可能性があります。SRTTとRTTVARがクリアされると、[RFC2988]式2.2で説明されているように、次のRTTサンプルで初期化する必要があります。
This section defines the initial set of EAP Types used in Request/ Response exchanges. More Types may be defined in future documents. The Type field is one octet and identifies the structure of an EAP Request or Response packet. The first 3 Types are considered special case Types.
このセクションでは、リクエスト/応答交換で使用されるEAPタイプの初期セットを定義します。将来のドキュメントでは、より多くのタイプが定義される場合があります。タイプフィールドは1オクテットで、EAPリクエストまたは応答パケットの構造を識別します。最初の3つのタイプは、特別なケースタイプと見なされます。
The remaining Types define authentication exchanges. Nak (Type 3) or Expanded Nak (Type 254) are valid only for Response packets, they MUST NOT be sent in a Request.
残りのタイプは、認証交換を定義します。NAK（タイプ3）または拡張されたNAK（タイプ254）は、応答パケットに対してのみ有効であり、リクエストで送信してはなりません。
All EAP implementations MUST support Types 1-4, which are defined in this document, and SHOULD support Type 254. Implementations MAY support other Types defined here or in future RFCs.
すべてのEAP実装は、このドキュメントで定義されているタイプ1〜4をサポートする必要があり、タイプ254をサポートする必要があります。実装は、ここまたは将来のRFCで定義されている他のタイプをサポートする場合があります。
1 Identity 2 Notification 3 Nak (Response only) 4 MD5-Challenge 5 One Time Password (OTP) 6 Generic Token Card (GTC) 254 Expanded Types 255 Experimental use
1アイデンティティ2通知3 NAK（応答のみ）4 MD5-Challenge 5ワンタイムパスワード（OTP）6ジェネリックトークンカード（GTC）254拡張タイプ255実験的使用
EAP methods MAY support authentication based on shared secrets. If the shared secret is a passphrase entered by the user, implementations MAY support entering passphrases with non-ASCII characters. In this case, the input should be processed using an appropriate stringprep [RFC3454] profile, and encoded in octets using UTF-8 encoding [RFC2279]. A preliminary version of a possible stringprep profile is described in [SASLPREP].
EAPメソッドは、共有秘密に基づいた認証をサポートする場合があります。共有秘密がユーザーによって入力されたパスフレーズである場合、実装は非ASCII文字を持つパスフレーズへの入場をサポートする場合があります。この場合、入力は適切なStringPrep [RFC3454]プロファイルを使用して処理し、UTF-8エンコード[RFC2279]を使用してオクテットでエンコードする必要があります。可能なStringPrepプロファイルの予備バージョンは、[saslprep]で説明されています。
Description
説明
The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the peer in the case where there is an expectation of interaction with a user. A Response of Type 1 (Identity) SHOULD be sent in Response to a Request with a Type of 1 (Identity).
IDタイプは、ピアの身元を照会するために使用されます。一般に、認証者はこれを最初のリクエストとして発行します。ユーザーとのやり取りが期待されている場合にピアに促すために、オプションの表示可能なメッセージを含めることができます。タイプ1（ID）の応答は、タイプ1（ID）のリクエストに応じて送信する必要があります。
Some EAP implementations piggy-back various options into the Identity Request after a NUL-character. By default, an EAP implementation SHOULD NOT assume that an Identity Request or Response can be larger than 1020 octets.
いくつかのEAP実装では、Nul-Characterの後にさまざまなオプションをIDリクエストに貯めます。デフォルトでは、EAPの実装では、IDリクエストまたは応答が1020オクテットを超えると想定してはなりません。
It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use. EAP Methods SHOULD include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response. Identity Requests and Responses are sent in cleartext, so an attacker may snoop on the identity, or even modify or spoof identity exchanges. To address these threats, it is preferable for an EAP method to include an identity exchange that supports per-packet authentication, integrity and replay protection, and confidentiality. The Identity Response may not be the appropriate identity for the method; it may have been truncated or obfuscated so as to provide privacy, or it may have been decorated for routing purposes. Where the peer is configured to only accept authentication methods supporting protected identity exchanges, the peer MAY provide an abbreviated Identity Response (such as omitting the peer-name portion of the NAI [RFC2486]). For further discussion of identity protection, see Section 7.3.
アイデンティティ応答は、主にルーティング目的と使用するEAPメソッドを選択するために使用することをお勧めします。EAPメソッドには、アイデンティティを取得するためのメソッド固有のメカニズムを含めて、アイデンティティ応答に依存する必要がないようにする必要があります。IDリクエストと応答はClearTextで送信されるため、攻撃者はIDをsn索するか、同一性交換を変更またはスプーフィングすることさえできます。これらの脅威に対処するには、EAPメソッドがパケットごとの認証、完全性とリプレイの保護、および機密性をサポートするID交換を含めることが望ましいです。アイデンティティ応答は、メソッドの適切なアイデンティティではない場合があります。プライバシーを提供するために切り捨てられたり、難読化されたりするか、ルーティングのために装飾されている可能性があります。ピアが保護されたアイデンティティ交換をサポートする認証方法のみを受け入れるように構成されている場合、ピアは略語されたアイデンティティ応答（NAI [RFC2486]のピアネーム部分を省略するなど）を提供する場合があります。アイデンティティ保護の詳細については、セクション7.3を参照してください。
Implementation Note: The peer MAY obtain the Identity via user input. It is suggested that the authenticator retry the Identity Request in the case of an invalid Identity or authentication failure to allow for potential typos on the part of the user. It is suggested that the Identity Request be retried a minimum of 3 times before terminating the authentication. The Notification Request MAY be used to indicate an invalid authentication attempt prior to transmitting a new Identity Request (optionally, the failure MAY be indicated within the message of the new Identity Request itself).
実装注：ピアは、ユーザー入力を介してIDを取得できます。認証者は、ユーザー側の潜在的なタイプミスを許可しない無効なIDまたは認証の失敗の場合にIDリクエストを再試行することをお勧めします。認証を終了する前に、IDリクエストを最低3回再試行することが提案されています。通知要求を使用して、新しいIDリクエストを送信する前に無効な認証試行を示すことができます（オプションで、新しいIDリクエスト自体のメッセージ内で障害が示される場合があります）。
Type
タイプ
1
1
Type-Data
タイプデータ
This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In all cases, the length of the Type-Data field is derived from the Length field of the Request/Response packet.
このフィールドには、UTF-8エンコードされたISO 10646文字[RFC2279]を含むリクエストに表示可能なメッセージが含まれる場合があります。リクエストにヌルが含まれている場合、nullの前のフィールドの部分のみが表示されます。アイデンティティが不明な場合、ID応答フィールドの長さはゼロバイトでなければなりません。ID応答フィールドは、終了してはなりません。すべての場合において、タイプデータフィールドの長さは、リクエスト/応答パケットの長さフィールドから派生します。
Security Claims (see Section 7.2):
セキュリティクレーム（セクション7.2を参照）：
Auth. mechanism: None Ciphersuite negotiation: No Mutual authentication: No Integrity protection: No Replay protection: No Confidentiality: No Key derivation: No Key strength: N/A Dictionary attack prot.: N/A Fast reconnect: No Crypt. binding: N/A Session independence: N/A Fragmentation: No Channel binding: No
認証。メカニズム：なしciphersuite交渉：相互認証なし：整合性保護なし：リプレイ保護なし：機密性なし：キー派生なし：キー強度なし：n/a辞書攻撃PROT。：n/a高速再接続：クリプトなし。バインディング：n/aセッション独立性：n/aフラグメンテーション：チャネルバインディングなし：いいえ
Description
説明
The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. An authenticator MAY send a Notification Request to the peer at any time when there is no outstanding Request, prior to completion of an EAP authentication method. The peer MUST respond to a Notification Request with a Notification Response unless the EAP authentication method specification prohibits the use of Notification messages. In any case, a Nak Response MUST NOT be sent in response to a Notification Request. Note that the default maximum length of a Notification Request is 1020 octets. By default, this leaves at most 1015 octets for the human readable message.
通知タイプは、オプションで、認証者からピアに表示可能なメッセージを伝えるために使用されます。Authenticatorは、EAP認証方法が完了する前に、未解決のリクエストがない場合、いつでもピアに通知リクエストを送信する場合があります。PEERは、EAP認証方法の仕様が通知メッセージの使用を禁止しない限り、通知応答を使用して通知リクエストに応答する必要があります。いずれにせよ、NAK応答を通知要求に応じて送信してはなりません。通知要求のデフォルトの最大長は1020オクテットであることに注意してください。デフォルトでは、これは人間の読み取り可能なメッセージのために最大1015オクテットを残します。
An EAP method MAY indicate within its specification that Notification messages must not be sent during that method. In this case, the peer MUST silently discard Notification Requests from the point where an initial Request for that Type is answered with a Response of the same Type.
EAPメソッドは、その方法中に通知メッセージを送信してはならないことをその仕様内で示す場合があります。この場合、ピアは、そのタイプの最初の要求が同じタイプの応答で回答されるポイントから静かに通知要求を捨てなければなりません。
The peer SHOULD display this message to the user or log it if it cannot be displayed. The Notification Type is intended to provide an acknowledged notification of some imperative nature, but it is not an error indication, and therefore does not change the state of the peer. Examples include a password with an expiration time that is about to expire, an OTP sequence integer which is nearing 0, an authentication failure warning, etc. In most circumstances, Notification should not be required.
ピアは、このメッセージをユーザーに表示するか、表示できない場合はログに記録する必要があります。通知タイプは、何らかの不可欠な性質の確認された通知を提供することを目的としていますが、エラーの表示ではないため、ピアの状態を変更しません。例には、有効期限が切れる時間のパスワード、0に近づいているOTPシーケンス整数、認証障害警告などが含まれます。ほとんどの場合、通知は必要ありません。
Type
タイプ
2
2
Type-Data
タイプデータ
The Type-Data field in the Request contains a displayable message greater than zero octets in length, containing UTF-8 encoded ISO 10646 characters [RFC2279]. The length of the message is determined by the Length field of the Request packet. The message MUST NOT be null terminated. A Response MUST be sent in reply to the Request with a Type field of 2 (Notification). The Type-Data field of the Response is zero octets in length. The Response should be sent immediately (independent of how the message is displayed or logged).
リクエストのタイプデータフィールドには、UTF-8エンコードされたISO 10646文字[RFC2279]を含む、長さがゼロオクテットより大きい表示可能なメッセージが含まれています。メッセージの長さは、リクエストパケットの長さフィールドによって決定されます。メッセージを終了してはなりません。2のタイプフィールド（通知）を使用して、リクエストへの返信で応答を送信する必要があります。応答のタイプデータフィールドの長さはゼロオクテットです。応答はすぐに送信する必要があります（メッセージの表示またはログの表示方法とは無関係です）。
Security Claims (see Section 7.2):
セキュリティクレーム（セクション7.2を参照）：
Auth. mechanism: None Ciphersuite negotiation: No Mutual authentication: No Integrity protection: No Replay protection: No Confidentiality: No Key derivation: No Key strength: N/A Dictionary attack prot.: N/A Fast reconnect: No Crypt. binding: N/A Session independence: N/A Fragmentation: No Channel binding: No
認証。メカニズム：なしciphersuite交渉：相互認証なし：整合性保護なし：リプレイ保護なし：機密性なし：キー派生なし：キー強度なし：n/a辞書攻撃PROT。：n/a高速再接続：クリプトなし。バインディング：n/aセッション独立性：n/aフラグメンテーション：チャネルバインディングなし：いいえ
Description
説明
The legacy Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains one or more authentication Types desired by the Peer. Type zero (0) is used to indicate that the sender has no viable alternatives, and therefore the authenticator SHOULD NOT send another Request after receiving a Nak Response containing a zero value.
レガシーNAKタイプは、応答メッセージでのみ有効です。目的の認証タイプが受け入れられないリクエストに返信されます。認証タイプには4以上の番号が付けられています。応答には、ピアが望む1つ以上の認証タイプが含まれています。タイプゼロ（0）は、送信者に実行可能な選択肢がないことを示すために使用されるため、ゼロ値を含むNAK応答を受け取った後、認証者は別の要求を送信しないでください。
Since the legacy Nak Type is valid only in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method.
レガシーNAKタイプは応答でのみ有効であり、機能が非常に限られているため、エラーメッセージの通信や特定のEAPメソッドに固有のパラメーターのネゴシエーションなど、汎用エラー表示として使用してはなりません。
Code
コード
2 for Response.
2応答用。
Identifier
識別子
The Identifier field is one octet and aids in matching Responses with Requests. The Identifier field of a legacy Nak Response MUST match the Identifier field of the Request packet that it is sent in response to.
識別子フィールドは1つのオクテットであり、リクエストとの対応を一致させるのに役立ちます。レガシーNAK応答の識別子フィールドは、応答して送信されるリクエストパケットの識別子フィールドと一致する必要があります。
Length
長さ
>=6
> = 6
Type
タイプ
3
3
Type-Data
タイプデータ
Where a peer receives a Request for an unacceptable authentication Type (4-253,255), or a peer lacking support for Expanded Types receives a Request for Type 254, a Nak Response (Type 3) MUST be sent. The Type-Data field of the Nak Response (Type 3) MUST contain one or more octets indicating the desired authentication Type(s), one octet per Type, or the value zero (0) to indicate no proposed alternative. A peer supporting Expanded Types that receives a Request for an unacceptable authentication Type (4-253, 255) MAY include the value 254 in the Nak Response (Type 3) to indicate the desire for an Expanded authentication Type. If the authenticator can accommodate this preference, it will respond with an Expanded Type Request (Type 254).
ピアが容認できない認証タイプ（4-253,255）のリクエストを受け取る場合、または拡張されたタイプのサポートがないピアがタイプ254のリクエストを受け取る場合、NAK応答（タイプ3）を送信する必要があります。NAK応答のタイプデータフィールド（タイプ3）には、目的の認証タイプ、タイプごとに1オクテット、または値ゼロ（0）を示す1つ以上のオクテットが含まれている必要があります。容認できない認証タイプ（4-253、255）のリクエストを受信するピアをサポートするピアには、拡張された認証タイプの欲求を示すために、NAK応答（タイプ3）の値254が含まれる場合があります。認証者がこの好みに対応できる場合、拡張されたタイプ要求（タイプ254）で応答します。
Security Claims (see Section 7.2):
セキュリティクレーム（セクション7.2を参照）：
Auth. mechanism: None Ciphersuite negotiation: No Mutual authentication: No Integrity protection: No Replay protection: No Confidentiality: No Key derivation: No Key strength: N/A Dictionary attack prot.: N/A Fast reconnect: No Crypt. binding: N/A Session independence: N/A Fragmentation: No Channel binding: No
認証。メカニズム：なしciphersuite交渉：相互認証なし：整合性保護なし：リプレイ保護なし：機密性なし：キー派生なし：キー強度なし：n/a辞書攻撃PROT。：n/a高速再接続：クリプトなし。バインディング：n/aセッション独立性：n/aフラグメンテーション：チャネルバインディングなし：いいえ
Description
説明
The Expanded Nak Type is valid only in Response messages. It MUST be sent only in reply to a Request of Type 254 (Expanded Type) where the authentication Type is unacceptable. The Expanded Nak Type uses the Expanded Type format itself, and the Response contains one or more authentication Types desired by the peer, all in Expanded Type format. Type zero (0) is used to indicate that the sender has no viable alternatives. The general format of the Expanded Type is described in Section 5.7.
拡張されたNAKタイプは、応答メッセージでのみ有効です。認証タイプが受け入れられないタイプ254（拡張型）のリクエストに応答してのみ送信する必要があります。拡張されたNAKタイプは、拡張されたタイプ形式自体を使用し、応答にはピアが望む1つ以上の認証タイプが含まれ、すべて拡張されたタイプ形式です。タイプゼロ（0）は、送信者に実行可能な選択肢がないことを示すために使用されます。拡張型の一般的な形式については、セクション5.7で説明します。
Since the Expanded Nak Type is valid only in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method.
拡張されたNAKタイプは応答でのみ有効であり、機能が非常に限られているため、エラーメッセージの通信や特定のEAPメソッドに固有のパラメーターのネゴシエーションなど、汎用エラー表示として使用してはなりません。
Code
コード
2 for Response.
2応答用。
Identifier
識別子
The Identifier field is one octet and aids in matching Responses with Requests. The Identifier field of an Expanded Nak Response MUST match the Identifier field of the Request packet that it is sent in response to.
識別子フィールドは1つのオクテットであり、リクエストとの対応を一致させるのに役立ちます。拡張されたNAK応答の識別子フィールドは、応答して送信されるリクエストパケットの識別子フィールドと一致する必要があります。
Length
長さ
>=20
> = 20
Type
タイプ
254
254
Vendor-Id
ベンダーID
0 (IETF)
0（ietf）
Vendor-Type
ベンダータイプ
3 (Nak)
3（nak）
Vendor-Data
ベンダーデイタ
The Expanded Nak Type is only sent when the Request contains an Expanded Type (254) as defined in Section 5.7. The Vendor-Data field of the Nak Response MUST contain one or more authentication Types (4 or greater), all in expanded format, 8 octets per Type, or the value zero (0), also in Expanded Type format, to indicate no proposed alternative. The desired authentication Types may include a mixture of Vendor-Specific and IETF Types. For example, an Expanded Nak Response indicating a preference for OTP (Type 5), and an MIT (Vendor-Id=20) Expanded Type of 6 would appear as follows:
拡張されたNAKタイプは、セクション5.7で定義されているように、リクエストに拡張型（254）が含まれている場合にのみ送信されます。NAK応答のベンダーDATAフィールドには、1つまたは複数の認証タイプ（4以下）、すべて拡張形式、タイプあたり8オクター、または拡張されたタイプ形式での値ゼロ（0）を含める必要があります。代替。目的の認証タイプには、ベンダー固有とIETFタイプの混合物が含まれる場合があります。たとえば、OTP（タイプ5）の好みを示す拡張されたNAK応答、およびMIT（Vendor-ID = 20）の拡張タイプ6は次のように表示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Identifier | Length=28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 (OTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 20 (MIT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An Expanded Nak Response indicating a no desired alternative would appear as follows:
望ましい代替案がないことを示す拡張されたNAK応答は、次のように表示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Identifier | Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (No alternative) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Claims (see Section 7.2):
セキュリティクレーム（セクション7.2を参照）：
Auth. mechanism: None Ciphersuite negotiation: No Mutual authentication: No Integrity protection: No Replay protection: No Confidentiality: No Key derivation: No Key strength: N/A Dictionary attack prot.: N/A Fast reconnect: No Crypt. binding: N/A Session independence: N/A Fragmentation: No Channel binding: No
認証。メカニズム：なしciphersuite交渉：相互認証なし：整合性保護なし：リプレイ保護なし：機密性なし：キー派生なし：キー強度なし：n/a辞書攻撃PROT。：n/a高速再接続：クリプトなし。バインディング：n/aセッション独立性：n/aフラグメンテーション：チャネルバインディングなし：いいえ
Description
説明
The MD5-Challenge Type is analogous to the PPP CHAP protocol [RFC1994] (with MD5 as the specified algorithm). The Request contains a "challenge" message to the peer. A Response MUST be sent in reply to the Request. The Response MAY be either of Type 4 (MD5-Challenge), Nak (Type 3), or Expanded Nak (Type 254). The Nak reply indicates the peer's desired authentication Type(s). EAP peer and EAP server implementations MUST support the MD5- Challenge mechanism. An authenticator that supports only pass-through MUST allow communication with a backend authentication server that is capable of supporting MD5-Challenge, although the EAP authenticator implementation need not support MD5-Challenge itself. However, if the EAP authenticator can be configured to authenticate peers locally (e.g., not operate in pass-through), then the requirement for support of the MD5-Challenge mechanism applies.
MD5-Challengeタイプは、PPP Chapプロトコル[RFC1994]（MD5を指定されたアルゴリズムとして）に類似しています。リクエストには、ピアへの「チャレンジ」メッセージが含まれています。リクエストへの返信で応答を送信する必要があります。応答は、タイプ4（MD5チャレンジ）、NAK（タイプ3）、または拡張されたNAK（タイプ254）のいずれかです。NAK応答は、ピアの希望する認証タイプを示します。EAPピアおよびEAPサーバーの実装は、MD5-チャレンジメカニズムをサポートする必要があります。パススルーのみをサポートする認証機は、MD5-Challengeをサポートできるバックエンド認証サーバーとの通信を可能にする必要がありますが、EAP認証機の実装はMD5-Challenge自体をサポートする必要はありません。ただし、EAP認証器をローカルで認証するように構成できる場合（たとえば、パススルーで動作しない）、MD5-Challengeメカニズムのサポートの要件が適用されます。
Note that the use of the Identifier field in the MD5-Challenge Type is different from that described in [RFC1994]. EAP allows for retransmission of MD5-Challenge Request packets, while [RFC1994] states that both the Identifier and Challenge fields MUST change each time a Challenge (the CHAP equivalent of the MD5-Challenge Request packet) is sent.
MD5-Challengeタイプでの識別子フィールドの使用は、[RFC1994]に記載されているものとは異なることに注意してください。EAPはMD5-Challenge要求パケットの再送信を可能にしますが、[RFC1994]は、識別子とチャレンジフィールドの両方がチャレンジ（MD5-Challengeリクエストパケットに相当するチャップ）が送信されるたびに変更する必要があると述べています。
Note: [RFC1994] treats the shared secret as an octet string, and does not specify how it is entered into the system (or if it is handled by the user at all). EAP MD5-Challenge implementations MAY support entering passphrases with non-ASCII characters. See Section 5 for instructions how the input should be processed and encoded into octets.
注：[RFC1994]は、共有秘密をオクテット文字列として扱い、システムに入力する方法を指定していません（またはユーザーによって処理された場合）。EAP MD5-Challengeの実装は、ASCII以外の文字を備えたパスフレーズへの侵入をサポートする場合があります。入力を処理してオクテットにエンコードする方法については、セクション5を参照してください。
Type
タイプ
4
4
Type-Data
タイプデータ
The contents of the Type-Data field is summarized below. For reference on the use of these fields, see the PPP Challenge Handshake Authentication Protocol [RFC1994].
タイプデータフィールドの内容を以下にまとめます。これらのフィールドの使用に関する参照については、PPPチャレンジハンドシェイク認証プロトコル[RFC1994]を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Claims (see Section 7.2):
セキュリティクレーム（セクション7.2を参照）：
Auth. mechanism: Password or pre-shared key. Ciphersuite negotiation: No Mutual authentication: No Integrity protection: No Replay protection: No Confidentiality: No Key derivation: No Key strength: N/A Dictionary attack prot.: No Fast reconnect: No Crypt. binding: N/A Session independence: N/A Fragmentation: No Channel binding: No
認証。メカニズム：パスワードまたは事前に共有キー。ciphersuiteの交渉：相互認証なし：整合性保護なし：リプレイ保護なし：機密性なし：キー派生なし：キー強度なし：n/a辞書攻撃プロト。バインディング：n/aセッション独立性：n/aフラグメンテーション：チャネルバインディングなし：いいえ
Description
説明
The One-Time Password system is defined in "A One-Time Password System" [RFC2289] and "OTP Extended Responses" [RFC2243]. The Request contains an OTP challenge in the format described in [RFC2289]. A Response MUST be sent in reply to the Request. The Response MUST be of Type 5 (OTP), Nak (Type 3), or Expanded Nak (Type 254). The Nak Response indicates the peer's desired authentication Type(s). The EAP OTP method is intended for use with the One-Time Password system only, and MUST NOT be used to provide support for cleartext passwords.
1回限りのパスワードシステムは、「1回限りのパスワードシステム」[RFC2289]および「OTP拡張応答」[RFC2243]で定義されています。この要求には、[RFC2289]で説明されている形式のOTPチャレンジが含まれています。リクエストへの返信で応答を送信する必要があります。応答は、5型（OTP）、NAK（タイプ3）、または拡張されたNAK（タイプ254）でなければなりません。NAK応答は、ピアの望ましい認証タイプを示します。EAP OTPメソッドは、ワンタイムパスワードシステムのみで使用することを目的としており、クリアテキストパスワードのサポートを提供するために使用してはなりません。
Type
タイプ
5
5
Type-Data
タイプデータ
The Type-Data field contains the OTP "challenge" as a displayable message in the Request. In the Response, this field is used for the 6 words from the OTP dictionary [RFC2289]. The messages MUST NOT be null terminated. The length of the field is derived from the Length field of the Request/Reply packet.
Type-Dataフィールドには、リクエストの表示可能なメッセージとしてOTP「チャレンジ」が含まれています。応答では、このフィールドは、OTP辞書[RFC2289]の6つの単語に使用されます。メッセージを終了してはなりません。フィールドの長さは、リクエスト/返信パケットの長さフィールドから派生します。
Note: [RFC2289] does not specify how the secret pass-phrase is entered by the user, or how the pass-phrase is converted into octets. EAP OTP implementations MAY support entering passphrases with non-ASCII characters. See Section 5 for instructions on how the input should be processed and encoded into octets.
注：[RFC2289]は、秘密のパスフレーズがユーザーによってどのように入力されるか、またはパスフラゼがオクテットに変換される方法を指定していません。EAP OTP実装は、ASCII以外の文字を備えたパスフレーズへの侵入をサポートする場合があります。入力をオクテットに処理してエンコードする方法については、セクション5を参照してください。
Security Claims (see Section 7.2):
セキュリティクレーム（セクション7.2を参照）：
Auth. mechanism: One-Time Password Ciphersuite negotiation: No Mutual authentication: No Integrity protection: No Replay protection: Yes Confidentiality: No Key derivation: No Key strength: N/A Dictionary attack prot.: No Fast reconnect: No Crypt. binding: N/A Session independence: N/A Fragmentation: No Channel binding: No
認証。メカニズム：1回限りのパスワードCiphersuite交渉：相互認証なし：整合性保護なし：リプレイ保護なし：はい機密性：キー派生なし：キー強度なし：n/a辞書攻撃PROT。バインディング：n/aセッション独立性：n/aフラグメンテーション：チャネルバインディングなし：いいえ
Description
説明
The Generic Token Card Type is defined for use with various Token Card implementations which require user input. The Request contains a displayable message and the Response contains the Token Card information necessary for authentication. Typically, this would be information read by a user from the Token card device and entered as ASCII text. A Response MUST be sent in reply to the Request. The Response MUST be of Type 6 (GTC), Nak (Type 3), or Expanded Nak (Type 254). The Nak Response indicates the peer's desired authentication Type(s). The EAP GTC method is intended for use with the Token Cards supporting challenge/response authentication and MUST NOT be used to provide support for cleartext passwords in the absence of a protected tunnel with server authentication.
一般的なトークンカードの種類は、ユーザー入力を必要とするさまざまなトークンカードの実装で使用するために定義されています。リクエストには表示可能なメッセージが含まれており、応答には認証に必要なトークンカード情報が含まれています。通常、これはトークンカードデバイスからユーザーが読み取り、ASCIIテキストとして入力する情報になります。リクエストへの返信で応答を送信する必要があります。応答は、タイプ6（GTC）、NAK（タイプ3）、または拡張されたNAK（タイプ254）でなければなりません。NAK応答は、ピアの望ましい認証タイプを示します。EAP GTCメソッドは、チャレンジ/応答認証をサポートするトークンカードで使用することを目的としており、サーバー認証を備えた保護されたトンネルがない場合にクリアテキストパスワードをサポートするために使用してはなりません。
Type
タイプ
6
6
Type-Data
タイプデータ
The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by the Length field of the Request packet. The message MUST NOT be null terminated. A Response MUST be sent in reply to the Request with a Type field of 6 (Generic Token Card). The Response contains data from the Token Card required for authentication. The length of the data is determined by the Length field of the Response packet.
リクエストのタイプデータフィールドには、長さがゼロオクテットよりも大きい表示可能なメッセージが含まれています。メッセージの長さは、リクエストパケットの長さフィールドによって決定されます。メッセージを終了してはなりません。6のタイプフィールド（汎用トークンカード）を使用して、リクエストへの応答で応答を送信する必要があります。応答には、認証に必要なトークンカードからのデータが含まれています。データの長さは、応答パケットの長さフィールドによって決定されます。
EAP GTC implementations MAY support entering a response with non-ASCII characters. See Section 5 for instructions how the input should be processed and encoded into octets.
EAP GTC実装は、ASCII以外の文字を使用して応答の入力をサポートする場合があります。入力を処理してオクテットにエンコードする方法については、セクション5を参照してください。
Security Claims (see Section 7.2):
セキュリティクレーム（セクション7.2を参照）：
Auth. mechanism: Hardware token. Ciphersuite negotiation: No Mutual authentication: No Integrity protection: No Replay protection: No Confidentiality: No Key derivation: No Key strength: N/A Dictionary attack prot.: No Fast reconnect: No Crypt. binding: N/A Session independence: N/A Fragmentation: No Channel binding: No
認証。メカニズム：ハードウェアトークン。ciphersuiteの交渉：相互認証なし：整合性保護なし：リプレイ保護なし：機密性なし：キー派生なし：キー強度なし：n/a辞書攻撃プロト。バインディング：n/aセッション独立性：n/aフラグメンテーション：チャネルバインディングなし：いいえ
Description
説明
Since many of the existing uses of EAP are vendor-specific, the Expanded method Type is available to allow vendors to support their own Expanded Types not suitable for general usage.
EAPの既存の使用の多くはベンダー固有であるため、拡張されたメソッドタイプを利用でき、ベンダーが一般的な使用に適していない独自の拡張タイプをサポートできるようにします。
The Expanded Type is also used to expand the global Method Type space beyond the original 255 values. A Vendor-Id of 0 maps the original 255 possible Types onto a space of 2^32-1 possible Types. (Type 0 is only used in a Nak Response to indicate no acceptable alternative).
拡張されたタイプは、元の255値を超えてグローバルメソッドタイプ空間を拡張するためにも使用されます。0のベンダーIDは、元の255の可能なタイプを2^32-1可能なタイプのスペースにマッピングします。（タイプ0は、許容可能な代替手段がないことを示すためにNAK応答でのみ使用されます）。
An implementation that supports the Expanded attribute MUST treat EAP Types that are less than 256 equivalently, whether they appear as a single octet or as the 32-bit Vendor-Type within an Expanded Type where Vendor-Id is 0. Peers not equipped to interpret the Expanded Type MUST send a Nak as described in Section 5.3.1, and negotiate a more suitable authentication method.
拡張属性をサポートする実装は、単一のオクテットとして表示されるか、ベンダーIDが0の拡張型タイプ内で32ビットベンダータイプとして表示されるかどうかにかかわらず、同等に256未満のEAPタイプを扱う必要があります。拡張されたタイプは、セクション5.3.1で説明されているようにNAKを送信し、より適切な認証方法を交渉する必要があります。
A summary of the Expanded Type format is shown below. The fields are transmitted from left to right.
拡張されたタイプ形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
254 for Expanded Type
拡張型の254
Vendor-Id
ベンダーID
The Vendor-Id is 3 octets and represents the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as allocated by IANA. A Vendor-Id of zero is reserved for use by the IETF in providing an expanded global EAP Type space.
ベンダーIDは3オクテットで、IANAによって割り当てられたように、ネットワークバイトの順序でベンダーのSMIネットワーク管理プライベートエンタープライズコードを表します。ゼロのベンダーIDは、IETFが拡張されたグローバルEAPタイプスペースを提供するために使用するために予約されています。
Vendor-Type
ベンダータイプ
The Vendor-Type field is four octets and represents the vendor-specific method Type.
ベンダータイプのフィールドは4オクターで、ベンダー固有のメソッドタイプを表します。
If the Vendor-Id is zero, the Vendor-Type field is an extension and superset of the existing namespace for EAP Types. The first 256 Types are reserved for compatibility with single-octet EAP Types that have already been assigned or may be assigned in the future. Thus, EAP Types from 0 through 255 are semantically identical, whether they appear as single octet EAP Types or as Vendor-Types when Vendor-Id is zero. There is one exception to this rule: Expanded Nak and Legacy Nak packets share the same Type, but must be treated differently because they have a different format.
ベンダーIDがゼロの場合、ベンダータイプのフィールドは、EAPタイプの既存の名前空間の拡張機能とスーパーセットです。最初の256種類は、すでに割り当てられているか、将来割り当てられているシングルオクテットEAPタイプとの互換性のために予約されています。したがって、0〜255のEAPタイプは、単一のオクテットEAPタイプとして表示されるか、ベンダーIDがゼロの場合のベンダータイプとして表示されるかどうかにかかわらず、意味的に同一です。このルールには1つの例外があります。拡張されたNAKとレガシーNAKパケットは同じタイプを共有しますが、異なる形式があるため、異なる扱いをする必要があります。
Vendor-Data
ベンダーデイタ
The Vendor-Data field is defined by the vendor. Where a Vendor-Id of zero is present, the Vendor-Data field will be used for transporting the contents of EAP methods of Types defined by the IETF.
ベンダーデータフィールドはベンダーによって定義されます。ゼロのベンダーIDが存在する場合、IETFによって定義されたタイプのEAPメソッドの内容を輸送するために、ベンダーDATAフィールドが使用されます。
Description
説明
The Experimental Type has no fixed format or content. It is intended for use when experimenting with new EAP Types. This Type is intended for experimental and testing purposes. No guarantee is made for interoperability between peers using this Type, as outlined in [RFC3692].
実験タイプには、固定形式やコンテンツがありません。新しいEAPタイプを実験するときに使用することを目的としています。このタイプは、実験およびテストの目的を目的としています。[RFC3692]で概説されているように、このタイプを使用してピア間の相互運用性を保証することはできません。
Type
タイプ
255
255
Type-Data
タイプデータ
Undefined
未定義
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the EAP protocol, in accordance with BCP 26, [RFC2434].
このセクションでは、BCP 26 [RFC2434]に従って、EAPプロトコルに関連する値の登録に関するインターネット割り当てされた番号局（IANA）にガイダンスを提供します。
There are two name spaces in EAP that require registration: Packet Codes and method Types.
EAPには、登録が必要な2つの名前スペースがあります。パケットコードとメソッドタイプです。
EAP is not intended as a general-purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication.
EAPは汎用プロトコルとして意図されておらず、認証とは無関係の目的のために割り当てを行うべきではありません。
The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration".
ここでは、BCP 26で定義されている意味で次の用語を使用しています：「名前スペース」、「割り当てられた値」、「登録」。
The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action".
ここでは、BCP 26で定義されている意味で次のポリシーが使用されています。「プライベート使用」、「最初に来る」、「エキスパートレビュー」、「必要な仕様」、「IETFコンセンサス」、「標準アクション」。
For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. But in order to allow for the allocation of values prior to the RFC being approved for publication, the Designated Expert can approve allocations once it seems clear that an RFC will be published. The Designated expert will post a request to the EAP WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation, and in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided.
指定された専門家に相談する必要がある登録要求のために、責任あるIESGエリアディレクターは指定された専門家を任命する必要があります。意図は、すべての割り当てに公開されたRFCが伴うことです。しかし、RFCが公開される前に値の割り当てを許可するために、指定された専門家は、RFCが公開されることが明らかになると思われる場合、割り当てを承認することができます。指定された専門家は、インターネットドラフトを含むコメントとレビューのために、EAP WGメーリングリスト（またはエリアディレクターによって指定された後継者）にリクエストを投稿します。30日間が経過する前に、指定された専門家は登録要求を承認または拒否し、EAP WGメーリングリストまたはその後継者に決定の通知を公開し、IANAに通知します。拒否通知は説明によって正当化されなければならず、それが可能な場合は、受け入れられるようにリクエストをどのように変更できるかについての具体的な提案を提供する必要があります。
Packet Codes have a range from 1 to 255, of which 1-4 have been allocated. Because a new Packet Code has considerable impact on interoperability, a new Packet Code requires Standards Action, and should be allocated starting at 5.
パケットコードの範囲は1〜255で、そのうち1〜4が割り当てられています。新しいパケットコードは相互運用性に大きな影響を与えるため、新しいパケットコードには標準アクションが必要であり、5から割り当てる必要があります。
The original EAP method Type space has a range from 1 to 255, and is the scarcest resource in EAP, and thus must be allocated with care. Method Types 1-45 have been allocated, with 20 available for re-use. Method Types 20 and 46-191 may be allocated on the advice of a Designated Expert, with Specification Required.
元のEAPメソッドタイプスペースは1〜255の範囲であり、EAPで最も希少なリソースであるため、注意して割り当てる必要があります。メソッドタイプ1-45が割り当てられており、20は再利用可能です。メソッドタイプ20および46-191は、指定された専門家のアドバイスで割り当てられ、仕様が必要です。
Allocation of blocks of method Types (more than one for a given purpose) should require IETF Consensus. EAP Type Values 192-253 are reserved and allocation requires Standards Action.
メソッドタイプのブロックの割り当て（特定の目的のために複数）が必要なはずです。IETFコンセンサスが必要です。EAPタイプの値192-253は予約されており、割り当てには標準アクションが必要です。
Method Type 254 is allocated for the Expanded Type. Where the Vendor-Id field is non-zero, the Expanded Type is used for functions specific only to one vendor's implementation of EAP, where no interoperability is deemed useful. When used with a Vendor-Id of zero, method Type 254 can also be used to provide for an expanded IETF method Type space. Method Type values 256-4294967295 may be allocated after Type values 1-191 have been allocated, on the advice of a Designated Expert, with Specification Required.
メソッドタイプ254は、拡張型に割り当てられます。ベンダーIDフィールドがゼロではない場合、拡張されたタイプは、1つのベンダーのEAPの実装に固有の関数に使用されます。ゼロのベンダーIDで使用する場合、メソッドタイプ254を使用して、拡張されたIETFメソッドタイプスペースを提供することもできます。メソッドタイプの値256-4294967295は、指定された専門家のアドバイスで、タイプ値1-191が割り当てられた後に割り当てられる場合があります。
Method Type 255 is allocated for Experimental use, such as testing of new EAP methods before a permanent Type is allocated.
メソッドタイプ255は、永久型が割り当てられる前に新しいEAPメソッドのテストなど、実験的に使用するために割り当てられます。
This section defines a generic threat model as well as the EAP method security claims mitigating those threats.
このセクションでは、一般的な脅威モデルと、EAPメソッドセキュリティがこれらの脅威を軽減する主張を定義しています。
It is expected that the generic threat model and corresponding security claims will used to define EAP method requirements for use in specific environments. An example of such a requirements analysis is provided in [IEEE-802.11i-req]. A security claims section is required in EAP method specifications, so that EAP methods can be evaluated against the requirements.
一般的な脅威モデルと対応するセキュリティクレームは、特定の環境での使用のためのEAPメソッド要件を定義するために使用されることが期待されています。このような要件分析の例は、[IEEE-802.11-Req]で提供されています。EAPメソッドの仕様では、セキュリティクレームセクションが必要であるため、EAPメソッドは要件に対して評価できます。
EAP was developed for use with PPP [RFC1661] and was later adapted for use in wired IEEE 802 networks [IEEE-802] in [IEEE-802.1X]. Subsequently, EAP has been proposed for use on wireless LAN networks and over the Internet. In all these situations, it is possible for an attacker to gain access to links over which EAP packets are transmitted. For example, attacks on telephone infrastructure are documented in [DECEPTION].
EAPは、PPP [RFC1661]で使用するために開発され、後に[IEEE-802.1x]の有線IEEE 802ネットワーク[IEEE-802]で使用するために適合しました。その後、EAPがワイヤレスLANネットワークおよびインターネット経由で使用することが提案されています。これらすべての状況で、攻撃者はEAPパケットが送信されるリンクにアクセスできるようになります。たとえば、電話インフラストラクチャへの攻撃は[欺ception]に文書化されています。
An attacker with access to the link may carry out a number of attacks, including:
リンクにアクセスできる攻撃者は、以下を含む多くの攻撃を実行する場合があります。
[1] An attacker may try to discover user identities by snooping authentication traffic.
[1] 攻撃者は、認証トラフィックをスヌーピングすることにより、ユーザーのアイデンティティを発見しようとする場合があります。
[2] An attacker may try to modify or spoof EAP packets.
[2] 攻撃者は、EAPパケットを変更またはスプーフィングしようとする場合があります。
[3] An attacker may launch denial of service attacks by spoofing lower layer indications or Success/Failure packets, by replaying EAP packets, or by generating packets with overlapping Identifiers.
[3] 攻撃者は、下層の適応症または成功/失敗パケットをスプーフィングすること、EAPパケットのリプレイ、または重複する識別子を持つパケットを生成することにより、サービス拒否攻撃を開始する場合があります。
[4] An attacker may attempt to recover the pass-phrase by mounting an offline dictionary attack.
[4] 攻撃者は、オフラインの辞書攻撃を取り付けることにより、パスフレーズを回復しようとする場合があります。
[5] An attacker may attempt to convince the peer to connect to an untrusted network by mounting a man-in-the-middle attack.
[5] 攻撃者は、中間の攻撃を取り付けることにより、ピアに信頼されていないネットワークに接続するよう説得しようとするかもしれません。
[6] An attacker may attempt to disrupt the EAP negotiation in order cause a weak authentication method to be selected.
[6] 攻撃者は、弱い認証方法を選択するためにEAP交渉を混乱させようとする場合があります。
[7] An attacker may attempt to recover keys by taking advantage of weak key derivation techniques used within EAP methods.
[7] 攻撃者は、EAPメソッド内で使用される弱いキー派生技術を利用することにより、キーを回復しようとする場合があります。
[8] An attacker may attempt to take advantage of weak ciphersuites subsequently used after the EAP conversation is complete.
[8] 攻撃者は、EAPの会話が完了した後、その後使用される弱いcifhersuitesを利用しようとする場合があります。
[9] An attacker may attempt to perform downgrading attacks on lower layer ciphersuite negotiation in order to ensure that a weaker ciphersuite is used subsequently to EAP authentication.
[9] 攻撃者は、より弱い暗号化されていることを保証するために、下層の暗号外観の交渉で格下げ攻撃を実行しようとする場合があります。その後、EAP認証に使用されます。
[10] An attacker acting as an authenticator may provide incorrect information to the EAP peer and/or server via out-of-band mechanisms (such as via a AAA or lower layer protocol). This includes impersonating another authenticator, or providing inconsistent information to the peer and EAP server.
[10] 認証者として行動する攻撃者は、帯域外のメカニズム（AAAまたは下層プロトコルなど）を介してEAPピアやサーバーに誤った情報を提供する場合があります。これには、別の認証因子になりすましたり、ピアサーバーとEAPサーバーに一貫性のない情報を提供したりすることが含まれます。
Depending on the lower layer, these attacks may be carried out without requiring physical proximity. Where EAP is used over wireless networks, EAP packets may be forwarded by authenticators (e.g., pre-authentication) so that the attacker need not be within the coverage area of an authenticator in order to carry out an attack on it or its peers. Where EAP is used over the Internet, attacks may be carried out at an even greater distance.
下層に応じて、これらの攻撃は、物理的な近接性を必要とせずに実行できます。EAPがワイヤレスネットワークで使用されている場合、EAPパケットは認証機（例えば、事前認証）によって転送される可能性があるため、攻撃者は攻撃またはそのピアを実行するために認証者のカバレッジエリア内にいる必要がありません。EAPがインターネットを介して使用される場合、攻撃はさらに遠くで実行される場合があります。
In order to clearly articulate the security provided by an EAP method, EAP method specifications MUST include a Security Claims section, including the following declarations:
EAPメソッドによって提供されるセキュリティを明確に明確にするために、EAPメソッド仕様には、次の宣言を含むセキュリティクレームセクションを含める必要があります。
[a] Mechanism. This is a statement of the authentication technology: certificates, pre-shared keys, passwords, token cards, etc.
[a] 機構。これは、認証技術のステートメントです。証明書、事前共有キー、パスワード、トークンカードなどです。
[b] Security claims. This is a statement of the claimed security properties of the method, using terms defined in Section 7.2.1: mutual authentication, integrity protection, replay protection, confidentiality, key derivation, dictionary attack resistance, fast reconnect, cryptographic binding. The Security Claims section of an EAP method specification SHOULD provide justification for the claims that are made. This can be accomplished by including a proof in an Appendix, or including a reference to a proof.
[b] セキュリティクレーム。これは、セクション7.2.1で定義されている項を使用して、メソッドのセキュリティプロパティの主張された声明であり、相互認証、整合性保護、リプレイ保護、機密性、キー派生、辞書攻撃抵抗、高速再接続、暗号化結合。EAPメソッド仕様のセキュリティクレームセクションは、行われた請求の正当化を提供する必要があります。これは、付録に証明を含めること、または証明への参照を含めることで実現できます。
[c] Key strength. If the method derives keys, then the effective key strength MUST be estimated. This estimate is meant for potential users of the method to determine if the keys produced are strong enough for the intended application.
[c] 重要な強さ。メソッドがキーを導出する場合、効果的なキー強度を推定する必要があります。この推定値は、生成されたキーが意図したアプリケーションに十分強いかどうかを判断するための方法の潜在的なユーザー向けです。
The effective key strength SHOULD be stated as a number of bits, defined as follows: If the effective key strength is N bits, the best currently known methods to recover the key (with non-negligible probability) require, on average, an effort comparable to 2^(N-1) operations of a typical block cipher. The statement SHOULD be accompanied by a short rationale, explaining how this number was derived. This explanation SHOULD include the parameters required to achieve the stated key strength based on current knowledge of the algorithms.
効果的なキー強度は、次のように定義される多数のビットとして記載する必要があります。有効なキー強度がNビットである場合、キーを回復するための現在の最良の方法（無交換可能な確率で）は、平均して、同等の努力が同等の努力を必要とします。典型的なブロック暗号の2^（n-1）操作へ。声明には、この数字がどのように導き出されたかを説明する短い理論的根拠を伴う必要があります。この説明には、アルゴリズムの現在の知識に基づいて、指定された重要な強度を達成するために必要なパラメーターを含める必要があります。
(Note: Although it is difficult to define what "comparable effort" and "typical block cipher" exactly mean, reasonable approximations are sufficient here. Refer to e.g. [SILVERMAN] for more discussion.)
（注：「比較可能な努力」と「典型的なブロック暗号」を正確に定義することは困難ですが、ここでは合理的な近似で十分です。
The key strength depends on the methods used to derive the keys. For instance, if keys are derived from a shared secret (such as a password or a long-term secret), and possibly some public information such as nonces, the effective key strength is limited by the strength of the long-term secret (assuming that the derivation procedure is computationally simple). To take another example, when using public key algorithms, the strength of the symmetric key depends on the strength of the public keys used.
キー強度は、キーを導出するために使用される方法に依存します。たとえば、キーが共有された秘密（パスワードや長期秘密など）から派生している場合、およびおそらく非sなどの公開情報から派生した場合、効果的なキー強度は長期的な秘密の強さによって制限されます（仮定してください。派生手順が計算的に単純であること。別の例を挙げると、公開キーアルゴリズムを使用する場合、対称キーの強度は、使用されるパブリックキーの強度に依存します。
[d] Description of key hierarchy. EAP methods deriving keys MUST either provide a reference to a key hierarchy specification, or describe how Master Session Keys (MSKs) and Extended Master Session Keys (EMSKs) are to be derived.
[d] 重要な階層の説明。キーを導き出すEAPメソッドは、キー階層仕様への参照を提供するか、マスターセッションキー（MSK）と拡張マスターセッションキー（EMSK）をどのように導き出すかを説明する必要があります。
[e] Indication of vulnerabilities. In addition to the security claims that are made, the specification MUST indicate which of the security claims detailed in Section 7.2.1 are NOT being made.
[e] 脆弱性の兆候。行われたセキュリティクレームに加えて、仕様は、セクション7.2.1で詳述されているセキュリティクレームのどれが行われていないかを示す必要があります。
These terms are used to describe the security properties of EAP methods:
これらの用語は、EAPメソッドのセキュリティプロパティを説明するために使用されます。
Protected ciphersuite negotiation This refers to the ability of an EAP method to negotiate the ciphersuite used to protect the EAP conversation, as well as to integrity protect the negotiation. It does not refer to the ability to negotiate the ciphersuite used to protect data.
保護された暗号化された交渉これは、EAPの会話を保護するために使用されるciphersuiteを交渉するEAPメソッドの能力と、交渉を保護する能力を指します。それは、データの保護に使用されるCiphersuiteを交渉する能力を指すものではありません。
Mutual authentication This refers to an EAP method in which, within an interlocked exchange, the authenticator authenticates the peer and the peer authenticates the authenticator. Two independent one-way methods, running in opposite directions do not provide mutual authentication as defined here.
相互認証これは、インターロックされた交換内で、認証者がピアを認証し、ピアが認証機を認証するEAPメソッドを指します。反対方向に実行される2つの独立した一方向の方法は、ここで定義されているように相互認証を提供しません。
Integrity protection This refers to providing data origin authentication and protection against unauthorized modification of information for EAP packets (including EAP Requests and Responses). When making this claim, a method specification MUST describe the EAP packets and fields within the EAP packet that are protected.
整合性保護これは、EAPパケット（EAPリクエストと応答を含む）の情報の不正な変更に対するデータ起源の認証と保護を提供することを指します。この主張をするとき、メソッド仕様は、保護されているEAPパケット内のEAPパケットとフィールドを記述する必要があります。
Replay protection This refers to protection against replay of an EAP method or its messages, including success and failure result indications.
リプレイ保護これは、成功と失敗の結果の表示を含む、EAPメソッドまたはそのメッセージのリプレイに対する保護を指します。
Confidentiality This refers to encryption of EAP messages, including EAP Requests and Responses, and success and failure result indications. A method making this claim MUST support identity protection (see Section 7.3).
機密性これは、EAPリクエストと応答、成功と失敗の結果の表示を含むEAPメッセージの暗号化を指します。この主張を作成する方法は、アイデンティティ保護をサポートする必要があります（セクション7.3を参照）。
Key derivation This refers to the ability of the EAP method to derive exportable keying material, such as the Master Session Key (MSK), and Extended Master Session Key (EMSK). The MSK is used only for further key derivation, not directly for protection of the EAP conversation or subsequent data. Use of the EMSK is reserved.
キー導入これは、マスターセッションキー（MSK）や拡張マスターセッションキー（EMSK）などのエクスポート可能なキーイング素材を導出するEAPメソッドの能力を指します。MSKは、EAPの会話や後続のデータの保護には直接ではなく、さらに重要な派生にのみ使用されます。EMSKの使用は予約されています。
Key strength If the effective key strength is N bits, the best currently known methods to recover the key (with non-negligible probability) require, on average, an effort comparable to 2^(N-1) operations of a typical block cipher.
キー強度効果的なキー強度がNビットである場合、キーを回復するための現在の最も既知の方法（無逆確率で）は、平均して、典型的なブロック暗号の2^（n-1）操作に匹敵する努力が必要です。
Dictionary attack resistance Where password authentication is used, passwords are commonly selected from a small set (as compared to a set of N-bit keys), which raises a concern about dictionary attacks. A method may be said to provide protection against dictionary attacks if, when it uses a password as a secret, the method does not allow an offline attack that has a work factor based on the number of passwords in an attacker's dictionary.
辞書攻撃抵抗パスワード認証が使用される場合、パスワードは一般的に小さなセット（一連のnビットキーと比較して）から選択され、辞書攻撃に関する懸念を引き起こします。方法は、パスワードを秘密として使用する場合、攻撃者の辞書のパスワード数に基づいて作業要因を持つオフライン攻撃を許可しない場合、辞書攻撃に対する保護を提供すると言えるかもしれません。
Fast reconnect The ability, in the case where a security association has been previously established, to create a new or refreshed security association more efficiently or in a smaller number of round-trips.
セキュリティ協会が以前に確立されていた場合に、能力を高速に再接続し、新しいまたは更新されたセキュリティ協会をより効率的に、または少数のラウンドトリップで作成します。
Cryptographic binding The demonstration of the EAP peer to the EAP server that a single entity has acted as the EAP peer for all methods executed within a tunnel method. Binding MAY also imply that the EAP server demonstrates to the peer that a single entity has acted as the EAP server for all methods executed within a tunnel method. If executed correctly, binding serves to mitigate man-in-the-middle vulnerabilities.
暗号化バインドEAPピアのデモをEAPサーバーに、単一のエンティティがトンネルメソッド内で実行されるすべての方法に対してEAPピアとして機能したことを示しています。バインディングは、EAPサーバーが、単一のエンティティがトンネルメソッド内で実行されるすべてのメソッドのEAPサーバーとして機能したことをピアに示すことを意味する場合があります。正しく実行された場合、バインディングは中間の脆弱性を緩和するのに役立ちます。
Session independence The demonstration that passive attacks (such as capture of the EAP conversation) or active attacks (including compromise of the MSK or EMSK) does not enable compromise of subsequent or prior MSKs or EMSKs.
セッションの独立受動攻撃（EAP会話のキャプチャなど）またはアクティブな攻撃（MSKまたはEMSKの妥協を含む）が、その後のMSKまたは以前のMSKまたはEMSKの妥協を可能にしないというデモンストレーション。
Fragmentation This refers to whether an EAP method supports fragmentation and reassembly. As noted in Section 3.1, EAP methods should support fragmentation and reassembly if EAP packets can exceed the minimum MTU of 1020 octets.
断片化これは、EAPメソッドが断片化と再組み立てをサポートするかどうかを指します。セクション3.1で述べたように、EAPパケットが1020オクテットの最小MTUを超える場合、EAPメソッドは断片化と再組み立てをサポートする必要があります。
Channel binding The communication within an EAP method of integrity-protected channel properties such as endpoint identifiers which can be compared to values communicated via out of band mechanisms (such as via a AAA or lower layer protocol).
チャネルバインドバインドバンド外のメカニズム（AAAまたは下層プロトコルなど）を介して伝達される値と比較できるエンドポイント識別子などの整合性保護されたチャネルプロパティのEAPメソッド内の通信。
Note: This list of security claims is not exhaustive. Additional properties, such as additional denial-of-service protection, may be relevant as well.
注：このセキュリティ請求のリストは網羅的ではありません。追加のサービス拒否保護などの追加のプロパティも同様に関連する場合があります。
An Identity exchange is optional within the EAP conversation. Therefore, it is possible to omit the Identity exchange entirely, or to use a method-specific identity exchange once a protected channel has been established.
EAP会話内では、ID交換がオプションです。したがって、保護されたチャネルが確立されたら、アイデンティティ交換を完全に省略したり、メソッド固有のアイデンティティ交換を使用することができます。
However, where roaming is supported as described in [RFC2607], it may be necessary to locate the appropriate backend authentication server before the authentication conversation can proceed. The realm portion of the Network Access Identifier (NAI) [RFC2486] is typically included within the EAP-Response/Identity in order to enable the authentication exchange to be routed to the appropriate backend authentication server. Therefore, while the peer-name portion of the NAI may be omitted in the EAP-Response/Identity where proxies or relays are present, the realm portion may be required.
ただし、[RFC2607]で説明されているようにローミングがサポートされている場合、認証会話が進む前に適切なバックエンド認証サーバーを見つける必要がある場合があります。ネットワークアクセス識別子（NAI）[RFC2486]のレルム部分は、通常、認証交換を適切なバックエンド認証サーバーにルーティングできるようにするために、EAP応答/IDに含まれています。したがって、NAIのピアネーム部分は、プロキシまたはリレーが存在するEAP応答/アイデンティティでは省略できますが、レルム部分が必要になる場合があります。
It is possible for the identity in the identity response to be different from the identity authenticated by the EAP method. This may be intentional in the case of identity privacy. An EAP method SHOULD use the authenticated identity when making access control decisions.
アイデンティティ応答のアイデンティティが、EAPメソッドによって認証されたアイデンティティとは異なる可能性があります。これは、IDプライバシーの場合に意図的な場合があります。EAPメソッドは、アクセス制御の決定を行うときに認証されたIDを使用する必要があります。
Where EAP is tunneled within another protocol that omits peer authentication, there exists a potential vulnerability to a man-in-the-middle attack. For details, see [BINDING] and [MITM].
EAPがピア認証を省略する別のプロトコル内でトンネル化されている場合、中間の攻撃に対する潜在的な脆弱性が存在します。詳細については、[バインディング]と[MITM]を参照してください。
As noted in Section 2.1, EAP does not permit untunneled sequences of authentication methods. Were a sequence of EAP authentication methods to be permitted, the peer might not have proof that a single entity has acted as the authenticator for all EAP methods within the sequence. For example, an authenticator might terminate one EAP method, then forward the next method in the sequence to another party without the peer's knowledge or consent. Similarly, the authenticator might not have proof that a single entity has acted as the peer for all EAP methods within the sequence.
セクション2.1で述べたように、EAPでは、認証方法の最初のシーケンスが許可されていません。許可されるEAP認証方法のシーケンスである場合、ピアは、単一のエンティティがシーケンス内のすべてのEAPメソッドの認証機として機能したことを証明していない場合があります。たとえば、認証者は1つのEAPメソッドを終了し、ピアの知識や同意なしに別の当事者にシーケンスの次のメソッドを転送する場合があります。同様に、認証機には、シーケンス内のすべてのEAPメソッドのピアとして単一のエンティティがPEERとして機能したことの証拠がない場合があります。
Tunneling EAP within another protocol enables an attack by a rogue EAP authenticator tunneling EAP to a legitimate server. Where the tunneling protocol is used for key establishment but does not require peer authentication, an attacker convincing a legitimate peer to connect to it will be able to tunnel EAP packets to a legitimate server, successfully authenticating and obtaining the key. This allows the attacker to successfully establish itself as a man-in-the-middle, gaining access to the network, as well as the ability to decrypt data traffic between the legitimate peer and server.
別のプロトコル内のトンネルEAPにより、Rogue EAP AuthenticatorがEAPを正当なサーバーにトンネリングすることによる攻撃を可能にします。トンネリングプロトコルがキー施設に使用されているがピア認証を必要としない場合、正当なピアに接続するよう説得する攻撃者は、EAPパケットを正当なサーバーにトンネルし、キーを認証して取得することができます。これにより、攻撃者は中間の男としての地位を確立し、ネットワークへのアクセスを獲得し、合法的なピアとサーバー間のデータトラフィックを解読する能力を獲得することができます。
This attack may be mitigated by the following measures:
この攻撃は、次の測定によって軽減される場合があります。
[a] Requiring mutual authentication within EAP tunneling mechanisms.
[a] EAPトンネリングメカニズム内で相互認証が必要です。
[b] Requiring cryptographic binding between the EAP tunneling protocol and the tunneled EAP methods. Where cryptographic binding is supported, a mechanism is also needed to protect against downgrade attacks that would bypass it. For further details on cryptographic binding, see [BINDING].
[b] EAPトンネルプロトコルとトンネリングEAPメソッドの間に暗号化結合が必要です。暗号化の結合がサポートされている場合、それをバイパスするダウングレード攻撃から保護するためにメカニズムも必要です。暗号化結合の詳細については、[バインディング]を参照してください。
[c] Limiting the EAP methods authorized for use without protection, based on peer and authenticator policy.
[c] ピアおよび認証装置のポリシーに基づいて、保護なしで使用することが許可されたEAPメソッドを制限します。
[d] Avoiding the use of tunnels when a single, strong method is available.
[d] 単一の強力な方法が利用可能な場合、トンネルの使用を回避します。
While EAP methods may support per-packet data origin authentication, integrity, and replay protection, support is not provided within the EAP layer.
EAPメソッドは、パケットごとのデータ起源認証、整合性、およびリプレイ保護をサポートする場合がありますが、サポートはEAPレイヤー内で提供されません。
Since the Identifier is only a single octet, it is easy to guess, allowing an attacker to successfully inject or replay EAP packets. An attacker may also modify EAP headers (Code, Identifier, Length, Type) within EAP packets where the header is unprotected. This could cause packets to be inappropriately discarded or misinterpreted.
識別子は単一のオクテットのみであるため、攻撃者がEAPパケットを正常に挿入またはリプレイすることができます。攻撃者は、ヘッダーが保護されていないEAPパケット内のEAPヘッダー（コード、識別子、長さ、タイプ）を変更することもできます。これにより、パケットが不適切に破棄または誤って解釈される可能性があります。
To protect EAP packets against modification, spoofing, or replay, methods supporting protected ciphersuite negotiation, mutual authentication, and key derivation, as well as integrity and replay protection, are recommended. See Section 7.2.1 for definitions of these security claims.
EAPパケットを修正、スプーフィング、またはリプレイから保護するために、保護された暗号化された交渉、相互認証、キー派生、および整合性とリプレイ保護をサポートする方法が推奨されます。これらのセキュリティクレームの定義については、セクション7.2.1を参照してください。
Method-specific MICs may be used to provide protection. If a per-packet MIC is employed within an EAP method, then peers, authentication servers, and authenticators not operating in pass-through mode MUST validate the MIC. MIC validation failures SHOULD be logged. Whether a MIC validation failure is considered a fatal error or not is determined by the EAP method specification.
メソッド固有のMICは、保護を提供するために使用できます。パケットごとのマイクがEAPメソッド内で採用されている場合、パススルーモードで動作しないピア、認証サーバー、および認証器がマイクを検証する必要があります。マイク検証の障害を記録する必要があります。MIC検証障害が致命的なエラーと見なされるかどうかは、EAPメソッドの仕様によって決定されます。
It is RECOMMENDED that methods providing integrity protection of EAP packets include coverage of all the EAP header fields, including the Code, Identifier, Length, Type, and Type-Data fields.
EAPパケットの整合性保護を提供する方法には、コード、識別子、長さ、タイプ、タイプデータフィールドなど、すべてのEAPヘッダーフィールドのカバレッジを含めることをお勧めします。
Since EAP messages of Types Identity, Notification, and Nak do not include their own MIC, it may be desirable for the EAP method MIC to cover information contained within these messages, as well as the header of each EAP message.
タイプのID、通知、およびNAKのEAPメッセージには独自のマイクが含まれていないため、EAPメソッドMICがこれらのメッセージに含まれる情報と各EAPメッセージのヘッダーをカバーすることが望ましい場合があります。
To provide protection, EAP also may be encapsulated within a protected channel created by protocols such as ISAKMP [RFC2408], as is done in [IKEv2] or within TLS [RFC2246]. However, as noted in Section 7.4, EAP tunneling may result in a man-in-the-middle vulnerability.
保護を提供するために、EAPは、[IKEV2]またはTLS [RFC2246]で行われるように、ISAKMP [RFC2408]などのプロトコルによって作成された保護チャネル内でカプセル化される場合があります。ただし、セクション7.4で述べたように、EAPトンネルは中間の脆弱性をもたらす可能性があります。
Existing EAP methods define message integrity checks (MICs) that cover more than one EAP packet. For example, EAP-TLS [RFC2716] defines a MIC over a TLS record that could be split into multiple fragments; within the FINISHED message, the MIC is computed over previous messages. Where the MIC covers more than one EAP packet, a MIC validation failure is typically considered a fatal error.
既存のEAPメソッドは、複数のEAPパケットをカバーするメッセージの整合性チェック（MICS）を定義します。たとえば、EAP-TLS [RFC2716]は、複数のフラグメントに分割できるTLSレコード上のMICを定義します。完成したメッセージ内で、MICは以前のメッセージで計算されます。マイクが複数のEAPパケットをカバーする場合、マイク検証障害は通常、致命的なエラーと見なされます。
Within EAP-TLS [RFC2716], a MIC validation failure is treated as a fatal error, since that is what is specified in TLS [RFC2246]. However, it is also possible to develop EAP methods that support per-packet MICs, and respond to verification failures by silently discarding the offending packet.
EAP-TLS [RFC2716]内では、MIC検証障害が致命的なエラーとして扱われます。これは、TLS [RFC2246]で指定されているためです。ただし、パケットごとのマイクをサポートするEAPメソッドを開発し、違反パケットを静かに破棄することにより、検証障害に応答することもできます。
In this document, descriptions of EAP message handling assume that per-packet MIC validation, where it occurs, is effectively performed as though it occurs before sending any responses or changing the state of the host which received the packet.
このドキュメントでは、EAPメッセージの処理の説明は、パケットごとのマイク検証が発生すると、回答を送信する前にパケットを受け取ったホストの状態を変更する前に発生するかのように効果的に実行されると仮定しています。
Password authentication algorithms such as EAP-MD5, MS-CHAPv1 [RFC2433], and Kerberos V [RFC1510] are known to be vulnerable to dictionary attacks. MS-CHAPv1 vulnerabilities are documented in [PPTPv1]; MS-CHAPv2 vulnerabilities are documented in [PPTPv2]; Kerberos vulnerabilities are described in [KRBATTACK], [KRBLIM], and [KERB4WEAK].
EAP-MD5、MS-CHAPV1 [RFC2433]、Kerberos V [RFC1510]などのパスワード認証アルゴリズムは、辞書攻撃に対して脆弱であることが知られています。MS-CHAPV1の脆弱性は[PPTPV1]に文書化されています。MS-Chapv2の脆弱性は[PPTPV2]に記録されています。Kerberosの脆弱性は、[Krbattack]、[Krblim]、および[kerb4weak]で説明されています。
In order to protect against dictionary attacks, authentication methods resistant to dictionary attacks (as defined in Section 7.2.1) are recommended.
辞書攻撃から保護するために、辞書攻撃に耐性のある認証方法（セクション7.2.1で定義）が推奨されます。
If an authentication algorithm is used that is known to be vulnerable to dictionary attacks, then the conversation may be tunneled within a protected channel in order to provide additional protection. However, as noted in Section 7.4, EAP tunneling may result in a man-in-the-middle vulnerability, and therefore dictionary attack resistant methods are preferred.
辞書攻撃に対して脆弱であることが知られている認証アルゴリズムが使用されている場合、追加の保護を提供するために、会話は保護されたチャネル内でトンネル化される場合があります。ただし、セクション7.4で述べたように、EAPトンネリングは中間の脆弱性をもたらす可能性があるため、辞書攻撃耐性方法が好まれます。
With EAP methods supporting one-way authentication, such as EAP-MD5, the peer does not authenticate the authenticator, making the peer vulnerable to attack by a rogue authenticator. Methods supporting mutual authentication (as defined in Section 7.2.1) address this vulnerability.
EAP-MD5などの一元配置認証をサポートするEAPメソッドにより、ピアは認証機を認証せず、ピアは不正な認証者による攻撃に対して脆弱になります。相互認証をサポートする方法（セクション7.2.1で定義されている）は、この脆弱性に対処します。
In EAP there is no requirement that authentication be full duplex or that the same protocol be used in both directions. It is perfectly acceptable for different protocols to be used in each direction. This will, of course, depend on the specific protocols negotiated. However, in general, completing a single unitary mutual authentication is preferable to two one-way authentications, one in each direction. This is because separate authentications that are not bound cryptographically so as to demonstrate they are part of the same session are subject to man-in-the-middle attacks, as discussed in Section 7.4.
EAPでは、認証が完全な二重であるか、同じプロトコルを両方向に使用するという要件はありません。さまざまなプロトコルを各方向に使用することは完全に受け入れられます。もちろん、これは交渉された特定のプロトコルに依存します。ただし、一般に、単一の単一の相互認証を完了することは、各方向に1つの1つの片道認証よりも望ましいです。これは、セクション7.4で説明したように、同じセッションの一部であることを示すために、暗号化されていない個別の認証が同じセッションの一部であることを示すためです。
In a negotiation attack, the attacker attempts to convince the peer and authenticator to negotiate a less secure EAP method. EAP does not provide protection for Nak Response packets, although it is possible for a method to include coverage of Nak Responses within a method-specific MIC.
交渉攻撃では、攻撃者はピアと認証者に、より安全でないEAPメソッドを交渉するよう説得しようとします。EAPは、NAK応答パケットの保護を提供しませんが、メソッド固有のマイク内にNAK応答のカバレッジを含めることができます。
Within or associated with each authenticator, it is not anticipated that a particular named peer will support a choice of methods. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set. Instead, for each named peer, there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method.
各認証装置内または関連する場合、特定の名前のピアがメソッドの選択をサポートすることは予想されません。これにより、セットの中から最も安全な方法を交渉する攻撃に対して、ピアが脆弱になります。代わりに、指定された各ピアについて、そのピア名を認証するために使用される正確な1つの方法の兆候があるはずです。ピアが異なる状況下で異なる認証方法を使用する必要がある場合、それぞれが正確に1つの認証方法を識別する明確なアイデンティティを採用する必要があります。
The interaction of EAP with lower layers such as PPP and IEEE 802 are highly implementation dependent.
EAPとPPPやIEEE 802などの下層層との相互作用は、実装に依存しています。
For example, upon failure of authentication, some PPP implementations do not terminate the link, instead limiting traffic in Network-Layer Protocols to a filtered subset, which in turn allows the peer the opportunity to update secrets or send mail to the network administrator indicating a problem. Similarly, while an authentication failure will result in denied access to the controlled port in [IEEE-802.1X], limited traffic may be permitted on the uncontrolled port.
たとえば、認証の障害時に、一部のPPP実装はリンクを終了せず、ネットワーク層プロトコルのトラフィックをフィルター付きサブセットに制限します。問題。同様に、認証障害により[IEEE-802.1x]の制御ポートへのアクセスが拒否されますが、制御されていないポートでのトラフィックが限られている場合があります。
In EAP there is no provision for retries of failed authentication. However, in PPP the LCP state machine can renegotiate the authentication protocol at any time, thus allowing a new attempt. Similarly, in IEEE 802.1X the Supplicant or Authenticator can re-authenticate at any time. It is recommended that any counters used for authentication failure not be reset until after successful authentication, or subsequent termination of the failed link.
EAPでは、認証に障害のある再取得に関する規定はありません。ただし、PPPでは、LCP状態マシンはいつでも認証プロトコルを再交渉でき、新しい試行が可能になります。同様に、IEEE 802.1xでは、サプリカントまたは認証装置はいつでも再認証できます。認証障害に使用されるカウンターは、認証が成功した後、またはその後の障害リンクの終了後にリセットされないことをお勧めします。
It is possible for the peer and EAP server to mutually authenticate and derive keys. In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. EAP Methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP Server.
ピアサーバーとEAPサーバーがキーを相互に認証および導き出すことが可能です。その後ネゴシエートされたCiphersuiteで使用するためのキーイング素材を提供するには、キーの導出をサポートするEAPメソッドは、少なくとも64オクテットのマスターセッションキー（MSK）をエクスポートし、少なくとも64オクテットの拡張マスターセッションキー（EMSK）をエクスポートする必要があります。キーを導き出すEAPメソッドは、EAPピアとEAPサーバーの間の相互認証を提供する必要があります。
The MSK and EMSK MUST NOT be used directly to protect data; however, they are of sufficient size to enable derivation of a AAA-Key subsequently used to derive Transient Session Keys (TSKs) for use with the selected ciphersuite. Each ciphersuite is responsible for specifying how to derive the TSKs from the AAA-Key.
MSKとEMSKは、データを保護するために直接使用してはなりません。ただし、それらは、選択したCiphersuiteで使用するための過渡的なセッションキー（TSK）を導出するために使用されるAAA-Keyの導出を可能にするのに十分なサイズです。各Ciphersuiteは、AAA-KeyからTSKを導出する方法を指定する責任があります。
The AAA-Key is derived from the keying material exported by the EAP method (MSK and EMSK). This derivation occurs on the AAA server. In many existing protocols that use EAP, the AAA-Key and MSK are equivalent, but more complicated mechanisms are possible (see [KEYFRAME] for details).
AAA-Keyは、EAPメソッド（MSKおよびEMSK）によってエクスポートされるキーイング材料から派生しています。この派生は、AAAサーバーで発生します。EAPを使用する多くの既存のプロトコルでは、AAA-KeyとMSKは同等ですが、より複雑なメカニズムが可能です（詳細については[KeyFrame]を参照）。
EAP methods SHOULD ensure the freshness of the MSK and EMSK, even in cases where one party may not have a high quality random number generator. A RECOMMENDED method is for each party to provide a nonce of at least 128 bits, used in the derivation of the MSK and EMSK.
EAPメソッドは、1つの当事者が高品質の乱数ジェネレーターを持っていない場合でも、MSKとEMSKの新鮮さを確保する必要があります。推奨される方法は、各当事者がMSKとEMSKの派生に使用される少なくとも128ビットの非CEを提供することです。
EAP methods export the MSK and EMSK, but not Transient Session Keys so as to allow EAP methods to be ciphersuite and media independent. Keying material exported by EAP methods MUST be independent of the ciphersuite negotiated to protect data.
EAPメソッドはMSKとEMSKをエクスポートしますが、EAPメソッドがCiphersuiteおよびメディアに依存しないように、一時的なセッションキーではありません。EAPメソッドによって輸出されたキーイング材料は、データを保護するために交渉されたCiphersuiteとは無関係でなければなりません。
Depending on the lower layer, EAP methods may run before or after ciphersuite negotiation, so that the selected ciphersuite may not be known to the EAP method. By providing keying material usable with any ciphersuite, EAP methods can used with a wide range of ciphersuites and media.
下層に応じて、EAPメソッドは、Ciphersuiteの交渉の前後に実行される可能性があるため、選択したCiphersuiteがEAPメソッドにわかっていない場合があります。任意のCiphersuiteで使用可能なキーイング材料を提供することにより、EAPメソッドは幅広い暗号筋およびメディアで使用できます。
In order to preserve algorithm independence, EAP methods deriving keys SHOULD support (and document) the protected negotiation of the ciphersuite used to protect the EAP conversation between the peer and server. This is distinct from the ciphersuite negotiated between the peer and authenticator, used to protect data.
アルゴリズムの独立性を保持するために、キーを導出するEAPメソッドは、ピアとサーバーのEAP会話を保護するために使用される暗号外観の保護された交渉をサポート（および文書化）する必要があります。これは、データを保護するために使用されるピアと認証者の間で交渉されたCiphersuiteとは異なります。
The strength of Transient Session Keys (TSKs) used to protect data is ultimately dependent on the strength of keys generated by the EAP method. If an EAP method cannot produce keying material of sufficient strength, then the TSKs may be subject to a brute force attack. In order to enable deployments requiring strong keys, EAP methods supporting key derivation SHOULD be capable of generating an MSK and EMSK, each with an effective key strength of at least 128 bits.
データの保護に使用される一時的なセッションキー（TSK）の強度は、最終的にEAPメソッドによって生成されるキーの強度に依存します。EAPメソッドが十分な強度のキーイング材料を生成できない場合、TSKはブルートフォース攻撃の影響を受ける可能性があります。強力なキーを必要とする展開を有効にするために、キー派生をサポートするEAPメソッドは、それぞれが少なくとも128ビットの効果的なキー強度を持つMSKとEMSKを生成できる必要があります。
Methods supporting key derivation MUST demonstrate cryptographic separation between the MSK and EMSK branches of the EAP key hierarchy. Without violating a fundamental cryptographic assumption (such as the non-invertibility of a one-way function), an attacker recovering the MSK or EMSK MUST NOT be able to recover the other quantity with a level of effort less than brute force.
キー導出をサポートする方法は、EAPキー階層のMSK分岐とEMSKブランチ間の暗号化分離を実証する必要があります。基本的な暗号化の仮定（一方向関数の非依存性など）に違反することなく、MSKまたはEMSKを回復する攻撃者は、ブルートフォースよりも少ないレベルの努力で他の量を回収できない必要があります。
Non-overlapping substrings of the MSK MUST be cryptographically separate from each other, as defined in Section 7.2.1. That is, knowledge of one substring MUST NOT help in recovering some other substring without breaking some hard cryptographic assumption. This is required because some existing ciphersuites form TSKs by simply splitting the AAA-Key to pieces of appropriate length. Likewise, non-overlapping substrings of the EMSK MUST be cryptographically separate from each other, and from substrings of the MSK.
セクション7.2.1で定義されているように、MSKの非重複サブストリングは互いに暗号化的に分離する必要があります。つまり、1つのサブストリングの知識は、いくつかのハードな暗号化の仮定を破らずに他のサブストリングを回復するのに役立ちないはずです。これは、既存の既存のシファースーツが適切な長さの断片に単に分割するだけでTSKを形成するため、必要です。同様に、EMSKの重複しないサブストリングは、互いに、およびMSKのサブストリングから暗号化的に分離する必要があります。
The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys. (This restriction will be relaxed in a future document that specifies how the EMSK can be used.)
EMSKは将来の使用のために予約されており、派生したEAPピアおよびEAPサーバーに留まる必要があります。追加のパーティーに運ばれたり、共有したりしたり、他のキーを導き出すために使用してはなりません。（この制限は、EMSKの使用方法を指定する将来の文書で緩和されます。）
Since EAP does not provide for explicit key lifetime negotiation, EAP peers, authenticators, and authentication servers MUST be prepared for situations in which one of the parties discards the key state, which remains valid on another party.
EAPは明示的な主要なライフタイム交渉を提供していないため、EAPピア、認証者、および認証サーバーは、当事者の1つが他の当事者で有効な主要状態を廃止する状況に備えなければなりません。
This specification does not provide detailed guidance on how EAP methods derive the MSK and EMSK, how the AAA-Key is derived from the MSK and/or EMSK, or how the TSKs are derived from the AAA-Key.
この仕様では、EAPメソッドがMSKとEMSKをどのように導出するか、AAA-KeyがMSKおよび/またはEMSKからどのように導出されるか、またはTSKがAAA-Keyから導出される方法に関する詳細なガイダンスを提供しません。
The development and validation of key derivation algorithms is difficult, and as a result, EAP methods SHOULD re-use well established and analyzed mechanisms for key derivation (such as those specified in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. EAP methods SHOULD also utilize well established and analyzed mechanisms for MSK and EMSK derivation. Further details on EAP Key Derivation are provided within [KEYFRAME].
キー派生アルゴリズムの開発と検証は困難であり、その結果、EAPメソッドは、発明するのではなく、重要な派生のメカニズムを再利用し、キー派生のメカニズムを再利用し、分析したメカニズム（IKE [RFC2409]またはTLS [RFC2246]で指定されているものなど）が再利用される必要があります。新しいもの。EAPメソッドは、MSKおよびEMSK派生のための十分に確立および分析されたメカニズムを利用する必要があります。EAPキーの導出の詳細は、[keyframe]内で提供されています。
If after the initial EAP authentication, data packets are sent without per-packet authentication, integrity, and replay protection, an attacker with access to the media can inject packets, "flip bits" within existing packets, replay packets, or even hijack the session completely. Without per-packet confidentiality, it is possible to snoop data packets.
最初のEAP認証の後、データパケットがパケットごとの認証、整合性、およびリプレイ保護なしで送信された場合、メディアにアクセスできる攻撃者は、既存のパケット内の「フリップビット」を挿入したり、パケットをリプレイしたり、セッションをハイジャックしたりできます。完全に。パケットごとの機密性がなければ、データパケットをスヌープすることができます。
To protect against data modification, spoofing, or snooping, it is recommended that EAP methods supporting mutual authentication and key derivation (as defined by Section 7.2.1) be used, along with lower layers providing per-packet confidentiality, authentication, integrity, and replay protection.
データの変更、スプーフィング、またはスヌーピングから保護するには、相互認証とキー派生をサポートするEAPメソッド（セクション7.2.1で定義）を使用することをお勧めします。リプレイ保護。
Additionally, if the lower layer performs ciphersuite negotiation, it should be understood that EAP does not provide by itself integrity protection of that negotiation. Therefore, in order to avoid downgrading attacks which would lead to weaker ciphersuites being used, clients implementing lower layer ciphersuite negotiation SHOULD protect against negotiation downgrading.
さらに、下層が暗号化された交渉を実行する場合、EAPはその交渉の整合性保護を自然に提供しないことを理解する必要があります。したがって、使用されるより弱い暗号網につながる攻撃の格下げを回避するために、下層の暗号外観の交渉を実装するクライアントは、交渉の格下げから保護する必要があります。
This can be done by enabling users to configure which ciphersuites are acceptable as a matter of security policy, or the ciphersuite negotiation MAY be authenticated using keying material derived from the EAP authentication and a MIC algorithm agreed upon in advance by lower-layer peers.
これは、ユーザーがセキュリティポリシーの問題として受け入れられるciphersuitesを構成できるようにすることで実行できます。または、EAP認証から派生したキーイングマテリアルと、低層のピアが事前に合意したマイクアルゴリズムを使用して、Ciphersuiteの交渉を認証することができます。
There are reliability and security issues with link layer indications in PPP, IEEE 802 LANs, and IEEE 802.11 wireless LANs:
PPP、IEEE 802 LANS、およびIEEE 802.11ワイヤレスLANSのリンクレイヤー表示に関する信頼性とセキュリティの問題があります。
[a] PPP. In PPP, link layer indications such as LCP-Terminate (a link failure indication) and NCP (a link success indication) are not authenticated or integrity protected. They can therefore be spoofed by an attacker with access to the link.
[a] ppp。PPPでは、LCPターミネート（リンク障害表示）やNCP（リンク成功指示）などのリンクレイヤー表示は認証されていないか、整合性が保護されていません。したがって、リンクにアクセスできる攻撃者によってスプーフィングできます。
[b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are not authenticated or integrity protected. They can therefore be spoofed by an attacker with access to the link.
[b] IEEE 802. IEEE 802.1x Eapol-StartおよびEapol-Logoffフレームは認証されていないか、整合性が保護されていません。したがって、リンクにアクセスできる攻撃者によってスプーフィングできます。
[c] IEEE 802.11. In IEEE 802.11, link layer indications include Disassociate and Deauthenticate frames (link failure indications), and the first message of the 4-way handshake (link success indication). These messages are not authenticated or integrity protected, and although they are not forwardable, they are spoofable by an attacker within range.
[c] IEEE 802.11。IEEE 802.11では、リンクレイヤーの表示には、リンク関連のフレームとデーメチケートフレーム（リンク障害表示）、および4ウェイハンドシェイクの最初のメッセージ（リンクの成功表示）が含まれます。これらのメッセージは認証されておらず、整合性が保護されていません。また、前向きではありませんが、範囲内の攻撃者がスプーフィングできます。
In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3 unicast data frames, and are therefore forwardable. This implies that while EAPOL-Start and EAPOL-Logoff messages may be authenticated and integrity protected, they can be spoofed by an authenticated attacker far from the target when "pre-authentication" is enabled.
IEEE 802.11では、IEEE 802.1xデータフレームはクラス3ユニキャストデータフレームとして送信されるため、前向きです。これは、Eapol-StartおよびEapol-Logoffメッセージが認証され、整合性が保護されている可能性があるが、「承認前」が有効になっている場合、ターゲットから遠く離れた認証された攻撃者によってスプーフィングできることを意味します。
In IEEE 802.11, a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. To avoid unnecessary resets, it is advisable to damp these indications, rather than passing them directly to the EAP. Since EAP supports retransmission, it is robust against transient connectivity losses.
IEEE 802.11では、ワイヤレス信号強度が出入りする可能性があり、攻撃者によって生成された無線周波数干渉の影響を受ける可能性があるため、「リンクダウン」の表示はリンク障害の信頼性の低い兆候です。不必要なリセットを回避するには、EAPに直接渡すのではなく、これらの適応症を抑えることをお勧めします。EAPは再送信をサポートするため、一時的な接続性損失に対して堅牢です。
It is possible for the EAP peer and EAP server to mutually authenticate and derive a AAA-Key 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 client to derive the AAA-Key from the MSK and EMSK exported by the EAP method, and to subsequently pass a Transient Session Key (TSK) to the ciphersuite module.
EAPピアおよびEAPサーバーは、後続のデータトラフィックを保護するために使用されるciphersuiteのAAA-Keyを相互に認証および導き出すことができます。ピアとEAPのクライアントは同じマシンに存在するため、これはピアに問題を提示しません。必要なのは、クライアントがEAPメソッドによってエクスポートされたMSKおよびEMSKからAAA-Keyを導き出し、その後一時的なセッションキー（TSK）をCiphersuiteモジュールに渡すことです。
However, in the case where the authenticator and authentication server reside on different machines, there are several implications for security.
ただし、AuthenticatorおよびAuthentication Serverがさまざまなマシンに存在する場合、セキュリティにはいくつかの意味があります。
[a] 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 authenticator that it is speaking to, using EAP alone.
[a] ピアと認証サーバーの間では、ピアと認証者の間では、認証が発生します。これは、ピアがEAPだけを使用して、それが話している認証機の身元を検証することができないことを意味します。
[b] As discussed in [RFC3579], the authenticator is dependent on the AAA protocol in order to know the outcome of an authentication conversation, and does not look at the encapsulated EAP packet (if one is present) to determine the outcome. In practice, this implies that the AAA protocol spoken between the authenticator and authentication server MUST support per-packet authentication, integrity, and replay protection.
[b] [RFC3579]で説明したように、認証会の結果を知るために、認証機はAAAプロトコルに依存しており、結果を決定するためにカプセル化されたEAPパケット（存在する場合）を調べません。実際には、これは、AuthenticatorとAuthentication Serverの間で話されているAAAプロトコルが、パケットごとの認証、整合性、およびリプレイ保護をサポートする必要があることを意味します。
[c] After completion of the EAP conversation, where lower layer security services such as per-packet confidentiality, authentication, integrity, and replay protection will be enabled, a secure association protocol SHOULD be run between the peer and authenticator in order to provide mutual authentication between the peer and authenticator, guarantee liveness of transient session keys, provide protected ciphersuite and capabilities negotiation for subsequent data, and synchronize key usage.
[c] パケットごとの機密性、認証、整合性、リプレイ保護などの下層レイヤーセキュリティサービスが有効になるEAP会話の完了後、セキュアーアソシエーションプロトコルを、ピアと認証器の間で実行する必要があります。ピアと認証者は、一時的なセッションキーのlivensionを保証し、後続のデータの保護された暗号化と機能交渉を提供し、キーの使用法を同期させます。
[d] A AAA-Key derived from the MSK and/or EMSK negotiated between the peer and authentication server MAY be transmitted to the authenticator. Therefore, a mechanism needs to be provided to transmit the AAA-Key from the authentication server to the authenticator that needs it. The specification of the AAA-key derivation, transport, and wrapping mechanisms is outside the scope of this document. Further details on AAA-Key Derivation are provided within [KEYFRAME].
[d] ピアと認証サーバーの間でネゴシエートされたMSKおよび/またはEMSKから派生したAAA-Keyは、認証機に送信される場合があります。したがって、AAA-Keyを認証サーバーから必要な認証機に送信するために、メカニズムを提供する必要があります。AAA-KEY派生、輸送、およびラッピングメカニズムの仕様は、このドキュメントの範囲外です。AAA-Key Derivationの詳細については、[keyframe]内に記載されています。
This specification does not define a mechanism for cleartext password authentication. The omission is intentional. Use of cleartext passwords would allow the password to be captured by an attacker with access to a link over which EAP packets are transmitted.
この仕様は、クリアテキストパスワード認証のメカニズムを定義しません。省略は意図的です。ClearTextパスワードを使用すると、EAPパケットが送信されるリンクにアクセスできる攻撃者がパスワードをキャプチャできます。
Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not provide confidentiality, EAP packets may be subsequently encapsulated for transport over the Internet where they may be captured by an attacker.
RADIUS [RFC3579]などのEAPをカプセル化するプロトコルは、機密性を提供できない可能性があるため、EAPパケットは、攻撃者がキャプチャできるインターネット上の輸送用にその後カプセル化される場合があります。
As a result, cleartext passwords cannot be securely used within EAP, except where encapsulated within a protected tunnel with server authentication. Some of the same risks apply to EAP methods without dictionary attack resistance, as defined in Section 7.2.1. For details, see Section 7.6.
その結果、サーバー認証を使用して保護されたトンネル内でカプセル化されている場合を除き、EAP内でClearTextパスワードを安全に使用することはできません。セクション7.2.1で定義されているように、辞書攻撃抵抗なしのEAPメソッドには同じリスクの一部が適用されます。詳細については、セクション7.6を参照してください。
It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This may enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via a AAA or lower layer protocol).
侵害された、または実装されていないEAP認証器が、誤った情報をEAPピアやサーバーに伝達することが可能です。これにより、認証者は別の認証器になりすましたり、帯域外のメカニズムを介して誤った情報を通信したりすることができます（AAAまたは下層層プロトコルなど）。
Where EAP is used in pass-through mode, the EAP peer typically does not verify the identity of the pass-through authenticator, it only verifies that the pass-through authenticator is trusted by the EAP server. This creates a potential security vulnerability.
EAPがパススルーモードで使用されている場合、EAPピアは通常、パススルー認証器のIDを検証しません。パススルー認証器がEAPサーバーによって信頼されていることのみを確認します。これにより、潜在的なセキュリティの脆弱性が生まれます。
Section 4.3.7 of [RFC3579] describes how an EAP pass-through authenticator acting as a AAA client can be detected if it attempts to impersonate another authenticator (such by sending incorrect NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
[RFC3579]のセクション4.3.7は、AAAクライアントとして機能するEAPパススルー認証機が、別の認証因子になりすましようとする場合（誤ったNAS-IDENTIFIER [RFC2865]、NAS-IP-Address [RFC2865555]を送信することでどのように検出できるかを説明しています。]またはNAS-IPV6-アドレス
[RFC3162] attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the AAA server while communicating misleading information to the EAP peer via a lower layer protocol.
[RFC3162] AAAプロトコルを介した属性）。ただし、AAAクライアントとして機能するパススルー認証機は、下層層プロトコルを介して誤解を招く情報をEAPピアに伝えながら、AAAサーバーに正しい情報を提供する可能性があります。
For example, it is possible for a compromised authenticator to utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via a lower layer protocol, or for a pass-through authenticator acting as a AAA client to provide an incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA protocol.
たとえば、侵害された認証装置が、下層のプロトコルを介してEAPピアと通信する際に、別の認証装置と呼ばれるステーションIDまたはNAS-IDENTIFIERを利用することができます。AAAプロトコルを介してAAAサーバーに誤ったピアコールステーション-ID [RFC2865] [RFC3580]。
In order to address this vulnerability, EAP methods may support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162].
この脆弱性に対処するために、EAPメソッドは、エンドポイント識別子などのチャネルプロパティの保護された交換をサポートする可能性があります（ただし、これらに限定されません）：ステーションID [RFC2865] [RFC3580]、Calling-Station-ID [RFC2865][RFC3580]、Nas-Identifier [RFC2865]、Nas-IP-Address [RFC2865]、およびNaS-IPV6-Address [RFC3162]。
Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. Where discrepancies are found, these SHOULD be logged; additional actions MAY also be taken, such as denying access.
このような保護された交換を使用すると、EAPメソッド内で交換されたメカニズムに対して、帯域外のメカニズムを介して認証器が提供するチャネルプロパティを一致させることができます。矛盾が見つかる場合、これらは記録する必要があります。アクセスの拒否など、追加のアクションも実行される場合があります。
Within EAP, Success and Failure packets are neither acknowledged nor integrity protected. Result indications improve resilience to loss of Success and Failure packets when EAP is run over lower layers which do not support retransmission or synchronization of the authentication state. In media such as IEEE 802.11, which provides for retransmission, as well as synchronization of authentication state via the 4-way handshake defined in [IEEE-802.11i], additional resilience is typically of marginal benefit.
EAP内では、成功と失敗のパケットは認識されておらず、整合性も保護されていません。結果の適応症は、認証状態の再送信または同期をサポートしない下層層上でEAPが実行される場合、成功と失敗のパケットの喪失に対する回復力を改善します。再送信を規定するIEEE 802.11などのメディアと、[IEEE-802.11i]で定義された4ウェイハンドシェイクを介した認証状態の同期では、追加の回復力は通常、わずかな利益をもたらします。
Depending on the method and circumstances, result indications can be spoofable by an attacker. A method is said to provide protected result indications if it supports result indications, as well as the "integrity protection" and "replay protection" claims. A method supporting protected result indications MUST indicate which result indications are protected, and which are not.
方法と状況に応じて、結果の表示は攻撃者が引き起こす可能性があります。メソッドは、結果の表示と「整合性保護」および「リプレイ保護」クレームをサポートする場合、保護された結果の表示を提供すると言われています。保護された結果の表示をサポートするメソッドは、どの結果表示が保護されているかを示している必要があります。
Protected result indications are not required to protect against rogue authenticators. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator.
Rogue Authenticatorから保護するために、保護された結果の表示は必要ありません。相互に認証する方法内で、ピアが成功する前にサーバーがピアに認証することを要求することで、攻撃者が不正な認証者として行動することを防ぎます。
However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the peer has authenticated to the server. If the peer were to accept the forged Success packet and attempt to access the network when it had not yet successfully authenticated to the server, a denial of service attack could be mounted against the peer. After such an attack, if the lower layer supports failure indications, the authenticator can synchronize state with the peer by providing a lower layer failure indication. See Section 7.12 for details.
ただし、サーバーがピアに認証された後、ピアがサーバーに認証される前に、攻撃者が成功パケットを築くことができます。ピアがForged Successパケットを受け入れ、サーバーにまだ正常に認証されていない場合にネットワークにアクセスしようとした場合、ピアに対してサービス拒否攻撃をマウントすることができます。このような攻撃の後、下層が障害の表示をサポートする場合、認証器は下層層の故障指示を提供することにより、状態をピアと同期させることができます。詳細については、セクション7.12を参照してください。
If a server were to authenticate the peer and send a Success packet prior to determining whether the peer has authenticated the authenticator, an idle timeout can occur if the authenticator is not authenticated by the peer. Where supported by the lower layer, an authenticator sensing the absence of the peer can free resources.
サーバーがピアを認証し、ピアが認証機を認証するかどうかを判断する前にサクセスパケットを送信する場合、認証機がピアによって認証されない場合、アイドルタイムアウトが発生する可能性があります。下層にサポートされている場合、ピアがないことを感知する認証者は、リソースを解放できます。
In a method supporting result indications, a peer that has authenticated the server does not consider the authentication successful until it receives an indication that the server successfully authenticated it. Similarly, a server that has successfully authenticated the peer does not consider the authentication successful until it receives an indication that the peer has authenticated the server.
結果の表示をサポートするメソッドでは、サーバーが認証が成功するとは、サーバーが正常に認証されたことを受け取るまで認証を成功させることはありません。同様に、ピアを正常に認証したサーバーは、ピアがサーバーを認証したことを示すことを受信するまで、認証を成功させることはありません。
In order to avoid synchronization problems, prior to sending a success result indication, it is desirable for the sender to verify that sufficient authorization exists for granting access, though, as discussed below, this is not always possible.
同期の問題を回避するために、成功結果の表示を送信する前に、送信者がアクセスを付与するための十分な承認が存在することを確認することが望ましいですが、以下で説明するように、これは常に可能ではありません。
While result indications may enable synchronization of the authentication result between the peer and server, this does not guarantee that the peer and authenticator will be synchronized in terms of their authorization or that timeouts will not occur. For example, the EAP server may not be aware of an authorization decision made by a AAA proxy; the AAA server may check authorization only after authentication has completed successfully, to discover that authorization cannot be granted, or the AAA server may grant access but the authenticator may be unable to provide it due to a temporary lack of resources. In these situations, synchronization may only be achieved via lower layer result indications.
結果の適応症は、ピアとサーバーの間の認証結果の同期を可能にする可能性がありますが、これは、ピアと認証者が許可の観点から同期されるか、タイムアウトが発生しないことを保証するものではありません。たとえば、EAPサーバーは、AAAプロキシによって行われた承認決定を認識していない場合があります。AAAサーバーは、認証が正常に完了した後にのみ承認を確認することができます。認証は許可できないことを発見するか、AAAサーバーがアクセスを付与する場合がありますが、認証者は一時的なリソースの不足により提供できない場合があります。これらの状況では、同期は、下層結果の表示を介してのみ達成できます。
Success indications may be explicit or implicit. For example, where a method supports error messages, an implicit success indication may be defined as the reception of a specific message without a preceding error message. Failures are typically indicated explicitly. As described in Section 4.2, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an error message prior to accepting a Failure packet.
成功の兆候は、明示的または暗黙的である可能性があります。たとえば、メソッドがエラーメッセージをサポートする場合、暗黙的な成功指示は、先行するエラーメッセージなしで特定のメッセージの受信として定義される場合があります。通常、障害は明示的に示されています。セクション4.2で説明されているように、ピアは、この方法がこれを明示的に許可しない時点で受け取った障害パケットを静かに破棄します。たとえば、独自のエラーメッセージを提供するメソッドでは、障害パケットを受け入れる前にピアがエラーメッセージを受信する必要がある場合があります。
Per-packet authentication, integrity, and replay protection of result indications protects against spoofing. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication", "integrity protection", and "replay protection" claims.
パケットごとの認証、整合性、および結果表示のリプレイ保護は、スプーフィングから保護されます。保護された結果の表示には、パケットごとの認証と整合性保護のためにキーを使用する必要があるため、保護された結果の表示をサポートする方法は、「キー派生」、「相互認証」、「整合性保護」、および「リプレイ保護」の主張もサポートする必要があります。
Protected result indications address some denial-of-service vulnerabilities due to spoofing of Success and Failure packets, though not all. EAP methods can typically provide protected result indications only in some circumstances. For example, errors can occur prior to key derivation, and so it may not be possible to protect all failure indications. It is also possible that result indications may not be supported in both directions or that synchronization may not be achieved in all modes of operation.
保護された結果の適応症は、すべてではありませんが、成功と失敗のパケットのスプーフィングによるいくつかのサービス拒否の脆弱性に対処しています。EAPメソッドは通常、状況によってのみ保護された結果の表示を提供できます。たとえば、キー導出の前にエラーが発生する可能性があるため、すべての障害指示を保護することはできない場合があります。また、結果の表示が両方向にサポートされない場合や、すべての動作モードで同期が達成されない可能性があります。
For example, within EAP-TLS [RFC2716], in the client authentication handshake, the server authenticates the peer, but does not receive a protected indication of whether the peer has authenticated it. In contrast, the peer authenticates the server and is aware of whether the server has authenticated it. In the session resumption handshake, the peer authenticates the server, but does not receive a protected indication of whether the server has authenticated it. In this mode, the server authenticates the peer and is aware of whether the peer has authenticated it.
たとえば、EAP-TLS [RFC2716]内で、クライアント認証ハンドシェイクでは、サーバーはピアを認証しますが、ピアが認証したかどうかの保護された兆候を受け取りません。対照的に、ピアはサーバーを認証し、サーバーがそれを認証しているかどうかを認識しています。セッションの再開ハンドシェイクでは、ピアはサーバーを認証しますが、サーバーが認証されているかどうかの保護された表示を受け取りません。このモードでは、サーバーはピアを認証し、ピアがそれを認証したかどうかを認識しています。
This protocol derives much of its inspiration from Dave Carrel's AHA document, as well as the PPP CHAP protocol [RFC1994]. Valuable feedback was provided by Yoshihiro Ohba of Toshiba America Research, Jari Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan Payne of the University of Maryland, Steve Bellovin of AT&T Research, Paul Funk of Funk Software, Pasi Eronen of Nokia, Joseph Salowey of Cisco, Paul Congdon of HP, and members of the EAP working group.
このプロトコルは、Dave CarrelのAHA文書とPPP Chapプロトコル[RFC1994]からインスピレーションの多くを導き出します。貴重なフィードバックは、東芝研究のヨシヒロ・オバ、エリクソンのジャリ・アークコ、マイクロソフトのサチン・セス、シスコ・システムズのグレン・ゾーン、インテルのジェシー・ウォーカー、ビル・アルボー、ニック・ペトロニ、メリーランド大学のブライアン・ペイン、スティーブ・ベロビンのブライアン・ペインによって提供されました。AT＆Tリサーチ、ファンクソフトウェアのポールファンク、ノキアのパシエロネン、シスコのジョセフサロウィー、HPのポールコンドン、およびEAPワーキンググループのメンバー。
The use of Security Claims sections for EAP methods, as required by Section 7.2 and specified for each EAP method described in this document, was inspired by Glen Zorn through [EAP-EVAL].
セクション7.2で要求され、このドキュメントで説明されている各EAPメソッドに指定されたEAPメソッドのセキュリティクレームセクションの使用は、[EAP-EVAL]を通じてGlen Zornに触発されました。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[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月。
[RFC2243] Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
[RFC2243] Metz、C。、「OTP Extended Responses」、RFC 2243、1997年11月。
[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月。
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", RFC 2289, February 1998.
[RFC2289] Haller、N.、N.、Metz、C.、Nesser、P。and M. Straw、「1回限りのパスワードシステム」、RFC 2289、1998年2月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[IEEE-802] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Overview and Architecture", IEEE Standard 802, 1990.
[IEEE-802]電気およびエレクトロニクスエンジニアの研究所、「ローカルおよびメトロポリタンエリアネットワーク：概要とアーキテクチャ」、IEEE Standard 802、1990。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001.
[IEEE-802.1X]電気および電子機器エンジニアの研究所、「ローカルおよびメトロポリタンエリアネットワーク：ポートベースのネットワークアクセス制御」、IEEE Standard 802.1x、2001年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510] Kohl、J。およびB. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性推奨」、RFC 1750、1994年12月。
[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T.、Allen、C.、Treese、W.、Karlton、P.、Freier、A。、およびP. Kocher、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284] Blunk、L。およびJ. Vollbrecht、「PPP拡張可能な認証プロトコル（EAP）」、RFC 2284、1998年3月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408] Maughan、D.、Schneider、M。and M. Schertler、「Internet Security Association and Key Management Protocol（ISAKMP）」、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[RFC2433] Zorn、G。およびS. Cobb、「Microsoft PPP Chap Extensions」、RFC 2433、1998年10月。
[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月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。およびB. Palter、 "層2トンネリングプロトコル" L2TP ""、RFC 2661、1999年8月。
[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月。
[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月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。and V.Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。およびD. Mitton、「Radius and IPv6」、RFC 3162、2001年8月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（リモート認証ダイヤルインユーザーサービス）拡張可能な認証プロトコル（EAP）のサポート」、RFC 3579、2003年9月。
[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.、Aboba、B.、Smith、A.、Zorn、G。、およびJ. Roese、「IEEE 802.1xリモート認証ダイヤルインユーザーサービス（RADIUS）使用ガイドライン」、RFC 3580、2003年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、2004年1月。
[DECEPTION] Slatalla, M. and J. Quittner, "Masters of Deception", Harper-Collins, New York, 1995.
[Deception] Slatalla、M。and J. Quittner、「Masters of Deception」、Harper-Collins、ニューヨーク、1995年。
[KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos Password Security", Proceedings of the 1999 ISOC Network and Distributed System Security Symposium, http://www.isoc.org/isoc/conferences/ndss/99/ proceedings/papers/wu.pdf.
[Krbattack] Wu、T。、「Kerberosパスワードセキュリティの実際の分析」、1999年のISOCネットワークおよび分散システムセキュリティシンポジウムの議事録、http：//www.isoc.org/isoc/conferences/ndss/99/議事録/論文/wu.pdf。
[KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos authentication system", Proceedings of the 1991 Winter USENIX Conference, pp. 253-267, 1991.
[Krblim] Bellovin、S。およびM. Merrit、「Kerberos認証システムの制限」、1991年冬のUsenix Conferenceの議事録、pp。253-267、1991。
[KERB4WEAK] Dole, B., Lodin, S. and E. Spafford, "Misplaced trust: Kerberos 4 session keys", Proceedings of the Internet Society Network and Distributed System Security Symposium, pp. 60-70, March 1997.
[Kerb4Weak] Dole、B.、Lodin、S。、およびE. Spafford、「誤った信頼：Kerberos 4セッションキー」、インターネット社会ネットワークの議事録およびSystem Security Symposiumの分配、60-70ページ、1997年3月。
[PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A Pre-IKE Credential Provisioning Protocol", Work in Progress, October 2002.
[PIC] Aboba、B.、Krawczyk、H。and Y. Sheffer、「Pic、A Credential Provisioning Protocol」、2002年10月の作業。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, January 2004.
[IKEV2] Kaufman、C。、「Internet Key Exchange（IKEV2）Protocol」、2004年1月の作業。
[PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's Point-to- Point Tunneling Protocol", Proceedings of the 5th ACM Conference on Communications and Computer Security, ACM Press, November 1998.
[PPTPV1] Schneier、B。and Mudge、「Microsoftのポイントツーポイントトンネルプロトコルの暗号分析」、1998年11月、ACM Press、ACM Communications and Computer Security Conferenceの議事録。
[IEEE-802.11] Institute of Electrical and Electronics Engineers, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1999.
[IEEE-802.11]電気およびエレクトロニクスエンジニアの研究所、「ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様」、IEEE Standard 802.11、1999。
[SILVERMAN] Silverman, Robert D., "A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths", RSA Laboratories Bulletin 13, April 2000 (Revised November 2001), http://www.rsasecurity.com/rsalabs/bulletins/ bulletin13.html.
[シルバーマン]シルバーマン、ロバートD.、「対称および非対称のキー長のコストベースのセキュリティ分析」、RSA研究所速報13、2000年4月13日（2001年11月改訂）、http：//www.rsasecurity.com/rsalabs/bulletins/ bulletin13.html。
[KEYFRAME] Aboba, B., "EAP Key Management Framework", Work in Progress, October 2003.
[Keyframe] Aboba、B。、「EAP Key Management Framework」、2003年10月、進行中の作業。
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for user names and passwords", Work in Progress, March 2004.
[SASLPrep] Zeilenga、K。、「Saslprep：ユーザー名とパスワードのStringPrepプロファイル」、2004年3月、進行中の作業。
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, "Unapproved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE Draft 802.11i (work in progress), 2003.
[IEEE -802.11i]電気および電子機器エンジニア研究所、「システム間の電気通信および情報交換の標準の承認されていないドラフトサプリメント - LAN/MAN固有の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様：強化されたセキュリティの仕様」、IEEEドラフト802.11i（作業中の作業）、2003年。
[DIAM-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", Work in Progress, February 2004.
[Diam-eap] Eronen、P.、Hiller、T。and G. Zorn、「直径拡張可能な認証プロトコル（EAP）アプリケーション」、2004年2月の作業。
[EAP-EVAL] Zorn, G., "Specifying Security Claims for EAP Authentication Types", Work in Progress, October 2002.
[EAP-EVAL] Zorn、G。、「EAP認証タイプのセキュリティ請求の指定」、2002年10月、進行中の作業。
[BINDING] Puthenkulam, J., "The Compound Authentication Binding Problem", Work in Progress, October 2003.
[バインディング] Puthenkulam、J。、「化合物認証結合問題」、2003年10月、進行中の作業。
[MITM] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-Middle in Tunneled Authentication Protocols", IACR ePrint Archive Report 2002/163, October 2002, <http://eprint.iacr.org/2002/163>.
[MITM] Asokan、N.、Niemi、V。およびK. Nyberg、「トンネル認証プロトコルの中間の中間」、IACR Eprint Archive Report 2002/163、2002年10月、<http：//eprint.iacr.org/2002/163>。
[IEEE-802.11i-req] Stanley, D., "EAP Method Requirements for Wireless LANs", Work in Progress, February 2004.
[IEEE-802.11-Req] Stanley、D。、「ワイヤレスLANSのEAPメソッド要件」、2004年2月、進行中の作業。
[PPTPv2] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)", CQRE 99, Springer-Verlag, 1999, pp. 192-203.
[PPTPV2] Schneier、B。and Mudge、「MicrosoftのPPTP認証拡張機能の暗号分析（MS-Chapv2）」、CQRE 99、Springer-Verlag、1999、pp。192-203。
This section lists the major changes between [RFC2284] and this document. Minor changes, including style, grammar, spelling, and editorial changes are not mentioned here.
このセクションには、[RFC2284]とこのドキュメントの間の主要な変更をリストします。ここでは、スタイル、文法、スペル、編集上の変更を含む小さな変更は言及されていません。
o The Terminology section (Section 1.2) has been expanded, defining more concepts and giving more exact definitions.
o 用語セクション（セクション1.2）が拡張されており、より多くの概念を定義し、より正確な定義を提供しています。
o The concepts of Mutual Authentication, Key Derivation, and Result Indications are introduced and discussed throughout the document where appropriate.
o 相互認証、重要な派生、および結果の表示の概念は、必要に応じて文書全体で紹介および議論されます。
o In Section 2, it is explicitly specified that more than one exchange of Request and Response packets may occur as part of the EAP authentication exchange. How this may be used and how it may not be used is specified in detail in Section 2.1.
o セクション2では、EAP認証交換の一部として複数のリクエストと応答パケットの交換が発生する可能性があることが明示的に指定されています。これがどのように使用されるか、どのように使用されないかは、セクション2.1で詳細に指定されています。
o Also in Section 2, some requirements have been made explicit for the authenticator when acting in pass-through mode.
o また、セクション2では、パススルーモードで行動する際に、いくつかの要件が認証器に明示的になっています。
o An EAP multiplexing model (Section 2.2) has been added to illustrate a typical implementation of EAP. There is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it.
o EAPの典型的な実装を示すために、EAPマルチプレックスモデル（セクション2.2）が追加されています。オンザワイヤの動作がそれと一致している限り、実装がこのモデルに適合するという要件はありません。
o As EAP is now in use with a variety of lower layers, not just PPP for which it was first designed, Section 3 on lower layer behavior has been added.
o EAPは現在、最初に設計されたPPPだけでなく、さまざまな下層層で使用されているため、下層の動作に関するセクション3が追加されています。
o In the description of the EAP Request and Response interaction (Section 4.1), both the behavior on receiving duplicate requests, and when packets should be silently discarded has been more exactly specified. The implementation notes in this section have been substantially expanded.
o EAPリクエストと応答の相互作用（セクション4.1）の説明では、重複リクエストを受信する際の動作と、パケットを静かに破棄する場合の両方がより正確に指定されています。このセクションの実装ノートは大幅に拡張されています。
o In Section 4.2, it has been clarified that Success and Failure packets must not contain additional data, and the implementation note has been expanded. A subsection giving requirements on processing of success and failure packets has been added.
o セクション4.2では、成功と失敗のパケットが追加のデータを含めてはならず、実装ノートが拡張されていることが明らかになりました。成功と失敗のパケットの処理に関する要件を与えるサブセクションが追加されました。
o Section 5 on EAP Request/Response Types lists two new Type values: the Expanded Type (Section 5.7), which is used to expand the Type value number space, and the Experimental Type. In the Expanded Type number space, the new Expanded Nak (Section 5.3.2) Type has been added. Clarifications have been made in the description of most of the existing Types. Security claims summaries have been added for authentication methods.
o EAP要求/応答タイプのセクション5には、2つの新しいタイプの値がリストされています。拡張されたタイプ（セクション5.7）。これは、タイプ値番号スペースを拡張するために使用され、実験型です。拡張されたタイプ番号スペースでは、新しい拡張されたNAK（セクション5.3.2）タイプが追加されました。既存のタイプのほとんどの説明で説明されています。認証方法については、セキュリティクレームの概要が追加されました。
o In Sections 5, 5.1, and 5.2, a requirement has been added such that fields with displayable messages should contain UTF-8 encoded ISO 10646 characters.
o セクション5、5.1、および5.2では、表示可能なメッセージを持つフィールドにUTF-8エンコードされたISO 10646文字を含めるように要件が追加されています。
o It is now required in Section 5.1 that if the Type-Data field of an Identity Request contains a NUL-character, only the part before the null is displayed. RFC 2284 prohibits the null termination of the Type-Data field of Identity messages. This rule has been relaxed for Identity Request messages and the Identity Request Type-Data field may now be null terminated.
o セクション5.1では、IDリクエストのタイプデータフィールドにnulキャラクターが含まれている場合、nullの前の部分のみが表示されることが必要です。RFC 2284は、アイデンティティメッセージのタイプデータフィールドのnull終了を禁止しています。このルールは、IDリクエストメッセージのために緩和されており、IDリクエストタイプデータフィールドがnull終了する可能性があります。
o In Section 5.5, support for OTP Extended Responses [RFC2243] has been added to EAP OTP.
o セクション5.5では、OTP拡張応答[RFC2243]のサポートがEAP OTPに追加されました。
o An IANA Considerations section (Section 6) has been added, giving registration policies for the numbering spaces defined for EAP.
o IANAの考慮事項セクション（セクション6）が追加されており、EAP用に定義された番号付けスペースの登録ポリシーを提供しています。
o The Security Considerations (Section 7) have been greatly expanded, giving a much more comprehensive coverage of possible threats and other security considerations.
o セキュリティ上の考慮事項（セクション7）は大幅に拡大されており、脅威の可能性やその他のセキュリティに関する考慮事項をより包括的な報道を提供しています。
o In Section 7.5, text has been added on method-specific behavior, providing guidance on how EAP method-specific integrity checks should be processed. Where possible, it is desirable for a method-specific MIC to be computed over the entire EAP packet, including the EAP layer header (Code, Identifier, Length) and EAP method layer header (Type, Type-Data).
o セクション7.5では、メソッド固有の動作に関するテキストが追加されており、EAPメソッド固有の整合性チェックをどのように処理するかについてのガイダンスを提供しています。可能であれば、EAPレイヤーヘッダー（コード、識別子、長さ）やEAPメソッドレイヤーヘッダー（タイプ、タイプデータ）など、EAPパケット全体でメソッド固有のマイクを計算することが望ましいです。
o In Section 7.14 the security risks involved in use of cleartext passwords with EAP are described.
o セクション7.14では、EAPを使用したクリアテキストパスワードの使用に伴うセキュリティリスクについて説明します。
o In Section 7.15 text has been added relating to detection of rogue NAS behavior.
o セクション7.15では、Rogue NASの行動の検出に関するテキストが追加されています。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
バーナード・アボバ・マイクロソフト・コーポレーションワン・マイクロソフト・ウェイ・レドモンド、ワシントン州98052 USA
Phone: +1 425 706 6605
Fax: +1 425 936 6605
EMail: bernarda@microsoft.com
Larry J. Blunk Merit Network, Inc 4251 Plymouth Rd., Suite 2000 Ann Arbor, MI 48105-2785 USA
Larry J. Blunk Merit Network、Inc 4251 Plymouth Rd。、Suite 2000 Ann Arbor、MI 48105-2785 USA
Phone: +1 734-647-9563
Fax: +1 734-647-3185
EMail: ljb@merit.edu
John R. Vollbrecht Vollbrecht Consulting LLC 9682 Alice Hill Drive Dexter, MI 48130 USA
John R. Vollebrecht Vollebrecht Consulting LLC 9682 Alice Hill Drive Dexter、MI 48130 USA
EMail: jrv@umich.edu
James Carlson Sun Microsystems, Inc 1 Network Drive Burlington, MA 01803-2757 USA
James Carlson Sun Systems、Inc 1ネットワークドライブバーリントン、マサチューセッツ州01803-2757 USA
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Henrik Levkowetz ipUnplugged AB Arenavagen 33 Stockholm S-121 28 SWEDEN
Henrik Levkowetz Ipunplugged AB Arenavagen 33 Stockholm S-121 28 Sweden
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。