JP2007310619A - 認証方式及びこれを用いた認証システム - Google Patents

Abstract

【課題】ＫＤＣのＩＰアドレスを事前に設定すること無く、セキュリティ面で安全な相互認証を異なるレルム間で行うことが可能な認証方式及びこれを用いた認証システムを実現する。
【解決手段】互いに異なるレルムに所属する端末の間でＫｅｒｂｅｒｏｓ認証方式を用いて認証を行う認証方式であって、一方のレルムに所属する端末が異なるレルムに所属する端末との間で認証を得るために一方のレルムにある鍵配布センターに対して異なるレルムにある鍵配布センターへアクセスするためのチケット認可チケットを要求し、一方のレルムにある鍵配布センターが要求のあったチケット認可チケットと共に暗号化された異なるレルムにある鍵配布センターのＩＰアドレスを一方のレルムに所属する端末に送信する。
【選択図】 図１

Description

本発明は、ネットワーク上で利用される認証方式及びこれを用いた認証システムに関し、特に異なるレルム（認証の管理権限の単位）間で鍵配布センター（Key Distribution Center：以下、ＫＤＣと呼ぶ。）のＩＰ（Internet Protocol）アドレスを事前に端末に設定すること無く、セキュリティ面で安全な相互認証が可能な認証方式及びこれを用いた認証システムに関する。

従来のインターネット等の汎用のネットワーク上で認証を行う認証方式としてはＫｅｒｂｅｒｏｓ認証（マサチューセッツ工科大学のＡｔｈｅｎａプロジェクトで開発されたネットワーク上で利用される認証方式）が存在し、Ｋｅｒｂｅｒｏｓ認証に関連する先行技術文献としては次のようなものがある。

特開２００３−０９９４０１号公報 特開２００４−１７８３６１号公報 特開２００５−０１８７４８号公報

Ｋｅｒｂｅｒｏｓ認証におけるＫＤＣは１つ以上のコンピュータから構成され、通常、認証サーバ（Authentication Server：以下、ＡＳと呼ぶ。）とチケット認可サーバ（Ticket Granting Server：以下、ＴＧＳと呼ぶ。）の機能がそれぞれ動作する。

ＡＳは端末からの要求に対し、チケット認可チケット（端末自身を証明するための証明書：Ticket Granting Ticket：以下、ＴＧＴと呼ぶ。）を発行する。ＴＧＳはサーバ等が提供するサービスを利用するためのサービスチケットを発行する。

図６はこのような従来の認証方式を用いた認証システムの一例を示す構成ブロック図である。図６において１は他の端末との間で相互認証を行おうとする端末、２及び５は端末１の相互認証の対象である端末、３及び４はＫＤＣ、６はＫＤＣのＩＰアドレスを提供するＤＮＳ（Domain Name System）サーバである。

また、端末１、端末２及びＫＤＣ３はレルム１００を構成し、ＫＤＣ４及び端末５はレルム１０１を構成している。端末１はネットワーク等を介して端末２、ＫＤＣ３、ＫＤＣ４、端末５及びＤＮＳサーバ６と相互に接続される。

ここで、図６に示す従来例の動作を図７及び図８を用いて説明する。図７は同一レルムの認証サービスを受ける時の動作を説明するメッセージフロー図、図８は異なるレルム間で認証サービスを受ける時の動作を説明するメッセージフロー図である。

端末１が端末２の提供するサービスを受ける時の認証処理の手順を図７を用いて説明する。端末−ＫＤＣ間及び端末−端末間のデータの送受信において、実際はＫｅｒｂｅｒｏｓプロトコルに従ったメッセージで行われ、ＴＧＴやサービスチケットもこのメッセージに含まれて送受信されているが、説明の簡単のために以下の説明においては省略する。

図７中”Ｓ００１”において端末１はＴＧＴＡをＫＤＣ３のＡＳへ要求する。図７中”Ｓ００２”においてＫＤＣ３のＡＳはＴＧＴ要求に対して、端末１とＫＤＣ３のＴＧＳとの間での通信で使用されるセッション鍵（以下、”セッション鍵Ａ”と呼ぶ。）が含まれたＴＧＴＡをＫＤＣ３のＴＧＳの秘密鍵（以下、”秘密鍵Ａ”と呼ぶ。）で暗号化し（以下、”暗号化ＴＧＴＡ”と呼ぶ。）、さらに、”セッション鍵Ａ”を端末１の秘密鍵（以下、”秘密鍵Ｂ”と呼ぶ。）で暗号化して”暗号化ＴＧＴＡ”と共に端末１へ送信する。

端末１は”暗号化ＴＧＴＡ”と暗号化された”セッション鍵Ａ”を受信し、暗号化された”セッション鍵Ａ”を”秘密鍵Ｂ”で復号化して”セッション鍵Ａ”を取得する。もし、暗号化された”セッション鍵Ａ”を受信したのが端末１でなければ、”秘密鍵Ｂ”を持っていないため、復号化することができず、”セッション鍵Ａ”を取得することができない。

そのため、端末１が”セッション鍵Ａ”を取得した時点で、ＫＤＣ３のＡＳによる”端末１の認証”の処理が完了する。

そして、図７中”Ｓ００３”において端末１は”セッション鍵Ａ”で暗号化した認証子、”暗号化ＴＧＴＡ”及び端末２の名前等の識別子をＫＤＣ３のＴＧＳへ送信して、サービスチケットＡ（端末１がＫＤＣ３によって認証されていることを証明するための証明書）を要求する。端末１が生成する認証子は、端末１の名前、ＩＰアドレス及び現在時刻等から構成される。

ＫＤＣ３のＴＧＳは”セッション鍵Ａ”で暗号化した認証子、”暗号化ＴＧＴＡ”及び端末２の名前等の識別子を受信し、”秘密鍵Ａ”で”暗号化ＴＧＴＡ”を復号化する。復号化したＴＧＴＡから”セッション鍵Ａ”を取得し、この”セッション鍵Ａ”で暗号化された端末１の認証子を復号化する。

そして、ＫＤＣ３のＴＧＳは復号化されたＴＧＴＡと端末１の認証子を比較し、ＴＧＴＡで証明されている端末が端末１であることを確認する。図７中”Ｓ００４”においてＫＤＣ３のＴＧＳはサービスチケット要求に対して、端末１と端末２との間での通信で使用されるセッション鍵（以下、”セッション鍵Ｂ”と呼ぶ。）が含まれたサービスチケットＡを端末２の秘密鍵（以下、”秘密鍵Ｃ”と呼ぶ。）で暗号化し（以下、”暗号化サービスチケットＡ”と呼ぶ。）、さらに、”セッション鍵Ｂ”を”セッション鍵Ａ”で暗号化して”暗号化サービスチケットＡ”と共に端末１へ送信する。

端末１は”暗号化サービスチケットＡ”と暗号化された”セッション鍵Ｂ”を受信し、暗号化された”セッション鍵Ｂ”を”セッション鍵Ａ”で復号化して”セッション鍵Ｂ”を取得する。もし、暗号化された”セッション鍵Ｂ”を受信したのが端末１でなければ、”セッション鍵Ａ”を持っていないため、復号化することができず、”セッション鍵Ｂ”を取得することができない。

そのため、端末１が”セッション鍵Ｂ”を取得した時点で、ＫＤＣ３のＴＧＳによる”端末１の認証”の処理が完了する。

そして、図７中”Ｓ００５”において端末１は”セッション鍵Ｂ”で暗号化した認証子、”暗号化サービスチケットＡ”を端末２へ送信して、端末２が提供するサービスを要求する。

最後に、図７中”Ｓ００６”において端末２は”秘密鍵Ｃ”で”暗号化サービスチケットＡ”を復号化し、”セッション鍵Ｂ”を取得して暗号化された端末１の認証子を復号化する。端末２は復号化されたサービスチケットＡと端末１の認証子を比較し、サービスチケットＡで証明されている端末が端末１であることを確認する。

次に端末１が異なるレルムにある端末５の提供するサービスを受ける時の認証処理の手順を図８を用いて説明する。図８中”Ｓ１０１”において端末１はＴＧＴＡをＫＤＣ３のＡＳへ要求する。図８中”Ｓ１０２”においてＫＤＣ３のＡＳはＴＧＴ要求に対して、”セッション鍵Ａ”が含まれたＴＧＴＡを”秘密鍵Ａ”で暗号化し、さらに、”セッション鍵Ａ”を”秘密鍵Ｂ”で暗号化して”暗号化ＴＧＴＡ”と共に端末１へ送信する。

端末１は”暗号化ＴＧＴＡ”と暗号化された”セッション鍵Ａ”を受信し、暗号化された”セッション鍵Ａ”を”秘密鍵Ｂ”で復号化して”セッション鍵Ａ”を取得する。もし、暗号化された”セッション鍵Ａ”を受信したのが端末１でなければ、”秘密鍵Ｂ”を持っていないため、復号化することができず、”セッション鍵Ａ”を取得することができない。

そのため、端末１が”セッション鍵Ａ”を取得した時点で、ＫＤＣ３のＡＳによる”端末１の認証”の処理が完了する。

図８中”Ｓ１０３”において端末１は”セッション鍵Ａ”で暗号化した認証子、”暗号化ＴＧＴＡ”及びＫＤＣ４の名前等の識別子をＫＤＣ３のＴＧＳへ送信して、ＫＤＣ４へアクセスするためのＴＧＴを要求する。

ＫＤＣ３のＴＧＳは”セッション鍵Ａ”で暗号化した認証子、”暗号化ＴＧＴＡ”及びＫＤＣ４の名前等の識別子を受信し、”秘密鍵Ａ”で”暗号化ＴＧＴＡ”を復号化する。復号化したＴＧＴＡから”セッション鍵Ａ”を取得し、この”セッション鍵Ａ”で暗号化された端末１の認証子を復号化する。

そして、ＫＤＣ３のＴＧＳは復号化されたＴＧＴＡと端末１の認証子を比較し、ＴＧＴＡで証明されている端末が端末１であることを確認する。図８中”Ｓ１０４”においてＫＤＣ３のＴＧＳはＫＤＣ４へアクセスするためのＴＧＴ要求に対して、端末１とＫＤＣ４との間での通信で使用されるセッション鍵（以下、”セッション鍵Ｃ”と呼ぶ。）が含まれたＴＧＴＢをＫＤＣ４の秘密鍵（以下、”秘密鍵Ｄ”と呼ぶ。）で暗号化し（以下、”暗号化ＴＧＴＢ”と呼ぶ。）、さらに、”セッション鍵Ｃ”を”セッション鍵Ａ”で暗号化して”暗号化ＴＧＴＢ”と共に端末１へ送信する。

端末１は”暗号化ＴＧＴＢ”と暗号化された”セッション鍵Ｃ”を受信し、暗号化された”セッション鍵Ｃ”を”セッション鍵Ａ”で復号化して”セッション鍵Ｃ”を取得する。もし、暗号化された”セッション鍵Ｃ”を受信したのが端末１でなければ、”セッション鍵Ａ”を持っていないため、復号化することができず、”セッション鍵Ｃ”を取得することができない。

そのため、端末１が”セッション鍵Ｃ”を取得した時点で、ＫＤＣ３のＴＧＳによる”端末１の認証”の処理が完了する。

そして、図８中”Ｓ１０５”において端末１は”セッション鍵Ｃ”で暗号化した認証子、”暗号化ＴＧＴＢ”及び端末５の名前等の識別子をＫＤＣ４のＴＧＳへ送信して、サービスチケットＢ（端末１がＫＤＣ４によって認証されていることを証明するための証明書）を要求する。

ＫＤＣ４のＴＧＳは”セッション鍵Ｃ”で暗号化した認証子、”暗号化ＴＧＴＢ”及び端末２の名前等の識別子を受信し、”秘密鍵Ｄ”で”暗号化ＴＧＴＢ”を復号化する。復号化したＴＧＴＢから”セッション鍵Ｃ”を取得し、この”セッション鍵Ｃ”で暗号化された端末１の認証子を復号化する。

そして、ＫＤＣ４のＴＧＳは復号化されたＴＧＴＢと端末１の認証子を比較し、ＴＧＴＢで証明されている端末が端末１であることを確認する。図８中”Ｓ１０６”においてＫＤＣ４のＴＧＳはサービスチケットＢ要求に対して、端末１と端末５との間での通信で使用されるセッション鍵（以下、”セッション鍵Ｄ”と呼ぶ。）が含まれたサービスチケットＢを端末５の秘密鍵（以下、”秘密鍵Ｅ”と呼ぶ。）で暗号化し（以下、”暗号化サービスチケットＢ”と呼ぶ。）、さらに、”セッション鍵Ｄ”を”セッション鍵Ｃ”で暗号化して”暗号化サービスチケットＢ”と共に端末１へ送信する。

端末１は”暗号化サービスチケットＢ”と暗号化された”セッション鍵Ｄ”を受信し、暗号化された”セッション鍵Ｄ”を”セッション鍵Ｃ”で復号化して”セッション鍵Ｄ”を取得する。もし、暗号化された”セッション鍵Ｄ”を受信したのが端末１でなければ、”セッション鍵Ｃ”を持っていないため、復号化することができず、”セッション鍵Ｄ”を取得することができない。

そのため、端末１が”セッション鍵Ｄ”を取得した時点で、ＫＤＣ４のＴＧＳによる”端末１の認証”の処理が完了する。

そして、図８中”Ｓ１０７”において端末１は”セッション鍵Ｄ”で暗号化した認証子、”暗号化サービスチケットＢ”を端末５へ送信して、端末５が提供するサービスを要求する。

最後に、図８中”Ｓ１０８”において端末５は”秘密鍵Ｅ”で”暗号化サービスチケットＢ”を復号化し、”セッション鍵Ｄ”を取得して暗号化された端末１の認証子を復号化する。端末５は復号化されたサービスチケットと端末１の認証子を比較し、サービスチケットＢで証明されている端末が端末１であることを確認する。

異なるレルム間で認証サービスを受ける場合には、端末１は事前にＫＤＣ４のＩＰアドレスが設定されているか、若しくは、図６に示すようにＤＮＳサーバ６から取得する。

この結果、端末１がレルム１０１にあるＫＤＣ４へアクセスするためのＴＧＴＢをＫＤＣ３のＡＳから取得し、このＴＧＴＢを用いて端末５へのサービスチケットＢをＫＤＣ４のＴＧＳから取得し、このサービスチケットＢを用いて端末５へ認証を要求することにより、レルム１００に所属する端末１がレルム１０１に所属する端末５に認証されるので、異なるレルム間で相互に認証を行うことが可能になる。

図６に示す従来例では、レルム１００に所属する端末１がレルム１０１に所属する端末５にアクセスするためには、レルム１０１にあるＫＤＣ４と通信しなければならず、その際に端末１は事前にＫＤＣ４のＩＰアドレスが設定されているか、若しくは、ＤＮＳサーバ６から取得しなければならない。

しかし、事前にＫＤＣ４のＩＰアドレスを設定する場合には、端末の数が増えてくると設定にかかる工数が膨大になり、さらに、ＫＤＣ４のＩＰアドレスが変更される度に再設定しなければならないという問題点があった。

また、ＫＤＣ４のＩＰアドレスをＤＮＳサーバ６から取得する場合には、事前にＫＤＣ４のＩＰアドレスを設定する必要は無いが、セキュリティ面で安全ではないという問題点があった。

従って本発明が解決しようとする課題は、ＫＤＣのＩＰアドレスを事前に端末に設定すること無く、セキュリティ面で安全な相互認証を異なるレルム間で行うことが可能な認証方式及びこれを用いた認証システムを実現することにある。

このような課題を達成するために、本発明のうち請求項１記載の発明は、
互いに異なるレルムに所属する端末の間でＫｅｒｂｅｒｏｓ認証方式を用いて認証を行う認証方式であって、
一方のレルムに所属する端末が異なるレルムに所属する端末との間で認証を得るために前記一方のレルムにある鍵配布センターに対して前記異なるレルムにある鍵配布センターへアクセスするためのチケット認可チケットを要求し、前記一方のレルムにある鍵配布センターが要求のあった前記チケット認可チケットと共に暗号化された前記異なるレルムにある鍵配布センターのＩＰアドレスを前記一方のレルムに所属する端末に送信し、前記一方のレルムに所属する端末が前記ＩＰアドレスに基づき前記異なるレルムにある鍵配布センターにアクセスしてサービスチケットの提供を受け、前記異なるレルムに所属する端末が前記サービスチケットを用いて前記一方のレルムに所属する端末の認証を行うことにより、鍵配布センターのＩＰアドレスを事前に端末に設定すること無く、セキュリティ面で安全な相互認証を異なるレルム間で行うことが可能になる。

請求項２記載の発明は、
互いに異なるレルムに所属する端末の間でＫｅｒｂｅｒｏｓ認証方式を用いて認証を行う認証システムにおいて、
異なるレルムに所属する端末との間で認証を得るために前記異なるレルムにある鍵配布センターへアクセスするためのチケット認可チケットを要求する一方のレルムに所属する端末と、前記要求のあった前記チケット認可チケットと共に暗号化された前記異なるレルムにある鍵配布センターのＩＰアドレスを前記一方のレルムに所属する端末へ送信する前記一方のレルムにある鍵配布センターと、前記一方のレルムに所属する端末が取得した前記チケット認可チケットに基づきサービスチケットを提供する前記異なるレルムにある鍵配布センターと、前記異なるレルムに所属し前記サービスチケットを用いて前記一方のレルムに所属する端末の認証を行う端末とを備えたことにより、鍵配布センターのＩＰアドレスを事前に端末に設定すること無く、セキュリティ面で安全な相互認証を異なるレルム間で行うことが可能になる。

請求項３記載の発明は、
互いに異なるレルムに所属する端末の間でＫｅｒｂｅｒｏｓ認証方式を用いて認証を行う認証システムにおいて、
複数の異なるレルムにそれぞれ所属する複数の端末のうち任意の端末との間で認証を得るために前記任意の端末が所属するレルムにある鍵配布センターへアクセスするためのチケット認可チケットを要求する一方のレルムに所属する端末と、前記複数の異なるレルムにそれぞれある複数の鍵配布センターのＩＰアドレスの中から前記任意の端末が所属するレルムの鍵配布センターのＩＰアドレスを選択し前記要求のあった前記チケット認可チケットと共に暗号化された前記異なるレルムにある鍵配布センターのＩＰアドレスを前記一方のレルムに所属する端末へ送信する一方のレルムにある鍵配布センターと、前記一方のレルムに所属する端末が取得した前記チケット認可チケットに基づきサービスチケットを提供する前記任意の端末が所属するレルムにある鍵配布センターと、前記サービスチケットを用いて前記一方のレルムに所属する端末の認証を行う前記任意の端末とを備えたことにより、鍵配布センターのＩＰアドレスを事前に端末に設定すること無く、セキュリティ面で安全な相互認証を異なるレルム間で行うことが可能になる。

請求項４記載の発明は、
互いに異なるレルムに所属する端末の間でＫｅｒｂｅｒｏｓ認証方式を用いて認証を行う認証システムにおいて、
第３のレルムに所属する第２の端末との間で認証を得るために前記第３のレルムにある第３の鍵配布センターへアクセスするためのチケット認可チケットを第１のレルムにある第１の鍵配布センター若しくは第２のレルムにある第２の鍵配布センターに要求する前記第１のレルムに所属する第１の端末と、前記要求のあった前記チケット認可チケットと共に暗号化された前記第２の鍵配布センターのＩＰアドレスを前記第１の端末へ送信する前記第１の鍵配布センターと、前記要求のあった前記チケット認可チケットと共に暗号化された前記第３の鍵配布センターのＩＰアドレスを前記第１の端末へ送信する前記第２の鍵配布センターと、前記第１の端末が前記第２の鍵配布センターから取得した前記チケット認可チケットに基づきサービスチケットを提供する前記第３の鍵配布センターと、前記サービスチケットを用いて前記第１の端末の認証を行う前記第２の端末とを備えたことにより、鍵配布センターのＩＰアドレスを事前に端末に設定すること無く、セキュリティ面で安全な相互認証を異なるレルム間で行うことが可能になる。

本発明によれば次のような効果がある。
請求項１，２，３及び請求項４の発明によれば、チケット認可チケットと共に暗号化された異なるレルムにある鍵配布センターのＩＰアドレスを端末に送信することにより、鍵配布センターのＩＰアドレスを事前に端末に設定すること無く、セキュリティ面で安全な相互認証を異なるレルム間で行うことが可能になる。

以下本発明を図面を用いて詳細に説明する。図１は本発明に係る認証方式及びこれを用いた認証システムの一実施例を示す構成ブロック図である。

図１において７は他の端末との間で相互認証を行おうとする端末、８及び１０はＫＤＣ、９は端末７の相互認証の対象である端末である。また、端末７及びＫＤＣ８はレルム１０２を構成し、端末９及びＫＤＣ１０はレルム１０３を構成している。端末７はネットワーク等を介してＫＤＣ８、端末９及びＫＤＣ１０と相互に接続される。

ここで、図１に示す実施例の動作を図２を用いて説明する。図２は異なるレルム間で認証サービスを受ける時の動作を説明するメッセージフロー図である。

図１に示す実施例の動作は図６及び図８の実施例とほぼ同一であり、異なる点はＴＧＴ要求に対するＴＧＴ応答メッセージの暗号化部分に異なるレルムにあるＫＤＣのＩＰアドレスを埋め込んだことである。

また、以下の説明において、端末−ＫＤＣ間及び端末−端末間の暗号化の詳細な説明は図８と同じため、省略する。

端末７が異なるレルムにある端末９の提供するサービスを受ける時の認証処理の手順を図２を用いて説明する。図２中”Ｓ２０１”において端末７はＴＧＴをＫＤＣ８のＡＳへ要求する。図２中”Ｓ２０２”においてＫＤＣ８のＡＳはＴＧＴ要求に対して応答し、ＴＧＴを含んだＴＧＴ応答メッセージを端末７へ送信する。

端末７は端末９がＫＤＣ１０の管理下にあることを予め認識しているので、図２中”Ｓ２０３”において端末７はＫＤＣ１０へアクセスするためのＴＧＴをＫＤＣ８のＴＧＳへ要求する。図２中”Ｓ２０４”においてＫＤＣ８のＴＧＳはＴＧＴ要求に対して応答し、暗号化部分にＫＤＣ１０のＩＰアドレスを埋め込んだＴＧＴ応答メッセージを端末７へ送信する。

そして、図２中”Ｓ２０５”において端末７は取得したＴＧＴ応答メッセージより暗号化されたＫＤＣ１０のＩＰアドレスを抽出して復号化し、ＴＧＴをＫＤＣ１０のＴＧＳへ送信して、端末７がＫＤＣ１０によって認証されていることを証明するための証明書であるサービスチケットを要求する。図２中”Ｓ２０６”においてＫＤＣ１０のＴＧＳはサービスチケット要求に対して応答し、サービスチケットを端末７へ送信する。

図２中”Ｓ２０７”において端末７は図２中”Ｓ２０６”において取得したサービスチケットを端末９へ送信して認証を要求する。最後に、図２中”Ｓ２０８”においてサービスチケットを確認した端末９は端末７を認証する。

この結果、レルム１０３にあるＫＤＣ１０のＩＰアドレスが暗号化部分に埋め込まれたＴＧＴ応答メッセージを端末７がＫＤＣ８のＴＧＳから取得し、暗号化されたＫＤＣ１０のＩＰアドレスを抽出して復号化することにより、端末７はＫＤＣ１０のＩＰアドレスを安全に取得できる。さらに、このＴＧＴを用いて端末９へのサービスチケットをＫＤＣ１０のＴＧＳから取得し、このサービスチケットを用いて端末９へ認証を要求し、端末７が端末９に認証されることにより、ＫＤＣ１０のＩＰアドレスを事前に端末７に設定すること無く、セキュリティ面で安全な相互認証を異なるレルム間で行うことが可能になる。

図３は本発明に係る認証方式及びこれを用いた認証システムの他の実施例を示す構成ブロック図である。

図３において１１は他の端末との間で相互認証を行おうとする端末、１２，１４及び１６はＫＤＣ、１３及び１５は端末１１の相互認証の対象である端末である。また、端末１１及びＫＤＣ１２はレルム１０４を構成し、端末１３及びＫＤＣ１４はレルム１０５を構成している。端末１５及びＫＤＣ１６はレルム１０６を構成している。

端末１１はネットワーク等を介してＫＤＣ１２、端末１３、ＫＤＣ１４、端末１５及びＫＤＣ１６と相互に接続される。

ここで、図３に示す実施例の動作を説明する。図３に示す実施例の動作は図１の実施例とほぼ同一であり、異なる点は複数の異なるレルムに所属する端末にアクセスする場合に、アクセス先のレルムにあるＫＤＣのＩＰアドレスを選択してＴＧＴ応答メッセージの暗号化部分に埋め込んでいることである。

具体的には、端末１１が端末１３にアクセスする場合は、ＫＤＣ１２のＴＧＳはＫＤＣ１４のＩＰアドレスを選択し、ＫＤＣ１４へアクセスするためのＴＧＴ要求に対するＴＧＴ応答メッセージの暗号化部分に埋め込んで端末１１へ送信する。一方、端末１１が端末１５にアクセスする場合は、ＫＤＣ１２のＴＧＳはＫＤＣ１６のＩＰアドレスを選択し、ＫＤＣ１６へアクセスするためのＴＧＴ要求に対するＴＧＴ応答メッセージの暗号化部分に埋め込んで端末１１へ送信する。

この結果、端末１１が端末１３にアクセスする場合は、ＫＤＣ１２のＴＧＳはＫＤＣ１４のＩＰアドレスを選択し、ＫＤＣ１４へアクセスするためのＴＧＴ要求に対するＴＧＴ応答メッセージの暗号化部分に埋め込んで端末１１へ送信し、端末１１が端末１５にアクセスする場合は、ＫＤＣ１２のＴＧＳはＫＤＣ１６のＩＰアドレスを選択し、ＫＤＣ１６へアクセスするためのＴＧＴ要求に対するＴＧＴ応答メッセージの暗号化部分に埋め込んで端末１１へ送信することにより、端末１１はＫＤＣ１４、若しくは、ＫＤＣ１６のＩＰアドレスを安全に取得できるので、ＫＤＣ１４、若しくは、ＫＤＣ１６のＩＰアドレスを事前に端末１１に設定すること無く、セキュリティ面で安全な相互認証を異なるレルム間で行うことが可能になる。

図４は本発明に係る認証方式及びこれを用いた認証システムの他の実施例を示す構成ブロック図である。

図４において１７は他の端末との間で相互認証を行おうとする端末、１８，１９及び２１はＫＤＣ、２０は端末１７の相互認証の対象である端末である。また、端末１７及びＫＤＣ１８はレルム１０７を構成し、端末２０及びＫＤＣ２１はレルム１０９を構成している。ＫＤＣ１９はレルム１０８にある。

端末１７はネットワーク等を介してＫＤＣ１８、ＫＤＣ１９、端末２０及びＫＤＣ２１と相互に接続される。

ここで、図４に示す実施例の動作を図５を用いて説明する。図５は異なるレルム間で認証サービスを受ける時の動作を説明するメッセージフロー図である。

図４に示す実施例の動作は図１の実施例とほぼ同一であり、異なる点は第１のレルムに所属する端末が第３のレルムに所属する端末にアクセスする場合に、第２のレルムにあるＫＤＣのＩＰアドレスが暗号化部分に埋め込まれたＴＧＴ応答メッセージを第１のレルムにあるＫＤＣのＴＧＳから取得し、第２のレルムにあるＫＤＣのＩＰアドレスを抽出し、第３のレルムにあるＫＤＣのＩＰアドレスが暗号化部分に埋め込まれたＴＧＴ応答メッセージを第２のレルムにあるＫＤＣのＴＧＳから取得することである。

この場合、第１のレルムに所属する端末、若しくは、第１のレルムにあるＫＤＣは、第２のレルムにあるＫＤＣが第３のレルムにあるＫＤＣのＩＰアドレスを知っていることを予め認識している。

図５中”Ｓ３０１”において端末１７はＴＧＴをＫＤＣ１８のＡＳへ要求する。図５中”Ｓ３０２”においてＫＤＣ１８のＡＳはＴＧＴ要求に対して応答し、ＴＧＴ応答メッセージを端末１７へ送信する。

図５中”Ｓ３０３”において端末１７はレルム１０８にあるＫＤＣ１９へアクセスするためのＴＧＴをＫＤＣ１８のＴＧＳへ要求する。図５中”Ｓ３０４”においてＫＤＣ１８のＴＧＳはＴＧＴ要求に対して応答し、ＫＤＣ１９のＩＰアドレスを暗号化部分に埋め込んだＴＧＴ応答メッセージを端末１７へ送信する。

図５中”Ｓ３０５”において端末１７は図５中”Ｓ３０４”において取得したＴＧＴ応答メッセージより暗号化されたＫＤＣ１９のＩＰアドレスを抽出して復号化し、レルム１０９にあるＫＤＣ２１へアクセスするためのＴＧＴをＫＤＣ１９のＴＧＳへ要求する。図５中”Ｓ３０６”においてＫＤＣ１９のＴＧＳはＴＧＴ要求に対して応答し、ＫＤＣ２１のＩＰアドレスを暗号化部分に埋め込んだＴＧＴ応答メッセージを端末１７へ送信する。

そして、図５中”Ｓ３０７”において端末１７は図５中”Ｓ３０６”において取得したＴＧＴ応答メッセージより暗号化されたＫＤＣ２１のＩＰアドレスを抽出して復号化し、ＴＧＴをＫＤＣ２１のＴＧＳへ送信して、端末１７がＫＤＣ２１によって認証されていることを証明するための証明書であるサービスチケットを要求する。図５中”Ｓ３０８”においてＫＤＣ２１のＴＧＳはサービスチケット要求に対して応答し、サービスチケットを端末１７へ送信する。

図５中”Ｓ３０９”において端末１７は図５中”Ｓ３０８”において取得したサービスチケットを端末２０へ送信して認証を要求する。最後に、図５中”Ｓ３１０”においてサービスチケットを確認した端末２０は端末１７を認証する。

この結果、レルム１０８にあるＫＤＣ１９のＩＰアドレスが暗号化部分に埋め込まれたＴＧＴ応答メッセージを端末１７がＫＤＣ１８のＴＧＳから取得し、暗号化されたＫＤＣ１９のＩＰアドレスを抽出して復号化し、レルム１０９にあるＫＤＣ２１のＩＰアドレスが暗号化部分に埋め込まれたＴＧＴ応答メッセージを端末１７がＫＤＣ１９のＴＧＳから取得し、暗号化されたＫＤＣ２１のＩＰアドレスを抽出して復号化することにより、端末１７はＫＤＣ１９及びＫＤＣ２１のＩＰアドレスを安全に取得できる。

さらに、端末１７がＫＤＣ１９のＴＧＳから取得したＴＧＴを用いて端末２０へのサービスチケットをＫＤＣ２１のＴＧＳから取得し、このサービスチケットを用いて端末２０へ認証を要求し、端末１７が端末２０に認証されることにより、ＫＤＣ１９及びＫＤＣ２１のＩＰアドレスを事前に端末１７に設定すること無く、セキュリティ面で安全な相互認証を異なるレルム間で行うことが可能になる。

なお、図１、図３及び図４に示す実施例において異なるレルムにあるＫＤＣのＩＰアドレスを応答メッセージの暗号化部分に埋め込んで端末に送信しているが、必ずしも応答メッセージの暗号化部分に埋め込む必要は無く、異なるレルムにあるＫＤＣのＩＰアドレスを別の手段で暗号化し、その暗号化されたＩＰアドレスをＴＧＴと共に端末に送信してもよい。

また、図３に示す実施例においてアクセス対象となるレルムがレルム１０５とレルム１０６の２つしか記載されていないが、必ずしも２つである必要は無く、アクセス対象となるレルムは複数あればよい。

また、図４に示す実施例においてＴＧＴを送信するＫＤＣ１９があるレルム１０８は１つしか記載されていないが、必ずしも１つである必要は無く、１つ以上あればよい。

本発明に係る認証方式及びこれを用いた認証システムの一実施例を示す構成ブロック図である。 異なるレルム間で認証サービスを受ける時の動作を説明するメッセージフロー図である。 本発明に係る認証方式及びこれを用いた認証システムの他の実施例を示す構成ブロック図である。 本発明に係る認証方式及びこれを用いた認証システムの他の実施例を示す構成ブロック図である。 異なるレルム間で認証サービスを受ける時の動作を説明するメッセージフロー図である。 従来の認証方式を用いた認証システムの一例を示す構成ブロック図である。 同一レルムの認証サービスを受ける時の動作を説明するメッセージフロー図である。 異なるレルム間で認証サービスを受ける時の動作を説明するメッセージフロー図である。

符号の説明

１，２，５，７，９，１１，１３，１５，１７，２０ 端末
３，４，８，１０，１２，１４，１６，１８，１９，２１ 鍵配布センター
６ ＤＮＳサーバ
１００，１０１，１０２，１０３，１０４，１０５、１０６，１０７，１０８，１０９ レルム

Claims (4)

1. 互いに異なるレルムに所属する端末の間でＫｅｒｂｅｒｏｓ認証方式を用いて認証を行う認証方式であって、
   一方のレルムに所属する端末が異なるレルムに所属する端末との間で認証を得るために前記一方のレルムにある鍵配布センターに対して前記異なるレルムにある鍵配布センターへアクセスするためのチケット認可チケットを要求し、
   前記一方のレルムにある鍵配布センターが要求のあった前記チケット認可チケットと共に暗号化された前記異なるレルムにある鍵配布センターのＩＰアドレスを前記一方のレルムに所属する端末に送信し、
   前記一方のレルムに所属する端末が前記ＩＰアドレスに基づき前記異なるレルムにある鍵配布センターにアクセスしてサービスチケットの提供を受け、
   前記異なるレルムに所属する端末が前記サービスチケットを用いて前記一方のレルムに所属する端末の認証を行う
   ことを特徴とする認証方式。
2. 互いに異なるレルムに所属する端末の間でＫｅｒｂｅｒｏｓ認証方式を用いて認証を行う認証システムにおいて、
   異なるレルムに所属する端末との間で認証を得るために前記異なるレルムにある鍵配布センターへアクセスするためのチケット認可チケットを要求する一方のレルムに所属する端末と、
   前記要求のあった前記チケット認可チケットと共に暗号化された前記異なるレルムにある鍵配布センターのＩＰアドレスを前記一方のレルムに所属する端末へ送信する前記一方のレルムにある鍵配布センターと、
   前記一方のレルムに所属する端末が取得した前記チケット認可チケットに基づきサービスチケットを提供する前記異なるレルムにある鍵配布センターと、
   前記異なるレルムに所属し前記サービスチケットを用いて前記一方のレルムに所属する端末の認証を行う端末と
   を備えたことを特徴とする認証システム。
3. 互いに異なるレルムに所属する端末の間でＫｅｒｂｅｒｏｓ認証方式を用いて認証を行う認証システムにおいて、
   複数の異なるレルムにそれぞれ所属する複数の端末のうち任意の端末との間で認証を得るために前記任意の端末が所属するレルムにある鍵配布センターへアクセスするためのチケット認可チケットを要求する一方のレルムに所属する端末と、
   前記複数の異なるレルムにそれぞれある複数の鍵配布センターのＩＰアドレスの中から前記任意の端末が所属するレルムの鍵配布センターのＩＰアドレスを選択し前記要求のあった前記チケット認可チケットと共に暗号化された前記異なるレルムにある鍵配布センターのＩＰアドレスを前記一方のレルムに所属する端末へ送信する一方のレルムにある鍵配布センターと、
   前記一方のレルムに所属する端末が取得した前記チケット認可チケットに基づきサービスチケットを提供する前記任意の端末が所属するレルムにある鍵配布センターと、
   前記サービスチケットを用いて前記一方のレルムに所属する端末の認証を行う前記任意の端末と
   を備えたことを特徴とする認証システム。
4. 互いに異なるレルムに所属する端末の間でＫｅｒｂｅｒｏｓ認証方式を用いて認証を行う認証システムにおいて、
   第３のレルムに所属する第２の端末との間で認証を得るために前記第３のレルムにある第３の鍵配布センターへアクセスするためのチケット認可チケットを第１のレルムにある第１の鍵配布センター若しくは第２のレルムにある第２の鍵配布センターに要求する前記第１のレルムに所属する第１の端末と、
   前記要求のあった前記チケット認可チケットと共に暗号化された前記第２の鍵配布センターのＩＰアドレスを前記第１の端末へ送信する前記第１の鍵配布センターと、
   前記要求のあった前記チケット認可チケットと共に暗号化された前記第３の鍵配布センターのＩＰアドレスを前記第１の端末へ送信する前記第２の鍵配布センターと、
   前記第１の端末が前記第２の鍵配布センターから取得した前記チケット認可チケットに基づきサービスチケットを提供する前記第３の鍵配布センターと、
   前記サービスチケットを用いて前記第１の端末の認証を行う前記第２の端末と
   を備えたことを特徴とする認証システム。
   

Images