"モバイルデバイスにおいて、前記モバイルデバイス専用である少なくとも1つのセキュリティクレデンシャルを格納することであって、前記少なくとも1つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含むことと、前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがセキュアユーザプレーンロケーションSUPLユーザと関連付けられているとして認証するためにSUPLロケーションプラットフォームSLPに前記少なくとも1つのセキュリティクレデンシャルを送信することと、を備える、認証の方法。前記少なくとも1つのセキュリティクレデンシャルは、公開鍵を含む請求項1に記載の方法。前記少なくとも1つのセキュリティクレデンシャルは、前記モバイルデバイスの国際移動体装置識別番号IMEI、移動局識別子MSID、及び一連番号のうちの少なくとも1つを含む請求項1に記載の方法。前記少なくとも1つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス証明書を含む請求項1に記載の方法。前記少なくとも1つのセキュリティクレデンシャルは、前記モバイルデバイスのユニバーサル集積スマートカードUICC、前記モバイルデバイスのメモリのセキュアな部分、又はそれらの組み合わせにおいて格納される請求項1に記載の方法。前記モバイルデバイスは、SUPLによってイネーブルにされる端末SETを含む請求項1に記載の方法。前記モバイルデバイスは、米国電気電子学会IEEE802.11規格に準拠して動作するネットワークを介して前記SLPに前記少なくとも1つのセキュリティクレデンシャルを送信する請求項1に記載の方法。モバイルデバイス専用である少なくとも1つのセキュリティクレデンシャルを格納するメモリであって、前記少なくとも1つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含むメモリと、前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがセキュアユーザプレーンロケーションSUPLユーザと関連付けられているとして認証するためにSUPLロケーションプラットフォームSLPに前記少なくとも1つのセキュリティクレデンシャルを送信することを前記モバイルデバイスに行わせるように構成されたプロセッサと、を備える、装置。前記少なくとも1つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス証明書、前記モバイルデバイスの公開鍵、国際移動体装置識別番号IMEI、移動局識別子MSID、及び一連番号のうちの少なくとも1つを含む請求項8に記載の装置。モバイルデバイス専用である少なくとも1つのセキュリティクレデンシャルを格納するための手段であって、前記少なくとも1つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含む手段と、前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがセキュアユーザプレーンロケーションSUPLユーザと関連付けられているとして認証するためにSUPLロケーションプラットフォームSLPに前記少なくとも1つのセキュリティクレデンシャルを送信することを前記モバイルデバイスに行わせるための手段と、を備える、装置。前記モバイルデバイスは、SUPLによってイネーブルにされる端末SETを含む請求項10に記載の装置。プロセッサによって実行されたときに、セキュアユーザプレーンロケーションSUPLサーバにおいて、モバイルデバイスに送信されるべきメッセージを生成し、前記モバイルデバイスのデバイス証明書を含む応答を前記モバイルデバイスから受信し、及び前記デバイス証明書に基づいて前記モバイルデバイスがSUPLユーザと関連付けられているとして認証することを前記プロセッサに行わせる命令を備え、前記メッセージは、前記SUPLサーバの識別子と前記SUPLサーバの公開鍵とを含むサーバ証明書と、前記モバイルデバイスのデバイス証明書の要求と、を含む、非一時的なプロセッサによって読み取り可能な媒体。前記モバイルデバイスは、SUPLによってイネーブルにされる端末SETを備え、前記SUPLサーバは、SUPLロケーションプラットフォームSLPを備える請求項12に記載の非一時的なプロセッサによって読み取り可能な媒体。前記メッセージは、前記モバイルデバイスによってサポートされる1つ以上のトランスポート層セキュリティTLS暗号スイートの表示を前記モバイルデバイスから受信したことに応答して送信され、前記メッセージは、前記1つ以上のTLS暗号スイートのうちの少なくとも1つの選択をさらに含む請求項12に記載の非一時的なプロセッサによって読み取り可能な媒体。前記デバイス証明書は、前記モバイルデバイスのデバイス識別子を含む請求項12に記載の非一時的なプロセッサによって読み取り可能な媒体。プロセッサと、前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、前記命令は、セキュアユーザプレーンロケーションSUPLサーバにおいて、モバイルデバイスに送信されるべきメッセージを生成し、前記モバイルデバイスのデバイス識別子を含む応答を前記モバイルデバイスから受信し、及び前記デバイス証明書に基づいて前記モバイルデバイスがSUPLユーザと関連付けられているとして認証するために前記プロセッサによって実行可能であり、前記メッセージは、前記SUPLサーバの識別子と前記SUPLサーバの公開鍵とを含むサーバ証明書と、前記モバイルデバイスのデバイス証明書の要求と、を含む、装置。前記メッセージは、前記モバイルデバイスによってサポートされる1つ以上のトランスポート層セキュリティTLS暗号スイートの表示を前記モバイルデバイスから前記SUPLサーバにおいて受信したことに応答して送信され、前記メッセージは、前記1つ以上のTLS暗号スイートのうちの少なくとも1つの選択をさらに含む請求項16に記載の装置。セキュアユーザプレーンロケーションSUPLサーバにおいて、モバイルデバイスによってサポートされる1つ以上のトランスポート層セキュリティTLS暗号スイートの表示を前記モバイルデバイスから受信することと、前記1つ以上のTLS暗号スイートが前記SUPLサーバによってサポートされるTLS事前共有鍵TLS-PSK暗号スイートを含むかどうかを決定することと、前記1つ以上のTLS暗号スイートが前記SUPLサーバによってサポートされる前記TLS-PSK暗号スイートを含むと決定したことに応答して、前記モバイルデバイスを認証するために汎用ブートストラッピングアーキテクチャGBAに基づく認証プロセスを実施することと、前記1つ以上のTLS暗号スイートが前記SUPLサーバによってサポートされるTLS-PSK暗号スイートを含まないと決定したことに応答して、前記SUPLサーバが証明書に基づく認証方法をサポートするかどうかを決定することと、前記SUPLサーバが前記証明書に基づく認証方法をサポートすると決定したことに応答して、前記モバイルデバイスにサーバ証明書を送信することと前記モバイルデバイスからデバイス証明書を受信することとを含む前記証明書に基づく認証方法を実施することと、を備える、方法。前記SUPLサーバが前記証明書に基づく認証方法をサポートしないと決定したことに応答して、前記モバイルデバイスが3rdGenerationPartnershipProject3GPPネットワーク又は3GPP2ネットワークに接続されるときに代替クライアント認証ACAに基づく認証方法を実施することをさらに備える請求項18に記載の方法。前記証明書に基づく認証方法は、前記モバイルデバイスによって使用されるアクセスネットワークから独立している請求項18に記載の方法。プロセッサと、前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、前記命令は、セキュアユーザプレーンロケーションSUPLサーバにおいて、モバイルデバイスによってサポートされる1つ以上のトランスポート層セキュリティTLS暗号スイートの表示を前記モバイルデバイスから受信し、前記1つ以上のTLS暗号スイートが前記SUPLサーバによってサポートされるTLS事前共有鍵TLS-PSK暗号スイートを含むかどうかを決定し、前記1つ以上のTLS暗号スイートが前記SUPLサーバによってサポートされる前記TLS-PSK暗号スイートを含むと決定したことに応答して、前記モバイルデバイスを認証するために汎用ブートストラッピングアーキテクチャGBAに基づく認証プロセスを実施し、前記1つ以上のTLS暗号スイートが前記SUPLサーバによってサポートされるTLS-PSK暗号スイートを含まないと決定したことに応答して、前記SUPLサーバが証明書に基づく認証方法をサポートするかどうかを決定し、前記SUPLサーバが前記証明書に基づく認証方法をサポートすると決定したことに応答して、前記モバイルデバイスにサーバ証明書を送信することと前記モバイルデバイスからデバイス証明書を受信することとを含む証明書に基づく認証プロセスを実施するために前記プロセッサによって実行可能である、装置。前記命令は、前記SUPLサーバが前記証明書に基づく認証方法をサポートしないと決定したことに応答して、前記モバイルデバイスが3rdGenerationPartnershipProject3GPPネットワーク又は3GPP2ネットワークに接続されるときに代替クライアント認証ACAに基づく認証方法を実施するために前記プロセッサによってさらに実行可能である請求項21に記載の装置。前記証明書に基づく認証プロセスは、前記モバイルデバイスによって使用されるアクセスネットワークから独立している請求項21に記載の装置。モバイルデバイスにおいて、セキュアユーザプレーンロケーションSUPLサーバと前記モバイルデバイスとの間でSUPLセッションを開始するために前記SUPLサーバからセッション開始メッセージを受信することと、前記モバイルデバイスが前記セッションメッセージを受信する前に前記モバイルデバイスが前記SUPLサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、前記有効なセッション開始メッセージ鍵を用いてセッション開始メッセージを認証することと、前記セッション開始メッセージの成功裏の認証に応答して前記SUPLサーバとの前記SUPLセッションを開始することと、を備える、方法。前記セッション開始メッセージは、SUPLINITメッセージを含む請求項24に記載の方法。前記有効なセッション開始メッセージ鍵は、SUPLINITROOTKEYを含む請求項24に記載の方法。前記モバイルデバイスが前記有効なセッション開始メッセージ鍵を受信しないことに応答して、前記SUPLサーバにメッセージを送信することと、前記メッセージに応答して前記SUPLサーバからセッション開始メッセージを受信することと、をさらに備える請求項24に記載の方法。前記メッセージは、SUPLINITKeyRequestパラメータを含む請求項27に記載の方法。前記メッセージは、SETCapabilitiesパラメータ内に含まれているSUPLINITRootKeyStatusパラメータを含む請求項27に記載の方法。プロセッサと、前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、前記命令は、モバイルデバイスにおいて、セキュアユーザプレーンロケーションSUPLサーバと前記モバイルデバイスとの間でSUPLセッションを開始するために前記SUPLサーバからセッション開始メッセージを受信し、前記モバイルデバイスが前記セッションメッセージを受信する前に前記モバイルデバイスが前記SUPLサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、前記有効なセッション開始メッセージ鍵を用いて前記セッション開始メッセージを認証し、及び前記セッション開始メッセージの成功裏の認証に応答して前記SUPLサーバとの前記SUPLセッションを開始するために前記プロセッサによって実行可能である、装置。前記セッション開始メッセージは、SUPLINITメッセージを含む請求項30に記載の装置。前記有効なセッション開始メッセージ鍵は、SUPLINITROOTKEYを含む請求項30に記載の装置。モバイルデバイスからセキュアユーザプレーンロケーションSUPLサーバにメッセージを送信することであって、前記メッセージは、SUPLINITRootKeyStatusパラメータを含むことを備える、方法。前記SUPLINITRootKeyStatusパラメータは、前記モバイルデバイスが無効なSUPLINITROOTKEY又は同期外れのSUPLINITROOTKEYを含むことを示す請求項33に記載の方法。前記SUPLINITRootKeyStatusパラメータは、前記メッセージのSUPLによってイネーブルにされる端末SETCapabilitiesパラメータ内に含められる請求項33に記載の方法。前記メッセージは、ユーザロケーションプロトコルULPメッセージを備える請求項33に記載の方法。セキュアプレーンロケーションSUPLサーバからモバイルデバイスに、SUPLINITKeyRseponseパラメータを含むSUPLENDメッセージを送信することを備える、方法。前記SUPLINITKeyRseponseパラメータは、モードA鍵識別子、一時的モードA鍵識別子、SUPLINITROOTKEY、及びモードA鍵寿命のうちの少なくとも1つを含む請求項37に記載の方法。モバイルデバイスにおいて、セキュアプレーンロケーションSUPLサーバと前記モバイルデバイスとの間でSUPLセッションを継続するために前記SUPLサーバからセッション再開メッセージを受信することと、前記モバイルデバイスが前記セッション再開メッセージを受信する前に前記モバイルデバイスが前記SUPLサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、前記有効なセッション開始メッセージ鍵を用いて前記セッション再開メッセージを認証することと、前記セッション再開メッセージの成功裏の認証に応答して前記SUPLサーバとの前記SUPLセッションを継続することと、を備える、方法。前記セッション再開メッセージは、SUPLREINITメッセージを含む請求項39に記載の方法。前記モバイルデバイスが前記有効なセッション開始メッセージ鍵を受信しないことに応答して、前記SUPLサーバにメッセージを送信することと、前記メッセージに応答して前記SUPLサーバからセッション開始メッセージ鍵を受信することと、をさらに備える請求項39に記載の方法。プロセッサと、前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、前記命令は、モバイルデバイスにおいて、セキュアユーザプレーンロケーションSUPLサーバと前記モバイルデバイスとの間でSUPLセッションを継続するために前記SUPLサーバからセッション再開メッセージを受信し、前記モバイルデバイスが前記セッション再開メッセージを受信する前に前記モバイルデバイスが前記SUPLサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、前記有効なセッション開始メッセージ鍵を用いて前記セッション再開メッセージを認証し、及び前記セッション再開メッセージの成功裏の認証に応答して前記SUPLサーバとの前記SUPLセッションを継続するために前記プロセッサによって実行可能である、装置。前記セッション再開メッセージは、SUPLREINITメッセージを含む請求項42に記載の装置。前記有効なセッション開始メッセージ鍵は、SUPLINITROOTKEYを含む請求項42に記載の装置。ウェブサーバにおいて、セキュアユーザプレーンロケーションSUPLによってイネーブルにされるモバイルデバイスからメッセージを受信することであって、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含むことと、前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信することと、前記ユーザ識別情報がSUPLサービスの権限が付与されたユーザを識別しているとして認証することと、前記モバイルデバイスが前記SUPLサービスの前記権限が付与されたユーザと関連付けられているとしてSUPLサーバが認証するのを可能にするために前記SUPLサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信することと、を備える、方法。前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含む請求項45に記載の方法。前記モバイルデバイスから前記メッセージを受信する前に前記モバイルデバイスに前記ウェブサーバの公開鍵を含むサーバ証明書を送信することと、前記ウェブサーバの公開鍵を用いて前記メッセージを復号することと、をさらに備える請求項45に記載の方法。前記セキュリティクレデンシャルは、前記モバイルデバイスの国際移動体装置識別番号IMEI、移動局識別子MSID、及び一連番号のうちの少なくとも1つのを含む請求項45に記載の方法。前記ユーザ識別情報は、識別子と、パスワードと、を含む請求項45に記載の方法。プロセッサと、前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、前記命令は、ウェブサーバにおいて、セキュアユーザプレーンロケーションSUPLによってイネーブルにされるモバイルデバイスからメッセージを受信し、前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信し、前記ユーザ識別情報がSUPLサービスの権限が付与されたユーザを識別しているとして認証し、及び前記モバイルデバイスが前記SUPLサービスの前記権限が付与されたユーザと関連付けられているとしてSUPLサーバが認証するのを可能にするために前記SUPLサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信するために前記プロセッサによって実行可能であり、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含む、装置。前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含む請求項50に記載の装置。ウェブサーバにおいて、セキュアユーザプレーンロケーションSUPLによってイネーブルにされるモバイルデバイスからメッセージを受信するための手段であって、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含む手段と、前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信するための手段と、前記ユーザ識別情報がSUPLサービスの権限が付与されたユーザを識別しているとして認証するための手段と、前記モバイルデバイスが前記SUPLサービスの前記権限が付与されたユーザと関連付けられているとしてSUPLサーバが認証するのを可能にするために前記SUPLサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信するための手段と、を備える、装置。前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含む請求項52に記載の装置。プロセッサによって実行されたときに、ウェブサーバにおいて、セキュアユーザプレーンロケーションSUPLによってイネーブルにされるモバイルデバイスからメッセージを受信し、前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信し、前記ユーザ識別情報がSUPLサービスの権限が付与されたユーザを識別しているとして認証し、及び前記モバイルデバイスが前記SUPLサービスの前記権限が付与されたユーザと関連付けられているとしてSUPLサーバが認証するのを可能にするために前記SUPLサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信することを前記プロセッサに行わせる命令を備え、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含む、非一時的なプロセッサによって読み取り可能な媒体。前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含む請求項54に記載の非一時的なプロセッサによって読み取り可能な媒体。セキュアユーザプレーンロケーションSUPLサーバにおいて、モバイルデバイスから第1の識別子及び第1のパスワードを受信することと、前記第1の識別子及び前記第1のパスワードがSUPLサービスの権限が付与されたユーザと関連付けられているとして認証することと、前記第1の識別子及び前記第1のパスワードに取って代わるための第2の識別子及び第2のパスワードを前記モバイルデバイスに送信することであって、前記SUPLサーバは、前記モバイルデバイスから前記第2の識別子及び前記第2のパスワードを受信した時点で前記モバイルデバイスとのSUPLセッションを確立するように構成されることと、を備える、方法。前記第1のパスワードは、ユーザによって選択され、前記第2の識別子及び前記第2のパスワードは、前記SUPLサーバにおいて生成される請求項56に記載の方法。前記SUPLサーバにおいて、第2のモバイルデバイスから前記第1の識別子及び第1のパスワードを受信することと、前記第1の識別子及び前記第1のパスワードが前記SUPLサービスの前記権限が付与されたユーザと関連付けられているとして認証することと、前記第2のモバイルデバイスが前記SUPLサービスにアクセスするのを許容することが、前記SUPLサービスにアクセスすることが許可される前記権限が付与されたユーザと関連付けられたモバイルデバイスのスレショルド数を超えることになるかどうかを決定することと、をさらに備える請求項56に記載の方法。前記第2のモバイルデバイスが前記SUPLサービスにアクセスするのを許容することが、前記SUPLサービスにアクセスすることが許可される前記権限が付与されたユーザと関連付けられたモバイルデバイスのスレショルド数を超えないと決定したことに応答して、前記第1の識別子及び前記第1のパスワードに取って代わるための第3の識別子及び第3のパスワードを前記第2のモバイルデバイスに送信することをさらに備える請求項58に記載の方法。前記第3の識別子は、前記第2の識別子と別個であり、前記SUPLサーバは、前記第2の識別子を用いる前記モバイルデバイスによって及び前記第3の識別子を用いる前記第2のモバイルデバイスによって前記SUPLサービスの使用法をモニタリングするように構成される請求項59に記載の方法。プロセッサと、前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、前記命令は、セキュアユーザプレーンロケーションSUPLサーバにおいて、モバイルデバイスから第1の識別子及び第1のパスワードを受信し、前記第1の識別子及び前記第1のパスワードがSUPLサービスの権限が付与されたユーザと関連付けられているとして認証し、及び前記第1の識別子及び前記第1のパスワードに取って代わるための第2の識別子及び第2のパスワードを前記モバイルデバイスに送信するために前記プロセッサによって実行可能であり、前記SUPLサーバは、前記モバイルデバイスから前記第2の識別子及び前記第2のパスワードを受信した時点で前記モバイルデバイスとのSUPLセッションを確立するように構成される、装置。前記第1のパスワードは、ユーザによって選択され、前記第2の識別子及び前記第2のパスワードは、前記SUPLサーバにおいて生成される請求項61に記載の装置。セキュアユーザプレーンロケーションSUPLサーバにおいて、モバイルデバイスから第1の識別子及び第1のパスワードを受信するための手段と、前記第1の識別子及び前記第1のパスワードがSUPLサービスの権限が付与されたユーザと関連付けられているとして認証するための手段と、前記第1の識別子及び前記第1のパスワードに取って代わるための第2の識別子及び第2のパスワードを前記モバイルデバイスに送信するための手段と、を備え、前記SUPLサーバは、前記モバイルデバイスから前記第2の識別子及び前記第2のパスワードを受信した時点で前記モバイルデバイスとのSUPLセッションを確立するように構成される、装置。前記第1のパスワードは、ユーザによって選択され、及び、前記第2の識別子及び前記第2のパスワードを生成するための手段をさらに備える請求項63に記載の装置。プロセッサによって実行されたときに、セキュアユーザプレーンロケーションSUPLサーバにおいて、モバイルデバイスから第1の識別子及び第1のパスワードを受信し、前記第1の識別子及び前記第1のパスワードがSUPLサービスの権限が付与されたユーザと関連付けられているとして認証し、及び前記第1の識別子及び前記第1のパスワードに取って代わるための第2の識別子及び第2のパスワードを前記モバイルデバイスに送信することを前記プロセッサに行わせる命令を備え、前記SUPLサーバは、前記モバイルデバイスから前記第2の識別子及び前記第2のパスワードを受信した時点で前記モバイルデバイスとのSUPLセッションを確立するように構成される、非一時的なプロセッサによって読み取り可能な媒体。前記第1のパスワードは、ユーザによって選択され、前記第2の識別子及び前記第2のパスワードは、前記SUPLサーバにおいて生成される請求項65に記載の非一時的なプロセッサによって読み取り可能な媒体。セキュアユーザプレーンロケーションSUPLサーバからモバイルデバイスにProtectionLevelパラメータを含むSUPLINITメッセージを送信することを備える、方法。前記ProtectionLevelパラメータは、Null保護、モードA保護、及びモードB保護のうちの1つを示すLevelパラメータ、及び鍵識別子タイプ及び鍵識別子のうちの少なくとも1つを含むProtectionパラメータのうちの少なくとも1つを含む請求項67に記載の方法。セキュアユーザプレーンロケーションSUPLサーバからモバイルデバイスにProtectionLevelパラメータを含むSUPLREINITメッセージを送信することを備える、方法。前記ProtectionLevelパラメータは、Null保護、モードA保護、及びモードB保護のうちの1つを示すLevelパラメータ、及び鍵識別子タイプ及び鍵識別子のうちの少なくとも1つを含むProtectionパラメータのうちの少なくとも1つを含む請求項69に記載の方法。図1を参照し、セキュアユーザプレーンロケーションSUPL環境において認証を行うために動作可能であるシステムの特定の実施形態が示され、概して100で表される。システム100は、1つ以上のアクセスネットワーク例えば、例示のためのアクセスネットワーク130を介してモバイルデバイス120に通信可能な形で結合されたSUPLサーバ110を含む。特定の実施形態では、SUPLサーバ110は、SUPLロケーションプラットフォームSLPであることができ及びモバイルデバイス120はSUPLによってイネーブルにされる端末SETであることができる。アクセスネットワーク130は、3GPPネットワーク、3GPP2ネットワーク、WiMAXネットワーク、Wi-Fiネットワーク例えば、IEEE802.11規格に準拠して動作するネットワーク、又は何らかのその他の無線アクセスネットワークであることができる。特定の実施形態では、モバイルデバイス120は、無線電話であることができる。SUPLサーバ110は、プロセッサ111と、プロセッサ111に結合されたメモリ112と、を含む。特定の実施形態では、メモリ122は、プロセッサ111によって実行可能な命令を格納することができ、命令は、様々な論理的モジュール、コンポーネント、及びアプリケーションを表す。メモリ112は、SUPLサーバ110の1つ以上のセキュリティクレデンシャルを格納することもできる。例えば、メモリ112は、SUPLサーバ110のためのサーバ証明書113を格納することができ、サーバ証明書113は、公開鍵114と、サーバ識別子ID115例えば、SUPLサーバ110に対応するグローバルで一意の識別子と、を含む。SUPLサーバ110は、公開鍵114に対応する秘密鍵を有することもできる。メモリ112は、認証論理116及びトランスポート層セキュリティTLS暗号化/復号論理117に対応する実行可能な命令を格納することもできる。認証論理116は、モバイルデバイス120を認証するために実行可能であることができる。TLS暗号化/復号論理117は、SUPLサーバ110からモバイルデバイス120に送信されるメッセージを暗号化するために及びモバイルデバイス120からSUPLサーバ110に送信されたメッセージを復号するために実行可能であることができる。例えば、モバイルデバイス120からの発信メッセージは、サーバ公開鍵114を用いて暗号化することができ、モバイルデバイス120からの着信メッセージは、サーバ公開鍵114に対応する秘密鍵を用いて復号することができる。モバイルデバイス120は、プロセッサ121と、プロセッサ121に結合されたメモリ122と、を含む。特定の実施形態では、メモリ122は、プロセッサ121によって実行可能な命令を格納し、命令は、様々な論理的モジュール、コンポーネント、及びアプリケーションを表すことができる。メモリ122は、モバイルデバイス120の1つ以上のセキュリティクレデンシャルを格納することもできる。例えば、メモリ122は、モバイルデバイス120のためのデバイス証明書123を格納することができ、デバイス証明書123は、公開鍵124と、デバイス識別子ID125と、を含む。モバイルデバイス120は、公開鍵124に対応する秘密鍵を有することもできる。デバイスID125は、国際移動体装置識別番号IMEI、移動局識別子MSID、一連番号、又はグローバルで一意であることができるその他の識別子であることができる。特定の実施形態では、デバイス証明書123は、メモリ122の代わりに又はメモリ122に加えて、モバイルデバイス120のユニバーサル集積回路カードUICCに格納することができる。メモリ122は、認証論理126及びトランスポート層セキュリティTLS暗号化/復号論理127に対応する実行可能な命令を格納することができる。認証論理126は、モバイルデバイス120でSUPLサーバ110を認証するために実行可能であることができる。TLS暗号化/復号論理127は、モバイルデバイス120からSUPLサーバ110に送信されたメッセージを暗号化するために及びSUPLサーバ110からモバイルデバイス120に送信されたメッセージを復号するために実行可能であることができる。例えば、モバイルデバイス120からの発信メッセージは、デバイス公開鍵124を用いて暗号化することができ、モバイルデバイス120への着信メッセージは、デバイス公開鍵124に対応する秘密鍵を用いて復号することができる。特定の実施形態では、SUPLサーバ110及びモバイルデバイス120は、相互認証手順に従事することができる。例えば、動作中に、モバイルデバイス120における認証論理126は、モバイルデバイス120が汎用ブーストラッピングアーキテクチャGBAに基づく認証をサポートするかどうかを決定することができる。モバイルデバイス120がGBAに基づく認証をサポートする場合は、モバイルデバイス120及びSUPLサーバ110は、GBAに基づく認証プロセス134を実施することができる。GBAに基づく認証は、アクセスネットワーク130が3GPP又は3GPP2ネットワークであるときに選択することができる。モバイルデバイス120は、SUPLサーバ110にメッセージ131を送信することによってTLSハンドシェイク手順を開始することができる。メッセージ131は、モバイルデバイス120においてTLS暗号化/復号論理127によってサポートされる1つ以上のTLS暗号スイートを示すことができる。例えば、メッセージ131は、ClientHelloメッセージであることができ、サポートされるTLS暗号スイートは、ClientHello.ciphersuitesフィールドによって示すことができる。SUPLサーバ110は、メッセージ131を処理し、示されているTLS暗号スイートのうちのいずれがSUPLサーバ110によって同じくサポートされているかどうかすなわち、共通にサポートされるTLS暗号スイートが存在するかどうかを決定することができる。モバイルデバイス120及びSUPLサーバ110の両方がTLSの事前共有鍵TLS-PSK暗号スイートをサポートする場合は、GBAをサポートすることができ、及びSUPLサーバ110は、GBAに基づく認証プロセス134を実施することができる。そうでない場合は、SUPLサーバ110は、メッセージ132を介して証明書に基づく認証を開始することができ又は代替クライアント認証ACAを開始することができる。ACAは、相互認証を提供することができ、及び使用されるアクセスネットワークのタイプ例えば、GSM登録商標/UMTS及びCDMAに依存することができる。ACA認証中には、SUPLサーバ110は、モバイルデバイス120によって提供されたIPアドレスをアクセスネットワーク130によって提供されるモバイルデバイス120に対応するIPアドレスと比較することによってモバイルデバイス120のインターネットプロトコルIPアドレスバインディングbindingを検証することができる。証明書に基づく認証は、アクセスネットワーク130のタイプから独立していることができ及びアクセスネットワーク130がWi-Fiネットワークであるときに使用することができる。メッセージ132は、SUPLサーバ110及びモバイルデバイス120によってサポートされる非PSKTLS暗号スイートの表示indicationと、サーバ公開鍵114を含むサーバ証明書113と、デバイス証明書要求と、を含むことができる。例示するために、メッセージ132は、共通してサポートされるTLS暗号スイートを示すServerHello.ciphersuiteフィールドを含むServerHelloメッセージを含むことができる。メッセージ132に応答して、モバイルデバイス120は、デバイス証明書123を含むメッセージ133を送信することができる。SUPLサーバ110は、デバイス証明書123内のデバイスID125を格納されたデバイスID例えば、図8及び9を参照してさらに説明されるように、SUPLユーザと関連付けられていることがSUPLサーバ110によって予めセキュアに検証されている格納されたデバイスIDと比較することによってモバイルデバイス120と関連付けられたSUPLユーザを識別するのを試みることができる。いずれのSUPLユーザも識別されない場合は、SUPLサーバ110とモバイルデバイス120との間での通信セッションを終了させることができる。SUPLユーザが識別される場合は、TLSハンドシェイクは完了することができ、SUPLサーバ110は、SUPLユーザのためにプロビジョニングprovisioningされるSUPLに基づくサービス例えば、位置に基づくサービスへのアクセスをモバイルデバイス120に認めることができる。特定の実施形態では、異なる認証方法も利用可能であることができる。例えば、モバイルデバイス120がWiMAXと互換可能なデバイスであり及び/又はアクセスネットワーク130がWiMAXネットワークであるときに、モバイルデバイス120及びSUPLサーバ110が両方ともSUPL暗号化鍵SEKに基づく認証方法をサポートする場合は、SEKに基づく認証方法が、SUPLサーバ110及びモバイルデバイス120の相互認証にとってより好ましいことができる。他の例として、SUPLサーバ110が証明書に基づく認証をサポートしない場合は、SUPLサーバ110は、異なる認証方法、例えば、ACAモバイルデバイス120が3GPP又は3GPP2アクセスネットワーク上にあるときにアクセスネットワークに依存する相互認証を提供することができる又はSLP専用認証非相互認証を提供することができ及び緊急シナリオ中のみに概して使用することができる、を開始するためにデバイス証明書を要求せずにメッセージ132を送信することができる。このように、図1のシステム100は、アクセスネットワークに依存しないでモバイルデバイスとSUPLサーバとの間での相互認証を可能にすることができる。例えば、アクセスネットワーク130は、3GPPネットワーク、3GPP2ネットワーク、WiMAXネットワーク、Wi-Fiネットワーク、又は何らかのその他のネットワークであることができる。図1のシステム100は、複数の相互認証方法のためのサポートを提供することもでき、GBAに基づく認証と、SEKに基づく認証と、証明書に基づく認証と、ACAに基づく認証と、SLP専用認証と、を含む。図2を参照し、SUPL環境において認証方法を交渉する方法の特定の実施形態が示され、概して200で表される。例示のための実施形態では、方法200は、図1のSUPLサーバ110によって実施することができる。方法200は、202において、SUPLサーバにおいて、モバイルデバイスによってサポートされる1つ以上のTLS暗号スイートの表示をモバイルデバイスから受信することを含むことができる。例えば、図1において、SUPLサーバ110は、モバイルデバイス120からメッセージ131を受信することができ、メッセージ131は、モバイルデバイス120によってサポートされる1つ以上のTLS暗号スイートを示す。方法200は、204において、モバイルデバイスによって示される少なくとも1つのTLS-PSK暗号スイートがSUPLサーバによってもサポートされるかどうかを決定することを含むこともできる。例えば、図1において、SUPLサーバ110は、モバイルデバイス120によってサポートされるTLS-PSK暗号スイートがSUPLサーバ110によってもサポートされるかどうかを決定することができる。204において、TLS-PSK暗号スイートがSUPLサーバ及びモバイルデバイスによって共通してサポートされると決定したことに応答して、206において、モバイルデバイスを認証するためにGBAに基づく認証プロセスを実施することができる。例えば、図1において、SUPLサーバ110は、GBAに基づく認証手順134を実施することができる。204において、TPS-PSK暗号スイートがSUPLサーバ及びモバイルデバイスによって共通してサポートされていないと決定したことに応答して、208において、証明書に基づく認証プロセスを実施することができる。証明書に基づくプロセスは、モバイルデバイスにサーバ証明書を送信することと、モバイルデバイスからデバイス証明書を受信することと、を含むことができ、及び、モバイルデバイスによって使用されるアクセスネットワークから独立していることができる。例えば、図1において、SUPLサーバ110は、メッセージ132を介してモバイルデバイス120にサーバ証明書113を送信することとメッセージ133を介してモバイルデバイス120からデバイス証明書123を受信することとを含む証明書に基づく認証手順を実施することができる。特定の実施形態では、図2の方法200は、フィールドプログラマブルゲートアレイFPGAデバイス、特定用途向け集積回路ASIC、処理ユニット、例えば、中央処理装置CPU、デジタル信号プロセッサDSP、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図2の方法200は、命令を実行するプロセッサによって実施することができる。図3を参照し、証明書を用いてSUPL環境において認証を行う方法の特定の実施形態が示され、概して300で表される。例示のための実施形態では、方法300は、図1のモバイルデバイス120によって実施することができる。方法300は、302において、モバイルデバイスにおいて、モバイルデバイス専用である少なくとも1つのセキュリティクレデンシャルを格納することを含むことができる。少なくとも1つのセキュリティクレデンシャルは、モバイルデバイスのデバイス識別子を含むことができる。例えば、図1において、モバイルデバイス120は、デバイスID125例えば、IMEI、MSID、一連番号、又は他のグローバルで一意の識別子を含むデバイス証明書123を格納することができる。方法300は、304において、デバイス識別子と格納されたデバイス識別子の比較に基づいてモバイルデバイスがSUPLユーザと関連付けられているとして認証するために少なくとも1つのセキュリティクレデンシャルをSUPLロケーションプラットフォームSLPに送信することを含むこともできる。例えば、図1において、モバイルデバイス120は、デバイスID125と他のエンティティによって予め提供された格納されたデバイスIDの比較に基づいてモバイルデバイス120がSUPLユーザと関連付けられているとしてSUPLサーバ110が認証できるようにメッセージ133を介してSUPLサーバ110例えば、SLPにデバイス証明書123を送信することができる。特定の実施形態では、図3の方法300は、フィールドプログラマブルゲートアレイFPGAデバイス、特定用途向け集積回路ASIC、処理ユニット、例えば、中央処理装置CPU、デジタル信号プロセッサDSP、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図3の方法300は、命令を実行するプロセッサによって実施することができる。図4を参照し、証明書を用いてSUPL環境において認証を行う方法の他の特定の実施形態が示され、概して400で表される。例示のための実施形態では、方法400は、図1のSUPLサーバ110によって実施することができる。方法400は、402において、SUPLサーバにおいて、モバイルデバイスによってサポートされる1つ以上のTLS暗号スイートの表示をモバイルデバイスから受信することを含むことができる。例えば、図1において、SUPLサーバ110は、モバイルデバイス120からメッセージ131を受信することができ、メッセージ131は、モバイルデバイス120によってサポートされる1つ以上のTLS暗号スイートを示す。方法400は、404において、SUPLサーバからモバイルデバイスにメッセージを送信することを含むこともできる。メッセージは、SUPLサーバの識別子とSUPLサーバの公開鍵とを含むサーバ証明書と、モバイルデバイスのデバイス証明書の要求と、TLS暗号スイートのうちの少なくとも1つの選択と、を含むことができる。例えば、図1において、SUPLサーバ110は、モバイルデバイス120にメッセージ132を送信することができ、メッセージ132は、サーバID115と、サーバ公開鍵114と、モバイルデバイス120のデバイス証明書123の要求と、共通してサポートされるTLS暗号スイートの選択と、を含む。方法400は、406において、モバイルデバイスのデバイス証明書を含む応答をモバイルデバイスから受信することをさらに含むことができる。例えば、図1において、SUPLサーバ110は、デバイス証明書123を含むメッセージ133を受信することができる。方法400は、408において、デバイス証明書に基づいてモバイルデバイスがSUPLユーザと関連付けられているとして認証することを含むことができる。例えば、図1において、SUPLサーバ110の認証論理116は、デバイス証明書123に基づいてモバイルデバイス120がSUPLユーザと関連付けられているとして認証することができる。特定の実施形態では、図4の方法400は、フィールドプログラマブルゲートアレイFPGAデバイス、特定用途向け集積回路ASIC、処理ユニット、例えば、中央処理装置CPU、デジタル信号プロセッサDSP、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図4の方法400は、命令を実行するプロセッサによって実施することができる。図1乃至4を参照して説明されるいずれの認証方法が使用されるかにかかわらず、いったん認証が完了した時点で、SUPLサーバ例えば、SLP及びモバイルデバイス例えば、SETは、SUPLセッション中にSUPLに基づくサービスに関して通信することができる。図5を参照し、SUPLサーバ510とモバイルデバイス520との間でやり取りすることができるメッセージの特定の実施形態が示され、概して500で示される。特定の実施形態では、SUPLサーバ510及びモバイルデバイス520は、SUPLセッションのコンテキストでユーザロケーションプロトコルULPメッセージを介して通信することができる。例えば、SUPLサーバ510は、モバイルデバイス520にSUPLINITメッセージ530を送信するように構成することができる。SUPLINITメッセージ530は、SUPLセッションを開始するためにSUPLサーバ110によって送信されるセッション開始メッセージを表すことができる。なりすまし及びリプレイ攻撃から保護するために、SUPLINITメッセージ530に対して保護を適用することができる。特定の実施形態では、SUPLINITメッセージ530は、ProtectionLevelパラメータを含むことができる。ProtectionLevelパラメータは、LevelパラメータNull、ModeA、又はModeBSUPLINIT保護のいずれが実装されるかを示す及びProtectionパラメータ例えば、鍵識別子タイプ及び鍵識別子のうちの少なくとも1つを含むのうちの少なくとも1つを含むことができる。特定の実施形態では、NullSUPLINIT保護は、エンドツーエンドの完全性もリプレイ保護も提供することができず、ModeASUPLINIT保護は、セキュリティが確保されたULPセッション中にSUPLサーバ510によってモバイルデバイス520に送信される共有鍵の使用によってエンドツーエンドの完全性及びリプレイ保護を提供することができ、ModeBSUPLINIT保護は、PSKに基づく方法例えば、GBA又はSEK方法から導き出された共有鍵を用いてエンドツーエンドの完全性及びリプレイ保護を提供することができる。特定の実施形態では、SUPLINIT保護は、セッション開始鍵例えば、SUPLINITROOTKEYに基づいて実装することができる。SUPLINITメッセージ530を受信した時点で、モバイルデバイス520は、モバイルデバイス520がSUPLサーバ510から有効なSUPLINITROOTKEYを以前に受信しているかどうかを決定することができ、そうである場合は、以前に受信されたSUPLINITROOTKEYは依然として有効であるかどうかを決定することができる。モバイルデバイス520が有効なSUPLINITROOTKEYを有する場合は、モバイルデバイス520は、SUPLINITROOTKEYを用いてSUPLINITメッセージ530を認証することができ及びSUPLINITメッセージ530の成功裏の認証に応答してSUPLサーバ510とSUPLセッションを開始することができる。特定の実施形態では、モバイルデバイス520が有効なSUPLINITROOTKEYを有さない場合は、モバイルデバイス520は、SUPLサーバ510にメッセージを送信することができ及びそのメッセージに応答して有効なSUPLINITROOTKEYを受信することができる。例えば、モバイルデバイス520は、有効なSUPLINITROOTKEYの要求を表すSUPLINITKeyRequestパラメータを含むメッセージを送信することができる。代替として、モバイルデバイス520は、新しいSUPLINITROOTKEYを要求する代わりに無効な又は同期外れのSUPLINITROOTKEYの存在を示すことができる。例えば、モバイルデバイス520は、モバイルデバイス520によって所有される現在のSUPLINITROOTKEYが無効又は同期外れであるかどうかを示すSUPLINITRootKeyStatusパラメータ541を含むULPメッセージ540を送信することができる。特定の実施形態では、SUPLINITRootKeyStatusパラメータ541は、ULPメッセージ540のSETCapabilitiesパラメータ内に含めることができる。SUPLINITRootKeyStatusパラメータ541をSETCapabilitiesパラメータ内に含めることは、SUPLINITRootKey状態情報を送信するための専用メッセージを導入する必要なしにSETCapabilitiesパラメータを任意選択的に又は強制的に含むSUPL2.0内で定義されたメッセージでのSUPLINITROOTKEY状態情報の送信を可能にすることができることが理解されるであろう。特定の実施形態では、SUPLINITRootKeyStatusパラメータ541は、ModeASUPLINIT保護のためにSETCapabilitiesパラメータ内に含めることができるが、NULL保護又はModeBSUPLINIT保護のためにSETCapabilitiesパラメータ内に含めることはできない。モバイルデバイス520は、すべてのネットワークによって開始されるSUPLセッションのために有効なSUPLINITROOTKEYを示すことはできないことが注目されるべきである。モバイルデバイス520には、SUPLINITROOTKEYを1回提供しておくことができ、提供された鍵は、その鍵が期限切れになる前は複数のネットワークによって開始されるSUPLセッションに関して有効であることができる。SUPLサーバ510は、SUPLINITKeyResponseパラメータを含むULPメッセージを送信することができる。例えば、SUPLサーバ510は、SUPLINITKeyResponseパラメータ551を含むSUPLENDメッセージ550を送信することができる。SUPLINITKeyResponseは、SUPLINITRootKeyStatus表示に直接応答して送信することはできず、SUPLINITKeyResponseは、同じSUPLセッション内にあることができない正規のSUPLENDメッセージ内に存在することができることが注目されるべきである例えば、SUPLセッションがSLPからSETへのSUPLENDメッセージによって終了されない場合。SUPLINITKeyResponseパラメータ551は、モードA鍵識別子、一時的モードA鍵識別子、SUPLINITROOTKEY例えば、新しいSUPLINITROOTKEY、及びモードA鍵寿命のうちの少なくとも1つを含むことができる。一般的SUPLセッションGSSがアクティブである間は、SLPすなわち、SUPLサーバ510は、SETすなわち、モバイルデバイス520との通信を開始することができる。SUPLサーバ510は、セッション再開メッセージ例えば、SUPLREINITメッセージ560を送信することができる。SUPLREINIT保護は、SUPLREINIT保護を参照してここにおいて説明されるように実装することができる。例えば、モバイルデバイス520が有効なSUPLINITROOTKEYを所有していない場合はSUPLINITROOTKEYは、セッション開始鍵及びセッション再開鍵の両方として機能することができる、モバイルデバイス520は、SUPLINITRootKeyStatusパラメータ541を介して有効なSUPLINITROOTKEYが存在しないことを示すことができ、応答して、SUPLENDメッセージ550SUPLINITKeyResponseパラメータ551を含むを受信することができる。モバイルデバイス520が有効なSUPLINITROOTKEYを有するときには、モバイルデバイス520は、SUPLREINITメッセージ560を認証することができ及びSUPLREINITメッセージ560の成功裏の認証に応答してSUPLサーバ510とのSUPLセッションを再開することができる。特定の実施形態では、SUPLREINITメッセージ560は、SUPLINITメッセージ530を参照してここにおいて説明されるように、ProtectionLevelパラメータを含むこともできる。特定の実施形態では、モバイルデバイス520は、モバイルデバイス520が有効なSUPLINITROOTKEYを有さないとき例えば、パワーアップ時又は所有されるSUPLINITROOTKEYの寿命が経過しているときにはNullSUPLINIT保護及びNullSUPLREINIT保護を適用することができる。Null保護が設定されているときには、モバイルデバイス520は、すべてのSUPLINITメッセージ及びSUPLREINITメッセージを処理することができる。モバイルデバイス520が有効なSUPLINITROOTKEYを有する場合は、ModeA又はModeB保護を適用することができる。図5において例示されるように、SUPLシステムにおいてセキュリティを実装するために様々なメッセージ及びメッセージパラメータを用いることができる。例えば、SUPLINIT及びSUPLREINIT保護のレベルを示すためにProtectionLevelパラメータを用いることができる。他の例として、現在のSUPLINITROOTKEYが無効又は同期外れであるかどうかを示すためにSUPLINITRootKeyStatusパラメータを使用することができる。さらに他の例として、新しいSUPLINITROOTKEYを提供するためにSUPLINITKeyResponseパラメータを用いることができる。図6を参照し、SUPL環境におけるセッション開始中の認証の方法の特定の実施形態が示され、概して600で表される。例示のための実施形態において、方法600は、図5のモバイルデバイス520によって実施することができる。方法600は、602において、セキュアユーザプレーンロケーションSUPLサーバとモバイルデバイスとの間でのSUPLセッションを開始するためにSUPLサーバからのセッション開始メッセージをモバイルデバイスにおいて受信することを含むことができる。例えば、図5では、モバイルデバイス520は、SUPLサーバ510からSUPLINITメッセージ530を受信することができる。方法600は、604において、モバイルデバイスがセッション開始メッセージを受信する前に有効なセッション開始メッセージ鍵を受信したかどうかを決定することを含むこともできる。例えば、図5では、モバイルデバイス520は、それが有効なSUPLINITROOTKEYを所有するかどうかを決定することができる。モバイルデバイスが有効なセッション開始メッセージ鍵を有するときには、方法600は、606において、セッション開始メッセージ鍵例えば、SUPLINITROOTKEYを用いてセッション開始メッセージを認証することと、608において、セッション開始メッセージの成功裏の認証に応答してSUPLサーバとのSUPLセッションを開始することと、をさらに含むことができる。例えば、図5において、モバイルデバイス520は、有効なSUPLINITROOTKEYを用いてSUPLINITメッセージ530を認証することができ及びSUPLサーバ510とのSUPLセッションを開始することができる。モバイルデバイスが有効なセッション開始メッセージ鍵を有さないときには、方法600は、610において、SUPLサーバにメッセージを送信することと、612において、そのメッセージに応答してSUPLサーバからセッション開始メッセージ鍵を受信することと、を含むことができる。例示することを目的として、SLP及びSETは、NULLSUPLINIT保護を用いてセッションを行うことができ、SETは、それのSUPLINITROOTKEYが無効であることの表示をセッション中に送信することができる。例えば、図5において、モバイルデバイス520は、SUPLINITRootKeyStatusパラメータ541を含むメッセージをSUPLサーバ510に送信することができ及び応答してSUPLINITKeyResponseパラメータ551を含むメッセージを受信することができる。特定の実施形態では、図6の方法600は、フィールドプログラマブルゲートアレイFPGAデバイス、特定用途向け集積回路ASIC、処理ユニット、例えば、中央処理装置CPU、デジタル信号プロセッサDSP、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図6の方法600は、命令を実行するプロセッサによって実施することができる。図7を参照し、SUPL環境におけるセッション再開中の認証の方法の特定の実施形態が示され、概して700で表される。例示のための実施形態では、方法700は、図5のモバイルデバイス520によって実施することができる。方法700は、702において、モバイルデバイスにおいて、セキュアユーザプレーンロケーションSUPLサーバとモバイルデバイスとの間でのSUPLセッションを継続するためのSUPLサーバからのセッション再開メッセージを受信することを含むことができる。例えば、図5において、モバイルデバイス520は、SUPLサーバ510からSUPLREINITメッセージ560を受信することができる。SUPLREINITメッセージ560は、SUPLサーバ510とモバイルデバイス520との間での既存の一般的なSUPLセッションGSSを継続することのネットワークによって開始された試行を表すことができる。方法700は、704において、モバイルデバイスがセッション再開メッセージを受信する前に有効なセッション開始メッセージ鍵を受信したかどうかを決定することも含むこともできる。例えば、図5において、モバイルデバイス520は、それが有効なSUPLINITROOTKEYを所有するかどうかを決定することができる。モバイルデバイスが有効なセッション開始メッセージ鍵を有する場合は、方法700は、706において、セッション開始メッセージ鍵を用いてセッション再開メッセージを認証することと、708において、セッション再開メッセージの成功裏の認証に応答してSUPLサーバとのSUPLセッションを継続することと、をさらに含むことができる。例えば、図5において、モバイルデバイス520は、有効なSUPLINITROOTKEYを用いてSUPLREINITメッセージ560を認証することができ及びSUPLサーバ510とのSUPLセッションを再開することができる。モバイルデバイスが有効なセッション開始メッセージ鍵を有さないときには、方法700は、710において、SUPLサーバにメッセージを送信することと、712において、そのメッセージに応答してSUPLサーバからセッション開始メッセージ鍵を受信することと、を含むことができる。例示することを目的として、SLP及びSETは、NULLSUPLINIT保護を用いてセッションを行うことができ、SETは、それのSUPLINITROOTKEYが無効であることの表示をセッション中に送信することができる。例えば、図5において、モバイルデバイス520は、SUPLINITRootKeyStatusパラメータ541を含むメッセージをSUPLサーバ510に送信することができ及び応答してSUPLINITKeyResponseパラメータ551を含むメッセージを受信することができる。特定の実施形態では、図7の方法700は、フィールドプログラマブルゲートアレイFPGAデバイス、特定用途向け集積回路ASIC、処理ユニット、例えば、中央処理装置CPU、デジタル信号プロセッサDSP、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図7の方法700は、命令を実行するプロセッサによって実施することができる。特定の実施形態では、証明書に基づく方法、GBAに基づく方法、SEKに基づく方法、ACAに基づく方法、及びSLP専用の方法以外の方法を介してモバイルデバイスとSUPLサーバとの間での相互認証を実施することができる。例えば、図8は、複数の識別子/パスワードを用いてSUPL環境において認証を実施するために動作可能なシステム800の特定の実施形態を例示する。システム800は、SUPLサーバ例えば、SLP820と通信することが可能なモバイルデバイス810例えば、SETを含む。複数の識別子/パスワードに基づく認証に加えて、図8のシステム800は、SUPLユーザにデバイス証明書をバインドbindさせる特定の例も示す。例えば、システム800は、デバイス証明書とSUPLユーザとの間でのバインディングを生成するためのメカニズムを提供するためのウェブサーバ830を含むことができる。ウェブサーバ830は、SUPLセッションのための認証を提供することはできず、むしろ、SUPL認証中にSLPによってのちに用いることができるバインディング情報を提供することができる。このバインディングは、典型的には1回だけ行うことができ、及び、SETがSUPLセッションに従事することができる前に行うことができる。バインディングが行われた時点で、デバイス証明書とユーザ情報の組み合わせをSLPに送信することができ、SLPは、この情報を格納してクライアント認証のために使用することができる。バインディングが行われた後は、SLPは、あるモバイルデバイスが特定のSUPLユーザに属することを知ることができる。ウェブサーバ830は、プロセッサ831と、プロセッサ831によって実行可能な命令を格納するメモリ832と、を含むことができる。例えば、命令は、認証論理833を表すことができる。ウェブサーバ830は、モバイルデバイス810と及びSUPLサーバ820と通信するために動作可能なネットワークインタフェース834を含むこともできる。ウェブサーバ830は、ユーザへのデバイス証明書のバインディングを提供する方法を示す一例であるにすぎないことが注目されるべきである。その他の実施形態では、その他のバインディングメカニズムを使用することができる。代替として、ウェブサーバ830は、デバイス証明書とユーザ情報の組み合わせを格納することができ、及び、SLPは、デバイス証明書を用いたデバイスの相互認証を行った時点でそのデバイス証明書と関連付けられたユーザ情報を提供するようにウェブサーバ830に要求することができる。モバイルデバイス810は、認証論理811例えば、モバイルデバイス810のメモリに格納され、モバイルデバイス810のプロセッサによって実行可能な命令を含むことができる。認証論理811は、モバイルデバイス810を特定のSUPLユーザと関連付けるバインドする又は登録するためにウェブサーバ830において対応する認証論理833と通信するように構成することができる。例えば、バインディングプロセスは、モバイルデバイス810がウェブサーバ830からメッセージ835を受信することから開始することができ、メッセージ835は、ウェブサーバ830のサーバ証明書と、ウェブサーバ830の公開鍵と、を含む。モバイルデバイス810は、ウェブサーバ830にメッセージ813を送信することによって応答することができ、メッセージ813は、モバイルデバイス810のセキュリティクレデンシャルを含む。例えば、モバイルデバイス810のセキュリティクレデンシャルは、モバイルデバイス810の公開鍵、国際移動体装置識別番号IMEI、移動局識別子MSID、及び/又は一連番号を含むデバイス証明書を含むことができる。モバイルデバイス810は、ウェブサーバ830にユーザ識別情報例えば、SUPLユーザと関連付けられたユーザ識別子及びパスワードを含むメッセージ814を送信することもできる。メッセージ813、814のうちの1つ又は両方は、ウェブサーバ830の公開鍵を用いて暗号化することができ、ウェブサーバ830は、ウェブサーバ830の秘密鍵を用いて暗号化されたメッセージを復号することができる。ウェブサーバ830は、モバイルデバイス810によって提供されたユーザ識別情報がSUPLサービスの権限が付与されたユーザと関連付けられているかどうかを決定するためにユーザ識別情報を認証することができる。例えば、ウェブサーバ830は、提供されたユーザ識別情報を、ウェブサーバ830に所在する又はウェブサーバ830にとってアクセス可能なSUPLユーザデータベースと比較することができる。ユーザ識別情報を検証した時点で、ウェブサーバ830は、モバイルデバイス810がSUPLサービスの権限が付与されたユーザと関連付けられているとして認証するためのメッセージ836をSUPLサーバ820に送信することによってバインディングプロセスを完了することができる。メッセージ836は、モバイルデバイス810のセキュリティクレデンシャル例えば、デバイス公開鍵、IMEI、MSID、及び/又は一連番号を含むデバイス証明書を含むことができる。モバイルデバイス810の認証論理811は、SUPLセッションの開始又は再開前にユーザモードTLSに基づく相互認証を行うためにSUPLサーバ820の対応する認証論理821と通信するように構成することもできる。例えば、モバイルデバイス810は、SUPLサーバ820にメッセージ815を送信することができ、メッセージ815は、第1の識別子と第1のパスワードとを含む。特定の実施形態では、第1のパスワードは、ユーザによって選択することができ、及び、相対的に弱い暗号強度を有することができる。例示するための実施形態では、第1の識別子及び第1のパスワードは、メッセージ814を介してモバイルデバイス810によってウェブサーバ830に送信される識別子及びパスワードに対応することができる。第1の識別子及び第1のパスワードを受信した時点で、認証論理821は、第1の識別子及び第1のパスワードがSUPLサーバの権限が付与されたユーザと関連付けられているとして認証することができる。例えば、認証論理821は、第1の識別子及び第1のパスワードがモバイルデバイス810に以前にバインディングされた権限が付与されたユーザに対応することを検証することができる。認証に成功したときには、SUPLサーバ820の識別子/パスワード生成論理822は、第1の識別子及び第1のパスワードに取って代わるための第2の識別子及び第2のパスワードを生成することができる。特定の実施形態では、第2のパスワードは、第1のパスワードよりも高い暗号強度を有することができる。SUPLサーバ820は、メッセージ824を介してモバイルデバイス810に第2の識別子及び第2のパスワードを送信することができる。モバイルデバイス810から第2の識別子及び第2のパスワードを後続して受信した時点で、SUPLサーバ820は、モバイルデバイス810とのセッションを確立することができる。特定の実施形態では、第2の識別子及び第2のパスワードは、セキュリティ上の目的でモバイルデバイス810のユーザから隠した状態にすることができる。上記の説明は、SUPLユーザが単一のモバイルデバイス例えば、SETと関連付けられていることに関するものであるが、SUPLユーザは、複数のデバイスと関連付けることができる。例えば、モバイルデバイス810と関連付けられたSUPLユーザは、第2のモバイルデバイス840へのアクセスも有することができる。第2のモバイルデバイス840に権限を付与するために、SUPLユーザは、第1のモバイルデバイス810をバインドさせるのと同様の方法で第2のモバイルデバイス840を自己のアカウント例えば、SUPLアカウントにバインドさせることができる。第2のモバイルデバイス840がSUPLユーザのアカウントにバインドされた後に相互認証を行うために、第2のモバイルデバイス840は、第1の識別子と第1のパスワードを含むメッセージ841をSUPLサーバ820に送信することができる。第1の識別子及び第1のパスワードが権限が付与されたSUPLユーザと関連付けられているとして認証した時点で、SUPLサーバ820は、第2のモバイルデバイス840にもSUPLサービスへのアクセスが許可されるべきかどうかを決定することができる。例えば、SUPLサーバ820は、ユーザ当たりのデバイス数に関する制限を実装することができ及び第2のモバイルデバイス840がSUPLサービスにアクセスするのを許容することがSUPLサービスにアクセスすることが許可された権限が付与されたユーザと関連付けられたモバイルのスレショルド数を超えるかどうかを決定することができる。第2のモバイルデバイス840がSUPLサービスにアクセスするのを許容することがスレショルドを超えない場合は、SUPLサーバ820は、第3の識別子と暗号的に強力な第3のパスワードとを含むメッセージ825を第2のモバイルデバイス840に送信することができる。第3の識別子及び第3のパスワードが第1の識別子及び第1のパスワードに取って代わることができ、及び、SUPLセッションを開始するために第2のモバイルデバイス840によって引き続いて使用することができる。特定の実施形態では、第3の識別子及び第3のパスワードは、第1のモバイルデバイス810に送信された第2の識別子及び第2のパスワードと別個であることができる。別個の識別子/パスワードの組み合わせをSUPLユーザの各モバイルデバイスに提供することによって、SUPLサーバ820は、1つのデバイスごとのモニタリングを実装することができる。例えば、SUPLサーバ820のモニタリング論理823は、第2の識別子を用いて第1のモバイルデバイス810によるSUPLサービスの使用をモニタリングするように及び第3の識別子を用いて第2のモバイルデバイス840によるSUPLサービスの使用をモニタリングするように構成することができる。図8のシステム800は、1つ以上のモバイルデバイスを特定のSUPLユーザとバインドさせる、登録する、及び/又は関連付けることができるバインディングプロセスを提供することができる。説明されるバインディングプロセスは、図1乃至4を参照して説明される認証プロセスを選択的に補足できることが理解されるだろう。例えば、図1を参照して説明されるように、SUPLサーバ110は、モバイルデバイス120のデバイスID125をSUPLユーザによって以前にセキュアに検証された格納されたデバイスIDと比較することによってSUPLユーザがモバイルデバイスと関連付けられているとして識別することを試みることができる。例示のための実施形態では、図1のSUPLサーバ110は、SUPLサーバ820であることができ、図1のモバイルデバイス120は、モバイルデバイス810であることができ、格納されたデバイスIDは、バインディングプロセス中にメッセージ836を介してSUPLサーバ820に提供されるデバイスセキュリティクレデンシャル内に含めることができる。さらに、図8のシステム800は、図1乃至4を参照して説明される認証プロセスに選択的に取って代わることができる認証プロセスを提供することができる。例えば、特定の実施形態は、GBAに基づく相互認証、SEKに基づく相互認証、及び/又は証明書に基づく相互認証の代わりに図8の複数の識別子/パスワードの認証プロセスを用いることを含むことができる。図9を参照し、ウェブサーバを用いたSUPL環境における認証の方法の特定の実施形態が示され、概して900で表される。例示のための実施形態では、方法900は、図8のウェブサーバ830によって実施することができる。方法900は、902において、ウェブサーバからSUPLによってイネーブルにされるモバイルデバイスにサーバ証明書を送信することを含むことができる。サーバ証明書は、ウェブサーバの公開鍵を含むことができる。例えば、図8において、ウェブサーバ830は、モバイルデバイス810にメッセージ835を送信することができ、メッセージ835は、ウェブサーバ830の証明書と公開鍵とを含む。方法900は、904において、モバイルデバイスのセキュリティクレデンシャルを含むモバイルデバイスからのメッセージをウェブサーバにおいて受信することを含むこともできる。例えば、図8において、ウェブサーバ830は、モバイルデバイス810からメッセージ813を受信することができ、メッセージ813は、モバイルデバイス810のセキュリティクレデンシャル例えば、デバイス証明書及びデバイス公開鍵を含む。方法900は、906において、ウェブサーバの秘密鍵を用いてメッセージを復号することと、908において、モバイルデバイスからユーザ識別情報を受信することと、をさらに含むことができる。例えば、図8において、ウェブサーバ830は、秘密鍵を用いてメッセージ813を復号することができ及びメッセージ814を介してモバイルデバイス810からユーザ識別情報例えば、識別子及びパスワードを受信することができる。代替として、又はさらに加えて、ユーザ識別情報は、ウェブサーバの秘密鍵を用いて復号することもできる。方法900は、910において、ユーザ識別情報がSUPLサービスの権限が付与されたユーザを識別しているとして認証することと、912において、モバイルデバイスがSUPLサービスの権限が付与されたユーザと関連付けられているとしてSUPLサーバが認証するのを可能にするためにモバイルデバイスのセキュリティクレデンシャルをSUPLサーバに送信することと、を含むことができる。例えば、図8において、ウェブサーバ830は、ユーザ識別情報が権限が付与されたSUPLユーザを識別しているとして認証することができ及びメッセージ836を介してSUPLサーバ820にデバイスセキュリティクレデンシャルを送信することができる。特定の実施形態では、図9の方法900は、フィールドプログラマブルゲートアレイFPGAデバイス、特定用途向け集積回路ASIC、処理ユニット、例えば、中央処理装置CPU、デジタル信号プロセッサDSP、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図9の方法900は、命令を実行するプロセッサによって実施することができる。図10を参照し、複数の識別子/パスワードを用いたSUPL環境における認証の方法の特定の実施形態が示され、概して1000で表される。例示するための実施形態において、方法1000は、図8のSUPLサーバ820によって実施することができる。方法1000は、1002において、モバイルデバイスから第1の識別子及び第1のパスワードをSUPLサーバにおいて受信することと、1004において、第1の識別子及び第1のパスワードがSUPLサービスの権限が付与されたユーザと関連付けられているとして認証することと、を含むことができる。例えば、図8において、SUPLサーバ820は、メッセージ815を介してモバイルデバイス810から第1の識別子及び第1のパスワードを受信することができ、及び、第1の識別子及び第1のパスワードが権限が付与されたユーザ例えば、以前にモバイルデバイス810にバインドされた権限が付与されたユーザと関連付けられているとして認証することができる。方法1000は、1006において、第1の識別子及び第1のパスワードに取って代わるための第2の識別子及び第2のパスワードをモバイルデバイスに送信することも含むことができる。SUPLサーバは、モバイルデバイスから第2の識別子及び第2のパスワードを受信した時点でモバイルデバイスとSUPLセッションを確立するように構成することができる。例えば、図8において、SUPLサーバ820は、第2の識別子及び第2のパスワードを生成してメッセージ824を介してモバイルデバイス810に送信することができ、及び、第2の識別子及び第2のパスワードを引き続いて受信した時点でモバイルデバイス810とのSUPLセッションを確立することができる。方法1000は、1008において、第2のモバイルデバイスから第1の識別子及び第1のパスワードをSUPLサーバにおいて受信することと、1010において、第1の識別子及び第1のパスワードがSUPLサービスの権限が付与されたユーザと関連付けられているとして認証することと、をさらに含むことができる。例えば、図8において、SUPLサーバ820は、メッセージ841を介して第2のモバイルデバイス840から第1の識別子及び第1のパスワードを受信することができ及び第1の識別子及び第1のパスワードが権限が付与されたユーザと関連付けられているとして認証することができる。例示するために、第2のモバイルデバイス840は、図9の方法900を介して権限が付与されたユーザに以前にバインドしておくこともできる。方法1000は、1012において、第2のモバイルデバイスがSUPLサービスにアクセスするのを許容することが、SUPLサービスにアクセスすることが許可された権限が付与されたユーザと関連付けられたモバイルデバイスのスレショルド数を超えるかどうかを決定することを含むことができる。例えば、図8において、ウェブサーバ820は、第2のモバイルデバイス840がSUPLサービスにアクセスするのを許容することがそのスレショルド数を超えることになるかどうかを決定することができる。特定の実施形態では、第2のモバイルデバイス840がSUPLサービスにアクセスするのを許容することがスレショルドを超えないときに、ウェブサーバ820は、メッセージ825を介して第2のモバイルデバイスに第3の識別子及び第3のパスワードを送信することができる。ウェブサーバ820は、第1のモバイルデバイス810及び第2のモバイルデバイス840によるSUPLサービスの使用法をモニタリングすることもできる。特定の実施形態では、図10の方法1000は、フィールドプログラマブルゲートアレイFPGAデバイス、特定用途向け集積回路ASIC、処理ユニット、例えば、中央処理装置CPU、デジタル信号プロセッサDSP、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図10の方法1000は、命令を実行するプロセッサによって実施することができる。図11を参照し、無線通信デバイスの特定の例示的な実施形態のブロック図が描かれ、概して1100で表される。例えば、デバイス1100は、SUPLによってイネーブルにされる端末SET、例えば、図1のモバイルデバイス120、図5のモバイルデバイス520、図8の第1のモバイルデバイス810、又は図8の第2のモバイルデバイス840であることができる。デバイス1100は、メモリ1132に結合されたプロセッサ1110を含む。メモリ1132は、ここにおいて開示される方法及びプロセス、例えば、図3の方法300、図6の方法600、図7の方法700、又はそれらのあらゆる組み合わせ、を実施するためにプロセッサ1110によって実行可能な命令1160を含むことができる。図11は、プロセッサ1110及びディスプレイ1128に結合されるディスプレイコントローラ1126も示す。プロセッサ1110及びスピーカー1136及びマイク1138にはCODEC1134を結合させることができる。図11は、1つ以上の無線コントローラ1140をプロセッサ1110及び無線アンテナ1142、1143に結合できることも示す。特定の実施形態では、アンテナ1142は、3GPP、3GPP2、及び/又はWiMAXアンテナであることができ、アンテナ1143は、Wi-Fiアンテナであることができる。プロセッサ1110及び無線コントローラ1140にはカードインタフェース1170を結合することもできる。カードインタフェース1170は、デバイス1100のセキュリティクレデンシャルを格納するカード1172例えば、加入者アイデンティティモジュールSIMカード、ユニバーサル集積回路カードUICC、又はその他のカードを収納するように構成することができる。例えば、セキュリティクレデンシャルは、デバイス証明書、公開/秘密鍵の対、IMEI、MSID、一連番号、グローバルで一意の識別子、又はそれらのあらゆる組み合わせを含むことができる。代替として、又はさらに加えて、デバイス1100のセキュリティクレデンシャルは、メモリ1132のセキュアな例えば、ユーザによって変更不能及び/又はアクセス不能な場所に格納することができる、例えば、セキュリティクレデンシャル1161。特定の実施形態では、プロセッサ1110、ディスプレイコントローラ1126、メモリ1132、CODEC1134、無線コントローラ1140、及びカードインタフェース1170は、システム-イン-パッケージsystem-in-package又はシステム-オン-チップsystem-on-chipデバイス例えば、移動局モデムMSM1122に含められる。特定の実施形態では、入力デバイス1130、例えば、タッチ画面及び/又はキーパッド、及び電源1144がシステムーオンーチップデバイス1122に結合される。さらに、特定の実施形態では、図11において例示されるように、ディスプレイ1128、入力デバイス1130、スピーカー1136、マイク1138、無線アンテナ1142及び1143、及び電源1144は、システムーオンーチップデバイス1122の外部である。しかしながら、ディスプレイ1128、入力デバイス1130、スピーカー1136、マイク1138、無線アンテナ1142及び1143、及び電源1144の各々は、システムーオンーチップデバイス1122のコンポーネント、例えば、インタフェース又はコントローラ、に結合することができる。説明される実施形態と関連して、モバイルデバイス専用である少なくとも1つのセキュリティクレデンシャルを格納するための手段を含む装置が開示される。例えば、格納するための手段は、図2のメモリ122、図11のメモリ1132、図11のカード1172、データを格納するように構成された1つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、モバイルデバイスがSUPLユーザと関連付けられているとして認証するための少なくとも1つのセキュリティクレデンシャルをSLPに送信することをモバイルデバイスに行わせるための手段も含むことができる。例えば、行わせるための手段は、図1のプロセッサ121、図11のプロセッサ1110、図1の無線コントローラ1140、データの送信を行わせるように構成された1つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。さらに、SUPLによってイネーブルにされるモバイルデバイスからのメッセージをウェブサーバにおいて受信するための手段を含む装置が開示され、メッセージは、モバイルデバイスのセキュリティクレデンシャルを含む。例えば、メッセージを受信するための手段は、図8のネットワークインタフェース834、データを受信するように構成された1つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、モバイルデバイスからのユーザ識別情報をウェブサーバにおいて受信するための手段も含む。例えば、ユーザ識別情報を受信するための手段は、図8のネットワークインタフェース834、データを受信するように構成された1つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、ユーザ識別情報がSUPLサービスの権限が付与されたユーザを識別しているとして認証するための手段も含む。例えば、認証するための手段は、図8のプロセッサ831、ユーザ識別情報を認証するように構成された1つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、モバイルデバイスがSUPLサービスの権限が付与されたユーザと関連付けられているとしてSUPLサーバが認証するのを可能にするためにモバイルデバイスのセキュリティクレデンシャルをSUPLサーバに送信するための手段を含む。例えば、送信するための手段は、図8のネットワークインタフェース834、データを受信するように構成された1つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。さらに、モバイルデバイスからの第1の識別子及び第1のパスワードをSUPLサーバにおいて受信するための手段を含む装置が開示される。例えば、受信するための手段は、図8のSUPLサーバ820のネットワークインタフェース、データを受信するように構成された1つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、第1の識別子及び第1のパスワードがSUPLサービスの権限が付与されたユーザと関連付けられているとして認証するための手段も含む。例えば、認証するための手段は、図8の認証論理821を実行するためにプログラミングされたプロセッサ、例えば、図1のプロセッサ111、識別子及びパスワードを認証するように構成された1つ以上のデバイス、又はそれらのあらゆる組み合わせを含むことができる。装置は、第1の識別子及び第1のパスワードに取って代わるための第2の識別子及び第2のパスワードをモバイルデバイスに送信するための手段をさらに含み、SUPLサーバは、モバイルデバイスから第2の識別子及び第2のパスワードを受信した時点でモバイルデバイスとのSUPLセッションを確立するように構成される。例えば、送信するための手段は、SUPLサーバ820のネットワークインタフェース、データを送信するように構成された1つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、第2の識別子及び第2のパスワードを生成するための手段を含むことができる。例えば、生成するための手段は、図8の識別子/パスワード生成論理822を実行するためにプログラミングされたプロセッサ、例えば、図1のプロセッサ111、識別子及びパスワードを生成するように構成された1つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。特定の実施形態では、上記のシステム及び方法の全部又は一部は、以下の追加の実施形態を参照してさらに説明することができ、及び/又は以下の追加の実施形態を参照して説明されるシステム及び方法によって選択的に、個々に又は組み合わせて取り替えることができる。追加の実施形態1序論SUPL2.0におけるセキュリティは、アクセスネットワーク専用である。代替クライアント認証ACAは、ソースIPアドレスに基づいてSETを識別するためのコアネットワークへのアクセスを要求するGBAは、3GPP/3GGP2ネットワークのみに適用可能SEKは、WiMAXネットワークのみに適用可能SUPL3.0における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。GBA及びユーザ名/パスワード認証の両方をサポートする単純な枠組単一のTLSの変形を使用することができる仕様及び実装を最小限変更概念概要ULPセキュリティサーバ証明書によるTLS2つのクライアント認証モード-ユーザモード:UserID,Usersecret=ユーザ名、パスワード-GBAモード:UserID,Usersecret=B-TID,KsNAFUserID,Counter,Digestが全メッセージに加えられ、Digestは以下のように計算される。A1=SLPDomainULPMessageDigest=HMACUsersecret,A1送信元がUserID,Counter,Digestを全メッセージに加え、受信元が検証するULPがSUPLINITクレデンシャルを更新するために使用されるSUPLINIT保護[例えば、非緊急時のみ]ULPv2.0BasicSUPLINITProtectionを模倣ULPを介してSLPによって提供されたSUPLINITクレデンシャルを使用セットアップ詳細オフラインユーザモードユーザ及びSLPがユーザ名、パスワードを取り決める-SLPは、ユーザ名、パスワードをユーザに提供することができる-ユーザは、ユーザ名、パスワードをSLPに提供することができる-これは、H-SLP又はA-SLPの両方が利用可能である。SET立ち上がり時ユーザモード-ユーザがユーザ名、パスワードをSUPLクライアントに入力するGBAモード-SETがBSFとブートストラップしてB-TID,K-sを入手する-SETは、必要に応じた頻度でB-TID,Ksをリフレッシュすることができることに注目することSUPLクライアントがSLPとのULPセッションを実施して新しいSUPLINITクレデンシャルを入手するULPセッションセキュリティ提案サーバ証明書によるTLSを使用することができるサーバ認証を取り扱う新しいパラメータをULPメッセージに加えるUserID,ReqCount,ReqDigestをSETからのメッセージにUserID,ReqCount,RespDigestをSLPからのメッセージにSETを発生元とするメッセージSETがUserID,ReqCount,ReqDigestを加えるSLPが、メッセージ内容を処理する前にReqCount及びReqDigestを検証するSLPを発生元とするメッセージSLPがUserID,ReqCount,RespDigestを加えるSETが、メッセージ内容を処理する前にReqCount及びRespDigestを検証するReqCount/RespCountReqCount/RespCountは同様の挙動を有するカウンタの目的は、リプレイ検出を可能にすることであるReqCount/RespCountは、ULPセッションごとに受信元及び送信元においてリセットされるすなわち、カウンタは、セッション識別子が変更されたときにリセットされる。送信元においてReqCount/RespCountが個々のメッセージごとに増分され、ULPメッセージに加えられる受信元において受信元が、予想した値とReqCount/RespCountを比較する。リプレイを検出した場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡すReqDigest/RespDigest生成ReqDigest/RespDigest生成は同一であることができる。すべての既知値をULPMessageフィールド内に挿入するULPMessageZをULPMessageとして形成し、ReqDigest/RespDigestフィールドがすべてゼロに設定されるDigestPayload=SLPDomain:ULPMessageZを形成する次式を計算するReqDigest/RespDigest=HMAC-SHA256-32Usersecret,DigestPayloadULPMessage内の該当フィールドにReqDigest/RespDigestを加えるユーザモードUserID,Usersecret:=ユーザ名、パスワードを使用するGBAモードUserID,Usersecret:=B-TID,KsNAFを使用し、ここで、[SET]Ks及びSLPURLからKsNAFを生成する[SLP]UserIDフィールドを抽出した時点で、SLPがBSFにB-TIDを提供し、BSFは、KsNAFとともに戻る。KsNAFは、B-TIDが変化しないかぎり変化しない。SUPLINITセキュリティ提案ULPTSV2.0Section6.1.6.6において既に定義されているBasicSUPLINITProtectionを模倣するGBAによってプロビジョニングされた鍵からSLPによってプロビジョニングされた鍵への適合化された記述SLPが、クライアント又はSLPのイニシアチブでULPセッション中に鍵識別子、SUPLINITROOTKEYを更新する-鍵識別子がリセットされたときにBasicReplayCounterがリセットされる最小限の標準化努力が要求されるSUPLINITクレデンシャル管理あらゆる接続セッションの最初のULPのやり取りにおいて生じるSETを発生元とするメッセージセッションの最初のメッセージは下記のいずれかを含むべきである。-クレデンシャルが入手可能でない場合は、SUPLINITCredentialReqインジケータ、又は-SET及びSLPが同期外れであるかどうかをSLPが検出するのを可能にするためのCurrentKeyIdentifier。SLPを発生元とするメッセージCurrentKeyIdentifierが正しい場合は、確認のためのSUPLINITCredentialOKインジケータを加える。CurrentKeyIdentifierが正しくない場合、又は、SETがSUPLINITCredentialReqインジケータを送信した又はサーバがSUPLINITクレデンシャルを更新することを希望する場合は、SLPは、SUPLINITクレデンシャルをプロビジョニングするためにULPメッセージにフィールドを加える-鍵識別子、SUPLINITROOTKEYを含む呼流れ例-SI即時フィックスステップA:ターゲットSETがreqcountを1234又はSETによって決定されたその他のいずれかの連続番号に設定し、メッセージダイジェストreqdigestを計算する。ターゲットSETがSUPLSTARTuser-id,reqcount=1234,reqdigest,...メッセージをH-SLPに送信する。ステップB:H-SLPが、受信されたメッセージダイジェストreqdigestを用いてSUPLSTARTの真正性を検査し及びリプレイカウンタreqcountも検査する。H-SLPが、rescountを4321又はSETによって決定されたその他のいずれかの連続番号に設定し、メッセージダイジェストreqdigestを計算する。H-SLPがSUPLRESPONSEuser-id,rescount=4321,resdigest,...メッセージをターゲットSETに送信する。ターゲットSETにおけるSUPLSTARTとSUPLRESPONSEとの間の期間=UT1。ステップC:ターゲットSETが、受信されたメッセージダイジェストresdigestを用いてSUPLRESPONSEの真正性を検査し及びリプレイカウンタreqcountも検査する。ターゲットSETが、reqcountを1だけ増分し12341及びメッセージダイジェストreqdigestを計算する。ターゲットSETがSUPLPOSINITuser-id,reqcount=12341,reqdigest...メッセージをH-SLPに送信する。H-SLPにおけるSUPLRESPONSEとSUPLPOSINITとの間の期間=ST1。ステップD:ターゲットSET及びH-SLPがSUPLPOSのやり取りに従事する。ターゲットSETにおけるSUPLPOSINITとSUPLPOSとの間の期間=UT2。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタreqcount/rescountに基づいてリプレイ完全性を検査する。ステップE:H-SLPが、受信されたメッセージダイジェストreqdigestを用いて受信された最後のSUPLPOSメッセージの真正性を検査し及びリプレイカウンタreqcountも検査する。H-SLPがreqcountを増分し43211、メッセージダイジェストresdigestを計算する。H-SLPが、SUPLENDuser-id,rescount=43211,resdigest,...メッセージをターゲットSETに送信する。ターゲットSETは、受信されたメッセージダイジェストresdigestを用いてSUPLENDの真正性を検査し及びリプレイカウンタreqcountも検査する。ターゲットSETにおけるSUPLPOSとSUPLENDとの間の期間=UT3。呼流れ例-NI即時フィックスステップA:H-SLPがrescountを1234又はH-SLPによって決定されたその他のいずれかの連続番号に設定し及びメッセージダイジェストBasicMACを計算する。H-SLPがSUPLINITuser-id,rescount=4321,BasicMAX,...メッセージをターゲットSETに送信する。ステップB:ターゲットSETが、受信されたメッセージダイジェストBasicMACを用いてSUPLINITの真正性を検査し及びリプレイカウンタreqcountも検査する。ターゲットSETが、reqcountを1234又はSETによって決定されたその他のいずれかの連続番号に設定し及びメッセージダイジェストreqdigestを計算する。ターゲットSETが、SUPLPOSINITuser-id,reqcount=1234,req-digest,...メッセージをH-SLPに送信する。H-SLPにおけるSUPLINITとSUPLPOSINITとの間の期間=ST1。ステップC:ターゲットSET及びH-SLPがSUPLPOSのやり取りに従事する。ターゲットSETにおけるSUPLPOSINITとSUPLPOSとの間の期間=UT2。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタreqcount/rescountに基づいてリプレイ完全性を検査する。ステップD:H-SLPが、受信されたメッセージダイジェストreqdigestを用いて受信された最後のSUPLPOSメッセージの真正性を検査し及びリプレイカウンタreqcountも検査する。H-SLPがreqcountを増分し43211及びメッセージダイジェストresdigestを計算する。H-SLPが、SUPLENDuser-id,rescount=43211,resdigest,...メッセージをターゲットSETに送信する。ターゲットSETは、受信されたメッセージダイジェストresdigestを用いてSUPLENDの真正性を検査し及びリプレイカウンタreqcountも検査する。ターゲットSETにおけるSUPLPOSとSUPLENDとの間の期間=UT3。追加の実施形態2序論SUPL2.0におけるセキュリティは、アクセスネットワーク専用である。ACAは、ソースIPアドレスに基づいてSETを識別するためのコアネットワークへのアクセスを要求するGBAは、3GPP/3GGP2ネットワークのみに適用可能SEKは、WiMAXネットワークのみに適用可能SUPL3.0における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。GBA及びユーザ名/パスワード認証の両方をサポートする単純な枠組単一のTLSの変形を使用することができる仕様及び実装の最小限の変更概念概要ULPセキュリティサーバ証明書によるTLS2つのクライアント認証モード-ユーザモード:UserID,Usersecret=ユーザ名、パスワード-GBAモード:UserID,Usersecret=B-TID,KsNAFUserID,Counter,Digestが全メッセージに加えられ、Digestは以下のように計算される。A1=SLPDomainULPMessageDigest=HMACUsersecret,A1送信元がUserID,Counter,Digestを全メッセージに加え、受信元が検証するULPがSUPLINITクレデンシャル鍵アイデンティティ、SUPINITROOTKEYを更新するために使用されるSUPLINIT保護[例えば、非緊急時のみ]SLPユーザモード又はGBAGBAモードによって生成されたSUPLINITクレデンシャルを有するULPv2.0BasicSUPLINITProtectionを使用するユーザモードでULPを介してSLPによって提供されたSUPLINITクレデンシャルを使用するセットアップ詳細オフラインユーザモードユーザ及びSLPがユーザ名、パスワードを取り決める-SLPは、ユーザ名、パスワードをユーザに提供することができる-ユーザは、ユーザ名、パスワードをSLPに提供することができる-これは、H-SLP又はA-SLPの両方が利用可能である。SET立ち上がり時ユーザモード-ユーザがユーザ名、パスワードをSUPLクライアントに入力するGBAモード-SETがBSFとブートストラップしてB-TID,Ksを入手する-SETは、必要に応じた頻度でB-TID,Ksをリフレッシュすることができることに注目することSUPLクライアントが新しいSUPLINITクレデンシャルを入手するためにSLPとのULPセッションを実施するULPセッションセキュリティ提案サーバ証明書によるTPLを使用することができるサーバ認証を取り扱う新しいパラメータをULPメッセージに加えるUserID,ReqCount,ReqDigestをSETからのメッセージにUserID,ReqCount,RespDigestをSLPからのメッセージにSETを発生元とするメッセージSETがUserID,ReqCount,ReqDigestを加えるSLPが、メッセージ内容を処理する前にReqCount及びReqDigestを検証するSLPを発生元とするメッセージSLPがUserID,ReqCount,RespDigestを加えるSETが、メッセージ内容を処理する前にRespCount及びRespDigestを検証するReqCount/RespCountReqCount/RespCountは同様の挙動を有するカウンタの目的は、リプレイ検出を可能にすることであるReqCount/RespCountは、ULPセッションごとに受信元及び送信元においてリセットされるすなわち、カウンタは、セッション識別子が変更されたときにリセットされる。送信元においてReqCount/RespCountが個々のメッセージごとに増分され、ULPメッセージに加えられる受信元において受信元が、予想した値とReqCount/RespCountを比較する。リプレイを検出した場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡すReqDigest/RespDigest生成ReqDigest/RespDigest生成は同一であることができる。すべての既知値をULPMessageフィールド内に挿入するULPMessageZをULPMessageとして形成し、ReqDigest/RespDigestフィールドがすべてゼロに設定されるDigestPayload=SLPDomain:ULPMessageZを形成する次式を計算するReqDigest/RespDigest=HMAC-SHA256-32Usersecret,DigestPayloadULPMessage内の該当フィールドにReqDigest/RespDigestを加えるユーザモードUserID,Usersecret:=ユーザ名、パスワードを使用するGBAモードUserID,Usersecret:=B-TID,KsNAFを使用し、ここで、[SET]Ks及びSLPURLからKsNAFを生成する[SLP]UserIDフィールドを抽出した時点で、SLPがBSFにB-TIDを提供し、BSFは、KsNAFとともに戻る。KsNAFは、B-TIDが変化しないかぎり変化しない。SUPLINITセキュリティ提案ULPTSV2.0Section6.1.6.6において既に定義されているBasicSUPLINITProtectionを使用するユーザモードにおけるGBAによってプロビジョニングされた鍵からSLPによってプロビジョニングされた鍵への適合化された記述SLPが、ユーザモードにおいてクライアント又はSLPのイニシアチブでULPセッション中に鍵識別子、SUPLINITROOTKEYを更新する-鍵識別子がリセットされたときにBasicReplayCounterがリセットされる最小限の標準化努力が要求されるSUPLINITProtectionパラメータBasicSUPLINITProtectionのためのSUPLINITプロテクタは、下記から成る。鍵識別子BasicReplayCounter長さ=2オクテットBasicMAC長さ=4オクテットBasicMACパラメータは、以下のように生成される。BasicMAC=HMAC-SHA256-32SUPLINITBasicIK,‘SUPLINIT’SUPLINITBasicIK=HMAC-SHA256-128SUPLINITROOTKEY,BasicIK鍵識別子がリセットされるときにBasicReplayCounterがリセットされる。鍵識別子及びSUPLINITROOTKEYは、UserID及びUsersecretと同じでなく、すなわち、SUPLINIT保護は、ULPメッセージ認証から独立して機能する。SUPLINITクレデンシャル管理あらゆる接続セッションの最初のULPやり取りにおいて生じるSETを発生元とするメッセージセッションの最初のメッセージは下記のいずれかを含むべきである。-クレデンシャルが入手可能でない場合は、SUPLINITCredentialReqインジケータ、又は-SET及びSLPが同期外れであるかどうかをSLPが検出するのを可能にするためのCurrentKeyIdentifierSLPを発生元とするメッセージCurrentKeyIdentifierが正しい場合は、確認のためのSUPLINITCredentialOKインジケータを加えるCurrentKeyIdentifierが正しくない場合、又は、SETがSUPLINITCredentialReqインジケータを送信した又はサーバがSUPLINITクレデンシャルを更新することを希望する場合は、SLPは、SUPLINITクレデンシャルをプロビジョニングするためにULPメッセージにフィールドを加える。-鍵識別子、SUPLINITROOTKEYを含む。呼流れ例-SI即時フィックスステップA:ターゲットSETがreqcountを1234又はSETによって決定されたその他のいずれかの連続番号に設定し及びメッセージダイジェストreqdigestを計算する。ターゲットSETがSUPLSTARTuser-id,reqcount=1234,reqdigest,...メッセージをH-SLPに送信する。ステップB:H-SLPが、受信されたメッセージダイジェストreqdigestを用いてSUPLSTARTの真正性を検査し及びリプレイカウンタreqcountも検査する。H-SLPが、rescountを4321又はSETによって決定されたその他のいずれかの連続番号に設定し及びメッセージダイジェストresdigestを計算する。H-SLPがSUPLRESPONSEuser-id,rescount=4321,res-digest,...メッセージをターゲットSETに送信する。ターゲットSETにおけるSUPLSTARTとSUPLRESPONSEとの間の期間=UT1。ステップC:ターゲットSETが、受信されたメッセージダイジェストresdigestを用いてSUPLRESPONSEの真正性を検査し及びリプレイカウンタrescountも検査する。ターゲットSETが、reqcountを1だけ増分し12341及びメッセージダイジェストreqdigestを計算する。ターゲットSETが、SUPLPOSINITuser-id,reqcount=12341,reqdigest...メッセージをH-SLPに送信する。H-SLPにおけるSUPLRESPONSEとSUPLPOSINITとの間の期間=ST1。ステップD:ターゲットSET及びH-SLPがSUPLPOSのやり取りに従事する。ターゲットSETにおけるSUPLPOSINITとSUPLPOSとの間の期間=UT2。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタreqcount/rescountに基づいてリプレイ完全性を検査する。ステップE:H-SLPが、受信されたメッセージダイジェストreqdigestを用いて受信された最後のSUPLPOSメッセージの真正性を検査し及びリプレイカウンタreqcountも検査する。H-SLPがreqcountを増分し43211及びメッセージダイジェストresdigestを計算する。H-SLPが、SUPLENDuser-id,rescount=43211,resdigest,...メッセージをターゲットSETに送信する。ターゲットSETが、受信されたメッセージダイジェストresdigestを用いてSUPLENDの真正性を検査し及びリプレイカウンタreqcountも検査する。ターゲットSETにおけるSUPLPOSとSUPLENDとの間の期間=UT3。呼流れ例-NI即時フィックスステップA:H-SLPがrescountを1234又はH-SLPによって決定されたその他のいずれかの連続番号に設定し及びメッセージダイジェストBasicMACを計算する。H-SLPがSUPLINITuser-id,rescount=4321,BasicMAX,...メッセージをターゲットSETに送信する。ステップB:ターゲットSETが、受信されたメッセージダイジェストBasicMACを用いてSUPLINITの真正性を検査し及びリプレイカウンタrescountも検査する。ターゲットSETが、reqcountを1234又はSETによって決定されたその他のいずれかの連続番号に設定し及びメッセージダイジェストreqdigestを計算する。ターゲットSETが、SUPLPOSINITuser-id,reqcount=1234,req-digest,...メッセージをH-SLPに送信する。H-SLPにおけるSUPLINITとSUPLPOSINITとの間の期間=ST1。ステップC:ターゲットSET及びH-SLPがSUPLPOSのやり取りに従事する。ターゲットSETにおけるSUPLPOSINITとSUPLPOSとの間の期間=UT2。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタreqcount/rescountに基づいてリプレイ完全性を検査する。ステップD:H-SLPが、受信されたメッセージダイジェストreqdigestを用いて受信された最後のSUPLPOSメッセージの真正性を検査し及びリプレイカウンタreqcountも検査する。H-SLPがreqcountを増分し43211及びメッセージダイジェストresdigestを計算する。H-SLPが、SUPLENDuser-id,rescount=43211,resdigest,...メッセージをターゲットSETに送信する。ターゲットSETが、受信されたメッセージダイジェストresdigestを用いてSUPLENDの真正性を検査し及びリプレイカウンタrescountも検査する。ターゲットSETにおけるSUPLPOSとSUPLENDとの間の期間=UT3。追加の実施形態3序論SUPL2.0におけるセキュリティは、アクセスネットワーク専用である。ACAは、ソースIPアドレスに基づいてSETを識別するためのコアネットワークへのアクセスを要求するGBAは、3GPP/3GGP2ネットワークのみに適用可能SEKは、WiMAXネットワークのみに適用可能SUPL3.0における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。GBA及びユーザ名/パスワード認証の両方をサポートする単純な枠組選択肢I:概念概要ULPセキュリティGBAモード:以前と同じようにTLS-PSKを使用ユーザモードULP:ユーザ名、パスワードに基づく-最初にサーバ証明書によるTLSハンドシェイクを実施してセキュアなコネクションを確立するSETによって送信された全ULPメッセージに加えられたユーザ名、カウンタ、ダイジェストであり、ダイジェストは以下のように計算される-A1=SLPDomainULPMessage-Digest=HMACPassword,A1SETがユーザ名、カウンタ、ダイジェストを全メッセージに加え、SLPが検証するSUPLINIT保護のために要求されるSUPLINITクレデンシャルKeyIdentity,SUPLINITROOTKEYを更新するためにULPが使用される選択肢I:オフライン手順ユーザモードULPオフラインユーザ及びSLPオペレータがユーザ名、パスワードを取り決めるその他の前提事項SETがSLPのURLを有するSETがSLPを認証するための該当するルート証明書を有する選択肢I:オンライン手順サーバ認証及び暗号化のために用いられるサーバ証明書によるTLSSETからのULPメッセージに新しいパラメータが加えられる:ユーザ名、カウンタ、ダイジェストSLPが、ULPメッセージ内容を処理する前にカウンタ及びダイジェストを検証するカウンタの目的は、リプレイ検出を可能にすることであるすべてのULPセッションに関して受信元及び送信元においてカウンタがリセットされる送信元において、メッセージごとにカウンタが増分され、ULPメッセージに加えられる受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す。選択肢II:概念概要ULPセキュリティGBAモード:以前と同じようにTLS-PSKを使用ユーザモードTLS:ユーザ名、パスワードに基づく-最初にサーバ証明書によるTLSハンドシェイクを実施してセキュアなコネクションを確立する。-SLPが、TLS再交渉を開始するためにHelloRequestを送信する。次に、SET及びSLPが、ユーザ名、パスワードを用いてユーザを認証するためにTLS-SRPハンドシェイクSRP=セキュアリモートパスワードを実施する。-TLS-SRPハンドシェイクにおいてユーザ名を隠すために最初のセキュアなコネクションが要求される。SUPLINIT保護のために要求される基本的保護SUPLINITクレデンシャルKeyIdentity,SUPLINITROOTKEYを更新するためにULPが使用される選択肢II:オフライン手順ユーザモードTLSオフラインユーザ及びSLPオペレータがユーザ名、パスワードを取り決めるその他の前提事項SETがSLPのURLを有するSETがSLPを認証するための該当するルート証明書を有する選択肢II:オンライン手順SETがTLSハンドシェイクを開始し、該当する暗号スィートを選択することによってGBA及び/又はユーザモードのためのサポートをTLSにおいて示す。SLPがGBAモード又はユーザモードを進めるべきかどうかを決定するGBAモードの場合セキュアなトンネルを確立するためにGBAを用いてTLS-PSKの場合と同じようにTLSハンドシェイクを継続する相互認証セキュアなチャネルでデータをやり取りするユーザモードの場合最初に、セキュアなチャネルを確立するためにサーバ証明書によるTLSハンドシェイクを継続するSETがSLPを認証するTLS=SRPハンドシェイクを実施するメッセージは、セキュアなチャネル内部でやり取りされるSLPがユーザを認証する新しいセッション鍵が得られる新しいセッション鍵によって保護されたセキュアなトンネルでデータをやり取りする選択肢II:オンライン手順-最初のTLSハンドシェイクSET→SLP:ClientHello:すべてのサポートされる暗号スイートを示す-SETがGBAをサポートする場合は、TLS-PSK暗号スイートのためのサポートを示す-SETがユーザモードをサポートする場合は、サーバ証明書及びTLSSRPを用いるTLSのためのサポートを示すSETはこの時点ではユーザ名を提供せず、要求される場合は、次のTLSハンドシェイクで提供される。SLP→SET:ServerHello:選択された暗号スイートを示す-SLPがGBAモードを選択する場合は、SLPは、TLS-PSK暗号スイートを示す-SLPがユーザモードを選択する場合は、SLPは、サーバ証明書を用いるTLSのための暗号スイートを示す-呼の流れが選択された暗号スイートの場合と同じように進む選択肢II:オンライン手順-最初のTLSハンドシェイク後GBAモードSET及びSLPが、セキュリティが確保されたチャネルを通じての通信を開始するユーザモードSLP→SET:HelloReqeust再交渉を開始するSET→SLP:ClientHelloTLS-SRPのためのサポートを示すTLS-SRP仕様に準拠してユーザ名を含めるSET→SLP:ServerHelloTLS-SRPの選択を示すTLS-SRPに準拠してやり取りを継続する成功裏のハンドシェイクに後続して、SET及びSLPが、セキュリティが確保されたチャネルでデータをやり取りすることを開始するSUPLINIT保護SUPL3.0におけるSUPLINIT保護は、SUPL2.0におけるSUPLINIT保護メカニズムに基づき、SUPLINITに添付されたメッセージ認証コードMACを使用するMACは、ユーザモードでULPを通じてプロビジョニングされたKey,Identity,SUPLINITROOTKEYを用いて計算されるGBAモードは、プロビジョニングを要求しないKey,Identity,SUPLINITROOTKEYを計算するための2つの方法:GBAモード:Key,Identity,SUPLINITROOTKEY=B-TID,Ks-B-TID,KsがBSFからブートストラップを外されるユーザモード:Key,Identity,SUPLINITROOTKEYがユーザ名、パスワードから生成されるSUPLINIT保護は、選択肢I及び選択肢IIに関して同じであるSUPLINIT保護メカニズムSUPLv3.0における2つの保護レベルNULL-セキュリティなし基本的保護-ULPを通じてプロビジョニングされた共有される鍵アイデンティティ、SUPLINITROOTKEYに基づく-SUPLv2.0からの基本的保護を模倣する-鍵識別子及びSUPLINITROOTKEYは、ユーザ名、パスワードと同じでない再同期化保護メカニズムSETがSETにおいてSLPの証明書から検証することができるというデジタルシグナチャに基づくSLP及びSETにおける鍵アイデンティティ、SUPLINITROOTKEYが同期外れになっていることにSLPが納得するときしか使用できない計算コストが高い可能がある:控えめに使用することができる。BasicSUPLINITProtectionパラメータBasicSUPLINITProtectionのためのSUPLINITプロテクタは、下記から成る。鍵識別子BasicReplayCounter長さ=2オクテットBasicMAC長さ=4オクテットBasicMACパラメータは、以下のように生成される。BasicMAC=HMAC-SHA256-32SUPLINITBasicIK,‘SUPLINIT’SUPLINITBasicIK=HMAC-SHA256-128SUPLINITROOTKEY,BasicIK鍵識別子がリセットされるときにBasicReplayCounterがリセットされる。SUPLINITROOTKEY管理あらゆるSUPLセッションの最初のULPやり取りにおいて生じる第1のSETを発生元とするメッセージセッションの第1のメッセージは下記のいずれかを含むべきである。-クレデンシャルが入手可能でない場合は、SUPLINITCredentialReqインジケータ、又は-SET及びSLPが同期外れであるかどうかをSLPが検出するのを可能にするためのCurrentKeyIdentifierSLP応答CurrentKeyIdentifierが正しい場合は、確認のためのSUPLINITCredentialOKインジケータを加える。CurrentKeyIdentifierが正しくない場合、又は、SETがSUPLINITCredentialReqインジケータを送信した又はSLPがSUPLINITクレデンシャルを更新することを希望する場合は、SLPは、SUPLINITクレデンシャルをプロビジョニングするためにULPメッセージにフィールドを加える。-鍵識別子、SUPLINITROOTKEYを含む。概要SUPL3.0では2つの新しいセキュリティモデルが考慮される選択肢I:ユーザモードULP選択肢II:ユーザモードTLSこれらの2つの新しいセキュリティモードは、ユーザ名、パスワードクライアント認証を使用し、サーバ認証及び暗号化は、レガシーのサーバ認証TLSに基づく。両選択肢とも、全ベアラをサポートするbeareragnosticセキュリティモデルであり、このため、SUPL3.0に適する。該当する場合及び望ましい場合はレガシーセキュリティモデルACA及びGBAを依然として使用することができる。SRP基本事項TLS-SRP[IETFRFC5054]は、セキュアリモートパスワードSRP[RFC2945]を認証及び鍵やり取りの基礎として使用する。主ステップ認証を行うサーバは、パスワードは不要であり、その代わりに、{Username,PasswordVerifier,Salt}を含むトリプレットを格納する。典型的には、ユーザのクライアントは、オフラインでサーバに登録時にトリプレットを生成する。Saltは、ユーザがランダムに選択することができる。PasswordVerifierは、Diffie-Hellman鍵やり取りと同様の複雑な数学を用いてUsername、Salt及びユーザのパスワードから計算される。サーバは、下記のためにユーザと対話してトリプレットを使用するユーザがパスワードを知っていることを検証するユーザ及びサーバのみによって知られる共有される秘密を確立する。この共有される秘密は、暗号化及び完全性保護のための鍵を生成するために使用することができるTLS-SRPでどのように使用されるか。SRPの幾つかの特性トリプレットは、ユーザになりすますために使用することができないサーバがトリプレットを守秘する必要がないサーバは、第三者がユーザになりすますことを試みるということを懸念せずに、第三者がユーザを検証するのを可能にするために第三者にトリプレットを提供することができる。-例えば、H-SLPは、A-SLPがユーザを認証するのを可能にするためにA-SLPにトリプレットを提供することができる。追加の実施形態4序論SUPL2.0におけるセキュリティは、アクセスネットワーク専用である。ACAは、ソースIPアドレスに基づいてSETを識別するためのコアネットワークへのアクセスを要求するGBAは、3GPP/3GGP2ネットワークのみに適用可能SEKは、WiMAXネットワークのみに適用可能SUPL3.0における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。GBA及びユーザ名/パスワード認証の両方をサポートする単純な枠組以下の説明では、両方の選択肢を対象にし、各手法の利点及び潜在的な欠点について論じる。ユーザモードオフライン手順ユーザモードULPオフラインユーザ及びSLPオペレータがユーザ名、パスワードを取り決めるその他の前提事項SETがSLPのURLを有するSETがSLPを認証するための該当するルート証明書を有するユーザモードULP:概念概要IユーザモードULP:ユーザ名、パスワードに基づく最初にサーバ証明書によるTLSハンドシェイクを実施してセキュアなコネクションを確立するSETによって送信された全ULPメッセージにユーザ名、カウンタ、ダイジェストが加えられ、ダイジェストは以下のように計算される-ULPMessageZは、ダイジェストフィールドがゼロに設定されたULPMessageである-UserULPIK=SHA-256Username:Password:SLPDomain:SUPL30ULP-Digest=HMAC-SHA-256-32UserULPIK,ULPMessageZSETがユーザ名、カウンタ、ダイジェストを全メッセージに加え、SLPが検証するユーザモードULP:概念概要IIサーバ認証及び暗号化のために用いられるサーバ証明書によるTLSSETからのULPメッセージに新しいパラメータが加えられる:ユーザ名、カウンタ、ダイジェストSLPが、ULPメッセージ内容を処理する前にカウンタ及びダイジェストを検証するカウンタの目的は、リプレイ検出を可能にすることであるすべてのULPセッションに関して受信元及び送信元においてカウンタがリセットされる送信元において、メッセージごとにカウンタが増分され、ULPメッセージに加えられる受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡すユーザモードTLS:概念概要ユーザモードTLS:ユーザ名、パスワードに基づく最初にサーバ証明書によるTLSハンドシェイクを実施してセキュアなコネクションを確立する。SLPが、TLS再交渉を開始するためにHelloRequestを送信する。次に、SET及びSLPは、ユーザ名、パスワードを用いてユーザを認証するためにTLS-SRPハンドシェイクSRP=セキュアリモートパスワードを実施する。TLS-SRPハンドシェイクにおいてユーザ名を隠すために最初のセキュアなコネクションが要求される。選択肢I:オフライン手順概要SETがTLSハンドシェイクを開始し、TLSにおいて、該当する暗号スィートを選択することによってGBA及び/又はユーザモードのためのサポートを示す。SLPがGBAモード又はユーザモードを進めるべきかどうかを決定するGBAモードの場合セキュアなトンネルを確立するためにGBAを用いてTLS-PSKの場合と同じようにTLSハンドシェイクを継続する-相互認証を提供するセキュアなチャネルでデータをやり取りするユーザモードの場合セキュアなチャネルを確立するためにサーバ証明書によるTLSハンドシェイクを継続する-SETがSLPを認証するセキュアなチャネルでデータをやり取りする-SLPがユーザを認証するのを可能にする新しいパラメータがSETからのULPメッセージに加えられるユーザ名、カウンタ、ダイジェスト選択肢I:オンライン手順詳細-TLSハンドシェイクSET→SLP:ClientHello:すべてのサポートされた暗号スイートを示す-SETがGBAをサポートする場合は、TLS-PSK暗号スイートのためのサポートを示す-SETがユーザモードをサポートする場合は、サーバ証明書を用いるTLSのためのサポートを示すSLP→SET:ServerHello選択された暗号スイートを示す-SLPがGBAモードを選択する場合は、SLPは、TLS-PSK暗号スイートを示す-SLPがユーザモードを選択する場合は、SLPは、サーバ証明書を用いるTLSのための暗号スイートを示す呼の流れは、選択された暗号スイートに関する場合と同じように進む選択肢I:オンライン手順詳細-TLSハンドシェイク後GBAモードSET及びSLPがセキュアなチャネルを通じて通信を開始するユーザモードSET及びSLPがセキュアなチャネルを通じて通信を開始するSETからのULPメッセージに新しいパラメータが加えられる:ユーザ名、カウンタ、ダイジェスト-SLPが、ULPメッセージ内容を処理する前にカウンタ及びダイジェストを検証する-カウンタの目的は、リプレイ検出を可能にすることである-すべてのULPセッションに関して受信元及び送信元においてカウンタがリセットされる-送信元において、メッセージごとにカウンタが増分され、ULPメッセージに加えられる-受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ検出を渡す選択肢II:オンライン手順概要SETがTLSハンドシェイクを開始し、該当する暗号スイートを選択することによってGBA及び/又はユーザモードのためのサポートをTLSにおいて示す。SLPがGBAモード又はユーザモードを進めるべきかどうかを決定するGBAモードの場合1.セキュアなトンネルを確立するためにGBAを用いてTLS-PSKの場合と同じようにTLSハンドシェイクを継続する-相互認証2.セキュアなチャネルでデータをやり取りするユーザモードの場合1.最初に、セキュアなチャネルを確立するためにサーバ証明書によるTLSハンドシェイクを継続する-SETがSLPを認証する2.TLS-SRPハンドシェイクを実施するメッセージは、セキュアなチャネル内部でやり取りされる-SLPがユーザを認証する-新しいセッション鍵が得られる3.新しいセッション鍵によって保護されたセキュアなトンネルでデータをやり取りする選択肢II:オンライン手順-最初のTLSハンドシェイクSET→SLP:ClientHello:すべてのサポートされる暗号スイートを示す-SETがGBAをサポートする場合は、TLS-PSK暗号スイートのためのサポートを示す-SETがユーザモードをサポートする場合は、サーバ証明書及びTLSSRPを用いるTLSのためのサポートを示すSETはこの時点ではユーザ名を提供せず、要求される場合は、次のTLSハンドシェイクで提供される。SLP→SET:ServerHello:選択された暗号スイートを示す-SLPがGBAモードを選択する場合は、SLPは、TLS-PSK暗号スイートを示す-SLPがユーザモードを選択する場合は、SLPは、サーバ証明書を用いるTLSのための暗号スイートを示す-呼の流れが選択された暗号スイートの場合と同じように進む選択肢II:オンライン手順詳細-最初のTLSハンドシェイク後GBAモードSET及びSLPが、セキュリティが確保されたチャネルを通じての通信を開始するユーザモードSLP→SET:HelloReqeust-再交渉を開始するSET→SLP:ClientHello-TLS-SRPのためのサポートを示す-TLS-SRP仕様に準拠してユーザ名を含めるSET→SLP:ServerHello-TLS-SRPの選択を示す-TLS-SRPに準拠してやり取りを継続する成功裏のハンドシェイクに後続して、SET及びSLPが、セキュリティが確保されたチャネルでデータをやり取りすることを開始するSUPLINIT保護SUPL3.0におけるSUPLINIT保護は、SUPL2.0におけるSUPLINIT保護メカニズムに基づき、SUPLINITに添付されたメッセージ認証コードMACを使用する。2つの認証法○GBAモードKey,Identity,SUPLINITROOTKEY=B-TID,Ks◆B-TID,KsがBSFとのブートストラップから外される○ユーザモード:認証がユーザ名、パスワードを使用するSUPLINIT保護は、選択肢I及び選択肢IIに関して同じであるSUPLINIT保護メカニズムSUPLv3.0において次の3つのタイプの保護が提供されるNULL-セキュリティなしGBAモード保護-SUPLv2.0基本保護と同一であるユーザモード保護-ユーザ名、パスワードに基づく認証-辞書攻撃を防止するためにランダム値を加える-リプレイを防止するために時間を加えるSUPLINITGBAモード保護GBA認証を使用する場合は、SUPLINITプロテクタパラメータは、下記から成る。鍵識別子=GBAB-TID長さ=可変GBAReplayConter長さ=2オクテット。リプレイを防止するSUPLINITGBAMAC長さ=4オクテット。メッセージを認証する。SUPLINITGBAMACパラメータは、次のように生成される。SUPLINITGBAMAC=HMAC-SHA256-32SUPLINITGBAIK,SUPLINITZSUPLINITGBAIK=HMAC-SHA256-128SUPLINITROOTKEY,GBAIKSUPLINITROOTKEYは、B-TIDに対応するGBAkeyKsint/extNAFであるSUPLINITZは、SUPLINITGBAMACフィールドがすべてゼロに設定されたSUPLINITメッセージである。鍵識別子がリセットされたときにGBAReplayCounterがリセットされるSUPLINITユーザモード保護ユーザモードセキュリティを使用する場合は、SUPLINITProtectorパラメータは、下記から成る。SUPLINITRAND長さ=8オクテット。これは、パスワードに対する辞書攻撃を防止するためにこのメッセージにとって一意のランダムな値であることができる。SUPLINITTIME長さ=4オクテット。メッセージ送信時間。リプレイを停止させる。SUPLINITUSERMAC長さ=4オクテット。メッセージを認証する。SUPLINITUSERMACはパラメータ次のように生成される。SUPLINITUSERMAC=HMAC-SHA256-32SUPLINITUSERIK,SUPLINITZSUPLINITUSERIK=SHA-256Username:Password:SLPDomain:SUPL30INITSUPLINITZは、SUPLINITUSERMACフィールドがすべてゼロに設定されたSUPLINITメッセージである。概要SUPL3.0では2つの新しいセキュリティモデルが考慮される。選択肢I:ユーザモードULP選択肢II:ユーザモードTLSこれらの2つの新しいセキュリティモードは、ユーザ名、パスワードクライアント認証を使用し、サーバ認証及び暗号化は、レガシーのサーバ認証TLSに基づく。両選択肢とも、全ベアラをサポートするbeareragnosticセキュリティモデルであり、このため、SUPL3.0に適する。該当する場合及び望ましい場合はレガシーセキュリティモデルACA及びGBAを依然として使用することができる。追加の実施形態5序論OMASUPL2.0におけるセキュリティは、アクセスネットワーク専用である。ACA代替クライアント認証は、ソースIPアドレスに基づいてSETを識別するためのコアネットワークへのアクセスを要求するGBA汎用ブートストラッピングアーキテクチャは、3GPP/3GGP2ネットワークのみに適用可能SEKSUPL暗号化鍵は、WiMAXネットワークのみに適用可能OMASUPL3.0における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。ユーザ名/パスワード認証に基づく単純な枠組レガシーのACA及びGBAに基づくセキュリティもサポートされるSUPL3.0セキュリティ概念概要IIACA及びGBAは、アクセスネットワーク専用であるが、該当する場合及びSUPLオペレータの選択に依存して使用することができる。ユーザモードTLSは、アクセスネットワークから独立しており、ACAの拡張とみなすことができる。ユーザモードTLS-概要I公開鍵TLSサーバ認証-H-SLP及びSLPは、セキュアな状態で接続され、H-SLTは認証されるがSETは認証されない。ユーザ名/パスワードTLS-SRPクライアント認証-H-SLP及びSLPは、セキュアな状態で接続され、H-SLT及びSETの両方が認証される。ユーザモードTLS最初に、セキュアな暗号化されたIP接続を生成するACAの場合と同じように公開鍵TLSを用いてサーバが認証される次に、SET及びSLPの両方において予めプロビジョニングされたユーザ名/パスワードを用いてTLS-SRPセキュアリモートパスワードに基づいてクライアントが認証されるユーザモードTLS概要II単純なユーザ名/パスワードメカニズムは、問題及び/又は脅威を引き起こすおそれがある。ユーザ名/パスワードが盗まれて異なるデバイスで使用されるおそれがあるユーザ名/パスワードが自由意志で明かされて異なるデバイスで同時に使用されるおそれがあるこれは以下によって解決することができる。ユーザ名/パスワードは、SUPLサービス起動直後の最初のSUPLセッションのみに関して使用する最初のSUPLセッション中に、SLPが、新しいユーザ名/パスワードを生成して最初のユーザ名/パスワードによって生成されたセキュアなIP接続を用いてSETに送信する次に、SETが最初のユーザ名/パスワードを新しいユーザ名/パスワードに取り代え、旧ユーザ名/パスワードを削除する次に、SLPによって生成されたユーザが見ることができないユーザ名/パスワードによってデバイスがSUPLサブスクリプションsubscriptionにバインドされる。これで、すべての将来のセッションが、SLPによって生成された新しいユーザ名/パスワードを使用する。その他のデバイスは、このユーザ名/パスワードは使用できない。4つのステップによるユーザモードTLSステップ1:ユーザ及びSLPオペレータが一時的なユーザ名及びパスワードを取り決める:Usernametemp,Passwordtempステップ2:最初のSUPLセッションが確立される。サーバによって認証されたTLSに基づいてサーバ認証及び暗号化が行われる。取り決められたUsernametemp,Passwordtempを用いてTLS-SRPSRP=セキュアリモートパスワードに基づいてクライアント認証が行われる。ステップ3:最初のSUPLセッション内で、SLPが、SETに送信する新しい暗号法的に強力なユーザ名、パスワードを生成し、Usernametemp,Passwordtempをユーザ名、パスワードに代える。SETは、ユーザ名、パスワードをセキュアな場所に格納する。ステップ4:すべての後続するTLSセッションが、サーバによって認証されたTLSに基づいてサーバ認証及び暗号化を使用する。クライアント認証は、ユーザ名、パスワードを用いてTLS-SRPに基づいて行われる。ユーザモードTLSステップ1-詳細ユーザ及びSLPオペレータが一時的なユーザ名及びパスワードを取り決める:Usernametemp,PasswordtempUsernametemp,Passwordtempは、様々な方法でSETにおいてプロビジョニングすることができる。オペレータによるオーバーザエアでのプロビジョニングオペレータのストアでプロビジョニングSETのフラッシングユーザ名及びパスワードを郵送するかオンラインで入手し、SETユーザが入力するその他SETにはSLPのURLがプロビジョニングされているSETには、SLPを認証するために要求される該当するルート証明書がプロビジョニングされているユーザモードTLSステップ2-詳細サーバの認証及び暗号化を開始するための最初のSUPLセッションの最初のTLSハンドシェイクSET→SLP:サーバ証明書及びTLS-SRPによるTLSのためのサポートを示すClientHelloSLP→SET:サーバ証明書によるTLSのための暗号スイートを示すServerHelloクライアント認証を開始するための2回目のTLSハンドシェイクSLP→SET:再交渉を開始するためのHello要求SET→SLP:TLS-SRPのためのサポートを示し、TLS-SRP仕様に準拠したUsernametempを含むClientHelloSLP→SET:TLS-SRPの選択を示すServerHelloクライアント認証は、Usernametemp,Passwordtempに基づいて行われる。新しいセッション鍵が生成されるこのセッション専用これで、SET及びSLPが、セキュリティが確保されたチャネルでSUPLセッションを実施することができる。ユーザモードTLSステップ3-詳細SLPが一時的なユーザ名及びパスワードUsernametemp,Passwordtempに基づいて暗号的に強力なユーザ名、パスワードを生成する。最初に、SLPからSETへのSUPLメッセージが暗号的に強力なユーザ名、パスワードを搬送する。SETが一時的なUsernametemp,Passwordtempをユーザ名、パスワードに代える。SETが一時的なUsernametemp,Passwordtempを廃棄する。SETがユーザ名、パスワードをセキュアな場所に格納する。注1:このステップは、SLPオペレータがユーザを関与させることなしにSETにおいてセキュアな状態でユーザ名/パスワードをプロビジョニングすることができた場合に実施することができる注2:3GPP/3GPP2における最初のアクセスに関しては、SLPは、SETIPアドレスがSETMSISDN又はIMSIと関連付けられていることをコアネットワーク内で検証し、SETがユーザに属することをさらに検証することができるユーザモードTLSステップ4-詳細後続するTLSセッションの確立に関して:サーバの認証及び暗号化を開始するためのTLSハンドシェイク:-SET→SLP:サーバ証明書及びTLS-SRPによるTLSのためのサポートを示すClientHello-SLP→SET:サーバ証明書によるTLSのための暗号スイートを示すServerHelloクライアント認証を開始するための第2のTLSハンドシェイク:-SLP→SET:再交渉を開始するためのHelloRequest-SET→SLP:TLS-SRPのためのサポートを示すClientHello及びTLS-SRP仕様に準拠したユーザ名を含む-SLP→SET:TLS-SRPの選択を示すServerHello-クライアント認証がユーザ名、パスワードに基づいて行われる-新しいセッション鍵が生成されるこれで、SET及びSLPが、セキュリティが確保されたチャネルでSUPLセッションを実施することができる。注:PSK-TLSは、暗号的にセキュアなユーザ名/パスワードが提供された時点で後続するアクセスのために使用可能であるが、TLS-SRPの再使用の方が低い複雑度で実装することができる。SUPLINIT保護概要SUPL3.0におけるSUPLINIT保護は、SUPL2.0におけるSUPLINIT保護メカニズムに基づき、SUPLINITに添付されたメッセージ認証コードMACを使用するSUPLv3.0では次の2つのタイプの保護が提供される:GBAモード保護-SUPLv2.0の基本的保護と同一ユーザモード保護-SLPによって生成されたユーザ名、パスワードに基づく認証すなわち、サービスの起動に使用された最初のユーザ名/パスワードUsernametemp,Passwordtempは使用しない。NULL保護もサポートされており、オペレータの選択に基づいて使用することができる。SUPLINITユーザモード保護IユーザモードTLSセキュリティを使用する場合は、SUPLINITProtectorパラメータは、下記から成る。SUPLINITTIME長さ=4オクテット。メッセージ送信時間。リプレイを停止させる。SUPLINITUSERMAC長さ=4オクテット。メッセージを認証する。SUPLINITプロテクタは、各SUPLINITに加えられ、SETが受信されたSUPLINITメッセージの真正性を検査するのを可能にする。オペレータがSUPLINIT保護を使用する例外的ケース例えば、SET及びSLPが同期外れでは、サービス拒否攻撃が保護されていないSUPLINITを多数のSETに送信することによってつけ込むことができないように例えば、リセットコマンドを介してSETに明示されている限りにおいてSETを再プロビジョニングするためにヌルSUPLINIT保護を一時的に使用することができる。SUPLINITユーザモード保護IISUPLINITUSERMACパラメータは次のように生成される。SUPLINITUSERMAC=HMAC-SHA256-32SUPLINITUSERIK,SUPLINITZSUPLINITUSERIK=SHA-256Username:Password:SLPDomain:SUPL30INITSUPLINITZは、SUPLINITUSERMACフィールドがすべてゼロに設定されたSUPLINITメッセージである。概要SUPL3.0に関して新しいセキュリティモデルが説明される:ユーザモードTLS。ユーザモードTLSは、ユーザ名、パスワードクライアント認証を使用し、他方、サーバ認証及び暗号化は、レガシーのサーバによって認証されたTLSに基づく。SUPLINIT保護は、ユーザモードTLSでもサポートされる。ユーザモードTLSは、全ベアラをサポートするセキュリティモデルであり、このため、SUPL3.0に適する。SUPLオペレータの選択に依存してレガシーセキュリティモデルACA及びGBAを依然として使用することができる。推奨ユーザモードTLSは、SUPL3.0のためのセキュリティモデルとして採用することができる。レガシーのACA及びGBAセキュリティモデルに関してサポートを維持することができる。SUPL3.0アクセスSLPA-SLPローミング中の加入者の場合は、精密な測位のサポートは、H-SLPプロバイダにとっては困難であるが、ローカルなローミングエリアの位置決定プロバイダにとってははるかに簡単である。オペレータは、オペレータBの加入者にとって有益な形でオペレータAに属するH-SLPを一時的に利用することが可能なその他のオペレータ及びプロバイダと取引関係にある場合がある。SUPL3.0RDは、SLPのより広範な利用可能性及びSLPへのより容易なアクセスに関する要件を含む。SUPL-EMER-03:SUPLは、緊急な位置決定要求のためのSETによって開始される及びネットワークによって開始される測位をサポートするものとするSUPL-HLF-18:SUPLは、SLPサービス発見をサポートするものとするH-SLPを有していない加入者が存在することもある-例えば、ホームオペレータがSUPLをサポートしていない-又は任意でH-SLPSUPLサポートを使用していないことがあるSUPLサポートをローミング中の加入者に拡張することを希望するオペレータが存在することがある-例えば、H-SLPを有さないそれら又はH-SLPが特定のローミングエリア内の位置を適切にサポートできないそれらアクセスSLPA-SLPA-SLPは、アクセスネットワークプロバイダに属すること、アクセスネットワークと関連付けること又はアクセスネットワークの地理的エリアをサポートすることができるA-SLPは、H-SLPとほぼ同一の方法でSUPL3.0をサポートすることができ、例えば、すべてのネットワークサービスとSETによって開始されるサービスとを含むSETは、A-SLPを発見すること又はA-SLPに関する情報例えば、A-SLPアドレス及びセキュリティパラメータが提供されることが必要になる可能な情報源は、アクセスネットワーク、H-SLP、及び独立した非標準化された発見であるA-SLPセキュリティは、H-SLPに関して定義される方法を再使用する-例えば、異なる認証方法は回避するべきであるSET及びA-SLPは、外部のSUPLエージェント及びSETの両方のためのSUPL3.0サービスをサポートするために限定された予め取り決められた期間だけ対話することができる可能なA-SLP使用法SETは、アクセスネットワークを介してULP3.0メッセージを用いてSLPと通信し及びA-SLPを発見及び検証するために任意選択で使用されるホームネットワークを介してULP3.0メッセージを用いてH-SLPと通信する。A-SLPは、MLPを介してSUPLエージェントと通信する。ユーザ事例例1-ユーザが新しい都市、町、観光地、等を訪れるH-SLPは、絶対位置しかサポートすることができず、さらに常に正確であるわけではなく例えば、建物内の場合、及び、補助情報、例えば、対象地点、地図、天候/交通情報、等、を提供できないことがある。A-SLPは、アプリケーションレベルのサービスSUPLの一部でない、例えば、方向の発見、対象地点、地図、天候/交通、等とともにより連続的な正確な位置サポートを提供することが可能である。例2-緊急呼サポートA-SLPがE-SLP能力もサポートする場合は、SETによるA-SLPの発見がのちのIPに基づく緊急呼に役立つことができる。SETは、A-SLPからおおよその位置を入手してそれを緊急SIPINVITE内に含め、それによって呼のルーティングを援助するという選択肢を有する。SETとA-SLP/E-SLPとの間での事前の関連付けも、PSAPディスパッチのためののちのより正確な位置決定に役立つことができる。A-SLPセキュリティ-1H-SLPの場合と同じセキュリティ手順が可能である1つの適切なセキュリティ方法は、OMA-LOC-2010-0xyz-INPSUPL3.0Securityにおいて説明されるユーザモードTLSである-例えば、これは、GBAのサポート、3GPP/3GPP2専用アクセス、SETを直接構成する能力を要求しないA-SLPオペレータ又はH-SLPオペレータ両オペレータ間に取引関係が存在する場合は、最初のユーザ名/パスワードを割り当てることができる。A-SLPは、その他のデバイスによる最初のユーザ名/パスワードの使用を回避するために最初のSUPLセッションでそのユーザ名/パスワードを新しい値に代えることができる。A-SLPオペレータは、ユーザ名/パスワードをプロビジョニングされたSETが意図されるユーザに属することを常に検証することができるわけではないが、これは、SETによって開始されたサービスに主に焦点を合わせ及びすべてのローミングユーザに関して同じ料金が課金されるA-SLPサービスにとっては重要ではない。注:ほとんどの場合は、ユーザは、A-SLPへのアクセスの喪失をA-SLPプロバイダに報告し例えば、最初のユーザ名/パスワードが他のユーザによって入手されて使用される場合、現在のユーザ/パスワードを無効にして新しいユーザ名/パスワードに代えることを可能にすることができる。A-SLPセキュリティ-21つの任意選択肢として、H-SLPは、A-SLPを発見するために、検証するために及びA-SLPのためのセキュリティのサポートを援助するために使用することができる。SETは、これらのパラメータのうちの1つを用いてH-SLPにULP要求を送信することができる。A現在のSET位置又はサービスを提供するアクセスネットワークのアイデンティティB既に発見済みのA-SLPアドレス例えば、オンラインで見つけられるか又はアクセスネットワークによって提供Aに関しては、H-SLPは、ローカルエリアにサービスを提供する信用されるA-SLPのアドレスを返信することができる。Bに関しては、H-SLPは、A-SLPが信用される、信用されないか又はH-SLPにとって未知であるかどうかを示すことができる。信用される事例におけるA及びBに関しては、H-SLPは、A-SLP又はH-SLPのいずれかによって割り当てられた最初のユーザ名/パスワードを任意選択でSETに提供することができるユーザ名/パスワード及びユーザ識別を転送するためにA-SLPとH-SLP又は関連付けられたプロバイダとの間での何らかの追加の対話が要求されるSULP3.0AD及びTSの影響既存のH-SLP、V-SLP、E-SLPとともにA-SLPを定義する適切な発見メカニズムを定義又は参照するユーザモードTSLセキュリティの使用を示すA-SLPの発見、検証及びセキュリティのための適切なH-SLPのサポートを加える各端部が新しいセッションのためにサポートするサービスを他方に知らせる既存のSUPL3.0メッセージフローにおいて既にサポートされるようにSET及びA-SLPがサポートされるサービスをH-SLP対話のために用いられるそれらの部分組に限定するのを可能にするあらゆる新しいプライバシー要件存在する場合を識別及びサポートするH-SLPサービスとの関係H-SLPプロバイダは、何らかの取引関係が存在する幾つかのA-SLPプロバイダをサポートすることを選択することができる。H-SLPプロバイダは、その他のオペレータからのローミング加入者へのASLプロバイダとしてサポートを提供することもできるSETは、次のようにA-SLPアクセスを制御するように構成することが可能である。a常にH-SLPを使用し、A-SLPの使用を禁止するbH-SLPを優先するがH-SLPによる承認を条件としてA-SLPの使用を許容する例えば、H-SLPプロバイダとのローミング契約が存在するときのみにA-SLPアクセスを許容するcSETがそれ自体の判定基準に基づいてH-SLPの使用又はA-SLPの使用を自由に決定するのを許容するd常にA-SLPを使用する例えば、H-SLPが存在しないときに該当する正味の結果として、SUPL3.0の使用法及び関連付けられた配備を向上させ、プロバイダ及びユーザにとって有益になることができるA-SLPサポートをSUPL3.0の一部として含めることができるH-SLPセキュリティサポートを再使用し及びH-SLPがA-SLPへのアクセスを援助又は制御するのを許容するあるレベルの非SUPLサポートを考慮する例えば、A-SLPの発見及びA-SLPプロバイダとH-SLPプロバイダとの間での対話に関して追加の実施形態6序論本実施形態は、クライアント認証のためにデバイス証明書を使用する。ACA及びGBAはアクセスネットワーク専用であるが、該当する場合及びSUPLオペレータの選択に依存して使用することができる。この実施形態の新しいセキュリティモデルは、デバイス証明書を用いたクライアント認証である。デバイス証明書に基づくクライアント認証は、アクセスネットワークから独立しており、従って、全タイプのアクセスネットワーク及びデバイスに関して使用することができるすなわち、3GPP/3GPP2でないアクセスネットワーク及びデバイスがサポートされる。デバイスの事前プロビジョニングメーカーは、製造中に下記の項目をSET内でプロビジョニングする。そのSETデバイスに一意の秘密鍵対応する公開鍵を1つ以上のグローバルで一意のSETデバイスアイデンティティ例えば、一連番号、IMEI又はMSIDにバインドさせる証明書1つ以上の一連の証明書が潜在的なSLPによって信用されることになるよく知られた証明書機関に戻される注:SLPによって信用されたCAへ戻る一連の連鎖が存在しない場合は、SLPは、SET認証を信用しない。SLPは、SLPの証明書を検証するために使用することができる1つ以上のルート証明書がSETにプロビジョニングされていることを確認する責任を有するこれらのルート証明書は、SETの製造中又は配布中にプロビジョニングすることができるこれらのルート証明書は、SUPLクライアントソフトウェアとバンドリングすることができる。注:SLP証明書からこれらのルート証明書まで戻る一連の証明書が存在しない場合は、SETは、SLPを認証することができない。OMA-LOCは、実装及び試験を簡略化及び統一するために共通のテンプレート又はプロフィールを規定することができる。デバイス証明書概要ステップ1:加入者認証範囲外加入者が、このデバイスは加入と関連付けられるべきであることをセキュアな形でSLPに検証するステップ2:ランタイムTLSハンドシェイク最初に:サーバ証明書を用いてサーバによって認証されたTLSハンドシェイクを行う次に:暗号化されたTLSトンネル内で、サーバ証明書及びクライアント証明書を用いて相互に認証されたTLSハンドシェイクを行う。これで、セキュアな状態でデータをやり取りすることができる。範囲外outofscpoe加入者認証ISETのアイデンティティのみが認証され、加入者のアイデンティティは認証されないため、SLPは、いずれの加入者が認証されたSETと関連付けられるべきかを知っている。これは、加入者がSET間で切り換わる回数だけ生じる。ユーザがSLPにSETのアイデンティティを提供するだけでは十分でないことがある。理由:ユーザ1は、ユーザ2のSETIDをSLPに提供してこれは私のSETですと言うことができる。SLPは、何が起きているかをユーザ2が承知しない状態でユーザ2の位置の詳細をユーザ1に提供することがある。セキュアな形で加入者をSETIDと関連付けるためにセキュアな方法が使用される。方法が範囲外の状態にされる。幾つかのシステムは、セキュアな形でデバイスアイデンティティを加入者例えば、Apple、Blackberryと関連付けるためのメカニズムを既に有する。方法例が以下において提供される。範囲外加入者認証IIセキュアな形で加入者をデバイスアイデンティティと関連付けるための方法例SLPオペレータが、SETを使用中にSLPによって所有されるウェブサイトに接続するように加入者をプロンプトする。加入者がSETを使用しながらウェブサイトおそらくWAPに接続する。ウェブサーバがデバイス証明書及びウェブサーバ証明書によるTSLハンドシェイクを要求する。この証明書は、SLPサービサーservicerと別個であることができる。加入者がウェブサイトと何らかの範囲外の認証を実施する。例えば、ウェブサイトは、SLP専用のユーザ名/パスワード、認定されたfederatedユーザ名/パスワード又はその他の加入者詳細、例えば、アドレス、誕生日、等、を要求することができる。これで、SLPオペレータが、セキュアな形で加入者をデバイスアイデンティティと関連付けており、この関連付けをSLP内に格納すべきである。ランタイムTLSハンドシェイク概要デバイス証明書に基づくクライアント認証最初に、セキュアな暗号化されたIP接続を生成するACAの場合と同じように公開鍵TLSを用いてサーバが認証されるこれは、デバイス証明書においてデバイスのアイデンティティを隠すことによって匿名性を保持する次に、クライアント及びサーバが、サービス証明書及びデバイス証明書に基づいて相互に認証されたTLSを行うランタイムTLSハンドシェイク詳細サーバによって認証されたセキュリティが確保されたトンネルを開始するための最初のSUPLセッションの最初のTLSハンドシェイクSET→SLP:サーバ証明書及びデバイス証明書によるTLSのためのサポートを示すClientHelloSLP→SET:サーバ証明書によるTLSのための暗号スイートを示すServerHelloSLP←→SET:セキュリティが確保されたトンネルを確立するためのTLSハンドシェイクを完了させる相互認証を行うための2回目のTLSハンドシェイクSLP→SET:再交渉を開始するためのHelloRequestSET→SLP:サーバ証明書及びデバイス証明書によるTLSのためのサポートを示すClientHelloSLP→SET:サーバ証明書及びデバイス証明書によるTLSの選択を示すServerHelloSPL←→SET:セキュリティが確保されたトンネルを確立するためのTLSハンドシェイクを完了させるこれで、SET及びSLPは、セキュリティが確保されたチャネルでSUPLセッションを行うことができる証明書取り消しデバイス証明書及びサーバ証明書の両方を取り消すことができるデバイス及びサーバの両方が、デバイス証明書が取り消されているかどうかを検査するために証明書取り消しリスト例えば、[RFC3280]又はオンライン証明書状態プロトコルOCSP[RFC2560]、等の方法を使用することができる。特定の方法は、段階3で考慮される。SUPLINIT保護概要SUPL3.0でのSUPLINIT保護は、SUPL2.0におけるSUPLINIT保護メカニズムに基づいており、SUPLINITに添付されたメッセージ認証コードMACを使用するこのセキュリティは、SLPに対するサービス拒否攻撃を防止することが目的である。SUPLv3.0は、SUPLv2.0と同じ保護を提供する:モードA保護-GBAに基づくクライアント認証を使用する場合に適用される-SUPLv2.0の基本的保護と同一である-GBAに基づくSUPLINITROOTKEYを使用する-モードB保護-SUPLv3.0は、SLPによってプロビジョニングされたSUPLINITROOTKEYを用いてサポートを追加している-ACA及びデバイス証明書クライアント認証をサポートするNULL保護もサポートされており、オペレータの選択に基づいて使用することができる。SUPLv3.0は、SLPがSUPLINITROOTKEYをプロビジョニングするためのメカニズムを追加しているモードB保護SUPLINITROOTKEYモードBSUPLINIT保護は、SLPがSUPLINITROOTKEYをデバイスにプロビジョニングすることを要求するSUPLINITROOTKEYは、デバイスと加入者のこの組み合わせに関して一意である。SUPLINITROOTKEYは、サービス拒否攻撃に対する保護をSLPに提供するためだけに使用することができることに注目すること。鍵を開示してもどのようなユーザデータも開示しない。鍵を開示しても、サービス拒否攻撃に関わる可能性がある1つの余分のデバイスを追加することになるにすぎない。各SUPLINITROOTKEYは、ほとんど価値を有さないため、この鍵は、有効な形で永久的であり、加入と関連付けられたその他の詳細とともに格納することができる。すなわち、これらの鍵のセキュリティを保護するための特別なサーバが必要ない。注:UNICCが取り除かれることは所有権の変更を示すため、その場合は、SETはSUPLINITROOTKEYを削除する。モードB手順モードBのプロビジョニングを開始モードBのプロビジョニングを開始するための手順モードBのプロビジョニングSLPがSUPLINITROOTKEYをSETにプロビジョニングするSUPLINITROOTKEYを用いないモードB使用法SUPLINITROOTKEYがプロビジョニングされていない場合は、SETは、MACを検証せずにSLPから受け取る最初のSUPLINITメッセージを受け入れる。SUPLINITROOTKEYを用いるモードB使用法SUPLINITROOTKEYがプロビジョニングされた時点で、SETは、MAC及び時間が正確に検証された場合にSLPから受け取ったSUPLINITメッセージを受け入れ、そうでない場合はSUPLINITメッセージを受け入れない。モードB例外-ハードリセットモードBプロビジョニング開始SUPLINITROOTKEYのプロビジョニングを開始すると、SETとSLPとの間でのセキュリティが確保されたULPセッション中にSUPLINITROOTKEYの提供が生じるSUPLINITROOTKEYのプロビジョニングを開始するセキュリティが確保されたULPセッションの開始時に、SETがSUPLINITROOTKEYを有していないことに気がついた場合は、SETは、SUPLINITROOTKEYRequestインジケータを最初のULPメッセージに含めることによってSUPLINITROOTKEYのプロビジョニングを開始する。SETは、セッションが生じない場合はある期間にわたる幾つかの回数のSUPLINITの失敗後にSUPLINITROOTKEYを要求するためのSUPLセッションを生じさせるように構成することができることに注目すること。SET内のSUPLINITROOTKEYが壊れているのではないかとSLPが思う場合例えば、SETがある時間にわたってSUPLINITROOTKEYに応答していない場合は、SLPは、最初のULPメッセージをSETから受信後にSUPLINITROOTKEYのプロビジョニングを開始することができる。モードBのプロビジョニング注:この手順は、モードBプロビジョニング開始に準拠する。SLPがモードB保護をサポートしないことを選択している場合は、SLPは、該当する表示をSETに送信する。その他の場合SLPがSUPLINITROOTKEYを入手するSLPがSETと加入者のこの組み合わせと関連付けられた既存のSUPLINITROOTKEYを有する場合は、SLPは、それのレコードからこの値を取り出すSLPがSETと加入者のこの組み合わせと関連付けられた既存のSUPLINITROOTKEYを有さない場合は、SLPは、新しいSUPLINITROOTKEYを生成する。SLPが、セキュリティが確保されたULPメッセージ内のパラメータとしてSETにSUPLINITROOTKEYを送信するSETがSUPLINITROOTKEYの値を格納する。SETは、SUPLINITROOTKEYの格納された値が壊れているかどうかをSETがのちに検出することを可能にすることになる格納された値の何らかの保護を適用することができる。該保護の例は、誤り訂正及び/又は完全性検査を含む。SUPLINITROOTKEYを有さないモードB使用法SETは、モードB保護を適用可能であるが、SUPLINITROOTKEYを有さない状態になることがある。例は、下記を含む。パワーアップ時で、SUPLINITROOTKEYがプロビジョニングされる前。SUPLINITROOTKEYが壊れているか又は削除されている。SETが該状態にある場合は、SETは、MACを検証せずに、SLPから受信した最初のSUPLINITメッセージを受け入れるSETがSLPとのTLSセッションを確立するSETが、SUPLINITROOTKEYを要求するために上記のモードBプロビジョニング開始手順を実施するSETが該状態にあることをSLPが知っている場合は、SLPは、SETがいずれにせよSUPLINITメッセージを受け入れることを知った状態で、NULL保護を用いて該メッセージを送信する。引き続くULPセッションでは、SET又はSLPは、SUPLINITROOTKEYのプロビジョニングを開始するために上記のモードBプロビジョニング開始手順を使用することができる。SUPLINITROOTKEYを有するモードB使用法SETがSUPLINITROOTKEYを有するとSLPが確信する場合は、SLPは、各SUPLINITメッセージにSUPLINITプロテクタを加える-これは、SETが受信されたSUPLINITメッセージの真正性を検査するのを可能にする。モードB保護を使用する場合は、SUPLINITProtectorパラメータは下記の項目から成る。SUPLINITTIME長さ=4オクテット。メッセージ送信時間。リプレイを停止させる。SUPLINITMODEBMAC長さ=4オクテット。メッセージを認証する。SETがSUPLINITROOTKEYを有する場合は、SETは、SUPLINITTIMEが有効であり及びSUPLINIT内で提供されたSUPLINITMODEBMACがSETによって計算された値と一致する場合のみにメッセージを受け入れる。SUPLINITMODEBMAC計算>SUPLINITMODEBMACパラメータは以下のように生成される:SUPLINITMODEBMAC=HMAC-SHA256-32SUPLINITROOTKEY,SUPLINITZSUPLINITZは、SUPLINITMODEBMACフィールドがすべてゼロに設定されたSUPLINITメッセージである。モードB例外-ハードリセットオペレータがSUPLINIT保護を使用する例外的なケース例えば、SET及びSLPが同期外れでは、サービス拒否攻撃が保護されていないSUPLINITを多数のSETに送信することによってつけ込むことができないように、例えば、リセットコマンドを介してSETに明示されている限りにおいて、SETを再プロビジョニングするためにヌルSUPLINIT保護を一時的に使用することができるこのリセットコマンドは、新たな脅威の導入を防止するために直接SETに入力される。概要SUPL3.0のための新しいセキュリティモデル:デバイス証明書を用いたクライアント認証。デバイス証明書は製造時にプロビジョニングされるデバイス証明書を用いたクライアント認証でもSUPLINIT保護がサポートされる。デバイス証明書に基づくクライアント認証は、全ベアラをサポートするbeareragnosticセキュリティモデルであり、このため、SUPL3.0に適する。SUPLオペレータの選択に依存してレガシーセキュリティモデルACA及びGBAを依然として使用することができる。推奨SUPL3.0のためのセキュリティモデルとしてデバイス証明書を用いるクライアント認証。レガシーのACAセキュリティモデル及びGBAセキュリティモデルのためのサポートを維持する。追加の実施形態7SUPL2.0のためのセキュリティ上の解決方法は、3GPP、3GPP2及びWIMaxアクセスネットワーク以外では利用できないことがあり例えば、WiFiアクセスをサポートしないことがあり、強力なセキュリティをサポートするためにGBAの実装を含む。さらに、セキュリティ上の解決方法は、ホームオペレータSLPH-SLPの代わりに又はホームオペレータSLPH-SLPに加えてアクセス関連SLPA-SLPをサポートするのを可能にできないことがある。本実施形態は、TLS-SRPを用いたクライアントSUPLによってイネーブルにされる端末SETの認証をサポートするためにSLPプロバイダによってユーザ又はユーザのSETに割り当てられたユーザ名及びパスワードを利用する。SUPLSET及びSLPは、SETがSLPを認証することを可能にするために公開鍵TLSを使用することができる。これは、TLS-SRP及び予め取り決められたユーザ名及びパスワードを用いたSLPによるSETの2回目の認証が生じるセキュアなTLS/IPコネクションを生成することができる。これは、最初のセキュアなTLS/IPコネクションを変更することができ、セキュアなSUPLセッションをサポートするために使用される。SLPは、このSUPLセッションを用いて、最初に割り当てられたユーザ名及びパスワードと取り替えるための新しいユーザ名及びパスワードをSETに提供することができる。新しいユーザ名及びパスワードは、ユーザには見えず、これは、ユーザが2つ以上のデバイスでユーザ名及びパスワードを使用するのを防止することができ及びユーザが最初のユーザ名パスワードをその他のユーザに誤って転送しないように保護することができる。この解決方法は、H-SLP及びA-SLPの両方に関して使用することができ、必ずしも3GPP、3GPP2又はWiMaxアクセスネットワークのみの使用を要求しない。従って、説明される実施形態は、SUPLセキュリティサポートを全IPアクセスネットワークに拡大し、GBAをサポートする必要なしに現在配備される解決方法よりも強力なセキュリティを提供することができ、及び、H-SLP及びA-SLPをサポートすることができる節の番号は、SUPL3.0の節番を指すことができる。6.セキュリティ上の考慮事項本節では、SUPLネットワークがSETを認証して権限を付与するのを可能にし及びSETがSUPLネットワークを認証して権限を付与するのを可能にするSUPLセキュリティ機能について説明する。注:別記がないかぎり、頭字語TLSの使用は、TLSハンドシェイクを用いて交渉することができるあらゆるセッションを指す。すなわち、これは、TLS1.1暗号スイート及びTLS-PSK暗号スイートの両方を含む。注:本節では、次の定義が適用される。3GPPベアラネットワークは、そのための規格が3GPPによって維持されるそれであり、これらは、GSMベアラネットワークと、GPRSベアラネットワークと、EDGEベアラネットワークと、WCDMA登録商標/TD-SCDMAベアラネットワークと、LTEベアラネットワークと、LTE-Aベアラネットワークとを含む。3GPP2ベアラネットワークは、そのための規格が3GPP2によって維持されるそれであり、これらは、cdmaOneベアラネットワークと、cdma20001xベアラネットワークと、cdma200EV-DOベアラネットワークとを含む。3GPPSETそれぞれ3GPP2SETは、それのホームネットワークオペレータが主に3GPPベアラネットワークそれぞれ3GPP2ネットワークを介してデータアクセスをサポートするSETである。WiMAXSETは、それのホームネットワークオペレータが主にWiMAXベアラネットワークを介してデータアクセスをサポートするSETである。曖昧な場合は例えば、複数のアクセスタイプをサポートするオペレータ、オペレータは、SETのタイプを決定することができる。注:H-SLPオペレータは、ここにおいて説明される認証方法は同じオペレータに属するアクセスネットワーク間でのSETハンドオーバーに関して及びSETIPアドレスが変更されない場合に引き続き有効であることに注目べきである。手順は、SETが1つのアクセスネットワークから異なるオペレータに属する他に移動するシナリオ又はIPアドレスが変更されるシナリオは考慮していない。これらのシナリオでは、他のアクセスシステムへのハンドオーバー後に、端末及びネットワークにおいてセキュリティコンテキストを利用できないことがあり及びネットワークと端末との間の信用度が変化することがあると推定される。パワーアップ及びシャットダウン、新しいUICCの検出又はUICCの取り外し次第、SETハンドセットは、SUPL3.0と関連付けられたSETハンドセット上の長期鍵は別にしてあらゆる鍵を削除しなければならず、下記のキーを含む。◆GBA鍵:例えば、Ks、KsNAF、KsextNAF◆WIMAX鍵:例えば、SEK◆TLS鍵:例えば、premastersecret、mastersecret、及びPSK値長期鍵は別とする。◆SUPL専用鍵:例えば、SUPLINITメッセージの保護と関連付けられた鍵。6.1SUPL認証方法SUPL3.0に関する認証サポート要件は次の通りである。SETとH-SLPとの間で相互認証をサポートすることができる。SETとD-SLPとの間で相互認証をサポートすることができる。SETとE-SLPとの間でサーバ認証をサポートすることができ、及び、SETとE-SLPとの間で相互認証をサポートすることができる。SUPL3.0は、2つのクラスのSET認証方法をサポートするANに依存する方法であり、クレデンシャルがSETユーザのアクセスネットワーク加入にバインドされる。ANから独立した方法であり、クレデンシャルがSETにバインドされるが、SETユーザのアクセスネットワーク加入に直接はバインドされない。該クレデンシャルをSETユーザのアクセスネットワーク加入にバインドすることは、範囲外out-of-scope手順を用いて達成させることができる。範囲外手順に関する詳細な説明については第6.6節を参照すること。相互認証が実施されるときには、SETは、SET内に含まれているSUPLエージェントを介してSETユーザの代わりに行動することができる。ANに依存する方法に関しては、SETは、SETユーザと関連付けられたセキュリティクレデンシャルを使用する。ANから独立した方法に関しては、SETは、SETと関連付けられたセキュリティクレデンシャルを使用する。SETユーザの認証が成功した場合は、その結果として、SETユーザのID例えば、MSISDN、WIMAXユーザID又はANから独立したユーザアイデンティティが成功裏に識別されなければならないことに注目すること。MSISDNが認証のために使用されるときには、SLPは、認証されたSETのMSISDNがセキュアな形で識別される前にIMSIとMSISDNのバインディングを行わなければならないことに注目すること。鍵管理詳細は第6.1.2節において見ることができる。6.1.1認証方法第6.1.1.1.節は、この明細書でサポートされる認証方法について説明する。第6.1.1.2節では、これらの方法に関する情報を提供するための概要を示してある。第6.1.1.3節は、様々なSUPL3.0のエンティティにおいていずれの方法が強制的又は任意選択であるかを説明し、所定の相互認証方法をサポートする場合に各エンティティにおいて要求されるプロトコルを記載した。6.1.1.1サポートされる相互認証方法の一覧SUPL認証モデルは、取り除くことが可能なトークン、例えばR-UIM/UICC/SIM/USIM又はSETハンドセットのいずれかにバインドされた、SLPとSETとの間での共有秘密鍵を確立することを要求する。本書では次の2つのクラスの認証方法が規定される:PSKに基づく方法、次の方法から成る:○ANに依存する汎用ブートストラッピングアーキテクチャGBAに基づく方法であり、相互認証を提供する;○ANに依存するSEKに基づく方法でありWIMAXSLPのみに適用可能、相互認証を提供する;証明書に基づく方法であり、次の方法から成る:○ANから独立したデバイス証明書に基づくDCert方法であり、相互認証を提供する;○ANに依存する代替クライアント認証ACAに基づく方法であり、相互認証を提供する;○ANから独立したSLP専用の方法であり緊急時のみに適用可能、SLPの認証のみを提供する。6.1.1.2サポートされる認証方法の概要情報用1.汎用ブートストラッピングアーキテクチャGBAに基づく。汎用ブートストラッピングアーキテクチャGBAGBAを有するTLS-PSKは、既存の3GPP/3GPP2認証メカニズムを用いて導き出される共有の秘密に基づく相互認証能力を提供する。SET及びSLPは、汎用ブートストラッピングアーキテクチャGBAを有するTLS-PSKを用いて相互に認証される。2.SEKに基づくWIMAXSLPのみに適用可能SET及びSLPは、SEKを有するTLS-PSKを用いて相互に認証される。SEK方法の詳細は、第6.1.2.1.2節において見つけることができる。3.デバイス証明書DCertに基づく。このANから独立した方法は、以下を用いるTLSを使用するSETに対してSLPを認証するためのRSAサーバ証明書、SLPに対してSETを認証するためのRSAクライアント証明書4.代替クライアント認証ACAに基づく。これは、以下によるTLSを使用するSETに対してSLPを認証するためのRSA証明書、SLPに対するSETの代替クライアント認証第6.1.4参照。この場合は、SLPは、SET識別子MSISDN、等と関連付けられたIPアドレスをベアラネットワークに確認させることによってSETを認証する。5.SLP専用。これは、SLPがSETを認証できないシナリオにおいて使用される。この方法は、非緊急時のためには使用できない。SETは、この方法とACA基づく場合を区別することができない。これは、以下によるTLSを使用するSETに対してSLPを認証するためのRSA証明書SETは認証されない。6.1.1.3エンティティ別の相互認証方法及びプロトコルのサポート以下の4つの表は、様々なクラスのSET及びそれらのSETをサポートするSLPにおけるSUPL3.0のサポートにとって何が任意選択的であり、何が強制的であるかを示す。第1の表は、以下においてSUPL3.0のために実装する上で強制的である方法及び任意選択的である方法を示す。○3GPP/3GPP2SET、○SETR-UIM/SIM/USIM及び○3GPP/3GPP2SETをサポートするSLP第2の表は、以下においてSUPL3.0のために実装する上で強制的である方法及び任意選択的である方法を示す。○WiMAXSET○それらのWiMAXSETをサポートするSLP;第3の表は、以下においてSUPL3.0のために実装する上で強制的である方法及び任意選択的である方法を示す。○3GPP/3GPP2もWiMAXもサポートしないSET、及び○それらのSETをサポートするSLP。第4の表は、様々な認証方法の各々をサポートするためのSLP、SETハンドセット及び該当する場合SETR-UIM/SIM/USIMのための要求されるプロトコルを示す。3GPP/3GPP2SET及びこれらのSETをサポートするSLPのための様々な認証方法に関する要件状況強制的又は任意選択的注1:SLP専用方法のためのSETハンドセットサポートは、緊急時のために要求されることがある。注2:3GPP及び3GPP2専用のACAに基づく方法に関するSET手順は、SLP専用方法に関するSET手順と同一である。従って、3GPP/3GPP2SETハンドセットは、SLP専用方法が緊急時のために要求される結果としてACAに基づく方法をサポートする。WiMAXSET、及びこれらのWiMAXSETをサポートするSLPのための様々な認証方法に関する要件状況強制的又は任意選択的3GPP、3GPP2及びWiMAXをサポートしないSET、及びこれらのSETをサポートするSLPのための様々な認証方法に関する要件状況強制的又は任意様々な相互認証方法をサポートするためのSLP、SETハンドセット及びSETR-UIM/UICC/SIM/USIMのための要求されるプロトコルGBAに基づく方法がサポートされる場合は、BSFは、H-SLPアプリケーションと関連付けられたユーザセキュリティ設定USSを格納する。H-SLPがUSSを要求するときには、BSFは、USSにSETユーザアイデンティティ例えば、IMPI、IMSI又はMSISDNを含めなければならない。注:GBAに基づく方法は、SUPLセッションを転送するために3GPP又は3GPP2ベアラネットワークを使用することには依存していない。しかしながら、SETは、GBAを実施するための必要なクレデンシャルを有するために3GPP又は3GPPホームネットワークオペレータを有さなければならない。6.1.1.4TLSハンドシェイク仕事量を最小にするための技法本節の手順は、SLPとSETとの間でTLSセッションを確立することに関連する作業量を最小にするものである。TLSとの矛盾が生じる場合は、TLSが優先する。SET及びSLPが2つ以上のSUPLセッションと関連付けられたSUPLメッセージを同時に通信中である場合は、SET及びSLPは、これらのメッセージのセキュリティを確保するために単一のTLSセッションを使用すべきである。すなわち、SET及びSLPは、SUPLセッションが同時である場合は別個のTLSセッションを確立すべきではない。SET及びSLPがTLSセッションを確立する場合は、SLPは、短縮されたハンドシェイクを用いてそのセッションを再開するのを可能にすることができる。TLSセッションを再開することの利点は、サーバ証明書に基づいてTLSを再開することは、公開鍵に関する動作を要求しない、すなわち、有意なレベルでより少ない処理を要求する対称的暗号アルゴリズムのみが要求されることである。注:緊急SUPLセッションは非常に偶発的に発生するので必要なデータを確実には格納できないため、このアプローチ法はE-SLPに関しては推奨されない。注:SLPは、TLSSessionIDを割り当てることによってセッションを再開させるのを可能にする。注:GBA及びSEKに基づく認証のために使用されるTLS-PSKセッションを再開させても同じ計算が行われるため利点はない。しかしながら、SLPはそれでもTLS-PSKセッションを再開させるのを可能にすることができる。注:SETは、TLSハンドシェイクのClientHelloメッセージ内のTLSSessionIDパラメータに再開すべきTLSセッションのTLSSessionIDを含めることによってTLSセッションを再開させるのを選択したことを示す。SETがTLSセッションを再開させることを希望しない場合は、SETは、TLSSessionIDを含めずにTLSClientHelloメッセージを送信し、その場合は、フルハンドシェイクが行われる。TLSSessionIDパラメータがTLSClientHelloメッセージ内に存在する場合は、SLPは、TLSセッションを再開させるかどうかを選択する。SessionIDパラメータがTLSClientHelloメッセージ内に存在しない場合は、SLPは、TLSハンドシェイクを前回のTLSセッションと関連付けることができず、このため、TLSハンドシェイクは、フルハンドシェイクを用いて完全に新しいTLSセッションを確立する。SETは、次の指針に従ってTLSセッションを再開させるかどうかを選択する。◆SETは、根本になるクレデンシャルKsextNAF又はSLP証明書又はSEK又はデバイス証明書が期限切れの場合はTLSセッションを再開させてはならない。◆SETは、希望される場合は、根本になるクレデンシャルの期限切れよりも早期にTLSセッションを再開させないことを選択することができる。◆SETは、パワーアップ前又は新しいR-UIM/UICC/SIM/USIMの検出前に確立されたセッションを再開させてはならない。SLPは、次の指針を用いてTLSセッションを再開させるかどうかを選択する。◆SETは、根本になるクレデンシャルKsextNAF又はSLP証明書又はSEK又はデバイス証明書が期限切れの場合はTLSセッションを再開させてはならない。◆SETは、希望される場合は、根本になるクレデンシャルの期限切れよりも早期にTLSセッションを再開させないことを選択することができる。注:各SLPは、短縮されたハンドシェイクを可能にするかどうかをそれ自体で判断しなければならず、この判断は、各々のSETごとに行うことさえも可能である。SLPは、既存のセッションを再開させることを受け入れたときには小さいリスクを冒していることになる。このリスクは、いたずらなSETがフルTLSハンドシェイク中に確立されたmastersecretを配布し、このため、その他の者がそのTLSセッションを再開させることができ、それによって複数のSETが単一のSETに対して課金されるサービスを入手するのを可能にする可能性があることである。いたずらなSETは、SET所有者が知らない状態でこれを行っていることが可能である例えば、悪意のあるコードに責任がある可能性がある。紛失は簡単に制限できることに注目すること。すなわち、該悪用が発生していることをSLPが検出するか又は疑う場合は、SLPは、簡単にaそのmastersecretを使用しているTLSセッションを終了させ、bいたずらなSETを特定し及びc必要な場合はユーザが引き続きサービスを有するのを可能にするためにフルハンドシェイクを用いていたずらなSETを再認証することができる。要約すると、DCert方法、ACAに基づく方法及びSLP専用方法に関して計算を低減させることについてのセッションを再開させることの利益は、攻撃というリスクを上回ると考えられる。6.1.2SUPL認証のための鍵管理SUPL認証モデルは、取り除くことが可能なトークン、例えばR-UIM/UICC/SIM/USIM又はSETハンドセットのいずれかにバインドされた、SLPとSETとの間での共有秘密鍵を確立することを要求する。6.1.2.1PSKに基づく方法6.1.2.1.1GBA方法をサポートする配備GBAをサポートする配備の場合は、共有鍵は次のように確立される:SLPがIP通信のセキュリティを確保するために及びSUPLINITを保護するために鍵素材をBSFに要求するときには、SLPは、USSユーザセキュリティ設定も要求しなければならない。USSは、永久的なユーザアイデンティティ例えば、IMPI、IMSI又はMSISDNを含まなければならない。SETとSLPとの間でのIP通信のセキュリティを確保するためには、SET及びSLPは、GBAを用いてTLS-PSKに従って共有秘密鍵を導き出し及び動作しなければならない。SLPは、SLPを指定する適切に定義されたドメイン名SLPAddressFQDN、例えば、slp.operator.com、を有さなければならない。TLS-PSKのために使用することができるGBAUaセキュリティプロトコル識別子がOMNAレジストリ内で定義されている。SLPは、BSFによって提供された永久的なユーザアイデンティティが対応するセキュリティが確保されたコネクションを通じてSLPによって受信されたSUPLメッセージ内のSETアイデンティティに対応することを確認しなければならない。SUPLINITのMAC保護に関して、GBAにより鍵が導き出される。SUPLINIT保護のために使用することができるGBAUaセキュリティプロトコル識別子がOMNAレジストリ内で定義されている。SUPLINITメッセージに含まれるbasicMACのkeyIdentifierは、KsNAFが生成されるKsのB-TIDでなければならない。注:H/D-SLPによるBSFへのSUPLINIT保護鍵の要求は、典型的には、H/D-SLPによるIP通信のセキュリティを確保する鍵の要求と同時に発生することになる。SETは、有効なKsが常にプロビジョニングされていることを確認しなければならない。有効なKsが存在しない場合は、SETは、KsをプロビジョニングするためのGBAブートストラッピング手順を開始しなければならない。新しいUICCUSIM/SIM/R-UIMがSETによって検出されるごとに新しいKsが確立されなければならない。さらに、SETは、ホームネットワークオペレータによって設定されたKsNAFの寿命が過ぎているときには新しい共有鍵を確立しなけければならない。6.1.2.1.2SEK方法をサポートする配備SEKをサポートする配備の場合は、共有鍵は次のように確立される:SETとSLPとの間でのIP通信のセキュリティを確保するために、SET及びSLPは、共有される秘密鍵を導き出さなければならず及びWiMAXAAAサーバによって提供された永久的なユーザアイデンティティが対応するセキュリティが確保されたコネクションを通じてSLPによって受信されたSUPLメッセージ内のSETアイデンティティに対応することを確認しなければならない。共有される鍵は、次の方法で導き出される:○SEK=HMAC-SHA256LSK,slp.operator.comの16の最上位左端オクテット。ここで、operator.comは、WIMAXオペレータのFQDNであり、LSKは、位置に基づくサービスに関するWiMAXネットワークプロトコル及びアーキテクチャにおける規定に従って導き出される。○SEKは、LSKと関連付けられた位置に基づくサービスに関するWiMAXネットワークプロトコル及びアーキテクチャにおいて定義される位置鍵識別子LSK-IDを引き継ぎ、鍵アイデンティティがWiMAX配備のためのB-TIDとして使用される。SUPLINITのMAC完全性保護のために、鍵は次の方法で導き出される:○SEKMAC=HMAC-SHA256LSK,mac.slp.operator.comの16の最上位左端オクテット。ここで、operator.comは、SLPオペレータのFQDNであり、LSKは、位置に基づくサービスに関するWiMAXネットワークプロトコル及びアーキテクチャにおける規定に従って導き出される。○SUPLINITメッセージに含まれているモードAMACのkeyIdentifierは、SEKMACが生成されるLSKのB-TIDでなければならない。注:SLPによるWiMAXAAAへのSUPLINIT保護鍵の要求は、典型的には、SLPによるIP通信のセキュリティを確保する鍵の要求と同時に発生することになる。SETは、有効なSEKが常に提供されていることを確認しなければならない。有効なSEKが存在しない場合は、SETは、上記に従ってSEKを導き出さなければならない。さらに、SETは、LSKの寿命が経過しているときには新しい共有鍵を確立しなければならない。SLPとWiMAXAAAサーバとの間のインタフェースは、SUPL3.0の範囲外である。6.1.2.2サーバ証明書に基づく方法6.1.2.2.1DCert方法をサポートする配備DCert方法をサポートする配備の場合は、共有鍵は次のように確立される:SETとSLPとの間でのIP通信のセキュリティを確保するために、SET及びSLPは、SLPを認証するサーバ証明書及びSETを認証するクライアント証明書を用いてTLS-RSAを使用しなければならない。クライアント証明書は、グローバルで一意のSETデバイスアイデンティティを提供することができる:○3GPPSETは、IMEIをグローバルで一意のSETデバイスアイデンティティとして使用することができる。○3GPP2SETは、MSIDをグローバルで一意のSETデバイスアイデンティティとして使用することができる。○WiMAXSETは、SET一連番号をグローバルで一意のSETデバイスアイデンティティとして使用することができる。○すべてのその他のSETは、適切なグローバル識別子例えば、売り主の身元を含む一連番号をグローバルで一意のSETデバイスアイデンティティとして使用することができる。SUPLユーザは、このデバイスがそれらの加入と関連付けられるべきであることをセキュリティが確保された形でSLPに検証しなければならない。このセキュアな検証は、本明細書の範囲外である。この話題に関するさらなる説明については第6.5節を参照すること。SUPLINITのMAC完全性保護のために、鍵は、ULPメッセージに入れてSLPによってSETに提供される。これは、第6.3.5節で説明される。6.1.2.2.2ACA方法をサポートする配備ACA方法をサポートする配備の場合は、共有鍵は次のように確立される:SETとSLPとの間でのIP通信のセキュリティを確保するために、SET及びSLPは、SLPを認証するサーバ証明書を用いてTLS-RSAを使用しなければならない。SET認証結果的に得られた共有秘密鍵を、上記の取り外し可能なトークン又は統合されたトークンのいずれかとバインドさせるは、第6.1.4節では非緊急時に関して及び第6.2.5節では緊急時に関して説明されている。SUPLINITのMAC完全性保護に関しては、鍵は、ULPメッセージでSLPによってSETに提供される。これは、第6.3.5節で説明される。6.1.2.2.3SLP専用方法をサポートする配備SLP専用方法をサポートする配備の場合は、共有鍵は次のように確立される:SETとSLPとの間でのIP通信のセキュリティを確保するために、SET及びSLPは、SLPを認証するサーバ証明書を用いてTLS-RSAを使用しなければならない。第6.1.4節では非緊急時に関して及び第6.2.5節では緊急時に関して説明されるようなSET認証結果的に得られた共有秘密鍵を、R-UIM/UICC/SIM/USIM又はSETハンドセットのいずれかにバインドさせるは存在しない。これらの事例ではSUPLINITのMAC保護はサポートされていない。6.1.3相互認証方法のTLSハンドシェイク及び交渉SET及びSLPは、適用されるべき相互にサポートされる認証方法を取り決める必要がある。6.1.3.1相互認証方法の交渉に関して情報用H-SLPへのTLSコネクションを確立するときには、SETは、最初に、以下の優先順序により、最高の優先度を有する相互にサポートされる認証メカニズムを用いてコネクションを確立することを試みる:◆PSKに基づく方法:GBA又はSEKに基づく方法が最も優先されるサポートされる場合;◆DCert方法:2番目に優先されるサポートされる場合◆ACA又はSLP専用方法:3番目に優先されるSETの観点からは、ACAに基づく方法とSLP専用方法との間に差はない。相互にサポートされる認証方法がない場合は、SETは、SUPLセッションを行うことができないことがある。PSKに基づく方法をサポートするSETは、BSF又はWiMAXAAAが問題に遭遇することに起因して所定の時点にGBA又はSEKに基づく方法を使用できないことがある。従って、SETがGBA又はSKEを用いて認証を確立することを試みても、SETがGBA又はSEKに基づく鍵を確立することができるかどうかは必ずしも保証されない。従って、SETは、最高の優先度を有する相互にサポートされる認証メカニズムを常に使用できるわけではない。SETは、利用可能な場合はそれよりも低い優先度の相互にサポートされる認証メカニズムに戻らなければならないことがある。H-SLP証明書でPSKに基づく方法のみがH-SLPによってサポートされることが示され、ブートストラッピングが失敗した場合は、SETは、該当するエンティティがオンラインに戻るための機会を与えるために、TLSハンドシェイクを再試行する前に少しの間待機することができる。SLPがGBA又はSEKのみをサポートする場合は、SLPは、GBA又はSEKを配備しているキャリアの加入者に対してSUPL3.0サービスを提供することに限定される。SLPがACAのみをサポートする場合は、SUPL3.0は、第6.1.4節において詳細に説明される状況でしか使用することができない。該場合に、SETが、SLPがIPバインディングを入手することができない代替ベアラ例えば、無線LANを介して通信する場合は、SLPは、SETを認証することができない。E-SLPがACAのみをサポートする場合は、第6.2.5.節において詳細に説明されるように、SET認証に関する停止警告が存在する。6.1.3.2非WiMAXSETのための相互認証方法の交渉非WiMAXSETの場合は、SUPLセッションのための相互認証方法の交渉は次のように進行する:1.SETが交渉を開始するa.SETがGBAをサポートする場合は、SETは、該当するGBA仕様に準拠した交渉を開始する。b.そうでない場合すなわち、SETがGBAをサポートしない場合は、SETは、ClientHelloメッセージによるTLSハンドシェイクを開始し、ClientHello.ciphersuitesフィールドは、TLS鍵やり取りアルゴリズムのためのRSA暗号化を用いるサポートされるTLS暗号スイートを示す。2.SLPが、受信されたClientHelloメッセージを処理する。SLPがClientHello.ciphersuitesリストを検討し、相互に参照される暗号スイートを選択する。a.SET及びSLPの両方がTLS-PSK暗号スイートをサポートする場合は、これは、GBAのためのサポートを示す。SLPがServerHello、ServerKeyExchange及びServerHelloDoneメッセージで応答し、ServerHello.ciphersuiteは、相互にサポートされるTLS-PSK暗号スイートを示す。b.そうでない場合は、SET及びSLPは、証明書に基づく方法をサポートしなければならないi.SLPがDCert方法をサポートする場合は、SLPは以下の項目で応答する1.ServerHello、ServerHello.ciphersuiteは、TLS鍵やり取りアルゴリズムのためのRSA暗号化を用いる相互にサポートされるTLS-PSK暗号スイートを示す、2.証明書、3.CertificateRequest及び4.ServerHelloDoneメッセージ。i.そうでない場合は、SETが3GPP/3GPP2SETであり、SLPがACA方法をサポートする場合は、SLPは次の項目で応答する1.ServerHello証明書、ServerHello.ciphersuiteは、TLS鍵やり取りアルゴリズムのためのRSA暗号化を用いる相互にサポートされるTLS暗号スイートを示す、2.証明書、3.CertificateRequestメッセージは送信されない4.ServerHelloDoneメッセージ3.SETが、ServerHelloメッセージ及び選択されたものに該当するその他のメッセージを処理し、SETに対して暗号スイートを示すa.ServerHello.ciphersuiteが、GBAがSLPによって選択されていることを示す場合は、SET及びSLPは、GBAプロセスを継続する。詳細は、本書の範囲外である。b.そうでない場合は、ServerHello.ciphersuiteは、TLS鍵やり取りアルゴリズムのためのRSA暗号化を用いる相互にサポートされるTLS暗号スイートを示す。i.SETがCertificate.Requestを受信した場合は、1.SETがDCert方法をサポートする場合は、SETは、デバイス証明書を提供し、SET及びサーバがTLSハンドシェイクを完了させる。サーバは、デバイス証明書内のグローバルで一意のSETデバイスアイデンティティと関連付けられたSUPLユーザを識別することを試みる。SUPLEユーザは、SETデバイスアイデンティティをそれらの加入と関連付けられるべきであることをSLPに対して既にセキュリティが確保された形で検証していることが推定される。a.SUPLユーザが識別されない場合は、セッションを終了させなければならない。TLSハンドシェイクは既に完了していると推定しているため、サーバは、ULP層で通信することが可能である。サーバは、ULPセッションを終了させるための該当するULP誤りメッセージを送信し、次に、TLSセッションを閉じなければならない。b.SUPLユーザが識別される場合は、サーバは、SUPLユーザと同じ権限をSETに提供する。2.そうでない場合は、SETは、SLPに応答し、それがDCert方法をサポートしないことを暗黙に示すための空のClientCertificateメッセージを含める。a.SLPがACAをサポートする場合は、SLP及びSETは、ACA方法に準拠して継続する。SLPは、ACA方法を用いて継続することができる。b.SLPがACA又はSLP専用方法をサポートしないSLPがDCert方法のみをサポートしている可能性がある場合は、SLPは、該当するTLS警告メッセージでTLSハンドシェイクを終了させる。ii.サーバがCertificate.Requestを送信しない場合は、SETは、ACA方法に準拠して継続する。SLPは、ACA方法又はSLP専用方法のいずれかを用いて継続することができる。3GPP2SETは、認証方法の交渉に関して同様の方法を使用し、選択された相違点を有する。6.1.3.3WiMAXSET及びSLPのための認証及び鍵再交渉に関する原則情報用鍵再交渉は、次の2つの方法で行うことができる:1.位置に基づくサービスのためのWiMAXネットワークプロトコル及びアーキテクチャにおいて定義される位置ルートキーが期限切れのときには、SETは、自動的にwimaxネットワークとそれ自体を再認証し、SUPLによって関連付けられたルート鍵がSETによって再生成される、又は、2.SLPが、SEK又は位置に基づくサービスのためのWiMAXネットワークプロトコル及びアーキテクチャにおいて定義される位置ルートキーが期限切れになっていることに気がつき、WiMAXAAAサーバに新しい鍵を要求する、又は3.SLPが、TLSハンドシェイク中にpskidentityunknownTLS警告メッセージを送信する。これは、SETがwimaxネットワークとそれ自体を再認証する必要があり、SUPLによって関連付けられたルート鍵がSETによって再生成される6.1.3.3.1認証手順WiMAX配備においては、PSKTLSハンドシェイクは、次のようにSEKを用いて使用することができる:-ClientHelloメッセージは、1つ以上のPSKに基づく暗号スイートを含むことができる;-ClientHelloメッセージは、規定されたservernameTLS拡張を含むことができ、及び、それは、SLPのホスト名を含むことができる;-ServerHelloメッセージは、SLPによって選択されたPSKに基づく暗号スイートを含むことができる;-ServerKeyExchangeをサーバによって送信することができ、及び、それはpskidentityhintフィールドを含むことができ、及び、それは、静的ストリングSUPLWIMAXブートストラッピングを含むことができる。-ClientKeyExchangeは、pskidentityフィールドを含むことができ、及び、それは、第6.1.2.1.2節において規定される接頭辞SUPLWIMAXブートストラッピング、分離文字;及び現在のBTIDを含むことができる。-SETは、SLP専用の鍵素材、すなわちSEK、からTLSプリマスタ秘密を導き出すことができる。6.1.3.3.2認証失敗認証失敗は、本書の範囲外の文書において説明されるように取り扱うことができる。6.1.3.3.3ブートストラッピングが要求されることの表示TLSハンドシェイク中には、SLPは、PSKに基づく暗号スイートを含むServerHelloメッセージ、及び、静的ストリングSUPLWIMAXブートストラッピングを含むpskidentityhintフィールドを含むServerKeyExchangeメッセージを送信することによってSEK鍵を要求することができることをSETに示すことができる。SETが有効なSEKを有さない場合は、これは、SETが第6.1.2.1.2節において定義されるように新しいSEKを導き出すようにトリガすることができる。6.1.3.3.4ブートストラッピング再交渉表示TLSセッションの使用中に、SLPは、closenotify警告メッセージをSETに送信することによってSEKが期限切れであることをSETに示すことができる。SETが、旧セッションIDを含むClientHelloメッセージを送信することによって旧TLSセッションを再開させることを試みる場合。SLPは、新しいセッションIDを有するServerHelloメッセージを送信することによって旧セッションIDを使用するのを拒否することができる。これは、SETが使用したSEKが期限切れであることをSETに示す。TLSハンドシェイク中に、SLPは、SETによって送信された終了されたメッセージに応答してhandshakefailureメッセージを送信することによってSEKが期限切れになっていることをSETに示すことができる。6.1.4代替クライアント認証ACAメカニズム本節は、GSM/UMTS及びCDMASETをサポートする配備のみに適用される。注:本節全体を通じて、SETIDは、MSISDNSETが3GPPベアラネットワーク上にある場合又はMDN、MIN又はIMSIのうちの1つSETが3GPP2ベアラネットワーク上にある場合のいずれかを意味する。第6.1.3節は、ACAに基づく方法をSLPによって選択することができる状況について概説する。SLPがTLSハンドシェイク中にACAに基づく方法を選択した場合は、SETを認証するためにSETID/IPアドレスマッピングに基づくクライアント認証をSLPによって使用することができる。本節の残りの部分では、代替認証メカニズムと呼ばれるこのメカニズムの詳細について説明する。SLPが代替クライアント認証メカニズムを実装する場合は、SLPは、GBAを有するPSK-TLSを使用する方法も同様に実装することが推奨される。第6.1.1.3節は、いずれのエンティティがACAに基づく方法をサポートしなければならないか、及びACAに基づく方法をサポートするエンティティによってサポートしなければならないアルゴリズムについて説明する。情報を提供することを目的として、ここでのこの情報は繰り返しである。◆ベアラネットワークは、ACAに基づく方法をサポートすることができる。ベアラネットワークは、H-SLPがベアラネットワークの加入者のためにACAに基づく方法をサポートすることを希望する場合はACAに基づく方法をサポートしなければならない。◆SLPは、ACAに基づく方法をサポートすることができる。◆GSM/UMTS及びCDMASETハンドセットは、ACAに基づく方法をサポートしなければならない。◆ACAに基づく方法は、SETUICC/UIM/SIM/USIMは含まない。◆ACAに基づく方法は、SPCエンティティは含まない。代替クライアント認証をサポートするSETは、証明書に基づくサーバSLP認証を用いるTLS1.1もサポートしなければならない。さらに、SETには、それがSLPサーバ証明書を検証するのを可能にするルート証明書をプロビジョニングしなければならない。ルート証明書をSETにプロビジョニングするための様々な異なる方法が存在するため、本明細書では特定のメカニズムは定義されていない。SUPLオペレータは、TLS1.1が代替クライアント認証のために使用されるときには該当するルート証明書がSET内に存在することを確認する必要がある。代替クライアント認証をサポートするSLPは、TLS1.1をサポートしなければならず、及び、有効なTLSサーバ証明書を有していなければならず、それは、代替クライアント認証を実装するSETによって検証することができる。代替クライアント認証ACAメカニズムは、SLPがSETに割り当てられたSETIDへのSETのIPアドレスのバインディングを検査することができるメカニズムである。ACAメカニズムが実装される場合は、SLPは、SETから受信されたSUPLメッセージのソースIPアドレスを、SETにアドレッシングするためにSLPによって用いられるSETIDにマッピングすることができなければならない。SLPがACAメカニズムを使用するためには、ベアラネットワークは、ベアラレベルでのIPアドレススプーフィングspoofingを防止しなければならない。ソースIPアドレスとSETのSETIDとの間での成功裏のマッピングは、ベアラネットワークにおいてSETがセキュアな形で識別されているすなわち、認証されていることを意味する。この解決方法は、SETにおける特定のクライアントSET認証の実装は要求しないが、SLPがベアラからの特定のSETIDのための正確なソースIPアドレスを取得するのをサポートすることを要求する。3GPPベアラ特有の課題:ソースIPアドレスの取得は、すべてのケースで可能であるわけではない-例えば、ホームネットワークではなく訪れたネットワークにおけるGGSNを用いたGPRSローミングアクセスの場合である。従って、代替クライアント認証メカニズムは、ホームネットワークがソースIPアドレスを割り当てるか又はそれへのアクセスを有するときのみ、例えば、SETがホームネットワークでGGSNを使用することが要求されるときのGPRSアクセスの場合、に依存すべきである。3GPP2ベアラ特有の課題:ソースIPアドレスの取得は、すべてのケースで可能であるわけではない-例えば、訪れたネットワーク内において単純なIP又はMIPアドレスを用いるローミングHRPDアクセスの場合である。従って、代替クライアント認証メカニズムは、ホームネットワークがソースIPアドレスを割り当てるか又はそれへのアクセスを有するときのみ、例えば、SETがホームネットワークでHAへのMIPを使用することが要求されるときのHRPDアクセスの場合、に依存すべきである。第6.1.4.1.節は、このメカニズムがSUPL3.0でのクライアント認証のためにどのようにして使用されるかを説明する。SUPLINITを転送するためにUPD/LPが使用される事例では、SLPは、最初に、SETIDを用いてSETIPアドレスに関してベアラネットワークに問い合わせることによって又はIPアドレスを用いてSETIDに関してベアラネットワークに問い合わせることによってIPアドレスを検証することができる。6.1.4.1ACA手順ネットワークによって開始されるシナリオ:SLPからSUPLINITメッセージを受信後に、及び本書の別の場所で説明されるように該当するセキュリティメカニズム及び通知/検証を適用後に、SETは、対応するSUPLセッションを継続する権限が付与され、第6.1.1.4節において説明されるように、既存の、オープンな相互に認証されたTLSセッションが使用されるべきであるか、又は前回の再開可能なTLSセッションを再開させることができる。オープンなTLSセッションがないか又はSET又はSLPがセッションを再開させないことを選択した場合は、SET及びSLPは、新しいTLSセッションを要求し、SET及びSLPは、認証方法を交渉するために第6.1.3節で説明される該当するステップを実施する。次のステップは、ネットワークによって開始されるシナリオにおいてSETを認証するために代替クライアント認証メカニズムが適用されるときにSLPによって使用される:1.SUPLINITメッセージは、SETIDを供給したMLP要求に応答して送信されたことに注目すること。SLPが、MLP要求のためのSLPセッションIDを割り当て、SUPLINITを送信する。SLPが、SLPセッションIDを用いてSETからの応答をMLPからの要求と関連付ける。しかしながら、SLPは、最初に、応答しているSETが正確なSETIDに対応することを検証しなければならない。残りのステップではこの認証プロセスについて説明する。2.SETが、SLPとのTLS1.1セッションを確立する。SETは、SLPによって提示されたTLSサーバ証明書がSETにおいて設定されたSLPのFQDNにバインドされていることを検査しなければならない。3.SLPが、SUPLINITに応答したSETからの最初のSUPLメッセージ内のSLPセッションIDがSLPによって割り当てられた現在有効なSLPセッションIDに対応するかどうかを決定する。最初のSUPLメッセージ内のSLPセッションIDが有効なSLPセッションIDに対応しない場合は、SLPは、該当するメッセージを用いてSUPLセッションを終了する。そうでない場合は、SLPは、対応するSETIDを注記する。4.SETからの最初のSUPLメッセージSUPLPOSINIT、SUPLSTART、SUPLAUTHREQUEST、SUPLTRIGGEREDSTART、SUPLREPORT又はSUPLENDに応答する前に、SLPは、SETのSETIDを検証しなければならない。これを達成する方法は次の2つである。a.SETIDを要求する。i.SLPが、SETによって使用されるソースIPアドレスを用いて現在のSETIDを見つけ出すために根本のベアラネットワークに問い合わせる。1.SETによって送信された最初のSUPLメッセージのソースIPアドレスに関してベアラから有効なSETIDが戻された場合は、SLPは、戻されたSETIDが正確なSETIDと内部で関連付けられていることを検査するステップ3参照。この検査が不合格である場合は、SLPは、該当するメッセージを用いてSUPLセッションを終了する。そうでない場合は、SETは真正であるとみなされ、SLPはSUPLセッションを継続する。2.有効なSETIDを見つけることができない場合は、SLPは、該当するSUPL誤りメッセージを用いてSUPLセッションを終了しなければならない。b.IPアドレスを要求するi.SLPが、このSETIDと関連付けられたSETによって使用中のソースIPアドレスを見つけ出すために根本のベアラネットワークに問い合わせるステップ3参照。1.ベアラネットワークがIPアドレスを戻した場合は、SLPは、このIPアドレスが最初のSUPLメッセージのソースIPアドレスに対応するかどうかを検査する。この検査が不合格である場合は、SLPは、該当するSUPLメッセージを用いてSUPLセッションを終了する。そうでない場合は、SETは真正であるとみなされ、SLPはSUPLセッションを継続する。2.IPアドレスを見つけることができない場合は、SLPは、該当するSUPL誤りメッセージを用いてSUPLセッションを終了しなければならない。注:ベアラネットワークは、SETID/IPアドレスのバインディングを得るためにステップ4における2つのタイプの問い合わせIPアドレスを要求する又はSETIDを要求するのうちの1つのみをサポートすることができる。SLPは、ベアラネットワークによってサポートされる方法を順守する責任を有する。SETによって開始されるシナリオ:SETがSUPLセッションを開始することを希望する場合は、第6.1.1.4節において説明されるように、既存の、オープンな相互に認証されたTLSセッションが使用されるべきであるか、又は前回の再開可能なTLSセッションを再開させることができる。オープンなTLSセッションがないか又はSET又はSLPがセッションを再開させないことを選択した場合は、SET及びSLPは、新しいTLSセッションを要求し、SET及びSLPは、認証方法を交渉するために第6.1.3節で説明される該当するステップを実施する。次のステップは、SETによって開始されるシナリオにおいてSETを認証するために代替クライアント認証メカニズムが適用されるときにSLPによって使用される:1.SETが、SLPとのTLS1.1セッションを確立する。SETは、SLPによって提示されたTLSサーバ証明書がSETにおいて設定されたSLPのFQDNにバインドされていることを検査しなければならない。2.最初のSUPLメッセージ例えば、SUPLSTART、SUPLTRIGGEREDSTARTに応答する前に、SLPは、SETのSETIDを検証しなければならない。これを達成する方法は次の2つである。a.SETIDを要求する。i.SLPが、SETによって使用されるソースIPアドレスを用いて現在のSETIDを見つけ出すために根本のベアラネットワークに問い合わせる。1.SETによって送信された最初のSUPLメッセージのソースIPアドレスに関してベアラから有効なSETIDが戻された場合は、SLPは、戻されたSETIDがSETによって提供されたものと同じであるかどうかを検査する。この検査が不合格である場合は、SLPは、該当するメッセージを用いてSUPLセッションを終了する。そうでない場合は、SETは真正であるとみなされ、SLPはSUPLセッションを継続する。2.有効なSETIDを見つけることができない場合は、SLPは、該当するSUPL誤りメッセージを用いてSUPLセッションを終了しなければならない。b.IPアドレスを要求するi.SLPが、このSETIDと関連付けられたSETによって使用中のソースIPアドレスを見つけ出すために根本のベアラネットワークに問い合わせる。1.ベアラネットワークがIPアドレスを戻した場合は、SLPは、このIPアドレスが最初のSUPLメッセージのソースIPアドレスに対応するかどうかを検査する。この検査が不合格である場合は、SLPは、該当するメッセージを用いてSUPLセッションを終了する。そうでない場合は、SETは真正であるとみなされ、SLPはSUPLセッションを継続する。2.IPアドレスを見つけることができない場合は、SLPは、該当するSUPL誤りメッセージを用いてSUPLセッションを終了しなければならない。注:SLPによって開始されるシナリオ及びSETによって開始されるシナリオの両方において、SLPは、SETIDを現在使用中のソースIPアドレスにバインドさせるためにベアラネットワークに該当する問い合わせを送信することによってSETを再認証することができる。これが有用であることが可能な様々な状況が存在し、例えば、ASETのIPアドレスがTLSセッション中に変わった場合は、SLPは、SETIDが新しいIPアドレスと関連付けられていることを確認するためにベアラネットワークに該当する問い合わせを送信することができる、BTLSセッションを再開するときには、SLPは、第6.1.1.4節において説明されるように前回のTLSセッションを再使用してそれによって計算を節約することができ、SETを認証するために単にベアラネットワークに該当する問い合わせを送信するだけであることができる。この方法でSETを再認証することは、SET自体との対話は含まないことに注目すること。6.2E-SLPに適用可能な認証メカニズム6.2.1緊急サービス規制当局に関してSUPL3.0緊急SUPLセッションは、SUPLを用いてネットワークによって開始させること又はSETによって開始させることができる。所管の緊急サービス規制当局は、これらの緊急セッションのためのサポートを要求する:所管の緊急サービス規制当局は、ネットワークによって開始されるセッション及びSETによって開始されるセッションのいずれに関してもサポートを要求することはできない;所管の緊急サービス規制当局は、ネットワークによって開始されるセッションのみを要求することができる;所管の緊急サービス規制当局は、SETによって開始されるセッションのみを要求することができる;所管の緊急サービス規制当局は、ネットワークによって開始されるセッション及びSETによって開始されるセッションの両方に関するサポートを要求することができる。6.2.2緊急セッション中のSUPLリソースの優先順位設定SETでの緊急SUPLセッションの継続期間中には、SETにおけるすべてのSUPLリソースがその緊急セッションのために利用可能でなければならない。従って、SETが緊急SUPLセッションを開始するときには、非緊急セッションに関連するあらゆるSUPL通信をSETによって直ちに終了させなければならない。この時点で非緊急SUPLINITメッセージをSETによって処理中例えば、MACを検証させる又はユーザの許可を得るである場合は、それらのプロセスは打ち切ることができ、SUPLINITメッセージを廃棄することができる。SETが緊急SUPLセッション中に非緊急SUPLINITメッセージを受信した場合は、これらのSUPLINITメッセージは廃棄することができる。6.2.3E-SLPFQDNネットワークによって開始される緊急SUPLセッションでは、E-SLPのFQDNは次の通りであることができる:1.SUPLINITにおいてE-SLPアドレスとしてSETに提供されたFQDN。E-SLPFQDNは、フォーマットe-slp.xxx.xxx.xxx.xxx.xxxを有することができ、ここで、xxxは、あらゆる有効なストリングであることができる。2.SUPLINITにおいてFQDNが提供されない場合は、プロビジョニングされたH-SLPアドレスを使用することができる。3.上記の1又は2に従ってFQDNを入手可能でない場合は、FQDNは、以下の3つの代替のうちの1つをデフォルトとすることができる:-3GPPベアラネットワークに接続される場合FQDNが明示で提供されない場合e-slp.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org。この場合は、MCC及びMNCは、サービスを提供する3GPPネットワークに対応する。-3GPP2ベアラネットワークに接続される場合FQDNが明示で提供されない場合e-slp.mnc<MNC>.mcc<MCC>.pub.3gpp2network.org。この場合は、MCC及びMNCは、サービスを提供する3GPP2ネットワークに対応する。-WiMAXベアラネットワークに接続される場合e-slp.operator.com。ここで、operator.comは、H-SLPオペレータのFQDNである。SETによって開始される緊急SUPLセッションでは、E-SLPのFQDNは、次の優先順であることができる。1.該当する場合所管の緊急サービス規制当局によって要求されたFQDN。2.ローカルアクセスネットワークによって又はH-SLPによって検証されたその他の手段によって提供されたFQDN。3.H-SLPによって提供されたFQDN。6.2.4.緊急SUPLINITメッセージの処理SUPLINITメッセージのSETに基づく完全性検証及びメッセージ源認証はE-SLPによって使用されない。従って、緊急SUPLINITにおけるMACフィールドは埋めてはならない。緊急呼中には、SETは、緊急SUPLINITメッセージのエンド-ツーエンド保護を適用することができない。E-SLPホワイトリストwhitelistの使用によって何らかの保護が提供される。E-SLPホワイトリストは、SETの現在の位置推定値例えば、CellD及び/又はNetworkIDに基づく。E-SLPホワイトリストは、SETが受信された緊急SUPLINITメッセージを処理すべき順序を決定するためにSETによって使用される。すなわち、E-SLPホワイトリストは、緊急SUPLINITメッセージを廃棄するためには使用することができない。6.2.4.1E-SLPホワイトリストエンド-ツー-エンドでセキュリティが確保されていないチャネルで緊急SUPLINITメッセージが受信された場合は例えば、SMS又はOMAPush又はUDP/IP、緊急SUPLINITメッセージは偽物であるか又は変更されているおそれがある。本節の残りの部分では、SETが可能な限り速やかに真正のE-SLPサーバに確実に接触できるようにするためのセキュリティ対策について説明する。注:規制上の要件では、SETが緊急SUPLINITメッセージを受け入れて処理すべき条件を規定する。例えば、多くの事例では、規制上の要件は、SETが緊急呼に現在従事している場合に緊急SUPLINITメッセージを受け入れて処理することをSETに要求するだけである。従って、SETが緊急SUPLINITメッセージを受け入れて処理すべき条件は、本書の範囲外である。SETが緊急SUPLINITメッセージを受信したときには、SETは、最初に、SETが緊急SUPLINITメッセージを受け入れるべき条件が現在満たされていることを検証しなければならない。それらの条件が満たされていない場合は、SETは、SUPLINITメッセージを無視することができる。ここからの説明では、SETが緊急SUPLINITメッセージを受信したときにそれらの条件が満たされていたと仮定する。注:攻撃者は、SETが真正の緊急SUPLINITメッセージをまさに予想しているときに複数の偽の緊急メッセージをSETに送信する可能性がある。いずれの緊急SLPからの緊急SUPLINITメッセージを予想すべきであるをSETに対して事前に伝えることができないケースが存在することがある。この攻撃が動機となって次の手順が設けられている。受け入れ及び処理条件が満たされている期間中は、SETは、緊急SUPLINITメッセージがE-SLPに関する予想外のアドレスを記載している場合でも受信された緊急SUPLINITメッセージを削除してはならない。条件がもはや満たされていないとSETが決定した時点で例えば、正確なE-SLPに接触されているか又は緊急呼後に十分な時間が経過している時点で、SETは、あらゆる受信された緊急SUPLINITメッセージを暗黙に廃棄しなければならない。受け入れ及び処理条件が依然として満たされている間にSETが偽の緊急SUPLINITメッセージを受信し、受け入れ及び処理する場合は、SETは、緊急SUPLINITメッセージ内で示されているE-SLPに接触するのを試みるまでは緊急SUPLINITメッセージが偽物であるという表示を受信できないことがある。この表示は、E-SLPがSUPLセッションを拒否したときに発生する。このプロセスは即時的ではなく、このため、SETが2つ以上の緊急SUPLINITメッセージを受信した場合は緊急SUPLINITメッセージを待ち行列に入れることが必要な場合がある。E-SLPホワイトリストは、SETが緊急SUPLINITメッセージを受信するのを予想することが可能なE-SLPFQDNのリストを含む。SETは、ホワイトリスト上に存在するE-SLPFQDNを含む緊急SUPLINITメッセージが、ホワイトリスト上に存在しないE-SLPFQDNを含む緊急SUPLINITメッセージの前に確実に処理されるようにするためにE-SLPホワイトリストを使用する。例:ホワイトリスト上のE-SLPFQDNを含む緊急SUPLINITメッセージは、ホワイトリスト上に存在しないE-SLPFQDNを含む緊急SUPLINITメッセージの前に確実に処理されるようにするために緊急SUPLINIT待ち行列において前方に進められる。E-SLPホワイトリストに記載されているかどうかは、緊急SUPLINIT待ち行列の順序を設定するための第1の判定基準である。第2の判定基準は、到着時間であり、先入れ先出し方式を使用する:SETがSETの現在位置に関する現在のE-SLPホワイトリストを有する場合は、SETは、待ち行列の順序を設定するために両方の判定基準を使用する。SETがSETの現在位置に関する現在のE-SLPホワイトリストを有しない場合は、SETは、待ち行列の順序を設定するために先入れ先出し方式を使用する。6.2.4.3緊急SUPLINITメッセージに関する手順エンドツーエンドでセキュリティが確保されているチャネルで緊急SUPLINITが受信された場合は例えば、セキュアなSIPPush、緊急SUPLINITメッセージは、直ちに処理することができる。この場合は、本小節の残りの考慮事項は無視される。エンドツーエンドでセキュリティが確保されていないチャネルで緊急SUPLINITメッセージが受信された場合は例えば、SMS又はOMAPush又はUPD/IP、そのメッセージは、第6.2.4.1節に従って待ち行列に入れられる。SETは、待ち行列内のメッセージ内を進行し、応答するためにE-SLPに接続するのを試みる前に該当する検証及び通知を適用する。SETは、SUPLINITメッセージに応答して、関連付けられたE-SLP第6.2.3節参照とセキュアなTLSセッション第6.2.5節参照を確立することができ、次のうちの1つが生じる。◆SETを認証後に第6.2.5節参照、E-SLPがSETを未終了状態のSUPLセッションと関連付けることができない場合は、E-SLPは、そのセッションを終了させることができる。TLSハンドシェイクがまだ完了していない場合は、E-SLPは、不必要な計算を節約するために、TLS誤りメッセージを用いてセッションを終了させるべきである。TLSハンドシェイクが完了している場合は、E-SLPは、SUPL誤りメッセージを用いてセッションを終了させ、SETに権限が付与されていないことを示すことができる。SETは、いずれの形式の誤りメッセージも、SUPLINITメッセージが不正なものであることを示すと解釈することができる。次に、SETは、待ち行列内の優先順位に従って次のSUPLINITメッセージに進んだ。◆SETを認証後に第6.2.5節参照、E-SLPがSETを未終了状態のSUPLセッションと関連付けることができる場合は、SET及びE-SLPは、通常通り継続する。SETは、真正のメッセージが見つかるまで緊急SUPLINITメッセージに応答し続ける。SETは、正しいE-SLPがいったん識別された時点であらゆる新しい又は待ち行列内のSUPLINITメッセージを廃棄することができる。正しいE-SLPからの新しい又は待ち行列内のSUPLINITメッセージはまだ処理することができる。次の2つの注記は、規制当局が考慮することを希望する提案である。注:正しいE-SLPがいったん識別された時点で、SETは、SUPLセッションが成功裏に完了するまでこの正しいE-SLPのFQDNを必ず覚えているべきである。E-SLPとのTLSセッションの終了が早すぎる場合例えば、データの接続性が失われた場合は、SETは、SUPLセッションが成功裏の完了まで継続することができるようにTLSセッションが再確立されるまでE-SLPとのTLSセッションを再確立するのを試み続けるべきである。幾つかの状況においては、SETがTLSセッションを数回再確立することが考えられる。SETがTLSセッションを再確立することに成功していない場合は、SETは、それにもかかわらず試み続けるべきである。これは緊急的な状況であるため、成功することの利益の方がバッテリ切れのコストよりも重要である。注:認証後であるがSUPLセッションの成功裏の完了前にE-SLPがSETとの接触を絶った場合は、E-SLPは、SETが接触を再確立してSUPLセッションを完了させることができることに望みをかけてSUPLセッションをオープン状態にすべきである。6.2.5緊急セッションのための認証注:E-SLPによってサポートすることができる相互認証方法が第6.1.1.3節に示されている。SET及びE-SLPは、第6.1.3節において規定されるように、TLSハンドシェイク中に相互認証方法に関して交渉する。緊急セッションに関する優先順位は次の通りである。GBA又はSEK方法:第1位DCert方法:第2位ACA方法:第3位SLP専用方法:最下位。SLP専用方法は最後の手段であるとみるべきである。すべてのこれらのケースに関するE-SLPのFQDNが第6.2.3節で説明されている。GBAに基づく方法3GPP/3GPP2SETのみ:SET及びE-SLPは、第6.1.3節において説明されるようにGBAを用いてPSK-TLSを行うことができ、E-SLPがNAFとして行動する。特定のSETに関してE-SLPによって入手されたKsNAFは、ホームネットワークオペレータによって設定された寿命の間SETアイデンティティ例えば、IMSI、MSISDNと関連付けて保持することができる。SEKに基づく方法WiMAXSETのみ:SET及びE-SLPは、第6.1.3節において説明されるようにSEKを用いるPSK-TLSを用いて相互認証を行うことができ、E-SLPはH-SLPと同様に行動する。E-SLPのFQDNは第6.2.3節で説明されている。特定のSETに関してE-SLPによって入手されたSEKは、ホームネットワークオペレータによって設定された寿命の間SETアイデンティティ例えば、WiMAXユーザIDと関連付けて保持することができる。DCert方法全SET:SET及びE-SLPは、第6.1.2.2.1節において説明されるようにDCert方法を用いた相互認証を行うことができる。SETは、SETに含まれるE-SLPのルート証明書及び第6.2.3節において定義されるE-SLPのFQDNを用いてE-SLPを認証することができる。ACAに基づく方法3GPP/3GPP2SET対応するベアラネットワーク上にある間のみ:PSK-TLSを用いるGBA及びDCert方法の両方がE-SLPにおいてサポートされていないSUPL3.0実装に関して、第6.1.4節において定義される代替クライアント認証メカニズムをサポートすることができ、次の相違点が存在する。E-SLPは、SETによって用いられるIPアドレスを、サービングネットワークによって-例えば、3GPPネットワークにおける、又は3GPP2ネットワークにおけるLRF又はE-CSCFによって、E-SLPに提供されたSETのためのIPアドレスとバインドさせることによってSETを認証することができる。ネットワークによって開始されるセッション:SETIPアドレスは、あらゆる緊急VoIP呼を開始するために使用され、及び、SUPLが呼び出される前にサービングネットワークによって検証することができるため、それは、E-SLPによって信頼できるとみなすことができる。回線モードで開始された緊急呼の場合は、SETIPアドレスはサービングネットワークに知られていないことがあり例えば、ホームネットワークによって割り当てることができる、その場合は、サービングネットワークによってE-SLPにIPアドレスを提供することができず及びのちにSETから受信されたときにIPアドレスを検証することができない。SETによって開始されるセッション:ACA方法を使用するために、サービングベアラネットワークは、ベアラレベルでのIPアドレスのスプーフィングを防止しなければならない。ACA方法は、SETがベアラネットワークにおいて認証されたとして登録されているどうかにかかわらず適用することができる。これは、SET内に起動されたSIM/USIM/UICC/RUIMが存在しない場合をサポートする。SLP専用方法全SET:その他のいずれの認証方法も使用できない場合は、SETは、SLP専用方法を用いてE-SLPへのセキュアなIPコネクションを確立することができる。SETは、SETに含まれるE-SLPのルート証明書及び第6.2.3節において定義されるE-SLPのFQDNを用いてE-SLPを認証することができる。相互認証を行う能力は、セッションがSETによって開始されるか又はネットワークによって開始されるかに依存する。ネットワークによって開始されるセッション:SUPLセッションがネットワークによって開始される場合は、E-SLPは、例えば第6.2.6節において説明されるようにセッションID及びSUPLINITの受信されたハッシュに基づいてSETの弱い認証をすることができる。SETによって開始されるセッション:SUPLセッションがSETによって開始される場合SLP専用方法は、SETがベアラネットワークにおいて認証されたとして登録されているどうかにかかわらず適用できることが注目されるべきである。これは、SET内に起動されたSIM/USIM/UICC/RUIMが存在しない場合をサポートする。6.2.6緊急SUPLセッションに関するSUPLINITの完全性保護E-SLPが第6.2.5節において説明されるようにSETを認証することができ、及び、E-SLPがSETを未終了状態のSUPLセッションと関連付けることができる場合は、E-SLPは、SUPLINITメッセージが変更されたかどうかを検査する。SUPLINITメッセージが変更されたことをE-SLPが検出した場合例えば、プロキシモードが指示されたときにSUPLAUTHREQメッセージが受信された場合、又はSLPセッションIDが誤っている場合又はVERが第6.3.1節において説明される検証に失敗した場合は、E-SLPは、SETに正しいパラメータが提供されるようにするためにTLSセッションを通じてSETにSUPLINITを送信しなければならない。応答して、SETは、最初に受信されたSUPLINITを用いて開始されたSUPLセッションを廃棄し、SETは、TLSセッションを通じて受信されたSUPLINITを用いて新しいSUPLセッションを開始することができる。次に、SETは、直ちにそのSUPLINITメッセージを処理することができすなわち、SETは、E-SLPホワイトリストを用いて優先度を評価しない、通知及び検証のための該当する行動を行い、ユーザがセッションを拒否しないことを条件として、SETは、セッションを継続するためにE-SLPに該当するメッセージSUPLPOSINIT又はSUPLAUTHREQを送信する。SUPLINITを再送信する能力は、緊急セッションのみを対象とすることが意図される。非緊急セッションでは、SUPLINITの変更が検出された場合は、SLPは、非緊急呼の流れにおいて規定されるように、SUPLENDを用いてSUPLセッションを終了させることができる。6.3SUPLINITメッセージの処理ネットワークによって開始されるセッションはSUPLINITメッセージによってトリガされるため、なりすまし及び幾つの場合はリプレイ攻撃からSUPLINITメッセージを保護することが不可欠である。SUPL3.0は、SUPLINITメッセージのための次の保護を規定している。ネットワークに基づくセキュリティ。SLPは、SUPLINITメッセージの認証第6.3.1節及びリプレイ保護第6.3.2節を確認するための検査を行うことができる。この検証は、SETがSUPLINITメッセージの内容を処理し、SUPLセッションを実施するためにSLPとセキュアなTLSセッションを確立した後に生じる。エンドツーエンドセキュリティ:SLPは、暗号化、完全性保護及びリプレイ保護の組み合わせをSUPLINITメッセージに適用することができ、SETは、復号、完全性検証及びリプレイ検出の対応する組み合わせを適用する。SETは、SUPLINITメッセージの内容を処理する前にこれらのセキュリティ措置を適用する。このセキュリティは、非緊急SUPLINITメッセージのみに適用される。ネットワークに基づくセキュリティは強制的であり、エンドツーエンドセキュリティは任意選択である。6.3.1SUPLINITメッセージのネットワークに基づく認証SLPは、SUPLINITメッセージの完全性のネットワーク検証を常時行う。SUPLINITメッセージに応答して送信される最初のメッセージすなわち、SUPLPOSINIT、SUPLAUTHREQ又はSUPLTRIGGEREDSTARTメッセージは、検証フィールドVERを含まなければならない。SLPがSUPLINITメッセージに応答して最初のメッセージを受信したときには、SLPは、送信されたSUPLINITメッセージに関して計算された対応する値に照らして受信されたVERフィールドを検査する。この検証が不合格の場合は、SLPは、状態コード‘authSuplinitFailure’が入ったSUPLENDメッセージを用いてセッションを終了させなければならない。検証フィールドのための値は、次のように計算しなければならない:VER=HSLPXORopad,HSLPXORipad,SUPLINITここで、SLPは、SLPアドレスのFQDNである。SHA-256は、opad及びipadを有するハッシュH関数として使用しなければならない。SHA-256HASH関数の出力は、64ビットで打ち切らなければならない。すなわち、同関数は、HMAC-SHA256-64として実装しなければならない。SLPアドレスは秘密とはみなされないことに注目すること。ここで使用されるHMAC構造は、どのようなデータ認証も提供せず、HASH関数の代替として使用されるにすぎない。6.3.2SUPLINITメッセージのネットワークに基づくリプレイ保護ネットワークによって開始される事例に関しては、リプレイ攻撃に対する保護をSLPによって提供しなければならない。SLPは、前回の、期限切れでないSUPLINITメッセージがSUPLメッセージ内部で受信されたSLPセッションIdに対応するそれとともに送信されていないかぎり認証されたSETからのどのようなSUPLメッセージも受け入れられないようにしなければならない。SLPは、SUPLメッセージのタイプ例えば、SUPLPOSINIT、SUPLAUTHREQ、SUPLTRIGGEREDSTARTがSUPLINITメッセージで送信されたパラメータと一致することも確認しなければならない。実装では、SLPセッションIdが認証されているSETユーザID例えば、MSISDN、WiMAXユーザID又はMDNと正確に関連付けられるようにしなければならない。SETユーザ認証が、本書で説明される代替クライアント認証方法を用いて行われる場合は、SETからの応答SUPLPOSINIT、SUPLAUTHREQ又はSUPLTRIGGEREDSTARTのソースIPアドレスとSETユーザのMSISDN又はMDNとの間のマッピングが既に確立されており、このMSISDN又はMDNを認証されたMSISDN又はMDNとして使用しなければならない。誤りのあるSUPLPOSINIT、SUPLAUTHREQ又はSUPLTRIGGEREDSTARTの廃棄は、SETにとっての課金可能なchargeableイベントを生成させてはならない。非プロキシネットワークによって開始される事例に関しては、SLPは、SUPL測位の成功裏の完了に関する確認をSPCから受信後のみに課金可能なイベントを生成しなければならない。6.3.3SUPLINITメッセージのエンドツーエンド保護注:SUPLINITメッセージのエンドツーエンド保護は、非緊急SUPLINITメッセージのみに対して適用される。本明細書では、エンドツーエンドのSUPLINIT保護のために3つの選択肢が提供されている。すなわち、Nullヌル、モードA及びモードBである。NullSUPLINIT保護は、エンドツーエンドの完全性保護、エンドツーエンドのリプレイ保護及び秘密性保護のいずれも提供しない。NullSUPLINIT保護のための手順は、第6.3.4節で説明される。モードASUPLINIT保護は、デフォルトのアルゴリズムを用いてのエンドツーエンドの完全性保護及びエンドツーエンドのリプレイ保護を提供する。モードASUPLINIT保護は、セキュリティが確保されたULPセッション中にSLPによってSETに送信された共有鍵を使用する。モードASUPLINIT保護のための手順は、第6.3.5節で説明される。モードBSUPLINIT保護は、デフォルトのアルゴリズムを用いてのエンドツーエンドの完全性保護及びエンドツーエンドのリプレイ保護を提供する。モードBSUPLINIT保護は、該当するPSKに基づく方法GBA方法又はSEK方法を用いて導き出された共有鍵を使用する。モードBSUPLINIT保護のための手順は、第6.3.6節で説明される。保護レベルに関する優先順位は次の通りである:◆NullSUPLINIT保護が最も低い優先順位を有する。◆モードASUPLINIT保護は、NullSUPLINIT保護よりも高い優先順位を有する。◆モードBSUPLINIT保護は、モードASUPLINIT保護よりも高い優先順位を有する。SUPLINITメッセージ内では、下表内のProtectionLevel保護レベルパラメータが現在の保護レベルに従って割り当てられる。注:本明細書は、将来の改訂版において加えられることになるより高度な保護レベルを考慮して書かれている。この高度な保護は、SUPLINITのセキュリティを確保するためのその他の方法についての交渉を可能にすることができる例えば、暗号化を可能にすること及びアルゴリズムの交渉を可能にすること。SETがSUPLINITメッセージを構文解析することができるかどうかを決定する際の助けとなるProtectionLevelパラメータが含まれている。保護レベルパラメータは、拡張性のために要求されることがある。SUPLINITメッセージは、セキュリティパラメータを含めるためのProtectorプロテクタパラメータを存在させることができる。Protectorパラメータの存在は下表において規定される。SUPLINITProtectorLevelパラメータ値及びSUPLINIT内でのProtectorパラメータの存在ACAに基づく方法をサポートするSET又はD-SLP又はH-SLPは、NullSUPLINIT保護をサポートしなければならない。全SETが、モードASUPLINIT保護手順をサポートしなければならない。D-SLP又はH-SLPは、モードASUPLINIT保護手順をサポートすることができる。PSKに基づく方法をサポートするSET又はD-SLP又はH-SLPは、モードBSUPLINIT保護手順をサポートしなければならない。E-SLPエンティティは、現在定義されているSUPLINIT保護には関わっていない。6.3.3.1SUPLINIT保護レベルの交渉次のプロセスは、D-SLP又はH-SLPであるSLPのみに適用され、それらのプロセスは、E-SLPには適用されない。SUPLINIT保護レベルがどのようにして交渉されるかに関する情報を提供するための説明を以下に示した:1.SETは、有効なSUPLINITROOTKEYが存在しないときには例えば、パワーアップ時又はSUPLINITROOTKEYの寿命が切れているときNullSUPLINIT保護を適用しなければならない。初期の保護レベルは、常にNullSUPLINITである。この状態で、SETは、すべてのSUPLINITメッセージを処理する、すなわち、いずれのメッセージも暗黙に廃棄されない。SUPLINITメッセージが不具合状態で構文解析される場合は、SETは、誤りメッセージをSLPに送信する。2.SETが、特定のSLPに関してモードA又はモードBSUPLINIT保護を用いて既に交渉された有効なSUPLINITROOTKEY及び有効なリプレイカウンタを有する場合は、SETは、交渉されたモードモードA又はモードBを用いてそのSLPからのすべてのSUPLINITメッセージを処理する。3.SETがSLPへの相互に認証されたセキュアなコネクションを確立するときに、a.相互認証のためにPSKに基づく方法GBA又はSEKが使用された場合は、モードBSUPLINIT保護が適用され、PSK-TLSのハンドシェイクにおいてやり取りされたB-TIDは、Ks3GPP及び3GPP2配備ではKsNAFとして使用される又は3GPP及び3GPP2配備においてKsNAFとして使用されるSUPLINITROOTKEYを導き出すために使用することができるSEKに対応する。このKsNAK又はSEK及び関連付けられたB-TIDは、以下のいずれかまでモードBSUPLINIT保護で使用される。i.鍵が期限切れになるまで。この場合は、SET及びSLPはNullSUPLINIT保護に戻るii.SET及びSLPが非緊急セッションでACA方法を使用するまで。この場合は、SET及びSLPは、以下のステップ3のbにおいて説明されるようにモードA又はNullSUPLINIT保護に戻る、又は、iii.SET及びH-SLPが、新しいB-TIDを用いてTLSを確立するためにGBAの又はSEKのブートストラッピング再交渉方法を使用するまで。この場合は、B-TID及び対応するKsNAF又はSEKがモードBSUPLINIT保護のために使用される。b.そうでない場合は、SET及びSLPは、DCert方法又はACA方法を用いてセキュアなコネクションを確立した。i.SETが有効なSUPLINITROOTKEYを有さない場合は、SETは、最初のULPメッセージでSUPLINITKeyRequestパラメータをSLPに送信する。1.SLPがモードASUPLINIT保護をサポートする場合は、SLPは、SETに対する最初のULP応答においてはModeAKeyIdentifier、TemporaryModeAKeyIdentifier、SUPLINITROOTKEY及びBasicReplayCounterパラメータを送信することによって応答する。SETがこれらのパラメータを受信したときに、これは、モードASUPLINIT保護が適用されることをSETに示す。注:SUPLINITROOTKEYを更新する方針は、SLPオペレータの判断である。2.SLPが、モードASUPLINIT保護をサポートしない又はこの特定の時点でモードASUPLINIT保護をサポートしない場合は、SLPは、NullSUPLINIT保護が適用されることを示す表示をULPメッセージでSETに送信する。ii.SETが有効なSUPLINITROOTKEYを有するが、有効なTemporaryModeAKeyIdentifierを有さないか又はリプレイ保護に関する同期化を失っている場合は、SETは、最初のULPメッセージでSUPLINITResynchRequestパラメータをSLPに送信する。1.SLPがモードASUPLINIT保護をサポートする場合は、SLPは、SETへの最初の応答において第6.3.6.1.1節で規定される手順を用いて新しいTemporaryModeAKeyIdentifierで応答する。SETがこの応答を受信したときには、これは、モードASUPLINIT保護が適用されることをSETに示す。2.SLPがモードASUPLINIT保護をサポートしない又はこの特定の時点でモードASUPLINIT保護をサポートすることを希望しない場合は、SLPは、NullSUPLINIT保護が適用されることを示す表示をULPメッセージでSETに送信する。これは、SETがH-SLPへの新しいTLSコネクションを設定するごとに保護レベルが再交渉されることを意味することに注目すること。6.3.3.2H-SLPの観点からの交渉SETとの直近のIPセッションがGBA又はSEK方法を用いて認証され、及びH-SLPがSETに関する現在のB-TID及び関連付けられた鍵を有する場合は、◆B-TIDがGBAを用いて入手された鍵に関するものである場合は、H-SLPは、SUPLINITROOTKEYを、直近のB-TIDに対応し、次のように生成されるKsint/extNAFとして割り当てる。○FQDNは、H-SLPFQDNであることができる。○SUPLINIT保護のために使用することができるGBAUaセキュリティプロトコル識別子は、OMNAレジストリで定義される。◆B-TIDがSEK方法を用いて導き出された鍵に関するものである場合は、SUPLINITROOTKEYは、第6.1.2.1.2節で定義されるSEKである。◆その他のSUPLINIT保護は交渉されていないと仮定すると、H-SLPは、そのSETのためにモードBSUPLINIT保護レベルを割り当てる。そうでない場合は、H-SLPがSETに関する有効なModeAKeyIdentifier及び関連付けられた鍵を有する場合は、H-SLPは、そのSETのためにモードASUPLINIT保護レベルを割り当てる。その他の保護レベルが割り当てられていない場合は、H-SLPは、そのSETに関してNullSUPLINIT保護レベルを割り当てる。H-SLPは、現在割り当てられているレベルのSUPLINIT保護に対応する引き渡し前にSUPLINITメッセージを処理するための手順を適用する。これは、SUPLINITメッセージ内のProtectionLevelパラメータのための該当値を割り当てることを含む。6.3.3.3SETの観点からの交渉H-SLPとの直近のIPセッションがGBA又はSEK方法を用いて認証され、及びSETが現在のB-TID及びそのIPセッションのために用いられる関連付けられた鍵を有する場合は、◆B-TIDがGBAを用いて入手された鍵に関するものである場合は、SETは、SUPLINITROOTKEYを、直近のB-TIDに対応し、次のように生成されるKsint/extNAFとして割り当てる。○FQDNは、H-SLPFQDNであることができる。○SUPLINIT保護のために使用することができるGBAUaセキュリティプロトコル識別子は、OMNAレジストリで定義される。◆B-TIDがSEK方法を用いて導き出された鍵に関するものである場合は、SUPLINITROOTKEYは、第6.1.2.1.2節で定義されるSEKである。◆その他のSUPLINIT保護は交渉されていないと仮定すると、SETは、モードBSUPLINIT保護レベルを割り当てる。そうでない場合は、SETがH-SLPに関する有効なModeAKeyIdentifier、関連付けられた鍵及びModeAReplayCounterを有する場合は、H-SLPは、SETは、そのSETのためにモードASUPLINIT保護レベルを割り当てる。その他の保護レベルが割り当てられていない場合は、SETは、NullSUPLINIT保護レベルを割り当てる。SETは、現在割り当てられているレベルのSUPLINIT保護に対応する受信されたSUPLINITメッセージを処理するための手順を適用する。6.3.3.4例外手順SET内部のSUPLINIT保護パラメータが壊れているとSETが決定した場合は、SETは、H-SLPとのTLSセッションを確立しなければならない。GBA認証が使用される場合は、SETは、新しい鍵を確立するためのGBAブートストラッピングを開始しなければならない。SEK方法を使用するSETに関しては、SETは、新しい鍵をイネーブルにするためSEKブートストラッピングを開始しなければならない。そうでない場合は、SETは、最初のセキュリティが確保されたULPメッセージでSUPLINITKeyRequestを送信し、第6.3.3.1節のステップ3.のbの手順に従う。SLPがセキュリティコンテキストを失った場合は例えば、大量のデータ損失、SLPは、測位活動を開始する手段を有さないことになる。コンテキストは、KsNAF又はSEKが期限切れになるか又はSETがSLPに接続するときに再確立される。このブロックアウトウィンドウblockoutwindowを防止するために、SLPは、該シナリオから回復するためにすべてのSUPLINITセキュリティコンテキスト情報が十分な冗長度を持って格納されるようにすべきである。6.3.4Nullレベルの保護が割り当てられるときの仕様注:NullSUPLINIT保護のためのSUPLINITプロテクタは存在しない。6.3.4.1H-SLP手順NullSUPLINIT保護の専用であるSLPのためのセキュリティ手順は存在しない。6.3.4.2SET手順NullSUPLINIT保護が割り当てられ、SETがSUPLINITメッセージを受信したときには、SETは、次の手順を適用する:◆ProtectionLevelパラメータが正しい場合は、SETは、メッセージを真正であるとみなし、セキュリティに関連する処理は要求されない。○SLP及びSETがより高い保護レベルをサポートすることができるが、パワーアップ中であるためSETがSLPにまだ接触していないと仮定すると、この場合は、SETは、NullSUPLINIT保護が割り当てられる。SETがSLPに接触するまでの期間において、SETは、正しいProtectionLevelパラメータを有するあらゆる受信されたSUPLINITメッセージを真正であるとみなす。受信されたSUPLINITメッセージに応答してであるかどうかにかかわらずSETがSLPに初めて接触した時点で、SET及びSLPは、より高い保護レベルに移行する。これらの2つのエンティティがより高い保護レベルに移行した時点で、SETは、真正でないSUPLINITメッセージを検出することができる。SETがパワーアップされるときとSETがSLPに最初に接触するときとの間には、SETが、あたかもSUPLINITメッセージが真正であるものとしてSETによって処理される非真正のSUPLINITメッセージを受信することが可能である。SETが非認証SUPLINITメッセージと関連付けられたSUPLセッションを進行させることを決定した場合は、SETは、SLPに接触してセキュアなTLSセッションを確立する。SUPLセッションは非真正のSUPLINITメッセージを用いて確立されたため、SLPはそれを許容しない。SET及びSLPがより高い保護レベルをサポートする場合は、これは同時に確立され、SETは、この時間後に非真正のSUPLメッセージを検出することができる。このことは、SET及びSLPがより高い保護レベルをサポートすることができる場合は、攻撃者が非真正のSUPLINITメッセージをSETに入手させる非常に小さい機会の窓が存在しており、SETは、多くとも1つの非真正のSUPLINITメッセージに関してSUPLセッションを進行させることを試みるにすぎないことを意味する。◆ProtectionLevelパラメータが正しくない場合すなわち、ProtectionLevelパラメータがNull以外の何かであった場合は、SETは、該当する誤りメッセージをSLPに送信する。○SLP及びSETでの保護レベルが同期化を失った場合は、この手順は、SET及びSLPが共通の保護レベルで再同期化するのを可能にする。6.3.5モードASUPLINIT保護レベルに関する仕様6.3.5.1モードASUPLINIT保護のための鍵識別子モードASUPLINIT保護は、SUPLINITメッセージとともに送信することができる2つの鍵識別子、すなわち、ModeAKeyIdentifier及びTemporaryModeAKeyIdentifier、を使用する。ModeAKeyIdentifierは、SUPLINITROOTKEYと関連付けられたグローバルで一意の、長期的な鍵識別子である。SLPは、SLPがSUPLINITROOTKEYのための新しい値をプロビジョニングするときのみに新しいModeAKeyIdentifierをSETに提供する。TemporaryModeAKeyIdentifierは、ModeAKeyIdentifierと関連付けられた短期のアイデンティティ仮名である。TemporaryModeAKeyIdentifierは、TemporaryModeAKeyIdentifierが有効である期間の間グローバルで一意であることができる。SET及びSLPは、第6.3.5.3節及び第6.3.5.4節において説明されるようにTemporaryModeAKeyIdentifierの値を同期化する。SLPは、典型的には、TemporaryModeAKeyIdentifierを基本的SUPLINITプロテクタ内のKeyIdentifierとして使用する。SETは、基本的SUPLINITプロテクタを検証するためにいずれのSUPLINITROOTKEYが使用されるべきかを決定するためにTemporaryModeAKeyIdentifierを使用する。ModeAKeyIdentifierは、典型的には、SUPLINITメッセージでは送信されず、その理由は、観察者が複数のSUPLINITメッセージを1つの共通のSETユーザと関連付けるのを可能にするためである。TemporaryModeAKeyIdentifierの目的は、脅威エージェントが複数のSUPLINITメッセージを1人のSETユーザと関連付けるためにModeAKeyIdentifierを使用するのを防止することである。SLP及びSETのみがTemporaryModeAKeyIdentifierをModeAKeyIdentifierと関連付けることができるようにすべきである。TemporaryModeAKeyIdentifierを変更する頻度は、主に、SETユーザの判断である。SLPは、SLP方針に基づいてTemporaryModeAKeyIdentifierのための新しい値を確立することを選択することができる。しかしながら、SLPがより長期のModeAKeyIdentifierを基本的SUPLINITプロテクタ内のKeyIdentifierとして使用することを希望する状況が存在する。例えば、SETが基本的SUPLINITプロテクタ内のTemporaryModeAKeyIdentifierを用いて複数のSUPLINIT/REINITメッセージに応答していないと仮定する。SLPは、SETがTemporaryModeAKeyIdentifierに関する同期化を失っていることを懸念するおそれがある。SET及びSLPは、長期的なModeAKeyIdentifierに関しての方が同期化状態を維持する可能性が高い。従って、SLPは、同期化を失うことがSETがSUPLINITメッセージを検証するのを妨げないようにするために基本的SUPLINITプロテクタ内のModeAKeyIdentifierを用いてSUPLINITメッセージを送信することができる。6.3.5.2モードASUPLINIT保護及び基本的SUPLINITプロテクタモードASUPLINIT保護は、基本的SUPLINITプロテクタ及び第6.3.7節において定義される関連付けられた手順を使用し、さらなる明確化のために以下を示した。◆KeyIdentifierType:ModeAKeyIdentifier又はTemporaryModeAKeyIdentifierのいずれかが使用されることを示す。◆KeyIdentifier:ModeAKeyIdentifierTypeに適宜対応するModeAKeyIdentifier又はTemporaryModeAKeyIdentifierのいずれかに対応する。◆BasicMACは、上記のKeyIdentifierと関連付けられたSUPLINITROOTKEYを用いて、SUPLINITIK=HMAC-SHA256-128SUPLINITROOTKEY,ModeAIKを用いて計算される。6.3.5.3H-SLP手順モードA専用H-SLP手順は、SETとSLPとの間で同期化を維持することに関するものである。SLPがセキュリティが確保されたセッションにおけるSETへの最初の応答メッセージでNewTemporaryModeAKeyIdentifierパラメータを送信し、新しいTemporaryModeAKeyIdentifierを後続させることによってTemporaryModeAKeyIdentifierのための新しい値が確立される。新しいTemporaryModeAKeyIdentifierを確立することは、その結果として、BasicLastReplayCounterが0x0000にリセットされ、SETがプレイされたSUPLINITメッセージに関する全情報を取り除く。SLPは、SUPLINITResynchRequest又はSLPの範囲外の内部判断のいずれかに応答して新しいTemporaryModeAKeyIdentifierを確立することができる。すなわち、SLPは、SETからの対応するSUPLINITResynchRequestが存在しないときでもTemporaryModeAKeyIdentifierを送信することができる。6.3.5.4SET手順モードA専用H-SLP手順は、SETとSLPとの間で同期化を維持することに関するものである。SETは、ULPセッションの最初のメッセージでSUPLINITResynchRequestを送信することによってTemporaryModeAKeyIdentifierのための新しい値を確立することをトリガすることができる。モードASUPLINIT保護がSETによって割り当てられた場合は、SETが所定のTemporaryModeAKeyIdentifierを有するSUPLINITメッセージを初めて処理する前に、SETは、BasicReplayCounterのためにそれの使用された値のキャッシュをクリアする。6.3.6モードBSUPLINIT保護レベルに関する仕様モードBSUPLINIT保護は、基本的SUPLINITプロテクタ及び第0節において定義される関連付けられた手順を使用し、さらなる明確化のために以下を示した。◆KeyIdentifierType:B-TID識別子のみがモードBSUPLINIT保護のためのサポートである。◆KeyIdentifier:現在のB-TIDに対応する。◆BasicMACパラメータは、SUPLINITIK=HMAC-SHA256-128SUPLINITROOTKEY,ModeAIKを用いて計算され、ここで、○GBAに基づく配備の場合は、SUPLINITROOTKEYは、直近のB-TIDに対応し、OMNAレジストリで定義されるSUPLINIT保護のためのGBAUaセキュリティプロトコル識別子を用いて生成されるKsint/extNAFである。○SEKに基づく配備の場合は、SUPLINITROOTKEYは、第6.1.2.1.2節で定義されるSEKMACである。6.3.6.1H-SLP手順モードB専用H-SLP手順は、SETとSLPとの間で同期化を維持することに関するものである。モードBSUPLINIT保護に関して、鍵が初めて使用されるときにSLP内のBasicReplayCounterがゼロにリセットされ、SETがプレイされたSUPLINITメッセージに関する全情報を取り除く。再同期化が要求されるとSLPが決定する起こりえない事象において、GBA方法をサポートする配備の場合は、SLPは、GBAB-TISを無効にすることによって再同期化をトリガする。そのSETが次にSLPに対して認証することを試みたときに、SLPは、TLS-PSKalertpskidentityunknownで応答する。これは、新しいGBA鍵を確立することをプロンプトする。SEK方法をサポートする配備の場合は、SLPは、SEKB-TISを無効にすることによって再同期化をトリガする。そのSETが次にSLPに対して認証することを試みたときに、SLPは、TLS-PSKalertpskidentityunknownで応答する。これは、第6.1.3.3節で説明されるように新しいSEKを確立することをプロンプトする。6.3.6.2SET手順モードB専用SET手順は、SETとSLPとの間で同期化を維持することに関するものである。モードBSUPLINIT保護がSETによって割り当てられた場合は、SETが所定のSUPLINITROOTKEYを有するSUPLINITメッセージを初めて処理する前に、SETは、BasicReplayCounterのためにそれの使用された値のキャッシュをクリアする。SETは、新しいGBAKs又は新しいSEKを適宜確立することによって再同期化をトリガすることができる。SLPは、SETとSLPとの間での次の成功裏の認証まで旧GBAKs又はSEKを使用し続ける。このため、SETは、その時まで旧GBAKs又はSEKを維持すべきである。6.3.7基本的SUPLINITプロテクタを使用するための仕様基本的SUPLINITプロテクタは、モードASUPLINIT保護及びモードBSUPLINIT保護の両方のために使用され、次のパラメータを含む:◆KeyIdentifierType:長さ=1オクテット◆KeyIdentifier:可変長。BasicMACを計算するために用いられる鍵に対応する。◆BasicReplayCounter:長さ=2オクテット◆BasicMAC:長さ=4オクテットBasicMACパラメータは、次のように生成される:◆BasicMAC=HMAC-SHA256-32SUPLINITBasicIK,SUPLINIT’、ここで、◆SUPLINITBasicIKは、モードASUPLINIT保護及びモードBSUPLINIT保護に関するそれぞれの第6.3.5節及び第6.3.6節により導き出される。◆SUPLINIT’は、SUPLINITメッセージに対応し、BasicMAC以外の全パラメータが割り当てられ、MACパラメータはすべてゼロに設定される。◆HMAC-SHA256-32及びHMAC-SHA256-128は、本書の範囲外の文書において規定されている。6.3.7.1H-SLP手順ModeALastReplayCounterの同期化のためのSLP手順が別の場所でモードA及びモードBSUPLINIT保護に関して規定される。モードA又はモードBSUPLINIT保護がSETに割り当てられた場合は、H-SLPは、SUPLINIメッセージを次のように構成する:1.SUPLINITプロテクタ外部のパラメータが別の場所で説明されるように割り当てられる。2.KeyIdentityTypeが、SLPがこのメッセージのために使用するKeyIdentityのタイプにより設定される。3.KeyIdentityが、SUPLINITROOTKEYと関連付けられたKeyIdentityに設定される。4.H-SLPが、このSET及び交渉されたSUPLINIT保護レベルと関連付けられたBasicLastReplayCounterValueの現在値を1だけ増加させ、その新しい値をBasicReplayCounterパラメータ内に挿入する。5.最後に、すべてのその他のパラメータが割り当てられた後に、BasicMACが上記のようにSUPLINIT及びSUPLINITROOTKEYから計算される。H-SLPには、モードA又はモードBSUPLINIT保護レベルが割り当てられる各SETのためのBasicLastReplayCounterパラメータの長さに等しい長さのBasicLastReplayCounterValueを格納するように要求することができる。SLP内のBasicLastReplayCounterValueが65535=216-1に近い場合は可能性が非常に小さい、SLPは、再同期化手順をトリガしなければならない第6.3.6.1節及び第6.3.7.1節を参照。6.3.7.2SET手順ModeALastReplayCounterの同期化のためのSET手順が別の場所でモードA及びモードBSUPLINIT保護に関して規定される。モードA又はモードBSUPLINIT保護が割り当てられた場合は、SETは、受信されたSUPLINITメッセージを次のように処理する:1.次のパラメータが該当する検証に失敗した場合はSETがSUPLINITメッセージを廃棄する:◆ProtectionLevel:交渉されたSUPLINIT保護レベルのための割り当てられた値でなければならない。◆KeyIdentityType:割り当てられたSUPLINIT保護レベルに関して有効でなければならない。◆KeyIdentity:交渉されたSUPLINIT保護レベルに関する現在のSUPLINITROOTKEYに対応しなければならない。◆BasicReplayCounter:SETは、メッセージのリプレイを検出するためにこの値を使用する。この技法は、各々の実装ごとであるが、SUPLINITメッセージが失われるか又はばらばらに引き渡される状況に対処することができるような強固さでなければならない。◆BasicMAC:上述されるようにSETがSUPLINIT及びSUPLINITROOTKEYから予想されるBasicMACを計算し、これを受信されたBasicMACと比較する:これらの値は等しくなければならない。2.前ステップにおいてSUPLINITが廃棄されなかった場合は、それは真正であるとみなされ、SETは、使用されるべきBasicReplayCounterValueを考慮する。BasicReplayCounterValueが65535=216-1に近い場合は可能性が非常に小さい、SETは、カウンタをリセットするためにSLPと新しいSUPLINITROOTKEYを確立しなければならない。6.4H-SLPアドレスをSETに提供する注:アクセスネットワークから独立したH-SLPのためにH-SLPアドレスをプロビジョニングすることは、FFSである。H-SLPアドレスは、UICC、SET内でH-SLPアドレスをプロビジョニングすることによってSETにとって入手可能になり、又は、デフォルトH-SLPが下記のように導き出される。このアドレスは、FQDNの形態でなければならず及びSETのホームネットワークによってセキュアな状態でプロビジョニングされるべきである。6.4.1.33GPP2SET3GPP2SETに関しては、H-SLPアドレスは、UMI又はR-UIMにおいてセキュアな状態でプロビジョニングされなければならない。6.4.2.33GPPSET3GPPSETは、FQDNの形態のH-SLPアドレスを、WAPPROVCONTにおいて規定されるAPPADDR/ADDR特性に基づくパラメータADDRとして読み取らなければならない。さらに、H-SLPアドレスは、3GPP準拠UICCUSIM/SIMに関するOMAスマートカードプロビジョニング仕様において定義されるブートストラップファイル内に又はSETの同等にセキュアなエリア内にセキュアな状態で格納しなければならない。SETは、H-SLPアドレスを読み取るためのOMAスマートカードプロビジョニングメカニズムをサポートしなければならない。H-SLPアドレスを格納するUSIM/SIMアプリケーション又はSET内のブートストラップファイルは、ユーザによって変更可能であってはならない。H-SLPがUICCUSIM/SIMにおいて設定されている場合は、SETは、最初に、UICCにおいてプロビジョニングされるH-SLPアドレスを読み取らなければならない。UICCにおいてプロビジョニングされるH-SLPアドレスが存在しない場合は、SETは、SETのセキュアなエリアからH-SLPアドレスを読み取ることができる。SET内でのH-SLPアドレスのプロビジョニング:H-SLPアドレスがSET内のセキュアな場所に格納されることになる場合は、それは、OMAデバイス管理V1.2又はそれ以降を用いてプロビジョニングしなければならない。OMADMを用いてH-SLPアドレスがプロビジョニングされる場合は、SETは、TLSハンドシェイク中にDMサーバによって提示されたサーバ側証明書に基づいてOMADMサーバを認証しなければならない。SETがH-SLPの格納をサポートする場合は、それは、第6.1.4節で説明される認証方式、すなわち、MSISDN/IPアドレスマッピング認証に基づく代替クライアント認証、に依存してはならず、SETは、第6.1.1節で説明されるPSL-TLS相互認証方法に依存しなければならない。H-SLPアドレスの自動設定:H-SLPアドレスがUICCUSIM/SIMのセキュアな格納エリア内又はSETのセキュアなエリア内で見つけることができない場合は、SETは、USIM/SIM内に格納されたIMSIに基づいてSET内でデフォルトH-SLPアドレスを設定しなければならない。H-SLPアドレスがUICCUSIM/SIMのセキュアな格納エリア内又はSETのセキュアなエリア内で見つけられているが、それを使用した結果、SUPLセッション中に認証失敗に終わった場合は、SETは、USIM/SIM内に格納されたIMSIに基づいてSET内でデフォルトH-SLPアドレスを設定しなければならない。デフォルトH-SLPアドレスを設定するためのメカニズムが以下に定義される。以下の例は、3GPPGBA仕様から流用したものであり、FQDNに基づくH-SLPアドレスが設定されるSUPL使用事例のために採用されていることに注目すること。このデフォルト設定メカニズムの実装は、3GPPGBA仕様の実装を要求しない。以下の例は、方法を例示することを目的として示されるにすぎず、GBAから独立して実装することができる。IMSIに基づくH-SLPの構成ステップ12又は3桁のMNCが使用されるかどうかに依存してIMSIの最初の5又は6桁を取りそれらをMCC及びMNCに分離する。MNCが2桁である場合は、始めにゼロを加えることができる。ステップ2ステップ1で導き出されたMCC及びMNCを用いてmnc<MNC>.mcc<MCC>.pub.3gppnetwork.orgドメイン名を生成し、ドメイン名の最初にラベルh-slp.を加える。例1:使用中のIMSIが234150999999999である場合は、ここで、MCC=234,MNC=15、MSIN=0999999999であり、H-SLPアドレスは、h-slp.mnc015.mcc234.pub.3gppnetwork.orgになる。新しいIMSIが電源投入中又は投入後にSETによって検出された場合は、すべての以前のH-SLP設定をSETから取り除かなければならない。より具体的には、SET内に格納されるあらゆるH-SLPを取り除かなければならない。IMSIが変更された場合は、SETは、最初に、UICCUSIM/SIMからH-SLPアドレスを読み取らなければならない。H-SLPアドレスがUICCUSIM/SIMに格納されていない場合は、SETは、H-SLPアドレスがSET内に格納されているかどうかを検査することができる。H-SLPアドレスがUICCでもSET内でも見つからない場合は、上述されるように新しいIMSIに基づいてSETによってデフォルトのH-SLPアドレスを設定しなければならない。実装では、SETのメーカーソフトウェアインストール後にSETにダウロードされるアプリケーションを介してH-SLPのアドレスを変更できないようにしなければならない。次の流れは、H-SLPアドレス格納を例示する。1.開始する。2に行く。2.IMSIは変更されたか。はいの場合は3に行く。いいえの場合は3を飛ばし、直接4に行く。3.SETからH-SLPをクリアする。4に行く。4.UICCにはH-SLPアドレスが入っているか。いいえの場合は5に行く。はいの場合は9に行く。5.SETのH-SLPアドレスはサポートされるか。いいえの場合は7に行く。はいの場合は6に行く。6.H-SLPアドレスがSET内でプロビジョニングされているか。いいえの場合は7に行く。はいの場合は8に行く。7.IMSIからH-SLPアドレスを生成する。10に行く。8.SETから設定を読み取る。10に行く。9.UICCからH-SLPアドレスを読み取る。10に行く。10.H-SLPアドレスを用いてH-SLPへのTLSコネクションを生成する。11に行く。11.認証は成功か。いいえの場合は12に行く。はいの場合は14に行く。12.H-SLPアドレスはIMSIから生成されたか。いいえの場合は7に行く。はいの場合は13に行く。13.SUPLセッションを打ち切り、終了する。14.SUPLセッションを実行し、終了する。6.4.3WIMAXに基づく配備SETがWiMAXネットワークに添付するときには、それは、OMADMを介して更新されたH-SLPアドレスを受信することができる。H-SLPアドレスがWiMAX端末にセキュアな形でプロビジョニングされるときには、それは、保護された環境で格納しなければならない。6.5秘密性及びデータ完全性プロトコルTLS1.1又はPSK-TLSは、SETとSLPとの間の秘密性及びデータ完全性を提供するために使用することができる。SETとSLPとの間のTLS又はPSK-TLSセッション内でSUPLINIT以外のすべてのSUPLメッセージが引き渡されなければならない。第6.1.1.3節は、SUPL3.0配備におけるいずれのエンティティがサーバ証明書認証によるTLS及び/又はTLS-PSKを強制的又は任意選択的であるかを決定するための詳細を提供する。6.5.1サーバ証明書を用いるTLSサーバ証明書を用いるTLS1.1の実装は、TLS1.1のWAPプロフィールに準拠することができ、明確化のために以下を示した:SETは、以下を実装することができる:TLSRSAWITHAES128CBCSHA.追加の暗号スイートを選ぶSET実装に関しては、SETは、以下を実装すべきである:TLSRSAWITH3DESEDECBCSHAサーバ証明書を用いるTLS1.1をサポートするSLPは、以下の暗号スイートを実装することができる。TLSRSAWITH3DESEDECBCSHATLSRSAWITHAES128CBCSHANULL暗号化をサポートすることを選ぶサーバ証明書を用いるTLS1.1をサポートするSLP実装に関しては、SLPは、TLSRSAWITHNULLSHAを実装することができる。TLSRSAWITHNULLSHAの使用は、秘密性の保護を提供しないため推奨されない。しかしながら、それは、認証及び完全性保護を依然として提供する。TLS1.1のWAP証明書プロフィールは、サーバ証明書を用いるTLS1.1をサポートするSLP及びSETによってサポートすることができる。6.5.2TLS-PSKTLS-PSKの実装は、TLSハンドシェイクに関するPSK-TLSに準拠することができ、バルク暗号化BulkCipheringは、TLS1.1に関して定義されているとおりである。TLS-PSKをサポートするSETは、以下を実装することができる。TLSPSKWITHAES128CBCSHA追加の暗号スイートを選ぶTLS-PSKをサポートするSET実装に関しては、SETは、以下を実装すべきである:TLSPSKWITH3DESEDECBCSHA以下の暗号スイートをSLPによって実装することができる。TLSPSKWITHAES128CBCSHA追加の暗号スイートを選ぶTLS-PSKをサポートするSLP実装に関しては、SLPは、以下を実装すべきである:TLSPSKWITH3DESEDECBCSHA非プロキシモードをサポートするSPCによって以下の暗号スイートを実装することができる。TLSPSKWITHAES128CBCSHA追加の暗号スイートを選ぶ非プロキシモードをサポートするSPC実装に関しては、SPCは、以下を実装すべきである。TLSPSKWITH3DESEDECBCSHA6.6DCert方法及びユーザバインディングDCert方法は、SETハンドセットを認証するが、GBA方法、SEK方法及びACA方法と異なりアクセスネットワーククレデンシャルに結合された認証は実施しない。SLPが相互認証のためにDCert方法を使用する場合は、SLPオペレータは、いずれのSUPLユーザがSETと関連付けられるべきかを検証するための何らかのその他のメカニズムが必要である。用語ユーザバインディングは、SUPLユーザをSETアイデンティティと関連付けことについて説明するために使用される。SETの所有権が変わった場合は、既存のSUPLユーザは、SLPオペレータに連絡してユーザバインディングを解除させる責任を有する。SUPL3.0は、ユーザバインディング手順を規定しないが、1つの可能な手順が第6.6.1節に示される。幾つかのSLPは、SLPオペレータによって提供されるその他のサービスの一部としてユーザバインディング手順を組み入れることができる。その他の場合は、ユーザバインディングは、配布チェーンの一部であることができる。SLPオペレータは、選択するあらゆるユーザバインディング手順を使用することができるが、次の点に留意すべきである。SUPLユーザをユーザバインディング手順の一部として認証されなければならない。○SUPLユーザの認証失敗は、サービスの窃盗を許容することになり、さらに、脅威エージェントが識別されたSUPLユーザの位置に関してSLPに誤解させるのを許容することになる。○SLPオペレータは、ユーザ認証に関して自己の既存のメカニズム及び方針を適用することを推奨する。SETをユーザバインディング手順の一部として認証されなければならない。○これに関する理由は微妙である。脅威エージェントがアリスの動きを追跡することを希望し、アリスがSETアイデンティティSETIDAを有するSETを所有すると仮定する。脅威エージェントは、合法的なSUPLユーザとして登録し、彼女自身を認証後に、SETアイデンティティSETIDAを有するSETを所有すると主張する。SLPオペレータがこのSETを脅威エージェントのアカウントと関連付けた場合は、脅威エージェントは、ネットワークによって開始されるセッションを介してSLPから定期的な位置更新を入手するための権限を自分自身に付与することができる。しかしながら、アリスがSETを使用中であるため、脅威エージェントは、実際にはアリスの位置の更新を入手している。SLPオペレータは、アリスの位置の秘密性を保持することが期待されるため、該攻撃を防止することがSLPオペレータの関心事である。6.6.1ユーザバインディング手順例DCert方法は、主に、ウェブブラウジング能力を有するSETを対象にして設計されており、例は、スマートフォン、タブレット又はタッチ画面式マルチメディアプレイヤーを含む。該SETは、次の仕組みを使用することができる。1.SLPオペレータが、SETを使用中にSLPによって所有されるウェブサーバのURLに接続するようにSUPLユーザをプロンプトする。2.加入者が、SETを使用中にウェブサイトおそらくWAPに接続する。3.ウェブサーバ及びSETがTLSを実施するa.ウェブサーバがサーバ証明書を提供し、クライアント証明書を要求する。ウェブサーバの証明書は、SUPLサービスのために使用されるSLPサービス証明書のための証明書とは別個であることができる。b.SETがウェブサーバを認証するc.SETがSETのデバイス証明書を用いてウェブサーバに認証する。d.これで、ウェブサーバは、セキュアなチャネルがデバイス証明書内のSETアイデンティティ例えば、IMEI、MEID又は一連番号と関連付けられていることを認証している。4.SUPLユーザが、ウェブサイトと何らかの範囲外の認証を実施する。例えば、ウェブサーバは、SLP専用のユーザ名/パスワード、又は認定されたfederatedユーザ名/パスワード又はその他の加入者詳細、例えば、アドレス、誕生日、等、を要求することができる。5.これで、SLPオペレータが、セキュアな形で加入者をデバイスアイデンティティと関連付けており、この関連付けをSLP内に格納すべきである。追加の実施形態8SUPL3.0は、モードASUPLINIT保護及びモードBSUPLINIT保護を定義している。モードA保護は、SLPがセキュリティの確保されたULPセッション中にSETに共有鍵を送信する能力を有することを要求する。この実施形態は、共有鍵パラメータについて説明し、共有鍵を要求及び送信するためにいずれのULPメッセージが使用されるべきかを示す。従って、この実施形態は、SUPL3.0内に組み入れることができ、節番号は、SUPL3.0の節を指すことができる。6.3.3SUPLINIT/REINITメッセージのエンドツーエンド保護注:SUPLINITメッセージのエンドツーエンド保護は、非緊急SUPLINIT/REINITメッセージのみに適用される。第6.3.3節のプロセスは、D-SLP及びH-SLPであるSLPのみに適用され、それらのプロセスは、E-SLPには適用されない。SUPLINIT及びSUPLREINITメッセージのエンドツーエンド保護のための手順は、SUPLINITメッセージとSUPLREINITメッセージとの間では区別がなく、SUPLINITメッセージ及びSUPLREINITメッセージの両方とも、あたかも同じタイプのメッセージとして処理される。単純化を目的として、それらの手順はSUPLINIT保護手順と呼び、SUPLINITメッセージ及びSUPLREINITメッセージの両方とも、SUPLINIT保護手順を用いて処理される。本明細書ではエンドツーエンドSUPLINIT保護に関して3つの選択肢が提供される。すなわち、Null、モードA及びモードB。NullSUPLINIT保護は、エンドツーエンド完全性保護、エンドツーエンドリプレイ保護及び秘密性保護のいずれも提供しない。NullSUPLINIT保護のための手順は、第6.3.4節で説明される。モードASUPLINIT保護は、デフォルトアルゴリズムを用いてのエンドツーエンド完全性保護及びエンドツーエンドリプレイ保護を提供する。モードASUPLINIT保護は、セキュリティが確保されたULPセッション中にSLPによってSETに送信された共有鍵を使用する。モードASUPLINIT保護のための手順は、第6.3.5節で説明される。モードBSUPLINIT保護は、デフォルトアルゴリズムを用いてのエンドツーエンド完全性保護及びエンドツーエンドリプレイ保護を提供する。モードBSUPLINIT保護は、該当するPSKに基づく方法GBA方法又はSEK方法を用いて導き出された共有鍵を使用する。モードBSUPLINIT保護のための手順は、第6.3.6節で説明される。保護レベルに関する優先順位は次の通りである:◆NullSUPLINIT保護は、最低の優先度を有する。◆モードASUPLINIT保護は、NullSUPLINIT保護よりも高い優先度を有する。◆モードBSUPLINIT保護は、モードASUPLINIT保護よりも高い優先度を有する。SUPLINITメッセージでは、下表内のProtectionLevelパラメータは、現在の保護レベルにより割り当てられる。注:この明細書は、将来のバージョンにおいてより高度な保護レベルを追加するのを可能にするように書かれている。この高度な保護は、SUPLINIT/REINITのセキュリティを確保するためのその他の方法の交渉を可能にする例えば、暗号化を可能にする及びアルゴリズムの交渉を可能にする。ProtectionLevelパラメータは、SETがSUPLINIT/REINITメッセージの構文解析ができるかどうかを決定するのを援助するために含められている。ProtectionLevelパラメータは、拡張性に関して要求される。SUPLINIT/REINITメッセージは、セキュリティパラメータを含めるために存在するProtectorパラメータを有することができ、Protectorパラメータの存在は、下表において規定される。SUPLINITProtectionLevelパラメータ値及びSUPLINITメッセージ及びSUPLREINITメッセージ内のProtectionLevelパラメータの存在ACAに基づく方法をサポートするSET又はD-SLP又はH-SLPは、NullSUPLINIT保護をサポートしなければならない。全SETがモードASUPLINIT保護手順をサポートすべきである。D-SLP又はH-SLPは、モードASUPLINIT保護手順をサポートすることができる。PSKに基づく方法をサポートするSET又はD-SLP又はH-SLPは、モードBSUPLINIT保護手順をサポートしなければならない。E-SLPエンティティは、現在定義されるSUPLINIT保護には含まれていない。6.3.3.1SUPLINIT保護レベルの交渉次のプロセスは、D-SLP及びH-SLPであるSLPのみに適用され、それらのプロセスは、E-SLPには適用されない。SUPLINIT保護レベルがどのようにして交渉されるかに関する情報を提供するための説明を以下に示した。4.SETは、有効なSUPLINITROOTKEYが存在しないときには例えば、パワーアップ時又はSUPLINITROOTKEYの寿命が切れているときNullSUPLINIT保護を適用しなければならない。初期の保護レベルは、常にNullSUPLINIT保護である。この状態で、SETは、すべてのSUPLINIT/REINITメッセージを処理する、すなわち、いずれのメッセージも暗黙に廃棄されない。SUPLINIT/REINITメッセージが不具合状態で構文解析される場合は、SETは、誤りメッセージをSLPに送信する。5.SETが、特定のSLPに関してモードA又はモードBSUPLINIT保護を用いて既に交渉された有効なSUPLINITROOTKEY及び有効なリプレイカウンタを有する場合は、SETは、交渉されたモードモードA又はモードBを用いてそのSLPからのすべてのSUPLINIT/REINITメッセージを処理する。6.SETがSLPへの相互に認証されたセキュアなコネクションを確立するときに、a.相互認証のためにPSKに基づく方法GBA又はSEKが使用された場合は、モードBSUPLINIT保護が適用され、PSK-TLSのハンドシェイクにおいてやり取りされたB-TIDは、Ks3GPP及び3GPP2配備ではKsNAFとして使用される又は3GPP及び3GPP2配備においてKsNAFとして使用されるSUPLINITROOTKEYを導き出すために使用することができるSEKに対応する。このKsNAK又はSEK及び関連付けられたB-TIDは、以下のいずれかまでモードBSUPLINIT保護で使用される。i.鍵が期限切れになるまで。この場合は、SET及びSLPはNullSUPLINIT保護に戻るii.SET及びSLPが非緊急セッションでACA方法を使用するまで。この場合は、SET及びSLPは、以下のステップ3のbにおいて説明されるようにモードA又はNullSUPLINIT保護に戻る、又は、iii.SET及びH-SLPが、新しいB-TIDを用いてTLSを確立するためにGBAの又はSEKのブートストラッピング再交渉方法を使用するまで。この場合は、B-TID及び対応するKsNAF又はSEKがモードBSUPLINIT保護のために使用される。b.そうでない場合は、SET及びSLPは、DCert方法又はACA方法を用いてセキュアなコネクションを確立した。i.SETが有効なSUPLINITROOTKEYを有さない場合は、それは、セキュアなセッションの確立に引き続いてそれのSETCapabilitiesパラメータを搬送する次のULPメッセージ内のSETCapabilitiessUPLINITRootKeyStatus=invalidSUPLINITRootKeyでSLPに示す。1.モードASUPLINIT保護の場合は、SLPは、次のSUPLENDメッセージにおいてモードASUPLINITROOTKEY確立手順を実施する第6.3.5.2節。成功裏のモードASUPLINITROOTKEY確立手順は、モードASUPLINIT保護が適用されることをSETに示す。成功裏のモードASUPLINITROOTKEY確立手順が生じるまでは、SETは、NullSUPLINIT保護を使用するものとする。注:SUPLINITROOTKEYを更新する方針は、SLPオペレータの判断である。2.SLPがモードASUPLINIT保護をサポートしない又はこの特定の時点でモードASUPLINIT保護をサポートしない場合は、SLPは、ModeAKeyIdentifier、TemporaryModeAKeyIdentifier、SUPLINITROOTKEY及びModeAKeyLifetimeパラメータを送信せず、それは、SETがNullSUPLINIT保護を使用するものとすることを示す。ii.SETが有効なSUPLINITROOTKEYを有するが、有効なTemporaryModeAKeyIdentifierを有さないか又はリプレイ保護に関する同期化を失っている場合は、それは、セキュアなセッションの確立に引き続いてそれのSETCapabilitiesパラメータを搬送する次のULPメッセージ内のSETCapabilitiessUPLINITRootKeyStatus=outofsyncSUPLINITRootKeyでSLPに示す。1.次のSUPLENDメッセージでモードA再同期化手順を実施する第6.3.5.3節。成功裏のモードA再同期化手順は、モードASUPLINIT保護が適用されることをSETに示す。成功裏のモードA再同期化手順が生じるまでは、SETは、NullSUPLINIT保護を使用するものとする。2.SLPがモードASUPLINIT保護をサポートしない又はこの特定の時点でモードASUPLINIT保護をサポートすることを希望しない場合は、SLPは、モードA再同期化手順を実施せず第6.3.5.3節、それは、SETがNullSUPLINIT保護を使用するものとすることを示す。これは、SETがSLPへの新しいTLSコネクションを設定するごとに保護レベルが再交渉されることを意味することに注目すること。6.3.3.2SLPの観点からの交渉SETとの直近のIPセッションがGBA又はSEK方法を用いて認証され、及びSLPがSETに関する現在のB-TID及び関連付けられた鍵を有する場合は、◆B-TIDがGBAを用いて入手された鍵に関するものである場合は、SLPは、SUPLINITROOTKEYを、直近のB-TIDに対応し、次のように生成されるKsint/extNAFとして割り当てる。○FQDNは、H-SLPFQDNであるものとする。○SUPLINIT保護のために使用するものとするGBAUaセキュリティプロトコル識別子は、OMNAレジストリ[OMNA]で定義される。◆B-TIDがSEK方法を用いて導き出された鍵に関するものである場合は、SUPLINITROOTKEYは、第6.1.2.1.2節で定義されるSEKである。◆その他のSUPLINIT保護は交渉されていないと仮定すると、SLPは、そのSETのためにモードBSUPLINIT保護レベルを割り当てる。そうでない場合は、SLPがSETに関する有効なModeAKeyIdentifier及び関連付けられた鍵を有する場合は、SLPは、そのSETのためにモードASUPLINIT保護レベルを割り当てる。その他の保護レベルが割り当てられていない場合は、SLPは、そのSETのためにNullSUPLINIT保護レベルを割り当てる。SLPは、現在割り当てられているレベルのSUPLINIT/REINIT保護に対応する引き渡し前にSUPLINITメッセージを処理するための手順を適用する。これは、SUPLINITメッセージ内のProtectionLevelパラメータのための該当値を割り当てることを含む。6.3.3.3SETの観点からの交渉SLPとの直近のIPセッションがGBA又はSEK方法を用いて認証され、及びSETがそのIPセッションのために用いられる現在のB-TID及び関連付けられた鍵を有する場合、◆B-TIDがGBAを用いて入手された鍵に関するものである場合は、SETは、SUPLINITROOTKEYを、直近のB-TIDに対応し、次のように生成されるKsint/extNAFとして割り当てる。○FQDNは、H-SLPFQDNであるものとする。○SUPLINIT保護のために使用するものとするGBAUaセキュリティプロトコル識別子[3GPP24.109]は、OMNAレジストリ[OMNA]で定義される。◆B-TIDがSEK方法を用いて導き出された鍵に関するものである場合は、SUPLINITROOTKEYは、第6.1.2.1.2節で定義されるSEKである。◆その他のSUPLINIT保護は交渉されていないと仮定すると、SETは、モードBSUPLINIT保護レベルを割り当てる。そうでない場合は、SETがSLPに関する有効なModeAKeyIdentifier、TemporaryModeAKeyIdentifier及び関連付けられたSUPLINITROOTKEYを有する場合は、SETは、そのSLPのためにモードASUPLINIT保護レベルを割り当てる。その他の保護レベルが割り当てられていない場合は、SETは、NullSUPLINIT保護レベルを割り当てる。SETは、現在割り当てられているレベルのSUPLINIT保護に対応する受信されたSUPLINIT/REINITメッセージを処理するための手順を適用する。6.3.3.4例外手順SET内部のSUPLINIT保護パラメータが壊れているとSETが決定した場合は、SETは、SLPとのTLSセッションを確立しなければならない。GBA認証が使用される場合は、SETは、新しい鍵を確立するためのGBAブートストラッピングを開始しなければならない。SEK方法を使用するSETに関しては、SETは、第6.1.2.1.2節において定義されるように、新しい鍵をイネーブルにするためにSEKブートストラッピングを開始しなければならない。そうでない場合は、SETは、第6.3.3.1節のステップ3のbの手順に従う。SLPがセキュリティコンテキストを失った場合は例えば、大量のデータ損失、SLPは、測位活動を開始する手段を有さないことになる。コンテキストは、KsNAF又はSEKが期限切れになるか又はSETがSLPに接続するときに再確立される。このブロックアウトウィンドウblockoutwindowを防止するために、SLPは、該シナリオから回復するためにすべてのSUPLINITセキュリティコンテキスト情報が十分な冗長度を持って格納されるようにすべきである。6.3.3.5SETにおいてSUPLINITメッセージを処理するための一般的手順以下の手順は、受信されたSUPLINITメッセージを処理する方法を決定するためにSETによって適用される。1.SETが送信SLPSUPLINITメッセージを送信したSLPを識別する。a.SUPLINITメッセージ内にD-SLPFQDNパラメータが存在する場合は、SETは、このパラメータを用いて送信SLPを識別するものとする。i.SETが識別されたD-SLPと既存の関係を有さない場合は、SETは、SUPLINITメッセージを暗黙に廃棄するものとし、現在の手順から出る。ii.そうでない場合は、SETは、ステップ2に進む。b.SUPLINITメッセージ内にD-SLPFQDNパラメータが存在しない場合は、SETは、送信SLPをSETのH-SLPとして識別する。2.SETが、送信SLPのために割り当てられたSUPLINIT保護レベルに基づいて初期フィルタリングを実施する:a.送信SLPのためにNullSUPLINIT保護が割り当てられた場合は、SETは、NullSUPLINIT保護手順を実施し、現在の手順から出る。b.送信SLPのためにモードA又はモードBSUPLINIT保護が割り当てられた場合は、i.SUPLINITメッセージにProtectorパラメータが入っていない場合は、SETは、SUPLINITメッセージを暗黙に廃棄し、現在の手順から出る。ii.SUPLINITメッセージにProtectorパラメータが入っている場合は、SETは、第6.3.5節又は第6.3.6節のそれぞれの該当するモードASUPLINIT保護手順又はモードBSUPLINIT保護手順を実施する。SETは、送信SLPと関連付けられたSUPLINITROOT鍵のうちのいずれがSUPLINITメッセージの処理のために使用されるべきかを識別するためにProtectorパラメータ内のKeyIdentifierを使用する。6.3.5モードASUPLINIT保護レベルに関する仕様6.3.5.1モードASUPLINIT保護のための鍵識別子モードASUPLINIT保護は、SUPLINIT/REINITメッセージとともに送信することができる2つの鍵識別子、すなわち、ModeAKeyIdentifier及びTemporaryModeAKeyIdentifier、を使用する。ModeAKeyIdentifierは、SUPLINITROOTKEYと関連付けられたグローバルで一意の、長期の鍵識別子である。SLPは、SLPがSUPLINITROOTKEYのための新しい値をプロビジョニングするときのみに新しいModeAKeyIdentifierをSETに提供する。TemporaryModeAKeyIdentifierは、ModeAKeyIdentifierと関連付けられた短期のアイデンティティ仮名である。TemporaryModeAKeyIdentifierは、TemporaryModeAKeyIdentifierが有効である期間の間グローバルで一意であるものとする。SET及びSLPは、第6.3.5.5節及び第6.3.5.6節において説明されるようにTemporaryModeAKeyIdentifierの値を同期化する。SLPは、典型的には、TemporaryModeAKeyIdentifierを基本的SUPLINITプロテクタ内のKeyIdentifierとして使用する。SETは、基本的SUPLINITプロテクタを検証するためにいずれのSUPLINITROOTKEYが使用されるべきかを決定するためにTemporaryModeAKeyIdentifierを使用する。ModeAKeyIdentifierは、典型的には、SUPLINIT/REINITメッセージでは送信されず、その理由は、観察者が複数のSUPLINIT/REINITメッセージを1つの共通のSETユーザと関連付けるのを可能にするためである。TemporaryModeAKeyIdentifierの目的は、脅威エージェントが複数のSUPLINITメッセージを1人のSETユーザと関連付けるためにModeAKeyIdentifierを使用するのを防止することである。SLP及びSETのみがTemporaryModeAKeyIdentifierをModeAKeyIdentifierと関連付けることができるようにすべきである。TemporaryModeAKeyIdentifierを変更する頻度は、主に、SETユーザの判断である。SLPは、SLP方針に基づいてTemporaryModeAKeyIdentifierのための新しい値を確立することを選択することができる。しかしながら、SLPがより長期のModeAKeyIdentifierを基本的SUPLINITプロテクタ内のKeyIdentifierとして使用することを希望する状況が存在する。例えば、SETが基本的SUPLINITプロテクタ内のTemporaryModeAKeyIdentifierを用いて複数のSUPLINIT/REINITメッセージに応答していないと仮定する。SLPは、SETがTemporaryModeAKeyIdentifierに関する同期化を失っていることを懸念するおそれがある。SET及びSLPは、長期的なModeAKeyIdentifierに関しての方が同期化状態を維持する可能性が高い。従って、SLPは、同期化を失うことがSETがSUPLINITメッセージを検証するのを妨げないようにするために基本的SUPLINITプロテクタ内のModeAKeyIdentifierを用いてSUPLINIT/REINITメッセージを送信することができる。6.3.5.2モードASUPLINITROOTKEY確立手順SUPLINITROOTKEYのための値は、SLPがセキュアなSUPLセッションにおけるSETへのSUPLENDメッセージ内で新しいModeAKeyIdentifierパラメータ、TemporaryModeAKeyIdentifierパラメータ、SUPLINITROOTKEYパラメータ及びModeAKeyLifetimeパラメータを送信することによって確立される。引き渡しが成功である場合は、SLP及びSETは、このモードASUPLINITROOTKEY確立手順を成功であるとみなす。ModeAKeyLifetimeパラメータは、鍵が有効でなくなるときのUTC時間を含む。6.3.5.3モードA再同期化手順SLPは、次のステップを用いてSETとTemporaryModeAKeyIdentifierのための新しい値を確立する:1.SLPが、セキュアなSUPLセッションでのSETへのSUPLENDメッセージにおいて現在のModeAKeyIdentifier及び新しいTemporaryModeAKeyIdentifierパラメータをSETに送信する。引き渡しが成功である場合は、SLPは、このモードA再同期化手順を成功であるとみなす。2.SETが、受信されたModeAKeyIdentifierを、SETがそのSLPのために現在割り当てている有効なSUPLINITROOTKEY値のModeAKeyIdentifierと比較する。a.ModeAKeyIdentifier値が異なる場合は、これは、SETにおいて割り当てられたModeAKeyIdentifierの値が壊れていることを示し、次のステップが実施される:i.SETがTemporaryModeAKeyIdentifierを廃棄し、このモードA再同期化手順は失敗であるとみなす。ii.SETが第6.3.3.4節の例外手順を開始する。b.受信されたModeAKeyIdentifierが有効なModeAKeyIdentifierと等しい場合は、i.SETは、新しいTemporaryModeAKeyIdentifierを対応するModeAKeyIdentifierと関連付ける。ii.SETは、このモードA再同期化手順を成功であるとみなす。6.3.5.4モードASUPLINIT保護及び基本的SUPLINITプロテクタモードASUPLINIT保護は、基本的SUPLINITプロテクタ及び第0節において定義される関連付けられた手順を使用し、さらなる明確化のために以下を示した。◆KeyIdentifierType:ModeAKeyIdentifier又はTemporaryModeAKeyIdentifierのいずれかが使用されることを示す。◆KeyIdentifier:ModeAKeyIdentifierTypeに適宜対応するModeAKeyIdentifier又はTemporaryModeAKeyIdentifierのいずれかに対応する。◆BasicMACは、上記のKeyIdentifierと関連付けられたSUPLINITROOTKEYを用いて、SUPLINITBasicIK=HMAC-SHA256-128SUPLINITROOTKEY,ModeAIKを用いて計算される。6.3.5.5SLP手順モードA専用SLP手順は、SUPLINITROOTKEY確立、SUPLINITROOTKEYの期限切れ、及びSETとSLPとの間で同期化を維持することに関するものである。モードASUPLINITROOTKEY確立手順は、第6.3.5.2節において規定される。SLPは、SETCapabilitiessUPLINITRootKeyStatus=invalidSUPLINITRootKeyにおけるSETによる同期外れ表示又はSLPの範囲外の内部判断に応答してモードASUPLINITROOTKEY確立手順を実施することができる。すなわち、SLPは、SETによる対応する表示がないときでもSUPLINITROOTKEYを関連付けられたパラメータとともに送信することができる。SUPLINITROOTKEY及び関連付けられたパラメータは、以下のうちの早い方の後にSLPにおいて有効であることを停止するものとする関連付けられたModeAKeyIdentifierの寿命、及びその後の成功したモードASUPLINITROOTKEY確立時第6.3.5.2節。モードA再同期化手順は、第6.3.5.3節において規定される。SLPは、SETCapabilitiessUPLINITRootKeyStatus=outofsyncSUPLINITRootKeyにおけるSETによる同期外れ表示又はSLPの範囲外の内部判断に応答してモードA再同期化手順を実施することができる。すなわち、SLPは、SETによる対応する表示がないときでもTemporaryModeAKeyIdentifierを送信することができる。成功したモードASUPLINITROOTKEY確立手順又は成功したモードA再同期化手順に引き続き、SLPは、BasicLastReplayCounterを0x0000にリセットする。6.3.5.6SET手順モードA専用SET手順は、SUPLINITROOTKEY確立、SUPLINITROOTKEYの期限切れ、及びSETとSLPとの間で同期化を維持することに関するものである。モードASUPLINITROOTKEY確立手順は、第6.3.5.2節において規定される。SETは、セキュアなセッション確立に引き続いてSETCapabilitiesパラメータを搬送するULPメッセージにおいてSETCapabilitiessUPLINITRootKeyStatus=invalidSUPLINITRootKeyにおける有効なSUPLINITROOTKEYをSET内において有さないことを示すことによってモードASUPLINITROOTKEY確立手順をトリガするのを試みることができる。確立されたSUPLINITROOTKEY及び関連付けられたパラメータは、以下のうちの早い方の後にSETにおいて無効であるとみなされるものとする関連付けられたModeAKeyIdentifierの寿命。その後の成功したモードASUPLINITROOTKEY確立第6.3.5.2節から5分後。この時間遅延は、最後のモードASUPLINITROOTKEY確立手順の前に送信されたSUPLINITメッセージの引き渡しを考慮したものであり、このため、SUPLINITメッセージは、前のSUPLINITROOTKEYを用いて保護しなければならないことになる。SETが、SUPLINITROOTKEY、ModeAKeyIdentifier及びModeAKeyLifetimeの値の崩壊を検出した時点。崩壊が発生した場合は、SETは、第6.3.3.4節の例外手順を開始するものとする。モードA再同期化手順は、第6.3.5.3節において規定される。SETは、セキュアなセッション確立に引き続いてSETCapabilitiesパラメータを搬送するULPメッセージにおいてSETCapabilitiessUPLINITRootKeyStatus=outofsyncSUPLINITRootKeyにおけるSET内での同期化喪失を示すことによってモードA再同期化手順をトリガするのを試みることができる。成功したモードASUPLINITROOTKEY確立手順又は成功したモードA再同期化手順に引き続き、SETは、BasicReplayCounterのための使用された値のキャッシュをクリアするSLPもBasicLastReplayCounterを0x0000にリセットしていることになるため。6.3.7基本的SUPLINITプロテクタを使用するための仕様基本的SUPLINITプロテクタは、モードASUPLINIT保護及びモードBSUPLINIT保護の両方のために使用され、次のパラメータを含む:◆KeyIdentifierType◆KeyIdentifier:長さ=8オクテット◆BasicReplayCounter:長さ=2オクテット◆BasicMAC:長さ=4オクテットBasicMACパラメータは、以下のように生成される。◆BasicMAC=HMAC-SHA256-32SUPLINITBasicIK,SUPLINIT/REINIT’、ここで、◆SUPLINITBasicIKは、モードASUPLINIT保護及びモードBSUPLINIT保護のそれぞれに関する第6.3.5節及び第6.3.6節により導き出される。◆SUPLINIT/REINIT’は、BasicMAC以外の全パラメータが割り当てられ、MACパラメータがすべてゼロに設定されたSUPLINIT/REINITに対応する◆HMAC-SHA256-32及びHMAC-SHA256-128は、[HMAC]において規定される。6.1.1.2サポートされる認証方法概要情報用1汎用ブートストラッピングアーキテクチャGBAに基づく。汎用ブートストラッピングアーキテクチャGBA[3GPP33.220]、[3GPP33.222]、[3GPP2S.S0114]、[3GPP24.109]を有するTLS-PSK。GBAは、既存の3GPP/3GPP2認証メカニズムを用いて導き出される共有される秘密に基づいて相互認証能力を提供する。◆SET及びSLPは、汎用ブートストラッピングアーキテクチャGBAを有するTLS-PSKを用いて相互に認証される。2SEKに基づくWIMAXSLPのみに適用。◆SET及びSLPは、SEKを有するTLS-PSKを用いて相互に認証される。SEK方法の詳細は、第6.1.2.1.2節において見つけることができる。3デバイス証明書DCertに基づく。このANから独立した方法は、次を用いるTLSを使用する◆SETに対してSLPを認証するためのRSAサーバ証明書、◆SLPに対してSETを認証するためのRSAクライアント証明書。4代替クライアント認証ACAに基づく。これは、次を用いるTLSを使用する◆SETに対してSLPを認証するためのRSA証明書、◆SLPに対するSETの代替クライアント認証第6.1.4節参照。この場合は、SLPは、SET識別子MSISDN、等と関連付けられたIPアドレスをベアラネットワークに確認させることによってSETを認証する。5SLP専用。これは、SLPがSETを認証できないシナリオにおいて使用される。この方法は、非緊急時のためには使用しないものとする。SETは、この方法とACA基づく場合を区別することができない。これは、以下を用いてTLSを使用する◆SETに対してSLPを認証するためのRSA証明書◆SETは認証されない。6.1.2.1.1GBA方法をサポートする配備GBA[3GPP33.220]、[3GPP24.109]、[3GPP2S.S0109]をサポートする配備の場合は、共有鍵は次のようにして確立される:SLPがIP通信のセキュリティを確保するために及びSUPLINIT及び/又はSUPLREINITを保護するために鍵素材をBSFに要求するときには、SLPは、USSユーザセキュリティ設定も要求しなければならない。USSは、永久的なユーザアイデンティティ例えば、IMPI、IMSI又はMSISDNを含まなければならない。SETとSLPとの間でのIP通信のセキュリティを確保するためには、SET及びSLPは、GBA[3GPP33.220]、[3GPP24.109]、[3GPP33.222]、[3GPP2S.S0109]を用いてTLS-PSKにより共有秘密鍵を導き出し及び動作しなければならない。SLPは、SLPを指定する適切に定義されたドメイン名SLPAddressFQDN、例えば、slp.operator.com、を有さなければならない。TLS-PSKのために使用されるものとするGBAUaセキュリティプロトコル識別子がOMNAレジストリ[OMNA]内で定義されている。SLPは、BSFによって提供された永久的なユーザアイデンティティが対応するセキュリティが確保されたコネクションを通じてSLPによって受信されたSUPLメッセージ内のSETアイデンティティに対応することを確認しなければならない。SUPLINIT及び/又はSUPLREINITのMAC保護に関して、GBA[3GPP33.220]、[3GPP24.109]により鍵が導き出される。SUPLINIT保護のために使用されるものとするGBAUaセキュリティプロトコル識別子がOMNAレジストリ[OMNA]内で定義されている。SUPLINITメッセージ又はSUPLREINITメッセージに含まれるbasicMACのKeyIdentifierは、KsNAFが生成されるKsのB-TIDでなければならない。注:D/H-SLPによるBSFへのSUPLINIT保護鍵の要求は、典型的には、D/H-SLPによるIP通信のセキュリティを確保する鍵の要求と同時に発生することになる。SETは、有効なKsが常にプロビジョニングされていることを確認しなければならない。有効なKsが存在しない場合は、SETは、KsをプロビジョニングするためのGBAブートストラッピング手順を開始しなければならない。新しいUICCUSIM/SIM/R-UIMがSETによって検出されるごとに新しいKsが確立されなければならない。さらに、SETは、ホームネットワークオペレータによって設定されたKsNAFの寿命が経過しているときには新しい共有鍵を確立しなければならない。SET能力パラメータ9.2.8SUPLENDSUPLENDメッセージ10.xSUPLINITKeyResponseSUPLINITKeyResponseパラメータは、SLPからSETにモードASUPLINIT保護のための鍵を送信するためのSUPLINITROOTKEY確立手順第6.3.5.2節参照において使用される。SUPLINITKeyResponse11.4メッセージ拡張SUPLバージョン3ULPVersion3messageextensionsDEFINITIONSAUTOMATICTAGSBEGINEXPORTSVer3SUPLINITextensionVer3SUPLSTARTextensionVer3SUPLPOSINITextensionVer3SUPLENDextensionVer3SUPLRESPONSEextensionVer3SUPLTRIGGEREDRESPONSEextensionVer3SUPLTRIGGEREDSTARTextensionVer3SUPLTRIGGEREDSTOPextensionVer3SUPLSETINITextensionVer3SUPLNOTIFYextensionVer3SUPLNOTIFYRESPONSEextensionVer3SUPLREPORTextensionQoPCapabilitiesRelativePositioningCapabilitiesCivicPositioningCapabilitiesIMPORTSVerQoPFQDNFROMULPComponentsCircularAreaEllipticalAreaPolygonAreaFROMVer2ULPComponentsPosProtocolVersion3GPPPosProtocolVersion3GPP2FROMULPVersion2parameterextensionsPosProtocolVersionOMAFROMULPVersion3parameterextensionsPosPayLoadFROMSUPLPOSNotificationFROMSUPLINITSessionIDFROMULPComponentsNotificationResponseFROMSUPLNOTIFYRESPONSEmaxnumSessionsSessionListFROMSUPLREPORTOMALPPeRelativeLocationOMALPPeReferencePointUniqueIDOMALPPeCivicLocationFROMOMALPPE幾つかの不変の部分は、簡潔さを目的として削除したVer3SUPLENDextensionSEQUENCElocationURISetLocationURISetOPTIONALslpAuthorizationSLPAuthorizationOPTIONALrelativePositionOMALPPeRelativeLocationOPTIONALcivicPositionOMALPPCivicLocationOPTIONALsULPINITKeyResponseSULPINITKeyResponseOPTIONAL幾つかの不変の部分は、簡潔さを目的として削除したSULPINITKeyResponseCHOICEmodeAKeyEstablishmentModeAKeyEstablishmentmodeAResynchModeAResynchModeAKeyEstablishmentSEQUENCEmodeAKeyIdentifierOCTETSTRINGtemporaryModeAKeyIdentifierOCTETSTRINGsUPLINITROOTKEYBITSTRINGModeAKeyLifetimeUTCTimeModeAResynchSEQUENCEmodeAKeyIdentifierOCTETSTRINGtemporaryModeAKeyIdentifierOCTETSTRINGEND116パラメータ拡張SUPLバージョン3ULPVersion3parameterextensionsDEFINITIONSAUTOMATICTAGSBEGINEXPORTSVer3PosProtocolextensionVer3SETCapabilitiesextensionVer3SLPCapabilitiesextensionVer3TriggerParamsextensionVer3ServiceSupportedextensionsIMPORTSQoPCapabilitiesRelativePositioningCapabilitiesCivicPositioningCapabilitiesFROMULPVersion3messageextensionsVer3PosProtocolextensionSEQUENCEposProtocolVersionLPPePosProtocolVersionOMAOPTIONALVer3SETCapabilitiesextensionSEQUENCEqoPCapabilitiesQoPCapabilitiesOPTIONALcivicPositioningCapabilitiesCivicPositioningCapabilitiesOPTIONALrelativePositioningCapabilitiesRelativePositioningCapabilitiesOPTIONALdSLPProvisionfromHSLPBOOLEANeSLPProvisionfromHSLPBOOLEANdSLPProvisionfromProxyDSLPBOOLEANeSLPProvisionfromProxyESLPBOOLEANdSLPNotificationtoHSLPBOOLEANsensorSupportBOOLEANsUPLINITRootKeyStatusSUPLINITRootKeyStatusOPTIONALSUPLINITRootKeyStatusENUMERATEDinvalidSUPLINITRootKeyoutofsyncSUPLINITRootKey幾つかの不変の部分は、簡潔さを目的として削除したEND追加の実施形態9ProtectorLevelパラメータに関する先行定義は、基本的保護がモードA保護及びモードB保護に変更されていることを反映していないことがあるモードB保護は、前基本的保護と同じである。先行のASN.1定義も更新することができる。従って、以下の提案は、モードA及びモードB保護を反映させ及びASN.1第11.4節を更新するように第10.25節を修正することを目的としてSUPL3.0に組み入れることができる節番は、SUPL3.0の節を指すことができる。10.22保護レベルProtectionLevelパラメータは、SUPLINIT/SUPLREINITメッセージのための保護レベルを定義する。11.3メッセージ拡張SUPLバージョン2ULPVersion2messageextensionsDEFINITIONSAUTOMATICTAGSBEGINEXPORTSVer2SUPLINITextensionVer2SUPLSTARTextensionVer2SUPLRESPONSEextensionVer2SUPLPOSINITextensionVer2SUPLPOSextensionVer2SUPLENDextensionIMPORTSSLPAddressPositionVerFROMULPComponentsSETCapabilitiesFROMSUPLSTARTSupportedNetworkInformationGNSSPosTechnologyMultipleLocationIdsUTRANGPSReferenceTimeResultUTRANGANSSReferenceTimeResultUTRANGPSReferenceTimeAssistanceUTRANGANSSReferenceTimeAssistanceSPCSETKeySPCTIDSPCSETKeylifetimeThirdPartyApplicationIDFROMVer2ULPComponentsTriggerTypeFROMSUPLTRIGGEREDSTARTVer3ProtectionLevelextensionFROMULPVersion3parameterextensions幾つかの不変の部分は、簡潔さを目的として削除したProtectionLevelSEQUENCEprotlevelProtLevelbasicProtectionParamsBasicProtectionParamsOPTIONALnotapplicableinSUPL30ver3ProtectionLevelextensionVer3ProtectionLevelextensionOPTIONALProtLevelENUMERATEDnullProtectionbasicProtectionver3modeAProtectionver3modeBProtection-basicProtectionisnotapplicableinSUPL30幾つかの不変の部分は、簡潔さを目的として削除したEND11.6パラメータ拡張SUPLバージョン3ULPVersion3parameterextensionsDEFINITIONSAUTOMATICTAGSBEGINEXPORTSVer3PosProtocolextensionVer3SETCapabilitiesextensionVer3SLPCapabilitiesextensionVer3TriggerParamsextensionVer3ServiceSupportedextensionsVer3ProtectionLevelextensionIMPORTSQoPCapabilitiesRelativePositioningCapabilitiesCivicPositioningCapabilitiesFROMULPVersion3messageextensions幾つかの不変の部分は、簡潔さを目的として削除したVer3ProtectionLevelextensionSEQUENCEkeyIdentifierTypeKeyIdentifierTypekeyIdentifierOCTETSTRINGbasicReplayCounterINTEGERbasicMACBITSTRINGKeyIdentifierTypeENUMERATEDModeAKeyIdentifierTemporaryModeAKeyIdentifierModeBKeyIdentifierENDここにおいて開示される実施形態と関係させて説明される様々な例示的な論理ブロック、コンフィギュレーション、モジュール、回路、及びアルゴリズム上のステップは、電子ハードウェア、処理デバイス、例えば、ハードウェアプロセッサ、によって実行されるコンピュータソフトウェア、又は両方の組み合わせとして実装することができることを当業者はさらに理解するであろう。上記においては、様々な例示的なコンポーネント、ブロック、コンフィギュレーション、モジュール、回路、及びステップが、それらの機能の観点で一般的に説明されている。該機能がハードウェアとして又は実行可能なソフトウェアとして実装されるかは、特定の用途及び全体的システムに対する設計上の制約事項に依存する。当業者は、説明されている機能を各々の特定の用途に合わせて様々な形で実装することができるが、該実装決定は、本開示の適用範囲からの逸脱を生じさせるものであるとは解釈されるべきではない。ここにおいて開示される実施形態と関係させて説明される方法又はアルゴリズムのステップは、直接ハードウェア内に、プロセッサによって実行されるソフトウェアモジュール内に、ファームウェア内に、又はそれらの組み合わせ内において具現化することができる。ソフトウェア又は論理モジュールは、非一時的な記憶媒体、例えば、ランダムアクセスメモリRAM、磁気抵抗ランダムアクセスメモリMRAM、スピン-トルク転送MRAMSTT-MRAM、フラッシュメモリ、読み取り専用メモリROM、プログラマブル読み取り専用メモリPROM、消去可能プログラマブル読み取り専用メモリEPROM、電気的消去可能プログラマブル読み取り専用メモリEEPROM、レジスタ、ハードディスク、取り外し可能なディスク、コンパクトディスク読み取り専用メモリCD-ROM、デジタルバーサタイルディスクDVD、Blu-rayディスク登録商標、又は当業において知られるその他の形態の記憶媒体、内に常駐することができる。上記の組み合わせもコンピュータによって読み取り可能な媒体の適用範囲内に含められるべきである。例は、データ構造を用いて符号化されたコンピュータによって読み取り可能な媒体と、コンピュータプログラムを用いて符号化されたコンピュータによって読み取り可能な媒体と、を含む。コンピュータによって読み取り可能な媒体は、製造品の形態をとることができる。典型的な記憶媒体は、プロセッサに結合され、このため、プロセッサは、記憶媒体から情報を読み取ること又は記憶媒体に情報を書き込むことができる。代替においては、記憶媒体は、プロセッサと一体化することができる。プロセッサ及び記憶媒体は、特定用途向け集積回路ASIC内に常駐することができる。ASICは、コンピューティングデバイス又はユーザ端末内に常駐することができる。代替においては、プロセッサ及び記憶媒体は、コンピューティングデバイス又はユーザ端末において個別のコンポーネントとして常駐することができる。従って、ここにおいて説明される方法は、用途に依存して様々な手段によって実装することができる。例えば、これらの方法は、ハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせ内に実装することができる。ASIC及びプロセッサに加えて、又はASIC及びプロセッサの代替として、ハードウェア実装は、ここにおいて説明される機能を果たすように設計されたデジタル信号処理デバイスDSPD、プログラマブル論理デバイスPLD、フィールドプログラマブルゲートアレイFPGA、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子デバイス、その他の電子ユニット、又はそれらの組み合わせを含むことができる。ここにおいて、用語制御論理は、ソフトウェア、ハードウェア、ファームウェア、又は組み合わせによって実装された論理を包含する。ファームウェア及び/又はソフトウェアを含む実装に関しては、方法は、ここにおいて説明される機能を果たすモジュール例えば、手順、関数、等を用いて実装することができる。ここにおいて説明される方法を実装する際には、命令を有形に具現化させるあらゆる機械によって読み取り可能な媒体を使用することができる。例えば、ソフトウェアコードは、メモリに格納して処理ユニットによって実行することができる。メモリは、処理ユニット内に又は処理ユニットの外部に実装することができる。ここにおいて用いられる場合において、用語メモリは、あらゆるタイプの長期、短期、揮発性、非揮発性、又はその他の記憶デバイスを意味し、いずれの特定のタイプの又は数のメモリにも限定されず、及びメモリが格納される媒体のタイプに限定されない。ファームウェア及び/又はソフトウェアが関係する実装においては、機能は、コンピュータによって読み取り可能な媒体において1つ以上の命令又はコードとして格納することができる。本開示は、Wi-Fi/WLAN又はその他の無線ネットワークと関係させて実装することができる。Wi-Fi/WLAN信号に加えて、無線/移動局は、衛星から信号を受信することもでき、それらは、全地球測位システムGPS、ガリレオ、GLONASSグロナス、NAVSTARナブスター、QZSS、これらのシステムの組み合わせからの衛星を使用するシステム、将来開発されるあらゆるSPSからであることができ、各々は、概して、衛星測位システムSPS又はGNSS全地球航法衛星システムと呼ばれる。本開示は、擬似衛星シュードライト又は擬似衛星を含むシステムの組み合わせと関係させて実装することもできる。本開示は、フェムトセル又はフェムトセルを含むシステムの組み合わせと関係させて実装することができる。本開示は、様々な無線通信ネットワーク、例えば、ワイヤレスワイドエリアネットワークWWAN、ワイヤレスローカルエリアネットワークWLAN、ワイヤレスパーソナルエリアネットワークWPAN、等、と関係させて実装することができる。用語ネットワーク及びシステムは、互換可能な形でしばしば用いられる。用語position位置及びlocation位置は、互換可能な形でしばしば用いられる。WWANは、符号分割多元接続CDMAネットワーク、時分割多元接続TDMAネットワーク、周波数分割多元接続FDMAネットワーク、直交周波数分割多元接続OFDMAネットワーク、単一搬送波周波数分割多元接続SC-FDMAネットワーク、ロングタームエボリューションLongTermEvolutionLTEネットワーク、WiMAXIEEE802.16ネットワーク、等であることができる。CDMAネットワークは、1つ以上の無線アクセス技術RAT、例えば、cdma2000、Wideband-CDMAW-CDMA、等、を実装することができる。cdma2000は、IS-95規格と、IS-2000規格と、IS-856規格と、を含む。TDMAネットワークは、グローバル移動体通信システムGSM、デジタルアドバンストモバイルフォンシステムD-AMPS、又は何らかのその他のRAT、を実装することができる。GSM及びW-CDMAは、3rdGenerationPartnershipProject3GPPという名称のコンソーシアムからの文書で説明される。cdma2000は、3rdGenerationPartnershipProject23GPP2という名称のコンソーシアムからの文書で説明される。3GPP及び3GPP2の文書は公に入手可能である。WLANは、IEEE802.11xネットワークであることができ、及びWPANは、Bluetooth登録商標ネットワーク、IEEE802.15x、又は何らかのその他タイプのネットワークであることができる。それらの技法は、WWAN、WLAN及び/又はWPANのあらゆる組み合わせと関係させて実装することもできる。衛星測位システムSPSは、典型的には、エンティティが送信機から受信された信号に少なくとも部分的に基づいて地球上又は地球上方における自己の位置を決定するのを可能にするために配置された送信機のシステムを含む。該送信機は、典型的には、設定された数のチップの繰り返し擬似ランダム雑音PNコードで表示された信号を送信し、地上に基づく制御局、ユーザ装置及び/又は又は宇宙ビークル上に配置することができる。特定の例では、該送信機は、地球軌道周回衛星ビークルSV上に配置することができる。例えば、全地球航法衛星システム、例えば、全地球測位システムGPS、ガリレオ、グロナス又はコンパス、から成る一群内のSVは、例えば、GPSにおけるように各衛星に関して異なるPNコードを用いて又はグロナスにおけるように異なる周波数で同じコードを用いて一群内のその他のSVによって送信されたPNコードと区別することができるPNコードで表示された信号を送信することができる。幾つかの態様により、ここにおいて提示される技法は、SPSのためのグローバルシステム例えば、GNSSに制限されない。例えば、ここにおいて提供される技法は、様々な地域システム、例えば、日本上空の準天頂衛星システムQZSS、インド上空のインド地域航法衛星システムIRNSS、中国上空の北斗、等、及び/又は、1つ以上の全地球的な及び/又は地域の航法衛星システムと関連付けることができる又は1つ以上の全地球的な及び/又は地域の航法衛星システムとともに使用するために使用可能にすることができる様々な補強システム例えば、静止衛星型衛星航法補強システムSBAS、に適用することができ又は様々な地域システム、例えば、日本上空の準天頂衛星システムQZSS、インド上空のインド地域航法衛星システムIRNSS、中国上空の北斗、等、及び/又は、1つ以上の全地球的な及び/又は地域の航法衛星システムと関連付けることができる又は1つ以上の全地球的な及び/又は地域の航法衛星システムとともに使用するために使用可能にすることができる様々な補強システム例えば、静止衛星型衛星航法補強システムSBASにおいて使用するために使用可能にすることができる。一例として、ただし制限することなしに、SBASは、完全性情報、時間差補正、等を提供する補強システム、例えば、ワイドエリア補強システムWAAS、欧州静止衛星航法オーバーレイサービスEGNOS、運輸多目的衛星用衛星航法補強システムMSAS、GPS補助地球補強航法システム又はGPS及び地球補強航法システムGAGAN、等を含むことができる。従って、ここにおいて使用される場合において、SPSは、1つ以上の全地球的な及び/又は地域的な航法衛星システム及び/又は補強システムのあらゆる組み合わせを含むことができ、及び、SPS信号は、SPS、SPS類似、及び/又は該1つ以上のSPSと関連付けられたその他の信号を含むことができる。方法は、擬似衛星又は衛星と擬似衛星の組み合わせを利用する位置決定システムとともに使用することができる。擬似衛星は、Lハンド又はその他の手段は搬送波信号で変調されたGPS又はCDMAセルラー信号に類似するPNコード又はその他の測距コードをブロードキャストする地上をベースにした送信機であり、GSP時間と同期化することができる。各々の該送信機には、遠隔受信機による識別を可能にするために一意のPNコードを割り当てることができる。擬似衛星は、軌道周回衛星からの信号を入手不能な状況、例えば、トンネル、鉱山、建物、アーバンキャニオン又はその他の包囲されたエリア内、において有用である。擬似衛星のその他の実装は、ラジオビーコンと呼ばれる。ここにおいて用いられる場合の用語衛星は、擬似衛星と、擬似衛星の同等物と、その他と、を含むことが意図される。ここにおいて用いられる場合の用語SPS信号は、擬似衛星又は擬似衛星の同等物からのSPS類似信号を含むことが意図される。移動局例えば、MS又はSTAは、無線通信及び/又はナビゲーション信号を受信することが可能なデバイス、例えば、セルラー又はその他の無線通信デバイス、パーソナル通信システムPCSデバイス、パーソナルナビゲーションデバイスPND、パーソナル情報マネージャPIM、パーソナルデジタルアシスタントPDA、ラップトップ、タブレット、ネットブック、スマートブック又はその他の適切なモバイルデバイス、を意味する。用語移動局は、例えば、短距離無線接続、赤外線接続、有線接続、又はその他の接続によってパーソナルナビゲーションデバイスPNDと通信するデバイスを含むことも意図されており、衛星信号の受信、援助データの受信、及び/又は位置関連の処理がそのデバイス又はPNDで生じるかどうかを問わない。さらに、移動局は、例えば、インターネット、Wi-Fi、又はその他のネットワークを介して、サーバとの通信が可能である全デバイス、例えば、無線通信デバイス、コンピュータ、ラップトップ、等を含むことが意図され、、衛星信号の受信、援助データの受信、及び/又は位置関連の処理がそのデバイスにおいて、サーバにおいて、又はネットワークと関連付けられた他のデバイスにおいて生じるかどうかを問わない。上記のいずれの動作可能な組み合わせも、移動局とみなされる。用語移動局及びモバイルデバイスは、互換可能な形でしばしば使用される。本開示は、実施形態例を含む。しかしながら、その他の実装を使用可能である。何かが最適化される、要求されるとする指定又はその他の指定は、本開示が最適化されているシステム、又は要求される要素が存在するシステムのみに適用されるということ又はその他の指定に起因するその他の制限を示すものではない。これらの指定は、特定の説明される実施形態のみに言及する。当然のことであるが、数多くの実装が可能である。技法は、ここにおいて説明されるプロトコル以外のそれらとともに使用することができ、現在開発中の又は開発予定のプロトコルを含む。開示される実施形態に関する前の説明は、当業者が開示される実施形態を製造又は使用することを可能にするために提供される。これらの実施形態に対する様々な変更は、当業者にとって容易に明確になるであろう、及びここにおいて定められる一般原理は、本開示の適用範囲を逸脱せずにその他の実施形態に対しても適用することができる。以上のように、本開示は、ここにおいて示される実施形態に限定されることは意図されず、次の請求項によって定義される原理及び新規の特徴に一致する限りにおいて最も広範な適用範囲が認められるべきである。"