CN101228769A

CN101228769A - 在通用引导架构（gba）中结合认证偏好来提供移动节点标识的装置、方法和计算机程序产品

Info

Publication number: CN101228769A
Application number: CNA2006800268790A
Authority: CN
Inventors: G·巴科; 陈达强
Original assignee: Nokia Oyj
Current assignee: Nokia Technologies Oy
Priority date: 2005-06-13
Filing date: 2006-06-07
Publication date: 2008-07-23
Anticipated expiration: 2026-06-07
Also published as: ZA200800344B; CN101228769B

Abstract

在本发明的一个示例性而非限制性方面中，提供一种方法包括：在无线网络(WN)中发送第一消息，该第一消息包括节点所支持的认证机制的列表以及与各认证机制相关联的对应标识；至少基于从节点接收的列表在WN中确定将要用于引导的认证机制；以及在向节点发送的第二消息中包括如下信息，该信息包括结合对应标识的所确定的认证机制。该方法还包括：至少保护节点所支持的认证机制的列表以及对应标识；以及将第二消息发送到网络，该第二消息至少包括认证机制的列表以及对应标识。该方法还包括从网络接收至少部分完整性保护的第二响应消息，其中第二响应消息包括所选认证机制的指示以及对应标识。

Description

在通用引导架构（GBA）中结合认证偏好来提供移动节点标识的装置、方法和计算机程序产品

技术领域

本发明的示例性而非限制性的实施例主要地涉及通信系统、方法和设备，并且更具体地涉及在通信系统中使用的认证和有关技术。

背景技术

这里限定如下定义：

3GPP 第三代合作伙伴项目

AAA 认证、授权和计费

GAA 通用认证架构

GBA 通用引导架构

BSF 引导服务器功能

AKA 认证和密钥协议

IM IP多媒体

ISIM IM服务标识模块

NAI 网络接入标识符

MN 移动节点

UE 用户设备

EV-DO 演进型仅支持数据业务(Evolution Data Only)

3 GPP GBA(见3 GPP TS 33.220″GAA：GBA″，作为证据A附于上文引用的美国临时专利申请第60/759,487号)的目的在于规定一种用以从3GPP AKA机制为应用安全引导认证和密钥协议的机制。在3GPP2中也引入GBA，其中除了AKA之外也标准化了包括SMEKEY(对于CDMA1x系统)和MN-AAA密钥(对于CDMA1x EV-DO系统)的传统密钥为基础的引导。结果，当在3GPP2系统中工作时，MN可以支持或者可以被要求支持多于一个的认证和引导机制。因此需要一种技术用于MN和网络对将要在引导中使用的算法集合达成协议。这对于支持3GPP和3GPP2网络的未来终端而言也是需要的，使得3GPP终端可以在3GPP2网络中漫游(以及反之亦然)并且仍然使用GBA。此外，运营商有可能在同一地理位置布署3GPP和3GPP2网络两者。在这样的情况下，终端也必须与网络协商所要使用的引导机制。

3GPP仅支持一个认证和引导机制，即具有3GPP定义算法的摘要-AKA机制和AKA协议。在摘要-AKA中规定了AKA与摘要认证一起的使用(见IETF RFC 3310″Digest AKA″，作为证据B附于上文引用的美国临时专利申请第60/759,487号)。

在3GPP2中有用于在网络侧中支持的引导的不同机制，因为传统和非传统终端都需要被支持。

MN可以具有对多个认证和密钥生成机制(例如AKA、MN-AAA、CAVE)的支持以及可以具有多个预先提供的保密(secret)。在3GPP2中定义有一种机制选择过程，该过程要求MN将它向BSF发送所支持的认证机制的列表插入到第一消息的有效载荷，使BSF能够选择它所偏好的认证机制。一旦BSF选择认证和密钥生成机制，它就联系正确的数据库和取回认证数据。例如，如果MN除了其它机制之外还支持MN-AAA而BSF选择MN-AAA，则BSF将联系H-AAA以取回挑战(challenge)。

MN也具有一个或者多个标识。例如，如果MN具有ISIM应用，则它具有专用标识。如果MN是EV-DO终端，则它具有NAI。如果MN是1x终端，则它具有类似IMSI的标识。

这产生一个问题在于：当MN先通过发送HTTP GET请求来联系BSF时(根据3GPP2 S.P0109-0，2005年12月8日第0.6版，″GenericBootstrapping Architecture(GBA)Framework″，作为附件C附于上文引用的美国临时专利申请第60/759,487号)，要求它将它的标识插入到请求中。由于多数标识只能与具体认证和密钥生成机制一起使用(例如专用标识只能与AKA一起使用，IMSI只能由CAVE使用，EV-DONAI只能由MN-AAA使用)，所以通过选择和包含它的标识之一于GET请求中，MN也隐含地预选认证机制。在已经插入一个具体标识时，BSF不能对可以与该标识一起使用的机制做出另一选择。可选地，MN的不同标识的映射可能需要可为BSF所访问，但是这一方式可能由于诸多原因而不是所期望的。

发明内容

根据本发明示例性而非限制性的实施例，本发明提供一种方法包括：在无线网络(WN)中接收第一消息，该第一消息包括节点所支持的认证机制的列表以及与各认证机制相关联的对应标识；至少基于从节点接收的列表在WN中确定将要用于引导的认证机制；以及在向节点发送的第二消息中包括如下信息，该信息包括所确定的结合对应标识的认证机制。

根据本发明示例性而非限制性的实施例，本发明还提供一种实施于计算机可读介质中的计算机程序产品，节点的数据处理器对该计算机程序产品的执行包括以下操作：向无线网络(WN)发送第一消息，该第一消息包括节点所支持的认证机制的列表以及与各认证机制相关联的对应标识；以及从WN接收第一响应消息，该第一响应消息包括结合对应标识的与由WN从节点在第一消息中提供的列表中选择的认证机制有关的信息。

根据本发明示例性而非限制性的实施例，本发明还提供一种包括数据处理器的设备，该数据处理器耦合到发送器和接收器并且可操作用以：经由发送器向网络发送第一消息，该第一消息包括设备所支持的认证机制的列表以及与各认证机制相关联的对应标识；以及经由接收器从网络接收第一响应消息，该第一响应消息包括结合对应标识的与由网络从列表中选择的认证机制有关的信息。

另外根据本发明示例性而非限制性的实施例，本发明提供一种实施于计算机可读介质中的计算机程序产品，无线网络单元(WNE)的数据处理器对计算机程序产品的执行包括以下操作：从节点接收第一消息，该第一消息包括节点所支持的认证机制的列表以及与各认证机制相关联的对应标识；至少部分基于从节点接收的列表来确定将要用于引导的认证机制；向节点发送第一响应消息，该第一响应消息包括与确定的认证机制以及对应标识有关的信息；以及从节点接收至少部分完整性保护的第二消息，该第二消息至少以完整性保护的形式包括节点所支持的认证机制的列表以及对应标识。

另外根据本发明示例性而非限制性的实施例，本发明提供一种包括数据处理器的网络设备，该数据处理器耦合到发送器和接收器并且可操作用以经由接收器从节点接收第一消息，该第一消息包括节点所支持的认证机制的列表以及与各认证机制相关联的对应标识。数据处理器还可操作用以：至少部分基于从节点接收的列表来确定将要用于引导的认证机制；以及经由发送器向节点发送第一响应消息，该第一响应消息包括与确定的认证机制和对应标识有关的信息。数据处理器还可操作用以从节点接收至少部分完整性保护的第二消息，该第二消息至少以完整性保护的形式包括节点所支持的认证机制的列表以及对应标识。

另外根据本发明示例性而非限制性的实施例，本发明提供一种设备包括：用于向网络发送第一消息的装置，该第一消息包括设备所支持的认证机制的列表以及与各认证机制相关联的对应标识；以及用于从网络接收第一响应消息的装置，该第一响应消息包括描述了网络从列表中选择的认证机制以及对应标识的信息。该设备还包括用于完整性保护设备所支持的认证机制的列表以及用于向网络发送至少部分完整性保护的第二消息的装置，该第二消息以完整性保护的形式包括设备所支持的认证机制的列表以及与各认证机制相关联的对应标识。

此外根据本发明示例性而非限制性的实施例，本发明提供一种网络设备包括：用于从节点接收第一消息的装置，该第一消息包括节点所支持的认证机制的列表以及与各认证机制相关联的对应标识；用于至少部分基于从节点接收的列表来选择将要用于引导的认证机制的装置；以及用于将第一响应消息发送到节点的装置，该第一响应消息包括与所选认证机制以及对应标识有关的信息。接收装置还可操作地用于从节点接收至少部分完整性保护的第二消息，该第二消息包括节点所支持的认证机制的列表以及与各认证机制相关联的对应标识。

此外根据本发明示例性而非限制性的实施例，本发明提供一种系统，其具有耦合到网络设备的设备，其中该设备包括数据处理器，该数据处理器耦合到发送器和接收器并且可操作用以经由发送器向网络设备发送第一消息，该第一消息包括设备所支持的认证机制的列表以及与各认证机制相关联的对应标识。网络设备包括数据处理器，该数据处理器耦合到发送器和接收器并且可操作用以从列表中选择认证机制。该设备经由接收器从网络设备接收第一响应消息，其中该第一响应消息包括与网络设备从列表中选择的认证机制以及对应标识有关的信息。该设备的数据处理器可操作用以：至少部分完整性保护该设备所支持的认证机制的列表以及对应标识；以及经由发送器发送第二消息到网络设备，该第二消息包括认证机制的列表以及对应标识。

此外根据本发明示例性而非限制性的实施例，本发明提供一种方法，其包括：向网络发送第一消息，该第一消息包括设备所支持的认证机制的列表以及与各认证机制相关联的对应标识；以及从网络接收第一响应消息，该第一响应消息包括结合对应标识的与由网络从列表中选择的认证机制有关的信息。

附图说明

在附图中：

图1是图示了3 GPP2 GBA参照网络架构的框图；

图2图示了具有认证机制选择的引导过程；

图3是具有MITM攻击的错误情形的例子；

图4是具有MITM攻击的错误情形的另一例子；

图5示出了具有使用多个回合的消息交换的引导的机制选择的例子；

图6示出了使用HTTP摘要认证的协商的非限制性例子；

图7示出了使用简单HTTP传送的协商的非限制性例子；以及

图8图示了根据本发明示例性实施例具有认证机制选择的引导过程并且该过程由如下文献中的图C.3-1 Bootstrapping signalingbased on AKA改编而成：3GPP2 S.P0109-0，Version 0.6，2005年12月8日，″Generic Bootstrapping Architecture(GBA)Framework″的附录C，其作为证据C附于上文引用的美国临时专利申请第60/759,487号。

具体实施方式

本发明的非限制性和示例性实施例主要地涉及认证并且具体地涉及已经在3GPP中定义以及也已经在3GPP2中引入的3GPP通用引导架构(GBA)。图1示出了一般而非限制性的引导参照架构。在图1中示出了归属订户系统(HSS)2、归属位置寄存器(HLR)4、接入、认证和计费(AAA)服务器6、BSF8、网络应用功能(NAF)10和用户设备/移动节点(MN)12以及在这些部件之间的接口。假设适当的发送器(Tx)和接收器(Rx)用来在MN12、BSF8与其它网络部件之间传送信息和消息。本发明的非限制性和示例性实施例主要地处理与在MN12与执行引导的BSF8之间的Ub接口有关的过程。注意到移动终端在3GPP中称为用户设备(UE)而在3GPP2中称为移动节点(MN)。在本专利申请中这些术语可以不失一般性地互换使用，而它们也可以甚至更一般地称为设备或者节点。

本发明的非限制性和示例性实施例提供一种用以协商用于在MN12与网络之间的引导的支持机制/算法的机制。

本发明的非限制性和示例性实施例提供一种用于MN 12和网络单元(BSF8)对用于在GBA(3GPP2环境)中使用的认证和引导机制达成协议的解决方案以及也定义了可以如何将该机制集成到现有3GPP过程中。假设MN12拥有其所支持的认证和引导机制的列表11，比如通过在耦合到数据处理器(DP)12B的存储器(MEM)12A中存储列表11。也假设存储器12A包括用于根据本发明各种实施例操作DP12B的程序代码。还假设BSF8也包括耦合到数据处理器(DP)8B的存储器(MEM)8A。假设存储器8A包括用于根据本发明各种实施例操作DP 8B的程序代码。

一般而言，MN 12的各种实施例包括但不限于蜂窝电话、具有无线通信能力的个人数字助理(PDA)、具有无线通信能力的便携计算机、具有无线通信能力的图像捕获设备如数字相机、具有无线通信能力的游戏设备、具有无线通信能力的音乐存储和回放设备、允许无线因特网接入和流览的因特网设备以及并入这样的功能组合的便携单元或者终端。在其它实施例中节点可以不包括能够经由无线链路与网络进行无线通信的发送器和接收器，因为可以代之以经由线缆或者接线来使用有线连接，包括电互连和光互连中的一种或者二者。

存储器8A和12A可以是适合于本地技术环境的任何类型以及可以使用任何适当的数据存储技术来实施，该数据存储技术比如是基于半导体的存储器设备、磁存储器设备和系统、光存储器设备和系统、固定存储器和可移除存储器。数据处理器8B和12B可以是适合于本地技术环境的任何类型以及作为非限制性例子可以包括通用计算机、专用计算机、微处理器、数字信号处理器(DSP)和基于多芯处理器架构的处理器中的一个或者多个。

一般而言，本发明的示例性实施例可以通过可由MN 12的诸如DP12B的数据处理器执行的计算机软件或者通过硬件电路或者通过软件和硬件电路的组合来实现。本发明的实施例也可以通过可由诸如DP8B的BSF8的数据处理器执行的计算机软件或者通过硬件电路或者通过软件和硬件电路的组合来实现。

先参照美国专利申请第11/232,494号，其申请日为2005年9月21日，发明名称为″Method，Apparatus and Computer Program ProductProviding Bootstrapping Mechanism Selection in Generic BootstrappingArchitecture(GBA)″，申请人为Gabor Bajko和Tat Keung Chan，通过整体引用将其内容结合于此就如同在这里进行完整重述一样。美国专利申请第11/232,494号作为证据D赋予上文引用的美国临时专利申请第60/759,487号并且基于35 U.S.C.§119(e)要求申请日为2005年6月13日的美国临时专利申请第60/690,528号的优先权和申请日为2005年6月21日的美国临时专利申请第60/692,855号(在下文中多次引用)的优先权，通过整体引用将它们的公开内容结合于此。

在进一步讨论本发明的示例性实施例之前以及为了获得对本发明更完全的理解，现在提供对在美国专利申请第11/232,494号中公开的主题内容的讨论。就此而言下文对图2-图7进行参照。

在一个示例性实施例中，根据在美国专利申请第11/232,494号公开的非限制性实施例，引导过程包括下文参照图2进一步具体描述的如下步骤。

A.在初始引导请求中，MN 12在请求中向BSF 8呈现它所支持的认证机制的列表11。MN 12也包括用户的标识。

B.BSF8基于从MN 12接收的列表11以及其它信息(作为非限制性例子包括BSF 8自身所支持的机制以及基于用户的标识而取回的用户的配置文件)对将要用于引导的认证机制进行判决。BSF 8然后继续所选认证机制，这通常包括以认证挑战做出响应。BSF 8也在响应中包括选定的认证机制的指示。

C.MN 12向BSF 8发送新的HTTP请求，该请求包含对基于所选认证机制而生成的挑战的响应。该消息也包括MN 12所支持的认证机制的原列表11，只是这一次它受完整性保护。

D.BSF 8检验对挑战的响应是否正确而在响应对应于预期响应的情况下认为MN的验证成功。如果验证成功而在步骤C中接收的列表11与在步骤A中的列表相同，则BSF 8以HTTP成功响应对MN做出响应。响应消息也可以包括被完整性保护的所选认证机制的指示。

E.MN 12接收成功响应以及可以检验所选认证机制与所指示的一样。

由于前两个消息(步骤A和B)通常由于双方尚未相互认证而不能受保护，所以MITM攻击者可以截获消息A以及去除列表中的强认证机制，仅在列表中留下一个或者多个弱认证机制以供BSF 8从中选择。这造成“跌标(bid down)”攻击，其中强迫引导过程即使在双方(例如BSF 8和MN 12)支持较强的认证机制时也基于较弱的认证机制。根据在美国专利申请第11/232,494号公开的非限制性实施例，该过程通过以下方式来消除这些种类的“跌标”攻击：在步骤C中使MN 12以完整性保护的形式重复该列表，由此允许如果在步骤A和C中的列表不匹配，BSF 8则检测到MITM攻击。

现在更具体地描述在美国专利申请第11/232,494号公开的非限制性实施例的各种方面，在3GPP中Ub接口(在MN 12与BSF 8之间)基于HTTP摘要认证。同一机制已经在3GPP2中采用。例如，对于3GPP和3GPP2 AKA，使用摘要AKA，而对于用于CDMA1x和CDMAEV-DO系统的引导，使用具有口令保护的Diffie-Helman的HTTP摘要认证(分别基于SMEKEY和MN 12-AAA密钥)(见3GPP2文献：″Bootstrapping procedures for CDMA 1x and CDMA 1x EV-DO Systems″，3GPP2 TSG-S WG4，波兰，2005年5月)。换而言之，可能的认证和引导机制可以至少包括如下各项：

3GPP AKA(没有指定算法，它是运营商特定的)；

3GPP2 AKA(SHA-1是强制的算法)；

基于SMEKEY的引导；以及

基于MN-AAA密钥的引导。

未来将有更多认证机制可供使用并且可以容易地在MN-BSF选择过程中包括这些认证机制。

为了消除对标准化用于IETF中每一和每个认证机制的摘要变体的需要，优选的是在HTTP消息的有效载荷中嵌入所支持的认证机制的列表以及所选认证机制而不是将此信息承载于摘要认证报头中。

图2示出了用于具有认证机制选择的GBA引导过程的消息序列并且具体说明如下：

1.MN 12将形式为HTTP GET的初始引导请求发送到BSF8。MN12在授权报头中包括用户的标识。另外，在HTTP有效载荷中包括所支持的认证机制的列表(例如[A，B，C])。

2.在收到引导请求时，BSF 8从有效载荷中提取所支持的认证机制的列表。基于所提取的认证机制、BSF 8本身所支持的认证机制的列表、用户配置文件(基于用户的标识来获取)以及可能其它信息，BSF 8对将要用于引导的认证机制进行判决。

3.BSF 8将HTTP 401未授权响应发送到MN 12。该响应包括基于所选认证机制的适当信息。例如，如果选择3GPP AKA，则WWW-认证报头包含根据IETF RFC 3310“摘要AKA”的AKA参数。此外，有效载荷还将包括所选认证机制(在这一情况下为A)的指示。此外还将用于摘要认证的保护质量(qop)设置为“auth-int”，这指示了需要有效载荷完整性保护。

4.MN 12从有效载荷中获取BSF 8的选择并且根据该选择来继续认证过程。通常这将包括基于接收的挑战和一些共享保密来计算响应。

5.MN 12将形式为HTTP GET的新引导请求发送到BSF 8，该请求具有根据所选认证机制的计算响应。此外，有效载荷还包括MN 12支持的认证机制的原列表。由于qop已经设置为“auth-int”，所以在摘要响应的计算中包括这一原列表并且因此该列表受完整性保护。

6.BSF 8先检验在有效载荷中呈现的列表与在步骤2中接收的列表相匹配。只有发现匹配，BSF 8才继续基于所选机制的认证。通常这包括检验所接收的摘要响应以及计算用于服务器侧认证目的的服务器响应。

7.BSF 8以指示了成功认证和引导操作的HTTP 200 OK消息做出响应。该消息也包括由BSF计算的摘要响应。该消息也包括所选认证机制的指示以供MN 12参照。类似地，通过将qop设置为“auth-int”来完整性保护这一指示。

8.MN 12可以检验所选认证机制确实与在步骤3中指示的认证机制相同。应当注意该机制即使在HTTP 200 OK响应中没有包括所选认证机制的情况下仍理想地起作用。

9.BSF 8和MN 12基于所选认证和引导机制来导出引导密钥。

图3图示了当MITM攻击者14尝试如上所述的跌标攻击时的情形。下文说明图3中的各步骤。

1.与在图2中的步骤1相同。原列表11例如包含三个支持机制，即A、B和C。

1a.消息1由MITM攻击者14截获。原列表11为仅包含可能是三个所支持机制中最弱的机制C的列表所取代。

2.BSF 8提取仅包含C的列表并且因此选择C而继续。

3.与在图2中的步骤3相同，其中指示了机制C。

4.MN 12认为BSF 8已经选择机制C并且因此相应地继续。

5.与在图2中的步骤6相同。虽然MN 12继续机制C，但是它在有效载荷中包括完整性保护的原列表[A，B，C]，因此MITM攻击者14无法修改消息。

6.BSF 8在检验所接收的列表同时发现它与在步骤2中接收的列表不相同。它推断已经起动跌标攻击并且因此以HTTP 403禁止消息放弃引导过程。

可选地，BSF 8可以在步骤2中的接收列表与在用户的配置文件中指示的列表不匹配时检测到这一攻击，在这一情况下它也可以判决放弃引导过程。这一点在图4的步骤1、2和3中示出。

另外根据在美国专利申请第11/232,494号中公开的非限制性实施例，至少一个实施例涉及如下情况，其中用于所选认证机制的引导过程涉及到要完成多于两个回合的请求/响应。例如，基于摘要-AKA的引导要求完成两个回合的请求/响应。尽管先前实施例描述了基于SMEKEY和MN-AAA密钥的引导可能也要求两个回合的请求/响应的情况，但是可能有它们要求多于两个回合的请求/响应的情况。在这样的情况下，在美国专利申请第11/232,494号中公开的非限制性实施例仍然适用。这一情形在图5中示出并且说明如下：

1.在初始引导请求中，MNS 12在请求中向BSF 8呈现它支持的认证机制的列表(例如{A，B，C})。MN 12也包括用户的标识。可以假设在多数情况下这一列表未受保护。

2.BSF 8基于从MN 12接收的列表以及其它信息(包括BSF 8自身支持的机制以及基于用户的标识而获取的用户的配置文件)对将要用于引导的认证机制进行判决。图5作为非限制性例子假设选定机制A。

3.BSF 8然后继续选定的认证机制，这通常包括通过认证挑战进行响应。BSF 8还在响应中包括对所选认证机制的指示(在这一例子中为机制A)。同样，这一指示可能未受保护。

应当注意从这一点起MN 12和BSF 8继续所选机制(例如如图5中所示机制A)。如上所述，不同机制可能要求回合数目不同的消息交换(例如请求/响应)来完成引导过程。例如，摘要-AKA机制要求在步骤3之后完成多一次请求/响应；而对于基于CAVE和MN-AAA密钥的引导，可能要求附加回合。根据本发明的示例性实施例，在这些后续消息的一个消息中，MN 12再次发送原列表11(与在消息1中发送的一样)，但是它受保护(例如完整性保护)；而BSF 8可以再次发送选定的机制(与在消息3中发送的一样)，但是它受保护(例如完整性保护)。注意到当MN 12以受保护方式再次发送的原列表11，对于BSF 8来说可选地(但是优选地)以受保护方式再次发送选定机制。如果以受保护方式再次发送这样的参数，则使另一方能够检验所发送的参数是否与接收的原参数相同以便检测MITM攻击者对改变未以保护方式发送的原参数的任何尝试。在以下描述中利用完整性保护作为一种用以保护参数的示例性技术。应当理解也可以对参数进行加密。

4.仍然参照图5，在步骤4，MN 12根据机制A来计算响应。

5-6.如前所述在MN 12与BSF 8之间可以有多个回合的请求/响应。在这些回合中的一些回合中，选定的机制可能不能提供所需完整性保护。因此，MN 12和BSF 8可能不能发送完整性保护的参数。

7.在引导过程中的某一些点，MN 12可以能够发送包括被完整性保护的数据的消息。例如，在消息7中假设MN 12能够发送这样的消息。如果是这样，则MN 12将包括受完整性保护的原列表11(在本例中为列表{A，B，C})，如在图5中由P[{A，B，C}]所示。

8.在收到消息时，BSF 8检验完整性保护的列表与MN 12在消息1中原始发送的列表相同。如果不相同，则BSF 8可以向MN 12发送错误响应以放弃操作(未示出)。可选地，BSF 8可以静默地放弃操作。

9.在引导过程中的某点，BSF 8可以能够发送包括受完整性保护的数据的消息。例如，在消息9中假设BSF 8能够发送这样的消息。BSF 8可以包括受完整性保护的选定机制(在本例中为机制A)，如在图5中由P[A]所示。

10.在收到消息时，MN 12检验完整性保护的选定机制与BSF 8在消息2中原始发送的选定机制相同。如果不相同，则MN 12可以向BSF 8发送错误消息以放弃操作(未示出)。可选地，MN 12可以静默地放弃操作。

11.如果成功，则使双方能够根据所选引导机制来导出引导密钥Ks。

可以注意到步骤7和8以及步骤9和10(如果存在)并非必须是以所述顺序并且它们并非必须在连续消息中。也就是说，BSF 8可以先发送具有完整性保护参数(选定的机制)的消息，而MN 12可以在以后时间发送具有完整性保护参数(所支持的机制的列表)的消息。此外在发送完整性保护的消息之前和之后还可以有更多回合的消息。

以下描述了提供根据在美国专利申请第11/232,494号中公开的非限制性实施例使用HTTP摘要认证(图6)和简单HTTP传送(图7)的示例性实施。应当注意在美国专利申请第11/232,494号中公开的示例性而非限制性实施例不限于这两个例子而也可以使用其它传送/认证机制(例如可扩展认证协议(EAP))来实现。在以下描述中假设在HTTP消息的有效载荷中发送机制协商所需要的参数(由MN 12发送的所支持机制的列表11以及由BSF 8发送的选定机制)。然而注意可选地，在HTTP消息中的适当报头中携带这些参数。

HTTP摘要认证

在这一示例性实施中，将具有口令保护的Diffie-Hellman的HTTP摘要认证用于引导。缺省口令(例如“11...1”)可以用作摘要口令，所以在使用MS_AUTH和/或BS_AUTH时在MN 12与BSF 8之间的相互认证实际上基于口令保护的Diffie-Hellman机制。口令保护的Diffie-Hellman机制的细节是基于正在3GPP2中规定的无线LAN互相作用规范中描述的WKEY(无线LAN密钥)生成过程(见3GPP2X.P0028″Wireless LAN interworking″的第7.1.1部分，作为证据D附于上文引用的申请日为2005年6月21日的美国临时专利申请第60/692,855号)。

图6图示了选定的机制为CAVE的引导机制协商的一个示例性实现，其中利用CAVE的引导过程总共要求三个回合的HTTP请求/响应。基于MN-AAA密钥的引导情形非常相似，因此不再具体描述。

下文更具体地描述再图6中示出的步骤。

1.MN 12朝着BSF 8发送HTTP GET请求。形式为“IMSI@realm.com”的用户的标识作为用户名包含于授权报头中。此外，用户还在有效载荷中发送所支持的引导/认证机制的列表11(例如{CAVE，B，C}，这意味着MN 12支持CAVE和两个其它机制B和C)。

2.BSF 8从有效载荷中获取所支持的机制的列表并且基于列表、用户名、用户配置文件和/或其它信息做出判决，而在该非限制性例子中，BSF 8选择CAVE作为引导机制。从这一点起，引导是基于CAVE这一选定机制的。BSF 8生成32位RAND挑战值。

3.BSF 8将HTTP 401响应发送到MN 12。RAND被base64编码并将其携带于WWW-认证报头的临时数(nonce)字段中。字段“qop-options”被设置为“auth-int”。有效载荷也包含CAVE是选定的机制的指示。

4.MN 12从有效载荷中提取选定的机制并且相应地继续。对于CAVE，由GBA功能接收的RAND挑战值作为模拟的全局挑战发送到R-UIM或者1X终端。

5.1X终端(或者R-UIM)以AUTHR和SMEKEY对全局挑战做出响应。AUTHR和SMEKEY然后被递送到GBA功能。

6.GBA功能将MS_PW设置为SMEKEY。它也为Diffie-Hellman方法生成保密随机数“x”。对于摘要认证，GBA功能也生成将要用作客户机临时数的32位随机数CRAND。

7.MN 12以适当的授权报头将另一HTTP GET请求发送到BSF 8。假设使用默认口令根据RFC2617(作为证据C附于申请日为2005年6月21日的美国临时专利申请第60/692,855号)来计算摘要响应。CRAND被base64编码并将其携带于临时数字段中。HTTP有效载荷包含AUTHR和MS_RESULT，即以MS_PW＝SMEKEY通过SMEKEY的散列来覆盖的g^x mod p。

8.BSF 8检验所接收的MS_RESULT不为零。充当VLR的BSF 8发送AUTHREQ到HLR/AC 4’。AUTHREQ包括RAND、SYSACCTYPE＝GAA接入和AUTHR参数。ESN参数被设置为全零。SYSCAP参数被设置为指示在这一系统接入上请求认证参数(位-A＝1)以及系统支持信令消息加密(位-B＝1)。SYSCAP参数的所有其它位优选地设置为零。

9.HLR/AC 4’检验AUTHR并且生成SMEKEY。

10.HLR/AC 4’以包括SMEKEY参数的TIA-41 AUTHREQ做出响应。如果认证失败，则AUTHREQ将仅包括接入拒绝指示。

11.BSF 8通过使用默认口令检验摘要响应来认证MN 12。如果成功，则BSF 8设置BS_PW＝SMEKEY并且为Diffie-Hellman方法生成随机保密数“y”。

12.BSF8生成128位Ks。也通过从步骤2取得base64编码的RAND值以及BSF8服务器名即base64encode(RAND)@BSF_servers_domain_name以NAI的形式生成B-TID值。

13.BSF 8将200 OK响应发送到MN 12。服务器摘要响应“rspauth”使用默认口令根据RFC 2617(作为证据C附于申请日为2005年6月21日的美国临时专利申请第60/692,855号)来计算并且携带于认证信息报头中。200 OK响应的有效载荷也包含BS_RESULT，即通过SMEKEY的散列来覆盖的g^y mod p、B-TID、密钥Ks的生命期、选定的机制(CAVE)的指示和BS_AUTH。注意到可以通过在BS_AUTH的计算中包括该数据来提供完整性保护。一个示例性例子如下：

14.MN 12使用默认口令根据RFC 2617(作为证据C附于申请日为2005年6月21日的美国临时专利申请第60/692,855号)来检验rspauth并且检验BS_AUTH等于XBS_AUTH’(使用与BS_AUTH相同的计算)。MN 12也检验所指示的选定机制为CAVE。如果成功，则认证了服务器和所发送的消息。如果不成功，则MN 12放弃引导过程并且可以立即或者在以后时间重试。

15.MN 12生成128位Ks。

16.MN 12以适当的授权报头将另一HTTP GET请求发送到BSF8。使用默认口令来计算摘要响应。有效载荷包含所支持的机制的原列表(在这一例子中为{CAVE，B，C})和MS_AUTH。可以通过在MS_AUTH的计算中包括需要保护的数据来提供完整性保护。一个示例性方式如下：

MS_AUTH[data]＝SHA-1(0x00000004|0x00000C80+sizeof(data)|MS_PARAM|data|MS_PARAM|data)modulo 2¹²⁸，其中数据是需要完整性保护的信息，在这一情况下为所支持的机制的原列表({CAVE，B，C})。

17.BSF 8使用默认口令来检验摘要响应并且通过检验MS_AUTH等于XMS_AUTH(与MS_AUTH相同的计算)来认证MN 12。BSF 8也检验所支持的机制的列表与在步骤2中接收的列表相同。如果不相同，则BSF 8可以向MN 12发送HTTP 403禁止响应或者其它错误响应或者静默地放弃引导过程(未示出)。

18.如果成功，则BSF 8发送200 OK响应到MN 12。

注意到在上述过程中有许多可能的变形。然而，根据在美国专利申请第11/232,494号中公开的示例性而非限制性实施例的基本概念保持相同，因此没有描述所有可能的变形。一个变形是MS_AUTH和BS_AUTH分别在步骤16和17中用作摘要口令，在这一情况下可以在MS_AUTH和BS_AUTH的计算中不包括“数据”。在该情况下的完整性保护将由摘要认证机制提供。另一变形是取代了在MN12一侧使用MS_AUTH并且在BSF 8一侧使用BS_AUTH，而是将在两侧仅使用MS_AUTH或者BS_AUTH。同样，在MS_AUTH或者BS_AUTH的计算中没有包括“数据”而通过摘要认证机制来提供完整性保护。

简单HTTP传送

在这一非限制性示例中，简单HTTP用作为一种用于MN 12和BSF8交换口令保护的Diffie-Hellman参数的传送机制。在MN 12与BSF 8之间的相互认证是基于使用MS_AUTH和BS_AUTH的口令保护的Diffie-Hellman机制。

图7图示了选定的机制为CAVE的引导机制协商的一个示例性实现，其中利用CAVE的引导过程要求三个回合的HTTP GET/响应。基于MN-AAA密钥的引导情形非常相似，因此不再具体描述。下文更具体地描述步骤。

1.MN 12朝着BSF 8发送HTTP GET请求。形式为“IMSI@realm.com”的用户的标识包含于有效载荷中。此外，用户还在有效载荷中包括所支持的引导/认证机制的列表(例如{CAVE，B，C}，这意味着MN 12支持CAVE和两个其它机制B和C)。

2.BSF 8从有效载荷中获取所支持的机制的列表并且基于该列表、用户名(也来自有效载荷)、用户配置文件和/或其它信息做出判决。假设BSF 8选择CAVE作为引导机制，而从这一点起，引导基于选定的机制(例如CAVE)。BSF 8生成32位RAND挑战值。

3.BSF 8将响应(例如200 OK)发送到MN 12。RAND被base64编码并将其携带于有效载荷中。有效载荷也包含CAVE是选定的机制的这一指示。

4.由GBA功能接收的RAND挑战值作为模拟的全局挑战发送到R-UIM或者1X终端。

6.GBA功能将MS_PW设置为SMEKEY。它也为Diffie-Hellman方法生成保密随机数“x”。

7.MN 12将另一HTTP GET请求发送到BSF 8。HTTP有效载荷包含AUTHR和MS_RESULT，即通过SMEKEY的散列来覆盖的g^x modp。

8.BSF 8检验所接收的MS_RESULT不为零。充当VLR的BSF 8发送AUTHREQ到HLR/AC 4’。AUTHREQ包括RAND、SYSACCTYPE＝GAA接入和AUTHR参数。ESN参数被设置为全零。SYSCAP参数被设置为指示在这一系统接入上请求认证参数(位-A＝1)以及系统支持信令消息加密(位-B＝1)。SYSCAP参数的所有其它位可以设置为零。

9.HLR/AC检验AUTHR并且生成SMEKEY。

10.HLR/AC以包括SMEKEY参数的TIA-41AUTHREQ做出响应。如果认证失败，则AUTHREQ可以仅包括接入拒绝指示。

11.BSF 8设置BS_PW＝SMEKEY并且为Diffie-Hellman方法生成随机保密数“y”。

12.BSF 8生成128位Ks。也可以通过从步骤2取得base64编码的RAND值以及BSF 8服务器名，即base64encode(RAND)@BSF_servers_domain_name以NAI的形式生成B-TID值。

13.BSF 8将响应(例如200 OK)发送到MN 12。响应的有效载荷包含BS_RESULT，即通过SMEKEY的散列来覆盖的g^y mod p、B-TID、密钥Ks的生命期、选定的机制(CAVE)的指示和BS_AUTH。注意到可以通过在BS_AUTH的计算中包括该数据来提供完整性保护。一个示例性方式如下：

14.MN 12检验BS_AUTH等于XBS_AUTH(使用与BS_AUTH相同的计算)。MN 12也检验所指示的选定机制为CAVE。如果成功，则认证了服务器和所发送的消息。如果不成功，则MN 12优选地放弃引导过程并且可以立即或者在以后时间重试。

15.MN 12生成128位Ks。

16.MN 12将另一HTTP GET请求发送到BSF 8。有效载荷包含MS_AUTH。有效载荷也可以包含所支持的机制的原列表(在这一例子中为{CAVE，B，C})和MS_AUTH。可以通过在MS_AUTH的计算中包括需要保护的数据来提供完整性保护。一个示例性方式如下：

MS_AUTH[data]＝SHA-1(0x00000004|0x00000C80+sizeof(data)|MS_PARAM|data|MS_PARAM|data)modulo 2¹²⁸，其中数据是需要完整性保护的信息以及所支持的机制的原列表({CAVE，B，C})。

17.BS通过检验MS_AUTH等于XMS_AUTH(使用与MS_AUTH相同的计算)来认证MN 12。BS也检验所支持的机制的列表与在步骤2中接收的列表相同。如果不相同，则BSF 8可以向MN 12发送HTTP403禁止响应或者其它错误响应，或者它可以静默地放弃引导过程(未示出)。

18.BSF 8发送响应(例如200 OK)到MN 12。

注意到在上述过程中有许多可能的变形。然而，根据在美国专利申请第11/232,494号中公开的非限制性和示例性实施例的基本概念保持相同。

XML方案定义

在3GPP GBA中，如果引导成功，则HTTP有效载荷在最终的200OK响应中携带B-TID(引导事务标识符)和密钥生命期。在3GPP TS24.109的附录C中定义了关联的XML方案。3GPP2扩展这一方案以允许有效载荷携带基于SMEKEY和MN-AAA密钥的引导所需其它信息，这些信息包括参数AUTHR(对于CAVE)和口令保护的Diffie-Hellman参数。在美国专利申请第11/232,494号中公开的非限制性实施例提供了进一步扩展的XML方案以包括认证机制的列表以及所选机制的指示。该方案的一种可能定义如下，其中用下划线和斜体示出了用于支持在美国专利申请第11/232,494号中公开的非限制性和示例性实施例的扩展。

<？xml version＝″1.0″cn coding＝″UTF-8″？>

<xs:schema targetNamespace＝″uri:3gpp2-gba″

xmlns:gba＝″uri:3gpp2-gba″

xmlns:xs＝http:∥www.w3.crg/2001/XMLSchema″>

<！--包含B-TID、密钥生命期和其它参数的根元素的定义-->

<xs:complexType name＝″bootstrappingInfoType″>

<xs:sequence>

<xs:element name＝″btid″type＝″xs:string″minOccurs″0″/>

<xs:element name＝″lifetime″type＝″xs:dateTime″minOccurs＝″0″/>

<xs:element name＝″authr″type＝″xs:base64Binary″minOccurs＝″0″/>

<xs:element name＝″ms_result″type＝″xs:base64Binary″minOccurs＝″0″/>

<xs:element name＝″bs_result″type＝″xs:base64Binary″minOccurs＝″0″/>

<xs:element name＝″auth list″minOccurs＝″0″>

<xs:simpleType>

<xs:list itemType＝″gba:authType″/>

</xs:simpleType>

</xs:element>

<xs:element name＝″auth″type＝″gba:authType″minOccurs＝″0″/>

</xs:sequence>

</xs:complexType>

<！--认证和引导机制类型的定义-->

<xs:simpleType name＝″authType″>

<xs:restriction base＝″xs:string″>

<xs:enumeration value＝″3GPP-AKA″/>

<xs:enumeration value＝″3GPP2-AKA″/>

<xs:enumeration value＝″CAVE″/>

<xs:enumeration value＝″MN-AAA″/>

</xs:restriction>

</xs:simpleType>

<！--根元素-->

<xs:element name＝″BootstrappingInfo″type＝″gba:bootstrappingInfoType″/>

</xs:schema>

在该方案中，元素“auth_list”用来携带图2和图3中的消息1和消息5中的认证和引导机制的列表11。元素“auth”用来携带图2和图3中的消息3和消息7中BSF所选机制的指示。类型“authType”被定义为各种标准中当前认证和引导机制的枚举并且可以取以下示例值：

“3GPP-AKA”：基于3GPP AKA机制的引导；

“3GPP2-AKA”：基于3GPP2 AKA机制的引导；

“CAVE”：基于SMEKEY(CAVE)的引导；以及

“MN-AAA”：基于MN-AAA密钥的引导。

当在GBA中支持更多认证机制时，将新的认证机制的对应名称添加到authType。

可选地，取代了具有“3GPP-AKA”和“3GPP2-AKA”，可以在方案中仅定义“AKA”。在AKA中使用的实际机制然后由网络运营商预先配置。

注意到在本质上上述方案是示例性的，而其它技术也可能实现同一目的。此外，该方案可以被扩展为包括被携带在有效载荷中的有用的其它信息。例如，在如上所述使用简单HTTP作为用于携带口令保护的Diffie-Hellman的示例性实现中，有效载荷优选地携带其它信息，比如用户名、RAND、MS_AUTH、BS_AUTH等等。该方案由此可以相应地被扩展为也允许携带这些参数。

应当注意在以上定义中的认证机制的名称是示例性的，而在这里不失一般性地加以使用。

应当认识到在图1-图7中描述的示例性实施例是简单、高效和安全的，不要求IETF中的标准化工作，可扩展为支持未来的认证和引导机制并且支持3GPP和3GPP2系统。

根据一种按照在美国专利申请第11/232,494号中公开的非限制性和示例性实施例的装置、方法和计算机程序产品，提供了一种用于由诸如BSF 8的网络设备或者节点和诸如MN 12设备或者节点执行以便执行如下引导过程的技术，该引导过程包括：在初始引导请求中，MN12向BSF 8发送包括MN 12所支持的认证机制的列表的第一请求消息；BSF 8至少基于从MN 12接收的列表来确定将要用于引导的认证机制并且继续所选认证机制和在对MN 12的响应消息中包括所确定的认证机制的指示；MN 12基于所确定的认证机制将至少部分完整性保护的第二请求消息发送到BSF 8，该第二请求消息以完整性保护的形式包括MN 12所支持的认证机制的列表。如果认证成功以及如果在第二请求消息中接收的列表与在第一请求消息中接收的列表相匹配，则网络可以用至少部分完整性保护的成功响应消息对MN 12做出响应，其中该成功响应消息以完整性保护的形式包括所选认证机制的指示。MN 12在收到成功响应消息时可以检验MN 12所用认证机制与BSF 8所选认证机制相匹配。MN 12发送的第一请求消息也可以包括用户的标识，该用户的标识可以由BSF 8用以辅助选择认证机制。

通过根据本发明的教导可以适应多个消息回合。可以通过摘要认证来继续协商或者作为非限制性例子可以使用HTTP来继续协商。

已经如此描述了在美国专利申请第11/232,494号中公开的发明的示例性和非限制性实施例，现在提供对根据本发明的发明示例性和非限制性实施例的描述。可以注意到本发明的示例性实施例可以结合在美国专利申请第11/232,494号中公开的发明的各种示例性实施例中的所有或者一些实施例来使用。

根据本发明的示例性实施例，以如下方式修改XML方案使得它清楚地定义在所支持的认证机制与可以与该具体机制一起使用的一个或者多个标识(id)之间的‘绑定’。如果一个标识可以与多个机制一起使用，则XML方案优选地列举所有可能的组合，例如：

机制1 id1

机制2 id2

机制3 id3

现在参照图8，一旦具有XML文档(基于XML方案)的第一HTTPGET消息作为有效载荷被BSF 8所接收(图8中的消息1)，BSF 8选择网络所偏好的机制并且联系适当的数据库以继续引导过程。如果所选机制恰好能与多于一个的标识(如在HTTP有效载荷中的XML文档中由MN 12列举的)一起使用，则BSF 8选择标识之一。一旦执行选择，由BSF在对GET请求的401响应(图8中的消息5)中返回给MN 12的XML文档明示地标识所选机制和对应的关联标识。

可以注意到XML方案定义了XML文档将如何显现。然后在HTTP消息的有效载荷中发送XML文档。由此，XML方案可以被认为是固定的并且在引导过程中没有被发送。然而，将遵循这一XML方案的XML文档作为HTTP有效载荷来发送以传送引导所需信息。

根据前文，将要插入到引导过程的消息中的标识如下所述：

A.从MN 12到BSF 8的HTTP GET请求(图8中的消息1)

HTTP GET请求中的授权报头可以包含MN 12标识中的任一标识。BSF 8这时不答复这一标识。优选地，HTTP有效载荷中的XML文档包含如上所述所支持的机制和MN 12标识的列表。

B.从BSF 8到MN 12的HTTP 401未授权响应(图8中的消息5)

BSF 8从在从MN 12接收的HTTP有效载荷中的XML文档中找到的列表中选择一个认证机制和一个对应标识。在响应消息的有效载荷中将所选认证机制以及对应标识返回给MN 12。

C.从MN 12到BSF 8的HTTP GET请求(图8中的消息7)

MN 12使用在先前消息的有效载荷中由BSF 8返回的它的标识作为HTTP摘要认证(授权报头字段)中的用户标识。MN 12和BSF 8然后根据BSF 8所选认证机制继续。优选地，HTTP有效载荷中的XML文档包含如上所述所支持的机制和MN 12标识。不同于消息1，此信息受完整性保护。

D.从BSF 8到MN 12的HTTP 200 OK响应(图8中的消息9)

BSF 8以指示了成功认证和引导操作的HTTP 200 OK消息做出响应。该消息也包括由BSF计算的摘要响应。该消息也可以包括所选认证机制以及对应标识的指示以供MN 12参照。类似地，通过将qop设置为“auth-int”来完整性保护这一指示。

其余的引导过程然后可以如在3GPP2 S.P0109-0，2005年12月8日第0.6版″Generic Bootstrapping Architecture(GBA)Framework″中所述那样继续，该文献作为证据C附于上文引用的美国临时专利申请第60/759,487号。这一文献有望作为3GPP2 S.S0109-0，vl.0来公布，并且当前最新版本为S00-20060220-121A_SP0109_V&V_changes.doc。

XML方案修改

当前XML方案如下：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<xs:schema targetNamespace＝″uri:3gpp2-gba″

xmlns:gba＝″uri:3gpp2-gba″

xmlns:xs＝″http://www.w3.org/2001/XMLSchema″>

<！--包含B-TID、密钥生命期和其它参数的根元素的定义-->

<xs:complexType name＝″bootstrappingInfoType″>

<xs:sequence>

<xs:element name＝″btid″type＝″xs:string″minOccurs＝″0″/>

<xs:element name＝″lifetime″type＝″xs:dateTime″minOccurs＝″0″/>

<xs:element name＝″esn″type＝″xs:base64Binary″minOccurs＝″0″/>

<xs:element name＝″ms_chall″ type＝″xs:base64Binary″

minOccurs＝″0″/>

<xs:element name＝″ms_result″ type＝xs:base64Binary″

minOccurs＝″0″/>

<xs:element name＝″bs_result″ type＝″xs:base64Binary″

minOccurs＝″0″/>

<xs:element name＝″auth_list″minOccurs＝″0″>

<xs:simpleType>

<xs:list itemType＝″gba:authType″/>

</xs:simpleType>

</xs:element>

<xs:element name＝″auth″type＝″gba:authType″minOccurs＝″0″/>

</xs:sequence>

</xs:complexType>

<！--认证和引导机制类型的定义-->

<xs:simpleType name＝″authType ″>

<xs:restriction base＝″xs:string″>

<xs:enumeration value＝″AKA″/>

<xs:enumeration value＝″CAVE″/>

<xs:enumeration value＝″MN-AAA″/>

</xs:restriction>

</xs:simpleType>

<！--根元素-->

</xs:schema>

可以对前述XML方案做出数个可能修改以便实施本发明的示例性实施例。下文是旨在作为举例而不是对本发明示例性实施例的实施和/或使用进行限制来阅读的数个例子。

例1

XML方案1：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<xs:schema targetNamespace＝″uri:3gpp2-gba″

xmlns:gba＝″uri:3gpp2-gba″

xmlns:xs＝″http:∥www.w3.org/2001/XMLSchema″>

<！--包含B-TID、密钥生命期和其它参数的根元素的定义-->

<xs:complexType name＝″bootstrappingInfoType″>

<xs:sequence>

<xs:element name＝″btid″type＝″xs:string″minOccurs＝″0″/>

<xs:element name＝″lifetime″type＝″xs:dateTime″minOccurs＝″0″/>

<xs:elemgnt name＝″esn″type＝xs:base64Binary″minOccurs＝″0″/>

<xs:element name＝″ms_chall″ type＝″xs:base64Binary″

minOccurs＝″0″/>

<xs:element name＝″ms_result″ type＝″xs:base64Binary″

minOccurs＝″0″/>

<xs:element name＝″bs_result″ type＝″xs:base64Binary″

minOccurs＝″0″/>

<xs:elememt name＝″auth_list″minOccurs＝″0″>

<xs:complexType>

<xs:sequence>

<xs:element name＝″auth_info″

type＝″gba:authInfo″minOccurs＝″1″/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name＝″auth″type＝″gba:authInfo″minOccurs＝″0″/>

</xs:sequence>

</xs:complexType>

<xs:complexType name＝″authInfo″>

<xs:sequence>

<xs:element name＝″method″type＝″gba:authType″/>

<xs:element name＝″clientid″type＝″xs:string″/>

</xs:sequence>

</xs:complexType>

<！--认证和引导机制类型的定义-->

<xs:simpleType name＝″authType″>

<xs:restriction basc＝″xs:string″>

<xs:enumeration value＝″AKA″/>

<xs:enumeration valuc＝″CAVE″/>

<xs:enumeration value＝″MN-AAA″/>

</xs:restriction>

</xs:simpleType>

<！--根元素-->

<xs:element name＝″BootstrappingInfo″ type＝″gba:bootstrappingInfoType″/>

</xs:schema>

下文是根据前述XML方案的“auth_list”的一个例子的“片断”：

<auth_list>

<auth_info>

<clientid>user1_private@home1.net</clientid>

</auth_info>

<auth_info>

</auth_info>

<auth_info>

<clientid>foo@example.com</clientid>

</auth_info>

</auth_list>

例2

XML方案2：

<？xml version＝″1.0encoding＝″UTF-8″？>

<xs:schema targetNamespace＝″uri:3gpp2-gba″

xmlns:gba＝″uri:3 gpp2-gba″

xmlns:xs＝″http:∥www.w3.org/2001/XMLSohema″>

<！--包含B-TID、密钥生命期和其它参数的根元素的定义-->

<xs:complexType name＝″bootstrappingInfoType″>

<xs:sequence>

<xs:element name＝″btid″type＝″xs:string″minOccurs＝″0″/>

<xs:element name＝″lifetime″type＝″xs:dateTime″minOccurs＝″0″/>

<xs:element name＝″esn″type＝″xs:base64Binary″minOccurs＝″0″/>

<xs:elemetn name＝″ms_chall″ type＝″xs:base64Binary″

minOccurs＝″0″/>

<xs:element name″ms_result″ type＝″xs:base64Binary″

minOccurs＝″0″>

<xs:element name＝″bs_result″ type＝″xs:base64Binary″

minOccurs＝″0″/>

<xs:element name＝″auth_list″minOccurs＝″0″>

<xs:complexType>

<xs:sequence>

<xs:element name＝″auth_info″

type＝″gba:authInfo″minOccurs＝″1″/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name＝″auth″type＝″gba:authInfo″minOccurs＝″0″/>

</xs:sequence>

</xs:complexType>

<xs:complexType name＝″authInfo″>

<xs:simpleContent>

<xs:extension base＝″gba:authType″>

<xs:attribute name＝″clientid″type＝″xs:string″use＝″required″/>

</xs:extension>

</xs:simpleContent>

</xs:complexType>

<！--认证和引导机制类型的定义-->

<xs:simpleType name＝″authType″>

<xs:restriction base＝″xs:string″>

<xs:enumeration value＝″AKA″/>

<xs:enumeration value＝″CAVE″/>

<xs:enumeration value＝″MN-AAA″/>

</xs:restriction>

</xs:simpleType>

<！--根元素-->

</xs:schema>

下文是根据这一XML方案的“auth_list”的一个例子的片断：

<auth_list>

<auth_info clientid ＝″user1_private@hom1.net″>AKA</auth_info>

<auth_info_clientid ＝″123456789012345″>CAVE</auth_info>

<auth_into clientid＝″foo@example.com″>MN-AAA</auth_info>

</auth_list>

例3

XML 方案3：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<xs:schema targetNamespace＝″uri:3gpp2-gba″

xmlns:gba＝″uri:3gpp2-gba″

xmlns:xs＝″http:∥www.w3.org/2001/XMLSchema″>

<！--包含B-TID、密钥生命期和其它参数的根元素的定义-->

<xs:complexType name＝″bootstrappingInfoType″>

<xs:sequence>

<xs:elemeut name＝″btid″type＝″xs:string″minOccurs＝″0″>

<xs:element name＝″lifetime″type＝″xs:dateTime″minOccurs＝″0″/>

<xs:element name＝″esn″type＝″xs:base64Binary″minOccurs＝″0″/>

<xs:element name＝″ms_chall″ type＝″xs:base64Binary″

minOccurs＝″0″/>

<xs:element name＝″ms_result″ type＝″xs:base64Binary″

minOccurs＝″0″/>

<xs:element name＝″bs_result″ type＝″xs:base64Binary′

minOccurs＝″0″/>

<xs:element name＝″auth_list″minOccurs＝″0″>

<xs:simpleType>

<xs:list itemType＝″gba:authType″>

</xs:simpleType>

</xs:element>

<xs:element name＝″auth″type＝″gba:authType″minOccurs＝″0″/>

<xs:element name＝″clientid_list″minOccurs＝″0″>

<xs:simpleType>

<xs:list itemType＝″xs:string″/>

</xs:simpleType>

</xs:element>

<xs:element name＝″clientid″type＝″xs:string″minOccurs＝″0″/>

</xs:sequence>

</xs:complexType>

<！--认证和引导机制类型的定义-->

<xs:simpleType name＝″authType″>

<xs:restriction base＝″xs:string″>

<xs:emumeration value＝″AKA″/>

<xs:emumeration value＝″CAVE″/>

<xs:emumeration value＝″MN-AAA″/>

</xs:restriction>

</xs:simpleType>

<！--根元素-->

</xs:schema>

下文是根据“auth_list”和“clientid_list”的片断：

<auth_list>AKA CAVE MN-AAA</auth_list>

<clientid_list>userl_private@homel.net 123456789012345 foo@example.com

</clientid_list>

图8示出了使用上述XML方案1的示例性呼叫流程。该例取自于3GPP2 S.P0109-0 2005年12月8日第0.6版″Generic BootstrappingArchitecture(GBA)Framework″的附录C的图C.3-1，该文献作为证据C附于上文引用的美国临时专利申请第60/759,487号。图8的例子强调了在HTTP有效载荷中产生的变化，因此只有消息1、5、7和9对于理解本发明的示例性实施例特别相关。其余的图可以与附录C中所示保持不变。

消息1.初始GET请求(MN 12到BSF 8)

这一消息的目的在于启动MN 12与BSF 8之间的引导过程。MN 12朝着它的归属BSF 8发送包含专用用户标识的HTTP请求。MN 12也在消息的有效载荷中将它所支持的引导机制的列表与对应标识一起呈现。

表：初始GET请求(MN 12到BSF 8)的例子

GET/HTTP/1.1

Host;bsf.home.net

User-Agent:Bootstrapping Client Agent

Date:

Accept:*/*

Referer:http:∥pki-portal.home1.net:2311/pkip/enroll

Authorization:Digest username＝″user1_private@home.nct″，realm＝″bsf.home.net″，nonce＝″″，

uri＝″/，response＝″″

Content-Type:application/vnd.3gpp2.bsf+xml

Content-Length:(...)

<？xml version＝″1.0″encoding＝″UTF-8″？>

<auth_list>

<auth_info>

<clientid>user1_private@home1.net<clientid>

</auth_info>

<auth_info>

</auth_info>

<auth_info>

<clientid>foo@example.com</clientid>

</auth_info>

</auth_list>

</BootstrappingInfo>

消息5.401未授权响应(BSF 8到MN 12)

BSF 8在HTTP 401未授权响应(没有CK、IK和XRES)中向MN8转发挑战。这是为了要求MN 12认证自身。该挑战包含根据RFC 3310(IETF RFC 3310“Digest AKA”，作为证据B附于上文引用的美国临时专利申请第60/759,487号)在临时数字段中填充的RAND和AUTN。

表：401未授权响应(BSF 8到MN 12)的例子

HTTP/1.1 401 Unauthorized

Server;Bootstrapping Server

Date:Mon，24 Oct 2005 10:13:17GMT

WWW-Authenticate:Digest realm＝″bsf.home.net″，nonce＝base64(RAND+AUTN+server

specific data)，algorithm＝AKAv 1-MD5，qop＝auth-int

Content-Type:application/vnd，3gpp2.bsf+xmI

Content-Lengh:(...)

<？xml version＝″1.0″encoding＝″UTF-8″？>

<auth>

<clienticd>user1_private@home1.net.</clientid>

</auth>

</BootstrappingInfo>

消息7.GET请求(MN 12到BSF 8)的例子

MN 12再次将具有用于响应计算的RES的HTTP GET请求发送到BSF 8。

表：GET请求(MN 12到BSF 8)的例子

GET/HTTP/1.1

IIost:bsf.home.net

User-Agent:Bootstrapping Client Agent

Date:Mon，24 Oct 2005 10:13:18 GMT

Accept*/*

Referer:http://pki-portal.home.net:2311/pkip/enroll

Authorization:Digest usern ame＝″user1_private@home.net″，realm＝″bsf.home.net″，

nonce＝base64(RAND+AUTN+server specific data)，uri＝″/″，qop＝auth-int，nc＝00000001，

cnoncc＝″6629fae49393a05397450978507c4ef1″，

response＝″6629fae49393a05397450978507c4ef1″，

opaqne＝″5ccc069c403ebaf9f0171e9517f30o41″，algorithm＝AKAv1-MD5

Content-Type:application/vnd.3 gpp2.bsf+xml

Content-Length:(...)

<？xml version＝″1.0″encoding＝″UTF-8″？>

<auth_list>

<auth_info>

<clientid> user1_private@home1.netuser1_private@home1.net

</clientid>

</auth_info>

<auth_info>

</auth_info>

<auth_info>

<clientid>foo@example.com</clientid>

</auth_info>

</auth_list>

</BootstrappingInfo>

消息9.例子200 OK响应(BSF 8到MN 12)

BSF 8将200 OK响应发送到MN 12以指示认证成功。

表：200 OK响应(BSF 8到MN 12)

HTTP/1.1200 OK

Server:Bootstrapping Server

Authentication-Info:qop＝auth-int，rspauth＝″6629fae49394a05397450978507c4ef1″，

cnonce＝″6629fae49393a05397450978507c4ef1″，nc＝00000001

Date:

Expires:*date/time*

Content-Type:application/vnd.3gpp.bsf+xml

Content-Length:(...)

<？xml version＝″1.0″encoding＝″UTF-8″？>

<auth>

<clientid>user1_private@home1.net</clientid>

</auth>

<btid>bmFtYXJ0bHUgc2F5cyBoaQ＝@bsf.operator.com</btid>

</BootstrappingInfo>

基于前文应当明显的是本发明的示例性实施例提供一种方法、装置和计算机程序产品用以：向无线网络(WN)发送第一消息，该第一消息包括节点所支持的认证机制的列表以及与各认证机制相关联的对应标识；以及在WN中至少基于从节点接收的列表来确定将要用于引导的认证机制；以及在对节点的第一响应消息中包括结合对应标识的与确定认证机制有关的信息。

可以认识到本发明的示例性实施例的一个方面在于：在本发明中，当在HTTP有效载荷中发送“认证机制”时，也包括不失一般性在这里也称为标识的对应标识。从这一点来看，对于来自MN 12的第一和第二请求，在HTTP有效载荷中包括所支持的机制的列表，因此也包括对应标识。另外对于WN发送的第一和第二响应，在有效载荷中包括所选认证机制，也包括对应标识。另外，来自MN 12的第二请求也包含列表以及对应标识，并且此信息受完整性保护。类似地，所选机制以及对应标识如果存在于第二响应中则优选地也受完整性保护。

一般而言，可以用硬件或者专用电路、软件、逻辑或者其任何组合来实施各种实施例。例如，可以用硬件实施一些方面，而可以用可由控制器、微处理器或者其它计算设备执行的固件或者软件实施其它方面，虽然本发明不限于此。尽管本发明的各种方面可以图示和描述为框图、流程图或者使用一些其它图形表示来描述，但是很好理解这里描述的这些块、装置、系统、技术或者方法可以实施于作为非限制性例子的硬件、软件、固件、专用电路或者逻辑、通用硬件或者控制器或者其它计算设备或者其一些组合中。

本发明的实施例可以实施于各种部件如集成电路模块中。集成电路的设计主要借助高度自动化工艺。复杂和强大的软件工具可用于将逻辑级设计转换成准备好在半导体衬底上被蚀刻和形成的半导体电路设计。

比如加利福尼亚芒廷维尤的Synopsys公司以及加利福尼亚圣何塞的Cadence Design公司提供的程序这样的程序使用建立好的设计规则以及预存设计模块库在半导体芯片上自动地对导体进行布线和对部件进行定位。一旦已经完成用于半导体电路的设计，标准化电子格式(例如Opus、GDSII等)的所得设计可以发送到半导体制作设施或者“fab”以进行制作。

在结合附图来阅读时鉴于的以上描述，各种修改和变化对于本领域技术人员来说可以变得明显。作为非限制性例子，其它类型的消息格式等可以用于在设备12与一个或者多个无线网络单元8之间传送信息和/或除了上文具体提到的认证机制之外或者取而代之还可以使用其它类型的认证机制。然而，本发明的教导的任何和所有修改仍然将落入本发明的非限制性实施例的范围内。

另外，本发明的非限制性实施例的一些特征在没有对应使用其它特征的情况下仍然可以有利地加以利用。这样，以上描述应当被认为仅仅说明本发明的原理、教导和示例性实施例而不是对它们进行限制。

Claims

1.一种方法，包括：

在无线网络(WN)中接收第一消息，所述第一消息包括节点所支持的认证机制的列表以及与各认证机制相关联的对应标识；

至少基于从所述节点接收的列表在所述WN中确定将要用于引导的认证机制；以及

在向所述节点发送的第二消息中包括如下信息，所述信息包括结合对应标识的所述确定的认证机制。

2.根据权利要求1所述的方法，其中如果所述确定的认证机制可与多个标识一起使用则还包括选择所述标识之一以与所述确定的认证机制相关联。

3.根据权利要求1所述的方法，其中所述第一消息包括HTTPGET请求，以及其中所述第二消息包括第一响应消息，所述第一响应消息包括明示地标识所述确定的认证机制以及对应标识的XML文档。

4.根据权利要求3所述的方法，还包括在所述WN中接收基于所述确定的认证机制来至少部分完整性保护的第三消息，所述第三消息以完整性保护的形式包括所述节点所支持的认证机制的列表以及对应标识；

如果认证成功以及如果在所述第三消息中接收的列表与在所述第一消息中接收的列表相匹配，则以至少部分完整性保护的第二响应消息对所述节点做出响应，其中所述第二响应消息可以以完整性保护的形式包括所选认证机制的指示以及对应标识。

5.根据权利要求4所述的方法，还包括接收所述第三消息以及检验所述节点所使用的认证机制与所述WN所确定的认证机制相匹配。

6.根据权利要求1所述的方法，其中至少所述确定步骤由引导服务器功能(BSF)执行。

7.根据权利要求1所述的方法，其中所述第一消息是HTTPGET，其中所述列表包含于HTTP有效载荷中。

8.根据权利要求1所述的方法，其中所述第二消息是HTTP 401未授权响应。

9.根据权利要求4所述的方法，其中所述第三消息是包括根据所选认证机制的计算响应的HTTP GET。

10.根据权利要求4所述的方法，其中所述第二响应消息是HTTP200 OK消息。

11.一种实施于计算机可读介质中的计算机程序产品，节点的数据处理器对所述计算机程序产品的执行包括以下操作：

向无线网络(WN)发送第一消息，所述第一消息包括所述节点所支持的认证机制的列表以及与各认证机制相关联的对应标识；以及

从所述WN接收第一响应消息，所述第一响应消息包括与结合对应标识的由所述WN从所述节点在所述第一消息中提供的所述列表中选择的认证机制有关的信息。

12.根据权利要求11所述的计算机程序产品，还包括以下操作：向所述WN发送至少部分完整性保护的第二消息，所述第二消息以完整性保护的形式包括所述节点所支持的认证机制的列表以及对应标识。

13.根据权利要求11所述的计算机程序产品，还包括以下操作：接收至少部分完整性保护的第二响应消息，其中所述第二响应消息以完整性保护的形式包括所选认证机制的指示以及对应标识。

14.根据权利要求13所述的计算机程序产品，其中从引导服务器功能(BSF)接收至少所述第一和第二响应消息。

15.根据权利要求11所述的计算机程序产品，其中所述第一消息作为HTTP GET来发送，其中所述列表包含于HTTP有效载荷中，以及其中所述第一响应消息作为HTTP 401未授权响应来接收。

16.根据权利要求12所述的计算机程序产品，其中所述第二消息作为包括根据所选认证机制的计算响应的HTTP GET来发送。

17.根据权利要求13所述的计算机程序产品，其中所述第二响应消息作为HTTP 200 OK消息来接收。

18.根据权利要求11所述的计算机程序产品，还包括检验所述节点所使用的认证机制与所述WN所选择的认证机制相匹配。

19.一种设备，包括数据处理器，所述数据处理器耦合到发送器和接收器并且可操作用以：经由所述发送器向网络发送第一消息，所述第一消息包括所述设备所支持的认证机制的列表以及与各认证机制相关联的对应标识；以及经由所述接收器从所述网络接收第一响应消息，所述第一响应消息包括结合对应标识的与由所述网络从所述列表中选择的认证机制有关的信息。

20.根据权利要求19所述的设备，其中所述数据处理器还可操作用以：完整性保护所述设备所支持的认证机制的列表；以及经由所述发送器向所述网络发送至少部分完整性保护的第二消息，所述第二消息以完整性保护的形式包括至少所述设备所支持的认证机制的列表以及对应标识。

21.根据权利要求19所述的设备，其中所述数据处理器还从所述网络接收至少部分完整性保护的第二响应消息，其中所述第二响应消息以完整性保护的形式包括所选认证机制的指示以及所述对应标识。

22.根据权利要求21所述的设备，其中从包括所述网络的部分的引导服务器功能(BSF)接收至少所述第一和第二响应消息。

23.根据权利要求19所述的设备，其中所述第一消息作为HTTPGET来发送，其中所述列表包含于HTTP有效载荷中，以及其中所述第一响应消息作为HTTP 401未授权响应来接收。

24.根据权利要求20所述的设备，其中所述第二消息作为包括根据所选认证机制的计算响应的HTTP GET来发送。

25.根据权利要求21所述的设备，其中所述第二响应消息作为HTTP 200 OK消息来接收。

26.根据权利要求19所述的设备，其中所述数据处理器进一步可操作用以检验所述设备所使用的认证机制与所述网络所选择的认证机制相匹配。

27.一种实施于计算机可读介质中的计算机程序产品，无线网络单元(WNE)的数据处理器对所述计算机程序产品的执行包括以下操作：

从节点接收第一消息，所述第一消息包括所述节点所支持的认证机制的列表以及与各认证机制相关联的对应标识；

至少部分基于从所述节点接收的列表来确定将要用于引导的认证机制；

向所述节点发送第一响应消息，所述第一响应消息包括与所述确定的认证机制以及对应标识有关的信息；以及

从所述节点接收至少部分完整性保护的第二消息，所述第二消息以完整性保护的形式至少包括所述节点所支持的认证机制的列表以及对应标识。

28.根据权利要求27所述的计算机程序产品，其中如果认证成功以及如果在所述第二消息中接收的列表与在所述第一消息中接收的列表相匹配，则还包括以下操作：向所述节点发送至少部分完整性保护的第二响应消息，其中所述第二响应消息可以用完整性保护的形式包括所选认证机制的指示以及对应标识。

29.根据权利要求27所述的计算机程序产品，还包括基于所述标识获取配置文件，以及其中所述确定操作考虑所述配置文件。

30.根据权利要求27所述的计算机程序产品，其中所述无线网络包括引导服务器功能(BSF)。

31.根据权利要求27所述的计算机程序产品，其中所述第一消息作为包括所述节点的用户的标识的HTTP GET来接收，其中所述列表包含于HTTP有效载荷中。

32.根据权利要求27所述的计算机程序产品，其中所述第一响应消息作为HTTP 401未授权响应来发送。

33.根据权利要求27所述的计算机程序产品，其中所述第二消息作为包括根据所选认证机制的计算响应的HTTP GET来接收。

34.根据权利要求28所述的计算机程序产品，其中所述第二响应消息作为HTTP 200 OK消息来发送。

35.一种网络设备，包括数据处理器，所述数据处理器耦合到发送器和接收器并且可操作用以经由所述接收器从节点接收第一消息，所述第一消息包括所述节点所支持的认证机制的列表以及与各认证机制相关联的对应标识，所述数据处理器还可操作用以：至少部分基于从所述节点接收的列表来确定将要用于引导的认证机制；以及经由所述发送器向所述节点发送第一响应消息，所述第一响应消息包括与所述确定的认证机制以及对应标识有关的信息，所述数据处理器还可操作用以从所述节点接收至少部分完整性保护的第二消息，所述第二消息以完整性保护的形式包括所述节点所支持的认证机制的列表以及对应标识。

36.根据权利要求35所述的网络设备，所述数据处理器还可操作用以：如果认证成功以及如果在所述第二消息中接收的列表与在所述第一消息中接收的列表相匹配，则向所述节点发送至少部分完整性保护的第二响应消息，其中所述第二响应消息以完整性保护的形式包括所选认证机制的指示以及所述对应标识。

37.根据权利要求35所述的网络设备，其中所述数据处理器还可操作用以基于所述标识获取配置文件以供在确定将要用于引导的认证机制时考虑。

38.根据权利要求35所述的网络设备，包括引导服务器功能(BSF)。

39.根据权利要求35所述的网络设备，其中所述第一消息作为包括所述节点的用户的标识的HTTP GET来接收，其中所述列表包含于HTTP有效载荷中。

40.根据权利要求35所述的网络设备，其中所述第一响应消息作为HTTP 401未授权响应来发送。

41.根据权利要求35所述的网络，其中所述第二消息作为包括根据所选认证机制的计算响应的HTTP GET来接收。

42.根据权利要求36所述的网络设备，其中所述第二响应消息作为HTTP 200 OK消息来发送。

43.一种设备，包括：用于向网络发送第一消息的装置，所述第一消息包括所述设备所支持的认证机制的列表以及与各认证机制相关联的对应标识；以及用于从所述网络接收第一响应消息的装置，所述第一响应消息包括描述了所述网络从所述列表中选择的认证机制以及对应标识的信息，该设备还包括用于完整性保护所述设备所支持的认证机制的列表以便向所述网络发送至少部分完整性保护的第二消息的装置，所述第二消息以完整性保护的形式包括所述设备所支持的认证机制的列表以及与各认证机制相关联的对应标识。

44.根据权利要求43所述的设备，其中所述接收装置还可操作用以从所述网络接收至少部分完整性保护的第二响应消息，其中所述第二响应消息以完整性保护的形式包括所选认证机制的指示以及所述对应标识。

45.根据权利要求43所述的设备，还包括用于检验所述设备所使用的认证机制与所述网络所选择的认证机制相匹配的装置。

46.一种网络设备，包括：用于从节点接收第一消息的装置，所述第一消息包括所述节点所支持的认证机制的列表以及与各认证机制相关联的对应标识；用于至少部分基于从所述节点接收的列表来选择将要用于引导的认证机制的装置；以及用于将第一响应消息发送到所述节点的装置，所述第一响应消息包括与所选认证机制以及对应标识有关的信息，所述接收装置还可操作用于从所述节点接收至少部分完整性保护的第二消息，所述第二消息包括所述节点所支持的认证机制的列表以及与各认证机制相关联的所述对应标识。

47.根据权利要求46所述的网络设备，其中所述发送装置用于响应于成功认证以及在所述第二消息中接收的列表与在所述第一消息中接收的列表相匹配而向所述节点发送至少部分完整性保护的第二响应消息，其中所述第二响应消息以完整性保护的形式包括所选认证机制的指示以及所述对应标识。

48.根据权利要求46所述的网络设备，还包括用于基于所述标识来取回配置文件以供所述选择装置在选择将要用于引导的所述认证机制时使用的装置。

49.根据权利要求46所述的网络设备，包括引导服务器功能(BSF)。

50.一种系统，包括耦合到网络设备的设备，所述设备包括数据处理器，所述数据处理器耦合到发送器和接收器并且可操作用以经由所述发送器向所述网络设备发送第一消息，所述第一消息包括所述设备所支持的认证机制的列表以及与各认证机制相关联的对应标识，所述网络设备包括数据处理器，所述数据处理器耦合到发送器和接收器并且可操作用以从所述列表中选择认证机制，所述设备经由所述接收器从所述网络设备接收第一响应消息，所述第一响应消息包括与所述网络设备从所述列表中选择的认证机制以及对应标识符有关的信息，所述设备的数据处理器可操作用以：至少部分完整性保护至少所述设备所支持的认证机制的列表以及所述对应标识；以及经由所述发送器发送第二消息到所述网络设备，所述第二消息包括所述认证机制的列表以及对应标识。

51.根据权利要求50所述的系统，其中所述数据处理器还从所述网络设备接收至少部分完整性保护的第二响应消息，其中所述第二响应消息以完整性保护的形式包括所述网络设备所选择的所述认证机制的指示以及所述对应标识。

52.根据权利要求50所述的系统，其中所述网络设备包括引导服务器功能(BSF)。

53.根据权利要求50所述的系统，其中所述设备通过无线链路耦合到所述网络设备。

54.一种方法，包括：

向网络发送第一消息，所述第一消息包括设备所支持的认证机制的列表以及与各认证机制相关联的对应标识；以及

从所述网络接收第一响应消息，所述第一响应消息包括结合对应标识的与由所述网络从所述列表中选择的认证机制有关的信息。

55.根据权利要求54所述的方法，还包括：

完整性保护至少所述设备所支持的认证机制的列表以及所述对应标识；以及

发送第二消息到所述网络，所述第二消息至少包括所述认证机制的列表以及所述对应标识。

56.根据权利要求54所述的方法，还包括：

从所述网络接收至少部分完整性保护的第二响应消息，其中所述第二响应消息包括所选认证机制的指示以及所述对应标识。

57.根据权利要求56所述的方法，其中从包括所述网络的部分的引导服务器功能(BSF)接收至少所述第一和第二响应消息。

58.根据权利要求54所述的方法，其中所述第一消息作为HTTPGET来发送，其中所述列表包含于HTTP有效载荷中，以及其中所述第一响应消息作为HTTP 401未授权响应来接收。

59.根据权利要求55所述的方法，其中所述第二消息作为包括根据所选认证机制的计算响应的HTTP GET来发送。

60.根据权利要求56所述的方法，其中所述第二响应消息作为HTTP 200 OK消息来接收。

61.根据权利要求54所述的方法，还包括检验所述设备所使用的认证机制与所述网络所选择的认证机制相匹配。