RFC2617 鉴权 中文

合集下载

头压缩协议(rfc4996)中文翻译

头压缩协议(rfc4996)中文翻译

RObust Header Compression (ROHC):A Profile for TCP/IP (ROHC-TCP)摘要本文档为TCP/IP报头指定了一个健壮的头压缩机制。

该机制被称为ROHC-TCP,提供了有效且健壮的TCP头压缩,包括频繁使用的TCP选项,如SACK(选择性确认)和时戳。

ROHC-TCP在错误率高和RTT长的链路上表现良好,常有许多这样的链路带宽有限,必需要头压缩。

目录1. 介绍2. 术语基础上下文基础上下文是压缩器和解压器都已经证实的上下文。

一个基础上下文可以被用来作为使用复制建立新上下文的参考基础上下文标识符(基础CID)基础CID是标识基础上下文的CID,从基础上下文中可以提取到上下文复制时需要的信息基础报头未压缩报文的最里层的IP和TCP报头的压缩形式链接条目一条链基于相似的特性组合条目。

ROHC-TCP为静态、动态、可复制或不规则的条目定义条目链。

链接是通过为每个报头添加条目来完成的,例如以条目在未压缩报文中出现顺序来添加给链。

上下文复制(CR)上下文复制是一种基于另外一个存在的有效上下文(一个基础上下文)来建立和初始化一个新上下文的机制。

引入这个机制是为了减少上下文建立流程的负载,特别适用于压缩多个短暂TCP连接,这些连接可能同时或近乎同时发生ROHC-TCP报文类型ROHC-TCP使用3种报文类型:初始和刷新(IR)报文类型,上下文修复(IR-CR)报文类型和压缩(CO)报文类型短暂(Short-lived) TCP传输是指用每个单个连接只传输少量报文的TCP连接2.1缩写2.2翻译术语Profile 机制Packet报文Header 报头、头Fields字段、域formal notation标注格式3. 背景3.1现存TCP/IP头压缩机制3.2TCP/IP头字段分类报文有可能压缩正是由于报文(尤其是连续的报文)的头字段之间有很大的冗余。

对于TCP/IP 头压缩要利用这些特性,了解各种头部字段的变化模式就很重要。

电信SIP规范(协议细则)

电信SIP规范(协议细则)
目录
1 范围......................................................... 3 2 编制说明 ..................................................... 3 3 SIP 及其扩展规范 .............................................. 4
中国电信 SIP规范
用户终端 代理服务 SIP-ISUP B2BUA
UA

互通单元
---
---
---
---
注册服务 器 --- 1.
2.
说明
本章主要描述 User Agent 的行为,但由于实现 proxy 功能的实体在处理消息时 可能转而承担 UAC 或 UAS 的角色,因此 16 章 中有些内容的描述也参照 了本章。但本章中的某些 细节性规定并不适合 UAC 或 UAS 在第 16 章中 的应用场合。 根据第 1 点的说明,本章 中对 Proxy 的要求实质上 是对实现 Proxy 功能的实 体在转而承担 UAC 或 UAS 角色时的要求,因此 本章内容对此种应用场合 下的 UAC 或 UAS 而言可 能都是部分要求。为了说 明上的方便,本章内容对 于“Proxy”只存在“要求” 或“不适用”,如果有特 殊考虑将在“说明”一栏 中进行解释
5.1 invite 消息................................................................................................................ 66 5.2 ACK........................................................................................................................67 5.3 BYE ........................................................................................................................ 67 5.4 CANCEL ................................................................................................................. 69 5.5 REGISTER............................................................................................................... 69 5.6 OPTIONS................................................................................................................. 70 5.7 INFO....................................................................................................................... 71 5.8 PRACK.................................................................................................................... 72

RFC2351 MATIP 航空协议

RFC2351 MATIP 航空协议

组织:中国互动出版网(/)RFC文档中文翻译计划(/compters/emook/aboutemook.htm)E-mail:********************译者:吕新阳(lv_xinyang *******************)译文发布时间:2002-5-3版权:本中文翻译文档版权归中国互动出版网所有。

可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。

Network Working Group A. Robert Request for Comments: 2351 SITA Category: Informational May 1998航空订座、票务及报文数据流在IP网络上的映射(RFC 2351 ——Mapping of Airline Reservation, Ticketing,and Messaging Traffic over IP )本备忘录的状态本文档讲述了一种Internet社区的信息,它不特指任何一种Internet标准。

本备忘录的发布不受任何限制。

版权声明Copyright (C) The Internet Society (1998). All Rights Reserved.安全性声明本文未全面考虑安全性的问题。

本文所提供的协议本身没有包含任何安全机制,其原因在于,数据流可以通过使用静态标识的外部机制来认证或使用文本密码机制,任何一种机制提供可靠的安全保证。

本文也概括性的指出了通过使用IPSEC对数据流加密的方法,但此方法仅供参考。

摘要本文档介绍了一种用协议,用于在IP网络上传输封装有航空专用协议的数据包。

目录1.介绍 (2)2.术语及缩略语 (4)3.分层模型 (6)4. 流标识 (7)5. TCP端口分配 (7)6. MA TIP会话建立 (7)7. TYPEA及TYPE B包结构概览 (9)8. TYPEA会话流的MA TIP包结构 (9)8.1控制包格式 (9)8.1.1 打开会话格式(SO) (10)8.1.2 确认打开格式(OC) (11)8.1.3 关闭会话(SC) (13)8.2数据包格式 (13)9. TYPEA主机到主机数据流的MA TIP包结构 (14)9.1控制包格式 (14)9.1.1 打开会话格式(SO) (14)9.1.2确认打开格式(OC) (16)9.1.3 关闭会话(SC) (16)9.2数据包格式 (17)10. TYPE B数据流的MA TIP包结构 (18)10.1控制包格式 (18)10.1.1 打开会话格式(SO) (18)10.1.2 确认打开格式(OC) (19)10.1.3 关闭会话(SC) (20)10.2数据包格式 (20)11. 安全考虑 (20)12. 作者地址 (21)13. 版权说明 (21)1.介绍航空业全球性的数据网络应用已经超过40年,共两类主要的数据流类型:Transactional traffic:事务处理流它主要是用于在航空公司或旅游代理与中央主机系统的通信,进行座位预定和订票申请.通常方式是哑终端或PC通过数据网络访问中央主机系统(IBM或UNISYS). Messaging:报文这种数据流是一种e-mail应用,不要求实时性连接.但要保证高级别的安全.寻址方式使用IATA定义的国际标准格式,其中包含城市和航空公司代码.它又称为TYPE B,传输时有高级别的保护,多点寻址并共分4个优先级.在IATA标准中定义了TYPE A和TYPE B报文的完整格式.在底层,同步协议早在六十年代,即在OSI和SNA标准之前就已经建立了.目前,在世界范围内,还有大量的传统设备在许多航空公司使用.他们还没有决定马上用开放标准的现代设备来替换现有的终端,而是寻求更加经济的方式来连接其终端至定座系统.大多数航空公司愿意从航空专署协议转换到标准协议上来,这样就可以从低成本的新技术中获益,但由于下述因素的存在使得这种转换难以很快实现:⏹应用还没有转换过去.⏹使用航空协议P1024B(IBM ALC) 或P1024C(UNISYS UTS)的哑终端数目庞大.现在有许多不同的基于网关的专属解决方案用来利用低成本的网络,但是它们不易扩展且互不兼容.未来,TCP/IP一定会更广泛的用于传输这些数据,只是因为:⏹TCP/IP 是基于UNIX应用的标准协议⏹TCP/IP栈价格低廉⏹TCP/IP 可用于企业内部网.本文档的目的是定义在TCP/IP上传输的航空专用各类数据流的映射.航空公司的系统中必须安装TCP/IP栈以支持数据流交换,如下所示:!---- ! ( )! ! ---------- ( )!---- ! ( )Type B HOST ( NETWORK )( )( ) !---o!----! ( ) -------- ! D ! ---o Type A stations!----! ---------- ( ) !---o!----! ( )TYPE A HOST !!!!--------! !--------Network Messaging System(D) : Gateway Type A router本文讨论的不同的航空专属数据流包括:-TYPE A Host / Terminal (主机到终端)-TYPE A Host/ TYPE A host(主机到主机)-TYPE B Host/ Network messaging System(主机到网络报文系统)对哑终端而言,会话必须由终端发起以使得主机和路由器之间建立一个IP连接.而如果使用智能工作站的话,只要它与网络有直接的连接,有一个TCP/IP栈和终端仿真软件,就可以建立自己到中央主机的直接IP连接.2.术语及缩略语ALC航空线路协议: IBM 航空专属协议(见P1024B)ASCII美国标准信息交换码ASCU代理设备控制单元: 用户端的一个集群.AX.25航空X.25: X.25 OSI模型的航空应用(IATA制定)BAUDOTITU-T 5定义的字母表.使用5位表示.加入填充位的BAUDOT使用7位表示,最重要位(bit 7)用于区分,第六位设置为1.BA TAPType B应用到应用协议.它是对TYPE B数据流加密的协议.由SITA定义并由IATA出版(SCR V ol. 3).EBCDIC扩充二进制编码的十进制交换码Flow ID Traffic数据流标识,用于区分主机到主机数据流的类型.HLDHigh Level Designator: 用于指示网络中某区域的进入点或退出点.IA交换地址: P1024B协议的ASCU 标识IATA国际航空运输协会IP网际协议IPARS国际程序航空定座系统:ALC中使用的编码类型.HTH主机到主机(数据流)LSB最不重要位MATIP航空数据流在网际协议的映射MSB最重要位OC确认打开(MATIP命令)OSI开放标准接口P1024BSITA对ALC(IBM 航空专属协议)的定义.使用六位填充位的参数(IPARS)和IA/TA用于物理寻址.P1024CSITA对UTS(UNISYS终端协议)的定义.使用七位参数(ASCII)和RID/SID用于物理寻址.RFU为将来使用的保留部分RID远端标识: P1024C协议的ASCU标识.SC关闭会话(MATIP命令)SCR系统和通信参考.(IATA 文档)SID栈标识: P1024C协议的终端标识SITA国际航空电讯联盟SO打开会话(MATIP 命令)TA终端地址: P1024B协议的终端标识TCP传输控制协议TYPE A Traffic交互数据流或点对点TYPE B Traffic高可靠性的符合IATA格式的报文流UTS通用终端系统,Unisys专属,见P1024C3.分层模型MATIP是端到端的协议.它试图在TCP层和航空应用间建立一个与路由无关的映射标准.+-------------------------------+|Airline TYPE A | Airline TYPE B|| | Application || |---------------|| Application | BATAP |+-------------------------------+| MATIP A | MATIP B |+-------------------------------+| T.C.P |+-------------------------------+| I.P |+-------------------------------+| MEDIA |+-------------------------------+4. 流标识在TYPE A 会话流中,航空主机应用通过4字节(H1,H2,A1,A2)来识别ASCU.这些字节是由主机分配并唯一的标识每一个ASCU.这样主机能够不依赖于IP地址而动态识别ASCU.H1 H2 A1 A2 字节遵从下列情况:-只使用A1,A2,而H1 H2设置为0000.-H1,H2标识会话,而A1A2标识会话中的ASCU.-H1,H2,A1,A2标识ASCU.前两种情况与AX.25映射完全兼容,HiH2与HLD等价,为十六进制表示的2字节.第三种情况更加灵活但与AX.25不兼容.在TYPEA主机到主机流中,标识域为3字节的H1 H2 Flow ID(可选).H1H2保留用来标识远端主机(与IP无关)并必须同时分配.在TYPEB流中,端系统的标识可通过使用HLDs,或者直接由一对IP地址确定. 5. TCP端口分配IANA(Internet Assigned Numbers Authority)为MATIP TYPE A和TYPE B流分配了相应端口号:MATIP Type A TCP 端口: 350MATIP Type B TCP 端口: 351通过不同的TCP端口号就可以区分数据流是type A 还是B.6. MATIP会话建立在两个应用进行数据交换之前,一个MA TIP会话必须在TCP连接上建立以确认数据流属性,如:-TYPE A数据流的子类型(Type A host to host 还是Type A conversational)-使用的多路复用情况(用于Type A)-数据头-字符集对不同的参数集,必须建立不同的会话和TCP连接.(如:两点间的P1024B和P1024C数据流需要建立两个不同的会话.)MATIP会话的建立可以由任一端初始化.在MA TIP层没有keep-alive机制.会话超时由TCP 的超时参数来控制.三个命令用于管理MATIP会话:-打开会话(SO) 用来发一个建立会话的请求.-确认打开(OC)用来确认SO命令.-关闭会话(SC)用来关闭当前的会话.MATIP会话建立的前提是相关TCP连接已经建立.然而,当关闭MA TIP会话时并不需要关闭TCP连接.典型的交换情况:TCP session establishmentSession Open ---------><----------- Open confirmdata exchange----------------------><-------------------------...Session Close ----------------->...<------------------------- Session OpenOpen confirm ------------------->data exchange<----------------------------------------------->打开会话命令可能包含配置参数.如果收到一个打开会话命令,但是同一个会话已经打开(如:相同的IP地址和端口号),这是打开会话命令可以自动清除会话中的旧配置,而用新的打开会话命令中的信息来建立新配置.如上图所示,打开和关闭命令是成对出现的.对于type A 会话流而言,SO和OC命令包含确认ASCU和会话的信息.在一个会话中通过2或4字节的信息来指示ASCU.一个标志(flag)指示ASCU是通过4字节(H1H2A1A2)还是2字节(A1A2)确认.对后者(type b)而言,H1H2保留用于会话标识.发出SO指令是为了打开MATIP会话.在Type A会话流中,它包含了此会话配置的所有ASCU 的列表.OC命令对SO命令进行确认.它可以全部或条件性的拒绝或接受它.在Type A中,它包含了会话中被拒绝或被确认的ASCU的列表.7. TYPEA及TYPE B包结构概览MATIP头部的前4个字节遵从下述规则:0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |C| Cmd | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Ver这个域标识MATIP的版本.它的值必须为001,否则包被认为无效.C指示是否为控制包.值为1时,此包是控制包值为0时,此包是数据包Cmd如果标志C的值为1,这个域标识控制命令Length这个域指出整个包的长度(字节数),包含包头.注意: 标识为可选(Opt)的域如果没使用则不会传送.8. TYPEA会话流(CONVERSATIONAL)的MATIP包结构8.1 控制包格式在MA TIP层有3个控制包打开或关闭会话.8.1.1 打开会话格式(SO)为了能够在传送数据包之前确认会话,SO命令被发送.它可以由任一端发起.当发生冲突时,IP 地址较低的一端的要求被忽略.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0|0 1|0| CD | STYP |0 0 0 0| RFU |MPX|HDR| PRES. |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| H1 | H2 | RFU ||-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reserved | RFU | Nbr of ASCUs |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Nbr of ASCUs | ASCU list (opt) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RFU保留部分,必须设为零.CD指出编码格式000: 5位(填充型的baudot)010: 6位(IPARS)100: 7位(ASCII)110: 8位(EBCDIC)xx1: R.F.USTYP指出流的子类型(对TYPE A而言)0001: TYPE A 会话流MPX指出TCP会话中的多路复用方式.可能值有:00: ASCU组,每个ASCU由4字节标识(H1H2A1A2)01: ASCU组,每个ASCU由2字节标识(A1A2)10: TCP会话中的单个ASCU.HDR指出航空专用地址的哪一部分在会话传送的报文的前面.可能值有:00: ASCU 头= H1+H2+A1+A201: ASCU 头=A1+A210: 没有头部11: 未使用MPX和HDR必须一致.当ASCU多路复用,数据必须包含ASCU标识.下表总结了允许的组合:+--------------------------+| MPX | 00 | 01 | 10 |+--------------------------+| HDR | || 00 | Y | Y | Y || 01 | N | Y | Y || 10 | N | N | Y |+--------------------------+PRES指出表示格式0001: P1024B0010: P1024C0011: 3270H1 H2当MPX=00,这两个域逻辑上标识会话.如果此域不用的话,必须设置为0.如果在MPX不为00,HDR=00的会话中,数据包中的H1H2必须同SO命令中设置的值相同.Nbr of ASCUs此域必须存在且值为每个会话中的ASCU的个数.值为0表示无法确定.这种情况下,ASCU列表不出现在’会话打开’命令中,但必须由另一端的’确认打开’命令来发送.ASCU列表包含用于每个ASCU的标识的列表.如果MPX=00,此域用4字节(H1H2A1A2)表示每个ASCU,否则用2字节(A1A2)表示.8.1.2 确认打开格式(OC)OC命令作为对SO命令的回应,通过检查每个ASCU的配置决定据绝或者接受这个会话.对接受的情况而言,OC指出被拒绝的ASCU的数目和地址.同时,它指出配置在MATIP会话中的ASCU的列表,前提是SO命令提供的列表正确无误,或者在会话中配置的ASCU的数目未知(如:ASCU数为0).8.1.2.1 拒绝连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| cause |+-+-+-+-+-+-+-+-+Cause此域指出拒绝此MA TIP会话的原因:00000001: 发送和接收方之间数据流类型不匹配00000010: SO头部的信息不一致10000100至11111111: 需应用支持其它值: 保留8.1.2.2 接受连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 0 1| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0 R 0 0 0 0 0| Nbr of ASCUs |Nbr of ASCU(opt| ASCU LIST |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R标记位,指出SO命令中ASCU配置的错误NBR of ASCUs如果SO命令中的MPX值为00,此域为2字节,否则,为1字节长.如果设置了R标志位,此域表示错误的ASCU数目.否则,指出此MA TIP会话中定义的ASCU 数目.注意: 此域的长度不是1字节就是2字节.在SO命令的对应位置,长度总是2字节.这个区别是由于兼容AX25(见第4节)的要求造成的.在SO命令中,可以在AX25 call user data中使用一个多余字节.不幸的是,在AX25 clear user data中没有那样的字节.ASCU LIST取决于R标志位,指出ASCU的列表(A1A2或H1H2A1A2),它们或者是有错误,或者是此次会话所包含的.8.1.3 关闭会话(SC)SC(关闭会话)命令用来关闭一个存在的MATIP会话.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Close Cause |+-+-+-+-+-+-+-+-+Close Cause指出会话关闭的原因:00000000: 正常关闭10000100至11111111:需应用支持其它值: 保留8.2 数据包格式0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| ID (optional) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Payload || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ID此域可选,且随会话建立过程中的HDR,PRES的值的不同而有不同的长度和格式.+------------------------------+-------------------------------+|HDR | PRES = P1024B and 3270 | PRES = P1024C |+------------------------------+-------------------------------+|00 |ID = 4 bytes H1-H2-A1-A2 | ID = 5 bytes H1-H2-A1-0x01-A2 |+------------------------------+-------------------------------+|01 |ID = 2 bytes A1-A2 | ID = 3 bytes A1-0x01-A2 |+------------------------------+-------------------------------+|10 |ID = 0 bytes | ID = 0 bytes |+------------------------------+-------------------------------+如果MPX值不为0,H1,H2的值必须同SO命令中的值匹配.Payload负载以终端标识起始:-一字节的终端标识(TA),P1024B协议使用-两字节的SID/DID终端标识,P1024C协议使用.-9. TYPEA主机到主机(HOST-TO-HOST)数据流的MATIP包结构9.1 控制包格式在MA TIP层共有3种控制包用来打开或关闭会话.9.1.1 打开会话格式(SO)打开会话命令用来在发数据包前确认会话的建立.它可以由任一端发起.当冲突发生时,忽略掉较低的IP地址一方的打开会话请求.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0|0 1|0| CD | STYP |0 0 0 0| RFU |MPX|HDR|0 0 0 0|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| H1 | H2 | RFU ||-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Flow ID(opt)|+-+-+-+-+-+-+-+-+RFU保留部分,必须设置为零.CD此域指出编码方式,同8.1.1.1部分说明.STYP指出数据流子类型(对Type A而言).0010: TYPE A IATA 主机到主机1000: SITA主机到主机MPX指出在TYPE A SITA 主机到主机的MATIP会话中使用的多路复用.可能值为:00: 无关01: 在TCP连接中为多数据流10: 在TCP连接中为单数据流HDR指出航空专用地址的哪一部分在会话传送的报文的前面.可能值有:00: 用于TYPE A SITA主机到主机的包头=H1+H2+Flow ID01: 用于TYPE A SITA主机到主机的包头=Flow ID10: 没有头部(默认为IA TA主机到主机)11: 未使用MPX和HDR必须一致.当数据流多路复用,数据必须包含数据流标识.下表总结了允许的组合:+---------------------+| MPX | 01 | 10 |+---------------------+| HDR | | || 00 | Y | Y || 01 | Y | Y || 10 | N | Y |+---------------------+H1 H2用来标识会话.如果不是用此域,值必须为0.如果HDR=00,数据包中的H1H2必须与SO命令中设置的值相同.Flow ID此域可选,指出数据流ID(范围3F –4F)9.1.2确认打开格式(OC)OC(确认打开)命令回应SO(打开会话)命令且用来接受或拒绝一个会话.9.1.2.1 拒绝连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cause |+-+-+-+-+-+-+-+-+Cause此域指出拒绝MATIP会话的原因:00000001: 在发送和接收方的数据流类型不匹配00000010: SO包头中的信息不匹配10000100至11111111: 需应用支持其它值:保留9.1.2.2 接受连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0|+-+-+-+-+-+-+-+-+9.1.3 关闭会话(SC)SC(关闭会话)命令用来关闭一个存在的MATIP会话.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |1|1 1 1 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Close Cause |+-+-+-+-+-+-+-+-+Close Cause指出会话关闭的原因:00000000: 正常关闭10000100至11111111: 需应用支持其它值: 保留9.2 数据包格式0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ID此域可选, 且随会话建立过程中的HDR的值的不同而有不同的长度和格式.+-------------------------------+|HDR | I.D. |+-------------------------------+|00 |ID = 3 bytes H1-H2 FLOW ID|+-------------------------------+|01 |ID = FLOW ID |+-------------------------------+|10 |ID nor present |+-------------------------------+Payload packet负载格式同MATIP层有关.它是按照IATA主机到主机规则编排且由发送和接收双方共同遵从.10. TYPE B数据流的MATIP包结构10.1 控制包格式在MA TIP层交换Type B数据共使用3种控制包打开或关闭会话.10.1.1 打开会话格式(SO)在发送数据包之前,建议令系统之间建立一个会话以保证它们之间能够通信(即:两个系统都支持将通过连接发送的数据流属性).基于此点要求,在TCP层连接建立之后,要马上通过使用下面定义的会话命令建立一个双向的握手.任一端都可以初始此过程.当发生冲突时,忽略掉来自较低IP地址的一端的会话打开请求.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 1 0| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0 0 0 0| C D | PROTEC| BFLAG | Sender HLD |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Recipient HLD |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length此域指出整个命令的字节数,包含头部.可能的长度只有6字节或10字节.CD指出编码方式,同8.1.1.1部分说明.PROTEC指出端到端报文应答传输协议机制.0010: BATAP其它值: 可以使用.BFLAG(X指’任意,不计’X X 0 0 指示此包中不含’发送方HLD,接收方HLD’,这种情况下,包长度为6字节.X X 1 0 指示此包中的第9,10,11,12字节分别存放’发送方HLD,接收方HLD’, 这种情况下,包长度为10字节.0 0 X X 指示连接请求由主机发出(Mainframe system).0 1 X X 指示连接请求由网关发出)Sender HLDType B 系统的HLD,用以发出打开会话命令Recipient HLDType B系统中的HLD,它是会话打开命令的目的端.10.1.2 确认打开格式(OC)OC(确认打开)命令回应SO(打开会话)命令,并接受或拒绝一个会话.10.1.2.1 拒绝连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Cause |+-+-+-+-+-+-+-+-+此包长度为5字节.Cause指出拒绝包的原因000001: 在接受和发送方的数据流类型不匹配.000010: SO头部的信息不一致000011: 安全机制类型不同000100至111111: 保留部分10.1.2.2 接受连接0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0| Ver |1|1 1 1 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0|+-+-+-+-+-+-+-+-+包长度为5字节.10.1.3 关闭会话(SC)SC(关闭会话)命令用来关闭一个存在的MATIP会话.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |1|1 1 1 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Close Cause |+-+-+-+-+-+-+-+-+Close Cause指出会话关闭的原因:00000000:正常关闭10000100 至11111111: 需应用支持其它值: 保留10.2 数据包格式0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|0|0|0|0| Ver |0|0 0 0 0 0 0 0| length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Payload || | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length此域指示整个包的字节数,包含头部.Payload按IATA标准编码的Type B 报文,并遵从应用的TYPE B服务的规则要求.11. 安全考虑对航空业来讲,数据安全异常重要.MA TIP使用者的安全机制可以在不同层实现:通过定义ASCU来保证与主机应用之间的会话.可以从两方面加以控制:通过静态配置在应用层定义ASCU地址(H1 H2 A1 A2),或使用用户账号/口令确认ASCU.大多数情况下,用户账号和口令可以通过中央主机中的软件来核实.同时他们还可以通过应用本身来检查.在TCP/IP中传输的MATIP会话可以通过防火墙.可以通过对网络(IP地址)层或TCP应用层施加控制来依赖防火墙机制保证安全性.对更高层的安全来说,所有应用可以通过对控制包实施IPSEC ESP加密实现.还可以使用重发保护,IPSEC ESP的强制加密器及NULL封装机制.数据包也可使用IPSEC ESP加密.禁止重法和使用IPSEC ESP强制加密器的完整性保护也可以使用.NULL 封装及其它的IPSEC ESP 要求的加密器也可以得到支持.12. 作者地址Alain RobertS.I.T.A.18, rue Paul Lafargue92904 PARIS LA DEFENSE 10FRANCEPhone: 33 1 46411491Fax: 33 1 46411277EMail: ****************.sita.int13. 版权说明Copyright (C) The Internet Society (1998). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain itor assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph areincluded on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.。

RFC2617 中文版

RFC2617 中文版

1.备忘 (3)2.版权申明 (3)3.摘要 (3)4.授权鉴别 (4)4.1.对HTTP/1.1规范的依赖 (4)4.2.访问鉴别框架 (4)5.基本鉴别方案 (6)6.摘要访问鉴别方案 (8)6.1.介绍 (8)6.1.1.目的 (8)6.1.2.操作概述 (8)6.1.3.摘要值的表示 (8)6.1.4.该方案的局限性 (8)6.2.摘要报头的规范 (9)6.2.1.WWW-Authenticate响应报头 (9)6.2.2.Authorization请求报头 (11)6.2.3.Authentication-info报头 (15)6.3.摘要操作 (17)6.4.安全协议讨论 (17)6.5.例子 (18)6.6.代理鉴别和代理授权 (18)7.安全考虑 (20)7.1.客户使用基本鉴别 (20)7.2.客户使用摘要鉴别 (20)7.3.受限的NONCE值使用 (21)7.4.基本鉴别与摘要鉴别的比较 (21)7.5.回放式攻击 (22)7.6.多方鉴别方案产生的缺点 (22)7.7.在线字典攻击 (23)7.8.中间人 (23)7.9.选择纯文本攻击 (23)7.10.预先计算的字典攻击 (24)7.11.批处理方式暴力攻击 (24)7.12.假冒服务器欺骗 (24)7.13.存储口令 (24)7.14.总结 (25)8.例子实现 (26)9.参考书目 (30)10.作者地址 (30)11.完整版权申明 (30)12.致谢 (30)1.备忘本文档跟踪记录Internet团体为完善协议而进行的讨论、建议。

详情请参见官方文件(STD1)。

本文可任意分发。

2.版权申明Copyright (C) The Internet Society (1999). All Rights Reserved3.摘要“HTTP/1.0”中包括基本访问鉴别方案(Basic Access Authentication scheme)。

RFC 6071(中文)-IP安全(IPsec)和互联网密钥交换(IKE)文件路线图(废止了RFC2411)

RFC 6071(中文)-IP安全(IPsec)和互联网密钥交换(IKE)文件路线图(废止了RFC2411)

本文翻译者:weicq2000RFC 6071 IP安全(IPsec)和互联网密钥交换(IKE)文件路线图(2011年2月)RFC 6071废止了RFC 2411。

摘要过去几年,定义和使用IP安全(IPsec)和互联网密钥交换(Internet Key Exchange, IKE)的RFCs数量急剧增长。

造成这种复杂情况的主要原因是这些RFCs源于许多IETF工作组:最初的IPsec 工作组,它的各种衍生组织,以及其他使用IPsec和/或IKE来保护它们的协议流量的工作组。

本文件归纳与IPsec和IKE有关的RFCs。

包括对每个RFC的简短描述,伴随背景信息介绍IPsec成长和扩展的动机及其来龙去脉。

本文件废止了RFC2411,先前的“IP安全文件路线图”。

[RFC-2411]简单描述各种等级基本IPsec文件的相互关系。

[RFC-2411]的要点是说明文件的建议内容,这些文件规定附加加密和认证算法。

本备忘录状态本文件不是互联网标准跟踪(Internet Standards Track)规范;出版它是出于提供信息目的。

本文件是互联网工程任务组(Internet Engineering Task Force, IETF)的作品。

它代表IETF 社会的共识。

它收到了公众评价并已获得互联网工程指导组(Internet Engineering Steering Group, IESG)认可和获准出版。

由IESG批准的文件不一定都是某个层次互联网标准的候选方案;参阅RFC5741第2章。

有关本文件目前状态信息,任何错误,以及如何得到有关它的反馈可以浏览:/info/rfc6071。

版权声明Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modifiedoutside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it intolanguages other than English.目录第1章序言第2章IPsec/IEK背景信息2-1 IPsec/IKE文件相互关系2-2 IPsec版本2-2-1 “旧”IPsec (IPsec-v2)和“新”IPsec (IPsec-v3)的不同2-3 IKE版本2-3-1 IKEv1和IKEv2的不同2-4 IPsec和IKE的IANA注册第3章IPsec文件3-1 基本文件3-1-1 “旧”IPsec (IPsec-v2)3-1-2 “新”IPsec (IPsec-v3)3-2 对IPsec的补充3-3 一般考虑第4章IKE文件4-1 基本文件4-1-1 IKEv14-1-2 IKEv24-2 补充和扩展4-2-1 对端认证方法4-2-2 证书内容和管理(PKI4IPsec)4-2-3 失效的对端检查4-2-4 远程访问第5章密码算法和套件5-1 算法要求5-2 加密算法5-3 完整性保护(认证)算法5-4 组合模式算法5-5 伪随机函数(PRFs)5-6 密码套件5-7 迪菲赫尔曼算法第6章多播的IPsec/IKE第7章IPsec/IKE派生物7-1 IPsec策略7-2 IPsec MIBs7-3 IP压缩( IPComp)7-4 有比没有好安全(BTNS)策略7-5 密钥的Kerberized互联网协商(KINK)7-6 IPsec安全远程访问(IPSRA)7-7 IPsec密钥信息资源记录(IPSECKEY)第8章使用IPsec/IKE的其他协议8-1 移动IP(MIPv4和MIPv6)8-2 开放最短路径优先(OSPF)8-3 主机标识协议(HIP)8-4 流控制传输协议(SCTP)8-5 茁壮首部压缩(ROHC)8-6 边界网关协议(BGP)8-7 IPsec 基准(测试)8-8 网络地址转换器(NAT)8-9 会话发起协议(SIP)8-10 显示分组灵敏度标签第9章其他采纳非IPsec功能IKE的协议9-1 可扩展认证协议(EAP)9-2 光纤通道9-3 无线安全第10章致谢第11章安全考虑第12章参考文献12-1 信息性参考文献附录A 算法要求等级归纳第1章序言互联网协议安全(Internet Protocol Security, IPsec)是一组协议,它在IP层对互联网通信提供安全保证。

RFC2367

RFC2367
为其它网络安全提供服务。做为可以自由发布和使用的美国海军研究实验室设计实
现的IPv6和IPsec的一部分,在4.4-Lite BSD内部实现了这个API的第一版。这里编
辑成档有助于其他人采用这个API,这些规定增强了密钥管理应用程序的可移植性(
例如:手工设置程序,ISAKMP守护进程,GKMP守护进程,Photuris守护进程或者SKIP
甚至部分SKIP协议层密钥管理提案能够在应用层实现。图1说明了密钥管理守护进
程和PF_KEY之间的关系。密钥管理守护进程使用PF_KEY与密钥引擎通信,并且使用
PF_INET(在IPv6下用PF_INET6)通过网络与远端的密钥管理程序通信。
“密钥引擎”或者“安全关联数据库(SADB)”在内核是一个逻辑实体,可以
Category: Informational B. Phan
July 1998
PF_KEY Key Management API, Version 2
图1: 密钥关联程序和PF_KEY的关系
为了获得好的性能,一些安全协议(如:IP安全)通常会在操作系统内核中实
现。其它的安全协议(如:OSPFv2密码认证)在内核外可信的特权程序中实现。图
2说明了一个可信的特权路由守护进程使用PF_INET同远端路由守护进程传递路由信
版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须
保留本文档的翻译及版权信息。
Network Working Group D. McDonald
Request for Comments: 2367 C. Metz
| |
| | 应用程序
======[PF_KEY]====[PF_INET]==========================

超文本传输协议 -- HTTP11(RFC 2616中文版) 中.

超文本传输协议 -- HTTP11(RFC 2616中文版) 中.

超文本传输协议 -- HTTP/1.1(RFC 2616中文版中13 HTTP中的缓存HTTP 典型应用于能通过采用缓存技术而提高性能的分布式信息系统。

HTTP/1.1协议包括的许多使缓存尽可能的工作的元素。

因为这些元素与协议的其他方面有着千丝万缕的联系,而且他们相互作用、影响,因此有必要单独的来介绍基本的缓存设计。

如果缓存不能改善性能, 他将一无用处。

HTTP/1.1中缓存的目的是为了在很多情况下减少发送请求,同时在许多情况下可以不需要发送完整响应。

前者减少了网络回路(译注:一个请求会返回一个响应,请求响应这个过程就是一个回路的数量;我们利用一个“过期(expiration ”机制来为此目的(见 13.2节。

后者减少了网络应用的带宽;我们用“验证(validation ”机制来为此目的。

对行为, 可行性, 和关闭的操作的要求放松了语义透明性的目的。

HTTP/1.1协议允许服务器, 缓存,和客户端能显示地降低透明性当在必要的时候。

然而,因为不透明的操作能混淆非专业的用户, 同时可能和某个服务器应用程序不兼容 (例如订购商品 , 因此此协议透明性在下面情况下才能被放松要求:-- 只有在一个显示的协议层的请求时,透明性才能被客户端或源服务器放松-- 当出现一个对终端用户的显示的警告时,透明性才能被缓存或被客户端放松因此, HTTP/1.1协议提供这些重要的元素:1.提供完整语义透明的协议特征,当这些特征被通信的所有方需要时2. 允许源服务器或用户代理显示的请求和控制不透明操作的协议特征3. 允许缓存给这样的响应绑定警告信息的协议特征, 这些响应不能保留请求的语义透明的近似一个基本的原则是客户端必须能够发现语义透明性的潜在的放松。

注意:服务器,缓存,或者客户端的实现者可能会面对设计上的判断,而这些判断没有显示地在此规范里讨论。

如果一个判断可能会影响语义透明性,那么实现者应该能维持语义透明性,除非一个仔细的完整的分析能说明打破透明性的好处。

RFC2617-cn

RFC2617-cn

HTTP Authentication: Basic and Digest Access Authentication备忘(Status of this Memo)本文档跟踪记录Internet团体为完善协议而进行的讨论、建议。

详情请参见官方文件(STD1)。

本文可任意分发。

版权声明(Copyright Notice)Copyright (C) The Internet Society (1999). All Rights Reserved.摘要(Abstract)“HTTP/1.0”中包括基本访问鉴别方案(Basic Access Authentication scheme)。

该方案不是安全的用户授权方法(除非与其它安全方法联合使用,如SSL[5]),因为其用户名和口令在网络上是以明文方式传送的。

本文档还提供了HTTP鉴别框架的规范,有关原始的基本鉴别方案和基于哈希加密的方案的内容,请参见摘要访问鉴别(Digest Acccess Authentication)。

从RFC2069公布以来,其中涉及的一些可选元素因为出现问题而被移出;而还有一些新的元素因为兼容性的原因而被加入,这些新元素虽然是可选的,但还是强烈建议使用的,因而,RFC2069[6]最终可能会被本规范所替代。

与基本方式类似的是,摘要鉴别授权对通讯双方都知道的秘密(如口令)进行校验;而与基本方式不同的是,该校验方式中的口令不以明文方式传输,而这正是基本方式的最大弱点。

正象其它大多数授权协议那样,该协议最大的风险不在于其协议本身,而是它周边的应用程序。

目录(Table of Contents)1 授权鉴别(Access Authentication) (3)1.1对HTTP/1.1规范的依赖(Reliance on the HTTP/1.1 Specification) (3)1.2 访问鉴别框架(Access Authentication Framework) (3)2 基本鉴别方案(Basic Authentication Scheme) (6)3 摘要访问 (7)访问鉴别方案(Digest Access Authentication Scheme) (7)3.1 介绍(Introduction) (8)3.1.1 目的(Purpose) (8)3.1.2 操作概述(Overall Operation) (8)3.1.3 摘要值的表示(Representation of digest values) (8)3.1.4 局限性(Limitations) (9)3.2 摘要报头的规范(Specification of Digest Headers) (9)3.2.1 WWW-鉴别回应报头(The WWW-Authenticate Response Header) (9)3.2.2 授权求报头(The Authorization Request Header) (14)3.2.2.1 请求-摘要(Request-Digest) (17)3.2.2.2 A1 (18)3.2.2.3 A2 (19)3.2.2.5 多样性考虑(Various considerations) (21)3.2.3 鉴别信息报头(The Authentication-Info Header) (22)3.3摘要操作(Digest Operation) (25)3.4 安全协议讨论(Security Protocol Negotiation) (26)3.5 例子(Example) (26)3.6 代理鉴别和代理授权(Proxy-Authentication and Proxy-Authorization) (28)4 安全考虑(Security Considerations) (28)4.1 客户使用基本鉴别(Authentication of Clients using Basic Authentication)28 4.2客户使用摘要鉴别(Authentication of Clients using Digest Authentication)29 4.3 受限的nonce值使用(Limited Use Nonce Values) (30)4.4 基本鉴别与分摘要鉴别的比较(Comparison of Digest with Basic Authentication) (32)4.5 回放式攻击(Replay Attacks) (32)4.6 由多方鉴别方案产生的弱点(Weakness Created by Multiple Authentication Schemes) (34)4.8 中间人(Man in the Middle) (36)4.9 选择纯文本攻击(Chosen plaintext attacks) (36)4.10 预先计算的字典攻击(Precomputed dictionary attacks) (37)4.11 批方式暴力攻击(Batch brute force attacks) (37)4.12 假冒服务器欺骗(Spoofing by Counterfeit Servers) (38)4.13 存储口令(Storing passwords) (39)4.14 摘要(Summary) (39)5 例子实现(Sample implementation) (41)7 参考书目(References) (50)8 作者地址(Authors' Addresses) (51)9. 完整版权声明(Full Copyright Statement) (54)感谢(Acknowledgement) (55)1 授权鉴别(Access Authentication)1.1对HTTP/1.1规范的依赖(Reliance on the HTTP/1.1 Specification)本规范和HTTP/1.1规范[2]一起使用,它使用HTTP/1.1文档2.1节的补充反馈方式(Augmented BNF),并依赖于该文档对非终端(non-terminals)的定义及对其它方面的描述。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

Network Working Group J. FranksRequest for Comments: 2617 Northwestern UniversityObsoletes: 2069 P. Hallam-BakerCategory: Standards Track Verisign, Inc.J. HostetlerAbiSource, Inc.S. LawrenceAgranat Systems, Inc.P. LeachMicrosoft CorporationA. LuotonenNetscape Communications CorporationL. StewartOpen Market, Inc.June 1999HTTP Authentication: Basic and Digest Access Authentication备忘(Status of this Memo)本文档跟踪记录Internet团体为完善协议而进行的讨论、建议。

详情请参见官方文件(STD1)。

本文可任意分发。

版权声明(Copyright Notice)Copyright (C) The Internet Society (1999). All Rights Reserved. 摘要(Abstract)“HTTP/1.0”中包括基本访问鉴别方案(Basic Access Authentication scheme)。

该方案不是安全的用户授权方法(除非与其它安全方法联合使用,如SSL[5]),因为其用户名和口令在网络上是以明文方式传送的。

本文档还提供了HTTP鉴别框架的规范,有关原始的基本鉴别方案和基于哈希加密的方案的内容,请参见分类访问鉴别(Digest Acccess Authentication)。

从RFC2069公布以来,其中涉及的一些可选元素因为出现问题而被移出;而还有一些新的元素因为兼容性的原因而被加入,这些新元素虽然是可选的,但还是强烈建议使用的,因而,RFC2069[6]最终可能会被本规范所替代。

Franks, et al. Standards Track [Page 1]与基本方式类似的是,分类鉴别授权对通讯双方都知道的秘密(如口令)进行校验;而与基本方式不同的是,该校验方式中的口令不以明文方式传输,而这正是基本方式的最大弱点。

正象其它大多数授权协议那样,该协议最大的风险不在于其协议本身,而是它周边的应用程序。

目录(Table of Contents)1 访问鉴别(Access Authentication)..................... ..................... ......... .. (3)1.1 对HTTP/1.1规范的依赖(Reliance on the HTTP/1.1 Specification) (3)1.2 访问鉴别框架(Access Authentication Framework)................. (3)2 基本鉴别方案(Basic Authentication Scheme)........................ ............... (5)3 分类访问鉴别方案(Digest Access Authentication Scheme)............. (6)3.1 介绍(Introduction)................................. ................... .. ..................... (6)3.1.1 目的(Purpose)...................................... ..................... .. (6)3.1.2 操作概述(OverallOperation)........................ ..................... ... . (6)3.1.3 分类值表示(Representation of digestvalues)............ . (7)3.1.4 局限性(Limitations)................................... ..................... .. (7)3.2 分类标题规范(Specification of Digest Headers)................. .. (7)3.2.1 WWW-鉴别回应标题(The WWW-Authenticate Response Header)..83.2.2 授权请求标题(The Authorization RequestHeader)....... . (11)3.2.3 鉴别信息标题(The Authentication-InfoHeader)....... .. (15)3.3 分类操作(Digest Operation)........................... ..................... ........ . (17)3.4 安全协议商议(Security ProtocolNegotiation).. (18)3.5 例子(Example)...................................... ................... .. ..................... . (18)3.6 代理鉴别和代理授权(Proxy-Authentication andProxy-Authorization) (19)4 安全考虑(Security Considerations)............................ ..................... .. . (19)4.1 使用基本鉴别方式的客户端鉴别(Authentication of Clients using BasicAuthentication).............................. ..................... ..................... (19)4.2 使用分类鉴别方式的客户端鉴别(Authentication of Clients using DigestAuthentication).............................. ..................... ..................... (20)4.3 使用有限制的nonce值(Limited Use Nonce Values)..................... .. (21)4.4用基本鉴别方式来进行分类比较(Comparisonof Digest with BasicAuthentication).. ..................... ..................... ...... .. (22)4.5 攻击回放(Replay Attacks).............................. ..................... ....... .. (22)4.5由多方鉴别方案产生的弱点(WeaknessCreated by Multiple Authentication Schemes).................................. (23)4.7 在线字典攻击(Online dictionary attacks)...................... ..................... . (23)4.8 中间人(Man in the Middle).............................. ..................... ........ . (24)4.9 选择纯文本攻击(Chosen plaintext attacks)............... ..................... (24)4.10 用预先计算的字典攻击(Precomputed dictionary attacks)............... . (25)4.11 批方式暴力攻击(Batch brute force attacks)...................... ........ .. (25)4.12 假冒服务器欺骗(Spoofing by Counterfeit Servers)............... . (25)4.13 存储口令(Storing passwords)........................ ..................... ........... . (26)4.14 摘要(Summary)................................ ..................... ... .................. . (26)5 例子实现(Sample implementation)....................... ..................... ....... . (27)6 感谢(Acknowledgments).............................. ................... .. ..................... .. . (31)Franks, et al. Standards Track [Page 2]7 参考书目(References)....................................... ............... ...... .............. . (31)8 作者地址(Authors' Addresses)............................ ..................... ....... (32)9 完整版权状况(Full Copyright Statement)........................ ..................... ........... . (34)1 授权鉴别(Access Authentication)1.1对HTTP/1.1规范的依赖(Reliance on the HTTP/1.1 Specification)本规范和HTTP/1.1规范[2]一起使用,它使用HTTP/1.1文档2.1节的补充反馈方式(Augmented BNF),并依赖于该文档对非终端(non-terminals)的定义及对其它方面的描述。

相关文档
最新文档