idnits 2.17.1 draft-ietf-radext-digest-auth-04.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 1464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1454. ** 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 (August 30, 2005) is 6814 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 1009, but not defined == Missing Reference: 'Note 2' is mentioned on line 1011, but not defined == Missing Reference: 'Note 3' is mentioned on line 1013, but not defined == Unused Reference: 'RFC2616' is defined on line 1250, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 1286, but no explicit reference was found in the text ** 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 1750 (Obsoleted by RFC 4086) -- 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 (~~), 10 warnings (==), 13 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 3, 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 August 30, 2005 14 RADIUS Extension for Digest Authentication 15 draft-ietf-radext-digest-auth-04.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 3, 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. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 23 86 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 94 A.1. Changes from draft-ietf-radext-digest-auth-03 . . . . . . 31 95 A.2. Changes from draft-ietf-radext-digest-auth-02 . . . . . . 31 96 A.3. Changes from draft-ietf-radext-digest-auth-01 . . . . . . 32 97 A.4. Changes from draft-ietf-radext-digest-auth-00 . . . . . . 32 98 A.5. Changes from draft-sterman-aaa-sip-04 . . . . . . . . . . 32 99 A.6. Changes from draft-sterman-aaa-sip-03 . . . . . . . . . . 32 100 A.7. Changes from draft-sterman-aaa-sip-02 . . . . . . . . . . 32 101 A.8. Changes from draft-sterman-aaa-sip-01 . . . . . . . . . . 33 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 103 Intellectual Property and Copyright Statements . . . . . . . . . . 35 105 1. Introduction 107 1.1. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 The use of normative requirement key words in this document shall 114 apply only to RADIUS Client and RADIUS Server implementations that 115 include the features described in this document. This document 116 creates no normative requirements for existing implementations. 118 HTTP-style protocol 119 The term 'HTTP-style' denotes any protocol that uses HTTP-like 120 headers and uses HTTP digest authentication as described in 121 [RFC2617]. Examples are HTTP and SIP. 122 NAS 123 Network Access Server, the RADIUS client. 124 nonce 125 An unpredictable value used to prevent replay attacks. The 126 nonce generator may use cryptographic mechanisms to produce 127 nonces it can recognize without maintaining state. 128 protection space 129 The combination of realm and digest URI, the use of which is 130 authorized by the RADIUS server. 131 SIP UA 132 SIP User Agent, an Internet endpoint that uses the Session 133 Initiation Protocol. 134 SIP UAS 135 SIP User Agent Server, a logical entity that generates a 136 response to a SIP (Session Initiation Protocol) request. 138 1.2. Motivation 140 The HTTP Digest Authentication mechanism, defined in [RFC2617], was 141 subsequently adapted to use with SIP in [RFC2543] (obsoleted by 142 [RFC3261]). Due to the limitations and weaknesses of Digest 143 Authentication (see [RFC2617], section 4), additional authentication 144 and encryption mechanisms are defined in SIP [RFC3261], including TLS 145 [RFC2246] and S/MIME [RFC2633]. However, Digest Authentication has 146 been widely implemented within SIP clients and to support those 147 clients there is a need for support of Digest Authentication within 148 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC3588]. 150 This document defines an extension to the RADIUS protocol to enable 151 support of Digest Authentication, for use with SIP, HTTP, and other 152 HTTP-style protocols using this authentication method. Support for 153 Digest mechanisms such as AKA [RFC3310] is also supported. A 154 companion document [I-D.ietf-aaa-diameter-sip-app] defines support 155 for Digest Authentication within Diameter. 157 1.3. Overview 159 HTTP digest is a challenge-response protocol used to authenticate a 160 client's request to access some resource on a server. Figure 1 shows 161 a single HTTP digest transaction. 163 HTTP/SIP.. 164 +------------+ (1) +------------+ 165 | |--------->| | 166 | HTTP-style | (2) | HTTP-style | 167 | Client |<---------| server | 168 | | (3) | | 169 | |--------->| | 170 | | (4) | | 171 | |<---------| | 172 +------------+ +------------+ 174 Figure 1: digest operation without RADIUS 176 If the client sends a request without any credentials (1), the server 177 will reply with an error response (2) containing a nonce. The client 178 creates a cryptographic digest from parts of the request, from the 179 nonce it received from the server, and a shared secret. The client 180 re-transmits the request (3) to the server, but now includes the 181 digest within the packet. The server does the same digest 182 calculation as the client and compares the result with the digest it 183 received in (3). If the digest values are identical, the server 184 grants access to the resource and sends a positive response to the 185 client (4). If the digest values differ, the server sends a negative 186 response to the client (4). 188 Instead of maintaining a local user database, the server could use 189 RADIUS to access a centralized user database. However, RADIUS 190 [RFC2865] does not include support for HTTP digest authentication. 191 The RADIUS client can not use the User-Password attribute, since it 192 does not receive a password from the HTTP-style client. The CHAP- 193 Challenge and CHAP-Password attributes are also not suitable since 194 the CHAP algorithm is not compatible with HTTP digest. 196 This document defines new attributes that enable the RADIUS server to 197 perform the digest calculation defined in [RFC2617], providing 198 support for Digest Authentication as a native authentication 199 mechanism within RADIUS. 201 This document defines new attributes that enable the RADIUS server to 202 perform the digest calculation defined in [RFC2617]. 204 The nonces required by the digest algorithm are either generated by 205 the RADIUS client or by the RADIUS server. A mix of nonce generation 206 modes is not supported. This specification assumes that both the 207 RADIUS client and server are appropriately configured to generate the 208 nonces in either the RADIUS client or the RADIUS server, but not in 209 both at the same time. Implementations, though, do not have the 210 means to verify this behavior. 212 1.3.1. Scenario 1, RADIUS client chooses nonces 214 HTTP/SIP RADIUS 216 +-----+ (1) +-----+ +-----+ 217 | |==========>| | | | 218 | | (2) | | | | 219 | |<==========| | | | 220 | | (3) | | | | 221 | |==========>| | | | 222 | A | | B | (4) | C | 223 | | | |---------->| | 224 | | | | (5) | | 225 | | | |<----------| | 226 | | (6) | | | | 227 | |<==========| | | | 228 +-----+ +-----+ +-----+ 230 ====> HTTP/SIP 231 ----> RADIUS 233 Figure 2: RADIUS client chooses nonces 235 The roles played by the entities in this scenario are as follows: 237 A: HTTP client / SIP UA 239 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 240 acting also as a RADIUS NAS (RADIUS client) 242 C: RADIUS server 244 The relevant order of messages sent in this scenario is as follows: 246 A sends B an HTTP/SIP request without authorization header (step 1). 247 B challenges A sending an HTTP/SIP "407 / 401 (Proxy) Authorization 248 required" response containing a locally generated nonce (step 2). A 249 sends B an HTTP/SIP request with authorization header (step 3). B 250 sends C a RADIUS Access-Request with attributes described in this 251 document (step 4). C responds to B with a RADIUS Access-Accept/ 252 Access-Reject response (step 5). If credentials were accepted, B 253 receives an Access-Accept response and the message sent from A is 254 considered authentic. If B receives an Access-Reject response, 255 however, B then responds to A with a "407 / 401 (Proxy) Authorization 256 required" response (step 6). 258 1.3.2. Scenario 2, RADIUS server chooses nonces 260 While the usage scenario described in Section 1.3.1 minimizes the 261 load on the RADIUS server, alternatives are required in some 262 situations. When using AKA [RFC3310] the nonce is partially derived 263 from a precomputed authentication vector, which is often stored 264 centrally. 266 Figure 3 depicts a scenario in which the RADIUS server chooses 267 nonces. In this case entities A and B communicate using HTTP or SIP, 268 while entities B and C communicate using RADIUS." 269 HTTP/SIP RADIUS 271 +-----+ (1) +-----+ +-----+ 272 | |==========>| | (2) | | 273 | | | |---------->| | 274 | | | | (3) | | 275 | | (4) | |<----------| | 276 | |<==========| | | | 277 | | (5) | | | | 278 | |==========>| | | | 279 | A | | B | (6) | C | 280 | | | |---------->| | 281 | | | | (7) | | 282 | | | |<----------| | 283 | | (8) | | | | 284 | |<==========| | | | 285 +-----+ +-----+ +-----+ 287 ====> HTTP/SIP 288 ----> RADIUS 290 Figure 3: RADIUS server chooses nonces 292 The roles played by the entities in this scenario are as follows: 294 A: HTTP client / SIP UA 296 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 297 acting also as a RADIUS NAS 299 C: RADIUS server 301 The following messages are sent in this scenario: 303 A sends B an HTTP/SIP request without an authorization header (step 304 1). B sends an Access-Request packet with the newly defined Digest- 305 Method and Digest-URI attributes but without a Digest-Nonce attribute 306 to the RADIUS server, C (step 2). C chooses a nonce and responds 307 with an Access-Challenge (step 3). This Access-Challenge contains 308 Digest attributes, from which B takes values to construct an HTTP/SIP 309 "(Proxy) Authorization required" response. The remaining steps are 310 identical with scenario 1 (Section 1.3.1): B sends this response to A 311 (step 4). A resends its request with its credentials (step 5). B 312 sends an Access-Request to C (step 6). C checks the credentials and 313 replies with Access-Accept or Access-Reject (step 7). Dependent on 314 the C's result, B processes A's request or rejects it with a "(Proxy) 315 Authorization required" response (step 8). 317 2. Interoperability 319 An implementation supporting this extension MUST include a Digest- 320 Response attribute within an Access-Request packet where Digest 321 Authentication is desired. An Access-Request MUST NOT contain both a 322 Digest-Response attribute and another authentication attribute, such 323 as User-Password, CHAP-Password, or EAP-Message. 325 RADIUS clients and servers MUST support both nonce generation modes. 326 As there is no automatic capability exchange, the operator MUST make 327 sure that the RADIUS client software uses the correct nonce 328 generation mode when accessing a specific RADIUS server: 329 o If the RADIUS server generates nonces, its RADIUS clients MUST NOT 330 try to generate nonces. 331 o If the RADIUS server does not generate nonces, its RADIUS clients 332 MUST generate nonces locally. 333 o If at least one HTTP-style client requires AKA authentication 334 [RFC3310], the RADIUS server MUST generate nonces and its RADIUS 335 clients MUST NOT generate nonces locally. 336 RADIUS implementations MUST offer respective configuration options. 338 3. Detailed Description 340 3.1. RADIUS Client Behavior 342 The attributes described in this document are sent in cleartext. 343 Therefore were a RADIUS client to accept secured connections (https 344 or sips) from HTTP-style clients, this could result in information 345 intentionally protected by HTTP-style clients being sent in the clear 346 during the RADIUS exchange. 348 If the packets between RADIUS client and RADIUS server are not 349 protected with IPsec, the RADIUS client MUST NOT accept secured 350 connections (like https or sips) from its HTTP-style clients, so that 351 HTTP-style clients are not provided with a false sense of security. 353 On reception of an HTTP-style request message, the RADIUS client 354 checks whether it is authorized to authenticate the request. Where 355 an HTTP-style request traverses several proxies and each of the 356 proxies requests to authenticate the HTTP-style client, the request 357 at the HTTP-style server may contain multiple credential sets. 359 The RADIUS client can use the 'realm' directive in HTTP to determine 360 which credentials are applicable. Where none of the realms are of 361 interest, the RADIUS client MUST behave as though no relevant 362 credentials were sent. In all situations the RADIUS client MUST send 363 zero or exactly one credential to the RADIUS server. The RADIUS 364 client MUST choose the credential of the (Proxy-)Authorization header 365 if the realm directive matches its locally configured realm. 367 If such a (Proxy-)Authorization header is present and contains HTTP 368 digest information, the RADIUS client checks the 'nonce' parameter. 369 If the RADIUS client generates nonces but did not issue the received 370 nonce, it responds with a 401 (Unauthorized) or 407 (Proxy 371 Authentication Required) to the HTTP-style client. In this error 372 response, the RADIUS client sends a new nonce. 374 If the RADIUS client recognizes the nonce or does not generate 375 nonces, it takes the header directives and puts them into a RADIUS 376 Access-Request packet. It puts the 'response' directive into a 377 Digest-Response attribute and the realm / nonce / digest-uri / qop / 378 algorithm / cnonce / nc / username / opaque directives into the 379 respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / 380 Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- 381 Username / Digest-Opaque attributes. The request method is put into 382 the Digest-Method attribute. The RADIUS client adds a Message- 383 Authenticator attribute, defined in [RFC3579] and sends the Access- 384 Request packet to the RADIUS server. 386 The RADIUS server processes the packet and responds with an Access- 387 Accept or an Access-Reject. 389 The RADIUS client constructs an Authentication-Info header: 390 o If the Access-Accept packet contains a Digest-Response-Auth 391 attribute, the RADIUS client checks the Digest-Qop attribute: 392 * If the Digest-Qop attribute's value is 'auth' or not specified, 393 the RADIUS client puts the Digest-Response-Auth attribute's 394 content into the Authentication-Info header's 'rspauth' 395 directive of the HTTP-style response. 396 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 397 client ignores the Access-Accept packet and behaves like it had 398 received an Access-Reject packet (Digest-Response-Auth can't be 399 correct as the RADIUS server does not know the contents of the 400 HTTP-style response's body). 401 o If the Access-Accept packet contains a Digest-HA1 attribute, the 402 RADIUS client checks the 'qop' and 'algorithm' directives in the 403 Authorization header of the HTTP-style request it wants to 404 authorize: 405 * If the 'qop' directive is missing or its value is 'auth', the 406 RADIUS client ignores the Digest-HA1 attribute. It does not 407 include an Authentication-Info header into its HTTP-style 408 response. 410 * If the 'qop' directive's value is 'auth-int' and at least one 411 of the following conditions is true, the RADIUS client 412 calculates the contents of the HTTP-style response's 'rspauth' 413 directive: 414 + The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5- 415 sess'. 416 + The packets between RADIUS client and RADIUS server are 417 protected with IPsec (see Section 8). 418 It creates the HTTP-style response message and calculates the 419 hash of this message's body. It uses the result and the 420 Digest-URI attribute's value of the corresponding Access- 421 Request packet to perform the H(A2) calculation. It takes the 422 Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop 423 values of the corresponding Access-Request and the Digest-HA1 424 attribute's value to finish the computation of the 'rspauth' 425 value. 426 o If the Access-Accept packet contains neither a Digest-Response- 427 Auth nor a Digest-HA1 attribute, the RADIUS client will not create 428 an Authentication-Info header for its HTTP-style response. 430 The RADIUS server MAY have added a Digest-Nextnonce attribute into an 431 Access-Accept packet. If the RADIUS client discovers this, it puts 432 the contents of this attribute into a 'nextnonce' directive. Now it 433 can send an HTTP-style response. 435 If the RADIUS client did receive an HTTP-style request without a 436 (Proxy-)Authorization header matching its locally configured realm 437 value, it obtains a new nonce and sends an error response (401 or 438 407) containing a (Proxy-)Authenticate header. 440 If the RADIUS client receives an Access-Reject from the RADIUS 441 server, it sends an error response to the HTTP-style request it has 442 received. If the RADIUS client does not receive a response, it 443 retransmits or fails over to another RADIUS server as described in 444 [RFC2865]. 446 The RADIUS client has three ways to obtain nonces: it generates them 447 locally, it has received one in a Digest-Nextnonce attribute of a 448 previously received Access-Accept packet, or it asks the RADIUS 449 server for one. To do the latter, it sends an Access-Request 450 containing a Digest-Method and a Digest-URI attribute but without a 451 Digest-Nonce attribute. It adds a Message-Authenticator (see 452 [RFC3579]) attribute to the Access-Request packet. The RADIUS server 453 chooses a nonce and responds with an Access-Challenge containing a 454 Digest-Nonce attribute. 456 The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- 457 Realm, Digest-Domain and Digest-Opaque attributes in the Access- 458 Challenge carrying the nonce. If these attributes are present, the 459 client MUST use them. 461 If the RADIUS client receives an Access-Challenge packet in response 462 to an Access-Request containing a Digest-Nonce attribute, the RADIUS 463 server did not accept the nonce. If a Digest-Stale attribute is 464 present in the Access-Challenge and has a value of 'true' (without 465 quotes), the RADIUS client sends an error (401 or 407) response 466 containing WWW-/Proxy-Authenticate header with the directive 'stale' 467 and the digest directives derived from the Digest-* attributes. 469 3.2. RADIUS Server Behavior 471 If the RADIUS server receives an Access-Request packet with a Digest- 472 Method and a Digest-URI attribute but without a Digest-Nonce 473 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 474 attribute and sends it in an Access-Challenge packet to the RADIUS 475 client. The RADIUS server MUST add Digest-Realm, Message- 476 Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or 477 more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes 478 to the Access-Challenge packet. If the server cannot choose a nonce, 479 it replies with an Access-Reject packet. 481 If the RADIUS server receives an Access-Request packet containing a 482 Digest-Response attribute, it looks for the following attributes: 483 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, 484 Digest-Algorithm, Digest-Username. Depending on the content of 485 Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- 486 Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and 487 [RFC3310] for details. If the Digest-Algorithm attribute is missing, 488 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque 489 attribute along with the nonce, the Access-Request MUST have a 490 matching Digest-Opaque attribute. 492 If mandatory attributes are missing, it MUST respond with an Access- 493 Reject packet. If the attributes are present, the RADIUS server 494 calculates the digest response as described in [RFC2617]. To look up 495 the password, the RADIUS server uses the RADIUS User-Name attribute. 496 The RADIUS server MUST check if the user identified by the User-Name 497 attribute 498 o is authorized to access the protection space defined by the 499 Digest-URI and Digest-Realm attributes, 500 o is authorized to use the URI included in the SIP-AOR attribute, if 501 this attribute is present. 502 If any of those checks fails, the RADIUS server MUST send an Access- 503 Reject. 505 Correlation between User-Name and SIP-AOR AVP values is required just 506 to avoid that any user can register or misuse a SIP-AOR allocated to 507 another user. 509 A RADIUS server MUST check if the RADIUS client is authorized to 510 serve users of the realm mentioned in the Digest-Realm attribute. If 511 the RADIUS client is not authorized, the RADIUS server MUST send an 512 Access-Reject. The RADIUS server SHOULD log the event so as to 513 notify the operator, and MAY take additional action such as sending 514 an Access-Reject in response to all future requests from this client, 515 until this behavior is reset by management action. 517 All values required for the digest calculation are taken from the 518 Digest attributes described in this document. If the calculated 519 digest response equals the value received in the Digest-Response 520 attribute, the authentication was successful. If not, the RADIUS 521 server responds with an Access-Reject. 523 If the authentication was successful, the RADIUS server adds an 524 attribute to the Access-Accept packet which can be used by the RADIUS 525 client to construct an Authentication-Info header: 526 o If the Digest-Qop attribute's value is 'auth' or unspecified, the 527 RADIUS server SHOULD put a Digest-Response-Auth attribute into the 528 Access-Accept packet 529 o If the Digest-Qop attribute's value is 'auth-int' and at least one 530 of the following conditions is true, the RADIUS server SHOULD put 531 a Digest-HA1 attribute into the Access-Accept packet: 532 * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- 533 MD5-sess'. 534 * The packets between RADIUS client and RADIUS server are 535 protected with IPsec (see Section 8). 536 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be 537 sent. 539 RADIUS servers issuing nonces MAY construct a Digest-Nextnonce 540 attribute and add it to the Access-Accept packet. This is useful to 541 limit the lifetime of a nonce and to save a round-trip in future 542 requests (see nextnonce discussion in [RFC2617], section 3.2.3). The 543 RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) 544 and sends the Access-Accept packet to the RADIUS client. 546 If the RADIUS server does not accept the nonce received in an Access- 547 Request packet but authentication was successful, the RADIUS server 548 MUST send an Access-Challenge packet containing a Digest-Stale 549 attribute set to 'true' (without quotes). The RADIUS server MUST add 550 Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm, 551 SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add 552 Digest-Domain, Digest-Opaque attributes to the Access-Challenge 553 packet. 555 4. New RADIUS attributes 557 If not stated otherwise, the attributes have the following format: 559 0 1 2 560 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type | Length | Text ... 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 4.1. Digest-Response attribute 567 Description 568 If this attribute is present in an Access-Request message, a 569 RADIUS server implementing this specification MUST treat the 570 Access-Request as a request for Digest Authentication. When a 571 RADIUS client receives a (Proxy-)Authorization header, it puts 572 the request-digest value into a Digest-Response attribute. 573 This attribute (which enables the user to prove possession of 574 the password) MUST only be used in Access-Requests. 575 Type 576 [IANA: use 102 if possible] for Digest-Response. 577 Length 578 >= 3 579 Text 580 When using HTTP digest, the text field is 32 octets long and 581 contains a hexadecimal representation of 16 octet digest value 582 as it was calculated by the authenticated client. Other digest 583 algorithms MAY define different digest lengths. The text field 584 MUST be copied from request-digest of digest-response 585 ([RFC2617]) without quotes. 587 4.2. Digest-Realm attribute 589 Description 590 This attribute describes a protection space of the RADIUS 591 server. See [RFC2617] 1.2 for details. It MUST only be used 592 in Access-Request and Access-Challenge packets. 593 Type 595 [IANA: use 103 if possible] for Digest-Realm 596 Length 597 >=3 598 Text 599 In Access-Requests, the RADIUS client takes the value of the 600 realm directive (realm-value according to [RFC2617]) without 601 quotes from the HTTP-style request it wants to authenticate. 602 In Access-Challenge packets, the RADIUS server puts the 603 expected realm value into this attribute. 605 4.3. Digest-Nonce attribute 607 Description 608 This attribute holds a nonce to be used in the HTTP Digest 609 calculation. If the Access-Request had a Digest-Method and a 610 Digest-URI but no Digest-Nonce attribute and the RADIUS server 611 is configured to choose nonces, it MUST put a Digest-Nonce 612 attribute into its Access-Challenge packet. This attribute 613 MUST only be used in Access-Request and Access-Challenge 614 packets. 615 Type 616 [IANA: use 104 if possible] for Digest-Nonce 617 Length 618 >=3 619 Text 620 In Access-Requests, the RADIUS client takes the value of the 621 nonce directive (nonce-value in [RFC2617]) without quotes from 622 the HTTP-style request it wants to authenticate. In Access- 623 Challenge packets, the attribute contains the nonce selected by 624 the RADIUS server. 626 4.4. Digest-Response-Auth attribute 628 Description 629 This attribute enables the RADIUS server to prove possesion of 630 the password. If the previously received Digest-Qop attribute 631 was 'auth-int' (without quotes), the RADIUS server MUST send a 632 Digest-HA1 attribute instead of a Digest-Response-Auth 633 attribute. The Digest-Response-Auth attribute MUST only be 634 used in Access-Accept packets. The RADIUS client puts the 635 attribute value without quotes into the rspauth directive of 636 the Authentication-Info header. 637 Type 638 [IANA: use 105 if possible] for Digest-Response-Auth. 640 Length 641 >= 3 642 Text 643 The RADIUS server calculates a digest according to section 644 3.2.3 of [RFC2617] and copies the result into this attribute. 645 Other digest algorithms than the one defined in [RFC2617] MAY 646 define digest lengths other than 32. 648 4.5. Digest-Nextnonce attribute 650 This attribute holds a nonce to be used in the HTTP Digest 651 calculation. 653 Description 654 If the RADIUS server is configured to choose nonces it MAY put 655 a Digest-Nextnonce attribute into an Access-Accept packet. If 656 this attribute is present, the RADIUS client MUST put the 657 contents of this attribute into the nextnonce directive of an 658 Authentication-Info header in its HTTP-style response. This 659 attribute MUST only be used in Access-Accept packets. 660 Type 661 [IANA: use 106 if possible] for Digest-Nextnonce 662 Length 663 >=3 664 Text 665 It is recommended that this text be base64 or hexadecimal data. 667 4.6. Digest-Method attribute 669 Description 670 This attribute holds the method value to be used in the HTTP 671 Digest calculation. This attribute MUST only be used in 672 Access-Request packets. 673 Type 674 [IANA: use 107 if possible] for Digest-Method 675 Length 676 >=3 677 Text 678 In Access-Requests, the RADIUS client takes the value of the 679 request method from the HTTP-style request it wants to 680 authenticate. 682 4.7. Digest-URI attribute 683 Description 684 This attribute is used to transport the contents of the digest- 685 uri directive or the URI of the HTTP-style request. It MUST 686 only be used in Access-Request packets. 687 Type 688 [IANA: use 108 if possible] for Digest-URI 689 Length 690 >=3 691 Text 692 If the HTTP-style request has an Authorization header, the 693 RADIUS client puts the value of the "uri" directive in the 694 (known as "digest-uri-value" in section 3.2.2 of [RFC2617]) 695 without quotes into this attribute. If there is no 696 Authorization header, the RADIUS client takes the value of the 697 request URI from the HTTP-style request it wants to 698 authenticate. 700 4.8. Digest-Qop attribute 702 Description 703 This attribute holds the Quality of Protection parameter that 704 influences the HTTP Digest calculation. This attribute MUST 705 only be used in Access-Request and Access-Challenge packets. A 706 RADIUS client SHOULD insert one of the Digest-Qop attributes it 707 has received in a previous Access-Challenge packet. RADIUS 708 servers SHOULD insert at least one Digest-Qop attribute in an 709 Access-Challenge packet. Digest-Qop is optional in order to 710 preserve backward compatibility with a minimal implementation 711 of [RFC2069]. 712 Type 713 [IANA: use 109 if possible] for Digest-Qop 714 Length 715 >=3 716 Text 717 In Access-Requests, the RADIUS client takes the value of the 718 qop directive (qop-value as described in [RFC2617]) without the 719 quotes from the HTTP-style request it wants to authenticate. 720 In Access-Challenge packets, the RADIUS server puts a desired 721 qop-value into this attribute. If the RADIUS server supports 722 more than one "quality of protection" value, it puts each qop- 723 value into a separate Digest-Qop attribute. 725 4.9. Digest-Algorithm attribute 726 Type 727 This attribute holds the algorithm parameter that influences 728 the HTTP Digest calculation. It MUST only be used in Access- 729 Request and Access-Challenge packets. If this attribute is 730 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 770 Description 771 This attribute holds the client nonce parameter that is used in 772 the HTTP Digest calculation. It MUST only be used in Access- 773 Request packets. 774 Type 775 [IANA: use 112 if possible] for Digest-CNonce 776 Length 777 >=3 778 Text 779 This attribute includes the value of the cnonce-value [RFC2617] 780 without quotes, taken from the HTTP-style request. 782 4.12. Digest-Nonce-Count attribute 784 Description 785 This attribute includes the nonce count parameter that is used 786 to detect replay attacks. The attribute MUST only be used in 787 Access-Request packets. 788 Type 789 [IANA: use 113 if possible] for Digest-Nonce-Count 790 Length 791 10 792 Text 793 In Access-Requests, the RADIUS client takes the value of the nc 794 directive (nc-value according to [RFC2617]) without quotes from 795 the HTTP-style request it wants to authenticate. 797 4.13. Digest-Username attribute 799 Description 800 This attribute holds the user name used in the HTTP digest 801 calculation. The RADIUS server MUST use this attribute only 802 for the purposes of calculating the digest. In order to 803 determine the appropriate user credentials, the RADIUS server 804 MUST use the User-Name (1) attribute, and MUST NOT use the 805 Digest-Username attribute. This attribute MUST only be used in 806 Access-Request packets. 807 Type 808 [IANA: use 114 if possible] for Digest-Username 809 Length 810 >= 3 811 Text 812 In Access-Requests, the RADIUS client takes the value of the 813 username directive (username-value according to [RFC2617]) 814 without quotes from the HTTP-style request it wants to 815 authenticate. 817 4.14. Digest-Opaque attribute 819 Description 820 This attribute holds the opaque parameter that is passed to the 821 HTTP-style client. The HTTP-style client will pass this value 822 back to the server (ie the RADIUS client) without modification. 823 This attribute is only used when the RADIUS server chooses 824 nonces and MUST only be used in Access-Request and Access- 825 Challenge packets. 826 Type 827 [IANA: use 115 if possible] for Digest-Opaque 828 Length 829 >=3 830 Text 831 In Access-Requests, the RADIUS client takes the value of the 832 opaque directive (opaque-value according to [RFC2617]) without 833 quotes from the HTTP-style request it wants to authenticate and 834 puts it into this attribute. In Access-Challenge packets, the 835 RADIUS server MAY include this attribute. 837 4.15. Digest-Auth-Param attribute 839 Description 840 This attribute is a placeholder for future extensions and 841 corresponds to the "auth-param" parameter defined in section 842 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism 843 whereby the RADIUS client and RADIUS server can exchange auth- 844 param extension parameters contained within Digest headers that 845 are not understood by the RADIUS client and for which there are 846 no corresponding stand-alone attributes. 847 Unlike the previously listed Digest-* attributes, the Digest- 848 Auth-Param contains not only the value, but also the parameter 849 name, since the parameter name is unknown to the RADIUS client. 850 If the Digest header contains several unknown parameters, then 851 the RADIUS implementation MUST repeat this attribute and each 852 instance MUST contain one different unknown Digest parameter/ 853 value combination. This attribute MUST ONLY be used in Access- 854 Request, Access-Challenge, or Access-Accept packets. 855 Type 856 [IANA: use 116 if possible] for Digest-Auth-Param 857 Length 858 >=3 859 Text 860 The text consists of the whole parameter, including its name 861 and the equal ('=') sign and quotes. 863 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. 913 Type 914 [IANA: use 119 if possible] for Digest-Stale 915 Length 916 3 917 Text 918 The attribute has either the value 'true' or 'false' (both 919 values without quotes). 921 4.19. Digest-HA1 attribute 923 Description 924 This attribute is used to allow the generation of an 925 Authentication-Info header, even if the HTTP-style response's 926 body is required for the calculation of the rspauth value. It 927 SHOULD be used in Access-Accept packets if the required quality 928 of protection ('qop') is 'auth-int'. 929 This attribute MUST NOT be sent if the qop parameter was not 930 specified or has a value of 'auth' (in this case, use Digest- 931 Response-Auth instead). 932 The Digest-HA1 attribute MUST only be sent by the RADIUS server 933 or processed by the RADIUS client if at least one of the 934 following conditions is true: 935 + The Digest-Algorithm attribute's value is 'MD5-sess' or 936 'AKAv1-MD5-sess'. 937 + The packets between RADIUS client and RADIUS server are 938 protected with IPsec (see Section 8). 939 This attribute MUST only be used in Access-Accept packets. 940 Type 941 [IANA: use 120 if possible] for Digest-HA1 942 Length 943 >= 3 944 Text 945 This attribute contains the hexadecimal representation of H(A1) 946 as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2. 948 4.20. SIP-AOR 950 Type 951 This attribute is used for the authorization of SIP messages. 952 The SIP-AOR attribute identifies the URI the use of which must 953 be authenticated and authorized. The RADIUS server uses this 954 attribute to authorize the processing of the SIP request. The 955 SIP-AOR can be derived from, e.g., the To header field in a SIP 956 REGISTER request (user under registration), or the From header 957 field in other SIP requests. However, the exact mapping of 958 this attribute to SIP can change due to new developments in the 959 protocol. This attribute MUST only be used when the RADIUS 960 client wants to authorize SIP users and MUST only be used in 961 Access-Request packets. 962 Type 963 [IANA:use 121 if possible] for SIP-AOR 964 Length 965 >=3 966 Text 967 The syntax of this attribute corresponds either to a SIP URI 968 (with the format defined in [RFC3261] or a TEL URI (with the 969 format defined in [RFC3966]). 970 The SIP-AOR attribute holds the complete URI, including 971 parameters and other parts. It is up to the RADIUS server what 972 components of the URI are regarded in the authorization 973 decision. 975 5. Table of Attributes 977 The following table provides a guide to which attributes may be found 978 in which kinds of packets, and in what quantity. 980 Req Accept Reject Challenge # Attribute 981 1 0 0 0 TBD User-Name 982 1 1 1 1 TBD Message-Authenticator 983 0-1 0 0 0 TBD Digest-Response 984 0-1 0 0 1 TBD Digest-Realm 985 0-1 0 0 1 TBD Digest-Nonce 986 0 0-1 0 0 TBD Digest-Response-Auth 987 (see Note 1, 2) 988 0 0-1 0 0 TBD Digest-Nextnonce 989 0-1 0 0 0 TBD Digest-Method 990 0-1 0 0 0 TBD Digest-URI 991 0-1 0 0 1+ TBD Digest-Qop 992 0-1 0 0 0-1 TBD Digest-Algorithm (see 993 Note 3) 994 0-1 0 0 0 TBD Digest-Entity-Body-Hash 995 0-1 0 0 0 TBD Digest-CNonce 996 0-1 0 0 0 TBD Digest-Nonce-Count 997 0-1 0 0 0 TBD Digest-Username 998 0-1 0 0 0-1 TBD Digest-Opaque 999 0+ 0+ 0 0+ TBD Digest-Auth-Param 1000 0-1 0 0 0 TBD Digest-AKA-Auts 1001 0 0 0 0+ TBD Digest-Domain 1002 0 0 0 0-1 TBD Digest-Stale 1003 0 0-1 0 0 TBD Digest-HA1 (see Note 1, 1004 2) 1005 0-1 0 0 0 TBD SIP-AOR 1007 Table 1 1009 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if 1010 Digest-Qop is 'auth-int'. 1011 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if 1012 Digest-Qop is 'auth'. 1013 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed 1015 6. Example 1017 This is an example sniffed from the traffic between a softphone (A), 1018 a Proxy Server (B) and example.com RADIUS server (C). The 1019 communication between the Proxy Server and a SIP PSTN gateway is 1020 omitted for brevity. The SIP messages are not shown completely. 1022 A->B 1024 INVITE sip:97226491335@example.com SIP/2.0 1025 From: 1026 To: 1028 B->A 1030 SIP/2.0 100 Trying 1032 B->A 1034 SIP/2.0 407 Proxy Authentication Required 1035 Proxy-Authenticate: Digest realm="example.com" 1036 ,nonce="3bada1a0", algorithm="md5" 1037 Content-Length: 0 1039 A->B 1041 ACK sip:97226491335@example.com SIP/2.0 1043 A->B 1045 INVITE sip:97226491335@example.com SIP/2.0 1046 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1047 ,opaque="",realm="example.com" 1048 ,response="f3ce87e6984557cd0fecc26f3c5e97a4" 1049 ,uri="sip:97226491335@10.0.69.38",username="12345678" 1050 From: 1051 To: 1053 B->C 1055 Code = 1 (Access-Request) 1056 Attributes: 1057 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1058 NAS-Port-Type = 5 (Virtual) 1059 User-Name = "12345678" 1060 Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" 1061 Digest-Realm = "example.com" 1062 Digest-Nonce = "3bada1a0" 1063 Digest-Method = "INVITE" 1064 Digest-URI = "sip:97226491335@example.com" 1065 Digest-Algorithm = "md5" 1066 Digest-Username = "12345678" 1067 SIP-AOR = "sip:12345678@example.com" 1069 C->B 1071 Code = 2 (Access-Accept) 1072 Attributes: 1073 Digest-Response-Auth = 1074 "6303c41b0e2c3e524e413cafe8cce954" 1076 B->A 1078 SIP/2.0 180 Ringing 1080 B->A 1082 SIP/2.0 200 OK 1084 A->B 1086 ACK sip:97226491335@example.com SIP/2.0 1088 A second example shows the traffic between a web browser (A), web 1089 server (B) and a RADIUS server (C). 1091 A->B 1093 GET /index.html HTTP/1.1 1095 B->A 1097 HTTP/1.1 407 Authentication Required 1098 WWW-Authenticate: Digest realm="example.com", 1099 domain="/index.html", 1100 nonce="a3086ac8", algorithm="md5" 1101 Content-Length: 0 1103 A->B 1105 GET /index.html HTTP/1.1 1106 Authorization: Digest algorithm="md5",nonce="a3086ac8" 1107 ,opaque="",realm="example.com" 1108 ,response="f052b68058b2987aba493857ae1ab002" 1109 ,uri="/index.html",username="12345678" 1111 B->C 1113 Code = 1 (Access-Request) 1114 Attributes: 1115 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1116 NAS-Port-Type = 5 (Virtual) 1117 User-Name = "12345678" 1118 Digest-Response = "f052b68058b2987aba493857ae1ab002" 1119 Digest-Realm = "example.com" 1120 Digest-Nonce = "a3086ac8" 1121 Digest-Method = "GET" 1122 Digest-URI = "/index.html"" 1123 Digest-Algorithm = "md5" 1124 Digest-Username = "12345678" 1126 C->B 1128 Code = 2 (Access-Accept) 1129 Attributes: 1130 Digest-Response-Auth = 1131 "e644aa513effbfe1caff67103ff6433c" 1133 B->A 1135 HTTP/1.1 200 OK 1136 ... 1138 1139 ... 1141 7. IANA Considerations 1143 This document serves as IANA registration request for a number of 1144 values from the RADIUS attribute type number space: 1146 +-------------------------+------------------------+ 1147 | placeholder | value assigned by IANA | 1148 +-------------------------+------------------------+ 1149 | Digest-Response | TBD | 1150 | Digest-Realm | TBD | 1151 | Digest-Nonce | TBD | 1152 | Digest-Nextnonce | TBD | 1153 | Digest-Response-Auth | TBD | 1154 | Digest-Method | TBD | 1155 | Digest-URI | TBD | 1156 | Digest-Qop | TBD | 1157 | Digest-Algorithm | TBD | 1158 | Digest-Entity-Body-Hash | TBD | 1159 | Digest-CNonce | TBD | 1160 | Digest-Nonce-Count | TBD | 1161 | Digest-Username | TBD | 1162 | Digest-Opaque | TBD | 1163 | Digest-Auth-Param | TBD | 1164 | Digest-AKA-Auts | TBD | 1165 | Digest-Domain | TBD | 1166 | Digest-Stale | TBD | 1167 | Digest-HA1 | TBD | 1168 | SIP-AOR | TBD | 1169 +-------------------------+------------------------+ 1171 Table 2 1173 8. Security Considerations 1175 The RADIUS extensions described in this document enable RADIUS to 1176 transport the data that required to perform a digest calculation. As 1177 a result, RADIUS inherits the vulnerabilities of HTTP Digest (see 1178 [RFC2617], section 4) in addition to RADIUS security vulnerabilities 1179 described in [RFC2865] Section 8 and [RFC3579] Section 4. 1181 An attacker compromising a RADIUS client or proxy can carry out man- 1182 in-the-middle attacks even if the paths between A, B and B, C 1183 (Figure 2) have been secured with TLS or IPsec. 1185 The RADIUS server MUST check the Digest-Realm attribute it has 1186 received from a client. If the RADIUS client is not authorized to 1187 serve HTTP-style clients of that realm, it might be compromised. 1189 RADIUS clients implementing the extension described in this document 1190 may authenticate HTTP-style requests received over the Internet. As 1191 compared with use of RADIUS to authenticate link layer network 1192 access, an attacker may find it easier to cover their tracks in such 1193 a scenario. 1195 An attacker can attempt a denial of service attack on one or more 1196 RADIUS servers by sending a large number of HTTP-style requests. To 1197 make simple denial of service attacks more difficult, the nonce 1198 issuer (RADIUS client or server) MUST check if it has generated the 1199 nonce received from an HTTP-style client. This SHOULD be done 1200 statelessly. For example, a nonce could consist of a 1201 cryptographically random part and some kind of signature provided by 1202 the RADIUS client, as described in [RFC2617], section 3.2.1. 1204 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm 1205 attributes in Access-Challenge messages. A man in the middle can 1206 modify or remove those attributes in a bidding down attack, causing 1207 the RADIUS client to use a weaker authentication scheme than 1208 intended. 1210 The Message-Authenticator attribute, described in [RFC3579] section 1211 3.2 MUST be included in Access-Request, Access-Challenge, Access- 1212 Reject and Access-Accept messages that contain attributes described 1213 in this specification. 1215 The Digest-HA1 attribute contains no random components if the 1216 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1217 attacks easier and enables replay attacks. 1219 HTTP-style clients can use TLS with server side certificates together 1220 with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, 1221 too. TLS or IPsec secure the connection while Digest Authentication 1222 authenticates the user. The RADIUS transaction can be regarded as 1223 one leg on the path between the HTTP-style client and the HTTP-style 1224 server. To prevent RADIUS from representing the weak link, a RADIUS 1225 client receiving an HTTP-style request via TLS or IPsec MUST use an 1226 equally secure connection to the RADIUS server. There are two ways 1227 to achieve this: 1228 o the RADIUS client may reject HTTP-style requests received over TLS 1229 or IPsec 1230 o the RADIUS client require that traffic be sent and received over 1231 IPsec. 1232 RADIUS over IPsec, if used, MUST conform to the requirements 1233 described in [RFC3579] section 4.2. 1235 9. Acknowledgments 1237 We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or 1238 providing comments and experimental implementation. 1240 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1241 Arkko, Avi Lior and Jun Wang. 1243 10. References 1245 10.1. Normative References 1247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1248 Requirement Levels", BCP 14, RFC 2119, March 1997. 1250 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1251 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1252 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1254 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1255 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1256 Authentication: Basic and Digest Access Authentication", 1257 RFC 2617, June 1999. 1259 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1260 "Remote Authentication Dial In User Service (RADIUS)", 1261 RFC 2865, June 2000. 1263 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1264 A., Peterson, J., Sparks, R., Handley, M., and E. 1265 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1266 June 2002. 1268 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1269 Protocol (HTTP) Digest Authentication Using Authentication 1270 and Key Agreement (AKA)", RFC 3310, September 2002. 1272 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1273 Dial In User Service) Support For Extensible 1274 Authentication Protocol (EAP)", RFC 3579, September 2003. 1276 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1277 RFC 3966, December 2004. 1279 10.2. Informative References 1281 [I-D.ietf-aaa-diameter-sip-app] 1282 Garcia-Martin, M., "Diameter Session Initiation Protocol 1283 (SIP) Application", draft-ietf-aaa-diameter-sip-app-07 1284 (work in progress), March 2005. 1286 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1287 Recommendations for Security", RFC 1750, December 1994. 1289 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 1290 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 1291 HTTP : Digest Access Authentication", RFC 2069, 1292 January 1997. 1294 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1295 RFC 2246, January 1999. 1297 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1298 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1299 March 1999. 1301 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1302 RFC 2633, June 1999. 1304 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1305 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1307 Appendix A. Change Log 1309 RFC editor: please remove this section prior to RFC publication. 1311 A.1. Changes from draft-ietf-radext-digest-auth-03 1313 o new 'Interoperability' section, requiring support for both nonce 1314 generation modes. 1315 o removed Diameter migration path section (again) 1316 o reference to server behavior in Security Considerations section 1317 o fixed text/table mismatch regarding Digest-Domain attributes 1319 A.2. Changes from draft-ietf-radext-digest-auth-02 1321 o added Diameter migration path section (again) 1322 o various typos 1324 A.3. Changes from draft-ietf-radext-digest-auth-01 1326 o removed Diameter migration path section 1327 o Included Digest-URI and Digest-Realm in the authorization 1328 decision, not just in the digest calculation 1329 o RADIUS server must check if a RADIUS client is authorized to serve 1330 the realm mentioned in Digest-Realm 1331 o moved 'Detailed Description' sections in front of 'New RADIUS 1332 attributes' section 1333 o replaced 'IPsec or otherwise secured connection' with IPsec 1334 o changed MAY to SHOULD for Digest-Algorithm in Access-Challenge 1335 o changed type of Digest-Entity-Body-Hash to text (all other H(..) 1336 result attributes are hex and text, too) 1337 o new abstract 1338 o Terminology section changed 1339 o 'Changes' section as appendix 1341 A.4. Changes from draft-ietf-radext-digest-auth-00 1343 o SIP-AOR attribute added 1344 o clarified use of Digest-Qop 1345 o attribute overview table added 1347 A.5. Changes from draft-sterman-aaa-sip-04 1349 o clarified usage of Digest-HA1 1350 o clarified usage of Digest-Stale (is sent in an Access-Challenge 1351 now) 1352 o clarified allowed attribute usage for message types 1353 o changed attribute type to 'Text' where the corresponding Diameter 1354 AVPs have a UTF8String 1355 o added Diameter client - RADIUS server handling 1357 A.6. Changes from draft-sterman-aaa-sip-03 1359 o addressed 'auth-int' issue 1360 o New Digest-Nextnonce attribute 1361 o revised abstract, motivational section and examples 1362 o Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce 1363 attribute' 1364 o shortened SIP messages in example, removed real-world addresses 1365 and product names 1367 A.7. Changes from draft-sterman-aaa-sip-02 1369 o Relaxed restrictions for Digest-Domain, Digest-Realm, Digest- 1370 Opaque, Digest-Qop and Digest-Algorithm 1372 o Additional security considerations for Digest-Domain, Digest-Qop 1373 and Digest-Algorithm usage in Access-Accept messages 1375 A.8. Changes from draft-sterman-aaa-sip-01 1377 o Replaced Sub-attributes with flat attributes 1378 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1379 o Added how a server must treat unknown attributes. 1380 o Added a section 'Migration path to Diameter' 1381 o Added an optional attribute for support of the digest scheme 1382 described in informational [RFC3310]. 1383 o Added a mode of operation where the RADIUS server chooses the 1384 nonce. This was required for AKA [RFC3310], but can be useful for 1385 ordinary Digest Authentication when the qop directive is not used. 1386 This required the addition of several attributes. 1388 Authors' Addresses 1390 Baruch Sterman 1391 Kayote Networks 1392 P.O. Box 1373 1393 Efrat 90435 1394 Israel 1396 Email: baruch@kayote.com 1398 Daniel Sadolevsky 1399 SecureOL, Inc. 1400 Jerusalem Technology Park 1401 P.O. Box 16120 1402 Jerusalem 91160 1403 Israel 1405 Email: dscreat@dscreat.com 1407 David Schwartz 1408 Kayote Networks 1409 P.O. Box 1373 1410 Efrat 90435 1411 Israel 1413 Email: david@kayote.com 1415 David Williams 1416 Cisco Systems 1417 7025 Kit Creek Road 1418 P.O. Box 14987 1419 Research Triangle Park NC 27709 1420 USA 1422 Email: dwilli@cisco.com 1424 Wolfgang Beck 1425 Deutsche Telekom AG 1426 Am Kavalleriesand 3 1427 Darmstadt 64295 1428 Germany 1430 Email: beckw@t-systems.com 1432 Intellectual Property Statement 1434 The IETF takes no position regarding the validity or scope of any 1435 Intellectual Property Rights or other rights that might be claimed to 1436 pertain to the implementation or use of the technology described in 1437 this document or the extent to which any license under such rights 1438 might or might not be available; nor does it represent that it has 1439 made any independent effort to identify any such rights. Information 1440 on the procedures with respect to rights in RFC documents can be 1441 found in BCP 78 and BCP 79. 1443 Copies of IPR disclosures made to the IETF Secretariat and any 1444 assurances of licenses to be made available, or the result of an 1445 attempt made to obtain a general license or permission for the use of 1446 such proprietary rights by implementers or users of this 1447 specification can be obtained from the IETF on-line IPR repository at 1448 http://www.ietf.org/ipr. 1450 The IETF invites any interested party to bring to its attention any 1451 copyrights, patents or patent applications, or other proprietary 1452 rights that may cover technology that may be required to implement 1453 this standard. Please address the information to the IETF at 1454 ietf-ipr@ietf.org. 1456 Disclaimer of Validity 1458 This document and the information contained herein are provided on an 1459 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1460 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1461 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1462 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1463 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1466 Copyright Statement 1468 Copyright (C) The Internet Society (2005). This document is subject 1469 to the rights, licenses and restrictions contained in BCP 78, and 1470 except as set forth therein, the authors retain all their rights. 1472 Acknowledgment 1474 Funding for the RFC Editor function is currently provided by the 1475 Internet Society.