EAP-TLS と EAP-TTLS 何が違う？

はじめに

「EAP-TLS と EAP-TTLS の違いを知りたい」と思って調べてみると、どの記事も 証明書が必要かどうか”という表面的な説明で終わっていませんか？

実は、この 2 つの違いを正しく理解するためには、その外側にある IEEE802.1X と EAP の構造 を理解する必要があります。

EAP-TLS や EAP-TTLS は、802.1X の中で使われる「認証方式（EAP メソッド）」の一種 に過ぎません。
つまり、TLS と TTLS の違いを語る前に、「そもそも 802.1X とは何か」「EAP とは何か」を押さえることが先決なのです。

この記事はは、「自分の環境ではどの EAP 方式を選ぶべきか」が構造的に理解できる 状態を目指します。

認証と暗号の関係

多くの人が「セキュリティ＝暗号化」と考えがちですが、実際には順序が逆です。

セキュリティは、まず、誰と通信しているのかを確認し、その後に通信を暗号化することで成立します。

すなわち、「認証 → 暗号化」 の流れがセキュリティの基本構造です。

認証（Authentication）とは

「この通信相手が正しいか」を確かめる工程です。ネットワークでいえば、「この端末／ユーザーが本当に許可された存在か」を確認すること。

この段階では、まだデータは暗号化されていません。認証が成功したあとで、初めて暗号化に使う鍵が安全に交換されます。

暗号化（Encryption）とは

認証によって確立された信頼済みの通信相手との間で、データを秘匿する仕組みです。

暗号化だけでは、通信相手が正しいとは保証されません。つまり、「暗号化だけでは安全ではない」のです。

例えば、HTTPS（TLS）も証明書によるサーバー認証を伴わなければ、偽サイトに暗号化通信をしてしまう危険があります。

IEEE802.1X と EAP の関係

ここで登場するのが IEEE802.1X（dot1x）。これは、有線 LAN・無線 LANで「認証プロセスを制御するためのフレームワーク」です。

役割を分けると次のようになります。

つまり、以下の三層構造でセキュリティが成り立っています。

• 802.1X がゲートの仕組みを提供し、
• EAP が認証方法を実行し、
• TLS がその後の通信を暗号化する。
  

IEEE802.1X とは

IEEE802.1X は、有線 LAN・無線 LANにおけるユーザー認証の標準規格です。現時点では、これを置き換える標準的なフレームワークは存在せず、「端末認証」の分野においては、これ以外の選択肢は存在しません（ベンダー固有の仕組みを除く）。

ネットワークに接続しようとする端末（クライアント）を、アクセス制御装置が認証サーバーに中継し、
「この端末をネットワークに入れて良いか」を判断します。

802.1X の構成要素

802.1X 認証は、以下の構成要素のやり取りで成立します。

これらが連携することで、「認証前は通信できないが、認証後にポートが開く」という動的制御が可能になります。

認証メッセージの流れ

802.1X での通信は、以下のように進行します:

[Supplicant] <-> [Authenticator] <-> [Authentication Server]

1. サプリカントが「接続したい」と要求を送信
2. オーセンティケーターがそれを EAP（Extensible Authentication Protocol）メッセージとして中継
3. 認証サーバーが EAP 方式（EAP-TLS など）を使ってクライアントを認証
4. 認証が成功すると、オーセンティケーターのポートが開放され、通信が可能になる

このとき、LAN 上では EAPOL（EAP over LAN） という形式で EAP メッセージが運ばれます。

dot1x は器であり、判断者ではない

ここで重要なのは、802.1X 自体は認証ロジックを持たないという点です。

dot1x は、EAP メッセージをサプリカントと認証サーバーの間でやり取りするための「器」であり、
「認証の中身（TLS・TTLS・PEAP など）」は EAP 側が定義します。

したがって、以下のような明確な分業構造になっています。

• 802.1X は「どのように認証を運ぶか」を決める仕組み
• EAP は「どのように認証を行うか」を決める仕組み

EAP とは

EAP（Extensible Authentication Protocol）は、さまざまな認証方式を柔軟に入れ替えられる拡張認証プロトコルです。

もともとは PPP（Point-to-Point Protocol）を拡張する形で誕生し、LAN 環境では EAPOL（EAP over LAN） として動作します。

EAP は認証方式そのものではない

EAP 自体は「どんな認証を行うか」を決めるものではなく、TLS、TTLS、PEAP などの認証方式（EAP メソッド）を包み込むためのフレームワークです。

EAP の役割は、ユーザー（サプリカント）とオーセンティケーター（ネットワーク機器）、そして認証サーバーの間で認証メッセージを安全にやり取りすること。

実際に「誰か」を確認するロジックは、それぞれの EAP 方式の内部で実行されます。

EAP が動作する構造

EAP は、802.1X ネットワークの中で次のように位置づけられます:

[Ethernet/Wi-Fi] -> [EAPOL] -> [EAP メソッド] -> [RADIUS]

各層の役割

• Ethernet/Wi-Fi: データリンク層。ユーザー端末とネットワーク機器（オーセンティケーター）が通信する物理的経路。まだ IP が確立していない段階でも通信可能。
• EAPOL（EAP over LAN）: 802.1X の内部で EAP メッセージを転送する仕組み。ユーザー端末（サプリカント）とオーセンティケーターの間で認証情報をやり取りする。
• EAP メソッド: EAP の内部で実際の認証ロジックを担当する部分。TLS、TTLS、PEAP など、方式によって「証明書認証」「パスワード認証」などの手段が異なる。
• RADIUS: オーセンティケーターが EAP メッセージをカプセル化して認証サーバーに転送するプロトコル。サーバー側でユーザー認証・許可を行い、結果をネットワーク機器に返す。

これらがが EAP メッセージを介してやり取りすることで、ユーザーの認証が成立します。

主な EAP 方式の種類と特徴

IEEE802.1X 認証の流れ

802.1X 認証は、大きく分けて 「接続前の認証フェーズ」 と 「認証後の暗号化フェーズ」 に分かれます。

この 2 つを混同しないことが、仕組みを正しく理解する鍵になります。

フェーズ 1: 認証フェーズ

1. Supplicant（ユーザー端末）が接続要求を送信
   • スイッチやアクセスポイント（Authenticator）に対して「ネットワークに参加したい」と通知。
   • この時点ではまだ通信ポートは閉じたまま。
2. Authenticator が EAP 認証を開始
   • Supplicant に「どの認証方式を使うか（EAP-TLS、PEAP など）」を通知。
   • 認証サーバー（RADIUS）との中継役として動作を始める。
3. Supplicant ↔ Auth Server 間で EAP メッセージ交換
   • Authenticator を経由して、EAP メッセージが往復。
   • EAP メソッド（TLS / TTLS / PEAP など）によって、証明書検証や ID・パスワード照合を行う。
   • ここまでが「認証」プロセス。
4. 認証成功でポート開放
   • 認証サーバーが「アクセス許可」の結果を Authenticator へ通知。
   • Authenticator はポートを開放し、Supplicant に通信権限を付与。

フェーズ 2: 暗号化フェーズ

5. セッション鍵交換
   • 認証サーバーと Supplicant が暗号鍵の元情報（セッションキー素材）を生成・共有。
   • Authenticator はサーバーから鍵情報を受け取り、通信の暗号化準備を行う。
6. データ通信開始（暗号化）
   • セッション鍵を用いてデータ通信を暗号化。
   • この時点で、認証済みユーザーのみが暗号化通信を行える。

補足：認証と暗号化の関係

両者は目的もタイミングも異なります。

802.1X は、まず EAP で認証を確立し、その後に暗号化通信（セッション確立）を開始する構造になっています。

各方式の詳細と比較

EAP は「認証メソッド」を入れ替えられる仕組みですが、実際の選択肢として主流なのが EAP-TLS / EAP-TTLS / PEAP（EAP-PEAP） の 3 方式です。

いずれも TLS を利用して通信を保護しますが、「クライアントをどう認証するか」 が異なります。

EAP-TLS: 証明書ベースの相互認証

• 概要:
  クライアント（ユーザー端末）とサーバーの双方が証明書を用いて認証する方式。認証フェーズの時点で、通信経路が TLS により完全に暗号化される。
• 特徴:
  • セキュリティレベル: 最高
  • クライアント証明書が必須
  • 証明書の発行・管理コストが高い（PKI 運用が前提）
• メリット:
  • 中間者攻撃・なりすましに極めて強い
  • 証明書の有効期限・失効リストでアクセス制御が可能
• デメリット：
  • クライアントごとの証明書配布・更新が運用負担
  • BYOD や不特定端末環境では非現実的
• 主な用途：
  企業 LAN、VPN、ゼロトラスト環境、政府・金融系ネットワーク

EAP-TTLS: TLS トンネル＋内部認証

• 概要:
  サーバー証明書で TLS トンネルを確立し、その内部でユーザー名＋パスワード認証（または別 EAP 方式）を行う構造。クライアント証明書は不要。
• 特徴:
  • クライアント: ユーザー名/パスワード
  • サーバー: 証明書
  • 内部認証: PAP、CHAP、MSCHAPv2、または EAP など柔軟に選択可能
• メリット:
  • クライアント証明書の運用負担がない
  • トンネル内部で任意の認証方式を選べる柔軟性
  • Linux や FreeRADIUS など OSS 環境と親和性が高い
• デメリット:
  • 実装間の互換性検証が必要
• 主な用途:
  大学ネットワーク、研究機関、Linux/Android ベースの環境

PEAP（EAP-PEAP）: Microsoft 標準の実装

• 概要：
  Microsoft と Cisco が共同策定。TLS トンネルを確立してから内部で EAP-MSCHAPv2 認証を行う。基本構造は EAP-TTLS と同じだが、内部認証方式が固定化されている。
• 特徴：
  • クライアント: ユーザー名/パスワード
  • サーバー: 証明書
  • 内部認証: EAP-MSCHAPv2（固定）
• メリット:
  • Windows / macOS / iOS に標準実装
  • 導入・設定が容易（クライアント証明書不要）
  • Active Directory との統合が容易
• デメリット：
  • 内部認証方式が限定的（MSCHAPv2 のみ）
  • パスワード認証依存でセキュリティ強度は中程度
• 主な用途：
  企業 Wi-Fi、教育機関、Windows ドメイン環境

比較まとめ

まとめ

一定の管理下にあるネットワーク環境（企業 LAN、ゼロトラスト構成、VPN など）であれば、EAP-TLS 一択で良いと思います。

証明書の発行・失効管理を自動化できる仕組みが整っているなら、セキュリティと運用の両立が可能です。

EAP-TTLS は、クライアント証明書の管理が難しい環境で現実的な選択肢となります。内部に柔軟な認証方式を取り込めるため、大学ネットワークや OSS 系インフラでは依然として実用的です。

ただし、本質的には EAP-TLS の妥協策であり、おそらく、それぞれの環境での利用シーンを考えると、EAP-TLS が理想的だと思うのではないでしょうか。運用方式やセキュリティ思想によって異なるので、よく検討してみると良いでしょう。

PEAP（EAP-PEAP） は、Windows ドメイン環境など「内部認証方式を変えられない場合の暫定策」です。セキュリティ面では MSCHAPv2 の脆弱性が指摘されており、新規構築では非推奨です。

Related posts:

公開鍵アルゴリズム RSA から Ed25519 へ CentOS7 Apache Web サーバー構築 TLS 対応 自己署名証明書 CentOS 7 Apache Web サーバー構築 TLS 対応 Let’s Encrypt VyOS OpenVPN Site-to-Site TLS Ubuntu 22.04 Apache Web サーバー構築 TLS 有効化 Ubuntu 22.04 389 Directory Server LDAP サーバー構築 #2 TLS 有効化 OpenVPN tls-auth を活用したセキュリティ強化