idnits 2.17.1 draft-ietf-radext-digest-auth-02.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1414. ** 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 32 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 (April 15, 2005) is 6922 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 987, but not defined == Missing Reference: 'Note 2' is mentioned on line 989, but not defined == Missing Reference: 'Note 3' is mentioned on line 991, but not defined == Unused Reference: 'RFC2616' is defined on line 1226, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 1262, 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. -------------------------------------------------------------------------------- 1 Network Working Group B. Sterman 2 Internet-Draft Kayote Networks 3 Expires: October 17, 2005 D. Sadolevsky 4 SecureOL, Inc. 5 D. Schwartz 6 Kayote Networks 7 D. Williams 8 Cisco Systems 9 W. Beck 10 Deutsche Telekom AG 11 April 15, 2005 13 RADIUS Extension for Digest Authentication 14 draft-ietf-radext-digest-auth-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on October 17, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document defines an extension to the RADIUS protocol to enable 48 support of Digest authentication, for use with HTTP-style protocols 49 like SIP and HTTP. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3.1 Scenario 1, RADIUS client chooses nonces . . . . . . . 6 58 1.3.2 Scenario 2, RADIUS server chooses nonces . . . . . . . 7 59 2. Detailed Description . . . . . . . . . . . . . . . . . . . . . 9 60 2.1 RADIUS Client Behavior . . . . . . . . . . . . . . . . . . 9 61 2.2 RADIUS Server Behavior . . . . . . . . . . . . . . . . . . 11 62 3. New RADIUS attributes . . . . . . . . . . . . . . . . . . . . 13 63 3.1 Digest-Response attribute . . . . . . . . . . . . . . . . 13 64 3.2 Digest-Realm attribute . . . . . . . . . . . . . . . . . . 14 65 3.3 Digest-Nonce attribute . . . . . . . . . . . . . . . . . . 14 66 3.4 Digest-Response-Auth attribute . . . . . . . . . . . . . . 15 67 3.5 Digest-Nextnonce attribute . . . . . . . . . . . . . . . . 15 68 3.6 Digest-Method attribute . . . . . . . . . . . . . . . . . 16 69 3.7 Digest-URI attribute . . . . . . . . . . . . . . . . . . . 16 70 3.8 Digest-Qop attribute . . . . . . . . . . . . . . . . . . . 16 71 3.9 Digest-Algorithm attribute . . . . . . . . . . . . . . . . 17 72 3.10 Digest-Entity-Body-Hash attribute . . . . . . . . . . . . 17 73 3.11 Digest-CNonce attribute . . . . . . . . . . . . . . . . . 18 74 3.12 Digest-Nonce-Count attribute . . . . . . . . . . . . . . . 18 75 3.13 Digest-Username attribute . . . . . . . . . . . . . . . . 19 76 3.14 Digest-Opaque attribute . . . . . . . . . . . . . . . . . 19 77 3.15 Digest-Auth-Param attribute . . . . . . . . . . . . . . . 19 78 3.16 Digest-AKA-Auts attribute . . . . . . . . . . . . . . . . 20 79 3.17 Digest-Domain attribute . . . . . . . . . . . . . . . . . 20 80 3.18 Digest-Stale attribute . . . . . . . . . . . . . . . . . . 21 81 3.19 Digest-HA1 attribute . . . . . . . . . . . . . . . . . . . 21 82 3.20 SIP-AOR . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 4. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 23 84 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 9.1 Normative References . . . . . . . . . . . . . . . . . . . 29 90 9.2 Informative References . . . . . . . . . . . . . . . . . . 29 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 92 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 A.1 Changes from draft-ietf-radext-digest-auth-01 . . . . . . 31 94 A.2 Changes from draft-ietf-radext-digest-auth-00 . . . . . . 31 95 A.3 Changes from draft-sterman-aaa-sip-04 . . . . . . . . . . 31 96 A.4 Changes from draft-sterman-aaa-sip-03 . . . . . . . . . . 32 97 A.5 Changes from draft-sterman-aaa-sip-02 . . . . . . . . . . 32 98 A.6 Changes from draft-sterman-aaa-sip-01 . . . . . . . . . . 32 99 Intellectual Property and Copyright Statements . . . . . . . . 33 101 1. Introduction 103 1.1 Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 HTTP-style protocol 110 a protocol using HTTP digest, like HTTP, SIP. 111 nonce 112 An unpredictable value used to prevent replay attacks. 113 protection space 114 The combination of realm and digest URI the use of which is 115 authorized by the RADIUS server. 117 1.2 Motivation 119 The HTTP Digest Authentication mechanism, defined in [RFC2617], was 120 subsequently adapted to use with SIP in [RFC2543] (obsoleted by 121 [RFC3261]). Due to the limitations and weaknesses of Digest 122 authentication (see [RFC2617], section 4), additional authentication 123 and encryption mechanisms are defined in SIP [RFC3261], including TLS 124 [RFC2246] and S/MIME [RFC2633]. However, Digest Authentication has 125 been widely implemented within SIP clients and to support those 126 clients there is a need for support of Digest Authentication within 127 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC3588]. 129 This document defines an extension to the RADIUS protocol to enable 130 support of Digest authentication, for use with SIP, HTTP, and other 131 HTTP-style protocols using this authentication method. Support for 132 Digest mechanisms such as AKA [RFC3310] is also supported. A 133 companion document [I-D.ietf-aaa-diameter-sip-app] defines support 134 for Digest authentication within Diameter. 136 1.3 Overview 138 HTTP digest is a challenge-response protocol used to authenticate a 139 client's request to access some resource on a server. Figure 1 shows 140 a single HTTP digest transaction. 142 HTTP/SIP.. 143 +------------+ (1) +------------+ 144 | |--------->| | 145 | HTTP-style | (2) | HTTP-style | 146 | Client |<---------| server | 147 | | (3) | | 148 | |--------->| | 149 | | (4) | | 150 | |<---------| | 151 +------------+ +------------+ 153 Figure 1: digest operation without RADIUS 155 If the client sends a request without any credentials (1), the server 156 will reply with an error response (2) containing a nonce. The client 157 creates a cryptographic digest from parts of the request, from the 158 nonce it received from the server, and a shared secret. The client 159 re-transmits the request (3) to the server, but now includes the 160 digest into the message. The server does the same digest calculation 161 as the client and compares the result with the digest it received in 162 (3). If the digest values are identical, the server grants access to 163 the resource and sends a positive response to the client (4). If the 164 digest values differ, the server sends a negative response to the 165 client (4). 167 Instead of maintaining a local user database, the server could use 168 RADIUS. However, RADIUS does not support HTTP digest without an 169 extension like the one described in this document. The RADIUS client 170 can not send a User-Password attribute as it does not receive a 171 password from the HTTP-style client. The RADIUS mechanism for CHAP 172 resembles HTTP digest, but the digest algorithms are not compatible. 174 This document extends RADIUS to support Digest Authentication, via 175 addition as a native authentication mechanism. An implementation 176 supporting this extension MUST include a Digest-Response attribute 177 within an Access-Request packet where Digest authentication is 178 desired. An Access-Request MUST NOT contain both a Digest-Response 179 attribute and another authentication attribute, such as User- 180 Password, CHAP-Password, or EAP-Message. 182 This document defines new attributes that enable the RADIUS server to 183 perform the digest calculation defined in [RFC2617]. 185 The nonces required by the digest algorithm are either generated by 186 the RADIUS client or by the RADIUS server. A mix of nonce generation 187 modes is not supported. 189 RADIUS clients and servers can support one, or both nonce generation 190 modes. 192 If the RADIUS server generates nonces, its RADIUS clients MUST NOT 193 try to generate nonces. If the RADIUS server does not generate 194 nonces, its RADIUS clients MUST generate nonces locally. If at least 195 one HTTP-style client requires AKA authentication [RFC3310], the 196 RADIUS server MUST generate nonces and its RADIUS clients MUST NOT 197 generate nonces locally. The nonce generation mode is a configurable 198 parameter 200 The operator MUST make sure that the RADIUS client software uses the 201 correct nonce generation mode when accessing a specific RADIUS 202 server. RADIUS clients implementing both modes MUST offer respective 203 configuration options. 205 1.3.1 Scenario 1, RADIUS client chooses nonces 207 HTTP/SIP RADIUS 209 +-----+ (1) +-----+ +-----+ 210 | |==========>| | | | 211 | | (2) | | | | 212 | |<==========| | | | 213 | | (3) | | | | 214 | |==========>| | | | 215 | A | | B | (4) | C | 216 | | | |---------->| | 217 | | | | (5) | | 218 | | | |<----------| | 219 | | (6) | | | | 220 | |<==========| | | | 221 +-----+ +-----+ +-----+ 223 ====> HTTP/SIP 224 ----> RADIUS 226 Figure 2: RADIUS client chooses nonces 228 The roles played by the entities in this scenario are as follows: 230 A: HTTP client / SIP UA 232 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 233 acting also as a RADIUS NAS (RADIUS client) 235 C: RADIUS server 237 The relevant order of messages sent in this scenario is as follows: 239 A sends B an HTTP/SIP request without authorization header (step 1). 240 B challenges A sending an HTTP/SIP "407 / 401 (Proxy) Authorization 241 required" response containing a locally generated nonce (step 2). A 242 sends B an HTTP/SIP request with authorization header (step 3). B 243 sends C a RADIUS Access-Request with attributes described in this 244 document (step 4). C responds to B with a RADIUS Access-Accept/ 245 Access-Reject response (step 5). If credentials were accepted B 246 receives an Access-Accept response and the message sent from A is 247 considered authentic. If B receives an Access-Reject response, 248 however, B then responds to A with a "407 / 401 (Proxy) 249 Authorization required" response (step 6). 251 1.3.2 Scenario 2, RADIUS server chooses nonces 253 In most cases, the operation outlined in Section 1.3.1 is sufficient. 254 It reduces the load on the RADIUS server to a minimum. However, when 255 using AKA [RFC3310] the nonce is partially derived from a precomputed 256 authentication vector. These authentication vectors are often stored 257 centrally. 259 Figure 3 depicts a scenario, where the RADIUS server chooses nonces. 260 It shows a generic case where entities A and B communicate in the 261 front-end using protocols such as HTTP/SIP, while entities B and C 262 communicate in the back-end using RADIUS. 264 HTTP/SIP RADIUS 266 +-----+ (1) +-----+ +-----+ 267 | |==========>| | (2) | | 268 | | | |---------->| | 269 | | | | (3) | | 270 | | (4) | |<----------| | 271 | |<==========| | | | 272 | | (5) | | | | 273 | |==========>| | | | 274 | A | | B | (6) | C | 275 | | | |---------->| | 276 | | | | (7) | | 277 | | | |<----------| | 278 | | (8) | | | | 279 | |<==========| | | | 280 +-----+ +-----+ +-----+ 282 ====> HTTP/SIP 283 ----> RADIUS 285 Figure 3: RADIUS server chooses nonces 287 The roles played by the entities in this scenario are as follows: 289 A: HTTP client / SIP UA 291 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 292 acting also as a RADIUS NAS 294 C: RADIUS server 296 The relevant order of messages sent in this scenario is as follows: 298 A sends B an HTTP/SIP request without authorization header (step 1). 299 B sends an Access-Request message with the newly defined Digest- 300 Method and Digest-URI attributes but without a Digest-Nonce attribute 301 to the RADIUS server, C (step 2). C chooses a nonce and responds 302 with an Access-Challenge (step 3). This Access-Challenge contains 303 Digest attributes, from which B takes values to construct an HTTP/SIP 304 "(Proxy) Authorization required" response. The remaining steps are 305 identical with scenario 1 (Section 1.3.1): B sends this response to A 306 (step 4). A resends its request with its credentials (step 5). B 307 sends an Access-Request to C (step 6). C checks the credentials and 308 replies with Access-Accept or Access-Reject (step 7). Dependent on 309 the C's result, B processes A's request or rejects it with a "(Proxy) 310 Authorization required" response (step 8). 312 2. Detailed Description 314 2.1 RADIUS Client Behavior 316 If the messages between RADIUS client and RADIUS server are not 317 protected with IPsec, the RADIUS client MUST NOT accept secured 318 connections (like https or sips) from its HTTP-style clients (or else 319 the HTTP-style clients would have a false sense of security). 321 On reception of an HTTP-style request message, the RADIUS client 322 checks whether it is responsible to authenticate the request. There 323 are situation where an HTTP-style request traverses several proxies, 324 and each of the proxies request to authenticate the HTTP-style 325 client. In this situation, it is a valid scenario that a HTTP-style 326 request received at a HTTP-style server contains several sets of 327 credentials. The 'realm' directive in HTTP is the key that the 328 RADIUS client can use to determine which credential is applicable. 329 It may happen also that none of the realms are of interest to the 330 RADIUS client, in which case the RADIUS client MUST consider that no 331 credentials (of interest) were sent. In any case, a RADIUS client 332 MUST send zero or exactly one credential to the RADIUS server. The 333 RADIUS client MUST choose the credential of the (Proxy-)Authorization 334 header where the realm directive matches its locally configured realm 335 value. 337 If such a header is present and contains HTTP digest information, the 338 RADIUS client checks the 'nonce' parameter. If the RADIUS client 339 generates nonces but did not issue the received nonce, it responds 340 with a 401 (Unauthorized) or 407 (Proxy Authentication Required) to 341 the HTTP-style client. In this error response, the RADIUS client 342 sends a new nonce. 344 If the RADIUS client recognizes the nonce or does not generate 345 nonces, it takes the header directives and puts them into a RADIUS 346 Access-Request message. It puts the 'response' directive into a 347 Digest-Response attribute and the realm / nonce / digest-uri / qop / 348 algorithm / cnonce / nc / username / opaque directives into the 349 respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / 350 Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- 351 Username / Digest-Opaque attributes. The request method is put into 352 the Digest-Method attribute. The RADIUS clients adds a Message- 353 Authenticator (see [RFC3579]) attribute. Now, the RADIUS client 354 sends the Access-Request message to the RADIUS server. 356 The RADIUS server processes the message and responds with an Access- 357 Accept or an Access-Reject message. 359 The RADIUS client constructs an Authentication-Info header: 360 o If the Access-Accept message contains a Digest-Response-Auth 361 attribute, the RADIUS client checks the Digest-Qop attribute: 362 * If the Digest-Qop attribute's value is 'auth' or not specified, 363 the RADIUS client puts the Digest-Response-Auth attribute's 364 content into the Authentication-Info header's 'rspauth' 365 directive of the HTTP-style response. 366 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 367 client ignores the Access-Accept message and behaves like it 368 had received an Access-Reject message (Digest-Response-Auth 369 can't be correct as the RADIUS server does not know the 370 contents of the HTTP-style response's body). 371 o If the Access-Accept message contains a Digest-HA1 attribute, the 372 RADIUS client checks the 'qop' and 'algorithm' directives in the 373 Authorization header of the HTTP-style request it wants to 374 authorize: 375 * If the 'qop' directive is missing or its value is 'auth', the 376 RADIUS client ignores the Digest-HA1 attribute. It does not 377 include an Authentication-Info header into its HTTP-style 378 response. 379 * If the 'qop' directive's value is 'auth-int' and at least one 380 of the following conditions is true, the RADIUS client 381 calculates the contents of the HTTP-style response's 'rspauth' 382 directive: 383 + The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5- 384 sess'. 385 + The messages between RADIUS client and RADIUS server are 386 protected with IPsec (see Section 7). 387 It creates the HTTP-style response message and calculates the 388 hash of this message's body. It uses the result and the 389 Digest-URI attribute's value of the corresponding Access- 390 Request message to perform the H(A2) calculation. It takes the 391 Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop 392 values of the corresponding Access-Request and the Digest-HA1 393 attribute's value to finish the computation of the 'rspauth' 394 value. 395 o If the Access-Accept message contains neither a Digest-Response- 396 Auth nor a Digest-HA1 attribute, the RADIUS client will not create 397 an Authentication-Info header for its HTTP-style response. 399 The RADIUS server MAY have added a Digest-Nextnonce attribute into an 400 Access-Accept message. If the RADIUS client discovers this, it puts 401 the contents of this attribute into a 'nextnonce' directive. Now it 402 can send an HTTP-style response. 404 If the RADIUS client did receive an HTTP-style request without a 405 (Proxy-)Authorization header matching its locally configured realm 406 value, it obtains a new nonce and sends an error response (401 or 407 407) containing a (Proxy-)Authenticate header. 409 If the RADIUS client receives an Access-Reject or no response from 410 the RADIUS server, it sends an error response to the HTTP-style 411 request it has received. 413 The RADIUS client has three ways to obtain nonces: it generates them 414 locally, it has received one in a Digest-Nextnonce attribute of a 415 previously received Access-Accept message, or it asks the RADIUS 416 server for one. To do the latter, it sends an Access-Request 417 containing a Digest-Method and a Digest-URI attribute but without a 418 Digest-Nonce attribute. It adds a Message-Authenticator (see 419 [RFC3579]) attribute to the Access-Request message. The RADIUS 420 server chooses a nonce and responds with an Access-Challenge 421 containing a Digest-Nonce attribute. 423 The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- 424 Realm, Digest-Domain and Digest-Opaque attributes in the Access- 425 Challenge carrying the nonce. If these attributes are present, the 426 client MUST use them. 428 If the RADIUS client receives an Access-Challenge message in response 429 to an Access-Request containing a Digest-Nonce attribute, the RADIUS 430 server did not accept the nonce. If a Digest-Stale attribute is 431 present in the Access-Challenge and has a value of 'true' (without 432 quotes), the RADIUS client sends an error (401 or 407) response 433 containing WWW-/Proxy-Authenticate header with the directive 'stale' 434 and the digest directives derived from the Digest-* attributes. 436 2.2 RADIUS Server Behavior 438 If the RADIUS server receives an Access-Request message with a 439 Digest-Method and a Digest-URI attribute but without a Digest-Nonce 440 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 441 attribute and sends it in an Access-Challenge message to the RADIUS 442 client. The RADIUS server Digest-Realm, Message-Authenticator (see 443 [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and 444 MAY add Digest-Domain, Digest-Opaque attributes to the Access- 445 Challenge message. If the server cannot choose a nonce, it replies 446 with an Access-Reject message. 448 If the RADIUS server receives an Access-Request message containing a 449 Digest-Response attribute, it looks for the following attributes: 450 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, 451 Digest-Algorithm, Digest-Username. Depending on the content of 452 Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- 453 Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and 454 [RFC3310] for details. If the Digest-Algorithm attribute is missing, 455 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque 456 attribute along with the nonce, the Access-Request MUST have a 457 matching Digest-Opaque attribute. 459 If mandatory attributes are missing, it MUST respond with an Access- 460 Reject message. If the attributes are present, the RADIUS server 461 calculates the digest response as described in [RFC2617]. To look up 462 the password, the RADIUS server uses the RADIUS User-Name attribute. 463 The RADIUS server MUST check if the user identified by the User-Name 464 attribute 465 o is authorized to access the protection space defined by the 466 Digest-URI and Digest-Realm attributes, 467 o is authorized to use the URI included in the SIP-AOR attribute, if 468 this attribute is present. 469 If any of those checks fails, the RADIUS server MUST send an Access- 470 Reject. 472 Correlation between User-Name and SIP-AOR AVP values is required just 473 to avoid that any user can register or misuse a SIP-AOR allocated to 474 another user. 476 A RADIUS MUST check if the RADIUS client is authorized to serve users 477 of the realm mentioned in the Digest-Realm attribute. If the RADIUS 478 client is not authorized, the RADIUS server silently discards the 479 Access-Request message. Other actions taken by the RADIUS server are 480 out of scope of this document. However, the RADIUS server should 481 notify the operator and may take additional action such as discarding 482 all future requests from this client, until some management action 483 tells it to do so again. 485 All values required for the digest calculation are taken from the 486 Digest attributes described in this document. If the calculated 487 digest response equals the value received in the Digest-Response 488 attribute, the authentication was successful. If not, the RADIUS 489 server responds with an Access-Reject. 491 If the authentication was successful, the RADIUS server adds an 492 attribute to the Access-Accept message which can be used by the 493 RADIUS client to construct an Authentication-Info header: 494 o If the Digest-Qop attribute's value is 'auth' or unspecified, the 495 RADIUS server SHOULD put a Digest-Response-Auth attribute into the 496 Access-Accept message 497 o If the Digest-Qop attribute's value is 'auth-int' and at least one 498 of the following conditions is true, the RADIUS server SHOULD put 499 a Digest-HA1 attribute into the Access-Accept message: 500 * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- 501 MD5-sess'. 503 * The messages between RADIUS client and RADIUS server are 504 protected with IPsec (see Section 7). 505 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be 506 sent. 508 RADIUS servers issuing nonces MAY construct a Digest-Nextnonce 509 attribute and add it to the Access-Accept message. This is useful to 510 limit the lifetime of a nonce and to save a round-trip in future 511 requests (see nextnonce discussion in [RFC2617], section 3.2.3). The 512 RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) 513 and sends the Access-Accept message to the RADIUS client. 515 If the RADIUS server does not accept the nonce received in an Access- 516 Request message but authentication was successful, the RADIUS server 517 MUST send an Access-Challenge message containing a Digest-Stale 518 attribute set to 'true' (without quotes). The RADIUS server MUST add 519 Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm, 520 SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add 521 Digest-Domain, Digest-Opaque attributes to the Access-Challenge 522 message. 524 3. New RADIUS attributes 526 The term 'HTTP-style' denotes any protocol that uses HTTP-like 527 headers and uses HTTP digest authentication as described in 528 [RFC2617]. Examples are HTTP and SIP. 530 If not stated otherwise, the attributes have the following format: 532 0 1 2 533 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type | Length | Text ... 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 3.1 Digest-Response attribute 540 Description 541 If this attribute is present in an Access-Request message, the 542 RADIUS server MUST view the Access-Request as a Digest one. 543 When a RADIUS client receives a (Proxy-)Authorization header, 544 it puts the request-digest value into a Digest-Response 545 attribute. The attribute proves the user knows the password 546 and MUST only be used in Access-Requests. 547 Type 548 [IANA: use 102 if possible] for Digest-Response. 549 Length 550 >= 3 551 Text 552 When using HTTP digest, the text field is 32 octets long and 553 contains hexadecimal representation of 16 octet digest value as 554 it was calculated by the authenticated client. Other digest 555 algorithms MAY define different digest lengths. The text field 556 MUST be copied from request-digest of digest-response 557 ([RFC2617]) without quotes. 559 3.2 Digest-Realm attribute 561 Description 562 This attribute describes a protection space of the RADIUS 563 server. See [RFC2617] 1.2 for details. It MUST only be used 564 in Access-Request and Access-Challenge messages. 565 Type 566 [IANA: use 103 if possible] for Digest-Realm 567 Length 568 >=3 569 Text 570 In Access-Requests, the RADIUS client takes the value of the 571 realm directive (realm-value according to [RFC2617]) without 572 quotes from the HTTP-style request it wants to authenticate. 573 In Access-Challenge messages, the RADIUS server puts the 574 expected realm value into this attribute. 576 3.3 Digest-Nonce attribute 578 Description 579 This attribute holds a nonce to be used in the HTTP Digest 580 calculation. If the Access-Request had a Digest-Method and a 581 Digest-URI but no Digest-Nonce attribute and the RADIUS server 582 is configured to choose nonces, it MUST put a Digest-Nonce 583 attribute into its Access-Challenge message. This attribute 584 MUST only be used in Access-Request and Access-Challenge 585 messages. 587 Type 588 [IANA: use 104 if possible] for Digest-Nonce 589 Length 590 >=3 591 Text 592 In Access-Requests, the RADIUS client takes the value of the 593 nonce directive (nonce-value in [RFC2617]) without quotes from 594 the HTTP-style request it wants to authenticate. In Access- 595 Challenge messages, the attribute contains the nonce selected 596 by the RADIUS server. 598 3.4 Digest-Response-Auth attribute 600 Description 601 This text proves the RADIUS server knows the password. If the 602 previously received Digest-Qop attribute was 'auth-int' 603 (without quotes), the RADIUS server MUST send a Digest-HA1 604 attribute instead of Digest-Response-Auth. The Digest- 605 Response-Auth attribute MUST only be used in Access-Accept 606 messages. The RADIUS client puts the attribute value without 607 quotes into the rspauth directive of the Authentication-Info 608 header. 609 Type 610 [IANA: use 105 if possible] for Digest-Response-Auth. 611 Length 612 >= 3 613 Text 614 The RADIUS server calculates a digest according to section 615 3.2.3 of [RFC2617] and copies the result into this attribute. 616 Other digest algorithms than the one defined in [RFC2617] MAY 617 define digest lengths other than 32. 619 3.5 Digest-Nextnonce attribute 621 This attribute holds a nonce to be used in the HTTP Digest 622 calculation. 624 Description 625 If the RADIUS server is configured to choose nonces it MAY put 626 a Digest-Nextnonce attribute into an Access-Accept message. If 627 this attribute is present, the RADIUS client MUST put the 628 contents of this attribute into the nextnonce directive of an 629 Authentication-Info header in its HTTP-style response. This 630 attribute MUST only be used in Access-Accept messages. 632 Type 633 [IANA: use 106 if possible] for Digest-Nextnonce 634 Length 635 >=3 636 Text 637 It is recommended that this text be base64 or hexadecimal data. 639 3.6 Digest-Method attribute 641 Description 642 This attribute holds the method value to be used in the HTTP 643 Digest calculation. This attribute MUST only be used in 644 Access-Request messages. 645 Type 646 [IANA: use 107 if possible] for Digest-Method 647 Length 648 >=3 649 Text 650 In Access-Requests, the RADIUS client takes the value of the 651 request method from the HTTP-style request it wants to 652 authenticate. 654 3.7 Digest-URI attribute 656 Description 657 This attribute is used to transport the contents of the digest- 658 uri directive or the URI of the HTTP-style request. It MUST 659 only be used in Access-Request messages. 660 Type 661 [IANA: use 108 if possible] for Digest-URI 662 Length 663 >=3 664 Text 665 If the HTTP-style request has an Authorization header, the 666 RADIUS client puts the value of the "uri" directive in the 667 (known as "digest-uri-value" in section 3.2.2 of [RFC2617]) 668 without quotes into this attribute. If there is no 669 Authorization header, the RADIUS client takes the value of the 670 request URI from the HTTP-style request it wants to 671 authenticate. 673 3.8 Digest-Qop attribute 675 Description 676 This attribute holds the Quality of Protection parameter that 677 influences the HTTP Digest calculation. This attribute MUST 678 only be used in Access-Request and Access-Challenge messages. 679 A RADIUS client SHOULD insert one of the Digest-Qop attributes 680 it has received in a previous Access-Challenge message. RADIUS 681 servers SHOULD insert at least one Digest-Qop attribute in an 682 Access-Challenge message. Digest-Qop is optional in order to 683 preserve backward compatibility with a minimal implementation 684 of [RFC2069]. 685 Type 686 [IANA: use 109 if possible] for Digest-Qop 687 Length 688 >=3 689 Text 690 In Access-Requests, the RADIUS client takes the value of the 691 qop directive (qop-value as described in [RFC2617]) without the 692 quotes from the HTTP-style request it wants to authenticate. 693 In Access-Challenge messages, the RADIUS server puts a desired 694 qop-value into this attribute. If the RADIUS server supports 695 more than one "quality of protection" value, it puts each qop- 696 value into a separate Digest-Qop attribute. 698 3.9 Digest-Algorithm attribute 700 Type 701 This attribute holds the algorithm parameter that influences 702 the HTTP Digest calculation. It MUST only be used in Access- 703 Request and Access-Challenge messages. If this attribute is 704 missing, "MD5" is assumed. 705 Type 706 [IANA: use 110 if possible] for Digest-Algorithm 707 Length 708 >=3 709 Text 710 In Access-Requests, the RADIUS client takes the value of the 711 algorithm directive (as described in [RFC2617], section 3.2.1) 712 without the quotes from the HTTP-style request it wants to 713 authenticate. In Access-Challenge messages, the RADIUS server 714 SHOULD put the desired algorithm into this attribute. 716 3.10 Digest-Entity-Body-Hash attribute 718 Description 719 When using the qop level 'auth-int', a hash of the HTTP-style 720 message body's contents is required for digest calculation. 721 Instead of sending the complete body of the message, only its 722 hash value is sent. This hash value can be used directly in 723 the digest calculation. 725 The clarifications described in section 22.4 of [RFC2617] about 726 the hash of empty entity bodies apply to the Digest-Entity- 727 Body-Hash attribute. This attribute MUST only be sent in 728 Access-Request packets. 729 Type 730 [IANA: use 111 if possible] for Digest-Entity-Body-Hash 731 Length 732 >=3 733 Text 734 The attribute holds the hexadecimal representation of H(entity- 735 body). This hash is required by certain authentication 736 mechanisms, such as HTTP Digest with quality of protection set 737 to "auth-int". RADIUS clients MUST use this attribute to 738 transport the hash of the entity body when HTTP Digest is the 739 authentication mechanism and the RADIUS server requires to 740 verify the integrity of the entity body (e.g., qop parameter 741 set to "auth-int"). Extensions to this document may define 742 support for authentication mechanisms other than HTTP Digest. 744 3.11 Digest-CNonce attribute 746 Description 747 This attribute holds the client nonce parameter that is used in 748 the HTTP Digest calculation. It MUST only be used in Access- 749 Request messages.u 750 Type 751 [IANA: use 112 if possible] for Digest-CNonce 752 Length 753 >=3 754 Text 755 This attribute includes the value of the cnonce-value [RFC2617] 756 without quotes, taken from the HTTP-style request. 758 3.12 Digest-Nonce-Count attribute 760 Description 761 This attribute includes the nonce count parameter that is used 762 to detect replay attacks. The attribute MUST only be used in 763 Access-Request messages. 764 Type 765 [IANA: use 113 if possible] for Digest-Nonce-Count 766 Length 767 10 768 Text 769 In Access-Requests, the RADIUS client takes the value of the nc 770 directive (nc-value according to [RFC2617]) without quotes from 771 the HTTP-style request it wants to authenticate. 773 3.13 Digest-Username attribute 775 Description 776 This attribute holds the user name parameter that is used in 777 the HTTP digest calculation. The RADIUS server MUST NOT use 778 this value for password finding, but only for digest 779 calculation purpose. In order to find the user record 780 containing the password, the RADIUS server MUST use the value 781 of the ([RFC2865] -)User-Name attribute. This attribute MUST 782 only be used in Access-Request packets. 783 Type 784 [IANA: use 114 if possible] for Digest-Username 785 Length 786 >= 3 787 Text 788 In Access-Requests, the RADIUS client takes the value of the 789 username directive (username-value according to [RFC2617]) 790 without quotes from the HTTP-style request it wants to 791 authenticate. 793 3.14 Digest-Opaque attribute 795 Description 796 This attribute holds the opaque parameter that is passed to the 797 HTTP-style client. The HTTP-style client will pass this value 798 back to the server (ie the RADIUS client) without modification. 799 This attribute is only used when the RADIUS server chooses 800 nonces and MUST only be used in Access-Request and Access- 801 Challenge messages. 802 Type 803 [IANA: use 115 if possible] for Digest-Opaque 804 Length 805 >=3 806 Text 807 In Access-Requests, the RADIUS client takes the value of the 808 opaque directive (opaque-value according to [RFC2617]) without 809 quotes from the HTTP-style request it wants to authenticate and 810 puts it into this attribute. In Access-Challenge messages, the 811 RADIUS server MAY include this attribute. 813 3.15 Digest-Auth-Param attribute 814 Description 815 This attribute is a placeholder for future extensions and 816 corresponds to the "auth-param" parameter defined in section 817 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism 818 whereby the RADIUS client and RADIUS server can exchange auth- 819 param extension parameters contained within Digest headers that 820 are not understood by the RADIUS client and for which there are 821 no corresponding stand-alone attributes. 822 Unlike the previously listed Digest-* attributes, the Digest- 823 Auth-Param contains not only the value, but also the parameter 824 name, since the parameter name is unknown to the RADIUS client. 825 If the Digest header contains several unknown parameters, then 826 the RADIUS implementation MUST repeat this attribute and each 827 instance MUST contain one different unknown Digest parameter/ 828 value combination. 829 This attribute MUST ONLY be used in Access-Request, Access- 830 Challenge, or Access-Accept messages. 831 Type 832 [IANA: use 116 if possible] for Digest-Auth-Param 833 Length 834 >=3 835 Text 836 The text consists of the whole parameter, including its name 837 and the equal ('=') sign and quotes. 839 3.16 Digest-AKA-Auts attribute 841 Description 842 This attribute holds the auts parameter that is used in the 843 Digest AKA ([RFC3310]) calculation. It is only used if the 844 algorithm of the digest-response denotes a version of AKA 845 digest [RFC3310]. This attribute MUST only be used in Access- 846 Request messages. 847 Type 848 [IANA: use 117 if possible] for Digest-AKA-Auts 849 Length 850 >=3 851 Text 852 In Access-Requests, the RADIUS client takes the value of the 853 auts directive (auts-param according to section 3.4 of 854 [RFC3310]) without quotes from the HTTP-style request it wants 855 to authenticate. 857 3.17 Digest-Domain attribute 858 Description 859 When a RADIUS client has asked for a nonce, the RADIUS server 860 MAY send one or more Digest-Domain attributes in its Access- 861 Challenge message. The RADIUS client puts them into the 862 quoted, space-separated list of URIs of the 'domain' directive 863 of a WWW-Authenticate header. The URIs in the list define the 864 protection space (see [RFC2617], section 3.2.1). RADIUS 865 servers MAY send one or more attributes of this type in Access- 866 Challenge messages. This attribute MUST only be used in 867 Access-Challenge messages. 868 Type 869 [IANA: use 118 if possible] for Digest-Domain 870 Length 871 3 872 Text 873 This attribute consists of a single URI, that defines a 874 protection space. 876 3.18 Digest-Stale attribute 878 Description 879 This attribute is sent by a RADIUS server in order to notify 880 the RADIUS client whether it has accepted a nonce. If the 881 nonce presented by the RADIUS client was stale, the value is 882 'true' and is 'false' otherwise. The RADIUS client puts the 883 content of this attribute into a 'stale' directive of the WWW- 884 Authenticate header in the HTTP-style response to the request 885 it wants to authenticate. The attribute MUST only be used in 886 Access-Challenge messages and only if the RADIUS server chooses 887 nonces. 888 Type 889 [IANA: use 119 if possible] for Digest-Stale 890 Length 891 3 892 Text 893 The attribute has either the value 'true' or 'false' (both 894 values without quotes). 896 3.19 Digest-HA1 attribute 898 Description 899 This attribute is used to allow the generation of an 900 Authentication-Info header, even if the HTTP-style response's 901 body is required for the calculation of the rspauth value. It 902 SHOULD be used in Access-Accept messages if the required 903 quality of protection ('qop') is 'auth-int'. 905 This attribute MUST NOT be sent if the qop parameter was not 906 specified or has a value of 'auth' (in this case, use Digest- 907 Response-Auth instead). 908 The Digest-HA1 attribute MUST only be sent by the RADIUS server 909 or processed by the RADIUS client if at least one of the 910 following conditions is true: 911 + The Digest-Algorithm attribute's value is 'MD5-sess' or 912 'AKAv1-MD5-sess'. 913 + The messages between RADIUS client and RADIUS server are 914 protected with IPsec (see Section 7). 915 This attribute MUST only be used in Access-Accept messages. 916 Type 917 [IANA: use 120 if possible] for Digest-HA1 918 Length 919 >= 3 920 Text 921 This attribute contains the hexadecimal representation of H(A1) 922 as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2. 924 3.20 SIP-AOR 926 Type 927 This attribute is used for the authorization of SIP messages. 928 The SIP-AOR attribute identifies the URI the use of which must 929 be authenticated and authorized. The RADIUS server uses this 930 attribute to authorize the processing of the SIP request. The 931 SIP-AOR can be derived from, e.g., the To header field in a SIP 932 REGISTER request (user under registration), or the From header 933 field in other SIP requests. However, the exact mapping of 934 this attribute to SIP can change due to new developments in the 935 protocol. 936 This attribute MUST only be used when the RADIUS client wants 937 to authorize SIP users and MUST only be used in Access-Request 938 messages. 939 Type 940 [IANA:use 121 if possible] for SIP-AOR 941 Length 942 >=3 943 Text 944 The syntax of this attribute corresponds either to a SIP URI 945 (with the format defined in [RFC3261] or a TEL URI (with the 946 format defined in [RFC3966]). 947 The SIP-AOR attribute holds the complete URI, including 948 parameters and other parts. It is up to the RADIUS server what 949 components of the URI are regarded in the authorization 950 decision. 952 4. Table of Attributes 954 The following table provides a guide to which attributes may be found 955 in which kinds of packets, and in what quantity. 957 +-------------------------+-----+-----+--------+--------+-----------+ 958 | Attribute | # | Req | Accept | Reject | Challenge | 959 +-------------------------+-----+-----+--------+--------+-----------+ 960 | User-Name | TBD | 1 | 0 | 0 | 0 | 961 | Message-Authenticator | TBD | 1 | 1 | 1 | 1 | 962 | Digest-Response | TBD | 0-1 | 0 | 0 | 0 | 963 | Digest-Realm | TBD | 0-1 | 0 | 0 | 1 | 964 | Digest-Nonce | TBD | 0-1 | 0 | 0 | 1 | 965 | Digest-Response-Auth | TBD | 0 | 0-1 | 0 | 0 | 966 | (see Note 1, 2) | | | | | | 967 | Digest-Nextnonce | TBD | 0 | 0-1 | 0 | 0 | 968 | Digest-Method | TBD | 0-1 | 0 | 0 | 0 | 969 | Digest-URI | TBD | 0-1 | 0 | 0 | 0 | 970 | Digest-Qop | TBD | 0-1 | 0 | 0 | 1+ | 971 | Digest-Algorithm (see | TBD | 0-1 | 0 | 0 | 0-1 | 972 | Note 3) | | | | | | 973 | Digest-Entity-Body-Hash | TBD | 0-1 | 0 | 0 | 0 | 974 | Digest-CNonce | TBD | 0-1 | 0 | 0 | 0 | 975 | Digest-Nonce-Count | TBD | 0-1 | 0 | 0 | 0 | 976 | Digest-Username | TBD | 0-1 | 0 | 0 | 0 | 977 | Digest-Opaque | TBD | 0-1 | 0 | 0 | 0-1 | 978 | Digest-Auth-Param | TBD | 0+ | 0+ | 0 | 0+ | 979 | Digest-AKA-Auts | TBD | 0-1 | 0 | 0 | 0 | 980 | Digest-Domain | TBD | 0 | 0 | 0 | 0-1 | 981 | Digest-Stale | TBD | 0 | 0 | 0 | 0-1 | 982 | Digest-HA1 (see Note 1, | TBD | 0 | 0-1 | 0 | 0 | 983 | 2) | | | | | | 984 | SIP-AOR | TBD | 0-1 | 0 | 0 | 0 | 985 +-------------------------+-----+-----+--------+--------+-----------+ 987 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if 988 Digest-Qop is 'auth-int'. 989 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if 990 Digest-Qop is 'auth'. 991 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed 993 5. Example 995 This is an example sniffed from the traffic between a softphone (A), 996 a Proxy Server (B) and example.com RADIUS server (C). The 997 communication between the Proxy Server and a SIP PSTN gateway is 998 omitted for brevity. The SIP messages are not shown completely. 1000 A->B 1002 INVITE sip:97226491335@example.com SIP/2.0 1003 From: 1004 To: 1006 B->A 1008 SIP/2.0 100 Trying 1010 B->A 1012 SIP/2.0 407 Proxy Authentication Required 1013 Proxy-Authenticate: Digest realm="example.com" 1014 ,nonce="3bada1a0", algorithm="md5" 1015 Content-Length: 0 1017 A->B 1019 ACK sip:97226491335@example.com SIP/2.0 1021 A->B 1023 INVITE sip:97226491335@example.com SIP/2.0 1024 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1025 ,opaque="",realm="example.com" 1026 ,response="f3ce87e6984557cd0fecc26f3c5e97a4" 1027 ,uri="sip:97226491335@10.0.69.38",username="12345678" 1028 From: 1029 To: 1031 B->C 1033 Code = 1 (Access-Request) 1034 Attributes: 1035 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1036 NAS-Port-Type = 5 (Virtual) 1037 User-Name = "12345678" 1038 Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" 1039 Digest-Realm = "example.com" 1040 Digest-Nonce = "3bada1a0" 1041 Digest-Method = "INVITE" 1042 Digest-URI = "sip:97226491335@example.com" 1043 Digest-Algorithm = "md5" 1044 Digest-Username = "12345678" 1045 SIP-AOR = "sip:12345678@example.com" 1047 C->B 1049 Code = 2 (Access-Accept) 1050 Attributes: 1051 Digest-Response-Auth = 1052 "6303c41b0e2c3e524e413cafe8cce954" 1054 B->A 1056 SIP/2.0 180 Ringing 1058 B->A 1060 SIP/2.0 200 OK 1062 A->B 1064 ACK sip:97226491335@example.com SIP/2.0 1066 A second example shows the traffic between a web browser (A), web 1067 server (B) and a RADIUS server (C). 1069 A->B 1071 GET /index.html HTTP/1.1 1073 B->A 1075 HTTP/1.1 407 Authentication Required 1076 WWW-Authenticate: Digest realm="example.com", 1077 domain="/index.html", 1078 nonce="a3086ac8", algorithm="md5" 1079 Content-Length: 0 1081 A->B 1083 GET /index.html HTTP/1.1 1084 Authorization: Digest algorithm="md5",nonce="a3086ac8" 1085 ,opaque="",realm="example.com" 1086 ,response="f052b68058b2987aba493857ae1ab002" 1087 ,uri="/index.html",username="12345678" 1089 B->C 1091 Code = 1 (Access-Request) 1092 Attributes: 1093 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1094 NAS-Port-Type = 5 (Virtual) 1095 User-Name = "12345678" 1096 Digest-Response = "f052b68058b2987aba493857ae1ab002" 1097 Digest-Realm = "example.com" 1098 Digest-Nonce = "a3086ac8" 1099 Digest-Method = "GET" 1100 Digest-URI = "/index.html"" 1101 Digest-Algorithm = "md5" 1102 Digest-Username = "12345678" 1104 C->B 1106 Code = 2 (Access-Accept) 1107 Attributes: 1108 Digest-Response-Auth = 1109 "e644aa513effbfe1caff67103ff6433c" 1111 B->A 1113 HTTP/1.1 200 OK 1114 ... 1116 1117 ... 1119 6. IANA Considerations 1121 This document serves as IANA registration request for a number of 1122 values from the RADIUS attribute type number space: 1124 +-------------------------+------------------------+ 1125 | placeholder | value assigned by IANA | 1126 +-------------------------+------------------------+ 1127 | Digest-Response | TBD | 1128 | Digest-Realm | TBD | 1129 | Digest-Nonce | TBD | 1130 | Digest-Nextnonce | TBD | 1131 | Digest-Response-Auth | TBD | 1132 | Digest-Method | TBD | 1133 | Digest-URI | TBD | 1134 | Digest-Qop | TBD | 1135 | Digest-Algorithm | TBD | 1136 | Digest-Entity-Body-Hash | TBD | 1137 | Digest-CNonce | TBD | 1138 | Digest-Nonce-Count | TBD | 1139 | Digest-Username | TBD | 1140 | Digest-Opaque | TBD | 1141 | Digest-Auth-Param | TBD | 1142 | Digest-AKA-Auts | TBD | 1143 | Digest-Domain | TBD | 1144 | Digest-Stale | TBD | 1145 | Digest-HA1 | TBD | 1146 | SIP-AOR | TBD | 1147 +-------------------------+------------------------+ 1149 Table 2 1151 7. Security Considerations 1153 The RADIUS extensions described in this document make RADIUS a 1154 transport protocol for the data that is required to perform a digest 1155 calculation. It adds the vulnerabilities of HTTP Digest (see 1156 [RFC2617], section 4) to those of RADIUS (see [RFC2865], Section 8 or 1157 Section 4 of [RFC3579]). 1159 If an attacker gains control over a RADIUS client or RADIUS proxy, he 1160 can perform man-in-the-middle attacks even if the paths between A, B 1161 and B, C (Figure 2) have been secured with TLS or IPsec. 1163 The RADIUS server MUST check the Digest-Realm attribute it has 1164 received from a client. If the RADIUS client is not authorized to 1165 serve HTTP-style clients of that realm, it might be compromised. 1167 RADIUS clients implementing the extension described in this document 1168 authenticate layer 3 requests received from the Internet. This is in 1169 contrast to the original use of RADIUS, where layer 2 sessions are 1170 authenticated. In layer 2 access networks, attackers can usually 1171 tracked down more easily. 1173 An attacker could try to overload the RADIUS infrastructure by 1174 excessively sending HTTP-style requests. To make simple denial of 1175 service attacks more difficult, the nonce issuer (RADIUS client or 1176 server) MUST check if it has generated the nonce received from an 1177 HTTP-style client. This SHOULD be done statelessly. For example, a 1178 nonce could consist of a cryptographically random part and some kind 1179 of signature of the RADIUS client, as described in [RFC2617], section 1180 3.2.1. 1182 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm 1183 attributes in Access-Challenge messages. A man in the middle can 1184 modify or remove those attributes in a bidding down attack. In this 1185 case, the RADIUS client would use a weaker authentication scheme than 1186 intended. RfC 3579 [RFC3579], section 3.2 describes a Message- 1187 Authenticator attribute which MUST be used to improve the integrity 1188 protection of RADIUS messages. The RADIUS server can use this 1189 attribute to verify the identity of the RADIUS client. 1191 The Digest-HA1 attribute contains no random components if the 1192 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1193 attacks easier and can be used for replay attacks. 1195 HTTP-style clients can use TLS with server side certificates together 1196 with HTTP-Digest authentication. Instead of TLS, IPsec can be used, 1197 too. TLS or IPsec secure the connection while Digest Authentication 1198 authenticates the user. The RADIUS transaction can be regarded as 1199 one leg on the path between the HTTP-style client and the HTTP-style 1200 server. To prevent the RADIUS transaction from being the weakest hop 1201 on the path, a RADIUS client receiving an HTTP-style request via TLS 1202 or IPsec MUST use an equally secure connection to the RADIUS server. 1203 There are two ways to achieve this: 1204 o the RADIUS client rejects HTTP-style requests received over TLS or 1205 IPsec 1206 o the operator of the RADIUS client takes actions to ensure that 1207 RADIUS traffic is exclusively sent and received using IPsec. 1208 When using IPsec, it MUST be set up as described [RFC3579] section 1209 4.2. 1211 8. Acknowledgments 1213 We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or 1214 providing comments and experimental implementation. 1216 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1217 Arkko, Avi Lior and Jun Wang. 1219 9. References 1221 9.1 Normative References 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, March 1997. 1226 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1227 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1228 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1230 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1231 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1232 Authentication: Basic and Digest Access Authentication", 1233 RFC 2617, June 1999. 1235 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1236 "Remote Authentication Dial In User Service (RADIUS)", 1237 RFC 2865, June 2000. 1239 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1240 A., Peterson, J., Sparks, R., Handley, M., and E. 1241 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1242 June 2002. 1244 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1245 Protocol (HTTP) Digest Authentication Using Authentication 1246 and Key Agreement (AKA)", RFC 3310, September 2002. 1248 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1249 Dial In User Service) Support For Extensible 1250 Authentication Protocol (EAP)", RFC 3579, September 2003. 1252 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1253 RFC 3966, December 2004. 1255 9.2 Informative References 1257 [I-D.ietf-aaa-diameter-sip-app] 1258 Garcia-Martin, M., "Diameter Session Initiation Protocol 1259 (SIP) Application", draft-ietf-aaa-diameter-sip-app-07 1260 (work in progress), March 2005. 1262 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1263 Recommendations for Security", RFC 1750, December 1994. 1265 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 1266 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 1267 HTTP : Digest Access Authentication", RFC 2069, 1268 January 1997. 1270 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1271 RFC 2246, January 1999. 1273 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1274 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1275 March 1999. 1277 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1278 RFC 2633, June 1999. 1280 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1281 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1283 Authors' Addresses 1285 Baruch Sterman 1286 Kayote Networks 1287 P.O. Box 1373 1288 Efrat 90435 1289 Israel 1291 Email: baruch@kayote.com 1293 Daniel Sadolevsky 1294 SecureOL, Inc. 1295 Jerusalem Technology Park 1296 P.O. Box 16120 1297 Jerusalem 91160 1298 Israel 1300 Email: dscreat@dscreat.com 1302 David Schwartz 1303 Kayote Networks 1304 P.O. Box 1373 1305 Efrat 90435 1306 Israel 1308 Email: david@kayote.com 1309 David Williams 1310 Cisco Systems 1311 7025 Kit Creek Road 1312 P.O. Box 14987 1313 Research Triangle Park NC 27709 1314 USA 1316 Email: dwilli@cisco.com 1318 Wolfgang Beck 1319 Deutsche Telekom AG 1320 Am Kavalleriesand 3 1321 Darmstadt 64295 1322 Germany 1324 Email: beckw@t-systems.com 1326 Appendix A. Change Log 1328 RFC editor: please remove this section prior to RFC publication. 1330 A.1 Changes from draft-ietf-radext-digest-auth-01 1332 o removed Diameter migration path section 1333 o Included Digest-URI and Digest-Realm in the authorization 1334 decision, not just in the digest calculation 1335 o RADIUS server must check if a RADIUS client is authorized to serve 1336 the realm mentioned in Digest-Realm 1337 o moved 'Detailed Description' sections in front of 'New RADIUS 1338 attributes' section 1339 o replaced 'IPsec or otherwise secured connection' with IPsec 1340 o changed MAY to SHOULD for Digest-Algorithm in Access-Challenge 1341 o changed type of Digest-Entity-Body-Hash to text (all other H(..) 1342 result attributes are hex and text, too) 1343 o new abstract 1344 o Terminology section changed 1345 o 'Changes' section as appendix 1347 A.2 Changes from draft-ietf-radext-digest-auth-00 1349 o SIP-AOR attribute added 1350 o clarified use of Digest-Qop 1351 o attribute overview table added 1353 A.3 Changes from draft-sterman-aaa-sip-04 1354 o clarified usage of Digest-HA1 1355 o clarified usage of Digest-Stale (is sent in an Access-Challenge 1356 now) 1357 o clarified allowed attribute usage for message types 1358 o changed attribute type to 'Text' where the corresponding Diameter 1359 AVPs have a UTF8String 1360 o added Diameter client - RADIUS server handling 1362 A.4 Changes from draft-sterman-aaa-sip-03 1364 o addressed 'auth-int' issue 1365 o New Digest-Nextnonce attribute 1366 o revised abstract, motivational section and examples 1367 o Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce 1368 attribute' 1369 o shortened SIP messages in example, removed real-world addresses 1370 and product names 1372 A.5 Changes from draft-sterman-aaa-sip-02 1374 o Relaxed restrictions for Digest-Domain, Digest-Realm, Digest- 1375 Opaque, Digest-Qop and Digest-Algorithm 1376 o Additional security considerations for Digest-Domain, Digest-Qop 1377 and Digest-Algorithm usage in Access-Accept messages 1379 A.6 Changes from draft-sterman-aaa-sip-01 1381 o Replaced Sub-attributes with flat attributes 1382 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1383 o Added how a server must treat unknown attributes. 1384 o Added a section 'Migration path to Diameter' 1385 o Added an optional attribute for support of the digest scheme 1386 described in informational [RFC3310]. 1387 o Added a mode of operation where the RADIUS server chooses the 1388 nonce. This was required for AKA [RFC3310], but can be useful for 1389 ordinary Digest authentication when the qop directive is not used. 1390 This required the addition of several attributes. 1392 Intellectual Property Statement 1394 The IETF takes no position regarding the validity or scope of any 1395 Intellectual Property Rights or other rights that might be claimed to 1396 pertain to the implementation or use of the technology described in 1397 this document or the extent to which any license under such rights 1398 might or might not be available; nor does it represent that it has 1399 made any independent effort to identify any such rights. Information 1400 on the procedures with respect to rights in RFC documents can be 1401 found in BCP 78 and BCP 79. 1403 Copies of IPR disclosures made to the IETF Secretariat and any 1404 assurances of licenses to be made available, or the result of an 1405 attempt made to obtain a general license or permission for the use of 1406 such proprietary rights by implementers or users of this 1407 specification can be obtained from the IETF on-line IPR repository at 1408 http://www.ietf.org/ipr. 1410 The IETF invites any interested party to bring to its attention any 1411 copyrights, patents or patent applications, or other proprietary 1412 rights that may cover technology that may be required to implement 1413 this standard. Please address the information to the IETF at 1414 ietf-ipr@ietf.org. 1416 Disclaimer of Validity 1418 This document and the information contained herein are provided on an 1419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1421 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1422 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1423 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1426 Copyright Statement 1428 Copyright (C) The Internet Society (2005). This document is subject 1429 to the rights, licenses and restrictions contained in BCP 78, and 1430 except as set forth therein, the authors retain all their rights. 1432 Acknowledgment 1434 Funding for the RFC Editor function is currently provided by the 1435 Internet Society.