YD/T 2922-2015
基本信息
标准号： YD/T 2922-2015
中文名称：数字蜂窝移动通信网通用认证架构通用自启动架构推送功能及推送层协议
标准类别：通信行业标准(YD)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：43741041
相关标签： 数字 蜂窝 移动 通信网 通用 认证 架构 推送 功能 协议
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 2922-2015.Digital cellular mobile communication network Generic authentication architecture Generic bootstrapping architecture push function and push layer.
1范围
YD/T 2922定义了一种建立在通用认证架构(GAA). 上的通用 自启动架构推送功能(GBA Push)，主要包括GBA推送架构、GBA推送功能。本标准还相应定义了一种实现GBA推送功能的推送层协议(GPL)。GPL标准内容包括消息格式、加密套组、处理模型，并假设密钥及其他安全协商(SA)参数以NAF SA的形式预配置在Push-NAF和UE中。GPL是一种可以用于单向保护的安全协议。GPL基本原理是，如果要求每个应用定义独自的安全机制，这明显会导致重复性的工作、标准化、及具体实现，而使用通用安全推送层GPL可以很好地解决这些问题。此外，GPL还可以使应用避免去了解安全层的内部工作原理。
YD/T 2922适用于应用层业务，例如手机电视(MBMS)、安全定位服务(SUPL) 等，为其提供统一的安全认证服务以及通信密钥协商服务，以保证应用业务的安全性。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
ISO/IEC 10118-3:2004 信 息技术-安全技术-散列函数-第三部分:专用散列函数(Information Technology - Security techniques-Hash-functions-Part 3: Dedicated hassh-functions)
3GPP TR 21.9053GPP标准词汇表 (Vocabulary for 3GPP Specifications)
1范围
YD/T 2922定义了一种建立在通用认证架构(GAA). 上的通用 自启动架构推送功能(GBA Push)，主要包括GBA推送架构、GBA推送功能。本标准还相应定义了一种实现GBA推送功能的推送层协议(GPL)。GPL标准内容包括消息格式、加密套组、处理模型，并假设密钥及其他安全协商(SA)参数以NAF SA的形式预配置在Push-NAF和UE中。GPL是一种可以用于单向保护的安全协议。GPL基本原理是，如果要求每个应用定义独自的安全机制，这明显会导致重复性的工作、标准化、及具体实现，而使用通用安全推送层GPL可以很好地解决这些问题。此外，GPL还可以使应用避免去了解安全层的内部工作原理。
YD/T 2922适用于应用层业务，例如手机电视(MBMS)、安全定位服务(SUPL) 等，为其提供统一的安全认证服务以及通信密钥协商服务，以保证应用业务的安全性。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
ISO/IEC 10118-3:2004 信 息技术-安全技术-散列函数-第三部分:专用散列函数(Information Technology - Security techniques-Hash-functions-Part 3: Dedicated hassh-functions)
3GPP TR 21.9053GPP标准词汇表 (Vocabulary for 3GPP Specifications)
标准图片预览
标准内容
ICS33.060.01
中华人民共和国通信行业标准
YD/T2922-2015
数字蜂窝移动通信网通用认证架构通用自启动架构推送功能及推送层协议DigitalcellularmobilecommunicationnetworkGeneric authentication architecture-Generic bootstrappingarchitecturepushfunctionandpushlayer(3GPPTS33.223V10.0.0,GenericAuthenticationArchitecture(GAA);GenericBootstrappingArchitecture(GBA)Pushfunction,3GPPTS33.224V10.0.0,GenericAuthenticationArchitecture(GAA);GenericBootstrappingArchitecture(GBA)PushLayer,MO)
2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
范围·
2规范性引用文件。
3符号和缩略语
3.1符号·
3.2缩略语
4GBA要求·
4.1GBA概述·
GBA架构·
5GBAPush架构及要求·
GBAPush架构·
GBA Push的要求·
GPL的要求
GBAPush功能
GBAPush消息流程及处理
数据对象
GPI完整性保护及机密性保护。
使用NAFSA的流程
GPL处理功能*
处理模型
会话开始·
会话终止
GPL安全协商·
联合传输
消息格式·
接收处理
外发处理
7.9GPL-SA初始化
7.10加密套组
附录A（资料性附录）选择Disposable-Ks模型的原因.附录B（规范性附录）GBA-Push的UE注册流程附录C（资料性附录）GPL使用场景·...次
附录D（资料性附录）本标准与3GPPTS33.223和3GPPTS33.224章节对应关系YD/T2922-2015
YD/T2922-2015
本标准按照GB/T1.1-2009给出的规则起草。本标准使用重新起草法修改采用3GPPTS33.223V10.0.0《通用认证架构；通用自启动架构推送功能》和3GPPTS33.224V10.0.0《通用认证架构；通用自启动架构推送层协议》，技术内容一致，附录D中列出了本标准与3GPPTS33.223和3GPPTS33.224的章条编号对照表。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会归口。本标准起草单位：华为技术有限公司、中国信息通信研究院、上海贝尔股份有限公司、中国联合网络通信集团有限公司、中兴通讯股份有限公司、摩托罗拉（北京）移动技术有限公司。本标准主要起草人：应江威、许怡娴、崔洋、袁琦、胡志远、高枫、李阳。II
1范围
数字蜂窝移动通信网
通用认证架构
通用自启动架构推送功能及推送层协议YD/T2922-2015
本标准定义了一种建立在通用认证架构（GAA）上的通用自启动架构推送功能（GBAPush），主要包括GBA推送架构、GBA推送功能。本标准还相应定义了一种实现GBA推送功能的推送层协议（GPL）。GPL标准内容包括消息格式、加密套组、处理模型，并假设密钥及其他安全协商（SA）参数以NAFSA的形式预配置在Push-NAF和UE中。GPL是一种可以用于单向保护的安全协议。GPL基本原理是，如果要求每个应用定义独自的安全机制，这明显会导致重复性的工作、标准化、及具体实现，而使用通用安全推送层GPL可以很好地解决这些问题。此外，GPL还可以使应用避免去了解安全层的内部工作原理。本标准适用于应用层业务，例如手机电视（MBMS）安全定位服务（SUPL）等，为其提供统一的安全认证服务以及通信密钥协商服务，以保证应用业务的安全性。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。ISO/IEC10118-3:2004信息技术-安全技术-散列函数-第三部分：专用散列函数（InformationTechnology-Security techniques-Hash-functions-Part 3: Dedicated hash-functions)3GPPTR21.9053GPP标准词汇表（Vocabularyfor3GPPSpecifications）3GPPTS29.109通用认证架构：基于Diameter协议的Zh和Zn接口：阶段3（GenericAuthenticationArchitecture (GAA); Zh and Zn Interfaces based on the Diameter protocol; Stage 3)3GPPTS31.101UICC终端接口；物理和逻辑特性（UICC-terminal interface;Physical andlogicalcharacteristics
3GPPTS31.111通用用户身份识别模块的应用工具包（UniversalSubscriberIdentityModule（USIM）ApplicationToolkit(USAT))
3GPPTS33.1023G安全的安全架构（3GSecurity；Securityarchitecture）3GPPTS33.2103G安全的网络域安全中的IP网络层安全（3GSecurity;NetworkDomainSecurity；IPnetworklayersecurity)
3GPPTS33.220通用认证架构：通用自启动架构（GenericAuthenticationArchitecture（GAA）;Genericbootstrappingarchitecture）
3GPPTS33.222通用认证架构：使用超文本接入网络应用功能：传输协议位于TLS传输层安全上CAccess to network application functions using Hypertext Transfer Protocol over Transport Layer SecurityHTTPS）
ETSITS102483UICC终端接口：UICC和终端之间的互联网协议连通性（UICC-Terminalinterface;Internet Protocol connectivity between UICC and terminal)1
YD/T2922-2015
ETSITS102600UICC终端接口：USB接口特性（UICC-TerminalinterfaceCharacteristicsof theUSBinterface)
FIPSPUB180-2（2002）安全散列标准（SecureHashStandard）FIPSPUB197高级加密标准（AdvancedEncryptionStandard）IETFRFC2104（1997）HMAC：用于消息认证的加密散列法（HMAC：Keyed-HashingforMessageAuthentication)
IETFRFC2246（1999）TLS协议版本1（TheTLSProtocolVersion1）IETFRFC4330用于IPv4、IPv6和OSI的简单网络时间协议SNTP的第4版本（SimpleNetworkTimeProtocol (SNTP)Version4forIPv4,IPv6andOSI)NISTSpecialPublication800-38A分组块加密操作模式的推荐（Recommendationfor BlockCiphenModesofOperation)
NISTSpecialPublication800-38A（2001）分组块加密操作模式的推荐-方法和技术（RecommendationforBlock CipherModes ofOperation-Methods andTechniques)OMA-WAP-TS-WSP-V1_0-20020920-C无线会话协议1.0版（WirelessSessionProtocol1.0）3符号和缩略语
3.1符号
3GPPTR21.905和3GPPTS33.220界定的和下列符号适用于本文件。AUTN（*）：GBA上下文中，GBAME根据AUTN值来验证认证向量来自于一个被授权的网络，而GBA_U根据AUTN*值来进行对网络的认证，具体描述参考文献3GPPTS33.220。AUTN（*）用来指示AUTN和AUTN*。
Disposable-Ks模型：用于GBA-push的密钥生成模型。每个Ks只能用于生成一个NAF-key，并且Ks不能重复使用。
GBA_UawareUICC：支持GBAU的UICC卡，GBAU代表Ks不能离开UICC卡。GBA-Push-Info：GBA-Push-Info包含GBA-Push中用于密钥生成的相关数据，其通过Upa参考点从NAF发送到UE。
NAFId：NAF的FQDN，与Ua安全协议标识相连接。NAF-key：NAF-key由Ks获取，可以用来指示Ks（int/ext）NAF或者KsNAF。NAFSA：NAF和UE之间基于NAF-key的安全协商。Push-message：通过Ua参考点从NAF发送给UE的消息，该消息使用了从Upa参考点自启动过程中获取的GBA密钥。
Push-NAF：被授权使用GBA-Push的NAF。UE_TrP：用于将GPI传递给UE的传输地址SNh：拥有有效MAC值的GPL消息中的最大序列号，用于重放保护。SN s：用于产生发出消息序列号的计数器。3.2缩略语
3GPPTR21.905列出的和下列的缩略语适用于本文件。BSF
Bootstrapping ServerFunction自启动服务器功能
GBA_ME
GPLMEME中的GPL
GPL_UUICC中GPL
Ks_int_NAF
Ks_extNAF
4GBA要求
GBA概述
Bootstrapping Transaction IdentifierFullyQualified Domain Name
Generic Authentication ArchitectureGenericBootstrappingArchitectureME-basedGBA
GBAwithUICC-basedenhancementsGBAPushInfo
Generic Push Layer
GPL hosted in the ME
GPLhosted in theUICC
GBA User Security Settings
Home Location Register
High Speed Protocol
Home Subscriber Server
Key Derivation FunctionbZxz.net
NAF-keyinGBA_MEmode
UICC internal NAF-key in GBA_UUICC external NAF-key in GBA UMessage Authentication Code
MobileEquipment
NetworkApplicationFunction
Push Temporary Identifier
Security Association
Security Association IdentifierSequence Number
UserEquipment
User Security Setting
自启动传输标识
正式域名
通用认证架构
通用自启动架构
基于ME的GBA
YD/T2922-2015
基于UICC增强的GBA
GBA推送信息
通用推送层
GBA用户安全设置
归属位置寄存器
高速协议
归属用户服务器
密钥获取功能
GBA_ME模式下的NAF-key
GBA_U下的UICC内部NAF-key
GBA_U下的UICC外部NAF-key
消息验证码
移动设备
网络应用功能
推送临时标识
安全协商
安全协商标识
序列号
用户设备
用户安全设置
GBAPush是在GBA安全机制基础之上提出的，而且GBAPush中的很多的定义、流程、及密钥推演都是基于GBA。GBA是一种为UE和网络侧NAF服务器之间建立共享秘密Ks而提出的，并基于3GPPAKA的通用密钥协商机制。
AKA是移动网络所用的一个非常有用的机制，而GBA重用AKA机制来建立应用层安全。GBA引入了一个新的网元BSF，该BSF与HSS之间有一个接口Zh。UE和HSS通过BSF来运行AKA，根据运行AKA获得的结果（CK，IK），在BSF和UE之间协商产生一个共享密钥Ks，UE同时根据Ks推演KsNAF。当EU和NAF需要建立连接时，应用服务器NAF能从BSF获得从Ks推演得到的会话密钥Ks-NAF和签约用户信息。通过这种方式，NAF和UE就能拥有一个共享密钥YD/T2922-2015
KsNAF，该共享密钥能为随后的应用提供安全保护，特别是在应用会话开始时认证UE和NAF。UE和BSF之间的通信、NAF和BSF之间的通信、BSF和HSS之间的通信独立于应用。4.2GBA架构
GBA网络架构如图1所示。
图1GBA网络模型
图1显示了GBA网络实体模型和他们之间的参考点，这些实体将包含在UE与网络侧之间进行的通用自启动过程中。
GBA安全过程主要由初始化、自启动安全协商、安全协商的使用三部分组成。初始化过程是一个UE和NAF通过Ua口协商是否需要使用GBA的过程。UE要与NAF进行通信，但是UE不知道NAF是否需要通过GBA方式产生的共享密钥，因此双方首先需要协商是否使用GBA方式来建立应用层安全连接。
自启动安全协商过程是UE与网络侧BSF之间通过Ub口进行安全认证和协商共享密钥Ks的过程。如果UE上存在有效的身份信息TMPLB-TID，则向BSF发送携带用户身份信息TMPI/B-TID的请求，BSF根据域名识别TMPI/B-TID并查询数据库判断本地是否存在该TMPI/B-TID，如果存在则提取对应的用户身份标识IMSI/IMPI并据此从用户归属网络服务器HSS中获取AV，否则BSF应要求用户发送包含用户身份标识IMSIIMPI的鉴权请求。然后UE和BSF基于AKA完成认证和密钥IK，CK的协商。最后通过串连CK，IK来生成共享密钥Ks，UE同时生成Ks_NAF。NAFSA安全协商的使用过程是UE与网络应用实体NAF之间协商共享密钥KsNAF的过程。在UE通过Ua口向NAF发起基于GBA的应用请求后，NAF通过Zn口向BSF请求KsNAF，BSF查找与该UE和NAF相关的Ks，然后根据Ks生成KsNAF并将其返回给NAF。此时，UE和NAF就已经共享了密钥KsNAF。一旦完成上述三个GBA自启动安全协商流程，就达到了GBA自启动安全协商的目的，能够实现UE和NAF在Ua口上的安全通信。
5GBAPush架构及要求
5.1介绍
5.1.1综述
GBA-Push是一种自启动NAF和UE间安全的机制，不强制UE联系BSF来发起自启动过程。GBA-Push与3GPPTS33.220中的GBA紧密相关并且基于GBA。GBA-Push针对GBAU和GBA_ME两种使用场景。4
5.1.2GBA-Push系统概述
YD/T2922-2015
基于GBA-Push系统的解决方案及其特性，本节的系统概述对该总体思路进行了大概描述。一般的使用场景是NAF发起建立共享安全协商（SA），即在NAF和UE之间建立一个NAFSA。NAF向UE推送GBA-Push-Info（GPI）信息，用于建立NAFSA。NAFSA中使用的是NAF-key，根据3GPPTS33.220中GBA定义的方法生成，而GPI由NAF从BSF请求获取。在NAFSA建立后，NAF就能发送受保护的推送消息给UE。如果存在由Ua口应用所定义的返回通道则UE也可以用SA保护返回给NAF的回复消息。如何使用NAFSA不在本规范研究范围内。NAFSA由上行、下行SA标识符来指示。
GBA-Push针对GBA_U和GBA_ME两种场景。如果只是用GBA-Push建立一个外部NAF-key，则应使用GBA_Push。基于GBA_U的GBA-Push会同时建立内部NAF-key和外部NAF-key。GBA-Push使用Disposable-Ks（Ks用完就可以丢弃）模型。该模型中的Ks只能使用一次来获取一组NAF-keys（以及用于保护GPI信息传递的其他密钥材料）。获取NAF-key之后，清除Ks或拒绝Ks的后续使用。当当前NAF或其他NAF需要新的NAF-keys时，则需要进行新的GBA-Push操作。注l：生成的NAF-key能用来保护NAF发送给UE的多条推送信息。不同NAFs的NAF-keys可以共存。使用Disposable-Ks模型，则根3GPPTS33.220或GBA-Push所建立的NAF-keys不会受到影响。基于GBA_ME的GBA-Push不会与GBA_U交互，但是基于GBA_U的GBAPush会无效UICC中的Ks。注2：3GPPTS33.220指明当执行了新的GBA_UKs生成流程，则UICC中现有的Ks将被覆盖。GBA-Push之后，ME马上发起新的自启动流程，以防止延时和同步问题，没有定文将GPI从NAF传递给UE的传递方法。注3：可能的传递方法有SMS、MMS，SIPMESSAGE、UDP广播。为了将GPI传递给UES，NAF需要知道对应于已选传递方法所应使用的消息传递地址。SMS和MMS的传递地址为MSISDN，SIPMESSAGE的传递地址为IMPU，UDP使用的是UDPport-IP-address配对，而广播传递方法的传递地址是和UE相关的公共标识或NAF和UE之间协商的标志。重发消息是一种用来获取在不可靠信道上（SMS或广播）传输可靠性的标准方法。因此，GBA-Push应允许GPI多次重传，并且可能会出现在每条推送给UE的负载里都包含GPI的情况。由GPI定义的NAFSA是基于特殊UICC（USIM/ISIM）应用的使用。有时传递方法/地址指示UE使用哪个UICC应用，而在某些场景下传递方法/地址需要明确地发送给UE。如果MSISDN用作传输地址，则使用与MSISDN相关的USIM。因为只有UE中的与MSISDN相关的USIM处于激活状态，SMS才能到达UE当IMPU用作目的地址，则使用相应的ISIM。对于UDP和广播，使用的USIM/ISIM应用需要在GPI中指示或者在其他频率信道协商一致。为了保护用户隐私，GPI部分信息需要进行机密性保护，特别是使用广播传输时的NAF标识。对于NAF到UE和UE到NAF消息之间的上行能力，UE到NAF安全的单独SA标识需要由NAF分配并且要包含在GPI受机密性保护的部分中。为了帮助防正DoS攻击产生的严重影响并且阻止有些NAF温用GBA-Push，需要对GPI进行完整性保护。由于GPI的完整性保护可以检测传输错误，因此这也可以防止UE接受不正确的GBAPush安全协商。由GPI定义的Ks密钥来获取用于机密性保护和完整性保护的密钥。5.2GBAPush架构
5.2.1技术说明及基本原理
GBAPush功能是建立在3GPPTS33.220所提供的安全架构和功能之上的，与3GPPTS33.220最主要的5
YD/T2922-2015
区别是在BSF和NAF、NAF和UE之间定义了新的参考点，如图2所示，该图由3GPPTS33.220的图4.1修改得到。
图2通过NAF完成推送自启动过程的网络模型图2所示的GBAPush架构基于以下基本原理：Ja
不能影响Ua参考点的安全保护，例如：不管用于安全保护的GBA密钥是UE发起的还是NAF推动过程发起的，都不应改变Ua参考点协议。一从BSF的角度看，NAF还是密钥获取的发起实体，然而这是在NAF没有B-TID的场景下而UE可能拥有一个有效的GBA会话）。基于3GPPTS33.220定义的Zn参考点协议，引入了新参考点Zpn。在NAF和UE之间引入了新的参考点Upa，通过Upa的所有消息都是由网络侧发起的。Upa定义了GBA推送消息。
一NAF通过Zpn参考点接收来自BSF的GBA推送消息，并将其通过Upa参考点发送给UE。5.2.2GBA-Push密钥生成模型
Disposable-Ks模型是应用于GBA-Push中的密钥模型。在该模型中，Ks只能被使用一次来生成一套单独的NAF-keys以及其他一些用来保护GPI传输的密钥材料，见6.3。获取NAF-key后，清除Ks或者不能再使用Ks，这意味着将没有建立好的可用Ks。如果只是想用GBA-Push建立一个外部NAF-key，那么应总是使用GBAME，这个功能不要求UICC支持GBAU。基于GBAU的GBA-Push不仅会协商一个内部NAF-key，还会协商一个外部NAF-key，3GPPTS33.220定义了NAF-keys的获取方式。在基于GBAME的GBA-Push自启动安全协商中，根据3GPPTS33.220生成的Ks不会受到影响。在基于GBAU的GBA-Push自启动安全协商中，根据3GPPTS33.220生成的GBAUKs将会无效。如果在基于GBAU的GBA-Push安全协商后有应用要求使用GBAUNAF-keys，则需要进行一次通用GBA来建立新的GBA_UKs。但是，该应用可以继续使用从该无效的Ks中获取的NAF-keyS，例如，原来已经使用NAF-keys的应用不会受到GBA-Push自启动安全协商的影响。GBA-Push只支持生成在UE和NAF之间共享的NAF SAS，NAFSA包括NAF-key、密钥生命周期、以及其他一些信息，它们在6.2.3小节中定义。5.3GBAPush的要求
5.3.1GBAPush的基本要求
以下这些基本要求应用于GBAPush：6
一网络实体Push-NAF应能够安全地触发建立其与UE之间的NAFSA。在触发NAFSA的生成时，Push-NAF应能够使用存在消息延时的传输通道。一Push-NAF应能够在发给BSF的请求消息中使用指示UE的公共标识。一如果GBAPush使用了公共标识，则公共标识应对应一个唯一的私有标识。YD/T2922-2015
一当只需要基于ME的NAF-keys时，例如，Ks在ME中建立，则应使用基于ME的GBAPush。当UE拥有支持GBA的UICC卡（GBAU），并且需要基于UICC和ME的NAF-keys或者需要只需要基于UICC的NAF-keys，例如，Ks在UICC中建立，则应使用基于UICC的GBAPush。一一从Push-NAF推送给UE消息的接收，触发了UE中NAF SA的生成。一UE不应需要联系网络实体才能正确生成NAFSA。一不管GBA自启动安全协商是通过Ub还是Upa参考点，UE和NAF应能够独立地在Ua参考点上使用NAF-keys。
注：当使用GBA-Push机制来创建UE和NAF之间的NAFSA时，不局限NAF将获取的安全协商只应用于网络侧发起的协议：同样，当使用UE发起的GBA时，不局限NAF将获取的安全协商只应用于UE发起的协议（Ua参考点）。一一为了避免预配置密钥，保护GPI信息机密性和完整性的密钥生成机制应基于GBA原则。一NAF不能够获取或生成用于保护GPI信息的密钥。5.3.2HSS及HLR的要求
HSS和HLR的要求应符合3GPPTS33.220。5.3.3BSF的要求
除了3GPPTS33.220的4.2.1小节中的BSF要求，还存在以下要求：BSF应能够查找到与公共标识所对应的私有标识。一一BSF应能多根据私有标识查找到对应的Ks。一BSF应能够根据新的Ks生成GPI。一一BSF应对GPI进行完整性保护。一BSF应对GPI中特定域进行机密性保护，需要机密性保护的域在6.2.1小节中介绍。5.3.4UE的要求
除了3GPPTS33.220的4.2.4小节中的UE要求，还存在以下要求：一UE应能够存储并处理NAFSAS。一一本标准中的ME也应实现3GPPTS33.220中所定义的GBA_U和GBA_ME。一UE可能执行一种认证授权机制来认证接收到的GBAPush消息注：GBAPush消息认证授权机制可以基于Push-NAFs的FQDN名所对应的白或黑名单列表。5.3.5参考点Upa的要求
参考点Upa的要求：
一UE应能够基于AKA来验证GPI来自一个被授权BSF。注l：通过Push-NAF可以拥有正确的Ks（ext/int）_NAF，表明BSF已经认证了NAF，这样，Push-NAF就间接地得到了认证。
一UE应能够确定进行自启动安全协商的UICC（USIM/ISIM）应用。一一NAF和UE应能够建立一个共享的NAFSA。YD/T2922-2015
一NAF应能够发送NAFSA标识信息。一BSF应能够将密钥材料的生命周期指示给UE。BSF通过Upa发送的密钥生命周期应指示密钥的过期时间。
注2：Upa参考点的要求是基于3GPPTS33.220中所述的Ub参考点的要求。5.3.6参考点Zh的要求
参考点Zh的要求与3GPPTS33.220中一样。5.3.7参考点Zpn及Zpn'的要求
参考点Zpn的要求：
一应提供互认证、机密性保护、完整性保护。一如果BSF和NAF处于同一个运营商网络，则应用3GPPTS33.210中的NDS/IP来保护基于DIAMETER协议的参考点Zpn
一如果BSF和NAF处于不同的运营商网络，则应根据IETFRFC2246的TLS来保护Zn-Proxy和BSF之间的基于DIAMETER协议的参考点Zpn'。注1：3GPPTS33.220的附录E指定了需要使用TLS特性。一基于Zpn/Zpn参考点的网络服务应用IETFRFC2246中的TLS来保护。注2：：3GPPTS33.220的附录E指定了需要使用TLS特性。注3：该要求根据3GPPTS33.220中的要求修改得到，以使适用于GBAPush。注4：由于UE可能无法验证pNAFPQDN，在网络侧的Zpn-proxy中严格检查pNAFFQDN-name显得十分重要。过于简单地检查pNAFFQDN-name，例如，只验证FQDN的一部分，可能会导致pNAFs滥用pNAFFQDN-name的上升。-BSF应能够将NAF请求的密钥材料发送给NAF。一根据BSF的策略以及NAF通过Zpn的请求消息中指示的应用，NAF应能够从BSF获取一组特定应用的USSs。
-NAF应能向BSF表明其需要申请一个应用还是一些应用的USSS。注5：如果某些应用只需要一个特定应用USS的子集，例如，IMPI，则NAF从来自BSF的完整USS中选择该子集。一BSF一个能够以单个NAF或单个应用的粒度进行配置。一私有用户标识，例如，IMPI，可能发送给NAF。特殊的USS可能发送给NAF。
一如果NAF向BSF请求的USSs不在用户的GUSS中，但只要满足BSF本地策略的条件，则这不应形成错误。BSF应只向NAF发送其所请求的并找到的USSS。可以这样配置本地策略：BSF可能请求一个或多个特定应用的USS，这些USS出现在特殊请求NAF的特殊用户的GUSS中；而如果条件不满足，则BSF拒绝来自NAF的请求。为了满足本地策略，不要求NAF通过Zpn参考点请求USSs信息，这些USSs是BSF要求出现在GUSS中的，更确切地说，BSF本地检查USS的存在性已经足够。也可以这样配置BSF：对于请求NAF，没有要求的USS。注6：更多关于本地策略使用的信息可以查看3GPPTS33.220的附录J。NAF应能够请求NAFSA的生命周期。BSF通过Zpn发送的密钥生命周期应指示密钥的过期时间。
注7：根据NAF的本地策略，这不妨碍NAF在密钥过期时间之前更新NAFSA，8
YD/T2922-2015
注8：如果传递给NAF的一个或多个USSs在HSS中的用户GUSS中发生了更新，则在下一次NAF从BSF请求USS时，BSF将更新的USSs通过Zpn参考点发送给NAF（如果BSF已经通过Zh参考点获取了HSS中更新了的用户GUSS）。5.3.8Zn-Proxy的要求
当PushNAF不在归属网络，则访问NAF应使用NAF网络的Zn-proxy来与用户BSF（归属BSF）交互。Zn-proxy的要求在3GPPTS33.220中描述。5.3.9参考点Ua的要求
参考点Ua的要求见3GPPTS33.220，另外增加以下要求：一应可以在上行方向使用SA标识，这些标识与建立NAFSA所使用的推送消息没有关系。5.3.10NAFSA标识的要求
要求如下：
一下行NAFSA标识应在UE中唯一并且唯一指示一个对应于特定NAFID的NAFSA。一一上行NAFSA标识应在NAF中唯一并且唯一指示一个对应于特定UE和Ua安全协议标识的NAFSA。
5.3.11参考点Dz的要求
该接口位于BSF和SLF之间，用于获取HSS的地址，DZz参考点应和3GPPTS33.220中的一样。该接口不要求处于只存在一个单一HSS的环境。5.4GPL的要求
5.4.1GPL会话的概念
可以预见未来将会出现基于Push-NAF的服务，这些服务依赖于单设备会话的概念，基于同一个安全协商来推送多条消息将带来很多益处。一个很好的例子是病毒签名服务器，病毒签名可能通过多条推送消息来传递（基本推送传递机制的消息尺寸限制原因），如果为每条消息都建立一个新的安全协商，这将会十分低效。
这要求GPL除了提供完整性保护之外（以及可能的机密性保护），还需要提供抗重放保护。图3所示描述了使用场景，其中只使用一个安全协商来将三条推送消息从Push-NAF传递给UE。注意步骤（1）和步骤（2）不属于本标准范围，步骤（1）和步骤（2）见3GPPTS33.222的规定。CUE
密钥根据Ks_NAF
或Ks intNAF获取
的安全关联
(1)UE和BSF之间Ks的建立
(2）Ks_NAF或Ks_intNAF的建立
密钥根据Ks_NAF
或Ks_int_NAF获取
的安全关联
推送消息1
推送消息2
推送消息3
图3安全会话示例
如果GPL用来提供一个完整的会话概念，包括通过超时设定/确认和重传机制、会话的重建、消息的9
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国通信行业标准
YD/T2922-2015
数字蜂窝移动通信网通用认证架构通用自启动架构推送功能及推送层协议DigitalcellularmobilecommunicationnetworkGeneric authentication architecture-Generic bootstrappingarchitecturepushfunctionandpushlayer(3GPPTS33.223V10.0.0,GenericAuthenticationArchitecture(GAA);GenericBootstrappingArchitecture(GBA)Pushfunction,3GPPTS33.224V10.0.0,GenericAuthenticationArchitecture(GAA);GenericBootstrappingArchitecture(GBA)PushLayer,MO)
2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
范围·
2规范性引用文件。
3符号和缩略语
3.1符号·
3.2缩略语
4GBA要求·
4.1GBA概述·
GBA架构·
5GBAPush架构及要求·
GBAPush架构·
GBA Push的要求·
GPL的要求
GBAPush功能
GBAPush消息流程及处理
数据对象
GPI完整性保护及机密性保护。
使用NAFSA的流程
GPL处理功能*
处理模型
会话开始·
会话终止
GPL安全协商·
联合传输
消息格式·
接收处理
外发处理
7.9GPL-SA初始化
7.10加密套组
附录A（资料性附录）选择Disposable-Ks模型的原因.附录B（规范性附录）GBA-Push的UE注册流程附录C（资料性附录）GPL使用场景·...次
附录D（资料性附录）本标准与3GPPTS33.223和3GPPTS33.224章节对应关系YD/T2922-2015
YD/T2922-2015
本标准按照GB/T1.1-2009给出的规则起草。本标准使用重新起草法修改采用3GPPTS33.223V10.0.0《通用认证架构；通用自启动架构推送功能》和3GPPTS33.224V10.0.0《通用认证架构；通用自启动架构推送层协议》，技术内容一致，附录D中列出了本标准与3GPPTS33.223和3GPPTS33.224的章条编号对照表。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会归口。本标准起草单位：华为技术有限公司、中国信息通信研究院、上海贝尔股份有限公司、中国联合网络通信集团有限公司、中兴通讯股份有限公司、摩托罗拉（北京）移动技术有限公司。本标准主要起草人：应江威、许怡娴、崔洋、袁琦、胡志远、高枫、李阳。II
1范围
数字蜂窝移动通信网
通用认证架构
通用自启动架构推送功能及推送层协议YD/T2922-2015
本标准定义了一种建立在通用认证架构（GAA）上的通用自启动架构推送功能（GBAPush），主要包括GBA推送架构、GBA推送功能。本标准还相应定义了一种实现GBA推送功能的推送层协议（GPL）。GPL标准内容包括消息格式、加密套组、处理模型，并假设密钥及其他安全协商（SA）参数以NAFSA的形式预配置在Push-NAF和UE中。GPL是一种可以用于单向保护的安全协议。GPL基本原理是，如果要求每个应用定义独自的安全机制，这明显会导致重复性的工作、标准化、及具体实现，而使用通用安全推送层GPL可以很好地解决这些问题。此外，GPL还可以使应用避免去了解安全层的内部工作原理。本标准适用于应用层业务，例如手机电视（MBMS）安全定位服务（SUPL）等，为其提供统一的安全认证服务以及通信密钥协商服务，以保证应用业务的安全性。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。ISO/IEC10118-3:2004信息技术-安全技术-散列函数-第三部分：专用散列函数（InformationTechnology-Security techniques-Hash-functions-Part 3: Dedicated hash-functions)3GPPTR21.9053GPP标准词汇表（Vocabularyfor3GPPSpecifications）3GPPTS29.109通用认证架构：基于Diameter协议的Zh和Zn接口：阶段3（GenericAuthenticationArchitecture (GAA); Zh and Zn Interfaces based on the Diameter protocol; Stage 3)3GPPTS31.101UICC终端接口；物理和逻辑特性（UICC-terminal interface;Physical andlogicalcharacteristics
3GPPTS31.111通用用户身份识别模块的应用工具包（UniversalSubscriberIdentityModule（USIM）ApplicationToolkit(USAT))
3GPPTS33.1023G安全的安全架构（3GSecurity；Securityarchitecture）3GPPTS33.2103G安全的网络域安全中的IP网络层安全（3GSecurity;NetworkDomainSecurity；IPnetworklayersecurity)
3GPPTS33.220通用认证架构：通用自启动架构（GenericAuthenticationArchitecture（GAA）;Genericbootstrappingarchitecture）
3GPPTS33.222通用认证架构：使用超文本接入网络应用功能：传输协议位于TLS传输层安全上CAccess to network application functions using Hypertext Transfer Protocol over Transport Layer SecurityHTTPS）
ETSITS102483UICC终端接口：UICC和终端之间的互联网协议连通性（UICC-Terminalinterface;Internet Protocol connectivity between UICC and terminal)1
YD/T2922-2015
ETSITS102600UICC终端接口：USB接口特性（UICC-TerminalinterfaceCharacteristicsof theUSBinterface)
FIPSPUB180-2（2002）安全散列标准（SecureHashStandard）FIPSPUB197高级加密标准（AdvancedEncryptionStandard）IETFRFC2104（1997）HMAC：用于消息认证的加密散列法（HMAC：Keyed-HashingforMessageAuthentication)
IETFRFC2246（1999）TLS协议版本1（TheTLSProtocolVersion1）IETFRFC4330用于IPv4、IPv6和OSI的简单网络时间协议SNTP的第4版本（SimpleNetworkTimeProtocol (SNTP)Version4forIPv4,IPv6andOSI)NISTSpecialPublication800-38A分组块加密操作模式的推荐（Recommendationfor BlockCiphenModesofOperation)
NISTSpecialPublication800-38A（2001）分组块加密操作模式的推荐-方法和技术（RecommendationforBlock CipherModes ofOperation-Methods andTechniques)OMA-WAP-TS-WSP-V1_0-20020920-C无线会话协议1.0版（WirelessSessionProtocol1.0）3符号和缩略语
3.1符号
3GPPTR21.905和3GPPTS33.220界定的和下列符号适用于本文件。AUTN（*）：GBA上下文中，GBAME根据AUTN值来验证认证向量来自于一个被授权的网络，而GBA_U根据AUTN*值来进行对网络的认证，具体描述参考文献3GPPTS33.220。AUTN（*）用来指示AUTN和AUTN*。
Disposable-Ks模型：用于GBA-push的密钥生成模型。每个Ks只能用于生成一个NAF-key，并且Ks不能重复使用。
GBA_UawareUICC：支持GBAU的UICC卡，GBAU代表Ks不能离开UICC卡。GBA-Push-Info：GBA-Push-Info包含GBA-Push中用于密钥生成的相关数据，其通过Upa参考点从NAF发送到UE。
NAFId：NAF的FQDN，与Ua安全协议标识相连接。NAF-key：NAF-key由Ks获取，可以用来指示Ks（int/ext）NAF或者KsNAF。NAFSA：NAF和UE之间基于NAF-key的安全协商。Push-message：通过Ua参考点从NAF发送给UE的消息，该消息使用了从Upa参考点自启动过程中获取的GBA密钥。
Push-NAF：被授权使用GBA-Push的NAF。UE_TrP：用于将GPI传递给UE的传输地址SNh：拥有有效MAC值的GPL消息中的最大序列号，用于重放保护。SN s：用于产生发出消息序列号的计数器。3.2缩略语
3GPPTR21.905列出的和下列的缩略语适用于本文件。BSF
Bootstrapping ServerFunction自启动服务器功能
GBA_ME
GPLMEME中的GPL
GPL_UUICC中GPL
Ks_int_NAF
Ks_extNAF
4GBA要求
GBA概述
Bootstrapping Transaction IdentifierFullyQualified Domain Name
Generic Authentication ArchitectureGenericBootstrappingArchitectureME-basedGBA
GBAwithUICC-basedenhancementsGBAPushInfo
Generic Push Layer
GPL hosted in the ME
GPLhosted in theUICC
GBA User Security Settings
Home Location Register
High Speed Protocol
Home Subscriber Server
Key Derivation FunctionbZxz.net
NAF-keyinGBA_MEmode
UICC internal NAF-key in GBA_UUICC external NAF-key in GBA UMessage Authentication Code
MobileEquipment
NetworkApplicationFunction
Push Temporary Identifier
Security Association
Security Association IdentifierSequence Number
UserEquipment
User Security Setting
自启动传输标识
正式域名
通用认证架构
通用自启动架构
基于ME的GBA
YD/T2922-2015
基于UICC增强的GBA
GBA推送信息
通用推送层
GBA用户安全设置
归属位置寄存器
高速协议
归属用户服务器
密钥获取功能
GBA_ME模式下的NAF-key
GBA_U下的UICC内部NAF-key
GBA_U下的UICC外部NAF-key
消息验证码
移动设备
网络应用功能
推送临时标识
安全协商
安全协商标识
序列号
用户设备
用户安全设置
GBAPush是在GBA安全机制基础之上提出的，而且GBAPush中的很多的定义、流程、及密钥推演都是基于GBA。GBA是一种为UE和网络侧NAF服务器之间建立共享秘密Ks而提出的，并基于3GPPAKA的通用密钥协商机制。
AKA是移动网络所用的一个非常有用的机制，而GBA重用AKA机制来建立应用层安全。GBA引入了一个新的网元BSF，该BSF与HSS之间有一个接口Zh。UE和HSS通过BSF来运行AKA，根据运行AKA获得的结果（CK，IK），在BSF和UE之间协商产生一个共享密钥Ks，UE同时根据Ks推演KsNAF。当EU和NAF需要建立连接时，应用服务器NAF能从BSF获得从Ks推演得到的会话密钥Ks-NAF和签约用户信息。通过这种方式，NAF和UE就能拥有一个共享密钥YD/T2922-2015
KsNAF，该共享密钥能为随后的应用提供安全保护，特别是在应用会话开始时认证UE和NAF。UE和BSF之间的通信、NAF和BSF之间的通信、BSF和HSS之间的通信独立于应用。4.2GBA架构
GBA网络架构如图1所示。
图1GBA网络模型
图1显示了GBA网络实体模型和他们之间的参考点，这些实体将包含在UE与网络侧之间进行的通用自启动过程中。
GBA安全过程主要由初始化、自启动安全协商、安全协商的使用三部分组成。初始化过程是一个UE和NAF通过Ua口协商是否需要使用GBA的过程。UE要与NAF进行通信，但是UE不知道NAF是否需要通过GBA方式产生的共享密钥，因此双方首先需要协商是否使用GBA方式来建立应用层安全连接。
自启动安全协商过程是UE与网络侧BSF之间通过Ub口进行安全认证和协商共享密钥Ks的过程。如果UE上存在有效的身份信息TMPLB-TID，则向BSF发送携带用户身份信息TMPI/B-TID的请求，BSF根据域名识别TMPI/B-TID并查询数据库判断本地是否存在该TMPI/B-TID，如果存在则提取对应的用户身份标识IMSI/IMPI并据此从用户归属网络服务器HSS中获取AV，否则BSF应要求用户发送包含用户身份标识IMSIIMPI的鉴权请求。然后UE和BSF基于AKA完成认证和密钥IK，CK的协商。最后通过串连CK，IK来生成共享密钥Ks，UE同时生成Ks_NAF。NAFSA安全协商的使用过程是UE与网络应用实体NAF之间协商共享密钥KsNAF的过程。在UE通过Ua口向NAF发起基于GBA的应用请求后，NAF通过Zn口向BSF请求KsNAF，BSF查找与该UE和NAF相关的Ks，然后根据Ks生成KsNAF并将其返回给NAF。此时，UE和NAF就已经共享了密钥KsNAF。一旦完成上述三个GBA自启动安全协商流程，就达到了GBA自启动安全协商的目的，能够实现UE和NAF在Ua口上的安全通信。
5GBAPush架构及要求
5.1介绍
5.1.1综述
GBA-Push是一种自启动NAF和UE间安全的机制，不强制UE联系BSF来发起自启动过程。GBA-Push与3GPPTS33.220中的GBA紧密相关并且基于GBA。GBA-Push针对GBAU和GBA_ME两种使用场景。4
5.1.2GBA-Push系统概述
YD/T2922-2015
基于GBA-Push系统的解决方案及其特性，本节的系统概述对该总体思路进行了大概描述。一般的使用场景是NAF发起建立共享安全协商（SA），即在NAF和UE之间建立一个NAFSA。NAF向UE推送GBA-Push-Info（GPI）信息，用于建立NAFSA。NAFSA中使用的是NAF-key，根据3GPPTS33.220中GBA定义的方法生成，而GPI由NAF从BSF请求获取。在NAFSA建立后，NAF就能发送受保护的推送消息给UE。如果存在由Ua口应用所定义的返回通道则UE也可以用SA保护返回给NAF的回复消息。如何使用NAFSA不在本规范研究范围内。NAFSA由上行、下行SA标识符来指示。
GBA-Push针对GBA_U和GBA_ME两种场景。如果只是用GBA-Push建立一个外部NAF-key，则应使用GBA_Push。基于GBA_U的GBA-Push会同时建立内部NAF-key和外部NAF-key。GBA-Push使用Disposable-Ks（Ks用完就可以丢弃）模型。该模型中的Ks只能使用一次来获取一组NAF-keys（以及用于保护GPI信息传递的其他密钥材料）。获取NAF-key之后，清除Ks或拒绝Ks的后续使用。当当前NAF或其他NAF需要新的NAF-keys时，则需要进行新的GBA-Push操作。注l：生成的NAF-key能用来保护NAF发送给UE的多条推送信息。不同NAFs的NAF-keys可以共存。使用Disposable-Ks模型，则根3GPPTS33.220或GBA-Push所建立的NAF-keys不会受到影响。基于GBA_ME的GBA-Push不会与GBA_U交互，但是基于GBA_U的GBAPush会无效UICC中的Ks。注2：3GPPTS33.220指明当执行了新的GBA_UKs生成流程，则UICC中现有的Ks将被覆盖。GBA-Push之后，ME马上发起新的自启动流程，以防止延时和同步问题，没有定文将GPI从NAF传递给UE的传递方法。注3：可能的传递方法有SMS、MMS，SIPMESSAGE、UDP广播。为了将GPI传递给UES，NAF需要知道对应于已选传递方法所应使用的消息传递地址。SMS和MMS的传递地址为MSISDN，SIPMESSAGE的传递地址为IMPU，UDP使用的是UDPport-IP-address配对，而广播传递方法的传递地址是和UE相关的公共标识或NAF和UE之间协商的标志。重发消息是一种用来获取在不可靠信道上（SMS或广播）传输可靠性的标准方法。因此，GBA-Push应允许GPI多次重传，并且可能会出现在每条推送给UE的负载里都包含GPI的情况。由GPI定义的NAFSA是基于特殊UICC（USIM/ISIM）应用的使用。有时传递方法/地址指示UE使用哪个UICC应用，而在某些场景下传递方法/地址需要明确地发送给UE。如果MSISDN用作传输地址，则使用与MSISDN相关的USIM。因为只有UE中的与MSISDN相关的USIM处于激活状态，SMS才能到达UE当IMPU用作目的地址，则使用相应的ISIM。对于UDP和广播，使用的USIM/ISIM应用需要在GPI中指示或者在其他频率信道协商一致。为了保护用户隐私，GPI部分信息需要进行机密性保护，特别是使用广播传输时的NAF标识。对于NAF到UE和UE到NAF消息之间的上行能力，UE到NAF安全的单独SA标识需要由NAF分配并且要包含在GPI受机密性保护的部分中。为了帮助防正DoS攻击产生的严重影响并且阻止有些NAF温用GBA-Push，需要对GPI进行完整性保护。由于GPI的完整性保护可以检测传输错误，因此这也可以防止UE接受不正确的GBAPush安全协商。由GPI定义的Ks密钥来获取用于机密性保护和完整性保护的密钥。5.2GBAPush架构
5.2.1技术说明及基本原理
GBAPush功能是建立在3GPPTS33.220所提供的安全架构和功能之上的，与3GPPTS33.220最主要的5
YD/T2922-2015
区别是在BSF和NAF、NAF和UE之间定义了新的参考点，如图2所示，该图由3GPPTS33.220的图4.1修改得到。
图2通过NAF完成推送自启动过程的网络模型图2所示的GBAPush架构基于以下基本原理：Ja
不能影响Ua参考点的安全保护，例如：不管用于安全保护的GBA密钥是UE发起的还是NAF推动过程发起的，都不应改变Ua参考点协议。一从BSF的角度看，NAF还是密钥获取的发起实体，然而这是在NAF没有B-TID的场景下而UE可能拥有一个有效的GBA会话）。基于3GPPTS33.220定义的Zn参考点协议，引入了新参考点Zpn。在NAF和UE之间引入了新的参考点Upa，通过Upa的所有消息都是由网络侧发起的。Upa定义了GBA推送消息。
一NAF通过Zpn参考点接收来自BSF的GBA推送消息，并将其通过Upa参考点发送给UE。5.2.2GBA-Push密钥生成模型
Disposable-Ks模型是应用于GBA-Push中的密钥模型。在该模型中，Ks只能被使用一次来生成一套单独的NAF-keys以及其他一些用来保护GPI传输的密钥材料，见6.3。获取NAF-key后，清除Ks或者不能再使用Ks，这意味着将没有建立好的可用Ks。如果只是想用GBA-Push建立一个外部NAF-key，那么应总是使用GBAME，这个功能不要求UICC支持GBAU。基于GBAU的GBA-Push不仅会协商一个内部NAF-key，还会协商一个外部NAF-key，3GPPTS33.220定义了NAF-keys的获取方式。在基于GBAME的GBA-Push自启动安全协商中，根据3GPPTS33.220生成的Ks不会受到影响。在基于GBAU的GBA-Push自启动安全协商中，根据3GPPTS33.220生成的GBAUKs将会无效。如果在基于GBAU的GBA-Push安全协商后有应用要求使用GBAUNAF-keys，则需要进行一次通用GBA来建立新的GBA_UKs。但是，该应用可以继续使用从该无效的Ks中获取的NAF-keyS，例如，原来已经使用NAF-keys的应用不会受到GBA-Push自启动安全协商的影响。GBA-Push只支持生成在UE和NAF之间共享的NAF SAS，NAFSA包括NAF-key、密钥生命周期、以及其他一些信息，它们在6.2.3小节中定义。5.3GBAPush的要求
5.3.1GBAPush的基本要求
以下这些基本要求应用于GBAPush：6
一网络实体Push-NAF应能够安全地触发建立其与UE之间的NAFSA。在触发NAFSA的生成时，Push-NAF应能够使用存在消息延时的传输通道。一Push-NAF应能够在发给BSF的请求消息中使用指示UE的公共标识。一如果GBAPush使用了公共标识，则公共标识应对应一个唯一的私有标识。YD/T2922-2015
一当只需要基于ME的NAF-keys时，例如，Ks在ME中建立，则应使用基于ME的GBAPush。当UE拥有支持GBA的UICC卡（GBAU），并且需要基于UICC和ME的NAF-keys或者需要只需要基于UICC的NAF-keys，例如，Ks在UICC中建立，则应使用基于UICC的GBAPush。一一从Push-NAF推送给UE消息的接收，触发了UE中NAF SA的生成。一UE不应需要联系网络实体才能正确生成NAFSA。一不管GBA自启动安全协商是通过Ub还是Upa参考点，UE和NAF应能够独立地在Ua参考点上使用NAF-keys。
注：当使用GBA-Push机制来创建UE和NAF之间的NAFSA时，不局限NAF将获取的安全协商只应用于网络侧发起的协议：同样，当使用UE发起的GBA时，不局限NAF将获取的安全协商只应用于UE发起的协议（Ua参考点）。一一为了避免预配置密钥，保护GPI信息机密性和完整性的密钥生成机制应基于GBA原则。一NAF不能够获取或生成用于保护GPI信息的密钥。5.3.2HSS及HLR的要求
HSS和HLR的要求应符合3GPPTS33.220。5.3.3BSF的要求
除了3GPPTS33.220的4.2.1小节中的BSF要求，还存在以下要求：BSF应能够查找到与公共标识所对应的私有标识。一一BSF应能多根据私有标识查找到对应的Ks。一BSF应能够根据新的Ks生成GPI。一一BSF应对GPI进行完整性保护。一BSF应对GPI中特定域进行机密性保护，需要机密性保护的域在6.2.1小节中介绍。5.3.4UE的要求
除了3GPPTS33.220的4.2.4小节中的UE要求，还存在以下要求：一UE应能够存储并处理NAFSAS。一一本标准中的ME也应实现3GPPTS33.220中所定义的GBA_U和GBA_ME。一UE可能执行一种认证授权机制来认证接收到的GBAPush消息注：GBAPush消息认证授权机制可以基于Push-NAFs的FQDN名所对应的白或黑名单列表。5.3.5参考点Upa的要求
参考点Upa的要求：
一UE应能够基于AKA来验证GPI来自一个被授权BSF。注l：通过Push-NAF可以拥有正确的Ks（ext/int）_NAF，表明BSF已经认证了NAF，这样，Push-NAF就间接地得到了认证。
一UE应能够确定进行自启动安全协商的UICC（USIM/ISIM）应用。一一NAF和UE应能够建立一个共享的NAFSA。YD/T2922-2015
一NAF应能够发送NAFSA标识信息。一BSF应能够将密钥材料的生命周期指示给UE。BSF通过Upa发送的密钥生命周期应指示密钥的过期时间。
注2：Upa参考点的要求是基于3GPPTS33.220中所述的Ub参考点的要求。5.3.6参考点Zh的要求
参考点Zh的要求与3GPPTS33.220中一样。5.3.7参考点Zpn及Zpn'的要求
参考点Zpn的要求：
一应提供互认证、机密性保护、完整性保护。一如果BSF和NAF处于同一个运营商网络，则应用3GPPTS33.210中的NDS/IP来保护基于DIAMETER协议的参考点Zpn
一如果BSF和NAF处于不同的运营商网络，则应根据IETFRFC2246的TLS来保护Zn-Proxy和BSF之间的基于DIAMETER协议的参考点Zpn'。注1：3GPPTS33.220的附录E指定了需要使用TLS特性。一基于Zpn/Zpn参考点的网络服务应用IETFRFC2246中的TLS来保护。注2：：3GPPTS33.220的附录E指定了需要使用TLS特性。注3：该要求根据3GPPTS33.220中的要求修改得到，以使适用于GBAPush。注4：由于UE可能无法验证pNAFPQDN，在网络侧的Zpn-proxy中严格检查pNAFFQDN-name显得十分重要。过于简单地检查pNAFFQDN-name，例如，只验证FQDN的一部分，可能会导致pNAFs滥用pNAFFQDN-name的上升。-BSF应能够将NAF请求的密钥材料发送给NAF。一根据BSF的策略以及NAF通过Zpn的请求消息中指示的应用，NAF应能够从BSF获取一组特定应用的USSs。
-NAF应能向BSF表明其需要申请一个应用还是一些应用的USSS。注5：如果某些应用只需要一个特定应用USS的子集，例如，IMPI，则NAF从来自BSF的完整USS中选择该子集。一BSF一个能够以单个NAF或单个应用的粒度进行配置。一私有用户标识，例如，IMPI，可能发送给NAF。特殊的USS可能发送给NAF。
一如果NAF向BSF请求的USSs不在用户的GUSS中，但只要满足BSF本地策略的条件，则这不应形成错误。BSF应只向NAF发送其所请求的并找到的USSS。可以这样配置本地策略：BSF可能请求一个或多个特定应用的USS，这些USS出现在特殊请求NAF的特殊用户的GUSS中；而如果条件不满足，则BSF拒绝来自NAF的请求。为了满足本地策略，不要求NAF通过Zpn参考点请求USSs信息，这些USSs是BSF要求出现在GUSS中的，更确切地说，BSF本地检查USS的存在性已经足够。也可以这样配置BSF：对于请求NAF，没有要求的USS。注6：更多关于本地策略使用的信息可以查看3GPPTS33.220的附录J。NAF应能够请求NAFSA的生命周期。BSF通过Zpn发送的密钥生命周期应指示密钥的过期时间。
注7：根据NAF的本地策略，这不妨碍NAF在密钥过期时间之前更新NAFSA，8
YD/T2922-2015
注8：如果传递给NAF的一个或多个USSs在HSS中的用户GUSS中发生了更新，则在下一次NAF从BSF请求USS时，BSF将更新的USSs通过Zpn参考点发送给NAF（如果BSF已经通过Zh参考点获取了HSS中更新了的用户GUSS）。5.3.8Zn-Proxy的要求
当PushNAF不在归属网络，则访问NAF应使用NAF网络的Zn-proxy来与用户BSF（归属BSF）交互。Zn-proxy的要求在3GPPTS33.220中描述。5.3.9参考点Ua的要求
参考点Ua的要求见3GPPTS33.220，另外增加以下要求：一应可以在上行方向使用SA标识，这些标识与建立NAFSA所使用的推送消息没有关系。5.3.10NAFSA标识的要求
要求如下：
一下行NAFSA标识应在UE中唯一并且唯一指示一个对应于特定NAFID的NAFSA。一一上行NAFSA标识应在NAF中唯一并且唯一指示一个对应于特定UE和Ua安全协议标识的NAFSA。
5.3.11参考点Dz的要求
该接口位于BSF和SLF之间，用于获取HSS的地址，DZz参考点应和3GPPTS33.220中的一样。该接口不要求处于只存在一个单一HSS的环境。5.4GPL的要求
5.4.1GPL会话的概念
可以预见未来将会出现基于Push-NAF的服务，这些服务依赖于单设备会话的概念，基于同一个安全协商来推送多条消息将带来很多益处。一个很好的例子是病毒签名服务器，病毒签名可能通过多条推送消息来传递（基本推送传递机制的消息尺寸限制原因），如果为每条消息都建立一个新的安全协商，这将会十分低效。
这要求GPL除了提供完整性保护之外（以及可能的机密性保护），还需要提供抗重放保护。图3所示描述了使用场景，其中只使用一个安全协商来将三条推送消息从Push-NAF传递给UE。注意步骤（1）和步骤（2）不属于本标准范围，步骤（1）和步骤（2）见3GPPTS33.222的规定。CUE
密钥根据Ks_NAF
或Ks intNAF获取
的安全关联
(1)UE和BSF之间Ks的建立
(2）Ks_NAF或Ks_intNAF的建立
密钥根据Ks_NAF
或Ks_int_NAF获取
的安全关联
推送消息1
推送消息2
推送消息3
图3安全会话示例
如果GPL用来提供一个完整的会话概念，包括通过超时设定/确认和重传机制、会话的重建、消息的9
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。