idnits 2.17.1 draft-ietf-radext-digest-auth-03.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 1513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1503. ** 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 (July 18, 2005) is 6850 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 1070, but not defined == Missing Reference: 'Note 2' is mentioned on line 1072, but not defined == Missing Reference: 'Note 3' is mentioned on line 1074, but not defined == Unused Reference: 'RFC2616' is defined on line 1309, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 1345, 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: January 19, 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 July 18, 2005 14 RADIUS Extension for Digest Authentication 15 draft-ietf-radext-digest-auth-03.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 January 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3.1 Scenario 1, RADIUS client chooses nonces . . . . . . . 6 59 1.3.2 Scenario 2, RADIUS server chooses nonces . . . . . . . 7 60 2. Detailed Description . . . . . . . . . . . . . . . . . . . . . 9 61 2.1 RADIUS Client Behavior . . . . . . . . . . . . . . . . . . 9 62 2.2 RADIUS Server Behavior . . . . . . . . . . . . . . . . . . 11 63 3. New RADIUS attributes . . . . . . . . . . . . . . . . . . . . 13 64 3.1 Digest-Response attribute . . . . . . . . . . . . . . . . 13 65 3.2 Digest-Realm attribute . . . . . . . . . . . . . . . . . . 14 66 3.3 Digest-Nonce attribute . . . . . . . . . . . . . . . . . . 14 67 3.4 Digest-Response-Auth attribute . . . . . . . . . . . . . . 15 68 3.5 Digest-Nextnonce attribute . . . . . . . . . . . . . . . . 15 69 3.6 Digest-Method attribute . . . . . . . . . . . . . . . . . 16 70 3.7 Digest-URI attribute . . . . . . . . . . . . . . . . . . . 16 71 3.8 Digest-Qop attribute . . . . . . . . . . . . . . . . . . . 16 72 3.9 Digest-Algorithm attribute . . . . . . . . . . . . . . . . 17 73 3.10 Digest-Entity-Body-Hash attribute . . . . . . . . . . . . 17 74 3.11 Digest-CNonce attribute . . . . . . . . . . . . . . . . . 18 75 3.12 Digest-Nonce-Count attribute . . . . . . . . . . . . . . . 18 76 3.13 Digest-Username attribute . . . . . . . . . . . . . . . . 18 77 3.14 Digest-Opaque attribute . . . . . . . . . . . . . . . . . 19 78 3.15 Digest-Auth-Param attribute . . . . . . . . . . . . . . . 19 79 3.16 Digest-AKA-Auts attribute . . . . . . . . . . . . . . . . 20 80 3.17 Digest-Domain attribute . . . . . . . . . . . . . . . . . 20 81 3.18 Digest-Stale attribute . . . . . . . . . . . . . . . . . . 21 82 3.19 Digest-HA1 attribute . . . . . . . . . . . . . . . . . . . 21 83 3.20 SIP-AOR . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 4. Migration Path to Diameter . . . . . . . . . . . . . . . . . . 22 85 4.1 RADIUS Client, Diameter Server . . . . . . . . . . . . . . 22 86 4.2 Diameter Client, RADIUS Server . . . . . . . . . . . . . . 23 87 4.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . 24 88 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 25 89 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 10.1 Normative References . . . . . . . . . . . . . . . . . . . 31 95 10.2 Informative References . . . . . . . . . . . . . . . . . . 31 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 98 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 33 99 A.1 Changes from draft-ietf-radext-digest-auth-02 . . . . . . 33 100 A.2 Changes from draft-ietf-radext-digest-auth-01 . . . . . . 33 101 A.3 Changes from draft-ietf-radext-digest-auth-00 . . . . . . 33 102 A.4 Changes from draft-sterman-aaa-sip-04 . . . . . . . . . . 34 103 A.5 Changes from draft-sterman-aaa-sip-03 . . . . . . . . . . 34 104 A.6 Changes from draft-sterman-aaa-sip-02 . . . . . . . . . . 34 105 A.7 Changes from draft-sterman-aaa-sip-01 . . . . . . . . . . 34 106 Intellectual Property and Copyright Statements . . . . . . . . 35 108 1. Introduction 110 1.1 Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 HTTP-style protocol 117 a protocol using HTTP digest, like HTTP, SIP. 118 nonce 119 An unpredictable value used to prevent replay attacks. 120 protection space 121 The combination of realm and digest URI the use of which is 122 authorized by the RADIUS server. 124 1.2 Motivation 126 The HTTP Digest Authentication mechanism, defined in [RFC2617], was 127 subsequently adapted to use with SIP in [RFC2543] (obsoleted by 128 [RFC3261]). Due to the limitations and weaknesses of Digest 129 authentication (see [RFC2617], section 4), additional authentication 130 and encryption mechanisms are defined in SIP [RFC3261], including TLS 131 [RFC2246] and S/MIME [RFC2633]. However, Digest Authentication has 132 been widely implemented within SIP clients and to support those 133 clients there is a need for support of Digest Authentication within 134 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC3588]. 136 This document defines an extension to the RADIUS protocol to enable 137 support of Digest authentication, for use with SIP, HTTP, and other 138 HTTP-style protocols using this authentication method. Support for 139 Digest mechanisms such as AKA [RFC3310] is also supported. A 140 companion document [I-D.ietf-aaa-diameter-sip-app] defines support 141 for Digest authentication within Diameter. 143 1.3 Overview 145 HTTP digest is a challenge-response protocol used to authenticate a 146 client's request to access some resource on a server. Figure 1 shows 147 a single HTTP digest transaction. 149 HTTP/SIP.. 150 +------------+ (1) +------------+ 151 | |--------->| | 152 | HTTP-style | (2) | HTTP-style | 153 | Client |<---------| server | 154 | | (3) | | 155 | |--------->| | 156 | | (4) | | 157 | |<---------| | 158 +------------+ +------------+ 160 Figure 1: digest operation without RADIUS 162 If the client sends a request without any credentials (1), the server 163 will reply with an error response (2) containing a nonce. The client 164 creates a cryptographic digest from parts of the request, from the 165 nonce it received from the server, and a shared secret. The client 166 re-transmits the request (3) to the server, but now includes the 167 digest into the message. The server does the same digest calculation 168 as the client and compares the result with the digest it received in 169 (3). If the digest values are identical, the server grants access to 170 the resource and sends a positive response to the client (4). If the 171 digest values differ, the server sends a negative response to the 172 client (4). 174 Instead of maintaining a local user database, the server could use 175 RADIUS. However, RADIUS does not support HTTP digest without an 176 extension like the one described in this document. The RADIUS client 177 can not send a User-Password attribute as it does not receive a 178 password from the HTTP-style client. The RADIUS mechanism for CHAP 179 resembles HTTP digest, but the digest algorithms are not compatible. 181 This document extends RADIUS to support Digest Authentication, via 182 addition as a native authentication mechanism. An implementation 183 supporting this extension MUST include a Digest-Response attribute 184 within an Access-Request packet where Digest authentication is 185 desired. An Access-Request MUST NOT contain both a Digest-Response 186 attribute and another authentication attribute, such as User- 187 Password, CHAP-Password, or EAP-Message. 189 This document defines new attributes that enable the RADIUS server to 190 perform the digest calculation defined in [RFC2617]. 192 The nonces required by the digest algorithm are either generated by 193 the RADIUS client or by the RADIUS server. A mix of nonce generation 194 modes is not supported. 196 RADIUS clients and servers can support one, or both nonce generation 197 modes. 199 If the RADIUS server generates nonces, its RADIUS clients MUST NOT 200 try to generate nonces. If the RADIUS server does not generate 201 nonces, its RADIUS clients MUST generate nonces locally. If at least 202 one HTTP-style client requires AKA authentication [RFC3310], the 203 RADIUS server MUST generate nonces and its RADIUS clients MUST NOT 204 generate nonces locally. The nonce generation mode is a configurable 205 parameter 207 The operator MUST make sure that the RADIUS client software uses the 208 correct nonce generation mode when accessing a specific RADIUS 209 server. RADIUS clients implementing both modes MUST offer respective 210 configuration options. 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) 256 Authorization required" response (step 6). 258 1.3.2 Scenario 2, RADIUS server chooses nonces 260 In most cases, the operation outlined in Section 1.3.1 is sufficient. 261 It reduces the load on the RADIUS server to a minimum. However, when 262 using AKA [RFC3310] the nonce is partially derived from a precomputed 263 authentication vector. These authentication vectors are often stored 264 centrally. 266 Figure 3 depicts a scenario, where the RADIUS server chooses nonces. 267 It shows a generic case where entities A and B communicate in the 268 front-end using protocols such as HTTP/SIP, while entities B and C 269 communicate in the back-end using RADIUS. 271 HTTP/SIP RADIUS 273 +-----+ (1) +-----+ +-----+ 274 | |==========>| | (2) | | 275 | | | |---------->| | 276 | | | | (3) | | 277 | | (4) | |<----------| | 278 | |<==========| | | | 279 | | (5) | | | | 280 | |==========>| | | | 281 | A | | B | (6) | C | 282 | | | |---------->| | 283 | | | | (7) | | 284 | | | |<----------| | 285 | | (8) | | | | 286 | |<==========| | | | 287 +-----+ +-----+ +-----+ 289 ====> HTTP/SIP 290 ----> RADIUS 292 Figure 3: RADIUS server chooses nonces 294 The roles played by the entities in this scenario are as follows: 296 A: HTTP client / SIP UA 298 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 299 acting also as a RADIUS NAS 301 C: RADIUS server 303 The relevant order of messages sent in this scenario is as follows: 305 A sends B an HTTP/SIP request without authorization header (step 1). 306 B sends an Access-Request message with the newly defined Digest- 307 Method and Digest-URI attributes but without a Digest-Nonce attribute 308 to the RADIUS server, C (step 2). C chooses a nonce and responds 309 with an Access-Challenge (step 3). This Access-Challenge contains 310 Digest attributes, from which B takes values to construct an HTTP/SIP 311 "(Proxy) Authorization required" response. The remaining steps are 312 identical with scenario 1 (Section 1.3.1): B sends this response to A 313 (step 4). A resends its request with its credentials (step 5). B 314 sends an Access-Request to C (step 6). C checks the credentials and 315 replies with Access-Accept or Access-Reject (step 7). Dependent on 316 the C's result, B processes A's request or rejects it with a "(Proxy) 317 Authorization required" response (step 8). 319 2. Detailed Description 321 2.1 RADIUS Client Behavior 323 If the messages between RADIUS client and RADIUS server are not 324 protected with IPsec, the RADIUS client MUST NOT accept secured 325 connections (like https or sips) from its HTTP-style clients (or else 326 the HTTP-style clients would have a false sense of security). 328 On reception of an HTTP-style request message, the RADIUS client 329 checks whether it is responsible to authenticate the request. There 330 are situation where an HTTP-style request traverses several proxies, 331 and each of the proxies request to authenticate the HTTP-style 332 client. In this situation, it is a valid scenario that a HTTP-style 333 request received at a HTTP-style server contains several sets of 334 credentials. The 'realm' directive in HTTP is the key that the 335 RADIUS client can use to determine which credential is applicable. 336 It may happen also that none of the realms are of interest to the 337 RADIUS client, in which case the RADIUS client MUST consider that no 338 credentials (of interest) were sent. In any case, a RADIUS client 339 MUST send zero or exactly one credential to the RADIUS server. The 340 RADIUS client MUST choose the credential of the (Proxy-)Authorization 341 header where the realm directive matches its locally configured realm 342 value. 344 If such a header is present and contains HTTP digest information, the 345 RADIUS client checks the 'nonce' parameter. If the RADIUS client 346 generates nonces but did not issue the received nonce, it responds 347 with a 401 (Unauthorized) or 407 (Proxy Authentication Required) to 348 the HTTP-style client. In this error response, the RADIUS client 349 sends a new nonce. 351 If the RADIUS client recognizes the nonce or does not generate 352 nonces, it takes the header directives and puts them into a RADIUS 353 Access-Request message. It puts the 'response' directive into a 354 Digest-Response attribute and the realm / nonce / digest-uri / qop / 355 algorithm / cnonce / nc / username / opaque directives into the 356 respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / 357 Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- 358 Username / Digest-Opaque attributes. The request method is put into 359 the Digest-Method attribute. The RADIUS clients adds a Message- 360 Authenticator (see [RFC3579]) attribute. Now, the RADIUS client 361 sends the Access-Request message to the RADIUS server. 363 The RADIUS server processes the message and responds with an Access- 364 Accept or an Access-Reject message. 366 The RADIUS client constructs an Authentication-Info header: 367 o If the Access-Accept message contains a Digest-Response-Auth 368 attribute, the RADIUS client checks the Digest-Qop attribute: 369 * If the Digest-Qop attribute's value is 'auth' or not specified, 370 the RADIUS client puts the Digest-Response-Auth attribute's 371 content into the Authentication-Info header's 'rspauth' 372 directive of the HTTP-style response. 373 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 374 client ignores the Access-Accept message and behaves like it 375 had received an Access-Reject message (Digest-Response-Auth 376 can't be correct as the RADIUS server does not know the 377 contents of the HTTP-style response's body). 378 o If the Access-Accept message contains a Digest-HA1 attribute, the 379 RADIUS client checks the 'qop' and 'algorithm' directives in the 380 Authorization header of the HTTP-style request it wants to 381 authorize: 382 * If the 'qop' directive is missing or its value is 'auth', the 383 RADIUS client ignores the Digest-HA1 attribute. It does not 384 include an Authentication-Info header into its HTTP-style 385 response. 386 * If the 'qop' directive's value is 'auth-int' and at least one 387 of the following conditions is true, the RADIUS client 388 calculates the contents of the HTTP-style response's 'rspauth' 389 directive: 390 + The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5- 391 sess'. 392 + The messages between RADIUS client and RADIUS server are 393 protected with IPsec (see Section 8). 394 It creates the HTTP-style response message and calculates the 395 hash of this message's body. It uses the result and the 396 Digest-URI attribute's value of the corresponding Access- 397 Request message to perform the H(A2) calculation. It takes the 398 Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop 399 values of the corresponding Access-Request and the Digest-HA1 400 attribute's value to finish the computation of the 'rspauth' 401 value. 402 o If the Access-Accept message contains neither a Digest-Response- 403 Auth nor a Digest-HA1 attribute, the RADIUS client will not create 404 an Authentication-Info header for its HTTP-style response. 406 The RADIUS server MAY have added a Digest-Nextnonce attribute into an 407 Access-Accept message. If the RADIUS client discovers this, it puts 408 the contents of this attribute into a 'nextnonce' directive. Now it 409 can send an HTTP-style response. 411 If the RADIUS client did receive an HTTP-style request without a 412 (Proxy-)Authorization header matching its locally configured realm 413 value, it obtains a new nonce and sends an error response (401 or 414 407) containing a (Proxy-)Authenticate header. 416 If the RADIUS client receives an Access-Reject or no response from 417 the RADIUS server, it sends an error response to the HTTP-style 418 request it has received. 420 The RADIUS client has three ways to obtain nonces: it generates them 421 locally, it has received one in a Digest-Nextnonce attribute of a 422 previously received Access-Accept message, or it asks the RADIUS 423 server for one. To do the latter, it sends an Access-Request 424 containing a Digest-Method and a Digest-URI attribute but without a 425 Digest-Nonce attribute. It adds a Message-Authenticator (see 426 [RFC3579]) attribute to the Access-Request message. The RADIUS 427 server chooses a nonce and responds with an Access-Challenge 428 containing a Digest-Nonce attribute. 430 The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- 431 Realm, Digest-Domain and Digest-Opaque attributes in the Access- 432 Challenge carrying the nonce. If these attributes are present, the 433 client MUST use them. 435 If the RADIUS client receives an Access-Challenge message in response 436 to an Access-Request containing a Digest-Nonce attribute, the RADIUS 437 server did not accept the nonce. If a Digest-Stale attribute is 438 present in the Access-Challenge and has a value of 'true' (without 439 quotes), the RADIUS client sends an error (401 or 407) response 440 containing WWW-/Proxy-Authenticate header with the directive 'stale' 441 and the digest directives derived from the Digest-* attributes. 443 2.2 RADIUS Server Behavior 445 If the RADIUS server receives an Access-Request message with a 446 Digest-Method and a Digest-URI attribute but without a Digest-Nonce 447 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 448 attribute and sends it in an Access-Challenge message to the RADIUS 449 client. The RADIUS server MUST add Digest-Realm, Message- 450 Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or 451 more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes 452 to the Access-Challenge message. If the server cannot choose a 453 nonce, it replies with an Access-Reject message. 455 If the RADIUS server receives an Access-Request message containing a 456 Digest-Response attribute, it looks for the following attributes: 457 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, 458 Digest-Algorithm, Digest-Username. Depending on the content of 459 Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- 460 Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and 461 [RFC3310] for details. If the Digest-Algorithm attribute is missing, 462 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque 463 attribute along with the nonce, the Access-Request MUST have a 464 matching Digest-Opaque attribute. 466 If mandatory attributes are missing, it MUST respond with an Access- 467 Reject message. If the attributes are present, the RADIUS server 468 calculates the digest response as described in [RFC2617]. To look up 469 the password, the RADIUS server uses the RADIUS User-Name attribute. 470 The RADIUS server MUST check if the user identified by the User-Name 471 attribute 472 o is authorized to access the protection space defined by the 473 Digest-URI and Digest-Realm attributes, 474 o is authorized to use the URI included in the SIP-AOR attribute, if 475 this attribute is present. 476 If any of those checks fails, the RADIUS server MUST send an Access- 477 Reject. 479 Correlation between User-Name and SIP-AOR AVP values is required just 480 to avoid that any user can register or misuse a SIP-AOR allocated to 481 another user. 483 A RADIUS server MUST check if the RADIUS client is authorized to 484 serve users of the realm mentioned in the Digest-Realm attribute. If 485 the RADIUS client is not authorized, the RADIUS server silently 486 discards the Access-Request message. Other actions taken by the 487 RADIUS server are out of scope of this document. However, the RADIUS 488 server should notify the operator and may take additional action such 489 as discarding all future requests from this client, until some 490 management action tells it to do so again. 492 All values required for the digest calculation are taken from the 493 Digest attributes described in this document. If the calculated 494 digest response equals the value received in the Digest-Response 495 attribute, the authentication was successful. If not, the RADIUS 496 server responds with an Access-Reject. 498 If the authentication was successful, the RADIUS server adds an 499 attribute to the Access-Accept message which can be used by the 500 RADIUS client to construct an Authentication-Info header: 501 o If the Digest-Qop attribute's value is 'auth' or unspecified, the 502 RADIUS server SHOULD put a Digest-Response-Auth attribute into the 503 Access-Accept message 504 o If the Digest-Qop attribute's value is 'auth-int' and at least one 505 of the following conditions is true, the RADIUS server SHOULD put 506 a Digest-HA1 attribute into the Access-Accept message: 507 * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- 508 MD5-sess'. 510 * The messages between RADIUS client and RADIUS server are 511 protected with IPsec (see Section 8). 512 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be 513 sent. 515 RADIUS servers issuing nonces MAY construct a Digest-Nextnonce 516 attribute and add it to the Access-Accept message. This is useful to 517 limit the lifetime of a nonce and to save a round-trip in future 518 requests (see nextnonce discussion in [RFC2617], section 3.2.3). The 519 RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) 520 and sends the Access-Accept message to the RADIUS client. 522 If the RADIUS server does not accept the nonce received in an Access- 523 Request message but authentication was successful, the RADIUS server 524 MUST send an Access-Challenge message containing a Digest-Stale 525 attribute set to 'true' (without quotes). The RADIUS server MUST add 526 Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm, 527 SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add 528 Digest-Domain, Digest-Opaque attributes to the Access-Challenge 529 message. 531 3. New RADIUS attributes 533 The term 'HTTP-style' denotes any protocol that uses HTTP-like 534 headers and uses HTTP digest authentication as described in 535 [RFC2617]. Examples are HTTP and SIP. 537 If not stated otherwise, the attributes have the following format: 539 0 1 2 540 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Type | Length | Text ... 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 3.1 Digest-Response attribute 547 Description 548 If this attribute is present in an Access-Request message, the 549 RADIUS server MUST view the Access-Request as a Digest one. 550 When a RADIUS client receives a (Proxy-)Authorization header, 551 it puts the request-digest value into a Digest-Response 552 attribute. The attribute proves the user knows the password 553 and MUST only be used in Access-Requests. 554 Type 555 [IANA: use 102 if possible] for Digest-Response. 556 Length 557 >= 3 558 Text 559 When using HTTP digest, the text field is 32 octets long and 560 contains hexadecimal representation of 16 octet digest value as 561 it was calculated by the authenticated client. Other digest 562 algorithms MAY define different digest lengths. The text field 563 MUST be copied from request-digest of digest-response 564 ([RFC2617]) without quotes. 566 3.2 Digest-Realm attribute 568 Description 569 This attribute describes a protection space of the RADIUS 570 server. See [RFC2617] 1.2 for details. It MUST only be used 571 in Access-Request and Access-Challenge messages. 572 Type 573 [IANA: use 103 if possible] for Digest-Realm 574 Length 575 >=3 576 Text 577 In Access-Requests, the RADIUS client takes the value of the 578 realm directive (realm-value according to [RFC2617]) without 579 quotes from the HTTP-style request it wants to authenticate. 580 In Access-Challenge messages, the RADIUS server puts the 581 expected realm value into this attribute. 583 3.3 Digest-Nonce attribute 585 Description 586 This attribute holds a nonce to be used in the HTTP Digest 587 calculation. If the Access-Request had a Digest-Method and a 588 Digest-URI but no Digest-Nonce attribute and the RADIUS server 589 is configured to choose nonces, it MUST put a Digest-Nonce 590 attribute into its Access-Challenge message. This attribute 591 MUST only be used in Access-Request and Access-Challenge 592 messages. 594 Type 595 [IANA: use 104 if possible] for Digest-Nonce 596 Length 597 >=3 598 Text 599 In Access-Requests, the RADIUS client takes the value of the 600 nonce directive (nonce-value in [RFC2617]) without quotes from 601 the HTTP-style request it wants to authenticate. In Access- 602 Challenge messages, the attribute contains the nonce selected 603 by the RADIUS server. 605 3.4 Digest-Response-Auth attribute 607 Description 608 This text proves the RADIUS server knows the password. If the 609 previously received Digest-Qop attribute was 'auth-int' 610 (without quotes), the RADIUS server MUST send a Digest-HA1 611 attribute instead of Digest-Response-Auth. The Digest- 612 Response-Auth attribute MUST only be used in Access-Accept 613 messages. The RADIUS client puts the attribute value without 614 quotes into the rspauth directive of the Authentication-Info 615 header. 616 Type 617 [IANA: use 105 if possible] for Digest-Response-Auth. 618 Length 619 >= 3 620 Text 621 The RADIUS server calculates a digest according to section 622 3.2.3 of [RFC2617] and copies the result into this attribute. 623 Other digest algorithms than the one defined in [RFC2617] MAY 624 define digest lengths other than 32. 626 3.5 Digest-Nextnonce attribute 628 This attribute holds a nonce to be used in the HTTP Digest 629 calculation. 631 Description 632 If the RADIUS server is configured to choose nonces it MAY put 633 a Digest-Nextnonce attribute into an Access-Accept message. If 634 this attribute is present, the RADIUS client MUST put the 635 contents of this attribute into the nextnonce directive of an 636 Authentication-Info header in its HTTP-style response. This 637 attribute MUST only be used in Access-Accept messages. 639 Type 640 [IANA: use 106 if possible] for Digest-Nextnonce 641 Length 642 >=3 643 Text 644 It is recommended that this text be base64 or hexadecimal data. 646 3.6 Digest-Method attribute 648 Description 649 This attribute holds the method value to be used in the HTTP 650 Digest calculation. This attribute MUST only be used in 651 Access-Request messages. 652 Type 653 [IANA: use 107 if possible] for Digest-Method 654 Length 655 >=3 656 Text 657 In Access-Requests, the RADIUS client takes the value of the 658 request method from the HTTP-style request it wants to 659 authenticate. 661 3.7 Digest-URI attribute 663 Description 664 This attribute is used to transport the contents of the digest- 665 uri directive or the URI of the HTTP-style request. It MUST 666 only be used in Access-Request messages. 667 Type 668 [IANA: use 108 if possible] for Digest-URI 669 Length 670 >=3 671 Text 672 If the HTTP-style request has an Authorization header, the 673 RADIUS client puts the value of the "uri" directive in the 674 (known as "digest-uri-value" in section 3.2.2 of [RFC2617]) 675 without quotes into this attribute. If there is no 676 Authorization header, the RADIUS client takes the value of the 677 request URI from the HTTP-style request it wants to 678 authenticate. 680 3.8 Digest-Qop attribute 682 Description 683 This attribute holds the Quality of Protection parameter that 684 influences the HTTP Digest calculation. This attribute MUST 685 only be used in Access-Request and Access-Challenge messages. 686 A RADIUS client SHOULD insert one of the Digest-Qop attributes 687 it has received in a previous Access-Challenge message. RADIUS 688 servers SHOULD insert at least one Digest-Qop attribute in an 689 Access-Challenge message. Digest-Qop is optional in order to 690 preserve backward compatibility with a minimal implementation 691 of [RFC2069]. 692 Type 693 [IANA: use 109 if possible] for Digest-Qop 694 Length 695 >=3 696 Text 697 In Access-Requests, the RADIUS client takes the value of the 698 qop directive (qop-value as described in [RFC2617]) without the 699 quotes from the HTTP-style request it wants to authenticate. 700 In Access-Challenge messages, the RADIUS server puts a desired 701 qop-value into this attribute. If the RADIUS server supports 702 more than one "quality of protection" value, it puts each qop- 703 value into a separate Digest-Qop attribute. 705 3.9 Digest-Algorithm attribute 707 Type 708 This attribute holds the algorithm parameter that influences 709 the HTTP Digest calculation. It MUST only be used in Access- 710 Request and Access-Challenge messages. If this attribute is 711 missing, "MD5" is assumed. 712 Type 713 [IANA: use 110 if possible] for Digest-Algorithm 714 Length 715 >=3 716 Text 717 In Access-Requests, the RADIUS client takes the value of the 718 algorithm directive (as described in [RFC2617], section 3.2.1) 719 without the quotes from the HTTP-style request it wants to 720 authenticate. In Access-Challenge messages, the RADIUS server 721 SHOULD put the desired algorithm into this attribute. 723 3.10 Digest-Entity-Body-Hash attribute 725 Description 726 When using the qop level 'auth-int', a hash of the HTTP-style 727 message body's contents is required for digest calculation. 728 Instead of sending the complete body of the message, only its 729 hash value is sent. This hash value can be used directly in 730 the digest calculation. 732 The clarifications described in section 22.4 of [RFC2617] about 733 the hash of empty entity bodies apply to the Digest-Entity- 734 Body-Hash attribute. This attribute MUST only be sent in 735 Access-Request packets. 736 Type 737 [IANA: use 111 if possible] for Digest-Entity-Body-Hash 738 Length 739 >=3 740 Text 741 The attribute holds the hexadecimal representation of H(entity- 742 body). RADIUS clients MUST use this attribute to transport the 743 hash of the entity body when HTTP Digest is the authentication 744 mechanism and the quality of protection 'auth-int' is used. 746 3.11 Digest-CNonce attribute 748 Description 749 This attribute holds the client nonce parameter that is used in 750 the HTTP Digest calculation. It MUST only be used in Access- 751 Request messages.u 752 Type 753 [IANA: use 112 if possible] for Digest-CNonce 754 Length 755 >=3 756 Text 757 This attribute includes the value of the cnonce-value [RFC2617] 758 without quotes, taken from the HTTP-style request. 760 3.12 Digest-Nonce-Count attribute 762 Description 763 This attribute includes the nonce count parameter that is used 764 to detect replay attacks. The attribute MUST only be used in 765 Access-Request messages. 766 Type 767 [IANA: use 113 if possible] for Digest-Nonce-Count 768 Length 769 10 770 Text 771 In Access-Requests, the RADIUS client takes the value of the nc 772 directive (nc-value according to [RFC2617]) without quotes from 773 the HTTP-style request it wants to authenticate. 775 3.13 Digest-Username attribute 776 Description 777 This attribute holds the user name parameter that is used in 778 the HTTP digest calculation. The RADIUS server MUST NOT use 779 this value for password finding, but only for digest 780 calculation purpose. In order to find the user record 781 containing the password, the RADIUS server MUST use the value 782 of the ([RFC2865] -)User-Name attribute. This attribute MUST 783 only be used in Access-Request packets. 784 Type 785 [IANA: use 114 if possible] for Digest-Username 786 Length 787 >= 3 788 Text 789 In Access-Requests, the RADIUS client takes the value of the 790 username directive (username-value according to [RFC2617]) 791 without quotes from the HTTP-style request it wants to 792 authenticate. 794 3.14 Digest-Opaque attribute 796 Description 797 This attribute holds the opaque parameter that is passed to the 798 HTTP-style client. The HTTP-style client will pass this value 799 back to the server (ie the RADIUS client) without modification. 800 This attribute is only used when the RADIUS server chooses 801 nonces and MUST only be used in Access-Request and Access- 802 Challenge messages. 803 Type 804 [IANA: use 115 if possible] for Digest-Opaque 805 Length 806 >=3 807 Text 808 In Access-Requests, the RADIUS client takes the value of the 809 opaque directive (opaque-value according to [RFC2617]) without 810 quotes from the HTTP-style request it wants to authenticate and 811 puts it into this attribute. In Access-Challenge messages, the 812 RADIUS server MAY include this attribute. 814 3.15 Digest-Auth-Param attribute 816 Description 817 This attribute is a placeholder for future extensions and 818 corresponds to the "auth-param" parameter defined in section 819 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism 820 whereby the RADIUS client and RADIUS server can exchange auth- 821 param extension parameters contained within Digest headers that 822 are not understood by the RADIUS client and for which there are 823 no corresponding stand-alone attributes. 825 Unlike the previously listed Digest-* attributes, the Digest- 826 Auth-Param contains not only the value, but also the parameter 827 name, since the parameter name is unknown to the RADIUS client. 828 If the Digest header contains several unknown parameters, then 829 the RADIUS implementation MUST repeat this attribute and each 830 instance MUST contain one different unknown Digest parameter/ 831 value combination. 832 This attribute MUST ONLY be used in Access-Request, Access- 833 Challenge, or Access-Accept messages. 834 Type 835 [IANA: use 116 if possible] for Digest-Auth-Param 836 Length 837 >=3 838 Text 839 The text consists of the whole parameter, including its name 840 and the equal ('=') sign and quotes. 842 3.16 Digest-AKA-Auts attribute 844 Description 845 This attribute holds the auts parameter that is used in the 846 Digest AKA ([RFC3310]) calculation. It is only used if the 847 algorithm of the digest-response denotes a version of AKA 848 digest [RFC3310]. This attribute MUST only be used in Access- 849 Request messages. 850 Type 851 [IANA: use 117 if possible] for Digest-AKA-Auts 852 Length 853 >=3 854 Text 855 In Access-Requests, the RADIUS client takes the value of the 856 auts directive (auts-param according to section 3.4 of 857 [RFC3310]) without quotes from the HTTP-style request it wants 858 to authenticate. 860 3.17 Digest-Domain attribute 862 Description 863 When a RADIUS client has asked for a nonce, the RADIUS server 864 MAY send one or more Digest-Domain attributes in its Access- 865 Challenge message. The RADIUS client puts them into the 866 quoted, space-separated list of URIs of the 'domain' directive 867 of a WWW-Authenticate header. The URIs in the list define the 868 protection space (see [RFC2617], section 3.2.1). RADIUS 869 servers MAY send one or more attributes of this type in Access- 870 Challenge messages. This attribute MUST only be used in 871 Access-Challenge messages. 873 Type 874 [IANA: use 118 if possible] for Digest-Domain 875 Length 876 3 877 Text 878 This attribute consists of a single URI, that defines a 879 protection space. 881 3.18 Digest-Stale attribute 883 Description 884 This attribute is sent by a RADIUS server in order to notify 885 the RADIUS client whether it has accepted a nonce. If the 886 nonce presented by the RADIUS client was stale, the value is 887 'true' and is 'false' otherwise. The RADIUS client puts the 888 content of this attribute into a 'stale' directive of the WWW- 889 Authenticate header in the HTTP-style response to the request 890 it wants to authenticate. The attribute MUST only be used in 891 Access-Challenge messages and only if the RADIUS server chooses 892 nonces. 893 Type 894 [IANA: use 119 if possible] for Digest-Stale 895 Length 896 3 897 Text 898 The attribute has either the value 'true' or 'false' (both 899 values without quotes). 901 3.19 Digest-HA1 attribute 903 Description 904 This attribute is used to allow the generation of an 905 Authentication-Info header, even if the HTTP-style response's 906 body is required for the calculation of the rspauth value. It 907 SHOULD be used in Access-Accept messages if the required 908 quality of protection ('qop') is 'auth-int'. 909 This attribute MUST NOT be sent if the qop parameter was not 910 specified or has a value of 'auth' (in this case, use Digest- 911 Response-Auth instead). 912 The Digest-HA1 attribute MUST only be sent by the RADIUS server 913 or processed by the RADIUS client if at least one of the 914 following conditions is true: 915 + The Digest-Algorithm attribute's value is 'MD5-sess' or 916 'AKAv1-MD5-sess'. 917 + The messages between RADIUS client and RADIUS server are 918 protected with IPsec (see Section 8). 920 This attribute MUST only be used in Access-Accept messages. 921 Type 922 [IANA: use 120 if possible] for Digest-HA1 923 Length 924 >= 3 925 Text 926 This attribute contains the hexadecimal representation of H(A1) 927 as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2. 929 3.20 SIP-AOR 931 Type 932 This attribute is used for the authorization of SIP messages. 933 The SIP-AOR attribute identifies the URI the use of which must 934 be authenticated and authorized. The RADIUS server uses this 935 attribute to authorize the processing of the SIP request. The 936 SIP-AOR can be derived from, e.g., the To header field in a SIP 937 REGISTER request (user under registration), or the From header 938 field in other SIP requests. However, the exact mapping of 939 this attribute to SIP can change due to new developments in the 940 protocol. 941 This attribute MUST only be used when the RADIUS client wants 942 to authorize SIP users and MUST only be used in Access-Request 943 messages. 944 Type 945 [IANA:use 121 if possible] for SIP-AOR 946 Length 947 >=3 948 Text 949 The syntax of this attribute corresponds either to a SIP URI 950 (with the format defined in [RFC3261] or a TEL URI (with the 951 format defined in [RFC3966]). 952 The SIP-AOR attribute holds the complete URI, including 953 parameters and other parts. It is up to the RADIUS server what 954 components of the URI are regarded in the authorization 955 decision. 957 4. Migration Path to Diameter 959 The attributes specified in this document correspond to some AVPs 960 defined in [I-D.ietf-aaa-diameter-sip-app]. 962 4.1 RADIUS Client, Diameter Server 964 If an Access-Request message contains a Digest-Nonce attribute, the 965 gateway maps all Digest-* attributes to a Diameter SIP-Authorization 966 AVP. If the Access-Request message contains a Digest-Method and a 967 Digest-URI attribute but no Digest-Nonce attribute, the gateway maps 968 the RADIUS attributes to Diameter AVPs. The gateway constructs a MAR 969 message and sends it to the Diameter server. 971 The Diameter Server responds with a MAA message. This message 972 contains a Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH 973 and challenge parameters in a SIP-Authenticate AVP. The gateway 974 translates the AVPs of SIP-Authenticate AVP and puts the resulting 975 RADIUS attributes into an Access-Challenge message. It sends the 976 Access-Challenge message to the RADIUS client. 978 The gateway maps an Access-Request message containing a Digest- 979 Response attribute to an MAR message with a Diameter SIP- 980 Authorization AVP. All RADIUS attributes of the Access-Request 981 message are mapped to the corresponding Diameter AVPs. The gateway 982 sends the MAR message to the Diameter server. 984 If the authentication was successful, the Diameter server replies 985 with an MAA containing a SIP-Authentication-Info and a Digest- 986 Response AVP. The gateway converts these AVPs to the corresponding 987 RADIUS attributes and constructs a RADIUS message. If the Result- 988 Code AVP is Diameter_SUCCESS, an Access-Accept is sent. In all other 989 cases, an Access-Reject is sent. 991 If the Diameter found the nonce to be stale, it will respond with a 992 new challenge in a SIP-Authenticate AVP of an MAA message. The 993 gateway handles this MAA like the first MAA message containing 994 challenge parameters, as described in above. 996 4.2 Diameter Client, RADIUS Server 998 The Diameter client sends a Diameter MAR to the gateway. If the MAR 999 message does not contain SIP-Auth-Data-Item AVPs, the gateway 1000 constructs an Access-Request message and maps the SIP-AOR and SIP- 1001 Method AVPs to RADIUS attributes. The gateway sends the Access- 1002 Request message to the RADIUS server which will respond with an 1003 Access-Challenge. The gateway creates a MAA message with a Result- 1004 Code AVP set to DIAMETER_MULTI_ROUND_AUTH and maps the Digest-* 1005 attributes to Diameter AVPs in a SIP-Authenticate AVP. The gateway 1006 sends the resulting MAA to the Diameter client, which will respond 1007 with a new MAR. 1009 The gateway checks the SIP-Auth-Data-Item AVPs of this MAR for an AVP 1010 where the Digest-Realm AVP matches the locally configured realm 1011 value. It takes the AVPs from this SIP-Auth-Data-Item AVP, converts 1012 them into the corresponding RADIUS attributes and constructs a RADIUS 1013 Access-Request message. The gateway sends the Access-Request message 1014 to the RADIUS server. If the RADIUS server responds with an Access- 1015 Accept message, the gateway converts the RADIUS attributes to 1016 Diameter AVPs, constructs a MAR with a Result-Code AVP set to 1017 DIAMETER_SUCCESS and sends this message to the Diameter client. If 1018 the RADIUS server responds with an Access-Reject message, the gateway 1019 converts the RADIUS attributes to Diameter AVPs, constructs a MAR 1020 with a Result-Code AVP set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH 1021 and sends this message to the Diameter client. 1023 4.3 Limitations 1025 This document covers not all functionality found in [I-D.ietf-aaa- 1026 diameter-sip-app]. 1027 o There is no equivalent to Diameter's UAR/UAA, SAR/SAA, LIR/LIA, 1028 RTR/RTA and PPR/PPA messages 1029 o The operational mode where the Diameter server sends the expected 1030 digest response to the client is not supported. 1032 The operational mode where the RADIUS client chooses nonces is not 1033 supported in [I-D.ietf-aaa-diameter-sip-app]. 1035 5. Table of Attributes 1037 The following table provides a guide to which attributes may be found 1038 in which kinds of packets, and in what quantity. 1040 +-------------------------+-----+-----+--------+--------+-----------+ 1041 | Attribute | # | Req | Accept | Reject | Challenge | 1042 +-------------------------+-----+-----+--------+--------+-----------+ 1043 | User-Name | TBD | 1 | 0 | 0 | 0 | 1044 | Message-Authenticator | TBD | 1 | 1 | 1 | 1 | 1045 | Digest-Response | TBD | 0-1 | 0 | 0 | 0 | 1046 | Digest-Realm | TBD | 0-1 | 0 | 0 | 1 | 1047 | Digest-Nonce | TBD | 0-1 | 0 | 0 | 1 | 1048 | Digest-Response-Auth | TBD | 0 | 0-1 | 0 | 0 | 1049 | (see Note 1, 2) | | | | | | 1050 | Digest-Nextnonce | TBD | 0 | 0-1 | 0 | 0 | 1051 | Digest-Method | TBD | 0-1 | 0 | 0 | 0 | 1052 | Digest-URI | TBD | 0-1 | 0 | 0 | 0 | 1053 | Digest-Qop | TBD | 0-1 | 0 | 0 | 1+ | 1054 | Digest-Algorithm (see | TBD | 0-1 | 0 | 0 | 0-1 | 1055 | Note 3) | | | | | | 1056 | Digest-Entity-Body-Hash | TBD | 0-1 | 0 | 0 | 0 | 1057 | Digest-CNonce | TBD | 0-1 | 0 | 0 | 0 | 1058 | Digest-Nonce-Count | TBD | 0-1 | 0 | 0 | 0 | 1059 | Digest-Username | TBD | 0-1 | 0 | 0 | 0 | 1060 | Digest-Opaque | TBD | 0-1 | 0 | 0 | 0-1 | 1061 | Digest-Auth-Param | TBD | 0+ | 0+ | 0 | 0+ | 1062 | Digest-AKA-Auts | TBD | 0-1 | 0 | 0 | 0 | 1063 | Digest-Domain | TBD | 0 | 0 | 0 | 0-1 | 1064 | Digest-Stale | TBD | 0 | 0 | 0 | 0-1 | 1065 | Digest-HA1 (see Note 1, | TBD | 0 | 0-1 | 0 | 0 | 1066 | 2) | | | | | | 1067 | SIP-AOR | TBD | 0-1 | 0 | 0 | 0 | 1068 +-------------------------+-----+-----+--------+--------+-----------+ 1070 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if 1071 Digest-Qop is 'auth-int'. 1072 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if 1073 Digest-Qop is 'auth'. 1074 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed 1076 6. Example 1078 This is an example sniffed from the traffic between a softphone (A), 1079 a Proxy Server (B) and example.com RADIUS server (C). The 1080 communication between the Proxy Server and a SIP PSTN gateway is 1081 omitted for brevity. The SIP messages are not shown completely. 1083 A->B 1085 INVITE sip:97226491335@example.com SIP/2.0 1086 From: 1087 To: 1089 B->A 1091 SIP/2.0 100 Trying 1093 B->A 1095 SIP/2.0 407 Proxy Authentication Required 1096 Proxy-Authenticate: Digest realm="example.com" 1097 ,nonce="3bada1a0", algorithm="md5" 1098 Content-Length: 0 1100 A->B 1102 ACK sip:97226491335@example.com SIP/2.0 1104 A->B 1106 INVITE sip:97226491335@example.com SIP/2.0 1107 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1108 ,opaque="",realm="example.com" 1109 ,response="f3ce87e6984557cd0fecc26f3c5e97a4" 1110 ,uri="sip:97226491335@10.0.69.38",username="12345678" 1111 From: 1112 To: 1114 B->C 1116 Code = 1 (Access-Request) 1117 Attributes: 1118 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1119 NAS-Port-Type = 5 (Virtual) 1120 User-Name = "12345678" 1121 Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" 1122 Digest-Realm = "example.com" 1123 Digest-Nonce = "3bada1a0" 1124 Digest-Method = "INVITE" 1125 Digest-URI = "sip:97226491335@example.com" 1126 Digest-Algorithm = "md5" 1127 Digest-Username = "12345678" 1128 SIP-AOR = "sip:12345678@example.com" 1130 C->B 1132 Code = 2 (Access-Accept) 1133 Attributes: 1134 Digest-Response-Auth = 1135 "6303c41b0e2c3e524e413cafe8cce954" 1137 B->A 1139 SIP/2.0 180 Ringing 1141 B->A 1143 SIP/2.0 200 OK 1145 A->B 1147 ACK sip:97226491335@example.com SIP/2.0 1149 A second example shows the traffic between a web browser (A), web 1150 server (B) and a RADIUS server (C). 1152 A->B 1154 GET /index.html HTTP/1.1 1156 B->A 1158 HTTP/1.1 407 Authentication Required 1159 WWW-Authenticate: Digest realm="example.com", 1160 domain="/index.html", 1161 nonce="a3086ac8", algorithm="md5" 1162 Content-Length: 0 1164 A->B 1166 GET /index.html HTTP/1.1 1167 Authorization: Digest algorithm="md5",nonce="a3086ac8" 1168 ,opaque="",realm="example.com" 1169 ,response="f052b68058b2987aba493857ae1ab002" 1170 ,uri="/index.html",username="12345678" 1172 B->C 1174 Code = 1 (Access-Request) 1175 Attributes: 1176 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1177 NAS-Port-Type = 5 (Virtual) 1178 User-Name = "12345678" 1179 Digest-Response = "f052b68058b2987aba493857ae1ab002" 1180 Digest-Realm = "example.com" 1181 Digest-Nonce = "a3086ac8" 1182 Digest-Method = "GET" 1183 Digest-URI = "/index.html"" 1184 Digest-Algorithm = "md5" 1185 Digest-Username = "12345678" 1187 C->B 1189 Code = 2 (Access-Accept) 1190 Attributes: 1191 Digest-Response-Auth = 1192 "e644aa513effbfe1caff67103ff6433c" 1194 B->A 1196 HTTP/1.1 200 OK 1197 ... 1199 1200 ... 1202 7. IANA Considerations 1204 This document serves as IANA registration request for a number of 1205 values from the RADIUS attribute type number space: 1207 +-------------------------+------------------------+ 1208 | placeholder | value assigned by IANA | 1209 +-------------------------+------------------------+ 1210 | Digest-Response | TBD | 1211 | Digest-Realm | TBD | 1212 | Digest-Nonce | TBD | 1213 | Digest-Nextnonce | TBD | 1214 | Digest-Response-Auth | TBD | 1215 | Digest-Method | TBD | 1216 | Digest-URI | TBD | 1217 | Digest-Qop | TBD | 1218 | Digest-Algorithm | TBD | 1219 | Digest-Entity-Body-Hash | TBD | 1220 | Digest-CNonce | TBD | 1221 | Digest-Nonce-Count | TBD | 1222 | Digest-Username | TBD | 1223 | Digest-Opaque | TBD | 1224 | Digest-Auth-Param | TBD | 1225 | Digest-AKA-Auts | TBD | 1226 | Digest-Domain | TBD | 1227 | Digest-Stale | TBD | 1228 | Digest-HA1 | TBD | 1229 | SIP-AOR | TBD | 1230 +-------------------------+------------------------+ 1232 Table 2 1234 8. Security Considerations 1236 The RADIUS extensions described in this document make RADIUS a 1237 transport protocol for the data that is required to perform a digest 1238 calculation. It adds the vulnerabilities of HTTP Digest (see 1239 [RFC2617], section 4) to those of RADIUS (see [RFC2865], Section 8 or 1240 Section 4 of [RFC3579]). 1242 If an attacker gains control over a RADIUS client or RADIUS proxy, he 1243 can perform man-in-the-middle attacks even if the paths between A, B 1244 and B, C (Figure 2) have been secured with TLS or IPsec. 1246 The RADIUS server MUST check the Digest-Realm attribute it has 1247 received from a client. If the RADIUS client is not authorized to 1248 serve HTTP-style clients of that realm, it might be compromised. 1250 RADIUS clients implementing the extension described in this document 1251 authenticate layer 3 requests received from the Internet. This is in 1252 contrast to the original use of RADIUS, where layer 2 sessions are 1253 authenticated. In layer 2 access networks, attackers can usually 1254 tracked down more easily. 1256 An attacker could try to overload the RADIUS infrastructure by 1257 excessively sending HTTP-style requests. To make simple denial of 1258 service attacks more difficult, the nonce issuer (RADIUS client or 1259 server) MUST check if it has generated the nonce received from an 1260 HTTP-style client. This SHOULD be done statelessly. For example, a 1261 nonce could consist of a cryptographically random part and some kind 1262 of signature of the RADIUS client, as described in [RFC2617], section 1263 3.2.1. 1265 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm 1266 attributes in Access-Challenge messages. A man in the middle can 1267 modify or remove those attributes in a bidding down attack. In this 1268 case, the RADIUS client would use a weaker authentication scheme than 1269 intended. RfC 3579 [RFC3579], section 3.2 describes a Message- 1270 Authenticator attribute which MUST be used to improve the integrity 1271 protection of RADIUS messages. The RADIUS server can use this 1272 attribute to verify the identity of the RADIUS client. 1274 The Digest-HA1 attribute contains no random components if the 1275 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1276 attacks easier and can be used for replay attacks. 1278 HTTP-style clients can use TLS with server side certificates together 1279 with HTTP-Digest authentication. Instead of TLS, IPsec can be used, 1280 too. TLS or IPsec secure the connection while Digest Authentication 1281 authenticates the user. The RADIUS transaction can be regarded as 1282 one leg on the path between the HTTP-style client and the HTTP-style 1283 server. To prevent the RADIUS transaction from being the weakest hop 1284 on the path, a RADIUS client receiving an HTTP-style request via TLS 1285 or IPsec MUST use an equally secure connection to the RADIUS server. 1286 There are two ways to achieve this: 1287 o the RADIUS client rejects HTTP-style requests received over TLS or 1288 IPsec 1289 o the operator of the RADIUS client takes actions to ensure that 1290 RADIUS traffic is exclusively sent and received using IPsec. 1291 When using IPsec, it MUST be set up as described [RFC3579] section 1292 4.2. 1294 9. Acknowledgments 1296 We would like to acknowledge Kevin McDermott (Cisco Systems) /or 1297 providing comments and experimental implementation. 1299 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1300 Arkko, Avi Lior and Jun Wang. 1302 10. References 1304 10.1 Normative References 1306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1307 Requirement Levels", BCP 14, RFC 2119, March 1997. 1309 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1310 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1311 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1313 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1314 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1315 Authentication: Basic and Digest Access Authentication", 1316 RFC 2617, June 1999. 1318 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1319 "Remote Authentication Dial In User Service (RADIUS)", 1320 RFC 2865, June 2000. 1322 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1323 A., Peterson, J., Sparks, R., Handley, M., and E. 1324 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1325 June 2002. 1327 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1328 Protocol (HTTP) Digest Authentication Using Authentication 1329 and Key Agreement (AKA)", RFC 3310, September 2002. 1331 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1332 Dial In User Service) Support For Extensible 1333 Authentication Protocol (EAP)", RFC 3579, September 2003. 1335 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1336 RFC 3966, December 2004. 1338 10.2 Informative References 1340 [I-D.ietf-aaa-diameter-sip-app] 1341 Garcia-Martin, M., "Diameter Session Initiation Protocol 1342 (SIP) Application", draft-ietf-aaa-diameter-sip-app-07 1343 (work in progress), March 2005. 1345 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1346 Recommendations for Security", RFC 1750, December 1994. 1348 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 1349 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 1350 HTTP : Digest Access Authentication", RFC 2069, 1351 January 1997. 1353 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1354 RFC 2246, January 1999. 1356 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1357 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1358 March 1999. 1360 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1361 RFC 2633, June 1999. 1363 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1364 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1366 Authors' Addresses 1368 Baruch Sterman 1369 Kayote Networks 1370 P.O. Box 1373 1371 Efrat 90435 1372 Israel 1374 Email: baruch@kayote.com 1376 Daniel Sadolevsky 1377 SecureOL, Inc. 1378 Jerusalem Technology Park 1379 P.O. Box 16120 1380 Jerusalem 91160 1381 Israel 1383 Email: dscreat@dscreat.com 1385 David Schwartz 1386 Kayote Networks 1387 P.O. Box 1373 1388 Efrat 90435 1389 Israel 1391 Email: david@kayote.com 1392 David Williams 1393 Cisco Systems 1394 7025 Kit Creek Road 1395 P.O. Box 14987 1396 Research Triangle Park NC 27709 1397 USA 1399 Email: dwilli@cisco.com 1401 Wolfgang Beck 1402 Deutsche Telekom AG 1403 Am Kavalleriesand 3 1404 Darmstadt 64295 1405 Germany 1407 Email: beckw@t-systems.com 1409 Appendix A. Change Log 1411 RFC editor: please remove this section prior to RFC publication. 1413 A.1 Changes from draft-ietf-radext-digest-auth-02 1415 o removed mentioning of extensions in Digest-Entity-Body-Hash -- AKA 1416 Digest is still covered by the spec 1417 o re-inserted Diameter migration path section 1419 A.2 Changes from draft-ietf-radext-digest-auth-01 1421 o removed Diameter migration path section 1422 o Included Digest-URI and Digest-Realm in the authorization 1423 decision, not just in the digest calculation 1424 o RADIUS server must check if a RADIUS client is authorized to serve 1425 the realm mentioned in Digest-Realm 1426 o moved 'Detailed Description' sections in front of 'New RADIUS 1427 attributes' section 1428 o replaced 'IPsec or otherwise secured connection' with IPsec 1429 o changed MAY to SHOULD for Digest-Algorithm in Access-Challenge 1430 o changed type of Digest-Entity-Body-Hash to text (all other H(..) 1431 result attributes are hex and text, too) 1432 o new abstract 1433 o Terminology section changed 1434 o 'Changes' section as appendix 1436 A.3 Changes from draft-ietf-radext-digest-auth-00 1437 o SIP-AOR attribute added 1438 o clarified use of Digest-Qop 1439 o attribute overview table added 1441 A.4 Changes from draft-sterman-aaa-sip-04 1443 o clarified usage of Digest-HA1 1444 o clarified usage of Digest-Stale (is sent in an Access-Challenge 1445 now) 1446 o clarified allowed attribute usage for message types 1447 o changed attribute type to 'Text' where the corresponding Diameter 1448 AVPs have a UTF8String 1449 o added Diameter client - RADIUS server handling 1451 A.5 Changes from draft-sterman-aaa-sip-03 1453 o addressed 'auth-int' issue 1454 o New Digest-Nextnonce attribute 1455 o revised abstract, motivational section and examples 1456 o Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce 1457 attribute' 1458 o shortened SIP messages in example, removed real-world addresses 1459 and product names 1461 A.6 Changes from draft-sterman-aaa-sip-02 1463 o Relaxed restrictions for Digest-Domain, Digest-Realm, Digest- 1464 Opaque, Digest-Qop and Digest-Algorithm 1465 o Additional security considerations for Digest-Domain, Digest-Qop 1466 and Digest-Algorithm usage in Access-Accept messages 1468 A.7 Changes from draft-sterman-aaa-sip-01 1470 o Replaced Sub-attributes with flat attributes 1471 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1472 o Added how a server must treat unknown attributes. 1473 o Added a section 'Migration path to Diameter' 1474 o Added an optional attribute for support of the digest scheme 1475 described in informational [RFC3310]. 1476 o Added a mode of operation where the RADIUS server chooses the 1477 nonce. This was required for AKA [RFC3310], but can be useful for 1478 ordinary Digest authentication when the qop directive is not used. 1479 This required the addition of several attributes. 1481 Intellectual Property Statement 1483 The IETF takes no position regarding the validity or scope of any 1484 Intellectual Property Rights or other rights that might be claimed to 1485 pertain to the implementation or use of the technology described in 1486 this document or the extent to which any license under such rights 1487 might or might not be available; nor does it represent that it has 1488 made any independent effort to identify any such rights. Information 1489 on the procedures with respect to rights in RFC documents can be 1490 found in BCP 78 and BCP 79. 1492 Copies of IPR disclosures made to the IETF Secretariat and any 1493 assurances of licenses to be made available, or the result of an 1494 attempt made to obtain a general license or permission for the use of 1495 such proprietary rights by implementers or users of this 1496 specification can be obtained from the IETF on-line IPR repository at 1497 http://www.ietf.org/ipr. 1499 The IETF invites any interested party to bring to its attention any 1500 copyrights, patents or patent applications, or other proprietary 1501 rights that may cover technology that may be required to implement 1502 this standard. Please address the information to the IETF at 1503 ietf-ipr@ietf.org. 1505 Disclaimer of Validity 1507 This document and the information contained herein are provided on an 1508 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1509 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1510 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1511 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1512 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1513 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1515 Copyright Statement 1517 Copyright (C) The Internet Society (2005). This document is subject 1518 to the rights, licenses and restrictions contained in BCP 78, and 1519 except as set forth therein, the authors retain all their rights. 1521 Acknowledgment 1523 Funding for the RFC Editor function is currently provided by the 1524 Internet Society.