idnits 2.17.1 draft-ietf-radext-digest-auth-06.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 1473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1463. ** 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 (October 14, 2005) is 6768 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 1018, but not defined == Missing Reference: 'Note 2' is mentioned on line 1020, but not defined == Missing Reference: 'Note 3' is mentioned on line 1022, but not defined ** 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-09 -- 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: 6 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: April 17, 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 October 14, 2005 14 RADIUS Extension for Digest Authentication 15 draft-ietf-radext-digest-auth-06.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 April 17, 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 . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . 19 79 4.15. Digest-Auth-Param attribute . . . . . . . . . . . . . . . 20 80 4.16. Digest-AKA-Auts attribute . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . 30 94 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 95 A.1. Changes from draft-ietf-radext-digest-auth-05 . . . . . . 31 96 A.2. Changes from draft-ietf-radext-digest-auth-04 . . . . . . 31 97 A.3. Changes from draft-ietf-radext-digest-auth-03 . . . . . . 31 98 A.4. Changes from draft-ietf-radext-digest-auth-02 . . . . . . 31 99 A.5. Changes from draft-ietf-radext-digest-auth-01 . . . . . . 31 100 A.6. Changes from draft-ietf-radext-digest-auth-00 . . . . . . 32 101 A.7. Changes from draft-sterman-aaa-sip-04 . . . . . . . . . . 32 102 A.8. Changes from draft-sterman-aaa-sip-03 . . . . . . . . . . 32 103 A.9. Changes from draft-sterman-aaa-sip-02 . . . . . . . . . . 32 104 A.10. Changes from draft-sterman-aaa-sip-01 . . . . . . . . . . 33 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 106 Intellectual Property and Copyright Statements . . . . . . . . . . 35 108 1. Introduction 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 The use of normative requirement key words in this document shall 117 apply only to RADIUS Client and RADIUS Server implementations that 118 include the features described in this document. This document 119 creates no normative requirements for existing implementations. 121 HTTP-style protocol 122 The term 'HTTP-style' denotes any protocol that uses HTTP-like 123 headers and uses HTTP digest authentication as described in 124 [RFC2617]. Examples are HTTP and SIP. 125 NAS 126 Network Access Server, the RADIUS client. 127 nonce 128 An unpredictable value used to prevent replay attacks. The 129 nonce generator may use cryptographic mechanisms to produce 130 nonces it can recognize without maintaining state. 131 protection space 132 The combination of realm and digest URI, the use of which is 133 authorized by the RADIUS server. 134 SIP UA 135 SIP User Agent, an Internet endpoint that uses the Session 136 Initiation Protocol. 137 SIP UAS 138 SIP User Agent Server, a logical entity that generates a 139 response to a SIP (Session Initiation Protocol) request. 141 1.2. Motivation 143 The HTTP Digest Authentication mechanism, defined in [RFC2617], was 144 subsequently adapted to use with SIP in [RFC2543] (obsoleted by 145 [RFC3261]). Due to the limitations and weaknesses of Digest 146 Authentication (see [RFC2617], section 4), additional authentication 147 and encryption mechanisms are defined in SIP [RFC3261], including TLS 148 [RFC2246] and S/MIME [RFC2633]. However, Digest Authentication has 149 been widely implemented within SIP clients and to support those 150 clients there is a need for support of Digest Authentication within 151 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC3588]. 153 This document defines an extension to the RADIUS protocol to enable 154 support of Digest Authentication, for use with SIP, HTTP, and other 155 HTTP-style protocols using this authentication method. Support for 156 Digest mechanisms such as AKA [RFC3310] is also supported. A 157 companion document [I-D.ietf-aaa-diameter-sip-app] defines support 158 for Digest Authentication within Diameter. 160 1.3. Overview 162 HTTP digest is a challenge-response protocol used to authenticate a 163 client's request to access some resource on a server. Figure 1 shows 164 a single HTTP digest transaction. 166 HTTP/SIP.. 167 +------------+ (1) +------------+ 168 | |--------->| | 169 | HTTP-style | (2) | HTTP-style | 170 | Client |<---------| server | 171 | | (3) | | 172 | |--------->| | 173 | | (4) | | 174 | |<---------| | 175 +------------+ +------------+ 177 Figure 1: digest operation without RADIUS 179 If the client sends a request without any credentials (1), the server 180 will reply with an error response (2) containing a nonce. The client 181 creates a cryptographic digest from parts of the request, from the 182 nonce it received from the server, and a shared secret. The client 183 re-transmits the request (3) to the server, but now includes the 184 digest within the packet. The server does the same digest 185 calculation as the client and compares the result with the digest it 186 received in (3). If the digest values are identical, the server 187 grants access to the resource and sends a positive response to the 188 client (4). If the digest values differ, the server sends a negative 189 response to the client (4). 191 Instead of maintaining a local user database, the server could use 192 RADIUS to access a centralized user database. However, RADIUS 193 [RFC2865] does not include support for HTTP digest authentication. 194 The RADIUS client can not use the User-Password attribute, since it 195 does not receive a password from the HTTP-style client. The CHAP- 196 Challenge and CHAP-Password attributes are also not suitable since 197 the CHAP algorithm is not compatible with HTTP digest. 199 This document defines new attributes that enable the RADIUS server to 200 perform the digest calculation defined in [RFC2617], providing 201 support for Digest Authentication as a native authentication 202 mechanism within RADIUS. 204 This document defines new attributes that enable the RADIUS server to 205 perform the digest calculation defined in [RFC2617]. 207 The nonces required by the digest algorithm are either generated by 208 the RADIUS client or by the RADIUS server. A mix of nonce generation 209 modes is not supported. This specification assumes that both the 210 RADIUS client and server are appropriately configured to generate the 211 nonces in either the RADIUS client or the RADIUS server, but not in 212 both at the same time. Implementations, though, do not have the 213 means to verify this behavior. 215 1.3.1. Scenario 1, RADIUS client chooses nonces 217 HTTP/SIP RADIUS 219 +-----+ (1) +-----+ +-----+ 220 | |==========>| | | | 221 | | (2) | | | | 222 | |<==========| | | | 223 | | (3) | | | | 224 | |==========>| | | | 225 | A | | B | (4) | C | 226 | | | |---------->| | 227 | | | | (5) | | 228 | | | |<----------| | 229 | | (6) | | | | 230 | |<==========| | | | 231 +-----+ +-----+ +-----+ 233 ====> HTTP/SIP 234 ----> RADIUS 236 Figure 2: RADIUS client chooses nonces 238 The roles played by the entities in this scenario are as follows: 240 A: HTTP client / SIP UA 242 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 243 acting also as a RADIUS NAS (RADIUS client) 245 C: RADIUS server 247 The relevant order of messages sent in this scenario is as follows: 249 A sends B an HTTP/SIP request without authorization header (step 1). 250 B challenges A sending an HTTP/SIP "407 / 401 (Proxy) Authorization 251 required" response containing a locally generated nonce (step 2). A 252 sends B an HTTP/SIP request with authorization header (step 3). B 253 sends C a RADIUS Access-Request with attributes described in this 254 document (step 4). C responds to B with a RADIUS Access-Accept/ 255 Access-Reject response (step 5). If credentials were accepted, B 256 receives an Access-Accept response and the message sent from A is 257 considered authentic. If B receives an Access-Reject response, 258 however, B then responds to A with a "407 / 401 (Proxy) Authorization 259 required" response (step 6). 261 1.3.2. Scenario 2, RADIUS server chooses nonces 263 While the usage scenario described in Section 1.3.1 minimizes the 264 load on the RADIUS server, alternatives are required in some 265 situations. When using AKA [RFC3310] the nonce is partially derived 266 from a precomputed authentication vector, which is often stored 267 centrally. 269 Figure 3 depicts a scenario in which the RADIUS server chooses 270 nonces. In this case entities A and B communicate using HTTP or SIP, 271 while entities B and C communicate using RADIUS." 272 HTTP/SIP RADIUS 274 +-----+ (1) +-----+ +-----+ 275 | |==========>| | (2) | | 276 | | | |---------->| | 277 | | | | (3) | | 278 | | (4) | |<----------| | 279 | |<==========| | | | 280 | | (5) | | | | 281 | |==========>| | | | 282 | A | | B | (6) | C | 283 | | | |---------->| | 284 | | | | (7) | | 285 | | | |<----------| | 286 | | (8) | | | | 287 | |<==========| | | | 288 +-----+ +-----+ +-----+ 290 ====> HTTP/SIP 291 ----> RADIUS 293 Figure 3: RADIUS server chooses nonces 295 The roles played by the entities in this scenario are as follows: 297 A: HTTP client / SIP UA 299 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 300 acting also as a RADIUS NAS 302 C: RADIUS server 304 The following messages are sent in this scenario: 306 A sends B an HTTP/SIP request without an authorization header (step 307 1). B sends an Access-Request packet with the newly defined Digest- 308 Method and Digest-URI attributes but without a Digest-Nonce attribute 309 to the RADIUS server, C (step 2). C chooses a nonce and responds 310 with an Access-Challenge (step 3). This Access-Challenge contains 311 Digest attributes, from which B takes values to construct an HTTP/SIP 312 "(Proxy) Authorization required" response. The remaining steps are 313 identical with scenario 1 (Section 1.3.1): B sends this response to A 314 (step 4). A resends its request with its credentials (step 5). B 315 sends an Access-Request to C (step 6). C checks the credentials and 316 replies with Access-Accept or Access-Reject (step 7). Dependent on 317 the C's result, B processes A's request or rejects it with a "(Proxy) 318 Authorization required" response (step 8). 320 2. Interoperability 322 An implementation supporting this extension MUST include a Digest- 323 Response attribute within an Access-Request packet where Digest 324 Authentication is desired. An Access-Request MUST NOT contain both a 325 Digest-Response attribute and another authentication attribute, such 326 as User-Password, CHAP-Password, or EAP-Message. 328 RADIUS clients and servers MUST support both nonce generation modes. 329 As there is no automatic capability exchange, the operator MUST make 330 sure that the RADIUS client software uses the correct nonce 331 generation mode when accessing a specific RADIUS server: 332 o If the RADIUS server generates nonces, its RADIUS clients MUST NOT 333 try to generate nonces. 334 o If the RADIUS server does not generate nonces, its RADIUS clients 335 MUST generate nonces locally. 336 o If at least one HTTP-style client requires AKA authentication 337 [RFC3310], the RADIUS server MUST generate nonces and its RADIUS 338 clients MUST NOT generate nonces locally. 339 RADIUS implementations MUST offer respective configuration options. 341 3. Detailed Description 343 3.1. RADIUS Client Behavior 345 The attributes described in this document are sent in cleartext. 346 Therefore were a RADIUS client to accept secured connections (https 347 or sips) from HTTP-style clients, this could result in information 348 intentionally protected by HTTP-style clients being sent in the clear 349 during the RADIUS exchange. 351 On reception of an HTTP-style request message, the RADIUS client 352 checks whether it is authorized to authenticate the request. Where 353 an HTTP-style request traverses several proxies and each of the 354 proxies requests to authenticate the HTTP-style client, the request 355 at the HTTP-style server may contain multiple credential sets. 357 The RADIUS client can use the 'realm' directive in HTTP to determine 358 which credentials are applicable. Where none of the realms are of 359 interest, the RADIUS client MUST behave as though no relevant 360 credentials were sent. In all situations the RADIUS client MUST send 361 zero or exactly one credential to the RADIUS server. The RADIUS 362 client MUST choose the credential of the (Proxy-)Authorization header 363 if the realm directive matches its locally configured realm. 365 If such a (Proxy-)Authorization header is present and contains HTTP 366 digest information, the RADIUS client checks the 'nonce' parameter. 367 If the RADIUS client generates nonces but did not issue the received 368 nonce, it responds with a 401 (Unauthorized) or 407 (Proxy 369 Authentication Required) to the HTTP-style client. In this error 370 response, the RADIUS client sends a new nonce. 372 If the RADIUS client recognizes the nonce or does not generate 373 nonces, it takes the header directives and puts them into a RADIUS 374 Access-Request packet. It puts the 'response' directive into a 375 Digest-Response attribute and the realm / nonce / digest-uri / qop / 376 algorithm / cnonce / nc / username / opaque directives into the 377 respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / 378 Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- 379 Username / Digest-Opaque attributes. The request method is put into 380 the Digest-Method attribute. The RADIUS client adds a Message- 381 Authenticator attribute, defined in [RFC3579] and sends the Access- 382 Request packet to the RADIUS server. 384 The RADIUS server processes the packet and responds with an Access- 385 Accept or an Access-Reject. 387 The RADIUS client constructs an Authentication-Info header: 388 o If the Access-Accept packet contains a Digest-Response-Auth 389 attribute, the RADIUS client checks the Digest-Qop attribute: 390 * If the Digest-Qop attribute's value is 'auth' or not specified, 391 the RADIUS client puts the Digest-Response-Auth attribute's 392 content into the Authentication-Info header's 'rspauth' 393 directive of the HTTP-style response. 394 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 395 client ignores the Access-Accept packet and behaves like it had 396 received an Access-Reject packet (Digest-Response-Auth can't be 397 correct as the RADIUS server does not know the contents of the 398 HTTP-style response's body). 399 o If the Access-Accept packet contains a Digest-HA1 attribute, the 400 RADIUS client checks the 'qop' and 'algorithm' directives in the 401 Authorization header of the HTTP-style request it wants to 402 authorize: 403 * If the 'qop' directive is missing or its value is 'auth', the 404 RADIUS client ignores the Digest-HA1 attribute. It does not 405 include an Authentication-Info header into its HTTP-style 406 response. 407 * If the 'qop' directive's value is 'auth-int' and at least one 408 of the following conditions is true, the RADIUS client 409 calculates the contents of the HTTP-style response's 'rspauth' 410 directive: 412 + The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5- 413 sess'. 414 + The packets between RADIUS client and RADIUS server are 415 protected with IPsec (see Section 9). 416 It creates the HTTP-style response message and calculates the 417 hash of this message's body. It uses the result and the 418 Digest-URI attribute's value of the corresponding Access- 419 Request packet to perform the H(A2) calculation. It takes the 420 Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop 421 values of the corresponding Access-Request and the Digest-HA1 422 attribute's value to finish the computation of the 'rspauth' 423 value. 424 o If the Access-Accept packet contains neither a Digest-Response- 425 Auth nor a Digest-HA1 attribute, the RADIUS client will not create 426 an Authentication-Info header for its HTTP-style response. 428 The RADIUS server MAY have added a Digest-Nextnonce attribute into an 429 Access-Accept packet. If the RADIUS client discovers this, it puts 430 the contents of this attribute into a 'nextnonce' directive. Now it 431 can send an HTTP-style response. 433 If the RADIUS client did receive an HTTP-style request without a 434 (Proxy-)Authorization header matching its locally configured realm 435 value, it obtains a new nonce and sends an error response (401 or 436 407) containing a (Proxy-)Authenticate header. 438 If the RADIUS client receives an Access-Reject from the RADIUS 439 server, it sends an error response to the HTTP-style request it has 440 received. If the RADIUS client does not receive a response, it 441 retransmits or fails over to another RADIUS server as described in 442 [RFC2865]. 444 The RADIUS client has three ways to obtain nonces: it generates them 445 locally, it has received one in a Digest-Nextnonce attribute of a 446 previously received Access-Accept packet, or it asks the RADIUS 447 server for one. To do the latter, it sends an Access-Request 448 containing a Digest-Method and a Digest-URI attribute but without a 449 Digest-Nonce attribute. It adds a Message-Authenticator (see 450 [RFC3579]) attribute to the Access-Request packet. The RADIUS server 451 chooses a nonce and responds with an Access-Challenge containing a 452 Digest-Nonce attribute. 454 The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- 455 Realm, Digest-Domain and Digest-Opaque attributes in the Access- 456 Challenge carrying the nonce. If these attributes are present, the 457 client MUST use them. 459 If the RADIUS client receives an Access-Challenge packet in response 460 to an Access-Request containing a Digest-Nonce attribute, the RADIUS 461 server did not accept the nonce. If a Digest-Stale attribute is 462 present in the Access-Challenge and has a value of 'true' (without 463 quotes), the RADIUS client sends an error (401 or 407) response 464 containing WWW-/Proxy-Authenticate header with the directive 'stale' 465 and the digest directives derived from the Digest-* attributes. 467 3.2. RADIUS Server Behavior 469 If the RADIUS server receives an Access-Request packet with a Digest- 470 Method and a Digest-URI attribute but without a Digest-Nonce 471 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 472 attribute and sends it in an Access-Challenge packet to the RADIUS 473 client. The RADIUS server MUST add Digest-Realm, Message- 474 Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or 475 more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes 476 to the Access-Challenge packet. If the server cannot choose a nonce, 477 it replies with an Access-Reject packet. 479 If the RADIUS server receives an Access-Request packet containing a 480 Digest-Response attribute, it looks for the following attributes: 481 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, 482 Digest-Algorithm, Digest-Username. Depending on the content of 483 Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- 484 Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and 485 [RFC3310] for details. If the Digest-Algorithm attribute is missing, 486 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque 487 attribute along with the nonce, the Access-Request MUST have a 488 matching Digest-Opaque attribute. 490 If mandatory attributes are missing, it MUST respond with an Access- 491 Reject packet. If the attributes are present, the RADIUS server 492 calculates the digest response as described in [RFC2617]. To look up 493 the password, the RADIUS server uses the RADIUS User-Name attribute. 494 The RADIUS server MUST check if the user identified by the User-Name 495 attribute 496 o is authorized to access the protection space defined by the 497 Digest-URI and Digest-Realm attributes, 498 o is authorized to use the URI included in the SIP-AOR attribute, if 499 this attribute is present. 500 If any of those checks fails, the RADIUS server MUST send an Access- 501 Reject. 503 Correlation between User-Name and SIP-AOR AVP values is required just 504 to avoid that any user can register or misuse a SIP-AOR allocated to 505 another user. 507 A RADIUS server MUST check if the RADIUS client is authorized to 508 serve users of the realm mentioned in the Digest-Realm attribute. If 509 the RADIUS client is not authorized, the RADIUS server MUST send an 510 Access-Reject. The RADIUS server SHOULD log the event so as to 511 notify the operator, and MAY take additional action such as sending 512 an Access-Reject in response to all future requests from this client, 513 until this behavior is reset by management action. 515 All values required for the digest calculation are taken from the 516 Digest attributes described in this document. If the calculated 517 digest response equals the value received in the Digest-Response 518 attribute, the authentication was successful. If not, the RADIUS 519 server responds with an Access-Reject. 521 If the authentication was successful, the RADIUS server adds an 522 attribute to the Access-Accept packet which can be used by the RADIUS 523 client to construct an Authentication-Info header: 524 o If the Digest-Qop attribute's value is 'auth' or unspecified, the 525 RADIUS server SHOULD put a Digest-Response-Auth attribute into the 526 Access-Accept packet 527 o If the Digest-Qop attribute's value is 'auth-int' and at least one 528 of the following conditions is true, the RADIUS server SHOULD put 529 a Digest-HA1 attribute into the Access-Accept packet: 530 * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- 531 MD5-sess'. 532 * The packets between RADIUS client and RADIUS server are 533 protected with IPsec (see Section 9). 534 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be 535 sent. 537 RADIUS servers issuing nonces MAY construct a Digest-Nextnonce 538 attribute and add it to the Access-Accept packet. This is useful to 539 limit the lifetime of a nonce and to save a round-trip in future 540 requests (see nextnonce discussion in [RFC2617], section 3.2.3). The 541 RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) 542 and sends the Access-Accept packet to the RADIUS client. 544 If the RADIUS server does not accept the nonce received in an Access- 545 Request packet but authentication was successful, the RADIUS server 546 MUST send an Access-Challenge packet containing a Digest-Stale 547 attribute set to 'true' (without quotes). The RADIUS server MUST add 548 Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm, 549 SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add 550 Digest-Domain, Digest-Opaque attributes to the Access-Challenge 551 packet. 553 4. New RADIUS attributes 554 If not stated otherwise, the attributes have the following format: 556 0 1 2 557 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Type | Length | Text ... 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 4.1. Digest-Response attribute 564 Description 565 If this attribute is present in an Access-Request message, a 566 RADIUS server implementing this specification MUST treat the 567 Access-Request as a request for Digest Authentication. When a 568 RADIUS client receives a (Proxy-)Authorization header, it puts 569 the request-digest value into a Digest-Response attribute. 570 This attribute (which enables the user to prove possession of 571 the password) MUST only be used in Access-Requests. 572 Type 573 [IANA: use 102 if possible] for Digest-Response. 574 Length 575 >= 3 576 Text 577 When using HTTP digest, the text field is 32 octets long and 578 contains a hexadecimal representation of 16 octet digest value 579 as it was calculated by the authenticated client. Other digest 580 algorithms MAY define different digest lengths. The text field 581 MUST be copied from request-digest of digest-response 582 ([RFC2617]) without quotes. 584 4.2. Digest-Realm attribute 586 Description 587 This attribute describes a protection space of the RADIUS 588 server. See [RFC2617] 1.2 for details. It MUST only be used 589 in Access-Request and Access-Challenge packets. 590 Type 591 [IANA: use 103 if possible] for Digest-Realm 592 Length 593 >=3 594 Text 595 In Access-Requests, the RADIUS client takes the value of the 596 realm directive (realm-value according to [RFC2617]) without 597 quotes from the HTTP-style request it wants to authenticate. 598 In Access-Challenge packets, the RADIUS server puts the 599 expected realm value into this attribute. 601 4.3. Digest-Nonce attribute 603 Description 604 This attribute holds a nonce to be used in the HTTP Digest 605 calculation. If the Access-Request had a Digest-Method and a 606 Digest-URI but no Digest-Nonce attribute and the RADIUS server 607 is configured to choose nonces, it MUST put a Digest-Nonce 608 attribute into its Access-Challenge packet. This attribute 609 MUST only be used in Access-Request and Access-Challenge 610 packets. 611 Type 612 [IANA: use 104 if possible] for Digest-Nonce 613 Length 614 >=3 615 Text 616 In Access-Requests, the RADIUS client takes the value of the 617 nonce directive (nonce-value in [RFC2617]) without quotes from 618 the HTTP-style request it wants to authenticate. In Access- 619 Challenge packets, the attribute contains the nonce selected by 620 the RADIUS server. 622 4.4. Digest-Response-Auth attribute 624 Description 625 This attribute enables the RADIUS server to prove possession of 626 the password. If the previously received Digest-Qop attribute 627 was 'auth-int' (without quotes), the RADIUS server MUST send a 628 Digest-HA1 attribute instead of a Digest-Response-Auth 629 attribute. The Digest-Response-Auth attribute MUST only be 630 used in Access-Accept packets. The RADIUS client puts the 631 attribute value without quotes into the rspauth directive of 632 the Authentication-Info header. 633 Type 634 [IANA: use 105 if possible] for Digest-Response-Auth. 635 Length 636 >= 3 638 Text 639 The RADIUS server calculates a digest according to section 640 3.2.3 of [RFC2617] and copies the result into this attribute. 641 Other digest algorithms than the one defined in [RFC2617] MAY 642 define digest lengths other than 32. 644 4.5. Digest-Nextnonce attribute 646 This attribute holds a nonce to be used in the HTTP Digest 647 calculation. 649 Description 650 If the RADIUS server is configured to choose nonces it MAY put 651 a Digest-Nextnonce attribute into an Access-Accept packet. If 652 this attribute is present, the RADIUS client MUST put the 653 contents of this attribute into the nextnonce directive of an 654 Authentication-Info header in its HTTP-style response. This 655 attribute MUST only be used in Access-Accept packets. 656 Type 657 [IANA: use 106 if possible] for Digest-Nextnonce 658 Length 659 >=3 660 Text 661 It is recommended that this text be base64 or hexadecimal data. 663 4.6. Digest-Method attribute 665 Description 666 This attribute holds the method value to be used in the HTTP 667 Digest calculation. This attribute MUST only be used in 668 Access-Request packets. 669 Type 670 [IANA: use 107 if possible] for Digest-Method 671 Length 672 >=3 673 Text 674 In Access-Requests, the RADIUS client takes the value of the 675 request method from the HTTP-style request it wants to 676 authenticate. 678 4.7. Digest-URI attribute 680 Description 681 This attribute is used to transport the contents of the digest- 682 uri directive or the URI of the HTTP-style request. It MUST 683 only be used in Access-Request packets. 685 Type 686 [IANA: use 108 if possible] for Digest-URI 687 Length 688 >=3 689 Text 690 If the HTTP-style request has an Authorization header, the 691 RADIUS client puts the value of the "uri" directive in the 692 (known as "digest-uri-value" in section 3.2.2 of [RFC2617]) 693 without quotes into this attribute. If there is no 694 Authorization header, the RADIUS client takes the value of the 695 request URI from the HTTP-style request it wants to 696 authenticate. 698 4.8. Digest-Qop attribute 700 Description 701 This attribute holds the Quality of Protection parameter that 702 influences the HTTP Digest calculation. This attribute MUST 703 only be used in Access-Request and Access-Challenge packets. A 704 RADIUS client SHOULD insert one of the Digest-Qop attributes it 705 has received in a previous Access-Challenge packet. RADIUS 706 servers SHOULD insert at least one Digest-Qop attribute in an 707 Access-Challenge packet. Digest-Qop is optional in order to 708 preserve backward compatibility with a minimal implementation 709 of [RFC2069]. 710 Type 711 [IANA: use 109 if possible] for Digest-Qop 712 Length 713 >=3 714 Text 715 In Access-Requests, the RADIUS client takes the value of the 716 qop directive (qop-value as described in [RFC2617]) without the 717 quotes from the HTTP-style request it wants to authenticate. 718 In Access-Challenge packets, the RADIUS server puts a desired 719 qop-value into this attribute. If the RADIUS server supports 720 more than one "quality of protection" value, it puts each qop- 721 value into a separate Digest-Qop attribute. 723 4.9. Digest-Algorithm attribute 725 Type 726 This attribute holds the algorithm parameter that influences 727 the HTTP Digest calculation. It MUST only be used in Access- 728 Request and Access-Challenge packets. If this attribute is 729 missing, "MD5" is assumed. 731 Type 732 [IANA: use 110 if possible] for Digest-Algorithm 733 Length 734 >=3 735 Text 736 In Access-Requests, the RADIUS client takes the value of the 737 algorithm directive (as described in [RFC2617], section 3.2.1) 738 without the quotes from the HTTP-style request it wants to 739 authenticate. In Access-Challenge packets, the RADIUS server 740 SHOULD put the desired algorithm into this attribute. 742 4.10. Digest-Entity-Body-Hash attribute 744 Description 745 When using the qop level 'auth-int', a hash of the HTTP-style 746 message body's contents is required for digest calculation. 747 Instead of sending the complete body of the message, only its 748 hash value is sent. This hash value can be used directly in 749 the digest calculation. 750 The clarifications described in section 22.4 of [RFC2617] about 751 the hash of empty entity bodies apply to the Digest-Entity- 752 Body-Hash attribute. This attribute MUST only be sent in 753 Access-Request packets. 754 Type 755 [IANA: use 111 if possible] for Digest-Entity-Body-Hash 756 Length 757 >=3 758 Text 759 The attribute holds the hexadecimal representation of H(entity- 760 body). This hash is required by certain authentication 761 mechanisms, such as HTTP Digest with quality of protection set 762 to "auth-int". RADIUS clients MUST use this attribute to 763 transport the hash of the entity body when HTTP Digest is the 764 authentication mechanism and the RADIUS server requires to 765 verify the integrity of the entity body (e.g., qop parameter 766 set to "auth-int"). Extensions to this document may define 767 support for authentication mechanisms other than HTTP Digest. 769 4.11. Digest-CNonce attribute 771 Description 772 This attribute holds the client nonce parameter that is used in 773 the HTTP Digest calculation. It MUST only be used in Access- 774 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 820 Description 821 This attribute holds the opaque parameter that is passed to the 822 HTTP-style client. The HTTP-style client will pass this value 823 back to the server (i.e. the RADIUS client) without 824 modification. This attribute is only used when the RADIUS 825 server chooses nonces and MUST only be used in Access-Request 826 and Access-Challenge packets. 827 Type 828 [IANA: use 115 if possible] for Digest-Opaque 829 Length 830 >=3 831 Text 832 In Access-Requests, the RADIUS client takes the value of the 833 opaque directive (opaque-value according to [RFC2617]) without 834 quotes from the HTTP-style request it wants to authenticate and 835 puts it into this attribute. In Access-Challenge packets, the 836 RADIUS server MAY include this attribute. 838 4.15. Digest-Auth-Param attribute 840 Description 841 This attribute is a placeholder for future extensions and 842 corresponds to the "auth-param" parameter defined in section 843 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism 844 whereby the RADIUS client and RADIUS server can exchange auth- 845 param extension parameters contained within Digest headers that 846 are not understood by the RADIUS client and for which there are 847 no corresponding stand-alone attributes. 848 Unlike the previously listed Digest-* attributes, the Digest- 849 Auth-Param contains not only the value, but also the parameter 850 name, since the parameter name is unknown to the RADIUS client. 851 If the Digest header contains several unknown parameters, then 852 the RADIUS implementation MUST repeat this attribute and each 853 instance MUST contain one different unknown Digest parameter/ 854 value combination. This attribute MUST ONLY be used in Access- 855 Request, Access-Challenge, or Access-Accept packets. 856 Type 857 [IANA: use 116 if possible] for Digest-Auth-Param 858 Length 859 >=3 860 Text 861 The text consists of the whole parameter, including its name 862 and the equal ('=') sign and quotes. 864 4.16. Digest-AKA-Auts attribute 865 Description 866 This attribute holds the auts parameter that is used in the 867 Digest AKA ([RFC3310]) calculation. It is only used if the 868 algorithm of the digest-response denotes a version of AKA 869 digest [RFC3310]. This attribute MUST only be used in Access- 870 Request packets. 871 Type 872 [IANA: use 117 if possible] for Digest-AKA-Auts 873 Length 874 >=3 875 Text 876 In Access-Requests, the RADIUS client takes the value of the 877 auts directive (auts-param according to section 3.4 of 878 [RFC3310]) without quotes from the HTTP-style request it wants 879 to authenticate. 881 4.17. Digest-Domain attribute 883 Description 884 When a RADIUS client has asked for a nonce, the RADIUS server 885 MAY send one or more Digest-Domain attributes in its Access- 886 Challenge packet. The RADIUS client puts them into the quoted, 887 space-separated list of URIs of the 'domain' directive of a 888 WWW-Authenticate header. The URIs in the list define the 889 protection space (see [RFC2617], section 3.2.1). RADIUS 890 servers MAY send one or more attributes of this type in Access- 891 Challenge packets. This attribute MUST only be used in Access- 892 Challenge packets. 893 Type 894 [IANA: use 118 if possible] for Digest-Domain 895 Length 896 3 897 Text 898 This attribute consists of a single URI, that defines a 899 protection space. 901 4.18. Digest-Stale attribute 903 Description 904 This attribute is sent by a RADIUS server in order to notify 905 the RADIUS client whether it has accepted a nonce. If the 906 nonce presented by the RADIUS client was stale, the value is 907 'true' and is 'false' otherwise. The RADIUS client puts the 908 content of this attribute into a 'stale' directive of the WWW- 909 Authenticate header in the HTTP-style response to the request 910 it wants to authenticate. The attribute MUST only be used in 911 Access-Challenge packets and only if the RADIUS server chooses 912 nonces. 914 Type 915 [IANA: use 119 if possible] for Digest-Stale 916 Length 917 3 918 Text 919 The attribute has either the value 'true' or 'false' (both 920 values without quotes). 922 4.19. Digest-HA1 attribute 924 Description 925 This attribute is used to allow the generation of an 926 Authentication-Info header, even if the HTTP-style response's 927 body is required for the calculation of the rspauth value. It 928 SHOULD be used in Access-Accept packets if the required quality 929 of protection ('qop') is 'auth-int'. 930 This attribute MUST NOT be sent if the qop parameter was not 931 specified or has a value of 'auth' (in this case, use Digest- 932 Response-Auth instead). 933 The Digest-HA1 attribute MUST only be sent by the RADIUS server 934 or processed by the RADIUS client if at least one of the 935 following conditions is true: 936 + The Digest-Algorithm attribute's value is 'MD5-sess' or 937 'AKAv1-MD5-sess'. 938 + The packets between RADIUS client and RADIUS server are 939 protected with IPsec (see Section 9). 940 This attribute MUST only be used in Access-Accept packets. 941 Type 942 [IANA: use 120 if possible] for Digest-HA1 943 Length 944 >= 3 945 Text 946 This attribute contains the hexadecimal representation of H(A1) 947 as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2. 949 4.20. SIP-AOR 951 Type 952 This attribute is used for the authorization of SIP messages. 953 The SIP-AOR attribute identifies the URI the use of which must 954 be authenticated and authorized. The RADIUS server uses this 955 attribute to authorize the processing of the SIP request. The 956 SIP-AOR can be derived from, e.g., the To header field in a SIP 957 REGISTER request (user under registration), or the From header 958 field in other SIP requests. However, the exact mapping of 959 this attribute to SIP can change due to new developments in the 960 protocol. This attribute MUST only be used when the RADIUS 961 client wants to authorize SIP users and MUST only be used in 962 Access-Request packets. 963 Type 964 [IANA:use 121 if possible] for SIP-AOR 965 Length 966 >=3 967 Text 968 The syntax of this attribute corresponds either to a SIP URI 969 (with the format defined in [RFC3261] or a TEL URI (with the 970 format defined in [RFC3966]). 971 The SIP-AOR attribute holds the complete URI, including 972 parameters and other parts. It is up to the RADIUS server what 973 components of the URI are regarded in the authorization 974 decision. 976 5. Diameter Compatibility 978 This document defines support for Digest Authentication in RADIUS. A 979 companion document "Diameter Session Initiation Protocol (SIP) 980 Application" [I-D.ietf-aaa-diameter-sip-app] defines support for 981 Digest Authentication in Diameter, and addresses compatibility issues 982 between RADIUS and Diameter. 984 6. Table of Attributes 986 The following table provides a guide to which attributes may be found 987 in which kinds of packets, and in what quantity. 989 Req Accept Reject Challenge # Attribute 990 1 0 0 0 1 User-Name 991 1 1 1 1 80 Message-Authenticator 992 0-1 0 0 0 TBD Digest-Response 993 0-1 0 0 1 TBD Digest-Realm 994 0-1 0 0 1 TBD Digest-Nonce 995 0 0-1 0 0 TBD Digest-Response-Auth 996 (see Note 1, 2) 997 0 0-1 0 0 TBD Digest-Nextnonce 998 0-1 0 0 0 TBD Digest-Method 999 0-1 0 0 0 TBD Digest-URI 1000 0-1 0 0 1+ TBD Digest-Qop 1001 0-1 0 0 0-1 TBD Digest-Algorithm (see 1002 Note 3) 1003 0-1 0 0 0 TBD Digest-Entity-Body-Hash 1004 0-1 0 0 0 TBD Digest-CNonce 1005 0-1 0 0 0 TBD Digest-Nonce-Count 1006 0-1 0 0 0 TBD Digest-Username 1007 0-1 0 0 0-1 TBD Digest-Opaque 1008 0+ 0+ 0 0+ TBD Digest-Auth-Param 1009 0-1 0 0 0 TBD Digest-AKA-Auts 1010 0 0 0 0+ TBD Digest-Domain 1011 0 0 0 0-1 TBD Digest-Stale 1012 0 0-1 0 0 TBD Digest-HA1 (see Note 1, 1013 2) 1014 0-1 0 0 0 TBD SIP-AOR 1016 Table 1 1018 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if 1019 Digest-Qop is 'auth-int'. 1020 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if 1021 Digest-Qop is 'auth'. 1022 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed 1024 7. Example 1026 This is an example sniffed from the traffic between a softphone (A), 1027 a Proxy Server (B) and example.com RADIUS server (C). The 1028 communication between the Proxy Server and a SIP PSTN gateway is 1029 omitted for brevity. The SIP messages are not shown completely. 1031 A->B 1033 INVITE sip:97226491335@example.com SIP/2.0 1034 From: 1035 To: 1037 B->A 1039 SIP/2.0 100 Trying 1041 B->A 1043 SIP/2.0 407 Proxy Authentication Required 1044 Proxy-Authenticate: Digest realm="example.com" 1045 ,nonce="3bada1a0", algorithm="md5" 1046 Content-Length: 0 1048 A->B 1050 ACK sip:97226491335@example.com SIP/2.0 1052 A->B 1054 INVITE sip:97226491335@example.com SIP/2.0 1055 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1056 ,opaque="",realm="example.com" 1057 ,response="f3ce87e6984557cd0fecc26f3c5e97a4" 1058 ,uri="sip:97226491335@10.0.69.38",username="12345678" 1059 From: 1060 To: 1062 B->C 1064 Code = 1 (Access-Request) 1065 Attributes: 1066 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1067 NAS-Port-Type = 5 (Virtual) 1068 User-Name = "12345678" 1069 Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" 1070 Digest-Realm = "example.com" 1071 Digest-Nonce = "3bada1a0" 1072 Digest-Method = "INVITE" 1073 Digest-URI = "sip:97226491335@example.com" 1074 Digest-Algorithm = "md5" 1075 Digest-Username = "12345678" 1076 SIP-AOR = "sip:12345678@example.com" 1078 C->B 1080 Code = 2 (Access-Accept) 1081 Attributes: 1082 Digest-Response-Auth = 1083 "6303c41b0e2c3e524e413cafe8cce954" 1085 B->A 1087 SIP/2.0 180 Ringing 1089 B->A 1091 SIP/2.0 200 OK 1093 A->B 1095 ACK sip:97226491335@example.com SIP/2.0 1097 A second example shows the traffic between a web browser (A), web 1098 server (B) and a RADIUS server (C). 1100 A->B 1102 GET /index.html HTTP/1.1 1104 B->A 1106 HTTP/1.1 407 Authentication Required 1107 WWW-Authenticate: Digest realm="example.com", 1108 domain="/index.html", 1109 nonce="a3086ac8", algorithm="md5" 1110 Content-Length: 0 1112 A->B 1114 GET /index.html HTTP/1.1 1115 Authorization: Digest algorithm="md5",nonce="a3086ac8" 1116 ,opaque="",realm="example.com" 1117 ,response="f052b68058b2987aba493857ae1ab002" 1118 ,uri="/index.html",username="12345678" 1120 B->C 1122 Code = 1 (Access-Request) 1123 Attributes: 1124 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1125 NAS-Port-Type = 5 (Virtual) 1126 User-Name = "12345678" 1127 Digest-Response = "f052b68058b2987aba493857ae1ab002" 1128 Digest-Realm = "example.com" 1129 Digest-Nonce = "a3086ac8" 1130 Digest-Method = "GET" 1131 Digest-URI = "/index.html"" 1132 Digest-Algorithm = "md5" 1133 Digest-Username = "12345678" 1135 C->B 1137 Code = 2 (Access-Accept) 1138 Attributes: 1139 Digest-Response-Auth = 1140 "e644aa513effbfe1caff67103ff6433c" 1142 B->A 1144 HTTP/1.1 200 OK 1145 ... 1147 1148 ... 1150 8. IANA Considerations 1152 This document serves as IANA registration request for a number of 1153 values from the RADIUS attribute type number space: 1155 +-------------------------+------------------------+ 1156 | placeholder | value assigned by IANA | 1157 +-------------------------+------------------------+ 1158 | Digest-Response | TBD | 1159 | Digest-Realm | TBD | 1160 | Digest-Nonce | TBD | 1161 | Digest-Nextnonce | TBD | 1162 | Digest-Response-Auth | TBD | 1163 | Digest-Method | TBD | 1164 | Digest-URI | TBD | 1165 | Digest-Qop | TBD | 1166 | Digest-Algorithm | TBD | 1167 | Digest-Entity-Body-Hash | TBD | 1168 | Digest-CNonce | TBD | 1169 | Digest-Nonce-Count | TBD | 1170 | Digest-Username | TBD | 1171 | Digest-Opaque | TBD | 1172 | Digest-Auth-Param | TBD | 1173 | Digest-AKA-Auts | TBD | 1174 | Digest-Domain | TBD | 1175 | Digest-Stale | TBD | 1176 | Digest-HA1 | TBD | 1177 | SIP-AOR | TBD | 1178 +-------------------------+------------------------+ 1180 Table 2 1182 9. Security Considerations 1184 The RADIUS extensions described in this document enable RADIUS to 1185 transport the data that required to perform a digest calculation. As 1186 a result, RADIUS inherits the vulnerabilities of HTTP Digest (see 1187 [RFC2617], section 4) in addition to RADIUS security vulnerabilities 1188 described in [RFC2865] Section 8 and [RFC3579] Section 4. 1190 An attacker compromising a RADIUS client or proxy can carry out man- 1191 in-the-middle attacks even if the paths between A, B and B, C 1192 (Figure 2) have been secured with TLS or IPsec. 1194 The RADIUS server MUST check the Digest-Realm attribute it has 1195 received from a client. If the RADIUS client is not authorized to 1196 serve HTTP-style clients of that realm, it might be compromised. 1198 RADIUS clients implementing the extension described in this document 1199 may authenticate HTTP-style requests received over the Internet. As 1200 compared with use of RADIUS to authenticate link layer network 1201 access, an attacker may find it easier to cover their tracks in such 1202 a scenario. 1204 An attacker can attempt a denial of service attack on one or more 1205 RADIUS servers by sending a large number of HTTP-style requests. To 1206 make simple denial of service attacks more difficult, the nonce 1207 issuer (RADIUS client or server) MUST check if it has generated the 1208 nonce received from an HTTP-style client. This SHOULD be done 1209 statelessly. For example, a nonce could consist of a 1210 cryptographically random part and some kind of signature provided by 1211 the RADIUS client, as described in [RFC2617], section 3.2.1. 1213 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm 1214 attributes in Access-Challenge messages. A man in the middle can 1215 modify or remove those attributes in a bidding down attack, causing 1216 the RADIUS client to use a weaker authentication scheme than 1217 intended. 1219 The Message-Authenticator attribute, described in [RFC3579] section 1220 3.2 MUST be included in Access-Request, Access-Challenge, Access- 1221 Reject and Access-Accept messages that contain attributes described 1222 in this specification. 1224 The Digest-HA1 attribute contains no random components if the 1225 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1226 attacks easier and enables replay attacks. 1228 HTTP-style clients can use TLS with server side certificates together 1229 with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, 1230 too. TLS or IPsec secure the connection while Digest Authentication 1231 authenticates the user. The RADIUS transaction can be regarded as 1232 one leg on the path between the HTTP-style client and the HTTP-style 1233 server. To prevent RADIUS from representing the weak link, a RADIUS 1234 client receiving an HTTP-style request via TLS or IPsec could use an 1235 equally secure connection to the RADIUS server. There are several 1236 ways to achieve this, for example: 1237 o the RADIUS client may reject HTTP-style requests received over TLS 1238 or IPsec 1239 o the RADIUS client require that traffic be sent and received over 1240 IPsec. 1241 RADIUS over IPsec, if used, MUST conform to the requirements 1242 described in [RFC3579] section 4.2. 1244 10. Acknowledgments 1246 We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or 1247 providing comments and experimental implementation. 1249 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1250 Arkko, Avi Lior and Jun Wang. 1252 11. References 1254 11.1. Normative References 1256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1257 Requirement Levels", BCP 14, RFC 2119, March 1997. 1259 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1260 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1261 Authentication: Basic and Digest Access Authentication", 1262 RFC 2617, June 1999. 1264 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1265 "Remote Authentication Dial In User Service (RADIUS)", 1266 RFC 2865, June 2000. 1268 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1269 A., Peterson, J., Sparks, R., Handley, M., and E. 1270 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1271 June 2002. 1273 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1274 Protocol (HTTP) Digest Authentication Using Authentication 1275 and Key Agreement (AKA)", RFC 3310, September 2002. 1277 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1278 Dial In User Service) Support For Extensible 1279 Authentication Protocol (EAP)", RFC 3579, September 2003. 1281 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1282 RFC 3966, December 2004. 1284 11.2. Informative References 1286 [I-D.ietf-aaa-diameter-sip-app] 1287 Garcia-Martin, M., "Diameter Session Initiation Protocol 1288 (SIP) Application", draft-ietf-aaa-diameter-sip-app-09 1289 (work in progress), September 2005. 1291 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 1292 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 1293 HTTP : Digest Access Authentication", RFC 2069, 1294 January 1997. 1296 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1297 RFC 2246, January 1999. 1299 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1300 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1301 March 1999. 1303 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1304 RFC 2633, June 1999. 1306 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1307 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1309 Appendix A. Change Log 1311 RFC editor: please remove this section prior to RFC publication. 1313 A.1. Changes from draft-ietf-radext-digest-auth-05 1315 o Removed interdependency between sips/https and RADIUS connection 1316 security. 1318 A.2. Changes from draft-ietf-radext-digest-auth-04 1320 o Short Diameter compatibility section 1322 A.3. 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.4. Changes from draft-ietf-radext-digest-auth-02 1332 o added Diameter migration path section (again) 1333 o various typos 1335 A.5. Changes from draft-ietf-radext-digest-auth-01 1336 o removed Diameter migration path section 1337 o Included Digest-URI and Digest-Realm in the authorization 1338 decision, not just in the digest calculation 1339 o RADIUS server must check if a RADIUS client is authorized to serve 1340 the realm mentioned in Digest-Realm 1341 o moved 'Detailed Description' sections in front of 'New RADIUS 1342 attributes' section 1343 o replaced 'IPsec or otherwise secured connection' with IPsec 1344 o changed MAY to SHOULD for Digest-Algorithm in Access-Challenge 1345 o changed type of Digest-Entity-Body-Hash to text (all other H(..) 1346 result attributes are hex and text, too) 1347 o new abstract 1348 o Terminology section changed 1349 o 'Changes' section as appendix 1351 A.6. Changes from draft-ietf-radext-digest-auth-00 1353 o SIP-AOR attribute added 1354 o clarified use of Digest-Qop 1355 o attribute overview table added 1357 A.7. Changes from draft-sterman-aaa-sip-04 1359 o clarified usage of Digest-HA1 1360 o clarified usage of Digest-Stale (is sent in an Access-Challenge 1361 now) 1362 o clarified allowed attribute usage for message types 1363 o changed attribute type to 'Text' where the corresponding Diameter 1364 AVPs have a UTF8String 1365 o added Diameter client - RADIUS server handling 1367 A.8. Changes from draft-sterman-aaa-sip-03 1369 o addressed 'auth-int' issue 1370 o New Digest-Nextnonce attribute 1371 o revised abstract, motivational section and examples 1372 o Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce 1373 attribute' 1374 o shortened SIP messages in example, removed real-world addresses 1375 and product names 1377 A.9. Changes from draft-sterman-aaa-sip-02 1379 o Relaxed restrictions for Digest-Domain, Digest-Realm, Digest- 1380 Opaque, Digest-Qop and Digest-Algorithm 1381 o Additional security considerations for Digest-Domain, Digest-Qop 1382 and Digest-Algorithm usage in Access-Accept messages 1384 A.10. Changes from draft-sterman-aaa-sip-01 1386 o Replaced Sub-attributes with flat attributes 1387 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1388 o Added how a server must treat unknown attributes. 1389 o Added a section 'Migration path to Diameter' 1390 o Added an optional attribute for support of the digest scheme 1391 described in informational [RFC3310]. 1392 o Added a mode of operation where the RADIUS server chooses the 1393 nonce. This was required for AKA [RFC3310], but can be useful for 1394 ordinary Digest Authentication when the qop directive is not used. 1395 This required the addition of several attributes. 1397 Authors' Addresses 1399 Baruch Sterman 1400 Kayote Networks 1401 P.O. Box 1373 1402 Efrat 90435 1403 Israel 1405 Email: baruch@kayote.com 1407 Daniel Sadolevsky 1408 SecureOL, Inc. 1409 Jerusalem Technology Park 1410 P.O. Box 16120 1411 Jerusalem 91160 1412 Israel 1414 Email: dscreat@dscreat.com 1416 David Schwartz 1417 Kayote Networks 1418 P.O. Box 1373 1419 Efrat 90435 1420 Israel 1422 Email: david@kayote.com 1424 David Williams 1425 Cisco Systems 1426 7025 Kit Creek Road 1427 P.O. Box 14987 1428 Research Triangle Park NC 27709 1429 USA 1431 Email: dwilli@cisco.com 1433 Wolfgang Beck 1434 Deutsche Telekom AG 1435 Am Kavalleriesand 3 1436 Darmstadt 64295 1437 Germany 1439 Email: beckw@t-systems.com 1441 Intellectual Property Statement 1443 The IETF takes no position regarding the validity or scope of any 1444 Intellectual Property Rights or other rights that might be claimed to 1445 pertain to the implementation or use of the technology described in 1446 this document or the extent to which any license under such rights 1447 might or might not be available; nor does it represent that it has 1448 made any independent effort to identify any such rights. Information 1449 on the procedures with respect to rights in RFC documents can be 1450 found in BCP 78 and BCP 79. 1452 Copies of IPR disclosures made to the IETF Secretariat and any 1453 assurances of licenses to be made available, or the result of an 1454 attempt made to obtain a general license or permission for the use of 1455 such proprietary rights by implementers or users of this 1456 specification can be obtained from the IETF on-line IPR repository at 1457 http://www.ietf.org/ipr. 1459 The IETF invites any interested party to bring to its attention any 1460 copyrights, patents or patent applications, or other proprietary 1461 rights that may cover technology that may be required to implement 1462 this standard. Please address the information to the IETF at 1463 ietf-ipr@ietf.org. 1465 Disclaimer of Validity 1467 This document and the information contained herein are provided on an 1468 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1469 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1470 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1471 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1472 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1473 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1475 Copyright Statement 1477 Copyright (C) The Internet Society (2005). This document is subject 1478 to the rights, licenses and restrictions contained in BCP 78, and 1479 except as set forth therein, the authors retain all their rights. 1481 Acknowledgment 1483 Funding for the RFC Editor function is currently provided by the 1484 Internet Society.