(57)【要約】【課題】始動者と応答者との間で拡張認証を行う場合、その都度Radiusサーバに認証問い合わせをしなくてもよい認証方法を提供する。【解決手段】始動者から送信される認証パケットを応答者が受信する受信ステップと、応答者から認証サーバに認証問い合わせを行う認証問い合わせステップと、認証問い合わせが成功したか否かを判定する認証判定ステップと、認証問い合わせが成功した場合に、ネゴシエーションを続行する認証続行ステップとを備えた通信制御方法であって、始動者から応答者に複数回ネゴシエーションを行った場合に、始動者が応答者に接続を開始した最初のネゴシエーションであるか否かを判断する認証判断ステップを備える。【選択図】図７
2006086618.tif 000002
【特許請求の範囲】
【請求項１】
始動者から送信される認証パケットを応答者が受信する受信ステップと、前記応答者から認証サーバに認証問い合わせを行う認証問い合わせステップと、前記認証問い合わせが成功したか否かを判定する認証判定ステップと、前記認証問い合わせが成功した場合に、ネゴシエーションを続行する認証続行ステップとを備えた通信制御方法であって、前記始動者から前記応答者に複数回ネゴシエーションを行った場合に、前記始動者が前記応答者に接続を開始した最初のネゴシエーションであるか否かを判断する認証判断ステップを備えたことを特徴とする通信制御方法。
【請求項２】
前記認証判断ステップが、最初のネゴシエーションであると判断した場合に、２回目以降のネゴシエーションは前記始動者から送信される前記認証パケットの認証情報と前記応答者が有する認証情報とを比較し、比較した結果一致した場合に、認証成功であると判断することを特徴とする、請求項１に記載の通信制御方法。
【請求項３】
前記認証情報は、ユーザネーム、IPアドレス及びパスワードであることを特徴とする、請求項２に記載の通信制御方法。
【請求項４】
始動者から送信される認証パケットを応答者が受信する受信部と、前記応答者から認証サーバに認証問い合わせを行う認証問い合わせ部と、前記認証問い合わせが成功したか否かを判定する認証判定部と、前記認証問い合わせが成功した場合に、ネゴシエーションを続行する認証続行部とを備えた通信制御装置であって、前記始動者から前記応答者に複数回ネゴシエーションを行った場合に、前記始動者が前記応答者に接続を開始した最初のネゴシエーションであるか否かを判断する認証判断部を備えたことを特徴とする通信制御装置。
【請求項５】
前記認証判断部が、最初のネゴシエーションであると判断した場合に、２回目以降のネゴシエーションは前記始動者から送信される前記認証パケットの認証情報と前記応答者が有する認証情報とを比較し、比較した結果一致した場合に、認証成功であると判断することを特徴とする、請求項４に記載の通信制御装置。
【請求項６】
前記認証情報は、ユーザネーム、IPアドレス及びパスワードであることを特徴とする、請求項５に記載の通信制御装置。
【請求項７】
始動者から送信される認証パケットを応答者に受信させ、前記応答者から認証サーバに認証問い合わせを行わせ、前記認証問い合わせが成功したか否かを判定させ、前記認証問い合わせが成功した場合に、ネゴシエーションを続行させる通信制御装置をコンピュータにより制御する制御プログラムであって、前記始動者から前記応答者に複数回ネゴシエーションを行った場合に、前記始動者が前記応答者に接続を開始した最初のネゴシエーションであるか否かを判断させることを特徴とする制御プログラム。
【請求項８】
前記判断が、最初のネゴシエーションであると判断した場合に、２回目以降のネゴシエーションは前記始動者から送信される前記認証パケットの認証情報と前記応答者が有する認証情報とを比較し、比較した結果一致した場合に、認証成功であると判断させることを特徴とする、請求項７に記載の制御プログラム。
【請求項９】
前記認証情報は、ユーザネーム、IPアドレス及びパスワードであることを特徴とする、請求項８に記載の制御プログラム。
【請求項１０】
請求項７から請求項９のいずれか１項に記載の制御プログラムを記録したことを特徴とするコンピュータ読取可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、IPsec(Internet Protocol security architecture)通信における認証時のトラフィック軽減を行う通信制御方法、通信制御装置、制御プログラム、記録媒体に関するものである。
【背景技術】
【０００２】
近年、インターネットに代表されるネットワークの普及とともに、電子メールやファイルの送受信がさかんに行われるようになってきた。それに伴い、セキュリティに対する不安も多くなっている。
【０００３】
従来、インターネット等のネットワークにおいて利用されるセキュリティ機構としては、特許文献１、２が開示するように、RFC(Request For Comment)2401に規定されているIP(Internet Protocol)層でのセキュリティ機構であるIPsec、WEBで利用されるSSL(Secure Socket Layer)等がある。
【０００４】
これらのプロトコルでは、安全な通信を行う前に、通信者間で暗号通信に利用されるセッション鍵を共有する必要がある。その方法としては、RFC2409で規定されているIKE(Internet Key Exchange)、または、SSLに含まれるHandshake Protocol等がある。
【０００５】
IKEは、IPsecに必要な鍵を動的に確立する独立した機構であり、具体的にはRFC2407及びRFC2408に規定されている。鍵交換の枠組みを提供するISAKMP(Internet Security Association and Key Management Protocol)と、ISAKMP上で実際の鍵管理機構を定義しているOakleyとからなる。
【０００６】
IKEは、ISAKMPのためのISAKMP SA(ISAKMP Security Association)を確立するPhase1と、IPsecのSAを確立するPhase2とにより構成される。これらの２つのPhaseを総称してネゴシエーションという。ネゴシエーションは、例えば、スイッチやルータ等のGatewayとパソコン等の通信端末とがつながった際に、お互いがどの通信モードを利用できるかを確認することである。なお、SAとは、通信を保護するするために用いられる方針や鍵の集合のことである。Phase1には通信者のIDの保護が可能なメインモードと、IDの保護が不可能なアグレッシブモードの２つが存在し、Phase2にはクイックモードのみが存在する。
【０００７】
図１は、メインモードの認証方法を説明するための図である。
図１に示すように、メインモードは、initiator（以下、始動者という）とresponder（以下、応答者という）とを有する。また、ｔは経過時刻を表している。メインモードは、始動者と応答者との間で６回（３往復）の通信を行ってISAKMPを確立する。始めの２回（１往復）の通信において両者で使用するアルゴリズム等の取り決めが行われる。次の２回（１往復）の通信において鍵交換に必要なDiffie-Hellman鍵交換アルゴリズムの公開値や乱数等の補助的なデータの交換が行われる。そして、最後の２回（１往復）の通信で生成された鍵の認証が行われる。
【０００８】
図２は、アグレッシブモードの認証方法を説明するための図である。
図２に示すように、アグレッシブモードは、始動者と応答者とを有する。また、ｔは経過時刻を表している。アグレッシブモードは、始動者と応答者との間で、３回（１．５往復）の通信を行い、ISAKMP SAを確立する。始めの２回（１往復）の通信において両者で使用するアルゴリズム等の取り決めと、鍵交換に必要なDiffie-Hellman鍵交換アルゴリズムの公開値や乱数等の補助的なデータの交換が行われる。そして、３回目の通信において、始動者の認証と生成された鍵の認証が行われる。この３回目の通信は、生成されるISAKMP SAによって暗号化されない。したがって、IDの保護が不可能となる。
【０００９】
メインモード、アグレッシブモードは、電子署名、公開鍵暗号、予め保持している共通鍵を用いる方法の３種類の認証方法が利用可能である。
【００１０】
Phase2のクイックモードは、始動者と応答者の間で、３回（１．５回）の通信を行い、IPsecのSAを確立する。クイックモードにおける通信内容は、ISAKMP SAによって保護される。始めの２回（１往復）の通信において、両者で使用するアルゴリズム等の取り決めが行われ、３回目の通信で生成された鍵の認証が行われる。
【００１１】
上述のようにして、IPsecで安全な通信を行う前に通信者間で暗号通信に利用されるセッション鍵を共有することができる。
【００１２】
続いて、認証サーバを利用し、IPsecトンネリングを行う通信システムを考える。IPsecトンネリングとは、暗号によって実現される安全な通信経路のことを指し、仮想的な専用回線とみなすことができる。
【００１３】
図３は、認証サーバを利用してCPE(Customer Premises Equipment)装置の認証を行うネットワークを模式的に示す図である。CPE装置は、企業や家庭などに設置される通信端末のことであり、パソコン等が該当する。図３に示すように、CPE装置の認証を行うネットワークは、ISP(Internet Service Provider)１、Radius(Remoto Authentication Dial In User Service)サーバ２、Gateway３、ESP(Encapsulating Security Payload)トンネル４、CPE装置５−１から５−３を有している。Gateway３は、ルータやスイッチ等がある。なお、ここではCPE装置が３台設置されて図示されているが、CPE装置は１台以上あればよい。
【００１４】
まず、CPE装置５−２は、Gateway３を中継して、Radiusサーバ２と認証を行う。CPE装置５−２がRadiusサーバ２と認証が成功した場合、ISP１に通信が可能となる。なお、Radiusサーバ２を利用せずに、Gateway３自身に認証手段があれば、Gateway３で認証処理を行い、認証が成功した場合、ISP１に通信が可能となる。
【００１５】
上述した認証処理について、図４を参照しながら詳細に説明する。
【００１６】
図４は、上述した図３に示すCPE装置の認証を行うネットワークの認証方法を説明するための図である。図４は始動者、応答者、認証サーバから構成されている。なお、始動者、応答者、認証サーバは、それぞれ図３に示すCPE装置、Gateway、Radiusサーバを表している。また、ｔは経過時刻を表している。
【００１７】
図４に示すように、始動者であるCPE装置は、応答者であるGatewayに対し、Phase1、即ち、ISAKMP SAを確立する。Phase1が確立された後、始動者であるCPE装置と応答者であるGatewayとでｘauth認証及びRadius-ｘauth認証をを行う。
【００１８】
ｘauth認証は、始動者であるCPE装置と応答者であるGatewayとで認証用パケットが１往復する。まず、応答者であるGatewayは、始動者であるCPE装置 にREQUESTパケットを送信する。REQUESTパケットは、応答者が始動者に対してユーザネームとパスワードを要求するパケットである。始動者であるCPE装置がREQUESTパケットを受信すると、始動者であるCPE装置は応答者であるGatewayに対して、REPLYパケットを送信する。REPLYパケットは、応答者から受信したREQUESTパケットに対し、ユーザネーム、IPアドレスをセットし、始動者が応答者に応答するパケットである。なお、ｘauth認証がPAP(Password Authentication Protocol)認証である場合、REPLYパケットはユーザネームとパスワードを入れて、応答者であるGatewayに送信される。
【００１９】
応答者であるGatewayが、REPLYパケットを受信すると、Radiusサーバに対して、Access-Requestパケットを送信する。Access-Requestパケットは、応答者からRadiusサーバに対して、接続要求を行うパケットであり、REPLYパケットにセットされているユーザネームとIPアドレスがセットされている。なお、ｘauth認証が、PAP認証である場合には、Access-RequestパケットにREPLYパケットのユーザネーム、IPアドレス、パスワードをセットしてRadiusサーバに送信する。
【００２０】
RadiusサーバがAccess-Requestパケットを受信すると、Radiusサーバ自身が有するユーザネーム、IPアドレスと、Access-Requestパケットにセットされたユーザネーム、IPアドレスを比較する。比較した結果、一致した場合、Radiusサーバは、認証成功と判断し、応答者であるGatewayに対して、Access-Acceptパケットを送信する。なお、PAP認証である場合には、比較項目にパスワードが追加される。Access-Acceptパケットは、接続許可を行うパケットであり、Radiusサーバが認証成功と判断した場合に応答者に対して送信するパケットである。
【００２１】
応答者であるGatewayは、Access-Acceptパケットを受信すると、始動者であるCPE装置にSETパケットを送信する。SETパケットは、応答者が始動者に対して認証成功であることを伝えるパケットである。始動者であるCPE装置は、SETパケットを受信すると、応答者であるGatewayに対して、ACKパケットを送信し、認証処理が完了する。ACKパケットは、始動者が応答者から受信したSETパケットに対し、認証成功であったことを確認するパケットである。
【００２２】
なお、Radiusサーバを使用せずにPAP認証を行う場合は、応答者であるGateway自身が有するユーザネーム、IPアドレス、パスワードとREPLYパケットにセットされたユーザネーム、IPアドレス、パスワードを比較する。比較した結果、一致した場合には、応答者であるGatewayは始動者であるCPE装置にSETパケットを送信する。始動者であるCPE装置はSETパケット受信すると、応答者であるGatewayに対して、ACKパケットを送信し、認証処理が完了する。
【００２３】
ｘauth認証及びRadius-ｘauth認証が完了すると、Phase2、即ち、IPsecのSAを確立する処理が開始さる。IPsecのSAを確立する処理が終了し、Phase１の処理を張り直す場合、Phase１、ｘauth認証、Radius-ｘauth認証、Phase2の処理を繰り返す。
【００２４】
さらに、上述した応答者であるGatewayとRadiusサーバとの認証処理をフローチャートを参照しながら詳細に説明する。
図５は、応答者であるGatewayとRadiusサーバとの認証処理を示す従来のフローチャートである。
【００２５】
まず、上述の認証方法を利用し、応答者であるGatewayがREPLYパケットを受信する（Ｓ１０１）。次に、応答者であるGatewayが受信したREPLYパケットにセットされているユーザネーム、パスワード等をAccess-Requestパケットにセットし、Gatewayは、RadiusサーバにAccess-Requestパケットを送信する、即ち、認証問い合わせを行う（Ｓ１０２）。Radiusサーバで認証が成功した場合（Ｓ１０３；Ｙｅｓ）、ネゴシエーションを続行、即ち、IKEを継続させる。Radiusサーバで認証が失敗した場合（Ｓ１０３；Ｎｏ）、ネゴシエーションを終了、即ち、IKEを中断する。
【特許文献１】特開２００１−２９８４４９号公報
【特許文献２】特開２００３−１７９５９２号公報
【発明の開示】
【発明が解決しようとする課題】
【００２６】
しかしながら、上述したような認証方法は、Phase１を張り直す、即ち、始動者と応答者との間で拡張認証を行う場合、その都度Radiusサーバに認証問い合わせをしなければいけなかった。そのため、通信ネットワーク上のトラフィックが増大し、ネットワーク運営に支障をきたしていた。
【００２７】
本発明は、上述の問題点に鑑みてなされたものであり、Phase１を張り直す、即ち、始動者と応答者との間で再度拡張認証を行う場合、その都度Radiusサーバに認証問い合わせをしなくてもよい通信制御方法を提供する。
【課題を解決するための手段】
【００２８】
本発明の通信制御方法の第１の態様は、始動者から送信される認証パケットを応答者が受信する受信ステップと、応答者から認証サーバに認証問い合わせを行う認証問い合わせステップと、認証問い合わせが成功したか否かを判定する認証判定ステップと、認証問い合わせが成功した場合に、ネゴシエーションを続行する認証続行ステップとを備えた通信制御方法であって、始動者から応答者に複数回ネゴシエーションを行った場合に、前記始動者が前記応答者に接続を開始した最初のネゴシエーションであるか否かを判断する認証判断ステップを備えたことを特徴とする通信制御方法である。
【００２９】
本発明の通信制御方法の第２の態様は、認証判断ステップが、最初のネゴシエーションであると判断した場合に、２回目以降のネゴシエーションは始動者から送信される認証パケットの認証情報と応答者が有する認証情報とを比較し、比較した結果一致した場合に、認証成功であると判断することを特徴とする通信制御方法である。
【００３０】
本発明の通信制御方法の第３の態様は、認証情報が、ユーザネーム、IPアドレス及びパスワードであることを特徴とする通信制御方法である。
【００３１】
本発明の通信制御装置の第１の態様は、始動者から送信される認証パケットを応答者が受信する受信部と、前記応答者から認証サーバに認証問い合わせを行う認証問い合わせ部と、前記認証問い合わせが成功したか否かを判定する認証判定部と、前記認証問い合わせが成功した場合に、ネゴシエーションを続行する認証続行部とを備えた通信制御装置であって、前記始動者から前記応答者に複数回ネゴシエーションを行った場合に、前記始動者が前記応答者に接続を開始した最初のネゴシエーションであるか否かを判断する認証判断部を備えたことを特徴とする通信制御装置である。
【００３２】
本発明の通信制御装置の第２の態様は、認証判断部が、最初のネゴシエーションであると判断した場合に、２回目以降のネゴシエーションは始動者から送信される認証パケットの認証情報と応答者が有する認証情報とを比較し、比較した結果一致した場合に、認証成功であると判断することを特徴とする通信制御装置である。
【００３３】
本発明の通信制御装置の第３の態様は、認証情報が、ユーザネーム、IPアドレス及びパスワードであることを特徴とする通信制御装置である。
【００３４】
本発明の制御プログラムの第１の態様は、始動者から送信される認証パケットを応答者に受信させ、応答者から認証サーバに認証問い合わせを行わせ、認証問い合わせが成功したか否かを判定させ、認証問い合わせが成功した場合に、ネゴシエーションを続行させる通信制御装置をコンピュータにより制御する制御プログラムであって、始動者から応答者に複数回ネゴシエーションを行った場合に、前記始動者が前記応答者に接続を開始した最初のネゴシエーションであるか否かを判断させることを特徴とする制御プログラムである。
【００３５】
本発明の制御プログラムの第２の態様は、判断が、最初のネゴシエーションであると判断した場合に、２回目以降のネゴシエーションは始動者から送信される認証パケットの認証情報と応答者が有する認証情報とを比較し、比較した結果一致した場合に、認証成功であると判断させることを特徴とする制御プログラムである。
【００３６】
本発明の制御プログラムの第３の態様は、認証情報が、ユーザネーム、IPアドレス及びパスワードであることを特徴とする制御プログラムである。
【００３７】
本発明の記録媒体の第１の態様は、上述に記載の制御プログラムを記録したことを特徴とするコンピュータ読取可能な記録媒体である。
【発明の効果】
【００３８】
本発明の通信制御方法により、始動者と応答者との間で拡張認証を行う場合、その都度Radiusサーバに認証問い合わせをしなくてもよい認証方法を提供することが可能となる。即ち、応答者とRadiusサーバとで行われる認証時のトラフィック量が軽減されることによって、従来より適切なネットワーク運営が期待できる。
【発明を実施するための最良の形態】
【００３９】
以下に、本発明の実施形態を、図面を参照しながら詳細に説明する。
【００４０】
図６は、本発明の通信制御方法を説明するための図である。
図６に示すように、本発明の通信制御方法は、始動者、応答者、認証サーバで構成される。また、ｔは経過時刻を表している。まず、始動者は応答者との間で、Phase1の処理を開始する。
【００４１】
Phase1では、メインモードを使用する。即ち、始動者と応答者との間で、６回（３往復）の通信を行ってISAKMPを確立する。始めの２回（１往復）の通信において両者で使用するアルゴリズム等の取り決めが行われる。次の２回（１往復）の通信において鍵交換に必要なDiffie-Hellman鍵交換アルゴリズムの公開値や乱数等の補助的なデータの交換が行われる。そして、最後の２回（１往復）の通信で生成された鍵の認証が行われる。Phase1の処理が終了すると、続いて、始動者は応答者との間で、ｘauth認証及びRadius−xauth認証を開始する。
【００４２】
ｘauth認証は、始動者と応答者とで認証用パケットが１往復する。まず、応答者は、始動者 にREQUESTパケットを送信する。REQUESTパケットは、応答者が始動者に対してユーザネームとIPアドレスを要求するパケットである。始動者がREQUESTパケットを受信すると、始動者は応答者に対して、REPLYパケットを送信する。REPLYパケットは、応答者から受信したREQUESTパケットに対し、ユーザネームとIPアドレスをセットし、始動者が応答者に応答するパケットである。なお、ｘauth認証がPAP認証である場合、REPLYパケットはユーザネームとIPアドレスとパスワードを入れて、応答者に送信される。
【００４３】
応答者が、REPLYパケットを受信すると、Radiusサーバに対して、Access-Requestパケットを送信する。Access-Requestパケットは、応答者からRadiusサーバに対して、接続要求を行うパケットであり、REPLYパケットにセットされているユーザネームとIPアドレスがAccess-Requestパケットにセットされている。なお、ｘauth認証が、PAP認証である場合には、Access-RequestパケットにREPLYパケットのユーザネーム、IPアドレス、パスワードをセットしてRadiusサーバに送信する。
【００４４】
応答者は、Access-Acceptパケットを受信すると、始動者から送信された際のユーザネームとIPアドレスを応答者自身に登録する。さらに、始動者にSETパケットを送信する。SETパケットは、応答者が始動者に対して認証成功であることを伝えるパケットである。始動者は、SETパケットを受信すると、応答者に対して、ACKパケットを送信し、認証処理が完了する。ACKパケットは、始動者が応答者から受信したSETパケットに対し、認証成功であったことを確認するパケットである。
【００４５】
なお、Radiusサーバを使用せずにPAP認証を行う場合は、応答者自身が有するユーザネーム、IPアドレス、パスワードとREPLYパケットにセットされたユーザネーム、IPアドレス、パスワードを比較する。比較した結果、一致した場合には、応答者は始動者にSETパケットを送信する。始動者はSETパケット受信すると、応答者に対して、ACKパケットを送信し、認証処理が完了する。
【００４６】
始動者が応答者との間で、ｘauth認証を成功させると、引き続いて、応答者はRadiusサーバとの間でRadius−xauth認証を行う。
【００４７】
Radius-xauth認証は、応答者であるGatewayが、REPLYパケットを受信すると、Radiusサーバに対して、Access-Requestパケットを送信する。Access-Requestパケットは、応答者からRadiusサーバに対して、接続要求を行うパケットであり、REPLYパケットにセットされているユーザネームとIPアドレスがAccess-Requestパケットにセットされている。なお、ｘauth認証が、PAP認証である場合には、Access-RequestパケットにREPLYパケットのユーザネーム、IPアドレス、パスワードをセットしてRadiusサーバに送信する。
【００４８】
RadiusサーバがAccess-Requestパケットを受信すると、Radiusサーバ自身が有するユーザネーム、パスワードと、Access-Requestパケットにセットされたユーザネーム、パスワードを比較する。比較した結果、一致した場合、Radiusサーバは、認証成功と判断し、応答者であるGatewayに対して、Access-Acceptパケットを送信する。Access-Acceptパケットは、接続許可を行うパケットであり、Radiusサーバが認証成功と判断した場合に応答者に対して送信するパケットである。
【００４９】
応答者がRadiusサーバとの間でRadius−xauth認証を成功させ、始動者との間でxauth認証を成功させると、始動者は応答者との間で、Phase2の処理を開始する。
【００５０】
Phase2は、クイックモードを使用する。即ち、始動者と応答者の間で、３回（１．５回）の通信を行い、IPsecのSAを確立する。クイックモードにおける通信内容は、ISAKMP SAによって保護される。始めの２回（１往復）の通信において、両者で使用するアルゴリズム等の取り決めが行われ、３回目の通信で生成された鍵の認証が行われる。
【００５１】
次に、始動者はPhase1の張り直し処理を行う。上述のPhase1の処理が終了後、続いて、始動者は応答者との間で、ｘauth認証を開始する。
【００５２】
ｘauth認証は、始動者と応答者とで認証用パケットが１往復する。まず、応答者は、始動者 にREQUESTパケットを送信する。始動者がREQUESTパケットを受信すると、始動者は応答者に対して、REPLYパケットを送信する。REPLYパケットは、応答者から受信したREQUESTパケットに対し、ユーザネームをセットし、始動者が応答者に応答するパケットである。なお、ｘauth認証がPAP認証である場合、REPLYパケットはユーザネームとパスワードを入れて、応答者に送信される。
【００５３】
応答者が、REPLYパケットを受信すると、応答者自身に登録されているユーザネームとIPアドレスとREPLYパケットにセットされているユーザネームとIPアドレスとを比較する。比較した結果、一致した場合、始動者は応答者との間で、Phase2の処理を行う。一致しなかった場合、応答者は始動者とのネゴシエーションを終了させる。
【００５４】
即ち、応答者とRadiusサーバとの間で１回目の認証が成功すると、２回目以降の応答者とRadiusサーバとの間での認証問い合わせは行わない。即ち、従来の応答者とRadiusサーバとの間での認証問い合わせである、図６に示す破線の矢印部分は、本発明によって行わないようにする。
【００５５】
その際、応答者とRadiusサーバとの認証問い合わせは、１回目で認証が成功した際のユーザネーム、IPアドレスを状態保持しておく。そして、２回目以降の応答者とRadiusサーバとの認証問い合わせで、１回目で認証が成功した際のユーザネーム、
IPアドレスを使用することにより、２回目以降の応答者とRadiusサーバとの認証問い合わせが不要となる。PAP認証の場合には、応答者はユーザネームとIPアドレスとパスワードを状態保持しておく。
【００５６】
なお、上述した２回目以降の応答者とRadiusサーバとの認証問い合わせが不要とならず、２回目以降の応答者とRadiusサーバとの認証問い合わせが必要となるのは、始動者と応答者とのSAがすべて解放された場合のみである。
【００５７】
そして、上述の実施形態はメインモードを利用して、Phase1の処理を行ったが、アグレッシブモードを利用して、Phase1の処理を行ってもよい。
【００５８】
さらに、上述した本発明の応答者とRadiusサーバとの認証処理をフローチャートを参照しながら詳細に説明する。
図７は、応答者とRadiusサーバとの認証処理を示す本発明のフローチャートである。
【００５９】
まず、応答者は始動者からREPLYパケットを受信する（Ｓ２０１）。応答者はREPLYパケットを受信すると、状態保持の判定を行う（Ｓ２０２）。なお、状態保持とは、ユーザネーム、IPアドレス等が応答者に保持されている状態をいう。応答者が状態保持中でない場合、即ち、ユーザネーム、IPアドレス等が保持されていない場合（Ｓ２０２；ＹＥＳ）、応答者はRadiusサーバに対して認証問い合わせを行う（Ｓ２０３）。即ち、応答者はRadiusサーバに対してAccess-Requestパケットを送信する。
【００６０】
応答者はRadiusサーバに対して認証問い合わせを行い、認証が成功したか否かを判定する（Ｓ２０４）。即ち、Access-Requestパケットにセットされているユーザネーム、IPアドレス等とRadiusサーバに登録されているユーザネーム、IPアドレス等とを比較する。
【００６１】
認証が成功した場合（Ｓ２０４：ＹＥＳ）、即ち、Access-Requestパケットにセットされているユーザネーム、IPアドレス等とRadiusサーバに登録されているユーザネーム、IPアドレス等とが一致した場合、応答者は状態保持を行う。即ち、応答者は始動者のユーザネーム、IPアドレス等を保持する（Ｓ２０５）。そして、応答者は、ネゴシエーションを続行する（Ｓ２０６）、即ち、IKEを継続させる。
【００６２】
一方、応答者が状態保持中である場合、即ち、応答者が始動者のユーザネーム、IPアドレス等を保持している場合（Ｓ２０２；ＮＯ）、応答者に状態保持されている始動者のユーザネーム、IPアドレス等と、REPLYパケットにセットされているユーザネーム、IPアドレス等とを比較する（Ｓ２０７）。
【００６３】
応答者に状態保持されている始動者のユーザネーム、IPアドレス等と、REPLYパケットにセットされているユーザネーム、IPアドレス等とを比較した結果、一致した場合（Ｓ２０７；ＹＥＳ）、ネゴシエーションは続行される（Ｓ２０６）。一方で、応答者に状態保持されている始動者のユーザネーム、IPアドレス等と、REPLYパケットにセットされているユーザネーム、IPアドレス等とを比較した結果、一致しなかった場合（Ｓ２０７；ＮＯ）、応答者はネゴシエーションを終了させる（Ｓ２０６）。
【００６４】
また、応答者がRadiusサーバに対して認証問い合わせを行い、認証が成功したか否かを判定する処理（Ｓ２０４）で、認証が失敗した場合（Ｓ２０４；ＮＯ）、応答者はネゴシエーションを終了させる（Ｓ２０６）。即ち、応答者がRadiusサーバに対してAccess-Requestパケットを送信し、Access-Requestパケットにセットされている始動者のユーザネーム、IPアドレス等と、Radiusサーバに登録されているユーザネーム、IPアドレス等とが一致しなかった場合は、応答者はネゴシエーションを終了させる。
【００６５】
なお、本実施形態はRadiusサーバを認証サーバとして使用したが、AAA(Authentication、Authorization、Authorization)サーバであればよく、TACACS(Terminal Access Controller Access Control System)サーバ等であってもよい。
【００６６】
さらに、本発明の通信制御装置（応答者）の動作について図８を参照しながら詳細に説明する。
【００６７】
図８は本発明の通信制御装置を示す他のブロック図である。図８に示すように、本発明の通信制御装置は、ISAKMP制御デーモン７、Kernel８、ピア情報データベース９、SA情報データベース１０を備えている。なお、本実施形態では、上述したRadiusサーバを使用せずに、始動者と応答者との間で認証処理を行うことを考える。
【００６８】
まず、始動者が応答者に接続すると、上述した応答者はPhase１の処理を開始する。そして、Phase１の処理が終了すると、次に応答者は、xauth認証を開始する。なお、Phase１の処理はメインモード、アグレッシブモードのどちらでもよい。
【００６９】
xauth認証では、応答者が始動者に対して、REQUESTパケットを送信する。始動者は、応答者から送信されたREQUESTパケットを受信すると、ユーザネーム、IPアドレスをREPLYパケットにセットし、応答者に送信する。
【００７０】
応答者は、始動者から送信されたREPLYパケットを受信する。そして、応答者は、REPLYパケットにセットされているユーザネーム、IPアドレスと、応答者自身に登録されているユーザネーム、IPアドレスとを比較する。比較して一致した場合、応答者の内部にあるISAKMP制御デーモン７は、ピア情報データベース８に登録されたピアの情報を基にSETパケットの送信依頼を、応答者の内部にあるKernel９に行う。
【００７１】
SETパケットの送信依頼を受けたKernel９は、始動者にSETパケットを送信する。SETパケットを受信した始動者は、応答者に対しACKパケットを送信する。応答者は始動者から送信されたACKパケットを受信すると、応答者は上述のPhase２の処理を開始する。
【００７２】
応答者は、上述のPhase２の処理を終了すると、応答者内部にあるISAKMP制御デーモン７が、Kernel９に対してIPsec SAの作成完了通知を行い、SA情報データベース１０にIPsec SA情報登録する。そして、Kernel９はSA情報データベース１０に登録されたSA情報を利用し、応答者と始動者とのESP通信を開始する。
【００７３】
以上の説明においては、通信制御装置を制御するための制御プログラムが予めＲＯＭに記憶されている場合について説明したが、各種磁気ディスク、光ディスク、メモリカード等の記録媒体に制御用のプログラムをあらかじめ記録し、これらの記録媒体から読み込み、インストールするように構成することも可能である。
【００７４】
また、通信インタフェースを設け、インターネット、ＬＡＮなどのネットワークを介して制御用プログラムをダウンロードし、インストールして実行するように構成することも可能である。このように構成することにより、ソフトウェア的により高機能としたり、より信頼性の高いネットワーク機器を構成することが可能となる。
【００７５】
なお、本発明は、上述した実施形態に限定されるものではなく、その要旨を逸脱しない範囲内で種々変形して実施することが可能である。
【産業上の利用可能性】
【００７６】
本発明の通信制御方法により、始動者と応答者との間で拡張認証を行う場合、その都度Radiusサーバに認証問い合わせをしなくてもよい。その結果、通信トラフィック量が軽減され、ネットワーク運営が良好となるため産業上の利用可能性が高い。
【図面の簡単な説明】
【００７７】
【図１】図１は、メインモードの認証方法を説明するための図である。
【図２】図２は、アグレッシブモードの認証方法を説明するための図である。
【図３】図３は、認証サーバを利用してCPE装置の認証を行うネットワークを模式的に示す図である。
【図４】図４は、図３に示すCPE装置の認証を行うネットワークの認証方法を説明するための図である。
【図５】図５は、応答者であるGatewayとRadiusサーバとの認証処理を示す従来のフローチャートである。
【図６】図６は、本発明の認証方法を説明するための図である。
【図７】図７は、応答者とRadiusサーバとの認証処理を示す本発明のフローチャートである。
【図８】図８は、応答者のブロック図である。
【符号の説明】
【００７８】
１  インターネット
２  Radiusサーバ
３  Gateway（応答者）
４  ESPトンネル
５−１〜５−３  CPE装置（始動者）
６  ネットワーク
７  ISAKMP制御デーモン
８  ピア情報データベース
９  Kernel
１０  SA情報データベース
【図１】
2006086618.tif 000003
【図２】
2006086618.tif 000004
【図３】
2006086618.tif 000005
【図４】
2006086618.tif 000006
【図５】
2006086618.tif 000007
【図６】
2006086618.tif 000008
【図７】
2006086618.tif 000009
【図８】
2006086618.tif 000010