JP2024110680A - 認証システムおよび認証サーバ - Google Patents

Abstract

【課題】認証強度を柔軟に設定可能な認証サーバおよび認証システムを提供する。【解決手段】通信端末１３は、ＩＥＥＥ８０２．１Ｘ規格に基づくサプリカントとして動作する。認証サーバ１０は、ＩＥＥＥ８０２．１Ｘ規格に基づき通信端末１３を認証する。認証装置１２は、ＩＥＥＥ８０２．１Ｘ規格に基づくオーセティケータとして動作し、通信端末１３との間でＥＡＰＯＬフレームを通信し、認証サーバ１０との間でＲＡＤＩＵＳパケットを通信する。認証サーバ１０は、認証装置１２からのＲＡＤＩＵＳパケットに含まれるＲＡＤＩＵＳ属性情報に基づいて複数の認証方式の中から１個の認証方式を選定し、選定した認証方式の使用を通信端末１３に提案する。【選択図】図１

Description

本発明は、認証システムおよび認証サーバに関する。

特許文献１には、ＭＡＣアドレスがランダム化された通信端末に対しても接続可否を判断可能な中継装置が示される。当該中継装置は、通信端末からの接続要求に含まれるＭＡＣアドレスが登録されたＭＡＣアドレスに対応しない場合、一時接続判定用の接続処理を実行して、当該通信端末からホスト名を取得する。そして、当該中継装置は、取得したホスト名が登録されたホスト名に対応する場合に接続を許可する。

特開２０２２－５０９４６号公報

有線ＬＡＮまたは無線ＬＡＮを含んだ認証システムでは、ＩＥＥＥ８０２．１Ｘ規格に基づく認証が広く用いられている。ＩＥＥＥ８０２．１Ｘ規格では、ＥＡＰ（Extensible Authentication Protocol）およびＲＡＤＩＵＳ（Remote Authentication Dial In User Service）規格を利用して認証が行われる。ＥＡＰは、様々な認証方式を利用するための手続きを規定するものである。ＲＡＤＩＵＳ規格は、ＲＡＤＩＵＳクライアントからの認証要求に対して、ＲＡＤＩＵＳサーバを用いて認証を行う際の手続きを規定するものである。

このような認証システムでは、使用する認証方式によって認証強度を変えることができる。例えば、認証強度が低い認証方式を用いる場合、被認証装置である通信端末に高度な機能を実装する必要がないため、セキュリティレベルが不十分となり得る反面、運用コスト、利便性または汎用性等の観点で有益となる。一方、認証強度が高い認証方式を用いる場合、通信端末に高度な機能を実装する必要があるため、セキュリティレベルは十分となり得るが、運用コスト、利便性または汎用性等の観点で不利益となる。そこで、このようなバランスを考慮して、認証強度を柔軟に設定できる仕組みが望まれる。

具体例として、特許文献１に記載されるような、ランダムＭＡＣアドレスを有する通信端末Ａと非ランダムＭＡＣアドレスを有する通信端末Ｂとが混在した認証システムを想定する。ランダムＭＡＣアドレスを有する通信端末Ａでは、非ランダムＭＡＣアドレスを有する通信端末Ｂとは異なり、ＭＡＣアドレスを含んだ通信ログから通信端末の挙動を追跡することは困難となり得る。このため、通信端末Ａには、通信端末Ｂと比べて、認証強度が高い認証方式を適用することが望ましい。ただし、全てを認証強度が高い認証方式に統一した場合、例えば、通信端末Ｂを用いる際の利便性等が損われる事態や、既存の通信端末Ｂでは当該認証方式に対応できない事態等が生じ得る。

本発明は、このようなことに鑑みてなされたものであり、その目的の一つは、認証強度を柔軟に設定可能な認証サーバおよび認証システムを提供することにある。

本発明の前記並びにその他の目的と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的な実施の形態の概要を簡単に説明すれば、次のとおりである。

一実施の形態による認証システムは、通信端末と、認証サーバと、認証装置と、を有する。通信端末は、ＩＥＥＥ８０２．１Ｘ規格に基づくサプリカントとして動作する。認証サーバは、ＩＥＥＥ８０２．１Ｘ規格に基づき通信端末を認証する。認証装置は、ＩＥＥＥ８０２．１Ｘ規格に基づくオーセティケータとして動作し、通信端末との間でＥＡＰＯＬフレームを通信し、認証サーバとの間でＲＡＤＩＵＳパケットを通信する。認証サーバは、認証装置からのＲＡＤＩＵＳパケットに含まれるＲＡＤＩＵＳ属性情報に基づいて複数の認証方式の中から１個の認証方式を選定し、選定した認証方式の使用を通信端末に提案する。

本願において開示される発明のうち、代表的な実施の形態によって得られる効果を簡単に説明すると、認証強度を柔軟に設定可能になる。

一実施の形態による認証システムの構成例および主要な動作例を示す概略図である。 図１に示される認証システムにおいて、認証装置と通信端末との間の通信で用いられるＥＡＰＯＬフレームのフォーマット構成例を示す概略図である。 図１に示される認証システムにおいて、認証装置と認証サーバとの間の通信で用いられるＲＡＤＩＵＳパケットのフォーマット構成例を示す概略図である。 図１に示される認証システムにおいて、非ランダムＭＡＣアドレスを有する通信端末を認証する場合の動作例を示すシーケンス図である。 図１に示される認証システムにおいて、ランダムＭＡＣアドレスを有する通信端末を認証する場合の動作例を示すシーケンス図である。 図４Ａとは異なる動作例を示すシーケンス図である。 図１における認証サーバの主要部の構成例を示す機能ブロック図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜認証システムの概略＞
図１は、一実施の形態による認証システムの構成例および主要な動作例を示す概略図である。図１に示される認証システムは、認証サーバ１０と、認証装置１２ａ，１２ｂと、通信端末１３ａ，１３ｂとを備える。認証装置１２ａ，１２ｂと認証サーバ１０とは、レイヤ３（Ｌ３）のネットワーク１１を介して接続される。また、認証装置１２ａ，１２ｂと通信端末１３ａ，１３ｂとは、レイヤ２（Ｌ２）のネットワークを介して接続される。明細書では、通信端末１３ａ，１３ｂを通信端末１３と総称し、認証装置１２ａ，１２ｂを認証装置１２と総称する。

通信端末１３は、ＩＥＥＥ８０２．１Ｘ規格に基づくサプリカントとして動作する。具体的には、通信端末１３は、例えば、プロセッサおよびメモリを有し、メモリに格納されたサプリカント用のプログラムをプロセッサにより実行することで、サプリカントとして動作する。この例では、通信端末１３ａは、パーソナルコンピュータ（ＰＣ）等であり、通信端末１３ｂは、スマートフォンやタブレットＰＣ等のモバイル機器である。通信端末１３ａは、ユーザ１４ａによって利用され、通信端末１３ｂは、ユーザ１４ｂによって利用される。

認証サーバ１０は、ＲＡＤＩＵＳサーバであり、ＩＥＥＥ８０２．１Ｘ規格に基づき、認証装置１２を介して通信端末１３を認証する。認証装置１２は、ＩＥＥＥ８０２．１Ｘ規格に基づくオーセティケータとして動作し、ＲＡＤＩＵＳクライアントでもある。認証装置１２ａ，１２ｂは、それぞれ、通信端末１３ａ，１３ｂとの間でＥＡＰＯＬ（EAP Over LAN）フレームを通信する。また、認証装置１２ａ，１２ｂは、認証サーバ１０との間でＲＡＤＩＵＳパケットを通信する。

ここで、例えば、認証装置１２ａは、ＭＡＣ（Medium Access Control）フレームを有線により中継する認証スイッチであり、認証装置１２ｂは、ＭＡＣフレームを無線により中継する無線アクセスポイントである。特に、公衆無線ＬＡＮ等のような無線通信ネットワークで利用される通信端末１３は、ユーザのプライバシーを保護する観点等から、ランダムＭＡＣアドレスを有する場合がある。このため、この例では、通信端末１３ｂは、ランダムＭＡＣアドレスを有しており、通信端末１３ａは、非ランダムＭＡＣアドレスを有している。

ランダムＭＡＣアドレスは、非ランダムＭＡＣアドレスとは異なり、４８ビットのＭＡＣアドレスにおける（４２ビット目，４１ビット目）が（１，０）に固定される。すなわち、ランダムＭＡＣアドレスは、１６進数表示を用い、“Ｘ”をドントケア値として、“Ｘ２：ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ”、“Ｘ６：ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ”、“ＸＡ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ”、または“ＸＥ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ”のいずれかである。

このような認証システムにおいて、通信端末１３ａの認証を行う場合を想定する。概略的には、まず、通信端末１３ａは、認証装置１２ａへ、ＥＡＰＯＬフレームを用いて認証情報を送信する（ステップＳ１０１ａ）。これに応じて、認証装置１２ａは、様々なＲＡＤＩＵＳ属性情報を含んだＲＡＤＩＵＳパケットを認証サーバ１０へ送信する（ステップＳ１０２ａ）。ＲＡＤＩＵＳ属性情報には、ＥＡＰＯＬフレームに含まれる認証情報に加えて、認証装置１２ａによって付加される認証情報も含まれ得る。

続いて、認証サーバ１０は、認証装置１２ａからのＲＡＤＩＵＳパケットに含まれるＲＡＤＩＵＳ属性情報に基づいて、予め設けられる複数の認証方式の中から１個の認証方式を選定する（ステップＳ１０３）。そして、認証サーバ１０は、選定した認証方式の使用を、認証装置１２ａを介して通信端末１３ａに提案する。具体的には、認証サーバ１０は、選定した認証方式の使用を提案するためのＲＡＤＩＵＳパケットを認証装置１２ａへ送信する（ステップＳ１０４ａ）。これに応じて、認証装置１２ａは、当該ＲＡＤＩＵＳパケットをＥＡＰＯＬフレームに変換して通信端末１３ａへ送信する（ステップＳ１０５ａ）。

通信端末１３ｂの認証を行う場合も、通信端末１３ａの場合と同様に、ステップＳ１０１ａ，Ｓ１０２ａ，Ｓ１０３，Ｓ１０４ａ，Ｓ１０５ａの処理にそれぞれ対応するステップＳ１０１ｂ，Ｓ１０２ｂ，Ｓ１０３，Ｓ１０４ｂ，Ｓ１０５ｂの処理が行われる。ただし、ステップＳ１０１ａ，Ｓ１０５ａでは、有線による通信が行われるのに対して、ステップＳ１０１ｂ，Ｓ１０５ｂでは、無線による通信が行われる。

このような方式を用いることで、ＲＡＤＩＵＳ属性情報から得られる様々な情報に基づいて、認証強度を柔軟に設定することが可能になる。具体例として、認証装置１２は、通信端末１３からのＥＡＰＯＬフレームに含まれる通信端末１３のＭＡＣアドレスを、ＲＡＤＩＵＳ属性情報の一つであるコーリングステーションＩＤに定めることができる。そして、認証装置１２は、当該コーリングステーションＩＤを含んだＲＡＤＩＵＳパケットを認証サーバ１０へ送信することができる（ステップＳ１０２ａ，Ｓ１０２ｂ）。

この場合、認証サーバ１０は、コーリングステーションＩＤの値、具体的には、前述した（４２ビット目，４１ビット目）の値に基づき、通信端末１３のＭＡＣアドレスが非ランダムＭＡＣアドレスであるかランダムＭＡＣアドレスであるかを判別することができる。そして、認証サーバ１０は、通信端末１３のＭＡＣアドレスがランダムＭＡＣアドレスである場合には、非ランダムＭＡＣアドレスである場合よりも認証強度が高い認証方式を選定することができる（ステップＳ１０３）。

ランダムＭＡＣアドレスを有する通信端末１３ｂでは、非ランダムＭＡＣアドレスを有する通信端末１３ａとは異なり、ＭＡＣアドレスを含んだ通信ログから通信端末１３ｂの挙動を追跡することは困難となり得る。このため、通信端末１３ｂには、通信端末１３ａと比べて、認証強度が高い認証方式を適用することが望まれる。図１に示される認証システムを用いることで、このような要求を満たすことが可能になる。

なお、認証サーバ１０に予め設けられる複数の認証方式として、例えば、ＰＥＡＰ（Protected EAP）、ＥＡＰ－ＴＬＳ（EAP-Transport Level Security）、ＥＡＰ－ＭＤ５（EAP-Message Digest 5）、ＥＡＰ－ＴＴＬＳ（EAP-Tunneled TLS）等が挙げられる。ＰＥＡＰおよびＥＡＰ－ＴＴＬＳは、認証サーバ１０におけるサーバ証明書と、通信端末１３におけるユーザＩＤおよびユーザパスワードとを用いた認証方式である。ＥＡＰ－ＴＬＳは、認証サーバ１０におけるサーバ証明書と、通信端末１３におけるクライアント証明書とを用いた認証方式である。ＥＡＰ－ＭＤ５は、サーバ証明書を用いずに、通信端末１３におけるユーザＩＤおよびユーザパスワードを用いた認証方式である。

認証強度は、サーバ証明書およびクライアント証明書を用いるＥＡＰ－ＴＬＳが最も高く、サーバ証明書もクライアント証明書も用いないＥＡＰ－ＭＤ５が最も低い。ただし、ＥＡＰ－ＴＬＳを用いる場合、特に、通信端末１３に予めクライアント証明書を組み込んでおく必要があるため、運用コスト、利便性または汎用性等の観点で不利益となり得る。また、ＰＥＡＰは、例えば、Ｗｉｎｄｏｗｓ（登録商標）等のＯＳを搭載した通信端末１３によって標準でサポートされている。このため、ＰＥＡＰは、運用コスト、利便性または汎用性等と、認証強度とのバランスに優れた認証方式となっている。

このような認証方式が設けられることを前提とすると、認証サーバ１０は、通信端末１３のＭＡＣアドレスがランダムＭＡＣアドレスである場合、すなわち通信端末１３ｂを認証する場合には、認証方式としてＥＡＰ－ＴＬＳを選定することが望ましい。一方、認証サーバ１０は、通信端末１３のＭＡＣアドレスが非ランダムＭＡＣアドレスである場合、すなわち通信端末１３ａを認証する場合には、認証方式としてＰＥＡＰを選定することが望ましい。

＜認証システムの詳細＞
図２Ａは、図１に示される認証システムにおいて、認証装置１２と通信端末１３との間の通信で用いられるＥＡＰＯＬフレームのフォーマット構成例を示す概略図である。図２Ａに示されるＥＡＰＯＬフレーム２０は、ＥＡＰＯＬプロトコルに基づくＭＡＣフレームでもある。ＥＡＰＯＬフレーム２０は、宛先ＭＡＣアドレス３０、送信元ＭＡＣアドレス３１およびＥＡＰメッセージ３２の各領域を含んでいる。ＥＡＰメッセージ３２は、パケットタイプ３３およびパケットボディ３４の各領域を含んでいる。パケットボディ３４は、ＥＡＰパケット２１を含んでいる。ＥＡＰパケット２１は、コード３５、タイプ３６およびデータ３７の各領域を含んでいる。

パケットタイプ３３では、ＥＡＰパケット、ＥＡＰ開始またはＥＡＰ終了等のように、パケットに担わせる機能が設定される。パケットタイプ３３によってＥＡＰパケットが設定された場合、ＥＡＰパケット２１内のコード３５によって、ＥＡＰリクエスト、ＥＡＰレスポンス、ＥＡＰ成功またはＥＡＰ失敗のように、命令または通知の内容が設定される。さらに、タイプ３６によって、“Ｉｄｅｎｔｉｔｙ”または“ＮＡＫ”といった通知の内容や、ＥＡＰ－ＴＬＳまたはＰＥＡＰ等のように、認証方式の種別が設定される。データ３７の領域には、コード３５またはタイプ３６の設定内容に応じた各データが格納される。なお、ＥＡＰ成功は認証成功を表し、ＥＡＰ失敗は認証失敗を表す。

図２Ｂは、図１に示される認証システムにおいて、認証装置１２と認証サーバ１０との間の通信で用いられるＲＡＤＩＵＳパケットのフォーマット構成例を示す概略図である。ＲＡＤＩＵＳパケット２６は、図２Ｂに示されるように、ＵＤＰ（User Datagram Protocol）パケット２５内のＵＤＰデータ４２の領域に格納される。ＵＤＰパケット２５は、ＵＤＰデータ４２の領域に加えて、送信元ポート４０および宛先ポート４１の各領域を含んでいる。送信元ポート４０および宛先ポート４１の各領域には、ＲＡＤＩＵＳを表す規定値が格納される。

ＲＡＤＩＵＳパケット２６は、コード４３、認証符号４４およびアトリビュート４５の各領域を含んでいる。コード４３では、ＲＡＤＩＵＳアクセスリクエスト、ＲＡＤＩＵＳアクセス許可、ＲＡＤＩＵＳアクセス拒否、ＲＡＤＩＵＳアクセスチャレンジ等といったように、命令または通知の内容が設定される。認証符号４４の領域は、データの偽造を防止するために用いられる。アトリビュート４５は、任意の数であるｎ個のＲＡＤＩＵＳ属性情報４６［１］～４６［ｎ］の領域を含んでいる。明細書では、ｎ個のＲＡＤＩＵＳ属性情報４６［１］～４６［ｎ］をＲＡＤＩＵＳ属性情報４６と総称する。各ＲＡＤＩＵＳ属性情報４６は、タイプ（Ｔ）、長さ（Ｌ）および属性値（Ｖ）からなるＴＬＶ形式で表される。

ＲＡＤＩＵＳ属性情報４６には、例えば、ユーザＩＤ、ユーザパスワード、ＮＡＳ－ＩＰアドレス、コーリングステーションＩＤ、コールドステーションＩＤ等を代表に、様々な認証情報が含まれ得る。ＮＡＳ－ＩＰアドレスは、認証装置１２のＩＰアドレスに定められる。コーリングステーションＩＤは、前述したように、通信端末１３のＭＡＣアドレスに定められる。コールドステーションＩＤは、認証装置１２のＭＡＣアドレスや、加えて、通信端末１３が用いるＳＳＩＤ（Service Set IDentifier）に定められる。

また、ＲＡＤＩＵＳ属性情報４６には、図２Ａに示したＥＡＰメッセージ３２の情報を含ませることが可能である。これにより、認証装置１２は、通信端末１３からのＥＡＰＯＬフレーム２０を受信し、それに含まれるＥＡＰメッセージ３２を、ＲＡＤＩＵＳパケット２６に格納して認証サーバ１０へ送信することができる。同様に、認証装置１２は、認証サーバ１０からのＲＡＤＩＵＳパケット２６を受信し、それに含まれるＥＡＰメッセージ３２を表すＲＡＤＩＵＳ属性情報４６を、ＥＡＰＯＬフレーム２０に格納して通信端末１３へ送信することができる。

図３は、図１に示される認証システムにおいて、非ランダムＭＡＣアドレスを有する通信端末１３ａを認証する場合の動作例を示すシーケンス図である。図３において、通信端末１３ａは、認証装置１２ａへ、ＥＡＰ開始を通知する（ステップＳ２０１）。ＥＡＰ開始を通知された認証装置１２ａは、通信端末１３ａへ、認証情報の一つであるユーザＩＤを要求するためのＥＡＰリクエストを送信する（ステップＳ２０２）。これに応じて、通信端末１３ａは、認証装置１２ａへ、ユーザＩＤを含んだＥＡＰレスポンスを送信する（ステップＳ２０３）。

続いて、ＥＡＰレスポンスを受信した認証装置１２ａは、認証サーバ１０へ、様々なＲＡＤＩＵＳ属性情報４６を含んだＲＡＤＩＵＳアクセスリクエストを送信する（ステップＳ２０４）。この際に、ＲＡＤＩＵＳ属性情報４６には、ＥＡＰレスポンス内のＥＡＰメッセージ３２に含まれる認証情報、例えばユーザＩＤ等に加えて、コーリングステーションＩＤ等も含まれる。詳細には、認証装置１２ａは、通信端末１３ａからのＥＡＰＯＬフレーム２０に含まれる通信端末１３ａのＭＡＣアドレス、例えば、送信元ＭＡＣアドレス３１を、コーリングステーションＩＤに定める。そして、認証装置１２ａは、認証サーバ１０へ、コーリングステーションＩＤ等を含んだＲＡＤＩＵＳアクセスリクエストを送信する。

次いで、ＲＡＤＩＵＳアクセスリクエストを受信した認証サーバ１０は、コーリングステーションＩＤの値に基づき、通信端末１３ａのＭＡＣアドレスが非ランダムＭＡＣアドレスであるかランダムＭＡＣアドレスであるかを判別する（ステップＳ２０５）。ここでの判別結果は、非ランダムＭＡＣアドレスである。このため、認証サーバ１０は、認証方式としてＰＥＡＰを選定する（ステップＳ２０５）。

続いて、認証サーバ１０は、ＰＥＡＰの使用を提案するためのＲＡＤＩＵＳアクセスチャレンジを認証装置１２ａへ送信する（ステップＳ２０６）。ＲＡＤＩＵＳアクセスチャレンジを受信した認証装置１２ａは、ＰＥＡＰの使用を提案するためのＥＡＰリクエストを通信端末１３ａへ送信する（ステップＳ２０７）。これに応じて、通信端末１３ａは、ＰＥＡＰの使用を受諾するためのＥＡＰレスポンスを認証装置１２ａへ送信する（ステップＳ２０８）。

次いで、ＥＡＰレスポンスを受信した認証装置１２ａは、ＰＥＡＰの使用を受諾するためのＲＡＤＩＵＳアクセスリクエストを認証サーバ１０へ送信する（ステップＳ２０９）。これに応じて、認証サーバ１０は、ＰＥＡＰ認証の開始を通知するためのＲＡＤＩＵＳアクセスチャレンジを認証装置１２ａへ送信する（ステップＳ２１０）。そして、ＲＡＤＩＵＳアクセスチャレンジを受信した認証装置１２ａは、ＰＥＡＰ認証の開始を通知するためのＥＡＰリクエストを通信端末１３ａへ送信する（ステップＳ２１１）。

以降は、通信端末１３ａと認証装置１２ａと認証サーバ１０との間で、ＰＥＡＰで規定される認証シーケンスが実行される（ステップＳ２１２）。概略的には、サーバ証明書を用いたＴＬＳネゴシエーションによって、通信端末１３ａと認証サーバ１０との間に暗号化保護を行うためのＴＬＳセッションが構築される。そして、認証サーバ１０は、ＴＬＳセッションの中で、チャレンジレスポンス方式を用いて通信端末１３ａにおけるユーザＩＤおよびユーザパスワードの認証可否を判定する。

その結果、認証サーバ１０は、認証を許可する場合には、認証成功を表すＲＡＤＩＵＳアクセス許可を認証装置１２ａへ通知し、認証を拒否する場合には、認証失敗を表すＲＡＤＩＵＳアクセス拒否を認証装置１２ａへ通知する。認証装置１２ａは、ＲＡＤＩＵＳアクセス許可またはＲＡＤＩＵＳアクセス拒否を、それぞれ、ＥＡＰ成功およびＥＡＰ失敗に変換して通信端末１３ａへ通知する。

図４Ａおよび図４Ｂは、図１に示される認証システムにおいて、ランダムＭＡＣアドレスを有する通信端末１３ｂを認証する場合の動作例を示すシーケンス図である。図４Ａには、通信端末１３ｂにクライアント証明書が組み込まれている場合の動作例が示され、図４Ｂには、通信端末１３ｂにクライアント証明書が組み込まれていない場合の動作例が示される。

図４Ａにおいて、まず、図３の場合と同様に、ステップＳ２０１～Ｓ２０４の処理が行われる。すなわち、通信端末１３ｂは認証装置１２ｂへＥＡＰ開始を通知し、認証装置１２ｂは通信端末１３ｂへＥＡＰリクエストを送信し、通信端末１３ｂは認証装置１２ｂへＥＡＰレスポンスを送信する（ステップＳ２０１～Ｓ２０３）。そして、認証装置１２ｂは、認証サーバ１０へ、ＲＡＤＩＵＳアクセスリクエストを送信する（ステップＳ２０４）。

続いて、ＲＡＤＩＵＳアクセスリクエストを受信した認証サーバ１０は、図３の場合と同様に、コーリングステーションＩＤの値に基づき、通信端末１３ｂのＭＡＣアドレスが非ランダムＭＡＣアドレスであるかランダムＭＡＣアドレスであるかを判別する（ステップＳ３０５）。ここでの判別結果は、図３の場合と異なりランダムＭＡＣアドレスである。このため、認証サーバ１０は、認証方式としてＥＡＰ－ＴＬＳを選定する（ステップＳ３０５）。

その後は、ステップＳ３０６～Ｓ３１１において、図３で述べたステップＳ２０６～Ｓ２１１の処理と同様の処理が行われる。ただし、ステップＳ３０６，Ｓ３０７において、認証サーバ１０によって提案される認証方式は、図３の場合とは異なり、ＥＡＰ－ＴＬＳである。また、通信端末１３ｂには、クライアント証明書が組み込まれている。このため、通信端末１３ｂは、認証サーバ１０からＥＡＰ－ＴＬＳの使用を提案されたのち、当該提案を受諾する（ステップＳ３０８，Ｓ３０９）。これに応じて、認証サーバ１０は、通信端末１３ｂへ、ＥＡＰ－ＴＬＳ認証の開始を通知する（ステップＳ３１０，Ｓ３１１）。

以降は、通信端末１３ｂと、認証装置１２ｂと、認証サーバ１０との間で、ＥＡＰ－ＴＬＳで規定される認証シーケンスが実行される（ステップＳ３１２）。概略的には、ＴＬＳネゴシエーションによって、認証サーバ１０からのサーバ証明書の正当性が通信端末１３ｂによって検証され、通信端末１３ｂからのクライアント証明書の正当性が認証サーバ１０によって検証される。

認証サーバ１０は、これらの証明書が正当であった場合には、認証成功を表すＲＡＤＩＵＳアクセス許可を認証装置１２ｂへ通知し、いずれかの証明書が不当であった場合には、認証失敗を表すＲＡＤＩＵＳアクセス拒否を認証装置１２ｂへ通知する。認証装置１２ｂは、ＲＡＤＩＵＳアクセス許可またはＲＡＤＩＵＳアクセス拒否を、それぞれ、ＥＡＰ成功およびＥＡＰ失敗に変換して通信端末１３ｂへ通知する。

図４Ｂでも、図４Ａの場合と同様に、ステップＳ２０１～Ｓ２０４、Ｓ３０５～Ｓ３０７の処理が順に行われる。ただし、図４Ａの場合と異なり、通信端末１３ｂには、クライアント証明書が組み込まれていない。このため、通信端末１３ｂは、認証サーバ１０からＥＡＰ－ＴＬＳの使用を提案されたのち（ステップＳ３０６，Ｓ３０７）、当該提案を拒否する（ステップＳ４０８）。

詳細には、通信端末１３ｂは、例えば、ＥＡＰ－ＴＬＳの使用を拒否し、かつＰＥＡＰの使用を提案するためのＥＡＰレスポンスを認証装置１２ｂへ送信する（ステップＳ４０８）。認証装置１２ｂは、当該ＥＡＰレスポンスをＲＡＤＩＵＳアクセスリクエストに変換して認証サーバ１０へ送信する（ステップＳ４０９）。ここで、認証サーバ１０は、通信端末１３ｂのＭＡＣアドレスがランダムＭＡＣアドレスであると判別した場合には、ＥＡＰ－ＴＬＳの使用のみを許可し、他の認証方式の使用を禁止する。このため、認証サーバ１０は、ＥＡＰ－ＴＬＳの使用を提案したのち、当該提案が通信端末１３ｂによって拒否された場合、他の認証方式、ここではＰＥＡＰに変更せずに、認証失敗と判定する。

その結果、認証サーバ１０は、認証装置１２ｂへ、認証失敗を表すＲＡＤＩＵＳアクセス拒否を通知する（ステップＳ４１０）。認証装置１２ｂは、ＲＡＤＩＵＳアクセス拒否をＥＡＰ失敗に変換して通信端末１３ｂへ通知する（ステップＳ４１１）。その後、認証装置１２ｂは、通信端末１３ｂからの所定のネットワークへのアクセスを遮断する。これにより、ランダムＭＡＣアドレスを有する通信端末１３ｂに対して、セキュリティを強化することが可能になる。

＜変形例について＞
図３、図４Ａおよび図４Ｂでは、ＲＡＤＩＵＳ属性情報４６の一つであるコーリングステーションＩＤ、すなわち通信端末１３のＭＡＣアドレスに基づいて、提案する認証方式を選定する例を示した。ただし、認証方式を選定するために用いるＲＡＤＩＵＳ属性情報４６は、コーリングステーションＩＤに限らず、例えば、ＮＡＳ－ＩＰアドレスや、コールドステーションＩＤ等であってもよい。

これらのＲＡＤＩＵＳ属性情報４６には、認証装置１２のＩＰアドレスおよびＭＡＣアドレスや、通信端末１３ｂが使用するＳＳＩＤが含まれる。これにより、例えば、複数の認証装置１２が設けられる場合に、認証装置１２毎に、ひいては、認証装置１２毎の単数または複数の通信端末１３を単位として認証方式を変えることや、ＳＳＩＤ毎に認証方式を変えることが可能になる。

また、認証装置１２ａからのＲＡＤＩＵＳ属性情報４６には、例えば、通信端末１３ａが接続される物理ポートの識別子等が含まれ得る。この場合、物理ポート毎に、ひいては、物理ポート毎の通信端末１３ａを単位として認証方式を変えることが可能になる。

＜認証サーバの詳細＞
図５は、図１における認証サーバ１０の主要部の構成例を示す機能ブロック図である。図５に示される認証サーバ１０は、属性情報判別部５０と、認証方式選定部５１と、認証方式提案部５２と、認証シーケンス実行部５３とを備える。これらの各部は、例えば、プロセッサがメモリに格納されたプログラムを実行することで実現される。ただし、これらの各部は、プロセッサによるプログラム処理に限らず、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）等によるハードウェア処理で実現されてもよく、プログラム処理とハードウェア処理との組み合わせで実現されてもよい。

属性情報判別部５０は、オーセティケータとして動作する認証装置１２からのＲＡＤＩＵＳパケット２６に含まれる、ＲＡＤＩＵＳ属性情報４６の内容を判別する。認証方式選定部５１は、属性情報判別部５０での判別結果に基づいて複数の認証方式の中から１個の認証方式を選定する。すなわち、属性情報判別部５０および認証方式選定部５１は、例えば、図３に示したステップＳ２０５、図４Ａおよび図４Ｂに示したステップＳ３０５の処理を実行する。

認証方式提案部５２は、認証方式選定部５１で選定した認証方式の使用を、サプリカントとして動作する通信端末１３に提案する。また、認証方式提案部５２は、選定した認証方式の使用を通信端末１３に提案したのち、当該提案が通信端末１３によって拒否された場合、通信端末１３へ認証失敗を通知する。ただし、この際に、認証方式提案部５２は、認証失敗を通知する前に、属性情報判別部５０での判別結果に応じて、他の認証方式へ変更するか否かを定めてもよい。

例えば、図３に示したように、属性情報判別部５０での判別結果が非ランダムＭＡＣアドレスである場合で、ステップＳ２０８にて、仮に、ＰＥＡＰの使用が拒否された際には、認証方式提案部５２は、通信端末１３ａとのネゴシエーションを介して、ＰＥＡＰを他の認証方式に変更してもよい。一方、図４Ｂに示したように、属性情報判別部５０での判別結果がランダムＭＡＣアドレスである場合で、ＥＡＰ－ＴＬＳの使用が拒否された際には、認証方式提案部５２は、他の認証方式への変更を行わず、通信端末１３ｂへ認証失敗を通知する。

なお、認証方式提案部５２は、認証方式の使用の提案が通信端末１３によって受諾された場合には、認証方式を確定し、確定した認証方式を用いた認証の開始を通信端末１３に通知する。すなわち、認証方式提案部５２は、例えば、図３に示したステップＳ２０６，Ｓ２１０、図４Ａに示したステップＳ３０６，Ｓ３１０、図４Ｂに示したステップＳ３０６，Ｓ４１０の処理を実行する。

認証シーケンス実行部５３は、認証方式提案部５２からの確定した認証方式の情報を受けて、当該認証方式に基づく認証シーケンスを実行する。すなわち、認証シーケンス実行部５３は、例えば、図３に示したステップＳ２１２、図４Ａに示したステップＳ３１２の処理を実行する。

＜実施の形態の主要な効果＞
以上、実施の形態の方式では、認証サーバ１０がＲＡＤＩＵＳ属性情報４６に基づいて複数の認証方式の中から１個の認証方式を選定する。これにより、認証強度を柔軟に設定可能な認証サーバおよび認証システムを実現できる。特に、ＲＡＤＩＵＳ属性情報４６に基づいて、通信端末１３がランダムＭＡＣアドレスを有するか否かを判別し、ランダムＭＡＣアドレスを有する場合に限って高い認証強度を有する認証方式を選定することで、運用コスト等の増大を抑制しつつ、セキュリティを強化することが可能になる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、前述した実施の形態は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

例えば、前述したプログラムは、非一時的な有形のコンピュータ可読記録媒体に格納された上で、コンピュータに供給され得る。このような記録媒体として、例えば、ハードディスクドライブ等を代表とする磁気記録媒体、ＤＶＤ（Digital Versatile Disc）やブルーレイディスク等を代表とする光記録媒体、フラッシュメモリ等を代表とする半導体メモリ等が挙げられる。

１０：認証サーバ、１２：認証装置、１３：通信端末、２０：ＥＡＰＯＬフレーム、２６：ＲＡＤＩＵＳパケット、４６：ＲＡＤＩＵＳ属性情報、５０：属性情報判別部、５１：認証方式選定部、５２：認証方式提案部

Claims (8)

1. ＩＥＥＥ８０２．１Ｘ規格に基づくサプリカントとして動作する通信端末と、
   ＩＥＥＥ８０２．１Ｘ規格に基づき前記通信端末を認証する認証サーバと、
   ＩＥＥＥ８０２．１Ｘ規格に基づくオーセティケータとして動作し、前記通信端末との間でＥＡＰＯＬ（Extensible Authentication Protocol Over LAN）フレームを通信し、前記認証サーバとの間でＲＡＤＩＵＳ（Remote Authentication Dial In User Service）パケットを通信する認証装置と、
   を備える認証システムであって、
   前記認証サーバは、前記認証装置からの前記ＲＡＤＩＵＳパケットに含まれるＲＡＤＩＵＳ属性情報に基づいて複数の認証方式の中から１個の認証方式を選定し、選定した認証方式の使用を前記通信端末に提案する、
   認証システム。
2. 請求項１に記載の認証システムにおいて、
   前記通信端末は、ＭＡＣアドレスとして、非ランダムＭＡＣアドレスまたはランダムＭＡＣアドレスを有し、
   前記認証装置は、前記通信端末からの前記ＥＡＰＯＬフレームに含まれる前記通信端末のＭＡＣアドレスを、前記ＲＡＤＩＵＳ属性情報の一つであるコーリングステーションＩＤに定め、前記コーリングステーションＩＤを含んだ前記ＲＡＤＩＵＳパケットを前記認証サーバへ送信し、
   前記認証サーバは、前記コーリングステーションＩＤの値に基づき、前記通信端末のＭＡＣアドレスが前記非ランダムＭＡＣアドレスであるか前記ランダムＭＡＣアドレスであるかを判別し、前記ランダムＭＡＣアドレスである場合には、前記非ランダムＭＡＣアドレスである場合よりも認証強度が高い認証方式を選定する、
   認証システム。
3. 請求項２に記載の認証システムにおいて、
   前記認証サーバは、前記通信端末のＭＡＣアドレスが前記ランダムＭＡＣアドレスである場合には、ＥＡＰ－ＴＬＳ（EAP-Transport Level Security）を選定し、前記非ランダムＭＡＣアドレスである場合には、ＰＥＡＰ（Protected EAP）を選定する、
   認証システム。
4. 請求項２に記載の認証システムにおいて、
   前記認証サーバは、前記通信端末のＭＡＣアドレスが前記ランダムＭＡＣアドレスである場合、前記選定した認証方式の使用を前記通信端末に提案したのち、当該提案が前記通信端末によって拒否された際には、他の認証方式への変更を行わず、前記通信端末へ認証失敗を通知する、
   認証システム。
5. ＩＥＥＥ８０２．１Ｘ規格に基づき、サプリカントとして動作する通信端末を、オーセティケータを介して認証する認証サーバであって、
   前記オーセティケータからのＲＡＤＩＵＳ（Remote Authentication Dial In User Service）パケットに含まれるＲＡＤＩＵＳ属性情報の内容を判別する属性情報判別部と、
   前記属性情報判別部での判別結果に基づいて複数の認証方式の中から１個の認証方式を選定する認証方式選定部と、
   前記認証方式選定部で選定した認証方式の使用を前記サプリカントに提案する認証方式提案部と、
   を備える、
   認証サーバ。
6. 請求項５に記載の認証サーバにおいて、
   前記通信端末は、ＭＡＣアドレスとして、非ランダムＭＡＣアドレスまたはランダムＭＡＣアドレスを有し、
   前記オーセティケータは、前記通信端末のＭＡＣアドレスを、前記ＲＡＤＩＵＳ属性情報の一つであるコーリングステーションＩＤに定め、前記コーリングステーションＩＤを含んだ前記ＲＡＤＩＵＳパケットを前記認証サーバへ送信し、
   前記属性情報判別部は、前記コーリングステーションＩＤの値に基づき、前記通信端末のＭＡＣアドレスが前記非ランダムＭＡＣアドレスであるか前記ランダムＭＡＣアドレスであるかを判別し、
   前記認証方式選定部は、前記通信端末のＭＡＣアドレスが前記ランダムＭＡＣアドレスである場合には、前記非ランダムＭＡＣアドレスである場合よりも認証強度が高い認証方式を選定する、
   認証サーバ。
7. 請求項６に記載の認証サーバにおいて、
   前記認証方式選定部は、前記通信端末のＭＡＣアドレスが前記ランダムＭＡＣアドレスである場合には、ＥＡＰ－ＴＬＳ（Extensible Authentication Protocol-Transport Level Security）を選定し、前記非ランダムＭＡＣアドレスである場合には、ＰＥＡＰ（Protected EAP）を選定する、
   認証サーバ。
8. 請求項６に記載の認証サーバにおいて、
   前記認証方式提案部は、前記通信端末のＭＡＣアドレスが前記ランダムＭＡＣアドレスである場合、前記選定した認証方式の使用を前記通信端末に提案したのち、当該提案が前記通信端末によって拒否された際には、他の認証方式への変更を行わず、前記通信端末へ認証失敗を通知する、
   認証サーバ。

Images