JP4681990B2 - 通信システム及び通信方式 - Google Patents

Description

本発明は、通信システム及び通信方法に関し、特に、ドメイン間の高速ローミングに適した通信システム及び通信方法に関する。

近年、無線通信技術の発展により、無線ＬＡＮや携帯移動通信システムなどの無線通信を利用した無線通信システムが広く普及している。これらの無線通信システムは、企業内や家庭内といった私設ネットワークのみならず、公衆ネットワークにおいても利用されている。

このような無線通信システムでは、移動端末とアクセスポイント（ＡＰ）間の通信が無線で行われるため、第三者によるなりすまし、改ざん、傍受などの危険性があるので、高いセキュリティ性が要求される。そして、移動端末からネットワークへのアクセスするためのアクセス権限の認証についてもセキュリティ性の面から見て重要となっている。

例えば、無線ＬＡＮの代表的な標準化方式であるＩＥＥＥ８０２．１ｘでは、認証プロトコルとしてＥＡＰ（Extensible Authentication Protocol）が規格化されている。ＥＡＰには、ＣＨＡＰ（Challenge Handshake Authentication Protocol）認証方式であるＥＡＰ−ＭＤ５（Message Digest 5）や、電子証明書を利用してサーバ側とクライアント（移動端末）側の双方で認証を行うＥＡＰ−ＴＬＳ（Transport Layer Security）、サーバ側のみ電子証明書を利用した認証を行うＥＡＰ−ＴＴＬＳ（Tunneled TLS）等がある。

このような認証方式を採用する無線通信システムは、ユーザが利用する移動端末と、ネットワークのアクセスを認証する認証サーバを有している。認証サーバ及び移動端末では、移動端末が無線ＬＡＮのアクセスポイントと通信を開始する際に、認証プロトコルにしたがって認証処理が行われる。

図１４は、認証プロトコルがＥＡＰ−ＴＴＬＳの場合に、移動端末と認証サーバ間で行われる認証処理を示している。ＥＡＰ−ＴＴＬＳでは、フェーズ１でＴＬＳ−ｔｕｎｎｅｌ確立を行った後、フェーズ２でユーザ認証が行われる。

まず、フェーズ１において、Ｉｄｅｎｔｉｔｙを含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットが移動端末から認証サーバへ送信され、ＴＴＬＳ ｓｔａｒｔを含むＥＡＰ Ｒｅｑｕｅｓｔパケットが認証サーバから移動端末へ送信された後、移動端末は、Ｃｌｉｅｎｔ乱数の生成と、Ｃｉｐｈｅｒ−Ｓｕｉｔｅ ｌｉｓｔの作成を行う（Ｓ１３０１）。このＣｉｐｈｅｒ−Ｓｕｉｔｅ（暗号群）は、キー交換用のプロトコルや、暗号化アルゴリズム、ＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）生成アルゴリズム等を含むものであり、Ｃｉｐｈｅｒ−Ｓｕｉｔｅ ｌｉｓｔは、Ｃｉｐｈｅｒ−Ｓｕｉｔｅを複数並べたものである。そして、移動端末は、生成したＣｌｉｅｎｔ乱数とＣｉｐｈｅｒ−Ｓｕｉｔｅ ｌｉｓｔ（ＳＱ３０１）を含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットを認証サーバへ送信する。

次いで、認証サーバは、移動端末へ割り当てるＳｅｓｓｉｏｎ−ＩＤの生成、Ｓｅｒｖｅｒ乱数の生成、Ｃｉｐｈｅｒ−Ｓｕｉｔｅの選定を行う（Ｓ１３０２）。そして、認証サーバは、生成したＳｅｓｓｉｏｎ−ＩＤと選定したＣｉｐｈｅｒ−Ｓｕｉｔｅ、Ｓｅｒｖｅｒ−Ｃｅｒｔ、Ｓｅｒｖｅｒ乱数（ＳＱ３０２）を含むＥＡＰ Ｒｅｑｕｅｓｔパケットを移動端末へ送信する。このＳｅｒｖｅｒ−Ｃｅｒｔは、電子証明書であり、サーバ自身の証明書からルート証明機関の証明書までの複数の証明書のリストが含まれている。

次いで、移動端末は、Ｃｅｒｔ−Ｂａｓｅｄ Ｓｅｒｖｅｒ認証処理、Ｐｒｅ−ｍａｓｔｅｒ−ｋｅｙの生成とＰＫＩ（Public Key Infrastructure）−ｂａｓｅｄ暗号化、Ｃｉｐｈｅｒ−ｋｅｙの生成を行い（Ｓ１３０３）、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ処理を行う。Ｃｅｒｔ−Ｂａｓｅｄ Ｓｅｒｖｅｒ認証処理は、受信した電子証明書を用いてサーバ認証を行う処理であり、処理時間や負荷が大きく、それらは証明書の信頼パスの長さに依存する。Ｐｒｅ−ｍａｓｔｅｒ−ｋｅｙは、４８バイトの乱数であり、Ｃｉｐｈｅｒ−ｋｅｙの作成の種となる。ＰＫＩ−ｂａｓｅｄ暗号化は、サーバの証明書から得られたサーバ公開鍵を用いて公開鍵暗号方式によりＰｒｅ−ｍａｓｔｅｒ−ｋｅｙを暗号化する。Ｃｉｐｈｅｒ−ｋｅｙは、Ｐｒｅ−ｍａｓｔｅｒ−ｋｅｙから生成され、認証サーバと移動端末の暗号化鍵や、ＭＡＣシークレット、初期ベクトル（ＩＶ）のセットである。Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ処理は、認証サーバと移動端末間でネゴシエーションした暗号化仕様や鍵の利用を開始させる処理である。そして、移動端末は、生成したＰｒｅ−ｍａｓｔｅｒ−ｋｅｙ（ＳＱ３０３）、ｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃを含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットを認証サーバへ送信する。

次いで、認証サーバは、受信したＰｒｅ−ｍａｓｔｅｒ−ｋｅｙの復号化、Ｃｉｐｈｅｒ−ｋｅｙの生成を行い（Ｓ１３０４）、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ処理を行う。そして、認証サーバは、ｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃを含むＥＡＰ Ｒｅｑｕｅｓｔパケットを移動端末へ送信する。

フェーズ１の認証が成功すると、フェーズ２において、移動端末と認証サーバとの間で、ＣＨＡＰ等によりユーザ認証が行われる。

図１５は、認証プロトコルがＥＡＰ−ＴＬＳの場合に、移動端末と認証サーバ間で行われる認証処理を示している。ＥＡＰ−ＴＬＳは、ＥＡＰ−ＴＴＬＳと比べて、電子証明書の認証を双方で行う点が異なる。

まず、移動端末と認証サーバとの間で、Ｉｄｅｎｔｉｔｙを含むＥＡＰ Ｒｅｓｐｏｎｓｅパケット、ＴＬＳ ｓｔａｒｔを含むＥＡＰ Ｒｅｑｕｅｓｔパケットが送受信された後、移動端末は、Ｃｌｉｅｎｔ乱数の生成、Ｃｉｐｈｅｒ−Ｓｕｉｔｅ ｌｉｓｔの作成を行い（Ｓ１４０１）、Ｃｌｉｅｎｔ乱数とＣｉｐｈｅｒ−Ｓｕｉｔｅ ｌｉｓｔ（ＳＱ４０１）を含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットを認証サーバへ送信する。

次いで、認証サーバは、Ｓｅｓｓｉｏｎ−ＩＤの生成、Ｓｅｒｖｅｒ乱数の生成、Ｃｉｐｈｅｒ−Ｓｕｉｔｅの選定を行い（Ｓ１４０２）、Ｓｅｓｓｉｏｎ−ＩＤ、Ｃｉｐｈｅｒ−Ｓｕｉｔｅ、Ｓｅｒｖｅｒ−Ｃｅｒｔ、Ｓｅｒｖｅｒ乱数、Ｃｅｒｔ−Ｒｅｑｕｅｓｔ（ＳＱ４０２）を含むＥＡＰ Ｒｅｑｕｅｓｔパケットを移動端末へ送信する。Ｃｅｒｔ−Ｒｅｑｕｅｓｔは、移動端末に電子証明書を要求するものである。

次いで、移動端末は、Ｃｅｒｔ−Ｂａｓｅｄ Ｓｅｒｖｅｒ認証処理、Ｐｒｅ−ｍａｓｔｅｒ−ｋｅｙの生成とＰＫＩ−ｂａｓｅｄ暗号化、Ｃｉｐｈｅｒ−ｋｅｙの生成を行い（Ｓ１４０３）、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ処理を行う。そして、移動端末は、Ｐｒｅ−ｍａｓｔｅｒ−ｋｅｙ（ＳＱ４０３）、Ｃｌｉｅｎｔ−Ｃｅｒｔ、ｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃを含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットを認証サーバへ送信する。Ｃｌｉｅｎｔ−Ｃｅｒｔは、クライアント（移動端末）の電子証明書である。

次いで、認証サーバは、Ｃｅｒｔ−ｂａｓｅｄ Ｃｌｉｅｎｔ認証処理を行い、Ｐｒｅ−ｍａｓｔｅｒ−ｋｅｙ復号化とＣｉｐｈｅｒ−ｋｅｙの生成を行い（Ｓ１４０４）、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ処理を行う。Ｃｅｒｔ−ｂａｓｅｄ Ｃｌｉｅｎｔ認証処理は、受信した電子証明書を用いてクライアント認証を行う処理である。そして、認証サーバは、ｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃを含むＥＡＰ Ｒｅｑｕｅｓｔパケットを移動端末へ送信する。

図１４や図１５のように、認証が行われる場合、移動端末と認証サーバにおいて電子証明書認証など複雑な処理のため処理負荷が高く、移動端末と認証サーバとの間でも多くの情報がやり取りされる。したがって、認証開始から認証終了まで時間がかかり、認証処理後のデータ通信に遅延が生じる場合がある。特に、マルチドメインでのローミングなど異なるドメイン間のハンドオーバ時に大きな問題となる。ハンドオーバでは、通信の中断を極力抑える必要があるが、ドメイン間を移動すると認証方式やドメイン認証ポリシーが変わることがあるため、新たなアクセス認証が必要となる。したがって、ハンドオーバ時に認証処理の全てを再度実行することとなり、認証処理に時間がかかってしまう。この場合、ハンドオーバ時に、移動端末の通信が一時的に中断される可能性が高くなる。

このような問題を解決する技術として、例えば、特許文献１や２、非特許文献１が知られている。

特許文献１には、無線通信システムにおいて、Ｎｅｉｇｈｂｏｒ Ｇｒａｐｈ（周辺ＡＰの構成図）を用いて、予め認証セッションの共通鍵をＡＰ間に転送することによって、高速かつ安定的なローミングサービスを可能とし、移動端末がシームレスな通信を行うための技術が記載されている。

特許文献２には、通信システムにおいて、確定された通信セッションの継続的な利用を可能とし、異なった認証レイヤや異なったネットワークインタフェースを経由した場合でも、高速認証または高速再認証を行うための技術が記載されている。

また、非特許文献１（ＩＥＴＦドラフト）には、無線通信システムにおいて、最初の完全認証（Full Authentication）時に、確立される認証セッション共通鍵及び事前共通鍵から、移動先で利用する新たな認証セッション共通鍵を計算することで、移動時に簡易な認証を行うことにより、その処理時間と処理負荷の削減を可能とする技術が記載されている。
特開２００４−２２２３００号公報 特開２００４−２０１２８８号公報 T.Clancy、外２名、"Technique for Method-Specific Fast EAP Rekeying"、［ｏｎｌｉｎｅ］、２００４年８月、Network Working Group、［平成１７年８月２５日検索］、インターネット＜ＵＲＬ：http://www.cs.umd.edu/~clancy/docs/draft-clancy-eap-rekeying-00.html＞

上記のように、従来の通信システムでは、ハンドオーバ時、認証処理の負荷が高く、処理に時間がかかるためシームレスなローミングサービスの弊害になるという問題がある。

上記特許文献１では、移動前のＡＰで認証セッションの共有鍵を生成し、移動端末が移動しうるＡＰ群に予め共有鍵を転送させることにより、再認証の処理を省略している。したがって、この方式では、ＡＰの変更が必須となるが、マルチドメイン環境において、全てのＡＰを変更することは大変難しく、コスト面を考えても不利である。また、プロアクティブキャッシング技法を実現するためには、周辺ＡＰの構成情報の把握や、隣接ＡＰとの間にセキュアな転送通路が必須となるが、異なるドメイン間において、ＡＰ構成情報の交換や、ＡＰ間の直接的な信頼関係を構成するのは、ポリシー的に困難である。したがって、この方式をマルチドメイン環境に適用するのは難しいと考えられる。

上記特許文献２では、認証レイヤの通信メディアの変更や、移動端末の移動があっても、移動端末と認証サーバ間の通信セッション情報の共有により、高速認証または再認証を可能としているが、移動前後の認証セッションの種類が変わる場合（例えば、ＥＡＰ−ＴＬＳの認証方式からＥＡＰ−ＴＴＬＳの認証方式に変更）、この方式を適用することはできない。

上記非特許文献１では、マルチドメイン環境への適用方式については言及されておらず、移動前後のドメインにおいて認証装置が変わる場合、移動端末とＡＰ間の共通鍵を作成することができない。また、移動前後で利用される認証方式が変わる場合に対応できないことや、移動後に移動端末と認証サーバ間で相互認証を行わないため、認証の信頼性及びセキュリティ強度が不十分であること等から、当該技術をそのままマルチドメイン環境に適用することは難しい。

本発明は以上のような事情を背景としてなされたものであって、本発明の目的は、マルチドメイン環境下でハンドオーバ時のアクセス認証の時間と処理負荷を削減できる通信システムを提供することを目的とする。

本発明にかかる通信システムは、移動端末と通信可能な複数の第１のアクセスポイントと、第１の認証方式に従って前記移動端末の認証を実行する第１の認証サーバを有する第１のドメインと、移動端末と通信可能な複数の第２のアクセスポイントと、第２の認証方式に従って前記移動端末の認証を実行する第２の認証サーバを有する第２のドメインとを備えた通信システムであって、前記移動端末が前記第１のアクセスポイントから前記第２のアクセスポイントに対してハンドオーバした場合に、前記第１の認証サーバは、前記第２の認証方式よりも速く認証処理可能な高速認証方式のために必要な認証セッション情報を前記第２の認証サーバに対して送信し、前記第２の認証サーバは、前記第１の認証サーバより前記認証セッション情報を受信し、当該認証セッション情報を用いて前記移動端末と高速認証を実行するものである。

上述の通信システムにおいて、前記第２の認証方式は電子証明書を用いた認証方式であり、前記高速認証方式は共通鍵を用いた認証方式であってもよい。

上述の通信システムにおいて、前記第１の認証サーバは、前記認証セッション情報の制御を行う第１の認証セッション制御部と、前記第１の認証方式に従った認証を実行する第１の認証処理部と、他のドメインの認証方式を管理する第１のポリシー管理部と、ドメイン毎の認証方式情報が格納された第１のドメインデータベースとを備え、前記第２の認証サーバは、前記認証セッション情報の制御を行う第２の認証セッション制御部と、前記第２の認証方式に従った認証を実行する第２の認証処理部と、他のドメインの認証方式を管理する第２のポリシー管理部と、ドメイン毎の認証方式情報が格納された第２のドメインデータベースとを備えていてもよい。

上述の通信システムにおいて、前記第１又は第２のポリシー管理部は、他のドメインより認証方式情報及び／又はドメイン認証ポリシーを取得し、前記第１又は第２のドメインデータベースに格納するものであってもよい。

上述の通信システムにおいて、前記第１の認証セッション制御部は、前記第１のポリシー管理部による転送指令に応じて前記第２の認証サーバに対して認証セッション情報を送信するものであってもよい。

上述の通信システムにおいて、前記第１の認証セッション制御部は、前記第２の認証サーバから認証セッション情報の要求に応じて当該第２の認証サーバに対して認証セッション情報を送信するものであってもよい。

上述の通信システムにおいて、前記第１の認証セッション制御部は、第２の認証サーバに送信する認証セッション情報を、前記第１のドメインデータベースに格納された前記第２の認証サーバの認証方式情報に基づいて決定するものであってもよい。

また、本発明にかかる通信システムは、移動端末と、前記移動端末と通信可能な複数の第１のアクセスポイントと、第１の認証方式に従って前記移動端末の認証を実行する第１の認証サーバを有する第１のドメインと、前記移動端末と通信可能な複数の第２のアクセスポイントと、第２の認証方式に従って前記移動端末の認証を実行する第２の認証サーバを有する第２のドメインとを備えた通信システムであって、前記移動端末が前記第１のアクセスポイントから前記第２のアクセスポイントに対してハンドオーバした場合に、前記第１の認証サーバは、前記第２の認証方式よりも速く認証処理可能な高速認証方式のために必要な認証セッション情報を前記第２の認証サーバに対して送信し、前記第２の認証サーバは、前記第１の認証サーバより前記認証セッション情報を受信し、前記移動端末と前記第２の認証サーバは、当該認証セッション情報を用いて高速認証を実行するものである。

上述の通信システムにおいて、前記移動端末は、ハンドオーバに応じて有効な認証セッションがある場合には、移動先の第２のアクセスポイントを介して前記第２の認証サーバに対して認証セッションの識別情報を送信し、前記第２の認証サーバは、当該認証セッションの識別情報に基づいて、認証セッション情報を検索するものであってもよい。

また、本発明にかかる通信方法は、移動端末との間で所定の認証方式により認証を実行する複数のドメイン間でハンドオーバが行なわれる場合の通信方法であって、移動元のドメインから移動先のドメインに対して当該移動元のドメインにおいて用いた認証セッション情報を送信するステップと、前記移動先のドメインは当該認証セッション情報を受信して、この認証セッション情報を用いて、高速認証方式により前記移動端末と認証を行なうステップとを備えたものである。

上述の通信方法において、移動先のドメインにおいて当該ドメインに最初にアクセスした際に用いられる認証方式は電子証明書を用いた認証方式であり、前記高速認証方式は共通鍵を用いた認証方式であってもよい。

上述の通信方法において、ハンドオーバが行なわれる場合に、前記移動元のドメインから前記移動先のドメインに対して認証セッション情報を送信するものであってもよい。

上述の通信方法において、ハンドオーバが行なわれる場合に、前記移動先のドメインからの認証セッション情報の要求に応じて、前記移動元のドメインから前記移動先のドメインに対して認証セッション情報を送信するものであってもよい。

本発明によれば、ハンドオーバ時におけるアクセス認証の時間と処理負荷を削減できる通信システムを提供することができる。

まず、本発明の実施の形態にかかる通信システムについて説明する。本実施形態にかかる通信システムは、マルチドメイン環境下での高速ローミングを実現するものであり、特に、移動前後のドメインで使用される認証方式が変わっても、新たな認証にかかる処理時間と処理負荷を最小限にすることにより、高速な認証を可能とするものである。

図１は、本実施形態にかかる通信システムの構成を示している。図に示されるように、この通信システムは、移動端末（ＳＴＡ）４、ドメイン１０、ホームドメイン４０を備えている。移動端末４は、ドメイン１０と無線ＬＡＮにより通信可能であり、ドメイン１０とホームドメイン４０は、ＩＰバックボーンなどにより通信可能である。

例えば、ドメイン１０とホームドメイン４０は、インターネットなどにも通信可能に接続されており、移動端末４は、ドメイン１０にアクセスすることでインターネットなどと通信を行う。ドメイン１０は、移動端末４がインターネットなどにアクセスするためのネットワークであり、ドメイン名で識別される。

各ドメインは、同一の移動端末に対して、利用可能な認証方式が異なる場合がある。例えば、ドメイン１０ａとドメイン１０ｂとでは、移動端末４のアクセスを認証する認証方式が異なっている。一例として、ドメイン１０ａの認証方式は、ＥＡＰ−ＴＬＳであり、ドメイン１０ｂの認証方式は、ＥＡＰ−ＴＴＬＳである。ただし、ドメインは複数の認証方式をサポートする場合もある。尚、本発明は、ドメイン間で認証方式が同じ場合にも適用可能であり、本発明により高速認証を実現することができる。

各ドメイン１０は、認証サーバ１、ドメインＤＢ（データベース）２、複数のＡＰ（アクセスポイント）３を有しており、それぞれ通信可能に接続されている。認証サーバ１は、移動端末４のアクセス認証するための認証装置であり、ドメイン毎にサポートされた認証方式にしたがって認証処理を行う。ドメインＤＢ２は、ポリシーデータベースであり、セキュリティに関する情報、ドメイン認証ポリシー、認証方式などが格納されている。

図１では、ドメイン１０ａに、認証サーバＡ（１ａ）、ドメインＤＢ−Ａ（２ａ）、ＡＰ３ａが接続され、ドメイン１０ｂに、認証サーバＢ（１ｂ）、ドメインＤＢ−Ｂ（２ｂ）、ＡＰ３ｂが接続されている。認証サーバＡ（１ａ）と認証サーバＢ（１ｂ）は、セキュア通信路２０により接続されている。セキュア通信路２０は、後述する認証セッション情報を転送するために、信頼できるセキュアな通信路であり、例えば、ＩＰｓｅｃ（ＩＰ Ｓｅｃｕｒｉｔｙ）やその他のトンネリング技術により接続されている。

移動端末４は、ノートＰＣやＰＤＡなど、ユーザが携帯して移動可能な情報処理装置である。ＡＰ３は、無線基地局であり、ＡＰ３から所定の範囲が通信エリア（カバーエリア）３０である。移動端末４は、通信エリア３０の範囲内において、ＡＰ３と無線通信が可能である。

ホームドメイン４０は、移動端末との契約を結んでいるネットワークである。ホームドメイン４０には、ホーム認証サーバ５が備えられている。ホーム認証サーバ５は、移動端末４のユーザ認証のための認証装置である。ホーム認証サーバ５は、ユーザ名とパスワードなどを記憶しており、認証サーバ１が移動端末４の認証を行う際に、認証サーバ１からの要求に応じてユーザ認証を行う。

次に、図２のプロック図を用いて、認証サーバ１とドメインＤＢ２の構成について説明する。図に示されるように、認証サーバ１は、認証セッション制御部１１、ポリシー管理部１２、認証処理部１３、ネットワークＩ／Ｆ１４を備えている。

ネットワークＩ／Ｆ１４は、物理ネットワークインタフェース及びそれにリンクされたデバイスドライバ、ダイアルアップ等のネットワーク制御機能、基本プロトコルスタック（ＴＣＰ／ＵＤＰ／ＩＰ等）を含んでいる。

認証処理部１３は、移動端末４と通信し、完全認証もしくは高速認証の認証処理を行う。この認証処理については後述する。

ポリシー管理部１２は、移動端末４の移動先ドメイン１０の認証方式を、ドメイン間での交渉（ネゴシエーション）、またはドメインＤＢ２への問い合わせによって把握する。また、ポリシー管理部１２は、移動端末４の移動前後に使用される認証方式に基づき、転送すべき認証セッション情報を確定し、認証セッション制御部１１に対し転送指令を出力する。例えば、ポリシー管理部１２は、他のドメインより取得した認証方式やドメイン認証ポリシーをドメインＤＢ２へ格納し、格納した情報に基づいて、転送する認証セッション情報を決定してもよい。

認証セッション制御部１１は、認証セッション情報の制御を行う。認証セッション情報は、ハンドオーバ時に認証手順を簡略化できるようにするための情報であり、例えば、セッション識別子、暗号方式、暗号キーなどを含んでいる。その他、認証セッション情報には、セキュリティに関する情報として認証セッション情報の有効期限やタイマ値などが含まれていてもよい。認証セッション情報の有効期限をハンドオーバ時に引きつぐことにより、セキュリティ性を向上できる。認証セッション制御部１１は、ポリシー管理部１２により転送すべき認証セッション情報の転送指令を受け取り、移動端末の移動先ドメインの認証サーバへ転送する。

ドメインＤＢ２は、認証サーバのポリシー管理部と連携して動作し、認証方式テーブル２１とドメインポリシーテーブル２２を備えている。認証方式テーブル２１には、ドメイン毎の認証方式が記憶されている。ドメインポリシーテーブル２２には、ドメイン毎のドメイン認証ポリシーが記憶されている。例えば、ドメイン認証ポリシーは、認証方式以外のセキュリティに関する情報などが格納されている。

次に、図３を用いて、本実施形態にかかる通信システムにおける認証方法の概要について説明する。まず、移動端末４がドメイン１０ａにおいて通信を行う場合、ＡＰ３ａを介して、移動端末４と認証サーバＡ（１ａ）との間で完全認証が行われる（Ｓ１０１）。完全認証（Ｆｕｌｌ Ａｕｔｈ）は、ＥＡＰ−ＴＬＳやＥＡＰ−ＴＴＬＳなどの認証方式（認証プロトコル）に定義されている認証処理手順の全てにより認証を行う。

この完全認証が成功すると、移動端末４と認証サーバＡ（１ａ）との間に認証セッションが確立される。この際、認証サーバＡ（１ａ）は、所定の手段を用いて（例えば、移動端末４の位置情報など）、次のドメイン１０ｂへ、移動端末４が移動することを予測する（Ｓ１０２）。

そうすると、認証サーバＡ（１ａ）は、移動先のドメインで高速認証を行うために必要な処理（高速認証制御）を行う。まず、認証サーバＡ（１ａ）は、ドメインＤＢ−Ａ（２ａ）に問い合わせを行い、移動元と移動先それぞれのドメインで使用される認証方式に基づき、転送すべき認証セッション情報を決定する（Ｓ１０３）。次に、認証サーバＡ（１ａ）は、認証サーバ間のセキュア通信路２０を介して、認証サーバＡ（１ａ）から移動先ドメインの認証サーバＢ（１ｂ）へ認証セッション情報を転送する（Ｓ１０４）。

次に、移動端末４が、ドメイン１０ｂに移動すると、ＡＰ３ｂを介して、移動端末４と認証サーバＢ（１ｂ）との間で高速認証が行われる（Ｓ１０５）。高速認証（Ｆａｓｔ Ａｕｔｈ）は、認証サーバＢ（１ｂ）が受け取った認証セッション情報に基づき、完全認証の手順を省略し、簡易かつ高速な処理に置き換えた認証処理手順により認証を行う。

次に、図４のフローチャートを用いて、本実施形態にかかる移動端末の認証処理について説明する。この処理は、図３のＳ１０１やＳ１０５のように、移動端末がドメイン１０との通信を開始する際の処理である。

まず、移動端末４は、初期状態で必要な初期設定を行い（Ｓ２０１）、ＡＰ３との通信を待つ待機状態となる（Ｓ２０２）。次いで、移動端末４は、ＡＰ３から受信する電波強度などにより、ＡＰ３の通信エリア３０に移動したことを検出する（Ｓ２０３）。

次いで、移動端末４は、有効な認証セッション情報があるかどうか判定する（Ｓ２０４）。例えば、認証セッション情報には、時間的な期限が設定されており、この期限が切れていないかどうか判断する。

Ｓ２０４において、有効な認証セッション情報があると判定された場合、移動端末４は、認証サーバ１へ認証セッション識別子を送信する（Ｓ２０５）。認証セッション識別子は、認証サーバ１で認証セッション情報を特定するための情報であり、移動端末４は、認証セッションの識別子情報を含む認証要求を、新たな認証サーバ１へ送信する。

次いで、移動端末４は、認証サーバ１で一致する認証セッション情報があるかどうか判定する（Ｓ２０６）。例えば、移動端末４は、認証サーバ１から一致するセッション情報（移動前のドメインの認証サーバから得られるセッション情報）があるかどうかの判断結果を受信することにより、この判定を行う。

Ｓ２０６において、認証サーバ１で一致する認証セッション情報があると判定された場合、移動端末４は、この認証セッション情報に基づいて高速認証処理を行う（Ｓ２０７）。また、Ｓ２０４において、有効な認証セッションがないと判定された場合、もしくは、Ｓ２０６において、認証サーバ１で一致する認証セッション情報がないと判定された場合、移動端末４は、完全認証処理を行う（Ｓ２０８）。Ｓ２０７もしくはＳ２０８の後、移動端末４は、Ｓ２０２の待機状態となり、Ｓ２０２〜Ｓ３０８の処理を繰り返す。

次に、図５〜図９のフローチャートを用いて、本実施形態にかかる認証サーバの処理について説明する。ここでは、認証セッション制御部１１による認証セッション情報の転送処理と、認証処理部１３による認証処理について説明する。

認証セッション制御部１１では、２つの転送モードにより認証セッション情報を転送できる。転送モードには、予め必要な認証セッション情報を移動元ドメインが移動先ドメインへ転送するプロアクティブモードと、移動元ドメインに必要な認証セッション情報を要求し、移動先ドメインが移動元ドメインから認証セッション情報を取得するリアクティブモードがある。認証セッション制御部１１は、いずれか一方のモードにより転送を行ってもよいし、両方のモードにより転送を行ってもよい。

図５は、プロアクティブモードにおける、移動元ドメイン１０の認証セッション制御部１１の転送処理を示している。移動元ドメイン１０では、認証セッション制御部１１は、初期状態で必要な初期設定を行い（Ｓ３０１）、他の認証サーバ１との通信を待つ待機状態となる（Ｓ３０２）。

次いで、認証セッション制御部１１は、ポリシー管理部１２から転送すべき認証セッション情報の転送指令を受信する（Ｓ３０３）。例えば、移動端末４の移動先のドメイン１０が検出されると、認証セッション制御部１１は、ポリシー管理部１２から移動端末４の移動前後で使用される認証方式に基づく、転送すべき旧認証セッション情報及び転送先認証サーバの情報の転送指令を受け取る。

次いで、認証セッション制御部１１は、移動先ドメインの認証サーバ１へ認証セッション情報を送信する（Ｓ３０４）。その後、認証セッション制御部１１は、Ｓ３０２の待機状態となり、Ｓ３０２〜Ｓ３０４の処理を繰り返す。

図６は、プロアクティブモードにおける、移動先ドメイン１０の認証セッション制御部１１の転送処理を示している。移動先ドメイン１０では、認証セッション制御部１１は、初期状態で必要な初期設定を行い（Ｓ４０１）、他の認証サーバ１との通信を待つ待機状態となる（Ｓ４０２）。

次いで、認証セッション制御部１１は、移動元ドメインの認証サーバより認証セッション情報を受信し更新する（Ｓ４０３）。例えば、認証セッション制御部１１は、受信した認証セッション情報を、認証サーバ１内などに設けられた記憶装置に格納する。

次いで、認証セッション制御部１１は、認証処理部１３からの問い合わせを受信する（Ｓ４０４）。例えば、移動端末４が移動すると、認証処理部１３の認証処理が開始されて、認証処理部１３から認証セッション制御部１１へ問い合わせが行われる。

次いで、認証セッション制御部１１は、一致する認証セッション情報があるかどうか判定する（Ｓ４０５）。すなわち、認証セッション制御部１１は、認証処理部１３からの問い合わせを受信すると、認証セッション識別子（例えば、Ｓｅｓｓｉｏｎ−ＩＤ）をキーワードとして、一致する認証セッション情報を保持しているかどうか検索する。

Ｓ４０５において、一致する認証セッション情報があると判定された場合、認証セッション制御部１１は、認証セッション情報を認証処理部１３に通知する（Ｓ４０６）。また、Ｓ４０６において、一致する認証セッション情報がないと判定された場合、認証セッション制御部１１は、検索失敗結果を認証処理部１３に通知する（Ｓ４０７）。このとき、認証処理部１３では、認証セッション制御部１１からの通知に基づいて認証処理を行う。

Ｓ４０６もしくはＳ４０７の後、認証セッション制御部１１は、Ｓ４０２の待機状態となり、Ｓ４０２〜Ｓ４０７の処理を繰り返す。

図７は、リアクティブモードにおける、移動元ドメイン１０の認証セッション制御部１１の処理を示している。移動元ドメイン１０では、認証セッション制御部１１は、初期状態で必要な初期設定を行い（Ｓ５０１）、他の認証サーバ１との通信を待つ待機状態となる（Ｓ５０２）。

認証セッション制御部１１は、移動先ドメイン１０の認証サーバ１から認証セッション情報の転送要求を受信する（Ｓ５０３）。次いで、認証セッション制御部１１は、Ｓ５０３で要求された認証セッション情報があるか（保持されているか）どうか判定する（Ｓ５０４）。

Ｓ５０４において、認証セッション情報があると判定された場合、認証セッション制御部１１は、認証セッション情報を移動先ドメイン１０の認証サーバ１へ送信する（Ｓ５０５）。また、Ｓ５０４において、認証セッション情報がないと判定された場合、認証セッション制御部１１は、検索失敗結果を移動先ドメイン１０の認証サーバ１へ送信する（Ｓ５０６）。例えば、認証セッション制御部１１は、認証セッション情報なしや、認証セッションの有効期限切れ、ドメイン認証ポリシー違反等の原因で検索失敗したことを通知する。

Ｓ５０５もしくはＳ５０６の後、認証セッション制御部１１は、Ｓ５０２の待機状態となり、Ｓ５０２〜Ｓ５０６の処理を繰り返す。

図８は、リアクティブモードにおける、移動先ドメイン１０の認証セッション制御部１１の処理を示している。移動先ドメイン１０では、認証セッション制御部１１は、初期状態で必要な初期設定を行い（Ｓ６０１）、他の認証サーバ１との通信を待つ待機状態となる（Ｓ６０２）。

次いで、認証セッション制御部１１は、認証処理部１３からの問い合わせを受信する（Ｓ６０３）。例えば、移動端末４が移動すると、認証処理部１３の認証処理が開始されて、認証処理部１３から認証セッション制御部１１へ問い合わせが行われる。

次いで、認証セッション制御部１１は、一致する認証セッション情報があるかどうか判定する（Ｓ６０４）。すなわち、認証セッション制御部１１は、認証処理部１３からの問い合わせを受信すると、認証セッション識別子をキーワードとして、一致する認証セッション情報を保持しているかどうか検索する。

Ｓ６０４において、一致する認証セッション情報があると判定された場合、認証セッション制御部１１は、認証セッション情報を認証処理部１３に通知する（Ｓ６０５）。また、Ｓ６０４において、一致する認証セッション情報がないと判定された場合、認証セッション制御部１１は、移動元ドメイン１０の認証サーバ１へ認証セッション情報の問い合わせを行う（Ｓ６０６）。例えば、認証セッション制御部１１は、ポリシー管理部１２より移動元ドメイン１０の情報及び転送されるべき認証セッション情報を把握でき、把握した移動元ドメイン１０の認証サーバ１へ認証セッション情報の転送要求を送信する。

Ｓ６０６の後、認証セッション制御部１１は、認証セッション情報を受信したか、つまり、移動元ドメイン１０から認証セッション情報が転送されたかどうか判定する（Ｓ６０７）。Ｓ６０７において、認証セッション情報を受信したと判定された場合、認証セッション制御部１１は、認証セッション情報を認証処理部１３に通知する（Ｓ６０５）。

また、Ｓ６０５において、認証セッション情報を受信していないと判定された場合、認証セッション制御部１１は、検索失敗結果を認証処理部１３に通知に通知する（Ｓ６０８）。このとき、認証処理部１３では、認証セッション制御部１１からの通知に基づいて認証処理を行う。Ｓ６０５もしくはＳ６０８の後、認証セッション制御部１１は、Ｓ６０２の待機状態となり、Ｓ６０２〜Ｓ６０８の処理を繰り返す。

図９は、移動端末４がドメイン１０との通信を開始する際における、認証処理部１３の認証処理を示している。まず、認証処理部１３は、初期状態で必要な初期設定を行い（Ｓ７０１）、移動端末４からの認証要求を待つ待機状態となる（Ｓ７０２）。

次いで、認証処理部１３は、移動端末４（ユーザ）からの認証要求を受信する（Ｓ７０３）。次いで、認証処理部１３は、受信した認証要求に認証セッション識別子があるかどうか判定する（Ｓ７０４）。

Ｓ７０４において、認証セッション識別子があると判定された場合、認証処理部１３は、認証セッション制御部１１に問い合わせる（Ｓ７０５）。すなわち、認証処理部１３は、移動端末４からの認証要求に含まれている認証セッション識別子を用いて、一致する認証セッション情報があるかどうか認証セッション制御部１１に問い合わせる。

次いで、認証処理部１３は、認証セッション制御部１１からの応答を受け取り、一致する認証セッション情報があるかどうか判定する（Ｓ７０６）。

Ｓ７０６において、一致する認証セッション情報があると判定された場合、認証処理部１３は、認証セッション情報を取得する（Ｓ７０７）。すなわち、認証処理部１３は、認証セッション制御部１１から、移動端末４の移動元ドメイン１０における旧認証セッション情報を取得する。Ｓ７０７の後、認証処理部１３は、この認証セッション情報に基づいて高速認証処理を行う（Ｓ７０８）。

また、Ｓ７０４において、認証セッション識別子がないと判定された場合、もしくは、Ｓ７０６において、一致する認証セッション情報がないと判定された場合、認証処理部１３は、完全認証処理を行う（Ｓ７１０）。

Ｓ７０８、もしくは、Ｓ７１０の後、認証処理部１３は、認証が成功したがどうか判定する（Ｓ７０９）。Ｓ７０９において、認証が成功したと判定された場合、認証処理部１３は、認証セッション制御部１１に対して、認証セッション情報の更新を要求する（Ｓ７１１）。すなわち、新たなドメインで認証が成功すると、認証セッション制御部１１では、保持している情報を新たな認証セッション情報に更新する。Ｓ７０９において、認証が失敗したと判定された場合、もしくは、Ｓ７１１の後、認証処理部１３は、Ｓ７０２の待機状態となり、Ｓ７０２〜Ｓ７１１の処理を繰り返す。

次に、本実施形態にかかる通信システムにおいて、ハンドオーバ時に行われる認証方法について説明する。図１０は、ＥＡＰ−ＴＬＳの認証方式のドメイン１０ａからＥＡＰ−ＴＴＬＳの認証方式のドメイン１０ｂへ、移動端末４が移動した場合の認証方法を示すシーケンスである。

まず、認証サーバＡ（１ａ）は、所定の手段により、移動端末４がドメイン１０ｂへ移動することを予測する（Ｓ８０１）。次いで、認証サーバＡは、移動先ドメイン１０ｂで使用される認証方式がＥＡＰ−ＴＴＬＳであることを把握する（Ｓ８０２）。

次いで、認証サーバＡは、移動先ドメイン１０ｂの認証サーバＢ（１ｂ）へＥＡＰ−ＴＬＳ用の認証セッション情報を転送する（Ｓ８０３）。このＥＡＰ−ＴＬＳ用の認証セッション情報には、移動端末４のＮＡＩ（Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ ＩＤ）、Ｓｅｓｓｉｏｎ−ＩＤ（セッション識別子）、Ｃｉｐｈｅｒ−Ｓｐｅｃ（暗号方式）、Ｃｉｐｈｅｒ−Ｋｅｙ（暗号キー）が含まれている。尚、この認証セッション情報は、セキュア通信路２０により保護されている。

次いで、移動端末４がドメイン１０ｂへ移動すると、移動端末４は、アクセスポイントＢ（ＡＰ３ｂ）の圏内（通信エリア内）に移動したことを検出する（Ｓ８０４）。

次いで、移動端末４とアクセスポイントＢとの通信が開始される（Ｓ８０５）。Ｓ８０５では、移動端末４とアクセスポイントＢとの間で、アソシエーション要求／応答パケットが送受信されてアソシエーションが行われ、さらにＥＡＰ Ｓｔａｒｔ（認証開始要求）パケット、ＥＡＰ ＩＤ Ｒｅｑｕｅｓｔ（ＥＡＰ−ＩＤ問い合わせ要求）パケット、ＮＡＩを含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットが送受信された後、認証サーバＢから、ＥＡＰ−ＴＴＬＳ ｓｔａｒｔを含むＥＡＰ Ｒｅｑｕｅｓｔパケットが移動端末４へ送信される。

次いで、移動端末４は、有効な旧認証セッション情報（移動前から使用している認証セッション情報）があることを確認し（Ｓ８０６）、旧Ｓｅｓｓｉｏｎ−ＩＤとＣｈａｌｌｅｎｇｅ値、Ｃｉｐｈｅｒ−Ｓｐｅｃを含むｃｌｉｅｎｔ ｈｅｌｌｏパケットを認証サーバＢへ送信する（Ｓ８０７）。

次いで、認証サーバＢは、高速認証処理を起動する（Ｓ８０８）。認証サーバＢは、ＥＡＰ−ＴＴＬＳで規定されている電子証明書方式を、Ｃｈａｌｌｅｎｇｅ／Ｒｅｓｐｏｎｓｅ方式（共通鍵認証方式）に置き換えて処理を行う。すなわち、認証サーバＢは、Ｓ８０３で受信している旧認証セッション情報を用いてＲｅｓｐｏｎｓｅ値を計算する。

次いで、認証サーバＢは、Ｓｅｓｓｉｏｎ−ＩＤとＲｅｓｐｏｎｓｅ値を含むｓｅｒｖｅｒ ｈｅｌｌｏパケットを移動端末４へ送信する（Ｓ８０９）。このとき、移動端末４では、Ｒｅｓｐｏｎｓｅ値の比較によりサーバの認証が行われる。次いで、サーバ認証が成功すると、移動端末４と認証サーバＢとの間で、ＴＬＳトンネルを介して、ＣＨＡＰ等によりユーザ認証が行われる（Ｓ８１０）。

図１１は、図１０の認証処理の詳細を示しており、従来例の図１４に対応したシーケンスである。まず、フェーズ１において、Ｉｄｅｎｔｉｔｙを含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットが移動端末４から認証サーバ１へ送信され、ＴＴＬＳ ｓｔａｒｔを含むＥＡＰ Ｒｅｑｕｅｓｔパケットが認証サーバ１から移動端末４へ送信された後、移動端末４は、Ｃｈａｌｌｅｎｇｅ値の生成を行う（Ｓ９０１）。例えば、移動端末４は、乱数によりＣｈａｌｌｅｎｇｅ値を生成する。そして、移動端末４は、Ｓｅｓｓｉｏｎ−ＩＤとＣｉｐｈｅｒ−Ｓｐｅｃ、生成したＣｈａｌｌｅｎｇｅ値（ＳＱ１０１）を含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットを認証サーバ１へ送信する。送信されるＳｅｓｓｉｏｎ−ＩＤとＣｉｐｈｅｒ−Ｓｐｅｃは、移動前のドメインで使用していたものである。

次いで、認証サーバ１は、受信したＣｈａｌｌｅｎｇｅ値に対してＲｅｓｐｏｎｓｅ値の計算を行う（Ｓ９０２）。例えば、認証サーバ１は、受信したＳｅｓｓｉｏｎ−ＩＤから認証セッション情報を検索し、該当する暗号方式と暗号キーによりＣｈａｌｌｅｎｇｅ値に基づき、Ｒｅｓｐｏｎｓｅ値を計算する。そして、認証サーバ１は、Ｓｅｓｓｉｏｎ−ＩＤ、計算したＲｅｓｐｏｎｓｅ値（ＳＱ１０２）を含むＥＡＰ Ｒｅｑｕｅｓｔパケットを移動端末４へ送信する。

次いで、移動端末４は、受信したＲｅｓｐｏｎｓｅ値と自分で計算した計算結果を比較することによりＳｅｒｖｅｒ認証を完了し（Ｓ９０３）、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ処理を行う。そして、移動端末４は、生成したｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃを含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットを認証サーバ１へ送信する。

次いで、認証サーバ１は、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ処理を行い、ｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃを含むＥＡＰ Ｒｅｑｕｅｓｔパケットを移動端末４へ送信する。

フェーズ１の認証が成功すると、フェーズ２において、移動端末４と認証サーバ１との間で、ＣＨＡＰ等によりユーザ認証が行われる。

図１１と図１４から示されるように、従来の処理Ｓ１３０１〜Ｓ１３０４をＳ９０１〜Ｓ９０３に置き換えることにより、認証サーバと移動端末での処理時間及び処理負荷を削減することができる。特に、Ｓ１３０３のＣｅｒｔ−Ｂａｓｅｄ Ｓｅｒｖｅｒ認証処理（電子証明書によるサーバ認証）とＰＫＩ−ｂａｓｅｄ暗号化処理（公開鍵暗号化処理）を、Ｓ９０３のＲｅｓｐｏｎｓｅ値計算処理へ置き換えることにより得られる効果は著しい。また、従来のシーケンスＳＱ３０１〜ＳＱ３０３を、ＳＱ１０１〜ＳＱ１０２に変更するため、認証サーバと移動端末との間でやり取りされる情報量が削減される。特に、ＳＱ３０２のＳｅｒｖｅｒ−Ｃｅｒｔの情報量が大きく、これが削減される効果は著しい。

尚、ＥＡＰ−ＴＬＳのドメインからＥＡＰ−ＴＴＬＳのドメインへのハンドオーバに限らず、逆に、ＥＡＰ−ＴＴＬＳのドメインからＥＡＰ−ＴＬＳのドメインへのハンドオーバの場合でも、同様に本発明を適用することができる。

例えば、ドメイン１０ａの認証方式をＥＡＰ−ＴＴＬＳ、ドメイン１０ｂの認証方式をＥＡＰ−ＴＬＳとして、ドメイン１０ａからドメイン１０ｂへ、移動端末４が移動した場合について説明する。ＥＡＰ−ＴＬＳは、ＥＡＰ−ＴＴＬＳと比べて、電子証明書の認証を双方で行う点が異なるが、その他については図１０や図１１と同様である。

図１２は、ＥＡＰ−ＴＬＳのドメイン１０ｂへ移動した場合の認証方法を示すシーケンスである。まず、認証サーバＡ（１ａ）は、移動端末４がドメイン１０ｂへ移動することを予測し（Ｓ１１０１）、移動先ドメイン１０ｂで使用される認証方式がＥＡＰ−ＴＬＳであることを把握する（Ｓ１１０２）。

次いで、認証サーバＡは、移動先ドメイン１０ｂの認証サーバＢ（１ｂ）へＥＡＰ−ＴＴＬＳ用の認証セッション情報を転送する（Ｓ１１０３）。このＥＡＰ−ＴＴＬＳ用の認証セッション情報は、ＥＡＰ−ＴＬＳ用の認証セッション情報と同様であり、移動端末４のＮＡＩ、Ｓｅｓｓｉｏｎ−ＩＤ、Ｃｉｐｈｅｒ−Ｓｐｅｃ、Ｃｉｐｈｅｒ−Ｋｅｙが含まれている。

次いで、移動端末４がドメイン１０ｂへ移動すると、移動端末４は、アクセスポイントＢ（ＡＰ３ｂ）の圏内（通信エリア内）に移動したことを検出する（Ｓ１１０４）。

次いで、Ｓ１１０５において、移動端末４とアクセスポイントＢとの間で、アソシエーションが行われ、ＥＡＰ Ｓｔａｒｔパケット、ＥＡＰ ＩＤ Ｒｅｑｕｅｓｔパケット、ＮＡＩを含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットが送受信された後、認証サーバＢから、ＥＡＰ−ＴＬＳ ｓｔａｒｔを含むＥＡＰ Ｒｅｑｕｅｓｔパケットが移動端末４へ送信される。

次いで、移動端末４は、有効な旧認証セッション情報があることを確認し（Ｓ１１０６）、旧Ｓｅｓｓｉｏｎ−ＩＤとＣｈａｌｌｅｎｇｅ値、Ｃｉｐｈｅｒ−Ｓｐｅｃを含むＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏパケットを認証サーバＢへ送信する（Ｓ１１０７）。

次いで、認証サーバＢは、高速認証処理を行う（Ｓ１１０８）。認証サーバＢは、ＥＡＰ−ＴＬＳで規定されている電子証明書方式を、Ｃｈａｌｌｅｎｇｅ／Ｒｅｓｐｏｎｓｅ方式に置き換えて認証を行う。すなわち、認証サーバＢは、Ｓ１１０３で受信している認証セッション情報を用いて、Ｒｅｓｐｏｎｓｅ値を計算する。

次いで、認証サーバＢは、Ｓｅｓｓｉｏｎ−ＩＤとＲｅｓｐｏｎｓｅ値を含むＴＬＳ ｓｅｒｖｅｒ ｈｅｌｌｏパケットを移動端末４へ送信する（Ｓ１１０９）。このとき、移動端末４では、Ｒｅｓｐｏｎｓｅ値の計算によりサーバの認証が行われる。次いで、サーバ認証が成功すると、移動端末４と認証サーバＢとの間で、電子証明書ベースでユーザ認証が行われる（Ｓ１１１０）。

図１３は、図１２の認証処理の詳細を示しており、従来例の図１５に対応したシーケンスである。まず、移動端末４と認証サーバ１との間で、Ｉｄｅｎｔｉｔｙを含むＥＡＰ Ｒｅｓｐｏｎｓｅパケット、ＴＬＳ ｓｔａｒｔを含むＥＡＰ Ｒｅｑｕｅｓｔパケットが送受信された後、移動端末４は、Ｃｈａｌｌｅｎｇｅ値の生成を行う（Ｓ１２０１）。そして、移動端末４は、Ｓｅｓｓｉｏｎ−ＩＤとＣｉｐｈｅｒ−Ｓｐｅｃ、生成したＣｈａｌｌｅｎｇｅ値（ＳＱ２０１）を含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットを認証サーバ１へ送信する。

次いで、認証サーバ１は、受信したＣｈａｌｌｅｎｇｅ値に対してＲｅｓｐｏｎｓｅ値の計算を行う（Ｓ１２０２）。そして、認証サーバ１は、Ｓｅｓｓｉｏｎ−ＩＤ、生成したＲｅｓｐｏｎｓｅ値（ＳＱ２０２）を含むＥＡＰ Ｒｅｑｕｅｓｔパケットを移動端末４へ送信する。

次いで、移動端末４は、受信したＲｅｓｐｏｎｓｅ値を計算して比較することによりＳｅｒｖｅｒ認証を完了し（Ｓ１２０３）、Ｃｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ処理を行う。そして、移動端末４は、Ｃｌｉｅｎｔ−Ｃｅｒｔと生成したｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃを含むＥＡＰ Ｒｅｓｐｏｎｓｅパケットを認証サーバ１へ送信する。

次いで、認証サーバ１は、Ｃｅｒｔ−ｂａｓｅｄ Ｃｌｉｅｎｔ認証とＣｈａｎｇｅ Ｃｉｐｈｅｒ Ｓｐｅｃ処理を行い、ｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃを含むＥＡＰ Ｒｅｑｕｅｓｔパケットを移動端末４へ送信する。

図１３と図１５から示されるように、ＥＡＰ−ＴＴＬＳのドメインへ移動した場合と同様、従来の処理Ｓ１４０１〜Ｓ１４０４をＳ１２０１〜Ｓ１２０３に置き換えることにより、認証サーバと移動端末での処理時間及び処理負荷を削減することができる。また、従来のシーケンスＳＱ４０１〜ＳＱ４０３を、ＳＱ２０１〜ＳＱ２０２に変更するため、認証サーバと移動端末との間でやり取りされる情報量が削減される。

以上説明したように、本実施形態では、異なるドメイン間を移動端末が移動する際に、移動前のドメインにおいて成功した認証に関する認証セッション情報を、移動後のドメインに転送することにより、移動後のドメインにおける認証を、簡易かつ高速に実現することができる。

移動前のドメインにおいて確立された信頼関係に基づき、移動後のドメインにおける認証の信頼性とセキュリティ強度を損なわずに、認証方式を電子証明書方式から共有鍵方式に置き換えることにより、処理負荷を軽減することができる。

移動前のドメインで認証された認証セッション識別子に基づくことで、移動後のドメインの認証サーバが、移動端末と共有している認証セッション情報を特定可能なため、認証に必要なシグナリング数（転送する情報量）を少なくすることができ、無線空間におけるトラフィック削減が可能となる。

ドメインＤＢ（ポリシーデータベース）に基づくネゴシエーションすることにより、移動前後のドメインでの認証方式が異なる場合であっても、移動前後の認証方式に応じて、移動先に転送すべき情報を柔軟に選択可能となり、転送する情報量を最小限に抑えることが可能となる。

認証時間の短縮効果について検証を行った。検証の結果、従来のＥＡＰ−ＴＴＬＳ方式に比べて、ユーザ認証においてtunneled CHAPとtunneled MD5-Challengeのいずれの場合も顕著な効果が見られた。移動端末と認証サーバの間で認証を開始してから終了までの時間を所要時間としたとき、｛（従来方式の所要時間）−（発明方式の所要時間）｝／（従来方式の所要時間）×１００（％）で表される短縮効率比は、tunneled CHAPの場合は８９％、tunneled MD5-Challengeの場合は８６．１％であった。

尚、本発明は上記の実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲で種々の変形、実施が可能である。例えば、認証方式は、ＥＡＰ−ＴＬＳ、ＥＡＰ−ＴＴＬＳに限らず、ＥＡＰ−ＭＤ５やその他の認証方式であってもよい。また、移動端末とネットワーク間の通信方式は、無線ＬＡＮに限らず、携帯移動通信システムなどのその他の無線通信でもよいし、有線通信であってもよい。

本発明にかかる通信システムの構成図である。 本発明にかかる認証サーバの構成を示すブロック図である。 本発明にかかる通信システムの認証方法を説明するための図である。 本発明にかかる移動端末による認証処理を示すフローチャートである。 本発明にかかる認証サーバによる転送処理を示すフローチャートである。 本発明にかかる認証サーバによる転送処理を示すフローチャートである。 本発明にかかる認証サーバによる転送処理を示すフローチャートである。 本発明にかかる認証サーバによる転送処理を示すフローチャートである。 本発明にかかる認証サーバによる認証処理を示すフローチャートである。 本発明にかかる通信システムによる認証方法を示すシーケンスである。 本発明にかかる認証方法を示すシーケンスである。 本発明にかかる通信システムによる認証方法を示すシーケンスである。 本発明にかかる認証方法を示すシーケンスである。 従来の認証方法を示すシーケンスである。 従来の認証方法を示すシーケンスである。

符号の説明

１ 認証サーバ
１０ ドメイン
１１ 認証セッション制御部
１２ ポリシー管理部
１３ 認証処理部
１４ ネットワークＩ／Ｆ
２ ドメインＤＢ
２１ 認証方式テーブル
２２ ドメインポリシーテーブル
３ ＡＰ
４ 移動端末
５ ホーム認証サーバ
２０ セキュア通信路
３０ 通信エリア
４０ ホームドメイン

Claims (13)

1. 移動端末と通信可能な複数の第１のアクセスポイントと、第１の認証方式に従って前記移動端末の認証を実行する第１の認証サーバを有する第１のドメインと、
   移動端末と通信可能な複数の第２のアクセスポイントと、第２の認証方式に従って前記移動端末の認証を実行する第２の認証サーバを有する第２のドメインとを備えた通信システムであって、
   前記移動端末が前記第１のアクセスポイントから前記第２のアクセスポイントに対してハンドオーバする場合に、
   前記第１の認証サーバは、前記移動端末が移動する前記第２の認証サーバの第２の認証方式を判別し、当該判別した第２の認証方式よりも速い認証処理が可能な高速認証方式に利用可能な情報を含む認証セッション情報を前記第２の認証サーバに対して送信し、
   前記第２の認証サーバは、前記第１の認証サーバより前記認証セッション情報を受信し、当該受信した認証セッション情報内の前記利用可能な情報を用いて前記移動端末の認証を実行する通信システム。
2. 前記第２の認証方式は電子証明書を用いた認証方式であり、前記高速認証方式は共通鍵を用いた認証方式であり、前記認証セッション情報は共通鍵の情報を含むことを特徴とする請求項１記載の通信システム。
3. 前記第１の認証サーバは、
   前記認証セッション情報の制御を行う第１の認証セッション制御部と、
   前記第１の認証方式に従った認証を実行する第１の認証処理部と、
   他のドメインの認証方式を管理する第１のポリシー管理部と、
   ドメイン毎の認証方式情報が格納された第１のドメインデータベースとを備え、
   前記第２の認証サーバは、
   前記認証セッション情報の制御を行う第２の認証セッション制御部と、
   前記第２の認証方式に従った認証を実行する第２の認証処理部と、
   他のドメインの認証方式を管理する第２のポリシー管理部と、
   ドメイン毎の認証方式情報が格納された第２のドメインデータベースとを備えたことを特徴とする請求項１記載の通信システム。
4. 前記第１又は第２のポリシー管理部は、他のドメインより認証方式情報及び／又はドメイン認証ポリシーを取得し、前記第１又は第２のドメインデータベースに格納することを特徴とする請求項３記載の通信システム。
5. 前記第１の認証セッション制御部は、前記第１のポリシー管理部による転送指令に応じて前記第２の認証サーバに対して認証セッション情報を送信することを特徴とする請求項３記載の通信システム。
6. 前記第１の認証セッション制御部は、前記第２の認証サーバから認証セッション情報の要求に応じて当該第２の認証サーバに対して認証セッション情報を送信することを特徴とする請求項３記載の通信システム。
7. 前記第１の認証セッション制御部は、第２の認証サーバに送信する認証セッション情報を、前記第１のドメインデータベースに格納された前記第２の認証サーバの認証方式情報に基づいて決定することを特徴とする請求項５又は６記載の通信システム
8. 移動端末と、
   前記移動端末と通信可能な複数の第１のアクセスポイントと、第１の認証方式に従って前記移動端末の認証を実行する第１の認証サーバを有する第１のドメインと、
   前記移動端末と通信可能な複数の第２のアクセスポイントと、第２の認証方式に従って前記移動端末の認証を実行する第２の認証サーバを有する第２のドメインとを備えた通信システムであって、
   前記移動端末が前記第１のアクセスポイントから前記第２のアクセスポイントに対してハンドオーバする場合に、
   前記第１の認証サーバは、前記移動端末が移動する前記第２の認証サーバの第２の認証方式を判別し、当該判別した第２の認証方式よりも速い認証処理が可能な高速認証方式に利用可能な情報を含む認証セッション情報を前記第２の認証サーバに対して送信し、
   前記第２の認証サーバは、前記第１の認証サーバより前記認証セッション情報を受信し、
   前記移動端末と前記第２の認証サーバは、当該認証セッション情報内の前記利用可能な情報を用いて認証を実行する通信システム。
9. 前記移動端末は、ハンドオーバに応じて有効な認証セッションがある場合には、移動先の第２のアクセスポイントを介して前記第２の認証サーバに対して認証セッションの識別情報を送信し、
   前記第２の認証サーバは、当該認証セッションの識別情報に基づいて、認証セッション情報を検索することを特徴とする請求項８記載の通信システム。
10. 移動端末との間で所定の認証方式により認証を実行する複数のドメイン間でハンドオーバが行なわれる場合の通信方法であって、
    移動元のドメインが前記移動端末が移動する移動先のドメインの認証方式を判別するステップと、
    移動元のドメインが移動先のドメインに対して当該移動元のドメインにおいて用いた情報であり且つ移動先のドメインの認証において前記判別した認証方式よりも速い認証処理が可能な高速認証方式に利用可能な情報を含む認証セッション情報を送信するステップと、
    前記移動先のドメインが前記認証セッション情報を受信し、前記受診した認証セッション情報内の前記利用可能な情報を用いて前記移動端末と認証を行なうステップとを備えた通信方法。
11. 移動先のドメインにおいて当該ドメインに最初にアクセスした際に用いられる認証方式は電子証明書を用いた認証方式であり、前記高速認証方式は共通鍵を用いた認証方式であることを特徴とする請求項１０記載の通信方法。
12. ハンドオーバが行なわれる場合に、前記移動元のドメインから前記移動先のドメインに対して共通鍵の情報を含む認証セッション情報を送信することを特徴とする請求項１０記載の通信方法。
13. ハンドオーバが行なわれる場合に、前記移動先のドメインからの認証セッション情報の要求に応じて、前記移動元のドメインから前記移動先のドメインに対して認証セッション情報を送信することを特徴とする請求項１０記載の通信方法。

Images