[要約] RFC 4137は、EAPピアと認証子のための状態機械に関する仕様であり、EAPフレームワークの拡張性を向上させることを目的としています。
Network Working Group J. Vollbrecht
Request for Comments: 4137 Meetinghouse Data Communications
Category: Informational P. Eronen
Nokia
N. Petroni
University of Maryland
Y. Ohba
TARI
August 2005
State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator
拡張可能な認証プロトコル（EAP）ピアおよび認証器用の状態マシン
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes a set of state machines for Extensible Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.
このドキュメントでは、拡張可能な認証プロトコル（EAP）ピア、EAPスタンドアロン認証機（非パススルー）、EAPバックエンド認証器（認証、承認、会計（AAA）サーバーで使用）、およびEAPバックエンド認証器のための一連の状態マシンについて説明します。EAPフル認証器（ローカルとパススルーの両方）。この一連の状態マシンは、Peer/AuthenticatorまたはPeer/Authenticator/AAA Server環境のいずれかでの展開をサポートするためにEAPを実装する方法を示しています。ピアおよびスタンドアロンの認証機マシンは、RFC 3748で定義されているEAPプロトコルがどのように実装されるかを示しています。バックエンドとフル/パススルー認証機は、RFC 3579で定義されているEAP/AAAプロトコルサポートを実装する方法を示しています。違いがある場合、RFC 3748およびRFC 3579は権威があります。
The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.
状態マシンは、EAP「スイッチ」モデルに基づいています。このモデルには、EAPスイッチとEAPメソッド間の相互作用のためのイベントとアクションが含まれます。EAP「スイッチ」モデルの簡単な説明は、紹介セクションに記載されています。
The state machine and associated model are informative only. Implementations may achieve the same results using different methods.
状態マシンと関連するモデルは有益です。実装は、異なる方法を使用して同じ結果を達成する場合があります。
Table of Contents
目次
1. Introduction: The EAP Switch Model ..............................3
2. Specification of Requirements ...................................4
3. Notational Conventions Used in State Diagrams ...................5
3.1. Notational Specifics .......................................5
3.2. State Machine Symbols ......................................7
3.3. Document Authority .........................................8
4. Peer State Machine ..............................................9
4.1. Interface between Peer State Machine and Lower Layer .......9
4.2. Interface between Peer State Machine and Methods ..........11
4.3. Peer State Machine Local Variables ........................13
4.4. Peer State Machine Procedures .............................14
4.5. Peer State Machine States .................................15
5. Stand-Alone Authenticator State Machine ........................17
5.1. Interface between Stand-Alone Authenticator State
Machine and Lower Layer ...................................17
5.2. Interface between Stand-Alone Authenticator State
Machine and Methods .......................................19
5.3. Stand-Alone Authenticator State Machine Local Variables ...21
5.4. EAP Stand-Alone Authenticator Procedures ..................22
5.5. EAP Stand-Alone Authenticator States ......................24
6. EAP Backend Authenticator ......................................26
6.1. Interface between Backend Authenticator State
Machine and Lower Layer ...................................26
6.2. Interface between Backend Authenticator State
Machine and Methods .......................................28
6.3. Backend Authenticator State Machine Local Variables .......28
6.4. EAP Backend Authenticator Procedures ......................28
6.5. EAP Backend Authenticator States ..........................29
7. EAP Full Authenticator .........................................29
7.1. Interface between Full Authenticator State Machine
and Lower Layer ...........................................30
7.2. Interface between Full Authenticator State Machine
and Methods ...............................................31
7.3. Full Authenticator State Machine Local Variables ..........32
7.4. EAP Full Authenticator Procedures .........................32
7.5. EAP Full Authenticator States .............................32
8. Implementation Considerations ..................................34
8.1. Robustness ................................................34
8.2. Method/Method and Method/Lower-Layer Interfaces ...........35
8.3. Peer State Machine Interoperability with Deployed
Implementations ...........................................35
9. Security Considerations ........................................35
10. Acknowledgements ..............................................36
11. References ....................................................37
11.1. Normative References ....................................37
11.2. Informative References ..................................37
Appendix. ASCII Versions of State Diagrams ........................38
A.1. EAP Peer State Machine (Figure 3) .......................38
A.2. EAP Stand-Alone Authenticator State Machine (Figure 4) ..41
A.3. EAP Backend Authenticator State Machine (Figure 5) ......44
A.4. EAP Full Authenticator State Machine (Figures 6 and 7) ..47
This document offers a proposed state machine for RFCs [RFC3748] and [RFC3579]. There are state machines for the peer, the stand-alone authenticator, a backend authenticator, and a full/pass-through authenticator. Accompanying each state machine diagram is a description of the variables, the functions, and the states in the diagram. Whenever possible, the same notation has been used in each of the state machines.
このドキュメントは、RFCS [RFC3748]および[RFC3579]用の提案された状態マシンを提供します。ピア用の状態マシン、スタンドアロン認証器、バックエンド認証器、フル/パススルー認証器があります。各ステートマシン図に伴うのは、図の変数、関数、および状態の説明です。可能な限り、各状態マシンで同じ表記が使用されています。
An EAP authentication consists of one or more EAP methods in sequence followed by an EAP Success or EAP Failure sent from the authenticator to the peer. The EAP switches control negotiation of EAP methods and sequences of methods.
EAP認証は、1つ以上のEAPメソッドで構成され、その後にEAPの成功またはEAP障害が認証者からピアに送られました。EAPは、EAPメソッドの制御交渉と一連の方法を制御する。
Peer Peer | Authenticator Auth
Method | Method
\ | /
\ | /
Peer | Auth
EAP <-----|----------> EAP
Switch | Switch
Figure 1: EAP Switch Model
図1：EAPスイッチモデル
At both the peer and authenticator, one or more EAP methods exist. The EAP switches select which methods each is willing to use, and negotiate between themselves to pick a method or sequence of methods.
ピアと認証者の両方に、1つ以上のEAPメソッドが存在します。EAPは、それぞれを使用する意思のあるメソッドを選択し、メソッドまたはシーケンスのメソッドを選択するために自分自身を交渉します。
Note that the methods may also have state machines. The details of these are outside the scope of this paper.
メソッドには状態マシンもある場合があることに注意してください。これらの詳細は、この論文の範囲外です。
Peer | Authenticator | Backend
| / Local |
| / Method |
Peer | Auth | Backend
EAP -|-----> EAP | --> EAP
Switch | Switch | / Server
| \ | /
| \ pass-through |
| |
Figure 2: EAP Pass-Through Model
図2：EAPパススルーモデル
The Full/Pass-Through state machine allows an NAS or edge device to pass EAP Response messages to a backend server where the authentication method resides. This paper includes a state machine for the EAP authenticator that supports both local and pass-through methods as well as a state machine for the backend authenticator existing at the AAA server. A simple stand-alone authenticator is also provided to show a basic, non-pass-through authenticator's behavior.
フル/パススルーステートマシンにより、NASまたはエッジデバイスは、認証方法が存在するバックエンドサーバーにEAP応答メッセージを渡すことができます。このホワイトペーパーには、ローカルとパススルーの両方の方法をサポートするEAP認証器用の状態マシンと、AAAサーバーに存在するバックエンド認証器用の状態マシンが含まれています。シンプルなスタンドアロン認証器も提供されており、基本的な非パススルー認証因子の動作を示すものです。
This document describes a set of state machines that can manage EAP authentication from the peer to an EAP method on the authenticator or from the peer through the authenticator pass-through method to the EAP method on the backend EAP server.
このドキュメントでは、ピアからAuthenticatorのEAPメソッド、またはピアからAuthenticator Pass-Sthroughメソッドを介してバックエンドEAPサーバーのEAPメソッドまでのEAPメソッドまでのEAP認証を管理できる一連の状態マシンについて説明します。
Some environments where EAP is used, such as PPP, may support peer-to-peer operation. That is, both parties act as peers and authenticators at the same time, in two simultaneous and independent EAP conversations. In this case, the implementation at each node has to perform demultiplexing of incoming EAP packets. EAP packets with code set to Response are delivered to the authenticator state machine, and EAP packets with code set to Request, Success, or Failure are delivered to the peer state machine.
PPPなどのEAPが使用される一部の環境は、ピアツーピア操作をサポートする場合があります。つまり、両当事者は、2つの同時および独立したEAP会話で、同時にピアと認証者として機能します。この場合、各ノードでの実装は、着信EAPパケットの非gultiplexingを実行する必要があります。応答に設定されたコードを備えたEAPパケットは、Authenticator Stateマシンに配信され、リクエスト、成功、または障害に設定されたコードを備えたEAPパケットがピアステートマシンに配信されます。
The state diagrams presented in this document have been coordinated with the diagrams in [1X-2004]. The format of the diagrams is adapted from the format therein. The interface between the state machines defined here and the IEEE 802.1X-2004 state machines is also explained in Appendix F of [1X-2004].
この文書に示されている状態図は、[2004年1x]の図と調整されています。図の形式は、その形式から採用されています。ここで定義されている状態マシンとIEEE 802.1x-2004の状態マシン間のインターフェイスも、[1x-2004]の付録Fで説明されています。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「必要」、「必須」、「「しなければ」、「そうしない」、「そうではない」、「そうはならない」、「そうでない」、「推奨」、「5月」、および「オプション」は解釈する必要があります[RFC2119]で説明されているように。
The following state diagrams have been completed based on the conventions specified in [1X-2004], section 8.2.1. The complete text is reproduced here:
次の状態図は、[1x-2004]、セクション8.2.1で指定された規則に基づいて完成しました。完全なテキストがここに再現されています：
State diagrams are used to represent the operation of the protocol by a number of cooperating state machines, each comprising a group of connected, mutually exclusive states. Only one state of each machine can be active at any given time.
状態図は、それぞれが接続された相互に排他的な状態のグループで構成される多くの協力状態マシンによるプロトコルの動作を表すために使用されます。いつでもアクティブにできるのは、各マシンの1つの状態のみです。
Each state is represented in the state diagram as a rectangular box, divided into two parts by a horizontal line. The upper part contains the state identifier, written in uppercase letters. The lower part contains any procedures that are executed upon entry to the state.
各状態は、状態図に長方形のボックスとして表され、水平線で2つの部分に分割されています。上部には、大文字で書かれた状態識別子が含まれています。下部には、州への参入時に実行される手順が含まれています。
All permissible transitions between states are represented by arrows, the arrowhead denoting the direction of the possible transition. Labels attached to arrows denote the condition(s) that must be met in order for the transition to take place. All conditions are expressions that evaluate to TRUE or FALSE; if a condition evaluates to TRUE, then the condition is met. The label UCT denotes an unconditional transition (i.e., UCT always evaluates to TRUE). A transition that is global in nature (i.e., a transition that occurs from any of the possible states if the condition attached to the arrow is met) is denoted by an open arrow; i.e., no specific state is identified as the origin of the transition. When the condition associated with a global transition is met, it supersedes all other exit conditions including UCT. The special global condition BEGIN supersedes all other global conditions, and once asserted it remains asserted until all state blocks have executed to the point that variable assignments and other consequences of their execution remain unchanged.
状態間の許容されるすべての遷移は、矢印で表され、矢印は遷移の可能性の方向を示します。矢印に添付されたラベルは、移行が行われるために満たさなければならない条件を示します。すべての条件は、真またはfalseを評価する式です。条件がtrueに評価された場合、条件は満たされます。ラベルUCTは、無条件の遷移を示します（つまり、UCTは常にTRUEに評価されます）。本質的にグローバルな遷移（つまり、矢印に付随する条件が満たされている場合に可能な状態のいずれかから発生する遷移）は、開いた矢印で示されます。すなわち、遷移の起源として特定される特定の状態はありません。グローバルな移行に関連する状態が満たされると、UCTを含む他のすべての出口条件に取って代わります。特別なグローバルな条件は、他のすべてのグローバル条件に取って代わることになり、すべての州ブロックが変数の割り当てやその他の結果が変化しないようになるまで実行されるまで、それを主張すると主張されたままです。
On entry to a state, the procedures defined for the state (if any) are executed exactly once, in the order that they appear on the page. Each action is deemed to be atomic; i.e., execution of a procedure completes before the next sequential procedure starts to execute. No procedures execute outside a state block. The procedures in only one state block execute at a time, even if the conditions for execution of state blocks in different state machines are satisfied, and all procedures in an executing state block complete execution before the transition to and execution of any other state block occurs. That is, the execution of any state block appears to be atomic with respect to the execution of any other state block, and the transition condition to that state from the previous state is TRUE when execution commences. The order of execution of state blocks in different state machines is undefined except as constrained by their transition conditions. A variable that is set to a particular value in a state block retains this value until a subsequent state block executes a procedure that modifies the value.
州への入場時に、州に対して定義された手順（もしあれば）は、ページに表示される順序で正確に1回実行されます。各アクションは原子と見なされます。つまり、手順の実行は、次のシーケンシャル手順が実行を開始する前に完了します。ステートブロックの外で実行される手順はありません。異なる状態マシンでの状態ブロックの実行条件が満たされた場合でも、1つの状態ブロックのみの手順は一度に1つずつ実行され、他の状態ブロックの遷移と実行が発生する前に、実行する状態ブロックの完全な実行のすべての手順が満たされています。。つまり、任意の状態ブロックの実行は、他の状態ブロックの実行に関してアトミックであるように見え、実行が開始されたときに前の状態からその状態への遷移条件は真実です。異なる状態マシンでの状態ブロックの実行順序は、移行条件によって制約される場合を除き、未定義です。状態ブロック内の特定の値に設定された変数は、その後の状態ブロックが値を変更する手順を実行するまで、この値を保持します。
On completion of all the procedures within a state, all exit conditions for the state (including all conditions associated with global transitions) are evaluated continuously until one of the conditions is met. The label ELSE denotes a transition that occurs if none of the other conditions for transitions from the state are met (i.e., ELSE evaluates to TRUE if all other possible exit conditions from the state evaluate to FALSE). Where two or more exit conditions with the same level of precedence become TRUE simultaneously, the choice as to which exit condition causes the state transition to take place is arbitrary.
州内のすべての手順が完了すると、状態のすべての出口条件（グローバル遷移に関連するすべての条件を含む）は、条件の1つが満たされるまで継続的に評価されます。ラベルは、州からの移行の他の条件のいずれも満たされない場合に発生する遷移を示します（つまり、州からの他のすべての可能な出口条件が虚偽に評価された場合、そうでなければtrueを評価します）。同じレベルの優先順位を持つ2つ以上の出口条件が同時に真実になる場合、どの出口条件が状態移行を起こすかという選択は任意です。
Where it is necessary to split a state machine description across more than one diagram, a transition between two states that appear on different diagrams is represented by an exit arrow drawn with dashed lines, plus a reference to the diagram that contains the destination state. Similarly, dashed arrows and a dashed state box are used on the destination diagram to show the transition to the destination state. In a state machine that has been split in this way, any global transitions that can cause entry to states defined in one of the diagrams are deemed potential exit conditions for all the states of the state machine, regardless of which diagram the state boxes appear in.
状態マシンの説明を複数の図に分割する必要がある場合、異なる図に表示される2つの状態間の遷移は、破線で描かれた出口矢印と、宛先状態を含む図への参照で表されます。同様に、破線の矢印と破線の状態ボックスが宛先図に使用され、宛先状態への移行が表示されます。この方法で分割された状態マシンでは、図のいずれかで定義された状態への入力を引き起こす可能性のあるグローバルな遷移は、状態マシンのすべての状態の潜在的な出口条件と見なされます。。
Should a conflict exist between the interpretation of a state diagram and either the corresponding global transition tables or the textual description associated with the state machine, the state diagram takes precedence. The interpretation of the special symbols and operators used in the state diagrams is as defined in Section 3.2; these symbols and operators are derived from the notation of the C++ programming language, ISO/IEC 14882. If a boolean variable is described in this clause as being set, it has or is assigned the value TRUE; if it is described as being reset or clear, it has the value FALSE.
状態図の解釈と、対応するグローバル遷移表または状態マシンに関連するテキストの説明の間に競合が存在する場合、状態図が優先されます。状態図で使用されている特別なシンボルと演算子の解釈は、セクション3.2で定義されています。これらのシンボルと演算子は、Cプログラミング言語の表記であるISO/IEC 14882の表記から派生しています。この句でブール変数が設定されていると記載されている場合、値がtrueに割り当てられているか、割り当てられています。リセットまたはクリアであると説明されている場合、値がfalseになります。
In addition to the above notation, there are a couple of clarifications specific to this document. First, all boolean variables are initialized to FALSE before the state machine execution begins. Second, the following notational shorthand is specific to this document:
上記の表記に加えて、このドキュメントに固有のいくつかの説明があります。まず、すべてのブール変数は、状態マシンの実行が開始される前にfalseに初期化されます。第二に、次の表記の速記はこのドキュメントに固有のものです。
<variable> = <expression1> | <expression2> | ...
Execution of a statement of this form will result in <variable> having a value of exactly one of the expressions. The logic for which of those expressions gets executed is outside of the state machine and could be environmental, configurable, or based on another state machine, such as that of the method.
このフォームのステートメントを実行すると、<変数>は式の1つの値を持つことになります。これらの式の実行が実行されるロジックは、状態マシンの外側であり、環境、構成可能、またはメソッドのような別の状態マシンに基づいている可能性があります。
( )
（）
Used to force the precedence of operators in Boolean expressions and to delimit the argument(s) of actions within state boxes.
ブール表現のオペレーターの優先順位を強制し、ステートボックス内のアクションの引数を区切るために使用されます。
;
;
Used as a terminating delimiter for actions within state boxes. If a state box contains multiple actions, the order of execution follows the normal English language conventions for reading text.
ステートボックス内のアクションの終了デリミッターとして使用されます。ステートボックスに複数のアクションが含まれている場合、実行の順序はテキストを読むための通常の英語規則に従います。
=
=
Assignment action. The value of the expression to the right of the operator is assigned to the variable to the left of the operator. If this operator is used to define multiple assignments (e.g., a = b = X), the action causes the value of the expression following the right-most assignment operator to be assigned to all the variables that appear to the left of the right-most assignment operator.
割り当てアクション。オペレーターの右側の式の値は、オペレーターの左側の変数に割り当てられます。この演算子を使用して複数の割り当て（a = b = xなど）を定義する場合、アクションにより、右の割り当てオペレーターに続く式の値が右側の左側の左側に表示されるすべての変数に割り当てられます。ほとんどの割り当て演算子。
!
！
Logical NOT operator.
論理的ではないオペレーター。
&&
&&
Logical AND operator.
論理および演算子。
||
||
Logical OR operator.
論理または演算子。
if...then...
もし...それなら...
Conditional action. If the Boolean expression following the "if" evaluates to TRUE, then the action following the "then" is executed.
条件付きアクション。「if」に続くブール式がtrueに評価される場合、「then」に続くアクションが実行されます。
{ statement 1, ... statement N }
{ステートメント1、...ステートメントn}
Compound statement. Braces are used to group statements that are executed together as if they were a single statement.
複合ステートメント。ブレースは、まるで単一のステートメントであるかのように一緒に実行される声明をグループ化するために使用されます。
!=
！=
Inequality. Evaluates to TRUE if the expression to the left of the operator is not equal in value to the expression to the right.
不平等。演算子の左側の式の式が右側の式と等しい値が等しくない場合、trueに評価します。
==
==
Equality. Evaluates to TRUE if the expression to the left of the operator is equal in value to the expression to the right.
平等。演算子の左側の式の式が右側の式との値に等しい場合、trueに評価します。
>
>
Greater than. Evaluates to TRUE if the value of the expression to the left of the operator is greater than the value of the expression to the right.
より大きい。オペレーターの左側の式の値が右側の式の値よりも大きい場合、trueに評価します。
<=
<=
Less than or equal to. Evaluates to TRUE if the value of the expression to the left of the operator is either less than or equal to the value of the expression to the right.
以下以上。演算子の左側の式の値が右側の式の値以下であるかどうかをtrueに評価します。
++
Increment the preceding integer operator by 1.
前の整数演算子を1で増分します。
+
Arithmetic addition operator.
算術追加演算子。
&
＆
Bitwise AND operator.
ビットワイズとオペレーター。
Should a conflict exist between the interpretation of a state diagram and either the corresponding global transition tables or the textual description associated with the state machine, the state diagram takes precedence. When a discrepancy occurs between any part of this document (text or diagram) and any of the related documents ([RFC3748], [RFC3579], etc.), the latter (the other document) is considered authoritative and takes precedence.
状態図の解釈と、対応するグローバル遷移表または状態マシンに関連するテキストの説明の間に競合が存在する場合、状態図が優先されます。このドキュメントの任意の部分（テキストまたは図）と関連ドキュメント（[RFC3748]、[RFC3579]など）の間で矛盾が発生すると、後者（他のドキュメント）は権威あると見なされ、優先されます。
The following is a diagram of the EAP peer state machine. Also included is an explanation of the primitives and procedures referenced in the diagram, as well as a clarification of notation.
以下は、EAPピアステートマシンの図です。また、図で参照されているプリミティブと手順の説明、および表記の明確化も含まれています。
(see the .pdf version for missing diagram or refer to Appendix A.1 if reading the .txt version)
（不足している図については.pdfバージョンを参照するか、.txtバージョンを読む場合は付録A.1を参照してください）
Figure 3: EAP Peer State Machine
図3：EAPピアステートマシン
The lower layer presents messages to the EAP peer state machine by storing the packet in eapReqData and setting the eapReq signal to TRUE. Note that despite the name of the signal, the lower layer does not actually inspect the contents of the EAP packet (it could be a Success or Failure message instead of a Request).
下層は、パケットをEapreqdataに保存し、EAPREQ信号をTRUEに設定することにより、EAPピアステートマシンにメッセージを提示します。信号の名前にもかかわらず、下層は実際にEAPパケットの内容を検査しないことに注意してください（リクエストの代わりに成功または失敗メッセージになる可能性があります）。
When the EAP peer state machine has finished processing the message, it sets either eapResp or eapNoResp. If it sets eapResp, the corresponding response packet is stored in eapRespData. The lower layer is responsible for actually transmitting this message. When the EAP peer state machine authentication is complete, it will set eapSuccess or eapFailure to indicate to the lower layer that the authentication has succeeded or failed.
EAPピアステートマシンがメッセージの処理を完了した場合、EAPRESPまたはEAPNORESPのいずれかを設定します。eaprespを設定すると、対応する応答パケットはeaprespdataに保存されます。下層は、このメッセージを実際に送信する責任があります。EAPピアステートマシン認証が完了すると、認証が成功または失敗したことを下層層に示すようにEAPSUCCESSまたはEAPFAILUREを設定します。
eapReq (boolean)
eapreq（boolean）
Set to TRUE in lower layer, FALSE in peer state machine. Indicates that a request is available in the lower layer.
下層でTRUEに設定し、ピアステートマシンでFALSEに設定します。下層層でリクエストが利用可能であることを示します。
eapReqData (EAP packet)
eapreqdata（EAPパケット）
Set in lower layer when eapReq is set to TRUE. The contents of the available request.
EAPREQがtrueに設定されている場合、下層に設定します。利用可能なリクエストの内容。
portEnabled (boolean)
porteNabled（boolean）
Indicates that the EAP peer state machine should be ready for communication. This is set to TRUE when the EAP conversation is started by the lower layer. If at any point the communication port or session is not available, portEnabled is set to FALSE, and the state machine transitions to DISABLED. To avoid unnecessary resets, the lower layer may dampen link down indications when it believes that the link is only temporarily down and that it will soon be back up (see [RFC3748], Section 7.12). In this case, portEnabled may not always be equal to the "link up" flag of the lower layer.
EAPピアステートマシンが通信の準備ができている必要があることを示します。これは、EAPの会話が下層によって開始されるときにTRUEに設定されます。いつでも通信ポートまたはセッションが使用できない場合、PorteNabledはFalseに設定され、状態マシンは無効に移行します。不必要なリセットを回避するために、下層は、リンクが一時的にのみダウンしており、すぐにバックアップされると考えている場合、リンクを抑えることができます（[RFC3748]、セクション7.12を参照）。この場合、PortEnabledは常に下層の「リンクアップ」フラグに等しくなるとは限りません。
idleWhile (integer)
アイドルwhile（整数）
Outside timer used to indicate how much time remains before the peer will time out while waiting for a valid request.
外部タイマーは、有効なリクエストを待っている間、ピアがタイムアウトするまでの時間を示すために使用されていました。
eapRestart (boolean)
eaprestart（boolean）
Indicates that the lower layer would like to restart authentication.
下層が認証を再開したいことを示します。
altAccept (boolean)
altaccept（boolean）
Alternate indication of success, as described in [RFC3748].
[RFC3748]に記載されているように、成功の代替兆候。
altReject (boolean)
altreject（boolean）
Alternate indication of failure, as described in [RFC3748].
[RFC3748]に記載されているように、障害の代替兆候。
eapResp (boolean)
eapresp（boolean）
Set to TRUE in peer state machine, FALSE in lower layer. Indicates that a response is to be sent.
ピアステートマシンでTRUEに設定され、下層でFALSE。応答が送信されることを示します。
eapNoResp (boolean)
eapnoresp（boolean）
Set to TRUE in peer state machine, FALSE in lower layer. Indicates that the request has been processed, but that there is no response to send.
ピアステートマシンでTRUEに設定され、下層でFALSE。リクエストが処理されたが、送信に対する応答がないことを示します。
eapSuccess (boolean)
eapsuccess（boolean）
Set to TRUE in peer state machine, FALSE in lower layer. Indicates that the peer has reached the SUCCESS state.
ピアステートマシンでTRUEに設定され、下層でFALSE。ピアが成功状態に到達したことを示します。
eapFail (boolean)
eapfail（boolean）
Set to TRUE in peer state machine, FALSE in lower layer. Indicates that the peer has reached the FAILURE state.
ピアステートマシンでTRUEに設定され、下層でFALSE。ピアが故障状態に到達したことを示します。
eapRespData (EAP packet)
eaprespdata（EAPパケット）
Set in peer state machine when eapResp is set to TRUE. The EAP packet that is the response to send.
EaprespがTrueに設定されているときに、ピアステートマシンに設定します。送信への応答であるEAPパケット。
eapKeyData (EAP key)
eapkeydata（EAPキー）
Set in peer state machine when keying material becomes available. Set during the METHOD state. Note that this document does not define the structure of the type "EAP key". We expect that it will be defined in [Keying].
キーイング素材が利用可能になったら、ピアステートマシンに設定します。メソッド状態中に設定します。このドキュメントは、タイプ「EAPキー」の構造を定義していないことに注意してください。[キーイング]で定義されると予想されます。
eapKeyAvailable (boolean)
eapkeyavailable（boolean）
Set to TRUE in the SUCCESS state if keying material is available. The actual key is stored in eapKeyData.
キーイング素材が利用可能な場合、成功状態でTRUEに設定します。実際のキーはEapkeyDataに保存されます。
ClientTimeout (integer)
ClientTimeOut（整数）
Configurable amount of time to wait for a valid request before aborting, initialized by implementation-specific means (e.g., a configuration setting).
実装固有の手段（たとえば、構成設定）によって初期化された、中止する前に有効なリクエストを待つための構成可能な時間。
IN: eapReqData (includes reqId)
In：eapreqdata（reqidを含む）
OUT: ignore, eapRespData, allowNotifications, decision
Out：無視、eaprespdata、allownotifications、決定
IN/OUT: methodState, (method-specific state)
In/out：MethodState、（メソッド固有の状態）
The following describes the interaction between the state machine and EAP methods.
以下は、状態マシンとEAPメソッド間の相互作用について説明しています。
If methodState==INIT, the method starts by initializing its own method-specific state.
MethodState == initの場合、メソッドは独自のメソッド固有の状態を初期化することから始まります。
Next, the method must decide whether to process the packet or to discard it silently. If the packet appears to have been sent by someone other than the legitimate authenticator (for instance, if message integrity check fails) and the method is capable of treating such situations as non-fatal, the method can set ignore=TRUE. In this case, the method should not modify any other variables.
次に、メソッドは、パケットを処理するか、静かに破棄するかを決定する必要があります。パケットが正当な認証者以外の誰かによって送信されたように見える場合（たとえば、メッセージの整合性チェックが失敗した場合）、メソッドがそのような状況を非致命的なものとして扱うことができる場合、メソッドは無視= trueを設定できます。この場合、メソッドは他の変数を変更してはなりません。
If the method decides to process the packet, it behaves as follows.
メソッドがパケットの処理を決定した場合、次のように動作します。
o It updates its own method-specific state.
o 独自のメソッド固有の状態を更新します。
o If the method has derived keying material it wants to export, it stores the keying material to eapKeyData.
o メソッドがキーイング材料を導き出した場合、エクスポートしたい場合、キーイング素材をEapkeyDataに保存します。
o It creates a response packet (with the same identifier as the request) and stores it to eapRespData.
o 応答パケット（リクエストと同じ識別子を使用）を作成し、eaprespdataに保存します。
o It sets ignore=FALSE.
o それは無視= falseを設定します。
Next, the method must update methodState and decision according to the following rules.
次に、メソッドは、次のルールに従ってMethodStateと決定を更新する必要があります。
methodState=CONT: The method always continues at this point (and the peer wants to continue it). The decision variable is always set to FAIL.
MethodState = cont：メソッドは常にこの時点で継続します（そして、ピアはそれを継続したいと考えています）。決定変数は常に失敗するように設定されています。
methodState=MAY_CONT: At this point, the authenticator can decide either to continue the method or to end the conversation. The decision variable tells us what to do if the conversation ends. If the current situation does not satisfy the peer's security policy (that is, if the authenticator now decides to allow access, the peer will not use it), set decision=FAIL. Otherwise, set decision=COND_SUCC.
MethodState = may_cont：この時点で、認証者はメソッドを継続するか、会話を終了するかを決定できます。決定変数は、会話が終了した場合に何をすべきかを教えてくれます。現在の状況がピアのセキュリティポリシーを満たしていない場合（つまり、認証者がアクセスを許可することを決定した場合、ピアはそれを使用しません）、決定= faileを設定します。それ以外の場合、決定= cond_succを設定します。
methodState=DONE: The method never continues at this point (or the peer sees no point in continuing it).
MethodState = done：この時点でメソッドは継続することはありません（または、ピアはそれを継続することには意味がありません）。
If either (a) the authenticator has informed us that it will not allow access, or (b) we're not willing to talk to this authenticator (e.g., our security policy is not satisfied), set decision=FAIL. (Note that this state can occur even if the method still has additional messages left, if continuing it cannot change the peer's decision to success).
（a）認証者がアクセスを許可しないことを通知した場合、または（b）この認証者と話すつもりはない（たとえば、セキュリティポリシーが満たされない）、決定を設定=失敗に設定します。（メソッドにまだ追加のメッセージが残っている場合でも、この状態が発生する可能性があることに注意してください。継続する場合、ピアの成功への決定を変更できない場合）。
If both (a) the server has informed us that it will allow access, and the next packet will be EAP Success, and (b) we're willing to use this access, set decision=UNCOND_SUCC.
（a）サーバーがアクセスを許可し、次のパケットがEAPの成功になることを通知した場合、（b）このアクセスを喜んで使用することをいとわない、決定= uncond_succを設定します。
Otherwise, we do not know what the server's decision is, but are willing to use the access if the server allows. In this case, set decision=COND_SUCC.
それ以外の場合は、サーバーの決定が何であるかはわかりませんが、サーバーが許可する場合はアクセスを喜んで使用します。この場合、決定= cond_succを設定します。
Finally, the method must set the allowNotifications variable. If the new methodState is either CONT or MAY_CONT, and if the method specification does not forbid the use of Notification messages, set allowNotifications=TRUE. Otherwise, set allowNotifications=FALSE.
最後に、メソッドはAllOwnotifications変数を設定する必要があります。新しいMethodStateがcontまたはmay_contのいずれかであり、メソッド仕様が通知メッセージの使用を禁止していない場合、alownotifications = trueを設定します。それ以外の場合、alowonotifications = falseを設定します。
selectMethod (EAP type)
selectMethod（EAPタイプ）
Set in GET_METHOD state. The method that the peer believes is currently "in progress"
get_method状態に設定します。ピアが現在信じている方法は現在「進行中」です
methodState (enumeration)
MethodState（列挙）
As described above.
上記のように。
lastId (integer)
lastid（整数）
0-255 or NONE. Set in SEND_RESPONSE state. The EAP identifier value of the last request.
0-255またはなし。send_response状態に設定します。最後の要求のEAP識別子値。
lastRespData (EAP packet)
Lastrespdata（EAPパケット）
Set in SEND_RESPONSE state. The EAP packet last sent from the peer.
send_response状態に設定します。EAPパケットは最後にピアから送信されました。
decision (enumeration)
決定（列挙）
As described above.
上記のように。
NOTE: EAP type can be normal type (0..253,255), or an extended type consisting of type 254, Vendor-Id, and Vendor-Type.
注：EAPタイプは、通常のタイプ（0..253,255）、またはタイプ254、ベンダーID、およびベンダータイプで構成される拡張タイプです。
rxReq (boolean)
rxreq（boolean）
Set in RECEIVED state. Indicates that the current received packet is an EAP request.
受信状態に設定されています。現在の受信パケットがEAPリクエストであることを示します。
rxSuccess (boolean)
rxsuccess（boolean）
Set in RECEIVED state. Indicates that the current received packet is an EAP Success.
受信状態に設定されています。現在の受信パケットがEAPの成功であることを示します。
rxFailure (boolean)
rxfailure（boolean）
Set in RECEIVED state. Indicates that the current received packet is an EAP Failure.
受信状態に設定されています。現在の受信パケットがEAP障害であることを示します。
reqId (integer)
reqid（整数）
Set in RECEIVED state. The identifier value associated with the current EAP request.
受信状態に設定されています。現在のEAP要求に関連付けられた識別子値。
reqMethod (EAP type)
reqmethod（EAPタイプ）
Set in RECEIVED state. The method type of the current EAP request.
受信状態に設定されています。現在のEAP要求のメソッドタイプ。
ignore (boolean)
無視（ブール）
Set in METHOD state. Indicates whether the method has decided to drop the current packet.
メソッド状態に設定します。メソッドが現在のパケットを削除することを決定したかどうかを示します。
NOTE: For method procedures, the method uses its internal state in addition to the information provided by the EAP layer. The only arguments that are explicitly shown as inputs to the procedures are those provided to the method by EAP. Those inputs provided by the method's internal state remain implicit.
注：メソッド手順では、メソッドはEAPレイヤーが提供する情報に加えて、内部状態を使用します。手順への入力として明示的に示されている唯一の引数は、EAPによってメソッドに提供されるものです。メソッドの内部状態によって提供されるこれらの入力は暗黙のままです。
parseEapReq()
parseeapreq（）
Determine the code, identifier value, and type of the current request. In the case of a parsing error (e.g., the length field is longer than the received packet), rxReq, rxSuccess, and rxFailure will all be set to FALSE. The values of reqId and reqMethod may be undefined as a result. Returns three booleans, one integer, and one EAP type.
現在の要求のコード、識別子値、およびタイプを決定します。解析エラーの場合（たとえば、長さフィールドは受信したパケットよりも長い）、rxreq、rxSuccess、およびrxfailureはすべてFalseに設定されます。結果として、reqidとreqmethodの値は未定義になる場合があります。3つのブリアン、1つの整数、1つのEAPタイプを返します。
processNotify()
processNotify（）
Process the contents of Notification Request (for instance, display it to the user or log it). The return value is undefined.
通知要求の内容を処理します（たとえば、ユーザーに表示するか、ログに記録します）。返品値は未定義です。
buildNotify()
buildnotify（）
Create the appropriate notification response. Returns an EAP packet.
適切な通知応答を作成します。EAPパケットを返します。
processIdentity()
ProcessIdentity（）
Process the contents of Identity Request. Return value is undefined.
IDリクエストの内容を処理します。返品値は未定義です。
buildIdentity()
buildidentity（）
Create the appropriate identity response. Returns an EAP packet.
適切なID応答を作成します。EAPパケットを返します。
m.check()
M.Check（）
Method-specific procedure to test for the validity of a message. Returns a boolean.
メッセージの有効性をテストする方法固有の手順。ブールを返します。
m.process()
M.Process（）
Method procedure to parse and process a request for that method. Returns a methodState enumeration, a decision enumeration, and a boolean.
その方法のリクエストを解析して処理する方法手順。MethodStateの列挙、決定の列挙、およびブール値を返します。
m.buildResp()
m.buildresp（）
Method procedure to create a response message. Returns an EAP packet.
応答メッセージを作成する方法手順。EAPパケットを返します。
m.getKey()
M.GetKey（）
Method procedure to obtain key material for use by EAP or lower layers. Returns an EAP key.
EAPまたは下層層で使用するための重要な材料を取得するための方法手順。EAPキーを返します。
DISABLED
無効
This state is reached whenever service from the lower layer is interrupted or unavailable. Immediate transition to INITIALIZE occurs when the port becomes enabled.
この状態は、下層からのサービスが中断または利用できない場合はいつでも到達します。ポートが有効になったときに、初期化するための即時移行が発生します。
INITIALIZE
初期化
Initializes variables when the state machine is activated.
状態マシンがアクティブになったときに変数を初期化します。
IDLE
アイドル
The state machine spends most of its time here, waiting for something to happen.
州のマシンはここでほとんどの時間を費やし、何かが起こるのを待っています。
RECEIVED
受け取った
This state is entered when an EAP packet is received. The packet header is parsed here.
この状態は、EAPパケットを受信したときに入力されます。パケットヘッダーはここで解析されます。
GET_METHOD
get_method
This state is entered when a request for a new type comes in. Either the correct method is started, or a Nak response is built.
この状態は、新しいタイプのリクエストが入ったときに入力されます。正しい方法が開始されるか、NAK応答が構築されます。
METHOD
方法
The method processing happens here. The request from the authenticator is processed, and an appropriate response packet is built.
メソッド処理はここで行われます。Authenticatorからのリクエストが処理され、適切な応答パケットが構築されます。
SEND_RESPONSE
send_response
This state signals the lower layer that a response packet is ready to be sent.
この状態は、応答パケットを送信する準備ができていることを示す下層を示しています。
DISCARD
破棄
This state signals the lower layer that the request was discarded, and no response packet will be sent at this time.
この状態は、リクエストが廃棄された下層層を通知し、現時点では応答パケットは送信されません。
IDENTITY
身元
Handles requests for Identity method and builds a response.
IDメソッドのリクエストを処理し、応答を構築します。
NOTIFICATION
通知
Handles requests for Notification method and builds a response.
通知方法のリクエストを処理し、応答を構築します。
RETRANSMIT
再送信
Retransmits the previous response packet.
以前の応答パケットを再送信します。
SUCCESS
成功
A final state indicating success.
成功を示す最終状態。
FAILURE
失敗
A final state indicating failure.
障害を示す最終状態。
The following is a diagram of the stand-alone EAP authenticator state machine. This diagram should be used for those interested in a self-contained, or non-pass-through, authenticator. Included is an explanation of the primitives and procedures referenced in the diagram, as well as a clarification of notation.
以下は、スタンドアロンのEAP認証状態マシンの図です。この図は、自己完結型の、またはパススルー以外の認証者に興味がある人には使用する必要があります。図で参照されているプリミティブと手順の説明、および表記法の説明が含まれています。
(see the .pdf version for missing diagram or refer to Appendix A.2 if reading the .txt version)
（不足している図については.pdfバージョンを参照するか、.txtバージョンを読む場合は付録A.2を参照してください）
Figure 4: EAP Stand-Alone Authenticator State Machine
図4：EAP Stand-Alone Authenticator State Machine
The lower layer presents messages to the EAP authenticator state machine by storing the packet in eapRespData and setting the eapResp signal to TRUE.
下層層は、EAPRespDataにパケットを保存し、EAPRESP信号をTRUEに設定することにより、EAP Authenticator Stateマシンにメッセージを提示します。
When the EAP authenticator state machine has finished processing the message, it sets one of the signals eapReq, eapNoReq, eapSuccess, and eapFail. If it sets eapReq, eapSuccess, or eapFail, the corresponding request (or success/failure) packet is stored in eapReqData. The lower layer is responsible for actually transmitting this message.
EAP Authenticator Stateマシンがメッセージの処理を完了した場合、EAPREQ、EAPNOREQ、EAPSUCCESS、およびEAPFAILの1つを設定します。EAPREQ、EAPSUCCESS、またはEAPFAILを設定すると、対応するリクエスト（または成功/失敗）パケットがEAPREQDATAに保存されます。下層は、このメッセージを実際に送信する責任があります。
eapResp (boolean)
eapresp（boolean）
Set to TRUE in lower layer, FALSE in authenticator state machine. Indicates that an EAP response is available for processing.
下層でTrueに設定し、Authenticator State MachineでFalse。EAP応答が処理に利用可能であることを示します。
eapRespData (EAP packet)
eaprespdata（EAPパケット）
Set in lower layer when eapResp is set to TRUE. The EAP packet to be processed.
EaprespがTrueに設定されている場合、下層に設定します。処理されるEAPパケット。
portEnabled (boolean)
porteNabled（boolean）
Indicates that the EAP authenticator state machine should be ready for communication. This is set to TRUE when the EAP conversation is started by the lower layer. If at any point the communication port or session is not available, portEnabled is set to FALSE, and the state machine transitions to DISABLED. To avoid unnecessary resets, the lower layer may dampen link down indications when it believes that the link is only temporarily down and that it will soon be back up (see [RFC3748], Section 7.12). In this case, portEnabled may not always be equal to the "link up" flag of the lower layer.
EAP Authenticator Stateマシンが通信の準備ができている必要があることを示します。これは、EAPの会話が下層によって開始されるときにTRUEに設定されます。いつでも通信ポートまたはセッションが使用できない場合、PorteNabledはFalseに設定され、状態マシンは無効に移行します。不必要なリセットを回避するために、下層は、リンクが一時的にのみダウンしており、すぐにバックアップされると考えている場合、リンクを抑えることができます（[RFC3748]、セクション7.12を参照）。この場合、PortEnabledは常に下層の「リンクアップ」フラグに等しくなるとは限りません。
retransWhile (integer)
レトランズ（整数）
Outside timer used to indicate how long the authenticator has waited for a new (valid) response.
外部タイマーは、認証者が新しい（有効な）応答を待っている期間を示すために使用されます。
eapRestart (boolean)
eaprestart（boolean）
Indicates that the lower layer would like to restart authentication.
下層が認証を再開したいことを示します。
eapSRTT (integer)
eapsrtt（整数）
Smoothed round-trip time. (See [RFC3748], Section 4.3.)
滑らかな往復時間。（[RFC3748]、セクション4.3を参照してください。）
eapRTTVAR (integer)
eaprttvar（整数）
Round-trip time variation. (See [RFC3748], Section 4.3.)
往復タイムバリエーション。（[RFC3748]、セクション4.3を参照してください。）
eapReq (boolean)
eapreq（boolean）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that a new EAP request is ready to be sent.
Authenticator State MachineでTrueに設定され、下層でFalse。新しいEAPリクエストが送信される準備ができていることを示します。
eapNoReq (boolean)
eapnoreq（boolean）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates the most recent response has been processed, but there is no new request to send.
Authenticator State MachineでTrueに設定され、下層でFalse。最新の応答が処理されたことを示しますが、送信する新しいリクエストはありません。
eapSuccess (boolean)
eapsuccess（boolean）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the SUCCESS state.
Authenticator State MachineでTrueに設定され、下層でFalse。州のマシンが成功状態に到達したことを示します。
eapFail (boolean)
eapfail（boolean）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the FAILURE state.
Authenticator State MachineでTrueに設定され、下層でFalse。状態マシンが故障状態に到達したことを示します。
eapTimeout (boolean)
eaptimeout（boolean）
Set to TRUE in the TIMEOUT_FAILURE state if the authenticator has reached its maximum number of retransmissions without receiving a response.
Authenticatorが応答を受信せずに最大再送信に達した場合、Timeout_Failure状態でTRUEに設定します。
eapReqData (EAP packet)
eapreqdata（EAPパケット）
Set in authenticator state machine when eapReq, eapSuccess, or eapFail is set to TRUE. The actual EAP request to be sent (or success/failure).
EAPREQ、EAPSUCCESS、またはEAPFAILがTrueに設定されている場合、Authenticator Stateマシンに設定されます。送信される実際のEAP要求（または成功/失敗）。
eapKeyData (EAP key)
eapkeydata（EAPキー）
Set in authenticator state machine when keying material becomes available. Set during the METHOD state. Note that this document does not define the structure of the type "EAP key". We expect that it will be defined in [Keying].
キーイング素材が利用可能になったら、認証状態のマシンに設定します。メソッド状態中に設定します。このドキュメントは、タイプ「EAPキー」の構造を定義していないことに注意してください。[キーイング]で定義されると予想されます。
eapKeyAvailable (boolean)
eapkeyavailable（boolean）
Set to TRUE in the SUCCESS state if keying material is available. The actual key is stored in eapKeyData.
キーイング素材が利用可能な場合、成功状態でTRUEに設定します。実際のキーはEapkeyDataに保存されます。
MaxRetrans (integer)
Maxretrans（整数）
Configurable maximum for how many retransmissions should be attempted before aborting.
中止する前に、いくつの再送信を試みる必要があるかについて、構成可能な最大値。
IN: eapRespData, methodState
In：eaprespdata、MethodState
OUT: ignore, eapReqData
OUT：無視、eapreqdata
IN/OUT: currentId, (method-specific state), (policy)
in/out：currentId、（メソッド固有の状態）、（ポリシー）
The following describes the interaction between the state machine and EAP methods.
以下は、状態マシンとEAPメソッド間の相互作用について説明しています。
m.init (in: -, out: -) When the method is first started, it must initialize its own method-specific state, possibly using some information from Policy (e.g., identity).
M.Init（in： - 、out： - ）メソッドが最初に開始されると、ポリシー（例：ID）からの情報を使用して、独自のメソッド固有の状態を初期化する必要があります。
m.buildReq (in: integer, out: EAP packet)
M.Buildreq（in：integer、out：eapパケット）
Next, the method creates a new EAP Request packet, with the given identifier value, and updates its method-specific state accordingly.
次に、このメソッドは、指定された識別子値を備えた新しいEAP要求パケットを作成し、それに応じてメソッド固有の状態を更新します。
m.getTimeout (in: -, out: integer or NONE)
The method can also provide a hint for retransmission timeout with m.getTimeout.
この方法は、M.GetTimeOutで再送信タイムアウトのヒントを提供することもできます。
m.check (in: EAP packet, out: boolean)
M.Check（in：EAPパケット、out：boolean）
When a new EAP Response is received, the method must first decide whether to process the packet or to discard it silently. If the packet looks like it was not sent by the legitimate peer (e.g., if it has an invalid Message Integrity Check (MIC), which should never occur), the method can indicate this by returning FALSE. In this case, the method should not modify its own method-specific state.
新しいEAP応答を受信した場合、方法はまずパケットを処理するか、静かに破棄するかを決定する必要があります。パケットが正当なピアによって送信されていないように見える場合（たとえば、無効なメッセージ整合性チェック（MIC）、決して発生しないでください）、メソッドはfalseを返すことでこれを示すことができます。この場合、メソッドは独自のメソッド固有の状態を変更してはなりません。
m.process (in: EAP packet, out: -)
m.isDone (in: -, out: boolean)
m.getKey (in: -, out: EAP key or NONE)
Next, the method processes the EAP Response and updates its own method-specific state. Now the options are to continue the conversation (send another request) or to end this method.
次に、メソッドはEAP応答を処理し、独自のメソッド固有の状態を更新します。これで、オプションは会話を続行し（別のリクエストを送信）、この方法を終了することです。
If the method wants to end the conversation, it
方法が会話を終了したい場合、
o Tells Policy about the outcome of the method and possibly other information.
o メソッドの結果、および場合によっては他の情報についてのポリシーを伝えます。
o If the method has derived keying material it wants to export, returns it from m.getKey().
o メソッドがエクスポートしたいキーイング素材を導き出した場合、M.GetKey（）から返します。
o Indicates that the method wants to end by returning TRUE from m.isDone().
o m.isdone（）からtrueを返すことでメソッドが終了したいことを示します。
Otherwise, the method continues by sending another request, as described earlier.
それ以外の場合、前述のように、この方法は別の要求を送信することで継続します。
currentMethod (EAP type)
CurrentMethod（EAPタイプ）
EAP type, IDENTITY, or NOTIFICATION.
EAPタイプ、ID、または通知。
currentId (integer)
CurrentID（整数）
0-255 or NONE. Usually updated in PROPOSE_METHOD state. Indicates the identifier value of the currently outstanding EAP request.
0-255またはなし。通常、propose_method状態で更新されます。現在未解決のEAP要求の識別子値を示します。
methodState (enumeration)
MethodState（列挙）
As described above.
上記のように。
retransCount (integer)
Recranscount（整数）
Reset in SEND_REQUEST state and updated in RETRANSMIT state. Current number of retransmissions.
send_request状態でリセットされ、再送信状態で更新されます。現在の再送信数。
lastReqData (EAP packet)
lastreqdata（EAPパケット）
Set in SEND_REQUEST state. EAP packet containing the last sent request.
send_request状態に設定します。最後の送信要求を含むEAPパケット。
methodTimeout (integer)
MethodTimeout（整数）
Method-provided hint for suitable retransmission timeout, or NONE.
適切な再送信タイムアウトのための方法が提供するヒント、またはなし。
rxResp (boolean)
rxResp（ブール）
Set in RECEIVED state. Indicates that the current received packet is an EAP response.
受信状態に設定されています。現在の受信パケットがEAP応答であることを示します。
respId (integer)
repid（整数）
Set in RECEIVED state. The identifier from the current EAP response.
受信状態に設定されています。現在のEAP応答からの識別子。
respMethod (EAP type)
Respmethod（EAPタイプ）
Set in RECEIVED state. The method type of the current EAP response.
受信状態に設定されています。現在のEAP応答のメソッドタイプ。
ignore (boolean)
無視（ブール）
Set in METHOD state. Indicates whether the method has decided to drop the current packet.
メソッド状態に設定します。メソッドが現在のパケットを削除することを決定したかどうかを示します。
decision (enumeration)
決定（列挙）
Set in SELECT_ACTION state. Temporarily stores the policy decision to succeed, fail, or continue.
select_action状態で設定します。成功、失敗、または継続するために、ポリシーの決定を一時的に保存します。
NOTE: For method procedures, the method uses its internal state in addition to the information provided by the EAP layer. The only arguments that are explicitly shown as inputs to the procedures are those provided to the method by EAP. Those inputs provided by the method's internal state remain implicit.
注：メソッド手順では、メソッドはEAPレイヤーが提供する情報に加えて、内部状態を使用します。手順への入力として明示的に示されている唯一の引数は、EAPによってメソッドに提供されるものです。メソッドの内部状態によって提供されるこれらの入力は暗黙のままです。
calculateTimeout()
calculateTimeout（）
Calculates the retransmission timeout, taking into account the retransmission count, round-trip time measurements, and method-specific timeout hint (see [RFC3748], Section 4.3). Returns an integer.
再送信カウント、往復時間測定、およびメソッド固有のタイムアウトヒントを考慮して、再送信タイムアウトを計算します（[RFC3748]、セクション4.3を参照）。整数を返します。
parseEapResp()
parseeapresp（）
Determines the code, identifier value, and type of the current response. In the case of a parsing error (e.g., the length field is longer than the received packet), rxResp will be set to FALSE. The values of respId and respMethod may be undefined as a result. Returns a boolean, an integer, and an EAP type.
現在の応答のコード、識別子値、およびタイプを決定します。解析エラーの場合（たとえば、長さフィールドは受信したパケットよりも長くなります）、rxRespはfalseに設定されます。結果として、RespidとRespmethodの値は未定義になる場合があります。ブール、整数、およびEAPタイプを返します。
buildSuccess()
buildsuccess（）
Creates an EAP Success Packet. Returns an EAP packet.
EAP成功パケットを作成します。EAPパケットを返します。
buildFailure()
buildfailure（）
Creates an EAP Failure Packet. Returns an EAP packet.
EAP障害パケットを作成します。EAPパケットを返します。
nextId()
nextid（）
Determines the next identifier value to use, based on the previous one. Returns an integer.
前のものに基づいて、使用する次の識別子値を決定します。整数を返します。
Policy.update()
policy.update（）
Updates all variables related to internal policy state. The return value is undefined.
内部ポリシー状態に関連するすべての変数を更新します。返品値は未定義です。
Policy.getNextMethod()
policy.getNextMethod（）
Determines the method that should be used at this point in the conversation based on predefined policy. Policy.getNextMethod() MUST comply with [RFC3748] (Section 2.1), which forbids the use of sequences of authentication methods within an EAP conversation. Thus, if an authentication method has already been executed within an EAP dialog, Policy.getNextMethod() MUST NOT propose another authentication method within the same EAP dialog. Returns an EAP type.
事前定義されたポリシーに基づいて、会話のこの時点で使用する必要がある方法を決定します。policy.getNextMethod（）は[RFC3748]（セクション2.1）に準拠する必要があります。したがって、EAPダイアログ内で認証方法が既に実行されている場合、policy.getNextMethod（）は、同じEAPダイアログ内で別の認証方法を提案してはなりません。EAPタイプを返します。
Policy.getDecision()
policy.getDecision（）
Determines if the policy will allow SUCCESS, FAIL, or is yet to determine (CONTINUE). Returns a decision enumeration.
ポリシーが成功を許可するか、失敗するか、まだ決定していないかどうかを判断します（継続）。決定の列挙を返します。
m.check()
M.Check（）
Method-specific procedure to test for the validity of a message. Returns a boolean.
メッセージの有効性をテストする方法固有の手順。ブールを返します。
m.process()
M.Process（）
Method procedure to parse and process a response for that method. The return value is undefined.
その方法の応答を解析して処理する方法手順。返品値は未定義です。
m.init()
M.Init（）
Method procedure to initialize state just before use. The return value is undefined.
使用直前に状態を初期化する方法手順。返品値は未定義です。
m.reset()
m.reset（）
Method procedure to indicate that the method is ending in the middle of or before completion. The return value is undefined.
メソッド手順は、メソッドが完了前または完了前に終了していることを示すための手順。返品値は未定義です。
m.isDone()
m.isdone（）
Method procedure to check for method completion. Returns a boolean.
メソッド手順メソッド完了を確認するため。ブールを返します。
m.getTimeout()
m.getTimeout（）
Method procedure to determine an appropriate timeout hint for that method. Returns an integer.
メソッド手順そのメソッドの適切なタイムアウトヒントを決定するための手順。整数を返します。
m.getKey()
M.GetKey（）
Method procedure to obtain key material for use by EAP or lower layers. Returns an EAP key.
EAPまたは下層層で使用するための重要な材料を取得するための方法手順。EAPキーを返します。
m.buildReq()
m.buildreq（）
Method procedure to produce the next request. Returns an EAP packet.
次のリクエストを作成する方法手順。EAPパケットを返します。
DISABLED
無効
The authenticator is disabled until the port is enabled by the lower layer.
認証機は、下層層によってポートが有効になるまで無効になります。
INITIALIZE
初期化
Initializes variables when the state machine is activated.
状態マシンがアクティブになったときに変数を初期化します。
IDLE
アイドル
The state machine spends most of its time here, waiting for something to happen.
州のマシンはここでほとんどの時間を費やし、何かが起こるのを待っています。
RECEIVED
受け取った
This state is entered when an EAP packet is received. The packet header is parsed here.
この状態は、EAPパケットを受信したときに入力されます。パケットヘッダーはここで解析されます。
INTEGRITY_CHECK
Integrity_Check
A method state in which the integrity of the incoming packet from the peer is verified by the method.
ピアからの着信パケットの完全性がメソッドによって検証される方法状態。
METHOD_RESPONSE
Method_Response
A method state in which the incoming packet is processed.
着信パケットが処理されるメソッド状態。
METHOD_REQUEST
method_request
A method state in which a new request is formulated if necessary.
必要に応じて新しいリクエストが策定されるメソッド状態。
PROPOSE_METHOD
propose_method
A state in which the authenticator decides which method to try next in the authentication.
認証者が認証で次に試す方法を決定する状態。
SELECT_ACTION
select_action
Between methods, the state machine re-evaluates whether its policy is satisfied and succeeds, fails, or remains undecided.
方法の間で、状態マシンは、そのポリシーが満たされ、成功し、失敗し、未定のままであるかどうかを再評価します。
SEND_REQUEST
send_request
This state signals the lower layer that a request packet is ready to be sent.
この状態は、リクエストパケットを送信する準備ができていることを示す下層を示しています。
DISCARD
破棄
This state signals the lower layer that the response was discarded, and no new request packet will be sent at this time.
この状態は、応答が破棄された下層層を示しており、現時点では新しいリクエストパケットは送信されません。
NAK
ナック
This state processes Nak responses from the peer.
この状態は、ピアからのNAK応答を処理します。
RETRANSMIT
再送信
Retransmits the previous request packet.
前のリクエストパケットを再送信します。
SUCCESS
成功
A final state indicating success.
成功を示す最終状態。
FAILURE
失敗
A final state indicating failure.
障害を示す最終状態。
TIMEOUT_FAILURE
timeout_failure
A final state indicating failure because no response has been received. Because no response was received, no new message (including failure) should be sent to the peer. Note that this is different from the FAILURE state, in which a message indicating failure is sent to the peer.
応答が受け取られていないため、障害を示す最終状態。応答がないため、新しいメッセージ（失敗を含む）をピアに送信する必要はありません。これは、故障状態とは異なることに注意してください。この状態では、障害を示すメッセージがピアに送信されます。
When operating in pass-through mode, there are conceptually two parts to the authenticator: the part that passes packets through, and the backend that actually implements the EAP method. The following diagram shows a state machine for the backend part of this model when using a AAA server. Note that this diagram is identical to Figure 4 except that no retransmit is included in the IDLE state because with RADIUS, retransmit is handled by the NAS. Also, a PICK_UP_METHOD state and variable in INITIALIZE state are added to allow the Method to "pick up" a method started in a NAS. Included is an explanation of the primitives and procedures referenced in the diagram, many of which are the same as above. Note that the "lower layer" in this case is some AAA protocol (e.g., RADIUS).
パススルーモードで動作する場合、認証機には概念的に2つの部分があります。パケットを通過する部分と、実際にEAPメソッドを実装するバックエンドです。次の図は、AAAサーバーを使用する際のこのモデルのバックエンド部分の状態マシンを示しています。この図は図4と同一であることに注意してください。ただし、Radiusでは再送信がNASによって処理されるため、再送信がアイドル状態に含まれていないことを除きます。また、初期化状態のpick_up_method状態と変数が追加され、メソッドがNASで開始されたメソッドを「ピックアップ」することができます。図で参照されているプリミティブと手順の説明が含まれています。その多くは上記と同じです。この場合の「下層」は、一部のAAAプロトコル（半径など）であることに注意してください。
(see the .pdf version for missing diagram or refer to Appendix A.3 if reading the .txt version)
（不足している図については.pdfバージョンを参照するか、.txtバージョンを読む場合は付録A.3を参照してください）
Figure 5: EAP Backend Authenticator State Machine
図5：EAPバックエンドAuthenticator State Machine
The lower layer presents messages to the EAP backend authenticator state machine by storing the packet in aaaEapRespData and setting the aaaEapResp signal to TRUE.
下層層は、パケットをAAAEAEAPRESPDATAに保存し、AAAEAPRESP信号をTRUEに設定することにより、EAPバックエンドAuthenticator Stateマシンにメッセージを提示します。
When the EAP backend authenticator state machine has finished processing the message, it sets one of the signals aaaEapReq, aaaEapNoReq, aaaSuccess, and aaaFail. If it sets eapReq, eapSuccess, or eapFail, the corresponding request (or success/failure) packet is stored in aaaEapReqData. The lower layer is responsible for actually transmitting this message.
EAP Backend Authenticator Stateマシンがメッセージの処理が完了した場合、AAAEAPREQ、AAAEAPNOREQ、AAASUCCESS、およびAAAFAILの1つを設定します。EAPREQ、EAPSUCCESS、またはEAPFAILを設定すると、対応するリクエスト（または成功/失敗）パケットがAAAEAPREQDATAに保存されます。下層は、このメッセージを実際に送信する責任があります。
aaaEapResp (boolean)
aaaeapresp（boolean）
Set to TRUE in lower layer, FALSE in authenticator state machine. Usually indicates that an EAP response, stored in aaaEapRespData, is available for processing by the AAA server. If aaaEapRespData is set to NONE, it indicates that the AAA server should send the initial EAP request.
下層でTrueに設定し、Authenticator State MachineでFalse。通常、AAAEAEAPRESPDATAに保存されているEAP応答がAAAサーバーで処理できることを示します。AAAEAEAPRESPDATAがNOに設定されている場合、AAAサーバーが最初のEAPリクエストを送信する必要があることを示します。
aaaEapRespData (EAP packet)
aaaeaeaprespdata（EAPパケット）
Set in lower layer when eapResp is set to TRUE. The EAP packet to be processed, or NONE.
EaprespがTrueに設定されている場合、下層に設定します。処理されるEAPパケット、またはなし。
backendEnabled (boolean)
BackEndenabled（boolean）
Indicates that there is a valid link to use for the communication. If at any point the port is not available, backendEnabled is set to FALSE, and the state machine transitions to DISABLED.
通信に使用する有効なリンクがあることを示します。いつでもポートが使用できない場合、BackEndenabledはFalseに設定され、状態マシンは無効になります。
aaaEapReq (boolean)
aaaeapreq（boolean）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that a new EAP request is ready to be sent.
Authenticator State MachineでTrueに設定され、下層でFalse。新しいEAPリクエストが送信される準備ができていることを示します。
aaaEapNoReq (boolean)
aaaeapnoreq（boolean）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the most recent response has been processed, but there is no new request to send.
Authenticator State MachineでTrueに設定され、下層でFalse。最新の応答が処理されたことを示しますが、送信する新しいリクエストはありません。
aaaSuccess (boolean)
aaasuccess（boolean）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the SUCCESS state.
Authenticator State MachineでTrueに設定され、下層でFalse。州のマシンが成功状態に到達したことを示します。
aaaFail (boolean)
aaafail（boolean）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the FAILURE state.
Authenticator State MachineでTrueに設定され、下層でFalse。状態マシンが故障状態に到達したことを示します。
aaaEapReqData (EAP packet)
aaaeapreqdata（EAPパケット）
Set in authenticator state machine when aaaEapReq, aaaSuccess, or aaaFail is set to TRUE. The actual EAP request to be sent (or success/failure).
AAAEAPREQ、AAASUCCESS、またはAAAFAILがTrueに設定されている場合、Authenticator State Machineに設定されます。送信される実際のEAP要求（または成功/失敗）。
aaaEapKeyData (EAP key)
aaaeapkeydata（EAPキー）
Set in authenticator state machine when keying material becomes available. Set during the METHOD_RESPONSE state. Note that this document does not define the structure of the type "EAP key". We expect that it will be defined in [Keying].
キーイング素材が利用可能になったら、認証状態のマシンに設定します。method_response状態中に設定します。このドキュメントは、タイプ「EAPキー」の構造を定義していないことに注意してください。[キーイング]で定義されると予想されます。
aaaEapKeyAvailable (boolean)
aaaeapkeyavailable（boolean）
Set to TRUE in the SUCCESS state if keying material is available. The actual key is stored in aaaEapKeyData.
キーイング素材が利用可能な場合、成功状態でTRUEに設定します。実際のキーはAAAEAPKEYDATAに保存されます。
aaaMethodTimeout (integer)
aaamethodtimeout（整数）
Method-provided hint for suitable retransmission timeout, or NONE. (Note that this hint is for the EAP retransmissions done by the pass-through authenticator, not for retransmissions of AAA packets.)
適切な再送信タイムアウトのための方法が提供するヒント、またはなし。（このヒントは、AAAパケットの再送信ではなく、パススルー認証機によって行われたEAP再送信のためのものであることに注意してください。）
The backend method interface is almost the same as in stand-alone authenticator described in Section 5.2. The only difference is that some methods on the backend may support "picking up" a conversation started by the pass-through. That is, the EAP Request packet was sent by the pass-through, but the backend must process the corresponding EAP Response. Usually only the Identity method supports this, but others are possible.
バックエンドメソッドインターフェイスは、セクション5.2で説明されているスタンドアロン認証器とほぼ同じです。唯一の違いは、バックエンドのいくつかのメソッドがパススルーによって開始された会話を「ピックアップ」することをサポートする可能性があることです。つまり、EAPリクエストパケットはパススルーによって送信されましたが、バックエンドは対応するEAP応答を処理する必要があります。通常、IDメソッドのみがこれをサポートしますが、他のものは可能です。
When "picking up" a conversation, m.initPickUp() is called instead of m.init(). Next, m.process() must examine eapRespData and update its own method-specific state to match what it would have been if it had actually sent the corresponding request. (Obviously, this only works for methods that can determine what the initial request contained; Identity and EAP-TLS are good examples.)
会話を「拾う」とき、m.initpickup（）はm.init（）の代わりに呼び出されます。次に、M.Process（）はEAPRESPDATAを調べ、実際に対応するリクエストを実際に送信した場合に何があったかに一致するように、独自のメソッド固有の状態を更新する必要があります。（明らかに、これは最初の要求に含まれるものを決定できる方法でのみ機能します。アイデンティティとEAP-TLは良い例です。）
After this, the processing continues as described in Section 5.2.
この後、セクション5.2で説明されているように処理は継続されます。
For definitions of the variables used in the Backend Authenticator, see Section 5.3.
バックエンド認証器で使用される変数の定義については、セクション5.3を参照してください。
Most of the procedures of the backend authenticator have already been defined in Section 5.4. This section contains definitions for those not existent in the stand-alone version, as well as those that are defined differently.
バックエンド認証器の手順のほとんどは、すでにセクション5.4で定義されています。このセクションには、スタンドアロンバージョンに存在しない人の定義と、異なる方法で定義されている定義が含まれています。
NOTE: For method procedures, the method uses its internal state in addition to the information provided by the EAP layer. The only arguments that are explicitly shown as inputs to the procedures are those provided to the method by EAP. Those inputs provided by the method's internal state remain implicit.
注：メソッド手順では、メソッドはEAPレイヤーが提供する情報に加えて、内部状態を使用します。手順への入力として明示的に示されている唯一の引数は、EAPによってメソッドに提供されるものです。メソッドの内部状態によって提供されるこれらの入力は暗黙のままです。
Policy.doPickUp()
policy.dopickup（）
Notifies the policy that an already-chosen method is being picked up and will be completed. Returns a boolean.
既に選択された方法が取り上げられており、完了するというポリシーに通知します。ブールを返します。
m.initPickUp()
M.InitPickup（）
Method procedure to initialize state when continuing from an already-started method. The return value is undefined.
メソッド手順既に開始された方法から継続するときに状態を初期化するための手順。返品値は未定義です。
Most of the states of the backend authenticator have already been defined in Section 5.5. This section contains definitions for those not existent in the stand-alone version, as well as those that are defined differently.
バックエンド認証器のほとんどの状態は、すでにセクション5.5で定義されています。このセクションには、スタンドアロンバージョンに存在しない人の定義と、異なる方法で定義されている定義が含まれています。
PICK_UP_METHOD
pick_up_method
Sets an initial state for a method that is being continued and that was started elsewhere.
継続されている方法の初期状態を設定し、他の場所で開始されました。
The following two diagrams show the state machine for a complete authenticator. The first diagram is identical to the stand-alone state machine, shown in Figure 4, with the exception that the SELECT_ACTION state has an added transition to PASSTHROUGH. The second diagram also keeps most of the logic, except the four method states, and it shows how the state machine works once it goes to pass-through mode.
次の2つの図は、完全な認証器用の状態マシンを示しています。最初の図は、select_action状態がパススルーに追加された遷移があることを除いて、図4に示すスタンドアロン状態マシンと同一です。2番目の図は、4つのメソッドの状態を除き、ほとんどのロジックを保持し、パススルーモードになった後の状態マシンの動作を示しています。
The first diagram is largely a reproduction of that found above, with the added hooks for a transition to PASSTHROUGH mode.
最初の図は、主に上記のものの複製であり、パススルーモードへの移行のためにフックが追加されています。
(see the .pdf version for missing diagram or refer to Appendix A.4 if reading the .txt version)
（不足している図については.pdfバージョンを参照するか、.txtバージョンを読む場合は付録A.4を参照してください）
Figure 6: EAP Full Authenticator State Machine (Part 1)
図6：EAPフル認証状態の状態マシン（パート1）
The second diagram describes the functionality necessary for an authenticator operating in pass-through mode. This section of the diagram is the counterpart of the backend diagram above.
2番目の図は、パススルーモードで動作する認証器に必要な機能を説明しています。図のこのセクションは、上記のバックエンド図の対応物です。
(see the .pdf version for missing diagram or refer to Appendix A.4 if reading the .txt version)
（不足している図については.pdfバージョンを参照するか、.txtバージョンを読む場合は付録A.4を参照してください）
Figure 7: EAP Full Authenticator State Machine (Part 2)
図7：EAPフル認証状態の状態マシン（パート2）
The full authenticator is unique in that it interfaces to multiple lower layers in order to support pass-through mode. The interface to the primary EAP transport layer is the same as described in Section 5. The following describes the interface to the second lower layer, which represents an interface to AAA. Note that there is not necessarily a direct interaction between the EAP layer and the AAA layer, as in the case of [1X-2004].
完全な認証機は、パススルーモードをサポートするために複数の下層層にインターフェイスするという点でユニークです。プライマリEAP輸送層へのインターフェイスは、セクション5で説明されているのと同じです。以下は、AAAへのインターフェイスを表す2番目の下層層へのインターフェイスを説明しています。[1x-2004]の場合のように、EAP層とAAA層の間に必ずしも直接的な相互作用があるわけではないことに注意してください。
aaaEapReq (boolean)
aaaeapreq（boolean）
Set to TRUE in lower layer, FALSE in authenticator state machine. Indicates that a new EAP request is available from the AAA server.
下層でTrueに設定し、Authenticator State MachineでFalse。AAAサーバーから新しいEAPリクエストが利用可能であることを示します。
aaaEapNoReq (boolean)
aaaeapnoreq（boolean）
Set to TRUE in lower layer, FALSE in authenticator state machine. Indicates that the most recent response has been processed, but that there is no new request to send.
下層でTrueに設定し、Authenticator State MachineでFalse。最新の応答が処理されているが、送信する新しいリクエストがないことを示します。
aaaSuccess (boolean)
aaasuccess（boolean）
Set to TRUE in lower layer. Indicates that the AAA backend authenticator has reached the SUCCESS state.
下層でtrueに設定します。AAA Backend Authenticatorが成功状態に到達したことを示します。
aaaFail (boolean)
aaafail（boolean）
Set to TRUE in lower layer. Indicates that the AAA backend authenticator has reached the FAILURE state.
下層でtrueに設定します。AAA Backend Authenticatorが障害状態に到達したことを示します。
aaaEapReqData (EAP packet)
aaaeapreqdata（EAPパケット）
Set in the lower layer when aaaEapReq, aaaSuccess, or aaaFail is set to TRUE. The actual EAP request to be sent (or success/ failure).
AAAEAPREQ、AAASUCCESS、またはAAAFAILがTRUEに設定されているときに下層に設定されます。送信される実際のEAP要求（または成功/失敗）。
aaaEapKeyData (EAP key)
aaaeapkeydata（EAPキー）
Set in lower layer when keying material becomes available from the AAA server. Note that this document does not define the structure of the type "EAP key". We expect that it will be defined in [Keying].
キーイング素材がAAAサーバーから使用可能になったときに下層に設定します。このドキュメントは、タイプ「EAPキー」の構造を定義していないことに注意してください。[キーイング]で定義されると予想されます。
aaaEapKeyAvailable (boolean)
aaaeapkeyavailable（boolean）
Set to TRUE in the lower layer if keying material is available. The actual key is stored in aaaEapKeyData.
キーイング材料が利用可能な場合は、下層でtrueに設定します。実際のキーはAAAEAPKEYDATAに保存されます。
aaaMethodTimeout (integer)
aaamethodtimeout（整数）
Method-provided hint for suitable retransmission timeout, or NONE. (Note that this hint is for the EAP retransmissions done by the pass-through authenticator, not for retransmissions of AAA packets.)
適切な再送信タイムアウトのための方法が提供するヒント、またはなし。（このヒントは、AAAパケットの再送信ではなく、パススルー認証機によって行われたEAP再送信のためのものであることに注意してください。）
aaaEapResp (boolean)
aaaeapresp（boolean）
Set to TRUE in authenticator state machine, FALSE in the lower layer. Indicates that an EAP response is available for processing by the AAA server.
Authenticator State MachineでTrueに設定され、下層でFalse。AAAサーバーによる処理にEAP応答が利用可能であることを示します。
aaaEapRespData (EAP packet)
aaaeaeaprespdata（EAPパケット）
Set in authenticator state machine when eapResp is set to TRUE. The EAP packet to be processed.
EAPRESPがtrueに設定されている場合、Authenticator Stateマシンに設定します。処理されるEAPパケット。
aaaIdentity (EAP packet)
aaaaidentity（EAPパケット）
Set in authenticator state machine when an IDENTITY response is received. Makes that identity available to AAA lower layer.
アイデンティティ応答が受信されたときに認証状態のマシンに設定します。そのアイデンティティをAAA下層層で利用できるようにします。
aaaTimeout (boolean)
aaatimeout（boolean）
Set in AAA_IDLE if, after a configurable amount of time, there is no response from the AAA layer. The AAA layer in the NAS is itself alive and OK, but for some reason it has not received a valid Access-Accept/Reject indication from the backend.
AAA_IDLEに設定されている場合、構成可能な時間の後、AAAレイヤーからの応答がない場合。NASのAAA層はそれ自体が生きており、大丈夫ですが、何らかの理由で、バックエンドから有効なアクセスaccept/拒否の表示を受け取っていません。
Same as Section 5.
セクション5と同じ。
Same as stand-alone authenticator (Section 5.2).
スタンドアロン認証器と同じ（セクション5.2）。
Many of the variables of the full authenticator have already been defined in Section 5. This section contains definitions for those not existent in the stand-alone version, as well as those that are defined differently.
完全な認証機の変数の多くは、セクション5ですでに定義されています。このセクションには、スタンドアロンバージョンに存在しない人の定義と、異なる方法で定義されているものが含まれています。
decision (enumeration)
決定（列挙）
Set in SELECT_ACTION state. Temporarily stores the policy decision to succeed, fail, continue with a local method, or continue in pass-through mode.
select_action状態で設定します。ポリシーの決定を一時的に保存し、成功、失敗、ローカルメソッドの継続、またはパススルーモードを継続します。
All the procedures defined in Section 5 exist in the full version. In addition, the following procedures are defined.
セクション5で定義されているすべての手順は、フルバージョンに存在します。さらに、次の手順が定義されています。
getId()
getId（）
Determines the identifier value chosen by the AAA server for the current EAP request. The return value is an integer.
現在のEAP要求に対してAAAサーバーによって選択された識別子値を決定します。返品値は整数です。
All the states defined in Section 5 exist in the full version. In addition, the following states are defined.
セクション5で定義されているすべての州は、フルバージョンに存在します。さらに、次の状態が定義されています。
INITIALIZE_PASSTHROUGH
intialize_passthrough
Initializes variables when the pass-through portion of the state machine is activated.
状態マシンのパススルー部分がアクティブになったときに変数を初期化します。
IDLE2
Idle2
The state machine waits for a response from the primary lower layer, which transports EAP traffic from the peer.
ステートマシンは、ピアからEAPトラフィックを輸送する主要な下層からの応答を待ちます。
IDLE
アイドル
The state machine spends most of its time here, waiting for something to happen.
州のマシンはここでほとんどの時間を費やし、何かが起こるのを待っています。
RECEIVED2
受信2
This state is entered when an EAP packet is received and the authenticator is in PASSTHROUGH mode. The packet header is parsed here.
この状態は、EAPパケットが受信され、認証機がパススルーモードになったときに入力されます。パケットヘッダーはここで解析されます。
AAA_REQUEST
aaa_request
The incoming EAP packet is parsed for sending to the AAA server.
着信EAPパケットは、AAAサーバーに送信するために解析されます。
AAA_IDLE
aaa_idle
Idle state that tells the AAA layer that it has a response and then waits for a new request, a no-request signal, or success/failure.
AAAレイヤーに応答があることを伝えるアイドル状態は、新しいリクエスト、リクエストなし信号、または成功/失敗を待ちます。
AAA_RESPONSE
aaa_response
State in which the request from the AAA interface is processed into an EAP request.
AAAインターフェイスからの要求がEAP要求に処理される状態。
SEND_REQUEST2
send_request2
This state signals the lower layer that a request packet is ready to be sent.
この状態は、リクエストパケットを送信する準備ができていることを示す下層を示しています。
DISCARD2
Disdard2
This state signals the lower layer that the response was discarded, and that no new request packet will be sent at this time.
この状態は、応答が廃棄され、現時点では新しいリクエストパケットが送信されないことを示す下層を示しています。
RETRANSMIT2
retransmit2
Retransmits the previous request packet.
前のリクエストパケットを再送信します。
SUCCESS2
成功2
A final state indicating success.
成功を示す最終状態。
FAILURE2
障害2
A final state indicating failure.
障害を示す最終状態。
TIMEOUT_FAILURE2
timeout_failure2
A final state indicating failure because no response has been received. Because no response was received, no new message (including failure) should be sent to the peer. Note that this is different from the FAILURE2 state, in which a message indicating failure is sent to the peer.
応答が受け取られていないため、障害を示す最終状態。応答がないため、新しいメッセージ（失敗を含む）をピアに送信する必要はありません。これは、故障2状態とは異なることに注意してください。この状態では、障害を示すメッセージがピアに送信されます。
In order to deal with erroneous cases that are not directly related to the protocol behavior, implementations may need additional considerations to provide robustness against errors.
プロトコルの動作に直接関係していない誤ったケースに対処するためには、エラーに対する堅牢性を提供するために、実装が追加の考慮事項が必要になる場合があります。
For example, an implementation of a state machine may spend a significant amount of time in a particular state performing the procedure defined for the state without returning a response. If such an implementation is made on a multithreading system, the procedure may be performed in a separate thread so that the implementation can perform appropriate action without blocking on the state for a long time (or forever if the procedure never completes due to, e.g., a non-responding user or a bug in an application callback function).
たとえば、状態マシンの実装は、特定の州でかなりの時間を費やして、応答を返さずに州に対して定義された手順を実行する場合があります。そのような実装がマルチスレッドシステムで行われた場合、手順は別のスレッドで実行される可能性があるため、実装は州を長時間ブロックせずに適切なアクションを実行できます（または、たとえば、手順が完了しない場合、応答しないユーザーまたはアプリケーションコールバック関数のバグ）。
The following states are identified as the possible places of blocking:
次の状態は、ブロッキングの可能性のある場所として特定されています。
o IDENTITY state in the peer state machine. It may take some time to process Identity request when a user input is needed for obtaining an identity from the user. The user may never input an identity. An implementation may define an additional state transition from IDENTITY state to FAILURE state so that authentication can fail if no identity is obtained from the user before ClientTimeout timer expires.
o ピアステートマシンのアイデンティティ状態。ユーザーからIDを取得するためにユーザー入力が必要な場合、IDリクエストを処理するのに時間がかかる場合があります。ユーザーはアイデンティティを入力することはできません。実装は、IDの状態から障害状態への追加の状態の移行を定義し、クライアントタイムアウトタイマーが期限切れになる前にユーザーからIDが取得されない場合、認証が失敗する可能性があります。
o METHOD state in the peer state machine and in METHOD_RESPONSE state in the authenticator state machines. It may take some time to perform method-specific procedures in these states. An implementation may define an additional state transition from METHOD state and METHOD_RESPONSE state to FAILURE or TIMEOUT_FAILURE state so that authentication can fail if no method processing result is obtained from the method before methodTimeout timer expires.
o メソッドステートピアステートマシンの状態およびAuthenticator StateマシンのMethod_Response状態。これらの状態で方法固有の手順を実行するのに時間がかかる場合があります。実装は、MethodTimeOutタイマーが期限切れになる前にメソッド処理結果がメソッドから取得されない場合に認証が失敗するように、メソッド状態およびMethod_response状態またはTimeout_Failure状態への追加の状態遷移を定義する場合があります。
Implementations may define additional interfaces to pass method-specific information between methods and lower layers. These interfaces are beyond the scope of this document.
実装は、メソッドと下層の間にメソッド固有の情報を渡すための追加のインターフェイスを定義する場合があります。これらのインターフェイスは、このドキュメントの範囲を超えています。
Number of deployed EAP authenticator implementations, mainly in RADIUS authentication servers, have been observed to increment the Identifier field incorrectly when generating EAP Success and EAP Failure packets which is against the MUST requirement in RFC 3748 section 4.2. The peer state machine is based on RFC 3748, and as such it will discard such EAP Success and EAP Failure packets.
主にRADIUS認証サーバーで展開されているEAP認証機の実装の数は、RFC 3748セクション4.2の必須要件に反するEAP成功とEAP障害パケットを生成するときに識別子フィールドを誤って増加させることが観察されています。ピアステートマシンはRFC 3748に基づいているため、このようなEAPの成功とEAP障害パケットを破棄します。
As a workaround for the potential interoperability issue with existing implementations, conditions for peer state machine transitions from RECEIVED state to SUCCESS and FAILURE states MAY be changed from "(reqId == lastId)" to "((reqId == lastId) || (reqId == (lastId + 1) & 255))". However, because this behavior does not conform to RFC 3748, such a workaround is not recommended, and if included, it should be implemented as an optional workaround that can be disabled.
既存の実装との潜在的な相互運用性の問題の回避策として、ピア状態から成功および失敗状態へのピアステートマシンの移行の条件は、「reqid == lastId）」から「（reqid == lastId）||（reqid ==（lastId 1）＆255）） "。ただし、この動作はRFC 3748に準拠していないため、このような回避策は推奨されず、含まれる場合は、無効にできるオプションの回避策として実装する必要があります。
This document's intent is to describe the EAP state machine fully. To this end, any security concerns with this document are likely a reflection of security concerns with EAP itself.
このドキュメントの目的は、EAPステートマシンを完全に説明することです。この目的のために、このドキュメントに関するセキュリティの懸念は、EAP自体に関するセキュリティの懸念を反映している可能性があります。
An accurate state machine can help reduce implementation errors. Although [RFC3748] remains the normative protocol description, this state machine should help in this regard.
正確な状態マシンは、実装エラーを減らすのに役立ちます。[RFC3748]は依然として規範的なプロトコルの説明ですが、この状態マシンはこの点で役立つはずです。
As noted in [RFC3748], some security concerns arise because of the following EAP packets:
[RFC3748]で述べたように、次のEAPパケットのためにいくつかのセキュリティの懸念が生じます。
1. EAP-Request/Response Identity 2. EAP-Response/NAK 3. EAP-Success/Failure
1. EAP-Request/Response ID 2. EAP-Response/Nak 3. EAP-SUSCESS/FOLION
Because these packets are not cryptographically protected by themselves, an attacker can modify or insert them without immediate detection by the peer or authenticator.
これらのパケットは暗号化されていないため、攻撃者は、ピアまたは認証者による即時検出なしに変更または挿入できます。
Following Figure 3 specification, an attacker may cause denial of service by: o Sending an EAP-Failure to the peer before the peer has started an EAP authentication method. As long as the peer has not modified the methodState variable (initialized to NONE), the peer MUST accept an EAP-Failure.
図3の仕様に従って、攻撃者は以下によってサービスの拒否を引き起こす場合があります。oピアがEAP認証方法を開始する前に、ピアにEAPフェイルを送信します。ピアがMethodState変数を変更していない限り（初期化されていない）、ピアはEAPフェイルを受け入れる必要があります。
o Forcing the peer to engage in endless EAP-Request/Response Identity exchanges before it has started an EAP authentication method. As long as the peer has not modified the selectedMethod variable (initialized to NONE), the peer MUST accept an EAP-Request/Identity and respond to it with an EAP-Response/Identity.
o EAP認証方法を開始する前に、ピアに無限のEAP-Request/Response Identity Identy Exchangeに従事するように強制します。ピアがSelectedMethod変数を変更していない限り（初期化されない）、ピアはEAP-Request/IDを受け入れ、EAP応答/アイデンティティで応答する必要があります。
Following Figure 4 specification, an attacker may cause denial of service by:
図4の仕様に従って、攻撃者は次のようにサービスの拒否を引き起こす可能性があります。
o Sending a NAK to the authenticator after the authenticator first proposes an EAP authentication method to the peer. When the methodState variable has the value PROPOSED, the authenticator is obliged to process a NAK that is received in response to its first packet of an EAP authentication method.
o Authenticatorが最初にピアにEAP認証方法を提案した後、AuthenticatorにNAKを送信します。MethodState変数に値が提案されている場合、Authenticatorは、EAP認証方法の最初のパケットに応じて受信されるNAKを処理する義務があります。
There MAY be some cases when it is desired to prevent such attacks. This can be done by modifying initial values of some variables of the EAP state machines. However, such modifications are NOT RECOMMENDED.
そのような攻撃を防ぐことが望ましい場合がある場合があります。これは、EAP状態マシンのいくつかの変数の初期値を変更することで実行できます。ただし、このような変更は推奨されません。
There is a trade-off between mitigating these denial-of-service attacks and being able to deal with EAP peers and authenticators in general. For instance, if a NAK is ignored when it is sent to the authenticator after it has just proposed an EAP authentication method to the peer, then a legitimate peer that is not able or willing to process the proposed EAP authentication method would fail without an opportunity to negotiate another EAP method.
これらのサービス拒否攻撃を緩和することと、一般的にEAPのピアや認証者に対処できることとの間にはトレードオフがあります。たとえば、NAKがピアにEAP認証方法を提案したばかりの後に認証器に送信されたときに無視される場合、提案されたEAP認証方法を処理することができない、または処理することを望んでいない正当なピアは、機会なしに失敗するでしょう別のEAPメソッドを交渉します。
The work in this document was done as part of the EAP Design Team. It was done primarily by Nick Petroni, John Vollbrecht, Pasi Eronen, and Yoshihiro Ohba. Nick started this work with Bryan Payne and Chuk Seng at the University of Maryland. John Vollbrecht of Meetinghouse Data Communications started independently with help from Dave Spence at Interlink Networks. John and Nick collaborated to create a common document, and then were joined by Pasi Eronen of Nokia, who has made major contributions in creating coherent state machines, and by Yoshihiro Ohba of Toshiba, who insisted on including pass-through documentation and provided significant support for understanding implementation issues.
このドキュメントの作業は、EAPデザインチームの一部として行われました。それは主にニック・ペトロニ、ジョン・ヴォルブレヒト、パシ・エロネン、ヨシヒロ・オバによって行われました。ニックはメリーランド大学でブライアン・ペインとチュク・センとこの仕事を始めました。Meetinghouse Data CommunicationsのJohn Vollbrechtは、インターリンクネットワークのDave Spenceの助けを借りて独立して始まりました。ジョンとニックは共通の文書を作成するために協力し、その後、一貫した州のマシンの作成に大きな貢献をしたノキアのパシ・エロネンと、パススルーのドキュメントを含めることを主張し、重要なサポートを提供した東芝のヨシヒロ・オバが加わりました実装の問題を理解するため。
In addition, significant response and conversation has come from the design team, especially Jari Arkko of Ericsson and Bernard Aboba of Microsoft, as well as the rest of the team. It has also been reviewed by IEEE 802.1, and has had input from Jim Burns of Meetinghouse and Paul Congdon of Hewlett Packard.
さらに、デザインチーム、特にマイクロソフトのエリクソンとバーナード・アボバのジャリ・アークコ、そして他のチームからの重要な反応と会話が来ています。また、IEEE 802.1によってレビューされており、MeetinghouseのJim BurnsとHewlett PackardのPaul Congdonから意見を述べました。
[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月。
[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月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., Levkowetz, H., "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, July 2005.
[Keying] Aboba、B.、Simon、D.、Arkko、J.、Eronen、P.、Levkowetz、H。、「拡張可能な認証プロトコル（EAP）キー管理フレームワーク」、2005年7月の作業。
[1X-2004] Institute of Electrical and Electronics Engineers, "Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE 802.1X-2004, December 2004.
[2004年1x-2004]電気および電子機器エンジニアの研究所、「ローカルおよびメトロポリタンエリアネットワークの標準：ポートベースのネットワークアクセス制御」、IEEE 802.1x-2004、2004年12月。
This appendix contains the state diagrams in ASCII format. Please use the PDF version whenever possible; it is much easier to understand.
この付録には、ASCII形式の状態図が含まれています。可能な限りPDFバージョンを使用してください。理解しやすいです。
The notation is as follows: state name and pseudocode executed when entering it are shown on the left; outgoing transitions with their conditions are shown on the right.
表記は次のとおりです。そこに入力すると実行される状態名と擬似コードが左に表示されます。条件による発信遷移は右側に示されています。
---------------------------------------------------------------------
(global transitions) | !portEnabled | DISABLED
|------------------------+--------------
| eapRestart && | INITIALIZE
| portEnabled |
-----------------------------+------------------------+--------------
DISABLED | portEnabled | INITIALIZE
-----------------------------+------------------------+--------------
INITIALIZE | |
| |
selectedMethod = NONE | |
methodState = NONE | |
allowNotifications = TRUE | |
decision = FAIL | UCT | IDLE
idleWhile = ClientTimeout | |
lastId = NONE | |
eapSuccess = FALSE | |
eapFail = FALSE | |
eapKeyData = NONE | |
eapKeyAvailable = FALSE | |
eapRestart = FALSE | |
-----------------------------+------------------------+--------------
IDLE | eapReq | RECEIVED
|------------------------+--------------
| (altAccept && |
| decision != FAIL) || |
| (idleWhile == 0 && | SUCCESS
| decision == |
| UNCOND_SUCC) |
|------------------------+--------------
|------------------------+--------------
| altReject || |
| (idleWhile == 0 && |
| decision != |
| UNCOND_SUCC) || | FAILURE
| (altAccept && |
| methodState != CONT && |
| decision == FAIL) |
-----------------------------+------------------------+--------------
RECEIVED | rxReq && | METHOD
| (reqId != lastId) && |
(rxReq,rxSuccess,rxFailure, | (reqMethod == |
reqId,reqMethod) = | selectedMethod) && |
parseEapReq(eapReqData) | (methodState != DONE) |
|------------------------+--------------
| rxReq && |
| (reqId != lastId) && |
| (selectedMethod == |
| NONE) && | GET_METHOD
| (reqMethod != |
| IDENTITY) && |
| (reqMethod != |
| NOTIFICATION) |
|------------------------+--------------
| rxReq && |
| (reqId != lastId) && |
| (selectedMethod == | IDENTITY
| NONE) && |
| (reqMethod == |
| IDENTITY) |
|------------------------+--------------
| rxReq && |
| (reqId != lastId) && |
| (reqMethod == | NOTIFICATION
| NOTIFICATION) && |
| allowNotifications |
|------------------------+--------------
| rxReq && | RETRANSMIT
| (reqId == lastId) |
|------------------------+--------------
| rxSuccess && |
| (reqId == lastId) && | SUCCESS
| (decision != FAIL) |
|------------------------+--------------
|------------------------+--------------
| (methodState!=CONT) && |
| ((rxFailure && |
| decision != |
| UNCOND_SUCC) || | FAILURE
| (rxSuccess && |
| decision == FAIL)) && |
| (reqId == lastId) |
|------------------------+--------------
| else | DISCARD
-----------------------------+------------------------+--------------
METHOD | |
| |
ignore = m.check(eapReqData) | ignore | DISCARD
if (!ignore) { | |
(methodState, decision, | |
allowNotifications) = |------------------------+--------------
m.process(eapReqData) | |
/* methodState is CONT, | |
MAY_CONT, or DONE */ | (methodState==DONE) && | FAILURE
/* decision is FAIL, | (decision == FAIL) |
COND_SUCC, or | |
UNCOND_SUCC */ | |
eapRespData = |------------------------+--------------
m.buildResp(reqId) | |
if (m.isKeyAvailable()) | else | SEND_RESPONSE
eapKeyData = m.getKey() | |
} | |
-----------------------------+------------------------+--------------
GET_METHOD | |
| selectedMethod == |
if (allowMethod(reqMethod)) {| reqMethod | METHOD
selectedMethod = reqMethod | |
methodState = INIT | |
} else { |------------------------+--------------
eapRespData = | |
buildNak(reqId) | else | SEND_RESPONSE
} | |
-----------------------------+------------------------+--------------
IDENTITY | |
| |
processIdentity(eapReqData) | UCT | SEND_RESPONSE
eapRespData = | |
buildIdentity(reqId) | |
-----------------------------+------------------------+--------------
-----------------------------+------------------------+--------------
NOTIFICATION | |
| |
processNotify(eapReqData) | UCT | SEND_RESPONSE
eapRespData = | |
buildNotify(reqId) | |
-----------------------------+------------------------+--------------
RETRANSMIT | |
| UCT | SEND_RESPONSE
eapRespData = lastRespData | |
-----------------------------+------------------------+--------------
DISCARD | |
| UCT | IDLE
eapReq = FALSE | |
eapNoResp = TRUE | |
-----------------------------+------------------------+--------------
SEND_RESPONSE | |
| |
lastId = reqId | |
lastRespData = eapRespData | UCT | IDLE
eapReq = FALSE | |
eapResp = TRUE | |
idleWhile = ClientTimeout | |
-----------------------------+------------------------+--------------
SUCCESS | |
| |
if (eapKeyData != NONE) | |
eapKeyAvailable = TRUE | |
eapSuccess = TRUE | |
-----------------------------+------------------------+--------------
FAILURE | |
| |
eapFail = TRUE | |
---------------------------------------------------------------------
Figure 8
---------------------------------------------------------------------
(global transitions) | !portEnabled | DISABLED
|---------------------+----------------
| eapRestart && | INITIALIZE
| portEnabled |
------------------------------+---------------------+----------------
DISABLED | portEnabled | INITIALIZE
------------------------------+---------------------+----------------
------------------------------+---------------------+----------------
INITIALIZE | |
| |
currentId = NONE | |
eapSuccess = FALSE | |
eapFail = FALSE | UCT | SELECT_ACTION
eapTimeout = FALSE | |
eapKeyData = NONE | |
eapKeyAvailable = FALSE | |
eapRestart = FALSE | |
------------------------------+---------------------+----------------
IDLE | |
| retransWhile == 0 | RETRANSMIT
retransWhile = | |
calculateTimeout( |---------------------+----------------
retransCount, eapSRTT, | eapResp | RECEIVED
eapRTTVAR, methodTimeout) | |
------------------------------+---------------------+----------------
RETRANSMIT | |
| retransCount > | TIMEOUT_FAILURE
retransCount++ | MaxRetrans |
if (retransCount<=MaxRetrans){| |
eapReqData = lastReqData |---------------------+----------------
eapReq = TRUE | else | IDLE
} | |
------------------------------+---------------------+----------------
RECEIVED | rxResp && |
| (respId == |
(rxResp,respId,respMethod)= | currentId) && |
parseEapResp(eapRespData) | (respMethod == NAK |
| || | NAK
| respMethod == |
| EXPANDED_NAK) && |
| (methodState == |
| PROPOSED) |
|---------------------+----------------
| rxResp && |
| (respId == |
| currentId) && | INTEGRITY_CHECK
| (respMethod == |
| currentMethod) |
|---------------------+----------------
| else | DISCARD
------------------------------+---------------------+----------------
------------------------------+---------------------+----------------
NAK | |
| UCT | SELECT_ACTION
m.reset() | |
Policy.update(<...>) | |
------------------------------+---------------------+----------------
SELECT_ACTION | decision == FAILURE | FAILURE
| |
decision = |---------------------+----------------
Policy.getDecision() | decision == SUCCESS | SUCCESS
/* SUCCESS, FAILURE, or |---------------------+----------------
CONTINUE */ | else | PROPOSE_METHOD
------------------------------+---------------------+----------------
INTEGRITY_CHECK | ignore | DISCARD
|---------------------+----------------
ignore = m.check(eapRespData) | !ignore | METHOD_RESPONSE
------------------------------+---------------------+----------------
METHOD_RESPONSE | |
| methodState == END | SELECT_ACTION
m.process(eapRespData) | |
if (m.isDone()) { | |
Policy.update(<...>) |---------------------+----------------
eapKeyData = m.getKey() | |
methodState = END | else | METHOD_REQUEST
} else | |
methodState = CONTINUE | |
------------------------------+---------------------+----------------
PROPOSE_METHOD | |
| |
currentMethod = | |
Policy.getNextMethod() | |
m.init() | UCT | METHOD_REQUEST
if (currentMethod==IDENTITY ||| |
currentMethod==NOTIFICATION)| |
methodState = CONTINUE | |
else | |
methodState = PROPOSED | |
------------------------------+---------------------+----------------
METHOD_REQUEST | |
| |
currentId = nextId(currentId) | UCT | SEND_REQUEST
eapReqData = | |
m.buildReq(currentId) | |
methodTimeout = m.getTimeout()| |
------------------------------+---------------------+----------------
------------------------------+---------------------+----------------
DISCARD | |
| UCT | IDLE
eapResp = FALSE | |
eapNoReq = TRUE | |
------------------------------+---------------------+----------------
SEND_REQUEST | |
| |
retransCount = 0 | UCT | IDLE
lastReqData = eapReqData | |
eapResp = FALSE | |
eapReq = TRUE | |
------------------------------+---------------------+----------------
TIMEOUT_FAILURE | |
| |
eapTimeout = TRUE | |
------------------------------+---------------------+----------------
FAILURE | |
| |
eapReqData = | |
buildFailure(currentId) | |
eapFail = TRUE | |
------------------------------+---------------------+----------------
SUCCESS | |
| |
eapReqData = | |
buildSuccess(currentId) | |
if (eapKeyData != NONE) | |
eapKeyAvailable = TRUE | |
eapSuccess = TRUE | |
---------------------------------------------------------------------
Figure 9
---------------------------------------------------------------------
(global transitions) | !backendEnabled | DISABLED
------------------------------+---------------------+----------------
DISABLED | backendEnabled && | INITIALIZE
| aaaEapResp |
------------------------------+---------------------+----------------
------------------------------+---------------------+----------------
INITIALIZE | !rxResp | SELECT_ACTION
|---------------------+----------------
currentMethod = NONE | rxResp && |
(rxResp,respId,respMethod)= | (respMethod == NAK |
parseEapResp(aaaEapRespData)| || | NAK
if (rxResp) | respMethod == |
currentId = respId | EXPANDED_NAK) |
else |---------------------+----------------
currentId = NONE | else | PICK_UP_METHOD
------------------------------+---------------------+----------------
PICK_UP_METHOD | |
| currentMethod == | SELECT_ACTION
if (Policy.doPickUp( | NONE |
respMethod)) { | |
currentMethod = respMethod |---------------------+----------------
m.initPickUp() | else | METHOD_RESPONSE
} | |
------------------------------+---------------------+----------------
IDLE | aaaEapResp | RECEIVED
------------------------------+---------------------+----------------
RECEIVED | rxResp && |
| (respId == |
(rxResp,respId,respMethod)= | currentId) && |
parseEapResp(aaaEapRespData)| (respMethod == NAK |
| || | NAK
| respMethod == |
| EXPANDED_NAK) && |
| (methodState == |
| PROPOSED) |
|---------------------+----------------
| rxResp && |
| (respId == |
| currentId) && | INTEGRITY_CHECK
| (respMethod == |
| currentMethod) |
|---------------------+----------------
| else | DISCARD
------------------------------+---------------------+----------------
NAK | |
| UCT | SELECT_ACTION
m.reset() | |
Policy.update(<...>) | |
------------------------------+---------------------+----------------
------------------------------+---------------------+----------------
SELECT_ACTION | decision == FAILURE | FAILURE
| |
decision = |---------------------+----------------
Policy.getDecision() | decision == SUCCESS | SUCCESS
/* SUCCESS, FAILURE, or |---------------------+----------------
CONTINUE */ | else | PROPOSE_METHOD
------------------------------+---------------------+----------------
INTEGRITY_CHECK | ignore | DISCARD
| |
ignore = |---------------------+----------------
m.check(aaaEapRespData) | !ignore | METHOD_RESPONSE
------------------------------+---------------------+----------------
METHOD_RESPONSE | |
| methodState == END | SELECT_ACTION
m.process(aaaEapRespData) | |
if (m.isDone()) { | |
Policy.update(<...>) |---------------------+----------------
aaaEapKeyData = m.getKey() | |
methodState = END | else | METHOD_REQUEST
} else | |
methodState = CONTINUE | |
------------------------------+---------------------+----------------
PROPOSE_METHOD | |
| |
currentMethod = | |
Policy.getNextMethod() | |
m.init() | UCT | METHOD_REQUEST
if (currentMethod==IDENTITY ||| |
currentMethod==NOTIFICATION)| |
methodState = CONTINUE | |
else | |
methodState = PROPOSED | |
------------------------------+---------------------+----------------
METHOD_REQUEST | |
| |
currentId = nextId(currentId) | |
aaaEapReqData = | UCT | SEND_REQUEST
m.buildReq(currentId) | |
aaaMethodTimeout = | |
m.getTimeout() | |
------------------------------+---------------------+----------------
DISCARD | |
| UCT | IDLE
aaaEapResp = FALSE | |
aaaEapNoReq = TRUE | |
------------------------------+---------------------+----------------
------------------------------+---------------------+----------------
SEND_REQUEST | |
| UCT | IDLE
aaaEapResp = FALSE | |
aaaEapReq = TRUE | |
------------------------------+---------------------+----------------
FAILURE | |
| |
aaaEapReqData = | |
buildFailure(currentId) | |
aaaEapFail = TRUE | |
------------------------------+---------------------+----------------
SUCCESS | |
| |
aaaEapReqData = | |
buildSuccess(currentId) | |
if (aaaEapKeyData != NONE) | |
aaaEapKeyAvailable = TRUE | |
aaaEapSuccess = TRUE | |
---------------------------------------------------------------------
Figure 10
This state machine contains all the states from EAP stand-alone authenticator state machine, except that SELECT_ACTION state is replaced with the following:
この状態マシンには、select_action状態が以下に置き換えられていることを除いて、EAPスタンドアロン認証状態マシンのすべての状態が含まれています。
---------------------------------------------------------------------
SELECT_ACTION | decision == FAILURE | FAILURE
| |
decision = |---------------------+----------------
Policy.getDecision() | decision == SUCCESS | SUCCESS
/* SUCCESS, FAILURE, CONTINUE,|---------------------+----------------
or PASSTHROUGH */ | decision == | INITIALIZE_
| PASSTHROUGH | PASSTHROUGH
|---------------------+----------------
| else | PROPOSE_METHOD
---------------------------------------------------------------------
Figure 11
And the following new states are added:
次の新しい状態が追加されています。
---------------------------------------------------------------------
INITIALIZE_PASSTHROUGH | currentId != NONE | AAA_REQUEST
|---------------------+----------------
aaaEapRespData = NONE | currentId == NONE | AAA_IDLE
------------------------------+---------------------+----------------
------------------------------+---------------------+----------------
IDLE2 | |
| retransWhile == 0 | RETRANSMIT2
retransWhile = | |
calculateTimeout( |---------------------+----------------
retransCount, eapSRTT, | eapResp | RECEIVED2
eapRTTVAR, methodTimeout) | |
------------------------------+---------------------+----------------
RETRANSMIT2 | |
| retransCount > | TIMEOUT_
retransCount++ | MaxRetrans | FAILURE2
if (retransCount<=MaxRetrans){| |
eapReqData = lastReqData |---------------------+----------------
eapReq = TRUE | else | IDLE2
} | |
------------------------------+---------------------+----------------
RECEIVED2 | rxResp && |
| (respId == | AAA_REQUEST
(rxResp,respId,respMethod)= | currentId) |
parseEapResp(eapRespData) |---------------------+----------------
| else | DISCARD2
------------------------------+---------------------+----------------
AAA_REQUEST | |
| |
if (respMethod == IDENTITY) { | UCT | AAA_IDLE
aaaIdentity = eapRespData | |
aaaEapRespData = eapRespData | |
------------------------------+---------------------+----------------
AAA_IDLE | aaaEapNoReq | DISCARD2
|---------------------+----------------
aaaFail = FALSE | aaaEapReq | AAA_RESPONSE
aaaSuccess = FALSE |---------------------+----------------
aaaEapReq = FALSE | aaaTimeout | TIMEOUT_
aaaEapNoReq = FALSE | | FAILURE2
aaaEapResp = TRUE |---------------------+----------------
| aaaFail | FAILURE2
|---------------------+----------------
| aaaSuccess | SUCCESS2
------------------------------+---------------------+----------------
AAA_RESPONSE | |
| |
eapReqData = aaaEapReqData | UCT | SEND_REQUEST2
currentId = getId(eapReqData) | |
methodTimeout = | |
aaaMethodTimeout | |
------------------------------+---------------------+----------------
------------------------------+---------------------+----------------
DISCARD2 | |
| UCT | IDLE2
eapResp = FALSE | |
eapNoReq = TRUE | |
------------------------------+---------------------+----------------
SEND_REQUEST2 | |
| |
retransCount = 0 | UCT | IDLE2
lastReqData = eapReqData | |
eapResp = FALSE | |
eapReq = TRUE | |
------------------------------+---------------------+----------------
TIMEOUT_FAILURE2 | |
| |
eapTimeout = TRUE | |
------------------------------+---------------------+----------------
FAILURE2 | |
| |
eapReqData = aaaEapReqData | |
eapFail = TRUE | |
------------------------------+---------------------+----------------
SUCCESS2 | |
| |
eapReqData = aaaEapReqData | |
eapKeyData = aaaEapKeyData | |
eapKeyAvailable = | |
aaaEapKeyAvailable | |
eapSuccess = TRUE | |
---------------------------------------------------------------------
Figure 12
Authors' Addresses
著者のアドレス
John Vollbrecht Meetinghouse Data Communications 9682 Alice Hill Drive Dexter, MI 48130 USA
John Vollbrecht Meetinghouse Data Communications 9682 Alice Hill Drive Dexter、Mi 48130 USA
EMail: jrv@mtghouse.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group, Finland
Pasi Eronen Nokia Research Center P.O.ボックス407フィン-00045ノキアグループ、フィンランド
EMail: pasi.eronen@nokia.com
Nick L. Petroni, Jr. University of Maryland, College Park A.V. Williams Building College Park, MD 20742 USA
ニックL.ペトロニ、ジュニアメリーランド大学、カレッジパークA.V.ウィリアムズビルディングカレッジパーク、メリーランド州20742アメリカ
EMail: npetroni@cs.umd.edu
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
ヨシヒロ・オバ・トーバ・アメリカ・リサーチ、Inc。1 Telcordia Drive Piscataway、NJ 08854 USA
EMail: yohba@tari.toshiba.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
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.
この文書は、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エディター機能の資金は現在、インターネット協会によって提供されています。