(57)【特許請求の範囲】
【請求項１】
モバイルデバイスにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）ロケーションプラットフォーム（ＳＬＰ）の公開鍵を含むサーバ証明書を受信することと、
前記モバイルデバイスにおいて、前記モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納することであって、前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含むことと、
前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証するために前記ＳＬＰに前記少なくとも１つのセキュリティクレデンシャルを送信することであって、前記少なくとも１つのセキュリティクレデンシャルは、前記ＳＬＰの秘密鍵によって復号されるように構成されたメッセージにおいて送信されることと、を備える、認証の方法。
【請求項２】
前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスの公開鍵を含む請求項１に記載の方法。
【請求項３】
前記デバイス識別子は、前記モバイルデバイスの国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び一連番号のうちの少なくとも１つを含む請求項１に記載の方法。
【請求項４】
前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス証明書を含む請求項１に記載の方法。
【請求項５】
前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのユニバーサル集積スマートカード（ＵＩＣＣ）、前記モバイルデバイスのメモリのセキュアな部分、又はそれらの任意の組み合わせにおいて格納される請求項１に記載の方法。
【請求項６】
前記モバイルデバイスは、ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）を含む請求項１に記載の方法。
【請求項７】
前記モバイルデバイスは、米国電気電子学会（ＩＥＥＥ）８０２．１１規格に準拠して動作するネットワークを介して前記ＳＬＰに前記少なくとも１つのセキュリティクレデンシャルを送信する請求項１に記載の方法。
【請求項８】
セキュアユーザプレーンロケーション（ＳＵＰＬ）ロケーションプラットフォーム（ＳＬＰ）の公開鍵を含むサーバ証明書を受信し、
モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納するように構成された非一時的なメモリであって、前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含む非一時的なメモリと、
前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証するために前記ＳＬＰに前記少なくとも１つのセキュリティクレデンシャルを送信することを前記モバイルデバイスに行わせるように構成されたプロセッサであって、前記少なくとも１つのセキュリティクレデンシャルは、前記ＳＬＰの秘密鍵によって復号されるように構成されたメッセージにおいて送信されるように構成されるプロセッサと、を備える、装置。
【請求項９】
前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス証明書、前記モバイルデバイスの公開鍵、前記モバイルデバイスの国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び一連番号のうちの少なくとも１つを含む請求項８に記載の装置。
【請求項１０】
モバイルデバイスにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）ロケーションプラットフォーム（ＳＬＰ）の公開鍵を含むサーバ証明書を受信するための手段と、
モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納するための手段であって、前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含む手段と、
前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証するために前記ＳＬＰに前記少なくとも１つのセキュリティクレデンシャルを送信することを前記モバイルデバイスに行わせるための手段であって、前記少なくとも１つのセキュリティクレデンシャルは、前記ＳＬＰの秘密鍵によって復号されるように構成されたメッセージにおいて送信される手段と、を備える、装置。
【請求項１１】
前記モバイルデバイスは、ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）を含む請求項１０に記載の装置。
【請求項１２】
セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスに、ウェブサーバの公開鍵を含むサーバ証明書を送信することと、
前記ウェブサーバにおいて、前記モバイルデバイスからメッセージを受信することであって、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含むことと、
前記ウェブサーバの秘密鍵を用いて前記メッセージを復号することと、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信することと、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとし
て認証することと、を備える、方法。
【請求項１３】
前記セキュリティクレデンシャルは、前記モバイルデバイスの公開鍵を含むデバイス証明書を含む請求項１２に記載の方法。
【請求項１４】
前記セキュリティクレデンシャルは、前記モバイルデバイスの国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び一連番号のうちの少なくとも１つを含む請求項１２に記載の方法。
【請求項１５】
前記ユーザ識別情報は、識別子と、パスワードと、を含む請求項１２に記載の方法。
【請求項１６】
プロセッサと、
前記プロセッサに結合されたメモリと、を備え、
前記メモリは、命令を格納するように構成され、前記命令が前記プロセッサによって実行されたときに、前記プロセッサは、
セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスに、ウェブサーバの公開鍵を含むサーバ証明書を送信することと、
前記ウェブサーバにおいて、前記モバイルデバイスからメッセージを受信することであって、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含むことと、
前記ウェブサーバの秘密鍵を用いて前記メッセージを復号することと、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信することと、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとし
て認証することと、を行なうように構成される、装置。
【請求項１７】
前記セキュリティクレデンシャルは、前記モバイルデバイスの公開鍵を含むデバイス証明書を含む請求項１６に記載の装置。
【請求項１８】
セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスに、ウェブサーバの公開鍵を含むサーバ証明書を送信するための手段と、
前記ウェブサーバにおいて、前記モバイルデバイスからメッセージを受信するための手段であって、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含む手段と、
前記ウェブサーバの秘密鍵を用いて前記メッセージを復号するための手段と、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信するための手段と、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとし
て認証するための手段と、を備える、装置。
【請求項１９】
前記セキュリティクレデンシャルは、前記モバイルデバイスの公開鍵を含むデバイス証明書を含む請求項１８に記載の装置。
【請求項２０】
プロセッサによって実行されたときに、
セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスに、ウェブサーバの公開鍵を含むサーバ証明書を送信することと、
前記ウェブサーバにおいて、前記モバイルデバイスからメッセージを受信することであって、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含むことと、
前記ウェブサーバの秘密鍵を用いて前記メッセージを復号することと、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信することと、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとし
て認証することと、を前記プロセッサに行わせる命令を備える、非一時的なプロセッサによって読み取り可能な格納媒体。
【請求項２１】
前記セキュリティクレデンシャルは、前記モバイルデバイスの公開鍵を含むデバイス証明書を含む請求項２０に記載の非一時的なプロセッサによって読み取り可能な格納媒体。
【請求項２２】
プロセッサによって実行されたときに、
セキュアユーザプレーンロケーション（ＳＵＰＬ）ロケーションプラットフォーム（ＳＬＰ）の公開鍵を含むサーバ証明書を受信し、モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納することであって、前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含むことと、
前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証するために前記ＳＬＰに前記少なくとも１つのセキュリティクレデンシャルを送信することであって、前記少なくとも１つのセキュリティクレデンシャルは、前記ＳＬＰの秘密鍵によって復号されるように構成されたメッセージにおいて送信されるように構成されることと、を前記プロセッサに行わせる命令を備える、非一時的なプロセッサによって読み取り可能な格納媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概して、セキュアユーザプレーンロケーション（ＳＵＰＬ）システムにおける認証に関するものである。
【背景技術】
【０００２】
技術が進歩した結果としてコンピューティングデバイスがますます小型化しかつますます強力になってきている。例えば、現在では、小型、軽量、そしてユーザによる持ち運びが容易な無線コンピューティングデバイスを含む様々な携帯式のパーソナルコンピューティングデバイス、例えば、携帯式の無線電話、パーソナルデジタルアシスタント（ＰＤＡ）、及びページングデバイス、が存在する。より具体的には、携帯式の無線電話、例えば、携帯電話及びインターネットプロトコル（ＩＰ）電話、は、無線ネットワークを通じて音声パケット及びデータパケットを通信することができる。さらに、数多くの該無線電話は、それらに組み込まれているその他のタイプのデバイスを含む。例えば、無線電話は、デジタルスチルカメラと、デジタルビデオカメラと、デジタルレコーダと、オーディオファイルプレーヤーと、も含むことができる。
【０００３】
無線電話は、位置に基づくサービスを可能にするための位置決定ハードウェア／ソフトウェアも装備することができる。例えば、無線電話は、全地球測位システム（ＧＰＳ）トランシーバを含むことができる。無線電話は、ネットワークによって補助された測位情報を受信することもできる（例えば、測位情報に基づいて複数のネットワーク塔間の無線電話の位置の三角測量を行う）。
【０００４】
セキュアユーザプレーンロケーション（ｓｅｃｕｒｅ  ｕｓｅｒ  ｐｌａｎｅ  ｌｏｃａｔｉｏｎ（ＳＵＰＬ））は、無線通信システムにおける位置に基づくサービスを可能にするために使用することができる技術規格である。ＳＵＰＬアーキテクチャは、２つの構成要素、すなわち、ＳＵＰＬによってイネーブルにされる端末（ＳＵＰＬＥ  ｅｎａｂｌｅｄ  ｔｅｒｍｉｎａｌ）（ＳＥＴ）及びネットワークによってアクセス可能なサーバとして実装することができるＳＵＰＬロケーションプラットフォーム（ＳＬＰ）、を含むことができる。ＳＵＰＬサービスを利用する前に、ＳＥＴ及び／又はＳＬＰが互いに認証することが要求される。しかしながら、ＳＵＰＬでのセキュリティ及び認証は、どのようなアクセスネットワークがＳＥＴによって使用されるかに依存することがある。例えば、３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ（第３世代パートナーシッププロジェクト）（３ＧＰＰ）又は３ＧＰＰ２ネットワークでの認証は、Ｗｏｒｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ（マイクロ波アクセスのための世界的相互運用性）（ＷｉＭＡＸ）での認証とは異なるセキュリティ方式を利用することができる。さらに、その他の利用可能なネットワーク、例えば、米国電気電子学会（ＩＥＥＥ）８０．１１（Ｗｉ−Ｆｉ）ネットワーク、の使用は、ＳＵＰＬ２．０において利用可能なセキュリティメカニズムによって完全にサポートされていないことがあり、それは、屋内に存在するか又はセルラーネットワーク状態が不良である無線電話がＳＵＰＬに基づく機能を利用するのを不能にすることがある。
【発明の概要】
【０００５】
ＳＵＰＬシステムにおける認証のシステム及び方法が開示される。開示されるシステム及び方法は、３ＧＰＰと、３ＧＰＰ２と、ＷｉＭＡＸと、Ｗｉ−Ｆｉネットワークと、を含む様々なアクセスネットワークに関するＳＥＴとＳＬＰとの間での相互認証をサポートすることができる。開示される技法は、ＳＵＰＬサーバ及びＳＥＴが、複数の認証方法のうちのいずれが使用されるべきかについて交渉するのを可能にすることができる。ここにおいて開示される認証方法は、アクセスネットワークタイプから独立した証明書に基づく認証を含み、ただし、アクセスネットワークタイプから独立した証明書に基づく認証に限定されない。特定の実装では、証明書に基づく認証は、認証中にＳＥＴとＳＬＰとの間でのセキュア（ｓｅｃｕｒｅ）な通信を可能にするためにトランスポート層セキュリティ（ＴＬＳ）を使用することができる。開示される技法は、ＳＵＰＬセッションの開始及び再開に対してもセキュリティを適用する。追加の実施形態では、認証は、証明書に基づく認証を介しての代わりに複数の識別子／パスワードの対を介して行うことができる。
【０００６】
特定の実施形態では、方法は、モバイルデバイスにおいて、モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャル（ｓｅｃｕｒｉｔｙ  ｃｒｅｄｅｎｔｉａｌ）を格納することを含み、セキュリティクレデンシャルは、モバイルデバイスのデバイス識別子を含む。方法は、デバイス識別子と格納されたデバイス識別子との比較に基づいてモバイルデバイスがセキュアユーザプレーンロケーション（ＳＵＰＬ）ユーザと関連付けられているとして認証するためにＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に少なくとも１つのセキュリティクレデンシャルを送信することも含む。
【０００７】
他の特定の実施形態では、非一時的なプロセッサによって読み取り可能な媒体は、プロセッサによって実行されたときに、モバイルデバイスに送信されるべきメッセージをＳＵＰＬサーバにおいて生成することをプロセッサに行わせる命令を含む。メッセージは、ＳＵＰＬサーバの識別子とＳＵＰＬサーバの公開鍵とを含むサーバ証明書と、モバイルデバイスのデバイス証明書の要求とを含む。命令は、プロセッサによって実行されたときに、モバイルデバイスのデバイス証明書を含む応答をモバイルデバイスから受信することもプロセッサに行わせる。命令は、プロセッサによって実行されたときに、デバイス証明書に基づいてモバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証することをプロセッサにさらに行わせる。
【０００８】
他の特定の実施形態では、装置は、プロセッサと、プロセッサに結合されたメモリと、を含む。メモリは、モバイルデバイスによってサポートされる１つ以上のＴＬＳ暗号スイート（ｃｉｐｈｅｒ  ｓｕｉｔｅ）（暗号の組）の表示（ｉｎｄｉｃａｔｉｏｎ）をモバイルデバイスからＳＵＰＬサーバにおいて受信するためにプロセッサによって実行可能な命令を格納する。命令は、１つ以上のＴＬＳ暗号スイートがＳＵＰＬサーバによってサポートされるＴＬＳ事前共有鍵（ＴＬＳ−ＰＳＫ）暗号スイートを含むかどうかを決定するためにもプロセッサによって実行可能である。命令は、１つ以上のＴＬＳ暗号スイートがＳＵＰＬサーバによってサポートされるＴＬＳ−ＰＳＫ暗号スイートを含むと決定したことに応答して、モバイルデバイスを認証するための汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく認証プロセスを実施するためにプロセッサによってさらに実行可能である。命令は、１つ以上のＴＬＳ暗号スイートがＳＵＰＬサーバによってサポートされるＴＬＳ−ＰＳＫ暗号スイートを含まないと決定したことに応答して、ＳＵＰＬサーバが証明書に基づく認証方法をサポートするかどうかを決定するためにプロセッサによって実行可能である。命令は、ＳＵＰＬサーバが証明書に基づく認証方法をサポートすると決定したことに応答して、モバイルデバイスにサーバ証明書を送信することとモバイルデバイスからデバイス証明書を受信することとを含む証明書に基づく認証プロセスを実施するためにもプロセッサによって実行可能である。命令は、ＳＵＰＬサーバが証明書に基づく認証方法をサポートしないと決定したことに応答して、モバイルデバイスが３ＧＰＰネットワーク又は３ＧＰＰ２ネットワークに接続されているときに代替クライアント認証（ＡＣＡ）に基づく認証方法を実施するためにプロセッサによってさらに実行可能であることができる。
【０００９】
他の特定の実施形態では、方法は、モバイルデバイスにおいて、ＳＵＰＬサーバとモバイルデバイスとの間でＳＵＰＬセッションを開始するためのセッション開始メッセージ（例えば、ＳＵＰＬ  ＩＮＩＴメッセージを含む）をＳＵＰＬサーバから受信することを含む。方法は、モバイルデバイスがセッション開始メッセージを受信する前にモバイルデバイスがＳＵＰＬサーバから有効なセッション開始メッセージ鍵（例えば、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを含む）を受信したことに応答して、セッション開始メッセージ鍵を用いてセッション開始メッセージを認証することと、セッション開始メッセージの成功裏の認証に応答してＳＵＰＬサーバとのＳＵＰＬセッションを開始することと、も含む。
【００１０】
他の特定の実施形態では、装置は、プロセッサと、プロセッサに結合されたメモリと、を含む。メモリは、モバイルデバイスにおいて、ＳＵＰＬサーバとモバイルデバイスとの間でＳＵＰＬセッション（例えば、一般的ＳＵＰＬセッション（ＧＳＳ））を継続するためのセッション再開メッセージ（例えば、ＳＵＰＬ  ＲＥＩＮＩＴメッセージを含む）をＳＵＰＬサーバから受信するためにプロセッサによって実行可能な命令を格納する。命令は、モバイルデバイスがセッション再開メッセージを受信する前にモバイルデバイスがＳＵＰＬサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、セッション開始メッセージ鍵を用いてセッション再開メッセージを認証し及びセッション再開メッセージの成功裏の認証に応答してＳＵＰＬサーバとのＳＵＰＬセッションを継続するためにプロセッサによって実行可能でもある。
【００１１】
他の特定の実施形態では、方法は、モバイルデバイスからＳＵＰＬサーバにメッセージを送信することを含み、メッセージは、（例えば、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの状態を示す）ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓ（ルートキー状態）パラメータを含む。例えば、ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータは、メッセージのＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓ（能力）パラメータに含めることができる。さらに他の実施形態では、方法は、ＳＵＰＬサーバからモバイルデバイスにＳＵＰＬ  ＥＮＤメッセージを送信することを含み、ＳＵＰＬ  ＥＮＤメッセージは、（例えば、新しいＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを提供する）ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅ（キー応答）パラメータを含む。他の特定の実施形態では、方法は、Ｐｒｏｔｅｃｔｉｏ  Ｌｅｖｅｌ（保護レベル）パラメータを含むＳＵＰＬ  ＩＮＩＴメッセージをＳＵＰＬサーバからモバイルデバイスに送信することを含む。さらに他の実施形態では、方法は、Ｐｒｏｔｅｃｔｉｏ  Ｌｅｖｅｌパラメータを含むＳＵＰＬ  ＲＥＩＮＩＴメッセージをＳＵＰＬサーバからモバイルデバイスに送信することを含む。
【００１２】
他の特定の実施形態では、方法は、ウェブサーバにおいて、ＳＵＰＬによってイネーブルにされるモバイルデバイスからのメッセージを受信することを含み、メッセージは、モバイルデバイスのセキュリティクレデンシャルを含む。方法は、ウェブサーバにおいて、モバイルデバイスからのユーザ識別情報を受信することと、ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証することと、も含む。方法は、モバイルデバイスがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするためにＳＵＰＬサーバにモバイルデバイスのセキュリティクレデンシャルを送信することをさらに含む。
【００１３】
他の特定の実施形態では、方法は、ＳＵＰＬサーバにおいて、モバイルデバイスから第１の識別子及び第１のパスワードを受信することを含む。例えば、第１の識別子及び第１のパスワードは、ユーザモードＴＬＳ認証手順中に受信することができる。方法は、第１の識別子及び第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証することも含む。方法は、第１の識別子及び第１のパスワードに取って代わるための第２の識別子及び第２のパスワードをモバイルデバイスに送信することをさらに含み、ＳＵＰＬサーバは、モバイルデバイスから第２の識別子及び第２のパスワードを受信した時点でモバイルデバイスとのＳＵＰＬセッションを確立するように構成される。
【００１４】
開示される実施形態のうちの少なくとも１つによって提供される特定の利点は、アクセスネットワークから独立してＳＵＰＬシステムで相互認証を行うことができることを含む。例えば、開示される実施形態のうちの１つ以上は、３ＧＰＰと、３ＧＰＰ２と、ＷｉＭＡＸと、Ｗｉ−Ｆｉネットワークとを含む様々なアクセスネットワークをサポートすることができる。他の例として、開示される実施形態のうちの１つ以上は、ＳＵＰＬセッションの開始及び再開にセキュリティを適用することができる。
【００１５】
次の節、すなわち、図面の簡単な説明、発明を実施するための形態、及び請求項、を含む本出願全体を再検討後に本開示のその他の態様、利点、及び特徴が明確になるであろう。
【図面の簡単な説明】
【００１６】
【図１】ＳＵＰＬ環境において認証を行うために動作可能なシステムの特定の実施形態を例示した図である。
【図２】ＳＵＰＬ環境において認証方法を交渉する方法の特定の実施形態を例示したフローチャートである。
【図３】証明書を用いてＳＵＰＬ環境において認証を行う方法の特定の実施形態を例示したフローチャートである。
【図４】証明書を用いてＳＵＰＬ環境において認証を行う方法の他の特定の実施形態を例示したフローチャートである。
【図５】ＳＵＰＬサーバとモバイルデバイスとの間でのメッセージングの特定の実施形態を例示した図である。
【図６】ＳＵＰＬ環境におけるセッション開始中の認証方法の特定の実施形態を例示したフローチャートである。
【図７】ＳＵＰＬ環境におけるセッション再開中の認証方法の特定の実施形態を例示したフローチャートである。
【図８】ウェブサーバ及び複数の識別子／パスワードを用いたＳＵＰＬ環境における認証の特定の実施形態を例示した図である。
【図９】ウェブサーバを用いたＳＵＰＬ環境における認証の特定の実施形態を例示したフローチャートである。
【図１０】複数の識別子／パスワードを用いたＳＵＰＬ環境における認証方法の特定の実施形態を例示したフローチャートである。
【図１１】ＳＥＴを実装する無線デバイスの特定の実施形態のブロック図である。
【発明を実施するための形態】
【００１７】
図１を参照し、セキュアユーザプレーンロケーション（ＳＵＰＬ）環境において認証を行うために動作可能であるシステムの特定の実施形態が示され、概して１００で表される。システム１００は、１つ以上のアクセスネットワーク（例えば、例示のためのアクセスネットワーク１３０）を介してモバイルデバイス１２０に通信可能な形で結合されたＳＵＰＬサーバ１１０を含む。特定の実施形態では、ＳＵＰＬサーバ１１０は、ＳＵＰＬロケーションプラットフォーム（ＳＬＰ）であることができ及びモバイルデバイス１２０はＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）であることができる。アクセスネットワーク１３０は、３ＧＰＰネットワーク、３ＧＰＰ２ネットワーク、ＷｉＭＡＸネットワーク、Ｗｉ−Ｆｉネットワーク（例えば、ＩＥＥＥ８０２．１１規格に準拠して動作するネットワーク）、又は何らかのその他の無線アクセスネットワークであることができる。特定の実施形態では、モバイルデバイス１２０は、無線電話であることができる。
【００１８】
ＳＵＰＬサーバ１１０は、プロセッサ１１１と、プロセッサ１１１に結合されたメモリ１１２と、を含む。特定の実施形態では、メモリ１２２は、プロセッサ１１１によって実行可能な命令を格納することができ、命令は、様々な論理的モジュール、コンポーネント、及びアプリケーションを表す。メモリ１１２は、ＳＵＰＬサーバ１１０の１つ以上のセキュリティクレデンシャルを格納することもできる。例えば、メモリ１１２は、ＳＵＰＬサーバ１１０のためのサーバ証明書１１３を格納することができ、サーバ証明書１１３は、公開鍵１１４と、サーバ識別子（ＩＤ）１１５（例えば、ＳＵＰＬサーバ１１０に対応するグローバルで一意の識別子）と、を含む。ＳＵＰＬサーバ１１０は、公開鍵１１４に対応する秘密鍵を有することもできる。メモリ１１２は、認証論理１１６及びトランスポート層セキュリティ（ＴＬＳ）暗号化／復号論理１１７に対応する実行可能な命令を格納することもできる。認証論理１１６は、モバイルデバイス１２０を認証するために実行可能であることができる。ＴＬＳ暗号化／復号論理１１７は、ＳＵＰＬサーバ１１０からモバイルデバイス１２０に送信されるメッセージを暗号化するために及びモバイルデバイス１２０からＳＵＰＬサーバ１１０に送信されたメッセージを復号するために実行可能であることができる。例えば、モバイルデバイス１２０からの発信メッセージは、サーバ公開鍵１１４を用いて暗号化することができ、モバイルデバイス１２０からの着信メッセージは、サーバ公開鍵１１４に対応する秘密鍵を用いて復号することができる。
【００１９】
モバイルデバイス１２０は、プロセッサ１２１と、プロセッサ１２１に結合されたメモリ１２２と、を含む。特定の実施形態では、メモリ１２２は、プロセッサ１２１によって実行可能な命令を格納し、命令は、様々な論理的モジュール、コンポーネント、及びアプリケーションを表すことができる。メモリ１２２は、モバイルデバイス１２０の１つ以上のセキュリティクレデンシャルを格納することもできる。例えば、メモリ１２２は、モバイルデバイス１２０のためのデバイス証明書１２３を格納することができ、デバイス証明書１２３は、公開鍵１２４と、デバイス識別子（ＩＤ）１２５と、を含む。モバイルデバイス１２０は、公開鍵１２４に対応する秘密鍵を有することもできる。デバイスＩＤ１２５は、国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、一連番号、又はグローバルで一意であることができるその他の識別子であることができる。特定の実施形態では、デバイス証明書１２３は、メモリ１２２の代わりに又はメモリ１２２に加えて、モバイルデバイス１２０のユニバーサル集積回路カード（ＵＩＣＣ）に格納することができる。メモリ１２２は、認証論理１２６及びトランスポート層セキュリティ（ＴＬＳ）暗号化／復号論理１２７に対応する実行可能な命令を格納することができる。認証論理１２６は、モバイルデバイス１２０でＳＵＰＬサーバ１１０を認証するために実行可能であることができる。ＴＬＳ暗号化／復号論理１２７は、モバイルデバイス１２０からＳＵＰＬサーバ１１０に送信されたメッセージを暗号化するために及びＳＵＰＬサーバ１１０からモバイルデバイス１２０に送信されたメッセージを復号するために実行可能であることができる。例えば、モバイルデバイス１２０からの発信メッセージは、デバイス公開鍵１２４を用いて暗号化することができ、モバイルデバイス１２０への着信メッセージは、デバイス公開鍵１２４に対応する秘密鍵を用いて復号することができる。
【００２０】
特定の実施形態では、ＳＵＰＬサーバ１１０及びモバイルデバイス１２０は、相互認証手順に従事することができる。例えば、動作中に、モバイルデバイス１２０における認証論理１２６は、モバイルデバイス１２０が汎用ブーストラッピングアーキテクチャ（ＧＢＡ）に基づく認証をサポートするかどうかを決定することができる。モバイルデバイス１２０がＧＢＡに基づく認証をサポートする場合は、モバイルデバイス１２０及びＳＵＰＬサーバ１１０は、ＧＢＡに基づく認証プロセス１３４を実施することができる。ＧＢＡに基づく認証は、アクセスネットワーク１３０が３ＧＰＰ又は３ＧＰＰ２ネットワークであるときに選択することができる。モバイルデバイス１２０は、ＳＵＰＬサーバ１１０にメッセージ１３１を送信することによってＴＬＳハンドシェイク手順を開始することができる。メッセージ１３１は、モバイルデバイス１２０においてＴＬＳ暗号化／復号論理１２７によってサポートされる１つ以上のＴＬＳ暗号スイートを示すことができる。例えば、メッセージ１３１は、ＣｌｉｅｎｔＨｅｌｌｏメッセージであることができ、サポートされるＴＬＳ暗号スイートは、ＣｌｉｅｎｔＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅｓフィールドによって示すことができる。
【００２１】
ＳＵＰＬサーバ１１０は、メッセージ１３１を処理し、示されているＴＬＳ暗号スイートのうちのいずれがＳＵＰＬサーバ１１０によって同じくサポートされているかどうか（すなわち、共通にサポートされるＴＬＳ暗号スイートが存在するかどうか）を決定することができる。モバイルデバイス１２０及びＳＵＰＬサーバ１１０の両方がＴＬＳの事前共有鍵（ＴＬＳ−ＰＳＫ）暗号スイートをサポートする場合は、ＧＢＡをサポートすることができ、及びＳＵＰＬサーバ１１０は、ＧＢＡに基づく認証プロセス１３４を実施することができる。そうでない場合は、ＳＵＰＬサーバ１１０は、メッセージ１３２を介して証明書に基づく認証を開始することができ又は代替クライアント認証（ＡＣＡ）を開始することができる。ＡＣＡは、相互認証を提供することができ、及び使用されるアクセスネットワークのタイプ（例えば、ＧＳＭ（登録商標）／ＵＭＴＳ及びＣＤＭＡ）に依存することができる。ＡＣＡ認証中には、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０によって提供されたＩＰアドレスをアクセスネットワーク１３０によって提供されるモバイルデバイス１２０に対応するＩＰアドレスと比較することによってモバイルデバイス１２０のインターネットプロトコル（ＩＰ）アドレスバインディング（ｂｉｎｄｉｎｇ）を検証することができる。証明書に基づく認証は、アクセスネットワーク１３０のタイプから独立していることができ及びアクセスネットワーク１３０がＷｉ−Ｆｉネットワークであるときに使用することができる。メッセージ１３２は、ＳＵＰＬサーバ１１０及びモバイルデバイス１２０によってサポートされる非ＰＳＫ  ＴＬＳ暗号スイートの表示（ｉｎｄｉｃａｔｉｏｎ）と、（サーバ公開鍵１１４を含む）サーバ証明書１１３と、デバイス証明書要求と、を含むことができる。例示するために、メッセージ１３２は、共通してサポートされるＴＬＳ暗号スイートを示すＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅフィールドを含むＳｅｒｖｅｒＨｅｌｌｏメッセージを含むことができる。
【００２２】
メッセージ１３２に応答して、モバイルデバイス１２０は、デバイス証明書１２３を含むメッセージ１３３を送信することができる。ＳＵＰＬサーバ１１０は、デバイス証明書１２３内のデバイスＩＤ１２５を格納されたデバイスＩＤ（例えば、図８及び９を参照してさらに説明されるように、ＳＵＰＬユーザと関連付けられていることがＳＵＰＬサーバ１１０によって予めセキュアに検証されている格納されたデバイスＩＤ）と比較することによってモバイルデバイス１２０と関連付けられたＳＵＰＬユーザを識別するのを試みることができる。いずれのＳＵＰＬユーザも識別されない場合は、ＳＵＰＬサーバ１１０とモバイルデバイス１２０との間での通信セッションを終了させることができる。ＳＵＰＬユーザが識別される場合は、ＴＬＳハンドシェイクは完了することができ、ＳＵＰＬサーバ１１０は、ＳＵＰＬユーザのためにプロビジョニング（ｐｒｏｖｉｓｉｏｎｉｎｇ）されるＳＵＰＬに基づくサービス（例えば、位置に基づくサービス）へのアクセスをモバイルデバイス１２０に認めることができる。
【００２３】
特定の実施形態では、異なる認証方法も利用可能であることができる。例えば、モバイルデバイス１２０がＷｉＭＡＸと互換可能なデバイスであり及び／又はアクセスネットワーク１３０がＷｉＭＡＸネットワークであるときに、モバイルデバイス１２０及びＳＵＰＬサーバ１１０が両方ともＳＵＰＬ暗号化鍵（ＳＥＫ）に基づく認証方法をサポートする場合は、ＳＥＫに基づく認証方法が、ＳＵＰＬサーバ１１０及びモバイルデバイス１２０の相互認証にとってより好ましいことができる。他の例として、ＳＵＰＬサーバ１１０が証明書に基づく認証をサポートしない場合は、ＳＵＰＬサーバ１１０は、異なる認証方法、例えば、ＡＣＡ（モバイルデバイス１２０が３ＧＰＰ又は３ＧＰＰ２アクセスネットワーク上にあるときにアクセスネットワークに依存する相互認証を提供することができる）又はＳＬＰ専用認証（非相互認証を提供することができ及び緊急シナリオ中のみに概して使用することができる）、を開始するためにデバイス証明書を要求せずにメッセージ１３２を送信することができる。
【００２４】
このように、図１のシステム１００は、アクセスネットワークに依存しないでモバイルデバイスとＳＵＰＬサーバとの間での相互認証を可能にすることができる。例えば、アクセスネットワーク１３０は、３ＧＰＰネットワーク、３ＧＰＰ２ネットワーク、ＷｉＭＡＸネットワーク、Ｗｉ−Ｆｉネットワーク、又は何らかのその他のネットワークであることができる。図１のシステム１００は、複数の相互認証方法のためのサポートを提供することもでき、ＧＢＡに基づく認証と、ＳＥＫに基づく認証と、証明書に基づく認証と、ＡＣＡに基づく認証と、ＳＬＰ専用認証と、を含む。
【００２５】
図２を参照し、ＳＵＰＬ環境において認証方法を交渉する方法の特定の実施形態が示され、概して２００で表される。例示のための実施形態では、方法２００は、図１のＳＵＰＬサーバ１１０によって実施することができる。
【００２６】
方法２００は、２０２において、ＳＵＰＬサーバにおいて、モバイルデバイスによってサポートされる１つ以上のＴＬＳ暗号スイートの表示をモバイルデバイスから受信することを含むことができる。例えば、図１において、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０からメッセージ１３１を受信することができ、メッセージ１３１は、モバイルデバイス１２０によってサポートされる１つ以上のＴＬＳ暗号スイートを示す。
【００２７】
方法２００は、２０４において、モバイルデバイスによって示される少なくとも１つのＴＬＳ−ＰＳＫ暗号スイートがＳＵＰＬサーバによってもサポートされるかどうかを決定することを含むこともできる。例えば、図１において、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０によってサポートされるＴＬＳ−ＰＳＫ暗号スイートがＳＵＰＬサーバ１１０によってもサポートされるかどうかを決定することができる。
【００２８】
２０４において、ＴＬＳ−ＰＳＫ暗号スイートがＳＵＰＬサーバ及びモバイルデバイスによって共通してサポートされると決定したことに応答して、２０６において、モバイルデバイスを認証するためにＧＢＡに基づく認証プロセスを実施することができる。例えば、図１において、ＳＵＰＬサーバ１１０は、ＧＢＡに基づく認証手順１３４を実施することができる。２０４において、ＴＰＳ−ＰＳＫ暗号スイートがＳＵＰＬサーバ及びモバイルデバイスによって共通してサポートされていないと決定したことに応答して、２０８において、証明書に基づく認証プロセスを実施することができる。証明書に基づくプロセスは、モバイルデバイスにサーバ証明書を送信することと、モバイルデバイスからデバイス証明書を受信することと、を含むことができ、及び、モバイルデバイスによって使用されるアクセスネットワークから独立していることができる。例えば、図１において、ＳＵＰＬサーバ１１０は、メッセージ１３２を介してモバイルデバイス１２０にサーバ証明書１１３を送信することとメッセージ１３３を介してモバイルデバイス１２０からデバイス証明書１２３を受信することとを含む証明書に基づく認証手順を実施することができる。
【００２９】
特定の実施形態では、図２の方法２００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図２の方法２００は、命令を実行するプロセッサによって実施することができる。
【００３０】
図３を参照し、証明書を用いてＳＵＰＬ環境において認証を行う方法の特定の実施形態が示され、概して３００で表される。例示のための実施形態では、方法３００は、図１のモバイルデバイス１２０によって実施することができる。
【００３１】
方法３００は、３０２において、モバイルデバイスにおいて、モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納することを含むことができる。少なくとも１つのセキュリティクレデンシャルは、モバイルデバイスのデバイス識別子を含むことができる。例えば、図１において、モバイルデバイス１２０は、デバイスＩＤ１２５（例えば、ＩＭＥＩ、ＭＳＩＤ、一連番号、又は他のグローバルで一意の識別子）を含むデバイス証明書１２３を格納することができる。
【００３２】
方法３００は、３０４において、デバイス識別子と格納されたデバイス識別子の比較に基づいてモバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証するために少なくとも１つのセキュリティクレデンシャルをＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に送信することを含むこともできる。例えば、図１において、モバイルデバイス１２０は、デバイスＩＤ１２５と他のエンティティによって予め提供された格納されたデバイスＩＤの比較に基づいてモバイルデバイス１２０がＳＵＰＬユーザと関連付けられているとしてＳＵＰＬサーバ１１０が認証できるようにメッセージ１３３を介してＳＵＰＬサーバ１１０（例えば、ＳＬＰ）にデバイス証明書１２３を送信することができる。
【００３３】
特定の実施形態では、図３の方法３００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図３の方法３００は、命令を実行するプロセッサによって実施することができる。
【００３４】
図４を参照し、証明書を用いてＳＵＰＬ環境において認証を行う方法の他の特定の実施形態が示され、概して４００で表される。例示のための実施形態では、方法４００は、図１のＳＵＰＬサーバ１１０によって実施することができる。
【００３５】
方法４００は、４０２において、ＳＵＰＬサーバにおいて、モバイルデバイスによってサポートされる１つ以上のＴＬＳ暗号スイートの表示をモバイルデバイスから受信することを含むことができる。例えば、図1において、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０からメッセージ１３１を受信することができ、メッセージ１３１は、モバイルデバイス１２０によってサポートされる１つ以上のＴＬＳ暗号スイートを示す。
【００３６】
方法４００は、４０４において、ＳＵＰＬサーバからモバイルデバイスにメッセージを送信することを含むこともできる。メッセージは、ＳＵＰＬサーバの識別子とＳＵＰＬサーバの公開鍵とを含むサーバ証明書と、モバイルデバイスのデバイス証明書の要求と、ＴＬＳ暗号スイートのうちの少なくとも１つの選択と、を含むことができる。例えば、図１において、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０にメッセージ１３２を送信することができ、メッセージ１３２は、サーバＩＤ１１５と、サーバ公開鍵１１４と、モバイルデバイス１２０のデバイス証明書１２３の要求と、共通してサポートされるＴＬＳ暗号スイートの選択と、を含む。
【００３７】
方法４００は、４０６において、モバイルデバイスのデバイス証明書を含む応答をモバイルデバイスから受信することをさらに含むことができる。例えば、図１において、ＳＵＰＬサーバ１１０は、デバイス証明書１２３を含むメッセージ１３３を受信することができる。
【００３８】
方法４００は、４０８において、デバイス証明書に基づいてモバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証することを含むことができる。例えば、図１において、ＳＵＰＬサーバ１１０の認証論理１１６は、デバイス証明書１２３に基づいてモバイルデバイス１２０がＳＵＰＬユーザと関連付けられているとして認証することができる。
【００３９】
特定の実施形態では、図４の方法４００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図４の方法４００は、命令を実行するプロセッサによって実施することができる。
【００４０】
図１乃至４を参照して説明されるいずれの認証方法が使用されるかにかかわらず、いったん認証が完了した時点で、ＳＵＰＬサーバ（例えば、ＳＬＰ）及びモバイルデバイス（例えば、ＳＥＴ）は、ＳＵＰＬセッション中にＳＵＰＬに基づくサービスに関して通信することができる。図５を参照し、ＳＵＰＬサーバ５１０とモバイルデバイス５２０との間でやり取りすることができるメッセージの特定の実施形態が示され、概して５００で示される。
【００４１】
特定の実施形態では、ＳＵＰＬサーバ５１０及びモバイルデバイス５２０は、ＳＵＰＬセッションのコンテキストでユーザロケーションプロトコル（ＵＬＰ）メッセージを介して通信することができる。例えば、ＳＵＰＬサーバ５１０は、モバイルデバイス５２０にＳＵＰＬ  ＩＮＩＴメッセージ５３０を送信するように構成することができる。ＳＵＰＬ  ＩＮＩＴメッセージ５３０は、ＳＵＰＬセッションを開始するためにＳＵＰＬサーバ１１０によって送信されるセッション開始メッセージを表すことができる。なりすまし及びリプレイ攻撃から保護するために、ＳＵＰＬ  ＩＮＩＴメッセージ５３０に対して保護を適用することができる。特定の実施形態では、ＳＵＰＬ  ＩＮＩＴメッセージ５３０は、Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータを含むことができる。Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータは、Ｌｅｖｅｌパラメータ（Ｎｕｌｌ、Ｍｏｄｅ  Ａ、又はＭｏｄｅ  Ｂ  ＳＵＰＬ  ＩＮＩＴ保護のいずれが実装されるかを示す）及びＰｒｏｔｅｃｔｉｏｎパラメータ（例えば、鍵識別子タイプ及び鍵識別子のうちの少なくとも１つを含む）のうちの少なくとも１つを含むことができる。特定の実施形態では、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護は、エンド・ツー・エンドの完全性もリプレイ保護も提供することができず、Ｍｏｄｅ  Ａ  ＳＵＰＬ  ＩＮＩＴ保護は、セキュリティが確保されたＵＬＰセッション中にＳＵＰＬサーバ５１０によってモバイルデバイス５２０に送信される共有鍵の使用によってエンド・ツー・エンドの完全性及びリプレイ保護を提供することができ、Ｍｏｄｅ  Ｂ  ＳＵＰＬ  ＩＮＩＴ保護は、ＰＳＫに基づく方法（例えば、ＧＢＡ又はＳＥＫ方法）から導き出された共有鍵を用いてエンド・ツー・エンドの完全性及びリプレイ保護を提供することができる。
【００４２】
特定の実施形態では、ＳＵＰＬ  ＩＮＩＴ保護は、セッション開始鍵（例えば、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）に基づいて実装することができる。ＳＵＰＬ  ＩＮＩＴメッセージ５３０を受信した時点で、モバイルデバイス５２０は、モバイルデバイス５２０がＳＵＰＬサーバ５１０から有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを以前に受信しているかどうかを決定することができ、そうである場合は、以前に受信されたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは依然として有効であるかどうかを決定することができる。モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、モバイルデバイス５２０は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いてＳＵＰＬ  ＩＮＩＴメッセージ５３０を認証することができ及びＳＵＰＬ  ＩＮＩＴメッセージ５３０の成功裏の認証に応答してＳＵＰＬサーバ５１０とＳＵＰＬセッションを開始することができる。
【００４３】
特定の実施形態では、モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない場合は、モバイルデバイス５２０は、ＳＵＰＬサーバ５１０にメッセージを送信することができ及びそのメッセージに応答して有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを受信することができる。例えば、モバイルデバイス５２０は、有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの要求を表すＳＵＰＬ_ＩＮＩＴ_ＫｅｙＲｅｑｕｅｓｔパラメータを含むメッセージを送信することができる。代替として、モバイルデバイス５２０は、新しいＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを要求する代わりに無効な又は同期外れのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの存在を示すことができる。例えば、モバイルデバイス５２０は、モバイルデバイス５２０によって所有される“現在の” ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが無効又は同期外れであるかどうかを示すＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータ５４１を含むＵＬＰメッセージ５４０を送信することができる。特定の実施形態では、ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータ５４１は、ＵＬＰメッセージ５４０のＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含めることができる。ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータ５４１をＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含めることは、ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ状態情報を送信するための専用メッセージを導入する必要なしにＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓパラメータを任意選択的に又は強制的に含むＳＵＰＬ２．０内で定義されたメッセージでのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ状態情報の送信を可能にすることができることが理解されるであろう。特定の実施形態では、ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータ５４１は、Ｍｏｄｅ  Ａ  ＳＵＰＬ  ＩＮＩＴ保護のためにＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含めることができるが、ＮＵＬＬ保護又はＭｏｄｅ  Ｂ  ＳＵＰＬ  ＩＮＩＴ保護のためにＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含めることはできない。
【００４４】
モバイルデバイス５２０は、すべてのネットワークによって開始されるＳＵＰＬセッションのために有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを示すことはできないことが注目されるべきである。モバイルデバイス５２０には、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを１回提供しておくことができ、提供された鍵は、その鍵が期限切れになる前は複数のネットワークによって開始されるＳＵＰＬセッションに関して有効であることができる。
【００４５】
ＳＵＰＬサーバ５１０は、ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅパラメータを含むＵＬＰメッセージを送信することができる。例えば、ＳＵＰＬサーバ５１０は、ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅパラメータ５５１を含むＳＵＰＬ  ＥＮＤメッセージ５５０を送信することができる。ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅは、ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓ表示に直接応答して送信することはできず、ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅは、同じＳＵＰＬセッション内にあることができない“正規の”ＳＵＰＬ  ＥＮＤメッセージ内に存在することができることが注目されるべきである（例えば、ＳＵＰＬセッションがＳＬＰからＳＥＴへのＳＵＰＬ  ＥＮＤメッセージによって終了されない場合）。ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅパラメータ５５１は、モードＡ鍵識別子、一時的モードＡ鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ（例えば、“新しい”ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）、及びモードＡ鍵寿命のうちの少なくとも１つを含むことができる。
【００４６】
一般的ＳＵＰＬセッション（ＧＳＳ）がアクティブである間は、ＳＬＰ（すなわち、ＳＵＰＬサーバ５１０）は、ＳＥＴ（すなわち、モバイルデバイス５２０）との通信を開始することができる。ＳＵＰＬサーバ５１０は、セッション再開メッセージ（例えば、ＳＵＰＬ  ＲＥＩＮＩＴメッセージ５６０）を送信することができる。ＳＵＰＬ  ＲＥＩＮＩＴ保護は、ＳＵＰＬ  ＲＥＩＮＩＴ保護を参照してここにおいて説明されるように実装することができる。例えば、モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを所有していない場合は（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、セッション開始鍵及びセッション再開鍵の両方として機能することができる）、モバイルデバイス５２０は、ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータ５４１を介して有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが存在しないことを示すことができ、応答して、ＳＵＰＬ  ＥＮＤメッセージ５５０（ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅパラメータ５５１を含む）を受信することができる。モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するときには、モバイルデバイス５２０は、ＳＵＰＬ  ＲＥＩＮＩＴメッセージ５６０を認証することができ及びＳＵＰＬ  ＲＥＩＮＩＴメッセージ５６０の成功裏の認証に応答してＳＵＰＬサーバ５１０とのＳＵＰＬセッションを再開することができる。特定の実施形態では、ＳＵＰＬ  ＲＥＩＮＩＴメッセージ５６０は、ＳＵＰＬ  ＩＮＩＴメッセージ５３０を参照してここにおいて説明されるように、Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータを含むこともできる。
【００４７】
特定の実施形態では、モバイルデバイス５２０は、モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さないとき（例えば、パワーアップ時又は所有されるＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの寿命が経過しているとき）にはＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護及びＮｕｌｌ  ＳＵＰＬ  ＲＥＩＮＩＴ保護を適用することができる。Ｎｕｌｌ保護が設定されているときには、モバイルデバイス５２０は、すべてのＳＵＰＬ  ＩＮＩＴメッセージ及びＳＵＰＬ  ＲＥＩＮＩＴメッセージを処理することができる。モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、ＭｏｄｅＡ又はＭｏｄｅＢ保護を適用することができる。
【００４８】
図５において例示されるように、ＳＵＰＬシステムにおいてセキュリティを実装するために様々なメッセージ及びメッセージパラメータを用いることができる。例えば、ＳＵＰＬ  ＩＮＩＴ及びＳＵＰＬ  ＲＥＩＮＩＴ保護のレベルを示すためにＰｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータを用いることができる。他の例として、現在のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが無効又は同期外れであるかどうかを示すためにＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータを使用することができる。さらに他の例として、“新しい” ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを提供するためにＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅパラメータを用いることができる。
【００４９】
図６を参照し、ＳＵＰＬ環境におけるセッション開始中の認証の方法の特定の実施形態が示され、概して６００で表される。例示のための実施形態において、方法６００は、図５のモバイルデバイス５２０によって実施することができる。
【００５０】
方法６００は、６０２において、セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバとモバイルデバイスとの間でのＳＵＰＬセッションを開始するためにＳＵＰＬサーバからのセッション開始メッセージをモバイルデバイスにおいて受信することを含むことができる。例えば、図５では、モバイルデバイス５２０は、ＳＵＰＬサーバ５１０からＳＵＰＬ  ＩＮＩＴメッセージ５３０を受信することができる。
【００５１】
方法６００は、６０４において、モバイルデバイスがセッション開始メッセージを受信する前に有効なセッション開始メッセージ鍵を受信したかどうかを決定することを含むこともできる。例えば、図５では、モバイルデバイス５２０は、それが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを所有するかどうかを決定することができる。
【００５２】
モバイルデバイスが有効なセッション開始メッセージ鍵を有するときには、方法６００は、６０６において、セッション開始メッセージ鍵（例えば、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を用いてセッション開始メッセージを認証することと、６０８において、セッション開始メッセージの成功裏の認証に応答してＳＵＰＬサーバとのＳＵＰＬセッションを開始することと、をさらに含むことができる。例えば、図５において、モバイルデバイス５２０は、有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いてＳＵＰＬ  ＩＮＩＴメッセージ５３０を認証することができ及びＳＵＰＬサーバ５１０とのＳＵＰＬセッションを開始することができる。
【００５３】
モバイルデバイスが有効なセッション開始メッセージ鍵を有さないときには、方法６００は、６１０において、ＳＵＰＬサーバにメッセージを送信することと、６１２において、そのメッセージに応答してＳＵＰＬサーバからセッション開始メッセージ鍵を受信することと、を含むことができる。例示することを目的として、ＳＬＰ及びＳＥＴは、ＮＵＬＬ  ＳＵＰＬ  ＩＮＩＴ保護を用いてセッションを行うことができ、ＳＥＴは、それのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが無効であることの表示をセッション中に送信することができる。例えば、図５において、モバイルデバイス５２０は、ＳＵＰＬ ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータ５４１を含むメッセージをＳＵＰＬサーバ５１０に送信することができ及び応答してＳＵＰＬ ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅパラメータ５５１を含むメッセージを受信することができる。
【００５４】
特定の実施形態では、図６の方法６００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図６の方法６００は、命令を実行するプロセッサによって実施することができる。
【００５５】
図７を参照し、ＳＵＰＬ環境におけるセッション再開中の認証の方法の特定の実施形態が示され、概して７００で表される。例示のための実施形態では、方法７００は、図５のモバイルデバイス５２０によって実施することができる。
【００５６】
方法７００は、７０２において、モバイルデバイスにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバとモバイルデバイスとの間でのＳＵＰＬセッションを継続するためのＳＵＰＬサーバからのセッション再開メッセージを受信することを含むことができる。例えば、図５において、モバイルデバイス５２０は、ＳＵＰＬサーバ５１０からＳＵＰＬ  ＲＥＩＮＩＴメッセージ５６０を受信することができる。ＳＵＰＬ  ＲＥＩＮＩＴメッセージ５６０は、ＳＵＰＬサーバ５１０とモバイルデバイス５２０との間での既存の一般的なＳＵＰＬセッション（ＧＳＳ）を継続することのネットワークによって開始された試行を表すことができる。
【００５７】
方法７００は、７０４において、モバイルデバイスがセッション再開メッセージを受信する前に有効なセッション開始メッセージ鍵を受信したかどうかを決定することも含むこともできる。例えば、図５において、モバイルデバイス５２０は、それが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを所有するかどうかを決定することができる。
【００５８】
モバイルデバイスが有効なセッション開始メッセージ鍵を有する場合は、方法７００は、７０６において、セッション開始メッセージ鍵を用いてセッション再開メッセージを認証することと、７０８において、セッション再開メッセージの成功裏の認証に応答してＳＵＰＬサーバとのＳＵＰＬセッションを継続することと、をさらに含むことができる。例えば、図５において、モバイルデバイス５２０は、有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いてＳＵＰＬ  ＲＥＩＮＩＴメッセージ５６０を認証することができ及びＳＵＰＬサーバ５１０とのＳＵＰＬセッションを再開することができる。
【００５９】
モバイルデバイスが有効なセッション開始メッセージ鍵を有さないときには、方法７００は、７１０において、ＳＵＰＬサーバにメッセージを送信することと、７１２において、そのメッセージに応答してＳＵＰＬサーバからセッション開始メッセージ鍵を受信することと、を含むことができる。例示することを目的として、ＳＬＰ及びＳＥＴは、ＮＵＬＬ  ＳＵＰＬ  ＩＮＩＴ保護を用いてセッションを行うことができ、ＳＥＴは、それのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが無効であることの表示をセッション中に送信することができる。例えば、図５において、モバイルデバイス５２０は、ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータ５４１を含むメッセージをＳＵＰＬサーバ５１０に送信することができ及び応答してＳＵＰＬ ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅパラメータ５５１を含むメッセージを受信することができる。
【００６０】
特定の実施形態では、図７の方法７００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図７の方法７００は、命令を実行するプロセッサによって実施することができる。
【００６１】
特定の実施形態では、証明書に基づく方法、ＧＢＡに基づく方法、ＳＥＫに基づく方法、ＡＣＡに基づく方法、及びＳＬＰ専用の方法以外の方法を介してモバイルデバイスとＳＵＰＬサーバとの間での相互認証を実施することができる。例えば、図８は、複数の識別子／パスワードを用いてＳＵＰＬ環境において認証を実施するために動作可能なシステム８００の特定の実施形態を例示する。システム８００は、ＳＵＰＬサーバ（例えば、ＳＬＰ）８２０と通信することが可能なモバイルデバイス８１０（例えば、ＳＥＴ）を含む。
【００６２】
複数の識別子／パスワードに基づく認証に加えて、図８のシステム８００は、ＳＵＰＬユーザにデバイス証明書をバインド（ｂｉｎｄ）させる特定の例も示す。例えば、システム８００は、デバイス証明書とＳＵＰＬユーザとの間でのバインディングを生成するためのメカニズムを提供するためのウェブサーバ８３０を含むことができる。ウェブサーバ８３０は、ＳＵＰＬセッションのための認証を提供することはできず、むしろ、ＳＵＰＬ認証中にＳＬＰによってのちに用いることができるバインディング情報を提供することができる。このバインディングは、典型的には１回だけ行うことができ、及び、ＳＥＴがＳＵＰＬセッションに従事することができる前に行うことができる。バインディングが行われた時点で、デバイス証明書とユーザ情報の組み合わせをＳＬＰに送信することができ、ＳＬＰは、この情報を格納してクライアント認証のために使用することができる。バインディングが行われた後は、ＳＬＰは、あるモバイルデバイスが特定のＳＵＰＬユーザに属することを“知る”ことができる。ウェブサーバ８３０は、プロセッサ８３１と、プロセッサ８３１によって実行可能な命令を格納するメモリ８３２と、を含むことができる。例えば、命令は、認証論理８３３を表すことができる。ウェブサーバ８３０は、モバイルデバイス８１０と及びＳＵＰＬサーバ８２０と通信するために動作可能なネットワークインタフェース８３４を含むこともできる。ウェブサーバ８３０は、ユーザへのデバイス証明書のバインディングを提供する方法を示す一例であるにすぎないことが注目されるべきである。その他の実施形態では、その他のバインディングメカニズムを使用することができる。代替として、ウェブサーバ８３０は、デバイス証明書とユーザ情報の組み合わせを格納することができ、及び、ＳＬＰは、（デバイス証明書を用いたデバイスの相互認証を行った時点で）そのデバイス証明書と関連付けられたユーザ情報を提供するようにウェブサーバ８３０に要求することができる。
【００６３】
モバイルデバイス８１０は、認証論理８１１（例えば、モバイルデバイス８１０のメモリに格納され、モバイルデバイス８１０のプロセッサによって実行可能な命令）を含むことができる。認証論理８１１は、モバイルデバイス８１０を特定のＳＵＰＬユーザと関連付ける（“バインドする”又は“登録する”）ためにウェブサーバ８３０において対応する認証論理８３３と通信するように構成することができる。例えば、バインディングプロセスは、モバイルデバイス８１０がウェブサーバ８３０からメッセージ８３５を受信することから開始することができ、メッセージ８３５は、ウェブサーバ８３０のサーバ証明書と、ウェブサーバ８３０の公開鍵と、を含む。モバイルデバイス８１０は、ウェブサーバ８３０にメッセージ８１３を送信することによって応答することができ、メッセージ８１３は、モバイルデバイス８１０のセキュリティクレデンシャルを含む。例えば、モバイルデバイス８１０のセキュリティクレデンシャルは、モバイルデバイス８１０の公開鍵、国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び／又は一連番号を含むデバイス証明書を含むことができる。モバイルデバイス８１０は、ウェブサーバ８３０にユーザ識別情報（例えば、ＳＵＰＬユーザと関連付けられたユーザ識別子及びパスワード）を含むメッセージ８１４を送信することもできる。メッセージ８１３、８１４のうちの１つ又は両方は、ウェブサーバ８３０の公開鍵を用いて暗号化することができ、ウェブサーバ８３０は、ウェブサーバ８３０の秘密鍵を用いて暗号化されたメッセージを復号することができる。
【００６４】
ウェブサーバ８３０は、モバイルデバイス８１０によって提供されたユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザと関連付けられているかどうかを決定するためにユーザ識別情報を認証することができる。例えば、ウェブサーバ８３０は、提供されたユーザ識別情報を、ウェブサーバ８３０に所在する又はウェブサーバ８３０にとってアクセス可能なＳＵＰＬユーザデータベースと比較することができる。ユーザ識別情報を検証した時点で、ウェブサーバ８３０は、モバイルデバイス８１０がＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証するためのメッセージ８３６をＳＵＰＬサーバ８２０に送信することによってバインディングプロセスを完了することができる。メッセージ８３６は、モバイルデバイス８１０のセキュリティクレデンシャル（例えば、デバイス公開鍵、ＩＭＥＩ、ＭＳＩＤ、及び／又は一連番号を含むデバイス証明書）を含むことができる。
【００６５】
モバイルデバイス８１０の認証論理８１１は、ＳＵＰＬセッションの開始又は再開前にユーザモードＴＬＳに基づく相互認証を行うためにＳＵＰＬサーバ８２０の対応する認証論理８２１と通信するように構成することもできる。例えば、モバイルデバイス８１０は、ＳＵＰＬサーバ８２０にメッセージ８１５を送信することができ、メッセージ８１５は、第１の識別子と第１のパスワードとを含む。特定の実施形態では、第１のパスワードは、ユーザによって選択することができ、及び、相対的に弱い暗号強度を有することができる。例示するための実施形態では、第１の識別子及び第１のパスワードは、メッセージ８１４を介してモバイルデバイス８１０によってウェブサーバ８３０に送信される識別子及びパスワードに対応することができる。
【００６６】
第１の識別子及び第１のパスワードを受信した時点で、認証論理８２１は、第１の識別子及び第１のパスワードがＳＵＰＬサーバの権限が付与されたユーザと関連付けられているとして認証することができる。例えば、認証論理８２１は、第１の識別子及び第１のパスワードがモバイルデバイス８１０に以前にバインディングされた権限が付与されたユーザに対応することを検証することができる。認証に成功したときには、ＳＵＰＬサーバ８２０の識別子／パスワード生成論理８２２は、第１の識別子及び第１のパスワードに取って代わるための第２の識別子及び第２のパスワードを生成することができる。特定の実施形態では、第２のパスワードは、第１のパスワードよりも高い暗号強度を有することができる。ＳＵＰＬサーバ８２０は、メッセージ８２４を介してモバイルデバイス８１０に第２の識別子及び第２のパスワードを送信することができる。モバイルデバイス８１０から第２の識別子及び第２のパスワードを後続して受信した時点で、ＳＵＰＬサーバ８２０は、モバイルデバイス８１０とのセッションを確立することができる。特定の実施形態では、第２の識別子及び第２のパスワードは、セキュリティ上の目的でモバイルデバイス８１０のユーザから隠した状態にすることができる。
【００６７】
上記の説明は、ＳＵＰＬユーザが単一のモバイルデバイス（例えば、ＳＥＴ）と関連付けられていることに関するものであるが、ＳＵＰＬユーザは、複数のデバイスと関連付けることができる。例えば、モバイルデバイス８１０と関連付けられたＳＵＰＬユーザは、第２のモバイルデバイス８４０へのアクセスも有することができる。第２のモバイルデバイス８４０に権限を付与するために、ＳＵＰＬユーザは、第１のモバイルデバイス８１０をバインドさせるのと同様の方法で第２のモバイルデバイス８４０を自己のアカウント（例えば、ＳＵＰＬアカウント）にバインドさせることができる。第２のモバイルデバイス８４０がＳＵＰＬユーザのアカウントにバインドされた後に相互認証を行うために、第２のモバイルデバイス８４０は、第１の識別子と第１のパスワードを含むメッセージ８４１をＳＵＰＬサーバ８２０に送信することができる。第１の識別子及び第１のパスワードが権限が付与されたＳＵＰＬユーザと関連付けられているとして認証した時点で、ＳＵＰＬサーバ８２０は、第２のモバイルデバイス８４０にもＳＵＰＬサービスへのアクセスが許可されるべきかどうかを決定することができる。例えば、ＳＵＰＬサーバ８２０は、ユーザ当たりのデバイス数に関する制限を実装することができ及び第２のモバイルデバイス８４０がＳＵＰＬサービスにアクセスするのを許容することがＳＵＰＬサービスにアクセスすることが許可された権限が付与されたユーザと関連付けられたモバイルのスレショルド数を超えるかどうかを決定することができる。第２のモバイルデバイス８４０がＳＵＰＬサービスにアクセスするのを許容することがスレショルドを超えない場合は、ＳＵＰＬサーバ８２０は、第３の識別子と暗号的に強力な第３のパスワードとを含むメッセージ８２５を第２のモバイルデバイス８４０に送信することができる。第３の識別子及び第３のパスワードが第１の識別子及び第１のパスワードに取って代わることができ、及び、ＳＵＰＬセッションを開始するために第２のモバイルデバイス８４０によって引き続いて使用することができる。
【００６８】
特定の実施形態では、第３の識別子及び第３のパスワードは、第１のモバイルデバイス８１０に送信された第２の識別子及び第２のパスワードと別個であることができる。別個の識別子／パスワードの組み合わせをＳＵＰＬユーザの各モバイルデバイスに提供することによって、ＳＵＰＬサーバ８２０は、１つのデバイスごとのモニタリングを実装することができる。例えば、ＳＵＰＬサーバ８２０のモニタリング論理８２３は、第２の識別子を用いて第１のモバイルデバイス８１０によるＳＵＰＬサービスの使用をモニタリングするように及び第３の識別子を用いて第２のモバイルデバイス８４０によるＳＵＰＬサービスの使用をモニタリングするように構成することができる。
【００６９】
図８のシステム８００は、１つ以上のモバイルデバイスを特定のＳＵＰＬユーザとバインドさせる、登録する、及び／又は関連付けることができるバインディングプロセスを提供することができる。説明されるバインディングプロセスは、図１乃至４を参照して説明される認証プロセスを選択的に補足できることが理解されるだろう。例えば、図１を参照して説明されるように、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０のデバイスＩＤ  １２５をＳＵＰＬユーザによって以前にセキュアに検証された格納されたデバイスＩＤと比較することによってＳＵＰＬユーザがモバイルデバイスと関連付けられているとして識別することを試みることができる。例示のための実施形態では、図１のＳＵＰＬサーバ１１０は、ＳＵＰＬサーバ８２０であることができ、図１のモバイルデバイス１２０は、モバイルデバイス８１０であることができ、格納されたデバイスＩＤは、バインディングプロセス中にメッセージ８３６を介してＳＵＰＬサーバ８２０に提供されるデバイスセキュリティクレデンシャル内に含めることができる。
【００７０】
さらに、図８のシステム８００は、図１乃至４を参照して説明される認証プロセスに選択的に取って代わることができる認証プロセスを提供することができる。例えば、特定の実施形態は、ＧＢＡに基づく相互認証、ＳＥＫに基づく相互認証、及び／又は証明書に基づく相互認証の代わりに図８の複数の識別子／パスワードの認証プロセスを用いることを含むことができる。
【００７１】
図９を参照し、ウェブサーバを用いたＳＵＰＬ環境における認証の方法の特定の実施形態が示され、概して９００で表される。例示のための実施形態では、方法９００は、図８のウェブサーバ８３０によって実施することができる。
【００７２】
方法９００は、９０２において、ウェブサーバからＳＵＰＬによってイネーブルにされるモバイルデバイスにサーバ証明書を送信することを含むことができる。サーバ証明書は、ウェブサーバの公開鍵を含むことができる。例えば、図８において、ウェブサーバ８３０は、モバイルデバイス８１０にメッセージ８３５を送信することができ、メッセージ８３５は、ウェブサーバ８３０の証明書と公開鍵とを含む。
【００７３】
方法９００は、９０４において、モバイルデバイスのセキュリティクレデンシャルを含むモバイルデバイスからのメッセージをウェブサーバにおいて受信することを含むこともできる。例えば、図８において、ウェブサーバ８３０は、モバイルデバイス８１０からメッセージ８１３を受信することができ、メッセージ８１３は、モバイルデバイス８１０のセキュリティクレデンシャル（例えば、デバイス証明書及びデバイス公開鍵）を含む。
【００７４】
方法９００は、９０６において、ウェブサーバの秘密鍵を用いてメッセージを復号することと、９０８において、モバイルデバイスからユーザ識別情報を受信することと、をさらに含むことができる。例えば、図８において、ウェブサーバ８３０は、秘密鍵を用いてメッセージ８１３を復号することができ及びメッセージ８１４を介してモバイルデバイス８１０からユーザ識別情報（例えば、識別子及びパスワード）を受信することができる。代替として、又はさらに加えて、ユーザ識別情報は、ウェブサーバの秘密鍵を用いて復号することもできる。
【００７５】
方法９００は、９１０において、ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証することと、９１２において、モバイルデバイスがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするためにモバイルデバイスのセキュリティクレデンシャルをＳＵＰＬサーバに送信することと、を含むことができる。例えば、図８において、ウェブサーバ８３０は、ユーザ識別情報が権限が付与されたＳＵＰＬユーザを識別しているとして認証することができ及びメッセージ８３６を介してＳＵＰＬサーバ８２０にデバイスセキュリティクレデンシャルを送信することができる。
【００７６】
特定の実施形態では、図９の方法９００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図９の方法９００は、命令を実行するプロセッサによって実施することができる。
【００７７】
図１０を参照し、複数の識別子／パスワードを用いたＳＵＰＬ環境における認証の方法の特定の実施形態が示され、概して１０００で表される。例示するための実施形態において、方法１０００は、図８のＳＵＰＬサーバ８２０によって実施することができる。
【００７８】
方法１０００は、１００２において、モバイルデバイスから第１の識別子及び第１のパスワードをＳＵＰＬサーバにおいて受信することと、１００４において、第１の識別子及び第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証することと、を含むことができる。例えば、図８において、ＳＵＰＬサーバ８２０は、メッセージ８１５を介してモバイルデバイス８１０から第１の識別子及び第１のパスワードを受信することができ、及び、第１の識別子及び第１のパスワードが権限が付与されたユーザ（例えば、以前にモバイルデバイス８１０にバインドされた権限が付与されたユーザ）と関連付けられているとして認証することができる。
【００７９】
方法１０００は、１００６において、第１の識別子及び第１のパスワードに取って代わるための第２の識別子及び第２のパスワードをモバイルデバイスに送信することも含むことができる。ＳＵＰＬサーバは、モバイルデバイスから第２の識別子及び第２のパスワードを受信した時点でモバイルデバイスとＳＵＰＬセッションを確立するように構成することができる。例えば、図８において、ＳＵＰＬサーバ８２０は、第２の識別子及び第２のパスワードを生成してメッセージ８２４を介してモバイルデバイス８１０に送信することができ、及び、第２の識別子及び第２のパスワードを引き続いて受信した時点でモバイルデバイス８１０とのＳＵＰＬセッションを確立することができる。
【００８０】
方法１０００は、１００８において、第２のモバイルデバイスから第１の識別子及び第１のパスワードをＳＵＰＬサーバにおいて受信することと、１０１０において、第１の識別子及び第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証することと、をさらに含むことができる。例えば、図８において、ＳＵＰＬサーバ８２０は、メッセージ８４１を介して第２のモバイルデバイス８４０から第１の識別子及び第１のパスワードを受信することができ及び第１の識別子及び第１のパスワードが権限が付与されたユーザと関連付けられているとして認証することができる。例示するために、第２のモバイルデバイス８４０は、図９の方法９００を介して権限が付与されたユーザに以前にバインドしておくこともできる。
【００８１】
方法１０００は、１０１２において、第２のモバイルデバイスがＳＵＰＬサービスにアクセスするのを許容することが、ＳＵＰＬサービスにアクセスすることが許可された権限が付与されたユーザと関連付けられたモバイルデバイスのスレショルド数を超えるかどうかを決定することを含むことができる。例えば、図８において、ウェブサーバ８２０は、第２のモバイルデバイス８４０がＳＵＰＬサービスにアクセスするのを許容することがそのスレショルド数を超えることになるかどうかを決定することができる。特定の実施形態では、第２のモバイルデバイス８４０がＳＵＰＬサービスにアクセスするのを許容することがスレショルドを超えないときに、ウェブサーバ８２０は、メッセージ８２５を介して第２のモバイルデバイスに第３の識別子及び第３のパスワードを送信することができる。ウェブサーバ８２０は、第１のモバイルデバイス８１０及び第２のモバイルデバイス８４０によるＳＵＰＬサービスの使用法をモニタリングすることもできる。
【００８２】
特定の実施形態では、図１０の方法１０００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図１０の方法１０００は、命令を実行するプロセッサによって実施することができる。
【００８３】
図１１を参照し、無線通信デバイスの特定の例示的な実施形態のブロック図が描かれ、概して１１００で表される。例えば、デバイス１１００は、ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）、例えば、図１のモバイルデバイス１２０、図５のモバイルデバイス５２０、図８の第１のモバイルデバイス８１０、又は図８の第２のモバイルデバイス８４０であることができる。
【００８４】
デバイス１１００は、メモリ１１３２に結合されたプロセッサ１１１０を含む。メモリ１１３２は、ここにおいて開示される方法及びプロセス、例えば、図３の方法３００、図６の方法６００、図７の方法７００、又はそれらのあらゆる組み合わせ、を実施するためにプロセッサ１１１０によって実行可能な命令１１６０を含むことができる。
【００８５】
図１１は、プロセッサ１１１０及びディスプレイ１１２８に結合されるディスプレイコントローラ１１２６も示す。プロセッサ１１１０及びスピーカー１１３６及びマイク１１３８にはＣＯＤＥＣ１１３４を結合させることができる。図１１は、１つ以上の無線コントローラ１１４０をプロセッサ１１１０及び無線アンテナ１１４２、１１４３に結合できることも示す。特定の実施形態では、アンテナ１１４２は、３ＧＰＰ、３ＧＰＰ２、及び／又はＷｉＭＡＸアンテナであることができ、アンテナ１１４３は、Ｗｉ−Ｆｉアンテナであることができる。プロセッサ１１１０及び無線コントローラ１１４０にはカードインタフェース１１７０を結合することもできる。カードインタフェース１１７０は、デバイス１１００のセキュリティクレデンシャルを格納するカード１１７２（例えば、加入者アイデンティティモジュール（ＳＩＭ）カード、ユニバーサル集積回路カード（ＵＩＣＣ）、又はその他のカード）を収納するように構成することができる。例えば、セキュリティクレデンシャルは、デバイス証明書、公開／秘密鍵の対、ＩＭＥＩ、ＭＳＩＤ、一連番号、グローバルで一意の識別子、又はそれらのあらゆる組み合わせを含むことができる。代替として、又はさらに加えて、デバイス１１００のセキュリティクレデンシャルは、メモリ１１３２の“セキュアな”（例えば、ユーザによって変更不能及び／又はアクセス不能な）場所に格納することができる、例えば、セキュリティクレデンシャル１１６１。
【００８６】
特定の実施形態では、プロセッサ１１１０、ディスプレイコントローラ１１２６、メモリ１１３２、ＣＯＤＥＣ１１３４、無線コントローラ１１４０、及びカードインタフェース１１７０は、システム−イン−パッケージ（ｓｙｓｔｅｍ−ｉｎ−ｐａｃｋａｇｅ又はシステム−オン−チップ（ｓｙｓｔｅｍ−ｏｎ−ｃｈｉｐ）デバイス（例えば、移動局モデム（ＭＳＭ））１１２２に含められる。特定の実施形態では、入力デバイス１１３０、例えば、タッチ画面及び／又はキーパッド、及び電源１１４４がシステムーオンーチップデバイス１１２２に結合される。さらに、特定の実施形態では、図１１において例示されるように、ディスプレイ１１２８、入力デバイス１１３０、スピーカー１１３６、マイク１１３８、無線アンテナ１１４２及び１１４３、及び電源１１４４は、システムーオンーチップデバイス１１２２の外部である。しかしながら、ディスプレイ１１２８、入力デバイス１１３０、スピーカー１１３６、マイク１１３８、無線アンテナ１１４２及び１１４３、及び電源１１４４の各々は、システムーオンーチップデバイス１１２２のコンポーネント、例えば、インタフェース又はコントローラ、に結合することができる。
【００８７】
説明される実施形態と関連して、モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納するための手段を含む装置が開示される。例えば、格納するための手段は、図２のメモリ１２２、図１１のメモリ１１３２、図１１のカード１１７２、データを格納するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、モバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証するための少なくとも１つのセキュリティクレデンシャルをＳＬＰに送信することをモバイルデバイスに行わせるための手段も含むことができる。例えば、行わせるための手段は、図１のプロセッサ１２１、図１１のプロセッサ１１１０、図１の無線コントローラ１１４０、データの送信を行わせるように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。
【００８８】
さらに、ＳＵＰＬによってイネーブルにされるモバイルデバイスからのメッセージをウェブサーバにおいて受信するための手段を含む装置が開示され、メッセージは、モバイルデバイスのセキュリティクレデンシャルを含む。例えば、メッセージを受信するための手段は、図８のネットワークインタフェース８３４、データを受信するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、モバイルデバイスからのユーザ識別情報をウェブサーバにおいて受信するための手段も含む。例えば、ユーザ識別情報を受信するための手段は、図８のネットワークインタフェース８３４、データを受信するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証するための手段も含む。例えば、認証するための手段は、図８のプロセッサ８３１、ユーザ識別情報を認証するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、モバイルデバイスがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするためにモバイルデバイスのセキュリティクレデンシャルをＳＵＰＬサーバに送信するための手段を含む。例えば、送信するための手段は、図８のネットワークインタフェース８３４、データを受信するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。
【００８９】
さらに、モバイルデバイスからの第１の識別子及び第１のパスワードをＳＵＰＬサーバにおいて受信するための手段を含む装置が開示される。例えば、受信するための手段は、図８のＳＵＰＬサーバ８２０のネットワークインタフェース、データを受信するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、第１の識別子及び第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証するための手段も含む。例えば、認証するための手段は、図８の認証論理８２１を実行するためにプログラミングされたプロセッサ、例えば、図１のプロセッサ１１１、識別子及びパスワードを認証するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせを含むことができる。装置は、第１の識別子及び第１のパスワードに取って代わるための第２の識別子及び第２のパスワードをモバイルデバイスに送信するための手段をさらに含み、ＳＵＰＬサーバは、モバイルデバイスから第２の識別子及び第２のパスワードを受信した時点でモバイルデバイスとのＳＵＰＬセッションを確立するように構成される。例えば、送信するための手段は、ＳＵＰＬサーバ８２０のネットワークインタフェース、データを送信するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、第２の識別子及び第２のパスワードを生成するための手段を含むことができる。例えば、生成するための手段は、図８の識別子／パスワード生成論理８２２を実行するためにプログラミングされたプロセッサ、例えば、図１のプロセッサ１１１、識別子及びパスワードを生成するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。
【００９０】
特定の実施形態では、上記のシステム及び方法の全部又は一部は、以下の追加の実施形態を参照してさらに説明することができ、及び／又は以下の追加の実施形態を参照して説明されるシステム及び方法によって選択的に、個々に又は組み合わせて取り替えることができる。
【００９１】
追加の実施形態１
序論
・  ＳＵＰＬ２．０におけるセキュリティは、アクセスネットワーク専用である。
【００９２】
・  代替クライアント認証（ＡＣＡ）は、ソースＩＰアドレスに基づいてＳＥＴを識別するためのコアネットワークへのアクセスを要求する
・  ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・  ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・  ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
【００９３】
・  ＧＢＡ及び“ユーザ名／パスワード”認証の両方をサポートする単純な枠組
・  単一のＴＬＳの変形を使用することができる
・  仕様及び実装を最小限変更
概念概要
・  ＵＬＰセキュリティ
・  サーバ証明書によるＴＬＳ
・  ２つのクライアント認証モード
−    （ユーザモード）：（Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（ユーザ名、パスワード）
−    （ＧＢＡモード）：（Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）
・  （Ｕｓｅｒ_ＩＤ，Ｃｏｕｎｔｅｒ，Ｄｉｇｅｓｔ）が全メッセージに加えられ、Ｄｉｇｅｓｔは以下のように計算される。
【００９４】
・  Ａ１＝ＳＬＰ_Ｄｏｍａｉｎ||ＵＬＰ_Ｍｅｓｓａｇｅ
・  Ｄｉｇｅｓｔ＝ＨＭＡＣ（Ｕｓｅｒ_ｓｅｃｒｅｔ，Ａ１）
・  送信元が（Ｕｓｅｒ_ＩＤ，  Ｃｏｕｎｔｅｒ，  Ｄｉｇｅｓｔ）を全メッセージに加え、受信元が検証する
・  ＵＬＰがＳＵＰＬ  ＩＮＩＴクレデンシャルを更新するために使用される
・  ＳＵＰＬ  ＩＮＩＴ保護［例えば、非緊急時のみ］
・  ＵＬＰｖ２．０  Ｂａｓｉｃ  ＳＵＰＬ  ＩＮＩＴ  Ｐｒｏｔｅｃｔｉｏｎを模倣
・  ＵＬＰを介してＳＬＰによって提供されたＳＵＰＬ  ＩＮＩＴクレデンシャルを使用
セットアップ詳細
・  オフライン
・  （ユーザモード）ユーザ及びＳＬＰが（ユーザ名、パスワード）を取り決める
−  ＳＬＰは、（ユーザ名、パスワード）をユーザに提供することができる
−  ユーザは、（ユーザ名、パスワード）をＳＬＰに提供することができる
−  これは、Ｈ−ＳＬＰ又はＡ−ＳＬＰの両方が利用可能である。
【００９５】
・  ＳＥＴ立ち上がり時
・  （ユーザモード）
−  ユーザが（ユーザ名、パスワード）をＳＵＰＬクライアントに入力する
・  （ＧＢＡモード）
−  ＳＥＴがＢＳＦとブートストラップして（Ｂ−ＴＩＤ，Ｋ−ｓ）を入手する
−  ＳＥＴは、必要に応じた頻度で（Ｂ−ＴＩＤ，Ｋｓ）をリフレッシュすることができることに注目すること
・  ＳＵＰＬクライアントがＳＬＰとのＵＬＰセッションを実施して新しいＳＵＰＬ  ＩＮＩＴクレデンシャルを入手する
ＵＬＰセッションセキュリティ提案
・  サーバ証明書によるＴＬＳを使用することができる
・  サーバ認証を取り扱う
・  新しいパラメータをＵＬＰメッセージに加える
・  （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）をＳＥＴからのメッセージに
・  （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）をＳＬＰからのメッセージに
・  ＳＥＴを発生元とするメッセージ
・  ＳＥＴが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）を加える
・  ＳＬＰが、メッセージ内容を処理する前にＲｅｑ_Ｃｏｕｎｔ及びＲｅｑ_Ｄｉｇｅｓｔを検証する
・  ＳＬＰを発生元とするメッセージ
・  ＳＬＰが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）を加える
・  ＳＥＴが、メッセージ内容を処理する前にＲｅｑ_Ｃｏｕｎｔ及びＲｅｓｐ_Ｄｉｇｅｓｔを検証する
Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔ
・  Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは同様の挙動を有する
・  カウンタの目的は、リプレイ検出を可能にすることである
・  Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは、ＵＬＰセッションごとに受信元及び送信元においてリセットされる
・  すなわち、カウンタは、セッション識別子が変更されたときにリセットされる。
【００９６】
・送信元において
・  Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔが個々のメッセージごとに増分され、ＵＬＰメッセージに加えられる
・受信元において
・  受信元が、予想した値とＲｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔを比較する。リプレイを検出した場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成
・  Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成は同一であることができる。
【００９７】
・  すべての既知値をＵＬＰ_Ｍｅｓｓａｇｅフィールド内に挿入する
・  ＵＬＰ_Ｍｅｓｓａｇｅ_ＺをＵＬＰ_Ｍｅｓｓａｇｅとして形成し、Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔフィールドがすべてゼロに設定される
・  ＤｉｇｅｓｔＰａｙｌｏａｄ＝ＳＬＰ_Ｄｏｍａｉｎ“：”ＵＬＰ_Ｍｅｓｓａｇｅ_Ｚを形成する
・次式を計算する
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ＝ＨＭＡＣ−ＳＨＡ２５６−３２（Ｕｓｅｒ_ｓｅｃｒｅｔ，  ＤｉｇｅｓｔＰａｙｌｏａｄ）
・  ＵＬＰ_Ｍｅｓｓａｇｅ内の該当フィールドにＲｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔを加える
・  （ユーザモード）
・  （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（ユーザ名、パスワード）を使用する
・  （ＧＢＡモード）
・  （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）を使用し、ここで、
・  ［ＳＥＴ］Ｋｓ及びＳＬＰ  ＵＲＬからＫｓ_ＮＡＦを生成する
・  ［ＳＬＰ］Ｕｓｅｒ_ＩＤフィールドを抽出した時点で、ＳＬＰがＢＳＦにＢ−ＴＩＤを提供し、ＢＳＦは、Ｋｓ_ＮＡＦとともに戻る。Ｋｓ_ＮＡＦは、Ｂ−ＴＩＤが変化しないかぎり変化しない。
【００９８】
ＳＵＰＬ  ＩＮＩＴセキュリティ提案
・  ＵＬＰ  ＴＳ  Ｖ２．０  Ｓｅｃｔｉｏｎ６．１．６．６において既に定義されているＢａｓｉｃ  ＳＵＰＬ_ＩＮＩＴ  Ｐｒｏｔｅｃｔｉｏｎを模倣する
・  ＧＢＡによってプロビジョニングされた鍵からＳＬＰによってプロビジョニングされた鍵への適合化された記述
・  ＳＬＰが、クライアント又はＳＬＰのイニシアチブでＵＬＰセッション中に（鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新する
−  鍵識別子がリセットされたときにＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる
・  最小限の標準化努力が要求される
ＳＵＰＬ_ＩＮＩＴクレデンシャル管理
・  あらゆる接続セッションの最初のＵＬＰのやり取りにおいて生じる
・  ＳＥＴを発生元とするメッセージ
・  セッションの最初のメッセージは下記のいずれかを含むべきである。
【００９９】
−  クレデンシャルが入手可能でない場合は、“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑ”インジケータ、又は
−  ＳＥＴ及びＳＬＰが同期外れであるかどうかをＳＬＰが検出するのを可能にするためのＣｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒ。
【０１００】
・ＳＬＰを発生元とするメッセージ
・  Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しい場合は、確認のための“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_ＯＫ”インジケータを加える。
【０１０１】
・  Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しくない場合、又は、ＳＥＴが“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑインジケータを送信した又はサーバがＳＵＰＬ_ＩＮＩＴクレデンシャルを更新することを希望する場合は、ＳＬＰは、ＳＵＰＬ_ＩＮＩＴクレデンシャルをプロビジョニングするためにＵＬＰメッセージにフィールドを加える
−  （鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を含む
呼流れ例−ＳＩ即時フィックス
・  ステップＡ：ターゲットＳＥＴがｒｅｑ_ｃｏｕｎｔを１２３４（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し、メッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴがＳＵＰＬ  ＳＴＡＲＴ（ｕｓｅｒ−ｉｄ，  ｒｅｑ_ｃｏｕｎｔ＝１２３４，  ｒｅｑ_ｄｉｇｅｓｔ，．．．）メッセージをＨ−ＳＬＰに送信する。
【０１０２】
・  ステップＢ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ  ＳＴＡＲＴの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰが、ｒｅｓ_ｃｏｕｎｔを４３２１（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し、メッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰがＳＵＰＬ  ＲＥＳＰＯＮＳＥ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１，ｒｅｓ_ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴにおけるＳＵＰＬ  ＳＴＡＲＴとＳＵＰＬ  ＲＥＳＰＯＮＳＥとの間の期間＝ＵＴ１。
【０１０３】
・  ステップＣ：ターゲットＳＥＴが、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ  ＲＥＳＰＯＮＳＥの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴが、ｒｅｑ_ｃｏｕｎｔを１だけ増分し（１２３４＋１）及びメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴがＳＵＰＬ  ＰＯＳ  ＩＮＩＴ（ｕｓｅｒ−ｉｄ，  ｒｅｑ_ｃｏｕｎｔ＝１２３４＋１，  ｒｅｑ_ｄｉｇｅｓｔ．．．）メッセージをＨ−ＳＬＰに送信する。Ｈ−ＳＬＰにおけるＳＵＰＬ  ＲＥＳＰＯＮＳＥとＳＵＰＬ  ＰＯＳ  ＩＮＩＴとの間の期間＝ＳＴ１。
【０１０４】
・  ステップＤ：ターゲットＳＥＴ及びＨ−ＳＬＰがＳＵＰＬ  ＰＯＳのやり取りに従事する。ターゲットＳＥＴにおけるＳＵＰＬ  ＰＯＳ  ＩＮＩＴとＳＵＰＬ  ＰＯＳとの間の期間＝ＵＴ２。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタ（ｒｅｑ_ｃｏｕｎｔ／ｒｅｓ_ｃｏｕｎｔ）に基づいてリプレイ完全性を検査する。
【０１０５】
・  ステップＥ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いて受信された最後のＳＵＰＬ  ＰＯＳメッセージの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰがｒｅｑ_ｃｏｕｎｔを増分し（４３２１＋１）、メッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰが、ＳＵＰＬ  ＥＮＤ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１＋１，  ｒｅｓ_ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴは、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ  ＥＮＤの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴにおけるＳＵＰＬ  ＰＯＳとＳＵＰＬ  ＥＮＤとの間の期間＝ＵＴ３。
【０１０６】
呼流れ例−ＮＩ即時フィックス
・  ステップＡ：Ｈ−ＳＬＰがｒｅｓ_ｃｏｕｎｔを１２３４（又はＨ−ＳＬＰによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ＢａｓｉｃＭＡＣ）を計算する。Ｈ−ＳＬＰがＳＵＰＬ  ＩＮＩＴ（ｕｓｅｒ−ｉｄ，  ｒｅｓ_ｃｏｕｎｔ＝４３２１，ＢａｓｉｃＭＡＸ，．．．）メッセージをターゲットＳＥＴに送信する。
【０１０７】
・  ステップＢ：ターゲットＳＥＴが、受信されたメッセージダイジェスト（ＢａｓｉｃＭＡＣ）を用いてＳＵＰＬ  ＩＮＩＴの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴが、ｒｅｑ_ｃｏｕｎｔを１２３４（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴが、ＳＵＰＬ  ＰＯＳ  ＩＮＩＴ（ｕｓｅｒ−ｉｄ，ｒｅｑ_ｃｏｕｎｔ＝１２３４，ｒｅｑ−ｄｉｇｅｓｔ，．．．）メッセージをＨ−ＳＬＰに送信する。Ｈ−ＳＬＰにおけるＳＵＰＬ  ＩＮＩＴとＳＵＰＬ  ＰＯＳ  ＩＮＩＴとの間の期間＝ＳＴ１。
【０１０８】
・  ステップＣ：ターゲットＳＥＴ及びＨ−ＳＬＰがＳＵＰＬ  ＰＯＳのやり取りに従事する。ターゲットＳＥＴにおけるＳＵＰＬ  ＰＯＳ  ＩＮＩＴとＳＵＰＬ  ＰＯＳとの間の期間＝ＵＴ２。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタ（ｒｅｑ_ｃｏｕｎｔ／ｒｅｓ_ｃｏｕｎｔ）に基づいてリプレイ完全性を検査する。
【０１０９】
・  ステップＤ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いて受信された最後のＳＵＰＬ  ＰＯＳメッセージの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰがｒｅｑ_ｃｏｕｎｔを増分し（４３２１＋１）及びメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰが、ＳＵＰＬ  ＥＮＤ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１＋１，ｒｅｓ_ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴは、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ  ＥＮＤの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴにおけるＳＵＰＬ  ＰＯＳとＳＵＰＬ  ＥＮＤとの間の期間＝ＵＴ３。
【０１１０】
追加の実施形態２
序論
・  ＳＵＰＬ２．０におけるセキュリティは、アクセスネットワーク専用である。
【０１１１】
・  ＡＣＡは、ソースＩＰアドレスに基づいてＳＥＴを識別するためのコアネットワークへのアクセスを要求する
・  ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・  ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・  ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
【０１１２】
・  ＧＢＡ及び“ユーザ名／パスワード”認証の両方をサポートする単純な枠組
・  単一のＴＬＳの変形を使用することができる
・  仕様及び実装の最小限の変更
概念概要
・  ＵＬＰセキュリティ
・  サーバ証明書によるＴＬＳ
・  ２つのクライアント認証モード
−    （ユーザモード）：（Ｕｓｅｒ_ＩＤ，  Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（ユーザ名、パスワード）
−    （ＧＢＡモード）：（Ｕｓｅｒ_ＩＤ，  Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）
・  （Ｕｓｅｒ_ＩＤ，  Ｃｏｕｎｔｅｒ，  Ｄｉｇｅｓｔ）が全メッセージに加えられ、Ｄｉｇｅｓｔは以下のように計算される。
【０１１３】
・  Ａ１＝ＳＬＰ_Ｄｏｍａｉｎ||ＵＬＰ_Ｍｅｓｓａｇｅ
・  Ｄｉｇｅｓｔ＝ＨＭＡＣ（Ｕｓｅｒ_ｓｅｃｒｅｔ，Ａ１）
・  送信元が（Ｕｓｅｒ_ＩＤ，  Ｃｏｕｎｔｅｒ，  Ｄｉｇｅｓｔ）を全メッセージに加え、受信元が検証する
・  ＵＬＰがＳＵＰＬ  ＩＮＩＴクレデンシャル（鍵アイデンティティ、ＳＵＰ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新するために使用される
・  ＳＵＰＬ  ＩＮＩＴ保護［例えば、非緊急時のみ］
・  ＳＬＰ（ユーザモード）又はＧＢＡ（ＧＢＡモード）によって生成されたＳＵＰＬ  ＩＮＩＴクレデンシャルを有するＵＬＰｖ２．０  ＢａｓｉｃＳＵＰＬ  ＩＮＩＴ  Ｐｒｏｔｅｃｔｉｏｎを使用する
・  ユーザモードでＵＬＰを介してＳＬＰによって提供されたＳＵＰＬ  ＩＮＩＴクレデンシャルを使用する
セットアップ詳細
・  オフライン
・  （ユーザモード）ユーザ及びＳＬＰが（ユーザ名、パスワード）を取り決める
−  ＳＬＰは、（ユーザ名、パスワード）をユーザに提供することができる
−  ユーザは、（ユーザ名、パスワード）をＳＬＰに提供することができる
−  これは、Ｈ−ＳＬＰ又はＡ−ＳＬＰの両方が利用可能である。
【０１１４】
・  ＳＥＴ立ち上がり時
・  （ユーザモード）
−  ユーザが（ユーザ名、パスワード）をＳＵＰＬクライアントに入力する
・  （ＧＢＡモード）
−  ＳＥＴがＢＳＦとブートストラップして（Ｂ−ＴＩＤ，Ｋｓ）を入手する
−  ＳＥＴは、必要に応じた頻度で（Ｂ−ＴＩＤ，Ｋｓ）をリフレッシュすることができることに注目すること
・  ＳＵＰＬクライアントが新しいＳＵＰＬ  ＩＮＩＴクレデンシャルを入手するためにＳＬＰとのＵＬＰセッションを実施する
ＵＬＰセッションセキュリティ提案
・  サーバ証明書によるＴＰＬを使用することができる
・  サーバ認証を取り扱う
・新しいパラメータをＵＬＰメッセージに加える
・  （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）をＳＥＴからのメッセージに
・  （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）をＳＬＰからのメッセージに
・  ＳＥＴを発生元とするメッセージ
・  ＳＥＴが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）を加える
・  ＳＬＰが、メッセージ内容を処理する前にＲｅｑ_Ｃｏｕｎｔ及びＲｅｑ_Ｄｉｇｅｓｔを検証する
・ＳＬＰを発生元とするメッセージ
・  ＳＬＰが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）を加える
・  ＳＥＴが、メッセージ内容を処理する前にＲｅｓｐ_Ｃｏｕｎｔ及びＲｅｓｐ_Ｄｉｇｅｓｔを検証する
Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔ
・  Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは同様の挙動を有する
・  カウンタの目的は、リプレイ検出を可能にすることである
・  Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは、ＵＬＰセッションごとに受信元及び送信元においてリセットされる
・  すなわち、カウンタは、セッション識別子が変更されたときにリセットされる。
【０１１５】
・  送信元において
・  Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔが個々のメッセージごとに増分され、ＵＬＰメッセージに加えられる
・受信元において
・  受信元が、予想した値とＲｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔを比較する。リプレイを検出した場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成
・  Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成は同一であることができる。
【０１１６】
・  すべての既知値をＵＬＰ_Ｍｅｓｓａｇｅフィールド内に挿入する
・  ＵＬＰ_Ｍｅｓｓａｇｅ_ＺをＵＬＰ_Ｍｅｓｓａｇｅとして形成し、Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔフィールドがすべてゼロに設定される
・  ＤｉｇｅｓｔＰａｙｌｏａｄ＝ＳＬＰ_Ｄｏｍａｉｎ“：”ＵＬＰ_Ｍｅｓｓａｇｅ_Ｚを形成する
・次式を計算する
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ＝ＨＭＡＣ−ＳＨＡ２５６−３２（Ｕｓｅｒ_ｓｅｃｒｅｔ，  ＤｉｇｅｓｔＰａｙｌｏａｄ）
・  ＵＬＰ_Ｍｅｓｓａｇｅ内の該当フィールドにＲｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔを加える
・  （ユーザモード）
・  （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（ユーザ名、パスワード）を使用する
・  （ＧＢＡモード）
・  （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）を使用し、ここで、
・  ［ＳＥＴ］Ｋｓ及びＳＬＰ  ＵＲＬからＫｓ_ＮＡＦを生成する
・  ［ＳＬＰ］Ｕｓｅｒ_ＩＤフィールドを抽出した時点で、ＳＬＰがＢＳＦにＢ−ＴＩＤを提供し、ＢＳＦは、Ｋｓ_ＮＡＦとともに戻る。Ｋｓ_ＮＡＦは、Ｂ−ＴＩＤが変化しないかぎり変化しない。
【０１１７】
ＳＵＰＬ  ＩＮＩＴセキュリティ提案
・  ＵＬＰ  ＴＳ  Ｖ２．０  Ｓｅｃｔｉｏｎ６．１．６．６において既に定義されているＢａｓｉｃ  ＳＵＰＬ_ＩＮＩＴ  Ｐｒｏｔｅｃｔｉｏｎを使用する
・  ユーザモードにおけるＧＢＡによってプロビジョニングされた鍵からＳＬＰによってプロビジョニングされた鍵への適合化された記述
・  ＳＬＰが、ユーザモードにおいてクライアント又はＳＬＰのイニシアチブでＵＬＰセッション中に（鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新する
−  鍵識別子がリセットされたときにＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる
・  最小限の標準化努力が要求される
ＳＵＰＬ_ＩＮＩＴ  Ｐｒｏｔｅｃｔｉｏｎパラメータ
・  Ｂａｓｉｃ  ＳＵＰＬ  ＩＮＩＴ  ＰｒｏｔｅｃｔｉｏｎのためのＳＵＰＬ  ＩＮＩＴプロテクタは、下記から成る。
【０１１８】
・  鍵識別子
・  ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ（長さ＝２オクテット）
・  ＢａｓｉｃＭＡＣ（長さ＝４オクテット）
・  ＢａｓｉｃＭＡＣパラメータは、以下のように生成される。
【０１１９】
・  ＢａｓｉｃＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ，‘ＳＵＰＬ_ＩＮＩＴ’）
・  ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｂａｓｉｃ  ＩＫ”
・  鍵識別子がリセットされるときにＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる。
【０１２０】
・  鍵識別子及びＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、Ｕｓｅｒ_ＩＤ及びＵｓｅｒ_ｓｅｃｒｅｔと同じでなく、すなわち、ＳＵＰＬ  ＩＮＩＴ保護は、ＵＬＰメッセージ認証から独立して機能する。
【０１２１】
ＳＵＰＬ_ＩＮＩＴクレデンシャル管理
・  あらゆる接続セッションの最初のＵＬＰやり取りにおいて生じる
・  ＳＥＴを発生元とするメッセージ
・  セッションの最初のメッセージは下記のいずれかを含むべきである。
【０１２２】
−  クレデンシャルが入手可能でない場合は、“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑ”インジケータ、又は
−  ＳＥＴ及びＳＬＰが同期外れであるかどうかをＳＬＰが検出するのを可能にするためのＣｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒ
・ＳＬＰを発生元とするメッセージ
・  Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しい場合は、確認のための“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_ＯＫ”インジケータを加える
・  Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しくない場合、又は、ＳＥＴが“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑインジケータを送信した又はサーバがＳＵＰＬ_ＩＮＩＴクレデンシャルを更新することを希望する場合は、ＳＬＰは、ＳＵＰＬ_ＩＮＩＴクレデンシャルをプロビジョニングするためにＵＬＰメッセージにフィールドを加える。
【０１２３】
−  （鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を含む。
【０１２４】
呼流れ例−ＳＩ即時フィックス
・  ステップＡ：ターゲットＳＥＴがｒｅｑ_ｃｏｕｎｔを１２３４（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴがＳＵＰＬ  ＳＴＡＲＴ（ｕｓｅｒ−ｉｄ，  ｒｅｑ_ｃｏｕｎｔ＝１２３４，  ｒｅｑ_ｄｉｇｅｓｔ，．．．）メッセージをＨ−ＳＬＰに送信する。
【０１２５】
・  ステップＢ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ  ＳＴＡＲＴの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰが、ｒｅｓ_ｃｏｕｎｔを４３２１（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰがＳＵＰＬ  ＲＥＳＰＯＮＳＥ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１，ｒｅｓ−ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴにおけるＳＵＰＬ  ＳＴＡＲＴとＳＵＰＬ  ＲＥＳＰＯＮＳＥとの間の期間＝ＵＴ１。
【０１２６】
・  ステップＣ：ターゲットＳＥＴが、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ  ＲＥＳＰＯＮＳＥの真正性を検査し及びリプレイカウンタ（ｒｅｓ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴが、ｒｅｑ_ｃｏｕｎｔを１だけ増分し（１２３４＋１）及びメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴが、ＳＵＰＬ  ＰＯＳ  ＩＮＩＴ（ｕｓｅｒ−ｉｄ，  ｒｅｑ_ｃｏｕｎｔ＝１２３４＋１，  ｒｅｑ_ｄｉｇｅｓｔ．．．）メッセージをＨ−ＳＬＰに送信する。Ｈ−ＳＬＰにおけるＳＵＰＬ  ＲＥＳＰＯＮＳＥとＳＵＰＬ  ＰＯＳ  ＩＮＩＴとの間の期間＝ＳＴ１。
【０１２７】
・  ステップＤ：ターゲットＳＥＴ及びＨ−ＳＬＰがＳＵＰＬ  ＰＯＳのやり取りに従事する。ターゲットＳＥＴにおけるＳＵＰＬ  ＰＯＳ  ＩＮＩＴとＳＵＰＬ  ＰＯＳとの間の期間＝ＵＴ２。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタ（ｒｅｑ_ｃｏｕｎｔ／ｒｅｓ_ｃｏｕｎｔ）に基づいてリプレイ完全性を検査する。
【０１２８】
・  ステップＥ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いて受信された最後のＳＵＰＬ  ＰＯＳメッセージの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰがｒｅｑ_ｃｏｕｎｔを増分し（４３２１＋１）及びメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰが、ＳＵＰＬ  ＥＮＤ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１＋１，  ｒｅｓ_ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴが、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ  ＥＮＤの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴにおけるＳＵＰＬ  ＰＯＳとＳＵＰＬ  ＥＮＤとの間の期間＝ＵＴ３。
【０１２９】
呼流れ例−ＮＩ即時フィックス
・  ステップＡ：Ｈ−ＳＬＰがｒｅｓ_ｃｏｕｎｔを１２３４（又はＨ−ＳＬＰによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ＢａｓｉｃＭＡＣ）を計算する。Ｈ−ＳＬＰがＳＵＰＬ  ＩＮＩＴ（ｕｓｅｒ−ｉｄ，  ｒｅｓ_ｃｏｕｎｔ＝４３２１，ＢａｓｉｃＭＡＸ，．．．）メッセージをターゲットＳＥＴに送信する。
【０１３０】
・  ステップＢ：ターゲットＳＥＴが、受信されたメッセージダイジェスト（ＢａｓｉｃＭＡＣ）を用いてＳＵＰＬ  ＩＮＩＴの真正性を検査し及びリプレイカウンタ（ｒｅｓ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴが、ｒｅｑ_ｃｏｕｎｔを１２３４（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴが、ＳＵＰＬ  ＰＯＳ  ＩＮＩＴ（ｕｓｅｒ−ｉｄ，ｒｅｑ_ｃｏｕｎｔ＝１２３４，ｒｅｑ−ｄｉｇｅｓｔ，．．．）メッセージをＨ−ＳＬＰに送信する。Ｈ−ＳＬＰにおけるＳＵＰＬ  ＩＮＩＴとＳＵＰＬ  ＰＯＳ  ＩＮＩＴとの間の期間＝ＳＴ１。
【０１３１】
・  ステップＣ：ターゲットＳＥＴ及びＨ−ＳＬＰがＳＵＰＬ  ＰＯＳのやり取りに従事する。ターゲットＳＥＴにおけるＳＵＰＬ  ＰＯＳ  ＩＮＩＴとＳＵＰＬ  ＰＯＳとの間の期間＝ＵＴ２。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタ（ｒｅｑ_ｃｏｕｎｔ／ｒｅｓ_ｃｏｕｎｔ）に基づいてリプレイ完全性を検査する。
【０１３２】
・  ステップＤ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いて受信された最後のＳＵＰＬ  ＰＯＳメッセージの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰがｒｅｑ_ｃｏｕｎｔを増分し（４３２１＋１）及びメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰが、ＳＵＰＬ  ＥＮＤ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１＋１，  ｒｅｓ_ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴが、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ  ＥＮＤの真正性を検査し及びリプレイカウンタ（ｒｅｓ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴにおけるＳＵＰＬ  ＰＯＳとＳＵＰＬ  ＥＮＤとの間の期間＝ＵＴ３。
【０１３３】
追加の実施形態３
序論
・  ＳＵＰＬ２．０におけるセキュリティは、アクセスネットワーク専用である。
【０１３４】
・  ＡＣＡは、ソースＩＰアドレスに基づいてＳＥＴを識別するためのコアネットワークへのアクセスを要求する
・  ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・  ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・  ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
【０１３５】
・  ＧＢＡ及び“ユーザ名／パスワード”認証の両方をサポートする単純な枠組
【表１】
0005876063.tif 000002
【表２】
0005876063.tif 000003
【０１３６】
選択肢Ｉ：概念概要
・  ＵＬＰセキュリティ
・  ＧＢＡモード：以前と同じようにＴＬＳ−ＰＳＫを使用
・  ユーザモードＵＬＰ：（ユーザ名、パスワード）に基づく
−        最初にサーバ証明書によるＴＬＳハンドシェイクを実施してセキュアなコネクションを確立する
・  ＳＥＴによって送信された全ＵＬＰメッセージに加えられた（ユーザ名、カウンタ、ダイジェスト）であり、ダイジェストは以下のように計算される
−        Ａ１＝ＳＬＰ_Ｄｏｍａｉｎ||ＵＬＰ_Ｍｅｓｓａｇｅ
−        Ｄｉｇｅｓｔ＝ＨＭＡＣ（Ｐａｓｓｗｏｒｄ，Ａ１）
・  ＳＥＴが（ユーザ名、カウンタ、ダイジェスト）を全メッセージに加え、ＳＬＰが検証する
・  ＳＵＰＬ  ＩＮＩＴ保護のために要求されるＳＵＰＬ  ＩＮＩＴクレデンシャル（Ｋｅｙ  Ｉｄｅｎｔｉｔｙ，ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新するためにＵＬＰが使用される
選択肢Ｉ：オフライン手順
・  ユーザモードＵＬＰ（オフライン）
・  ユーザ及びＳＬＰオペレータが（ユーザ名、パスワード）を取り決める
・  その他の前提事項
・  ＳＥＴがＳＬＰのＵＲＬを有する
・  ＳＥＴがＳＬＰを認証するための該当するルート証明書を有する
選択肢Ｉ：オンライン手順
・  サーバ認証及び暗号化のために用いられるサーバ証明書によるＴＬＳ
・  ＳＥＴからのＵＬＰメッセージに新しいパラメータが加えられる：（ユーザ名、カウンタ、ダイジェスト）
・  ＳＬＰが、ＵＬＰメッセージ内容を処理する前にカウンタ及びダイジェストを検証する
・  カウンタの目的は、リプレイ検出を可能にすることである
・  すべてのＵＬＰセッションに関して受信元及び送信元においてカウンタがリセットされる
・  送信元において、メッセージごとにカウンタが増分され、ＵＬＰメッセージに加えられる
・  受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す。
【０１３７】
選択肢ＩＩ：概念概要
・  ＵＬＰセキュリティ
・  ＧＢＡモード：以前と同じようにＴＬＳ−ＰＳＫを使用
・  ユーザモードＴＬＳ：（ユーザ名、パスワード）に基づく
−        最初にサーバ証明書によるＴＬＳハンドシェイクを実施してセキュアなコネクションを確立する。
【０１３８】
−        ＳＬＰが、ＴＬＳ再交渉を開始するために“Ｈｅｌｌｏ  Ｒｅｑｕｅｓｔ”を送信する。次に、ＳＥＴ及びＳＬＰが、（ユーザ名、パスワード）を用いてユーザを認証するためにＴＬＳ−ＳＲＰハンドシェイク（ＳＲＰ＝セキュアリモートパスワード）を実施する。
【０１３９】
−        ＴＬＳ−ＳＲＰハンドシェイクにおいてユーザ名を隠すために最初のセキュアなコネクションが要求される。
【０１４０】
・  ＳＵＰＬ  ＩＮＩＴ保護のために要求される基本的保護ＳＵＰＬ  ＩＮＩＴクレデンシャル（Ｋｅｙ  Ｉｄｅｎｔｉｔｙ，ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新するためにＵＬＰが使用される
選択肢ＩＩ：オフライン手順
・  ユーザモードＴＬＳ（オフライン）
・  ユーザ及びＳＬＰオペレータが（ユーザ名、パスワード）を取り決める
・  その他の前提事項
・  ＳＥＴがＳＬＰのＵＲＬを有する
・  ＳＥＴがＳＬＰを認証するための該当するルート証明書を有する
選択肢ＩＩ：オンライン手順
・  ＳＥＴがＴＬＳハンドシェイクを開始し、該当する暗号スィートを選択することによってＧＢＡ及び／又はユーザモードのためのサポートをＴＬＳにおいて示す。
【０１４１】
・  ＳＬＰがＧＢＡモード又はユーザモードを進めるべきかどうかを決定する
・ＧＢＡモードの場合
・  セキュアなトンネルを確立するためにＧＢＡを用いてＴＬＳ−ＰＳＫの場合と同じようにＴＬＳハンドシェイクを継続する
・相互認証
・  セキュアなチャネルでデータをやり取りする
・ユーザモードの場合
・  最初に、セキュアなチャネルを確立するためにサーバ証明書によるＴＬＳハンドシェイクを継続する
・  ＳＥＴがＳＬＰを認証する
・  ＴＬＳ＝ＳＲＰハンドシェイクを実施する（メッセージは、セキュアなチャネル内部でやり取りされる）
・  ＳＬＰがユーザを認証する
・新しいセッション鍵が得られる
・  新しいセッション鍵によって保護されたセキュアなトンネルでデータをやり取りする
選択肢ＩＩ：オンライン手順−最初のＴＬＳハンドシェイク
・  ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ  Ｈｅｌｌｏ：
・すべてのサポートされる暗号スイートを示す
−        ＳＥＴがＧＢＡをサポートする場合は、ＴＬＳ−ＰＳＫ暗号スイートのためのサポートを示す
−        ＳＥＴがユーザモードをサポートする場合は、サーバ証明書及びＴＬＳ  ＳＲＰを用いるＴＬＳのためのサポートを示す
・  ＳＥＴはこの時点ではユーザ名を提供せず、要求される場合は、次のＴＬＳハンドシェイクで提供される。
・  ＳＬＰ→ＳＥＴ：Ｓｅｒｖｅｒ  Ｈｅｌｌｏ：
・  選択された暗号スイートを示す
−        ＳＬＰがＧＢＡモードを選択する場合は、ＳＬＰは、ＴＬＳ−ＰＳＫ暗号スイートを示す
−        ＳＬＰがユーザモードを選択する場合は、ＳＬＰは、サーバ証明書を用いるＴＬＳのための暗号スイートを示す
−        呼の流れが選択された暗号スイートの場合と同じように進む
選択肢ＩＩ：オンライン手順−最初のＴＬＳハンドシェイク後
・  ＧＢＡモード
・  ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルを通じての通信を開始する
・  ユーザモード
・  ＳＬＰ→ＳＥＴ：Ｈｅｌｌｏ  Ｒｅｑｅｕｓｔ
・  再交渉を開始する
・  ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ  Ｈｅｌｌｏ
・  ＴＬＳ−ＳＲＰのためのサポートを示す
・  ＴＬＳ−ＳＲＰ仕様に準拠してユーザ名を含める
・  ＳＥＴ→ＳＬＰ：ＳｅｒｖｅｒＨｅｌｌｏ
・  ＴＬＳ−ＳＲＰの選択を示す
・  ＴＬＳ−ＳＲＰに準拠してやり取りを継続する
・  成功裏のハンドシェイクに後続して、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでデータをやり取りすることを開始する
ＳＵＰＬ  ＩＮＩＴ保護
・  ＳＵＰＬ３．０におけるＳＵＰＬ  ＩＮＩＴ保護は、ＳＵＰＬ２．０におけるＳＵＰＬ  ＩＮＩＴ保護メカニズムに基づき、ＳＵＰＬ  ＩＮＩＴに添付されたメッセージ認証コード（ＭＡＣ）を使用する
・  ＭＡＣは、ユーザモードでＵＬＰを通じてプロビジョニングされた（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ，  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を用いて計算される（ＧＢＡモードは、プロビジョニングを要求しない）
・  （Ｋｅｙ，Ｉｄｅｎｔｉｔｙ，  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を計算するための２つの方法：
・  ＧＢＡモード：（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ，  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）＝（Ｂ−ＴＩＤ，Ｋｓ）
−  （Ｂ−ＴＩＤ，Ｋｓ）がＢＳＦからブートストラップを外される
・  ユーザモード：（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ，  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）が（ユーザ名、パスワード）から生成される
・  ＳＵＰＬ  ＩＮＩＴ保護は、選択肢Ｉ及び選択肢ＩＩに関して同じである
ＳＵＰＬ  ＩＮＩＴ保護メカニズム
・  ＳＵＰＬｖ３．０における２つの保護レベル
・ＮＵＬＬ
−        セキュリティなし
・  基本的保護
−        ＵＬＰを通じてプロビジョニングされた共有される鍵アイデンティティ、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹに基づく
−        ＳＵＰＬｖ２．０からの基本的保護を模倣する
−        鍵識別子及びＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、ユーザ名、パスワードと同じでない
・  再同期化保護メカニズム
・  ＳＥＴがＳＥＴにおいてＳＬＰの証明書から検証することができるというデジタルシグナチャに基づく
・  ＳＬＰ及びＳＥＴにおける鍵アイデンティティ、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが同期外れになっていることにＳＬＰが納得するときしか使用できない
・  計算コストが高い可能がある：控えめに使用することができる。
【０１４２】
Ｂａｓｉｃ  ＳＵＰＬ  ＩＮＩＴ  Ｐｒｏｔｅｃｔｉｏｎパラメータ
・  Ｂａｓｉｃ  ＳＵＰＬ  ＩＮＩＴ  ＰｒｏｔｅｃｔｉｏｎのためのＳＵＰＬ  ＩＮＩＴプロテクタは、下記から成る。
【０１４３】
・  鍵識別子
・  ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ（長さ＝２オクテット）
・  ＢａｓｉｃＭＡＣ（長さ＝４オクテット）
・  ＢａｓｉｃＭＡＣパラメータは、以下のように生成される。
【０１４４】
・  ＢａｓｉｃＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ，‘ＳＵＰＬ_ＩＮＩＴ’）
・  ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｂａｓｉｃ  ＩＫ”
・  鍵識別子がリセットされるときにＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる。
【０１４５】
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ管理
・  あらゆるＳＵＰＬセッションの最初のＵＬＰやり取りにおいて生じる
・  第１のＳＥＴを発生元とするメッセージ
・  セッションの第１のメッセージは下記のいずれかを含むべきである。
【０１４６】
−    クレデンシャルが入手可能でない場合は、“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑ”インジケータ、又は
−    ＳＥＴ及びＳＬＰが同期外れであるかどうかをＳＬＰが検出するのを可能にするためのＣｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒ
・  ＳＬＰ応答
・  Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しい場合は、確認のための“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_ＯＫ”インジケータを加える。
【０１４７】
・  Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しくない場合、又は、ＳＥＴが“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑインジケータを送信した又はＳＬＰがＳＵＰＬ_ＩＮＩＴクレデンシャルを更新することを希望する場合は、ＳＬＰは、ＳＵＰＬ_ＩＮＩＴクレデンシャルをプロビジョニングするためにＵＬＰメッセージにフィールドを加える。
【０１４８】
−    （鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を含む。
【表３】
0005876063.tif 000004
【０１４９】
概要
・  ＳＵＰＬ３．０では２つの新しいセキュリティモデルが考慮される
・  選択肢Ｉ：ユーザモードＵＬＰ
・  選択肢ＩＩ：ユーザモードＴＬＳ
・  これらの２つの新しいセキュリティモードは、（ユーザ名、パスワード）クライアント認証を使用し、サーバ認証及び暗号化は、レガシーのサーバ認証ＴＬＳに基づく。
【０１５０】
・  両選択肢とも、全ベアラをサポートする（ｂｅａｒｅｒ  ａｇｎｏｓｔｉｃ）セキュリティモデルであり、このため、ＳＵＰＬ３．０に適する。
【０１５１】
・  該当する場合及び望ましい場合はレガシーセキュリティモデル（ＡＣＡ及びＧＢＡ）を依然として使用することができる。
【０１５２】
ＳＲＰ基本事項
・  ＴＬＳ−ＳＲＰ［ＩＥＴＦ  ＲＦＣ  ５０５４］は、セキュアリモートパスワード（ＳＲＰ［ＲＦＣ２９４５］を認証及び鍵やり取りの基礎として使用する。
【０１５３】
・  主ステップ
・  認証を行うサーバは、パスワードは不要であり、その代わりに、｛Ｕｓｅｒｎａｍｅ，ＰａｓｓｗｏｒｄＶｅｒｉｆｉｅｒ，Ｓａｌｔ｝を含むトリプレットを格納する。
【０１５４】
・  典型的には、ユーザのクライアントは、オフラインでサーバに登録時にトリプレットを生成する。
【０１５５】
・  Ｓａｌｔは、ユーザがランダムに選択することができる。
【０１５６】
・  ＰａｓｓｗｏｒｄＶｅｒｉｆｉｅｒは、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵やり取りと同様の複雑な数学を用いてＵｓｅｒｎａｍｅ、Ｓａｌｔ及びユーザのパスワードから計算される。
【０１５７】
・  サーバは、下記のためにユーザと対話してトリプレットを使用する
・  ユーザがパスワードを知っていることを検証する
・  ユーザ及びサーバのみによって知られる共有される秘密を確立する。この共有される秘密は、暗号化及び完全性保護のための鍵を生成するために使用することができる（ＴＬＳ−ＳＲＰでどのように使用されるか）。
【０１５８】
ＳＲＰの幾つかの特性
・  トリプレットは、ユーザになりすますために使用することができない
・  サーバがトリプレットを守秘する必要がない
・  サーバは、第三者がユーザになりすますことを試みるということを懸念せずに、第三者がユーザを検証するのを可能にするために第三者にトリプレットを提供することができる。
【０１５９】
−  例えば、Ｈ−ＳＬＰは、Ａ−ＳＬＰがユーザを認証するのを可能にするためにＡ−ＳＬＰにトリプレットを提供することができる。
【０１６０】
追加の実施形態４
序論
・  ＳＵＰＬ２．０におけるセキュリティは、アクセスネットワーク専用である。
【０１６１】
・  ＡＣＡは、ソースＩＰアドレスに基づいてＳＥＴを識別するためのコアネットワークへのアクセスを要求する
・  ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・  ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・  ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
【０１６２】
・  ＧＢＡ及び“ユーザ名／パスワード”認証の両方をサポートする単純な枠組
【表４】
0005876063.tif 000005
【表５】
0005876063.tif 000006
【０１６３】
以下の説明では、両方の選択肢を対象にし、各手法の利点及び潜在的な欠点について論じる。
【０１６４】
ユーザモードオフライン手順
・  ユーザモードＵＬＰ（オフライン）
・  ユーザ及びＳＬＰオペレータが（ユーザ名、パスワード）を取り決める
・  その他の前提事項
・  ＳＥＴがＳＬＰのＵＲＬを有する
・  ＳＥＴがＳＬＰを認証するための該当するルート証明書を有する
ユーザモードＵＬＰ：概念概要Ｉ
・  ユーザモードＵＬＰ：（ユーザ名、パスワード）に基づく
・  最初にサーバ証明書によるＴＬＳハンドシェイクを実施してセキュアなコネクションを確立する
・  ＳＥＴによって送信された全ＵＬＰメッセージに（ユーザ名、カウンタ、ダイジェスト）が加えられ、ダイジェストは以下のように計算される
−        ＵＬＰ_Ｍｅｓｓａｇｅ_Ｚは、ダイジェストフィールドがゼロに設定されたＵＬＰ_Ｍｅｓｓａｇｅである
−        Ｕｓｅｒ_ＵＬＰ_ＩＫ＝ＳＨＡ−２５６（Ｕｓｅｒｎａｍｅ||“：”||Ｐａｓｓｗｏｒｄ||“：”||ＳＬＰ_Ｄｏｍａｉｎ||“：ＳＵＰＬ３０ＵＬＰ”）
−        Ｄｉｇｅｓｔ＝ＨＭＡＣ−ＳＨＡ−２５６−３２（Ｕｓｅｒ_ＵＬＰ_ＩＫ，ＵＬＰ_Ｍｅｓｓａｇｅ_Ｚ）
・  ＳＥＴが（ユーザ名、カウンタ、ダイジェスト）を全メッセージに加え、ＳＬＰが検証する
ユーザモードＵＬＰ：概念概要ＩＩ
・  サーバ認証及び暗号化のために用いられるサーバ証明書によるＴＬＳ
・  ＳＥＴからのＵＬＰメッセージに新しいパラメータが加えられる：（ユーザ名、カウンタ、ダイジェスト）
・  ＳＬＰが、ＵＬＰメッセージ内容を処理する前にカウンタ及びダイジェストを検証する
・  カウンタの目的は、リプレイ検出を可能にすることである
・  すべてのＵＬＰセッションに関して受信元及び送信元においてカウンタがリセットされる
・  送信元において、メッセージごとにカウンタが増分され、ＵＬＰメッセージに加えられる
・  受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す
ユーザモードＴＬＳ：概念概要
・  ユーザモードＴＬＳ：（ユーザ名、パスワード）に基づく
・  最初にサーバ証明書によるＴＬＳハンドシェイクを実施してセキュアなコネクションを確立する。
【０１６５】
・  ＳＬＰが、ＴＬＳ再交渉を開始するために“Ｈｅｌｌｏ  Ｒｅｑｕｅｓｔ”を送信する。次に、ＳＥＴ及びＳＬＰは、（ユーザ名、パスワード）を用いてユーザを認証するためにＴＬＳ−ＳＲＰハンドシェイク（ＳＲＰ＝セキュアリモートパスワード）を実施する。
【０１６６】
・  ＴＬＳ−ＳＲＰハンドシェイクにおいてユーザ名を隠すために最初のセキュアなコネクションが要求される。
【０１６７】
選択肢Ｉ：オフライン手順概要
・  ＳＥＴがＴＬＳハンドシェイクを開始し、ＴＬＳにおいて、該当する暗号スィートを選択することによってＧＢＡ及び／又はユーザモードのためのサポートを示す。
【０１６８】
・  ＳＬＰがＧＢＡモード又はユーザモードを進めるべきかどうかを決定する
・  ＧＢＡモードの場合
・  セキュアなトンネルを確立するためにＧＢＡを用いてＴＬＳ−ＰＳＫの場合と同じようにＴＬＳハンドシェイクを継続する
−  相互認証を提供する
・  セキュアなチャネルでデータをやり取りする
・  ユーザモードの場合
・セキュアなチャネルを確立するためにサーバ証明書によるＴＬＳハンドシェイクを継続する
−  ＳＥＴがＳＬＰを認証する
・  セキュアなチャネルでデータをやり取りする
−  ＳＬＰがユーザを認証するのを可能にする新しいパラメータがＳＥＴからのＵＬＰメッセージに加えられる（ユーザ名、カウンタ、ダイジェスト）
選択肢Ｉ：オンライン手順詳細−ＴＬＳハンドシェイク
・  ＳＥＴ→ＳＬＰ：  Ｃｌｉｅｎｔ  Ｈｅｌｌｏ：
・  すべてのサポートされた暗号スイートを示す
−  ＳＥＴがＧＢＡをサポートする場合は、ＴＬＳ−ＰＳＫ暗号スイートのためのサポートを示す
−  ＳＥＴがユーザモードをサポートする場合は、サーバ証明書を用いるＴＬＳのためのサポートを示す
・  ＳＬＰ→ＳＥＴ：Ｓｅｒｖｅｒ  Ｈｅｌｌｏ
・  選択された暗号スイートを示す
−  ＳＬＰがＧＢＡモードを選択する場合は、ＳＬＰは、ＴＬＳ−ＰＳＫ暗号スイートを示す
−  ＳＬＰがユーザモードを選択する場合は、ＳＬＰは、サーバ証明書を用いるＴＬＳのための暗号スイートを示す
・  呼の流れは、選択された暗号スイートに関する場合と同じように進む
選択肢Ｉ：オンライン手順詳細−ＴＬＳハンドシェイク後
・ＧＢＡモード
・  ＳＥＴ及びＳＬＰがセキュアなチャネルを通じて通信を開始する
・ユーザモード
・  ＳＥＴ及びＳＬＰがセキュアなチャネルを通じて通信を開始する
・  ＳＥＴからのＵＬＰメッセージに新しいパラメータが加えられる：（ユーザ名、カウンタ、ダイジェスト）
−  ＳＬＰが、ＵＬＰメッセージ内容を処理する前にカウンタ及びダイジェストを検証する
−  カウンタの目的は、リプレイ検出を可能にすることである
−  すべてのＵＬＰセッションに関して受信元及び送信元においてカウンタがリセットされる
−  送信元において、メッセージごとにカウンタが増分され、ＵＬＰメッセージに加えられる
−  受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ検出を渡す
選択肢ＩＩ：オンライン手順概要
・  ＳＥＴがＴＬＳハンドシェイクを開始し、該当する暗号スイートを選択することによってＧＢＡ及び／又はユーザモードのためのサポートをＴＬＳにおいて示す。
【０１６９】
・  ＳＬＰがＧＢＡモード又はユーザモードを進めるべきかどうかを決定する
・  ＧＢＡモードの場合
１．セキュアなトンネルを確立するためにＧＢＡを用いてＴＬＳ−ＰＳＫの場合と同じようにＴＬＳハンドシェイクを継続する
−相互認証
２．セキュアなチャネルでデータをやり取りする
・  ユーザモードの場合
１．最初に、セキュアなチャネルを確立するためにサーバ証明書によるＴＬＳハンドシェイクを継続する
−ＳＥＴがＳＬＰを認証する
２．ＴＬＳ−ＳＲＰハンドシェイクを実施する（メッセージは、セキュアなチャネル内部でやり取りされる）
−ＳＬＰがユーザを認証する
−新しいセッション鍵が得られる
３．新しいセッション鍵によって保護されたセキュアなトンネルでデータをやり取りする
選択肢ＩＩ：オンライン手順−最初のＴＬＳハンドシェイク
ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ  Ｈｅｌｌｏ：
・  すべてのサポートされる暗号スイートを示す
−  ＳＥＴがＧＢＡをサポートする場合は、ＴＬＳ−ＰＳＫ暗号スイートのためのサポートを示す
−  ＳＥＴがユーザモードをサポートする場合は、サーバ証明書及びＴＬＳ  ＳＲＰを用いるＴＬＳのためのサポートを示す
・  ＳＥＴはこの時点ではユーザ名を提供せず、要求される場合は、次のＴＬＳハンドシェイクで提供される。
・  ＳＬＰ→ＳＥＴ：Ｓｅｒｖｅｒ  Ｈｅｌｌｏ：
・  選択された暗号スイートを示す
−  ＳＬＰがＧＢＡモードを選択する場合は、ＳＬＰは、ＴＬＳ−ＰＳＫ暗号スイートを示す
−  ＳＬＰがユーザモードを選択する場合は、ＳＬＰは、サーバ証明書を用いるＴＬＳのための暗号スイートを示す
−  呼の流れが選択された暗号スイートの場合と同じように進む
選択肢ＩＩ：オンライン手順詳細−最初のＴＬＳハンドシェイク後
・  ＧＢＡモード
・  ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルを通じての通信を開始する
・  ユーザモード
・  ＳＬＰ→ＳＥＴ：Ｈｅｌｌｏ  Ｒｅｑｅｕｓｔ
−  再交渉を開始する
・  ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ  Ｈｅｌｌｏ
−  ＴＬＳ−ＳＲＰのためのサポートを示す
−  ＴＬＳ−ＳＲＰ仕様に準拠してユーザ名を含める
・  ＳＥＴ→ＳＬＰ：ＳｅｒｖｅｒＨｅｌｌｏ
−  ＴＬＳ−ＳＲＰの選択を示す
−  ＴＬＳ−ＳＲＰに準拠してやり取りを継続する
・  成功裏のハンドシェイクに後続して、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでデータをやり取りすることを開始する
ＳＵＰＬ  ＩＮＩＴ保護
・  ＳＵＰＬ３．０におけるＳＵＰＬ  ＩＮＩＴ保護は、ＳＵＰＬ２．０におけるＳＵＰＬ  ＩＮＩＴ保護メカニズムに基づき、ＳＵＰＬ  ＩＮＩＴに添付されたメッセージ認証コード（ＭＡＣ）を使用する。
【０１７０】
・  ２つの認証法
○  ＧＢＡモード（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ，  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）＝（Ｂ−ＴＩＤ，Ｋｓ）
◆  （Ｂ−ＴＩＤ，Ｋｓ）がＢＳＦとのブートストラップから外される
○  ユーザモード：認証が（ユーザ名、パスワード）を使用する
・  ＳＵＰＬ  ＩＮＩＴ保護は、選択肢Ｉ及び選択肢ＩＩに関して同じである
ＳＵＰＬ  ＩＮＩＴ保護メカニズム
・  ＳＵＰＬｖ３．０において次の３つのタイプの保護が提供される
・  ＮＵＬＬ
−      セキュリティなし
・  ＧＢＡモード保護
−      ＳＵＰＬｖ２．０基本保護と同一である
・  ユーザモード保護
−      （ユーザ名、パスワード）に基づく認証
−      辞書攻撃を防止するためにランダム値を加える
−      リプレイを防止するために時間を加える
ＳＵＰＬ  ＩＮＩＴ  ＧＢＡモード保護
・  ＧＢＡ認証を使用する場合は、ＳＵＰＬ  ＩＮＩＴプロテクタパラメータは、下記から成る。
【０１７１】
・  鍵識別子＝ＧＢＡ  Ｂ−ＴＩＤ（長さ＝可変）
・  ＧＢＡ_ＲｅｐｌａｙＣｏｎｔｅｒ（長さ＝２オクテット）。リプレイを防止する
・  ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＭＡＣ（長さ＝４オクテット）。メッセージを認証する。
【０１７２】
・  ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＭＡＣパラメータは、次のように生成される。
【０１７３】
・  ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ_Ｚ）
・  ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“ＧＢＡ  ＩＫ”
・ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、Ｂ−ＴＩＤに対応するＧＢＡ  ｋｅｙ  Ｋｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦである
・  ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ  ＩＮＩＴメッセージである。
【０１７４】
・鍵識別子がリセットされたときにＧＢＡ_ＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる
ＳＵＰＬ  ＩＮＩＴユーザモード保護
・  ユーザモードセキュリティを使用する場合は、ＳＵＰＬ  ＩＮＩＴ  Ｐｒｏｔｅｃｔｏｒパラメータは、下記から成る。
【０１７５】
・  ＳＵＰＬ_ＩＮＩＴ_ＲＡＮＤ（長さ＝８オクテット）。これは、パスワードに対する辞書攻撃を防止するためにこのメッセージにとって一意のランダムな値であることができる。
【０１７６】
・  ＳＵＰＬ_ＩＮＩＴ_ＴＩＭＥ（長さ＝４オクテット）。メッセージ送信時間。リプレイを停止させる。
【０１７７】
・  ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣ（長さ＝４オクテット）。メッセージを認証する。
【０１７８】
・  ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣはパラメータ次のように生成される。
【０１７９】
・  ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ_Ｚ）
・  ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＩＫ＝ＳＨＡ−２５６（Ｕｓｅｒｎａｍｅ
||“：”||Ｐａｓｓｗｏｒｄ“：”||ＳＬＰ_Ｄｏｍａｉｎ||“：ＳＵＰＬ３０ＩＮＩＴ”）
・  ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ  ＩＮＩＴメッセージである。
【表６】
0005876063.tif 000007
【０１８０】
概要
・  ＳＵＰＬ３．０では２つの新しいセキュリティモデルが考慮される。
【０１８１】
・  選択肢Ｉ：ユーザモードＵＬＰ
・  選択肢ＩＩ：ユーザモードＴＬＳ
・  これらの２つの新しいセキュリティモードは、（ユーザ名、パスワード）クライアント認証を使用し、サーバ認証及び暗号化は、レガシーのサーバ認証ＴＬＳに基づく。
【０１８２】
・  両選択肢とも、全ベアラをサポートする（ｂｅａｒｅｒ  ａｇｎｏｓｔｉｃ）セキュリティモデルであり、このため、ＳＵＰＬ３．０に適する。
【０１８３】
・  該当する場合及び望ましい場合はレガシーセキュリティモデル（ＡＣＡ及びＧＢＡ）を依然として使用することができる。
【０１８４】
追加の実施形態５
序論
・  ＯＭＡ  ＳＵＰＬ２．０におけるセキュリティは、アクセスネットワーク専用である。
【０１８５】
・  ＡＣＡ（代替クライアント認証）は、ソースＩＰアドレスに基づいてＳＥＴを識別するためのコアネットワークへのアクセスを要求する
・  ＧＢＡ（汎用ブートストラッピングアーキテクチャ）は、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・  ＳＥＫ（ＳＵＰＬ暗号化鍵）は、ＷｉＭＡＸネットワークのみに適用可能
・  ＯＭＡ  ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
【０１８６】
・  “ユーザ名／パスワード”認証に基づく単純な枠組
・  レガシーのＡＣＡ及びＧＢＡに基づくセキュリティもサポートされる
【表７】
0005876063.tif 000008
【０１８７】
ＳＵＰＬ３．０セキュリティ概念概要ＩＩ
・  ＡＣＡ及びＧＢＡは、アクセスネットワーク専用であるが、該当する場合及びＳＵＰＬオペレータの選択に依存して使用することができる。
【０１８８】
・  ユーザモードＴＬＳは、アクセスネットワークから独立しており、ＡＣＡの拡張とみなすことができる。
【０１８９】
ユーザモードＴＬＳ−概要Ｉ
・  公開鍵ＴＬＳサーバ認証−Ｈ−ＳＬＰ及びＳＬＰは、セキュアな状態で接続され、Ｈ−ＳＬＴは認証されるがＳＥＴは認証されない。
【０１９０】
・  ユーザ名／パスワードＴＬＳ−ＳＲＰクライアント認証−Ｈ−ＳＬＰ及びＳＬＰは、セキュアな状態で接続され、Ｈ−ＳＬＴ及びＳＥＴの両方が認証される。
【０１９１】
・  ユーザモードＴＬＳ
・  最初に、セキュアな暗号化されたＩＰ接続を生成するＡＣＡの場合と同じように公開鍵ＴＬＳを用いてサーバが認証される
・  次に、ＳＥＴ及びＳＬＰの両方において予めプロビジョニングされたユーザ名／パスワードを用いてＴＬＳ−ＳＲＰ（セキュアリモートパスワード）に基づいてクライアントが認証される
ユーザモードＴＬＳ概要ＩＩ
・  単純なユーザ名／パスワードメカニズムは、問題及び／又は脅威を引き起こすおそれがある。
【０１９２】
・  ユーザ名／パスワードが盗まれて異なるデバイスで使用されるおそれがある
・  ユーザ名／パスワードが自由意志で明かされて異なるデバイスで同時に使用されるおそれがある
・  これは以下によって解決することができる。
【０１９３】
・  ユーザ名／パスワードは、ＳＵＰＬサービス起動直後の最初のＳＵＰＬセッションのみに関して使用する
・  最初のＳＵＰＬセッション中に、ＳＬＰが、新しいユーザ名／パスワードを生成して（最初のユーザ名／パスワードによって生成されたセキュアなＩＰ接続を用いて）ＳＥＴに送信する
・  次に、ＳＥＴが最初のユーザ名／パスワードを新しいユーザ名／パスワードに取り代え、旧ユーザ名／パスワードを削除する
・  次に、ＳＬＰによって生成されたユーザが見ることができないユーザ名／パスワードによってデバイスがＳＵＰＬサブスクリプション（subscription）にバインドされる。
【０１９４】
・  これで、すべての将来のセッションが、ＳＬＰによって生成された新しいユーザ名／パスワードを使用する。
【０１９５】
・  その他のデバイスは、このユーザ名／パスワードは使用できない。
【０１９６】
４つのステップによるユーザモードＴＬＳ
・ステップ１：ユーザ及びＳＬＰオペレータが一時的なユーザ名及びパスワードを取り決める：
（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）
・ステップ２：最初のＳＵＰＬセッションが確立される。サーバによって認証されたＴＬＳに基づいてサーバ認証及び暗号化が行われる。取り決められた（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）を用いてＴＬＳ−ＳＲＰ（ＳＲＰ＝セキュアリモートパスワード）に基づいてクライアント認証が行われる。
【０１９７】
・ステップ３：最初のＳＵＰＬセッション内で、ＳＬＰが、ＳＥＴに送信する新しい暗号法的に強力な（ユーザ名、パスワード）を生成し、（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）を（ユーザ名、パスワード）に代える。ＳＥＴは、（ユーザ名、パスワード）をセキュアな場所に格納する。
【０１９８】
・ステップ４：すべての後続するＴＬＳセッションが、サーバによって認証されたＴＬＳに基づいてサーバ認証及び暗号化を使用する。クライアント認証は、（ユーザ名、パスワード）を用いてＴＬＳ−ＳＲＰに基づいて行われる。
【０１９９】
ユーザモードＴＬＳステップ１−詳細
・  ユーザ及びＳＬＰオペレータが一時的なユーザ名及びパスワードを取り決める：
（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）
・  （Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）は、様々な方法でＳＥＴにおいてプロビジョニングすることができる。
【０２００】
・  オペレータによるオーバーザエアでのプロビジョニング
・  オペレータのストアでプロビジョニング（ＳＥＴのフラッシング）
・  ユーザ名及びパスワードを郵送するかオンラインで入手し、ＳＥＴユーザが入力する
・  その他
・  ＳＥＴにはＳＬＰのＵＲＬがプロビジョニングされている
・  ＳＥＴには、ＳＬＰを認証するために要求される該当するルート証明書がプロビジョニングされている
ユーザモードＴＬＳステップ２−詳細
・  サーバの認証及び暗号化を開始するための最初のＳＵＰＬセッションの最初のＴＬＳハンドシェイク
・  ＳＥＴ→ＳＬＰ：サーバ証明書及びＴＬＳ−ＳＲＰによるＴＬＳのためのサポートを示すＣｌｉｅｎｔ  Ｈｅｌｌｏ
・  ＳＬＰ→ＳＥＴ：サーバ証明書によるＴＬＳのための暗号スイートを示すＳｅｒｖｅｒ  Ｈｅｌｌｏ
・  クライアント認証を開始するための２回目のＴＬＳハンドシェイク
・  ＳＬＰ→ＳＥＴ：再交渉を開始するためのＨｅｌｌｏ要求
・  ＳＥＴ→ＳＬＰ：ＴＬＳ−ＳＲＰのためのサポートを示し、ＴＬＳ−ＳＲＰ仕様に準拠したＵｓｅｒｎａｍｅ_ｔｅｍｐを含むＣｌｉｅｎｔ  Ｈｅｌｌｏ
・  ＳＬＰ→ＳＥＴ：ＴＬＳ−ＳＲＰの選択を示すＳｅｒｖｅｒ  Ｈｅｌｌｏ
・  クライアント認証は、（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）に基づいて行われる。
【０２０１】
・  新しいセッション鍵が生成される（このセッション専用）
・  これで、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでＳＵＰＬセッションを実施することができる。
【０２０２】
ユーザモードＴＬＳステップ３−詳細
・  ＳＬＰが一時的なユーザ名及びパスワード（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）に基づいて暗号的に強力な（ユーザ名、パスワード）を生成する。
【０２０３】
・  最初に、ＳＬＰからＳＥＴへのＳＵＰＬメッセージが暗号的に強力な（ユーザ名、パスワード）を搬送する。
【０２０４】
・  ＳＥＴが一時的な（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）を（ユーザ名、パスワード）に代える。
【０２０５】
・  ＳＥＴが一時的な（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）を廃棄する。
【０２０６】
・  ＳＥＴが（ユーザ名、パスワード）をセキュアな場所に格納する。
【０２０７】
・  注１：このステップは、ＳＬＰオペレータがユーザを関与させることなしにＳＥＴにおいてセキュアな状態でユーザ名／パスワードをプロビジョニングすることができた場合に実施することができる
・  注２：３ＧＰＰ／３ＧＰＰ２における最初のアクセスに関しては、ＳＬＰは、ＳＥＴ  ＩＰアドレスがＳＥＴ  ＭＳＩＳＤＮ又はＩＭＳＩと関連付けられていることをコアネットワーク内で検証し、ＳＥＴがユーザに属することをさらに検証することができる
ユーザモードＴＬＳステップ４−詳細
・  後続するＴＬＳセッションの確立に関して：
・  サーバの認証及び暗号化を開始するためのＴＬＳハンドシェイク：
−  ＳＥＴ→ＳＬＰ：サーバ証明書及びＴＬＳ−ＳＲＰによるＴＬＳのためのサポートを示すＣｌｉｅｎｔ  Ｈｅｌｌｏ
−  ＳＬＰ→ＳＥＴ：サーバ証明書によるＴＬＳのための暗号スイートを示すＳｅｒｖｅｒ  Ｈｅｌｌｏ
・  クライアント認証を開始するための第２のＴＬＳハンドシェイク：
−  ＳＬＰ→ＳＥＴ：再交渉を開始するためのＨｅｌｌｏ  Ｒｅｑｕｅｓｔ
−  ＳＥＴ→ＳＬＰ：ＴＬＳ−ＳＲＰのためのサポートを示すＣｌｉｅｎｔ  Ｈｅｌｌｏ及びＴＬＳ−ＳＲＰ仕様に準拠したユーザ名を含む
−  ＳＬＰ→ＳＥＴ：ＴＬＳ−ＳＲＰの選択を示すＳｅｒｖｅｒ  Ｈｅｌｌｏ
−  クライアント認証が（ユーザ名、パスワード）に基づいて行われる
−  新しいセッション鍵が生成される
・  これで、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでＳＵＰＬセッションを実施することができる。
【０２０８】
・  注：ＰＳＫ−ＴＬＳは、暗号的にセキュアなユーザ名／パスワードが提供された時点で後続するアクセスのために使用可能であるが、ＴＬＳ−ＳＲＰの再使用の方が低い複雑度で実装することができる。
【０２０９】
ＳＵＰＬ  ＩＮＩＴ保護概要
・  ＳＵＰＬ３．０におけるＳＵＰＬ  ＩＮＩＴ保護は、ＳＵＰＬ２．０におけるＳＵＰＬ  ＩＮＩＴ保護メカニズムに基づき、ＳＵＰＬ  ＩＮＩＴに添付されたメッセージ認証コード（ＭＡＣ）を使用する
・  ＳＵＰＬ  ｖ３．０では次の２つのタイプの保護が提供される：
・  ＧＢＡモード保護
−        ＳＵＰＬ  ｖ２．０の基本的保護と同一
・  ユーザモード保護
−        ＳＬＰによって生成された（ユーザ名、パスワード）に基づく認証（すなわち、サービスの起動に使用された最初のユーザ名／パスワード（Ｕｓ  ｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）は使用しない）。
【０２１０】
・ＮＵＬＬ保護もサポートされており、オペレータの選択に基づいて使用することができる。
【０２１１】
ＳＵＰＬ  ＩＮＩＴユーザモード保護Ｉ
・ユーザモードＴＬＳセキュリティを使用する場合は、ＳＵＰＬ  ＩＮＩＴ  Ｐｒｏｔｅｃｔｏｒパラメータは、下記から成る。
【０２１２】
・  ＳＵＰＬ_ＩＮＩＴ_ＴＩＭＥ（長さ＝４オクテット）。メッセージ送信時間。リプレイを停止させる。
【０２１３】
・  ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣ（長さ＝４オクテット）。メッセージを認証する。
【０２１４】
・  ＳＵＰＬ  ＩＮＩＴプロテクタは、各ＳＵＰＬ  ＩＮＩＴに加えられ、ＳＥＴが受信されたＳＵＰＬ  ＩＮＩＴメッセージの真正性を検査するのを可能にする。
【０２１５】
・  オペレータがＳＵＰＬ  ＩＮＩＴ保護を使用する例外的ケース（例えば、ＳＥＴ及びＳＬＰが同期外れ）では、サービス拒否攻撃が保護されていないＳＵＰＬ  ＩＮＩＴを多数のＳＥＴに送信することによってつけ込むことができないように（例えば、リセットコマンドを介して）ＳＥＴに明示されている限りにおいてＳＥＴを再プロビジョニングするためにヌルＳＵＰＬ  ＩＮＩＴ保護を一時的に使用することができる。
【０２１６】
ＳＵＰＬ  ＩＮＩＴユーザモード保護ＩＩ
・  ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣパラメータは次のように生成される。
【０２１７】
・  ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ_Ｚ）
・  ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＩＫ＝ＳＨＡ−２５６（Ｕｓｅｒｎａｍｅ||“：”||Ｐａｓｓｗｏｒｄ||“：”||ＳＬＰ_Ｄｏｍａｉｎ||“：ＳＵＰＬ３０ＩＮＩＴ”）
・  ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ  ＩＮＩＴメッセージである。
【０２１８】
概要
・  ＳＵＰＬ３．０に関して新しいセキュリティモデルが説明される：ユーザモードＴＬＳ。
【０２１９】
・  ユーザモードＴＬＳは、（ユーザ名、パスワード）クライアント認証を使用し、他方、サーバ認証及び暗号化は、レガシーのサーバによって認証されたＴＬＳに基づく。
【０２２０】
・  ＳＵＰＬ  ＩＮＩＴ保護は、ユーザモードＴＬＳでもサポートされる。
【０２２１】
・  ユーザモードＴＬＳは、全ベアラをサポートするセキュリティモデルであり、このため、ＳＵＰＬ３．０に適する。
【０２２２】
・  ＳＵＰＬオペレータの選択に依存してレガシーセキュリティ
モデル（ＡＣＡ及びＧＢＡ）を依然として使用することができる。
【０２２３】
推奨
・  ユーザモードＴＬＳは、ＳＵＰＬ３．０のためのセキュリティモデルとして採用することができる。
【０２２４】
・  レガシーのＡＣＡ及びＧＢＡセキュリティモデルに関してサポートを維持することができる。
【０２２５】
ＳＵＰＬ３．０アクセスＳＬＰ（Ａ−ＳＬＰ）
・  ローミング中の加入者の場合は、精密な測位のサポートは、Ｈ−ＳＬＰプロバイダにとっては困難であるが、ローカルなローミングエリアの位置決定プロバイダにとってははるかに簡単である。
【０２２６】
・  オペレータは、オペレータＢの加入者にとって有益な形でオペレータＡに属するＨ−ＳＬＰを一時的に利用することが可能なその他のオペレータ及びプロバイダと取引関係にある場合がある。
【０２２７】
・  ＳＵＰＬ３．０ＲＤは、ＳＬＰのより広範な利用可能性及びＳＬＰへのより容易なアクセスに関する要件を含む。
【０２２８】
・  ＳＵＰＬ−ＥＭＥＲ−０３：ＳＵＰＬは、緊急な位置決定要求のためのＳＥＴによって開始される及びネットワークによって開始される測位をサポートするものとする
・  ＳＵＰＬ−ＨＬＦ−１８：ＳＵＰＬは、ＳＬＰサービス発見をサポートするものとする
・  Ｈ−ＳＬＰを有していない加入者が存在することもある−例えば、ホームオペレータがＳＵＰＬをサポートしていない−又は任意でＨ−ＳＬＰ  ＳＵＰＬサポートを使用していないことがある
・  ＳＵＰＬサポートをローミング中の加入者に拡張することを希望するオペレータが存在することがある−例えば、Ｈ−ＳＬＰを有さないそれら又はＨ−ＳＬＰが特定のローミングエリア内の位置を適切にサポートできないそれら
アクセスＳＬＰ（Ａ−ＳＬＰ）
・  Ａ−ＳＬＰは、アクセスネットワークプロバイダに属すること、アクセスネットワークと関連付けること又はアクセスネットワークの地理的エリアをサポートすることができる
・  Ａ−ＳＬＰは、Ｈ−ＳＬＰとほぼ同一の方法でＳＵＰＬ３．０をサポートすることができ、例えば、すべてのネットワークサービスとＳＥＴによって開始されるサービスとを含む
・  ＳＥＴは、Ａ−ＳＬＰを発見すること又はＡ−ＳＬＰに関する情報（例えば、Ａ−ＳＬＰアドレス及びセキュリティパラメータ）が提供されることが必要になる
・  可能な情報源は、アクセスネットワーク、Ｈ−ＳＬＰ、及び独立した（非標準化された）発見である
・  Ａ−ＳＬＰセキュリティは、Ｈ−ＳＬＰに関して定義される方法を再使用する−例えば、異なる認証方法は回避するべきである
・  ＳＥＴ及びＡ−ＳＬＰは、外部のＳＵＰＬエージェント及びＳＥＴの両方のためのＳＵＰＬ３．０サービスをサポートするために限定された予め取り決められた期間だけ対話することができる
可能なＡ−ＳＬＰ使用法
・  ＳＥＴは、アクセスネットワークを介してＵＬＰ３．０メッセージを用いてＳＬＰと通信し及び（Ａ−ＳＬＰを発見及び検証するために任意選択で使用される）ホームネットワークを介してＵＬＰ３．０メッセージを用いてＨ−ＳＬＰと通信する。
【０２２９】
・  Ａ−ＳＬＰは、ＭＬＰを介してＳＵＰＬエージェントと通信する。
【０２３０】
ユーザ事例
・  例１−ユーザが新しい都市、町、観光地、等を訪れる
・  Ｈ−ＳＬＰは、絶対位置しかサポートすることができず、さらに常に正確であるわけではなく（例えば、建物内の場合）、及び、補助情報、例えば、対象地点、地図、天候／交通情報、等、を提供できないことがある。
【０２３１】
・  Ａ−ＳＬＰは、アプリケーションレベルのサービス（ＳＵＰＬの一部でない）、例えば、方向の発見、対象地点、地図、天候／交通、等とともにより連続的な正確な位置サポートを提供することが可能である。
【０２３２】
・  例２−緊急呼サポート
・  Ａ−ＳＬＰがＥ−ＳＬＰ能力もサポートする場合は、ＳＥＴによるＡ−ＳＬＰの発見がのちのＩＰに基づく緊急呼に役立つことができる。
【０２３３】
・  ＳＥＴは、Ａ−ＳＬＰからおおよその位置を入手してそれを緊急ＳＩＰ  ＩＮＶＩＴＥ内に含め、それによって呼のルーティングを援助するという選択肢を有する。
【０２３４】
・  ＳＥＴとＡ−ＳＬＰ／Ｅ−ＳＬＰとの間での事前の関連付けも、ＰＳＡＰディスパッチのためののちのより正確な位置決定に役立つことができる。
【０２３５】
Ａ−ＳＬＰセキュリティ−１
・  Ｈ−ＳＬＰの場合と同じセキュリティ手順が可能である
・  １つの適切なセキュリティ方法は、ＯＭＡ−ＬＯＣ−２０１０−０ｘｙｚ−ＩＮＰ_ＳＵＰＬ_３．０_Ｓｅｃｕｒｉｔｙにおいて説明されるユーザモードＴＬＳである−例えば、これは、ＧＢＡのサポート、３ＧＰＰ／３ＧＰＰ２専用アクセス、ＳＥＴを直接構成する能力を要求しない
・  Ａ−ＳＬＰオペレータ又はＨ−ＳＬＰオペレータ（両オペレータ間に取引関係が存在する場合）は、最初のユーザ名／パスワードを割り当てることができる。
【０２３６】
・  Ａ−ＳＬＰは、その他のデバイスによる最初のユーザ名／パスワードの使用を回避するために最初のＳＵＰＬセッションでそのユーザ名／パスワードを新しい値に代えることができる。
【０２３７】
・  Ａ−ＳＬＰオペレータは、ユーザ名／パスワードをプロビジョニングされたＳＥＴが意図されるユーザに属することを常に検証することができるわけではないが、これは、ＳＥＴによって開始されたサービスに主に焦点を合わせ及びすべてのローミングユーザに関して同じ料金が課金されるＡ−ＳＬＰサービスにとっては重要ではない。
【０２３８】
・  注：ほとんどの場合は、ユーザは、Ａ−ＳＬＰへのアクセスの喪失をＡ−ＳＬＰプロバイダに報告し（例えば、最初のユーザ名／パスワードが他のユーザによって入手されて使用される場合）、現在のユーザ／パスワードを無効にして新しいユーザ名／パスワードに代えることを可能にすることができる。
【０２３９】
Ａ−ＳＬＰセキュリティ−２
・  １つの任意選択肢として、Ｈ−ＳＬＰは、Ａ−ＳＬＰを発見するために、検証するために及びＡ−ＳＬＰのためのセキュリティのサポートを援助するために使用することができる。
【０２４０】
・  ＳＥＴは、これらのパラメータのうちの１つを用いてＨ−ＳＬＰにＵＬＰ要求を送信することができる。
【０２４１】
・  （Ａ）現在のＳＥＴ位置又はサービスを提供するアクセスネットワークのアイデンティティ
・  （Ｂ）既に発見済みのＡ−ＳＬＰアドレス（例えば、オンラインで見つけられるか又はアクセスネットワークによって提供）
・  （Ａ）に関しては、Ｈ−ＳＬＰは、ローカルエリアにサービスを提供する信用されるＡ−ＳＬＰのアドレスを返信することができる。
【０２４２】
・  （Ｂ）に関しては、Ｈ−ＳＬＰは、Ａ−ＳＬＰが信用される、信用されないか又はＨ−ＳＬＰにとって未知であるかどうかを示すことができる。
【０２４３】
・  信用される事例における（Ａ）及び（Ｂ）に関しては、Ｈ−ＳＬＰは、Ａ−ＳＬＰ又はＨ−ＳＬＰのいずれかによって割り当てられた最初のユーザ名／パスワードを任意選択でＳＥＴに提供することができる（ユーザ名／パスワード及びユーザ識別を転送するためにＡ−ＳＬＰとＨ−ＳＬＰ又は関連付けられたプロバイダとの間での何らかの追加の対話が要求される）
ＳＵＬＰ３．０ＡＤ及びＴＳの影響
・  （既存のＨ−ＳＬＰ、Ｖ−ＳＬＰ、Ｅ−ＳＬＰとともに）Ａ−ＳＬＰを定義する
・  適切な発見メカニズムを定義又は参照する
・  ユーザモードＴＳＬセキュリティの使用を示す
・  Ａ−ＳＬＰの発見、検証及びセキュリティのための適切なＨ−ＳＬＰのサポートを加える
・  （各端部が新しいセッションのためにサポートするサービスを他方に知らせる既存のＳＵＰＬ３．０メッセージフローにおいて既にサポートされるように）ＳＥＴ及びＡ−ＳＬＰがサポートされるサービスをＨ−ＳＬＰ対話のために用いられるそれらの部分組に限定するのを可能にする
・  あらゆる新しいプライバシー要件（存在する場合）を識別及びサポートする
Ｈ−ＳＬＰサービスとの関係
・  Ｈ−ＳＬＰプロバイダは、何らかの取引関係が存在する幾つかのＡ−ＳＬＰプロバイダをサポートすることを選択することができる。
【０２４４】
・  Ｈ−ＳＬＰプロバイダは、その他のオペレータからのローミング加入者へのＡＳＬプロバイダとしてサポートを提供することもできる
・  ＳＥＴは、次のようにＡ−ＳＬＰアクセスを制御するように構成することが可能である。
【０２４５】
ａ）常にＨ−ＳＬＰを使用し、Ａ−ＳＬＰの使用を禁止する
ｂ）Ｈ−ＳＬＰを優先するがＨ−ＳＬＰによる承認を条件としてＡ−ＳＬＰの使用を許容する（例えば、Ｈ−ＳＬＰプロバイダとのローミング契約が存在するときのみにＡ−ＳＬＰアクセスを許容する）
ｃ）ＳＥＴがそれ自体の判定基準に基づいてＨ−ＳＬＰの使用又はＡ−ＳＬＰの使用を自由に決定するのを許容する
ｄ）常にＡ−ＳＬＰを使用する（例えば、Ｈ−ＳＬＰが存在しないときに該当する）
・  正味の結果として、ＳＵＰＬ３．０の使用法及び関連付けられた配備を向上させ、プロバイダ及びユーザにとって有益になることができる
・  Ａ−ＳＬＰサポートをＳＵＰＬ３．０の一部として含めることができる
・  Ｈ−ＳＬＰセキュリティサポートを再使用し及びＨ−ＳＬＰがＡ−ＳＬＰへのアクセスを援助又は制御するのを許容する
・  あるレベルの非ＳＵＰＬサポートを考慮する（例えば、Ａ−ＳＬＰの発見及びＡ−ＳＬＰプロバイダとＨ−ＳＬＰプロバイダとの間での対話に関して）
追加の実施形態６
序論
・  本実施形態は、クライアント認証のためにデバイス証明書を使用する。
【表８】
0005876063.tif 000009
【０２４６】
・  ＡＣＡ及びＧＢＡはアクセスネットワーク専用であるが、該当する場合及びＳＵＰＬオペレータの選択に依存して使用することができる。
【０２４７】
・  この実施形態の新しいセキュリティモデルは、デバイス証明書を用いたクライアント認証である。デバイス証明書に基づくクライアント認証は、アクセスネットワークから独立しており、従って、全タイプのアクセスネットワーク及びデバイスに関して使用することができる（すなわち、３ＧＰＰ／３ＧＰＰ２でないアクセスネットワーク及びデバイスがサポートされる）。
【０２４８】
デバイスの事前プロビジョニング
・  メーカーは、製造中に下記の項目をＳＥＴ内でプロビジョニングする。
【０２４９】
・  そのＳＥＴデバイスに一意の秘密鍵
・  対応する公開鍵を１つ以上のグローバルで一意のＳＥＴデバイスアイデンティティ（例えば、一連番号、ＩＭＥＩ又はＭＳＩＤ）にバインドさせる証明書
・  １つ以上の一連の証明書が潜在的なＳＬＰによって信用されることになるよく知られた証明書機関に戻される
・  注：ＳＬＰによって信用されたＣＡへ戻る一連の連鎖が存在しない場合は、ＳＬＰは、ＳＥＴ認証を信用しない。
・  ＳＬＰは、ＳＬＰの証明書を検証するために使用することができる１つ以上のルート証明書がＳＥＴにプロビジョニングされていることを確認する責任を有する
・  これらのルート証明書は、ＳＥＴの製造中又は配布中にプロビジョニングすることができる
・  これらのルート証明書は、ＳＵＰＬクライアントソフトウェアとバンドリングすることができる。
【０２５０】
・  注：ＳＬＰ証明書からこれらのルート証明書まで戻る一連の証明書が存在しない場合は、ＳＥＴは、ＳＬＰを認証することができない。
・  ＯＭＡ−ＬＯＣは、実装及び試験を簡略化及び統一するために共通のテンプレート又はプロフィールを規定することができる。
【０２５１】
デバイス証明書概要
・ステップ１：加入者認証（範囲外）
・  加入者が、このデバイスは加入と関連付けられるべきであることをセキュアな形でＳＬＰに検証する
・ステップ２：ランタイムＴＬＳハンドシェイク
・  最初に：サーバ証明書を用いてサーバによって認証されたＴＬＳハンドシェイクを行う
・  次に：暗号化されたＴＬＳトンネル内で、サーバ証明書及びクライアント証明書を用いて相互に認証されたＴＬＳハンドシェイクを行う。
【０２５２】
・  これで、セキュアな状態でデータをやり取りすることができる。
【０２５３】
（範囲外）（ｏｕｔ  ｏｆ  ｓｃｐｏｅ）加入者認証Ｉ
・  ＳＥＴのアイデンティティのみが認証され、加入者のアイデンティティは認証されないため、ＳＬＰは、いずれの加入者が（認証された）ＳＥＴと関連付けられるべきかを知っている。
【０２５４】
・  これは、加入者がＳＥＴ間で切り換わる回数だけ生じる。
【０２５５】
・  ユーザがＳＬＰにＳＥＴのアイデンティティを提供するだけでは十分でないことがある。
【０２５６】
・  理由：ユーザ１は、ユーザ２のＳＥＴ  ＩＤをＳＬＰに提供して“これは私のＳＥＴです”と言うことができる。ＳＬＰは、何が起きているかをユーザ２が承知しない状態でユーザ２の位置の詳細をユーザ１に提供することがある。
【０２５７】
・  セキュアな形で加入者をＳＥＴ  ＩＤと関連付けるためにセキュアな方法が使用される。
【０２５８】
・  方法が範囲外の状態にされる。
【０２５９】
・幾つかのシステムは、セキュアな形でデバイスアイデンティティを加入者（例えば、Ａｐｐｌｅ、Ｂｌａｃｋｂｅｒｒｙ）と関連付けるためのメカニズムを既に有する。
【０２６０】
・  方法例が以下において提供される。
【０２６１】
（範囲外）加入者認証ＩＩ
・  セキュアな形で加入者をデバイスアイデンティティと関連付けるための方法例
・  ＳＬＰオペレータが、ＳＥＴを使用中にＳＬＰによって所有されるウェブサイトに接続するように加入者をプロンプトする。
【０２６２】
・  加入者がＳＥＴを使用しながらウェブサイト（おそらくＷＡＰ）に接続する。
【０２６３】
・  ウェブサーバがデバイス証明書及びウェブサーバ証明書によるＴＳＬハンドシェイクを要求する。
【０２６４】
・  この証明書は、ＳＬＰサービサー（ｓｅｒｖｉｃｅｒ）と別個であることができる。
【０２６５】
・  加入者がウェブサイトと何らかの（範囲外の）認証を実施する。例えば、ウェブサイトは、ＳＬＰ専用のユーザ名／パスワード、認定された（ｆｅｄｅｒａｔｅｄ）ユーザ名／パスワード又はその他の加入者詳細、例えば、アドレス、誕生日、等、を要求することができる。
【０２６６】
・  これで、ＳＬＰオペレータが、セキュアな形で加入者をデバイスアイデンティティと関連付けており、この関連付けをＳＬＰ内に格納すべきである。
【０２６７】
ランタイムＴＬＳハンドシェイク概要
・  デバイス証明書に基づくクライアント認証
・  最初に、セキュアな暗号化されたＩＰ接続を生成するＡＣＡの場合と同じように公開鍵ＴＬＳを用いてサーバが認証される
・  これは、デバイス証明書においてデバイスのアイデンティティを隠すことによって匿名性を保持する
・  次に、クライアント及びサーバが、サービス証明書及びデバイス証明書に基づいて相互に認証されたＴＬＳを行う
ランタイムＴＬＳハンドシェイク詳細
・  サーバによって認証されたセキュリティが確保されたトンネルを開始するための最初のＳＵＰＬセッションの最初のＴＬＳハンドシェイク
・  ＳＥＴ→ＳＬＰ：サーバ証明書及びデバイス証明書によるＴＬＳのためのサポートを示すＣｌｉｅｎｔ  Ｈｅｌｌｏ
・  ＳＬＰ→ＳＥＴ：サーバ証明書によるＴＬＳのための暗号スイートを示すＳｅｒｖｅｒ  Ｈｅｌｌｏ
ＳＬＰ←→ＳＥＴ：セキュリティが確保されたトンネルを確立するためのＴＬＳハンドシェイクを完了させる
・  相互認証を行うための２回目のＴＬＳハンドシェイク
・  ＳＬＰ→ＳＥＴ：再交渉を開始するためのＨｅｌｌｏ  Ｒｅｑｕｅｓｔ
・  ＳＥＴ→ＳＬＰ：サーバ証明書及びデバイス証明書によるＴＬＳのためのサポートを示すＣｌｉｅｎｔ  Ｈｅｌｌｏ
・  ＳＬＰ→ＳＥＴ：サーバ証明書及びデバイス証明書によるＴＬＳの選択を示すＳｅｒｖｅｒ  Ｈｅｌｌｏ
ＳＰＬ←→ＳＥＴ：セキュリティが確保されたトンネルを確立するためのＴＬＳハンドシェイクを完了させる
・  これで、ＳＥＴ及びＳＬＰは、セキュリティが確保されたチャネルでＳＵＰＬセッションを行うことができる
証明書取り消し
・  デバイス証明書及びサーバ証明書の両方を取り消すことができる
・  デバイス及びサーバの両方が、デバイス証明書が取り消されているかどうかを検査するために証明書取り消しリスト（例えば、［ＲＦＣ３２８０］）又はオンライン証明書状態プロトコル（ＯＣＳＰ）［ＲＦＣ２５６０］、等の方法を使用することができる。
【０２６８】
・  特定の方法は、段階３で考慮される。
【０２６９】
ＳＵＰＬ  ＩＮＩＴ保護概要
・  ＳＵＰＬ３．０でのＳＵＰＬ  ＩＮＩＴ保護は、ＳＵＰＬ２．０におけるＳＵＰＬ  ＩＮＩＴ保護メカニズムに基づいており、ＳＵＰＬ  ＩＮＩＴに添付されたメッセージ認証コード（ＭＡＣ）を使用する
・  このセキュリティは、ＳＬＰに対するサービス拒否攻撃を防止することが目的である。
【０２７０】
・  ＳＵＰＬ  ｖ３．０は、ＳＵＰＬ  ｖ２．０と同じ保護を提供する：
・  モードＡ保護
−  ＧＢＡに基づくクライアント認証を使用する場合に適用される
−  ＳＵＰＬ  ｖ２．０の基本的保護と同一である
−  ＧＢＡに基づくＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを使用する
−  モードＢ保護
−  ＳＵＰＬ  ｖ３．０は、ＳＬＰによってプロビジョニングされたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いてサポートを追加している
−  ＡＣＡ及びデバイス証明書クライアント認証をサポートする
・  ＮＵＬＬ保護もサポートされており、オペレータの選択に基づいて使用することができる。
【０２７１】
・  ＳＵＰＬ  ｖ３．０は、ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹをプロビジョニングするためのメカニズムを追加している
モードＢ保護ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ
・  モードＢ  ＳＵＰＬ_ＩＮＩＴ保護は、ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹをデバイスにプロビジョニングすることを要求する
・  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、デバイスと加入者のこの組み合わせに関して一意である。
【０２７２】
・  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、サービス拒否攻撃に対する保護をＳＬＰに提供するためだけに使用することができることに注目すること。
【０２７３】
・  鍵を開示してもどのようなユーザデータも開示しない。
【０２７４】
・  鍵を開示しても、サービス拒否攻撃に関わる可能性がある１つの余分のデバイスを追加することになるにすぎない。
【０２７５】
・  各ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、ほとんど価値を有さないため、この鍵は、有効な形で“永久的”であり、加入と関連付けられたその他の詳細とともに格納することができる。
【０２７６】
・  すなわち、これらの鍵のセキュリティを保護するための特別なサーバが必要ない。
【０２７７】
・  注：ＵＮＩＣＣが取り除かれることは所有権の変更を示すため、その場合は、ＳＥＴはＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを削除する。
【０２７８】
モードＢ手順
・  モードＢのプロビジョニングを開始
・  モードＢのプロビジョニングを開始するための手順
・  モードＢのプロビジョニング
・  ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹをＳＥＴにプロビジョニングする
・  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いないモードＢ使用法
・  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹがプロビジョニングされていない場合は、ＳＥＴは、ＭＡＣを検証せずにＳＬＰから受け取る最初のＳＵＰＬ_ＩＮＩＴメッセージを受け入れる。
【０２７９】
・  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いるモードＢ使用法
・  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹがプロビジョニングされた時点で、ＳＥＴは、ＭＡＣ及び時間が正確に検証された場合にＳＬＰから受け取ったＳＵＰＬ_ＩＮＩＴメッセージを受け入れ、そうでない場合はＳＵＰＬ_ＩＮＩＴメッセージを受け入れない。
【０２８０】
・モードＢ例外−ハードリセット
モードＢプロビジョニング開始
・  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのプロビジョニングを開始すると、ＳＥＴとＳＬＰとの間での（セキュリティが確保された）ＵＬＰセッション中にＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの提供が生じる
・  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのプロビジョニングを開始する
・  セキュリティが確保されたＵＬＰセッションの開始時に、ＳＥＴがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有していないことに気がついた場合は、ＳＥＴは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ_Ｒｅｑｕｅｓｔインジケータを最初のＵＬＰメッセージに含めることによってＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのプロビジョニングを開始する。
【０２８１】
・  ＳＥＴは、セッションが生じない場合はある期間にわたる幾つかの回数のＳＵＰＬ  ＩＮＩＴの失敗後に（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを要求するための）ＳＵＰＬセッションを生じさせるように構成することができることに注目すること。
【０２８２】
・  ＳＥＴ内のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが壊れているのではないかとＳＬＰが思う場合（例えば、ＳＥＴがある時間にわたってＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹに応答していない場合）は、ＳＬＰは、最初のＵＬＰメッセージをＳＥＴから受信後にＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのプロビジョニングを開始することができる。
【０２８３】
モードＢのプロビジョニング
・  注：この手順は、“モードＢプロビジョニング開始”に準拠する。
【０２８４】
・  ＳＬＰがモードＢ保護をサポートしないことを選択している場合は、ＳＬＰは、該当する表示をＳＥＴに送信する。
【０２８５】
・  その他の場合
・  ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを入手する
・  ＳＬＰがＳＥＴと加入者のこの組み合わせと関連付けられた既存のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、ＳＬＰは、それのレコードからこの値を取り出す
・  ＳＬＰがＳＥＴと加入者のこの組み合わせと関連付けられた既存のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない場合は、ＳＬＰは、新しいＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを生成する。
【０２８６】
・  ＳＬＰが、セキュリティが確保されたＵＬＰメッセージ内のパラメータとしてＳＥＴにＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを送信する
・  ＳＥＴがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの値を格納する。
【０２８７】
・  ＳＥＴは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの格納された値が壊れているかどうかをＳＥＴがのちに検出することを可能にすることになる格納された値の何らかの保護を適用することができる。該保護の例は、誤り訂正及び／又は完全性検査を含む。
【０２８８】
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さないモードＢ使用法
・  ＳＥＴは、モードＢ保護を適用可能であるが、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない状態になることがある。例は、下記を含む。
【０２８９】
・  パワーアップ時で、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹがプロビジョニングされる前。
【０２９０】
・  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが壊れているか又は削除されている。
【０２９１】
・  ＳＥＴが該状態にある場合は、ＳＥＴは、ＭＡＣを検証せずに、ＳＬＰから受信した最初のＳＵＰＬ_ＩＮＩＴメッセージを受け入れる
・  ＳＥＴがＳＬＰとのＴＬＳセッションを確立する
・  ＳＥＴが、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを要求するために上記のモードＢプロビジョニング開始手順を実施する
・  ＳＥＴが該状態にあることをＳＬＰが知っている場合は、ＳＬＰは、ＳＥＴがいずれにせよＳＵＰＬ_ＩＮＩＴメッセージを受け入れることを知った状態で、ＮＵＬＬ保護を用いて該メッセージを送信する。
【０２９２】
・  引き続くＵＬＰセッションでは、ＳＥＴ又はＳＬＰは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのプロビジョニングを開始するために上記のモードＢプロビジョニング開始手順を使用することができる。
【０２９３】
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するモードＢ使用法
・  ＳＥＴがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するとＳＬＰが確信する場合は、ＳＬＰは、各ＳＵＰＬ  ＩＮＩＴメッセージにＳＵＰＬ  ＩＮＩＴプロテクタを加える−これは、ＳＥＴが受信されたＳＵＰＬ  ＩＮＩＴメッセージの真正性を検査するのを可能にする。
【０２９４】
・  モードＢ保護を使用する場合は、ＳＵＰＬ  ＩＮＩＴ  Ｐｒｏｔｅｃｔｏｒパラメータは下記の項目から成る。
【０２９５】
・  ＳＵＰＬ_ＩＮＩＴ_ＴＩＭＥ（長さ＝４オクテット）。メッセージ送信時間。リプレイを停止させる。
【０２９６】
・  ＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣ（長さ＝４オクテット）。メッセージを認証する。
【０２９７】
・  ＳＥＴがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、ＳＥＴは、ＳＵＰＬ_ＩＮＩＴ_ＴＩＭＥが有効であり及びＳＵＰＬ_ＩＮＩＴ内で提供されたＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣがＳＥＴによって計算された値と一致する場合のみにメッセージを受け入れる。
【０２９８】
ＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣ計算
＞    ＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣパラメータは以下のように生成される：
・  ＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，ＳＵＰＬ_ＩＮＩＴ_Ｚ）
・  ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ  ＩＮＩＴメッセージである。
【０２９９】
モードＢ例外−ハードリセット
・  オペレータがＳＵＰＬ  ＩＮＩＴ保護を使用する例外的なケース（例えば、ＳＥＴ及びＳＬＰが同期外れ）では、サービス拒否攻撃が保護されていないＳＵＰＬ  ＩＮＩＴを多数のＳＥＴに送信することによってつけ込むことができないように、（例えば、リセットコマンドを介して）ＳＥＴに明示されている限りにおいて、ＳＥＴを再プロビジョニングするためにヌルＳＵＰＬ  ＩＮＩＴ保護を一時的に使用することができる
・  このリセットコマンドは、新たな脅威の導入を防止するために直接ＳＥＴに入力される。
【０３００】
概要
・  ＳＵＰＬ３．０のための新しいセキュリティモデル：デバイス証明書を用いたクライアント認証。
【０３０１】
・  デバイス証明書は製造時にプロビジョニングされる
・  デバイス証明書を用いたクライアント認証でもＳＵＰＬ  ＩＮＩＴ保護がサポートされる。
【０３０２】
・  デバイス証明書に基づくクライアント認証は、全ベアラをサポートする（ｂｅａｒｅｒ  ａｇｎｏｓｔｉｃ）セキュリティモデルであり、このため、ＳＵＰＬ３．０に適する。
【０３０３】
・  ＳＵＰＬオペレータの選択に依存してレガシーセキュリティモデル（ＡＣＡ及びＧＢＡ）を依然として使用することができる。
【０３０４】
推奨
・  ＳＵＰＬ３．０のためのセキュリティモデルとしてデバイス証明書を用いるクライアント認証。
【０３０５】
・  レガシーのＡＣＡセキュリティモデル及びＧＢＡセキュリティモデルのためのサポートを維持する。
【０３０６】
追加の実施形態７
ＳＵＰＬ２．０のためのセキュリティ上の解決方法は、３ＧＰＰ、３ＧＰＰ２及びＷＩＭａｘアクセスネットワーク以外では利用できないことがあり（例えば、ＷｉＦｉアクセスをサポートしないことがあり）、強力なセキュリティをサポートするためにＧＢＡの実装を含む。さらに、セキュリティ上の解決方法は、ホームオペレータＳＬＰ（Ｈ−ＳＬＰ）の代わりに又はホームオペレータＳＬＰ（Ｈ−ＳＬＰ）に加えてアクセス関連ＳＬＰ（Ａ−ＳＬＰ）をサポートするのを可能にできないことがある。
【０３０７】
本実施形態は、ＴＬＳ−ＳＲＰを用いたクライアント（ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ））の認証をサポートするためにＳＬＰプロバイダによってユーザ又はユーザのＳＥＴに割り当てられたユーザ名及びパスワードを利用する。ＳＵＰＬ  ＳＥＴ及びＳＬＰは、ＳＥＴがＳＬＰを認証することを可能にするために公開鍵ＴＬＳを使用することができる。これは、ＴＬＳ−ＳＲＰ（及び予め取り決められたユーザ名及びパスワード）を用いたＳＬＰによるＳＥＴの２回目の認証が生じるセキュアなＴＬＳ／ＩＰコネクションを生成することができる。これは、最初のセキュアなＴＬＳ／ＩＰコネクションを変更することができ、セキュアなＳＵＰＬセッションをサポートするために使用される。ＳＬＰは、このＳＵＰＬセッションを用いて、最初に割り当てられたユーザ名及びパスワードと取り替えるための新しいユーザ名及びパスワードをＳＥＴに提供することができる。新しいユーザ名及びパスワードは、ユーザには見えず、これは、ユーザが２つ以上のデバイスでユーザ名及びパスワードを使用するのを防止することができ及びユーザが最初のユーザ名パスワードをその他のユーザに誤って転送しないように保護することができる。この解決方法は、Ｈ−ＳＬＰ及びＡ−ＳＬＰの両方に関して使用することができ、必ずしも３ＧＰＰ、３ＧＰＰ２又はＷｉＭａｘアクセスネットワークのみの使用を要求しない。
【０３０８】
従って、説明される実施形態は、ＳＵＰＬセキュリティサポートを全ＩＰアクセスネットワークに拡大し、ＧＢＡをサポートする必要なしに現在配備される解決方法よりも強力なセキュリティを提供することができ、及び、Ｈ−ＳＬＰ及びＡ−ＳＬＰをサポートすることができる（節の番号は、ＳＵＰＬ３．０の節番を指すことができる）。
【０３０９】
６．セキュリティ上の考慮事項
本節では、ＳＵＰＬネットワークがＳＥＴを認証して権限を付与するのを可能にし及びＳＥＴがＳＵＰＬネットワークを認証して権限を付与するのを可能にするＳＵＰＬセキュリティ機能について説明する。
【０３１０】
注：別記がないかぎり、頭字語ＴＬＳの使用は、ＴＬＳハンドシェイクを用いて交渉することができるあらゆるセッションを指す。すなわち、これは、ＴＬＳ１．１暗号スイート及びＴＬＳ−ＰＳＫ暗号スイートの両方を含む。
【０３１１】
注：本節では、次の定義が適用される。３ＧＰＰベアラネットワークは、そのための規格が３ＧＰＰによって維持されるそれであり、これらは、ＧＳＭベアラネットワークと、ＧＰＲＳベアラネットワークと、ＥＤＧＥベアラネットワークと、ＷＣＤＭＡ（登録商標）／ＴＤ−ＳＣＤＭＡベアラネットワークと、ＬＴＥベアラネットワークと、ＬＴＥ−Ａベアラネットワークとを含む。３ＧＰＰ２ベアラネットワークは、そのための規格が３ＧＰＰ２によって維持されるそれであり、これらは、ｃｄｍａＯｎｅベアラネットワークと、ｃｄｍａ２０００  １ｘベアラネットワークと、ｃｄｍａ２００  ＥＶ−ＤＯベアラネットワークとを含む。３ＧＰＰ  ＳＥＴ（それぞれ３ＧＰＰ２  ＳＥＴ）は、それのホームネットワークオペレータが主に３ＧＰＰベアラネットワーク（それぞれ３ＧＰＰ２ネットワーク）を介してデータアクセスをサポートするＳＥＴである。ＷｉＭＡＸ  ＳＥＴは、それのホームネットワークオペレータが主にＷｉＭＡＸベアラネットワークを介してデータアクセスをサポートするＳＥＴである。曖昧な場合は（例えば、複数のアクセスタイプをサポートするオペレータ）、オペレータは、ＳＥＴのタイプを決定することができる。
【０３１２】
注：Ｈ−ＳＬＰオペレータは、ここにおいて説明される認証方法は同じオペレータに属するアクセスネットワーク間でのＳＥＴハンドオーバーに関して及びＳＥＴ  ＩＰアドレスが変更されない場合に引き続き有効であることに注目べきである。手順は、ＳＥＴが１つのアクセスネットワークから異なるオペレータに属する他に移動するシナリオ又はＩＰアドレスが変更されるシナリオは考慮していない。これらのシナリオでは、他のアクセスシステムへのハンドオーバー後に、端末及びネットワークにおいてセキュリティコンテキストを利用できないことがあり及びネットワークと端末との間の信用度が変化することがあると推定される。
【０３１３】
パワーアップ及びシャットダウン、新しいＵＩＣＣの検出又はＵＩＣＣの取り外し次第、ＳＥＴハンドセットは、ＳＵＰＬ３．０と関連付けられたＳＥＴハンドセット上の（長期鍵は別にして）あらゆる鍵を削除しなければならず、下記のキーを含む。
【０３１４】
◆  ＧＢＡ鍵：例えば、Ｋｓ、Ｋｓ_ＮＡＦ、Ｋｓ_ｅｘｔ_ＮＡＦ
◆  ＷＩＭＡＸ鍵：例えば、ＳＥＫ
◆  ＴＬＳ鍵：例えば、ｐｒｅ_ｍａｓｔｅｒ_ｓｅｃｒｅｔ、ｍａｓｔｅｒ_ｓｅｃｒｅｔ、及びＰＳＫ値（長期鍵は別とする）。
【０３１５】
◆  ＳＵＰＬ専用鍵：例えば、ＳＵＰＬ  ＩＮＩＴメッセージの保護と関連付けられた鍵。
【０３１６】
６．１  ＳＵＰＬ認証方法
ＳＵＰＬ３．０に関する認証サポート要件は次の通りである。
【０３１７】
・ＳＥＴとＨ−ＳＬＰとの間で相互認証をサポートすることができる。
【０３１８】
・ＳＥＴとＤ−ＳＬＰとの間で相互認証をサポートすることができる。
【０３１９】
・ＳＥＴとＥ−ＳＬＰとの間でサーバ認証をサポートすることができ、及び、ＳＥＴとＥ−ＳＬＰとの間で相互認証をサポートすることができる。
【０３２０】
ＳＵＰＬ３．０は、２つのクラスのＳＥＴ認証方法をサポートする
・  ＡＮに依存する方法であり、クレデンシャルがＳＥＴユーザのアクセスネットワーク加入にバインドされる。
【０３２１】
・  ＡＮから独立した方法であり、クレデンシャルがＳＥＴにバインドされるが、ＳＥＴユーザのアクセスネットワーク加入に直接はバインドされない。該クレデンシャルをＳＥＴユーザのアクセスネットワーク加入にバインドすることは、範囲外（ｏｕｔ−ｏｆ−ｓｃｏｐｅ）手順を用いて達成させることができる。範囲外手順に関する詳細な説明については第６．６節を参照すること。
【０３２２】
相互認証が実施されるときには、ＳＥＴは、ＳＥＴ内に含まれているＳＵＰＬエージェントを介してＳＥＴユーザの代わりに行動することができる。
【０３２３】
・  ＡＮに依存する方法に関しては、ＳＥＴは、ＳＥＴユーザと関連付けられたセキュリティクレデンシャルを使用する。
【０３２４】
・  ＡＮから独立した方法に関しては、ＳＥＴは、ＳＥＴと関連付けられたセキュリティクレデンシャルを使用する。
【０３２５】
ＳＥＴユーザの認証が成功した場合は、その結果として、ＳＥＴユーザのＩＤ（例えば、ＭＳＩＳＤＮ、ＷＩＭＡＸユーザＩＤ又はＡＮから独立したユーザアイデンティティ）が成功裏に識別されなければならないことに注目すること。
【０３２６】
ＭＳＩＳＤＮが認証のために使用されるときには、ＳＬＰは、認証されたＳＥＴのＭＳＩＳＤＮがセキュアな形で識別される前にＩＭＳＩとＭＳＩＳＤＮのバインディングを行わなければならないことに注目すること。
【０３２７】
鍵管理詳細は第６．１．２節において見ることができる。
【０３２８】
６．１．１  認証方法
第６．１．１．１．節は、この明細書でサポートされる認証方法について説明する。第６．１．１．２節では、これらの方法に関する情報を提供するための概要を示してある。第６．１．１．３節は、様々なＳＵＰＬ３．０のエンティティにおいていずれの方法が強制的又は任意選択であるかを説明し、所定の相互認証方法をサポートする場合に各エンティティにおいて要求されるプロトコルを記載した。
【０３２９】
６．１．１．１  サポートされる相互認証方法の一覧
ＳＵＰＬ認証モデルは、取り除くことが可能なトークン、例えばＲ−ＵＩＭ／ＵＩＣＣ／ＳＩＭ／ＵＳＩＭ又はＳＥＴハンドセットのいずれかにバインドされた、ＳＬＰとＳＥＴとの間での共有秘密鍵を確立することを要求する。
【０３３０】
本書では次の２つのクラスの認証方法が規定される：
・ＰＳＫに基づく方法、次の方法から成る：
○  ＡＮに依存する汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく方法であり、相互認証を提供する；
○  ＡＮに依存するＳＥＫに基づく方法であり（ＷＩＭＡＸ  ＳＬＰのみに適用可能）、相互認証を提供する；
・  証明書に基づく方法であり、次の方法から成る：
○  ＡＮから独立したデバイス証明書に基づく（ＤＣｅｒｔ）方法であり、相互認証を提供する；
○  ＡＮに依存する代替クライアント認証（ＡＣＡ）に基づく方法であり、相互認証を提供する；
○  ＡＮから独立したＳＬＰ専用の方法であり（緊急時のみに適用可能）、ＳＬＰの認証のみを提供する。
【０３３１】
６．１．１．２  サポートされる認証方法の概要（情報用）
１．汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく。汎用ブートストラッピングアーキテクチャ（ＧＢＡ）ＧＢＡを有するＴＬＳ−ＰＳＫは、既存の３ＧＰＰ／３ＧＰＰ２認証メカニズムを用いて導き出される共有の秘密に基づく相互認証能力を提供する。
【０３３２】
・  ＳＥＴ及びＳＬＰは、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）を有するＴＬＳ−ＰＳＫを用いて相互に認証される。
【０３３３】
２．ＳＥＫに基づく（ＷＩＭＡＸ  ＳＬＰのみに適用可能）
・  ＳＥＴ及びＳＬＰは、ＳＥＫを有するＴＬＳ−ＰＳＫを用いて相互に認証される。ＳＥＫ方法の詳細は、第６．１．２．１．２節において見つけることができる。
【０３３４】
３．デバイス証明書（ＤＣｅｒｔ）に基づく。このＡＮから独立した方法は、以下を用いるＴＬＳを使用する
・  ＳＥＴに対してＳＬＰを認証するためのＲＳＡサーバ証明書、
・  ＳＬＰに対してＳＥＴを認証するためのＲＳＡクライアント証明書
４．代替クライアント認証（ＡＣＡ）に基づく。これは、以下によるＴＬＳを使用する
・  ＳＥＴに対してＳＬＰを認証するためのＲＳＡ証明書、
・  ＳＬＰに対するＳＥＴの代替クライアント認証（第６．１．４参照）。この場合は、ＳＬＰは、ＳＥＴ識別子（ＭＳＩＳＤＮ、等）と関連付けられたＩＰアドレスをベアラネットワークに確認させることによってＳＥＴを認証する。
【０３３５】
５．ＳＬＰ専用。これは、ＳＬＰがＳＥＴを認証できないシナリオにおいて使用される。この方法は、非緊急時のためには使用できない。ＳＥＴは、この方法とＡＣＡ基づく場合を区別することができない。これは、以下によるＴＬＳを使用する
・  ＳＥＴに対してＳＬＰを認証するためのＲＳＡ証明書
・  ＳＥＴは認証されない。
【０３３６】
６．１．１．３  エンティティ別の相互認証方法及びプロトコルのサポート
以下の４つの表は、様々なクラスのＳＥＴ及びそれらのＳＥＴをサポートするＳＬＰにおけるＳＵＰＬ３．０のサポートにとって何が任意選択的であり、何が強制的であるかを示す。
【０３３７】
・  第１の表は、以下においてＳＵＰＬ３．０のために実装する上で強制的である方法及び任意選択的である方法を示す。
【０３３８】
○  ３ＧＰＰ／３ＧＰＰ２  ＳＥＴ、
○  ＳＥＴ（Ｒ−）ＵＩＭ／ＳＩＭ／ＵＳＩＭ及び
○  ３ＧＰＰ／３ＧＰＰ２  ＳＥＴをサポートするＳＬＰ
・  第２の表は、以下においてＳＵＰＬ３．０のために実装する上で強制的である方法及び任意選択的である方法を示す。
【０３３９】
○  ＷｉＭＡＸ  ＳＥＴ
○  それらのＷｉＭＡＸ  ＳＥＴをサポートするＳＬＰ；
・  第３の表は、以下においてＳＵＰＬ３．０のために実装する上で強制的である方法及び任意選択的である方法を示す。
【０３４０】
○  ３ＧＰＰ／３ＧＰＰ２もＷｉＭＡＸもサポートしないＳＥＴ、及び
○  それらのＳＥＴをサポートするＳＬＰ。
【０３４１】
・  第４の表は、様々な認証方法の各々をサポートするためのＳＬＰ、ＳＥＴハンドセット及び（該当する場合）ＳＥＴ（Ｒ−）ＵＩＭ／ＳＩＭ／ＵＳＩＭのための要求されるプロトコルを示す。
【表９】
0005876063.tif 000010
【０３４２】
３ＧＰＰ／３ＧＰＰ２  ＳＥＴ及びこれらのＳＥＴをサポートするＳＬＰのための様々な認証方法に関する要件状況（強制的又は任意選択的）
注１：ＳＬＰ専用方法のためのＳＥＴハンドセットサポートは、緊急時のために要求されることがある。
【０３４３】
注２：（３ＧＰＰ及び３ＧＰＰ２専用の）ＡＣＡに基づく方法に関するＳＥＴ手順は、ＳＬＰ専用方法に関するＳＥＴ手順と同一である。従って、３ＧＰＰ／３ＧＰＰ２  ＳＥＴハンドセットは、ＳＬＰ専用方法が緊急時のために要求される結果としてＡＣＡに基づく方法をサポートする。
【表１０】
0005876063.tif 000011
【０３４４】
ＷｉＭＡＸ  ＳＥＴ、及びこれらのＷｉＭＡＸ  ＳＥＴをサポートするＳＬＰのための様々な認証方法に関する要件状況（強制的又は任意選択的）
【表１１】
0005876063.tif 000012
【０３４５】
３ＧＰＰ、３ＧＰＰ２及びＷｉＭＡＸをサポートしないＳＥＴ、及びこれらのＳＥＴをサポートするＳＬＰのための様々な認証方法に関する要件状況（強制的又は任意
【表１２】
0005876063.tif 000013
【０３４６】
様々な相互認証方法をサポートするためのＳＬＰ、ＳＥＴハンドセット及びＳＥＴ  Ｒ−ＵＩＭ／ＵＩＣＣ／ＳＩＭ／ＵＳＩＭのための要求されるプロトコル
ＧＢＡに基づく方法がサポートされる場合は、ＢＳＦは、Ｈ−ＳＬＰアプリケーションと関連付けられたユーザセキュリティ設定（ＵＳＳ）を格納する。Ｈ−ＳＬＰがＵＳＳを要求するときには、ＢＳＦは、ＵＳＳにＳＥＴユーザアイデンティティ（例えば、ＩＭＰＩ、ＩＭＳＩ又はＭＳＩＳＤＮ）を含めなければならない。
【０３４７】
注：ＧＢＡに基づく方法は、ＳＵＰＬセッションを転送するために３ＧＰＰ又は３ＧＰＰ２ベアラネットワークを使用することには依存していない。しかしながら、ＳＥＴは、ＧＢＡを実施するための必要なクレデンシャルを有するために３ＧＰＰ又は３ＧＰＰホームネットワークオペレータを有さなければならない。
【０３４８】
６．１．１．４  ＴＬＳハンドシェイク仕事量を最小にするための技法
本節の手順は、ＳＬＰとＳＥＴとの間でＴＬＳセッションを確立することに関連する作業量を最小にするものである。ＴＬＳとの矛盾が生じる場合は、ＴＬＳが優先する。
【０３４９】
ＳＥＴ及びＳＬＰが２つ以上のＳＵＰＬセッションと関連付けられたＳＵＰＬメッセージを同時に通信中である場合は、ＳＥＴ及びＳＬＰは、これらのメッセージのセキュリティを確保するために単一のＴＬＳセッションを使用すべきである。すなわち、ＳＥＴ及びＳＬＰは、ＳＵＰＬセッションが同時である場合は別個のＴＬＳセッションを確立すべきではない。
【０３５０】
ＳＥＴ及びＳＬＰがＴＬＳセッションを確立する場合は、ＳＬＰは、短縮されたハンドシェイクを用いてそのセッションを再開するのを可能にすることができる。ＴＬＳセッションを再開することの利点は、サーバ証明書に基づいてＴＬＳを再開することは、公開鍵に関する動作を要求しない、すなわち、（有意なレベルでより少ない処理を要求する）対称的暗号アルゴリズムのみが要求されることである。
【０３５１】
注：緊急ＳＵＰＬセッションは非常に偶発的に発生するので必要なデータを確実には格納できないため、このアプローチ法はＥ−ＳＬＰに関しては推奨されない。
【０３５２】
注：ＳＬＰは、ＴＬＳ  ＳｅｓｓｉｏｎＩＤを割り当てることによってセッションを再開させるのを可能にする。
【０３５３】
注：（ＧＢＡ及びＳＥＫに基づく認証のために使用される）ＴＬＳ−ＰＳＫセッションを再開させても同じ計算が行われるため利点はない。しかしながら、ＳＬＰはそれでもＴＬＳ−ＰＳＫセッションを再開させるのを可能にすることができる。
【０３５４】
注：ＳＥＴは、ＴＬＳハンドシェイクのＣｌｉｅｎｔＨｅｌｌｏメッセージ内のＴＬＳ  ＳｅｓｓｉｏｎＩＤパラメータに（再開すべきＴＬＳセッションの）ＴＬＳ  ＳｅｓｓｉｏｎＩＤを含めることによってＴＬＳセッションを再開させるのを選択したことを示す。ＳＥＴがＴＬＳセッションを再開させることを希望しない場合は、ＳＥＴは、ＴＬＳ  ＳｅｓｓｉｏｎＩＤを含めずにＴＬＳ  ＣｌｉｅｎｔＨｅｌｌｏメッセージを送信し、その場合は、フルハンドシェイクが行われる。ＴＬＳ  ＳｅｓｓｉｏｎＩＤパラメータがＴＬＳ  ＣｌｉｅｎｔＨｅｌｌｏメッセージ内に存在する場合は、ＳＬＰは、ＴＬＳセッションを再開させるかどうかを選択する。ＳｅｓｓｉｏｎＩＤパラメータがＴＬＳ  ＣｌｉｅｎｔＨｅｌｌｏメッセージ内に存在しない場合は、ＳＬＰは、ＴＬＳハンドシェイクを前回のＴＬＳセッションと関連付けることができず、このため、ＴＬＳハンドシェイクは、フルハンドシェイクを用いて完全に新しいＴＬＳセッションを確立する。
【０３５５】
ＳＥＴは、次の指針に従ってＴＬＳセッションを再開させるかどうかを選択する。
【０３５６】
◆  ＳＥＴは、根本になるクレデンシャル（Ｋｓ（_ｅｘｔ）_ＮＡＦ又はＳＬＰ証明書又はＳＥＫ又はデバイス証明書）が期限切れの場合はＴＬＳセッションを再開させてはならない。
【０３５７】
◆  ＳＥＴは、希望される場合は、根本になるクレデンシャルの期限切れよりも早期にＴＬＳセッションを再開させないことを選択することができる。
【０３５８】
◆  ＳＥＴは、パワーアップ前又は新しいＲ−ＵＩＭ／ＵＩＣＣ／ＳＩＭ／ＵＳＩＭの検出前に確立されたセッションを再開させてはならない。
【０３５９】
ＳＬＰは、次の指針を用いてＴＬＳセッションを再開させるかどうかを選択する。
【０３６０】
◆  ＳＥＴは、根本になるクレデンシャル（Ｋｓ（_ｅｘｔ）_ＮＡＦ又はＳＬＰ証明書又はＳＥＫ又はデバイス証明書）が期限切れの場合はＴＬＳセッションを再開させてはならない。
【０３６１】
◆  ＳＥＴは、希望される場合は、根本になるクレデンシャルの期限切れよりも早期にＴＬＳセッションを再開させないことを選択することができる。
【０３６２】
注：各ＳＬＰは、短縮されたハンドシェイクを可能にするかどうかをそれ自体で判断しなければならず、この判断は、各々のＳＥＴごとに行うことさえも可能である。ＳＬＰは、既存のセッションを再開させることを受け入れたときには小さいリスクを冒していることになる。このリスクは、“いたずらな”ＳＥＴが（フルＴＬＳハンドシェイク中に確立された）ｍａｓｔｅｒ_ｓｅｃｒｅｔを配布し、このため、その他の者がそのＴＬＳセッションを再開させることができ、それによって複数のＳＥＴが単一のＳＥＴに対して課金されるサービスを入手するのを可能にする可能性があることである。“いたずらな”ＳＥＴは、ＳＥＴ所有者が知らない状態でこれを行っていることが可能である（例えば、悪意のあるコードに責任がある可能性がある）。紛失は簡単に制限できることに注目すること。すなわち、該悪用が発生していることをＳＬＰが検出するか（又は疑う）場合は、ＳＬＰは、簡単に（ａ）そのｍａｓｔｅｒ_ｓｅｃｒｅｔを使用しているＴＬＳセッションを終了させ、（ｂ）“いたずらな”ＳＥＴを特定し及び（ｃ）必要な場合はユーザが引き続きサービスを有するのを可能にするためにフルハンドシェイクを用いて“いたずらな”ＳＥＴを再認証することができる。要約すると、ＤＣｅｒｔ方法、ＡＣＡに基づく方法及びＳＬＰ専用方法に関して（計算を低減させることについての）セッションを再開させることの利益は、攻撃というリスクを上回ると考えられる。
【０３６３】
６．１．２  ＳＵＰＬ認証のための鍵管理
ＳＵＰＬ認証モデルは、取り除くことが可能なトークン、例えばＲ−ＵＩＭ／ＵＩＣＣ／ＳＩＭ／ＵＳＩＭ又はＳＥＴハンドセットのいずれかにバインドされた、ＳＬＰとＳＥＴとの間での共有秘密鍵を確立することを要求する。
【０３６４】
６．１．２．１  ＰＳＫに基づく方法
６．１．２．１．１  ＧＢＡ方法をサポートする配備
ＧＢＡをサポートする配備の場合は、共有鍵は次のように確立される：
・  ＳＬＰが（ＩＰ通信のセキュリティを確保するために及びＳＵＰＬ  ＩＮＩＴを保護するために）鍵素材をＢＳＦに要求するときには、ＳＬＰは、ＵＳＳ（ユーザセキュリティ設定）も要求しなければならない。ＵＳＳは、永久的なユーザアイデンティティ（例えば、ＩＭＰＩ、ＩＭＳＩ又はＭＳＩＳＤＮ）を含まなければならない。
【０３６５】
・  ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するためには、ＳＥＴ及びＳＬＰは、ＧＢＡを用いてＴＬＳ−ＰＳＫに従って共有秘密鍵を導き出し及び動作しなければならない。ＳＬＰは、ＳＬＰを指定する適切に定義されたドメイン名ＳＬＰ_Ａｄｄｒｅｓｓ_ＦＱＤＮ、例えば、ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ、を有さなければならない。ＴＬＳ−ＰＳＫのために使用することができるＧＢＡ  Ｕａセキュリティプロトコル識別子がＯＭＮＡレジストリ内で定義されている。ＳＬＰは、ＢＳＦによって提供された永久的なユーザアイデンティティが対応するセキュリティが確保されたコネクションを通じてＳＬＰによって受信されたＳＵＰＬメッセージ内のＳＥＴアイデンティティに対応することを確認しなければならない。
【０３６６】
・  ＳＵＰＬ  ＩＮＩＴのＭＡＣ保護に関して、ＧＢＡにより鍵が導き出される。ＳＵＰＬ  ＩＮＩＴ保護のために使用することができるＧＢＡ  Ｕａセキュリティプロトコル識別子がＯＭＮＡレジストリ内で定義されている。ＳＵＰＬ  ＩＮＩＴメッセージに含まれるｂａｓｉｃＭＡＣのｋｅｙＩｄｅｎｔｉｆｉｅｒは、Ｋｓ_ＮＡＦが生成されるＫｓのＢ−ＴＩＤでなければならない。注：Ｈ／Ｄ−ＳＬＰによるＢＳＦへのＳＵＰＬ  ＩＮＩＴ保護鍵の要求は、典型的には、Ｈ／Ｄ−ＳＬＰによるＩＰ通信のセキュリティを確保する鍵の要求と同時に発生することになる。
【０３６７】
・  ＳＥＴは、有効なＫｓが常にプロビジョニングされていることを確認しなければならない。有効なＫｓが存在しない場合は、ＳＥＴは、ＫｓをプロビジョニングするためのＧＢＡブートストラッピング手順を開始しなければならない。新しいＵＩＣＣ（ＵＳＩＭ／ＳＩＭ／Ｒ−ＵＩＭ）がＳＥＴによって検出されるごとに新しいＫｓが確立されなければならない。さらに、ＳＥＴは、（ホームネットワークオペレータによって設定された）Ｋｓ_ＮＡＦの寿命が過ぎているときには新しい共有鍵を確立しなけければならない。
【０３６８】
６．１．２．１．２  ＳＥＫ方法をサポートする配備
ＳＥＫをサポートする配備の場合は、共有鍵は次のように確立される：
・  ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するために、ＳＥＴ及びＳＬＰは、共有される秘密鍵を導き出さなければならず及びＷｉＭＡＸ  ＡＡＡサーバによって提供された永久的なユーザアイデンティティが対応するセキュリティが確保されたコネクションを通じてＳＬＰによって受信されたＳＵＰＬメッセージ内のＳＥＴアイデンティティに対応することを確認しなければならない。共有される鍵は、次の方法で導き出される：
○  ＳＥＫ＝ＨＭＡＣ−ＳＨＡ２５６（ＬＳＫ，“ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ”）の１６の最上位（左端）オクテット。ここで、'ｏｐｅｒａｔｏｒ．ｃｏｍ'は、ＷＩＭＡＸオペレータのＦＱＤＮであり、ＬＳＫは、位置に基づくサービスに関するＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおける規定に従って導き出される。
【０３６９】
○  ＳＥＫは、ＬＳＫと関連付けられた（位置に基づくサービスに関するＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおいて定義される）位置鍵識別子（ＬＳＫ−ＩＤ）を引き継ぎ、鍵アイデンティティがＷｉＭＡＸ配備のためのＢ−ＴＩＤとして使用される。
【０３７０】
・  ＳＵＰＬ  ＩＮＩＴのＭＡＣ完全性保護のために、鍵は次の方法で導き出される：
○  ＳＥＫ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６（ＬＳＫ，“ｍａｃ．ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ”）の１６の最上位（左端）オクテット。ここで、'ｏｐｅｒａｔｏｒ．ｃｏｍ'は、ＳＬＰオペレータのＦＱＤＮであり、ＬＳＫは、位置に基づくサービスに関するＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおける規定に従って導き出される。
【０３７１】
○  ＳＵＰＬ  ＩＮＩＴメッセージに含まれているモードＡ  ＭＡＣのｋｅｙＩｄｅｎｔｉｆｉｅｒは、ＳＥＫ_ＭＡＣが生成されるＬＳＫのＢ−ＴＩＤでなければならない。注：ＳＬＰによるＷｉＭＡＸ  ＡＡＡへのＳＵＰＬ  ＩＮＩＴ保護鍵の要求は、典型的には、ＳＬＰによるＩＰ通信のセキュリティを確保する鍵の要求と同時に発生することになる。
【０３７２】
ＳＥＴは、有効なＳＥＫが常に提供されていることを確認しなければならない。有効なＳＥＫが存在しない場合は、ＳＥＴは、上記に従ってＳＥＫを導き出さなければならない。さらに、ＳＥＴは、ＬＳＫの寿命が経過しているときには新しい共有鍵を確立しなければならない。ＳＬＰとＷｉＭＡＸ  ＡＡＡサーバとの間のインタフェースは、ＳＵＰＬ３．０の範囲外である。
【０３７３】
６．１．２．２  サーバ証明書に基づく方法
６．１．２．２．１  ＤＣｅｒｔ方法をサポートする配備
ＤＣｅｒｔ方法をサポートする配備の場合は、共有鍵は次のように確立される：
・  ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するために、ＳＥＴ及びＳＬＰは、ＳＬＰを認証するサーバ証明書及びＳＥＴを認証するクライアント証明書を用いてＴＬＳ−ＲＳＡを使用しなければならない。クライアント証明書は、グローバルで一意のＳＥＴデバイスアイデンティティを提供することができる：
○  ３ＧＰＰ  ＳＥＴは、ＩＭＥＩをグローバルで一意のＳＥＴデバイスアイデンティティとして使用することができる。
【０３７４】
○  ３ＧＰＰ２  ＳＥＴは、ＭＳＩＤをグローバルで一意のＳＥＴデバイスアイデンティティとして使用することができる。
【０３７５】
○  ＷｉＭＡＸ  ＳＥＴは、ＳＥＴ一連番号をグローバルで一意のＳＥＴデバイスアイデンティティとして使用することができる。
【０３７６】
○  すべてのその他のＳＥＴは、適切なグローバル識別子（例えば、売り主の身元を含む一連番号）をグローバルで一意のＳＥＴデバイスアイデンティティとして使用することができる。
【０３７７】
・  ＳＵＰＬユーザは、このデバイスがそれらの加入と関連付けられるべきであることをセキュリティが確保された形でＳＬＰに検証しなければならない。このセキュアな検証は、本明細書の範囲外である。この話題に関するさらなる説明については第６．５節を参照すること。
【０３７８】
・  ＳＵＰＬ  ＩＮＩＴのＭＡＣ完全性保護のために、鍵は、ＵＬＰメッセージに入れてＳＬＰによってＳＥＴに提供される。これは、第６．３．５節で説明される。
【０３７９】
６．１．２．２．２  ＡＣＡ方法をサポートする配備
ＡＣＡ方法をサポートする配備の場合は、共有鍵は次のように確立される：
・  ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するために、ＳＥＴ及びＳＬＰは、ＳＬＰを認証するサーバ証明書を用いてＴＬＳ−ＲＳＡを使用しなければならない。ＳＥＴ認証（結果的に得られた共有秘密鍵を、上記の取り外し可能なトークン又は統合されたトークンのいずれかとバインドさせる）は、第６．１．４節では非緊急時に関して及び第６．２．５節では緊急時に関して説明されている。
【０３８０】
・  ＳＵＰＬ  ＩＮＩＴのＭＡＣ完全性保護に関しては、鍵は、ＵＬＰメッセージでＳＬＰによってＳＥＴに提供される。これは、第６．３．５節で説明される。
【０３８１】
６．１．２．２．３  ＳＬＰ専用方法をサポートする配備
ＳＬＰ専用方法をサポートする配備の場合は、共有鍵は次のように確立される：
・  ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するために、ＳＥＴ及びＳＬＰは、ＳＬＰを認証するサーバ証明書を用いてＴＬＳ−ＲＳＡを使用しなければならない。第６．１．４節では非緊急時に関して及び第６．２．５節では緊急時に関して説明されるようなＳＥＴ認証（結果的に得られた共有秘密鍵を、Ｒ−ＵＩＭ／ＵＩＣＣ／ＳＩＭ／ＵＳＩＭ又はＳＥＴハンドセットのいずれかにバインドさせる）は存在しない。
【０３８２】
・これらの事例ではＳＵＰＬ  ＩＮＩＴのＭＡＣ保護はサポートされていない。
【０３８３】
６．１．３  相互認証方法のＴＬＳハンドシェイク及び交渉
ＳＥＴ及びＳＬＰは、適用されるべき相互にサポートされる認証方法を取り決める必要がある。
【０３８４】
６．１．３．１  相互認証方法の交渉に関して（情報用）
Ｈ−ＳＬＰへのＴＬＳコネクションを確立するときには、ＳＥＴは、最初に、以下の優先順序により、最高の優先度を有する相互にサポートされる認証メカニズムを用いてコネクションを確立することを試みる：
◆  ＰＳＫに基づく方法：ＧＢＡ又はＳＥＫに基づく方法が最も優先される（サポートされる場合）；
◆  ＤＣｅｒｔ方法：２番目に優先される（サポートされる場合）
◆  ＡＣＡ又はＳＬＰ専用方法：３番目に優先される（ＳＥＴの観点からは、ＡＣＡに基づく方法とＳＬＰ専用方法との間に差はない）。
【０３８５】
相互にサポートされる認証方法がない場合は、ＳＥＴは、ＳＵＰＬセッションを行うことができないことがある。
【０３８６】
ＰＳＫに基づく方法をサポートするＳＥＴは、ＢＳＦ又はＷｉＭＡＸ  ＡＡＡが問題に遭遇することに起因して所定の時点にＧＢＡ又はＳＥＫに基づく方法を使用できないことがある。従って、ＳＥＴがＧＢＡ又はＳＫＥを用いて認証を確立することを試みても、ＳＥＴがＧＢＡ又はＳＥＫに基づく鍵を確立することができるかどうかは必ずしも保証されない。
【０３８７】
従って、ＳＥＴは、最高の優先度を有する相互にサポートされる認証メカニズムを常に使用できるわけではない。ＳＥＴは、利用可能な場合はそれよりも低い優先度の相互にサポートされる認証メカニズムに戻らなければならないことがある。
【０３８８】
（Ｈ−ＳＬＰ証明書で）ＰＳＫに基づく方法のみがＨ−ＳＬＰによってサポートされることが示され、ブートストラッピングが失敗した場合は、ＳＥＴは、該当するエンティティがオンラインに戻るための機会を与えるために、ＴＬＳハンドシェイクを再試行する前に少しの間待機することができる。
【０３８９】
ＳＬＰがＧＢＡ又はＳＥＫのみをサポートする場合は、ＳＬＰは、ＧＢＡ又はＳＥＫを配備しているキャリアの加入者に対してＳＵＰＬ３．０サービスを提供することに限定される。ＳＬＰがＡＣＡのみをサポートする場合は、ＳＵＰＬ３．０は、第６．１．４節において詳細に説明される状況でしか使用することができない。該場合に、ＳＥＴが、ＳＬＰがＩＰバインディングを入手することができない代替ベアラ（例えば、無線ＬＡＮ）を介して通信する場合は、ＳＬＰは、ＳＥＴを認証することができない。
【０３９０】
Ｅ−ＳＬＰがＡＣＡのみをサポートする場合は、第６．２．５．節において詳細に説明されるように、ＳＥＴ認証に関する停止警告が存在する。
【０３９１】
６．１．３．２  非ＷｉＭＡＸ  ＳＥＴのための相互認証方法の交渉
非ＷｉＭＡＸ  ＳＥＴの場合は、ＳＵＰＬセッションのための相互認証方法の交渉は次のように進行する：
１．ＳＥＴが交渉を開始する
ａ．ＳＥＴがＧＢＡをサポートする場合は、ＳＥＴは、該当するＧＢＡ仕様に準拠した交渉を開始する。
【０３９２】
ｂ．そうでない場合（すなわち、ＳＥＴがＧＢＡをサポートしない場合）は、ＳＥＴは、ＣｌｉｅｎｔＨｅｌｌｏメッセージによるＴＬＳハンドシェイクを開始し、ＣｌｉｅｎｔＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅｓフィールドは、ＴＬＳ鍵やり取りアルゴリズムのためのＲＳＡ暗号化を用いるサポートされるＴＬＳ暗号スイートを示す。
【０３９３】
２．ＳＬＰが、受信されたＣｌｉｅｎｔＨｅｌｌｏメッセージを処理する。ＳＬＰがＣｌｉｅｎｔＨｅｌｌｏ．ｃｉｐｈｅｒｓｕｉｔｅｓリストを検討し、相互に参照される暗号スイートを選択する。
【０３９４】
ａ．ＳＥＴ及びＳＬＰの両方がＴＬＳ−ＰＳＫ暗号スイートをサポートする場合は、これは、ＧＢＡのためのサポートを示す。ＳＬＰがＳｅｒｖｅｒＨｅｌｌｏ、ＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅ及びＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージで応答し、ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅは、相互にサポートされるＴＬＳ−ＰＳＫ暗号スイートを示す。
【０３９５】
ｂ．そうでない場合は、ＳＥＴ及びＳＬＰは、証明書に基づく方法をサポートしなければならない
ｉ．ＳＬＰがＤＣｅｒｔ方法をサポートする場合は、ＳＬＰは以下の項目で応答する
１．ＳｅｒｖｅｒＨｅｌｌｏ、ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅは、ＴＬＳ鍵やり取りアルゴリズムのためのＲＳＡ暗号化を用いる相互にサポートされるＴＬＳ−ＰＳＫ暗号スイートを示す、
２．証明書、
３．ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔ及び
４．ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージ。
【０３９６】
ｉ．そうでない場合は、ＳＥＴが３ＧＰＰ／３ＧＰＰ２  ＳＥＴであり、ＳＬＰがＡＣＡ方法をサポートする場合は、ＳＬＰは次の項目で応答する
１．ＳｅｒｖｅｒＨｅｌｌｏ証明書、ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅは、ＴＬＳ鍵やり取りアルゴリズムのためのＲＳＡ暗号化を用いる相互にサポートされるＴＬＳ暗号スイートを示す、
２．証明書、
３．（ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔメッセージは送信されない）
４．ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージ
３．ＳＥＴが、ＳｅｒｖｅｒＨｅｌｌｏメッセージ及び選択されたものに該当するその他のメッセージを処理し、ＳＥＴに対して暗号スイートを示す
ａ．ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅが、ＧＢＡがＳＬＰによって選択されていることを示す場合は、ＳＥＴ及びＳＬＰは、ＧＢＡプロセスを継続する。詳細は、本書の範囲外である。
【０３９７】
ｂ．そうでない場合は、ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅは、ＴＬＳ鍵やり取りアルゴリズムのためのＲＳＡ暗号化を用いる相互にサポートされるＴＬＳ暗号スイートを示す。
【０３９８】
ｉ．ＳＥＴがＣｅｒｔｉｆｉｃａｔｅ．Ｒｅｑｕｅｓｔを受信した場合は、
１．ＳＥＴがＤＣｅｒｔ方法をサポートする場合は、ＳＥＴは、デバイス証明書を提供し、ＳＥＴ及びサーバがＴＬＳハンドシェイクを完了させる。サーバは、デバイス証明書内のグローバルで一意のＳＥＴデバイスアイデンティティと関連付けられたＳＵＰＬユーザを識別することを試みる。ＳＵＰＬＥユーザは、ＳＥＴデバイスアイデンティティをそれらの加入と関連付けられるべきであることをＳＬＰに対して既にセキュリティが確保された形で検証していることが推定される。
【０３９９】
ａ．ＳＵＰＬユーザが識別されない場合は、セッションを終了させなければならない。ＴＬＳハンドシェイクは既に完了していると推定しているため、サーバは、ＵＬＰ層で通信することが可能である。サーバは、ＵＬＰセッションを終了させるための該当するＵＬＰ誤りメッセージを送信し、次に、ＴＬＳセッションを閉じなければならない。
【０４００】
ｂ．ＳＵＰＬユーザが識別される場合は、サーバは、ＳＵＰＬユーザと同じ権限をＳＥＴに提供する。
【０４０１】
２．そうでない場合は、ＳＥＴは、ＳＬＰに応答し、それがＤＣｅｒｔ方法をサポートしないことを暗黙に示すための空のＣｌｉｅｎｔＣｅｒｔｉｆｉｃａｔｅメッセージを含める。
【０４０２】
ａ．ＳＬＰがＡＣＡをサポートする場合は、ＳＬＰ及びＳＥＴは、ＡＣＡ方法に準拠して継続する。ＳＬＰは、ＡＣＡ方法を用いて継続することができる。
【０４０３】
ｂ．ＳＬＰがＡＣＡ又はＳＬＰ専用方法をサポートしない（ＳＬＰがＤＣｅｒｔ方法のみをサポートしている可能性がある）場合は、ＳＬＰは、該当するＴＬＳ警告メッセージでＴＬＳハンドシェイクを終了させる。
【０４０４】
ｉｉ．サーバがＣｅｒｔｉｆｉｃａｔｅ．Ｒｅｑｕｅｓｔを送信しない場合は、ＳＥＴは、ＡＣＡ方法に準拠して継続する。ＳＬＰは、ＡＣＡ方法又はＳＬＰ専用方法のいずれかを用いて継続することができる。
【０４０５】
３ＧＰＰ２  ＳＥＴは、認証方法の交渉に関して同様の方法を使用し、選択された相違点を有する。
【０４０６】
６．１．３．３  ＷｉＭＡＸ  ＳＥＴ及びＳＬＰのための認証及び鍵再交渉に関する原則（情報用）
鍵再交渉は、次の２つの方法で行うことができる：
１．（位置に基づくサービスのためのＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおいて定義される）位置ルートキーが期限切れのときには、ＳＥＴは、自動的にｗｉｍａｘネットワークとそれ自体を再認証し、ＳＵＰＬによって関連付けられたルート鍵がＳＥＴによって再生成される、又は、
２．ＳＬＰが、ＳＥＫ又は（位置に基づくサービスのためのＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおいて定義される）位置ルートキーが期限切れになっていることに気がつき、ＷｉＭＡＸ  ＡＡＡサーバに新しい鍵を要求する、又は
３．ＳＬＰが、ＴＬＳハンドシェイク中に“ｐｓｋ_ｉｄｅｎｔｉｔｙ_ｕｎｋｎｏｗｎ”ＴＬＳ警告メッセージを送信する。これは、ＳＥＴがｗｉｍａｘネットワークとそれ自体を再認証する必要があり、ＳＵＰＬによって関連付けられたルート鍵がＳＥＴによって再生成される
６．１．３．３．１  認証手順
ＷｉＭＡＸ配備においては、ＰＳＫ  ＴＬＳハンドシェイクは、次のようにＳＥＫを用いて使用することができる：
−  ＣｌｉｅｎｔＨｅｌｌｏメッセージは、１つ以上のＰＳＫに基づく暗号スイートを含むことができる；
−  ＣｌｉｅｎｔＨｅｌｌｏメッセージは、規定されたｓｅｒｖｅｒ_ｎａｍｅＴＬＳ拡張を含むことができ、及び、それは、ＳＬＰのホスト名を含むことができる；
−  ＳｅｒｖｅｒＨｅｌｌｏメッセージは、ＳＬＰによって選択されたＰＳＫに基づく暗号スイートを含むことができる；
−  ＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅをサーバによって送信することができ、及び、それはｐｓｋ_ｉｄｅｎｔｉｔｙ_ｈｉｎｔフィールドを含むことができ、及び、それは、静的ストリング"ＳＵＰＬ  ＷＩＭＡＸブートストラッピング"を含むことができる。
【０４０７】
−  ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅは、ｐｓｋ_ｉｄｅｎｔｉｔｙフィールドを含むことができ、及び、それは、第６．１．２．１．２節において規定される接頭辞"ＳＵＰＬ  ＷＩＭＡＸブートストラッピング"、分離文字"；"及び現在のＢ_ＴＩＤを含むことができる。
【０４０８】
−  ＳＥＴは、ＳＬＰ専用の鍵素材、すなわちＳＥＫ、からＴＬＳプリマスタ秘密を導き出すことができる。
【０４０９】
６．１．３．３．２  認証失敗
認証失敗は、本書の範囲外の文書において説明されるように取り扱うことができる。
【０４１０】
６．１．３．３．３  ブートストラッピングが要求されることの表示
ＴＬＳハンドシェイク中には、ＳＬＰは、ＰＳＫに基づく暗号スイートを含むＳｅｒｖｅｒＨｅｌｌｏメッセージ、及び、静的ストリング"ＳＵＰＬ  ＷＩＭＡＸブートストラッピング"を含むｐｓｋ_ｉｄｅｎｔｉｔｙ_ｈｉｎｔフィールドを含むＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージを送信することによってＳＥＫ鍵を要求することができることをＳＥＴに示すことができる。ＳＥＴが有効なＳＥＫを有さない場合は、これは、ＳＥＴが第６．１．２．１．２節において定義されるように新しいＳＥＫを導き出すようにトリガすることができる。
【０４１１】
６．１．３．３．４  ブートストラッピング再交渉表示
ＴＬＳセッションの使用中に、ＳＬＰは、ｃｌｏｓｅ_ｎｏｔｉｆｙ警告メッセージをＳＥＴに送信することによってＳＥＫが期限切れであることをＳＥＴに示すことができる。ＳＥＴが、旧セッションＩＤを含むＣｌｉｅｎｔＨｅｌｌｏメッセージを送信することによって旧ＴＬＳセッションを再開させることを試みる場合。ＳＬＰは、新しいセッションＩＤを有するＳｅｒｖｅｒＨｅｌｌｏメッセージを送信することによって旧セッションＩＤを使用するのを拒否することができる。これは、ＳＥＴが使用したＳＥＫが期限切れであることをＳＥＴに示す。
【０４１２】
ＴＬＳハンドシェイク中に、ＳＬＰは、ＳＥＴによって送信された終了されたメッセージに応答してｈａｎｄｓｈａｋｅ_ｆａｉｌｕｒｅメッセージを送信することによってＳＥＫが期限切れになっていることをＳＥＴに示すことができる。
【０４１３】
６．１．４  代替クライアント認証（ＡＣＡ）メカニズム
本節は、ＧＳＭ／ＵＭＴＳ及びＣＤＭＡ  ＳＥＴをサポートする配備のみに適用される。
【０４１４】
注：本節全体を通じて、ＳＥＴ_ＩＤは、ＭＳＩＳＤＮ（ＳＥＴが３ＧＰＰベアラネットワーク上にある場合）又はＭＤＮ、ＭＩＮ又はＩＭＳＩのうちの１つ（ＳＥＴが３ＧＰＰ２ベアラネットワーク上にある場合）のいずれかを意味する。
【０４１５】
第６．１．３節は、ＡＣＡに基づく方法をＳＬＰによって選択することができる状況について概説する。ＳＬＰがＴＬＳハンドシェイク中にＡＣＡに基づく方法を選択した場合は、ＳＥＴを認証するためにＳＥＴ_ＩＤ／ＩＰアドレスマッピングに基づくクライアント認証をＳＬＰによって使用することができる。本節の残りの部分では、代替認証メカニズムと呼ばれるこのメカニズムの詳細について説明する。ＳＬＰが代替クライアント認証メカニズムを実装する場合は、ＳＬＰは、ＧＢＡを有するＰＳＫ−ＴＬＳを使用する方法も同様に実装することが推奨される。
【０４１６】
第６．１．１．３節は、いずれのエンティティがＡＣＡに基づく方法をサポートしなければならないか、及びＡＣＡに基づく方法をサポートするエンティティによってサポートしなければならないアルゴリズムについて説明する。情報を提供することを目的として、ここでのこの情報は繰り返しである。
【０４１７】
◆  ベアラネットワークは、ＡＣＡに基づく方法をサポートすることができる。ベアラネットワークは、Ｈ−ＳＬＰがベアラネットワークの加入者のためにＡＣＡに基づく方法をサポートすることを希望する場合はＡＣＡに基づく方法をサポートしなければならない。
【０４１８】
◆  ＳＬＰは、ＡＣＡに基づく方法をサポートすることができる。
【０４１９】
◆  ＧＳＭ／ＵＭＴＳ及びＣＤＭＡ  ＳＥＴハンドセットは、ＡＣＡに基づく方法をサポートしなければならない。
【０４２０】
◆  ＡＣＡに基づく方法は、ＳＥＴ  ＵＩＣＣ／ＵＩＭ／ＳＩＭ／ＵＳＩＭは含まない。
【０４２１】
◆  ＡＣＡに基づく方法は、ＳＰＣエンティティは含まない。
【０４２２】
代替クライアント認証をサポートするＳＥＴは、証明書に基づくサーバ（ＳＬＰ）認証を用いるＴＬＳ１．１もサポートしなければならない。さらに、ＳＥＴには、それがＳＬＰサーバ証明書を検証するのを可能にするルート証明書をプロビジョニングしなければならない。ルート証明書をＳＥＴにプロビジョニングするための様々な異なる方法が存在するため、本明細書では特定のメカニズムは定義されていない。ＳＵＰＬオペレータは、ＴＬＳ１．１が代替クライアント認証のために使用されるときには該当するルート証明書がＳＥＴ内に存在することを確認する必要がある。
【０４２３】
代替クライアント認証をサポートするＳＬＰは、ＴＬＳ１．１をサポートしなければならず、及び、有効なＴＬＳサーバ証明書を有していなければならず、それは、代替クライアント認証を実装するＳＥＴによって検証することができる。
【０４２４】
代替クライアント認証（ＡＣＡ）メカニズムは、ＳＬＰがＳＥＴに割り当てられたＳＥＴ_ＩＤへのＳＥＴのＩＰアドレスのバインディングを検査することができるメカニズムである。ＡＣＡメカニズムが実装される場合は、ＳＬＰは、ＳＥＴから受信されたＳＵＰＬメッセージのソースＩＰアドレスを、ＳＥＴにアドレッシングするためにＳＬＰによって用いられるＳＥＴ_ＩＤにマッピングすることができなければならない。ＳＬＰがＡＣＡメカニズムを使用するためには、ベアラネットワークは、ベアラレベルでのＩＰアドレススプーフィング（ｓｐｏｏｆｉｎｇ）を防止しなければならない。ソースＩＰアドレスとＳＥＴのＳＥＴ_ＩＤとの間での成功裏のマッピングは、ベアラネットワークにおいてＳＥＴがセキュアな形で識別されている（すなわち、認証されている）ことを意味する。この解決方法は、ＳＥＴにおける特定のクライアント（ＳＥＴ）認証の実装は要求しないが、ＳＬＰがベアラからの特定のＳＥＴ_ＩＤのための正確なソースＩＰアドレスを取得するのをサポートすることを要求する。
【０４２５】
３ＧＰＰベアラ特有の課題：ソースＩＰアドレスの取得は、すべてのケースで可能であるわけではない−例えば、ホームネットワークではなく訪れたネットワークにおけるＧＧＳＮを用いたＧＰＲＳローミングアクセスの場合である。従って、代替クライアント認証メカニズムは、ホームネットワークがソースＩＰアドレスを割り当てるか又はそれへのアクセスを有するときのみ、例えば、ＳＥＴがホームネットワークでＧＧＳＮを使用することが要求されるときのＧＰＲＳアクセスの場合、に依存すべきである。
【０４２６】
３ＧＰＰ２ベアラ特有の課題：ソースＩＰアドレスの取得は、すべてのケースで可能であるわけではない−例えば、訪れたネットワーク内において単純なＩＰ又はＭＩＰアドレスを用いるローミングＨＲＰＤアクセスの場合である。従って、代替クライアント認証メカニズムは、ホームネットワークがソースＩＰアドレスを割り当てるか又はそれへのアクセスを有するときのみ、例えば、ＳＥＴがホームネットワークでＨＡへのＭＩＰを使用することが要求されるときのＨＲＰＤアクセスの場合、に依存すべきである。
【０４２７】
第６．１．４．１．節は、このメカニズムがＳＵＰＬ３．０でのクライアント認証のためにどのようにして使用されるかを説明する。
【０４２８】
ＳＵＰＬ  ＩＮＩＴを転送するためにＵＰＤ／ＬＰが使用される事例では、ＳＬＰは、最初に、ＳＥＴ_ＩＤを用いてＳＥＴ  ＩＰアドレスに関してベアラネットワークに問い合わせることによって又はＩＰアドレスを用いてＳＥＴ_ＩＤに関してベアラネットワークに問い合わせることによってＩＰアドレスを検証することができる。
【０４２９】
６．１．４．１  ＡＣＡ手順
ネットワークによって開始されるシナリオ：ＳＬＰからＳＵＰＬ  ＩＮＩＴメッセージを受信後に、（及び本書の別の場所で説明されるように該当するセキュリティメカニズム及び通知／検証を適用後に）、ＳＥＴは、対応するＳＵＰＬセッションを継続する権限が付与され、第６．１．１．４節において説明されるように、既存の、オープンな相互に認証されたＴＬＳセッションが使用されるべきであるか、又は前回の再開可能なＴＬＳセッションを再開させることができる。オープンなＴＬＳセッションがないか又はＳＥＴ又はＳＬＰがセッションを再開させないことを選択した場合は、ＳＥＴ及びＳＬＰは、新しいＴＬＳセッションを要求し、ＳＥＴ及びＳＬＰは、認証方法を交渉するために第６．１．３節で説明される該当するステップを実施する。
【０４３０】
次のステップは、ネットワークによって開始されるシナリオにおいてＳＥＴを認証するために代替クライアント認証メカニズムが適用されるときにＳＬＰによって使用される：
１．ＳＵＰＬ  ＩＮＩＴメッセージは、ＳＥＴ_ＩＤを供給したＭＬＰ要求に応答して送信されたことに注目すること。ＳＬＰが、ＭＬＰ要求のためのＳＬＰセッションＩＤを割り当て、ＳＵＰＬ  ＩＮＩＴを送信する。ＳＬＰが、ＳＬＰセッションＩＤを用いてＳＥＴからの応答をＭＬＰからの要求と関連付ける。しかしながら、ＳＬＰは、最初に、応答しているＳＥＴが正確なＳＥＴ_ＩＤに対応することを検証しなければならない。残りのステップではこの認証プロセスについて説明する。
【０４３１】
２．ＳＥＴが、ＳＬＰとのＴＬＳ１．１セッションを確立する。ＳＥＴは、ＳＬＰによって提示されたＴＬＳサーバ証明書がＳＥＴにおいて設定されたＳＬＰのＦＱＤＮにバインドされていることを検査しなければならない。
【０４３２】
３．ＳＬＰが、（ＳＵＰＬ  ＩＮＩＴに応答した）ＳＥＴからの最初のＳＵＰＬメッセージ内のＳＬＰセッションＩＤがＳＬＰによって割り当てられた現在有効なＳＬＰセッションＩＤに対応するかどうかを決定する。最初のＳＵＰＬメッセージ内のＳＬＰセッションＩＤが有効なＳＬＰセッションＩＤに対応しない場合は、ＳＬＰは、該当するメッセージを用いてＳＵＰＬセッションを終了する。そうでない場合は、ＳＬＰは、対応するＳＥＴ  ＩＤを注記する。
【０４３３】
４．ＳＥＴからの最初のＳＵＰＬメッセージ（ＳＵＰＬ  ＰＯＳ  ＩＮＩＴ、ＳＵＰＬ  ＳＴＡＲＴ、ＳＵＰＬ  ＡＵＴＨ  ＲＥＱＵＥＳＴ、ＳＵＰＬ  ＴＲＩＧＧＥＲＥＤ  ＳＴＡＲＴ、ＳＵＰＬ  ＲＥＰＯＲＴ又はＳＵＰＬ  ＥＮＤ）に応答する前に、ＳＬＰは、ＳＥＴのＳＥＴ_ＩＤを検証しなければならない。これを達成する方法は次の２つである。
【０４３４】
ａ．ＳＥＴ_ＩＤを要求する。
【０４３５】
ｉ．ＳＬＰが、ＳＥＴによって使用されるソースＩＰアドレスを用いて現在のＳＥＴ_ＩＤを見つけ出すために根本のベアラネットワークに問い合わせる。
【０４３６】
１．ＳＥＴによって送信された最初のＳＵＰＬメッセージのソースＩＰアドレスに関してベアラから有効なＳＥＴ_ＩＤが戻された場合は、ＳＬＰは、戻されたＳＥＴ_ＩＤが正確なＳＥＴ_ＩＤと内部で関連付けられていることを検査する（ステップ３参照）。この検査が不合格である場合は、ＳＬＰは、該当するメッセージを用いてＳＵＰＬセッションを終了する。そうでない場合は、ＳＥＴは真正であるとみなされ、ＳＬＰはＳＵＰＬセッションを継続する。
【０４３７】
２．有効なＳＥＴ_ＩＤを見つけることができない場合は、ＳＬＰは、該当するＳＵＰＬ誤りメッセージを用いてＳＵＰＬセッションを終了しなければならない。
【０４３８】
ｂ．ＩＰアドレスを要求する
ｉ．ＳＬＰが、このＳＥＴ_ＩＤと関連付けられたＳＥＴによって使用中のソースＩＰアドレスを見つけ出すために根本のベアラネットワークに問い合わせる（ステップ３参照）。
【０４３９】
１．ベアラネットワークがＩＰアドレスを戻した場合は、ＳＬＰは、このＩＰアドレスが最初のＳＵＰＬメッセージのソースＩＰアドレスに対応するかどうかを検査する。この検査が不合格である場合は、ＳＬＰは、該当するＳＵＰＬメッセージを用いてＳＵＰＬセッションを終了する。そうでない場合は、ＳＥＴは真正であるとみなされ、ＳＬＰはＳＵＰＬセッションを継続する。
【０４４０】
２．ＩＰアドレスを見つけることができない場合は、ＳＬＰは、該当するＳＵＰＬ誤りメッセージを用いてＳＵＰＬセッションを終了しなければならない。
【０４４１】
注：ベアラネットワークは、ＳＥＴ_ＩＤ／ＩＰアドレスのバインディングを得るためにステップ４における２つのタイプの問い合わせ（ＩＰアドレスを要求する又はＳＥＴ_ＩＤを要求する）のうちの１つのみをサポートすることができる。ＳＬＰは、ベアラネットワークによってサポートされる方法を順守する責任を有する。
【０４４２】
ＳＥＴによって開始されるシナリオ：ＳＥＴがＳＵＰＬセッションを開始することを希望する場合は、第６．１．１．４節において説明されるように、既存の、オープンな相互に認証されたＴＬＳセッションが使用されるべきであるか、又は前回の再開可能なＴＬＳセッションを再開させることができる。オープンなＴＬＳセッションがないか又はＳＥＴ又はＳＬＰがセッションを再開させないことを選択した場合は、ＳＥＴ及びＳＬＰは、新しいＴＬＳセッションを要求し、ＳＥＴ及びＳＬＰは、認証方法を交渉するために第６．１．３節で説明される該当するステップを実施する。
【０４４３】
次のステップは、ＳＥＴによって開始されるシナリオにおいてＳＥＴを認証するために代替クライアント認証メカニズムが適用されるときにＳＬＰによって使用される：
１．ＳＥＴが、ＳＬＰとのＴＬＳ１．１セッションを確立する。ＳＥＴは、ＳＬＰによって提示されたＴＬＳサーバ証明書がＳＥＴにおいて設定されたＳＬＰのＦＱＤＮにバインドされていることを検査しなければならない。
【０４４４】
２．最初のＳＵＰＬメッセージ（例えば、ＳＵＰＬ  ＳＴＡＲＴ、ＳＵＰＬ  ＴＲＩＧＧＥＲＥＤ  ＳＴＡＲＴ）に応答する前に、ＳＬＰは、ＳＥＴのＳＥＴ_ＩＤを検証しなければならない。これを達成する方法は次の２つである。
【０４４５】
ａ．ＳＥＴ_ＩＤを要求する。
【０４４６】
ｉ．ＳＬＰが、ＳＥＴによって使用されるソースＩＰアドレスを用いて現在のＳＥＴ_ＩＤを見つけ出すために根本のベアラネットワークに問い合わせる。
【０４４７】
１．ＳＥＴによって送信された最初のＳＵＰＬメッセージのソースＩＰアドレスに関してベアラから有効なＳＥＴ_ＩＤが戻された場合は、ＳＬＰは、戻されたＳＥＴ_ＩＤがＳＥＴによって提供されたものと同じであるかどうかを検査する。この検査が不合格である場合は、ＳＬＰは、該当するメッセージを用いてＳＵＰＬセッションを終了する。そうでない場合は、ＳＥＴは真正であるとみなされ、ＳＬＰはＳＵＰＬセッションを継続する。
【０４４８】
２．有効なＳＥＴ_ＩＤを見つけることができない場合は、ＳＬＰは、該当するＳＵＰＬ誤りメッセージを用いてＳＵＰＬセッションを終了しなければならない。
【０４４９】
ｂ．ＩＰアドレスを要求する
ｉ．ＳＬＰが、このＳＥＴ_ＩＤと関連付けられたＳＥＴによって使用中のソースＩＰアドレスを見つけ出すために根本のベアラネットワークに問い合わせる。
【０４５０】
１．ベアラネットワークがＩＰアドレスを戻した場合は、ＳＬＰは、このＩＰアドレスが最初のＳＵＰＬメッセージのソースＩＰアドレスに対応するかどうかを検査する。この検査が不合格である場合は、ＳＬＰは、該当するメッセージを用いてＳＵＰＬセッションを終了する。そうでない場合は、ＳＥＴは真正であるとみなされ、ＳＬＰはＳＵＰＬセッションを継続する。
【０４５１】
２．ＩＰアドレスを見つけることができない場合は、ＳＬＰは、該当するＳＵＰＬ誤りメッセージを用いてＳＵＰＬセッションを終了しなければならない。
【０４５２】
注：ＳＬＰによって開始されるシナリオ及びＳＥＴによって開始されるシナリオの両方において、ＳＬＰは、ＳＥＴ_ＩＤを現在使用中のソースＩＰアドレスにバインドさせるためにベアラネットワークに該当する問い合わせを送信することによってＳＥＴを再認証することができる。これが有用であることが可能な様々な状況が存在し、例えば、（Ａ）ＳＥＴのＩＰアドレスがＴＬＳセッション中に変わった場合は、ＳＬＰは、ＳＥＴ_ＩＤが新しいＩＰアドレスと関連付けられていることを確認するためにベアラネットワークに該当する問い合わせを送信することができる、（Ｂ）ＴＬＳセッションを再開するときには、ＳＬＰは、第６．１．１．４節において説明されるように前回のＴＬＳセッションを再使用してそれによって計算を節約することができ、ＳＥＴを認証するために単にベアラネットワークに該当する問い合わせを送信するだけであることができる。この方法でＳＥＴを再認証することは、ＳＥＴ自体との対話は含まないことに注目すること。
【０４５３】
６．２  Ｅ−ＳＬＰに適用可能な認証メカニズム
６．２．１  緊急サービス規制当局に関して
ＳＵＰＬ３．０緊急ＳＵＰＬセッションは、（ＳＵＰＬを用いて）ネットワークによって開始させること又はＳＥＴによって開始させることができる。所管の緊急サービス規制当局は、これらの緊急セッションのためのサポートを要求する：
・  所管の緊急サービス規制当局は、ネットワークによって開始されるセッション及びＳＥＴによって開始されるセッションのいずれに関してもサポートを要求することはできない；
・  所管の緊急サービス規制当局は、ネットワークによって開始されるセッションのみを要求することができる；
・  所管の緊急サービス規制当局は、ＳＥＴによって開始されるセッションのみを要求することができる；
・  所管の緊急サービス規制当局は、ネットワークによって開始されるセッション及びＳＥＴによって開始されるセッションの両方に関するサポートを要求することができる。
【０４５４】
６．２．２  緊急セッション中のＳＵＰＬリソースの優先順位設定
ＳＥＴでの緊急ＳＵＰＬセッションの継続期間中には、ＳＥＴにおけるすべてのＳＵＰＬリソースがその緊急セッションのために利用可能でなければならない。従って、
・  ＳＥＴが緊急ＳＵＰＬセッションを開始するときには、非緊急セッションに関連するあらゆるＳＵＰＬ通信をＳＥＴによって直ちに終了させなければならない。この時点で非緊急ＳＵＰＬ  ＩＮＩＴメッセージをＳＥＴによって処理中（例えば、ＭＡＣを検証させる又はユーザの許可を得る）である場合は、それらのプロセスは打ち切ることができ、ＳＵＰＬ  ＩＮＩＴメッセージを廃棄することができる。
【０４５５】
・  ＳＥＴが緊急ＳＵＰＬセッション中に非緊急ＳＵＰＬ  ＩＮＩＴメッセージを受信した場合は、これらのＳＵＰＬ  ＩＮＩＴメッセージは廃棄することができる。
【０４５６】
６．２．３  Ｅ−ＳＬＰ  ＦＱＤＮ
ネットワークによって開始される緊急ＳＵＰＬセッションでは、Ｅ−ＳＬＰのＦＱＤＮは次の通りであることができる：
１．ＳＵＰＬ  ＩＮＩＴにおいてＥ−ＳＬＰアドレスとしてＳＥＴに提供されたＦＱＤＮ。Ｅ−ＳＬＰ  ＦＱＤＮは、フォーマット"ｅ−ｓｌｐ．ｘｘｘ．ｘｘｘ．ｘｘｘ．ｘｘｘ．ｘｘｘ"を有することができ、ここで、"ｘｘｘ"は、あらゆる有効なストリングであることができる。
【０４５７】
２．ＳＵＰＬ  ＩＮＩＴにおいてＦＱＤＮが提供されない場合は、プロビジョニングされたＨ−ＳＬＰアドレスを使用することができる。
【０４５８】
３．上記の１又は２に従ってＦＱＤＮを入手可能でない場合は、ＦＱＤＮは、以下の３つの代替のうちの１つをデフォルトとすることができる：
−  （３ＧＰＰベアラネットワークに接続される場合）ＦＱＤＮが明
示で提供されない場合“ｅ−ｓｌｐ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．ｐｕｂ．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ”。この場合は、ＭＣＣ及びＭＮＣは、サービスを提供する３ＧＰＰネットワークに対応する。
【０４５９】
−  （３ＧＰＰ２ベアラネットワークに接続される場合）ＦＱＤＮが明示で提供されない場合“ｅ−ｓｌｐ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．ｐｕｂ．３ｇｐｐ２ｎｅｔｗｏｒｋ．ｏｒｇ”。この場合は、ＭＣＣ及びＭＮＣは、サービスを提供する３ＧＰＰ２ネットワークに対応する。
【０４６０】
−  （ＷｉＭＡＸベアラネットワークに接続される場合）"ｅ−ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ"。ここで、ｏｐｅｒａｔｏｒ．ｃｏｍは、Ｈ−ＳＬＰオペレータのＦＱＤＮである。
【０４６１】
ＳＥＴによって開始される緊急ＳＵＰＬセッションでは、Ｅ−ＳＬＰのＦＱＤＮは、次の優先順であることができる。
【０４６２】
１．（該当する場合）所管の緊急サービス規制当局によって要求されたＦＱＤＮ。
【０４６３】
２．ローカルアクセスネットワークによって又はＨ−ＳＬＰによって検証されたその他の手段によって提供されたＦＱＤＮ。
【０４６４】
３．Ｈ−ＳＬＰによって提供されたＦＱＤＮ。
【０４６５】
６．２．４．  緊急ＳＵＰＬ  ＩＮＩＴメッセージの処理
ＳＵＰＬ  ＩＮＩＴメッセージのＳＥＴに基づく完全性検証及びメッセージ源認証はＥ−ＳＬＰによって使用されない。従って、緊急ＳＵＰＬ  ＩＮＩＴにおけるＭＡＣフィールドは埋めてはならない。
【０４６６】
緊急呼中には、ＳＥＴは、緊急ＳＵＰＬ  ＩＮＩＴメッセージのエンド−ツー・エンド保護を適用することができない。
【０４６７】
Ｅ−ＳＬＰホワイトリスト（ｗｈｉｔｅｌｉｓｔ）の使用によって何らかの保護が提供される。Ｅ−ＳＬＰホワイトリストは、ＳＥＴの現在の位置推定値（例えば、ＣｅｌｌＤ及び／又はＮｅｔｗｏｒｋＩＤ）に基づく。Ｅ−ＳＬＰホワイトリストは、ＳＥＴが受信された緊急ＳＵＰＬ  ＩＮＩＴメッセージを処理すべき順序を決定するためにＳＥＴによって使用される。すなわち、Ｅ−ＳＬＰホワイトリストは、緊急ＳＵＰＬ  ＩＮＩＴメッセージを廃棄するためには使用することができない。
【０４６８】
６．２．４．１  Ｅ−ＳＬＰホワイトリスト
エンド−ツー−エンドでセキュリティが確保されていないチャネルで緊急ＳＵＰＬ  ＩＮＩＴメッセージが受信された場合は（例えば、ＳＭＳ又はＯＭＡ  Ｐｕｓｈ又はＵＤＰ／ＩＰ）、緊急ＳＵＰＬ  ＩＮＩＴメッセージは偽物であるか又は変更されているおそれがある。本節の残りの部分では、ＳＥＴが可能な限り速やかに真正のＥ−ＳＬＰサーバに確実に接触できるようにするためのセキュリティ対策について説明する。
【０４６９】
注：規制上の要件では、ＳＥＴが緊急ＳＵＰＬ  ＩＮＩＴメッセージを受け入れて処理すべき条件を規定する。例えば、多くの事例では、規制上の要件は、ＳＥＴが緊急呼に現在従事している場合に緊急ＳＵＰＬ  ＩＮＩＴメッセージを受け入れて処理することをＳＥＴに要求するだけである。従って、（ＳＥＴが緊急ＳＵＰＬ  ＩＮＩＴメッセージを受け入れて処理すべき）条件は、本書の範囲外である。
【０４７０】
ＳＥＴが緊急ＳＵＰＬ  ＩＮＩＴメッセージを受信したときには、ＳＥＴは、最初に、（ＳＥＴが緊急ＳＵＰＬ  ＩＮＩＴメッセージを受け入れるべき）条件が現在満たされていることを検証しなければならない。それらの条件が満たされていない場合は、ＳＥＴは、ＳＵＰＬ  ＩＮＩＴメッセージを無視することができる。ここからの説明では、ＳＥＴが緊急ＳＵＰＬ  ＩＮＩＴメッセージを受信したときにそれらの条件が満たされていたと仮定する。
【０４７１】
注：攻撃者は、ＳＥＴが真正の緊急ＳＵＰＬ  ＩＮＩＴメッセージをまさに予想しているときに複数の（偽の）緊急メッセージをＳＥＴに送信する可能性がある。いずれの緊急ＳＬＰからの緊急ＳＵＰＬ  ＩＮＩＴメッセージを予想すべきであるをＳＥＴに対して（事前に）伝えることができないケースが存在することがある。この攻撃が動機となって次の手順が設けられている。
【０４７２】
"受け入れ及び処理"条件が満たされている期間中は、ＳＥＴは、緊急ＳＵＰＬ  ＩＮＩＴメッセージがＥ−ＳＬＰに関する予想外のアドレスを記載している場合でも受信された緊急ＳＵＰＬ  ＩＮＩＴメッセージを削除してはならない。条件がもはや満たされていないとＳＥＴが決定した時点で（例えば、正確なＥ−ＳＬＰに接触されているか又は緊急呼後に十分な時間が経過している時点で）、ＳＥＴは、あらゆる受信された緊急ＳＵＰＬ  ＩＮＩＴメッセージを暗黙に廃棄しなければならない。
【０４７３】
（"受け入れ及び処理"条件が依然として満たされている間に）ＳＥＴが偽の緊急ＳＵＰＬ  ＩＮＩＴメッセージを受信し、受け入れ及び処理する場合は、ＳＥＴは、緊急ＳＵＰＬ  ＩＮＩＴメッセージ内で示されているＥ−ＳＬＰに接触するのを試みるまでは緊急ＳＵＰＬ  ＩＮＩＴメッセージが偽物であるという表示を受信できないことがある。この表示は、Ｅ−ＳＬＰがＳＵＰＬセッションを拒否したときに発生する。このプロセスは即時的ではなく、このため、ＳＥＴが２つ以上の緊急ＳＵＰＬ  ＩＮＩＴメッセージを受信した場合は緊急ＳＵＰＬ  ＩＮＩＴメッセージを待ち行列に入れることが必要な場合がある。
【０４７４】
Ｅ−ＳＬＰホワイトリストは、ＳＥＴが緊急ＳＵＰＬ  ＩＮＩＴメッセージを受信するのを予想することが可能なＥ−ＳＬＰ  ＦＱＤＮのリストを含む。ＳＥＴは、ホワイトリスト上に存在するＥ−ＳＬＰ  ＦＱＤＮを含む緊急ＳＵＰＬ  ＩＮＩＴメッセージが、ホワイトリスト上に存在しないＥ−ＳＬＰ  ＦＱＤＮを含む緊急ＳＵＰＬ  ＩＮＩＴメッセージの前に確実に処理されるようにするためにＥ−ＳＬＰホワイトリストを使用する。
【０４７５】
例：ホワイトリスト上のＥ−ＳＬＰ  ＦＱＤＮを含む緊急ＳＵＰＬ  ＩＮＩＴメッセージは、ホワイトリスト上に存在しないＥ−ＳＬＰ  ＦＱＤＮを含む緊急ＳＵＰＬ  ＩＮＩＴメッセージの前に確実に処理されるようにするために緊急ＳＵＰＬ  ＩＮＩＴ待ち行列において前方に進められる。Ｅ−ＳＬＰホワイトリストに記載されているかどうかは、緊急ＳＵＰＬ  ＩＮＩＴ待ち行列の順序を設定するための第１の判定基準である。第２の判定基準は、到着時間であり、先入れ先出し方式を使用する：
・  ＳＥＴがＳＥＴの現在位置に関する現在のＥ−ＳＬＰホワイトリストを有する場合は、ＳＥＴは、待ち行列の順序を設定するために両方の判定基準を使用する。
【０４７６】
・  ＳＥＴがＳＥＴの現在位置に関する現在のＥ−ＳＬＰホワイトリストを有しない場合は、ＳＥＴは、待ち行列の順序を設定するために先入れ先出し方式を使用する。
【０４７７】
６．２．４．３  緊急ＳＵＰＬ  ＩＮＩＴメッセージに関する手順
エンド・ツー・エンドでセキュリティが確保されているチャネルで緊急ＳＵＰＬ  ＩＮＩＴが受信された場合は（例えば、セキュアなＳＩＰ  Ｐｕｓｈ）、
緊急ＳＵＰＬ  ＩＮＩＴメッセージは、直ちに処理することができる。この場合は、本小節の残りの考慮事項は無視される。
【０４７８】
エンド・ツー・エンドでセキュリティが確保されていないチャネルで緊急ＳＵＰＬ  ＩＮＩＴメッセージが受信された場合は（例えば、ＳＭＳ又はＯＭＡ  Ｐｕｓｈ又はＵＰＤ／ＩＰ）、そのメッセージは、第６．２．４．１節に従って待ち行列に入れられる。ＳＥＴは、待ち行列内のメッセージ内を進行し、応答するためにＥ−ＳＬＰに接続するのを試みる前に該当する検証及び通知を適用する。
【０４７９】
ＳＥＴは、ＳＵＰＬ  ＩＮＩＴメッセージに応答して、関連付けられたＥ−ＳＬＰ（第６．２．３節参照）とセキュアなＴＬＳセッション（第６．２．５節参照）を確立することができ、次のうちの１つが生じる。
【０４８０】
◆  ＳＥＴを認証後に（第６．２．５節参照）、Ｅ−ＳＬＰがＳＥＴを未終了状態のＳＵＰＬセッションと関連付けることができない場合は、Ｅ−ＳＬＰは、そのセッションを終了させることができる。ＴＬＳハンドシェイクがまだ完了していない場合は、Ｅ−ＳＬＰは、不必要な計算を節約するために、ＴＬＳ誤りメッセージを用いてセッションを終了させるべきである。ＴＬＳハンドシェイクが完了している場合は、Ｅ−ＳＬＰは、ＳＵＰＬ誤りメッセージを用いてセッションを終了させ、ＳＥＴに権限が付与されていないことを示すことができる。ＳＥＴは、いずれの形式の誤りメッセージも、ＳＵＰＬ  ＩＮＩＴメッセージが不正なものであることを示すと解釈することができる。次に、ＳＥＴは、待ち行列内の優先順位に従って次のＳＵＰＬＩＮＩＴメッセージに進んだ。
【０４８１】
◆  ＳＥＴを認証後に（第６．２．５節参照）、Ｅ−ＳＬＰがＳＥＴを未終了状態のＳＵＰＬセッションと関連付けることができる場合は、ＳＥＴ及びＥ−ＳＬＰは、通常通り継続する。
【０４８２】
ＳＥＴは、真正のメッセージが見つかるまで緊急ＳＵＰＬ  ＩＮＩＴメッセージに応答し続ける。ＳＥＴは、正しいＥ−ＳＬＰがいったん識別された時点であらゆる新しい又は待ち行列内のＳＵＰＬ  ＩＮＩＴメッセージを廃棄することができる。正しいＥ−ＳＬＰからの新しい又は待ち行列内のＳＵＰＬ  ＩＮＩＴメッセージはまだ処理することができる。
【０４８３】
次の２つの注記は、規制当局が考慮することを希望する提案である。
【０４８４】
注：正しいＥ−ＳＬＰがいったん識別された時点で、ＳＥＴは、ＳＵＰＬセッションが成功裏に完了するまでこの正しいＥ−ＳＬＰのＦＱＤＮを必ず覚えているべきである。Ｅ−ＳＬＰとのＴＬＳセッションの終了が早すぎる場合（例えば、データの接続性が失われた場合）は、ＳＥＴは、ＳＵＰＬセッションが成功裏の完了まで継続することができるようにＴＬＳセッションが再確立されるまでＥ−ＳＬＰとのＴＬＳセッションを再確立するのを試み続けるべきである。幾つかの状況においては、ＳＥＴがＴＬＳセッションを数回再確立することが考えられる。ＳＥＴがＴＬＳセッションを再確立することに成功していない場合は、ＳＥＴは、それにもかかわらず試み続けるべきである。これは緊急的な状況であるため、成功することの利益の方がバッテリ切れのコストよりも重要である。
【０４８５】
注：認証後であるがＳＵＰＬセッションの成功裏の完了前にＥ−ＳＬＰがＳＥＴとの接触を絶った場合は、Ｅ−ＳＬＰは、ＳＥＴが接触を再確立してＳＵＰＬセッションを完了させることができることに望みをかけてＳＵＰＬセッションをオープン状態にすべきである。
【０４８６】
６．２．５  緊急セッションのための認証
注：Ｅ−ＳＬＰによってサポートすることができる相互認証方法が第６．１．１．３節に示されている。ＳＥＴ及びＥ−ＳＬＰは、第６．１．３節において規定されるように、ＴＬＳハンドシェイク中に相互認証方法に関して交渉する。
【０４８７】
緊急セッションに関する優先順位は次の通りである。
【０４８８】
・  ＧＢＡ又はＳＥＫ方法：第１位
・  ＤＣｅｒｔ方法：第２位
・  ＡＣＡ方法：第３位
・  ＳＬＰ専用方法：最下位。ＳＬＰ専用方法は最後の手段であるとみるべきである。
【０４８９】
すべてのこれらのケースに関するＥ−ＳＬＰのＦＱＤＮが第６．２．３節で説明されている。
【０４９０】
ＧＢＡに基づく方法（３ＧＰＰ／３ＧＰＰ２  ＳＥＴのみ）：ＳＥＴ及びＥ−ＳＬＰは、第６．１．３節において説明されるようにＧＢＡを用いてＰＳＫ−ＴＬＳを行うことができ、Ｅ−ＳＬＰがＮＡＦとして行動する。特定のＳＥＴに関してＥ−ＳＬＰによって入手されたＫｓ_ＮＡＦは、ホームネットワークオペレータによって設定された寿命の間ＳＥＴアイデンティティ（例えば、ＩＭＳＩ、ＭＳＩＳＤＮ）と関連付けて保持することができる。
【０４９１】
ＳＥＫに基づく方法（ＷｉＭＡＸ  ＳＥＴのみ）：ＳＥＴ及びＥ−ＳＬＰは、第６．１．３節において説明されるようにＳＥＫを用いるＰＳＫ−ＴＬＳを用いて相互認証を行うことができ、Ｅ−ＳＬＰはＨ−ＳＬＰと同様に行動する。Ｅ−ＳＬＰのＦＱＤＮは第６．２．３節で説明されている。特定のＳＥＴに関してＥ−ＳＬＰによって入手されたＳＥＫは、ホームネットワークオペレータによって設定された寿命の間ＳＥＴアイデンティティ（例えば、ＷｉＭＡＸユーザＩＤ）と関連付けて保持することができる。
【０４９２】
ＤＣｅｒｔ方法（全ＳＥＴ）：ＳＥＴ及びＥ−ＳＬＰは、第６．１．２．２．１節において説明されるようにＤＣｅｒｔ方法を用いた相互認証を行うことができる。ＳＥＴは、ＳＥＴに含まれるＥ−ＳＬＰのルート証明書及び第６．２．３節において定義されるＥ−ＳＬＰのＦＱＤＮを用いてＥ−ＳＬＰを認証することができる。
【０４９３】
ＡＣＡに基づく方法（３ＧＰＰ／３ＧＰＰ２  ＳＥＴ  対応するベアラネットワーク上にある間のみ）：ＰＳＫ−ＴＬＳを用いるＧＢＡ及びＤＣｅｒｔ方法の両方がＥ−ＳＬＰにおいてサポートされていないＳＵＰＬ３．０実装に関して、第６．１．４節において定義される代替クライアント認証メカニズムをサポートすることができ、次の相違点が存在する。Ｅ−ＳＬＰは、ＳＥＴによって用いられるＩＰアドレスを、サービングネットワークによって−例えば、３ＧＰＰネットワークにおける、又は３ＧＰＰ２ネットワークにおけるＬＲＦ又はＥ−ＣＳＣＦによって、Ｅ−ＳＬＰに提供されたＳＥＴのためのＩＰアドレスとバインドさせることによってＳＥＴを認証することができる。
【０４９４】
・ネットワークによって開始されるセッション：ＳＥＴ  ＩＰアドレスは、あらゆる緊急ＶｏＩＰ呼を開始するために使用され、及び、ＳＵＰＬが呼び出される前にサービングネットワークによって検証することができるため、それは、Ｅ−ＳＬＰによって信頼できるとみなすことができる。回線モードで開始された緊急呼の場合は、ＳＥＴ  ＩＰアドレスはサービングネットワークに知られていないことがあり（例えば、ホームネットワークによって割り当てることができる）、その場合は、サービングネットワークによってＥ−ＳＬＰにＩＰアドレスを提供することができず及びのちにＳＥＴから受信されたときにＩＰアドレスを検証することができない。
【０４９５】
・ＳＥＴによって開始されるセッション：ＡＣＡ方法を使用するために、サービングベアラネットワークは、ベアラレベルでのＩＰアドレスのスプーフィングを防止しなければならない。ＡＣＡ方法は、ＳＥＴがベアラネットワークにおいて認証されたとして登録されているどうかにかかわらず適用することができる。これは、ＳＥＴ内に起動されたＳＩＭ／ＵＳＩＭ／ＵＩＣＣ／（Ｒ）ＵＩＭが存在しない場合をサポートする。
【０４９６】
ＳＬＰ専用方法（全ＳＥＴ）：その他のいずれの認証方法も使用できない場合は、ＳＥＴは、ＳＬＰ専用方法を用いてＥ−ＳＬＰへのセキュアなＩＰコネクションを確立することができる。ＳＥＴは、ＳＥＴに含まれるＥ−ＳＬＰのルート証明書及び第６．２．３節において定義されるＥ−ＳＬＰのＦＱＤＮを用いてＥ−ＳＬＰを認証することができる。相互認証を行う能力は、セッションがＳＥＴによって開始されるか又はネットワークによって開始されるかに依存する。
【０４９７】
・  ネットワークによって開始されるセッション：ＳＵＰＬセッションがネットワークによって開始される場合は、Ｅ−ＳＬＰは、（例えば）第６．２．６節において説明されるようにセッションＩＤ及びＳＵＰＬ  ＩＮＩＴの受信されたハッシュに基づいてＳＥＴの弱い認証をすることができる。
【０４９８】
・  ＳＥＴによって開始されるセッション：ＳＵＰＬセッションがＳＥＴによって開始される場合
ＳＬＰ専用方法は、ＳＥＴがベアラネットワークにおいて認証されたとして登録されているどうかにかかわらず適用できることが注目されるべきである。これは、ＳＥＴ内に起動されたＳＩＭ／ＵＳＩＭ／ＵＩＣＣ／（Ｒ）ＵＩＭが存在しない場合をサポートする。
【０４９９】
６．２．６  緊急ＳＵＰＬセッションに関するＳＵＰＬ  ＩＮＩＴの完全性保護
Ｅ−ＳＬＰが第６．２．５節において説明されるようにＳＥＴを認証することができ、及び、Ｅ−ＳＬＰがＳＥＴを未終了状態のＳＵＰＬセッションと関連付けることができる場合は、Ｅ−ＳＬＰは、ＳＵＰＬ  ＩＮＩＴメッセージが変更されたかどうかを検査する。ＳＵＰＬ  ＩＮＩＴメッセージが変更されたことをＥ−ＳＬＰが検出した場合（例えば、プロキシモードが指示されたときにＳＵＰＬ  ＡＵＴＨ  ＲＥＱメッセージが受信された場合、又はＳＬＰセッションＩＤが誤っている場合又はＶＥＲが第６．３．１節において説明される検証に失敗した場合）は、Ｅ−ＳＬＰは、ＳＥＴに正しいパラメータが提供されるようにするためにＴＬＳセッションを通じてＳＥＴにＳＵＰＬ  ＩＮＩＴを送信しなければならない。応答して、ＳＥＴは、最初に受信されたＳＵＰＬ  ＩＮＩＴを用いて開始されたＳＵＰＬセッションを廃棄し、ＳＥＴは、ＴＬＳセッションを通じて受信されたＳＵＰＬ  ＩＮＩＴを用いて新しいＳＵＰＬセッションを開始することができる。次に、ＳＥＴは、直ちにそのＳＵＰＬ  ＩＮＩＴメッセージを処理することができ（すなわち、ＳＥＴは、Ｅ−ＳＬＰホワイトリストを用いて優先度を評価しない）、通知及び検証のための該当する行動を行い、ユーザがセッションを拒否しないことを条件として、ＳＥＴは、セッションを継続するためにＥ−ＳＬＰに該当するメッセージ（ＳＵＰＬ  ＰＯＳ  ＩＮＩＴ又はＳＵＰＬ  ＡＵＴＨ  ＲＥＱ）を送信する。
【０５００】
ＳＵＰＬ  ＩＮＩＴを再送信する能力は、緊急セッションのみを対象とすることが意図される。非緊急セッションでは、ＳＵＰＬ  ＩＮＩＴの変更が検出された場合は、ＳＬＰは、非緊急呼の流れにおいて規定されるように、ＳＵＰＬ  ＥＮＤを用いてＳＵＰＬセッションを終了させることができる。
【０５０１】
６．３  ＳＵＰＬ  ＩＮＩＴメッセージの処理
ネットワークによって開始されるセッションはＳＵＰＬ  ＩＮＩＴメッセージによってトリガされるため、なりすまし及び（幾つの場合は）リプレイ攻撃からＳＵＰＬ  ＩＮＩＴメッセージを保護することが不可欠である。
【０５０２】
ＳＵＰＬ３．０は、ＳＵＰＬ  ＩＮＩＴメッセージのための次の保護を規定している。
【０５０３】
・  ネットワークに基づくセキュリティ。ＳＬＰは、ＳＵＰＬ  ＩＮＩＴメッセージの認証（第６．３．１節）及びリプレイ保護（第６．３．２節）を確認するための検査を行うことができる。この検証は、ＳＥＴがＳＵＰＬ  ＩＮＩＴメッセージの内容を処理し、ＳＵＰＬセッションを実施するためにＳＬＰとセキュアなＴＬＳセッションを確立した後に生じる。
【０５０４】
・エンド・ツー・エンドセキュリティ：ＳＬＰは、暗号化、完全性保護及びリプレイ保護の組み合わせをＳＵＰＬ  ＩＮＩＴメッセージに適用することができ、ＳＥＴは、復号、完全性検証及びリプレイ検出の対応する組み合わせを適用する。ＳＥＴは、ＳＵＰＬ  ＩＮＩＴメッセージの内容を処理する前にこれらのセキュリティ措置を適用する。このセキュリティは、非緊急ＳＵＰＬ  ＩＮＩＴメッセージのみに適用される。
【０５０５】
ネットワークに基づくセキュリティは強制的であり、エンド・ツー・エンドセキュリティは任意選択である。
【０５０６】
６．３．１  ＳＵＰＬ  ＩＮＩＴメッセージのネットワークに基づく認証
ＳＬＰは、ＳＵＰＬ  ＩＮＩＴメッセージの完全性のネットワーク検証を常時行う。ＳＵＰＬ  ＩＮＩＴメッセージに応答して送信される最初のメッセージ（すなわち、ＳＵＰＬ  ＰＯＳ  ＩＮＩＴ、ＳＵＰＬ  ＡＵＴＨ  ＲＥＱ  又はＳＵＰＬ  ＴＲＩＧＧＥＲＥＤ  ＳＴＡＲＴメッセージ）は、検証フィールド（ＶＥＲ）を含まなければならない。ＳＬＰがＳＵＰＬ  ＩＮＩＴメッセージに応答して最初のメッセージを受信したときには、ＳＬＰは、送信されたＳＵＰＬ  ＩＮＩＴメッセージに関して計算された対応する値に照らして受信されたＶＥＲフィールドを検査する。この検証が不合格の場合は、ＳＬＰは、状態コード‘ａｕｔｈＳｕｐｌｉｎｉｔＦａｉｌｕｒｅ’が入ったＳＵＰＬ  ＥＮＤメッセージを用いてセッションを終了させなければならない。
【０５０７】
検証フィールドのための値は、次のように計算しなければならない：
・  ＶＥＲ＝Ｈ（ＳＬＰ  ＸＯＲ  ｏｐａｄ，Ｈ（ＳＬＰ  ＸＯＲ  ｉｐａｄ，ＳＵＰＬ  ＩＮＩＴ））
ここで、ＳＬＰは、ＳＬＰアドレスのＦＱＤＮである。ＳＨＡ−２５６は、ｏｐａｄ及びｉｐａｄを有するハッシュ（Ｈ）関数として使用しなければならない。ＳＨＡ−２５６  ＨＡＳＨ関数の出力は、６４ビットで打ち切らなければならない。すなわち、同関数は、ＨＭＡＣ−ＳＨＡ２５６−６４として実装しなければならない。ＳＬＰアドレスは秘密とはみなされないことに注目すること。ここで使用されるＨＭＡＣ構造は、どのようなデータ認証も提供せず、ＨＡＳＨ関数の代替として使用されるにすぎない。
【０５０８】
６．３．２  ＳＵＰＬ  ＩＮＩＴメッセージのネットワークに基づくリプレイ保護
ネットワークによって開始される事例に関しては、リプレイ攻撃に対する保護をＳＬＰによって提供しなければならない。ＳＬＰは、前回の、期限切れでないＳＵＰＬ  ＩＮＩＴメッセージがＳＵＰＬメッセージ内部で受信された“ＳＬＰセッションＩｄ”に対応するそれとともに送信されていないかぎり認証されたＳＥＴからのどのようなＳＵＰＬメッセージも受け入れられないようにしなければならない。ＳＬＰは、ＳＵＰＬメッセージのタイプ（例えば、ＳＵＰＬ  ＰＯＳ  ＩＮＩＴ、ＳＵＰＬ  ＡＵＴＨ  ＲＥＱ、ＳＵＰＬ  ＴＲＩＧＧＥＲＥＤ  ＳＴＡＲＴ）がＳＵＰＬ  ＩＮＩＴメッセージで送信されたパラメータと一致することも確認しなければならない。実装では、“ＳＬＰセッションＩｄ”が認証されているＳＥＴユーザＩＤ（例えば、ＭＳＩＳＤＮ、ＷｉＭＡＸユーザＩＤ又はＭＤＮ）と正確に関連付けられるようにしなければならない。
【０５０９】
ＳＥＴユーザ認証が、本書で説明される代替クライアント認証方法を用いて行われる場合は、ＳＥＴからの応答（ＳＵＰＬ  ＰＯＳ  ＩＮＩＴ、ＳＵＰＬ  ＡＵＴＨ  ＲＥＱ又はＳＵＰＬ  ＴＲＩＧＧＥＲＥＤ  ＳＴＡＲＴ）のソースＩＰアドレスとＳＥＴユーザのＭＳＩＳＤＮ又はＭＤＮとの間のマッピングが既に確立されており、このＭＳＩＳＤＮ又はＭＤＮを認証されたＭＳＩＳＤＮ又はＭＤＮとして使用しなければならない。
【０５１０】
誤りのあるＳＵＰＬ  ＰＯＳ  ＩＮＩＴ、ＳＵＰＬ  ＡＵＴＨ  ＲＥＱ又はＳＵＰＬ  ＴＲＩＧＧＥＲＥＤ  ＳＴＡＲＴの廃棄は、ＳＥＴにとっての課金可能な（ｃｈａｒｇｅａｂｌｅ）イベントを生成させてはならない。
【０５１１】
非プロキシネットワークによって開始される事例に関しては、ＳＬＰは、ＳＵＰＬ測位の成功裏の完了に関する確認をＳＰＣから受信後のみに課金可能なイベントを生成しなければならない。
【０５１２】
６．３．３  ＳＵＰＬ  ＩＮＩＴメッセージのエンド・ツー・エンド保護
注：ＳＵＰＬ  ＩＮＩＴメッセージのエンド・ツー・エンド保護は、非緊急ＳＵＰＬ  ＩＮＩＴメッセージのみに対して適用される。
【０５１３】
本明細書では、エンド・ツー・エンドのＳＵＰＬ  ＩＮＩＴ保護のために３つの選択肢が提供されている。すなわち、Ｎｕｌｌ（ヌル）、モードＡ及びモードＢである。
【０５１４】
・  Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護は、エンド・ツー・エンドの完全性保護、エンド・ツー・エンドのリプレイ保護及び秘密性保護のいずれも提供しない。Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護のための手順は、第６．３．４節で説明される。
【０５１５】
・  モードＡ  ＳＵＰＬ  ＩＮＩＴ保護は、デフォルトのアルゴリズムを用いてのエンド・ツー・エンドの完全性保護及びエンド・ツー・エンドのリプレイ保護を提供する。モードＡ  ＳＵＰＬ  ＩＮＩＴ保護は、セキュリティが確保されたＵＬＰセッション中にＳＬＰによってＳＥＴに送信された共有鍵を使用する。モードＡ  ＳＵＰＬ  ＩＮＩＴ保護のための手順は、第６．３．５節で説明される。
【０５１６】
・  モードＢ  ＳＵＰＬ  ＩＮＩＴ保護は、デフォルトのアルゴリズムを用いてのエンド・ツー・エンドの完全性保護及びエンド・ツー・エンドのリプレイ保護を提供する。モードＢ  ＳＵＰＬ  ＩＮＩＴ保護は、該当するＰＳＫに基づく方法（ＧＢＡ方法又はＳＥＫ方法）を用いて導き出された共有鍵を使用する。モードＢ  ＳＵＰＬ  ＩＮＩＴ保護のための手順は、第６．３．６節で説明される。
【０５１７】
保護レベルに関する優先順位は次の通りである：
◆  Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護が最も低い優先順位を有する。
【０５１８】
◆  モードＡ  ＳＵＰＬ  ＩＮＩＴ保護は、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護よりも高い優先順位を有する。
【０５１９】
◆  モードＢ  ＳＵＰＬ  ＩＮＩＴ保護は、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護よりも高い優先順位を有する。
【０５２０】
ＳＵＰＬ  ＩＮＩＴメッセージ内では、（下表内の）Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌ（保護レベル）パラメータが現在の保護レベルに従って割り当てられる。
【０５２１】
注：本明細書は、将来の改訂版において加えられることになるより高度な保護レベルを考慮して書かれている。この高度な保護は、ＳＵＰＬ  ＩＮＩＴのセキュリティを確保するためのその他の方法についての交渉を可能にすることができる（例えば、暗号化を可能にすること及びアルゴリズムの交渉を可能にすること）。ＳＥＴがＳＵＰＬ  ＩＮＩＴメッセージを構文解析することができるかどうかを決定する際の助けとなるＰｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータが含まれている。保護レベルパラメータは、拡張性のために要求されることがある。
【０５２２】
ＳＵＰＬ  ＩＮＩＴメッセージは、セキュリティパラメータを含めるためのＰｒｏｔｅｃｔｏｒ（プロテクタ）パラメータを存在させることができる。Ｐｒｏｔｅｃｔｏｒパラメータの存在は下表において規定される。
【表１３】
0005876063.tif 000014
【０５２３】
ＳＵＰＬ  ＩＮＩＴ  Ｐｒｏｔｅｃｔｏｒ  Ｌｅｖｅｌパラメータ値及びＳＵＰＬ  ＩＮＩＴ内でのＰｒｏｔｅｃｔｏｒパラメータの存在
ＡＣＡに基づく方法をサポートするＳＥＴ又はＤ−ＳＬＰ又はＨ−ＳＬＰは、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護をサポートしなければならない。
【０５２４】
全ＳＥＴが、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護手順をサポートしなければならない。
【０５２５】
Ｄ−ＳＬＰ又はＨ−ＳＬＰは、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護手順をサポートすることができる。ＰＳＫに基づく方法をサポートするＳＥＴ又はＤ−ＳＬＰ又はＨ−ＳＬＰは、モードＢ  ＳＵＰＬ  ＩＮＩＴ保護手順をサポートしなければならない。
【０５２６】
Ｅ−ＳＬＰエンティティは、現在定義されているＳＵＰＬ  ＩＮＩＴ保護には関わっていない。
【０５２７】
６．３．３．１  ＳＵＰＬ  ＩＮＩＴ保護レベルの交渉
次のプロセスは、Ｄ−ＳＬＰ又はＨ−ＳＬＰであるＳＬＰのみに適用され、それらのプロセスは、Ｅ−ＳＬＰには適用されない。
【０５２８】
ＳＵＰＬ  ＩＮＩＴ保護レベルがどのようにして交渉されるかに関する情報を提供するための説明を以下に示した：
１．ＳＥＴは、有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが存在しないときには（例えば、パワーアップ時又はＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの寿命が切れているとき）Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護を適用しなければならない。初期の保護レベルは、常にＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴである。この状態で、ＳＥＴは、すべてのＳＵＰＬ  ＩＮＩＴメッセージを処理する、すなわち、いずれのメッセージも暗黙に廃棄されない。ＳＵＰＬ  ＩＮＩＴメッセージが不具合状態で構文解析される場合は、ＳＥＴは、誤りメッセージをＳＬＰに送信する。
【０５２９】
２．ＳＥＴが、特定のＳＬＰに関してモードＡ又はモードＢ  ＳＵＰＬ  ＩＮＩＴ保護を用いて既に交渉された有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及び有効なリプレイカウンタを有する場合は、ＳＥＴは、交渉されたモード（モードＡ又はモードＢ）を用いてそのＳＬＰからのすべてのＳＵＰＬ  ＩＮＩＴメッセージを処理する。
【０５３０】
３．ＳＥＴがＳＬＰへの相互に認証されたセキュアなコネクションを確立するときに、
ａ．相互認証のためにＰＳＫに基づく方法（ＧＢＡ又はＳＥＫ）が使用された場合は、モードＢ  ＳＵＰＬ  ＩＮＩＴ保護が適用され、ＰＳＫ−ＴＬＳのハンドシェイクにおいてやり取りされたＢ−ＴＩＤは、Ｋｓ（３ＧＰＰ及び３ＧＰＰ２配備ではＫｓ_ＮＡＦとして使用される）又は３ＧＰＰ及び３ＧＰＰ２配備においてＫｓ_ＮＡＦとして使用されるＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを導き出すために使用することができるＳＥＫに対応する。このＫｓ_ＮＡＫ又はＳＥＫ及び関連付けられたＢ−ＴＩＤは、以下のいずれかまでモードＢ  ＳＵＰＬ  ＩＮＩＴ保護で使用される。
【０５３１】
ｉ．鍵が期限切れになるまで。この場合は、ＳＥＴ及びＳＬＰはＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護に戻る
ｉｉ．ＳＥＴ及びＳＬＰが非緊急セッションでＡＣＡ方法を使用するまで。この場合は、ＳＥＴ及びＳＬＰは、以下のステップ３のｂにおいて説明されるようにモードＡ又はＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護に戻る、又は、
ｉｉｉ．ＳＥＴ及びＨ−ＳＬＰが、新しいＢ−ＴＩＤを用いてＴＬＳを確立するためにＧＢＡの又はＳＥＫのブートストラッピング再交渉方法を使用するまで。この場合は、Ｂ−ＴＩＤ及び対応するＫｓ_ＮＡＦ又はＳＥＫがモードＢ  ＳＵＰＬ  ＩＮＩＴ保護のために使用される。
【０５３２】
ｂ．そうでない場合は、ＳＥＴ及びＳＬＰは、ＤＣｅｒｔ方法又はＡＣＡ方法を用いてセキュアなコネクションを確立した。
【０５３３】
ｉ．ＳＥＴが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない場合は、ＳＥＴは、最初のＵＬＰメッセージでＳＵＰＬ_ＩＮＩＴ_ＫｅｙＲｅｑｕｅｓｔパラメータをＳＬＰに送信する。
【０５３４】
１．ＳＬＰがモードＡ  ＳＵＰＬ  ＩＮＩＴ保護をサポートする場合は、ＳＬＰは、ＳＥＴに対する最初のＵＬＰ応答においてはＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及びＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒパラメータを送信することによって応答する。ＳＥＴがこれらのパラメータを受信したときに、これは、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護が適用されることをＳＥＴに示す。
【０５３５】
注：ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを更新する方針は、ＳＬＰオペレータの判断である。
【０５３６】
２．ＳＬＰが、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護をサポートしない（又はこの特定の時点でモードＡ  ＳＵＰＬ  ＩＮＩＴ保護をサポートしない）場合は、ＳＬＰは、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護が適用されることを示す表示を（ＵＬＰメッセージで）ＳＥＴに送信する。
【０５３７】
ｉｉ．ＳＥＴが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するが、有効なＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを有さないか又はリプレイ保護に関する同期化を失っている場合は、ＳＥＴは、最初のＵＬＰメッセージでＳＵＰＬ_ＩＮＩＴ_ＲｅｓｙｎｃｈＲｅｑｕｅｓｔパラメータをＳＬＰに送信する。
【０５３８】
１．ＳＬＰがモードＡ  ＳＵＰＬ  ＩＮＩＴ保護をサポートする場合は、ＳＬＰは、（ＳＥＴへの最初の応答において）第６．３．６．１．１節で規定される手順を用いて新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒで応答する。ＳＥＴがこの応答を受信したときには、これは、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護が適用されることをＳＥＴに示す。
【０５３９】
２．ＳＬＰがモードＡ  ＳＵＰＬ  ＩＮＩＴ保護をサポートしない（又はこの特定の時点でモードＡ  ＳＵＰＬ  ＩＮＩＴ保護をサポートすることを希望しない）場合は、ＳＬＰは、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護が適用されることを示す表示を（ＵＬＰメッセージで）ＳＥＴに送信する。
【０５４０】
これは、ＳＥＴがＨ−ＳＬＰへの新しいＴＬＳコネクションを設定するごとに保護レベルが再交渉されることを意味することに注目すること。
【０５４１】
６．３．３．２  Ｈ−ＳＬＰの観点からの交渉
ＳＥＴとの直近のＩＰセッションがＧＢＡ又はＳＥＫ方法を用いて認証され、及びＨ−ＳＬＰがＳＥＴに関する現在のＢ−ＴＩＤ及び関連付けられた鍵を有する場合は、
◆  Ｂ−ＴＩＤがＧＢＡを用いて入手された鍵に関するものである場合は、Ｈ−ＳＬＰは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを、直近のＢ−ＴＩＤに対応し、次のように生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦとして割り当てる。
【０５４２】
○  ＦＱＤＮは、Ｈ−ＳＬＰ_ＦＱＤＮであることができる。
【０５４３】
○  ＳＵＰＬ_ＩＮＩＴ保護のために使用することができるＧＢＡ  Ｕａセキュリティプロトコル識別子は、ＯＭＮＡレジストリで定義される。
【０５４４】
◆  Ｂ−ＴＩＤがＳＥＫ方法を用いて導き出された鍵に関するものである場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、第６．１．２．１．２節で定義されるＳＥＫである。
【０５４５】
◆  その他のＳＵＰＬ  ＩＮＩＴ保護は交渉されていないと仮定すると、Ｈ−ＳＬＰは、そのＳＥＴのためにモードＢ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０５４６】
そうでない場合は、Ｈ−ＳＬＰがＳＥＴに関する有効なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及び関連付けられた鍵を有する場合は、Ｈ−ＳＬＰは、そのＳＥＴのためにモードＡ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０５４７】
その他の保護レベルが割り当てられていない場合は、Ｈ−ＳＬＰは、そのＳＥＴに関してＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０５４８】
Ｈ−ＳＬＰは、現在割り当てられているレベルのＳＵＰＬ  ＩＮＩＴ保護に対応する（引き渡し前にＳＵＰＬ  ＩＮＩＴメッセージを処理するための）手順を適用する。これは、ＳＵＰＬ  ＩＮＩＴメッセージ内のＰｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータのための該当値を割り当てることを含む。
【０５４９】
６．３．３．３  ＳＥＴの観点からの交渉
Ｈ−ＳＬＰとの直近のＩＰセッションがＧＢＡ又はＳＥＫ方法を用いて認証され、及びＳＥＴが現在のＢ−ＴＩＤ及びそのＩＰセッションのために用いられる関連付けられた鍵を有する場合は、
◆  Ｂ−ＴＩＤがＧＢＡを用いて入手された鍵に関するものである場合は、ＳＥＴは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを、直近のＢ−ＴＩＤに対応し、次のように生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦとして割り当てる。
【０５５０】
○  ＦＱＤＮは、Ｈ−ＳＬＰ_ＦＱＤＮであることができる。
【０５５１】
○  ＳＵＰＬ_ＩＮＩＴ保護のために使用することができるＧＢＡ  Ｕａセキュリティプロトコル識別子は、ＯＭＮＡレジストリで定義される。
【０５５２】
◆  Ｂ−ＴＩＤがＳＥＫ方法を用いて導き出された鍵に関するものである場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、第６．１．２．１．２節で定義されるＳＥＫである。
【０５５３】
◆  その他のＳＵＰＬ  ＩＮＩＴ保護は交渉されていないと仮定すると、ＳＥＴは、モードＢ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０５５４】
そうでない場合は、ＳＥＴがＨ−ＳＬＰに関する有効なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、関連付けられた鍵及びＭｏｄｅＡＲｅｐｌａｙＣｏｕｎｔｅｒを有する場合は、Ｈ−ＳＬＰは、ＳＥＴは、そのＳＥＴのためにモードＡ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０５５５】
その他の保護レベルが割り当てられていない場合は、ＳＥＴは、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０５５６】
ＳＥＴは、現在割り当てられているレベルのＳＵＰＬ  ＩＮＩＴ保護に対応する（受信されたＳＵＰＬ  ＩＮＩＴメッセージを処理するための）手順を適用する。
【０５５７】
６．３．３．４  例外手順
ＳＥＴ内部のＳＵＰＬ  ＩＮＩＴ保護パラメータが壊れているとＳＥＴが決定した場合は、ＳＥＴは、Ｈ−ＳＬＰとのＴＬＳセッションを確立しなければならない。
【０５５８】
・  ＧＢＡ認証が使用される場合は、ＳＥＴは、新しい鍵を確立するためのＧＢＡブートストラッピングを開始しなければならない。
【０５５９】
・  ＳＥＫ方法を使用するＳＥＴに関しては、ＳＥＴは、新しい鍵をイネーブルにするためＳＥＫブートストラッピングを開始しなければならない。
【０５６０】
・  そうでない場合は、ＳＥＴは、最初のセキュリティが確保されたＵＬＰメッセージでＳＵＰＬ_ＩＮＩＴ_ＫｅｙＲｅｑｕｅｓｔを送信し、
第６．３．３．１節のステップ３．のｂの手順に従う。
【０５６１】
ＳＬＰがセキュリティコンテキストを失った場合は（例えば、大量のデータ損失）、ＳＬＰは、測位活動を開始する手段を有さないことになる。コンテキストは、Ｋｓ_ＮＡＦ又はＳＥＫが期限切れになるか又はＳＥＴがＳＬＰに接続するときに再確立される。この“ブロックアウトウィンドウ”（ｂｌｏｃｋ  ｏｕｔ  ｗｉｎｄｏｗ）を防止するために、ＳＬＰは、該シナリオから回復するためにすべてのＳＵＰＬ  ＩＮＩＴセキュリティコンテキスト情報が十分な冗長度を持って格納されるようにすべきである。
【０５６２】
６．３．４  Ｎｕｌｌレベルの保護が割り当てられるときの仕様
注：Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護のためのＳＵＰＬ  ＩＮＩＴプロテクタは存在しない。
【０５６３】
６．３．４．１  Ｈ−ＳＬＰ手順
Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護の専用であるＳＬＰのためのセキュリティ手順は存在しない。
【０５６４】
６．３．４．２  ＳＥＴ手順
Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護が割り当てられ、ＳＥＴがＳＵＰＬ  ＩＮＩＴメッセージを受信したときには、ＳＥＴは、次の手順を適用する：
◆  Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータが正しい場合は、ＳＥＴは、メッセージを真正であるとみなし、セキュリティに関連する処理は要求されない。
【０５６５】
○  ＳＬＰ及びＳＥＴがより高い保護レベルをサポートすることができるが、パワーアップ中であるためＳＥＴがＳＬＰにまだ接触していないと仮定すると、この場合は、ＳＥＴは、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護が割り当てられる。ＳＥＴがＳＬＰに接触するまでの期間において、ＳＥＴは、（正しいＰｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータを有する）あらゆる受信されたＳＵＰＬ  ＩＮＩＴメッセージを真正であるとみなす。（受信されたＳＵＰＬ  ＩＮＩＴメッセージに応答してであるかどうかにかかわらず）ＳＥＴがＳＬＰに初めて接触した時点で、ＳＥＴ及びＳＬＰは、より高い保護レベルに移行する。これらの２つのエンティティがより高い保護レベルに移行した時点で、ＳＥＴは、真正でないＳＵＰＬ  ＩＮＩＴメッセージを検出することができる。ＳＥＴがパワーアップされるときとＳＥＴがＳＬＰに最初に接触するときとの間には、ＳＥＴが、あたかもＳＵＰＬ  ＩＮＩＴメッセージが真正であるものとしてＳＥＴによって処理される非真正のＳＵＰＬ  ＩＮＩＴメッセージを受信することが可能である。ＳＥＴが非認証ＳＵＰＬ  ＩＮＩＴメッセージと関連付けられたＳＵＰＬセッションを進行させることを決定した場合は、ＳＥＴは、ＳＬＰに接触してセキュアなＴＬＳセッションを確立する。ＳＵＰＬセッションは非真正のＳＵＰＬ  ＩＮＩＴメッセージを用いて確立されたため、ＳＬＰはそれを許容しない。ＳＥＴ及びＳＬＰがより高い保護レベルをサポートする場合は、これは同時に確立され、ＳＥＴは、この時間後に非真正のＳＵＰＬメッセージを検出することができる。このことは、ＳＥＴ及びＳＬＰがより高い保護レベルをサポートすることができる場合は、攻撃者が非真正のＳＵＰＬ  ＩＮＩＴメッセージをＳＥＴに入手させる非常に小さい機会の窓が存在しており、ＳＥＴは、多くとも１つの非真正のＳＵＰＬ  ＩＮＩＴメッセージに関してＳＵＰＬセッションを進行させることを試みるにすぎないことを意味する。
【０５６６】
◆  Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータが正しくない場合（すなわち、Ｐｒｏｔｅｃｔｉｏｎ  ＬｅｖｅｌパラメータがＮｕｌｌ以外の何かであった場合）は、ＳＥＴは、該当する誤りメッセージをＳＬＰに送信する。
【０５６７】
○  ＳＬＰ及びＳＥＴでの保護レベルが同期化を失った場合は、この手順は、ＳＥＴ及びＳＬＰが共通の保護レベルで再同期化するのを可能にする。
【０５６８】
６．３．５  モードＡ  ＳＵＰＬ  ＩＮＩＴ保護レベルに関する仕様
６．３．５．１  モードＡ  ＳＵＰＬ  ＩＮＩＴ保護のための鍵識別子
モードＡ  ＳＵＰＬ  ＩＮＩＴ保護は、ＳＵＰＬ  ＩＮＩＴメッセージとともに送信することができる２つの鍵識別子、すなわち、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及びＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、を使用する。
【０５６９】
・  ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹと関連付けられたグローバルで一意の、長期的な鍵識別子である。ＳＬＰは、ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのための新しい値をプロビジョニングするときのみに新しいＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒをＳＥＴに提供する。
【０５７０】
・  ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けられた短期のアイデンティティ（仮名）である。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒが有効である期間の間グローバルで一意であることができる。ＳＥＴ及びＳＬＰは、第６．３．５．３節及び第６．３．５．４節において説明されるようにＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの値を同期化する。
【０５７１】
ＳＬＰは、典型的には、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを基本的ＳＵＰＬ  ＩＮＩＴプロテクタ内のＫｅｙＩｄｅｎｔｉｆｉｅｒとして使用する。ＳＥＴは、基本的ＳＵＰＬ  ＩＮＩＴプロテクタを検証するためにいずれのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが使用されるべきかを決定するためにＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを使用する。
【０５７２】
ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、典型的には、ＳＵＰＬ  ＩＮＩＴメッセージでは送信されず、その理由は、観察者が複数のＳＵＰＬ  ＩＮＩＴメッセージを１つの共通のＳＥＴユーザと関連付けるのを可能にするためである。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの目的は、脅威エージェントが複数のＳＵＰＬ  ＩＮＩＴメッセージを１人のＳＥＴユーザと関連付けるためにＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを使用するのを防止することである。ＳＬＰ及びＳＥＴのみがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒをＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けることができるようにすべきである。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを変更する頻度は、主に、ＳＥＴユーザの判断である。ＳＬＰは、ＳＬＰ方針に基づいてＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのための新しい値を確立することを選択することができる。
【０５７３】
しかしながら、ＳＬＰがより長期のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを基本的ＳＵＰＬ  ＩＮＩＴプロテクタ内のＫｅｙＩｄｅｎｔｉｆｉｅｒとして使用することを希望する状況が存在する。例えば、ＳＥＴが基本的ＳＵＰＬ  ＩＮＩＴプロテクタ内のＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを用いて複数のＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージに応答していないと仮定する。ＳＬＰは、ＳＥＴがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒに関する同期化を失っていることを懸念するおそれがある。ＳＥＴ及びＳＬＰは、長期的なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒに関しての方が同期化状態を維持する可能性が高い。従って、ＳＬＰは、同期化を失うことがＳＥＴがＳＵＰＬ  ＩＮＩＴメッセージを検証するのを妨げないようにするために基本的ＳＵＰＬ  ＩＮＩＴプロテクタ内のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを用いてＳＵＰＬ  ＩＮＩＴメッセージを送信することができる。
【０５７４】
６．３．５．２  モードＡ  ＳＵＰＬ  ＩＮＩＴ保護及び基本的ＳＵＰＬ  ＩＮＩＴプロテクタ
モードＡ  ＳＵＰＬ  ＩＮＩＴ保護は、基本的ＳＵＰＬ  ＩＮＩＴプロテクタ及び第６．３．７節において定義される関連付けられた手順を使用し、さらなる明確化のために以下を示した。
【０５７５】
◆  ＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅ：ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ又はＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのいずれかが使用されることを示す。
【０５７６】
◆  ＫｅｙＩｄｅｎｔｉｆｉｅｒ：ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅに適宜対応するＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ又はＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのいずれかに対応する。
【０５７７】
◆  ＢａｓｉｃＭＡＣは、上記のＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けられたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いて、ＳＵＰＬ_ＩＮＩＴ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｍｏｄｅ  Ａ  ＩＫ”）を用いて計算される。
【０５７８】
６．３．５．３  Ｈ−ＳＬＰ手順
モードＡ専用Ｈ−ＳＬＰ手順は、ＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
【０５７９】
ＳＬＰが（セキュリティが確保されたセッションにおけるＳＥＴへの最初の応答メッセージで）ＮｅｗＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒパラメータを送信し、新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを後続させることによってＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのための新しい値が確立される。新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを確立することは、その結果として、ＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒが０ｘ００００にリセットされ、ＳＥＴが“プレイされた”ＳＵＰＬ  ＩＮＩＴメッセージに関する全情報を取り除く。
【０５８０】
ＳＬＰは、ＳＵＰＬ_ＩＮＩＴ_ＲｅｓｙｎｃｈＲｅｑｕｅｓｔ又はＳＬＰの（範囲外の）内部判断のいずれかに応答して新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを確立することができる。すなわち、ＳＬＰは、ＳＥＴからの対応するＳＵＰＬ_ＩＮＩＴ_ＲｅｓｙｎｃｈＲｅｑｕｅｓｔが存在しないときでもＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを送信することができる。
【０５８１】
６．３．５．４  ＳＥＴ手順
モードＡ専用Ｈ−ＳＬＰ手順は、ＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
【０５８２】
ＳＥＴは、ＵＬＰセッションの最初のメッセージでＳＵＰＬ_ＩＮＩＴ_ＲｅｓｙｎｃｈＲｅｑｕｅｓｔを送信することによってＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのための新しい値を確立することをトリガすることができる。
【０５８３】
モードＡ  ＳＵＰＬ  ＩＮＩＴ保護がＳＥＴによって割り当てられた場合は、ＳＥＴが所定のＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを有するＳＵＰＬ  ＩＮＩＴメッセージを初めて処理する前に、ＳＥＴは、ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒのためにそれの使用された値のキャッシュをクリアする。
【０５８４】
６．３．６  モードＢ  ＳＵＰＬ  ＩＮＩＴ保護レベルに関する仕様
モードＢ  ＳＵＰＬ  ＩＮＩＴ保護は、基本的ＳＵＰＬ  ＩＮＩＴプロテクタ及び第０節において定義される関連付けられた手順を使用し、さらなる明確化のために以下を示した。
【０５８５】
◆  ＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅ：Ｂ−ＴＩＤ識別子のみがモードＢ  ＳＵＰＬ  ＩＮＩＴ保護のためのサポートである。
【０５８６】
◆  ＫｅｙＩｄｅｎｔｉｆｉｅｒ：現在のＢ−ＴＩＤに対応する。
【０５８７】
◆  ＢａｓｉｃＭＡＣパラメータは、ＳＵＰＬ_ＩＮＩＴ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｍｏｄｅ  Ａ  ＩＫ”）を用いて計算され、ここで、
○  ＧＢＡに基づく配備の場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、直近のＢ−ＴＩＤに対応し、ＯＭＮＡレジストリで定義されるＳＵＰＬ  ＩＮＩＴ保護のためのＧＢＡ  Ｕａセキュリティプロトコル識別子を用いて生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦである。
【０５８８】
○  ＳＥＫに基づく配備の場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、第６．１．２．１．２節で定義されるＳＥＫ_ＭＡＣである。
【０５８９】
６．３．６．１  Ｈ−ＳＬＰ手順
モードＢ専用Ｈ−ＳＬＰ手順は、ＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
【０５９０】
モードＢ  ＳＵＰＬ  ＩＮＩＴ保護に関して、鍵が初めて使用されるときにＳＬＰ内のＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがゼロにリセットされ、ＳＥＴが“プレイされた”ＳＵＰＬ  ＩＮＩＴメッセージに関する全情報を取り除く。
【０５９１】
再同期化が要求されるとＳＬＰが決定する起こりえない事象において、
・  ＧＢＡ方法をサポートする配備の場合は、ＳＬＰは、ＧＢＡ  Ｂ−ＴＩＳを無効にすることによって再同期化をトリガする。そのＳＥＴが次にＳＬＰに対して認証することを試みたときに、ＳＬＰは、ＴＬＳ−ＰＳＫ  ａｌｅｒｔ“ｐｓｋ_ｉｄｅｎｔｉｔｙ_ｕｎｋｎｏｗｎ”で応答する。これは、新しいＧＢＡ鍵を確立することをプロンプトする。
【０５９２】
・  ＳＥＫ方法をサポートする配備の場合は、ＳＬＰは、ＳＥＫ  Ｂ−ＴＩＳを無効にすることによって再同期化をトリガする。そのＳＥＴが次にＳＬＰに対して認証することを試みたときに、ＳＬＰは、ＴＬＳ−ＰＳＫ  ａｌｅｒｔ“ｐｓｋ_ｉｄｅｎｔｉｔｙ_ｕｎｋｎｏｗｎ”で応答する。これは、第６．１．３．３節で説明されるように新しいＳＥＫを確立することをプロンプトする。
【０５９３】
６．３．６．２  ＳＥＴ手順
モードＢ専用ＳＥＴ手順は、ＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
【０５９４】
モードＢ  ＳＵＰＬ  ＩＮＩＴ保護がＳＥＴによって割り当てられた場合は、
・  ＳＥＴが所定のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するＳＵＰＬ  ＩＮＩＴメッセージを初めて処理する前に、ＳＥＴは、ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒのためにそれの使用された値のキャッシュをクリアする。
【０５９５】
・  ＳＥＴは、新しいＧＢＡ  Ｋｓ又は新しいＳＥＫを適宜確立することによって再同期化をトリガすることができる。ＳＬＰは、ＳＥＴとＳＬＰとの間での次の成功裏の認証まで旧ＧＢＡ  Ｋｓ（又はＳＥＫ）を使用し続ける。このため、ＳＥＴは、その時まで旧ＧＢＡ  Ｋｓ（又はＳＥＫ）を維持すべきである。
【０５９６】
６．３．７  基本的ＳＵＰＬ  ＩＮＩＴプロテクタを使用するための仕様
基本的ＳＵＰＬ  ＩＮＩＴプロテクタは、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護及びモードＢ  ＳＵＰＬ  ＩＮＩＴ保護の両方のために使用され、次のパラメータを含む：
◆  ＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅ：長さ＝１オクテット
◆  ＫｅｙＩｄｅｎｔｉｆｉｅｒ：可変長。ＢａｓｉｃＭＡＣを計算するために用いられる鍵に対応する。
【０５９７】
◆  ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ：長さ＝２オクテット
◆  ＢａｓｉｃＭＡＣ：長さ＝４オクテット
ＢａｓｉｃＭＡＣパラメータは、次のように生成される：
◆  ＢａｓｉｃＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ’）、ここで、
◆  ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫは、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護及びモードＢ  ＳＵＰＬ  ＩＮＩＴ保護に関するそれぞれの第６．３．５節及び第６．３．６節により導き出される。
【０５９８】
◆  ＳＵＰＬ_ＩＮＩＴ’は、ＳＵＰＬ  ＩＮＩＴメッセージに対応し、ＢａｓｉｃＭＡＣ以外の全パラメータが割り当てられ、ＭＡＣパラメータはすべてゼロに設定される。
【０５９９】
◆  ＨＭＡＣ−ＳＨＡ２５６−３２及びＨＭＡＣ−ＳＨＡ２５６−１２８は、本書の範囲外の文書において規定されている。
【０６００】
６．３．７．１  Ｈ−ＳＬＰ手順
ＭｏｄｅＡＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒの同期化のためのＳＬＰ手順が別の場所でモードＡ及びモードＢ  ＳＵＰＬ  ＩＮＩＴ保護に関して規定される。
【０６０１】
モードＡ又はモードＢ  ＳＵＰＬ  ＩＮＩＴ保護がＳＥＴに割り当てられた場合は、Ｈ−ＳＬＰは、ＳＵＰＬ  ＩＮＩメッセージを次のように構成する：
１．ＳＵＰＬ  ＩＮＩＴプロテクタ外部のパラメータが別の場所で説明されるように割り当てられる。
【０６０２】
２．ＫｅｙＩｄｅｎｔｉｔｙＴｙｐｅが、ＳＬＰがこのメッセージのために使用するＫｅｙＩｄｅｎｔｉｔｙのタイプにより設定される。
【０６０３】
３．ＫｅｙＩｄｅｎｔｉｔｙが、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹと関連付けられたＫｅｙＩｄｅｎｔｉｔｙに設定される。
【０６０４】
４．Ｈ−ＳＬＰが、（このＳＥＴ及び交渉されたＳＵＰＬ  ＩＮＩＴ保護レベルと関連付けられた）ＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒＶａｌｕｅの現在値を１だけ増加させ、その新しい値をＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒパラメータ内に挿入する。
【０６０５】
５．最後に、すべてのその他のパラメータが割り当てられた後に、ＢａｓｉｃＭＡＣが上記のようにＳＵＰＬ  ＩＮＩＴ及びＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹから計算される。
【０６０６】
Ｈ−ＳＬＰには、モードＡ又はモードＢ  ＳＵＰＬ  ＩＮＩＴ保護レベルが割り当てられる各ＳＥＴのためのＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒパラメータの長さに等しい長さのＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒＶａｌｕｅを格納するように要求することができる。
【０６０７】
ＳＬＰ内のＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒＶａｌｕｅが６５５３５＝２１６−１に近い場合は（可能性が非常に小さい）、ＳＬＰは、再同期化手順をトリガしなければならない（第６．３．６．１節及び第６．３．７．１節を参照）。
【０６０８】
６．３．７．２  ＳＥＴ手順
ＭｏｄｅＡＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒの同期化のためのＳＥＴ手順が別の場所でモードＡ及びモードＢ  ＳＵＰＬ  ＩＮＩＴ保護に関して規定される。
【０６０９】
モードＡ又はモードＢ  ＳＵＰＬ  ＩＮＩＴ保護が割り当てられた場合は、ＳＥＴは、受信されたＳＵＰＬ  ＩＮＩＴメッセージを次のように処理する：
１．次のパラメータが該当する検証に失敗した場合はＳＥＴがＳＵＰＬ  ＩＮＩＴメッセージを廃棄する：
◆  Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌ：交渉されたＳＵＰＬ  ＩＮＩＴ保護レベルのための割り当てられた値でなければならない。
【０６１０】
◆  ＫｅｙＩｄｅｎｔｉｔｙＴｙｐｅ：割り当てられたＳＵＰＬ  ＩＮＩＴ保護レベルに関して有効でなければならない。
【０６１１】
◆  ＫｅｙＩｄｅｎｔｉｔｙ：交渉されたＳＵＰＬ  ＩＮＩＴ保護レベルに関する現在のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹに対応しなければならない。
【０６１２】
◆  ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ：ＳＥＴは、メッセージのリプレイを検出するためにこの値を使用する。この技法は、各々の実装ごとであるが、ＳＵＰＬ  ＩＮＩＴメッセージが失われるか又はばらばらに引き渡される状況に対処することができるような強固さでなければならない。
【０６１３】
◆  ＢａｓｉｃＭＡＣ：（上述されるように）ＳＥＴがＳＵＰＬ  ＩＮＩＴ及びＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹから予想されるＢａｓｉｃＭＡＣを計算し、これを受信されたＢａｓｉｃＭＡＣと比較する：これらの値は等しくなければならない。
【０６１４】
２．前ステップにおいてＳＵＰＬ  ＩＮＩＴが廃棄されなかった場合は、それは真正であるとみなされ、ＳＥＴは、使用されるべきＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒＶａｌｕｅを考慮する。ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒＶａｌｕｅが６５５３５＝２１６−１に近い場合は（可能性が非常に小さい）、ＳＥＴは、カウンタをリセットするためにＳＬＰと新しいＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを確立しなければならない。
【０６１５】
６．４  Ｈ−ＳＬＰアドレスをＳＥＴに提供する
注：アクセスネットワークから独立したＨ−ＳＬＰのためにＨ−ＳＬＰアドレスをプロビジョニングすることは、ＦＦＳである。
【０６１６】
Ｈ−ＳＬＰアドレスは、ＵＩＣＣ、ＳＥＴ内でＨ−ＳＬＰアドレスをプロビジョニングすることによってＳＥＴにとって入手可能になり、又は、デフォルトＨ−ＳＬＰが下記のように導き出される。このアドレスは、ＦＱＤＮの形態でなければならず及びＳＥＴのホームネットワークによってセキュアな状態でプロビジョニングされるべきである。
【０６１７】
６．４．１．３  ３ＧＰＰ２  ＳＥＴ
３ＧＰＰ２  ＳＥＴに関しては、Ｈ−ＳＬＰアドレスは、ＵＭＩ又はＲ−ＵＩＭにおいてセキュアな状態でプロビジョニングされなければならない。
【０６１８】
６．４．２．３  ３ＧＰＰ  ＳＥＴ
３ＧＰＰ  ＳＥＴは、（ＦＱＤＮの形態の）Ｈ−ＳＬＰアドレスを、ＷＡＰ  ＰＲＯＶＣＯＮＴにおいて規定される“ＡＰＰＡＤＤＲ／ＡＤＤＲ”特性に基づくパラメータ“ＡＤＤＲ”として読み取らなければならない。さらに、Ｈ−ＳＬＰアドレスは、３ＧＰＰ準拠ＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）に関するＯＭＡスマートカードプロビジョニング仕様において定義されるブートストラップファイル内に又はＳＥＴの同等にセキュアなエリア内にセキュアな状態で格納しなければならない。ＳＥＴは、Ｈ−ＳＬＰアドレスを読み取るためのＯＭＡスマートカードプロビジョニングメカニズムをサポートしなければならない。Ｈ−ＳＬＰアドレスを格納するＵＳＩＭ／ＳＩＭアプリケーション又はＳＥＴ内のブートストラップファイルは、ユーザによって変更可能であってはならない。Ｈ−ＳＬＰがＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）において設定されている場合は、ＳＥＴは、最初に、ＵＩＣＣにおいてプロビジョニングされるＨ−ＳＬＰアドレスを読み取らなければならない。ＵＩＣＣにおいてプロビジョニングされるＨ−ＳＬＰアドレスが存在しない場合は、ＳＥＴは、ＳＥＴのセキュアなエリアからＨ−ＳＬＰアドレスを読み取ることができる。
【０６１９】
ＳＥＴ内でのＨ−ＳＬＰアドレスのプロビジョニング：Ｈ−ＳＬＰアドレスがＳＥＴ内のセキュアな場所に格納されることになる場合は、それは、ＯＭＡデバイス管理Ｖ１．２又はそれ以降を用いてプロビジョニングしなければならない。ＯＭＡ  ＤＭを用いてＨ−ＳＬＰアドレスがプロビジョニングされる場合は、ＳＥＴは、ＴＬＳハンドシェイク中にＤＭサーバによって提示されたサーバ側証明書に基づいてＯＭＡ  ＤＭサーバを認証しなければならない。ＳＥＴがＨ−ＳＬＰの格納をサポートする場合は、それは、第６．１．４節で説明される認証方式、すなわち、ＭＳＩＳＤＮ／ＩＰアドレスマッピング認証に基づく代替クライアント認証、に依存してはならず、ＳＥＴは、第６．１．１節で説明されるＰＳＬ−ＴＬＳ相互認証方法に依存しなければならない。
【０６２０】
Ｈ−ＳＬＰアドレスの自動設定：Ｈ−ＳＬＰアドレスがＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）のセキュアな格納エリア内又はＳＥＴのセキュアなエリア内で見つけることができない場合は、ＳＥＴは、ＵＳＩＭ／ＳＩＭ内に格納されたＩＭＳＩに基づいてＳＥＴ内でデフォルトＨ−ＳＬＰアドレスを設定しなければならない。
【０６２１】
Ｈ−ＳＬＰアドレスがＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）のセキュアな格納エリア内又はＳＥＴのセキュアなエリア内で見つけられているが、それを使用した結果、ＳＵＰＬセッション中に認証失敗に終わった場合は、ＳＥＴは、ＵＳＩＭ／ＳＩＭ内に格納されたＩＭＳＩに基づいてＳＥＴ内でデフォルトＨ−ＳＬＰアドレスを設定しなければならない。
【０６２２】
デフォルトＨ−ＳＬＰアドレスを設定するためのメカニズムが以下に定義される。
【０６２３】
以下の例は、３ＧＰＰ  ＧＢＡ仕様から流用したものであり、（ＦＱＤＮに基づく）Ｈ−ＳＬＰアドレスが設定されるＳＵＰＬ使用事例のために採用されていることに注目すること。このデフォルト設定メカニズムの実装は、３ＧＰＰ  ＧＢＡ仕様の実装を要求しない。以下の例は、方法を例示することを目的として示されるにすぎず、ＧＢＡから独立して実装することができる。
【０６２４】
ＩＭＳＩに基づくＨ−ＳＬＰの構成
ステップ１）２又は３桁のＭＮＣが使用されるかどうかに依存してＩＭＳＩの最初の５又は６桁を取りそれらをＭＣＣ及びＭＮＣに分離する。ＭＮＣが２桁である場合は、始めにゼロを加えることができる。
【０６２５】
ステップ２）ステップ１で導き出されたＭＣＣ及びＭＮＣを用いて“ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．ｐｕｂ．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ”ドメイン名を生成し、ドメイン名の最初にラベル“ｈ−ｓｌｐ．”を加える。
【０６２６】
例１：使用中のＩＭＳＩが“２３４１５０９９９９９９９９９”である場合は、ここで、ＭＣＣ＝２３４，ＭＮＣ＝１５、ＭＳＩＮ＝０９９９９９９９９９であり、Ｈ−ＳＬＰアドレスは、“ｈ−ｓｌｐ．ｍｎｃ０１５．ｍｃｃ２３４．ｐｕｂ．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ”になる。
【０６２７】
新しいＩＭＳＩが電源投入中又は投入後にＳＥＴによって検出された場合は、すべての以前のＨ−ＳＬＰ設定をＳＥＴから取り除かなければならない。より具体的には、ＳＥＴ内に格納されるあらゆるＨ−ＳＬＰを取り除かなければならない。
【０６２８】
ＩＭＳＩが変更された場合は、ＳＥＴは、最初に、ＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）からＨ−ＳＬＰアドレスを読み取らなければならない。Ｈ−ＳＬＰアドレスがＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）に格納されていない場合は、ＳＥＴは、Ｈ−ＳＬＰアドレスがＳＥＴ内に格納されているかどうかを検査することができる。Ｈ−ＳＬＰアドレスがＵＩＣＣでもＳＥＴ内でも見つからない場合は、上述されるように新しいＩＭＳＩに基づいてＳＥＴによってデフォルトのＨ−ＳＬＰアドレスを設定しなければならない。
【０６２９】
実装では、ＳＥＴのメーカーソフトウェアインストール後にＳＥＴにダウロードされるアプリケーションを介してＨ−ＳＬＰのアドレスを変更できないようにしなければならない。
【０６３０】
次の流れは、Ｈ−ＳＬＰアドレス格納を例示する。
【０６３１】
１．開始する。２に行く。
【０６３２】
２．ＩＭＳＩは変更されたか。はいの場合は３に行く。いいえの場合は３を飛ばし、直接４に行く。
【０６３３】
３．ＳＥＴからＨ−ＳＬＰをクリアする。４に行く。
【０６３４】
４．ＵＩＣＣにはＨ−ＳＬＰアドレスが入っているか。いいえの場合は５に行く。はいの場合は９に行く。
【０６３５】
５．ＳＥＴのＨ−ＳＬＰアドレスはサポートされるか。いいえの場合は７に行く。はいの場合は６に行く。
【０６３６】
６．Ｈ−ＳＬＰアドレスがＳＥＴ内でプロビジョニングされているか。いいえの場合は７に行く。はいの場合は８に行く。
【０６３７】
７．ＩＭＳＩからＨ−ＳＬＰアドレスを生成する。１０に行く。
【０６３８】
８．ＳＥＴから設定を読み取る。１０に行く。
【０６３９】
９．ＵＩＣＣからＨ−ＳＬＰアドレスを読み取る。１０に行く。
【０６４０】
１０．Ｈ−ＳＬＰアドレスを用いてＨ−ＳＬＰへのＴＬＳコネクションを生成する。１１に行く。
【０６４１】
１１．認証は成功か。いいえの場合は１２に行く。はいの場合は１４に行く。
【０６４２】
１２．Ｈ−ＳＬＰアドレスはＩＭＳＩから生成されたか。いいえの場合は７に行く。はいの場合は１３に行く。
【０６４３】
１３．ＳＵＰＬセッションを打ち切り、終了する。
【０６４４】
１４．ＳＵＰＬセッションを実行し、終了する。
【０６４５】
６．４．３  ＷＩＭＡＸに基づく配備
ＳＥＴがＷｉＭＡＸネットワークに添付するときには、それは、ＯＭＡ  ＤＭを介して更新されたＨ−ＳＬＰアドレスを受信することができる。Ｈ−ＳＬＰアドレスがＷｉＭＡＸ端末にセキュアな形でプロビジョニングされるときには、それは、保護された環境で格納しなければならない。
【０６４６】
６．５  秘密性及びデータ完全性プロトコル
ＴＬＳ１．１又はＰＳＫ−ＴＬＳは、ＳＥＴとＳＬＰとの間の秘密性及びデータ完全性を提供するために使用することができる。ＳＥＴとＳＬＰとの間のＴＬＳ又はＰＳＫ−ＴＬＳセッション内で“ＳＵＰＬ  ＩＮＩＴ”以外のすべてのＳＵＰＬメッセージが引き渡されなければならない。
【０６４７】
第６．１．１．３節は、ＳＵＰＬ３．０配備におけるいずれのエンティティがサーバ証明書認証によるＴＬＳ及び／又はＴＬＳ−ＰＳＫを強制的又は任意選択的であるかを決定するための詳細を提供する。
【０６４８】
６．５．１  サーバ証明書を用いるＴＬＳ
サーバ証明書を用いるＴＬＳ１．１の実装は、ＴＬＳ１．１のＷＡＰプロフィールに準拠することができ、明確化のために以下を示した：
ＳＥＴは、以下を実装することができる：
・  ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ．
追加の暗号スイートを選ぶＳＥＴ実装に関しては、ＳＥＴは、以下を実装すべきである：
・  ＴＬＳ_ＲＳＡ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
サーバ証明書を用いるＴＬＳ１．１をサポートするＳＬＰは、以下の暗号スイートを実装することができる。
【０６４９】
・  ＴＬＳ_ＲＳＡ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
・  ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ.
ＮＵＬＬ暗号化をサポートすることを選ぶサーバ証明書を用いるＴＬＳ１．１をサポートするＳＬＰ実装に関しては、ＳＬＰは、ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＮＵＬＬ_ＳＨＡを実装することができる。ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＮＵＬＬ_ＳＨＡの使用は、秘密性の保護を提供しないため推奨されない。しかしながら、それは、認証及び完全性保護を依然として提供する。
【０６５０】
ＴＬＳ１．１のＷＡＰ証明書プロフィールは、サーバ証明書を用いるＴＬＳ１．１をサポートするＳＬＰ及びＳＥＴによってサポートすることができる。
【０６５１】
６．５．２  ＴＬＳ−ＰＳＫ
ＴＬＳ−ＰＳＫの実装は、ＴＬＳハンドシェイクに関するＰＳＫ−ＴＬＳに準拠することができ、バルク暗号化（Ｂｕｌｋ  Ｃｉｐｈｅｒｉｎｇ）は、ＴＬＳ１．１に関して定義されているとおりである。
【０６５２】
ＴＬＳ−ＰＳＫをサポートするＳＥＴは、以下を実装することができる。
【０６５３】
・  ＴＬＳ_ＰＳＫ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ.
追加の暗号スイートを選ぶＴＬＳ−ＰＳＫをサポートするＳＥＴ実装に関しては、ＳＥＴは、以下を実装すべきである：
・  ＴＬＳ_ＰＳＫ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
以下の暗号スイートをＳＬＰによって実装することができる。
【０６５４】
・  ＴＬＳ_ＰＳＫ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ.
追加の暗号スイートを選ぶＴＬＳ−ＰＳＫをサポートするＳＬＰ実装に関しては、ＳＬＰは、以下を実装すべきである：
・  ＴＬＳ_ＰＳＫ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
非プロキシモードをサポートするＳＰＣによって以下の暗号スイートを実装することができる。
【０６５５】
・  ＴＬＳ_ＰＳＫ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ.
追加の暗号スイートを選ぶ非プロキシモードをサポートするＳＰＣ実装に関しては、ＳＰＣは、以下を実装すべきである。
【０６５６】
・  ＴＬＳ_ＰＳＫ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
６．６  ＤＣｅｒｔ方法及びユーザバインディング
ＤＣｅｒｔ方法は、ＳＥＴハンドセットを認証するが、（ＧＢＡ方法、ＳＥＫ方法及びＡＣＡ方法と異なり）アクセスネットワーククレデンシャルに結合された認証は実施しない。
【０６５７】
ＳＬＰが相互認証のためにＤＣｅｒｔ方法を使用する場合は、ＳＬＰオペレータは、いずれのＳＵＰＬユーザがＳＥＴと関連付けられるべきかを検証するための何らかのその他のメカニズムが必要である。用語“ユーザバインディング”は、ＳＵＰＬユーザをＳＥＴアイデンティティと関連付けことについて説明するために使用される。
【０６５８】
ＳＥＴの所有権が変わった場合は、既存のＳＵＰＬユーザは、ＳＬＰオペレータに連絡してユーザバインディングを解除させる責任を有する。
【０６５９】
ＳＵＰＬ３．０は、ユーザバインディング手順を規定しないが、１つの可能な手順が第６．６．１節に示される。幾つかのＳＬＰは、ＳＬＰオペレータによって提供されるその他のサービスの一部としてユーザバインディング手順を組み入れることができる。その他の場合は、ユーザバインディングは、配布チェーンの一部であることができる。
【０６６０】
ＳＬＰオペレータは、選択するあらゆる“ユーザバインディング”手順を使用することができるが、次の点に留意すべきである。
【０６６１】
・  ＳＵＰＬユーザをユーザバインディング手順の一部として認証されなければならない。
【０６６２】
○  ＳＵＰＬユーザの認証失敗は、サービスの窃盗を許容することになり、さらに、脅威エージェントが識別されたＳＵＰＬユーザの位置に関してＳＬＰに誤解させるのを許容することになる。
【０６６３】
○  ＳＬＰオペレータは、ユーザ認証に関して自己の既存のメカニズム及び方針を適用することを推奨する。
【０６６４】
・  ＳＥＴをユーザバインディング手順の一部として認証されなければならない。
【０６６５】
○  これに関する理由は微妙である。脅威エージェントがアリスの動きを追跡することを希望し、アリスがＳＥＴアイデンティティ“ＳＥＴ_ＩＤ_Ａ”を有するＳＥＴを所有すると仮定する。脅威エージェントは、合法的なＳＵＰＬユーザとして登録し、彼女自身を認証後に、ＳＥＴアイデンティティ“ＳＥＴ_ＩＤ_Ａ”を有するＳＥＴを所有すると主張する。ＳＬＰオペレータがこのＳＥＴを脅威エージェントのアカウントと関連付けた場合は、脅威エージェントは、（ネットワークによって開始されるセッションを介して）ＳＬＰから定期的な位置更新を入手するための権限を自分自身に付与することができる。しかしながら、アリスがＳＥＴを使用中であるため、脅威エージェントは、実際にはアリスの位置の更新を入手している。ＳＬＰオペレータは、アリスの位置の秘密性を保持することが期待されるため、該攻撃を防止することがＳＬＰオペレータの関心事である。
【０６６６】
６．６．１  ユーザバインディング手順例
ＤＣｅｒｔ方法は、主に、ウェブブラウジング能力を有するＳＥＴを対象にして設計されており、例は、スマートフォン、タブレット又はタッチ画面式マルチメディアプレイヤーを含む。
【０６６７】
該ＳＥＴは、次の仕組みを使用することができる。
【０６６８】
１．ＳＬＰオペレータが、ＳＥＴを使用中にＳＬＰによって所有されるウェブサーバのＵＲＬに接続するようにＳＵＰＬユーザをプロンプトする。
【０６６９】
２．加入者が、ＳＥＴを使用中にウェブサイト（おそらくＷＡＰ）に接続する。
【０６７０】
３．ウェブサーバ及びＳＥＴがＴＬＳを実施する
ａ．ウェブサーバがサーバ証明書を提供し、クライアント証明書を要求する。ウェブサーバの証明書は、ＳＵＰＬサービスのために使用されるＳＬＰサービス証明書のための証明書とは別個であることができる。
【０６７１】
ｂ．ＳＥＴがウェブサーバを認証する
ｃ．ＳＥＴがＳＥＴのデバイス証明書を用いてウェブサーバに認証する。
【０６７２】
ｄ．これで、ウェブサーバは、セキュアなチャネルがデバイス証明書内のＳＥＴアイデンティティ（例えば、ＩＭＥＩ、ＭＥＩＤ又は一連番号）と関連付けられていることを認証している。
【０６７３】
４．ＳＵＰＬユーザが、ウェブサイトと何らかの（範囲外の）認証を実施する。例えば、ウェブサーバは、ＳＬＰ専用のユーザ名／パスワード、又は認定された（ｆｅｄｅｒａｔｅｄ）ユーザ名／パスワード又はその他の加入者詳細、例えば、アドレス、誕生日、等、を要求することができる。
【０６７４】
５．これで、ＳＬＰオペレータが、セキュアな形で加入者をデバイスアイデンティティと関連付けており、この関連付けをＳＬＰ内に格納すべきである。
【０６７５】
追加の実施形態８
ＳＵＰＬ３．０は、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護及びモードＢ  ＳＵＰＬ  ＩＮＩＴ保護を定義している。モードＡ保護は、ＳＬＰがセキュリティの確保されたＵＬＰセッション中にＳＥＴに共有鍵を送信する能力を有することを要求する。この実施形態は、共有鍵パラメータについて説明し、共有鍵を要求及び送信するためにいずれのＵＬＰメッセージが使用されるべきかを示す。従って、この実施形態は、ＳＵＰＬ３．０内に組み入れることができ、節番号は、ＳＵＰＬ３．０の節を指すことができる。
【０６７６】
６．３．３  ＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージのエンド・ツー・  エンド保護
注：ＳＵＰＬ  ＩＮＩＴメッセージのエンド・ツー・エンド保護は、非緊急ＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージのみに適用される。
【０６７７】
第６．３．３節のプロセスは、Ｄ−ＳＬＰ及びＨ−ＳＬＰであるＳＬＰのみに適用され、それらのプロセスは、Ｅ−ＳＬＰには適用されない。
【０６７８】
ＳＵＰＬ  ＩＮＩＴ及びＳＵＰＬ  ＲＥＩＮＩＴメッセージのエンド・ツー・エンド保護のための手順は、ＳＵＰＬ  ＩＮＩＴメッセージとＳＵＰＬ  ＲＥＩＮＩＴメッセージとの間では区別がなく、ＳＵＰＬ  ＩＮＩＴメッセージ及びＳＵＰＬ  ＲＥＩＮＩＴメッセージの両方とも、あたかも同じタイプのメッセージとして処理される。単純化を目的として、それらの手順はＳＵＰＬ  ＩＮＩＴ保護手順と呼び、ＳＵＰＬ  ＩＮＩＴメッセージ及びＳＵＰＬ  ＲＥＩＮＩＴメッセージの両方とも、ＳＵＰＬ  ＩＮＩＴ保護手順を用いて処理される。
【０６７９】
本明細書ではエンド・ツー・エンドＳＵＰＬ  ＩＮＩＴ保護に関して３つの選択肢が提供される。すなわち、Ｎｕｌｌ、モードＡ及びモードＢ。
【０６８０】
・  Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護は、エンド・ツー・エンド完全性保護、エンド・ツー・エンドリプレイ保護及び秘密性保護のいずれも提供しない。Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護のための手順は、第６．３．４節で説明される。
【０６８１】
・  モードＡ  ＳＵＰＬ  ＩＮＩＴ保護は、デフォルトアルゴリズムを用いてのエンド・ツー・エンド完全性保護及びエンド・ツー・エンドリプレイ保護を提供する。モードＡ  ＳＵＰＬ  ＩＮＩＴ保護は、セキュリティが確保されたＵＬＰセッション中にＳＬＰによってＳＥＴに送信された共有鍵を使用する。モードＡ  ＳＵＰＬ  ＩＮＩＴ保護のための手順は、第６．３．５節で説明される。
【０６８２】
・  モードＢ  ＳＵＰＬ  ＩＮＩＴ保護は、デフォルトアルゴリズムを用いてのエンド・ツー・エンド完全性保護及びエンド・ツー・エンドリプレイ保護を提供する。モードＢ  ＳＵＰＬ  ＩＮＩＴ保護は、該当するＰＳＫに基づく方法（ＧＢＡ方法又はＳＥＫ方法）を用いて導き出された共有鍵を使用する。モードＢ  ＳＵＰＬ  ＩＮＩＴ保護のための手順は、第６．３．６節で説明される。
【０６８３】
保護レベルに関する優先順位は次の通りである：
◆  Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護は、最低の優先度を有する。
【０６８４】
◆  モードＡ  ＳＵＰＬ  ＩＮＩＴ保護は、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護よりも高い優先度を有する。
【０６８５】
◆  モードＢ  ＳＵＰＬ  ＩＮＩＴ保護は、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護よりも高い優先度を有する。
【０６８６】
ＳＵＰＬ  ＩＮＩＴメッセージでは、（下表内の）Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータは、現在の保護レベルにより割り当てられる。
【０６８７】
注：この明細書は、将来のバージョンにおいてより高度な保護レベルを追加するのを可能にするように書かれている。この高度な保護は、ＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴのセキュリティを確保するためのその他の方法の交渉を可能にする（例えば、暗号化を可能にする及びアルゴリズムの交渉を可能にする）。
【０６８８】
Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータは、ＳＥＴがＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージの構文解析ができるかどうかを決定するのを援助するために含められている。Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータは、拡張性に関して要求される。
【０６８９】
ＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージは、セキュリティパラメータを含めるために存在するＰｒｏｔｅｃｔｏｒパラメータを有することができ、
Ｐｒｏｔｅｃｔｏｒパラメータの存在は、下表において規定される。
【表１４】
0005876063.tif 000015
【０６９０】
ＳＵＰＬ  ＩＮＩＴ  Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータ値及びＳＵＰＬ  ＩＮＩＴメッセージ及びＳＵＰＬ  ＲＥＩＮＩＴメッセージ内のＰｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータの存在
ＡＣＡに基づく方法をサポートするＳＥＴ又はＤ−ＳＬＰ又はＨ−ＳＬＰは、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護をサポートしなければならない。
【０６９１】
全ＳＥＴがモードＡ  ＳＵＰＬ  ＩＮＩＴ保護手順をサポートすべきである。
【０６９２】
Ｄ−ＳＬＰ又はＨ−ＳＬＰは、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護手順をサポートすることができる。
【０６９３】
ＰＳＫに基づく方法をサポートするＳＥＴ又はＤ−ＳＬＰ又はＨ−ＳＬＰは、モードＢ  ＳＵＰＬ  ＩＮＩＴ保護手順をサポートしなければならない。
【０６９４】
Ｅ−ＳＬＰエンティティは、現在定義されるＳＵＰＬ  ＩＮＩＴ保護には含まれていない。
【０６９５】
６．３．３．１  ＳＵＰＬ  ＩＮＩＴ保護レベルの交渉
次のプロセスは、Ｄ−ＳＬＰ及びＨ−ＳＬＰであるＳＬＰのみに適用され、それらのプロセスは、Ｅ−ＳＬＰには適用されない。
【０６９６】
ＳＵＰＬ  ＩＮＩＴ保護レベルがどのようにして交渉されるかに関する情報を提供するための説明を以下に示した。
【０６９７】
４．ＳＥＴは、有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが存在しないときには（例えば、パワーアップ時又はＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの寿命が切れているとき）Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護を適用しなければならない。初期の保護レベルは、常にＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護である。この状態で、ＳＥＴは、すべてのＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージを処理する、すなわち、いずれのメッセージも暗黙に廃棄されない。ＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージが不具合状態で構文解析される場合は、ＳＥＴは、誤りメッセージをＳＬＰに送信する。
【０６９８】
５．ＳＥＴが、特定のＳＬＰに関してモードＡ又はモードＢ  ＳＵＰＬ  ＩＮＩＴ保護を用いて既に交渉された有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及び有効なリプレイカウンタを有する場合は、ＳＥＴは、交渉されたモード（モードＡ又はモードＢ）を用いてそのＳＬＰからのすべてのＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージを処理する。
【０６９９】
６．ＳＥＴがＳＬＰへの相互に認証されたセキュアなコネクションを確立するときに、
ａ．相互認証のためにＰＳＫに基づく方法（ＧＢＡ又はＳＥＫ）が使用された場合は、モードＢ  ＳＵＰＬ  ＩＮＩＴ保護が適用され、ＰＳＫ−ＴＬＳのハンドシェイクにおいてやり取りされたＢ−ＴＩＤは、Ｋｓ（３ＧＰＰ及び３ＧＰＰ２配備ではＫｓ_ＮＡＦとして使用される）又は３ＧＰＰ及び３ＧＰＰ２配備においてＫｓ_ＮＡＦとして使用されるＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを導き出すために使用することができるＳＥＫに対応する。このＫｓ_ＮＡＫ又はＳＥＫ及び関連付けられたＢ−ＴＩＤは、以下のいずれかまでモードＢ  ＳＵＰＬ  ＩＮＩＴ保護で使用される。
【０７００】
ｉ．鍵が期限切れになるまで。この場合は、ＳＥＴ及びＳＬＰはＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護に戻る
ｉｉ．ＳＥＴ及びＳＬＰが非緊急セッションでＡＣＡ方法を使用するまで。この場合は、ＳＥＴ及びＳＬＰは、以下のステップ３のｂにおいて説明されるようにモードＡ又はＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護に戻る、又は、
ｉｉｉ．ＳＥＴ及びＨ−ＳＬＰが、新しいＢ−ＴＩＤを用いてＴＬＳを確立するためにＧＢＡの又はＳＥＫのブートストラッピング再交渉方法を使用するまで。この場合は、Ｂ−ＴＩＤ及び対応するＫｓ_ＮＡＦ又はＳＥＫがモードＢ  ＳＵＰＬ  ＩＮＩＴ保護のために使用される。
【０７０１】
ｂ．そうでない場合は、ＳＥＴ及びＳＬＰは、ＤＣｅｒｔ方法又はＡＣＡ方法を用いてセキュアなコネクションを確立した。
【０７０２】
ｉ．ＳＥＴが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない場合は、それは、セキュアなセッションの確立に引き続いてそれのＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓパラメータを搬送する次のＵＬＰメッセージ内のＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｉｎｖａｌｉｄＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）でＳＬＰに示す。
【０７０３】
１．モードＡ  ＳＵＰＬ  ＩＮＩＴ保護の場合は、ＳＬＰは、次のＳＵＰＬ  ＥＮＤメッセージにおいてモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順を実施する（第６．３．５．２節）。成功裏のモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順は、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護が適用されることをＳＥＴに示す。成功裏のモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順が生じるまでは、ＳＥＴは、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護を使用するものとする。
【０７０４】
注：ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを更新する方針は、ＳＬＰオペレータの判断である。
【０７０５】
２．ＳＬＰがモードＡ  ＳＵＰＬ  ＩＮＩＴ保護をサポートしない（又はこの特定の時点でモードＡ  ＳＵＰＬ  ＩＮＩＴ保護をサポートしない）場合は、ＳＬＰは、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及びＭｏｄｅＡＫｅｙＬｉｆｅｔｉｍｅパラメータを送信せず、それは、ＳＥＴがＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護を使用するものとすることを示す。
【０７０６】
ｉｉ．ＳＥＴが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するが、有効なＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを有さないか又はリプレイ保護に関する同期化を失っている場合は、それは、セキュアなセッションの確立に引き続いてそれのＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓパラメータを搬送する次のＵＬＰメッセージ内のＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｏｕｔｏｆｓｙｎｃＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）でＳＬＰに示す。
【０７０７】
１．次のＳＵＰＬ  ＥＮＤメッセージでモードＡ再同期化手順を実施する（第６．３．５．３節）。成功裏のモードＡ再同期化手順は、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護が適用されることをＳＥＴに示す。成功裏のモードＡ再同期化手順が生じるまでは、ＳＥＴは、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護を使用するものとする。
【０７０８】
２．ＳＬＰがモードＡ  ＳＵＰＬ  ＩＮＩＴ保護をサポートしない（又はこの特定の時点でモードＡ  ＳＵＰＬ  ＩＮＩＴ保護をサポートすることを希望しない）場合は、ＳＬＰは、モードＡ再同期化手順を実施せず（第６．３．５．３節）、それは、ＳＥＴがＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護を使用するものとすることを示す。）
これは、ＳＥＴがＳＬＰへの新しいＴＬＳコネクションを設定するごとに保護レベルが再交渉されることを意味することに注目すること。
【０７０９】
６．３．３．２  ＳＬＰの観点からの交渉
ＳＥＴとの直近のＩＰセッションがＧＢＡ又はＳＥＫ方法を用いて認証され、及びＳＬＰがＳＥＴに関する現在のＢ−ＴＩＤ及び関連付けられた鍵を有する場合は、
◆  Ｂ−ＴＩＤがＧＢＡを用いて入手された鍵に関するものである場合は、ＳＬＰは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを、直近のＢ−ＴＩＤに対応し、次のように生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦとして割り当てる。
【０７１０】
○  ＦＱＤＮは、Ｈ−ＳＬＰ_ＦＱＤＮであるものとする。
【０７１１】
○  ＳＵＰＬ_ＩＮＩＴ保護のために使用するものとするＧＢＡ  Ｕａセキュリティプロトコル識別子は、ＯＭＮＡレジストリ［ＯＭＮＡ］で定義される。
【０７１２】
◆  Ｂ−ＴＩＤがＳＥＫ方法を用いて導き出された鍵に関するものである場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、第６．１．２．１．２節で定義されるＳＥＫである。
【０７１３】
◆  その他のＳＵＰＬ  ＩＮＩＴ保護は交渉されていないと仮定すると、ＳＬＰは、そのＳＥＴのためにモードＢ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０７１４】
そうでない場合は、ＳＬＰがＳＥＴに関する有効なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及び関連付けられた鍵を有する場合は、ＳＬＰは、そのＳＥＴのためにモードＡ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０７１５】
その他の保護レベルが割り当てられていない場合は、ＳＬＰは、そのＳＥＴのためにＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０７１６】
ＳＬＰは、現在割り当てられているレベルのＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴ保護に対応する（引き渡し前にＳＵＰＬ  ＩＮＩＴメッセージを処理するための）手順を適用する。これは、ＳＵＰＬ  ＩＮＩＴメッセージ内のＰｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータのための該当値を割り当てることを含む。
【０７１７】
６．３．３．３  ＳＥＴの観点からの交渉
ＳＬＰとの直近のＩＰセッションがＧＢＡ又はＳＥＫ方法を用いて認証され、及びＳＥＴがそのＩＰセッションのために用いられる現在のＢ−ＴＩＤ及び関連付けられた鍵を有する場合、
◆  Ｂ−ＴＩＤがＧＢＡを用いて入手された鍵に関するものである場合は、ＳＥＴは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを、直近のＢ−ＴＩＤに対応し、次のように生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦとして割り当てる。
【０７１８】
○  ＦＱＤＮは、Ｈ−ＳＬＰ_ＦＱＤＮであるものとする。
【０７１９】
○  ＳＵＰＬ_ＩＮＩＴ保護のために使用するものとするＧＢＡ  Ｕａセキュリティプロトコル識別子［３ＧＰＰ２４．１０９］は、ＯＭＮＡレジストリ［ＯＭＮＡ］で定義される。
【０７２０】
◆  Ｂ−ＴＩＤがＳＥＫ方法を用いて導き出された鍵に関するものである場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、第６．１．２．１．２節で定義されるＳＥＫである。
【０７２１】
◆  その他のＳＵＰＬ  ＩＮＩＴ保護は交渉されていないと仮定すると、ＳＥＴは、モードＢ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０７２２】
そうでない場合は、ＳＥＴがＳＬＰに関する有効なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及び関連付けられたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、ＳＥＴは、そのＳＬＰのためにモードＡ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０７２３】
その他の保護レベルが割り当てられていない場合は、ＳＥＴは、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護レベルを割り当てる。
【０７２４】
ＳＥＴは、現在割り当てられているレベルのＳＵＰＬ  ＩＮＩＴ保護に対応する（受信されたＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージを処理するための）手順を適用する。
【０７２５】
６．３．３．４  例外手順
ＳＥＴ内部のＳＵＰＬ  ＩＮＩＴ保護パラメータが壊れているとＳＥＴが決定した場合は、ＳＥＴは、ＳＬＰとのＴＬＳセッションを確立しなければならない。
【０７２６】
・  ＧＢＡ認証が使用される場合は、ＳＥＴは、新しい鍵を確立するためのＧＢＡブートストラッピングを開始しなければならない。
【０７２７】
・  ＳＥＫ方法を使用するＳＥＴに関しては、ＳＥＴは、第６．１．２．１．２節において定義されるように、新しい鍵をイネーブルにするためにＳＥＫブートストラッピングを開始しなければならない。
【０７２８】
・  そうでない場合は、ＳＥＴは、第６．３．３．１節のステップ３のｂの手順に従う。
【０７２９】
ＳＬＰがセキュリティコンテキストを失った場合は（例えば、大量のデータ損失）、ＳＬＰは、測位活動を開始する手段を有さないことになる。コンテキストは、Ｋｓ_ＮＡＦ又はＳＥＫが期限切れになるか又はＳＥＴがＳＬＰに接続するときに再確立される。この“ブロックアウトウィンドウ”（ｂｌｏｃｋ  ｏｕｔ  ｗｉｎｄｏｗ）を防止するために、ＳＬＰは、該シナリオから回復するためにすべてのＳＵＰＬ  ＩＮＩＴセキュリティコンテキスト情報が十分な冗長度を持って格納されるようにすべきである。
【０７３０】
６．３．３．５  ＳＥＴにおいてＳＵＰＬ  ＩＮＩＴメッセージを処理するための一般的手順
以下の手順は、受信されたＳＵＰＬ  ＩＮＩＴメッセージを処理する方法を決定するためにＳＥＴによって適用される。
【０７３１】
１．ＳＥＴが送信ＳＬＰ（ＳＵＰＬ  ＩＮＩＴメッセージを送信したＳＬＰ）を識別する。
【０７３２】
ａ．ＳＵＰＬ  ＩＮＩＴメッセージ内にＤ−ＳＬＰ  ＦＱＤＮパラメータが存在する場合は、ＳＥＴは、このパラメータを用いて送信ＳＬＰを識別するものとする。
【０７３３】
ｉ．ＳＥＴが識別されたＤ−ＳＬＰと既存の関係を有さない場合は、ＳＥＴは、ＳＵＰＬ  ＩＮＩＴメッセージを暗黙に廃棄するものとし、現在の手順から出る。
【０７３４】
ｉｉ．そうでない場合は、ＳＥＴは、ステップ２に進む。
【０７３５】
ｂ．ＳＵＰＬ  ＩＮＩＴメッセージ内にＤ−ＳＬＰ  ＦＱＤＮパラメータが存在しない場合は、ＳＥＴは、送信ＳＬＰをＳＥＴのＨ−ＳＬＰとして識別する。
【０７３６】
２．ＳＥＴが、送信ＳＬＰのために割り当てられたＳＵＰＬ  ＩＮＩＴ保護レベルに基づいて初期フィルタリングを実施する：
ａ．送信ＳＬＰのためにＮｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護が割り当てられた場合は、ＳＥＴは、Ｎｕｌｌ  ＳＵＰＬ  ＩＮＩＴ保護手順を実施し、現在の手順から出る。
【０７３７】
ｂ．送信ＳＬＰのためにモードＡ又はモードＢ  ＳＵＰＬ  ＩＮＩＴ保護が割り当てられた場合は、
ｉ．ＳＵＰＬ  ＩＮＩＴメッセージにＰｒｏｔｅｃｔｏｒパラメータが入っていない場合は、ＳＥＴは、ＳＵＰＬ  ＩＮＩＴメッセージを暗黙に廃棄し、現在の手順から出る。
【０７３８】
ｉｉ．ＳＵＰＬ  ＩＮＩＴメッセージにＰｒｏｔｅｃｔｏｒパラメータが入っている場合は、ＳＥＴは、第６．３．５節又は第６．３．６節のそれぞれの該当するモードＡ  ＳＵＰＬ  ＩＮＩＴ保護手順又はモードＢ  ＳＵＰＬ  ＩＮＩＴ保護手順を実施する。ＳＥＴは、送信ＳＬＰと関連付けられたＳＵＰＬ  ＩＮＩＴ  ＲＯＯＴ鍵のうちのいずれがＳＵＰＬ  ＩＮＩＴメッセージの処理のために使用されるべきかを識別するためにＰｒｏｔｅｃｔｏｒパラメータ内のＫｅｙＩｄｅｎｔｉｆｉｅｒを使用する。
【０７３９】
６．３．５  モードＡ  ＳＵＰＬ  ＩＮＩＴ保護レベルに関する仕様
６．３．５．１  モードＡ  ＳＵＰＬ  ＩＮＩＴ保護のための鍵識別子
モードＡ  ＳＵＰＬ  ＩＮＩＴ保護は、ＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージとともに送信することができる２つの鍵識別子、すなわち、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及びＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、を使用する。
【０７４０】
・  ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹと関連付けられたグローバルで一意の、長期の鍵識別子である。ＳＬＰは、ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのための新しい値をプロビジョニングするときのみに新しいＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒをＳＥＴに提供する。
【０７４１】
・  ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けられた短期のアイデンティティ（仮名）である。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒが有効である期間の間グローバルで一意であるものとする。ＳＥＴ及びＳＬＰは、第６．３．５．５節及び第６．３．５．６節において説明されるようにＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの値を同期化する。
【０７４２】
ＳＬＰは、典型的には、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを基本的ＳＵＰＬ  ＩＮＩＴプロテクタ内のＫｅｙＩｄｅｎｔｉｆｉｅｒとして使用する。ＳＥＴは、基本的ＳＵＰＬ  ＩＮＩＴプロテクタを検証するためにいずれのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが使用されるべきかを決定するためにＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを使用する。
【０７４３】
ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、典型的には、ＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージでは送信されず、その理由は、観察者が複数のＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージを１つの共通のＳＥＴユーザと関連付けるのを可能にするためである。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの目的は、脅威エージェントが複数のＳＵＰＬ  ＩＮＩＴメッセージを１人のＳＥＴユーザと関連付けるためにＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを使用するのを防止することである。ＳＬＰ及びＳＥＴのみがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒをＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けることができるようにすべきである。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを変更する頻度は、主に、ＳＥＴユーザの判断である。ＳＬＰは、ＳＬＰ方針に基づいてＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのための新しい値を確立することを選択することができる。
【０７４４】
しかしながら、ＳＬＰがより長期のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを基本的ＳＵＰＬ  ＩＮＩＴプロテクタ内のＫｅｙＩｄｅｎｔｉｆｉｅｒとして使用することを希望する状況が存在する。例えば、ＳＥＴが基本的ＳＵＰＬ  ＩＮＩＴプロテクタ内のＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを用いて複数のＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージに応答していないと仮定する。ＳＬＰは、ＳＥＴがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒに関する同期化を失っていることを懸念するおそれがある。ＳＥＴ及びＳＬＰは、長期的なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒに関しての方が同期化状態を維持する可能性が高い。従って、ＳＬＰは、同期化を失うことがＳＥＴがＳＵＰＬ  ＩＮＩＴメッセージを検証するのを妨げないようにするために基本的ＳＵＰＬ  ＩＮＩＴプロテクタ内のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを用いてＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴメッセージを送信することができる。
【０７４５】
６．３．５．２  モードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのための値は、ＳＬＰが（セキュアなＳＵＰＬセッションにおけるＳＥＴへのＳＵＰＬ  ＥＮＤメッセージ内で）新しいＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒパラメータ、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒパラメータ、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹパラメータ及びＭｏｄｅＡＫｅｙＬｉｆｅｔｉｍｅパラメータを送信することによって確立される。引き渡しが成功である場合は、ＳＬＰ及びＳＥＴは、このモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順を成功であるとみなす。
【０７４６】
ＭｏｄｅＡＫｅｙＬｉｆｅｔｉｍｅパラメータは、鍵が有効でなくなるときのＵＴＣ時間を含む。
【０７４７】
６．３．５．３  モードＡ再同期化手順
ＳＬＰは、次のステップを用いてＳＥＴとＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのための新しい値を確立する：
１．ＳＬＰが、（セキュアなＳＵＰＬセッションでのＳＥＴへのＳＵＰＬ  ＥＮＤメッセージにおいて）現在のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及び新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒパラメータをＳＥＴに送信する。引き渡しが成功である場合は、ＳＬＰは、このモードＡ再同期化手順を成功であるとみなす。
【０７４８】
２．ＳＥＴが、受信されたＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを、ＳＥＴがそのＳＬＰのために現在割り当てている有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ値のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと比較する。
【０７４９】
ａ．ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ値が異なる場合は、これは、ＳＥＴにおいて割り当てられたＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの値が壊れていることを示し、次のステップが実施される：
ｉ．ＳＥＴがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを廃棄し、このモードＡ再同期化手順は失敗であるとみなす。
【０７５０】
ｉｉ．ＳＥＴが第６．３．３．４節の例外手順を開始する。
【０７５１】
ｂ．受信されたＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒが有効なＭｏ  ｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと等しい場合は、
ｉ．ＳＥＴは、新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを対応するＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付ける。
【０７５２】
ｉｉ．ＳＥＴは、このモードＡ再同期化手順を成功であるとみなす。
【０７５３】
６．３．５．４  モードＡ  ＳＵＰＬ  ＩＮＩＴ保護及び基本的ＳＵＰＬ  ＩＮＩＴプロテクタ
モードＡ  ＳＵＰＬ  ＩＮＩＴ保護は、基本的ＳＵＰＬ  ＩＮＩＴプロテクタ及び第０節において定義される関連付けられた手順を使用し、さらなる明確化のために以下を示した。
【０７５４】
◆  ＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅ：ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ又はＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのいずれかが使用されることを示す。
【０７５５】
◆  ＫｅｙＩｄｅｎｔｉｆｉｅｒ：ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅに適宜対応するＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ又はＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのいずれかに対応する。
【０７５６】
◆  ＢａｓｉｃＭＡＣは、上記のＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けられたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いて、ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｍｏｄｅ  Ａ  ＩＫ”）を用いて計算される。
【０７５７】
６．３．５．５  ＳＬＰ手順
モードＡ専用ＳＬＰ手順は、ＳＵＰＬ  ＩＮＩＴ  ＲＯＯＴ  ＫＥＹ確立、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの期限切れ、及びＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
【０７５８】
モードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順は、第６．３．５．２節において規定される。ＳＬＰは、（ＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｉｎｖａｌｉｄＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）における）ＳＥＴによる同期外れ表示又はＳＬＰの（範囲外の）内部判断に応答してモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順を実施することができる。すなわち、ＳＬＰは、ＳＥＴによる対応する表示がないときでもＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを（関連付けられたパラメータとともに）送信することができる。
【０７５９】
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及び関連付けられたパラメータは、以下のうちの早い方の後にＳＬＰにおいて有効であることを停止するものとする
・  関連付けられたＭｏｄｅＡ  ＫｅｙＩｄｅｎｔｉｆｉｅｒの寿命、及び
・  その後の成功したモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立時（第６．３．５．２節）。
【０７６０】
モードＡ再同期化手順は、第６．３．５．３節において規定される。ＳＬＰは、（ＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｏｕｔｏｆｓｙｎｃＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）における）ＳＥＴによる同期外れ表示又はＳＬＰの（範囲外の）内部判断に応答してモードＡ再同期化手順を実施することができる。すなわち、ＳＬＰは、ＳＥＴによる対応する表示がないときでもＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを送信することができる。
【０７６１】
成功したモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順又は成功したモードＡ再同期化手順に引き続き、ＳＬＰは、ＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒを０ｘ００００にリセットする。
【０７６２】
６．３．５．６  ＳＥＴ手順
モードＡ専用ＳＥＴ手順は、ＳＵＰＬ  ＩＮＩＴ  ＲＯＯＴ_ＫＥＹ確立、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの期限切れ、及びＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
【０７６３】
モードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順は、第６．３．５．２節において規定される。ＳＥＴは、セキュアなセッション確立に引き続いてＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓパラメータを搬送するＵＬＰメッセージにおいて（ＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｉｎｖａｌｉｄＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）における）有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹをＳＥＴ内において有さないことを示すことによってモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順をトリガするのを試みることができる。
【０７６４】
確立されたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及び関連付けられたパラメータは、以下のうちの早い方の後にＳＥＴにおいて無効であるとみなされるものとする
・  関連付けられたＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの寿命。
【０７６５】
・  その後の成功したモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立（第６．３．５．２節）から５分後。この時間遅延は、最後のモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順の前に送信されたＳＵＰＬ  ＩＮＩＴメッセージの引き渡しを考慮したものであり、このため、ＳＵＰＬ  ＩＮＩＴメッセージは、前のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いて保護しなければならないことになる。
【０７６６】
・  ＳＥＴが、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及びＭｏｄｅＡＫｅｙＬｉｆｅｔｉｍｅの値の崩壊を検出した時点。崩壊が発生した場合は、ＳＥＴは、第６．３．３．４節の例外手順を開始するものとする。
【０７６７】
モードＡ再同期化手順は、第６．３．５．３節において規定される。ＳＥＴは、セキュアなセッション確立に引き続いてＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓパラメータを搬送するＵＬＰメッセージにおいて（ＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｏｕｔｏｆｓｙｎｃＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）における）ＳＥＴ内での同期化喪失を示すことによってモードＡ再同期化手順をトリガするのを試みることができる。
【０７６８】
成功したモードＡ  ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順又は成功したモードＡ再同期化手順に引き続き、ＳＥＴは、ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒのための使用された値のキャッシュをクリアする（ＳＬＰもＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒを０ｘ００００にリセットしていることになるため）。
【０７６９】
６．３．７  基本的ＳＵＰＬ  ＩＮＩＴプロテクタを使用するための仕様
基本的ＳＵＰＬ  ＩＮＩＴプロテクタは、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護及びモードＢ  ＳＵＰＬ  ＩＮＩＴ保護の両方のために使用され、次のパラメータを含む：
◆  ＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅ
◆  ＫｅｙＩｄｅｎｔｉｆｉｅｒ：長さ＝８オクテット
◆  ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ：長さ＝２オクテット
◆  ＢａｓｉｃＭＡＣ：長さ＝４オクテット
ＢａｓｉｃＭＡＣパラメータは、以下のように生成される。
【０７７０】
◆  ＢａｓｉｃＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ／ＲＥＩＮＩＴ’）、ここで、
◆  ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫは、モードＡ  ＳＵＰＬ  ＩＮＩＴ保護及びモードＢ  ＳＵＰＬ  ＩＮＩＴ保護のそれぞれに関する第６．３．５節及び第６．３．６節により導き出される。
【０７７１】
◆  ＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴ’は、ＢａｓｉｃＭＡＣ以外の全パラメータが割り当てられ、ＭＡＣパラメータがすべてゼロに設定されたＳＵＰＬ  ＩＮＩＴ／ＲＥＩＮＩＴに対応する
◆  ＨＭＡＣ−ＳＨＡ２５６−３２及びＨＭＡＣ−ＳＨＡ２５６−１２８は、［ＨＭＡＣ］において規定される。
【０７７２】
６．１．１．２  サポートされる認証方法概要（情報用）
（１）汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく。汎用ブートストラッピングアーキテクチャ（ＧＢＡ）［３ＧＰＰ  ３３．２２０］、［３ＧＰＰ  ３３．２２２］、［３ＧＰＰ２Ｓ．Ｓ０１１４］、［３ＧＰＰ  ２４．１０９］を有するＴＬＳ−ＰＳＫ。ＧＢＡは、既存の３ＧＰＰ／３ＧＰＰ２認証メカニズムを用いて導き出される共有される秘密に基づいて相互認証能力を提供する。
【０７７３】
◆  ＳＥＴ及びＳＬＰは、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）を有するＴＬＳ−ＰＳＫを用いて相互に認証される。
【０７７４】
（２）ＳＥＫに基づく（ＷＩＭＡＸ  ＳＬＰのみに適用）。
【０７７５】
◆  ＳＥＴ及びＳＬＰは、ＳＥＫを有するＴＬＳ−ＰＳＫを用いて相互に認証される。ＳＥＫ方法の詳細は、第６．１．２．１．２節において見つけることができる。
【０７７６】
（３）デバイス証明書（ＤＣｅｒｔ）に基づく。このＡＮから独立した方法は、次を用いるＴＬＳを使用する
◆  ＳＥＴに対してＳＬＰを認証するためのＲＳＡサーバ証明書、
◆  ＳＬＰに対してＳＥＴを認証するためのＲＳＡクライアント証明書。
【０７７７】
（４）代替クライアント認証（ＡＣＡ）に基づく。これは、次を用いるＴＬＳを使用する
◆  ＳＥＴに対してＳＬＰを認証するためのＲＳＡ証明書、
◆  ＳＬＰに対するＳＥＴの代替クライアント認証（第６．１．４節参照）。この場合は、ＳＬＰは、ＳＥＴ識別子（ＭＳＩＳＤＮ、等）と関連付けられたＩＰアドレスをベアラネットワークに確認させることによってＳＥＴを認証する。
【０７７８】
（５）ＳＬＰ専用。これは、ＳＬＰがＳＥＴを認証できないシナリオにおいて使用される。この方法は、非緊急時のためには使用しないものとする。ＳＥＴは、この方法とＡＣＡ基づく場合を区別することができない。これは、以下を用いてＴＬＳを使用する
◆  ＳＥＴに対してＳＬＰを認証するためのＲＳＡ証明書
◆  ＳＥＴは認証されない。
【０７７９】
６．１．２．１．１  ＧＢＡ方法をサポートする配備
（ＧＢＡ［３ＧＰＰ  ３３．２２０］、［３ＧＰＰ  ２４．１０９］、［３ＧＰＰ２  Ｓ．Ｓ０１０９］をサポートする配備の場合は、共有鍵は次のようにして確立される：
・  ＳＬＰが（ＩＰ通信のセキュリティを確保するために及びＳＵＰＬ  ＩＮＩＴ及び／又はＳＵＰＬ  ＲＥＩＮＩＴを保護するために）鍵素材をＢＳＦに要求するときには、ＳＬＰは、ＵＳＳ（ユーザセキュリティ設定）も要求しなければならない。ＵＳＳは、永久的なユーザアイデンティティ（例えば、ＩＭＰＩ、ＩＭＳＩ又はＭＳＩＳＤＮ）を含まなければならない。
【０７８０】
・ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するためには、ＳＥＴ及びＳＬＰは、ＧＢＡ（［３ＧＰＰ  ３３．２２０］、［３ＧＰＰ  ２４．１０９］、［３ＧＰＰ  ３３．２２２］、［３ＧＰＰ２  Ｓ．Ｓ０１０９］）を用いてＴＬＳ−ＰＳＫにより共有秘密鍵を導き出し及び動作しなければならない。ＳＬＰは、ＳＬＰを指定する適切に定義されたドメイン名ＳＬＰ_Ａｄｄｒｅｓｓ_ＦＱＤＮ、例えば、ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ、を有さなければならない。ＴＬＳ−ＰＳＫのために使用されるものとするＧＢＡ  Ｕａセキュリティプロトコル識別子がＯＭＮＡレジストリ［ＯＭＮＡ］内で定義されている。ＳＬＰは、ＢＳＦによって提供された永久的なユーザアイデンティティが対応するセキュリティが確保されたコネクションを通じてＳＬＰによって受信されたＳＵＰＬメッセージ内のＳＥＴアイデンティティに対応することを確認しなければならない。
【０７８１】
・ＳＵＰＬ  ＩＮＩＴ及び／又はＳＵＰＬ  ＲＥＩＮＩＴのＭＡＣ保護に関して、ＧＢＡ（［３ＧＰＰ  ３３．２２０］、［３ＧＰＰ  ２４．１０９］）により鍵が導き出される。ＳＵＰＬ  ＩＮＩＴ保護のために使用されるものとするＧＢＡ  Ｕａセキュリティプロトコル識別子がＯＭＮＡレジストリ［ＯＭＮＡ］内で定義されている。ＳＵＰＬ  ＩＮＩＴメッセージ（又はＳＵＰＬ  ＲＥＩＮＩＴメッセージ）に含まれるｂａｓｉｃＭＡＣのＫｅｙＩｄｅｎｔｉｆｉｅｒは、Ｋｓ_ＮＡＦが生成されるＫｓのＢ−ＴＩＤでなければならない。注：Ｄ／Ｈ−ＳＬＰによるＢＳＦへのＳＵＰＬ  ＩＮＩＴ保護鍵の要求は、典型的には、Ｄ／Ｈ−ＳＬＰによるＩＰ通信のセキュリティを確保する鍵の要求と同時に発生することになる。
【０７８２】
・ＳＥＴは、有効なＫｓが常にプロビジョニングされていることを確認しなければならない。有効なＫｓが存在しない場合は、ＳＥＴは、ＫｓをプロビジョニングするためのＧＢＡブートストラッピング手順を開始しなければならない。新しいＵＩＣＣ（ＵＳＩＭ／ＳＩＭ／Ｒ−ＵＩＭ）がＳＥＴによって検出されるごとに新しいＫｓが確立されなければならない。さらに、ＳＥＴは、（ホームネットワークオペレータによって設定された）Ｋｓ_ＮＡＦの寿命が経過しているときには新しい共有鍵を確立しなければならない。
【表１５−１】
0005876063.tif 000016
【表１５−２】
0005876063.tif 000017
【表１５−３】
0005876063.tif 000018
【表１５−４】
0005876063.tif 000019
【表１５−５】
0005876063.tif 000020
【表１５−６】
0005876063.tif 000021
【表１５−７】
0005876063.tif 000022
【表１５−８】
0005876063.tif 000023
【表１５−９】
0005876063.tif 000024
【０７８３】
ＳＥＴ能力パラメータ
９．２．８  ＳＵＰＬ  ＥＮＤ  
【表１６−１】
0005876063.tif 000025
【表１６−２】
0005876063.tif 000026
【表１６−３】
0005876063.tif 000027
【０７８４】
ＳＵＰＬ  ＥＮＤメッセージ
１０．ｘ  ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅ
ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅパラメータは、ＳＬＰからＳＥＴにモードＡ  ＳＵＰＬ  ＩＮＩＴ保護のための鍵を送信するためのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順（第６．３．５．２節参照）において使用される。
【表１７−１】
0005876063.tif 000028
【表１７−２】
0005876063.tif 000029
【０７８５】
ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｅｓｐｏｎｓｅ
１１．４  メッセージ拡張（ＳＵＰＬバージョン３）
ULP-Version-3-message-extensions DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
EXPORTS
Ver3-SUPL-INIT-extension,Ver3-SUPL-START-extension,Ver3-SUPL-POS-INIT-extension, Ver3-SUPL-END-extension, Ver3-SUPL-RESPONSE-extension, Ver3-SUPL-TRIGGERED-
RESPONSE-extension, Ver3-SUPL-TRIGGERED-START-extension, Ver3-SUPL-TRIGGERED-
STOP-extension, Ver3-SUPL-SET-INIT-extension, Ver3-SUPL-NOTIFY-extension, Ver3-SUPL-
NOTIFY-RESPONSE-extension, Ver3-SUPL-REPORT-extension, QoPCapabilities,
RelativePositioningCapabilities, CivicPositioningCapabilities;
IMPORTS
Ver, QoP, FQDN
FROM ULP-Components
CircularArea, EllipticalArea, PolygonArea
FROM Ver2-ULP-Components
PosProtocolVersion3GPP, PosProtocolVersion3GPP2
FROM ULP-Version-2-parameter-extensions
PosProtocolVersionOMA
FROM ULP-Version-3-parameter-extensions
PosPayLoad
FROM SUPL-POS
Notification
FROM SUPL-INIT
SessionID
FROM ULP-Components
NotificationResponse
FROM SUPL-NOTIFY-RESPONSE
maxnumSessions, SessionList
FROM SUPL-REPORT
OMA-LPPe-RelativeLocation,OMA-LPPe-ReferencePointUniqueID,OMA-LPPe-CivicLocation
FROM OMA-LPPE;
[幾つかの不変の部分は、簡潔さを目的として削除した]
Ver3-SUPL-END-extension ::= SEQUENCE {
locationURISet                LocationURISet  OPTIONAL,
slpAuthorization      SLPAuthorization        OPTIONAL,
relativePosition              OMA-LPPe-RelativeLocation OPTIONAL,
civicPosition        OMA-LPP-CivicLocation OPTIONAL,
sULPINITKeyResponse   SULPINITKeyResponse OPTIONAL,
...}
[幾つかの不変の部分は、簡潔さを目的として削除した]
SULPINITKeyResponse ::= CHOICE {
modeAKeyEstablishment                ModeAKeyEstablishment,
modeAResynch                  ModeAResynch,
...}
ModeAKeyEstablishment ::= SEQUENCE {
modeAKeyIdentifier                  OCTET STRING(SIZE (8)),
temporaryModeAKeyIdentifier   OCTET STRING(SIZE (8)),
sUPLINITROOTKEY                              BIT STRING(SIZE (128)),
ModeAKeyLifetime                              UTCTime,
...}
ModeAResynch ::= SEQUENCE {
modeAKeyIdentifier                  OCTET STRING(SIZE (8)),
temporaryModeAKeyIdentifier   OCTET STRING(SIZE (8)),
...}
END
11.6    パラメータ拡張（ＳＵＰＬバージョン３）
ULP-Version-3-parameter-extensions DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
EXPORTS
Ver3-PosProtocol-extension,Ver3-SETCapabilities-extension,Ver3-SLPCapabilities-extension, Ver3-TriggerParams-extension, Ver3-ServiceSupported-extensions;
IMPORTS
QoPCapabilities, RelativePositioningCapabilities, CivicPositioningCapabilities
FROM ULP-Version-3-message-extensions;
Ver3-PosProtocol-extension ::= SEQUENCE {
posProtocolVersionLPPe        PosProtocolVersionOMA OPTIONAL,
...}
Ver3-SETCapabilities-extension ::= SEQUENCE {
qoPCapabilities QoPCapabilities OPTIONAL,
civicPositioningCapabilities CivicPositioningCapabilities OPTIONAL,
relativePositioningCapabilities                RelativePositioningCapabilities
OPTIONAL,
d-SLP-Provision-from-H-SLP                              BOOLEAN,
e-SLP-Provision-from-H-SLP                              BOOLEAN,
d-SLP-Provision-from-Proxy-D-SLP                BOOLEAN,
e-SLP-Provision-from-Proxy-E-SLP                BOOLEAN,
d-SLP-Notification-to-H-SLP                            BOOLEAN,
sensorSupport                                     BOOLEAN,
sUPLINITRootKeyStatus   SUPLINITRootKeyStatus OPTIONAL,
...}
SUPLINITRootKeyStatus ::= ENUMERATED {invalidSUPLINITRootKey(0),
outofsyncSUPLINITRootKey(1), ...}
[幾つかの不変の部分は、簡潔さを目的として削除した]
END
追加の実施形態９
Ｐｒｏｔｅｃｔｏｒ  Ｌｅｖｅｌパラメータに関する先行定義は、基本的保護がモードＡ保護及びモードＢ保護に変更されていることを反映していないことがある（モードＢ保護は、前基本的保護と同じである）。先行のＡＳＮ．１定義も更新することができる。従って、以下の提案は、モードＡ及びモードＢ保護を反映させ及びＡＳＮ．１第１１．４節を更新するように第１０．２５節を修正することを目的としてＳＵＰＬ３．０に組み入れることができる（節番は、ＳＵＰＬ３．０の節を指すことができる）。
【０７８６】
１０．２２  保護レベル
Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータは、ＳＵＰＬ  ＩＮＩＴ／ＳＵＰＬ  ＲＥＩＮＩＴメッセージのための保護レベルを定義する。
【表１８】
0005876063.tif 000030
【０７８７】
１１．３  メッセージ拡張（ＳＵＰＬバージョン２）
ULP-Version-2-message-extensions DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
EXPORTS
Ver2-SUPL-INIT-extension,Ver2-SUPL-START-extension,Ver2-SUPL-RESPONSE-extension,Ver2-SUPL-POS-INIT-extension,Ver2-SUPL-POS-extension, Ver2-SUPL-END-extension;
IMPORTS
SLPAddress, Position, Ver
FROM ULP-Components
SETCapabilities
FROM SUPL-START
SupportedNetworkInformation, GNSSPosTechnology, MultipleLocationIds, UTRAN-GPSReferenceTimeResult, UTRAN-GANSSReferenceTimeResult, UTRAN-GPSReferenceTimeAssistance, UTRAN-GANSSReferenceTimeAssistance, SPCSETKey, SPCTID, SPCSETKeylifetime, ThirdParty, ApplicationID
FROM Ver2-ULP-Components
TriggerType
FROM SUPL-TRIGGERED-START
Ver3-ProtectionLevel-extension
FROM ULP-Version-3-parameter-extensions;
[幾つかの不変の部分は、簡潔さを目的として削除した]
ProtectionLevel ::= SEQUENCE {
protlevel              ProtLevel,
basicProtectionParams  BasicProtectionParams   OPTIONAL, -- not applicable in SUPL 3.0
...,
ver3-ProtectionLevel-extension  Ver3-ProtectionLevel-extension OPTIONAL}
ProtLevel ::= ENUMERATED {
nullProtection(0), basicProtection(1), ..., ver3-modeAProtection(2), ver3-modeBProtection(3)} − basicProtection(1) is not applicable in SUPL 3.0
[幾つかの不変の部分は、簡潔さを目的として削除した]
END
１１．６  パラメータ拡張（ＳＵＰＬバージョン３）
ULP-Version-3-parameter-extensions DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
EXPORTS
Ver3-PosProtocol-extension,Ver3-SETCapabilities-extension,Ver3-SLPCapabilities-extension, Ver3-TriggerParams-extension, Ver3-ServiceSupported-extensions, Ver3-ProtectionLevel-extension;
IMPORTS
QoPCapabilities, RelativePositioningCapabilities, CivicPositioningCapabilities
FROM ULP-Version-3-message-extensions;
[幾つかの不変の部分は、簡潔さを目的として削除した]
Ver3-ProtectionLevel-extension ::= SEQUENCE {
keyIdentifierType            KeyIdentifierType,
keyIdentifier                OCTET STRING(SIZE (8)),
basicReplayCounter    INTEGER(0..65535),
basicMAC                      BIT STRING(SIZE (32)),
...}
KeyIdentifierType ::= ENUMERATED {
ModeAKeyIdentifier(0), TemporaryModeAKeyIdentifier(1), ModeBKeyIdentifier(2), ...}
END
ここにおいて開示される実施形態と関係させて説明される様々な例示的な論理ブロック、コンフィギュレーション、モジュール、回路、及びアルゴリズム上のステップは、電子ハードウェア、処理デバイス、例えば、ハードウェアプロセッサ、によって実行されるコンピュータソフトウェア、又は両方の組み合わせとして実装することができることを当業者はさらに理解するであろう。上記においては、様々な例示的なコンポーネント、ブロック、コンフィギュレーション、モジュール、回路、及びステップが、それらの機能の観点で一般的に説明されている。該機能がハードウェアとして又は実行可能なソフトウェアとして実装されるかは、特定の用途及び全体的システムに対する設計上の制約事項に依存する。当業者は、説明されている機能を各々の特定の用途に合わせて様々な形で実装することができるが、該実装決定は、本開示の適用範囲からの逸脱を生じさせるものであるとは解釈されるべきではない。
【０７８８】
ここにおいて開示される実施形態と関係させて説明される方法又はアルゴリズムのステップは、直接ハードウェア内に、プロセッサによって実行されるソフトウェアモジュール内に、ファームウェア内に、又はそれらの組み合わせ内において具現化することができる。ソフトウェア又は論理モジュールは、非一時的な記憶媒体、例えば、ランダムアクセスメモリ（ＲＡＭ）、磁気抵抗ランダムアクセスメモリ（ＭＲＡＭ）、スピン−トルク転送ＭＲＡＭ（ＳＴＴ−ＭＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、プログラマブル読み取り専用メモリ（ＰＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、レジスタ、ハードディスク、取り外し可能なディスク、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、デジタルバーサタイルディスク（ＤＶＤ）、Ｂｌｕ−ｒａｙディスク（登録商標）、又は当業において知られるその他の形態の記憶媒体、内に常駐することができる。上記の組み合わせもコンピュータによって読み取り可能な媒体の適用範囲内に含められるべきである。例は、データ構造を用いて符号化されたコンピュータによって読み取り可能な媒体と、コンピュータプログラムを用いて符号化されたコンピュータによって読み取り可能な媒体と、を含む。コンピュータによって読み取り可能な媒体は、製造品の形態をとることができる。典型的な記憶媒体は、プロセッサに結合され、このため、プロセッサは、記憶媒体から情報を読み取ること又は記憶媒体に情報を書き込むことができる。代替においては、記憶媒体は、プロセッサと一体化することができる。プロセッサ及び記憶媒体は、特定用途向け集積回路（ＡＳＩＣ）内に常駐することができる。ＡＳＩＣは、コンピューティングデバイス又はユーザ端末内に常駐することができる。代替においては、プロセッサ及び記憶媒体は、コンピューティングデバイス又はユーザ端末において個別のコンポーネントとして常駐することができる。従って、ここにおいて説明される方法は、用途に依存して様々な手段によって実装することができる。例えば、これらの方法は、ハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせ内に実装することができる。
【０７８９】
ＡＳＩＣ及びプロセッサに加えて、又はＡＳＩＣ及びプロセッサの代替として、ハードウェア実装は、ここにおいて説明される機能を果たすように設計されたデジタル信号処理デバイス（ＤＳＰＤ）、プログラマブル論理デバイス（ＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子デバイス、その他の電子ユニット、又はそれらの組み合わせを含むことができる。ここにおいて、用語“制御論理”は、ソフトウェア、ハードウェア、ファームウェア、又は組み合わせによって実装された論理を包含する。
【０７９０】
ファームウェア及び／又はソフトウェアを含む実装に関しては、方法は、ここにおいて説明される機能を果たすモジュール（例えば、手順、関数、等）を用いて実装することができる。ここにおいて説明される方法を実装する際には、命令を有形に具現化させるあらゆる機械によって読み取り可能な媒体を使用することができる。例えば、ソフトウェアコードは、メモリに格納して処理ユニットによって実行することができる。メモリは、処理ユニット内に又は処理ユニットの外部に実装することができる。ここにおいて用いられる場合において、用語“メモリ”は、あらゆるタイプの長期、短期、揮発性、非揮発性、又はその他の記憶デバイスを意味し、いずれの特定のタイプの又は数のメモリにも限定されず、及びメモリが格納される媒体のタイプに限定されない。ファームウェア及び／又はソフトウェアが関係する実装においては、機能は、コンピュータによって読み取り可能な媒体において１つ以上の命令又はコードとして格納することができる。
【０７９１】
本開示は、Ｗｉ−Ｆｉ／ＷＬＡＮ又はその他の無線ネットワークと関係させて実装することができる。Ｗｉ−Ｆｉ／ＷＬＡＮ信号に加えて、無線／移動局は、衛星から信号を受信することもでき、それらは、全地球測位システム（ＧＰＳ）、ガリレオ、ＧＬＯＮＡＳＳ（グロナス）、ＮＡＶＳＴＡＲ（ナブ
スター）、ＱＺＳＳ、これらのシステムの組み合わせからの衛星を使用するシステム、将来開発されるあらゆるＳＰＳからであることができ、各々は、概して、衛星測位システム（ＳＰＳ）又はＧＮＳＳ（全地球航法衛星システム）と呼ばれる。本開示は、擬似衛星（シュードライト）又は擬似衛星を含むシステムの組み合わせと関係させて実装することもできる。本開示は、フェムトセル又はフェムトセルを含むシステムの組み合わせと関係させて実装することができる。
【０７９２】
本開示は、様々な無線通信ネットワーク、例えば、ワイヤレスワイドエリアネットワーク（ＷＷＡＮ）、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）、等、と関係させて実装することができる。用語“ネットワーク”及び“システム”は、互換可能な形でしばしば用いられる。用語“ｐｏｓｉｔｉｏｎ”（位置）及び“ｌｏｃａｔｉｏｎ）”（位置）は、互換可能な形でしばしば用いられる。ＷＷＡＮは、符号分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交周波数分割多元接続（ＯＦＤＭＡ）ネットワーク、単一搬送波周波数分割多元接続（ＳＣ−ＦＤＭＡ）ネットワーク、ロングタームエボリューション（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ））ネットワーク、ＷｉＭＡＸ（ＩＥＥＥ８０２．１６）ネットワーク、等であることができる。ＣＤＭＡネットワークは、１つ以上の無線アクセス技術（ＲＡＴ）、例えば、ｃｄｍａ２０００、Ｗｉｄｅｂａｎｄ−ＣＤＭＡ（Ｗ−ＣＤＭＡ）、等、を実装することができる。ｃｄｍａ２０００は、ＩＳ−９５規格と、ＩＳ−２０００規格と、ＩＳ−８５６規格と、を含む。ＴＤＭＡネットワークは、グローバル移動体通信システム（ＧＳＭ）、デジタルアドバンストモバイルフォンシステム（Ｄ−ＡＭＰＳ）、又は何らかのその他のＲＡＴ、を実装することができる。ＧＳＭ及びＷ−ＣＤＭＡは、“３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ”（３ＧＰＰ）という名称のコンソーシアムからの文書で説明される。ｃｄｍａ２０００は、“３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ２”（３ＧＰＰ２）という名称のコンソーシアムからの文書で説明される。３ＧＰＰ及び３ＧＰＰ２の文書は公に入手可能である。ＷＬＡＮは、ＩＥＥＥ８０２．１１ｘネットワークであることができ、及びＷＰＡＮは、Ｂｌｕｅｔｏｏｔｈ（登録商標）ネットワーク、ＩＥＥＥ８０２．１５ｘ、又は何らかのその他タイプのネットワークであることができる。それらの技法は、ＷＷＡＮ、ＷＬＡＮ及び／又はＷＰＡＮのあらゆる組み合わせと関係させて実装することもできる。
【０７９３】
衛星測位システム（ＳＰＳ）は、典型的には、エンティティが送信機から受信された信号に少なくとも部分的に基づいて地球上又は地球上方における自己の位置を決定するのを可能にするために配置された送信機のシステムを含む。該送信機は、典型的には、設定された数のチップの繰り返し擬似ランダム雑音（ＰＮ）コードで表示された信号を送信し、地上に基づく制御局、ユーザ装置及び／又は又は宇宙ビークル上に配置することができる。特定の例では、該送信機は、地球軌道周回衛星ビークル（ＳＶ）上に配置することができる。例えば、全地球航法衛星システム(ＧＮＳＳ)、例えば、全地球測位システム（ＧＰＳ）、ガリレオ、グロナス又はコンパス、から成る一群内のＳＶは、（例えば、ＧＰＳにおけるように各衛星に関して異なるＰＮコードを用いて又はグロナスにおけるように異なる周波数で同じコードを用いて）一群内のその他のＳＶによって送信されたＰＮコードと区別することができるＰＮコードで表示された信号を送信することができる。幾つかの態様により、ここにおいて提示される技法は、ＳＰＳのためのグローバルシステム（例えば、ＧＮＳＳ）に制限されない。例えば、ここにおいて提供される技法は、様々な地域システム、例えば、日本上空の準天頂衛星システム（ＱＺＳＳ）、インド上空のインド地域航法衛星システム（ＩＲＮＳＳ）、中国上空の北斗、等、及び／又は、１つ以上の全地球的な及び／又は地域の航法衛星システムと関連付けることができる又は１つ以上の全地球的な及び／又は地域の航法衛星システムとともに使用するために使用可能にすることができる様々な補強システム（例えば、（静止衛星型衛星航法補強システム（ＳＢＡＳ））、に適用することができ又は様々な地域システム、例えば、日本上空の準天頂衛星システム（ＱＺＳＳ）、インド上空のインド地域航法衛星システム（ＩＲＮＳＳ）、中国上空の北斗、等、及び／又は、１つ以上の全地球的な及び／又は地域の航法衛星システムと関連付けることができる又は１つ以上の全地球的な及び／又は地域の航法衛星システムとともに使用するために使用可能にすることができる様々な補強システム（例えば、（静止衛星型衛星航法補強システム（ＳＢＡＳ））において使用するために使用可能にすることができる。一例として、ただし制限することなしに、ＳＢＡＳは、完全性情報、時間差補正、等を提供する補強システム、例えば、ワイドエリア補強システム（ＷＡＡＳ）、欧州静止衛星航法オーバーレイサービス（ＥＧＮＯＳ）、運輸多目的衛星用衛星航法補強システム（ＭＳＡＳ）、ＧＰＳ補助地球補強航法システム又はＧＰＳ及び地球補強航法システム（ＧＡＧＡＮ）、等を含むことができる。従って、ここにおいて使用される場合において、ＳＰＳは、１つ以上の全地球的な及び／又は地域的な航法衛星システム及び／又は補強システムのあらゆる組み合わせを含むことができ、及び、ＳＰＳ信号は、ＳＰＳ、ＳＰＳ類似、及び／又は該１つ以上のＳＰＳと関連付けられたその他の信号を含むことができる。
【０７９４】
方法は、擬似衛星又は衛星と擬似衛星の組み合わせを利用する位置決定システムとともに使用することができる。擬似衛星は、Ｌハンド（又はその他の手段は）搬送波信号で変調された（ＧＰＳ又はＣＤＭＡセルラー信号に類似する）ＰＮコード又はその他の測距コードをブロードキャストする地上をベースにした送信機であり、ＧＳＰ時間と同期化することができる。各々の該送信機には、遠隔受信機による識別を可能にするために一意のＰＮコードを割り当てることができる。擬似衛星は、軌道周回衛星からの信号を入手不能な状況、例えば、トンネル、鉱山、建物、アーバンキャニオン又はその他の包囲されたエリア内、において有用である。擬似衛星のその他の実装は、ラジオビーコンと呼ばれる。ここにおいて用いられる場合の用語“衛星”は、擬似衛星と、擬似衛星の同等物と、その他と、を含むことが意図される。ここにおいて用いられる場合の用語“ＳＰＳ信号”は、擬似衛星又は擬似衛星の同等物からのＳＰＳ類似信号を含むことが意図される。
【０７９５】
移動局（例えば、ＭＳ又はＳＴＡ）は、無線通信及び／又はナビゲーション信号を受信することが可能なデバイス、例えば、セルラー又はその他の無線通信デバイス、パーソナル通信システム（ＰＣＳ）デバイス、パーソナルナビゲーションデバイス（ＰＮＤ）、パーソナル情報マネージャ（ＰＩＭ）、パーソナルデジタルアシスタント（ＰＤＡ）、ラップトップ、タブレット、ネットブック、スマートブック又はその他の適切なモバイルデバイス、を意味する。用語“移動局”は、例えば、短距離無線接続、赤外線接続、有線接続、又はその他の接続によってパーソナルナビゲーションデバイス（ＰＮＤ）と通信するデバイスを含むことも意図されており、衛星信号の受信、援助データの受信、及び／又は位置関連の処理がそのデバイス又はＰＮＤで生じるかどうかを問わない。さらに、“移動局”は、例えば、インターネット、Ｗｉ−Ｆｉ、又はその他のネットワークを介して、サーバとの通信が可能である全デバイス、例えば、無線通信デバイス、コンピュータ、ラップトップ、等を含むことが意図され、、衛星信号の受信、援助データの受信、及び／又は位置関連の処理がそのデバイスにおいて、サーバにおいて、又はネットワークと関連付けられた他のデバイスにおいて生じるかどうかを問わない。上記のいずれの動作可能な組み合わせも、“移動局”とみなされる。用語“移動局”及び“モバイルデバイス”は、互換可能な形でしばしば使用される。
【０７９６】
本開示は、実施形態例を含む。しかしながら、その他の実装を使用可能である。何かが“最適化される”、“要求される”とする指定又はその他の指定は、本開示が最適化されているシステム、又は“要求される”要素が存在するシステムのみに適用されるということ（又はその他の指定に起因するその他の制限）を示すものではない。これらの指定は、特定の説明される実施形態のみに言及する。当然のことであるが、数多くの実装が可能である。技法は、ここにおいて説明されるプロトコル以外のそれらとともに使用することができ、現在開発中の又は開発予定のプロトコルを含む。
【０７９７】
開示される実施形態に関する前の説明は、当業者が開示される実施形態を製造又は使用することを可能にするために提供される。これらの実施形態に対する様々な変更は、当業者にとって容易に明確になるであろう、及びここにおいて定められる一般原理は、本開示の適用範囲を逸脱せずにその他の実施形態に対しても適用することができる。以上のように、本開示は、ここにおいて示される実施形態に限定されることは意図されず、次の請求項によって定義される原理及び新規の特徴に一致する限りにおいて最も広範な適用範囲が認められるべきである。
以下に、出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
モバイルデバイスにおいて、前記モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納することであって、前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含むことと、
前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがセキュアユーザプレーンロケーション（ＳＵＰＬ）ユーザと関連付けられているとして認証するためにＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に前記少なくとも１つのセキュリティクレデンシャルを送信することと、を備える、認証の方法。
［Ｃ２］
前記少なくとも１つのセキュリティクレデンシャルは、公開鍵を含むＣ１に記載の方法。
［Ｃ３］
前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスの国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び一連番号のうちの少なくとも１つを含むＣ１に記載の方法。
［Ｃ４］
前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス証明書を含むＣ１に記載の方法。
［Ｃ５］
前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのユニバーサル集積スマートカード（ＵＩＣＣ）、前記モバイルデバイスのメモリのセキュアな部分、又はそれらの組み合わせにおいて格納されるＣ１に記載の方法。
［Ｃ６］
前記モバイルデバイスは、ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）を含むＣ１に記載の方法。
［Ｃ７］
前記モバイルデバイスは、米国電気電子学会（ＩＥＥＥ）８０２．１１規格に準拠して動作するネットワークを介して前記ＳＬＰに前記少なくとも１つのセキュリティクレデンシャルを送信するＣ１に記載の方法。
［Ｃ８］
モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納するメモリであって、前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含むメモリと、
前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがセキュアユーザプレーンロケーション（ＳＵＰＬ）ユーザと関連付けられているとして認証するためにＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に前記少なくとも１つのセキュリティクレデンシャルを送信することを前記モバイルデバイスに行わせるように構成されたプロセッサと、を備える、装置。
［Ｃ９］
前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス証明書、前記モバイルデバイスの公開鍵、国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び一連番号のうちの少なくとも１つを含むＣ８に記載の装置。
［Ｃ１０］
モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納するための手段であって、前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含む手段と、
前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがセキュアユーザプレーンロケーション（ＳＵＰＬ）ユーザと関連付けられているとして認証するためにＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に前記少なくとも１つのセキュリティクレデンシャルを送信することを前記モバイルデバイスに行わせるための手段と、を備える、装置。
［Ｃ１１］
前記モバイルデバイスは、ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）を含むＣ１０に記載の装置。
［Ｃ１２］
プロセッサによって実行されたときに、
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスに送信されるべきメッセージを生成し、
前記モバイルデバイスのデバイス証明書を含む応答を前記モバイルデバイスから受信し、及び
前記デバイス証明書に基づいて前記モバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証することを前記プロセッサに行わせる命令を備え、前記メッセージは、
前記ＳＵＰＬサーバの識別子と前記ＳＵＰＬサーバの公開鍵とを含むサーバ証明書と、
前記モバイルデバイスのデバイス証明書の要求と、を含む、非一時的なプロセッサによって読み取り可能な媒体。
［Ｃ１３］
前記モバイルデバイスは、ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）を備え、前記ＳＵＰＬサーバは、ＳＵＰＬロケーションプラットフォーム（ＳＬＰ）を備えるＣ１２に記載の非一時的なプロセッサによって読み取り可能な媒体。
［Ｃ１４］
前記メッセージは、前記モバイルデバイスによってサポートされる１つ以上のトランスポート層セキュリティ（ＴＬＳ）暗号スイートの表示を前記モバイルデバイスから受信したことに応答して送信され、前記メッセージは、前記１つ以上のＴＬＳ暗号スイートのうちの少なくとも１つの選択をさらに含むＣ１２に記載の非一時的なプロセッサによって読み取り可能な媒体。
［Ｃ１５］
前記デバイス証明書は、前記モバイルデバイスのデバイス識別子を含むＣ１２に記載の非一時的なプロセッサによって読み取り可能な媒体。
［Ｃ１６］
プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスに送信されるべきメッセージを生成し、
前記モバイルデバイスのデバイス識別子を含む応答を前記モバイルデバイスから受信し、及び
前記デバイス証明書に基づいて前記モバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証するために前記プロセッサによって実行可能であり、前記メッセージは、
前記ＳＵＰＬサーバの識別子と前記ＳＵＰＬサーバの公開鍵とを含むサーバ証明書と、
前記モバイルデバイスのデバイス証明書の要求と、を含む、装置。
［Ｃ１７］
前記メッセージは、前記モバイルデバイスによってサポートされる１つ以上のトランスポート層セキュリティ（ＴＬＳ）暗号スイートの表示を前記モバイルデバイスから前記ＳＵＰＬサーバにおいて受信したことに応答して送信され、前記メッセージは、前記１つ以上のＴＬＳ暗号スイートのうちの少なくとも１つの選択をさらに含むＣ１６に記載の装置。
［Ｃ１８］
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスによってサポートされる１つ以上のトランスポート層セキュリティ（ＴＬＳ）暗号スイートの表示を前記モバイルデバイスから受信することと、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされるＴＬＳ事前共有鍵（ＴＬＳ−ＰＳＫ）暗号スイートを含むかどうかを決定することと、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされる前記ＴＬＳ−ＰＳＫ暗号スイートを含むと決定したことに応答して、前記モバイルデバイスを認証するために汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく認証プロセスを実施することと、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされるＴＬＳ−ＰＳＫ暗号スイートを含まないと決定したことに応答して、前記ＳＵＰＬサーバが証明書に基づく認証方法をサポートするかどうかを決定することと、
前記ＳＵＰＬサーバが前記証明書に基づく認証方法をサポートすると決定したことに応答して、前記モバイルデバイスにサーバ証明書を送信することと前記モバイルデバイスからデバイス証明書を受信することとを含む前記証明書に基づく認証方法を実施することと、を備える、方法。
［Ｃ１９］
前記ＳＵＰＬサーバが前記証明書に基づく認証方法をサポートしないと決定したことに応答して、前記モバイルデバイスが３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ（３ＧＰＰ）ネットワーク又は３ＧＰＰ２ネットワークに接続されるときに代替クライアント認証（ＡＣＡ）に基づく認証方法を実施することをさらに備えるＣ１８に記載の方法。
［Ｃ２０］
前記証明書に基づく認証方法は、前記モバイルデバイスによって使用されるアクセスネットワークから独立しているＣ１８に記載の方法。
［Ｃ２１］
プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスによってサポートされる１つ以上のトランスポート層セキュリティ（ＴＬＳ）暗号スイートの表示を前記モバイルデバイスから受信し、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされるＴＬＳ事前共有鍵（ＴＬＳ−ＰＳＫ）暗号スイートを含むかどうかを決定し、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされる前記ＴＬＳ−ＰＳＫ暗号スイートを含むと決定したことに応答して、前記モバイルデバイスを認証するために汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく認証プロセスを実施し、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされるＴＬＳ−ＰＳＫ暗号スイートを含まないと決定したことに応答して、前記ＳＵＰＬサーバが証明書に基づく認証方法をサポートするかどうかを決定し、
前記ＳＵＰＬサーバが前記証明書に基づく認証方法をサポートすると決定したことに応答して、前記モバイルデバイスにサーバ証明書を送信することと前記モバイルデバイスからデバイス証明書を受信することとを含む証明書に基づく認証プロセスを実施するために前記プロセッサによって実行可能である、装置。
［Ｃ２２］
前記命令は、前記ＳＵＰＬサーバが前記証明書に基づく認証方法をサポートしないと決定したことに応答して、前記モバイルデバイスが３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ（３ＧＰＰ）ネットワーク又は３ＧＰＰ２ネットワークに接続されるときに代替クライアント認証（ＡＣＡ）に基づく認証方法を実施するために前記プロセッサによってさらに実行可能であるＣ２１に記載の装置。
［Ｃ２３］
前記証明書に基づく認証プロセスは、前記モバイルデバイスによって使用されるアクセスネットワークから独立しているＣ２１に記載の装置。
［Ｃ２４］
モバイルデバイスにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバと前記モバイルデバイスとの間でＳＵＰＬセッションを開始するために前記ＳＵＰＬサーバからセッション開始メッセージを受信することと、
前記モバイルデバイスが前記セッションメッセージを受信する前に前記モバイルデバイスが前記ＳＵＰＬサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、
前記有効なセッション開始メッセージ鍵を用いてセッション開始メッセージを認証することと、
前記セッション開始メッセージの成功裏の認証に応答して前記ＳＵＰＬサーバとの前記ＳＵＰＬセッションを開始することと、を備える、方法。
［Ｃ２５］
前記セッション開始メッセージは、ＳＵＰＬ  ＩＮＩＴメッセージを含むＣ２４に記載の方法。
［Ｃ２６］
前記有効なセッション開始メッセージ鍵は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを含むＣ２４に記載の方法。
［Ｃ２７］
前記モバイルデバイスが前記有効なセッション開始メッセージ鍵を受信しないことに応答して、
前記ＳＵＰＬサーバにメッセージを送信することと、
前記メッセージに応答して前記ＳＵＰＬサーバからセッション開始メッセージを受信することと、をさらに備えるＣ２４に記載の方法。
［Ｃ２８］
前記メッセージは、ＳＵＰＬ_ＩＮＩＴ_ＫｅｙＲｅｑｕｅｓｔパラメータを含むＣ２７に記載の方法。
［Ｃ２９］
前記メッセージは、ＳＥＴ  Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含まれているＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータを含むＣ２７に記載の方法。
［Ｃ３０］
プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
モバイルデバイスにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバと前記モバイルデバイスとの間でＳＵＰＬセッションを開始するために前記ＳＵＰＬサーバからセッション開始メッセージを受信し、
前記モバイルデバイスが前記セッションメッセージを受信する前に前記モバイルデバイスが前記ＳＵＰＬサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、
前記有効なセッション開始メッセージ鍵を用いて前記セッション開始メッセージを認証し、及び
前記セッション開始メッセージの成功裏の認証に応答して前記ＳＵＰＬサーバとの前記ＳＵＰＬセッションを開始するために前記プロセッサによって実行可能である、装置。
［Ｃ３１］
前記セッション開始メッセージは、ＳＵＰＬ  ＩＮＩＴメッセージを含むＣ３０に記載の装置。
［Ｃ３２］
前記有効なセッション開始メッセージ鍵は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを含むＣ３０に記載の装置。
［Ｃ３３］
モバイルデバイスからセキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにメッセージを送信することであって、前記メッセージは、ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータを含むことを備える、方法。
［Ｃ３４］
前記ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータは、前記モバイルデバイスが無効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ又は同期外れのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを含むことを示すＣ３３に記載の方法。
［Ｃ３５］
前記ＳＵＰＬ  ＩＮＩＴ  Ｒｏｏｔ  Ｋｅｙ  Ｓｔａｔｕｓパラメータは、前記メッセージのＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含められるＣ３３に記載の方法。
［Ｃ３６］
前記メッセージは、ユーザロケーションプロトコル（ＵＬＰ）メッセージを備えるＣ３３に記載の方法。
［Ｃ３７］
セキュアプレーンロケーション（ＳＵＰＬ）サーバからモバイルデバイスに、ＳＵＰＬ
ＩＮＩＴ  Ｋｅｙ  Ｒｓｅｐｏｎｓｅパラメータを含むＳＵＰＬ  ＥＮＤメッセージを送信することを備える、方法。
［Ｃ３８］
前記ＳＵＰＬ  ＩＮＩＴ  Ｋｅｙ  Ｒｓｅｐｏｎｓｅパラメータは、モードＡ鍵識別子、一時的モードＡ鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ、及びモードＡ鍵寿命のうちの少なくとも１つを含むＣ３７に記載の方法。
［Ｃ３９］
モバイルデバイスにおいて、セキュアプレーンロケーション（ＳＵＰＬ）サーバと前記モバイルデバイスとの間でＳＵＰＬセッションを継続するために前記ＳＵＰＬサーバからセッション再開メッセージを受信することと、
前記モバイルデバイスが前記セッション再開メッセージを受信する前に前記モバイルデバイスが前記ＳＵＰＬサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、
前記有効なセッション開始メッセージ鍵を用いて前記セッション再開メッセージを認証することと、
前記セッション再開メッセージの成功裏の認証に応答して前記ＳＵＰＬサーバとの前記ＳＵＰＬセッションを継続することと、を備える、方法。
［Ｃ４０］
前記セッション再開メッセージは、ＳＵＰＬ  ＲＥＩＮＩＴメッセージを含むＣ３９に記載の方法。
［Ｃ４１］
前記モバイルデバイスが前記有効なセッション開始メッセージ鍵を受信しないことに応答して、
前記ＳＵＰＬサーバにメッセージを送信することと、
前記メッセージに応答して前記ＳＵＰＬサーバからセッション開始メッセージ鍵を受信することと、をさらに備えるＣ３９に記載の方法。
［Ｃ４２］
プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
モバイルデバイスにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバと前記モバイルデバイスとの間でＳＵＰＬセッションを継続するために前記ＳＵＰＬサーバからセッション再開メッセージを受信し、
前記モバイルデバイスが前記セッション再開メッセージを受信する前に前記モバイルデバイスが前記ＳＵＰＬサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、
前記有効なセッション開始メッセージ鍵を用いて前記セッション再開メッセージを認証し、及び
前記セッション再開メッセージの成功裏の認証に応答して前記ＳＵＰＬサーバとの前記ＳＵＰＬセッションを継続するために前記プロセッサによって実行可能である、装置。
［Ｃ４３］
前記セッション再開メッセージは、ＳＵＰＬ  ＲＥＩＮＩＴメッセージを含むＣ４２に記載の装置。
［Ｃ４４］
前記有効なセッション開始メッセージ鍵は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを含むＣ４２に記載の装置。
［Ｃ４５］
ウェブサーバにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスからメッセージを受信することであって、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含むことと、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信することと、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証することと、
前記モバイルデバイスが前記ＳＵＰＬサービスの前記権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするために前記ＳＵＰＬサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信することと、を備える、方法。
［Ｃ４６］
前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含むＣ４５に記載の方法。
［Ｃ４７］
前記モバイルデバイスから前記メッセージを受信する前に前記モバイルデバイスに前記ウェブサーバの公開鍵を含むサーバ証明書を送信することと、
前記ウェブサーバの公開鍵を用いて前記メッセージを復号することと、をさらに備えるＣ４５に記載の方法。
［Ｃ４８］
前記セキュリティクレデンシャルは、前記モバイルデバイスの国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び一連番号のうちの少なくとも１つのを含むＣ４５に記載の方法。
［Ｃ４９］
前記ユーザ識別情報は、識別子と、パスワードと、を含むＣ４５に記載の方法。
［Ｃ５０］
プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
ウェブサーバにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスからメッセージを受信し、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信し、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証し、及び
前記モバイルデバイスが前記ＳＵＰＬサービスの前記権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするために前記ＳＵＰＬサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信するために前記プロセッサによって実行可能であり、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含む、装置。
［Ｃ５１］
前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含むＣ５０に記載の装置。
［Ｃ５２］
ウェブサーバにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスからメッセージを受信するための手段であって、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含む手段と、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信するための手段と、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証するための手段と、
前記モバイルデバイスが前記ＳＵＰＬサービスの前記権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするために前記ＳＵＰＬサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信するための手段と、を備える、装置。
［Ｃ５３］
前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含むＣ５２に記載の装置。
［Ｃ５４］
プロセッサによって実行されたときに、
ウェブサーバにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスからメッセージを受信し、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信し、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証し、及び
前記モバイルデバイスが前記ＳＵＰＬサービスの前記権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするために前記ＳＵＰＬサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信することを前記プロセッサに行わせる命令を備え、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含む、非一時的なプロセッサによって読み取り可能な媒体。
［Ｃ５５］
前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含むＣ５４に記載の非一時的なプロセッサによって読み取り可能な媒体。
［Ｃ５６］
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスから第１の識別子及び第１のパスワードを受信することと、
前記第１の識別子及び前記第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証することと、
前記第１の識別子及び前記第１のパスワードに取って代わるための第２の識別子及び第２のパスワードを前記モバイルデバイスに送信することであって、前記ＳＵＰＬサーバは、前記モバイルデバイスから前記第２の識別子及び前記第２のパスワードを受信した時点で前記モバイルデバイスとのＳＵＰＬセッションを確立するように構成されることと、を備える、方法。
［Ｃ５７］
前記第１のパスワードは、ユーザによって選択され、前記第２の識別子及び前記第２のパスワードは、前記ＳＵＰＬサーバにおいて生成されるＣ５６に記載の方法。
［Ｃ５８］
前記ＳＵＰＬサーバにおいて、第２のモバイルデバイスから前記第１の識別子及び第１のパスワードを受信することと、
前記第１の識別子及び前記第１のパスワードが前記ＳＵＰＬサービスの前記権限が付与されたユーザと関連付けられているとして認証することと、
前記第２のモバイルデバイスが前記ＳＵＰＬサービスにアクセスするのを許容することが、前記ＳＵＰＬサービスにアクセスすることが許可される前記権限が付与されたユーザと関連付けられたモバイルデバイスのスレショルド数を超えることになるかどうかを決定することと、をさらに備えるＣ５６に記載の方法。
［Ｃ５９］
前記第２のモバイルデバイスが前記ＳＵＰＬサービスにアクセスするのを許容することが、前記ＳＵＰＬサービスにアクセスすることが許可される前記権限が付与されたユーザと関連付けられたモバイルデバイスのスレショルド数を超えないと決定したことに応答して、前記第１の識別子及び前記第１のパスワードに取って代わるための第３の識別子及び第３のパスワードを前記第２のモバイルデバイスに送信することをさらに備えるＣ５８に記載の方法。
［Ｃ６０］
前記第３の識別子は、前記第２の識別子と別個であり、前記ＳＵＰＬサーバは、前記第２の識別子を用いる前記モバイルデバイスによって及び前記第３の識別子を用いる前記第２のモバイルデバイスによって前記ＳＵＰＬサービスの使用法をモニタリングするように構成されるＣ５９に記載の方法。
［Ｃ６１］
プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスから第１の識別子及び第１のパスワードを受信し、
前記第１の識別子及び前記第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証し、及び
前記第１の識別子及び前記第１のパスワードに取って代わるための第２の識別子及び第２のパスワードを前記モバイルデバイスに送信するために前記プロセッサによって実行可能であり、前記ＳＵＰＬサーバは、前記モバイルデバイスから前記第２の識別子及び前記第２のパスワードを受信した時点で前記モバイルデバイスとのＳＵＰＬセッションを確立するように構成される、装置。
［Ｃ６２］
前記第１のパスワードは、ユーザによって選択され、前記第２の識別子及び前記第２のパスワードは、前記ＳＵＰＬサーバにおいて生成されるＣ６１に記載の装置。
［Ｃ６３］
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスから第１の識別子及び第１のパスワードを受信するための手段と、
前記第１の識別子及び前記第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証するための手段と、
前記第１の識別子及び前記第１のパスワードに取って代わるための第２の識別子及び第２のパスワードを前記モバイルデバイスに送信するための手段と、を備え、前記ＳＵＰＬサーバは、前記モバイルデバイスから前記第２の識別子及び前記第２のパスワードを受信した時点で前記モバイルデバイスとのＳＵＰＬセッションを確立するように構成される、装置。
［Ｃ６４］
前記第１のパスワードは、ユーザによって選択され、及び、前記第２の識別子及び前記第２のパスワードを生成するための手段をさらに備えるＣ６３に記載の装置。
［Ｃ６５］
プロセッサによって実行されたときに、
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスから第１の識別子及び第１のパスワードを受信し、
前記第１の識別子及び前記第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証し、及び
前記第１の識別子及び前記第１のパスワードに取って代わるための第２の識別子及び第２のパスワードを前記モバイルデバイスに送信することを前記プロセッサに行わせる命令を備え、前記ＳＵＰＬサーバは、前記モバイルデバイスから前記第２の識別子及び前記第２のパスワードを受信した時点で前記モバイルデバイスとのＳＵＰＬセッションを確立するように構成される、非一時的なプロセッサによって読み取り可能な媒体。
［Ｃ６６］
前記第１のパスワードは、ユーザによって選択され、前記第２の識別子及び前記第２のパスワードは、前記ＳＵＰＬサーバにおいて生成されるＣ６５に記載の非一時的なプロセッサによって読み取り可能な媒体。
［Ｃ６７］
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバからモバイルデバイスにＰｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータを含むＳＵＰＬ  ＩＮＩＴメッセージを送信することを備える、方法。
［Ｃ６８］
前記Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータは、
Ｎｕｌｌ保護、モードＡ保護、及びモードＢ保護のうちの１つを示すＬｅｖｅｌパラメータ、及び
鍵識別子タイプ及び鍵識別子のうちの少なくとも１つを含むＰｒｏｔｅｃｔｉｏｎパラメータのうちの少なくとも１つを含むＣ６７に記載の方法。
［Ｃ６９］
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバからモバイルデバイスにＰｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータを含むＳＵＰＬ  ＲＥＩＮＩＴメッセージを送信することを備える、方法。
［Ｃ７０］
前記Ｐｒｏｔｅｃｔｉｏｎ  Ｌｅｖｅｌパラメータは、
Ｎｕｌｌ保護、モードＡ保護、及びモードＢ保護のうちの１つを示すＬｅｖｅｌパラメータ、及び
鍵識別子タイプ及び鍵識別子のうちの少なくとも１つを含むＰｒｏｔｅｃｔｉｏｎパラメータのうちの少なくとも１つを含むＣ６９に記載の方法。
【図１】
0005876063.tif 000031
【図２】
0005876063.tif 000032
【図３】
0005876063.tif 000033
【図４】
0005876063.tif 000034
【図５】
0005876063.tif 000035
【図６】
0005876063.tif 000036
【図７】
0005876063.tif 000037
【図８】
0005876063.tif 000038
【図９】
0005876063.tif 000039
【図１０】
0005876063.tif 000040
【図１１】
0005876063.tif 000041