RFC2617 鉴权 中文
头压缩协议(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规范(协议细则)
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 航空协议
组织:中国互动出版网(/)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 中文版
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)
本文翻译者: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
现的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中文版) 中.
超文本传输协议 -- 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
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)的定义及对其它方面的描述。
iso27017概念介绍 -回复
iso27017概念介绍-回复ISO 27017是信息技术- 安全技术- 信息安全管理系统- 云计算信息安全的国际标准。
它为云计算提供了一系列的安全控制,帮助组织在云计算环境中保护其信息资产。
本文将详细介绍ISO 27017的概念,包括标准的背景、内容和实施方法。
1. 标准背景云计算已成为现代企业的重要组成部分,它提供了灵活、可扩展的IT资源。
然而,云计算环境也带来了一系列的安全风险,包括数据泄露、服务中断和违法行为。
为了解决这些问题,国际标准化组织(ISO)于2015年发布了ISO 27017。
2. 标准内容ISO 27017基于ISO 27002,它是信息安全管理系统的国际标准。
ISO 27017专注于云计算环境中的安全控制,提供了一系列的最佳实践和控制措施,以保护云计算环境中的信息资产。
这些控制措施包括:- 云计算中的虚拟化安全:包括虚拟机监控、虚拟机迁移和虚拟化管理- 数据保护与备份:包括数据分类、加密、备份和恢复- 供应链管理:包括云服务提供商的选择、服务级别协议管理和安全审计- 身份与访问管理:包括身份验证、权限管理、多因素身份验证和单点登录- 事件管理和响应:包括威胁监测、事件响应和漏洞管理- 物理和环境安全:包括数据中心的安全控制、访问控制和监控此外,ISO 27017还包括管理人员相关的安全措施,例如安全政策、安全培训和风险评估。
3. 实施方法实施ISO 27017需要经过一系列步骤。
第一步是确定组织的云计算安全要求。
这包括识别敏感数据、评估云服务提供商的安全能力、定义组织的安全策略和目标。
第二步是创建信息安全管理团队。
这个团队将负责实施ISO 27017的各项要求,并监测和维护安全控制的有效性。
第三步是进行风险评估和治理。
这包括评估云计算环境中的风险,确定相应的安全控制,并建立适当的安全治理机制。
第四步是开展安全意识培训。
组织需要确保员工了解云计算的安全要求,并能够正确使用云服务。
RFC1945中文
组织:中国互动出版网(/)RFC文档中文翻译计划(/compters/emook/aboutemook.htm)E-mail:********************译者:黄晓东(黄晓东****************)译文发布时间:2001-7-14版权:本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。
Network Working Group T. Berners-Lee Request for Comments: 1945 MIT/LCS Category: Informational R. Fielding UC IrvineH. FrystykMIT/LCSMay 1996超文本传输协议 -- HTTP/1.0(Hyptertext Transfer Protocol – HTTP/1.0)关于下段备忘(Status of This Memo)本段文字为Internet团体提供信息,并没有以任何方式指定Internet标准。
本段文字没有分发限制。
IESG提示(IESG Note):IESG已在关注此协议,并期待该文档能尽快被标准跟踪文档所替代。
摘要(Abstract)HTTP(Hypertext Transfer Protocol)是应用级协议,它适应了分布式超媒体协作系统对灵活性及速度的要求。
它是一个一般的、无状态的、基于对象的协议,通过对其请求方法(request methods)进行扩展,可以被用于多种用途,比如命名服务器(name server)及分布式对象管理系统。
HTTP的一个特性是其数据表现类型允许系统的构建不再依赖于要传输的数据。
HTTP自从1990年就在WWW上被广泛使用。
该规范反映了“HTTP/1.0”的普通用法。
目录(Table of Contents)1. 介绍(Introduction) 61.1 目的(Purpose) 61.2 术语(Terminology) 61.3 概述(Overall Operation)81.4 HTTP and MIME 92. 标志转换及通用语法(Notational Conventions and Generic Grammar)9 2.1 补充反馈方式(Augmented BNF)92.2 基本规则(Basic Rules)103. 协议参数(Protocol Parameters) 123.1 HTTP版本(HTTP Version)123.2 统一资源标识(Uniform Resource Identifiers)133.2.1 一般语法(General Syntax)133.2.2 http URL 143.3 Date/Time 格式(Date/Time Formats)153.4 字符集(Character Sets)163.5 内容译码(Content Codings)163.6 介质类型(Media Types)173.6.1标准及文本缺省(Canonicalization and Text Defaults)183.6.2 多部分类型(Multipart Types) 183.7 产品标识(Product Tokens) 194. HTTP 消息(HTTP Message)194.1 消息类型(Message Types)194.2 消息标题(Message Headers)204.3 普通标题域(General Header Fields)205. 请求(Request)215.1 请求队列(Request-Line)215.1.1 方法(Method)225.1.2 请求URI(Request-URI)225.2 请求标题域(Request Header Fields)236. 回应(Response)236.1 状态行(Status-Line)246.1.1 状态代码和原因分析(Status Code and Reason Phrase)246.2 回应标题域(Response Header Fields)257. 实体(Entity)267.1 实体标题域(Entity Header Fields) 267.2 实体主体(Entity Body)267.2.1 类型(Type)277.2.2 长度(Length)278. 方法定义(Method Definitions)278.1 GET 288.2 HEAD 288.3 POST 289. 状态代码定义(Status Code Definitions) 299.1 消息1xx(Informational 1xx)299.2 成功2xx(Successful 2xx)299.3 重定向(Redirection 3xx)309.4 客户端错误(Client Error )4xx 319.5 服务器错误(Server Error )5xx 3210. 标题域定义(Header Field Definitions) 3310.1 允许(Allow) 3310.2 授权(Authorization) 3410.3 内容编码(Content-Encoding)3410.4 内容长度(Content-Length)3410.5 内容类型(Content-Type)3510.6 日期(Date)3510.7 过期(Expires)3610.8 来自(From)3710.9 从何时更改(If-Modified-Since)3710.10 最近更改(Last-Modified)3810.11 位置(Location) 3810.12 注解(Pragma)3910.13 提交方(Referer) 3910.14 服务器(Server) 4010.15 用户代理(User-Agent)4010.16 WWW-授权(WWW-Authenticate) 4011. 访问鉴别(Access Authentication)4111.1 基本授权方案(Basic Authentication Scheme)4212. 安全考虑(Security Considerations)4312.1 客户授权(Authentication of Clients) 4312.2 安全方法(Safe Methods)4312.3 服务器日志信息的弊端(Abuse of Server Log Information)4312.4 敏感信息传输(Transfer of Sensitive Information) 4412.5 基于文件及路径名的攻击(Attacks Based On File and Path Names)4413. 感谢(Acknowledgments)4514. 参考书目(References)4515. 作者地址(Authors' Addresses) 47附录(Appendices)48A. Internet介质类型消息/http(Internet Media Type message/http)48B. 容错应用(Tolerant Applications)48C. 与MIME的关系(Relationship to MIME)49C.1 转换为规范形式(Conversion to Canonical Form) 49C.2 日期格式转换(Conversion of Date Formats) 49C.3 内容编码介绍(Introduction of Content-Encoding)50C.4 无内容传输编码(No Content-Transfer-Encoding) 50C.5 多个主体的HTTP标题域(HTTP Header Fields in Multipart Body-Parts)50D. 附加特性(Additional Features) 50D.1 附加请求方法(Additional Request Methods) 51D.2 附加标题域定义(Additional Header Field Definitions)511. 介绍(Introduction)1.1 目的(Purpose)HTTP(Hypertext Transfer Protocol)是应用级协议,它适应了分布式超媒体协作系统对灵活性及速度的要求。
rfc2217协议内容
竭诚为您提供优质文档/双击可除rfc2217协议内容篇一:串口服务器410软件设计手册usR-tcp232-410软件设计手册文件版本:V1.0.1目录usR-tcp232-410软件设计手册................................................. ................................................... . (1)1.产品概述................................................. ................................................... ................................................... .. (3)1.1.产品简介.................................................................................................... . (3)1.2.功能特点................................................. ................................................... . (3)1.3.与旧的e45系列的兼容性声明................................................. ................................................... . (4)2.产品功能................................................. ................................................... ................................................... .. (5)2.1.tcpclient模式特性................................................. ................................................... (5)2.2.tcpserver模式特性................................................. ................................................... (7)2.3.udpclient模式特性................................................. ................................................... .. (8)2.4.udpserver模式特性................................................. ................................................... (10)2.5.httpdclient.................................... ................................................... . (11)2.6.Vcom应用模式................................................. ................................................... . (13)2.7.增值功能................................................. ................................................... .. (14)2.7.1.网页转串口功能................................................. ................................................... (14)2.7.2.自定义网页功能................................................. ................................................... (17)2.7.3.modbusRtu转modbustcp.......................................... ................................................... .182.7.4.串口打包机制................................................. ................................................... . (18)2.7.5.流量计算................................................. ................................................... (19)2.7.6.类RFc2217功能................................................. ................................................... (19)3.设置协议................................................. ................................................... ................................................... (21)3.1.网络设置协议................................................. ................................................... (21)3.1.1.设置参数的流程................................................. ................................................... (21)3.1.2.设置指令内容................................................. ................................................... . (21)3.1.3.返回指令内容................................................. ................................................... . (24)3.2.串口设置协议................................................. ................................................... (26)4.免责声明................................................. ................................................... ................................................... (26)5.更新历史................................................. ................................................... ................................................... (26)1.产品概述1.1.产品简介usR-tcp232-410是有人物联网技术有限公司推出的m4系列的串口服务器,是用来将tcp/udp数据包与Rs232/Rs485接口实现数据透明传输的设备。
超文本传输协议--HTTP1.1(RFC2616中文版)上
超文本传输协议--HTTP1.1(RFC2616中文版)上超文本传输协议 -- HTTP/1.1(RFC 2616中文版) 上说明本文档规定了互联网社区的标准组协议,并需要讨论和建议以便更加完善。
请参考“互联网官方协议标准”(STD 1)来了解本协议的标准化状态。
本协议不限流传发布。
版权声明Copyright (C)The Internet Society (1999). All Rights Reserved.摘要超文本传输协议(HTTP)是一种为分布式,合作式,超媒体信息系统。
它是一种通用的,无状态(stateless)的协议,除了应用于超文本传输外,它也可以应用于诸如名称服务器和分布对象管理系统之类的系统,这可以通过扩展它的请求方法,错误代码和报头[47]来实现。
HTTP的一个特点是数据表现形式是可输入的和可协商性的,这就允许系统能被建立而独立于数据传输。
HTTP在1990年WWW全球信息刚刚起步的时候就得到了应用。
本说明书详细阐述了HTTP/1.1 协议,是RFC 2068的修订版[33]。
目录(略)1 引论1.1 目的超文本传输协议(HTTP)是一种为分布式,合作式,多媒体信息系统服务,面向应用层的协议。
在1990年WWW全球信息刚刚起步的时候HTTP就得到了应用。
HTTP的第一个版本叫做HTTP/0.9,是一种为互联网原始数据传输服务的简单协议。
由RFC 1945[6]定义的HTTP/1.0进一步完善了这个协议。
它允许消息以类似MIME的格式传送,包括有关数据传输的维护信息和关于请求/响应的句法修正。
但是,HTTP/1.0没有充分考虑到分层代理,缓存的作用以及对稳定连接和虚拟主机的需求。
并且随着不完善的应用程序的激增,HTTP/1.0迫切需要一个新的版本,以便使两个通信应用程序能够确定彼此的真实性能。
这里规定的协议叫做擧TTP/1.1".这个协议与HTTP/1.0相比,要求更为严格,以确保各项功能得到可靠实现。
RFC2617 鉴权 中文
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]最终可能会被本规范所替代。
OpenID认证协议2.0中文版
OpenID Authentication 2.0 – Implementor’s Draft 12OpenID认证协议2.0 —草案12Table of Contents1.符号惯例 (4)2.术语 (5)3.协议概要 (6)4.数据格式 (6)4.1协议消息 (6)4.1.1键-值表单编码 (6)4.1.2 HTTP编码 (7)4.1.3例子 (7)4.2整数的表示 (8)5.通信类型 (8)5.1直接通信 (8)5.1.1直接通信请求 (8)5.1.2直接通信响应 (8)5.1.2.1成功响应 (9)5.1.2.1失败响应 (9)5.2间接通信 (9)5.2.1 HTTP 重定向 (9)5.2.2 HTML表单重定向 (9)5.2.3间接通信失败响应 (10)6.产生签名 (10)6.1步骤 (10)6.2签名算法 (10)7.初始化及自动发现 (11)7.1初始化 (11)7.2规格化 (11)7.3自动发现 (11)7.3.1自动发现的信息 (11)7.3.2基于XRDS的自动发现 (12)7.3.2.1 OpenID服务条目 (12)7.3.3基于HTML的自动发现 (13)8.创建Association (13)8.1Association会话请求 (14)8.1.1通用请求参数 (14)8.1.2 Diffie-Hellman请求参数 (14)8.2 Association会话响应 (14)8.2.1通用响应参数 (15)8.2.2非加密响应参数 (15)8.2.3 Diffie-Hellman响应参数 (15)8.2.4不成功响应参数 (15)8.3 Association类型 (16)8.3.1HMAC-SHA1 (16)8.3.2HMAC-SHA256 (16)8.4 Association会话类型 (16)8.4.1 No-Encryption Association会话 (16)8.4.2 Diffie-Hellman Association会话 (16)9.请求认证 (17)9.1请求参数 (17)9.2 Realms (18)9.2.1域 (18)9.2.2使用域对返回URL确认 (19)9.3即时请求(Immediate Requests) (19)10.响应认证请求 (20)10.1肯定断言 (20)10.2否定断言 (22)10.2.1响应即时请求 (22)10.2.2响应非即时请求 (22)11.验证断言 (23)11.1验证返回URL (23)11.2验证发现的信息 (23)11.3检查随机序列 (24)11.4验证签名 (25)11.4.1利用Association验证 (25)11.4.2同OP直接验证 (25)11.5标识用户 (26)11.5.1标识回收 (26)11.5.2 HTTP和HTTPS URL标识 (26)12.扩展 (27)13. RP发现 (28)14.与OpenID 认证协议1.1版本兼容性 (29)14.1自1.1版变更 (29)14.1.1初始化与发现过程的更新 (29)14.1.2安全改进 (29)14.1.3扩展 (30)14.2实现与1.1版兼容 (30)14.2.1依赖方(Relying Party) (30)14.2.2 OpenID提供方(OpenID Providers) (31)15.安全考虑 (32)15.1预防攻击 (32)15.1.1窃听攻击(Eavesdropping Attacks) (32)15.1.2中间人攻击(Man-in-the-Middle Attacks) (32)15.2用户代理 (33)15.3用户界面考虑 (33)15.4 HTTP和HTTPS URL标识 (34)15.5拒绝服务攻击 (34)15.6协议变量 (34)附录A. 示例 (35)附录A.1 规范化 (35)附录A.2 OP-Local标识 (36)附录A.3 XRDS (36)附录A.4 HTML标识记号 (36)附录A.5 XRI CanonicalID (37)附录B. Diffie-Hellman密匙交换默认值 (37)Appendix C. Acknowledgements (37)16. Normative References (38)对照词汇表文档历史1.符号惯例本文档中的下面这些关键字在[RFC2119]标准中都有描述。
ipsec中文rfc
组织:中国互动出版网(/)RFC文档中文翻译计划(/compters/emook/aboutemook.htm)E-mail:********************译者:sword(************************)译文发布时间:2001-7-25版权:本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。
Network Working Group D. HarkinsRequest for Comments: 2409 D. CarrelCategory: Standards Track cisco SystemsNovember 1998Internet密钥交换(IKE)(The Internet Key Exchange)本备忘录的现状本文档指定了一个Internet 团体的Internet标准协议,并请求讨论和建议以作改进。
请参考当前版本的“Internet官方协议标准”(STD 1),查看本协议的标准化进程和现状。
本文档的分发不受限制。
版权通告Copyright (C) The Internet Society (1998)。
保留所有的权利。
目录1.摘要 22.讨论 23.术语和定义 33.1必要的术语 33.2符号 33.3完全后继保密 43.4安全联盟 44.简介 55.交换 65.1 使用签名来验证的IKE第一阶段 85.2 使用公共密钥加密的第一阶段验证 85.3 使用修改过的公钥加密模式来进行第一阶段的验证 10 5.4 使用共享密钥的第一阶段协商 115.5 第二阶段——快速模式 125.6 新组模式 145.7 ISAKMP信息交换 156 Oakley组 156.1 第一个Oakley缺省组 156.2 第二个Oakley组 166.3 第三个Oakley组 166.4 第四个Oakley组 167. 完整IKE交换的负载爆炸 177.1 使用主模式的第一阶段 177.2 使用快速模式的第二阶段 188. 完全后继保密举例 2010.安全考虑 2111.IANA考虑 2211.1 属性类 2211.2 加密算法类 2211.3 hash算法 2211.4 组描述和组类型 2311.5 存活期类型 2312. 鸣谢 2313.参考 23附录A 25属性分配号码 25属性种类 26种类值 26附录B 28作者地址 30作者的注释 30完全版权声明 311.摘要ISAKMP ([MSST98])中对验证和密钥交换提出了结构框架,但没有具体定义。
中国移动CM-IMS企业用户接入设备开通网关设备规范
中国移动通信企业标准QB-╳╳-╳╳╳-╳╳╳╳中国移动C M-I M S接入开通网关规范T e c h n i c a l S p e c i f i c a t i o n f o r C M-I M S A c c e s sD e v i c e S e r v i c e P r o v i s i o n i n g G a t e w a y版本号:0.9.3╳╳╳╳-╳╳-╳╳发布╳╳╳╳-╳╳-╳╳实施中国移动通信集团公司发布目录前言 (IV)1. 范围 (1)2. 规范性引用文件 (1)3. 术语、定义和缩略语 (1)4. 总体概述 (2)4.1. 组网 (2)4.2. Centrix端到端开通流程 (3)4.2.1. 客户端施工在业务支撑系统的流程 (4)4.2.2. 客户端施工在网络支撑系统的流程 (5)5. 功能要求 (6)5.1. 维护与接入设备间的链接 (6)5.1.1. HTTPS链路要求 (6)5.1.2. 接入设备初始上电注册要求 (9)5.1.3. 接入设备非初始上电注册要求 (12)5.2. 接入设备开通功能 (14)5.3. 接口协议转换功能 (14)5.4. 操作记录维护功能 (14)5.5. 其他能力要求 (14)5.5.1. IP 地址的获取 (14)5.5.2. 防火墙的穿越 (14)5.5.3. 安全要求 (15)5.6. SOAP(与业务支撑系统北向接口协议) (15)5.7. TR069协议(南向接口) (16)6. 接口要求 (16)6.1. 与业务支撑系统接口(北向接口) (16)6.2. 与接入设备接口(南向接口) (16)6.3. 维护管理接口 (16)6.4. 双机备份接口 (16)7. 业务流程 (16)7.1. HTTPS建链流程 (16)7.1.1. 接入设备发起 (16)7.1.2. 接入开通网关发起 (17)7.2. 双密码下发流程 (19)7.3. 接入设备初始上电注册流程 (19)7.3.1. 无NAT场景下初始注册流程 (19)7.3.2. 有NAT场景下初始注册流程 (21)7.4. 超时重注册流程 (22)7.5. 重启、变更IP地址重注册 (23)7.5.1. 无NAT场景下重启、变更IP地址重注册流程 (23)7.5.2. 有NAT场景下重启、变更IP地址重注册流程 (24)7.6. 开户 (25)7.7. 修改 (26)7.8. 查询 (26)7.9. 销户 (27)7.10. 用户名和密码下发流程............................. 错误!未定义书签。
RFC2616中文文档
RFC2616中文文档Network Working Group(网络工作组) R. FieldingRequest for Comments: 2616 UC IrvineObsoletes(过时弃用): 2068 J. GettysCategory: Standards Track (类别:标准组)Compaq/W3CJ. MogulCompaqH. FrystykW3C/MITL. MasinterXeroxP. LeachMicrosoftT. Berners-LeeW3C/MITJune 1999超文本传输协议-HTTP/1.1本备忘录状况本文档说明了用于互联网社区的标准化跟踪协议,但还需要讨论和建议以便更加完善。
请参考"互联网官方协议标准"(STD1)来了解本协议的标准化状态。
分发散布本文是不受限制的。
版权声明Copyright (C) The Internet Society (1999). All Rights Reserved.摘要超文本传输协议(HTTP)是一种应用于分布式、协作式、超媒体信息系统的应用层协议。
它是一种通用的,状态无关的协议,可以用于除了超文本以外,还可以通过扩展它的请求方法,错误代码和报头[47]来完成更多任务,比如名称服务和分布对象管理系统。
HTTP的一个特点是数据表示方式的典型性(typing)和可协商性,允许建立独立于被传输数据的系统。
HTTP在1990年WWW全球信息刚刚起步的时候就得到了应用。
本规范定义了HTTP/ 1.1协议,这是RFC 2068的升级版[33]。
[页码1]------------------------------------------------------------------------目录1 Introduction (介绍) (7)1.1 Purpose(目的) (7)1.2 Requirements (要求) (8)1.3 Terminology (术语) (8)1.4 Overall Operation (概述) (12)2 Notational Conventions and Generic Grammar(标志转换及通用语法)(14)2.1 Augmented BNF (扩充的范式) (14)2.2 Basic Rules (基本规则) (15)3 Protocol Parameters (协议参数) (17)3.1 HTTP Version (版本) (17)3.2 Uniform Resource Identifiers (统一资源标识) (18)3.2.1 General Syntax (通用语法) (19)3.2.2 http URL (19)3.2.3 URI Comparison (URI对比) (20)3.3 Date/Time Formats (时间日期格式) (20)3.3.1 Full Date (完整日期) (20)3.3.2 Delta Seconds (21)3.4 Character Sets (字符集) (21)3.4.1 Missing Charset (不见了的字符集) (22)3.5 Content Codings (内容编码) (23)3.6 Transfer Codings (传输编码) (24)3.6.1 Chunked Transfer Coding (大块数据传输编码) (25)3.7 Media Types (媒介类型) (26)3.7.1 Canonicalization and Text Defaults (27)3.7.2 Multipart Types (复合类型) (27)3.8 Product T okens (产品记号) (28)3.9 Quality Values (质量值) (29)3.10 Language Tags (语言标签) (29)3.11 Entity Tags (实体标签) (30)3.12 Range Units (范围单位) (30)4 HTTP Message (HTTP 消息) (31)4.1 Message Types (消息类型) (31)4.2 Message Headers (消息头) (31)4.3 Message Body (消息主体) (32)4.4 Message Length (消息长度) (33)4.5 General Header Fields (通用头字段) (34)5 Request (请求) (35)5.1 Request-Line (请求行) (35)5.1.1 Method (方法) (36)5.1.2 Request-URI (请求-URI) (36)5.2 The Resource Identified by a Request (38)5.3 Request Header Fields (请求头字段) (38)6 Response (应答) (39)6.1 Status-Line (状态行) (39)6.1.1 Status Code and Reason Phrase (状态码和原因短语)(39)6.2 Response Header Fields (应答头字段) (41)[页码2]------------------------------------------------------------------------7 Entity (实体) (42)7.1 Entity Header Fields (实体头字段) (42)7.2 Entity Body (实体主体) (43)7.2.1 Type (类型) (43)7.2.2 Entity Length (实体长度) (43)8 Connections (连接) (44)8.1 Persistent Connections (持久连接) (44)8.1.1 Purpose (目的) (44)8.1.2 Overall Operation(概述) (45)8.1.3 Proxy Servers (代理服务器) (46)8.1.4 Practical Considerations (实践中的考虑) (46)8.2 Message Transmission Requirements (消息传送请求)(47)8.2.1 Persistent Connections and Flow Control(持久连接和流程控制) (47)8.2.2 Monitoring Connections for Error Status Messages(出错状态消息的监测连接) (48)8.2.3 Use of the 100 (Continue) Status(状态号100的使用) (48)8.2.4 Client Behavior if Server Prematurely Closes Connection(如果服务器过早关闭连接,客户端的行为) (50)9 Method Definitions (方法的定义) (51)9.1 Safe and Idempotent Methods (安全和幂等方法) (51)9.1.1 Safe Methods (安全方法) (51)9.1.2 Idempotent Methods (幂等方法) (51)9.2 OPTIONS (选项) (52)9.3 GET (命令:GET) (53)9.4 HEAD (命令:HEAD) (54)9.5 POST (命令:POST) (54)9.6 PUT (命令:PUT) (55)9.7 DELETE (命令:DELETE) (56)9.8 TRACE (命令:TRACE) (56)9.9 CONNECT (命令:CONNECT) (57)10 Status Code Definitions (状态码定义) (57)10.1 Informational 1xx (报告:1XX) (57)10.1.1 100 Continue (100 继续) (58)10.1.2 101 Switching Protocols(交换协议) (58)10.2 Successful 2xx (成功:2XX) (58)10.2.1 200 OK (200 正常) (58)10.2.2 201 Created (201 已建立) (59)10.2.3 202 Accepted (202 已接受) (59)10.2.4 203 Non-Authoritative Information (无认证信息) (59)10.2.5 204 No Content (无内容) (60)10.2.6 205 Reset Content (重置内容) (60)10.2.7 206 Partial Content (部分内容) (60)10.3 Redirection 3xx (3XX 重定向) (61)10.3.1 300 Multiple Choices (复合选择) (61)10.3.2 301 Moved Permanently (永久转移) (62)10.3.3 302 Found (找到) (62)10.3.4 303 See Other (访问其他) (63)10.3.5 304 Not Modified (304 没有更改) (63)10.3.6 305 Use Proxy (305 使用代理) (64)10.3.7 306 (Unused) (306 未使用) (64)[页码3]------------------------------------------------------------------------10.3.8 307 Temporary Redirect (暂时重定向) (65)10.4 Client Error 4xx (客户端错误) (65)10.4.1 400 Bad Request (错误请求) (65)10.4.2 401 Unauthorized (未认证) (66)10.4.3 402 Payment Required (支付请求) (66)10.4.4 403 Forbidden (禁止) (66)10.4.5 404 Not Found (没有找到) (66)10.4.6 405 Method Not Allowed (方法不容许) (66)10.4.7 406 Not Acceptable (不可接受) (67)10.4.8 407 Proxy Authentication Required (要求代理认证)(67)10.4.9 408 Request Timeout (请求超时) (67)10.4.10 409 Conflict (冲突) (67)10.4.11 410 Gone (离开) (68)10.4.12 411 Length Required (长度请求) (68)10.4.13 412 Precondition Failed (预处理失败) (68)10.4.14 413 Request Entity Too Large (请求的实体太大了)(69)10.4.15 414 Request-URI Too Long (请求URI太长了) (69)10.4.16 415 Unsupported Media Type (不支持的媒提类型)(69)10.4.17 416 Requested Range Not Satisfiable (请求范围未满足) (69)10.4.18 417 Expectation Failed (期望失败) (70)10.5 Server Error 5xx (服务器错误 5XX) (70)10.5.1 500 Internal Server Error (内部错误) (70)10.5.2 501 Not Implemented (未实现) (70)10.5.3 502 Bad Gateway (错误网关) (70)10.5.4 503 Service Unavailable (服务不可用) (70)10.5.5 504 Gateway Timeout (网关超时) (71)10.5.6 505 HTTP Version Not Supported (版本不支持) (71)11 Access Authentication (访问认证) (71)12 Content Negotiation (内容协商) (71)12.1 Server-driven Negotiation (服务器驱动协商) (72)12.2 Agent-driven Negotiation (客户端驱动协商) (73)12.3 Transparent Negotiation (透明协商) (74)13 Caching in HTTP (缓存) (74)13.1.1 Cache Correctness (缓存正确性) (75)13.1.2 Warnings (警告) (76)13.1.3 Cache-control Mechanisms (缓存控制机制) (77)13.1.4 Explicit User Agent Warnings (直接用户代理警告) (78)13.1.5 Exceptions to the Rules and Warnings (规则和警告的异常).78 13.1.6 Client-controlled Behavior(客户控制的行为)(79)13.2 Expiration Model (过期模式) (79)13.2.1 Server-Specified Expiration (服务器指定过期) (79)13.2.2 Heuristic Expiration (启发式过期) (80)13.2.3 Age Calculations (年龄计算) (80)13.2.4 Expiration Calculations (过期计算) (83)13.2.5 Disambiguating Expiration Values (消除歧义的过期值)(84)13.2.6 Disambiguating Multiple Responses (消除歧义的复合应答)..84 13.3 Validation Model (确认模式) (85)13.3.1 Last-Modified Dates (最后更改日期) (86)[页码4]------------------------------------------------------------------------13.3.2 Entity Tag Cache Validators (实体标签缓存确认) (86)13.3.3 Weak and Strong Validators (强弱确认) (86)13.3.4 Rules for When to Use Entity Tags and Last-ModifiedDates当使用实体标签和最后更改日期字段时候的规则 (89)13.3.5 Non-validating Conditionals (不可确认的条件) (90)13.4 Response Cacheability (应答缓存功能) (91)13.5 Constructing Responses From Caches (从缓存构造应答)(92)13.5.1 End-to-end and Hop-by-hop Headers (端对端和逐跳的头) (92)13.5.2 Non-modifiable Headers (不可以更改的报头) (92)13.5.3 Combining Headers (组合报头) (94)13.5.4 Combining Byte Ranges (组合字节范围) (95)13.6 Caching Negotiated Responses (缓存协商过的应答)(95)13.7 Shared and Non-Shared Caches (共享和非共享缓存)(96)13.8 Errors or Incomplete Response Cache Behavior(错误或不完整应答缓存行为) (97)13.9 Side Effects of GET and HEAD (GET和HEAD的单方影响) (97)13.10 Invalidation After Updates or Deletions(更新和删除后的失效) (97)13.11 Write-Through Mandatory (强制写通过) (98)13.12 Cache Replacement (缓存替换) (99)13.13 History Lists (历史列表) (99)14 Header Field Definitions (头字段定义) (100)14.1 Accept (接受) (100)14.2 Accept-Charset (接受的字符集) (102)14.3 Accept-Encoding (接受的编码方式) (102)14.4 Accept-Language (接受的语言) (104)14.5 Accept-Ranges (接受的范围) (105)14.6 Age (年龄,生存期) (106)14.7 Allow (容许) (106)14.8 Authorization (认证) (107)14.9 Cache-Control (缓存控制) (108)14.9.1 What is Cacheable (什么可以缓存) (109)14.9.2 What May be Stored by Caches (什么将被缓存存储)(110)14.9.3 Modifications of the Basic Expiration Mechanism基本过期机制的更改 (111)14.9.4 Cache Revalidation and Reload Controls缓存重确认和重载控制 (113)14.9.5 No-Transform Directive (不可转换指示) (115)14.9.6 Cache Control Extensions (缓存控制扩展) (116)14.10 Connection (连接) (117)14.11 Content-Encoding (内容编码) (118)14.12 Content-Language (内容语言) (118)14.13 Content-Length (内容长度) (119)14.14 Content-Location (内容位置) (120)14.15 Content-MD5 (内容的MD5校验) (121)14.16 Content-Range (内容范围) (122)14.17 Content-Type (内容类型) (124)14.18 Date (日期) (124)14.18.1 Clockless Origin Server Operation (无时钟服务器操作)..12514.19 ETag (标签) (126)14.20 Expect (期望) (126)14.21 Expires (过期) (127)14.22 From (来自) (128)[页码5]------------------------------------------------------------------------14.23 Host (主机) (128)14.24 If-Match (如果匹配) (129)14.25 If-Modified-Since (如果自从某个时间已经更改) (130)14.26 If-None-Match (如果没有匹配) (132)14.27 If-Range (如果范围) (133)14.28 If-Unmodified-Since (如果自从某个时间未更改) (134)14.29 Last-Modified (最后更改) (134)14.30 Location (位置) (135)14.31 Max-Forwards (最大向前量) (136)14.32 Pragma (语法) (136)14.33 Proxy-Authenticate (代理鉴别) (137)14.34 Proxy-Authorization (代理授权) (137)14.35 Range (范围) (138)14.35.1 Byte Ranges (字节范围) (138)14.35.2 Range Retrieval Requests (范围重获请求) (139)14.36 Referer (引用自) (140)14.37 Retry-After (一会重试) (141)14.38 Server (服务器) (141)14.39 TE (142)14.40 Trailer (追踪者) (143)14.41 Transfer-Encoding(传输编码) (143)14.42 Upgrade (改良) (144)14.43 User-Agent (用户代理) (145)14.44 Vary (变更) (145)14.45 Via (经由) (146)14.46 Warning (警告) (148)14.47 WWW-Authenticate (WWW鉴别) (150)15 Security Considerations (对安全的考虑) (150)15.1 Personal Information(个人信息) (151)15.1.1 Abuse of Server Log Information (服务日志信息的滥用) (151)15.1.2 Transfer of Sensitive Information (敏感信息传输)(151)15.1.3 Encoding Sensitive Information in URI's(对URI中的敏感信息编码) (152)15.1.4 Privacy Issues Connected to Accept Headers(可接受头的秘密问题) (152)15.2 Attacks Based On File and Path Names基于文件名和路径的攻击 (153)15.3 DNS Spoofing (DNS欺骗) (154)15.4 Location Headers and Spoofing (位置头和欺骗) (154)15.5 Content-Disposition Issues (内容部署问题) (154)15.6 Authentication Credentials and Idle Clients(信用鉴定与空闲客户) (155)15.7 Proxies and Caching (代理与缓存) (155)15.7.1 Denial of Service Attacks on Proxies(对代理的服务拒绝攻击) (156)16 Acknowledgments (致谢) (156)17 References (参考) (158)18 Authors' Addresses (作者地址) (162)19 Appendices (附录) (164)19.1 Internet Media Type message/http and application/http(网络媒体类型:消息/HTTP和应用/HTTP) (164)19.2 Internet Media Type multipart/byteranges(网络媒体类型:多部分/字节范围) (165)19.3 Tolerant Applications (容错的应用) (166)19.4 Differences Between HTTP Entities and RFC 2045 Entities(HTTP的实体和RFC2045中实体的区别) (167)[页码6]------------------------------------------------------------------------19.4.1 MIME-Version (MIME版本) (167)19.4.2 Conversion to Canonical Form (语言形式转变) (167)19.4.3 Conversion of Date Formats (日期格式的转变) (168)19.4.4 Introduction of Content-Encoding (内容编码的介绍)(168)19.4.5 No Content-Transfer-Encoding (不要内容传输编码)(168)19.4.6 Introduction of Transfer-Encoding (传输编码的介绍)(169)19.4.7 MHTML and Line Length Limitations(MHTML与行长度限制) (169)19.5 Additional Features (附加的一些性质) (169)19.5.1 Content-Disposition (内容部署) (170)19.6 Compatibility with Previous Versions (与久版本的兼容性)(170)19.6.1 Changes from HTTP/1.0 (自HTTP/1.0的更改) (171)19.6.2 Compatibility with HTTP/1.0 Persistent Connections(与HTTP/1.1持久连接的兼容性) (172)19.6.3 Changes from RFC 2068 (自RFC268的更改) (172)20 Index (索引) (175)21 Full Copyright Statement (完整版权声明) (176)1 概述1.1 目的超文本传输协议(HTTP)是一种应用于分布式、合作式、多媒体信息系统的应用层协议。
TCPIP协议簇常见协议RFC对应表
常见协议RFC对应表COPS Common Open Policy Service公共开放策略服务FANP Flow Attribute Notification Protocol流属性通知协议Finger User Information Protocol用户信息协议FTP File Transfer Protocol文件传输协议HTTP Hypertext Transfer Protocol超文本传输协议IMAP4Internet Message Access Protocol version 4因特网信息访问协议第四版IMPP Instant Messaging and Presence Protocol即时信息表示协议IRC Internet Relay Chat Protocol Internet在线聊天协议ISAKMP Internet Security Association and Key Managemen Interne安全连接和密钥管理协议DNS Domain Name System域名系统DHCP Dynamic Host Configuration Protocol动态主机配置协议BOOTP Bootstrap Protocol引导协议NTP Network Time Protocol网络时间协议NNTP Network News Transfer Protocol网络新闻传输协议POP3Post Office Protocol version 3邮局协议第三版Radius Remote Authentication Dial In User Service远程用户拨号认证服务协议RLOGIN Remote Login远程登陆协议RTSP Real-time Streaming Protocol实时流协议SCTP Stream Control Transmision Protocol流控制传输协议S-HTTP Secure Hypertext Transfer Protocol安全超文本传输协议SLP Service Location Protocol服务定位协议SMTP Simple Mail Transfer Protocol简单邮件传输协议ICP Internet Cache Protocol Internet缓存协议SNMP Simple Network Management Protocol简单网络管理协议SOCKS Socket Secure安全套接字协议TACACS Terminal Access Controller Access Control System终端访问控制器访问控制系统TELNET TCP/IP Terminal Emulation Protocol TCP/IP终端仿真协议TFTP Trivial File Transfer Protocol简单文件传输协议X-Window X Window X WindowPresentation LayerNBSSN NetBIOS Session Service NetBIOS会话服务协议LPP LightWight Presentation Protocol轻量级表示协议Session LayerTLS Transport Layer Security传输层安全协议LDAP Lightweight Directory Access Protocol轻量级目录访问协议RPC Remote Procedure Call protocol 远程过程调用协议Transport LayerMobile IP Mobile IP Protocol移动IP协议RUDP Reliable User Datagram Protocol可靠的用户数据报协议TALI Transport Adapter Layer Interface传输适配层接口协议TCP Transmission Control Protocol传输控制协议UDP User Datagram Protocol用户数据报协议Van Jacobson compressed TCP压缩TCP协议XOT X.25 over TCP基于TCP之上的X.25协议Network LayerEGP Exterior Gateway Protocol外部网关协议OSPF Open Shortest Path First开放最短路径优先协议DVMRP Distance Vector Multicast Routing Protocol距离矢量组播路由协议ICMP Internet Control Message Protocol version 4Internet控制信息协议ICMPv6Internet Control Message Protocol version 6Internet控制信息协议第6版IGMP Internet Group Management Protocol Internet组管理协议IP Internet Protocol version 4互联网协议NHRP Next Hop Resolution Protocol下一跳解析协议IPv6Internet Protocol version 6互联网协议第6版MOSPF Mulitcast Open Shortest Path First组播开放最短路径优先协议PGM Pragamatic General Mulitcast Protocol实际通用组播协议PIM-SM Protocol Independent Multicast-Sparse Mode稀疏模式独立组播协议PIM-DM Protocol Independent Multicast-Dense Mode密集模式独立组播协议SLIP Serial Line IP串行线路IP协议MARS Multicast Address Resolution Server组播地址解析服务器协议RIP2Routing Information Protocol version 2路由信息协议第2版RIPng for IPv6Routing Information Protocol for IPv6IPv6路由信息协议RSVP Resource-Reservation Protocol 资源预留协议VRRP Virtual Router Redundancy Protocol虚拟路由器冗余协议AH Authentication Header Protocol认证头协议ESP Encapsulating Security Payload安全封装有效载荷协议Data Link LayerARP Address Resolution Protocol地址解析协议RARP Reverse Address Resolution Protocol逆向地址解析协议IARP Inverse Address Resolution Protocol逆向地址解析协议DCAP Data Link Switching Client Access Protocol数据转接客户访问协议MPLS Multi-Protocol Label Switching多协议标签交换协议ATMP Ascend Tunnel Management Protocol接入隧道管理协议L2F The Layer 2 Forwarding Protocol第二层转发协议L2TP Layer 2 Tunneling Protocol第二层隧道协议PPTP Point to Point Tunneling Protocol点对点隧道协议RFC 2748RFC 2129 RFC 1194,1196,1228RFC 959RFC 1945,2616RFC 1730RFC 3861RFC 1459RFC 2048RFC 4343RFC 2131RFC 951RFC 958RFC 977RFC 1939RFC 2138RFC 1258,1282RFC 2326RFC 2960RFC 2660RFC 2165RFC 821,2821RFC 2186RFC 1157RFC 1928RFC 1492RFC 854RFC 1350RFC 1198RFC 1001RFC 1085RFC 2246RFC 1777 RFC 1050,1057,1831RFC 2002RFC 908,1151RFC 3094RFC 793RFC 768RFC 1144RFC 1613RFC 827RFC 2178,2328RFC 1075RFC 792RFC 1885,2463 RFC 1112, 2236,3376RFC 791RFC 2332RFC 1883,2460RFC 1585RFC 3208RFC 2362RFC 3973RFC 1055RFC 2022RFC 2453RFC 2080RFC 2205,2750RFC 2338,3768RFC 2402RFC 2406RFC 826RFC 903RFC 2390RFC 2114RFC 3031,3032RFC 2107RFC 2341RFC 2661RFC 2637。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 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)的定义及对其它方面的描述。