JP4874037B2

JP4874037B2 - ネットワーク機器

Info

Publication number: JP4874037B2
Application number: JP2006247241A
Authority: JP
Inventors: 憲一北村
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2006-09-12
Filing date: 2006-09-12
Publication date: 2012-02-08
Anticipated expiration: 2026-09-12
Also published as: JP2008072242A

Description

本発明は、ＩＰｓｅｃ（Security Architecture for Internet Protocol）の制御を、機器のみでなくユーザ等を単位に行えるようにしたネットワーク機器に関する。

ＩＰｓｅｃにより通信を暗号化することにより、通信経路上の安全を保つことが可能となってきた（例えば、特許文献１、２参照。）。

ＩＰｓｅｃの認証とアクセスコントロールについては、ＩＰｓｅｃの暗号化共有鍵を生成するための処理であるＩＫＥ（Internet Key Exchange）によるＰｈａｓｅ１の処理において、規格上はユーザ名やディレクトリサービスの国際標準であるＸ．５００で規定されたものも利用することができる。

しかし、機器に設定して処理されることを前提としているため、データを振り分ける識別子としては、ＩＰ（Internet Protocol）アドレス、ＭＡＣ（Media Access Control）アドレスが前提とされている。

同様に、ＩＰｓｅｃのアクセスデータベースとしてもＩＰアドレスで振り分けることが規格上指示されている。
特開２００６−２０２６６号公報特開２００６−２０２６２号公報

上述したように、従来はＩＰアドレスもしくはＭＡＣアドレスが管理上の識別子として用いられていたため、本人認証として認証されるＩＫＥの部分では、機器が正しいことは確保されているが、それを使うユーザが正しいことは確保できていない。

このため、例えば、一つのＭＦＰ（Multi Function Printer）等の機器を複数のユーザが共有する環境において、port9100からのＲＯＷデータ印刷、ＬＰＲ（Line PRinter daemon protocol）等の、プロトコル自体に認証機構を持っていないものを使う場面にあっては、機器で認証がされている限り、機器にログインしているどんなユーザからでも印刷できてしまうという問題があった。印刷以外にも、ｒｓｈ（remote shell）コマンドの実行や、ＵＤＰ（User Datagram Protocol）によるＤＮＳ（Domain Name System）の名前解決等についても、プロトコル上、認証データを流すことができないため、同様の問題があった。

なお、現在のＩＰｓｅｃでは、１つのＩＤで記述可能なパケットしか通すことができないという仕様があるため、ＩＰｓｅｃＳＡ（Security Association）を細かく設定することによりアクセスコントロールすることしかできず、ユーザを単位としたアクセスコントロールを実現することは困難であった。

一方、ＳＳＬ（Secure Socket Layer）を用いることによりユーザの認証および暗号化を行うことができるが、ＳＳＬはプロトコルに依存するため、アプリケーションに変更が必要となり、既存のシステムに導入することは困難である。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、ＩＰｓｅｃの制御を、機器のみでなくユーザ等を単位に行えるようにしたネットワーク機器を提供することにある。

上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、機器で認証したＩＰｓｅｃＳＡに基づいて通信データに１次のＩＰｓｅｃを適用する１次ＩＰｓｅｃ手段と、１次のＩＰｓｅｃが適用されたペイロードにつき、ユーザで認証したＩＰｓｅｃＳＡに基づいて２次のＩＰｓｅｃを適用する２次ＩＰｓｅｃ手段とを備え、認証サーバによりユーザＩＤおよびパスワードによる認証を行い、当該認証サーバから取得した識別子および共通鍵を用いて上記２次のＩＰｓｅｃを適用するネットワーク機器を要旨としている。

また、請求項２に記載されるように、請求項１に記載のネットワーク機器において、送信側と宛先側で互いに決めた識別子とその識別子に対する共通鍵とを利用して認証を行い、認証した識別子をペイロードに適用する２次ＩＰｓｅｃのセレクタに利用するようにすることができる。

また、請求項３に記載されるように、請求項１に記載のネットワーク機器において、ユーザ認証のための識別子および共通鍵をサーバで管理するようにすることができる。

また、請求項４に記載されるように、請求項１に記載のネットワーク機器において、１次のＩＰｓｅｃを作成する段階で、２次のＩＰｓｅｃをサポートしている相手かどうかを識別する能力交換手段を備え、上記能力交換手段は、ＰｒｉｖａｔｅＵＳＥによるパケット交換により問い合わせを行うようにすることができる。

また、請求項５に記載されるように、請求項１に記載のネットワーク機器において、上記ユーザによる認証は、データベースにＩＤが存在し、かつ、アクセス条件に当てはまる場合に適正であると判断するようにすることができる。

また、請求項６に記載されるように、請求項１に記載のネットワーク機器において、宛先側の機器では、１次のＩＰｓｅｃの暗号解除後に機器のアクセス許可があり、かつ、２次のＩＰｓｅｃの暗号解除後にユーザのアクセス許可がある場合に受信パケットを上位の処理に送るようにすることができる。

また、請求項７、８に記載されるように、アクセス制御方法として構成することができる。

本発明のネットワーク機器にあっては、２重のＩＰｓｅｃを適用することにより、ＩＰｓｅｃの制御を、機器のみでなくユーザ等を単位に行うことができ、適切なアクセスコントロールを行うことができる。

以下、本発明の好適な実施形態につき説明する。

＜システム構成＞
図１は本発明のネットワーク機器を用いたネットワークシステムの一実施形態を示す全体構成図である。

図１において、ネットワーク３上にはネットワーク機器１Ａ、１Ｂと認証サーバ（ＸＡＵＴＨサーバ）２とが接続されている。なお、認証サーバ２は必須ではなく、必要に応じて設けられるものである。また、後述する動作説明ではネットワーク機器１Ａとネットワーク機器１Ｂとの間で通信するものとしているが、同一のネットワーク３上に限らず、ルータ等を介して他のセグメントにあるネットワーク機器と通信することも可能である。

図２はネットワーク機器１（１Ａ、１Ｂ）の内部構成例を示す図である。

図２において、ネットワーク機器１は、通信を利用するアプリケーション１１と、ネットワーク制御を行うネットワーク処理部１２と、ネットワーク処理部１２の内部にあって鍵交換処理を行うＩＫＥ処理部１３と、ＩＰｓｅｃの設定を保持するＩＰｓｅｃＳＡデータベース１４と、ＩＰｖ４（Internet Protocol version 4）およびＩＰｖ６（Internet Protocol version 6）のＩＰレイヤの処理を行うＩＰ処理部１５と、ＩＰ処理部１５の内部にあって１次ＩＰｓｅｃおよび２次ＩＰｓｅｃの処理を行うＩＰｓｅｃ処理部１６と、ネットワークとのインタフェースを行うＩ／Ｆ処理部１７とを備えている。

＜基本的な２重ＩＰｓｅｃ＞
図３はＩＰｓｅｃＳＡデータベース１４の例を示す図であり、（ａ）は１次ＩＰｓｅｃＳＡ、（ｂ）は２次ＩＰｓｅｃＳＡを示している。（ａ）に示す１次ＩＰｓｅｃＳＡは、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、暗号化方式、認証方式等の情報を保持している。（ｂ）に示す２次ＩＰｓｅｃＳＡは、ユーザを識別する識別ＩＤ（送信側、宛先側で共通の識別子）、送信元ポート、宛先ポート、暗号化方式、認証方式等の情報を保持している。

図４は２重ＩＰｓｅｃのためのネゴシエーションの例を示す図である。

図４において、ネットワーク機器１Ａが送信側、ネットワーク機器１Ｂが宛先側であるものとすると、ネットワーク機器１Ａからの要求に応じて、１次ＩＰｓｅｃＳＡ（図３（ａ））に基づき、１次ＩＰｓｅｃＰｈａｓｅ１によるデバイス認証（ＰｒｅＳｈａｒｅＫｅｙ、デジタル署名、公開鍵認証等）および鍵交換を行い（ステップＳ１０１）、続いて１次ＩＰｓｅｃＰｈａｓｅ２による１次ＩＰｓｅｃの暗号化方式、暗号鍵、ＳＡの決定を行う（ステップＳ１０２）。これ以降は１次ＩＰｓｅｃによる暗号化通信となる。

次いで、２次ＩＰｓｅｃＳＡ（図３（ｂ））に基づき、２次ＩＰｓｅｃＰｈａｓｅ１によるユーザ認証（ＦＱＤＮ（Fully Qualified Domain Name）、Ｘ．５００等で指定させたユーザＩＤによる、ＰｒｅＳｈａｒｅＫｅｙ、デジタル署名、公開鍵認証等）および鍵交換を行い（ステップＳ１０３）、続いて２次ＩＰｓｅｃＰｈａｓｅ２による２次ＩＰｓｅｃの暗号化方式、暗号鍵、ＳＡの決定を行う（ステップＳ１０４）。これ以降は１次ＩＰｓｅｃおよび２次ＩＰｓｅｃが適用された暗号化通信を行う（ステップＳ１０５）。

図５は２次ＩＰｓｅｃＰｈａｓｅ１によるユーザ認証の宛先側での処理例を示すフローチャートである。

図５において、処理を開始すると（ステップＳ１１１）、送信側のネットワーク機器１Ａから送信されたＩＤでＩＰｓｅｃＳＡデータベース１４を検索し（ステップＳ１１２）、ＩＤが存在するか否か判断する（ステップＳ１１３）。

ＩＤが存在する場合（ステップＳ１１３のＹＥＳ）、ＩＰｓｅｃＳＡデータベース１４をさらに検索し（ステップＳ１１４）、アクセス条件に当てはまるか判断し（ステップＳ１１５）、アクセス条件に当てはまる場合（ステップＳ１１５のＹＥＳ）は共通鍵を確認し（ステップＳ１１６）、処理を終了する（ステップＳ１１８）。

一方、ＩＤが存在しない場合（ステップＳ１１３のＮＯ）もしくはアクセス条件に当てはまらない場合（ステップＳ１１５のＮＯ）は、アクセス破棄のコマンドを送信側に送信し（ステップＳ１１７）、処理を終了する（ステップＳ１１８）。

図６〜図９は１次ＩＰｓｅｃおよび２次ＩＰｓｅｃの適用される通信データの構造を示す図であり、図６は２次がＡＨ（Authentication Header）、１次がＥＳＰ（Encapsulating Security Payload）による場合、図７は２次がＥＳＰ、１次がＥＳＰによる場合、図８は２次がＡＨ、１次がＡＨによる場合、図９は２次がＥＳＰ、１次がＡＨによる場合である。１次ＩＰｓｅｃおよび２次ＩＰｓｅｃのそれぞれにつき、トランスポートモードの場合とトンネルモードの場合とを併記してある。１次ＩＰｓｅｃの適用されるペイロードにはユーザを識別するセレクタとしての識別子データが付加されている。

図１０は２重ＩＰｓｅｃのデータ復号の処理例を示すフローチャートである。

図１０において、処理を開始すると（ステップＳ１２１）、１次ＩＰｓｅｃの暗号を解除し（ステップＳ１２２）、ＩＰｓｅｃＳＡデータベース１４を参照してデバイスのアクセス許可があるか否か判断する（ステップＳ１２３）。

デバイスのアクセス許可がある場合（ステップＳ１２３のＹＥＳ）、２次ＩＰｓｅｃの暗号を解除し（ステップＳ１２４）、ＩＰｓｅｃＳＡデータベース１４を参照してユーザを示す識別子のアクセス許可があるか否か判断し（ステップＳ１２５）、識別子のアクセス許可がある場合（ステップＳ１２５のＹＥＳ）、パケットを上位の処理に送り（ステップＳ１２６）、処理を終了する（ステップＳ１２８）。

一方、デバイスのアクセス許可がない場合（ステップＳ１２３のＮＯ）もしくは識別子のアクセス許可がない場合（ステップＳ１２５のＮＯ）は、パケットを破棄し（ステップＳ１２７）、処理を終了する（ステップＳ１２８）。

なお、上述した方式では、ユーザの認証データを予め共通のデータとしてＩＰｓｅｃＳＡデータベース１４に入れておく必要がある。しかし、これではアクセス制御のために機器ごとに認証データを入れ込む必要があり、認証データを予め入れておくことは漏洩の可能性があるため運用上危険である。この点を改善するため、認証データにデジタル署名を利用することが望ましい。

この場合、共通の識別ＩＤ、共通の認証キーを使うのではなく、この部分について外部サーバを利用したデジタル署名認証を実施する。このときの識別ＩＤは、Ｘ．５００のツリー構造をとり、この識別子をＩＤとして埋め込んで２次ＩＰｓｅｃＳＡを作成する。この場合の２次ＩＰｓｅｃＳＡの例を図１１に示す。１次ＩＰｓｅｃＳＡは図３（ａ）に示したものと同様である。

＜ＸＡＵＴＨによる認証を用いた２重ＩＰｓｅｃ＞
上述した実施例では、ユーザの制御情報を予め共通データとしてＩＰｓｅｃＳＡデータベース１４に入れておく必要がある。このため、機器が多くなると設定が煩雑になる。そこで、ＸＡＵＴＨによるユーザ、パスワード認証と連動させて２次ＩＰｓｅｃＳＡを生成することにより、アクセス制御をサーバで管理することが可能となる。

図１２はＸＡＵＴＨによる認証を用いた２重ＩＰｓｅｃのネゴシエーションの例を示す図である。

図１２において、ネットワーク機器１Ａが送信側、ネットワーク機器１Ｂが宛先側であるものとすると、ネットワーク機器１Ａからの要求に応じて、１次ＩＰｓｅｃＰｈａｓｅ１によるデバイス認証および鍵交換を行い（ステップＳ２０１）、続いて認証サーバ（ＸＡＵＴＨ）２によるユーザ、パスワードの認証を行う（ステップＳ２０２）。そして、そのユーザ名をＦＱＤＮ名として２次ＩＰｓｅｃＳＡのセレクタに設定する。これにより、ユーザ認証されたＳＡを作成する。

次いで、１次ＩＰｓｅｃＰｈａｓｅ２による１次ＩＰｓｅｃの暗号化方式、暗号鍵、ＳＡの決定を行う（ステップＳ２０３）。これ以降は１次ＩＰｓｅｃによる暗号化通信となる。

次いで、２次ＩＰｓｅｃＰｈａｓｅ１によるデバイス認証および鍵交換を行い（ステップＳ２０４）、続いて２次ＩＰｓｅｃＰｈａｓｅ２による２次ＩＰｓｅｃの暗号化方式、暗号鍵、ＳＡの決定を行う（ステップＳ２０５）。これ以降は１次ＩＰｓｅｃおよび２次ＩＰｓｅｃが適用された暗号化通信を行う（ステップＳ２０６）。

なお、ＸＡＵＴＨによるユーザ、パスワードの認証（ステップＳ２０２）は、認証データの通信を伴い、最低限の暗号化がされている必要があることから、１次ＩＰｓｅｃＰｈａｓｅ１（ステップＳ２０１）の後である必要があるが、２次ＩＰｓｅｃＰｈａｓｅ２（ステップＳ２０５）の前までであれば、位置を変更することができる。すなわち、上述した１次ＩＰｓｅｃＰｈａｓｅ１（ステップＳ２０１）の直後の他に、１次ＩＰｓｅｃＰｈａｓｅ２（ステップＳ２０３）の直後、もしくは、２次ＩＰｓｅｃＰｈａｓｅ１（ステップＳ２０４）の直後に置くことができる。ただし、Ｐｈａｓｅ１の処理は比較的に重いものであるとともに、認証に失敗してそれまでの処理が無駄になることもあることから、１次ＩＰｓｅｃＰｈａｓｅ１（ステップＳ２０１）の直後が最も好ましい。

＜ＰｒｉｖａｔｅＵＳＥによる能力交換を用いた２重ＩＰｓｅｃ＞
上述した各実施例では、１次ＩＰｓｅｃ、２次ＩＰｓｅｃ両方が生成されないと通信ができない状態である。このため、機器として状態確認するために用いるＵＤＰなどのネットワーク環境を確認するデータや、機器同士が状態を確認するデータ等については、特にユーザ認証を必要としない状況が存在する。そこで、１次ＩＰｓｅｃのみで処理するセレクタを設定し、２次ＩＰｓｅｃが利用できるかどうかを指定することができる仕組みを提供することにより、ユーザ認証が必要なものと必要でないものの制御を可能としている。これにより、１次ＩＰｓｅｃのみのものは重要性の低い情報のみを提供し、２次ＩＰｓｅｃを提供するものは重要性の高い情報を提供することができる。

図１３はＩＰｓｅｃＳＡデータベース１４の例を示す図であり、２次ＩＰｓｅｃＳＡは、送信元識別ＩＤ、宛先、送信元ポート、宛先ポート、暗号化方式、認証方式等の情報を保持している。１次ＩＰｓｅｃＳＡは図３（ａ）に示したものと同様である。

図１４はＰｒｉｖａｔｅＵＳＥによる能力交換を用いた２重ＩＰｓｅｃのネゴシエーションの例を示す図である。

図１４において、ネットワーク機器１Ａが送信側、ネットワーク機器１Ｂが宛先側であるものとすると、ネットワーク機器１Ａからの要求に応じて、１次ＩＰｓｅｃＰｈａｓｅ１によるデバイス認証および鍵交換を行い（ステップＳ３０１）、続いてＰｒｉｖａｔｅＵＳＥにより２次ＩＰｓｅｃをサポートしているか否かの確認を行う（ステップＳ３０２）。図１５はＰｒｉｖａｔｅＵＳＥによるパケット交換の様子を示す図であり、ＩＳＡＫＭＰ（Internet Security Association Key Management Protocol）ヘッダにＰｒｉｖａｔｅＵＳＥデータを付加してデータ通信することで能力交換を行う。

図１４に戻り、続いて、１次ＩＰｓｅｃＰｈａｓｅ２による１次ＩＰｓｅｃの暗号化方式、暗号鍵、ＳＡの決定を行う（ステップＳ３０３）。これ以降は１次ＩＰｓｅｃによる暗号化通信となる。

その後、ＰｒｉｖａｔｅＵＳＥによる能力交換（ステップＳ３０２）で２次ＩＰｓｅｃをサポートしていない場合は、２次ＩＰｓｅｃの処理ができないときの動作を別途規定しておき、その規定に従って処理する。２次ＩＰｓｅｃをサポートしていない状況もセレクタとして設定する（図１３）。

次いで、２次ＩＰｓｅｃをサポートしている場合は、続いて、２次ＩＰｓｅｃＰｈａｓｅ１によるデバイス認証および鍵交換を行い（ステップＳ３０４）、続いて２次ＩＰｓｅｃＰｈａｓｅ２による２次ＩＰｓｅｃの暗号化方式、暗号鍵、ＳＡの決定を行う（ステップＳ３０５）。これ以降は１次ＩＰｓｅｃおよび２次ＩＰｓｅｃが適用された暗号化通信を行う（ステップＳ３０６）。

なお、ＰｒｉｖａｔｅＵＳＥによる２次ＩＰｓｅｃをサポートしているか否かの確認（ステップＳ３０２）を１次ＩＰｓｅｃＰｈａｓｅ１（ステップＳ３０１）の直後に行う例につき図示したが、ＰｒｉｖａｔｅＵＳＥによる能力交換は平文の状態でも問題ないことから１次ＩＰｓｅｃＰｈａｓｅ１（ステップＳ３０１）の直前でもよく、あるいは、１次ＩＰｓｅｃＰｈａｓｅ２（ステップＳ３０３）の直後でもよい。

図１６は２重ＩＰｓｅｃのデータ復号の処理例を示すフローチャートである。

図１６において、処理を開始すると（ステップＳ３１１）、１次ＩＰｓｅｃの暗号を解除し（ステップＳ３１２）、ＩＰｓｅｃＳＡデータベース１４を参照してデバイスのアクセス許可があるか否か判断する（ステップＳ３１３）。

デバイスのアクセス許可がある場合（ステップＳ３１３のＹＥＳ）、２次ＩＰｓｅｃが適用されているか否か判断する（ステップＳ３１４）。

２次ＩＰｓｅｃが適用されている場合（ステップＳ３１４のＹＥＳ）、２次ＩＰｓｅｃの暗号を解除し（ステップＳ３１５）、ＩＰｓｅｃＳＡデータベース１４を参照してユーザを示す識別子のアクセス許可があるか否か判断し（ステップＳ３１６）、識別子のアクセス許可がある場合（ステップＳ３１６のＹＥＳ）、パケットを上位の処理に送り（ステップＳ３１７）、処理を終了する（ステップＳ３２０）。

一方、２次ＩＰｓｅｃが適用されていない場合（ステップＳ３１４のＮＯ）もしくは識別子のアクセス許可がない場合（ステップＳ３１６のＮＯ）、アクセス許可されたプロトコルおよびポートであるか否か判断し（ステップＳ３１８）、アクセス許可されたプロトコルおよびポートである場合（ステップＳ３１８のＹＥＳ）、パケットを上位の処理に送り（ステップＳ３１７）、処理を終了する（ステップＳ３２０）。

また、デバイスのアクセス許可がない場合（ステップＳ３１３のＮＯ）もしくはアクセス許可されたプロトコルおよびポートでない場合（ステップＳ３１８のＮＯ）は、パケットを破棄し（ステップＳ３１９）、処理を終了する（ステップＳ３２０）。

＜総括＞
以上のように、本発明にあっては、機器で認証したＩＰｓｅｃＳＡとさらにユーザで認証したＩＰｓｅｃＳＡを利用できるようにし、機器を共通で使用する場合に異なるＩＰｓｅｃＳＡを作成することができるようしているため、機器を複数のユーザが共有で使用していても認証データを変えることによりアクセス制御することが可能となる。

例えば、一つのＭＦＰ等の機器を複数のユーザが共有する環境において、port9100からのＲＯＷデータ印刷、ＬＰＲ等の、プロトコル自体に認証機構を持っていないものを使う場面にあっても、ＩＰｓｅｃを２重にしてユーザ認証することができるため、印刷を許可された人と許可されない人を分けて利用させることができる。

同様に、ｒｓｈコマンドの実行やＵＤＰによるＤＮＳの名前解決等においても、許可されたユーザについてのみ処理させることができる。

この場合、ＳＳＬ等のプロトコル依存の暗号化と比べ、プロトコルによらずにＴＣＰ／ＩＰのレイヤで機器の認証、個人の認証を実施できるため、アプリケーションを変更することなく適用することができる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

本発明のネットワーク機器を用いたネットワークシステムの一実施形態を示す全体構成図である。ネットワーク機器の内部構成例を示す図である。ＩＰｓｅｃＳＡデータベースの例を示す図である。２重ＩＰｓｅｃのためのネゴシエーションの例を示す図である。２次ＩＰｓｅｃＰｈａｓｅ１によるユーザ認証の宛先側での処理例を示すフローチャートである。２次がＡＨ、１次がＥＳＰによる場合の通信データの構造を示す図である。２次がＥＳＰ、１次がＥＳＰによる場合の通信データの構造を示す図である。２次がＡＨ、１次がＡＨによる場合の通信データの構造を示す図である。２次がＥＳＰ、１次がＡＨによる場合の通信データの構造を示す図である。２重ＩＰｓｅｃのデータ復号の処理例を示すフローチャートである。ＩＰｓｅｃＳＡデータベースの例を示す図である。ＸＡＵＴＨによる認証を用いた２重ＩＰｓｅｃのネゴシエーションの例を示す図である。ＩＰｓｅｃＳＡデータベースの例を示す図である。ＰｒｉｖａｔｅＵＳＥによる能力交換を用いた２重ＩＰｓｅｃのネゴシエーションの例を示す図である。ＰｒｉｖａｔｅＵＳＥによるパケット交換の様子を示す図である。２重ＩＰｓｅｃのデータ復号の処理例を示すフローチャートである。

符号の説明

１、１Ａ、１Ｂネットワーク機器
１１アプリケーション
１２ネットワーク処理部
１３ＩＫＥ処理部
１４ＩＰｓｅｃＳＡデータベース
１５ＩＰ処理部
１６ＩＰｓｅｃ処理部
１７Ｉ／Ｆ処理部
２認証サーバ
３ネットワーク

Claims

機器で認証したＩＰｓｅｃＳＡに基づいて通信データに１次のＩＰｓｅｃを適用する１次ＩＰｓｅｃ手段と、
１次のＩＰｓｅｃが適用されたペイロードにつき、ユーザで認証したＩＰｓｅｃＳＡに基づいて２次のＩＰｓｅｃを適用する２次ＩＰｓｅｃ手段とを備え、
認証サーバによりユーザＩＤおよびパスワードによる認証を行い、当該認証サーバから取得した識別子および共通鍵を用いて上記２次のＩＰｓｅｃを適用することを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
送信側と宛先側で互いに決めた識別子とその識別子に対する共通鍵とを利用して認証を行い、認証した識別子をペイロードに適用する２次ＩＰｓｅｃのセレクタに利用することを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
ユーザ認証のための識別子および共通鍵をサーバで管理することを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
１次のＩＰｓｅｃを作成する段階で、２次のＩＰｓｅｃをサポートしている相手かどうかを識別する能力交換手段を備え、
上記能力交換手段は、ＰｒｉｖａｔｅＵＳＥによるパケット交換により問い合わせを行うことを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
上記ユーザによる認証は、データベースにＩＤが存在し、かつ、アクセス条件に当てはまる場合に適正であると判断することを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
宛先側の機器では、１次のＩＰｓｅｃの暗号解除後に機器のアクセス許可があり、かつ、２次のＩＰｓｅｃの暗号解除後にユーザのアクセス許可がある場合に受信パケットを上位の処理に送ることを特徴とするネットワーク機器。
機器で認証したＩＰｓｅｃＳＡに基づいて通信データに１次のＩＰｓｅｃを適用する１次ＩＰｓｅｃ工程と、
１次のＩＰｓｅｃが適用されたペイロードにつき、ユーザで認証したＩＰｓｅｃＳＡに基づいて２次のＩＰｓｅｃを適用する２次ＩＰｓｅｃ工程とを備え、
認証サーバによりユーザＩＤおよびパスワードによる認証を行い、当該認証サーバから取得した識別子および共通鍵を用いて上記２次のＩＰｓｅｃを適用することを特徴とするアクセス制御方法。
請求項７に記載のアクセス制御方法において、
送信側と宛先側で互いに決めた識別子とその識別子に対する共通鍵とを利用して認証を行い、認証した識別子をペイロードに適用する２次ＩＰｓｅｃのセレクタに利用することを特徴とするアクセス制御方法。