在通用自举架构中的网络应用功能授权的制作方法

xiaoxiao2020-9-10  4

【知识产权代理】【专利服务】Tel:18215660330

在通用自举架构中的网络应用功能授权的制作方法
【专利摘要】本发明提供了一种在通用自举架构GBA中授权订户用户设备访问网络应用功能NAF的方法。所述方法包括:在自举服务器功能BSF处,从NAF接收对订户用户设备的密钥材料的请求,其中NAF与一个或多个NAF标识符NAF_ID相关联;从归属订户系统HSS获得订户信息,所述信息包括对订户有效的一个或多个NAF_ID;根据所述NAF的标识和包括在订户信息中的NAF_ID,授权订户用户设备。在授权订户用户设备的情况下,使用包含在所述订户信息中的NAF_ID来导出密钥材料;并向所述NAF发送所述密钥材料。
【专利说明】在通用自举架构中的网络应用功能授权

【技术领域】
[0001] 本发明涉及在通用自举架构中使用的方法和装置。更具体地,本发明涉及用于授 权订户用户设备的方法和装置。

【背景技术】
[0002] 为了方便向用户终端供应服务,例如3G网络的移动网络通常需要在客户终端(例 如,移动终端)和提供服务的基于网络的服务节点之间建立安全的通信信道或"安全关 联"。3GPP技术规范TS 33. 220V11. 1.0(2011-12)中定义的通用自举架构(GBA)提供可以 向网络应用功能(NAF)(即,应用服务器)认证客户终端(UE)的机制,以及为在客户终端和 NAF之间使用而获得的安全会话密钥。图1示意性地示出了如3GPP TS33. 220所述的GBA 的简单网络模型的示例,包括自举服务器功能(BSF)、网络认证功能(NAF)、订户定位功能 (SLF)、归属订户系统(HSS)和用户设备(UE)。NAF和UE之间的通信经由参考点Ua,NAF和 BSF之间的通信经由参考点Zn,UE和BSF之间的通信经由参考点Ub,BSF和HSS之间的通 信经由参考点Zh,而BSF和SLF之间的通信经由参考点Dz。
[0003] 当UE希望联系NAF且前期没有在UE和NAF之间建立安全关联时,UE可以通过通 信请求来联系NAF,所述请求可以不包括任何GBA相关参数。如果NAF需要使用通过GBA获 得的安全关联,则NAF可以用自举发起消息来响应UE。然后UE用BSF开始自举过程。GBA 根据3GPP TS33. 102所述的3GPPAKA机制,针对应用安全性提供自举认证与密钥协商(AKA) 的机制。这种机制允许向BSF认证UE并且UE获得主密钥(Ks)和自举业务标识符(B-TID)。 GBA用户安全设置(GUSS)是全部用户安全设置的集合,并被存储在HSS中。在自举过程期 间,BSF从HSS获得⑶SS。在图2中将自举过程表示为步骤2. 1)。
[0004] 在UE和BSF之间共享主密钥Ks,但不与NAF进行共享。相反,通过UE得到应用专 用密钥Ks_NAF。基于Ks和NAF_ID来导出Ks_NAF,其中NAF_ID被构造为NAF的完全限定 域名(FQDN)和参考点Ua的安全协议标识符的串接。在3GPP TS 33. 220中描述了 Ks_NAF 的导出,并在图2中将Ks_NAF的导出表示为步骤2. 2)。
[0005] 然后UE在应用请求中经由参考点Ua向NAF提供B_TID。图2中将该步骤表示为步 骤2. 3)。在NAF处接收到该应用请求之后,如图2的步骤2. 4. 1所示,NAF确定NAF_ID,检 验是否授权用户使用该NAF_ID。然后如图2的步骤2. 4. 2所示,NAF向BSF发送包括B-TID 和NAF_ID在内的认证请求。
[0006] 一旦接收到该认证请求,BSF使用B-TID来查找主密钥Ks,BSF基于Ks和由NAF 提供的NAF_ID,导出应用专用密钥Ks_NAF。在图2中将该步骤表示为步骤2. 5)。如图2的 步骤2. 6)所示,BSF向NAF回送包括Ks_NAF在内的认证答复。BSF还可以在对NAF的认证 答复中包括其它信息,例如自举时间和密钥寿命。如果由B_TID识别的密钥在BSF处是不 可用的,则BSF将在对NAF的回复中指示该情况,然后NAF向UE发送自举重新协商请求。
[0007] 现在NAF和UE二者都知道Ks_NAF的值,它们可以使用该密钥来保护在NAF和UE 之间经由参考点Ua的通信(步骤2. 7)。
[0008] 基于NAF的NAF_ID来导出应用专用密钥Ks_NAF,而NAF_ID是基于NAF的FQDN 的。特定的FQDN唯一地识别NAF。如果发生以下三个情况中的一个情况,则在UE处导出 的Ks_NAF与在BSF处导出的Ks_NAF相同。首先,NAF仅具有一个FQDN。其次,NAF具有多 个FQDN,每个FQDN关系到单独的IP地址。NAF可以通过分析输入请求的目的地IP来确定 UE使用哪个FQDN来导出密钥。第三,NAF具有多个FQDN,UE可以在它的请求中(例如,在 HTTP请求的Host首部中)包括用于导出密钥的FQDN。第三种情况可以是当NAF仅具有一 个IP地址但具有多个FQDN的情况。因此,NAF需要知道UE使用哪个FQDN,使得它可以从 BSF获得正确的Ks_NAF。然后NAF验证FQDN并向BSF发送该FQDN。
[0009] 在一些情况下,需要将一个物理NAF节点分为服务不同用户集合的若干个逻辑 NAF。例如,配置了单个NAF节点的服务供应商可能想要确保来自不同企业的用户不会彼此 干扰,其中可从若干企业网络访问所述单个NAF节点。存在若干个实现这种分离的方式,但 是特别方便的一个方式是向每个企业分配单独的FQDN(例如,naf. enterpriseX. com)并使 用多个FQDN来区分用户。然而,为了确保使用来自较大集合的FQDN中的特定FQDN的安全 性,NAF必须检验是否授权用户使用特定FQDN。对用户的授权需要在NAF处维护用户数据 库,或者需要将企业名称包括在用户ID中。
[0010] 还存在可能需要多个FQDN的其它情景。例如,当从内部网络访问NAF时,NAF可能 根据第一 FQDN是已知的,当从公共互联网访问NAF时,NAF可能根据第二FQDN是已知的。 [0011] 将多个FQDN存储在NAF中并将多个FQDN与不同的用户集合快速关联已成为一种 管理负担。当存在多个要维护的NAF时和当FQDN和用户频繁改变时,该问题可能更加严重。


【发明内容】

[0012] 本发明的目的在于克服或至少缓解上述缺点。通过将全部FQDN相关信息以及全 部其它用户数据提供在HSS中,而不是令每个NAF自己维护FQDN相关信息,来实现所述目 的。
[0013] 根据本发明的第一方面,提供了一种在通用自举架构GBA中授权订户用户设备访 问网络应用功能NAF的方法。所述方法包括:在自举服务器功能BSF处,从NAF接收对订户 用户设备的密钥材料的请求,其中NAF与一个或多个NAF标识符NAF_ID相关联;从归属订 户系统HSS获得订户信息,所述信息包括对订户有效的一个或多个NAF_ID ;根据所述NAF 的标识和包括在订户信息中的NAF_ID,授权订户用户设备。在授权订户用户设备的情况下, 使用包含在所述订户信息中的NAF_ID来导出密钥材料;以及向所述NAF发送所述密钥材 料。
[0014] 所述请求可以包括NAF标识符,并且所述授权步骤可以包括:将包含在所述请求 中的NAF标识符与包括在所述订户信息中的NAF标识符相匹配。
[0015] 所述从NAF接收到的请求可以不包含NAF标识符。
[0016] 所述订户信息可以包括GBA用户安全设置⑶SS。可以使用完全限定域名FQDN来 构造 NAF标识符。
[0017] 根据本发明的第二方面,提供了一种被配置为操作作为自举服务器功能BSF的装 置,在通用自举架构GBA中使用。所述装置包括第一接收器,用于从网络应用功能NAF接收 对订户用户设备的密钥材料的请求,其中所述NAF与一个或多个NAF标识符相关联。所述 装置还包括第二接收器,用于从归属订户系统HSS接收订户信息,所述信息包括对订户有 效的一个或多个NAF标识符。所述装置还包括:第一处理器,用于根所述NAF的标识和包括 在订户信息中的NAF标识符,授权订户用户设备;以及第二处理器,布置为在授权订户用户 设备的情况下,使用包含在所述订户信息中的NAF标识符来导出密钥材料。所述装置还包 括发送器,用于向所述NAF发送所述密钥材料。
[0018] 所述请求可以包括NAF标识符,所述第一处理器还可以被布置为将包含在所述请 求中的NAF标识符与包括在所述订户信息中的NAF标识符相匹配。所述订户相关信息可以 包括GBA用户安全设置⑶SS。可以使用完全限定域名FQDN来构造 NAF标识符。
[0019] 根据本发明的第三方面,提供了一种在通用自举架构GBA中授权订户用户设备来 访问网络应用功能NAF的方法。所述方法包括:在订户用户设备处,向NAF发送请求,其中所 述NAF与一个或多个NAF标识符NAF_ID相关联;以及在NAF处接收所述请求。在NAF处, 向自举服务器功能BSF发送认证请求,并在BSF处接收所述认证请求。在BSF处,从归属订 户系统HSS获得订户信息,所述信息包括对订户有效的一个或多个NAF_ID。在BSF处,根据 所述NAF的标识和包括在订户信息中的NAF_ID,来授权订户用户设备。在授权订户用户设 备的情况下,使用包含在所述订户信息中的NAF_ID来导出密钥材料。向NAF发送所述密钥 材料,并在所述NAF处接收密钥材料。
[0020] 所述方法还可以包括:在用户设备处,从BSF获得临时标识符B-TID以及主密钥, 并将B-TID包括在所述向NAF发送的请求中;以及在BSF处,使用B-TID识别在订户信息中 的正确NAF标识符。
[0021] 所述认证请求可以包括NAF标识符,并且所述授权步骤可以包括:在BSF处,将包 含在所述请求中的NAF标识符与包括在所述订户信息中的NAF标识符相匹配。
[0022] 所述由NAF发送的认证请求可以不包含NAF标识符。
[0023] 所述订户相关信息可以包括GBA用户安全设置⑶SS。
[0024] 可以使用完全限定域名FQDN来构造 NAF标识符。
[0025] 根据本发明的第四方面,提供了一种包括计算机可读代码的计算机程序,当在装 置上运行所述计算机可读代码时,使得所述装置用作根据本发明的第二方面的装置。
[0026] 根据本发明的第五方面,提供了一种包括计算机可读介质和计算机程序的计算机 程序产品,其中所述计算机程序包括计算机可读代码,当在装置上运行所述计算机可读代 码时,使得所述装置用作根据本发明的第二方面的装置,并且将所述计算机程序存储在所 述计算机可读介质上。

【专利附图】

【附图说明】
[0027] 图1示意性地示出了 GBA的简单网络模型的示例;
[0028] 图2示出了由GBA提供的自举与密钥导出机制的示例信号流;
[0029] 图3是示出了授权订户用户设备的方法的流程图;
[0030] 图4示意性地示出了适合于实现授权订户用户设备的方法的BSF的示例;
[0031] 图5是示出了根据第一实施例的授权订户用户设备的方法的流程图;
[0032] 图6示出了与第一实施例相关联的信号流;
[0033] 图7是示出了根据第二实施例的授权订户用户设备的方法的流程图;以及
[0034] 图8示出了与第二实施例相关联的信号流。

【具体实施方式】
[0035] 在3GPP技术规范TS 33. 220中定义的通用自举架构(GBA)提供可以向网络应用 功能(NAF)认证客户终端(UE)的机制,以及为在UE和NAF之间使用而获得的安全会话密 钥。如图2所示,GBA提供了如下机制:UE用自举服务器功能(BSF)进行自举使得向BSF认 证UE,并且得到了主密钥Ks和自举交易标识符(B-TID)。在自举期间,BSF从归属订户系 统(HSS)获得GBA用户安全设置(⑶SS)。然后UE基于Ks和NAF标识符NAF_ID,导出应用 专用密钥Ks-NAF,其中NAF_ID被构造为NAF的完全限定域名(FQDN)和参考点Ua的安全协 议标识符的串接,其中UE和NAF之间的通信经由所述参考点Ua。然后,UE向NAF发送包括 B-TID的应用请求。当接收到该请求时,NAF确定并验证NAF_ID。NAF在认证请求中向BSF 发送B-TID和NAF_ID。当接收到该认证请求时,BSF使用接收到的B-TID查找Ks,并基于 Ks和NAF_ID,导出Ks_NAF。BSF在认证答复中向NAF发送所述Ks_NAF。现在NAF和UE共 享相同的密钥Ks_NAF,可以将所述Ks_NAF用于保护在NAF和UE之间的通信。
[0036] 可能需要将一个物理NAF节点分为服务不同用户的多个逻辑NAF。然后可以向每 个用户或每个用户组分配单独的FQDN。在导出密钥Ks_NAF的期间,NAF必须通过检验是否 授权特定用户使用NAF_ID所基于的特定FQDN,来验证该NAF_ID。将多个FQDN存储在NAF 中并将其与不同用户相关联是NAF的管理负担。
[0037] 可以将全部的FQDN相关信息以及全部的其它用户数据提供在HSS中,而不是令每 个NAF自己维护FQDN相关信息。这样,对NAF节点的布置和管理变得不那么复杂。在自举 期间,可以将FQDN的集合包括在从HSS向BSF传送的⑶SS中,其中所述FQDN是当UE联系 特定NAF时允许使用的FQDN。BSF可以向NAF转发该认证信息,或它可以自己实现该认证 信息。
[0038] 图3是从高级别示出了当从HSS获得FQDN相关信息而不是将其存储在NAF中时, 在BSF处实施的用于导出密钥材料的步骤的流程图。当BSF接收到(S3. 1)对密钥材料的 请求时,BSF从HSS获得(S3. 2)包括FQDN的订户信息。备选地,例如,如果BSF在初始自 举过程期间获得具有FQDN的订户信息,则这两个步骤的顺序(S3. 1和3. 2)可以是不同的。
[0039] 图4示意性地示出了适于实现授权订户UE来访问NAF的方法的BSF 1的示例。可 以将BSF 1实现为计算机硬件和软件的组合。BSF 1包括接收器2,用于从NAF接收授权请 求;以及第二接收器3,用于从HSS接收包括FQDN的订户信息。BSF 1包括第一处理器4,用 于根据订户信息来检验是否允许所述UE使用特定FQDN。BSF 1包括用于导出密钥Ks_NAF 的第二处理器5。BSF 1包括用于向NAF发送认证答复的发送器6。BSF 1还包括用于存储 数据的存储器7。
[0040] 更详细地考虑该方法,图5描述了第一实施例,图5是示出了在BSF处用于产生 认证答复的方法步骤的流程图。BSF从NAF接收(S5. 1)对密钥材料的请求并从HSS获得 (S5. 2)订户信息。由于从HSS获得包括UE被授权使用的FQDN的订户信息,对密钥材料的 请求不需要包含NAF_ID。BSF导出(S5. 3)密钥材料,并向NAF发送(S5. 4)该密钥材料。将 确定并验证NAF_ID的作用从NAF移到BSF,从而减少NAF节点的管理负担。
[0041] 现在参考图6更详细地描述第一实施例。在自举期间(图6的步骤6. 1),UE获得 B-TID和主密钥Ks,BSF获得包括在⑶SS中的FQDN的集合,其中允许UE使用所述FQDN。 FQDN的集合可以包括单个FQDN或多个FQDN,并针对每个NAF列出。然后UE基于主密钥 Ks和NAF_ID导出(步骤6. 2)应用专用密钥Ks_NAF。NAF_ID是NAF的FQDN和Ua安全性 协议标识符(图6中被表示为PROTO_ID)的串接。尽管图6将所述串接表示为NAF_ID = FQDN | | PROTO_ID,但是还可以以与NAF_ID不同的方式来构造所述NAF标识符。然后UE以 与先前所述的相似方式向NAF发送应用请求(步骤6. 3),其中所述请求包括B-TID。在NAF 处,当接收到所述请求时,向BSF发送包括B-TID的认证请求(步骤6. 4)。并非如图2的 步骤2. 4. 1)所示,此时NAF不确定并且不验证NAF_ID。当接收到认证请求时,BSF通过参 考与UE相关联的GUSS来确定正确的FQDN。所述FQDN与用户在步骤6. 2)使用的FQDN相 同。BSF确定NAF_ID,并由BSF来构造 Ks_NAF (步骤6. 5)。在认证回复中将Ks_NAF发送给 NAF (步骤6. 6)。现在NAF和UE二者都知道Ks_NAF的值,它们可以使用该密钥来保护经由 参考点Ua的NAF和UE之间的通信(步骤6. 7)。可以将传输层安全性(TLS)网络协议用于 在NAF和UE之间的通信。图6的步骤6. 5)代替图2的步骤2. 4. . 1),NAF不再需要向BSF 转发 NAF_ID。
[0042] 该第一实施例在以下方面不符合3GPP TS 33. 220技术规范。第一实施例与3GPP TS 33. 220的条款4. 5. 2的不同之处在于:该实施例中的⑶SS包括针对特定NAF而允许该 UE使用的FQDN的集合,而条款4. 5. 2中公开的⑶SS不包括FQDN的集合。第一实施例与条 款4. 5. 3的不同之处在于:第一实施例的NAF不确定、验证或发送NAF_ID,而条款4. 5. 3中 公开的NAF被布置为执行这些步骤。与3GPP TS 33. 220技术规范相比较而言,简化了 NAF 节点的布置和管理。
[0043] 图7示出了第二实施例,图7是示出了在BSF处用于产生认证答复的方法步骤的 流程图。在第二实施例中,NAF仍向BSF发送包括NAF_ID的对密钥材料的请求,并且BSF接 收(S7. 1)所述请求。BSF从HSS获得订户信息(S7. 2)。基于从HSS获得的订户信息,BSF 通过将从NAF接收到的FQDN与从HSS随着订户信息获得的FQDN进行比较(S7. 3),来验证 NAF_ID。如果接收到的FQDN与订户信息中针对NAF所列的多个FQDN之一相匹配,则验证 了 NAF_ID。步骤S7. 4和步骤S7. 5与图5的步骤S5. 3和S5. 4相同。将验证NAF_ID的作 用从NAF移到BSF,从而减少了 NAF节点的管理负担。
[0044] 图8更详细地示出了第二实施例。步骤8. 1)到8. 3)与第一实施例的步骤6. 1) 到6. 3相同。在步骤8. 4中,NAF在认证请求中向BSF转发NAF_ID (图8示出为NAF_ID)。 当接收到认证请求时,BSF使用B-TID识别该Ks。BSF还通过考虑是否将FQDN提供在⑶SS 中,来确定是否授权用户使用该NAF_ID (即,BSF验证该NAF_ID),其中所接收到的NAF_ID 是基于所述FQDN的。如果将接收到的NAF_ID所基于的FQDN提供在⑶SS中,则验证了该 NAF_ID。如果接收到的NAF_ID所基于的FQDN与提供在⑶SS中的FQDN不匹配,则没有验 证NAF_ID,BSF将在对NAF的回复中对此加以指示,然后NAF将向UE发送自举重新协商请 求。在BSF处对NAF_ID进行验证之后,其余步骤(8. 5、8.6和8. 7)与第一实施例中的步骤 (6. 5、6· 6 和 6. 7)相同。
[0045] 当允许单个UE使用不同FQDN访问NAF时,可以使用第二实施例。例如,运营商可 以具有在两个不同的FQDN下可用但使用相同NAF的两个服务。
[0046] 第二实施例比第一实施例需要改变更少的规范。然而,第二实施例在以下方面不 符合3GPP TS 33. 220技术规范。第二实施例与3GPP TS 33. 220的条款4. 5. 2的不同之 处在于:该实施例的GUSS包括允许所述UE使用的FQDN的集合,而条款4. 5. 2中所公开的 ⑶SS不包括FQDN的集合。第二实施例与条款4. 5. 3的不同之处在于:第二实施例的NAFf 验证NAF_ID,而条款4. 5. 3所公开的NAF被布置为验证该NAF_ID。与3GPP TS 33. 220技 术规范相比较而言,简化了 NAF节点的布置和管理。
[0047] 表格1示出了示例的GUSS,示出了可以如何包括应用专用信息并将应用专用 信息包括在何处。在该特定实施例中,存在与用户相关联的两个NAF标识 :〇penid-naf. operator, com和kms. operator, com。当用户联系这些NAF标识之一时,仅允许他使用在表 格1中在对应NAF标识下列出的多个NAF标识符(在这种情况下,NAF_ID)之一。作为背 景,表格1所不的NAF_ID是基于64位编码的。
[0048] 表格 1 中的 NAF 标识 openid-naf. operator. com 和 kms. operator, com 是独立于 NAF标识符(NAF_ID)的本地NAF标识。本地NAF标识可以识别在BSF处的特定NAF,而不 识别在NAF和UE之间的对应参考点Ua。如果本地NAF标识不识别Ua参考点,则本地NAF 标识还不包括Ua安全性协议标识符PR0T0_ID。通常,NAF已具有本地NAF标识。例如,如 果Zn参考点的安全性是基于Diameter协议的,则本地NAF标识应是在Diameter请求的 Origin-Host字段内的FQDN。备选地,安全性可以是基于互联网协议安全性(IPSEC)协议 或TLS协议的,在这种情况下本地NAF标识应是在这些协议中使用的标识符。
[0049] 表格中以〈nafList〉开始并以〈/nafList〉结束的示例⑶SS的部分是与特定用户 或用户群的数据相关的部分。NAF_ID "GNhcbGVhc3VyZS4"是为导出密钥而使用的NAF_ID。 如结合第二实施例所述,两个NAF_ID "Npb24dGhlci"和"GNhcmhc3VyZS4"是用于识别单个 NAF (实体)kms-naf. operator, com 的多个 NAF_ID 的不例。
[0050] 可以使用多个FQDN的模型的示例是软件即服务(SaaS)云模型。例如,如果电信 运营商希望向若干公司的用户提供密钥管理服务(KMS),则它可以在多个FQDN下提供KMS 服务。来自公司A的用户可以使用在名称为kms. companyA. com下的服务,来自公司B的用 户可以使用在名称为kms. companyB. com的服务。SaaS商业模型的另一示例是公司Z从单 个NAF提供两个服务(free. compZ. com和registered. compZ. com)。上述实施例通过将确 定和/或验证NAF_ID的步骤移至BSF,来减小NAF节点的管理负担。
[0051] 上述实施例的另一优点涉及控制用户对服务的访问程度。例如,在多媒体广播多 播服务中,存在提供不同类型内容服务的若干广播多播服务中心(即,若干NAF),运营商可 能希望根据用户的订阅(例如,铜牌、银牌或金牌订阅)来限制用户对不同类型内容的访 问。可以通过仅将特定集合的广播-多播服务中心(即,NAF)包括在用户的⑶SS中,来实 现这种类型的内容访问控制。如果需要更精细程度的访问控制,则可以将附加授权信息包 括在所述⑶SS中。
[0052] 表格 1
[0053] <guss id="358500004836551 (f/)ims.mnc050.mcc358.3gppnetvvork.org"> <bsfInfo> < I i fe ? i m e>86400<71 i fe Time> </bsfInfo> <ussL.ist> <uss id="l" type="l" nafGroup="A"> <iiicls> <uid>lcl:35850483655 1 </uid> < ui cl> 1 a uri. I ai t i ncn @opcralor. com</uid> </u.ids> <flags> <(lag> 1 </(lag> </uss> </ussList> <nalList> <nai' i d=opcn i d-na f. opcrat or. coin > <nafids> <nafid>G NhcbG Vhc3 VyZS4=</nafid> <nafids> </naf> <naf id=km s-naf. operator. com> <nafids> <n afi d> N pb 2 4 dG h 1 c i </n afi d> <nafid>GNhcmhc3 VyZS4=</nafid>
[0054] <nafids> </naf> </nafList> <7guss>
【权利要求】
1. 一种在通用自举架构GBA中授权订户用户设备访问网络应用功能NAF的方法,所述 方法包括在自举服务器功能BSF处: 从NAF接收(S3. 1)对订户用户设备的密钥材料的请求,其中所述NAF与一个或多个 NAF标识符相关联; 从归属订户系统HSS获得(S3. 2)订户信息,所述信息包括对订户有效的一个或多个 NAF标识符; 根据所述NAF的标识和包括在订户信息中的NAF标识符,授权订户用户设备; 在授权订户用户设备的情况下,使用包含在所述订户信息中的NAF标识符来导出 (S3. 3)密钥材料;以及 向所述NAF发送(S3. 4)所述密钥材料。
2. 根据权利要求1所述的方法,其中所述请求包括NAF标识符,并且所述授权步骤包 括:将包含在所述请求中的NAF标识符与包括在所述订户信息中的NAF标识符相匹配。
3. 根据权利要求1所述的方法,其中所述从NAF接收到的请求不包含NAF标识符。
4. 根据权利要求1到3中的任一权利要求所述的方法,其中所述订户信息包括GBA用 户安全设置⑶SS。
5. 根据上述权利要求中的任一权利要求所述的方法,其中使用完全限定域名FQDN来 构造 NAF标识符。
6. -种被配置为操作作为自举服务器功能BSF的装置,用在通用自举架构GBA中,所述 装置包括: 第一接收器(2),用于从网络应用功能NAF接收对订户用户设备的密钥材料的请求,其 中所述NAF与一个或多个NAF标识符相关联; 第二接收器(3),用于从归属订户系统HSS接收订户信息,所述信息包括对订户有效的 一个或多个NAF标识符; 第一处理器(4),用于根据所述NAF的标识和包括在订户信息中的NAF标识符,授权订 户用户设备; 第二处理器(5),布置为在授权订户用户设备的情况下,使用包含在所述订户信息中的 NAF标识符来导出密钥材料; 发送器(6),用于向所述NAF发送所述密钥材料。
7. 根据权利要求6所述的装置,其中所述请求包括NAF标识符,所述第一处理器(4)还 被布置为:将包含在所述请求中的NAF标识符与包括在所述订户信息中的NAF标识符相匹 配。
8. 根据权利要求6或7所述的装置,其中所述订户相关信息包括GBA用户安全设置 ⑶SS。
9. 根据权利要求6到8中的任一权利要求所述的装置,其中使用完全限定域名FQDN来 构造 NAF标识符。
10. -种在通用自举架构GBA中授权订户用户设备访问网络应用功能NAF的方法,所述 方法包括: 在订户用户设备处,向NAF发送请求,其中所述NAF与一个或多个NAF标识符相关联; 在NAF处接收所述请求; 在NAF处,向自举服务器功能BSF发送认证请求; 在BSF(l)处接收(S3. 1)所述认证请求; 在BSF(l)处,从归属订户系统HSS获得(S3. 2)订户信息,所述信息包括对订户有效的 一个或多个NAF标识符; 在BSF (1)处,根据所述NAF的标识和包括在订户信息中的NAF标识符,来授权订户用 户设备; 在授权订户用户设备的情况下,使用包含在所述订户信息中的NAF标识符来导出 (S3. 3)密钥材料; 向所述NAF发送(S3. 4)所述密钥材料;以及 在所述NAF处接收所述密钥材料。
11. 根据权利要求10所述的方法,还包括: 在用户设备处,从BSF(l)获得临时标识符B-TID以及主密钥,并将B-TID包括在所述 向NAF发送的请求中;以及 在BSF(l)处,使用B-TID识别在订户信息中的正确NAF标识符。
12. 根据权利要求11所述的方法,其中所述认证请求包括NAF标识符,且所述授权步骤 包括:在BSF处,将包含在所述请求中的NAF标识符与包括在所述订户信息中的NAF标识符 相匹配。
13. 根据权利要求11所述的方法,其中所述NAF发送的认证请求不包含NAF标识符。
14. 根据权利要求10到13中的任一权利要求所述的方法,其中所述订户相关信息包括 GBA用户安全设置⑶SS。
15. 根据权利要求10到14中的任一权利要求所述的方法,其中使用完全限定域名 FQDN来构造 NAF标识符。
16. -种包括计算机可读代码的计算机程序,当在装置上运行所述计算机可读代码时, 使得所述装置用作根据权利要求6到9中的任意权利要求所述的装置。
17. -种包括计算机可读介质和计算机程序的计算机程序产品,其中所述计算机程序 包括计算机可读代码,当在装置上运行所述计算机可读代码时,使得所述装置用作根据权 利要求6到9中的任意权利要求所述的装置,并且其中,所述计算机程序存储在所述计算机 可读介质上。
【文档编号】H04W12/08GK104247485SQ201280072667
【公开日】2014年12月24日 申请日期:2012年4月26日 优先权日:2012年4月26日
【发明者】普拉耶沃·库马·纳卡米, 奥斯卡·奥尔松 申请人:瑞典爱立信有限公司

最新回复(0)