Web教材一覧ネットワークネットワークセキュリティ技術

ネットワーク認証

キーワード

LAN接続、IEEE 802.1X、EAP、RADUIS、PPP、PPPoE、サプリカント、認証装置、認証サーバ、EAPoL、EAP-MD5、EAP-TLS、PEAP、、MAC RADIUS認証、RADIUS認証、PAP、CHAP、Web認証、AND認証、AAA、送信ドメイン認証、メールサーバ、SPF、DKIN、DMARC、エンベロープアドレス、ヘッダアドレス、DNSSEC、DNSキャッシュポイズニング、共有サイト、クライアント、リソースオーナー、リソースサーバ、認可サーバ、認証、認可、OpenID、OpenID Connect、OAuth、アクセストークン、マッシュアップ、Webサービス、シングルサインイン


LAN接続の認証

利用者の端末機器をLAN(有線でも無線でも)に接続するとき、その接続を認めるかどうかを認証するための規格を対象にします。
 ここでの主要プロトコルは、LAN認証全般に関するIEEE 802.1X、その実装のうち、端末とスイッチハブやアクセスポイントとの間で認証を行うEAP、さらにネットワーク層で高度な認証を行うRADUISです。

予備知識として:PPP(Point-to-point protocol)

Point-to-point とは、2台の機器を回線接続することです。PPPは、その接続での代表的な認証方式です。初期の電話回線利用時代には相手を決定するのに電話をかけました。それをダイアルアップPPP、イーサーネットが主流になった頃はPPPoE(PPP over Ethernet)といわれました。
 PPPの通信は、データリンク層でのLCP(Link Control Protocol、リンク制御プロトコル)とネットワーク層でのNCP(Network Control Protocol、ネットワーク制御プロトコル)の2つの通信プロトコルを使用しています。
 LCPではPAP(Password Authentication Protocol、パスワード認証プロトコル)やパスワードをハッシュ化して送るCHAP(Challenge-Handshake Authentication Protocol)を使ってユーザ認証を行ってリンクを確立した後、NCPで多様な通信プロトコルに必要な設定や認証を行って接続を確立します。
 当時から、PPPを用いた認証方式にRADIUSがあり、認証サーバとして用いられていました。

EAPやRADIUSは、PPPの発展プロトコルだといえます。現在ではPPPをそのまま使うのは稀です。

IEEE 802.1X

IEEE 802.1xとは、有線LAN、無線LANで使用される認証プロトコルです。
 以下の3要素が連携して認証します。
  ・サプリカント:LANに接続する端末にインストールされた認証クライアント・ソフトウェア
  ・認証装置:IEEE 802.1x対応のスイッチングハブやアクセスポイント
  ・認証サーバ: 認証を判断するサーバ。RADIUSサーバなど。

端末と認証装置を接続したときに、サプリカントの情報(ユーザIDやパスワードなど)がEAPメッセージとして認証装置に送られます。そのプロトコルがEAPです。
 認証装置は、自ら認証するのではなく、EAPメッセージを暗号化してRADIUSパケットとして認証サーバに送ります。認証サーバは、端末のユーザIDやパスワードなどを調べて認証し、その結果を認証装置に戻します。
 その結果を認証装置が受けて、端末の接続許可・拒否を決定するのです。

LAN接続認証の構成図

IEEE 802.1X の重要なプロトコルであるEAPは、左図のような階層になっています。
 EAPは、多くのプロトコルの集合体です。EAPをLAN環境に合わせたものをEAPoL(EAP over Lan)といいます。LANでの通信プロトコルは、有線LAN(Ethernet)では IEEE 802.3、無線LANでは IEEE 802.11シリーズが一般的ですが、EAPoLはそれを仮想化して一つにまとめたものです。
 また、EAPにはEAP-MD5やEAP-TLSなど多様な認証方式があります(後述)。

IEEE 802.1X の3要素であるサプリカント-認証装置-認証サーバ の関係は右図のようになります。

LAN接続認証の手順

端末をLANに接続し、許可・拒否されるまでの手順は上図の右下のようになります。

  1. 接続
    接続信号が認証装置に送られます。
  2. EAP情報要求
    EAPoLを確立して、ユーザID、パスワードなどを要求します。
  3. EAP情報通知
    ユーザID、パスワードなど(EAPメッセージ)を通知します。
  4. 認証要求
    認証装置と認証サーバの間でUDP通信を確立。EAPメッセージをRADIUSパケットにして送信
  5. 認証シーケンス
    一時的に端末と認証サーバ間にLANが確立。それを通して認証合否が決定します。
    接続にどのような条件があるかは、認証サーバの設定により異なります。
  6. 認証通知
    認証の結果を認証装置に知らせます。
  7. キー通知
    認証結果が拒否のときは、端末にその旨表示して接続を遮断します。
    認証が許可ならば、有線の場合はVLANのID(注)、無線の場合はネットワークセキュリティキーを端末に通知します。
  8. 通信可能
    端末は、それらのキーを用いることにより、LANが利用可能になります。

(注)端末が有線LANに参加するとは、通常は、既に設定してある多数の端末を接続しているVLAN(Virtual Local Area Network)に新端末を追加することになります。キー通知でのキーとは、スイッチンハブでの該当するVLANの番号のことです。

EAP(Extensive Authentication Protocol、拡張認証プロトコル)の認証方式

データリンク層での認証プロトコルPPPを拡張した認証プロトコルの総称です。PPPは多様な環境で拡張機能をもつようになり、それらをEAPxxのような名称がつけられました。IEEE802.1Xに規定されるフレームワークにおいて、どの認証方式を用いるかを指定するプロトコルです。仕様は、RFC 2284で規定されています。

EAP自体はセキュリティ機能を持っていません。次に代表的な認証方式を掲げます。すべてクライアントとサーバ間を暗号化通信で行いますが、認証にユーザIDとパスワードを用いるか、SSL/TSLでの電子証明書を用いるかの違いです。

            端末           認証サーバ
   EAP-MD5  ユーザID、パスワード    -
   EAP-TLS  電子証明書        電子証明書
   PEAP     ユーザID、パスワード  電子証明書

EAP-MD5
ユーザIDとパスワードで認証します。パスワードはチャレンジ&レスポンス方式で暗号化されて送信されます。クライアントの認証はできるが、サーバの認識はできません。単純で基本的な方式ですが、セキュリティ面で劣ります。
EAP-TLS(Transport Layer Security)
TLSはSSLの後継規格。クライアントとサーバの両方が電子証明書を発行し、TLS方式で相互認証を行います。相互に電子証明書を発行・管理する必要があり、手間とコストはかかりますが、セキュリティ性の高い処理が行えます。無線LANでの主流になっています。
PEAP(Protected EAP)
サーバ側の電子証明書でサーバ認証をして、クライアントとサーバ間に、TLS暗号化通信とEAP通信を組み合わせてSSLの暗号トンネルを構築し、その暗号化通信路を通して、クライアントのユーザIDとパスワードを送り、クライアント認証を行ないます。
クライアントの電子証明書が不要になるので手間やコストが節約できます。

RADIUS(Remote Authentication Dial-In User Service)

RADIUSは、ダイアルアップ時代にインターネット接続において端末を認証するプロトコルでしたが、イーサーネットの時代になり端末と接続機器の間での認証に対応しました。そのような背景のため、RADIUSの基本仕様では非暗号化パスワードをそのまま流す PAP(Password Authentication Protocol)、チャレンジ型認証の CHAP は EAP-MD5 とは非互換などがありました。EAPはデータリンク層、RADIUSはネットワーク層のプロトコルでしたが、連携には問題があります。

RFC3579 で EAP over RADIUS の仕様が策定され、IEEE 802.1X はその仕様を採用しています。すなわち、IEEE 802.1X対応RADUISでは、EAPとRADIUSとの連携が円滑になり、端末と認証機器間の認証を EAPoL で行い、認証機器と認証サーバ間の認証を RADIUS で行うこと、EAPoLでのEAPメッセージをRADIUSパケットとして通信することが可能になったのです。現在のRADIUSはIEEE 802.1X対応が通常です。

IEEE 802.1X RADIUSでの認証方法

IEEE 802.1X での、全体の構造や認証の方法は前述しました。そのうち、認証装置と認証サーバ(RADIUSサーバ)との関係を簡単に復習します。

認証装置と認証サーバ間は Ethernat で接続され、認証装置がRADIUSクライアント、認証サーバがRADIUSサーバになります。
、  認証装置は端末から受け取ったEAPメッセージを暗号化したRADIUSパケットにして、認証サーバに端末の認証を依頼します。
 端末と認証装置は既にEAPoLでLAN接続されているので、認証装置と認証サーバ間の接続が確立すると、端末と認証サーバ間もLANで接続されたことになります。それに必要な情報交換を行います。
 認証サーバは、EAPメッセージの内容(ユーザIDやパスワード、電子証明書など)を認証データベースの情報と突合せ、必要があれば、端末から追加情報を得たりして、端末の認証を行い、その結果を認証装置に戻します。
 認証装置は、認証結果により接続の可否を端末に伝えます。接続許可のときはLAN通信に必要な情報を端末に伝えます。

IEEE 802.1X 以外のRADIUS認証

RADIUSは、IEEE 802.1X 以外の認証プロトコルがあります。代表的なものを掲げます。

RADIUSの機能:AAA

RADIUSの機能をAAAということがあります。

RADIUSには、ユーザIDとパスワードの組み合わせだけなく、多様な情報を暗号化したRADIUSデータベースをもっています。例えば、次のような項目もあります。

これらを1台のRADIUSサーバで管理するよりも、内容に応じて複数のサーバに分散したほうが運用が容易になるとか、セキュリティの観点から分散させることもあります。

RADIUSのメリット


送信ドメイン認証(Sender Domain Authentication)

送信ドメイン認証のイメージ

ここでは「なりすましメール」を防ぐことを対象にします。
 メールを受け取ると、メールソフト画面の差出人の欄に、差出人の氏名あるいはメールアドレスが表示されますが、それは送信者が送信に使った本当のメールアドレスではなく、メールソフトのfrom欄に送信者が任意に記述したものなのです。悪意のある送信者は、この機能を使って、あたかも信頼のあるところからのメールのように見せかけることができます。

メールは、送信者端末機器→送信側メールサーバ→受信側メールサーバで送られます。そのプロトコルはSMTPですが、なまのSMTPは送信時の本人認証機能をもっていません。多くのプロバイダは、契約者に限定するなど何らかの認証方法を講じていますが、なかには認証をしないことをウリにしている(アングラ)サーバもあります。悪意の送信者はこのようなサーバを使って勝手なメールアドレスで送信できるのです。

その対策の一つに、送信側メールサーバと受信側メールサーバ間での転送メールに関して、受信側メールサーバが認証することがあります。それを送信ドメイン認証といいます。

送信ドメイン認証の方式

代表的な送信ドメイン認証の方式に、SPF、DKIN、DMARCなどがあります。

SPF(Sender Policy Framework)
受信側メールサーバが受け取ったメールが、本当に送信側メールサーバから転送されたものであるかを認証します。すなわち、認証対象は送信側メールサーバであり送信者ではありません。
 送信側メールサーバのドメインにはDSNサーバがあり、そこには、送信側メールサーバのIPアドレスなど(SPFレコード)が登録されています。
 転送メールには送信側メールサーバのIPアドレスがあります。また、受信側メールサーバは転送メールから送信側のDSNサーバを知り、DSNサーバからSPFレコードを取得します。このIPアドレスとSPFレコードのIPアドレスが一致すれば、この転送メールが送信側メールサーバから送られてきたことが認証できます。
DKIN(DomainKeys Identified Mail)
SPFと同様に、送信側メールサーバから転送であることの認証ですが、認証にはデジタル証明書(サーバ証明書)を用います。送信側メールサーバから受信側メールサーバへ、転送メールを本文としたデジタル署名のメールを送信したようなイメージです。
 送信側メールサーバは、自身の秘密鍵によるデジタル署名を付けてメールを暗号化送信します。受信側メールサーバは、メールヘッダから特定したドメインのDNSサーバから公開鍵を取得し、そのデジタル署名を検証します。この検証によって、両メールサーバ間でのなりすましやメール本文の改ざんの有無(ヘッダアドレスの改ざんなど)を確認すること、送信側の信用度の評価などができます。
DMARC(Domain-based Message Authentication、Reporting and Conformance)
SFPやDKINでは、認証をしただけで、認証失敗メールの取扱いは、受信者の判断に任せられています。DMARCは、認証失敗メールの対応策を送信者が受信者に対してDMARCポリシーと呼ばれるレコードをDNS上で公開することで表明する仕組みです。 RFC 7489 で標準化されています。

SFPやDKINは、単純な機能は認証対象は送信側メールサーバであり送信者ではありません。しかし、下記のように、送信者が自分のメールアドレスを詐称することが大きな問題です。

エンベロープ(envelope)アドレスとヘッダ(header)アドレス

メールを送信するとき、郵便での封筒での住所に相当する受信者のメールアドレス(toアドレス)と送信者のメールアドレス(fromアドレス)を指定します。これをエンベロープto、エンベロープfromといいます。また、手紙に「~様」「~より」と書くことがあります。これらをヘッダto、ヘッダfromといいます。ヘッダアドレスは送信者が任意のアドレス(存在の有無不問)にすることができます。

メールの送受信は、エンベロープアドレスで行われます。不達メッセージエンベロープfromに通知されます。
 ところが、受信者のメールソフトの「差出人」や「宛先」で表示されるのはヘッダアドレスなのです。受信者は、ヘッダfromからのメールだと判断します。
 通常はエンベロープアドレスとヘッダアドレスは同じなのですが、例えば次のような理由により、異なるアドレスにしたいこともあります。

しかし、これを悪用すると、本当はエンベロープfromなのにヘッダfromだと思わせ、なりすますことができます。
 SFPやDKINを拡張して、メールの中身に入り、エンベロープアドレスとヘッダアドレスを比較して、一致しないときに警告を表示するようにしているものもあります。
 しかし、一致しないときはすべて遮断するというのでは困ります。通過・遮断させるヘッダアドレスをリストするとか、悪意のヘッダアドレスを収集するなどの工夫が必要ですが、それには通常のプロトコルの範囲ではなく、メールソフトのフィルタリングやアンチウイルスソフトなどの分野になります。

DNSSEC(Domain Name System Security Extensions)

DNS(Domain Name System)とは、メールアドレスやURLのドメイン名とIPアドレスとを対応付けるシステムです。DNSサーバには、これまでに解決したドメイン名とIPアドレスの対応の一覧表を持っています。その一覧表にないときは、上位のDNSサーバに聞きに行きます。このようにバケツリレー式に問い合わせることにより解決できるという仕組みです。

悪意を持つ者が、その一覧表を改ざんしてIPアドレスを悪意のあるメールサーバやWebサイトにすると、これまで信用してアクセスしていたメールアドレスやURLが、悪意を持つサーバに繋がれてします。この手口をDNSキャッシュポイズニング(DNS cache poisoning)といいます。

キャッシュポイズニングは、そもそも怪しい(アングラ)サーバを介して、詐称したパケットが攻撃対象となるDNSサーバに送信されることによるものです。
 DNSSECでは、キャッシュポイズニングを防ぐ仕組みです。
 DNSサーバが上位のDNSサーバ(このIPアドレスが改ざんされているかもしれない)に問い合わせるとき、上位DNSサーバの電子証明書を得ることで、本来の上位のDNSサーバであることを確認できます。また、問合せパケット内に、暗号化した特定の文字列を入れておき、応答の中の文字列が正しく復号できないときは、応答が不正サーバからであり、ここで得たIPアドレスが改ざんされているかもしれない(信用できない)と結論できます。


認可サーバによる認証・認可

共有サイトでの認証・認可

次のようなケースを例にします。
 あなたは、共有サイトに、写真やアプリを登録しています。限定した友人からのアクセスを期待していますが、友人により、写真を見るだけ、写真の投稿、アプリの実行など限定したいのです。

関係者とサーバ等(用語)

あなたが、共有サイトに写真やアプリを投稿して、あなたの友人に写真を見せたりアプリを利用させることを例に、ここで用いる用語を説明します。

次の4つのサーバなどがあります。

クライアント (client)
エンドユーザの端末です。
リソースオーナー (resource owner)
オーナーのWebページ。クライアントは、まずここを介してて、リソースサーバを利用します。
リソースサーバ (resource server)
オーナーがプロバイダのサイトに登録した写真やアプリです。
認可サーバ (authorization server)
リソースサーバにコンテンツを登録したときに、どのクライアントにどの処理を認可するか(写真を見るだけ、投稿も許す、アプリを実行するなど)の情報を加えますが、それをまとめたサーバです。プロバイダサイトにあります。
クライアントの認証・認可は認可サーバが行います。

認証と認可

  認証(Authentication)誰であるかを特定すること OpenID
  認可(Authorization) 利用権限を与えること   OAuth

本人認証だけでは全ての権限を与えることになります。特定の処理だけに限定するには認可が必要です。逆に、認可されれば認証は不要だと考えられますが、認可情報は第三者に漏洩する可能性があるので、重要なときには認証も必要になります。

(注)OAuth 2.0 は、アクセストークンの要求方法とそれに対する応答方法を標準化したものです。
OpenID Connectは、OAuth 2.0を使ってID連携をする際に、OAuth 2.0では標準化されていない機能で、かつID連携には共通して必要となる機能を標準化したものです。

マッシュアップでの認証

多くのサイトがそれぞれのサービス(Webサービス)をしています。例えば旅行の計画をするとき、列車予約と旅館予約の両方が必要になりますが、JRや私鉄、個別の旅館のサイトをいちいち調べるのでは大変です。それらのWebサービスを束ねるポータルサイトがあれば便利です。
 このような大規模のものでなく、店舗紹介ページにGoogle地図を埋め込むような小規模なものもあります。実際にはGoogleに利用を申し込むのですが、形式的には店舗ページがポータルサイト、Google地図がWebサービスになります。
 このような仕組みをマッシュアップといいます。

ここでは、大規模マッシュアップを想定した記述になっています。テーマは、利用者がポータルサイトを介して多数のWebサービスサイトを巡回するとき、異なるサイトにはいるたびに、ユーザID、パスワードなどを入力する手間を省くために、ポータルサイトで入力したものだけでよい(シングルサインイン)ようにする仕組みです。
 その仕組みには、OAuth 2.0/OpenID Connect を用います。

上述の「共有サイト」との関係、マッシュアップの特徴を列挙します。
 技術的には、「共有サイト」での用語を使うべきでしょうが、不自然な表現になるので、勝手に(OAuth 2.0/OpenID Connect の規格用語ではない)用語を使います。

マッシュアップの認証・認可手順

次のような手順により、利用者は最初のログインだけ(シングルサインイン)で、ポータルサイトに登録されているWebサービスサイトを巡回することができるのです。