JP5572314B2 - 無線携帯インターネットシステムにおける端末保安関連パラメター交渉方法 - Google Patents

Description

本発明は、無線携帯インターネットシステムにおける端末保安関連パラメター交渉方法に関し、より詳しくは、無線携帯インターネットシステムで多様な認証政策とメッセージ認証方式を効率的に支援及び管理するための端末保安関連パラメター交渉方法に関するものである。

無線携帯インターネットは、従来無線ＬＡＮのように固定されたアクセスポイント（ＡＰ）を利用する近距離データ通信方式に移動性をさらに支援する次世代通信方式である。このような無線携帯インターネットは、多様な標準が提案され、現在ＩＥＥＥ８０２．１６を中心に携帯インターネットの国際標準化が進められている。ここでＩＥＥＥ８０２．１６は、基本的に都市圏通信網（ＭＡＮ）を支援する規格で、構内情報通信網（ＬＡＮ）と広域通信網（ＷＡＮ）の中間程度の地域を網羅する情報通信網を意味する。

このようなＩＥＥＥ８０２．１６無線ＭＡＮ基盤の無線携帯インターネットシステムにおける認証政策においては、ＲＳＡ（Ｒｉｖｅｓｔ Ｓｈａｍｉｒ Ａｄｌｅｍａｎ）基盤の認証とＥＡＰ（Ｅｘｔｅｎｓｉｂｅｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）基盤の認証という、この２種類の認証方式が支援された。そして、端末と基地局は、初期接続手続中に行われる端末基本機能交渉過程を通じて、前記２種類の認証方式に対する交渉を行う。この時、端末は、基地局にＩＥＥＥ８０２．１６標準プロトコルのＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）メッセージのうちの１つであるＳＢＣ-ＲＥＱ（Ｓｕｂｓｃｒｉｂｅｒ ｓｔａｔｉｏｎ Ｂａｓｉｃ Ｃａｐａｂｉｌｉｔｙ Ｒｅｑｕｅｓｔ）メッセージを伝送することで、端末が支援可能な全ての認証方式、ここでは２種類の認証方式を通知する。ここで、認証は、端末装置に対する認証、基地局装置に対する認証または使用者認証を意味する。

一方、ＳＢＣ-ＲＥＱメッセージを受信した基地局は、端末から通知された認証方式と基地局自ら支援する認証方式を比較して交渉を行う。その後、基地局は、交渉された認証方式に関して、ＭＡＣメッセージのうちの１つであるＳＢＣ-ＲＳＰ（ＳＳ Ｂａｓｉｃ Ｃａｐａｂｉｌｉｔｙ Ｒｅｓｐｏｎｓｅ）メッセージを端末に伝送して知らせる。端末と基地局は、このような手続によって交渉された認証方式で、端末に対する認証機能を行う。

しかし、前記従来方式によると、ＲＳＡ基盤の認証方式とＥＡＰ基盤の認証方式のみを支援するため多様な認証方式を支援することができず、より効率的な認証方式の支援が要求される。また、無線携帯インターネットシステムの事業者政策によって、システム性能の向上のために認証機能が省略されなければならないが、従来方式によると、認証機能を省略することができないという問題がある。

一方、無線携帯インターネットシステムでは、端末に対する認証機能を行う場合、端末と基地局との間で通信される全ての制御メッセージに対するメッセージ認証機能を支援している。

端末と基地局は、このようなメッセージ認証のためにＨＭＡＣ（Ｈａｓｈｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）とＣＭＡＣ（Ｃｉｐｈｅｒ-ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）を代表的に使用し、端末のシステム再接続手続やハンドオーバー手続を行う時に端末と基地局との間で交換される制御メッセージに使用される多様な大きさのＨＭＡＣが存在するが、従来無線携帯インターネットシステムでは、このように多様なメッセージ認証方式が選択できる方法やメッセージ認証機能が省略できる方法が定義されていないという問題がある。
米国特許第6134434号明細書 欧州特許出願公開第1102505号明細書

したがって、本発明の技術的課題は、無線携帯インターネットシステムでより多様な認証政策とメッセージ認証方式を支援すると同時に、事業者の政策に応じて認証機能またはメッセージ認証機能が省略できる無線携帯インターネットシステムにおける端末保安関連パラメター交渉方法を提供することにある。

前記課題を達成するための本発明の１つの特徴による無線携帯インターネットシステムにおける端末保安関連パラメター交渉方法は、無線携帯インターネットシステムの端末が基地局と端末保安関連パラメターを交渉する方法として、ａ）前記端末が支援可能な保安関連機能が記載された保安関連交渉パラメターが含まれると共に、端末保安関連パラメターを交渉するための基本機能交渉要求メッセージを前記基地局に送信する段階;及び、ｂ）前記基地局で交渉された保安関連機能が記載された保安関連交渉パラメターが含まれると共に、前記送信された基本機能交渉要求メッセージに対する応答として前記基地局から送信される基本機能交渉応答メッセージを、受信する段階を含み、前記基本機能交渉応答メッセージに含まれる保安関連交渉パラメターが、前記端末に対する認証を行わずに省略する機能を支援することを特徴とする。

ここで、前記基本機能交渉応答メッセージに含まれる保安関連交渉パラメターは、前記端末と基地局との間で伝達されるメッセージに対する認証を行わずに省略する機能を支援することを特徴とする。

また、メッセージに対する認証機能を支援する時に多様なメッセージ認証コード方式の選択を可能にすることを特徴とする。

本発明の他の特徴による無線携帯インターネットシステムにおける端末保安関連パラメター交渉方法は、無線携帯インターネットシステムの基地局が端末と保安関連パラメターを交渉する方法として、ａ）前記端末が支援可能な保安関連機能が記載された保安関連交渉パラメターが含まれると共に、端末保安関連パラメターを交渉するための基本機能交渉要求メッセージを、前記端末から受信する段階;及びｂ）前記受信された保安関連交渉パラメターに記載された前記端末が支援可能な保安関連機能と前記基地局が支援可能な保安関連機能に対する比較及び交渉を行い、その交渉結果が記載された保安関連交渉パラメターを含む基本機能交渉応答メッセージを、前記端末に送信する段階を含み、前記基本機能交渉応答メッセージに含まれる保安関連交渉パラメターが、前記端末に対する認証を行わずに省略する機能を支援することを特徴とする。

ここで、前記基本機能交渉応答メッセージに含まれる保安関連交渉パラメターは、前記端末と基地局との間で伝達されるメッセージに対する認証を行わずに省略する機能を支援することを特徴とする。

また、メッセージに対する認証機能を支援する時、多様なメッセージ認証コード方式選択を可能にすることを特徴とする。

以下、添付した図面を参照して本発明の実施例について、本発明が属する技術分野における通常の知識を有する者が容易に実施できるように詳しく説明する。しかし、本発明は、多様で相異なる形態で実現することができ、ここで説明する実施例に限られない。図面で本発明を明確に説明するために説明上不必要な部分は省略した。明細書全体にわたって類似の部分については同一図面符号を付けた。

明細書全体である部分がある構成要素を“含む”とするとした時、これは特に反対になる記載のない限り他の構成要素を除くことではなく、他の構成要素をさらに含むことができることを意味する。

以下、添付した図面を参照して本発明の実施例による無線携帯インターネットシステムにおける端末保安関連パラメター交渉方法について詳細に説明する。

端末が電源の供給を受けて基地局との初期接続手続が始まると、端末は、まず基地局と下り方向リンク同期を設定し、上り方向リンクパラメターを獲得する。このような上り方向リンクパラメターには、物理階層の特性（例えば、信号対雑音比）によるチャンネルデスクリプタメッセージが含まれてもよい。

その後、端末と基地局は、無線リンク初期接続段階であるレンジング（Ｒａｎｇｉｎｇ）手続を行い、このようなレンジング手続が完了されると、端末と基地局との間の端末基本機能交渉段階が行われる。このような端末基本機能交渉段階を通じて、端末と基地局が物理階層に関する様々なパラメターを交渉する。また、この段階によって、保安に関するパラメターが交渉される。この時、交渉されるパラメターには、ＰＫＭ（Ｐｒｉｖａｃｙ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ）バージョン、認証政策、メッセージ認証機能が含まれる。

図１は、本発明の実施例による無線携帯インターネットシステムにおける端末保安関連パラメターを交渉するための端末基本機能交渉過程の流れ図である。

図１を参照すると、端末と基地局との間におけるレンジング手続が終わると、端末に対する認証のために、認証方式交渉過程を含む基本機能交渉（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ Ｂａｓｉｃ Ｃａｐａｂｉｌｉｔｙ Ｎｅｇｏｔｉａｔｉｏｎ）手続が行われる。

まず、端末は、基本機能交渉、特に端末の保安関連パラメター交渉のために、ＩＥＥＥ８０２．１６標準プロトコルのＭＡＣメッセージのうちの１つである端末基本機能交渉要求（ＳＢＣ-ＲＥＱ）メッセージを基地局に送信する（Ｓ１００）。

この時、ＳＢＣ-ＲＥＱメッセージには、端末が支援可能な全ての情報を含むパラメターが含まれている。特に、このＳＢＣ-ＲＥＱメッセージには、端末保安関連交渉パラメター（Ｓｅｃｕｒｉｔｙ Ｎｅｏｔｉａｔｉｏｎ Ｐａｒａｍｅｔｅｒｓ）というフィールドを通じて端末が支援する全ての保安関連パラメターが含まれて、基地局に通知される。このような端末保安関連交渉パラメターフィールドには、複数の副フィールドが含まれ、ＰＫＭバージョン支援、認証政策支援、メッセージ認証コード方式を表現する副フィールドが該当する。このような副フィールドについては後述する。

端末は、支援可能な多様な認証政策、支援可能な多様なメッセージ認証コード方式を、ＳＢＣ-ＲＥＱメッセージの副フィールドを通じて、基地局に通知することができる。

次に、端末から送信されたＳＢＣ-ＲＥＱメッセージを受信した基地局は、端末に対する認証のために、ＩＥＥＥ８０２．１６の規格に既に定義された基本機能交渉を行うと同時に、ＳＢＣ-ＲＥＱメッセージに含まれている端末保安関連交渉パラメターと基地局自ら支援可能な端末保安関連パラメターを比較して、最終的な値を定める。この時、基地局は、従来ＲＳＡ基盤の認証方式とＥＡＰ基盤の認証方式のうちのいずれかを選択することから抜けて、より多様な認証政策を選択することができる。例えば、基地局は、無線携帯インターネットシステムの事業者政策によって端末に対する認証機能を行わずに省略する認証政策も決めることができる。また、基地局は、ＨＭＡＣとＣＭＡＣのうちのいずれかを選択することから抜けて、より多様なメッセージ認証コード方式を決めることができる。例えば、認証政策と同様に、基地局は、無線携帯インターネットシステムの事業者政策によってメッセージに対する認証機能を行わずに省略するメッセージ認証コード方式を決めることもできる。

このように基地局で交渉された端末保安関連交渉パラメターは、ＩＥＥＥ８０２．１６標準プロトコルのＭＡＣメッセージのうちの１つである基本機能交渉応答（ＳＢＣ-ＲＳＰ）メッセージを通じて、端末に転送される（Ｓ１１０）。

したがって、端末と基地局との間の端末基本機能交渉手続が完了し、その結果、端末と基地局は、端末保安に関連して交渉されたパラメターを互いに共有する。

図２は、本発明の実施例による無線携帯インターネットシステムにおける端末保安関連パラメター交渉方法で提案する端末保安関連交渉パラメターを示すテーブルを表す図面である。

前記のように、端末と基地局は、ＳＢＣ-ＲＥＱメッセージ及びＳＢＣ-ＲＳＰメッセージを交換することで、端末基本機能交渉過程を行う。この時、前記ＳＢＣ-ＲＥＱメッセージ及びＳＢＣ-ＲＳＰメッセージ内には、端末保安関連パラメター交渉遂行のために端末保安関連交渉パラメターフィールドが含まれる。

この端末保安関連交渉パラメターフィールドは、複数の副フィールドで構成されている。そして、このフィールドのタイプは２５であり、長さは、中に構成された複数の副フィールドを含むかどうかによって流動的である。

図３は、図２に示された端末保安関連交渉パラメターの構成を示すテーブルを表す図面である。

図３を参照すると、端末保安関連交渉パラメターフィールドは、複数の副フィールドを含む。この副フィールドは、端末に対する実質的な権限検証、つまり、端末に対する認証を行う以前に、端末と基地局との間で交渉されなければならないフィールドである。つまり、端末に対する基本機能交渉過程で交渉されなければならないフィールドである。このような複数の副フィールドには、ＰＫＭバージョン支援（ＰＫＭ Ｖｅｒｓｉｏｎ Ｓｕｐｐｏｒｔ）、認証政策支援（Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｐｏｌｉｃｙ Ｓｕｐｐｏｒｔ）、メッセージ認証コード方式（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ Ｍｏｄｅ）及びＰＮウィンドウサイズ（Ｗｉｎｄｏｗ Ｓｉｚｅ）が含まれる。

ＰＫＭバージョン支援副フィールドは、端末と基地局との間でＰＫＭバージョンを交渉するために使用される副フィールドである。ここで、ＰＫＭは、ＩＥＥＥ８０２．１６標準プロトコルで保安階層を定義する保安キー管理（Ｐｒｉｖａｃｙ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ）プロトコルである。ここには、ＰＫＭバージョン１を示すＰＫＭ Ｖ１、及びＰＫＭバージョン２を示すＰＫＭ Ｖ２が存在する。

認証政策支援副フィールドは、端末と基地局との間で認証政策を交渉するために使用される副フィールドである。この副フィールドを通じて、端末と基地局は、多様な認証政策を選択することができ、また無線携帯インターネットシステム事業者の政策によって端末に対する認証機能が省略されてもよい。ここで、認証機能は、端末装置に対する認証機能、基地局装置に対する認証機能または使用者認証機能を意味する。

メッセージ認証コード方式（ＭＡＣ Ｍｏｄｅ）副フィールドは、端末と基地局との間で交換される全ての制御メッセージに対する認証方式を交渉するために使用される副フィールドである。この副フィールドを通じて、端末と基地局との間でメッセージ認証機能が省略されることもあり、またメッセージ認証機能が省略されない場合には、多様なメッセージ認証方式の中で選択された１つの方式が行われる。

ＰＮ（Ｐａｃｋｅｔ Ｎｕｍｂｅｒ）ウィンドウサイズ副フィールドは、１つのＳＡ（Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ）ごとに受信ＰＮウィンドウサイズを交渉するために使用される副フィールドである。

図４は、図３に示されたＰＫＭバージョン支援副フィールドのパラメターを示すテーブルを表す図面である。

図４に示されたようなＰＫＭバージョン支援副フィールドは、上述のように保安関連交渉パラメターに含まれる１つの副フィールドとして与えられると共に、ＰＫＭバージョンを交渉するための副フィールドである。言い換えると、端末と基地局が、ＰＫＭバージョン１またはＰＫＭバージョン２のうちの１つを選択するために使用する副フィールドである。この副フィールドは、フィールドタイプが１であるために結果的に保安関連交渉パラメターフィールドと関連してそのタイプが２５．１に決められ、１バイトの長さを有する。

このようなＰＫＭバージョン支援副フィールドの１バイトの中で、第０ビット（Ｂｉｔ#０）と第１ビット（Ｂｉｔ#１）のみが実際に使用され、他のビット（Ｂｉｔ#２-７）は使用されずに０に設定される。ここで、第０ビット（Ｂｉｔ#０）はＰＫＭバージョン１を示し、第１ビット（Ｂｉｔ#１）はＰＫＭバージョン２を示し、各ビット（Ｂｉｔ#０，１）が１に設定される場合には、当該ＰＫＭバージョンを支援することを示す。

したがって、端末は、ＰＫＭバージョン支援副フィールドに３つの方式で記載することができ、端末は、ＰＫＭバージョン１のみを支援する方式（Ｂｉｔ#０=１、Ｂｉｔ#１=０）、ＰＫＭバージョン２のみを支援する方式（Ｂｉｔ#０=０、Ｂｉｔ#１=１）、そしてＰＫＭバージョン１とＰＫＭバージョン２の両方とも支援する方式（Ｂｉｔ#０=１、Ｂｉｔ#１=１）のうちの１つを支援することができる。

図１を参照して説明すると、端末は、支援可能な全てのＰＫＭバージョンが記載されたＰＫＭバージョン支援副フィールドが含まれているＳＢＣ-ＲＥＱメッセージ（Ｓ１００）を基地局に伝送することで、端末が支援可能な全てのＰＫＭバージョンを基地局に通知する。これを受信した基地局は、自身が支援可能なＰＫＭバージョンと比較してこのパラメターを交渉し、その交渉の結果、決められたＰＫＭバージョンが記載されたＰＫＭバージョン支援副フィールドが含まれているＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）を端末に伝送することによって、基地局で交渉されたＰＫＭバージョンが端末に伝達される。

このように端末と基地局との間で交渉されて共有されたＰＫＭバージョンを有して端末に対する権限検証、つまり、認証手続が行われる。したがって、基地局は、交渉されたＰＫＭバージョンのメッセージでない非交渉されたＰＫＭバージョンのメッセージが受信される場合に、端末に対する認証手続を行わずに受信されたメッセージを廃棄する。

図５は、図３に示された認証政策支援副フィールドのパラメターを示すテーブルを表す図面である。

図５に示されたような認証政策支援副フィールドは、上述のように保安関連交渉パラメターに含まれる１つの副フィールドとして与えられると共に、認証政策を交渉するための副フィールドである。本発明の実施例による無線携帯インターネットシステムでは、大きく３つの認証方式、つまり、ＲＳＡを基づく認証方式（ＲＳＡ-ｂａｓｅｄ ａｕｔｈｏｒｉｚａｔｉｏｎ）、ＥＡＰを基づく認証方式（ＥＡＰ-ｂａｓｅｄ ａｕｔｈｏｒｉｚａｔｉｏｎ）と、ＲＳＡ基盤認証方式またはＥＡＰ基盤認証方式を通じて割り当てられたキーによるメッセージ認証機能を伴う認証されたＥＡＰ基盤の認証方式（Ａｕｔｈｅｎｔｉｃａｔｅｄ ＥＡＰ-ｂａｓｅｄ ａｕｔｈｏｒｉｚａｔｉｏｎ）が定義されている。つまり、端末と基地局がこの３つの認証方式の中の１つ以上の認証方式を選択するために使用する副フィールドである。この副フィールドは、フィールドタイプが２であるために、結果的に保安関連交渉パラメターフィールドと関連してそのタイプが２５．２に決められ、１バイトの長さを有する。

このような認証政策支援副フィールドは、端末や基地局が支援するＰＫＭバージョンが２である場合に定義される。つまり、端末や基地局が支援するＰＫＭバージョンが１である場合において交渉される認証政策は、ＲＳＡ基盤認証方式のみであるためである。

このような認証政策支援副フィールドの１バイトの中で、第０ビット（Ｂｉｔ#０）から第２ビット（Ｂｉｔ#２）までは端末の初期接続手続で有効なビットである。そして、第４ビット（Ｂｉｔ#４）から第６ビット（Ｂｉｔ#６）までは端末のシステム再接続手続やハンドオーバー手続で有効なビットである。残り第３ビット（Ｂｉｔ#３）と第７ビット（Ｂｉｔ#７）は使用されずに０に設定される。ここで、第０ビット（Ｂｉｔ#０）と第４ビット（Ｂｉｔ#４）はＲＳＡに基づく認証方式（ＲＳＡ-ｂａｓｅｄ ａｕｔｈｏｒｉｚａｔｉｏｎ）を示し、第１ビット（Ｂｉｔ#１）と第５ビット（Ｂｉｔ#５）はＥＡＰに基づく認証方式（ＥＡＰ-ｂａｓｅｄ ａｕｔｈｏｒｉｚａｔｉｏｎ）を示し、第２ビット（Ｂｉｔ#２）と第６ビット（Ｂｉｔ#６）は認証されたＥＡＰ基盤の認証方式をそれぞれ示し、各ビット（Ｂｉｔ#０〜Ｂｉｔ#２、Ｂｉｔ#４〜Ｂｉｔ#６）が１に設定される場合には、該当する認証政策を支援することを示す。

したがって、初期接続手続中にある端末は、前記副フィールドの下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）を通じて、初期接続手続中の認証手続で支援可能な認証政策にのみ値を１に設定し、支援が不可能な認証政策に対しては値を０に設定する。

また、端末は、前記副フィールドの上位３ビット（Ｂｉｔ#４〜Ｂｉｔ#６）を通じて、再接続手続中やハンドオーバー手続中の認証手続で支援可能な認証政策にのみ値を１に設定し、支援不可能な認証政策に対しては値を０に設定する。

図１を参照して説明すると、端末は、支援可能な全ての認証政策が記載された認証政策支援副フィールドが含まれたＳＢＣ-ＲＥＱメッセージ（Ｓ１００）を基地局に伝送して、端末が支援可能な全ての認証政策を基地局に通知する。

これを受信した基地局は、まず、端末から伝送される認証政策支援副フィールドの下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）に関して、自分が支援可能な認証政策と比較し、このパラメターを交渉する。そして、認証政策支援副フィールドの上位３ビット（Ｂｉｔ#４〜Ｂｉｔ#６）は、端末がシステム再接続またはハンドオーバー時に使用することを要請する認証政策であるので、この複数のビットに対しては交渉せずに、基地局が別に管理した後、端末のハンドオーバー要請時に近接基地局に通知する。

基地局が、前記で交渉された認証政策が記載された認証政策支援副フィールドが含まれたＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）を端末に伝送することで、基地局で交渉された認証政策が端末に伝達される。この時、ＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）に含まれた認証政策支援副フィールドの中の下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）は、基地局が最終的に交渉した初期接続手続中の認証手続を行う時に使用される認証政策を表現したもので、他のビット（Ｂｉｔ#３〜Ｂｉｔ#７）は０に設定されている。

本発明の実施例では、無線携帯インターネットシステムの事業者政策によってシステム性能を志向する場合、端末の認証機能が省略されることもできる。この時には、基地局が端末に伝送するＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）に含まれる認証政策支援副フィールド値が全て０に設定される。つまり、基地局は、端末に伝送する認証政策支援副フィールドの全てのビットを０に設定することで、事業者の政策によって端末の認証機能が省略されることを知らせることができる。この場合、端末は、基地局との間で、端末に対する権限検証、つまり、認証手続を行わず、直ちに端末を基地局に登録する登録手続を行う。

一方、端末が基地局に伝送するＳＢＣ-ＲＥＱメッセージ（Ｓ１００）に認証政策支援副フィールドが存在すると、これに対する応答として基地局が端末に伝送するＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）に、認証政策支援副フィールドが必ず存在しなければならない。

これとは反対に、端末が基地局に伝送するＳＢＣ-ＲＥＱメッセージ（Ｓ１００）に認証政策支援副フィールドが存在しなければ、端末はＲＳＡ基盤の認証政策のみを支援する。この場合では、基地局が端末に伝送するＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）に交渉された認証政策支援副フィールドが存在しないことがあり、この場合、端末と基地局との間で交渉された認証政策はＲＳＡ基盤の認証政策である。万一、基地局が端末に伝送するＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）に交渉された認証政策支援副フィールドが存在すると、ＲＳＡ基盤の認証政策が交渉されたことと同様な結果、または以下で説明される認証機能を支援しない結果（Ｎｏ Ａｕｔｈｏｒｉｚａｔｉｏｎ）が記載されて伝達される。ＲＳＡ基盤の認証政策が交渉されたことと同様な結果に対しては、第０ビット（Ｂｉｔ#０）が１に設定されて端末に伝達され、認証政策が省略される結果については後述する。

このように端末と基地局との間で交渉されて共有された認証政策によって、端末または基地局に対する権限検証または使用者認証、つまり、多様な認証手続が行われる。したがって、基地局は、交渉された認証政策に相当しない認証関連メッセージが受信された場合には、端末に対する認証手続を行わず、受信されたメッセージを廃棄する。

図６は、図５に示された認証政策支援副フィールドを使用して交渉可能な全ての認証政策を示すテーブルを表す図面である。

ＩＥＥＥ８０２．１６無線ＭＡＮ基盤の無線携帯インターネットシステムにおける認証政策は、大きく３つの認証方式（ＲＳＡに基づく認証方式とＥＡＰに基づく認証方式、そして認証されたＥＡＰ基盤認証方式）の組み合わせからなることは前述した通りである。前記３つの認証方式の組み合わせを端末基本機能交渉段階を行いながら端末と基地局が交渉し、この交渉結果によって、基地局は端末に対する認証を行う。

初期接続手続中の認証手続のために認証政策支援副フィールドの下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）が使用され、再接続手続やハンドオーバー手続中の認証手続のために認証政策支援副フィールドの上位３ビット（Ｂｉｔ#４〜Ｂｉｔ#６）が使用される。

このように、認証政策支援副フィールドの各ビットを使用して支援可能な認証政策には、図６に示した通りに８種類のケースが存在する。

このような８種類のケースの中で、端末が基地局に伝送するＳＢＣ-ＲＥＱメッセージ（Ｓ１００）に含まれる認証政策支援副フィールドに対しては、ケース３、４、５、６及び７のみが適用される。端末は、最少で１つ以上の認証政策を支援しなければならないので、認証機能を支援しないケース１は適用できない。また、ケース２とケース８は、現在の保安キー管理プロトコル（ＰＫＭバージョン２）で支援しないために適用できない。

一方、ＳＢＣ-ＲＥＱメッセージを受信した基地局は、認証政策支援副フィールドに対して交渉し、この副フィールドが含まれているＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）を端末に伝送して端末基本機能交渉段階を完了する。ＳＢＣ-ＲＳＰメッセージに含まれる認証政策支援副フィールドには、初期接続手続中の認証手続の時に必要な交渉された認証政策のみが提示される。つまり、上位３ビット（Ｂｉｔ#４〜Ｂｉｔ#６）は０にセッティングされ、下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）のみが有効なビット値となる。

また、無線携帯インターネットシステムの事業者政策によってシステム性能を考慮する場合、認証機能を省略してもよい。このような場合は、認証政策支援副フィールドの下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）を全て０に設定することで行われる。

例えば、基地局が最終的にＥＡＰ基盤の認証方式のみを認証政策として選択する場合には、ケース３のように認証政策支援副フィールドの下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）を設定すればよい。

また、ＥＡＰ基盤の認証方式を行った後、これに基づく認証されたＥＡＰ基盤の認証方式を同時に支援する認証政策を、基地局が最終的に選択した場合には、ケース４のように認証政策支援副フィールドの下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）を設定すればよい。

また、ＲＳＡ基盤の認証方式のみを認証政策として基地局が最終的に選択した場合には、ケース５のように認証政策支援副フィールドの下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）を設定すればよい。

また、ＲＳＡ基盤の認証方式を行った後、これを先例として認証されたＥＡＰ基盤の認証方式を同時に支援する認証政策を、基地局が最終的に選択した場合には、ケース６のように認証政策支援副フィールドの下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）を設定すればよい。

また、ＲＳＡ基盤の認証方式を行った後、ＥＡＰ基盤の認証方式を同時に支援する認証政策を、基地局が最終的に選択した場合には、ケース７のように認証政策支援副フィールドの下位３ビット（Ｂｉｔ#０〜Ｂｉｔ#２）を設定すればよい。

上述のように、ケース２とケース８は、現在の保安キー管理プロトコル（ＰＫＭ）で支援しないために適用できない。

このような方法で、端末と基地局が、初期接続手続中の認証手続のために使用される認証政策を交渉する。交渉された認証政策によって端末と基地局の両方が認証手続を行い、基地局は、交渉されなった認証政策に関するメッセージを受信する場合には、当該メッセージを廃棄する。

図７は、図３に示されたメッセージ認証コード方式副フィールドのパラメターを示すテーブルを表す図面である。

図７に示されたようなメッセージ認証コード方式副フィールドは、上述したように保安関連交渉パラメターに含まれる１つの副フィールドとして与えられると共に、メッセージ認証方式を交渉するための副フィールドである。

本発明の実施例による無線携帯インターネットシステムにおけるメッセージ認証コード方式としては、ＨＭＡＣ、ＣＭＡＣと多様なｓｈｏｒｔ-ＨＭＡＣが定義されている。つまり、端末と基地局がこのようなメッセージ認証コード方式の中の１つ以上のメッセージ認証方式を選択するために使用する副フィールドである。この副フィールドは、フィールドタイプが３であるので、結果的に保安関連交渉パラメターフィールドと関連してそのタイプが２５．３に決められ、１バイトの長さを有する。

ここで、ｓｈｏｒｔ-ＨＭＡＣメッセージ認証コード方式は、ハンドオーバー時に必要なメッセージ、つまり、ＭＯＢ_ＳＬＰ-ＲＥＱ/ＲＳＰ、ＭＯＢ_ＳＣＡＮ-ＲＥＱ/ＲＳＰ、ＭＯＢ_ＭＳＨＯ-ＲＥＱ、ＭＯＢ_ＢＳＨＯ-ＲＥＱ/ＲＳＰ、ＭＯＢ_ＨＯ-ＩＮＤとＲＮＧ-ＲＥＱ/ＲＳＰメッセージにのみ適用できる。

このようなメッセージ認証コード方式副フィールドの１バイトの中で、第０ビット（Ｂｉｔ#０）から第４ビット（Ｂｉｔ#４）までは有効なビットであり、他のビット（Ｂｉｔ#５〜Ｂｉｔ#７）は使用されずに全て０に設定される。

ここで、第０ビット（Ｂｉｔ#０）はＨＭＡＣ方式を示し、第１ビット（Ｂｉｔ#１）はＣＭＡＣ方式を示し、第２ビット（Ｂｉｔ#２）は６４-ビットｓｈｏｒｔ-ＨＭＡＣ方式を示し、第３ビット（Ｂｉｔ#３）は８０-ビットｓｈｏｒｔ-ＨＭＡＣ方式を示し、第４ビット（Ｂｉｔ#４）は９６-ビットｓｈｏｒｔ-ＨＭＡＣ方式を示し、各ビット（Ｂｉｔ#０〜Ｂｉｔ#４）が１に設定される場合、該当するメッセージ認証コード方式を支援することを示す。

したがって、初期接続手続中にある端末は、前記副フィールドの２個のビット（Ｂｉｔ#０〜Ｂｉｔ#１）を通じて、初期接続手続中の認証手続で支援可能なメッセージ認証コード方式にのみ値を１に設定し、支援不可能なメッセージ認証コード方式に対しては値を０に設定する。

また、端末は、前記副フィールドの３個のビット（Ｂｉｔ#２〜Ｂｉｔ#４）を通じて、ハンドオーバー手続を行う時に必要なメッセージに適用可能なメッセージ認証コード方式を基地局に通知し、支援可能なメッセージ認証コード方式にのみ値を１に設定し、支援不可能なメッセージ認証コード方式に対しては値を０に設定する。

図１を参照して説明すると、端末は、支援可能な全てのメッセージ認証コード方式が記載された副フィールドが含まれたＳＢＣ-ＲＥＱメッセージ（Ｓ１００）を基地局に伝送することによって、端末が支援可能な全てのメッセージ認証コード方式を基地局に通知する。

これを受信した基地局は、まず、端末から伝送されるメッセージ認証コード方式副フィールドの下位２ビット（Ｂｉｔ#０〜Ｂｉｔ#１）に関して、自分が支援可能なメッセージ認証コード方式と比較してこのパラメターを交渉する。

基地局が、前記で交渉されたメッセージ認証コード方式が記載された副フィールドが含まれたＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）を端末に伝送することで、基地局で交渉されたメッセージ認証コード方式が端末に伝達される。この時、ＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）に含まれた交渉されたメッセージ認証コード方式副フィールドの中の下位２ビット（Ｂｉｔ#０〜Ｂｉｔ#１）は、端末の再接続手続やハンドオフ手続でない手続に定義されるメッセージに使用されるメッセージ認証コード方式を表現したもので、次のビット（Ｂｉｔ#２〜Ｂｉｔ#４）は、端末の再接続手続やハンドオフ手続に定義されるメッセージに使用されるメッセージ認証コード方式を表現したもので、残りビット（Ｂｉｔ#５〜Ｂｉｔ#７）は０に設定されている。

端末と基地局は、１つ以上のメッセージ認証コード方式を支援することができる。万一、端末と基地局が１つのメッセージ認証コード方式のみを支援するように交渉した場合、２つのノードの間の制御メッセージ通信の時に、当該メッセージ認証コード方式を使用しなければならない。これとは異なって、端末と基地局が１つ以上のメッセージ認証コード方式を支援する場合、２つのノード間の制御メッセージを通信する時に、交渉されたメッセージ認証コード方式のうちの１つの方式を使用しなければならない。

特に、無線携帯インターネットシステムの事業者政策によってシステム性能を志向する場合、メッセージ認証機能が省略されてもよい。この時には、基地局が端末に伝送するＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）に含まれたメッセージ認証コード方式副フィールドの値が全て０に設定される。つまり、基地局は、端末に伝送するメッセージ認証コード方式副フィールドの全てのビットを０に設定することによって、事業者の政策によってメッセージ認証機能が省略されることを知らせることができる。

一方、端末が基地局に伝送するＳＢＣ-ＲＥＱメッセージ（Ｓ１００）にメッセージ認証コード方式副フィールドが存在すると、これに対する応答として基地局が端末に伝送するＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）に、メッセージ認証コード方式副フィールドが必ず存在しなければならない。

これとは反対に、端末が基地局に伝送するＳＢＣ-ＲＥＱメッセージ（Ｓ１００）にメッセージ認証コード方式副フィールドが存在しないと、端末は、ただＨＭＡＣ方式のみを使用するメッセージ認証方式のみを支援する。この場合において、基地局が端末に伝送するＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）に、交渉されたメッセージ認証コード方式副フィールドが存在しないこともあり、もしメッセージ認証コード方式副フィールドが存在しない場合、端末と基地局との間で交渉されたメッセージ認証コード方式は、ＨＭＡＣ基盤のメッセージ認証コード方式である。万一基地局が端末に伝送するＳＢＣ-ＲＳＰメッセージ（Ｓ１１０）に交渉されたメッセージ認証コード方式副フィールドが存在すると、ＨＭＡＣ基盤のメッセージ認証コード方式が交渉されたことと同様な結果、またはメッセージ認証機能を支援しない結果が記載されて伝達される。ＨＭＡＣ基盤のメッセージ認証コード方式が交渉されたことと同様な結果に対しては、第０ビット（Ｂｉｔ#０）が１に設定されて端末に伝達され、メッセージ認証機能を省略する結果に対しては、全てのビット（Ｂｉｔ#０〜Ｂｉｔ#７）が０に設定されて端末に伝達される。

このように端末と基地局との間で共有されたメッセージ認証コード方式に応じて、端末と基地局との間で通信される制御メッセージに対する認証機能を行う。端末や基地局の両方が、交渉されないメッセージ認証コード方式を使用した制御メッセージを受信した場合、当該制御メッセージに対する認証段階を行わずに受信されたメッセージを廃棄する。

以上、本発明の好ましい実施例について詳細に説明したが、本発明はこれに限定されるわけではなく、その他の多様な変更や変形が可能である。

本発明によると次のような効果がある。

第一に、多様な保安に関するパラメターを１つの保安交渉パラメターに含めさせることによって、当該パラメターに対する管理がより容易になる。

第二に、ＰＫＭバージョン支援という副フィールドを提供することによって、端末と基地局が多様なＰＫＭバージョンの認証プロトコルを交渉することができる基盤が備えられる。

第三に、認証政策支援という副フィールドを提供することによって、端末と基地局が多様な認証政策を流動的に立てることができる。また、認証政策の最終決定権限を基地局が有するので、無線携帯インターネットシステムの事業者が認証機能をより容易に使用することができる。

第四に、基地局が交渉された多様な認証政策を有するので、より強力な認証機能を行うことができる。

第五に、無線携帯インターネットシステムの事業者がシステムの性能を考慮する場合、認証機能を省略することができる。

第六に、メッセージ認証コード方式という副フィールドを提供することによって、端末と基地局が多様な方式でメッセージ認証機能を行うことができる。また、メッセージ認証コード方式の最終決定権を基地局が有するので、無線携帯インターネットシステムの事業者が無線区間制御メッセージを通信する時、メッセージ認証機能に対してより容易に管理することができる。

第七に、無線携帯インターネットシステムの事業者がシステムの性能を考慮する場合、制御メッセージ認証機能が省略されてもよい。

本発明の実施例による無線携帯インターネットシステムにおける端末保安関連パラメターを交渉するための端末基本機能交渉過程の流れ図である。 本発明の実施例による無線携帯インターネットシステムにおける端末保安関連パラメター交渉方法で提案する端末保安関連交渉パラメターを示すテーブルを表す図面である。 図２に示された端末保安関連交渉パラメターの構成を示すテーブルを表す図面である。 図３に示されたＰＫＭバージョン支援（ＰＫＭ Ｖｅｒｓｉｏｎ Ｓｕｐｐｏｒｔ）副フィールドのパラメターを示すテーブルを表す図面である。 図３に示された認証政策支援副フィールドのパラメターを示すテーブルを表す図面である。 図５に示された認証政策支援副フィールドを使用して交渉可能な全ての組み合わせの認証政策を示すテーブルを表す図面である。 図３に示されたメッセージ認証コード方式副フィールドのパラメターを示すテーブルを表す図面である。

Claims (14)

1. 通信システムの端末が保安能力を交渉する方法において、
   前記端末が支援可能なＰＫＭ（ｐｒｉｖａｃｙ ｋｅｙ ｍａｎａｇｅｍｅｎｔ）バージョンを示すＰＫＭバージョン支援（ＰＫＭ ｖｅｒｓｉｏｎ ｓｕｐｐｏｒｔ）情報、前記端末が支援可能な認証ポリシーを示す認証ポリシー支援（ａｕｔｈｏｒｉｚａｔｉｏｎ ｐｏｌｉｃｙ ｓｕｐｐｏｒｔ）情報、前記端末が支援可能なメッセージ認証コード方式（ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｏｄｅ ｍｏｄｅ）を示すメッセージ認証コード方式情報、および前記端末が支援可能なＰＮ（ｐａｃｋｅｔ ｎｕｍｂｅｒ）ウィンドウサイズ（ＰＮ ｗｉｎｄｏｗ ｓｉｚｅ）を示すＰＮウィンドウサイズ情報を含む要請メッセージを生成する段階と、
   前記要請メッセージを基地局に伝送する段階とを含み、
   前記認証ポリシー支援情報は、複数のビットを含み、
   前記認証ポリシー支援情報の前記複数のビットのうちの一つのビットは、再接続手続でのＥＡＰ基盤認証の支援の有無を示し、
   前記認証ポリシー支援情報の前記複数のビットが全て０である場合、前記ＥＡＰ基盤認証とＲＳＡ基盤認証が支援されないことを示す
   ことを特徴とする方法。
2. 前記要請メッセージは、ＳＢＣ−ＲＥＱ（ｓｕｂｓｃｒｉｂｅｒ ｓｔａｔｉｏｎ ｂａｓｉｃ ａｐａｂｉｌｉｔｙ ｒｅｑｕｅｓｔ）メッセージであることを特徴とする請求項１に記載の方法。
3. 前記ＰＫＭバージョン支援情報は、前記端末がＰＫＭバージョン２を支援するか否かに関する情報を含むことを特徴とする請求項１または２に記載の方法。
4. 前記認証ポリシー支援情報の前記複数のビットのうちの一つのビットは、再接続手続でのＥＡＰ基盤認証の支援の有無を示すことを特徴とする請求項１または２に記載の方法。
5. 前記メッセージ認証コード方式情報は、複数のビットを含み、
   前記複数のビットのうちの一つのビットは、ＣＭＡＣ（Ｃｉｐｈｅｒ−ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）の支援の有無を示し、
   前記複数のビットが全て０である場合、前記メッセージ認証コード方式情報は、メッセージ認証コードが適用されないことを示すことを特徴とする請求項１または２に記載の方法。
6. 前記複数のビットのうちの他の一つのビットは、前記端末がＨＭＡＣ（Ｈａｓｈｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）の支援の有無を示すことを特徴とする請求項５に記載の方法。
7. 前記ＰＮウィンドウサイズ情報は、セキュリティ アソシエーションＩＤごとの受信ＰＮウィンドウサイズのケイパビリティを示す情報であることを特徴とする請求項１または２に記載の方法。
8. 通信システムの基地局が保安能力を交渉する方法において、
   端末と交渉したＰＫＭ（ｐｒｉｖａｃｙ ｋｅｙ ｍａｎａｇｅｍｅｎｔ）バージョンを示すＰＫＭバージョン支援（ＰＫＭ ｖｅｒｓｉｏｎ ｓｕｐｐｏｒｔ）情報、前記端末と交渉した認証ポリシーを示す認証ポリシー支援（ａｕｔｈｏｒｉｚａｔｉｏｎ ｐｏｌｉｃｙ ｓｕｐｐｏｒｔ）情報、前記端末と交渉したメッセージ認証コード方式（ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｏｄｅ ｍｏｄｅ）を示すメッセージ認証コード方式情報、および前記端末と交渉したＰＮ（ｐａｃｋｅｔ ｎｕｍｂｅｒ）ウィンドウサイズ（ＰＮ ｗｉｎｄｏｗ ｓｉｚｅ）を示すＰＮウィンドウサイズ情報を含む応答メッセージを生成する段階と、
   前記応答メッセージを端末に伝送する段階とを含み、
   前記認証ポリシー支援情報は、複数のビットを含み、
   前記認証ポリシー支援情報の前記複数のビットのうちの一つのビットは、再接続手続でのＥＡＰ基盤認証の支援の有無を示し、
   前記認証ポリシー支援情報の前記複数のビットが全て０である場合、前記ＥＡＰ基盤認証とＲＳＡ基盤認証が支援されないことを示す
   ことを特徴とする方法。
9. 前記応答メッセージは、ＳＢＣ−ＲＳＰ（ｓｕｂｓｃｒｉｂｅｒ ｓｔａｔｉｏｎ ｂａｓｉｃ ｃａｐａｂｉｌｉｔｙ ｒｅｑｕｅｓｔ）メッセージであることを特徴とする請求項８に記載の方法。
10. 前記ＰＫＭバージョン支援情報は、前記基地局がＰＫＭバージョン２を支援するか否かに関する情報を含むことを特徴とする、請求項８または９に記載の方法。
11. 前記認証ポリシー支援情報の前記複数のビットのうちの一つのビットは、再接続手続でのＥＡＰ基盤認証の支援の有無を示すことを特徴とする請求項８または９に記載の方法。
12. 前記メッセージ認証コード方式情報は、複数のビットを含み、
    前記複数のビットのうちの一つのビットは、ＣＭＡＣ（Ｃｉｐｈｅｒ−ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）の支援の有無を示し、
    前記複数のビットが全て０である場合、前記メッセージ認証コード方式情報は、メッセージ認証コードが適用されないことを示すことを特徴とする請求項８または９に記載の方法。
13. 前記複数のビットのうちの他の一つのビットは、前記端末がＨＭＡＣ（Ｈａｓｈｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）の支援の有無を示すことを特徴とする請求項１２に記載の方法。
14. 前記ＰＮウィンドウサイズ情報は、セキュリティ アソシエーションＩＤごとの受信ＰＮウィンドウサイズのケイパビリティを示す情報であることを特徴とする請求項８または９に記載の方法。

Images