EAP-TLS と EAP-TTLS の違い – 証明書認証、ID / パスワード認証、TEAP との使い分け

EAP-TLS と EAP-TTLS は、どちらも IEEE 802.1X や WPA-Enterprise などで使われる EAP メソッドです。名前は似ていますが、認証の考え方はかなり違います。

最初に結論を言うと、EAP-TLS はクライアント証明書まで使う相互認証です。一方、EAP-TTLS はサーバー証明書で TLS トンネルを作り、その内側で ID / パスワード認証などを行う方式です。

そのため、違いは単に「証明書を使うかどうか」ではありません。EAP-TLS は端末やユーザーに証明書を配布し、秘密鍵を持つ主体だけを通す設計です。EAP-TTLS は TLS で保護された内側に、既存の LDAP、Active Directory、RADIUS、ID / パスワード認証を収める設計です。

どちらが絶対に正しいという話ではありません。見るべきなのは、PKI、端末管理、証明書配布、既存 ID 基盤、利用者端末、運用負荷のどこに責任を置けるかです。

まず違いを表で確認する

観点	EAP-TLS	EAP-TTLS
基本構造	サーバー証明書とクライアント証明書による相互認証	サーバー証明書で TLS トンネルを作り、内側で別の認証を行う
クライアント証明書	基本的に必要	通常は不要
サーバー証明書	必要	必要
主な認証情報	証明書と秘密鍵	ID / パスワード、PAP、CHAP、MSCHAPv2 など
使いやすい基盤	PKI、MDM、証明書配布基盤	LDAP、Active Directory、RADIUS、既存 ID 基盤
強み	管理された端末や証明書を持つ主体だけを通しやすい	既存のユーザー認証基盤を活かしやすい
弱点	証明書の発行、配布、更新、失効管理が重い	内側の認証方式とサーバー証明書検証に依存する
向く環境	社給端末、管理端末、高い保証が必要な環境	BYOD、既存 ID 基盤を使う環境、段階移行

検索で「EAP-TLS EAP-TTLS 違い」と調べる人が最初に知りたいのは、おそらくこの表の部分です。EAP-TLS は証明書を端末側にも配る方式、EAP-TTLS は TLS トンネルの中に既存の認証を入れる方式、と押さえると見通しがよくなります。

802.1X と EAP の位置づけ

EAP-TLS や EAP-TTLS を理解するには、まず 802.1X と EAP の役割を分けて考える必要があります。802.1X はネットワークの入口を制御する枠組みであり、EAP はその中で認証メッセージを運ぶための拡張認証プロトコルです。

• Supplicant: 認証を受ける端末やクライアント
• Authenticator: スイッチや無線 LAN アクセスポイントなど、ネットワークの入口を制御する機器
• Authentication Server: RADIUS サーバーなど、実際に認証判断を行うサーバー
• EAP メソッド: EAP-TLS、EAP-TTLS、PEAP、TEAP など、認証の中身を決める方式

つまり、802.1X は認証方式そのものではありません。EAP メッセージをサプリカントと認証サーバーの間で運び、認証結果に応じてネットワークの入口を開閉する仕組みです。

この中で、EAP-TLS や EAP-TTLS は「どう本人性を確認するか」を決める EAP メソッドです。

EAP-TLS の仕組み

EAP-TLS は、TLS の仕組みを使ってサーバーとクライアントの両方を証明書で認証します。サーバーはサーバー証明書を提示し、クライアントもクライアント証明書を提示します。

• サーバー証明書で認証サーバーの正当性を確認する
• クライアント証明書で端末またはユーザーの正当性を確認する
• 秘密鍵を持たない端末は認証を通しにくい
• パスワード認証に比べてフィッシングや辞書攻撃に強い

EAP-TLS の強さは、認証情報が単なるパスワードではなく、証明書と秘密鍵に結びついている点にあります。特に社給端末や管理端末のように、証明書配布と端末管理を統制できる環境では有力です。

EAP-TLS の難しさ

一方で、EAP-TLS は PKI の運用が必要です。証明書を発行し、端末に配布し、更新し、紛失や退職、端末廃棄時に失効させる必要があります。

技術的には強くても、証明書ライフサイクルを管理できなければ運用が重くなります。EAP-TLS は「安全だから採用する」だけでは足りません。証明書を誰に、どの端末へ、どの期間、どう配り、どう失効させるのかまで決めて初めて成立します。

EAP-TTLS の仕組み

EAP-TTLS は、まずサーバー証明書を使って TLS トンネルを作り、その内側でユーザー名とパスワードなどの認証を行う方式です。クライアント証明書を必須にしない構成が一般的です。

• サーバー証明書で認証サーバーを確認する
• TLS トンネルを作る
• トンネルの内側で PAP、CHAP、MSCHAPv2 などの認証を行う
• LDAP や Active Directory など既存の ID 基盤と組み合わせやすい

EAP-TTLS の利点は、クライアント証明書を全端末へ配布しなくても、TLS による保護の内側で既存のユーザー認証を使えることです。証明書配布が難しい環境や、段階的に 802.1X を導入する環境では現実的です。

EAP-TTLS の注意点

EAP-TTLS は、サーバー証明書の検証を正しく行うことが前提です。利用者が証明書警告を無視したり、端末側でサーバー証明書検証を無効にしたりすると、偽の認証サーバーに接続して認証情報を渡す危険があります。

また、内側で使う認証方式によって安全性が変わります。単に TLS トンネルの中に入っているから安全、と考えるのではなく、サーバー証明書検証、内側の認証方式、パスワード管理をセットで見る必要があります。

EAP-TTLS と PEAP の違い

EAP-TTLS と PEAP はどちらも、サーバー証明書で TLS トンネルを作り、その内側でユーザー認証を行う方式です。そのため、EAP-TLS との対比では近い位置にあります。

大まかには、PEAP は Windows 環境でよく使われ、内側に MSCHAPv2 を使う構成が多いです。EAP-TTLS は内側に PAP なども使いやすく、RADIUS から LDAP など既存の認証基盤へつなぎやすい場面があります。

ただし、ここも「PEAP は Windows、EAP-TTLS は Linux」と単純に覚えるより、内側で何を認証するのか、クライアント OS が何を標準サポートするのか、利用者にどこまで設定を任せるのかで判断した方が安全です。

どちらを選ぶべきか

選定では、暗号方式の強さだけでなく、端末管理と認証基盤を見ます。EAP-TLS は理想的に見えますが、証明書の配布・更新・失効を運用できることが前提です。EAP-TTLS は導入しやすい一方で、サーバー証明書検証とパスワード管理が弱いと危険です。

状況	候補	理由
社給端末を管理できる	EAP-TLS	クライアント証明書と端末管理を結びつけやすい
MDM や証明書配布基盤がある	EAP-TLS	証明書の配布・更新・失効を運用しやすい
既存の ID / パスワード認証を使いたい	EAP-TTLS または PEAP	LDAP、Active Directory、RADIUS と接続しやすい
BYOD を含めたい	EAP-TTLS、PEAP、TEAP を検討	端末証明書の配布範囲と利用者認証を分けて考えやすい
端末認証とユーザー認証を組み合わせたい	TEAP	複数の認証要素を組み合わせる設計に向く
利用者が証明書警告を無視しがち	方式以前に端末設定を管理する	サーバー証明書検証が崩れると安全性が大きく落ちる

実務では、「EAP-TLS が一番安全だから採用する」という言い方だけでは不十分です。証明書配布が破綻している EAP-TLS より、サーバー証明書検証とパスワード管理がきちんと設計された EAP-TTLS の方が、運用として成立する場合もあります。

逆に、端末を厳密に管理したい環境で、EAP-TTLS による ID / パスワード認証だけに寄せると、端末の所有や管理状態を認証に反映しにくくなります。

TEAP との関係

EAP-TEAP は、EAP-TLS と EAP-TTLS / PEAP の間にある課題を確認するための方式として見ると理解しやすいです。端末認証とユーザー認証を組み合わせる設計や、段階的な認証を扱いやすくする目的があります。

EAP-TLS は証明書による相互認証に強く、EAP-TTLS は既存 ID 基盤を TLS トンネル内で使いやすい。TEAP は、端末とユーザー、証明書と内側の認証をどう組み合わせるかという設計問題に近い位置にあります。

TEAP については、別記事の EAP-TEAP の仕組みと設計指針 で確認しています。

参考書籍

まとめ

EAP-TLS と EAP-TTLS の違いは、証明書の有無だけではありません。EAP-TLS はクライアント証明書を使った相互認証であり、端末管理と PKI を前提に強い認証を行います。EAP-TTLS はサーバー証明書で TLS トンネルを作り、その内側で既存のユーザー認証を使う方式です。

高い保証が必要で端末を管理できるなら EAP-TLS、既存の ID 基盤を活かして導入したいなら EAP-TTLS、端末認証とユーザー認証を組み合わせたいなら TEAP まで含めて検討する、という確認が現実的です。

方式名だけで安全性を判断するのではなく、証明書をどう配るのか、サーバー証明書をどう検証するのか、内側の認証方式をどう選ぶのか、認証失敗時にどう切り分けるのかまで含めて設計する必要があります。