通信方法および通信システム
【課題】IKEv2において、本来、IKErではないノードが、IKErになりすまして、IKEiのノードのIDを取得することを防止する。
【解決手段】IKEiのノード１０は、IKE＿AUTH1stメッセージにより、IKErのノード２０に対し、仮ＩＤを通知する。その後、IKEiのノード１０は、IKE＿AUTH2ndメッセージによりIKErのノード２０のディジタル署名を受信し、このIKErのノード２０の認証処理を行う。ここで、IKErのノード２０の本人性の認証がとれたとき、IKE＿AUTH3rdメッセージにより、このIKEiのノード１０の本ＩＤを通知する。
【解決手段】IKEiのノード１０は、IKE＿AUTH1stメッセージにより、IKErのノード２０に対し、仮ＩＤを通知する。その後、IKEiのノード１０は、IKE＿AUTH2ndメッセージによりIKErのノード２０のディジタル署名を受信し、このIKErのノード２０の認証処理を行う。ここで、IKErのノード２０の本人性の認証がとれたとき、IKE＿AUTH3rdメッセージにより、このIKEiのノード１０の本ＩＤを通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、IPsec（Internet Protocol Security）トンネリングに用いられるIKE（Internet Key Exchange）技術に関する。
【背景技術】
【０００２】
従来、インターネット上での通信セキュリティに関する技術として、IPsecトンネルがある（非特許文献１参照）。このIPsecトンネルを自動で確立するための技術としては、IETF RFC4306に規定されるIKEv2がある（非特許文献２参照）。本技術を用いることにより、接続しようとするIPsecトンネル終端装置間で、本人性認証を行うための情報の交換、IPsecトンネル内のIP通信を行うために利用するIPアドレス（プレフィックス）の割り当て、暗号化鍵の生成等を行って、セキュアなIPsecトンネルを確立することができる。なお、本人性の認証には、例えば、AAA（Authentication Authorization Accounting）サーバ等、認証サーバとの連携による実現も可能である。
【０００３】
これらの技術により、IKEv2イニシエータ（IKEi）のノードとIKEv2レスポンダ（IKEr）のノードとの間でIPsecトンネルを確立し、IKEiのノードは、このIPsecトンネル経由で通信相手の端末との間でセキュアな通信を行うことができる。
【０００４】
このことを、図１を用いて説明する。ここでは、IKEiのノードの認証方式として、MD5-Challengeを用いる場合を例に説明する。
【０００５】
IKEiのノードは、IKErのノードとの間で、IKE＿SA＿INIT（Internet Key Exchange＿Security Associationの初期情報）の交換を行う（Ｓ１）。つまり、IKEのための初期情報の交換を行う。そして、IKEiのノードは、自身のユーザIDを、IKE＿AUTH1stメッセージによりIKErのノードへ通知する（Ｓ２）。そして、IKErのノードは、通知されたユーザIDを元に認証サーバの選択を行い（Ｓ３）、その選択した認証サーバへ、このユーザIDを含むAccess-Request1stメッセージを送信する（Ｓ４）。認証サーバは、受信したAccess-Request1stメッセージに含まれるユーザIDを元に、このユーザIDの認証方式を選択し（Ｓ５）、選択した認証方式と、その認証方式に用いる情報（チャレンジ値）とを含むAccess-Challengeメッセージを、IKErのノードへ送信する（Ｓ６）。
【０００６】
そして、IKErのノードは、自身のディジタル署名と、チャレンジ値とを含むIKE＿AUTH2ndメッセージをIKEiのノードへ送信する（Ｓ７）。次に、IKEiのノードは、ディジタル署名に基づきIKErのノードの認証を行い（Ｓ８：レスポンダ認証）、その認証結果がOKだった場合、指定された認証方式に基づき、自身のパスワードをチャレンジ値でハッシュ化したハッシュ化パスワードをIKE＿AUTH3rdメッセージで送信する（Ｓ９）。そして、IKErのノードは、認証サーバへ、IKErのノードのハッシュ化パスワードをAccess-Request2ndメッセージにより送信する（Ｓ１０）。その後、認証サーバは、Access-Request1stメッセージで受信したIDのノードに関するチャレンジ値で、ハッシュ化パスワードからパスワードを取り出し、このパスワードが、当該ノードのパスワードであることを確認すると、その旨をAccess-AcceptメッセージでIKErのノードへ通知する。その後、IKErのノードはIKEiのノードとの間でIPsecトンネルを確立する。そして、IKEiのノードは、このIKErのノードとの間に確立されたIPsecトンネル経由で、通信相手の端末との間で通信を行う。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】IETF、RFC4301、[online]、[2010年2月10日検索]、インターネット、<URL: http://www.ietf.org/rfc/rfc4301.txt >
【非特許文献２】IETF、RFC4306、[online]、[2010年2月10日検索]、インターネット、<URL: http://www.ietf.org/rfc/rfc4306.txt >
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、前記した従来技術は、IKEiのノードがIKErの認証を完了する前に、IKErのノードへ、イニシエータID（IDi）を通知するものである。このため、本来、IKErではないノードが、IKErになりすまして、IKEiのノードのID（IDi）を取得する可能性がある。そこで、本発明は、前記した問題を解決し、本来、IKEv2において、IKErではないノードが、IKErになりすまして、IKEiのノードのIDを取得することを防止することを目的とする。
【課題を解決するための手段】
【０００９】
前記した課題を解決するため、本発明は、IKE（Internet Key Exchange）v2においてイニシエータとなるIKEiのノードと、IKEv2におけるレスポンダとなるIKErのノードと、IKErのノードからの認証要求に応じて認証処理を行う認証サーバとを含む通信システムに関する発明とした。この通信システムのIKEiのノードは、IKErのノードのＩＤごとに、IKEv2において、そのＩＤのIKErのノードに対し用いる自身のIKEiのノードの仮ＩＤおよび本ＩＤを示したリモートアクセス管理情報を記憶する。そして、IKEiのノードは、リモートアクセス管理情報から読み出した、IKErのノードに対し用いる仮ＩＤを含むIKE＿AUTH1stメッセージを、IKErのノードへ送信する。そして、IKErのノードは、IKEiのノードからのIKE＿AUTH1stメッセージを受信したとき、認証サーバへ、IKE＿AUTH1stメッセージに含まれる仮ＩＤのノードの認証に用いる認証方式を問い合わせるAccess-Request1stメッセージを送信する。次に、IKErのノードは、認証サーバから仮ＩＤのノードの認証に用いる認証方式を含む応答を受信し、自身のIKErのノードのディジタル署名を生成する。そして、IKErのノードは、受信した応答に含まれる認証方式と、自身のIKErのノードのディジタル署名とを含むIKE＿AUTH2ndメッセージをIKEiのノードへ送信する。次に、IKEiのノードは、IKErのノードから受信したIKE＿AUTH2ndメッセージに含まれるディジタル署名に基づきIKErのノードの認証処理を実行する。そして、IKEiのノードは、IKErのノードの認証ＯＫが確認されたとき、リモートアクセス管理情報から読み出したIKErのノードに対し用いる本ＩＤと認証方式の認証に用いる認証情報とを含むIKE＿AUTH3rdメッセージをIKErのノードへ送信する。次に、IKErのノードは、IKEiのノードから受信したIKE＿AUTH3rdメッセージに含まれる本ＩＤと認証方式の認証に用いる認証情報とをAccess-Request2ndメッセージに含めて、認証サーバへ送信する。そして、IKErのノードは、認証サーバから受信した、Access-Request2ndメッセージの応答がIKEiのノードの認証結果が認証ＯＫを示すものであるとき、IKEiのノードとの間にIPsecトンネルを確立する。
【００１０】
このようにIKEiのノードは、IKErのノードの認証を行う前に、IKErのノードへ自身の仮IDを通知する。そして、この仮IDの通知後、IKErのノードから送信されたIKE＿AUTH2ndメッセージに基づきIKErのノードの認証を行い、認証ＯＫだったときに、IKErのノードに対し本ID（このIKEiのノードのID）を通知する。よって、本来、IKErではないノードが、IKErになりすまして、IKEiのノードのIDを取得することを防止できる。
【００１１】
また、本発明の通信システムのIKErのノードは、IKEiのノードから受信したIKE＿AUTH3rdメッセージにＩＤが含まれていなかったとき、Access-Request1stに含まれるＩＤをAccess-Request2ndメッセージに含めて、認証サーバへ送信する。そして、認証サーバから受信した、Access-Request2ndメッセージの応答がIKEiのノードの認証結果が認証ＯＫを示すものであるとき、IKErのノードは、IKEiのノードとの間にIPsecトンネルを確立する。
【００１２】
このようにIKErのノードは、IKEiのノードからIKE＿AUTH3rdメッセージにIDが含まれていなかったときでも、IKE＿AUTH1stメッセージで受信したID（本IDまたは仮ID）を用いて認証サーバへ、Access-Request2ndメッセージを送信する。つまり、IKErのノードは、（１）IKE＿AUTH1stメッセージで本IDを受信した場合や、（２）IKE＿AUTH1stメッセージで仮IDを受信したが、その後IKE＿AUTH3rdメッセージで本IDを受信しなかった場合でも、IKE＿AUTH1stメッセージで受信したID（本IDまたは仮ID）を用いて、認証サーバへAccess-Request2ndメッセージを送信することができる。
【００１３】
また、本発明の通信システムの認証サーバは、ノードの仮ＩＤおよび本ＩＤと、ノードが用いる認証方式を含むユーザ管理情報を備える。そして、この認証サーバは、IKErのノードから、仮ＩＤを含むAccess-Request1stメッセージを受信したとき、ユーザ管理情報を参照して、仮ＩＤのノードの認証に用いる認証方式を含む応答をIKErのノードへ送信する。その後、認証サーバは、本ＩＤおよび認証情報を含むAccess-Request2ndメッセージを受信したとき、ユーザ管理情報を参照して、本ＩＤのノードの認証処理を行い、認証処理の認証結果をIKErのノードへ送信する。
【００１４】
このようにすることで、認証サーバは、Access-Requestメッセージに仮IDが含まれていた場合でも、本IDが含まれていた場合でも、そのIDのノードの認証に用いる認証方式および認証方式に用いる情報をIKErのノードへ送信することができる。
【発明の効果】
【００１５】
本発明によれば、IKEv2において、IKErではないノードが、IKErになりすまして、IKEiのノードのIDを取得することを防止できる。
【図面の簡単な説明】
【００１６】
【図１】比較例となるIKEv2における処理手順を示したシーケンス図である。
【図２】本実施の形態の通信システムの構成例を示した図である。
【図３】本実施の形態の通信システムの処理手順を示したシーケンス図である。
【図４】本実施の形態の通信システムの構成例を示した図である。
【図５】図４のリモートアクセス管理情報を例示した図である。
【図６】図４のドメイン管理情報を例示した図である。
【図７】図４のユーザ管理情報を例示した図である。
【図８】図４のIKEiのノードの処理手順を示した図である。
【図９】図４のIKErのノードの処理手順を示した図である。
【図１０】図４の認証サーバの処理手順を示した図である。
【図１１】本実施の形態の通信システムに用いられるノードの構成例を示した図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態を説明する。まず、図２を用いて本実施の形態の通信システムの構成例を説明する。通信システムは、ノード１０（１０Ａ，１０Ｂ），２０と、端末４０と、認証サーバ３０とを含んで構成される。ノード１０，２０は、ＩＰネットワーク経由で接続され、IPsecトンネルを確立する。そして、ノード１０，２０と通信相手である端末４０との間で、このIPsecトンネル経由での通信を行う。なお、このノード１０は、IPsecトンネル確立のためのIKEv2を実行する際、イニシエータ（IKEi）となるノードである。また、ノード２０は、このIKEv2を実行する際、レスポンダ（IKEr）となるノードである。このノード１０，２０はＩＰネットワーク経由で通信可能なコンピュータやルータにより実現される。認証サーバ３０は、このIKEiのノード１０を認証するための認証方式やこの認証方式に用いる各種情報を記憶するサーバであり、IKErのノード２０に接続される。IKErのノード２０は、この認証サーバ３０によりIKEiのノード１０の認証を行う。
【００１８】
次に、図３を用いて通信システムの処理の概要を説明する。ここでは概略説明のため、図３の説明を一部を省略する。まず、IKEiのノード１０は、IKErのノード２０との間でIKE＿SA＿INITの交換を行った後（Ｓ１１）、IKE＿AUTH1stメッセージによりIKErのノード２０へ仮IDを通知する（Ｓ１２）。この仮IDは、自身のノード１０の本当のユーザＩＤを示す本IDの送信前に使う仮のユーザIDである。
【００１９】
その後、IKEiのノード１０は、IKErのノード２０からIKE＿AUTH2ndメッセージを受信すると（Ｓ１７）、このIKE＿AUTH2ndメッセージにより受信したIKErのノード２０のディジタル署名に基づき、IKErのノード２０の認証を行う（Ｓ１８：レスポンダ認証）。そして、このIKErのノード２０の本人性の認証ができたとき、IKE＿AUTH3rdメッセージにより、このIKEiのノード１０の本IDをIKErのノード２０へ通知する（Ｓ１９）。つまり、IKEiのノード１０は、IKErのノード２０の本人性の認証ができてから、このIKEiのノード１０の本IDをIKErのノード２０へ送信する。よって、本来、このIKEiのノード１０のIKErではないノードが、IKErになりすまして、IKEiのノードのIDを取得することを防止できる。図３の処理の詳細は、後記する。
【００２０】
＜構成＞
次に、図４を用いて、通信システムを構成するノード１０，２０、認証サーバ３０の構成を説明する。ノード１０，２０、認証サーバ３０はそれぞれ、入出力部、処理部および記憶部を備える。
【００２１】
図４の各入出力部は、ＩＰネットワーク経由でデータを送受信可能な通信インタフェースや入出力インタフェースから構成される。また、各処理部は、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。さらに、各記憶部は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ等の記憶媒体から構成される。なお、ノード１０，２０、認証サーバ３０をプログラム実行処理により実現する場合、各記憶部には、ノード１０，２０や認証サーバ３０の機能を実現するためのプログラムが格納される。
【００２２】
＜IKEiのノード＞
まず、IKEiのノード１０を説明する。IKEiのノード１０は、入出力部１１、処理部１２および記憶部１３を備える。まず、記憶部１３から説明する。記憶部１３は、リモートアクセス管理情報１３１を記憶する。このリモートアクセス管理情報１３１は、IKErのノード２０のID（例えば、IKErのノード２０のアドレスのドメイン）ごとに、このIKErのノード２０が仮IDを用いてIKEv2のIKE＿AUTH1stメッセージを送信してもよいノードか否かを示すフラグと、仮IDを用いてIKE＿AUTH1stメッセージを送信してもよいノードであるとき、このノードに対し用いる仮IDおよび本IDとを示した情報である（図５参照）。
【００２３】
例えば、図５に示すリモートアクセス管理情報１３１において、IKErのノード２０が「fqdn.ntt.co.jp」であるとき、このノードに対しては仮IDを用いることができ（フラグ「On」）、そのとき用いる自身のノードの仮IDは「md5-user-1@vpn1-remote.net」であり、本IDは「alice@ntt.co.jp」であることを示す。このリモートアクセス管理情報１３１は、入出力部１１経由で更新可能である。例えば、図５に示す「No2」の情報において、仮IDのフラグは「Off」となっているが、仮IDを用いるようにしたい場合、このフラグを「On」に変更し、仮IDの欄に仮IDとして用いるIDを記述すればよい。このリモートアクセス管理情報１３１は、IKEiのノード１０が、IKE＿AUTH1stメッセージやIKE＿AUTH3rdメッセージを送信する際に参照される。
【００２４】
次に、図４の処理部１２を説明する。処理部１２は、主にIKErのノード２０との間でIKE＿AUTHメッセージの送受信を行い、IKErのノード２０の認証処理を行う。この処理部１２は、IKE＿AUTHメッセージ処理部１２１と、認証処理部１２２と、認証情報作成部１２３と、IPsecトンネル処理部１２４とを備える。
【００２５】
IKE＿AUTHメッセージ処理部１２１は、入出力部１１経由で、このIKEiのノード１０のレスポンダであるIKErのノード２０のアドレスの入力を受け付ける。そして、IKE＿AUTHメッセージ処理部１２１は、リモートアクセス管理情報１３１と、このIKErのノード２０のアドレスとを参照して、このIKErのノード２０に対し用いる仮IDを読み出す。そして、IKE＿AUTHメッセージ処理部１２１は、この読み出した仮IDを含むIKE＿AUTH1stメッセージを作成し、IKErのノード２０へ送信する。また、このIKE＿AUTHメッセージ処理部１２１は、IKErのノード２０へのIKE＿AUTH1stメッセージ送信後、認証処理部１２２により、このIKErのノードの認証ＯＫが確認されたとき、リモートアクセス管理情報１３１から、このIKErのノード２０に対し用いる本IDを読み出す。そして、このIKE＿AUTHメッセージ処理部１２１は、この本IDと、このIKEiのノード１０の認証に用いる認証情報（詳細は後記）を含むIKE＿AUTH3rdメッセージをIKErのノード２０へ送信する。
【００２６】
認証処理部１２２は、入出力部１１経由で、IKErのノード２０から受信したIKE＿AUTH2ndメッセージに含まれるディジタル署名に基づきIKErのノード２０の本人性の認証を行う。
【００２７】
認証情報作成部１２３は、IKErのノード２０から受信したIKE＿AUTH2ndメッセージで指定された認証方式に従い、自身のIKEiのノードの認証情報を作成する。例えば、このIKE＿AUTH2ndメッセージで指定された認証方式がMD5-Challengeであり、このメッセージによりMD5-Challengeに用いられるチャレンジ値が送信されてきたとき、このチャレンジ値を用いて、自身のパスワードをハッシュ化したハッシュ化パスワードを作成する。なお、このIKEiのノード１０のパスワードとチャレンジ値とは認証サーバ３０側にも記憶されている。そして、認証サーバ３０が、IKErのノード２０経由で、IKEiのノード１０のハッシュ化パスワードを受信し、このハッシュ化パスワードからパスワードを取り出し、、このパスワードが、自身の記憶するパスワードと同じとき、認証サーバ３０は、このIKEiのノード１０が確かにノード１０であると判断する。
【００２８】
IPsecトンネル処理部１２４は、認証処理部１２２において認証がとれたIKErのノード２０との間でIPsecトンネルを確立する。
【００２９】
＜IKErのノード＞
次に、IKErのノード２０を説明する。IKErのノード２０は、入出力部２１、処理部２２および記憶部２３を備える。まず、記憶部２３から説明する。この記憶部２３は、ドメイン管理情報２３１を記憶する。このドメイン管理情報２３１は、IKEiのノード１０のID（例えば、IKEiのノード１０のアドレスのドメイン）ごとに、当該IDが本IDか仮IDかを示すフラグと、そのIDのIKEiのノード１０からのIKE＿AUTHメッセージを受信したとき、そのIKEiのノード１０の認証方法を問い合わせる認証サーバ３０のアドレスを示した情報である。例えば、図６に示すドメイン管理情報２３１において、IKEiのノード１０から「vpn1-remote.net」というドメインを持つIDをIKE＿AUTHメッセージで受信したとき、このIDは仮IDであり（フラグＯｎ）、このIDのIKEiのノード１０の認証方法の問い合わせ先の認証サーバ３０のアドレスは「1100::1」であることを示す。このドメイン管理情報２３１は、入出力部２１経由で更新される。このドメイン管理情報２３１は、図４の仮ID判定部２２１（後記）において、IKEiのノード１０から送信されたIDが本IDか仮IDかを判定するときや、IKEiのノード１０の認証方法の問い合わせ先である認証サーバ３０を選択するときに参照される。
【００３０】
次に、処理部２２を説明する。処理部２２は、仮ID判定部２２１と、Access-Requestメッセージ処理部２２２と、ディジタル署名生成部２２３と、IKE＿AUTHメッセージ処理部２２４と、IPsecトンネル処理部２２５とを備える。
【００３１】
仮ID判定部２２１は、入出力部２１経由で、IKEiのノード１０からIKE＿AUTH1stメッセージを受信すると、ドメイン管理情報２３１を参照して、この受信したIKE＿AUTH1stメッセージに含まれるIDが仮IDであるか本IDかを判定する。
【００３２】
Access-Requestメッセージ処理部２２２は、仮ID判定部２２１によりIKE＿AUTH1stメッセージに含まれるIDが仮IDと判定されたとき、認証サーバ３０へ、この仮IDを含むAccess-Request1stメッセージを送信する。つまり、Access-Requestメッセージ処理部２２２は、このAccess-Request1stメッセージにより、認証サーバ３０へ、この仮IDのノードの認証に用いる認証方式を問い合わせる。また、Access-Requestメッセージ処理部２２２は、IKEiのノード１０からIKE＿AUTH3rdメッセージを受信したとき、このIKE＿AUTH3rdメッセージに含まれるIKEiのノード１０の本IDおよび認証情報（例えば、ハッシュ化パスワード）をAccess-Request2ndメッセージにより、認証サーバ３０へ送信する。つまり、Access-Requestメッセージ処理部２２２は、このAccess-Request2ndメッセージにより、認証サーバ３０へ、当該本IDのIKEiのノード１０の認証を依頼する。
【００３３】
ディジタル署名生成部２２３は、認証サーバ３０からAccess-Requestメッセージの応答を受信したとき、自身のIKErのノード２０のディジタル署名を生成する。
【００３４】
IKE＿AUTHメッセージ処理部２２４は、認証サーバ３０からのAccess-Requestメッセージの応答に含まれる認証方式と、その認証方式に用いる情報と、自身のディジタル署名とを含むIKE＿AUTH2ndメッセージを、IKE＿AUTH1stメッセージの送信元のIKEiのノード１０へ送信する。これにより、IKErのノード２０は、IKEiのノード１０へ、自身のディジタル署名と、IKEiのノード１０の認証情報を作成するときの認証方式と、その認証方式に用いる情報とを通知することができる。なお、ここで当該認証方式に用いる情報が特になければ、その情報をIKE＿AUTH2nd含めなくてもよい。
【００３５】
IPsecトンネル処理部２２５は、認証サーバ３０から受信した、Access-Request2ndメッセージの応答がIKEiのノード１０の認証ＯＫを示すものであるとき、IKEiのノード１０との間にIPsecトンネルを確立する。
【００３６】
＜認証サーバ＞
次に、認証サーバ３０を説明する。認証サーバ３０は、入出力部３１、処理部３２および記憶部３３を備える。まず、記憶部３３から説明する。この記憶部３３は、ユーザ管理情報３３１を記憶する。ユーザ管理情報３３１は、図７に示すように、IKEiのノード１０の仮IDおよび本IDと、このIKEiのノード１０が用いる認証方式と、その認証方式に用いる情報とを示した情報である。なお、図７のユーザ管理情報３３１は、認証方式が、MD5-Challengeであるノード１０に発行するチャレンジ値（発行Challenge)、パスワード等を含む。このチャレンジ値は、この値がMD5-Challengeに用いられるチャレンジ値であることを示す識別情報を含む。これにより、IKEiのノード１０は、この値がMD5-Challengeに用いられるチャレンジ値であることを判断できる。このユーザ管理情報３３１は、図４の入出力部３１経由で更新される。また、このユーザ管理情報３３１は、認証部３２１（後記）が、IKEiのノード１０の認証方式やその認証方式に用いる情報（チャレンジ値等）を選択するとき等に参照される。
【００３７】
処理部３２は、認証部３２１を備える。この認証部３２１は、IKErのノード２０から、ノード１０の仮IDを含むAccess-Request1stメッセージを受信したとき、ユーザ管理情報３３１を参照して、この仮IDのノード１０の認証に用いる認証方式を選択する。そして、この選択した認証方式を含む応答をIKErのノード２０へ送信する。また、この認証部３２１は、IKErのノード２０から、ノード１０の本IDおよび認証情報を含むAccess-Request2ndメッセージを受信したとき、この認証情報とユーザ管理情報３３１とを参照して、本IDのノード１０の認証処理を行う。そして、認証部３２１は、この認証処理の認証結果をIKErのノード２０へ送信する。例えば、認証部３２１は、IKEiのノード１０の本IDとハッシュ化パスワードを受信すると、ユーザ管理情報３３１に示される当該本IDのチャレンジ値を用いて、このハッシュ化パスワードのパスワードを取り出す。そして、この取り出したパスワードが、ユーザ管理情報３３１に示される当該本IDのパスワードと同じであれば、そのIKEiのノード１０を認証ＯＫ（本人性の認証が取れた）と判断し、その認証結果をAccess-Request2ndメッセージの送信元のIKErのノード２０へ送信する。
【００３８】
次に、図３の処理を詳細に説明する。まず、IKEiのノード１０は、IKErのノード２０との間でIKE＿SA＿INITの交換を行う（Ｓ１１）。そして、IKEiのノード１０のIKE＿AUTHメッセージ処理部１２１（図４参照）は、このIKErのノード２０に対し用いる仮IDをリモートアクセス管理情報１３１（図５参照）から読み出し、IKE＿AUTH1stメッセージにより通知する（Ｓ１２）。
【００３９】
次に、IKErのノード２０は、入出力部２１経由でIKE＿AUTH1stメッセージを受信すると、このIKE＿AUTH1stメッセージに含まれる仮IDをキーとしてドメイン管理情報２３１（図６参照）を参照して、認証サーバ３０の選択を行う（Ｓ１３）。そして、この選択した認証サーバ３０へ、この仮IDを含むAccess-Request1stを送信する（Ｓ１４）。
【００４０】
認証サーバ３０は、受信したAccess-Request1stに含まれる仮IDをキーとして、ユーザ管理情報３３１から、IKEiのノード１０の認証方式の選択を行う（Ｓ１５）。また、このユーザ管理情報３３１から、この認証方式に用いる情報（例えば、MD5-Challengeのチャレンジ値）を読み出し、この選択した認証方式とその認証方式に用いる情報とをAccess-Challengeメッセージに含めてIKErのノード２０へ送信する（Ｓ１６）。IKErのノード２０は、このAccess-Challengeメッセージを受信すると、自身のディジタル署名を生成する。そして、IKErのノード２０は、このディジタル署名と、Access-Challengeに含まれる認証方式、その認証方式に用いる情報とをIKE＿AUTH2ndメッセージによりIKEiのノード１０へ送信する（Ｓ１７）。
【００４１】
IKEiのノード１０は、IKErのノード２０からIKE＿AUTH2ndメッセージを受信すると、このIKE＿AUTH2ndメッセージに含まれるIKErのノード２０のディジタル署名をもとに、このIKErのノード２０の認証を行う（Ｓ１８：レスポンダ認証）。そして、認証ＯＫだったとき（つまり、IKErのノード２０の本人性が確認できたとき）、IKE＿AUTH3rdメッセージにより、このIKEiのノード１０の本IDを通知する（Ｓ１９）。また、このとき、IKEiのノード１０は、IKE＿AUTH2ndメッセージにより通知された認証方式に従い、その認証方式に用いる情報（チャレンジ値）を用いて、IKEiのノード１０の認証情報を作成する。例えば、チャレンジ値を用いてこのIKEiのノード１０のパスワードをハッシュ化する。そして、IKE＿AUTH3rdメッセージに、このIKEiのノード１０の認証情報を含めてIKErのノード２０へ送信する。
【００４２】
このIKE＿AUTH3rdを受信したIKErのノード２０は、IKEiのノード１０の認証情報および本IDを含むAccess-Request2ndメッセージを認証サーバ３０へ送信する（Ｓ２０）。そして、認証サーバ３０は、このAccess-Request2ndメッセージに含まれる認証情報および本IDとを用いて、IKEiのノード１０の認証処理を行う。そして、その結果、このIKEiのノード１０が認証ＯＫだったとき、その旨をAccess-AcceptメッセージでIKErのノード２０へ送信する。その後、IKErのノード２０とIKEiのノード１０とはIPsecトンネル確立処理を実行し、IKEiのノード１０は端末４０と、このIPsecトンネル経由で通信を行う。
【００４３】
このようにIKEiのノード１０は、IKErのノード２０の認証後に本IDを送信するので、なりすましのIKErのノード２０、IKEiのノード１０の本IDを取得することを防止できる。
【００４４】
次に、IKEiのノード１０、IKErのノード２０および認証サーバ３０の処理を説明する。まず、図８を用いて、IKEiのノード１０の処理を説明する。
【００４５】
＜IKEiのノードの処理手順＞
まず、IKEiのノード１０は、IPsecトンネルの確立先のIKErのノード２０のアドレスを取得する。そして、IKEiのノード１０は、このIKErのノード２０のアドレスと、リモートアクセス管理情報１３１（図５参照）とを参照して、このIKErのノード２０は、IKE＿AUTH1stメッセージで仮IDを用いることが可能なIKErのノード２０か否かを判断する（Ｓ２１：リモートアクセス管理情報において仮IDフラグＯｎのIKEr？）。ここで、このIKErのノード２０がIKE＿AUTH1stメッセージで仮IDを用いることが可能なIKErのノード２０であれば（Ｓ２１のＹｅｓ）、IKEiのノード１０のIKE＿AUTHメッセージ処理部１２１は、リモートアクセス管理情報１３１を参照して、このIKErのノード２０のアドレスに仮IDと本IDの設定があるか否かを判断する（Ｓ２２）。ここで、仮IDと本IDの設定があれば（Ｓ２２のＹｅｓ）、IKE＿AUTHメッセージ処理部１２１は、IKE＿AUTH1stメッセージにて仮IDをIKErのノード２０へ送信する（Ｓ２３）。
【００４６】
その後、IKEiのノード１０は、IKErのノード２０から受信したIKE＿AUTH2ndメッセージにて、認証サーバ３０から送信されたチャレンジ値（認証方式に用いる情報）と、IKErのノード２０のディジタル署名とを正常に受信できたとき（Ｓ２４のＹｅｓ）、認証処理部１２２により、このディジタル署名の認証を実行する（Ｓ２５）。そして、この認証の結果、レスポンダ認証ＯＫだったとき（Ｓ２６のＹｅｓ）、つまり、ディジタル署名によりIKErのノード２０の本人性が確認できたとき、認証情報作成部１２３はチャレンジ値を用いてハッシュ化パスワードを作成する。そして、IKE＿AUTHメッセージ処理部１２１は、IKE＿AUTH3rdメッセージにて、このIKEiのノード１０の本IDとハッシュ化パスワードとをIKErのノード２０へ送信する（Ｓ２７）。
【００４７】
その後、IKE＿AUTHメッセージ処理部１２１がIKE＿AUTH4thメッセージにて、IKErのノード２０の認証結果を正常に受信できたとき（Ｓ２８のＹｅｓ）、IKEiのノード１０は、IKE＿AUTH5thメッセージ以降、RFC4306に基づく動作を実行し（Ｓ２９）、IKErのノード２０との間にIPsecトンネルを確立する。
【００４８】
なお、図８のＳ２１で、IKEiのノード１０が、IKErのノード２０がIKE＿AUTH1stメッセージで仮IDを用いることができないIKErのノード２０と判断したとき（Ｓ２１のＮｏ）、および、Ｓ２２で、リモートアクセス管理情報１３１に、当該IKErのノード２０の仮IDまたは本IDしか設定がなかったとき、または、いずれのIDの設定もなかったとき（Ｓ２２のＮｏ）、処理をＳ３０へ進める。つまり、IKEiのノード１０は、RFC4306に基づき、図１のＳ３以降の動作を実行する（Ｓ３０）。
【００４９】
また、図８のＳ２４で、IKEiのノード１０が、IKErのノード２０から受信したIKE＿AUTH2ndメッセージにて、認証サーバ３０から送信されたチャレンジ値（認証方式に用いる情報）と、IKErのノード２０のディジタル署名を正常に受信できなかったとき（Ｓ２４のＮｏ）、および、Ｓ２８で、IKE＿AUTHメッセージ処理部１２１がIKE＿AUTH4thメッセージにて、IKErのノード２０の認証結果を正常に受信できなかったとき（Ｓ２８のＮｏ）、処理をＳ３２へ進める。すなわち、IKEiのノード１０は、リモートアクセス管理情報１３１における、当該IKErのノード２０に用いる仮IDの仮IDフラグをＯｆｆにする（Ｓ３２）。そして、処理を終了する。
【００５０】
さらに、図８のＳ２６において、IKEiのノード１０がIKErのノード２０の本人性が確認できなかったとき（Ｓ２６のＮｏ）、通常のレスポンダ認証失敗処理を実行する（Ｓ３１）。例えば、IKEiのノード１０は、IKErのノード２０の本人性が確認できなかったことを、出力装置等に出力する。そして、処理を終了する。
【００５１】
以上説明したIKEiのノード１０によれば、IKErのノード２０が自身のレスポンダであることを確認した上で、IKErのノード２０へ本IDを送信する。よって、なりすましのIKErのノード２０が、IKEiのノード１０の本IDを取得することを防止できる。
【００５２】
＜IKErのノードの処理手順＞
次に、図９を用いて、IKErのノード２０の処理手順を説明する。IKErのノード２０は、IKE＿AUTH1stメッセージにてIKEiのノード１０の仮IDを受信する（Ｓ４１）。そして、IKErのノード２０の仮ID判定部２２１は、ドメイン管理情報２３１を参照して、受信ID（仮IDのドメイン）が、ドメイン管理情報２３１上に存在し（Ｓ４２のＹｅｓ）、かつ、受信IDのドメインは、ドメイン管理情報２３１上で仮IDフラグがＯｎ（Ｓ４３のＹｅｓ）であることを確認すると、処理をＳ４４へ進める。つまり、IKErのノード２０は、通常の認証サーバ３０との連携とRFC4306に基づく動作を実行する（Ｓ４４）。すなわち、IKErのノード２０は、仮IDがドメイン管理情報２３１上に存在することを確認すると、図３のＳ１３〜Ｓ１９に基づき、IKEiのノード１０からIKE＿AUTH3rdメッセージを受信する。また、図４のIKErのノード２０のAccess-Request1stメッセージ処理部２２２は、IKE＿AUTH3rdメッセージにて、IKEiのノード１０のID（本ID）とハッシュ化パスワードを受信したとき（Ｓ４５のＹｅｓ）、以降、IKEiのノード１０のIDとして、このIKE＿AUTH3rdメッセージで受信したIDを用いて、RFC4306に基づく動作を実行する（Ｓ４６）。すなわち、図１のＳ３以降の処理と同様の処理を実行する。
【００５３】
一方、IKErのノード２０のAccess-Requestメッセージ処理部２２２は、IKE＿AUTH3rdメッセージにて、IKEiのノード１０のID（本ID）とハッシュ化パスワードを受信できなかったとき（Ｓ４５のＮｏ）、以降、IKEiのノード１０のIDとしてIKE＿AUTH1stメッセージで受信したIDを用い、通常の認証サーバ３０連携と、RFC4306に基づく動作を実行する（Ｓ４９）。すなわち、図１のＳ３以降の処理と同様の処理を実行する。
【００５４】
なお、Ｓ４２において、IKErのノード２０の仮ID判定部２２１が、ドメイン管理情報２３１を参照して、受信ID（仮IDのドメイン）が、ドメイン管理情報２３１上に存在しないと判定したとき（Ｓ４２のＮｏ）、このIDはIKErのノード２０のイニシエータであるIKEiのノード１０のIDではないことになるので、認証失敗処理を実行する（Ｓ４７）。つまり、IKErのノード２０は、IKE＿AUTH1stメッセージの送信元のIKEiのノード１０の認証に失敗したことを、出力装置等に出力する。そして、処理を終了する。
【００５５】
また、IKErのノード２０の仮ID判定部２２１は、受信IDのドメインが、ドメイン管理情報２３１上で仮IDフラグＯｎではないと判定したとき（Ｓ４３のＮｏ）、RFC4306に基づく処理を実行する。すなわち、図１のＳ３以降の処理と同様の処理を実行する。
【００５６】
＜認証サーバ＞
次に、図１０を用いて認証サーバ３０の処理手順を説明する。認証サーバ３０の認証部３２１（図４参照）は、Access-Request1stメッセージにて、IKEiのノード１０のIDを受信する（Ｓ５１）。そして、認証部３２１は、この受信IDがユーザ管理情報３３１（図７参照）上に存在するか否かを判断する（Ｓ５２）。ここで、受信IDがユーザ管理情報３３１上に存在すれば（Ｓ５２のＹｅｓ）、ユーザ管理情報３３１を参照して、このIDのIKEiのノード１０に対し用いる認証方式を選択する。そして、この選択した認証方式に従い処理を行う（Ｓ５３）。例えば、当該IKEiのノード１０の認証方式として、MD5-Challengeを選択した場合、認証部３２１は、IKErのノード２０へ、このIKEiのノード１０に用いるチャレンジ値をユーザ管理情報３３１から読み出し、IKErのノード２０へAccess-Challengeメッセージにより送信する（Ｓ５４）。
【００５７】
その後、認証処理部１２２は、IKErのノード２０からAccess-Request2ndにて、IKEiのノード１０のIDとハッシュ化パスワードを受信する（Ｓ５４）。そして、認証部３２１は、ユーザ管理情報３３１に示される当該IDのIKEiのノード１０のチャレンジ値を用いてハッシュ化パスワードからパスワードを取り出す。そして、Ｓ５４で受信した受信IDと、取り出したパスワードが、ユーザ管理情報３３１の本IDとパスワードに合致したか否か（つまり、認証に成功したか否か）を判断する（Ｓ５５）。ここで、受信IDと、取り出したパスワードが、ユーザ管理情報３３１の本IDとパスワードに合致するとき（Ｓ５５のＹｅｓ）、認証成功処理を実行する（Ｓ５６）。つまり、認証部３２１は、IKEiのノード１０の認証に成功したことを、Access-AcceptメッセージでIKErのノード２０へ送信する。一方、Ｓ５２で認証部３２１が、この受信IDはユーザ管理情報３３１上に存在しないと判断したとき（Ｓ５２のＮｏ）、および、Ｓ５５で受信IDとパスワードが、ユーザ管理情報３３１の本IDとパスワードに合致しないとき（つまり、認証に失敗したと判断したとき）（Ｓ５５のＮｏ）、認証失敗処理を行う（Ｓ５７）。例えば、認証処理部１２２は、IKEiのノード１０の認証に失敗したことをIKErのノード２０へ通知する。
【００５８】
このようにすることで、認証サーバ３０は、IKEiのノード１０が仮IDを用いる場合であっても、IKErのノード２０へ、このIKEiのノード１０の認証方式を通知したり、IKEiのノード１０の認証処理を実行したりすることができる。
【００５９】
以上説明した通信システムによれば、IKEv2において、IKErではないノードが、IKErになりすまして、IKEiのノード１０のIDを取得することを防止できる。
【００６０】
なお、前記した実施の形態において、ノード１０がIKEiのノードであり、ノード２０がIKErのノードである場合を例に説明したが、これに限定されない。例えば、通信システムで、IPsecトンネルの終端となるノードについて、IKEiのノードとしての機能とIKErのノードとしての機能の両方を備えるノード５０として構成してもよい。このノード５０の構成を、図１１に示す。前記した実施の形態と同様の構成要素は、同じ符号を付して説明を省略する。
【００６１】
図１１に示すように、このノード５０は、入出力部５１、処理部５２および記憶部５３を備える。そして、処理部５２は、認証処理部１２２、認証情報作成部１２３、仮ID判定部２２１、Access-Requestメッセージ処理部２２２、ディジタル署名生成部２２３に加え、IPsecトンネル処理部５２１、IKE＿AUTHメッセージ処理部５２２を備える。
【００６２】
このIPsecトンネル処理部５２１は、他のノード５０との間でIPsecトンネルを確立する。IKE＿AUTHメッセージ処理部５２２は、ノード１０のIKE＿AUTHメッセージ処理部１２１の機能と、ノード２０のIKE＿AUTHメッセージ処理部２２４の機能とを備える。つまり、IKE＿AUTHメッセージ処理部１２１は、自身がIKEiのノードとして動作するときにはIKE＿AUTHメッセージ処理部１２１と同様にIKErのノードに対しIKE＿AUTHメッセージを送信する。また、自身がIKErのノードとなるときにはIKE＿AUTHメッセージ処理部２２４と同様にIKEiのノードに対しIKE＿AUTHメッセージを送信する。また、記憶部５３は、ドメイン管理情報２３１およびリモートアクセス管理情報１３１を記憶する。つまり、自身がIKEiのノードとして動作するときには、リモートアクセス管理情報１３１を参照して、仮ＩＤおよび本ＩＤを選択する。また、自身がIKErのノードとして動作するときには、ドメイン管理情報２３１を参照して、受信ＩＤが仮ＩＤか本ＩＤかを判断し、認証サーバ３０の選択を行う。
【符号の説明】
【００６３】
１０，２０，５０ ノード
１１，２１，３１，５１ 入出力部
１２，２２，３２，５２ 処理部
１３，２３，３３，５３ 記憶部
３０ 認証サーバ
４０ 端末
１２１ IKE＿AUTHメッセージ処理部
１２２ 認証処理部
１２３ 認証情報作成部
１２４，２２５，５２１ IPsecトンネル処理部
１３１ リモートアクセス管理情報
２２１ 仮ID判定部
２２２ Access-Requestメッセージ処理部
２２３ ディジタル署名生成部
２２４，５２２ IKE＿AUTHメッセージ処理部
２３１ ドメイン管理情報
３２１ 認証部
３３１ ユーザ管理情報
【技術分野】
【０００１】
本発明は、IPsec（Internet Protocol Security）トンネリングに用いられるIKE（Internet Key Exchange）技術に関する。
【背景技術】
【０００２】
従来、インターネット上での通信セキュリティに関する技術として、IPsecトンネルがある（非特許文献１参照）。このIPsecトンネルを自動で確立するための技術としては、IETF RFC4306に規定されるIKEv2がある（非特許文献２参照）。本技術を用いることにより、接続しようとするIPsecトンネル終端装置間で、本人性認証を行うための情報の交換、IPsecトンネル内のIP通信を行うために利用するIPアドレス（プレフィックス）の割り当て、暗号化鍵の生成等を行って、セキュアなIPsecトンネルを確立することができる。なお、本人性の認証には、例えば、AAA（Authentication Authorization Accounting）サーバ等、認証サーバとの連携による実現も可能である。
【０００３】
これらの技術により、IKEv2イニシエータ（IKEi）のノードとIKEv2レスポンダ（IKEr）のノードとの間でIPsecトンネルを確立し、IKEiのノードは、このIPsecトンネル経由で通信相手の端末との間でセキュアな通信を行うことができる。
【０００４】
このことを、図１を用いて説明する。ここでは、IKEiのノードの認証方式として、MD5-Challengeを用いる場合を例に説明する。
【０００５】
IKEiのノードは、IKErのノードとの間で、IKE＿SA＿INIT（Internet Key Exchange＿Security Associationの初期情報）の交換を行う（Ｓ１）。つまり、IKEのための初期情報の交換を行う。そして、IKEiのノードは、自身のユーザIDを、IKE＿AUTH1stメッセージによりIKErのノードへ通知する（Ｓ２）。そして、IKErのノードは、通知されたユーザIDを元に認証サーバの選択を行い（Ｓ３）、その選択した認証サーバへ、このユーザIDを含むAccess-Request1stメッセージを送信する（Ｓ４）。認証サーバは、受信したAccess-Request1stメッセージに含まれるユーザIDを元に、このユーザIDの認証方式を選択し（Ｓ５）、選択した認証方式と、その認証方式に用いる情報（チャレンジ値）とを含むAccess-Challengeメッセージを、IKErのノードへ送信する（Ｓ６）。
【０００６】
そして、IKErのノードは、自身のディジタル署名と、チャレンジ値とを含むIKE＿AUTH2ndメッセージをIKEiのノードへ送信する（Ｓ７）。次に、IKEiのノードは、ディジタル署名に基づきIKErのノードの認証を行い（Ｓ８：レスポンダ認証）、その認証結果がOKだった場合、指定された認証方式に基づき、自身のパスワードをチャレンジ値でハッシュ化したハッシュ化パスワードをIKE＿AUTH3rdメッセージで送信する（Ｓ９）。そして、IKErのノードは、認証サーバへ、IKErのノードのハッシュ化パスワードをAccess-Request2ndメッセージにより送信する（Ｓ１０）。その後、認証サーバは、Access-Request1stメッセージで受信したIDのノードに関するチャレンジ値で、ハッシュ化パスワードからパスワードを取り出し、このパスワードが、当該ノードのパスワードであることを確認すると、その旨をAccess-AcceptメッセージでIKErのノードへ通知する。その後、IKErのノードはIKEiのノードとの間でIPsecトンネルを確立する。そして、IKEiのノードは、このIKErのノードとの間に確立されたIPsecトンネル経由で、通信相手の端末との間で通信を行う。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】IETF、RFC4301、[online]、[2010年2月10日検索]、インターネット、<URL: http://www.ietf.org/rfc/rfc4301.txt >
【非特許文献２】IETF、RFC4306、[online]、[2010年2月10日検索]、インターネット、<URL: http://www.ietf.org/rfc/rfc4306.txt >
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、前記した従来技術は、IKEiのノードがIKErの認証を完了する前に、IKErのノードへ、イニシエータID（IDi）を通知するものである。このため、本来、IKErではないノードが、IKErになりすまして、IKEiのノードのID（IDi）を取得する可能性がある。そこで、本発明は、前記した問題を解決し、本来、IKEv2において、IKErではないノードが、IKErになりすまして、IKEiのノードのIDを取得することを防止することを目的とする。
【課題を解決するための手段】
【０００９】
前記した課題を解決するため、本発明は、IKE（Internet Key Exchange）v2においてイニシエータとなるIKEiのノードと、IKEv2におけるレスポンダとなるIKErのノードと、IKErのノードからの認証要求に応じて認証処理を行う認証サーバとを含む通信システムに関する発明とした。この通信システムのIKEiのノードは、IKErのノードのＩＤごとに、IKEv2において、そのＩＤのIKErのノードに対し用いる自身のIKEiのノードの仮ＩＤおよび本ＩＤを示したリモートアクセス管理情報を記憶する。そして、IKEiのノードは、リモートアクセス管理情報から読み出した、IKErのノードに対し用いる仮ＩＤを含むIKE＿AUTH1stメッセージを、IKErのノードへ送信する。そして、IKErのノードは、IKEiのノードからのIKE＿AUTH1stメッセージを受信したとき、認証サーバへ、IKE＿AUTH1stメッセージに含まれる仮ＩＤのノードの認証に用いる認証方式を問い合わせるAccess-Request1stメッセージを送信する。次に、IKErのノードは、認証サーバから仮ＩＤのノードの認証に用いる認証方式を含む応答を受信し、自身のIKErのノードのディジタル署名を生成する。そして、IKErのノードは、受信した応答に含まれる認証方式と、自身のIKErのノードのディジタル署名とを含むIKE＿AUTH2ndメッセージをIKEiのノードへ送信する。次に、IKEiのノードは、IKErのノードから受信したIKE＿AUTH2ndメッセージに含まれるディジタル署名に基づきIKErのノードの認証処理を実行する。そして、IKEiのノードは、IKErのノードの認証ＯＫが確認されたとき、リモートアクセス管理情報から読み出したIKErのノードに対し用いる本ＩＤと認証方式の認証に用いる認証情報とを含むIKE＿AUTH3rdメッセージをIKErのノードへ送信する。次に、IKErのノードは、IKEiのノードから受信したIKE＿AUTH3rdメッセージに含まれる本ＩＤと認証方式の認証に用いる認証情報とをAccess-Request2ndメッセージに含めて、認証サーバへ送信する。そして、IKErのノードは、認証サーバから受信した、Access-Request2ndメッセージの応答がIKEiのノードの認証結果が認証ＯＫを示すものであるとき、IKEiのノードとの間にIPsecトンネルを確立する。
【００１０】
このようにIKEiのノードは、IKErのノードの認証を行う前に、IKErのノードへ自身の仮IDを通知する。そして、この仮IDの通知後、IKErのノードから送信されたIKE＿AUTH2ndメッセージに基づきIKErのノードの認証を行い、認証ＯＫだったときに、IKErのノードに対し本ID（このIKEiのノードのID）を通知する。よって、本来、IKErではないノードが、IKErになりすまして、IKEiのノードのIDを取得することを防止できる。
【００１１】
また、本発明の通信システムのIKErのノードは、IKEiのノードから受信したIKE＿AUTH3rdメッセージにＩＤが含まれていなかったとき、Access-Request1stに含まれるＩＤをAccess-Request2ndメッセージに含めて、認証サーバへ送信する。そして、認証サーバから受信した、Access-Request2ndメッセージの応答がIKEiのノードの認証結果が認証ＯＫを示すものであるとき、IKErのノードは、IKEiのノードとの間にIPsecトンネルを確立する。
【００１２】
このようにIKErのノードは、IKEiのノードからIKE＿AUTH3rdメッセージにIDが含まれていなかったときでも、IKE＿AUTH1stメッセージで受信したID（本IDまたは仮ID）を用いて認証サーバへ、Access-Request2ndメッセージを送信する。つまり、IKErのノードは、（１）IKE＿AUTH1stメッセージで本IDを受信した場合や、（２）IKE＿AUTH1stメッセージで仮IDを受信したが、その後IKE＿AUTH3rdメッセージで本IDを受信しなかった場合でも、IKE＿AUTH1stメッセージで受信したID（本IDまたは仮ID）を用いて、認証サーバへAccess-Request2ndメッセージを送信することができる。
【００１３】
また、本発明の通信システムの認証サーバは、ノードの仮ＩＤおよび本ＩＤと、ノードが用いる認証方式を含むユーザ管理情報を備える。そして、この認証サーバは、IKErのノードから、仮ＩＤを含むAccess-Request1stメッセージを受信したとき、ユーザ管理情報を参照して、仮ＩＤのノードの認証に用いる認証方式を含む応答をIKErのノードへ送信する。その後、認証サーバは、本ＩＤおよび認証情報を含むAccess-Request2ndメッセージを受信したとき、ユーザ管理情報を参照して、本ＩＤのノードの認証処理を行い、認証処理の認証結果をIKErのノードへ送信する。
【００１４】
このようにすることで、認証サーバは、Access-Requestメッセージに仮IDが含まれていた場合でも、本IDが含まれていた場合でも、そのIDのノードの認証に用いる認証方式および認証方式に用いる情報をIKErのノードへ送信することができる。
【発明の効果】
【００１５】
本発明によれば、IKEv2において、IKErではないノードが、IKErになりすまして、IKEiのノードのIDを取得することを防止できる。
【図面の簡単な説明】
【００１６】
【図１】比較例となるIKEv2における処理手順を示したシーケンス図である。
【図２】本実施の形態の通信システムの構成例を示した図である。
【図３】本実施の形態の通信システムの処理手順を示したシーケンス図である。
【図４】本実施の形態の通信システムの構成例を示した図である。
【図５】図４のリモートアクセス管理情報を例示した図である。
【図６】図４のドメイン管理情報を例示した図である。
【図７】図４のユーザ管理情報を例示した図である。
【図８】図４のIKEiのノードの処理手順を示した図である。
【図９】図４のIKErのノードの処理手順を示した図である。
【図１０】図４の認証サーバの処理手順を示した図である。
【図１１】本実施の形態の通信システムに用いられるノードの構成例を示した図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態を説明する。まず、図２を用いて本実施の形態の通信システムの構成例を説明する。通信システムは、ノード１０（１０Ａ，１０Ｂ），２０と、端末４０と、認証サーバ３０とを含んで構成される。ノード１０，２０は、ＩＰネットワーク経由で接続され、IPsecトンネルを確立する。そして、ノード１０，２０と通信相手である端末４０との間で、このIPsecトンネル経由での通信を行う。なお、このノード１０は、IPsecトンネル確立のためのIKEv2を実行する際、イニシエータ（IKEi）となるノードである。また、ノード２０は、このIKEv2を実行する際、レスポンダ（IKEr）となるノードである。このノード１０，２０はＩＰネットワーク経由で通信可能なコンピュータやルータにより実現される。認証サーバ３０は、このIKEiのノード１０を認証するための認証方式やこの認証方式に用いる各種情報を記憶するサーバであり、IKErのノード２０に接続される。IKErのノード２０は、この認証サーバ３０によりIKEiのノード１０の認証を行う。
【００１８】
次に、図３を用いて通信システムの処理の概要を説明する。ここでは概略説明のため、図３の説明を一部を省略する。まず、IKEiのノード１０は、IKErのノード２０との間でIKE＿SA＿INITの交換を行った後（Ｓ１１）、IKE＿AUTH1stメッセージによりIKErのノード２０へ仮IDを通知する（Ｓ１２）。この仮IDは、自身のノード１０の本当のユーザＩＤを示す本IDの送信前に使う仮のユーザIDである。
【００１９】
その後、IKEiのノード１０は、IKErのノード２０からIKE＿AUTH2ndメッセージを受信すると（Ｓ１７）、このIKE＿AUTH2ndメッセージにより受信したIKErのノード２０のディジタル署名に基づき、IKErのノード２０の認証を行う（Ｓ１８：レスポンダ認証）。そして、このIKErのノード２０の本人性の認証ができたとき、IKE＿AUTH3rdメッセージにより、このIKEiのノード１０の本IDをIKErのノード２０へ通知する（Ｓ１９）。つまり、IKEiのノード１０は、IKErのノード２０の本人性の認証ができてから、このIKEiのノード１０の本IDをIKErのノード２０へ送信する。よって、本来、このIKEiのノード１０のIKErではないノードが、IKErになりすまして、IKEiのノードのIDを取得することを防止できる。図３の処理の詳細は、後記する。
【００２０】
＜構成＞
次に、図４を用いて、通信システムを構成するノード１０，２０、認証サーバ３０の構成を説明する。ノード１０，２０、認証サーバ３０はそれぞれ、入出力部、処理部および記憶部を備える。
【００２１】
図４の各入出力部は、ＩＰネットワーク経由でデータを送受信可能な通信インタフェースや入出力インタフェースから構成される。また、各処理部は、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。さらに、各記憶部は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ等の記憶媒体から構成される。なお、ノード１０，２０、認証サーバ３０をプログラム実行処理により実現する場合、各記憶部には、ノード１０，２０や認証サーバ３０の機能を実現するためのプログラムが格納される。
【００２２】
＜IKEiのノード＞
まず、IKEiのノード１０を説明する。IKEiのノード１０は、入出力部１１、処理部１２および記憶部１３を備える。まず、記憶部１３から説明する。記憶部１３は、リモートアクセス管理情報１３１を記憶する。このリモートアクセス管理情報１３１は、IKErのノード２０のID（例えば、IKErのノード２０のアドレスのドメイン）ごとに、このIKErのノード２０が仮IDを用いてIKEv2のIKE＿AUTH1stメッセージを送信してもよいノードか否かを示すフラグと、仮IDを用いてIKE＿AUTH1stメッセージを送信してもよいノードであるとき、このノードに対し用いる仮IDおよび本IDとを示した情報である（図５参照）。
【００２３】
例えば、図５に示すリモートアクセス管理情報１３１において、IKErのノード２０が「fqdn.ntt.co.jp」であるとき、このノードに対しては仮IDを用いることができ（フラグ「On」）、そのとき用いる自身のノードの仮IDは「md5-user-1@vpn1-remote.net」であり、本IDは「alice@ntt.co.jp」であることを示す。このリモートアクセス管理情報１３１は、入出力部１１経由で更新可能である。例えば、図５に示す「No2」の情報において、仮IDのフラグは「Off」となっているが、仮IDを用いるようにしたい場合、このフラグを「On」に変更し、仮IDの欄に仮IDとして用いるIDを記述すればよい。このリモートアクセス管理情報１３１は、IKEiのノード１０が、IKE＿AUTH1stメッセージやIKE＿AUTH3rdメッセージを送信する際に参照される。
【００２４】
次に、図４の処理部１２を説明する。処理部１２は、主にIKErのノード２０との間でIKE＿AUTHメッセージの送受信を行い、IKErのノード２０の認証処理を行う。この処理部１２は、IKE＿AUTHメッセージ処理部１２１と、認証処理部１２２と、認証情報作成部１２３と、IPsecトンネル処理部１２４とを備える。
【００２５】
IKE＿AUTHメッセージ処理部１２１は、入出力部１１経由で、このIKEiのノード１０のレスポンダであるIKErのノード２０のアドレスの入力を受け付ける。そして、IKE＿AUTHメッセージ処理部１２１は、リモートアクセス管理情報１３１と、このIKErのノード２０のアドレスとを参照して、このIKErのノード２０に対し用いる仮IDを読み出す。そして、IKE＿AUTHメッセージ処理部１２１は、この読み出した仮IDを含むIKE＿AUTH1stメッセージを作成し、IKErのノード２０へ送信する。また、このIKE＿AUTHメッセージ処理部１２１は、IKErのノード２０へのIKE＿AUTH1stメッセージ送信後、認証処理部１２２により、このIKErのノードの認証ＯＫが確認されたとき、リモートアクセス管理情報１３１から、このIKErのノード２０に対し用いる本IDを読み出す。そして、このIKE＿AUTHメッセージ処理部１２１は、この本IDと、このIKEiのノード１０の認証に用いる認証情報（詳細は後記）を含むIKE＿AUTH3rdメッセージをIKErのノード２０へ送信する。
【００２６】
認証処理部１２２は、入出力部１１経由で、IKErのノード２０から受信したIKE＿AUTH2ndメッセージに含まれるディジタル署名に基づきIKErのノード２０の本人性の認証を行う。
【００２７】
認証情報作成部１２３は、IKErのノード２０から受信したIKE＿AUTH2ndメッセージで指定された認証方式に従い、自身のIKEiのノードの認証情報を作成する。例えば、このIKE＿AUTH2ndメッセージで指定された認証方式がMD5-Challengeであり、このメッセージによりMD5-Challengeに用いられるチャレンジ値が送信されてきたとき、このチャレンジ値を用いて、自身のパスワードをハッシュ化したハッシュ化パスワードを作成する。なお、このIKEiのノード１０のパスワードとチャレンジ値とは認証サーバ３０側にも記憶されている。そして、認証サーバ３０が、IKErのノード２０経由で、IKEiのノード１０のハッシュ化パスワードを受信し、このハッシュ化パスワードからパスワードを取り出し、、このパスワードが、自身の記憶するパスワードと同じとき、認証サーバ３０は、このIKEiのノード１０が確かにノード１０であると判断する。
【００２８】
IPsecトンネル処理部１２４は、認証処理部１２２において認証がとれたIKErのノード２０との間でIPsecトンネルを確立する。
【００２９】
＜IKErのノード＞
次に、IKErのノード２０を説明する。IKErのノード２０は、入出力部２１、処理部２２および記憶部２３を備える。まず、記憶部２３から説明する。この記憶部２３は、ドメイン管理情報２３１を記憶する。このドメイン管理情報２３１は、IKEiのノード１０のID（例えば、IKEiのノード１０のアドレスのドメイン）ごとに、当該IDが本IDか仮IDかを示すフラグと、そのIDのIKEiのノード１０からのIKE＿AUTHメッセージを受信したとき、そのIKEiのノード１０の認証方法を問い合わせる認証サーバ３０のアドレスを示した情報である。例えば、図６に示すドメイン管理情報２３１において、IKEiのノード１０から「vpn1-remote.net」というドメインを持つIDをIKE＿AUTHメッセージで受信したとき、このIDは仮IDであり（フラグＯｎ）、このIDのIKEiのノード１０の認証方法の問い合わせ先の認証サーバ３０のアドレスは「1100::1」であることを示す。このドメイン管理情報２３１は、入出力部２１経由で更新される。このドメイン管理情報２３１は、図４の仮ID判定部２２１（後記）において、IKEiのノード１０から送信されたIDが本IDか仮IDかを判定するときや、IKEiのノード１０の認証方法の問い合わせ先である認証サーバ３０を選択するときに参照される。
【００３０】
次に、処理部２２を説明する。処理部２２は、仮ID判定部２２１と、Access-Requestメッセージ処理部２２２と、ディジタル署名生成部２２３と、IKE＿AUTHメッセージ処理部２２４と、IPsecトンネル処理部２２５とを備える。
【００３１】
仮ID判定部２２１は、入出力部２１経由で、IKEiのノード１０からIKE＿AUTH1stメッセージを受信すると、ドメイン管理情報２３１を参照して、この受信したIKE＿AUTH1stメッセージに含まれるIDが仮IDであるか本IDかを判定する。
【００３２】
Access-Requestメッセージ処理部２２２は、仮ID判定部２２１によりIKE＿AUTH1stメッセージに含まれるIDが仮IDと判定されたとき、認証サーバ３０へ、この仮IDを含むAccess-Request1stメッセージを送信する。つまり、Access-Requestメッセージ処理部２２２は、このAccess-Request1stメッセージにより、認証サーバ３０へ、この仮IDのノードの認証に用いる認証方式を問い合わせる。また、Access-Requestメッセージ処理部２２２は、IKEiのノード１０からIKE＿AUTH3rdメッセージを受信したとき、このIKE＿AUTH3rdメッセージに含まれるIKEiのノード１０の本IDおよび認証情報（例えば、ハッシュ化パスワード）をAccess-Request2ndメッセージにより、認証サーバ３０へ送信する。つまり、Access-Requestメッセージ処理部２２２は、このAccess-Request2ndメッセージにより、認証サーバ３０へ、当該本IDのIKEiのノード１０の認証を依頼する。
【００３３】
ディジタル署名生成部２２３は、認証サーバ３０からAccess-Requestメッセージの応答を受信したとき、自身のIKErのノード２０のディジタル署名を生成する。
【００３４】
IKE＿AUTHメッセージ処理部２２４は、認証サーバ３０からのAccess-Requestメッセージの応答に含まれる認証方式と、その認証方式に用いる情報と、自身のディジタル署名とを含むIKE＿AUTH2ndメッセージを、IKE＿AUTH1stメッセージの送信元のIKEiのノード１０へ送信する。これにより、IKErのノード２０は、IKEiのノード１０へ、自身のディジタル署名と、IKEiのノード１０の認証情報を作成するときの認証方式と、その認証方式に用いる情報とを通知することができる。なお、ここで当該認証方式に用いる情報が特になければ、その情報をIKE＿AUTH2nd含めなくてもよい。
【００３５】
IPsecトンネル処理部２２５は、認証サーバ３０から受信した、Access-Request2ndメッセージの応答がIKEiのノード１０の認証ＯＫを示すものであるとき、IKEiのノード１０との間にIPsecトンネルを確立する。
【００３６】
＜認証サーバ＞
次に、認証サーバ３０を説明する。認証サーバ３０は、入出力部３１、処理部３２および記憶部３３を備える。まず、記憶部３３から説明する。この記憶部３３は、ユーザ管理情報３３１を記憶する。ユーザ管理情報３３１は、図７に示すように、IKEiのノード１０の仮IDおよび本IDと、このIKEiのノード１０が用いる認証方式と、その認証方式に用いる情報とを示した情報である。なお、図７のユーザ管理情報３３１は、認証方式が、MD5-Challengeであるノード１０に発行するチャレンジ値（発行Challenge)、パスワード等を含む。このチャレンジ値は、この値がMD5-Challengeに用いられるチャレンジ値であることを示す識別情報を含む。これにより、IKEiのノード１０は、この値がMD5-Challengeに用いられるチャレンジ値であることを判断できる。このユーザ管理情報３３１は、図４の入出力部３１経由で更新される。また、このユーザ管理情報３３１は、認証部３２１（後記）が、IKEiのノード１０の認証方式やその認証方式に用いる情報（チャレンジ値等）を選択するとき等に参照される。
【００３７】
処理部３２は、認証部３２１を備える。この認証部３２１は、IKErのノード２０から、ノード１０の仮IDを含むAccess-Request1stメッセージを受信したとき、ユーザ管理情報３３１を参照して、この仮IDのノード１０の認証に用いる認証方式を選択する。そして、この選択した認証方式を含む応答をIKErのノード２０へ送信する。また、この認証部３２１は、IKErのノード２０から、ノード１０の本IDおよび認証情報を含むAccess-Request2ndメッセージを受信したとき、この認証情報とユーザ管理情報３３１とを参照して、本IDのノード１０の認証処理を行う。そして、認証部３２１は、この認証処理の認証結果をIKErのノード２０へ送信する。例えば、認証部３２１は、IKEiのノード１０の本IDとハッシュ化パスワードを受信すると、ユーザ管理情報３３１に示される当該本IDのチャレンジ値を用いて、このハッシュ化パスワードのパスワードを取り出す。そして、この取り出したパスワードが、ユーザ管理情報３３１に示される当該本IDのパスワードと同じであれば、そのIKEiのノード１０を認証ＯＫ（本人性の認証が取れた）と判断し、その認証結果をAccess-Request2ndメッセージの送信元のIKErのノード２０へ送信する。
【００３８】
次に、図３の処理を詳細に説明する。まず、IKEiのノード１０は、IKErのノード２０との間でIKE＿SA＿INITの交換を行う（Ｓ１１）。そして、IKEiのノード１０のIKE＿AUTHメッセージ処理部１２１（図４参照）は、このIKErのノード２０に対し用いる仮IDをリモートアクセス管理情報１３１（図５参照）から読み出し、IKE＿AUTH1stメッセージにより通知する（Ｓ１２）。
【００３９】
次に、IKErのノード２０は、入出力部２１経由でIKE＿AUTH1stメッセージを受信すると、このIKE＿AUTH1stメッセージに含まれる仮IDをキーとしてドメイン管理情報２３１（図６参照）を参照して、認証サーバ３０の選択を行う（Ｓ１３）。そして、この選択した認証サーバ３０へ、この仮IDを含むAccess-Request1stを送信する（Ｓ１４）。
【００４０】
認証サーバ３０は、受信したAccess-Request1stに含まれる仮IDをキーとして、ユーザ管理情報３３１から、IKEiのノード１０の認証方式の選択を行う（Ｓ１５）。また、このユーザ管理情報３３１から、この認証方式に用いる情報（例えば、MD5-Challengeのチャレンジ値）を読み出し、この選択した認証方式とその認証方式に用いる情報とをAccess-Challengeメッセージに含めてIKErのノード２０へ送信する（Ｓ１６）。IKErのノード２０は、このAccess-Challengeメッセージを受信すると、自身のディジタル署名を生成する。そして、IKErのノード２０は、このディジタル署名と、Access-Challengeに含まれる認証方式、その認証方式に用いる情報とをIKE＿AUTH2ndメッセージによりIKEiのノード１０へ送信する（Ｓ１７）。
【００４１】
IKEiのノード１０は、IKErのノード２０からIKE＿AUTH2ndメッセージを受信すると、このIKE＿AUTH2ndメッセージに含まれるIKErのノード２０のディジタル署名をもとに、このIKErのノード２０の認証を行う（Ｓ１８：レスポンダ認証）。そして、認証ＯＫだったとき（つまり、IKErのノード２０の本人性が確認できたとき）、IKE＿AUTH3rdメッセージにより、このIKEiのノード１０の本IDを通知する（Ｓ１９）。また、このとき、IKEiのノード１０は、IKE＿AUTH2ndメッセージにより通知された認証方式に従い、その認証方式に用いる情報（チャレンジ値）を用いて、IKEiのノード１０の認証情報を作成する。例えば、チャレンジ値を用いてこのIKEiのノード１０のパスワードをハッシュ化する。そして、IKE＿AUTH3rdメッセージに、このIKEiのノード１０の認証情報を含めてIKErのノード２０へ送信する。
【００４２】
このIKE＿AUTH3rdを受信したIKErのノード２０は、IKEiのノード１０の認証情報および本IDを含むAccess-Request2ndメッセージを認証サーバ３０へ送信する（Ｓ２０）。そして、認証サーバ３０は、このAccess-Request2ndメッセージに含まれる認証情報および本IDとを用いて、IKEiのノード１０の認証処理を行う。そして、その結果、このIKEiのノード１０が認証ＯＫだったとき、その旨をAccess-AcceptメッセージでIKErのノード２０へ送信する。その後、IKErのノード２０とIKEiのノード１０とはIPsecトンネル確立処理を実行し、IKEiのノード１０は端末４０と、このIPsecトンネル経由で通信を行う。
【００４３】
このようにIKEiのノード１０は、IKErのノード２０の認証後に本IDを送信するので、なりすましのIKErのノード２０、IKEiのノード１０の本IDを取得することを防止できる。
【００４４】
次に、IKEiのノード１０、IKErのノード２０および認証サーバ３０の処理を説明する。まず、図８を用いて、IKEiのノード１０の処理を説明する。
【００４５】
＜IKEiのノードの処理手順＞
まず、IKEiのノード１０は、IPsecトンネルの確立先のIKErのノード２０のアドレスを取得する。そして、IKEiのノード１０は、このIKErのノード２０のアドレスと、リモートアクセス管理情報１３１（図５参照）とを参照して、このIKErのノード２０は、IKE＿AUTH1stメッセージで仮IDを用いることが可能なIKErのノード２０か否かを判断する（Ｓ２１：リモートアクセス管理情報において仮IDフラグＯｎのIKEr？）。ここで、このIKErのノード２０がIKE＿AUTH1stメッセージで仮IDを用いることが可能なIKErのノード２０であれば（Ｓ２１のＹｅｓ）、IKEiのノード１０のIKE＿AUTHメッセージ処理部１２１は、リモートアクセス管理情報１３１を参照して、このIKErのノード２０のアドレスに仮IDと本IDの設定があるか否かを判断する（Ｓ２２）。ここで、仮IDと本IDの設定があれば（Ｓ２２のＹｅｓ）、IKE＿AUTHメッセージ処理部１２１は、IKE＿AUTH1stメッセージにて仮IDをIKErのノード２０へ送信する（Ｓ２３）。
【００４６】
その後、IKEiのノード１０は、IKErのノード２０から受信したIKE＿AUTH2ndメッセージにて、認証サーバ３０から送信されたチャレンジ値（認証方式に用いる情報）と、IKErのノード２０のディジタル署名とを正常に受信できたとき（Ｓ２４のＹｅｓ）、認証処理部１２２により、このディジタル署名の認証を実行する（Ｓ２５）。そして、この認証の結果、レスポンダ認証ＯＫだったとき（Ｓ２６のＹｅｓ）、つまり、ディジタル署名によりIKErのノード２０の本人性が確認できたとき、認証情報作成部１２３はチャレンジ値を用いてハッシュ化パスワードを作成する。そして、IKE＿AUTHメッセージ処理部１２１は、IKE＿AUTH3rdメッセージにて、このIKEiのノード１０の本IDとハッシュ化パスワードとをIKErのノード２０へ送信する（Ｓ２７）。
【００４７】
その後、IKE＿AUTHメッセージ処理部１２１がIKE＿AUTH4thメッセージにて、IKErのノード２０の認証結果を正常に受信できたとき（Ｓ２８のＹｅｓ）、IKEiのノード１０は、IKE＿AUTH5thメッセージ以降、RFC4306に基づく動作を実行し（Ｓ２９）、IKErのノード２０との間にIPsecトンネルを確立する。
【００４８】
なお、図８のＳ２１で、IKEiのノード１０が、IKErのノード２０がIKE＿AUTH1stメッセージで仮IDを用いることができないIKErのノード２０と判断したとき（Ｓ２１のＮｏ）、および、Ｓ２２で、リモートアクセス管理情報１３１に、当該IKErのノード２０の仮IDまたは本IDしか設定がなかったとき、または、いずれのIDの設定もなかったとき（Ｓ２２のＮｏ）、処理をＳ３０へ進める。つまり、IKEiのノード１０は、RFC4306に基づき、図１のＳ３以降の動作を実行する（Ｓ３０）。
【００４９】
また、図８のＳ２４で、IKEiのノード１０が、IKErのノード２０から受信したIKE＿AUTH2ndメッセージにて、認証サーバ３０から送信されたチャレンジ値（認証方式に用いる情報）と、IKErのノード２０のディジタル署名を正常に受信できなかったとき（Ｓ２４のＮｏ）、および、Ｓ２８で、IKE＿AUTHメッセージ処理部１２１がIKE＿AUTH4thメッセージにて、IKErのノード２０の認証結果を正常に受信できなかったとき（Ｓ２８のＮｏ）、処理をＳ３２へ進める。すなわち、IKEiのノード１０は、リモートアクセス管理情報１３１における、当該IKErのノード２０に用いる仮IDの仮IDフラグをＯｆｆにする（Ｓ３２）。そして、処理を終了する。
【００５０】
さらに、図８のＳ２６において、IKEiのノード１０がIKErのノード２０の本人性が確認できなかったとき（Ｓ２６のＮｏ）、通常のレスポンダ認証失敗処理を実行する（Ｓ３１）。例えば、IKEiのノード１０は、IKErのノード２０の本人性が確認できなかったことを、出力装置等に出力する。そして、処理を終了する。
【００５１】
以上説明したIKEiのノード１０によれば、IKErのノード２０が自身のレスポンダであることを確認した上で、IKErのノード２０へ本IDを送信する。よって、なりすましのIKErのノード２０が、IKEiのノード１０の本IDを取得することを防止できる。
【００５２】
＜IKErのノードの処理手順＞
次に、図９を用いて、IKErのノード２０の処理手順を説明する。IKErのノード２０は、IKE＿AUTH1stメッセージにてIKEiのノード１０の仮IDを受信する（Ｓ４１）。そして、IKErのノード２０の仮ID判定部２２１は、ドメイン管理情報２３１を参照して、受信ID（仮IDのドメイン）が、ドメイン管理情報２３１上に存在し（Ｓ４２のＹｅｓ）、かつ、受信IDのドメインは、ドメイン管理情報２３１上で仮IDフラグがＯｎ（Ｓ４３のＹｅｓ）であることを確認すると、処理をＳ４４へ進める。つまり、IKErのノード２０は、通常の認証サーバ３０との連携とRFC4306に基づく動作を実行する（Ｓ４４）。すなわち、IKErのノード２０は、仮IDがドメイン管理情報２３１上に存在することを確認すると、図３のＳ１３〜Ｓ１９に基づき、IKEiのノード１０からIKE＿AUTH3rdメッセージを受信する。また、図４のIKErのノード２０のAccess-Request1stメッセージ処理部２２２は、IKE＿AUTH3rdメッセージにて、IKEiのノード１０のID（本ID）とハッシュ化パスワードを受信したとき（Ｓ４５のＹｅｓ）、以降、IKEiのノード１０のIDとして、このIKE＿AUTH3rdメッセージで受信したIDを用いて、RFC4306に基づく動作を実行する（Ｓ４６）。すなわち、図１のＳ３以降の処理と同様の処理を実行する。
【００５３】
一方、IKErのノード２０のAccess-Requestメッセージ処理部２２２は、IKE＿AUTH3rdメッセージにて、IKEiのノード１０のID（本ID）とハッシュ化パスワードを受信できなかったとき（Ｓ４５のＮｏ）、以降、IKEiのノード１０のIDとしてIKE＿AUTH1stメッセージで受信したIDを用い、通常の認証サーバ３０連携と、RFC4306に基づく動作を実行する（Ｓ４９）。すなわち、図１のＳ３以降の処理と同様の処理を実行する。
【００５４】
なお、Ｓ４２において、IKErのノード２０の仮ID判定部２２１が、ドメイン管理情報２３１を参照して、受信ID（仮IDのドメイン）が、ドメイン管理情報２３１上に存在しないと判定したとき（Ｓ４２のＮｏ）、このIDはIKErのノード２０のイニシエータであるIKEiのノード１０のIDではないことになるので、認証失敗処理を実行する（Ｓ４７）。つまり、IKErのノード２０は、IKE＿AUTH1stメッセージの送信元のIKEiのノード１０の認証に失敗したことを、出力装置等に出力する。そして、処理を終了する。
【００５５】
また、IKErのノード２０の仮ID判定部２２１は、受信IDのドメインが、ドメイン管理情報２３１上で仮IDフラグＯｎではないと判定したとき（Ｓ４３のＮｏ）、RFC4306に基づく処理を実行する。すなわち、図１のＳ３以降の処理と同様の処理を実行する。
【００５６】
＜認証サーバ＞
次に、図１０を用いて認証サーバ３０の処理手順を説明する。認証サーバ３０の認証部３２１（図４参照）は、Access-Request1stメッセージにて、IKEiのノード１０のIDを受信する（Ｓ５１）。そして、認証部３２１は、この受信IDがユーザ管理情報３３１（図７参照）上に存在するか否かを判断する（Ｓ５２）。ここで、受信IDがユーザ管理情報３３１上に存在すれば（Ｓ５２のＹｅｓ）、ユーザ管理情報３３１を参照して、このIDのIKEiのノード１０に対し用いる認証方式を選択する。そして、この選択した認証方式に従い処理を行う（Ｓ５３）。例えば、当該IKEiのノード１０の認証方式として、MD5-Challengeを選択した場合、認証部３２１は、IKErのノード２０へ、このIKEiのノード１０に用いるチャレンジ値をユーザ管理情報３３１から読み出し、IKErのノード２０へAccess-Challengeメッセージにより送信する（Ｓ５４）。
【００５７】
その後、認証処理部１２２は、IKErのノード２０からAccess-Request2ndにて、IKEiのノード１０のIDとハッシュ化パスワードを受信する（Ｓ５４）。そして、認証部３２１は、ユーザ管理情報３３１に示される当該IDのIKEiのノード１０のチャレンジ値を用いてハッシュ化パスワードからパスワードを取り出す。そして、Ｓ５４で受信した受信IDと、取り出したパスワードが、ユーザ管理情報３３１の本IDとパスワードに合致したか否か（つまり、認証に成功したか否か）を判断する（Ｓ５５）。ここで、受信IDと、取り出したパスワードが、ユーザ管理情報３３１の本IDとパスワードに合致するとき（Ｓ５５のＹｅｓ）、認証成功処理を実行する（Ｓ５６）。つまり、認証部３２１は、IKEiのノード１０の認証に成功したことを、Access-AcceptメッセージでIKErのノード２０へ送信する。一方、Ｓ５２で認証部３２１が、この受信IDはユーザ管理情報３３１上に存在しないと判断したとき（Ｓ５２のＮｏ）、および、Ｓ５５で受信IDとパスワードが、ユーザ管理情報３３１の本IDとパスワードに合致しないとき（つまり、認証に失敗したと判断したとき）（Ｓ５５のＮｏ）、認証失敗処理を行う（Ｓ５７）。例えば、認証処理部１２２は、IKEiのノード１０の認証に失敗したことをIKErのノード２０へ通知する。
【００５８】
このようにすることで、認証サーバ３０は、IKEiのノード１０が仮IDを用いる場合であっても、IKErのノード２０へ、このIKEiのノード１０の認証方式を通知したり、IKEiのノード１０の認証処理を実行したりすることができる。
【００５９】
以上説明した通信システムによれば、IKEv2において、IKErではないノードが、IKErになりすまして、IKEiのノード１０のIDを取得することを防止できる。
【００６０】
なお、前記した実施の形態において、ノード１０がIKEiのノードであり、ノード２０がIKErのノードである場合を例に説明したが、これに限定されない。例えば、通信システムで、IPsecトンネルの終端となるノードについて、IKEiのノードとしての機能とIKErのノードとしての機能の両方を備えるノード５０として構成してもよい。このノード５０の構成を、図１１に示す。前記した実施の形態と同様の構成要素は、同じ符号を付して説明を省略する。
【００６１】
図１１に示すように、このノード５０は、入出力部５１、処理部５２および記憶部５３を備える。そして、処理部５２は、認証処理部１２２、認証情報作成部１２３、仮ID判定部２２１、Access-Requestメッセージ処理部２２２、ディジタル署名生成部２２３に加え、IPsecトンネル処理部５２１、IKE＿AUTHメッセージ処理部５２２を備える。
【００６２】
このIPsecトンネル処理部５２１は、他のノード５０との間でIPsecトンネルを確立する。IKE＿AUTHメッセージ処理部５２２は、ノード１０のIKE＿AUTHメッセージ処理部１２１の機能と、ノード２０のIKE＿AUTHメッセージ処理部２２４の機能とを備える。つまり、IKE＿AUTHメッセージ処理部１２１は、自身がIKEiのノードとして動作するときにはIKE＿AUTHメッセージ処理部１２１と同様にIKErのノードに対しIKE＿AUTHメッセージを送信する。また、自身がIKErのノードとなるときにはIKE＿AUTHメッセージ処理部２２４と同様にIKEiのノードに対しIKE＿AUTHメッセージを送信する。また、記憶部５３は、ドメイン管理情報２３１およびリモートアクセス管理情報１３１を記憶する。つまり、自身がIKEiのノードとして動作するときには、リモートアクセス管理情報１３１を参照して、仮ＩＤおよび本ＩＤを選択する。また、自身がIKErのノードとして動作するときには、ドメイン管理情報２３１を参照して、受信ＩＤが仮ＩＤか本ＩＤかを判断し、認証サーバ３０の選択を行う。
【符号の説明】
【００６３】
１０，２０，５０ ノード
１１，２１，３１，５１ 入出力部
１２，２２，３２，５２ 処理部
１３，２３，３３，５３ 記憶部
３０ 認証サーバ
４０ 端末
１２１ IKE＿AUTHメッセージ処理部
１２２ 認証処理部
１２３ 認証情報作成部
１２４，２２５，５２１ IPsecトンネル処理部
１３１ リモートアクセス管理情報
２２１ 仮ID判定部
２２２ Access-Requestメッセージ処理部
２２３ ディジタル署名生成部
２２４，５２２ IKE＿AUTHメッセージ処理部
２３１ ドメイン管理情報
３２１ 認証部
３３１ ユーザ管理情報
【特許請求の範囲】
【請求項１】
IKE（Internet Key Exchange）v2においてイニシエータとなるIKEiのノードと、前記IKEv2におけるレスポンダとなるIKErのノードと、前記IKErのノードからの認証要求に応じて認証処理を行う認証サーバとを含む通信システムにおける通信方法であって、
前記IKErのノードのＩＤごとに、前記IKEv2において、前記ＩＤのIKErのノードに対し用いる自身のIKEiのノードの仮ＩＤおよび本ＩＤを示したリモートアクセス管理情報を記憶する記憶部を備える前記IKEiのノードは、
前記リモートアクセス管理情報から読み出した、前記IKErのノードに対し用いる前記仮ＩＤを含むIKE＿AUTH1stメッセージを、前記IKErのノードへ送信し、
前記IKErのノードは、
前記IKEiのノードからのIKE＿AUTH1stメッセージを受信したとき、
前記認証サーバへ、前記IKE＿AUTH1stメッセージに含まれる仮ＩＤのノードの認証に用いる認証方式を問い合わせるAccess-Request1stメッセージを送信し、
前記認証サーバから前記仮ＩＤのノードの認証に用いる認証方式を含む応答を受信し、前記自身のIKErのノードのディジタル署名を生成し、
前記受信した応答に含まれる認証方式と、前記自身のIKErのノードのディジタル署名とを含むIKE＿AUTH2ndメッセージを前記IKEiのノードへ送信し、
前記IKEiのノードは、
前記IKErのノードから受信した前記IKE＿AUTH2ndメッセージに含まれるディジタル署名に基づき前記IKErのノードの認証処理を実行し、前記IKErのノードの認証ＯＫが確認されたとき、前記リモートアクセス管理情報から読み出した前記IKErのノードに対し用いる本ＩＤと前記認証方式の認証に用いる認証情報とを含むIKE＿AUTH3rdメッセージを前記IKErのノードへ送信し、
前記IKErのノードは、
前記IKEiのノードから受信した前記IKE＿AUTH3rdメッセージに含まれる前記本ＩＤと前記認証方式の認証に用いる認証情報とをAccess-Request2ndメッセージに含めて、前記認証サーバへ送信し、
前記認証サーバから受信した、前記Access-Request2ndメッセージの応答が前記IKEiのノードの認証結果が認証ＯＫを示すものであるとき、前記IKEiのノードとの間にIPsecトンネルを確立することを特徴とする通信方法。
【請求項２】
前記IKErのノードは、
前記IKEiのノードから受信した前記IKE＿AUTH3rdメッセージに前記ＩＤが含まれていなかったとき、前記Access-Request1stに含まれるＩＤをAccess-Request2ndメッセージに含めて、前記認証サーバへ送信し、
前記認証サーバから受信した、前記Access-Request2ndメッセージの応答が前記IKEiのノードの認証結果が認証ＯＫを示すものであるとき、前記IKEiのノードとの間にIPsecトンネルを確立することを特徴とする請求項１に記載の通信方法。
【請求項３】
前記認証サーバは、
前記ノードの仮ＩＤおよび本ＩＤと、前記ノードが用いる認証方式を含むユーザ管理情報を備え、
前記IKErのノードから、前記仮ＩＤを含むAccess-Request1stメッセージを受信したとき、前記ユーザ管理情報を参照して、前記仮ＩＤのノードの認証に用いる認証方式を含む応答を前記IKErのノードへ送信し、
前記本ＩＤおよび認証情報を含むAccess-Request2ndメッセージを受信したとき、前記ユーザ管理情報を参照して、前記本ＩＤのノードの認証処理を行い、前記認証処理の認証結果をIKErのノードへ送信することを特徴とする請求項１または請求項２に記載の通信方法。
【請求項４】
IKE（Internet Key Exchange）v2においてイニシエータとなるIKEiのノードと、前記IKEv2におけるレスポンダとなるIKErのノードと、前記IKErのノードからの認証要求に応じて認証処理を行う認証サーバとを含む通信システムであって、
前記IKEiのノードは、
前記IKErのノードのＩＤごとに、前記IKEv2において、前記ＩＤのIKErのノードに対し用いる自身のIKEiのノードの仮ＩＤおよび本ＩＤを示したリモートアクセス管理情報を記憶する記憶部と、
前記リモートアクセス管理情報から読み出した、前記IKErのノードに対し用いる前記仮ＩＤを含むIKE＿AUTH1stメッセージを、前記IKErのノードへ送信し、認証処理部により前記IKErのノードの認証ＯＫが確認されたとき、前記リモートアクセス管理情報から読み出した前記IKErのノードに対し用いる本ＩＤと前記作成した認証情報を含むIKE＿AUTH3rdメッセージを前記IKErのノードへ送信する第１のIKE＿AUTHメッセージ処理部と、
前記IKErのノードから受信したIKE＿AUTH2ndメッセージに含まれる認証方式に従い前記IKEiのノードの認証情報を作成する認証情報作成部と、
前記IKErのノードから受信した前記IKE＿AUTH2ndメッセージに含まれるディジタル署名に基づき前記IKErのノードの認証処理を実行する前記認証処理部と、
前記IKErのノードとの間にIPsecトンネルを確立する第１のIPsecトンネル処理部とを備え、
前記IKErのノードは、
（１）認証サーバへ、前記IKE＿AUTH1stメッセージに含まれる前記仮ＩＤノードの認証に用いる認証方式を問い合わせるAccess-Request1stを送信し、（２）前記IKEiのノードから前記IKE＿AUTH3rdメッセージを受信したとき、前記IKE＿AUTH3rdに含まれる前記本ＩＤおよび前記IKEiのノードの認証情報をAccess-Request2ndメッセージに含めて、前記認証サーバへ送信する、Access-Requestメッセージ処理部と、
前記認証サーバから、前記Access-Request1stの応答を受信したとき、前記自身のIKErのノードのディジタル署名を生成するディジタル署名生成部と、
前記受信したAccess-Request1stの応答に含まれる認証方式と、前記自身のIKErのノードのディジタル署名とを含む前記IKE＿AUTH2ndメッセージを前記IKEiのノードへ送信する第２のIKE＿AUTHメッセージ処理部と、
前記認証サーバから受信した、前記Access-Request2ndメッセージの応答が前記IKEiのノードの認証結果が認証ＯＫを示すものであるとき、前記IKEiのノードとの間にIPsecトンネルを確立する第２のIPsecトンネル処理部とを備えることを特徴とする通信システム。
【請求項１】
IKE（Internet Key Exchange）v2においてイニシエータとなるIKEiのノードと、前記IKEv2におけるレスポンダとなるIKErのノードと、前記IKErのノードからの認証要求に応じて認証処理を行う認証サーバとを含む通信システムにおける通信方法であって、
前記IKErのノードのＩＤごとに、前記IKEv2において、前記ＩＤのIKErのノードに対し用いる自身のIKEiのノードの仮ＩＤおよび本ＩＤを示したリモートアクセス管理情報を記憶する記憶部を備える前記IKEiのノードは、
前記リモートアクセス管理情報から読み出した、前記IKErのノードに対し用いる前記仮ＩＤを含むIKE＿AUTH1stメッセージを、前記IKErのノードへ送信し、
前記IKErのノードは、
前記IKEiのノードからのIKE＿AUTH1stメッセージを受信したとき、
前記認証サーバへ、前記IKE＿AUTH1stメッセージに含まれる仮ＩＤのノードの認証に用いる認証方式を問い合わせるAccess-Request1stメッセージを送信し、
前記認証サーバから前記仮ＩＤのノードの認証に用いる認証方式を含む応答を受信し、前記自身のIKErのノードのディジタル署名を生成し、
前記受信した応答に含まれる認証方式と、前記自身のIKErのノードのディジタル署名とを含むIKE＿AUTH2ndメッセージを前記IKEiのノードへ送信し、
前記IKEiのノードは、
前記IKErのノードから受信した前記IKE＿AUTH2ndメッセージに含まれるディジタル署名に基づき前記IKErのノードの認証処理を実行し、前記IKErのノードの認証ＯＫが確認されたとき、前記リモートアクセス管理情報から読み出した前記IKErのノードに対し用いる本ＩＤと前記認証方式の認証に用いる認証情報とを含むIKE＿AUTH3rdメッセージを前記IKErのノードへ送信し、
前記IKErのノードは、
前記IKEiのノードから受信した前記IKE＿AUTH3rdメッセージに含まれる前記本ＩＤと前記認証方式の認証に用いる認証情報とをAccess-Request2ndメッセージに含めて、前記認証サーバへ送信し、
前記認証サーバから受信した、前記Access-Request2ndメッセージの応答が前記IKEiのノードの認証結果が認証ＯＫを示すものであるとき、前記IKEiのノードとの間にIPsecトンネルを確立することを特徴とする通信方法。
【請求項２】
前記IKErのノードは、
前記IKEiのノードから受信した前記IKE＿AUTH3rdメッセージに前記ＩＤが含まれていなかったとき、前記Access-Request1stに含まれるＩＤをAccess-Request2ndメッセージに含めて、前記認証サーバへ送信し、
前記認証サーバから受信した、前記Access-Request2ndメッセージの応答が前記IKEiのノードの認証結果が認証ＯＫを示すものであるとき、前記IKEiのノードとの間にIPsecトンネルを確立することを特徴とする請求項１に記載の通信方法。
【請求項３】
前記認証サーバは、
前記ノードの仮ＩＤおよび本ＩＤと、前記ノードが用いる認証方式を含むユーザ管理情報を備え、
前記IKErのノードから、前記仮ＩＤを含むAccess-Request1stメッセージを受信したとき、前記ユーザ管理情報を参照して、前記仮ＩＤのノードの認証に用いる認証方式を含む応答を前記IKErのノードへ送信し、
前記本ＩＤおよび認証情報を含むAccess-Request2ndメッセージを受信したとき、前記ユーザ管理情報を参照して、前記本ＩＤのノードの認証処理を行い、前記認証処理の認証結果をIKErのノードへ送信することを特徴とする請求項１または請求項２に記載の通信方法。
【請求項４】
IKE（Internet Key Exchange）v2においてイニシエータとなるIKEiのノードと、前記IKEv2におけるレスポンダとなるIKErのノードと、前記IKErのノードからの認証要求に応じて認証処理を行う認証サーバとを含む通信システムであって、
前記IKEiのノードは、
前記IKErのノードのＩＤごとに、前記IKEv2において、前記ＩＤのIKErのノードに対し用いる自身のIKEiのノードの仮ＩＤおよび本ＩＤを示したリモートアクセス管理情報を記憶する記憶部と、
前記リモートアクセス管理情報から読み出した、前記IKErのノードに対し用いる前記仮ＩＤを含むIKE＿AUTH1stメッセージを、前記IKErのノードへ送信し、認証処理部により前記IKErのノードの認証ＯＫが確認されたとき、前記リモートアクセス管理情報から読み出した前記IKErのノードに対し用いる本ＩＤと前記作成した認証情報を含むIKE＿AUTH3rdメッセージを前記IKErのノードへ送信する第１のIKE＿AUTHメッセージ処理部と、
前記IKErのノードから受信したIKE＿AUTH2ndメッセージに含まれる認証方式に従い前記IKEiのノードの認証情報を作成する認証情報作成部と、
前記IKErのノードから受信した前記IKE＿AUTH2ndメッセージに含まれるディジタル署名に基づき前記IKErのノードの認証処理を実行する前記認証処理部と、
前記IKErのノードとの間にIPsecトンネルを確立する第１のIPsecトンネル処理部とを備え、
前記IKErのノードは、
（１）認証サーバへ、前記IKE＿AUTH1stメッセージに含まれる前記仮ＩＤノードの認証に用いる認証方式を問い合わせるAccess-Request1stを送信し、（２）前記IKEiのノードから前記IKE＿AUTH3rdメッセージを受信したとき、前記IKE＿AUTH3rdに含まれる前記本ＩＤおよび前記IKEiのノードの認証情報をAccess-Request2ndメッセージに含めて、前記認証サーバへ送信する、Access-Requestメッセージ処理部と、
前記認証サーバから、前記Access-Request1stの応答を受信したとき、前記自身のIKErのノードのディジタル署名を生成するディジタル署名生成部と、
前記受信したAccess-Request1stの応答に含まれる認証方式と、前記自身のIKErのノードのディジタル署名とを含む前記IKE＿AUTH2ndメッセージを前記IKEiのノードへ送信する第２のIKE＿AUTHメッセージ処理部と、
前記認証サーバから受信した、前記Access-Request2ndメッセージの応答が前記IKEiのノードの認証結果が認証ＯＫを示すものであるとき、前記IKEiのノードとの間にIPsecトンネルを確立する第２のIPsecトンネル処理部とを備えることを特徴とする通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１１−１７６４６９（Ｐ２０１１−１７６４６９Ａ）
【公開日】平成２３年９月８日（２０１１．９．８）
【国際特許分類】
【出願番号】特願２０１０−３７７４７（Ｐ２０１０−３７７４７）
【出願日】平成２２年２月２３日（２０１０．２．２３）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２３年９月８日（２０１１．９．８）
【国際特許分類】
【出願日】平成２２年２月２３日（２０１０．２．２３）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]