5G移动通信网 安全技术要求（第二阶段）

15G移动通信网安全技术要求(第二阶段)本文件规定了第二阶段的5G移动通信网的安全技术要求、安全功能以及相关安全流程等，主要包括5G物联网安全、5G低时延高保障安全、增强服务化架构安全、5G固移融合安全、接入回传一体化安全、垂直行业与局域网安全、5G语音连续性安全、增强切片安全、增强用户面完整性保护以及用户面安全网关功能要求等。本文件适用于面向个人、企业等场景下独立组网的5G移动通信网络安全架构搭建、安全要求定义与安全能力实施。下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件：不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。YD/T2258-2011移动通信网安全术语集YD/T2910-2015LTE/SAE安全技术要求YD/T3627-20195G数字蜂窝移动通信网增强移动宽带终端设备技术要求(第一阶段)YD/T3628-20195G移动通信网安全技术要求3GPPTR21.9053GPP规范词汇表(Vocabularyfor3GPPSpecifications)Continuity(SRVCC):Stage2)3GPPTS23.3165G系统(5CS)的无线和有线融合接入支持(二阶段)(Wirelessandwirelineconvergenceaccesssupportforthe3GPPTS23.5025G系统流程(二阶段)(Proceduresforthe5GSystem;Stage2)(MAS)protocolfor5GSyste3GPPTS33.220通用认证体系结构(GAA)(GenericAuthenticationArchitecture(GAA))Description:Stage2)3GPPIS38.401下一代无线通信网络架构描述(NG-RAN;Architecturedescription)IEEEStd802.11-2016系统间电信和信息交换局域网和城域网特殊要求第11部分：无线LAN介质访问控制(MAC)和物理层(PHY)规范(TelecommunicationsandintormationexchangebetweensystemsLocalandmetropolitanareanetworks—SpecificLANMediunAccessControl0MAC)andPhysicalLayer(PHY)IETFRFC2410空加密算法及其在IPsec中的应用(TheNULLEneryptionAlgorithmandItsIETFRFC3748可扩展身份验证协议(EAP)(ExtensibleAuthenticationProtocol(EAP))IETFRFC7515JSONWeb签名(J23术语、定义和缩略语3.1术语和定义YD/T2258-2011、YD/T3628-2019以及3GPPTR21.905界定的以及下列术语和定义适用于本文件5G安全上下文50securitycontext由UE和服务网络本地创建并由存储在UE和服务网络的“5G安全上下文数据“表示的安全参数集下列缩略语适用于本文件。第三代移动通信网络第三代合作伙伴计划第5代移动通信网络5G核心网5G家庭网关AAA认证、授权和计费Authentication,Authorizationand认证、授权和计费代理Authentication,Authorizationand认证、授权和计费服务器Authentication,Authorizationand接入与移动性管理功能AccessandMobilityManage应用程序接口接入网络AccessNetwork接入层认证服务器功能回传适配协议宽带论坛回传(美国)有线行业研发实验室客户端凭证断言ClientCredentials控制面电路交掺集中单元动态主机分配协议数据网络DataNetwork数据无线承载3数据包传输层安全协议DatagramTransportLayer分布单元可扩展认证协议ExtensibleAuthenticationP早期数据传输EarlyDataTransmiss理EvolvedPacketSystemMobilityMa演进的分组系统EvolvedPacketSy固定接入网关功能固网家庭网关5G基站theNextGenerationNodeB公共用户标识符GenericPublicSubscriptionIden接入回传一体化IntegratedAccessandBackhaulIP多媒体子系统IPMultinediaS互联网协议InternetProt互联网安全协议InternetProtocolPLMN内部用户面安全局域网链路控制协议移动管理实体MobileManagementEntityMN主节点移动交换中心备Non-5G-CapableoverWLAN非5G能力设备Non-5G-CapableNAI网络接入标识NetworkAecessIdentifier非接入层安全下一跳计数器NF网络功能NIDD非IP数据传输NRF网络存储功能NetworkRepositoryFunct切片认证授权功能etworkslicespecificauthentdauthorizationfunct物理层小区识别分组数据汇聚协议PncletDataConverge数据包单元PacketDataUnit非独立的非公共网络PublieNetworkintegratedNon-PublieNetwork点对点协议Point-to-PointProtoc公共陆地移动网数据交换预共享密钥预配置上行链路资源PreconfiguredUplinkRe无线链路控制无线链路失败RadioLinkFailu无线资源控制RadioResource4服务控制点SEAF安全锚功能SEcurityAnchor安全边缘保护代理SecurityEdgeProtec用户标识去隐藏功能SubscriptionIdentifierDe-concealing安全模式命令会话管理功能SessionManagenentFunct短信服务ShortMessage辅节点独立非公共网络Stand-aloneNon-PublicNetwork信令无线承载SignalingRadio单一语音呼叫连续性SingleRadioVoiceCall用户隐藏标识用户永久标识SubscriptionPermanent传输层安全协议TransportLayerTNAN可信非3GPP接入网络TrustedNon-3GPPAccessNetwTrustedNon-3GPPAccessPointTrustedNon-3GPPGatewayFunction时间敏感通信时间数感网络Tine-SensitiveNetwor可信无线局域网互通功能TrustedWLANInterworki用户设备统一数据管理用户面用户面功能高可靠低时延通信Ultra-ReliableandLowLatency通用用户身份模块UniversalSubscriberIdentityMo有线接入网关功能WirelineAccessGatewayFunction无线局域网WirelessLocalAreaNetwork4.1RRO终端能力上报流程网络在启动RRC终端能力上报流程之前应当激活接入层安全机制(例如成功执行一次ASSWC流除了不做身份认证的紧急呼叫和终端使用控制面蜂窝物联网优化机制以外，如果网络已经在AS安全机制激活之前要求终端执行RRC终端能力转移流程，网络不能为了后续使用而在本地存储它们，也不能给其他网络实体发送它们。否则，网络应在成功执行一次ASSMC流程之后重新再执行一次RRC终端能力转移流程。流程无法得到安全保护。4.2在蜂窝物联网中的安全处理54.2.15G蜂窝物联网控制面优化机制中的安全处理4.2.1.1利用50蜂窝物联网控制面优化机制进行小数据传输的安全流程5G蜂窝物联网控制面优化机制用于在上行链路和下行链路方向上交换小的用户数据或者作为NAS信令有效负载的SMS。终端和MF使用特定于NAS连接的NAS安全上下文为小用户数据或者SMS执行完整性保护与加密。如果终端使用5G蜂窝物联网控制面优化机制进行发起端的数据传输，则终端会发送一个控制面服务请求消息，消息中包括一个用于小用户数据或者SWS传输的容器。控制面服务请求消息应被部分加密(即对包含上行链路用户数据或SMs的容器进行加密，不存在未加密的明文),并且完整性应由特定于NAS连接的当前5GNAS安全上下文进行保护。接收到带有包含小用户数据或SMS传输在内的加密容器的控制平面服务请求消息后，AMF将验证整个控制面服务请求消息的完整性并解密该加密容器以获得小用户数据或SMS。当对容器应用NAS加密/解密机制时，应将LENGTH值设置为容器报文的长度OM-OONNECTED模式下的终端会在ULNAS传输消息中向AF发送小用户数据或SMS.应当使用特定于NAS连接下的当前5GNAS安全上下文来对ULNAS传输消息进行加密和完整性保护。在接收到用于小用户数据或SUS传输的ULNAS传输消息后，AF将验证完整性并解密UL.MAS传输消息以获得小用户数据或如果终端使用5G蜂窝物联网控制面优化机制进行接收端数据传输，则终端从MF发出的DLMAS传输消息中获得小用户数据或SMS。DLNAS传输消息应使用特定于NAS连接的当前5GMAS安全上下文进行加密和完整性保护。在接收到用于传输小用户数据或SMS的DLNAS传输消息后，终端应验证消息完整性并解密DLNAS传输消息以获得小用户数据或SMS。4.2.1.2利用50蜂窝物联网控制面优化机制进行RRC连接重建流程的安全流程在终端仅使用5G蜂窝物联网控制面优化机制，出现无线链路失败(RLF)的情况时，终端的接入层可能会触发RRC连接的重建。由于没有可用的接入层安全保护，重建流程无法得到安全保护。为了保护重建流程，终端的接入层功能会触发终端非接入层提供ULNASMAC和XDLNAS_MAC两个参数。这些参数分别用于表明终端正在请求重建，而且终端在与一个真实的网络进行交互。终端通过当前的MAS完整性保护算法来计算ULMAS_MAC和XDLNAS_MAC,需要用到的输入参数主要有：完整性保护密钥Ksin,用于下一个上行MS消息的上行NASCOUNT,同时要将DIRECTION位设置为0,受到保护的目标基站识别码(targetCell-ID)则用来计算NAS-MAC.当终端发送了一条MS消息后，会以完全相同的方式增加上行链路MASCOUNT。MS-MAC的前16位形成UL.NAS_MAC,后16位形成XDLNMSMAC,并由终端进行存储。终端将向目标基站发送包含截短5G-S-TMSI(theTruncated5G-S-TMSI)在内的RRC连接重建，NASCOUNT的5个最低位用于计算消息中的NAS-MAC和ULNSMAC。目标基站通过消息中包含的截短5G-S-TMSI,识别出是由工作在5G蜂窝物联网控制面优化机制下终端所发出的RRC连接重建请求消息。目标基站通过截短5G-S-TISI生戌5G-S-TMSI。目标基站将5G-S-TMSI,MASCOUNT的低位，UL.NAS_MAC和控制面重定位消息中的TargotCel1-ID发送给终端的服AMF使用NASCOUNT的低位来估计完整的上行NASCOUNT并计算XNAS-MAC,其中使用的输入参数与终端计算NAS-MAC时的参数相同(例如，估算得到的上行链路NASCOUNT,DIRECTION位设置为0,以及作为消息的targetCELL-ID)。AMF将收到的UL_NAS_MAC与XNAS-MAC的前16位进行比较，如果结果相同，网络就能够确认RRC连接的重建消息是由真实的终端所发送。类似MF收到一个用该NAS0OUNT成功保护的NAS消息一样，对存储在AMF中上行链路NASCOUNT进行设置。6AMF将DL_NAS_MAC设置为己经计算得到的XNAS-MAC的后16位，并在连接重建认证消息中将DL_NAS_MAC发送到目标基站。目标基站将在RRC连接重建消息中将DL.NAS_MAC发送给终端。终端应当检查接收到的DLNAS_MAC是否与存储的XDLNAS_MAC相同。如果相同，则终端完成重建流程。4.2.25G蜂窝物联网用户面优化机制中的安全处理5G蜂窝物联网用户面优化机制中的安全处理目的是允许基站挂起一个RRC连接，并通过终端在随后时间里使用5G蜂窝物联网用户面优化机制来对RRC连接进行恢复。终端可以在同一个或不同基站上恢复被挂起的RRC连接。终端和基站在暂停时存储AS安全上下文，并在恢复时重新激活AS安全上下文。终端和基站也可以在这个流程中使用EDT(早期数据传输)或PUR(预配置上行链路资源)功能4.2.2.2连接挂起当基站启动连接挂起流程时，它将N2挂起请求消息发送到AMF。收到N2暂停请求消息后，AMF将检查其本地策略。如果本地策略指示需要新的NH推导，则AMF应将其本地保存的NCC值增加1,并从其存储的数据中计算出一个新的NH。AMF需要存储该新的数组(NH,NCC,并通过N2挂起响应消息将其在收到AMF发出的N2暂停响应消息后，如果该消息包括数组(NH,NCC},则基站应将新的[NH,NCC)存储在N2暂停响应消息中，并删除任何现有未使用的存储(NH,NOC)数组。基站应向终端发送一个使用当前AS安全上下文在PDCP层进行加密和完整性保护的RRCRelease,同时该release的原因设置为rrc-suspend。基站在该RRCRelease消息中包括一个新的I-RNTI和一个NOC。I-RNTI用于上下文标识，并且由基站分配的I-RNTI的UED在同一终端的连续挂起中并不相同。这是为了避免基于I-RNTI来跟踪终端。如果基站有新的和未使用的(NOC,M}对，则基站应在RRCRelease消息中包含NOC,否则，基站将在RRCRelease消息中包含与当前K关联的相同NCC.NOC用于AS安全保护。基站在将RRCRelease发送给终端之后，应删除当前的AS密钥Kcme,KIpm.(如果可用)和KIpimt (如果可用),但是应保留当前的AS密钥Kgrint。如果发送的NCC值是新鲜的且属于未使用的{NOC,NH},则基站将保存现有终端AS安全上下文中的[NCC,NH},井删除当前的AS密钥Ks。如果发送的NOC值与当前K关联的NCC值相同，则基站将保留当前的AS密钥K,和NCC。基站应将发送的I-RNTI与当前的终端上下文(包括S安全上下文的其余部分)一起存储。当从基站接收到releaseCause设置为rrc-suspend的RRCRelease消息后，终端应当使用密钥Kgrcm.来解密RRCRelease,并通过检查POCPMAC来验证接收到的RRCRelease消息的完整性。如果消息完整性验证成功，则终端应当接收NCC,并将其保存为当前终端上下文中存储的NCC.4.2.2.3针对新基站在CM-IDLE状态挂起的连接恢复当使用5G峰窝物联网用户面优化机制的终端决定恢复在CM-TDLE状态下挂起的RRC连接时，终端在SRBO上发送RRC恢复请求消息(即没有受到完整性保护)。终端在RRC恢复请求消息中应包含I-RNTI和ShortResumeAC-I。I-RNTI用于上下文标识，其值应与终端从源小区的RRCRelease包含的源基站中接收到的I-RNTI相同，同时该RRCRelease的releaseCause为rrc-suspend.ShortResumeMAC-I是一个16位消息认证令牌，终端应在存储的AS安全上下文中使用完整性算法(EIA)计算该令牌，该流程是由终端、源基站、当前的Kgcim以及以下输入参数之间协商确定的。——KEY:应设置为当前Kgcim:——BEARER:所有位应设置为1:——方向：对应位应设置为1;--C0UNT:所有位应设置为1:7——消息：设置为VarShortResumeLAC-Input,并具有以下输入：源C-RNTI,源PCI,恢复常数，源PCI和源C-RNTI与终端被挂起的小区相关联。目标小区ID(Cel1-ID)是终端所发送RHC恢复请求消息的目标小区标识。恢复常数允许区分VarShortResuneMAC和VarShortMAC.为了保护发送RRC继续请求消息之后的所有RRC消息(除了RRC拒绝消息),终端使用目标PCI,目标EARFCN-DL和基于水平密钥或者垂直密钥推衍的Ks/NH来推导K-pw'。终端进一步通过K-u”推导出Krimt,Kcm,Kar。(可选)和Kpim;(可选)。然后，终端将所有PDCPCOUNs重置为0,并激当目标基站从终端接收到RRC恢复请求消息时，目标基站从RRC恢复请求消息中提取I-RNTI。目标基站基于I-RNTI中的信息通过发送Xn-AP检索终端上下文请求消息与源基站联系，其中包括：I-RNTI,ShortResumeMAC-1和目标Cel1-ID,为了允许源基站验证终端请求并检索包括终端5GAS安全上下文在内的终端上下文。源基站使用I-RNTI从其数据库检索其保存的5GAS安全上下文在内的终端上下文。源基站使用存储在检索到的终端5GAS安全上下文中的当前Kpcm密钥来验证shortResuneMAC-I(以与上述相同的方式计算shortResumeMAC-I)。如果shortResumeMAC-I验证成功，则源基站使用目标小区PCI,目标EARFCN-DL和当前终端5GAS安全上下文中的K₂/NH来计算Kg-a*,并根据源基站是否具有未使用的{NOC,NH],来决定使用水平密钥推衍还是垂直密钥推衍。源基站能够通过从目标基站接收到的目标Cel1-ID,从小区配置数据库中获取目标PCI和目标EARFCN-DL。然后，源基站将向目标基站响应Xn-AP检索终端上下文响应消息，该消息包括包含5GAS安全上下文在内的终端上下文。发送到目标基站的5GAS安全上下文应包括新推衍的Kw*与Kc-au*关联的NCC,终端EPS安全能力，UP安全策略，UP安全激活状态和终端与源小区共同使用的加密和完整性算法。日标基站将检查其是否支持终端与最后一个源小区使用的加密和完整性算法。如果目标基站不支持在最后一个源小区中使用的加密和完整性算法，或者目标基站倾向于使用与源基站不同的算法，则目标基站将会在SRB0上向终端发送一个RRCSetup消息，以便继续进行RRC连接建立，就像终端处于RBC_IDLE(即回退流程)一样。如果目标基站支持最后一个源小区使用的加密和完整性算法，并且这些算法是由目标基站所选择，则目标基站使用终端与源小区使用的算法、接收到的K-w*推导新的AS密钥(RRC完整性密钥，RRC加密密钥和用户面密钥)。目标基站将所有PDCPCOUNT重置为0,并激活PDCP层中的新密钥。目标基站将在SRB1上通过RRC恢复消息响应终端，该消息受到完整性保护并使用新的RRC密钥在PDCP层中进行加密。如果目标基站可以支持UP安全激活状态，则目标基站将使用终端在最后一个源小区使用的UP安全激活。当终端接收到RRC恢复消息时，终端将使用基于新Kc-auw导出的Kc对消息进行解密。终端还应通过使用从新Km-s导出的Karim验证PDCPMAO-I的方式来验证RRCResunc消息。如果RRCResume消息验证成功，则终端应当删除当前的Kcim并保存新K的推衍的Kocin,Kong,Korme(可选)和KPint (可选),作为终端当前AS安全上下文的一部分。在这种情况下，终端应当使用当前的Kciz和Kacm,在SRB1上向目标基站发送受完整性保护和加密的RRC恢复完成消息。终端将使用UP安全激活状态来保护UP数据。如果终端从目标基站接收到响应RRC恢复请求消息的RBC拒绝消息，则终端应删除用于连接恢复尝试的新AS密钥，包括新获得的Kc-en",新获得的RBC完整性密钥，RRC加密密钥和P密钥，并将当前的Kpcint和K,/NH保留在其当前的AS上下文中。在那种情况下，对于任何目标基站的下一次恢复，终端将从与最初挂起时相同的AS安全上下文开始，例如相同的K/NH将作为推衍新Ka-ew*的根密钥。在成功恢复后，目标基站将与AMF执行路径切换流程，如X2切换的情况一样。AMF应验证终端的安全能力，而SMF应验证终端的UP安全策略。8当使用EDT或PUR功能时，在发送RRC继续请求消息之前，终端应使用新推衍的KA.根据UP安全激活对ULUP数据进行加密，并向目标基站发送在带有RRC继续请求的在PDCP层中加密的UL.UP数据。目标基站在从源基站提取终端上下文后，将根据UP安全激活的状态，使用新获得的Krm获取ULUP数据。终端和目标基站将使用相同的Kr。和UP安全激活来保护RRCRelease,以及可能存在的RRC恢复消息中4.2.2.4针对同一基站CM-IDLE状态挂起的连接恢复目标基站可以与先前条款描述中的源基站相同。如果是，则同一个基站同时充当了源基站和目标基站的角色。特别是，即使终端正在从其挂起的位置恢复到同一小区，也应得到一个新的Kc-u但是，仍然存在以下差异。成功恢复后，基站将向AMF发送N2恢复请求消息。收到N2恢复请求消息后，AMF将检查其本地策略。如果AMF中的本地策略指示需要推衍新的NH,则AF需要将其本地保留的NCC值增加1,并从其存储的数据中计算出一个新的NH。AMF将存储该新数组，并在N2恢复响应消息中将其发送到基站。在收到AMF发出的N2恢复响应消息后，如果该消息包括[NH,NCC],则基站应将[NH,NCC]存储在N2恢复响应消息中，并删除任何现有未使用的(NH,NCC}。{NH,NCC}可以在下一个挂起/恢复或Xn切换流程中使用。4.2.3非IP数据传输接口(NIDD)的保护NIDD的功能可用于处理与终端的发起端和接收端通信，其中用于通信的数据被认为是非结构化由于NEF了NIDDAPI,因此应使用TLS保护机制保护NIDD接口。4.2.4基于从56系统到4G系统重定向NAS中的安全处理当终端启动向AMF的注册流程时，AMF可以通过一个终端不应使用5G核心网的EMM原因，使得终端从5G核心网重定向到4G核心网。以下要求适用于具有EM原因的注册拒绝消息，该消息向终端指示该终端不应使用5G核心网：--一旦在AMF和终端之间建立了NAS安全性，AF将仅发送这种注册拒绝消息：——如果接收到的消息受到完整性保护并且终端己成功验证了注册拒绝消息的完整性，终端仅应处理此类注册拒绝消息本章描述了URLLC的安全要求、流程和处理。其流程和处理包括对数据传输的安全策略实施。URLLC的一般特性在3GPPTS23.501、3GPPTS38.300和3GPPTS23.502中描述。5.2冗余传输的安全保障5.2.1基于双连接的冗余用户面路径为了支持URLIC业务，UE在5G网络上将建立两个冗余PDU会话，这样50S就可以建立两个冗余PDU会话的分离的用户面路径，如3GPPTS23.501v16.10.0中5.33所述。其中，单个NG-RAN节点可以识别两个PDU会话的冗余用户面资源，两个NG-RAN节点通过双连接识别冗余用户面资源，即，一个PDU会9YD/T××和DN之间通过3GPP网络中不同的路径发送冗余数据。用于传输冗余PDU会话的双连接的安全流程和描述己经在YD/T3628-2019的6.10中介绍。本章仅介绍额外的安全特性。5.2.2安全策略方面当使用双连接进行冗余传输时，两个PDU会话都通过MN进行初始建立。SMF应在PDU会话建立流程中向MN提供两个PDU会话各自的UP安全策略，如YD/T3628-2019的6.6.1所述。来自SMF的用于冗余数据传输的两个PDU会话的UP安全策略应具有相同的加密和完整性保护设置。网络(UDM或SMF)应确保如3GPPTS23.501中描述的UE发送的所有冗余PDU会话应具有相同的UP安全策略设置。MN应预配置或应能够访问SN支持的安全能力(即，SN是否支持UP完整性保护)。MN在选择SN时应使用收到的UP安全策略。MN应确保第一PDU会话和第二PDU会话具有相同的LP安全激活状态。如果SMF或UDM不允许为URLLC业务使用UP安全策略中的“优先”选项，或者说SMF或UDM可以保证第一PDU会话和第二PDU会话的UP安全策略是相同的，即只包含“不需要”或“需要”,那么如YD/T3628-2019的6.10所述，MN将UP安全策略发送给SN.如果允许将URLIC业务的UP安全策略设为“优先”选项，则应在YD/T3628-2019的6.10中描述的双连接机制下进行以下增强：--MN应根据这两次数据传输的UP安全策略决定UP加密保护和完整性保护。MN应存储N和UE根据第一PDU会话建立的DRB所使用的UP安全激活状态。然后，MN在向SN卸载第二PDU会话的DRB时，应向SN发送第一PDU会话对应的UP安全激活状态：--SN应使用从MN接收的UP安全激活5.3N3/N9接口的冗余传输如果冗余数据通过两条相同的N3隧道实现，如图1所示，冗余数据将通过UPF和RAN之间的两条独立的N3隧道进行传输，这些N3隧道与一个PDU会话关联。并且通过不同的传输层路径来传输，可以提升服务的可靠性。N4N3能道1N3N3随道2NG-RANN6N图1基于UPF和独立MNG-RAN之间两条N3隧道的冗余传输为了保护N3接口上的冗余数据，应重用YD/T3628-2019的9.3中定义的机制。对于增加的冗余路径，应提供与单路径相同的安全级别。对于独立NG-RAN两条N9隧道的冗余数据传输场景，应采用NDS/IP保护机制来保护上述两条N9隧道的冗余数据传输。6增强服务化架构安全要求本描述增强服务化架构安全要求与流程。增强服务化架构的大部分安全要求与流程与一阶段服务化架构的安全要求与流程结合紧密，因此本全面阐述增强服务化架构的安全要求与流程。5G系统对增强服务化架构的安全要求特性参考YD/T3628-2019的描述6.2认证和静态授权6.2.1静态授权静态投权是NRF和NF服务生产者的本地授权，可以在不使用基于令牌的授权时使用。在NnrfNFDiscovery流程中，NRF确保NF服务使用者被授权来发现NF服务生产者的服务。如果在一个PLMN中未使用基于令牌的授权，并且NF服务生产者收到服务请求，则NF服务生产者应根据其本地策略检查NF服务使用者的授权。如果NF服务使用者被授权接收服务，则NF服务生产者应授予NF服务使用者访问服务API的权限6.2.2NF和NRF之间的认证和授权NRF和NF在发现、注册、令牌请求流程中需要相互认证。在直接通信中，NF和NRF应使用以下方法之一进行认证：——如果PMN在传输层使用保护，则传输层保护解决方案提供的认证应用于NRF和NF的相互认——如果PMN在传输层不使用保护，则NS/IP或物理安全可能隐含NRF和NF的相互认证。6.2.2.2间接通信在间接通信中，NF和NRF应使用以下方法之一进行身份验证：——传输层保护解决方案提供的NF和NRF之间的相互认证；——如13.3.8所述，基于客户端凭据断言(CCA)的身份验证注1:客户增凭证声明身份验证基于NF服务使用者通过中间设备(如SCP)发送到NRF的OCA令牌。基于CCA——隐式的，即依赖于NF服务使用者和SCP之间以及SCP和NRF之间的身份验证，由传输层、NDS/IP或物理安全的逐跳安全提供保护6.2.2.3发现请求和错误处理的授权当NRF(NF)从未经身份验证的NF(NRF)接收消息时，NRF应支持诸误处理，并可以发回错误消息。在NRF与NF之间成功进行身份验证之后，NRF应决定NF是否被授权执行发现和注册。Nnrf_NFDiscoveryReques在漫游场景下，NF服务生产者的NRF应基于预期NF/NF服务的配置文件，NF服务使用者的类型和服务网络ID,来授权Nnrf_NFDiscoveryRequest。如果NRF发现NF服务使用者不被允许发现预期的NF实例，则NRF应支持错误处理，并可以YD/T××发回错误消息。6.2.3NF和NF之间的认证和投权在直接通信中，一个PLMN内的网络功能之间的认证应使用以下方法之一：——如果PMN在传输层使用保护，则传输层保护解决方案提供的认证应用于NF之间的认证：——如果PLMN在传输层不使用保护，则NDS/IP或物理安全可能隐含一个PLMN内的NF之间的身份验证。如果PLMN使用基于令牌的授权，则网络应在传输层使用保护6.2.3.2间接通信在间接通信方案中，NF服务生产者和NF服务使用者之间应使用隐式认证，这种隐式认证是通过在NF服务使用者和SCP之间以及SCP和NF服务生产者之间的传输层保护解决方案，NDS/IP或物理层安全来实现认证的。如果PLMN使用基于令牌的授权，并且PLMN的策略要求NRF在授子访问令牌之前先对NF服务使用者进行认证，则访问令牌会向NF服务生产者指示NF服务使用者已经由NRF认证。如果需要NF服务使用者额外的认证，则NF服务生产者使用基于CCA的身份验证在应用层对NF服务使用者进行身份验证。基于CCA验证的NF服务使用者认证是可选使用的，并且基于运营商策略。如YD/T3628-2019中所述，PLMN间UP安全功能(IPUPS)提供了一种标准化解决方案，在漫游场景下，将N16/N32上的PLMNV-SMF和H-SMF之间的5GSBAREST服务操作绑定到N9上的GTP-U,6.2.3.4错误处理当NF接收到来自未经认证的NF的消息时，接收的NF应支持错误处理，并且可以发回错误消息6.2.4SEPP和NF之间的认证和授权一个PLMN内SEPP和网络功能之间的认证应使用以下方法之一：——如果PLMN在传输层使用保护，则传输层保护解决方案提供的认证应用于SEPP和NF之间的认证；—如果PMN在传输层上不使用保护，则一个PLMN内SEPP和NF之间的身份验证可能会由NDS/IP或物理安全隐含。在SEPP将网络功能发送的消息转发到其他PLMN中的网络功能之前，以及SEPP将其他PLMN中的其他网络功能发送的消息转发到网络功能之前，网络功能和SEPP应相互认证6.2.5SEPP和SCP之间的认证一个PLN内SEPP与SCP之间的认证应使用以下方法之一：——如果PLMN在传输层使用保护，则传输层保护解决方案提供的认证应用于SEPP和SCP之间的认证；-—如果PLMN在传输层不使用保护，则一个PLMN内SEPP和SCP之间的认证可能会被NDS/IP或物理安全隐含。SCP和SEPP应在转发传入或传出请求之前相互认证。6.2.6SCP和NF之间的认证和投权SCP和网络功能应使用以下方法之一进行相互认证，然后才能在该接口上交换服务层消息：——如果PMN在传输层使用保护，则传输层保护解决方案提供的认证应用于SCP和网络功能的相互认证；——如果PLMN不在传输层使用保护，则NDS/IP或物理安全可能隐含SCP和网络功能的相互认SCP和网络功能之间的身份验证可以通过共置来隐式实现。6.2.7SCP之间的认证和授权SCP应使用以下方法之一来相互认证，然后才能在该接口上交换服务层消息：——如果PLMN在传输层使用保护，则传输层保护解决方案提供的认证应用于SCP的认证：——如果PLMN在传输层不使用保护，则NDS/IP或物理安全可能隐含SCP和SCP之间相互认证。6.2.8基于客户端凭据断言(CCA)的认证客户端凭据断言(CCA)是由NF服务使用者签名的令牌。通过将签名的令牌包括在服务请求中，从而NF服务使用者能被接收者(NRF,NF服务生产者)进行身份认证。CCA包括NF服务使用者的NF实例ID,可以由NF服务生产者根据证书进行检查。CCA包含时间戳以限制其生存时间。与NRF生成的访问令牌相比，CA的生存期更短。因此，它们可用于对NF-NF通信具有较短生存期的令牌要求的部署中。需要权衡的是，当CCA的寿命太短时，它要求NF服务使用者为每个新的服务请求生成一个新的CCA。CCA无法在漫游场景下使用，因为除非在两个PLMN之间建立了3GPPTS33.310中提及的交叉认证流程，否则本地PLMN中的NF服务生产者将无法验证受访PLMN中NF服务生产者的签名。CCA不对整个服务请求提供完整性保护。它也没有为NF服务使用者提供一种认证NF服务生产6.2.8.2客户端凭据断言签名(JWS)的数字签名保护。——NF服务使用者(subject)的NF实例ID: 时间戳(iat)和到期时间(exp):——预期受众(audience)的NF类型，即类型“NRF",“NF服务生产者”或“NRF”和“NF服务生产者”NF服务使用者应根据它的私钥对生成的CCA进行数字签名，根据IETFRFC7515所述。签名过的CCA应包括以下字段之一：——X.509URL(x5u),用于引用X.509公钥证书或用于签署客户端身份验证声明的证书链的资——X.509证书链(x5c),包括用于签署客户端身份验证声明的X.509公钥证书或证书链。YD/T××6.2.8.3客户端凭据断言的验证CCA的验证应由接收节点(即NRF或NF服务生产者)根据以下方式执行——按照IEIFRFC7515中所述验证JWS的签名：——按照IETFRFC7519所述验证指定的时间戳(iat)和/或到期时间(exp)。如果接收节点是NRF,则NRF会验证时间戳(iat)和到期时间(exp)。如果接收节点是NF服务生产者，则NF服务生产者将验证到期时间，并且可能验证时间戳。——它检查OCA中的受众声明是否与自己的类型相符：一-验证CCA中NFc的NF实例ID是否与用于签署CCA的公钥证书中的NF实例ID相匹配。6.2.9间接通信场景中的服务访问授权6.2.9.1无委托发现流程的间接通信的授权6.2.9.1.1NF服务使用者和NRF在传输层之间具有认证本章节涵盖了NF服务使用者和NRF通过相互认证的TLS连接，无委托发现流程的间接通信的授权，如图2所示。发面图2授权和服务调用流程，用于无委托发现的间接通信、WF和NRF之间在传输层有相互认证发现NF服务生产者：步骤0)可选地，NF服务使用者可以在请求授权以调用NF服务生产者的服务之前发现NF服务生产者。例如，如果NF服务使用者尚未发现NF服务生产者，则它可以运行发现流程。对NF服务使用者授权：步骤1)-2)NF服务使用者和NFF在传输层之间进行相互认证之后，NF服务使用者和NRF将执行YD/T3628-2019的13.4.1.1中“服务访问之前的访问令牌请求”流程。如果NF服务使用者已经发现NF服务生产者，则它也可以执行YD/T3628-2019的13.4.1.1中所述的“针对特定NF服务生产者/NF服务生产者实例的访问令牌请求”流程。服务请求：sm步骤4)NRF认证NF服务使用者。如果cNF身份验证成功并且NF服务使用者基于NRF策略被授权，则NRF会按照YD/T3628-2019中13.4.1.1的描述发出访问令牌。NRF使用NF服务使用者实例ID作为访问令牌的标识(Subject)。步骤5)NRF在访问令牌响应(Nnrf_AccessToken_GetResponse)中将访问令牌发送给SCP。步骤6)SCP将服务请求发送到NF服务生产者。服务请求包括在步骤5中接收到的访问令牌，也可以包括NF服务使用者CA。步骤7)NF服务生产者对NF服务使用者进行认证，如果成功，它将按照YD/T3628-2019中13.4.1.1所述验证访问令牌。步骤8)如果访问令牌的验证成功，则NF服务生产者将服务响应发送到SCP.步骤9)SCP将服务响应发送给NF服务使用者。7.1确定UE中的信任关系根据3GPPTS23.501中所述，有各种可能来确定UE中的信任关系。比如，可信的非蜂窝接入网可以预先配置在UE中。如果USIM支持非蜂窝接入网业务，归属网络运营商可以在USIM中配置一个可信的非蜂窝接入网列表。在UE中预先配置信息的情况下，归属网络运营商在USIM中预先配置的可信非蜂窝接入网列表应优先于XE中预先配置的信息。7.2非蜂窝可信接入50核心网的安全当UE通过TNAN注册到5GC时，实现可信非蜂窝接入5G核心网的安全。UE注册到5GC,同时通过EAP-5G流程向TNAN进行认证，这与非可信非蜂窝接入的注册流程类似。UE和TNAN之间的链路可以是任何支持EAP封装的数据链路(层2)。TNAP与TNGF之间的Ta接口要求参见3GPPTS23.501v16.10.0中的4.2.8.3.2。当UE尝试通过TNAN注册到5GC时，TNGF终止EAP-5G信令，并将NAS消息转发给5GC。TNAP是一个可信实体，因此UE和TNGF之间不需要IPSec加密，安全依赖于UE和TNAP之间的层2安全。即对于用户面和信令来说，NULL加密就足够了。独立的IPSeeSAs可用于NAS传输和PDU会话。UE在5GC注册结束时，UE和TNGF之间建立IPSeeSA(NWt接口),用于保护UE和TNGF之间的NAS消息。后续UE发起PDU会话建立时，TNGF为每个PDU会话建立一个或多个IPSec子SAs。这将导致UE和TNGF-UP之间要建立额外的IPSecSA(NWt接口),用于两者之间的用户面传输。7.2.2.1描述了不支持5GCMAS(N5CW)的WLANUEs如何通过可信的非蜂窝接入进行注册。这些N5CW设备能够使用3GPP凭证对网络进行身份验证，并借助于向AMF提供5CCNAS协议栈的互操作功能 (TWIF)进行注册。根据YD/T3628-2019的7.1定义，归属运营商策略决定该非蜂窝接入网络是可信的非蜂窝接入网络。当YD/T3628-2019的4.1中与非蜂窝接入网相关的所有安全域被归属运营商认为足够安全时，该非蜂窝接入可被该运营商识别为可信的非蜂窝接入。然而，该策略决定可能基于与安全功能组无关注：在YD/T3628-2019的7.1中规定了UE如何获得运营商策略，以及LE将如何处7.2.2.1可信非蜂窝接入认证以下规定了UE如何通过可信的非蜂窝接入网络被5G网络认证这是基于3GPPTS23.502v16.10.04.12a.2.2“可信非蜂窝接入的注册流程”中规定的流程。认证流程与YD/T3628-2019的7.2中定义的可信非蜂窝接入认证流程类似，如图5所示，具体如下m字YD/T××图5可信非蜂窝接入的注册/认证和PDU会话建立步骤0)UE通过3GPPTS23.501v16.10.06.3.12中规定的可信非蜂窝接入网选择流程选择一个步骤1)UE和TNAP之间建立层2连接。在IEEE802.11中，该步疆对应于802.11联盟。对于PPP,该步骤对应PPPLCP协商。在其他类型的非蜂窝接入(例如以太网),可以不执行此步骤。步骤2)-3)发起EAP认证流程。EAP消息应封装到层2数据包中，如IEEE802.3/802.1x数据包、IEEE步骤4)-10)EAP-5G流程按照YD/T3628-2019的7.2的规定执行，并做以下修改-—EAP-5G数据包不能封装在IKEv2数据包中。UE还应在AN参数中包括UEId,例如在相同PLMN已经注册后获得的5G-GUTI;-—认证成功后，在UE和AMF中创建YD/T3628-2019Kair)。Kra在步骤10a中从AMF传递到TNGF(包含在N2初始上下文建立请求中);——TNAP是一个可信实体。TNGF应生成附录A.2中规定的Krw,并在步骤10b中将其从TNGF 数据包，其中包含含有TNGF的IP地址的”TNGFContactInfo"。步骤11)公共TNAP密钥被UE和TNAP用于根据应用的非蜂窝技术推导安全密钥，并用于建立安全联盟以保护所有后续流量。在IEEE802.11中，Kmap是成对主密钥(PMK)并且执行四次握手，该四次握手在WLANAP和UE之间建立安全上下文，用于保护空口中的单播和多播流量。从该步骤开始，UE和TNAP之间的所有消息都要经过加密和完整性保护。注：当前流程假设开启UE和TMAP之间的层2加密保护步骏12)UE从TNAN接收到IP配置，例如通过DHCP。步骤13)UE应发起与TNGF的IKE_INIT的交换。UE在步骤9b中的EAP-5G信令中已经接收到TNGF的IP地址，随后E应发起IKEAUTH交换，并应包含与步骤5中提供的UEid相同的UEId(比如SUCI或5G-GUTI)公共Krs,用于双向认证。密钥Krns,根据附录A.1中的规定推衍。NULL加密根据IETFRFC2410的规定协商。步骤13c后，UE和INGF之间建立IPseeSA(即NWt连接),用于传输后续所有的MAS消息。该IPseeSA不使用加密，只使用完整性保护步骤14)NWtp连接建立成功后，TNGF向M回复N2InitialContextSetupResponse消息。步骤15)NASRegistrationAccept消息由MF发送，并通过建立的NWt连接转发给UE。步骤16)-18)UE发起建立PDU会话。按照3GPPTS23.502v16.10.04.12a.5中的规定执行。TNGF可以为每个PDU会话建立一个或多个IPSec子SA。步骤19)建立的PDU会话的用户面数据在UE和TNGF之间建立的IPSee子SA中传输。7.2.2.2可信非蜂窝接入的密钥层次结构在YD/T3628-2019的6.2.1中描述的密钥层次结构适用，但有以下更改；a)非蜂窝接入的密钥在可信接入上下文中称为Krr。b)从AMF收到的密钥Kna有两个不同的用途；在UE和TNGF之间建立IPSeeSAs,在和UETNAP之间为了满足上述用途，需要将密钥分离，应使用图6中的密钥层次结构。Kis密钥用于建立IPSeeSAs,Kcx密钥用于建立接入安全。 wucurww步骤1`10:在5GC上初始注册。步骤2)N5CW设备应提供其网络接入标识(NAT),可信WLAN接入点(TWAP)选择可信ULAN互通功能(TWIF),例如基于接收到的地址域，并向选中的TWIF发送A请求。YD/T3628-2019的6.12.2中的规定构建。数，对于不支持5GNAS的N5CW设备，这些参数都是相同的。注册类型表示为“初始注册”步骤4)TWIF应选择AMF(例如：如果由N5CW设备提供，则使用NAI中的5G-GUTI),并应向AMF发步骤5)如果AF收到SUCI,则AMF通过向AUSF发送Nausf_UEAuthentication_Authenticate请求消息触发认证流程。Nausf_UEAuthentication_AuthenticateRequest消息中携带SUCI信息。步骤6)AUSF应向UDM发送Nudm_UEAuthentication_Get请求，其中包含SUCI步骤7)收到Nudm_UEAuthentication_Get请求后，如果其中包含SUCI,则UDM调用SIDF。在UDM处理请求之前，SIDF应解码SUCI以获得SUPI.步骤8)为了执行N5CW设备和归属网络之间的相互认证，将会触发EAP-AKA'流程。EAP-AKA”发生在N5CW设备和AISF之间。在N2接口中，EAP消息封装在NASAuthentication消息中。N5CW设备和WIF之间交换的EAP-AKA消息应封装在层2数据包中，比如IEEE802.3/802.1x数据包，IEEE802.11/802.1x数据包，PPP数据包等。步骤9)该场景不需要NAS安全上下文。AMF应根据YD/T3628-2019的附录A.9中的规定，使用接收到的Km密钥推导出Kmm密钥。AF和TWIF之间的NAS安全建立与未认证的紧急呼叫类似，即使用NULL加密和NULL完整性保护。步骤10a)MF应向TWIF发送MAS安全模式命令。NAS安全模式命令应包含EAP-Success消息和NUL安全算法步骤10b)TWIF不应直接将EAP-Success转发给N5CW,而是存储EAP-Success消息，等特Kmp.步骤10c)WIF应向AF发送NAS安全模式完成消息步骤11)AF发送N2初始上下文建立请求，并向TWIF提供Km密钥。步骤12)TWIF应按照附录A.1中的规定，使用Kmn密钥推衍出TNAP密钥Krww,并将TNAP密钥和EAP-Success消息发送到可信WLAN接入点。再通过可信WLAN接入点将EAP-Success消息转发给N5CW设备。TNAP密钥与PIK(成对主密钥)相对应，PMK根据IEEE802.11中的规范，保护WLAN空口通信。为了将N5CW设备的所有用户面流量传输到TWIF,可信WLAN接入点与TWIF之间需要建立层2或层3连接，此连接随后绑定到为此N5CW设备创建的N3连接。步骤13)TWIF应向AMF发送X2初始上下文建立响应消息。步骤14)后续步骤参见3GPPTS23.502v16.10.04.12b.2的要求。7.3有线接入50核心网安全为了支持5G系统的无线和有线融合，在架构规范3GPPTS23.501中引入了两个新的网络实体：5G-RG作为5GUE,可以通过有线接入网(W-5GAN)或固定无线接入网(FWA)接入5GC。重用本文中定义的安全流程。FN-RG可以通过有线接入网(W-5GAN)接入5GC,7-AGF代表FN-RG完成注册流程。作为N1的终结点，支持5G的UE可以通过RG接入5CC,BG通过有线接入网(W-5GAN)或NG-RAN接入5GC。UE支持非可信非蜂窝接入或可信非蜂窝接入。5G-RG可以通过W-5GAN、NG-RAN或同时使用两种册流程在3GPPTS23.316v16.9.0的4.11中规定。5G-RG通过W-5GAN连接到5GC的注册流程在3GPPTS23.316v16.9.0的7.2.1中规定。步骤4)W-AGF应按照3GPPTS23.316中的规定选择AMF。然后，W-AGF应在N2初始UE消息中将从UE接收的注册请求转发给选择的AMF。步骤5)如YD/T3628-2019的6.4.6所述，如果AMF收到5G-GUTI,并且注册受到完整性保护，则AMF可以使用安全上下文验证完整性保护。如果5G-RG已经通过NGRAN注册到同一个AMF,井且AMF第一次通过有线接入接收到UE的NAS信令，则用于完整性验证的对应ULNASCOUNT的值为0。否则，可以使用现有的非3GPP特定的ULNASCOUNT进行完整性验证。如果完整性验证成功，则5G-RG通过AMF认证。如果完整性验证成功，且NG-RAN上没有激活新的安全上下文，则可跳过步骤8至步骤11。如果完整性验证成功，并且新的安全上下文已经通过NG-RAN激活，则认证可能被跳过，但AMF应使用NASsWC流程激活新的上下文，如步骤8及以后所述。否则，AMF需要对5G-RG进行认证。如果AMF决定对5G-RG进行认证，则应使用YD/T3628-2019的6.1.3中的一种方法。在这种情况下，AMF应向AUSF发送密钥请求。ALSF可以发起YD/T3628-2019的6.1.3中规定的认证流程。AMF和UE之间，认证数据包封装在MAS认证消息中，NAS认证消息承载在AMF和W-AGF之间的N2信令中，然后封装在W-AGF和UE之间的EAP-5G/5G-NAS数据包中。在来自归属网络的最终认证消息中，AUSF将从Kns推衍的锚密钥K发送给SEAF。SEAF将从K推衍Kaw,并发送给AMF,AMF用于推衍MAS安全密钥。如果如YD/T3628-2019的6.1.3.1所述，EAP-AKA'被用于验证，则AUSF应包含EAP-Success。5G-BG也推衍锚密钥Kp,并从Kgw推衍Km,然后从Ku推步骤6)AMF应向UE发送安全模式命令(SMC),以激活与NAS连接标识符”0x02”相关联的MAS安EAP-Sucess封装在SMC消息中。步骤7)W-AGF应在EAP-Request/5C-MAS数据包内将NASSMC转发给5G-RG。步骤8)W-AGF通过N2接口将包含NASsWCConplete的NAS数据包转发给AMF。步骤9)AMF收到在来自UE的MASSWCComplete消息后或完整性保护验证成功后，就发起NGAP流程用于建立AN上下文。AMF应使用与YD/T3628-2019的附录A.9中定义的NAS连接标识符“0x02”相关联的上行NASCOUNT计算W-AGF密钥Kgww,该密钥相当于密钥Kc。步骤10)AMF在收到NAS安全模式完成时，应向W-AGF发送N2初始上下文建立请求消息。消息中包步骤11)W-AGF在收到NGAP初始上下文建立请求消息后，将发送EAP-Success/EAP-5G到5G-RG。这会使EAP-5G会话结束，并不再进十步交换LAP-5G数据包。步骤12)W-AGF在收到AMF发送的MS注册接受消息后，通过建立的W-CP将该消息转发给5G-RG。UE和W-AGF之间的所有进一步的MAS消息都将通过已建立的W-CP发送由于FN-RG是BBF或CableLabs定义的非无线实体，因此不支持N1。W-AGF代表FN-RC提供N1连接。认证方法在FN-RG和AUSF之间执行，如图9所示。W-AGF可以对FN-RG进行认证，这由本地策略控制。假设管理W-5GAN的有线运营商与管理5GC的PLMN运营商之间存在信任关系。AMF信任W-5GAN,基于在AMF与W-5GAN之间使用NS/IP或DTLS建立安全时执行的相互认证。authenticatedyw.*步骤11)检查指示并确认不需要归属网络认证后，AMF应建立AMF和W-AGF之间的NAS安全，采用NILL加密和NUL1.完整性保护。步骤12)AMF应向W-AGF发送注册接受消息，该消息包含5G-GUTI和其他参数。连接到5G-RG或FN-RG的UE可以通过N3IWF或TNGF接入5GC。FN-RG后的UE可以使用3GPPTS23.502v16.10.04.1.2.2.2中定义的非可信非峰窝接入流程，通过N3IWF接入5GC.5G-RG后的UE可以使用3GPPTS23.502v16.10.04.12.2.2中定义的非可信非蜂窝接入，也可以使用3GPPTS23.502v16.10.04.12a.2.2中定义的可信非蜂窝接入当UE使用非可信的非蜂窝接入时，UE的认证方式参见YD/T3628-2019的7.2.1。当UE使用可信的非蜂窝接入时，UE的认证如7.2.2.1中所述。7.3.5有线接入的用户隐私在YD/T3628-2019的5.2.5、6.12和附录C中关于用户隐私的要求和流程适用于5G-RG。如3GPPTS23.316v16.9.04.7.3和4.7.4中所述，对于代表FN-RG的W-AGF,应使用空方案构造7.3.6N5CW基于可信WLAN接入的用户隐私YD/T3628-2019的5.2.5、6.12和附录C中关于UE用户隐私的要求和流程适用于N5CW。8接入回传一体化安全要求本章描述了适用于NR接入回传一体化(IAB)架构和功能实体的安全流程，以支持NR基站的无线回传。3GPPTS23.501和3GPPTS38.401描述了接入回传一体化架构和功能实体的相关内容3GPPTS33.401中定义了FN-DC中应用于接入回传一体化的安全要求和安全流程。8.2安全要求和功能IAB节点(IAB-UE)应支持IAB节点(IAB-UE)与支持接入回传一体化架构的5GC之间的NAS信令的加密，完整性保护和重放保护。IAB节点(IAB-UE)应支持IAB节点(IAB-UE)与IAB归属节点之间的RRC信令的加密，完整性保护和重放保护。应支持IAB节点(IAB-UE)与支持接入回传一体化架构的5GC之间的相互认证。8.2.2对IAB归属节点的要求IAB归属节点应支持IAB归属节点与IAB节点(IAB-UE)之间的RRC信令的加密，完整性保护YD/T××和重放保护。8.2.3对支持接入回传一体化架构的5G0的要求支持接入回传一体化架构的5GC应支持IAB节点(IAB-UE)与支持接入回传一体化架构的5GC之间的NAS信令的加密，完整性保护和重放保护。应支持接入回传一体化架构的5GC与IAB节点(IAB-LE)之间的相互认证。5GC应决定是否授权IAB节点作为IAB节点(gNB-DU)运行。8.2.4对于安全环境的要求IAB节点(gNB-DU)和IAB归属节点的安全环境应满足YD/T3628-2019中5.3.8的要求。IAB节点(gNB-DU)和IAB-donor-CU之间的F1接口应满足的YD/T3628-2019中5.3.9的要求。8.3IAB节点集成流程IAB节点由UE功能(称为IAB-UE)和gNB-DU功能[2]组成。IAB集成流程包括3GPPTS38.401中详细介绍的3个阶段。身份向网络执行注册流程，以便向5GC进行注册，因此，IAB节点和5GC之间建立了MAS和AS安全。中使用安全RRC信令建立和配置的，以支持IAB节点与IAB归属节点之间的路由c)gNB-DU部分建立(阶段3):I阶段1使得IAB-UE注册，因此，在IAB归属节点和IAB节点之间建立了AS安全：阶段2使用已建立的AS安全对IAB节点进行了安全配置，阶段3建立了IAB归属节点和IAB节点之间的安全F18.3.2IAB节点的身份认证和授权(阶段1)IAB-UE功能应充当UE,并应重用YD/T3628-2019中指定的UE进行主认证，密钥推衍和分发机制，签约凭证存储要求，NAS安全和AS安全等流程。注1:对于独立部署场景，YD/T3628-2019附录B描述了如何使用其他EAP方法IAB节点的授权应由在3GPPTS23.501中描述的支持1AB架构的5G核心网执行。8.3.3IAB节点(gNB-DU)和IAB-donor-CU(阶段3)之间F1接口安全机制本章节描述了适用于IAB节点(gNB-DU)和IAB-donor-CU之间的F1接口的要求8.3.3.2F1接口的安全机制F1接口将IAB节点(gNB-DU)连接到IAB-donor-CU.它由用于控制面的F1-C和用于用户面的F1-U组成。使用YD/T3628-2019中9.8.2规定的F1接口安全机制来建立IAB的F1