RFC2617 中文版.doc

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 备忘 本文档跟踪记录Internet团体为完善协议而进行的讨论、建议。详情请参见官方文件（STD1）。本文可任意分发。 版权申明 Copyright (C) The Internet Society (1999). All Rights Reserved 摘要 “HTTP/1.0”中包括基本访问鉴别方案（Basic Access Authentication scheme）。该方案不是安全的用户授权方法（除非与其它安全方法联合使用，如SSL[5]），因为其用户名和口令在网络上是以明文方式传送的。 本文档还提供了HTTP鉴别框架的规范，有关原始的基本鉴别方案和基于哈希加密的方案的内容，请参见摘要访问鉴别（Digest Acccess Authentication）。从RFC2069公布以来，其中涉及的一些可选元素因为出现问题而被移出；而还有一些新的元素因为兼容性的原因而被加入，这些新元素虽然是可选的，但还是强烈建议使用的，因而，RFC2069[6]最终可能会被本规范所替代。 与基本方式类似的是，摘要鉴别授权对通讯双方都知道的秘密（如口令）进行校验；而与基本方式不同的是，该校验方式中的口令不以明文方式传输，而这正是基本方式的最大弱点。正象其它大多数授权协议那样，该协议最大的风险不在于其协议本身，而是它周边的应用程序。授权鉴别 对HTTP/1.1规范的依赖 本规范和HTTP/1.1规范[2]一起使用，它使用HTTP/1.1文档2.1节的补充反馈方式（Augmented BNF），并依赖于该文档对非终端（non-terminals）的定义及对其它方面的描述。 访问鉴别框架 HTTP提供了简单的挑战－回应鉴别机制，它可能被服务器用来质询客户端请求，也可能被客户端用来提供鉴别信息。授权方案用可扩展的、大小写敏感的符号来标识，后跟获取证明所需要的以逗号分隔的‘属性－值’对。 auth-scheme = token auth-param = token "=" ( token | quoted-string ) 401（未授权）回应消息被原始服务器端用来质询用户代理的授权。该回应必须包括含有至少一个被请求资源challenge的WWW－鉴别报头域。407（需要鉴别代理）回应消息被代理用来质询客户端的授权，它的Proxy-Authenticate报头域必须包括至少一个proxy对被请求资源的challenge。 challenge = auth-scheme 1*SP 1#auth-param 注意：用户代理（agent）解析WWW-Authenticate或Proxy-Authenticate的报头域，在碰到含有多个challenge或多个WWW-Authenticate报头域时，要特别小心，因为这些challenge本身可能就包含了以逗号分隔的鉴别参数对。 鉴别参数realm的定义在所有的鉴别方案中使用： realm = "realm" "=" realm-value realm-value = quoted-string Realm项（大小写敏感）在所有涉及challenge的鉴别方案中都要用到。Realm值（大小写敏感）要与被访问服务器的‘根’URL的规范用法（即绝