EAP-TEAP の仕組みと設計指針 – 端末認証とユーザー認証を組み合わせる

EAP-TEAP は、802.1X 認証で使われる EAP メソッドの一つです。名前だけを見ると EAP-TTLS や PEAP の後継のように見えますが、単純な置き換えではありません。

TEAP を理解するうえで重要なのは、TLS トンネルの内側で複数の認証を組み合わせ、端末認証とユーザー認証を一つの認証設計として扱える点です。

EAP-TEAP の位置づけ

EAP-TEAP は RFC 7170 で定義された Tunneled EAP です。外側では TLS トンネルを確立し、その内側で複数の inner method を扱えるようにします。

EAP-TLS が証明書による相互認証を中心にする方式だとすれば、EAP-TTLS や PEAP は TLS トンネル内でユーザー認証を行う方式です。TEAP は、そのトンネル型認証をより構造化し、端末とユーザーの両方を扱いやすくする方向の方式と見ると理解しやすいです。

TEAP の基本構造

TEAP では、まずサーバー証明書を検証して TLS トンネルを作ります。その後、トンネルの内側で端末認証、ユーザー認証、再認証などを組み合わせます。

• 外側で TLS トンネルを確立する
• トンネルの内側で one or more の inner method を実行する
• 端末認証とユーザー認証を同じ認証セッションで扱える
• 認証結果に応じて VLAN、ACL、ロールなどの認可情報を返せる

端末認証とユーザー認証を分けて考える

802.1X の設計では、端末を信用するのか、ユーザーを信用するのか、あるいは両方を見るのかを分けて考える必要があります。

• 端末認証: 管理された端末かどうかを確認する
• ユーザー認証: 誰がその端末を使っているかを確認する
• 端末 + ユーザー認証: 管理端末であり、かつ許可されたユーザーであることを確認する

EAP-TLS は端末証明書を使った端末認証に強く、EAP-TTLS / PEAP はユーザー認証を導入しやすい方式です。TEAP はこの二つを同じトンネル型認証の中で組み合わせやすくするための選択肢です。

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

TEAP は、単に新しいから選ぶものではありません。端末とユーザーを分けて評価したい要件がある場合に意味があります。

• 社給端末かどうかを確認したうえで、利用ユーザーも確認したい
• 端末証明書とユーザー ID を組み合わせて認可を決めたい
• machine authentication と user authentication の両方を扱いたい
• 接続後の VLAN、ACL、ロールを認証結果に応じて変えたい
• 証明書ベースの設計と ID ベースの設計を段階的に整理したい

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

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

• 端末証明書だけで十分に管理できている
• BYOD を扱わない
• ユーザーごとの動的な認可を必要としていない
• クライアント OS や supplicant の対応状況がそろっていない
• RADIUS 側の運用が複雑化することを避けたい

設計時に確認すること

TEAP は認証方式として魅力がありますが、実装対応と運用設計を確認しないまま採用すると、かえって認証基盤を複雑にします。

EAP-TLS / EAP-TTLS 記事との関係

EAP-TLS と EAP-TTLS の違いは、証明書による相互認証か、TLS トンネル内のユーザー認証か、という点にあります。TEAP はその先にある、端末認証とユーザー認証をどう組み合わせるかという設計の話です。

前提となる EAP-TLS / EAP-TTLS の比較は、EAP-TLS と EAP-TTLS の違い で整理しています。

まとめ

EAP-TEAP は、EAP-TTLS や PEAP を単に置き換える方式というより、端末認証とユーザー認証を同じトンネル型認証の中で整理するための方式です。

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

関連記事

• EAP-TLS と EAP-TTLS の違い
• Ubuntu 26.04 FreeRADIUS の基本設定