密钥lol服务器连接异常

国际电信联盟ITU-TM.
3016.
3国际电信联盟电信标准化部门(04/2005)M系列:电信管理,包括TMN和网络维护电信管理网管理平面的安全:安全机制ITU-TM.
3016.
3建议书国际电信联盟ITU-TM系列建议书电信管理,包括TMN和网络维护引言与维护和维护组织的一般原则M.
10-M.
299国际传输系统M.
300-M.
559国际电话电路M.
560-M.
759公共信道信令系统M.
760-M.
799国际电报系统和相片传真传输M.
800-M.
899国际租用一次群和超群链路M.
900-M.
999国际租用电路M.
1000-M.
1099移动电信系统和业务M.
1100-M.
1199国际公众电话网M.
1200-M.
1299国际数据传输系统M.
1300-M.
1399标志和信息交换M.
1400-M.
1999国际传送网M.
2000-M.
2999电信管理网M.
3000-M.
3599综合业务数字网M.
3600-M.
3999公共信道信令系统M.
4000-M.
4999欲了解更详细信息,请查阅ITU-T建议书目录.
ITU-TM.
3016.
3建议书(04/2005)iITU-TM.
3016.
3建议书管理平面的安全:安全机制摘要本建议书定义了电信管理网中管理平面的安全机制.
本建议书主要关注于网元(NE)和管理系统(MS)的管理平面安全特性,NE和MS属于电信基础设施中的一部分.
来源ITU-T第4研究组(2005-2008)按照ITU-TA.
8建议书规定的程序,于2005年4月13日批准了ITU-TM.
3016.
3建议书.
关键词ITU-T建议书D.
000由ITU-T第3研究组(2001-2004年)编写,并按照WTSA第1号决议的程序于2002年6月14日批准.
iiITU-TM.
3016.
3建议书(04/2005)前言国际电信联盟(ITU)是从事电信领域工作的联合国专门机构.
ITU-T(国际电信联盟电信标准化部门)是国际电信联盟的常设机构,负责研究技术、操作和资费问题,并且为在世界范围内实现电信标准化,发表有关上述研究项目的建议书.
每四年一届的世界电信标准化全会(WTSA)确定ITU-T各研究组的研究课题,再由各研究组制定有关这些课题的建议书.
WTSA第1号决议规定了批准建议书须遵循的程序.
属ITU-T研究范围的某些信息技术领域的必要标准,是与国际标准化组织(ISO)和国际电工技术委员会(IEC)合作制定的.
注本建议书为简要而使用的"主管部门"一词,既指电信主管部门,又指经认可的运营机构.
遵守本建议书的规定是以自愿为基础的,但建议书可能包含某些强制性条款(以确保例如互操作性或适用性等),只有满足所有强制性条款的规定,才能达到遵守建议书的目的.
"应该"或"必须"等其他一些强制性用语及其否定形式被用于表达特定要求.
使用此类用语不表示要求任何一方遵守本建议书.
知识产权国际电联提请注意:本建议书的应用或实施可能涉及使用已申报的知识产权.
国际电联对无论是其成员还是建议书制定程序之外的其他机构提出的有关已申报的知识产权的证据、有效性或适用性不表示意见.
至本建议书批准之日止,国际电联尚未收到实施本建议书可能需要的受专利保护的知识产权的通知.
但需要提醒实施者注意的是,这可能不是最新信息,因此大力提倡他们查询电信标准化局(TSB)的专利数据库.
国际电联2005版权所有.
未经国际电联事先书面许可,不得以任何手段复制本出版物的任何部分.
ITU-TM.
3016.
3建议书(04/2005)iii目录页1范围12参考文献13定义24缩写25约定36安全机制36.
1用户鉴权.
46.
2对等实体和数据源鉴权.
56.
3访问控制.
66.
4数据机密性.
76.
5数据完整性.
96.
6审计跟踪.
116.
7密钥交换.
126.
8告警上报.
126.
9分组过滤.
13附录I—IPsec,SSL/TLS和SSH安全机制13I.
1IPsec13I.
2SSL/TLS.
14I.
3SSH15附录II16II.
1目标.
16II.
2影响分组过滤的网络设计考虑事宜.
16II.
3基本分组过滤.
19II.
4增强的分组过滤.
19参考资料.
20ivITU-TM.
3016.
3建议书(04/2005)引言电信网是全球通信和经济的重要基础设施.
为控制此基础设施的管理功能提供适当的安全是必需的.
电信网络管理安全有很多标准存在.
然而遵循程度较低,而且在不同的电信设备和软件组件中是不一致的.
本建议书确定了安全机制,允许设备提供商、代理及业务提供商能够实现一个安全的电信管理基础设施.
尽管目前这些安全机制已经代表了当前对技术状态的理解,但技术在不断发展中,条件也会发生变化,为了更加成功,本建议书必须根据条件的变化而发展.
本建议书应作为一个基础,业务提供商可能包括附加的安全机制来满足他们特定的超出本建议书所涉及的需求.
本建议书是ITU-TM.
3016.
x系列建议书的一部分,该系列建议书将为持续发展的网络的管理平面安全提供指南和建议:TU-TM.
3016.
0建议书—管理平面的安全:概述.
ITU-TM.
3016.
1建议书—管理平面的安全:安全需求.
ITU-TM.
3016.
2建议书—管理平面的安全:安全服务.
ITU-TM.
3016.
3建议书—管理平面的安全:安全机制.
ITU-TM.
3016.
4建议书—管理平面的安全:简表文稿.
ITU-TM.
3016.
3建议书(04/2005)1ITU-TM.
3016.
3建议书管理平面的安全:安全机制1范围ITU-TM.
3016.
1-M.
3016.
3建议书为提供适当的管理功能安全定义了一系列安全需求、业务和机制,这些管理功能是支持电信基础设施所必需的.
由于不同的行政部门和组织机构对安全有不同级别的要求,ITU-TM.
30161-M.
3016.
3建议书不指定某项安全需求、业务或机制为必选项或可选项.
本建议书确定了电信管理中管理平面的安全机制.
本建议书主要关注于网元(NE)和管理系统(MS)的管理平面安全特性,NE和MS属于电信基础设施中的一部分.
本建议书为通用建议书,不是针对电信管理网(TMN)中的某一个特定接口的安全机制.
ITU-TM.
3016.
4建议书中定义的文稿用来帮助各组织、行政部门及其他国家/国际机构等指定对需求支持的必选项和可选项,以及取值范围和取值等,以此来实现他们各自的安全策略.
2参考文献下列ITU-T建议书和其他参考文献的条款,通过在本建议书中的引用而构成本建议书的条款.
在出版时,所指出的版本是有效的.
所有的建议书和其他参考文献都面临修订,使用本建议书的各方应探讨使用下列建议书和其他参考文献最新版本的可能性.
当前有效的ITU-T建议书清单定期出版.
本建议书中引用某个独立文件,并非确定该文件具备建议书的地位.
—ITU-TRecommendationG.
8080/Y.
1304(2001),ArchitecturefortheAutomaticallySwitchedOpticalNetwork(ASON),plusAmendment2(2005).
—ITU-TRecommendationM.
3010(2000),Principlesforatelecommunicationsmanagementnetwork.
—ITU-TRecommendationM.
3016.
0(2005),Securityforthemanagementplane:Overview.
—ITU-TRecommendationM.
3016.
2(2005),Securityforthemanagementplane:Securityservices.
—ITU-TRecommendationM.
3016.
3(2005),Securityforthemanagementplane:Securitymechanism.
—ITU-TRecommendationM.
3016.
4(2005),Securityforthemanagementplane:Profileproforma.
—ITU-TRecommendationX.
509(2000),Informationtechnology–OpenSystemsInterconnection:TheDirectory:Public-keyandattributecertificateframeworks,plusCorrigendum1(2001),Corrigendum2(2002),andCorrigendum3(2004).
—ITU-TRecommendationX.
800(1991),SecurityarchitectureforOpenSystemsInterconnectionforCCITTApplications,plusAmendment1(1996).
2ITU-TM.
3016.
3建议书(04/2005)—ITU-TRecommendationX.
805(2003),Securityarchitectureforsystemsprovidingend-to-endcommunications.
3定义本建议书未规定新的术语.
4缩写本建议书采用下列缩写:CORBA公共对象请求代理体系DoS拒绝服务EMS网元管理系统FTP文件传输协议HTTP超文本传输协议IETF互联网工程工作小组IP互联网协议IPSec互联网协议安全ISO/IEC国际标准化组织/国际电子技术委员会ITU-T国际电信联盟电信标准化部门MS管理系统,含任何EMS、NMS和OSS1NE网元NE/MS网元或管理系统NMS网络管理系统NTP网络时间协议NTPv3NTP第三版OAM&P操作、管理、维护和指配OS运行系统OSS运营支撑系统RFC征求意见SAML安全声明标记语言SNMP简单网络管理协议SNMPv3SNMP第三版SOAP简单对象访问协议SSH安全外壳SSL安全套接层1OSS在电信管理网层次结构中,一般可用来与MS用在相同的上下文中.
ITU-TM.
3016.
3建议书(04/2005)3TCP传输控制协议TLS传输层安全TMN电信管理网XML扩展标记语言5约定在ITU-TM.
3016.
1,M.
3016.
2和M.
3016.
3建议书中,用一个描述符来表示不同的需求、服务和机制.
描述符的组成包括下述三个字母,后带一个数字:—REQ:表示需求;—SER:表示服务;—MAC:表示机制.
6安全机制本节包含了为操作、管理、维护和指配(OAM&P)以及运营支撑系统(OSS)安全而定义的特定的安全机制,可将OAM&P和OSS应用于基础设施、服务和应用的管理平面安全.
如下的表1复制自ITU-TM.
3016.
0建议书(ITU-TM.
3016.
0建议书中的表4).
该表概述了安全需求和安全服务间的关系,并且作为本系列建议书中其他建议书组织的基础.
例如,ITU-TM.
3016.
1建议书讨论了安全功能需求,ITU-TM.
3016.
2建议书讨论了安全服务,而本建议书(ITU-TM.
3016.
3建议书)讨论了适用于安全服务的特定的安全机制.
本节仅定义了标准解决方案所涵盖的安全服务,其他可能的服务(如拒绝服务的检测)将不予考虑.
表1/M.
3016.
3-安全需求和安全服务间的映射安全功能需求安全服务身份认证用户鉴权对等实体鉴权数据源鉴权受控访问和授权访问控制机密性保护—已存储数据访问控制机密性机密性保护—传送中数据机密性数据完整性保护—已存储数据访问控制数据完整性保护—传送中数据完整性责任制不可否认活动日志审计跟踪安全告警上报安全告警安全审计审计跟踪DCN的保护分组检测4ITU-TM.
3016.
3建议书(04/2005)如下的表2简要描述了本节的组织:表2/M.
3016.
3-本节的组织节号内容6.
1讨论了鉴权安全机制,包括用户鉴权和对等实体鉴权.
6.
2讨论了数据源鉴权.
6.
3讨论了访问控制安全机制.
6.
4讨论了数据机密性安全机制.
6.
5讨论了数据完整性安全机制.
6.
6讨论了审计跟踪安全机制.
6.
1用户鉴权用户鉴权是验证一个人所声明的身份的行为.
用户鉴权可能基于的安全机制包括:—用户ID和口令(使用适当的复杂口令)的组合,口令可以是一次性的口令(如安全号).
—多因素鉴权.
—独立的签名鉴权.
本节将详细讨论用户鉴权的安全机制.
6.
1.
1用户ID和口令鉴权用户ID和静态口令可能会在用户鉴权中使用.
用户鉴权证明了合法的系统用户的真实身份,也阻止了非法入侵者的伪装侵袭.
通过适当的鉴权,使得跟踪活动,并应用访问控制来限制用户进行未授权操作或扮演未授权角色成为可能,如6.
2节所述.
用户ID和口令鉴权包括为每个用户分配一个独立的用户ID,然后再分配一个适当复杂的安全口令,该口令与用户ID联合使用来证明用户身份.
口令应当包括足够多的字符,并应随机化,确保不被其他人或机器的自动技术猜测出来.
复杂口令的字符可能包括如下所述的要求:机制1:可能要求口令包含最小数量的字符长度(如8个字符).
机制2:可能要求口令不能包含一些特定的字符.
机制2a:可能要求口令不能是用户ID的重复,或是用户ID的倒序.
机制2b:可能要求口令中任何地方都不能包含已成形的字符序列(如字典中的单词或产品名称等).
机制3:可能要求口令不能包含多于指定重复次数的连续的同一字符的重复.
机制4:可能要求口令至少包含指定数量的小写和/或大写希腊字符.
机制5:可能要求口令至少包含指定数量的数字字符.
ITU-TM.
3016.
3建议书(04/2005)5机制6:可能要求口令至少包含指定数量的特殊字符.
口令的管理对于确保一个安全的鉴权系统来说也是非常重要的.
希望得到如下所述的口令系统管理能力:机制7:口令管理系统可能要求输入旧的口令,以阻止其他用户在已登录用户不知情的情况下修改一个已登录用户的口令.
机制8:系统可能会进行自动地检测来确保新的登录口令与之前旧的口令不同(因为一般来说,口令是通过一个单向的加密系统来存储的,会要求提供旧的口令来允许系统判断新旧口令的不同程度2).
机制9:系统可能会支持一个口令的历史列表来防止口令的重复使用.
机制10:系统可能会在一定时间间隔后强制修改口令.
机制11:当使用非法口令企图进入系统达到一定次数后,系统可能会在一段时间内(如60分钟)限制其尝试其他口令,或者将该用户锁住.
被加锁的用户需要与系统安全管理员联系来解除锁定.
6.
1.
2多因素鉴权多因素鉴权指的是这样一种鉴权流程,即在鉴权时需要两个或更多不同类型的信息或因素,来证实被鉴权用户的身份.
多因素鉴权的要求提高了鉴权系统的安全性,可以不仅仅依赖于某种单一的因素,因为单一的因素可能更易于被欺骗.
在多因素鉴权中典型采用的鉴权因素包括:一些用户所知道的信息:如,安全口令或通行短语.
一些用户所具有的信息:如,令牌、灵通卡、一次性口令发生器.
一些用户本身的信息:如,指纹或其他生物测量值.
一个通用的多因素鉴权机制为双因素鉴权,即要求两个鉴权信任书.
一个双因素鉴权的典型示例为银行卡系统,用户必须携带他们拥有的卡,并且还需要检验与卡相关的安全PIN码.
机制12:具有指定因素数目的多因素鉴权.
6.
1.
3个人签名用户鉴权用户鉴权可能会支持安全的个人签名方法,和X.
509建议书中定义的认证书公共密钥基础设施.
在安全的个人签名中,协议仍然会对信任书实体提出挑战,然而,一个用户可能不必输入信任书,因为信任书已经以某种方式(如Kerberos)安全隐藏了.
使用安全的个人签名技术可以减少用户不得不多次进行系统鉴权的必要性,多次鉴权对用户来说是很不方便的.
机制13:个人签名鉴权.
6.
2对等实体和数据源鉴权使用对等实体鉴权安全机制来验证对等系统所声称的身份.
使用数据源鉴权安全机制来确保所接收的数据来源于声称发送了这些消息的系统.
对等实体鉴权和数据源鉴权是紧密相关的,并且可能基于如下的安全机制:2作为单向加密系统的例外,对称加密的口令也可能会用做口令,该口令需要解码以便在可靠的系统到系统间通信或独立签名时作内部使用或临时使用.
6ITU-TM.
3016.
3建议书(04/2005)—密码鉴权机制.
—可信任的路径鉴权机制.
本节将详细讨论这些鉴权安全机制.
6.
2.
1密码鉴权密码鉴权机制在系统间(如系统到系统,应用到应用等)进行数据通信时提供鉴权,并且是建立具有完全的数据完整性私密通信的基础.
在数据通信过程中,发送实体的密码鉴权允许消息的接收者来鉴别发送者的身份(对等实体鉴权),并且确定消息的源(数据源鉴权).
在一个安全的通信通道中,对等实体和数据源鉴权可能会基于与每个消息相关的密码信息来将发送实体的身份与消息绑定起来.
接收者会检查与消息同时提供的密码信息来验证发送实体的真实身份.
可用于对等实体鉴权和数据源鉴权的密码技术包括:公共密钥加密,对称密钥加密,数字签名和数字散列(哈希)技术3.
密码鉴权可能是单向的,即仅是会话的一端被鉴权;也可能是双向的,即会话的双方均被鉴权.
双向鉴权更安全,可以用来帮助阻止积极的侵袭.
机制14:基于公共密钥加密的对等实体鉴权和数据源鉴权.
机制15:基于对称密钥加密的对等实体鉴权和数据源鉴权.
机制16:基于数字签名的对等实体鉴权和数据源鉴权.
机制17:基于数字散列技术的对等实体鉴权和数据源鉴权.
机制18:双向的加密鉴权.
6.
2.
2可信任的路径用户鉴权可信任的路径鉴权是一种安全机制,该机制可以保证系统到系统的鉴权交互是在一个安全的通信路径上得到保护的.
该机制仅可由系统激活,且不能被假冒.
一个可信任的路径可以或者是一个专用的物理通道(如:直接连接到系统的终端),或者是一个包括完整性和重放保护的加密路径(如:IPsec虚拟专用网,安全套接层/传输层安全(SSL/TLS)隧道,或是安全外壳(SSH)等)4.
关于IPSec,SSL/TLS和SSH安全协议的讨论见附录I.
机制19:基于可信任的路径的对等实体鉴权和数据源鉴权.
6.
3访问控制一个TMN应当提供能力确保参与者不对信息和资源进行未授权地访问.
访问控制安全机制确保仅有授权的用户才被允许访问管理系统的安全资源.
3美国国家标准协会T1.
243-1995,《操作、管理、维护》.
4摘自国家计算机安全中心,NCSC-TG-004-88,《计算机安全术语集》,1998年10月(网址在http://csrc.
nist.
gov/SBC/PDF/NCSC-TG-004_COMPUSEC_Glossary.
pdf).
ITU-TM.
3016.
3建议书(04/2005)7访问控制安全机制可能由一个中央系统来提供,并且常常与鉴权系统相结合.
例如,一个中央远端接入拨号用户系统(RADIUS)服务器可能会与一个轻权目录访问协议(LDAP)数据库相结合,共同提供一个中央系统进行鉴权和访问控制.
访问控制安全机制可能具有如下特性:机制20:所有的管理活动都要与特定的个人相联系.
机制21:访问控制安全机制可能支持"最小权限"思想(即一个人扮演一种角色,将仅具有对该角色所允许的功能进行读取数据、修改数据或执行管理活动等操作的权限)机制22:至少应该有几个管理员账号不因为与口令相关的活动而被锁住,如登录失败或超时等.
机制23:可以定义多个管理员角色,每个角色根据关键的安全管理活动的不同而具有不同的权限级别.
例如,一个系统可能会定义五种管理员用户角色,另一个系统可能会定义三种管理员用户角色.
在这两种情况下,都允许所定义的角色具有对如下安全活动的不同的权限:机制23a:定义和分配用户权限.
机制23b:增加和删除用户ID.
机制23c:初始化和重置登录口令.
机制23d:初始化和修改加密密钥.
机制23e:设置系统的登录口令超时门限.
机制23f:为每个用户设置系统的登录失败次数限制个数.
机制23g:解除锁定或修改系统的锁定超时值.
机制23h:设置系统的去活超时值.
机制23i:设置系统安全日志和告警配置.
机制23j:管理系统安全日志流程.
机制23k:升级安全软件.
机制23l:终止任何用户和系统会话.
机制23m:定义和分配新用户和用户组的应用层权限.
机制23n:维护一个访问应用程序的所有请求的记录.
机制23o:在应用级别增加和删除用户.
机制23p:监测所有的应用安全日志.
机制23q:配置应用安全日志和告警.
机制23r:管理应用安全日志流程.
机制23s:终止任何用户的应用会话.
6.
4数据机密性使用数据机密性安全机制来防止对交互数据的非授权接收.
本节将讨论提供数据机密性的密码安全机制.
数据机密性基于密码基础.
密码系统使用基于标准的和公众可用的特定算法,因此可以允许大范围的审查,并易于实现.
密码的"强度"基于所使用的加密算法,以及所使用的密钥长度(即,强度指的是解密工程师寻找或猜测某个特定算法中使用的密钥值所要求的时间长度).
8ITU-TM.
3016.
3建议书(04/2005)安全协议(如IPsec,SSL/TLS,SSH)一般都提供数据源鉴权,数据完整性和数据机密性(见A对IPsec,SSL/TLS和SSH安全协议的讨论).
其他协议,如简单网络管理协议第3版(SNMPv3)5,公共对象请求代理体系(CORBA),边界网关协议和开放的最短路径优先协议等的安全扩展也都设计为可以提供数据源鉴权和数据完整性.
用于产生、存储、分配、销毁和废除数据机密性加密密钥的方法是非常重要的.
另外,其他因素,如密钥长度、密钥选择、算法选择等也对一个专用密码系统的安全强度具有直接的影响和作用.
6.
4.
1对称的数据机密性对称的,或安全的密钥加密指的是这样一个加密系统,在此加密系统中加密和解密密钥是相同的.
对称的密码系统要求在进行初始分配时对每个用户都共享一个唯一的安全密钥(如加密密钥).
密钥必须通过一个安全的途径提供给每个用户,或由用户内部产生(如根据某个共享的安全根密码),因为知道了加密密钥就意味着知道了解密密钥,反之亦然.
数据机密性安全机制可能会基于对称的加密算法,如数据加密标准(DES),高级加密标准(AES),三倍数据加密算法(3DES),和其他算法等.
DES是一个已经应用了多年的56-比特的对称加密算法.
由于它具有短的密钥长度,因此在使用大量的并行计算时,DES由于密钥的枯竭而广受争议,目前DES被认为是较弱的算法.
美国国家标准和技术协会(NIST)对DES给出了较低的评价.
NIST选择了AES来替代DES作为美国政府应用的标准对称加密算法.
AES的密钥长度可为128比特,192比特和256比特.
3DES从本质上来说还是DES算法,只是使用两个56-比特密钥或三个56-比特密钥运行三次.
3DES由联邦信息处理标准(FIPS)定义,见出版物46-3,《数据加密标准》,1999年10月,附录2,第22页(见网址http://csirc.
nist.
gov/publications/fips/fips46-3/fips46-3.
pdf).
3DES执行时,可以或者使用两个独立的56-比特密钥,或者使用三个独立的56-比特密钥,相应的分别可以具有112比特和168比特的强度.
然而3DES会受到所谓的"在中间相遇"的攻击,即能够将两个密钥长度的3DES强度缩减为57个比特,而不是期望的112比特.
同样的攻击可以将三个密钥长度的3DES强度缩减为112个比特,而不是期望的168比特.
这样,若需要较高的安全3DES,则要使用三个独立的密钥,而最差的强度也需要使用112比特.
DES算法由于使用较短的56-比特密钥,因此执行起来可能会相对快一些,而3DES从本质上来说,必须执行三次DES,因此会慢很多.
AES,具有的最短的密钥长度为128比特,其加密强度要强于3DES,然而在硬件和软件上执行速度都可能非常快.
例如,AES的一个软件实现,与DES在同一个平台上运行,其执行速度几乎接近于DES,但是密码强度要远远强于DES.
机制24:基于DES加密算法的对称数据机密性.
5SNMPv3也可能提供机密性.
ITU-TM.
3016.
3建议书(04/2005)9机制25:基于AES加密算法的对称数据机密性.
机制26:基于3DES加密算法的对称数据机密性.
6.
4.
2不对称数据机密性不对称加密系统指的是这样一个加密系统,在此加密系统中加密和解密密钥是相关但不同的.
其中一个密钥为公共密钥(公钥),而另一个密钥为私密密钥(私钥).
公钥不同于私钥,并且要从公钥中导出私钥在计算上是不可行的.
公钥被广泛地发布,而私钥总是保持私密.
数据机密性安全机制可能会基于不对称加密算法,如RivestShamirAdleman(RSA),椭圆曲线加密法(ECC)和其他等.
RSA算法是一种广泛应用的不对称算法,可以应用于加密和数字签名.
RSA基于大素数因子分解的数学难点.
RSA算法的公钥长度为1024比特和2048比特.
注意:具有2048比特长度密钥的RSA在加密强度上与128比特密钥长度的对称加密算法的强度基本相同.
椭圆曲线加密法(ECC)是一种用于公钥加密的新方法(相比较RSA算法而言).
使用ECC算法,在某个特定的域中定义一个椭圆曲线,然后,可以解决该域的椭圆曲线离散对数问题.
与其他公钥算法相比,ECC算法的主要优势在于它的密钥长度,一个160-比特长度的ECC密钥在安全性上与一个1024-比特长度的RSA密钥的安全性基本相同.
一个210-比特长度的ECC密钥在安全性上与一个2048-比特长度的RSA密钥的安全性基本相同.
更小的ECC密钥长度,意味着更低的计算开销和一个更有效的加密系统6.
机制27:基于指定密钥长度的RSA加密算法的不对称数据机密性.
机制28:基于指定密钥长度的ECC加密算法的不对称数据机密性.
6.
4.
3数据机密性—小结为提供数据机密性,可能会使用到的算法示例以表格方式列于表3中.
一些议题必须被考虑到,如格式化、填充、错误处理条件、选择合适的素数、公用指数的大小等,以及在ECC算法中,基域和曲线也必须被考虑到,然而,这些议题都不在本建议书的范围之内.
表3/M.
3016.
3-数据机密性加密算法示例类别算法说明AES高级加密标准3-DES三倍数据加密算法对称加密算法DES数据加密标准RSARivest,Shamir,Adleman不对称加密算法ECC椭圆曲线加密法6关于RSA,Diffie-Hellman和ECC算法的更详细信息见《数字签名标准》,2002年11月(网址在http://csrc.
nist.
gov/cryptval/dss.
htm).
10ITU-TM.
3016.
3建议书(04/2005)6.
5数据完整性使用数据完整性安全机制来保证被传送的数据不被修改.
数据完整性基于密码基础.
密码系统使用基于标准的和公众可用的特定算法,因此可以允许大范围的审查,并易于实现.
安全协议(如IPsec,SSL/TLS,SSH)除了提供其他安全服务,如数据机密性和数据源鉴权外,一般都提供基于底层加密算法的数据完整性(见A对IPsec,SSL/TLS和SSH安全协议的讨论).
用于产生、存储、分配、销毁和废除数据完整性加密密钥的方法是极为重要的.
另外,其他因素,如密钥长度、密钥选择、算法选择等也对一个专用密码系统的安全强度具有直接的影响和作用.
6.
5.
1对称数据完整性对称的,或安全的密钥加密指的是这样一个加密系统,在此加密系统中信息发送方和接收方所使用的用于数据完整性的密钥是相同的.
对称的密码系统要求在进行初始分配时对每个用户都共享一个唯一的安全密钥(如验证密钥).
密钥必须通过一个安全的途径提供给每个用户,或由用户内部产生(如根据某个共享的安全根密码).
对于任意长度消息的对称数据完整性安全机制都可能基于键控的消息摘要算法与哈希函数相结合.
键控的消息摘要算法包括:具有消息摘要5的散列消息认证代码(HMAC-MD5-96)7算法和具有安全散列算法1的散列消息认证代码(HMAC-SHA-1-96)8.
机制29:基于HMAC-MD5-96加密算法的对称数据完整性.
机制30:基于HMAC-SHA-1-96加密算法的对称数据完整性.
6.
5.
2不对称数据完整性不对称数据完整性系统指的是这样一个系统,在此系统中签名和验证所使用的密钥是相关但不同的.
其中验证密钥为公共密钥(公钥),而签名密钥为私密密钥(私钥).
签名密钥不同于验证密钥,且从验证密钥中导出签名密钥是不可行的.
验证密钥被广泛地发布,而签名密钥总是保持私密.
数据完整性安全机制可能基于不对称的加密算法,如数字签名算法(DSA)和RivestShamirAdleman(RSA)算法.
具备不对称数据完整性安全机制后,发送方可以使用一个签名密钥(私钥)来对一个消息摘要作出标记,同时接收方使用验证密钥(公钥)来验证消息摘要所作的标记是由声明的发送方所做出的.
机制31:基于指定密钥长度的DSA加密算法的不对称数据完整性.
机制32:基于指定密钥长度的RSA加密算法的不对称数据完整性.
7互联网工程工作小组(IETF)RFC2403,《ESP和AH中HMAC-MD5-96的使用》,C.
Madson,R.
Glenn,1998年11月.
8互联网工程工作小组(IETF)RFC2404,《ESP和AH中HMAC-SHA-1-96的使用》,C.
Madson,R.
Glenn,1998年11月.
ITU-TM.
3016.
3建议书(04/2005)116.
5.
3数据完整性—小结为提供数据完整性,可能会使用到的算法示例以表格方式列于表4中.
一些议题必须被考虑到,如格式化、填充、错误处理条件、选择合适的素数等,然而,这些议题都不在本建议书的范围之内.
表4/M.
3016.
3-数据完整性加密算法示例类别算法说明不对称消息验证算法DSA数字签名算法HMAC-MD5-96具有消息摘要5的散列消息认证码对称消息验证算法HMAC-SHA-1-96具有安全散列算法1的散列消息认证码6.
6审计跟踪网元和管理系统应当提供足够的能力允许进行调查、审计、实时检测、分析和保护等活动,这样才能够实施正确的补救措施.
本节考虑了用于安全审计日志的安全机制.
关于安全审计日志的内容和格式的更详细信息不在本建议书的定义范围之内.
安全审计日志存储在网元和管理系统中.
这些安全日志可能存储于本地,也可能会传送到一个中央日志库和/或日志分析设备.
Syslog是用于将安全审计日志从本地存储设备传送到中央日志库的一种通用机制.
一般而言,一个设备能够将任何活动存入日志,包括:修改安全属性和服务,修改访问控制,或修改设备的其他配置参数,每次登录企图及其结果,以及每次退出或会话终止等,不论是通过远端执行还是通过控制台执行.
将与OAM&P消息相关的非安全事件,有时又称为"最新修改"的消息记入日志,对所有可审计的行为来说是必须的.
网元或管理系统将审计日志记录加上顺序标签,并进行密码鉴权(标记)后,可能将审计日志记录发送到一个不能变更的审计服务器中.
安全审计日志可能通过一个可信任的路径发送到中央库.
为确保对行为的正确分析,大量日志原始资料的日期和时间必须被正确地和安全地同步(如通过NTPv3).
机制33:基于Syslog的安全审计日志.
机制34:安全审计日志记录包含如下信息:机制34a:关于活动或已记入日志的实际行为的描述.
机制34b:发起活动的用户或进程的身份及安全级别.
机制34c:活动发生的日期和时间.
机制34d:网络源和目的地信息,若需要时(如登录时).
机制34e:活动执行的成功或失败指示.
机制34f:需要审计的任何行为.
机制35:发送到一个不能变更的审计服务器中的安全审计日志.
12ITU-TM.
3016.
3建议书(04/2005)机制36:已进行密码签名的安全审计日志.
机制37:通过一个可信任的路径发送到中央库的安全审计日志.
6.
7密钥交换对于对称数据机密性和对称数据完整性应用程序,加密密钥必须在终端系统间安全地交换.
这些对称算法的密钥常规应当通过一种与鉴权紧密绑定的过程进行交换,以免入侵者在鉴权过程和密钥分发过程之间得逞.
用于产生、存储、分配、销毁和废除这些加密密钥的方法是极为重要的.
另外,其他因素,如密钥长度、密钥选择、算法选择等也对密码系统所提供的安全性具有直接的影响和作用.
有不同的方法能够用于指配和/或交换加密密钥.
一个概念上很简单的方法是预共享密钥交换,即密钥被带外发送,且指配给每一个必要的终端系统.
例如,密钥能够由授权的网络管理者选择并配置给终端系统.
在终端系统数量较少时,可以采用预共享密钥交换,但对于具有大量终端系统的情况而言,这种方法的扩展性不好,因为这种方法在产生和配置大量密钥时会变得很繁琐.
不对称算法,如Rivest,Shamir,Adleman(RSA)能够用于支持密钥交换服务.
使用RSA,一个终端系统选择对称加密密钥,并且在RSA加密算法的保护下将密钥发送到其他终端系统.
使用该方法时,不对称算法应当具有适当的密钥长度以保护被发送的对称密钥.
例如,为了保护一个128-比特的对称密钥,RSA算法应当使用2048-比特长度密钥或更长密钥,所使用的密钥加密强度应当与128-比特对称密钥的加密强度大致相当.
Diffie-Hellman密钥一致算法是用于密钥分发的一种通用方法.
使用Diffie-Hellman算法,终端可以通过一个公众网络独立地获得安全对称加密密码.
在Diffie-Hellman过程中,仅有中间结果在终端间发送,且安全密钥决不会被泄漏.
如果选择了正确的Diffie-Hellman素数个数,对于入侵者而言,要从中间结果中导出安全密钥,在计算上是不可行的.
对于RSA算法和Diffie-Hellman算法,一些议题也必须被考虑到,如选择合适的素数,选择公共指数,错误处理条件等.
机制38:基于预共享密钥的加密密钥交换.
机制39:基于指定RSA密钥长度的不对称RSA算法的加密密钥交换.
机制40:基于Diffie-Hellman密钥一致算法,且拥有一个特定的Diffie-Hellman素数组的加密密钥交换.
6.
8告警上报在检测到任何安全侵害,或不能够继续记录审计日志时,都应当向管理员发送安全告警.
机制41:安全告警上报机制,如X.
736建议书中所定义.
ITU-TM.
3016.
3建议书(04/2005)136.
9分组过滤为了保护DCN不受袭击,且不丢失DCN的信息,应当对基于分组连接的设备使用分组过滤功能.
机制42:基于如下一个或多个检测条件的分组过滤:机制42a:源IP地址.
机制42b:目的地IP地址.
机制42c:协议.
机制42d:源端口.
机制42e:目的地端口.
并且提供如下一个或多个行为:机制42f:通过.
机制42g:停止.
机制42h:修改.
机制42i:前向.
并且应具备潜在的能力来考虑到之前的决定(即状态相关的).
附录IIPsec,SSL/TLS和SSH安全机制I.
1IPsecIPsec明确了IP层的安全,通过联合使用加密和协议安全机制来提供IPSec.
IPSec协议在网络层(层3)和传输层(层4)间运行,能够用于保护任何类型的数据流(TCP或UDP),且独立于应用程序.
设计IPSec是用来为IPv4和IPv6提供具有交互能力的、高质量的、基于加密系统的安全机制.
IPSec提供的安全服务集包括:a)数据完整性;b)基于IP地址的数据源鉴权;c)机器到机器的鉴权;d)抗重放保护;e)数据机密性;f)加密密钥交换.
为满足这些目标,需要用到两类业务流安全服务:认证头(AH)和封装的安全负载(ESP),同时,还需要用到加密密钥管理程序和协议.
认证头(AH)服务为IP分组提供了数据源鉴权、机器到机器的鉴权和数据完整性.
封装安全负载(ESP)服务除为IP分组提供数据源鉴权,机器到机器的鉴权和数据完整性外,还提供了数据机密性服务.
IPsec机制的设计独立于加密算法,这种设计可以允许选择不同的算法集,而不会影响到其他方面的实现.
14ITU-TM.
3016.
3建议书(04/2005)密钥管理由互联网密钥交换(IKE)协议来提供.
终端之间密钥的协商可以手工进行,也可以自动进行.
自动的密钥协商可以基于预共享的密钥(如口令)或是X.
509建议书中定义的信任书.
参见[RFC2401],[RFC2402],[RFC2403],[RFC2404],[RFC2405],[RFC2406],[RFC2407],[RFC2408],[RFC2409],[RFC2410],[RFC2411],[RFC2412],[RFC3602],[RFC2451],[FIPS-197].
I.
2SSL/TLS安全套接层(SSL)安全协议为传输层(层4)的TCP/IP连接提供数据加密、服务器鉴权、消息完整性和可选的客户鉴权服务.
SSL当前版本为3.
0.
传输层安全(TLS)是SSL的IETF标准版本,其超越SSL的安全增强点包括:要求支持Diffie-Hellman和DSA数字签名算法(DSA),可选支持RSA.
使用增强的散列消息鉴权算法(HMAC)来替代一个非标准的,SSL定义的MAC算法.
修改了密钥生成算法,该算法使用MD5(消息摘要5)和带有HMAC的SHA-1(安全哈希算法1).
SSL/TLS协议运行在网络层之上(层4),并且仅能与传输控制协议(TCP)共同工作,而不能与用户数据报协议(UDP)共同工作.
一般运行在SSL/TLS之上的应用层协议包括,但不限于:超文本传输协议(HTTP),简便目录访问协议(LDAP),以及互联网消息访问协议.
更高层的应用层协议也可以运行在SSL/TLS之上,但不需关心SSL/TLS的任何细节,然而,应用层必须通过使用I/O回调函数与SSL/TLS相连接起来.
SSL/TLS协议为TCP业务流提供了三个安全功能:数据机密性、数据完整性和鉴权.
SSL/TLS安全协议体系结构提供了两个可以运行在TCP之上的层:SSL/TLS上层协议;SSL/TLS记录协议.
SSL/TLS上层协议包括:SSL/TLS握手协议,SSL/TLS密码交换协议和SSL/TLS警报协议.
SSL/TLS会话由SSL/TLS握手协议最初发起,提供如下功能:a)鉴权和安全机制的协商.
b)客户端和服务器端的鉴权(使用服务器或客户的公钥/私钥).
c)建立安全密钥.
一旦SSL/TLS会话被建立,即可使用SSL/TLS记录协议来提供批量数据传输服务.
SSL/TLS记录协议提供如下功能:a)基于服务器密钥的数据源鉴权.
b)数据完整性.
c)机密性.
注意:目前SSL的版本为版本3(SSLv3),TLS的版本为版本1.
不建议使用更早的SSL和TLS版本.
ITU-TM.
3016.
3建议书(04/2005)15SSL/TLS允许使用单向鉴权或双向鉴权,在单向鉴权中,仅有服务器端对客户端进行鉴权;而双向鉴权中,客户端和服务器端相互进行鉴权.
单向鉴权是在公众互联网中常用的方法.
对于网络管理应用程序,建议使用双向鉴权,让通信双方都知道正在与他们通信的对方,正是想与之通信的终端.
参见[RFC2246],[RFC3546],[SSLV3].
I.
3SSHSSH是应用层(层7)安全协议,一般用来直接替代不安全的协议如Telnet和文件传输协议(FTP)等.
Telnet和FTP是不安全的协议,因为它们显式地传送口令及其他所有的数据.
SSH也可通过使用端口前向方式来保护其他协议,因此SSH可作为通用的网络安全协议来使用.
SSH有两个版本:SSHv1和SSHv2.
SSHv1发布于1998年,现在认为它是不安全的,并且已经被废除了.
安全外壳第2版(SSHv2)的特性有:完整地替代Telnet,Rlogin,Rsh,Rcp和FTP协议,以提供安全的文件传输和文件拷贝.
对用户进行自动鉴权(口令不以明文传递).
双向鉴权(服务器端和客户端均被鉴权).
通过使用端口前向技术对随机的基于TCP/IP的应用程序进行隧道化.
对数据进行加密以提供数据机密性.
多种鉴权选择,包括口令、公钥和安全ID鉴权.
多个密码组可用.
SSHv2体系结构包括三个主要的组件:传输层协议[SSH-TRANS]提供服务器鉴权,数据机密性和数据完整性.
该部分还可能可选地提供压缩功能.
用户鉴权协议[SSH-USERAUTH]为服务器对客户端的用户进行鉴权.
连接协议[SSH-CONNECT]将加密隧道复用到多个逻辑通道中.
连接协议提供的通道可以用于更广泛的目的.
可为建立安全的交互式Shell会话提供标准的方法,也可为前向(隧道化)随机的TCP/IP端口和连接等提供标准的方法.
端口号22已经在IANA中注册为SSHv2应用程序使用的标准端口.
参见[SSH-ARCH],[SSH-TRANS],[SSH-USERAUTH],[SSH-CONNECT].
16ITU-TM.
3016.
3建议书(04/2005)附录II本附录描述了分组过滤的机制,分组过滤是用来加强数据通信网(DCN)的安全性.
数据通信网(DCN)是连接管理应用程序(常位于网络操作中心)和网元之间的网络,可以提供集中的指配、告警监视、测试、计费、以及其他网络管理活动.
RFC3871中的2.
8–2.
10小节提供了一个需求集,来对大型的互联网服务提供商的IP网络基础设施进行分组过滤.
本文稿引用RFC3871来定义对DCN的过滤.
分组过滤是一个过程,该过程基于某种确定的匹配条件9,来决定对每个通过网元的分组进行部署.
可以有几种部署方式,如:通过、停止、前向(直接发向其他地方)等.
分组过滤通过决定将什么样的业务流通过网元或管理系统来提供基本的保护机制.
主要考虑的是对从其他网络(如承载着客户业务流的网络,对等的管理网络系统等)进入到DCN的流量进行过滤.
另外,DCN的某些特定网元需要与其他网元隔离开来,因此,过滤也可应用于DCN的不同子网(或域)之间.
II.
1目标分组过滤机制的主要目标在于:1)从客户业务流方面保护DCN基础设施.
这种保护应当包括适当共享公共资源以避免服务质量的下降或服务拒绝.
2)从对等网络方面保护DCN基础设施.
3)预防DCN中与所应用的安全策略不一致的业务流量通过DCN基础设施传播到更多的地方.
II.
2影响分组过滤的网络设计考虑事宜本附录并不暗示DCN设计的需求,然而,DCN的设计和部署会影响到网络中分组过滤的部署和需求.
图II.
1显示了一个典型的DCN设计.
9分组过滤的描述与分组路由很相似;然而,本附录关注的是分组过滤,而不是分组路由.
ITU-TM.
3016.
3建议书(04/2005)17图II.
1/M.
3016.
3-通用的DCN示例有三种类型的DCN设计得到了普遍的认可:带内管理:DCN使用承载客户数据的业务网络所保留的带宽.
例如,以太网链路上的一个VLAN可被用来承载管理业务流,或者一个IPSec或SSH连接可被用于互联网连接之上(如图II.
1中,NOC技术在互联网之上被连接).
带外管理:DCN是一个与承载客户业务流的业务网络完全不同的网络.
该网络可覆盖在承载客户数据流的物理网络之上.
混合方式:结合带内管理和带外管理两种方式.
对这三种管理体系结构的比较和通用讨论已经超出了本建议书的范围(见RFC3871的第2.
2节);然而,使用其中的哪一种将影响到对过滤的需求.
用于创建DCN的基本原理会根据所支持的网元种类、操作程序、以及参数选择、网络拓扑、经济等各方面的不同而有所变化,网络能力、恢复性,以及安全性等都是在设计每种类型的DCN时需要考虑的问题.
下一代被管理的业务供应将使用基于分组(如帧中继,ATM,IP,MPLS,以太网等)的传输设备来实现.
这些业务的出现将使得对接入设备(CPE)的管理成为必须.
18ITU-TM.
3016.
3建议书(04/2005)在必要时,可能会使用如下一种混合模型:在临界点(POP)使用带外管理,而在POP到CPE接入设备间使用带内管理,因为要在所有到CPE接入设备的通路上都使用带外管理在经济上可能是不可行的.
图II.
1中的"接入网元B"显示了后一种情况.
在这种情况下,增强的过滤(如防火墙)能够用来保护DCN不受CPE的侵袭.
带内连接的另一个例子是对一个远端的,孤立的POP的管理,这种情况下,建立一个分离的网络是不可行的,应将业务网作为DCN的一个备份.
使用分组过滤也意味着DCN使用的地址空间与分配给客户的地址空间是分离的,且在这两个域间没有进行业务流交换的需求.
地址空间的分离简化了分组过滤器的开发,分组过滤器可用来阻塞客户到管理资源的业务流.
最简单的方法是将源于DCN之外的所有流向DCN的业务流量全部阻塞,这样来保护管理基础设施不受客户业务流的侵袭.
然而,在某些情况下,业务流是必须在网外和DCN之间交换的,如两个服务提供商之间管理信息的交换(如两个SP之间位于中间点的DCC).
因此,必须实施指配以允许一些受限的业务流在不同的域间流动,且需要更多的控制(如增强的分组过滤)来提供足够的DCN安全.
图II.
1显示了基于上述假设的DCN的设计.
业务传输(图中蓝线)承载着客户的业务流.
DCN(图中红线)承载着管理业务流.
服务中心中包括向客户提供服务的服务器,以及客户所要访问的服务器(如软交换机)等.
数据中心中包括用来对网络进行管理和监视的服务器和其他运行系统,客户不会直接访问这些服务器.
从DCN到网元的连接可以使用IP、X.
25、异步或ISOCLNS等.
在DCN和业务网络的边界提供输入分组过滤是在'接入网元'中提供DCN安全的基本需求.
然而,这样的分组过滤可能还不够,因为侵袭可能来自DCN内部的一个网元或主机.
因此,适当的分组过滤机制需要在DCN的多个点上进行战略实现,以确保与所应用的安全策略相一致.
另外,当DCN连接到外部网络(如互联网,SP的企业网,合作伙伴的网络等)时,可能需要实现增强的分组过滤.
由于分组过滤是整个网络安全策略的一个组成部分,因此它的使用必须在整个网络安全原则和策略的上下文中,网络安全原则和策略包括如区域划分和防御深度等.
由于一个好的安全策略包括对主机自身(如软交换机)的安全需求,以及网络的区域划分等,这些都不在本建议书的范围之内.
为了保护管理基础设施,以及一般意义上的DCN,对于网络操作员来说,将从DCN边界外(如从对等实体或从客户端)接收到的一些分组丢弃掉的措施是有用的.
例如,具有无效源IP地址的分组,以及要发向DCN内部专用IP地址的分组等都不应当被允许进入DCN的边界.
该功能被称之为输入过滤.
该需求引自[RFC3871]和[RFC2827].
有两种类型的分组过滤:基于分组头信息的基本分组过滤,通过分组头信息,能够检测到伪装源地址的分组,并将其阻塞.
增强的分组过滤,包括:—分组状态检查,这种情况下,在作过滤决定时,会使用到上下文和状态信息.
—对特定协议的动态过滤,在这种情况下,会根据协议负载所承载的信息而动态地打开过滤器.
—深度分组检测,在这种情况下,具有任何异常的,不平常的、或可疑内容的应用层协议都会被检测.
ITU-TM.
3016.
3建议书(04/2005)19II.
3基本分组过滤连接到DCN的设备应当具备选项来停止从远端接口(如客户端或对等实体)接收来的包含非法源IP地址的分组.
非法源IP地址可由以下部分组成:Bogon地址(见RFC3871的第1.
8节).
Martians(见RFC3871的第1.
8节).
未分配给客户的IP地址(或是对对等实体发送而言是非法的IP地址).
分组过滤机制应当能够基于'机制42'所定义的属性,将从外部(如从客户端)发来的,且发向分配给DCN的地址组的业务流进行过滤.
分组过滤机制应当提供精确的基于每个接口的业务流统计.
统计的粒度级别可以根据分组过滤机制的不同而变化.
设备应当能够过滤从DCN外部(如从客户端)发来的业务流,也就是说,能够基于'机制42'所定义的属性,通过任何一个接口,可能包括环回接口,将业务流直接发向网元.
分组过滤机制可能支持TMN模型中的多安全域观点,在这个模型中,一个安全域内的所有网元都必须受到一个公共安全策略的控制.
设备可能会具备能力根据业务流、异常、以及操作条件等产生适当的告警信息.
II.
4增强的分组过滤当用户和管理业务流间存在着高度的交叉时,即用户和管理业务流在网络边界并没有很好地隔离,且DCN直接连接到其他网络时,应当考虑这些建议.
另外,在被保护的子网边界(如DCN和数据中心之间)也应当使用这些过滤能力.
该机制应当检测DCN中所使用的应用协议,检测到任何异常的协议或反常的行为,都应当适当地阻塞这些业务流.
该机制应当检查DCN中业务流的内容,无论何时,都应当检测恶意的内容,如病毒、蠕虫、特洛伊等.
该机制应当提供保护以对抗拒绝服务(DoS)的攻击.
该机制应当能够进行状态相关的过滤,即在进行分组过滤时使用会话信息.
一个会话的返回业务流应当总是被允许通过.
该机制应当对网络中所有承载端口信息的协议支持动态针孔能力,这些协议包括如FTP,SIP等.
分组过滤机制应当检查负载中的端口信息,并且在会话的生命周期中打开该指定端口(动态针孔)的通信.
一旦当会话突然终止时,应当存在一个适当的超时机制来关闭端口.
该机制应当支持协议的强制执行,包括停止错误的分组,或停止不正确的会话建立等.
其他所建议的过滤能力可参见RFC3871中的2.
7-2.
10节.
20ITU-TM.
3016.
3建议书(04/2005)参考资料[RFC2827]IETFRFC2827(2000),NetworkIngressFiltering:DefeatingDenialofServiceAttackswhichemployIPSourceAddressSpoofing.
[RFC2401]IETFRFC2401(1998),SecurityArchitecturefortheInternetProtocol,http://www.
ietf.
org/rfc/rfc2401.
txtnumber=2401[RFC3704]IETFRFC3704(2004),IngressFilteringforMultihomedNetworks.
[RFC3871]IETFRFC3871(2004),OperationalSecurityRequirementsforLargeInternetServiceProvider(ISP)IPNetworkInfrastructure.
[NDS/IP]3GPPTS33.
210(2001),3rdGenerationPartnershipProject;TechnicalSpecificationGroupServicesandSystemAspects;3GSecurity;NetworkDomainSecurity;IPnetworklayersecurity.
[RFC2402]IETFRFC2402(1998),IPAuthenticationHeader,http://www.
ietf.
org/rfc/rfc2402.
txtnumber=2402[RFC2403]IETFRFC2403(1998),TheUseofHMAC-MD5-96withinESPandAH,http://www.
ietf.
org/rfc/rfc2403.
txtnumber=2403[RFC2404]IETFRFC2404(1998),TheUseofHMAC-SHA-1-96withinESPandAH,http://www.
ietf.
org/rfc/rfc2404.
txtnumber=2404[RFC2405]IETFRFC2405(1998),TheESPDES-CBCCipherAlgorithmwithExplicitIV,http://www.
ietf.
org/rfc/rfc2405.
txtnumber=2405[RFC2406]IETFRFC2406(1998),IPEncapsulatingSecurityPayload(ESP),http://www.
ietf.
org/rfc/rfc2406.
txtnumber=2406[RFC2407]IETFRFC2407(1998),TheInternetIPSecurityDomainofInterpretationforISAKMP,http://www.
ietf.
org/rfc/rfc2407.
txtnumber=2407[RFC2408]IETFRFC2408(1998),InternetSecurityAssociationandKeyManagementProtocol(ISAKMP),http://www.
ietf.
org/rfc/rfc2408.
txtnumber=2408[RFC2409]IETFRFC2409(1998),TheInternetKeyExchange(IKE),http://www.
ietf.
org/rfc/rfc2409.
txtnumber=2409[RFC2410]IETFRFC2410(1998),TheNULLEncryptionAlgorithmandItsUsewithIPsec,http://www.
ietf.
org/rfc/rfc2410.
txtnumber=2410[RFC2411]IETFRFC2411(1998),IPSecurityDocumentRoadmap,http://www.
ietf.
org/rfc/rfc2411.
txtnumber=2411[RFC2412]IETFRFC2412(1998),TheOAKLEYKeyDeterminationProtocol,http://www.
ietf.
org/rfc/rfc2412.
txtnumber=2412[RFC3602]IETFRFC3602(2003),TheAES-CBCCipherAlgorithmandItsUsewithIPsec,http://www.
ietf.
org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-04.
txt[RFC2451]IETFRFC2451(1998),TheESPCBC-ModeCipherAlgorithms,http://www.
ietf.
org/rfc/rfc2451.
txt[RFC2246]IETFRFC2246(1999),TheTLSProtocol,Version1.
0,ftp://ftp.
rfc-editor.
org/in-notes/rfc2246.
txt[RFC3546]IETFRFC3546(2003),TransportLayerSecurity(TLS)Extensions,ftp://ftp.
rfc-editor.
org/in-notes/rfc3546.
txtITU-TM.
3016.
3建议书(04/2005)21[SSLV3]SecureSocketLayerVersion3.
0Specification,NetscapeCommunications.
http://wp.
netscape.
com/eng/ssl3/[SSH-ARCH]YLONEN(T.
):SSHProtocolArchitecture,I-Ddraft-ietf-architecture-15.
txt,October2003.
http://www.
ietf.
org/internet-drafts/draft-ietf-secsh-architecture-15.
txt[SSH-TRANS]YLONEN(T.
):SSHTransportLayerProtocol,I-Ddraft-ietf-transport-17.
txt,October2003.
http://www.
ietf.
org/internet-drafts/draft-ietf-secsh-transport-17.
txt[SSH-USERAUTH]YLONEN(T.
):SSHAuthenticationProtocol,I-Ddraft-ietf-userauth-18.
txt,September2002.
http://www.
ietf.
org/internet-drafts/draft-ietf-secsh-userauth-18.
txt[SSH-CONNECT]YLONEN(T.
):SSHConnectionProtocol,I-Ddraft-ietf-connect-18.
txt,October2003.
http://www.
ietf.
org/internet-drafts/draft-ietf-secsh-connect-18.
txt[FIPS-46-3]DataEncryptionStandard.
(DescribesbothDESand3DES).
http://csrc.
nist.
gov/publications/fips/fips46-3/fips46-3.
pdf[FIPS-197]AdvancedEncryptionStandard(AES),FIPSPublication197,NationalInstituteofStandardsandTechnology,November2001.
http://csrc.
nist.
gov/publications/fips/fips197/fips-197.
pdf[RFC2437]IETFRFC2437(1998),PKCS#1:RSACryptographySpecificationsVersion2.
0,http://www.
ietf.
org/rfc/rfc2437.
txtnumber=2437瑞士印刷2005年,日内瓦ITU-T系列建议书A系列ITU-T工作的组织D系列一般资费原则E系列综合网络运行、电话业务、业务运行和人为因素F系列非话电信业务G系列传输系统和媒质、数字系统和网络H系列视听和多媒体系统I系列综合业务数字网J系列有线网和电视、声音节目及其他多媒体信号的传输K系列干扰的防护L系列线缆的构成、安装和保护及外部设备的其他组件M系列电信管理,包括TMN和网络维护N系列维护:国际声音节目和电视传输电路O系列测量设备技术规程P系列电话传输质量、电话装置、本地线路网络Q系列交换和信令R系列电报传输S系列电报业务终端设备T系列远程信息处理业务的终端设备U系列电报交换V系列电话网上的数据通信X系列数据网和开放系统通信及安全Y系列全球信息基础设施、互联网的协议问题和下一代网络Z系列用于电信系统的语言和一般软件问题