idnits 2.17.1 draft-ietf-radext-digest-auth-01.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.a on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1440. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 36 instances of lines with control characters in the document. == 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 == Line 53 has weird spacing: '...cribing the a...' -- 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 (February 20, 2005) is 6998 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) == Unused Reference: 'RFC2616' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'RFC3588' is defined on line 1360, 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-06 -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- 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: 10 errors (**), 0 flaws (~~), 8 warnings (==), 11 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: August 24, 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 February 20, 2005 13 RADIUS Extension for Digest Authentication 14 draft-ietf-radext-digest-auth-01.txt 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all provisions 19 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 20 author represents that any applicable patent or other IPR claims of 21 which he or she is aware have been or will be disclosed, and any of 22 which he or she become aware will be disclosed, in accordance with 23 RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 24, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 48 Several protocols use the authentication mechanisms of the Hypertext 49 Transfer Protocol, HTTP. This document specifies an extension to the 50 Remote Authentication Dial In User Service (RADIUS) that allows a 51 RADIUS client in an HTTP-style server, upon reception of a request, 52 retrieve and compute Digest authentication information from a RADIUS 53 server. Additionally, a scenario describing the authentication of a 54 user emitting an HTTP-style request is provided. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3.1 Scenario 1, RADIUS client chooses nonces . . . . . . . 6 63 1.3.2 Scenario 2, RADIUS server chooses nonces . . . . . . . 7 64 2. New RADIUS attributes . . . . . . . . . . . . . . . . . . . . 9 65 2.1 Digest-Response attribute . . . . . . . . . . . . . . . . 9 66 2.2 Digest-Realm attribute . . . . . . . . . . . . . . . . . . 9 67 2.3 Digest-Nonce attribute . . . . . . . . . . . . . . . . . . 10 68 2.4 Digest-Response-Auth attribute . . . . . . . . . . . . . . 10 69 2.5 Digest-Nextnonce attribute . . . . . . . . . . . . . . . . 11 70 2.6 Digest-Method attribute . . . . . . . . . . . . . . . . . 11 71 2.7 Digest-URI attribute . . . . . . . . . . . . . . . . . . . 11 72 2.8 Digest-Qop attribute . . . . . . . . . . . . . . . . . . . 12 73 2.9 Digest-Algorithm attribute . . . . . . . . . . . . . . . . 12 74 2.10 Digest-Entity-Body-Hash attribute . . . . . . . . . . . . 12 75 2.11 Digest-CNonce attribute . . . . . . . . . . . . . . . . . 13 76 2.12 Digest-Nonce-Count attribute . . . . . . . . . . . . . . . 13 77 2.13 Digest-Username attribute . . . . . . . . . . . . . . . . 14 78 2.14 Digest-Opaque attribute . . . . . . . . . . . . . . . . . 14 79 2.15 Digest-Auth-Param attribute . . . . . . . . . . . . . . . 14 80 2.16 Digest-AKA-Auts attribute . . . . . . . . . . . . . . . . 15 81 2.17 Digest-Domain attribute . . . . . . . . . . . . . . . . . 15 82 2.18 Digest-Stale attribute . . . . . . . . . . . . . . . . . . 16 83 2.19 Digest-HA1 attribute . . . . . . . . . . . . . . . . . . . 16 84 2.20 SIP-AOR . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 3. Detailed Description . . . . . . . . . . . . . . . . . . . . . 18 86 3.1 RADIUS Client Behavior . . . . . . . . . . . . . . . . . . 18 87 3.2 RADIUS Server Behavior . . . . . . . . . . . . . . . . . . 20 88 4. Migration Path to Diameter . . . . . . . . . . . . . . . . . . 22 89 4.1 RADIUS Client, Diameter Server . . . . . . . . . . . . . . 22 90 4.2 Diameter Client, RADIUS Server . . . . . . . . . . . . . . 22 91 4.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . 23 92 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 24 93 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 96 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 9.1 Changes from draft-ietf-radext-digest-auth-00 . . . . . . 33 98 9.2 Changes from draft-sterman-aaa-sip-04 . . . . . . . . . . 33 99 9.3 Changes from draft-sterman-aaa-sip-03 . . . . . . . . . . 33 100 9.4 Changes from draft-sterman-aaa-sip-02 . . . . . . . . . . 33 101 9.5 Changes from draft-sterman-aaa-sip-01 . . . . . . . . . . 33 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 103 10.1 Normative References . . . . . . . . . . . . . . . . . . . 34 104 10.2 Informative References . . . . . . . . . . . . . . . . . . 34 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36 106 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 107 Intellectual Property and Copyright Statements . . . . . . . . 39 109 1. Introduction 111 1.1 Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 This document uses terminology from [RFC2617] and [RFC2865] 119 1.2 Motivation 121 Digest authentication is a simple authentication mechanism for HTTP 122 and SIP. While it was not too successful in HTTP environments, it is 123 the only SIP authentication mechanism that has been widely adopted. 124 Due to the limitations and weaknesses of Digest authentication (see 125 [RFC2617], section 4), additional PKI-based authentication and 126 encryption mechanisms have been introduced into SIP: TLS [RFC2246] 127 and S/MIME [RFC2633]. The majority of today's SIP clients only 128 supports HTTP digest. 130 Current RADIUS-based AAA infrastructures have been built and debugged 131 over years. Some deficiencies of RADIUS have been mitigated with 132 proprietary extensions. Operators are therefore reluctant to replace 133 their RADIUS infrastructure in order to enable a single new 134 authentication mechanism. 136 Given the complexity of the alternatives, simple clients will 137 continue to support HTTP digest authentication only. Its 138 interoperability with a back-end authentication protocol such as 139 RADIUS is needed. 141 Operators that are about to replace their RADIUS-based AAA 142 infrastructure are strongly recommended to use Diameter. 144 1.3 Overview 146 Figure 1 depicts the basic scenario that is relevant for this 147 document. 'HTTP-style Client' and 'RADIUS Client' are entities using 148 a protocol with support for HTTP Digest Authentication, like SIP or 149 HTTP. 151 HTTP/SIP RADIUS 152 +------------+ +--------+ +--------+ 153 | HTTP-style | | RADIUS | | RADIUS | 154 | Client |<========>| Client |<------->| Server | 155 | | | | | | 156 +------------+ +--------+ +--------+ 158 Figure 1: Overview of operation 160 The approach taken here is to extend RADIUS to support Digest 161 authentication by mimicking its native support for CHAP 162 authentication. According to [RFC2865], the RADIUS server 163 distinguishes between different authentication schemes by looking at 164 the presence of an attribute specific for that scheme. For the three 165 natively supported authentication schemes, these attributes are: 166 User-Password for PAP (or any other clear-text password scheme), 167 CHAP-Password for CHAP, and State + User- Password for 168 challenge-response scheme. This document adds another attribute to 169 be used in this role: Digest-Response. Also according to [RFC2865], 170 "An Access-Request packet MUST contain either a User-Password or a 171 CHAP-Password or a State. It MUST NOT contain both a User-Password 172 and a CHAP-Password. If future extensions allow other kinds of 173 authentication information to be conveyed, the attribute for that can 174 be used instead of User-Password or CHAP-Password." The 175 Digest-Response introduced here therefore can be used instead of 176 User-Password or CHAP-Password. 178 The HTTP Authentication parameters found in the Proxy-Authorization 179 or Authorization request header are mapped into newly defined RADIUS 180 attributes. These new RADIUS attributes are defined in the document 181 together with some other information required for calculating the 182 correct digest response on the RADIUS server with exception of the 183 password, which the RADIUS server is assumed to be able to retrieve 184 from a data store given the username. 186 The nonces required by the digest algorithm are either generated by 187 the RADIUS client or by the RADIUS server. A mix of nonce generation 188 modes is not supported. If the RADIUS server generates nonces, its 189 RADIUS clients MUST NOT try to generate nonces. If the RADIUS server 190 does not generate nonces, its RADIUS clients MUST generate nonces 191 locally. If at least one HTTP-style client requires AKA 192 authentication [RFC3310], the RADIUS server MUST generate nonces and 193 its RADIUS clients MUST NOT generate nonces locally. 195 1.3.1 Scenario 1, RADIUS client chooses nonces 197 HTTP/SIP RADIUS 199 +-----+ (1) +-----+ +-----+ 200 | |==========>| | | | 201 | | (2) | | | | 202 | |<==========| | | | 203 | | (3) | | | | 204 | |==========>| | | | 205 | A | | B | (4) | C | 206 | | | |---------->| | 207 | | | | (5) | | 208 | | | |<----------| | 209 | | (6) | | | | 210 | |<==========| | | | 211 +-----+ +-----+ +-----+ 213 ====> HTTP/SIP 214 ----> RADIUS 216 Figure 2: RADIUS client chooses nonces 218 The roles played by the entities in this scenario are as follows: 220 A: HTTP client / SIP UA 222 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 223 acting also as a RADIUS NAS (RADIUS client) 225 C: RADIUS server 227 The relevant order of messages sent in this scenario is as follows: 229 A sends B an HTTP/SIP request without authorization header (step 1). 230 B challenges A sending an HTTP/SIP "407 / 401 (Proxy) Authorization 231 required" response containing a locally generated nonce (step 2). A 232 sends B an HTTP/SIP request with authorization header (step 3). B 233 sends C a RADIUS Access-Request with attributes described in this 234 document (step 4). C responds to B with a RADIUS 235 Access-Accept/Access-Reject response (step 5). If credentials were 236 accepted B receives an Access-Accept response and the message sent 237 from A is considered authentic. If B receives an Access-Reject 238 response, however, B then responds to A with a "407 / 401 (Proxy) 239 Authorization required" response (step 6). 241 1.3.2 Scenario 2, RADIUS server chooses nonces 243 In most cases, the operation outlined in Section 1.3.1 is sufficient. 244 It reduces the load on the RADIUS server to a minimum. However, when 245 using AKA [RFC3310] the nonce is partially derived from a precomputed 246 authentication vector. These authentication vectors are often stored 247 centrally. 249 Figure 3 depicts a scenario, where the RADIUS server chooses nonces. 250 It shows a generic case where entities A and B communicate in the 251 front-end using protocols such as HTTP/SIP, while entities B and C 252 communicate in the back-end using RADIUS. 254 HTTP/SIP RADIUS 256 +-----+ (1) +-----+ +-----+ 257 | |==========>| | (2) | | 258 | | | |---------->| | 259 | | | | (3) | | 260 | | (4) | |<----------| | 261 | |<==========| | | | 262 | | (5) | | | | 263 | |==========>| | | | 264 | A | | B | (6) | C | 265 | | | |---------->| | 266 | | | | (7) | | 267 | | | |<----------| | 268 | | (8) | | | | 269 | |<==========| | | | 270 +-----+ +-----+ +-----+ 272 ====> HTTP/SIP 273 ----> RADIUS 275 Figure 3: RADIUS server chooses nonces 277 The roles played by the entities in this scenario are as follows: 279 A: HTTP client / SIP UA 281 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 282 acting also as a RADIUS NAS 284 C: RADIUS server 286 The relevant order of messages sent in this scenario is as follows: 288 A sends B an HTTP/SIP request without authorization header (step 1). 289 B sends an Access-Request message with the newly defined 290 Digest-Method and Digest-URI attributes but without a Digest-Nonce 291 attribute to the RADIUS server, C (step 2). C chooses a nonce and 292 responds with an Access-Challenge (step 3). This Access-Challenge 293 contains Digest attributes, from which B takes values to construct an 294 HTTP/SIP "(Proxy) Authorization required" response. The remaining 295 steps are identical with scenario 1 (Section 1.3.1): B sends this 296 response to A (step 4). A resends its request with its credentials 297 (step 5). B sends an Access-Request to C (step 6). C checks the 298 credentials and replies with Access-Accept or Access-Reject (step 7). 299 Dependent on the C's result, B processes A's request or rejects it 300 with a "(Proxy) Authorization required" response (step 8). 302 2. New RADIUS attributes 304 The term 'HTTP-style' denotes any protocol that uses HTTP-like 305 headers and uses HTTP digest authentication as described in 306 [RFC2617]. Examples are HTTP and SIP. 308 If not stated otherwise, the attributes have the following format: 310 0 1 2 311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Type | Length | String... 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 2.1 Digest-Response attribute 318 If this attribute is present in an Access-Request message, the RADIUS 319 server SHOULD view the Access-Request as a Digest one. When a RADIUS 320 client receives a (Proxy-)Authorization header, it puts the 321 request-digest value into a Digest-Response attribute. 323 Type 324 [IANA: use 102 if possible] for Digest-Response. 325 Length 326 >= 3 327 Text 328 This attribute MUST only be used in Access-Requests. It proves 329 the user knows the password. The text field is usually 32 330 octets long and contains hexadecimal representation of 16 octet 331 digest value as it was calculated by the authenticated client. 332 The text field SHOULD be copied from request-digest of 333 digest-response ([RFC2617]) without quotes. 335 2.2 Digest-Realm attribute 337 This attribute describes a protection space of the RADIUS server. 338 See [RFC2617] 1.2 for details. 340 Type 342 [IANA: use 103 if possible] for Digest-Realm 343 Length 344 >=3 345 Text 346 In Access-Requests, the RADIUS client takes the value of the 347 realm directive (realm-value according to [RFC2617]) without 348 quotes from the HTTP-style request it wants to authenticate. 349 In Access-Challenge messages, the RADIUS server puts the 350 expected realm value into this attribute. This attribute MUST 351 only be used in Access-Request and Access-Challenge messages. 353 2.3 Digest-Nonce attribute 355 This attribute holds a random nonce to be used in the HTTP Digest 356 calculation. 358 Type 359 [IANA: use 104 if possible] for Digest-Nonce 360 Length 361 >=3 362 Text 363 In Access-Requests, the RADIUS client takes the value of the 364 nonce directive (nonce-value in [RFC2617]) without quotes from 365 the HTTP-style request it wants to authenticate. If the 366 Access-Request had a Digest-Method and a Digest-URI but no 367 Digest-Nonce attribute and the RADIUS server is configured to 368 choose nonces, it MUST put a Digest-Nonce attribute into its 369 Access-Challenge message. This attribute MUST only be used in 370 Access-Request and Access-Challenge messages. 372 2.4 Digest-Response-Auth attribute 374 Type 375 [IANA: use 105 if possible] for Digest-Response-Auth. 376 Length 377 >= 3 378 Text 379 This attribute MUST only be used in Access-Accept messages. 380 This text proves the RADIUS server knows the password. The 381 RADIUS server calculates a digest according to section 3.2.3 of 382 [RFC2617] and copies the result into this attribute. The 383 RADIUS client puts the attribute value without quotes into the 384 rspauth directive of the Authentication-Info header. If the 385 previously received Digest-Qop attribute was 'auth-int' 386 (without quotes), the RADIUS server MUST send a Digest-HA1 387 attribute instead of Digest-Response-Auth. 389 2.5 Digest-Nextnonce attribute 391 This attribute holds a random nonce to be used in the HTTP Digest 392 calculation. 394 Type 395 [IANA: use 106 if possible] for Digest-Nextnonce 396 Length 397 >=3 398 Text 399 If the RADIUS server is configured to choose nonces it MAY put 400 a Digest-Nextnonce attribute into an Access-Accept message. If 401 this attribute is present, the RADIUS client MUST put the 402 contents of this attribute into the nextnonce directive of an 403 Authentication-Info header in its HTTP-style response. This 404 attribute MUST only be used in Access-Accept messages. 406 2.6 Digest-Method attribute 408 This attribute holds the method string to be used in the HTTP Digest 409 calculation. 411 Type 412 [IANA: use 107 if possible] for Digest-Method 413 Length 414 >=3 415 Text 416 In Access-Requests, the RADIUS client takes the value of the 417 request method from the HTTP-style request it wants to 418 authenticate. This attribute MUST only be used in 419 Access-Request messages. 421 2.7 Digest-URI attribute 423 This attribute holds the URI string to be used in the HTTP Digest 424 calculation. 426 Type 427 [IANA: use 108 if possible] for Digest-URI 428 Length 429 >=3 430 Text 431 If the HTTP-style request has an Authorization header, the 432 RADIUS client puts the value of the "uri" directive in the 433 (known as "digest-uri-value" in Section 3.2.2 of [RFC2617]) 434 without quotes into this attribute. If there is no 435 Authorization header, the RADIUS client takes the value of the 436 request URI from the HTTP-style request it wants to 437 authenticate. The attribute MUST only be used in 438 Access-Request messages. 440 2.8 Digest-Qop attribute 442 This attribute holds the Quality of Protection parameter that 443 influences the HTTP Digest calculation. 445 Type 446 [IANA: use 109 if possible] for Digest-Qop 447 Length 448 >=3 449 Text 450 In Access-Requests, the RADIUS client takes the value of the 451 qop directive (qop-value as described in [RFC2617]) without the 452 quotes from the HTTP-style request it wants to authenticate. 453 In Access-Challenge messages, the RADIUS server SHOULD put the 454 desired qop-value into this attribute. If the RADIUS server 455 supports more than one "quality of protection" value, it puts 456 each qop-value into a separate Digest-Qop attribute. This 457 attribute MUST only be used in Access-Request and 458 Access-Challenge messages. 460 2.9 Digest-Algorithm attribute 462 This attribute holds the algorithm parameter that influences the HTTP 463 Digest calculation. 465 Type 466 [IANA: use 110 if possible] for Digest-Algorithm 467 Length 468 >=3 469 Text 470 In Access-Requests, the RADIUS client takes the value of the 471 algorithm directive (as described in [RFC2617], section 3.2.1) 472 without the quotes from the HTTP-style request it wants to 473 authenticate. In Access-Challenge messages, the RADIUS server 474 MAY put the desired algorithm into this attribute. This 475 attribute MUST only be used in Access-Request and 476 Access-Challenge messages. 478 2.10 Digest-Entity-Body-Hash attribute 480 When using the qop level 'auth-int', a hash of the message body's 481 contents is required for digest calculation. Instead of sending the 482 complete body of the message, only its hash value is sent. This hash 483 value can be used directly in the digest calculation. 485 Type 486 [IANA: use 111 if possible] for Digest-Entity-Body-Hash 487 Length 488 >=3 489 String 490 The Digest-Entity-Body-Hash attribute contains a hash of the 491 entity body contained in the SIP message. This hash is 492 required by certain authentication mechanisms, such as HTTP 493 Digest with quality of protection set to "auth-int". RADIUS 494 clients MUST use this attribute to transport the hash of the 495 entity body when HTTP Digest is the authentication mechanism 496 and the RADIUS server requires to verify the integrity of the 497 entity body (e.g., qop parameter set to "auth-int"). 498 Extensions to this document may define support for 499 authentication mechanisms other than HTTP Digest. 500 The clarifications described in Section 22.4 of [RFC2617] about 501 the hash of empty entity bodies apply to the 502 Digest-Entity-Body-Hash attribute. This attribute MUST only be 503 sent in Access-Request packets. 505 2.11 Digest-CNonce attribute 507 This attribute holds the client nonce parameter that is used in the 508 HTTP Digest calculation. 510 Type 511 [IANA: use 112 if possible] for Digest-CNonce 512 Length 513 >=3 514 Text 515 In Access-Requests, the RADIUS client takes the value of the 516 cnonce directive (cnonce-value according to [RFC2617]) without 517 quotes from the HTTP-style request it wants to authenticate. 518 This attribute MUST only be used in Access-Request messages. 520 2.12 Digest-Nonce-Count attribute 522 This attribute holds the nonce count parameter that is used to detect 523 replay attacks. 525 Type 526 [IANA: use 113 if possible] for Digest-Nonce-Count 527 Length 528 10 529 Text 530 In Access-Requests, the RADIUS client takes the value of the nc 531 directive (nc-value according to [RFC2617]) without quotes from 532 the HTTP-style request it wants to authenticate. The attribute 533 MUST only be used in Access-Request messages. 535 2.13 Digest-Username attribute 537 This attribute holds the user name parameter that is used in the HTTP 538 digest calculation. 540 Type 541 [IANA: use 114 if possible] for Digest-Username 542 Length 543 >= 3 544 Text 545 In Access-Requests, the RADIUS client takes the value of the 546 username directive (username-value according to [RFC2617]) 547 without quotes from the HTTP-style request it wants to 548 authenticate. The RADIUS server SHOULD NOT use this value for 549 password finding, but only for digest calculation purpose. In 550 order to find the user record containing the password, the 551 RADIUS server SHOULD use the value of the ([RFC2865] 552 -)User-Name attribute. This attribute MUST only be used in 553 Access-Request packets. 555 2.14 Digest-Opaque attribute 557 This attribute holds the opaque parameter that is passed to the 558 HTTP-style client. The HTTP-style client will pass this value back 559 to the server (ie the RADIUS client) without modification. 561 Type 562 [IANA: use 115 if possible] for Digest-Opaque 563 Length 564 >=3 565 Text 566 This attribute is only used when the RADIUS server chooses 567 nonces. In Access-Requests, the RADIUS client takes the value 568 of the opaque directive (opaque-value according to [RFC2617]) 569 without quotes from the HTTP-style request it wants to 570 authenticate and puts it into this attribute. In 571 Access-Challenge messages, the RADIUS server MAY include this 572 attribute. This attribute MUST only be used in Access-Request 573 and Access-Challenge messages. 575 2.15 Digest-Auth-Param attribute 577 This attribute is a placeholder for future extensions. 579 Type 580 [IANA: use 116 if possible] for Digest-Auth-Param 581 Length 582 >=3 583 Text 584 The Digest-Auth-Param is the mechanism whereby the RADIUS 585 client and RADIUS server can exchange possible extension 586 parameters contained in Digest headers that are not understood 587 by the RADIUS client and for which there are no corresponding 588 stand-alone attributes. Unlike the previously listed Digest-* 589 attributes, the Digest-Auth-Param contains not only the value, 590 but also the parameter name, since the parameter name is 591 unknown to the RADIUS client. If the Digest header contains 592 several unknown parameters, then the RADIUS implementation MUST 593 repeat this attribute and each instance MUST contain one 594 different unknown Digest parameter/value combination. This 595 attribute corresponds to the "auth-param" parameter defined in 596 section 3.2.1 of [RFC2617]. 597 The text consists of the whole parameter, including its name 598 and the equal ('=') sign and quotes. This attribute MAY be 599 used in any type of RADIUS messages. 601 2.16 Digest-AKA-Auts attribute 603 This attribute holds the auts parameter that is used in the Digest 604 AKA ([RFC3310]) calculation. 606 Type 607 [IANA: use 117 if possible] for Digest-AKA-Auts 608 Length 609 >=3 610 Text 611 In Access-Requests, the RADIUS client takes the value of the 612 auts directive (auts-param according to section 3.4 of 613 [RFC3310]) without quotes from the HTTP-style request it wants 614 to authenticate. It is only used if the algorithm of the 615 digest-response denotes a version of AKA digest [RFC3310]. 616 This attribute MUST only be used in Access-Request messages. 618 2.17 Digest-Domain attribute 620 When a RADIUS client has asked for a nonce, the RADIUS server MAY 621 send one or more Digest-Domain attributes in its Access-Challenge 622 message. The RADIUS client puts them into the quoted, 623 space-separated list of URIs of the 'domain' directive of a 624 WWW-Authenticate header. The URIs in the list define the protection 625 space (see [RFC2617], section 3.2.1). 627 Type 628 [IANA: use 118 if possible] for Digest-Domain 629 Length 630 3 631 Text 632 This attribute consists of a single URI, that defines a 633 protection space. RADIUS servers MAY send one or more 634 attributes of this type in Access-Challenge messages. This 635 attribute MUST only be used in Access-Challenge messages. 637 2.18 Digest-Stale attribute 639 The RADIUS server uses this attribute to tell whether it has accepted 640 a nonce. 642 Type 643 [IANA: use 119 if possible] for Digest-Stale 644 Length 645 3 646 Text 647 The attribute has either the value 'true' or 'false' (both 648 values without quotes). If the nonce presented by the RADIUS 649 client was stale, the value is 'true' and is 'false' otherwise. 650 The RADIUS client puts the content of this attribute into a 651 'stale' directive of the WWW-Authenticate header in the 652 HTTP-style response to the request it wants to authenticate. 653 The attribute MUST only be used in Access-Challenge messages 654 and only if the RADIUS server chooses nonces. 656 2.19 Digest-HA1 attribute 658 This attribute is used to allow the generation of an 659 Authentication-Info header, even if the HTTP-style response's body is 660 required for the calculation of the rspauth value. 662 Type 663 [IANA: use 120 if possible] for Digest-HA1 664 Length 665 >= 3 666 Text 667 This attribute contains the hexadecimal representation of H(A1) 668 as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2. 669 It SHOULD be used in Access-Accept messages if the required 670 quality of protection ('qop') is 'auth-int'. 671 This attribute MUST NOT be sent if the qop parameter was not 672 specified or has a value of 'auth' (in this case, use 673 Digest-Response-Auth instead). 675 The Digest-HA1 attribute MUST only be sent by the RADIUS server 676 or processed by the RADIUS client if at least one of the 677 following conditions is true: 678 + The Digest-Algorithm attribute's value is 'MD5-sess' or 679 'AKAv1-MD5-sess'. 680 + The authenticity and integrity of the Access-Accept message 681 is secured by cryptographic or equivalently secure means. 682 This attribute MUST only be used in Access-Accept messages. 684 2.20 SIP-AOR 686 This attribute is for the authorization of SIP messages. 688 Type 689 [IANA:use 121 if possible] for SIP-AOR 690 Length 691 >=3 692 String 693 The syntax of this attribute corresponds either to a SIP URI 694 (with the format defined in [RFC3261] or a TEL URI (with the 695 format defined in [RFC3966]). 696 The SIP-AOR attribute identifies the URI the use of which must 697 be authenticated and authorized. The RADIUS server uses this 698 attribute to authorize the processing of the SIP request. The 699 SIP-AOR can be derived from, e.g., the To header field in a SIP 700 REGISTER request (user under registration), or the From header 701 field in other SIP requests. However, the exact mapping of 702 this attribute to SIP can change due to new developments in the 703 protocol. 704 This attribute MUST only be used when the RADIUS client wants 705 to authorize SIP users and MUST only be used in Access-Request 706 messages. 708 3. Detailed Description 710 3.1 RADIUS Client Behavior 712 If a RADIUS client has no encrypted or otherwise secured connection 713 to its RADIUS server, it MUST NOT accept secured connections (like 714 https or sips) from its HTTP-style clients (or else the HTTP-style 715 clients would have a false sense of security). 717 On reception of an HTTP-style request message, the RADIUS client 718 checks whether it is responsible to authenticate the request. There 719 are situation where an HTTP-style request traverses several proxies, 720 and each of the proxies request to authenticate the HTTP-style 721 client. In this situation, it is a valid scenario that a HTTP-style 722 request received at a HTTP-style server contains several sets of 723 credentials. The 'realm' directive in HTTP is the key that the 724 RADIUS client can use to determine which credential is applicable. 725 It may happen also that none of the realms are of interests to the 726 RADIUS client, in which case the RADIUS client MUST consider that no 727 credentials (of interest) were sent. In any case, a RADIUS client 728 MUST send zero or exactly one credential to the RADIUS server. The 729 RADIUS client MUST choose the credential of the (Proxy-)Authorization 730 header where the realm directive matches its locally configured realm 731 value. If such a header is present and contains HTTP digest 732 information, the RADIUS client checks the 'nonce' parameter. If the 733 RADIUS client generates nonces but did not issue the received nonce, 734 it responds with a 401 (Unauthorized) or 407 (Proxy Authentication 735 Required) to the HTTP-style client. In this error response, the 736 RADIUS client sends a new nonce. 738 If the RADIUS client recognizes the nonce or does not generate 739 nonces, it takes the header directives and puts them into a RADIUS 740 Access-Request message. It puts the 'response' directive into a 741 Digest-Response attribute and the realm / nonce / digest-uri / qop / 742 algorithm / cnonce / nc / username / opaque directives into the 743 respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / 744 Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / 745 Digest-Username / Digest-Opaque attributes. The request method is 746 put into the Digest-Method attribute. Now, the RADIUS client sends 747 the Access-Request message to the RADIUS server. 749 The RADIUS server processes the message and responds with an 750 Access-Accept or an Access-Reject message. 752 The RADIUS client constructs an Authentication-Info header: 753 o If the Access-Accept message contains a Digest-Response-Auth 754 attribute, the RADIUS client checks the Digest-Qop attribute: 756 * If the Digest-Qop attribute's value is 'auth' or not specified, 757 the RADIUS client puts the Digest-Response-Auth attribute's 758 content into the Authentication-Info header's 'rspauth' 759 directive of the HTTP-style response. 760 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 761 client ignores the Access-Accept message and behaves like it 762 had received an Access-Reject message (Digest-Response-Auth 763 can't be correct as the RADIUS server does not know the 764 contents of the HTTP-style response's body). 765 o If the Access-Accept message contains a Digest-HA1 attribute, the 766 RADIUS client checks the 'qop' and 'algorithm' directives in the 767 Authorization header of the HTTP-style request it wants to 768 authorize: 769 * If the 'qop' directive is missing or its value is 'auth', the 770 RADIUS client ignores the Digest-HA1 attribute. It does not 771 include an Authentication-Info header into its HTTP-style 772 response. 773 * If the 'qop' directive's value is 'auth-int' and at least one 774 of the following conditions is true, the RADIUS client 775 calculates the contents of the HTTP-style response's 'rspauth' 776 directive: 777 + The algorithm directive's value is 'MD5-sess' or 778 'AKAv1-MD5-sess'. 779 + The Access-Accept message was secured by cryptographic or 780 equivalently secure means. 781 It creates the HTTP-style response message and calculates the 782 hash of this message's body. It uses the result and the 783 Digest-URI attribute's value of the corresponding 784 Access-Request message to perform the H(A2) calculation. It 785 takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and 786 Digest-Qop values of the corresponding Access-Request and the 787 Digest-HA1 attribute's value to finish the computation of the 788 'rspauth' value. 789 o If the Access-Accept message contains neither a 790 Digest-Response-Auth nor a Digest-HA1 attribute, the RADIUS client 791 will not create an Authentication-Info header for its HTTP-style 792 response. 794 The RADIUS server MAY have added a Digest-Nextnonce attribute into an 795 Access-Accept message. If the RADIUS client discovers this, it puts 796 the contents of this attribute into a 'nextnonce' directive. Now it 797 can send an HTTP-style response. 799 If the RADIUS client did receive an HTTP-style request without a 800 (Proxy-)Authorization header matching its locally configured realm 801 value, it obtains a new nonce and sends an error response (401 or 802 407) containing a (Proxy-)Authenticate header. 804 If the RADIUS client receives an Access-Reject or no response from 805 the RADIUS server, it sends an error response to the HTTP-style 806 request it has received. 808 The RADIUS client has three ways to obtain nonces: it generates them 809 locally, it has received one in a Digest-Nextnonce attribute of a 810 previously received Access-Accept message, or it asks the RADIUS 811 server for one. To do the latter, it sends an Access-Request 812 containing a Digest-Method and a Digest-URI attribute but without a 813 Digest-Nonce attribute. The RADIUS server chooses a nonce and 814 responds with an Access-Challenge containing a Digest-Nonce 815 attribute. 817 The RADIUS server can send Digest-Qop, Digest-Algorithm, 818 Digest-Realm, Digest-Domain and Digest-Opaque attributes in the 819 Access-Challenge carrying the nonce. If these attributes are 820 present, the client MUST use them. 822 If the RADIUS client receives an Access-Challenge message in response 823 to an Access-Request containing a Digest-Nonce attribute, the RADIUS 824 server did not accept the nonce. If a Digest-Stale attribute is 825 present in the Access-Challenge and has a value of 'true' (without 826 quotes), the RADIUS client sends an error (401 or 407) response 827 containing WWW-/Proxy-Authenticate header with the directive 'stale' 828 and the digest directives derived from the Digest-* attributes. 830 3.2 RADIUS Server Behavior 832 If the RADIUS server receives an Access-Request message with a 833 Digest-Method and a Digest-URI attribute but without a Digest-Nonce 834 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 835 attribute and sends it in an Access-Challenge message to the RADIUS 836 client. The RADIUS server MUST add Digest-Algorithm, Digest-Realm, 837 SHOULD add one or more Digest-Qop and MAY add Digest-Domain, 838 Digest-Opaque attributes to the Access-Challenge message. If the 839 server cannot choose a nonce, it replies with an Access-Reject 840 message. 842 If the RADIUS server receives an Access-Request message containing a 843 Digest-Response attribute, it looks for the following attributes: 844 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, 845 Digest-Algorithm, Digest-Username. Depending on the content of 846 Digest-Algorithm and Digest-Qop, it looks for 847 Digest-Entity-Body-Hash, Digest-CNonce and Digest-AKA-Auts, too. See 848 [RFC2617] and [RFC3310] for details. If it has issued a 849 Digest-Opaque attribute along with the nonce, the Access-Request MUST 850 have a matching Digest-Opaque attribute. 852 If mandatory attributes are missing, it MUST respond with an 853 Access-Reject message. If the attributes are present, the RADIUS 854 server calculates the digest response as described in [RFC2617]. To 855 look up the password, the RADIUS server uses the RADIUS User-Name 856 attribute. The RADIUS server MUST check if the user identified by 857 User-Name attribute is authorized to use the the URI included in the 858 SIP-AOR attribute. If this authorization fails, the RADIUS server 859 MUST send an Access-Reject. 861 Correlation between User-Name and SIP-AOR AVP values is required just 862 to avoid that any user can register or misuse a SIP-AOR allocated to 863 another user. 865 All other values are taken from the Digest attributes described in 866 this document. If the calculated digest response equals the string 867 received in the Digest-Response attribute, the authentication was 868 successful. If not, the RADIUS server responds with an 869 Access-Reject. 871 If the authentication was successful, the RADIUS server adds an 872 attribute to the Access-Accept message which can be used by the 873 RADIUS client to construct an Authentication-Info header: 874 o If the Digest-Qop attribute's value is 'auth' or unspecified, the 875 RADIUS server SHOULD put a Digest-Response-Auth attribute into the 876 Access-Accept message 877 o If the Digest-Qop attribute's value is 'auth-int' and at least one 878 of the following conditions is true, the RADIUS server SHOULD put 879 a Digest-HA1 attribute into the Access-Accept message: 880 * The Digest-Algorithm attribute's value is 'MD5-sess' or 881 'AKAv1-MD5-sess'. 882 * The authenticity and integrity of the Access-Accept message is 883 secured by cryptographic or equivalently secure means. 884 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be 885 sent. 887 RADIUS servers issuing nonces MAY construct a Digest-Nextnonce 888 attribute and add it to the Access-Accept message. This is useful to 889 limit the lifetime of a nonce and to save a round-trip in future 890 requests (see nextnonce discussion in [RFC2617], section 3.2.3). 892 If the RADIUS server does not accept the nonce received in an 893 Access-Request message but authentication was successful, the RADIUS 894 server MUST send an Access-Challenge message containing a 895 Digest-Stale attribute set to 'true' (without quotes). The RADIUS 896 server MUST add Digest-Nonce, Digest-Algorithm, Digest-Realm, SHOULD 897 add one or more Digest-Qop and MAY add Digest-Domain, Digest-Opaque 898 attributes to the Access-Challenge message. 900 4. Migration Path to Diameter 902 The attributes specified in this document correspond to some AVPs 903 defined in [I-D.ietf-aaa-diameter-sip-app]. 905 4.1 RADIUS Client, Diameter Server 907 If an Access-Request message contains a Digest-Nonce attribute, the 908 gateway maps all Digest-* attributes to a Diameter SIP-Authorization 909 AVP. If the Access-Request message contains a Digest-Method and a 910 Digest-URI attribute but no Digest-Nonce attribute, the gateway maps 911 the RADIUS attributes to Diameter AVPs. The gateway constructs a MAR 912 message and sends it to the Diameter server. 914 The Diameter Server responds with a MAA message. This message 915 contains a Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH 916 and challenge parameters in a SIP-Authenticate AVP. The gateway 917 translates the AVPs of SIP-Authenticate AVP and puts the resulting 918 RADIUS attributes into an Access-Challenge message. It sends the 919 Access-Challenge message to the RADIUS client. 921 The gateway maps an Access-Request message containing a 922 Digest-Response attribute to an MAR message with a Diameter 923 SIP-Authorization AVP. All RADIUS attributes of the Access-Request 924 message are mapped to the corresponding Diameter AVPs. The gateway 925 sends the MAR message to the Diameter server. 927 If the authentication was successful, the Diameter server replies 928 with an MAA containing a SIP-Authentication-Info and a 929 Digest-Response AVP. The gateway converts these AVPs to the 930 corresponding RADIUS attributes and constructs a RADIUS message. If 931 the Result-Code AVP is Diameter_SUCCESS, an Access-Accept is sent. 932 In all other cases, an Access-Reject is sent. 934 If the Diameter found the nonce to be stale, it will respond with a 935 new challenge in a SIP-Authenticate AVP of an MAA message. The 936 gateway handles this MAA like the first MAA message containing 937 challenge parameters, as described in above. 939 4.2 Diameter Client, RADIUS Server 941 The Diameter client sends a Diameter MAR to the gateway. If the MAR 942 message does not contain SIP-Auth-Data-Item AVPs, the gateway 943 constructs an Access-Request message and maps the SIP-AOR and 944 SIP-Method AVPs to RADIUS attributes. The gateway sends the 945 Access-Request message to the RADIUS server which will respond with 946 an Access-Challenge. The gateway creates a MAA message with a 947 Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH and maps the 948 Digest-* attributes to Diameter AVPs in a SIP-Authenticate AVP. The 949 gateway sends the resulting MAA to the Diameter client, which will 950 respond with a new MAR. 952 The gateway checks the SIP-Auth-Data-Item AVPs of this MAR for an AVP 953 where the Digest-Realm AVP matches the locally configured realm 954 value. It takes the AVPs from this SIP-Auth-Data-Item AVP, converts 955 them into the corresponding RADIUS attributes and constructs a RADIUS 956 Access-Request message. The gateway sends the Access-Request message 957 to the RADIUS server. If the RADIUS server responds with an 958 Access-Accept message, the gateway converts the RADIUS attributes to 959 Diameter AVPs, constructs a MAR with a Result-Code AVP set to 960 DIAMETER_SUCCESS and sends this message to the Diameter client. If 961 the RADIUS server responds with an Access-Reject message, the gateway 962 converts the RADIUS attributes to Diameter AVPs, constructs a MAR 963 with a Result-Code AVP set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH 964 and sends this message to the Diameter client. 966 4.3 Limitations 968 This document covers not all functionality found in 969 [I-D.ietf-aaa-diameter-sip-app]. 970 o There is no equivalent to Diameter's UAR/UAA, SAR/SAA, LIR/LIA, 971 RTR/RTA and PPR/PPA messages 972 o The operational mode where the Diameter server sends the expected 973 digest response to the client is not supported. 975 The operational mode where the RADIUS client chooses nonces is not 976 supported in [I-D.ietf-aaa-diameter-sip-app]. 978 5. Table of Attributes 980 The following table provides a guide to which attributes may be found 981 in which kinds of packets, and in what quantity. 983 +-------------------------+-----+-----+--------+--------+-----------+ 984 | Attribute | # | Req | Accept | Reject | Challenge | 985 +-------------------------+-----+-----+--------+--------+-----------+ 986 | Digest-Response | TBD | 0-1 | 0 | 0 | 0 | 987 | | | | | | | 988 | Digest-Realm | TBD | 0-1 | 0 | 0 | 1 | 989 | | | | | | | 990 | Digest-Nonce | TBD | 0-1 | 0 | 0 | 1 | 991 | | | | | | | 992 | Digest-Response-Auth | TBD | 0 | 0-1 | 0 | 0 | 993 | | | | | | | 994 | Digest-Nextnonce | TBD | 0 | 0-1 | 0 | 0 | 995 | | | | | | | 996 | Digest-Method | TBD | 0-1 | 0 | 0 | 0 | 997 | | | | | | | 998 | Digest-URI | TBD | 0-1 | 0 | 0 | 0 | 999 | | | | | | | 1000 | Digest-Qop | TBD | 0-1 | 0 | 0 | 1+ | 1001 | | | | | | | 1002 | Digest-Algorithm | TBD | 0-1 | 0 | 0 | 0-1 | 1003 | | | | | | | 1004 | Digest-Entity-Body-Hash | TBD | 0-1 | 0 | 0 | 0 | 1005 | | | | | | | 1006 | Digest-CNonce | TBD | 0-1 | 0 | 0 | 0 | 1007 | | | | | | | 1008 | Digest-Nonce-Count | TBD | 0-1 | 0 | 0 | 0 | 1009 | | | | | | | 1010 | Digest-Username | TBD | 0-1 | 0 | 0 | 0 | 1011 | | | | | | | 1012 | Digest-Opaque | TBD | 0-1 | 0 | 0 | 0-1 | 1013 | | | | | | | 1014 | Digest-Auth-Param | TBD | 0+ | 0+ | 0+ | 0+ | 1015 | | | | | | | 1016 | Digest-AKA-Auts | TBD | 0-1 | 0 | 0 | 0 | 1017 | | | | | | | 1018 | Digest-Domain | TBD | 0 | 0 | 0 | 0-1 | 1019 | | | | | | | 1020 | Digest-Stale | TBD | 0 | 0 | 0 | 0-1 | 1021 | | | | | | | 1022 | Digest-HA1 | TBD | 0 | 0-1 | 0 | 0 | 1023 | | | | | | | 1024 | SIP-AOR | TBD | 0-1 | 0 | 0 | 0 | 1025 +-------------------------+-----+-----+--------+--------+-----------+ 1027 6. Example 1029 This is an example sniffed from the traffic between a softphone (A), 1030 a Proxy Server (B) and example.com RADIUS server (C). The 1031 communication between the Proxy Server and a SIP PSTN gateway is 1032 omitted for brevity. The SIP messages are not shown completely. 1034 A->B 1036 INVITE sip:97226491335@example.com SIP/2.0 1037 From: 1038 To: 1040 B->A 1042 SIP/2.0 100 Trying 1044 B->A 1046 SIP/2.0 407 Proxy Authentication Required 1047 Proxy-Authenticate: Digest realm="example.com" 1048 ,nonce="3bada1a0", algorithm="md5" 1049 Content-Length: 0 1051 A->B 1053 ACK sip:97226491335@example.com SIP/2.0 1055 A->B 1057 INVITE sip:97226491335@example.com SIP/2.0 1058 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1059 ,opaque="",realm="example.com" 1060 ,response="f3ce87e6984557cd0fecc26f3c5e97a4" 1061 ,uri="sip:97226491335@10.0.69.38",username="12345678" 1062 From: 1063 To: 1065 B->C 1067 Code = 1 (Access-Request) 1068 Attributes: 1069 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1070 NAS-Port-Type = 5 (Virtual) 1071 User-Name = "12345678" 1072 Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" 1073 Digest-Realm = "example.com" 1074 Digest-Nonce = "3bada1a0" 1075 Digest-Method = "INVITE" 1076 Digest-URI = "sip:97226491335@example.com" 1077 Digest-Algorithm = "md5" 1078 Digest-Username = "12345678" 1079 SIP-AOR = "sip:12345678@example.com" 1081 C->B 1083 Code = 2 (Access-Accept) 1084 Attributes: 1085 Digest-Response-Auth = 1086 "6303c41b0e2c3e524e413cafe8cce954" 1088 B->A 1090 SIP/2.0 180 Ringing 1092 B->A 1094 SIP/2.0 200 OK 1096 A->B 1098 ACK sip:97226491335@example.com SIP/2.0 1100 A second example shows the traffic between a web browser (A), web 1101 server (B) and a RADIUS server (C). 1103 A->B 1105 GET /index.html HTTP/1.1 1107 B->A 1109 HTTP/1.1 407 Authentication Required 1110 WWW-Authenticate: Digest realm="example.com", 1111 domain="/index.html", 1112 nonce="a3086ac8", algorithm="md5" 1113 Content-Length: 0 1115 A->B 1117 GET /index.html HTTP/1.1 1118 Authorization: Digest algorithm="md5",nonce="a3086ac8" 1119 ,opaque="",realm="example.com" 1120 ,response="f052b68058b2987aba493857ae1ab002" 1121 ,uri="/index.html",username="12345678" 1123 B->C 1125 Code = 1 (Access-Request) 1126 Attributes: 1127 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1128 NAS-Port-Type = 5 (Virtual) 1129 User-Name = "12345678" 1130 Digest-Response = "f052b68058b2987aba493857ae1ab002" 1131 Digest-Realm = "example.com" 1132 Digest-Nonce = "a3086ac8" 1133 Digest-Method = "GET" 1134 Digest-URI = "/index.html"" 1135 Digest-Algorithm = "md5" 1136 Digest-Username = "12345678" 1138 C->B 1140 Code = 2 (Access-Accept) 1141 Attributes: 1142 Digest-Response-Auth = 1143 "e644aa513effbfe1caff67103ff6433c" 1145 B->A 1147 HTTP/1.1 200 OK 1148 ... 1150 1151 ... 1153 7. IANA Considerations 1155 This document serves as IANA registration request for a number of 1156 values from the RADIUS attribute type number space: 1158 +-------------------------+------------------------+ 1159 | placeholder | value assigned by IANA | 1160 +-------------------------+------------------------+ 1161 | Digest-Response | TBD | 1162 | | | 1163 | Digest-Realm | TBD | 1164 | | | 1165 | Digest-Nonce | TBD | 1166 | | | 1167 | Digest-Nextnonce | TBD | 1168 | | | 1169 | Digest-Response-Auth | TBD | 1170 | | | 1171 | Digest-Method | TBD | 1172 | | | 1173 | Digest-URI | TBD | 1174 | | | 1175 | Digest-Qop | TBD | 1176 | | | 1177 | Digest-Algorithm | TBD | 1178 | | | 1179 | Digest-Entity-Body-Hash | TBD | 1180 | | | 1181 | Digest-CNonce | TBD | 1182 | | | 1183 | Digest-Nonce-Count | TBD | 1184 | | | 1185 | Digest-Username | TBD | 1186 | | | 1187 | Digest-Opaque | TBD | 1188 | | | 1189 | Digest-Auth-Param | TBD | 1190 | | | 1191 | Digest-AKA-Auts | TBD | 1192 | | | 1193 | Digest-Domain | TBD | 1194 | | | 1195 | Digest-Stale | TBD | 1196 | | | 1197 | Digest-HA1 | TBD | 1198 | | | 1199 | SIP-AOR | TBD | 1200 +-------------------------+------------------------+ 1201 Table 2 1203 8. Security Considerations 1205 The RADIUS extensions described in this document make RADIUS a 1206 transport protocol for the data that is required to perform a digest 1207 calculation. It adds the vulnerabilities of HTTP Digest (see 1208 [RFC2617], section 4) to those of RADIUS (see [RFC2865], section 8 or 1209 here [1])). 1211 If an attacker gets access to a RADIUS client or RADIUS proxy, it can 1212 perform man-in-the-middle attacks even if the connections between A, 1213 B and B, C (Figure 2) have been secured with TLS or IPSec. 1215 SIP or HTTP requests occur much more frequently than dial-in 1216 requests. RADIUS servers implementing this specification must meet 1217 that additional performance requirements. An attacker could try to 1218 overload the RADIUS infrastructure by excessively sending SIP or HTTP 1219 requests. This kind of attack was more difficult when RADIUS was 1220 just used for dial-in authentication: the attacker could be 1221 identified by the DSL / Cable interface or with some help of the PSTN 1222 provider. 1224 To make simple denial of service attacks more difficult, the nonce 1225 issuer (RADIUS client or server) MUST check if it has generated the 1226 nonce received from an HTTP-style client. This SHOULD be done 1227 statelessly. For example, a nonce could consist of a 1228 cryptographically random part and some kind of signature of the 1229 RADIUS client, as described in [RFC2617], section 3.2.1. 1231 RADIUS servers MAY include Digest-Qop and Digest-Algorithm attributes 1232 in Access-Challenge messages. A man in the middle can modify or 1233 remove those attributes in a bidding down attack. In this case, the 1234 RADIUS client would use a weaker authentication scheme than intended. 1235 RfC 3579 [RFC3579], section 3.2 describes a Message-Authenticator 1236 attribute which MUST be used to improve the integrity protection of 1237 RADIUS messages. The RADIUS server can use this attribute to verify 1238 the identity of the RADIUS client. 1240 The Digest-HA1 attribute contains no random components if the 1241 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1242 attacks easier and can be used for replay attacks. 1244 HTTP-style clients can use TLS with server side certificates together 1245 with HTTP-Digest authentication. Instead of TLS, IPSec can be used, 1246 too. TLS or IPSec secure the connection while Digest Authentication 1247 authenticates the user. The RADIUS connection can be regarded as one 1248 leg on the path between the HTTP-style client and the HTTP-style 1249 server. To prevent the RADIUS link from being the weakest hop on the 1250 path, a RADIUS client receiving an HTTP-style request via TLS or 1251 IPSec MUST use an equally secure connection to the RADIUS server. 1252 There are two ways to achieve this: 1253 o the RADIUS client rejects HTTP-style requests received over TLS or 1254 IPSec 1255 o the operator of the RADIUS client takes actions to ensure that 1256 RADIUS traffic is exclusively sent and received using IPSec. 1257 When using IPSec, it MUST be set up as described [RFC3579] section 1258 4.2. 1260 9. Change Log 1262 9.1 Changes from draft-ietf-radext-digest-auth-00 1264 o SIP-AOR attribute added 1265 o clarified use of Digest-Qop 1266 o attribute overview table added 1268 9.2 Changes from draft-sterman-aaa-sip-04 1270 o clarified usage of Digest-HA1 1271 o clarified usage of Digest-Stale (is sent in an Access-Challenge 1272 now) 1273 o clarified allowed attribute usage for message types 1274 o changed attribute type to 'Text' where the corresponding Diameter 1275 AVPs have a UTF8String 1276 o added Diameter client - RADIUS server handling 1278 9.3 Changes from draft-sterman-aaa-sip-03 1280 o addressed 'auth-int' issue 1281 o New Digest-Nextnonce attribute 1282 o revised abstract, motivational section and examples 1283 o Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce 1284 attribute' 1285 o shortened SIP messages in example, removed real-world addresses 1286 and product names 1288 9.4 Changes from draft-sterman-aaa-sip-02 1290 o Relaxed restrictions for Digest-Domain, Digest-Realm, 1291 Digest-Opaque, Digest-Qop and Digest-Algorithm 1292 o Additional security considerations for Digest-Domain, Digest-Qop 1293 and Digest-Algorithm usage in Access-Accept messages 1295 9.5 Changes from draft-sterman-aaa-sip-01 1297 o Replaced Sub-attributes with flat attributes 1298 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1299 o Added how a server must treat unknown attributes. 1300 o Added a section 'Migration path to Diameter' 1301 o Added an optional attribute for support of the digest scheme 1302 described in informational [RFC3310]. 1303 o Added a mode of operation where the RADIUS server chooses the 1304 nonce. This was required for AKA [RFC3310], but can be useful for 1305 ordinary Digest authentication when the qop directive is not used. 1306 This required the addition of several attributes. 1308 10. References 1310 10.1 Normative References 1312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1313 Requirement Levels", BCP 14, RFC 2119, March 1997. 1315 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1316 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1317 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1319 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1320 Leach, P., Luotonen, A. and L. Stewart, "HTTP 1321 Authentication: Basic and Digest Access Authentication", 1322 RFC 2617, June 1999. 1324 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1325 "Remote Authentication Dial In User Service (RADIUS)", 1326 RFC 2865, June 2000. 1328 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1329 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 1330 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1332 [RFC3310] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer 1333 Protocol (HTTP) Digest Authentication Using Authentication 1334 and Key Agreement (AKA)", RFC 3310, September 2002. 1336 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1337 Dial In User Service) Support For Extensible 1338 Authentication Protocol (EAP)", RFC 3579, September 2003. 1340 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1341 RFC 3966, December 2004. 1343 10.2 Informative References 1345 [I-D.ietf-aaa-diameter-sip-app] 1346 Garcia-Martin, M., "Diameter Session Initiation Protocol 1347 (SIP) Application", 1348 Internet-Draft draft-ietf-aaa-diameter-sip-app-06, 1349 February 2005. 1351 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1352 Recommendations for Security", RFC 1750, December 1994. 1354 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1355 RFC 2246, January 1999. 1357 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1358 RFC 2633, June 1999. 1360 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1361 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1363 URIs 1365 [1] 1367 Authors' Addresses 1369 Baruch Sterman 1370 Kayote Networks 1371 P.O. Box 1373 1372 Efrat 90435 1373 Israel 1375 Email: baruch@kayote.com 1377 Daniel Sadolevsky 1378 SecureOL, Inc. 1379 Jerusalem Technology Park 1380 P.O. Box 16120 1381 Jerusalem 91160 1382 Israel 1384 Email: dscreat@dscreat.com 1386 David Schwartz 1387 Kayote Networks 1388 P.O. Box 1373 1389 Efrat 90435 1390 Israel 1392 Email: david@kayote.com 1394 David Williams 1395 Cisco Systems 1396 7025 Kit Creek Road 1397 P.O. Box 14987 1398 Research Triangle Park NC 27709 1399 USA 1401 Email: dwilli@cisco.com 1402 Wolfgang Beck 1403 Deutsche Telekom AG 1404 Am Kavalleriesand 3 1405 Darmstadt 64295 1406 Germany 1408 Email: beckw@t-systems.com 1410 Appendix A. Acknowledgments 1412 We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or 1413 providing comments and experimental implementation. 1415 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1416 Arrko, Avi Lior and Jun Wang. 1418 Intellectual Property Statement 1420 The IETF takes no position regarding the validity or scope of any 1421 Intellectual Property Rights or other rights that might be claimed to 1422 pertain to the implementation or use of the technology described in 1423 this document or the extent to which any license under such rights 1424 might or might not be available; nor does it represent that it has 1425 made any independent effort to identify any such rights. Information 1426 on the procedures with respect to rights in RFC documents can be 1427 found in BCP 78 and BCP 79. 1429 Copies of IPR disclosures made to the IETF Secretariat and any 1430 assurances of licenses to be made available, or the result of an 1431 attempt made to obtain a general license or permission for the use of 1432 such proprietary rights by implementers or users of this 1433 specification can be obtained from the IETF on-line IPR repository at 1434 http://www.ietf.org/ipr. 1436 The IETF invites any interested party to bring to its attention any 1437 copyrights, patents or patent applications, or other proprietary 1438 rights that may cover technology that may be required to implement 1439 this standard. Please address the information to the IETF at 1440 ietf-ipr@ietf.org. 1442 Disclaimer of Validity 1444 This document and the information contained herein are provided on an 1445 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1446 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1447 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1448 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1449 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1450 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1452 Copyright Statement 1454 Copyright (C) The Internet Society (2005). This document is subject 1455 to the rights, licenses and restrictions contained in BCP 78, and 1456 except as set forth therein, the authors retain all their rights. 1458 Acknowledgment 1460 Funding for the RFC Editor function is currently provided by the 1461 Internet Society.