idnits 2.17.1 draft-ietf-radext-digest-auth-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1465. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 34 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 9, 2005) is 6797 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Note 1' is mentioned on line 1019, but not defined == Missing Reference: 'Note 2' is mentioned on line 1021, but not defined == Missing Reference: 'Note 3' is mentioned on line 1023, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 3310 ** Downref: Normative reference to an Informational RFC: RFC 3579 == Outdated reference: A later version (-12) exists of draft-ietf-aaa-diameter-sip-app-07 -- Obsolete informational reference (is this intentional?): RFC 2069 (Obsoleted by RFC 2617) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 2633 (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sterman 3 Internet-Draft Kayote Networks 4 Expires: March 13, 2006 D. Sadolevsky 5 SecureOL, Inc. 6 D. Schwartz 7 Kayote Networks 8 D. Williams 9 Cisco Systems 10 W. Beck 11 Deutsche Telekom AG 12 September 9, 2005 14 RADIUS Extension for Digest Authentication 15 draft-ietf-radext-digest-auth-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on March 13, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document defines an extension to the RADIUS protocol to enable 49 support of Digest Authentication, for use with HTTP-style protocols 50 like SIP and HTTP. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.3.1. Scenario 1, RADIUS client chooses nonces . . . . . . . 6 59 1.3.2. Scenario 2, RADIUS server chooses nonces . . . . . . . 7 60 2. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 9 61 3. Detailed Description . . . . . . . . . . . . . . . . . . . . . 9 62 3.1. RADIUS Client Behavior . . . . . . . . . . . . . . . . . . 9 63 3.2. RADIUS Server Behavior . . . . . . . . . . . . . . . . . . 12 64 4. New RADIUS attributes . . . . . . . . . . . . . . . . . . . . 14 65 4.1. Digest-Response attribute . . . . . . . . . . . . . . . . 14 66 4.2. Digest-Realm attribute . . . . . . . . . . . . . . . . . . 14 67 4.3. Digest-Nonce attribute . . . . . . . . . . . . . . . . . . 15 68 4.4. Digest-Response-Auth attribute . . . . . . . . . . . . . . 15 69 4.5. Digest-Nextnonce attribute . . . . . . . . . . . . . . . . 16 70 4.6. Digest-Method attribute . . . . . . . . . . . . . . . . . 16 71 4.7. Digest-URI attribute . . . . . . . . . . . . . . . . . . . 16 72 4.8. Digest-Qop attribute . . . . . . . . . . . . . . . . . . . 17 73 4.9. Digest-Algorithm attribute . . . . . . . . . . . . . . . . 17 74 4.10. Digest-Entity-Body-Hash attribute . . . . . . . . . . . . 18 75 4.11. Digest-CNonce attribute . . . . . . . . . . . . . . . . . 18 76 4.12. Digest-Nonce-Count attribute . . . . . . . . . . . . . . . 19 77 4.13. Digest-Username attribute . . . . . . . . . . . . . . . . 19 78 4.14. Digest-Opaque attribute . . . . . . . . . . . . . . . . . 20 79 4.15. Digest-Auth-Param attribute . . . . . . . . . . . . . . . 20 80 4.16. Digest-AKA-Auts attribute . . . . . . . . . . . . . . . . 21 81 4.17. Digest-Domain attribute . . . . . . . . . . . . . . . . . 21 82 4.18. Digest-Stale attribute . . . . . . . . . . . . . . . . . . 21 83 4.19. Digest-HA1 attribute . . . . . . . . . . . . . . . . . . . 22 84 4.20. SIP-AOR . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 23 86 6. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 23 87 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 90 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 31 94 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 95 A.1. Changes from draft-ietf-radext-digest-auth-04 . . . . . . 31 96 A.2. Changes from draft-ietf-radext-digest-auth-03 . . . . . . 31 97 A.3. Changes from draft-ietf-radext-digest-auth-02 . . . . . . 31 98 A.4. Changes from draft-ietf-radext-digest-auth-01 . . . . . . 32 99 A.5. Changes from draft-ietf-radext-digest-auth-00 . . . . . . 32 100 A.6. Changes from draft-sterman-aaa-sip-04 . . . . . . . . . . 32 101 A.7. Changes from draft-sterman-aaa-sip-03 . . . . . . . . . . 32 102 A.8. Changes from draft-sterman-aaa-sip-02 . . . . . . . . . . 32 103 A.9. Changes from draft-sterman-aaa-sip-01 . . . . . . . . . . 33 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 105 Intellectual Property and Copyright Statements . . . . . . . . . . 35 107 1. Introduction 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 The use of normative requirement key words in this document shall 116 apply only to RADIUS Client and RADIUS Server implementations that 117 include the features described in this document. This document 118 creates no normative requirements for existing implementations. 120 HTTP-style protocol 121 The term 'HTTP-style' denotes any protocol that uses HTTP-like 122 headers and uses HTTP digest authentication as described in 123 [RFC2617]. Examples are HTTP [RFC2616] and SIP [RFC3261]. 124 NAS 125 Network Access Server, the RADIUS client. 126 nonce 127 An unpredictable value used to prevent replay attacks. The 128 nonce generator may use cryptographic mechanisms to produce 129 nonces it can recognize without maintaining state. 130 protection space 131 The combination of realm and digest URI, the use of which is 132 authorized by the RADIUS server. 133 SIP UA 134 SIP User Agent, an Internet endpoint that uses the Session 135 Initiation Protocol. 136 SIP UAS 137 SIP User Agent Server, a logical entity that generates a 138 response to a SIP (Session Initiation Protocol) request. 140 1.2. Motivation 142 The HTTP Digest Authentication mechanism, defined in [RFC2617], was 143 subsequently adapted to use with SIP in [RFC2543] (obsoleted by 144 [RFC3261]). Due to the limitations and weaknesses of Digest 145 Authentication (see [RFC2617], section 4), additional authentication 146 and encryption mechanisms are defined in SIP [RFC3261], including TLS 147 [RFC2246] and S/MIME [RFC2633]. However, Digest Authentication has 148 been widely implemented within SIP clients and to support those 149 clients there is a need for support of Digest Authentication within 150 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC3588]. 152 This document defines an extension to the RADIUS protocol to enable 153 support of Digest Authentication, for use with SIP, HTTP, and other 154 HTTP-style protocols using this authentication method. Support for 155 Digest mechanisms such as AKA [RFC3310] is also supported. A 156 companion document [I-D.ietf-aaa-diameter-sip-app] defines support 157 for Digest Authentication within Diameter. 159 1.3. Overview 161 HTTP digest is a challenge-response protocol used to authenticate a 162 client's request to access some resource on a server. Figure 1 shows 163 a single HTTP digest transaction. 165 HTTP/SIP.. 166 +------------+ (1) +------------+ 167 | |--------->| | 168 | HTTP-style | (2) | HTTP-style | 169 | Client |<---------| server | 170 | | (3) | | 171 | |--------->| | 172 | | (4) | | 173 | |<---------| | 174 +------------+ +------------+ 176 Figure 1: digest operation without RADIUS 178 If the client sends a request without any credentials (1), the server 179 will reply with an error response (2) containing a nonce. The client 180 creates a cryptographic digest from parts of the request, from the 181 nonce it received from the server, and a shared secret. The client 182 re-transmits the request (3) to the server, but now includes the 183 digest within the packet. The server does the same digest 184 calculation as the client and compares the result with the digest it 185 received in (3). If the digest values are identical, the server 186 grants access to the resource and sends a positive response to the 187 client (4). If the digest values differ, the server sends a negative 188 response to the client (4). 190 Instead of maintaining a local user database, the server could use 191 RADIUS to access a centralized user database. However, RADIUS 192 [RFC2865] does not include support for HTTP digest authentication. 193 The RADIUS client can not use the User-Password attribute, since it 194 does not receive a password from the HTTP-style client. The CHAP- 195 Challenge and CHAP-Password attributes are also not suitable since 196 the CHAP algorithm is not compatible with HTTP digest. 198 This document defines new attributes that enable the RADIUS server to 199 perform the digest calculation defined in [RFC2617], providing 200 support for Digest Authentication as a native authentication 201 mechanism within RADIUS. 203 This document defines new attributes that enable the RADIUS server to 204 perform the digest calculation defined in [RFC2617]. 206 The nonces required by the digest algorithm are either generated by 207 the RADIUS client or by the RADIUS server. A mix of nonce generation 208 modes is not supported. This specification assumes that both the 209 RADIUS client and server are appropriately configured to generate the 210 nonces in either the RADIUS client or the RADIUS server, but not in 211 both at the same time. Implementations, though, do not have the 212 means to verify this behavior. 214 1.3.1. Scenario 1, RADIUS client chooses nonces 216 HTTP/SIP RADIUS 218 +-----+ (1) +-----+ +-----+ 219 | |==========>| | | | 220 | | (2) | | | | 221 | |<==========| | | | 222 | | (3) | | | | 223 | |==========>| | | | 224 | A | | B | (4) | C | 225 | | | |---------->| | 226 | | | | (5) | | 227 | | | |<----------| | 228 | | (6) | | | | 229 | |<==========| | | | 230 +-----+ +-----+ +-----+ 232 ====> HTTP/SIP 233 ----> RADIUS 235 Figure 2: RADIUS client chooses nonces 237 The roles played by the entities in this scenario are as follows: 239 A: HTTP client / SIP UA 241 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 242 acting also as a RADIUS NAS (RADIUS client) 244 C: RADIUS server 246 The relevant order of messages sent in this scenario is as follows: 248 A sends B an HTTP/SIP request without authorization header (step 1). 249 B challenges A sending an HTTP/SIP "407 / 401 (Proxy) Authorization 250 required" response containing a locally generated nonce (step 2). A 251 sends B an HTTP/SIP request with authorization header (step 3). B 252 sends C a RADIUS Access-Request with attributes described in this 253 document (step 4). C responds to B with a RADIUS Access-Accept/ 254 Access-Reject response (step 5). If credentials were accepted, B 255 receives an Access-Accept response and the message sent from A is 256 considered authentic. If B receives an Access-Reject response, 257 however, B then responds to A with a "407 / 401 (Proxy) Authorization 258 required" response (step 6). 260 1.3.2. Scenario 2, RADIUS server chooses nonces 262 While the usage scenario described in Section 1.3.1 minimizes the 263 load on the RADIUS server, alternatives are required in some 264 situations. When using AKA [RFC3310] the nonce is partially derived 265 from a precomputed authentication vector, which is often stored 266 centrally. 268 Figure 3 depicts a scenario in which the RADIUS server chooses 269 nonces. In this case entities A and B communicate using HTTP or SIP, 270 while entities B and C communicate using RADIUS." 271 HTTP/SIP RADIUS 273 +-----+ (1) +-----+ +-----+ 274 | |==========>| | (2) | | 275 | | | |---------->| | 276 | | | | (3) | | 277 | | (4) | |<----------| | 278 | |<==========| | | | 279 | | (5) | | | | 280 | |==========>| | | | 281 | A | | B | (6) | C | 282 | | | |---------->| | 283 | | | | (7) | | 284 | | | |<----------| | 285 | | (8) | | | | 286 | |<==========| | | | 287 +-----+ +-----+ +-----+ 289 ====> HTTP/SIP 290 ----> RADIUS 292 Figure 3: RADIUS server chooses nonces 294 The roles played by the entities in this scenario are as follows: 296 A: HTTP client / SIP UA 298 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 299 acting also as a RADIUS NAS 301 C: RADIUS server 303 The following messages are sent in this scenario: 305 A sends B an HTTP/SIP request without an authorization header (step 306 1). B sends an Access-Request packet with the newly defined Digest- 307 Method and Digest-URI attributes but without a Digest-Nonce attribute 308 to the RADIUS server, C (step 2). C chooses a nonce and responds 309 with an Access-Challenge (step 3). This Access-Challenge contains 310 Digest attributes, from which B takes values to construct an HTTP/SIP 311 "(Proxy) Authorization required" response. The remaining steps are 312 identical with scenario 1 (Section 1.3.1): B sends this response to A 313 (step 4). A resends its request with its credentials (step 5). B 314 sends an Access-Request to C (step 6). C checks the credentials and 315 replies with Access-Accept or Access-Reject (step 7). Dependent on 316 the C's result, B processes A's request or rejects it with a "(Proxy) 317 Authorization required" response (step 8). 319 2. Interoperability 321 An implementation supporting this extension MUST include a Digest- 322 Response attribute within an Access-Request packet where Digest 323 Authentication is desired. An Access-Request MUST NOT contain both a 324 Digest-Response attribute and another authentication attribute, such 325 as User-Password, CHAP-Password, or EAP-Message. 327 RADIUS clients and servers MUST support both nonce generation modes. 328 As there is no automatic capability exchange, the operator MUST make 329 sure that the RADIUS client software uses the correct nonce 330 generation mode when accessing a specific RADIUS server: 331 o If the RADIUS server generates nonces, its RADIUS clients MUST NOT 332 try to generate nonces. 333 o If the RADIUS server does not generate nonces, its RADIUS clients 334 MUST generate nonces locally. 335 o If at least one HTTP-style client requires AKA authentication 336 [RFC3310], the RADIUS server MUST generate nonces and its RADIUS 337 clients MUST NOT generate nonces locally. 338 RADIUS implementations MUST offer respective configuration options. 340 3. Detailed Description 342 3.1. RADIUS Client Behavior 344 The attributes described in this document are sent in cleartext. 345 Therefore were a RADIUS client to accept secured connections (https 346 or sips) from HTTP-style clients, this could result in information 347 intentionally protected by HTTP-style clients being sent in the clear 348 during the RADIUS exchange. 350 If the packets between RADIUS client and RADIUS server are not 351 protected with IPsec, the RADIUS client MUST NOT accept secured 352 connections (like https or sips) from its HTTP-style clients, so that 353 HTTP-style clients are not provided with a false sense of security. 355 On reception of an HTTP-style request message, the RADIUS client 356 checks whether it is authorized to authenticate the request. Where 357 an HTTP-style request traverses several proxies and each of the 358 proxies requests to authenticate the HTTP-style client, the request 359 at the HTTP-style server may contain multiple credential sets. 361 The RADIUS client can use the 'realm' directive in HTTP to determine 362 which credentials are applicable. Where none of the realms are of 363 interest, the RADIUS client MUST behave as though no relevant 364 credentials were sent. In all situations the RADIUS client MUST send 365 zero or exactly one credential to the RADIUS server. The RADIUS 366 client MUST choose the credential of the (Proxy-)Authorization header 367 if the realm directive matches its locally configured realm. 369 If such a (Proxy-)Authorization header is present and contains HTTP 370 digest information, the RADIUS client checks the 'nonce' parameter. 371 If the RADIUS client generates nonces but did not issue the received 372 nonce, it responds with a 401 (Unauthorized) or 407 (Proxy 373 Authentication Required) to the HTTP-style client. In this error 374 response, the RADIUS client sends a new nonce. 376 If the RADIUS client recognizes the nonce or does not generate 377 nonces, it takes the header directives and puts them into a RADIUS 378 Access-Request packet. It puts the 'response' directive into a 379 Digest-Response attribute and the realm / nonce / digest-uri / qop / 380 algorithm / cnonce / nc / username / opaque directives into the 381 respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / 382 Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- 383 Username / Digest-Opaque attributes. The request method is put into 384 the Digest-Method attribute. The RADIUS client adds a Message- 385 Authenticator attribute, defined in [RFC3579] and sends the Access- 386 Request packet to the RADIUS server. 388 The RADIUS server processes the packet and responds with an Access- 389 Accept or an Access-Reject. 391 The RADIUS client constructs an Authentication-Info header: 392 o If the Access-Accept packet contains a Digest-Response-Auth 393 attribute, the RADIUS client checks the Digest-Qop attribute: 394 * If the Digest-Qop attribute's value is 'auth' or not specified, 395 the RADIUS client puts the Digest-Response-Auth attribute's 396 content into the Authentication-Info header's 'rspauth' 397 directive of the HTTP-style response. 398 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 399 client ignores the Access-Accept packet and behaves like it had 400 received an Access-Reject packet (Digest-Response-Auth can't be 401 correct as the RADIUS server does not know the contents of the 402 HTTP-style response's body). 403 o If the Access-Accept packet contains a Digest-HA1 attribute, the 404 RADIUS client checks the 'qop' and 'algorithm' directives in the 405 Authorization header of the HTTP-style request it wants to 406 authorize: 407 * If the 'qop' directive is missing or its value is 'auth', the 408 RADIUS client ignores the Digest-HA1 attribute. It does not 409 include an Authentication-Info header into its HTTP-style 410 response. 412 * If the 'qop' directive's value is 'auth-int' and at least one 413 of the following conditions is true, the RADIUS client 414 calculates the contents of the HTTP-style response's 'rspauth' 415 directive: 416 + The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5- 417 sess'. 418 + The packets between RADIUS client and RADIUS server are 419 protected with IPsec (see Section 9). 420 It creates the HTTP-style response message and calculates the 421 hash of this message's body. It uses the result and the 422 Digest-URI attribute's value of the corresponding Access- 423 Request packet to perform the H(A2) calculation. It takes the 424 Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop 425 values of the corresponding Access-Request and the Digest-HA1 426 attribute's value to finish the computation of the 'rspauth' 427 value. 428 o If the Access-Accept packet contains neither a Digest-Response- 429 Auth nor a Digest-HA1 attribute, the RADIUS client will not create 430 an Authentication-Info header for its HTTP-style response. 432 The RADIUS server MAY have added a Digest-Nextnonce attribute into an 433 Access-Accept packet. If the RADIUS client discovers this, it puts 434 the contents of this attribute into a 'nextnonce' directive. Now it 435 can send an HTTP-style response. 437 If the RADIUS client did receive an HTTP-style request without a 438 (Proxy-)Authorization header matching its locally configured realm 439 value, it obtains a new nonce and sends an error response (401 or 440 407) containing a (Proxy-)Authenticate header. 442 If the RADIUS client receives an Access-Reject from the RADIUS 443 server, it sends an error response to the HTTP-style request it has 444 received. If the RADIUS client does not receive a response, it 445 retransmits or fails over to another RADIUS server as described in 446 [RFC2865]. 448 The RADIUS client has three ways to obtain nonces: it generates them 449 locally, it has received one in a Digest-Nextnonce attribute of a 450 previously received Access-Accept packet, or it asks the RADIUS 451 server for one. To do the latter, it sends an Access-Request 452 containing a Digest-Method and a Digest-URI attribute but without a 453 Digest-Nonce attribute. It adds a Message-Authenticator (see 454 [RFC3579]) attribute to the Access-Request packet. The RADIUS server 455 chooses a nonce and responds with an Access-Challenge containing a 456 Digest-Nonce attribute. 458 The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- 459 Realm, Digest-Domain and Digest-Opaque attributes in the Access- 460 Challenge carrying the nonce. If these attributes are present, the 461 client MUST use them. 463 If the RADIUS client receives an Access-Challenge packet in response 464 to an Access-Request containing a Digest-Nonce attribute, the RADIUS 465 server did not accept the nonce. If a Digest-Stale attribute is 466 present in the Access-Challenge and has a value of 'true' (without 467 quotes), the RADIUS client sends an error (401 or 407) response 468 containing WWW-/Proxy-Authenticate header with the directive 'stale' 469 and the digest directives derived from the Digest-* attributes. 471 3.2. RADIUS Server Behavior 473 If the RADIUS server receives an Access-Request packet with a Digest- 474 Method and a Digest-URI attribute but without a Digest-Nonce 475 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 476 attribute and sends it in an Access-Challenge packet to the RADIUS 477 client. The RADIUS server MUST add Digest-Realm, Message- 478 Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or 479 more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes 480 to the Access-Challenge packet. If the server cannot choose a nonce, 481 it replies with an Access-Reject packet. 483 If the RADIUS server receives an Access-Request packet containing a 484 Digest-Response attribute, it looks for the following attributes: 485 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, 486 Digest-Algorithm, Digest-Username. Depending on the content of 487 Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- 488 Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and 489 [RFC3310] for details. If the Digest-Algorithm attribute is missing, 490 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque 491 attribute along with the nonce, the Access-Request MUST have a 492 matching Digest-Opaque attribute. 494 If mandatory attributes are missing, it MUST respond with an Access- 495 Reject packet. If the attributes are present, the RADIUS server 496 calculates the digest response as described in [RFC2617]. To look up 497 the password, the RADIUS server uses the RADIUS User-Name attribute. 498 The RADIUS server MUST check if the user identified by the User-Name 499 attribute 500 o is authorized to access the protection space defined by the 501 Digest-URI and Digest-Realm attributes, 502 o is authorized to use the URI included in the SIP-AOR attribute, if 503 this attribute is present. 504 If any of those checks fails, the RADIUS server MUST send an Access- 505 Reject. 507 Correlation between User-Name and SIP-AOR AVP values is required just 508 to avoid that any user can register or misuse a SIP-AOR allocated to 509 another user. 511 A RADIUS server MUST check if the RADIUS client is authorized to 512 serve users of the realm mentioned in the Digest-Realm attribute. If 513 the RADIUS client is not authorized, the RADIUS server MUST send an 514 Access-Reject. The RADIUS server SHOULD log the event so as to 515 notify the operator, and MAY take additional action such as sending 516 an Access-Reject in response to all future requests from this client, 517 until this behavior is reset by management action. 519 All values required for the digest calculation are taken from the 520 Digest attributes described in this document. If the calculated 521 digest response equals the value received in the Digest-Response 522 attribute, the authentication was successful. If not, the RADIUS 523 server responds with an Access-Reject. 525 If the authentication was successful, the RADIUS server adds an 526 attribute to the Access-Accept packet which can be used by the RADIUS 527 client to construct an Authentication-Info header: 528 o If the Digest-Qop attribute's value is 'auth' or unspecified, the 529 RADIUS server SHOULD put a Digest-Response-Auth attribute into the 530 Access-Accept packet 531 o If the Digest-Qop attribute's value is 'auth-int' and at least one 532 of the following conditions is true, the RADIUS server SHOULD put 533 a Digest-HA1 attribute into the Access-Accept packet: 534 * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- 535 MD5-sess'. 536 * The packets between RADIUS client and RADIUS server are 537 protected with IPsec (see Section 9). 538 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be 539 sent. 541 RADIUS servers issuing nonces MAY construct a Digest-Nextnonce 542 attribute and add it to the Access-Accept packet. This is useful to 543 limit the lifetime of a nonce and to save a round-trip in future 544 requests (see nextnonce discussion in [RFC2617], section 3.2.3). The 545 RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) 546 and sends the Access-Accept packet to the RADIUS client. 548 If the RADIUS server does not accept the nonce received in an Access- 549 Request packet but authentication was successful, the RADIUS server 550 MUST send an Access-Challenge packet containing a Digest-Stale 551 attribute set to 'true' (without quotes). The RADIUS server MUST add 552 Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm, 553 SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add 554 Digest-Domain, Digest-Opaque attributes to the Access-Challenge 555 packet. 557 4. New RADIUS attributes 559 If not stated otherwise, the attributes have the following format: 561 0 1 2 562 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type | Length | Text ... 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 4.1. Digest-Response attribute 569 Description 570 If this attribute is present in an Access-Request message, a 571 RADIUS server implementing this specification MUST treat the 572 Access-Request as a request for Digest Authentication. When a 573 RADIUS client receives a (Proxy-)Authorization header, it puts 574 the request-digest value into a Digest-Response attribute. 575 This attribute (which enables the user to prove possession of 576 the password) MUST only be used in Access-Requests. 577 Type 578 [IANA: use 102 if possible] for Digest-Response. 579 Length 580 >= 3 581 Text 582 When using HTTP digest, the text field is 32 octets long and 583 contains a hexadecimal representation of 16 octet digest value 584 as it was calculated by the authenticated client. Other digest 585 algorithms MAY define different digest lengths. The text field 586 MUST be copied from request-digest of digest-response 587 ([RFC2617]) without quotes. 589 4.2. Digest-Realm attribute 591 Description 592 This attribute describes a protection space of the RADIUS 593 server. See [RFC2617] 1.2 for details. It MUST only be used 594 in Access-Request and Access-Challenge packets. 595 Type 597 [IANA: use 103 if possible] for Digest-Realm 598 Length 599 >=3 600 Text 601 In Access-Requests, the RADIUS client takes the value of the 602 realm directive (realm-value according to [RFC2617]) without 603 quotes from the HTTP-style request it wants to authenticate. 604 In Access-Challenge packets, the RADIUS server puts the 605 expected realm value into this attribute. 607 4.3. Digest-Nonce attribute 609 Description 610 This attribute holds a nonce to be used in the HTTP Digest 611 calculation. If the Access-Request had a Digest-Method and a 612 Digest-URI but no Digest-Nonce attribute and the RADIUS server 613 is configured to choose nonces, it MUST put a Digest-Nonce 614 attribute into its Access-Challenge packet. This attribute 615 MUST only be used in Access-Request and Access-Challenge 616 packets. 617 Type 618 [IANA: use 104 if possible] for Digest-Nonce 619 Length 620 >=3 621 Text 622 In Access-Requests, the RADIUS client takes the value of the 623 nonce directive (nonce-value in [RFC2617]) without quotes from 624 the HTTP-style request it wants to authenticate. In Access- 625 Challenge packets, the attribute contains the nonce selected by 626 the RADIUS server. 628 4.4. Digest-Response-Auth attribute 630 Description 631 This attribute enables the RADIUS server to prove possession of 632 the password. If the previously received Digest-Qop attribute 633 was 'auth-int' (without quotes), the RADIUS server MUST send a 634 Digest-HA1 attribute instead of a Digest-Response-Auth 635 attribute. The Digest-Response-Auth attribute MUST only be 636 used in Access-Accept packets. The RADIUS client puts the 637 attribute value without quotes into the rspauth directive of 638 the Authentication-Info header. 639 Type 640 [IANA: use 105 if possible] for Digest-Response-Auth. 642 Length 643 >= 3 644 Text 645 The RADIUS server calculates a digest according to section 646 3.2.3 of [RFC2617] and copies the result into this attribute. 647 Other digest algorithms than the one defined in [RFC2617] MAY 648 define digest lengths other than 32. 650 4.5. Digest-Nextnonce attribute 652 This attribute holds a nonce to be used in the HTTP Digest 653 calculation. 655 Description 656 If the RADIUS server is configured to choose nonces it MAY put 657 a Digest-Nextnonce attribute into an Access-Accept packet. If 658 this attribute is present, the RADIUS client MUST put the 659 contents of this attribute into the nextnonce directive of an 660 Authentication-Info header in its HTTP-style response. This 661 attribute MUST only be used in Access-Accept packets. 662 Type 663 [IANA: use 106 if possible] for Digest-Nextnonce 664 Length 665 >=3 666 Text 667 It is recommended that this text be base64 or hexadecimal data. 669 4.6. Digest-Method attribute 671 Description 672 This attribute holds the method value to be used in the HTTP 673 Digest calculation. This attribute MUST only be used in 674 Access-Request packets. 675 Type 676 [IANA: use 107 if possible] for Digest-Method 677 Length 678 >=3 679 Text 680 In Access-Requests, the RADIUS client takes the value of the 681 request method from the HTTP-style request it wants to 682 authenticate. 684 4.7. Digest-URI attribute 685 Description 686 This attribute is used to transport the contents of the digest- 687 uri directive or the URI of the HTTP-style request. It MUST 688 only be used in Access-Request packets. 689 Type 690 [IANA: use 108 if possible] for Digest-URI 691 Length 692 >=3 693 Text 694 If the HTTP-style request has an Authorization header, the 695 RADIUS client puts the value of the "uri" directive in the 696 (known as "digest-uri-value" in section 3.2.2 of [RFC2617]) 697 without quotes into this attribute. If there is no 698 Authorization header, the RADIUS client takes the value of the 699 request URI from the HTTP-style request it wants to 700 authenticate. 702 4.8. Digest-Qop attribute 704 Description 705 This attribute holds the Quality of Protection parameter that 706 influences the HTTP Digest calculation. This attribute MUST 707 only be used in Access-Request and Access-Challenge packets. A 708 RADIUS client SHOULD insert one of the Digest-Qop attributes it 709 has received in a previous Access-Challenge packet. RADIUS 710 servers SHOULD insert at least one Digest-Qop attribute in an 711 Access-Challenge packet. Digest-Qop is optional in order to 712 preserve backward compatibility with a minimal implementation 713 of [RFC2069]. 714 Type 715 [IANA: use 109 if possible] for Digest-Qop 716 Length 717 >=3 718 Text 719 In Access-Requests, the RADIUS client takes the value of the 720 qop directive (qop-value as described in [RFC2617]) without the 721 quotes from the HTTP-style request it wants to authenticate. 722 In Access-Challenge packets, the RADIUS server puts a desired 723 qop-value into this attribute. If the RADIUS server supports 724 more than one "quality of protection" value, it puts each qop- 725 value into a separate Digest-Qop attribute. 727 4.9. Digest-Algorithm attribute 728 Type 729 This attribute holds the algorithm parameter that influences 730 the HTTP Digest calculation. It MUST only be used in Access- 731 Request and Access-Challenge packets. If this attribute is 732 missing, "MD5" is assumed. 733 Type 734 [IANA: use 110 if possible] for Digest-Algorithm 735 Length 736 >=3 737 Text 738 In Access-Requests, the RADIUS client takes the value of the 739 algorithm directive (as described in [RFC2617], section 3.2.1) 740 without the quotes from the HTTP-style request it wants to 741 authenticate. In Access-Challenge packets, the RADIUS server 742 SHOULD put the desired algorithm into this attribute. 744 4.10. Digest-Entity-Body-Hash attribute 746 Description 747 When using the qop level 'auth-int', a hash of the HTTP-style 748 message body's contents is required for digest calculation. 749 Instead of sending the complete body of the message, only its 750 hash value is sent. This hash value can be used directly in 751 the digest calculation. 752 The clarifications described in section 22.4 of [RFC2617] about 753 the hash of empty entity bodies apply to the Digest-Entity- 754 Body-Hash attribute. This attribute MUST only be sent in 755 Access-Request packets. 756 Type 757 [IANA: use 111 if possible] for Digest-Entity-Body-Hash 758 Length 759 >=3 760 Text 761 The attribute holds the hexadecimal representation of H(entity- 762 body). This hash is required by certain authentication 763 mechanisms, such as HTTP Digest with quality of protection set 764 to "auth-int". RADIUS clients MUST use this attribute to 765 transport the hash of the entity body when HTTP Digest is the 766 authentication mechanism and the RADIUS server requires to 767 verify the integrity of the entity body (e.g., qop parameter 768 set to "auth-int"). Extensions to this document may define 769 support for authentication mechanisms other than HTTP Digest. 771 4.11. Digest-CNonce attribute 772 Description 773 This attribute holds the client nonce parameter that is used in 774 the HTTP Digest calculation. It MUST only be used in Access- 775 Request packets. 776 Type 777 [IANA: use 112 if possible] for Digest-CNonce 778 Length 779 >=3 780 Text 781 This attribute includes the value of the cnonce-value [RFC2617] 782 without quotes, taken from the HTTP-style request. 784 4.12. Digest-Nonce-Count attribute 786 Description 787 This attribute includes the nonce count parameter that is used 788 to detect replay attacks. The attribute MUST only be used in 789 Access-Request packets. 790 Type 791 [IANA: use 113 if possible] for Digest-Nonce-Count 792 Length 793 10 794 Text 795 In Access-Requests, the RADIUS client takes the value of the nc 796 directive (nc-value according to [RFC2617]) without quotes from 797 the HTTP-style request it wants to authenticate. 799 4.13. Digest-Username attribute 801 Description 802 This attribute holds the user name used in the HTTP digest 803 calculation. The RADIUS server MUST use this attribute only 804 for the purposes of calculating the digest. In order to 805 determine the appropriate user credentials, the RADIUS server 806 MUST use the User-Name (1) attribute, and MUST NOT use the 807 Digest-Username attribute. This attribute MUST only be used in 808 Access-Request packets. 809 Type 810 [IANA: use 114 if possible] for Digest-Username 811 Length 812 >= 3 813 Text 814 In Access-Requests, the RADIUS client takes the value of the 815 username directive (username-value according to [RFC2617]) 816 without quotes from the HTTP-style request it wants to 817 authenticate. 819 4.14. Digest-Opaque attribute 821 Description 822 This attribute holds the opaque parameter that is passed to the 823 HTTP-style client. The HTTP-style client will pass this value 824 back to the server (i.e. the RADIUS client) without 825 modification. This attribute is only used when the RADIUS 826 server chooses nonces and MUST only be used in Access-Request 827 and Access-Challenge packets. 828 Type 829 [IANA: use 115 if possible] for Digest-Opaque 830 Length 831 >=3 832 Text 833 In Access-Requests, the RADIUS client takes the value of the 834 opaque directive (opaque-value according to [RFC2617]) without 835 quotes from the HTTP-style request it wants to authenticate and 836 puts it into this attribute. In Access-Challenge packets, the 837 RADIUS server MAY include this attribute. 839 4.15. Digest-Auth-Param attribute 841 Description 842 This attribute is a placeholder for future extensions and 843 corresponds to the "auth-param" parameter defined in section 844 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism 845 whereby the RADIUS client and RADIUS server can exchange auth- 846 param extension parameters contained within Digest headers that 847 are not understood by the RADIUS client and for which there are 848 no corresponding stand-alone attributes. 849 Unlike the previously listed Digest-* attributes, the Digest- 850 Auth-Param contains not only the value, but also the parameter 851 name, since the parameter name is unknown to the RADIUS client. 852 If the Digest header contains several unknown parameters, then 853 the RADIUS implementation MUST repeat this attribute and each 854 instance MUST contain one different unknown Digest parameter/ 855 value combination. This attribute MUST ONLY be used in Access- 856 Request, Access-Challenge, or Access-Accept packets. 857 Type 858 [IANA: use 116 if possible] for Digest-Auth-Param 859 Length 860 >=3 861 Text 862 The text consists of the whole parameter, including its name 863 and the equal ('=') sign and quotes. 865 4.16. Digest-AKA-Auts attribute 867 Description 868 This attribute holds the auts parameter that is used in the 869 Digest AKA ([RFC3310]) calculation. It is only used if the 870 algorithm of the digest-response denotes a version of AKA 871 digest [RFC3310]. This attribute MUST only be used in Access- 872 Request packets. 873 Type 874 [IANA: use 117 if possible] for Digest-AKA-Auts 875 Length 876 >=3 877 Text 878 In Access-Requests, the RADIUS client takes the value of the 879 auts directive (auts-param according to section 3.4 of 880 [RFC3310]) without quotes from the HTTP-style request it wants 881 to authenticate. 883 4.17. Digest-Domain attribute 885 Description 886 When a RADIUS client has asked for a nonce, the RADIUS server 887 MAY send one or more Digest-Domain attributes in its Access- 888 Challenge packet. The RADIUS client puts them into the quoted, 889 space-separated list of URIs of the 'domain' directive of a 890 WWW-Authenticate header. The URIs in the list define the 891 protection space (see [RFC2617], section 3.2.1). RADIUS 892 servers MAY send one or more attributes of this type in Access- 893 Challenge packets. This attribute MUST only be used in Access- 894 Challenge packets. 895 Type 896 [IANA: use 118 if possible] for Digest-Domain 897 Length 898 3 899 Text 900 This attribute consists of a single URI, that defines a 901 protection space. 903 4.18. Digest-Stale attribute 905 Description 906 This attribute is sent by a RADIUS server in order to notify 907 the RADIUS client whether it has accepted a nonce. If the 908 nonce presented by the RADIUS client was stale, the value is 909 'true' and is 'false' otherwise. The RADIUS client puts the 910 content of this attribute into a 'stale' directive of the WWW- 911 Authenticate header in the HTTP-style response to the request 912 it wants to authenticate. The attribute MUST only be used in 913 Access-Challenge packets and only if the RADIUS server chooses 914 nonces. 915 Type 916 [IANA: use 119 if possible] for Digest-Stale 917 Length 918 3 919 Text 920 The attribute has either the value 'true' or 'false' (both 921 values without quotes). 923 4.19. Digest-HA1 attribute 925 Description 926 This attribute is used to allow the generation of an 927 Authentication-Info header, even if the HTTP-style response's 928 body is required for the calculation of the rspauth value. It 929 SHOULD be used in Access-Accept packets if the required quality 930 of protection ('qop') is 'auth-int'. 931 This attribute MUST NOT be sent if the qop parameter was not 932 specified or has a value of 'auth' (in this case, use Digest- 933 Response-Auth instead). 934 The Digest-HA1 attribute MUST only be sent by the RADIUS server 935 or processed by the RADIUS client if at least one of the 936 following conditions is true: 937 + The Digest-Algorithm attribute's value is 'MD5-sess' or 938 'AKAv1-MD5-sess'. 939 + The packets between RADIUS client and RADIUS server are 940 protected with IPsec (see Section 9). 941 This attribute MUST only be used in Access-Accept packets. 942 Type 943 [IANA: use 120 if possible] for Digest-HA1 944 Length 945 >= 3 946 Text 947 This attribute contains the hexadecimal representation of H(A1) 948 as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2. 950 4.20. SIP-AOR 952 Type 953 This attribute is used for the authorization of SIP messages. 954 The SIP-AOR attribute identifies the URI the use of which must 955 be authenticated and authorized. The RADIUS server uses this 956 attribute to authorize the processing of the SIP request. The 957 SIP-AOR can be derived from, e.g., the To header field in a SIP 958 REGISTER request (user under registration), or the From header 959 field in other SIP requests. However, the exact mapping of 960 this attribute to SIP can change due to new developments in the 961 protocol. This attribute MUST only be used when the RADIUS 962 client wants to authorize SIP users and MUST only be used in 963 Access-Request packets. 964 Type 965 [IANA:use 121 if possible] for SIP-AOR 966 Length 967 >=3 968 Text 969 The syntax of this attribute corresponds either to a SIP URI 970 (with the format defined in [RFC3261] or a TEL URI (with the 971 format defined in [RFC3966]). 972 The SIP-AOR attribute holds the complete URI, including 973 parameters and other parts. It is up to the RADIUS server what 974 components of the URI are regarded in the authorization 975 decision. 977 5. Diameter Compatibility 979 This document defines support for Digest Authentication in RADIUS. A 980 companion document "Diameter Session Initiation Protocol (SIP) 981 Application" [I-D.ietf-aaa-diameter-sip-app] defines support for 982 Digest Authentication in Diameter, and addresses compatibility issues 983 between RADIUS and Diameter. 985 6. Table of Attributes 987 The following table provides a guide to which attributes may be found 988 in which kinds of packets, and in what quantity. 990 Req Accept Reject Challenge # Attribute 991 1 0 0 0 1 User-Name 992 1 1 1 1 80 Message-Authenticator 993 0-1 0 0 0 TBD Digest-Response 994 0-1 0 0 1 TBD Digest-Realm 995 0-1 0 0 1 TBD Digest-Nonce 996 0 0-1 0 0 TBD Digest-Response-Auth 997 (see Note 1, 2) 998 0 0-1 0 0 TBD Digest-Nextnonce 999 0-1 0 0 0 TBD Digest-Method 1000 0-1 0 0 0 TBD Digest-URI 1001 0-1 0 0 1+ TBD Digest-Qop 1002 0-1 0 0 0-1 TBD Digest-Algorithm (see 1003 Note 3) 1004 0-1 0 0 0 TBD Digest-Entity-Body-Hash 1005 0-1 0 0 0 TBD Digest-CNonce 1006 0-1 0 0 0 TBD Digest-Nonce-Count 1007 0-1 0 0 0 TBD Digest-Username 1008 0-1 0 0 0-1 TBD Digest-Opaque 1009 0+ 0+ 0 0+ TBD Digest-Auth-Param 1010 0-1 0 0 0 TBD Digest-AKA-Auts 1011 0 0 0 0+ TBD Digest-Domain 1012 0 0 0 0-1 TBD Digest-Stale 1013 0 0-1 0 0 TBD Digest-HA1 (see Note 1, 1014 2) 1015 0-1 0 0 0 TBD SIP-AOR 1017 Table 1 1019 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if 1020 Digest-Qop is 'auth-int'. 1021 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if 1022 Digest-Qop is 'auth'. 1023 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed 1025 7. Example 1027 This is an example sniffed from the traffic between a softphone (A), 1028 a Proxy Server (B) and example.com RADIUS server (C). The 1029 communication between the Proxy Server and a SIP PSTN gateway is 1030 omitted for brevity. The SIP messages are not shown completely. 1032 A->B 1034 INVITE sip:97226491335@example.com SIP/2.0 1035 From: 1036 To: 1038 B->A 1040 SIP/2.0 100 Trying 1042 B->A 1044 SIP/2.0 407 Proxy Authentication Required 1045 Proxy-Authenticate: Digest realm="example.com" 1046 ,nonce="3bada1a0", algorithm="md5" 1047 Content-Length: 0 1049 A->B 1051 ACK sip:97226491335@example.com SIP/2.0 1053 A->B 1055 INVITE sip:97226491335@example.com SIP/2.0 1056 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1057 ,opaque="",realm="example.com" 1058 ,response="f3ce87e6984557cd0fecc26f3c5e97a4" 1059 ,uri="sip:97226491335@10.0.69.38",username="12345678" 1060 From: 1061 To: 1063 B->C 1065 Code = 1 (Access-Request) 1066 Attributes: 1067 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1068 NAS-Port-Type = 5 (Virtual) 1069 User-Name = "12345678" 1070 Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" 1071 Digest-Realm = "example.com" 1072 Digest-Nonce = "3bada1a0" 1073 Digest-Method = "INVITE" 1074 Digest-URI = "sip:97226491335@example.com" 1075 Digest-Algorithm = "md5" 1076 Digest-Username = "12345678" 1077 SIP-AOR = "sip:12345678@example.com" 1079 C->B 1081 Code = 2 (Access-Accept) 1082 Attributes: 1083 Digest-Response-Auth = 1084 "6303c41b0e2c3e524e413cafe8cce954" 1086 B->A 1088 SIP/2.0 180 Ringing 1090 B->A 1092 SIP/2.0 200 OK 1094 A->B 1096 ACK sip:97226491335@example.com SIP/2.0 1098 A second example shows the traffic between a web browser (A), web 1099 server (B) and a RADIUS server (C). 1101 A->B 1103 GET /index.html HTTP/1.1 1105 B->A 1107 HTTP/1.1 407 Authentication Required 1108 WWW-Authenticate: Digest realm="example.com", 1109 domain="/index.html", 1110 nonce="a3086ac8", algorithm="md5" 1111 Content-Length: 0 1113 A->B 1115 GET /index.html HTTP/1.1 1116 Authorization: Digest algorithm="md5",nonce="a3086ac8" 1117 ,opaque="",realm="example.com" 1118 ,response="f052b68058b2987aba493857ae1ab002" 1119 ,uri="/index.html",username="12345678" 1121 B->C 1123 Code = 1 (Access-Request) 1124 Attributes: 1125 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1126 NAS-Port-Type = 5 (Virtual) 1127 User-Name = "12345678" 1128 Digest-Response = "f052b68058b2987aba493857ae1ab002" 1129 Digest-Realm = "example.com" 1130 Digest-Nonce = "a3086ac8" 1131 Digest-Method = "GET" 1132 Digest-URI = "/index.html"" 1133 Digest-Algorithm = "md5" 1134 Digest-Username = "12345678" 1136 C->B 1138 Code = 2 (Access-Accept) 1139 Attributes: 1140 Digest-Response-Auth = 1141 "e644aa513effbfe1caff67103ff6433c" 1143 B->A 1145 HTTP/1.1 200 OK 1146 ... 1148 1149 ... 1151 8. IANA Considerations 1153 This document serves as IANA registration request for a number of 1154 values from the RADIUS attribute type number space: 1156 +-------------------------+------------------------+ 1157 | placeholder | value assigned by IANA | 1158 +-------------------------+------------------------+ 1159 | Digest-Response | TBD | 1160 | Digest-Realm | TBD | 1161 | Digest-Nonce | TBD | 1162 | Digest-Nextnonce | TBD | 1163 | Digest-Response-Auth | TBD | 1164 | Digest-Method | TBD | 1165 | Digest-URI | TBD | 1166 | Digest-Qop | TBD | 1167 | Digest-Algorithm | TBD | 1168 | Digest-Entity-Body-Hash | TBD | 1169 | Digest-CNonce | TBD | 1170 | Digest-Nonce-Count | TBD | 1171 | Digest-Username | TBD | 1172 | Digest-Opaque | TBD | 1173 | Digest-Auth-Param | TBD | 1174 | Digest-AKA-Auts | TBD | 1175 | Digest-Domain | TBD | 1176 | Digest-Stale | TBD | 1177 | Digest-HA1 | TBD | 1178 | SIP-AOR | TBD | 1179 +-------------------------+------------------------+ 1181 Table 2 1183 9. Security Considerations 1185 The RADIUS extensions described in this document enable RADIUS to 1186 transport the data that required to perform a digest calculation. As 1187 a result, RADIUS inherits the vulnerabilities of HTTP Digest (see 1188 [RFC2617], section 4) in addition to RADIUS security vulnerabilities 1189 described in [RFC2865] Section 8 and [RFC3579] Section 4. 1191 An attacker compromising a RADIUS client or proxy can carry out man- 1192 in-the-middle attacks even if the paths between A, B and B, C 1193 (Figure 2) have been secured with TLS or IPsec. 1195 The RADIUS server MUST check the Digest-Realm attribute it has 1196 received from a client. If the RADIUS client is not authorized to 1197 serve HTTP-style clients of that realm, it might be compromised. 1199 RADIUS clients implementing the extension described in this document 1200 may authenticate HTTP-style requests received over the Internet. As 1201 compared with use of RADIUS to authenticate link layer network 1202 access, an attacker may find it easier to cover their tracks in such 1203 a scenario. 1205 An attacker can attempt a denial of service attack on one or more 1206 RADIUS servers by sending a large number of HTTP-style requests. To 1207 make simple denial of service attacks more difficult, the nonce 1208 issuer (RADIUS client or server) MUST check if it has generated the 1209 nonce received from an HTTP-style client. This SHOULD be done 1210 statelessly. For example, a nonce could consist of a 1211 cryptographically random part and some kind of signature provided by 1212 the RADIUS client, as described in [RFC2617], section 3.2.1. 1214 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm 1215 attributes in Access-Challenge messages. A man in the middle can 1216 modify or remove those attributes in a bidding down attack, causing 1217 the RADIUS client to use a weaker authentication scheme than 1218 intended. 1220 The Message-Authenticator attribute, described in [RFC3579] section 1221 3.2 MUST be included in Access-Request, Access-Challenge, Access- 1222 Reject and Access-Accept messages that contain attributes described 1223 in this specification. 1225 The Digest-HA1 attribute contains no random components if the 1226 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1227 attacks easier and enables replay attacks. 1229 HTTP-style clients can use TLS with server side certificates together 1230 with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, 1231 too. TLS or IPsec secure the connection while Digest Authentication 1232 authenticates the user. The RADIUS transaction can be regarded as 1233 one leg on the path between the HTTP-style client and the HTTP-style 1234 server. To prevent RADIUS from representing the weak link, a RADIUS 1235 client receiving an HTTP-style request via TLS or IPsec MUST use an 1236 equally secure connection to the RADIUS server. There are two ways 1237 to achieve this: 1238 o the RADIUS client may reject HTTP-style requests received over TLS 1239 or IPsec 1240 o the RADIUS client require that traffic be sent and received over 1241 IPsec. 1242 RADIUS over IPsec, if used, MUST conform to the requirements 1243 described in [RFC3579] section 4.2. 1245 10. Acknowledgments 1247 We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or 1248 providing comments and experimental implementation. 1250 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1251 Arkko, Avi Lior and Jun Wang. 1253 11. References 1255 11.1. Normative References 1257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1258 Requirement Levels", BCP 14, RFC 2119, March 1997. 1260 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1261 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1262 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1264 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1265 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1266 Authentication: Basic and Digest Access Authentication", 1267 RFC 2617, June 1999. 1269 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1270 "Remote Authentication Dial In User Service (RADIUS)", 1271 RFC 2865, June 2000. 1273 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1274 A., Peterson, J., Sparks, R., Handley, M., and E. 1275 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1276 June 2002. 1278 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1279 Protocol (HTTP) Digest Authentication Using Authentication 1280 and Key Agreement (AKA)", RFC 3310, September 2002. 1282 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1283 Dial In User Service) Support For Extensible 1284 Authentication Protocol (EAP)", RFC 3579, September 2003. 1286 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1287 RFC 3966, December 2004. 1289 11.2. Informative References 1291 [I-D.ietf-aaa-diameter-sip-app] 1292 Garcia-Martin, M., "Diameter Session Initiation Protocol 1293 (SIP) Application", draft-ietf-aaa-diameter-sip-app-07 1294 (work in progress), March 2005. 1296 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 1297 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 1298 HTTP : Digest Access Authentication", RFC 2069, 1299 January 1997. 1301 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1302 RFC 2246, January 1999. 1304 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1305 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1306 March 1999. 1308 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1309 RFC 2633, June 1999. 1311 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1312 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1314 Appendix A. Change Log 1316 RFC editor: please remove this section prior to RFC publication. 1318 A.1. Changes from draft-ietf-radext-digest-auth-04 1320 o Short Diameter compatibility section 1322 A.2. Changes from draft-ietf-radext-digest-auth-03 1324 o new 'Interoperability' section, requiring support for both nonce 1325 generation modes. 1326 o removed Diameter migration path section (again) 1327 o reference to server behavior in Security Considerations section 1328 o fixed text/table mismatch regarding Digest-Domain attributes 1330 A.3. Changes from draft-ietf-radext-digest-auth-02 1332 o added Diameter migration path section (again) 1333 o various typos 1335 A.4. Changes from draft-ietf-radext-digest-auth-01 1337 o removed Diameter migration path section 1338 o Included Digest-URI and Digest-Realm in the authorization 1339 decision, not just in the digest calculation 1340 o RADIUS server must check if a RADIUS client is authorized to serve 1341 the realm mentioned in Digest-Realm 1342 o moved 'Detailed Description' sections in front of 'New RADIUS 1343 attributes' section 1344 o replaced 'IPsec or otherwise secured connection' with IPsec 1345 o changed MAY to SHOULD for Digest-Algorithm in Access-Challenge 1346 o changed type of Digest-Entity-Body-Hash to text (all other H(..) 1347 result attributes are hex and text, too) 1348 o new abstract 1349 o Terminology section changed 1350 o 'Changes' section as appendix 1352 A.5. Changes from draft-ietf-radext-digest-auth-00 1354 o SIP-AOR attribute added 1355 o clarified use of Digest-Qop 1356 o attribute overview table added 1358 A.6. Changes from draft-sterman-aaa-sip-04 1360 o clarified usage of Digest-HA1 1361 o clarified usage of Digest-Stale (is sent in an Access-Challenge 1362 now) 1363 o clarified allowed attribute usage for message types 1364 o changed attribute type to 'Text' where the corresponding Diameter 1365 AVPs have a UTF8String 1366 o added Diameter client - RADIUS server handling 1368 A.7. Changes from draft-sterman-aaa-sip-03 1370 o addressed 'auth-int' issue 1371 o New Digest-Nextnonce attribute 1372 o revised abstract, motivational section and examples 1373 o Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce 1374 attribute' 1375 o shortened SIP messages in example, removed real-world addresses 1376 and product names 1378 A.8. Changes from draft-sterman-aaa-sip-02 1380 o Relaxed restrictions for Digest-Domain, Digest-Realm, Digest- 1381 Opaque, Digest-Qop and Digest-Algorithm 1383 o Additional security considerations for Digest-Domain, Digest-Qop 1384 and Digest-Algorithm usage in Access-Accept messages 1386 A.9. Changes from draft-sterman-aaa-sip-01 1388 o Replaced Sub-attributes with flat attributes 1389 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1390 o Added how a server must treat unknown attributes. 1391 o Added a section 'Migration path to Diameter' 1392 o Added an optional attribute for support of the digest scheme 1393 described in informational [RFC3310]. 1394 o Added a mode of operation where the RADIUS server chooses the 1395 nonce. This was required for AKA [RFC3310], but can be useful for 1396 ordinary Digest Authentication when the qop directive is not used. 1397 This required the addition of several attributes. 1399 Authors' Addresses 1401 Baruch Sterman 1402 Kayote Networks 1403 P.O. Box 1373 1404 Efrat 90435 1405 Israel 1407 Email: baruch@kayote.com 1409 Daniel Sadolevsky 1410 SecureOL, Inc. 1411 Jerusalem Technology Park 1412 P.O. Box 16120 1413 Jerusalem 91160 1414 Israel 1416 Email: dscreat@dscreat.com 1418 David Schwartz 1419 Kayote Networks 1420 P.O. Box 1373 1421 Efrat 90435 1422 Israel 1424 Email: david@kayote.com 1426 David Williams 1427 Cisco Systems 1428 7025 Kit Creek Road 1429 P.O. Box 14987 1430 Research Triangle Park NC 27709 1431 USA 1433 Email: dwilli@cisco.com 1435 Wolfgang Beck 1436 Deutsche Telekom AG 1437 Am Kavalleriesand 3 1438 Darmstadt 64295 1439 Germany 1441 Email: beckw@t-systems.com 1443 Intellectual Property Statement 1445 The IETF takes no position regarding the validity or scope of any 1446 Intellectual Property Rights or other rights that might be claimed to 1447 pertain to the implementation or use of the technology described in 1448 this document or the extent to which any license under such rights 1449 might or might not be available; nor does it represent that it has 1450 made any independent effort to identify any such rights. Information 1451 on the procedures with respect to rights in RFC documents can be 1452 found in BCP 78 and BCP 79. 1454 Copies of IPR disclosures made to the IETF Secretariat and any 1455 assurances of licenses to be made available, or the result of an 1456 attempt made to obtain a general license or permission for the use of 1457 such proprietary rights by implementers or users of this 1458 specification can be obtained from the IETF on-line IPR repository at 1459 http://www.ietf.org/ipr. 1461 The IETF invites any interested party to bring to its attention any 1462 copyrights, patents or patent applications, or other proprietary 1463 rights that may cover technology that may be required to implement 1464 this standard. Please address the information to the IETF at 1465 ietf-ipr@ietf.org. 1467 Disclaimer of Validity 1469 This document and the information contained herein are provided on an 1470 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1471 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1472 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1473 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1474 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1475 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1477 Copyright Statement 1479 Copyright (C) The Internet Society (2005). This document is subject 1480 to the rights, licenses and restrictions contained in BCP 78, and 1481 except as set forth therein, the authors retain all their rights. 1483 Acknowledgment 1485 Funding for the RFC Editor function is currently provided by the 1486 Internet Society.