RFC2617 中文版.docx

RFC2617 中文版.docx

《RFC2617 中文版.docx》由会员分享，可在线阅读，更多相关《RFC2617 中文版.docx（25页珍藏版）》请在冰豆网上搜索。

RFC2617中文版

1.备忘

本文档跟踪记录Internet团体为完善协议而进行的讨论、建议。

详情请参见官方文件（STD1）。

本文可任意分发。

2.版权申明

Copyright（C）TheInternetSociety（1999）.AllRightsReserved

3.摘要

“HTTP/1.0”中包括基本访问鉴别方案（BasicAccessAuthenticationscheme）。

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

本文档还提供了HTTP鉴别框架的规范，有关原始的基本鉴别方案和基于哈希加密的方案的内容，请参见摘要访问鉴别（DigestAcccessAuthentication）。

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

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

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

4.授权鉴别

4.1.对HTTP/1.1规范的依赖

本规范和HTTP/1.1规范[2]一起使用，它使用HTTP/1.1文档2.1节的补充反馈方式（AugmentedBNF），并依赖于该文档对非终端（non-terminals）的定义及对其它方面的描述。

4.2.访问鉴别框架

HTTP提供了简单的挑战－回应鉴别机制，它可能被服务器用来质询客户端请求，也可能被客户端用来提供鉴别信息。

授权方案用可扩展的、大小写敏感的符号来标识，后跟获取证明所需要的以逗号分隔的‘属性－值’对。

auth-scheme=token

auth-param=token"="（token|quoted-string）

401（未授权）回应消息被原始服务器端用来质询用户代理的授权。

该回应必须包括含有至少一个被请求资源challenge的WWW－鉴别报头域。

407（需要鉴别代理）回应消息被代理用来质询客户端的授权，它的Proxy-Authenticate报头域必须包括至少一个proxy对被请求资源的challenge。

challenge=auth-scheme1*SP1#auth-param

注意：

用户代理（agent）解析WWW-Authenticate或Proxy-Authenticate的报头域，在碰到含有多个challenge或多个WWW-Authenticate报头域时，要特别小心，因为这些challenge本身可能就包含了以逗号分隔的鉴别参数对。

鉴别参数realm的定义在所有的鉴别方案中使用：

realm="realm""="realm-value

realm-value=quoted-string

Realm项（大小写敏感）在所有涉及challenge的鉴别方案中都要用到。

Realm值（大小写敏感）要与被访问服务器的‘根’URL的规范用法（即绝对路径为空的服务器的绝对URI－absoluteURI，见5.1.2节[2]）联合使用，以定义受保护的区间。

这些realm参数允许将服务器上受保护资源分成若干个区间，每个区间都有其自己的鉴别方案和（或）授权数据库。

Realm值是字符串，通常由原始服务器分配，针对某些鉴别方案可能还有附加的语法问题。

注意，可能存在多个challenge，auth-scheme相同，而realm不同的情况。

通常，agent在收到401（未授权）回应时，可能（也可能不会）希望服务器对其授权。

如果希望授权，用户代理将在请求中加入授权请求报头（Authorizationrequest-header）域。

授权域值由信任证书组成，其中有对用户代理所请求资源领域的授权信息。

Client在收到407（需要代理鉴别）回应时，如希望通过代理进行自身的鉴别，可在请求中加入代理授权请求报头域（Proxy-Authorizationrequest-header）。

授权域值和代理授权域值都是由证书（credential）组成，这些证书包括被请求资源的客户端鉴别信息realm的值。

agent必须选用它所能理解的最强的auth-scheme及用户回应challenge的请求信任。

credentials=auth-scheme#auth-param

注意：

许多浏览器只支持基本方案，要求它在auth-scheme中排在第一位。

如果提供最低程度的满意度，服务器端应只支持基本方案。

受保护区间定义了将要自动使用证书的区域。

如果早先的请求已经通过认证，在由授权方案，参数和（或）用户选择等所指定的时间间隔内，其它的请求可通过相同的证书来访问该保护区域。

除非鉴别方案有特别指定，否则单个保护区域不能扩展到该服务器以外的范围。

如果原始服务器不希望通过发送的请求来接受证书，它应当返回401（未授权）回应。

该回应必须包括一个WWW-鉴别报头域，而该域要包含至少一个（可能是新的）对被请求资源的challenge。

如果proxy不接受用请求方式发送证书，它应当返回407（需要代理鉴别）回应。

该回应必须包括一个代理鉴别（Proxy-Authenticate）报头域，而该域要包含至少一个（可能是新的），代理可用的，对被请求资源的challenge。

HTTP协议的访问鉴别并不限于这种简单的challenge-response机制，还可以使用其它的方法，比如传输级加密或消息封装及通过附加报头域来指定鉴别信息等等。

但是，这些方法不在本文档的讨论范围。

proxy必须完全透明地处理原始服务器对useragent的鉴别，也就是说，它们必须在不做任何改动的前提下将WWW-鉴别和授权报头向前推送，这方面的规定见[2]的14.8节。

代理-鉴别（WWW-Authenticate）和代理-授权（Proxy-Authorization）报头域都是hop-by-hop报头（见[2]的13.5.1节）。

5.基本鉴别方案

用户代理必须对于每个领域（realm）通过用户标识（user-ID）及口令来对自身进行授权，这是基本授权方案的工作模式。

Realm值应当被看作不透明的字符串，该值将用于同服务器端其它的realm值相比较。

只有用户标识及口令通过受保护资源的认证，服务器才会给请求授权。

授权参数没有可选项。

对于基本方案，上面所述框架的应用形式如下：

challenge="Basic"realm

credentials="Basic"basic-credentials

在接收到对受保护区域的未经认证的资源请求时，服务器应当回应一个challenge，如下：

WWW-Authenticate:

Basicrealm="WallyWorld"

“WallyWorld”是由服务器分配的字符串，用于对请求URI所指定的受保护资源进行标识。

代理也应使用使用Proxy-Authenticate报头域来回应同样的challenge。

为了接收授权，客户端需要在基于64位（base64[5]）的证书中发送用户标识及口令，中间用冒号’:

’分隔。

basic-credentials=base64-user-pass

base64-user-pass=

exceptnotlimitedto76char/line>

user-pass=userid":

"password

userid=*

">

password=*TEXT

Userids可能是大小写敏感的。

如果用户代理希望发送用户标识”Aladdin”和口令“opensesame”，应当遵循下面的报头域形式：

Authorization:

BasicQWxhZGRpbjpvcGVuIHNlc2FtZQ==

客户端应当假定请求URI中所涉及的所有其它路径都在由当前质询的基本realm值所指定的保护空间中。

客户端在未收到服务器的其它质询时，可能会优先发送对应于该空间资源的授权报头。

同样，当客户向proxy发送请求，它也可能在未收到代理服务器的其它质询之前，在代理授权（Proxy-Authorization）报头域中还使用原来的uerid和password。

详情参见[安全考虑]的第4节中与基本鉴别相关的内容。

6.摘要访问鉴别方案

6.1.介绍

6.1.1.目的

“HTTP/1.0”中包括基本访问鉴别方案（BasicAccessAuthenticationscheme[1]）。

该方案不是安全的用户鉴别方法，因为其用户名和口令在网络上是以明文方式传送的。

本节提供不以明文方式发送口令的方案规范，参见“摘要访问鉴别”。

摘要访问鉴别（DigestAccessAuthentication）方案不是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.该方案的局限性

本文中描述的摘要鉴别方案存在许多已知的局限性，它只是对基本鉴别方案的替代，除此外，别无他用。

它是基于口令认证的系统，在服务器端也要面对任何其它口令系统同样存在的问题。

本协议并没有为最初用户和服务器间的口令建立提供安全做法。

用户和开发者都应注意，该协议并不象Kerberos或任何客户端的私钥方案那样安全。

但是，即便它一无是处，总还比在telnet、ftp用的机制好一些，当然，也比基本方案安全。

6.2.摘要报头的规范

摘要访问鉴别方案在概念上与基本方案相似。

更改的WWW-鉴别报头行和授权报头行的格式在下面给出。

另外，还有个新的报头，即Authentication-Info，也在下面指定。

6.2.1.WWW-Authenticate响应报头

服务器在收到对受保护对象未经认证的访问请求时，会回应401（未授权）状态码。

在摘要方案中，WWW-鉴报头题应遵循如下写法：

challenge="Digest"digest-challenge

digest-challenge=1#（realm|[domain]|nonce|

[opaque]|[stale]|[algorithm]|[qop-options]|[auth-param]）

domain="domain""="<">URI（1*SPURI）<">

URI=absoluteURI|abs_path

Nonce="nonce""="nonce-value

nonce-value=quoted-string

opaque="opaque""="quoted-string

stale="stale""="（"true"|"false"）

algorithm="algorithm""="（"MD5"|"MD5-sess"|token）

qop-options="qop""="<">1#qop-value<">

qop-value="auth"|"auth-int"|token

上面表示值的意思如下：

◆realm：

显示给用户看的字符串，这样他们就知道使用哪个用户名和口令了。

该字符串应当包括至少一个执行鉴别的主机名和对可能访问用户群体的附加项。

例如：

****************************.com

◆domain：

指在引号中用空格分隔的URI列表（见RFCXURI[7]中定义的保护区间）。

如果URI是采用绝对路径，它是相对于被访问服务器‘根’的URL（见上面1.2节）。

该列表中的绝对URI被用来访问另外一个不同的服务器。

客户端可发送同样的鉴别信息来访问由此列表确定的URI集合：

任何URI，只要其做为前缀出现在列表中，就可以认为它指向同样的受保护区域。

如果表示被忽略或是空值，客户端应这样理解，即，该保护区域由回应服务器的全部URI组成。

该表示对代理-鉴别（Proxy-Authenticate）报头没有意义，因为对它们来说，受保护区域总是整个代理（proxy），如果出现，也会被忽略。

◆nonce：

服务器端指定的数据字符，它应在每个401回应产生时，被唯一地创建。

建议该字符以base64方式或16进制方式出现。

另外，该字符在报头行中传递时是在引号内的，因此不允许使用双引号字符。

其内容与实现无关，而其实现的质量取决于良好的选择。

例如，nonce可能以基于64位编码来构造，如下例：

time-stampH（time-stamp":

"ETag":

"private-key）。

如上，时间戳（time-stamp）是由服务器产生的时间值或其它非重复值；Etag是HTTP与请求实体相关的ETag报头的值；private-key是只有服务器才知道的值。

在碰到这种形式的nonce时，服务器在收到客户鉴别报头后，会对哈希部分进行重新计算，并在nonce值与报头不符或其time-stamp值不够新时拒绝该请求。

通过这种方式，服务器端可以限制nonce合法的时间范围。

Etag中的内容将防止对资源的更新版本进行重复请求。

（注意：

在nonce中包括客户端的IP地址将向服务器提出要求，即不要再重用同样客户发出的nonce值。

实际上，单个用户发出的请求会穿越多个代理，这样做可能导致该过程的中断。

另外，IP地址也是可以假冒的）。

有的实现可能会选择不接受先前先用的nonce或先前使用的摘要，以防止回放式攻击（replayattack）。

或者，实现在回应POST｜PUT请求时，也可以选择以前的nonce或摘要（digest）和GET请求的time-stamp。

更详细的信息，见本文第4节。

nonce是客户端的opaque。

◆opaque：

由服务器指定的字符串，客户端不能改动它，如果并发请求的URI也指向同一个受保护区间，则该信息将被加在这些请求的授权报头域中返给服务器。

建议采用base64或16进制的字符串。

◆stale：

一个标志，用来指示客户端先前的请求因其nonce值过期而被拒绝。

如果stale是TRUE（大小写敏感），客户端可能希望用新的加密回应重新进行请求，而不用麻烦用户提供新的用户名和口令。

服务器端只有在收到的请求nonce值不合法，而该nonce对应的摘要（digest）是合法的情况下（即客户端知道正确的用户名/口令），才能将stale置成TRUE值。

如果stale是FALSE或其它非TRUE值，或者其stale域不存在，说明用户名、口令非法，要求输入新的值。

◆algorithm：

是个字符串，用来项用来产生摘要及校验和的算法对。

如果该域没指定，则认为是“MD5“算法。

如果该域指定的算法无法理解，该challenge将被忽略。

在本文档中,用KD（secret,data）表示对数据"data"和"secret"调用摘要算法获取字符串，用H（data）表示对数据"data"调用校验和算法获取字符串。

而unq（X）表示将带引号字符串的引号去掉。

对于"MD5"和"MD5-sess"算法：

H（data）=MD5（data），并且KD（secret,data）=H（concat（secret,":

",data））。

也就是说，摘要（digest）就是对secret与data通过冒号连接一起的结果进行MD5运算。

而"MD5-sess"算法则允许其它第三方服务器参与鉴别。

具体用法的区别，参见3.2.2.2节的描述。

◆qop-options：

该项是可选的，用于RFC2069[6]的向后兼容。

它应当被与该摘要方案版本兼容的任何实现所使用。

如果存在，它是带引号的一个或多个字符组成的字符串，用来指示服务器支持的保护水平（qualityofprotection）。

“auth”值表示鉴别方式，“auth-int”表示鉴别保护的完整性。

见后面为有该项选择的应用程序重新计算回应项值。

不能识别的选项必须被忽略。

◆auth-param：

该项用于未来扩展。

任何无法识别的项都必须被忽略。

6.2.2.Authorization请求报头

客户端想重试发送请求，并传递对应前面所框架定义的授权报头行，如下：

credentials="Digest"digest-response

digest-response=1#（username|realm|nonce|digest-uri|response|[algorithm]|[cnonce]|[opaque]|[message-qop]|[nonce-count]|[auth-param]）

username="username""="username-value

username-value=quoted-string

digest-uri="uri""="digest-uri-value

digest-uri-value=request-uri;AsspecifiedbyHTTP/1.1

message-qop="qop""="qop-value

cnonce="cnonce""="cnonce-value

cnonce-value=nonce-value

nonce-count="nc""="nc-value

nc-value=8LHEX

response="response""="request-digest

request-digest=<">32LHEX<">

LHEX="0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|

"8"|"9"|"a"|"b"|"c"|"d"|"e"|"f"

opaque域和算法（algorithm）域的值必须在被请求实体的WWW-鉴别回应报头中给出。

◆response：

是个字符串，由32个经过计算的16进制数字组成，用来证明用户是否知道口令。

◆username：

用户名，是指定的realm项。

◆digest-uri：

从请求队列（Request-Line）中的请求URI得到的URI；这里存在副本是因为代理（proxy）在传送时允许对请求队列进行修改。

◆qop：

该项指客户端对该消息应用的保护等级（qualityofprotection）。

如果不为空，其值必须是服务器支持在WWW-Authenticate报头中采用的几种值之一。

这些值会对request-digest的计算造成影响。

注意，这是个单独的符号，而不是象WWW-Authenticate那样，是带引号的可选值列表。

该项是可选项，这是为了和RFC2069[6]所规定的最小实现保持向后的兼容性。

但是，如果服务器端通过在WWW-Authenticate报头域中添加qop项，就表明该服务器支持qop，因而，必须使用该项项。

◆cnonce：

当qop项发送了，该项必须要指定，而当服务器端没有在WWW-Authenticate报头域中添加qop项时，该项一定不能指定。

cnonce-value是客户端提供的字符串，它由客户端和服务器共同使用，用来避免选择纯文本攻击、提供共同鉴别、提供某些消息的完整性保护。

详情见下面的response-digest值和request-digest值的计算。

◆nonce-count：

当qop项发送了（见上面），该项必须要指定，而当服务器端没有在WWW-鉴别（WWW-Authenticate）报头域中添加qop项时，该项一定不能指定。

nc-value是16进制表示的计数值，用来统计客户端发送的带nonce值的请求（包括当前请求）个数。

例如，在第一个请求回应中给出了nonce的值，客户端发送”nc=00000001"，其目的是允许服务器通过对此计算副本的维护来检测请求重复（requestreplay），即当同样的nc-value出现两次，说明请求是可回放的。

详情见下面请求-摘要（request-digest）值的构建。

◆auth-param：

该项用于未来扩展。

任何无法识别的项都应被忽略。

如果项或其值不正确，或者需要的项没有给出，都会得到400（非法请求）回应。

如果request-digest是非法的，登录失败将会被记入日志，因为在某个单独的客户端出现的重复登录失败可能意味着攻击者正试图猜测口令。

前面定义的request-digest指示了其编码方式。

下面的定义将表明这些值是如何参与计算的。

Request-Digest

如果“qop”值是"auth"或"auth-int"：

request-digest=<">

":

"nc-value

":

"unq（cnonce-value）

":

"unq（qop-value）

":

"H（A2）

）<">

如果“qop”项没有给出（与RFC2069保持兼容性）：

request-digest=<">

"H（A2））<">

A1及A2的定义在下面。

A1

如果"algorithm"值是“MD5”或没有指定，则A1是：

A1=unq（username-value）":

"unq（realm-value）":

"passwd

其中：

passwd=

如果"algorithm"值是"MD5-sess"，则A1只要计算一次，即当客户端发出第一个请求，并从服务器收到WWW-Authenticatechallenge时计算。

它使用该challenge中的服务器的nonce，则用来构建A1的第一个客户端nonce值应为：

A1=H（unq（username-value）":

"unq（realm-value）

":

"passwd）

":

"unq（nonce-value）":

"unq（cnonce-value）

上式为并发请求和回应的鉴别产生一个“s