YDB 074-2012 下一代网络( NGN ) 身份管理机制.pdf

上传人:吴艺期 文档编号:239691 上传时间:2019-07-13 格式:PDF 页数:40 大小:2.12MB
下载 相关 举报
YDB 074-2012 下一代网络( NGN ) 身份管理机制.pdf_第1页
第1页 / 共40页
YDB 074-2012 下一代网络( NGN ) 身份管理机制.pdf_第2页
第2页 / 共40页
YDB 074-2012 下一代网络( NGN ) 身份管理机制.pdf_第3页
第3页 / 共40页
YDB 074-2012 下一代网络( NGN ) 身份管理机制.pdf_第4页
第4页 / 共40页
YDB 074-2012 下一代网络( NGN ) 身份管理机制.pdf_第5页
第5页 / 共40页
亲,该文档总共40页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

1、j虽标J佳委技术在最主主二口YDB 074一一2012下一代网络(NGN)份管理机制Next generation network identity management mechanisms CITU-T Y.2722:2010 , NGN identity management mechanisms , MOD) 2012一0325印发中国通信标准化协会发布YDB 074-2012 自欠前言. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2、 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 l 范围. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 规范性引用文件. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 术语、定义和缩略语. . . . . 2 3. 1 术语和定义. . . . . . 2 3. 2 缩略语. . . . . . . . . . 5 4 支持IdM功能的机制与规程. . . . . 6 4. 1 生命周期管理. . . . . . 6 4. 2 认i正和认i正f呆i正. 6 4. 3 关联与绑定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4、. . . . . . . . . . . . . . . . . . . . . . . . 21 4.4 发现机制. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4. 5 IdM通信与信息交换. . . . 22 4. 6 个人可识别信息(PII)的保护. . . . 25 4. 7 联盟身份功能. . . . . . . . . . . . . . . . . .

5、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4. 8 身份信息的准入控制. . 26 4.9 单点登录. . . . . . . 26 4.四单点登出. . . . 27 5 安全.29 附录A(资料性附录)WSS X. 509v3信息认证. . . . . . 30 附录B(资料性附录)Open四十OAuth准入控制机制. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6、 . . 33 参考文献. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 YDB 074-一2012_,_ 目IJ仨=1本技术报告是下一代网络(闷的身份管理研究系列技术报告之一,该系列技术报告的结构及名称预计如下:一一下一代网络CNGN)身份管理需求; 一一下一代网络CNGN)身份管理功能架构要求; 一一下一代网络CNGN)身份管理机制。本技术报

7、告按照GBl.1-2009给出的规则起草。本技术报告使用重新起草法修改采用ITU-TY. 2722: 2010 报文头中,报文头中同时还包含数字签名oSOAP 消息的接收方使用数字签名核实消息发送方用于在SOAPiE文摘要上计算签名和检查其完整性的密钥。摘要算法使用SHA1算法,签名算法是RSA_SHA1算法,具体规定见OASISWSS SOAP (2004)规范。签名的值由中的提供。两种主体确认方法定义了将密钥信息传送给接收方的不同方式,详细说明见下面子章节。4.2.1.2.2 Holder-of-key主体确认方法图3描述用于密钥持有方主体断言方法的SAML断言结构,要素的)j法属性表明主

8、体确认方法Cholder-of-key)。该方法规定,发送发(证实实体)必须通过表明对密钥的了解证明它有权给出有关主体的声明(密钥由SAML断言中要素所含的要素予以识别)0 要素识别用于确认主体身份的公共或秘密密钥。该方法进a步规定,发送方可通过用该密钥对SOAP正文摘要签名的方式完成上述工作。如图2所示,签名包含在WS安全报文头中的要素中。8 YDS 074-2012 图3密钥持有方主体确认方法使用的SAML断言结构SOAP消息接收方使用证明实体提供的信息(在中)获得密钥,雨后计算SOAP正文的数字签名并检查该签名是否与证明实体提供的签名相匹配。如果匹配,则可将SAML断言的主体和声明归属于

9、证明实体,并将完整性由密钥保护的SOAPlE文内容视为由证明实体提供。4.2.1.2.3 Sender-vouches主体确认方法图4描述发送凭证主体确认方法使用的SAML断言结构。要素的方法属性表明主体确认方法(发送凭证)。证明实体受接收方委托对主体做出SAML断言,条件是要素的方法属性数值表明是发送凭证方法。证明实体从一个或多个主管机构获得一个或多个断言或有关断言的参考,并将其纳入SOAP消息中,之后计算SAML断言摘要和SOAP消息正文的签名。签名包含在WS安全报文头的要素中(如图2所示)。作为可选方式,证明实体可向接收方提供用于计算签名的密钥信息。如果不存在此类信息,则期望接受方通过其

10、它手段识别密钥。接收方检查签名的有效性,如果签名有效,则接收方确认证明实体己对主体做出了声明的事实。9 YDB 074-一2012图4发送凭证主体确认方法使用的SAML断言结构4. 2. 2 基于证书的认证方法ITU-T Y.2704 (2010)阐述如何使用x.509证书进行认证。4. 2. 3 基于密码的认证方法根据所要求的保证等级,X.1035 (2007) 可使用基于辛苦码的认证。有关基于密码的认iE机制的说明,请见ITU-T4. 2. 4 一次性密码根据所要求的保证等级,现方式。可使用。TP(一次性密码)0 IETF RFC 2289 (1998) 4. 2. 5 基于双向认证的AK

11、A(Authentication and Key Agreement)使用规定了。TP的一种实通用移动通信系统(UMTS)认证和密钥协议(AKA)协议被用于移动基站和网络之间的相互认证。UMTS AKA是一种挑战一响应(challenge-response)协议,使用长期的、通用签约用户身份模块(USIM)和认证中心之间共用的密钥,后者亦可是IdSP的组成成分。这些实体分别在移动基站的通用集成电路卡(UICC)和移动台的归属网络千r.oAKA协议由3GPP33102 (2007)具体规定。4. 2. 6 集成在IMS中的基于PKI的认证方法4.2.6. 1 概述IMS安全是以AKA机制作为基础

12、的,采用共享密钥和挑战一响应协议进行用户与网络之间的认证,但-些NGNll!.务(如IPTV)的安全以PKI证书为基础。为便于将这些NGN业务与IMS业务相结合,有必要将基于PKI的认证与IMS进行结合,且能充分利用IMS的安全优势。将IMS与基于PKI的认证相结合允许用户设备和网络根据各自的证书相互认证,并根据与AKA相同的密钥生成算法就-套加密密钥达成协议。为此,有必要为用户设备和网络分别提供私钥和证书,并使其能够进行PKI操作。有关加密密钥(CK)和完整性密钥CIK)协议,所描述的结合机制具体规定了两种可选方案:10 YDS 074-2012 a) 使用终端用户功能和S-5-家乡用户签约

13、系统(HSS)之间的共享密钥就CK和IK密钥达成材1.t们b) 不使用共享密钥而就CK和IK密钥达成协议。4. 2. 6. 2 认证过程中的实体S-5:家乡签约用户系统(HSS)。终端用户功能:该实体能够运行SIP客户端。S-n:呼叫会话控制功能实体(CSC-FE), S-n表示下列实体之一:一一-S一l呼出呼叫会话控制功能实体(S-CSC-FE)一-S-2代理呼叫会话控制功能实体(P一CSC-FE)一-S-3询问呼叫会话控制功能实体(I一CSC-FE)当实体之间所描述的认证规程没有区别时,S-n用于表示其中的一个实体。4.2.6.3 通过在终端用户功能之间共享密钥的方式建立CK和IK密钥协议

14、备选方案1)E主终用户功能制体始时时问服功$.5 ($ TJP.FE) 1没JllIjJ,fHJ,岛-PI)2.$-10,获得RlND.、1K (j1lP- J1,fPI) 3.R必函、CK、IK4.4IJ1末我投权CRA!.口吨N,.;碗AM)生司FJ.IN(J.挺挺且由J、IKOCK 3庄周IjMP.、J1I世1、.INJ lJ I K(Ri心吕DJ6. 莫德t主要记录8.2z 1.核lJ.:国5IMS认证机制与基于PKI的认证的结合如图5所示,呼叫流程基本步骤如下:1 )终端用户功能采用用户IMPU和JIMPI向S-n发送SIP注册请求。2) S-l要求S-5进行随机的RAND、CK和I

15、K质询。3GPP33102 (2007)具体规定RAND、CK和IK的数值。3) S-5接收S-5提供的有关用户的RAND、CK和1K。4) S-n利用RAND质询及其加密数值NprRAND向终端用户功能发送未经授权的SIP消息。终端用户功能:一一接收假设等于RAND的数值A和假设等于NprRAND的数值B一一检索网络公共密钥Npu一一利用N,X才B进行解密,并将结果与A进行比较。如果数值相等,则网络得到认证:如数值不等,则中断认证规程一一一使用共享密钥IC生成IK和CK一一生成U,Npl1K! K (RAND)数值5)终端用户功能利用IMPU平P1MPI标识符和UprNpuK!K(RAND)

16、数值向S-n发送SIP注册信息。11 YDB 074-2012 6) S一l向S-5发送在步骤5中收到的数据,并要求核实用户记录。S-5进行下列操作:一一查阅用户证书,以获得用户公共密钥UPU一一利用Up5(才收到的数值C进行解密,该数值被假设等于UprN K I K (RAND) 以检索数值DIE,其中D被假设等于Nr,时,E被假设等于K(RAND) 一一用网络私钥Npr5(数值D解密,以获得K一一用K对数值E解密,以获得RAND一一一将RAND与RAND进行比较,如果二者匹配,则用户得到认证7) S-5将认证结果和用户记录通报S-lo的S一l利用记录检查得到认证的用户是否有权进行注册并接收

17、所要求的服务。如情况如此,则S-n通知终端用户功能接入得到授权。4.2.6.4 不通过在终端用户功能之间共享密钥的方式建立CK和IK密钥协议(备选方案2)12 最终用户功院1.在朋UMPrJ_且1!J)服务控制功能实排(S且)$.5 (SUP.FE) $.l: 1寻P11、rDUM?江1M?)3RAND 4.401末,:t属性方法设为数值发送凭证。一一计算数值Ks(K)。一一将断言包含在SAML应答中,之后按照步骤2所述的、与SAML请求相同的方法交付SAML应答并计算经HTTP的数值Ks(K) (即,作为查询字符串的一部分)。数值Ks(K)由参数pki-auth-keyinfo传送。一一为确

18、保认证的来源和经URL编码的信息的完整性,A-2按照YD/T2094.1 (2010)中的规定对其进行签名。应采用共享密钥Ks进行签名。一一在对已签名的URL确认后,AS得到保证,SAML断言是由A-2做出的。AS对断言本身进行检查(如确保条件得到满足),之后,AS检索数值Ks(K) ,并采用共享Ks对其进行解密,以获得K。此时,AS己对终端用户功能进行了认证,因此两个实体在共用密钥K,该密钥可用于确保这二者之间的通信。7)如政策要求做出授权决定,则AS获得有关认iE吾境的信息。在这种情况下,A-2通过公共密钥x.509 的认证语境等级规定的信息做出应答,具体要求见YD/T2094.4 (20

19、10)。的AS向终端用户功能发送授权决定结果。4.2.7.4 对参与认证过程实体的要求16 为支持所述的机制,各参与实体必须满足下列要求:a) 对终端用户功能的要求终端用户功能必须能够:一一运行HTTP客户端:一一安全地存储其私钥Upr(如在智能卡上存储); 一一获得网络公共密钥N川一-一进行加密和解密:一一生成密钥K。b) 对应用服务器(AS)的要求一一-AS必须支持SAML,见YD/T2094.6 (2010) ; 一一-AS必须拥有与A-2共享的密钥(Ks)。c) 对A-2功能实体的要求A-2功能实体必须能够:一一支持丑盯TTP协协A办、议比;川、?卜r、一一-安全地存储其私钥一一获得用

20、户公共密钥U弘b归阳t邸t,; 一一-进行力加口密和解密;二、一一生成随机挑战RAND;一一-支持SAML,见YD/T一一拥有与AS共享的密钥EKs)d) 对S-5功能实体的要求一-S-5功能实体必须安全地存储用4.2.7.5 对参与认证实体之间接口的要求对接口的要求如下:YDB 07 4-2012 一一终端用户功能和应用服务器之间的接口必须支持HTTPI办议,见IETFRFC 2616 (1999) ; 一一-终端用户功能和k-2功能实体之间的接、阳必须支持世TTPIJ议,见IETFRFC 2616 (1999) ; 一-A-2和应用服务体之间的接口必须支持SAM;Y觅YD月2094.6(2

21、010) ; A-2和S-5功能实体之间的接口必须支持查询一应答机制,以方便A一2从S-5处获得用户的x. 509证书。4. 2. 8 基于OpenlD认证与j脆的结合4、4. 2. 8. 1 概述庐r方便将IMS-与基于penID认证相结合的机制将针对网络的IdM与针对用户的I峭的能力相结合,该机制:一一有助于网络运营商向接入网络应用的用户提供身份服务:一一向用户提供跨主岖的SS以及带有己有ISIM应用的网络服务:一一有利于用户J娟、:perlI:v. 2的规定在网络上控制其公共标识符;一一-在WebJV.用访问过程中通过使用用户可信的网络运营商来提升用户的安全。3GPP TR 33. 92

22、4 (2009)描述了几种将QpenID与依赖:自启动服务器功能(BSF)的AKA相结合的解决办法。二、本节介绍的另一种备选机制允许将OperrID与:AKM自结合、OpenED规范可以采用多种的认证机制,同时还支持3GPPTR 33. 924飞2009)中描述的分离终端场景。penID还可以与包括OAuth在内的其它技术实现互通。4.2.8.2 参与认证的实体与流程终端用户功能:该实体能够运行网络客户端并与ISIM应用进行通信。应用服务器:提供网络服务的实体,它发挥着依赖方的作用。17 YDB 074-2012 A-2:应用网关功能实体(APL-GW-FE),该实体相当于OpenID身份提供

23、方oS-5:家乡繁灼用户京纯(I-!S们飞认证流程如图8所示。该国未显示应用服务器与A-2之间建立短期签名密钥的流程。该图所示为两种OpenID选择方案的基本规程步骤:一-A-2与应用服务器之间共享密钥:一一-A-2与运用服务器之间不共享密钥。两个选择方案之间的共同步骤为a)至f),步骤7a只适用于方案a。步骤7b、胁和9b仅适用于方案boE主用户功能牛+ 1. Authn句坦d到者求2.1每请或重发IdP4认证、清求、原旬5.1窍寄6返回带有重发凶明的经签名的认还结果在退回认诅结果民.返回认证结果峰-嗡一-一方2总和b的共有信自包峰等国方案豆的信怠喝喝-万京b的信息A-2 (命培nID.ld

24、Sp)应用服务备依始方3我但AV.和基于-JMPl的用户*割It宫内紧?ro.i者在对签名进行核实图8IMS认证机制与基于OpenlD的认证的结合基本步骤如下:S-5 1 )终端用户功能的网络客户端向应用服务器发出认证请求AuthnOpenID,该请求包含OpenID标识符。2)应用服务器利用所提供的OpenID;fjJ;识符发现A吃的URL(A-2发挥着OpenID身份提供方的作用), 并将用户认证请求重发至URL。该步骤之后,A-2将用户标识符与IMS的私人和公共标识符相关联。1) A-2 J.A S-5处获得AKA认证矢量AV和基于IMPI的用户档案。2) A-2使用HTTP摘要AKA方

25、法(见IETFRFC 4169 (2005) )或向终端用户功能发送认证请求(见IETFRFC 3310 (2002) ) ,该请求包含有助于终端用户功能对网络进行认证的质询和数量。该步骤之后,终端用户功能按照IETFRFC 4169 (2005)和RFC3310 (2002)中的具体规定,对网络进行认证。3) A-2从S-5处获得AKA认证矢量AV和基于IMPI的用户档案。18 YDB 074-2012 4) A一2使用HTTP摘要AKA方法(见IETFRFC 4169 (2005) )或向终端用户功能发送认证请求(见IETFRFC 3310 (2002) ) ,该请求包含有助于终端用户功能

26、对网络进行认证的质询和数量。该步骤之后,终端用户功能按照IETFRFC 4169 (2005)和RFC3310 (2002)中的具体规定,对网络进行认证。5)终端用户功能按照IETFRFC 4169 (2005)和IETFRFC 3310 (2002)中的具体规定,向A-2发送对质询的应答。该步骤之后,A-2按照IETF.RFC 4169. (2005)和RFG33102002)中的具体规定,对终端用户功能进行认证。芝,川6) A-2向终端用户功能发送经签名的信息,茹J认声称的OpefiID标识符属于用户。在方案a中,使用与应用服务器共享的密饲对倍息进行签名。对方案b丽吉,则使用A吃的秘密密钥

27、进行签名。该信息包含将终端用户功能的网络客户端重发至应用服务嚣的请求。OpnID.y二2详细阐述了有关签名和重发的规程,该文件还阎明了预防攻击的措施以重复飞使用己签名的认证断言为基础。只针对方案a的步骤:7a)应用服务器对在步骤f收割的应答签名进行核实后,即将认证结果通知终端用户功能。应用服务器利用与A-2共享的秘密密钥进行上述核实。如果1至6或7a步骤中的任何?步失败,则认证规程终止。只针对方案b的步骤:7b)应用服务器向A-2发送在步骤6中收到的信息拷贝,并提出对签名进行核实的请求。8b)对其自身签名进行核实后,A2向应用服务器报告核实结果。9b)应用服务器向终端用户功能报告认证结果。如果

28、1至6、7b、8b或饨的任何0217失败,贝ui人证规程终止。4.2.8.3 对参与认证过程实体的要求为支持所述的机制,参加认证的实体必须满足下列要求:对终端用户功能的要求,终端用户功能必须能侈z一一通过使用HTTP摘要去KA方法进程认iEi一一与ISIM应用进行通信。对应用服务器的要求,应用服务器必须能够支持OpenIDv2.。规范要求。对A一2功能实体的要求,.A-2功能实体必须能够:一一进行HTTP摘要AKA认证:一一将用户OpenID标识符与他或她的IMS公共和私人身份相关联:一一作为OpenID身价提供方对S-5功能实体的要求二除1T1J.T二Y,2012(2006)规定的要求外,对

29、S-5功能实体没有其它要求。4. 2. 8. 4 对参与认证实体之间接口的要求对接口的要求如下:二一一终端用户功能和应用服务器之间的接口必须支持OpenIDv:Z具体规定的OpenID认证。一一终端用户功能与A过二功能实体之间的接口必须支持HTTP摘要AKA协议,具体要求见IETFRFC 4169 (2005)手JIETFRFC 3310 (2002)。对A-2与S-5功能实体之间的接口没有任何针对具体机制的要求。4.2.8.5 分离用户终端场景中OpenlD与AKA的互通机制分离用户终端情形系指认证代理(具有廿lCC卡接入的实体)与浏览代理未置于同一用户终端的情况。19 YDB 074-20

30、12 考虑到本节所述的直接AKA解决方案中IdSP与伸缩式(collapsed)NAF/BSF相对应,因此该解决方案完含芝持阳PPTR怡。924(2009)栩5Eo读取决于青接AKA认iiL而不县某干GRA的认iL4.2.9 GBA 通用配置体系架构(GBA)具体规定了充分利用3GPP认证和密钥协议(AKA)机制的自启动配置认证和密钥协议建立的框架。GBA有助于终端用户向网络应用功能(NAF)的认证,并可在NGN身份管理中实现:一一认证和密钥协议一一一隐私保护一一单点登陆GBA是由三个部分组成的认证系统:一一一试图使用用户设备(UE)获得网络服务的终端用户。一一应用服务器(称作网络应用功能或N

31、AF)。一一受信任的实体(称作启动配置服务器功能或BSF),它参与两个其它实体之间的认和密钥交换。GBA有助于使用用户终端的终端用户在不向应用服务器(NAF)透露其长期证书和密钥的情况下利用可信实体(BSF)对应用服务器进行认证。下述参考模式具体说明GBA认证规程的基本内容。t主-括号中的标签表示TU-TY.20 12具体规定的实体图9简单的自动启动配置网络模式GBA规程的基本步骤如下:1) NAF请求认证并就经Ua参考点的GBA的使用进行协商。2)在四上运行的BSF客户端启动经过参考点Ub的自动配置规程,BSF经ZhJAHSS处提取认证信息和GBA用户安全设置。UE手UBSF矛Ij用http

32、摘要AKA相互认证。通过该规程,UE从BSF处收到通用配置交易标识符(B-TID) ,并建立UE与BSF之间的共享密钥(Ks)。3) UEM.Ks推导出Ks_NAF,并向NAF发送B-TID(以及针对应用的数据)0 4) NAF经Zn参考点向BSF发送B-TID。5) BSF根据B-TID确定应使用的Ks,从中推导出KsNAF,并向NAF发送Ks_NAF。6)最后,UE;tUNAF通过共享密钥Ks_NAF相互认证。确切的认证规程取决于UE和NAF之间的协议。例如,GBA规定,基于HTTP的应用可使用HTTP摘要认证,具体要求见IETFRFC 2617 (1999)和IETFRFC 4279 (

33、2005) 20 YDB 07 4-2012 注:BSF经Dz参考点对SLF进行查询,以获得包含针对签约用户数据的HSS的名称。如BSF被设置为使用预定HSS,则不需要SLF,ITU-T Y.2012 (2006)规定了GBA到NGN实体的映射,包括:一-NAF与ITU-TY.2012 (2006)图3中的应用实体相对应:NGN的一般性功能架构:一-HSS与S-5业务用户档案FE对应:一-SLF与S-4签约定位FE对应:一-UE与终端用户功能对应。4.2.10 基于IMSI的认证根据所要求的保证等级,可在WAP网络巾使用IMSI(国际移动签约用户身份)进行具有后向容性的认证。由于IMSI是独一

34、无工的字母字符串,因此可用作特定业务的实体身份。该机制:一一在无线应用中将IMSI代码用作实体身份:一一提供可靠的业务渠道,条件是在端点提出认证请求时,端点具有合法的IMSI;-一一所以系统均信任WAP网关的认证结果,并为该实体提供服务;一一通过IMSI在GPRS/CDMA1x与无线应用(如无线邮箱等)为同一端点提供单点登录功能:实现IMSI代码的安全保护。4. 3 关联与绑定根据ITU-TY. 2720 (2009)规定,可;自身份信息(标识符、证书和属性)进行关联,以建立确保实体身份的绑定。推动关联的解决方案的一个日标是从不同渠道获得种类繁多的身份信息并以可理解的统一格式将其呈现给应用。此

35、类解决方案的理念由图10具体说明。该图阐明身份信息的三种渠道:HSS、呈现服务器和特定应用的用户数据数据库。应用在做出认证和授权决定时,需要所有这三种类型的信息。在所阐释的示例中,关联机制采用了Diameter、LDAP和SQL协议从各相关渠道获得数据。之后,以相关应用理解的格式向该应用呈现数据。因此,关联机制降低了应用为与不同身份信息渠道进行通信而支持多个协议的负担。时比DA岳阳里础知SQL 气数据渠道注-关机制为应用提供所有身份数据的统一呈现。图10身份信息关联21 YDB 074-2012 4.4 发现机制4.4.1 概述ITU-T Y. 2721 (2010)规定在NGN/IdSP域内

36、和各不同NGN/IdSP域之间,要求NGN/IdSP支持发现身份信息渠道的功能和能力。本节以示例说明支持这些要求的标准机制以及对有关规范的参考。4. 4. 2 网络域内发现机制ITU-T Y.2012 (2006)定义了一个特殊实体一一-签约定位功能实体(SL-FE)。该实体提供储存特定签约用户身份信息的家乡签约用户系统(HSS)的地址。SL-FE有助于发现HSS,后者负责存储用户档案,针对签约用户的定位数据和现状状态数据。网络实体通过查询HSS,可获得这一身份信息。如ITU-TY.2012 (2006)规定,下列网络实体可就适当HSS的地址向SL-FE提出查询:一一应用支持功能实体(AS-F

37、E)一一询问呼叫会话控制功能实体(I-CSC-FE)一一一主叫呼叫会话控制功能实体(S-CSC-FE)3GPP规范TS23.228中规定了这些实体在运营商网络中找到存储特定用户身份信息的HSS地址的机制。ITU-TY.2012 (2006)中定义的实体与3GPP规范TS23.228中定义实体的映射关系如下:一-AS-FE与AS对应一一I-CSC-FE与I-CSCF对应一-S一CSC-FE与S-CSCF对应一-SL-FE与SLF对应4.4.3 网络域间发现机制网络域间发现IdSP的机制示例包括SAML,见YD/T2094.2 (2010)和ID-WSF中规定的机制。这些机制依赖联盟之间预先建立的

38、协议。OpenID (参见OpenIDv. 2规范)发现机制是一种动态发现IdSP的机制。4.5 IdM通信与信息交换4.5.1 IdM通信与信息交换的安全4. 5. 1. 1 基于SAML2.0的解决方案为保护完整性和保密性,SAML 2.0建议使用安全的通道或诸如TLS或IPsec等安全网络协议的自己置来保护经过网络连接传送的数据包。除安全的通信通道外,为保护信息层面的完整性,可使用XML签名。在使用XML签名时,应符合YD/T2094.2 (2010)规定。除安全的通信通道外,为保护信息层面的保密性,在使用XML加密时,应符合YD/T2094.2 (2010) 规定。4.5.1.2 基于

39、身份Web服务功能架构的解决方案ID-WSF可用于基于身份的万维网(WWW)服务。为使用ID-WSF,应保证发送方和接收方之间的通信和信息的完整性和保密性能够得到保护。同SAML2. 0一样,建议通过使用安全的迪道或诸如TLS或IPsec等安全网络协议的配置来保护经过网络连接传送的数据包(参见LAID-WSF security规范)。a) 传输层渠道保护22 YDB 074-2012 在将SSL或TLS作为安全网络协议用于ID-WSF时,要求使用SSL3. 0、TLS1. 0或更高版本协议。终接SSL (3.0)或TLS(1.0)连接的实体需要在握手期间提供或接收合适的加密套件。以下为建议使用

40、的TLS1.0加密套件(或其对应的SSL3.0套件),但不仅限于下列加密套件。一一-TLSRSA WITH RC4 128 SHA 一一-TLSRSA WITH 3DES EDE CBC SHA 一一一TLSDHE DSS WIT日3DESEDE CBC SHA 一一-TLSRSA WITH AES CBC SHA 一一一.TLSDHE DSS WITH AES.CBCSHA了 为对协议消息进行签名和核实,建议通信实体使用完全不同予用于SSL或TLS渠道保护的证书和私饲。其它安全协议如IPSC或Keiheros,在能够保证安全措施鸣的条件下也可采用。b) 信息保密性的保护在存在中问环节时,通倍

41、实体需要确保敏感信息不被透露给未得到授权的实体。在此方面,要求这些实体使用网络服务安全CWSS)SOAR消息安全(白OASISWSS叮SOAR.( 2004 )规范制定)规定的保密机制对SOAP封包内容进行加密。c) 有关信息完整性的规则只有当根据自由SOAP绑定版本2.0 (参见LASOAP binding规范)将万维网服务安全(WSS)SOAP消息安全用于与SOAP绑定的ID一WSF协议消忠时,本节所述的信息完整性规则才适用。在这种情况下,要求发送方创建报文头中包含的单一,且要求该签名参考所有被要求签名的组成部分。应特别指出,要求该签名参考SOAP.iE文要素(要素本身)、与签名相关的安全

42、令牌以及自由SOAP绑走版本2.0(参见LASOP bndng规范确定的信息的所有报文头C包括必须具备和可选的报文头块)。安全令牌的一个示例是fR=文:头中传送的要素。签名中参考的报文头要素示例包括wsse:S扎ty报文头块中的wsu:TimestarnP.wsa:MessageID、wsa:Re1atesTo、sb:Framework、sb:Sendr和功:Invg,tinIdent ty;报文头块;需要注意的是,在构建端点参考的参考参数所瓷的要素肘需要十分谨慎,因为这将提升至SOAP报文头块中。建议应努力避免相互冲突或重复的身份工Ij)属性,例如通过使用相关技术生成唯一身份。如果对信息进行

43、v签名,则要求发送方在:报文头的后代加以纳入。要求要素利用要素参考主体确认密钥,要求要素包含一个要素,以便在报文头中对主体确认密钥进行定位。建议在纳入该参考时要遵守OAstSSAML token (2006)规范中规定的网络服务安全。1) 发送方处理规则 要求报文头要素的构建和装饰应符合OASISSAML token (2006)规定。要求报文头要素具有逻辑值真实的mustUnderstand属性。要求发送方将信息认证支全令牌作为要素的直接后代予以放置。在使用信息、认J班机制时要求发送方道守为发送方和接收方规定信息完整性规则。下列方面的考虑不适用于承载(Bearer)令牌:对要求进行独立信息认

44、证的部署设置而言,要求以对信息正文和报文头有关部分进行签名的方式完成义务,同时将作为报文头的直接后代予以放置。对于不要求进行独立信息认证的部署设置而言,可以通过将所用的证书和密钥相互关联完成义务,以通过信息证书令牌描述的证书和密钥影响对等实体认证。为满足这一要求,需23 YDS 074-2012 要发出断言的主管当局在创建断言时使用的方法能确保确认密铝可毫无歧义地被核实为是建:在对等实件iAiE月厅使用的同样的吁书和需f月三为精心E书梓代攻击的威胁,j雪样做县十分必要的。建议将证书或证书链与主体确认密钥绑定一起。2) 接收方处理规则 要求接收方对以其为目标的要素进行定位。做法必须遵守网络服务安

45、全(WSS) SOAP消息安全规定的规则以及适用的WSS令牌资料(见OASIS SAML token (2006) 规范。要求报文头要素具有逻辑数值真实的mustUnderstand属性,且接收方必须符合网络服务安全(WSS)SOAP 消息安全的规定(见OASIS WSS SOAP (2004)规范)和适用的WSS令牌资料处理这一报文头块。 要求接收方对安全令牌进行定位并确定它信任发放令牌的主管当局。要求接收方确认发行方经令牌发出的签名。建议接收方酌情针对错误认证带来的风险对签名密钥的信任语义予以确认。XML签名句法与处理要求参见W3C报文头中传送的要素进行定位。除非安全机制是对等SAMLV2

46、,否则要求接收方解决中传送的内容,并采用其描述的密钥对己签名的要素进行确认。当安全机制为对等SAMLV2时,密钥为SSL!TLS客户端认证中使用的客户密钥。 当使用信息认证机制时,要求接收方遵守为发送方和接收方制定的信息完整性规则。d) 利用WSSX,509令牌处理信息本节规定具有X509数值的信息机制的语义和处理规则,详细信息、参见附录A。这些URI支持单方面(发送方信息认证,并具有下列形式:一-urn:liberty:security:2003-08:PEER:X509,其中PEER根据采用的对等认证机制的不同而不同(如,可能为o(null)、TLS等)。WSS X509信息认证机制使用网络服务安全X,509证书令牌资料作为信息发送方向接受方进行认证的手段,这些信息认证机制是单方面的,即只对信息发送方进行认证,具体要求见OASISWSS X. 509 profile (2006)。有关何时应对应答信息进行认证的建议不属于本文件的范围,但值得指出的是,也可依赖该机制对应答信息进行认证。然而在此建议人们认识到,对应答信息的独立认证不能够

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 标准规范 > 行业标准 > YD通信行业

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1