EAP-TLS と EAP-TTLS は、どちらも IEEE 802.1X などで使われる EAP メソッドです。名前は似ていますが、認証の考え方はかなり違います。
よくある説明では「EAP-TLS は証明書、EAP-TTLS は ID / パスワード」とまとめられます。しかし、それだけだと本質を外します。重要なのは、EAP-TLS はクライアント証明書まで含めた相互認証であり、EAP-TTLS は TLS トンネルの内側で別の認証方式を使う、という構造の違いです。
EAP-TLS と EAP-TTLS の違いは、単に「証明書が必要かどうか」ではありません。EAP-TLS はクライアント証明書を使った相互認証、EAP-TTLS はサーバー証明書で TLS トンネルを作り、その内側でユーザー認証を行う方式です。
- EAP-TLS は端末・ユーザーに証明書を配布できる管理環境に向く
- EAP-TTLS は既存の ID / パスワード認証基盤を使いやすい
- どちらもサーバー証明書の検証を軽視すると危険になる
- 選定では PKI、端末管理、認証基盤、運用負荷を合わせて見る
書籍
マスタリング TCP/IP 入門編 第6版
Ethernet、IP、TCP/IP、ネットワークの基礎を体系的に確認したい場合の参考書籍です。802.1X や EAP を理解する前提として、ネットワークの土台を押さえる助けになります。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
結論
管理された端末だけを確実に通したいなら、基本的には EAP-TLS が強いです。一方で、既存のユーザー名とパスワード、LDAP、Active Directory、RADIUS の認証基盤を活かしたいなら、EAP-TTLS は現実的な選択肢になります。
ただし EAP-TTLS でも、サーバー証明書の検証を正しく行わなければ安全性は大きく落ちます。逆に EAP-TLS でも、証明書の配布や失効管理が破綻していると運用としては危険です。
| 観点 | EAP-TLS | EAP-TTLS |
|---|---|---|
| 基本構造 | 証明書による相互認証 | サーバー証明書で TLS トンネルを作り、内側で認証 |
| クライアント証明書 | 必要 | 通常は不要 |
| サーバー証明書 | 必要 | 必要 |
| 利用しやすい認証基盤 | PKI、MDM、証明書配布基盤 | LDAP、Active Directory、RADIUS、既存 ID / パスワード |
| 強み | 秘密鍵を持つ端末だけを通しやすい | 既存のユーザー認証を活かしやすい |
| 弱点 | 証明書の発行、配布、失効管理が重い | 内側の認証方式とサーバー証明書検証に依存する |
| 向く環境 | 管理端末、社給端末、高い保証が必要な環境 | BYOD、既存 ID 基盤を使う環境、段階移行 |
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 の流れ
- Supplicant がネットワークへ接続を要求する
- Authenticator が EAPOL を使って EAP メッセージを中継する
- Authenticator は RADIUS などを使って Authentication Server へ中継する
- Authentication Server が EAP メソッドに従って認証する
- 認証成功後、Authenticator が通信を許可する
つまり、802.1X は認証方式そのものではありません。EAP メッセージをサプリカントと認証サーバーの間で運び、認証結果に応じてネットワークの入口を開閉する仕組みです。
EAP-TLS の仕組み
EAP-TLS は、TLS の仕組みを使ってサーバーとクライアントの両方を証明書で認証します。サーバーはサーバー証明書を提示し、クライアントもクライアント証明書を提示します。
- サーバー証明書で認証サーバーの正当性を確認する
- クライアント証明書で端末またはユーザーの正当性を確認する
- 秘密鍵を持たない端末は認証を通しにくい
- パスワード認証に比べてフィッシングや辞書攻撃に強い
EAP-TLS の強さは、認証情報が単なるパスワードではなく、証明書と秘密鍵に結びついている点にあります。特に社給端末や管理端末のように、証明書配布と端末管理を統制できる環境では有力です。
EAP-TLS の難しさ
一方で、EAP-TLS は PKI の運用が必要です。証明書を発行し、端末に配布し、更新し、紛失や退職、端末廃棄時に失効させる必要があります。技術的には強くても、証明書ライフサイクルを管理できなければ運用が重くなります。
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 など既存の認証基盤へつなぎやすい場面があります。
どちらを選ぶべきか
選定では、暗号方式の強さだけでなく、端末管理と認証基盤を見ます。EAP-TLS は理想的に見えますが、証明書の配布・更新・失効を運用できることが前提です。EAP-TTLS は導入しやすい一方で、サーバー証明書検証とパスワード管理が弱いと危険です。
- 社給端末、MDM、証明書配布基盤があるなら
EAP-TLS - 既存の ID / パスワード認証を使いたいなら
EAP-TTLSまたは PEAP - 端末証明書とユーザー認証を組み合わせたいなら TEAP も候補
- 証明書警告を利用者判断に任せる運用は避ける
- RADIUS、LDAP、AD、端末管理、証明書失効まで含めて設計する
TEAP との関係
EAP-TEAP は、EAP-TLS と EAP-TTLS / PEAP の間にある課題を整理するための方式として見ると理解しやすいです。端末認証とユーザー認証を組み合わせる設計や、段階的な認証を扱いやすくする目的があります。
TEAP については、別記事の EAP-TEAP の仕組みと設計指針 で整理しています。
まとめ
EAP-TLS と EAP-TTLS の違いは、証明書の有無だけではありません。EAP-TLS はクライアント証明書を使った相互認証であり、端末管理と PKI を前提に強い認証を行います。EAP-TTLS はサーバー証明書で TLS トンネルを作り、その内側で既存のユーザー認証を使う方式です。
高い保証が必要で端末を管理できるなら EAP-TLS、既存の ID 基盤を活かして導入したいなら EAP-TTLS、端末認証とユーザー認証を組み合わせたいなら TEAP まで含めて検討する、という整理が現実的です。



