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