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