idnits 2.17.1 draft-sterman-aaa-sip-04.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 1266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1256. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1272), 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 2 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 53 has weird spacing: '...cribing the a...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2004) is 7248 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 1166, but no explicit reference was found in the text == Unused Reference: 'RFC3588' is defined on line 1183, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-aaa-diameter-sip-app-03 ** 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 (~~), 7 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-04.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 Several protocols borrow the authentication mechanisms from the 49 Hypertext Transfer Protocol, HTTP. This document specifies an 50 extension to RADIUS that allows a RADIUS client in an HTTP-style 51 server, upon reception of a request, retrieve and compute Digest 52 authentication information from a RADIUS server. Additionally, a 53 scenario describing the authentication of a user emitting an 54 HTTP-style request is provided. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3.1 Scenario 1, RADIUS client chooses nonces . . . . . . . 6 63 1.3.2 Scenario 2, RADIUS server chooses nonces . . . . . . . 7 64 2. New RADIUS attributes . . . . . . . . . . . . . . . . . . . . 9 65 2.1 Digest-Response attribute . . . . . . . . . . . . . . . . 9 66 2.2 Digest-Realm attribute . . . . . . . . . . . . . . . . . . 9 67 2.3 Digest-Nonce attribute . . . . . . . . . . . . . . . . . . 10 68 2.4 Digest-Response-Auth attribute . . . . . . . . . . . . . . 10 69 2.5 Digest-Nextnonce attribute . . . . . . . . . . . . . . . . 10 70 2.6 Digest-Method attribute . . . . . . . . . . . . . . . . . 11 71 2.7 Digest-URI attribute . . . . . . . . . . . . . . . . . . . 11 72 2.8 Digest-QoP attribute . . . . . . . . . . . . . . . . . . . 11 73 2.9 Digest-Algorithm attribute . . . . . . . . . . . . . . . . 12 74 2.10 Digest-Entity-Body-Hash attribute . . . . . . . . . . . . 12 75 2.11 Digest-CNonce attribute . . . . . . . . . . . . . . . . . 13 76 2.12 Digest-Nonce-Count attribute . . . . . . . . . . . . . . . 13 77 2.13 Digest-Username attribute . . . . . . . . . . . . . . . . 13 78 2.14 Digest-Opaque attribute . . . . . . . . . . . . . . . . . 14 79 2.15 Digest-Auth-Param attribute . . . . . . . . . . . . . . . 14 80 2.16 Digest-AKA-Auts attribute . . . . . . . . . . . . . . . . 14 81 2.17 Digest-Domain attribute . . . . . . . . . . . . . . . . . 15 82 2.18 Digest-Stale attribute . . . . . . . . . . . . . . . . . . 15 83 2.19 Digest-HA1 attribute . . . . . . . . . . . . . . . . . . . 15 84 3. Detailed Description . . . . . . . . . . . . . . . . . . . . . 17 85 3.1 RADIUS Client Behaviour . . . . . . . . . . . . . . . . . 17 86 3.2 RADIUS Server Behaviour . . . . . . . . . . . . . . . . . 19 87 4. Migration Path to Diameter . . . . . . . . . . . . . . . . . . 21 88 4.1 Basic operation . . . . . . . . . . . . . . . . . . . . . 22 89 4.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . 22 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 92 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 8. Changes from draft-sterman-aaa-sip-03 . . . . . . . . . . . . 28 94 9. Changes from draft-sterman-aaa-sip-02 . . . . . . . . . . . . 29 95 10. Changes from draft-sterman-aaa-sip-01 . . . . . . . . . . . 30 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 97 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 31 98 11.2 Informative References . . . . . . . . . . . . . . . . . . . 31 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 100 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 101 Intellectual Property and Copyright Statements . . . . . . . . 35 103 1. Introduction 105 1.1 Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 1.2 Motivation 113 Digest authentication is a simple authentication mechanism for HTTP 114 and SIP. While it was not too successful in HTTP environments, it is 115 the only SIP authentication mechanism that has been widely adopted. 116 Due to the limitations and weaknesses of Digest authentication (see 117 [RFC2617], section 4 />), additional PKI-based authentication and 118 encryption mechanisms have been introduced into SIP: TLS [RFC2246] 119 and S/MIME [RFC2633]. The majority of today's SIP clients only 120 supports HTTP digest. 122 Current RADIUS-based AAA infrastructures have been built and debugged 123 over years. Some deficiencies of RADIUS have been mitigated with 124 proprietary (ie costly) extensions. Operators are therefore 125 reluctant to replace their RADIUS infrastructure in order to enable a 126 single new authentication mechanism. 128 Given the complexity of the alternatives, simple clients will 129 continue to support HTTP digest authentication only. Its 130 interoperability with a back-end authentication protocol such as 131 RADIUS is needed. 133 Operators that are about to replace their RADIUS-based AAA 134 infrastructure are strongly recommended to use Diameter. 136 1.3 Overview 138 Figure 1 depicts the basic scenario that is relevant for this 139 document. 'HTTP-style Client' and 'RADIUS Client' are entities using 140 a protocol with support for HTTP Digest Authentication, like SIP or 141 HTTP. 143 HTTP/SIP RADIUS 144 +------------+ +--------+ +--------+ 145 | HTTP-style | | RADIUS | | RADIUS | 146 | Client |<========>| Client |<------->| Server | 147 | | | | | | 148 +------------+ +--------+ +--------+ 150 Figure 1: Overview of operation 152 The approach taken here is to extend RADIUS to support Digest 153 authentication by mimicking its native support for CHAP 154 authentication. According to [RFC2865], the RADIUS server 155 distinguishes between different authentication schemes by looking at 156 the presence of an attribute specific for that scheme. For the three 157 natively supported authentication schemes, these attributes are: 158 User-Password for PAP (or any other clear-text password scheme), 159 CHAP-Password for CHAP, and State + User- Password for 160 challenge-response scheme. This document adds another attribute to 161 be used in this role: Digest-Response. Also according to [RFC2865], 162 "An Access-Request packet MUST contain either a User-Password or a 163 CHAP-Password or a State. It MUST NOT contain both a User-Password 164 and a CHAP-Password. If future extensions allow other kinds of 165 authentication information to be conveyed, the attribute for that can 166 be used instead of User-Password or CHAP-Password." The 167 Digest-Response introduced here therefore can be used instead of 168 User-Password or CHAP-Password. 170 The HTTP Authentication parameters found in the Proxy-Authorization 171 or Authorization request header are mapped into newly defined RADIUS 172 attributes. These new RADIUS attributes are defined in the document 173 together with some other information required for calculating the 174 correct digest response on the RADIUS server with exception of the 175 password, which the RADIUS server is assumed to be able to retrieve 176 from a data store given the username. 178 The nonces required by the digest algorithm are either generated by 179 the RADIUS client or by the RADIUS server. If at least one 180 HTTP-style client requires AKA authentication [RFC3310], the RADIUS 181 server MUST support nonce generation and its RADIUS clients MUST NOT 182 generate nonces locally. 184 1.3.1 Scenario 1, RADIUS client chooses nonces 186 HTTP/SIP RADIUS 188 +-----+ (1) +-----+ +-----+ 189 | |==========>| | | | 190 | | (2) | | | | 191 | |<==========| | | | 192 | | (3) | | | | 193 | |==========>| | | | 194 | A | | B | (4) | C | 195 | | | |---------->| | 196 | | | | (5) | | 197 | | | |<----------| | 198 | | (6) | | | | 199 | |<==========| | | | 200 +-----+ +-----+ +-----+ 202 ====> HTTP/SIP 203 ----> RADIUS 205 Figure 2: RADIUS client chooses nonces 207 The roles played by the entities in this scenario are as follows: 209 A: HTTP client / SIP UA 211 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 212 acting also as a RADIUS NAS 214 C: RADIUS server 216 The relevant order of messages sent in this scenario is as follows: 218 A sends B an HTTP/SIP request without authorization header (step 1). 219 B challenges A sending an HTTP/SIP "(Proxy) Authorization required" 220 response containing a locally generated nonce (step 2). A sends B an 221 HTTP/SIP request with authorization header (step 3). B sends C a 222 RADIUS Access-Request with attributes described in this document 223 (step 4). C responds to B with a RADIUS Access-Accept/Access-Reject 224 response (step 5). If credentials were accepted B receives an 225 Access-Accept response and the message sent from A is considered 226 authentic. If B receives an Access-Reject response, however, B then 227 responds to A with a "(Proxy) Authorization required" response (step 228 6). 230 1.3.2 Scenario 2, RADIUS server chooses nonces 232 In most cases, the operation outlined in Section 1.3.1 is sufficient. 233 It reduces the load on the RADIUS server to a minimum. However, when 234 using AKA [RFC3310] the nonce is partially derived from a precomputed 235 authentication vector. These authentication vectors are often stored 236 centrally. 238 Figure 3 depicts a scenario, where the RADIUS server chooses nonces. 239 It shows a generic case where entities A and B communicate in the 240 front-end using protocols such as HTTP/SIP, while entities B and C 241 communicate in the back-end using RADIUS. 243 HTTP/SIP RADIUS 245 +-----+ (1) +-----+ +-----+ 246 | |==========>| | (2) | | 247 | | | |---------->| | 248 | | | | (3) | | 249 | | (4) | |<----------| | 250 | |<==========| | | | 251 | | (5) | | | | 252 | |==========>| | | | 253 | A | | B | (6) | C | 254 | | | |---------->| | 255 | | | | (7) | | 256 | | | |<----------| | 257 | | (8) | | | | 258 | |<==========| | | | 259 +-----+ +-----+ +-----+ 261 ====> HTTP/SIP 262 ----> RADIUS 264 Figure 3: RADIUS server chooses nonces 266 The roles played by the entities in this scenario are as follows: 268 A: HTTP client / SIP UA 270 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 271 acting also as a RADIUS NAS 273 C: RADIUS server 275 The relevant order of messages sent in this scenario is as follows: 277 A sends B an HTTP/SIP request without authorization header (step 1). 278 B sends an Access-Request message with the newly defined 279 Digest-Method and Digest-URI attributes but without a Digest-Nonce 280 attribute to the RADIUS server, C (step 2). C chooses a nonce and 281 responds with an Access-Challenge (step 3). This Access-Challenge 282 contains Digest attributes, from which B takes values to construct an 283 HTTP/SIP "(Proxy) Authorization required" response. The remaining 284 steps are identical with scenario 1 (Section 1.3.1): B sends this 285 response to A (step 4). A resends its request with its credentials 286 (step 5). B sends an Access-Request to C (step 6). C checks the 287 credentials and replies with Access-Accept or Access-Reject (step 7). 288 Dependent on the C's result, B processes A's request or rejects it 289 with a "(Proxy) Authorization required" response (step 8). 291 2. New RADIUS attributes 293 DIG-RES, DIG-REALM, DIG-NONCE, DIG-RSPAUTH, DIG-NEXTNONCE, 294 DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG, DIG-BODY, DIG-CNONCE, DIG-NC, 295 DIG-USER, DIG-OPAQUE, DIG-AUTHP, DIG-AUTS, DIG-DOMAIN, DIG-STALE and 296 DIG-HA1 are placeholders for values that are taken from the RADIUS 297 attribute type number space (see Section 5). 299 The term 'HTTP-style' denotes any protocol that uses HTTP-like 300 headers and uses HTTP digest authentication as described in 301 [RFC2617]. Examples are HTTP and SIP. 303 If not stated otherwise, the attributes have the following format: 305 0 1 2 306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type | Length | String... 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 2.1 Digest-Response attribute 313 If this attribute is present, the RADIUS server SHOULD view the 314 Access-Request as a Digest one. When a RADIUS client receives a 315 (Proxy-)Authorization header, it puts the request-digest value into a 316 Digest-Response attribute. 318 Type 319 DIG-RES for Digest-Response. 320 Length 321 34 322 String 323 This attribute is only used in Access-Requests. This string 324 proves the user knows a password. The String field is 32 325 octets long and contains hexadecimal representation of 16 octet 326 digest value as it was calculated by the authenticated client. 327 The String field SHOULD be copied from request-digest of 328 digest-response ([RFC2617]). 330 2.2 Digest-Realm attribute 332 This string attribute describes a protection space of the RADIUS 333 server. See [RFC2617] 1.2 for details. 335 Type 336 DIG-REALM 337 Length 338 >=3 339 String 340 In Access-Requests, the RADIUS client takes the value of the 341 realm directive (realm-value) from the HTTP-style request it 342 wants to authenticate. In Access-Challenge messages, the 343 RADIUS server puts the expected realm value into this 344 attribute. 346 2.3 Digest-Nonce attribute 348 This attribute holds a random nonce to be used in the HTTP Digest 349 calculation. 351 Type 352 DIG-NONCE 353 Length 354 >=3 355 String 356 In Access-Requests, the RADIUS client takes the value of the 357 nonce directive (nonce-value) from the HTTP-style request it 358 wants to authenticate. If the Access-Request had a 359 Digest-Method and a Digest-URI but no Digest-Nonce attribute 360 and the RADIUS server is configured to choose nonces, it MUST 361 put a Digest-Nonce attribute into its Access-Challenge message. 363 2.4 Digest-Response-Auth attribute 365 Type 366 DIG-RSPAUTH for Digest-Response-Auth. 367 Length 368 34 369 String 370 This attribute is only used in Access-Accept messages if the 371 RADIUS server is configured to choose nonces. This string 372 proves the RADIUS server knows the password. The RADIUS server 373 calculates a digest according to section 3.2.3 of [RFC2617] and 374 copies the result into this string. The RADIUS client puts the 375 string into the rspauth directive of the Authentication-Info 376 header. 378 2.5 Digest-Nextnonce attribute 380 This attribute holds a random nonce to be used in the HTTP Digest 381 calculation. 383 Type 384 DIG-NEXTNONCE 385 Length 386 >=3 387 String 388 If the RADIUS server is configured to choose nonces and to use 389 Authentication-Info, it puts a Digest-Nextnonce attribute into 390 its Access-Accept message. It contains the nonce value that 391 SHOULD be used by the client in the next Access-Request 392 message. The RADIUS client MUST put the contents of this 393 attribute into the nextnonce directive of its HTTP-style 394 response. 396 2.6 Digest-Method attribute 398 This attribute holds the method string to be used in the HTTP Digest 399 calculation. 401 Type 402 DIG-METHOD 403 Length 404 >=3 405 String 406 In Access-Requests, the RADIUS client takes the value of the 407 request method from the HTTP-style request it wants to 408 authenticate. This attribute MUST only be used in 409 Access-Request messages. 411 2.7 Digest-URI attribute 413 This attribute holds the URI string to be used in the HTTP Digest 414 calculation. 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.8 Digest-QoP attribute 428 This attribute holds the Quality of Protection parameter that 429 influences the HTTP Digest calculation. 431 Type 432 DIG-QOP 433 Length 434 >=3 435 String 436 In Access-Requests, the RADIUS client takes the value of the 437 qop directive (qop-value) from the HTTP-style request it wants 438 to authenticate. In Access-Challenge messages, the RADIUS 439 server SHOULD put the desired qop-value into this attribute. 441 2.9 Digest-Algorithm attribute 443 This attribute holds the algorithm parameter that influences the HTTP 444 Digest calculation. 446 Type 447 DIG-ALG 448 Length 449 >=3 450 String 451 In Access-Requests, the RADIUS client takes the value of the 452 algorithm directive from the HTTP-style request it wants to 453 authenticate. In Access-Accept messages, the RADIUS server MAY 454 put the desired algorithm into this attribute. 456 2.10 Digest-Entity-Body-Hash attribute 458 When using the qop level 'auth-int', the contents of the message body 459 are required for digest calculation. Instead of sending the complete 460 body of the message, only its hash value is sent. This hash value 461 can be used directly in the digest calculation. 463 Type 464 DIG-BODY 465 Length 466 34 467 String 468 String, hexadecimal representation of a digest calculated over 469 entity-body of HTTP/SIP request ([RFC2616], [RFC3261]). 470 Computed by entity B in figure Figure 2. This attribute is not 471 part of the HTTP Digest response. See [RFC2617] section 472 3.2.2.3. This attribute MUST only be sent in Access-Request 473 packets. 475 2.11 Digest-CNonce attribute 477 This attribute holds the client nonce parameter that is used in the 478 HTTP Digest calculation. 480 Type 481 DIG-CNONCE 482 Length 483 >=3 484 String 485 In Access-Requests, the RADIUS client takes the value of the 486 cnonce directive (cnonce-value) from the HTTP-style request it 487 wants to authenticate. The attribute is never used in 488 Access-Accept, Access-Challenge or Access-Reject messages. 490 2.12 Digest-Nonce-Count attribute 492 This attribute holds the nonce count parameter that is used to detect 493 replay attacks. 495 Type 496 DIG-NC 497 Length 498 9 499 String 500 In Access-Requests, the RADIUS client takes the value of the nc 501 directive (nc-value) from the HTTP-style request it wants to 502 authenticate. The attribute MUST only be used in 503 Access-Request messages. 505 2.13 Digest-Username attribute 507 This attribute holds the user name parameter that is used in the HTTP 508 digest calculation. 510 Type 511 DIG-USER 512 Length 513 >= 3 514 String 515 In Access-Requests, the RADIUS client takes the value of the 516 username directive (username-value) from the HTTP-style request 517 it wants to authenticate. The RADIUS server SHOULD NOT use 518 this value for password finding, but only for digest 519 calculation purpose. In order to find the user record 520 containing the password, the RADIUS server SHOULD use the value 521 of the ([RFC2865] -)User-Name attribute. This attribute MUST 522 only be sent in Access-Request packets. 524 2.14 Digest-Opaque attribute 526 This attribute holds the opaque parameter that is passed to the 527 HTTP-style client. Th HTTP-style client passes this value back to 528 the server (ie the RADIUS client) without modification. 530 Type 531 DIG-OPAQUE 532 Length 533 >=3 534 String 535 This attribute is only used when the RADIUS server chooses 536 nonces. In Access-Requests, the RADIUS client takes the value 537 of the opaque directive from the HTTP-style request it wants to 538 authenticate and puts it into this attribute. In 539 Access-Challenge messages, the RADIUS server MAY include this 540 attribute. 542 2.15 Digest-Auth-Param attribute 544 This attribute is a placeholder for future extensions. 546 Type 547 DIG-AUTHP 548 Length 549 >=3 550 String 551 This attribute is for future extensions. Any extension 552 parameter in the digest-response can be put into a 553 Digest-Auth-Param attribute. The string consists of the whole 554 parameter, including its name and the equal ('=') sign. RADIUS 555 servers that do not implement a parameter contained in a 556 Digest-Auth-Param attribute MUST respond with an Access-Reject 557 message. RADIUS clients that do not implement a parameter 558 contained in a Digest-Auth-Param attribute MUST reject the 559 original HTTP-style request. This attribute MAY be used in 560 Access-Request and Access-Accept messages. 562 2.16 Digest-AKA-Auts attribute 564 This attribute holds the auts parameter that is used in the AKA 565 Digest ([RFC3310]) calculation. 567 Type 568 DIG-AUTS 570 Length 571 >=3 572 String 573 In Access-Requests, the RADIUS client takes the value of the 574 auts directive from the HTTP-style request it wants to 575 authenticate. It is only used if the algorithm of the 576 digest-response denotes a version of AKA digest [RFC3310]. 577 RADIUS servers that do not implement AKA digest MUST respond 578 with an Access-Reject message. 580 2.17 Digest-Domain attribute 582 When a RADIUS client has asked for a nonce, the RADIUS server MAY add 583 one or more Digest-Domain attributes to its Access-Challenge message. 584 The RADIUS client puts them into the quoted, space-separated list of 585 URIs of the 'domain' directive of a WWW-Authenticate header. The 586 URIs in the list define the protection space (see [RFC2617], section 587 3.2.1). 589 Type 590 DIG-DOMAIN 591 Length 592 3 593 String 594 The string consists of a single URI, that defines a protection 595 space. RADIUS servers MAY send attributes of this type in 596 Access-Challenge messages. RADIUS clients MUST NOT put 597 attributes of this type in Access-Request messages. 599 2.18 Digest-Stale attribute 601 If this attribute is present, the RADIUS server did not accept the 602 nonce value. 604 Type 605 DIG-STALE 606 Length 607 3 608 String 609 The string consists of a single character. If the nonce 610 presented by the RADIUS client was stale, the character is '1' 611 and is '0' otherwise. The attribute MUST be used in 612 Access-Accept messages if the RADIUS server chooses nonces. 614 2.19 Digest-HA1 attribute 616 If this attribute is present, the RADIUS server did not accept the 617 nonce value. 619 Type 620 DIG-HA1 621 Length 622 34 623 String 624 This string contains the hexadecimal representation of H(A1) as 625 described in [RFC2617], section 3.2.1 and 3.2.2.2. This 626 attribute is only used in Access-Accept messages. It is used 627 by the RADIUS client to calculate the 'rspauth' directive in an 628 Authentication-Info header when the quality of protection 629 ('qop') is 'auth-int'. Digest-HA1 SHOULD only be sent if the 630 'algorithm' directive's value is 'MD5-sess' or 631 'AKAv1-MD5-sess'. This attribute MUST NOT be sent if the qop 632 parameter was not specified or has value of 'auth'. If the 633 'algorithm' directive's value is 'MD5' or 'AKAv1-MD5', the 634 Digest-HA1 attribute MUST NOT be sent by the RADIUS server or 635 processed by the RADIUS client, unless the authenticity and 636 integrity of the Access-Accept message was secured by 637 cryptographic or equivalently secure means. 639 3. Detailed Description 641 3.1 RADIUS Client Behaviour 643 A RADIUS client without an encrypted or otherwise secured connection 644 (see Section 6) to its RADIUS server only accepts unsecured 645 connections from its HTTP-style clients (or else the clients would 646 have a false sense of security). 648 The RADIUS client examines the (Proxy-)Authorization header of an 649 incoming HTTP-style request message. If this header is present and 650 contains HTTP digest information, the RADIUS client checks the 651 'nonce' parameter. If the 'nonce' value has not been sent by the 652 RADIUS client, it responds with a 401 (Unauthorized) or 407 (Proxy 653 Authentication Required) to the HTTP-style client. In this error 654 response, the RADIUS client sends a new nonce. 656 If the RADIUS client recognizes the nonce, it takes the header 657 parameters and puts them into a RADIUS Access-Request message. It 658 puts the 'response' parameter into a Digest-Response attribute and 659 the realm / nonce / qop / algorithm / cnonce / nc / username into the 660 respective Digest-Realm / Digest-Nonce / Digest-QoP / 661 Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / 662 Digest-Username attributes. The request URI and the request method 663 are put into the Digest-URI and Digest-Method attributes. Now, the 664 RADIUS client sends the Access-Request message to the RADIUS server. 666 The RADIUS server processes the message and responds with an 667 Access-Accept or an Access-Reject message. 669 The RADIUS clients constructs an Authentication-Info header: 670 o If the Access-Accept message contains a Digest-Response-Auth 671 attribute, the RADIUS client checks the Digest-QoP attribute: 672 * If the Digest-Qop attribute's value is 'auth' or not specified, 673 the RADIUS client puts the Digest-Response-Auth attribute's 674 content into the 'rspauth' directive of the HTTP-style 675 response. 676 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 677 client ignores the Access-Accept message and behaves like it 678 had received an Access-Reject message. 679 o If the Access-Accept message contains a Digest-HA1 attribute, the 680 RADIUS client checks the Digest-QoP and Digest-Algorithm 681 attributes: 682 * If the Digest-Qop attribute is missing or its value is 'auth', 683 the RADIUS client ignores the Digest-HA1 attribute. It does 684 not include an Authentication-Info header into its HTTP-style 685 response. 687 * If the Digest-Qop attribute's value is 'auth-int' and the 688 Digest-Algorithm attribute's value is 'MD5-sess' or 689 'AKAv1-MD5-sess', the RADIUS client calculates the contents of 690 the 'rspauth' directive. It creates the HTTP-style response 691 message and calculates the hash of this message's body. It 692 uses the result and the Digest-URI attribute's value of the 693 corresponding Access-Request message to perform the H(A2) 694 calculation. It takes the Digest-Nonce, Digest-Nonce-Count, 695 Digest-CNonce and Digest-QoP values of the corresponding 696 Access-Request and the Digest-HA1 attribute's value to finish 697 the computation of the 'rspauth' value. 698 * If the Digest-Qop attribute's value is 'auth-int' and the 699 Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5', the 700 RADIUS client MUST NOT use the Digest-HA1 attribute, unless it 701 knows for sure that the Access-Accept message was encrypted or 702 otherwise protected against eavesdropping. 704 The RADIUS server MAY have added a Digest-Nextnonce attribute. If 705 the RADIUS client discovers this, it puts the contents of this 706 attribute into a 'nextnonce' directive. Now it can send an 707 HTTP-style response. 709 If the RADIUS client did not receive a (Proxy-)Authorization header 710 from its HTTP-style client, it obtains a new nonce and sends an error 711 response (401 or 407) containing a (Proxy-)Authenticate header. 713 If the RADIUS client receives an Access-Reject or no response from 714 the RADIUS server, it sends an error response to the HTTP-style 715 request it has received. 717 The RADIUS client has three ways to obtain nonces: it generates them 718 locally, it has received one in a Digest-Nonce attribute of a 719 previously received Access-Accept message, or it asks the RADIUS 720 server for one. To do the latter, it sends an Access-Request 721 containing a Digest-Method and a Digest-URI attribute but without a 722 Digest-Nonce attribute. The RADIUS server chooses a nonce and 723 responds with an Access-Challenge containing a Digest-Nonce 724 attribute. 726 If the RADIUS server responds with an Access-Reject, the RADIUS 727 client MAY generate a nonce locally. If the RADIUS client does not 728 generate nonces locally, the authentication has failed. The RADIUS 729 server can send Digest-QoP, Digest-Algorithm, Digest-Realm, 730 Digest-Domain and Digest-Opaque attributes in the Access-Challenge 731 carrying the nonce. If these attributes are present, the client MUST 732 use them. 734 If the Digest-Stale attribute is present in the Access-Accept message 735 following an Access-Challenge, the RADIUS client sends an error (401 736 or 407) response containing WWW-/Proxy-Authenticate header with the 737 directives 'stale' and 'nextnonce'. 739 3.2 RADIUS Server Behaviour 741 If the RADIUS server receives an Access-Request message with a 742 Digest-Method and a Digest-URI attribute but without a Digest-Nonce 743 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 744 attribute and sends it in an Access-Challenge message to the RADIUS 745 client. The RADIUS server MUST add Digest-Algorithm, Digest-Realm, 746 SHOULD add Digest-QoP and MAY add Digest-Domain, Digest-Opaque 747 attributes to the Access-Challenge message. If the server cannot 748 choose a nonce, it replies with an Access-Reject message. 750 If the RADIUS server receives an Access-Request message containing a 751 Digest-Response attribute, it looks for the following attributes: 752 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-QoP, 753 Digest-Algorithm, Digest-Username. Depending on the content of 754 Digest-Algorithm and Digest-QoP, it looks for 755 Digest-Entity-Body-Hash, Digest-CNonce and Digest-AKA-Auts, too. See 756 [RFC2617] and [RFC3310] for details. If it has issued a 757 Digest-Opaque attribute along with the nonce, the Access-Request MUST 758 have a matching Digest-Opaque attribute. 760 If it does not find these attributes, it responds with an 761 Access-Reject message. If the attributes are present, the RADIUS 762 server calculates the digest response as described in [RFC2617]. To 763 look up the password, the RADIUS server uses the RADIUS User-Name 764 attribute. All other values are taken from the Digest attributes 765 described in this document. If the calculated digest response equals 766 the string received in the Digest-Response attribute, the 767 authentication was successful. If not, the RADIUS server responds 768 with an Access-Reject. 770 If the authentication was successful, the RADIUS server adds an 771 attribute to the Access-Accept message which can be used by the 772 RADIUS client to construct an Authentication-Info header: 773 o If the Digest-QoP attribute's value is 'auth' or unspecified, the 774 RADIUS server puts a Digest-Response-Auth attribute into the 775 Access-Accept message 776 o If the Digest-QoP attribute's value is 'auth-int' and the 777 Digest-Algorithm attribute's value is 'MD5-sess' or 778 'AKAv1-MD5-sess', the RADIUS server puts a Digest-HA1 attribute 779 into the Access-Accept message. 780 o If the Digest-QoP attribute's value is 'auth-int' and the 781 Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5', the 782 RADIUS server MUST NOT send a Digest-HA1 attribute unless the 783 connection between RADIUS server and client is encrypted or 784 otherwise protected against eavesdropping. 786 RADIUS servers issuing nonces MAY construct a Digest-Nextnonce 787 attribute. This is useful to limit the lifetime of a nonce and to 788 save a round-trip in future requests (see nextnonce discussion in 789 [RFC2617], section 3.2.3). The Digest-Response attribute and the 790 optional Digest-Nextnonce attribute are send to the RADIUS client in 791 an Access-Accept message. 793 4. Migration Path to Diameter 795 The following table gives an overview of the mapping between RADIUS 796 attributes defined here and the corresponding Diameter AVPs described 797 in [I-D.ietf-aaa-diameter-sip-app]: 799 +-------------------------+-----------------------------------------+ 800 | RADIUS | Diameter | 801 +-------------------------+-----------------------------------------+ 802 | Digest-Realm | Digest-Realm | 803 | | | 804 | Digest-Nonce | Digest-Nonce | 805 | | | 806 | Digest-URI | Digest-URI | 807 | | | 808 | Digest-Domain | Digest-Domain | 809 | | | 810 | Digest-QoP | Digest-Qop | 811 | | | 812 | Digest-Algorithm | Digest-Algorithm | 813 | | | 814 | Digest-CNonce | Digest-Cnonce | 815 | | | 816 | Digest-Nonce-Count | Digest-Nonce-Count | 817 | | | 818 | Digest-Method | SIP-Method AVP | 819 | | | 820 | Digest-Username | Digest-Username AVP | 821 | | | 822 | Digest-Entity-Body-Hash | SIP-Entity-Body-Hash AVP | 823 | | | 824 | Digest-Response | SIP-Authorization Digest-Response | 825 | | | 826 | Digest-Response-Auth | SIP-Authentication-Info Digest-Response | 827 | | | 828 | Digest-Opaque | Digest-Opaque AVP | 829 | | | 830 | Digest-Auth-Param | Digest-Auth-Param | 831 | | | 832 | Digest-AKA-Auts | Digest-AKA-Auts | 833 | | | 834 | Digest-Stale | Digest-Stale AVP | 835 +-------------------------+-----------------------------------------+ 837 Table 1 839 4.1 Basic operation 841 If an Access-Request message contains a Digest-Method and a 842 Digest-URI attribute but no Digest-Nonce attribute, the gateway maps 843 the RADIUS attributes to Diameter according to Table 2. The gateway 844 construct a MAR message and sends it to the Diameter server. 846 +---------------+------------+ 847 | RADIUS | Diameter | 848 +---------------+------------+ 849 | Digest-URI | SIP-AOR | 850 | | | 851 | Digest-Method | SIP-Method | 852 +---------------+------------+ 854 Table 2 856 The Diameter Server responds with a MAA message. This message 857 contains a Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH 858 and challenge parameters. The gateway translates the AVPs and puts 859 the resulting RADIUS attributes into an Access-Challenge message. It 860 sends the Access-Challenge message to the RADIUS client. 862 The gateway maps an Access-Request message containing a 863 Digest-Response attribute to a MAR message with a Diameter 864 SIP-Authorization AVP. All RADIUS attributes of the Access-Request 865 message are mapped to the corresponding Diameter AVPs. The gateway 866 sends the MAR message to the Diameter server. 868 If the authentication was successful, the Diameter server replies 869 with a MAA containing a SIP-Authentication-Info and a Digest-Response 870 AVP. The gateway converts these to the corresponding RADIUS 871 attributes and constructs a RADIUS message. If the Result-Code AVP 872 is Diameter_SUCCESS or a Digest-Stale AVP is present, an 873 Access-Accept is sent. In all other cases, an Access-Reject is sent. 875 4.2 Limitations 877 This document covers not all functionality found in 878 [I-D.ietf-aaa-diameter-sip-app]. 879 o There is no equivalent to Diameter's UAR/UAA, SAR/SAA, LIR/LIA, 880 RTR/RTA and PPR/PPA messages 881 o The operational mode where the Diameter server sends the expected 882 digest response to the client is not possible. 884 The operational mode where the RADIUS client chooses nonces is not 885 possible with [I-D.ietf-aaa-diameter-sip-app]. 887 5. IANA Considerations 889 This document serves as IANA registration request for a number of 890 values from the RADIUS attribute type number space: 892 +---------------+------------------------+ 893 | placeholder | value assigned by IANA | 894 +---------------+------------------------+ 895 | DIG-RES | TBD | 896 | | | 897 | DIG-REALM | TBD | 898 | | | 899 | DIG-NONCE | TBD | 900 | | | 901 | DIG-NEXTNONCE | TBD | 902 | | | 903 | DIG-RSPAUTH | TBD | 904 | | | 905 | DIG-METHOD | TBD | 906 | | | 907 | DIG-URI | TBD | 908 | | | 909 | DIG-QOP | TBD | 910 | | | 911 | DIG-ALG | TBD | 912 | | | 913 | DIG-BODY | TBD | 914 | | | 915 | DIG-CNONCE | TBD | 916 | | | 917 | DIG-NC | TBD | 918 | | | 919 | DIG-USER | TBD | 920 | | | 921 | DIG-OPAQUE | TBD | 922 | | | 923 | DIG-AUTHP | TBD | 924 | | | 925 | DIG-AUTS | TBD | 926 | | | 927 | DIG-DOMAIN | TBD | 928 | | | 929 | DIG-STALE | TBD | 930 | | | 931 | DIG-HA1 | TBD | 932 +---------------+------------------------+ 934 Table 3 936 6. Security Considerations 938 The RADIUS extensions described in this document make RADIUS a 939 transport protocol for the data that is required to perform a digest 940 calculation. It adds the vulnerabilities of HTTP Digest (see 941 [RFC2617], section 4) to those of RADIUS (see [RFC2865], section 8 or 942 )). 944 If an attacker gets access to a RADIUS client or RADIUS proxy, it can 945 perform man-in-the-middle attacks even if the connections between A, 946 B and B, C (Figure 2) have been secured with TLS or IPSec. 948 SIP or HTTP requests occur much more frequently than dial-in 949 requests. RADIUS servers implementing this specification must meet 950 that additional performance requirements. An attacker could try to 951 overload the RADIUS infrastructure by excessively sending SIP or HTTP 952 requests. This kind of attack was more difficult when RADIUS was 953 just used for dial-in authentication: the attacker could be 954 identified by the DSL / Cable interface or with some help of the PSTN 955 provider. 957 To make simple denial of service attacks more difficult, RADIUS 958 clients MUST check if nonces received from a client have been issued 959 by them. This SHOULD be done statelessly. For example, a nonce 960 could consist of a cryptographically random part and some kind of 961 signature of the RADIUS client, as described in [RFC2617], section 962 3.2.1. 964 RADIUS servers MAY include Digest-QoP and Digest-Algorithm attributes 965 in Access-Accept messages. A man in the middle can modify or remove 966 those attributes in a bidding down attack. In this case, the RADIUS 967 client would use a weaker authentication scheme than intended. 968 Informational RfC 3579 [RFC3579], section 3.2 describes a 969 Message-Authenticator attribute which MAY be used to protect the 970 integrity of RADIUS messages. 972 The Digest-HA1 attribute contains no random components if the 973 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 974 attacks easier and can be used for replay attacks. 976 HTTP-style clients can use TLS with server side certificates together 977 with HTTP-Digest authentication. Instead of TLS, IPSec can be used, 978 too. TLS or IPSec secure the connection while Digest Authentication 979 authenticates the user. If a RADIUS client accepts such connections, 980 it MUST have an equally secure connection to the RADIUS server. 982 7. Example 984 This is an example sniffed from the traffic between a softphone (A), 985 a Proxy Server (B) and examplecom RADIUS server (C). The 986 communication between the Proxy Server and a SIP PSTN gateway is 987 omitted for brevity. The SIP messages are not shown completely. 989 A->B 991 INVITE sip:97226491335@10.0.69.38 SIP/2.0 993 B->A 995 SIP/2.0 100 Trying 997 B->A 999 SIP/2.0 407 Proxy Authentication Required 1000 Proxy-Authenticate: Digest realm="examplecom" 1001 ,nonce="3bada1a0", algorithm="md5" 1002 Content-Length: 0 1004 A->B 1006 ACK sip:97226491335@10.0.69.38 SIP/2.0 1008 A->B 1010 INVITE sip:97226491335@10.0.69.38 SIP/2.0 1011 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1012 ,opaque="",realm="examplecom" 1013 ,response="2ae133421cda65d67dc50d13ba0eb9bc" 1014 ,uri="sip:97226491335@10.0.69.38",username="12345678" 1016 B->C 1018 Code = 1 (Access-Request) 1019 Attributes: 1020 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1021 NAS-Port-Type = 5 (Virtual) 1022 User-Name = "12345678" 1023 Digest-Response (DIG-RES) = "2ae133421cda65d67dc50d13ba0eb9bc" 1024 Digest-Realm (DIG-REALM) = "examplecom" 1025 Digest-Nonce (DIG-NONCE) = "3bada1a0" 1026 Digest-Method (DIG-METHOD) = "INVITE" 1027 Digest-URI (DIG-URI) = "sip:97226491335@10.0.69.38" 1028 Digest-Algorithm (DIG-ALG) = "md5" 1029 Digest-Username (DIG-USER) = "12345678" 1031 C->B 1033 Code = 2 (Access-Accept) 1034 Attributes: 1035 Digest-Response-Auth (DIG-RSPAUTH) = 1036 "6303c41b0e2c3e524e413cafe8cce954" 1038 B->A 1040 SIP/2.0 180 Ringing 1042 B->A 1044 SIP/2.0 200 OK 1046 A->B 1048 ACK sip:97226491335@10.0.69.38:5060 SIP/2.0 1050 A second example shows the traffic between a web browser (A), web 1051 server (B) and a RADIUS server (C). 1053 A->B 1055 GET /index.html HTTP/1.1 1057 B->A 1059 HTTP/1.1 407 Authentication Required 1060 WWW-Authenticate: Digest realm="examplecom", domain="/index.html", 1061 ,nonce="a3086ac8", algorithm="md5" 1063 Content-Length: 0 1065 A->B 1067 GET /index.html HTTP/1.1 1068 Authorization: Digest algorithm="md5",nonce="a3086ac8" 1069 ,opaque="",realm="examplecom" 1070 ,response="369b593b9a79e001256a2b40afe49f4c" 1071 ,uri="/index.html",username="12345678" 1073 B->C 1075 Code = 1 (Access-Request) 1076 Attributes: 1077 NAS-IP-Address = a 0 45 26 (10.0.69.38) 1078 NAS-Port-Type = 5 (Virtual) 1079 User-Name = "12345678" 1080 Digest-Response (DIG-RES) = "369b593b9a79e001256a2b40afe49f4c" 1081 Digest-Realm (DIG-REALM) = "examplecom" 1082 Digest-Nonce (DIG-NONCE) = "a3086ac8" 1083 Digest-Method (DIG-METHOD) = "GET" 1084 Digest-URI (DIG-URI) = "/index.html"" 1085 Digest-Algorithm (DIG-ALG) = "md5" 1086 Digest-Username (DIG-USER) = "12345678" 1088 C->B 1090 Code = 2 (Access-Accept) 1091 Attributes: 1092 Digest-Response-Auth (DIG-RSPAUTH) = 1093 "e644aa513effbfe1caff67103ff6433c" 1095 B->A 1097 HTTP/1.1 200 OK 1098 ... 1100 1101 ... 1103 8. Changes from draft-sterman-aaa-sip-03 1105 o addressed 'auth-int' issue 1106 o New Digest-Nextnonce attribute 1107 o revised abstract, motivational section and examples 1108 o Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce 1109 attribute' 1110 o shortened SIP messages in example, removed real-world addresses 1111 and product names 1113 9. Changes from draft-sterman-aaa-sip-02 1115 o Relaxed restrictions for DIG-DOMAIN, DIG-REALM, DIG-OPAQUE, 1116 DIG-QOP and DIG-ALG 1117 o Additional security considerations for DIG-DOMAIN, DIG-QOP and 1118 DIG-ALG usage in Access-Accept messages 1120 10. Changes from draft-sterman-aaa-sip-01 1122 o Replaced Sub-attributes with flat attributes 1123 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1124 o Added how a server must treat unknown attributes. 1125 o Added a section 'Migration path to Diameter' 1126 o Added an optional attribute for support of the digest scheme 1127 described in informational [RFC3310]. 1128 o Added a mode of operation where the RADIUS server chooses the 1129 nonce. This was required for AKA [RFC3310], but can be useful for 1130 ordinary Digest authentication when the qop directive is not used. 1131 This required the addition of several attributes. 1133 11. References 1135 11.1 Normative References 1137 [I-D.ietf-aaa-diameter-sip-app] 1138 Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 1139 Canales-Valenzuela, C. and K. Tammi, "Diameter Session 1140 Initiation Protocol (SIP) Application", 1141 draft-ietf-aaa-diameter-sip-app-03 (work in progress), 1142 July 2004. 1144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1145 Requirement Levels", BCP 14, RFC 2119, March 1997. 1147 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1148 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1149 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1151 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1152 Leach, P., Luotonen, A. and L. Stewart, "HTTP 1153 Authentication: Basic and Digest Access Authentication", 1154 RFC 2617, June 1999. 1156 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1157 "Remote Authentication Dial In User Service (RADIUS)", RFC 1158 2865, June 2000. 1160 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1161 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 1162 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1164 11.2 Informative References 1166 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1167 Recommendations for Security", RFC 1750, December 1994. 1169 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1170 RFC 2246, January 1999. 1172 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1173 RFC 2633, June 1999. 1175 [RFC3310] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer 1176 Protocol (HTTP) Digest Authentication Using Authentication 1177 and Key Agreement (AKA)", RFC 3310, September 2002. 1179 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1180 Dial In User Service) Support For Extensible 1181 Authentication Protocol (EAP)", RFC 3579, September 2003. 1183 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1184 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1186 Authors' Addresses 1188 Baruch Sterman 1189 Kayote Networks 1190 P.O. Box 1373 1191 Efrat 90435 1192 Israel 1194 EMail: baruch@kayote.com 1196 Daniel Sadolevsky 1197 SecureOL, Inc. 1198 Jerusalem Technology Park 1199 P.O. Box 16120 1200 Jerusalem 91160 1201 Israel 1203 EMail: dscreat@dscreat.com 1205 David Schwartz 1206 Kayote Networks 1207 P.O. Box 1373 1208 Efrat 90435 1209 Israel 1211 EMail: david@kayote.com 1213 David Williams 1214 Cisco Systems 1215 7025 Kit Creek Road 1216 P.O. Box 14987 1217 Research Triangle Park NC 27709 1218 USA 1220 EMail: dwilli@cisco.com 1221 Wolfgang Beck 1222 Deutsche Telekom AG 1223 Am Kavalleriesand 3 1224 Darmstadt 64295 1225 Germany 1227 EMail: beckw@t-systems.com 1229 Appendix A. Acknowledgements 1231 We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or 1232 providing comments and experimental implementation. 1234 Intellectual Property Statement 1236 The IETF takes no position regarding the validity or scope of any 1237 Intellectual Property Rights or other rights that might be claimed to 1238 pertain to the implementation or use of the technology described in 1239 this document or the extent to which any license under such rights 1240 might or might not be available; nor does it represent that it has 1241 made any independent effort to identify any such rights. Information 1242 on the procedures with respect to rights in RFC documents can be 1243 found in BCP 78 and BCP 79. 1245 Copies of IPR disclosures made to the IETF Secretariat and any 1246 assurances of licenses to be made available, or the result of an 1247 attempt made to obtain a general license or permission for the use of 1248 such proprietary rights by implementers or users of this 1249 specification can be obtained from the IETF on-line IPR repository at 1250 http://www.ietf.org/ipr. 1252 The IETF invites any interested party to bring to its attention any 1253 copyrights, patents or patent applications, or other proprietary 1254 rights that may cover technology that may be required to implement 1255 this standard. Please address the information to the IETF at 1256 ietf-ipr@ietf.org. 1258 Disclaimer of Validity 1260 This document and the information contained herein are provided on an 1261 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1262 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1263 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1264 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1265 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1266 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1268 Copyright Statement 1270 Copyright (C) The Internet Society (2004). This document is subject 1271 to the rights, licenses and restrictions contained in BCP 78, and 1272 except as set forth therein, the authors retain all their rights. 1274 Acknowledgment 1276 Funding for the RFC Editor function is currently provided by the 1277 Internet Society.