EAP-TEAP とは何か – 端末認証とユーザー認証を組み合わせる設計

EAP-TEAP は、802.1X 認証で使われる EAP メソッドの一つです。TEAP は Tunneled EAP の略で、RFC 7170 で定義されています。

名前だけを見ると、EAP-TTLS や PEAP の別名、あるいは EAP-TLS の後継のように見えるかもしれません。しかし、TEAP の本質はそこではありません。TEAP は、TLS トンネルの内側で複数の認証を組み合わせ、端末認証とユーザー認証を同じ認証設計の中で扱いやすくする方式です。

そのため、TEAP を理解するときは「どの方式が新しいか」ではなく、「端末を確認する認証」と「ユーザーを確認する認証」を、どの順序で、どの境界の中で、どの認可判断につなげるのかを見る必要があります。

• EAP-TLS は、クライアント証明書を使った相互認証が中心になる
• EAP-TTLS や PEAP は、TLS トンネル内で ID / パスワード認証を扱いやすい
• EAP-TEAP は、TLS トンネル内で複数の認証を組み合わせる設計に向いている
• 採用可否は、RADIUS サーバー、supplicant、OS、証明書運用、認可設計に依存する

EAP-TEAP の位置づけ

TEAP は、外側で TLS トンネルを確立し、その内側で one or more の EAP method や認証情報を扱うための方式です。大きく見れば、EAP-TTLS や PEAP と同じく「トンネル型 EAP」に分類できます。

ただし、TEAP は単にトンネルを作ってユーザー名とパスワードを流すだけの方式ではありません。端末証明書を使った machine authentication、ユーザー ID を使った user authentication、再認証、認可情報の扱いを、より明示的に組み合わせやすい構造を持っています。

ここで重要なのは、TEAP が「EAP-TLS より強い」「EAP-TTLS より新しい」といった単純な比較で決まるものではないことです。EAP-TLS、EAP-TTLS、PEAP、TEAP は、どれも認証設計の部品です。どれを使うべきかは、守りたい対象、管理できる証明書、利用する端末、既存の ID 基盤、ネットワーク接続後の認可設計によって変わります。

方式	中心になる考え方	向いている場面	注意点
EAP-TLS	クライアント証明書を含む相互認証	管理端末を証明書で強く識別したい	証明書配布、更新、失効管理が必要
EAP-TTLS	TLS トンネル内で ID / パスワードなどを認証	既存の ID 基盤を活かしたい	サーバー証明書検証と inner method の設計が重要
PEAP	TLS トンネル内で主にユーザー認証を行う	Windows 系環境で扱いやすい構成を取りたい	内側の認証方式の制約を受けやすい
EAP-TEAP	TLS トンネル内で複数の認証を組み合わせる	端末認証とユーザー認証を同じ設計で扱いたい	対応状況と運用設計が複雑になりやすい

TEAP の基本構造

TEAP の基本構造は、外側の TLS トンネルと、その内側で実行される認証処理に分けて見ると分かりやすくなります。

• まず RADIUS サーバー側の証明書を検証し、TLS トンネルを確立する
• TLS トンネルの内側で、端末認証やユーザー認証などの inner method を実行する
• 必要に応じて、複数の認証結果を組み合わせて接続可否や認可を決める
• 認証結果に応じて、VLAN、ACL、ロール、セッション属性などを返す

この構造により、TEAP では「この端末は管理された端末か」と「この端末を使っているユーザーは誰か」を同じ認証の流れの中で扱いやすくなります。これは、端末証明書だけを見る設計とも、ユーザー名とパスワードだけを見る設計とも異なります。

端末認証とユーザー認証を分ける理由

802.1X の設計でよく混乱するのは、「ネットワークへ接続してよい対象」を何で判断するのかです。端末を信用したいのか、ユーザーを信用したいのか、それとも端末とユーザーの組み合わせを信用したいのかで、選ぶ方式は変わります。

端末認証は、管理された端末かどうかを見るためのものです。社給 PC、管理対象のスマートフォン、MDM 配下の端末、証明書が配布された端末などを識別する場合に意味があります。一方で、端末認証だけでは、その端末を今使っているユーザーまでは直接表現できません。

ユーザー認証は、誰が接続しているかを見るためのものです。LDAP、Active Directory、ID / パスワード、MFA などの ID 基盤と接続しやすい一方で、ユーザーが正しくても、接続元の端末が管理対象かどうかは別の問題として残ります。

TEAP は、この二つを同じ認証設計の中で扱いたい場合に意味を持ちます。つまり、TEAP の価値は「認証方式が増えたこと」ではなく、端末とユーザーという異なる信頼対象を、同じ接続判断の中で組み合わせやすくする点にあります。

TEAP が有効になりやすい場面

TEAP は、単に新しいから採用するものではありません。端末認証とユーザー認証を分けて評価し、その結果をネットワークの認可に反映したい場合に向いています。

• 社給端末かどうかを確認したうえで、利用ユーザーも確認したい
• 端末証明書とユーザー ID を組み合わせて、接続先 VLAN やロールを変えたい
• machine authentication と user authentication の両方を扱いたい
• 端末だけ、ユーザーだけ、端末 + ユーザーで認可を分けたい
• EAP-TLS 中心の設計から、ユーザー単位の認可へ段階的に広げたい

たとえば、管理端末であれば社内ネットワークへ接続できるが、ユーザー属性によって利用できるセグメントや ACL を変えたい場合があります。このとき、端末証明書だけではユーザー属性を反映しにくく、ID / パスワードだけでは端末の管理状態を確認しにくくなります。TEAP は、その両方を一つの認証フローとして扱うための選択肢になります。

TEAP を無理に使わなくてよい場面

一方で、TEAP は万能ではありません。すでに EAP-TLS で端末証明書認証が安定しており、端末単位の制御で要件を満たせているなら、TEAP を追加する必要は限定的です。認証方式を増やせば、RADIUS 設定、端末設定、証明書運用、障害時の切り分けも増えます。

• 端末証明書だけで十分に接続制御できている
• BYOD や未管理端末を扱わない
• ユーザーごとの動的な認可を必要としていない
• クライアント OS や supplicant の TEAP 対応がそろっていない
• RADIUS 側の運用をこれ以上複雑にしたくない

TEAP は設計自由度を上げます。しかし、自由度が上がるということは、設計すべき境界も増えるということです。端末認証とユーザー認証を組み合わせる理由が明確でなければ、単にトラブルシュートしにくい認証基盤になる可能性があります。

設計時に確認すること

TEAP を検討する場合、最初に見るべきなのは規格名ではなく、実際に運用できるかどうかです。RADIUS サーバーが対応していても、クライアント側の supplicant が対応していなければ使えません。逆に、端末が対応していても、証明書運用や ID 基盤との接続が確認されていなければ安定しません。

検討項目	確認すること
supplicant 対応	Windows、macOS、Linux、スマートフォン、無線 LAN クライアント、有線 802.1X クライアントが TEAP に対応しているか
RADIUS 対応	FreeRADIUS、Windows NPS、Cisco ISE などで TEAP と inner method を扱えるか
端末証明書	証明書の発行、配布、更新、失効、端末廃棄時の処理をどう設計するか
ユーザー認証	LDAP、Active Directory、MFA、パスワード認証、ユーザー属性をどう接続するか
認可設計	認証結果を VLAN、ACL、ロール、セグメント、ポリシーへどう反映するか
障害時	RADIUS サーバー、CA、ディレクトリ、ネットワーク機器の障害時にどこまで接続を許可するか

特に重要なのは、認証と認可を混同しないことです。TEAP で端末とユーザーを確認できたとしても、その結果をどうネットワーク制御へ反映するかは別の設計です。RADIUS の属性、スイッチや無線 LAN コントローラーのポリシー、VLAN 設計、ACL 設計まで含めて考える必要があります。

EAP-TLS / EAP-TTLS との関係

EAP-TLS と EAP-TTLS の違いは、証明書による相互認証を中心にするのか、TLS トンネル内で ID / パスワード認証などを扱うのか、という点にあります。TEAP は、その比較の先にある方式です。

つまり、EAP-TLS は「端末やユーザーに証明書を持たせて強く認証する」設計に向きます。EAP-TTLS や PEAP は「サーバー証明書でトンネルを作り、その内側で既存の ID 認証を使う」設計に向きます。TEAP は「端末認証とユーザー認証を、同じトンネル型 EAP の中で組み合わせる」設計に向きます。

前提となる比較は、EAP-TLS と EAP-TTLS の違い で確認しています。TEAP は、その記事で扱った証明書認証とトンネル型認証を、さらに組み合わせて考えるための論点です。

まとめ

EAP-TEAP は、EAP-TTLS や PEAP を単純に置き換える方式ではありません。TLS トンネルの内側で複数の認証を組み合わせ、端末認証とユーザー認証を同じ認証設計の中で扱いやすくする方式です。

端末証明書だけで十分なら EAP-TLS、既存の ID / パスワード認証を活かしたいなら EAP-TTLS や PEAP、端末とユーザーを組み合わせて認可まで設計したいなら TEAP、という位置づけで考えると分かりやすくなります。

ただし、TEAP は採用すれば自動的に高度な認証基盤になるものではありません。supplicant、RADIUS、証明書、ID 基盤、認可ポリシー、障害時の扱いまで含めて設計できる場合に、はじめて意味のある選択肢になります。

参考情報

関連する記事