YD/T 2909-2015
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 2909-2015.Mobile network domain security authentication framework.
1范围
YD/T 2909适用于使用NDS/IP或者TLS的网元(NE)的认证。
对于3GPP TS 33.210中所述的NDS/IP，本标准包括在相应Za接口的安全网关(SEG)的认证和在Zb接口的网元之间以及网元和安全网关之间的认证。运营商域内的网络设备(即网元和安全网关)的认证是运营商内部的事情，这与3GPPTS 33.210中规定一致,即强制部署Za接口，运营商自己决定是否配置Zb接口，因为Zb接口为可选。如果是在相同运营商的两个安全域之间的Za接口或者Zb接口，证书的有效性可能受限于运营商的域。
注:假如两个安全网关是同一个管理中心(例如，由相同移动运营商拥有)下两个不同网络域的相互连接，那么还是需要部署Za接口，但是Za接口的使用由运营商决定。
基于IP协议的NDS架构如图1所示:
2规范性引用文件
下列文件对于本文件的应用必不可少。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
3GPP TR 21.905 Vocabulary for 3GPP Specifications 3GPP规范的词汇表
3GPP TS 33.203 Access security for IP-based services 基于IP业务的接入安全
1范围
YD/T 2909适用于使用NDS/IP或者TLS的网元(NE)的认证。
对于3GPP TS 33.210中所述的NDS/IP，本标准包括在相应Za接口的安全网关(SEG)的认证和在Zb接口的网元之间以及网元和安全网关之间的认证。运营商域内的网络设备(即网元和安全网关)的认证是运营商内部的事情，这与3GPPTS 33.210中规定一致,即强制部署Za接口，运营商自己决定是否配置Zb接口，因为Zb接口为可选。如果是在相同运营商的两个安全域之间的Za接口或者Zb接口，证书的有效性可能受限于运营商的域。
注:假如两个安全网关是同一个管理中心(例如，由相同移动运营商拥有)下两个不同网络域的相互连接，那么还是需要部署Za接口，但是Za接口的使用由运营商决定。
基于IP协议的NDS架构如图1所示:
2规范性引用文件
下列文件对于本文件的应用必不可少。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
3GPP TR 21.905 Vocabulary for 3GPP Specifications 3GPP规范的词汇表
3GPP TS 33.203 Access security for IP-based services 基于IP业务的接入安全
标准图片预览
标准内容
ICS33.030
中华人民共和国通信行业标准
YD/T2909-2015
移动通信网络域安全认证框架
Mobilenetwork domain security authenticationframework(3GPPTS33.310V9.5.0,NetworkDomainSecurity(NDS)AuthenticationFramework(AF),IDT)2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
1范围
2规范性引用文件
3术语、定义、缩略语和符号·
3.1术语和定义·
3.2缩略语和符号…
4公钥基础设施（PKI）介绍..
4.1手动交叉认证·
4.2桥CA的交叉认证
5NDS/AF的架构与使用场景
5.1NDS/AF的PKI架构·
5.2应用场景
6配置·
证书配置·
6.1aCRL配置·
6.2IKE协商与配置
6.2aTLS配置·
路径确认·
7架构与机制的详细描述
7.1知识库
生命周期管理
交叉证书..
废除SEG/TLSCA交叉证书..
7.5在NDS/IP端实体之间Za接口上使用IKE建立安全连接使用TLS建立安全连接：
7.5b在NDS/IP实体之间Zb接口上建立安全连接7.6CRL管理·
8对于NDS/IP网元和安全网关的后向兼容性9基站的证书注册过程
架构·
安全机制
YD/T2909-2015
YD/T2909-2015
9.4证书简介
9.5CMPv2简介
9.6CMPv2传输
附录A（规范性附录）重要和非重要的证书扩展·附录B（资料性附录）对简单信任模型的决定附录C（资料性附录）SEGs的CRL库接入协议·附录D（资料性附录）在CR中存储交叉证书的结论：附录E（资料性附录）TLS协议的规格附录F（资料性附录）
TLS证书手动处理
初始登记的样本CMPv2信息流…
附录G（资料性附录）
本标准按照GB/T1.12009给出的规则起草。YD/T2909-2015
本标准使用翻译法等同采用3GPPTS33.310V9.5.0“网络域安全：认证框架”（NetworkDomainSecurity(NDS),AuthenticationFramework(AF))请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：华为技术有限公司、中国信息通信研究院、中国移动通信集团公司、中国联合网络通信集团有限公司、上海贝尔股份有限公司、诺基亚西门子通信（上海）有限公司。本标准主要起草人：崔洋、黄迎新、胡志远、崔媛媛、齐曼鹏、张尼、陆伟。III
YD/T2909-2015
在移动通信系统中，越来越多的网元设备和接口需要安全机制加以保护，其中，特别是对于可灵活扩展的实体认证框架(AF)有着日趋迫切的需求。本标准为移动通信网提供了一种高度可扩展的身份认证框架。该框架遵循网络域安全研究的前后关系，有效地聚焦于核心网实体的控制面，因此AF可以为所有使用NDS/IP的网络节点提供有效安全的实体认证。此外，基于可信模型的可行性分析与效果预测，本标准还对AF实施所涉及的协议与证书特性也相应加以分析整理。依据上述分析得出安全认证框架的具体实施条件，以使电信运营商可以结合IP安全技术（IPsec）与公钥基础设施技术（PKI）来提供对网络域节点的有效保护。具体的，本标准描述了移动通信网的网络域安全认证框架，包括PKI交叉认证、CA证书管理（包括申请、创建、吊销、更新）、网元实体证书管理、网元设备CA管理和基站的证书自动申请等。V
1范围
移动通信网络域安全认证框架
本标准适用于使用NDS/IP或者TLS的网元(NE)的认证。YD/T2909-2015
对于3GPPTS33.210中所述的NDS/IP，本标准包括在相应Za接口的安全网关（SEG）的认证和在Zb接口的网元之间以及网元和安全网关之间的认证。运营商域内的网络设备（即网元和安全网关）的认证是运营商内部的事情，这与3GPPTS33.210中规定一致，即强制部署Za接口，运营商自已决定是否配置Zb接口，因为Zb接口为可选。如果是在相同运营商的两个安全域之间的Za接口或者Zb接口，证书的有效性可能受限于运营商的域。注：假如两个安全网关是同一个管理中心（例如，由相同移动运营商拥有）下两个不同网络域的相互连接，那么还是需要部署Za接口，但是Za接口的使用由运营商决定。基于IP协议的NDS架构如图1所示：安全域A
IKE“连接”
ESP随道
安全域B
图13GPPTS33.210中基于IP协议的NDS架构对于TLS，本标准集中于运营商之间的链路的TLS实体的认证。例如，对于IMS和非IMS网络3GPPTS33.203和在3GPPTS33.220里的Zn接口上的运营商间的通信，TLS有详细说明。运营商内链路的TLS实体的认证视为运营商内部的事情。然而，当所有的TLS网元和PKI基础设施属于同一个运营商时，NDS/AF很容易适配到运营商内部的使用场景，因为这只是运营商之间使用场景的简化。证书的有效性受限于运营商的域。一个附录包括关于TLS证书手动处理的信息，以防基于TLS的NDS/AF，不能实现自动登记和撤销。
2规范性引用文件
下列文件对于本文件的应用必不可少。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。3GPPTR21.905
Vocabularyfor3GPPSpecifications3GPP规范的词汇表
YD/T2909-2015
3GPPTS33.203
3GPPTS33.210
3GPPTS33.220
IETFRFC1035
IETFRFC1981
IETFRFC2252
IETFRFC2560
IETFRFC2817
IETFRFC2818
IETFRFC2986
IETFRFC3749
IETFRFC4210
IETFRFC4211
IETFRFC4346
IETFRFC 4945
IETFRFC5246
IETFRFC5280
IETFRFC5922
IETFRFC5924
Access security for IP-based services3rd Generation Partnership Project,TechnicalSpecification Group Services and System Aspects;3G Security; Network domain security; IP networklayer security
Generic Authentication Architecture: GenericBootstrapping Architecture
Domain Names-Implementation and SpecificationPath MTU Discovery for IP version 6Lightweight Directory Access Protocol (v3):Attribute Syntax DefinitionsX.509 Internet Public Key Infrastructure OnlineCertificate Status Protocol-OCSPUpgrading to TLS Within HTTP/1.1HTTP Over TLS
PKCS#10 Certification Request SyntaxSpecification Version 1.7
Transport Layer Security Protocol CompressionMethods
Internet X.509 Public Key InfrastructureCertificate Management ProtocolInternet X.509 Public Key InfrastructureCertificate Request Message Format (CRMF)The Transport Layer Security (TLS) ProtocolVersion 1.1
The Internet IP Security PKI Profile ofIKEv1/ISAKMP,IKEv2,andPKIX
The Transport Layer Security (TLS) ProtocolVersion1.2
Internet X.509Public Key InfrastructureCertificate and Certificate Revocation List (CRL)Profile
Domain Certificates in the Session InitiationProtocol (SIP)
Extended Key Usage (EKU) for Session InitiationProtocol (SIP) X.509 Certificates基于IP业务的接入安全
网络域安全：IP网络层安全
通用认证框架：通用自举架构
一实现和规范
IPv6的路径MTU发现
轻量级目录访问协议：属性
语法定义
X.509因特网公钥基础设施
在线证书状态查询协议
HTTP/1.1升级到TLS
基于TLS的HTTP
证书请求语法规范
传输层安全协议的压缩方式
互联网X.509公钥基础设施
证书管理协议
X.509公钥基础设施证书请
求消息格式
传输层安全TLSv1.1
IKEv1/ISAKMP、IKEv2和
PKIX的互联网IP安全PKI
传输层安全TLSv1.2
X.509因特网公钥基础设施
证书及证书撤销列表
会话初始化协议中的域证书
会话初始化协议中X.509证
书的扩展的密钥使用
IETFRFC6712
PKI基础
InternetX.509PublicKeyInfrastructure--HTTPTransfer for the Certificate Management Protocol(CMP)
PKI basics -A Technical Perspective\, November2002,http://oasis-pki.org/pdfs/PKIBasics-A technical perspective.pdf
3术语、定义、缩略语和符号
3.1术语和定义
3GPPTR21.905列出的及下列术语和定义适用于本文件。3.1.1
互连认证中心InterconnectionCAYD/T2909-2015
X.509公钥基础设施一HTTP
CMP传输协议
技术前景
个特殊运营商颁发交叉证书给与该运营商相互连接的其他域的SEGsCAS。3.1.2
互连协议InterconnectionAgreement由两个运营商建立安全通信的协议。这是出于保护运营商之间不同形式通信的目的，例如：GPRS漫游、MMS相互连接、WLAN漫游和IMS相互连接。3.1.3
本地证书库LocalCR
存有交叉证书的证书库。
本地证书撤销列表LocalCRL：
包含交叉证书撤销列表的列表。3.1.5
预共享密钥Pre-SharedKey
NDS/IP中SEG之间的IKE使用的认证方法。3.1.6
公共证书撤销列表PublicCRL
包含SEG撤销列表和CA证书的列表，且能被其他运营商访问。3.1.7
安全网关认证中心SEGCA
在一个特殊运营商域内给SEGs颁发证书的认证中心。3.2缩略语和符号
下列缩略语和符号适用于本文件。AF
Authentication Framework
Certification Authority
Certificate Repository
Certificate Revocation List
认证框架
认证中心
证书库
证书撤销列表
YD/T2909-2015
GenericBootstrappingArchitectureIP Multimedia Subsystem IP
Network Domain Security下载标准就来标准下载网
Public Key Infrastructure
Proof Of Possession
Pre-Shared Key
RegistrationAuthority
Security Gateway
Virtual Private Network
通用自举架构
多媒体子系统
网络域安全
公钥基础设施
证明所有权
预共享密钥
注册中心
安全网关
虚拟专用网络
InterfacebetweenSEGsbelongingtodifferent不同网络或安全域之间的安全网关的接口（该接口可能在同一个运营商内networks/security domains(a Za interfacemaybean intraoran interoperatorinterface)部，也可能在不同运营商之间
InterfacebetweenSEGsandNEsandinterface同一网络或同一安全域之间的安全网betweenNEswithinthesamenetwork/security关的接口和网元及网元之间的接口domain
4公钥基础设施（PKI）介绍
PKI论坛的“PKI基础技术前景”对PKI技术进行了简单中立的介绍。因此，在介绍部分只描述了交叉认证的两个方面。
交又认证是在两个认证中心之间建立信任关系的一个过程。在认证中心B交叉认证认证中心A时认证中心A已经选择由认证中心B颁发的可信的证书。交叉认证过程使处于两个认证中心下的用户信任由对方认证中心颁发的证书。在本标准中，信任等同于能够认证。4.1手动交叉认证
相互的交叉认证直接建立在两个认证中心之间。这个方法常称之为手动交叉认证。在手动交叉认证中，认证中心在本地决定信任。当认证中心A选择信任认证中心B时，认证中心A签署认证中心B的证书，并且在本地分发这个新证书（由A签名的B的证书）这种方法的缺点是，它常常会导致出现这样的场景：做出信任决定的实体需要获得很多证书/对于每一个本地认证中心愿意信任的安全域，需要有一个由本地认证中心签名的证书。然而，所有的证书都能在本地配置，且在本地签名，因此，证书管理非常灵活。4.2桥CA的交叉认证
桥CA能减少为用于证书校验的实体所配置的证书数量。当两个认证中心通过桥CA做相互交叉认证时，该两个认证中心不必知道彼此，能信任彼此，因为在这种模型中，信任是具有传递性的（A信任桥CA，桥CA信任B，因此A信任B，反之亦然）。桥CA在认证中心之间表现得就像一个桥。但是，两个认证中心应信任桥CA会做正确的事情。所有关于信任的决定都能委派给桥CA，桥CA在一些使用场合是再好不过的。如果桥CA决定交叉认证一个认证中心M，以前交叉认证过的认证中心自动开始信任M。在所有实体共享一个公共的认证中心场景中，桥CA形式的交叉非常实用。如果一个认证中心需要对来自桥CA的信任或接入控制进行限制，那么该认证中心还需额外执行这些限制条件。4
5NDS/AF的架构与使用场景
认证中心类型的定义如下：
YD/T2909-2015
一安全网关的认证中心（SEGCA）：一个CA给指定运营商域内的安全网关颁发证书。一网络实体的认证中心(NECA)：一个CA给指定运营商域内的网络实体颁发IPsec证书，而且这些证书只限定使用于Zb接口（Zb：网络域内的实体之间或网络域实体与安全网关之间的接口）。一TLS客户端认证中心(TLSclientCA)：一个CA给指定运营商域内的TLS实体颁发TLS客户端证书。
一TLS服务器认证中心(TLSserVerCA)：一个CA给指定运营商域内的TLS实体颁发TLS服务器证书。
互连认证中心（InterconnectionCA）：一个CA代表一个指定运营商将交叉证书颁发给其它域内的SEGCA，TLS客户端CA以及TLS服务器CA，使用这些交叉证书能实现运营商的SEGs、TLS实体的互连。
互连CA的公钥安全地存储在运营商域内的各个SEG和TLS实体中，这就能够使SEG和TLS实体相互验证交叉证书。假设每个运营商域内包含几十个而不是几百个SEG或TLS实体。运营商可以将两个或两个以上的如上所述的CA合并。比如，同一个CA可以用来颁发实体TLS证书以及IPsec证书。另外，同一个CA也可以用来颁发实体证书和交叉证书。NDS/AF最初是基于一个简单的信任模型（参见附录B），该模型避免引入传递性信任或/和额外认证信息。该简单模型隐含手动的交叉认证。5.1NDS/AF的PKI架构
本条定义了NDS/AF的PKI架构。目标是定义一个灵活且简单的架构，并能做到与其它实现方式进行互操作。
如下描述的架构使用了简单接入控制方法，即每一个经过认证的实体都将得到服务。可能会实现更加精细的接入控制，但这不属于本标准的研究范围。本架构不依赖于桥CA，而是在不同安全域之间直接使用交叉证书，这使SEG和TLS实体中的策略配置变得更加简便。
5.1.1总体架构
除非运营商选择合并多个CA，否则每个安全域至少要有一个SEGCA，NECA，TLS客户端CA或TLS服务器CA，以及一个专属于运营商的互连CA。一个域中的SEGCA将证书颁发给该域内的SEGs，这些SEGs与其它域内的SEGs存在相互连接，即Za接口。SEG证书也可以用在Zb接口上与NE进行相互通信。NECA将证书颁发给NEs，用来实现NE之间的通信以及NE与可信任域内的SEGs之间的通信，即Zb接口。TLS客户端CA将证书颁发给该域内需要与其它域内的TLS服务器建立TLS连接的TLS用户。TLS服务器CA将证书颁发给域内需要与其它域内的TLS用户建立TLS连接的TLS服务器。互连CA将证书颁发给SEGCAs、TLS客户端CAs或与本域内的SEG、TLS客户端存在相互连接的其它域内TLS服务器CAs。本标准描述了需要的各种证书的总体配置（profile），同时也描述了一种生成交叉证书的方法。总体而言，所有的证书都应基于IETFRFC5280。5.1.1.1NDS/IP场景
YD/T2909-2015
以下描述了使用SEGCAs颁发IPsec证书的架构。SEGCA应该将证书颁发给使用Za接口的安全网关。当安全域A中的SEG与安全域B中的SEG建立安全连接时，它们应当能相互认证。相互认证是由SEGCAs颁发给SEGs的证书来实现的。当各个域间建立互连时，互连CA就交叉认证了对等运营商的SEGCA。生成的交叉证书需要本地配置于每个域中。对于安全域A中的与安全域B间存在Za接口的SEG来说，由安全域A的互连CA为安全域B的SEGCA生成的交叉证书应该有效且可用。同样的，对于安全域B中的与安全域A间存在Za接口的SEG来说，由安全域B的互连CA为安全域A的SEGCA生成的交叉证书应该有效且可用。基于IPsec证书来认证SEGs和NEs的总体架构如图2所示。注：为了避免重复，一个潜在的CA在图2中并没有表现出来。安全域A
Interconnection
SEGCAA
IKE“连费
ESP隧进
国发证书
安全域B
Interconnection
SEGCAB
图2NDS/IP场景下信任校验路径
交叉认证之后，SEGa就能确认路径：SEGb->SEGCAB->互连CAA。安全域A内的所有实体只信任安全域A内的互连CA颁发的证书。同样地，SEGb能确认路径：SEGa->SEGCAA->互连CAB该路径在安全域B内可确认，因为路径终止于一个可信任的证书（安全域B的互连CAB）。互连CA路径中的第二张证书进行签名。例如，在安全域A中，SEGCAB的证书是由安全域A中的互连CA在执行交叉认证时进行签名。5.1.1.2TLS场景
以下描述了使用TLSCAS颁发TLS证书的架构。TLS客户端CA应该将证书颁发给其安全域内的TLS用户。同样地，TLS服务器CA应将证书颁发给其域内的TLS服务器。当安全域A中的TLS实体与安全域B中的TLS实体建立安全连接时，它们应当能相互认证。互认证是由TLS客户端/服务器CAs颁发给TLS实体的证书来实现。当各个域间建立互连时，互连CA就交叉认证了对等运营商的TLS客户端/服务器CAS。生成的交叉证书只需要本地配置于每个域中。对于安全域A中需要与安全域B连接的TLS实体来说，由安全域A的互连CA为安全域B6
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国通信行业标准
YD/T2909-2015
移动通信网络域安全认证框架
Mobilenetwork domain security authenticationframework(3GPPTS33.310V9.5.0,NetworkDomainSecurity(NDS)AuthenticationFramework(AF),IDT)2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
1范围
2规范性引用文件
3术语、定义、缩略语和符号·
3.1术语和定义·
3.2缩略语和符号…
4公钥基础设施（PKI）介绍..
4.1手动交叉认证·
4.2桥CA的交叉认证
5NDS/AF的架构与使用场景
5.1NDS/AF的PKI架构·
5.2应用场景
6配置·
证书配置·
6.1aCRL配置·
6.2IKE协商与配置
6.2aTLS配置·
路径确认·
7架构与机制的详细描述
7.1知识库
生命周期管理
交叉证书..
废除SEG/TLSCA交叉证书..
7.5在NDS/IP端实体之间Za接口上使用IKE建立安全连接使用TLS建立安全连接：
7.5b在NDS/IP实体之间Zb接口上建立安全连接7.6CRL管理·
8对于NDS/IP网元和安全网关的后向兼容性9基站的证书注册过程
架构·
安全机制
YD/T2909-2015
YD/T2909-2015
9.4证书简介
9.5CMPv2简介
9.6CMPv2传输
附录A（规范性附录）重要和非重要的证书扩展·附录B（资料性附录）对简单信任模型的决定附录C（资料性附录）SEGs的CRL库接入协议·附录D（资料性附录）在CR中存储交叉证书的结论：附录E（资料性附录）TLS协议的规格附录F（资料性附录）
TLS证书手动处理
初始登记的样本CMPv2信息流…
附录G（资料性附录）
本标准按照GB/T1.12009给出的规则起草。YD/T2909-2015
本标准使用翻译法等同采用3GPPTS33.310V9.5.0“网络域安全：认证框架”（NetworkDomainSecurity(NDS),AuthenticationFramework(AF))请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：华为技术有限公司、中国信息通信研究院、中国移动通信集团公司、中国联合网络通信集团有限公司、上海贝尔股份有限公司、诺基亚西门子通信（上海）有限公司。本标准主要起草人：崔洋、黄迎新、胡志远、崔媛媛、齐曼鹏、张尼、陆伟。III
YD/T2909-2015
在移动通信系统中，越来越多的网元设备和接口需要安全机制加以保护，其中，特别是对于可灵活扩展的实体认证框架(AF)有着日趋迫切的需求。本标准为移动通信网提供了一种高度可扩展的身份认证框架。该框架遵循网络域安全研究的前后关系，有效地聚焦于核心网实体的控制面，因此AF可以为所有使用NDS/IP的网络节点提供有效安全的实体认证。此外，基于可信模型的可行性分析与效果预测，本标准还对AF实施所涉及的协议与证书特性也相应加以分析整理。依据上述分析得出安全认证框架的具体实施条件，以使电信运营商可以结合IP安全技术（IPsec）与公钥基础设施技术（PKI）来提供对网络域节点的有效保护。具体的，本标准描述了移动通信网的网络域安全认证框架，包括PKI交叉认证、CA证书管理（包括申请、创建、吊销、更新）、网元实体证书管理、网元设备CA管理和基站的证书自动申请等。V
1范围
移动通信网络域安全认证框架
本标准适用于使用NDS/IP或者TLS的网元(NE)的认证。YD/T2909-2015
对于3GPPTS33.210中所述的NDS/IP，本标准包括在相应Za接口的安全网关（SEG）的认证和在Zb接口的网元之间以及网元和安全网关之间的认证。运营商域内的网络设备（即网元和安全网关）的认证是运营商内部的事情，这与3GPPTS33.210中规定一致，即强制部署Za接口，运营商自已决定是否配置Zb接口，因为Zb接口为可选。如果是在相同运营商的两个安全域之间的Za接口或者Zb接口，证书的有效性可能受限于运营商的域。注：假如两个安全网关是同一个管理中心（例如，由相同移动运营商拥有）下两个不同网络域的相互连接，那么还是需要部署Za接口，但是Za接口的使用由运营商决定。基于IP协议的NDS架构如图1所示：安全域A
IKE“连接”
ESP随道
安全域B
图13GPPTS33.210中基于IP协议的NDS架构对于TLS，本标准集中于运营商之间的链路的TLS实体的认证。例如，对于IMS和非IMS网络3GPPTS33.203和在3GPPTS33.220里的Zn接口上的运营商间的通信，TLS有详细说明。运营商内链路的TLS实体的认证视为运营商内部的事情。然而，当所有的TLS网元和PKI基础设施属于同一个运营商时，NDS/AF很容易适配到运营商内部的使用场景，因为这只是运营商之间使用场景的简化。证书的有效性受限于运营商的域。一个附录包括关于TLS证书手动处理的信息，以防基于TLS的NDS/AF，不能实现自动登记和撤销。
2规范性引用文件
下列文件对于本文件的应用必不可少。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。3GPPTR21.905
Vocabularyfor3GPPSpecifications3GPP规范的词汇表
YD/T2909-2015
3GPPTS33.203
3GPPTS33.210
3GPPTS33.220
IETFRFC1035
IETFRFC1981
IETFRFC2252
IETFRFC2560
IETFRFC2817
IETFRFC2818
IETFRFC2986
IETFRFC3749
IETFRFC4210
IETFRFC4211
IETFRFC4346
IETFRFC 4945
IETFRFC5246
IETFRFC5280
IETFRFC5922
IETFRFC5924
Access security for IP-based services3rd Generation Partnership Project,TechnicalSpecification Group Services and System Aspects;3G Security; Network domain security; IP networklayer security
Generic Authentication Architecture: GenericBootstrapping Architecture
Domain Names-Implementation and SpecificationPath MTU Discovery for IP version 6Lightweight Directory Access Protocol (v3):Attribute Syntax DefinitionsX.509 Internet Public Key Infrastructure OnlineCertificate Status Protocol-OCSPUpgrading to TLS Within HTTP/1.1HTTP Over TLS
PKCS#10 Certification Request SyntaxSpecification Version 1.7
Transport Layer Security Protocol CompressionMethods
Internet X.509 Public Key InfrastructureCertificate Management ProtocolInternet X.509 Public Key InfrastructureCertificate Request Message Format (CRMF)The Transport Layer Security (TLS) ProtocolVersion 1.1
The Internet IP Security PKI Profile ofIKEv1/ISAKMP,IKEv2,andPKIX
The Transport Layer Security (TLS) ProtocolVersion1.2
Internet X.509Public Key InfrastructureCertificate and Certificate Revocation List (CRL)Profile
Domain Certificates in the Session InitiationProtocol (SIP)
Extended Key Usage (EKU) for Session InitiationProtocol (SIP) X.509 Certificates基于IP业务的接入安全
网络域安全：IP网络层安全
通用认证框架：通用自举架构
一实现和规范
IPv6的路径MTU发现
轻量级目录访问协议：属性
语法定义
X.509因特网公钥基础设施
在线证书状态查询协议
HTTP/1.1升级到TLS
基于TLS的HTTP
证书请求语法规范
传输层安全协议的压缩方式
互联网X.509公钥基础设施
证书管理协议
X.509公钥基础设施证书请
求消息格式
传输层安全TLSv1.1
IKEv1/ISAKMP、IKEv2和
PKIX的互联网IP安全PKI
传输层安全TLSv1.2
X.509因特网公钥基础设施
证书及证书撤销列表
会话初始化协议中的域证书
会话初始化协议中X.509证
书的扩展的密钥使用
IETFRFC6712
PKI基础
InternetX.509PublicKeyInfrastructure--HTTPTransfer for the Certificate Management Protocol(CMP)
PKI basics -A Technical Perspective\, November2002,http://oasis-pki.org/pdfs/PKIBasics-A technical perspective.pdf
3术语、定义、缩略语和符号
3.1术语和定义
3GPPTR21.905列出的及下列术语和定义适用于本文件。3.1.1
互连认证中心InterconnectionCAYD/T2909-2015
X.509公钥基础设施一HTTP
CMP传输协议
技术前景
个特殊运营商颁发交叉证书给与该运营商相互连接的其他域的SEGsCAS。3.1.2
互连协议InterconnectionAgreement由两个运营商建立安全通信的协议。这是出于保护运营商之间不同形式通信的目的，例如：GPRS漫游、MMS相互连接、WLAN漫游和IMS相互连接。3.1.3
本地证书库LocalCR
存有交叉证书的证书库。
本地证书撤销列表LocalCRL：
包含交叉证书撤销列表的列表。3.1.5
预共享密钥Pre-SharedKey
NDS/IP中SEG之间的IKE使用的认证方法。3.1.6
公共证书撤销列表PublicCRL
包含SEG撤销列表和CA证书的列表，且能被其他运营商访问。3.1.7
安全网关认证中心SEGCA
在一个特殊运营商域内给SEGs颁发证书的认证中心。3.2缩略语和符号
下列缩略语和符号适用于本文件。AF
Authentication Framework
Certification Authority
Certificate Repository
Certificate Revocation List
认证框架
认证中心
证书库
证书撤销列表
YD/T2909-2015
GenericBootstrappingArchitectureIP Multimedia Subsystem IP
Network Domain Security下载标准就来标准下载网
Public Key Infrastructure
Proof Of Possession
Pre-Shared Key
RegistrationAuthority
Security Gateway
Virtual Private Network
通用自举架构
多媒体子系统
网络域安全
公钥基础设施
证明所有权
预共享密钥
注册中心
安全网关
虚拟专用网络
InterfacebetweenSEGsbelongingtodifferent不同网络或安全域之间的安全网关的接口（该接口可能在同一个运营商内networks/security domains(a Za interfacemaybean intraoran interoperatorinterface)部，也可能在不同运营商之间
InterfacebetweenSEGsandNEsandinterface同一网络或同一安全域之间的安全网betweenNEswithinthesamenetwork/security关的接口和网元及网元之间的接口domain
4公钥基础设施（PKI）介绍
PKI论坛的“PKI基础技术前景”对PKI技术进行了简单中立的介绍。因此，在介绍部分只描述了交叉认证的两个方面。
交又认证是在两个认证中心之间建立信任关系的一个过程。在认证中心B交叉认证认证中心A时认证中心A已经选择由认证中心B颁发的可信的证书。交叉认证过程使处于两个认证中心下的用户信任由对方认证中心颁发的证书。在本标准中，信任等同于能够认证。4.1手动交叉认证
相互的交叉认证直接建立在两个认证中心之间。这个方法常称之为手动交叉认证。在手动交叉认证中，认证中心在本地决定信任。当认证中心A选择信任认证中心B时，认证中心A签署认证中心B的证书，并且在本地分发这个新证书（由A签名的B的证书）这种方法的缺点是，它常常会导致出现这样的场景：做出信任决定的实体需要获得很多证书/对于每一个本地认证中心愿意信任的安全域，需要有一个由本地认证中心签名的证书。然而，所有的证书都能在本地配置，且在本地签名，因此，证书管理非常灵活。4.2桥CA的交叉认证
桥CA能减少为用于证书校验的实体所配置的证书数量。当两个认证中心通过桥CA做相互交叉认证时，该两个认证中心不必知道彼此，能信任彼此，因为在这种模型中，信任是具有传递性的（A信任桥CA，桥CA信任B，因此A信任B，反之亦然）。桥CA在认证中心之间表现得就像一个桥。但是，两个认证中心应信任桥CA会做正确的事情。所有关于信任的决定都能委派给桥CA，桥CA在一些使用场合是再好不过的。如果桥CA决定交叉认证一个认证中心M，以前交叉认证过的认证中心自动开始信任M。在所有实体共享一个公共的认证中心场景中，桥CA形式的交叉非常实用。如果一个认证中心需要对来自桥CA的信任或接入控制进行限制，那么该认证中心还需额外执行这些限制条件。4
5NDS/AF的架构与使用场景
认证中心类型的定义如下：
YD/T2909-2015
一安全网关的认证中心（SEGCA）：一个CA给指定运营商域内的安全网关颁发证书。一网络实体的认证中心(NECA)：一个CA给指定运营商域内的网络实体颁发IPsec证书，而且这些证书只限定使用于Zb接口（Zb：网络域内的实体之间或网络域实体与安全网关之间的接口）。一TLS客户端认证中心(TLSclientCA)：一个CA给指定运营商域内的TLS实体颁发TLS客户端证书。
一TLS服务器认证中心(TLSserVerCA)：一个CA给指定运营商域内的TLS实体颁发TLS服务器证书。
互连认证中心（InterconnectionCA）：一个CA代表一个指定运营商将交叉证书颁发给其它域内的SEGCA，TLS客户端CA以及TLS服务器CA，使用这些交叉证书能实现运营商的SEGs、TLS实体的互连。
互连CA的公钥安全地存储在运营商域内的各个SEG和TLS实体中，这就能够使SEG和TLS实体相互验证交叉证书。假设每个运营商域内包含几十个而不是几百个SEG或TLS实体。运营商可以将两个或两个以上的如上所述的CA合并。比如，同一个CA可以用来颁发实体TLS证书以及IPsec证书。另外，同一个CA也可以用来颁发实体证书和交叉证书。NDS/AF最初是基于一个简单的信任模型（参见附录B），该模型避免引入传递性信任或/和额外认证信息。该简单模型隐含手动的交叉认证。5.1NDS/AF的PKI架构
本条定义了NDS/AF的PKI架构。目标是定义一个灵活且简单的架构，并能做到与其它实现方式进行互操作。
如下描述的架构使用了简单接入控制方法，即每一个经过认证的实体都将得到服务。可能会实现更加精细的接入控制，但这不属于本标准的研究范围。本架构不依赖于桥CA，而是在不同安全域之间直接使用交叉证书，这使SEG和TLS实体中的策略配置变得更加简便。
5.1.1总体架构
除非运营商选择合并多个CA，否则每个安全域至少要有一个SEGCA，NECA，TLS客户端CA或TLS服务器CA，以及一个专属于运营商的互连CA。一个域中的SEGCA将证书颁发给该域内的SEGs，这些SEGs与其它域内的SEGs存在相互连接，即Za接口。SEG证书也可以用在Zb接口上与NE进行相互通信。NECA将证书颁发给NEs，用来实现NE之间的通信以及NE与可信任域内的SEGs之间的通信，即Zb接口。TLS客户端CA将证书颁发给该域内需要与其它域内的TLS服务器建立TLS连接的TLS用户。TLS服务器CA将证书颁发给域内需要与其它域内的TLS用户建立TLS连接的TLS服务器。互连CA将证书颁发给SEGCAs、TLS客户端CAs或与本域内的SEG、TLS客户端存在相互连接的其它域内TLS服务器CAs。本标准描述了需要的各种证书的总体配置（profile），同时也描述了一种生成交叉证书的方法。总体而言，所有的证书都应基于IETFRFC5280。5.1.1.1NDS/IP场景
YD/T2909-2015
以下描述了使用SEGCAs颁发IPsec证书的架构。SEGCA应该将证书颁发给使用Za接口的安全网关。当安全域A中的SEG与安全域B中的SEG建立安全连接时，它们应当能相互认证。相互认证是由SEGCAs颁发给SEGs的证书来实现的。当各个域间建立互连时，互连CA就交叉认证了对等运营商的SEGCA。生成的交叉证书需要本地配置于每个域中。对于安全域A中的与安全域B间存在Za接口的SEG来说，由安全域A的互连CA为安全域B的SEGCA生成的交叉证书应该有效且可用。同样的，对于安全域B中的与安全域A间存在Za接口的SEG来说，由安全域B的互连CA为安全域A的SEGCA生成的交叉证书应该有效且可用。基于IPsec证书来认证SEGs和NEs的总体架构如图2所示。注：为了避免重复，一个潜在的CA在图2中并没有表现出来。安全域A
Interconnection
SEGCAA
IKE“连费
ESP隧进
国发证书
安全域B
Interconnection
SEGCAB
图2NDS/IP场景下信任校验路径
交叉认证之后，SEGa就能确认路径：SEGb->SEGCAB->互连CAA。安全域A内的所有实体只信任安全域A内的互连CA颁发的证书。同样地，SEGb能确认路径：SEGa->SEGCAA->互连CAB该路径在安全域B内可确认，因为路径终止于一个可信任的证书（安全域B的互连CAB）。互连CA路径中的第二张证书进行签名。例如，在安全域A中，SEGCAB的证书是由安全域A中的互连CA在执行交叉认证时进行签名。5.1.1.2TLS场景
以下描述了使用TLSCAS颁发TLS证书的架构。TLS客户端CA应该将证书颁发给其安全域内的TLS用户。同样地，TLS服务器CA应将证书颁发给其域内的TLS服务器。当安全域A中的TLS实体与安全域B中的TLS实体建立安全连接时，它们应当能相互认证。互认证是由TLS客户端/服务器CAs颁发给TLS实体的证书来实现。当各个域间建立互连时，互连CA就交叉认证了对等运营商的TLS客户端/服务器CAS。生成的交叉证书只需要本地配置于每个域中。对于安全域A中需要与安全域B连接的TLS实体来说，由安全域A的互连CA为安全域B6
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。