RFC2617 中文版
- 格式：doc
- 大小：177.50 KB
- 文档页数：30
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）。
该方案不是安全的用户授权方法（除非与其它安全方法联合使用，如SSL[5]），因为其用户名和口令在网络上是以明文方式传送的。
本文档还提供了HTTP鉴别框架的规范，有关原始的基本鉴别方案和基于哈希加密的方案的内容，请参见摘要访问鉴别（Digest Acccess Authentication）。
从RFC2069公布以来，其中涉及的一些可选元素因为出现问题而被移出；而还有一些新的元素因为兼容性的原因而被加入，这些新元素虽然是可选的，但还是强烈建议使用的，因而，RFC2069[6]最终可能会被本规范所替代。
与基本方式类似的是，摘要鉴别授权对通讯双方都知道的秘密（如口令）进行校验；而与基本方式不同的是，该校验方式中的口令不以明文方式传输，而这正是基本方式的最大弱点。
正象其它大多数授权协议那样，该协议最大的风险不在于其协议本身，而是它周边的应用程序。
4.授权鉴别4.1. 对HTTP/1.1规范的依赖本规范和HTTP/1.1规范[2]一起使用，它使用HTTP/1.1文档2.1节的补充反馈方式（Augmented BNF），并依赖于该文档对非终端（non-terminals）的定义及对其它方面的描述。
4.2. 访问鉴别框架HTTP提供了简单的挑战－回应鉴别机制，它可能被服务器用来质询客户端请求，也可能被客户端用来提供鉴别信息。
授权方案用可扩展的、大小写敏感的符号来标识，后跟获取证明所需要的以逗号分隔的‘属性－值’对。
401（未授权）回应消息被原始服务器端用来质询用户代理的授权。
该回应必须包括含有至少一个被请求资源challenge的WWW－鉴别报头域。
407（需要鉴别代理）回应消息被代理用来质询客户端的授权，它的Proxy-Authenticate报头域必须包括至少一个proxy对被请求资源的challenge。
注意：用户代理（agent）解析WWW-Authenticate或Proxy-Authenticate的报头域，在碰到含有多个challenge或多个WWW-Authenticate报头域时，要特别小心，因为这些challenge本身可能就包含了以逗号分隔的鉴别参数对。
鉴别参数realm的定义在所有的鉴别方案中使用：Realm项（大小写敏感）在所有涉及challenge的鉴别方案中都要用到。
Realm值（大小写敏感）要与被访问服务器的‘根’URL的规范用法（即绝对路径为空的服务器的绝对URI －absoluteURI，见5.1.2节[2]）联合使用，以定义受保护的区间。
这些realm参数允许将服务器上受保护资源分成若干个区间，每个区间都有其自己的鉴别方案和（或）授权数据库。
Realm值是字符串，通常由原始服务器分配，针对某些鉴别方案可能还有附加的语法问题。
注意，可能存在多个challenge，auth-scheme相同，而realm不同的情况。
通常，agent在收到401（未授权）回应时，可能（也可能不会）希望服务器对其授权。
如果希望授权，用户代理将在请求中加入授权请求报头（Authorization request-header）域。
授权域值由信任证书组成，其中有对用户代理所请求资源领域的授权信息。
Client在收到407（需要代理鉴别）回应时，如希望通过代理进行自身的鉴别，可在请求中加入代理授权请求报头域（Proxy-Authorization request-header）。
授权域值和代理授权域值都是由证书（credential）组成，这些证书包括被请求资源的客户端鉴别信息realm的值。
agent 必须选用它所能理解的最强的auth-scheme及用户回应challenge的请求信任。
注意：许多浏览器只支持基本方案，要求它在auth-scheme中排在第一位。
如果提供最低程度的满意度，服务器端应只支持基本方案。
受保护区间定义了将要自动使用证书的区域。
如果早先的请求已经通过认证，在由授权方案，参数和（或）用户选择等所指定的时间间隔内，其它的请求可通过相同的证书来访问该保护区域。
除非鉴别方案有特别指定，否则单个保护区域不能扩展到该服务器以外的范围。
如果原始服务器不希望通过发送的请求来接受证书，它应当返回401（未授权）回应。
该回应必须包括一个WWW-鉴别报头域，而该域要包含至少一个（可能是新的）对被请求资源的challenge。
如果proxy不接受用请求方式发送证书，它应当返回407（需要代理鉴别）回应。
该回应必须包括一个代理鉴别（Proxy-Authenticate）报头域，而该域要包含至少一个（可能是新的），代理可用的，对被请求资源的challenge。
HTTP协议的访问鉴别并不限于这种简单的challenge-response机制，还可以使用其它的方法，比如传输级加密或消息封装及通过附加报头域来指定鉴别信息等等。
但是，这些方法不在本文档的讨论范围。
proxy必须完全透明地处理原始服务器对user agent的鉴别，也就是说，它们必须在不做任何改动的前提下将WWW-鉴别和授权报头向前推送，这方面的规定见[2]的14.8节。
代理-鉴别（WWW-Authenticate）和代理-授权（Proxy-Authorization）报头域都是hop-by-hop报头（见[2]的13.5.1节）。
5.基本鉴别方案用户代理必须对于每个领域（realm）通过用户标识（user-ID）及口令来对自身进行授权，这是基本授权方案的工作模式。
Realm值应当被看作不透明的字符串，该值将用于同服务器端其它的realm值相比较。
只有用户标识及口令通过受保护资源的认证，服务器才会给请求授权。
授权参数没有可选项。
对于基本方案，上面所述框架的应用形式如下：在接收到对受保护区域的未经认证的资源请求时，服务器应当回应一个challenge，如下：“WallyWorld”是由服务器分配的字符串，用于对请求URI所指定的受保护资源进行标识。
代理也应使用使用Proxy-Authenticate报头域来回应同样的challenge。
为了接收授权，客户端需要在基于64位（base64 [5]）的证书中发送用户标识及口令，中间用冒号’:’分隔。
Userids可能是大小写敏感的。
如果用户代理希望发送用户标识”Aladdin”和口令“open sesame”，应当遵循下面的报头域形式：客户端应当假定请求URI中所涉及的所有其它路径都在由当前质询的基本realm值所指定的保护空间中。
客户端在未收到服务器的其它质询时，可能会优先发送对应于该空间资源的授权报头。
同样，当客户向proxy发送请求，它也可能在未收到代理服务器的其它质询之前，在代理授权（Proxy-Authorization）报头域中还使用原来的uerid和password。
详情参见[安全考虑]的第4节中与基本鉴别相关的内容。
6.摘要访问鉴别方案6.1. 介绍6.1.1.目的“HTTP/1.0”中包括基本访问鉴别方案（Basic Access Authentication scheme[1]）。
该方案不是安全的用户鉴别方法，因为其用户名和口令在网络上是以明文方式传送的。
本节提供不以明文方式发送口令的方案规范，参见“摘要访问鉴别”。
摘要访问鉴别（Digest Access Authentication）方案不是WWW安全问题的最终解决方案。
该方案不提供消息内容的加密，其目的只是创建一个简单的鉴别方法，以弥补基本鉴别方案中存在的大部分严重漏洞。
6.1.2.操作概述和基本访问鉴别相似，摘要方案基于简单的挑战－回应范例。
摘要方案使用nonce值来challenge。
合法的回应包含对用户名、口令、给定nonce值、HTTP方法、请求URI的校验和（checksum，缺省是MD5的校验和），因此，口令不会以明文方式传送。
有些基本方案要求将用户名及口令预先排成一定的格式（不在本文范围）后再行使用。
6.1.3.摘要值的表示可选的报头，允许服务器指定用来创建校验和或摘要的算法。
MD5是缺省的方法，而且也是本文唯一提及的算法。
在本文中，128位的MD5摘要由32个可打印的ASCII码字符表示。
128位摘要中的位按其重要性由高到低转换，在某个时刻每4位可用下面的ASCII表示。
每4位都可用16进制字符‘0123456789abcdef’表示，也就是说，二进制0000由字符‘0’表示；0001由字符‘1’表示，以后如此类推，1111用‘f’表示。
6.1.4.该方案的局限性本文中描述的摘要鉴别方案存在许多已知的局限性，它只是对基本鉴别方案的替代，除此外，别无他用。
它是基于口令认证的系统，在服务器端也要面对任何其它口令系统同样存在的问题。
本协议并没有为最初用户和服务器间的口令建立提供安全做法。
