用于安全用户平面定位系统中的认证的方法和装置与流程

概括地说，本公开内容涉及安全用户平面定位(SUPL)系统中的认证。

背景技术：
技术的进步导致更小并且更强大的计算设备。例如，当前存在各种便携式个人计算设备，其中包括无线计算设备，诸如体积小、轻便并且易于用户携带的便携式无线电话、个人数字助理(PDA)、以及寻呼设备。更具体地说，诸如蜂窝电话和因特网协议(IP)电话之类的便携式无线电话能够在无线网络上传送语音和数据分组。此外，许多这种无线电话包括合并在其中的其它类型的设备。例如，无线电话还可以包括数字静态照相机、数字视频摄像机、数字录音机、以及音频文件播放器。无线电话还可以配有位置确定硬件/软件以能够进行基于位置的服务。例如，无线电话可以包括全球定位系统(GPS)收发机。无线电话还可以接收网络辅助定位信息(例如，基于在多个网络塔之间对无线电话的位置进行三角测量的定位信息)。安全用户平面定位(SUPL)是可以用于能够在无线通信系统中进行基于位置的服务的技术标准。SUPL架构可以包括两个组成部分：支持SUPL的终端(SET)和可以实现为网络可接入的服务器的SUPL定位平台(SLP)。在利用SUPL服务之前，可能要求SET和/或SLP彼此进行认证。然而，SUPL中的安全和认证可能取决于由SET所使用的接入网络。例如，第三代合作伙伴计划(3GPP)或3GPP2网络上的认证可以利用与微波接入全球互通(WiMAX)网络上的认证不同的安全机制。此外，SUPL2.0中可用的安全机制可能不完全支持使用诸如电气和电子工程师协会(IEEE)802.11(Wi-Fi)网络之类的其它可用网络，这可能使得基于SUPL的功能对于在室内或者经历较差蜂窝网络状况的无线电话不可用。

技术实现要素：
公开了SUPL系统中的认证的系统和方法。所公开的系统和方法可以针对包括3GPP、3GPP2、WiMAX和Wi-Fi网络的各种接入网络，支持SET和SLP之间的相互认证。所公开的技术可以使SUPL服务器和SET能够协商使用多种认证方法中的哪种。本文所公开的认证方法包括但不限于独立于接入网络类型的基于证书的认证。在具体实现中，基于证书的认证可以在认证期间使用传输层安全（TLS）以使得在SET和SLP之间能够进行安全通信。所公开的技术还将安全应用于SUPL会话发起和重发起。在附加实施例中，可以经由多标识符/密码对而不是经由基于证书的认证来执行认证。在特定实施例中，一种方法包括：在移动设备处存储特定于该移动设备的至少一个安全证书，其中，所述安全证书包括所述移动设备的设备标识符。该方法还包括：将所述至少一个安全证书发送到安全用户平面定位（SUPL）定位平台（SLP），以基于所述设备标识符与所存储的设备标识符的比较将所述移动设备认证为与SUPL用户相关联。在另一个特定实施例中，一种非暂时性处理器可读介质，其包括指令，当所述指令由处理器执行时，使所述处理器在SUPL服务器处生成要发送到移动设备的消息。所述消息包括：包括所述SUPL服务器的标识符和所述SUPL服务器的公钥的服务器证书；以及对所述移动设备的设备证书的请求。当所述指令由处理器执行时，还使所述处理器从所述移动设备接收包括所述移动设备的设备证书的应答。当所述指令由处理器执行时，还使所述处理器基于所述设备证书，将所述移动设备认证为与SUPL用户相关联。在另一个特定实施例中，一种装置包括处理器和耦合到所述处理器的存储器。所述存储器存储可由所述处理器执行以进行以下操作的指令：在SUPL服务器处，从移动设备接收由所述移动设备所支持的一个或多个TLS密码组的指示。所述指令还可由所述处理器执行以确定所述一个或多个TLS密码组是否包括由所述SUPL服务器支持的TLS预共享密钥（TLS-PSK）密码组。所述指令还可由所述处理器执行以响应于确定所述一个或多个TLS密码组包括由所述SUPL服务器所支持的所述TLS-PSK密码组，执行基于通用引导架构（GBA）的认证过程，以对所述移动设备进行认证。所述指令还可由所述处理器执行以响应于确定所述一个或多个TLS密码组不包括由所述SUPL服务器所支持的TLS-PSK密码组，确定所述SUPL服务器是否支持基于证书的认证方法。所述指令还可由所述处理器执行以响应于确定所述SUPL服务器支持所述基于证书的认证方法，执行基于证书的认证过程，所述基于证书的认证过程包括将服务器证书发送到所述移动设备，以及从所述移动设备接收设备证书。所述指令还可由所述处理器执行以响应于确定所述SUPL服务器不支持所述基于证书的认证方法，当所述移动设备连接到3GPP网络或者3GPP2网络时，执行基于交替客户端认证（ACA）的认证方法。在另一个特定实施例中，一种方法包括：在移动设备处从SUPL服务器接收会话发起消息（例如，包括SUPLINIT消息），以在所述SUPL服务器和所述移动设备之间发起SUPL会话。所述方法还包括：响应于所述移动设备在所述移动设备接收到所述会话发起消息之前从SUPL服务器接收到有效的会话发起消息密钥（例如，包括SUPL_INIT_ROOT_KEY），使用所述会话发起消息密钥对所述会话发起消息进行认证，以及响应于对所述会话发起消息的成功认证，发起与所述SUPL服务器的SUPL会话。在另一个特定实施例中，一种装置包括处理器和耦合到所述处理器的存储器。所述存储器存储可由所述处理器执行以进行以下操作的指令：在移动设备处从SUPL服务器接收会话重发起消息（例如，包括SUPLREINIT消息），以在所述SUPL服务器和所述移动设备之间继续SUPL会话（例如，通用SUPL会话（GSS））。所述指令还可由所述处理器执行以响应于所述移动设备在所述移动设备接收到所述会话重发起消息之前从所述SUPL服务器接收到有效会话发起消息密钥，使用所述会话发起消息密钥对所述会话重发起消息进行认证，以及响应于对所述会话重发起消息的成功认证，继续与所述SUPL服务器的所述SUPL会话。在另一个特定实施例中，一种方法包括从移动设备向SUPL服务器发送消息，其中，所述消息包括SUPLINIT根密钥状态参数（例如，指示SUPL_INIT_ROOT_KEY的状态）。例如，可以将所述SUPLINIT根密钥状态参数包括在所述消息的SET能力参数中。在另一个实施例中，一种方法包括将SUPLEND消息从SUPL服务器发送到移动设备，其中，所述SUPLEND消息包括SUPLINIT密钥响应参数（例如，提供新的SUPL_INIT_ROOT_KEY）。在另一个特定实施例中，一种方法包括将包括保护等级参数的SUPLINIT消息从SUPL服务器发送到移动设备。在另一个实施例中，一种方法包括将包括保护等级参数的SPULREINIT消息从SUPL服务器发送到移动设备。在另一个特定实施例中，一种方法包括在网页服务器处从支持SUPL的移动设备接收消息，其中，所述消息包括所述移动设备的安全证书。所述方法还包括在所述网页服务器处从所述移动设备接收用户标识信息，并且将所述用户标识信息认证为标识SUPL服务的授权用户。所述方法还包括将所述移动设备的所述安全证书发送到SUPL服务器，以使得所述SUPL服务器能够将所述移动设备认证为与所述SUPL服务的所述授权用户相关联。在另一个特定实施例中，一种方法包括在SUPL服务器处从移动设备接收所述第一标识符和所述第一密码。例如，可以在用户模式TLS认证过程期间接收第一标识符和第一密码。所述方法还包括将所述第一标识符和所述第一密码认证为与SUPL服务器的授权用户相关联。所述方法还包括将第二标识符和第二密码发送给所述移动设备以替代所述第一标识符和所述第一密码，其中，所述SUPL服务器配置为在从所述移动设备接收到所述第二标识符和所述第二密码之后与所述移动设备建立SUPL会话。由所公开的实施例中的至少一个所提供的特定优点包括在SUPL系统中独立于接入网络执行相互认证的能力。例如，所公开实施例中的一个或多个可以支持包括3GPP、3GPP2、WiMAX和Wi-Fi网络等的各种接入网络。作为另一个例子，所公开实施例中的一个或多个可以将安全应用于SUPL会话发起和重发起。在回顾了包括下列章节的整个申请之后，本公开内容的其它方面、优点和特征将变得显而易见：附图简要说明、详细说明和权利要求。附图说明图1是示出可操作以在SUPL环境中执行认证的系统的特定实施例的图；图2是示出在SUPL环境中协商认证方法的方法的特定实施例的流程图；图3是示出在SUPL环境中使用证书执行认证的方法的特定实施例的流程图；图4是示出在SUPL环境中使用证书执行认证的方法的另一个特定实施例的流程图；图5是示出在SUPL服务器和移动设备之间的消息传送的特定实施例的图；图6是示出在SUPL环境中的会话发起期间的认证的方法的特定实施例的流程图；图7是示出在SUPL环境中的会话重发起期间的认证的方法的特定实施例的流程图；图8是示出在SUPL环境中使用网页服务器和多个标识符/密码的认证的特定实施例的图；图9是示出在SUPL环境中使用网页服务器的认证的方法的特定实施例的流程图；图10是示出在SUPL环境中使用多个标识符/密码的认证的方法的特定实施例的流程图；以及图11是实现SET的无线设备的特定实施例的框图。具体实施方式参考图1，其示出了可操作以在安全用户平面定位（SUPL）环境中执行认证的系统的特定实施例，并且被概括地标记为100。系统100包括经由一个或多个接入网络（例如，说明性接入网络130）通信地耦接到移动设备120的SUPL服务器110。在特定实施例中，SUPL服务器110可以是SUPL定位平台（SLP），并且移动设备120可以是支持SUPL的终端（SET）。接入网络130可以是3GPP网络、3GPP2网络、WiMAX网络、Wi-Fi网络（例如，根据IEEE802.11标准进行操作的网络）、或者某些其它无线接入网络。在特定实施例中，移动设备120可以是无线电话。SUPL服务器110可以包括处理器111和耦接到处理器111的存储器112。在特定实施例中，存储器112可以存储可由处理器111执行的指令，其中，该指令代表各种逻辑模块、组件和应用。存储器112还可以存储SUPL服务器110的一个或多个安全证书。例如，存储器112可以存储用于SUPL服务器110的服务器证书113，其中，服务器证书113包括公钥114和服务器标识符（ID）115（例如，对应于SUPL服务器110的全球唯一标识符）。SUPL服务器110还可以具有对应于公钥114的私钥。存储器112还可以存储对应于认证逻辑116和传输层安全（TLS）加密/解密逻辑117的可执行指令。可以执行认证逻辑116，以对移动设备120进行认证。可以执行TLS加密/解密逻辑117，以对从SUPL服务器110发送到移动设备120的消息进行加密并且对从移动设备120发送到SUPL服务器110的消息进行解密。例如，可以使用服务器公钥114对从移动设备120传出的消息进行加密，并且可以使用对应于服务器公钥114的私钥对从移动设备120进入的消息进行解密。移动设备120可以包括处理器121和耦接到处理器121的存储器122。在特定实施例中，存储器122存储可由处理器121执行的指令，其中，该指令可以代表各种逻辑模块、组件和应用。存储器122还可以存储移动设备120的一个或多个安全证书。例如，存储器122可以存储用于移动设备120的设备证书123，其中，设备证书123包括公钥124和设备标识符（ID）125。移动设备120还可以具有对应于公钥124的私钥。设备ID125可以是国际移动设备标识（IMEI）、移动台标识（MSID）、序列号、或者可以是全球唯一的其它标识符。在特定实施例中，设备证书123可以存储在移动设备120的通用集成电路卡（UICC）处而不是存储器122中，或者除了存储器122之外还存储在移动设备120的UICC处。存储器122可以存储对应于认证逻辑126和传输层安全（TLS）加密/解密逻辑127的可执行指令。可以执行认证逻辑126，以在移动设备120处对SUPL服务器110进行认证。可以执行TLS加密/解密逻辑127，以对从移动设备120发送到SUPL服务器110的消息进行加密，并且对从SUPL服务器110发送到移动设备120的消息进行解密。例如，可以使用设备公钥124对从移动设备120传出的消息进行加密，并且可以使用对应于设备公钥124的私钥对进入移动设备120的消息进行解密。在特定实施例中，SUPL服务器110和移动设备120可以参与相互认证的过程。例如，在操作期间，移动设备120处的认证逻辑126可以确定移动设备120是否支持基于通用引导架构（GBA）的认证。如果移动设备120支持基于GBA的认证，则移动设备120和SUPL服务器110可以执行基于GBA的认证过程134。当接入网络130是3GPP或者3GPP2网络时，可以选择基于GBA的认证。移动设备120可以通过向SUPL服务器110发送消息131来发起TLS握手过程。消息131可以指示由移动设备120处的TLS加密/解密逻辑127所支持的一个或多个TLS密码组。例如，消息131可以是客户端问候（ClientHello）消息，并且所支持的TLS密码组可以由ClientHello.cipher_suites字段来指示。SUPL服务器110可以对消息131进行处理，并且确定所指示的TLS密码组中任何一个SUPL是否也被服务器110支持（即，是否存在任何共同支持的TLS密码组）。如果移动设备120和SUPL服务器110都支持TLS预共享密钥（TLS-PSK）密码组，则可以支持GBA，并且SUPL服务器110可以执行基于GBA的认证过程134。否则，SUPL服务器110可以经由消息132发起基于证书的认证，或者可以发起交替客户端认证（ACA）。ACA可以提供相互认证，并且可以取决于所使用的接入网络的类型（例如，GSM/UMTS和CDMA）。在ACA认证期间，SUPL服务器110可以通过将由移动设备120所提供的IP地址与由接入网络130所提供的对应于移动设备120的IP地址进行比较，来验证移动设备120的因特网协议（IP）地址绑定。基于证书的认证可以独立于接入网络130的类型，并且可以在接入网络130是Wi-Fi网络时使用。消息132可以包括由SUPL服务器110和移动设备120所支持的非PSKTLS密码组的指示、服务器证书113（其包括服务器公钥114）、以及对设备证书的请求。为了说明，消息132可以包括服务器问候消息（ServerHello），服务器问候消息包括指示共同支持的TLS密码组的ServerHello.cipher_suite字段。响应于消息132，移动设备120可以发送包括设备证书123的消息133。SUPL服务器110可以通过将设备证书123中的设备ID125与所存储的设备ID（例如，如参考图8-9进一步所描述的，所存储的先前由SUPL服务器110安全地验证为与SUPL用户相关联的设备ID）进行比较，来尝试识别与移动设备120相关联的SUPL用户。如果没有识别出SUPL用户，则可以终止SUPL服务器110和移动终端120之间的通信会话。如果识别出SUPL用户，则TLS握手可以完成，并且SUPL服务器110可以授权移动设备120接入为SUPL用户提供的基于SUPL的服务（例如，基于位置的服务。）在特定实施例中，还可以利用不同的认证方法。例如，当移动设备120是WiMAX兼容设备和/或接入网络是WiMAX网络时，如果移动设备120和SUPL服务器110都支持基于SUPL加密密钥（SEK）的认证方法，则基于SEK的认证方法对于SUPL服务器110和移动设备120的相互认证可以是优选的。作为另一个例子，如果SUPL服务器110不支持基于证书的认证，则SUPL服务器110可以在不请求设备证书的情况下发送消息132，以发起不同的认证方法，诸如ACA（当移动设备120在3GPP或者3GPP2接入网络上时，ACA可以提供依赖于接入网络的相互认证）或仅SLP认证（其可以提供非相互认证，并且通常可以仅在紧急情况期间使用）。因此，图1的系统100可以能够独立于接入网络在移动设备和SUPL服务器之间进行相互认证。例如，接入网络130可以是3GPP网络、3GPP2网络、WiMAX网络、Wi-Fi网络、或者某些其它网络。图1的系统100还可以提供对多种相互认证方法的支持，包括基于GBA的认证、基于SEK的认证、基于证书的认证、基于ACA的认证、以及仅SLP认证。参考图2，示出了在SUPL环境中对认证方法进行协商的方法的特定实施例，并且被概括地标记为200。在说明性实施例中，方法200可以由图1的SUPL服务器110来执行。方法200可以包括：在202，在SUPL服务器处从移动设备接收由该移动设备所支持的一个或多个TLS密码组的指示。例如，在图1中，SUPL服务器110可以从移动设备120接收消息131，其中，消息131指示由移动设备120所支持的一个或多个TLS密码组。方法200还可以包括：在204，确定由移动设备所指示的至少一个TLS-PSK密码组是否也被SUPL服务器支持。例如，在图1中，SUPL服务器110可以确定由移动设备120所支持的任何TLS-PSK密码组是否也被SUPL服务器110支持。响应于在204确定TLS-PSK密码组是被SUPL服务器和移动设备所共同支持的，在206，可以执行基于GBA的认证过程来对移动设备进行认证。例如，在图1中，SUPL服务器110可以执行基于GBA的认证过程134。响应于在204确定TLS-PSK密码组不被SUPL服务器和移动设备所共同支持，在208，可以执行基于证书的认证过程。基于证书的过程可以包括向移动设备发送服务器证书，以及从移动设备接收设备证书，并且可以独立于由移动设备所使用的接入网络。例如，在图1中，SUPL服务器110可以执行基于证书的认证过程，其中包括经由消息132将服务器证书113发送到移动设备120，并且经由消息133从移动设备120接收设备证书123。在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图2的方法200。作为例子，图2的方法200可以由执行指令的处理器来执行。参考图3，示出了在SUPL环境中使用证书执行认证的方法的特定实施例，并且被概括地标记为300。在说明性实施例中，方法300可以由图1的移动设备120来执行。方法300可以包括：在302，在移动设备处存储特定于该移动设备的至少一个安全证书。该至少一个安全证书可以包括移动设备的设备标识符。例如，在图1中，移动设备120可以存储包含设备ID125（例如，IMEI、MSID、序列号、或者另一全球唯一标识符）的设备证书123。方法300还可以包括：在304，将至少一个安全证书发送到SUPL定位平台（SLP），以基于设备标识符与所存储的设备标识符的比较将移动设备认证为与SUPL用户相关联。例如，在图1中，移动设备120可以经由消息133将设备证书123发送到SUPL服务器110（例如，SLP），使得SUPL服务器110能够基于设备ID125与所存储的先前由另一实体提供的设备ID的比较来将移动设备120认证为与SUPL用户相关联。在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图3的方法300。作为例子，图3的方法300可以由执行指令的处理器来执行。参考图4，示出了在SUPL环境中使用证书执行认证的方法的另一特定实施例，并且概括地标记为400。在说明性实施例中，方法400可以由图1的SUPL服务器110执行。方法400可以包括：在402，在SUPL服务器处从移动设备接收由该移动设备所支持的一个或多个TLS密码组的指示。例如，在图1中，SUPL服务器110可以从移动设备120接收消息131，其中，消息131指示由移动设备120所支持的一个或多个TLS密码组。方法400还可以包括：在404，从SUPL服务器向移动设备发送消息。该消息可以包括：服务器证书，其包括SUPL服务器的标识符和SUPL服务器的公钥；对移动设备的设备证书的请求；以及至少一个TLS密码组的选择。例如，在图1中，SUPL服务器110可以将消息132发送到移动设备120，其中，消息132包括服务器ID115、服务器公钥114、对移动设备120的设备证书123的请求、以及共同支持的TLS密码组的选择。方法400还可以包括：在406，从移动设备接收包括该移动设备的设备证书的应答。例如，在图1中，SUPL服务器110可以接收包括设备证书123的消息133。方法400可以包括：在408，基于设备证书将移动设备认证为与SUPL用户相关联。例如，在图1中，SUPL服务器110处的认证逻辑116可以基于设备证书123，将移动设备120认证为与SUPL用户相关联。在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合来实现图4的方法400。作为例子，图4的方法400可以由执行指令的处理器执行。无论使用参考图1-4所描述的哪个认证方法，一旦完成认证，则SUPL服务器（例如，SLP）和移动设备（例如，SET）可以在SUPL会话期间进行有关于基于SUPL的服务的通信。参考图5，示出了可以在SUPL服务器510和移动设备520之间进行交换的消息的特定实施例，并且概括地标记为500。在特定实施例中，SUPL服务器510和移动设备520可以在SUPL会话的上下文中，经由用户定位协议（ULP）消息进行通信。例如，SUPL服务器510可以配置为将SUPLINIT消息530发送到移动设备520。SUPLINIT消息530可以代表由SUPL服务器110所发送以发起SUPL会话的会话发起消息。为了预防伪装和重放攻击，可以将保用应用于SUPLINIT消息530。在特定实施例中，SUPLINIT消息530可以包括保护等级参数。保护等级参数可以包括等级参数（其指示是实施空、模式A、还是模式BSUPLINIT保护）和保护参数（例如，包括密钥标识符类型和密钥标识符中的至少一个）中的至少一个。在特定实施例中，空SUPLINIT保护不可以提供端到端完整性或者重放保护，模式ASUPLINIT保护可以通过使用由SUPL服务器510在安全ULP会话期间发送到移动设备520的共享密钥来提供端到端完整性和重放保护，而模式BSUPLINIT保护可以使用从基于PSK的方法（例如，GBA或者SEK方法）得到的共享密钥来提供端到端完整性和重放保护。在特定实施例中，可以基于会话发起密钥（例如，SUPL_INIT_ROOT_KEY）来实现SUPLINIT保护。在接收到SUPLINIT消息530之后，移动设备520可以确定移动设备520先前是否从SUPL服务器510接收到有效的SUPL_INIT_ROOT_KEY，并且如果如此，该先前接收的SUPL_INIT_ROOT_KEY是否仍然有效。如果移动设备520具有有效的SUPL_INIT_ROOT_KEY，则移动设备520可以使用该SUPL_INIT_ROOT_KEY来对SUPLINIT消息530进行认证，并且响应于对SUPLINIT消息530的成功认证，可以发起与SUPL服务器510的SUPL会话。在特定实施例中，如果移动设备520不具有有效的SUPL_INIT_ROOT_KEY，则移动设备520可以向SUPL服务器510发送消息，并且可以响应于该消息，接收有效的SUPL_INIT_ROOT_KEY。例如，移动设备520可以发送包括SUPL_INIT_KEYREQUEST参数的消息，其代表对有效SUPL_INIT_ROOT_KEY的请求。替代地，移动设备520可以指示存在无效或者不同步的SUPL_INIT_ROOT_KEY，而不是请求新的SUPL_INIT_ROOT_KEY。例如，移动设备520可以发送包括SUPLINIT根密钥状态参数541的ULP消息540，其指示由移动设备520所拥有的“当前”SUPL_INIT_ROOT_KEY是无效的还是不同步的。在特定实施例中，可以将SUPLINIT根密钥状态参数541包括在ULP消息540的SET能力参数内。将意识到的是，将SUPLINIT根密钥状态参数541包括在SET能力参数内可以使得能够在SUPL2.0中所定义的消息中的传输SUPL_INIT_ROOT_KEY状态信息，其中该消息选择性地或者强制性地包括SET能力参数，而不必出于发送SUPL_INIT_ROOT_KEY状态信息的目的引入专用消息。在特定实施例中，针对模式ASUPLINIT保护，但是不针对空保护或者模式BSUPLINIT保护，可以将SUPLINIT根密钥状态参数541包括在SET能力参数内。应该注意到的是，移动设备520可以不针对每个网络发起的SUPL会话指示无效的SUPL_INIT_ROOT_KEY。可以向移动设备520提供SUPL_INIT_ROOT_KEY一次，并且随后，在密钥期满之前，所提供的密钥可以针对多个网络发起的SUPL会话是有效的。SUPL服务器510可以发送包括SUPLINIT密钥响应参数的ULP消息。例如，SUPL服务器510可以发送包括SUPLINIT密钥响应参数551的SUPLEND消息550。应该注意到的是，可以不直接响应于SUPLINIT根密钥状态指示而发送SUPLINIT密钥响应；SUPLINIT密钥响应可以在“常规”SUPLEND消息中，该“常规”SUPLEND消息可以不在同一个SUPL会话中（例如，如果该SUPL会话不是以从SLP到SET的SUPLEND消息结束的）。SUPLINIT密钥响应参数551可以包括模式A密钥标识符、临时模式A密钥标识符、SUPL_INIT_ROOT_KEY（例如，“新的”SUPL_INIT_ROOT_KEY）和模式A密钥有效期中的至少一个。当通用SUPL会话（GSS）是活动的时，SLP（即，SUPL服务器510）可以发起与SET（即，移动设备520）的通信。SUPL服务器510可以发送会话重发起消息（例如，SUPLREINIT消息560）。可以按照本文参照SUPLINIT保护所描述的来实现SUPLREINIT保护。例如，如果移动设备520不拥有有效的SUPL_INIT_ROOT_KEY（该SUPL_INIT_ROOT_KEY可以用作会话发起密钥以及会话重发起密钥两者），则移动设备520可以经由SUPLINIT根密钥状态参数541指示缺乏有效的SUPL_INIT_ROOT_KEY，并且可以接收作为响应的SUPLEND消息550（包括SUPLINIT密钥响应参数551）。当移动设备520具有有效的SUPL_INIT_ROOT_KEY时，移动设备520可以对SUPLREINIT消息560进行认证，并且可以响应于对SUPLREINIT消息560的成功认证，重发起与SUPL服务器510的SUPL会话。在特定实施例中，SUPLREINIT消息560还可以包括诸如本文参考SUPLINIT消息530所描述的保护等级参数。在特定实施例中，当移动设备520不具有有效SUPL_INIT_ROOT_KEY时（例如，在加电时或者当所拥有的SUPL_INIT_ROOT_KEY的有效期期满时），移动设备520可以应用空SUPLINIT保护和空SUPLREINIT保护。当设置了空保护时，移动设备520可以处理所有SUPLINIT和SUPLREINIT消息。如果移动设备520具有有效的SUPL_INIT_ROOT_KEY，则可以应用模式A或者模式B保护。因此，如在图5中所示出的，可以使用各种消息和消息参数来实现SUPL系统中的安全。例如，可以使用保护等级参数来指示SUPLINIT和SUPLREINIT保护的等级。作为另一个例子，可以使用SUPLINIT根密钥状态参数来指示当前的SUPL_INIT_ROOT_KEY是无效的还是不同步的。作为另一个例子，可以使用SUPLINIT密钥响应参数来提供“新的”SUPL_INIT_ROOT_KEY。参考图6，示出了在SUPL环境中会话发起期间的认证的方法的特定实施例，并且被概括地标记为600。在说明性实施例中，方法600可以由图5的移动设备520执行。方法600可以包括：在602，在移动设备处从安全用户平面定位（SUPL）服务器接收会话发起消息，以在SUPL服务器和移动设备之间发起SUPL会话。例如，在图5中，移动设备520可以从SUPL服务器510接收SUPLINIT消息530。方法600还可以包括：在604，在接收会话发起消息之前确定移动设备是否接收到有效的会话发起消息密钥。例如，在图5中，移动设备520可以确定其是否拥有有效的SUPL_INIT_ROOT_KEY。当移动设备具有有效的会话发起消息密钥时，方法600还可以包括：在606，使用会话发起消息密钥（例如，SUPL_INIT_ROOT_KEY）对会话发起消息进行认证，以及在608，响应于对会话发起消息的成功认证，发起与SUPL服务器的SUPL会话。例如，在图5中，移动设备520可以使用有效的SUPL_INIT_ROOT_KEY对SUPLINIT消息530进行认证，并且可以发起与SUPL服务器510的SUPL会话。当移动设备不具有有效的会话发起消息密钥时，方法600可以包括：在610，向SUPL服务器发送消息，以及在612，响应于该消息，从SUPL服务器接收会话发起消息。为了说明，SLP和SET可以采用空SUPLINIT保护进行会话，并且SET可以在其SUPL_INIT_ROOT_KEY是无效的会话期间发送指示。例如，在图5中，移动设备520可以将包括SUPLINIT根密钥状态参数541的消息发送到SUPL服务器510，并且可以接收作为响应的包括SUPLINIT密钥响应参数551的消息。在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图6的方法600。作为例子，图6的方法600可以由执行指令的处理器执行。参考图7，示出了在SUPL环境中在会话重发起期间的认证的方法的特定实施例，并且被概括地标记为700。在说明性实施例中，方法700可以由图5的移动设备520执行。方法700可以包括：在702，在移动设备处从安全用户平面定位（SUPL）服务器接收会话重发起消息，以继续在SUPL服务器和移动设备之间进行SUPL会话。例如，在图5中，移动设备520可以从SUPL服务器510接收SUPLREINIT消息560。SUPLREINIT消息560可以代表网络发起的用以继续SUPL服务器510和移动设备520之间的现有的通用SUPL会话（GSS）的尝试。方法700还可以包括：在704，确定移动设备在接收到会话重发起消息之前是否接收到有效的会话发起消息。例如，在图5中，移动设备520可以确定其是否拥有有效的SUPL_INIT_ROOT_KEY。当移动设备具有有效的会话发起消息密钥时，方法700还可以包括：在706，使用会话发起消息密钥对会话重发起消息进行认证，以及在708，响应于对会话重发起消息的成功认证，继续与SUPL服务器的SUPL会话。例如，在图5中，移动设备520可以使用有效的SUPL_INIT_ROOT_KEY对SUPLREINIT消息560进行认证，并且可以重发起与SUPL服务器510的SUPL会话。当移动设备不具有有效的会话发起消息密钥时，方法700可以包括：在710，向SUPL服务器发送消息，以及在712，响应于该消息，从SUPL服务器接收会话发起消息密钥。为了说明，SLP和SET可以采用空SUPLINIT保护进行会话，并且SET可以在其SUPL_INIT_ROOT_KEY是无效的会话期间发送指示。例如，在图5中，移动设备520可以将包括SUPLINIT根密钥状态参数541的消息发送到SUPL服务器510，并且可以接收作为响应的包括SUPLINIT密钥响应参数551的消息。在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图7的方法700。作为例子，图7的方法700可以由执行指令的处理器执行。在特定实施例中，可以经由与基于证书、基于GBA、基于SEK、基于ACA、以及仅SLP的方法不同的方法来执行移动设备和SUPL服务器之间的相互认证。例如，图8示出了可操作以在SUPL环境中使用多个标识符/密码来执行认证的系统800的特定实施例。系统800包括能够与SUPL服务器（例如，SLP）820进行通信的移动设备810（例如，SET）。除了基于多个标识符/密码进行认证之外，图8的系统800还示出了将设备证书绑定到SUPL用户的特定例子。例如，系统800可以包括网页服务器830，其提供了在设备证书和SUPL用户之间创建绑定的机制。应该注意到的是，网页服务器830可以不为SUPL会话提供认证，而是提供随后可以在SUPL认证期间由SLP使用的绑定信息。该绑定通常可以仅执行一次，并且可以在SET能够参与SUPL会话之前执行。一旦执行了绑定，可以将设备证书和用户信息的组合发送到SLP，并且SLP可以存储该信息并且使用其用于客户端认证。因此，在执行绑定之后，SLP可以“知道”特定的移动设备属于特定的SUPL用户。网页服务器830可以包括处理器831和存储器832，存储器832存储可由处理器831执行的指令。例如，该指令可以代表认证逻辑833。网页服务器830还可以包括网络接口834，网络接口834可操作以与移动设备810以及与SUPL服务器820进行通信。应该注意到，网页服务器830仅是如何向用户提供设备证书绑定的一个例子。在其它实施例中，可以使用其它绑定机制。或者，网页服务器830可以存储设备证书和用户信息的组合，并且SLP（在使用设备证书执行了相互认证之后）可以要求网页服务器830提供与该设备证书相关联的用户信息。移动设备810可以包括认证逻辑811（例如，存储在移动设备810的存储器中并且可由移动设备810的处理器执行的指令）。认证逻辑811可以配置为与网页服务器830处相应的认证逻辑833进行通信，以将移动设备810与特定的SUPL用户相关联（例如，“绑定”或者“注册”）。例如，绑定过程可以开始于移动设备810从网页服务器830接收消息835，其中，消息835包括网页服务器830的服务器证书和网页服务器830的公钥。移动设备810可以通过向网页服务器830发送消息813来进行响应，其中，消息813包括移动设备810的安全证书。例如，移动设备810的安全证书可以包括设备证书，该设备证书包括移动设备810的公钥、国际移动设备标识（IMEI）、移动站标识（MSID）、和/或序列号。移动设备810还可以将包括用户标识信息（例如，与SUPL用户相关联的用户标识符和密码）的消息814发送到网页服务器830。可以使用网页服务器830的公钥对消息813、814中的一者或二者进行加密，并且网页服务器830可以使用网页服务器830的私钥对经加密的消息进行解密。网页服务器830可以对由移动设备810所提供的用户标识信息进行认证，以确定该用户标识信息是否与SUPL服务的授权用户相关联。例如，网页服务器830可以将所提供的用户标识信息与位于或者可接入网络页服务器830的SUPL用户数据库进行比较。在验证了用户标识信息，网页服务器830可以通过发送消息836至SUPL服务器820以将移动设备810认证为与SUPL服务的授权用户相关联来完成绑定过程。消息836可以包括移动设备810的安全证书（例如，包含设备公钥和IMEI、MSID和/或序列号的设备证书）。移动设备810的认证逻辑811还可以配置为与SUPL服务器820处的相应的认证逻辑821进行通信，以在SUPL会话的开始或者重新开始之前执行基于用户模式TLS的相互认证。例如，移动设备810可以发送消息815至SUPL服务器820，其中，消息815包括第一标识符和第一密码。在特定实施例中，第一密码可以是用户选择的，并且可能具有相对较低的加密强度。在说明性实施例中，第一标识符和第一密码可以对应于由移动设备810经由消息814发送到网页服务器830的标识符和密码。在接收到第一标识符和第一密码之后，认证逻辑821可以将第一标识符和第一密码认证为与SUPL服务器的授权用户相关联。例如，认证逻辑821可以验证第一标识符和第一密码对应于之前绑定到移动设备810的授权用户。当认证成功时，SUPL服务器820处的标识符/密码生成逻辑822可以生成第二标识符和第二密码以代替第一标识符和第一密码。在特定实施例中，第二密码可以具有比第一密码更高的加密强度。SUPL服务器820可以经由消息824将第二标识符和第二密码发送给移动设备810。在随后从移动设备810接收到第二标识符和第二密码之后，SUPL服务器820可以与移动设备810建立SUPL会话。在特定实施例中，出于安全目的，可以保持向移动设备810的用户隐藏第二标识符和第二密码。虽然前面的描述涉及与单个移动设备（例如，SET）相关联的SUPL用户，但是SUPL用户可以与多个设备相关联。例如，与移动设备810相关联的SUPL用户还可以具有对第二移动设备840的接入。为了对第二移动设备840进行授权，SUPL用户可以以类似于绑定第一移动设备810的方式将第二移动设备840绑定至他或者她的账号（例如，SUPL账号）。为了在将第二移动设备840绑定到SUPL用户账号之后执行相互认证，第二移动设备840可以将包括第一标识符和第二密码的消息841发送给SUPL服务器820。在将第一标识符和第一密码认证为与授权SUPL用户相关联之后，SUPL服务器820可以确定是否也应该授权第二移动设备840接入SUPL服务。例如，SUPL服务器820可以实现设备每用户的限制，并且可以确定允许第二移动设备840接入SUPL服务是否将超过与准许接入SUPL服务的授权用户相关联的移动设备的阈值数目。如果允许第二移动设备840接入SUPL服务不会超过阈值，则SUPL服务器820可以将包括第三标识符和加密性强的第三密码的消息825发送到第二移动设备840。第三标识符和第三密码可以代替第一标识符和第一密码，并且可以由第二移动设备840随后用于开始SUPL会话。在特定实施例中，第三标识符和第三密码可以与发送到第一移动设备810的第二标识符和第二密码不同。通过向SUPL用户的每个移动设备提供不同的标识符/密码的组合，SUPL服务器820可以在每设备基础上实现监测。例如，SUPL服务器820处的监测逻辑823可以配置为对由使用第二标识符的第一移动设备810对SUPL服务的使用进行监测，并且对由使用第三标识符的第二移动设备840对SUPL服务的使用进行监测。因此，图8的系统800可以提供绑定过程，通过该绑定过程将一个或多个移动设备与特定SUPL用户进行绑定、注册和/或相关联。将意识到的是，所描述的绑定过程可以选择性地补充参考图1-4所描述的认证过程。例如，如参考图1-4所描述的，SUPL服务器110可以通过将移动设备的设备ID125与所存储的之前由SUPL用户所安全验证的设备ID进行比较，来尝试将SUPL用户识别为与移动设备120相关联。在说明性实施例中，图1的SUPL服务器110可以是SUPL服务器820，图1的移动设备120可以是移动设备810，并且可以将所存储的设备ID包括在绑定过程期间经由消息836提供给SUPL服务器820的设备安全证书中。另外，图8的系统800可以提供认证过程，该认证过程可以选择性地代替参考图1-4所描述的认证过程。例如，特定实施例可以包括使用图8的多标识符/密码认证过程，代替基于GBA的相互认证、基于SEK的相互认证和/或基于认证的相互认证。参考图9，示出了在SUPL环境中使用网页服务器进行认证的方法的特定实施例，并且被概括地标记为900。在说明性实施例中，方法900可以由图8的网页服务器830执行。方法900可以包括：在902，从网页服务器向支持SUPL的移动设备发送服务器证书。该服务器证书可以包括网页服务器的公钥。例如，在图8中，网页服务器830可以将消息835发送给移动设备810，其中，消息835包括网页服务器830的证书和公钥。方法900还可以包括：在904，在网页服务器处从移动设备接收包括该移动设备的安全证书的消息。例如，在图8中，网页服务器830可以从移动设备810接收消息813，其中，消息813包括移动设备810的安全证书（例如，设备证书和设备公钥）。方法900还可以包括：在906，使用网页服务器的私钥对消息进行解密，以及在908，从移动设备接收用户标识信息。例如，在图8中，网页服务器830可以使用私钥对消息813进行解密，并且可以经由消息814从移动设备810接收用户标识信息（例如，标识符和密码）。可替换地或者另外，还可以使用网页服务器的私钥对用户标识信息进行解密。方法900可以包括：在910，将用户标识信息认证为标识SUPL服务器的授权用户，以及在912，将移动设备的安全证书发送给SUPL服务器，以使得SUPL服务器能够将该移动设备认证为与SUPL服务的授权用户相关联。例如，在图8中，网页服务器830可以将用户标识信息认证为标识授权的SUPL用户，并且可以经由消息836将设备安全证书发送到SUPL服务器820。在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图9的方法900。作为例子，图9的方法900可以由执行指令的处理器执行。参考图10，使出了在SUPL环境中使用多个标识符/密码进行认证的方法的特定实施例，并且被概括地标记为1000。在说明性实施例中，方法1000可以由图8的SUPL服务器820执行。方法1000可以包括：在1002，在SUPL服务器处从移动设备接收第一标识符和第一密码，以及在1004，将第一标识符和第一密码认证为与SUPL服务的授权用户相关联。例如，在图8中，SUPL服务器可以经由消息815从移动设备810接收第一标识符和第一密码，并且可以将第一标识符和第一密码认证为与授权用户（例如，之前绑定到移动设备810的授权用户）相关联。方法1000还可以包括：在1006，将第二标识符和第二密码发送到移动设备以代替第一标识符和第一密码。SUPL服务器可以配置为在从移动设备接收到第二标识符和第二密码之后，与该移动设备建立SUPL会话。例如，在图8中，SUPL服务器820可以生成第二标识符和第二密码，并且经由消息824将第二标识符和第二密码发送到移动设备810，并且在移动设备810随后接收到第二标识符和第二密码之后，可以与移动设备810建立SUPL会话。方法1000还可以包括：在1008，在SUPL服务器处从第二移动设备接收第一标识符和第一密码，以及在1010，将第一标识符和第一密码认证为与SUPL服务的授权用户相关联。例如，在图8中，SUPL服务器820可以经由消息841从第二移动设备840接收第一标识符和第一密码，并且可以将第一标识符和第一密码认证为与授权用户相关联。为了说明，还可以经由图9的方法900将第二移动设备840预先绑定到授权用户。方法1000可以包括：在1012，确定允许第二移动设备接入SUPL服务是否将超过与准许接入SUPL服务的授权用户相关联的移动设备的阈值数目。例如，在图8中，网页服务器820可以确定允许第二移动设备840接入SUPL服务是否将超过阈值。在特定实施例中，当允许第二移动设备840接入SUPL服务不会超过阈值时，网页服务器820可以经由消息825将第三标识符和第三密码发送到第二移动设备。网页服务器820还可以对由第一移动设备810和第二移动设备840对SUPL服务的使用进行监测。在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图10的方法1000。作为例子，图10的方法1000可以由执行指令的处理器执行。参考图11，描述了无线通信设备的特定说明性实施例的方框图，并且被概括地标记为1100。例如，设备1100可以是诸如图1的移动设备120、图5的移动设备520、图8的第一移动设备810、或者图8的第二移动设备840的支持SUPL的终端（SET）。设备1100包括连接到存储器1132的处理器1110。存储器1132可以包括通过处理器1100可执行以便执行在这里所公开的诸如图3的方法300、图6的方法600、图7的方法700、或者其任意组合的方法和过程的指令1160。图11还示出了连接到处理器1110和显示器1128的显示器控制器1126。可以将CODEC1134连接到处理器1110并且连接到扬声器1136和麦克风1138。图11还指示可以将一个或多个无线控制器1140连接到处理器1110并且连接到无线天线1142、1143。在特定实施例中，天线1142可以是3GPP、3GPP2和/或WiMAX天线，并且天线1143可以是Wi-Fi天线。还可以将卡接口1170连接到处理器1110并且连接到无线控制器1140。可以将卡接口1170配置为容纳存储设备1100的安全证书的卡1172（例如，用户标识模块（SIM）卡、通用集成电路卡（UICC）或者其它卡）。例如，安全证书可以包括设备证书、公共/私钥对、IMEI、MSID、序列号、全球唯一标识符、或者其任意组合。可替换地或者另外，可以将诸如安全证书1161的设备1100的安全证书存储在存储器1132（例如，用户不可修改和/或不可访问）的“安全”位置中。在特定实施例中，将显示器控制器1126、存储器1132、CODEC1134、无线控制器1140和卡接口1170包括在封装内系统或者片上系统设备（例如，移动台调制解调器（MSM））1122中。在特定实施例中，将诸如触摸屏和/或按键的输入设备1130和电源1144连接到片上系统设备1122。此外，在特定实施例中，如在图11中所说明的，显示器1128、输入设备1130、扬声器1136、麦克风1138、无线天线1142和1143、以及电源1144在片上系统设备1122外部。然而，可以将显示器1128、输入设备1130、扬声器1136、麦克风1138、无线天线1142和1143、以及电源1144中的每个连接到片上系统设备1122诸如接口或者控制器的组件。结合所描述的实施例，公开了一种包括用于存储至少一个特定于移动设备的安全证书的模块的装置。例如，用于存储的模块可以是图2的存储器122、图11的存储器1132、图11的卡1172、配置为存储数据的一个或多个器件、或者其任意组合。该装置还可以包括用于使移动设备将至少一个安全证书发送给SLP以便将移动设备认证为与SUPL用户相关联的模块。例如，用于使得移动设备进行上述操作的模块可以是图1的处理器121、图11的处理器1110、图1的无线控制器1140、配置为导致数据传输的一个或多个器件、或者其组合。另外，公开了一种包括用于在网页服务器处从支持SUPL的移动设备接收消息的模块的装置，其中，该消息包括移动设备的安全证书。例如，用于接收消息的模块可以是图8的网络接口834、配置为接收数据的一个或多个器件、或者其任意组合。该装置还包括用于在网页服务器处从移动设备接收用户标识信息的模块。例如，用于接收用户标识信息的模块可以是图8的网络接口834、配置为接收数据的一个或多个器件、或者其任意组合。该装置还包括用于将用户标识信息认证为标识SUPL服务的授权用户的模块。例如，用于认证的模块可以是图8的处理器831、配置为对用户标识信息进行认证的一个或多个器件、或者其任意组合。该装置包括用于将移动设备的安全证书发送给SUPL服务器以便使得SUPL服务器能够将移动设备认证为与SUPL服务的授权用户相关联的模块。例如，用户发送的模块可以是图8的网络接口834、配置为接收数据的一个或多个器件、或者其任意组合。此外，公开了一种包括用于在SUPL服务器处从移动设备接收第一标识符和第一密码的模块的装置。例如，用于接收的模块可以是图8的SUPL服务器820的网络接口、配置为接收数据的一个或多个器件、或者其任意组合。该装置还包括用于将第一标识符和第一密码认证为与SUPL服务的授权用户相关联的模块。例如，用于认证的模块可以包括诸如图1的处理器111、可编程执行图8的认证逻辑821的处理器、配置为对标识符和密码进行认证的一个或多个器件、或者其任意组合。该装置还包括用于将第二标识符和第二密码发送到移动设备以代替第一标识符和第一密码的模块，其中，SUPL服务器配置为在从移动设备接收到第二标识符和第二密码之后，与移动设备建立SUPL会话。例如，用于发送的模块可以是SUPL服务器820的网络接口、配置为发送数据的一个或多个器件、或者其任意组合。该装置可以包括用于生成第二标识符和第二密码的模块。例如，用于生成的模块可以包括诸如图1的处理器111、可编程执行图8的标识符/密码生成逻辑822的处理器、配置为生成标识符和密码的一个或多个器件、或者其任意组合。在特定实施例中，还可以参考下文的附加实施例对前述所有或者部分系统和方法进行描述，和/或可以用参考下文的附加实施例所描述的系统和方法有选择地单独或者组合代替前述所有或者部分系统和方法。附加实施例1介绍·SUPL2.0中的安全是特定于接入网络的：·交替客户端认证（ACA）需要接入核心网络以便基于源IP地址对SET进行识别·GBA仅可应用于3GPP/3GPP2网络·SEK仅可应用于WiMAX网络·SUPL3.0中新的需求需要可应用于所有接入网络的认证机制。该实施例描述了可应用于所有接入网络的新的安全机制：·同时支持GBA和“用户名/密码”认证的简单框架·可以使用单个TLS变体·对规范和实现改变最小概念综述·ULP安全·具有服务器证书的TLS·两种客户端认证模式-（用户模式）:（User_ID,User_secret）=（用户名,密码）-（GBA模式）:（User_ID,User_secret）=（B-TID,Ks_NAF）·添加到所有消息的（User_ID,Counter,Digest），将Digest计算为·A1=SLP_Domain||ULP_Message,·Digest=HMAC（User_secret,A1）·发送器将（User_ID,Counter,Digest）添加到所有消息，接收器验证·用于更新SUPLINIT认证的ULP·SUPLINIT保护[例如，仅非紧急]·MimicsULPv2.0基本SUPLINIT保护·使用通过SLP经由ULP提供的SUPLINIT认证设置细节·离线·（用户模式）用户和SLP对（用户名,密码）取得一致-SLP可以将（用户名,密码）提供给用户-用户可以将（用户名,密码）提供给SLP-这可用于H-SLP或者A-SLP·在SET处发起·（用户模式）-用户将（用户名,密码）输入到SUPL客户·（GBA模式）-SET采用BSF引导以便获得（B-TID,Ks）-注意，SET可以于需要时更新（B-TID,Ks）·SUPL客户执行与SLP的ULP会话，以便获得新的SUPLINIT认证ULP会话安全提议·可以使用具有服务器证书的TLS·维护服务器认证·将新参数添加到ULP消息·将（User_ID,Req_Count,Req_Digest）添加到来自SET的消息·将（User_ID,Resp_Count,Resp_Digest）添加到来自SLP的消息·SET所发起的消息·SET添加（User_ID,Req_Count,Req_Digest）·SLP在对消息内容进行处理之前验证Req_Count和Req_Digest·SLP所发起的消息·SLP添加（User_ID,RespCounter,Resp_Digest）·SET在对消息内容进行处理之前验证Resp_Count和Resp_DigestReq_Count/Resp_Count·Req_Count/Resp_Count具有相似的行为·计数器的目的是能够进行重放检测·每次ULP会话重置接收器和发送器中的Req_Count/Resp_Count·即，当改变会话标识符时，重置计数器。·在发送器处：·Req_Count/Resp_Count每条消息递增并且添加到ULP消息·在接收器处：·接收器将Req_Count/Resp_Count与它们所期望的值进行比较。如果它们检测到重放，则它们以错误退出。否则，消息通过重放保护Req_Digest/Resp_Digest生成·Req_Digest/Resp_Digest生成可以是相同的·将所有已知值插入ULP_Message字段·采用将Req_Digest/Resp_Digest字段设置为全零形成ULP_Message_Z作为ULP_Message·形成DigestPayload=SLP_Domain“:”ULP_Message_Z·计算Req_Digest/Resp_Digest=HMAC-SHA256-32（User_secret,DigestPayload）·将Req_Digest/Resp_Digest添加到ULP_Message中的合适字段·（用户模式）·使用（User_ID,User_secret）:=（用户名,密码）·（GBA模式）·使用（User_ID,User_secret）:=（B-TID,Ks_NAF）,其中·[SET]从Ks和SLPURL生成Ks_NAF·[SLP]一旦它提取出User_ID字段，SLP就将B-TID提供给BSF，并且BSF返回Ks_NAF。Ks_NAF将不改变直到B-TID改变为止。SUPL_INIT安全提议·已经在ULPTSV2.0章节6.1.6.6中定义的Mimics基本SUPL_INIT保护·从GBA预分配的密钥到SLP预分配的密钥的改编说明·SLP在ULP会话期间在客户或者SLP主动性下更新（KeyIdentifier,SUPL_INIT_ROOT_KEY）-当重置密钥标识符时重置BasicReplayCounter·最小化所需的标准化努力SUPL_INIT认证管理·出现在任何连接会话的首次ULP交换中·SET所发起的消息·会话的首条消息应该包括-如果没有可用的认证，“SUPL_INIT_Credential_Req”指示符，或者-Current_Key_Identifier以便允许SLP检测SET和SLP是否不同步·SLP所发起的消息·如果Current_Key_Identifier是正确的，则添加“SUPL_INIT_Credential_OK”指示符以便进行确认·如果Current_Key_Identifier是不正确的，或者SET所发送的“SUPL_INIT_Credential_Req”指示符或者服务器希望更新SUPL_INIT认证，则为了提供SUPL_INIT认证，SLP将字段添加到ULP消息-包含（KeyIdentifier,SUPL_INIT_ROOT_KEY）示例呼叫流–SI立即固定·步骤A:目标SET将req_count设置为1234（或者如SET所确定的任何其它顺序号）并且计算消息摘要（req_digest）。目标SET将SUPLSTART（user-id,req_count=1234,req_digest,…）消息发送到H-SLP。·步骤B:H-SLP使用所接收的消息摘要（req_digest）检查SUPLSTART的确实性，并且还检查重放计数器（req_count）。H-SLP将res_count设置为4321（或者如通过SET所确定的任何其它顺序号）并且计算消息摘要（res_digest）。H-SLP将SUPLRESPONSE（user-id,res_count=4321,res_digest,…）消息发送给目标SET。在目标SET处SUPLSTART和SUPLRESPONSE之间的周期=UT1。·步骤C:目标SET使用所接收的消息摘要（res_digest）检查SUPLRESPONSE的确实性，并且还检查重放计数器（res_count）。目标SET给req_count增加1（1234+1），并且计算消息摘要（req_digest）。目标SET将SUPLPOSINIT（user-id,req_count=1234+1,req_digest…）消息发送给H-SLP。在H-SLP处SUPLRESPONSE和SUPLPOSINIT之间的周期=ST1。·步骤D:目标SET和H-SLP参与SUPLPOS交换。在目标SET处SUPLPOSINIT和SUPLPOS之间的周期=UT2。每边基于所接收的消息摘要检查消息确实性，并且基于消息计数器（req_count/res_count）检查重放完整性。·步骤E:H-SLP使用所接收的消息摘要（req_digest）检查所接收的最后一个SUPLPOS消息的确实性，并且还检查重放计数器（req_count）。H-SLP将req_count增加1（4321+1），并且计算消息摘要（res_digest）。H-SLP将SUPLEND（user-id,res_count=4321+1,res_digest,…）消息发送给目标SET。目标SET使用所接收的消息摘要（res_digest）检查SUPLEND的确实性，并且还检查重放计数器（res_count）。在目标SET处SUPLPOS和SUPLEND之间的周期=UT3。示例呼叫流–NI立即固定·步骤A:H-SLP将res_count设置为1234（或者如H-SLP所确定的任何其它顺序号）并且计算消息摘要（BasicMAC）。H-SLP将SUPLINIT（user-id,res_count=4321,BasicMAC,…）消息发送到目标SET。·步骤B:目标SET使用所接收的消息摘要（BasicMAC）检查SUPLINIT的确实性，并且还检查重放计数器（res_count）。目标SET将req_count设置为1234（或者如通过SET所确定的任何其它顺序号）并且计算消息摘要（req_digest）。目标SET将SUPLPOSINIT（user-id,req_count=1234,req_digest,…）消息发送给H-SLP。在H-SLP处SUPLINIT和SUPLPOSINIT之间的周期=ST1。·步骤C:目标SET和H-SLP参与SUPLPOS交换。在目标SET处SUPLPOSINIT和SUPLPOS之间的周期=UT2。每边基于所接收的消息摘要检查消息确实性，并且基于消息计数器（req_count/res_count）检查重放完整性。·步骤D:H-SLP使用所接收的消息摘要（req_digest）检查所接收的最后一个SUPLPOS消息的确实性，并且还检查重放计数器（req_count）。H-SLP将req_count增加1（4321+1），并且计算消息摘要（res_digest）。H-SLP将SUPLEND（user-id,res_count=4321+1,res_digest,…）消息发送给目标SET。目标SET使用所接收的消息摘要（res_digest）检查SUPLEND的确实性，并且还检查重放计数器（res_count）。在目标SET处SUPLPOS和SUPLEND之间的周期=UT3。附加实施例2介绍·SUPL2.0中的安全是接入网络专用的：·ACA需要接入核心网络以便基于源IP地址对SET进行识别·GBA仅可应用于3GPP/3GPP2网络·SEK仅可应用于WiMAX网络·SUPL3.0中新的需求需要可应用于所有接入网络的认证机制。该实施例描述了可应用于所有接入网络的新的安全机制：·同时支持GBA和“用户名/密码”认证的简单框架·可以使用单个TLS变体·对规范和实现改变最小概念综述·ULP安全·具有服务器证书的TLS·两种客户端认证模式-（用户模式）:（User_ID,User_secret）=（用户名,密码）-（GBA模式）:（User_ID,User_secret）=（B-TID,Ks_NAF）·添加到所有消息的（User_ID,Counter,Digest），将Digest计算为·A1=SLP_Domain||ULP_Message,·Digest=HMAC（User_secret,A1）·发送器将（User_ID,Counter,Digest）添加到所有消息，接收器验证·用于更新SUPLINIT认证（KeyIdentity,SUPL_INIT_ROOT_KEY）的ULP·SUPLINIT保护[例如，仅非紧急]·使用具有通过SLP（用户模式）或者GBA（GBA模式）生成的SULPINIT认证的ULPv2.0基本SUPLINIT保护·使用在用户模式中通过SLP经由ULP提供的SUPLINIT认证设置细节·离线·（用户模式）用户和SLP对（用户名,密码）取得一致-SLP可以将（用户名,密码）提供给用户-用户可以将（用户名,密码）提供给SLP-这可用于H-SLP或者A-SLP·在SET处发起·（用户模式）-用户将（用户名,密码）输入到SUPL客户·（GBA模式）-SET采用BSF引导以便获得（B-TID,Ks）-注意，SET可以于需要时更新（B-TID,Ks）·SUPL客户执行与SLP的ULP会话，以便获得新的SUPLINIT认证ULP会话安全提议·可以使用具有服务器证书的TLS·维护服务器认证·将新参数添加到ULP消息·将（User_ID,Req_Count,Req_Digest）添加到来自SET的消息·将（User_ID,Resp_Count,Resp_Digest）添加到来自SLP的消息·SET所发起的消息·SET添加（User_ID,Req_Count,Req_Digest）·SLP在对消息内容进行处理之前验证Req_Count和Req_Digest·SLP所发起的消息·SLP添加（User_ID,RespCounter,Resp_Digest）·SET在对消息内容进行处理之前验证Resp_Count和Resp_DigestReq_Count/Resp_Count·Req_Count/Resp_Count具有相似的行为·计数器的目的是能够进行重放检测·每次ULP会话重置接收器和发送器中的Req_Count/Resp_Count·即，当改变会话标识符时，重置计数器。·在发送器处：·Req_Count/Resp_Count每条消息递增并且添加到ULP消息·在接收器处：·接收器将Req_Count/Resp_Count与它们所期望的值进行比较。如果它们检测到重放，则它们以错误退出。否则，消息通过重放保护Req_Digest/Resp_Digest生成·Req_Digest/Resp_Digest生成可以是相同的·将所有已知值插入ULP_Message字段·采用将Req_Digest/Resp_Digest字段设置为全零形成ULP_Message_Z作为ULP_Message·形成DigestPayload=SLP_Domain“:”ULP_Message_Z·计算Req_Digest/Resp_Digest=HMAC-SHA256-32（User_secret,DigestPayload）·将Req_Digest/Resp_Digest添加到ULP_Message中的合适字段·（用户模式）·使用（User_ID,User_secret）:=（用户名,密码）·（GBA模式）·使用（User_ID,User_secret）:=（B-TID,Ks_NAF）,其中·[SET]从Ks和SLPURL生成Ks_NAF·[SLP]一旦它提取出User_ID字段，SLP就将B-TID提供给BSF，并且BSF返回Ks_NAF。Ks_NAF将不改变直到B-TID改变为止。SUPL_INIT安全提议·使用已经在ULPTSV2.0章节6.1.6.6中定义的基本SUPL_INIT保护·在用户模式中从GBA预分配的密钥到SLP预分配的密钥的改编说明·在用户模式中SLP在ULP会话期间在客户或者SLP主动性下更新（KeyIdentifier,SUPL_INIT_ROOT_KEY）-当重置密钥标识符时重置BasicReplayCounter·最小化所需的标准化努力SUPL_INIT保护参数·用于基本SUPLINIT保护的SUPLINIT保护符由以下组成:·密钥标识符·BasicReplayCounter（长度=2个八位字节）·BasicMAC（长度=4个八位字节）·如下生成BasicMAC参数:·BasicMAC=HMAC-SHA256-32（SUPL_INIT_Basic_IK,‘SUPL_INIT’）·SUPL_INIT_Basic_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“BasicIK”）·当重置密钥标识符时，重置BasicReplayCounter·由于User_ID和User_secret即SUPLINIT保护与ULP消息认证独立工作，所以密钥标识符和SUPL_INIT_ROOT_KEY是不相同的SUPL_INIT认证管理·出现在任何连接会话的首次ULP交换中·SET所发起的消息·会话的首条消息应该包括-如果没有可用的认证，“SUPL_INIT_Credential_Req”指示符，或者-Current_Key_Identifier以便允许SLP检测SET和SLP是否不同步·SLP所发起的消息·如果Current_Key_Identifier是正确的，则添加“SUPL_INIT_Credential_OK”指示符以便进行确认·如果Current_Key_Identifier是不正确的，或者SET所发送的“SUPL_INIT_Credential_Req”指示符或者服务器希望更新SUPL_INIT认证，则为了提供SUPL_INIT认证，SLP将字段添加到ULP消息-包含（KeyIdentifier,SUPL_INIT_ROOT_KEY）示例呼叫流–SI立即固定·步骤A:目标SET将req_count设置为1234（或者如SET所确定的任何其它顺序号）并且计算消息摘要（req_digest）。目标SET将SUPLSTART（user-id,req_count=1234,req_digest,…）消息发送到H-SLP。·步骤B:H-SLP使用所接收的消息摘要（req_digest）检查SUPLSTART的确实性，并且还检查重放计数器（req_count）。H-SLP将res_count设置为4321（或者如通过SET所确定的任何其它顺序号）并且计算消息摘要（res_digest）。H-SLP将SUPLRESPONSE（user-id,res_count=4321,res_digest,…）消息发送给目标SET。在目标SET处SUPLSTART和SUPLRESPONSE之间的周期=UT1。·步骤C:目标SET使用所接收的消息摘要（res_digest）检查SUPLRESPONSE的确实性，并且还检查重放计数器（res_count）。目标SET给req_count增加1（1234+1），并且计算消息摘要（req_digest）。目标SET将SUPLPOSINIT（user-id,req_count=1234+1,req_digest…）消息发送给H-SLP。在H-SLP处SUPLRESPONSE和SUPLPOSINIT之间的周期=ST1。·步骤D:目标SET和H-SLP参与SUPLPOS交换。在目标SET处SUPLPOSINIT和SUPLPOS之间的周期=UT2。每边基于所接收的消息摘要检查消息确实性，并且基于消息计数器（req_count/res_count）检查重放完整性。·步骤E:H-SLP使用所接收的消息摘要（req_digest）检查所接收的最后一个SUPLPOS消息的确实性，并且还检查重放计数器（req_count）。H-SLP将req_count增加1（4321+1），并且计算消息摘要（res_digest）。H-SLP将SUPLEND（user-id,res_count=4321+1,res_digest,…）消息发送给目标SET。目标SET使用所接收的消息摘要（res_digest）检查SUPLEND的确实性，并且还检查重放计数器（res_count）。在目标SET处SUPLPOS和SUPLEND之间的周期=UT3。示例呼叫流–NI立即固定·步骤A:H-SLP将res_count设置为1234（或者如H-SLP所确定的任何其它顺序号）并且计算消息摘要（BasicMAC）。H-SLP将SUPLINIT（user-id,res_count=4321,BasicMAC,…）消息发送到目标SET。·步骤B:目标SET使用所接收的消息摘要（BasicMAC）检查SUPLINIT的确实性，并且还检查重放计数器（res_count）。目标SET将req_count设置为1234（或者如通过SET所确定的任何其它顺序号）并且计算消息摘要（req_digest）。目标SET将SUPLPOSINIT（user-id,req_count=1234,req_digest,…）消息发送给H-SLP。在H-SLP处SUPLINIT和SUPLPOSINIT之间的周期=ST1。·步骤C:目标SET和H-SLP参与SUPLPOS交换。在目标SET处SUPLPOSINIT和SUPLPOS之间的周期=UT2。每边基于所接收的消息摘要检查消息确实性，并且基于消息计数器（req_count/res_count）检查重放完整性。·步骤D:H-SLP使用所接收的消息摘要（req_digest）检查所接收的最后一个SUPLPOS消息的确实性，并且还检查重放计数器（req_count）。H-SLP将req_count增加1（4321+1），并且计算消息摘要（res_digest）。H-SLP将SUPLEND（user-id,res_count=4321+1,res_digest,…）消息发送给目标SET。目标SET使用所接收的消息摘要（res_digest）检查SUPLEND的确实性，并且还检查重放计数器（res_count）。在目标SET处SUPLPOS和SUPLEND之间的周期=UT3。附加实施例3介绍·SUPL2.0中的安全是接入网络专用的：·ACA需要接入核心网络以便基于源IP地址对SET进行识别·GBA仅可应用于3GPP/3GPP2网络·SEK仅可应用于WiMAX网络·SUPL3.0中新的需求需要可应用于所有接入网络的认证机制。该实施例描述了可应用于所有接入网络的新的安全机制：·同时支持GBA和“用户名/密码”认证的简单框架SUPL3.0安全概念综述ISUPL3.0安全概念综述II为SUPL3.0安全考虑下列两种选项:选项I选项IIACA（A）ACA（A）GBA（B）GBA（B）用户模式ULP（C）用户模式TLS（D）选项I:概念综述·ULP安全·GBA模式:如之前那样使用TLS-PSK·用户模式ULP:基于（用户名,密码）–首先与服务器证书进行TLS握手，以便建立安全连接·将（Username,Counter,Digest）添加到通过SET发送的所有ULP消息，将Digest计算为–A1=SLP_Domain||ULP_Message,–Digest=HMAC（Password,A1）·SET将（Username,Counter,Digest）添加到所有消息，SLP验证·用于更新为了SUPLINIT保护所需要的SUPLINIT认证（KeyIdentity,SUPL_INIT_ROOT_KEY）的ULP选项I:离线过程·用户模式ULP（离线）·用户和SLP运营商对（用户名,密码）取得一致·其它假设·SET具有SLP的URL·SET具有用于对SLP进行认证的合适的根认证选项I:在线过程·用于服务器认证和加密的具有服务器证书的TLS·将新的参数添加到来自SET的ULP消息:（Username,Counter,Digest）·SLP在对ULP消息内容进行处理之前验证计数器和摘要·计数器的目的是能够进行重放检测·每次ULP会话重置接收器和发送器中的计数器·在发送器处，计数器每条消息增加1并且将其添加到ULP消息·在接收器处，将计数器与预期值进行比较。如果检测到重放，以错误退出。否则，消息通过重放保护。选项II:概念综述·ULP安全·GBA模式:如之前那样使用TLS-PSK·用户模式TLS:基于（用户名,密码）–首先与服务器证书进行TLS握手，以便建立安全连接–SLP发送“问候请求”以便发起TLS重新协商。随后，SET和SLP进行TLS-SRP握手（SRP=安全远程密码），以便使用（用户名，密码）对用户进行认证。–需要第一个安全连接，以便在TLS-SRP握手中隐藏用户名。·用于更新为了SUPLINIT保护所需要的基本保护SUPLINIT认证（KeyIdentity,SUPL_INIT_ROOT_KEY）的ULP选项II:离线过程·用户模式TLS（离线）·用户和SLP运营商对（用户名,密码）取得一致·其它假设·SET具有SLP的URL·SET具有用于对SLP进行认证的合适的根认证选项II:在线过程·SET发起TLS握手，通过选择合适的密码组在TLS中指示支持GBA和/或用户模式·SLP确定是以GBA模式还是用户模式继续进行·如果GBA模式，则·对于使用GBA的TLS-PSK，继续TLS握手，以便建立安全通道·相互认证·在安全通道中交换数据·如果用户模式，则·首先采用服务器证书继续TLS握手，以便建立安全通道·SET对SLP进行认证·进行TLS-SRP握手（在安全通道内部交换消息）·SLP对用户进行认证·得到新的会话密钥·受新的会话密钥保护在安全通道中交换数据选项II:在线过程-首次TLS握手·SET→SLP:客户问候:·指示所有支持的密码组–如果SET支持GBA，就指示支持TLS-PSK密码组–如果SET支持用户模式，就指示支持采用服务器证书的TLS和TLSSRP·SET此时不提供用户名，如果需要，将在下一次TLS握手中提供·SLP→SET:服务器问候:·指示所选择的密码组–如果SLP选择GBA模式，SLP就指示TLS-PSK密码组–如果SLP选择用户模式，SLP就指示采用服务器证书的TLS–对于所选择的密码组，呼叫流继续选项II:在线过程-在首次TLS握手之后·GBA模式·SET和SLP在安全信道上开始通信·用户模式·SLP→SET:问候请求·发起重新协商·SET→SLP:客户问候·指示支持TLS-SRP·包括用户名作为每个TLS-SRP规范·SET→SLP:服务器问候·指示TLS-SRP的选择·每个TLS-SRP继续交换·在成功握手之后，SET和SLP开始在安全信道上交换数据。SUPLINIT保护·SUPL3.0中的SUPLINIT保护基于SUPL2.0中的SUPLINIT保护机制，并且使用附加到SUPLINIT的消息认证码（MAC）·在用户模式中使用在ULP上提供的（KeyIdentity,SUPL_INIT_ROOT_KEY）计算MAC（GBA模式不需要提供）·用于计算（KeyIdentity,SUPL_INIT_ROOT_KEY）的两种方法:·GBA模式:（KeyIdentity,SUPL_INIT_ROOT_KEY）=（B-TID,Ks）–（B-TID,Ks）是BSF的引导关·用户模式:从（用户名，密码）生成（KeyIdentity,SUPL_INIT_ROOT_KEY）·SUPLINIT保护对于选项I和选项II是相同的SUPLINIT保护机制·在SUPLv3.0中的两个保护级别:·无–无安全·基本保护–基于共享密钥标识，在ULP上提供的SUPL_INIT_ROOT_KEY–来自SUPLv2.0的Mimics基本保护–密钥标识符和SUPL_INIT_ROOT_KEY随着用户名、密码不同·重新同步保护机制:·基于SET可以从SET中的SLP认证验证的数字签名·仅当SLP承认密钥标识、SLP和SET中的SUPL_INIT_ROOT_KEY变得不同步时可以使用·计算可能很昂贵:可以节俭使用基本SUPLINIT保护参数·用于基本SUPLINIT保护的SUPLINIT保护符由以下组成:·密钥标识符·BasicReplayCounter（长度=2个八位字节）·BasicMAC（长度=4个八位字节）·如下生成BasicMAC参数:·BasicMAC=HMAC-SHA256-32（SUPL_INIT_Basic_IK,‘SUPL_INIT’）·SUPL_INIT_Basic_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“BasicIK”）·当重置密钥标识符时，重置BasicReplayCounterSUPL_INIT_ROOT_KEY管理·出现在任何SUPL会话的首次ULP交换中·SET首次发起的消息·会话的首条消息应该包括-如果没有可用的认证，“SUPL_INIT_Credential_Req”指示符，或者-Current_Key_Identifier以便允许SLP检测SET和SLP是否不同步·SLP的响应·如果Current_Key_Identifier是正确的，则添加“SUPL_INIT_Credential_OK”指示符以便进行确认·如果Current_Key_Identifier是不正确的，或者SET所发送的“SUPL_INIT_Credential_Req”指示符或者SLP希望更新SUPL_INIT认证，则为了提供SUPL_INIT认证，SLP将字段添加到ULP消息-包含（KeyIdentifier,SUPL_INIT_ROOT_KEY）用户模式比较总结·在SUPL3.0中考虑了两种新的安全模式·选项I:用户模式ULP·选项II:用户模式TLS·两种新的安全模型使用（用户名，密码）客户端认证，而服务器认证和加密是基于传统服务器授权的TLS的。·两种选项是不可知承载者的安全模型，并且因此适合SUPL3.0。·在可应用和所期望之处，仍然可以使用传统安全模型（ACA和GBA）。SRP基础·TLS-SRP[IETFRFC5054]使用安全远程密码（SRP[RFC2945]）作为认证和密钥交换的基础·主要步骤·服务器进行认证不需要密码，作为替代，它存储包含{用户名,密码验证,趣味}的三连变量·典型情况下，当与服务器离线注册时，用户的客户生成三连变量·趣味可以由用户随机选择。·使用类似于Diffie-Hellman密钥交换的微妙数学从用户名、趣味和用户的密码中计算密码验证。·服务器在与用户的交互作用中使用三连变量，以便·验证用户知道密码，并且·建立仅用户和服务器知道的共享秘密。随后，可以使用该共享秘密生成用于加密和完整性保护（这是它在TLS-SRP中如何使用的）的密钥SRP的一些属性·不可以使用三连变量模仿用户·服务器不需要保持三连变量是秘密的·服务器可以将三连变量提供给第三方，以便允许第三方验证用户，服务器不关心第三方随后将尝试模仿用户–例如，H-SLP可以将三连变量提供给A-SLP，以便允许A-SLP对用户进行认证附加实施例4介绍·SUPL2.0中的安全是接入网络专用的：·ACA需要接入核心网络以便基于源IP地址对SET进行识别·GBA仅可应用于3GPP/3GPP2网络·SEK仅可应用于WiMAX网络·SUPL3.0中新的需求需要可应用于所有接入网络的认证机制。该实施例描述了可应用于所有接入网络的新的安全机制：·同时支持GBA和“用户名/密码”认证的简单框架SUPL3.0安全概念综述ISUPL3.0安全概念综述II为SUPL3.0安全考虑下列两种选项:选项I选项IIACA（A）ACA（A）GBA（B）GBA（B）用户模式ULP（C）用户模式TLS（D）下列讨论提供了两种选项，并且讨论了每种方法的优点和潜在缺点。用户模式离线过程·用户模式（离线）·用户和SLP运营商就（用户名，密码）取得一致·其它假设·SET具有SLP的URL·SET具有用于对SLP进行认证的合适的根认证用户模式ULP:概念综述I·用户模式ULP:基于（用户名，密码）·首先与服务器证书进行TLS握手，以便建立安全连接·将（Username,Counter,Digest）添加到通过SET发送的所有ULP消息，将Digest计算为–ULP_Message_Z是具有Digest字段设置为零的ULP_Message–User_ULP_IK=SHA-256（Username||“:”||Password||“:”||SLP_Domain||“:SUPL30ULP”）–Digest=HMAC-SHA-256-32（User_ULP_IK,ULP_Message_Z）·SET将（Username,Counter,Digest）添加到所有消息，SLP验证用户模式ULP:概念综述II·具有用于服务器认证和加密的服务器证书的TLS·将新的参数添加到来自SET的ULP消息:（Username,Counter,Digest）·SLP在对ULP消息内容进行处理之前验证计数器和摘要·计数器的目的是能够进行重放检测·每次ULP会话重置接收器和发送器中的计数器·在发送器处，计数器每条消息增加1并且将其添加到ULP消息·在接收器处，将计数器与预期值进行比较。如果检测到重放，以错误退出。否则，消息通过重放保护。用户模式TLS:概念综述·用户模式ULP:基于（用户名，密码）·首先与服务器证书进行TLS握手，以便建立安全连接·SLP发送“问候请求”以便发起TLS重新协商。随后，SET和SLP进行TLS-SRP握手（SRP=安全远程密码），以便使用（用户名，密码）对用户进行认证。·需要第一个安全连接，以便在TLS-SRP握手中隐藏用户名。选项I:在线过程综述·SET发起TLS握手，通过选择合适的密码组在TLS中指示支持GBA和/或用户模式·SLP确定是以GBA模式还是用户模式继续进行·如果GBA模式，则·对于使用GBA的TLS-PSK，继续TLS握手，以便建立安全通道–提供相互认证·在安全通道中交换数据·如果用户模式，则·继续与服务器证书的TLS握手，以便建立安全通道–SET对SLP进行认证·在安全通道内部交换数据–将新的参数添加到来自SET的ULP消息（Username,Counter,Digest），其允许SLP对用户进行认证选项I:在线过程细节-TLS握手·SET→SLP:客户问候:·指示所有支持的密码组–如果SET支持GBA，就指示支持TLS-PSK密码组–如果SET支持用户模式，就指示支持采用服务器证书的TLS·SLP→SET:服务器问候:·指示所选择的密码组–如果SLP选择GBA模式，SLP就指示TLS-PSK密码组–如果SLP选择用户模式，SLP就指示采用服务器证书的TLS·对于所选择的密码组，呼叫流继续选项I:在线过程细节–在TLS握手之后·GBA模式·SET和SLP在安全信道上开始通信·用户模式·SET和SLP在安全信道上开始通信·将新的参数添加到来自SET的ULP消息:（Username,Counter,Digest）–SLP在对ULP消息内容进行处理之前验证计数器和摘要–计数器的目的是能够进行重放检测–每次ULP会话重置接收器和发送器中的计数器–在发送器处，计数器每条消息增加1并且将其添加到ULP消息–在接收器处，将计数器与预期值进行比较。如果检测到重放，以错误退出。否则，消息通过重放保护。选项II:在线过程综述·SET发起TLS握手，通过选择合适的密码组在TLS中指示支持GBA和/或用户模式。·SLP确定是以GBA模式还是用户模式继续进行·如果GBA模式，则1.对于使用GBA的TLS-PSK，继续TLS握手，以便建立安全通道–相互认证2.在安全通道中交换数据·如果用户模式，则1.首先继续与服务器证书TLS握手，以便建立安全通道–SET对SLP进行认证2.进行TLS-SRP握手（在安全通道内部交换消息）–SLP对用户进行认证–得到新的会话密钥3.受新的会话密钥保护在安全通道中交换数据选项II:在线过程细节-首次TLS握手·SET→SLP:客户问候:·指示所有支持的密码组–如果SET支持GBA，就指示支持TLS-PSK密码组–如果SET支持用户模式，就指示支持采用服务器证书的TLS和TLSSRP·SET此时不提供用户名，如果需要，将在下一次TLS握手中提供·SLP→SET:服务器问候:·指示所选择的密码组–如果SLP选择GBA模式，SLP就指示TLS-PSK密码组–如果SLP选择用户模式，SLP就指示用于采用服务器证书的TLS的密码组–对于所选择的密码组，呼叫流继续选项II:在线过程细节-在首次TLS握手之后·GBA模式·SET和SLP在安全信道上开始通信·用户模式·SLP→SET:问候请求–发起重新协商·SET→SLP:客户问候–指示支持TLS-SRP–包括用户名作为每个TLS-SRP规范·SET→SLP:服务器问候–指示TLS-SRP的选择·每个TLS-SRP继续交换·在成功握手之后，SET和SLP开始在安全信道上交换数据。SUPLINIT保护·SUPL3.0中的SUPLINIT保护基于SUPL2.0中的SUPLINIT保护机制，并且使用附加到SUPLINIT的消息认证码（MAC）·用于认证的两种方法:○GBA模式:（KeyIdentity,SUPL_INIT_ROOT_KEY）=（B-TID,Ks）■（B-TID,Ks）是BSF的引导关○用户模式:使用（用户名，密码）进行认证·SUPLINIT保护对于选项I和选项II是相同的SUPLINIT保护机制·在SUPLv3.0中提供的三种保护类型:·无–无安全·GBA模式保护–与SUPLv2.0基本保护相同·用户模式保护–基于（用户名，密码）进行认证–添加随机值以防止字典攻击–添加时间以防止重放SUPLINITGBA模式保护·如果使用GBA认证，则SUPLINIT保护符参数由以下组成：·密钥标识符=GBAB-TID（长度=变量）·GBA_ReplayCounter（长度=2个八位字节）。防止重放·SUPL_INIT_GBA_MAC（长度=4个八位字节）。对消息进行认证。·如下生成SUPL_INIT_GBA_MAC参数:·SUPL_INIT_GBA_MAC=HMAC-SHA256-32（SUPL_INIT_GBA_IK,SUPL_INIT_Z）·SUPL_INIT_GBA_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“GBAIK”）·SUPL_INIT_ROOT_KEY是对应于B-TID的GBA密钥Ks_（int/ext_）NAF·SUPL_INIT_Z是具有将SUPL_INIT_GBA_MAC字段设置为全零的SUPLINIT消息·当重置密钥标识符时重置GBA_ReplayCounterSUPLINIT用户模式保护·如果使用用户模式安全，则SUPLINIT保护符参数由以下组成：·SUPL_INIT_RAND（长度=8个八位字节）。这可以是对该消息唯一的随机值以防止在密码上的字典攻击。·SUPL_INIT_TIME（长度=4个八位字节）。发送消息的时间。停止重放。.·SUPL_INIT_USER_MAC（长度=4个八位字节）。对消息进行认证。.·如下生成SUPL_INIT_USER_MAC参数:·SUPL_INIT_USER_MAC=HMAC-SHA256-32（SUPL_INIT_USER_IK,SUPL_INIT_Z）·SUPL_INIT_USER_IK=SHA-256（Username||“:”||Password“:”||SLP_Domain||“:SUPL30INIT”）·SUPL_INIT_Z是具有将SUPL_INIT_USER_MAC字段设置为全零的SUPLINIT消息。用户模式比较总结·在SUPL3.0中考虑了两种新的安全模型·选项I:用户模式ULP·选项II:用户模式TLS·两种新的安全模型使用（用户名，密码）客户端认证，而服务器认证和加密是基于传统服务器授权的TLS的。·两种选项是不可知承载者的安全模型，并且因此适合SUPL3.0。·在可应用和所期望之处，仍然可以使用传统安全模型（ACA和GBA）。附加实施例5介绍·OMASUPL2.0中的安全是接入网络专用的：·ACA（可替换客户端认证）需要接入核心网络以便基于源IP地址对SET进行识别·GBA（通用引导架构）仅可应用于3GPP/3GPP2网络·SEK（SUPL加密密钥）仅可应用于WiMAX网络·OMASUPL3.0中新的需求需要可应用于所有接入网络的认证机制。该实施例描述了可应用于所有接入网络的新的安全机制：·基于“用户名/密码”认证的简单框架·还支持传统的ACA和基于GBA的安全SUPL3.0安全概念综述I用于SUPL3.0的安全基于三种安全方法：SUPL3.0安全概念综述II·ACA和GBA是接入网络专用的，但是可以在可应用之处并且取决于SUPL运营商的选择使用。·用户模式TLS是独立于接入网络的，并且可以将其视为ACA的增强。用户模式TLS–综述I·公钥TLS服务器认证–安全连接H-SLP和SLP；对H-SLP进行认证但是不对SET进行认证。·用户名/密码TLS-SRP客户端认证-安全连接H-SLP和SLP；对H-SLP和SET都进行认证·用户模式TLS·当在ACA中产生安全加密IP连接时，使用公钥TLS首先对服务器进行认证·随后，在SET和SLP中使用预提供的用户名/密码基于TLS-SRP（安全远程密码）对客户进行认证用户模式TLS综述II·简单的用户名/密码机制可能造成问题和/或威胁：·用户名/密码可能被盗并且在不同的设备上使用·用户名/密码可能自动泄露并且同时在不同设备上使用·这可以通过以下办法解决：·仅为紧随SUPL服务激活之后的第一个SUPL会话使用用户名/密码。·在第一个SUPL会话期间，SLP创建新的用户名/密码，并且发送到SET（使用通过初始用户名/密码创建的安全IP连接）。·SET随后用新的用户名/密码代替初始用户名/密码，并且删除旧的用户名/密码。·随后，通过由SLP创建的用户不可见的用户名/密码将设备绑定到SUPL订阅。·则，所有将来的TLS会话使用由SLP创建的新的用户名/密码。·则，其它设备不能使用该用户名/密码在4个步骤中的用户模式TLS·步骤1:用户和SLP运营商就临时用户名和密码取得一致：（用户名_临时,密码_临时）。·步骤2:建立第一个SUPL会话。基于服务器授权的TLS执行服务器认证和计算。使用已经过协议的（用户名_临时,密码_临时）基于TLS-SRP（SRP=安全远程密码）执行客户端认证。·步骤3:在第一个SUPL会话内，SLP生成新的并且加密性强的（用户名，密码），将其发送到SET。SET以（用户名，密码）代替（用户名_临时,密码_临时）。SET将（用户名，密码）存储在安全位置。·步骤4:所有后续的TLS会话基于服务器授权的TLS使用服务器认证和计算。使用（用户名，密码）基于TLS-SRP执行客户端认证。用户模式TLS步骤1–细节·用户和SLP运营商就临时用户名和密码取得一致：（用户名_临时,密码_临时）·可以以各种方式在SET中提供（用户名_临时,密码_临时）：·在空中通过运营商提供·在运营商的商店提供（SET的闪存）·通过邮件发送或者在线获得并且通过SET用户输入的用户名和密码·其它·给SLP提供了SLP的URL·给SLP提供了对SLP进行授权所需的合适的根认证用户模式TLS步骤2–细节·第一个SUPL会话的首次TLS握手，以便发起服务器认证和加密：·SET→SLP:指示支持具有服务器证书的TLS和TLS-SRP的客户问候·SLP→SET:指示用于具有服务器证书的密码组的服务器问候·第二次TLS握手，以便发起客户端认证·SLP→SET:问候请求，以便发起重新协商·SET→SLP:指示支持TLS-SRP并且包括每TLS-SRP规范的用户名_临时的客户问候·SLP→SET:指示TLS-SRP选择的服务器问候·基于（用户名_临时,密码_临时）执行客户端认证·生成新的会话密钥（仅用于该会话）·SET和SLP现在可以在安全信道上进行SUPL会话用户模式TLS步骤3–细节·SLP基于临时用户名和密码（用户名_临时,密码_临时）创建加密性强的（用户名,密码）。·从SLP到SET的第一条SUPL消息携带加密性强的（用户名,密码）。·SET以（用户名,密码）代替临时（用户名_临时,密码_临时）。·SET丢弃（用户名_临时,密码_临时）。·SET将（用户名,密码）存储在安全位置中。·注释1:如果SLP运营商能够在不包括用户的SET中安全地提供用户名/密码，可以不执行该步骤·注释2:对于3GPP/3GPP2初始接入，SLP可以在核心网中验证SETIP地址与SETMSISDN或者IMSI相关联，以便进一步验证SET属于用户用户模式TLS步骤4–细节·对于后续的TLS会话建立:·TLS握手，以便发起服务器认证和加密:–SET→SLP:指示支持具有服务器证书的TLS和TLS-SRP的客户问候–SLP→SET:指示用于具有服务器证书的密码组的服务器问候·第二次TLS握手，以便发起客户端认证:–SLP→SET:问候请求，以便发起重新协商–SET→SLP:指示支持TLS-SRP并且包括每TLS-SRP规范的用户名的客户问候–SLP→SET:指示TLS-SRP选择的服务器问候–基于（用户名,密码）执行客户端认证–生成新的会话密钥·SET和SLP现在可以在安全信道上进行SUPL会话·注释:虽然一旦提供了加密的安全用户名/密码PSK-TLS可以用于后续接入，但是可以以减小的复杂度实现TLS-SRP的重用SUPLINIT保护综述·SUPL3.0中的SUPLINIT保护基于SUPL2.0中的SUPLINIT保护机制，并且使用附加到SUPLINIT的消息认证码（MAC）·在SUPLv3.0中所提出的两种保护类型:·GBA模式保护–与SUPLv2.0基本保护相同·User模式保护–基于由SLP创建的（用户名，密码）的认证（即，不使用用于服务激活的初始用户名/密码（用户名_临时，密码_临时））。·也支持空保护并且可以基于运营商的选择使用。SUPLINIT用户模式保护I·如果使用用户模式TLS安全，则SUPLINIT保护符参数由以下组成：·SUPL_INIT_TIME（长度=4个八位字节）。发送消息的时间。停止重放。·SUPL_INIT_USER_MAC（长度=4个八位字节）。对消息进行认证。·将SUPLINIT保护符添加到每条SUPLINIT消息，并且允许SET检查所接收的SUPLINIT消息的确实性。·对于运营商使用SUPLINIT保护的例外情况（例如，SET和SLP不同步），只要明确地给SET指示（例如，经由重置命令），可以使用空SUPLINIT保护临时重新提供SET，使得服务攻击拒绝不能利用此过将无保护的SUPLINIT发送给大量SET。SUPLINIT用户模式保护II·如下生成SUPL_INIT_USER_MAC参数:·SUPL_INIT_USER_MAC=HMAC-SHA256-32（SUPL_INIT_USER_IK,SUPL_INIT_Z）·SUPL_INIT_USER_IK=SHA-256（Username||“:”||Password“:”||SLP_Domain||“:SUPL30INIT”）·SUPL_INIT_Z是具有SUPL_INIT_USER_MAC字段设置为全零的SUPLINIT消息总结·为SUPL3.0描述了新的安全模型:用户模型TLS。·用户模式TLS使用（用户名，密码）客户端认证，而服务器认证和加密基于传统服务器授权的TLS。·在用户模式TLS中也支持SUPLINIT保护。·用户模式TLS是不可知承载者的安全模型，并且因此适合SUPL3.0。·取决于SUPL运营商的选择，仍然可以使用传统安全模型（ACA和GBA）。推荐·可以采用用户模式TLS作为用于SUPL3.0的安全模型·可以维持对传统ACA和GBA安全模型的支持SUPL3.0接入SLP（A-SLP）·对于漫游用户，支持精确定位对于H-SLP提供商可能是困难的，但是对于本地漫游区域中的定位提供商容易得多·在一些情况下，运营商与其它运营商和提供商可以具有商业关系，其可能临时使用属于运营商A的H-SLP使运营商B的用户受益·SUPL3.0RD包括面向更广泛可用性和更容易接入SLP的需求:·SUPL-EMER-03:SUPL应该支持用于紧急定位请求的SET发起的和网络发起的定位·SUPL-HLF-18:SUPL应该支持SLP服务发现·一些用户可能不具有H-SLP–例如，本地运营商不支持SUPL–或者不选择H-SLPSUPL支持·一些运营商可能希望给漫游用户扩展SUPL支持–例如，那行没有H-SLP的运营商或者其H-SLP在特定漫游区域中不能充分支持定位的运营商接入SLP（A-SLP）·A-SLP可以属于接入网络提供商、可以与接入网络相关联、或者支持接入网络的地理区域·A-SLP可以以与H-SLP几乎相同的方式支持SUPL3.0–例如，包括所有网络和SET发起的服务·SET将需要发现或者给SET提供关于A-SLP的信息（例如，A-SLP地址和安全参数）·可能的信息源是接入网络、H-SLP以及独立（非标准）发现·A-SLP安全应该重新使用为H-SLP定义的方法–例如，避免不同的认证方法·SET和A-SLP可以相互作用有限的预协议时间周期，以便为外部SUPL代理和SET支持SUPL3.0服务可能的A-SLP使用·SET使用ULP3.0消息经由接入网络与SLP进行通信，并且使用ULP3.0消息经由本地网络（可选地，用于发现和验证A-SLP）与H-SLP进行通信。·A-SLP经由MLP与SUPL代理进行通信。示例用户案例·示例1–用户访问新的城市、城镇、游览地等。·H-SLP可能仅能支持绝对定位，并且不总是精确的（例如，如果在大楼内部），并且可能不能提供诸如感兴趣点、地图、天气/交通信息等的辅助信息。·A-SLP可以与诸如方向寻找、感兴趣点、地图、天气/交通等的应用级服务（不是SUPL的部分）一起提供更多连续的精确定位支持。·示例2–紧急呼叫支持·如果A-SLP还支持E-SLP性能，通过SET发现A-SLP可以辅助稍后基于IP的紧急呼叫·随后，SET具有从A-SLP获得其近似位置以及将其包括在紧急SIPINVITE中从而辅助呼叫例程的选项·SET和A-SLP/E-SLP之间之前的联系也可以辅助稍后对PSAP发送更精确的定位A-SLP安全-1·关于H-SLP，允许相同的安全过程·如在OMA-LOC-2010-0xyz-INP_SUPL_3.0_Security中所描述的，合适的安全方法是用户模式TLS–例如，这不需要支持GBA、仅接入3GPP/3GPP2、直接对SET进行配置的能力·A-SLP运营商或者H-SLP运营商（在两个运营商之间存在商业关系）可以分配初始用户名/密码·随后，A-SLP可以采用在第一个SUPL会话上的新的值代替初始用户名/密码，以避免其它设备使用该用户名/密码·虽然A-SLP运营商可能不总是能够验证给SET提供的用户名/密码属于预期用户，但是对于主要集中在SET发起的服务并且以相同费率对所有漫游用户收费的A-SLP服务来说，这可能不要紧·注释:在大多数情况下，用户可以将接入A-SLP失败报告给A-SLP提供商（例如，如果另一个用户获得并且使用初始用户名/密码），这允许使当前用户名/密码无效并且用新的用户名/密码代替A-SLP安全-2·作为选项，可以使用H-SLP发现、验证和帮助支持对于A-SLP的安全·SET可以将ULP请求发送到H-SLP，其具有这些参数之一：·（A）当前SET定位或者服务接入网络标识·（B）已经发现的A-SLP地址（例如，在线发现或者通过接入网络提供）·对于（A），H-SLP可以返回对本地区域进行服务的信赖A-SLP的地址·对于（B），H-SLP可以指示A-SLP是可信赖的、不可信赖的、还是对于H-SLP未知的·对于（A）并且对于（B），在受信赖的情况下，H-SLP可以有选择地给SET提供初始A-SLP或者H-SLP分配的用户名/密码（对于此，随后，将需要在A-SLP和H-SLP或者相关联提供商之间的一些附加相互作用来传送用户名/密码和用户标识）SUPL3.0AD和TS影响·定义A-SLP（与现存H-SLP、V-SLP、E-SLP一起）·定义或者参考合适的发现机制·指示使用用户模式TLS安全·为A-SLP发现、验证和安全添加任何合适的H-SLP支持·允许SET和A-SLP将所支持的服务限制于用于H-SLP相互作用的那些服务的子集（如已经在现存SUPL3.0消息流中所支持的，其中，每个端点告知服务的另一个端点它将支持新的会话）·识别和支持新的私有需求（如果有）与H-SLP服务的关系·H-SLP提供商可以选择支持某个与其存在某些商业关系的A-SLP提供商·H-SLP提供商还可以给来自其它运营商的漫游用户提供作为A-SLP提供商的支持·可以对SET进行配置，以便控制A-SLP，如下:a)总是使用H-SLP并且禁止A-SLP使用b)最好使用H-SLP但是允许服从H-SLP赞成的A-SLP使用（例如，仅当与H-SLP提供商存在漫游协议时，才允许A-SLP接入）c)允许SET基于其自身标准自由决定H-SLP与A-SLP的使用，或者d)总是使用A-SLP（例如，当不存在H-SLP时可应用）·最终结果可以增加SUPL3.0使用和有益于提供商和用户的相关联部署·可以将A-SLP支持包括为SUPL3.0的部分·重新使用H-SLP安全支持并且允许H-SLP辅助或者控制A-SLP接入·允许某个级别的非SUPL支持（例如，关于A-SLP和H-SLP提供商之间的A-SLP发现和相互作用）附加实施例6介绍该实施例为客户端认证使用设备证书。SUPL3.0安全概念综述ISUPL3.0安全概念综述II·ACA和GBA是接入网络专用的，但是可以在可应用之处并且取决于SUPL运营商的选择使用。·该实施例新的安全模型是使用设备证书的客户端认证。基于客户端认证的设备证书是独立于接入网络的，并且因此可以用于所有类型的接入网络和设备（即，非3GPP/3GPP2接入网络和所支持的设备）。设备预提供·在制造期间，制造商提供到SET内·对于该SET设备唯一的私钥·将相应的公钥绑定到一个或多个全球唯一的SET设备标识（例如，序列号、IMEI或MSID）的认证·返回众所周知的受潜在SLP信赖的认证权威的一个或多个认证链条·注释:如果不存在返回受SLP信赖的CA的链条，则SLP将不信赖SET认证·SLP负责确保给SET提供一个或多个可以用于验证SLP的认证的根认证·可以在SET制造或者销售期间提供这些根认证，·可以将这些根认证与SUPL客户软件绑定。·注释:如果不存在从SLP认证返回这些根认证之一的认证链条，则SET将不能对SLP进行认证·OMA-LOC可以为认证指定公共模版或者轮廓，以便简化并且统一实现和测试设备证书总结·步骤1:用户授权（在范围外）·用户安全地向SLP验证应该将该设备与他们的订阅相关联·步骤2:运行时间TLS握手·首先:使用服务器证书执行服务器授权的TLS握手·其次:在加密TLS隧道内部，使用服务器证书和客户端认证执行相互授权的TLS握手·现在可以安全地交换数据（在范围外）用户认证I·由于仅对SET标识而不是用户标识进行认证，SLP知道应该将哪个用户与（授权的）SET相关联·每当用户在SET之间切换时，这发生·将SET标识提供给SLP对于用户可能是不足的·原因:用户1可以将用户2的SETID提供给SLP，并且说“这是我的SET”。随后，SLP可以在用户2没有意识到发生了什么的情况下将用户2位置的细节提供给用户1。·使用安全方法将用户与SETID安全地进行相关联·方法是在范围之外的·一些系统已经具有将设备标识与用户安全相关联的机制（例如，苹果、黑莓）·下面提供了示例方法（在范围外）用户认证II·用于将用户与设备标识安全相关联的示例方法·SLP运营商提示用户连接到SLP拥有的网站同时使用SET·用户连接到网站（可能是WAP），同时使用SET·网页服务器请求采用设备证书和网页服务器证书的TLS握手·该认证可能与SLP服务车不同·用户执行一些与网站的认证（在范围外）。例如，网站可能请求SLP专用的用户名/密码、或者联合的用户名/密码或者诸如地址、出生日期等的其它用户细节·SLP运营商现在已经将用户与设备标识安全地进行相关联，并且应该将该相关联存储在SLP中。运行时间TLS握手综述·基于客户端认证的设备证书·在ACA产生安全加密的IP连接中，首先使用公钥GLS对服务器进行认证·这通过将设备标识隐藏在设备证书中保持匿名·接下来，客户和服务器基于服务器证书和设备证书执行相互授权的TLS运行时间TLS握手细节·第一个SUPL会话的第一次TLS握手，以便发起服务器授权的安全通道:·SET→SLP:指示对采用服务器证书和设备证书的TLS支持的客户问候·SLP→SET:指示用于采用服务器证书的TLS的密码组的服务器问候·SLP←→SET:完成TLS握手，以便建立安全通道·第二次TLS握手执行相互认证·SLP→SET:问候请求，以便发起重新协商·SET→SLP:指示对采用服务器证书和设备证书的TLS支持的客户问候·SLP→SET:指示具有服务器证书和设备证书的TLS选择的服务器问候·SLP←→SET:完成TLS握手，以便建立安全通道·SET和SLP现在可以在安全通道上进行SUPL会话认证撤回·可以撤回设备和服务器证书·设备和服务器可以使用诸如认证撤回列表（例如，[RFC3280]）或者在线认证状态协议（OCSP）[RFC2560]的方法检查是否撤回了设备证书·专用方法是阶段3考虑SUPLINIT保护综述·SUPL3.0中的SUPLINIT保护是基于SUPL2.0中的SUPLINIT保护机制，并且使用附加到SUPLINIT的消息认证码（MAC）·该安全是防止拒绝在SLP上的服务攻击·SUPLv3.0提供了与SUPLv2.0相同的保护:·模式A保护–如果使用基于GBA的客户端认证就应用–与来自SUPLv2.0的基本保护相同–使用基于GBA的SUPL_INIT_ROOT_KEY–模式B保护–SUPLv3.0使用SLP提供的SUPL_INIT_ROOT_KEY添加支持–支持ACA和设备证书客户端认证·也支持空保护，并且可以基于运营商的选择使用·SUPLv3.0为SLP添加了机制提供SUPL_INIT_ROOT_KEY模式B保护SUPL_INIT_ROOT_KEY·模式BSUPL_INIT保护需要SLP将SUPL_INIT_ROOT_KEY提供给设备·SUPL_INIT_ROOT_KEY对设备和用户的这种组合是唯一的·注意，可以仅为了给SLP提供拒绝服务攻击的保护使用SUPL_INIT_ROOT_KEY·公钥将不暴露任何用户数据·公钥仅添加了一个可以包括在拒绝服务攻击中的额外设备·由于每个SUPL_INIT_ROOT_KEY具有很小的值，所以密钥可能“永久”有效，并且与和订阅相关联的其它细节一起存储·也就是说，对这些密钥进行保护的专用服务器不是必需的·注释:如果移除UICC，由于这指示所有权改变，所以SET就删除SUPL_INIT_ROOT_KEY模式B过程·模式B开始提供·用于开始模式B提供的过程·模式B提供·SLP将SUPL_INIT_ROOT_KEY提供给SET·无SUPL_INIT_ROOT_KEY的模式B使用·如果不提供SUPL_INIT_ROOT_KEY，则SET不验证MAC就接受它从SLP接收的第一条SUPL_INIT消息·有SUPL_INIT_ROOT_KEY的模式B使用·一旦提供了SUPL_INIT_ROOT_KEY，则如果验证MAC和时间正确，SET就接受它从SLP接收的SUPL_INIT消息，并且否则，不接受SUPL_INIT消息·模式B例外–硬重置模式B开始提供·开始SUPL_INIT_ROOT_KEY提供，并且在SET和SLP之间的（安全）ULP会话期间出现SUPL_INIT_ROOT_KEY提供·开始SUPL_INIT_ROOT_KEY提供·如果在安全ULP会话之初，SET注意到它没有SUPL_INIT_ROOT_KEY，则SET就通过将SUPL_INIT_ROOT_KEY_Request指示符包括在第一条ULP消息中开始SUPL_INIT_ROOT_KEY提供·注意到，可以将SET配置为如果否则会话不发生，就在一段时间周期上SUPLINIT失败一些次数之后发起SUPL会话（以便请求SUPL_INIT_ROOT_KEY）·如果SLP怀疑SET中的SUPL_INIT_ROOT_KEY已经被破坏（例如，如果SET不对SUPL_INIT消息作出响应一段时间），则SLP可以在从SET接收到第一条ULP消息之后开始SUPL_INIT_ROOT_KEY提供模式B提供·注释:该过程在“模式B开始提供”之后·如果SLP已经选择不支持模式B保护，则SLP就将合适的指示发送到SET·否则·SLP获得SUPL_INIT_ROOT_KEY·如果SLP具有与SET和用户的这种组合相关联的现存SUPL_INIT_ROOT_KEY，则SLP从其记录中找回该值·如果SLP不具有与SET和用户的这种组合相关联的现存SUPL_INIT_ROOT_KEY，则SLP生成新的SUPL_INIT_ROOT_KEY·SLP将SUPL_INIT_ROOT_KEY作为安全ULP消息中的参数发送到SET·SET存储SUPL_INIT_ROOT_KEY的值·如果所存储的SUPL_INIT_ROOT_KEY值被破坏，SET可以对所存储的值应用某种允许SET稍后进行检测的保护。这种保护的例子包括纠错和/或完整性检查不具有SUPL_INIT_ROOT_KEY的模式B使用·SET可以在可以应用模式B保护的状态中，但它不具有SUPL_INIT_ROOT_KEY。例子包括:·在上电时，在提供SUPL_INIT_ROOT_KEY之前·SUPL_INIT_ROOT_KEY被破坏或者被删除·如果SET在这种状态中，则SET不验证MAC就接受它从SLP接受的第一条SUPL_INIT消息·SET与SLP建立TLS会话·SET执行上述模式B开始提供过程，以便请求SUPL_INIT_ROOT_KEY·如果SLP知道SET在这种状态中，则SLP使用空保护发送SUPL_INIT消息，知道SET无论如何将接受这些消息·在后续ULP会话中，SET或者SLP可以使用上述模式B开始提供过程，以便开始提供SUPL_INIT_ROOT_KEY具有SUPL_INIT_ROOT_KEY的模式B使用·如果SLP认为SET具有SUPL_INIT_ROOT_KEY，则SLP就将SUPLINIT保护符添加到每条SUPLINIT消息–这允许SET检查所接收的SUPLINIT消息的确实性·如果使用模式B保护，则SUPLINIT保护符参数由以下组成：·SUPL_INIT_TIME（长度=4个八位字节）。发送消息的时间。停止重放。·SUPL_INIT_MODE_B_MAC（长度=4个八位字节）.对消息进行认证。·如果SET具有SUPL_INIT_ROOT_KEY，则只要SUPL_INIT_ROOT_KEY有效，SET就接受消息，并且在SUPL_INIT中提供的SUPL_INIT_MODE_B_MAC与SET所计算的值一致SUPL_INIT_MODE_B_MAC计算如下生成SUPL_INIT_MODE_B_MAC参数:·SUPL_INIT_MODE_B_MAC=HMAC-SHA256-32（SUPL_INIT_ROOT_KEY,SUPL_INIT_Z）·SUPL_INIT_Z是具有将SUPL_INIT_MODE_B_MAC字段设置为全零的SUPLINIT消息ModeB例外–硬重置·对于运营商使用SUPLINIT保护的例外情况（e.g.SET和SLP不同步），只要明确地给SET指出（例如，经由重置命令），可以使用空SUPLINIT保护临时重新提供SET，使得拒绝服务攻击不能利用此将未受保护的SUPLINIT发送给大量SET·将该重置命令直接输入SET，以防止引入新的威胁总结·用于SUPL3.0的新的安全模型:使用设备证书的客户端认证·在制造商处提供设备证书·在使用设备证书的客户端认证中也支持SUPLINIT保护·基于设备证书的客户端认证是不可知承载者的安全模型，并且因此适合SUPL3.0·取决于SUPL运营商的选择，仍然可以使用传统安全模型（ACA和GBA）推荐·使用设备证书的客户端认证作为用于SUPL3.0的安全模型·维持对传统ACA和GBA安全模型的支持附加实施例7除了3GPP、3GPP2和WiMax接入网络，用于SUPL2.0的安全解决方案可能是不可用的（例如，可能不支持WiFi接入），并且为了支持强安全性，用于SUPL2.0的安全解决方案包括GBA实现。另外，代替或者除了本地运营商SLP（H-SLP）之外，安全性解决方案可能不允许支持接入相关联的SLP（A-SLP）。该实施例利用通过SLP提供商分配给用户或者用户的支持SUPL的终端（SET）的用户名和密码，以便使用TLS-SRP支持客户（SET）认证。SUPLSET和SLP可以使用公钥TLS，以便允许SET对SLP进行认证。这可以产生安全TLS/IP连接，在其上发生通过SLP使用TLS-SRP（以及预先协议过的用户名和密码）的第二次认证。这可以修改初始安全IP/TLS连接，随后使用其支持安全的SUPL会话。随后，SLP可以使用该SUPL会话给SET提供新的用户名和密码，以便代替最初分配的用户名和密码。新的用户名和密码对于用户可以是不可见的，这可以防止用户在多于一台设备中使用该用户名和密码，并且可以防止用户将初始用户名密码意外传递给其他用户。解决方法可以用于H-SLP和A-SLP，并且不必需仅使用3GPP、3GPP2或者WiMax接入网络。因此，所描述的实施例可以将SUPL安全支持扩展到所有IP接入网络，可以提供比当前所部署的不必须支持GBA的解决方法更强的安全性，并且可以支持H-SLP和A-SLP（章节号可以指SUPL3.0章节号）。6.安全考虑该章节描述了使得SUPL网络能够对SET进行认证和授权并且使得SET能够对SUPL网络进行认证和授权的SUPL安全功能。注释:除非另有说明，使用缩写词TLS是指可以使用TLS握手协商的任何会话:这包括TLS1.1密码组和TLS-PSK密码组。注释:在该章节中，应用下列定义。3GPP承载网络是用于由3GPP所维持的标准的一个网络；这些网络包括GSM、GPRS、EDGE、WCDAM、TD-SCDMA、LTE和LTE-A承载网络。3GPP2承载网络是用于由3GPP2所维持的标准的一个网络；这些网络包括cdmaone、cdma20001x和cdma2000EV-DO承载网络。3GPPSET（分别是3GPP2SET）是其本地网络运营商主要经由3GPP承载网络（分别是3GPP2承载网络）支持数据接入的SET。WiMAXSET是其本地网络运营商主要经由WiMAX承载网络支持数据接入的SET。在不明确的情况下（例如，支持多种接入类型的运营商），运营商可以决定SET的类型。注释:H-SLP运营商应该注意到在这里所描述的认证方法对于在属于相同运营商的接入网络之间的或者SETIP地址不改变的SET切换保持有效。过程不考虑SET从一个接入网络移动到属于不同运营商的另一个接入网络裸着IP地址改变的情景。在这些情景中，假设在切换到另一个接入系统之后，终端和网络中的安全内容可能不可用，并且网络和终端之间的信任级别可能改变。一上电和关闭，检测到新的UICC或者移除UICC，SET手持设备就必须删除SET手持设备上与SUPL3.0相关联的任何密钥（除长期密钥以外），包括■GBA密钥:诸如Ks、Ks_NAF、Ks_ext_NAF■WIMAX密钥:诸如SEK■TLS密钥:诸如pre_master_secret、master_secret和PSK值（除长期密钥以外）.■SUPL专用密钥:诸如与SUPLINIT消息保护相关联的密钥6.1SUPL认证方法对SUPL3.0的认证支持需求如下:·可以支持SET和H-SLP之间的相互认证·可以支持SET和D-SLP之间的相互认证·可以支持SET和E-SLP之间的服务器认证，并且可以支持SET和E-SLP之间的相互认证SUPL3.0支持两种类型的SET认证方法·取决于AN的方法，其中，将认证绑定到SET用户的接入网络订阅·独立于AN的方法，其中，将认证绑定到SET，但是不直接绑定到SET用户的接入网络订阅。可以使用在范围外的过程实现将该认证绑定到SET用户的接入网络订阅。对于在范围外过程的更多讨论，见章节6.6。当执行相互认证时，SET可以经由包含在SET中的SUPL代理起代表SET用户的作用。·对于取决于AN的方法，SET使用与SET用户相关联的安全证书·对于独立于AN的方法，SET使用与SET用户相关联的安全证书注意到，SET用户的成功认证必然导致对SET用户ID（例如，MSISDN、WIMAX用户ID或者独立于AN的用户标识）的成功识别。注意到，当MSISDN用于识别时，SLP在对授权SET用户的MSISDN进行安全识别之前必须执行IMSI到MSISDN的绑定。可以在章节6.1.2中找到密钥管理的细节。6.1.1认证方法章节6.1.1.1列出了在本说明书中支持的认证方法。在章节6.1.1.2中提供了这些方法的提供信息的概述。章节6.1.1.3描述了在各种SUPL3.0实体中哪种方法是强制的或者可选择的，并且如果实体支持给定的相互认证方法，列出了每种实体中所需的协议。6.1.1.1所支持的相互认证方法列表SUPL认证模型需要在SLP和SET之间建立共享密钥；绑定到诸如R-UIM/UICC/SIM/USIM的可移除令牌或者SET手持设备。在该文档中指定了两种类型的认证方法:·基于PSK的方法，由下列方法组成:○取决于AN的基于通用引导架构（GBA）的方法，提供相互认证；○取决于AN的基于SEK的方法（仅可应用于WIMAXSLP），提供相互认证；·基于认证的方法，由下列方法组成:○独立于AN的基于设备证书（DCert）的方法，提供相互认证；○取决于AN的基于可选客户端认证（ACA）的方法，提供相互认证；○独立于AN的仅SLP的方法（仅可应用于紧急情况），仅提供了SLP认证。6.1.1.2所支持的认证方法综述（提供信息的）1.基于通用引导架构（GBA）具有通用引导架构（GBA）的TLS-PSKGBA提供了基于使用现存3GPP/3GPP2认证机制得到的共享密钥的相互认证性能。·使用具有通用引导架构（GBA）的TLS-PSK对SET和SLP进行相互认证。2.基于SEK（仅可应用于WIMAXSLP）·使用具有SEK的TLS-PSK对SET和SLP进行相互认证。可以在章节6.1.2.1.2中找到SEK方法的细节。3.基于设备证书（DCert）该独立于AN的方法使用具有如下认证的TLS·RSA服务器证书，以便将SLP授权给SET·RSA客户端认证，以便将SET授权给SLP4.基于可选客户端认证（ACA）这使用具有如下认证的TLS·RSA认证，以便将SLP授权给SET·可选的SET到SLP的客户端认证（见章节6.1.4）。在该情况下，SLP通过使承载网络确认与SET标识符（MSISDN等）相关联的IP地址对SET进行认证。5.仅SLP这在SLP不可能对SET进行认证的情景中使用。该方法不可以用于非紧急情况。SET不能对该方法和基于ACA的方法作出区分。这使用具有下列认证的TLS·RSA认证，以便将SLP授权给SET·不对SET进行认证6.1.1.3通过实体支持相互认证方法和协议下面的4个表描述了在各种类型的SET以及支持那些SET的SLP中哪些是为了支持SUPL3.0可选和强制的:·第一个表指示为了SUPL3.0在下列SET中实现强制的那些方法和可选的那些方法○3GPP/3GPP2SET○SET（R-）UIM/SIM/USIM和○支持3GPP/3GPP2SET的SLP·第二个表指示为了SUPL3.0在下列SET中实现强制的那些方法和可选的那些方法○WiMAXSET和○支持那些WiMAXSET的SLP·第三个表指示为了SUPL3.0在下列SET中实现强制的那些方法和可选的那些方法○不支持3GPP/3GPP2或者WiMAX的SET和○支持那些SET的SLP·第四个表列出了对于SLP、SET手持设备和（可应用之处）SET（R-）UIM/SIM/USIM为了支持各种认证方法中的每种所需的协议。用于3GPP/3GPP2SET和支持这些SET的SLP的各种认证方法的需求状态（强制或者可选）注释1:对于紧急情况，可能需要SET手持设备支持仅SLP的方法。注释2:用于基于ACA方法的SET过程（仅对于3GPP和3GPP2）与用于仅SLP方法的SET过程是相同的。因此，响应于紧急情况需要仅SLP方法的结果，3GPP/3GPP2SET手持设备支持基于ACA的方法。用于WiMAXSET和支持这些WiMAXSET的SLP的各种认证方法的需求状态（强制或者可选）用于不支持3GPP、3GPP2或者WiMAXSET和支持这些SET的SLP的各种认证方法的需求状态（强制或者可选）用于支持各种相互认证方法的SLP、SET手持设备和SETR-UIM/UICC/SIM/USIM所需的协议在支持基于GBA的方法之处，BSF存储与H-SLP应用相关联的用户安全设置（USS）。当H-SLP请求USS时，BSF必须将SET用户标识（例如，IMPI、IMSI或者MSISDN）包括在USS中。注释:基于GBA的方法不取决于使用3GPP或者3GPP2承载网络传送SUPL会话。然而，为了具有用于执行GBA的必要认证，SET必须具有3GPP或者3GPP2本地网络运营商。6.1.1.4用于最小化TLS握手工作量的技术在该章节中的过程最小化与在SLP和SET之间建立TLS会话相关联的工作量。在与TLS存在冲突之处，TLS获得优先。如果SET和SLP正在同时传送与多于一个SUPL会话相关联的SUPL消息，则SET和SLP应该使用单独一个TLS会话以保护这些消息；也就是说，如果SUPL会话是同时的，SET和SLP不应该建立不同的TLS会话。如果SET和SLP建立TLS会话，则SLP可以允许使用简短握手重发起会话。重发起TLS会话的优点是基于服务器证书重发起TLS会话不需要公共密钥操作:仅需要对称密码组算法（其明显需要更少处理）。注释:对于E-SLP，由于紧急SUPL会话出现太频繁，所以不推荐该方法，以保证存储必要的数据。注释:SLP允许通过分配TLS会话ID重发起会话。注释:由于执行相同的计算，所以重发起TLS-PSK会话不存在优点（如用于基于GBA和SEK的认证）。然而，SLP仍然可以允许重发起TLS-PSK会话。注释:SET通过在TLS握手的客户问候消息中的TLS会话ID参数中包括（将要重发起的TLS会话的）TLS会话ID指示重发起TLS会话的选择。如果SET不希望重发起TLS会话，则SET发送不包括TLS会话ID的TLS客户问候消息，在该情况下，将执行完整握手。如果在TLS客户问候消息中呈现TLS会话ID参数，则SLP就选择是否重发起TLS会话。如果在TLS客户问候消息中没有呈现会话ID参数，则SLP就不可以将TLS握手与之前的TLS会话相关联，因此TLS握手使用完整握手建立新的完整的TLS会话。SET使用下列指导方针选择是否重发起TLS会话。■如果潜在认证（Ks（_ext）_NAF或者SLP认证或者SEK或设备证书）过期，SET不必重发起TLS会话。■如果期望，SET可以选择在潜在认证过期之前不重发起TLS会话。■SET不必重发起在上电或者检测到新的R-UIM/UICC/SIM/USIM之前建立的会话。SLP使用下列指导方针选择是否重发起TLS会话。■如果潜在认证（Ks（_ext）_NAF或者SLP认证或者SEK或设备证书）过期，SET不必重发起TLS会话。■如果期望，SET可以选择在潜在认证过期之前不重发起TLS会话。注释:每个SLP必须为其自身确定是否允许简短的握手，并且甚至可以在逐个SET的基础上作出该决定。当SLP接受重发起现存的TLS会话时，它冒很小的风险。该风险是“淘气的”SET分发master_secret（在完整的TLS会话期间所建立的）、使得其它SET可以重发起该TLS会话，因此允许多个SET获得将对单个SET收费的服务的可能性。“淘气的”SET可能在不知道SET所有者的情况下（例如，恶意代码可能在错误处）这样做。注意到，可以很容易限制丢失:如果SLP检测到（或者怀疑）出现这种滥用，则SLP可以很容易（a）使用该master_secret结束TLS会话，（b）识别出“淘气的”SET并且（c）使用完整握手对“淘气的”SET进行重新认证，以便如果需要允许用户继续拥有服务。总之，对于DCert方法、基于ACA的方法和仅SLP的方法，认为重发起会话的益处（在减少计算方面）超过了攻击的风险。6.1.2用于SUPL认证的密钥管理SUPL认证模型需要在SLP和SET之间建立共享秘密密钥，绑定到诸如R-UIM/UICC/SIM/USIM的可移除令牌或者SET手持设备。6.1.2.1基于PSK的方法6.1.2.1.1支持GBA方法的部署在支持GBA的部署的情况下，如下建立共享密钥:·当SLP从BSF请求密钥材料（为了使IP通信安全并且为了保护SUPLINIT）时，SLP也必须请求USS（用户安全设置）。USS必须包括永久用户标识（例如，IMPI、IMSI或者MSISDN）。·为了使SET和SLP之间的IP通信安全，SET和SLP必须得到共享秘密密钥，并且使用GBA根据TLS-PSK工作。SLP必须具有良好定义的指定SLP的域名SLP_Address_FQDN，例如，slp.operator.com。在OMNA注册中定义了可以用于TLS-PSK的GBAUa安全协议标识符。SLP必须确认BSF所提供的永久用户标识符对应于在相应的安全连接上由SLP所接收的SUPL消息中的SET标识。·对于SUPLINIT的MAC保护，根据GBA得到密钥。在OMNA注册中定义了可以用于SUPLINIT保护的GBAUa安全协议标识符。包括在SUPLINIT消息中的basicMAC的密钥标识符必须是从其生成Ks_NAF的Ks的B-TID。注释:典型地，从BSF对SUPLINIT保护密钥的H/D-SLP请求将与对使IP通信安全的密钥的H/D-SLP请求同时出现。·SET必须确保总是给它提供了有效的Ks。如果不存在有效的Ks，则SET必须开始GBA引导程序过程以便提供Ks。每次SET检测到新的UICC（USIM/SIM/R-UIM）时，必须建立新的Ks。另外，当Ks_NAF的有效期（由本地网络运营商设置）过期时，SET必须建立新的共享密钥。6.1.2.1.2支持SEK方法的部署在支持SEK的部署的情况下，如下建立共享密钥:·为了使SET和SLP之间的IP通信安全，SET和SLP必须得到共享秘密密钥，并且确认由WiMAXAAA服务器提供的永久用户标识对应于SLP在相应的安全连接上所接收的SUPL消息中的SET标识。以下列方式得到共享密钥:○SEK=HMAC-SHA256（LSK,“slp.operator.com”）的16个最重要的（最左边的）八位字节，其中，‘operator.com’是WIMAX运营商的FQDN，并且如在WiMAX网络协议和用于基于定位服务的体系结构中所指定的那样得到LSK。○SEK将继承与LSK相关联的定位密钥标识符（LSK-ID）（如在WiMAX网络协议和用于基于定位服务的体系结构中所定义的），并且对于WiMAX部署，将使用密钥标识作为B-TID。·对于SUPLINIT的MAC完整性保护，以下列方式得到密钥:○SEK_MAC=HMAC-SHA256（LSK,“mac.slp.operator.com”）的16个最重要的（最左边的）八位字节，其中，‘operator.com’是SLP运营商的FQDN，并且如在WiMAX网络协议和用于基于定位服务的体系结构中所指定的那样得到LSK。○包括在SUPLINIT消息中的模式AMAC的密钥标识符必须是从其生成SEK_MAC的LSK的B-TID。注释:典型地，来自WiMAXAAA的对SUPLINIT保护密钥的SLP请求将与对使IP通信安全的密钥的SLP请求同时出现。SET必须确保总是给它提供了有效的SEK。如果不存在有效的SEK，则SEK必须如上所指定的那样得到SEK。另外，当LSK的有效期过期时，SEK必须建立新的共享密钥。SLP和WiMAXAAA服务器之间的接口在SUPL3.0的范围外。6.1.2.2基于服务器证书的方法6.1.2.2.1支持Dcert方法的部署在支持DCert方法的部署的情况下，如下建立共享密钥:·为了使SET和SLP之间的IP通信安全，SET和SLP必须使用具有对SLP进行认证的服务器证书和对SET进行认证的客户端认证的TLS-RSA。客户端认证可以提供全球唯一的SET设备标识:○3GPPSET可以使用IMEI作为全球唯一的SET设备标识。○3GPP2SET可以使用MSID作为全球唯一的SET设备标识。○WiMAXSET可以使用SET序列号作为全球唯一的SET设备标识。○所有其它SET可以使用合适的全球标识符（例如，包括卖主标识的序列号）作为全球唯一的SET设备标识。·SUPL用户必须安全地向SLP验证该设备应该与他们的订阅相关联。该安全验证在本说明书的范围外。关于该主题的更多讨论，见章节6.5。·对于SUPLINIT的MAC完整性保护，由SLP在ULP消息中将密钥提供给SET。这在章节6.3.5中进行了描述。6.1.2.2.2支持ACA方法的部署在支持ACA方法的部署的情况下，如下建立共享密钥:·为了使SET和SLP之间的IP通信安全，SET和SLP必须使用具有对SLP进行认证的服务器证书的TLS-RSA。在章节6.1.4中描述了用于非紧急情况的SET认证并且在章节6.2.5中描述了用于紧急情况的SET认证（其将所得到的共享秘密密钥绑定到）上面所讨论的可移除或者集成令牌）。·对于SUPLINIT的MAC完整性保护，由SLP在ULP消息中将密钥提供给SET。这在章节6.3.5中进行了描述。6.1.2.2.3支持仅SLP方法的部署在支持仅SLP方法的部署的情况下，如下建立共享密钥:·为了使SET和SLP之间的IP通信安全，SET和SLP必须使用具有对SLP进行认证的服务器证书的TLS-RSA。如在章节6.1.4中对于非紧急情况并且在章节6.2.5中对于紧急情况所描述的，不存在SET认证（其将所得到的共享秘密密钥绑定到R-UIM/UICC/SIM/USIM或者SET手持设备）。·在这些情况下不支持SUPLINIT的MAC保护。6.1.3相互认证方法的TLS握手和协商SET和SLP需要就将要应用的相互支持的认证方法取得一致。6.1.3.1关于协商相互认证方法（提供信息的）当建立到H-SLP的TLS连接时，根据下列优先次序，SET首先尝试使用具有最高优先的相互支持的认证机制建立连接:■基于PSK的方法:基于GBA或者SEK的方法首先优先（如果支持）；■DCert方法:第二优先（如果支持）；■ACA或者仅SLP的方法:第三优先（从SET的角度，在基于ACA的方法和仅SLP的方法之间不存在差异）。如果不存在相互支持的认证方法，则SET可能不能执行SUPL会话。由于BSF或者WiMAXAAA经历问题，所以支持基于PSK的方法的SET在给定时间点可能不能使用基于GBA或者SEK的方法。因此，SET尝试使用GBA或者SEK建立认证不保证SET可能能够建立基于GBA或者SEK的密钥。因此，SET可能不总是能够使用相互支持的具有最高优选的认证机制。如果可用，SET可能必须回复到更不优选的相互支持的认证机制。如果仅（在H-SLP认证中）将基于PSK的方法指示为受H-SLP支持，并且引导程序失败，则为了给合适的实体返回在线的机会，SET可以在重新尝试TLS握手之前等待一小会儿。如果SLP仅支持GBA或者SEK，则SLP受限于将SUPL3.0服务提供给已经部署了GBA或者SEK的载波的用户。如果SLP仅支持ACA，则仅可以在章节6.1.4中详细讨论的环境中使用SUPL3.0。注意到在该情况下，如果SET经由对于其SLP不能获得IP绑定的可选承载（诸如无线LAN）进行通信，则SLP将不能对SET进行认证。如果E-SLP仅支持ACA，则如在章节6.2.5中详细讨论的，在SET认证上存在限定。6.1.3.2为非WiMAXSET协商相互认证的方法对于非WiMAXSET，用于SUPL会话的相互认证方法的协商如下继续:1.SET开始协商a.如果SET支持GBA，则SET根据有关GBA规范开始协商。b.否则（也就是说，如果SET不支持GBA），则SET就以客户问候消息开始TLS握手，客户问候.密码组字段指示所支持的为TLS密钥交换算法使用RSA加密的TLS密码组。2.SLP处理所接收的客户问候消息。SLP检查客户问候.密码组列表并且选择相互支持的密码组。a.如果SET和SLP都支持TLS-PSK密码组，则这指示支持GBA。SLP以服务器问候、服务器密钥交换和服务器问候完成消息作出响应，服务器问候.密码组指示相互支持的TLS-PSK密码组。b.否则，SET和SLP必须支持基于认证的方法。i.如果SLP支持DCert方法，则SLP以如下内容作出响应1.具有服务器问候.密码组的服务器问候，指示对于TLS密钥交换算法使用RSA加密的相互支持的TLS密码组，2.认证，3.认证请求和4.服务器问候完成消息。ii.否则，如果SET是3GPP/3GPP2SET并且SLP支持ACA方法，则SLP以如下内容作出响应1.服务器问候认证，具有指示对于TLS密钥交换算法使用RSA加密的相互支持的TLS密码组的服务器问候.密码组。2.认证3.（不发送认证请求消息）4.服务器问候完成消息3.SET处理服务器问候消息和适合于所选择的给SET指示密码组的其它消息a.如果服务器问候.密码组指示SLP已经选择了GBA，则SET和SLP继续GBA过程。细节在本文档的范围外。b.否则，服务器问候.密码组指示对于TLS密钥交换算法使用RSA加密的相互支持的TLS密码组。i.如果SET接收到认证.请求，则1.如果SET支持DCert方法，则SET提供设备证书，并且SET和服务器完成TLS握手。服务器尝试识别对设备证书中与全球唯一的SET设备标识相关联的SUPL用户。假定SUPL用户已经向SLP安全地验证应该将SET设备标识与他们的订阅相关联。a.如果没有识别出SUPL用户，则必须终止会话。由于我们假定已经完成了TLS握手，所以服务器能够在ULP层进行通信。服务器必须发送合适的ULP错误消息以终止ULP会话，并且随后关闭TLS会话。b.如果识别出SUPL用户，则服务器给SET提供与SUPL用户相同的授权。2.否则，SET对SLP作出应答，包括空客户端认证消息，以便暗中指示它不支持DCert方法。a.如果SLP支持ACA，则SLP和SET随着每个ACA方法继续。SLP可以使用ACA方法继续。b.如果SLP不支持ACA或者仅SLP的方法（SLP可能仅支持DCert方法），则SLP以合适的TLS报警消息终止TLS握手。ii.如果服务器不发送认证.请求，则SET随着每个ACA方法继续。SLP可以继续使用ACA方法或者仅SLP的方法。3GPP2SET可以为认证方法协商使用具有所选择的差异的类似的方法。6.1.3.3用于WiMAXSET和SLP的认证和密钥重新协商的原理（提供信息的）密钥重新协商可以以两种方式发生:1.当定位根密钥（如在WiMAX网络协议和体系结构中为基于定位的服务所定义的）过期时，SET自动将其自身与wimax网络重新认证，并且将通过SET重新生成与SUPL相关联的根密钥，或者2.SLP注意到SEK或者定位根密钥（如在WiMAX网络协议和体系结构中为基于定位的服务所定义的）过期时，它将从WiMAXAAA服务器请求新的密钥，或者3.SLP在TLS握手期间发送“psk_标识_未知”TLS报警消息。这向SET指示SET需要将其自身与wimax网络重新认证，并且将通过SET重新生成与SUPL相关联的根密钥。6.1.3.3.1认证过程在WiMAX部署中，可以采用SEK使用PSKTLS握手，如下:-客户问候消息可以包含一个或多个基于PSK的密码组；-客户问候消息可以包含如在其中所指定的服务器_名称扩展，并且它可以包含SLP的主机名称；-服务器问候消息可以包含通过SLP所选择的基于PSK的密码组；-可以通过服务器发送服务器密钥交换，并且它可以包含psk_identity_hint字段，并且它可以包含静态字符串“SUPLWIMAX引导程序”；-客户密钥交换可以包含psk_identity字段，并且它可以包含如在章节6.1.2.1.2中所指定的前缀“SUPLWIMAX引导程序”、一个单独的字符“；”和当前B-TID；-SET可以从SLP专用密钥材料即SEK中得到TLS预控制的密码。6.1.3.3.2认证失败可以如在本文档范围外所描述的对认证失败进行处理。6.1.3.3.3引导程序所需的指示在TLS握手期间，通过发送包含基于PSK的密码组的服务器问候消息以及包含psk_identity_hint字段的服务器密钥交换消息，其包含静态字符串“SUPLWIMAX引导程序”，SLP可以向SET指示可能需要SEK密钥。如果SET不具有有效的SEK，这可能触发SET得到如在章节6.1.2.1.2中所定义的新的SEK。6.1.3.3.4引导程序重新协商指示在使用TLS会话期间，SLP可以通过将close_notify报警消息发送给SET向SET指示SEK已经过期。如果SET通过发送包含旧的会话ID的客户问候消息尝试重发起旧的TLS会话。SLP可以通过发送具有新的会话ID的服务器问候消息拒绝使用旧的会话ID。这将向SET指示它所使用的SEK已经过期。在TLS握手期间，响应于由SET发送的所完成消息，SLP可以通过发送握手_失败消息向SET指示SEK已经过期。这将向SET指示它所使用的SEK已经过期。6.1.4交替客户端认证（ACA）机制该章节仅应用于支持GSM/UMTS和CDMASET的部署。注释:贯穿该章节，SET_ID是指MSISDN（如果SET在3GPP承载网络上）或者MDN、MIN或IMSI之一（如果SET在3GPP2承载网络上）。章节6.1.3概述了SLP可以选择基于ACA的方法的环境。如果SLP在TLS握手期间选择ACA方法，则SLP可以使用基于SET_ID/IP地址映射的客户端认证对SET进行认证。该章节的其余部分描述了已知为可选客户端认证机制的该机制的细节。如果SLP执行可选客户端认证机制，则就推荐SLP也使用具有GBA的PSK-TLS实现该方法。章节6.1.1.3描述了哪个实体必须支持基于ACA的方法，以及支持基于ACA方法的实体必须支持的算法。为了提供信息的目的，在这里重复该信息:■承载网络可以支持基于ACA的方法。如果H-SLP希望为承载网络的用户支持基于ACA的方法，承载网络就必须支持基于ACA的方法。■SLP可以支持基于ACA的方法。■GSM/UMTS和CDMASET手持设备必须支持基于ACA的方法。■基于ACA的方法不包括SETUICC/UIM/SIM/USIM。■基于ACA的方法不包括SPC实体。支持交替客户端认证的SET也必须支持就具有基于认证的服务器（SLP）认证的TLS1.1。另外，必须给SET提供使得它能够验证SLP服务器证书的根认证。存在用于给SET提供根认证的各种不同的方法。没有根据该说明书定义特定机制。SUPL运营商需要确保当为交替客户端认证使用TLS1.1时，相关联的根认证存在于SET中。支持交替客户端认证的SLP必须支持TLS1.1并且必须具有有效的TLS服务器证书，可以通过执行交替客户端认证的SET对其进行验证。交替客户端认证（ACA）机制是SLP可以检查SET的IP地址到分配给SET的SET_ID的绑定的机制。如果执行ACA机制，则SLP必须能够将从SET接收的SUPL消息的源IP地址映射到SLP所使用的SET_ID，以便对SET进行寻址。为了使SLP使用ACA机制，承载网络必须防止在承载级的IP地址欺骗。在源IP地址和SET的SET_ID之间的成功映射将暗示在承载网络上对SET安全地进行识别（例如，认证）。该解决方案不需要在SET上的任何专用客户（SET）认证实现，但是需要SLP支持为特定SET_ID从承载获得正确的源IP地址。3GPP承载特定问题:在所有情况下获得源IP地址将是不可能的–例如，对于在访问而不是本地网络中使用GGSN的GPRS漫游接入。因此，交替客户端认证机制应该仅依赖于本地网络何时分配源IP地址或者具有到它的接入–例如，当可能需要SET使用本地网络中的GGSN时，为GPRS接入所申请的。3GPP2承载特定问题:在所有情况下获得源IP地址将是不可能的–例如，对于在访问网络内使用简单IP或MIP接入的漫游HRPD接入。因此，交替客户端认证机制应该仅依赖于本地网络何时分配源IP地址或者具有到它的接入–例如，当可能需要SET使用到本地网络中的HA的MIP时，为HRPD接入所申请的。章节6.1.4.1描述了如何为SUPL3.0中的客户端认证使用该机制。在使用UDP/IP传送SUPLINIT的情况下，SLP可以首先通过使用SET_ID为SETIP地址查询承载网络或者通过使用IP地址为SET_ID查询承载网络验证IP地址。6.1.4.1ACA过程网络发起的情景:如果在从SLP接收到SUPLINIT消息之后（并且在应用如在本文档中其它地方所描述的合适的安全机制和通知/验证之后），就授权SET继续相应的SUPL会话，则应该使用现存的公开相互认证的TLS会话，或者可以如在章节6.1.1.4中所讨论的重发起之前可恢复的TLS会话。如果不能存在公开的TLS会话，或者SET或SLP选择不重发起会话，则SET和SLP需要新的TLS会话，并且SET和SLP执行如在章节6.1.3中所描述的用于对认证方法进行协商的合适的步骤。当为了对网络发起的情景中的SET进行认证应用交替客户端认证机制时，SLP使用下列步骤:1.注意到，响应于提供SET_ID的MLP请求，发送SUPLINIT消息。SLP为MLP请求分配SLP会话ID，并且发送SUPLINIT。SLP使用SLP会话ID将来自SET的响应与来自MIP的请求相关联。然而，SLP必须首先验证相应的SET对应于正确的SET_ID。剩余的步骤描述了该认证过程。2.SET与SLP建立TLS1.1会话。SET必须检查将SLP所给出的TLS服务器证书绑定到在SET中配置的SLP的FQDN。3.SLP确定来自SET的第一条SUPL消息（响应于SUPLINIT）中的SLP会话ID是否对应于由SLP所分配的当前有效的SLP会话ID。如果第一条SUPL消息中的SLP会话ID不对应于有效的SLP会话ID，则SLP以合适的消息结束SUPL会话。否则，SLP记录相应的SETID。4.在对来自SET的第一条SUPL消息作出响应（SUPLPOSINIT、SUPLSTART、SUPLAUTHREQUEST、SUPLTRIGGEREDSTART、SUPLREPORT或者SUPLEND）之前，SLP必须验证SET的SET_ID。存在用于实现此的两种方法。a.请求SET_IDi.SLP查询潜在承载网络找到使用SET所使用的源IP地址的当前SET_ID。1.如果从用于由SET发送的第一条SUPL消息的源IP地址的承载返回有效的SET_ID，则SLP就检查所返回的SET_ID在内部与正确的SET_ID相关联（见步骤3）。如果该检查失败，则SLP以合适的消息结束SUPL会话。否则，认为SET是可信的，并且SLP继续SUPL会话。2.如果不能找到有效的SET_ID，则SLP必须以相关联SUPL错误消息终止SUPL会话。b.请求IP地址i.SLP查询潜在的承载网络以找到与该SET_ID相关联的SET使用的源IP地址（见步骤3）。1.如果承载网络返回IP地址，则SLP就检查该IP地址对应于第一条SUPL消息的源IP地址。如果该检查失败，则SLP以合适的SUPL消息结束SUPL会话。否则，认为SET是可信的，并且SLP继续SUPL会话。2.如果不能找到IP地址，则SLP必须以相关联SUPL错误消息终止SUPL会话。注释:为了获得SET_ID/IP地址绑定，承载网络可能仅支持步骤4中两种查询类型（请求IP地址或者请求SET_ID）之一。SLP负责符合承载网络所支持的方法。SET发起的情景:当SET希望发起SUPL会话时，应该使用现存公开的相互认证的TLS会话，或者可以如在章节6.1.1.4中所讨论的重发起之前可恢复的TLS会话。如果不存在公开的TLS会话，或者SET或SLP选择不重发起会话，则SET和SLP需要新的TLS会话，并且SET和SLP执行如在章节6.1.3中所描述的用于对认证方法进行协商的合适的步骤。当为了对SET发起的情景中的SET进行认证应用交替客户端认证机制时，SLP使用下列步骤。1.SET与SLP建立TLS1.1会话。SET必须检查将SLP所给出的TLS服务器证书绑定到在SET中所配置的SLP的FQDN。2.在对第一条SUPL消息（例如，SUPLSTART、SUPLTRIGGEREDSTART）作出响应之前，SLP必须验证SET的SET_ID。存在用于实现此的两种方法。a.请求SET_IDi.SLP使用SET所使用的源IP地址查询潜在的承载网络以找到当前的SET_ID。1.如果从承载返回对于由SET发送的第一条SUPL消息的源IP地址有效的SET_ID，则SLP就检查所返回的SET_ID与SET所提供的相同。如果该检查失败，则SLP以合适的消息结束SUPL会话。否则，认为SET是可信赖的，并且SLP继续SUPL会话。2.如果不能找到有效的SET_ID，SLP必须以相关联SUPL错误消息终止SUPL会话。b.请求IP地址i.SLP查询潜在的承载网络以找到与该SET_ID相关联的SET所使用的源IP地址。1.如果承载网络返回IP地址，则SLP检查该IP地址对应于第一条SUPL消息的源IP地址。如果该检查失败，则SLP以合适的消息结束SUPL会话。否则，认为SET是可信赖的，并且SLP继续SUPL会话。2.如果不能找到IP地址，SLP必须以相关联SUPL错误消息终止SUPL会话。注释:在SLP发起的和SET发起的情景中，SLP可以通过给承载网络发送合适的查询对SET进行重新认证，以便将SET_ID绑定到当前正在使用的源IP地址。存在这可能是有用的各种环境，例如：（A）如果SET的IP地址在TLS会话期间改变，则SLP可以给承载网络发送合适的查询，以便确保SET_ID与新的IP地址相关联；（B）当重发起TLS会话时，SLP可以重新使用之前如在章节6.1.1.4中所讨论的TLS会话，从而节约计算，并且简单地将合适的查询发送到承载网络，以便对SET进行认证。注意到，以这种方式对SET进行重新认证不包括与SET自身的相互作用。6.2可应用于E-SLP的认证机制6.2.1关于紧急服务调整主体SUPL3.0紧急SUPL会话可以是网络发起的（使用SUPL）或者SET发起的。合适的紧急服务调整主体将规定对这些紧急会话的支持:·合适的紧急服务调整主体可以不规定对网络发起的或者SET发起的会话的支持；·合适的紧急服务调整主体可以规定仅支持网络发起的会话；·合适的紧急服务调整主体可以规定仅支持SET发起的会话；·合适的紧急服务调整主体可以规定支持网络发起的和SET发起的会话。6.2.2在紧急会话期间SUPL会话区分优先次序对于紧急SUPL会话在SET上的持续时间，必须使SET上的所有SUPL资源对于该紧急会话是可利用的。因此：·当SET发起紧急SUPL会话时，必须立即通过SET终止任何关于非紧急会话的SUPL通信。如果此时SET正在处理非紧急的SUPLINIT消息（例如，具有经验证的MAC或者获得用户许可），则这些过程可能失败，并且可能丢弃SUPLINIT消息。·如果SET在紧急SUPL会话中接收到非紧急SUPLINIT消息，可以丢弃这些SUPLINIT消息。6.2.3E-SLPFQDN在网络发起的紧急SUPL会话中，E-SLP的FQDN可以是：1.提供给SET作为SUPLINIT中的E-SLP地址的FQDN。E-SLPFQDN可以具有“e-slp.xxx.xxx.xxx.xxx.xxx”的格式，其中，“xxx”可以是任何有效的字符串。2.如果不在SUPLINIT中提供FQDN，可以使用所提供的H-SLP地址。3.如果每次上述1或2FQDN是不可用的，可以将FQDN默认为下列3个可选项之一：-（如果连接到3GPP承载网络）如果不明确提供FQDN，就是“e-slp.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org”。在该情况下，MCC和MNC对应于服务3GPP网络。-（如果连接到3GPP2承载网络）如果不明确提供FQDN，就是“e-slp.mnc<MNC>.mcc<MCC>.pub.3gpp2network.org”。在该情况下，MCC和MNC对应于服务3GPP2网络。-（如果连接到WiMAX承载网络）就是“e-slp.operator.com”，其中，operator.com是H-SLP运营商的FQDN。在SET发起的紧急SUPL会话中，E-SLP的FQDN可以是如下优先次序：1.（如果可用）由合适的紧急情况服务调整主体所规定的FQDN。2.由本地接入网络或者通过H-SLP所验证的其它方式提供的FQDN。3.由H-SLP提供的FQDN。6.2.4处理紧急SUPLINIT消息E-SLP不使用SUPLINIT消息基于SET的完整性验证和消息初始认证。因此，不必组装紧急SUPLINIT中的MAC字段。在紧急呼叫期间，SET不可以应用紧急SUPLINIT消息的端到端保护。通过使用E-SLP白名单提供了一些保护。E-SLP白名单基于对SET的当前位置估计（诸如蜂窝ID和/或网络ID）。SET使用E-SLP白名单确定SET应该对所接收的紧急SUPLINIT消息进行处理的次序：E-SLP白名单不可以用于丢弃紧急SUPLINIT消息。6.2.4.1E-SLP白名单如果在不安全的端到端信道上（诸如SMS或者OMA推送或UDP/IP）接收紧急SUPLINIT消息，则紧急SUPLINIT消息可以是伪造或者改变的。该章节的剩余部分描述了用于确保SET能够尽可能联系真正的E-SLP服务器的安全措施。注释:调整需求将规定SET应该接受和处理紧急SUPLINIT消息的条件。例如，在许多情况下，调整需求仅需要如果SET当前正在参与紧急呼叫，SET就接受和处理紧急SUPLINIT消息。因此，条件（在该条件下SET应该接受和处理紧急SUPLINIT消息）在本文档的范围外。当SET接收紧急SUPLINIT消息时，SET必须首先验证当前满足条件（在该条件下SET应该接受紧急SUPLINIT消息）。如果不满足条件，则SET刻意忽略SUPLINIT消息。关于此的描述假定当SET接收紧急SUPLINIT消息时满足条件。注释:攻击者可能在SET正在期望真正的紧急SUPLINIT消息的同时给SET发送多个（虚假的）紧急消息。可能存在不能（提前）告诉SET期望来自哪个紧急SLP的紧急SUPLINIT消息的情况。该攻击是下列过程的动机。对于满足“接受和处理”条件的时期，即使紧急SUPLINIT消息列出了对于E-SLP不期望的地址，SET也不必删除所接收的紧急SUPLINIT消息。一旦SET确定不再满足条件（例如，一旦联系了正确的E-SLP，或者在紧急呼叫之后已经经过了足够时间），则SET必须默默地丢弃任何所接收的紧急SUPLINIT消息。如果SET接收、接受和处理虚假的紧急SUPLINIT消息（当仍然满足“接受和处理”条件时），则SET可能不接收紧急SUPLINIT消息是虚假的指示，直到尝试联系在紧急SUPLINIT消息中所指示的E-SLP为止。当E-SLP拒绝SUPL会话时，出现该指示。该过程不是即时的，因此SET可能必须查询紧急SUPLINIT消息它是否接收到多于一条紧急SUPLINIT消息。E-SLP白名单包含SET可以期望从其接收紧急SUPLINIT消息的E-SLPFQDN列表。SET使用E-SLP白名单以确保应该在包括不在白名单上的E-SLPFQDN的紧急SUPLINIT消息之前对包括在白名单上的E-SLPFQDN的紧急SUPLINIT消息进行处理。示例:将包含在白名单上的E-SLPFQDN的紧急SUPLINIT消息推送到紧急SUPLINIT队列，以便确保在对包含不在白名单上的E-SLPFQDN的紧急SUPLINIT消息之前对消息进行处理。E-SLP白名单应该是用于对紧急SUPLINIT队列进行排序的第一准则。第二准则是到达时间，使用先入先出原则:·如果SET具有对于SET当前位置的当前E-SLP白名单，则SET使用两个准则对队列进行排序。·如果SET不具有对于SET当前位置的当前E-SLP白名单，则SET使用先入先出原则对队列进行排序。6.2.4.3关于紧急SUPLINIT消息的过程如果在端到端安全的信道（诸如安全SIP推送）上接收到紧急SUPLINIT，则可以立即对紧急SUPLINIT消息进行处理。在该情况下，忽略该子章节的剩余考虑。如果在不是端到端安全的信道（诸如SMS或者OMA推送或UDP/IP）上接收到紧急SUPLINIT消息，则如在章节6.2.4.1中对消息进行排队。SET通过队列中的消息工作，在尝试连接到E-SLP以便作出响应之前应用合适的验证和通知。响应于SUPLINIT消息，SET可以与相关联E-SLP（见章节6.2.3）建立安全的TLS会话（见章节6.2.5），并且下列之一发生：■如果在对SET认证之后（见章节6.2.5），E-SLP不能将SET与任何显著的SUPL会话相关联，则E-SLP可以结束会话。如果还没有完成TLS握手，为了节约不必要的计算，则E-SLP应该使用TLS错误消息结束会话。如果完成TLS握手，则E-SLP可以使用指示没有对SET进行授权的SUPL错误消息结束会话。SET可以将错误消息的任何一种形式解释为SUPLINIT消息是欺骗性的指示。随后，SET以在队列中优先权的次序对下一个SUPLINIT消息进行处理。■如果，在对SET进行认证之后（见章节6.2.5），E-SLP能够将SET与显著的SUPL会话相关联，则SET和E-SLP如正常继续。SET继续对紧急SUPLINIT消息作出响应，直到找到真正的消息为止。一旦识别出正确的E-SLP，SET可以丢弃任何新的或者已排队的SUPLINIT消息。仍然可以对来自正确E-SLP的新的或者已排队的SUPLINIT消息进行处理。下列两个注释是调整主题可能希望考虑的建议。注释:一旦识别出正确的E-SLP，则SET就应该确保它记得该正确的E-SLP的FQDN直到SUPL会话成功地完成为止。如果与E-SLP的TLS会话过早地结束（例如，如果存在数据丢失连接），SET就应该继续尝试与E-SLP重新建立TLS会话，直到重新建立TLS会话使得SUPL会话可以继续成功完成为止。在一些情况下，可以想象SET重新建立TLS会话若干次。如果SET在重新建立TLS会话时没有获得成功，无论如何SET就应该继续尝试：由于这是紧急情况，成功的益处比缺点蓄电池的开销更有价值。注释:如果E-SLP在认证之后但是在成功完成SUPL会话之前丢失与SET的联系，则E-SLP应该保持SUPL会话公开，希望SET能够重新建立联系并且完成SUPL会话。6.2.5用于紧急会话的认证注释:在章节6.1.1.3中指定了E-SLP可以支持的相互认证的方法。如在章节6.1.3中所指定的，SET和E-SLP在TLS握手期间协商相互认证方法。用于紧急会话的优先次序是·GBA或者SEK方法:第一优先·DCert方法:第二优先·ACA方法:第三优先·仅SLP的方法:最后优先。应该将仅SLP的方法视为最后手段。在章节6.2.3中讨论了用于所有这些情况的E-SLP的FQDN。基于GBA的方法（仅3GPP/3GPP2SET）:如在章节6.1.3中所描述的，SET和E-SLP可以采用GBA执行PSK-TLS，E-SLP作为NAF。对于网络运营商设置的有效期，可以保留由E-SLP为特定SET获得的Ks_NAF与SET标识（例如，IMSI、MSISDN）相关联。基于SEK的方法（仅WiMAXSET）:如在章节6.1.3中所描述的，SET和E-SLP可以采用SEK使用PSK-TLS执行相互认证，E-SLP以与H-SLP类似的方式作用。在章节6.2.3中讨论了E-SLP的FQDN。对于网络运营商设置的有效期，可以保留由E-SLP为特定SET获得的SEK与SET标识（例如，WiMAX用户ID）相关联。DCert方法（所有SET）:如在章节6.1.2.2.1中所描述的，SET和E-SLP可以使用DCert方法执行相互认证。如在章节6.2.3中所定义的，SET可以使用包含在SET中的E-SLP的根认证和E-SLP的FQDN对E-SLP进行认证。基于ACA的方法（仅当在相应的承载网络上的3GPP/3GPP2SET）:对于在E-SLP中不支持采用PSK-TLS的GBA和DCert方法的SUPL3.0实现，可以支持在章节6.1.4中定义的可选客户端认证机制，具有如下差异。E-SLP可以通过将SET所使用的IP地址与服务网络提供给E-SLP的用于SET的IP地址绑定对SET进行认证，-例如，通过3GPP网络中或者3GPP2网络中的LRF或者E-CSCF。·网络发起的会话:由于使用SETIP地址发起任何紧急VoIP呼叫，并且在唤醒SUPL之前可以通过服务网络对SETIP地址进行验证，所以E-SLP可以认为它是可靠的。在电路模式中发起紧急呼叫的情况下，SETIP地址对于服务网络可能是未知的（例如，可以通过本地网络分配），在该情况下，不能通过服务网络给E-SLP提供IP地址，并且当稍后从SET接收时，不能验证IP地址。·SET发起的会话:为了使用ACA方法，服务承载网络必须防止在承载级的IP地址欺骗。应该注意到，无论SET是否在承载网络上注册为授权的，都可以应用ACA方法。这支持在SET中不存在激活SIM/USIM/UICC/（R）UIM的情况。仅SLP方法（所有SET）:如果不能使用其它认证方法，则SET可以使用仅SLP的方法建立到E-SLP的安全IP连接。SET可以使用如在章节6.2.3中所定义的包含在SET中的E-SLP的根认证和E-SLP的FQDN对E-SLP进行认证。执行相互认证的能力取决于会话是SET发起的还是网络发起的。·网络发起的会话:如果SUPL会话是网络发起的，则E-SLP可以基于（例如）如在章节6.2.6中所讨论的会话ID和所接收的SUPLINIT的散列对SET进行微弱认证·SET发起的会话:如果SUPL会话是SET发起的应该注意到，无论SET是否在承载网络上注册为授权的，都可以应用仅SLP的方法。这支持在SET中不存在激活SIM/USIM/UICC/（R）UIM的情况。6.2.6用于紧急SUPL会话的SUPLINIT的完整性保护如果E-SLP能够如在章节6.2.5中所讨论的对SET进行认证，并且E-SLP可以将SET与显著的SUPL会话相关联，则E-SLP就检查SUPLINIT消息是否改变。如果E-SLP检测到SUPLINIT消息改变（例如，如在章节6.3.1中所描述的，如果当指示代理模式时接收到SUPLAUTHREQ消息，或者如果SLP会话ID是错误的，或者如果VER验证失败），则E-SLP必须在TLS会话上将SUPLINIT发送给SET，以便确保给SET提供正确的参数。作为响应，SET将丢弃使用它最初接收的SUPLINIT发起的SUPL会话，并且SET可以使用在TLS会话上接收的SUPLINIT发起新的SUPL会话。随后，SET可以立即对该SUPLINIT消息进行处理（即，SET不使用E-SLP白名单评估优先权）、执行用于通知和验证的合适的行为，并且假如用户不拒绝会话，则SET就将合适的消息（SUPLPOSINIT或者SUPLAUTHREQ）发送给E-SLP以便继续会话。重新发送SUPLINIT的能力仅仅旨在为了紧急会话。在非紧会话中，如果检测到SUPLINIT的改变，则如在非紧急呼叫流中所指定的，SLP可以使用SUPLEND结束SUPL会话。6.3SUPLINIT消息的处理由于网络发起的SUPL会话是通过SUPLINIT消息触发的，所以必需保护SUPLINIT消息对抗伪装并且（在一些情况下）对抗重放攻击。SUPL3.0为SUPLINIT消息指定了下列保护:·基于网络的安全，其中，SLP可以执行检查，以确保SUPLINIT消息的认证（章节6.3.1）和重放保护（章节6.3.2）。在SET对SUPLINIT消息的内容进行处理并且为了执行SUPL会话的目的与SLP建立了安全的TLS会话之后，发生该验证。·端到端安全，其中：SLP可以给SUPLINIT消息应用加密、完整性保护和重放保护的组合；并且SET应用相应的解密、完整性验证和重放检测的组合。SET在对SUPLINIT消息的内容进行处理之前应用这些安全措施。该安全性仅应用于非紧急SUPLINIT消息。基于网络的安全性是强制的，而端到端安全性是可选的。6.3.1SUPLINIT消息基于网络的认证SLP总是执行SUPLINIT消息完整性的网络验证。响应于SUPLINIT消息而发送的第一条消息（即，SUPLPOSINIT、SUPLAUTHREQ或者SUPLTRIGGEREDSTART消息）必须包含验证字段（VER）。当SLP接收到响应于SUPLINIT消息而发送的第一条消息时，SLP必须检查所接收的VER字段与在所发送的SUPLINIT消息上计算的相应值。如果该验证失败，SLP必须以包含状态码‘authSuplinitFailure’的SUPLEND消息终止会话。必须如下计算用于验证字段的值：·VER=H（SLPXORopad,H（SLPXORipad,SUPLINIT））其中，SLP是SLP地址的FQDN。SHA-256必须用作采用opad和ipad的散列（H）函数。必须将SHA-256HASH函数的输出截短到64比特，即必须将函数实现为HMAC-SHA256-64。注意到，不认为SLP地址是秘密的。这里所使用的HMAC结构不提供任何数据认证，而是仅用作对HASH函数的替换。6.3.2SUPLINIT消息基于网络的重放保护对于网络发起的情况，必须由SLP提供保护对抗重放攻击。除非已经与对应于在SUPL消息内部所接收的“SLP会话Id”一起发送了之前未过期的SUPLINIT消息，否则SLP必须确保没有从授权SET接受SUPL消息。SLP还必须确保SUPL消息的类型（例如，SUPLPOSINIT、SUPLAUTHREQ、SUPLTRIGGEREDSTART）与在SUPLINIT消息中发送的参数一致。实现必须确保将“SLP会话Id”与已经授权的SET用户ID（例如，MSISDN、WiMAX用户ID或MDN）正确相关联。如果使用本文档中所描述的可选客户端认证方法执行SET用户认证，则已经建立了在来自SET的响应的源IP地址（UPLPOSINIT、SUPLAUTHREQ或SUPLTRIGGEREDSTART）和SET用户的MSISDN或MDN之间的映射，并且必须使用该MSISDN或MDN作为授权的MSISDN或MDN。抛弃错误，SUPLPOSINIT、SUPLAUTHREQ或SUPLTRIGGEREDSTART不必生成对于SET可收费的事件。对于非代理网络发起的情况，SLP必须仅在从SPC接收到对成功完成SUPL定位确认之后创建可收费的事件。6.3.3SUPLINIT消息的端到端保护注释:SUPLINIT消息的端到端保护仅应用于非紧急SUPLINIT消息。在本说明书中提供了端到端SUPLINIT保护的三种选规则：空、模式A和模式B。·空SUPLINIT保护不提供端到端完整性保护、不提供端到端重放保护并且不提供机密性保护。在章节6.3.4中描述了用于空SUPLINIT保护的过程。·模式ASUPLINIT保护使用默认算法提供端到端完整性保护和端到端重放保护。模式ASUPLINIT保护使用SLP在安全ULP会话期间发送给SET的共享密钥。在章节6.3.5中描述了用于模式ASUPLINIT保护的过程。·模式BSUPLINIT保护使用默认算法提供端到端完整性保护和端到端重放保护。模式BSUPLINIT保护使用利用合适的基于PSK的方法（GBA或者SEK方法）得到的共享密钥。在章节6.3.6中描述了用于模式BSUPLINIT保护的过程。对于保护级的优先权次序如下：■空SUPLINIT保护具有最小优先权。■模式ASUPLINIT保护具有比空SUPLINIT保护更高的优先权。■模式BSUPLINIT保护具有比模式ASUPLINIT保护更高的优先权。在SUPLINIT消息中，根据当前保护级分配保护等级参数（在下表中）。注释:书写本说明书以便允许在未来修订中添加更先进的保护级别。该先进保护可以允许为了使SUPLINIT安全的其它方式的协商（例如，允许加密并且允许算法协商）。包括保护等级参数以便帮助SET确定它是否能够解析SUPLINIT消息：为了扩展，可能需要保护等级参数。SUPLINIT消息具有为了包括安全参数呈现的保护器参数：在下表中指定了保护器参数的呈现。SUPLINIT保护等级参数值和SUPLINIT保护器参数的呈现支持基于ACA的方法的SET或D-SLP或H-SLP必须支持空SUPLINIT保护。所有的SET必须支持模式ASUPLINIT保护过程。D-SLP或者H-SLP可以支持模式ASUPLINIT保护过程。SET或者D-SLP或者支持基于PSK方法的H-SLP必须支持模式BSUPLINIT保护过程。E-SLP实体不包括在当前定义的SUPLINIT保护中。6.3.3.1协商SUPLINIT保护级别下列过程仅应用于是D-SLP和H-SLP的SLP，过程不应用于E-SLP。如何协商SUPLINIT保护等级的非正式描述如下：1.当不存在有效的SUPL_INIT_ROOT_KEY时（例如，在上电时或者当SUPL_INIT_ROOT_KEY的有效期过期时），SET必须应用空SUPLINIT保护。最初的保护等级总是空SUPLINIT保护。在该状态中，SET处理所有SUPLINIT消息，即不静静地丢弃任何消息。如果以错误条件对SUPLINIT消息进行解析，SET就将错误消息发送给SLP。2.如果SET具有有效的SUPL_INIT_ROOT_KEY以及对于特定SLP已经使用模式A或者模式BSUPLINIT保护协商的有效的ReplayCounter，则SET使用协商模式（模式A或者模式B）对来自该SLP的所有SUPLINIT消息进行处理。3.当SET建立到SLP的相互认证的安全连接时，a.如果为相互认证使用基于PSK的方法（GBA或者SEK），则模式BSUPLINIT保护应用，并且在PSK-TLS握手中交换的B-TID对应于Ks（将用作3GPP和3GPP2部署中的Ks_NAF）或者可以用于得到将用作3GPP和3GPP2部署中的Ks_NAF的SUPL_INIT_ROOT_KEY的SEK。在模式BSUPLINIT保护中使用该Ks_NAF或者SEK以及相关联的B-TID，直到下列条件之一为止：i.密钥过期，在该情况下，SET和SLP回复空SUPLINIT保护，ii.SET和SLP在非紧急会话中使用ACA方法，在该情况下，如在以下步骤3b中所讨论的，SET和SLP回复模式A或者空SUPLINIT保护，或者iii.SET和H-SLP使用GBA或者SEK的引导程序重新协商方法使用新的B-TID建立TLS，在该情况下，现在B-TID和相应的Ks_NAF或SEK用于模式BSUPLINIT保护。b.否则，SET和SLP使用DCert或ACA方法建立安全连接。i.如果SET不具有有效的SUPL_INIT_ROOT_KEY，则SET在第一条ULP消息中将SUPL_INIT_KeyRequest参数发送给SLP。1.如果SLP支持模式ASUPLINIT保护，则SLP通过在第一个对SET的ULP响应中发送模式密钥标识符、临时模式A密钥标识符、SUPL_INIT_ROOT_KEY和基本重放计数器参数作出响应。当SET接收这些参数时，则这向SET指示模式ASUPLINIT保护应用。注释:用于更新SUPL_INIT_ROOT_KEY的策略是SLP运营商的决定。2.如果SLP不支持模式ASUPLINIT保护（或者在该特定时间不支持模式ASUPLINIT保护），则SLP就给SET（在ULP消息中）发送空SUPLINIT保护应用的指示。ii.如果SET具有有效的SUPL_INIT_ROOT_KEY，但是不具有有效的临时模式A密钥标识符或者丢失了关于重放保护的同步，则SET在第一条ULP消息中将SUPL_INIT_ResynchRequest参数发送给SLP。1.如果SLP支持模式ASUPLINIT保护，则SLP使用在章节6.3.6.1.1中所指定的过程以新的临时模式A密钥标识符作出响应（在对SET的第一次响应中）。当SET接收到该响应时，则这向SET指示模式ASUPLINIT保护应用。2.如果SLP不支持模式ASUPLINIT保护（或者在该特定时间不支持模式ASUPLINIT保护），则SLP给SET（在ULP消息中）发送空SUPLINIT保护应用的指示。注意到，这意味着每次SET建立到H-SLP的新的TLS连接时，都重新协商保护等级。6.3.3.2从H-SLP角度的协商如果使用GBA或者SEK方法对与SET的最新IP会话进行认证，并且H-SLP具有当前B-TID和用于SET的相关联密钥，则■如果B-TID是用于使用GBA获得的密钥，则H-SLP分配SUPL_INIT_ROOT_KEY是对应于最新B-TID的Ks_（int/ext_）NAF，并且如下生成○FQDN可以是H-SLP_FQDN○在OMNA注册中定义了可以用于SUPL_INIT保护的GBAUa安全协议标识符■如果B-TID是用于使用SEK方法获得的密钥，则SUPL_INIT_ROOT_KEY是如在6.1.2.1.2中所定义的SEK■假定没有协商任何其它SUPLINIT保护，则H-SLP为该SET分配模式BSUPLINIT保护等级。否则，如果H-SLP具有有效的模式A密钥标识符以及用于SET的相关联密钥，则H-SLP为该SET分配模式ASUPLINIT保护等级。如果没有分配其它保护级别，则H-SLP为该SET分配空SUPLINIT保护等级。H-SLP应用对应于当前所分配的SUPLINIT保护级别的过程（为了在递送之前处理SUPLINIT消息）。这包括为SUPLINIT消息中的保护等级参数分配合适的值。6.3.3.3从SET角度的协商如果使用GBA或者SEK方法对与H-SLP的最新IP会话进行认证，并且SET具有当前B-TID和用于该IP会话的相关联密钥，则■如果B-TID是用于使用GBA获得的密钥，则SET分配SUPL_INIT_ROOT_KEY是对应于最新B-TID的Ks_（int/ext_）NAF，并且如下生成○FQDN可以是H-SLP_FQDN○在OMNA注册中定义了可以用于SUPL_INIT保护的GBAUa安全协议标识符■如果B-TID是用于使用SEK方法获得的密钥，则SUPL_INIT_ROOT_KEY是如在6.1.2.1.2中所定义的SEK■假定没有协商任何其它SUPLINIT保护，则SET分配模式BSUPLINIT保护等级。否则，如果SET具有有效的模式A密钥标识符、相关联密钥以及用于H-SLP的模式A重放计数器，则H-SLP为该SET分配模式ASUPLINIT保护等级。如果没有分配其它保护级别，则SET分配空SUPLINIT保护级别。SET应用对应于当前所分配的SUPLINIT保护的过程（为了处理所接收的SUPLINIT消息）。6.3.3.4例外过程如果SET确定SET发起的SUPLINIT保护参数已经被破坏，则SET必须与H-SLP建立TLS会话：·如果使用GBA认证，则SET必须发起GBA引导程序以便建立新的密钥；·对于使用SEK方法的SET，SET必须发起SEK引导程序以便使能新的密钥；·否则，SET在第一条安全ULP消息中发送SUPL_INIT_KeyRequest，并且跟随在章节6.3.3.1的步骤3.b中的过程之后。如果SLP丢失安全内容（例如，大量数据丢失），则SLP将没有办法发起定位行为。当Ks_NAF过期或者SET连接到SLP时，将重建内容。为了防止这种“封闭窗口”，SLP应该确保以充分从该情景中恢复的冗余存储所有SUPLINIT安全内容信息。6.3.4当分配空保护级别时的规范注释:对于空SUPLINIT保护不存在SUPLINIT保护器。6.3.4.1H-SLP过程对于专用于空SUPLINIT保护的SLP不存在安全过程。6.3.4.2SET过程当分配空SUPLINIT保护并且SET接收到SUPLINIT消息时，则SET应用下列过程：■如果保护等级参数是正确的，则SET认为消息是可信的，并且可以不需要关于安全的处理。○假定SLP和SET可以支持更高的保护级别，但是由于正在上电，SET还没有与SLP联系：在该情况下，SET将具有空SUPLINIT保护分配。在直到SET联系SLP为止的时期中，SET将认为任何所接收的SUPLINIT消息（具有正确的保护等级参数）是可信的。当SET首次联系SLP时（其可以或者可以不是对所接收的SUPLINIT消息作出响应），SET和SLP将转换到更高的保护级别。一旦两个实体转换到更高的保护级别，SET可以检测未认证的SUPLINIT消息。在当SET上电时和当SET首次联系SLP时之间，存在SET可以接收不可信的SUPLINIT消息的时期，其中，好像该SUPLINIT消息是可信的一样，SET对其进行处理。如果SET决定继续进行与未认证SUPLINIT消息相关联的SUPL会话，则SET将联系SLP并且建立安全的TLS会话。由于使用不可信的SUPLINIT消息建立SUPL会话，所以SLP将不允许SUPL会话。如果SET和SLP支持更高的保护级别，则这将同时建立，并且SET此后将能够检测不可信的SUPL消息。这意味着，如果SET和SLP可以支持更高的保护级别，则存在非常小的攻击者使SET接受不可信的SUPLINIT消息的机会窗口，并且SET将仅为至多一条不可信的SUPLINIT消息尝试继续进行SUPL会话。■如果保护等级参数不正确（即，如果保护等级参数是除了空之外的其它任何内容），则SET将合适的错误消息发送给SLP。○在SLP和SET处的保护级别失去同步的情况下，该过程允许SET和SLP在公共保护级别上进行重新同步。6.3.5用于模式ASUPLINIT保护级别的规范6.3.5.1用于模式ASUPLINIT保护的密钥标识符模式ASUPLINIT保护使用使用可以与SUPLINIT消息一起发送的两个密钥标识符：模式A密钥标识符和临时模式A密钥标识符。·模式A密钥标识符是全球唯一的、与SUPL_INIT_ROOT_KEY相关联的长期密钥标识符。仅当SLP为SUPL_INIT_ROOT_KEY提供新的值时，SLP给SET提供新的模式A密钥标识符。·临时模式A密钥标识符是与模式A密钥标识符相关联的短期标识（假名）。临时模式A密钥标识符在临时模式A密钥标识符有效期间可以是全球唯一的。如在章节6.3.5.3和6.3.5.4中所述，SET和SLP对临时模式A密钥标识符的值进行同步。典型地，SLP将使用临时模式A密钥标识符作为基本SUPLINIT保护器中的密钥标识符。随后，SET使用临时模式A密钥标识符确定应该使用哪个SUPL_INIT_ROOT_KEY验证基本SUPLINIT保护器。典型地，不在SUPLINIT消息中发送模式A密钥标识符，因为这将允许观测者将多条SUPLINIT消息与公共SET用户相关联。临时模式A密钥标识符的目的是防止威胁代理使用模式A密钥标识符将多条SUPLINIT消息与SET用户相关联。仅SLP和SET应该能够将临时模式A密钥标识符与模式A密钥标识符相关联。改变临时模式A密钥标识符的频率主要是SET用户的决定。SLP可以基于SLP策略选择为临时模式A密钥标识符建立新的值。然而，存在SLP可能希望使用长期模式A密钥标识符作为基本SUPLINIT保护器中的密钥标识符的情况。例如，假定SET还没有使用基本SUPLINIT保护器中的临时模式A密钥标识符对多条SUPLINIT消息作出响应。SLP可能关心SET已经丢失关于临时模式A密钥标识符的同步。SET和SLP更可能保持在长期模式A密钥标识符上的同步。因此，SLP可以使用基本SUPLINIT保护器中的模式A密钥标识符发送SUPLINIT消息，以确保同步丢失不防止SET验证SUPLINIT消息。6.3.5.2模式ASUPLINIT保护和基本SUPLINIT保护器模式ASUPLINIT保护使用如在章节6.3.7中所定义的基本SUPLINIT保护器和相关联过程，具有下列附加澄清：■密钥标识符类型:指示使用模式A密钥标识符还是临时模式A密钥标识符。■密钥标识符:对应于模式A密钥标识符还是临时模式A密钥标识符作为适合于模式A密钥标识符类型。■使用SUPL_INIT_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“ModeAIK”）计算BasicMAC，使用与上述密钥标识符相关联的SUPL_INIT_ROOT_KEY。6.3.5.3H-SLP过程仅模式A专用的H-SLP过程涉及维持SET和SLP之间的同步。通过SLP在发送新的临时模式A密钥标识符参数（在到安全ULP会话中的SET的第一条响应消息中）之后发送新的临时模式A密钥标识符建立对于临时模式A密钥标识符的新的值。建立新的临时模式A密钥标识符导致将BasicLastReplayCounter重置为0x0000，并且SET移除关于“所播放的”SUPLINIT消息的所有信息。响应于SUPL_INIT_ResynchRequest或者SLP的内部决定（在范围外），SLP可以建立新的临时模式A密钥标识符。也就是说，即使当不存在来自SET的相应的SUPL_INIT_ResynchRequest时，SLP也可以发送临时模式A密钥标识符。6.3.5.4SET过程仅模式A专用的SET过程涉及维持SET和SLP之间的同步。SET可以通过在ULP会话的第一条消息中发送SUPL_INIT_ResynchRequest触发为临时模式A密钥标识符建立新的值。如果通过SET分配了模式ASUPLINIT，则在SET采用给定的临时模式A密钥标识符对SUPLINIT消息进行处理之前，SET清理它的具有为基本重放计数器使用过的值的缓存。6.3.6用于模式BSUPLINIT保护级别的规范模式BSUPLINIT保护使用如在章节0中所定义的基本SUPLINIT保护器和相关联过程，具有下列附加澄清：■密钥标识符类型:对于模式BSUPLINIT保护，仅支持B-TID标识符。■密钥标识符:对应于当前B-TID■使用SUPL_INIT_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“ModeAIK”）计算BasicMAC参数，其中：○对于基于GBA的部署，SUPL_INIT_ROOT_KEY是对应于最新B-TID的Ks_（int/ext_）NAF，并且如在OMNA注册中所定义的使用用于SUPLINIT保护的GBAUa安全协议标识符生成。○对于基于SEK的部署，SUPL_INIT_ROOT_KEY是如在章节6.1.2.1.2中所定义的SEK_MAC。6.3.6.1H-SLP过程仅模式B专用的H-SLP过程涉及维持SET和SLP之间的同步。对于模式BSUPLINIT保护，首次使用密钥时，将SLP中的基本重放计数器重置为零，并且SET移除关于“已播放的”SUPLINIT消息的所有信息。在SLP确定可能需要重新同步的不太可能的情况下：·在部署支持GBA方法的情况下，SLP通过使GBAB-TID无效触发重新同步。当SET接下来尝试对SLP进行认证时，则SLP将以TLS-PSK报警“psk_identity_unknown”作出响应。这提示建立新的GBA密钥。·在部署支持SEK方法的情况下，SLP通过使SEKB-TID无效触发重新同步。当该SET接下来尝试对SLP进行认证时，则SLP将以TLS-PSK报警“psk_identity_unknown”作出响应。这提示建立如在章节6.1.3.3中所描述的新的SEK。6.3.6.2SET过程仅模式B专用的SET过程涉及维持SET和SLP之间的同步。如果通过SET分配了模式BSUPLINIT保护，则·在SET首次采用给定的SUPL_INIT_ROOT_KEY对SUPLINIT消息进行处理之前，SET清理它的具有为基本重放计数器使用过的值的缓存。·SET可以通过建立适当的新的GBAKs或者新的SEK触发重新同步。SLP将继续使用旧的GBAKs（或SEK），直到SET和SLP之间下一次成功认证为止，因此SET应该维持旧的GBAKs（或SEK）直到那时为止。6.3.7用于使用基本SUPLINIT保护器的规范基本SUPLINIT保护器用于模式A和模式BSUPLINIT保护，包括下列参数：■密钥标识符类型:长度=1个八位字节■密钥标识符:可变长度。对应于用于计算BasicMAC的密钥■基本重放计数器:长度=2个八位字节■BasicMAC:长度=4个八位字节如下生成BasicMAC参数：■BasicMAC=HMAC-SHA256-32（SUPL_INIT_Basic_IK,SUPL_INIT’），其中■根据章节6.3.5和6.3.6分别为模式A和模式BSUPLINIT保护得到SUPL_INIT_Basic_IK，■SUPL_INIT’对应于分配了除了BasicMAC之外的所有参数的SUPLINIT，并且具有设置为全零的MAC参数，并且■在本文档范围之外的文档中规定了HMAC-SHA256-32和HMAC-SHA256-128。6.3.7.1H-SLP过程在其它地方规定了对于模式A和模式BSUPLINIT保护的用于模式A最后重放计数器同步的SLP过程。如果给SET分配了模式A或模式BSUPLINIT保护，则H-SLP由SUPLINIT消息组成，如下：1.如其它处所述分配SUPLINIT保护器之外的参数。2.根据SLP将用于该消息的密钥标识符的类型设置密钥标识符类型。3.将密钥标识设备为与SUPL_INIT_ROOT_KEY相关联的密钥标识。4.H-SLP将基本最后重放计数器值（与该SET相关联以及经协商的SUPLINIT保护级别）的当前值增大1，并且将新的值插入基本重放计数器参数中。5.最后，在分配了所有其它参数之后，如上所规定的那样，从SUPLINIT和SUPL_INIT_ROOT_KEY计算出BasicMAC。可能需要H-SLP为每个分配了模式A或者模式BSUPLINIT保护等级的SET存储长度等于基本重放计数器参数长度的基本最后重放计数器值。如果SLP中的基本最后重放计数器值接近65535=216-1（其未必很高），则SLP必须触发重新同步过程（见章节6.3.6.1和6.3.7.1）。6.3.7.2SET过程在其它地方规定了对于模式A和模式BSUPLINIT保护的用于模式A最后重放计数器同步的SET过程。如果分配了模式A或模式BSUPLINIT保护，则SET对所接收的SUPLINIT消息进行处理，如下：1.如果下列参数不能合适地验证，SET就丢弃SUPLINIT消息：■保护级别:必须是为经协商的SUPLINIT保护级别所分配的值■密钥标识类型:对于所分配的SUPLINIT保护级别必须是有效的■密钥标识:必须对应于用于经协商的SUPLINIT保护级别的当前SUPL_INIT_ROOT_KEY■级别重放计数器:SET使用该值检测消息的重放。技术可以是实现专用的，但是必须足够健壮，以便处理SUPLINIT消息丢失或者不按次序递送的情况。■BasicMAC:SET从SUPLINIT和SUPL_INIT_ROOT_KEY（如上所述）计算所期望的BasicMAC，并且将这与所接收的BasicMAC进行比较：值必须相等。2.如果在之前步骤中没有丢失SUPLINIT，则认为它是可信的，并且SET考虑使用基本重放计数器值。如果基本重放计数器值接近65535=216-1（其未必很高），则SET必须与SLP建立新的SUPL_INIT_ROOT_KEY，以便重置计数器。6.4给SET提供H-SLP地址注释:为独立于接入网络的H-SLP提供H-SLP地址是FFS。通过在UICC中提供H-SLP地址使H-SLP地址对SET可用，如下所述得到SET或者默认H-SLP地址。该地址必须是FQDN的形式，并且应该通过SET的本地网络安全地提供。6.4.13GPP2SET对于3GPP2SET，必须在UIM或者R-UIM中安全地提供H-SLP地址。6.4.23GPPSET3GPPSET必须读取H-SLP地址（以FQDN的形式）作为在WAPPROVCONT中所指定的“APPADDR/ADDR”字符下的参数“ADDR”。另外，如在关于适应3GPP的UICC（USIM/SIM）的OMA智能卡供应规范中或者在SET的等效安全区域中所定义的，必须将H-SLP地址安全地存储在发起程序文件中。SET必须支持OMA智能卡供应机制，以便读取H-SLP地址。USIM/SIM应用或者存储H-SLP地址的SET中的发起程序文件必须是用户不可改变的。如果在UICC（USIM/SIM）中配置H-SLP地址，SET必须首先读取在UICC中提供的H-SLP地址。如果在UICC中不提供H-SLP地址，则SET可以从SET上的安全区域读取H-SLP地址。在SET中提供H-SLP地址:如果将H-SLP地址存储在SET上的安全位置中，就必须使用OMA设备管理V1.2或者稍后提供它。如果使用OMADM提供H-SLP地址，SET必须基于在TLS握手期间通过DM服务器呈现的服务器侧的认证对OMADM服务器进行认证。如果SET支持H-SLP地址的存储，它就不必依赖在章节6.1.4中所提出的认证机制，即基于MSISDN/IP地址映射认证的交替客户端认证，即SET必须依赖如在章节6.1.1中所描述的PSK-TLS相互认证方法。H-SLP地址的自动配置:如果不能在UICC的安全存储区域（USIM/SIM）中或者在SET的安全区域中找到H-SLP地址，SET就必须基于存储在USIM/SIM中的IMSI配置SET中的默认H-SLP地址。在UICC的安全存储区域（USIM/SIM）中或者在SET的安全区域中找到H-SLP地址、但是其使用导致认证失败同时发起SUPL会话的情况下，SET必须基于存储在USIM/SIM中的IMSI配置SET中的默认H-SLP地址。配置默认H-SLP地址的机制定义如下。请注意，从3GPPGBA规范中取得并且为对（基于FQDN）配置H-SLP地址的SUPL使用情况采用下列例子。默认配置机制的实现不需要3GPPGBA规范的实现。给出下面的例子以便仅对方法进行说明，并且可以独立于GBA实现。基于IMSI的H-SLP配置:步骤1）取决于使用2位还是3位数字MNC并且将它们分成MCC和MNC，取IMSI的前5位或6位数字；如果MNC是2位数字，则可以在开始处添加零；步骤2）使用在步骤1中得到的MCC和MNC创建“mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org”域名；将标志“h-slp.”添加到域名的开始处。示例1:如果使用的IMSI是“234150999999999”，其中，MCC=234、MNC=15并且MSIN=0999999999，则H-SLP地址将是“h-slp.mnc015.mcc234.pub.3gppnetwork.org”。如果SET在上电期间或者在上电之后检测到新的IMSI，就必须从SET移除所有之前的H-SLP设置。更具体地说，必须移除任何存储在SET中的H-SLP地址。在改变IMSI的情况下，SET必须首先从UICC（USIM/SIM）读取H-SLP地址。如果UICC（USIM/SIM）上没有存储H-SLP地址，SET可以检查H-SLP地址是否存储在SET上。如果在UICC或者SET上没有找到H-SLP地址，则如上所述，SET必须基于新的IMSI配置默认H-SLP地址。实现必须确保在SET安装制造商软件之后不能经由下载到SET的应用改变H-SLP的地址。下列流程示出了H-SLP地址存储。1.开始。转到2。2.IMSI是否改变？如果是，转到3。如果否，跳过3并且直接转到4。3.从SET中清除H-SLP。转到4。4.UICC是否包含H-SLP地址？如果否，转到5。如果是，转到9。5.是否支持SET上的H-SLP地址如果否，转到9。如果是，转到6。6.是否在SET中提供了H-SLP地址？如果否，转到7。如果是，转到8。7.从IMSI创建H-SLP地址。转到10。8.从SET中读取设置。转到10。9.从UICC中读取H-SLP地址。转到10。10.使用H-SLP地址创建到H-SLP的TLS连接。转到11。11.认证是否成功？如果否，转到12。如果是，转到14。12.是否从IMSI创建H-SL地址？如果否，转到7。如果是，转到13。13.中止SUPL会话并且结束。14.运行SUPL会话并且结束。6.4.3基于WIMAX的部署当SET连上WiMAX网络时，它可以经由OMADM接收更新的H-SLP地址。当以安全方式将H-SLP地址提供给WiMAX终端时，必须将它存储在受保护的环境中。6.5机密性和数据完整性协议可以使用TLS1.1或者PSK-TLS提供SET和SLP之间的机密性和数据完整性。必须在SET和SLP之间的TLS或者PSK-TLS会话内递送除了“SUPLINIT”之外的所有SUPL消息。章节6.1.1.3提供了用于确定SUPL3.0部署中的哪个实体使采用服务器证书认证的TLS和/或TLS-PSK作为强制或者可选的细节。6.5.1采用服务器证书的TLS采用服务器证书的TLS的实现可以符合下列澄清，并且TLS1.1的WAP简介具有下列澄清：SET可以实现:·TLS_RSA_WITH_AES_128_CBC_SHA.对于优选附加密码组的SET实现，SET应该实现:·TLS_RSA_WITH_3DES_EDE_CBC_SHA.支持采用服务器证书的TLS1.1的SLP可以实现下列密码组:·TLS_RSA_WITH_3DES_EDE_CBC_SHA.·TLS_RSA_WITH_AES_128_CBC_SHA.对于支持具有服务器证书的TLS1.1的、优选支持空加密的SLP实现，SLP可以实现TLS_RSA_WITH_NULL_SHA。注意到，由于它不提供任何机密性保护，所以不推荐使用TLS_RSA_WITH_NULL_SHA。然而，它仍然提供认证和完整性保护。支持采用服务器证书的TLS1.1的SLP和SET可以支持TLS1.1的WAP认证简介。6.5.2TLS-PSKTLS-PSK实现可以符合用于TLS握手的PSK-TLS，具有为TLS1.1定义的大量密码。支持TLS-PSK的SET可以实现:·TLS_PSK_WITH_AES_128_CBC_SHA对于支持优选附加密码组的TLS-PSK的SET实现，SET应该实现:·TLS_PSK_WITH_3DES_EDE_CBC_SHA可以通过SLP实现下列密码组:·TLS_PSK_WITH_AES_128_CBC_SHA对于支持优选附加密码组的TLS-PSK的SLP实现，SLP应该实现：·TLS_PSK_WITH_3DES_EDE_CBC_SHA可以通过支持无代理模式的SPC实现下列密码组：·TLS_PSK_WITH_AES_128_CBC_SHA对于支持优选附加密码组的无代理模式的SPC实现，SPC应该实现：·TLS_PSK_WITH_3DES_EDE_CBC_SHA6.6DCert方法和用户绑定DCert方法对SET手持装置进行认证，但是（不像GBA、SEK和ACA方法）不执行依靠接入网络认证的任何认证。如果SLP为相互认证使用DCert方法，则SLP运营商需要某些其它机制验证哪个SUPL用户应该与SET相关联。使用术语“用户绑定”描述将SUPL用户与SET标识相关联。如果SET所有者改变，则联系SLP运营商释放用户绑定是现有SUPL用户的责任。虽然在章节6.6.1中示出了一种可能过程，但是SUPL3.0不指定用户绑定过程。一些SLP可以将用户绑定过程合并为SLP运营商所提供的其它服务的一部分。在其它情况下，用户绑定可以是分配链条的一部分。SLP运营商可以使用他们选择的任何“用户绑定”过程，但是应该考虑下列点:·必须将SUPL用户认证为用户绑定过程的一部分。○对SUPL用户认证失败将允许服务盗用，并且允许威胁代理误导SLP关于所识别SUPL用户的定位。○我们推荐SLP运营商为用户认证应用他们现有的机制和策略。·必须将SET认证为用户绑定过程的一部分。○原因是微妙的。假定威胁代理希望追随Alice的运动并且Alice拥有具有SET标识“SET_ID_A”的SET。威胁代理注册为合法SUPL用户，并且在对她自己进行认证之后，要求拥有具有SET标识“SET_ID_A”的SET。如果SLP运营商将该SET与威胁代理的账号相关联，则威胁代理可以授权它们自己从SLP（经由网络发起的会话）获得周期性的定位更新。然而，由于Alice正在使用SET，威胁代理实际上得到Alice的定位更新。由于SLP运营商预期保持Alice的定位是秘密的，所以防止这种攻击是在SLP运营商的感兴趣范围内。6.6.1示例用户绑定过程主要为具有网页浏览能力的SET设计了DCert方法：例子包括智能电话、写字板或者触摸屏多媒体播放器。这种SET可以使用下列机制:1.SLP运营商提示SUPL用户在使用SET时连接到SLP所拥有的网页服务器的URL。2.用于在使用SET时连接到网站（可能是WAP）。3.网页服务器和SET执行TLS。a.网页服务器提供服务器证书，并且请求客户端认证。网页服务器的认证可以与用于SUPL服务的SLP服务器证书的认证不同。b.SET可以对网页服务器进行认证。c.SET使用SET的设备证书向网页服务器认证。d.网页服务器现在已经认证安全信道与设备证书中的SET标识（例如，IMEI、MEID或者序列号）相关联。4.SUPL用户执行与网站的一些认证（在范围外）。例如，网页服务器可以请求SLP专用的用户名/密码，或者联合用户名/密码或者诸如地址、出生日期等的其它用户细节。5.SLP运营商现在将用户与设备标识安全地相关联，并且应该将该关联存储在SLP中。附加实施例8SUPL3.0已经定义了模式A和模式BSUPLINIT保护。模式A保护需要SLP具有在安全ULP会话期间将共享密钥发送到SET的能力。该实施例描述了共享密钥参数，并且指示将要使用哪条ULP消息请求和发送共享密钥。因此，可以将该实施例合并入SUPL3.0中，并且章节号可以称为SUPL3.0章节。6.3.3SUPLINIT/REINIT消息的端到端保护注释:SUPLINIT消息的端到端保护仅应用于非紧急SUPLINIT/REINIT消息。章节6.3.3中的过程仅应用于是D-SLP和H-SLP的SLP；过程不应用于E-SLP。用于SUPLINIT和SUPLREINIT消息的端到端保护的过程在SUPLINIT和SUPLREINIT消息之间没有区别，-对SUPLINIT和SUPLREINIT消息进行处理就好像它们是相同类型的消息。为简便起见，我们将这些过程称为SUPLINIT保护过程–使用SUPLINIT保护过程对SUPLINIT和SUPLREINIT消息进行处理。在本说明书中提供了端到端SUPLINIT保护的三种选项：空、模式A和模式B。·空SUPLINIT保护不提供端到端完整性保护、不提供端到端重放保护并且不提供机密性保护。在章节6.3.4中描述了用于空SUPLINIT保护的过程。·模式ASUPLINIT保护使用默认算法提供端到端完整性保护和端到端重放保护。模式ASUPLINIT保护使用SLP在安全ULP会话期间发送给SET的共享密钥。在章节6.3.5中描述了用于模式ASUPLINIT保护的过程。·模式BSUPLINIT保护使用默认算法提供端到端完整性保护和端到端重放保护。模式BSUPLINIT保护使用利用合适的基于PSK的方法（GBA或者SEK方法）得到的共享密钥。在章节6.3.6中描述了用于模式BSUPLINIT保护的过程。对于保护级的优先权次序如下：■空SUPLINIT保护具有最小优先权。■模式ASUPLINIT保护具有比空SUPLINIT保护更高的优先权。■模式BSUPLINIT保护具有比模式ASUPLINIT保护更高的优先权。在SUPLINIT消息中，根据当前保护级分配保护等级参数（在下表中）。注释:书写本说明书以便允许在未来修订中添加更先进的保护级别。该先进保护可以允许为了使SUPLINIT/REINIT安全的其它方式的协商（例如，允许加密并且允许算法协商）。包括保护等级参数以便帮助SET确定它是否能够解析SUPLINIT/REINIT消息：为了扩展，需要保护等级参数。SUPLINIT/REINIT消息具有为了包括安全参数呈现的保护器参数：在下表中指定了保护器参数的呈现。SUPLINIT保护等级参数值以及SUPLINIT和SUPLREINIT消息中保护器参数的呈现支持基于ACA的方法的SET或D-SLP或H-SLP必须支持空SUPLINIT保护。所有的SET应该支持模式ASUPLINIT保护过程。D-SLP或者H-SLP可以支持模式ASUPLINIT保护过程。SET或者D-SLP或者支持基于PSK方法的H-SLP必须支持模式BSUPLINIT保护过程。E-SLP实体不包括在当前定义的SUPLINIT保护中。6.3.3.1协商SUPLINIT保护级别下列过程仅应用于是D-SLP和H-SLP的SLP；过程不应用于E-SLP。对如何协商SUPLINIT保护等级的非正式说明如下：1.当不存在有效的SUPL_INIT_ROOT_KEY时（例如，在上电时或者当SUPL_INIT_ROOT_KEY的有效期过期时），SET必须应用空SUPLINIT保护。初始保护等级总是空SUPLINIT保护。在该状态下，SET对所有的SUPLINIT/REINIT消息进行处理，即不静静地丢弃任何消息。如果采用错误条件对SUPLINIT/REINIT消息进行解析，SET就将错误消息发送到SLP。2.如果SET具有有效的SUPL_INIT_ROOT_KEY和对于特定SLP已经使用模式A或者模式BSUPLINIT保护协商的有效的重放计数器，则SET对所有SUPLINIT/REINIT消息进行处理，SLP从其中使用经协商的模式（模式A或者模式B）。3.当SET建立到SLP的相互认证的安全连接时，a.如果为相互认证使用基于PSK的方法（GBA或者SEK），则模式BSUPLINIT保护应用，并且在PSK-TLS握手中交换的B-TID对应于Ks（在3GPP和3GPP2部署中将用作Ks_NAF）或者可以用于得到将在3GPP和3GPP2部署中用作Ks_NAF的SUPL_INIT_ROOT_KEY的SEK。在模式BSUPLINIT保护中使用该Ks_NAF或者SEK以及相关联的B-TID，直到下列条件之一为止：i.密钥过期，在该情况下，SET和SLP回复空SUPLINIT保护，ii.SET和SLP在非紧急会话中使用ACA方法，在该情况下，如在以下步骤3b中所讨论的，SET和SLP回复模式A或者空SUPLINIT保护，或者iii.SET和H-SLP使用GBA或者SEK的引导程序重新协商方法使用新的B-TID建立TLS，在该情况下，现在B-TID和相应的Ks_NAF或SEK用于模式BSUPLINIT保护。b.否则，SET和SLP使用DCert或ACA方法建立安全连接。i.如果SET不具有有效的SUPL_INIT_ROOT_KEY，则它在安全会话建立之后携带SET能力参数的下一条ULP消息中的SET性能（sUPLINITRootKeyStatus=“invalidSUPLINITRootKey”）中将此指示给SLP。1.如果SLP支持模式ASUPLINIT保护，则SLP在下一条SUPLEND消息中执行模式ASUPL_INIT_ROOT_KEY建立过程（章节6.3.5.2）。成功的模式ASUPL_INIT_ROOT_KEY建立过程向SET指示模式ASUPLINIT保护应用。直到成功的模式ASUPL_INIT_ROOT_KEY建立过程出现为止，SET应该使用空SUPLINIT保护。注释:用于更新SUPL_INIT_ROOT_KEY的策略是SLP运营商的决定。2.如果SLP不支持模式ASUPLINIT保护（或者在该特定时间不支持模式ASUPLINIT保护），则SLP不发送模式A密钥标识符、临时模式A密钥标识符、SUPL_INIT_ROOT_KEY和模式A密钥有效期参数，其指示SET应该使用空SUPLINIT保护。ii.如果SET具有有效的SUPL_INIT_ROOT_KEY，但是不具有有效的临时模式A密钥标识符或者已经丢失关于重放保护的同步，则它就在安全会话建立之后携带SET能力参数的下一条ULP消息中的SET性能（sUPLINITRootKeyStatus=“outofsyncSUPLINITRootKey”）中将此指示给SLP。1.在下一条SUPLEND消息中执行模式A重新同步过程（章节6.3.5.3）。成功的模式A重新同步过程向SET指示模式ASUPLINIT保护应用。直到成功的模式A重新同步过程出现为止，SET应该使用空SUPLINIT保护。2.如果SLP不支持模式ASUPLINIT保护（或者在该特定时间不希望支持模式ASUPLINIT保护），则SLP不执行模式A重新同步（见章节6.3.5.3），其指示SET应该使用空SUPLINIT保护。注意到，这意味着每次SET建立到SLP的新的TLS连接，就对保护等级进行重新协商。6.3.3.2从SLP角度的协商如果使用GBA或者SEK方法对与SET的最新IP会话进行认证，并且SLP具有当前B-TID和用于SET的相关联密钥，则■如果B-TID是用于使用GBA获得的密钥，则SLP分配SUPL_INIT_ROOT_KEY是对应于最新B-TID的Ks_（int/ext_）NAF，并且如下生成○FQDN应该是SLP_FQDN○在OMNA注册中[OMNA]定义了应该用于SUPL_INIT保护的GBAUa安全协议标识符■如果B-TID是用于使用SEK方法获得的密钥，则SUPL_INIT_ROOT_KEY是如在6.1.2.1.2中所定义的SEK■假定没有协商任何其它SUPLINIT保护，则SLP为该SET分配模式BSUPLINIT保护等级。否则，如果SLP具有有效的模式A密钥标识符以及用于SET的相关联密钥，则SLP为该SET分配模式ASUPLINIT保护等级。如果没有分配其它保护级别，则SLP为该SET分配空SUPLINIT保护等级。SLP应用对应于当前所分配的SUPLINIT/REINIT保护级别的过程（为了在递送之前处理SUPLINIT/REINIT消息）。这包括为SUPLINIT消息中的保护等级参数分配合适的值。6.3.3.3从SET角度的协商如果使用GBA或者SEK方法对与SLP的最新IP会话进行认证，并且SET具有当前B-TID和用于该IP会话的相关联密钥，则■如果B-TID是用于使用GBA获得的密钥，则SET分配SUPL_INIT_ROOT_KEY是对应于最新B-TID的Ks_（int/ext_）NAF，并且如下生成○FQDN应该是SLP_FQDN○在OMNA注册中[OMNA]定义了应该用于SUPL_INIT保护的GBAUa安全协议标识符[3GPP24.109]■如果B-TID是用于使用SEK方法获得的密钥，则SUPL_INIT_ROOT_KEY是如在6.1.2.1.2中所定义的SEK■假定没有协商任何其它SUPLINIT保护，则SET分配模式BSUPLINIT保护等级。否则，如果SET具有有效的模式A密钥标识符、临时模式A密钥标识符以及用于SLP的相关联SUPL_INIT_ROOT_KEY，则SET为该SLP分配模式ASUPLINIT保护等级。如果没有分配其它保护级别，则SET分配空SUPLINIT保护级别。SET应用对应于当前所分配的SUPLINIT保护的过程（为了处理所接收的SUPLINIT/REINIT消息）。6.3.3.4例外过程如果SET确定SET内部的SUPLINIT保护参数已经被破坏，则SET必须与SLP建立TLS会话：·如果使用GBA认证，则SET必须发起GBA引导程序以便建立新的密钥；·对于使用SEK方法的SET，如在章节6.1.2.1.2中所定义的，SET必须发起SEK引导程序以便使能新的密钥；·否则，SET跟随在章节6.3.3.1的步骤3.b中的过程之后。如果SLP丢失安全内容（例如，大量数据丢失），则SLP将没有办法发起定位行为。当Ks_NAF或SEK过期或者SET连接到SLP时，将重建内容。为了防止这种“封闭窗口”，SLP应该确保以充分从该情景中恢复的冗余存储所有SUPLINIT保护安全内容信息。6.3.3.5用于在SET处对SUPLINIT消息进行处理的一般过程SET应用下列过程，以便确定如何对所接收的SUPLINIT消息进行处理。1.SET对发送SIP（发送SUPLINIT消息的SLP）进行识别。a.如果在SUPLINIT消息中存在D-SLPFQDN参数，则SET应该使用该参数对发送SLP进行识别。i.如果SET与所识别的D-SLP没有现有的关系，则SET应该静静地丢弃SUPLINIT消息并且退出当前过程。ii.否则，SET继续进行到步骤2。b.如果在SUPLINIT消息中不存在D-SLPFQDN参数，则SET将发送SLP识别为SET的H-SLP。2.SET基于为发送SLP分配的SUPLINIT保护等级执行初始过滤：a.如果为发送SLP分配空SUPLINIT保护，则SET执行空SUPLINIT保护过程，并且退出当前过程。b.如果为发送SLP分配模式A或者模式BSUPLINIT保护，则i.如果SUPLINIT消息不包含保护器参数，则SET静静地丢弃SUPLINIT消息并且退出当前过程。ii.如果SUPLINIT消息包含保护器参数，则SET分别执行章节6.3.5或者章节6.3.6中合适的模式A或模式BSUPLINIT保护过程。SET使用保护器参数中的密钥标识符参数，以便识别为了处理SUPLINIT消息使用与发送SLP相关联的哪个SUPLINITROOT密钥。6.3.5用于模式ASUPLINIT保护级别的规范6.3.5.1用于模式ASUPLINIT保护的密钥标识符模式ASUPLINIT保护使用使用可以与SUPLINIT/REINIT消息一起发送的两个密钥标识符：模式A密钥标识符和临时模式A密钥标识符。·模式A密钥标识符是全球唯一的、与SUPL_INIT_ROOT_KEY相关联的长期密钥标识符。仅当SLP为SUPL_INIT_ROOT_KEY提供新的值时，SLP给SET提供新的模式A密钥标识符。·临时模式A密钥标识符是与模式A密钥标识符相关联的短期标识（假名）。临时模式A密钥标识符在临时模式A密钥标识符有效期间可以是全球唯一的。如在章节6.3.5.5和6.3.5.6中所述，SET和SLP对临时模式A密钥标识符的值进行同步。典型地，SLP将使用临时模式A密钥标识符作为基本SUPLINIT保护器中的密钥标识符。随后，SET使用临时模式A密钥标识符确定应该使用哪个SUPL_INIT_ROOT_KEY验证基本SUPLINIT保护器。典型地，不在SUPLINIT/REINIT消息中发送模式A密钥标识符，因为这将允许观测者将多条SUPLINIT/REINIT消息与公共SET用户相关联。临时模式A密钥标识符的目的是防止威胁代理使用模式A密钥标识符将多条SUPLINIT/REINIT消息与SET用户相关联。仅SLP和SET应该能够将临时模式A密钥标识符与模式A密钥标识符相关联。改变临时模式A密钥标识符的频率主要是SET用户的决定。SLP可以基于SLP策略选择为临时模式A密钥标识符建立新的值。然而，存在SLP可能希望使用长期模式A密钥标识符作为基本SUPLINIT保护器中的密钥标识符的情况。例如，假定SET还没有使用基本SUPLINIT保护器中的临时模式A密钥标识符对多条SUPLINIT/REINIT消息作出响应。SLP可能关心SET已经丢失关于临时模式A密钥标识符的同步。SET和SLP更可能保持在长期模式A密钥标识符上的同步。因此，SLP可以使用基本SUPLINIT保护器中的模式A密钥标识符发送SUPLINIT/REINIT消息，以确保同步丢失不防止SET验证SUPLINIT/REINIT消息。6.3.5.2模式ASUPL_INIT_ROOT_KEY建立过程通过SLP（在安全SUPL会话中发送给SET的SUPLEND消息中）发送新的模式A密钥标识符、临时模式A密钥标识符、SUPL_INIT_ROOT_KEY和模式A密钥有效期参数建立对于SUPL_INIT_ROOT_KEY的值。如果递送成功，则SLP和SET认为该模式ASUPL_INIT_ROOT_KEY建立过程是成功的。模式A密钥有效期参数包含当密钥停止有效时的UTC时间。6.3.5.3模式A重新同步过程SLP使用下列步骤与SET建立用于临时模式A密钥标识符的新的值：1.SLP将当前模式A密钥标识符和新的临时模式A密钥标识符参数发送给SET（在安全SUPL会话中发送给SET的SUPLEND消息中）。如果递送成功，则SLP认为该模式A重新同步过程是成功的。2.SET将所接收的模式A密钥标识符与具有SET当前为该SLP分配的有效SUPL_INIT_ROOT_KEY值的模式A密钥标识符进行比较。a.如果模式A密钥标识符值不同，则这指示在SET上分配的模式A密钥标识符值的破坏，并且执行下列步骤：i.SET丢弃临时模式A密钥标识符，并且认为该模式A重新同步是失败的。ii.SET开始章节6.3.3.4中的例外过程。b.如果所接收的模式A密钥标识符等于有效的模式A密钥标识符，则：i.SET将新的临时模式A密钥标识符与相应的模式A密钥标识符相关联，ii.SET认为该模式A重新同步是成功的。6.3.5.4模式ASUPLINIT保护和基本SUPLINIT保护器模式ASUPLINIT保护使用如在章节0中所定义的基本SUPLINIT保护器和相关联过程，具有下列附加澄清：■密钥标识符类型:指示使用模式A密钥标识符还是临时模式A密钥标识符。■密钥标识符:对应于模式A密钥标识符还是临时模式A密钥标识符作为适合于模式A密钥标识符类型。■使用SUPL_INIT_Basic_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“ModeAIK”）计算BasicMAC，使用与上述密钥标识符相关联的SUPL_INIT_ROOT_KEY。6.3.5.5SLP过程仅模式A专用的SLP过程涉及SUPLINITROOTKEY建立、SUPL_INIT_ROOT_KEY过期、以及维持SET和SLP之间的同步。在章节6.3.5.2中指定了模式ASUPL_INIT_ROOT_KEY建立过程。响应于SET的不同步指示（在SET性能（sUPLINITRootKeyStatus=”invalidSUPLINITRootKey”）中）或者SLP的（在范围之外）内部决定，SLP可以执行模式ASUPL_INIT_ROOT_KEY建立过程。也就是说，即使当不存在由SET发送的相应指示时，SLP也可以发送SUPL_INIT_ROOT_KEY（采用相关联参数）。在下列时间早期之后，SUPL_INIT_ROOT_KEY和相关联参数应该停止在SLP中有效·相关联模式A密钥标识符的有效期，以及·稍后成功的模式ASUPL_INIT_ROOT_KEY建立的时间（章节6.3.5.2）在章节6.3.5.3中指定了模式A重新同步过程。响应于SET的不同步指示（在SET性能（sUPLINITRootKeyStatus=”outofsyncSUPLINITRootKey”）中）或者SLP的（在范围之外）内部决定，SLP可以执行模式A重新同步过程。也就是说，即使当不存在由SET发送的相应指示时，SLP也可以发送临时模式A密钥标识符。在成功的模式ASUPL_INIT_ROOT_KEY建立过程和成功的模式A重新同步过程之后，SLP将基本最后重放计数器重置为0x0000。6.3.5.6SET过程仅模式A专用的SET过程涉及SUPLINITROOTKEY建立、SUPL_INIT_ROOT_KEY过期、以及维持SET和SLP之间的同步。在章节6.3.5.2中指定了模式ASUPL_INIT_ROOT_KEY建立过程。SET可以通过在安全会话建立之后携带SET能力参数的ULP消息中指示它在SET中不具有有效的SUPL_INIT_ROOT_KEY（在SET性能（sUPLINITRootKeyStatus=”invalidSUPLINITRootKey”）中）来尝试触发模式ASUPL_INIT_ROOT_KEY建立过程。在下列时间早期之后，应该认为所建立的SUPL_INIT_ROOT_KEY和相关联参数在SET中无效。·相关联模式A密钥标识符的有效期。·稍后成功的模式ASUPL_INIT_ROOT_KEY建立时间之后5分钟（章节6.3.5.2）。由于使用先前的SUPL_INIT_ROOT_KEY将保护该SUPLINIT消息，所以该时间延迟允许递送在最近的模式ASUPL_INIT_ROOT_KEY建立过程之前发送的任何SUPLINIT消息的递送。·SET检测到SUPL_INIT_ROOT_KEY、模式A密钥标识符和模式A密钥有效期的值的破坏的任何时间。如果发生破坏，则SET应该开始章节6.3.3.4中的例外过程。在章节6.3.5.3中指定了模式A重新同步过程。SET可以通过在安全会话建立之后携带SET能力参数的ULP消息中指示在SET中丢失同步（在SET性能（sUPLINITRootKeyStatus=”outofsyncSUPLINITRootKey”）中）来尝试触发模式A重新同步过程。成功的模式ASUPL_INIT_ROOT_KEY建立过程或者成功的模式A重新同步过程之后，SET清理它的具有为基本重放计数器使用过的值的缓存（由于SLP也将基本重放计数器重置为0x0000）。6.3.7对于使用基本SUPLINIT保护器的规范为模式A和模式BSUPLINIT保护使用的基本SUPLINIT保护器包括下列参数：■密钥标识符类型■密钥标识符:长度=8个八位字节■基本重放计数器:长度=2个八位字节■BasicMAC:长度=4个八位字节.如下生成BasicMAC参数:■BasicMAC=HMAC-SHA256-32（SUPL_INIT_Basic_IK,SUPL_INIT/REINIT’），其中■根据分别用于模式A和模式BSUPLINIT保护的章节6.3.5和6.3.6得到SUPL_INIT_Basic_IK，■SUPL_INIT/REINIT’对应于SUPLINIT/REINIT消息，分配除了BasicMAC之外的所有参数，并且具有设置为全零的MAC参数，并且■在[HMAC]中指定HMAC-SHA256-32和HMAC-SHA256-128。6.1.1.2所支持的认证方法综述（提供信息的）（1）基于通用引导架构（GBA）具有通用引导架构（GBA）[3GPP33.220]、[3GPP33.222]、[3GPP2S.S0114]、[3GPP24.109]的TLS-PSK。GBA提供了基于使用现存3GPP/3GPP2认证机制得到的共享密钥的相互认证性能■使用具有通用引导架构（GBA）的TLS-PSK对SET和SLP进行相互认证。（2）基于SEK（仅可应用于WIMAXSLP）■使用具有SEK的TLS-PSK对SET和SLP进行相互认证。可以在章节6.1.2.1.2中找到SEK方法的细节。（3）基于设备证书（DCert）该独立于AN的方法使用具有如下认证的TLS■RSA服务器证书，以便将SLP授权给SET■RSA客户端认证，以便将SET授权给SLP（4）基于可选客户端认证（ACA）这使用具有如下认证的TLS■RSA认证，以便将SLP授权给SET■可选的SET到SLP的客户端认证（见章节6.1.4）。在该情况下，SLP通过使承载网络确认与SET标识符（MSISDN等）相关联的IP地址对SET进行认证。（5）仅SLP这在SLP不可能对SET进行认证的情景中使用。该方法不应该用于非紧急情况。SET不能对该方法和基于ACA的方法作出区分。这使用具有下列认证的TLS■RSA认证，以便将SLP授权给SET■不对SET进行认证6.1.2.1.1支持GBA方法的部署在支持（GBA[3GPP33.220]、[3GPP24.109]、[3GPP2S.S0109]）的部署的情况下，如下建立共享密钥:·当SLP从BSF请求密钥材料（为了使IP通信安全并且为了保护SUPLINIT和/或SUPLREINIT）时，SLP也必须请求USS（用户安全设置）。USS必须包括永久用户标识（例如，IMPI、IMSI或者MSISDN）。·为了使SET和SLP之间的IP通信安全，SET和SLP必须得到共享秘密密钥，并且使用GBA（[3GPP33.220]、[3GPP24.109]、[3GPP33.222]、[3GPP2S.S0109]）根据TLS-PSK工作。SLP必须具有良好定义的指定SLP的域名SLP_Address_FQDN，例如，slp.operator.com。在OMNA注册[OMNA]中定义了应该用于TLS-PSK的GBAUa安全协议标识符。SLP必须确认BSF所提供的永久用户标识对应于在相应的安全连接上由SLP所接收的SUPL消息中的SET标识。·对于SUPLINIT和/或SUPLREINIT的MAC保护，根据GBA（[3GPP33.220]、[3GPP2S.S0109]）得到密钥。在OMNA注册[OMNA]中定义了应该用于SUPLINIT保护的GBAUa安全协议标识符。包括在SUPLINIT消息（或者SUPLREINIT消息）中的basicMAC的密钥标识符必须是从其生成Ks_NAF的Ks的B-TID。注释:典型地，从BSF对SUPLINIT保护密钥的D/H-SLP请求将与对使IP通信安全的密钥的D/H-SLP请求同时出现。·SET必须确保总是给它提供了有效的Ks。如果不存在有效的Ks，则SET必须开始GBA引导程序过程以便提供Ks。每次SET检测到新的UICC（USIM/SIM/R-UIM）时，必须建立新的Ks。另外，当Ks_NAF的有效期（由本地网络运营商设置）过期时，SET必须建立新的共享密钥。10.8SET性能SET能力参数9.2.8SUPLENDSUPLEND是正常或者异常结束SUPL过程的消息。SUPLEND消息10.xSUPLINIT密钥响应在SUPL_INIT_ROOT_KEY建立过程（见章节6.3.5.2）中使用SUPLINIT密钥响应参数，以便将用于模式ASUPLINIT保护的密钥从SLP发送到SET。SUPLINIT密钥响应11.4消息扩展（SUPL版本3）ULP-版本-3-消息-扩展自动定义标志::=开始输出Ver3-SUPL-INIT-扩展,Ver3-SUPL-START-扩展,Ver3-SUPL-POS-INIT-扩展,Ver3-SUPL-END-扩展,Ver3-SUPL-RESPONSE-扩展,Ver3-SUPL-TRIGGERED-RESPONSE-扩展,Ver3-SUPL-TRIGGERED-START-扩展,Ver3-SUPL-TRIGGERED-STOP-扩展,Ver3-SUPL-SET-INIT-扩展,Ver3-SUPL-NOTIFY-扩展,Ver3-SUPL-NOTIFY-RESPONSE-扩展,Ver3-SUPL-REPORT-扩展,QoP性能,相对定位性能,城市定位性能;输入Ver,QoP,FQDN来自ULP-分量圆形区域，椭圆形区域，多边形区域来自Ver2-ULP-分量定位协议版本3GPP,定位协议版本3GPP2来自ULP-版本-2-参数-扩展定位协议版本OMA来自ULP-版本-3-参数-扩展定位有效负载来自SUPL-POS通知来自SUPL-INIT会话ID来自ULP-分量通知响应来自SUPL-NOTIFY-RESPONSE最大会话数目,会话列表来自SUPL-REPORTOMA-LPPe-相对定位,OMA-LPPe-参考点唯一ID,OMA-LPPe-城市定位FROMOMA-LPPE;[为简便起见移除了一些不改变的部分][为简便起见移除了一些不改变的部分]结束11.6参数扩展（SUPL版本3）ULP-版本-3-参数-扩展自动定义标志::=开始输出Ver3-定位协议-扩展,Ver3-SET性能-扩展,Ver3-SLP性能-扩展,Ver3-触发参数-扩展,Ver3-所支持的服务-扩展;输入QoP性能,相对定位性能,城市定位性能，来自ULP-版本-3-消息-扩展;Ver3-定位协议-扩展::=序列{定位协议版本LPPe定位协议版本OMA可选的,...}SUPLINIT根密钥状态::=列举{无效SUPLINIT根密钥（0）,不同步SUPLINIT根密钥（1）,...}[为简便起见移除了一些不改变的部分]结束附加实施例9保护等级参数的预先定义可能不反映基本保护已经改变到模式A保护和模式B保护的事实（模式B保护与之前的基本保护是相同的）。还可以更新预先的ASN.1定义。因此，可以将下列提议合并到SUPL3.0内，以便修改章节10.25反映模式A和模式B保护，并且也更新ASN.1章节11.4（可以将章节号称为SUPL3.0章节）。10.22保护级别保护等级参数定义了对于SUPLINIT/SUPLREINIT消息的保护级别。11.3消息扩展（SUPL版本2）ULP-版本-2-消息-扩展自动定义标志::=开始输出Ver2-SUPL-INIT-扩展,Ver2-SUPL-START-扩展,Ver2-SUPL-RESPONSE-扩展,Ver2-SUPL-POS-INIT-扩展,Ver2-SUPL-POS-扩展,Ver2-SUPL-END-扩展;输入SLP地址,位置,Ver来自ULP-分量SET性能来自SUPL-START所支持的网络的信息，GNSS定位技术，多定位Id，UTRAN-GPS参考时间结果,UTRAN-GANSS参考尸检结果,UTRAN-GPS参考时间辅助,UTRAN-GANSS参考时间辅助,SPCSET密钥,SPCTID,SPCSET密钥有效期,第三方,应用ID来自Ver2-ULP-分量触发类型来自SUPL-TRIGGERED-STARTVer3-保护级别-扩展来自ULP-版本-3-参数-扩展;[为简便起见移除了一些不改变的部分]保护级别::=列举{空保护（0）,基本保护（1）,...,ver3-模式A保护（2）,ver3-模式B保护（3）}–基本保护（1）不可用于SUPL3.0中[为简便起见移除了一些不改变的部分]结束11.6参数扩展（SUPL版本3）ULP-版本-3-参数-扩展自动定义标志::=开始输出Ver3-定位协议-扩展,Ver3-SET性能-扩展,Ver3-SLP性能-扩展,Ver3-触发参数-扩展,Ver3-所支持的服务-扩展,Ver3-保护级别-扩展;输入QoP性能,相对定位性能,城市定位性能来自ULP-版本-3-消息-扩展;[为简便起见移除了一些不改变的部分]密钥标识符类型::=列举{模式A密钥标识符（0）,临时模式A密钥标识符（1）,模式B密钥标识符（2）,...}结束本领域的技术人员将进一步意识到，可以将结合这里所公开的实施例描述的各种说明性逻辑块、配置、模块、电路和算法步骤实现为电子硬件、通过诸如硬件处理器的处理设备执行的计算机软件、或者二者的组合。上文一般以它们的功能的形式描述了各种说明性组件、块、配置、模块、电路和步骤。将该功能实现为硬件还是可执行软件取决于特定的应用和施加在整个系统上的设计约束。对于每个特定应用，熟练的技术人员可以以不同方式实现所描述的功能，但是不应该将该实现决定解释为造成偏离本公开内容的范围。可以将结合在这里所公开的实施例描述的方法或算法的步骤直接具体化在硬件、通过处理器执行的软件模块、固件、或者其组合中。软件或者逻辑块可以驻留在诸如随机访问存储器（RAM）、磁抗随机访问存储器（MRAM）、旋转-扭矩传递MRAM（SIT-MRAM）、闪存、只读存储器（ROM）、可编程只读存储器（PROM）、可擦除可编程只读存储器（EPROM）、电可擦除可编程只读存储器（EEPROM）、寄存器、硬盘、可移动盘、紧密光盘只读存储器（CD-ROM）、数字多用光盘（DVD）、蓝光光盘、或者本领域中已知的任何其它形式的存储媒体的非易失性存储媒体中。也应该将上述组合包括在计算机可读媒体的范围内。示例包括采用数据结构编码的计算机可读媒体和采用计算机程序编码的计算机可读媒体。计算机可读媒体可以表现为制造商品的形式。将示例性存储媒体连接到处理器，使得处理器可以从存储媒体读取信息，并且将信息写入存储媒体。可替换地，可以将存储媒体集成到处理器。处理器和存储媒体可以驻留在专用集成电路（ASIC）中。ASIC可以驻留在计算设备或者用户终端中。可替换地，处理器和存储媒体可以作为分立组件驻留在计算设备或者用户终端中。因此，取决于应用，可以通过各种方式实现在这里所描述的方法。例如，可以在硬件、固件、软件、或者其组合中实现这些方法。另外，或者作为对ASIC和处理器的替代，硬件实现可以包括数字信号处理器件（DSPD）、可编程逻辑器件（PLD）、现场可编程门阵列（FPGA）、处理器、控制器、微控制器、微处理器、电子器件、设计为执行在这里所描述的功能的其它电子单元、或者其组合。在这里，术语“控制逻辑”包含通过软件、硬件、固件或者组合实现的逻辑。对于包括固件和/或软件的实现，可以采用执行在这里所述功能的模块（例如，过程、函数等）实现方法。可以使用任何可触摸收录指令的机器可读媒体实现在这里所述的方法。例如，可以将软件代码存储在存储器中，并且通过处理单元执行。可以在处理单元内或者处理单元外部实现存储器。如在这里所使用的，术语“存储器”是指任何类型的长期、短期、易失、非易失、或者其它存储器件，并且不限于任何特定类型的存储器或者存储器数目、或者在其上存储存储器的媒体类型。在包括固件和/或软件的实现中，可以将函数作为一条或多条指令或代码存储在计算机可读媒体上。可以结合Wi-Fi/WLAN或者其它无线网络实现本公开内容。除了Wi-Fi/WLAN信号之外，无线/移动台还可以从卫星接收信号，其可以来自全球定位系统（GPS）、伽利略、GLONASS、NAVSTAR、QZSS、使用来自这些系统的组合的卫星的系统、或者将来开发的任何SPS，在这里一般将每个称为卫星定位系统（SPS）或者GNSS（全球导航卫星系统）。还可以结合伪星或者包括伪星的系统的组合实现本公开内容。可以结合毫微微蜂窝或者包括毫微微蜂窝的系统的组合实现本公开内容。可以结合诸如无线广域网（WWAN）、无线局域网（WLAN）、无线个域网（WPAN）等的各种无线通信网络实现本公开内容。术语“网络”和“系统”通常可互换使用。通常可互换使用术语“位置”和“定位”。WWAN可以是码分多址（CDMA）网络、时分多址（TDMA）网络、频分多址（FDMA）网络、正交频分多址（OFDMA）网络、单载波频分多址（SC-FDMA）网络、长期演进（LTE）网络、WiMAX（IEEE802.16）网络等。CDMA网络可以实现诸如cdma2000、宽带CDMA（W-CDMA）等的一种或多种无线电接入技术（RAT）。Cdma2000包括IS-95、IS-2000和IS-856标准。TDMA网络可以实现全球移动通信系统（GSM）、数字先进移动电话系统（D-AMPS）、或者某些其它RAT。在来自名为“第三代合作伙伴计划”（3GPP）的联盟的文档中描述了GSM和W-CDMA。在来自名为“第三代合作伙伴计划2”（3GPP2）的联盟的文档中描述了cdma2000。3GPP和3GPP2文档是公开可用的。WLAN可以是IEEE802.11x网络，并且WPAN可以是蓝牙网络、IEEE802.15x、或者某些其它类型的网络。还可以结合WWAN、WLAN和/或WPAN的任意组合实现该技术。典型地，卫星定位系统（SPS）包括发射机系统，安置其使得实体能够至少部分基于从发射机接收的信号确定它们在地球表面或者之上的位置。典型地，该发射机发送采用具有一组码片的重复伪随机噪声（PN）码标记的信号，并且可以位于基于地面的控制站、用户装置和/或太空交通模块上。在具体示例中，这种发射机可以位于地球轨道人造卫星（SV）上。例如，在诸如全球定位系统（GPS）、伽利略、Glonass或者Compass的全球导航卫星系统（GNSS）星座中的SV可以发送采用与星座中的其它SV所发送的PN码不同的PN码标记的信号（例如，为GPS中的每个卫星使用不同的PN码，或者在Glonass中在不同频率上使用相同码）。根据某些方面，在这里所提出的技术不限于用于SPS的全球系统（GNSS）。例如，在这里所提供的技术可以应用于各种地域性系统和/或各种增加的系统（例如，基于卫星的增加系统（SBAS）），或者使得能够在各种地域性系统中和/或各种增加的系统使用，q其中，地域性系统诸如日本的准天顶卫星系统（QZSS）、印度的印度区域导航卫星系统（IRNSS）、中国的北斗等，增加的系统可以与一个或多个全球和/或区域导航卫星系统相关联，或者否则使得能够与一个或多个全球和/或区域导航卫星系统一起使用。通过举例但不是限制的方式，SBAS可以包括提供完整性信息、微分修正等的增加的系统，诸如广域增加系统（WAAS）、欧洲相对地球静止导航覆盖服务（EGNOS）、多功能卫星增加系统（MSAS）、GPS辅助Geo增加导航或者GPS和Geo增加导航系统（GAGAN）等。因此，如在这里所使用的，SPS可以包括一个或多个全球和/或区域导航卫星系统和/或增加系统的任意组合，并且SPS信号可以包括SPS、类SPS、和/或与该一个或多个SPS相关联的其它信号。可以与利用伪星或者卫星和伪星组合的定位确定系统一起使用方法。伪星是基于地面的发射机，其广播在L频带（或者其它频率）载波信号上调制的PN码或者其它距离修正码（类似于GPS或者CDMA蜂窝信号），可以将其与GPS时间同步。可以给每个这种发射机分配唯一的PN码，以便允许通过远程接收机进行识别。伪星在诸如在隧道、矿井、大楼、市内峡谷、或者其它封闭区域中来自轨道卫星的信号可能是不可用的情况下是有用的。伪星的另一种实现已知为无线电信标。如在这里所使用的，术语“卫星”旨在包括伪星、伪星等价物、或者可能其它。如在这里所使用的，术语“SPS信号”旨在包括来自伪星或者伪星等价物的像SPS的信号。移动台（例如，MS或者STA）是指诸如蜂窝或者其它无线通信设备、个人通信系统（PCS）设备、个人导航设备（PND）、个人信息管理器（PIM）、个人数字助理（PDA）、膝上型电脑、平板电脑、上网本、智能本或者其它能够接收无线通信和/或导航信号的合适的移动设备的设备。术语“移动台”还旨在包括诸如通过短距离无线、红外、有线连接、或者其它连接与个人导航设备（PND）进行通信的设备——无论在设备或者在PND处是否出现卫星信号接收、辅助数据接收和/或关于定位的处理。同时，“移动台”旨在包括包含无线通信设备、计算机、膝上型电脑等的所有设备，其能够诸如经由因特网、Wi-Fi或者其它网络与服务器进行通信，并且无论在设备处、在服务器处、或者在与网络相关联的另一个设备处是否出现卫星信号接收、辅助数据接收和/或关于定位的处理。也将上述的任何可操作组合视为“移动台”。术语“移动台”和“移动设备”通常可互换使用。本公开内容包括示例实施例，然而，可以使用其它实现。指定某物是“最优的”、“所需的”或者其它指定不指示当前公开仅适用于最优系统、或者“所需的”要素存在的系统（或者由于其它指定的其它限制）。这些指定仅指特别描述的实现。当然，许多实现是可能的。可以采用除了在这里所讨论的那些协议之外的协议、包括在开发中或者将要开发的协议来使用技术。提供了所公开实施例的前述说明，以便使得本领域的技术人员能够进行或者使用所公开的实施例。对于本领域的技术人员，对这些实施例的各种修改将是显而易见的，并且在这里定义的原理可以应用于其它实施例，而不脱离本公开内容的范围。因此，本公开内容不是旨在限制于在这里所示的实施例，而是要符合与通过下列权利要求所定义的原理和新颖特征一致的可能最宽范围。