5. 初期EAPリクエスト/レスポンスタイプ

このセクションでは、リクエスト/レスポンス交換で使用される EAP タイプの初期セットを定義します。将来のドキュメントでさらに多くのタイプが定義される可能性があります。Type フィールドは 1 オクテットで、EAP Request または Response パケットの構造を識別します。最初の 3 つのタイプは特殊なケースタイプと見なされます。

残りのタイプは認証交換を定義します。Nak (Type 3) または Expanded Nak (Type 254) は Response パケットに対してのみ有効であり、Request で送信してはなりません (MUST NOT)。

すべての EAP 実装は、このドキュメントで定義されている Types 1-4 をサポートする必要があり (MUST)、Type 254 をサポートすべきです (SHOULD)。実装は、ここまたは将来の RFC で定義されている他の Types をサポートできます (MAY)。

1 Identity 2 Notification 3 Nak (Response のみ) 4 MD5-Challenge 5 One Time Password (OTP) 6 Generic Token Card (GTC) 254 Expanded Types 255 実験的使用

EAP メソッドは共有秘密に基づく認証をサポートできます (MAY)。共有秘密がユーザーが入力したパスフレーズである場合、実装は非 ASCII 文字を含むパスフレーズの入力をサポートできます (MAY)。その場合、入力は適切な stringprep [RFC3454] プロファイルで処理され、UTF-8 エンコーディング [RFC2279] を使用してオクテットにエンコードされるべきです。[SASLPREP] には、可能な stringprep プロファイルの初期版が記載されています。

5.1. Identity

説明

Identity Type はピアの ID を照会するために使用されます。通常、認証器はこれを初期 Request として発行します。オプションの表示可能メッセージを含めることができ (MAY)、ユーザーとの対話が予想される場合にピアにプロンプトを表示します。Type 1 (Identity) の Request に応答して、Type 1 (Identity) の Response を送信する必要があります (SHOULD)。

一部の EAP 実装では、NUL 文字の後に Identity Request にさまざまなオプションを追加します。デフォルトでは、EAP 実装は Identity Request または Response が 1020 オクテットを超える可能性があると仮定すべきではありません (SHOULD NOT)。

Identity Response は主にルーティング目的および使用する EAP メソッドを選択するために使用することが推奨されます (RECOMMENDED)。EAP メソッドは、Identity Response に依存する必要がないように、ID を取得するためのメソッド固有のメカニズムを含むべきです (SHOULD)。Identity Request と Response は平文で送信されるため、攻撃者は ID を盗聴したり、ID 交換を変更または偽装したりすることができます。これらの脅威に対処するために、EAP メソッドには、パケットごとの認証、完全性、リプレイ保護、機密性をサポートする ID 交換を含めることが最善です。Identity Response は、そのメソッドの適切な ID ではない可能性があります。プライバシーを提供するために切り詰められたり難読化されたりしているか、ルーティング目的で装飾されている可能性があります。ピアが保護された ID 交換をサポートする認証メソッドのみを受け入れるように構成されている場合、ピアは省略形の Identity Response（たとえば、NAI [RFC2486] のピア名部分を省略する）を提供できます (MAY)。ID 保護の詳細については、セクション 7.3 を参照してください。

実装に関する注意：ピアはユーザー入力から ID を取得できます (MAY)。無効な ID または認証失敗の場合に Identity Request を再試行して、ユーザーの入力ミスの可能性を許可することが推奨されます。認証を終了する前に、Identity Request を少なくとも 3 回再試行することが推奨されます。無効な認証試行を示すために、新しい Identity Request を送信する前に Notification Request を使用できます (MAY)（オプションで、新しい Identity Request 自体のメッセージで失敗を示すこともできます (MAY)）。

Type

Type-Data

このフィールドは、Request に UTF-8 エンコードされた ISO 10646 文字 [RFC2279] を含む表示可能メッセージを含むことができます (MAY)。Request に null 値が含まれている場合、null の前のフィールドの部分のみが表示されます。ID が不明な場合、Identity Response フィールドの長さはゼロバイトである必要があります。Identity Response フィールドは null で終了してはなりません (MUST NOT)。すべての場合において、Type-Data フィールドの長さは Request/Response パケットの Length フィールドから派生します。

セキュリティ要求（セクション 7.2 参照）：

認証メカニズム：なし暗号スイートネゴシエーション：なし相互認証：なし完全性保護：なしリプレイ保護：なし機密性：なし鍵導出：なし鍵強度：該当なし辞書攻撃保護：該当なし高速再接続：なし暗号化バインディング：該当なしセッション独立性：該当なしフラグメンテーション：なしチャネルバインディング：なし

5.2. Notification

説明

Notification Type は、認証器からピアに表示可能なメッセージを伝達するためにオプションで使用されます。認証器は、EAP 認証メソッドが完了する前に、未処理の Request がないときにいつでも、ピアに Notification Request を送信できます (MAY)。ピアは、EAP 認証メソッド仕様が Notification メッセージの使用を禁止していない限り、Notification Request に Notification Response で応答する必要があります (MUST)。いかなる場合でも、Notification Request に応答して Nak Response を送信してはなりません (MUST NOT)。Notification Request のデフォルトの最大長は 1020 オクテットであることに注意してください。デフォルトでは、これにより人間が読めるメッセージに最大 1015 オクテットが残されます。

EAP メソッドは、そのメソッド中に Notification メッセージを送信してはならないことを仕様で示すことができます (MAY)。その場合、ピアは、同じ Type の Response で Type の初期 Request に応答する時点から、Notification Request を静かに破棄する必要があります (MUST)。

ピアはこのメッセージをユーザーに表示するか、表示できない場合は記録する必要があります (SHOULD)。Notification Type は、ある種の必要性のある確認された通知を提供することを目的としていますが、エラー指示ではないため、ピアの状態を変更しません。例には、まもなく期限切れになるパスワード、ゼロに近づく OTP シーケンス整数、認証失敗警告などが含まれます。ほとんどの場合、Notification は必要ないはずです。

Type

Type-Data

Request の Type-Data フィールドには、UTF-8 エンコードされた ISO 10646 文字 [RFC2279] を含む、ゼロオクテットより大きい長さの表示可能メッセージが含まれます。メッセージの長さは Request パケットの Length フィールドによって決定されます。メッセージは null で終了してはなりません (MUST NOT)。Type フィールドが 2 (Notification) の Request に応答するために、Response を送信する必要があります (MUST)。Response の Type-Data フィールドの長さはゼロオクテットです。Response はすぐに送信される必要があります（メッセージの表示または記録方法に関係なく）。

セキュリティ要求（セクション 7.2 参照）：

5.3. Nak

5.3.1. レガシー Nak

説明

レガシー Nak Type は Response メッセージでのみ有効です。目的の認証 Type が受け入れられない Request への応答として送信されます。認証タイプは 4 以上に番号付けされています。Response には、ピアが望む 1 つ以上の認証タイプが含まれます。タイプゼロ (0) は、送信者に実行可能な代替手段がないことを示すために使用されます。そのため、認証器は、ゼロ値を含む Nak Response を受信した後、別の Request を送信すべきではありません (SHOULD NOT)。

レガシー Nak Type は Responses でのみ有効で機能が非常に限られているため、一般的なエラー指示として使用してはなりません (MUST NOT)。たとえば、エラーメッセージ通信や特定の EAP メソッドに固有のパラメーターネゴシエーションには使用できません。

Code

2 (Response 用)。

Identifier

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

Length

=6

Type

Type-Data

ピアが受け入れられない認証 Type (4-253, 255) の Request を受信した場合、または Expanded Types のサポートがないピアが Type 254 の Request を受信した場合、Nak Response (Type 3) を送信する必要があります (MUST)。Nak Response (Type 3) の Type-Data フィールドには、目的の認証タイプを示す 1 つ以上のオクテット（タイプごとに 1 オクテット）、または代替案の提案がない場合は値ゼロ (0) を含める必要があります (MUST)。Expanded Types をサポートし、受け入れられない認証 Type (4-253, 255) の Request を受信したピアは、Expanded 認証 Type の必要性を示すために、Nak Response (Type 3) に値 254 を含めることができます (MAY)。認証器がこの好みを満たすことができる場合、Expanded Type Request (Type 254) で応答します。

セキュリティ要求（セクション 7.2 参照）：

5.3.2. 拡張 Nak (Expanded Nak)

説明

Expanded Nak Type は Response メッセージでのみ有効です。認証 Type が受け入れられない Type 254 (Expanded Type) の Request への応答としてのみ送信される必要があります (MUST)。Expanded Nak Type 自体は Expanded Type 形式を使用し、Response には、すべて Expanded Type 形式の、ピアが望む 1 つ以上の認証タイプが含まれます。タイプゼロ (0) は、送信者に実行可能な代替手段がないことを示すために使用されます。Expanded Type の一般的な形式は、セクション 5.7 で説明されています。

Expanded Nak Type は Responses でのみ有効で機能が非常に限られているため、一般的なエラー指示として使用してはなりません (MUST NOT)。たとえば、エラーメッセージ通信や特定の EAP メソッドに固有のパラメーターネゴシエーションには使用できません。

Code

2 (Response 用)。

Identifier

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

Length

=20

Type

254

Vendor-Id

0 (IETF)

Vendor-Type

3 (Nak)

Vendor-Data

Expanded Nak Type は、Request にセクション 5.7 で定義されている Expanded Type (254) が含まれている場合にのみ送信されます。Nak Response の Vendor-Data フィールドには、すべて拡張形式の、1 つ以上の認証タイプ（4 以上）（タイプごとに 8 オクテット）、または代替案の提案がない場合は値ゼロ (0)（Expanded Type 形式でも）を含める必要があります (MUST)。目的の認証タイプには、ベンダー固有タイプと IETF タイプの混合が含まれる場合があります。たとえば、OTP (Type 5) と MIT (Vendor-Id=20) Expanded Type 6 の好みを示す Expanded Nak 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

目的の代替案がないことを示す Expanded Nak 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

セキュリティ要求（セクション 7.2 参照）：

5.4. MD5-Challenge

説明

MD5-Challenge Type は PPP CHAP プロトコル [RFC1994] (MD5 を指定されたアルゴリズムとして) に類似しています。Request にはピアへの「チャレンジ」メッセージが含まれます。Request に応答するために Response を送信する必要があります (MUST)。Response は、Type 4 (MD5-Challenge)、Nak (Type 3)、または Expanded Nak (Type 254) である場合があります (MAY)。Nak 応答は、ピアが望む認証タイプを示します。EAP ピアおよび EAP サーバー実装は MD5-Challenge メカニズムをサポートする必要があります (MUST)。パススルーのみをサポートする認証器は、MD5-Challenge をサポートできるバックエンド認証サーバーとの通信を許可する必要があります (MUST)が、EAP 認証器実装自体が MD5-Challenge をサポートする必要はありません。ただし、EAP 認証器がピアをローカルで認証するように構成できる場合（たとえば、パススルー方式で動作しない場合）、MD5-Challenge メカニズムをサポートする要件が適用されます。

MD5-Challenge Type での Identifier フィールドの使用は、[RFC1994] で説明されているものとは異なることに注意してください。EAP では MD5-Challenge Request パケットの再送信が可能ですが、[RFC1994] では、Challenge（MD5-Challenge Request パケットの CHAP 同等物）が送信されるたびに、Identifier と Challenge フィールドを変更する必要があります (MUST)。

注：[RFC1994] は共有秘密をオクテット文字列として扱い、システムへの入力方法（またはユーザーが処理するかどうか）を指定していません。EAP MD5-Challenge 実装は、非 ASCII 文字を含むパスフレーズの入力をサポートできます (MAY)。入力の処理方法とオクテットへのエンコード方法については、セクション 5 を参照してください。

Type

Type-Data

Type-Data フィールドの内容は次のように要約されます。これらのフィールドの使用については、PPP Challenge Handshake Authentication Protocol [RFC1994] を参照してください。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

セキュリティ要求（セクション 7.2 参照）：

認証メカニズム：パスワードまたは事前共有鍵暗号スイートネゴシエーション：なし相互認証：なし完全性保護：なしリプレイ保護：なし機密性：なし鍵導出：なし鍵強度：該当なし辞書攻撃保護：なし高速再接続：なし暗号化バインディング：該当なしセッション独立性：該当なしフラグメンテーション：なしチャネルバインディング：なし

5.5. ワンタイムパスワード (One-Time Password, OTP)

説明

ワンタイムパスワードシステムは、「ワンタイムパスワードシステム」[RFC2289] および「OTP 拡張レスポンス」[RFC2243] で定義されています。Request には、[RFC2289] で説明されている形式の OTP チャレンジが含まれます。Request に応答するために Response を送信する必要があります (MUST)。Response は、Type 5 (OTP)、Nak (Type 3)、または Expanded Nak (Type 254) である必要があります (MUST)。Nak Response は、ピアが望む認証タイプを示します。EAP OTP メソッドは、ワンタイムパスワードシステム専用であり、平文パスワードのサポートを提供するために使用してはなりません (MUST NOT)。

Type

Type-Data

Type-Data フィールドには、Request では表示可能メッセージとして OTP「チャレンジ」が含まれます。Response では、このフィールドは OTP ディクショナリ [RFC2289] の 6 語に使用されます。メッセージは null で終了してはなりません (MUST NOT)。フィールドの長さは、Request/Reply パケットの Length フィールドから派生します。

注：[RFC2289] は、ユーザーが鍵パスフレーズを入力する方法、またはパスフレーズをオクテットに変換する方法を指定していません。EAP OTP 実装は、非 ASCII 文字を含むパスフレーズの入力をサポートできます (MAY)。入力の処理方法とオクテットへのエンコード方法については、セクション 5 を参照してください。

セキュリティ要求（セクション 7.2 参照）：

認証メカニズム：ワンタイムパスワード暗号スイートネゴシエーション：なし相互認証：なし完全性保護：なしリプレイ保護：あり機密性：なし鍵導出：なし鍵強度：該当なし辞書攻撃保護：なし高速再接続：なし暗号化バインディング：該当なしセッション独立性：該当なしフラグメンテーション：なしチャネルバインディング：なし

5.6. 汎用トークンカード (Generic Token Card, GTC)

説明

Generic Token Card Type は、ユーザー入力を必要とするさまざまなトークンカード実装で使用するために定義されています。Request には表示可能メッセージが含まれ、Response には認証に必要なトークンカード情報が含まれます。通常、これはユーザーがトークンカードデバイスから読み取り、ASCII テキストとして入力する情報です。Request に応答するために Response を送信する必要があります (MUST)。Response は、Type 6 (GTC)、Nak (Type 3)、または Expanded Nak (Type 254) である必要があります (MUST)。Nak Response は、ピアが望む認証タイプを示します。EAP GTC メソッドは、チャレンジ/レスポンス認証をサポートするトークンカード用であり、サーバー認証を備えた保護されたトンネルがない場合、平文パスワードのサポートを提供するために使用してはなりません (MUST NOT)。

Type

Type-Data

Request の Type-Data フィールドには、ゼロオクテットより大きい長さの表示可能メッセージが含まれます。メッセージの長さは Request パケットの Length フィールドによって決定されます。メッセージは null で終了してはなりません (MUST NOT)。Type フィールドが 6 (Generic Token Card) の Request に応答するために、Response を送信する必要があります (MUST)。Response には、認証に必要なトークンカードデータが含まれます。データの長さは Response パケットの Length フィールドによって決定されます。

EAP GTC 実装は、非 ASCII 文字を含むレスポンスの入力をサポートできます (MAY)。入力の処理方法とオクテットへのエンコード方法については、セクション 5 を参照してください。

セキュリティ要求（セクション 7.2 参照）：

認証メカニズム：ハードウェアトークン暗号スイートネゴシエーション：なし相互認証：なし完全性保護：なしリプレイ保護：なし機密性：なし鍵導出：なし鍵強度：該当なし辞書攻撃保護：なし高速再接続：なし暗号化バインディング：該当なしセッション独立性：該当なしフラグメンテーション：なしチャネルバインディング：なし

5.7. 拡張タイプ (Expanded Types)

説明

EAP の既存の使用の多くはベンダー固有であるため、Expanded メソッド Type は、ベンダーが一般的な使用に適していない独自の Expanded Types をサポートできるようにするために利用可能です。

Expanded Type は、元の 255 個の値を超えてグローバルメソッド Type 空間を拡張するためにも使用されます。Vendor-Id が 0 の場合、元の 255 個の可能な Types が 2^32-1 個の可能な Types 空間にマッピングされます。（Type 0 は、Nak Response でのみ、受け入れ可能な代替案がないことを示すために使用されます。）

Expanded 属性をサポートする実装は、256 未満の EAP Types を、単一オクテットとして表示される場合でも、Vendor-Id が 0 の Expanded Type 内の 32 ビット Vendor-Type として表示される場合でも、同等に扱う必要があります (MUST)。Expanded Type を解釈する装備がないピアは、セクション 5.3.1 で説明されているように Nak を送信し、より適切な認証メソッドをネゴシエートする必要があります (MUST)。

Expanded Type 形式の概要を次に示します。フィールドは左から右に送信されます。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

254 (Expanded Type 用)

Vendor-Id

Vendor-Id は 3 オクテットで、IANA によって割り当てられた、ベンダーの SMI ネットワーク管理プライベートエンタープライズコード（ネットワークバイトオーダー）を表します。Vendor-Id がゼロの場合、拡張されたグローバル EAP Type 空間を提供するために IETF 用に予約されています。

Vendor-Type

Vendor-Type フィールドは 4 オクテットで、ベンダー固有のメソッド Type を表します。

Vendor-Id がゼロの場合、Vendor-Type フィールドは既存の EAP Types 名前空間の拡張およびスーパーセットです。最初の 256 Types は、割り当てられているか将来割り当てられる可能性のある単一オクテット EAP Types との互換性のために予約されています。したがって、0 から 255 の EAP Types は、単一オクテット EAP Types として表示される場合でも、Vendor-Id がゼロのときに Vendor-Types として表示される場合でも、意味的に同一です。この規則には 1 つの例外があります。Expanded Nak と Legacy Nak パケットは同じ Type を共有しますが、形式が異なるため、区別して扱う必要があります。

Vendor-Data

Vendor-Data フィールドはベンダーによって定義されます。Vendor-Id がゼロの場合、Vendor-Data フィールドは、IETF 定義の Types の EAP メソッドの内容を伝達するために使用されます。

5.8. 実験的 (Experimental)

説明

Experimental Type には固定のフォーマットや内容はありません。新しい EAP Types を実験する際に使用することを目的としています。このタイプは実験およびテスト目的で使用されます。[RFC3692] で説明されているように、このタイプを使用するピア間の相互運用性は保証されません。

Type

255

Type-Data

未定義