RFC3261: SIP:22.4 摘要式身份验证方案

22.4 The Digest Authentication Scheme
22.4 摘要式身份验证方案

   This section describes the modifications and clarifications required to apply the HTTP Digest authentication scheme to SIP.  The SIP scheme usage is almost completely identical to that for HTTP [17].

​本节介绍将HTTP摘要式身份验证方案应用于SIP所需的修改和说明。SIP方案的使用几乎与HTTP[17]完全相同。

   Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], SIP servers supporting RFC 2617 MUST ensure they are backwards compatible with RFC 2069.  Procedures for this backwards compatibility are specified in RFC 2617.  Note, however, that SIP servers MUST NOT accept or request Basic authentication.

​由于RFC 2543基于RFC 2069[39]中定义的HTTP摘要，因此支持RFC 2617的SIP服务端必须确保它们与RFC 2069向后兼容。在RFC 2617中规定了这种向后兼容性的过程。但是，请注意，SIP服务端不得接受或请求基本身份验证。

   The rules for Digest authentication follow those defined in [17], with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following differences:

​摘要式身份验证的规则遵循[17]中定义的规则，“HTTP/1.1”替换为“SIP/2.0”，此外还有以下差异：

      1.  The URI included in the challenge has the following BNF:

1.挑战中包含的URI具有以下BNF：

          URI  =  SIP-URI / SIPS-URI

      2.  The BNF in RFC 2617 has an error in that the 'uri' parameter of the Authorization header field for HTTP Digest authentication is not enclosed in quotation marks.  (The example in Section 3.5 of RFC 2617 is correct.)  For SIP, the 'uri' MUST be enclosed in quotation marks.
​
2.RFC 2617中的BNF有一个错误，即用于HTTP摘要式身份验证的Authorization报头字段的“uri”参数没有包含在引号中。（RFC 2617第3.5节中的示例是正确的。）对于SIP，“uri”必须用引号括起来。

      3.  The BNF for digest-uri-value is:

3.摘要uri值的BNF为：

          digest-uri-value  =  Request-URI ; as defined in Section 25

​
digest-uri-value = Request-URI ;如第25节所定义​

      4.  The example procedure for choosing a nonce based on Etag does not work for SIP.

4.用于基于Etag选择随机数的示例过程不适用于SIP。

      5.  The text in RFC 2617 [17] regarding cache operation does not apply to SIP.

​5.RFC 2617[17]中关于高速缓存操作的文本不适用于SIP。

      6.  RFC 2617 [17] requires that a server check that the URI in the request line and the URI included in the Authorization header field point to the same resource.  In a SIP context, these two URIs may refer to different users, due to forwarding at some  proxy.  Therefore, in SIP, a server MAY check that the Request-URI in the Authorization header field value corresponds to a user for whom the server is willing to accept forwarded or direct requests, but it is not necessarily a failure if the two fields are not equivalent.

​6.RFC 2617[17]要求服务端检查请求行中的URI和Authorization报头字段中包括的URI是否指向相同的资源。在SIP上下文中，由于在某个代理处进行转发，这两个URI可能指代不同的用户。因此，在SIP中，服务端可以检查Authorization报头字段值中的Request-URI是否对应于服务端愿意接受转发或直接请求的用户，但如果这两个字段不相等，则不一定是失败。

      7.  As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when SIP messages have no body) that the hash of the entity-body resolves to the MD5 hash of an empty string, or:

7.作为对摘要式认证方案中用于消息完整性保证的A2值的计算的澄清，实现者应当假设，当实体主体为空时（即，当SIP消息没有主体时），实体主体的散列解析为空字符串的MD5散列，或者：

             H(entity-body) = MD5("") = "d41d8cd98f00b204e9800998ecf8427e"

      8.  RFC 2617 notes that a cnonce value MUST NOT be sent in an Authorization (and by extension Proxy-Authorization) header field if no qop directive has been sent.  Therefore, any algorithms that have a dependency on the cnonce (including "MD5-Sess") require that the qop directive be sent.  Use of the "qop" parameter is optional in RFC 2617 for the purposes of backwards compatibility with RFC 2069; since RFC 2543 was based on RFC 2069, the "qop" parameter must unfortunately remain optional for clients and servers to receive.  However, servers MUST always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values.  If a client receives a "qop" parameter in a challenge header field, it MUST send the "qop" parameter in any resulting authorization header field.

​8.RFC 2617指出，如果没有发送qop指令，则不得在Authorization以及扩展为Proxy-Authorization）报头字段中发送cnonce值。因此，任何依赖cnonce的算法（包括“MD5-Sess”）都要求发送qop指令。为了与RFC 2069向后兼容，在RFC 2617中使用“qop”参数是可选的；由于RFC 2543是基于RFC 2069的，不幸的是，“qop”参数对于客户端和服务端来说必须是可选的。但是，服务端必须始终在WWW-Authenticate和Proxy-Authenticate报头字段值中发送一个“qop”参数。如果客户端在质询标头字段中接收到“qop”参数，则必须在任何生成的授权报头字段中发送“qop”参数。

   RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069).  However, we now allow usage of this header field, since it provides integrity checks over the bodies and provides mutual authentication.  RFC 2617 [17] defines mechanisms for backwards compatibility using the qop attribute in the request. These mechanisms MUST be used by a server to determine if the client supports the new mechanisms in RFC 2617 that were not specified in RFC 2069.

​RFC 2543不允许使用Authentication-Info报头字段（它有效地使用了RFC 2069）。但是，我们现在允许使用这个报头字段，因为它提供了对主体的完整性检查，并提供了相互身份验证。RFC 2617[17]使用请求中的qop属性定义了向后兼容性的机制。服务端必须使用这些机制来确定客户端是否支持RFC 2617中未在RFC 2069中指定的新机制。