JP2013546260A - セキュアユーザプレーンロケーション（ｓｕｐｌ）システムにおける認証 - Google Patents
セキュアユーザプレーンロケーション（ｓｕｐｌ）システムにおける認証 Download PDFInfo
- Publication number
- JP2013546260A JP2013546260A JP2013537891A JP2013537891A JP2013546260A JP 2013546260 A JP2013546260 A JP 2013546260A JP 2013537891 A JP2013537891 A JP 2013537891A JP 2013537891 A JP2013537891 A JP 2013537891A JP 2013546260 A JP2013546260 A JP 2013546260A
- Authority
- JP
- Japan
- Prior art keywords
- supl
- mobile device
- slp
- message
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 claims abstract description 518
- 230000004044 response Effects 0.000 claims description 83
- 230000008569 process Effects 0.000 claims description 51
- 230000015654 memory Effects 0.000 claims description 48
- 230000000977 initiatory effect Effects 0.000 claims description 44
- 230000007246 mechanism Effects 0.000 description 51
- 230000001012 protector Effects 0.000 description 39
- 238000012545 processing Methods 0.000 description 36
- 238000004891 communication Methods 0.000 description 27
- 238000004422 calculation algorithm Methods 0.000 description 13
- 238000003860 storage Methods 0.000 description 12
- 238000012795 verification Methods 0.000 description 12
- 239000003795 chemical substances by application Substances 0.000 description 11
- 238000001514 detection method Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 9
- 230000003416 augmentation Effects 0.000 description 8
- 230000007774 longterm Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 230000008859 change Effects 0.000 description 7
- 230000001960 triggered effect Effects 0.000 description 7
- 230000001419 dependent effect Effects 0.000 description 6
- 238000007726 management method Methods 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 4
- 238000012790 confirmation Methods 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 230000001413 cellular effect Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 239000000463 material Substances 0.000 description 3
- 230000001105 regulatory effect Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000000717 retained effect Effects 0.000 description 2
- 238000012552 review Methods 0.000 description 2
- 150000003839 salts Chemical class 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 101000759879 Homo sapiens Tetraspanin-10 Proteins 0.000 description 1
- 108010007100 Pulmonary Surfactant-Associated Protein A Proteins 0.000 description 1
- 102100027773 Pulmonary surfactant-associated protein A2 Human genes 0.000 description 1
- 102100024990 Tetraspanin-10 Human genes 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000008275 binding mechanism Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000011010 flushing procedure Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008450 motivation Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 230000002787 reinforcement Effects 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
- H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
- H04W12/0431—Key distribution or pre-distribution; Key agreement
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
- H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/029—Location-based management or tracking services
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Power Engineering (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
特定の方法は、モバイルデバイスにおいて、モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納することを含む。方法は、デバイス識別子と格納されたデバイス識別子との比較に基づいてモバイルデバイスがセキュアユーザプレーンロケーション（ＳＵＰＬ）ユーザと関連付けられているとして認証するためにＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に少なくとも１つのセキュリティクレデンシャルを送信することも含む。開示される技法は、ＳＵＰＬサーバ及びＳＵＰＬによってイネーブルにされる端末ＳＥＴが複数の認証方法のうちのいずれが使用されべきかを交渉するのを可能にすることができる。
Description
本開示は、概して、セキュアユーザプレーンロケーション（ＳＵＰＬ）システムにおける認証に関するものである。
技術が進歩した結果としてコンピューティングデバイスがますます小型化しかつますます強力になってきている。例えば、現在では、小型、軽量、そしてユーザによる持ち運びが容易な無線コンピューティングデバイスを含む様々な携帯式のパーソナルコンピューティングデバイス、例えば、携帯式の無線電話、パーソナルデジタルアシスタント（ＰＤＡ）、及びページングデバイス、が存在する。より具体的には、携帯式の無線電話、例えば、携帯電話及びインターネットプロトコル（ＩＰ）電話、は、無線ネットワークを通じて音声パケット及びデータパケットを通信することができる。さらに、数多くの該無線電話は、それらに組み込まれているその他のタイプのデバイスを含む。例えば、無線電話は、デジタルスチルカメラと、デジタルビデオカメラと、デジタルレコーダと、オーディオファイルプレーヤーと、も含むことができる。
無線電話は、位置に基づくサービスを可能にするための位置決定ハードウェア／ソフトウェアも装備することができる。例えば、無線電話は、全地球測位システム（ＧＰＳ）トランシーバを含むことができる。無線電話は、ネットワークによって補助された測位情報を受信することもできる（例えば、測位情報に基づいて複数のネットワーク塔間の無線電話の位置の三角測量を行う）。
セキュアユーザプレーンロケーション（ｓｅｃｕｒｅ ｕｓｅｒ ｐｌａｎｅ ｌｏｃａｔｉｏｎ（ＳＵＰＬ））は、無線通信システムにおける位置に基づくサービスを可能にするために使用することができる技術規格である。ＳＵＰＬアーキテクチャは、２つの構成要素、すなわち、ＳＵＰＬによってイネーブルにされる端末（ＳＵＰＬＥ ｅｎａｂｌｅｄ ｔｅｒｍｉｎａｌ）（ＳＥＴ）及びネットワークによってアクセス可能なサーバとして実装することができるＳＵＰＬロケーションプラットフォーム（ＳＬＰ）、を含むことができる。ＳＵＰＬサービスを利用する前に、ＳＥＴ及び／又はＳＬＰが互いに認証することが要求される。しかしながら、ＳＵＰＬでのセキュリティ及び認証は、どのようなアクセスネットワークがＳＥＴによって使用されるかに依存することがある。例えば、３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（第３世代パートナーシッププロジェクト）（３ＧＰＰ）又は３ＧＰＰ２ネットワークでの認証は、Ｗｏｒｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（マイクロ波アクセスのための世界的相互運用性）（ＷｉＭＡＸ）での認証とは異なるセキュリティ方式を利用することができる。さらに、その他の利用可能なネットワーク、例えば、米国電気電子学会（ＩＥＥＥ）８０．１１（Ｗｉ−Ｆｉ）ネットワーク、の使用は、ＳＵＰＬ２．０において利用可能なセキュリティメカニズムによって完全にサポートされていないことがあり、それは、屋内に存在するか又はセルラーネットワーク状態が不良である無線電話がＳＵＰＬに基づく機能を利用するのを不能にすることがある。
ＳＵＰＬシステムにおける認証のシステム及び方法が開示される。開示されるシステム及び方法は、３ＧＰＰと、３ＧＰＰ２と、ＷｉＭＡＸと、Ｗｉ−Ｆｉネットワークと、を含む様々なアクセスネットワークに関するＳＥＴとＳＬＰとの間での相互認証をサポートすることができる。開示される技法は、ＳＵＰＬサーバ及びＳＥＴが、複数の認証方法のうちのいずれが使用されるべきかについて交渉するのを可能にすることができる。ここにおいて開示される認証方法は、アクセスネットワークタイプから独立した証明書に基づく認証を含み、ただし、アクセスネットワークタイプから独立した証明書に基づく認証に限定されない。特定の実装では、証明書に基づく認証は、認証中にＳＥＴとＳＬＰとの間でのセキュア（ｓｅｃｕｒｅ）な通信を可能にするためにトランスポート層セキュリティ（ＴＬＳ）を使用することができる。開示される技法は、ＳＵＰＬセッションの開始及び再開に対してもセキュリティを適用する。追加の実施形態では、認証は、証明書に基づく認証を介しての代わりに複数の識別子／パスワードの対を介して行うことができる。
特定の実施形態では、方法は、モバイルデバイスにおいて、モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャル（ｓｅｃｕｒｉｔｙ ｃｒｅｄｅｎｔｉａｌ）を格納することを含み、セキュリティクレデンシャルは、モバイルデバイスのデバイス識別子を含む。方法は、デバイス識別子と格納されたデバイス識別子との比較に基づいてモバイルデバイスがセキュアユーザプレーンロケーション（ＳＵＰＬ）ユーザと関連付けられているとして認証するためにＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に少なくとも１つのセキュリティクレデンシャルを送信することも含む。
他の特定の実施形態では、非一時的なプロセッサによって読み取り可能な媒体は、プロセッサによって実行されたときに、モバイルデバイスに送信されるべきメッセージをＳＵＰＬサーバにおいて生成することをプロセッサに行わせる命令を含む。メッセージは、ＳＵＰＬサーバの識別子とＳＵＰＬサーバの公開鍵とを含むサーバ証明書と、モバイルデバイスのデバイス証明書の要求とを含む。命令は、プロセッサによって実行されたときに、モバイルデバイスのデバイス証明書を含む応答をモバイルデバイスから受信することもプロセッサに行わせる。命令は、プロセッサによって実行されたときに、デバイス証明書に基づいてモバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証することをプロセッサにさらに行わせる。
他の特定の実施形態では、装置は、プロセッサと、プロセッサに結合されたメモリと、を含む。メモリは、モバイルデバイスによってサポートされる１つ以上のＴＬＳ暗号スイート（ｃｉｐｈｅｒ ｓｕｉｔｅ）（暗号の組）の表示（ｉｎｄｉｃａｔｉｏｎ）をモバイルデバイスからＳＵＰＬサーバにおいて受信するためにプロセッサによって実行可能な命令を格納する。命令は、１つ以上のＴＬＳ暗号スイートがＳＵＰＬサーバによってサポートされるＴＬＳ事前共有鍵（ＴＬＳ−ＰＳＫ）暗号スイートを含むかどうかを決定するためにもプロセッサによって実行可能である。命令は、１つ以上のＴＬＳ暗号スイートがＳＵＰＬサーバによってサポートされるＴＬＳ−ＰＳＫ暗号スイートを含むと決定したことに応答して、モバイルデバイスを認証するための汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく認証プロセスを実施するためにプロセッサによってさらに実行可能である。命令は、１つ以上のＴＬＳ暗号スイートがＳＵＰＬサーバによってサポートされるＴＬＳ−ＰＳＫ暗号スイートを含まないと決定したことに応答して、ＳＵＰＬサーバが証明書に基づく認証方法をサポートするかどうかを決定するためにプロセッサによって実行可能である。命令は、ＳＵＰＬサーバが証明書に基づく認証方法をサポートすると決定したことに応答して、モバイルデバイスにサーバ証明書を送信することとモバイルデバイスからデバイス証明書を受信することとを含む証明書に基づく認証プロセスを実施するためにもプロセッサによって実行可能である。命令は、ＳＵＰＬサーバが証明書に基づく認証方法をサポートしないと決定したことに応答して、モバイルデバイスが３ＧＰＰネットワーク又は３ＧＰＰ２ネットワークに接続されているときに代替クライアント認証（ＡＣＡ）に基づく認証方法を実施するためにプロセッサによってさらに実行可能であることができる。
他の特定の実施形態では、方法は、モバイルデバイスにおいて、ＳＵＰＬサーバとモバイルデバイスとの間でＳＵＰＬセッションを開始するためのセッション開始メッセージ（例えば、ＳＵＰＬ ＩＮＩＴメッセージを含む）をＳＵＰＬサーバから受信することを含む。方法は、モバイルデバイスがセッション開始メッセージを受信する前にモバイルデバイスがＳＵＰＬサーバから有効なセッション開始メッセージ鍵（例えば、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを含む）を受信したことに応答して、セッション開始メッセージ鍵を用いてセッション開始メッセージを認証することと、セッション開始メッセージの成功裏の認証に応答してＳＵＰＬサーバとのＳＵＰＬセッションを開始することと、も含む。
他の特定の実施形態では、装置は、プロセッサと、プロセッサに結合されたメモリと、を含む。メモリは、モバイルデバイスにおいて、ＳＵＰＬサーバとモバイルデバイスとの間でＳＵＰＬセッション（例えば、一般的ＳＵＰＬセッション（ＧＳＳ））を継続するためのセッション再開メッセージ（例えば、ＳＵＰＬ ＲＥＩＮＩＴメッセージを含む）をＳＵＰＬサーバから受信するためにプロセッサによって実行可能な命令を格納する。命令は、モバイルデバイスがセッション再開メッセージを受信する前にモバイルデバイスがＳＵＰＬサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、セッション開始メッセージ鍵を用いてセッション再開メッセージを認証し及びセッション再開メッセージの成功裏の認証に応答してＳＵＰＬサーバとのＳＵＰＬセッションを継続するためにプロセッサによって実行可能でもある。
他の特定の実施形態では、方法は、モバイルデバイスからＳＵＰＬサーバにメッセージを送信することを含み、メッセージは、（例えば、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの状態を示す）ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓ（ルートキー状態）パラメータを含む。例えば、ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータは、メッセージのＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓ（能力）パラメータに含めることができる。さらに他の実施形態では、方法は、ＳＵＰＬサーバからモバイルデバイスにＳＵＰＬ ＥＮＤメッセージを送信することを含み、ＳＵＰＬ ＥＮＤメッセージは、（例えば、新しいＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを提供する）ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅ（キー応答）パラメータを含む。他の特定の実施形態では、方法は、Ｐｒｏｔｅｃｔｉｏ Ｌｅｖｅｌ（保護レベル）パラメータを含むＳＵＰＬ ＩＮＩＴメッセージをＳＵＰＬサーバからモバイルデバイスに送信することを含む。さらに他の実施形態では、方法は、Ｐｒｏｔｅｃｔｉｏ Ｌｅｖｅｌパラメータを含むＳＵＰＬ ＲＥＩＮＩＴメッセージをＳＵＰＬサーバからモバイルデバイスに送信することを含む。
他の特定の実施形態では、方法は、ウェブサーバにおいて、ＳＵＰＬによってイネーブルにされるモバイルデバイスからのメッセージを受信することを含み、メッセージは、モバイルデバイスのセキュリティクレデンシャルを含む。方法は、ウェブサーバにおいて、モバイルデバイスからのユーザ識別情報を受信することと、ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証することと、も含む。方法は、モバイルデバイスがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするためにＳＵＰＬサーバにモバイルデバイスのセキュリティクレデンシャルを送信することをさらに含む。
他の特定の実施形態では、方法は、ＳＵＰＬサーバにおいて、モバイルデバイスから第１の識別子及び第１のパスワードを受信することを含む。例えば、第１の識別子及び第１のパスワードは、ユーザモードＴＬＳ認証手順中に受信することができる。方法は、第１の識別子及び第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証することも含む。方法は、第１の識別子及び第１のパスワードに取って代わるための第２の識別子及び第２のパスワードをモバイルデバイスに送信することをさらに含み、ＳＵＰＬサーバは、モバイルデバイスから第２の識別子及び第２のパスワードを受信した時点でモバイルデバイスとのＳＵＰＬセッションを確立するように構成される。
開示される実施形態のうちの少なくとも１つによって提供される特定の利点は、アクセスネットワークから独立してＳＵＰＬシステムで相互認証を行うことができることを含む。例えば、開示される実施形態のうちの１つ以上は、３ＧＰＰと、３ＧＰＰ２と、ＷｉＭＡＸと、Ｗｉ−Ｆｉネットワークとを含む様々なアクセスネットワークをサポートすることができる。他の例として、開示される実施形態のうちの１つ以上は、ＳＵＰＬセッションの開始及び再開にセキュリティを適用することができる。
次の節、すなわち、図面の簡単な説明、発明を実施するための形態、及び請求項、を含む本出願全体を再検討後に本開示のその他の態様、利点、及び特徴が明確になるであろう。
図１を参照し、セキュアユーザプレーンロケーション（ＳＵＰＬ）環境において認証を行うために動作可能であるシステムの特定の実施形態が示され、概して１００で表される。システム１００は、１つ以上のアクセスネットワーク（例えば、例示のためのアクセスネットワーク１３０）を介してモバイルデバイス１２０に通信可能な形で結合されたＳＵＰＬサーバ１１０を含む。特定の実施形態では、ＳＵＰＬサーバ１１０は、ＳＵＰＬロケーションプラットフォーム（ＳＬＰ）であることができ及びモバイルデバイス１２０はＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）であることができる。アクセスネットワーク１３０は、３ＧＰＰネットワーク、３ＧＰＰ２ネットワーク、ＷｉＭＡＸネットワーク、Ｗｉ−Ｆｉネットワーク（例えば、ＩＥＥＥ８０２．１１規格に準拠して動作するネットワーク）、又は何らかのその他の無線アクセスネットワークであることができる。特定の実施形態では、モバイルデバイス１２０は、無線電話であることができる。
ＳＵＰＬサーバ１１０は、プロセッサ１１１と、プロセッサ１１１に結合されたメモリ１１２と、を含む。特定の実施形態では、メモリ１２２は、プロセッサ１１１によって実行可能な命令を格納することができ、命令は、様々な論理的モジュール、コンポーネント、及びアプリケーションを表す。メモリ１１２は、ＳＵＰＬサーバ１１０の１つ以上のセキュリティクレデンシャルを格納することもできる。例えば、メモリ１１２は、ＳＵＰＬサーバ１１０のためのサーバ証明書１１３を格納することができ、サーバ証明書１１３は、公開鍵１１４と、サーバ識別子（ＩＤ）１１５（例えば、ＳＵＰＬサーバ１１０に対応するグローバルで一意の識別子）と、を含む。ＳＵＰＬサーバ１１０は、公開鍵１１４に対応する秘密鍵を有することもできる。メモリ１１２は、認証論理１１６及びトランスポート層セキュリティ（ＴＬＳ）暗号化／復号論理１１７に対応する実行可能な命令を格納することもできる。認証論理１１６は、モバイルデバイス１２０を認証するために実行可能であることができる。ＴＬＳ暗号化／復号論理１１７は、ＳＵＰＬサーバ１１０からモバイルデバイス１２０に送信されるメッセージを暗号化するために及びモバイルデバイス１２０からＳＵＰＬサーバ１１０に送信されたメッセージを復号するために実行可能であることができる。例えば、モバイルデバイス１２０からの発信メッセージは、サーバ公開鍵１１４を用いて暗号化することができ、モバイルデバイス１２０からの着信メッセージは、サーバ公開鍵１１４に対応する秘密鍵を用いて復号することができる。
モバイルデバイス１２０は、プロセッサ１２１と、プロセッサ１２１に結合されたメモリ１２２と、を含む。特定の実施形態では、メモリ１２２は、プロセッサ１２１によって実行可能な命令を格納し、命令は、様々な論理的モジュール、コンポーネント、及びアプリケーションを表すことができる。メモリ１２２は、モバイルデバイス１２０の１つ以上のセキュリティクレデンシャルを格納することもできる。例えば、メモリ１２２は、モバイルデバイス１２０のためのデバイス証明書１２３を格納することができ、デバイス証明書１２３は、公開鍵１２４と、デバイス識別子（ＩＤ）１２５と、を含む。モバイルデバイス１２０は、公開鍵１２４に対応する秘密鍵を有することもできる。デバイスＩＤ１２５は、国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、一連番号、又はグローバルで一意であることができるその他の識別子であることができる。特定の実施形態では、デバイス証明書１２３は、メモリ１２２の代わりに又はメモリ１２２に加えて、モバイルデバイス１２０のユニバーサル集積回路カード（ＵＩＣＣ）に格納することができる。メモリ１２２は、認証論理１２６及びトランスポート層セキュリティ（ＴＬＳ）暗号化／復号論理１２７に対応する実行可能な命令を格納することができる。認証論理１２６は、モバイルデバイス１２０でＳＵＰＬサーバ１１０を認証するために実行可能であることができる。ＴＬＳ暗号化／復号論理１２７は、モバイルデバイス１２０からＳＵＰＬサーバ１１０に送信されたメッセージを暗号化するために及びＳＵＰＬサーバ１１０からモバイルデバイス１２０に送信されたメッセージを復号するために実行可能であることができる。例えば、モバイルデバイス１２０からの発信メッセージは、デバイス公開鍵１２４を用いて暗号化することができ、モバイルデバイス１２０への着信メッセージは、デバイス公開鍵１２４に対応する秘密鍵を用いて復号することができる。
特定の実施形態では、ＳＵＰＬサーバ１１０及びモバイルデバイス１２０は、相互認証手順に従事することができる。例えば、動作中に、モバイルデバイス１２０における認証論理１２６は、モバイルデバイス１２０が汎用ブーストラッピングアーキテクチャ（ＧＢＡ）に基づく認証をサポートするかどうかを決定することができる。モバイルデバイス１２０がＧＢＡに基づく認証をサポートする場合は、モバイルデバイス１２０及びＳＵＰＬサーバ１１０は、ＧＢＡに基づく認証プロセス１３４を実施することができる。ＧＢＡに基づく認証は、アクセスネットワーク１３０が３ＧＰＰ又は３ＧＰＰ２ネットワークであるときに選択することができる。モバイルデバイス１２０は、ＳＵＰＬサーバ１１０にメッセージ１３１を送信することによってＴＬＳハンドシェイク手順を開始することができる。メッセージ１３１は、モバイルデバイス１２０においてＴＬＳ暗号化／復号論理１２７によってサポートされる１つ以上のＴＬＳ暗号スイートを示すことができる。例えば、メッセージ１３１は、ＣｌｉｅｎｔＨｅｌｌｏメッセージであることができ、サポートされるＴＬＳ暗号スイートは、ＣｌｉｅｎｔＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅｓフィールドによって示すことができる。
ＳＵＰＬサーバ１１０は、メッセージ１３１を処理し、示されているＴＬＳ暗号スイートのうちのいずれがＳＵＰＬサーバ１１０によって同じくサポートされているかどうか（すなわち、共通にサポートされるＴＬＳ暗号スイートが存在するかどうか）を決定することができる。モバイルデバイス１２０及びＳＵＰＬサーバ１１０の両方がＴＬＳの事前共有鍵（ＴＬＳ−ＰＳＫ）暗号スイートをサポートする場合は、ＧＢＡをサポートすることができ、及びＳＵＰＬサーバ１１０は、ＧＢＡに基づく認証プロセス１３４を実施することができる。そうでない場合は、ＳＵＰＬサーバ１１０は、メッセージ１３２を介して証明書に基づく認証を開始することができ又は代替クライアント認証（ＡＣＡ）を開始することができる。ＡＣＡは、相互認証を提供することができ、及び使用されるアクセスネットワークのタイプ（例えば、ＧＳＭ（登録商標）／ＵＭＴＳ及びＣＤＭＡ）に依存することができる。ＡＣＡ認証中には、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０によって提供されたＩＰアドレスをアクセスネットワーク１３０によって提供されるモバイルデバイス１２０に対応するＩＰアドレスと比較することによってモバイルデバイス１２０のインターネットプロトコル（ＩＰ）アドレスバインディング（ｂｉｎｄｉｎｇ）を検証することができる。証明書に基づく認証は、アクセスネットワーク１３０のタイプから独立していることができ及びアクセスネットワーク１３０がＷｉ−Ｆｉネットワークであるときに使用することができる。メッセージ１３２は、ＳＵＰＬサーバ１１０及びモバイルデバイス１２０によってサポートされる非ＰＳＫ ＴＬＳ暗号スイートの表示（ｉｎｄｉｃａｔｉｏｎ）と、（サーバ公開鍵１１４を含む）サーバ証明書１１３と、デバイス証明書要求と、を含むことができる。例示するために、メッセージ１３２は、共通してサポートされるＴＬＳ暗号スイートを示すＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅフィールドを含むＳｅｒｖｅｒＨｅｌｌｏメッセージを含むことができる。
メッセージ１３２に応答して、モバイルデバイス１２０は、デバイス証明書１２３を含むメッセージ１３３を送信することができる。ＳＵＰＬサーバ１１０は、デバイス証明書１２３内のデバイスＩＤ１２５を格納されたデバイスＩＤ（例えば、図８及び９を参照してさらに説明されるように、ＳＵＰＬユーザと関連付けられていることがＳＵＰＬサーバ１１０によって予めセキュアに検証されている格納されたデバイスＩＤ）と比較することによってモバイルデバイス１２０と関連付けられたＳＵＰＬユーザを識別するのを試みることができる。いずれのＳＵＰＬユーザも識別されない場合は、ＳＵＰＬサーバ１１０とモバイルデバイス１２０との間での通信セッションを終了させることができる。ＳＵＰＬユーザが識別される場合は、ＴＬＳハンドシェイクは完了することができ、ＳＵＰＬサーバ１１０は、ＳＵＰＬユーザのためにプロビジョニング（ｐｒｏｖｉｓｉｏｎｉｎｇ）されるＳＵＰＬに基づくサービス（例えば、位置に基づくサービス）へのアクセスをモバイルデバイス１２０に認めることができる。
特定の実施形態では、異なる認証方法も利用可能であることができる。例えば、モバイルデバイス１２０がＷｉＭＡＸと互換可能なデバイスであり及び／又はアクセスネットワーク１３０がＷｉＭＡＸネットワークであるときに、モバイルデバイス１２０及びＳＵＰＬサーバ１１０が両方ともＳＵＰＬ暗号化鍵（ＳＥＫ）に基づく認証方法をサポートする場合は、ＳＥＫに基づく認証方法が、ＳＵＰＬサーバ１１０及びモバイルデバイス１２０の相互認証にとってより好ましいことができる。他の例として、ＳＵＰＬサーバ１１０が証明書に基づく認証をサポートしない場合は、ＳＵＰＬサーバ１１０は、異なる認証方法、例えば、ＡＣＡ（モバイルデバイス１２０が３ＧＰＰ又は３ＧＰＰ２アクセスネットワーク上にあるときにアクセスネットワークに依存する相互認証を提供することができる）又はＳＬＰ専用認証（非相互認証を提供することができ及び緊急シナリオ中のみに概して使用することができる）、を開始するためにデバイス証明書を要求せずにメッセージ１３２を送信することができる。
このように、図１のシステム１００は、アクセスネットワークに依存しないでモバイルデバイスとＳＵＰＬサーバとの間での相互認証を可能にすることができる。例えば、アクセスネットワーク１３０は、３ＧＰＰネットワーク、３ＧＰＰ２ネットワーク、ＷｉＭＡＸネットワーク、Ｗｉ−Ｆｉネットワーク、又は何らかのその他のネットワークであることができる。図１のシステム１００は、複数の相互認証方法のためのサポートを提供することもでき、ＧＢＡに基づく認証と、ＳＥＫに基づく認証と、証明書に基づく認証と、ＡＣＡに基づく認証と、ＳＬＰ専用認証と、を含む。
図２を参照し、ＳＵＰＬ環境において認証方法を交渉する方法の特定の実施形態が示され、概して２００で表される。例示のための実施形態では、方法２００は、図１のＳＵＰＬサーバ１１０によって実施することができる。
方法２００は、２０２において、ＳＵＰＬサーバにおいて、モバイルデバイスによってサポートされる１つ以上のＴＬＳ暗号スイートの表示をモバイルデバイスから受信することを含むことができる。例えば、図１において、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０からメッセージ１３１を受信することができ、メッセージ１３１は、モバイルデバイス１２０によってサポートされる１つ以上のＴＬＳ暗号スイートを示す。
方法２００は、２０４において、モバイルデバイスによって示される少なくとも１つのＴＬＳ−ＰＳＫ暗号スイートがＳＵＰＬサーバによってもサポートされるかどうかを決定することを含むこともできる。例えば、図１において、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０によってサポートされるＴＬＳ−ＰＳＫ暗号スイートがＳＵＰＬサーバ１１０によってもサポートされるかどうかを決定することができる。
２０４において、ＴＬＳ−ＰＳＫ暗号スイートがＳＵＰＬサーバ及びモバイルデバイスによって共通してサポートされると決定したことに応答して、２０６において、モバイルデバイスを認証するためにＧＢＡに基づく認証プロセスを実施することができる。例えば、図１において、ＳＵＰＬサーバ１１０は、ＧＢＡに基づく認証手順１３４を実施することができる。２０４において、ＴＰＳ−ＰＳＫ暗号スイートがＳＵＰＬサーバ及びモバイルデバイスによって共通してサポートされていないと決定したことに応答して、２０８において、証明書に基づく認証プロセスを実施することができる。証明書に基づくプロセスは、モバイルデバイスにサーバ証明書を送信することと、モバイルデバイスからデバイス証明書を受信することと、を含むことができ、及び、モバイルデバイスによって使用されるアクセスネットワークから独立していることができる。例えば、図１において、ＳＵＰＬサーバ１１０は、メッセージ１３２を介してモバイルデバイス１２０にサーバ証明書１１３を送信することとメッセージ１３３を介してモバイルデバイス１２０からデバイス証明書１２３を受信することとを含む証明書に基づく認証手順を実施することができる。
特定の実施形態では、図２の方法２００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図２の方法２００は、命令を実行するプロセッサによって実施することができる。
図３を参照し、証明書を用いてＳＵＰＬ環境において認証を行う方法の特定の実施形態が示され、概して３００で表される。例示のための実施形態では、方法３００は、図１のモバイルデバイス１２０によって実施することができる。
方法３００は、３０２において、モバイルデバイスにおいて、モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納することを含むことができる。少なくとも１つのセキュリティクレデンシャルは、モバイルデバイスのデバイス識別子を含むことができる。例えば、図１において、モバイルデバイス１２０は、デバイスＩＤ１２５（例えば、ＩＭＥＩ、ＭＳＩＤ、一連番号、又は他のグローバルで一意の識別子）を含むデバイス証明書１２３を格納することができる。
方法３００は、３０４において、デバイス識別子と格納されたデバイス識別子の比較に基づいてモバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証するために少なくとも１つのセキュリティクレデンシャルをＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に送信することを含むこともできる。例えば、図１において、モバイルデバイス１２０は、デバイスＩＤ１２５と他のエンティティによって予め提供された格納されたデバイスＩＤの比較に基づいてモバイルデバイス１２０がＳＵＰＬユーザと関連付けられているとしてＳＵＰＬサーバ１１０が認証できるようにメッセージ１３３を介してＳＵＰＬサーバ１１０（例えば、ＳＬＰ）にデバイス証明書１２３を送信することができる。
特定の実施形態では、図３の方法３００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図３の方法３００は、命令を実行するプロセッサによって実施することができる。
図４を参照し、証明書を用いてＳＵＰＬ環境において認証を行う方法の他の特定の実施形態が示され、概して４００で表される。例示のための実施形態では、方法４００は、図１のＳＵＰＬサーバ１１０によって実施することができる。
方法４００は、４０２において、ＳＵＰＬサーバにおいて、モバイルデバイスによってサポートされる１つ以上のＴＬＳ暗号スイートの表示をモバイルデバイスから受信することを含むことができる。例えば、図1において、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０からメッセージ１３１を受信することができ、メッセージ１３１は、モバイルデバイス１２０によってサポートされる１つ以上のＴＬＳ暗号スイートを示す。
方法４００は、４０４において、ＳＵＰＬサーバからモバイルデバイスにメッセージを送信することを含むこともできる。メッセージは、ＳＵＰＬサーバの識別子とＳＵＰＬサーバの公開鍵とを含むサーバ証明書と、モバイルデバイスのデバイス証明書の要求と、ＴＬＳ暗号スイートのうちの少なくとも１つの選択と、を含むことができる。例えば、図１において、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０にメッセージ１３２を送信することができ、メッセージ１３２は、サーバＩＤ１１５と、サーバ公開鍵１１４と、モバイルデバイス１２０のデバイス証明書１２３の要求と、共通してサポートされるＴＬＳ暗号スイートの選択と、を含む。
方法４００は、４０６において、モバイルデバイスのデバイス証明書を含む応答をモバイルデバイスから受信することをさらに含むことができる。例えば、図１において、ＳＵＰＬサーバ１１０は、デバイス証明書１２３を含むメッセージ１３３を受信することができる。
方法４００は、４０８において、デバイス証明書に基づいてモバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証することを含むことができる。例えば、図１において、ＳＵＰＬサーバ１１０の認証論理１１６は、デバイス証明書１２３に基づいてモバイルデバイス１２０がＳＵＰＬユーザと関連付けられているとして認証することができる。
特定の実施形態では、図４の方法４００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図４の方法４００は、命令を実行するプロセッサによって実施することができる。
図１乃至４を参照して説明されるいずれの認証方法が使用されるかにかかわらず、いったん認証が完了した時点で、ＳＵＰＬサーバ（例えば、ＳＬＰ）及びモバイルデバイス（例えば、ＳＥＴ）は、ＳＵＰＬセッション中にＳＵＰＬに基づくサービスに関して通信することができる。図５を参照し、ＳＵＰＬサーバ５１０とモバイルデバイス５２０との間でやり取りすることができるメッセージの特定の実施形態が示され、概して５００で示される。
特定の実施形態では、ＳＵＰＬサーバ５１０及びモバイルデバイス５２０は、ＳＵＰＬセッションのコンテキストでユーザロケーションプロトコル（ＵＬＰ）メッセージを介して通信することができる。例えば、ＳＵＰＬサーバ５１０は、モバイルデバイス５２０にＳＵＰＬ ＩＮＩＴメッセージ５３０を送信するように構成することができる。ＳＵＰＬ ＩＮＩＴメッセージ５３０は、ＳＵＰＬセッションを開始するためにＳＵＰＬサーバ１１０によって送信されるセッション開始メッセージを表すことができる。なりすまし及びリプレイ攻撃から保護するために、ＳＵＰＬ ＩＮＩＴメッセージ５３０に対して保護を適用することができる。特定の実施形態では、ＳＵＰＬ ＩＮＩＴメッセージ５３０は、Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータを含むことができる。Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータは、Ｌｅｖｅｌパラメータ（Ｎｕｌｌ、Ｍｏｄｅ Ａ、又はＭｏｄｅ Ｂ ＳＵＰＬ ＩＮＩＴ保護のいずれが実装されるかを示す）及びＰｒｏｔｅｃｔｉｏｎパラメータ（例えば、鍵識別子タイプ及び鍵識別子のうちの少なくとも１つを含む）のうちの少なくとも１つを含むことができる。特定の実施形態では、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護は、エンド・ツー・エンドの完全性もリプレイ保護も提供することができず、Ｍｏｄｅ Ａ ＳＵＰＬ ＩＮＩＴ保護は、セキュリティが確保されたＵＬＰセッション中にＳＵＰＬサーバ５１０によってモバイルデバイス５２０に送信される共有鍵の使用によってエンド・ツー・エンドの完全性及びリプレイ保護を提供することができ、Ｍｏｄｅ Ｂ ＳＵＰＬ ＩＮＩＴ保護は、ＰＳＫに基づく方法（例えば、ＧＢＡ又はＳＥＫ方法）から導き出された共有鍵を用いてエンド・ツー・エンドの完全性及びリプレイ保護を提供することができる。
特定の実施形態では、ＳＵＰＬ ＩＮＩＴ保護は、セッション開始鍵（例えば、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）に基づいて実装することができる。ＳＵＰＬ ＩＮＩＴメッセージ５３０を受信した時点で、モバイルデバイス５２０は、モバイルデバイス５２０がＳＵＰＬサーバ５１０から有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを以前に受信しているかどうかを決定することができ、そうである場合は、以前に受信されたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは依然として有効であるかどうかを決定することができる。モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、モバイルデバイス５２０は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いてＳＵＰＬ ＩＮＩＴメッセージ５３０を認証することができ及びＳＵＰＬ ＩＮＩＴメッセージ５３０の成功裏の認証に応答してＳＵＰＬサーバ５１０とＳＵＰＬセッションを開始することができる。
特定の実施形態では、モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない場合は、モバイルデバイス５２０は、ＳＵＰＬサーバ５１０にメッセージを送信することができ及びそのメッセージに応答して有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを受信することができる。例えば、モバイルデバイス５２０は、有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの要求を表すＳＵＰＬ_ＩＮＩＴ_ＫｅｙＲｅｑｕｅｓｔパラメータを含むメッセージを送信することができる。代替として、モバイルデバイス５２０は、新しいＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを要求する代わりに無効な又は同期外れのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの存在を示すことができる。例えば、モバイルデバイス５２０は、モバイルデバイス５２０によって所有される“現在の” ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが無効又は同期外れであるかどうかを示すＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータ５４１を含むＵＬＰメッセージ５４０を送信することができる。特定の実施形態では、ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータ５４１は、ＵＬＰメッセージ５４０のＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含めることができる。ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータ５４１をＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含めることは、ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ状態情報を送信するための専用メッセージを導入する必要なしにＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓパラメータを任意選択的に又は強制的に含むＳＵＰＬ２．０内で定義されたメッセージでのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ状態情報の送信を可能にすることができることが理解されるであろう。特定の実施形態では、ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータ５４１は、Ｍｏｄｅ Ａ ＳＵＰＬ ＩＮＩＴ保護のためにＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含めることができるが、ＮＵＬＬ保護又はＭｏｄｅ Ｂ ＳＵＰＬ ＩＮＩＴ保護のためにＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含めることはできない。
モバイルデバイス５２０は、すべてのネットワークによって開始されるＳＵＰＬセッションのために有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを示すことはできないことが注目されるべきである。モバイルデバイス５２０には、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを１回提供しておくことができ、提供された鍵は、その鍵が期限切れになる前は複数のネットワークによって開始されるＳＵＰＬセッションに関して有効であることができる。
ＳＵＰＬサーバ５１０は、ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅパラメータを含むＵＬＰメッセージを送信することができる。例えば、ＳＵＰＬサーバ５１０は、ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅパラメータ５５１を含むＳＵＰＬ ＥＮＤメッセージ５５０を送信することができる。ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅは、ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓ表示に直接応答して送信することはできず、ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅは、同じＳＵＰＬセッション内にあることができない“正規の”ＳＵＰＬ ＥＮＤメッセージ内に存在することができることが注目されるべきである（例えば、ＳＵＰＬセッションがＳＬＰからＳＥＴへのＳＵＰＬ ＥＮＤメッセージによって終了されない場合）。ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅパラメータ５５１は、モードＡ鍵識別子、一時的モードＡ鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ（例えば、“新しい”ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）、及びモードＡ鍵寿命のうちの少なくとも１つを含むことができる。
一般的ＳＵＰＬセッション（ＧＳＳ）がアクティブである間は、ＳＬＰ（すなわち、ＳＵＰＬサーバ５１０）は、ＳＥＴ（すなわち、モバイルデバイス５２０）との通信を開始することができる。ＳＵＰＬサーバ５１０は、セッション再開メッセージ（例えば、ＳＵＰＬ ＲＥＩＮＩＴメッセージ５６０）を送信することができる。ＳＵＰＬ ＲＥＩＮＩＴ保護は、ＳＵＰＬ ＲＥＩＮＩＴ保護を参照してここにおいて説明されるように実装することができる。例えば、モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを所有していない場合は（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、セッション開始鍵及びセッション再開鍵の両方として機能することができる）、モバイルデバイス５２０は、ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータ５４１を介して有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが存在しないことを示すことができ、応答して、ＳＵＰＬ ＥＮＤメッセージ５５０（ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅパラメータ５５１を含む）を受信することができる。モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するときには、モバイルデバイス５２０は、ＳＵＰＬ ＲＥＩＮＩＴメッセージ５６０を認証することができ及びＳＵＰＬ ＲＥＩＮＩＴメッセージ５６０の成功裏の認証に応答してＳＵＰＬサーバ５１０とのＳＵＰＬセッションを再開することができる。特定の実施形態では、ＳＵＰＬ ＲＥＩＮＩＴメッセージ５６０は、ＳＵＰＬ ＩＮＩＴメッセージ５３０を参照してここにおいて説明されるように、Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータを含むこともできる。
特定の実施形態では、モバイルデバイス５２０は、モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さないとき（例えば、パワーアップ時又は所有されるＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの寿命が経過しているとき）にはＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護及びＮｕｌｌ ＳＵＰＬ ＲＥＩＮＩＴ保護を適用することができる。Ｎｕｌｌ保護が設定されているときには、モバイルデバイス５２０は、すべてのＳＵＰＬ ＩＮＩＴメッセージ及びＳＵＰＬ ＲＥＩＮＩＴメッセージを処理することができる。モバイルデバイス５２０が有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、ＭｏｄｅＡ又はＭｏｄｅＢ保護を適用することができる。
図５において例示されるように、ＳＵＰＬシステムにおいてセキュリティを実装するために様々なメッセージ及びメッセージパラメータを用いることができる。例えば、ＳＵＰＬ ＩＮＩＴ及びＳＵＰＬ ＲＥＩＮＩＴ保護のレベルを示すためにＰｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータを用いることができる。他の例として、現在のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが無効又は同期外れであるかどうかを示すためにＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータを使用することができる。さらに他の例として、“新しい” ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを提供するためにＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅパラメータを用いることができる。
図６を参照し、ＳＵＰＬ環境におけるセッション開始中の認証の方法の特定の実施形態が示され、概して６００で表される。例示のための実施形態において、方法６００は、図５のモバイルデバイス５２０によって実施することができる。
方法６００は、６０２において、セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバとモバイルデバイスとの間でのＳＵＰＬセッションを開始するためにＳＵＰＬサーバからのセッション開始メッセージをモバイルデバイスにおいて受信することを含むことができる。例えば、図５では、モバイルデバイス５２０は、ＳＵＰＬサーバ５１０からＳＵＰＬ ＩＮＩＴメッセージ５３０を受信することができる。
方法６００は、６０４において、モバイルデバイスがセッション開始メッセージを受信する前に有効なセッション開始メッセージ鍵を受信したかどうかを決定することを含むこともできる。例えば、図５では、モバイルデバイス５２０は、それが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを所有するかどうかを決定することができる。
モバイルデバイスが有効なセッション開始メッセージ鍵を有するときには、方法６００は、６０６において、セッション開始メッセージ鍵（例えば、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を用いてセッション開始メッセージを認証することと、６０８において、セッション開始メッセージの成功裏の認証に応答してＳＵＰＬサーバとのＳＵＰＬセッションを開始することと、をさらに含むことができる。例えば、図５において、モバイルデバイス５２０は、有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いてＳＵＰＬ ＩＮＩＴメッセージ５３０を認証することができ及びＳＵＰＬサーバ５１０とのＳＵＰＬセッションを開始することができる。
モバイルデバイスが有効なセッション開始メッセージ鍵を有さないときには、方法６００は、６１０において、ＳＵＰＬサーバにメッセージを送信することと、６１２において、そのメッセージに応答してＳＵＰＬサーバからセッション開始メッセージ鍵を受信することと、を含むことができる。例示することを目的として、ＳＬＰ及びＳＥＴは、ＮＵＬＬ ＳＵＰＬ ＩＮＩＴ保護を用いてセッションを行うことができ、ＳＥＴは、それのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが無効であることの表示をセッション中に送信することができる。例えば、図５において、モバイルデバイス５２０は、ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータ５４１を含むメッセージをＳＵＰＬサーバ５１０に送信することができ及び応答してＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅパラメータ５５１を含むメッセージを受信することができる。
特定の実施形態では、図６の方法６００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図６の方法６００は、命令を実行するプロセッサによって実施することができる。
図７を参照し、ＳＵＰＬ環境におけるセッション再開中の認証の方法の特定の実施形態が示され、概して７００で表される。例示のための実施形態では、方法７００は、図５のモバイルデバイス５２０によって実施することができる。
方法７００は、７０２において、モバイルデバイスにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバとモバイルデバイスとの間でのＳＵＰＬセッションを継続するためのＳＵＰＬサーバからのセッション再開メッセージを受信することを含むことができる。例えば、図５において、モバイルデバイス５２０は、ＳＵＰＬサーバ５１０からＳＵＰＬ ＲＥＩＮＩＴメッセージ５６０を受信することができる。ＳＵＰＬ ＲＥＩＮＩＴメッセージ５６０は、ＳＵＰＬサーバ５１０とモバイルデバイス５２０との間での既存の一般的なＳＵＰＬセッション（ＧＳＳ）を継続することのネットワークによって開始された試行を表すことができる。
方法７００は、７０４において、モバイルデバイスがセッション再開メッセージを受信する前に有効なセッション開始メッセージ鍵を受信したかどうかを決定することも含むこともできる。例えば、図５において、モバイルデバイス５２０は、それが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを所有するかどうかを決定することができる。
モバイルデバイスが有効なセッション開始メッセージ鍵を有する場合は、方法７００は、７０６において、セッション開始メッセージ鍵を用いてセッション再開メッセージを認証することと、７０８において、セッション再開メッセージの成功裏の認証に応答してＳＵＰＬサーバとのＳＵＰＬセッションを継続することと、をさらに含むことができる。例えば、図５において、モバイルデバイス５２０は、有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いてＳＵＰＬ ＲＥＩＮＩＴメッセージ５６０を認証することができ及びＳＵＰＬサーバ５１０とのＳＵＰＬセッションを再開することができる。
モバイルデバイスが有効なセッション開始メッセージ鍵を有さないときには、方法７００は、７１０において、ＳＵＰＬサーバにメッセージを送信することと、７１２において、そのメッセージに応答してＳＵＰＬサーバからセッション開始メッセージ鍵を受信することと、を含むことができる。例示することを目的として、ＳＬＰ及びＳＥＴは、ＮＵＬＬ ＳＵＰＬ ＩＮＩＴ保護を用いてセッションを行うことができ、ＳＥＴは、それのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが無効であることの表示をセッション中に送信することができる。例えば、図５において、モバイルデバイス５２０は、ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータ５４１を含むメッセージをＳＵＰＬサーバ５１０に送信することができ及び応答してＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅパラメータ５５１を含むメッセージを受信することができる。
特定の実施形態では、図７の方法７００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図７の方法７００は、命令を実行するプロセッサによって実施することができる。
特定の実施形態では、証明書に基づく方法、ＧＢＡに基づく方法、ＳＥＫに基づく方法、ＡＣＡに基づく方法、及びＳＬＰ専用の方法以外の方法を介してモバイルデバイスとＳＵＰＬサーバとの間での相互認証を実施することができる。例えば、図８は、複数の識別子／パスワードを用いてＳＵＰＬ環境において認証を実施するために動作可能なシステム８００の特定の実施形態を例示する。システム８００は、ＳＵＰＬサーバ（例えば、ＳＬＰ）８２０と通信することが可能なモバイルデバイス８１０（例えば、ＳＥＴ）を含む。
複数の識別子／パスワードに基づく認証に加えて、図８のシステム８００は、ＳＵＰＬユーザにデバイス証明書をバインド（ｂｉｎｄ）させる特定の例も示す。例えば、システム８００は、デバイス証明書とＳＵＰＬユーザとの間でのバインディングを生成するためのメカニズムを提供するためのウェブサーバ８３０を含むことができる。ウェブサーバ８３０は、ＳＵＰＬセッションのための認証を提供することはできず、むしろ、ＳＵＰＬ認証中にＳＬＰによってのちに用いることができるバインディング情報を提供することができる。このバインディングは、典型的には１回だけ行うことができ、及び、ＳＥＴがＳＵＰＬセッションに従事することができる前に行うことができる。バインディングが行われた時点で、デバイス証明書とユーザ情報の組み合わせをＳＬＰに送信することができ、ＳＬＰは、この情報を格納してクライアント認証のために使用することができる。バインディングが行われた後は、ＳＬＰは、あるモバイルデバイスが特定のＳＵＰＬユーザに属することを“知る”ことができる。ウェブサーバ８３０は、プロセッサ８３１と、プロセッサ８３１によって実行可能な命令を格納するメモリ８３２と、を含むことができる。例えば、命令は、認証論理８３３を表すことができる。ウェブサーバ８３０は、モバイルデバイス８１０と及びＳＵＰＬサーバ８２０と通信するために動作可能なネットワークインタフェース８３４を含むこともできる。ウェブサーバ８３０は、ユーザへのデバイス証明書のバインディングを提供する方法を示す一例であるにすぎないことが注目されるべきである。その他の実施形態では、その他のバインディングメカニズムを使用することができる。代替として、ウェブサーバ８３０は、デバイス証明書とユーザ情報の組み合わせを格納することができ、及び、ＳＬＰは、（デバイス証明書を用いたデバイスの相互認証を行った時点で）そのデバイス証明書と関連付けられたユーザ情報を提供するようにウェブサーバ８３０に要求することができる。
モバイルデバイス８１０は、認証論理８１１（例えば、モバイルデバイス８１０のメモリに格納され、モバイルデバイス８１０のプロセッサによって実行可能な命令）を含むことができる。認証論理８１１は、モバイルデバイス８１０を特定のＳＵＰＬユーザと関連付ける（“バインドする”又は“登録する”）ためにウェブサーバ８３０において対応する認証論理８３３と通信するように構成することができる。例えば、バインディングプロセスは、モバイルデバイス８１０がウェブサーバ８３０からメッセージ８３５を受信することから開始することができ、メッセージ８３５は、ウェブサーバ８３０のサーバ証明書と、ウェブサーバ８３０の公開鍵と、を含む。モバイルデバイス８１０は、ウェブサーバ８３０にメッセージ８１３を送信することによって応答することができ、メッセージ８１３は、モバイルデバイス８１０のセキュリティクレデンシャルを含む。例えば、モバイルデバイス８１０のセキュリティクレデンシャルは、モバイルデバイス８１０の公開鍵、国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び／又は一連番号を含むデバイス証明書を含むことができる。モバイルデバイス８１０は、ウェブサーバ８３０にユーザ識別情報（例えば、ＳＵＰＬユーザと関連付けられたユーザ識別子及びパスワード）を含むメッセージ８１４を送信することもできる。メッセージ８１３、８１４のうちの１つ又は両方は、ウェブサーバ８３０の公開鍵を用いて暗号化することができ、ウェブサーバ８３０は、ウェブサーバ８３０の秘密鍵を用いて暗号化されたメッセージを復号することができる。
ウェブサーバ８３０は、モバイルデバイス８１０によって提供されたユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザと関連付けられているかどうかを決定するためにユーザ識別情報を認証することができる。例えば、ウェブサーバ８３０は、提供されたユーザ識別情報を、ウェブサーバ８３０に所在する又はウェブサーバ８３０にとってアクセス可能なＳＵＰＬユーザデータベースと比較することができる。ユーザ識別情報を検証した時点で、ウェブサーバ８３０は、モバイルデバイス８１０がＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証するためのメッセージ８３６をＳＵＰＬサーバ８２０に送信することによってバインディングプロセスを完了することができる。メッセージ８３６は、モバイルデバイス８１０のセキュリティクレデンシャル（例えば、デバイス公開鍵、ＩＭＥＩ、ＭＳＩＤ、及び／又は一連番号を含むデバイス証明書）を含むことができる。
モバイルデバイス８１０の認証論理８１１は、ＳＵＰＬセッションの開始又は再開前にユーザモードＴＬＳに基づく相互認証を行うためにＳＵＰＬサーバ８２０の対応する認証論理８２１と通信するように構成することもできる。例えば、モバイルデバイス８１０は、ＳＵＰＬサーバ８２０にメッセージ８１５を送信することができ、メッセージ８１５は、第１の識別子と第１のパスワードとを含む。特定の実施形態では、第１のパスワードは、ユーザによって選択することができ、及び、相対的に弱い暗号強度を有することができる。例示するための実施形態では、第１の識別子及び第１のパスワードは、メッセージ８１４を介してモバイルデバイス８１０によってウェブサーバ８３０に送信される識別子及びパスワードに対応することができる。
第１の識別子及び第１のパスワードを受信した時点で、認証論理８２１は、第１の識別子及び第１のパスワードがＳＵＰＬサーバの権限が付与されたユーザと関連付けられているとして認証することができる。例えば、認証論理８２１は、第１の識別子及び第１のパスワードがモバイルデバイス８１０に以前にバインディングされた権限が付与されたユーザに対応することを検証することができる。認証に成功したときには、ＳＵＰＬサーバ８２０の識別子／パスワード生成論理８２２は、第１の識別子及び第１のパスワードに取って代わるための第２の識別子及び第２のパスワードを生成することができる。特定の実施形態では、第２のパスワードは、第１のパスワードよりも高い暗号強度を有することができる。ＳＵＰＬサーバ８２０は、メッセージ８２４を介してモバイルデバイス８１０に第２の識別子及び第２のパスワードを送信することができる。モバイルデバイス８１０から第２の識別子及び第２のパスワードを後続して受信した時点で、ＳＵＰＬサーバ８２０は、モバイルデバイス８１０とのセッションを確立することができる。特定の実施形態では、第２の識別子及び第２のパスワードは、セキュリティ上の目的でモバイルデバイス８１０のユーザから隠した状態にすることができる。
上記の説明は、ＳＵＰＬユーザが単一のモバイルデバイス（例えば、ＳＥＴ）と関連付けられていることに関するものであるが、ＳＵＰＬユーザは、複数のデバイスと関連付けることができる。例えば、モバイルデバイス８１０と関連付けられたＳＵＰＬユーザは、第２のモバイルデバイス８４０へのアクセスも有することができる。第２のモバイルデバイス８４０に権限を付与するために、ＳＵＰＬユーザは、第１のモバイルデバイス８１０をバインドさせるのと同様の方法で第２のモバイルデバイス８４０を自己のアカウント（例えば、ＳＵＰＬアカウント）にバインドさせることができる。第２のモバイルデバイス８４０がＳＵＰＬユーザのアカウントにバインドされた後に相互認証を行うために、第２のモバイルデバイス８４０は、第１の識別子と第１のパスワードを含むメッセージ８４１をＳＵＰＬサーバ８２０に送信することができる。第１の識別子及び第１のパスワードが権限が付与されたＳＵＰＬユーザと関連付けられているとして認証した時点で、ＳＵＰＬサーバ８２０は、第２のモバイルデバイス８４０にもＳＵＰＬサービスへのアクセスが許可されるべきかどうかを決定することができる。例えば、ＳＵＰＬサーバ８２０は、ユーザ当たりのデバイス数に関する制限を実装することができ及び第２のモバイルデバイス８４０がＳＵＰＬサービスにアクセスするのを許容することがＳＵＰＬサービスにアクセスすることが許可された権限が付与されたユーザと関連付けられたモバイルのスレショルド数を超えるかどうかを決定することができる。第２のモバイルデバイス８４０がＳＵＰＬサービスにアクセスするのを許容することがスレショルドを超えない場合は、ＳＵＰＬサーバ８２０は、第３の識別子と暗号的に強力な第３のパスワードとを含むメッセージ８２５を第２のモバイルデバイス８４０に送信することができる。第３の識別子及び第３のパスワードが第１の識別子及び第１のパスワードに取って代わることができ、及び、ＳＵＰＬセッションを開始するために第２のモバイルデバイス８４０によって引き続いて使用することができる。
特定の実施形態では、第３の識別子及び第３のパスワードは、第１のモバイルデバイス８１０に送信された第２の識別子及び第２のパスワードと別個であることができる。別個の識別子／パスワードの組み合わせをＳＵＰＬユーザの各モバイルデバイスに提供することによって、ＳＵＰＬサーバ８２０は、１つのデバイスごとのモニタリングを実装することができる。例えば、ＳＵＰＬサーバ８２０のモニタリング論理８２３は、第２の識別子を用いて第１のモバイルデバイス８１０によるＳＵＰＬサービスの使用をモニタリングするように及び第３の識別子を用いて第２のモバイルデバイス８４０によるＳＵＰＬサービスの使用をモニタリングするように構成することができる。
図８のシステム８００は、１つ以上のモバイルデバイスを特定のＳＵＰＬユーザとバインドさせる、登録する、及び／又は関連付けることができるバインディングプロセスを提供することができる。説明されるバインディングプロセスは、図１乃至４を参照して説明される認証プロセスを選択的に補足できることが理解されるだろう。例えば、図１を参照して説明されるように、ＳＵＰＬサーバ１１０は、モバイルデバイス１２０のデバイスＩＤ １２５をＳＵＰＬユーザによって以前にセキュアに検証された格納されたデバイスＩＤと比較することによってＳＵＰＬユーザがモバイルデバイスと関連付けられているとして識別することを試みることができる。例示のための実施形態では、図１のＳＵＰＬサーバ１１０は、ＳＵＰＬサーバ８２０であることができ、図１のモバイルデバイス１２０は、モバイルデバイス８１０であることができ、格納されたデバイスＩＤは、バインディングプロセス中にメッセージ８３６を介してＳＵＰＬサーバ８２０に提供されるデバイスセキュリティクレデンシャル内に含めることができる。
さらに、図８のシステム８００は、図１乃至４を参照して説明される認証プロセスに選択的に取って代わることができる認証プロセスを提供することができる。例えば、特定の実施形態は、ＧＢＡに基づく相互認証、ＳＥＫに基づく相互認証、及び／又は証明書に基づく相互認証の代わりに図８の複数の識別子／パスワードの認証プロセスを用いることを含むことができる。
図９を参照し、ウェブサーバを用いたＳＵＰＬ環境における認証の方法の特定の実施形態が示され、概して９００で表される。例示のための実施形態では、方法９００は、図８のウェブサーバ８３０によって実施することができる。
方法９００は、９０２において、ウェブサーバからＳＵＰＬによってイネーブルにされるモバイルデバイスにサーバ証明書を送信することを含むことができる。サーバ証明書は、ウェブサーバの公開鍵を含むことができる。例えば、図８において、ウェブサーバ８３０は、モバイルデバイス８１０にメッセージ８３５を送信することができ、メッセージ８３５は、ウェブサーバ８３０の証明書と公開鍵とを含む。
方法９００は、９０４において、モバイルデバイスのセキュリティクレデンシャルを含むモバイルデバイスからのメッセージをウェブサーバにおいて受信することを含むこともできる。例えば、図８において、ウェブサーバ８３０は、モバイルデバイス８１０からメッセージ８１３を受信することができ、メッセージ８１３は、モバイルデバイス８１０のセキュリティクレデンシャル（例えば、デバイス証明書及びデバイス公開鍵）を含む。
方法９００は、９０６において、ウェブサーバの秘密鍵を用いてメッセージを復号することと、９０８において、モバイルデバイスからユーザ識別情報を受信することと、をさらに含むことができる。例えば、図８において、ウェブサーバ８３０は、秘密鍵を用いてメッセージ８１３を復号することができ及びメッセージ８１４を介してモバイルデバイス８１０からユーザ識別情報（例えば、識別子及びパスワード）を受信することができる。代替として、又はさらに加えて、ユーザ識別情報は、ウェブサーバの秘密鍵を用いて復号することもできる。
方法９００は、９１０において、ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証することと、９１２において、モバイルデバイスがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするためにモバイルデバイスのセキュリティクレデンシャルをＳＵＰＬサーバに送信することと、を含むことができる。例えば、図８において、ウェブサーバ８３０は、ユーザ識別情報が権限が付与されたＳＵＰＬユーザを識別しているとして認証することができ及びメッセージ８３６を介してＳＵＰＬサーバ８２０にデバイスセキュリティクレデンシャルを送信することができる。
特定の実施形態では、図９の方法９００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図９の方法９００は、命令を実行するプロセッサによって実施することができる。
図１０を参照し、複数の識別子／パスワードを用いたＳＵＰＬ環境における認証の方法の特定の実施形態が示され、概して１０００で表される。例示するための実施形態において、方法１０００は、図８のＳＵＰＬサーバ８２０によって実施することができる。
方法１０００は、１００２において、モバイルデバイスから第１の識別子及び第１のパスワードをＳＵＰＬサーバにおいて受信することと、１００４において、第１の識別子及び第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証することと、を含むことができる。例えば、図８において、ＳＵＰＬサーバ８２０は、メッセージ８１５を介してモバイルデバイス８１０から第１の識別子及び第１のパスワードを受信することができ、及び、第１の識別子及び第１のパスワードが権限が付与されたユーザ（例えば、以前にモバイルデバイス８１０にバインドされた権限が付与されたユーザ）と関連付けられているとして認証することができる。
方法１０００は、１００６において、第１の識別子及び第１のパスワードに取って代わるための第２の識別子及び第２のパスワードをモバイルデバイスに送信することも含むことができる。ＳＵＰＬサーバは、モバイルデバイスから第２の識別子及び第２のパスワードを受信した時点でモバイルデバイスとＳＵＰＬセッションを確立するように構成することができる。例えば、図８において、ＳＵＰＬサーバ８２０は、第２の識別子及び第２のパスワードを生成してメッセージ８２４を介してモバイルデバイス８１０に送信することができ、及び、第２の識別子及び第２のパスワードを引き続いて受信した時点でモバイルデバイス８１０とのＳＵＰＬセッションを確立することができる。
方法１０００は、１００８において、第２のモバイルデバイスから第１の識別子及び第１のパスワードをＳＵＰＬサーバにおいて受信することと、１０１０において、第１の識別子及び第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証することと、をさらに含むことができる。例えば、図８において、ＳＵＰＬサーバ８２０は、メッセージ８４１を介して第２のモバイルデバイス８４０から第１の識別子及び第１のパスワードを受信することができ及び第１の識別子及び第１のパスワードが権限が付与されたユーザと関連付けられているとして認証することができる。例示するために、第２のモバイルデバイス８４０は、図９の方法９００を介して権限が付与されたユーザに以前にバインドしておくこともできる。
方法１０００は、１０１２において、第２のモバイルデバイスがＳＵＰＬサービスにアクセスするのを許容することが、ＳＵＰＬサービスにアクセスすることが許可された権限が付与されたユーザと関連付けられたモバイルデバイスのスレショルド数を超えるかどうかを決定することを含むことができる。例えば、図８において、ウェブサーバ８２０は、第２のモバイルデバイス８４０がＳＵＰＬサービスにアクセスするのを許容することがそのスレショルド数を超えることになるかどうかを決定することができる。特定の実施形態では、第２のモバイルデバイス８４０がＳＵＰＬサービスにアクセスするのを許容することがスレショルドを超えないときに、ウェブサーバ８２０は、メッセージ８２５を介して第２のモバイルデバイスに第３の識別子及び第３のパスワードを送信することができる。ウェブサーバ８２０は、第１のモバイルデバイス８１０及び第２のモバイルデバイス８４０によるＳＵＰＬサービスの使用法をモニタリングすることもできる。
特定の実施形態では、図１０の方法１０００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイス、特定用途向け集積回路（ＡＳＩＣ）、処理ユニット、例えば、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、他のハードウェアデバイス、ファームウェアデバイス、又はそれらのあらゆる組み合わせを介して実装することができる。一例として、図１０の方法１０００は、命令を実行するプロセッサによって実施することができる。
図１１を参照し、無線通信デバイスの特定の例示的な実施形態のブロック図が描かれ、概して１１００で表される。例えば、デバイス１１００は、ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）、例えば、図１のモバイルデバイス１２０、図５のモバイルデバイス５２０、図８の第１のモバイルデバイス８１０、又は図８の第２のモバイルデバイス８４０であることができる。
デバイス１１００は、メモリ１１３２に結合されたプロセッサ１１１０を含む。メモリ１１３２は、ここにおいて開示される方法及びプロセス、例えば、図３の方法３００、図６の方法６００、図７の方法７００、又はそれらのあらゆる組み合わせ、を実施するためにプロセッサ１１１０によって実行可能な命令１１６０を含むことができる。
図１１は、プロセッサ１１１０及びディスプレイ１１２８に結合されるディスプレイコントローラ１１２６も示す。プロセッサ１１１０及びスピーカー１１３６及びマイク１１３８にはＣＯＤＥＣ１１３４を結合させることができる。図１１は、１つ以上の無線コントローラ１１４０をプロセッサ１１１０及び無線アンテナ１１４２、１１４３に結合できることも示す。特定の実施形態では、アンテナ１１４２は、３ＧＰＰ、３ＧＰＰ２、及び／又はＷｉＭＡＸアンテナであることができ、アンテナ１１４３は、Ｗｉ−Ｆｉアンテナであることができる。プロセッサ１１１０及び無線コントローラ１１４０にはカードインタフェース１１７０を結合することもできる。カードインタフェース１１７０は、デバイス１１００のセキュリティクレデンシャルを格納するカード１１７２（例えば、加入者アイデンティティモジュール（ＳＩＭ）カード、ユニバーサル集積回路カード（ＵＩＣＣ）、又はその他のカード）を収納するように構成することができる。例えば、セキュリティクレデンシャルは、デバイス証明書、公開／秘密鍵の対、ＩＭＥＩ、ＭＳＩＤ、一連番号、グローバルで一意の識別子、又はそれらのあらゆる組み合わせを含むことができる。代替として、又はさらに加えて、デバイス１１００のセキュリティクレデンシャルは、メモリ１１３２の“セキュアな”（例えば、ユーザによって変更不能及び／又はアクセス不能な）場所に格納することができる、例えば、セキュリティクレデンシャル１１６１。
特定の実施形態では、プロセッサ１１１０、ディスプレイコントローラ１１２６、メモリ１１３２、ＣＯＤＥＣ１１３４、無線コントローラ１１４０、及びカードインタフェース１１７０は、システム−イン−パッケージ（ｓｙｓｔｅｍ−ｉｎ−ｐａｃｋａｇｅ又はシステム−オン−チップ（ｓｙｓｔｅｍ−ｏｎ−ｃｈｉｐ）デバイス（例えば、移動局モデム（ＭＳＭ））１１２２に含められる。特定の実施形態では、入力デバイス１１３０、例えば、タッチ画面及び／又はキーパッド、及び電源１１４４がシステムーオンーチップデバイス１１２２に結合される。さらに、特定の実施形態では、図１１において例示されるように、ディスプレイ１１２８、入力デバイス１１３０、スピーカー１１３６、マイク１１３８、無線アンテナ１１４２及び１１４３、及び電源１１４４は、システムーオンーチップデバイス１１２２の外部である。しかしながら、ディスプレイ１１２８、入力デバイス１１３０、スピーカー１１３６、マイク１１３８、無線アンテナ１１４２及び１１４３、及び電源１１４４の各々は、システムーオンーチップデバイス１１２２のコンポーネント、例えば、インタフェース又はコントローラ、に結合することができる。
説明される実施形態と関連して、モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納するための手段を含む装置が開示される。例えば、格納するための手段は、図２のメモリ１２２、図１１のメモリ１１３２、図１１のカード１１７２、データを格納するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、モバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証するための少なくとも１つのセキュリティクレデンシャルをＳＬＰに送信することをモバイルデバイスに行わせるための手段も含むことができる。例えば、行わせるための手段は、図１のプロセッサ１２１、図１１のプロセッサ１１１０、図１の無線コントローラ１１４０、データの送信を行わせるように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。
さらに、ＳＵＰＬによってイネーブルにされるモバイルデバイスからのメッセージをウェブサーバにおいて受信するための手段を含む装置が開示され、メッセージは、モバイルデバイスのセキュリティクレデンシャルを含む。例えば、メッセージを受信するための手段は、図８のネットワークインタフェース８３４、データを受信するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、モバイルデバイスからのユーザ識別情報をウェブサーバにおいて受信するための手段も含む。例えば、ユーザ識別情報を受信するための手段は、図８のネットワークインタフェース８３４、データを受信するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証するための手段も含む。例えば、認証するための手段は、図８のプロセッサ８３１、ユーザ識別情報を認証するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、モバイルデバイスがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするためにモバイルデバイスのセキュリティクレデンシャルをＳＵＰＬサーバに送信するための手段を含む。例えば、送信するための手段は、図８のネットワークインタフェース８３４、データを受信するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。
さらに、モバイルデバイスからの第１の識別子及び第１のパスワードをＳＵＰＬサーバにおいて受信するための手段を含む装置が開示される。例えば、受信するための手段は、図８のＳＵＰＬサーバ８２０のネットワークインタフェース、データを受信するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、第１の識別子及び第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証するための手段も含む。例えば、認証するための手段は、図８の認証論理８２１を実行するためにプログラミングされたプロセッサ、例えば、図１のプロセッサ１１１、識別子及びパスワードを認証するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせを含むことができる。装置は、第１の識別子及び第１のパスワードに取って代わるための第２の識別子及び第２のパスワードをモバイルデバイスに送信するための手段をさらに含み、ＳＵＰＬサーバは、モバイルデバイスから第２の識別子及び第２のパスワードを受信した時点でモバイルデバイスとのＳＵＰＬセッションを確立するように構成される。例えば、送信するための手段は、ＳＵＰＬサーバ８２０のネットワークインタフェース、データを送信するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。装置は、第２の識別子及び第２のパスワードを生成するための手段を含むことができる。例えば、生成するための手段は、図８の識別子／パスワード生成論理８２２を実行するためにプログラミングされたプロセッサ、例えば、図１のプロセッサ１１１、識別子及びパスワードを生成するように構成された１つ以上のデバイス、又はそれらのあらゆる組み合わせであることができる。
特定の実施形態では、上記のシステム及び方法の全部又は一部は、以下の追加の実施形態を参照してさらに説明することができ、及び／又は以下の追加の実施形態を参照して説明されるシステム及び方法によって選択的に、個々に又は組み合わせて取り替えることができる。
追加の実施形態１
序論
・ ＳＵＰＬ２．０におけるセキュリティは、アクセスネットワーク専用である。
・ 代替クライアント認証（ＡＣＡ）は、ソースＩＰアドレスに基づいてＳＥＴを識別するためのコアネットワークへのアクセスを要求する
・ ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・ ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・ ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
・ ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・ ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・ ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
・ ＧＢＡ及び“ユーザ名／パスワード”認証の両方をサポートする単純な枠組
・ 単一のＴＬＳの変形を使用することができる
・ 仕様及び実装を最小限変更
概念概要
・ ＵＬＰセキュリティ
・ サーバ証明書によるＴＬＳ
・ ２つのクライアント認証モード
− （ユーザモード）：（Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（ユーザ名、パスワード）
− （ＧＢＡモード）：（Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）
・ （Ｕｓｅｒ_ＩＤ，Ｃｏｕｎｔｅｒ，Ｄｉｇｅｓｔ）が全メッセージに加えられ、Ｄｉｇｅｓｔは以下のように計算される。
・ 単一のＴＬＳの変形を使用することができる
・ 仕様及び実装を最小限変更
概念概要
・ ＵＬＰセキュリティ
・ サーバ証明書によるＴＬＳ
・ ２つのクライアント認証モード
− （ユーザモード）：（Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（ユーザ名、パスワード）
− （ＧＢＡモード）：（Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）
・ （Ｕｓｅｒ_ＩＤ，Ｃｏｕｎｔｅｒ，Ｄｉｇｅｓｔ）が全メッセージに加えられ、Ｄｉｇｅｓｔは以下のように計算される。
・ Ａ１＝ＳＬＰ_Ｄｏｍａｉｎ||ＵＬＰ_Ｍｅｓｓａｇｅ
・ Ｄｉｇｅｓｔ＝ＨＭＡＣ（Ｕｓｅｒ_ｓｅｃｒｅｔ，Ａ１）
・ 送信元が（Ｕｓｅｒ_ＩＤ， Ｃｏｕｎｔｅｒ， Ｄｉｇｅｓｔ）を全メッセージに加え、受信元が検証する
・ ＵＬＰがＳＵＰＬ ＩＮＩＴクレデンシャルを更新するために使用される
・ ＳＵＰＬ ＩＮＩＴ保護［例えば、非緊急時のみ］
・ ＵＬＰｖ２．０ Ｂａｓｉｃ ＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｉｏｎを模倣
・ ＵＬＰを介してＳＬＰによって提供されたＳＵＰＬ ＩＮＩＴクレデンシャルを使用
セットアップ詳細
・ オフライン
・ （ユーザモード）ユーザ及びＳＬＰが（ユーザ名、パスワード）を取り決める
− ＳＬＰは、（ユーザ名、パスワード）をユーザに提供することができる
− ユーザは、（ユーザ名、パスワード）をＳＬＰに提供することができる
− これは、Ｈ−ＳＬＰ又はＡ−ＳＬＰの両方が利用可能である。
・ Ｄｉｇｅｓｔ＝ＨＭＡＣ（Ｕｓｅｒ_ｓｅｃｒｅｔ，Ａ１）
・ 送信元が（Ｕｓｅｒ_ＩＤ， Ｃｏｕｎｔｅｒ， Ｄｉｇｅｓｔ）を全メッセージに加え、受信元が検証する
・ ＵＬＰがＳＵＰＬ ＩＮＩＴクレデンシャルを更新するために使用される
・ ＳＵＰＬ ＩＮＩＴ保護［例えば、非緊急時のみ］
・ ＵＬＰｖ２．０ Ｂａｓｉｃ ＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｉｏｎを模倣
・ ＵＬＰを介してＳＬＰによって提供されたＳＵＰＬ ＩＮＩＴクレデンシャルを使用
セットアップ詳細
・ オフライン
・ （ユーザモード）ユーザ及びＳＬＰが（ユーザ名、パスワード）を取り決める
− ＳＬＰは、（ユーザ名、パスワード）をユーザに提供することができる
− ユーザは、（ユーザ名、パスワード）をＳＬＰに提供することができる
− これは、Ｈ−ＳＬＰ又はＡ−ＳＬＰの両方が利用可能である。
・ ＳＥＴ立ち上がり時
・ （ユーザモード）
− ユーザが（ユーザ名、パスワード）をＳＵＰＬクライアントに入力する
・ （ＧＢＡモード）
− ＳＥＴがＢＳＦとブートストラップして（Ｂ−ＴＩＤ，Ｋ−ｓ）を入手する
− ＳＥＴは、必要に応じた頻度で（Ｂ−ＴＩＤ，Ｋｓ）をリフレッシュすることができることに注目すること
・ ＳＵＰＬクライアントがＳＬＰとのＵＬＰセッションを実施して新しいＳＵＰＬ ＩＮＩＴクレデンシャルを入手する
ＵＬＰセッションセキュリティ提案
・ サーバ証明書によるＴＬＳを使用することができる
・ サーバ認証を取り扱う
・ 新しいパラメータをＵＬＰメッセージに加える
・ （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）をＳＥＴからのメッセージに
・ （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）をＳＬＰからのメッセージに
・ ＳＥＴを発生元とするメッセージ
・ ＳＥＴが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）を加える
・ ＳＬＰが、メッセージ内容を処理する前にＲｅｑ_Ｃｏｕｎｔ及びＲｅｑ_Ｄｉｇｅｓｔを検証する
・ ＳＬＰを発生元とするメッセージ
・ ＳＬＰが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）を加える
・ ＳＥＴが、メッセージ内容を処理する前にＲｅｑ_Ｃｏｕｎｔ及びＲｅｓｐ_Ｄｉｇｅｓｔを検証する
Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔ
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは同様の挙動を有する
・ カウンタの目的は、リプレイ検出を可能にすることである
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは、ＵＬＰセッションごとに受信元及び送信元においてリセットされる
・ すなわち、カウンタは、セッション識別子が変更されたときにリセットされる。
・ （ユーザモード）
− ユーザが（ユーザ名、パスワード）をＳＵＰＬクライアントに入力する
・ （ＧＢＡモード）
− ＳＥＴがＢＳＦとブートストラップして（Ｂ−ＴＩＤ，Ｋ−ｓ）を入手する
− ＳＥＴは、必要に応じた頻度で（Ｂ−ＴＩＤ，Ｋｓ）をリフレッシュすることができることに注目すること
・ ＳＵＰＬクライアントがＳＬＰとのＵＬＰセッションを実施して新しいＳＵＰＬ ＩＮＩＴクレデンシャルを入手する
ＵＬＰセッションセキュリティ提案
・ サーバ証明書によるＴＬＳを使用することができる
・ サーバ認証を取り扱う
・ 新しいパラメータをＵＬＰメッセージに加える
・ （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）をＳＥＴからのメッセージに
・ （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）をＳＬＰからのメッセージに
・ ＳＥＴを発生元とするメッセージ
・ ＳＥＴが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）を加える
・ ＳＬＰが、メッセージ内容を処理する前にＲｅｑ_Ｃｏｕｎｔ及びＲｅｑ_Ｄｉｇｅｓｔを検証する
・ ＳＬＰを発生元とするメッセージ
・ ＳＬＰが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）を加える
・ ＳＥＴが、メッセージ内容を処理する前にＲｅｑ_Ｃｏｕｎｔ及びＲｅｓｐ_Ｄｉｇｅｓｔを検証する
Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔ
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは同様の挙動を有する
・ カウンタの目的は、リプレイ検出を可能にすることである
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは、ＵＬＰセッションごとに受信元及び送信元においてリセットされる
・ すなわち、カウンタは、セッション識別子が変更されたときにリセットされる。
・送信元において
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔが個々のメッセージごとに増分され、ＵＬＰメッセージに加えられる
・受信元において
・ 受信元が、予想した値とＲｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔを比較する。リプレイを検出した場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成
・ Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成は同一であることができる。
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔが個々のメッセージごとに増分され、ＵＬＰメッセージに加えられる
・受信元において
・ 受信元が、予想した値とＲｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔを比較する。リプレイを検出した場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成
・ Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成は同一であることができる。
・ すべての既知値をＵＬＰ_Ｍｅｓｓａｇｅフィールド内に挿入する
・ ＵＬＰ_Ｍｅｓｓａｇｅ_ＺをＵＬＰ_Ｍｅｓｓａｇｅとして形成し、Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔフィールドがすべてゼロに設定される
・ ＤｉｇｅｓｔＰａｙｌｏａｄ＝ＳＬＰ_Ｄｏｍａｉｎ“：”ＵＬＰ_Ｍｅｓｓａｇｅ_Ｚを形成する
・次式を計算する
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ＝ＨＭＡＣ−ＳＨＡ２５６−３２（Ｕｓｅｒ_ｓｅｃｒｅｔ， ＤｉｇｅｓｔＰａｙｌｏａｄ）
・ ＵＬＰ_Ｍｅｓｓａｇｅ内の該当フィールドにＲｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔを加える
・ （ユーザモード）
・ （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（ユーザ名、パスワード）を使用する
・ （ＧＢＡモード）
・ （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）を使用し、ここで、
・ ［ＳＥＴ］Ｋｓ及びＳＬＰ ＵＲＬからＫｓ_ＮＡＦを生成する
・ ［ＳＬＰ］Ｕｓｅｒ_ＩＤフィールドを抽出した時点で、ＳＬＰがＢＳＦにＢ−ＴＩＤを提供し、ＢＳＦは、Ｋｓ_ＮＡＦとともに戻る。Ｋｓ_ＮＡＦは、Ｂ−ＴＩＤが変化しないかぎり変化しない。
・ ＵＬＰ_Ｍｅｓｓａｇｅ_ＺをＵＬＰ_Ｍｅｓｓａｇｅとして形成し、Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔフィールドがすべてゼロに設定される
・ ＤｉｇｅｓｔＰａｙｌｏａｄ＝ＳＬＰ_Ｄｏｍａｉｎ“：”ＵＬＰ_Ｍｅｓｓａｇｅ_Ｚを形成する
・次式を計算する
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ＝ＨＭＡＣ−ＳＨＡ２５６−３２（Ｕｓｅｒ_ｓｅｃｒｅｔ， ＤｉｇｅｓｔＰａｙｌｏａｄ）
・ ＵＬＰ_Ｍｅｓｓａｇｅ内の該当フィールドにＲｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔを加える
・ （ユーザモード）
・ （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（ユーザ名、パスワード）を使用する
・ （ＧＢＡモード）
・ （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）を使用し、ここで、
・ ［ＳＥＴ］Ｋｓ及びＳＬＰ ＵＲＬからＫｓ_ＮＡＦを生成する
・ ［ＳＬＰ］Ｕｓｅｒ_ＩＤフィールドを抽出した時点で、ＳＬＰがＢＳＦにＢ−ＴＩＤを提供し、ＢＳＦは、Ｋｓ_ＮＡＦとともに戻る。Ｋｓ_ＮＡＦは、Ｂ−ＴＩＤが変化しないかぎり変化しない。
ＳＵＰＬ ＩＮＩＴセキュリティ提案
・ ＵＬＰ ＴＳ Ｖ２．０ Ｓｅｃｔｉｏｎ６．１．６．６において既に定義されているＢａｓｉｃ ＳＵＰＬ_ＩＮＩＴ Ｐｒｏｔｅｃｔｉｏｎを模倣する
・ ＧＢＡによってプロビジョニングされた鍵からＳＬＰによってプロビジョニングされた鍵への適合化された記述
・ ＳＬＰが、クライアント又はＳＬＰのイニシアチブでＵＬＰセッション中に（鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新する
− 鍵識別子がリセットされたときにＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる
・ 最小限の標準化努力が要求される
ＳＵＰＬ_ＩＮＩＴクレデンシャル管理
・ あらゆる接続セッションの最初のＵＬＰのやり取りにおいて生じる
・ ＳＥＴを発生元とするメッセージ
・ セッションの最初のメッセージは下記のいずれかを含むべきである。
− クレデンシャルが入手可能でない場合は、“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑ”インジケータ、又は
− ＳＥＴ及びＳＬＰが同期外れであるかどうかをＳＬＰが検出するのを可能にするためのＣｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒ。
− ＳＥＴ及びＳＬＰが同期外れであるかどうかをＳＬＰが検出するのを可能にするためのＣｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒ。
・ＳＬＰを発生元とするメッセージ
・ Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しい場合は、確認のための“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_ＯＫ”インジケータを加える。
・ Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しい場合は、確認のための“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_ＯＫ”インジケータを加える。
・ Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しくない場合、又は、ＳＥＴが“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑインジケータを送信した又はサーバがＳＵＰＬ_ＩＮＩＴクレデンシャルを更新することを希望する場合は、ＳＬＰは、ＳＵＰＬ_ＩＮＩＴクレデンシャルをプロビジョニングするためにＵＬＰメッセージにフィールドを加える
− （鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を含む
呼流れ例−ＳＩ即時フィックス
・ ステップＡ：ターゲットＳＥＴがｒｅｑ_ｃｏｕｎｔを１２３４（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し、メッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴがＳＵＰＬ ＳＴＡＲＴ（ｕｓｅｒ−ｉｄ， ｒｅｑ_ｃｏｕｎｔ＝１２３４， ｒｅｑ_ｄｉｇｅｓｔ，．．．）メッセージをＨ−ＳＬＰに送信する。
− （鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を含む
呼流れ例−ＳＩ即時フィックス
・ ステップＡ：ターゲットＳＥＴがｒｅｑ_ｃｏｕｎｔを１２３４（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し、メッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴがＳＵＰＬ ＳＴＡＲＴ（ｕｓｅｒ−ｉｄ， ｒｅｑ_ｃｏｕｎｔ＝１２３４， ｒｅｑ_ｄｉｇｅｓｔ，．．．）メッセージをＨ−ＳＬＰに送信する。
・ ステップＢ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ ＳＴＡＲＴの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰが、ｒｅｓ_ｃｏｕｎｔを４３２１（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し、メッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰがＳＵＰＬ ＲＥＳＰＯＮＳＥ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１，ｒｅｓ_ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴにおけるＳＵＰＬ ＳＴＡＲＴとＳＵＰＬ ＲＥＳＰＯＮＳＥとの間の期間＝ＵＴ１。
・ ステップＣ：ターゲットＳＥＴが、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ ＲＥＳＰＯＮＳＥの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴが、ｒｅｑ_ｃｏｕｎｔを１だけ増分し（１２３４＋１）及びメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴがＳＵＰＬ ＰＯＳ ＩＮＩＴ（ｕｓｅｒ−ｉｄ， ｒｅｑ_ｃｏｕｎｔ＝１２３４＋１， ｒｅｑ_ｄｉｇｅｓｔ．．．）メッセージをＨ−ＳＬＰに送信する。Ｈ−ＳＬＰにおけるＳＵＰＬ ＲＥＳＰＯＮＳＥとＳＵＰＬ ＰＯＳ ＩＮＩＴとの間の期間＝ＳＴ１。
・ ステップＤ：ターゲットＳＥＴ及びＨ−ＳＬＰがＳＵＰＬ ＰＯＳのやり取りに従事する。ターゲットＳＥＴにおけるＳＵＰＬ ＰＯＳ ＩＮＩＴとＳＵＰＬ ＰＯＳとの間の期間＝ＵＴ２。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタ（ｒｅｑ_ｃｏｕｎｔ／ｒｅｓ_ｃｏｕｎｔ）に基づいてリプレイ完全性を検査する。
・ ステップＥ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いて受信された最後のＳＵＰＬ ＰＯＳメッセージの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰがｒｅｑ_ｃｏｕｎｔを増分し（４３２１＋１）、メッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰが、ＳＵＰＬ ＥＮＤ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１＋１， ｒｅｓ_ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴは、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ ＥＮＤの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴにおけるＳＵＰＬ ＰＯＳとＳＵＰＬ ＥＮＤとの間の期間＝ＵＴ３。
呼流れ例−ＮＩ即時フィックス
・ ステップＡ：Ｈ−ＳＬＰがｒｅｓ_ｃｏｕｎｔを１２３４（又はＨ−ＳＬＰによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ＢａｓｉｃＭＡＣ）を計算する。Ｈ−ＳＬＰがＳＵＰＬ ＩＮＩＴ（ｕｓｅｒ−ｉｄ， ｒｅｓ_ｃｏｕｎｔ＝４３２１，ＢａｓｉｃＭＡＸ，．．．）メッセージをターゲットＳＥＴに送信する。
・ ステップＢ：ターゲットＳＥＴが、受信されたメッセージダイジェスト（ＢａｓｉｃＭＡＣ）を用いてＳＵＰＬ ＩＮＩＴの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴが、ｒｅｑ_ｃｏｕｎｔを１２３４（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴが、ＳＵＰＬ ＰＯＳ ＩＮＩＴ（ｕｓｅｒ−ｉｄ，ｒｅｑ_ｃｏｕｎｔ＝１２３４，ｒｅｑ−ｄｉｇｅｓｔ，．．．）メッセージをＨ−ＳＬＰに送信する。Ｈ−ＳＬＰにおけるＳＵＰＬ ＩＮＩＴとＳＵＰＬ ＰＯＳ ＩＮＩＴとの間の期間＝ＳＴ１。
・ ステップＣ：ターゲットＳＥＴ及びＨ−ＳＬＰがＳＵＰＬ ＰＯＳのやり取りに従事する。ターゲットＳＥＴにおけるＳＵＰＬ ＰＯＳ ＩＮＩＴとＳＵＰＬ ＰＯＳとの間の期間＝ＵＴ２。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタ（ｒｅｑ_ｃｏｕｎｔ／ｒｅｓ_ｃｏｕｎｔ）に基づいてリプレイ完全性を検査する。
・ ステップＤ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いて受信された最後のＳＵＰＬ ＰＯＳメッセージの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰがｒｅｑ_ｃｏｕｎｔを増分し（４３２１＋１）及びメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰが、ＳＵＰＬ ＥＮＤ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１＋１，ｒｅｓ_ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴは、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ ＥＮＤの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴにおけるＳＵＰＬ ＰＯＳとＳＵＰＬ ＥＮＤとの間の期間＝ＵＴ３。
追加の実施形態２
序論
・ ＳＵＰＬ２．０におけるセキュリティは、アクセスネットワーク専用である。
・ ＡＣＡは、ソースＩＰアドレスに基づいてＳＥＴを識別するためのコアネットワークへのアクセスを要求する
・ ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・ ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・ ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
・ ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・ ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・ ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
・ ＧＢＡ及び“ユーザ名／パスワード”認証の両方をサポートする単純な枠組
・ 単一のＴＬＳの変形を使用することができる
・ 仕様及び実装の最小限の変更
概念概要
・ ＵＬＰセキュリティ
・ サーバ証明書によるＴＬＳ
・ ２つのクライアント認証モード
− （ユーザモード）：（Ｕｓｅｒ_ＩＤ， Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（ユーザ名、パスワード）
− （ＧＢＡモード）：（Ｕｓｅｒ_ＩＤ， Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）
・ （Ｕｓｅｒ_ＩＤ， Ｃｏｕｎｔｅｒ， Ｄｉｇｅｓｔ）が全メッセージに加えられ、Ｄｉｇｅｓｔは以下のように計算される。
・ 単一のＴＬＳの変形を使用することができる
・ 仕様及び実装の最小限の変更
概念概要
・ ＵＬＰセキュリティ
・ サーバ証明書によるＴＬＳ
・ ２つのクライアント認証モード
− （ユーザモード）：（Ｕｓｅｒ_ＩＤ， Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（ユーザ名、パスワード）
− （ＧＢＡモード）：（Ｕｓｅｒ_ＩＤ， Ｕｓｅｒ_ｓｅｃｒｅｔ）＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）
・ （Ｕｓｅｒ_ＩＤ， Ｃｏｕｎｔｅｒ， Ｄｉｇｅｓｔ）が全メッセージに加えられ、Ｄｉｇｅｓｔは以下のように計算される。
・ Ａ１＝ＳＬＰ_Ｄｏｍａｉｎ||ＵＬＰ_Ｍｅｓｓａｇｅ
・ Ｄｉｇｅｓｔ＝ＨＭＡＣ（Ｕｓｅｒ_ｓｅｃｒｅｔ，Ａ１）
・ 送信元が（Ｕｓｅｒ_ＩＤ， Ｃｏｕｎｔｅｒ， Ｄｉｇｅｓｔ）を全メッセージに加え、受信元が検証する
・ ＵＬＰがＳＵＰＬ ＩＮＩＴクレデンシャル（鍵アイデンティティ、ＳＵＰ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新するために使用される
・ ＳＵＰＬ ＩＮＩＴ保護［例えば、非緊急時のみ］
・ ＳＬＰ（ユーザモード）又はＧＢＡ（ＧＢＡモード）によって生成されたＳＵＰＬ ＩＮＩＴクレデンシャルを有するＵＬＰｖ２．０ ＢａｓｉｃＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｉｏｎを使用する
・ ユーザモードでＵＬＰを介してＳＬＰによって提供されたＳＵＰＬ ＩＮＩＴクレデンシャルを使用する
セットアップ詳細
・ オフライン
・ （ユーザモード）ユーザ及びＳＬＰが（ユーザ名、パスワード）を取り決める
− ＳＬＰは、（ユーザ名、パスワード）をユーザに提供することができる
− ユーザは、（ユーザ名、パスワード）をＳＬＰに提供することができる
− これは、Ｈ−ＳＬＰ又はＡ−ＳＬＰの両方が利用可能である。
・ Ｄｉｇｅｓｔ＝ＨＭＡＣ（Ｕｓｅｒ_ｓｅｃｒｅｔ，Ａ１）
・ 送信元が（Ｕｓｅｒ_ＩＤ， Ｃｏｕｎｔｅｒ， Ｄｉｇｅｓｔ）を全メッセージに加え、受信元が検証する
・ ＵＬＰがＳＵＰＬ ＩＮＩＴクレデンシャル（鍵アイデンティティ、ＳＵＰ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新するために使用される
・ ＳＵＰＬ ＩＮＩＴ保護［例えば、非緊急時のみ］
・ ＳＬＰ（ユーザモード）又はＧＢＡ（ＧＢＡモード）によって生成されたＳＵＰＬ ＩＮＩＴクレデンシャルを有するＵＬＰｖ２．０ ＢａｓｉｃＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｉｏｎを使用する
・ ユーザモードでＵＬＰを介してＳＬＰによって提供されたＳＵＰＬ ＩＮＩＴクレデンシャルを使用する
セットアップ詳細
・ オフライン
・ （ユーザモード）ユーザ及びＳＬＰが（ユーザ名、パスワード）を取り決める
− ＳＬＰは、（ユーザ名、パスワード）をユーザに提供することができる
− ユーザは、（ユーザ名、パスワード）をＳＬＰに提供することができる
− これは、Ｈ−ＳＬＰ又はＡ−ＳＬＰの両方が利用可能である。
・ ＳＥＴ立ち上がり時
・ （ユーザモード）
− ユーザが（ユーザ名、パスワード）をＳＵＰＬクライアントに入力する
・ （ＧＢＡモード）
− ＳＥＴがＢＳＦとブートストラップして（Ｂ−ＴＩＤ，Ｋｓ）を入手する
− ＳＥＴは、必要に応じた頻度で（Ｂ−ＴＩＤ，Ｋｓ）をリフレッシュすることができることに注目すること
・ ＳＵＰＬクライアントが新しいＳＵＰＬ ＩＮＩＴクレデンシャルを入手するためにＳＬＰとのＵＬＰセッションを実施する
ＵＬＰセッションセキュリティ提案
・ サーバ証明書によるＴＰＬを使用することができる
・ サーバ認証を取り扱う
・新しいパラメータをＵＬＰメッセージに加える
・ （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）をＳＥＴからのメッセージに
・ （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）をＳＬＰからのメッセージに
・ ＳＥＴを発生元とするメッセージ
・ ＳＥＴが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）を加える
・ ＳＬＰが、メッセージ内容を処理する前にＲｅｑ_Ｃｏｕｎｔ及びＲｅｑ_Ｄｉｇｅｓｔを検証する
・ＳＬＰを発生元とするメッセージ
・ ＳＬＰが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）を加える
・ ＳＥＴが、メッセージ内容を処理する前にＲｅｓｐ_Ｃｏｕｎｔ及びＲｅｓｐ_Ｄｉｇｅｓｔを検証する
Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔ
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは同様の挙動を有する
・ カウンタの目的は、リプレイ検出を可能にすることである
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは、ＵＬＰセッションごとに受信元及び送信元においてリセットされる
・ すなわち、カウンタは、セッション識別子が変更されたときにリセットされる。
・ （ユーザモード）
− ユーザが（ユーザ名、パスワード）をＳＵＰＬクライアントに入力する
・ （ＧＢＡモード）
− ＳＥＴがＢＳＦとブートストラップして（Ｂ−ＴＩＤ，Ｋｓ）を入手する
− ＳＥＴは、必要に応じた頻度で（Ｂ−ＴＩＤ，Ｋｓ）をリフレッシュすることができることに注目すること
・ ＳＵＰＬクライアントが新しいＳＵＰＬ ＩＮＩＴクレデンシャルを入手するためにＳＬＰとのＵＬＰセッションを実施する
ＵＬＰセッションセキュリティ提案
・ サーバ証明書によるＴＰＬを使用することができる
・ サーバ認証を取り扱う
・新しいパラメータをＵＬＰメッセージに加える
・ （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）をＳＥＴからのメッセージに
・ （Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）をＳＬＰからのメッセージに
・ ＳＥＴを発生元とするメッセージ
・ ＳＥＴが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｑ_Ｄｉｇｅｓｔ）を加える
・ ＳＬＰが、メッセージ内容を処理する前にＲｅｑ_Ｃｏｕｎｔ及びＲｅｑ_Ｄｉｇｅｓｔを検証する
・ＳＬＰを発生元とするメッセージ
・ ＳＬＰが（Ｕｓｅｒ_ＩＤ，Ｒｅｑ_Ｃｏｕｎｔ，Ｒｅｓｐ_Ｄｉｇｅｓｔ）を加える
・ ＳＥＴが、メッセージ内容を処理する前にＲｅｓｐ_Ｃｏｕｎｔ及びＲｅｓｐ_Ｄｉｇｅｓｔを検証する
Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔ
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは同様の挙動を有する
・ カウンタの目的は、リプレイ検出を可能にすることである
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔは、ＵＬＰセッションごとに受信元及び送信元においてリセットされる
・ すなわち、カウンタは、セッション識別子が変更されたときにリセットされる。
・ 送信元において
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔが個々のメッセージごとに増分され、ＵＬＰメッセージに加えられる
・受信元において
・ 受信元が、予想した値とＲｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔを比較する。リプレイを検出した場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成
・ Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成は同一であることができる。
・ Ｒｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔが個々のメッセージごとに増分され、ＵＬＰメッセージに加えられる
・受信元において
・ 受信元が、予想した値とＲｅｑ_Ｃｏｕｎｔ／Ｒｅｓｐ_Ｃｏｕｎｔを比較する。リプレイを検出した場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成
・ Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ生成は同一であることができる。
・ すべての既知値をＵＬＰ_Ｍｅｓｓａｇｅフィールド内に挿入する
・ ＵＬＰ_Ｍｅｓｓａｇｅ_ＺをＵＬＰ_Ｍｅｓｓａｇｅとして形成し、Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔフィールドがすべてゼロに設定される
・ ＤｉｇｅｓｔＰａｙｌｏａｄ＝ＳＬＰ_Ｄｏｍａｉｎ“：”ＵＬＰ_Ｍｅｓｓａｇｅ_Ｚを形成する
・次式を計算する
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ＝ＨＭＡＣ−ＳＨＡ２５６−３２（Ｕｓｅｒ_ｓｅｃｒｅｔ， ＤｉｇｅｓｔＰａｙｌｏａｄ）
・ ＵＬＰ_Ｍｅｓｓａｇｅ内の該当フィールドにＲｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔを加える
・ （ユーザモード）
・ （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（ユーザ名、パスワード）を使用する
・ （ＧＢＡモード）
・ （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）を使用し、ここで、
・ ［ＳＥＴ］Ｋｓ及びＳＬＰ ＵＲＬからＫｓ_ＮＡＦを生成する
・ ［ＳＬＰ］Ｕｓｅｒ_ＩＤフィールドを抽出した時点で、ＳＬＰがＢＳＦにＢ−ＴＩＤを提供し、ＢＳＦは、Ｋｓ_ＮＡＦとともに戻る。Ｋｓ_ＮＡＦは、Ｂ−ＴＩＤが変化しないかぎり変化しない。
・ ＵＬＰ_Ｍｅｓｓａｇｅ_ＺをＵＬＰ_Ｍｅｓｓａｇｅとして形成し、Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔフィールドがすべてゼロに設定される
・ ＤｉｇｅｓｔＰａｙｌｏａｄ＝ＳＬＰ_Ｄｏｍａｉｎ“：”ＵＬＰ_Ｍｅｓｓａｇｅ_Ｚを形成する
・次式を計算する
Ｒｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔ＝ＨＭＡＣ−ＳＨＡ２５６−３２（Ｕｓｅｒ_ｓｅｃｒｅｔ， ＤｉｇｅｓｔＰａｙｌｏａｄ）
・ ＵＬＰ_Ｍｅｓｓａｇｅ内の該当フィールドにＲｅｑ_Ｄｉｇｅｓｔ／Ｒｅｓｐ_Ｄｉｇｅｓｔを加える
・ （ユーザモード）
・ （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（ユーザ名、パスワード）を使用する
・ （ＧＢＡモード）
・ （Ｕｓｅｒ_ＩＤ，Ｕｓｅｒ_ｓｅｃｒｅｔ）：＝（Ｂ−ＴＩＤ，Ｋｓ_ＮＡＦ）を使用し、ここで、
・ ［ＳＥＴ］Ｋｓ及びＳＬＰ ＵＲＬからＫｓ_ＮＡＦを生成する
・ ［ＳＬＰ］Ｕｓｅｒ_ＩＤフィールドを抽出した時点で、ＳＬＰがＢＳＦにＢ−ＴＩＤを提供し、ＢＳＦは、Ｋｓ_ＮＡＦとともに戻る。Ｋｓ_ＮＡＦは、Ｂ−ＴＩＤが変化しないかぎり変化しない。
ＳＵＰＬ ＩＮＩＴセキュリティ提案
・ ＵＬＰ ＴＳ Ｖ２．０ Ｓｅｃｔｉｏｎ６．１．６．６において既に定義されているＢａｓｉｃ ＳＵＰＬ_ＩＮＩＴ Ｐｒｏｔｅｃｔｉｏｎを使用する
・ ユーザモードにおけるＧＢＡによってプロビジョニングされた鍵からＳＬＰによってプロビジョニングされた鍵への適合化された記述
・ ＳＬＰが、ユーザモードにおいてクライアント又はＳＬＰのイニシアチブでＵＬＰセッション中に（鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新する
− 鍵識別子がリセットされたときにＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる
・ 最小限の標準化努力が要求される
ＳＵＰＬ_ＩＮＩＴ Ｐｒｏｔｅｃｔｉｏｎパラメータ
・ Ｂａｓｉｃ ＳＵＰＬ ＩＮＩＴ ＰｒｏｔｅｃｔｉｏｎのためのＳＵＰＬ ＩＮＩＴプロテクタは、下記から成る。
・ 鍵識別子
・ ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ（長さ＝２オクテット）
・ ＢａｓｉｃＭＡＣ（長さ＝４オクテット）
・ ＢａｓｉｃＭＡＣパラメータは、以下のように生成される。
・ ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ（長さ＝２オクテット）
・ ＢａｓｉｃＭＡＣ（長さ＝４オクテット）
・ ＢａｓｉｃＭＡＣパラメータは、以下のように生成される。
・ ＢａｓｉｃＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ，‘ＳＵＰＬ_ＩＮＩＴ’）
・ ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｂａｓｉｃ ＩＫ”
・ 鍵識別子がリセットされるときにＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる。
・ ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｂａｓｉｃ ＩＫ”
・ 鍵識別子がリセットされるときにＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる。
・ 鍵識別子及びＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、Ｕｓｅｒ_ＩＤ及びＵｓｅｒ_ｓｅｃｒｅｔと同じでなく、すなわち、ＳＵＰＬ ＩＮＩＴ保護は、ＵＬＰメッセージ認証から独立して機能する。
ＳＵＰＬ_ＩＮＩＴクレデンシャル管理
・ あらゆる接続セッションの最初のＵＬＰやり取りにおいて生じる
・ ＳＥＴを発生元とするメッセージ
・ セッションの最初のメッセージは下記のいずれかを含むべきである。
− クレデンシャルが入手可能でない場合は、“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑ”インジケータ、又は
− ＳＥＴ及びＳＬＰが同期外れであるかどうかをＳＬＰが検出するのを可能にするためのＣｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒ
・ＳＬＰを発生元とするメッセージ
・ Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しい場合は、確認のための“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_ＯＫ”インジケータを加える
・ Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しくない場合、又は、ＳＥＴが“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑインジケータを送信した又はサーバがＳＵＰＬ_ＩＮＩＴクレデンシャルを更新することを希望する場合は、ＳＬＰは、ＳＵＰＬ_ＩＮＩＴクレデンシャルをプロビジョニングするためにＵＬＰメッセージにフィールドを加える。
− ＳＥＴ及びＳＬＰが同期外れであるかどうかをＳＬＰが検出するのを可能にするためのＣｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒ
・ＳＬＰを発生元とするメッセージ
・ Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しい場合は、確認のための“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_ＯＫ”インジケータを加える
・ Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しくない場合、又は、ＳＥＴが“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑインジケータを送信した又はサーバがＳＵＰＬ_ＩＮＩＴクレデンシャルを更新することを希望する場合は、ＳＬＰは、ＳＵＰＬ_ＩＮＩＴクレデンシャルをプロビジョニングするためにＵＬＰメッセージにフィールドを加える。
− （鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を含む。
呼流れ例−ＳＩ即時フィックス
・ ステップＡ：ターゲットＳＥＴがｒｅｑ_ｃｏｕｎｔを１２３４（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴがＳＵＰＬ ＳＴＡＲＴ（ｕｓｅｒ−ｉｄ， ｒｅｑ_ｃｏｕｎｔ＝１２３４， ｒｅｑ_ｄｉｇｅｓｔ，．．．）メッセージをＨ−ＳＬＰに送信する。
・ ステップＢ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ ＳＴＡＲＴの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰが、ｒｅｓ_ｃｏｕｎｔを４３２１（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰがＳＵＰＬ ＲＥＳＰＯＮＳＥ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１，ｒｅｓ−ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴにおけるＳＵＰＬ ＳＴＡＲＴとＳＵＰＬ ＲＥＳＰＯＮＳＥとの間の期間＝ＵＴ１。
・ ステップＣ：ターゲットＳＥＴが、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ ＲＥＳＰＯＮＳＥの真正性を検査し及びリプレイカウンタ（ｒｅｓ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴが、ｒｅｑ_ｃｏｕｎｔを１だけ増分し（１２３４＋１）及びメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴが、ＳＵＰＬ ＰＯＳ ＩＮＩＴ（ｕｓｅｒ−ｉｄ， ｒｅｑ_ｃｏｕｎｔ＝１２３４＋１， ｒｅｑ_ｄｉｇｅｓｔ．．．）メッセージをＨ−ＳＬＰに送信する。Ｈ−ＳＬＰにおけるＳＵＰＬ ＲＥＳＰＯＮＳＥとＳＵＰＬ ＰＯＳ ＩＮＩＴとの間の期間＝ＳＴ１。
・ ステップＤ：ターゲットＳＥＴ及びＨ−ＳＬＰがＳＵＰＬ ＰＯＳのやり取りに従事する。ターゲットＳＥＴにおけるＳＵＰＬ ＰＯＳ ＩＮＩＴとＳＵＰＬ ＰＯＳとの間の期間＝ＵＴ２。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタ（ｒｅｑ_ｃｏｕｎｔ／ｒｅｓ_ｃｏｕｎｔ）に基づいてリプレイ完全性を検査する。
・ ステップＥ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いて受信された最後のＳＵＰＬ ＰＯＳメッセージの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰがｒｅｑ_ｃｏｕｎｔを増分し（４３２１＋１）及びメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰが、ＳＵＰＬ ＥＮＤ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１＋１， ｒｅｓ_ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴが、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ ＥＮＤの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴにおけるＳＵＰＬ ＰＯＳとＳＵＰＬ ＥＮＤとの間の期間＝ＵＴ３。
呼流れ例−ＮＩ即時フィックス
・ ステップＡ：Ｈ−ＳＬＰがｒｅｓ_ｃｏｕｎｔを１２３４（又はＨ−ＳＬＰによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ＢａｓｉｃＭＡＣ）を計算する。Ｈ−ＳＬＰがＳＵＰＬ ＩＮＩＴ（ｕｓｅｒ−ｉｄ， ｒｅｓ_ｃｏｕｎｔ＝４３２１，ＢａｓｉｃＭＡＸ，．．．）メッセージをターゲットＳＥＴに送信する。
・ ステップＢ：ターゲットＳＥＴが、受信されたメッセージダイジェスト（ＢａｓｉｃＭＡＣ）を用いてＳＵＰＬ ＩＮＩＴの真正性を検査し及びリプレイカウンタ（ｒｅｓ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴが、ｒｅｑ_ｃｏｕｎｔを１２３４（又はＳＥＴによって決定されたその他のいずれかの連続番号）に設定し及びメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を計算する。ターゲットＳＥＴが、ＳＵＰＬ ＰＯＳ ＩＮＩＴ（ｕｓｅｒ−ｉｄ，ｒｅｑ_ｃｏｕｎｔ＝１２３４，ｒｅｑ−ｄｉｇｅｓｔ，．．．）メッセージをＨ−ＳＬＰに送信する。Ｈ−ＳＬＰにおけるＳＵＰＬ ＩＮＩＴとＳＵＰＬ ＰＯＳ ＩＮＩＴとの間の期間＝ＳＴ１。
・ ステップＣ：ターゲットＳＥＴ及びＨ−ＳＬＰがＳＵＰＬ ＰＯＳのやり取りに従事する。ターゲットＳＥＴにおけるＳＵＰＬ ＰＯＳ ＩＮＩＴとＳＵＰＬ ＰＯＳとの間の期間＝ＵＴ２。各側は、受信されたメッセージダイジェストに基づいてメッセージ真正性を及びメッセージカウンタ（ｒｅｑ_ｃｏｕｎｔ／ｒｅｓ_ｃｏｕｎｔ）に基づいてリプレイ完全性を検査する。
・ ステップＤ：Ｈ−ＳＬＰが、受信されたメッセージダイジェスト（ｒｅｑ_ｄｉｇｅｓｔ）を用いて受信された最後のＳＵＰＬ ＰＯＳメッセージの真正性を検査し及びリプレイカウンタ（ｒｅｑ_ｃｏｕｎｔ）も検査する。Ｈ−ＳＬＰがｒｅｑ_ｃｏｕｎｔを増分し（４３２１＋１）及びメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を計算する。Ｈ−ＳＬＰが、ＳＵＰＬ ＥＮＤ（ｕｓｅｒ−ｉｄ，ｒｅｓ_ｃｏｕｎｔ＝４３２１＋１， ｒｅｓ_ｄｉｇｅｓｔ，．．．）メッセージをターゲットＳＥＴに送信する。ターゲットＳＥＴが、受信されたメッセージダイジェスト（ｒｅｓ_ｄｉｇｅｓｔ）を用いてＳＵＰＬ ＥＮＤの真正性を検査し及びリプレイカウンタ（ｒｅｓ_ｃｏｕｎｔ）も検査する。ターゲットＳＥＴにおけるＳＵＰＬ ＰＯＳとＳＵＰＬ ＥＮＤとの間の期間＝ＵＴ３。
追加の実施形態３
序論
・ ＳＵＰＬ２．０におけるセキュリティは、アクセスネットワーク専用である。
・ ＡＣＡは、ソースＩＰアドレスに基づいてＳＥＴを識別するためのコアネットワークへのアクセスを要求する
・ ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・ ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・ ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
・ ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・ ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・ ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
・ ＧＢＡ及び“ユーザ名／パスワード”認証の両方をサポートする単純な枠組
選択肢Ｉ：概念概要
・ ＵＬＰセキュリティ
・ ＧＢＡモード：以前と同じようにＴＬＳ−ＰＳＫを使用
・ ユーザモードＵＬＰ：（ユーザ名、パスワード）に基づく
− 最初にサーバ証明書によるＴＬＳハンドシェイクを実施してセキュアなコネクションを確立する
・ ＳＥＴによって送信された全ＵＬＰメッセージに加えられた（ユーザ名、カウンタ、ダイジェスト）であり、ダイジェストは以下のように計算される
− Ａ１＝ＳＬＰ_Ｄｏｍａｉｎ||ＵＬＰ_Ｍｅｓｓａｇｅ
− Ｄｉｇｅｓｔ＝ＨＭＡＣ（Ｐａｓｓｗｏｒｄ，Ａ１）
・ ＳＥＴが（ユーザ名、カウンタ、ダイジェスト）を全メッセージに加え、ＳＬＰが検証する
・ ＳＵＰＬ ＩＮＩＴ保護のために要求されるＳＵＰＬ ＩＮＩＴクレデンシャル（Ｋｅｙ Ｉｄｅｎｔｉｔｙ，ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新するためにＵＬＰが使用される
選択肢Ｉ：オフライン手順
・ ユーザモードＵＬＰ（オフライン）
・ ユーザ及びＳＬＰオペレータが（ユーザ名、パスワード）を取り決める
・ その他の前提事項
・ ＳＥＴがＳＬＰのＵＲＬを有する
・ ＳＥＴがＳＬＰを認証するための該当するルート証明書を有する
選択肢Ｉ：オンライン手順
・ サーバ認証及び暗号化のために用いられるサーバ証明書によるＴＬＳ
・ ＳＥＴからのＵＬＰメッセージに新しいパラメータが加えられる：（ユーザ名、カウンタ、ダイジェスト）
・ ＳＬＰが、ＵＬＰメッセージ内容を処理する前にカウンタ及びダイジェストを検証する
・ カウンタの目的は、リプレイ検出を可能にすることである
・ すべてのＵＬＰセッションに関して受信元及び送信元においてカウンタがリセットされる
・ 送信元において、メッセージごとにカウンタが増分され、ＵＬＰメッセージに加えられる
・ 受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す。
・ ＵＬＰセキュリティ
・ ＧＢＡモード：以前と同じようにＴＬＳ−ＰＳＫを使用
・ ユーザモードＵＬＰ：（ユーザ名、パスワード）に基づく
− 最初にサーバ証明書によるＴＬＳハンドシェイクを実施してセキュアなコネクションを確立する
・ ＳＥＴによって送信された全ＵＬＰメッセージに加えられた（ユーザ名、カウンタ、ダイジェスト）であり、ダイジェストは以下のように計算される
− Ａ１＝ＳＬＰ_Ｄｏｍａｉｎ||ＵＬＰ_Ｍｅｓｓａｇｅ
− Ｄｉｇｅｓｔ＝ＨＭＡＣ（Ｐａｓｓｗｏｒｄ，Ａ１）
・ ＳＥＴが（ユーザ名、カウンタ、ダイジェスト）を全メッセージに加え、ＳＬＰが検証する
・ ＳＵＰＬ ＩＮＩＴ保護のために要求されるＳＵＰＬ ＩＮＩＴクレデンシャル（Ｋｅｙ Ｉｄｅｎｔｉｔｙ，ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新するためにＵＬＰが使用される
選択肢Ｉ：オフライン手順
・ ユーザモードＵＬＰ（オフライン）
・ ユーザ及びＳＬＰオペレータが（ユーザ名、パスワード）を取り決める
・ その他の前提事項
・ ＳＥＴがＳＬＰのＵＲＬを有する
・ ＳＥＴがＳＬＰを認証するための該当するルート証明書を有する
選択肢Ｉ：オンライン手順
・ サーバ認証及び暗号化のために用いられるサーバ証明書によるＴＬＳ
・ ＳＥＴからのＵＬＰメッセージに新しいパラメータが加えられる：（ユーザ名、カウンタ、ダイジェスト）
・ ＳＬＰが、ＵＬＰメッセージ内容を処理する前にカウンタ及びダイジェストを検証する
・ カウンタの目的は、リプレイ検出を可能にすることである
・ すべてのＵＬＰセッションに関して受信元及び送信元においてカウンタがリセットされる
・ 送信元において、メッセージごとにカウンタが増分され、ＵＬＰメッセージに加えられる
・ 受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す。
選択肢ＩＩ：概念概要
・ ＵＬＰセキュリティ
・ ＧＢＡモード：以前と同じようにＴＬＳ−ＰＳＫを使用
・ ユーザモードＴＬＳ：（ユーザ名、パスワード）に基づく
− 最初にサーバ証明書によるＴＬＳハンドシェイクを実施してセキュアなコネクションを確立する。
− ＳＬＰが、ＴＬＳ再交渉を開始するために“Ｈｅｌｌｏ Ｒｅｑｕｅｓｔ”を送信する。次に、ＳＥＴ及びＳＬＰが、（ユーザ名、パスワード）を用いてユーザを認証するためにＴＬＳ−ＳＲＰハンドシェイク（ＳＲＰ＝セキュアリモートパスワード）を実施する。
− ＴＬＳ−ＳＲＰハンドシェイクにおいてユーザ名を隠すために最初のセキュアなコネクションが要求される。
・ ＳＵＰＬ ＩＮＩＴ保護のために要求される基本的保護ＳＵＰＬ ＩＮＩＴクレデンシャル（Ｋｅｙ Ｉｄｅｎｔｉｔｙ，ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を更新するためにＵＬＰが使用される
選択肢ＩＩ：オフライン手順
・ ユーザモードＴＬＳ（オフライン）
・ ユーザ及びＳＬＰオペレータが（ユーザ名、パスワード）を取り決める
・ その他の前提事項
・ ＳＥＴがＳＬＰのＵＲＬを有する
・ ＳＥＴがＳＬＰを認証するための該当するルート証明書を有する
選択肢ＩＩ：オンライン手順
・ ＳＥＴがＴＬＳハンドシェイクを開始し、該当する暗号スィートを選択することによってＧＢＡ及び／又はユーザモードのためのサポートをＴＬＳにおいて示す。
選択肢ＩＩ：オフライン手順
・ ユーザモードＴＬＳ（オフライン）
・ ユーザ及びＳＬＰオペレータが（ユーザ名、パスワード）を取り決める
・ その他の前提事項
・ ＳＥＴがＳＬＰのＵＲＬを有する
・ ＳＥＴがＳＬＰを認証するための該当するルート証明書を有する
選択肢ＩＩ：オンライン手順
・ ＳＥＴがＴＬＳハンドシェイクを開始し、該当する暗号スィートを選択することによってＧＢＡ及び／又はユーザモードのためのサポートをＴＬＳにおいて示す。
・ ＳＬＰがＧＢＡモード又はユーザモードを進めるべきかどうかを決定する
・ＧＢＡモードの場合
・ セキュアなトンネルを確立するためにＧＢＡを用いてＴＬＳ−ＰＳＫの場合と同じようにＴＬＳハンドシェイクを継続する
・相互認証
・ セキュアなチャネルでデータをやり取りする
・ユーザモードの場合
・ 最初に、セキュアなチャネルを確立するためにサーバ証明書によるＴＬＳハンドシェイクを継続する
・ ＳＥＴがＳＬＰを認証する
・ ＴＬＳ＝ＳＲＰハンドシェイクを実施する（メッセージは、セキュアなチャネル内部でやり取りされる）
・ ＳＬＰがユーザを認証する
・新しいセッション鍵が得られる
・ 新しいセッション鍵によって保護されたセキュアなトンネルでデータをやり取りする
選択肢ＩＩ：オンライン手順−最初のＴＬＳハンドシェイク
・ ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ Ｈｅｌｌｏ：
・すべてのサポートされる暗号スイートを示す
− ＳＥＴがＧＢＡをサポートする場合は、ＴＬＳ−ＰＳＫ暗号スイートのためのサポートを示す
− ＳＥＴがユーザモードをサポートする場合は、サーバ証明書及びＴＬＳ ＳＲＰを用いるＴＬＳのためのサポートを示す
・ ＳＥＴはこの時点ではユーザ名を提供せず、要求される場合は、次のＴＬＳハンドシェイクで提供される。
・ ＳＬＰ→ＳＥＴ：Ｓｅｒｖｅｒ Ｈｅｌｌｏ：
・ 選択された暗号スイートを示す
− ＳＬＰがＧＢＡモードを選択する場合は、ＳＬＰは、ＴＬＳ−ＰＳＫ暗号スイートを示す
− ＳＬＰがユーザモードを選択する場合は、ＳＬＰは、サーバ証明書を用いるＴＬＳのための暗号スイートを示す
− 呼の流れが選択された暗号スイートの場合と同じように進む
選択肢ＩＩ：オンライン手順−最初のＴＬＳハンドシェイク後
・ ＧＢＡモード
・ ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルを通じての通信を開始する
・ ユーザモード
・ ＳＬＰ→ＳＥＴ：Ｈｅｌｌｏ Ｒｅｑｅｕｓｔ
・ 再交渉を開始する
・ ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ Ｈｅｌｌｏ
・ ＴＬＳ−ＳＲＰのためのサポートを示す
・ ＴＬＳ−ＳＲＰ仕様に準拠してユーザ名を含める
・ ＳＥＴ→ＳＬＰ：ＳｅｒｖｅｒＨｅｌｌｏ
・ ＴＬＳ−ＳＲＰの選択を示す
・ ＴＬＳ−ＳＲＰに準拠してやり取りを継続する
・ 成功裏のハンドシェイクに後続して、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでデータをやり取りすることを開始する
ＳＵＰＬ ＩＮＩＴ保護
・ ＳＵＰＬ３．０におけるＳＵＰＬ ＩＮＩＴ保護は、ＳＵＰＬ２．０におけるＳＵＰＬ ＩＮＩＴ保護メカニズムに基づき、ＳＵＰＬ ＩＮＩＴに添付されたメッセージ認証コード（ＭＡＣ）を使用する
・ ＭＡＣは、ユーザモードでＵＬＰを通じてプロビジョニングされた（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ， ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を用いて計算される（ＧＢＡモードは、プロビジョニングを要求しない）
・ （Ｋｅｙ，Ｉｄｅｎｔｉｔｙ， ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を計算するための２つの方法：
・ ＧＢＡモード：（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ， ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）＝（Ｂ−ＴＩＤ，Ｋｓ）
− （Ｂ−ＴＩＤ，Ｋｓ）がＢＳＦからブートストラップを外される
・ ユーザモード：（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ， ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）が（ユーザ名、パスワード）から生成される
・ ＳＵＰＬ ＩＮＩＴ保護は、選択肢Ｉ及び選択肢ＩＩに関して同じである
ＳＵＰＬ ＩＮＩＴ保護メカニズム
・ ＳＵＰＬｖ３．０における２つの保護レベル
・ＮＵＬＬ
− セキュリティなし
・ 基本的保護
− ＵＬＰを通じてプロビジョニングされた共有される鍵アイデンティティ、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹに基づく
− ＳＵＰＬｖ２．０からの基本的保護を模倣する
− 鍵識別子及びＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、ユーザ名、パスワードと同じでない
・ 再同期化保護メカニズム
・ ＳＥＴがＳＥＴにおいてＳＬＰの証明書から検証することができるというデジタルシグナチャに基づく
・ ＳＬＰ及びＳＥＴにおける鍵アイデンティティ、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが同期外れになっていることにＳＬＰが納得するときしか使用できない
・ 計算コストが高い可能がある：控えめに使用することができる。
・ＧＢＡモードの場合
・ セキュアなトンネルを確立するためにＧＢＡを用いてＴＬＳ−ＰＳＫの場合と同じようにＴＬＳハンドシェイクを継続する
・相互認証
・ セキュアなチャネルでデータをやり取りする
・ユーザモードの場合
・ 最初に、セキュアなチャネルを確立するためにサーバ証明書によるＴＬＳハンドシェイクを継続する
・ ＳＥＴがＳＬＰを認証する
・ ＴＬＳ＝ＳＲＰハンドシェイクを実施する（メッセージは、セキュアなチャネル内部でやり取りされる）
・ ＳＬＰがユーザを認証する
・新しいセッション鍵が得られる
・ 新しいセッション鍵によって保護されたセキュアなトンネルでデータをやり取りする
選択肢ＩＩ：オンライン手順−最初のＴＬＳハンドシェイク
・ ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ Ｈｅｌｌｏ：
・すべてのサポートされる暗号スイートを示す
− ＳＥＴがＧＢＡをサポートする場合は、ＴＬＳ−ＰＳＫ暗号スイートのためのサポートを示す
− ＳＥＴがユーザモードをサポートする場合は、サーバ証明書及びＴＬＳ ＳＲＰを用いるＴＬＳのためのサポートを示す
・ ＳＥＴはこの時点ではユーザ名を提供せず、要求される場合は、次のＴＬＳハンドシェイクで提供される。
・ ＳＬＰ→ＳＥＴ：Ｓｅｒｖｅｒ Ｈｅｌｌｏ：
・ 選択された暗号スイートを示す
− ＳＬＰがＧＢＡモードを選択する場合は、ＳＬＰは、ＴＬＳ−ＰＳＫ暗号スイートを示す
− ＳＬＰがユーザモードを選択する場合は、ＳＬＰは、サーバ証明書を用いるＴＬＳのための暗号スイートを示す
− 呼の流れが選択された暗号スイートの場合と同じように進む
選択肢ＩＩ：オンライン手順−最初のＴＬＳハンドシェイク後
・ ＧＢＡモード
・ ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルを通じての通信を開始する
・ ユーザモード
・ ＳＬＰ→ＳＥＴ：Ｈｅｌｌｏ Ｒｅｑｅｕｓｔ
・ 再交渉を開始する
・ ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ Ｈｅｌｌｏ
・ ＴＬＳ−ＳＲＰのためのサポートを示す
・ ＴＬＳ−ＳＲＰ仕様に準拠してユーザ名を含める
・ ＳＥＴ→ＳＬＰ：ＳｅｒｖｅｒＨｅｌｌｏ
・ ＴＬＳ−ＳＲＰの選択を示す
・ ＴＬＳ−ＳＲＰに準拠してやり取りを継続する
・ 成功裏のハンドシェイクに後続して、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでデータをやり取りすることを開始する
ＳＵＰＬ ＩＮＩＴ保護
・ ＳＵＰＬ３．０におけるＳＵＰＬ ＩＮＩＴ保護は、ＳＵＰＬ２．０におけるＳＵＰＬ ＩＮＩＴ保護メカニズムに基づき、ＳＵＰＬ ＩＮＩＴに添付されたメッセージ認証コード（ＭＡＣ）を使用する
・ ＭＡＣは、ユーザモードでＵＬＰを通じてプロビジョニングされた（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ， ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を用いて計算される（ＧＢＡモードは、プロビジョニングを要求しない）
・ （Ｋｅｙ，Ｉｄｅｎｔｉｔｙ， ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を計算するための２つの方法：
・ ＧＢＡモード：（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ， ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）＝（Ｂ−ＴＩＤ，Ｋｓ）
− （Ｂ−ＴＩＤ，Ｋｓ）がＢＳＦからブートストラップを外される
・ ユーザモード：（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ， ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）が（ユーザ名、パスワード）から生成される
・ ＳＵＰＬ ＩＮＩＴ保護は、選択肢Ｉ及び選択肢ＩＩに関して同じである
ＳＵＰＬ ＩＮＩＴ保護メカニズム
・ ＳＵＰＬｖ３．０における２つの保護レベル
・ＮＵＬＬ
− セキュリティなし
・ 基本的保護
− ＵＬＰを通じてプロビジョニングされた共有される鍵アイデンティティ、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹに基づく
− ＳＵＰＬｖ２．０からの基本的保護を模倣する
− 鍵識別子及びＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、ユーザ名、パスワードと同じでない
・ 再同期化保護メカニズム
・ ＳＥＴがＳＥＴにおいてＳＬＰの証明書から検証することができるというデジタルシグナチャに基づく
・ ＳＬＰ及びＳＥＴにおける鍵アイデンティティ、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが同期外れになっていることにＳＬＰが納得するときしか使用できない
・ 計算コストが高い可能がある：控えめに使用することができる。
Ｂａｓｉｃ ＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｉｏｎパラメータ
・ Ｂａｓｉｃ ＳＵＰＬ ＩＮＩＴ ＰｒｏｔｅｃｔｉｏｎのためのＳＵＰＬ ＩＮＩＴプロテクタは、下記から成る。
・ 鍵識別子
・ ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ（長さ＝２オクテット）
・ ＢａｓｉｃＭＡＣ（長さ＝４オクテット）
・ ＢａｓｉｃＭＡＣパラメータは、以下のように生成される。
・ ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ（長さ＝２オクテット）
・ ＢａｓｉｃＭＡＣ（長さ＝４オクテット）
・ ＢａｓｉｃＭＡＣパラメータは、以下のように生成される。
・ ＢａｓｉｃＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ，‘ＳＵＰＬ_ＩＮＩＴ’）
・ ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｂａｓｉｃ ＩＫ”
・ 鍵識別子がリセットされるときにＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる。
・ ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｂａｓｉｃ ＩＫ”
・ 鍵識別子がリセットされるときにＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる。
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ管理
・ あらゆるＳＵＰＬセッションの最初のＵＬＰやり取りにおいて生じる
・ 第１のＳＥＴを発生元とするメッセージ
・ セッションの第１のメッセージは下記のいずれかを含むべきである。
− クレデンシャルが入手可能でない場合は、“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑ”インジケータ、又は
− ＳＥＴ及びＳＬＰが同期外れであるかどうかをＳＬＰが検出するのを可能にするためのＣｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒ
・ ＳＬＰ応答
・ Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しい場合は、確認のための“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_ＯＫ”インジケータを加える。
− ＳＥＴ及びＳＬＰが同期外れであるかどうかをＳＬＰが検出するのを可能にするためのＣｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒ
・ ＳＬＰ応答
・ Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しい場合は、確認のための“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_ＯＫ”インジケータを加える。
・ Ｃｕｒｒｅｎｔ_Ｋｅｙ_Ｉｄｅｎｔｉｆｉｅｒが正しくない場合、又は、ＳＥＴが“ＳＵＰＬ_ＩＮＩＴ_Ｃｒｅｄｅｎｔｉａｌ_Ｒｅｑインジケータを送信した又はＳＬＰがＳＵＰＬ_ＩＮＩＴクレデンシャルを更新することを希望する場合は、ＳＬＰは、ＳＵＰＬ_ＩＮＩＴクレデンシャルをプロビジョニングするためにＵＬＰメッセージにフィールドを加える。
− （鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）を含む。
概要
・ ＳＵＰＬ３．０では２つの新しいセキュリティモデルが考慮される
・ 選択肢Ｉ：ユーザモードＵＬＰ
・ 選択肢ＩＩ：ユーザモードＴＬＳ
・ これらの２つの新しいセキュリティモードは、（ユーザ名、パスワード）クライアント認証を使用し、サーバ認証及び暗号化は、レガシーのサーバ認証ＴＬＳに基づく。
・ ＳＵＰＬ３．０では２つの新しいセキュリティモデルが考慮される
・ 選択肢Ｉ：ユーザモードＵＬＰ
・ 選択肢ＩＩ：ユーザモードＴＬＳ
・ これらの２つの新しいセキュリティモードは、（ユーザ名、パスワード）クライアント認証を使用し、サーバ認証及び暗号化は、レガシーのサーバ認証ＴＬＳに基づく。
・ 両選択肢とも、全ベアラをサポートする（ｂｅａｒｅｒ ａｇｎｏｓｔｉｃ）セキュリティモデルであり、このため、ＳＵＰＬ３．０に適する。
・ 該当する場合及び望ましい場合はレガシーセキュリティモデル（ＡＣＡ及びＧＢＡ）を依然として使用することができる。
ＳＲＰ基本事項
・ ＴＬＳ−ＳＲＰ［ＩＥＴＦ ＲＦＣ ５０５４］は、セキュアリモートパスワード（ＳＲＰ［ＲＦＣ２９４５］を認証及び鍵やり取りの基礎として使用する。
・ 主ステップ
・ 認証を行うサーバは、パスワードは不要であり、その代わりに、｛Ｕｓｅｒｎａｍｅ，ＰａｓｓｗｏｒｄＶｅｒｉｆｉｅｒ，Ｓａｌｔ｝を含むトリプレットを格納する。
・ 認証を行うサーバは、パスワードは不要であり、その代わりに、｛Ｕｓｅｒｎａｍｅ，ＰａｓｓｗｏｒｄＶｅｒｉｆｉｅｒ，Ｓａｌｔ｝を含むトリプレットを格納する。
・ 典型的には、ユーザのクライアントは、オフラインでサーバに登録時にトリプレットを生成する。
・ Ｓａｌｔは、ユーザがランダムに選択することができる。
・ ＰａｓｓｗｏｒｄＶｅｒｉｆｉｅｒは、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵やり取りと同様の複雑な数学を用いてＵｓｅｒｎａｍｅ、Ｓａｌｔ及びユーザのパスワードから計算される。
・ サーバは、下記のためにユーザと対話してトリプレットを使用する
・ ユーザがパスワードを知っていることを検証する
・ ユーザ及びサーバのみによって知られる共有される秘密を確立する。この共有される秘密は、暗号化及び完全性保護のための鍵を生成するために使用することができる（ＴＬＳ−ＳＲＰでどのように使用されるか）。
・ ユーザがパスワードを知っていることを検証する
・ ユーザ及びサーバのみによって知られる共有される秘密を確立する。この共有される秘密は、暗号化及び完全性保護のための鍵を生成するために使用することができる（ＴＬＳ−ＳＲＰでどのように使用されるか）。
ＳＲＰの幾つかの特性
・ トリプレットは、ユーザになりすますために使用することができない
・ サーバがトリプレットを守秘する必要がない
・ サーバは、第三者がユーザになりすますことを試みるということを懸念せずに、第三者がユーザを検証するのを可能にするために第三者にトリプレットを提供することができる。
− 例えば、Ｈ−ＳＬＰは、Ａ−ＳＬＰがユーザを認証するのを可能にするためにＡ−ＳＬＰにトリプレットを提供することができる。
追加の実施形態４
序論
・ ＳＵＰＬ２．０におけるセキュリティは、アクセスネットワーク専用である。
・ ＡＣＡは、ソースＩＰアドレスに基づいてＳＥＴを識別するためのコアネットワークへのアクセスを要求する
・ ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・ ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・ ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
・ ＧＢＡは、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・ ＳＥＫは、ＷｉＭＡＸネットワークのみに適用可能
・ ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
・ ＧＢＡ及び“ユーザ名／パスワード”認証の両方をサポートする単純な枠組
以下の説明では、両方の選択肢を対象にし、各手法の利点及び潜在的な欠点について論じる。
ユーザモードオフライン手順
・ ユーザモードＵＬＰ（オフライン）
・ ユーザ及びＳＬＰオペレータが（ユーザ名、パスワード）を取り決める
・ その他の前提事項
・ ＳＥＴがＳＬＰのＵＲＬを有する
・ ＳＥＴがＳＬＰを認証するための該当するルート証明書を有する
ユーザモードＵＬＰ：概念概要Ｉ
・ ユーザモードＵＬＰ：（ユーザ名、パスワード）に基づく
・ 最初にサーバ証明書によるＴＬＳハンドシェイクを実施してセキュアなコネクションを確立する
・ ＳＥＴによって送信された全ＵＬＰメッセージに（ユーザ名、カウンタ、ダイジェスト）が加えられ、ダイジェストは以下のように計算される
− ＵＬＰ_Ｍｅｓｓａｇｅ_Ｚは、ダイジェストフィールドがゼロに設定されたＵＬＰ_Ｍｅｓｓａｇｅである
− Ｕｓｅｒ_ＵＬＰ_ＩＫ＝ＳＨＡ−２５６（Ｕｓｅｒｎａｍｅ||“：”||Ｐａｓｓｗｏｒｄ||“：”||ＳＬＰ_Ｄｏｍａｉｎ||“：ＳＵＰＬ３０ＵＬＰ”）
− Ｄｉｇｅｓｔ＝ＨＭＡＣ−ＳＨＡ−２５６−３２（Ｕｓｅｒ_ＵＬＰ_ＩＫ，ＵＬＰ_Ｍｅｓｓａｇｅ_Ｚ）
・ ＳＥＴが（ユーザ名、カウンタ、ダイジェスト）を全メッセージに加え、ＳＬＰが検証する
ユーザモードＵＬＰ：概念概要ＩＩ
・ サーバ認証及び暗号化のために用いられるサーバ証明書によるＴＬＳ
・ ＳＥＴからのＵＬＰメッセージに新しいパラメータが加えられる：（ユーザ名、カウンタ、ダイジェスト）
・ ＳＬＰが、ＵＬＰメッセージ内容を処理する前にカウンタ及びダイジェストを検証する
・ カウンタの目的は、リプレイ検出を可能にすることである
・ すべてのＵＬＰセッションに関して受信元及び送信元においてカウンタがリセットされる
・ 送信元において、メッセージごとにカウンタが増分され、ＵＬＰメッセージに加えられる
・ 受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ保護を渡す
ユーザモードＴＬＳ：概念概要
・ ユーザモードＴＬＳ：（ユーザ名、パスワード）に基づく
・ 最初にサーバ証明書によるＴＬＳハンドシェイクを実施してセキュアなコネクションを確立する。
・ ＳＬＰが、ＴＬＳ再交渉を開始するために“Ｈｅｌｌｏ Ｒｅｑｕｅｓｔ”を送信する。次に、ＳＥＴ及びＳＬＰは、（ユーザ名、パスワード）を用いてユーザを認証するためにＴＬＳ−ＳＲＰハンドシェイク（ＳＲＰ＝セキュアリモートパスワード）を実施する。
・ ＴＬＳ−ＳＲＰハンドシェイクにおいてユーザ名を隠すために最初のセキュアなコネクションが要求される。
選択肢Ｉ：オフライン手順概要
・ ＳＥＴがＴＬＳハンドシェイクを開始し、ＴＬＳにおいて、該当する暗号スィートを選択することによってＧＢＡ及び／又はユーザモードのためのサポートを示す。
・ ＳＬＰがＧＢＡモード又はユーザモードを進めるべきかどうかを決定する
・ ＧＢＡモードの場合
・ セキュアなトンネルを確立するためにＧＢＡを用いてＴＬＳ−ＰＳＫの場合と同じようにＴＬＳハンドシェイクを継続する
− 相互認証を提供する
・ セキュアなチャネルでデータをやり取りする
・ ユーザモードの場合
・セキュアなチャネルを確立するためにサーバ証明書によるＴＬＳハンドシェイクを継続する
− ＳＥＴがＳＬＰを認証する
・ セキュアなチャネルでデータをやり取りする
− ＳＬＰがユーザを認証するのを可能にする新しいパラメータがＳＥＴからのＵＬＰメッセージに加えられる（ユーザ名、カウンタ、ダイジェスト）
選択肢Ｉ：オンライン手順詳細−ＴＬＳハンドシェイク
・ ＳＥＴ→ＳＬＰ： Ｃｌｉｅｎｔ Ｈｅｌｌｏ：
・ すべてのサポートされた暗号スイートを示す
− ＳＥＴがＧＢＡをサポートする場合は、ＴＬＳ−ＰＳＫ暗号スイートのためのサポートを示す
− ＳＥＴがユーザモードをサポートする場合は、サーバ証明書を用いるＴＬＳのためのサポートを示す
・ ＳＬＰ→ＳＥＴ：Ｓｅｒｖｅｒ Ｈｅｌｌｏ
・ 選択された暗号スイートを示す
− ＳＬＰがＧＢＡモードを選択する場合は、ＳＬＰは、ＴＬＳ−ＰＳＫ暗号スイートを示す
− ＳＬＰがユーザモードを選択する場合は、ＳＬＰは、サーバ証明書を用いるＴＬＳのための暗号スイートを示す
・ 呼の流れは、選択された暗号スイートに関する場合と同じように進む
選択肢Ｉ：オンライン手順詳細−ＴＬＳハンドシェイク後
・ＧＢＡモード
・ ＳＥＴ及びＳＬＰがセキュアなチャネルを通じて通信を開始する
・ユーザモード
・ ＳＥＴ及びＳＬＰがセキュアなチャネルを通じて通信を開始する
・ ＳＥＴからのＵＬＰメッセージに新しいパラメータが加えられる：（ユーザ名、カウンタ、ダイジェスト）
− ＳＬＰが、ＵＬＰメッセージ内容を処理する前にカウンタ及びダイジェストを検証する
− カウンタの目的は、リプレイ検出を可能にすることである
− すべてのＵＬＰセッションに関して受信元及び送信元においてカウンタがリセットされる
− 送信元において、メッセージごとにカウンタが増分され、ＵＬＰメッセージに加えられる
− 受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ検出を渡す
選択肢ＩＩ：オンライン手順概要
・ ＳＥＴがＴＬＳハンドシェイクを開始し、該当する暗号スイートを選択することによってＧＢＡ及び／又はユーザモードのためのサポートをＴＬＳにおいて示す。
・ ＧＢＡモードの場合
・ セキュアなトンネルを確立するためにＧＢＡを用いてＴＬＳ−ＰＳＫの場合と同じようにＴＬＳハンドシェイクを継続する
− 相互認証を提供する
・ セキュアなチャネルでデータをやり取りする
・ ユーザモードの場合
・セキュアなチャネルを確立するためにサーバ証明書によるＴＬＳハンドシェイクを継続する
− ＳＥＴがＳＬＰを認証する
・ セキュアなチャネルでデータをやり取りする
− ＳＬＰがユーザを認証するのを可能にする新しいパラメータがＳＥＴからのＵＬＰメッセージに加えられる（ユーザ名、カウンタ、ダイジェスト）
選択肢Ｉ：オンライン手順詳細−ＴＬＳハンドシェイク
・ ＳＥＴ→ＳＬＰ： Ｃｌｉｅｎｔ Ｈｅｌｌｏ：
・ すべてのサポートされた暗号スイートを示す
− ＳＥＴがＧＢＡをサポートする場合は、ＴＬＳ−ＰＳＫ暗号スイートのためのサポートを示す
− ＳＥＴがユーザモードをサポートする場合は、サーバ証明書を用いるＴＬＳのためのサポートを示す
・ ＳＬＰ→ＳＥＴ：Ｓｅｒｖｅｒ Ｈｅｌｌｏ
・ 選択された暗号スイートを示す
− ＳＬＰがＧＢＡモードを選択する場合は、ＳＬＰは、ＴＬＳ−ＰＳＫ暗号スイートを示す
− ＳＬＰがユーザモードを選択する場合は、ＳＬＰは、サーバ証明書を用いるＴＬＳのための暗号スイートを示す
・ 呼の流れは、選択された暗号スイートに関する場合と同じように進む
選択肢Ｉ：オンライン手順詳細−ＴＬＳハンドシェイク後
・ＧＢＡモード
・ ＳＥＴ及びＳＬＰがセキュアなチャネルを通じて通信を開始する
・ユーザモード
・ ＳＥＴ及びＳＬＰがセキュアなチャネルを通じて通信を開始する
・ ＳＥＴからのＵＬＰメッセージに新しいパラメータが加えられる：（ユーザ名、カウンタ、ダイジェスト）
− ＳＬＰが、ＵＬＰメッセージ内容を処理する前にカウンタ及びダイジェストを検証する
− カウンタの目的は、リプレイ検出を可能にすることである
− すべてのＵＬＰセッションに関して受信元及び送信元においてカウンタがリセットされる
− 送信元において、メッセージごとにカウンタが増分され、ＵＬＰメッセージに加えられる
− 受信元において、カウンタが予想された値と比較される。リプレイが検出された場合は、誤りを有する状態で出る。そうでない場合は、メッセージがリプレイ検出を渡す
選択肢ＩＩ：オンライン手順概要
・ ＳＥＴがＴＬＳハンドシェイクを開始し、該当する暗号スイートを選択することによってＧＢＡ及び／又はユーザモードのためのサポートをＴＬＳにおいて示す。
・ ＳＬＰがＧＢＡモード又はユーザモードを進めるべきかどうかを決定する
・ ＧＢＡモードの場合
１．セキュアなトンネルを確立するためにＧＢＡを用いてＴＬＳ−ＰＳＫの場合と同じようにＴＬＳハンドシェイクを継続する
−相互認証
２．セキュアなチャネルでデータをやり取りする
・ ユーザモードの場合
１．最初に、セキュアなチャネルを確立するためにサーバ証明書によるＴＬＳハンドシェイクを継続する
−ＳＥＴがＳＬＰを認証する
２．ＴＬＳ−ＳＲＰハンドシェイクを実施する（メッセージは、セキュアなチャネル内部でやり取りされる）
−ＳＬＰがユーザを認証する
−新しいセッション鍵が得られる
３．新しいセッション鍵によって保護されたセキュアなトンネルでデータをやり取りする
選択肢ＩＩ：オンライン手順−最初のＴＬＳハンドシェイク
ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ Ｈｅｌｌｏ：
・ すべてのサポートされる暗号スイートを示す
− ＳＥＴがＧＢＡをサポートする場合は、ＴＬＳ−ＰＳＫ暗号スイートのためのサポートを示す
− ＳＥＴがユーザモードをサポートする場合は、サーバ証明書及びＴＬＳ ＳＲＰを用いるＴＬＳのためのサポートを示す
・ ＳＥＴはこの時点ではユーザ名を提供せず、要求される場合は、次のＴＬＳハンドシェイクで提供される。
・ ＳＬＰ→ＳＥＴ：Ｓｅｒｖｅｒ Ｈｅｌｌｏ：
・ 選択された暗号スイートを示す
− ＳＬＰがＧＢＡモードを選択する場合は、ＳＬＰは、ＴＬＳ−ＰＳＫ暗号スイートを示す
− ＳＬＰがユーザモードを選択する場合は、ＳＬＰは、サーバ証明書を用いるＴＬＳのための暗号スイートを示す
− 呼の流れが選択された暗号スイートの場合と同じように進む
選択肢ＩＩ：オンライン手順詳細−最初のＴＬＳハンドシェイク後
・ ＧＢＡモード
・ ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルを通じての通信を開始する
・ ユーザモード
・ ＳＬＰ→ＳＥＴ：Ｈｅｌｌｏ Ｒｅｑｅｕｓｔ
− 再交渉を開始する
・ ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ Ｈｅｌｌｏ
− ＴＬＳ−ＳＲＰのためのサポートを示す
− ＴＬＳ−ＳＲＰ仕様に準拠してユーザ名を含める
・ ＳＥＴ→ＳＬＰ：ＳｅｒｖｅｒＨｅｌｌｏ
− ＴＬＳ−ＳＲＰの選択を示す
− ＴＬＳ−ＳＲＰに準拠してやり取りを継続する
・ 成功裏のハンドシェイクに後続して、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでデータをやり取りすることを開始する
ＳＵＰＬ ＩＮＩＴ保護
・ ＳＵＰＬ３．０におけるＳＵＰＬ ＩＮＩＴ保護は、ＳＵＰＬ２．０におけるＳＵＰＬ ＩＮＩＴ保護メカニズムに基づき、ＳＵＰＬ ＩＮＩＴに添付されたメッセージ認証コード（ＭＡＣ）を使用する。
・ ＧＢＡモードの場合
１．セキュアなトンネルを確立するためにＧＢＡを用いてＴＬＳ−ＰＳＫの場合と同じようにＴＬＳハンドシェイクを継続する
−相互認証
２．セキュアなチャネルでデータをやり取りする
・ ユーザモードの場合
１．最初に、セキュアなチャネルを確立するためにサーバ証明書によるＴＬＳハンドシェイクを継続する
−ＳＥＴがＳＬＰを認証する
２．ＴＬＳ−ＳＲＰハンドシェイクを実施する（メッセージは、セキュアなチャネル内部でやり取りされる）
−ＳＬＰがユーザを認証する
−新しいセッション鍵が得られる
３．新しいセッション鍵によって保護されたセキュアなトンネルでデータをやり取りする
選択肢ＩＩ：オンライン手順−最初のＴＬＳハンドシェイク
ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ Ｈｅｌｌｏ：
・ すべてのサポートされる暗号スイートを示す
− ＳＥＴがＧＢＡをサポートする場合は、ＴＬＳ−ＰＳＫ暗号スイートのためのサポートを示す
− ＳＥＴがユーザモードをサポートする場合は、サーバ証明書及びＴＬＳ ＳＲＰを用いるＴＬＳのためのサポートを示す
・ ＳＥＴはこの時点ではユーザ名を提供せず、要求される場合は、次のＴＬＳハンドシェイクで提供される。
・ ＳＬＰ→ＳＥＴ：Ｓｅｒｖｅｒ Ｈｅｌｌｏ：
・ 選択された暗号スイートを示す
− ＳＬＰがＧＢＡモードを選択する場合は、ＳＬＰは、ＴＬＳ−ＰＳＫ暗号スイートを示す
− ＳＬＰがユーザモードを選択する場合は、ＳＬＰは、サーバ証明書を用いるＴＬＳのための暗号スイートを示す
− 呼の流れが選択された暗号スイートの場合と同じように進む
選択肢ＩＩ：オンライン手順詳細−最初のＴＬＳハンドシェイク後
・ ＧＢＡモード
・ ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルを通じての通信を開始する
・ ユーザモード
・ ＳＬＰ→ＳＥＴ：Ｈｅｌｌｏ Ｒｅｑｅｕｓｔ
− 再交渉を開始する
・ ＳＥＴ→ＳＬＰ：Ｃｌｉｅｎｔ Ｈｅｌｌｏ
− ＴＬＳ−ＳＲＰのためのサポートを示す
− ＴＬＳ−ＳＲＰ仕様に準拠してユーザ名を含める
・ ＳＥＴ→ＳＬＰ：ＳｅｒｖｅｒＨｅｌｌｏ
− ＴＬＳ−ＳＲＰの選択を示す
− ＴＬＳ−ＳＲＰに準拠してやり取りを継続する
・ 成功裏のハンドシェイクに後続して、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでデータをやり取りすることを開始する
ＳＵＰＬ ＩＮＩＴ保護
・ ＳＵＰＬ３．０におけるＳＵＰＬ ＩＮＩＴ保護は、ＳＵＰＬ２．０におけるＳＵＰＬ ＩＮＩＴ保護メカニズムに基づき、ＳＵＰＬ ＩＮＩＴに添付されたメッセージ認証コード（ＭＡＣ）を使用する。
・ ２つの認証法
○ ＧＢＡモード（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ， ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）＝（Ｂ−ＴＩＤ，Ｋｓ）
◆ （Ｂ−ＴＩＤ，Ｋｓ）がＢＳＦとのブートストラップから外される
○ ユーザモード：認証が（ユーザ名、パスワード）を使用する
・ ＳＵＰＬ ＩＮＩＴ保護は、選択肢Ｉ及び選択肢ＩＩに関して同じである
ＳＵＰＬ ＩＮＩＴ保護メカニズム
・ ＳＵＰＬｖ３．０において次の３つのタイプの保護が提供される
・ ＮＵＬＬ
− セキュリティなし
・ ＧＢＡモード保護
− ＳＵＰＬｖ２．０基本保護と同一である
・ ユーザモード保護
− （ユーザ名、パスワード）に基づく認証
− 辞書攻撃を防止するためにランダム値を加える
− リプレイを防止するために時間を加える
ＳＵＰＬ ＩＮＩＴ ＧＢＡモード保護
・ ＧＢＡ認証を使用する場合は、ＳＵＰＬ ＩＮＩＴプロテクタパラメータは、下記から成る。
○ ＧＢＡモード（Ｋｅｙ，Ｉｄｅｎｔｉｔｙ， ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ）＝（Ｂ−ＴＩＤ，Ｋｓ）
◆ （Ｂ−ＴＩＤ，Ｋｓ）がＢＳＦとのブートストラップから外される
○ ユーザモード：認証が（ユーザ名、パスワード）を使用する
・ ＳＵＰＬ ＩＮＩＴ保護は、選択肢Ｉ及び選択肢ＩＩに関して同じである
ＳＵＰＬ ＩＮＩＴ保護メカニズム
・ ＳＵＰＬｖ３．０において次の３つのタイプの保護が提供される
・ ＮＵＬＬ
− セキュリティなし
・ ＧＢＡモード保護
− ＳＵＰＬｖ２．０基本保護と同一である
・ ユーザモード保護
− （ユーザ名、パスワード）に基づく認証
− 辞書攻撃を防止するためにランダム値を加える
− リプレイを防止するために時間を加える
ＳＵＰＬ ＩＮＩＴ ＧＢＡモード保護
・ ＧＢＡ認証を使用する場合は、ＳＵＰＬ ＩＮＩＴプロテクタパラメータは、下記から成る。
・ 鍵識別子＝ＧＢＡ Ｂ−ＴＩＤ（長さ＝可変）
・ ＧＢＡ_ＲｅｐｌａｙＣｏｎｔｅｒ（長さ＝２オクテット）。リプレイを防止する
・ ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＭＡＣ（長さ＝４オクテット）。メッセージを認証する。
・ ＧＢＡ_ＲｅｐｌａｙＣｏｎｔｅｒ（長さ＝２オクテット）。リプレイを防止する
・ ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＭＡＣ（長さ＝４オクテット）。メッセージを認証する。
・ ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＭＡＣパラメータは、次のように生成される。
・ ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ_Ｚ）
・ ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“ＧＢＡ ＩＫ”
・ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、Ｂ−ＴＩＤに対応するＧＢＡ ｋｅｙ Ｋｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦである
・ ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ ＩＮＩＴメッセージである。
・ ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“ＧＢＡ ＩＫ”
・ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、Ｂ−ＴＩＤに対応するＧＢＡ ｋｅｙ Ｋｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦである
・ ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＧＢＡ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ ＩＮＩＴメッセージである。
・鍵識別子がリセットされたときにＧＢＡ_ＲｅｐｌａｙＣｏｕｎｔｅｒがリセットされる
ＳＵＰＬ ＩＮＩＴユーザモード保護
・ ユーザモードセキュリティを使用する場合は、ＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｏｒパラメータは、下記から成る。
ＳＵＰＬ ＩＮＩＴユーザモード保護
・ ユーザモードセキュリティを使用する場合は、ＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｏｒパラメータは、下記から成る。
・ ＳＵＰＬ_ＩＮＩＴ_ＲＡＮＤ（長さ＝８オクテット）。これは、パスワードに対する辞書攻撃を防止するためにこのメッセージにとって一意のランダムな値であることができる。
・ ＳＵＰＬ_ＩＮＩＴ_ＴＩＭＥ（長さ＝４オクテット）。メッセージ送信時間。リプレイを停止させる。
・ ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣ（長さ＝４オクテット）。メッセージを認証する。
・ ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣはパラメータ次のように生成される。
・ ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ_Ｚ）
・ ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＩＫ＝ＳＨＡ−２５６（Ｕｓｅｒｎａｍｅ
||“：”||Ｐａｓｓｗｏｒｄ“：”||ＳＬＰ_Ｄｏｍａｉｎ||“：ＳＵＰＬ３０ＩＮＩＴ”）
・ ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ ＩＮＩＴメッセージである。
・ ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＩＫ＝ＳＨＡ−２５６（Ｕｓｅｒｎａｍｅ
||“：”||Ｐａｓｓｗｏｒｄ“：”||ＳＬＰ_Ｄｏｍａｉｎ||“：ＳＵＰＬ３０ＩＮＩＴ”）
・ ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ ＩＮＩＴメッセージである。
概要
・ ＳＵＰＬ３．０では２つの新しいセキュリティモデルが考慮される。
・ ＳＵＰＬ３．０では２つの新しいセキュリティモデルが考慮される。
・ 選択肢Ｉ：ユーザモードＵＬＰ
・ 選択肢ＩＩ：ユーザモードＴＬＳ
・ これらの２つの新しいセキュリティモードは、（ユーザ名、パスワード）クライアント認証を使用し、サーバ認証及び暗号化は、レガシーのサーバ認証ＴＬＳに基づく。
・ 選択肢ＩＩ：ユーザモードＴＬＳ
・ これらの２つの新しいセキュリティモードは、（ユーザ名、パスワード）クライアント認証を使用し、サーバ認証及び暗号化は、レガシーのサーバ認証ＴＬＳに基づく。
・ 両選択肢とも、全ベアラをサポートする（ｂｅａｒｅｒ ａｇｎｏｓｔｉｃ）セキュリティモデルであり、このため、ＳＵＰＬ３．０に適する。
・ 該当する場合及び望ましい場合はレガシーセキュリティモデル（ＡＣＡ及びＧＢＡ）を依然として使用することができる。
追加の実施形態５
序論
・ ＯＭＡ ＳＵＰＬ２．０におけるセキュリティは、アクセスネットワーク専用である。
・ ＡＣＡ（代替クライアント認証）は、ソースＩＰアドレスに基づいてＳＥＴを識別するためのコアネットワークへのアクセスを要求する
・ ＧＢＡ（汎用ブートストラッピングアーキテクチャ）は、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・ ＳＥＫ（ＳＵＰＬ暗号化鍵）は、ＷｉＭＡＸネットワークのみに適用可能
・ ＯＭＡ ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
・ ＧＢＡ（汎用ブートストラッピングアーキテクチャ）は、３ＧＰＰ／３ＧＧＰ２ネットワークのみに適用可能
・ ＳＥＫ（ＳＵＰＬ暗号化鍵）は、ＷｉＭＡＸネットワークのみに適用可能
・ ＯＭＡ ＳＵＰＬ３．０における新しい要件では、全アクセスネットワークに適用可能な認証メカニズムが要求される。この実施形態は、全アクセスネットワークに適用可能な新しいセキュリティメカニズムについて説明する。
・ “ユーザ名／パスワード”認証に基づく単純な枠組
・ レガシーのＡＣＡ及びＧＢＡに基づくセキュリティもサポートされる
・ レガシーのＡＣＡ及びＧＢＡに基づくセキュリティもサポートされる
ＳＵＰＬ３．０セキュリティ概念概要ＩＩ
・ ＡＣＡ及びＧＢＡは、アクセスネットワーク専用であるが、該当する場合及びＳＵＰＬオペレータの選択に依存して使用することができる。
・ ＡＣＡ及びＧＢＡは、アクセスネットワーク専用であるが、該当する場合及びＳＵＰＬオペレータの選択に依存して使用することができる。
・ ユーザモードＴＬＳは、アクセスネットワークから独立しており、ＡＣＡの拡張とみなすことができる。
ユーザモードＴＬＳ−概要Ｉ
・ 公開鍵ＴＬＳサーバ認証−Ｈ−ＳＬＰ及びＳＬＰは、セキュアな状態で接続され、Ｈ−ＳＬＴは認証されるがＳＥＴは認証されない。
・ ユーザ名／パスワードＴＬＳ−ＳＲＰクライアント認証−Ｈ−ＳＬＰ及びＳＬＰは、セキュアな状態で接続され、Ｈ−ＳＬＴ及びＳＥＴの両方が認証される。
・ ユーザモードＴＬＳ
・ 最初に、セキュアな暗号化されたＩＰ接続を生成するＡＣＡの場合と同じように公開鍵ＴＬＳを用いてサーバが認証される
・ 次に、ＳＥＴ及びＳＬＰの両方において予めプロビジョニングされたユーザ名／パスワードを用いてＴＬＳ−ＳＲＰ（セキュアリモートパスワード）に基づいてクライアントが認証される
ユーザモードＴＬＳ概要ＩＩ
・ 単純なユーザ名／パスワードメカニズムは、問題及び／又は脅威を引き起こすおそれがある。
・ ユーザ名／パスワードが盗まれて異なるデバイスで使用されるおそれがある
・ ユーザ名／パスワードが自由意志で明かされて異なるデバイスで同時に使用されるおそれがある
・ これは以下によって解決することができる。
・ ユーザ名／パスワードが自由意志で明かされて異なるデバイスで同時に使用されるおそれがある
・ これは以下によって解決することができる。
・ ユーザ名／パスワードは、ＳＵＰＬサービス起動直後の最初のＳＵＰＬセッションのみに関して使用する
・ 最初のＳＵＰＬセッション中に、ＳＬＰが、新しいユーザ名／パスワードを生成して（最初のユーザ名／パスワードによって生成されたセキュアなＩＰ接続を用いて）ＳＥＴに送信する
・ 次に、ＳＥＴが最初のユーザ名／パスワードを新しいユーザ名／パスワードに取り代え、旧ユーザ名／パスワードを削除する
・ 次に、ＳＬＰによって生成されたユーザが見ることができないユーザ名／パスワードによってデバイスがＳＵＰＬサブスクリプション（subscription）にバインドされる。
・ 最初のＳＵＰＬセッション中に、ＳＬＰが、新しいユーザ名／パスワードを生成して（最初のユーザ名／パスワードによって生成されたセキュアなＩＰ接続を用いて）ＳＥＴに送信する
・ 次に、ＳＥＴが最初のユーザ名／パスワードを新しいユーザ名／パスワードに取り代え、旧ユーザ名／パスワードを削除する
・ 次に、ＳＬＰによって生成されたユーザが見ることができないユーザ名／パスワードによってデバイスがＳＵＰＬサブスクリプション（subscription）にバインドされる。
・ これで、すべての将来のセッションが、ＳＬＰによって生成された新しいユーザ名／パスワードを使用する。
・ その他のデバイスは、このユーザ名／パスワードは使用できない。
４つのステップによるユーザモードＴＬＳ
・ステップ１：ユーザ及びＳＬＰオペレータが一時的なユーザ名及びパスワードを取り決める：
（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）
・ステップ２：最初のＳＵＰＬセッションが確立される。サーバによって認証されたＴＬＳに基づいてサーバ認証及び暗号化が行われる。取り決められた（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）を用いてＴＬＳ−ＳＲＰ（ＳＲＰ＝セキュアリモートパスワード）に基づいてクライアント認証が行われる。
・ステップ３：最初のＳＵＰＬセッション内で、ＳＬＰが、ＳＥＴに送信する新しい暗号法的に強力な（ユーザ名、パスワード）を生成し、（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）を（ユーザ名、パスワード）に代える。ＳＥＴは、（ユーザ名、パスワード）をセキュアな場所に格納する。
・ステップ４：すべての後続するＴＬＳセッションが、サーバによって認証されたＴＬＳに基づいてサーバ認証及び暗号化を使用する。クライアント認証は、（ユーザ名、パスワード）を用いてＴＬＳ−ＳＲＰに基づいて行われる。
ユーザモードＴＬＳステップ１−詳細
・ ユーザ及びＳＬＰオペレータが一時的なユーザ名及びパスワードを取り決める：
（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）
・ （Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）は、様々な方法でＳＥＴにおいてプロビジョニングすることができる。
・ オペレータによるオーバーザエアでのプロビジョニング
・ オペレータのストアでプロビジョニング（ＳＥＴのフラッシング）
・ ユーザ名及びパスワードを郵送するかオンラインで入手し、ＳＥＴユーザが入力する
・ その他
・ ＳＥＴにはＳＬＰのＵＲＬがプロビジョニングされている
・ ＳＥＴには、ＳＬＰを認証するために要求される該当するルート証明書がプロビジョニングされている
ユーザモードＴＬＳステップ２−詳細
・ サーバの認証及び暗号化を開始するための最初のＳＵＰＬセッションの最初のＴＬＳハンドシェイク
・ ＳＥＴ→ＳＬＰ：サーバ証明書及びＴＬＳ−ＳＲＰによるＴＬＳのためのサポートを示すＣｌｉｅｎｔ Ｈｅｌｌｏ
・ ＳＬＰ→ＳＥＴ：サーバ証明書によるＴＬＳのための暗号スイートを示すＳｅｒｖｅｒ Ｈｅｌｌｏ
・ クライアント認証を開始するための２回目のＴＬＳハンドシェイク
・ ＳＬＰ→ＳＥＴ：再交渉を開始するためのＨｅｌｌｏ要求
・ ＳＥＴ→ＳＬＰ：ＴＬＳ−ＳＲＰのためのサポートを示し、ＴＬＳ−ＳＲＰ仕様に準拠したＵｓｅｒｎａｍｅ_ｔｅｍｐを含むＣｌｉｅｎｔ Ｈｅｌｌｏ
・ ＳＬＰ→ＳＥＴ：ＴＬＳ−ＳＲＰの選択を示すＳｅｒｖｅｒ Ｈｅｌｌｏ
・ クライアント認証は、（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）に基づいて行われる。
・ オペレータのストアでプロビジョニング（ＳＥＴのフラッシング）
・ ユーザ名及びパスワードを郵送するかオンラインで入手し、ＳＥＴユーザが入力する
・ その他
・ ＳＥＴにはＳＬＰのＵＲＬがプロビジョニングされている
・ ＳＥＴには、ＳＬＰを認証するために要求される該当するルート証明書がプロビジョニングされている
ユーザモードＴＬＳステップ２−詳細
・ サーバの認証及び暗号化を開始するための最初のＳＵＰＬセッションの最初のＴＬＳハンドシェイク
・ ＳＥＴ→ＳＬＰ：サーバ証明書及びＴＬＳ−ＳＲＰによるＴＬＳのためのサポートを示すＣｌｉｅｎｔ Ｈｅｌｌｏ
・ ＳＬＰ→ＳＥＴ：サーバ証明書によるＴＬＳのための暗号スイートを示すＳｅｒｖｅｒ Ｈｅｌｌｏ
・ クライアント認証を開始するための２回目のＴＬＳハンドシェイク
・ ＳＬＰ→ＳＥＴ：再交渉を開始するためのＨｅｌｌｏ要求
・ ＳＥＴ→ＳＬＰ：ＴＬＳ−ＳＲＰのためのサポートを示し、ＴＬＳ−ＳＲＰ仕様に準拠したＵｓｅｒｎａｍｅ_ｔｅｍｐを含むＣｌｉｅｎｔ Ｈｅｌｌｏ
・ ＳＬＰ→ＳＥＴ：ＴＬＳ−ＳＲＰの選択を示すＳｅｒｖｅｒ Ｈｅｌｌｏ
・ クライアント認証は、（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）に基づいて行われる。
・ 新しいセッション鍵が生成される（このセッション専用）
・ これで、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでＳＵＰＬセッションを実施することができる。
・ これで、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでＳＵＰＬセッションを実施することができる。
ユーザモードＴＬＳステップ３−詳細
・ ＳＬＰが一時的なユーザ名及びパスワード（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）に基づいて暗号的に強力な（ユーザ名、パスワード）を生成する。
・ 最初に、ＳＬＰからＳＥＴへのＳＵＰＬメッセージが暗号的に強力な（ユーザ名、パスワード）を搬送する。
・ ＳＥＴが一時的な（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）を（ユーザ名、パスワード）に代える。
・ ＳＥＴが一時的な（Ｕｓｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）を廃棄する。
・ ＳＥＴが（ユーザ名、パスワード）をセキュアな場所に格納する。
・ 注１：このステップは、ＳＬＰオペレータがユーザを関与させることなしにＳＥＴにおいてセキュアな状態でユーザ名／パスワードをプロビジョニングすることができた場合に実施することができる
・ 注２：３ＧＰＰ／３ＧＰＰ２における最初のアクセスに関しては、ＳＬＰは、ＳＥＴ ＩＰアドレスがＳＥＴ ＭＳＩＳＤＮ又はＩＭＳＩと関連付けられていることをコアネットワーク内で検証し、ＳＥＴがユーザに属することをさらに検証することができる
ユーザモードＴＬＳステップ４−詳細
・ 後続するＴＬＳセッションの確立に関して：
・ サーバの認証及び暗号化を開始するためのＴＬＳハンドシェイク：
− ＳＥＴ→ＳＬＰ：サーバ証明書及びＴＬＳ−ＳＲＰによるＴＬＳのためのサポートを示すＣｌｉｅｎｔ Ｈｅｌｌｏ
− ＳＬＰ→ＳＥＴ：サーバ証明書によるＴＬＳのための暗号スイートを示すＳｅｒｖｅｒ Ｈｅｌｌｏ
・ クライアント認証を開始するための第２のＴＬＳハンドシェイク：
− ＳＬＰ→ＳＥＴ：再交渉を開始するためのＨｅｌｌｏ Ｒｅｑｕｅｓｔ
− ＳＥＴ→ＳＬＰ：ＴＬＳ−ＳＲＰのためのサポートを示すＣｌｉｅｎｔ Ｈｅｌｌｏ及びＴＬＳ−ＳＲＰ仕様に準拠したユーザ名を含む
− ＳＬＰ→ＳＥＴ：ＴＬＳ−ＳＲＰの選択を示すＳｅｒｖｅｒ Ｈｅｌｌｏ
− クライアント認証が（ユーザ名、パスワード）に基づいて行われる
− 新しいセッション鍵が生成される
・ これで、ＳＥＴ及びＳＬＰが、セキュリティが確保されたチャネルでＳＵＰＬセッションを実施することができる。
・ 注：ＰＳＫ−ＴＬＳは、暗号的にセキュアなユーザ名／パスワードが提供された時点で後続するアクセスのために使用可能であるが、ＴＬＳ−ＳＲＰの再使用の方が低い複雑度で実装することができる。
ＳＵＰＬ ＩＮＩＴ保護概要
・ ＳＵＰＬ３．０におけるＳＵＰＬ ＩＮＩＴ保護は、ＳＵＰＬ２．０におけるＳＵＰＬ ＩＮＩＴ保護メカニズムに基づき、ＳＵＰＬ ＩＮＩＴに添付されたメッセージ認証コード（ＭＡＣ）を使用する
・ ＳＵＰＬ ｖ３．０では次の２つのタイプの保護が提供される：
・ ＧＢＡモード保護
− ＳＵＰＬ ｖ２．０の基本的保護と同一
・ ユーザモード保護
− ＳＬＰによって生成された（ユーザ名、パスワード）に基づく認証（すなわち、サービスの起動に使用された最初のユーザ名／パスワード（Ｕｓ ｅｒｎａｍｅ_ｔｅｍｐ，Ｐａｓｓｗｏｒｄ_ｔｅｍｐ）は使用しない）。
・ＮＵＬＬ保護もサポートされており、オペレータの選択に基づいて使用することができる。
ＳＵＰＬ ＩＮＩＴユーザモード保護Ｉ
・ユーザモードＴＬＳセキュリティを使用する場合は、ＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｏｒパラメータは、下記から成る。
・ ＳＵＰＬ_ＩＮＩＴ_ＴＩＭＥ（長さ＝４オクテット）。メッセージ送信時間。リプレイを停止させる。
・ ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣ（長さ＝４オクテット）。メッセージを認証する。
・ ＳＵＰＬ ＩＮＩＴプロテクタは、各ＳＵＰＬ ＩＮＩＴに加えられ、ＳＥＴが受信されたＳＵＰＬ ＩＮＩＴメッセージの真正性を検査するのを可能にする。
・ オペレータがＳＵＰＬ ＩＮＩＴ保護を使用する例外的ケース（例えば、ＳＥＴ及びＳＬＰが同期外れ）では、サービス拒否攻撃が保護されていないＳＵＰＬ ＩＮＩＴを多数のＳＥＴに送信することによってつけ込むことができないように（例えば、リセットコマンドを介して）ＳＥＴに明示されている限りにおいてＳＥＴを再プロビジョニングするためにヌルＳＵＰＬ ＩＮＩＴ保護を一時的に使用することができる。
ＳＵＰＬ ＩＮＩＴユーザモード保護ＩＩ
・ ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣパラメータは次のように生成される。
・ ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ_Ｚ）
・ ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＩＫ＝ＳＨＡ−２５６（Ｕｓｅｒｎａｍｅ||“：”||Ｐａｓｓｗｏｒｄ||“：”||ＳＬＰ_Ｄｏｍａｉｎ||“：ＳＵＰＬ３０ＩＮＩＴ”）
・ ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ ＩＮＩＴメッセージである。
・ ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＩＫ＝ＳＨＡ−２５６（Ｕｓｅｒｎａｍｅ||“：”||Ｐａｓｓｗｏｒｄ||“：”||ＳＬＰ_Ｄｏｍａｉｎ||“：ＳＵＰＬ３０ＩＮＩＴ”）
・ ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＵＳＥＲ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ ＩＮＩＴメッセージである。
概要
・ ＳＵＰＬ３．０に関して新しいセキュリティモデルが説明される：ユーザモードＴＬＳ。
・ ユーザモードＴＬＳは、（ユーザ名、パスワード）クライアント認証を使用し、他方、サーバ認証及び暗号化は、レガシーのサーバによって認証されたＴＬＳに基づく。
・ ＳＵＰＬ ＩＮＩＴ保護は、ユーザモードＴＬＳでもサポートされる。
・ ユーザモードＴＬＳは、全ベアラをサポートするセキュリティモデルであり、このため、ＳＵＰＬ３．０に適する。
・ ＳＵＰＬオペレータの選択に依存してレガシーセキュリティ
モデル（ＡＣＡ及びＧＢＡ）を依然として使用することができる。
モデル（ＡＣＡ及びＧＢＡ）を依然として使用することができる。
推奨
・ ユーザモードＴＬＳは、ＳＵＰＬ３．０のためのセキュリティモデルとして採用することができる。
・ レガシーのＡＣＡ及びＧＢＡセキュリティモデルに関してサポートを維持することができる。
ＳＵＰＬ３．０アクセスＳＬＰ（Ａ−ＳＬＰ）
・ ローミング中の加入者の場合は、精密な測位のサポートは、Ｈ−ＳＬＰプロバイダにとっては困難であるが、ローカルなローミングエリアの位置決定プロバイダにとってははるかに簡単である。
・ オペレータは、オペレータＢの加入者にとって有益な形でオペレータＡに属するＨ−ＳＬＰを一時的に利用することが可能なその他のオペレータ及びプロバイダと取引関係にある場合がある。
・ ＳＵＰＬ３．０ＲＤは、ＳＬＰのより広範な利用可能性及びＳＬＰへのより容易なアクセスに関する要件を含む。
・ ＳＵＰＬ−ＥＭＥＲ−０３：ＳＵＰＬは、緊急な位置決定要求のためのＳＥＴによって開始される及びネットワークによって開始される測位をサポートするものとする
・ ＳＵＰＬ−ＨＬＦ−１８：ＳＵＰＬは、ＳＬＰサービス発見をサポートするものとする
・ Ｈ−ＳＬＰを有していない加入者が存在することもある−例えば、ホームオペレータがＳＵＰＬをサポートしていない−又は任意でＨ−ＳＬＰ ＳＵＰＬサポートを使用していないことがある
・ ＳＵＰＬサポートをローミング中の加入者に拡張することを希望するオペレータが存在することがある−例えば、Ｈ−ＳＬＰを有さないそれら又はＨ−ＳＬＰが特定のローミングエリア内の位置を適切にサポートできないそれら
アクセスＳＬＰ（Ａ−ＳＬＰ）
・ Ａ−ＳＬＰは、アクセスネットワークプロバイダに属すること、アクセスネットワークと関連付けること又はアクセスネットワークの地理的エリアをサポートすることができる
・ Ａ−ＳＬＰは、Ｈ−ＳＬＰとほぼ同一の方法でＳＵＰＬ３．０をサポートすることができ、例えば、すべてのネットワークサービスとＳＥＴによって開始されるサービスとを含む
・ ＳＥＴは、Ａ−ＳＬＰを発見すること又はＡ−ＳＬＰに関する情報（例えば、Ａ−ＳＬＰアドレス及びセキュリティパラメータ）が提供されることが必要になる
・ 可能な情報源は、アクセスネットワーク、Ｈ−ＳＬＰ、及び独立した（非標準化された）発見である
・ Ａ−ＳＬＰセキュリティは、Ｈ−ＳＬＰに関して定義される方法を再使用する−例えば、異なる認証方法は回避するべきである
・ ＳＥＴ及びＡ−ＳＬＰは、外部のＳＵＰＬエージェント及びＳＥＴの両方のためのＳＵＰＬ３．０サービスをサポートするために限定された予め取り決められた期間だけ対話することができる
可能なＡ−ＳＬＰ使用法
・ ＳＥＴは、アクセスネットワークを介してＵＬＰ３．０メッセージを用いてＳＬＰと通信し及び（Ａ−ＳＬＰを発見及び検証するために任意選択で使用される）ホームネットワークを介してＵＬＰ３．０メッセージを用いてＨ−ＳＬＰと通信する。
・ ＳＵＰＬ−ＨＬＦ−１８：ＳＵＰＬは、ＳＬＰサービス発見をサポートするものとする
・ Ｈ−ＳＬＰを有していない加入者が存在することもある−例えば、ホームオペレータがＳＵＰＬをサポートしていない−又は任意でＨ−ＳＬＰ ＳＵＰＬサポートを使用していないことがある
・ ＳＵＰＬサポートをローミング中の加入者に拡張することを希望するオペレータが存在することがある−例えば、Ｈ−ＳＬＰを有さないそれら又はＨ−ＳＬＰが特定のローミングエリア内の位置を適切にサポートできないそれら
アクセスＳＬＰ（Ａ−ＳＬＰ）
・ Ａ−ＳＬＰは、アクセスネットワークプロバイダに属すること、アクセスネットワークと関連付けること又はアクセスネットワークの地理的エリアをサポートすることができる
・ Ａ−ＳＬＰは、Ｈ−ＳＬＰとほぼ同一の方法でＳＵＰＬ３．０をサポートすることができ、例えば、すべてのネットワークサービスとＳＥＴによって開始されるサービスとを含む
・ ＳＥＴは、Ａ−ＳＬＰを発見すること又はＡ−ＳＬＰに関する情報（例えば、Ａ−ＳＬＰアドレス及びセキュリティパラメータ）が提供されることが必要になる
・ 可能な情報源は、アクセスネットワーク、Ｈ−ＳＬＰ、及び独立した（非標準化された）発見である
・ Ａ−ＳＬＰセキュリティは、Ｈ−ＳＬＰに関して定義される方法を再使用する−例えば、異なる認証方法は回避するべきである
・ ＳＥＴ及びＡ−ＳＬＰは、外部のＳＵＰＬエージェント及びＳＥＴの両方のためのＳＵＰＬ３．０サービスをサポートするために限定された予め取り決められた期間だけ対話することができる
可能なＡ−ＳＬＰ使用法
・ ＳＥＴは、アクセスネットワークを介してＵＬＰ３．０メッセージを用いてＳＬＰと通信し及び（Ａ−ＳＬＰを発見及び検証するために任意選択で使用される）ホームネットワークを介してＵＬＰ３．０メッセージを用いてＨ−ＳＬＰと通信する。
・ Ａ−ＳＬＰは、ＭＬＰを介してＳＵＰＬエージェントと通信する。
ユーザ事例
・ 例１−ユーザが新しい都市、町、観光地、等を訪れる
・ Ｈ−ＳＬＰは、絶対位置しかサポートすることができず、さらに常に正確であるわけではなく（例えば、建物内の場合）、及び、補助情報、例えば、対象地点、地図、天候／交通情報、等、を提供できないことがある。
・ Ａ−ＳＬＰは、アプリケーションレベルのサービス（ＳＵＰＬの一部でない）、例えば、方向の発見、対象地点、地図、天候／交通、等とともにより連続的な正確な位置サポートを提供することが可能である。
・ 例２−緊急呼サポート
・ Ａ−ＳＬＰがＥ−ＳＬＰ能力もサポートする場合は、ＳＥＴによるＡ−ＳＬＰの発見がのちのＩＰに基づく緊急呼に役立つことができる。
・ Ａ−ＳＬＰがＥ−ＳＬＰ能力もサポートする場合は、ＳＥＴによるＡ−ＳＬＰの発見がのちのＩＰに基づく緊急呼に役立つことができる。
・ ＳＥＴは、Ａ−ＳＬＰからおおよその位置を入手してそれを緊急ＳＩＰ ＩＮＶＩＴＥ内に含め、それによって呼のルーティングを援助するという選択肢を有する。
・ ＳＥＴとＡ−ＳＬＰ／Ｅ−ＳＬＰとの間での事前の関連付けも、ＰＳＡＰディスパッチのためののちのより正確な位置決定に役立つことができる。
Ａ−ＳＬＰセキュリティ−１
・ Ｈ−ＳＬＰの場合と同じセキュリティ手順が可能である
・ １つの適切なセキュリティ方法は、ＯＭＡ−ＬＯＣ−２０１０−０ｘｙｚ−ＩＮＰ_ＳＵＰＬ_３．０_Ｓｅｃｕｒｉｔｙにおいて説明されるユーザモードＴＬＳである−例えば、これは、ＧＢＡのサポート、３ＧＰＰ／３ＧＰＰ２専用アクセス、ＳＥＴを直接構成する能力を要求しない
・ Ａ−ＳＬＰオペレータ又はＨ−ＳＬＰオペレータ（両オペレータ間に取引関係が存在する場合）は、最初のユーザ名／パスワードを割り当てることができる。
・ Ａ−ＳＬＰは、その他のデバイスによる最初のユーザ名／パスワードの使用を回避するために最初のＳＵＰＬセッションでそのユーザ名／パスワードを新しい値に代えることができる。
・ Ａ−ＳＬＰオペレータは、ユーザ名／パスワードをプロビジョニングされたＳＥＴが意図されるユーザに属することを常に検証することができるわけではないが、これは、ＳＥＴによって開始されたサービスに主に焦点を合わせ及びすべてのローミングユーザに関して同じ料金が課金されるＡ−ＳＬＰサービスにとっては重要ではない。
・ 注：ほとんどの場合は、ユーザは、Ａ−ＳＬＰへのアクセスの喪失をＡ−ＳＬＰプロバイダに報告し（例えば、最初のユーザ名／パスワードが他のユーザによって入手されて使用される場合）、現在のユーザ／パスワードを無効にして新しいユーザ名／パスワードに代えることを可能にすることができる。
Ａ−ＳＬＰセキュリティ−２
・ １つの任意選択肢として、Ｈ−ＳＬＰは、Ａ−ＳＬＰを発見するために、検証するために及びＡ−ＳＬＰのためのセキュリティのサポートを援助するために使用することができる。
・ ＳＥＴは、これらのパラメータのうちの１つを用いてＨ−ＳＬＰにＵＬＰ要求を送信することができる。
・ （Ａ）現在のＳＥＴ位置又はサービスを提供するアクセスネットワークのアイデンティティ
・ （Ｂ）既に発見済みのＡ−ＳＬＰアドレス（例えば、オンラインで見つけられるか又はアクセスネットワークによって提供）
・ （Ａ）に関しては、Ｈ−ＳＬＰは、ローカルエリアにサービスを提供する信用されるＡ−ＳＬＰのアドレスを返信することができる。
・ （Ｂ）既に発見済みのＡ−ＳＬＰアドレス（例えば、オンラインで見つけられるか又はアクセスネットワークによって提供）
・ （Ａ）に関しては、Ｈ−ＳＬＰは、ローカルエリアにサービスを提供する信用されるＡ−ＳＬＰのアドレスを返信することができる。
・ （Ｂ）に関しては、Ｈ−ＳＬＰは、Ａ−ＳＬＰが信用される、信用されないか又はＨ−ＳＬＰにとって未知であるかどうかを示すことができる。
・ 信用される事例における（Ａ）及び（Ｂ）に関しては、Ｈ−ＳＬＰは、Ａ−ＳＬＰ又はＨ−ＳＬＰのいずれかによって割り当てられた最初のユーザ名／パスワードを任意選択でＳＥＴに提供することができる（ユーザ名／パスワード及びユーザ識別を転送するためにＡ−ＳＬＰとＨ−ＳＬＰ又は関連付けられたプロバイダとの間での何らかの追加の対話が要求される）
ＳＵＬＰ３．０ＡＤ及びＴＳの影響
・ （既存のＨ−ＳＬＰ、Ｖ−ＳＬＰ、Ｅ−ＳＬＰとともに）Ａ−ＳＬＰを定義する
・ 適切な発見メカニズムを定義又は参照する
・ ユーザモードＴＳＬセキュリティの使用を示す
・ Ａ−ＳＬＰの発見、検証及びセキュリティのための適切なＨ−ＳＬＰのサポートを加える
・ （各端部が新しいセッションのためにサポートするサービスを他方に知らせる既存のＳＵＰＬ３．０メッセージフローにおいて既にサポートされるように）ＳＥＴ及びＡ−ＳＬＰがサポートされるサービスをＨ−ＳＬＰ対話のために用いられるそれらの部分組に限定するのを可能にする
・ あらゆる新しいプライバシー要件（存在する場合）を識別及びサポートする
Ｈ−ＳＬＰサービスとの関係
・ Ｈ−ＳＬＰプロバイダは、何らかの取引関係が存在する幾つかのＡ−ＳＬＰプロバイダをサポートすることを選択することができる。
ＳＵＬＰ３．０ＡＤ及びＴＳの影響
・ （既存のＨ−ＳＬＰ、Ｖ−ＳＬＰ、Ｅ−ＳＬＰとともに）Ａ−ＳＬＰを定義する
・ 適切な発見メカニズムを定義又は参照する
・ ユーザモードＴＳＬセキュリティの使用を示す
・ Ａ−ＳＬＰの発見、検証及びセキュリティのための適切なＨ−ＳＬＰのサポートを加える
・ （各端部が新しいセッションのためにサポートするサービスを他方に知らせる既存のＳＵＰＬ３．０メッセージフローにおいて既にサポートされるように）ＳＥＴ及びＡ−ＳＬＰがサポートされるサービスをＨ−ＳＬＰ対話のために用いられるそれらの部分組に限定するのを可能にする
・ あらゆる新しいプライバシー要件（存在する場合）を識別及びサポートする
Ｈ−ＳＬＰサービスとの関係
・ Ｈ−ＳＬＰプロバイダは、何らかの取引関係が存在する幾つかのＡ−ＳＬＰプロバイダをサポートすることを選択することができる。
・ Ｈ−ＳＬＰプロバイダは、その他のオペレータからのローミング加入者へのＡＳＬプロバイダとしてサポートを提供することもできる
・ ＳＥＴは、次のようにＡ−ＳＬＰアクセスを制御するように構成することが可能である。
・ ＳＥＴは、次のようにＡ−ＳＬＰアクセスを制御するように構成することが可能である。
ａ）常にＨ−ＳＬＰを使用し、Ａ−ＳＬＰの使用を禁止する
ｂ）Ｈ−ＳＬＰを優先するがＨ−ＳＬＰによる承認を条件としてＡ−ＳＬＰの使用を許容する（例えば、Ｈ−ＳＬＰプロバイダとのローミング契約が存在するときのみにＡ−ＳＬＰアクセスを許容する）
ｃ）ＳＥＴがそれ自体の判定基準に基づいてＨ−ＳＬＰの使用又はＡ−ＳＬＰの使用を自由に決定するのを許容する
ｄ）常にＡ−ＳＬＰを使用する（例えば、Ｈ−ＳＬＰが存在しないときに該当する）
・ 正味の結果として、ＳＵＰＬ３．０の使用法及び関連付けられた配備を向上させ、プロバイダ及びユーザにとって有益になることができる
・ Ａ−ＳＬＰサポートをＳＵＰＬ３．０の一部として含めることができる
・ Ｈ−ＳＬＰセキュリティサポートを再使用し及びＨ−ＳＬＰがＡ−ＳＬＰへのアクセスを援助又は制御するのを許容する
・ あるレベルの非ＳＵＰＬサポートを考慮する（例えば、Ａ−ＳＬＰの発見及びＡ−ＳＬＰプロバイダとＨ−ＳＬＰプロバイダとの間での対話に関して）
追加の実施形態６
序論
・ 本実施形態は、クライアント認証のためにデバイス証明書を使用する。
ｂ）Ｈ−ＳＬＰを優先するがＨ−ＳＬＰによる承認を条件としてＡ−ＳＬＰの使用を許容する（例えば、Ｈ−ＳＬＰプロバイダとのローミング契約が存在するときのみにＡ−ＳＬＰアクセスを許容する）
ｃ）ＳＥＴがそれ自体の判定基準に基づいてＨ−ＳＬＰの使用又はＡ−ＳＬＰの使用を自由に決定するのを許容する
ｄ）常にＡ−ＳＬＰを使用する（例えば、Ｈ−ＳＬＰが存在しないときに該当する）
・ 正味の結果として、ＳＵＰＬ３．０の使用法及び関連付けられた配備を向上させ、プロバイダ及びユーザにとって有益になることができる
・ Ａ−ＳＬＰサポートをＳＵＰＬ３．０の一部として含めることができる
・ Ｈ−ＳＬＰセキュリティサポートを再使用し及びＨ−ＳＬＰがＡ−ＳＬＰへのアクセスを援助又は制御するのを許容する
・ あるレベルの非ＳＵＰＬサポートを考慮する（例えば、Ａ−ＳＬＰの発見及びＡ−ＳＬＰプロバイダとＨ−ＳＬＰプロバイダとの間での対話に関して）
追加の実施形態６
序論
・ 本実施形態は、クライアント認証のためにデバイス証明書を使用する。
・ ＡＣＡ及びＧＢＡはアクセスネットワーク専用であるが、該当する場合及びＳＵＰＬオペレータの選択に依存して使用することができる。
・ この実施形態の新しいセキュリティモデルは、デバイス証明書を用いたクライアント認証である。デバイス証明書に基づくクライアント認証は、アクセスネットワークから独立しており、従って、全タイプのアクセスネットワーク及びデバイスに関して使用することができる（すなわち、３ＧＰＰ／３ＧＰＰ２でないアクセスネットワーク及びデバイスがサポートされる）。
デバイスの事前プロビジョニング
・ メーカーは、製造中に下記の項目をＳＥＴ内でプロビジョニングする。
・ そのＳＥＴデバイスに一意の秘密鍵
・ 対応する公開鍵を１つ以上のグローバルで一意のＳＥＴデバイスアイデンティティ（例えば、一連番号、ＩＭＥＩ又はＭＳＩＤ）にバインドさせる証明書
・ １つ以上の一連の証明書が潜在的なＳＬＰによって信用されることになるよく知られた証明書機関に戻される
・ 注：ＳＬＰによって信用されたＣＡへ戻る一連の連鎖が存在しない場合は、ＳＬＰは、ＳＥＴ認証を信用しない。
・ ＳＬＰは、ＳＬＰの証明書を検証するために使用することができる１つ以上のルート証明書がＳＥＴにプロビジョニングされていることを確認する責任を有する
・ これらのルート証明書は、ＳＥＴの製造中又は配布中にプロビジョニングすることができる
・ これらのルート証明書は、ＳＵＰＬクライアントソフトウェアとバンドリングすることができる。
・ 対応する公開鍵を１つ以上のグローバルで一意のＳＥＴデバイスアイデンティティ（例えば、一連番号、ＩＭＥＩ又はＭＳＩＤ）にバインドさせる証明書
・ １つ以上の一連の証明書が潜在的なＳＬＰによって信用されることになるよく知られた証明書機関に戻される
・ 注：ＳＬＰによって信用されたＣＡへ戻る一連の連鎖が存在しない場合は、ＳＬＰは、ＳＥＴ認証を信用しない。
・ ＳＬＰは、ＳＬＰの証明書を検証するために使用することができる１つ以上のルート証明書がＳＥＴにプロビジョニングされていることを確認する責任を有する
・ これらのルート証明書は、ＳＥＴの製造中又は配布中にプロビジョニングすることができる
・ これらのルート証明書は、ＳＵＰＬクライアントソフトウェアとバンドリングすることができる。
・ 注：ＳＬＰ証明書からこれらのルート証明書まで戻る一連の証明書が存在しない場合は、ＳＥＴは、ＳＬＰを認証することができない。
・ ＯＭＡ−ＬＯＣは、実装及び試験を簡略化及び統一するために共通のテンプレート又はプロフィールを規定することができる。
・ ＯＭＡ−ＬＯＣは、実装及び試験を簡略化及び統一するために共通のテンプレート又はプロフィールを規定することができる。
デバイス証明書概要
・ステップ１：加入者認証（範囲外）
・ 加入者が、このデバイスは加入と関連付けられるべきであることをセキュアな形でＳＬＰに検証する
・ステップ２：ランタイムＴＬＳハンドシェイク
・ 最初に：サーバ証明書を用いてサーバによって認証されたＴＬＳハンドシェイクを行う
・ 次に：暗号化されたＴＬＳトンネル内で、サーバ証明書及びクライアント証明書を用いて相互に認証されたＴＬＳハンドシェイクを行う。
・ これで、セキュアな状態でデータをやり取りすることができる。
（範囲外）（ｏｕｔ ｏｆ ｓｃｐｏｅ）加入者認証Ｉ
・ ＳＥＴのアイデンティティのみが認証され、加入者のアイデンティティは認証されないため、ＳＬＰは、いずれの加入者が（認証された）ＳＥＴと関連付けられるべきかを知っている。
・ これは、加入者がＳＥＴ間で切り換わる回数だけ生じる。
・ ユーザがＳＬＰにＳＥＴのアイデンティティを提供するだけでは十分でないことがある。
・ 理由：ユーザ１は、ユーザ２のＳＥＴ ＩＤをＳＬＰに提供して“これは私のＳＥＴです”と言うことができる。ＳＬＰは、何が起きているかをユーザ２が承知しない状態でユーザ２の位置の詳細をユーザ１に提供することがある。
・ セキュアな形で加入者をＳＥＴ ＩＤと関連付けるためにセキュアな方法が使用される。
・ 方法が範囲外の状態にされる。
・幾つかのシステムは、セキュアな形でデバイスアイデンティティを加入者（例えば、Ａｐｐｌｅ、Ｂｌａｃｋｂｅｒｒｙ）と関連付けるためのメカニズムを既に有する。
・ 方法例が以下において提供される。
（範囲外）加入者認証ＩＩ
・ セキュアな形で加入者をデバイスアイデンティティと関連付けるための方法例
・ ＳＬＰオペレータが、ＳＥＴを使用中にＳＬＰによって所有されるウェブサイトに接続するように加入者をプロンプトする。
・ 加入者がＳＥＴを使用しながらウェブサイト（おそらくＷＡＰ）に接続する。
・ ウェブサーバがデバイス証明書及びウェブサーバ証明書によるＴＳＬハンドシェイクを要求する。
・ この証明書は、ＳＬＰサービサー（ｓｅｒｖｉｃｅｒ）と別個であることができる。
・ 加入者がウェブサイトと何らかの（範囲外の）認証を実施する。例えば、ウェブサイトは、ＳＬＰ専用のユーザ名／パスワード、認定された（ｆｅｄｅｒａｔｅｄ）ユーザ名／パスワード又はその他の加入者詳細、例えば、アドレス、誕生日、等、を要求することができる。
・ これで、ＳＬＰオペレータが、セキュアな形で加入者をデバイスアイデンティティと関連付けており、この関連付けをＳＬＰ内に格納すべきである。
ランタイムＴＬＳハンドシェイク概要
・ デバイス証明書に基づくクライアント認証
・ 最初に、セキュアな暗号化されたＩＰ接続を生成するＡＣＡの場合と同じように公開鍵ＴＬＳを用いてサーバが認証される
・ これは、デバイス証明書においてデバイスのアイデンティティを隠すことによって匿名性を保持する
・ 次に、クライアント及びサーバが、サービス証明書及びデバイス証明書に基づいて相互に認証されたＴＬＳを行う
ランタイムＴＬＳハンドシェイク詳細
・ サーバによって認証されたセキュリティが確保されたトンネルを開始するための最初のＳＵＰＬセッションの最初のＴＬＳハンドシェイク
・ ＳＥＴ→ＳＬＰ：サーバ証明書及びデバイス証明書によるＴＬＳのためのサポートを示すＣｌｉｅｎｔ Ｈｅｌｌｏ
・ ＳＬＰ→ＳＥＴ：サーバ証明書によるＴＬＳのための暗号スイートを示すＳｅｒｖｅｒ Ｈｅｌｌｏ
ＳＬＰ←→ＳＥＴ：セキュリティが確保されたトンネルを確立するためのＴＬＳハンドシェイクを完了させる
・ 相互認証を行うための２回目のＴＬＳハンドシェイク
・ ＳＬＰ→ＳＥＴ：再交渉を開始するためのＨｅｌｌｏ Ｒｅｑｕｅｓｔ
・ ＳＥＴ→ＳＬＰ：サーバ証明書及びデバイス証明書によるＴＬＳのためのサポートを示すＣｌｉｅｎｔ Ｈｅｌｌｏ
・ ＳＬＰ→ＳＥＴ：サーバ証明書及びデバイス証明書によるＴＬＳの選択を示すＳｅｒｖｅｒ Ｈｅｌｌｏ
ＳＰＬ←→ＳＥＴ：セキュリティが確保されたトンネルを確立するためのＴＬＳハンドシェイクを完了させる
・ これで、ＳＥＴ及びＳＬＰは、セキュリティが確保されたチャネルでＳＵＰＬセッションを行うことができる
証明書取り消し
・ デバイス証明書及びサーバ証明書の両方を取り消すことができる
・ デバイス及びサーバの両方が、デバイス証明書が取り消されているかどうかを検査するために証明書取り消しリスト（例えば、［ＲＦＣ３２８０］）又はオンライン証明書状態プロトコル（ＯＣＳＰ）［ＲＦＣ２５６０］、等の方法を使用することができる。
・ 特定の方法は、段階３で考慮される。
ＳＵＰＬ ＩＮＩＴ保護概要
・ ＳＵＰＬ３．０でのＳＵＰＬ ＩＮＩＴ保護は、ＳＵＰＬ２．０におけるＳＵＰＬ ＩＮＩＴ保護メカニズムに基づいており、ＳＵＰＬ ＩＮＩＴに添付されたメッセージ認証コード（ＭＡＣ）を使用する
・ このセキュリティは、ＳＬＰに対するサービス拒否攻撃を防止することが目的である。
・ ＳＵＰＬ ｖ３．０は、ＳＵＰＬ ｖ２．０と同じ保護を提供する：
・ モードＡ保護
− ＧＢＡに基づくクライアント認証を使用する場合に適用される
− ＳＵＰＬ ｖ２．０の基本的保護と同一である
− ＧＢＡに基づくＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを使用する
− モードＢ保護
− ＳＵＰＬ ｖ３．０は、ＳＬＰによってプロビジョニングされたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いてサポートを追加している
− ＡＣＡ及びデバイス証明書クライアント認証をサポートする
・ ＮＵＬＬ保護もサポートされており、オペレータの選択に基づいて使用することができる。
・ モードＡ保護
− ＧＢＡに基づくクライアント認証を使用する場合に適用される
− ＳＵＰＬ ｖ２．０の基本的保護と同一である
− ＧＢＡに基づくＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを使用する
− モードＢ保護
− ＳＵＰＬ ｖ３．０は、ＳＬＰによってプロビジョニングされたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いてサポートを追加している
− ＡＣＡ及びデバイス証明書クライアント認証をサポートする
・ ＮＵＬＬ保護もサポートされており、オペレータの選択に基づいて使用することができる。
・ ＳＵＰＬ ｖ３．０は、ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹをプロビジョニングするためのメカニズムを追加している
モードＢ保護ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ
・ モードＢ ＳＵＰＬ_ＩＮＩＴ保護は、ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹをデバイスにプロビジョニングすることを要求する
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、デバイスと加入者のこの組み合わせに関して一意である。
モードＢ保護ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ
・ モードＢ ＳＵＰＬ_ＩＮＩＴ保護は、ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹをデバイスにプロビジョニングすることを要求する
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、デバイスと加入者のこの組み合わせに関して一意である。
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、サービス拒否攻撃に対する保護をＳＬＰに提供するためだけに使用することができることに注目すること。
・ 鍵を開示してもどのようなユーザデータも開示しない。
・ 鍵を開示しても、サービス拒否攻撃に関わる可能性がある１つの余分のデバイスを追加することになるにすぎない。
・ 各ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、ほとんど価値を有さないため、この鍵は、有効な形で“永久的”であり、加入と関連付けられたその他の詳細とともに格納することができる。
・ すなわち、これらの鍵のセキュリティを保護するための特別なサーバが必要ない。
・ 注：ＵＮＩＣＣが取り除かれることは所有権の変更を示すため、その場合は、ＳＥＴはＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを削除する。
モードＢ手順
・ モードＢのプロビジョニングを開始
・ モードＢのプロビジョニングを開始するための手順
・ モードＢのプロビジョニング
・ ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹをＳＥＴにプロビジョニングする
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いないモードＢ使用法
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹがプロビジョニングされていない場合は、ＳＥＴは、ＭＡＣを検証せずにＳＬＰから受け取る最初のＳＵＰＬ_ＩＮＩＴメッセージを受け入れる。
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いるモードＢ使用法
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹがプロビジョニングされた時点で、ＳＥＴは、ＭＡＣ及び時間が正確に検証された場合にＳＬＰから受け取ったＳＵＰＬ_ＩＮＩＴメッセージを受け入れ、そうでない場合はＳＵＰＬ_ＩＮＩＴメッセージを受け入れない。
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹがプロビジョニングされた時点で、ＳＥＴは、ＭＡＣ及び時間が正確に検証された場合にＳＬＰから受け取ったＳＵＰＬ_ＩＮＩＴメッセージを受け入れ、そうでない場合はＳＵＰＬ_ＩＮＩＴメッセージを受け入れない。
・モードＢ例外−ハードリセット
モードＢプロビジョニング開始
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのプロビジョニングを開始すると、ＳＥＴとＳＬＰとの間での（セキュリティが確保された）ＵＬＰセッション中にＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの提供が生じる
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのプロビジョニングを開始する
・ セキュリティが確保されたＵＬＰセッションの開始時に、ＳＥＴがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有していないことに気がついた場合は、ＳＥＴは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ_Ｒｅｑｕｅｓｔインジケータを最初のＵＬＰメッセージに含めることによってＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのプロビジョニングを開始する。
・ ＳＥＴは、セッションが生じない場合はある期間にわたる幾つかの回数のＳＵＰＬ ＩＮＩＴの失敗後に（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを要求するための）ＳＵＰＬセッションを生じさせるように構成することができることに注目すること。
・ ＳＥＴ内のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが壊れているのではないかとＳＬＰが思う場合（例えば、ＳＥＴがある時間にわたってＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹに応答していない場合）は、ＳＬＰは、最初のＵＬＰメッセージをＳＥＴから受信後にＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのプロビジョニングを開始することができる。
モードＢのプロビジョニング
・ 注：この手順は、“モードＢプロビジョニング開始”に準拠する。
・ ＳＬＰがモードＢ保護をサポートしないことを選択している場合は、ＳＬＰは、該当する表示をＳＥＴに送信する。
・ その他の場合
・ ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを入手する
・ ＳＬＰがＳＥＴと加入者のこの組み合わせと関連付けられた既存のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、ＳＬＰは、それのレコードからこの値を取り出す
・ ＳＬＰがＳＥＴと加入者のこの組み合わせと関連付けられた既存のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない場合は、ＳＬＰは、新しいＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを生成する。
・ ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを入手する
・ ＳＬＰがＳＥＴと加入者のこの組み合わせと関連付けられた既存のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、ＳＬＰは、それのレコードからこの値を取り出す
・ ＳＬＰがＳＥＴと加入者のこの組み合わせと関連付けられた既存のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない場合は、ＳＬＰは、新しいＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを生成する。
・ ＳＬＰが、セキュリティが確保されたＵＬＰメッセージ内のパラメータとしてＳＥＴにＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを送信する
・ ＳＥＴがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの値を格納する。
・ ＳＥＴがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの値を格納する。
・ ＳＥＴは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの格納された値が壊れているかどうかをＳＥＴがのちに検出することを可能にすることになる格納された値の何らかの保護を適用することができる。該保護の例は、誤り訂正及び／又は完全性検査を含む。
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さないモードＢ使用法
・ ＳＥＴは、モードＢ保護を適用可能であるが、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない状態になることがある。例は、下記を含む。
・ パワーアップ時で、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹがプロビジョニングされる前。
・ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが壊れているか又は削除されている。
・ ＳＥＴが該状態にある場合は、ＳＥＴは、ＭＡＣを検証せずに、ＳＬＰから受信した最初のＳＵＰＬ_ＩＮＩＴメッセージを受け入れる
・ ＳＥＴがＳＬＰとのＴＬＳセッションを確立する
・ ＳＥＴが、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを要求するために上記のモードＢプロビジョニング開始手順を実施する
・ ＳＥＴが該状態にあることをＳＬＰが知っている場合は、ＳＬＰは、ＳＥＴがいずれにせよＳＵＰＬ_ＩＮＩＴメッセージを受け入れることを知った状態で、ＮＵＬＬ保護を用いて該メッセージを送信する。
・ ＳＥＴがＳＬＰとのＴＬＳセッションを確立する
・ ＳＥＴが、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを要求するために上記のモードＢプロビジョニング開始手順を実施する
・ ＳＥＴが該状態にあることをＳＬＰが知っている場合は、ＳＬＰは、ＳＥＴがいずれにせよＳＵＰＬ_ＩＮＩＴメッセージを受け入れることを知った状態で、ＮＵＬＬ保護を用いて該メッセージを送信する。
・ 引き続くＵＬＰセッションでは、ＳＥＴ又はＳＬＰは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのプロビジョニングを開始するために上記のモードＢプロビジョニング開始手順を使用することができる。
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するモードＢ使用法
・ ＳＥＴがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するとＳＬＰが確信する場合は、ＳＬＰは、各ＳＵＰＬ ＩＮＩＴメッセージにＳＵＰＬ ＩＮＩＴプロテクタを加える−これは、ＳＥＴが受信されたＳＵＰＬ ＩＮＩＴメッセージの真正性を検査するのを可能にする。
・ モードＢ保護を使用する場合は、ＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｏｒパラメータは下記の項目から成る。
・ ＳＵＰＬ_ＩＮＩＴ_ＴＩＭＥ（長さ＝４オクテット）。メッセージ送信時間。リプレイを停止させる。
・ ＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣ（長さ＝４オクテット）。メッセージを認証する。
・ ＳＥＴがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、ＳＥＴは、ＳＵＰＬ_ＩＮＩＴ_ＴＩＭＥが有効であり及びＳＵＰＬ_ＩＮＩＴ内で提供されたＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣがＳＥＴによって計算された値と一致する場合のみにメッセージを受け入れる。
ＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣ計算
＞ ＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣパラメータは以下のように生成される：
・ ＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，ＳＵＰＬ_ＩＮＩＴ_Ｚ）
・ ＳＵＰＬ_ＩＮＩＴ_Ｚは、ＳＵＰＬ_ＩＮＩＴ_ＭＯＤＥ_Ｂ_ＭＡＣフィールドがすべてゼロに設定されたＳＵＰＬ ＩＮＩＴメッセージである。
モードＢ例外−ハードリセット
・ オペレータがＳＵＰＬ ＩＮＩＴ保護を使用する例外的なケース（例えば、ＳＥＴ及びＳＬＰが同期外れ）では、サービス拒否攻撃が保護されていないＳＵＰＬ ＩＮＩＴを多数のＳＥＴに送信することによってつけ込むことができないように、（例えば、リセットコマンドを介して）ＳＥＴに明示されている限りにおいて、ＳＥＴを再プロビジョニングするためにヌルＳＵＰＬ ＩＮＩＴ保護を一時的に使用することができる
・ このリセットコマンドは、新たな脅威の導入を防止するために直接ＳＥＴに入力される。
概要
・ ＳＵＰＬ３．０のための新しいセキュリティモデル：デバイス証明書を用いたクライアント認証。
・ デバイス証明書は製造時にプロビジョニングされる
・ デバイス証明書を用いたクライアント認証でもＳＵＰＬ ＩＮＩＴ保護がサポートされる。
・ デバイス証明書を用いたクライアント認証でもＳＵＰＬ ＩＮＩＴ保護がサポートされる。
・ デバイス証明書に基づくクライアント認証は、全ベアラをサポートする（ｂｅａｒｅｒ ａｇｎｏｓｔｉｃ）セキュリティモデルであり、このため、ＳＵＰＬ３．０に適する。
・ ＳＵＰＬオペレータの選択に依存してレガシーセキュリティモデル（ＡＣＡ及びＧＢＡ）を依然として使用することができる。
推奨
・ ＳＵＰＬ３．０のためのセキュリティモデルとしてデバイス証明書を用いるクライアント認証。
・ レガシーのＡＣＡセキュリティモデル及びＧＢＡセキュリティモデルのためのサポートを維持する。
追加の実施形態７
ＳＵＰＬ２．０のためのセキュリティ上の解決方法は、３ＧＰＰ、３ＧＰＰ２及びＷＩＭａｘアクセスネットワーク以外では利用できないことがあり（例えば、ＷｉＦｉアクセスをサポートしないことがあり）、強力なセキュリティをサポートするためにＧＢＡの実装を含む。さらに、セキュリティ上の解決方法は、ホームオペレータＳＬＰ（Ｈ−ＳＬＰ）の代わりに又はホームオペレータＳＬＰ（Ｈ−ＳＬＰ）に加えてアクセス関連ＳＬＰ（Ａ−ＳＬＰ）をサポートするのを可能にできないことがある。
本実施形態は、ＴＬＳ−ＳＲＰを用いたクライアント（ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ））の認証をサポートするためにＳＬＰプロバイダによってユーザ又はユーザのＳＥＴに割り当てられたユーザ名及びパスワードを利用する。ＳＵＰＬ ＳＥＴ及びＳＬＰは、ＳＥＴがＳＬＰを認証することを可能にするために公開鍵ＴＬＳを使用することができる。これは、ＴＬＳ−ＳＲＰ（及び予め取り決められたユーザ名及びパスワード）を用いたＳＬＰによるＳＥＴの２回目の認証が生じるセキュアなＴＬＳ／ＩＰコネクションを生成することができる。これは、最初のセキュアなＴＬＳ／ＩＰコネクションを変更することができ、セキュアなＳＵＰＬセッションをサポートするために使用される。ＳＬＰは、このＳＵＰＬセッションを用いて、最初に割り当てられたユーザ名及びパスワードと取り替えるための新しいユーザ名及びパスワードをＳＥＴに提供することができる。新しいユーザ名及びパスワードは、ユーザには見えず、これは、ユーザが２つ以上のデバイスでユーザ名及びパスワードを使用するのを防止することができ及びユーザが最初のユーザ名パスワードをその他のユーザに誤って転送しないように保護することができる。この解決方法は、Ｈ−ＳＬＰ及びＡ−ＳＬＰの両方に関して使用することができ、必ずしも３ＧＰＰ、３ＧＰＰ２又はＷｉＭａｘアクセスネットワークのみの使用を要求しない。
従って、説明される実施形態は、ＳＵＰＬセキュリティサポートを全ＩＰアクセスネットワークに拡大し、ＧＢＡをサポートする必要なしに現在配備される解決方法よりも強力なセキュリティを提供することができ、及び、Ｈ−ＳＬＰ及びＡ−ＳＬＰをサポートすることができる（節の番号は、ＳＵＰＬ３．０の節番を指すことができる）。
６．セキュリティ上の考慮事項
本節では、ＳＵＰＬネットワークがＳＥＴを認証して権限を付与するのを可能にし及びＳＥＴがＳＵＰＬネットワークを認証して権限を付与するのを可能にするＳＵＰＬセキュリティ機能について説明する。
注：別記がないかぎり、頭字語ＴＬＳの使用は、ＴＬＳハンドシェイクを用いて交渉することができるあらゆるセッションを指す。すなわち、これは、ＴＬＳ１．１暗号スイート及びＴＬＳ−ＰＳＫ暗号スイートの両方を含む。
注：本節では、次の定義が適用される。３ＧＰＰベアラネットワークは、そのための規格が３ＧＰＰによって維持されるそれであり、これらは、ＧＳＭベアラネットワークと、ＧＰＲＳベアラネットワークと、ＥＤＧＥベアラネットワークと、ＷＣＤＭＡ（登録商標）／ＴＤ−ＳＣＤＭＡベアラネットワークと、ＬＴＥベアラネットワークと、ＬＴＥ−Ａベアラネットワークとを含む。３ＧＰＰ２ベアラネットワークは、そのための規格が３ＧＰＰ２によって維持されるそれであり、これらは、ｃｄｍａＯｎｅベアラネットワークと、ｃｄｍａ２０００ １ｘベアラネットワークと、ｃｄｍａ２００ ＥＶ−ＤＯベアラネットワークとを含む。３ＧＰＰ ＳＥＴ（それぞれ３ＧＰＰ２ ＳＥＴ）は、それのホームネットワークオペレータが主に３ＧＰＰベアラネットワーク（それぞれ３ＧＰＰ２ネットワーク）を介してデータアクセスをサポートするＳＥＴである。ＷｉＭＡＸ ＳＥＴは、それのホームネットワークオペレータが主にＷｉＭＡＸベアラネットワークを介してデータアクセスをサポートするＳＥＴである。曖昧な場合は（例えば、複数のアクセスタイプをサポートするオペレータ）、オペレータは、ＳＥＴのタイプを決定することができる。
注：Ｈ−ＳＬＰオペレータは、ここにおいて説明される認証方法は同じオペレータに属するアクセスネットワーク間でのＳＥＴハンドオーバーに関して及びＳＥＴ ＩＰアドレスが変更されない場合に引き続き有効であることに注目べきである。手順は、ＳＥＴが１つのアクセスネットワークから異なるオペレータに属する他に移動するシナリオ又はＩＰアドレスが変更されるシナリオは考慮していない。これらのシナリオでは、他のアクセスシステムへのハンドオーバー後に、端末及びネットワークにおいてセキュリティコンテキストを利用できないことがあり及びネットワークと端末との間の信用度が変化することがあると推定される。
パワーアップ及びシャットダウン、新しいＵＩＣＣの検出又はＵＩＣＣの取り外し次第、ＳＥＴハンドセットは、ＳＵＰＬ３．０と関連付けられたＳＥＴハンドセット上の（長期鍵は別にして）あらゆる鍵を削除しなければならず、下記のキーを含む。
◆ ＧＢＡ鍵：例えば、Ｋｓ、Ｋｓ_ＮＡＦ、Ｋｓ_ｅｘｔ_ＮＡＦ
◆ ＷＩＭＡＸ鍵：例えば、ＳＥＫ
◆ ＴＬＳ鍵：例えば、ｐｒｅ_ｍａｓｔｅｒ_ｓｅｃｒｅｔ、ｍａｓｔｅｒ_ｓｅｃｒｅｔ、及びＰＳＫ値（長期鍵は別とする）。
◆ ＷＩＭＡＸ鍵：例えば、ＳＥＫ
◆ ＴＬＳ鍵：例えば、ｐｒｅ_ｍａｓｔｅｒ_ｓｅｃｒｅｔ、ｍａｓｔｅｒ_ｓｅｃｒｅｔ、及びＰＳＫ値（長期鍵は別とする）。
◆ ＳＵＰＬ専用鍵：例えば、ＳＵＰＬ ＩＮＩＴメッセージの保護と関連付けられた鍵。
６．１ ＳＵＰＬ認証方法
ＳＵＰＬ３．０に関する認証サポート要件は次の通りである。
・ＳＥＴとＨ−ＳＬＰとの間で相互認証をサポートすることができる。
・ＳＥＴとＤ−ＳＬＰとの間で相互認証をサポートすることができる。
・ＳＥＴとＥ−ＳＬＰとの間でサーバ認証をサポートすることができ、及び、ＳＥＴとＥ−ＳＬＰとの間で相互認証をサポートすることができる。
ＳＵＰＬ３．０は、２つのクラスのＳＥＴ認証方法をサポートする
・ ＡＮに依存する方法であり、クレデンシャルがＳＥＴユーザのアクセスネットワーク加入にバインドされる。
・ ＡＮから独立した方法であり、クレデンシャルがＳＥＴにバインドされるが、ＳＥＴユーザのアクセスネットワーク加入に直接はバインドされない。該クレデンシャルをＳＥＴユーザのアクセスネットワーク加入にバインドすることは、範囲外（ｏｕｔ−ｏｆ−ｓｃｏｐｅ）手順を用いて達成させることができる。範囲外手順に関する詳細な説明については第６．６節を参照すること。
相互認証が実施されるときには、ＳＥＴは、ＳＥＴ内に含まれているＳＵＰＬエージェントを介してＳＥＴユーザの代わりに行動することができる。
・ ＡＮに依存する方法に関しては、ＳＥＴは、ＳＥＴユーザと関連付けられたセキュリティクレデンシャルを使用する。
・ ＡＮから独立した方法に関しては、ＳＥＴは、ＳＥＴと関連付けられたセキュリティクレデンシャルを使用する。
ＳＥＴユーザの認証が成功した場合は、その結果として、ＳＥＴユーザのＩＤ（例えば、ＭＳＩＳＤＮ、ＷＩＭＡＸユーザＩＤ又はＡＮから独立したユーザアイデンティティ）が成功裏に識別されなければならないことに注目すること。
ＭＳＩＳＤＮが認証のために使用されるときには、ＳＬＰは、認証されたＳＥＴのＭＳＩＳＤＮがセキュアな形で識別される前にＩＭＳＩとＭＳＩＳＤＮのバインディングを行わなければならないことに注目すること。
鍵管理詳細は第６．１．２節において見ることができる。
６．１．１ 認証方法
第６．１．１．１．節は、この明細書でサポートされる認証方法について説明する。第６．１．１．２節では、これらの方法に関する情報を提供するための概要を示してある。第６．１．１．３節は、様々なＳＵＰＬ３．０のエンティティにおいていずれの方法が強制的又は任意選択であるかを説明し、所定の相互認証方法をサポートする場合に各エンティティにおいて要求されるプロトコルを記載した。
６．１．１．１ サポートされる相互認証方法の一覧
ＳＵＰＬ認証モデルは、取り除くことが可能なトークン、例えばＲ−ＵＩＭ／ＵＩＣＣ／ＳＩＭ／ＵＳＩＭ又はＳＥＴハンドセットのいずれかにバインドされた、ＳＬＰとＳＥＴとの間での共有秘密鍵を確立することを要求する。
本書では次の２つのクラスの認証方法が規定される：
・ＰＳＫに基づく方法、次の方法から成る：
○ ＡＮに依存する汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく方法であり、相互認証を提供する；
○ ＡＮに依存するＳＥＫに基づく方法であり（ＷＩＭＡＸ ＳＬＰのみに適用可能）、相互認証を提供する；
・ 証明書に基づく方法であり、次の方法から成る：
○ ＡＮから独立したデバイス証明書に基づく（ＤＣｅｒｔ）方法であり、相互認証を提供する；
○ ＡＮに依存する代替クライアント認証（ＡＣＡ）に基づく方法であり、相互認証を提供する；
○ ＡＮから独立したＳＬＰ専用の方法であり（緊急時のみに適用可能）、ＳＬＰの認証のみを提供する。
・ＰＳＫに基づく方法、次の方法から成る：
○ ＡＮに依存する汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく方法であり、相互認証を提供する；
○ ＡＮに依存するＳＥＫに基づく方法であり（ＷＩＭＡＸ ＳＬＰのみに適用可能）、相互認証を提供する；
・ 証明書に基づく方法であり、次の方法から成る：
○ ＡＮから独立したデバイス証明書に基づく（ＤＣｅｒｔ）方法であり、相互認証を提供する；
○ ＡＮに依存する代替クライアント認証（ＡＣＡ）に基づく方法であり、相互認証を提供する；
○ ＡＮから独立したＳＬＰ専用の方法であり（緊急時のみに適用可能）、ＳＬＰの認証のみを提供する。
６．１．１．２ サポートされる認証方法の概要（情報用）
１．汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく。汎用ブートストラッピングアーキテクチャ（ＧＢＡ）ＧＢＡを有するＴＬＳ−ＰＳＫは、既存の３ＧＰＰ／３ＧＰＰ２認証メカニズムを用いて導き出される共有の秘密に基づく相互認証能力を提供する。
・ ＳＥＴ及びＳＬＰは、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）を有するＴＬＳ−ＰＳＫを用いて相互に認証される。
２．ＳＥＫに基づく（ＷＩＭＡＸ ＳＬＰのみに適用可能）
・ ＳＥＴ及びＳＬＰは、ＳＥＫを有するＴＬＳ−ＰＳＫを用いて相互に認証される。ＳＥＫ方法の詳細は、第６．１．２．１．２節において見つけることができる。
３．デバイス証明書（ＤＣｅｒｔ）に基づく。このＡＮから独立した方法は、以下を用いるＴＬＳを使用する
・ ＳＥＴに対してＳＬＰを認証するためのＲＳＡサーバ証明書、
・ ＳＬＰに対してＳＥＴを認証するためのＲＳＡクライアント証明書
４．代替クライアント認証（ＡＣＡ）に基づく。これは、以下によるＴＬＳを使用する
・ ＳＥＴに対してＳＬＰを認証するためのＲＳＡ証明書、
・ ＳＬＰに対するＳＥＴの代替クライアント認証（第６．１．４参照）。この場合は、ＳＬＰは、ＳＥＴ識別子（ＭＳＩＳＤＮ、等）と関連付けられたＩＰアドレスをベアラネットワークに確認させることによってＳＥＴを認証する。
５．ＳＬＰ専用。これは、ＳＬＰがＳＥＴを認証できないシナリオにおいて使用される。この方法は、非緊急時のためには使用できない。ＳＥＴは、この方法とＡＣＡ基づく場合を区別することができない。これは、以下によるＴＬＳを使用する
・ ＳＥＴに対してＳＬＰを認証するためのＲＳＡ証明書
・ ＳＥＴは認証されない。
６．１．１．３ エンティティ別の相互認証方法及びプロトコルのサポート
以下の４つの表は、様々なクラスのＳＥＴ及びそれらのＳＥＴをサポートするＳＬＰにおけるＳＵＰＬ３．０のサポートにとって何が任意選択的であり、何が強制的であるかを示す。
・ 第１の表は、以下においてＳＵＰＬ３．０のために実装する上で強制的である方法及び任意選択的である方法を示す。
○ ３ＧＰＰ／３ＧＰＰ２ ＳＥＴ、
○ ＳＥＴ（Ｒ−）ＵＩＭ／ＳＩＭ／ＵＳＩＭ及び
○ ３ＧＰＰ／３ＧＰＰ２ ＳＥＴをサポートするＳＬＰ
・ 第２の表は、以下においてＳＵＰＬ３．０のために実装する上で強制的である方法及び任意選択的である方法を示す。
○ ＳＥＴ（Ｒ−）ＵＩＭ／ＳＩＭ／ＵＳＩＭ及び
○ ３ＧＰＰ／３ＧＰＰ２ ＳＥＴをサポートするＳＬＰ
・ 第２の表は、以下においてＳＵＰＬ３．０のために実装する上で強制的である方法及び任意選択的である方法を示す。
○ ＷｉＭＡＸ ＳＥＴ
○ それらのＷｉＭＡＸ ＳＥＴをサポートするＳＬＰ；
・ 第３の表は、以下においてＳＵＰＬ３．０のために実装する上で強制的である方法及び任意選択的である方法を示す。
○ それらのＷｉＭＡＸ ＳＥＴをサポートするＳＬＰ；
・ 第３の表は、以下においてＳＵＰＬ３．０のために実装する上で強制的である方法及び任意選択的である方法を示す。
○ ３ＧＰＰ／３ＧＰＰ２もＷｉＭＡＸもサポートしないＳＥＴ、及び
○ それらのＳＥＴをサポートするＳＬＰ。
○ それらのＳＥＴをサポートするＳＬＰ。
・ 第４の表は、様々な認証方法の各々をサポートするためのＳＬＰ、ＳＥＴハンドセット及び（該当する場合）ＳＥＴ（Ｒ−）ＵＩＭ／ＳＩＭ／ＵＳＩＭのための要求されるプロトコルを示す。
３ＧＰＰ／３ＧＰＰ２ ＳＥＴ及びこれらのＳＥＴをサポートするＳＬＰのための様々な認証方法に関する要件状況（強制的又は任意選択的）
注１：ＳＬＰ専用方法のためのＳＥＴハンドセットサポートは、緊急時のために要求されることがある。
注１：ＳＬＰ専用方法のためのＳＥＴハンドセットサポートは、緊急時のために要求されることがある。
注２：（３ＧＰＰ及び３ＧＰＰ２専用の）ＡＣＡに基づく方法に関するＳＥＴ手順は、ＳＬＰ専用方法に関するＳＥＴ手順と同一である。従って、３ＧＰＰ／３ＧＰＰ２ ＳＥＴハンドセットは、ＳＬＰ専用方法が緊急時のために要求される結果としてＡＣＡに基づく方法をサポートする。
ＷｉＭＡＸ ＳＥＴ、及びこれらのＷｉＭＡＸ ＳＥＴをサポートするＳＬＰのための様々な認証方法に関する要件状況（強制的又は任意選択的）
３ＧＰＰ、３ＧＰＰ２及びＷｉＭＡＸをサポートしないＳＥＴ、及びこれらのＳＥＴをサポートするＳＬＰのための様々な認証方法に関する要件状況（強制的又は任意
様々な相互認証方法をサポートするためのＳＬＰ、ＳＥＴハンドセット及びＳＥＴ Ｒ−ＵＩＭ／ＵＩＣＣ／ＳＩＭ／ＵＳＩＭのための要求されるプロトコル
ＧＢＡに基づく方法がサポートされる場合は、ＢＳＦは、Ｈ−ＳＬＰアプリケーションと関連付けられたユーザセキュリティ設定（ＵＳＳ）を格納する。Ｈ−ＳＬＰがＵＳＳを要求するときには、ＢＳＦは、ＵＳＳにＳＥＴユーザアイデンティティ（例えば、ＩＭＰＩ、ＩＭＳＩ又はＭＳＩＳＤＮ）を含めなければならない。
ＧＢＡに基づく方法がサポートされる場合は、ＢＳＦは、Ｈ−ＳＬＰアプリケーションと関連付けられたユーザセキュリティ設定（ＵＳＳ）を格納する。Ｈ−ＳＬＰがＵＳＳを要求するときには、ＢＳＦは、ＵＳＳにＳＥＴユーザアイデンティティ（例えば、ＩＭＰＩ、ＩＭＳＩ又はＭＳＩＳＤＮ）を含めなければならない。
注：ＧＢＡに基づく方法は、ＳＵＰＬセッションを転送するために３ＧＰＰ又は３ＧＰＰ２ベアラネットワークを使用することには依存していない。しかしながら、ＳＥＴは、ＧＢＡを実施するための必要なクレデンシャルを有するために３ＧＰＰ又は３ＧＰＰホームネットワークオペレータを有さなければならない。
６．１．１．４ ＴＬＳハンドシェイク仕事量を最小にするための技法
本節の手順は、ＳＬＰとＳＥＴとの間でＴＬＳセッションを確立することに関連する作業量を最小にするものである。ＴＬＳとの矛盾が生じる場合は、ＴＬＳが優先する。
ＳＥＴ及びＳＬＰが２つ以上のＳＵＰＬセッションと関連付けられたＳＵＰＬメッセージを同時に通信中である場合は、ＳＥＴ及びＳＬＰは、これらのメッセージのセキュリティを確保するために単一のＴＬＳセッションを使用すべきである。すなわち、ＳＥＴ及びＳＬＰは、ＳＵＰＬセッションが同時である場合は別個のＴＬＳセッションを確立すべきではない。
ＳＥＴ及びＳＬＰがＴＬＳセッションを確立する場合は、ＳＬＰは、短縮されたハンドシェイクを用いてそのセッションを再開するのを可能にすることができる。ＴＬＳセッションを再開することの利点は、サーバ証明書に基づいてＴＬＳを再開することは、公開鍵に関する動作を要求しない、すなわち、（有意なレベルでより少ない処理を要求する）対称的暗号アルゴリズムのみが要求されることである。
注：緊急ＳＵＰＬセッションは非常に偶発的に発生するので必要なデータを確実には格納できないため、このアプローチ法はＥ−ＳＬＰに関しては推奨されない。
注：ＳＬＰは、ＴＬＳ ＳｅｓｓｉｏｎＩＤを割り当てることによってセッションを再開させるのを可能にする。
注：（ＧＢＡ及びＳＥＫに基づく認証のために使用される）ＴＬＳ−ＰＳＫセッションを再開させても同じ計算が行われるため利点はない。しかしながら、ＳＬＰはそれでもＴＬＳ−ＰＳＫセッションを再開させるのを可能にすることができる。
注：ＳＥＴは、ＴＬＳハンドシェイクのＣｌｉｅｎｔＨｅｌｌｏメッセージ内のＴＬＳ ＳｅｓｓｉｏｎＩＤパラメータに（再開すべきＴＬＳセッションの）ＴＬＳ ＳｅｓｓｉｏｎＩＤを含めることによってＴＬＳセッションを再開させるのを選択したことを示す。ＳＥＴがＴＬＳセッションを再開させることを希望しない場合は、ＳＥＴは、ＴＬＳ ＳｅｓｓｉｏｎＩＤを含めずにＴＬＳ ＣｌｉｅｎｔＨｅｌｌｏメッセージを送信し、その場合は、フルハンドシェイクが行われる。ＴＬＳ ＳｅｓｓｉｏｎＩＤパラメータがＴＬＳ ＣｌｉｅｎｔＨｅｌｌｏメッセージ内に存在する場合は、ＳＬＰは、ＴＬＳセッションを再開させるかどうかを選択する。ＳｅｓｓｉｏｎＩＤパラメータがＴＬＳ ＣｌｉｅｎｔＨｅｌｌｏメッセージ内に存在しない場合は、ＳＬＰは、ＴＬＳハンドシェイクを前回のＴＬＳセッションと関連付けることができず、このため、ＴＬＳハンドシェイクは、フルハンドシェイクを用いて完全に新しいＴＬＳセッションを確立する。
ＳＥＴは、次の指針に従ってＴＬＳセッションを再開させるかどうかを選択する。
◆ ＳＥＴは、根本になるクレデンシャル（Ｋｓ（_ｅｘｔ）_ＮＡＦ又はＳＬＰ証明書又はＳＥＫ又はデバイス証明書）が期限切れの場合はＴＬＳセッションを再開させてはならない。
◆ ＳＥＴは、希望される場合は、根本になるクレデンシャルの期限切れよりも早期にＴＬＳセッションを再開させないことを選択することができる。
◆ ＳＥＴは、パワーアップ前又は新しいＲ−ＵＩＭ／ＵＩＣＣ／ＳＩＭ／ＵＳＩＭの検出前に確立されたセッションを再開させてはならない。
ＳＬＰは、次の指針を用いてＴＬＳセッションを再開させるかどうかを選択する。
◆ ＳＥＴは、根本になるクレデンシャル（Ｋｓ（_ｅｘｔ）_ＮＡＦ又はＳＬＰ証明書又はＳＥＫ又はデバイス証明書）が期限切れの場合はＴＬＳセッションを再開させてはならない。
◆ ＳＥＴは、希望される場合は、根本になるクレデンシャルの期限切れよりも早期にＴＬＳセッションを再開させないことを選択することができる。
注：各ＳＬＰは、短縮されたハンドシェイクを可能にするかどうかをそれ自体で判断しなければならず、この判断は、各々のＳＥＴごとに行うことさえも可能である。ＳＬＰは、既存のセッションを再開させることを受け入れたときには小さいリスクを冒していることになる。このリスクは、“いたずらな”ＳＥＴが（フルＴＬＳハンドシェイク中に確立された）ｍａｓｔｅｒ_ｓｅｃｒｅｔを配布し、このため、その他の者がそのＴＬＳセッションを再開させることができ、それによって複数のＳＥＴが単一のＳＥＴに対して課金されるサービスを入手するのを可能にする可能性があることである。“いたずらな”ＳＥＴは、ＳＥＴ所有者が知らない状態でこれを行っていることが可能である（例えば、悪意のあるコードに責任がある可能性がある）。紛失は簡単に制限できることに注目すること。すなわち、該悪用が発生していることをＳＬＰが検出するか（又は疑う）場合は、ＳＬＰは、簡単に（ａ）そのｍａｓｔｅｒ_ｓｅｃｒｅｔを使用しているＴＬＳセッションを終了させ、（ｂ）“いたずらな”ＳＥＴを特定し及び（ｃ）必要な場合はユーザが引き続きサービスを有するのを可能にするためにフルハンドシェイクを用いて“いたずらな”ＳＥＴを再認証することができる。要約すると、ＤＣｅｒｔ方法、ＡＣＡに基づく方法及びＳＬＰ専用方法に関して（計算を低減させることについての）セッションを再開させることの利益は、攻撃というリスクを上回ると考えられる。
６．１．２ ＳＵＰＬ認証のための鍵管理
ＳＵＰＬ認証モデルは、取り除くことが可能なトークン、例えばＲ−ＵＩＭ／ＵＩＣＣ／ＳＩＭ／ＵＳＩＭ又はＳＥＴハンドセットのいずれかにバインドされた、ＳＬＰとＳＥＴとの間での共有秘密鍵を確立することを要求する。
６．１．２．１ ＰＳＫに基づく方法
６．１．２．１．１ ＧＢＡ方法をサポートする配備
ＧＢＡをサポートする配備の場合は、共有鍵は次のように確立される：
・ ＳＬＰが（ＩＰ通信のセキュリティを確保するために及びＳＵＰＬ ＩＮＩＴを保護するために）鍵素材をＢＳＦに要求するときには、ＳＬＰは、ＵＳＳ（ユーザセキュリティ設定）も要求しなければならない。ＵＳＳは、永久的なユーザアイデンティティ（例えば、ＩＭＰＩ、ＩＭＳＩ又はＭＳＩＳＤＮ）を含まなければならない。
・ ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するためには、ＳＥＴ及びＳＬＰは、ＧＢＡを用いてＴＬＳ−ＰＳＫに従って共有秘密鍵を導き出し及び動作しなければならない。ＳＬＰは、ＳＬＰを指定する適切に定義されたドメイン名ＳＬＰ_Ａｄｄｒｅｓｓ_ＦＱＤＮ、例えば、ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ、を有さなければならない。ＴＬＳ−ＰＳＫのために使用することができるＧＢＡ Ｕａセキュリティプロトコル識別子がＯＭＮＡレジストリ内で定義されている。ＳＬＰは、ＢＳＦによって提供された永久的なユーザアイデンティティが対応するセキュリティが確保されたコネクションを通じてＳＬＰによって受信されたＳＵＰＬメッセージ内のＳＥＴアイデンティティに対応することを確認しなければならない。
・ ＳＵＰＬ ＩＮＩＴのＭＡＣ保護に関して、ＧＢＡにより鍵が導き出される。ＳＵＰＬ ＩＮＩＴ保護のために使用することができるＧＢＡ Ｕａセキュリティプロトコル識別子がＯＭＮＡレジストリ内で定義されている。ＳＵＰＬ ＩＮＩＴメッセージに含まれるｂａｓｉｃＭＡＣのｋｅｙＩｄｅｎｔｉｆｉｅｒは、Ｋｓ_ＮＡＦが生成されるＫｓのＢ−ＴＩＤでなければならない。注：Ｈ／Ｄ−ＳＬＰによるＢＳＦへのＳＵＰＬ ＩＮＩＴ保護鍵の要求は、典型的には、Ｈ／Ｄ−ＳＬＰによるＩＰ通信のセキュリティを確保する鍵の要求と同時に発生することになる。
・ ＳＥＴは、有効なＫｓが常にプロビジョニングされていることを確認しなければならない。有効なＫｓが存在しない場合は、ＳＥＴは、ＫｓをプロビジョニングするためのＧＢＡブートストラッピング手順を開始しなければならない。新しいＵＩＣＣ（ＵＳＩＭ／ＳＩＭ／Ｒ−ＵＩＭ）がＳＥＴによって検出されるごとに新しいＫｓが確立されなければならない。さらに、ＳＥＴは、（ホームネットワークオペレータによって設定された）Ｋｓ_ＮＡＦの寿命が過ぎているときには新しい共有鍵を確立しなけければならない。
６．１．２．１．２ ＳＥＫ方法をサポートする配備
ＳＥＫをサポートする配備の場合は、共有鍵は次のように確立される：
・ ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するために、ＳＥＴ及びＳＬＰは、共有される秘密鍵を導き出さなければならず及びＷｉＭＡＸ ＡＡＡサーバによって提供された永久的なユーザアイデンティティが対応するセキュリティが確保されたコネクションを通じてＳＬＰによって受信されたＳＵＰＬメッセージ内のＳＥＴアイデンティティに対応することを確認しなければならない。共有される鍵は、次の方法で導き出される：
○ ＳＥＫ＝ＨＭＡＣ−ＳＨＡ２５６（ＬＳＫ，“ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ”）の１６の最上位（左端）オクテット。ここで、'ｏｐｅｒａｔｏｒ．ｃｏｍ'は、ＷＩＭＡＸオペレータのＦＱＤＮであり、ＬＳＫは、位置に基づくサービスに関するＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおける規定に従って導き出される。
○ ＳＥＫは、ＬＳＫと関連付けられた（位置に基づくサービスに関するＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおいて定義される）位置鍵識別子（ＬＳＫ−ＩＤ）を引き継ぎ、鍵アイデンティティがＷｉＭＡＸ配備のためのＢ−ＴＩＤとして使用される。
・ ＳＵＰＬ ＩＮＩＴのＭＡＣ完全性保護のために、鍵は次の方法で導き出される：
○ ＳＥＫ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６（ＬＳＫ，“ｍａｃ．ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ”）の１６の最上位（左端）オクテット。ここで、'ｏｐｅｒａｔｏｒ．ｃｏｍ'は、ＳＬＰオペレータのＦＱＤＮであり、ＬＳＫは、位置に基づくサービスに関するＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおける規定に従って導き出される。
○ ＳＥＫ_ＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６（ＬＳＫ，“ｍａｃ．ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ”）の１６の最上位（左端）オクテット。ここで、'ｏｐｅｒａｔｏｒ．ｃｏｍ'は、ＳＬＰオペレータのＦＱＤＮであり、ＬＳＫは、位置に基づくサービスに関するＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおける規定に従って導き出される。
○ ＳＵＰＬ ＩＮＩＴメッセージに含まれているモードＡ ＭＡＣのｋｅｙＩｄｅｎｔｉｆｉｅｒは、ＳＥＫ_ＭＡＣが生成されるＬＳＫのＢ−ＴＩＤでなければならない。注：ＳＬＰによるＷｉＭＡＸ ＡＡＡへのＳＵＰＬ ＩＮＩＴ保護鍵の要求は、典型的には、ＳＬＰによるＩＰ通信のセキュリティを確保する鍵の要求と同時に発生することになる。
ＳＥＴは、有効なＳＥＫが常に提供されていることを確認しなければならない。有効なＳＥＫが存在しない場合は、ＳＥＴは、上記に従ってＳＥＫを導き出さなければならない。さらに、ＳＥＴは、ＬＳＫの寿命が経過しているときには新しい共有鍵を確立しなければならない。ＳＬＰとＷｉＭＡＸ ＡＡＡサーバとの間のインタフェースは、ＳＵＰＬ３．０の範囲外である。
６．１．２．２ サーバ証明書に基づく方法
６．１．２．２．１ ＤＣｅｒｔ方法をサポートする配備
ＤＣｅｒｔ方法をサポートする配備の場合は、共有鍵は次のように確立される：
・ ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するために、ＳＥＴ及びＳＬＰは、ＳＬＰを認証するサーバ証明書及びＳＥＴを認証するクライアント証明書を用いてＴＬＳ−ＲＳＡを使用しなければならない。クライアント証明書は、グローバルで一意のＳＥＴデバイスアイデンティティを提供することができる：
○ ３ＧＰＰ ＳＥＴは、ＩＭＥＩをグローバルで一意のＳＥＴデバイスアイデンティティとして使用することができる。
○ ３ＧＰＰ２ ＳＥＴは、ＭＳＩＤをグローバルで一意のＳＥＴデバイスアイデンティティとして使用することができる。
○ ＷｉＭＡＸ ＳＥＴは、ＳＥＴ一連番号をグローバルで一意のＳＥＴデバイスアイデンティティとして使用することができる。
○ すべてのその他のＳＥＴは、適切なグローバル識別子（例えば、売り主の身元を含む一連番号）をグローバルで一意のＳＥＴデバイスアイデンティティとして使用することができる。
・ ＳＵＰＬユーザは、このデバイスがそれらの加入と関連付けられるべきであることをセキュリティが確保された形でＳＬＰに検証しなければならない。このセキュアな検証は、本明細書の範囲外である。この話題に関するさらなる説明については第６．５節を参照すること。
・ ＳＵＰＬ ＩＮＩＴのＭＡＣ完全性保護のために、鍵は、ＵＬＰメッセージに入れてＳＬＰによってＳＥＴに提供される。これは、第６．３．５節で説明される。
６．１．２．２．２ ＡＣＡ方法をサポートする配備
ＡＣＡ方法をサポートする配備の場合は、共有鍵は次のように確立される：
・ ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するために、ＳＥＴ及びＳＬＰは、ＳＬＰを認証するサーバ証明書を用いてＴＬＳ−ＲＳＡを使用しなければならない。ＳＥＴ認証（結果的に得られた共有秘密鍵を、上記の取り外し可能なトークン又は統合されたトークンのいずれかとバインドさせる）は、第６．１．４節では非緊急時に関して及び第６．２．５節では緊急時に関して説明されている。
・ ＳＵＰＬ ＩＮＩＴのＭＡＣ完全性保護に関しては、鍵は、ＵＬＰメッセージでＳＬＰによってＳＥＴに提供される。これは、第６．３．５節で説明される。
６．１．２．２．３ ＳＬＰ専用方法をサポートする配備
ＳＬＰ専用方法をサポートする配備の場合は、共有鍵は次のように確立される：
・ ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するために、ＳＥＴ及びＳＬＰは、ＳＬＰを認証するサーバ証明書を用いてＴＬＳ−ＲＳＡを使用しなければならない。第６．１．４節では非緊急時に関して及び第６．２．５節では緊急時に関して説明されるようなＳＥＴ認証（結果的に得られた共有秘密鍵を、Ｒ−ＵＩＭ／ＵＩＣＣ／ＳＩＭ／ＵＳＩＭ又はＳＥＴハンドセットのいずれかにバインドさせる）は存在しない。
・これらの事例ではＳＵＰＬ ＩＮＩＴのＭＡＣ保護はサポートされていない。
６．１．３ 相互認証方法のＴＬＳハンドシェイク及び交渉
ＳＥＴ及びＳＬＰは、適用されるべき相互にサポートされる認証方法を取り決める必要がある。
６．１．３．１ 相互認証方法の交渉に関して（情報用）
Ｈ−ＳＬＰへのＴＬＳコネクションを確立するときには、ＳＥＴは、最初に、以下の優先順序により、最高の優先度を有する相互にサポートされる認証メカニズムを用いてコネクションを確立することを試みる：
◆ ＰＳＫに基づく方法：ＧＢＡ又はＳＥＫに基づく方法が最も優先される（サポートされる場合）；
◆ ＤＣｅｒｔ方法：２番目に優先される（サポートされる場合）
◆ ＡＣＡ又はＳＬＰ専用方法：３番目に優先される（ＳＥＴの観点からは、ＡＣＡに基づく方法とＳＬＰ専用方法との間に差はない）。
相互にサポートされる認証方法がない場合は、ＳＥＴは、ＳＵＰＬセッションを行うことができないことがある。
ＰＳＫに基づく方法をサポートするＳＥＴは、ＢＳＦ又はＷｉＭＡＸ ＡＡＡが問題に遭遇することに起因して所定の時点にＧＢＡ又はＳＥＫに基づく方法を使用できないことがある。従って、ＳＥＴがＧＢＡ又はＳＫＥを用いて認証を確立することを試みても、ＳＥＴがＧＢＡ又はＳＥＫに基づく鍵を確立することができるかどうかは必ずしも保証されない。
従って、ＳＥＴは、最高の優先度を有する相互にサポートされる認証メカニズムを常に使用できるわけではない。ＳＥＴは、利用可能な場合はそれよりも低い優先度の相互にサポートされる認証メカニズムに戻らなければならないことがある。
（Ｈ−ＳＬＰ証明書で）ＰＳＫに基づく方法のみがＨ−ＳＬＰによってサポートされることが示され、ブートストラッピングが失敗した場合は、ＳＥＴは、該当するエンティティがオンラインに戻るための機会を与えるために、ＴＬＳハンドシェイクを再試行する前に少しの間待機することができる。
ＳＬＰがＧＢＡ又はＳＥＫのみをサポートする場合は、ＳＬＰは、ＧＢＡ又はＳＥＫを配備しているキャリアの加入者に対してＳＵＰＬ３．０サービスを提供することに限定される。ＳＬＰがＡＣＡのみをサポートする場合は、ＳＵＰＬ３．０は、第６．１．４節において詳細に説明される状況でしか使用することができない。該場合に、ＳＥＴが、ＳＬＰがＩＰバインディングを入手することができない代替ベアラ（例えば、無線ＬＡＮ）を介して通信する場合は、ＳＬＰは、ＳＥＴを認証することができない。
Ｅ−ＳＬＰがＡＣＡのみをサポートする場合は、第６．２．５．節において詳細に説明されるように、ＳＥＴ認証に関する停止警告が存在する。
６．１．３．２ 非ＷｉＭＡＸ ＳＥＴのための相互認証方法の交渉
非ＷｉＭＡＸ ＳＥＴの場合は、ＳＵＰＬセッションのための相互認証方法の交渉は次のように進行する：
１．ＳＥＴが交渉を開始する
ａ．ＳＥＴがＧＢＡをサポートする場合は、ＳＥＴは、該当するＧＢＡ仕様に準拠した交渉を開始する。
ｂ．そうでない場合（すなわち、ＳＥＴがＧＢＡをサポートしない場合）は、ＳＥＴは、ＣｌｉｅｎｔＨｅｌｌｏメッセージによるＴＬＳハンドシェイクを開始し、ＣｌｉｅｎｔＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅｓフィールドは、ＴＬＳ鍵やり取りアルゴリズムのためのＲＳＡ暗号化を用いるサポートされるＴＬＳ暗号スイートを示す。
２．ＳＬＰが、受信されたＣｌｉｅｎｔＨｅｌｌｏメッセージを処理する。ＳＬＰがＣｌｉｅｎｔＨｅｌｌｏ．ｃｉｐｈｅｒｓｕｉｔｅｓリストを検討し、相互に参照される暗号スイートを選択する。
ａ．ＳＥＴ及びＳＬＰの両方がＴＬＳ−ＰＳＫ暗号スイートをサポートする場合は、これは、ＧＢＡのためのサポートを示す。ＳＬＰがＳｅｒｖｅｒＨｅｌｌｏ、ＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅ及びＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージで応答し、ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅは、相互にサポートされるＴＬＳ−ＰＳＫ暗号スイートを示す。
ｂ．そうでない場合は、ＳＥＴ及びＳＬＰは、証明書に基づく方法をサポートしなければならない
ｉ．ＳＬＰがＤＣｅｒｔ方法をサポートする場合は、ＳＬＰは以下の項目で応答する
１．ＳｅｒｖｅｒＨｅｌｌｏ、ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅは、ＴＬＳ鍵やり取りアルゴリズムのためのＲＳＡ暗号化を用いる相互にサポートされるＴＬＳ−ＰＳＫ暗号スイートを示す、
２．証明書、
３．ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔ及び
４．ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージ。
ｉ．ＳＬＰがＤＣｅｒｔ方法をサポートする場合は、ＳＬＰは以下の項目で応答する
１．ＳｅｒｖｅｒＨｅｌｌｏ、ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅは、ＴＬＳ鍵やり取りアルゴリズムのためのＲＳＡ暗号化を用いる相互にサポートされるＴＬＳ−ＰＳＫ暗号スイートを示す、
２．証明書、
３．ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔ及び
４．ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージ。
ｉ．そうでない場合は、ＳＥＴが３ＧＰＰ／３ＧＰＰ２ ＳＥＴであり、ＳＬＰがＡＣＡ方法をサポートする場合は、ＳＬＰは次の項目で応答する
１．ＳｅｒｖｅｒＨｅｌｌｏ証明書、ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅは、ＴＬＳ鍵やり取りアルゴリズムのためのＲＳＡ暗号化を用いる相互にサポートされるＴＬＳ暗号スイートを示す、
２．証明書、
３．（ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔメッセージは送信されない）
４．ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージ
３．ＳＥＴが、ＳｅｒｖｅｒＨｅｌｌｏメッセージ及び選択されたものに該当するその他のメッセージを処理し、ＳＥＴに対して暗号スイートを示す
ａ．ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅが、ＧＢＡがＳＬＰによって選択されていることを示す場合は、ＳＥＴ及びＳＬＰは、ＧＢＡプロセスを継続する。詳細は、本書の範囲外である。
１．ＳｅｒｖｅｒＨｅｌｌｏ証明書、ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅは、ＴＬＳ鍵やり取りアルゴリズムのためのＲＳＡ暗号化を用いる相互にサポートされるＴＬＳ暗号スイートを示す、
２．証明書、
３．（ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔメッセージは送信されない）
４．ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージ
３．ＳＥＴが、ＳｅｒｖｅｒＨｅｌｌｏメッセージ及び選択されたものに該当するその他のメッセージを処理し、ＳＥＴに対して暗号スイートを示す
ａ．ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅが、ＧＢＡがＳＬＰによって選択されていることを示す場合は、ＳＥＴ及びＳＬＰは、ＧＢＡプロセスを継続する。詳細は、本書の範囲外である。
ｂ．そうでない場合は、ＳｅｒｖｅｒＨｅｌｌｏ．ｃｉｐｈｅｒ_ｓｕｉｔｅは、ＴＬＳ鍵やり取りアルゴリズムのためのＲＳＡ暗号化を用いる相互にサポートされるＴＬＳ暗号スイートを示す。
ｉ．ＳＥＴがＣｅｒｔｉｆｉｃａｔｅ．Ｒｅｑｕｅｓｔを受信した場合は、
１．ＳＥＴがＤＣｅｒｔ方法をサポートする場合は、ＳＥＴは、デバイス証明書を提供し、ＳＥＴ及びサーバがＴＬＳハンドシェイクを完了させる。サーバは、デバイス証明書内のグローバルで一意のＳＥＴデバイスアイデンティティと関連付けられたＳＵＰＬユーザを識別することを試みる。ＳＵＰＬＥユーザは、ＳＥＴデバイスアイデンティティをそれらの加入と関連付けられるべきであることをＳＬＰに対して既にセキュリティが確保された形で検証していることが推定される。
１．ＳＥＴがＤＣｅｒｔ方法をサポートする場合は、ＳＥＴは、デバイス証明書を提供し、ＳＥＴ及びサーバがＴＬＳハンドシェイクを完了させる。サーバは、デバイス証明書内のグローバルで一意のＳＥＴデバイスアイデンティティと関連付けられたＳＵＰＬユーザを識別することを試みる。ＳＵＰＬＥユーザは、ＳＥＴデバイスアイデンティティをそれらの加入と関連付けられるべきであることをＳＬＰに対して既にセキュリティが確保された形で検証していることが推定される。
ａ．ＳＵＰＬユーザが識別されない場合は、セッションを終了させなければならない。ＴＬＳハンドシェイクは既に完了していると推定しているため、サーバは、ＵＬＰ層で通信することが可能である。サーバは、ＵＬＰセッションを終了させるための該当するＵＬＰ誤りメッセージを送信し、次に、ＴＬＳセッションを閉じなければならない。
ｂ．ＳＵＰＬユーザが識別される場合は、サーバは、ＳＵＰＬユーザと同じ権限をＳＥＴに提供する。
２．そうでない場合は、ＳＥＴは、ＳＬＰに応答し、それがＤＣｅｒｔ方法をサポートしないことを暗黙に示すための空のＣｌｉｅｎｔＣｅｒｔｉｆｉｃａｔｅメッセージを含める。
ａ．ＳＬＰがＡＣＡをサポートする場合は、ＳＬＰ及びＳＥＴは、ＡＣＡ方法に準拠して継続する。ＳＬＰは、ＡＣＡ方法を用いて継続することができる。
ｂ．ＳＬＰがＡＣＡ又はＳＬＰ専用方法をサポートしない（ＳＬＰがＤＣｅｒｔ方法のみをサポートしている可能性がある）場合は、ＳＬＰは、該当するＴＬＳ警告メッセージでＴＬＳハンドシェイクを終了させる。
ｉｉ．サーバがＣｅｒｔｉｆｉｃａｔｅ．Ｒｅｑｕｅｓｔを送信しない場合は、ＳＥＴは、ＡＣＡ方法に準拠して継続する。ＳＬＰは、ＡＣＡ方法又はＳＬＰ専用方法のいずれかを用いて継続することができる。
３ＧＰＰ２ ＳＥＴは、認証方法の交渉に関して同様の方法を使用し、選択された相違点を有する。
６．１．３．３ ＷｉＭＡＸ ＳＥＴ及びＳＬＰのための認証及び鍵再交渉に関する原則（情報用）
鍵再交渉は、次の２つの方法で行うことができる：
１．（位置に基づくサービスのためのＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおいて定義される）位置ルートキーが期限切れのときには、ＳＥＴは、自動的にｗｉｍａｘネットワークとそれ自体を再認証し、ＳＵＰＬによって関連付けられたルート鍵がＳＥＴによって再生成される、又は、
２．ＳＬＰが、ＳＥＫ又は（位置に基づくサービスのためのＷｉＭＡＸネットワークプロトコル及びアーキテクチャにおいて定義される）位置ルートキーが期限切れになっていることに気がつき、ＷｉＭＡＸ ＡＡＡサーバに新しい鍵を要求する、又は
３．ＳＬＰが、ＴＬＳハンドシェイク中に“ｐｓｋ_ｉｄｅｎｔｉｔｙ_ｕｎｋｎｏｗｎ”ＴＬＳ警告メッセージを送信する。これは、ＳＥＴがｗｉｍａｘネットワークとそれ自体を再認証する必要があり、ＳＵＰＬによって関連付けられたルート鍵がＳＥＴによって再生成される
６．１．３．３．１ 認証手順
ＷｉＭＡＸ配備においては、ＰＳＫ ＴＬＳハンドシェイクは、次のようにＳＥＫを用いて使用することができる：
− ＣｌｉｅｎｔＨｅｌｌｏメッセージは、１つ以上のＰＳＫに基づく暗号スイートを含むことができる；
− ＣｌｉｅｎｔＨｅｌｌｏメッセージは、規定されたｓｅｒｖｅｒ_ｎａｍｅＴＬＳ拡張を含むことができ、及び、それは、ＳＬＰのホスト名を含むことができる；
− ＳｅｒｖｅｒＨｅｌｌｏメッセージは、ＳＬＰによって選択されたＰＳＫに基づく暗号スイートを含むことができる；
− ＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅをサーバによって送信することができ、及び、それはｐｓｋ_ｉｄｅｎｔｉｔｙ_ｈｉｎｔフィールドを含むことができ、及び、それは、静的ストリング"ＳＵＰＬ ＷＩＭＡＸブートストラッピング"を含むことができる。
− ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅは、ｐｓｋ_ｉｄｅｎｔｉｔｙフィールドを含むことができ、及び、それは、第６．１．２．１．２節において規定される接頭辞"ＳＵＰＬ ＷＩＭＡＸブートストラッピング"、分離文字"；"及び現在のＢ_ＴＩＤを含むことができる。
− ＳＥＴは、ＳＬＰ専用の鍵素材、すなわちＳＥＫ、からＴＬＳプリマスタ秘密を導き出すことができる。
６．１．３．３．２ 認証失敗
認証失敗は、本書の範囲外の文書において説明されるように取り扱うことができる。
６．１．３．３．３ ブートストラッピングが要求されることの表示
ＴＬＳハンドシェイク中には、ＳＬＰは、ＰＳＫに基づく暗号スイートを含むＳｅｒｖｅｒＨｅｌｌｏメッセージ、及び、静的ストリング"ＳＵＰＬ ＷＩＭＡＸブートストラッピング"を含むｐｓｋ_ｉｄｅｎｔｉｔｙ_ｈｉｎｔフィールドを含むＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージを送信することによってＳＥＫ鍵を要求することができることをＳＥＴに示すことができる。ＳＥＴが有効なＳＥＫを有さない場合は、これは、ＳＥＴが第６．１．２．１．２節において定義されるように新しいＳＥＫを導き出すようにトリガすることができる。
６．１．３．３．４ ブートストラッピング再交渉表示
ＴＬＳセッションの使用中に、ＳＬＰは、ｃｌｏｓｅ_ｎｏｔｉｆｙ警告メッセージをＳＥＴに送信することによってＳＥＫが期限切れであることをＳＥＴに示すことができる。ＳＥＴが、旧セッションＩＤを含むＣｌｉｅｎｔＨｅｌｌｏメッセージを送信することによって旧ＴＬＳセッションを再開させることを試みる場合。ＳＬＰは、新しいセッションＩＤを有するＳｅｒｖｅｒＨｅｌｌｏメッセージを送信することによって旧セッションＩＤを使用するのを拒否することができる。これは、ＳＥＴが使用したＳＥＫが期限切れであることをＳＥＴに示す。
ＴＬＳハンドシェイク中に、ＳＬＰは、ＳＥＴによって送信された終了されたメッセージに応答してｈａｎｄｓｈａｋｅ_ｆａｉｌｕｒｅメッセージを送信することによってＳＥＫが期限切れになっていることをＳＥＴに示すことができる。
６．１．４ 代替クライアント認証（ＡＣＡ）メカニズム
本節は、ＧＳＭ／ＵＭＴＳ及びＣＤＭＡ ＳＥＴをサポートする配備のみに適用される。
注：本節全体を通じて、ＳＥＴ_ＩＤは、ＭＳＩＳＤＮ（ＳＥＴが３ＧＰＰベアラネットワーク上にある場合）又はＭＤＮ、ＭＩＮ又はＩＭＳＩのうちの１つ（ＳＥＴが３ＧＰＰ２ベアラネットワーク上にある場合）のいずれかを意味する。
第６．１．３節は、ＡＣＡに基づく方法をＳＬＰによって選択することができる状況について概説する。ＳＬＰがＴＬＳハンドシェイク中にＡＣＡに基づく方法を選択した場合は、ＳＥＴを認証するためにＳＥＴ_ＩＤ／ＩＰアドレスマッピングに基づくクライアント認証をＳＬＰによって使用することができる。本節の残りの部分では、代替認証メカニズムと呼ばれるこのメカニズムの詳細について説明する。ＳＬＰが代替クライアント認証メカニズムを実装する場合は、ＳＬＰは、ＧＢＡを有するＰＳＫ−ＴＬＳを使用する方法も同様に実装することが推奨される。
第６．１．１．３節は、いずれのエンティティがＡＣＡに基づく方法をサポートしなければならないか、及びＡＣＡに基づく方法をサポートするエンティティによってサポートしなければならないアルゴリズムについて説明する。情報を提供することを目的として、ここでのこの情報は繰り返しである。
◆ ベアラネットワークは、ＡＣＡに基づく方法をサポートすることができる。ベアラネットワークは、Ｈ−ＳＬＰがベアラネットワークの加入者のためにＡＣＡに基づく方法をサポートすることを希望する場合はＡＣＡに基づく方法をサポートしなければならない。
◆ ＳＬＰは、ＡＣＡに基づく方法をサポートすることができる。
◆ ＧＳＭ／ＵＭＴＳ及びＣＤＭＡ ＳＥＴハンドセットは、ＡＣＡに基づく方法をサポートしなければならない。
◆ ＡＣＡに基づく方法は、ＳＥＴ ＵＩＣＣ／ＵＩＭ／ＳＩＭ／ＵＳＩＭは含まない。
◆ ＡＣＡに基づく方法は、ＳＰＣエンティティは含まない。
代替クライアント認証をサポートするＳＥＴは、証明書に基づくサーバ（ＳＬＰ）認証を用いるＴＬＳ１．１もサポートしなければならない。さらに、ＳＥＴには、それがＳＬＰサーバ証明書を検証するのを可能にするルート証明書をプロビジョニングしなければならない。ルート証明書をＳＥＴにプロビジョニングするための様々な異なる方法が存在するため、本明細書では特定のメカニズムは定義されていない。ＳＵＰＬオペレータは、ＴＬＳ１．１が代替クライアント認証のために使用されるときには該当するルート証明書がＳＥＴ内に存在することを確認する必要がある。
代替クライアント認証をサポートするＳＬＰは、ＴＬＳ１．１をサポートしなければならず、及び、有効なＴＬＳサーバ証明書を有していなければならず、それは、代替クライアント認証を実装するＳＥＴによって検証することができる。
代替クライアント認証（ＡＣＡ）メカニズムは、ＳＬＰがＳＥＴに割り当てられたＳＥＴ_ＩＤへのＳＥＴのＩＰアドレスのバインディングを検査することができるメカニズムである。ＡＣＡメカニズムが実装される場合は、ＳＬＰは、ＳＥＴから受信されたＳＵＰＬメッセージのソースＩＰアドレスを、ＳＥＴにアドレッシングするためにＳＬＰによって用いられるＳＥＴ_ＩＤにマッピングすることができなければならない。ＳＬＰがＡＣＡメカニズムを使用するためには、ベアラネットワークは、ベアラレベルでのＩＰアドレススプーフィング（ｓｐｏｏｆｉｎｇ）を防止しなければならない。ソースＩＰアドレスとＳＥＴのＳＥＴ_ＩＤとの間での成功裏のマッピングは、ベアラネットワークにおいてＳＥＴがセキュアな形で識別されている（すなわち、認証されている）ことを意味する。この解決方法は、ＳＥＴにおける特定のクライアント（ＳＥＴ）認証の実装は要求しないが、ＳＬＰがベアラからの特定のＳＥＴ_ＩＤのための正確なソースＩＰアドレスを取得するのをサポートすることを要求する。
３ＧＰＰベアラ特有の課題：ソースＩＰアドレスの取得は、すべてのケースで可能であるわけではない−例えば、ホームネットワークではなく訪れたネットワークにおけるＧＧＳＮを用いたＧＰＲＳローミングアクセスの場合である。従って、代替クライアント認証メカニズムは、ホームネットワークがソースＩＰアドレスを割り当てるか又はそれへのアクセスを有するときのみ、例えば、ＳＥＴがホームネットワークでＧＧＳＮを使用することが要求されるときのＧＰＲＳアクセスの場合、に依存すべきである。
３ＧＰＰ２ベアラ特有の課題：ソースＩＰアドレスの取得は、すべてのケースで可能であるわけではない−例えば、訪れたネットワーク内において単純なＩＰ又はＭＩＰアドレスを用いるローミングＨＲＰＤアクセスの場合である。従って、代替クライアント認証メカニズムは、ホームネットワークがソースＩＰアドレスを割り当てるか又はそれへのアクセスを有するときのみ、例えば、ＳＥＴがホームネットワークでＨＡへのＭＩＰを使用することが要求されるときのＨＲＰＤアクセスの場合、に依存すべきである。
第６．１．４．１．節は、このメカニズムがＳＵＰＬ３．０でのクライアント認証のためにどのようにして使用されるかを説明する。
ＳＵＰＬ ＩＮＩＴを転送するためにＵＰＤ／ＬＰが使用される事例では、ＳＬＰは、最初に、ＳＥＴ_ＩＤを用いてＳＥＴ ＩＰアドレスに関してベアラネットワークに問い合わせることによって又はＩＰアドレスを用いてＳＥＴ_ＩＤに関してベアラネットワークに問い合わせることによってＩＰアドレスを検証することができる。
６．１．４．１ ＡＣＡ手順
ネットワークによって開始されるシナリオ：ＳＬＰからＳＵＰＬ ＩＮＩＴメッセージを受信後に、（及び本書の別の場所で説明されるように該当するセキュリティメカニズム及び通知／検証を適用後に）、ＳＥＴは、対応するＳＵＰＬセッションを継続する権限が付与され、第６．１．１．４節において説明されるように、既存の、オープンな相互に認証されたＴＬＳセッションが使用されるべきであるか、又は前回の再開可能なＴＬＳセッションを再開させることができる。オープンなＴＬＳセッションがないか又はＳＥＴ又はＳＬＰがセッションを再開させないことを選択した場合は、ＳＥＴ及びＳＬＰは、新しいＴＬＳセッションを要求し、ＳＥＴ及びＳＬＰは、認証方法を交渉するために第６．１．３節で説明される該当するステップを実施する。
次のステップは、ネットワークによって開始されるシナリオにおいてＳＥＴを認証するために代替クライアント認証メカニズムが適用されるときにＳＬＰによって使用される：
１．ＳＵＰＬ ＩＮＩＴメッセージは、ＳＥＴ_ＩＤを供給したＭＬＰ要求に応答して送信されたことに注目すること。ＳＬＰが、ＭＬＰ要求のためのＳＬＰセッションＩＤを割り当て、ＳＵＰＬ ＩＮＩＴを送信する。ＳＬＰが、ＳＬＰセッションＩＤを用いてＳＥＴからの応答をＭＬＰからの要求と関連付ける。しかしながら、ＳＬＰは、最初に、応答しているＳＥＴが正確なＳＥＴ_ＩＤに対応することを検証しなければならない。残りのステップではこの認証プロセスについて説明する。
２．ＳＥＴが、ＳＬＰとのＴＬＳ１．１セッションを確立する。ＳＥＴは、ＳＬＰによって提示されたＴＬＳサーバ証明書がＳＥＴにおいて設定されたＳＬＰのＦＱＤＮにバインドされていることを検査しなければならない。
３．ＳＬＰが、（ＳＵＰＬ ＩＮＩＴに応答した）ＳＥＴからの最初のＳＵＰＬメッセージ内のＳＬＰセッションＩＤがＳＬＰによって割り当てられた現在有効なＳＬＰセッションＩＤに対応するかどうかを決定する。最初のＳＵＰＬメッセージ内のＳＬＰセッションＩＤが有効なＳＬＰセッションＩＤに対応しない場合は、ＳＬＰは、該当するメッセージを用いてＳＵＰＬセッションを終了する。そうでない場合は、ＳＬＰは、対応するＳＥＴ ＩＤを注記する。
４．ＳＥＴからの最初のＳＵＰＬメッセージ（ＳＵＰＬ ＰＯＳ ＩＮＩＴ、ＳＵＰＬ ＳＴＡＲＴ、ＳＵＰＬ ＡＵＴＨ ＲＥＱＵＥＳＴ、ＳＵＰＬ ＴＲＩＧＧＥＲＥＤ ＳＴＡＲＴ、ＳＵＰＬ ＲＥＰＯＲＴ又はＳＵＰＬ ＥＮＤ）に応答する前に、ＳＬＰは、ＳＥＴのＳＥＴ_ＩＤを検証しなければならない。これを達成する方法は次の２つである。
ａ．ＳＥＴ_ＩＤを要求する。
ｉ．ＳＬＰが、ＳＥＴによって使用されるソースＩＰアドレスを用いて現在のＳＥＴ_ＩＤを見つけ出すために根本のベアラネットワークに問い合わせる。
１．ＳＥＴによって送信された最初のＳＵＰＬメッセージのソースＩＰアドレスに関してベアラから有効なＳＥＴ_ＩＤが戻された場合は、ＳＬＰは、戻されたＳＥＴ_ＩＤが正確なＳＥＴ_ＩＤと内部で関連付けられていることを検査する（ステップ３参照）。この検査が不合格である場合は、ＳＬＰは、該当するメッセージを用いてＳＵＰＬセッションを終了する。そうでない場合は、ＳＥＴは真正であるとみなされ、ＳＬＰはＳＵＰＬセッションを継続する。
２．有効なＳＥＴ_ＩＤを見つけることができない場合は、ＳＬＰは、該当するＳＵＰＬ誤りメッセージを用いてＳＵＰＬセッションを終了しなければならない。
ｂ．ＩＰアドレスを要求する
ｉ．ＳＬＰが、このＳＥＴ_ＩＤと関連付けられたＳＥＴによって使用中のソースＩＰアドレスを見つけ出すために根本のベアラネットワークに問い合わせる（ステップ３参照）。
ｉ．ＳＬＰが、このＳＥＴ_ＩＤと関連付けられたＳＥＴによって使用中のソースＩＰアドレスを見つけ出すために根本のベアラネットワークに問い合わせる（ステップ３参照）。
１．ベアラネットワークがＩＰアドレスを戻した場合は、ＳＬＰは、このＩＰアドレスが最初のＳＵＰＬメッセージのソースＩＰアドレスに対応するかどうかを検査する。この検査が不合格である場合は、ＳＬＰは、該当するＳＵＰＬメッセージを用いてＳＵＰＬセッションを終了する。そうでない場合は、ＳＥＴは真正であるとみなされ、ＳＬＰはＳＵＰＬセッションを継続する。
２．ＩＰアドレスを見つけることができない場合は、ＳＬＰは、該当するＳＵＰＬ誤りメッセージを用いてＳＵＰＬセッションを終了しなければならない。
注：ベアラネットワークは、ＳＥＴ_ＩＤ／ＩＰアドレスのバインディングを得るためにステップ４における２つのタイプの問い合わせ（ＩＰアドレスを要求する又はＳＥＴ_ＩＤを要求する）のうちの１つのみをサポートすることができる。ＳＬＰは、ベアラネットワークによってサポートされる方法を順守する責任を有する。
ＳＥＴによって開始されるシナリオ：ＳＥＴがＳＵＰＬセッションを開始することを希望する場合は、第６．１．１．４節において説明されるように、既存の、オープンな相互に認証されたＴＬＳセッションが使用されるべきであるか、又は前回の再開可能なＴＬＳセッションを再開させることができる。オープンなＴＬＳセッションがないか又はＳＥＴ又はＳＬＰがセッションを再開させないことを選択した場合は、ＳＥＴ及びＳＬＰは、新しいＴＬＳセッションを要求し、ＳＥＴ及びＳＬＰは、認証方法を交渉するために第６．１．３節で説明される該当するステップを実施する。
次のステップは、ＳＥＴによって開始されるシナリオにおいてＳＥＴを認証するために代替クライアント認証メカニズムが適用されるときにＳＬＰによって使用される：
１．ＳＥＴが、ＳＬＰとのＴＬＳ１．１セッションを確立する。ＳＥＴは、ＳＬＰによって提示されたＴＬＳサーバ証明書がＳＥＴにおいて設定されたＳＬＰのＦＱＤＮにバインドされていることを検査しなければならない。
２．最初のＳＵＰＬメッセージ（例えば、ＳＵＰＬ ＳＴＡＲＴ、ＳＵＰＬ ＴＲＩＧＧＥＲＥＤ ＳＴＡＲＴ）に応答する前に、ＳＬＰは、ＳＥＴのＳＥＴ_ＩＤを検証しなければならない。これを達成する方法は次の２つである。
ａ．ＳＥＴ_ＩＤを要求する。
ｉ．ＳＬＰが、ＳＥＴによって使用されるソースＩＰアドレスを用いて現在のＳＥＴ_ＩＤを見つけ出すために根本のベアラネットワークに問い合わせる。
１．ＳＥＴによって送信された最初のＳＵＰＬメッセージのソースＩＰアドレスに関してベアラから有効なＳＥＴ_ＩＤが戻された場合は、ＳＬＰは、戻されたＳＥＴ_ＩＤがＳＥＴによって提供されたものと同じであるかどうかを検査する。この検査が不合格である場合は、ＳＬＰは、該当するメッセージを用いてＳＵＰＬセッションを終了する。そうでない場合は、ＳＥＴは真正であるとみなされ、ＳＬＰはＳＵＰＬセッションを継続する。
２．有効なＳＥＴ_ＩＤを見つけることができない場合は、ＳＬＰは、該当するＳＵＰＬ誤りメッセージを用いてＳＵＰＬセッションを終了しなければならない。
ｂ．ＩＰアドレスを要求する
ｉ．ＳＬＰが、このＳＥＴ_ＩＤと関連付けられたＳＥＴによって使用中のソースＩＰアドレスを見つけ出すために根本のベアラネットワークに問い合わせる。
ｉ．ＳＬＰが、このＳＥＴ_ＩＤと関連付けられたＳＥＴによって使用中のソースＩＰアドレスを見つけ出すために根本のベアラネットワークに問い合わせる。
１．ベアラネットワークがＩＰアドレスを戻した場合は、ＳＬＰは、このＩＰアドレスが最初のＳＵＰＬメッセージのソースＩＰアドレスに対応するかどうかを検査する。この検査が不合格である場合は、ＳＬＰは、該当するメッセージを用いてＳＵＰＬセッションを終了する。そうでない場合は、ＳＥＴは真正であるとみなされ、ＳＬＰはＳＵＰＬセッションを継続する。
２．ＩＰアドレスを見つけることができない場合は、ＳＬＰは、該当するＳＵＰＬ誤りメッセージを用いてＳＵＰＬセッションを終了しなければならない。
注：ＳＬＰによって開始されるシナリオ及びＳＥＴによって開始されるシナリオの両方において、ＳＬＰは、ＳＥＴ_ＩＤを現在使用中のソースＩＰアドレスにバインドさせるためにベアラネットワークに該当する問い合わせを送信することによってＳＥＴを再認証することができる。これが有用であることが可能な様々な状況が存在し、例えば、（Ａ）ＳＥＴのＩＰアドレスがＴＬＳセッション中に変わった場合は、ＳＬＰは、ＳＥＴ_ＩＤが新しいＩＰアドレスと関連付けられていることを確認するためにベアラネットワークに該当する問い合わせを送信することができる、（Ｂ）ＴＬＳセッションを再開するときには、ＳＬＰは、第６．１．１．４節において説明されるように前回のＴＬＳセッションを再使用してそれによって計算を節約することができ、ＳＥＴを認証するために単にベアラネットワークに該当する問い合わせを送信するだけであることができる。この方法でＳＥＴを再認証することは、ＳＥＴ自体との対話は含まないことに注目すること。
６．２ Ｅ−ＳＬＰに適用可能な認証メカニズム
６．２．１ 緊急サービス規制当局に関して
ＳＵＰＬ３．０緊急ＳＵＰＬセッションは、（ＳＵＰＬを用いて）ネットワークによって開始させること又はＳＥＴによって開始させることができる。所管の緊急サービス規制当局は、これらの緊急セッションのためのサポートを要求する：
・ 所管の緊急サービス規制当局は、ネットワークによって開始されるセッション及びＳＥＴによって開始されるセッションのいずれに関してもサポートを要求することはできない；
・ 所管の緊急サービス規制当局は、ネットワークによって開始されるセッションのみを要求することができる；
・ 所管の緊急サービス規制当局は、ＳＥＴによって開始されるセッションのみを要求することができる；
・ 所管の緊急サービス規制当局は、ネットワークによって開始されるセッション及びＳＥＴによって開始されるセッションの両方に関するサポートを要求することができる。
６．２．２ 緊急セッション中のＳＵＰＬリソースの優先順位設定
ＳＥＴでの緊急ＳＵＰＬセッションの継続期間中には、ＳＥＴにおけるすべてのＳＵＰＬリソースがその緊急セッションのために利用可能でなければならない。従って、
・ ＳＥＴが緊急ＳＵＰＬセッションを開始するときには、非緊急セッションに関連するあらゆるＳＵＰＬ通信をＳＥＴによって直ちに終了させなければならない。この時点で非緊急ＳＵＰＬ ＩＮＩＴメッセージをＳＥＴによって処理中（例えば、ＭＡＣを検証させる又はユーザの許可を得る）である場合は、それらのプロセスは打ち切ることができ、ＳＵＰＬ ＩＮＩＴメッセージを廃棄することができる。
・ ＳＥＴが緊急ＳＵＰＬセッション中に非緊急ＳＵＰＬ ＩＮＩＴメッセージを受信した場合は、これらのＳＵＰＬ ＩＮＩＴメッセージは廃棄することができる。
６．２．３ Ｅ−ＳＬＰ ＦＱＤＮ
ネットワークによって開始される緊急ＳＵＰＬセッションでは、Ｅ−ＳＬＰのＦＱＤＮは次の通りであることができる：
１．ＳＵＰＬ ＩＮＩＴにおいてＥ−ＳＬＰアドレスとしてＳＥＴに提供されたＦＱＤＮ。Ｅ−ＳＬＰ ＦＱＤＮは、フォーマット"ｅ−ｓｌｐ．ｘｘｘ．ｘｘｘ．ｘｘｘ．ｘｘｘ．ｘｘｘ"を有することができ、ここで、"ｘｘｘ"は、あらゆる有効なストリングであることができる。
２．ＳＵＰＬ ＩＮＩＴにおいてＦＱＤＮが提供されない場合は、プロビジョニングされたＨ−ＳＬＰアドレスを使用することができる。
３．上記の１又は２に従ってＦＱＤＮを入手可能でない場合は、ＦＱＤＮは、以下の３つの代替のうちの１つをデフォルトとすることができる：
− （３ＧＰＰベアラネットワークに接続される場合）ＦＱＤＮが明
示で提供されない場合“ｅ−ｓｌｐ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．ｐｕｂ．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ”。この場合は、ＭＣＣ及びＭＮＣは、サービスを提供する３ＧＰＰネットワークに対応する。
− （３ＧＰＰベアラネットワークに接続される場合）ＦＱＤＮが明
示で提供されない場合“ｅ−ｓｌｐ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．ｐｕｂ．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ”。この場合は、ＭＣＣ及びＭＮＣは、サービスを提供する３ＧＰＰネットワークに対応する。
− （３ＧＰＰ２ベアラネットワークに接続される場合）ＦＱＤＮが明示で提供されない場合“ｅ−ｓｌｐ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．ｐｕｂ．３ｇｐｐ２ｎｅｔｗｏｒｋ．ｏｒｇ”。この場合は、ＭＣＣ及びＭＮＣは、サービスを提供する３ＧＰＰ２ネットワークに対応する。
− （ＷｉＭＡＸベアラネットワークに接続される場合）"ｅ−ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ"。ここで、ｏｐｅｒａｔｏｒ．ｃｏｍは、Ｈ−ＳＬＰオペレータのＦＱＤＮである。
ＳＥＴによって開始される緊急ＳＵＰＬセッションでは、Ｅ−ＳＬＰのＦＱＤＮは、次の優先順であることができる。
１．（該当する場合）所管の緊急サービス規制当局によって要求されたＦＱＤＮ。
２．ローカルアクセスネットワークによって又はＨ−ＳＬＰによって検証されたその他の手段によって提供されたＦＱＤＮ。
３．Ｈ−ＳＬＰによって提供されたＦＱＤＮ。
６．２．４． 緊急ＳＵＰＬ ＩＮＩＴメッセージの処理
ＳＵＰＬ ＩＮＩＴメッセージのＳＥＴに基づく完全性検証及びメッセージ源認証はＥ−ＳＬＰによって使用されない。従って、緊急ＳＵＰＬ ＩＮＩＴにおけるＭＡＣフィールドは埋めてはならない。
緊急呼中には、ＳＥＴは、緊急ＳＵＰＬ ＩＮＩＴメッセージのエンド−ツー・エンド保護を適用することができない。
Ｅ−ＳＬＰホワイトリスト（ｗｈｉｔｅｌｉｓｔ）の使用によって何らかの保護が提供される。Ｅ−ＳＬＰホワイトリストは、ＳＥＴの現在の位置推定値（例えば、ＣｅｌｌＤ及び／又はＮｅｔｗｏｒｋＩＤ）に基づく。Ｅ−ＳＬＰホワイトリストは、ＳＥＴが受信された緊急ＳＵＰＬ ＩＮＩＴメッセージを処理すべき順序を決定するためにＳＥＴによって使用される。すなわち、Ｅ−ＳＬＰホワイトリストは、緊急ＳＵＰＬ ＩＮＩＴメッセージを廃棄するためには使用することができない。
６．２．４．１ Ｅ−ＳＬＰホワイトリスト
エンド−ツー−エンドでセキュリティが確保されていないチャネルで緊急ＳＵＰＬ ＩＮＩＴメッセージが受信された場合は（例えば、ＳＭＳ又はＯＭＡ Ｐｕｓｈ又はＵＤＰ／ＩＰ）、緊急ＳＵＰＬ ＩＮＩＴメッセージは偽物であるか又は変更されているおそれがある。本節の残りの部分では、ＳＥＴが可能な限り速やかに真正のＥ−ＳＬＰサーバに確実に接触できるようにするためのセキュリティ対策について説明する。
注：規制上の要件では、ＳＥＴが緊急ＳＵＰＬ ＩＮＩＴメッセージを受け入れて処理すべき条件を規定する。例えば、多くの事例では、規制上の要件は、ＳＥＴが緊急呼に現在従事している場合に緊急ＳＵＰＬ ＩＮＩＴメッセージを受け入れて処理することをＳＥＴに要求するだけである。従って、（ＳＥＴが緊急ＳＵＰＬ ＩＮＩＴメッセージを受け入れて処理すべき）条件は、本書の範囲外である。
ＳＥＴが緊急ＳＵＰＬ ＩＮＩＴメッセージを受信したときには、ＳＥＴは、最初に、（ＳＥＴが緊急ＳＵＰＬ ＩＮＩＴメッセージを受け入れるべき）条件が現在満たされていることを検証しなければならない。それらの条件が満たされていない場合は、ＳＥＴは、ＳＵＰＬ ＩＮＩＴメッセージを無視することができる。ここからの説明では、ＳＥＴが緊急ＳＵＰＬ ＩＮＩＴメッセージを受信したときにそれらの条件が満たされていたと仮定する。
注：攻撃者は、ＳＥＴが真正の緊急ＳＵＰＬ ＩＮＩＴメッセージをまさに予想しているときに複数の（偽の）緊急メッセージをＳＥＴに送信する可能性がある。いずれの緊急ＳＬＰからの緊急ＳＵＰＬ ＩＮＩＴメッセージを予想すべきであるをＳＥＴに対して（事前に）伝えることができないケースが存在することがある。この攻撃が動機となって次の手順が設けられている。
"受け入れ及び処理"条件が満たされている期間中は、ＳＥＴは、緊急ＳＵＰＬ ＩＮＩＴメッセージがＥ−ＳＬＰに関する予想外のアドレスを記載している場合でも受信された緊急ＳＵＰＬ ＩＮＩＴメッセージを削除してはならない。条件がもはや満たされていないとＳＥＴが決定した時点で（例えば、正確なＥ−ＳＬＰに接触されているか又は緊急呼後に十分な時間が経過している時点で）、ＳＥＴは、あらゆる受信された緊急ＳＵＰＬ ＩＮＩＴメッセージを暗黙に廃棄しなければならない。
（"受け入れ及び処理"条件が依然として満たされている間に）ＳＥＴが偽の緊急ＳＵＰＬ ＩＮＩＴメッセージを受信し、受け入れ及び処理する場合は、ＳＥＴは、緊急ＳＵＰＬ ＩＮＩＴメッセージ内で示されているＥ−ＳＬＰに接触するのを試みるまでは緊急ＳＵＰＬ ＩＮＩＴメッセージが偽物であるという表示を受信できないことがある。この表示は、Ｅ−ＳＬＰがＳＵＰＬセッションを拒否したときに発生する。このプロセスは即時的ではなく、このため、ＳＥＴが２つ以上の緊急ＳＵＰＬ ＩＮＩＴメッセージを受信した場合は緊急ＳＵＰＬ ＩＮＩＴメッセージを待ち行列に入れることが必要な場合がある。
Ｅ−ＳＬＰホワイトリストは、ＳＥＴが緊急ＳＵＰＬ ＩＮＩＴメッセージを受信するのを予想することが可能なＥ−ＳＬＰ ＦＱＤＮのリストを含む。ＳＥＴは、ホワイトリスト上に存在するＥ−ＳＬＰ ＦＱＤＮを含む緊急ＳＵＰＬ ＩＮＩＴメッセージが、ホワイトリスト上に存在しないＥ−ＳＬＰ ＦＱＤＮを含む緊急ＳＵＰＬ ＩＮＩＴメッセージの前に確実に処理されるようにするためにＥ−ＳＬＰホワイトリストを使用する。
例：ホワイトリスト上のＥ−ＳＬＰ ＦＱＤＮを含む緊急ＳＵＰＬ ＩＮＩＴメッセージは、ホワイトリスト上に存在しないＥ−ＳＬＰ ＦＱＤＮを含む緊急ＳＵＰＬ ＩＮＩＴメッセージの前に確実に処理されるようにするために緊急ＳＵＰＬ ＩＮＩＴ待ち行列において前方に進められる。Ｅ−ＳＬＰホワイトリストに記載されているかどうかは、緊急ＳＵＰＬ ＩＮＩＴ待ち行列の順序を設定するための第１の判定基準である。第２の判定基準は、到着時間であり、先入れ先出し方式を使用する：
・ ＳＥＴがＳＥＴの現在位置に関する現在のＥ−ＳＬＰホワイトリストを有する場合は、ＳＥＴは、待ち行列の順序を設定するために両方の判定基準を使用する。
・ ＳＥＴがＳＥＴの現在位置に関する現在のＥ−ＳＬＰホワイトリストを有しない場合は、ＳＥＴは、待ち行列の順序を設定するために先入れ先出し方式を使用する。
６．２．４．３ 緊急ＳＵＰＬ ＩＮＩＴメッセージに関する手順
エンド・ツー・エンドでセキュリティが確保されているチャネルで緊急ＳＵＰＬ ＩＮＩＴが受信された場合は（例えば、セキュアなＳＩＰ Ｐｕｓｈ）、
緊急ＳＵＰＬ ＩＮＩＴメッセージは、直ちに処理することができる。この場合は、本小節の残りの考慮事項は無視される。
エンド・ツー・エンドでセキュリティが確保されていないチャネルで緊急ＳＵＰＬ ＩＮＩＴメッセージが受信された場合は（例えば、ＳＭＳ又はＯＭＡ Ｐｕｓｈ又はＵＰＤ／ＩＰ）、そのメッセージは、第６．２．４．１節に従って待ち行列に入れられる。ＳＥＴは、待ち行列内のメッセージ内を進行し、応答するためにＥ−ＳＬＰに接続するのを試みる前に該当する検証及び通知を適用する。
ＳＥＴは、ＳＵＰＬ ＩＮＩＴメッセージに応答して、関連付けられたＥ−ＳＬＰ（第６．２．３節参照）とセキュアなＴＬＳセッション（第６．２．５節参照）を確立することができ、次のうちの１つが生じる。
◆ ＳＥＴを認証後に（第６．２．５節参照）、Ｅ−ＳＬＰがＳＥＴを未終了状態のＳＵＰＬセッションと関連付けることができない場合は、Ｅ−ＳＬＰは、そのセッションを終了させることができる。ＴＬＳハンドシェイクがまだ完了していない場合は、Ｅ−ＳＬＰは、不必要な計算を節約するために、ＴＬＳ誤りメッセージを用いてセッションを終了させるべきである。ＴＬＳハンドシェイクが完了している場合は、Ｅ−ＳＬＰは、ＳＵＰＬ誤りメッセージを用いてセッションを終了させ、ＳＥＴに権限が付与されていないことを示すことができる。ＳＥＴは、いずれの形式の誤りメッセージも、ＳＵＰＬ ＩＮＩＴメッセージが不正なものであることを示すと解釈することができる。次に、ＳＥＴは、待ち行列内の優先順位に従って次のＳＵＰＬＩＮＩＴメッセージに進んだ。
◆ ＳＥＴを認証後に（第６．２．５節参照）、Ｅ−ＳＬＰがＳＥＴを未終了状態のＳＵＰＬセッションと関連付けることができる場合は、ＳＥＴ及びＥ−ＳＬＰは、通常通り継続する。
ＳＥＴは、真正のメッセージが見つかるまで緊急ＳＵＰＬ ＩＮＩＴメッセージに応答し続ける。ＳＥＴは、正しいＥ−ＳＬＰがいったん識別された時点であらゆる新しい又は待ち行列内のＳＵＰＬ ＩＮＩＴメッセージを廃棄することができる。正しいＥ−ＳＬＰからの新しい又は待ち行列内のＳＵＰＬ ＩＮＩＴメッセージはまだ処理することができる。
次の２つの注記は、規制当局が考慮することを希望する提案である。
注：正しいＥ−ＳＬＰがいったん識別された時点で、ＳＥＴは、ＳＵＰＬセッションが成功裏に完了するまでこの正しいＥ−ＳＬＰのＦＱＤＮを必ず覚えているべきである。Ｅ−ＳＬＰとのＴＬＳセッションの終了が早すぎる場合（例えば、データの接続性が失われた場合）は、ＳＥＴは、ＳＵＰＬセッションが成功裏の完了まで継続することができるようにＴＬＳセッションが再確立されるまでＥ−ＳＬＰとのＴＬＳセッションを再確立するのを試み続けるべきである。幾つかの状況においては、ＳＥＴがＴＬＳセッションを数回再確立することが考えられる。ＳＥＴがＴＬＳセッションを再確立することに成功していない場合は、ＳＥＴは、それにもかかわらず試み続けるべきである。これは緊急的な状況であるため、成功することの利益の方がバッテリ切れのコストよりも重要である。
注：認証後であるがＳＵＰＬセッションの成功裏の完了前にＥ−ＳＬＰがＳＥＴとの接触を絶った場合は、Ｅ−ＳＬＰは、ＳＥＴが接触を再確立してＳＵＰＬセッションを完了させることができることに望みをかけてＳＵＰＬセッションをオープン状態にすべきである。
６．２．５ 緊急セッションのための認証
注：Ｅ−ＳＬＰによってサポートすることができる相互認証方法が第６．１．１．３節に示されている。ＳＥＴ及びＥ−ＳＬＰは、第６．１．３節において規定されるように、ＴＬＳハンドシェイク中に相互認証方法に関して交渉する。
緊急セッションに関する優先順位は次の通りである。
・ ＧＢＡ又はＳＥＫ方法：第１位
・ ＤＣｅｒｔ方法：第２位
・ ＡＣＡ方法：第３位
・ ＳＬＰ専用方法：最下位。ＳＬＰ専用方法は最後の手段であるとみるべきである。
・ ＤＣｅｒｔ方法：第２位
・ ＡＣＡ方法：第３位
・ ＳＬＰ専用方法：最下位。ＳＬＰ専用方法は最後の手段であるとみるべきである。
すべてのこれらのケースに関するＥ−ＳＬＰのＦＱＤＮが第６．２．３節で説明されている。
ＧＢＡに基づく方法（３ＧＰＰ／３ＧＰＰ２ ＳＥＴのみ）：ＳＥＴ及びＥ−ＳＬＰは、第６．１．３節において説明されるようにＧＢＡを用いてＰＳＫ−ＴＬＳを行うことができ、Ｅ−ＳＬＰがＮＡＦとして行動する。特定のＳＥＴに関してＥ−ＳＬＰによって入手されたＫｓ_ＮＡＦは、ホームネットワークオペレータによって設定された寿命の間ＳＥＴアイデンティティ（例えば、ＩＭＳＩ、ＭＳＩＳＤＮ）と関連付けて保持することができる。
ＳＥＫに基づく方法（ＷｉＭＡＸ ＳＥＴのみ）：ＳＥＴ及びＥ−ＳＬＰは、第６．１．３節において説明されるようにＳＥＫを用いるＰＳＫ−ＴＬＳを用いて相互認証を行うことができ、Ｅ−ＳＬＰはＨ−ＳＬＰと同様に行動する。Ｅ−ＳＬＰのＦＱＤＮは第６．２．３節で説明されている。特定のＳＥＴに関してＥ−ＳＬＰによって入手されたＳＥＫは、ホームネットワークオペレータによって設定された寿命の間ＳＥＴアイデンティティ（例えば、ＷｉＭＡＸユーザＩＤ）と関連付けて保持することができる。
ＤＣｅｒｔ方法（全ＳＥＴ）：ＳＥＴ及びＥ−ＳＬＰは、第６．１．２．２．１節において説明されるようにＤＣｅｒｔ方法を用いた相互認証を行うことができる。ＳＥＴは、ＳＥＴに含まれるＥ−ＳＬＰのルート証明書及び第６．２．３節において定義されるＥ−ＳＬＰのＦＱＤＮを用いてＥ−ＳＬＰを認証することができる。
ＡＣＡに基づく方法（３ＧＰＰ／３ＧＰＰ２ ＳＥＴ 対応するベアラネットワーク上にある間のみ）：ＰＳＫ−ＴＬＳを用いるＧＢＡ及びＤＣｅｒｔ方法の両方がＥ−ＳＬＰにおいてサポートされていないＳＵＰＬ３．０実装に関して、第６．１．４節において定義される代替クライアント認証メカニズムをサポートすることができ、次の相違点が存在する。Ｅ−ＳＬＰは、ＳＥＴによって用いられるＩＰアドレスを、サービングネットワークによって−例えば、３ＧＰＰネットワークにおける、又は３ＧＰＰ２ネットワークにおけるＬＲＦ又はＥ−ＣＳＣＦによって、Ｅ−ＳＬＰに提供されたＳＥＴのためのＩＰアドレスとバインドさせることによってＳＥＴを認証することができる。
・ネットワークによって開始されるセッション：ＳＥＴ ＩＰアドレスは、あらゆる緊急ＶｏＩＰ呼を開始するために使用され、及び、ＳＵＰＬが呼び出される前にサービングネットワークによって検証することができるため、それは、Ｅ−ＳＬＰによって信頼できるとみなすことができる。回線モードで開始された緊急呼の場合は、ＳＥＴ ＩＰアドレスはサービングネットワークに知られていないことがあり（例えば、ホームネットワークによって割り当てることができる）、その場合は、サービングネットワークによってＥ−ＳＬＰにＩＰアドレスを提供することができず及びのちにＳＥＴから受信されたときにＩＰアドレスを検証することができない。
・ＳＥＴによって開始されるセッション：ＡＣＡ方法を使用するために、サービングベアラネットワークは、ベアラレベルでのＩＰアドレスのスプーフィングを防止しなければならない。ＡＣＡ方法は、ＳＥＴがベアラネットワークにおいて認証されたとして登録されているどうかにかかわらず適用することができる。これは、ＳＥＴ内に起動されたＳＩＭ／ＵＳＩＭ／ＵＩＣＣ／（Ｒ）ＵＩＭが存在しない場合をサポートする。
ＳＬＰ専用方法（全ＳＥＴ）：その他のいずれの認証方法も使用できない場合は、ＳＥＴは、ＳＬＰ専用方法を用いてＥ−ＳＬＰへのセキュアなＩＰコネクションを確立することができる。ＳＥＴは、ＳＥＴに含まれるＥ−ＳＬＰのルート証明書及び第６．２．３節において定義されるＥ−ＳＬＰのＦＱＤＮを用いてＥ−ＳＬＰを認証することができる。相互認証を行う能力は、セッションがＳＥＴによって開始されるか又はネットワークによって開始されるかに依存する。
・ ネットワークによって開始されるセッション：ＳＵＰＬセッションがネットワークによって開始される場合は、Ｅ−ＳＬＰは、（例えば）第６．２．６節において説明されるようにセッションＩＤ及びＳＵＰＬ ＩＮＩＴの受信されたハッシュに基づいてＳＥＴの弱い認証をすることができる。
・ ＳＥＴによって開始されるセッション：ＳＵＰＬセッションがＳＥＴによって開始される場合
ＳＬＰ専用方法は、ＳＥＴがベアラネットワークにおいて認証されたとして登録されているどうかにかかわらず適用できることが注目されるべきである。これは、ＳＥＴ内に起動されたＳＩＭ／ＵＳＩＭ／ＵＩＣＣ／（Ｒ）ＵＩＭが存在しない場合をサポートする。
ＳＬＰ専用方法は、ＳＥＴがベアラネットワークにおいて認証されたとして登録されているどうかにかかわらず適用できることが注目されるべきである。これは、ＳＥＴ内に起動されたＳＩＭ／ＵＳＩＭ／ＵＩＣＣ／（Ｒ）ＵＩＭが存在しない場合をサポートする。
６．２．６ 緊急ＳＵＰＬセッションに関するＳＵＰＬ ＩＮＩＴの完全性保護
Ｅ−ＳＬＰが第６．２．５節において説明されるようにＳＥＴを認証することができ、及び、Ｅ−ＳＬＰがＳＥＴを未終了状態のＳＵＰＬセッションと関連付けることができる場合は、Ｅ−ＳＬＰは、ＳＵＰＬ ＩＮＩＴメッセージが変更されたかどうかを検査する。ＳＵＰＬ ＩＮＩＴメッセージが変更されたことをＥ−ＳＬＰが検出した場合（例えば、プロキシモードが指示されたときにＳＵＰＬ ＡＵＴＨ ＲＥＱメッセージが受信された場合、又はＳＬＰセッションＩＤが誤っている場合又はＶＥＲが第６．３．１節において説明される検証に失敗した場合）は、Ｅ−ＳＬＰは、ＳＥＴに正しいパラメータが提供されるようにするためにＴＬＳセッションを通じてＳＥＴにＳＵＰＬ ＩＮＩＴを送信しなければならない。応答して、ＳＥＴは、最初に受信されたＳＵＰＬ ＩＮＩＴを用いて開始されたＳＵＰＬセッションを廃棄し、ＳＥＴは、ＴＬＳセッションを通じて受信されたＳＵＰＬ ＩＮＩＴを用いて新しいＳＵＰＬセッションを開始することができる。次に、ＳＥＴは、直ちにそのＳＵＰＬ ＩＮＩＴメッセージを処理することができ（すなわち、ＳＥＴは、Ｅ−ＳＬＰホワイトリストを用いて優先度を評価しない）、通知及び検証のための該当する行動を行い、ユーザがセッションを拒否しないことを条件として、ＳＥＴは、セッションを継続するためにＥ−ＳＬＰに該当するメッセージ（ＳＵＰＬ ＰＯＳ ＩＮＩＴ又はＳＵＰＬ ＡＵＴＨ ＲＥＱ）を送信する。
ＳＵＰＬ ＩＮＩＴを再送信する能力は、緊急セッションのみを対象とすることが意図される。非緊急セッションでは、ＳＵＰＬ ＩＮＩＴの変更が検出された場合は、ＳＬＰは、非緊急呼の流れにおいて規定されるように、ＳＵＰＬ ＥＮＤを用いてＳＵＰＬセッションを終了させることができる。
６．３ ＳＵＰＬ ＩＮＩＴメッセージの処理
ネットワークによって開始されるセッションはＳＵＰＬ ＩＮＩＴメッセージによってトリガされるため、なりすまし及び（幾つの場合は）リプレイ攻撃からＳＵＰＬ ＩＮＩＴメッセージを保護することが不可欠である。
ＳＵＰＬ３．０は、ＳＵＰＬ ＩＮＩＴメッセージのための次の保護を規定している。
・ ネットワークに基づくセキュリティ。ＳＬＰは、ＳＵＰＬ ＩＮＩＴメッセージの認証（第６．３．１節）及びリプレイ保護（第６．３．２節）を確認するための検査を行うことができる。この検証は、ＳＥＴがＳＵＰＬ ＩＮＩＴメッセージの内容を処理し、ＳＵＰＬセッションを実施するためにＳＬＰとセキュアなＴＬＳセッションを確立した後に生じる。
・エンド・ツー・エンドセキュリティ：ＳＬＰは、暗号化、完全性保護及びリプレイ保護の組み合わせをＳＵＰＬ ＩＮＩＴメッセージに適用することができ、ＳＥＴは、復号、完全性検証及びリプレイ検出の対応する組み合わせを適用する。ＳＥＴは、ＳＵＰＬ ＩＮＩＴメッセージの内容を処理する前にこれらのセキュリティ措置を適用する。このセキュリティは、非緊急ＳＵＰＬ ＩＮＩＴメッセージのみに適用される。
ネットワークに基づくセキュリティは強制的であり、エンド・ツー・エンドセキュリティは任意選択である。
６．３．１ ＳＵＰＬ ＩＮＩＴメッセージのネットワークに基づく認証
ＳＬＰは、ＳＵＰＬ ＩＮＩＴメッセージの完全性のネットワーク検証を常時行う。ＳＵＰＬ ＩＮＩＴメッセージに応答して送信される最初のメッセージ（すなわち、ＳＵＰＬ ＰＯＳ ＩＮＩＴ、ＳＵＰＬ ＡＵＴＨ ＲＥＱ 又はＳＵＰＬ ＴＲＩＧＧＥＲＥＤ ＳＴＡＲＴメッセージ）は、検証フィールド（ＶＥＲ）を含まなければならない。ＳＬＰがＳＵＰＬ ＩＮＩＴメッセージに応答して最初のメッセージを受信したときには、ＳＬＰは、送信されたＳＵＰＬ ＩＮＩＴメッセージに関して計算された対応する値に照らして受信されたＶＥＲフィールドを検査する。この検証が不合格の場合は、ＳＬＰは、状態コード‘ａｕｔｈＳｕｐｌｉｎｉｔＦａｉｌｕｒｅ’が入ったＳＵＰＬ ＥＮＤメッセージを用いてセッションを終了させなければならない。
検証フィールドのための値は、次のように計算しなければならない：
・ ＶＥＲ＝Ｈ（ＳＬＰ ＸＯＲ ｏｐａｄ，Ｈ（ＳＬＰ ＸＯＲ ｉｐａｄ，ＳＵＰＬ ＩＮＩＴ））
ここで、ＳＬＰは、ＳＬＰアドレスのＦＱＤＮである。ＳＨＡ−２５６は、ｏｐａｄ及びｉｐａｄを有するハッシュ（Ｈ）関数として使用しなければならない。ＳＨＡ−２５６ ＨＡＳＨ関数の出力は、６４ビットで打ち切らなければならない。すなわち、同関数は、ＨＭＡＣ−ＳＨＡ２５６−６４として実装しなければならない。ＳＬＰアドレスは秘密とはみなされないことに注目すること。ここで使用されるＨＭＡＣ構造は、どのようなデータ認証も提供せず、ＨＡＳＨ関数の代替として使用されるにすぎない。
６．３．２ ＳＵＰＬ ＩＮＩＴメッセージのネットワークに基づくリプレイ保護
ネットワークによって開始される事例に関しては、リプレイ攻撃に対する保護をＳＬＰによって提供しなければならない。ＳＬＰは、前回の、期限切れでないＳＵＰＬ ＩＮＩＴメッセージがＳＵＰＬメッセージ内部で受信された“ＳＬＰセッションＩｄ”に対応するそれとともに送信されていないかぎり認証されたＳＥＴからのどのようなＳＵＰＬメッセージも受け入れられないようにしなければならない。ＳＬＰは、ＳＵＰＬメッセージのタイプ（例えば、ＳＵＰＬ ＰＯＳ ＩＮＩＴ、ＳＵＰＬ ＡＵＴＨ ＲＥＱ、ＳＵＰＬ ＴＲＩＧＧＥＲＥＤ ＳＴＡＲＴ）がＳＵＰＬ ＩＮＩＴメッセージで送信されたパラメータと一致することも確認しなければならない。実装では、“ＳＬＰセッションＩｄ”が認証されているＳＥＴユーザＩＤ（例えば、ＭＳＩＳＤＮ、ＷｉＭＡＸユーザＩＤ又はＭＤＮ）と正確に関連付けられるようにしなければならない。
ＳＥＴユーザ認証が、本書で説明される代替クライアント認証方法を用いて行われる場合は、ＳＥＴからの応答（ＳＵＰＬ ＰＯＳ ＩＮＩＴ、ＳＵＰＬ ＡＵＴＨ ＲＥＱ又はＳＵＰＬ ＴＲＩＧＧＥＲＥＤ ＳＴＡＲＴ）のソースＩＰアドレスとＳＥＴユーザのＭＳＩＳＤＮ又はＭＤＮとの間のマッピングが既に確立されており、このＭＳＩＳＤＮ又はＭＤＮを認証されたＭＳＩＳＤＮ又はＭＤＮとして使用しなければならない。
誤りのあるＳＵＰＬ ＰＯＳ ＩＮＩＴ、ＳＵＰＬ ＡＵＴＨ ＲＥＱ又はＳＵＰＬ ＴＲＩＧＧＥＲＥＤ ＳＴＡＲＴの廃棄は、ＳＥＴにとっての課金可能な（ｃｈａｒｇｅａｂｌｅ）イベントを生成させてはならない。
非プロキシネットワークによって開始される事例に関しては、ＳＬＰは、ＳＵＰＬ測位の成功裏の完了に関する確認をＳＰＣから受信後のみに課金可能なイベントを生成しなければならない。
６．３．３ ＳＵＰＬ ＩＮＩＴメッセージのエンド・ツー・エンド保護
注：ＳＵＰＬ ＩＮＩＴメッセージのエンド・ツー・エンド保護は、非緊急ＳＵＰＬ ＩＮＩＴメッセージのみに対して適用される。
本明細書では、エンド・ツー・エンドのＳＵＰＬ ＩＮＩＴ保護のために３つの選択肢が提供されている。すなわち、Ｎｕｌｌ（ヌル）、モードＡ及びモードＢである。
・ Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護は、エンド・ツー・エンドの完全性保護、エンド・ツー・エンドのリプレイ保護及び秘密性保護のいずれも提供しない。Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護のための手順は、第６．３．４節で説明される。
・ モードＡ ＳＵＰＬ ＩＮＩＴ保護は、デフォルトのアルゴリズムを用いてのエンド・ツー・エンドの完全性保護及びエンド・ツー・エンドのリプレイ保護を提供する。モードＡ ＳＵＰＬ ＩＮＩＴ保護は、セキュリティが確保されたＵＬＰセッション中にＳＬＰによってＳＥＴに送信された共有鍵を使用する。モードＡ ＳＵＰＬ ＩＮＩＴ保護のための手順は、第６．３．５節で説明される。
・ モードＢ ＳＵＰＬ ＩＮＩＴ保護は、デフォルトのアルゴリズムを用いてのエンド・ツー・エンドの完全性保護及びエンド・ツー・エンドのリプレイ保護を提供する。モードＢ ＳＵＰＬ ＩＮＩＴ保護は、該当するＰＳＫに基づく方法（ＧＢＡ方法又はＳＥＫ方法）を用いて導き出された共有鍵を使用する。モードＢ ＳＵＰＬ ＩＮＩＴ保護のための手順は、第６．３．６節で説明される。
保護レベルに関する優先順位は次の通りである：
◆ Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護が最も低い優先順位を有する。
◆ モードＡ ＳＵＰＬ ＩＮＩＴ保護は、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護よりも高い優先順位を有する。
◆ モードＢ ＳＵＰＬ ＩＮＩＴ保護は、モードＡ ＳＵＰＬ ＩＮＩＴ保護よりも高い優先順位を有する。
ＳＵＰＬ ＩＮＩＴメッセージ内では、（下表内の）Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌ（保護レベル）パラメータが現在の保護レベルに従って割り当てられる。
注：本明細書は、将来の改訂版において加えられることになるより高度な保護レベルを考慮して書かれている。この高度な保護は、ＳＵＰＬ ＩＮＩＴのセキュリティを確保するためのその他の方法についての交渉を可能にすることができる（例えば、暗号化を可能にすること及びアルゴリズムの交渉を可能にすること）。ＳＥＴがＳＵＰＬ ＩＮＩＴメッセージを構文解析することができるかどうかを決定する際の助けとなるＰｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータが含まれている。保護レベルパラメータは、拡張性のために要求されることがある。
ＳＵＰＬ ＩＮＩＴメッセージは、セキュリティパラメータを含めるためのＰｒｏｔｅｃｔｏｒ（プロテクタ）パラメータを存在させることができる。Ｐｒｏｔｅｃｔｏｒパラメータの存在は下表において規定される。
ＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｏｒ Ｌｅｖｅｌパラメータ値及びＳＵＰＬ ＩＮＩＴ内でのＰｒｏｔｅｃｔｏｒパラメータの存在
ＡＣＡに基づく方法をサポートするＳＥＴ又はＤ−ＳＬＰ又はＨ−ＳＬＰは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護をサポートしなければならない。
ＡＣＡに基づく方法をサポートするＳＥＴ又はＤ−ＳＬＰ又はＨ−ＳＬＰは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護をサポートしなければならない。
全ＳＥＴが、モードＡ ＳＵＰＬ ＩＮＩＴ保護手順をサポートしなければならない。
Ｄ−ＳＬＰ又はＨ−ＳＬＰは、モードＡ ＳＵＰＬ ＩＮＩＴ保護手順をサポートすることができる。ＰＳＫに基づく方法をサポートするＳＥＴ又はＤ−ＳＬＰ又はＨ−ＳＬＰは、モードＢ ＳＵＰＬ ＩＮＩＴ保護手順をサポートしなければならない。
Ｅ−ＳＬＰエンティティは、現在定義されているＳＵＰＬ ＩＮＩＴ保護には関わっていない。
６．３．３．１ ＳＵＰＬ ＩＮＩＴ保護レベルの交渉
次のプロセスは、Ｄ−ＳＬＰ又はＨ−ＳＬＰであるＳＬＰのみに適用され、それらのプロセスは、Ｅ−ＳＬＰには適用されない。
ＳＵＰＬ ＩＮＩＴ保護レベルがどのようにして交渉されるかに関する情報を提供するための説明を以下に示した：
１．ＳＥＴは、有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが存在しないときには（例えば、パワーアップ時又はＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの寿命が切れているとき）Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護を適用しなければならない。初期の保護レベルは、常にＮｕｌｌ ＳＵＰＬ ＩＮＩＴである。この状態で、ＳＥＴは、すべてのＳＵＰＬ ＩＮＩＴメッセージを処理する、すなわち、いずれのメッセージも暗黙に廃棄されない。ＳＵＰＬ ＩＮＩＴメッセージが不具合状態で構文解析される場合は、ＳＥＴは、誤りメッセージをＳＬＰに送信する。
２．ＳＥＴが、特定のＳＬＰに関してモードＡ又はモードＢ ＳＵＰＬ ＩＮＩＴ保護を用いて既に交渉された有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及び有効なリプレイカウンタを有する場合は、ＳＥＴは、交渉されたモード（モードＡ又はモードＢ）を用いてそのＳＬＰからのすべてのＳＵＰＬ ＩＮＩＴメッセージを処理する。
３．ＳＥＴがＳＬＰへの相互に認証されたセキュアなコネクションを確立するときに、
ａ．相互認証のためにＰＳＫに基づく方法（ＧＢＡ又はＳＥＫ）が使用された場合は、モードＢ ＳＵＰＬ ＩＮＩＴ保護が適用され、ＰＳＫ−ＴＬＳのハンドシェイクにおいてやり取りされたＢ−ＴＩＤは、Ｋｓ（３ＧＰＰ及び３ＧＰＰ２配備ではＫｓ_ＮＡＦとして使用される）又は３ＧＰＰ及び３ＧＰＰ２配備においてＫｓ_ＮＡＦとして使用されるＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを導き出すために使用することができるＳＥＫに対応する。このＫｓ_ＮＡＫ又はＳＥＫ及び関連付けられたＢ−ＴＩＤは、以下のいずれかまでモードＢ ＳＵＰＬ ＩＮＩＴ保護で使用される。
ａ．相互認証のためにＰＳＫに基づく方法（ＧＢＡ又はＳＥＫ）が使用された場合は、モードＢ ＳＵＰＬ ＩＮＩＴ保護が適用され、ＰＳＫ−ＴＬＳのハンドシェイクにおいてやり取りされたＢ−ＴＩＤは、Ｋｓ（３ＧＰＰ及び３ＧＰＰ２配備ではＫｓ_ＮＡＦとして使用される）又は３ＧＰＰ及び３ＧＰＰ２配備においてＫｓ_ＮＡＦとして使用されるＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを導き出すために使用することができるＳＥＫに対応する。このＫｓ_ＮＡＫ又はＳＥＫ及び関連付けられたＢ−ＴＩＤは、以下のいずれかまでモードＢ ＳＵＰＬ ＩＮＩＴ保護で使用される。
ｉ．鍵が期限切れになるまで。この場合は、ＳＥＴ及びＳＬＰはＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護に戻る
ｉｉ．ＳＥＴ及びＳＬＰが非緊急セッションでＡＣＡ方法を使用するまで。この場合は、ＳＥＴ及びＳＬＰは、以下のステップ３のｂにおいて説明されるようにモードＡ又はＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護に戻る、又は、
ｉｉｉ．ＳＥＴ及びＨ−ＳＬＰが、新しいＢ−ＴＩＤを用いてＴＬＳを確立するためにＧＢＡの又はＳＥＫのブートストラッピング再交渉方法を使用するまで。この場合は、Ｂ−ＴＩＤ及び対応するＫｓ_ＮＡＦ又はＳＥＫがモードＢ ＳＵＰＬ ＩＮＩＴ保護のために使用される。
ｉｉ．ＳＥＴ及びＳＬＰが非緊急セッションでＡＣＡ方法を使用するまで。この場合は、ＳＥＴ及びＳＬＰは、以下のステップ３のｂにおいて説明されるようにモードＡ又はＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護に戻る、又は、
ｉｉｉ．ＳＥＴ及びＨ−ＳＬＰが、新しいＢ−ＴＩＤを用いてＴＬＳを確立するためにＧＢＡの又はＳＥＫのブートストラッピング再交渉方法を使用するまで。この場合は、Ｂ−ＴＩＤ及び対応するＫｓ_ＮＡＦ又はＳＥＫがモードＢ ＳＵＰＬ ＩＮＩＴ保護のために使用される。
ｂ．そうでない場合は、ＳＥＴ及びＳＬＰは、ＤＣｅｒｔ方法又はＡＣＡ方法を用いてセキュアなコネクションを確立した。
ｉ．ＳＥＴが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない場合は、ＳＥＴは、最初のＵＬＰメッセージでＳＵＰＬ_ＩＮＩＴ_ＫｅｙＲｅｑｕｅｓｔパラメータをＳＬＰに送信する。
１．ＳＬＰがモードＡ ＳＵＰＬ ＩＮＩＴ保護をサポートする場合は、ＳＬＰは、ＳＥＴに対する最初のＵＬＰ応答においてはＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及びＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒパラメータを送信することによって応答する。ＳＥＴがこれらのパラメータを受信したときに、これは、モードＡ ＳＵＰＬ ＩＮＩＴ保護が適用されることをＳＥＴに示す。
注：ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを更新する方針は、ＳＬＰオペレータの判断である。
２．ＳＬＰが、モードＡ ＳＵＰＬ ＩＮＩＴ保護をサポートしない（又はこの特定の時点でモードＡ ＳＵＰＬ ＩＮＩＴ保護をサポートしない）場合は、ＳＬＰは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護が適用されることを示す表示を（ＵＬＰメッセージで）ＳＥＴに送信する。
ｉｉ．ＳＥＴが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するが、有効なＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを有さないか又はリプレイ保護に関する同期化を失っている場合は、ＳＥＴは、最初のＵＬＰメッセージでＳＵＰＬ_ＩＮＩＴ_ＲｅｓｙｎｃｈＲｅｑｕｅｓｔパラメータをＳＬＰに送信する。
１．ＳＬＰがモードＡ ＳＵＰＬ ＩＮＩＴ保護をサポートする場合は、ＳＬＰは、（ＳＥＴへの最初の応答において）第６．３．６．１．１節で規定される手順を用いて新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒで応答する。ＳＥＴがこの応答を受信したときには、これは、モードＡ ＳＵＰＬ ＩＮＩＴ保護が適用されることをＳＥＴに示す。
２．ＳＬＰがモードＡ ＳＵＰＬ ＩＮＩＴ保護をサポートしない（又はこの特定の時点でモードＡ ＳＵＰＬ ＩＮＩＴ保護をサポートすることを希望しない）場合は、ＳＬＰは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護が適用されることを示す表示を（ＵＬＰメッセージで）ＳＥＴに送信する。
これは、ＳＥＴがＨ−ＳＬＰへの新しいＴＬＳコネクションを設定するごとに保護レベルが再交渉されることを意味することに注目すること。
６．３．３．２ Ｈ−ＳＬＰの観点からの交渉
ＳＥＴとの直近のＩＰセッションがＧＢＡ又はＳＥＫ方法を用いて認証され、及びＨ−ＳＬＰがＳＥＴに関する現在のＢ−ＴＩＤ及び関連付けられた鍵を有する場合は、
◆ Ｂ−ＴＩＤがＧＢＡを用いて入手された鍵に関するものである場合は、Ｈ−ＳＬＰは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを、直近のＢ−ＴＩＤに対応し、次のように生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦとして割り当てる。
○ ＦＱＤＮは、Ｈ−ＳＬＰ_ＦＱＤＮであることができる。
○ ＳＵＰＬ_ＩＮＩＴ保護のために使用することができるＧＢＡ Ｕａセキュリティプロトコル識別子は、ＯＭＮＡレジストリで定義される。
◆ Ｂ−ＴＩＤがＳＥＫ方法を用いて導き出された鍵に関するものである場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、第６．１．２．１．２節で定義されるＳＥＫである。
◆ その他のＳＵＰＬ ＩＮＩＴ保護は交渉されていないと仮定すると、Ｈ−ＳＬＰは、そのＳＥＴのためにモードＢ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
そうでない場合は、Ｈ−ＳＬＰがＳＥＴに関する有効なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及び関連付けられた鍵を有する場合は、Ｈ−ＳＬＰは、そのＳＥＴのためにモードＡ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
その他の保護レベルが割り当てられていない場合は、Ｈ−ＳＬＰは、そのＳＥＴに関してＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
Ｈ−ＳＬＰは、現在割り当てられているレベルのＳＵＰＬ ＩＮＩＴ保護に対応する（引き渡し前にＳＵＰＬ ＩＮＩＴメッセージを処理するための）手順を適用する。これは、ＳＵＰＬ ＩＮＩＴメッセージ内のＰｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータのための該当値を割り当てることを含む。
６．３．３．３ ＳＥＴの観点からの交渉
Ｈ−ＳＬＰとの直近のＩＰセッションがＧＢＡ又はＳＥＫ方法を用いて認証され、及びＳＥＴが現在のＢ−ＴＩＤ及びそのＩＰセッションのために用いられる関連付けられた鍵を有する場合は、
◆ Ｂ−ＴＩＤがＧＢＡを用いて入手された鍵に関するものである場合は、ＳＥＴは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを、直近のＢ−ＴＩＤに対応し、次のように生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦとして割り当てる。
○ ＦＱＤＮは、Ｈ−ＳＬＰ_ＦＱＤＮであることができる。
○ ＳＵＰＬ_ＩＮＩＴ保護のために使用することができるＧＢＡ Ｕａセキュリティプロトコル識別子は、ＯＭＮＡレジストリで定義される。
◆ Ｂ−ＴＩＤがＳＥＫ方法を用いて導き出された鍵に関するものである場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、第６．１．２．１．２節で定義されるＳＥＫである。
◆ その他のＳＵＰＬ ＩＮＩＴ保護は交渉されていないと仮定すると、ＳＥＴは、モードＢ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
そうでない場合は、ＳＥＴがＨ−ＳＬＰに関する有効なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、関連付けられた鍵及びＭｏｄｅＡＲｅｐｌａｙＣｏｕｎｔｅｒを有する場合は、Ｈ−ＳＬＰは、ＳＥＴは、そのＳＥＴのためにモードＡ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
その他の保護レベルが割り当てられていない場合は、ＳＥＴは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
ＳＥＴは、現在割り当てられているレベルのＳＵＰＬ ＩＮＩＴ保護に対応する（受信されたＳＵＰＬ ＩＮＩＴメッセージを処理するための）手順を適用する。
６．３．３．４ 例外手順
ＳＥＴ内部のＳＵＰＬ ＩＮＩＴ保護パラメータが壊れているとＳＥＴが決定した場合は、ＳＥＴは、Ｈ−ＳＬＰとのＴＬＳセッションを確立しなければならない。
・ ＧＢＡ認証が使用される場合は、ＳＥＴは、新しい鍵を確立するためのＧＢＡブートストラッピングを開始しなければならない。
・ ＳＥＫ方法を使用するＳＥＴに関しては、ＳＥＴは、新しい鍵をイネーブルにするためＳＥＫブートストラッピングを開始しなければならない。
・ そうでない場合は、ＳＥＴは、最初のセキュリティが確保されたＵＬＰメッセージでＳＵＰＬ_ＩＮＩＴ_ＫｅｙＲｅｑｕｅｓｔを送信し、
第６．３．３．１節のステップ３．のｂの手順に従う。
第６．３．３．１節のステップ３．のｂの手順に従う。
ＳＬＰがセキュリティコンテキストを失った場合は（例えば、大量のデータ損失）、ＳＬＰは、測位活動を開始する手段を有さないことになる。コンテキストは、Ｋｓ_ＮＡＦ又はＳＥＫが期限切れになるか又はＳＥＴがＳＬＰに接続するときに再確立される。この“ブロックアウトウィンドウ”（ｂｌｏｃｋ ｏｕｔ ｗｉｎｄｏｗ）を防止するために、ＳＬＰは、該シナリオから回復するためにすべてのＳＵＰＬ ＩＮＩＴセキュリティコンテキスト情報が十分な冗長度を持って格納されるようにすべきである。
６．３．４ Ｎｕｌｌレベルの保護が割り当てられるときの仕様
注：Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護のためのＳＵＰＬ ＩＮＩＴプロテクタは存在しない。
６．３．４．１ Ｈ−ＳＬＰ手順
Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護の専用であるＳＬＰのためのセキュリティ手順は存在しない。
６．３．４．２ ＳＥＴ手順
Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護が割り当てられ、ＳＥＴがＳＵＰＬ ＩＮＩＴメッセージを受信したときには、ＳＥＴは、次の手順を適用する：
◆ Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータが正しい場合は、ＳＥＴは、メッセージを真正であるとみなし、セキュリティに関連する処理は要求されない。
○ ＳＬＰ及びＳＥＴがより高い保護レベルをサポートすることができるが、パワーアップ中であるためＳＥＴがＳＬＰにまだ接触していないと仮定すると、この場合は、ＳＥＴは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護が割り当てられる。ＳＥＴがＳＬＰに接触するまでの期間において、ＳＥＴは、（正しいＰｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータを有する）あらゆる受信されたＳＵＰＬ ＩＮＩＴメッセージを真正であるとみなす。（受信されたＳＵＰＬ ＩＮＩＴメッセージに応答してであるかどうかにかかわらず）ＳＥＴがＳＬＰに初めて接触した時点で、ＳＥＴ及びＳＬＰは、より高い保護レベルに移行する。これらの２つのエンティティがより高い保護レベルに移行した時点で、ＳＥＴは、真正でないＳＵＰＬ ＩＮＩＴメッセージを検出することができる。ＳＥＴがパワーアップされるときとＳＥＴがＳＬＰに最初に接触するときとの間には、ＳＥＴが、あたかもＳＵＰＬ ＩＮＩＴメッセージが真正であるものとしてＳＥＴによって処理される非真正のＳＵＰＬ ＩＮＩＴメッセージを受信することが可能である。ＳＥＴが非認証ＳＵＰＬ ＩＮＩＴメッセージと関連付けられたＳＵＰＬセッションを進行させることを決定した場合は、ＳＥＴは、ＳＬＰに接触してセキュアなＴＬＳセッションを確立する。ＳＵＰＬセッションは非真正のＳＵＰＬ ＩＮＩＴメッセージを用いて確立されたため、ＳＬＰはそれを許容しない。ＳＥＴ及びＳＬＰがより高い保護レベルをサポートする場合は、これは同時に確立され、ＳＥＴは、この時間後に非真正のＳＵＰＬメッセージを検出することができる。このことは、ＳＥＴ及びＳＬＰがより高い保護レベルをサポートすることができる場合は、攻撃者が非真正のＳＵＰＬ ＩＮＩＴメッセージをＳＥＴに入手させる非常に小さい機会の窓が存在しており、ＳＥＴは、多くとも１つの非真正のＳＵＰＬ ＩＮＩＴメッセージに関してＳＵＰＬセッションを進行させることを試みるにすぎないことを意味する。
◆ Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータが正しくない場合（すなわち、Ｐｒｏｔｅｃｔｉｏｎ ＬｅｖｅｌパラメータがＮｕｌｌ以外の何かであった場合）は、ＳＥＴは、該当する誤りメッセージをＳＬＰに送信する。
○ ＳＬＰ及びＳＥＴでの保護レベルが同期化を失った場合は、この手順は、ＳＥＴ及びＳＬＰが共通の保護レベルで再同期化するのを可能にする。
６．３．５ モードＡ ＳＵＰＬ ＩＮＩＴ保護レベルに関する仕様
６．３．５．１ モードＡ ＳＵＰＬ ＩＮＩＴ保護のための鍵識別子
モードＡ ＳＵＰＬ ＩＮＩＴ保護は、ＳＵＰＬ ＩＮＩＴメッセージとともに送信することができる２つの鍵識別子、すなわち、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及びＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、を使用する。
・ ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹと関連付けられたグローバルで一意の、長期的な鍵識別子である。ＳＬＰは、ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのための新しい値をプロビジョニングするときのみに新しいＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒをＳＥＴに提供する。
・ ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けられた短期のアイデンティティ（仮名）である。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒが有効である期間の間グローバルで一意であることができる。ＳＥＴ及びＳＬＰは、第６．３．５．３節及び第６．３．５．４節において説明されるようにＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの値を同期化する。
ＳＬＰは、典型的には、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを基本的ＳＵＰＬ ＩＮＩＴプロテクタ内のＫｅｙＩｄｅｎｔｉｆｉｅｒとして使用する。ＳＥＴは、基本的ＳＵＰＬ ＩＮＩＴプロテクタを検証するためにいずれのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが使用されるべきかを決定するためにＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを使用する。
ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、典型的には、ＳＵＰＬ ＩＮＩＴメッセージでは送信されず、その理由は、観察者が複数のＳＵＰＬ ＩＮＩＴメッセージを１つの共通のＳＥＴユーザと関連付けるのを可能にするためである。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの目的は、脅威エージェントが複数のＳＵＰＬ ＩＮＩＴメッセージを１人のＳＥＴユーザと関連付けるためにＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを使用するのを防止することである。ＳＬＰ及びＳＥＴのみがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒをＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けることができるようにすべきである。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを変更する頻度は、主に、ＳＥＴユーザの判断である。ＳＬＰは、ＳＬＰ方針に基づいてＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのための新しい値を確立することを選択することができる。
しかしながら、ＳＬＰがより長期のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを基本的ＳＵＰＬ ＩＮＩＴプロテクタ内のＫｅｙＩｄｅｎｔｉｆｉｅｒとして使用することを希望する状況が存在する。例えば、ＳＥＴが基本的ＳＵＰＬ ＩＮＩＴプロテクタ内のＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを用いて複数のＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージに応答していないと仮定する。ＳＬＰは、ＳＥＴがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒに関する同期化を失っていることを懸念するおそれがある。ＳＥＴ及びＳＬＰは、長期的なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒに関しての方が同期化状態を維持する可能性が高い。従って、ＳＬＰは、同期化を失うことがＳＥＴがＳＵＰＬ ＩＮＩＴメッセージを検証するのを妨げないようにするために基本的ＳＵＰＬ ＩＮＩＴプロテクタ内のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを用いてＳＵＰＬ ＩＮＩＴメッセージを送信することができる。
６．３．５．２ モードＡ ＳＵＰＬ ＩＮＩＴ保護及び基本的ＳＵＰＬ ＩＮＩＴプロテクタ
モードＡ ＳＵＰＬ ＩＮＩＴ保護は、基本的ＳＵＰＬ ＩＮＩＴプロテクタ及び第６．３．７節において定義される関連付けられた手順を使用し、さらなる明確化のために以下を示した。
◆ ＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅ：ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ又はＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのいずれかが使用されることを示す。
◆ ＫｅｙＩｄｅｎｔｉｆｉｅｒ：ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅに適宜対応するＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ又はＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのいずれかに対応する。
◆ ＢａｓｉｃＭＡＣは、上記のＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けられたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いて、ＳＵＰＬ_ＩＮＩＴ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｍｏｄｅ Ａ ＩＫ”）を用いて計算される。
６．３．５．３ Ｈ−ＳＬＰ手順
モードＡ専用Ｈ−ＳＬＰ手順は、ＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
ＳＬＰが（セキュリティが確保されたセッションにおけるＳＥＴへの最初の応答メッセージで）ＮｅｗＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒパラメータを送信し、新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを後続させることによってＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのための新しい値が確立される。新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを確立することは、その結果として、ＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒが０ｘ００００にリセットされ、ＳＥＴが“プレイされた”ＳＵＰＬ ＩＮＩＴメッセージに関する全情報を取り除く。
ＳＬＰは、ＳＵＰＬ_ＩＮＩＴ_ＲｅｓｙｎｃｈＲｅｑｕｅｓｔ又はＳＬＰの（範囲外の）内部判断のいずれかに応答して新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを確立することができる。すなわち、ＳＬＰは、ＳＥＴからの対応するＳＵＰＬ_ＩＮＩＴ_ＲｅｓｙｎｃｈＲｅｑｕｅｓｔが存在しないときでもＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを送信することができる。
６．３．５．４ ＳＥＴ手順
モードＡ専用Ｈ−ＳＬＰ手順は、ＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
ＳＥＴは、ＵＬＰセッションの最初のメッセージでＳＵＰＬ_ＩＮＩＴ_ＲｅｓｙｎｃｈＲｅｑｕｅｓｔを送信することによってＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのための新しい値を確立することをトリガすることができる。
モードＡ ＳＵＰＬ ＩＮＩＴ保護がＳＥＴによって割り当てられた場合は、ＳＥＴが所定のＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを有するＳＵＰＬ ＩＮＩＴメッセージを初めて処理する前に、ＳＥＴは、ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒのためにそれの使用された値のキャッシュをクリアする。
６．３．６ モードＢ ＳＵＰＬ ＩＮＩＴ保護レベルに関する仕様
モードＢ ＳＵＰＬ ＩＮＩＴ保護は、基本的ＳＵＰＬ ＩＮＩＴプロテクタ及び第０節において定義される関連付けられた手順を使用し、さらなる明確化のために以下を示した。
◆ ＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅ：Ｂ−ＴＩＤ識別子のみがモードＢ ＳＵＰＬ ＩＮＩＴ保護のためのサポートである。
◆ ＫｅｙＩｄｅｎｔｉｆｉｅｒ：現在のＢ−ＴＩＤに対応する。
◆ ＢａｓｉｃＭＡＣパラメータは、ＳＵＰＬ_ＩＮＩＴ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｍｏｄｅ Ａ ＩＫ”）を用いて計算され、ここで、
○ ＧＢＡに基づく配備の場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、直近のＢ−ＴＩＤに対応し、ＯＭＮＡレジストリで定義されるＳＵＰＬ ＩＮＩＴ保護のためのＧＢＡ Ｕａセキュリティプロトコル識別子を用いて生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦである。
○ ＧＢＡに基づく配備の場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、直近のＢ−ＴＩＤに対応し、ＯＭＮＡレジストリで定義されるＳＵＰＬ ＩＮＩＴ保護のためのＧＢＡ Ｕａセキュリティプロトコル識別子を用いて生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦである。
○ ＳＥＫに基づく配備の場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、第６．１．２．１．２節で定義されるＳＥＫ_ＭＡＣである。
６．３．６．１ Ｈ−ＳＬＰ手順
モードＢ専用Ｈ−ＳＬＰ手順は、ＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
モードＢ ＳＵＰＬ ＩＮＩＴ保護に関して、鍵が初めて使用されるときにＳＬＰ内のＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒがゼロにリセットされ、ＳＥＴが“プレイされた”ＳＵＰＬ ＩＮＩＴメッセージに関する全情報を取り除く。
再同期化が要求されるとＳＬＰが決定する起こりえない事象において、
・ ＧＢＡ方法をサポートする配備の場合は、ＳＬＰは、ＧＢＡ Ｂ−ＴＩＳを無効にすることによって再同期化をトリガする。そのＳＥＴが次にＳＬＰに対して認証することを試みたときに、ＳＬＰは、ＴＬＳ−ＰＳＫ ａｌｅｒｔ“ｐｓｋ_ｉｄｅｎｔｉｔｙ_ｕｎｋｎｏｗｎ”で応答する。これは、新しいＧＢＡ鍵を確立することをプロンプトする。
・ ＳＥＫ方法をサポートする配備の場合は、ＳＬＰは、ＳＥＫ Ｂ−ＴＩＳを無効にすることによって再同期化をトリガする。そのＳＥＴが次にＳＬＰに対して認証することを試みたときに、ＳＬＰは、ＴＬＳ−ＰＳＫ ａｌｅｒｔ“ｐｓｋ_ｉｄｅｎｔｉｔｙ_ｕｎｋｎｏｗｎ”で応答する。これは、第６．１．３．３節で説明されるように新しいＳＥＫを確立することをプロンプトする。
６．３．６．２ ＳＥＴ手順
モードＢ専用ＳＥＴ手順は、ＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
モードＢ ＳＵＰＬ ＩＮＩＴ保護がＳＥＴによって割り当てられた場合は、
・ ＳＥＴが所定のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するＳＵＰＬ ＩＮＩＴメッセージを初めて処理する前に、ＳＥＴは、ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒのためにそれの使用された値のキャッシュをクリアする。
・ ＳＥＴは、新しいＧＢＡ Ｋｓ又は新しいＳＥＫを適宜確立することによって再同期化をトリガすることができる。ＳＬＰは、ＳＥＴとＳＬＰとの間での次の成功裏の認証まで旧ＧＢＡ Ｋｓ（又はＳＥＫ）を使用し続ける。このため、ＳＥＴは、その時まで旧ＧＢＡ Ｋｓ（又はＳＥＫ）を維持すべきである。
６．３．７ 基本的ＳＵＰＬ ＩＮＩＴプロテクタを使用するための仕様
基本的ＳＵＰＬ ＩＮＩＴプロテクタは、モードＡ ＳＵＰＬ ＩＮＩＴ保護及びモードＢ ＳＵＰＬ ＩＮＩＴ保護の両方のために使用され、次のパラメータを含む：
◆ ＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅ：長さ＝１オクテット
◆ ＫｅｙＩｄｅｎｔｉｆｉｅｒ：可変長。ＢａｓｉｃＭＡＣを計算するために用いられる鍵に対応する。
◆ ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ：長さ＝２オクテット
◆ ＢａｓｉｃＭＡＣ：長さ＝４オクテット
ＢａｓｉｃＭＡＣパラメータは、次のように生成される：
◆ ＢａｓｉｃＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ’）、ここで、
◆ ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫは、モードＡ ＳＵＰＬ ＩＮＩＴ保護及びモードＢ ＳＵＰＬ ＩＮＩＴ保護に関するそれぞれの第６．３．５節及び第６．３．６節により導き出される。
◆ ＢａｓｉｃＭＡＣ：長さ＝４オクテット
ＢａｓｉｃＭＡＣパラメータは、次のように生成される：
◆ ＢａｓｉｃＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ’）、ここで、
◆ ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫは、モードＡ ＳＵＰＬ ＩＮＩＴ保護及びモードＢ ＳＵＰＬ ＩＮＩＴ保護に関するそれぞれの第６．３．５節及び第６．３．６節により導き出される。
◆ ＳＵＰＬ_ＩＮＩＴ’は、ＳＵＰＬ ＩＮＩＴメッセージに対応し、ＢａｓｉｃＭＡＣ以外の全パラメータが割り当てられ、ＭＡＣパラメータはすべてゼロに設定される。
◆ ＨＭＡＣ−ＳＨＡ２５６−３２及びＨＭＡＣ−ＳＨＡ２５６−１２８は、本書の範囲外の文書において規定されている。
６．３．７．１ Ｈ−ＳＬＰ手順
ＭｏｄｅＡＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒの同期化のためのＳＬＰ手順が別の場所でモードＡ及びモードＢ ＳＵＰＬ ＩＮＩＴ保護に関して規定される。
モードＡ又はモードＢ ＳＵＰＬ ＩＮＩＴ保護がＳＥＴに割り当てられた場合は、Ｈ−ＳＬＰは、ＳＵＰＬ ＩＮＩメッセージを次のように構成する：
１．ＳＵＰＬ ＩＮＩＴプロテクタ外部のパラメータが別の場所で説明されるように割り当てられる。
２．ＫｅｙＩｄｅｎｔｉｔｙＴｙｐｅが、ＳＬＰがこのメッセージのために使用するＫｅｙＩｄｅｎｔｉｔｙのタイプにより設定される。
３．ＫｅｙＩｄｅｎｔｉｔｙが、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹと関連付けられたＫｅｙＩｄｅｎｔｉｔｙに設定される。
４．Ｈ−ＳＬＰが、（このＳＥＴ及び交渉されたＳＵＰＬ ＩＮＩＴ保護レベルと関連付けられた）ＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒＶａｌｕｅの現在値を１だけ増加させ、その新しい値をＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒパラメータ内に挿入する。
５．最後に、すべてのその他のパラメータが割り当てられた後に、ＢａｓｉｃＭＡＣが上記のようにＳＵＰＬ ＩＮＩＴ及びＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹから計算される。
Ｈ−ＳＬＰには、モードＡ又はモードＢ ＳＵＰＬ ＩＮＩＴ保護レベルが割り当てられる各ＳＥＴのためのＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒパラメータの長さに等しい長さのＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒＶａｌｕｅを格納するように要求することができる。
ＳＬＰ内のＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒＶａｌｕｅが６５５３５＝２１６−１に近い場合は（可能性が非常に小さい）、ＳＬＰは、再同期化手順をトリガしなければならない（第６．３．６．１節及び第６．３．７．１節を参照）。
６．３．７．２ ＳＥＴ手順
ＭｏｄｅＡＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒの同期化のためのＳＥＴ手順が別の場所でモードＡ及びモードＢ ＳＵＰＬ ＩＮＩＴ保護に関して規定される。
モードＡ又はモードＢ ＳＵＰＬ ＩＮＩＴ保護が割り当てられた場合は、ＳＥＴは、受信されたＳＵＰＬ ＩＮＩＴメッセージを次のように処理する：
１．次のパラメータが該当する検証に失敗した場合はＳＥＴがＳＵＰＬ ＩＮＩＴメッセージを廃棄する：
◆ Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌ：交渉されたＳＵＰＬ ＩＮＩＴ保護レベルのための割り当てられた値でなければならない。
◆ ＫｅｙＩｄｅｎｔｉｔｙＴｙｐｅ：割り当てられたＳＵＰＬ ＩＮＩＴ保護レベルに関して有効でなければならない。
◆ ＫｅｙＩｄｅｎｔｉｔｙ：交渉されたＳＵＰＬ ＩＮＩＴ保護レベルに関する現在のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹに対応しなければならない。
◆ ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ：ＳＥＴは、メッセージのリプレイを検出するためにこの値を使用する。この技法は、各々の実装ごとであるが、ＳＵＰＬ ＩＮＩＴメッセージが失われるか又はばらばらに引き渡される状況に対処することができるような強固さでなければならない。
◆ ＢａｓｉｃＭＡＣ：（上述されるように）ＳＥＴがＳＵＰＬ ＩＮＩＴ及びＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹから予想されるＢａｓｉｃＭＡＣを計算し、これを受信されたＢａｓｉｃＭＡＣと比較する：これらの値は等しくなければならない。
２．前ステップにおいてＳＵＰＬ ＩＮＩＴが廃棄されなかった場合は、それは真正であるとみなされ、ＳＥＴは、使用されるべきＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒＶａｌｕｅを考慮する。ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒＶａｌｕｅが６５５３５＝２１６−１に近い場合は（可能性が非常に小さい）、ＳＥＴは、カウンタをリセットするためにＳＬＰと新しいＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを確立しなければならない。
６．４ Ｈ−ＳＬＰアドレスをＳＥＴに提供する
注：アクセスネットワークから独立したＨ−ＳＬＰのためにＨ−ＳＬＰアドレスをプロビジョニングすることは、ＦＦＳである。
Ｈ−ＳＬＰアドレスは、ＵＩＣＣ、ＳＥＴ内でＨ−ＳＬＰアドレスをプロビジョニングすることによってＳＥＴにとって入手可能になり、又は、デフォルトＨ−ＳＬＰが下記のように導き出される。このアドレスは、ＦＱＤＮの形態でなければならず及びＳＥＴのホームネットワークによってセキュアな状態でプロビジョニングされるべきである。
６．４．１．３ ３ＧＰＰ２ ＳＥＴ
３ＧＰＰ２ ＳＥＴに関しては、Ｈ−ＳＬＰアドレスは、ＵＭＩ又はＲ−ＵＩＭにおいてセキュアな状態でプロビジョニングされなければならない。
６．４．２．３ ３ＧＰＰ ＳＥＴ
３ＧＰＰ ＳＥＴは、（ＦＱＤＮの形態の）Ｈ−ＳＬＰアドレスを、ＷＡＰ ＰＲＯＶＣＯＮＴにおいて規定される“ＡＰＰＡＤＤＲ／ＡＤＤＲ”特性に基づくパラメータ“ＡＤＤＲ”として読み取らなければならない。さらに、Ｈ−ＳＬＰアドレスは、３ＧＰＰ準拠ＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）に関するＯＭＡスマートカードプロビジョニング仕様において定義されるブートストラップファイル内に又はＳＥＴの同等にセキュアなエリア内にセキュアな状態で格納しなければならない。ＳＥＴは、Ｈ−ＳＬＰアドレスを読み取るためのＯＭＡスマートカードプロビジョニングメカニズムをサポートしなければならない。Ｈ−ＳＬＰアドレスを格納するＵＳＩＭ／ＳＩＭアプリケーション又はＳＥＴ内のブートストラップファイルは、ユーザによって変更可能であってはならない。Ｈ−ＳＬＰがＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）において設定されている場合は、ＳＥＴは、最初に、ＵＩＣＣにおいてプロビジョニングされるＨ−ＳＬＰアドレスを読み取らなければならない。ＵＩＣＣにおいてプロビジョニングされるＨ−ＳＬＰアドレスが存在しない場合は、ＳＥＴは、ＳＥＴのセキュアなエリアからＨ−ＳＬＰアドレスを読み取ることができる。
ＳＥＴ内でのＨ−ＳＬＰアドレスのプロビジョニング：Ｈ−ＳＬＰアドレスがＳＥＴ内のセキュアな場所に格納されることになる場合は、それは、ＯＭＡデバイス管理Ｖ１．２又はそれ以降を用いてプロビジョニングしなければならない。ＯＭＡ ＤＭを用いてＨ−ＳＬＰアドレスがプロビジョニングされる場合は、ＳＥＴは、ＴＬＳハンドシェイク中にＤＭサーバによって提示されたサーバ側証明書に基づいてＯＭＡ ＤＭサーバを認証しなければならない。ＳＥＴがＨ−ＳＬＰの格納をサポートする場合は、それは、第６．１．４節で説明される認証方式、すなわち、ＭＳＩＳＤＮ／ＩＰアドレスマッピング認証に基づく代替クライアント認証、に依存してはならず、ＳＥＴは、第６．１．１節で説明されるＰＳＬ−ＴＬＳ相互認証方法に依存しなければならない。
Ｈ−ＳＬＰアドレスの自動設定：Ｈ−ＳＬＰアドレスがＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）のセキュアな格納エリア内又はＳＥＴのセキュアなエリア内で見つけることができない場合は、ＳＥＴは、ＵＳＩＭ／ＳＩＭ内に格納されたＩＭＳＩに基づいてＳＥＴ内でデフォルトＨ−ＳＬＰアドレスを設定しなければならない。
Ｈ−ＳＬＰアドレスがＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）のセキュアな格納エリア内又はＳＥＴのセキュアなエリア内で見つけられているが、それを使用した結果、ＳＵＰＬセッション中に認証失敗に終わった場合は、ＳＥＴは、ＵＳＩＭ／ＳＩＭ内に格納されたＩＭＳＩに基づいてＳＥＴ内でデフォルトＨ−ＳＬＰアドレスを設定しなければならない。
デフォルトＨ−ＳＬＰアドレスを設定するためのメカニズムが以下に定義される。
以下の例は、３ＧＰＰ ＧＢＡ仕様から流用したものであり、（ＦＱＤＮに基づく）Ｈ−ＳＬＰアドレスが設定されるＳＵＰＬ使用事例のために採用されていることに注目すること。このデフォルト設定メカニズムの実装は、３ＧＰＰ ＧＢＡ仕様の実装を要求しない。以下の例は、方法を例示することを目的として示されるにすぎず、ＧＢＡから独立して実装することができる。
ＩＭＳＩに基づくＨ−ＳＬＰの構成
ステップ１）２又は３桁のＭＮＣが使用されるかどうかに依存してＩＭＳＩの最初の５又は６桁を取りそれらをＭＣＣ及びＭＮＣに分離する。ＭＮＣが２桁である場合は、始めにゼロを加えることができる。
ステップ２）ステップ１で導き出されたＭＣＣ及びＭＮＣを用いて“ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．ｐｕｂ．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ”ドメイン名を生成し、ドメイン名の最初にラベル“ｈ−ｓｌｐ．”を加える。
例１：使用中のＩＭＳＩが“２３４１５０９９９９９９９９９”である場合は、ここで、ＭＣＣ＝２３４，ＭＮＣ＝１５、ＭＳＩＮ＝０９９９９９９９９９であり、Ｈ−ＳＬＰアドレスは、“ｈ−ｓｌｐ．ｍｎｃ０１５．ｍｃｃ２３４．ｐｕｂ．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ”になる。
新しいＩＭＳＩが電源投入中又は投入後にＳＥＴによって検出された場合は、すべての以前のＨ−ＳＬＰ設定をＳＥＴから取り除かなければならない。より具体的には、ＳＥＴ内に格納されるあらゆるＨ−ＳＬＰを取り除かなければならない。
ＩＭＳＩが変更された場合は、ＳＥＴは、最初に、ＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）からＨ−ＳＬＰアドレスを読み取らなければならない。Ｈ−ＳＬＰアドレスがＵＩＣＣ（ＵＳＩＭ／ＳＩＭ）に格納されていない場合は、ＳＥＴは、Ｈ−ＳＬＰアドレスがＳＥＴ内に格納されているかどうかを検査することができる。Ｈ−ＳＬＰアドレスがＵＩＣＣでもＳＥＴ内でも見つからない場合は、上述されるように新しいＩＭＳＩに基づいてＳＥＴによってデフォルトのＨ−ＳＬＰアドレスを設定しなければならない。
実装では、ＳＥＴのメーカーソフトウェアインストール後にＳＥＴにダウロードされるアプリケーションを介してＨ−ＳＬＰのアドレスを変更できないようにしなければならない。
次の流れは、Ｈ−ＳＬＰアドレス格納を例示する。
１．開始する。２に行く。
２．ＩＭＳＩは変更されたか。はいの場合は３に行く。いいえの場合は３を飛ばし、直接４に行く。
３．ＳＥＴからＨ−ＳＬＰをクリアする。４に行く。
４．ＵＩＣＣにはＨ−ＳＬＰアドレスが入っているか。いいえの場合は５に行く。はいの場合は９に行く。
５．ＳＥＴのＨ−ＳＬＰアドレスはサポートされるか。いいえの場合は７に行く。はいの場合は６に行く。
６．Ｈ−ＳＬＰアドレスがＳＥＴ内でプロビジョニングされているか。いいえの場合は７に行く。はいの場合は８に行く。
７．ＩＭＳＩからＨ−ＳＬＰアドレスを生成する。１０に行く。
８．ＳＥＴから設定を読み取る。１０に行く。
９．ＵＩＣＣからＨ−ＳＬＰアドレスを読み取る。１０に行く。
１０．Ｈ−ＳＬＰアドレスを用いてＨ−ＳＬＰへのＴＬＳコネクションを生成する。１１に行く。
１１．認証は成功か。いいえの場合は１２に行く。はいの場合は１４に行く。
１２．Ｈ−ＳＬＰアドレスはＩＭＳＩから生成されたか。いいえの場合は７に行く。はいの場合は１３に行く。
１３．ＳＵＰＬセッションを打ち切り、終了する。
１４．ＳＵＰＬセッションを実行し、終了する。
６．４．３ ＷＩＭＡＸに基づく配備
ＳＥＴがＷｉＭＡＸネットワークに添付するときには、それは、ＯＭＡ ＤＭを介して更新されたＨ−ＳＬＰアドレスを受信することができる。Ｈ−ＳＬＰアドレスがＷｉＭＡＸ端末にセキュアな形でプロビジョニングされるときには、それは、保護された環境で格納しなければならない。
６．５ 秘密性及びデータ完全性プロトコル
ＴＬＳ１．１又はＰＳＫ−ＴＬＳは、ＳＥＴとＳＬＰとの間の秘密性及びデータ完全性を提供するために使用することができる。ＳＥＴとＳＬＰとの間のＴＬＳ又はＰＳＫ−ＴＬＳセッション内で“ＳＵＰＬ ＩＮＩＴ”以外のすべてのＳＵＰＬメッセージが引き渡されなければならない。
第６．１．１．３節は、ＳＵＰＬ３．０配備におけるいずれのエンティティがサーバ証明書認証によるＴＬＳ及び／又はＴＬＳ−ＰＳＫを強制的又は任意選択的であるかを決定するための詳細を提供する。
６．５．１ サーバ証明書を用いるＴＬＳ
サーバ証明書を用いるＴＬＳ１．１の実装は、ＴＬＳ１．１のＷＡＰプロフィールに準拠することができ、明確化のために以下を示した：
ＳＥＴは、以下を実装することができる：
・ ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ．
追加の暗号スイートを選ぶＳＥＴ実装に関しては、ＳＥＴは、以下を実装すべきである：
・ ＴＬＳ_ＲＳＡ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
サーバ証明書を用いるＴＬＳ１．１をサポートするＳＬＰは、以下の暗号スイートを実装することができる。
・ ＴＬＳ_ＲＳＡ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
・ ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ.
ＮＵＬＬ暗号化をサポートすることを選ぶサーバ証明書を用いるＴＬＳ１．１をサポートするＳＬＰ実装に関しては、ＳＬＰは、ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＮＵＬＬ_ＳＨＡを実装することができる。ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＮＵＬＬ_ＳＨＡの使用は、秘密性の保護を提供しないため推奨されない。しかしながら、それは、認証及び完全性保護を依然として提供する。
・ ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ.
ＮＵＬＬ暗号化をサポートすることを選ぶサーバ証明書を用いるＴＬＳ１．１をサポートするＳＬＰ実装に関しては、ＳＬＰは、ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＮＵＬＬ_ＳＨＡを実装することができる。ＴＬＳ_ＲＳＡ_ＷＩＴＨ_ＮＵＬＬ_ＳＨＡの使用は、秘密性の保護を提供しないため推奨されない。しかしながら、それは、認証及び完全性保護を依然として提供する。
ＴＬＳ１．１のＷＡＰ証明書プロフィールは、サーバ証明書を用いるＴＬＳ１．１をサポートするＳＬＰ及びＳＥＴによってサポートすることができる。
６．５．２ ＴＬＳ−ＰＳＫ
ＴＬＳ−ＰＳＫの実装は、ＴＬＳハンドシェイクに関するＰＳＫ−ＴＬＳに準拠することができ、バルク暗号化（Ｂｕｌｋ Ｃｉｐｈｅｒｉｎｇ）は、ＴＬＳ１．１に関して定義されているとおりである。
ＴＬＳ−ＰＳＫをサポートするＳＥＴは、以下を実装することができる。
・ ＴＬＳ_ＰＳＫ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ.
追加の暗号スイートを選ぶＴＬＳ−ＰＳＫをサポートするＳＥＴ実装に関しては、ＳＥＴは、以下を実装すべきである：
・ ＴＬＳ_ＰＳＫ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
以下の暗号スイートをＳＬＰによって実装することができる。
追加の暗号スイートを選ぶＴＬＳ−ＰＳＫをサポートするＳＥＴ実装に関しては、ＳＥＴは、以下を実装すべきである：
・ ＴＬＳ_ＰＳＫ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
以下の暗号スイートをＳＬＰによって実装することができる。
・ ＴＬＳ_ＰＳＫ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ.
追加の暗号スイートを選ぶＴＬＳ−ＰＳＫをサポートするＳＬＰ実装に関しては、ＳＬＰは、以下を実装すべきである：
・ ＴＬＳ_ＰＳＫ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
非プロキシモードをサポートするＳＰＣによって以下の暗号スイートを実装することができる。
追加の暗号スイートを選ぶＴＬＳ−ＰＳＫをサポートするＳＬＰ実装に関しては、ＳＬＰは、以下を実装すべきである：
・ ＴＬＳ_ＰＳＫ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
非プロキシモードをサポートするＳＰＣによって以下の暗号スイートを実装することができる。
・ ＴＬＳ_ＰＳＫ_ＷＩＴＨ_ＡＥＳ_１２８_ＣＢＣ_ＳＨＡ.
追加の暗号スイートを選ぶ非プロキシモードをサポートするＳＰＣ実装に関しては、ＳＰＣは、以下を実装すべきである。
追加の暗号スイートを選ぶ非プロキシモードをサポートするＳＰＣ実装に関しては、ＳＰＣは、以下を実装すべきである。
・ ＴＬＳ_ＰＳＫ_ＷＩＴＨ_３ＤＥＳ_ＥＤＥ_ＣＢＣ_ＳＨＡ.
６．６ ＤＣｅｒｔ方法及びユーザバインディング
ＤＣｅｒｔ方法は、ＳＥＴハンドセットを認証するが、（ＧＢＡ方法、ＳＥＫ方法及びＡＣＡ方法と異なり）アクセスネットワーククレデンシャルに結合された認証は実施しない。
６．６ ＤＣｅｒｔ方法及びユーザバインディング
ＤＣｅｒｔ方法は、ＳＥＴハンドセットを認証するが、（ＧＢＡ方法、ＳＥＫ方法及びＡＣＡ方法と異なり）アクセスネットワーククレデンシャルに結合された認証は実施しない。
ＳＬＰが相互認証のためにＤＣｅｒｔ方法を使用する場合は、ＳＬＰオペレータは、いずれのＳＵＰＬユーザがＳＥＴと関連付けられるべきかを検証するための何らかのその他のメカニズムが必要である。用語“ユーザバインディング”は、ＳＵＰＬユーザをＳＥＴアイデンティティと関連付けことについて説明するために使用される。
ＳＥＴの所有権が変わった場合は、既存のＳＵＰＬユーザは、ＳＬＰオペレータに連絡してユーザバインディングを解除させる責任を有する。
ＳＵＰＬ３．０は、ユーザバインディング手順を規定しないが、１つの可能な手順が第６．６．１節に示される。幾つかのＳＬＰは、ＳＬＰオペレータによって提供されるその他のサービスの一部としてユーザバインディング手順を組み入れることができる。その他の場合は、ユーザバインディングは、配布チェーンの一部であることができる。
ＳＬＰオペレータは、選択するあらゆる“ユーザバインディング”手順を使用することができるが、次の点に留意すべきである。
・ ＳＵＰＬユーザをユーザバインディング手順の一部として認証されなければならない。
○ ＳＵＰＬユーザの認証失敗は、サービスの窃盗を許容することになり、さらに、脅威エージェントが識別されたＳＵＰＬユーザの位置に関してＳＬＰに誤解させるのを許容することになる。
○ ＳＬＰオペレータは、ユーザ認証に関して自己の既存のメカニズム及び方針を適用することを推奨する。
・ ＳＥＴをユーザバインディング手順の一部として認証されなければならない。
○ これに関する理由は微妙である。脅威エージェントがアリスの動きを追跡することを希望し、アリスがＳＥＴアイデンティティ“ＳＥＴ_ＩＤ_Ａ”を有するＳＥＴを所有すると仮定する。脅威エージェントは、合法的なＳＵＰＬユーザとして登録し、彼女自身を認証後に、ＳＥＴアイデンティティ“ＳＥＴ_ＩＤ_Ａ”を有するＳＥＴを所有すると主張する。ＳＬＰオペレータがこのＳＥＴを脅威エージェントのアカウントと関連付けた場合は、脅威エージェントは、（ネットワークによって開始されるセッションを介して）ＳＬＰから定期的な位置更新を入手するための権限を自分自身に付与することができる。しかしながら、アリスがＳＥＴを使用中であるため、脅威エージェントは、実際にはアリスの位置の更新を入手している。ＳＬＰオペレータは、アリスの位置の秘密性を保持することが期待されるため、該攻撃を防止することがＳＬＰオペレータの関心事である。
６．６．１ ユーザバインディング手順例
ＤＣｅｒｔ方法は、主に、ウェブブラウジング能力を有するＳＥＴを対象にして設計されており、例は、スマートフォン、タブレット又はタッチ画面式マルチメディアプレイヤーを含む。
該ＳＥＴは、次の仕組みを使用することができる。
１．ＳＬＰオペレータが、ＳＥＴを使用中にＳＬＰによって所有されるウェブサーバのＵＲＬに接続するようにＳＵＰＬユーザをプロンプトする。
２．加入者が、ＳＥＴを使用中にウェブサイト（おそらくＷＡＰ）に接続する。
３．ウェブサーバ及びＳＥＴがＴＬＳを実施する
ａ．ウェブサーバがサーバ証明書を提供し、クライアント証明書を要求する。ウェブサーバの証明書は、ＳＵＰＬサービスのために使用されるＳＬＰサービス証明書のための証明書とは別個であることができる。
ａ．ウェブサーバがサーバ証明書を提供し、クライアント証明書を要求する。ウェブサーバの証明書は、ＳＵＰＬサービスのために使用されるＳＬＰサービス証明書のための証明書とは別個であることができる。
ｂ．ＳＥＴがウェブサーバを認証する
ｃ．ＳＥＴがＳＥＴのデバイス証明書を用いてウェブサーバに認証する。
ｃ．ＳＥＴがＳＥＴのデバイス証明書を用いてウェブサーバに認証する。
ｄ．これで、ウェブサーバは、セキュアなチャネルがデバイス証明書内のＳＥＴアイデンティティ（例えば、ＩＭＥＩ、ＭＥＩＤ又は一連番号）と関連付けられていることを認証している。
４．ＳＵＰＬユーザが、ウェブサイトと何らかの（範囲外の）認証を実施する。例えば、ウェブサーバは、ＳＬＰ専用のユーザ名／パスワード、又は認定された（ｆｅｄｅｒａｔｅｄ）ユーザ名／パスワード又はその他の加入者詳細、例えば、アドレス、誕生日、等、を要求することができる。
５．これで、ＳＬＰオペレータが、セキュアな形で加入者をデバイスアイデンティティと関連付けており、この関連付けをＳＬＰ内に格納すべきである。
追加の実施形態８
ＳＵＰＬ３．０は、モードＡ ＳＵＰＬ ＩＮＩＴ保護及びモードＢ ＳＵＰＬ ＩＮＩＴ保護を定義している。モードＡ保護は、ＳＬＰがセキュリティの確保されたＵＬＰセッション中にＳＥＴに共有鍵を送信する能力を有することを要求する。この実施形態は、共有鍵パラメータについて説明し、共有鍵を要求及び送信するためにいずれのＵＬＰメッセージが使用されるべきかを示す。従って、この実施形態は、ＳＵＰＬ３．０内に組み入れることができ、節番号は、ＳＵＰＬ３．０の節を指すことができる。
６．３．３ ＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージのエンド・ツー・ エンド保護
注：ＳＵＰＬ ＩＮＩＴメッセージのエンド・ツー・エンド保護は、非緊急ＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージのみに適用される。
第６．３．３節のプロセスは、Ｄ−ＳＬＰ及びＨ−ＳＬＰであるＳＬＰのみに適用され、それらのプロセスは、Ｅ−ＳＬＰには適用されない。
ＳＵＰＬ ＩＮＩＴ及びＳＵＰＬ ＲＥＩＮＩＴメッセージのエンド・ツー・エンド保護のための手順は、ＳＵＰＬ ＩＮＩＴメッセージとＳＵＰＬ ＲＥＩＮＩＴメッセージとの間では区別がなく、ＳＵＰＬ ＩＮＩＴメッセージ及びＳＵＰＬ ＲＥＩＮＩＴメッセージの両方とも、あたかも同じタイプのメッセージとして処理される。単純化を目的として、それらの手順はＳＵＰＬ ＩＮＩＴ保護手順と呼び、ＳＵＰＬ ＩＮＩＴメッセージ及びＳＵＰＬ ＲＥＩＮＩＴメッセージの両方とも、ＳＵＰＬ ＩＮＩＴ保護手順を用いて処理される。
本明細書ではエンド・ツー・エンドＳＵＰＬ ＩＮＩＴ保護に関して３つの選択肢が提供される。すなわち、Ｎｕｌｌ、モードＡ及びモードＢ。
・ Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護は、エンド・ツー・エンド完全性保護、エンド・ツー・エンドリプレイ保護及び秘密性保護のいずれも提供しない。Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護のための手順は、第６．３．４節で説明される。
・ モードＡ ＳＵＰＬ ＩＮＩＴ保護は、デフォルトアルゴリズムを用いてのエンド・ツー・エンド完全性保護及びエンド・ツー・エンドリプレイ保護を提供する。モードＡ ＳＵＰＬ ＩＮＩＴ保護は、セキュリティが確保されたＵＬＰセッション中にＳＬＰによってＳＥＴに送信された共有鍵を使用する。モードＡ ＳＵＰＬ ＩＮＩＴ保護のための手順は、第６．３．５節で説明される。
・ モードＢ ＳＵＰＬ ＩＮＩＴ保護は、デフォルトアルゴリズムを用いてのエンド・ツー・エンド完全性保護及びエンド・ツー・エンドリプレイ保護を提供する。モードＢ ＳＵＰＬ ＩＮＩＴ保護は、該当するＰＳＫに基づく方法（ＧＢＡ方法又はＳＥＫ方法）を用いて導き出された共有鍵を使用する。モードＢ ＳＵＰＬ ＩＮＩＴ保護のための手順は、第６．３．６節で説明される。
保護レベルに関する優先順位は次の通りである：
◆ Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護は、最低の優先度を有する。
◆ モードＡ ＳＵＰＬ ＩＮＩＴ保護は、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護よりも高い優先度を有する。
◆ モードＢ ＳＵＰＬ ＩＮＩＴ保護は、モードＡ ＳＵＰＬ ＩＮＩＴ保護よりも高い優先度を有する。
ＳＵＰＬ ＩＮＩＴメッセージでは、（下表内の）Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータは、現在の保護レベルにより割り当てられる。
注：この明細書は、将来のバージョンにおいてより高度な保護レベルを追加するのを可能にするように書かれている。この高度な保護は、ＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴのセキュリティを確保するためのその他の方法の交渉を可能にする（例えば、暗号化を可能にする及びアルゴリズムの交渉を可能にする）。
Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータは、ＳＥＴがＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージの構文解析ができるかどうかを決定するのを援助するために含められている。Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータは、拡張性に関して要求される。
ＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージは、セキュリティパラメータを含めるために存在するＰｒｏｔｅｃｔｏｒパラメータを有することができ、
Ｐｒｏｔｅｃｔｏｒパラメータの存在は、下表において規定される。
ＳＵＰＬ ＩＮＩＴ Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータ値及びＳＵＰＬ ＩＮＩＴメッセージ及びＳＵＰＬ ＲＥＩＮＩＴメッセージ内のＰｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータの存在
ＡＣＡに基づく方法をサポートするＳＥＴ又はＤ−ＳＬＰ又はＨ−ＳＬＰは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護をサポートしなければならない。
ＡＣＡに基づく方法をサポートするＳＥＴ又はＤ−ＳＬＰ又はＨ−ＳＬＰは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護をサポートしなければならない。
全ＳＥＴがモードＡ ＳＵＰＬ ＩＮＩＴ保護手順をサポートすべきである。
Ｄ−ＳＬＰ又はＨ−ＳＬＰは、モードＡ ＳＵＰＬ ＩＮＩＴ保護手順をサポートすることができる。
ＰＳＫに基づく方法をサポートするＳＥＴ又はＤ−ＳＬＰ又はＨ−ＳＬＰは、モードＢ ＳＵＰＬ ＩＮＩＴ保護手順をサポートしなければならない。
Ｅ−ＳＬＰエンティティは、現在定義されるＳＵＰＬ ＩＮＩＴ保護には含まれていない。
６．３．３．１ ＳＵＰＬ ＩＮＩＴ保護レベルの交渉
次のプロセスは、Ｄ−ＳＬＰ及びＨ−ＳＬＰであるＳＬＰのみに適用され、それらのプロセスは、Ｅ−ＳＬＰには適用されない。
ＳＵＰＬ ＩＮＩＴ保護レベルがどのようにして交渉されるかに関する情報を提供するための説明を以下に示した。
４．ＳＥＴは、有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが存在しないときには（例えば、パワーアップ時又はＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの寿命が切れているとき）Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護を適用しなければならない。初期の保護レベルは、常にＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護である。この状態で、ＳＥＴは、すべてのＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージを処理する、すなわち、いずれのメッセージも暗黙に廃棄されない。ＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージが不具合状態で構文解析される場合は、ＳＥＴは、誤りメッセージをＳＬＰに送信する。
５．ＳＥＴが、特定のＳＬＰに関してモードＡ又はモードＢ ＳＵＰＬ ＩＮＩＴ保護を用いて既に交渉された有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及び有効なリプレイカウンタを有する場合は、ＳＥＴは、交渉されたモード（モードＡ又はモードＢ）を用いてそのＳＬＰからのすべてのＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージを処理する。
６．ＳＥＴがＳＬＰへの相互に認証されたセキュアなコネクションを確立するときに、
ａ．相互認証のためにＰＳＫに基づく方法（ＧＢＡ又はＳＥＫ）が使用された場合は、モードＢ ＳＵＰＬ ＩＮＩＴ保護が適用され、ＰＳＫ−ＴＬＳのハンドシェイクにおいてやり取りされたＢ−ＴＩＤは、Ｋｓ（３ＧＰＰ及び３ＧＰＰ２配備ではＫｓ_ＮＡＦとして使用される）又は３ＧＰＰ及び３ＧＰＰ２配備においてＫｓ_ＮＡＦとして使用されるＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを導き出すために使用することができるＳＥＫに対応する。このＫｓ_ＮＡＫ又はＳＥＫ及び関連付けられたＢ−ＴＩＤは、以下のいずれかまでモードＢ ＳＵＰＬ ＩＮＩＴ保護で使用される。
ａ．相互認証のためにＰＳＫに基づく方法（ＧＢＡ又はＳＥＫ）が使用された場合は、モードＢ ＳＵＰＬ ＩＮＩＴ保護が適用され、ＰＳＫ−ＴＬＳのハンドシェイクにおいてやり取りされたＢ−ＴＩＤは、Ｋｓ（３ＧＰＰ及び３ＧＰＰ２配備ではＫｓ_ＮＡＦとして使用される）又は３ＧＰＰ及び３ＧＰＰ２配備においてＫｓ_ＮＡＦとして使用されるＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを導き出すために使用することができるＳＥＫに対応する。このＫｓ_ＮＡＫ又はＳＥＫ及び関連付けられたＢ−ＴＩＤは、以下のいずれかまでモードＢ ＳＵＰＬ ＩＮＩＴ保護で使用される。
ｉ．鍵が期限切れになるまで。この場合は、ＳＥＴ及びＳＬＰはＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護に戻る
ｉｉ．ＳＥＴ及びＳＬＰが非緊急セッションでＡＣＡ方法を使用するまで。この場合は、ＳＥＴ及びＳＬＰは、以下のステップ３のｂにおいて説明されるようにモードＡ又はＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護に戻る、又は、
ｉｉｉ．ＳＥＴ及びＨ−ＳＬＰが、新しいＢ−ＴＩＤを用いてＴＬＳを確立するためにＧＢＡの又はＳＥＫのブートストラッピング再交渉方法を使用するまで。この場合は、Ｂ−ＴＩＤ及び対応するＫｓ_ＮＡＦ又はＳＥＫがモードＢ ＳＵＰＬ ＩＮＩＴ保護のために使用される。
ｉｉ．ＳＥＴ及びＳＬＰが非緊急セッションでＡＣＡ方法を使用するまで。この場合は、ＳＥＴ及びＳＬＰは、以下のステップ３のｂにおいて説明されるようにモードＡ又はＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護に戻る、又は、
ｉｉｉ．ＳＥＴ及びＨ−ＳＬＰが、新しいＢ−ＴＩＤを用いてＴＬＳを確立するためにＧＢＡの又はＳＥＫのブートストラッピング再交渉方法を使用するまで。この場合は、Ｂ−ＴＩＤ及び対応するＫｓ_ＮＡＦ又はＳＥＫがモードＢ ＳＵＰＬ ＩＮＩＴ保護のために使用される。
ｂ．そうでない場合は、ＳＥＴ及びＳＬＰは、ＤＣｅｒｔ方法又はＡＣＡ方法を用いてセキュアなコネクションを確立した。
ｉ．ＳＥＴが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有さない場合は、それは、セキュアなセッションの確立に引き続いてそれのＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓパラメータを搬送する次のＵＬＰメッセージ内のＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｉｎｖａｌｉｄＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）でＳＬＰに示す。
１．モードＡ ＳＵＰＬ ＩＮＩＴ保護の場合は、ＳＬＰは、次のＳＵＰＬ ＥＮＤメッセージにおいてモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順を実施する（第６．３．５．２節）。成功裏のモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順は、モードＡ ＳＵＰＬ ＩＮＩＴ保護が適用されることをＳＥＴに示す。成功裏のモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順が生じるまでは、ＳＥＴは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護を使用するものとする。
注：ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを更新する方針は、ＳＬＰオペレータの判断である。
２．ＳＬＰがモードＡ ＳＵＰＬ ＩＮＩＴ保護をサポートしない（又はこの特定の時点でモードＡ ＳＵＰＬ ＩＮＩＴ保護をサポートしない）場合は、ＳＬＰは、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及びＭｏｄｅＡＫｅｙＬｉｆｅｔｉｍｅパラメータを送信せず、それは、ＳＥＴがＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護を使用するものとすることを示す。
ｉｉ．ＳＥＴが有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有するが、有効なＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを有さないか又はリプレイ保護に関する同期化を失っている場合は、それは、セキュアなセッションの確立に引き続いてそれのＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓパラメータを搬送する次のＵＬＰメッセージ内のＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｏｕｔｏｆｓｙｎｃＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）でＳＬＰに示す。
１．次のＳＵＰＬ ＥＮＤメッセージでモードＡ再同期化手順を実施する（第６．３．５．３節）。成功裏のモードＡ再同期化手順は、モードＡ ＳＵＰＬ ＩＮＩＴ保護が適用されることをＳＥＴに示す。成功裏のモードＡ再同期化手順が生じるまでは、ＳＥＴは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護を使用するものとする。
２．ＳＬＰがモードＡ ＳＵＰＬ ＩＮＩＴ保護をサポートしない（又はこの特定の時点でモードＡ ＳＵＰＬ ＩＮＩＴ保護をサポートすることを希望しない）場合は、ＳＬＰは、モードＡ再同期化手順を実施せず（第６．３．５．３節）、それは、ＳＥＴがＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護を使用するものとすることを示す。）
これは、ＳＥＴがＳＬＰへの新しいＴＬＳコネクションを設定するごとに保護レベルが再交渉されることを意味することに注目すること。
これは、ＳＥＴがＳＬＰへの新しいＴＬＳコネクションを設定するごとに保護レベルが再交渉されることを意味することに注目すること。
６．３．３．２ ＳＬＰの観点からの交渉
ＳＥＴとの直近のＩＰセッションがＧＢＡ又はＳＥＫ方法を用いて認証され、及びＳＬＰがＳＥＴに関する現在のＢ−ＴＩＤ及び関連付けられた鍵を有する場合は、
◆ Ｂ−ＴＩＤがＧＢＡを用いて入手された鍵に関するものである場合は、ＳＬＰは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを、直近のＢ−ＴＩＤに対応し、次のように生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦとして割り当てる。
○ ＦＱＤＮは、Ｈ−ＳＬＰ_ＦＱＤＮであるものとする。
○ ＳＵＰＬ_ＩＮＩＴ保護のために使用するものとするＧＢＡ Ｕａセキュリティプロトコル識別子は、ＯＭＮＡレジストリ［ＯＭＮＡ］で定義される。
◆ Ｂ−ＴＩＤがＳＥＫ方法を用いて導き出された鍵に関するものである場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、第６．１．２．１．２節で定義されるＳＥＫである。
◆ その他のＳＵＰＬ ＩＮＩＴ保護は交渉されていないと仮定すると、ＳＬＰは、そのＳＥＴのためにモードＢ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
そうでない場合は、ＳＬＰがＳＥＴに関する有効なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及び関連付けられた鍵を有する場合は、ＳＬＰは、そのＳＥＴのためにモードＡ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
その他の保護レベルが割り当てられていない場合は、ＳＬＰは、そのＳＥＴのためにＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
ＳＬＰは、現在割り当てられているレベルのＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴ保護に対応する（引き渡し前にＳＵＰＬ ＩＮＩＴメッセージを処理するための）手順を適用する。これは、ＳＵＰＬ ＩＮＩＴメッセージ内のＰｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータのための該当値を割り当てることを含む。
６．３．３．３ ＳＥＴの観点からの交渉
ＳＬＰとの直近のＩＰセッションがＧＢＡ又はＳＥＫ方法を用いて認証され、及びＳＥＴがそのＩＰセッションのために用いられる現在のＢ−ＴＩＤ及び関連付けられた鍵を有する場合、
◆ Ｂ−ＴＩＤがＧＢＡを用いて入手された鍵に関するものである場合は、ＳＥＴは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを、直近のＢ−ＴＩＤに対応し、次のように生成されるＫｓ_（ｉｎｔ／ｅｘｔ_）ＮＡＦとして割り当てる。
○ ＦＱＤＮは、Ｈ−ＳＬＰ_ＦＱＤＮであるものとする。
○ ＳＵＰＬ_ＩＮＩＴ保護のために使用するものとするＧＢＡ Ｕａセキュリティプロトコル識別子［３ＧＰＰ２４．１０９］は、ＯＭＮＡレジストリ［ＯＭＮＡ］で定義される。
◆ Ｂ−ＴＩＤがＳＥＫ方法を用いて導き出された鍵に関するものである場合は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹは、第６．１．２．１．２節で定義されるＳＥＫである。
◆ その他のＳＵＰＬ ＩＮＩＴ保護は交渉されていないと仮定すると、ＳＥＴは、モードＢ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
そうでない場合は、ＳＥＴがＳＬＰに関する有効なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及び関連付けられたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを有する場合は、ＳＥＴは、そのＳＬＰのためにモードＡ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
その他の保護レベルが割り当てられていない場合は、ＳＥＴは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護レベルを割り当てる。
ＳＥＴは、現在割り当てられているレベルのＳＵＰＬ ＩＮＩＴ保護に対応する（受信されたＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージを処理するための）手順を適用する。
６．３．３．４ 例外手順
ＳＥＴ内部のＳＵＰＬ ＩＮＩＴ保護パラメータが壊れているとＳＥＴが決定した場合は、ＳＥＴは、ＳＬＰとのＴＬＳセッションを確立しなければならない。
・ ＧＢＡ認証が使用される場合は、ＳＥＴは、新しい鍵を確立するためのＧＢＡブートストラッピングを開始しなければならない。
・ ＳＥＫ方法を使用するＳＥＴに関しては、ＳＥＴは、第６．１．２．１．２節において定義されるように、新しい鍵をイネーブルにするためにＳＥＫブートストラッピングを開始しなければならない。
・ そうでない場合は、ＳＥＴは、第６．３．３．１節のステップ３のｂの手順に従う。
ＳＬＰがセキュリティコンテキストを失った場合は（例えば、大量のデータ損失）、ＳＬＰは、測位活動を開始する手段を有さないことになる。コンテキストは、Ｋｓ_ＮＡＦ又はＳＥＫが期限切れになるか又はＳＥＴがＳＬＰに接続するときに再確立される。この“ブロックアウトウィンドウ”（ｂｌｏｃｋ ｏｕｔ ｗｉｎｄｏｗ）を防止するために、ＳＬＰは、該シナリオから回復するためにすべてのＳＵＰＬ ＩＮＩＴセキュリティコンテキスト情報が十分な冗長度を持って格納されるようにすべきである。
６．３．３．５ ＳＥＴにおいてＳＵＰＬ ＩＮＩＴメッセージを処理するための一般的手順
以下の手順は、受信されたＳＵＰＬ ＩＮＩＴメッセージを処理する方法を決定するためにＳＥＴによって適用される。
１．ＳＥＴが送信ＳＬＰ（ＳＵＰＬ ＩＮＩＴメッセージを送信したＳＬＰ）を識別する。
ａ．ＳＵＰＬ ＩＮＩＴメッセージ内にＤ−ＳＬＰ ＦＱＤＮパラメータが存在する場合は、ＳＥＴは、このパラメータを用いて送信ＳＬＰを識別するものとする。
ｉ．ＳＥＴが識別されたＤ−ＳＬＰと既存の関係を有さない場合は、ＳＥＴは、ＳＵＰＬ ＩＮＩＴメッセージを暗黙に廃棄するものとし、現在の手順から出る。
ｉｉ．そうでない場合は、ＳＥＴは、ステップ２に進む。
ｂ．ＳＵＰＬ ＩＮＩＴメッセージ内にＤ−ＳＬＰ ＦＱＤＮパラメータが存在しない場合は、ＳＥＴは、送信ＳＬＰをＳＥＴのＨ−ＳＬＰとして識別する。
２．ＳＥＴが、送信ＳＬＰのために割り当てられたＳＵＰＬ ＩＮＩＴ保護レベルに基づいて初期フィルタリングを実施する：
ａ．送信ＳＬＰのためにＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護が割り当てられた場合は、ＳＥＴは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護手順を実施し、現在の手順から出る。
ａ．送信ＳＬＰのためにＮｕｌｌ ＳＵＰＬ ＩＮＩＴ保護が割り当てられた場合は、ＳＥＴは、Ｎｕｌｌ ＳＵＰＬ ＩＮＩＴ保護手順を実施し、現在の手順から出る。
ｂ．送信ＳＬＰのためにモードＡ又はモードＢ ＳＵＰＬ ＩＮＩＴ保護が割り当てられた場合は、
ｉ．ＳＵＰＬ ＩＮＩＴメッセージにＰｒｏｔｅｃｔｏｒパラメータが入っていない場合は、ＳＥＴは、ＳＵＰＬ ＩＮＩＴメッセージを暗黙に廃棄し、現在の手順から出る。
ｉ．ＳＵＰＬ ＩＮＩＴメッセージにＰｒｏｔｅｃｔｏｒパラメータが入っていない場合は、ＳＥＴは、ＳＵＰＬ ＩＮＩＴメッセージを暗黙に廃棄し、現在の手順から出る。
ｉｉ．ＳＵＰＬ ＩＮＩＴメッセージにＰｒｏｔｅｃｔｏｒパラメータが入っている場合は、ＳＥＴは、第６．３．５節又は第６．３．６節のそれぞれの該当するモードＡ ＳＵＰＬ ＩＮＩＴ保護手順又はモードＢ ＳＵＰＬ ＩＮＩＴ保護手順を実施する。ＳＥＴは、送信ＳＬＰと関連付けられたＳＵＰＬ ＩＮＩＴ ＲＯＯＴ鍵のうちのいずれがＳＵＰＬ ＩＮＩＴメッセージの処理のために使用されるべきかを識別するためにＰｒｏｔｅｃｔｏｒパラメータ内のＫｅｙＩｄｅｎｔｉｆｉｅｒを使用する。
６．３．５ モードＡ ＳＵＰＬ ＩＮＩＴ保護レベルに関する仕様
６．３．５．１ モードＡ ＳＵＰＬ ＩＮＩＴ保護のための鍵識別子
モードＡ ＳＵＰＬ ＩＮＩＴ保護は、ＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージとともに送信することができる２つの鍵識別子、すなわち、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及びＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ、を使用する。
・ ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹと関連付けられたグローバルで一意の、長期の鍵識別子である。ＳＬＰは、ＳＬＰがＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのための新しい値をプロビジョニングするときのみに新しいＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒをＳＥＴに提供する。
・ ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けられた短期のアイデンティティ（仮名）である。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒが有効である期間の間グローバルで一意であるものとする。ＳＥＴ及びＳＬＰは、第６．３．５．５節及び第６．３．５．６節において説明されるようにＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの値を同期化する。
ＳＬＰは、典型的には、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを基本的ＳＵＰＬ ＩＮＩＴプロテクタ内のＫｅｙＩｄｅｎｔｉｆｉｅｒとして使用する。ＳＥＴは、基本的ＳＵＰＬ ＩＮＩＴプロテクタを検証するためにいずれのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹが使用されるべきかを決定するためにＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを使用する。
ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒは、典型的には、ＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージでは送信されず、その理由は、観察者が複数のＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージを１つの共通のＳＥＴユーザと関連付けるのを可能にするためである。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの目的は、脅威エージェントが複数のＳＵＰＬ ＩＮＩＴメッセージを１人のＳＥＴユーザと関連付けるためにＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを使用するのを防止することである。ＳＬＰ及びＳＥＴのみがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒをＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けることができるようにすべきである。ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを変更する頻度は、主に、ＳＥＴユーザの判断である。ＳＬＰは、ＳＬＰ方針に基づいてＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのための新しい値を確立することを選択することができる。
しかしながら、ＳＬＰがより長期のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを基本的ＳＵＰＬ ＩＮＩＴプロテクタ内のＫｅｙＩｄｅｎｔｉｆｉｅｒとして使用することを希望する状況が存在する。例えば、ＳＥＴが基本的ＳＵＰＬ ＩＮＩＴプロテクタ内のＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを用いて複数のＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージに応答していないと仮定する。ＳＬＰは、ＳＥＴがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒに関する同期化を失っていることを懸念するおそれがある。ＳＥＴ及びＳＬＰは、長期的なＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒに関しての方が同期化状態を維持する可能性が高い。従って、ＳＬＰは、同期化を失うことがＳＥＴがＳＵＰＬ ＩＮＩＴメッセージを検証するのを妨げないようにするために基本的ＳＵＰＬ ＩＮＩＴプロテクタ内のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを用いてＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴメッセージを送信することができる。
６．３．５．２ モードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹのための値は、ＳＬＰが（セキュアなＳＵＰＬセッションにおけるＳＥＴへのＳＵＰＬ ＥＮＤメッセージ内で）新しいＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒパラメータ、ＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒパラメータ、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹパラメータ及びＭｏｄｅＡＫｅｙＬｉｆｅｔｉｍｅパラメータを送信することによって確立される。引き渡しが成功である場合は、ＳＬＰ及びＳＥＴは、このモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順を成功であるとみなす。
ＭｏｄｅＡＫｅｙＬｉｆｅｔｉｍｅパラメータは、鍵が有効でなくなるときのＵＴＣ時間を含む。
６．３．５．３ モードＡ再同期化手順
ＳＬＰは、次のステップを用いてＳＥＴとＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのための新しい値を確立する：
１．ＳＬＰが、（セキュアなＳＵＰＬセッションでのＳＥＴへのＳＵＰＬ ＥＮＤメッセージにおいて）現在のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及び新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒパラメータをＳＥＴに送信する。引き渡しが成功である場合は、ＳＬＰは、このモードＡ再同期化手順を成功であるとみなす。
２．ＳＥＴが、受信されたＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを、ＳＥＴがそのＳＬＰのために現在割り当てている有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ値のＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと比較する。
ａ．ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ値が異なる場合は、これは、ＳＥＴにおいて割り当てられたＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの値が壊れていることを示し、次のステップが実施される：
ｉ．ＳＥＴがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを廃棄し、このモードＡ再同期化手順は失敗であるとみなす。
ｉ．ＳＥＴがＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを廃棄し、このモードＡ再同期化手順は失敗であるとみなす。
ｉｉ．ＳＥＴが第６．３．３．４節の例外手順を開始する。
ｂ．受信されたＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒが有効なＭｏ ｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと等しい場合は、
ｉ．ＳＥＴは、新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを対応するＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付ける。
ｉ．ＳＥＴは、新しいＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを対応するＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付ける。
ｉｉ．ＳＥＴは、このモードＡ再同期化手順を成功であるとみなす。
６．３．５．４ モードＡ ＳＵＰＬ ＩＮＩＴ保護及び基本的ＳＵＰＬ ＩＮＩＴプロテクタ
モードＡ ＳＵＰＬ ＩＮＩＴ保護は、基本的ＳＵＰＬ ＩＮＩＴプロテクタ及び第０節において定義される関連付けられた手順を使用し、さらなる明確化のために以下を示した。
◆ ＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅ：ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ又はＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのいずれかが使用されることを示す。
◆ ＫｅｙＩｄｅｎｔｉｆｉｅｒ：ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅに適宜対応するＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ又はＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒのいずれかに対応する。
◆ ＢａｓｉｃＭＡＣは、上記のＫｅｙＩｄｅｎｔｉｆｉｅｒと関連付けられたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いて、ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ＝ＨＭＡＣ−ＳＨＡ２５６−１２８（ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ，“Ｍｏｄｅ Ａ ＩＫ”）を用いて計算される。
６．３．５．５ ＳＬＰ手順
モードＡ専用ＳＬＰ手順は、ＳＵＰＬ ＩＮＩＴ ＲＯＯＴ ＫＥＹ確立、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの期限切れ、及びＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
モードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順は、第６．３．５．２節において規定される。ＳＬＰは、（ＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｉｎｖａｌｉｄＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）における）ＳＥＴによる同期外れ表示又はＳＬＰの（範囲外の）内部判断に応答してモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順を実施することができる。すなわち、ＳＬＰは、ＳＥＴによる対応する表示がないときでもＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを（関連付けられたパラメータとともに）送信することができる。
ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及び関連付けられたパラメータは、以下のうちの早い方の後にＳＬＰにおいて有効であることを停止するものとする
・ 関連付けられたＭｏｄｅＡ ＫｅｙＩｄｅｎｔｉｆｉｅｒの寿命、及び
・ その後の成功したモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立時（第６．３．５．２節）。
モードＡ再同期化手順は、第６．３．５．３節において規定される。ＳＬＰは、（ＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｏｕｔｏｆｓｙｎｃＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）における）ＳＥＴによる同期外れ表示又はＳＬＰの（範囲外の）内部判断に応答してモードＡ再同期化手順を実施することができる。すなわち、ＳＬＰは、ＳＥＴによる対応する表示がないときでもＴｅｍｐｏｒａｒｙＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒを送信することができる。
成功したモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順又は成功したモードＡ再同期化手順に引き続き、ＳＬＰは、ＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒを０ｘ００００にリセットする。
６．３．５．６ ＳＥＴ手順
モードＡ専用ＳＥＴ手順は、ＳＵＰＬ ＩＮＩＴ ＲＯＯＴ_ＫＥＹ確立、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹの期限切れ、及びＳＥＴとＳＬＰとの間で同期化を維持することに関するものである。
モードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順は、第６．３．５．２節において規定される。ＳＥＴは、セキュアなセッション確立に引き続いてＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓパラメータを搬送するＵＬＰメッセージにおいて（ＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｉｎｖａｌｉｄＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）における）有効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹをＳＥＴ内において有さないことを示すことによってモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順をトリガするのを試みることができる。
確立されたＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ及び関連付けられたパラメータは、以下のうちの早い方の後にＳＥＴにおいて無効であるとみなされるものとする
・ 関連付けられたＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒの寿命。
・ その後の成功したモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立（第６．３．５．２節）から５分後。この時間遅延は、最後のモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順の前に送信されたＳＵＰＬ ＩＮＩＴメッセージの引き渡しを考慮したものであり、このため、ＳＵＰＬ ＩＮＩＴメッセージは、前のＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを用いて保護しなければならないことになる。
・ ＳＥＴが、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ、ＭｏｄｅＡＫｅｙＩｄｅｎｔｉｆｉｅｒ及びＭｏｄｅＡＫｅｙＬｉｆｅｔｉｍｅの値の崩壊を検出した時点。崩壊が発生した場合は、ＳＥＴは、第６．３．３．４節の例外手順を開始するものとする。
モードＡ再同期化手順は、第６．３．５．３節において規定される。ＳＥＴは、セキュアなセッション確立に引き続いてＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓパラメータを搬送するＵＬＰメッセージにおいて（ＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓ（ｓＵＰＬＩＮＩＴＲｏｏｔＫｅｙＳｔａｔｕｓ＝”ｏｕｔｏｆｓｙｎｃＳＵＰＬＩＮＩＴＲｏｏｔＫｅｙ”）における）ＳＥＴ内での同期化喪失を示すことによってモードＡ再同期化手順をトリガするのを試みることができる。
成功したモードＡ ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順又は成功したモードＡ再同期化手順に引き続き、ＳＥＴは、ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒのための使用された値のキャッシュをクリアする（ＳＬＰもＢａｓｉｃＬａｓｔＲｅｐｌａｙＣｏｕｎｔｅｒを０ｘ００００にリセットしていることになるため）。
６．３．７ 基本的ＳＵＰＬ ＩＮＩＴプロテクタを使用するための仕様
基本的ＳＵＰＬ ＩＮＩＴプロテクタは、モードＡ ＳＵＰＬ ＩＮＩＴ保護及びモードＢ ＳＵＰＬ ＩＮＩＴ保護の両方のために使用され、次のパラメータを含む：
◆ ＫｅｙＩｄｅｎｔｉｆｉｅｒＴｙｐｅ
◆ ＫｅｙＩｄｅｎｔｉｆｉｅｒ：長さ＝８オクテット
◆ ＢａｓｉｃＲｅｐｌａｙＣｏｕｎｔｅｒ：長さ＝２オクテット
◆ ＢａｓｉｃＭＡＣ：長さ＝４オクテット
ＢａｓｉｃＭＡＣパラメータは、以下のように生成される。
◆ ＢａｓｉｃＭＡＣ＝ＨＭＡＣ−ＳＨＡ２５６−３２（ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫ，ＳＵＰＬ_ＩＮＩＴ／ＲＥＩＮＩＴ’）、ここで、
◆ ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫは、モードＡ ＳＵＰＬ ＩＮＩＴ保護及びモードＢ ＳＵＰＬ ＩＮＩＴ保護のそれぞれに関する第６．３．５節及び第６．３．６節により導き出される。
◆ ＳＵＰＬ_ＩＮＩＴ_Ｂａｓｉｃ_ＩＫは、モードＡ ＳＵＰＬ ＩＮＩＴ保護及びモードＢ ＳＵＰＬ ＩＮＩＴ保護のそれぞれに関する第６．３．５節及び第６．３．６節により導き出される。
◆ ＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴ’は、ＢａｓｉｃＭＡＣ以外の全パラメータが割り当てられ、ＭＡＣパラメータがすべてゼロに設定されたＳＵＰＬ ＩＮＩＴ／ＲＥＩＮＩＴに対応する
◆ ＨＭＡＣ−ＳＨＡ２５６−３２及びＨＭＡＣ−ＳＨＡ２５６−１２８は、［ＨＭＡＣ］において規定される。
◆ ＨＭＡＣ−ＳＨＡ２５６−３２及びＨＭＡＣ−ＳＨＡ２５６−１２８は、［ＨＭＡＣ］において規定される。
６．１．１．２ サポートされる認証方法概要（情報用）
（１）汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく。汎用ブートストラッピングアーキテクチャ（ＧＢＡ）［３ＧＰＰ ３３．２２０］、［３ＧＰＰ ３３．２２２］、［３ＧＰＰ２Ｓ．Ｓ０１１４］、［３ＧＰＰ ２４．１０９］を有するＴＬＳ−ＰＳＫ。ＧＢＡは、既存の３ＧＰＰ／３ＧＰＰ２認証メカニズムを用いて導き出される共有される秘密に基づいて相互認証能力を提供する。
◆ ＳＥＴ及びＳＬＰは、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）を有するＴＬＳ−ＰＳＫを用いて相互に認証される。
（２）ＳＥＫに基づく（ＷＩＭＡＸ ＳＬＰのみに適用）。
◆ ＳＥＴ及びＳＬＰは、ＳＥＫを有するＴＬＳ−ＰＳＫを用いて相互に認証される。ＳＥＫ方法の詳細は、第６．１．２．１．２節において見つけることができる。
（３）デバイス証明書（ＤＣｅｒｔ）に基づく。このＡＮから独立した方法は、次を用いるＴＬＳを使用する
◆ ＳＥＴに対してＳＬＰを認証するためのＲＳＡサーバ証明書、
◆ ＳＬＰに対してＳＥＴを認証するためのＲＳＡクライアント証明書。
◆ ＳＥＴに対してＳＬＰを認証するためのＲＳＡサーバ証明書、
◆ ＳＬＰに対してＳＥＴを認証するためのＲＳＡクライアント証明書。
（４）代替クライアント認証（ＡＣＡ）に基づく。これは、次を用いるＴＬＳを使用する
◆ ＳＥＴに対してＳＬＰを認証するためのＲＳＡ証明書、
◆ ＳＬＰに対するＳＥＴの代替クライアント認証（第６．１．４節参照）。この場合は、ＳＬＰは、ＳＥＴ識別子（ＭＳＩＳＤＮ、等）と関連付けられたＩＰアドレスをベアラネットワークに確認させることによってＳＥＴを認証する。
◆ ＳＥＴに対してＳＬＰを認証するためのＲＳＡ証明書、
◆ ＳＬＰに対するＳＥＴの代替クライアント認証（第６．１．４節参照）。この場合は、ＳＬＰは、ＳＥＴ識別子（ＭＳＩＳＤＮ、等）と関連付けられたＩＰアドレスをベアラネットワークに確認させることによってＳＥＴを認証する。
（５）ＳＬＰ専用。これは、ＳＬＰがＳＥＴを認証できないシナリオにおいて使用される。この方法は、非緊急時のためには使用しないものとする。ＳＥＴは、この方法とＡＣＡ基づく場合を区別することができない。これは、以下を用いてＴＬＳを使用する
◆ ＳＥＴに対してＳＬＰを認証するためのＲＳＡ証明書
◆ ＳＥＴは認証されない。
◆ ＳＥＴに対してＳＬＰを認証するためのＲＳＡ証明書
◆ ＳＥＴは認証されない。
６．１．２．１．１ ＧＢＡ方法をサポートする配備
（ＧＢＡ［３ＧＰＰ ３３．２２０］、［３ＧＰＰ ２４．１０９］、［３ＧＰＰ２ Ｓ．Ｓ０１０９］をサポートする配備の場合は、共有鍵は次のようにして確立される：
・ ＳＬＰが（ＩＰ通信のセキュリティを確保するために及びＳＵＰＬ ＩＮＩＴ及び／又はＳＵＰＬ ＲＥＩＮＩＴを保護するために）鍵素材をＢＳＦに要求するときには、ＳＬＰは、ＵＳＳ（ユーザセキュリティ設定）も要求しなければならない。ＵＳＳは、永久的なユーザアイデンティティ（例えば、ＩＭＰＩ、ＩＭＳＩ又はＭＳＩＳＤＮ）を含まなければならない。
・ＳＥＴとＳＬＰとの間でのＩＰ通信のセキュリティを確保するためには、ＳＥＴ及びＳＬＰは、ＧＢＡ（［３ＧＰＰ ３３．２２０］、［３ＧＰＰ ２４．１０９］、［３ＧＰＰ ３３．２２２］、［３ＧＰＰ２ Ｓ．Ｓ０１０９］）を用いてＴＬＳ−ＰＳＫにより共有秘密鍵を導き出し及び動作しなければならない。ＳＬＰは、ＳＬＰを指定する適切に定義されたドメイン名ＳＬＰ_Ａｄｄｒｅｓｓ_ＦＱＤＮ、例えば、ｓｌｐ．ｏｐｅｒａｔｏｒ．ｃｏｍ、を有さなければならない。ＴＬＳ−ＰＳＫのために使用されるものとするＧＢＡ Ｕａセキュリティプロトコル識別子がＯＭＮＡレジストリ［ＯＭＮＡ］内で定義されている。ＳＬＰは、ＢＳＦによって提供された永久的なユーザアイデンティティが対応するセキュリティが確保されたコネクションを通じてＳＬＰによって受信されたＳＵＰＬメッセージ内のＳＥＴアイデンティティに対応することを確認しなければならない。
・ＳＵＰＬ ＩＮＩＴ及び／又はＳＵＰＬ ＲＥＩＮＩＴのＭＡＣ保護に関して、ＧＢＡ（［３ＧＰＰ ３３．２２０］、［３ＧＰＰ ２４．１０９］）により鍵が導き出される。ＳＵＰＬ ＩＮＩＴ保護のために使用されるものとするＧＢＡ Ｕａセキュリティプロトコル識別子がＯＭＮＡレジストリ［ＯＭＮＡ］内で定義されている。ＳＵＰＬ ＩＮＩＴメッセージ（又はＳＵＰＬ ＲＥＩＮＩＴメッセージ）に含まれるｂａｓｉｃＭＡＣのＫｅｙＩｄｅｎｔｉｆｉｅｒは、Ｋｓ_ＮＡＦが生成されるＫｓのＢ−ＴＩＤでなければならない。注：Ｄ／Ｈ−ＳＬＰによるＢＳＦへのＳＵＰＬ ＩＮＩＴ保護鍵の要求は、典型的には、Ｄ／Ｈ−ＳＬＰによるＩＰ通信のセキュリティを確保する鍵の要求と同時に発生することになる。
・ＳＥＴは、有効なＫｓが常にプロビジョニングされていることを確認しなければならない。有効なＫｓが存在しない場合は、ＳＥＴは、ＫｓをプロビジョニングするためのＧＢＡブートストラッピング手順を開始しなければならない。新しいＵＩＣＣ（ＵＳＩＭ／ＳＩＭ／Ｒ−ＵＩＭ）がＳＥＴによって検出されるごとに新しいＫｓが確立されなければならない。さらに、ＳＥＴは、（ホームネットワークオペレータによって設定された）Ｋｓ_ＮＡＦの寿命が経過しているときには新しい共有鍵を確立しなければならない。
ＳＥＴ能力パラメータ
９．２．８ ＳＵＰＬ ＥＮＤ
９．２．８ ＳＵＰＬ ＥＮＤ
ＳＵＰＬ ＥＮＤメッセージ
１０．ｘ ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅ
ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅパラメータは、ＳＬＰからＳＥＴにモードＡ ＳＵＰＬ ＩＮＩＴ保護のための鍵を送信するためのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順（第６．３．５．２節参照）において使用される。
１０．ｘ ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅ
ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅパラメータは、ＳＬＰからＳＥＴにモードＡ ＳＵＰＬ ＩＮＩＴ保護のための鍵を送信するためのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ確立手順（第６．３．５．２節参照）において使用される。
ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｅｓｐｏｎｓｅ
１１．４ メッセージ拡張（ＳＵＰＬバージョン３）
ULP-Version-3-message-extensions DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
EXPORTS
Ver3-SUPL-INIT-extension,Ver3-SUPL-START-extension,Ver3-SUPL-POS-INIT-extension, Ver3-SUPL-END-extension, Ver3-SUPL-RESPONSE-extension, Ver3-SUPL-TRIGGERED-
RESPONSE-extension, Ver3-SUPL-TRIGGERED-START-extension, Ver3-SUPL-TRIGGERED-
STOP-extension, Ver3-SUPL-SET-INIT-extension, Ver3-SUPL-NOTIFY-extension, Ver3-SUPL-
NOTIFY-RESPONSE-extension, Ver3-SUPL-REPORT-extension, QoPCapabilities,
RelativePositioningCapabilities, CivicPositioningCapabilities;
IMPORTS
Ver, QoP, FQDN
FROM ULP-Components
CircularArea, EllipticalArea, PolygonArea
FROM Ver2-ULP-Components
PosProtocolVersion3GPP, PosProtocolVersion3GPP2
FROM ULP-Version-2-parameter-extensions
PosProtocolVersionOMA
FROM ULP-Version-3-parameter-extensions
PosPayLoad
FROM SUPL-POS
Notification
FROM SUPL-INIT
SessionID
FROM ULP-Components
NotificationResponse
FROM SUPL-NOTIFY-RESPONSE
maxnumSessions, SessionList
FROM SUPL-REPORT
OMA-LPPe-RelativeLocation,OMA-LPPe-ReferencePointUniqueID,OMA-LPPe-CivicLocation
FROM OMA-LPPE;
[幾つかの不変の部分は、簡潔さを目的として削除した]
Ver3-SUPL-END-extension ::= SEQUENCE {
locationURISet LocationURISet OPTIONAL,
slpAuthorization SLPAuthorization OPTIONAL,
relativePosition OMA-LPPe-RelativeLocation OPTIONAL,
civicPosition OMA-LPP-CivicLocation OPTIONAL,
sULPINITKeyResponse SULPINITKeyResponse OPTIONAL,
...}
[幾つかの不変の部分は、簡潔さを目的として削除した]
SULPINITKeyResponse ::= CHOICE {
modeAKeyEstablishment ModeAKeyEstablishment,
modeAResynch ModeAResynch,
...}
ModeAKeyEstablishment ::= SEQUENCE {
modeAKeyIdentifier OCTET STRING(SIZE (8)),
temporaryModeAKeyIdentifier OCTET STRING(SIZE (8)),
sUPLINITROOTKEY BIT STRING(SIZE (128)),
ModeAKeyLifetime UTCTime,
...}
ModeAResynch ::= SEQUENCE {
modeAKeyIdentifier OCTET STRING(SIZE (8)),
temporaryModeAKeyIdentifier OCTET STRING(SIZE (8)),
...}
END
11.6 パラメータ拡張（ＳＵＰＬバージョン３）
ULP-Version-3-parameter-extensions DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
EXPORTS
Ver3-PosProtocol-extension,Ver3-SETCapabilities-extension,Ver3-SLPCapabilities-extension, Ver3-TriggerParams-extension, Ver3-ServiceSupported-extensions;
IMPORTS
QoPCapabilities, RelativePositioningCapabilities, CivicPositioningCapabilities
FROM ULP-Version-3-message-extensions;
Ver3-PosProtocol-extension ::= SEQUENCE {
posProtocolVersionLPPe PosProtocolVersionOMA OPTIONAL,
...}
Ver3-SETCapabilities-extension ::= SEQUENCE {
qoPCapabilities QoPCapabilities OPTIONAL,
civicPositioningCapabilities CivicPositioningCapabilities OPTIONAL,
relativePositioningCapabilities RelativePositioningCapabilities
OPTIONAL,
d-SLP-Provision-from-H-SLP BOOLEAN,
e-SLP-Provision-from-H-SLP BOOLEAN,
d-SLP-Provision-from-Proxy-D-SLP BOOLEAN,
e-SLP-Provision-from-Proxy-E-SLP BOOLEAN,
d-SLP-Notification-to-H-SLP BOOLEAN,
sensorSupport BOOLEAN,
sUPLINITRootKeyStatus SUPLINITRootKeyStatus OPTIONAL,
...}
SUPLINITRootKeyStatus ::= ENUMERATED {invalidSUPLINITRootKey(0),
outofsyncSUPLINITRootKey(1), ...}
[幾つかの不変の部分は、簡潔さを目的として削除した]
END
追加の実施形態９
Ｐｒｏｔｅｃｔｏｒ Ｌｅｖｅｌパラメータに関する先行定義は、基本的保護がモードＡ保護及びモードＢ保護に変更されていることを反映していないことがある（モードＢ保護は、前基本的保護と同じである）。先行のＡＳＮ．１定義も更新することができる。従って、以下の提案は、モードＡ及びモードＢ保護を反映させ及びＡＳＮ．１第１１．４節を更新するように第１０．２５節を修正することを目的としてＳＵＰＬ３．０に組み入れることができる（節番は、ＳＵＰＬ３．０の節を指すことができる）。
１１．４ メッセージ拡張（ＳＵＰＬバージョン３）
ULP-Version-3-message-extensions DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
EXPORTS
Ver3-SUPL-INIT-extension,Ver3-SUPL-START-extension,Ver3-SUPL-POS-INIT-extension, Ver3-SUPL-END-extension, Ver3-SUPL-RESPONSE-extension, Ver3-SUPL-TRIGGERED-
RESPONSE-extension, Ver3-SUPL-TRIGGERED-START-extension, Ver3-SUPL-TRIGGERED-
STOP-extension, Ver3-SUPL-SET-INIT-extension, Ver3-SUPL-NOTIFY-extension, Ver3-SUPL-
NOTIFY-RESPONSE-extension, Ver3-SUPL-REPORT-extension, QoPCapabilities,
RelativePositioningCapabilities, CivicPositioningCapabilities;
IMPORTS
Ver, QoP, FQDN
FROM ULP-Components
CircularArea, EllipticalArea, PolygonArea
FROM Ver2-ULP-Components
PosProtocolVersion3GPP, PosProtocolVersion3GPP2
FROM ULP-Version-2-parameter-extensions
PosProtocolVersionOMA
FROM ULP-Version-3-parameter-extensions
PosPayLoad
FROM SUPL-POS
Notification
FROM SUPL-INIT
SessionID
FROM ULP-Components
NotificationResponse
FROM SUPL-NOTIFY-RESPONSE
maxnumSessions, SessionList
FROM SUPL-REPORT
OMA-LPPe-RelativeLocation,OMA-LPPe-ReferencePointUniqueID,OMA-LPPe-CivicLocation
FROM OMA-LPPE;
[幾つかの不変の部分は、簡潔さを目的として削除した]
Ver3-SUPL-END-extension ::= SEQUENCE {
locationURISet LocationURISet OPTIONAL,
slpAuthorization SLPAuthorization OPTIONAL,
relativePosition OMA-LPPe-RelativeLocation OPTIONAL,
civicPosition OMA-LPP-CivicLocation OPTIONAL,
sULPINITKeyResponse SULPINITKeyResponse OPTIONAL,
...}
[幾つかの不変の部分は、簡潔さを目的として削除した]
SULPINITKeyResponse ::= CHOICE {
modeAKeyEstablishment ModeAKeyEstablishment,
modeAResynch ModeAResynch,
...}
ModeAKeyEstablishment ::= SEQUENCE {
modeAKeyIdentifier OCTET STRING(SIZE (8)),
temporaryModeAKeyIdentifier OCTET STRING(SIZE (8)),
sUPLINITROOTKEY BIT STRING(SIZE (128)),
ModeAKeyLifetime UTCTime,
...}
ModeAResynch ::= SEQUENCE {
modeAKeyIdentifier OCTET STRING(SIZE (8)),
temporaryModeAKeyIdentifier OCTET STRING(SIZE (8)),
...}
END
11.6 パラメータ拡張（ＳＵＰＬバージョン３）
ULP-Version-3-parameter-extensions DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
EXPORTS
Ver3-PosProtocol-extension,Ver3-SETCapabilities-extension,Ver3-SLPCapabilities-extension, Ver3-TriggerParams-extension, Ver3-ServiceSupported-extensions;
IMPORTS
QoPCapabilities, RelativePositioningCapabilities, CivicPositioningCapabilities
FROM ULP-Version-3-message-extensions;
Ver3-PosProtocol-extension ::= SEQUENCE {
posProtocolVersionLPPe PosProtocolVersionOMA OPTIONAL,
...}
Ver3-SETCapabilities-extension ::= SEQUENCE {
qoPCapabilities QoPCapabilities OPTIONAL,
civicPositioningCapabilities CivicPositioningCapabilities OPTIONAL,
relativePositioningCapabilities RelativePositioningCapabilities
OPTIONAL,
d-SLP-Provision-from-H-SLP BOOLEAN,
e-SLP-Provision-from-H-SLP BOOLEAN,
d-SLP-Provision-from-Proxy-D-SLP BOOLEAN,
e-SLP-Provision-from-Proxy-E-SLP BOOLEAN,
d-SLP-Notification-to-H-SLP BOOLEAN,
sensorSupport BOOLEAN,
sUPLINITRootKeyStatus SUPLINITRootKeyStatus OPTIONAL,
...}
SUPLINITRootKeyStatus ::= ENUMERATED {invalidSUPLINITRootKey(0),
outofsyncSUPLINITRootKey(1), ...}
[幾つかの不変の部分は、簡潔さを目的として削除した]
END
追加の実施形態９
Ｐｒｏｔｅｃｔｏｒ Ｌｅｖｅｌパラメータに関する先行定義は、基本的保護がモードＡ保護及びモードＢ保護に変更されていることを反映していないことがある（モードＢ保護は、前基本的保護と同じである）。先行のＡＳＮ．１定義も更新することができる。従って、以下の提案は、モードＡ及びモードＢ保護を反映させ及びＡＳＮ．１第１１．４節を更新するように第１０．２５節を修正することを目的としてＳＵＰＬ３．０に組み入れることができる（節番は、ＳＵＰＬ３．０の節を指すことができる）。
１０．２２ 保護レベル
Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータは、ＳＵＰＬ ＩＮＩＴ／ＳＵＰＬ ＲＥＩＮＩＴメッセージのための保護レベルを定義する。
１１．３ メッセージ拡張（ＳＵＰＬバージョン２）
ULP-Version-2-message-extensions DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
EXPORTS
Ver2-SUPL-INIT-extension,Ver2-SUPL-START-extension,Ver2-SUPL-RESPONSE-extension,Ver2-SUPL-POS-INIT-extension,Ver2-SUPL-POS-extension, Ver2-SUPL-END-extension;
IMPORTS
SLPAddress, Position, Ver
FROM ULP-Components
SETCapabilities
FROM SUPL-START
SupportedNetworkInformation, GNSSPosTechnology, MultipleLocationIds, UTRAN-GPSReferenceTimeResult, UTRAN-GANSSReferenceTimeResult, UTRAN-GPSReferenceTimeAssistance, UTRAN-GANSSReferenceTimeAssistance, SPCSETKey, SPCTID, SPCSETKeylifetime, ThirdParty, ApplicationID
FROM Ver2-ULP-Components
TriggerType
FROM SUPL-TRIGGERED-START
Ver3-ProtectionLevel-extension
FROM ULP-Version-3-parameter-extensions;
[幾つかの不変の部分は、簡潔さを目的として削除した]
ProtectionLevel ::= SEQUENCE {
protlevel ProtLevel,
basicProtectionParams BasicProtectionParams OPTIONAL, -- not applicable in SUPL 3.0
...,
ver3-ProtectionLevel-extension Ver3-ProtectionLevel-extension OPTIONAL}
ProtLevel ::= ENUMERATED {
nullProtection(0), basicProtection(1), ..., ver3-modeAProtection(2), ver3-modeBProtection(3)} − basicProtection(1) is not applicable in SUPL 3.0
[幾つかの不変の部分は、簡潔さを目的として削除した]
END
１１．６ パラメータ拡張（ＳＵＰＬバージョン３）
ULP-Version-3-parameter-extensions DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
EXPORTS
Ver3-PosProtocol-extension,Ver3-SETCapabilities-extension,Ver3-SLPCapabilities-extension, Ver3-TriggerParams-extension, Ver3-ServiceSupported-extensions, Ver3-ProtectionLevel-extension;
IMPORTS
QoPCapabilities, RelativePositioningCapabilities, CivicPositioningCapabilities
FROM ULP-Version-3-message-extensions;
[幾つかの不変の部分は、簡潔さを目的として削除した]
Ver3-ProtectionLevel-extension ::= SEQUENCE {
keyIdentifierType KeyIdentifierType,
keyIdentifier OCTET STRING(SIZE (8)),
basicReplayCounter INTEGER(0..65535),
basicMAC BIT STRING(SIZE (32)),
...}
KeyIdentifierType ::= ENUMERATED {
ModeAKeyIdentifier(0), TemporaryModeAKeyIdentifier(1), ModeBKeyIdentifier(2), ...}
END
ここにおいて開示される実施形態と関係させて説明される様々な例示的な論理ブロック、コンフィギュレーション、モジュール、回路、及びアルゴリズム上のステップは、電子ハードウェア、処理デバイス、例えば、ハードウェアプロセッサ、によって実行されるコンピュータソフトウェア、又は両方の組み合わせとして実装することができることを当業者はさらに理解するであろう。上記においては、様々な例示的なコンポーネント、ブロック、コンフィギュレーション、モジュール、回路、及びステップが、それらの機能の観点で一般的に説明されている。該機能がハードウェアとして又は実行可能なソフトウェアとして実装されるかは、特定の用途及び全体的システムに対する設計上の制約事項に依存する。当業者は、説明されている機能を各々の特定の用途に合わせて様々な形で実装することができるが、該実装決定は、本開示の適用範囲からの逸脱を生じさせるものであるとは解釈されるべきではない。
ここにおいて開示される実施形態と関係させて説明される方法又はアルゴリズムのステップは、直接ハードウェア内に、プロセッサによって実行されるソフトウェアモジュール内に、ファームウェア内に、又はそれらの組み合わせ内において具現化することができる。ソフトウェア又は論理モジュールは、非一時的な記憶媒体、例えば、ランダムアクセスメモリ（ＲＡＭ）、磁気抵抗ランダムアクセスメモリ（ＭＲＡＭ）、スピン−トルク転送ＭＲＡＭ（ＳＴＴ−ＭＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、プログラマブル読み取り専用メモリ（ＰＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、レジスタ、ハードディスク、取り外し可能なディスク、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、デジタルバーサタイルディスク（ＤＶＤ）、Ｂｌｕ−ｒａｙディスク（登録商標）、又は当業において知られるその他の形態の記憶媒体、内に常駐することができる。上記の組み合わせもコンピュータによって読み取り可能な媒体の適用範囲内に含められるべきである。例は、データ構造を用いて符号化されたコンピュータによって読み取り可能な媒体と、コンピュータプログラムを用いて符号化されたコンピュータによって読み取り可能な媒体と、を含む。コンピュータによって読み取り可能な媒体は、製造品の形態をとることができる。典型的な記憶媒体は、プロセッサに結合され、このため、プロセッサは、記憶媒体から情報を読み取ること又は記憶媒体に情報を書き込むことができる。代替においては、記憶媒体は、プロセッサと一体化することができる。プロセッサ及び記憶媒体は、特定用途向け集積回路（ＡＳＩＣ）内に常駐することができる。ＡＳＩＣは、コンピューティングデバイス又はユーザ端末内に常駐することができる。代替においては、プロセッサ及び記憶媒体は、コンピューティングデバイス又はユーザ端末において個別のコンポーネントとして常駐することができる。従って、ここにおいて説明される方法は、用途に依存して様々な手段によって実装することができる。例えば、これらの方法は、ハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせ内に実装することができる。
ＡＳＩＣ及びプロセッサに加えて、又はＡＳＩＣ及びプロセッサの代替として、ハードウェア実装は、ここにおいて説明される機能を果たすように設計されたデジタル信号処理デバイス（ＤＳＰＤ）、プログラマブル論理デバイス（ＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子デバイス、その他の電子ユニット、又はそれらの組み合わせを含むことができる。ここにおいて、用語“制御論理”は、ソフトウェア、ハードウェア、ファームウェア、又は組み合わせによって実装された論理を包含する。
ファームウェア及び／又はソフトウェアを含む実装に関しては、方法は、ここにおいて説明される機能を果たすモジュール（例えば、手順、関数、等）を用いて実装することができる。ここにおいて説明される方法を実装する際には、命令を有形に具現化させるあらゆる機械によって読み取り可能な媒体を使用することができる。例えば、ソフトウェアコードは、メモリに格納して処理ユニットによって実行することができる。メモリは、処理ユニット内に又は処理ユニットの外部に実装することができる。ここにおいて用いられる場合において、用語“メモリ”は、あらゆるタイプの長期、短期、揮発性、非揮発性、又はその他の記憶デバイスを意味し、いずれの特定のタイプの又は数のメモリにも限定されず、及びメモリが格納される媒体のタイプに限定されない。ファームウェア及び／又はソフトウェアが関係する実装においては、機能は、コンピュータによって読み取り可能な媒体において１つ以上の命令又はコードとして格納することができる。
本開示は、Ｗｉ−Ｆｉ／ＷＬＡＮ又はその他の無線ネットワークと関係させて実装することができる。Ｗｉ−Ｆｉ／ＷＬＡＮ信号に加えて、無線／移動局は、衛星から信号を受信することもでき、それらは、全地球測位システム（ＧＰＳ）、ガリレオ、ＧＬＯＮＡＳＳ（グロナス）、ＮＡＶＳＴＡＲ（ナブ
スター）、ＱＺＳＳ、これらのシステムの組み合わせからの衛星を使用するシステム、将来開発されるあらゆるＳＰＳからであることができ、各々は、概して、衛星測位システム（ＳＰＳ）又はＧＮＳＳ（全地球航法衛星システム）と呼ばれる。本開示は、擬似衛星（シュードライト）又は擬似衛星を含むシステムの組み合わせと関係させて実装することもできる。本開示は、フェムトセル又はフェムトセルを含むシステムの組み合わせと関係させて実装することができる。
スター）、ＱＺＳＳ、これらのシステムの組み合わせからの衛星を使用するシステム、将来開発されるあらゆるＳＰＳからであることができ、各々は、概して、衛星測位システム（ＳＰＳ）又はＧＮＳＳ（全地球航法衛星システム）と呼ばれる。本開示は、擬似衛星（シュードライト）又は擬似衛星を含むシステムの組み合わせと関係させて実装することもできる。本開示は、フェムトセル又はフェムトセルを含むシステムの組み合わせと関係させて実装することができる。
本開示は、様々な無線通信ネットワーク、例えば、ワイヤレスワイドエリアネットワーク（ＷＷＡＮ）、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）、等、と関係させて実装することができる。用語“ネットワーク”及び“システム”は、互換可能な形でしばしば用いられる。用語“ｐｏｓｉｔｉｏｎ”（位置）及び“ｌｏｃａｔｉｏｎ）”（位置）は、互換可能な形でしばしば用いられる。ＷＷＡＮは、符号分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交周波数分割多元接続（ＯＦＤＭＡ）ネットワーク、単一搬送波周波数分割多元接続（ＳＣ−ＦＤＭＡ）ネットワーク、ロングタームエボリューション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ））ネットワーク、ＷｉＭＡＸ（ＩＥＥＥ８０２．１６）ネットワーク、等であることができる。ＣＤＭＡネットワークは、１つ以上の無線アクセス技術（ＲＡＴ）、例えば、ｃｄｍａ２０００、Ｗｉｄｅｂａｎｄ−ＣＤＭＡ（Ｗ−ＣＤＭＡ）、等、を実装することができる。ｃｄｍａ２０００は、ＩＳ−９５規格と、ＩＳ−２０００規格と、ＩＳ−８５６規格と、を含む。ＴＤＭＡネットワークは、グローバル移動体通信システム（ＧＳＭ）、デジタルアドバンストモバイルフォンシステム（Ｄ−ＡＭＰＳ）、又は何らかのその他のＲＡＴ、を実装することができる。ＧＳＭ及びＷ−ＣＤＭＡは、“３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ”（３ＧＰＰ）という名称のコンソーシアムからの文書で説明される。ｃｄｍａ２０００は、“３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ２”（３ＧＰＰ２）という名称のコンソーシアムからの文書で説明される。３ＧＰＰ及び３ＧＰＰ２の文書は公に入手可能である。ＷＬＡＮは、ＩＥＥＥ８０２．１１ｘネットワークであることができ、及びＷＰＡＮは、Ｂｌｕｅｔｏｏｔｈ（登録商標）ネットワーク、ＩＥＥＥ８０２．１５ｘ、又は何らかのその他タイプのネットワークであることができる。それらの技法は、ＷＷＡＮ、ＷＬＡＮ及び／又はＷＰＡＮのあらゆる組み合わせと関係させて実装することもできる。
衛星測位システム（ＳＰＳ）は、典型的には、エンティティが送信機から受信された信号に少なくとも部分的に基づいて地球上又は地球上方における自己の位置を決定するのを可能にするために配置された送信機のシステムを含む。該送信機は、典型的には、設定された数のチップの繰り返し擬似ランダム雑音（ＰＮ）コードで表示された信号を送信し、地上に基づく制御局、ユーザ装置及び／又は又は宇宙ビークル上に配置することができる。特定の例では、該送信機は、地球軌道周回衛星ビークル（ＳＶ）上に配置することができる。例えば、全地球航法衛星システム(ＧＮＳＳ)、例えば、全地球測位システム（ＧＰＳ）、ガリレオ、グロナス又はコンパス、から成る一群内のＳＶは、（例えば、ＧＰＳにおけるように各衛星に関して異なるＰＮコードを用いて又はグロナスにおけるように異なる周波数で同じコードを用いて）一群内のその他のＳＶによって送信されたＰＮコードと区別することができるＰＮコードで表示された信号を送信することができる。幾つかの態様により、ここにおいて提示される技法は、ＳＰＳのためのグローバルシステム（例えば、ＧＮＳＳ）に制限されない。例えば、ここにおいて提供される技法は、様々な地域システム、例えば、日本上空の準天頂衛星システム（ＱＺＳＳ）、インド上空のインド地域航法衛星システム（ＩＲＮＳＳ）、中国上空の北斗、等、及び／又は、１つ以上の全地球的な及び／又は地域の航法衛星システムと関連付けることができる又は１つ以上の全地球的な及び／又は地域の航法衛星システムとともに使用するために使用可能にすることができる様々な補強システム（例えば、（静止衛星型衛星航法補強システム（ＳＢＡＳ））、に適用することができ又は様々な地域システム、例えば、日本上空の準天頂衛星システム（ＱＺＳＳ）、インド上空のインド地域航法衛星システム（ＩＲＮＳＳ）、中国上空の北斗、等、及び／又は、１つ以上の全地球的な及び／又は地域の航法衛星システムと関連付けることができる又は１つ以上の全地球的な及び／又は地域の航法衛星システムとともに使用するために使用可能にすることができる様々な補強システム（例えば、（静止衛星型衛星航法補強システム（ＳＢＡＳ））において使用するために使用可能にすることができる。一例として、ただし制限することなしに、ＳＢＡＳは、完全性情報、時間差補正、等を提供する補強システム、例えば、ワイドエリア補強システム（ＷＡＡＳ）、欧州静止衛星航法オーバーレイサービス（ＥＧＮＯＳ）、運輸多目的衛星用衛星航法補強システム（ＭＳＡＳ）、ＧＰＳ補助地球補強航法システム又はＧＰＳ及び地球補強航法システム（ＧＡＧＡＮ）、等を含むことができる。従って、ここにおいて使用される場合において、ＳＰＳは、１つ以上の全地球的な及び／又は地域的な航法衛星システム及び／又は補強システムのあらゆる組み合わせを含むことができ、及び、ＳＰＳ信号は、ＳＰＳ、ＳＰＳ類似、及び／又は該１つ以上のＳＰＳと関連付けられたその他の信号を含むことができる。
方法は、擬似衛星又は衛星と擬似衛星の組み合わせを利用する位置決定システムとともに使用することができる。擬似衛星は、Ｌハンド（又はその他の手段は）搬送波信号で変調された（ＧＰＳ又はＣＤＭＡセルラー信号に類似する）ＰＮコード又はその他の測距コードをブロードキャストする地上をベースにした送信機であり、ＧＳＰ時間と同期化することができる。各々の該送信機には、遠隔受信機による識別を可能にするために一意のＰＮコードを割り当てることができる。擬似衛星は、軌道周回衛星からの信号を入手不能な状況、例えば、トンネル、鉱山、建物、アーバンキャニオン又はその他の包囲されたエリア内、において有用である。擬似衛星のその他の実装は、ラジオビーコンと呼ばれる。ここにおいて用いられる場合の用語“衛星”は、擬似衛星と、擬似衛星の同等物と、その他と、を含むことが意図される。ここにおいて用いられる場合の用語“ＳＰＳ信号”は、擬似衛星又は擬似衛星の同等物からのＳＰＳ類似信号を含むことが意図される。
移動局（例えば、ＭＳ又はＳＴＡ）は、無線通信及び／又はナビゲーション信号を受信することが可能なデバイス、例えば、セルラー又はその他の無線通信デバイス、パーソナル通信システム（ＰＣＳ）デバイス、パーソナルナビゲーションデバイス（ＰＮＤ）、パーソナル情報マネージャ（ＰＩＭ）、パーソナルデジタルアシスタント（ＰＤＡ）、ラップトップ、タブレット、ネットブック、スマートブック又はその他の適切なモバイルデバイス、を意味する。用語“移動局”は、例えば、短距離無線接続、赤外線接続、有線接続、又はその他の接続によってパーソナルナビゲーションデバイス（ＰＮＤ）と通信するデバイスを含むことも意図されており、衛星信号の受信、援助データの受信、及び／又は位置関連の処理がそのデバイス又はＰＮＤで生じるかどうかを問わない。さらに、“移動局”は、例えば、インターネット、Ｗｉ−Ｆｉ、又はその他のネットワークを介して、サーバとの通信が可能である全デバイス、例えば、無線通信デバイス、コンピュータ、ラップトップ、等を含むことが意図され、、衛星信号の受信、援助データの受信、及び／又は位置関連の処理がそのデバイスにおいて、サーバにおいて、又はネットワークと関連付けられた他のデバイスにおいて生じるかどうかを問わない。上記のいずれの動作可能な組み合わせも、“移動局”とみなされる。用語“移動局”及び“モバイルデバイス”は、互換可能な形でしばしば使用される。
本開示は、実施形態例を含む。しかしながら、その他の実装を使用可能である。何かが“最適化される”、“要求される”とする指定又はその他の指定は、本開示が最適化されているシステム、又は“要求される”要素が存在するシステムのみに適用されるということ（又はその他の指定に起因するその他の制限）を示すものではない。これらの指定は、特定の説明される実施形態のみに言及する。当然のことであるが、数多くの実装が可能である。技法は、ここにおいて説明されるプロトコル以外のそれらとともに使用することができ、現在開発中の又は開発予定のプロトコルを含む。
開示される実施形態に関する前の説明は、当業者が開示される実施形態を製造又は使用することを可能にするために提供される。これらの実施形態に対する様々な変更は、当業者にとって容易に明確になるであろう、及びここにおいて定められる一般原理は、本開示の適用範囲を逸脱せずにその他の実施形態に対しても適用することができる。以上のように、本開示は、ここにおいて示される実施形態に限定されることは意図されず、次の請求項によって定義される原理及び新規の特徴に一致する限りにおいて最も広範な適用範囲が認められるべきである。
Claims (70)
- モバイルデバイスにおいて、前記モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納することであって、前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含むことと、
前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがセキュアユーザプレーンロケーション（ＳＵＰＬ）ユーザと関連付けられているとして認証するためにＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に前記少なくとも１つのセキュリティクレデンシャルを送信することと、を備える、認証の方法。 - 前記少なくとも１つのセキュリティクレデンシャルは、公開鍵を含む請求項１に記載の方法。
- 前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスの国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び一連番号のうちの少なくとも１つを含む請求項１に記載の方法。
- 前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス証明書を含む請求項１に記載の方法。
- 前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのユニバーサル集積スマートカード（ＵＩＣＣ）、前記モバイルデバイスのメモリのセキュアな部分、又はそれらの組み合わせにおいて格納される請求項１に記載の方法。
- 前記モバイルデバイスは、ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）を含む請求項１に記載の方法。
- 前記モバイルデバイスは、米国電気電子学会（ＩＥＥＥ）８０２．１１規格に準拠して動作するネットワークを介して前記ＳＬＰに前記少なくとも１つのセキュリティクレデンシャルを送信する請求項１に記載の方法。
- モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納するメモリであって、前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含むメモリと、
前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがセキュアユーザプレーンロケーション（ＳＵＰＬ）ユーザと関連付けられているとして認証するためにＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に前記少なくとも１つのセキュリティクレデンシャルを送信することを前記モバイルデバイスに行わせるように構成されたプロセッサと、を備える、装置。 - 前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス証明書、前記モバイルデバイスの公開鍵、国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び一連番号のうちの少なくとも１つを含む請求項８に記載の装置。
- モバイルデバイス専用である少なくとも１つのセキュリティクレデンシャルを格納するための手段であって、前記少なくとも１つのセキュリティクレデンシャルは、前記モバイルデバイスのデバイス識別子を含む手段と、
前記デバイス識別子と格納されたデバイス識別子との比較に基づいて前記モバイルデバイスがセキュアユーザプレーンロケーション（ＳＵＰＬ）ユーザと関連付けられているとして認証するためにＳＵＰＬロケーションプラットフォーム（ＳＬＰ）に前記少なくとも１つのセキュリティクレデンシャルを送信することを前記モバイルデバイスに行わせるための手段と、を備える、装置。 - 前記モバイルデバイスは、ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）を含む請求項１０に記載の装置。
- プロセッサによって実行されたときに、
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスに送信されるべきメッセージを生成し、
前記モバイルデバイスのデバイス証明書を含む応答を前記モバイルデバイスから受信し、及び
前記デバイス証明書に基づいて前記モバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証することを前記プロセッサに行わせる命令を備え、前記メッセージは、
前記ＳＵＰＬサーバの識別子と前記ＳＵＰＬサーバの公開鍵とを含むサーバ証明書と、
前記モバイルデバイスのデバイス証明書の要求と、を含む、非一時的なプロセッサによって読み取り可能な媒体。 - 前記モバイルデバイスは、ＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）を備え、前記ＳＵＰＬサーバは、ＳＵＰＬロケーションプラットフォーム（ＳＬＰ）を備える請求項１２に記載の非一時的なプロセッサによって読み取り可能な媒体。
- 前記メッセージは、前記モバイルデバイスによってサポートされる１つ以上のトランスポート層セキュリティ（ＴＬＳ）暗号スイートの表示を前記モバイルデバイスから受信したことに応答して送信され、前記メッセージは、前記１つ以上のＴＬＳ暗号スイートのうちの少なくとも１つの選択をさらに含む請求項１２に記載の非一時的なプロセッサによって読み取り可能な媒体。
- 前記デバイス証明書は、前記モバイルデバイスのデバイス識別子を含む請求項１２に記載の非一時的なプロセッサによって読み取り可能な媒体。
- プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスに送信されるべきメッセージを生成し、
前記モバイルデバイスのデバイス識別子を含む応答を前記モバイルデバイスから受信し、及び
前記デバイス証明書に基づいて前記モバイルデバイスがＳＵＰＬユーザと関連付けられているとして認証するために前記プロセッサによって実行可能であり、前記メッセージは、
前記ＳＵＰＬサーバの識別子と前記ＳＵＰＬサーバの公開鍵とを含むサーバ証明書と、
前記モバイルデバイスのデバイス証明書の要求と、を含む、装置。 - 前記メッセージは、前記モバイルデバイスによってサポートされる１つ以上のトランスポート層セキュリティ（ＴＬＳ）暗号スイートの表示を前記モバイルデバイスから前記ＳＵＰＬサーバにおいて受信したことに応答して送信され、前記メッセージは、前記１つ以上のＴＬＳ暗号スイートのうちの少なくとも１つの選択をさらに含む請求項１６に記載の装置。
- セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスによってサポートされる１つ以上のトランスポート層セキュリティ（ＴＬＳ）暗号スイートの表示を前記モバイルデバイスから受信することと、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされるＴＬＳ事前共有鍵（ＴＬＳ−ＰＳＫ）暗号スイートを含むかどうかを決定することと、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされる前記ＴＬＳ−ＰＳＫ暗号スイートを含むと決定したことに応答して、前記モバイルデバイスを認証するために汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく認証プロセスを実施することと、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされるＴＬＳ−ＰＳＫ暗号スイートを含まないと決定したことに応答して、前記ＳＵＰＬサーバが証明書に基づく認証方法をサポートするかどうかを決定することと、
前記ＳＵＰＬサーバが前記証明書に基づく認証方法をサポートすると決定したことに応答して、前記モバイルデバイスにサーバ証明書を送信することと前記モバイルデバイスからデバイス証明書を受信することとを含む前記証明書に基づく認証方法を実施することと、を備える、方法。 - 前記ＳＵＰＬサーバが前記証明書に基づく認証方法をサポートしないと決定したことに応答して、前記モバイルデバイスが３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）ネットワーク又は３ＧＰＰ２ネットワークに接続されるときに代替クライアント認証（ＡＣＡ）に基づく認証方法を実施することをさらに備える請求項１８に記載の方法。
- 前記証明書に基づく認証方法は、前記モバイルデバイスによって使用されるアクセスネットワークから独立している請求項１８に記載の方法。
- プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスによってサポートされる１つ以上のトランスポート層セキュリティ（ＴＬＳ）暗号スイートの表示を前記モバイルデバイスから受信し、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされるＴＬＳ事前共有鍵（ＴＬＳ−ＰＳＫ）暗号スイートを含むかどうかを決定し、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされる前記ＴＬＳ−ＰＳＫ暗号スイートを含むと決定したことに応答して、前記モバイルデバイスを認証するために汎用ブートストラッピングアーキテクチャ（ＧＢＡ）に基づく認証プロセスを実施し、
前記１つ以上のＴＬＳ暗号スイートが前記ＳＵＰＬサーバによってサポートされるＴＬＳ−ＰＳＫ暗号スイートを含まないと決定したことに応答して、前記ＳＵＰＬサーバが証明書に基づく認証方法をサポートするかどうかを決定し、
前記ＳＵＰＬサーバが前記証明書に基づく認証方法をサポートすると決定したことに応答して、前記モバイルデバイスにサーバ証明書を送信することと前記モバイルデバイスからデバイス証明書を受信することとを含む証明書に基づく認証プロセスを実施するために前記プロセッサによって実行可能である、装置。 - 前記命令は、前記ＳＵＰＬサーバが前記証明書に基づく認証方法をサポートしないと決定したことに応答して、前記モバイルデバイスが３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）ネットワーク又は３ＧＰＰ２ネットワークに接続されるときに代替クライアント認証（ＡＣＡ）に基づく認証方法を実施するために前記プロセッサによってさらに実行可能である請求項２１に記載の装置。
- 前記証明書に基づく認証プロセスは、前記モバイルデバイスによって使用されるアクセスネットワークから独立している請求項２１に記載の装置。
- モバイルデバイスにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバと前記モバイルデバイスとの間でＳＵＰＬセッションを開始するために前記ＳＵＰＬサーバからセッション開始メッセージを受信することと、
前記モバイルデバイスが前記セッションメッセージを受信する前に前記モバイルデバイスが前記ＳＵＰＬサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、
前記有効なセッション開始メッセージ鍵を用いてセッション開始メッセージを認証することと、
前記セッション開始メッセージの成功裏の認証に応答して前記ＳＵＰＬサーバとの前記ＳＵＰＬセッションを開始することと、を備える、方法。 - 前記セッション開始メッセージは、ＳＵＰＬ ＩＮＩＴメッセージを含む請求項２４に記載の方法。
- 前記有効なセッション開始メッセージ鍵は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを含む請求項２４に記載の方法。
- 前記モバイルデバイスが前記有効なセッション開始メッセージ鍵を受信しないことに応答して、
前記ＳＵＰＬサーバにメッセージを送信することと、
前記メッセージに応答して前記ＳＵＰＬサーバからセッション開始メッセージを受信することと、をさらに備える請求項２４に記載の方法。 - 前記メッセージは、ＳＵＰＬ_ＩＮＩＴ_ＫｅｙＲｅｑｕｅｓｔパラメータを含む請求項２７に記載の方法。
- 前記メッセージは、ＳＥＴ Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含まれているＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータを含む請求項２７に記載の方法。
- プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
モバイルデバイスにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバと前記モバイルデバイスとの間でＳＵＰＬセッションを開始するために前記ＳＵＰＬサーバからセッション開始メッセージを受信し、
前記モバイルデバイスが前記セッションメッセージを受信する前に前記モバイルデバイスが前記ＳＵＰＬサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、
前記有効なセッション開始メッセージ鍵を用いて前記セッション開始メッセージを認証し、及び
前記セッション開始メッセージの成功裏の認証に応答して前記ＳＵＰＬサーバとの前記ＳＵＰＬセッションを開始するために前記プロセッサによって実行可能である、装置。 - 前記セッション開始メッセージは、ＳＵＰＬ ＩＮＩＴメッセージを含む請求項３０に記載の装置。
- 前記有効なセッション開始メッセージ鍵は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを含む請求項３０に記載の装置。
- モバイルデバイスからセキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにメッセージを送信することであって、前記メッセージは、ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータを含むことを備える、方法。
- 前記ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータは、前記モバイルデバイスが無効なＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ又は同期外れのＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを含むことを示す請求項３３に記載の方法。
- 前記ＳＵＰＬ ＩＮＩＴ Ｒｏｏｔ Ｋｅｙ Ｓｔａｔｕｓパラメータは、前記メッセージのＳＵＰＬによってイネーブルにされる端末（ＳＥＴ）Ｃａｐａｂｉｌｉｔｉｅｓパラメータ内に含められる請求項３３に記載の方法。
- 前記メッセージは、ユーザロケーションプロトコル（ＵＬＰ）メッセージを備える請求項３３に記載の方法。
- セキュアプレーンロケーション（ＳＵＰＬ）サーバからモバイルデバイスに、ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｓｅｐｏｎｓｅパラメータを含むＳＵＰＬ ＥＮＤメッセージを送信することを備える、方法。
- 前記ＳＵＰＬ ＩＮＩＴ Ｋｅｙ Ｒｓｅｐｏｎｓｅパラメータは、モードＡ鍵識別子、一時的モードＡ鍵識別子、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹ、及びモードＡ鍵寿命のうちの少なくとも１つを含む請求項３７に記載の方法。
- モバイルデバイスにおいて、セキュアプレーンロケーション（ＳＵＰＬ）サーバと前記モバイルデバイスとの間でＳＵＰＬセッションを継続するために前記ＳＵＰＬサーバからセッション再開メッセージを受信することと、
前記モバイルデバイスが前記セッション再開メッセージを受信する前に前記モバイルデバイスが前記ＳＵＰＬサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、
前記有効なセッション開始メッセージ鍵を用いて前記セッション再開メッセージを認証することと、
前記セッション再開メッセージの成功裏の認証に応答して前記ＳＵＰＬサーバとの前記ＳＵＰＬセッションを継続することと、を備える、方法。 - 前記セッション再開メッセージは、ＳＵＰＬ ＲＥＩＮＩＴメッセージを含む請求項３９に記載の方法。
- 前記モバイルデバイスが前記有効なセッション開始メッセージ鍵を受信しないことに応答して、
前記ＳＵＰＬサーバにメッセージを送信することと、
前記メッセージに応答して前記ＳＵＰＬサーバからセッション開始メッセージ鍵を受信することと、をさらに備える請求項３９に記載の方法。 - プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
モバイルデバイスにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバと前記モバイルデバイスとの間でＳＵＰＬセッションを継続するために前記ＳＵＰＬサーバからセッション再開メッセージを受信し、
前記モバイルデバイスが前記セッション再開メッセージを受信する前に前記モバイルデバイスが前記ＳＵＰＬサーバから有効なセッション開始メッセージ鍵を受信したことに応答して、
前記有効なセッション開始メッセージ鍵を用いて前記セッション再開メッセージを認証し、及び
前記セッション再開メッセージの成功裏の認証に応答して前記ＳＵＰＬサーバとの前記ＳＵＰＬセッションを継続するために前記プロセッサによって実行可能である、装置。 - 前記セッション再開メッセージは、ＳＵＰＬ ＲＥＩＮＩＴメッセージを含む請求項４２に記載の装置。
- 前記有効なセッション開始メッセージ鍵は、ＳＵＰＬ_ＩＮＩＴ_ＲＯＯＴ_ＫＥＹを含む請求項４２に記載の装置。
- ウェブサーバにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスからメッセージを受信することであって、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含むことと、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信することと、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証することと、
前記モバイルデバイスが前記ＳＵＰＬサービスの前記権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするために前記ＳＵＰＬサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信することと、を備える、方法。 - 前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含む請求項４５に記載の方法。
- 前記モバイルデバイスから前記メッセージを受信する前に前記モバイルデバイスに前記ウェブサーバの公開鍵を含むサーバ証明書を送信することと、
前記ウェブサーバの公開鍵を用いて前記メッセージを復号することと、をさらに備える請求項４５に記載の方法。 - 前記セキュリティクレデンシャルは、前記モバイルデバイスの国際移動体装置識別番号（ＩＭＥＩ）、移動局識別子（ＭＳＩＤ）、及び一連番号のうちの少なくとも１つのを含む請求項４５に記載の方法。
- 前記ユーザ識別情報は、識別子と、パスワードと、を含む請求項４５に記載の方法。
- プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
ウェブサーバにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスからメッセージを受信し、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信し、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証し、及び
前記モバイルデバイスが前記ＳＵＰＬサービスの前記権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするために前記ＳＵＰＬサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信するために前記プロセッサによって実行可能であり、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含む、装置。 - 前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含む請求項５０に記載の装置。
- ウェブサーバにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスからメッセージを受信するための手段であって、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含む手段と、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信するための手段と、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証するための手段と、
前記モバイルデバイスが前記ＳＵＰＬサービスの前記権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするために前記ＳＵＰＬサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信するための手段と、を備える、装置。 - 前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含む請求項５２に記載の装置。
- プロセッサによって実行されたときに、
ウェブサーバにおいて、セキュアユーザプレーンロケーション（ＳＵＰＬ）によってイネーブルにされるモバイルデバイスからメッセージを受信し、
前記ウェブサーバにおいて、前記モバイルデバイスからユーザ識別情報を受信し、
前記ユーザ識別情報がＳＵＰＬサービスの権限が付与されたユーザを識別しているとして認証し、及び
前記モバイルデバイスが前記ＳＵＰＬサービスの前記権限が付与されたユーザと関連付けられているとしてＳＵＰＬサーバが認証するのを可能にするために前記ＳＵＰＬサーバに前記モバイルデバイスの前記セキュリティクレデンシャルを送信することを前記プロセッサに行わせる命令を備え、前記メッセージは、前記モバイルデバイスのセキュリティクレデンシャルを含む、非一時的なプロセッサによって読み取り可能な媒体。 - 前記セキュリティクレデンシャルは、公開鍵を含むデバイス証明書を含む請求項５４に記載の非一時的なプロセッサによって読み取り可能な媒体。
- セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスから第１の識別子及び第１のパスワードを受信することと、
前記第１の識別子及び前記第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証することと、
前記第１の識別子及び前記第１のパスワードに取って代わるための第２の識別子及び第２のパスワードを前記モバイルデバイスに送信することであって、前記ＳＵＰＬサーバは、前記モバイルデバイスから前記第２の識別子及び前記第２のパスワードを受信した時点で前記モバイルデバイスとのＳＵＰＬセッションを確立するように構成されることと、を備える、方法。 - 前記第１のパスワードは、ユーザによって選択され、前記第２の識別子及び前記第２のパスワードは、前記ＳＵＰＬサーバにおいて生成される請求項５６に記載の方法。
- 前記ＳＵＰＬサーバにおいて、第２のモバイルデバイスから前記第１の識別子及び第１のパスワードを受信することと、
前記第１の識別子及び前記第１のパスワードが前記ＳＵＰＬサービスの前記権限が付与されたユーザと関連付けられているとして認証することと、
前記第２のモバイルデバイスが前記ＳＵＰＬサービスにアクセスするのを許容することが、前記ＳＵＰＬサービスにアクセスすることが許可される前記権限が付与されたユーザと関連付けられたモバイルデバイスのスレショルド数を超えることになるかどうかを決定することと、をさらに備える請求項５６に記載の方法。 - 前記第２のモバイルデバイスが前記ＳＵＰＬサービスにアクセスするのを許容することが、前記ＳＵＰＬサービスにアクセスすることが許可される前記権限が付与されたユーザと関連付けられたモバイルデバイスのスレショルド数を超えないと決定したことに応答して、前記第１の識別子及び前記第１のパスワードに取って代わるための第３の識別子及び第３のパスワードを前記第２のモバイルデバイスに送信することをさらに備える請求項５８に記載の方法。
- 前記第３の識別子は、前記第２の識別子と別個であり、前記ＳＵＰＬサーバは、前記第２の識別子を用いる前記モバイルデバイスによって及び前記第３の識別子を用いる前記第２のモバイルデバイスによって前記ＳＵＰＬサービスの使用法をモニタリングするように構成される請求項５９に記載の方法。
- プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、命令を格納するように構成され、
前記命令は、
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスから第１の識別子及び第１のパスワードを受信し、
前記第１の識別子及び前記第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証し、及び
前記第１の識別子及び前記第１のパスワードに取って代わるための第２の識別子及び第２のパスワードを前記モバイルデバイスに送信するために前記プロセッサによって実行可能であり、前記ＳＵＰＬサーバは、前記モバイルデバイスから前記第２の識別子及び前記第２のパスワードを受信した時点で前記モバイルデバイスとのＳＵＰＬセッションを確立するように構成される、装置。 - 前記第１のパスワードは、ユーザによって選択され、前記第２の識別子及び前記第２のパスワードは、前記ＳＵＰＬサーバにおいて生成される請求項６１に記載の装置。
- セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスから第１の識別子及び第１のパスワードを受信するための手段と、
前記第１の識別子及び前記第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証するための手段と、
前記第１の識別子及び前記第１のパスワードに取って代わるための第２の識別子及び第２のパスワードを前記モバイルデバイスに送信するための手段と、を備え、前記ＳＵＰＬサーバは、前記モバイルデバイスから前記第２の識別子及び前記第２のパスワードを受信した時点で前記モバイルデバイスとのＳＵＰＬセッションを確立するように構成される、装置。 - 前記第１のパスワードは、ユーザによって選択され、及び、前記第２の識別子及び前記第２のパスワードを生成するための手段をさらに備える請求項６３に記載の装置。
- プロセッサによって実行されたときに、
セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバにおいて、モバイルデバイスから第１の識別子及び第１のパスワードを受信し、
前記第１の識別子及び前記第１のパスワードがＳＵＰＬサービスの権限が付与されたユーザと関連付けられているとして認証し、及び
前記第１の識別子及び前記第１のパスワードに取って代わるための第２の識別子及び第２のパスワードを前記モバイルデバイスに送信することを前記プロセッサに行わせる命令を備え、前記ＳＵＰＬサーバは、前記モバイルデバイスから前記第２の識別子及び前記第２のパスワードを受信した時点で前記モバイルデバイスとのＳＵＰＬセッションを確立するように構成される、非一時的なプロセッサによって読み取り可能な媒体。 - 前記第１のパスワードは、ユーザによって選択され、前記第２の識別子及び前記第２のパスワードは、前記ＳＵＰＬサーバにおいて生成される請求項６５に記載の非一時的なプロセッサによって読み取り可能な媒体。
- セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバからモバイルデバイスにＰｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータを含むＳＵＰＬ ＩＮＩＴメッセージを送信することを備える、方法。
- 前記Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータは、
Ｎｕｌｌ保護、モードＡ保護、及びモードＢ保護のうちの１つを示すＬｅｖｅｌパラメータ、及び
鍵識別子タイプ及び鍵識別子のうちの少なくとも１つを含むＰｒｏｔｅｃｔｉｏｎパラメータのうちの少なくとも１つを含む請求項６７に記載の方法。 - セキュアユーザプレーンロケーション（ＳＵＰＬ）サーバからモバイルデバイスにＰｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータを含むＳＵＰＬ ＲＥＩＮＩＴメッセージを送信することを備える、方法。
- 前記Ｐｒｏｔｅｃｔｉｏｎ Ｌｅｖｅｌパラメータは、
Ｎｕｌｌ保護、モードＡ保護、及びモードＢ保護のうちの１つを示すＬｅｖｅｌパラメータ、及び
鍵識別子タイプ及び鍵識別子のうちの少なくとも１つを含むＰｒｏｔｅｃｔｉｏｎパラメータのうちの少なくとも１つを含む請求項６９に記載の方法。
Applications Claiming Priority (11)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US41088210P | 2010-11-06 | 2010-11-06 | |
| US61/410,882 | 2010-11-06 | ||
| US201161437184P | 2011-01-28 | 2011-01-28 | |
| US61/437,184 | 2011-01-28 | ||
| US201161471048P | 2011-04-01 | 2011-04-01 | |
| US61/471,048 | 2011-04-01 | ||
| US201161527341P | 2011-08-25 | 2011-08-25 | |
| US61/527,341 | 2011-08-25 | ||
| US13/288,949 US8627422B2 (en) | 2010-11-06 | 2011-11-03 | Authentication in secure user plane location (SUPL) systems |
| US13/288,949 | 2011-11-03 | ||
| PCT/US2011/059455 WO2012087435A1 (en) | 2010-11-06 | 2011-11-04 | Authentication in secure user plane location (supl) systems |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015152192A Division JP6185017B2 (ja) | 2010-11-06 | 2015-07-31 | セキュアユーザプレーンロケーション（ｓｕｐｌ）システムにおける認証 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2013546260A true JP2013546260A (ja) | 2013-12-26 |
| JP5876063B2 JP5876063B2 (ja) | 2016-03-02 |
Family
ID=45048220
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013537891A Active JP5876063B2 (ja) | 2010-11-06 | 2011-11-04 | セキュアユーザプレーンロケーション（ｓｕｐｌ）システムにおける認証 |
| JP2015152192A Active JP6185017B2 (ja) | 2010-11-06 | 2015-07-31 | セキュアユーザプレーンロケーション（ｓｕｐｌ）システムにおける認証 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015152192A Active JP6185017B2 (ja) | 2010-11-06 | 2015-07-31 | セキュアユーザプレーンロケーション（ｓｕｐｌ）システムにおける認証 |
Country Status (6)
| Country | Link |
|---|---|
| US (4) | US8627422B2 (ja) |
| EP (1) | EP2636203B1 (ja) |
| JP (2) | JP5876063B2 (ja) |
| KR (2) | KR101530538B1 (ja) |
| CN (2) | CN103370915B (ja) |
| WO (1) | WO2012087435A1 (ja) |
Families Citing this family (209)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7487363B2 (en) | 2001-10-18 | 2009-02-03 | Nokia Corporation | System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage |
| US8948012B2 (en) | 2005-12-29 | 2015-02-03 | Nokia Corporation | System and method for interactive session provision |
| CN101227458B (zh) * | 2007-01-16 | 2011-11-23 | 华为技术有限公司 | 移动ip系统及更新家乡代理根密钥的方法 |
| US8989705B1 (en) | 2009-06-18 | 2015-03-24 | Sprint Communications Company L.P. | Secure placement of centralized media controller application in mobile access terminal |
| US8560604B2 (en) | 2009-10-08 | 2013-10-15 | Hola Networks Ltd. | System and method for providing faster and more efficient data communication |
| US8627422B2 (en) | 2010-11-06 | 2014-01-07 | Qualcomm Incorporated | Authentication in secure user plane location (SUPL) systems |
| EP2461613A1 (en) * | 2010-12-06 | 2012-06-06 | Gemalto SA | Methods and system for handling UICC data |
| US10009319B2 (en) | 2011-02-07 | 2018-06-26 | Qualcomm Incorporated | Methods, apparatuses and articles for identifying and authorizing location servers and location services using a proxy location server |
| US8738027B2 (en) | 2011-02-07 | 2014-05-27 | Qualcomm Incorporated | Methods and apparatus for identifying and authorizing location servers and location services |
| EP2487948A1 (en) * | 2011-02-11 | 2012-08-15 | Research In Motion Limited | System and method for managing access to a communication network |
| ES2631578T3 (es) | 2011-04-01 | 2017-09-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Métodos y aparatos para evitar daños en ataques de red |
| CN102149085B (zh) * | 2011-04-21 | 2014-01-15 | 惠州Tcl移动通信有限公司 | 移动终端及其多接入点管理方法 |
| US9491620B2 (en) | 2012-02-10 | 2016-11-08 | Qualcomm Incorporated | Enabling secure access to a discovered location server for a mobile device |
| WO2013123233A2 (en) * | 2012-02-14 | 2013-08-22 | Apple Inc. | Methods and apparatus for large scale distribution of electronic access clients |
| US9887833B2 (en) * | 2012-03-07 | 2018-02-06 | The Trustees Of Columbia University In The City Of New York | Systems and methods to counter side channel attacks |
| US8955086B2 (en) * | 2012-03-16 | 2015-02-10 | Red Hat, Inc. | Offline authentication |
| US9027102B2 (en) | 2012-05-11 | 2015-05-05 | Sprint Communications Company L.P. | Web server bypass of backend process on near field communications and secure element chips |
| US8756677B2 (en) * | 2012-05-30 | 2014-06-17 | Google Inc. | Variable-strength security based on time and/or number of partial password unlocks |
| US20130326612A1 (en) * | 2012-06-04 | 2013-12-05 | Crocus Technology Inc. | Apparatus and Method for Forming Secure Computational Resources |
| US9497169B2 (en) * | 2012-06-08 | 2016-11-15 | Samsung Electronics Co., Ltd. | Method and system for selective protection of data exchanged between user equipment and network |
| US9282898B2 (en) | 2012-06-25 | 2016-03-15 | Sprint Communications Company L.P. | End-to-end trusted communications infrastructure |
| US9066230B1 (en) | 2012-06-27 | 2015-06-23 | Sprint Communications Company L.P. | Trusted policy and charging enforcement function |
| US8649770B1 (en) | 2012-07-02 | 2014-02-11 | Sprint Communications Company, L.P. | Extended trusted security zone radio modem |
| US8667607B2 (en) | 2012-07-24 | 2014-03-04 | Sprint Communications Company L.P. | Trusted security zone access to peripheral devices |
| US9183412B2 (en) | 2012-08-10 | 2015-11-10 | Sprint Communications Company L.P. | Systems and methods for provisioning and using multiple trusted security zones on an electronic device |
| US9015068B1 (en) | 2012-08-25 | 2015-04-21 | Sprint Communications Company L.P. | Framework for real-time brokering of digital content delivery |
| US8954588B1 (en) | 2012-08-25 | 2015-02-10 | Sprint Communications Company L.P. | Reservations in real-time brokering of digital content delivery |
| US9215180B1 (en) | 2012-08-25 | 2015-12-15 | Sprint Communications Company L.P. | File retrieval in real-time brokering of digital content |
| WO2014060013A1 (en) * | 2012-10-15 | 2014-04-24 | Nokia Solutions And Networks Oy | Network authentication |
| EP2723111B1 (de) * | 2012-10-16 | 2017-12-06 | Deutsche Telekom AG | Mehrfaktor-Authentifikation für mobile Endgeräte |
| US9357382B2 (en) * | 2012-10-31 | 2016-05-31 | Intellisist, Inc. | Computer-implemented system and method for validating call connections |
| US8898769B2 (en) | 2012-11-16 | 2014-11-25 | At&T Intellectual Property I, Lp | Methods for provisioning universal integrated circuit cards |
| US9237133B2 (en) * | 2012-12-12 | 2016-01-12 | Empire Technology Development Llc. | Detecting matched cloud infrastructure connections for secure off-channel secret generation |
| EP2888854B1 (en) * | 2013-01-29 | 2018-02-21 | BlackBerry Limited | A system and method for providing a certificate-based trust framework using a secondary network |
| US9197413B1 (en) * | 2013-02-06 | 2015-11-24 | Rockwell Collins, Inc. | Hybrid secure communication system and method |
| US9578664B1 (en) | 2013-02-07 | 2017-02-21 | Sprint Communications Company L.P. | Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system |
| US9161227B1 (en) | 2013-02-07 | 2015-10-13 | Sprint Communications Company L.P. | Trusted signaling in long term evolution (LTE) 4G wireless communication |
| US9485095B2 (en) * | 2013-02-22 | 2016-11-01 | Cisco Technology, Inc. | Client control through content key format |
| US9426833B2 (en) * | 2013-03-01 | 2016-08-23 | T-Mobile Usa, Inc. | Systems and methods for emergency call route failover |
| US9104840B1 (en) | 2013-03-05 | 2015-08-11 | Sprint Communications Company L.P. | Trusted security zone watermark |
| US9613208B1 (en) | 2013-03-13 | 2017-04-04 | Sprint Communications Company L.P. | Trusted security zone enhanced with trusted hardware drivers |
| US9049013B2 (en) | 2013-03-14 | 2015-06-02 | Sprint Communications Company L.P. | Trusted security zone containers for the protection and confidentiality of trusted service manager data |
| US9049186B1 (en) * | 2013-03-14 | 2015-06-02 | Sprint Communications Company L.P. | Trusted security zone re-provisioning and re-use capability for refurbished mobile devices |
| US8984592B1 (en) | 2013-03-15 | 2015-03-17 | Sprint Communications Company L.P. | Enablement of a trusted security zone authentication for remote mobile device management systems and methods |
| US9191388B1 (en) | 2013-03-15 | 2015-11-17 | Sprint Communications Company L.P. | Trusted security zone communication addressing on an electronic device |
| US9374363B1 (en) | 2013-03-15 | 2016-06-21 | Sprint Communications Company L.P. | Restricting access of a portable communication device to confidential data or applications via a remote network based on event triggers generated by the portable communication device |
| US9602537B2 (en) * | 2013-03-15 | 2017-03-21 | Vmware, Inc. | Systems and methods for providing secure communication |
| US9021585B1 (en) | 2013-03-15 | 2015-04-28 | Sprint Communications Company L.P. | JTAG fuse vulnerability determination and protection using a trusted execution environment |
| US9171243B1 (en) | 2013-04-04 | 2015-10-27 | Sprint Communications Company L.P. | System for managing a digest of biographical information stored in a radio frequency identity chip coupled to a mobile communication device |
| US9324016B1 (en) | 2013-04-04 | 2016-04-26 | Sprint Communications Company L.P. | Digest of biographical information for an electronic device with static and dynamic portions |
| US9454723B1 (en) | 2013-04-04 | 2016-09-27 | Sprint Communications Company L.P. | Radio frequency identity (RFID) chip electrically and communicatively coupled to motherboard of mobile communication device |
| US9838869B1 (en) | 2013-04-10 | 2017-12-05 | Sprint Communications Company L.P. | Delivering digital content to a mobile device via a digital rights clearing house |
| US9443088B1 (en) | 2013-04-15 | 2016-09-13 | Sprint Communications Company L.P. | Protection for multimedia files pre-downloaded to a mobile device |
| US9137218B2 (en) * | 2013-05-03 | 2015-09-15 | Akamai Technologies, Inc. | Splicing into an active TLS session without a certificate or private key |
| US9069952B1 (en) | 2013-05-20 | 2015-06-30 | Sprint Communications Company L.P. | Method for enabling hardware assisted operating system region for safe execution of untrusted code using trusted transitional memory |
| US9560519B1 (en) | 2013-06-06 | 2017-01-31 | Sprint Communications Company L.P. | Mobile communication device profound identity brokering framework |
| CN103324883B (zh) * | 2013-06-24 | 2015-07-29 | 腾讯科技（深圳）有限公司 | 一种多媒体播放终端的认证方法、终端、服务器以及系统 |
| US9183606B1 (en) | 2013-07-10 | 2015-11-10 | Sprint Communications Company L.P. | Trusted processing location within a graphics processing unit |
| US9402163B2 (en) * | 2013-07-19 | 2016-07-26 | Qualcomm Incorporated | In-building location security and privacy |
| CN105340356A (zh) * | 2013-08-02 | 2016-02-17 | 英特尔Ip公司 | 电力周期间的安全用户平面位置(supl)会话持久性 |
| US9208339B1 (en) | 2013-08-12 | 2015-12-08 | Sprint Communications Company L.P. | Verifying Applications in Virtual Environments Using a Trusted Security Zone |
| US9241044B2 (en) | 2013-08-28 | 2016-01-19 | Hola Networks, Ltd. | System and method for improving internet communication by using intermediate nodes |
| US20150074765A1 (en) * | 2013-09-06 | 2015-03-12 | Oracle International Corporation | Registration and configuration of point-of-service devices |
| US9036820B2 (en) | 2013-09-11 | 2015-05-19 | At&T Intellectual Property I, Lp | System and methods for UICC-based secure communication |
| US9350717B1 (en) | 2013-09-23 | 2016-05-24 | Amazon Technologies, Inc. | Location service for user authentication |
| US9208300B2 (en) * | 2013-10-23 | 2015-12-08 | At&T Intellectual Property I, Lp | Apparatus and method for secure authentication of a communication device |
| US9240994B2 (en) | 2013-10-28 | 2016-01-19 | At&T Intellectual Property I, Lp | Apparatus and method for securely managing the accessibility to content and applications |
| US9185626B1 (en) | 2013-10-29 | 2015-11-10 | Sprint Communications Company L.P. | Secure peer-to-peer call forking facilitated by trusted 3rd party voice server provisioning |
| US9313660B2 (en) | 2013-11-01 | 2016-04-12 | At&T Intellectual Property I, Lp | Apparatus and method for secure provisioning of a communication device |
| US9240989B2 (en) | 2013-11-01 | 2016-01-19 | At&T Intellectual Property I, Lp | Apparatus and method for secure over the air programming of a communication device |
| US9191522B1 (en) | 2013-11-08 | 2015-11-17 | Sprint Communications Company L.P. | Billing varied service based on tier |
| US9276910B2 (en) * | 2013-11-19 | 2016-03-01 | Wayne Fueling Systems Llc | Systems and methods for convenient and secure mobile transactions |
| US10700856B2 (en) * | 2013-11-19 | 2020-06-30 | Network-1 Technologies, Inc. | Key derivation for a module using an embedded universal integrated circuit card |
| US9161325B1 (en) | 2013-11-20 | 2015-10-13 | Sprint Communications Company L.P. | Subscriber identity module virtualization |
| CN106851628B (zh) | 2013-12-05 | 2020-08-07 | 华为终端有限公司 | 下载运营商的文件的方法及设备 |
| US9363736B2 (en) * | 2013-12-16 | 2016-06-07 | Qualcomm Incorporated | Methods and apparatus for provisioning of credentials in network deployments |
| US9602962B2 (en) * | 2014-01-15 | 2017-03-21 | Qualcomm Incorporated | Methods and systems for providing location based services in a venue using femtocells |
| US9118655B1 (en) | 2014-01-24 | 2015-08-25 | Sprint Communications Company L.P. | Trusted display and transmission of digital ticket documentation |
| US9197994B2 (en) | 2014-01-29 | 2015-11-24 | Kaseya Limited | Identifying mobile device location and corresponding support center locations to provide support services over a network |
| JP2015148896A (ja) * | 2014-02-05 | 2015-08-20 | アプリックスＩｐホールディングス株式会社 | 通信システム及びサーバ |
| US9407654B2 (en) * | 2014-03-20 | 2016-08-02 | Microsoft Technology Licensing, Llc | Providing multi-level password and phishing protection |
| EP3451621B1 (en) * | 2014-03-21 | 2021-06-30 | Sun Patent Trust | Security key derivation in dual connectivity |
| US9226145B1 (en) | 2014-03-28 | 2015-12-29 | Sprint Communications Company L.P. | Verification of mobile device integrity during activation |
| US9713006B2 (en) | 2014-05-01 | 2017-07-18 | At&T Intellectual Property I, Lp | Apparatus and method for managing security domains for a universal integrated circuit card |
| US9450947B2 (en) * | 2014-05-20 | 2016-09-20 | Motorola Solutions, Inc. | Apparatus and method for securing a debugging session |
| KR102126010B1 (ko) | 2014-05-23 | 2020-06-23 | 후아웨이 테크놀러지 컴퍼니 리미티드 | Euicc 관리 방법, euicc, sm 플랫폼 및 시스템 |
| US10165442B2 (en) * | 2014-05-29 | 2018-12-25 | Panasonic Intellectual Property Management Co., Ltd. | Transmission device, reception device, transmission method, and reception method |
| US10623952B2 (en) | 2014-07-07 | 2020-04-14 | Huawei Technologies Co., Ltd. | Method and apparatus for authorizing management for embedded universal integrated circuit card |
| US20170206722A1 (en) * | 2014-07-09 | 2017-07-20 | Deja View Concepts, Inc. | Bluetooth Low Energy for Access Control |
| US9734643B2 (en) * | 2014-07-10 | 2017-08-15 | Bank Of America Corporation | Accessing secure areas based on identification via personal device |
| US10332050B2 (en) | 2014-07-10 | 2019-06-25 | Bank Of America Corporation | Identifying personnel-staffing adjustments based on indoor positioning system detection of physical customer presence |
| US10108952B2 (en) | 2014-07-10 | 2018-10-23 | Bank Of America Corporation | Customer identification |
| US10074130B2 (en) | 2014-07-10 | 2018-09-11 | Bank Of America Corporation | Generating customer alerts based on indoor positioning system detection of physical customer presence |
| US10028081B2 (en) | 2014-07-10 | 2018-07-17 | Bank Of America Corporation | User authentication |
| CN104158659B (zh) * | 2014-07-21 | 2015-11-11 | 小米科技有限责任公司 | 防伪验证方法、装置和系统 |
| US9230085B1 (en) | 2014-07-29 | 2016-01-05 | Sprint Communications Company L.P. | Network based temporary trust extension to a remote or mobile device enabled via specialized cloud services |
| EP3195523B1 (en) * | 2014-08-20 | 2020-03-18 | Telefonaktiebolaget LM Ericsson (publ) | Methods, devices and management terminals for establishing a secure session with a service |
| US9531542B2 (en) | 2014-09-19 | 2016-12-27 | Bank Of America Corporation | Secure remote password |
| US9825937B2 (en) | 2014-09-23 | 2017-11-21 | Qualcomm Incorporated | Certificate-based authentication |
| US10225736B2 (en) | 2014-10-06 | 2019-03-05 | Lg Electronics Inc. | Method and apparatus for managing authentication in wireless communication system while subscriber identity module is not available |
| FR3027177B1 (fr) * | 2014-10-13 | 2016-11-04 | Morpho | Procede d'authentification d'un dispositif client aupres d'un serveur a l'aide d'un element secret |
| US9843446B2 (en) * | 2014-10-14 | 2017-12-12 | Dropbox, Inc. | System and method for rotating client security keys |
| PT107993B (pt) * | 2014-10-21 | 2016-11-11 | Inst De Telecomunicações | Método e sistema de autenticação de um domínio de operador 3gpp |
| US11399019B2 (en) * | 2014-10-24 | 2022-07-26 | Netflix, Inc. | Failure recovery mechanism to re-establish secured communications |
| US11533297B2 (en) | 2014-10-24 | 2022-12-20 | Netflix, Inc. | Secure communication channel with token renewal mechanism |
| US10050955B2 (en) | 2014-10-24 | 2018-08-14 | Netflix, Inc. | Efficient start-up for secured connections and related services |
| JP6380009B2 (ja) * | 2014-10-31 | 2018-08-29 | 株式会社リコー | 情報処理システム、認証方法、および情報処理装置 |
| US9820132B2 (en) | 2014-12-01 | 2017-11-14 | Nokia Technologies Oy | Wireless short-range discovery and connection setup using first and second wireless carrier |
| US10356053B1 (en) * | 2014-12-12 | 2019-07-16 | Charles Schwab & Co., Inc. | System and method for allowing access to an application or features thereof on each of one or more user devices |
| US10136283B2 (en) * | 2014-12-30 | 2018-11-20 | Stmicroelectronics S.R.L. | Methods for providing a response to a command requesting the execution of a proactive command |
| US9779232B1 (en) | 2015-01-14 | 2017-10-03 | Sprint Communications Company L.P. | Trusted code generation and verification to prevent fraud from maleficent external devices that capture data |
| EP3248359A4 (en) * | 2015-01-22 | 2018-09-05 | Visa International Service Association | Method and system for establishing a secure communication tunnel |
| US9838868B1 (en) | 2015-01-26 | 2017-12-05 | Sprint Communications Company L.P. | Mated universal serial bus (USB) wireless dongles configured with destination addresses |
| US9961074B2 (en) * | 2015-02-10 | 2018-05-01 | Dell Products, Lp | System and method for providing an authentication certificate for a wireless handheld device a data center environment |
| KR102001753B1 (ko) * | 2015-03-16 | 2019-10-01 | 콘비다 와이어리스, 엘엘씨 | 공개 키잉 메커니즘들을 사용한 서비스 계층에서의 종단간 인증 |
| US9473945B1 (en) | 2015-04-07 | 2016-10-18 | Sprint Communications Company L.P. | Infrastructure for secure short message transmission |
| WO2016162502A1 (en) * | 2015-04-08 | 2016-10-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, apparatus, and system for providing encryption or integrity protection in a wireless network |
| US9338147B1 (en) * | 2015-04-24 | 2016-05-10 | Extrahop Networks, Inc. | Secure communication secret sharing |
| US11057446B2 (en) | 2015-05-14 | 2021-07-06 | Bright Data Ltd. | System and method for streaming content from multiple servers |
| US9807083B2 (en) * | 2015-06-05 | 2017-10-31 | Sony Corporation | Distributed white list for security renewability |
| US9473941B1 (en) * | 2015-06-16 | 2016-10-18 | Nokia Technologies Oy | Method, apparatus, and computer program product for creating an authenticated relationship between wireless devices |
| US10230767B2 (en) | 2015-07-29 | 2019-03-12 | At&T Intellectual Property I, L.P. | Intra-carrier and inter-carrier network security system |
| JP5951094B1 (ja) * | 2015-09-07 | 2016-07-13 | ヤフー株式会社 | 生成装置、端末装置、生成方法、生成プログラム及び認証処理システム |
| JP6122924B2 (ja) | 2015-09-11 | 2017-04-26 | ヤフー株式会社 | 提供装置、端末装置、提供方法、提供プログラム及び認証処理システム |
| US9819679B1 (en) | 2015-09-14 | 2017-11-14 | Sprint Communications Company L.P. | Hardware assisted provenance proof of named data networking associated to device data, addresses, services, and servers |
| US10462116B1 (en) * | 2015-09-15 | 2019-10-29 | Amazon Technologies, Inc. | Detection of data exfiltration |
| CN106572066B (zh) * | 2015-10-10 | 2019-11-22 | 西安西电捷通无线网络通信股份有限公司 | 一种实体身份有效性验证方法及其装置 |
| US10282719B1 (en) | 2015-11-12 | 2019-05-07 | Sprint Communications Company L.P. | Secure and trusted device-based billing and charging process using privilege for network proxy authentication and audit |
| US9817992B1 (en) | 2015-11-20 | 2017-11-14 | Sprint Communications Company Lp. | System and method for secure USIM wireless network access |
| US10972262B2 (en) * | 2015-12-30 | 2021-04-06 | T-Mobile Usa, Inc. | Persona and device based certificate management |
| US10652023B2 (en) | 2015-12-30 | 2020-05-12 | T-Mobile Usa, Inc. | Persona and device based certificate management |
| JP6526248B2 (ja) | 2016-01-26 | 2019-06-12 | 株式会社ソラコム | サーバ及びプログラム |
| US10228926B2 (en) * | 2016-01-28 | 2019-03-12 | T-Mobile Usa, Inc. | Remote support installation mechanism |
| US10863558B2 (en) * | 2016-03-30 | 2020-12-08 | Schweitzer Engineering Laboratories, Inc. | Communication device for implementing trusted relationships in a software defined network |
| US10129228B1 (en) * | 2016-03-30 | 2018-11-13 | Amazon Technologies, Inc. | Authenticated communication between devices |
| US10104119B2 (en) * | 2016-05-11 | 2018-10-16 | Cisco Technology, Inc. | Short term certificate management during distributed denial of service attacks |
| US10362021B2 (en) * | 2016-05-31 | 2019-07-23 | Airwatch Llc | Device authentication based upon tunnel client network requests |
| CN106302414B (zh) * | 2016-08-04 | 2019-05-31 | 北京百度网讯科技有限公司 | 网站内容防抓取方法和装置 |
| CN107809411B (zh) * | 2016-09-09 | 2021-12-03 | 华为技术有限公司 | 移动网络的认证方法、终端设备、服务器和网络认证实体 |
| US11805107B2 (en) * | 2016-10-24 | 2023-10-31 | Nubeva, Inc. | Extracting encryption keys to enable monitoring services |
| US10609556B2 (en) * | 2016-10-31 | 2020-03-31 | Telefonaktiebolaget Lm Ericsson (Publ) | Authentication for next generation systems |
| EP3322149B1 (en) * | 2016-11-10 | 2023-09-13 | Tata Consultancy Services Limited | Customized map generation with real time messages and locations from concurrent users |
| US10218694B2 (en) | 2016-11-22 | 2019-02-26 | Bank Of America Corporation | Securely orchestrating events initiated at remote servers using a certificate server |
| US10645086B1 (en) * | 2016-12-30 | 2020-05-05 | Charles Schwab & Co., Inc. | System and method for handling user requests for web services |
| US10862885B2 (en) * | 2017-03-20 | 2020-12-08 | Forescout Technologies, Inc. | Device identification |
| US10476673B2 (en) | 2017-03-22 | 2019-11-12 | Extrahop Networks, Inc. | Managing session secrets for continuous packet capture systems |
| WO2018190854A1 (en) * | 2017-04-14 | 2018-10-18 | Giesecke+Devrient Mobile Security America, Inc. | Device and method for authenticating transport layer security communications |
| US11190504B1 (en) * | 2017-05-17 | 2021-11-30 | Amazon Technologies, Inc. | Certificate-based service authorization |
| US10499246B2 (en) | 2017-05-17 | 2019-12-03 | Verizon Patent And Licensing Inc. | Hardware identification-based security authentication service for IoT devices |
| US20190014095A1 (en) * | 2017-07-06 | 2019-01-10 | At&T Intellectual Property I, L.P. | Facilitating provisioning of an out-of-band pseudonym over a secure communication channel |
| US10788998B2 (en) | 2017-07-07 | 2020-09-29 | Sap Se | Logging changes to data stored in distributed data storage system |
| US10499249B1 (en) | 2017-07-11 | 2019-12-03 | Sprint Communications Company L.P. | Data link layer trust signaling in communication network |
| CN115038078A (zh) * | 2017-07-25 | 2022-09-09 | 瑞典爱立信有限公司 | 用于获得supi的认证服务器、ue及其方法和介质 |
| US11190374B2 (en) | 2017-08-28 | 2021-11-30 | Bright Data Ltd. | System and method for improving content fetching by selecting tunnel devices |
| EP3767494B1 (en) | 2017-08-28 | 2023-02-15 | Bright Data Ltd. | Method for improving content fetching by selecting tunnel devices |
| US9967292B1 (en) | 2017-10-25 | 2018-05-08 | Extrahop Networks, Inc. | Inline secret sharing |
| US20190182645A1 (en) * | 2017-12-08 | 2019-06-13 | Qualcomm Incorporated | Provisioning mechanism to trigger a subscription download at a user equipment |
| US10389574B1 (en) | 2018-02-07 | 2019-08-20 | Extrahop Networks, Inc. | Ranking alerts based on network monitoring |
| US10038611B1 (en) | 2018-02-08 | 2018-07-31 | Extrahop Networks, Inc. | Personalization of alerts based on network monitoring |
| US10270794B1 (en) | 2018-02-09 | 2019-04-23 | Extrahop Networks, Inc. | Detection of denial of service attacks |
| US10659054B2 (en) * | 2018-02-23 | 2020-05-19 | Nxp B.V. | Trusted monotonic counter using internal and external non-volatile memory |
| GB2573262B (en) * | 2018-03-08 | 2022-04-13 | Benefit Vantage Ltd | Mobile identification method based on SIM card and device-related parameters |
| BR112020020332A2 (pt) * | 2018-04-05 | 2021-01-05 | Nokia Technologies Oy | Gerenciamento de identificador de assinatura unificada em sistemas de comunicação |
| US11018930B2 (en) * | 2018-05-16 | 2021-05-25 | Vmware Inc. | Internet of things gateway onboarding |
| US10411978B1 (en) | 2018-08-09 | 2019-09-10 | Extrahop Networks, Inc. | Correlating causes and effects associated with network activity |
| US10594718B1 (en) | 2018-08-21 | 2020-03-17 | Extrahop Networks, Inc. | Managing incident response operations based on monitored network activity |
| CN109495441A (zh) * | 2018-09-10 | 2019-03-19 | 北京车和家信息技术有限公司 | 接入认证方法、装置、相关设备及计算机可读存储介质 |
| US11985567B2 (en) | 2018-09-12 | 2024-05-14 | Qualcomm Incorporated | Methods and systems for enhancement of positioning related protocols |
| US11068598B2 (en) * | 2018-11-01 | 2021-07-20 | Dell Products L.P. | Chassis internal device security |
| CN111147421B (zh) * | 2018-11-02 | 2023-06-16 | 中兴通讯股份有限公司 | 一种基于通用引导架构gba的认证方法及相关设备 |
| US20200154241A1 (en) * | 2018-11-08 | 2020-05-14 | Mediatek Inc. | Methods for reliable transmission of a supl init message |
| CN109714343B (zh) * | 2018-12-28 | 2022-02-22 | 北京天融信网络安全技术有限公司 | 一种网络流量异常的判断方法及装置 |
| US10820200B2 (en) * | 2019-01-14 | 2020-10-27 | T-Mobile Usa, Inc. | Framework for securing device activations |
| US11190521B2 (en) * | 2019-01-18 | 2021-11-30 | Vmware, Inc. | TLS policy enforcement at a tunnel gateway |
| US11212319B2 (en) | 2019-01-24 | 2021-12-28 | Zhnith Incorporated | Multiple sentinels for securing communications |
| JP7273523B2 (ja) * | 2019-01-25 | 2023-05-15 | 株式会社東芝 | 通信制御装置および通信制御システム |
| EP4075304B1 (en) | 2019-02-25 | 2023-06-28 | Bright Data Ltd. | System and method for url fetching retry mechanism |
| US11411922B2 (en) | 2019-04-02 | 2022-08-09 | Bright Data Ltd. | System and method for managing non-direct URL fetching service |
| US10965702B2 (en) | 2019-05-28 | 2021-03-30 | Extrahop Networks, Inc. | Detecting injection attacks using passive network monitoring |
| JP7298356B2 (ja) * | 2019-07-16 | 2023-06-27 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置及び情報処理プログラム |
| US11165814B2 (en) | 2019-07-29 | 2021-11-02 | Extrahop Networks, Inc. | Modifying triage information based on network monitoring |
| US10742530B1 (en) | 2019-08-05 | 2020-08-11 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
| US11388072B2 (en) | 2019-08-05 | 2022-07-12 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
| US11509642B2 (en) * | 2019-08-21 | 2022-11-22 | Truist Bank | Location-based mobile device authentication |
| US10742677B1 (en) | 2019-09-04 | 2020-08-11 | Extrahop Networks, Inc. | Automatic determination of user roles and asset types based on network monitoring |
| US11451959B2 (en) * | 2019-09-30 | 2022-09-20 | Fortinet, Inc. | Authenticating client devices in a wireless communication network with client-specific pre-shared keys |
| US11233859B2 (en) * | 2019-10-31 | 2022-01-25 | Arm Ip Limited | Machine-to-machine communications |
| CN111083631B (zh) * | 2019-12-02 | 2020-11-03 | 兰州交通大学 | 一种保护位置隐私和查询隐私的高效查询处理方法 |
| US11165823B2 (en) | 2019-12-17 | 2021-11-02 | Extrahop Networks, Inc. | Automated preemptive polymorphic deception |
| CN113132995B (zh) * | 2019-12-31 | 2023-04-07 | 中移智行网络科技有限公司 | 一种设备管控方法、装置、存储介质和计算机设备 |
| CN114040387B (zh) * | 2020-07-21 | 2024-06-04 | 中国移动通信有限公司研究院 | 一种攻击消息的确定方法、装置及设备 |
| US11411997B2 (en) * | 2020-08-13 | 2022-08-09 | Salesforce, Inc. | Active fingerprinting for transport layer security (TLS) servers |
| US11463466B2 (en) | 2020-09-23 | 2022-10-04 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
| US11310256B2 (en) | 2020-09-23 | 2022-04-19 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
| US11361630B1 (en) | 2020-11-20 | 2022-06-14 | Bank Of America Corporation | Identifying and logging mobile devices posing security threats |
| US11882452B2 (en) | 2020-11-20 | 2024-01-23 | Bank Of America Corporation | Monitoring for security threats associated with mobile devices that have been identified and logged |
| US20220182838A1 (en) * | 2020-12-08 | 2022-06-09 | Verizon Patent And Licensing Inc. | Systems and methods for obtaining a subscriber identity for an emergency call |
| CN112584350B (zh) * | 2020-12-10 | 2023-02-28 | 阿波罗智联(北京)科技有限公司 | 处理信息的方法、装置、设备及可读存储介质 |
| US20230396609A1 (en) * | 2021-02-26 | 2023-12-07 | Xero Limited | Multi-factor authentication |
| CN112906063B (zh) * | 2021-02-26 | 2024-04-26 | 杭州萤石软件有限公司 | 一种数字摘要算法处理设备方法、装置、系统及设备 |
| US11349861B1 (en) | 2021-06-18 | 2022-05-31 | Extrahop Networks, Inc. | Identifying network entities based on beaconing activity |
| US20230061362A1 (en) * | 2021-08-31 | 2023-03-02 | International Business Machines Corporation | Message delivery in cellular roaming scenarios |
| US11336564B1 (en) | 2021-09-01 | 2022-05-17 | Schweitzer Engineering Laboratories, Inc. | Detection of active hosts using parallel redundancy protocol in software defined networks |
| US11750502B2 (en) | 2021-09-01 | 2023-09-05 | Schweitzer Engineering Laboratories, Inc. | Detection of in-band software defined network controllers using parallel redundancy protocol |
| US11296967B1 (en) | 2021-09-23 | 2022-04-05 | Extrahop Networks, Inc. | Combining passive network analysis and active probing |
| CN113993131B (zh) * | 2021-10-28 | 2023-06-30 | 中国联合网络通信集团有限公司 | 访问控制方法及装置 |
| US20230137082A1 (en) * | 2021-10-31 | 2023-05-04 | Qualcomm Incorporated | Generic Bootstrapping Architecture (GBA) Signaling To Indicate Need For Key Renegotiation |
| US11843606B2 (en) | 2022-03-30 | 2023-12-12 | Extrahop Networks, Inc. | Detecting abnormal data access based on data similarity |
| CN116471081B (zh) * | 2023-04-18 | 2023-12-12 | 中国石油天然气股份有限公司辽宁销售分公司 | 一种基于物联网技术的室内安防匿名认证方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070287448A1 (en) * | 2006-06-09 | 2007-12-13 | Samsung Electronics Co. Ltd. | Method for Providing Triggered Location Information of a Target Terminal |
| JP2009505455A (ja) * | 2005-08-02 | 2009-02-05 | クゥアルコム・インコーポレイテッド | Ｖｏｉｐ緊急呼出支援 |
Family Cites Families (54)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU4781899A (en) * | 1998-07-03 | 2000-01-24 | Nokia Mobile Phones Limited | Secure session set up based on the wireless application protocol |
| JP2002074188A (ja) | 2000-06-16 | 2002-03-15 | Sony Computer Entertainment Inc | 会員情報登録方法および装置、会員認証方法および装置、サーバコンピュータ |
| US7120675B1 (en) | 2000-09-26 | 2006-10-10 | Microsoft Corporation | Information location service |
| GB2401293B (en) * | 2002-01-17 | 2004-12-22 | Toshiba Res Europ Ltd | Data transmission links |
| US7240366B2 (en) * | 2002-05-17 | 2007-07-03 | Microsoft Corporation | End-to-end authentication of session initiation protocol messages using certificates |
| US20050108520A1 (en) * | 2002-06-12 | 2005-05-19 | Sumitomo Heavy Industries, Ltd. | Authentication apparatus and method, network system, recording medium and computer program |
| US20040059941A1 (en) | 2002-09-19 | 2004-03-25 | Myfamily.Com, Inc. | Systems and methods for identifying users and providing access to information in a network environment |
| US7376834B2 (en) * | 2003-07-18 | 2008-05-20 | Palo Alto Research Center Incorporated | System and method for securely controlling communications |
| TWI290439B (en) * | 2005-11-09 | 2007-11-21 | Min-Chieh Su | Mobile communication terminal verification authorization system and method thereof |
| WO2005051033A1 (en) | 2003-11-13 | 2005-06-02 | Nokia Corporation | Ip-based mechanism for location service systems, methods, and devices |
| KR101119295B1 (ko) * | 2004-04-21 | 2012-03-16 | 삼성전자주식회사 | 네트워크에 독립적으로 구성된 측위 서버를 이용한이동단말기의 위치결정장치 및 그 방법 |
| US9723087B2 (en) * | 2004-08-03 | 2017-08-01 | Lg Electronics Inc. | User privacy management apparatus and method in mobile communications system |
| KR100575802B1 (ko) | 2004-09-13 | 2006-05-03 | 엘지전자 주식회사 | 위치 정보 시스템에서의 로밍 방법 및 시스템 |
| US7512967B2 (en) | 2004-12-29 | 2009-03-31 | Alcatel-Lucent Usa Inc. | User authentication in a conversion system |
| WO2006075856A1 (en) | 2005-01-17 | 2006-07-20 | Lg Electronics Inc. | Tls session management method in supl-based positioning system |
| KR100846868B1 (ko) * | 2005-01-17 | 2008-07-17 | 엘지전자 주식회사 | Ｓｕｐｌ 기반의 위치정보 시스템에서의 ｔｌｓ 세션관리방법 |
| KR100595714B1 (ko) | 2005-04-01 | 2006-07-03 | 엘지전자 주식회사 | Ｓｕｐｌ 기반의 위치정보 시스템에서 ｓｕｐｌ 초기화메시지 및 이를 이용한 ｓｕｐｌ 처리방법 |
| KR100878813B1 (ko) | 2005-04-29 | 2009-01-14 | 엘지전자 주식회사 | 위치정보 전송 방법 |
| CN100450297C (zh) * | 2005-07-25 | 2009-01-07 | 华为技术有限公司 | 一种基于安全的用户平面移动定位方法及系统 |
| US10178522B2 (en) | 2005-08-02 | 2019-01-08 | Qualcomm Incorporated | VoIP emergency call support |
| US8068056B2 (en) | 2005-08-25 | 2011-11-29 | Qualcomm Incorporated | Location reporting with secure user plane location (SUPL) |
| US9137770B2 (en) | 2005-09-15 | 2015-09-15 | Qualcomm Incorporated | Emergency circuit-mode call support |
| KR100748513B1 (ko) | 2005-10-07 | 2007-08-14 | 엘지전자 주식회사 | 위치 서비스 방법 및 시스템 |
| AU2006225248B2 (en) | 2005-10-10 | 2007-10-18 | Samsung Electronics Co., Ltd. | Location service-providing system and deferred location request service-providing method using previously computed location in location service-providing system |
| KR20070108301A (ko) | 2005-12-01 | 2007-11-09 | 엘지전자 주식회사 | 위치 기반의 통지를 위한 위치정보 시스템 및 그 방법 |
| JP4655951B2 (ja) * | 2006-02-06 | 2011-03-23 | ソニー株式会社 | 情報処理装置、情報記録媒体製造装置、情報記録媒体、および方法、並びにコンピュータ・プログラム |
| US7778639B2 (en) | 2006-04-06 | 2010-08-17 | Lg Electronics Inc. | Network-initiated area event triggered positioning method for roaming terminal in mobile communication system |
| US8478287B2 (en) | 2006-06-07 | 2013-07-02 | Samsung Electronics Co., Ltd. | Method for positioning target terminal while protecting privacy of user thereof |
| US8218512B2 (en) | 2006-06-14 | 2012-07-10 | Toshiba America Research, Inc. | Distribution of session keys to the selected multiple access points based on geo-location of APs |
| US9094784B2 (en) | 2006-10-10 | 2015-07-28 | Qualcomm Incorporated | Registration of a terminal with a location server for user plane location |
| US7974235B2 (en) * | 2006-11-13 | 2011-07-05 | Telecommunication Systems, Inc. | Secure location session manager |
| US8509140B2 (en) * | 2006-11-21 | 2013-08-13 | Honeywell International Inc. | System and method for transmitting information using aircraft as transmission relays |
| US9083745B2 (en) | 2007-03-12 | 2015-07-14 | Qualcomm Incorporated | Network independent location services |
| WO2008142581A2 (en) | 2007-04-05 | 2008-11-27 | Nokia Corporation | Method, apparatuses and program product for utilizing user datagram protocol instead of wireless datagram rotocol for sending supl message from a location platform |
| EP2210436A1 (en) * | 2007-10-05 | 2010-07-28 | InterDigital Technology Corporation | Techniques for secure channelization between uicc and a terminal |
| FR2958821A1 (fr) | 2007-12-11 | 2011-10-14 | Mediscs | Procede d'authentification d'un utilisateur |
| US8712439B2 (en) | 2008-01-11 | 2014-04-29 | Qualcomm Incorporated | Method and apparatus for using service capability information for user plane location |
| US8392980B1 (en) | 2008-08-22 | 2013-03-05 | Avaya Inc. | Trusted host list for TLS sessions |
| US20100146592A1 (en) * | 2008-12-04 | 2010-06-10 | Dell Products L. P. | Systems and methods for providing session continuity across a chassis management controller failover |
| JP5449788B2 (ja) * | 2009-01-23 | 2014-03-19 | 株式会社Ｎｔｔドコモ | 測位支援装置及び測位支援方法 |
| US8301160B2 (en) | 2009-03-16 | 2012-10-30 | Andrew Llc | System and method for SUPL roaming using a held client |
| TWI448139B (zh) | 2009-05-15 | 2014-08-01 | Chi Mei Comm Systems Inc | 用於手機遠端測試之伺服器及方法 |
| US8443202B2 (en) * | 2009-08-05 | 2013-05-14 | Daon Holdings Limited | Methods and systems for authenticating users |
| US8630622B2 (en) | 2009-12-07 | 2014-01-14 | At&T Mobility Ii Llc | Devices, systems and methods for location assistance verification |
| US8434142B2 (en) * | 2010-02-26 | 2013-04-30 | Telefonaktiebolaget L M Ericsson (Publ) | Method for mitigating on-path attacks in mobile IP network |
| US8874710B2 (en) | 2010-04-27 | 2014-10-28 | Nokia Corporation | Access network discovery |
| US10063642B2 (en) * | 2010-08-21 | 2018-08-28 | Qualcomm Incorporated | Method and apparatus for supporting location services via a generic location session |
| US8627422B2 (en) | 2010-11-06 | 2014-01-07 | Qualcomm Incorporated | Authentication in secure user plane location (SUPL) systems |
| US8631238B2 (en) * | 2010-12-17 | 2014-01-14 | Oracle International Corporation | Preventing race conditions in secure token exchange |
| US8352749B2 (en) | 2010-12-17 | 2013-01-08 | Google Inc. | Local trusted services manager for a contactless smart card |
| CA2762739C (en) | 2010-12-29 | 2021-01-12 | Bce Inc. | Method and system for transmitting a network-initiated message to a mobile device |
| US10009319B2 (en) | 2011-02-07 | 2018-06-26 | Qualcomm Incorporated | Methods, apparatuses and articles for identifying and authorizing location servers and location services using a proxy location server |
| US8738027B2 (en) | 2011-02-07 | 2014-05-27 | Qualcomm Incorporated | Methods and apparatus for identifying and authorizing location servers and location services |
| US8811939B2 (en) | 2011-02-07 | 2014-08-19 | Qualcomm Incorporated | Method and/or apparatus for location privacy via uniform resource identifier provisioning |
-
2011
- 2011-11-03 US US13/288,949 patent/US8627422B2/en active Active
- 2011-11-04 WO PCT/US2011/059455 patent/WO2012087435A1/en active Application Filing
- 2011-11-04 EP EP11788658.0A patent/EP2636203B1/en active Active
- 2011-11-04 CN CN201180064445.0A patent/CN103370915B/zh active Active
- 2011-11-04 JP JP2013537891A patent/JP5876063B2/ja active Active
- 2011-11-04 KR KR1020137014523A patent/KR101530538B1/ko active IP Right Grant
- 2011-11-04 KR KR1020147029822A patent/KR101869368B1/ko active IP Right Grant
- 2011-11-04 CN CN201610028131.XA patent/CN105491070B/zh active Active
-
2013
- 2013-12-04 US US14/097,077 patent/US9119065B2/en active Active
- 2013-12-04 US US14/097,070 patent/US9402177B2/en active Active
-
2015
- 2015-07-31 JP JP2015152192A patent/JP6185017B2/ja active Active
-
2016
- 2016-07-22 US US15/217,880 patent/US9706408B2/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009505455A (ja) * | 2005-08-02 | 2009-02-05 | クゥアルコム・インコーポレイテッド | Ｖｏｉｐ緊急呼出支援 |
| US20070287448A1 (en) * | 2006-06-09 | 2007-12-13 | Samsung Electronics Co. Ltd. | Method for Providing Triggered Location Information of a Target Terminal |
Non-Patent Citations (4)
| Title |
|---|
| JPN6015012400; Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ: "ＵｓｅｒＰｌａｎｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ" Ｖｅｒｓｉｏｎ ２．０， ＯＭＡ-ＴＳ-ＵＬＰ-Ｖ２＿０-２００８０６２７-Ｃ, 20080627, ｐ．２４-２６， ２０３-２１５， ２２３-２４９， ３９７-３９９, Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ［ｏｎｌｉｎｅ］ * |
| JPN6015012401; 池上 輝哉、加藤 清志、中村 暢達、平池 龍一: '"システム運用管理におけるＵＮＤＯ操作ユーザインタフェース"' 情報処理学会研究報告 Ｖｏｌ．２００４、Ｎｏ．１１５, 20041112, ｐ．７９-８６, 社団法人情報処理学会 * |
| JPN6015012402; Ｔｏｌｇａ Ｇｏｅｚｅ， Ｏｅｚｇｕｅｎ Ｂａｙｒａｋ， Ｍｅｔｉｎ Ｂａｒｕｔ， Ｍ． Ｏｇｕｚ Ｓｕｎａｙ: '"Ｓｅｃｕｒｅ Ｕｓｅｒ-Ｐｌａｎｅ Ｌｏｃａｔｉｏｎ （ＳＵＰＬ） Ａｒｃｈｉｔｅｃｔｕｒｅ Ｆｏｒ Ａｓｓｉｓｔｅｄ ＧＰＳ （Ａ-ＧＰＳ）"' ４ｔｈ Ａｄｖａｎｃｅｄ Ｓａｔｅｌｌｉｔｅ Ｍｏｂｉｌｅ Ｓｙｓｔｅｍｓ， ２００８ （ＡＳＮＳ ２００８） , 20080826, ｐ．２２９-２３４, ＩＥＥＥ * |
| JPN6015012403; ▲高▼橋 誠、青山 晋也、鈴木 喬: '"Ｔｅｃｈｎｏｌｏｇｙ Ｒｅｐｏｒｔｓ 国際ローミングＳＵＰＬによるＦＯＭＡ位置情報機能の開発 -現在位置確認機能-"' ＮＴＴ ＤＯＣＯＭＯテクニカル・ジャーナル Ｖｏｌ．１７、Ｎｏ．２, 20090701, ｐ．６-１０, 社団法人電気通信協会 * |
Also Published As
| Publication number | Publication date |
|---|---|
| US9119065B2 (en) | 2015-08-25 |
| US20160337861A1 (en) | 2016-11-17 |
| JP5876063B2 (ja) | 2016-03-02 |
| CN103370915B (zh) | 2016-12-07 |
| WO2012087435A1 (en) | 2012-06-28 |
| KR101869368B1 (ko) | 2018-06-21 |
| KR20130089655A (ko) | 2013-08-12 |
| CN103370915A (zh) | 2013-10-23 |
| JP2016007004A (ja) | 2016-01-14 |
| KR20140137454A (ko) | 2014-12-02 |
| EP2636203B1 (en) | 2020-10-21 |
| EP2636203A1 (en) | 2013-09-11 |
| US20140094147A1 (en) | 2014-04-03 |
| KR101530538B1 (ko) | 2015-06-22 |
| US9706408B2 (en) | 2017-07-11 |
| CN105491070A (zh) | 2016-04-13 |
| JP6185017B2 (ja) | 2017-08-23 |
| US20140093081A1 (en) | 2014-04-03 |
| US9402177B2 (en) | 2016-07-26 |
| US8627422B2 (en) | 2014-01-07 |
| US20130067552A1 (en) | 2013-03-14 |
| CN105491070B (zh) | 2019-10-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6185017B2 (ja) | セキュアユーザプレーンロケーション（ｓｕｐｌ）システムにおける認証 | |
| US20240064144A1 (en) | Security lifecycle management of devices in a communications network | |
| JP6759232B2 (ja) | 完全前方秘匿性を有する認証および鍵共有 | |
| KR101556046B1 (ko) | 통신 핸드오프 시나리오를 위한 인증 및 보안 채널 설정 | |
| KR101287309B1 (ko) | 홈 노드-ｂ 장치 및 보안 프로토콜 | |
| US9674219B2 (en) | Authenticating public land mobile networks to mobile stations | |
| CN110786031A (zh) | 用于5g切片标识符的隐私保护的方法和系统 | |
| US20160255502A1 (en) | Method and apparatus to perform device to device communication in wireless communication network | |
| WO2009030155A1 (en) | Method, system and apparatus for negotiating the security ability when a terminal is moving | |
| US20230354013A1 (en) | Secure communication method and device | |
| WO2019196766A1 (zh) | 通信方法和装置 | |
| Lei et al. | 5G security system design for all ages | |
| WO2018103732A1 (zh) | 一种紧急号码的配置、获取方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20131205 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20150331 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20150630 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20150731 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20151222 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160120 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5876063 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |