メインコンテンツまでスキップ

5. Initial EAP Request/Response Types

5. Initial EAP Request/Response Types​

使用する認証方式を決定するため、認証開始時に EAP Request/Response パケットが送信される。本書では、すべての EAP 実装に共通の初期タイプを定義する。Identity、Notification、Nak、MD5-Challenge、One-Time Password、Generic Token Card、および Expanded Nak である。残りの EAP タイプは EAP 方式ドキュメントで定義される。すべての EAP 実装は Identity、Nak、MD5-Challenge、One-Time Password、Generic Token Card、および Expanded Nak をサポートしなければならない (MUST)。

EAP 方式ドキュメントでは、その方式がフラグメント化 (fragmentation)、キー導出 (key derivation)、相互認証 (mutual authentication)、結果指示 (result indication) をサポートするかどうかを明記すべきである (SHOULD)。これらの属性は第 7.5 節で詳しく説明する。

5.1. Identity​

5.1.1. 概要​

Description

認証開始時に、オーセンティケータはピアに EAP-Request パケットの Identity を送信して、EAP-Request Identity に対する応答を要求してもよい (MAY)。ピアは、他の方法（たとえばダイヤルアップユーザーの発信者 ID）ですでに識別を認識していない限り、ピアのネットワークアクセス識別子 (NAI) [RFC2486] を含む EAP-Response Identity パケットで応答すべきである (SHOULD)。一部の環境では、オーセンティケータは NAI のドメイン部分を使用して認証要求をルーティングする場合がある（たとえば RADIUS プロキシ [RFC2865]）。NAI のその他の用途は [RFC2486] で説明されている。

オーセンティケータが EAP-Request Identity を送信して認証を開始しない場合、ピアは最初の EAP-Request を受信した後、NAI に対する応答を含む EAP-Response Identity を送信してもよい (MAY)。認証開始時にピアを直ちに認証する必要があり、ピアのアイデンティティが重要でない場合、オーセンティケータは EAP-Request Identity をバイパスし、別のタイプの EAP-Request（たとえば MD5-Challenge）を直接送信してもよい (MAY)。

Type

1

Type-Data

Type-Data フィールドには、ユーザーに表示され、入力を促すテキストで構成されるデータブロックが含まれていてもよい (MAY)。このテキストは UTF-8 でエンコードされた ISO 10646 文字 [ISO.10646] で表現されなければならない (MUST)。オーセンティケータは、ピアから EAP-Response を受信した直後に次の EAP-Request を送信すべきである (SHOULD)。タイプ 1 の EAP-Response パケットは、EAP-Request Identity の再送を引き起こすべきではない (SHOULD NOT)。

実装では、ピアおよびオーセンティケータ実装は、認証方式が必要に応じてアイデンティティ（たとえばトンネル方式の場合）を取得できるように、Identity Request/Response を認証方式から見えるようにすべきである (SHOULD)。

5.1.2. アイデンティティ管理​

一部の環境では、ピアのアイデンティティ情報が利用できない、または誤った提示（たとえば NAI の形式を使用しているが、2 つのピア間でユーザーを一意に識別するのに十分な情報を含んでいない）により、認証失敗を引き起こす可能性がある。EAP 展開におけるアイデンティティ管理の問題には、アイデンティティの選択とアイデンティティの保護が含まれる。

アイデンティティの選択

リンク確立時、ピアはオーセンティケータの機能を知らず、認証を開始するときにデフォルトのアイデンティティを使用してもよい (MAY)。証明書ベースの方式では、使用される証明書は通常ピアのアイデンティティを明らかにする。EAP-TLS [RFC2716]、EAP-TTLS [EAP-TTLS]、PEAP [PEAP] などの方式では、使用される証明書、ユーザー名、または匿名アイデンティティは、認証試行ごとに異なっていてもよい (MAY)。オーセンティケータがピアを認証した後、ピアが使用すべきユーザー名または証明書に関するガイダンス（たとえばトンネル内）を提供してもよい (MAY)。これは、初期アイデンティティネゴシエーションが失敗した後の 2 回目の認証試行で使用されるアイデンティティとして使用できる。

アイデンティティの保護

EAP 認証が完了する前に、ピアのアイデンティティが第三者に暴露される可能性がある。この暴露を防ぐため、EAP 方式はアイデンティティ保護（暗号化や匿名識別子によるなど）をサポートしてもよい (MAY)。EAP-TLS [RFC2716] では、トンネル内でアイデンティティを提供できるため、パッシブ盗聴から保護される。EAP-TTLS [EAP-TTLS] および PEAP [PEAP] では、初期ハンドシェイクに匿名アイデンティティを使用し、実際のアイデンティティはトンネル内で提供される。

5.2. Notification​

Description

値のタイプが Notification である EAP-Request または EAP-Response パケットは、人間が読めるメッセージを伝達するために使用される。ピアはこのメッセージをユーザーに表示してもよく (MAY)、記録および/または管理者に提示してもよい (MAY)。オーセンティケータは、ユーザーに関連する内容（たとえば「まもなく切断されます」）を通知するために通知を送信してもよい (MAY)。ピアは値が Notification である EAP-Response パケットで応答すべきであり (SHOULD)、メッセージを表示しないことを選択してもよい (MAY)（またはその一部のみを表示してもよい）。ただし、メッセージは UTF-8 でエンコードされた ISO 10646 文字 [ISO.10646] で提供されるべきである (SHOULD)。

Notification 要求が認証完了前に送信された場合、ピアはメッセージを表示しないことを選択したとしても、Notification 応答を送信すべきである (SHOULD)。EAP 認証プロセスの完了後に送信された通知は、ピアによって無視されてもよく (MAY)、他の EAP 方式に宛てられたデータを運ぶために絶対に使用してはならない (MUST NOT)。

Type

2

Type-Data

ユーザーに表示するテキストメッセージ。UTF-8 でエンコードされた ISO 10646 文字 [ISO.10646] を使用。

5.3. Nak​

5.3.1. Legacy Nak​

Description

ピアは、値のタイプが Nak である EAP-Response パケットを送信して、初期の EAP-Request に同意しないことをオーセンティケータに示す。NAK は、EAP-Request に応答し、かつ送信された初期応答が Nak でない場合にのみ送信され、認証開始付近でのみ送信されるべきである (SHOULD)。通常、Nak は、オーセンティケータがピアがサポートしない認証タイプを要求した場合にのみ送信されるが、ピアは要求された認証タイプをサポートしているが一部の構成詳細が受け入れられない場合（たとえば、ピアはその方式をサポートしているが NAS がその方式に必要なサービス品質を提供できない）にも送信される可能性がある。Nak を受信したとき、オーセンティケータは、ピアが Nak で提案した認証タイプを送信するか、別の EAP-Request を送信して応答してもよい (MAY)。EAP 方式ドキュメントでは、その方式が（Nak を介して）ネゴシエート可能か、または必須（認証開始時に実装される必要がある）かを明記してもよい (MAY)。

Nak は EAP の legacy 機能であり、拡張能力が限られていることに注意。新しい認証方式は Expanded Nak（第 5.3.2 節）を使用すべきである (SHOULD)。なぜなら、Nak は Expanded Type（第 5.3.2 節）に対する反対を表すために使用できないからである。さらに、一部の EAP 方式は Nak を使用するのではなく（たとえばトンネル方式内で）ネゴシエートするように設計されている。したがって、可能な場合は Expanded Nak を使用することを推奨する。

Type

3

Type-Data

従来の Nak では、Type-Data フィールドは 1 つ以上のオクテットで構成され、ピアが初期 Response で使用することを望む認証タイプを示す。たとえば、ピアが MD5-Challenge（タイプ 4）要求を受信したが、One-Time Password（タイプ 5）および Generic Token Card（タイプ 6）をサポートしている場合、値 5 および 6 を含む Type-Data フィールドを持つ Nak で応答する。

5.3.2. Expanded Nak​

Description

Expanded Nak は、EAP 方式タイプのネゴシエーションに使用される。Nak に似ているが、Expanded Type 形式（第 5.3.2 節）を使用する。Expanded Nak は、従来のタイプと Expanded タイプの両方に対する反対を表すことができる。

Type

254

Type-Data

Expanded Nak の場合、Type-Data フィールドは Vendor-Id および Vendor-Type（第 5.3.2 節参照）で始まる。Expanded Nak はネゴシエーションに使用されるため、Vendor-Type フィールドはピアが使用を望む認証方式タイプ（従来または Expanded）を示すために使用される。Vendor-Id フィールドはベンダーを示すために使用される。たとえば、Expanded Type が要求されたがピアが別の方式を好む場合、Expanded Nak の Vendor-Id および Vendor-Type はピアが好む方式を示すべきである。

5.4. MD5-Challenge​

5.4.1. 概要​

Description

MD5-Challenge タイプは、PPP CHAP プロトコル [RFC1994] に対応し、CHAP と同様の認証を EAP 内で提供する。MD5-Challenge は、共有秘密を用いた MD5 ハッシュ関数 [MD5] を使用して認証を行う。MD5-Challenge は最も広く展開されている EAP 方式であり、多くの既存の無線アクセスポイントに実装されている。MD5-Challenge は共有秘密上の相互認証を提供するが、キー導出やトンネリングはサポートしない。MD5-Challenge はアイデンティティ保護を提供しない。MD5-Challenge は辞書攻撃に対して脆弱である。

MD5-Challenge の具体的な実装は [RFC1994] 第 5 節にある。EAP では、MD5-Challenge パケットは CHAP と同様に計算されるが、主な違いは Value-Size および Response フィールドのエンコードである。EAP では、Value-Size は Value フィールドの一部として転送され、別のフィールドとしては転送されない。

Type

4

Type-Data

EAP MD5-Challenge の場合、Type-Data フィールドには Value-Size、Value、および Name フィールドが含まれ、形式は以下のとおり。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value-Size   |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Value-Size

Value フィールドの長さ（オクテット単位）を示す 1 オクテット。

Value

このフィールドにはハッシュ値またはチャレンジ値が含まれ、長さは Value-Size フィールドで示される。

Name

このフィールドには送信者のホスト名またはユーザー名が含まれる。このフィールドは UTF-8 でエンコードされた ISO 10646 文字 [ISO.10646] を含まなければならない (MUST)。

5.4.2. 実装ノート​

MD5-Challenge パケットは以下のように計算される。

[1] オーセンティケータは、Type フィールドを 4（MD5-Challenge）に設定し、Type-Data フィールドにチャレンジ値を含む EAP-Request パケットをピアに送信する。

[2] ピアでは、共有秘密、ピアの Identifier、チャレンジ値、および Name フィールドを入力として MD5 ハッシュ値を計算する。ピアはハッシュ値を含む EAP-Response パケットで応答する。

[3] オーセンティケータはハッシュ値を検証し、ハッシュ値が一致する場合、オーセンティケータはピアを正常に認証する。

5.5. ワンタイムパスワード (OTP)​

Description

One Time Password タイプは、[RFC2289] で定義されたワンタイムパスワードシステムに対応する。OTP タイプは、各パスワードが 1 回のみ使用されるワンタイムパスワードを使用した認証を可能にする。この方式は、毎回の認証試行で異なるパスワードを使用するため、リプレイ攻撃に対する保護を提供する。OTP は相互認証やキー導出を提供しない。

Type

5

Type-Data

OTP タイプの場合、Type-Data フィールドには、ユーザーに表示され、入力を促すテキストで構成されるデータブロックの後にスペースが続き、その後にワンタイムパスワードが続く。このテキストは UTF-8 でエンコードされた ISO 10646 文字 [ISO.10646] で表現されるべきである (SHOULD)。フィールドの具体的な形式は [RFC2289] で説明されている。

5.6. 汎用トークンカード (GTC)​

Description

Generic Token Card タイプは、さまざまなトークンカード実装をサポートするために使用される。GTC タイプは、オーセンティケータがチャレンジをピアに送信し、ピアがそのトークンカードを使用して応答を計算できるようにする。GTC はトークンカード実装の詳細を規定しない。代わりに、外部認証サーバーからのチャレンジ/レスポンスをピアに渡すことをサポートする。GTC は相互認証やキー導出を提供しない。

Type

6

Type-Data

GTC タイプの場合、Type-Data フィールドには、ユーザーに表示され、入力を促すテキストで構成されるデータブロックの後にスペースが続き、その後にトークンカードによって生成された値が続く。このテキストは UTF-8 でエンコードされた ISO 10646 文字 [ISO.10646] で表現されるべきである (SHOULD)。

5.7. 拡張タイプ (Expanded Types)​

説明

EAP の既存の用途の多くはベンダー固有であるため、拡張メソッドタイプ (Expanded Type) を利用して、一般的な用途に適さないベンダー独自の拡張タイプをサポートできる。

拡張タイプは、グローバルなメソッドタイプ空間を元の 255 の値を超えて拡張するためにも使用される。Vendor-Id が 0 の場合、元の 255 の可能なタイプを 2^32-1 の可能なタイプの空間にマッピングする。(タイプ 0 は、受け入れ可能な代替がないことを示すために Nak 応答でのみ使用される)。

拡張属性をサポートする実装は、256 未満の EAP タイプを、単一のオクテットとして現れるか、Vendor-Id が 0 の拡張タイプ内の 32 ビット Vendor-Type として現れるかに関わらず、同等に扱わなければならない (MUST)。拡張タイプを解釈できないピアは、セクション 5.3.1 で説明されているように Nak を送信し、より適切な認証方式をネゴシエートしなければならない (MUST)。

拡張タイプのフォーマットの要約を以下に示す。フィールドは左から右へ送信される。

    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      |   Vendor-Id (cont)            | Vendor-Type...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor-Type (cont)                 |  Vendor-Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

拡張タイプ (Expanded Type) を示す 254

Vendor-Id

Vendor-Id は 3 オクテットであり、IANA によって割り当てられたベンダーの SMI Network Management Private Enterprise Code をネットワークバイトオーダーで表す。Vendor-Id がゼロの場合は、拡張されたグローバル EAP タイプ空間を提供するために IETF による使用のために予約されている。

Vendor-Type

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

Vendor-Id がゼロの場合、Vendor-Type フィールドは既存の EAP タイプ名前空間の拡張およびスーパーセットである。最初の 256 タイプは、すでに割り当てられている、または将来割り当てられる可能性のある単一オクテット EAP タイプとの互換性のために予約されている。したがって、タイプ 0 から 255 の EAP タイプは、単一オクテット EAP タイプとして現れるか、Vendor-Id がゼロの場合の Vendor-Type として現れるかに関わらず、意味的に同一である。この規則には 1 つの例外がある。Expanded Nak と Legacy Nak パケットは同じ Type を共有するが、フォーマットが異なるため異なる方法で扱わなければならない。

Vendor-Data

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

5.8. 実験的 (Experimental)​

説明

実験的タイプ (Experimental Type) には固定のフォーマットや内容はない。新しい EAP タイプの試験時に使用することを意図している。このタイプは実験およびテストの目的で意図されている。[RFC3692] で概説されているように、このタイプを使用するピア間の相互運用性については一切保証されない。

Type

255

Type-Data

未定義 (Undefined)