4. EAP Packet Format
4. EAP Packet Format
EAP パケットのフォーマットの要約を以下に示す。フィールドは左から右へ送信される。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
Code フィールドは 1 オクテットであり、EAP パケットの種類を識別する。EAP コードは以下のように割り当てられる。
1 Request
2 Response
3 Success
4 Failure
EAP はコード 1-4 のみを定義しているため、それ以外のコードを持つ EAP パケットは、authenticator および peer の両方によって黙って廃棄されなければならない (MUST)。
Identifier
Identifier フィールドは 1 オクテットであり、応答を要求と照合するのに役立つ。
Length
Length フィールドは 2 オクテットであり、Code、Identifier、Length、Data フィールドを含む EAP パケットの長さをオクテット単位で示す。Length フィールドの範囲外のオクテットは、データリンク層のパディングとして扱われ、受信時に無視されなければならない (MUST)。Length フィールドが受信したオクテット数より大きい値に設定されたメッセージは、黙って廃棄されなければならない (MUST)。
Data
Data フィールドは 0 個以上のオクテットからなる。Data フィールドのフォーマットは Code フィールドによって決まる。
4.1. Request と Response
説明
Request パケット（Code フィールドを 1 に設定）は、authenticator から peer に送信される。各 Request には、要求される内容を示す Type フィールドがある。有効な Response パケットを受信するまで、あるいはオプションの再試行カウンタが期限切れになるまで、あるいは下位層からエラー指示を受信するまで、さらに Request パケットを送信しなければならない (MUST)。
再送される Request は、新しい Request と区別するために、同じ Identifier 値で送信されなければならない (MUST)。data フィールドの内容は Request の種類による。peer は有効な Request パケットに応答して Response パケットを送信しなければならない (MUST)。Response は有効な Request への応答としてのみ送信されなければならず、タイマーで再送されてはならない (MUST NOT)。
peer がすでに Response を送信した有効な重複 Request を受信した場合、その Request を再処理することなく、元の Response を再送しなければならない (MUST)。Request は受信した順序で処理されなければならず (MUST)、現在の Request の処理を完了してから次の Request を調べなければならない (MUST)。
Request および Response パケットのフォーマットの要約を以下に示す。フィールドは左から右へ送信される。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 for Request
2 for Response
Identifier
Identifier フィールドは 1 オクテットである。Request パケットが応答待ちでタイムアウトのために再送される場合、Identifier フィールドは同じでなければならない (MUST)。新しい Request（再送ではない）は、Identifier フィールドを変更しなければならない (MUST)。
Response の Identifier フィールドは、現在保留中の Request と一致しなければならない (MUST)。現在保留中の Request の Identifier 値と一致しない Identifier を持つ Response を受信した authenticator は、その Response を黙って廃棄しなければならない (MUST)。
新しい Request と再送の混同を避けるため、各新しい Request に選択された Identifier 値は、直前の Request と異なっていればよく、セッション内で一意である必要はない。これを実現する 1 つの方法は、初期値から開始し、新しい Request ごとに Identifier をインクリメントすることである。最初の Identifier をゼロから始めるのではなく乱数で初期化することが推奨される。これにより、シーケンス攻撃がやや困難になるためである。
Identifier 空間はセッションごとに一意であるため、authenticator は同時に実行される認証セッションを 256 個に制限されない。同様に、再認証時には EAP セッションが長期間続く可能性があり、256 回の往復に制限されない。
実装注記：authenticator は Request メッセージの再送信を担当する。Request メッセージが他の場所（たとえばバックエンド認証サーバ）から取得される場合、authenticator はそれを再送信できるように Request のコピーを保存する必要がある。peer は、Request をいかなる方法でも（外部への渡しを含めて）処理する前に、重複する Request メッセージを検出して処理する責任がある。また、authenticator は、いかなる方法でも（バックエンド認証サーバへの検証のための渡しを含めて）応答する前に、Identifier 値が一致しない Response メッセージを廃棄する責任がある。authenticator は peer からの Response を受信する前に再送信を行う可能性があるため、authenticator は複数の Response を受信する可能性があり、それぞれが一致する Identifier を持つ。authenticator が新しい Request を受信するまで Identifier 値は更新されないため、authenticator は Response をバックエンド認証サーバに 1 つずつ転送する。
Length
Length フィールドは 2 オクテットであり、Code、Identifier、Length、Type、Type-Data フィールドを含む EAP パケットの長さを示す。Length フィールドの範囲外のオクテットは、データリンク層のパディングとして扱われ、受信時に無視されなければならない (MUST)。Length フィールドが受信したオクテット数より大きい値に設定されたメッセージは、黙って廃棄されなければならない (MUST)。
Type
Type フィールドは 1 オクテットである。このフィールドは Request または Response の種類を示す。各 Request または Response EAP は単一の Type を指定しなければならない (MUST)。Types の初期仕様は、このドキュメントのセクション 5 に記載されている。
Response の Type フィールドは、Request の Type フィールドと一致しなければならない (MUST)。または、peer が Request Type を受け入れないことを示す、従来のまたは拡張された Nak（セクション 5.3 参照）と一致しなければならない (MUST)。初期の非 Nak Response を送信した後、peer は Request への応答として Nak（従来または拡張）を送信してはならない (MUST NOT)。これらの要件を満たさない Response を受信した EAP サーバは、それを黙って廃棄しなければならない (MUST)。
Type-Data
Type-Data フィールドは、Request の種類とそれに対応する Response によって異なる。
4.2. Success と Failure
Success パケットは、EAP 認証方式（タイプ 4 以上）の完了後に、peer が authenticator によって正常に認証されたことを示すために、authenticator から peer に送信される。authenticator は、Code フィールドを 3（Success）に設定した EAP パケットを送信しなければならない (MUST)。authenticator が peer を認証できない場合（1 つ以上の Request に対する Response が受け入れられない）、現在の EAP 方式が失敗した完了後に、実装は Code フィールドを 4（Failure）に設定した EAP パケットを送信しなければならない (MUST)。authenticator は、人的入力エラーを許容するために、Failure 応答を送信する前に複数の Request を発行することを望む場合がある。Success パケットおよび Failure パケットは追加のデータを含んではならない (MUST NOT)。
指定された方式の仕様がその時点での終了を明示的に許可していない場合、authenticator EAP は Success パケットおよび Failure パケットを送信してはならない (MUST NOT)。送信が明示的に許可されていない Success または Failure パケットを受信した peer EAP 実装は、それを黙って廃棄しなければならない (MUST)。デフォルトでは、peer EAP は「canned」Success パケット（接続オープン時に即座に送信される Success パケット）を黙って廃棄しなければならない (MUST)。これにより、悪意のある authenticator が EAP 方式セッションの終了前に Success パケットを送信して相互認証を回避することができなくなる。
実装注記：Success パケットおよび Failure パケットは確認されないため、authenticator によって再送信されず、失われる可能性がある。peer は、本注記で説明されているように、この状況を考慮しなければならない。下位層の成功および失敗指示の処理に関するガイドラインについては、セクション 3.4 も参照のこと。
セクション 2.1 で述べたように、EAP セッション内では 1 つの EAP 認証方式のみが許可される。EAP 方式は結果指示を実装できる。authenticator が失敗の結果指示を peer に送信した後、peer の応答に関係なく、続いて Failure パケットを送信しなければならない (MUST)。authenticator が成功の結果指示を peer に送信し、peer から成功の結果指示を受信した後、続いて Success パケットを送信しなければならない (MUST)。
peer 側では、方式が正常に完了しなかった場合（すなわち、authenticator が失敗の結果指示を送信した、あるいは peer がおそらく失敗の結果指示を送信した後にセッションを続行しないことを決定した）、peer はセッションを終了し、下位層に失敗を指示しなければならない (MUST)。peer は Success パケットを黙って廃棄しなければならず (MUST)、Failure パケットを黙って廃棄してもよい (MAY)。したがって、Failure パケットの喪失が必ずしもタイムアウトを引き起こすとは限らない。
peer 側では、双方が成功の結果指示を交換した後、Failure パケットは黙って廃棄されなければならない (MUST)。peer は、EAP Success を受信しなかった場合、EAP Success パケットが失われ、認証が正常に完了したと推測してもよい (MAY)。
authenticator が結果指示を送信しておらず、peer がセッションを続行する意思がある場合、peer は方式の完了後に Success または Failure パケットを待機し、それらを黙って廃棄してはならない (MUST NOT)。Success パケットも Failure パケットも受信されなかった場合、peer は、失われたパケットが EAP Failure であった場合の長時間のタイムアウトを回避するために、セッションを終了すべきである (SHOULD)。
peer が authenticator 経由で認証を試みて失敗した場合、authenticator は Failure パケットを送信しなければならず (MUST)、Success パケットを送信してアクセスを許可してはならない (MUST NOT)。ただし、制限されたアクセス（たとえばゲストアクセス）が提供される状況では、authenticator は peer の認証を省略してもよい (MAY)。この場合、authenticator は Success パケットを送信しなければならない (MUST)。
peer が authenticator によって正常に認証されたが、authenticator が結果指示を送信しなかった場合、peer が現在ネットワークアクセスに対して認可されていない場合、authenticator は Failure パケットを送信してアクセスを拒否してもよい (MAY)。
Success パケットおよび Failure パケットのフォーマットの要約を以下に示す。フィールドは左から右へ送信される。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
3 for Success
4 for Failure
Identifier
Identifier フィールドは 1 オクテットであり、応答を応答と照合するのに役立つ。Identifier フィールドは、応答する Response パケットの Identifier フィールドと一致しなければならない (MUST)。
Length
4
4.3. 再送動作
認証プロセスはしばしばユーザ入力を伴うため、再送戦略と認証タイムアウトを決定する際には注意が必要である。デフォルトでは、信頼できない下位層上で EAP を実行する場合、EAP 再送タイマーは動的に推定されるべきである (SHOULD)。再送の最大回数は 3-5 回が推奨される。
信頼できる下位層（たとえば、[PIC] の ISAKMP/TCP over EAP）上で実行される場合、authenticator の再送タイマーは無限大に設定されるべきであり (SHOULD)、EAP 層での再送は発生しない。peer は、無期限に Request を待機しないように、タイムアウト値を維持してもよい (MAY)。
認証プロセスにユーザ入力が必要な場合、測定される往復時間はネットワーク特性ではなくユーザの応答性によって決まる可能性があるため、RTO の動的推定は役に立たない可能性がある。代わりに、再送タイマーはユーザが応答するのに十分な時間を提供するように設定されるべきであり (SHOULD)、トークンカードが関与する場合（セクション 5.6 参照）など、一部のケースではより長いタイムアウトが必要となる。
authenticator EAP に適切なタイムアウト値に関するガイダンスを提供するために、バックエンド認証サーバから（たとえば RADIUS Session-Timeout 属性を介して）authenticator に提案を伝えることができる。
EAP 再送タイマーを動的に推定するために、[RFC2988] で説明されている SRTT、RTTVAR、RTO を推定するアルゴリズム（Karn アルゴリズムの使用を含む）を、以下の修正を加えて使用することが推奨される。
[a] 分散システム間で固定タイマーを使用する場合に発生する可能性のある同期動作を避けるために、再送タイマーは RTO 値を使用して計算され、-RTOmin/2 から RTOmin/2 の間からランダムに抽出された値を加えることでジッタを発生させる。ジッタを発生させるために他の計算を使用してもよい (MAY)。これらは疑似ランダムでなければならない (MUST)。疑似乱数生成の議論については、[RFC1750] を参照のこと。
[b] EAP が単一のリンク上（インターネット上ではなく）で転送される場合、RTOinitial、RTOmin、RTOmax より小さい値を使用できる。推奨される値は、RTOinitial=1 秒、RTOmin=200ms、RTOmax=20 秒である。
[c] EAP が単一のリンク上（インターネット上ではなく）で転送される場合、推定はセッションごとではなく、authenticator ごとに行うことができる (MAY)。これにより、再送推定は下位層の動作に関する情報を最大限に活用できる。
[d] EAP 実装は、タイマーを複数回下げた後、SRTT および RTTVAR をクリアしてもよい (MAY)。この状況では現在の SRTT および RTTVAR が誤っている可能性が高いためである。SRTT および RTTVAR をクリアした後、[RFC2988] の式 2.2 で説明されているように、次にサンプリングされた RTT を使用して初期化されるべきである。