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
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).
著作権（C）インターネット協会（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スタンドアローンオーセンティケータ（非パススルー）（認証、認可、アカウンティング（AAA）サーバ上で使用するため）、EAPのバックエンド認証のためのステートマシンのセットを記述し、 （ローカルとパススルーの両方のための）EAPフルオーセンティケータ。ステートマシンのこのセットは、EAPピア/オーセンティケータまたはピア/オーセンティケータ/ AAA Server環境のいずれかでの展開をサポートするために実装する方法を示しています。ピアおよびスタンドアロン認証子機は、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.
この文書は、RFCの[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認証は、ピアに認証者から送信されたEAP成功又はEAP失敗が続くシーケンス内の1つまたは複数の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.
ピア及びオーセンティケータの両方で、一つ以上の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応答メッセージを通過させます。本稿では、ローカルおよびパススルー方法ならびにAAAサーバに存在するバックエンド認証のためのステートマシンの両方をサポートするEAP認証のための状態機械を含みます。シンプルなスタンドアローンのオーセンティケータは、基本的な、非パススルー認証システムの動作を示すために提供されています。
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.
この文書では、オーセンティケータ上の又はバックエンド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パケットの逆多重化を実行しなければなりません。レスポンスに設定されたコードとEAPパケットは認証マシンに配信され、そして、成功を要求するように設定コード、または失敗して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].
この文書の状態図は、[1X-2004]の図でコーディネートされています。図の形式は、内部フォーマットから適合されています。ここで定義されたステートマシンと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].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "OPTIONAL" は解釈されるべきです[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.
状態図は、協働する状態機械の数でプロトコルの動作を表すために使用され、それぞれが接続され、相互に排他的な状態の基を含みます。各マシンの唯一の状態は、任意の時点でアクティブにできます。
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.
各状態は、水平線によって二つの部分に分け、長方形の箱のような状態図に示されています。上部は大文字で書かれた状態識別子が含まれています。下部は、状態に入るときに実行される任意の手順を含んでいます。
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.
状態間の全ての許容遷移は、矢印で可能な遷移の方向を示す矢印で表されています。矢印に取り付けられたラベルは、場所を取るために遷移ために満たされなければならない条件（複数可）を意味します。すべての条件がTRUEまたはFALSEに評価式です。条件がTRUEと評価される場合、その条件が満たされています。ラベルUCTは無条件遷移（すなわち、UCTは常にTRUEに評価される）です。性質（すなわち、矢印に取り付けられた条件が満たされた場合に可能な状態のいずれかから生じる遷移）が白抜きの矢印で示されているのグローバルである遷移。すなわち、具体的な状態遷移の起源として同定されていません。グローバル遷移に関連付けられた条件が満たされたとき、それはUCTを含むすべての他の終了条件に取って代わります。特別なグローバルな条件の他のすべてのグローバルな条件を優先し、一度すべての状態ブロックは変数の代入とその実行の他の結果が変わらないことをポイントに実行されるまで、それがアサートされたままアサートBEGIN。
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.
状態へのエントリでは、状態（もしあれば）のために定義された手順は、それらがページに表示される順序で、一度だけ実行されます。各アクションはアトミックであるとみなされます。次の連続手順が実行を開始する前に、すなわち、手順の実行が完了します。いいえ手順は、状態ブロックの外側で実行しません。唯一つの状態ブロック内の手順が異なる状態マシンの状態ブロックの実行条件が成立している場合でも、一度に実行し、他の状態ブロックに遷移し、実行前に実行状態ブロックの完全な実行中のすべての手順が発生します。すなわち、任意の状態ブロックの実行は、他の状態ブロックの実行に対してアトミックであるように見える、そして実行が始まるときに以前の状態からの状態への遷移条件がTRUEです。異なる状態マシンの状態ブロックの実行の順序は、それらの遷移条件によって制約される場合を除き定義されていません。その後の状態ブロックは、値を修正手順を実行するまで、状態ブロック内の特定の値に設定されている変数は、この値を保持します。
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.
いずれかの条件が満たされるまで、状態内のすべての手順の完了時に、（グローバル遷移に関連するすべての状態を含む）状態のためのすべての終了条件を連続的に評価されます。状態からの遷移のための他の条件のいずれも満たされない場合、ラベルELSEが起こる遷移を示し（状態から他のすべての可能な終了条件がFALSEに評価された場合、すなわち、ELSE TRUEと評価）。同時にTRUEになる優先順位の同じレベルを持つ場合二つ以上の終了条件、終了条件は、状態遷移が起こるさせるようれた選択は任意です。
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> | ...
<変数> = <式1> | <式2> | ...
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.
この形式の文を実行すると、表現の正確に一つの値を持つ<変数>になります。実行されますこれらの表現の対象の論理は、ステートマシンの外であり、そのような方法と、環境設定、または別の状態機械に基づくことができます。
( )
（ ）
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.
NOT論理演算子。
&&
＆＆
Logical AND operator.
論理AND演算子。
||
｜｜
Logical OR operator.
論理OR演算子。
if...then...
そして...もし...
Conditional action. If the Boolean expression following the "if" evaluates to TRUE, then the action following the "then" is executed.
条件付きアクション。 「それから」実行され、次のTRUEと評価され、「場合」は、アクション以下のブール式は、If。
{ 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.
ビット単位のAND演算子。
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)
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にパケットを格納し、TRUEにeapReq信号を設定することにより、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（ブール値）
Set to TRUE in lower layer, FALSE in peer state machine. Indicates that a request is available in the lower layer.
ピア・ステート・マシンでFALSE、下層にTRUEに設定します。リクエストが下層に利用可能であることを示します。
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（ブール値）
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がDISABLEDにFALSE、ステートマシン遷移に設定されています。それはすぐに戻ってくるというリンクが一時的にしかダウンしていると信じているとするとき、不要なリセットを回避するために、下位層が指摘ダウンリンクを減衰させること（[RFC3748]のセクション7.12を参照してください）。この場合、portEnabledは常に下層の「リンクアップ」フラグに等しくなくてもよいです。
idleWhile (integer)
idleWhile（整数）
Outside timer used to indicate how much time remains before the peer will time out while waiting for a valid request.
外タイマーは有効な要求を待っている間に、ピアがタイムアウトするまでの残り時間を示すために使用されます。
eapRestart (boolean)
eapRestart（ブール値）
Indicates that the lower layer would like to restart authentication.
下位層が認証を再起動したいことを示します。
altAccept (boolean)
altAccept（ブール値）
Alternate indication of success, as described in [RFC3748].
[RFC3748]に記載されているように、成功の代替指標、。
altReject (boolean)
altReject（ブール値）
Alternate indication of failure, as described in [RFC3748].
[RFC3748]に記載されているように、障害の代替指標、。
eapResp (boolean)
eapResp（ブール値）
Set to TRUE in peer state machine, FALSE in lower layer. Indicates that a response is to be sent.
下層にFALSE、ピアステートマシンでTRUEに設定します。応答が送信されることを示します。
eapNoResp (boolean)
eapNoResp（ブール値）
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.
下層にFALSE、ピアステートマシンでTRUEに設定します。リクエストが処理されたことはなく、送信する応答がないことを示します。
eapSuccess (boolean)
eapSuccess（ブール値）
Set to TRUE in peer state machine, FALSE in lower layer. Indicates that the peer has reached the SUCCESS state.
下層にFALSE、ピアステートマシンでTRUEに設定します。ピアがSUCCESS状態に達したことを示します。
eapFail (boolean)
eapFail（ブール値）
Set to TRUE in peer state machine, FALSE in lower layer. Indicates that the peer has reached the FAILURE state.
下層にFALSE、ピアステートマシンでTRUEに設定します。ピアがFAILURE状態に達したことを示します。
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].
鍵材料が使用可能になったときに、ピア・ステート・マシンに設定してください。 METHOD状態の時に設定してください。この文書は、タイプ「EAPキー」の構造を定義していないことに注意してください。私たちは、それが[イング]で定義されることを期待しています。
eapKeyAvailable (boolean)
eapKeyAvailable（ブール値）
Set to TRUE in the SUCCESS state if keying material is available. The actual key is stored in eapKeyData.
材料をキーイングが利用可能な場合SUCCESS状態で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：この時点では、オーセンティケータは、メソッドを継続するか、会話を終了するかを決めることができます。決定変数は、会話が終了した場合に何をすべきかを教えてくれる。現在の状況は（オーセンティケータが、今のアクセスを許可することを決定した場合であること、ピアはそれを使用しません）ピアのセキュリティポリシーを満たさない場合は、= FAILを決定する設定。それ以外の場合は、意思決定= 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）私たちは、このオーセンティケータに話をして喜んじゃないことを私たちに伝えている場合（例えば、当社のセキュリティポリシーを満たしていない）、設定決定= FAIL。 （継続あれば、それは成功にピアの決定を変更することはできません、方法がまだ残って追加メッセージを持っている場合でも、この状態が発生する可能性があることに注意してください）。
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のいずれかである場合メソッドの仕様は、通知メッセージの使用を禁止していない場合、および、allowNotifications = TRUEを設定します。それ以外の場合は、allowNotifications =は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またはNONE。 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（ブール値）
Set in RECEIVED state. Indicates that the current received packet is an EAP request.
受信した状態で設定してください。現在の受信パケットがEAP要求であることを示します。
rxSuccess (boolean)
rxSuccess（ブール値）
Set in RECEIVED state. Indicates that the current received packet is an EAP Success.
受信した状態で設定してください。現在の受信パケットがEAP成功であることを示します。
rxFailure (boolean)
rxFailure（ブール値）
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)
（boolean）を無視します
Set in METHOD state. Indicates whether the method has decided to drop the current packet.
METHOD状態に設定してください。この方法は、現在のパケットをドロップすることを決定したかどうかを示します。
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.
アイデンティティ要求の内容を処理します。戻り値は未定義です。
buildIdentity()
buildIdentity（）
Create the appropriate identity response. Returns an EAP packet.
適切なアイデンティティ応答を作成します。 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
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
INITIALIZE
Initializes variables when the state machine is activated.
ステートマシンが起動されると、変数を初期化します。
IDLE
IDLE
The state machine spends most of its time here, waiting for something to happen.
ステートマシンは、何かが起こるのを待って、ここではそのほとんどの時間を費やしています。
RECEIVED
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.
メソッドの処理はここで起こります。オーセンティケータからのリクエストが処理され、適切な応答パケットが構築されています。
SEND_RESPONSE
SEND_RESPONSE
This state signals the lower layer that a response packet is ready to be sent.
この状態は、応答パケットを送信する準備ができている下層に信号を送ります。
DISCARD
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.
アイデンティティメソッドのリクエストを処理し、応答を構築します。
NOTIFICATION
通知
Handles requests for Notification method and builds a response.
通知方法の要求を処理し、応答を構築します。
RETRANSMIT
RETRANSMIT
Retransmits the previous response packet.
前回の応答パケットを再送します。
SUCCESS
成功
A final state indicating success.
成功を示す最終状態。
FAILURE
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)
Figure 4: EAP Stand-Alone Authenticator State Machine
図4：EAPは、スタンドアロン認証ステートマシン
5.1. Interface between Stand-Alone Authenticator State Machine and Lower Layer
5.1. スタンドアロン認証ステートマシンと下層との間のインターフェイス
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にパケットを格納し、TRUEにeapResp信号を設定することによって、EAP認証ステートマシンにメッセージを提示します。
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認証ステートマシンがメッセージの処理を終了したとき、それは、信号eapReq、eapNoReq、eapSuccess、及びeapFailのいずれかを設定します。それはeapReq、eapSuccess、又はeapFailを設定した場合、対応する要求（または成功/失敗）パケットがeapReqDataに格納されています。下の層は、実際にこのメッセージを送信するための責任があります。
eapResp (boolean)
eapResp（ブール値）
Set to TRUE in lower layer, FALSE in authenticator state machine. Indicates that an EAP response is available for processing.
認証マシンでFALSE、下層にTRUEに設定します。 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（ブール値）
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認証ステートマシンが通信のための準備ができている必要があることを示します。 EAPの会話が下位層によって開始されたときにこれがTRUEに設定されています。任意の時点で通信ポートまたはセッションが使用できない場合、portEnabledがDISABLEDにFALSE、ステートマシン遷移に設定されています。それはすぐに戻ってくるというリンクが一時的にしかダウンしていると信じているとするとき、不要なリセットを回避するために、下位層が指摘ダウンリンクを減衰させること（[RFC3748]のセクション7.12を参照してください）。この場合、portEnabledは常に下層の「リンクアップ」フラグに等しくなくてもよいです。
retransWhile (integer)
retransWhile（整数）
Outside timer used to indicate how long the authenticator has waited for a new (valid) response.
外タイマーは、オーセンティケータは、新たな（有効な）応答を待っている時間の長さを示すために使用します。
eapRestart (boolean)
eapRestart（ブール値）
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（ブール値）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that a new EAP request is ready to be sent.
下層にFALSE、認証マシンでTRUEに設定します。新しいEAP要求を送信する準備ができていることを示します。
eapNoReq (boolean)
eapNoReq（ブール値）
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.
下層にFALSE、認証マシンでTRUEに設定します。最新の応答が処理されたことを示しますが、送信するための新たな要求がありません。
eapSuccess (boolean)
eapSuccess（ブール値）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the SUCCESS state.
下層にFALSE、認証マシンでTRUEに設定します。ステートマシンがSUCCESS状態に達したことを示します。
eapFail (boolean)
eapFail（ブール値）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the FAILURE state.
下層にFALSE、認証マシンでTRUEに設定します。ステートマシンがFAILURE状態に達したことを示します。
eapTimeout (boolean)
eapTimeout（ブール値）
Set to TRUE in the TIMEOUT_FAILURE state if the authenticator has reached its maximum number of retransmissions without receiving a response.
オーセンティケータは、応答を受信せずに再送信の最大数に達した場合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に設定されている場合、認証マシンに設定してください。実際に送信される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].
鍵材料が使用可能になったときに認証マシンに設定してください。 METHOD状態の時に設定してください。この文書は、タイプ「EAPキー」の構造を定義していないことに注意してください。私たちは、それが[イング]で定義されることを期待しています。
eapKeyAvailable (boolean)
eapKeyAvailable（ブール値）
Set to TRUE in the SUCCESS state if keying material is available. The actual key is stored in eapKeyData.
材料をキーイングが利用可能な場合SUCCESS状態でTRUEに設定します。実際のキーはeapKeyDataに格納されます。
MaxRetrans (integer)
MaxRetrans（整数）
Configurable maximum for how many retransmissions should be attempted before aborting.
どのように多くの再送信のための設定可能な最大値は、中止する前に試みるべきです。
5.2. Interface between Stand-Alone Authenticator State Machine and Methods
5.2. スタンドアロン認証ステートマシンとメソッドの間のインタフェース
IN: eapRespData, methodState
以下の場合：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: -)
m.init（中： - 、アウト： - ）
When the method is first started, it must initialize its own method-specific state, possibly using some information from Policy (e.g., identity).
この方法は、最初に起動すると、それはおそらく政策（例えば、同一性）からいくつかの情報を使用して、独自のメソッド固有の状態を初期化する必要があります。
m.buildReq (in: integer, out: EAP packet)
（：整数、アウト：EAPパケット内の）m.buildReq
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)
m.getTimeout（中： - 、アウト：整数または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（中：EAPパケット、アウト：ブール）
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.process（中：EAPパケット、アウト： - ）
m.isDone (in: -, out: boolean)
m.isDone（中： - 、アウト：ブール）
m.getKey (in: -, out: EAP key or NONE)
m.getKey（中： - 、アウト：EAPキーまたは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タイプ、IDENTITY、または通知。
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またはNONE。通常PROPOSE_METHODの状態に更新しました。現在、未解決のEAP要求の識別子の値を示します。
methodState (enumeration)
methodState（列挙）
As described above.
上記のように。
retransCount (integer)
retransCount（整数）
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.
適切な再送タイムアウト、またはNONEのための方法が提供ヒント。
rxResp (boolean)
rxResp（ブール値）
Set in RECEIVED state. Indicates that the current received packet is an EAP response.
受信した状態で設定してください。現在の受信パケットがEAP応答であることを示します。
respId (integer)
respId（整数）
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)
（boolean）を無視します
Set in METHOD state. Indicates whether the method has decided to drop the current packet.
METHOD状態に設定してください。この方法は、現在のパケットをドロップすることを決定したかどうかを示します。
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.getNextメソッド（）
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（）EAP対話内の認証方法の配列の使用を禁止する[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.
ポリシーはSUCCESS、FAILを可能にするかどうかを決定し、又は（CONTINUE）を決定するためにまだあります。意思決定の列挙を返します。
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
DISABLED
The authenticator is disabled until the port is enabled by the lower layer.
ポートが下位レイヤで有効にされるまで、オーセンティケータは無効になっています。
INITIALIZE
INITIALIZE
Initializes variables when the state machine is activated.
ステートマシンが起動されると、変数を初期化します。
IDLE
IDLE
The state machine spends most of its time here, waiting for something to happen.
ステートマシンは、何かが起こるのを待って、ここではそのほとんどの時間を費やしています。
RECEIVED
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
DISCARD
This state signals the lower layer that the response was discarded, and no new request packet will be sent at this time.
この状態は、応答が破棄されたことを下位層に信号を送り、そして新たな要求パケットは、この時点で送信されません。
NAK
NAK
This state processes Nak responses from the peer.
この状態は、ピアからのNAK応答を処理します。
RETRANSMIT
RETRANSMIT
Retransmits the previous request packet.
前の要求パケットを再送します。
SUCCESS
成功
A final state indicating success.
成功を示す最終状態。
FAILURE
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).
パケットの通過部分、および実際にEAPメソッドを実装するバックエンド：パススルーモードで動作する場合、オーセンティケータには2つの部分は、概念的にあります。次の図は、AAAサーバを使用して、このモデルのバックエンド部分の状態マシンを示します。この図は、RADIUSと、再送信は、NASによって処理されているので何ら再送がIDLE状態に含まれていないことを除いて図4と同一であることに留意されたいです。また、INITIALIZE状態でPICK_UP_METHOD状態と変数は、メソッドは、メソッドがNASに始まった「拾う」できるようにするために追加されます。上記と同じである多くは図中で参照プリミティブおよび手順の説明が含まれます。この場合の「下層」は、いくつかのAAAプロトコル（例えば、RADIUS）であることに留意されたいです。
(see the .pdf version for missing diagram or
refer to Appendix A.3 if reading the .txt version)
Figure 5: EAP Backend Authenticator State Machine
図5：EAPバックエンド認証ステートマシン
6.1. Interface between Backend Authenticator State Machine and Lower Layer
6.1. バックエンド認証ステートマシンと下層との間のインターフェイス
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.
下層aaaEapRespDataにパケットを格納し、TRUEにaaaEapResp信号を設定することにより、EAPバックエンド認証ステートマシンにメッセージを提示します。
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バックエンド認証ステートマシンがメッセージの処理を終了したとき、それは、信号aaaEapReq、aaaEapNoReq、aaaSuccess、及びaaaFailのいずれかを設定します。それはeapReq、eapSuccess、又はeapFailを設定した場合、対応する要求（または成功/失敗）パケットがaaaEapReqDataに格納されています。下の層は、実際にこのメッセージを送信するための責任があります。
aaaEapResp (boolean)
aaaEapResp（ブール値）
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.
認証マシンでFALSE、下層にTRUEに設定します。通常aaaEapRespDataに格納されたEAP応答は、AAAサーバによる処理のために利用可能であることを示しています。 aaaEapRespDataがNONEに設定されている場合は、AAAサーバが初期のEAP要求を送信する必要があることを示します。
aaaEapRespData (EAP packet)
aaaEapRespData（EAPパケット）
Set in lower layer when eapResp is set to TRUE. The EAP packet to be processed, or NONE.
eapRespがTRUEに設定されている下層に設定してください。 EAPの処理されるべきパケット、またはNONE。
backendEnabled (boolean)
backendEnabled（ブール値）
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はDISABLEDにFALSE、およびステート・マシンの遷移に設定されています。
aaaEapReq (boolean)
aaaEapReq（ブール値）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that a new EAP request is ready to be sent.
下層にFALSE、認証マシンでTRUEに設定します。新しいEAP要求を送信する準備ができていることを示します。
aaaEapNoReq (boolean)
aaaEapNoReq（ブール値）
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.
下層にFALSE、認証マシンでTRUEに設定します。最新の応答が処理されたことを示しますが、送信するための新たな要求がありません。
aaaSuccess (boolean)
aaaSuccess（ブール値）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the SUCCESS state.
下層にFALSE、認証マシンでTRUEに設定します。ステートマシンがSUCCESS状態に達したことを示します。
aaaFail (boolean)
aaaFail（ブール値）
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the FAILURE state.
下層にFALSE、認証マシンでTRUEに設定します。ステートマシンがFAILURE状態に達したことを示します。
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に設定されている場合、認証マシンに設定してください。実際に送信される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（ブール値）
Set to TRUE in the SUCCESS state if keying material is available. The actual key is stored in aaaEapKeyData.
材料をキーイングが利用可能な場合SUCCESS状態で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.)
適切な再送タイムアウト、またはNONEのための方法が提供ヒント。 （このヒントはないAAAパケットの再送信のために、パススルー認証によって行わEAP再送信のためのものであることに注意してください。）
6.2. Interface between Backend Authenticator State Machine and Methods
6.2. バックエンド認証ステートマシンとメソッドの間のインタフェース
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 Requestパケットをパススルーによって送信されましたが、バックエンドは、対応するEAP応答を処理する必要があります。通常、唯一のアイデンティティメソッドはこれをサポートしていますが、他のものが可能です。
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-TLSが良い例です。）
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.
最初の図は、主にPASSTHROUGHモードへの移行のための追加フックと上記見られるの再生です。
(see the .pdf version for missing diagram or
refer to Appendix A.4 if reading the .txt version)
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)
Figure 7: EAP Full Authenticator State Machine (Part 2)
図7：EAP完全認証ステートマシン（その2）
7.1. Interface between Full Authenticator State Machine and Lower Layers
7.1. 完全な認証ステートマシンと下位層の間のインタフェース
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].
フルオーセンティケータは、パススルーモードをサポートするために、複数の下位層へのそのインタフェースに固有です。以下はAAAへのインタフェースを表す第二の下層へのインタフェースを記述するセクション5に記載されているように、一次EAPトランスポート層へのインタフェースは同じです。 [1X-2004]の場合のように、必ずしもEAP層とAAA層との間の直接的な相互作用がないことに留意されたいです。
aaaEapReq (boolean)
aaaEapReq（ブール値）
Set to TRUE in lower layer, FALSE in authenticator state machine. Indicates that a new EAP request is available from the AAA server.
認証マシンでFALSE、下層にTRUEに設定します。新しいEAP要求がAAAサーバから利用可能であることを示します。
aaaEapNoReq (boolean)
aaaEapNoReq（ブール値）
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.
認証マシンでFALSE、下層にTRUEに設定します。最新の応答が処理されたことはなく、送信するための新たな要求がないことを示します。
aaaSuccess (boolean)
aaaSuccess（ブール値）
Set to TRUE in lower layer. Indicates that the AAA backend authenticator has reached the SUCCESS state.
下層にTRUEに設定します。 AAAのバックエンドのオーセンティケータがSUCCESS状態に達したことを示します。
aaaFail (boolean)
aaaFail（ブール値）
Set to TRUE in lower layer. Indicates that the AAA backend authenticator has reached the FAILURE state.
下層にTRUEに設定します。 AAAのバックエンドのオーセンティケータがFAILURE状態に達したことを示します。
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（ブール値）
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.)
適切な再送タイムアウト、またはNONEのための方法が提供ヒント。 （このヒントはないAAAパケットの再送信のために、パススルー認証によって行わEAP再送信のためのものであることに注意してください。）
aaaEapResp (boolean)
aaaEapResp（ブール値）
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.
認証マシンでtrueに設定、下層にFALSE。 EAP応答は、AAAサーバによって処理のために利用可能であることを示します。
aaaEapRespData (EAP packet)
aaaEapRespData（EAPパケット）
Set in authenticator state machine when eapResp is set to TRUE. The EAP packet to be processed.
eapRespがTRUEに設定されている場合、認証マシンに設定してください。 EAPパケットを処理します。
aaaIdentity (EAP packet)
aaaIdentity（EAPパケット）
Set in authenticator state machine when an IDENTITY response is received. Makes that identity available to AAA lower layer.
IDENTITYレスポンスを受信したときに認証マシンに設定してください。 AAAにそのIDを使用できるようになり、下位層。
aaaTimeout (boolean)
aaaTimeout（ブール値）
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層は生きているとOKが、それは、有効なアクセス-受け入れ/バックエンドからの指示を拒否を受信していない何らかの理由そのものです。
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
INITIALIZE 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
IDLE
The state machine spends most of its time here, waiting for something to happen.
ステートマシンは、何かが起こるのを待って、ここではそのほとんどの時間を費やしています。
RECEIVED2
RECEIVED2
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
DISCARD2
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
SUCCESS2
A final state indicating success.
成功を示す最終状態。
FAILURE2
FAILURE2
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.
応答が受信されなかったため失敗したことを示す最終状態。応答が受信されなかったため、（失敗を含む）は、新しいメッセージがピアに送信されるべきではありません。このメッセージを示す障害がピアに送信されたFAILURE2状態とは異なることに留意されたいです。
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を取得するために必要とされるアイデンティティ要求を処理するためにいくつかの時間がかかることがあります。ユーザーは決して入力のアイデンティティがあります。 ClientTimeoutタイマが満了する前に、何もアイデンティティがユーザから取得されていない場合、認証は失敗することができるような実装は、故障状態にIDENTITY状態から追加の状態遷移を定義することができます。
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.
オーセンティケータステートマシンでのピア状態のマシンでとMETHOD_RESPONSE状態でO方式状態。これは、これらの状態でメソッド固有の手順を実行するには時間がかかる場合があります。 methodTimeoutタイマが満了する前に、何方法の処理結果は、方法から得られない場合、認証は失敗することができるので、実装が失敗またはTIMEOUT_FAILURE状態にMETHOD状態とMETHOD_RESPONSE状態から追加の状態遷移を定義することができます。
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.
展開EAP認証の実装の数は、主にRADIUS認証サーバに、RFC 3748のセクション4.2でMUST要件に反している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-要求/応答アイデンティティ2. EAP応答/ NAK 3. EAP-成功/失敗
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仕様に続いて、攻撃者はによりサービス拒否を引き起こす可能性があります。ピアは、EAP認証方式を開始する前にピアにEAP-失敗を送信O。限り、ピアは（NONEに初期化）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.
それはEAP認証方式を開始した前に、無限のEAP要求/応答アイデンティティ交換に従事するためにピアを強制O。限りピアが（NONEに初期化）selectedMethod変数を変更していないとして、ピアはEAP要求/アイデンティティを受け入れ、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.
オーセンティケータの後にオーセンティケータにNAKを送信oを最初のピアにEAP認証方式を提案します。 methodState変数提案値を有する場合、オーセンティケータは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設計チームの一部として行われました。それはニックペトローニ、ジョンVollbrecht、パシEronen、および義弘大場によって主に行われていました。ニックは、メリーランド大学のブライアン・ペインとチュク・センでこの仕事を始めました。集会所データ通信のジョンVollbrechtは、インターリンクNetworksのデイブ・スペンスからの助けを借りて独立して始めました。ジョンとニックは、共通の文書を作成するために協力して、コヒーレントステートマシンを作成する際に大きな貢献をしてきたノキアのパシEronen、が加わった、とパススルードキュメントを含むことを主張し、重要なサポートを提供し、東芝の義弘大場、によって実装上の問題を理解するため。
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.
また、有意な応答との会話は、デザインチーム、特にエリクソンのヤリArkkoとマイクロソフトのバーナードAboba、だけでなく、チームの残りの部分から来ています。また、IEEE 802.1によって検討されてきた、と集会所のジム・バーンズとヒューレット・パッカードのポールコングドンからの入力がありました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.カルフーン、 "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.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（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.
【キーイング] Aboba、B.、サイモン、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.
電気電子技術者の[1X-2004]研究所、「ローカルおよびメトロポリタンエリアネットワークの標準：ポートベースのネットワークアクセス制御」、IEEE 802.1X-2004、2004年12月。
Appendix A. ASCII versions of state diagrams
状態図の付録A.のASCIIバージョン
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.
次のように表記がある：それは左側に示されている入力するときの状態名と疑似コードを実行します。その条件と出力遷移が右側に表示されます。
A.1. EAP Peer State Machine (Figure 3)
A.1。 EAPピアステートマシン（図3）
---------------------------------------------------------------------
(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
A.2. EAP Stand-Alone Authenticator State Machine (Figure 4)
A.2。 EAPは、スタンドアロン認証ステートマシン（図4）
---------------------------------------------------------------------
(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
A.3. EAP Backend Authenticator State Machine (Figure 5)
A.3。 EAPバックエンド認証ステートマシン（図5）
---------------------------------------------------------------------
(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
A.4. EAP Full Authenticator State Machine (Figures 6 and 7)
A.4。 EAP完全認証ステートマシン（図6および7）
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
ジョンVollbrecht集会所データ・コミュニケーションズ9682アリスの丘ドライブデクスター、MI 48130 USA
EMail: jrv@mtghouse.com
メールアドレス：jrv@mtghouse.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group, Finland
ノキア・リサーチセンター私書箱のパシEronenボックス407 FIN-00045ノキアグループ、フィンランド
EMail: pasi.eronen@nokia.com
メールアドレス：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.ウィリアムズビルカレッジパーク、MD 20742 USA
EMail: npetroni@cs.umd.edu
メールアドレス：npetroni@cs.umd.edu
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
義弘大場東芝アメリカリサーチ社1のTelcordiaドライブピスカタウェイ、NJ 08854 USA
EMail: yohba@tari.toshiba.com
メールアドレス：yohba@tari.toshiba.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。