RFC4137 日本語訳
4137 State Machines for Extensible Authentication Protocol (EAP) Peerand Authenticator. J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba. August 2005. (Format: TXT=105781, PDF=107470 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Vollbrechtがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4137年の公会堂データ通信カテゴリ: 情報のP.のペトローニメリーランド大学Y.オオバタリEronenノキアN.2005年8月
State Machines for Extensible Authentication Protocol (EAP)
Peer and Authenticator
拡張認証プロトコル(EAP)同輩と固有識別文字のための州のマシン
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes a set of state machines for Extensible Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.
このドキュメントは拡張認証プロトコル(EAP)同輩、EAPのスタンドアロンの固有識別文字(非パスの)、EAPバックエンド固有識別文字(Authentication、Authorization、およびAccounting(AAA)サーバにおける使用のための)、およびEAPの完全な固有識別文字(両方における地方の、そして、パス突き抜けている)のために1セットの州のマシンについて説明します。 このセットの州のマシンは同輩/固有識別文字か同輩/固有識別文字/AAA Server環境のどちらかにおける展開をサポートするためにどうEAPを実装することができるかを示しています。 RFC3748で定義されたEAPプロトコルがどう実装されるかもしれないかに同輩とスタンドアロンの固有識別文字マシンは説明に役立っています。 バックエンドと完全であるかパス終えた固有識別文字はRFC3579で定義されたEAP/AAAプロトコルサポートがどう実装されるかもしれないかを例証します。 違いがあるところでは、RFC3748とRFC3579は正式です。
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 SwitchとEAPメソッドとの相互作用のためのイベントと動作を入れます。 Introduction部でEAP「スイッチ」モデルの簡単な説明を与えます。
The state machine and associated model are informative only. Implementations may achieve the same results using different methods.
州のマシンの、そして、関連しているモデルは有益です。単に。 実装は、異なったメソッドを使用することで同じ結果を獲得するかもしれません。
Vollbrecht, et al. Informational [Page 1] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[1ページ]のRFC4137EAP州は2005年8月を機械加工します。
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
1. 序論: EAPはモデルを切り換えます…3 2. 要件の仕様…4 3. 記号法のコンベンションは状態でダイヤグラムを使用しました…5 3.1. 記号法の詳細…5 3.2. マシンシンボルを述べてください…7 3.3. 権威を記録してください…8 4. 同輩州のマシン…9 4.1. 同輩州のマシンと下層の間で連結してください…9 4.2. 同輩州のマシンとメソッドの間で連結してください…11 4.3. 同輩州のマシン局所変数…13 4.4. 同輩州のマシン手順…14 4.5. 同輩州のマシン州…15 5. スタンドアロンの固有識別文字州のマシン…17 5.1. スタンドアロンの固有識別文字州のマシンと下層の間で連結してください…17 5.2. スタンドアロンの固有識別文字州のマシンとメソッドの間で連結してください…19 5.3. スタンドアロンの固有識別文字州のマシン局所変数…21 5.4. EAPのスタンドアロンの固有識別文字手順…22 5.5. EAPのスタンドアロンの固有識別文字州…24 6. EAPバックエンド固有識別文字…26 6.1. バックエンド固有識別文字州のマシンと下層の間で連結してください…26 6.2. バックエンド固有識別文字州のマシンとメソッドの間で連結してください…28 6.3. バックエンド固有識別文字州のマシン局所変数…28 6.4. EAPバックエンド固有識別文字手順…28 6.5. EAPバックエンド固有識別文字州…29 7. EAPの完全な固有識別文字…29 7.1. 完全な固有識別文字州のマシンと下層の間で連結してください…30 7.2. 完全な固有識別文字州のマシンとメソッドの間で連結してください…31 7.3. 完全な固有識別文字州のマシン局所変数…32 7.4. EAPの完全な固有識別文字手順…32 7.5. EAPの完全な固有識別文字州…32 8. 実装問題…34 8.1. 丈夫さ…34 8.2. メソッド/メソッドとメソッド/下層は連結します…35 8.3. 配布している実装がある同輩州のマシン相互運用性…35 9. セキュリティ問題…35 10. 承認…36 11. 参照…37 11.1. 標準の参照…37 11.2. 有益な参照…37
Vollbrecht, et al. Informational [Page 2] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[2ページ]のRFC4137EAP州は2005年8月を機械加工します。
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
付録。 州のダイヤグラムのASCIIバージョン…38 A.1。 EAP同輩州のマシン(図3)…38 A.2。 EAPのスタンドアロンの固有識別文字州のマシン(図4)。41 A.3。 EAPバックエンド固有識別文字州のマシン(図5)…44 A.4。 EAPの完全な固有識別文字州のマシン(数字6と7)。47
1. Introduction: The EAP Switch Model
1. 序論: EAPスイッチモデル
This document offers a proposed state machine for RFCs [RFC3748] and [RFC3579]. There are state machines for the peer, the stand-alone authenticator, a backend authenticator, and a full/pass-through authenticator. Accompanying each state machine diagram is a description of the variables, the functions, and the states in the diagram. Whenever possible, the same notation has been used in each of the state machines.
このドキュメントはRFCs[RFC3748]と[RFC3579]のために提案された州のマシンを提供します。 同輩、スタンドアロンの固有識別文字、バックエンド固有識別文字、および完全であるかパス終えた固有識別文字のための州のマシンがあります。 それぞれの州のマシンダイヤグラムに伴うのは、ダイヤグラムによる変数、機能、および州の記述です。 可能で、同じ記法がそれぞれの州のマシンで使用されたときはいつも。
An EAP authentication consists of one or more EAP methods in sequence followed by an EAP Success or EAP Failure sent from the authenticator to the peer. The EAP switches control negotiation of EAP methods and sequences of methods.
EAP認証はEAP Successによって連続して従われた1つ以上のEAPメソッドか固有識別文字から同輩に送られたEAP Failureから成ります。 EAPはEAPメソッドのコントロール交渉とメソッドの系列を切り換えます。
Peer Peer | Authenticator Auth
Method | Method
\ | /
\ | /
Peer | Auth
EAP <-----|----------> EAP
Switch | Switch
同輩同輩| 固有識別文字Authメソッド| メソッド、\| / \ | /同輩| Auth EAP<。-----|---------->EAPスイッチ| スイッチ
Figure 1: EAP Switch Model
図1: EAPスイッチモデル
At both the peer and authenticator, one or more EAP methods exist. The EAP switches select which methods each is willing to use, and negotiate between themselves to pick a method or sequence of methods.
同輩と固有識別文字の両方では、1つ以上のEAPメソッドが存在しています。 EAPスイッチはメソッドのメソッドか系列を選ぶために自分たちの間でどのメソッドを使用して、交渉するかを構わないそれぞれが、思っている選択します。
Note that the methods may also have state machines. The details of these are outside the scope of this paper.
また、メソッドには州のマシンがあるかもしれないことに注意してください。 この紙の範囲の外にこれらの詳細があります。
Vollbrecht, et al. Informational [Page 3] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[3ページ]のRFC4137EAP州は2005年8月を機械加工します。
Peer | Authenticator | Backend
| / Local |
| / Method |
Peer | Auth | Backend
EAP -|-----> EAP | --> EAP
Switch | Switch | / Server
| \ | /
| \ pass-through |
| |
同輩| 固有識別文字| バックエンド| /地方です。| | /メソッド| 同輩| Auth| バックエンドEAP、-|----->EAP| -->EAPスイッチ| スイッチ| /サーバ| \ | / | \通じて通ります。| | |
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.
認証方法があるバックエンドサーバへの通じてFull/通り州のマシンがNASか渡すエッジデバイスを許容するEAP Responseメッセージ。 この紙は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認証に対処できる1セットの州のマシンについて説明します。
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.
EAPがPPPなどのように使用されるいくつかの環境が同輩への操作を同輩にサポートするかもしれません。 すなわち、双方は同時に、同輩と固有識別文字として2つの同時の、そして、独立しているEAPの会話で機能します。 この場合、各ノードの実装は入って来るEAPパケットの逆多重化を実行しなければなりません。 Responseに設定されたコードがあるEAPパケットは固有識別文字州のマシンに提供されます、そして、Request、Success、またはFailureに設定されたコードがある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]のAppendix Fで説明されます。
2. Specification of Requirements
2. 要件の仕様
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
Vollbrecht, et al. Informational [Page 4] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[4ページ]のRFC4137EAP州は2005年8月を機械加工します。
3. Notational Conventions Used in State Diagrams
3. 州のダイヤグラムで使用される記号法のコンベンション
3.1. Notational Specifics
3.1. 記号法の詳細
The following state diagrams have been completed based on the conventions specified in [1X-2004], section 8.2.1. The complete text is reproduced here:
以下の州のダイヤグラムは[1X-2004]、セクション8.2.1で指定されたコンベンションに基づいて完成しました。 全文はここで再生します:
State diagrams are used to represent the operation of the protocol
by a number of cooperating state machines, each comprising a group
of connected, mutually exclusive states. Only one state of each
machine can be active at any given time.
州のダイヤグラムは州が機械加工する多くの協力によるプロトコルの操作を表すのに使用されます、それぞれ接続されて、互いに唯一の州のグループを包括して。 それぞれのマシンの1つの州だけがその時々で活動的である場合があります。
Each state is represented in the state diagram as a rectangular
box, divided into two parts by a horizontal line. The upper part
contains the state identifier, written in uppercase letters. The
lower part contains any procedures that are executed upon entry to
the state.
各状態は水平な線によって2つの部品に分割された長方形の箱として州のダイヤグラムで表されます。 上部は大文字に書かれた州の識別子を含んでいます。 下部はエントリーのときに状態に実行されるどんな手順も含んでいます。
All permissible transitions between states are represented by
arrows, the arrowhead denoting the direction of the possible
transition. Labels attached to arrows denote the condition(s)
that must be met in order for the transition to take place. All
conditions are expressions that evaluate to TRUE or FALSE; if a
condition evaluates to TRUE, then the condition is met. The label
UCT denotes an unconditional transition (i.e., UCT always
evaluates to TRUE). A transition that is global in nature (i.e.,
a transition that occurs from any of the possible states if the
condition attached to the arrow is met) is denoted by an open
arrow; i.e., no specific state is identified as the origin of the
transition. When the condition associated with a global
transition is met, it supersedes all other exit conditions
including UCT. The special global condition BEGIN supersedes all
other global conditions, and once asserted it remains asserted
until all state blocks have executed to the point that variable
assignments and other consequences of their execution remain
unchanged.
州の間のすべての許されている変遷が矢、可能な変遷の方向を指示する矢尻によって表されます。 矢に取り付けられたラベルは変遷が行われるために満たされなければならない条件を指示します。 すべての状態がそれがTRUEかFALSEに評価する式です。 状態はaであるなら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
状態へのエントリーでは、状態(もしあれば)と定義された手順がまさに一度実行されます、それらがページで見えるオーダーで。 各動作が原子であると考えられます。 すなわち、手順の実行は次の連続した手順の前に実行する始めを終了します。 どんな手順も外で州のブロックを実行しません。 1だけの手順は、異なった州のマシンの州のブロックの実行のための状態が満たされてもブロックが一度に、実行して、実行状態のすべての手順が変遷の前の完全な実行を妨げると述べます、そして、いかなる他の州のブロックの実行も起こります。 すなわち、どんな状態の実行
Vollbrecht, et al. Informational [Page 5] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[5ページ]のRFC4137EAP州は2005年8月を機械加工します。
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.
州の中のすべての手順の完成のときに、状態の1つが会われるまで、状態(グローバルな変遷に関連しているすべての状態を含んでいる)のためのすべての出口状態が絶え間なく評価されます。 ラベルELSEが状態からの変遷のための他の状態のいずれも満たされないなら起こる変遷を指示する、(すなわち、ELSEが、可能なすべてのもう一方が状態からの状態を出るかどうかTRUEに評価する、FALSEに関する評価、) 同じレベルの先行がある2つ以上の出口状態が同時に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.
1個以上のダイヤグラムの向こう側に州のマシン記述を分けるのが必要であるところでは、異なったダイヤグラムで現れる2つの州の間の変遷は投げつけられた系列で引き起こされた出口矢、および目的地州を含むダイヤグラムの参照で表されます。 同様に、投げつけられた矢と投げつけられた州の箱は、目的地州への変遷を示しているのに目的地ダイヤグラムの上で使用されます。 このように分けられた州のマシンでは、ダイヤグラムの1つで定義された州にエントリーを引き起こす場合があるどんなグローバルな変遷も州のマシンのすべての州のための潜在的出口状態であると考えられます、州の箱がどのダイヤグラムで現れるかにかかわらず。
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/IEC14882の記法からこれらのシンボルとオペレータを得ます。 または、ブール変数がこの節で設定されると説明されるなら、説明される、値の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:
上の記法に加えて、このドキュメントに特定の2、3の明確化があります。 まず最初に、州のマシン実行が始まる前にすべてのブール変数がFALSEに初期化されます。 2番目に、以下の記号法の速記はこのドキュメントに特定です:
Vollbrecht, et al. Informational [Page 6] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[6ページ]のRFC4137EAP州は2005年8月を機械加工します。
<variable> = <expression1> | <expression2> | ...
<の可変>は<expression1>と等しいです。| <expression2>。| ...
Execution of a statement of this form will result in <variable>
having a value of exactly one of the expressions. The logic for
which of those expressions gets executed is outside of the state
machine and could be environmental, configurable, or based on
another state machine, such as that of the method.
このフォームの声明の実行はちょうど式の1つの値を持っている<の可変>をもたらすでしょう。 それらの式のどれが実行されるか論理は、州のマシンの外にあって、環境であって、構成可能であり、別の州のマシンに基づくことができました、メソッドのものなどのように。
3.2. State Machine Symbols
3.2. 州のマシンシンボル
( )
( )
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.
課題動作。 オペレータの右への式の値はオペレータの左への変数に割り当てられます。 このオペレータが複数の課題を定義するのに使用されるなら(例えば=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.
条件付きの動き。 “if"に続くとTRUE、当時の「当時」に続く動作に評価される論理式が実行されるなら。
Vollbrecht, et al. Informational [Page 7] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[7ページ]のRFC4137EAP州は2005年8月を機械加工します。
{ 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.
Bitwiseする、ANDオペレータ。
3.3. Document Authority
3.3. ドキュメント権威
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]など)のどれかの間にも起こると、後者(もう片方のドキュメント)は、正式であると考えられて、優先します。
Vollbrecht, et al. Informational [Page 8] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[8ページ]のRFC4137EAP州は2005年8月を機械加工します。
4. Peer State Machine
4. 同輩州のマシン
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)
(.txtバージョンを読むなら、消えるための.pdfバージョンがAppendix A.1について図解するか、または言及するのを見ます)
Figure 3: EAP Peer State Machine
図3: EAP同輩州のマシン
4.1. Interface between Peer State Machine and Lower Layer
4.1. 同輩州のマシンと下層の間で連結してください。
The lower layer presents messages to the EAP peer state machine by storing the packet in eapReqData and setting the eapReq signal to TRUE. Note that despite the name of the signal, the lower layer does not actually inspect the contents of the EAP packet (it could be a Success or Failure message instead of a Request).
下層は、eapReqDataにパケットを保存して、eapReq信号をTRUEに設定することによって、EAP同輩州のマシンにメッセージを提示します。 信号の名前にもかかわらず、下層が実際にEAPパケットのコンテンツを点検しないことに注意してください(それはSuccessであるかもしれませんかFailureはRequestの代わりにメッセージです)。
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に認証が成功するか、または失敗したのを下層に示すように設定するでしょう。
4.1.1. Variables (Lower Layer to Peer)
4.1.1. 変数(じっと見る下層)
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
EAP同輩州のマシンがコミュニケーションの準備ができるべきであるのを示します。 EAPの会話が下層によって始められるとき、これはTRUEに設定されます。 COMポートかセッションが任意な点で利用可能でないなら、portEnabledはFALSE、およびDISABLEDへの州のマシン変遷に用意ができています。 リンクが一時下にだけあって、そうするのが信じているとき、不要なリセットを避けるために、下層は指摘の下側にリンクを湿らせるかもしれません。
Vollbrecht, et al. Informational [Page 9] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[9ページ]のRFC4137EAP州は2005年8月を機械加工します。
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.
すぐ、上がった状態で([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]で説明されるような失敗の代替のしるし。
4.1.2. Variables (peer to lower layer)
4.1.2. 変数(下層への同輩)
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状態に着いたのを示します。
Vollbrecht, et al. Informational [Page 10] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[10ページ]のRFC4137EAP州は2005年8月を機械加工します。
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に保存されます。
4.1.3. Constants
4.1.3. 定数
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).
中止になる前の実装特有によって初期化された有効な要求を待つ構成可能な時間は(例えば、構成設定)を意味します。
4.2. Interface between Peer State Machine and Methods
4.2. 同輩州のマシンとメソッドの間で連結してください。
IN: eapReqData (includes reqId)
中: eapReqData(reqIdを含んでいます)
OUT: ignore, eapRespData, allowNotifications, decision
出かける: 無視、eapRespData、allowNotifications、決定
IN/OUT: methodState, (method-specific state)
IN/出かける: 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.
メソッドが、パケットを処理すると決めるなら、それは以下の通り反応します。
Vollbrecht, et al. Informational [Page 11] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[11ページ]のRFC4137EAP州は2005年8月を機械加工します。
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: メソッドはここにいつも続きます(同輩はそれを続けたがっています)。 決定変数はいつもFAILに設定されます。
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は5月_CONTと等しいです: ここに、固有識別文字は、メソッドを続けているか、または会話を終わらせると決めることができます。 会話が終わるなら、決定変数は、何をしたらよいかを私たちに言います。 現在の状況が同輩の安全保障政策を満たさないなら(すなわち、固有識別文字が、現在アクセスを許すと決めると、同輩はそれを使用しないでしょう)、決定=FAILを設定してください。 さもなければ、決定=COND_SUCCを設定してください。
methodState=DONE: The method never continues at this point (or the
peer sees no point in continuing it).
行われたmethodState=: メソッドはここに決して続きません(同輩はそれを続ける意味が全くわかりません)。
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.
(b) (a) 両方であるなら、サーバは、アクセスを許すと私たちにお知らせくださいました、そして、次のパケットはEAP Successになるでしょう、そして、私たちはこのアクセスを使用します、セット決定=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変数を設定しなければなりません。 メソッド仕様がNotificationメッセージの使用を禁じないなら、新しいmethodStateがCONTか5月_CONTのどちらかであるなら、allowNotifications=TRUEを設定してください。 さもなければ、allowNotifications=FALSEを設定してください。
Vollbrecht, et al. Informational [Page 12] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[12ページ]のRFC4137EAP州は2005年8月を機械加工します。
4.3. Peer State Machine Local Variables
4.3. 同輩州のマシン局所変数
4.3.1. Long-Term (Maintained between Packets)
4.3.1. 長期(パケットの間で維持されます)
selectMethod (EAP type)
selectMethod(EAPタイプ)
Set in GET_METHOD state. The method that the peer believes is
currently "in progress"
GET_METHOD状態にセットしてください。 同輩が現在「進行中である」と信じているメソッド
methodState (enumeration)
methodState(列挙)
As described above.
上で説明されるように。
lastId (integer)
lastId(整数)
0-255 or NONE. Set in SEND_RESPONSE state. The EAP identifier
value of the last request.
0-255かなし。 SEND_RESPONSE状態にセットしてください。 最後の要求のEAP識別子価値。
lastRespData (EAP packet)
lastRespData(EAPパケット)
Set in SEND_RESPONSE state. The EAP packet last sent from the
peer.
SEND_RESPONSE状態にセットしてください。 EAPパケットは最後に同輩から発信しました。
decision (enumeration)
決定(列挙)
As described above.
上で説明されるように。
NOTE: EAP type can be normal type (0..253,255), or an extended type consisting of type 254, Vendor-Id, and Vendor-Type.
以下に注意してください。 EAPタイプは、正常体型(0..253、255)か、タイプ254から成る拡張タイプと、Vendor-イドと、Vendor-タイプであるかもしれません。
4.3.2. Short-Term (Not Maintained between Packets)
4.3.2. 短期的(パケットの間で維持されません)
rxReq (boolean)
rxReq(論理演算子)
Set in RECEIVED state. Indicates that the current received packet
is an EAP request.
RECEIVED状態にセットしてください。 現在の容認されたパケットがEAP要求であることを示します。
rxSuccess (boolean)
rxSuccess(論理演算子)
Set in RECEIVED state. Indicates that the current received packet
is an EAP Success.
RECEIVED状態にセットしてください。 現在の容認されたパケットがEAP Successであることを示します。
rxFailure (boolean)
rxFailure(論理演算子)
Set in RECEIVED state. Indicates that the current received packet
is an EAP Failure.
RECEIVED状態にセットしてください。 現在の容認されたパケットがEAP Failureであることを示します。
Vollbrecht, et al. Informational [Page 13] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[13ページ]のRFC4137EAP州は2005年8月を機械加工します。
reqId (integer)
reqId(整数)
Set in RECEIVED state. The identifier value associated with the
current EAP request.
RECEIVED状態にセットしてください。 現在のEAP要求に関連している識別子値。
reqMethod (EAP type)
reqMethod(EAPタイプ)
Set in RECEIVED state. The method type of the current EAP
request.
RECEIVED状態にセットしてください。 現在のEAP要求のメソッドタイプ。
ignore (boolean)
無視します。(論理演算子)
Set in METHOD state. Indicates whether the method has decided to
drop the current packet.
METHOD状態にセットしてください。 メソッドが、現在のパケットを下げると決めたか否かに関係なく、示します。
4.4. Peer State Machine Procedures
4.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によるメソッドに提供されました。 メソッドの内部の州によって提供されたそれらの入力は暗黙のままです。
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の値は未定義であるかもしれません。 論理演算子、1つの整数、および1EAPがタイプするリターンthree。
processNotify()
processNotifyします。()
Process the contents of Notification Request (for instance,
display it to the user or log it). The return value is undefined.
Notification Requestのコンテンツを処理してください(例えば、ユーザにそれを表示するか、またはそれを登録してください)。 リターン値は未定義です。
buildNotify()
buildNotifyします。()
Create the appropriate notification response. Returns an EAP
packet.
適切な通知応答を作成してください。 EAPパケットを返します。
processIdentity()
processIdentity()
Process the contents of Identity Request. Return value is
undefined.
Identity Requestのコンテンツを処理してください。 リターン値は未定義です。
Vollbrecht, et al. Informational [Page 14] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[14ページ]のRFC4137EAP州は2005年8月を機械加工します。
buildIdentity()
buildIdentity()
Create the appropriate identity response. Returns an EAP packet.
適切なアイデンティティ応答を作成してください。 EAPパケットを返します。
m.check()
m. チェックしてください。()
Method-specific procedure to test for the validity of a message.
Returns a boolean.
メッセージの正当性がないかどうかテストするメソッド特有の手順。 論理演算子を返します。
m.process()
m.プロセス()
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キーを返します。
4.5. Peer State Machine States
4.5. 同輩州のマシン州
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
怠けてください。
The state machine spends most of its time here, waiting for
something to happen.
何かが起こるのを待っていて、州のマシンはここで時間の大部分を過ごします。
RECEIVED
受信します。
This state is entered when an EAP packet is received. The packet
header is parsed here.
EAPパケットが受け取られているとき、この状態は入られます。 パケットのヘッダーはここで分析されます。
Vollbrecht, et al. Informational [Page 15] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[15ページ]のRFC4137EAP州は2005年8月を機械加工します。
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
_応答を送ってください。
This state signals the lower layer that a response packet is ready
to be sent.
この州は、応答パケットを送る準備ができていると下層に合図します。
DISCARD
破棄
This state signals the lower layer that the request was discarded,
and no response packet will be sent at this time.
この州は、要求が捨てられて、応答パケットが全くこのとき送られないと下層に合図します。
IDENTITY
アイデンティティ
Handles requests for Identity method and builds a response.
Identityメソッドを求める要求を扱って、応答を組み込みます。
NOTIFICATION
通知
Handles requests for Notification method and builds a response.
Notificationメソッドを求める要求を扱って、応答を組み込みます。
RETRANSMIT
再送してください。
Retransmits the previous response packet.
前の応答パケットを再送します。
SUCCESS
成功
A final state indicating success.
成功を示す最終的な州。
FAILURE
失敗
A final state indicating failure.
失敗を示す最終的な州。
Vollbrecht, et al. Informational [Page 16] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[16ページ]のRFC4137EAP州は2005年8月を機械加工します。
5. Stand-Alone Authenticator State Machine
5. スタンドアロンの固有識別文字州のマシン
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)
(.txtバージョンを読むなら、消えるための.pdfバージョンがAppendix A.2について図解するか、または言及するのを見ます)
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にパケットを保存して、eapResp信号をTRUEに設定することによって、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の1つを設定します。 eapReq、eapSuccess、またはeapFailを設定するなら、対応する要求(または、成功/失敗)パケットはeapReqDataに保存されます。 下層は実際にこのメッセージを送るのに原因となります。
5.1.1. Variables (Lower Layer to Stand-Alone Authenticator)
5.1.1. 変数(スタンドアロンの固有識別文字への下層)
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
EAP固有識別文字州のマシンがコミュニケーションの準備ができるべきであるのを示します。 EAPの会話が下層によって始められるとき、これはTRUEに設定されます。 COMポートかセッションが任意な点で利用可能でないなら、portEnabledはFALSE、およびDISABLEDへの州のマシン変遷に用意ができています。 リンクが一時下にだけあって、そうするのが信じているとき、不要なリセットを避けるために、下層は指摘の下側にリンクを湿らせるかもしれません。
Vollbrecht, et al. Informational [Page 17] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[17ページ]のRFC4137EAP州は2005年8月を機械加工します。
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.
すぐ、上がった状態で([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を見てください。)
5.1.2. Variables (Stand-Alone Authenticator To Lower Layer)
5.1.2. 変数(下層へのスタンドアロンの固有識別文字)
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状態に達したのを示します。
Vollbrecht, et al. Informational [Page 18] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[18ページ]のRFC4137EAP州は2005年8月を機械加工します。
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に保存されます。
5.1.3. Constants
5.1.3. 定数
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
出かける: 無視、eapReqData
IN/OUT: currentId, (method-specific state), (policy)
IN/出かける: currentId、(メソッド特有の状態)(方針)
The following describes the interaction between the state machine and EAP methods.
以下は州のマシンとEAPメソッドとの相互作用について説明します。
m.init (in: -, out: -)
m. イニット(中:、-、以下、-、)
Vollbrecht, et al. Informational [Page 19] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[19ページ]のRFC4137EAP州は2005年8月を機械加工します。
When the method is first started, it must initialize its own method- specific state, possibly using some information from Policy (e.g., identity).
メソッドが最初に始められるとき、それ自身のメソッドの特定の状態を初期化しなければなりません、ことによるとPolicy(例えば、アイデンティティ)からの何らかの情報を使用して。
m.buildReq (in: integer, out: EAP packet)
m. buildReq(アウト: コネ: 整数、EAPパケット)
Next, the method creates a new EAP Request packet, with the given identifier value, and updates its method-specific state accordingly.
次に、メソッドは、与えられた識別子値で新しいEAP Requestパケットを作成して、それに従って、メソッド特有の状態をアップデートします。
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. チェックしてください。(アウト: コネ: 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 Responseが受け取られているとき、メソッドは、最初に、パケットを処理するか、または静かにそれを捨てるかを決めなければなりません。 パケットが、それが正統の同輩によって送られなかった(例えば、決して起こるはずがない無効のMessage Integrity Check(MIC)を持っているなら)ように見えるなら、メソッドは戻っているFALSEでこれを示すことができます。 この場合、メソッドはそれ自身のメソッド特有の状態を変更するべきではありません。
m.process (in: EAP packet, out: -)
m.プロセス(コネ: 以下からの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 Responseを処理して、それ自身のメソッド特有の状態をアップデートします。 今、オプションは、会話(別の要求を送る)を続けているか、またはこのメソッドを終わらせることです。
If the method wants to end the conversation, it
会話を終わらせるメソッド必需品であるならそれ
o Tells Policy about the outcome of the method and possibly other
information.
o メソッドとことによると他の情報の結果に関してPolicyに話します。
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.
さもなければ、メソッドは、より早く説明されるように別の要求を送ることによって、続きます。
Vollbrecht, et al. Informational [Page 20] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[20ページ]のRFC4137EAP州は2005年8月を機械加工します。
5.3. Stand-Alone Authenticator State Machine Local Variables
5.3. スタンドアロンの固有識別文字州のマシン局所変数
5.3.1. Long-Term (Maintained between Packets)
5.3.1. 長期(パケットの間で維持されます)
currentMethod (EAP type)
currentMethod(EAPタイプ)
EAP type, IDENTITY, or NOTIFICATION.
EAPタイプ、IDENTITY、またはNOTIFICATION。
currentId (integer)
currentId(整数)
0-255 or NONE. Usually updated in PROPOSE_METHOD state.
Indicates the identifier value of the currently outstanding EAP
request.
0-255かなし。 通常、PROPOSE_METHOD状態でアップデートしています。 現在傑出しているEAP要求の識別子値を示します。
methodState (enumeration)
methodState(列挙)
As described above.
上で説明されるように。
retransCount (integer)
retransCount(整数)
Reset in SEND_REQUEST state and updated in RETRANSMIT state.
Current number of retransmissions.
SENDに_状態であってRETRANSMIT状態でアップデートされた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のためのメソッドに提供されたヒント。
5.3.2. Short-Term (Not Maintained between Packets)
5.3.2. 短期的(パケットの間で維持されません)
rxResp (boolean)
rxResp(論理演算子)
Set in RECEIVED state. Indicates that the current received packet
is an EAP response.
RECEIVED状態にセットしてください。 現在の容認されたパケットがEAP応答であることを示します。
respId (integer)
respId(整数)
Set in RECEIVED state. The identifier from the current EAP
response.
RECEIVED状態にセットしてください。 現在のEAP応答からの識別子。
respMethod (EAP type)
respMethod(EAPタイプ)
Set in RECEIVED state. The method type of the current EAP
response.
RECEIVED状態にセットしてください。 現在のEAP応答のメソッドタイプ。
Vollbrecht, et al. Informational [Page 21] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[21ページ]のRFC4137EAP州は2005年8月を機械加工します。
ignore (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状態にセットしてください。 一時、成功するか、失敗するか、または続くという政策決定を保存します。
5.4. EAP Stand-Alone Authenticator Procedures
5.4. EAPのスタンドアロンの固有識別文字手順
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.
次の識別子値が前のものに基づいて使用することを決定します。 整数を返します。
Vollbrecht, et al. Informational [Page 22] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[22ページ]のRFC4137EAP州は2005年8月を機械加工します。
Policy.update()
Policy.update()
Updates all variables related to internal policy state. The
return value is undefined.
すべての変数が内部の政策ポジションに関係づけたアップデート。 リターン値は未定義です。
Policy.getNextMethod()
Policy.getNextMethod()
Determines the method that should be used at this point in the
conversation based on predefined policy. Policy.getNextMethod()
MUST comply with [RFC3748] (Section 2.1), which forbids the use of
sequences of authentication methods within an EAP conversation.
Thus, if an authentication method has already been executed within
an EAP dialog, Policy.getNextMethod() MUST NOT propose another
authentication method within the same EAP dialog. Returns an EAP
type.
ここに事前に定義された方針に基づく会話に使用されるべきであるメソッドを決定します。 Policy.getNextMethod()は[RFC3748](セクション2.1)に従わなければなりません。(それは、EAPの会話の中で認証方法の系列の使用を禁じます)。 したがって、認証方法が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. チェックしてください。()
Method-specific procedure to test for the validity of a message.
Returns a boolean.
メッセージの正当性がないかどうかテストするメソッド特有の手順。 論理演算子を返します。
m.process()
m.プロセス()
Method procedure to parse and process a response for that method.
The return value is undefined.
そのメソッドのための応答を分析して、処理するメソッド手順。 リターン値は未定義です。
m.init()
m. イニット()
Method procedure to initialize state just before use. The return
value is undefined.
使用のすぐ前に状態を初期化するメソッド手順。 リターン値は未定義です。
m.reset()
m. リセット()
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.
メソッド完成がないかどうかチェックするメソッド手順。 論理演算子を返します。
Vollbrecht, et al. Informational [Page 23] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[23ページ]のRFC4137EAP州は2005年8月を機械加工します。
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パケットを返します。
5.5. EAP Stand-Alone Authenticator States
5.5. EAPのスタンドアロンの固有識別文字州
DISABLED
無効にされます。
The authenticator is disabled until the port is enabled by the
lower layer.
ポートが下層によって可能にされるまで、固有識別文字は障害があります。
INITIALIZE
初期化します。
Initializes variables when the state machine is activated.
州のマシンが活性であるときに、変数を初期化します。
IDLE
怠けてください。
The state machine spends most of its time here, waiting for
something to happen.
何かが起こるのを待っていて、州のマシンはここで時間の大部分を過ごします。
RECEIVED
受信します。
This state is entered when an EAP packet is received. The packet
header is parsed here.
EAPパケットが受け取られているとき、この状態は入られます。 パケットのヘッダーはここで分析されます。
INTEGRITY_CHECK
保全_はチェックします。
A method state in which the integrity of the incoming packet from
the peer is verified by the method.
同輩からの入って来るパケットの保全がメソッドによって確かめられるメソッド状態。
METHOD_RESPONSE
メソッド_応答
A method state in which the incoming packet is processed.
入って来るパケットが処理されるメソッド状態。
METHOD_REQUEST
メソッド_要求
A method state in which a new request is formulated if necessary.
必要なら、新しい要求が定式化されるメソッド状態。
Vollbrecht, et al. Informational [Page 24] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[24ページ]のRFC4137EAP州は2005年8月を機械加工します。
PROPOSE_METHOD
_メソッドを提案してください。
A state in which the authenticator decides which method to try
next in the authentication.
固有識別文字が次に認証で試みるどのメソッドを決める状態。
SELECT_ACTION
_動作を選択してください。
Between methods, the state machine re-evaluates whether its policy
is satisfied and succeeds, fails, or remains undecided.
メソッドの間では、方針が満たされていて、成功するか、失敗するか、または未定のままであることにかかわらず州のマシンは再評価します。
SEND_REQUEST
_要求を送ってください。
This state signals the lower layer that a request packet is ready
to be sent.
この州は、リクエスト・パケットを送る準備ができていると下層に合図します。
DISCARD
破棄
This state signals the lower layer that the response was
discarded, and no new request packet will be sent at this time.
この州は、応答が捨てられて、どんな新しいリクエスト・パケットもこのとき送られないと下層に合図します。
NAK
NAK
This state processes Nak responses from the peer.
この州は同輩からNak応答を処理します。
RETRANSMIT
再送してください。
Retransmits the previous request packet.
前のリクエスト・パケットを再送します。
SUCCESS
成功
A final state indicating success.
成功を示す最終的な州。
FAILURE
失敗
A final state indicating failure.
失敗を示す最終的な州。
TIMEOUT_FAILURE
タイムアウト_失敗
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.
応答を全く受けていないので失敗を示す最終的な州。 応答を全く受けなかったので、どんな新しいメッセージ(失敗を含んでいる)も同輩に送るべきではありません。 これがFAILURE状態と異なっていることに注意してください。(そこでは、失敗を示すメッセージが同輩に送られます)。
Vollbrecht, et al. Informational [Page 25] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[25ページ]のRFC4137EAP州は2005年8月を機械加工します。
6. EAP Backend Authenticator
6. EAPバックエンド固有識別文字
When operating in pass-through mode, there are conceptually two parts to the authenticator: the part that passes packets through, and the backend that actually implements the EAP method. The following diagram shows a state machine for the backend part of this model when using a AAA server. Note that this diagram is identical to Figure 4 except that no retransmit is included in the IDLE state because with RADIUS, retransmit is handled by the NAS. Also, a PICK_UP_METHOD state and variable in INITIALIZE state are added to allow the Method to "pick up" a method started in a NAS. Included is an explanation of the primitives and procedures referenced in the diagram, many of which are the same as above. Note that the "lower layer" in this case is some AAA protocol (e.g., RADIUS).
通じて通りモードで作動するとき、概念的に、固有識別文字への2つの部品があります: それがパケットを通過する部分、および実際にEAPがメソッドであると実装するバックエンド。 RADIUSと共に、再送してください。a AAAサーバこのダイヤグラムが図4と同じであるというメモを使用するとき、以下のダイヤグラムがこのモデルのバックエンド部分に州のマシンを示していて、いいえが再送されるのがIDLE状態に含まれている、NASによって扱われます。 また、INITIALIZE状態のPICK_UP_METHOD状態と変数は、MethodがNASで始められたメソッドを「拾うこと」を許容するために加えられます。 含まれているのは、それの多くが同じくらい上で同じであるダイヤグラムで参照をつけられる基関数と手順に関する説明です。 この場合、「下層」が何らかのAAAプロトコル(例えば、RADIUS)であることに注意してください。
(see the .pdf version for missing diagram or
refer to Appendix A.3 if reading the .txt version)
(.txtバージョンを読むなら、消えるための.pdfバージョンがAppendix A.3について図解するか、または言及するのを見ます)
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にパケットを保存して、aaaEapResp信号をTRUEに設定することによって、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の1つを設定します。 eapReq、eapSuccess、またはeapFailを設定するなら、対応する要求(または、成功/失敗)パケットはaaaEapReqDataに保存されます。 下層は実際にこのメッセージを送るのに原因となります。
6.1.1. Variables (AAA Interface to Backend Authenticator)
6.1.1. 変数(バックエンド固有識別文字へのAAAインタフェース)
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。
Vollbrecht, et al. Informational [Page 26] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[26ページ]のRFC4137EAP州は2005年8月を機械加工します。
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はFALSE、およびDISABLEDへの州のマシン変遷に用意ができています。
6.1.2. Variables (Backend Authenticator to AAA Interface)
6.1.2. 変数(AAAインタフェースへのバックエンド固有識別文字)
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.
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that a new EAP request is ready to be sent.
aaaEapNoReq (boolean)
aaaEapNoReq (boolean)
Set to TRUE in authenticator state machine, FALSE in lower layer.
Indicates that the most recent response has been processed, but
there is no new request to send.
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.
aaaSuccess (boolean)
aaaSuccess (boolean)
Set to TRUE in authenticator state machine, FALSE in lower layer.
Indicates that the state machine has reached the SUCCESS state.
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the SUCCESS state.
aaaFail (boolean)
aaaFail (boolean)
Set to TRUE in authenticator state machine, FALSE in lower layer.
Indicates that the state machine has reached the FAILURE state.
Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the FAILURE state.
aaaEapReqData (EAP packet)
aaaEapReqData (EAP packet)
Set in authenticator state machine when aaaEapReq, aaaSuccess, or
aaaFail is set to TRUE. The actual EAP request to be sent (or
success/failure).
Set in authenticator state machine when aaaEapReq, aaaSuccess, or aaaFail is set to TRUE. The actual EAP request to be sent (or success/failure).
aaaEapKeyData (EAP key)
aaaEapKeyData (EAP key)
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].
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].
aaaEapKeyAvailable (boolean)
aaaEapKeyAvailable (boolean)
Set to TRUE in the SUCCESS state if keying material is available.
The actual key is stored in aaaEapKeyData.
Set to TRUE in the SUCCESS state if keying material is available. The actual key is stored in aaaEapKeyData.
Vollbrecht, et al. Informational [Page 27] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 27] RFC 4137 EAP State Machines August 2005
aaaMethodTimeout (integer)
aaaMethodTimeout (integer)
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.)
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.)
6.2. Interface between Backend Authenticator State Machine and
Methods
6.2. Interface between Backend Authenticator State Machine and Methods
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.
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.
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.)
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.)
After this, the processing continues as described in Section 5.2.
After this, the processing continues as described in Section 5.2.
6.3. Backend Authenticator State Machine Local Variables
6.3. Backend Authenticator State Machine Local Variables
For definitions of the variables used in the Backend Authenticator, see Section 5.3.
For definitions of the variables used in the Backend Authenticator, see Section 5.3.
6.4. EAP Backend Authenticator Procedures
6.4. EAP Backend Authenticator Procedures
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.
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.
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.
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.
Vollbrecht, et al. Informational [Page 28] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 28] RFC 4137 EAP State Machines August 2005
Policy.doPickUp()
Policy.doPickUp()
Notifies the policy that an already-chosen method is being picked
up and will be completed. Returns a boolean.
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.
Method procedure to initialize state when continuing from an already-started method. The return value is undefined.
6.5. EAP Backend Authenticator States
6.5. EAP Backend Authenticator States
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.
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.
PICK_UP_METHOD
PICK_UP_METHOD
Sets an initial state for a method that is being continued and
that was started elsewhere.
Sets an initial state for a method that is being continued and that was started elsewhere.
7. EAP Full Authenticator
7. EAP Full Authenticator
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.
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.
The first diagram is largely a reproduction of that found above, with the added hooks for a transition to PASSTHROUGH mode.
The first diagram is largely a reproduction of that found above, with the added hooks for a transition to PASSTHROUGH mode.
(see the .pdf version for missing diagram or
refer to Appendix A.4 if reading the .txt version)
(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)
Figure 6: EAP Full Authenticator State Machine (Part 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.
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.
(see the .pdf version for missing diagram or
refer to Appendix A.4 if reading the .txt version)
(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)
Figure 7: EAP Full Authenticator State Machine (Part 2)
Vollbrecht, et al. Informational [Page 29] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 29] RFC 4137 EAP State Machines August 2005
7.1. Interface between Full Authenticator State Machine and Lower
Layers
7.1. Interface between Full Authenticator State Machine and Lower Layers
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].
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].
7.1.1. Variables (AAA Interface to Full Authenticator)
7.1.1. Variables (AAA Interface to Full Authenticator)
aaaEapReq (boolean)
aaaEapReq (boolean)
Set to TRUE in lower layer, FALSE in authenticator state machine.
Indicates that a new EAP request is available from the AAA server.
Set to TRUE in lower layer, FALSE in authenticator state machine. Indicates that a new EAP request is available from the AAA server.
aaaEapNoReq (boolean)
aaaEapNoReq (boolean)
Set to TRUE in lower layer, FALSE in authenticator state machine.
Indicates that the most recent response has been processed, but
that there is no new request to send.
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.
aaaSuccess (boolean)
aaaSuccess (boolean)
Set to TRUE in lower layer. Indicates that the AAA backend
authenticator has reached the SUCCESS state.
Set to TRUE in lower layer. Indicates that the AAA backend authenticator has reached the SUCCESS state.
aaaFail (boolean)
aaaFail (boolean)
Set to TRUE in lower layer. Indicates that the AAA backend
authenticator has reached the FAILURE state.
Set to TRUE in lower layer. Indicates that the AAA backend authenticator has reached the FAILURE state.
aaaEapReqData (EAP packet)
aaaEapReqData (EAP packet)
Set in the lower layer when aaaEapReq, aaaSuccess, or aaaFail is
set to TRUE. The actual EAP request to be sent (or success/
failure).
Set in the lower layer when aaaEapReq, aaaSuccess, or aaaFail is set to TRUE. The actual EAP request to be sent (or success/ failure).
aaaEapKeyData (EAP key)
aaaEapKeyData (EAP key)
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].
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].
Vollbrecht, et al. Informational [Page 30] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 30] RFC 4137 EAP State Machines August 2005
aaaEapKeyAvailable (boolean)
aaaEapKeyAvailable (boolean)
Set to TRUE in the lower layer if keying material is available.
The actual key is stored in aaaEapKeyData.
Set to TRUE in the lower layer if keying material is available. The actual key is stored in aaaEapKeyData.
aaaMethodTimeout (integer)
aaaMethodTimeout (integer)
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.)
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.)
7.1.2. Variables (full authenticator to AAA interface)
7.1.2. Variables (full authenticator to AAA interface)
aaaEapResp (boolean)
aaaEapResp (boolean)
Set to TRUE in authenticator state machine, FALSE in the lower
layer. Indicates that an EAP response is available for processing
by the AAA server.
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.
aaaEapRespData (EAP packet)
aaaEapRespData (EAP packet)
Set in authenticator state machine when eapResp is set to TRUE.
The EAP packet to be processed.
Set in authenticator state machine when eapResp is set to TRUE. The EAP packet to be processed.
aaaIdentity (EAP packet)
aaaIdentity (EAP packet)
Set in authenticator state machine when an IDENTITY response is
received. Makes that identity available to AAA lower layer.
Set in authenticator state machine when an IDENTITY response is received. Makes that identity available to AAA lower layer.
aaaTimeout (boolean)
aaaTimeout (boolean)
Set in AAA_IDLE if, after a configurable amount of time, there is
no response from the AAA layer. The AAA layer in the NAS is
itself alive and OK, but for some reason it has not received a
valid Access-Accept/Reject indication from the backend.
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.
7.1.3. Constants
7.1.3. Constants
Same as Section 5.
Same as Section 5.
7.2. Interface between Full Authenticator State Machine and Methods
7.2. Interface between Full Authenticator State Machine and Methods
Same as stand-alone authenticator (Section 5.2).
Same as stand-alone authenticator (Section 5.2).
Vollbrecht, et al. Informational [Page 31] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 31] RFC 4137 EAP State Machines August 2005
7.3. Full Authenticator State Machine Local Variables
7.3. Full Authenticator State Machine Local Variables
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.
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.
7.3.1. Short-Term (Not Maintained between Packets)
7.3.1. Short-Term (Not Maintained between Packets)
decision (enumeration)
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.
Set in SELECT_ACTION state. Temporarily stores the policy decision to succeed, fail, continue with a local method, or continue in pass-through mode.
7.4. EAP Full Authenticator Procedures
7.4. EAP Full Authenticator Procedures
All the procedures defined in Section 5 exist in the full version. In addition, the following procedures are defined.
All the procedures defined in Section 5 exist in the full version. In addition, the following procedures are defined.
getId()
getId()
Determines the identifier value chosen by the AAA server for the
current EAP request. The return value is an integer.
Determines the identifier value chosen by the AAA server for the current EAP request. The return value is an integer.
7.5. EAP Full Authenticator States
7.5. EAP Full Authenticator States
All the states defined in Section 5 exist in the full version. In addition, the following states are defined.
All the states defined in Section 5 exist in the full version. In addition, the following states are defined.
INITIALIZE_PASSTHROUGH
INITIALIZE_PASSTHROUGH
Initializes variables when the pass-through portion of the state
machine is activated.
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.
The state machine waits for a response from the primary lower layer, which transports EAP traffic from the peer.
IDLE
IDLE
The state machine spends most of its time here, waiting for
something to happen.
The state machine spends most of its time here, waiting for something to happen.
Vollbrecht, et al. Informational [Page 32] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 32] RFC 4137 EAP State Machines August 2005
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.
This state is entered when an EAP packet is received and the authenticator is in PASSTHROUGH mode. The packet header is parsed here.
AAA_REQUEST
AAA_REQUEST
The incoming EAP packet is parsed for sending to the AAA server.
The incoming EAP packet is parsed for sending to the AAA server.
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.
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_RESPONSE
AAA_RESPONSE
State in which the request from the AAA interface is processed
into an EAP request.
State in which the request from the AAA interface is processed into an EAP request.
SEND_REQUEST2
SEND_REQUEST2
This state signals the lower layer that a request packet is ready
to be sent.
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.
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.
Retransmits the previous request packet.
SUCCESS2
SUCCESS2
A final state indicating success.
A final state indicating success.
FAILURE2
FAILURE2
A final state indicating failure.
A final state indicating failure.
Vollbrecht, et al. Informational [Page 33] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 33] RFC 4137 EAP State Machines August 2005
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.
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.
8. Implementation Considerations
8. Implementation Considerations
8.1. Robustness
8.1. Robustness
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.
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).
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:
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 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 METHOD state in the peer state machine and in METHOD_RESPONSE
state in the authenticator state machines. It may take some time
to perform method-specific procedures in these states. An
implementation may define an additional state transition from
METHOD state and METHOD_RESPONSE state to FAILURE or
TIMEOUT_FAILURE state so that authentication can fail if no method
processing result is obtained from the method before methodTimeout
timer expires.
o 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.
Vollbrecht, et al. Informational [Page 34] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 34] RFC 4137 EAP State Machines August 2005
8.2. Method/Method and Method/Lower-Layer Interfaces
8.2. Method/Method and Method/Lower-Layer Interfaces
Implementations may define additional interfaces to pass method- specific information between methods and lower layers. These interfaces are beyond the scope of this document.
Implementations may define additional interfaces to pass method- specific information between methods and lower layers. These interfaces are beyond the scope of this document.
8.3. Peer State Machine Interoperability with Deployed Implementations
8.3. Peer State Machine Interoperability with Deployed Implementations
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.
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.
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.
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.
9. Security Considerations
9. Security Considerations
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.
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.
An accurate state machine can help reduce implementation errors. Although [RFC3748] remains the normative protocol description, this state machine should help in this regard.
An accurate state machine can help reduce implementation errors. Although [RFC3748] remains the normative protocol description, this state machine should help in this regard.
As noted in [RFC3748], some security concerns arise because of the following EAP packets:
As noted in [RFC3748], some security concerns arise because of the following EAP packets:
1. EAP-Request/Response Identity
2. EAP-Response/NAK
3. EAP-Success/Failure
1. EAP-Request/Response Identity 2. EAP-Response/NAK 3. EAP-Success/Failure
Because these packets are not cryptographically protected by themselves, an attacker can modify or insert them without immediate detection by the peer or authenticator.
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:
Following Figure 3 specification, an attacker may cause denial of service by:
Vollbrecht, et al. Informational [Page 35] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 35] RFC 4137 EAP State Machines August 2005
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.
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.
o Forcing the peer to engage in endless EAP-Request/Response
Identity exchanges before it has started an EAP authentication
method. As long as the peer has not modified the selectedMethod
variable (initialized to NONE), the peer MUST accept an EAP-
Request/Identity and respond to it with an EAP-Response/Identity.
o 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.
Following Figure 4 specification, an attacker may cause denial of service by:
Following Figure 4 specification, an attacker may cause denial of service by:
o Sending a NAK to the authenticator after the authenticator first
proposes an EAP authentication method to the peer. When the
methodState variable has the value PROPOSED, the authenticator is
obliged to process a NAK that is received in response to its first
packet of an EAP authentication method.
o 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.
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.
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.
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.
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.
10. Acknowledgements
10. Acknowledgements
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.
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.
Vollbrecht, et al. Informational [Page 36] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 36] RFC 4137 EAP State Machines August 2005
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.
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.
11. References
11. References
11.1. Normative References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
11.2. Informative References
11.2. Informative References
[Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., Levkowetz,
H., "Extensible Authentication Protocol (EAP) Key
Management Framework", Work in Progress, July 2005.
[Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., Levkowetz, H., "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, July 2005.
[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] Institute of Electrical and Electronics Engineers, "Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE 802.1X-2004, December 2004.
Vollbrecht, et al. Informational [Page 37] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 37] RFC 4137 EAP State Machines August 2005
Appendix A. ASCII versions of state diagrams
Appendix A. ASCII versions of state diagrams
This appendix contains the state diagrams in ASCII format. Please use the PDF version whenever possible; it is much easier to understand.
This appendix contains the state diagrams in ASCII format. Please use the PDF version whenever possible; it is much easier to understand.
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.
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 Peer State Machine (Figure 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) |
|------------------------+--------------
--------------------------------------------------------------------- (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) | |------------------------+--------------
Vollbrecht, et al. Informational [Page 38] RFC 4137 EAP State Machines August 2005
Vollbrecht, et al. Informational [Page 38] RFC 4137 EAP State Machines August 2005
|------------------------+--------------
| 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) |
|------------------------+--------------
|------------------------+-------------- | altReject|| | | (idleWhile=0、| | 決定!=| | UNCOND_SUCC、) || | 失敗| (altAccept、| | methodState!がCONTと等しい、| | 決定=FAIL) | -----------------------------+------------------------+-------------- 受信します。| rxReq| 方法| (reqId!=lastId) && | (| (reqMethod=| reqId、reqMethod)=| rxReq、rxSuccess、rxFailure、selectedMethod) && | parseEapReq(eapReqData)| (行われたmethodState=!) | |------------------------+-------------- | rxReq| | (reqId!=lastId) && | | (selectedMethod=| | なにも) && | _方法を得てください。| (reqMethod=!| | アイデンティティ) && | | (reqMethod=!| | 通知) | |------------------------+-------------- | rxReq| | (reqId!=lastId) && | | (selectedMethod=| アイデンティティ| なにも) && | | (reqMethod=| | アイデンティティ) | |------------------------+-------------- | rxReq| | (reqId!=lastId) && | | (reqMethod=|通知|通知) && | | allowNotifications| |------------------------+-------------- | rxReq| 再送してください。| (reqId=lastId) | |------------------------+-------------- | rxSuccess| | (reqId=lastId) && | 成功| (決定!=は失敗します) | |------------------------+--------------
Vollbrecht, et al. Informational [Page 39] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[39ページ]のRFC4137EAP州は2005年8月を機械加工します。
|------------------------+--------------
| (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) | |
-----------------------------+------------------------+--------------
|------------------------+-------------- | (methodState!=CONT) && | | (rxFailure、| | 決定!=| | UNCOND_SUCC) | | | FAILURE|、(rxSuccess、| | 決定=FAIL) && | | (reqId=lastId) | |------------------------+-------------- | ほか| 破棄-----------------------------+------------------------+-------------- 方法| | | | =m.チェック(eapReqData)を無視してください。| 無視します。| 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() | | } | | -----------------------------+------------------------+-------------- _方法を得てください。| | | selectedMethod=| if (allowMethod(reqMethod)) {| reqMethod | METHOD selectedMethod = reqMethod | | methodState = INIT | | } else { |------------------------+-------------- eapRespData = | | buildNak(reqId) | else | SEND_RESPONSE } | | -----------------------------+------------------------+-------------- アイデンティティ| | | | processIdentity(eapReqData)| UCT| _応答eapRespData=を送ってください。| | buildIdentity(reqId)| | -----------------------------+------------------------+--------------
Vollbrecht, et al. Informational [Page 40] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[40ページ]のRFC4137EAP州は2005年8月を機械加工します。
-----------------------------+------------------------+--------------
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
-----------------------------+------------------------+-------------- 通知| | | | processNotifyします(eapReqData)。| UCT| _応答eapRespData=を送ってください。| | buildNotifyします(reqId)。| | -----------------------------+------------------------+-------------- 再送してください。| | | UCT| _応答eapRespData=lastRespDataを送ってください。| | -----------------------------+------------------------+-------------- 破棄| | | UCT| eapReqを= 虚偽で空費してください。| | eapNoRespは本当に等しいです。| | -----------------------------+------------------------+-------------- _応答を送ってください。| | | | lastIdはreqIdと等しいです。| | lastRespDataはeapRespDataと等しいです。| UCT| eapReqを= 虚偽で空費してください。| | eapRespは本当に等しいです。| | idleWhileはClientTimeoutと等しいです。| | -----------------------------+------------------------+-------------- 成功| | | | (eapKeyData!=なにも)です。| | eapKeyAvailableは本当に等しいです。| | eapSuccessは本当に等しいです。| | -----------------------------+------------------------+-------------- 失敗| | | | eapFailは本当に等しいです。| | --------------------------------------------------------------------- エイト環
A.2. EAP Stand-Alone Authenticator State Machine (Figure 4)
A.2。 EAPのスタンドアロンの固有識別文字州のマシン(図4)
---------------------------------------------------------------------
(global transitions) | !portEnabled | DISABLED
|---------------------+----------------
| eapRestart && | INITIALIZE
| portEnabled |
------------------------------+---------------------+----------------
DISABLED | portEnabled | INITIALIZE
------------------------------+---------------------+----------------
--------------------------------------------------------------------- (グローバルな変遷) | portEnabled| 無能にされます。|---------------------+---------------- | eapRestart| 初期化します。| portEnabledしました。| ------------------------------+---------------------+---------------- 無能にされます。| portEnabledしました。| 初期化します。------------------------------+---------------------+----------------
Vollbrecht, et al. Informational [Page 41] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[41ページ]のRFC4137EAP州は2005年8月を機械加工します。
------------------------------+---------------------+----------------
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
------------------------------+---------------------+----------------
------------------------------+---------------------+---------------- 初期化します。| | | | currentIdはなにもと等しくはありません。| | eapSuccessは偽と等しいです。| | eapFailは偽と等しいです。| UCT| _動作eapTimeoutを= 虚偽で選択してください。| | eapKeyDataはなにもと等しくはありません。| | eapKeyAvailableは偽と等しいです。| | eapRestartは偽と等しいです。| | ------------------------------+---------------------+---------------- 怠けてください。| | | retransWhile=0| retransWhile=を再送してください。| | calculateTimeout( |---------------------+---------------- retransCount, eapSRTT, | eapResp | RECEIVED eapRTTVAR, methodTimeout) | | ------------------------------+---------------------+---------------- 再送してください。| | | retransCount>。| タイムアウト_失敗retransCount++| MaxRetrans| if (retransCount<=MaxRetrans){| | eapReqData = lastReqData |---------------------+---------------- eapReq = TRUE | else | IDLE } | | ------------------------------+---------------------+---------------- 受信します。| rxResp| | (respId=| (rxResp、respId、respMethod)=| currentId) && | parseEapResp(eapRespData)| (NAK| | | | | NAK| respMethod=| | 拡張_respMethod=NAK) && | | (methodState=|、|、提案、) | |---------------------+---------------- | rxResp| | (respId=| | currentId) && | 保全_はチェックします。| (respMethod=| | currentMethod) | |---------------------+---------------- | ほか| 破棄------------------------------+---------------------+----------------
Vollbrecht, et al. Informational [Page 42] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[42ページ]のRFC4137EAP州は2005年8月を機械加工します。
------------------------------+---------------------+----------------
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()| |
------------------------------+---------------------+----------------
------------------------------+---------------------+---------------- NAK| | | UCT| SELECT_ACTION m.リセット()| | Policy.update(<…>)| | ------------------------------+---------------------+---------------- _動作を選択してください。| 決定=FAILURE| 失敗| | 決定=|---------------------+---------------- Policy.getDecision()| 決定=SUCCESS| または成功/*成功、失敗。|---------------------+---------------- */を続けてください。| ほか| _方法を提案してください。------------------------------+---------------------+---------------- 保全_はチェックします。| 無視します。| 破棄|---------------------+---------------- =m.チェック(eapRespData)を無視してください。| 無視| 方法_応答------------------------------+---------------------+---------------- 方法_応答| | | methodState=エンド| _動作m.の過程(eapRespData)を選択してください。| | if (m.isDone()) { | | Policy.update(<...>) |---------------------+---------------- eapKeyData = m.getKey() | | methodState = END | else | METHOD_REQUEST } else | | methodState=は続きます。| | ------------------------------+---------------------+---------------- _方法を提案してください。| | | | currentMethod=| | Policy.getNextMethod()| | m. イニット()| UCT| _が(アイデンティティ| | | | currentMethod=currentMethod=通知)であるなら要求する方法| | methodState=は続きます。| | ほか| | methodState=は提案しました。| | ------------------------------+---------------------+---------------- 方法_要求| | | | currentIdはnextId(currentId)と等しいです。| UCT| _要求eapReqData=を送ってください。| | m. buildReq(currentId)| | methodTimeoutはm.getTimeout()と等しいです。| | ------------------------------+---------------------+----------------
Vollbrecht, et al. Informational [Page 43] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[43ページ]のRFC4137EAP州は2005年8月を機械加工します。
------------------------------+---------------------+----------------
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
------------------------------+---------------------+---------------- 破棄| | | UCT| eapRespを= 虚偽で空費してください。| | eapNoReqは本当に等しいです。| | ------------------------------+---------------------+---------------- _要求を送ってください。| | | | retransCount=0| UCT| 使用されていないlastReqDataはeapReqDataと等しいです。| | eapRespは偽と等しいです。| | eapReqは本当に等しいです。| | ------------------------------+---------------------+---------------- タイムアウト_失敗| | | | eapTimeoutは本当に等しいです。| | ------------------------------+---------------------+---------------- 失敗| | | | eapReqData=| | buildFailure(currentId)| | eapFailは本当に等しいです。| | ------------------------------+---------------------+---------------- 成功| | | | eapReqData=| | buildSuccess(currentId)| | (eapKeyData!=なにも)です。| | eapKeyAvailableは本当に等しいです。| | eapSuccessは本当に等しいです。| | --------------------------------------------------------------------- 図9
A.3. EAP Backend Authenticator State Machine (Figure 5)
A.3。 EAPバックエンド固有識別文字州のマシン(図5)
---------------------------------------------------------------------
(global transitions) | !backendEnabled | DISABLED
------------------------------+---------------------+----------------
DISABLED | backendEnabled && | INITIALIZE
| aaaEapResp |
------------------------------+---------------------+----------------
--------------------------------------------------------------------- (グローバルな変遷) | backendEnabled| 無能にされます。------------------------------+---------------------+---------------- 無能にされます。| backendEnabled| 初期化します。| aaaEapResp| ------------------------------+---------------------+----------------
Vollbrecht, et al. Informational [Page 44] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[44ページ]のRFC4137EAP州は2005年8月を機械加工します。
------------------------------+---------------------+----------------
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(<...>) | |
------------------------------+---------------------+----------------
------------------------------+---------------------+---------------- 初期化します。| rxResp| _動作を選択してください。|---------------------+---------------- currentMethodはなにもと等しくはありません。| rxResp| (rxResp、respId、respMethod)= | (NAK| parseEapResp(aaaEapRespData)| | | | respMethod=NAKは(rxResp)| respMethod=| currentIdであるならrespIdと等しいです| 拡張_NAK) | ほか|---------------------+---------------- currentIdはなにもと等しくはありません。| ほか| _方法に_を選んでください。------------------------------+---------------------+---------------- _方法に_を選んでください。| | | currentMethod=| SELECT_ACTION if (Policy.doPickUp( | NONE | respMethod)) { | | currentMethod = respMethod |---------------------+---------------- m.initPickUp() | else | METHOD_RESPONSE } | | ------------------------------+---------------------+---------------- 怠けてください。| aaaEapResp| 受信します。------------------------------+---------------------+---------------- 受信します。| rxResp| | (respId=| (rxResp、respId、respMethod)=| currentId) && | parseEapResp(aaaEapRespData)| (NAK| | | | | NAK| respMethod=| | 拡張_respMethod=NAK) && | | (methodState=|、|、提案、) | |---------------------+---------------- | rxResp| | (respId=| | currentId) && | 保全_はチェックします。| (respMethod=| | currentMethod) | |---------------------+---------------- | ほか| 破棄------------------------------+---------------------+---------------- NAK| | | UCT| SELECT_ACTION m.リセット()| | Policy.update(<…>)| | ------------------------------+---------------------+----------------
Vollbrecht, et al. Informational [Page 45] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[45ページ]のRFC4137EAP州は2005年8月を機械加工します。
------------------------------+---------------------+----------------
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 | |
------------------------------+---------------------+----------------
------------------------------+---------------------+---------------- _動作を選択してください。| 決定=FAILURE| 失敗| | 決定=|---------------------+---------------- Policy.getDecision()| 決定=SUCCESS| または成功/*成功、失敗。|---------------------+---------------- */を続けてください。| ほか| _方法を提案してください。------------------------------+---------------------+---------------- 保全_はチェックします。| 無視します。| 破棄| | =を無視してください。|---------------------+---------------- m. (aaaEapRespData)をチェックしてください。| 無視| 方法_応答------------------------------+---------------------+---------------- 方法_応答| | | methodState=エンド| _動作m.の過程(aaaEapRespData)を選択してください。| | if (m.isDone()) { | | Policy.update(<...>) |---------------------+---------------- aaaEapKeyData = m.getKey() | | methodState = END | else | METHOD_REQUEST } else | | methodState=は続きます。| | ------------------------------+---------------------+---------------- _方法を提案してください。| | | | currentMethod=| | Policy.getNextMethod()| | m. イニット()| UCT| _が(アイデンティティ| | | | currentMethod=currentMethod=通知)であるなら要求する方法| | methodState=は続きます。| | ほか| | methodState=は提案しました。| | ------------------------------+---------------------+---------------- 方法_要求| | | | currentIdはnextId(currentId)と等しいです。| | aaaEapReqData=| UCT| _要求m.buildReq(currentId)を送ってください。| | aaaMethodTimeout=| | m. getTimeout()| | ------------------------------+---------------------+---------------- 破棄| | | UCT| aaaEapRespを= 虚偽で空費してください。| | aaaEapNoReqは本当に等しいです。| | ------------------------------+---------------------+----------------
Vollbrecht, et al. Informational [Page 46] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[46ページ]のRFC4137EAP州は2005年8月を機械加工します。
------------------------------+---------------------+----------------
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
------------------------------+---------------------+---------------- _要求を送ってください。| | | UCT| aaaEapRespを= 虚偽で空費してください。| | aaaEapReqは本当に等しいです。| | ------------------------------+---------------------+---------------- 失敗| | | | aaaEapReqData=| | buildFailure(currentId)| | aaaEapFailは本当に等しいです。| | ------------------------------+---------------------+---------------- 成功| | | | aaaEapReqData=| | buildSuccess(currentId)| | (aaaEapKeyData!=なにも)です。| | aaaEapKeyAvailableは本当に等しいです。| | aaaEapSuccessは本当に等しいです。| | --------------------------------------------------------------------- 図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:
この州のマシンはEAPのスタンドアロンの固有識別文字状態からの州が機械加工するすべてを含んでいます、SELECT_ACTION状態を以下に取り替えるのを除いて:
---------------------------------------------------------------------
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
--------------------------------------------------------------------- _動作を選択してください。| 決定=FAILURE| 失敗| | 決定=|---------------------+---------------- Policy.getDecision()| 決定=SUCCESS| 成功/*成功、失敗は続きます。|---------------------+---------------- または、PASSTHROUGH*/| 決定=| _を初期化してください。| PASSTHROUGH| PASSTHROUGH|---------------------+---------------- | ほか| _方法を提案してください。--------------------------------------------------------------------- 図11
And the following new states are added:
そして、以下の新しい州は加えられます:
---------------------------------------------------------------------
INITIALIZE_PASSTHROUGH | currentId != NONE | AAA_REQUEST
|---------------------+----------------
aaaEapRespData = NONE | currentId == NONE | AAA_IDLE
------------------------------+---------------------+----------------
--------------------------------------------------------------------- _PASSTHROUGHを初期化してください。| currentId!はなにもと等しくはありません。| トリプルA_要求|---------------------+---------------- aaaEapRespDataはなにもと等しくはありません。| currentId=なし| トリプルA_は怠けます。------------------------------+---------------------+----------------
Vollbrecht, et al. Informational [Page 47] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[47ページ]のRFC4137EAP州は2005年8月を機械加工します。
------------------------------+---------------------+----------------
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 | |
------------------------------+---------------------+----------------
------------------------------+---------------------+---------------- IDLE2| | | retransWhile=0| RETRANSMIT2 retransWhile=| | calculateTimeout( |---------------------+---------------- retransCount, eapSRTT, | eapResp | RECEIVED2 eapRTTVAR, methodTimeout) | | ------------------------------+---------------------+---------------- RETRANSMIT2| | | retransCount>。| タイムアウト_retransCount++| MaxRetrans| FAILURE2 if (retransCount<=MaxRetrans){| | eapReqData = lastReqData |---------------------+---------------- eapReq = TRUE | else | IDLE2 } | | ------------------------------+---------------------+---------------- RECEIVED2| rxResp| | (respId=| トリプルA_は(rxResp、respId、respMethod)=を要求します| currentId) | parseEapResp(eapRespData)|---------------------+---------------- | ほか| DISCARD2------------------------------+---------------------+---------------- トリプルA_要求| | | | 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 | | ------------------------------+---------------------+----------------
Vollbrecht, et al. Informational [Page 48] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[48ページ]のRFC4137EAP州は2005年8月を機械加工します。
------------------------------+---------------------+----------------
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
------------------------------+---------------------+---------------- DISCARD2| | | UCT| IDLE2 eapRespは偽と等しいです。| | eapNoReqは本当に等しいです。| | ------------------------------+---------------------+---------------- _REQUEST2を送ってください。| | | | retransCount=0| UCT| IDLE2 lastReqDataはeapReqDataと等しいです。| | eapRespは偽と等しいです。| | eapReqは本当に等しいです。| | ------------------------------+---------------------+---------------- タイムアウト_FAILURE2| | | | eapTimeoutは本当に等しいです。| | ------------------------------+---------------------+---------------- FAILURE2| | | | eapReqDataはaaaEapReqDataと等しいです。| | eapFailは本当に等しいです。| | ------------------------------+---------------------+---------------- SUCCESS2| | | | eapReqDataはaaaEapReqDataと等しいです。| | eapKeyDataはaaaEapKeyDataと等しいです。| | eapKeyAvailable=| | aaaEapKeyAvailable| | eapSuccessは本当に等しいです。| | --------------------------------------------------------------------- 図12
Vollbrecht, et al. Informational [Page 49] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[49ページ]のRFC4137EAP州は2005年8月を機械加工します。
Authors' Addresses
作者のアドレス
John Vollbrecht Meetinghouse Data Communications 9682 Alice Hill Drive Dexter, MI 48130 USA
MI48130米国のジョンVollbrecht公会堂Data Communications9682アリス・ヒル・Driveデクスター
EMail: jrv@mtghouse.com
メール: jrv@mtghouse.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group, Finland
パシEronenノキアリサーチセンター私書箱407フィン-00045Nokia Group、フィンランド
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
メリーランド、カレッジパークA.V.ウィリアムズ・Building MD20742カレッジパーク(米国)の大学にL.ペトローニ、Jr.に傷を付けてください。
EMail: npetroni@cs.umd.edu
メール: npetroni@cs.umd.edu
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
芳広オオバ東芝アメリカ研究Inc.1Telcordia Driveニュージャージー08854ピスキャタウェイ(米国)
EMail: yohba@tari.toshiba.com
メール: yohba@tari.toshiba.com
Vollbrecht, et al. Informational [Page 50] RFC 4137 EAP State Machines August 2005
Vollbrecht、他 情報[50ページ]のRFC4137EAP州は2005年8月を機械加工します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Vollbrecht, et al. Informational [Page 51]
Vollbrecht、他 情報[51ページ]
一覧
スポンサーリンク
