4. EAPパケットフォーマット

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 (コード)

Codeフィールドは1オクテットで、EAPパケットのタイプを識別します。EAPコードは次のように割り当てられます:

1 Request 2 Response 3 Success 4 Failure

EAPはコード1-4のみを定義しているため、他のコードを持つEAPパケットは認証器とピアの両方によって静かに破棄される必要があります (MUST)。

Identifier (識別子)

Identifierフィールドは1オクテットで、応答を要求と照合するのに役立ちます。

Length (長さ)

Lengthフィールドは2オクテットで、Code、Identifier、Length、Dataフィールドを含むEAPパケットの長さをオクテット単位で示します。Lengthフィールドの範囲外のオクテットはデータリンク層パディングとして扱われるべきであり、受信時に無視される必要があります (MUST)。Lengthフィールドが受信したオクテット数より大きい値に設定されているメッセージは静かに破棄される必要があります (MUST)。

Data (データ)

Dataフィールドは0個以上のオクテットです。DataフィールドのフォーマットはCodeフィールドによって決定されます。

4.1. リクエストとレスポンス (Request and Response)

説明

Requestパケット (Codeフィールドが1に設定) は認証器からピアに送信されます。各Requestには、要求されているものを示すTypeフィールドがあります。有効なResponseパケットが受信されるか、オプションの再試行カウンターが期限切れになるか、下位層の障害指示が受信されるまで、追加のRequestパケットを送信する必要があります (MUST)。

再送信されるRequestsは、新しいRequestsと区別するために同じIdentifier値で送信される必要があります (MUST)。dataフィールドの内容はRequest Typeに依存します。ピアは有効なRequestパケットに応答してResponseパケットを送信する必要があります (MUST)。Responsesは有効なRequestに応答してのみ送信される必要があり (MUST)、タイマーで再送信されることはありません。

ピアがすでにResponseを送信した有効な重複Requestを受信した場合、Requestを再処理せずに元のResponseを再送信する必要があります (MUST)。Requestsは受信した順序で処理される必要があり (MUST)、次の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 (コード)

1はRequest用 2はResponse用

Identifier (識別子)

Identifierフィールドは1オクテットです。Responseを待っているタイムアウトのためにRequestパケットが再送信される場合、Identifierフィールドは同じである必要があります (MUST)。新しい (再送信ではない) Requestsは、Identifierフィールドを変更する必要があります (MUST)。

ResponseのIdentifierフィールドは、現在未処理のRequestのIdentifierフィールドと一致する必要があります (MUST)。Identifier値が現在未処理のRequestと一致しないResponseを受信する認証器は、Responseを静かに破棄する必要があります (MUST)。

新しいRequestsと再送信の混乱を避けるために、各新しいRequestに選択されるIdentifier値は前のRequestと異なるだけでよく、会話内で一意である必要はありません。これを実現する1つの方法は、Identifierを初期値から開始し、新しいRequestごとにインクリメントすることです。ゼロから始めるのではなく、最初のIdentifierをランダムな数で初期化することが推奨されます。これによりシーケンス攻撃がやや困難になります。

Identifier空間は各セッションに固有であるため、認証器は256の同時認証会話のみに制限されません。同様に、再認証により、EAP会話は長期間にわたって続く可能性があり、256往復のみに制限されません。

実装ノート: 認証器はRequestメッセージの再送信を担当します。Requestメッセージが他の場所から取得される場合 (バックエンド認証サーバーからなど)、認証器はこれを実現するためにRequestのコピーを保存する必要があります。ピアは、外部パーティーに渡すことを含め、あらゆる方法で処理する前に、重複Requestメッセージを検出して処理する責任があります。認証器は、検証のためにバックエンド認証サーバーに渡すことを含め、あらゆる方法で行動する前に、一致しないIdentifier値を持つResponseメッセージを破棄する責任もあります。認証器はピアからResponseを受信する前に再送信できるため、認証器は複数のResponsesを受信できます。それぞれが一致するIdentifierを持っています。認証器が新しいRequestを受信するまで、Identifier値は更新されないため、認証器はResponsesをバックエンド認証サーバーに一度に1つずつ転送します。

Length (長さ)

Lengthフィールドは2オクテットで、Code、Identifier、Length、Type、Type-Dataフィールドを含むEAPパケットの長さを示します。Lengthフィールドの範囲外のオクテットはデータリンク層パディングとして扱われるべきであり、受信時に無視される必要があります (MUST)。Lengthフィールドが受信したオクテット数より大きい値に設定されているメッセージは静かに破棄される必要があります (MUST)。

Type (タイプ)

Typeフィールドは1オクテットです。このフィールドはRequestまたはResponseのTypeを示します。各EAP RequestまたはResponseに対して単一のTypeを指定する必要があります (MUST)。Typesの初期仕様は、このドキュメントのセクション5に続きます。

ResponseのTypeフィールドは、Requestのフィールドと一致するか、Request TypeがピアにとってAcceptableでないことを示すレガシーまたはExpanded Nak (セクション5.3を参照) に対応する必要があります (MUST)。ピアは、初期の非Nak Responseが送信された後、Requestに応答してNak (レガシーまたは拡張) を送信してはなりません (MUST NOT)。これらの要件を満たさないResponseを受信するEAPサーバーは、それを静かに破棄する必要があります (MUST)。

Type-Data

Type-DataフィールドはRequestのTypeと関連するResponseによって変化します。

4.2. 成功と失敗 (Success and Failure)

Successパケットは、EAP認証メソッド (Type 4以上) の完了後、ピアが認証器に正常に認証されたことを示すために認証器からピアに送信されます。認証器はCodeフィールドが3 (Success) に設定されたEAPパケットを送信する必要があります (MUST)。認証器がピアを認証できない場合 (1つ以上のRequestsに対するAcceptableでないResponses)、進行中のEAPメソッドの失敗した完了の後、実装はCodeフィールドが4 (Failure) に設定されたEAPパケットを送信する必要があります (MUST)。認証器は、人間のタイプミスを許可するために、Failure応答を送信する前に複数のRequestsを発行することを望む場合があります (MAY)。SuccessおよびFailureパケットは追加のデータを含んではなりません (MUST NOT)。

与えられたメソッドの仕様がメソッドがその時点で終了することを明示的に許可していない場合、EAP認証器によってSuccessおよびFailureパケットを送信してはなりません (MUST NOT)。送信が明示的に許可されていない場合にSuccessまたはFailureパケットを受信するピアEAP実装は、それを静かに破棄する必要があります (MUST)。デフォルトでは、EAPピアは「缶詰」Successパケット (接続直後に送信されるSuccessパケット) を静かに破棄する必要があります (MUST)。これにより、不正な認証器がEAPメソッド会話の終了前にSuccessパケットを送信することによって相互認証をバイパスできないことが保証されます。

実装ノート: SuccessおよびFailureパケットは確認されないため、認証器によって再送信されず、失われる可能性があります。このノートで説明されているように、ピアはこの状況を許可する必要があります (MUST)。下位層の成功と失敗の指示の処理に関するガイダンスについては、セクション3.4も参照してください。

セクション2.1で説明されているように、EAP会話内では単一のEAP認証メソッドのみが許可されます。EAPメソッドは結果指示を実装できます。認証器がピアに失敗結果指示を送信した後、ピアからの応答に関係なく、その後Failureパケットを送信する必要があります (MUST)。認証器がピアに成功結果指示を送信し、ピアから成功結果指示を受信した後、その後Successパケットを送信する必要があります (MUST)。

ピアでは、メソッドが失敗して完了すると (つまり、認証器が失敗結果指示を送信するか、ピアが会話を続けたくないと判断した場合、失敗結果指示を送信した後に可能性があります)、ピアは会話を終了し、下位層に失敗を示す必要があります (MUST)。ピアはSuccessパケットを静かに破棄する必要があり (MUST)、Failureパケットを静かに破棄できます (MAY)。その結果、Failureパケットの損失はタイムアウトにつながる必要はありません。

ピアでは、両側が成功結果指示を交換した後、Failureパケットは静かに破棄される必要があります (MUST)。EAP Successが受信されない場合、ピアはEAP Successパケットが失われ、認証が正常に終了したと結論付けることができます (MAY)。

認証器が結果指示を送信しておらず、ピアが会話を続ける意思がある場合、ピアはメソッドが完了したらSuccessまたはFailureパケットを待ち、どちらも静かに破棄してはなりません (MUST NOT)。SuccessもFailureパケットも受信されない場合、失われたパケットがEAP Failureだった場合に長いタイムアウトを避けるために、ピアは会話を終了すべきです (SHOULD)。

ピアが認証器に認証しようとして失敗した場合、認証器はFailureパケットを送信する必要があり (MUST)、Successパケットを送信してアクセスを許可してはなりません (MUST NOT)。ただし、限られたアクセスが提供される状況 (ゲストアクセスなど) では、認証器はピアに認証させることを省略できます (MAY)。この場合、認証器はSuccessパケットを送信する必要があります (MUST)。

ピアが認証器に正常に認証されたが、認証器が結果指示を送信しない場合、ピアが現在ネットワークアクセスを許可されていない場合、認証器は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 (コード)

3はSuccess用 4はFailure用

Identifier (識別子)

Identifierフィールドは1オクテットで、応答をResponsesと照合するのに役立ちます。Identifierフィールドは、応答して送信されるResponseパケットのIdentifierフィールドと一致する必要があります (MUST)。

Length (長さ)

4.3. 再送信動作 (Retransmission Behavior)

認証プロセスにはユーザー入力が含まれることが多いため、再送信戦略と認証タイムアウトを決定する際には注意が必要です。デフォルトでは、EAPが信頼性のない下位層で実行される場合、EAP再送信タイマーは動的に推定されるべきです (SHOULD)。最大3〜5回の再送信が推奨されます。

信頼性のある下位層で実行される場合 (たとえば、[PIC] 内のEAP over ISAKMP/TCP)、認証器再送信タイマーは無限の値に設定されるべきです (SHOULD)。これにより、EAP層で再送信が発生しなくなります。ピアは、Requestを無期限に待機しないようにタイムアウト値を維持できます。

認証プロセスにユーザー入力が必要な場合、測定されたラウンドトリップ時間はネットワーク特性ではなくユーザーの応答性によって決定される可能性があるため、動的RTO推定は役立たない可能性があります。代わりに、再送信タイマーはユーザーが応答するのに十分な時間を提供するように設定されるべきです (SHOULD)。特定のケース (トークンカードが関与する場合など (セクション5.6を参照)) では、より長いタイムアウトが必要です。

EAP認証器に適切なタイムアウト値に関するガイダンスを提供するために、ヒントをバックエンド認証サーバーから認証器に伝達できます (RADIUS Session-Timeout属性など)。

EAP再送信タイマーを動的に推定するために、[RFC2988] で説明されているSRTT、RTTVAR、RTOの推定アルゴリズムが推奨されます (RECOMMENDED)。Karnのアルゴリズムの使用を含め、次の潜在的な変更があります:

[a] 分散システム間の固定タイマーで発生する可能性のある同期動作を回避するために、再送信タイマーはRTO値を使用し、-RTOmin/2とRTOmin/2の間で描画された値をランダムに追加することによってジッターで計算されます。ジッターを作成するための代替計算を使用できます (MAY)。これらは疑似ランダムである必要があります (MUST)。疑似乱数生成の議論については、[RFC1750] を参照してください。

[b] EAPが単一リンクで転送される場合 (インターネット経由ではなく)、RTOinitial、RTOmin、およびRTOmaxのより小さい値を使用できます (MAY)。推奨値は、RTOinitial=1秒、RTOmin=200ms、RTOmax=20秒です。

[c] EAPが単一リンクで転送される場合 (インターネット経由ではなく)、推定はセッションごとではなく認証器ごとに行うことができます (MAY)。これにより、再送信推定はリンク層動作に関する情報を最大限に活用できます。

[d] EAP実装は、タイマーを複数回バックオフした後、SRTTとRTTVARをクリアできます (MAY)。この状況では、現在のSRTTとRTTVARが間違っている可能性が高いためです。SRTTとRTTVARがクリアされると、[RFC2988] 式2.2で説明されているように、次のRTTサンプルで初期化する必要があります。