はじめに
EAP-TEAP（Tunneled EAP）は、従来の EAP-TTLS と PEAP を統合し、より安全で柔軟なトンネル型認証を実現するために策定された新しい方式です。
多くの人が「TEAP = TTLS の改良版」と捉えますが、実際には 802.1X 認証の運用思想そのものを変える要素を含んでいます。
本記事では、EAP-TEAP の内部構造・特徴・利点・運用上の注意点を、EAP-TLS / TTLS / PEAP との比較を交えながら整理します。
EAP-TLS / EAP-TTLS についてはこちらにまとめがあります。
TEAP の誕生背景
EAP-TEAP は RFC 7170（2014 年）で定義され、IETF と Cisco/Microsoft を中心に策定されました。目的は、次の二つを同時に満たすことです。
- EAP-TTLS/PEAP の断片的な実装を統合
- 証明書と ID 認証のハイブリッド化（柔軟性と自動化）
EAP-TEAP の基本構造
EAP-TEAP も EAP-TTLS と同様に、サーバー側の証明書で TLS トンネルを張ります。その内部（トンネル内）では、複数の認証手段を柔軟に組み合わせられるのが特徴です。
レイヤ構造は以下のようになります：
| 層 | 役割 |
|---|---|
| IEEE802.1X | ネットワークアクセス制御の枠組み |
| EAP | 拡張認証プロトコル |
| EAP-TEAP | トンネル確立＋内部 EAP 認証（複数可） |
| TLS | 暗号化された通信経路を提供 |
TEAP の内部構造とフェーズ
EAP-TEAP は 2 段階のフェーズで構成されます。
フェーズ 1: 外部認証（Outer Authentication）
- サーバー証明書を検証し、TLSトンネルを確立
- オプションでクライアント証明書を使用可能（EAP-TLS 的構造）
フェーズ 2: 内部認証（Inner Authentication）
- トンネル内部で、ユーザー ID やデバイス ID などを別の EAP 方式で認証
- 複数の内部 EAP（例: EAP-MSCHAPv2 + EAP-TLS）を組み合わせ可能
- PAC（Protected Access Credential）による再認証もサポート
特徴とメリット
- 二重認証（デバイス＋ユーザー）の統合
- TEAP は、同一セッション内でマシン認証とユーザー認証を順次実施可能。
- PAC による再認証高速化
- 一度確立したセッション情報をキャッシュして再利用可能。
- 証明書・パスワードの併用
- クライアント証明書を必須にせず、ID/パスワードや別 EAP 方式を内部で利用可能。
- 構造が標準化された
- PEAP/TTLS がベンダー実装差で不安定だった問題を解消。
デメリットと注意点
- 対応クライアントがまだ限定的
- Windows 10 以降: 対応（ネイティブ）
- macOS/iOS: 非対応（2025 年時点）
- Android/Linux: 一部サポート（wpa_supplicant 3.x 系）
- 設定が複雑
- 二段階構造のため、RADIUS 側の設定も EAP チェーンを意識する必要がある。
- PAC 管理
- PAC の発行・破棄・更新が管理対象になる（証明書ほどではないが運用要）
他方式との比較表
| 項目 | EAP-TLS | EAP-TTLS | PEAP | EAP-TEAP |
|---|---|---|---|---|
| クライアント証明書 | 必須 | 不要 | 不要 | 任意 |
| 内部認証方式 | なし | 任意 | 固定（MSCHAPv2） | 任意（複数可） |
| PAC 再認証 | なし | 一部実装 | あり | 標準対応 |
| 二重認証（マシン＋ユーザー） | 不可 | 不可 | 一部可 | 標準サポート |
| 実装互換性 | 高 | 中 | 高 | 中（発展途上） |
| セキュリティ | ◎◎ | ◎ | ○ | ◎◎（TLS1.3 対応） |
まとめ
EAP-TEAP は、802.1X 認証における「理想と現実の折衷点」といえます。
EAP-TLS の堅牢性と、EAP-TTLS / PEAP の柔軟性を併せ持ち、デバイス認証とユーザー認証を統合できる初の標準方式です。条件を満たす環境では有力な選択肢となりますが、すべてのクライアント OS が対応しているわけではないため、導入には慎重な検証が必要です。また、EAP-TEAP の目的は認証の柔軟性であり、セキュリティ強度は EAP-TLS と同等と考えて良いです。
一方で、すでにクライアント証明書認証（EAP-TLS）を導入している環境において、EAP-TEAP を追加してユーザー認証を重ねる必要性は限定的です。理論的には「ネットワークごとに認証方式を分ける（証明書ベース／ID ベース）」といった柔軟な構成も可能ですが、運用コストと可用性を考慮すると、一般的な設計では採用されにくい構成です。
一般的な運用指針としては、一定規模以上の企業ネットワークで 802.1X 認証を使用する場合、クライアント証明書を必須とする構成（EAP-TLS） が最も安定的で、堅牢性・管理性ともに優れています。その上で、特定の運用要件（ユーザーとデバイスの二重認証など）を満たす必要がある場合に限り、EAP-TEAP を補完的に採用するのが望ましいでしょう。
また、ID ベース認証を採用する場合には、認証サーバーとのネットワーク的距離にも注意が必要です。認証サーバーがインターネット上に存在する構成では、通信障害によりクライアントがネットワーク接続できなくなるリスクがあります。
特に大規模環境では、認証基盤を内部ネットワーク側に配置する設計が推奨されます。
