idnits 2.17.1 draft-sterman-aaa-sip-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1202. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1218), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 15 instances 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 48 has weird spacing: '... Basic and D...' == Line 52 has weird spacing: '.... This docum...' == Line 189 has weird spacing: '...esponse conta...' == Line 190 has weird spacing: '...ization heade...' == Line 238 has weird spacing: '...sent in this ...' == (3 more instances...) -- 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 (June 11, 2004) is 7256 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: 'RFC1750' is defined on line 1115, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-aaa-diameter-sip-app-02 ** 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) -- 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 (~~), 11 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: December 10, 2004 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 June 11, 2004 14 RADIUS Extension for Digest Authentication 15 draft-sterman-aaa-sip-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 and any of which I become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 10, 2004. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). All Rights Reserved. 46 Abstract 48 Basic and Digest authentication schemes are widely used in 49 protocols such as SIP and HTTP . RADIUS is a protocol for back end 50 authentication. RADIUS supports Basic authentication natively, as 51 well as several other authentication schemes, such as CHAP, but does 52 not support Digest authentication scheme. This document describes 53 an extension to RADIUS for Digest authentication and provides a 54 scenario of Digest user authentication. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.3 Scenario 1, RADIUS client chooses nonces . . . . . . . . . 4 62 1.4 Scenario 2, RADIUS server chooses nonces . . . . . . . . . 5 63 1.5 Approach . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2. New RADIUS attributes . . . . . . . . . . . . . . . . . . . 8 65 2.1 Digest-Response attribute . . . . . . . . . . . . . . . . 8 66 2.2 Digest-Realm attribute . . . . . . . . . . . . . . . . . . 9 67 2.3 Digest-Nonce attribute . . . . . . . . . . . . . . . . . . 9 68 2.4 Digest-Method attribute . . . . . . . . . . . . . . . . . 10 69 2.5 Digest-URI attribute . . . . . . . . . . . . . . . . . . . 11 70 2.6 Digest-QoP attribute . . . . . . . . . . . . . . . . . . . 11 71 2.7 Digest-Algorithm attribute . . . . . . . . . . . . . . . . 12 72 2.8 Digest-Body attribute . . . . . . . . . . . . . . . . . . 12 73 2.9 Digest-CNonce attribute . . . . . . . . . . . . . . . . . 13 74 2.10 Digest-Nonce-Count attribute . . . . . . . . . . . . . . 13 75 2.11 Digest-Username attribute . . . . . . . . . . . . . . . 14 76 2.12 Digest-Opaque attribute . . . . . . . . . . . . . . . . 15 77 2.13 Digest-Auth-Param attribute . . . . . . . . . . . . . . 15 78 2.14 Digest-AKA-Auts attribute . . . . . . . . . . . . . . . 16 79 2.15 Digest-Domain attribute . . . . . . . . . . . . . . . . 16 80 2.16 Digest-Stale attribute . . . . . . . . . . . . . . . . . 17 81 3. Detailed Description . . . . . . . . . . . . . . . . . . . . 19 82 3.1 RADIUS Client Behaviour . . . . . . . . . . . . . . . . . 19 83 3.2 RADIUS Server Behaviour . . . . . . . . . . . . . . . . . 20 84 4. Migration Path to DIAMETER . . . . . . . . . . . . . . . . . 22 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 86 6. Security Considerations . . . . . . . . . . . . . . . . . . 25 87 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 8. Changes from -01 . . . . . . . . . . . . . . . . . . . . . . 30 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 31 91 9.2 Informative References . . . . . . . . . . . . . . . . . . . 31 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 93 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 94 Intellectual Property and Copyright Statements . . . . . . . 34 96 1. Introduction 98 1.1 Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 1.2 Motivation 106 Digest authentication is a simple authentication mechanism for HTTP 107 and SIP. While it was not too successful in HTTP environments, it is 108 the only SIP authentication mechanism that has been widely adopted. 109 Due to the weaknesses of Digest authentication (see Section 6), 110 PKI-based authentication and encryption mechanisms have been 111 introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However, 112 most SIP user agents that support TLS don't send client certificates. 113 SIP with S/MIME is lacking support, too: even two years after the 114 inclusion of S/MIME into SIP, almost no implementations exist. 116 SIP service providers whishing to authenticate their clients have the 117 following options: they can 118 o build a PKI and wait for interopable S/MIME capable SIP 119 implementations, 120 o build a PKI and wait for SIP implementations supporting TLS with 121 client-side certificates, 122 o replace their existing RADIUS infrastructure with DIAMETER 123 [RFC3588], when DIAMETER supports HTTP Digest authentication, 124 o use TLS for server authentication and plaintext passwords (Basic) 125 for client authentication, which can be done with standard RADIUS, 126 o upgrade their existing RADIUS servers with the functionality 127 described in this document 129 PKI solutions only cover authentication, not authorization (EAP could 130 change this, but its use with SIP is not standardized). TLS / Basic 131 authentication works only with the limited number of SIP devices that 132 implement TLS. Basic authentication has been deprecated for SIP in 133 [RFC3261]. 135 Current RADIUS-based AAA infrastructures have been built and debugged 136 over years. Deficiencies of RADIUS have been mitigated with 137 proprietary (ie costly) extensions. Operators are therefore 138 reluctant to replace their RADIUS infrastructure in order to enable a 139 single new authentication mechanism. 141 Given the complexity of S/MIME, simple clients will continue to 142 support HTTP digest authentication only. Its interopability with a 143 back-end authentication protocol such as RADIUS is needed. 145 Operators that are about to replace their RADIUS-based AAA 146 infrastructure are strongly recommended to use DIAMETER. 148 1.3 Scenario 1, RADIUS client chooses nonces 150 Figure 1 depicts the basic scenario that is relevant for this 151 document. It shows a generic case where entities A and B communicate 152 in the front-end using protocols such as HTTP/SIP, while entities B 153 and C communicate in the back-end using RADIUS. 155 HTTP/SIP RADIUS 157 +-----+ (1) +-----+ +-----+ 158 | |==========>| | | | 159 | | (2) | | | | 160 | |<==========| | | | 161 | | (3) | | | | 162 | |==========>| | | | 163 | A | | B | (4) | C | 164 | | | |---------->| | 165 | | | | (5) | | 166 | | | |<----------| | 167 | | (6) | | | | 168 | |<==========| | | | 169 +-----+ +-----+ +-----+ 171 ====> HTTP/SIP 172 ----> RADIUS 174 Figure 1: Overview of basic operation 176 The roles played by the entities in this scenario are as follows: 178 A: HTTP client / SIP UA 180 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 181 acting also as a RADIUS NAS 183 C: RADIUS server 185 The relevant order of messages sent in this scenario is as follows: 187 A sends B an HTTP/SIP request without authorization header (step 1). 188 B challenges A sending an HTTP/SIP "(Proxy) Authorization required" 189 response containing a locally generated nonce (step 2). A sends B 190 an HTTP/SIP request with authorization header (step 3). B sends C 191 a RADIUS Access-Request with attributes described in this document 192 (step 4). C responds to B with a RADIUS Access-Accept/Access-Reject 193 response (step 5). If credentials were accepted B receives an 194 Access-Accept response and the message sent from A is considered 195 authentic. If B receives an Access-Reject response, however, B then 196 responds to A with a "(Proxy) Authorization required" response (step 197 6). 199 1.4 Scenario 2, RADIUS server chooses nonces 201 Figure 2 depicts an alternative scenario, where the RADIUS server 202 generates nonces. It shows a generic case where entities A and B 203 communicate in the front-end using protocols such as HTTP/SIP, while 204 entities B and C communicate in the back-end using RADIUS. 206 HTTP/SIP RADIUS 208 +-----+ (1) +-----+ +-----+ 209 | |==========>| | (2) | | 210 | | | |---------->| | 211 | | | | (3) | | 212 | | (4) | |<----------| | 213 | |<==========| | | | 214 | | (5) | | | | 215 | |==========>| | | | 216 | A | | B | (6) | C | 217 | | | |---------->| | 218 | | | | (7) | | 219 | | | |<----------| | 220 | | (8) | | | | 221 | |<==========| | | | 222 +-----+ +-----+ +-----+ 224 ====> HTTP/SIP 225 ----> RADIUS 227 Figure 2: RADIUS server chooses nonces 229 The roles played by the entities in this scenario are as follows: 231 A: HTTP client / SIP UA 233 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 234 acting also as a RADIUS NAS 236 C: RADIUS server 238 The relevant order of messages sent in this scenario is as follows: 240 A sends B an HTTP/SIP request without authorization header (step 1). 241 B sends an Access-Request message with the newly defined 242 Digest-Method and Digest-URI attributes but without a Digest-Nonce 243 attribute to the RADIUS server, C (step 2). C chooses a nonce and 244 responds with an Access-Accept (step 3). This Access-Accept contains 245 Digest attributes, from which B takes values to construct a HTTP/SIP 246 "(Proxy) Authorization required" response. The remaining steps are 247 identical with scenario 1 (Section 1.3): B sends this response to A 248 (step 4). A resends its request with its credentials (step 5). B 249 sends an Access-Request to C (step 6). C checks the credentials and 250 replies with Access-Accept or Access-Reject (step 7). Dependent on 251 the C's result, B processes A's request or rejects it with a "(Proxy) 252 Authorization required" response (step 8). 254 1.5 Approach 256 The approach taken here is to extend RADIUS to support Digest 257 authentication by mimicking its native support for CHAP 258 authentication. According to [RFC2865], the RADIUS server 259 distinguishes between different authentication schemes by looking at 260 the presence of an attribute specific for that scheme. For the three 261 natively supported authentication schemes, these attributes are: 262 User-Password for PAP (or any other clear-text password scheme), 263 CHAP-Password for CHAP, and State + User- Password for 264 challenge-response scheme. This document adds another attribute to 265 be used in this role: Digest-Response. Also according to [RFC2865], 266 "An Access-Request packet MUST contain either a User-Password or a 267 CHAP-Password or a State. It MUST NOT contain both a User-Password 268 and a CHAP-Password. If future extensions allow other kinds of 269 authentication information to be conveyed, the attribute for that can 270 be used instead of User-Password or CHAP-Password." The 271 Digest-Response introduced here therefore can be used instead of 272 User-Password or CHAP-Password. 274 The HTTP Authentication parameters found in the Proxy-Authorization 275 or Authorization request header are mapped into newly defined RADIUS 276 attributes. These new RADIUS attributes are defined in the document 277 together with some other information required for calculating the 278 correct digest response on the RADIUS server with exception of the 279 password, which the RADIUS server is assumed to be able to retrieve 280 from a data store given the username. 282 In most cases, the operation outlined in Section 1.3 is sufficient. 283 It reduces the load on the RADIUS server to a minimum. However, in 284 some cases the RADIUS server is better off with pre-computed hashes. 285 Section 1.4 describes an mechanism that enables this style of 286 authentication. 288 2. New RADIUS attributes 290 DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG, 291 DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP, 292 DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that 293 will be assigned by IANA, if this specification becomes a working 294 group document. 296 The term 'HTTP-style' denotes any protocol that uses HTTP-like 297 headers and uses HTTP digest authentication as described in 298 [RFC2617]. Examples are HTTP and SIP. 300 2.1 Digest-Response attribute 302 If this attribute is present, the RADIUS server SHOULD view the 303 Access-Request as a Digest one. The following paragraphs apply for 304 RADIUS servers implementing this specification. Access-Request 305 packets MUST contain an Digest-Response attribute. In Access-Request 306 packets, this attribute contains the digest taken from request-digest 307 field in Digest (Proxy)Authorization header, as received from the 308 HTTP or SIP client. 310 Access-Accept packets MUST contain a Digest-Response attribute. In 311 Access-Accept packets, this attribute contains a digest that can be 312 used for generating Authentication-Info headers. The calculation of 313 this digest is described in [RFC2617], section 3.2.3. A summary of 314 the Digest-Response attribute format is shown below. The fields are 315 transmitted from left to right. 317 0 1 2 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type | Length | String... 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Type 324 DIG-RES for Digest-Response. Early implementations have used 325 the experimental type 206. 326 Length 327 34 329 String 330 In Access-Requests, this string proves the user knows a 331 password. The String field is 32 octets long and contains 332 hexadecimal representation of 16 octet digest value as it was 333 calculated by the authenticated client. The String field 334 SHOULD be copied from request-digest of digest-response 335 ([RFC2617]). In Access-Accepts, this string proves the RADIUS 336 server knows the password. The RADIUS server calculates a 337 digest according to section 3.2.3 of [RFC2617] and copies the 338 result into this string. 340 2.2 Digest-Realm attribute 342 This string attribute describes a protection space of the RADIUS 343 server. See [RFC2617] 1.2 for details. 345 0 1 2 346 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type | Length | String... 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Type 352 DIG-REALM 353 Length 354 >=3 355 String 356 In Access-Requests, the RADIUS client takes the value of the 357 realm directive (realm-value) from the HTTP-style request it 358 wants to authenticate. In Access-Accept messages, the RADIUS 359 server puts the expected realm value into this attribute, if 360 the RADIUS client asked for a nonce. 362 2.3 Digest-Nonce attribute 364 This attribute holds a random nonce to be used in the HTTP Digest 365 calculation. 367 0 1 2 368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type | Length | String... 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Type 374 DIG-NONCE 375 Length 376 >=3 377 String 378 In Access-Requests, the RADIUS client takes the value of the 379 nonce directive (nonce-value) from the HTTP-style request it 380 wants to authenticate. If the Access-Request had a 381 Digest-Nonce attribute, the RADIUS server MAY put the nonce to 382 be used in a future request into this attribute in the 383 Access-Accept message. If the Access-Request had a 384 Digest-Method and a Digest-URI but no Digest-Nonce attribute 385 and the RADIUS server is configured to choose nonces, it MUST 386 put a Digest-Nonce attribute into its Access-Accept message. 388 2.4 Digest-Method attribute 390 This attribute holds the method string to be used in the HTTP Digest 391 calculation. 393 0 1 2 394 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type | Length | String... 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Type 400 DIG-METHOD 401 Length 402 >=3 403 String 404 In Access-Requests, the RADIUS client takes the value of the 405 request method from the HTTP-style request it wants to 406 authenticate. This attribute MUST only be used in 407 Access-Request messages. 409 2.5 Digest-URI attribute 411 This attribute holds the URI string to be used in the HTTP Digest 412 calculation. 414 0 1 2 415 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Length | String... 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Type 421 DIG-URI 422 Length 423 >=3 424 String 425 In Access-Requests, the RADIUS client takes the value of the 426 request URI (digest-uri-value) from the HTTP-style request it 427 wants to authenticate. The attribute MUST only be used in 428 Access-Request messages. 430 2.6 Digest-QoP attribute 432 This attribute holds the Quality of Protection parameter that 433 influences the HTTP Digest calculation. 435 0 1 2 436 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type | Length | String... 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Type 442 DIG-QOP 443 Length 444 >=3 445 String 446 In Access-Requests, the RADIUS client takes the value of the 447 qop directive (qop-value) from the HTTP-style request it wants 448 to authenticate. The attribute MUST only be used in 449 Access-Request messages. 451 2.7 Digest-Algorithm attribute 453 This attribute holds the algorithm parameter that influences the HTTP 454 Digest calculation. 456 0 1 2 457 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Type | Length | String... 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Type 463 DIG-ALG 464 Length 465 >=3 466 String 467 In Access-Requests, the RADIUS client takes the value of the 468 algorithm directive from the HTTP-style request it wants to 469 authenticate. The attribute MUST only be used in 470 Access-Request messages. 472 2.8 Digest-Body attribute 474 When using the qop level 'auth-int', the contents of the message body 475 are required for digest calculation. Instead of sending the complete 476 body of the message, only its hash value is sent. This hash value 477 can be used directly in the digest calculation. 479 0 1 2 480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Type | Length | String... 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Type 485 DIG-BODY 486 Length 487 34 488 String 489 String, hexadecimal representation of a digest calculated over 490 entity-body of HTTP/SIP request ([RFC2616], [RFC3261]). 491 Computed by entity B in figure Figure 1. This attribute is 492 not part of the HTTP Digest response. See [RFC2617] section 493 3.2.2.3. This attribute MUST only be sent in Access-Request 494 packets. 496 2.9 Digest-CNonce attribute 498 This attribute holds the client nonce parameter that is used in the 499 HTTP Digest calculation. 501 0 1 2 502 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Type | Length | String... 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Type 508 DIG-CNONCE 509 Length 510 >=3 511 String 512 In Access-Requests, the RADIUS client takes the value of the 513 cnonce directive (cnonce-value) from the HTTP-style request it 514 wants to authenticate. The attribute is never used in 515 Access-Response messages. 517 2.10 Digest-Nonce-Count attribute 519 This attribute holds the nonce count parameter that is used to detect 520 replay attacks. 522 0 1 2 523 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type | Length | String... 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Type 529 DIG-NC 530 Length 531 9 532 String 533 In Access-Requests, the RADIUS client takes the value of the nc 534 directive (nc-value) from the HTTP-style request it wants to 535 authenticate. The attribute MUST only be used in 536 Access-Request messages. 538 2.11 Digest-Username attribute 540 This attribute holds the user name parameter that is used in the HTTP 541 digest calculation. 543 0 1 2 544 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Length | String... 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Type 550 DIG-USER 551 Length 552 >= 3 553 String 554 In Access-Requests, the RADIUS client takes the value of the 555 username directive (username-value) from the HTTP-style request 556 it wants to authenticate. The RADIUS server SHOULD NOT use 557 this value for password finding, but only for digest 558 calculation purpose. In order to find the user record 559 containing the password, the RADIUS server SHOULD use the value 560 of the ([RFC2865] -)User-Name attribute. This attribute MUST 561 only be sent in Access-Request packets. 563 2.12 Digest-Opaque attribute 565 This attribute holds the opaque parameter that is passed to the 566 HTTP-style client. Th HTTP-style client passes this value back to 567 the server (ie the RADIUS client) without modification. 569 0 1 2 570 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type | Length | String... 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Type 576 DIG-OPAQUE 577 Length 578 >=3 579 String 580 This attribute is only used when the RADIUS server chooses 581 nonces. In Access-Requests, the RADIUS client takes the value 582 of the opaque directive from the HTTP-style request it wants to 583 authenticate and puts it into this attribute. In 584 Access-Accepts that convey a nonce, the RADIUS server MAY 585 include this attribute. 587 2.13 Digest-Auth-Param attribute 589 This attribute is a placeholder for future extensions. 591 0 1 2 592 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type | Length | String... 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Type 598 DIG-AUTHP 599 Length 600 >=3 601 String 602 This attribute is for future extensions. Any extension 603 parameter in the digest-response can be put into a 604 Digest-Auth-Param attribute. The string consists of the whole 605 parameter, including its name and the equal ('=') sign. RADIUS 606 servers that do not implement a parameter contained in an 607 Digest-Auth-Param attribute MUST respond with an Access-Reject 608 message. RADIUS clients that do not implement a parameter 609 contained in an Digest-Auth-Param attribute MUST reject the 610 original HTTP-style request. 612 2.14 Digest-AKA-Auts attribute 614 This attribute holds the auts parameter that is used in the AKA 615 Digest ([RFC3310]) calculation. 617 0 1 2 618 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Type | Length | String... 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Type 624 DIG-AUTS 625 Length 626 >=3 627 String 628 In Access-Requests, the RADIUS client takes the value of the 629 auts directive from the HTTP-style request it wants to 630 authenticate. It is only used if the algorithm of the 631 digest-response denotes a version of AKA digest [RFC3310]. 632 RADIUS servers that do not implement AKA digest MUST respond 633 with an Access-Reject message. The attribute MUST only be used 634 in Access-Request messages. 636 2.15 Digest-Domain attribute 638 When a RADIUS client has asked for a nonce, the RADIUS server MAY add 639 one or more Digest-Domain attributes to its Access-Accept message. 640 The RADIUS client puts them into the quoted, space-separated list of 641 URIs of the 'domain' directive of a WWW-Authenticate header. The 642 URIs in the list define the protection space (see [RFC2617], section 643 3.2.1). 645 0 1 2 646 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Type | Length | String... 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Type 652 DIG-DOMAIN 653 Length 654 3 655 String 656 The string consists of a single URI, that defines a protection 657 space. Attributes of this type MUST only be used in 658 Access-Accept messages. 660 2.16 Digest-Stale attribute 662 If this attribute is present, the RADIUS server did not accept the 663 nonce value. 665 0 1 2 666 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Type | Length | String... 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Type 672 DIG-STALE 673 Length 674 3 675 String 676 The string consists of a single character '1'. The contents of 677 this string MAY be ignored by an implementation. The presence 678 of the attribute itself tells the RADIUS client that the nonce 679 was considered stale. The attribute MUST only be used in 680 Access-Accept messages. 682 3. Detailed Description 684 3.1 RADIUS Client Behaviour 686 A RADIUS client without an encrypted or otherwise secured connection 687 to its RADIUS server only accepts unsecured connections from its 688 HTTP-style clients (or else the clients would have a false sense of 689 security). 691 The RADIUS client examines the (Proxy-)Authorization header of an 692 incoming HTTP-style request message. If this header is present and 693 contains HTTP digest information, the RADIUS client checks the 694 'nonce' parameter. If the 'nonce' value has not been sent by the 695 RADIUS client, it responds with a 401 (Unauthorized) or 407 (Proxy 696 Authentication Required) to the HTTP-style client. In this error 697 response, the RADIUS client sends a new nonce. 699 If the RADIUS client recognizes the nonce, it takes the header 700 parameters and puts them into a RADIUS Access-Request message. It 701 puts the 'response' parameter into a Digest-Response attribute and 702 the realm / nonce / qop / algorithm / cnonce / nc / username into the 703 respective Digest-Realm / Digest-Nonce / Digest-QoP / 704 Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / 705 Digest-Username attributes. The request URI and the request method 706 are put into the Digest-URI and Digest-Method attributes. Now, the 707 RADIUS client sends the Access-Request message to the RADIUS server. 709 The RADIUS client has three ways to obtain nonces: it generates them 710 locally, it has received one in a Digest-Nonce attribute of a 711 previously received Access-Accept message, or it asks the RADIUS 712 server for one. To do the latter, it sends an Access-Request 713 containing a Digest-Method and Digest-URI attribute but without a 714 Digest-Nonce attribute. The RADIUS server chooses a nonce and 715 responds with an Access-Accept containing a Digest-Nonce attribute. 716 If the RADIUS server responds with an Access-Reject, the RADIUS 717 client MAY generate a nonce locally. If the RADIUS client does not 718 generate nonces locally, the authentication has failed. 720 The RADIUS server processes the message and responds with an 721 Access-Accept or an Access-Reject. If the RADIUS client receives an 722 Access-Accept, it examines the Digest attributes contained in the 723 message. 725 If the Digest-Stale attribute is present, the RADIUS client sends an 726 error (401 or 407) response containing WWW-/Proxy-Authenticate header 727 with a stale directive. 729 If the Digest-Stale attribute is not present, the RADIUS client 730 constructs an Authentication-Info header and puts the contents of 731 Digest-Response into the 'rspauth' directive. The RADIUS server MAY 732 have added a Digest-Nonce attribute. If the RADIUS client discovers 733 this, it puts the contents of this attribute into a 'nextnonce' 734 directive. Now it can send a HTTP-style response. 736 If the RADIUS client did not receive a (Proxy-)Authorization header 737 from its HTTP-style client, it obtains a new nonce and sends an error 738 response (401 or 407) containing a (Proxy-)Authenticate header. 740 If the RADIUS client receives an Access-Reject or no response from 741 the RADIUS server, it sends an error response to the HTTP-style 742 request it has received. 744 3.2 RADIUS Server Behaviour 746 If the RADIUS server receives an Access-Request message with a 747 Digest-Method and a Digest-URI attribute but without a Digest-Nonce 748 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 749 attribute and sends it in an Access-Accept message to the RADIUS 750 client. If the server cannot choose a nonce, it replies with an 751 Access-Reject message. 753 If the RADIUS server receives an Access-Request message containing a 754 Digest-Response attribute, it looks for the following attributes: 755 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-QoP, 756 Digest-Algorithm, Digest-Username. Depending on the content of 757 Digest-Algorithm and Digest-QoP, it looks for Digest-Body, 758 Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and [RFC3310] 759 for details. If it has issued a Digest-Opaque attribute along with 760 the present nonce, the Access-Request MUST have a matching 761 Digest-Opaque attribute. 763 If it does not find these attributes, it responds with an 764 Access-Reject message. If the attributes are present, the RADIUS 765 server calculates the digest response as described in [RFC2617]. To 766 look up the password, the RADIUS server uses the RADIUS User-Name 767 attribute. All other values are taken from the Digest attributes 768 described in this document. If the calculated digest response equals 769 the string received in the Digest-Response attribute, the 770 authentication was successful. If not, the RADIUS server responds 771 with an Access-Reject. 773 If the authentication was successful, the RADIUS server calculates a 774 Digest-Response attribute that can be used by the RADIUS client to 775 construct an Authentication-Info header. The calculation of this 776 response is described in [RFC2617], section 3.2.3. RADIUS servers 777 issuing nonces MAY construct a Digest-Nonce attribute. This is 778 useful to limit the lifetime of a nonce and to save a round-trip in 779 future requests (see nextnonce discussion in [RFC2617], section 780 3.2.3). The Digest-Response attribute and the optional Digest-Nonce 781 attribute are send to the RADIUS client in an Access-Accept message. 783 4. Migration Path to DIAMETER 785 The following table gives an overview of the mapping between RADIUS 786 attributes defined here and the corresponding DIAMETER AVPs described 787 in [I-D.ietf-aaa-diameter-sip-app]: 789 +---------------------------------+---------------------------------+ 790 | RADIUS | DIAMETER | 791 +---------------------------------+---------------------------------+ 792 | Digest-Realm | Digest-Realm | 793 | | | 794 | Digest-Nonce | Digest-Nonce | 795 | | | 796 | Digest-URI | Digest-URI | 797 | | | 798 | Digest-Domain | Digest-Domain | 799 | | | 800 | Digest-QoP | Digest-Qop | 801 | | | 802 | Digest-Algorithm | Digest-Algorithm | 803 | | | 804 | Digest-CNonce | Digest-Cnonce | 805 | | | 806 | Digest-Nonce-Count | Digest-Nonce-Count | 807 | | | 808 | Digest-Method | SIP-Method AVP | 809 | | | 810 | Digest-Username | Digest-Username AVP | 811 | | | 812 | Digest-Body | SIP-Entity-Body-Hash AVP | 813 | | | 814 | Access-Request Digest-Response | SIP-Authorization | 815 | | Digest-Response | 816 | | | 817 | Access-Accept Digest-Response | SIP-Authentication-Info | 818 | | Digest-Response | 819 | | | 820 | Digest-Opaque | Digest-Opaque AVP | 821 | | | 822 | Digest-Auth-Param | Digest-Auth-Param | 823 | | | 824 | Digest-AKA-Auts | Digest-AKA-Auts | 825 | | | 826 | Digest-Response | Digest-Response AVP | 827 | | | 828 | Digest-Stale | Digest-Stale AVP | 829 +---------------------------------+---------------------------------+ 830 Table 1 832 Access-Requests containing a Digest-Response attribute and other 833 Digest attributes are mapped to a DIAMETER SIP-Authorization AVP. 834 The RADIUS/DIAMETER gateway constructs a MAR and sends it to the 835 DIAMETER server. 837 If the authentication was successful, the DIAMETER server replies 838 with a MAA containing a SIP-Authentication-Info and a Digest-Response 839 AVP. The gateway converts these to the corresponding RADIUS 840 attributes and constructs a RADIUS message. If the Result-Code AVP 841 is DIAMETER_SUCCESS or a Digest-Stale AVP is present, an 842 Access-Accept is sent. In all other cases, an Access-Reject is sent. 844 +---------------+------------+ 845 | RADIUS | DIAMETER | 846 +---------------+------------+ 847 | Digest-URI | SIP-AOR | 848 | | | 849 | Digest-Method | SIP-Method | 850 +---------------+------------+ 852 Table 2 854 If an Access-Request contains a Digest-Method and a Digest-URI 855 attribute but no Digest-Nonce attribute, the gateway maps the RADIUS 856 attributes to DIAMETER according to Table 2. The gateway construct a 857 MAR message and sends it to the DIAMETER server. 859 If the MAA contains a SIP-Authenticate-AVP, the gateway maps the 860 contained values to RADIUS attributes, according to Table 1. If the 861 Result-Code AVP is DIAMETER_MULTI_ROUND_AUTH, the gateway constructs 862 an Access-Accept and sends it. 864 5. IANA Considerations 866 DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG, 867 DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP, 868 DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that 869 require IANA registration. They must be assigned from the RADIUS 870 attribute type number space, if this specification becomes a working 871 group document. 873 6. Security Considerations 875 The RADIUS extensions described in this document make RADIUS a 876 transport protocol for the data that is required to perform a digest 877 calculation. It adds the vulnerabilities of HTTP Digest (see 878 [RFC2617], section 4) to those of RADIUS (see [RFC2865], section 8 or 879 )). 881 If an attacker gets access to a RADIUS client, it can perform 882 man-in-the-middle attacks even if the connections between A, B and B, 883 C (Figure 1) have been secured with TLS or IPSec. 885 SIP or HTTP requests occur much more frequently than dial-in 886 requests. RADIUS servers implementing this specification must meet 887 that additional performance requirements. An attacker could try to 888 overload the RADIUS infrastructure by excessively sending SIP or HTTP 889 requests. This kind of attack was more difficult when RADIUS was 890 just used for dial-in authentication: the attacker could be 891 identified by the DSL / Cable interface or with some help of the PSTN 892 provider. 894 To make simple denial of service attacks more difficult, RADIUS 895 clients MUST check if nonces received from a client have been issued 896 by them. This SHOULD be done statelessly. For example, a nonce 897 could consist of a cryptographically random part and some kind of 898 signature of the RADIUS client, as described in [RFC2617], section 899 3.2.1. 901 HTTP-style clients can use TLS with server side certificates together 902 with HTTP-Digest authentication. IPSec can be used in a similar way. 903 TLS or IPSec secure the connection while Digest Authentication 904 authenticates the user. If a RADIUS client accepts such connections, 905 it MUST have a secure connection to the RADIUS server. 907 7. Example 909 This is an example sniffed from the traffic between HearMe softphone 910 (A), Cisco Systems Proxy Server (B) and deltathree RADIUS server (C) 911 (The communication between Cisco Systems Proxy Server and a SIP PSTN 912 gateway is omitted for brevity): 914 A->B 916 INVITE sip:97226491335@213.137.69.38 SIP/2.0 917 Via: SIP/2.0/UDP 213.137.67.67:5061 918 From: ;tag=216ae97f 919 To: sip:97226491335@213.137.69.38 920 Contact: sip:12345678@213.137.67.67:5061 921 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 922 CSeq: 2544265 INVITE 923 Content-Length: 150 924 Content-Type: application/sdp 925 User-Agent: HearMe SoftPHONE 927 v=0 928 o=HearMe 2544265 2544265 IN IP4 213.137.67.67 929 s=HearMe 930 c=IN IP4 213.137.67.67 931 t=0 0 932 m=audio 8000 RTP/AVP 0 4 933 a=ptime:20 934 a=x-ssrc:009aa330 936 B->A 938 SIP/2.0 100 Trying 939 Via: SIP/2.0/UDP 213.137.67.67:5061 940 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 941 From: ;tag=216ae97f 942 To: sip:97226491335@213.137.69.38 943 CSeq: 2544265 INVITE 944 Content-Length: 0 946 B->A 948 SIP/2.0 407 Proxy Authentication Required 949 Via: SIP/2.0/UDP 213.137.67.67:5061 950 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 951 From: ;tag=216ae97f 952 To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc 953 CSeq: 2544265 INVITE 954 Proxy-Authenticate: DIGEST realm="deltathree" 955 ,nonce="3bada1a0", algorithm="md5" 956 Content-Length: 0 958 A->B 960 ACK sip:97226491335@213.137.69.38 SIP/2.0 961 Via: SIP/2.0/UDP 213.137.67.67:5061 962 From: ;tag=216ae97f 963 To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc 964 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 965 CSeq: 2544265 ACK 966 Content-Length: 0 968 A->B 970 INVITE sip:97226491335@213.137.69.38 SIP/2.0 971 Via: SIP/2.0/UDP 213.137.67.67:5061 972 From: ;tag=29e97f 973 To: sip:97226491335@213.137.69.38 974 Contact: sip:12345678@213.137.67.67:5061 975 Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 976 CSeq: 2544266 INVITE 977 Content-Length: 150 978 Content-Type: application/sdp 979 User-Agent: HearMe SoftPHONE 980 Proxy-Authorization: DIGEST algorithm="md5",nonce="3bada1a0" 981 ,opaque="",realm="deltathree" 982 ,response="2ae133421cda65d67dc50d13ba0eb9bc" 983 ,uri="sip:97226491335@213.137.69.38",username="12345678" 985 v=0 986 o=HearMe 2544265 2544265 IN IP4 213.137.67.67 987 s=HearMe 988 c=IN IP4 213.137.67.67 989 t=0 0 990 m=audio 8000 RTP/AVP 0 4 991 a=ptime:20 992 a=x-ssrc:009aa330 994 B->C 995 Code = 1 (Access-Request) 996 Identifier = 1 997 Length = 162 998 Authenticator = 56 7b e6 9a 8e 43 cf b6 fb a6 c0 f0 9a 92 6f 0e 999 Attributes: 1000 NAS-IP-Address = d5 89 45 26 (213.137.69.38) 1001 NAS-Port-Type = 5 (Virtual) 1002 User-Name = "12345678" 1003 Digest-Response (DIG-RES) = "2ae133421cda65d67dc50d13ba0eb9bc" 1004 Digest-Realm (DIG-REALM) = "deltathree" 1005 Digest-Nonce (DIG-NONCE) = "3bada1a0" 1006 Digest-Method (DIG-METHOD) = "INVITE" 1007 Digest-URI (DIG-URI) = "sip:97226491335@213.137.69.38" 1008 Digest-Algorithm (DIG-ALG) = "md5" 1009 Digest-Username (DIG-USER) = "12345678" 1011 C->B 1013 Code = 2 (Access-Accept) 1014 Identifier = 1 1015 Length = 20 1016 Authenticator = 6d 76 53 ce aa 07 9a f7 ac b4 b0 e2 96 2f c4 0d 1017 Attributes: 1018 Digest-Response (206) = "6303c41b0e2c3e524e413cafe8cce954" 1020 B->A 1022 SIP/2.0 180 Ringing 1023 Via: SIP/2.0/UDP 213.137.67.67:5061 1024 From: ;tag=29e97f 1025 To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E 1026 Date: Tue, 25 Jan 2000 03:41:00 gmt 1027 Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 1028 Server: Cisco-SIPGateway/IOS-12.x 1029 Record-Route: 1031 CSeq: 2544266 INVITE 1032 Content-Length: 0 1034 B->A 1036 SIP/2.0 200 OK 1037 Via: SIP/2.0/UDP 213.137.67.67:5061 1038 From: ;tag=29e97f 1039 To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E 1040 Date: Tue, 25 Jan 2000 03:41:00 gmt 1041 Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 1042 Authentication-Info: nextnonce="ef0189c5", 1043 rspauth="6303c41b0e2c3e524e413cafe8cce954" 1044 Server: Cisco-SIPGateway/IOS-12.x 1045 Record-Route: 1047 CSeq: 2544266 INVITE 1048 Contact: 1049 Content-Type: application/sdp 1050 Content-Length: 158 1052 v=0 1053 o=CiscoSystemsSIP-GW-UserAgent 1901 5895 IN IP4 213.137.69.36 1054 s=SIP Call 1055 c=IN IP4 213.137.69.36 1056 t=0 0 1057 m=audio 17724 RTP/AVP 0 1058 a=rtpmap:0 PCMU/8000 1060 A->B 1062 ACK sip:97226491335@213.137.69.38:5060 SIP/2.0 1063 Via: SIP/2.0/UDP 213.137.67.67:5061 1064 From: ;tag=29e97f 1065 To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E 1066 Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 1067 CSeq: 2544266 ACK 1068 Content-Length: 0 1069 Route: 1071 8. Changes from -01 1073 o Replaced Sub-attributes with flat attributes 1074 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1075 o Added how a server must treat unknown attributes. 1076 o Added a section 'Migration path to DIAMETER' 1077 o Added an optional attribute for support of the digest scheme 1078 described in informational [RFC3310]. 1079 o Added a mode of operation where the RADIUS server chooses the 1080 nonce. This was required for AKA [RFC3310], but can be useful for 1081 ordinary Digest authentication when the qop directive is not used. 1082 This required the addition of several attributes. 1084 9. References 1086 9.1 Normative References 1088 [I-D.ietf-aaa-diameter-sip-app] 1089 Garcia-Martin, M., "Diameter Session Initiation Protocol 1090 (SIP) Application", draft-ietf-aaa-diameter-sip-app-02 1091 (work in progress), April 2004. 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, March 1997. 1096 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1097 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1098 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1100 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1101 Leach, P., Luotonen, A. and L. Stewart, "HTTP 1102 Authentication: Basic and Digest Access Authentication", 1103 RFC 2617, June 1999. 1105 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1106 "Remote Authentication Dial In User Service (RADIUS)", RFC 1107 2865, June 2000. 1109 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1110 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 1111 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1113 9.2 Informative References 1115 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1116 Recommendations for Security", RFC 1750, December 1994. 1118 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1119 RFC 2246, January 1999. 1121 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1122 RFC 2633, June 1999. 1124 [RFC3310] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer 1125 Protocol (HTTP) Digest Authentication Using Authentication 1126 and Key Agreement (AKA)", RFC 3310, September 2002. 1128 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1129 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1131 Authors' Addresses 1133 Baruch Sterman 1134 Kayote Networks 1135 P.O. Box 1373 1136 Efrat 90435 1137 Israel 1139 EMail: baruch@kayote.com 1141 Daniel Sadolevsky 1142 SecureOL, Inc. 1143 Jerusalem Technology Park 1144 P.O. Box 16120 1145 Jerusalem 91160 1146 Israel 1148 EMail: dscreat@dscreat.com 1150 David Schwartz 1151 Kayote Networks 1152 P.O. Box 1373 1153 Efrat 90435 1154 Israel 1156 EMail: david@kayote.com 1158 David Williams 1159 Cisco Systems 1160 7025 Kit Creek Road 1161 P.O. Box 14987 1162 Research Triangle Park NC 27709 1163 USA 1165 EMail: dwilli@cisco.com 1167 Wolfgang Beck 1168 Deutsche Telekom AG 1169 Am Kavalleriesand 3 1170 Darmstadt 64295 1171 Germany 1173 EMail: beckw@t-systems.com 1175 Appendix A. Acknowledgements 1177 We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or 1178 providing comments and experimental implementation. 1180 Intellectual Property Statement 1182 The IETF takes no position regarding the validity or scope of any 1183 Intellectual Property Rights or other rights that might be claimed to 1184 pertain to the implementation or use of the technology described in 1185 this document or the extent to which any license under such rights 1186 might or might not be available; nor does it represent that it has 1187 made any independent effort to identify any such rights. Information 1188 on the procedures with respect to rights in RFC documents can be 1189 found in BCP 78 and BCP 79. 1191 Copies of IPR disclosures made to the IETF Secretariat and any 1192 assurances of licenses to be made available, or the result of an 1193 attempt made to obtain a general license or permission for the use of 1194 such proprietary rights by implementers or users of this 1195 specification can be obtained from the IETF on-line IPR repository at 1196 http://www.ietf.org/ipr. 1198 The IETF invites any interested party to bring to its attention any 1199 copyrights, patents or patent applications, or other proprietary 1200 rights that may cover technology that may be required to implement 1201 this standard. Please address the information to the IETF at 1202 ietf-ipr@ietf.org. 1204 Disclaimer of Validity 1206 This document and the information contained herein are provided on an 1207 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1208 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1209 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1210 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1211 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1212 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1214 Copyright Statement 1216 Copyright (C) The Internet Society (2004). This document is subject 1217 to the rights, licenses and restrictions contained in BCP 78, and 1218 except as set forth therein, the authors retain all their rights. 1220 Acknowledgment 1222 Funding for the RFC Editor function is currently provided by the 1223 Internet Society.