Network Working Group B. Sterman
Request for Comments: 4590 Kayote Networks
Category: Standards Track D. Sadolevsky
SecureOL, Inc.
D. Schwartz
Kayote Networks
D. Williams
Cisco Systems
W. Beck
Deutsche Telekom AG
July 2006
Network Working Group B. Sterman
Request for Comments: 4590 Kayote Networks
Category: Standards Track D. Sadolevsky
SecureOL, Inc.
D. Schwartz
Kayote Networks
D. Williams
Cisco Systems
W. Beck
Deutsche Telekom AG
July 2006
RADIUS Extension for Digest Authentication
用于摘要身份验证的RADIUS扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP.
本文档定义了对远程身份验证拨入用户服务（RADIUS）协议的扩展，以支持摘要身份验证，并与HTTP样式的协议（如会话启动协议（SIP）和HTTP）一起使用。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. Motivation .................................................3
1.3. Overview ...................................................4
2. Detailed Description ............................................6
2.1. RADIUS Client Behavior .....................................6
2.1.1. Credential Selection ................................6
2.1.2. Constructing an Access-Request ......................6
2.1.3. Constructing an Authentication-Info Header ..........7
2.1.4. Failed Authentication ...............................8
2.1.5. Obtaining Nonces ....................................9
2.2. RADIUS Server Behavior .....................................9
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. Motivation .................................................3
1.3. Overview ...................................................4
2. Detailed Description ............................................6
2.1. RADIUS Client Behavior .....................................6
2.1.1. Credential Selection ................................6
2.1.2. Constructing an Access-Request ......................6
2.1.3. Constructing an Authentication-Info Header ..........7
2.1.4. Failed Authentication ...............................8
2.1.5. Obtaining Nonces ....................................9
2.2. RADIUS Server Behavior .....................................9
2.2.1. General Attribute Checks ............................9
2.2.2. Authentication .....................................10
2.2.3. Constructing the Reply .............................11
3. New RADIUS Attributes ..........................................12
3.1. Digest-Response attribute .................................12
3.2. Digest-Realm Attribute ....................................13
3.3. Digest-Nonce Attribute ....................................13
3.4. Digest-Response-Auth Attribute ............................14
3.5. Digest-Nextnonce Attribute ................................14
3.6. Digest-Method Attribute ...................................14
3.7. Digest-URI Attribute ......................................15
3.8. Digest-Qop Attribute ......................................15
3.9. Digest-Algorithm Attribute ................................16
3.10. Digest-Entity-Body-Hash Attribute ........................16
3.11. Digest-CNonce Attribute ..................................17
3.12. Digest-Nonce-Count Attribute .............................17
3.13. Digest-Username Attribute ................................17
3.14. Digest-Opaque Attribute ..................................18
3.15. Digest-Auth-Param Attribute ..............................18
3.16. Digest-AKA-Auts Attribute ................................19
3.17. Digest-Domain Attribute ..................................19
3.18. Digest-Stale Attribute ...................................20
3.19. Digest-HA1 Attribute .....................................20
3.20. SIP-AOR Attribute ........................................21
4. Diameter Compatibility .........................................21
5. Table of Attributes ............................................22
6. Examples .......................................................23
7. IANA Considerations ............................................27
8. Security Considerations ........................................27
8.1. Denial of Service .........................................28
8.2. Confidentiality and Data Integrity ........................28
9. Acknowledgements ...............................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................30
2.2.1. General Attribute Checks ............................9
2.2.2. Authentication .....................................10
2.2.3. Constructing the Reply .............................11
3. New RADIUS Attributes ..........................................12
3.1. Digest-Response attribute .................................12
3.2. Digest-Realm Attribute ....................................13
3.3. Digest-Nonce Attribute ....................................13
3.4. Digest-Response-Auth Attribute ............................14
3.5. Digest-Nextnonce Attribute ................................14
3.6. Digest-Method Attribute ...................................14
3.7. Digest-URI Attribute ......................................15
3.8. Digest-Qop Attribute ......................................15
3.9. Digest-Algorithm Attribute ................................16
3.10. Digest-Entity-Body-Hash Attribute ........................16
3.11. Digest-CNonce Attribute ..................................17
3.12. Digest-Nonce-Count Attribute .............................17
3.13. Digest-Username Attribute ................................17
3.14. Digest-Opaque Attribute ..................................18
3.15. Digest-Auth-Param Attribute ..............................18
3.16. Digest-AKA-Auts Attribute ................................19
3.17. Digest-Domain Attribute ..................................19
3.18. Digest-Stale Attribute ...................................20
3.19. Digest-HA1 Attribute .....................................20
3.20. SIP-AOR Attribute ........................................21
4. Diameter Compatibility .........................................21
5. Table of Attributes ............................................22
6. Examples .......................................................23
7. IANA Considerations ............................................27
8. Security Considerations ........................................27
8.1. Denial of Service .........................................28
8.2. Confidentiality and Data Integrity ........................28
9. Acknowledgements ...............................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................30
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The use of normative requirement key words in this document shall apply only to RADIUS client and RADIUS server implementations that include the features described in this document. This document creates no normative requirements for existing implementations.
本文件中规范性要求关键字的使用仅适用于包含本文件所述功能的RADIUS客户端和RADIUS服务器实现。本文件对现有实施没有任何规范性要求。
HTTP-style protocol The term 'HTTP-style' denotes any protocol that uses HTTP-like headers and uses HTTP Digest Authentication as described in [RFC2617]. Examples are HTTP and the Session Initiation Protocol (SIP).
HTTP样式协议术语“HTTP样式”表示使用类似HTTP的头并使用[RFC2617]中所述HTTP摘要身份验证的任何协议。例如HTTP和会话启动协议（SIP）。
NAS Network Access Server, the RADIUS client.
NAS网络访问服务器，RADIUS客户端。
nonce An unpredictable value used to prevent replay attacks. The nonce generator may use cryptographic mechanisms to produce nonces it can recognize without maintaining state.
nonce用于防止重播攻击的不可预测值。nonce生成器可以使用加密机制来生成它可以识别的nonce，而无需维护状态。
protection space HTTP-style protocols differ in their definition of the protection space. For HTTP, it is defined as the combination of realm and canonical root URL of the requested resource for which the use is authorized by the RADIUS server. In the case of SIP, the realm string alone defines the protection space.
保护空间HTTP风格的协议在保护空间的定义上有所不同。对于HTTP，它被定义为RADIUS服务器授权使用的请求资源的领域和规范根URL的组合。对于SIP，领域字符串单独定义保护空间。
SIP UA SIP User Agent, an Internet endpoint that uses the Session Initiation Protocol.
SIP UA SIP用户代理，使用会话启动协议的Internet端点。
SIP UAS SIP User Agent Server, a logical entity that generates a response to a SIP (Session Initiation Protocol) request.
SIP UAS SIP用户代理服务器，生成对SIP（会话启动协议）请求的响应的逻辑实体。
The HTTP Digest Authentication mechanism, defined in [RFC2617], was subsequently adapted for use with SIP [RFC3261]. Due to the limitations and weaknesses of Digest Authentication (see [RFC2617], section 4), additional authentication and encryption mechanisms are defined in SIP [RFC3261], including Transport Layer Security (TLS) [RFC4346] and Secure MIME (S/MIME) [RFC3851]. However, Digest Authentication support is mandatory in SIP implementations, and Digest Authentication is the preferred way for a SIP UA to authenticate itself to a proxy server. Digest Authentication is used in other protocols as well.
[RFC2617]中定义的HTTP摘要身份验证机制随后被改编为与SIP[RFC3261]一起使用。由于摘要身份验证的局限性和弱点（参见[RFC2617]第4节），SIP[RFC3261]中定义了额外的身份验证和加密机制，包括传输层安全性（TLS）[RFC4346]和安全MIME（S/MIME）[RFC3851]。然而，摘要身份验证支持在SIP实现中是强制性的，并且摘要身份验证是SIP UA向代理服务器进行自身身份验证的首选方式。摘要身份验证也用于其他协议中。
To simplify the provisioning of users, there is a need to support this authentication mechanism within Authentication, Authorization, and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter [RFC3588].
为了简化用户配置，需要在身份验证、授权和记帐（AAA）协议（如RADIUS[RFC2865]和Diameter[RFC3588]）中支持此身份验证机制。
This document defines an extension to the RADIUS protocol to enable support of Digest Authentication for use with SIP, HTTP, and other HTTP-style protocols using this authentication method. Support for Digest mechanisms such as Authentication and Key Agreement (AKA) [RFC3310] is also supported. A companion document [SIP-APP] defines support for Digest Authentication within Diameter.
本文档定义了RADIUS协议的扩展，以支持摘要身份验证，以便使用此身份验证方法与SIP、HTTP和其他HTTP样式的协议一起使用。还支持诸如身份验证和密钥协议（AKA）[RFC3310]之类的摘要机制。附带文档[SIP-APP]定义了对Diameter内摘要身份验证的支持。
HTTP Digest is a challenge-response protocol used to authenticate a client's request to access some resource on a server. Figure 1 shows a single HTTP Digest transaction.
HTTP摘要是一种质询响应协议，用于验证客户端访问服务器上某些资源的请求。图1显示了一个HTTP摘要事务。
HTTP/SIP..
+------------+ (1) +------------+
| |--------->| |
| HTTP-style | (2) | HTTP-style |
| client |<---------| server |
| | (3) | |
| |--------->| |
| | (4) | |
| |<---------| |
+------------+ +------------+
HTTP/SIP..
+------------+ (1) +------------+
| |--------->| |
| HTTP-style | (2) | HTTP-style |
| client |<---------| server |
| | (3) | |
| |--------->| |
| | (4) | |
| |<---------| |
+------------+ +------------+
Figure 1: Digest operation without RADIUS
图1：无半径的摘要操作
If the client sends a request without any credentials (1), the server will reply with an error response (2) containing a nonce. The client creates a cryptographic digest from parts of the request, from the nonce it received from the server, and from a shared secret. The client re-transmits the request (3) to the server, but now includes the digest within the packet. The server does the same digest calculation as the client and compares the result with the digest it received in (3). If the digest values are identical, the server grants access to the resource and sends a positive response to the client (4). If the digest values differ, the server sends a negative response to the client (4).
如果客户端发送的请求没有任何凭据（1），服务器将使用包含nonce的错误响应（2）进行响应。客户机从请求的一部分、从服务器收到的nonce和共享机密创建加密摘要。客户端将请求（3）重新传输到服务器，但现在将摘要包含在数据包中。服务器执行与客户端相同的摘要计算，并将结果与（3）中接收到的摘要进行比较。如果摘要值相同，则服务器授予对资源的访问权，并向客户端发送肯定响应（4）。如果摘要值不同，服务器将向客户端发送否定响应（4）。
Instead of maintaining a local user database, the server could use RADIUS to access a centralized user database. However, RADIUS [RFC2865] does not include support for HTTP Digest Authentication. The RADIUS client cannot use the User-Password attribute, since it does not receive a password from the HTTP-style client. The CHAP-Challenge and CHAP-Password attributes described in [RFC1994] are also not suitable since the CHAP algorithm is not compatible with HTTP Digest.
服务器可以使用RADIUS访问集中式用户数据库，而不是维护本地用户数据库。但是，RADIUS[RFC2865]不支持HTTP摘要身份验证。RADIUS客户端无法使用“用户密码”属性，因为它没有从HTTP样式的客户端接收密码。[RFC1994]中描述的CHAP质询和CHAP密码属性也不适用，因为CHAP算法与HTTP摘要不兼容。
This document defines new attributes that enable the RADIUS server to perform the digest calculation defined in [RFC2617], providing support for Digest Authentication as a native authentication mechanism within RADIUS.
本文档定义了使RADIUS服务器能够执行[RFC2617]中定义的摘要计算的新属性，为摘要身份验证作为RADIUS中的本机身份验证机制提供了支持。
The nonces required by the digest algorithm are generated by the RADIUS server. Generating them in the RADIUS client would save a round-trip, but introduce security and operational issues. Some digest algorithms -- e.g., AKA [RFC3310] -- would not work.
摘要算法所需的nonce由RADIUS服务器生成。在RADIUS客户机中生成它们将节省往返时间，但会带来安全和操作问题。一些摘要算法——例如AKA[RFC3310]——无法工作。
Figure 2 depicts a scenario in which the HTTP-style server defers authentication to a RADIUS server. Entities A and B communicate using HTTP or SIP, while entities B and C communicate using RADIUS.
图2描述了HTTP样式服务器将身份验证推迟到RADIUS服务器的场景。实体A和B使用HTTP或SIP进行通信，而实体B和C使用RADIUS进行通信。
HTTP/SIP RADIUS
HTTP/SIP RADIUS
+-----+ (1) +-----+ +-----+
| |==========>| | (2) | |
| | | |---------->| |
| | | | (3) | |
| | (4) | |<----------| |
| |<==========| | | |
| | (5) | | | |
| |==========>| | | |
| A | | B | (6) | C |
| | | |---------->| |
| | | | (7) | |
| | | |<----------| |
| | (8) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
+-----+ (1) +-----+ +-----+
| |==========>| | (2) | |
| | | |---------->| |
| | | | (3) | |
| | (4) | |<----------| |
| |<==========| | | |
| | (5) | | | |
| |==========>| | | |
| A | | B | (6) | C |
| | | |---------->| |
| | | | (7) | |
| | | |<----------| |
| | (8) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
====> HTTP/SIP
----> RADIUS
====> HTTP/SIP
----> RADIUS
Figure 2: HTTP Digest over RADIUS
图2:RADIUS上的HTTP摘要
The entities have the following roles:
这些实体具有以下角色：
A: HTTP client / SIP UA
A:HTTP客户端/SIPUA
B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
acting also as a RADIUS NAS
B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
acting also as a RADIUS NAS
C: RADIUS server
C:RADIUS服务器
The following messages are sent in this scenario:
在此场景中发送以下消息：
A sends B an HTTP/SIP request without an authorization header (step 1). B sends an Access-Request packet with the newly defined Digest-Method and Digest-URI attributes but without a Digest-Nonce attribute to the RADIUS server, C (step 2). C chooses a nonce and responds with an Access-Challenge (step 3). This Access-Challenge contains Digest attributes, from which B takes values to construct an HTTP/SIP "(Proxy) Authorization required" response. B sends this response to A (step 4). A resends its request with its credentials (step 5). B sends an Access-Request to C (step 6). C checks the credentials and replies with Access-Accept or Access-Reject (step 7). Depending on C's result, B processes A's request or rejects it with a "(Proxy) Authorization required" response (step 8).
A向B发送一个HTTP/SIP请求，但不带授权头（步骤1）。B向RADIUS服务器C发送具有新定义的摘要方法和摘要URI属性但不具有摘要Nonce属性的访问请求数据包（步骤2）。C选择一个nonce并用访问质询进行响应（步骤3）。此访问质询包含摘要属性，B从中获取值以构造HTTP/SIP“（代理）授权要求”响应。B将此响应发送给A（步骤4）。A使用其凭据重新发送其请求（步骤5）。B向C发送访问请求（步骤6）。C使用Access Accept或Access Reject检查凭据和回复（步骤7）。根据C的结果，B处理A的请求，或使用“（需要代理）授权”响应拒绝A的请求（步骤8）。
The attributes described in this document are sent in cleartext. Therefore, were a RADIUS client to accept secure connections (HTTPS or SIPS) from HTTP-style clients, this could result in information intentionally protected by HTTP-style clients being sent in the clear during RADIUS exchange.
本文档中描述的属性以明文形式发送。因此，如果RADIUS客户端接受来自HTTP样式客户端的安全连接（HTTPS或SIPS），这可能会导致在RADIUS交换期间以明文形式发送受HTTP样式客户端有意保护的信息。
On reception of an HTTP-style request message, the RADIUS client checks whether it is authorized to authenticate the request. Where an HTTP-style request traverses several proxies and each of the proxies requests to authenticate the HTTP-style client, the request at the HTTP-style server may contain multiple credential sets.
在接收到HTTP样式的请求消息时，RADIUS客户端将检查其是否被授权对请求进行身份验证。当HTTP样式请求遍历多个代理并且每个代理请求对HTTP样式客户端进行身份验证时，HTTP样式服务器上的请求可能包含多个凭据集。
The RADIUS client can use the 'realm' directive in HTTP to determine which credentials are applicable. Where none of the realms are of interest, the RADIUS client MUST behave as though no relevant credentials were sent. In all situations, the RADIUS client MUST send zero or exactly one credential to the RADIUS server. The RADIUS client MUST choose the credential of the (Proxy-)Authorization header if the realm directive matches its locally configured realm.
RADIUS客户端可以使用HTTP中的“realm”指令来确定哪些凭据是适用的。如果对任何领域都不感兴趣，RADIUS客户端的行为必须与未发送任何相关凭据一样。在所有情况下，RADIUS客户端必须向RADIUS服务器发送零个或正好一个凭据。如果realm指令与其本地配置的realm相匹配，RADIUS客户端必须选择（代理）授权头的凭据。
If a matching (Proxy-)Authorization header is present and contains HTTP Digest information, the RADIUS client checks the 'nonce' parameter.
如果存在匹配的（代理）授权标头并包含HTTP摘要信息，RADIUS客户端将检查“nonce”参数。
If the RADIUS client recognizes the nonce, it takes the header directives and puts them into a RADIUS Access-Request packet. It puts the 'response' directive into a Digest-Response attribute and the realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username, and opaque directives into the respective Digest-Realm, Digest-Nonce, Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce, Digest-Nonce-Count, Digest-Username, and Digest-Opaque attributes. The RADIUS client puts the request method into the Digest-Method attribute.
如果RADIUS客户端识别nonce，它将接收头指令并将它们放入RADIUS访问请求数据包中。它将“response”指令放入摘要响应属性，将realm、nonce、摘要uri、qop、algorithm、cnonce、nc、username和不透明指令放入相应的摘要领域、摘要nonce、摘要uri、摘要qop、摘要算法、摘要cnonce、摘要nonce Count、摘要username和摘要不透明属性。RADIUS客户端将请求方法放入摘要方法属性中。
Due to syntactic requirements, HTTP-style protocols have to escape with backslash all quote and backslash characters in contents of HTTP Digest directives. When translating directives into RADIUS attributes, the RADIUS client only removes the surrounding quotes where present. See Section 3 for an example.
由于语法要求，HTTP样式协议必须在HTTP摘要指令的内容中使用反斜杠all quote和反斜杠字符转义。在将指令转换为RADIUS属性时，RADIUS客户端仅删除存在的周围引号。有关示例，请参见第3节。
If the Quality of Protection (qop) directive's value is 'auth-int', the RADIUS client calculates H(entity-body) as described in [RFC2617], Section 3.2.1, and puts the result in a Digest-Entity-Body-Hash attribute.
如果保护质量（qop）指令的值为“auth int”，RADIUS客户端将按照[RFC2617]第3.2.1节中的说明计算H（实体体），并将结果放入摘要实体体哈希属性中。
The RADIUS client adds a Message-Authenticator attribute, defined in [RFC3579], and sends the Access-Request packet to the RADIUS server.
RADIUS客户端添加[RFC3579]中定义的消息验证器属性，并将访问请求数据包发送到RADIUS服务器。
The RADIUS server processes the packet and responds with an Access-Accept or an Access-Reject.
RADIUS服务器处理数据包并以访问接受或访问拒绝响应。
After having received an Access-Accept from the RADIUS server, the RADIUS client constructs an Authentication-Info header:
从RADIUS服务器接收访问接受后，RADIUS客户端将构造一个身份验证信息头：
o If the Access-Accept packet contains a Digest-Response-Auth attribute, the RADIUS client checks the Digest-Qop attribute:
o 如果访问接受数据包包含摘要响应身份验证属性，RADIUS客户端将检查摘要Qop属性：
* If the Digest-Qop attribute's value is 'auth' or not specified, the RADIUS client puts the Digest-Response-Auth attribute's content into the Authentication-Info header's 'rspauth' directive of the HTTP-style response.
* 如果摘要Qop属性的值为“auth”或未指定，RADIUS客户端会将摘要响应auth属性的内容放入HTTP样式响应的身份验证信息头的“rspauth”指令中。
* If the Digest-Qop attribute's value is 'auth-int', the RADIUS client ignores the Access-Accept packet and behaves as if it had received an Access-Reject packet (Digest-Response-Auth can't be correct as the RADIUS server does not know the contents of the HTTP-style response's body).
* 如果Digest Qop属性的值为“auth int”，RADIUS客户端将忽略访问接受数据包，并表现为接收到访问拒绝数据包（Digest Response auth不能正确，因为RADIUS服务器不知道HTTP样式响应正文的内容）。
o If the Access-Accept packet contains a Digest-HA1 attribute, the RADIUS client checks the 'qop' and 'algorithm' directives in the Authorization header of the HTTP-style request it wants to authorize:
o 如果Access Accept数据包包含Digest-HA1属性，RADIUS客户端将检查其要授权的HTTP样式请求的授权标头中的“qop”和“algorithm”指令：
* If the 'qop' directive is missing or its value is 'auth', the RADIUS client ignores the Digest-HA1 attribute. It does not include an Authentication-Info header in its HTTP-style response.
* 如果缺少'qop'指令或其值为'auth'，RADIUS客户端将忽略Digest-HA1属性。它的HTTP样式响应中不包含身份验证信息头。
* If the 'qop' directive's value is 'auth-int' and at least one of the following conditions is true, the RADIUS client calculates the contents of the HTTP-style response's 'rspauth' directive:
* 如果'qop'指令的值为'auth int'，且至少下列条件之一为真，RADIUS客户端将计算HTTP样式响应的'rspauth'指令的内容：
+ The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
+ 算法指令的值为“MD5 sess”或“AKAv1-MD5-sess”。
+ IP Security (IPsec) is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8).
+ IP安全（IPsec）配置为使用IPsec保护RADIUS客户端和RADIUS服务器之间的通信量（请参阅第8节）。
It creates the HTTP-style response message and calculates the hash of this message's body. It uses the result and the Digest-URI attribute's value of the corresponding Access-Request packet to perform the H(A2) calculation. It takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and Digest-Qop values of the corresponding Access-Request and the Digest-HA1 attribute's value to finish the computation of the 'rspauth' value.
它创建HTTP风格的响应消息并计算该消息正文的哈希值。它使用相应访问请求数据包的结果和摘要URI属性值来执行H（A2）计算。它采用相应访问请求的摘要Nonce、摘要Nonce Count、摘要CNonce和摘要Qop值以及摘要HA1属性的值来完成“rspauth”值的计算。
o If the Access-Accept packet contains neither a Digest-Response-Auth nor a Digest-HA1 attribute, the RADIUS client will not create an Authentication-Info header for its HTTP-style response.
o 如果Access Accept数据包既不包含摘要响应Auth也不包含摘要-HA1属性，RADIUS客户端将不会为其HTTP样式的响应创建身份验证信息头。
When the RADIUS server provides a Digest-Nextnonce attribute in the Access-Accept packet, the RADIUS client puts the contents of this attribute into a 'nextnonce' directive. Now it can send an HTTP-style response.
当RADIUS服务器在Access Accept数据包中提供摘要NextOnce属性时，RADIUS客户端将此属性的内容放入“NextOnce”指令中。现在它可以发送HTTP风格的响应。
If the RADIUS client did receive an HTTP-style request without a (Proxy-)Authorization header matching its locally configured realm value, it obtains a new nonce and sends an error response (401 or 407) containing a (Proxy-)Authenticate header.
如果RADIUS客户端确实接收到HTTP样式的请求，但没有与其本地配置的领域值匹配的（代理）授权标头，则它将获得一个新的nonce并发送一个包含（代理）身份验证标头的错误响应（401或407）。
If the RADIUS client receives an Access-Challenge packet in response to an Access-Request containing a Digest-Nonce attribute, the RADIUS server did not accept the nonce. If a Digest-Stale attribute is present in the Access-Challenge and has a value of 'true' (without surrounding quotes), the RADIUS client sends an error response (401 or 407) containing a WWW-/Proxy-Authenticate header with the directive 'stale' and the digest directives derived from the Digest-* attributes.
如果RADIUS客户端收到一个访问质询数据包以响应包含摘要Nonce属性的访问请求，则RADIUS服务器不接受该Nonce。如果访问质询中存在摘要Stale属性，且该属性的值为“true”（不带引号），RADIUS客户端将发送一个错误响应（401或407），其中包含一个WWW-/Proxy Authenticate标头，该标头具有指令“Stale”和从摘要-*属性派生的摘要指令。
If the RADIUS client receives an Access-Reject from the RADIUS server, it sends an error response to the HTTP-style request it has received. If the RADIUS client does not receive a response, it retransmits or fails over to another RADIUS server as described in [RFC2865].
如果RADIUS客户端从RADIUS服务器接收到访问拒绝，它将向其接收到的HTTP样式请求发送错误响应。如果RADIUS客户端没有收到响应，它将重新传输或故障转移到另一个RADIUS服务器，如[RFC2865]中所述。
The RADIUS client has two ways to obtain nonces: it has received one in a Digest-Nextnonce attribute of a previously received Access-Accept packet or it asks the RADIUS server for one. To do the latter, it sends an Access-Request containing a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute. It adds a Message-Authenticator (see [RFC3579]) attribute to the Access-Request packet. The RADIUS server chooses a nonce and responds with an Access-Challenge containing a Digest-Nonce attribute.
RADIUS客户端有两种获取nonce的方法：它在先前接收到的Access Accept数据包的Digest Nextnonce属性中接收到一个nonce，或者它向RADIUS服务器请求一个nonce。为了实现后者，它发送一个包含摘要方法和摘要URI属性但不包含摘要Nonce属性的访问请求。它将消息验证器（请参见[RFC3579]）属性添加到访问请求数据包中。RADIUS服务器选择一个nonce并使用包含摘要nonce属性的访问质询进行响应。
The RADIUS client constructs a (Proxy-)Authenticate header using the received Digest-Nonce and Digest-Realm attributes to fill the nonce and realm directives. The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-Domain, and Digest-Opaque attributes in the Access-Challenge carrying the nonce. If these attributes are present, the client MUST use them.
RADIUS客户端使用收到的摘要Nonce和摘要Realm属性构造（代理）身份验证标头，以填充Nonce和Realm指令。RADIUS服务器可以在带有nonce的访问质询中发送摘要Qop、摘要算法、摘要域和摘要不透明属性。如果存在这些属性，客户端必须使用它们。
If the RADIUS server receives an Access-Request packet with a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce attribute and sends it in an Access-Challenge packet to the RADIUS client. The RADIUS server MUST add Digest-Realm, Message-Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm and one or more Digest-Qop, and MAY add Digest-Domain or Digest-Opaque attributes to the Access-Challenge packet.
如果RADIUS服务器接收到一个带有摘要方法和摘要URI属性但没有摘要Nonce属性的访问请求数据包，它将选择一个Nonce。它将nonce放入摘要nonce属性中，并将其作为访问质询数据包发送给RADIUS客户端。RADIUS服务器必须添加摘要域、消息验证器（请参见[RFC3579]），应该添加摘要算法和一个或多个摘要Qop，并且可以向访问质询数据包添加摘要域或摘要不透明属性。
If the RADIUS server receives an Access-Request packet containing a Digest-Response attribute, it looks for the following attributes:
如果RADIUS服务器接收到包含摘要响应属性的访问请求数据包，它将查找以下属性：
Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, Digest-Algorithm, and Digest-Username. Depending on the content of Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body-Hash, Digest-CNonce, and Digest-AKA-Auts, too. See [RFC2617] and [RFC3310] for details. If the Digest-Algorithm attribute is missing, 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque attribute along with the nonce, the Access-Request MUST have a matching Digest-Opaque attribute.
摘要域、摘要Nonce、摘要方法、摘要URI、摘要Qop、摘要算法和摘要用户名。根据摘要算法和摘要Qop的内容，它还会查找摘要实体体哈希、摘要CNonce和摘要AKA AUT。详见[RFC2617]和[RFC3310]。如果缺少摘要算法属性，则假定为“MD5”。如果RADIUS服务器已随nonce一起发出摘要不透明属性，则访问请求必须具有匹配的摘要不透明属性。
If mandatory attributes are missing, it MUST respond with an Access-Reject packet.
如果缺少必需的属性，则必须使用访问拒绝数据包进行响应。
The RADIUS server removes '\' characters that escape quote and '\' characters from the text values it has received in the Digest-* attributes.
RADIUS服务器从摘要-*属性中接收的文本值中删除转义引号的“\”字符和“\”字符。
If the mandatory attributes are present, the RADIUS server MUST check if the RADIUS client is authorized to serve users of the realm mentioned in the Digest-Realm attribute. If the RADIUS client is not authorized, the RADIUS server MUST send an Access-Reject. The RADIUS server SHOULD log the event so as to notify the operator, and MAY take additional action such as sending an Access-Reject in response to all future requests from this client, until this behavior is reset by management action.
如果存在强制属性，RADIUS服务器必须检查RADIUS客户端是否有权为摘要领域属性中提到的领域的用户提供服务。如果RADIUS客户端未经授权，RADIUS服务器必须发送访问拒绝。RADIUS服务器应记录事件，以便通知操作员，并可采取其他措施，如发送访问拒绝，以响应来自该客户端的所有未来请求，直到管理措施重置此行为。
The RADIUS server determines the age of the nonce in Digest-Nonce by using an embedded time-stamp or by looking it up in a local table. The RADIUS server MUST check the integrity of the nonce if it embeds the time-stamp in the nonce. Section 2.2.2 describes how the server handles old nonces.
RADIUS服务器通过使用嵌入的时间戳或在本地表中查找来确定摘要nonce中nonce的时间。如果RADIUS服务器在nonce中嵌入时间戳，则必须检查nonce的完整性。第2.2.2节描述了服务器如何处理旧的nonce。
If the Access-Request message has passed the checks described above, the RADIUS server calculates the digest response as described in [RFC2617]. To look up the password, the RADIUS server uses the RADIUS User-Name attribute. The RADIUS server MUST check if the user identified by the User-Name attribute
如果访问请求消息已通过上述检查，RADIUS服务器将按照[RFC2617]中所述计算摘要响应。要查找密码，RADIUS服务器使用RADIUS用户名属性。RADIUS服务器必须检查用户名属性是否标识了用户
o is authorized to access the protection space and
o 有权进入保护空间和
o is authorized to use the URI included in the SIP-AOR attribute, if this attribute is present.
o 被授权使用SIP-AOR属性中包含的URI（如果该属性存在）。
If any of those checks fails, the RADIUS server MUST send an Access-Reject.
如果任何检查失败，RADIUS服务器必须发送访问拒绝。
Correlation between User-Name and SIP-AOR AVP values is required just to avoid that any user can register or misuse a SIP-AOR allocated to a different user.
需要用户名和SIP-AOR AVP值之间的关联，以避免任何用户可以注册或误用分配给不同用户的SIP-AOR。
All values required for the digest calculation are taken from the Digest attributes described in this document. If the calculated digest response equals the value received in the Digest-Response attribute, the authentication was successful.
摘要计算所需的所有值均取自本文档中描述的摘要属性。如果计算的摘要响应等于摘要响应属性中接收的值，则验证成功。
If the response values match, but the RADIUS server considers the nonce in the Digest-Nonce attribute as too old, it sends an Access-Challenge packet containing a new nonce and a Digest-Stale attribute with a value of 'true' (without surrounding quotes).
如果响应值匹配，但RADIUS服务器认为摘要nonce属性中的nonce太旧，则会发送一个访问质询数据包，其中包含一个新的nonce和一个值为“true”（不带引号）的摘要Stale属性。
If the response values don't match, the RADIUS server responds with an Access-Reject.
如果响应值不匹配，RADIUS服务器将以访问拒绝响应。
If the authentication was successful, the RADIUS server adds an attribute to the Access-Accept packet that can be used by the RADIUS client to construct an Authentication-Info header:
如果身份验证成功，RADIUS服务器将向Access Accept数据包添加一个属性，RADIUS客户端可以使用该属性来构造身份验证信息头：
o If the Digest-Qop attribute's value is 'auth' or unspecified, the RADIUS server SHOULD put a Digest-Response-Auth attribute into the Access-Accept packet.
o 如果摘要Qop属性的值为“auth”或未指定，RADIUS服务器应将摘要响应auth属性放入Access Accept数据包中。
o If the Digest-Qop attribute's value is 'auth-int' and at least one of the following conditions is true, the RADIUS server SHOULD put a Digest-HA1 attribute into the Access-Accept packet:
o 如果Digest Qop属性的值为“auth int”，并且至少满足以下条件之一，RADIUS服务器应将Digest-HA1属性放入Access Accept数据包中：
* The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
* 摘要算法属性的值为“MD5 sess”或“AKAv1-MD5-sess”。
* IPsec is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8).
* IPsec配置为使用IPsec保护RADIUS客户端和RADIUS服务器之间的通信量（请参阅第8节）。
In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be sent.
在所有其他情况下，不得发送摘要响应Auth或摘要-HA1。
RADIUS servers MAY construct a Digest-Nextnonce attribute and add it to the Access-Accept packet. This is useful to limit the lifetime of a nonce and to save a round-trip in future requests (see nextnonce discussion in [RFC2617], section 3.2.3). The RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) and sends the Access-Accept packet to the RADIUS client.
RADIUS服务器可以构造摘要NextOnce属性并将其添加到Access Accept数据包中。这有助于限制nonce的生存期，并在将来的请求中保存往返（请参阅[RFC2617]第3.2.3节中的下一次讨论）。RADIUS服务器添加消息验证器属性（请参见[RFC3579]），并将访问接受数据包发送到RADIUS客户端。
If the RADIUS server does not accept the nonce received in an Access-Request packet but authentication was successful, the RADIUS server MUST send an Access-Challenge packet containing a Digest-Stale attribute set to 'true' (without surrounding quotes). The RADIUS server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm, SHOULD add Digest-Algorithm and one or more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes to the Access-Challenge packet.
如果RADIUS服务器不接受访问请求数据包中接收到的nonce，但身份验证成功，则RADIUS服务器必须发送一个访问质询数据包，该数据包包含设置为“true”的摘要过时属性（不带引号）。RADIUS服务器必须添加消息验证器（请参见[RFC3579]）、摘要Nonce、摘要Realm，并应添加摘要算法和一个或多个摘要Qop，并可向访问质询数据包添加摘要域、摘要不透明属性。
If not stated otherwise, the attributes have the following format:
如果未另行说明，则属性具有以下格式：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Quote and backslash characters in Digest-* attributes representing HTTP-style directives with a quoted-string syntax are escaped. The surrounding quotes are removed. They are syntactical delimiters that are redundant in RADIUS. For example, the directive
摘要-*属性中的引号和反斜杠字符表示带有引号字符串语法的HTTP样式指令，将被转义。周围的引号将被删除。它们是在半径上冗余的语法分隔符。例如，指令
realm="the \"example\" value"
realm=“示例”值”
is represented as follows:
代表如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest-Realm | 23 | the \"example\" value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest-Realm | 23 | the \"example\" value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description If this attribute is present in an Access-Request message, a RADIUS server implementing this specification MUST treat the Access-Request as a request for Digest Authentication. When a RADIUS client receives a (Proxy-)Authorization header, it puts the request-digest value into a Digest-Response attribute. This attribute (which enables the user to prove possession of the password) MUST only be used in Access-Requests. Type 103 for Digest-Response. Length >= 3
说明如果访问请求消息中存在此属性，则实现此规范的RADIUS服务器必须将访问请求视为摘要身份验证请求。当RADIUS客户端收到（代理）授权头时，它将请求摘要值放入摘要响应属性中。此属性（允许用户证明拥有密码）只能在访问请求中使用。输入103作为摘要响应。长度>=3
Text When using HTTP Digest, the text field is 32 octets long and contains a hexadecimal representation of a 16-octet digest value as it was calculated by the authenticated client. Other digest algorithms MAY define different digest lengths. The text field MUST be copied from request-digest of digest-response ([RFC2617]) without surrounding quotes.
文本使用HTTP摘要时，文本字段的长度为32个八位字节，包含16个八位字节摘要值的十六进制表示形式，该值是由经过身份验证的客户端计算的。其他摘要算法可以定义不同的摘要长度。文本字段必须从摘要响应的请求摘要（[RFC2617]）中复制，不带引号。
Description This attribute describes a protection space component of the RADIUS server. HTTP-style protocols differ in their definition of the protection space. See [RFC2617], Section 1.2, for details. It MUST only be used in Access-Request and Access-Challenge packets. Type 104 for Digest-Realm Length >=3 Text In Access-Requests, the RADIUS client takes the value of the realm directive (realm-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server puts the expected realm value into this attribute.
描述此属性描述RADIUS服务器的保护空间组件。HTTP风格的协议在保护空间的定义上有所不同。详见[RFC2617]，第1.2节。它只能在访问请求和访问质询数据包中使用。在Access请求中键入104表示摘要领域长度>=3文本，RADIUS客户机获取领域指令的值（领域值根据[RFC2617]），而不使用它想要验证的HTTP样式请求的引号。在访问质询数据包中，RADIUS服务器将预期的领域值放入此属性中。
Description
描述
This attribute holds a nonce to be used in the HTTP Digest calculation. If the Access-Request had a Digest-Method and a Digest-URI but no Digest-Nonce attribute, the RADIUS server MUST put a Digest-Nonce attribute into its Access-Challenge packet. This attribute MUST only be used in Access-Request and Access-Challenge packets. Type 105 for Digest-Nonce Length >=3 Text In Access-Requests, the RADIUS client takes the value of the nonce directive (nonce-value in [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the attribute contains the nonce selected by the RADIUS server.
此属性保存要在HTTP摘要计算中使用的nonce。如果访问请求具有摘要方法和摘要URI，但没有摘要Nonce属性，则RADIUS服务器必须将摘要Nonce属性放入其访问质询数据包中。此属性只能在访问请求和访问质询数据包中使用。在Access请求中键入105表示摘要Nonce Length>=3文本，RADIUS客户机获取Nonce指令的值（在[RFC2617]中为Nonce值），而不使用它要验证的HTTP样式请求中的引号。在访问质询数据包中，该属性包含RADIUS服务器选择的nonce。
Description This attribute enables the RADIUS server to prove possession of the password. If the previously received Digest-Qop attribute was 'auth-int' (without surrounding quotes), the RADIUS server MUST send a Digest-HA1 attribute instead of a Digest-Response-Auth attribute. The Digest-Response-Auth attribute MUST only be used in Access-Accept packets. The RADIUS client puts the attribute value without surrounding quotes into the rspauth directive of the Authentication-Info header. Type 106 for Digest-Response-Auth. Length >= 3 Text The RADIUS server calculates a digest according to section 3.2.3 of [RFC2617] and copies the result into this attribute. Digest algorithms other than the one defined in [RFC2617] MAY define digest lengths other than 32.
说明此属性使RADIUS服务器能够证明拥有密码。如果以前收到的摘要Qop属性为“auth int”（不带引号），RADIUS服务器必须发送摘要HA1属性，而不是摘要响应auth属性。摘要响应身份验证属性只能在Access Accept数据包中使用。RADIUS客户端将不带引号的属性值放入Authentication Info标头的rspauth指令中。为摘要响应身份验证键入106。长度>=3文本RADIUS服务器根据[RFC2617]第3.2.3节计算摘要，并将结果复制到此属性中。[RFC2617]中定义的摘要算法以外的摘要算法可以定义32以外的摘要长度。
This attribute holds a nonce to be used in the HTTP Digest calculation.
此属性保存要在HTTP摘要计算中使用的nonce。
Description
描述
The RADIUS server MAY put a Digest-Nextnonce attribute into an Access-Accept packet. If this attribute is present, the RADIUS client MUST put the contents of this attribute into the nextnonce directive of an Authentication-Info header in its HTTP-style response. This attribute MUST only be used in Access-Accept packets. Type 107 for Digest-Nextnonce Length >=3 Text It is recommended that this text be base64 or hexadecimal data.
RADIUS服务器可以将摘要NextOnce属性放入Access Accept数据包中。如果存在此属性，RADIUS客户端必须在其HTTP样式响应中将此属性的内容放入身份验证信息头的NEXTNOCE指令中。此属性只能在Access-Accept数据包中使用。键入107表示摘要下一次长度>=3文本建议此文本为base64或十六进制数据。
Description This attribute holds the method value to be used in the HTTP Digest calculation. This attribute MUST only be used in Access-Request packets.
Description此属性保存要在HTTP摘要计算中使用的方法值。此属性只能在访问请求数据包中使用。
Type 108 for Digest-Method Length >=3 Text In Access-Requests, the RADIUS client takes the value of the request method from the HTTP-style request it wants to authenticate.
在Access请求中键入108表示摘要方法长度>=3文本，RADIUS客户端从它要验证的HTTP样式请求中获取请求方法的值。
Description This attribute is used to transport the contents of the digest-uri directive or the URI of the HTTP-style request. It MUST only be used in Access-Request packets. Type 109 for Digest-URI Length >=3 Text If the HTTP-style request has an Authorization header, the RADIUS client puts the value of the "uri" directive found in the HTTP-style request Authorization header (known as "digest-uri-value" in section 3.2.2 of [RFC2617]) without surrounding quotes into this attribute. If there is no Authorization header, the RADIUS client takes the value of the request URI from the HTTP-style request it wants to authenticate.
描述此属性用于传输摘要uri指令的内容或HTTP样式请求的uri。它只能在访问请求数据包中使用。键入109表示摘要URI长度>=3文本如果HTTP样式请求具有授权标头，RADIUS客户端将在HTTP样式请求授权标头中找到的“URI”指令的值（在[RFC2617]的第3.2.2节中称为“摘要URI值”）放入该属性，而不加引号。如果没有授权标头，RADIUS客户机将从它要验证的HTTP样式请求中获取请求URI的值。
Description This attribute holds the Quality of Protection parameter that influences the HTTP Digest calculation. This attribute MUST only be used in Access-Request and Access-Challenge packets. A RADIUS client SHOULD insert one of the Digest-Qop attributes it has received in a previous Access-Challenge packet. RADIUS servers SHOULD insert at least one Digest-Qop attribute in an Access-Challenge packet. Digest-Qop is optional in order to preserve backward compatibility with a minimal implementation of [RFC2069]. Type 110 for Digest-Qop Length >=3 Text In Access-Requests, the RADIUS client takes the value of the qop directive (qop-value as described in [RFC2617]) from the
说明此属性包含影响HTTP摘要计算的保护质量参数。此属性只能在访问请求和访问质询数据包中使用。RADIUS客户端应插入它在先前访问质询数据包中接收到的摘要Qop属性之一。RADIUS服务器应在访问质询数据包中至少插入一个摘要Qop属性。摘要Qop是可选的，以保持与[RFC2069]的最小实现的向后兼容性。在访问请求中键入110，对于摘要Qop长度>=3文本，RADIUS客户端从
HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server puts a desired qop-value into this attribute. If the RADIUS server supports more than one "quality of protection" value, it puts each qop-value into a separate Digest-Qop attribute.
它要进行身份验证的HTTP样式请求。在访问质询数据包中，RADIUS服务器将所需的qop值放入该属性。如果RADIUS服务器支持多个“保护质量”值，则会将每个qop值放入单独的摘要qop属性中。
Description This attribute holds the algorithm parameter that influences the HTTP Digest calculation. It MUST only be used in Access-Request and Access-Challenge packets. If this attribute is missing, MD5 is assumed. Type 111 for Digest-Algorithm Length >=3 Text In Access-Requests, the RADIUS client takes the value of the algorithm directive (as described in [RFC2617], section 3.2.1) from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server SHOULD put the desired algorithm into this attribute.
说明此属性保存影响HTTP摘要计算的算法参数。它只能在访问请求和访问质询数据包中使用。如果缺少此属性，则假定为MD5。输入111，对于Access请求中的摘要算法长度>=3文本，RADIUS客户端从其要验证的HTTP样式请求中获取算法指令的值（如[RFC2617]第3.2.1节所述）。在访问质询数据包中，RADIUS服务器应将所需的算法放入该属性中。
Description When using the qop-level 'auth-int', a hash of the HTTP-style message body's contents is required for digest calculation. Instead of sending the complete body of the message, only its hash value is sent. This hash value can be used directly in the digest calculation.
说明使用qop级别“auth int”时，摘要计算需要HTTP样式消息体内容的哈希。只发送其哈希值，而不是发送消息的完整正文。此哈希值可直接用于摘要计算。
The clarifications described in section 22.4 of [RFC3261] about the hash of empty entity bodies apply to the Digest-Entity-Body-Hash attribute. This attribute MUST only be sent in Access-Request packets. Type 112 for Digest-Entity-Body-Hash Length >=3 Text The attribute holds the hexadecimal representation of H(entity-body). This hash is required by certain authentication mechanisms, such as HTTP Digest with quality of protection set to "auth-int". RADIUS clients MUST use this attribute to transport the hash of the entity body when HTTP Digest is the authentication mechanism and the RADIUS server
[RFC3261]第22.4节中描述的关于空实体散列的澄清适用于摘要实体散列属性。此属性只能在访问请求数据包中发送。为摘要实体体哈希长度>=3文本键入112该属性保存H（实体体）的十六进制表示形式。某些身份验证机制需要此哈希，例如保护质量设置为“auth int”的HTTP摘要。当HTTP摘要是身份验证机制和RADIUS服务器时，RADIUS客户端必须使用此属性来传输实体体的哈希
requires that the integrity of the entity body (e.g., qop parameter set to "auth-int") be verified. Extensions to this document may define support for authentication mechanisms other than HTTP Digest.
要求验证实体主体的完整性（例如，qop参数设置为“auth int”）。本文档的扩展可以定义对HTTP摘要以外的身份验证机制的支持。
Description This attribute holds the client nonce parameter that is used in the HTTP Digest calculation. It MUST only be used in Access-Request packets. Type 113 for Digest-CNonce Length >=3 Text This attribute includes the value of the cnonce-value [RFC2617] without surrounding quotes, taken from the HTTP-style request.
说明此属性保存HTTP摘要计算中使用的客户端nonce参数。它只能在访问请求数据包中使用。为摘要CNonce长度>=3文本键入113此属性包括CNonce值[RFC2617]的值，不带引号，取自HTTP样式请求。
Description This attribute includes the nonce count parameter that is used to detect replay attacks. The attribute MUST only be used in Access-Request packets.
说明此属性包括用于检测重播攻击的nonce count参数。该属性只能在访问请求数据包中使用。
Type 114 for Digest-Nonce-Count Length 10 Text In Access-Requests, the RADIUS client takes the value of the nc directive (nc-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate.
对于Access请求中的摘要Nonce Count Length 10文本，键入114，RADIUS客户机获取nc指令的值（根据[RFC2617]的nc值），而不使用它要验证的HTTP样式请求中的引号。
Description This attribute holds the user name used in the HTTP Digest calculation. The RADIUS server MUST use this attribute only for the purposes of calculating the digest. In order to determine the appropriate user credentials, the RADIUS server MUST use the User-Name (1) attribute, and MUST NOT use the Digest-Username attribute. This attribute MUST only be used in Access-Request packets. Type 115 for Digest-Username
说明此属性保存HTTP摘要计算中使用的用户名。RADIUS服务器必须仅在计算摘要时使用此属性。为了确定适当的用户凭据，RADIUS服务器必须使用用户名（1）属性，而不能使用摘要用户名属性。此属性只能在访问请求数据包中使用。键入115作为摘要用户名
Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the username directive (username-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate.
长度>=3文本在访问请求中，RADIUS客户机获取username指令的值（根据[RFC2617]的username值），而不使用它想要验证的HTTP样式请求的引号。
Description This attribute holds the opaque parameter that is passed to the HTTP-style client. The HTTP-style client will pass this value back to the server (i.e., the RADIUS client) without modification. This attribute MUST only be used in Access-Request and Access-Challenge packets. Type 116 for Digest-Opaque Length >=3 Text In Access-Requests, the RADIUS client takes the value of the opaque directive (opaque-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate and puts it into this attribute. In Access-Challenge packets, the RADIUS server MAY include this attribute.
Description此属性保存传递给HTTP样式客户端的不透明参数。HTTP样式的客户端将不经修改地将此值传递回服务器（即RADIUS客户端）。此属性只能在访问请求和访问质询数据包中使用。输入116对于Access请求中的摘要不透明长度>=3文本，RADIUS客户端从它要验证的HTTP样式请求中获取不透明指令的值（根据[RFC2617]的不透明值），而不使用引号，并将其放入此属性中。在访问质询数据包中，RADIUS服务器可能包含此属性。
Description This attribute is a placeholder for future extensions and corresponds to the "auth-param" parameter defined in section 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism whereby the RADIUS client and RADIUS server can exchange auth-param extension parameters contained within Digest headers that are not understood by the RADIUS client and for which there are no corresponding stand-alone attributes.
说明该属性是未来扩展的占位符，对应于[RFC2617]第3.2.1节中定义的“auth param”参数。摘要Auth Param是一种机制，RADIUS客户端和RADIUS服务器可以通过该机制交换摘要头中包含的Auth Param扩展参数，这些参数RADIUS客户端无法理解，并且没有相应的独立属性。
Unlike the previously listed Digest-* attributes, the Digest-Auth-Param contains not only the value but also the parameter name, since the parameter name is unknown to the RADIUS client. If the Digest header contains several unknown parameters, then the RADIUS implementation MUST repeat this attribute and each instance MUST contain one different unknown Digest parameter/value combination. This attribute MUST ONLY be used in Access-Request, Access-Challenge, or Access-Accept packets.
与前面列出的Digest-*属性不同，Digest Auth Param不仅包含值，还包含参数名，因为RADIUS客户端不知道参数名。如果摘要标头包含多个未知参数，则RADIUS实现必须重复此属性，并且每个实例必须包含一个不同的未知摘要参数/值组合。此属性只能在访问请求、访问质询或访问接受数据包中使用。
Type 117 for Digest-Auth-Param Length >=3 Text The text consists of the whole parameter, including its name and the equal sign ('=') and quotes.
为摘要Auth Param Length>=3文本键入117文本由整个参数组成，包括其名称、等号（'='）和引号。
Description This attribute holds the auts parameter that is used in the Digest AKA ([RFC3310]) calculation. It is only used if the algorithm of the digest-response denotes a version of AKA Digest [RFC3310]. This attribute MUST only be used in Access-Request packets. Type 118 for Digest-AKA-Auts Length >=3 Text In Access-Requests, the RADIUS client takes the value of the auts directive (auts-param according to section 3.4 of [RFC3310]) without surrounding quotes from the HTTP-style request it wants to authenticate.
说明此属性保存摘要AKA（[RFC3310]）计算中使用的auts参数。仅当摘要响应的算法表示AKA摘要[RFC3310]的版本时，才使用它。此属性只能在访问请求数据包中使用。在Access请求中键入118表示摘要AKA Auts Length>=3文本，RADIUS客户机获取Auts指令的值（根据[RFC3310]第3.4节的Auts参数），而不使用其想要验证的HTTP样式请求的引号。
Description When a RADIUS client has asked for a nonce, the RADIUS server MAY send one or more Digest-Domain attributes in its Access-Challenge packet. The RADIUS client puts them into the quoted, space-separated list of URIs of the 'domain' directive of a WWW-Authenticate header. Together with Digest-Realm, the URIs in the list define the protection space (see [RFC2617], section 3.2.1) for some HTTP-style protocols. This attribute MUST only be used in Access-Challenge packets. Type 119 for Digest-Domain Length 3 Text This attribute consists of a single URI that defines a protection space component.
说明当RADIUS客户端请求一个nonce时，RADIUS服务器可以在其访问质询数据包中发送一个或多个摘要域属性。RADIUS客户机将它们放入WWW Authenticate头的“domain”指令的URI的引用、空格分隔列表中。列表中的URI与摘要域一起定义了某些HTTP样式协议的保护空间（请参见[RFC2617]，第3.2.1节）。此属性只能在访问质询数据包中使用。为摘要域长度3文本键入119此属性由定义保护空间组件的单个URI组成。
Description This attribute is sent by a RADIUS server in order to notify the RADIUS client whether it has accepted a nonce. If the nonce presented by the RADIUS client was stale, the value is 'true' and is 'false' otherwise. The RADIUS client puts the content of this attribute into a 'stale' directive of the WWW-Authenticate header in the HTTP-style response to the request it wants to authenticate. The attribute MUST only be used in Access-Challenge packets. Type 120 for Digest-Stale Length 3 Text The attribute has either the value 'true' or 'false' (both values without surrounding quotes).
说明此属性由RADIUS服务器发送，以通知RADIUS客户端是否已接受nonce。如果RADIUS客户端提供的nonce已过时，则该值为“true”，否则为“false”。RADIUS客户端将此属性的内容放入它想要验证的请求的HTTP样式响应中WWW Authenticate头的“stale”指令中。该属性只能在访问质询数据包中使用。为摘要过时长度3文本键入120该属性的值为“true”或“false”（两个值均不带引号）。
Description This attribute is used to allow the generation of an Authentication-Info header, even if the HTTP-style response's body is required for the calculation of the rspauth value. It SHOULD be used in Access-Accept packets if the required quality of protection ('qop') is 'auth-int'.
Description此属性用于允许生成身份验证信息头，即使计算rspauth值需要HTTP样式响应的主体。如果所需的保护质量（“qop”）为“auth int”，则应在访问接受数据包中使用。
This attribute MUST NOT be sent if the qop parameter was not specified or has a value of 'auth' (in this case, use Digest-Response-Auth instead).
如果未指定qop参数或其值为“auth”（在本例中，使用摘要响应auth），则不得发送此属性。
The Digest-HA1 attribute MUST only be sent by the RADIUS server or processed by the RADIUS client if at least one of the following conditions is true:
如果至少满足以下条件之一，则Digest-HA1属性只能由RADIUS服务器发送或由RADIUS客户端处理：
+ The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
+ 摘要算法属性的值为“MD5 sess”或“AKAv1-MD5-sess”。
+ IPsec is configured to protect traffic between RADIUS client and RADIUS server with IPsec (see Section 8).
+ IPsec配置为使用IPsec保护RADIUS客户端和RADIUS服务器之间的通信量（请参阅第8节）。
This attribute MUST only be used in Access-Accept packets. Type 121 for Digest-HA1 Length >= 3
此属性只能在Access-Accept数据包中使用。Digest-HA1长度>=3的类型121
Text This attribute contains the hexadecimal representation of H(A1) as described in [RFC2617], sections 3.1.3, 3.2.1, and 3.2.2.2.
文本此属性包含[RFC2617]第3.1.3节、第3.2.1节和第3.2.2.2节中所述的H（A1）的十六进制表示形式。
Description This attribute is used for the authorization of SIP messages. The SIP-AOR attribute identifies the URI, the use of which must be authenticated and authorized. The RADIUS server uses this attribute to authorize the processing of the SIP request. The SIP-AOR can be derived from, for example, the To header field in a SIP REGISTER request (user under registration), or the From header field in other SIP requests. However, the exact mapping of this attribute to SIP can change due to new developments in the protocol. This attribute MUST only be used when the RADIUS client wants to authorize SIP users and MUST only be used in Access-Request packets. Type 122 for SIP-AOR Length >=3 Text The syntax of this attribute corresponds either to a SIP URI (with the format defined in [RFC3261] or a tel URI (with the format defined in [RFC3966]).
说明此属性用于SIP消息的授权。SIP-AOR属性标识URI，必须对其使用进行身份验证和授权。RADIUS服务器使用此属性授权SIP请求的处理。例如，SIP-AOR可以从SIP注册请求（注册中的用户）中的To报头字段或其他SIP请求中的from报头字段派生。但是，由于协议的新发展，该属性到SIP的精确映射可能会发生变化。此属性只能在RADIUS客户端希望授权SIP用户时使用，并且只能在访问请求数据包中使用。SIP-AOR长度>=3文本的类型122此属性的语法对应于SIP URI（使用[RFC3261]中定义的格式）或tel URI（使用[RFC3966]中定义的格式）。
The SIP-AOR attribute holds the complete URI, including parameters and other parts. It is up to the RADIUS server what components of the URI are regarded in the authorization decision.
SIP-AOR属性保存完整的URI，包括参数和其他部分。由RADIUS服务器决定在授权决策中考虑URI的哪些组件。
This document defines support for Digest Authentication in RADIUS. A companion document "Diameter Session Initiation Protocol (SIP) Application" [SIP-APP] defines support for Digest Authentication in Diameter, and addresses compatibility issues between RADIUS and Diameter.
本文档定义了对RADIUS中摘要身份验证的支持。附带文档“Diameter会话启动协议（SIP）应用程序”[SIP-APP]定义了对Diameter中摘要身份验证的支持，并解决了RADIUS和Diameter之间的兼容性问题。
The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
下表提供了在哪些类型的数据包中可以找到哪些属性以及数量的指南。
+-----+--------+--------+-----------+-----+-------------------------+
| Req | Accept | Reject | Challenge | # | Attribute |
+-----+--------+--------+-----------+-----+-------------------------+
| 1 | 0 | 0 | 0 | 1 | User-Name |
| 1 | 1 | 1 | 1 | 80 | Message-Authenticator |
| 0-1 | 0 | 0 | 0 | 103 | Digest-Response |
| 0-1 | 0 | 0 | 1 | 104 | Digest-Realm |
| 0-1 | 0 | 0 | 1 | 105 | Digest-Nonce |
| 0 | 0-1 | 0 | 0 | 106 | Digest-Response-Auth |
| | | | | | (see Note 1, 2) |
| 0 | 0-1 | 0 | 0 | 107 | Digest-Nextnonce |
| 0-1 | 0 | 0 | 0 | 108 | Digest-Method |
| 0-1 | 0 | 0 | 0 | 109 | Digest-URI |
| 0-1 | 0 | 0 | 0+ | 110 | Digest-Qop |
| 0-1 | 0 | 0 | 0-1 | 111 | Digest-Algorithm (see |
| | | | | | Note 3) |
| 0-1 | 0 | 0 | 0 | 112 | Digest-Entity-Body-Hash |
| 0-1 | 0 | 0 | 0 | 113 | Digest-CNonce |
| 0-1 | 0 | 0 | 0 | 114 | Digest-Nonce-Count |
| 0-1 | 0 | 0 | 0 | 115 | Digest-Username |
| 0-1 | 0 | 0 | 0-1 | 116 | Digest-Opaque |
| 0+ | 0+ | 0 | 0+ | 117 | Digest-Auth-Param |
| 0-1 | 0 | 0 | 0 | 118 | Digest-AKA-Auts |
| 0 | 0 | 0 | 0+ | 119 | Digest-Domain |
| 0 | 0 | 0 | 0-1 | 120 | Digest-Stale |
| 0 | 0-1 | 0 | 0 | 121 | Digest-HA1 (see Note 1, |
| | | | | | 2) |
| 0-1 | 0 | 0 | 0 | 122 | SIP-AOR |
+-----+--------+--------+-----------+-----+-------------------------+
+-----+--------+--------+-----------+-----+-------------------------+
| Req | Accept | Reject | Challenge | # | Attribute |
+-----+--------+--------+-----------+-----+-------------------------+
| 1 | 0 | 0 | 0 | 1 | User-Name |
| 1 | 1 | 1 | 1 | 80 | Message-Authenticator |
| 0-1 | 0 | 0 | 0 | 103 | Digest-Response |
| 0-1 | 0 | 0 | 1 | 104 | Digest-Realm |
| 0-1 | 0 | 0 | 1 | 105 | Digest-Nonce |
| 0 | 0-1 | 0 | 0 | 106 | Digest-Response-Auth |
| | | | | | (see Note 1, 2) |
| 0 | 0-1 | 0 | 0 | 107 | Digest-Nextnonce |
| 0-1 | 0 | 0 | 0 | 108 | Digest-Method |
| 0-1 | 0 | 0 | 0 | 109 | Digest-URI |
| 0-1 | 0 | 0 | 0+ | 110 | Digest-Qop |
| 0-1 | 0 | 0 | 0-1 | 111 | Digest-Algorithm (see |
| | | | | | Note 3) |
| 0-1 | 0 | 0 | 0 | 112 | Digest-Entity-Body-Hash |
| 0-1 | 0 | 0 | 0 | 113 | Digest-CNonce |
| 0-1 | 0 | 0 | 0 | 114 | Digest-Nonce-Count |
| 0-1 | 0 | 0 | 0 | 115 | Digest-Username |
| 0-1 | 0 | 0 | 0-1 | 116 | Digest-Opaque |
| 0+ | 0+ | 0 | 0+ | 117 | Digest-Auth-Param |
| 0-1 | 0 | 0 | 0 | 118 | Digest-AKA-Auts |
| 0 | 0 | 0 | 0+ | 119 | Digest-Domain |
| 0 | 0 | 0 | 0-1 | 120 | Digest-Stale |
| 0 | 0-1 | 0 | 0 | 121 | Digest-HA1 (see Note 1, |
| | | | | | 2) |
| 0-1 | 0 | 0 | 0 | 122 | SIP-AOR |
+-----+--------+--------+-----------+-----+-------------------------+
Table 1
表1
[Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if Digest-Qop is 'auth-int'.
[注1]如果摘要Qop为“Auth int”，则必须使用摘要HA1而不是摘要响应验证。
[Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if Digest-Qop is 'auth'.
[注2]如果摘要Qop为“Auth”，则必须使用摘要响应Auth而不是Digest-HA1。
[Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.
[注3]如果缺少摘要算法，则假定为“MD5”。
This is an example selected from the traffic between a softphone (A), a Proxy Server (B), and an example.com RADIUS server (C). The communication between the Proxy Server and a SIP Public Switched Telephone Network (PSTN) gateway is omitted for brevity. The SIP messages are not shown completely.
这是从软电话（a）、代理服务器（B）和example.com RADIUS服务器（C）之间的流量中选择的示例。为了简洁起见，省略了代理服务器和SIP公共交换电话网（PSTN）网关之间的通信。SIP消息未完全显示。
A->B
A->B
INVITE sip:97226491335@example.com SIP/2.0
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
INVITE sip:97226491335@example.com SIP/2.0
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
B->A
B->A
SIP/2.0 100 Trying
SIP/2.0 100
B->C
B->C
Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 (192.0.2.38) NAS-Port-Type = 5 (Virtual) User-Name = 12345678 Digest-Method = INVITE Digest-URI = sip:97226491335@example.com Message-Authenticator = 08 af 7e 01 b6 8d 74 c3 a4 3c 33 e1 56 2a 80 43
代码=1（访问请求）属性：NAS IP地址=C002 26（192.0.2.38）NAS端口类型=5（虚拟）用户名=12345678摘要方法=邀请摘要URI=sip:97226491335@example.com消息验证器=08 af 7e 01 b6 8d 74 c3 a4 3c 33 e1 56 2a 80 43
C->B
C->B
Code = 11 (Access-Challenge) Attributes: Digest-Nonce = 3bada1a0 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
代码=11（访问质询）属性：摘要Nonce=3bada1a0摘要Realm=example.com摘要Qop=auth摘要算法=MD5消息验证器=f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
B->A
B->A
SIP/2.0 407 Proxy Authentication Required
Proxy-Authenticate: Digest realm="example.com"
,nonce="3bada1a0",qop=auth,algorithm=MD5
Content-Length: 0
SIP/2.0 407 Proxy Authentication Required
Proxy-Authenticate: Digest realm="example.com"
,nonce="3bada1a0",qop=auth,algorithm=MD5
Content-Length: 0
A->B
A->B
ACK sip:97226491335@example.com SIP/2.0
ACK sip:97226491335@example.com SIP/2.0
A->B
A->B
INVITE sip:97226491335@example.com SIP/2.0
Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
,realm="example.com"
,response="f3ce87e6984557cd0fecc26f3c5e97a4"
,uri="sip:97226491335@example.com",username="12345678"
,qop=auth,algorithm=MD5
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
INVITE sip:97226491335@example.com SIP/2.0
Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
,realm="example.com"
,response="f3ce87e6984557cd0fecc26f3c5e97a4"
,uri="sip:97226491335@example.com",username="12345678"
,qop=auth,algorithm=MD5
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
B->C
B->C
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678
Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4
Digest-Realm = example.com
Digest-Nonce = 3bada1a0
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Digest-Qop = auth
Digest-Algorithm = md5
Digest-Username = 12345678
SIP-AOR = sip:12345678@example.com
Message-Authenticator =
ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678
Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4
Digest-Realm = example.com
Digest-Nonce = 3bada1a0
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Digest-Qop = auth
Digest-Algorithm = md5
Digest-Username = 12345678
SIP-AOR = sip:12345678@example.com
Message-Authenticator =
ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff
C->B
C->B
Code = 2 (Access-Accept) Attributes: Digest-Response-Auth = 6303c41b0e2c3e524e413cafe8cce954 Message-Authenticator = 75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1
代码=2（访问接受）属性：摘要响应身份验证=6303c41b0e2c3e524e413cafe8cce954消息验证器=75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1
B->A
B->A
SIP/2.0 180 Ringing
SIP/2.0 180振铃
B->A
B->A
SIP/2.0 200 OK
SIP/2.0 200正常
A->B
A->B
ACK sip:97226491335@example.com SIP/2.0
ACK sip:97226491335@example.com SIP/2.0
A second example shows the traffic between a web browser (A), web server (B), and a RADIUS server (C).
第二个示例显示了web浏览器（A）、web服务器（B）和RADIUS服务器（C）之间的通信量。
A->B
A->B
GET /index.html HTTP/1.1
GET/index.html HTTP/1.1
B->C
B->C
Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 (192.0.2.38) NAS-Port-Type = 5 (Virtual) Digest-Method = GET Digest-URI = /index.html Message-Authenticator = 34 a6 26 46 f3 81 f9 b4 97 c0 dd 9d 11 8f ca c7
代码=1（访问请求）属性：NAS IP地址=C002 26（192.0.2.38）NAS端口类型=5（虚拟）摘要方法=获取摘要URI=/index.html消息验证器=34 a6 26 46 f3 81 f9 b4 97 c0 dd 9d 11 8f ca c7
C->B
C->B
Code = 11 (Access-Challenge) Attributes: Digest-Nonce = a3086ac8 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
代码=11（访问质询）属性：摘要Nonce=a3086ac8摘要Realm=example.com摘要Qop=auth摘要算法=MD5消息验证器=f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
B->A
B->A
HTTP/1.1 401 Authentication Required
WWW-Authenticate: Digest realm="example.com",
nonce="a3086ac8",qop=auth,algorithm=MD5
Content-Length: 0
HTTP/1.1 401 Authentication Required
WWW-Authenticate: Digest realm="example.com",
nonce="a3086ac8",qop=auth,algorithm=MD5
Content-Length: 0
A->B
A->B
GET /index.html HTTP/1.1
Authorization: Digest algorithm=MD5,nonce="a3086ac8"
,realm="example.com"
,response="f052b68058b2987aba493857ae1ab002"
,uri="/index.html",username="12345678"
,qop=auth,algorithm=MD5
GET /index.html HTTP/1.1
Authorization: Digest algorithm=MD5,nonce="a3086ac8"
,realm="example.com"
,response="f052b68058b2987aba493857ae1ab002"
,uri="/index.html",username="12345678"
,qop=auth,algorithm=MD5
B->C
B->C
Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 (192.0.2.38) NAS-Port-Type = 5 (Virtual) User-Name = 12345678 Digest-Response = f052b68058b2987aba493857ae1ab002 Digest-Realm = example.com Digest-Nonce = a3086ac8 Digest-Method = GET Digest-URI = /index.html Digest-Username = 12345678 Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b
代码=1（访问请求）属性：NAS IP地址=C002 26（192.0.2.38）NAS端口类型=5（虚拟）User Name=12345678 Digest Response=f052b68058b2987aba493857ae1ab002 Digest Realm=example.com Digest Nonce=a3086ac8 Digest Method=GET Digest URI=/index.html Digest Username=12345678 Digest Qop=auth Digest Algorithm=MD5 Message Authenticator=06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b
C->B
C->B
Code = 2 (Access-Accept) Attributes: Digest-Response-Auth = e644aa513effbfe1caff67103ff6433c Message-Authenticator = 7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7
代码=2（访问接受）属性：摘要响应身份验证=E6444AA513EFFBFE1CAFF67103FF6433C消息身份验证程序=7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7
B->A
B->A
HTTP/1.1 200 OK ...
HTTP/1.1200OK。。。
<html> ...
<html>。。。
This document serves as an IANA registration request for a number of values from the RADIUS attribute type number space. The IANA has assigned the following:
本文档用作RADIUS属性类型编号空间中许多值的IANA注册请求。IANA分配了以下各项：
+-------------------------+------------------------+
| placeholder | value assigned by IANA |
+-------------------------+------------------------+
| Digest-Response | 103 |
| Digest-Realm | 104 |
| Digest-Nonce | 105 |
| Digest-Nextnonce | 106 |
| Digest-Response-Auth | 107 |
| Digest-Method | 108 |
| Digest-URI | 109 |
| Digest-Qop | 110 |
| Digest-Algorithm | 111 |
| Digest-Entity-Body-Hash | 112 |
| Digest-CNonce | 113 |
| Digest-Nonce-Count | 114 |
| Digest-Username | 115 |
| Digest-Opaque | 116 |
| Digest-Auth-Param | 117 |
| Digest-AKA-Auts | 118 |
| Digest-Domain | 119 |
| Digest-Stale | 120 |
| Digest-HA1 | 121 |
| SIP-AOR | 122 |
+-------------------------+------------------------+
+-------------------------+------------------------+
| placeholder | value assigned by IANA |
+-------------------------+------------------------+
| Digest-Response | 103 |
| Digest-Realm | 104 |
| Digest-Nonce | 105 |
| Digest-Nextnonce | 106 |
| Digest-Response-Auth | 107 |
| Digest-Method | 108 |
| Digest-URI | 109 |
| Digest-Qop | 110 |
| Digest-Algorithm | 111 |
| Digest-Entity-Body-Hash | 112 |
| Digest-CNonce | 113 |
| Digest-Nonce-Count | 114 |
| Digest-Username | 115 |
| Digest-Opaque | 116 |
| Digest-Auth-Param | 117 |
| Digest-AKA-Auts | 118 |
| Digest-Domain | 119 |
| Digest-Stale | 120 |
| Digest-HA1 | 121 |
| SIP-AOR | 122 |
+-------------------------+------------------------+
Table 2
表2
The RADIUS extensions described in this document enable RADIUS to transport the data that is required to perform a digest calculation. As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see [RFC2617], section 4) in addition to RADIUS security vulnerabilities described in [RFC2865], section 8, and [RFC3579], section 4.
本文档中描述的RADIUS扩展使RADIUS能够传输执行摘要计算所需的数据。因此，除了[RFC2865]第8节和[RFC3579]第4节中描述的RADIUS安全漏洞外，RADIUS还继承了HTTP摘要的漏洞（请参见[RFC2617]第4节）。
An attacker compromising a RADIUS client or proxy can carry out man-in-the-middle attacks even if the paths between A, B and B, C (Figure 2) have been secured with TLS or IPsec.
即使a、B和B、C（图2）之间的路径已使用TLS或IPsec进行保护，危及RADIUS客户端或代理的攻击者也可以执行中间人攻击。
The RADIUS server MUST check the Digest-Realm attribute it has received from a client. If the RADIUS client is not authorized to serve HTTP-style clients of that realm, it might be compromised.
RADIUS服务器必须检查它从客户端收到的摘要域属性。如果RADIUS客户端未被授权为该领域的HTTP风格客户端提供服务，则可能会受到损害。
RADIUS clients implementing the extension described in this document may authenticate HTTP-style requests received over the Internet. As compared with the use of RADIUS to authenticate link-layer network access, attackers may find it easier to cover their tracks in such a scenario.
实现本文档中所述扩展的RADIUS客户端可以对通过Internet接收的HTTP样式请求进行身份验证。与使用RADIUS对链路层网络访问进行身份验证相比，攻击者可能会发现在这种情况下更容易掩盖其踪迹。
An attacker can attempt a denial-of-service attack on one or more RADIUS servers by sending a large number of HTTP-style requests. To make simple denial-of-service attacks more difficult, the RADIUS server MUST check whether it has generated the nonce received from an HTTP-style client. This SHOULD be done statelessly. For example, a nonce could consist of a cryptographically random part and some kind of signature provided by the RADIUS client, as described in [RFC2617], section 3.2.1.
攻击者可以通过发送大量HTTP样式的请求，在一个或多个RADIUS服务器上尝试拒绝服务攻击。为了使简单的拒绝服务攻击更加困难，RADIUS服务器必须检查是否已生成从HTTP样式客户端接收的nonce。这应该是无状态的。例如，nonce可以由加密随机部分和RADIUS客户端提供的某种签名组成，如[RFC2617]第3.2.1节所述。
The attributes described in this document are sent in cleartext. RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm attributes in Access-Challenge messages. A man in the middle can modify or remove those attributes in a bidding down attack, causing the RADIUS client to use a weaker authentication scheme than intended.
本文档中描述的属性以明文形式发送。RADIUS服务器应在访问质询消息中包含摘要Qop和摘要算法属性。中间人可以在竞价下降攻击中修改或删除这些属性，导致RADIUS客户端使用比预期的较弱的认证方案。
The Message-Authenticator attribute, described in [RFC3579], section 3.2 MUST be included in Access-Request, Access-Challenge, Access-Reject, and Access-Accept messages that contain attributes described in this specification.
[RFC3579]第3.2节所述的消息验证器属性必须包含在包含本规范所述属性的访问请求、访问质询、访问拒绝和访问接受消息中。
The Digest-HA1 attribute contains no random components if the algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary attacks easier and enables replay attacks.
如果算法为“MD5”或“AKAv1-MD5”，则Digest-HA1属性不包含随机组件。这使得脱机字典攻击更容易，并支持重播攻击。
Some parameter combinations require the protection of RADIUS packets against eavesdropping and tampering. Implementations SHOULD try to determine automatically whether IPsec is configured to protect traffic between the RADIUS client and the RADIUS server. If this is not possible, the implementation checks a configuration parameter telling it whether IPsec will protect RADIUS traffic. The default value of this configuration parameter tells the implementation that RADIUS packets will not be protected.
某些参数组合需要保护RADIUS数据包免受窃听和篡改。实施应尝试自动确定是否将IPsec配置为保护RADIUS客户端和RADIUS服务器之间的通信量。如果不可能，则实现将检查一个配置参数，告诉它IPsec是否将保护RADIUS流量。此配置参数的默认值告诉实现RADIUS数据包将不受保护。
HTTP-style clients can use TLS with server side certificates together with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, too. TLS or IPsec secure the connection while Digest Authentication authenticates the user. The RADIUS transaction can be regarded as
HTTP样式的客户端可以将TLS与服务器端证书以及HTTP摘要身份验证一起使用。也可以使用IPsec代替TLS。TLS或IPsec在摘要身份验证对用户进行身份验证时保护连接。RADIUS事务可以看作是
one leg on the path between the HTTP-style client and the HTTP-style server. To prevent RADIUS from representing the weak link, a RADIUS client receiving an HTTP-style request via TLS or IPsec could use an equally secure connection to the RADIUS server. There are several ways to achieve this, for example:
HTTP样式客户端和HTTP样式服务器之间路径上的一个分支。为了防止RADIUS表示弱链接，通过TLS或IPsec接收HTTP样式请求的RADIUS客户端可以使用到RADIUS服务器的同等安全连接。有几种方法可以实现这一点，例如：
o The RADIUS client may reject HTTP-style requests received over TLS or IPsec.
o RADIUS客户端可以拒绝通过TLS或IPsec接收的HTTP样式的请求。
o The RADIUS client may require that traffic be sent and received over IPsec.
o RADIUS客户端可能要求通过IPsec发送和接收通信量。
RADIUS over IPsec, if used, MUST conform to the requirements described in [RFC3579], section 4.2.
IPsec上的RADIUS（如果使用）必须符合[RFC3579]第4.2节中所述的要求。
We would like to acknowledge Kevin McDermott (Cisco Systems) for providing comments and experimental implementation.
我们感谢Kevin McDermott（Cisco Systems）提供的意见和实验实施。
Many thanks to all reviewers, especially to Miguel Garcia, Jari Arkko, Avi Lior, and Jun Wang.
非常感谢所有评论家，特别是米格尔·加西亚、贾里·阿尔科、阿维·利奥和王军。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[SIP-APP] Garcia-Martin, M., "Diameter Session Initiation Protocol (SIP) Application", Work in Progress), April 2006.
[SIP-APP]Garcia Martin，M.，“Diameter会话启动协议（SIP）应用”，正在进行的工作，2006年4月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.
[RFC2069]Franks，J.，Hallam Baker，P.，Hostetler，J.，Leach，P.，Lootonen，A.，Sink，E.，和L.Stewart，“HTTP的扩展：摘要访问认证”，RFC 2069，1997年1月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002.
[RFC3310]Niemi，A.，Arkko，J.，和V.Torvinen，“使用身份验证和密钥协议（AKA）的超文本传输协议（HTTP）摘要身份验证”，RFC 331102002年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
Authors' Addresses
作者地址
Baruch Sterman Kayote Networks P.O. Box 1373 Efrat 90435 Israel
Baruch Sterman Kayote Networks邮政信箱1373，地址：以色列90435
EMail: baruch@kayote.com
EMail: baruch@kayote.com
Daniel Sadolevsky SecureOL, Inc. Jerusalem Technology Park P.O. Box 16120 Jerusalem 91160 Israel
Daniel Sadolevsky SecureOL，Inc.耶路撒冷科技园邮政信箱16120耶路撒冷91160以色列
EMail: dscreat@dscreat.com
EMail: dscreat@dscreat.com
David Schwartz Kayote Networks P.O. Box 1373 Efrat 90435 Israel
David Schwartz Kayote Networks邮政信箱1373，地址：以色列90435
EMail: david@kayote.com
EMail: david@kayote.com
David Williams Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park NC 27709 USA
David Williams Cisco Systems 7025 Kit Creek Road邮政信箱14987美国北卡罗来纳州三角研究园27709
EMail: dwilli@cisco.com
EMail: dwilli@cisco.com
Wolfgang Beck Deutsche Telekom AG Deutsche Telekom Allee 7 Darmstadt 64295 Germany
沃尔夫冈·贝克德国电信股份公司德国电信阿莱7号达姆施塔特64295德国
EMail: beckw@t-systems.com
EMail: beckw@t-systems.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。