idnits 2.17.1 draft-ietf-radext-digest-auth-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1672. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6645 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) == Missing Reference: 'IANA TBD' is mentioned on line 1109, but not defined == Missing Reference: 'Note 1' is mentioned on line 1163, but not defined == Missing Reference: 'Note 2' is mentioned on line 1165, but not defined == Missing Reference: 'Note 3' is mentioned on line 1167, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Downref: Normative reference to an Informational RFC: RFC 3579 == Outdated reference: A later version (-12) exists of draft-ietf-aaa-diameter-sip-app-11 -- Obsolete informational reference (is this intentional?): RFC 2069 (Obsoleted by RFC 2617) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- 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: 7 errors (**), 0 flaws (~~), 9 warnings (==), 12 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: August 5, 2006 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 February 2006 14 RADIUS Extension for Digest Authentication 15 draft-ietf-radext-digest-auth-07.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 27 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 August 5, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document defines an extension to the Remote Authentication Dial 49 In User Service (RADIUS) protocol to enable support of Digest 50 Authentication, for use with HTTP-style protocols like the Session 51 Initiation Protocol (SIP) and HTTP. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.3.1. Scenario 1, RADIUS client chooses nonces . . . . . . . 7 60 1.3.2. Scenario 2, RADIUS server chooses nonces . . . . . . . 8 61 2. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 9 62 3. Detailed Description . . . . . . . . . . . . . . . . . . . . . 9 63 3.1. RADIUS Client Configuration . . . . . . . . . . . . . . . 10 64 3.2. RADIUS Client Behavior . . . . . . . . . . . . . . . . . . 10 65 3.2.1. Credential Selection . . . . . . . . . . . . . . . . . 10 66 3.2.2. Constructing an Access-Request . . . . . . . . . . . . 10 67 3.2.3. Constructing an Authentication-Info header . . . . . . 11 68 3.2.4. Failed Authentication . . . . . . . . . . . . . . . . 12 69 3.2.5. Obtaining Nonces . . . . . . . . . . . . . . . . . . . 12 70 3.3. RADIUS Server Behavior . . . . . . . . . . . . . . . . . . 13 71 3.3.1. General Attribute Checks . . . . . . . . . . . . . . . 14 72 3.3.2. Checking the Nonce Validity . . . . . . . . . . . . . 14 73 3.3.3. Authentication . . . . . . . . . . . . . . . . . . . . 15 74 3.3.4. Constructing the Reply . . . . . . . . . . . . . . . . 16 75 4. New RADIUS attributes . . . . . . . . . . . . . . . . . . . . 17 76 4.1. Digest-Response attribute . . . . . . . . . . . . . . . . 17 77 4.2. Digest-Realm attribute . . . . . . . . . . . . . . . . . . 17 78 4.3. Digest-Nonce attribute . . . . . . . . . . . . . . . . . . 18 79 4.4. Digest-Response-Auth attribute . . . . . . . . . . . . . . 18 80 4.5. Digest-Nextnonce attribute . . . . . . . . . . . . . . . . 19 81 4.6. Digest-Method attribute . . . . . . . . . . . . . . . . . 19 82 4.7. Digest-URI attribute . . . . . . . . . . . . . . . . . . . 19 83 4.8. Digest-Qop attribute . . . . . . . . . . . . . . . . . . . 20 84 4.9. Digest-Algorithm attribute . . . . . . . . . . . . . . . . 20 85 4.10. Digest-Entity-Body-Hash attribute . . . . . . . . . . . . 21 86 4.11. Digest-CNonce attribute . . . . . . . . . . . . . . . . . 21 87 4.12. Digest-Nonce-Count attribute . . . . . . . . . . . . . . . 22 88 4.13. Digest-Username attribute . . . . . . . . . . . . . . . . 22 89 4.14. Digest-Opaque attribute . . . . . . . . . . . . . . . . . 23 90 4.15. Digest-Auth-Param attribute . . . . . . . . . . . . . . . 23 91 4.16. Digest-AKA-Auts attribute . . . . . . . . . . . . . . . . 24 92 4.17. Digest-Domain attribute . . . . . . . . . . . . . . . . . 24 93 4.18. Digest-Stale attribute . . . . . . . . . . . . . . . . . . 24 94 4.19. Digest-HA1 attribute . . . . . . . . . . . . . . . . . . . 25 95 4.20. SIP-AOR . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 26 98 6. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 26 99 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 102 9.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 32 103 9.2. Confidentiality and Data Integrity . . . . . . . . . . . . 32 104 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 107 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 108 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35 109 A.1. Changes from draft-ietf-radext-digest-auth-06 . . . . . . 35 110 A.2. Changes from draft-ietf-radext-digest-auth-05 . . . . . . 35 111 A.3. Changes from draft-ietf-radext-digest-auth-04 . . . . . . 35 112 A.4. Changes from draft-ietf-radext-digest-auth-03 . . . . . . 35 113 A.5. Changes from draft-ietf-radext-digest-auth-02 . . . . . . 36 114 A.6. Changes from draft-ietf-radext-digest-auth-01 . . . . . . 36 115 A.7. Changes from draft-ietf-radext-digest-auth-00 . . . . . . 36 116 A.8. Changes from draft-sterman-aaa-sip-04 . . . . . . . . . . 36 117 A.9. Changes from draft-sterman-aaa-sip-03 . . . . . . . . . . 36 118 A.10. Changes from draft-sterman-aaa-sip-02 . . . . . . . . . . 37 119 A.11. Changes from draft-sterman-aaa-sip-01 . . . . . . . . . . 37 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 121 Intellectual Property and Copyright Statements . . . . . . . . . . 39 123 1. Introduction 125 1.1. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 The use of normative requirement key words in this document shall 132 apply only to RADIUS Client and RADIUS Server implementations that 133 include the features described in this document. This document 134 creates no normative requirements for existing implementations. 136 HTTP-style protocol 137 The term 'HTTP-style' denotes any protocol that uses HTTP-like 138 headers and uses HTTP digest authentication as described in 139 [RFC2617]. Examples are HTTP and the Session Initiation 140 Protocol (SIP). 141 NAS 142 Network Access Server, the RADIUS client. 143 nonce 144 An unpredictable value used to prevent replay attacks. The 145 nonce generator may use cryptographic mechanisms to produce 146 nonces it can recognize without maintaining state. 147 protection space 148 HTTP-style protocols differ in their definition of the 149 protection space. For HTTP, it is defined as the combination 150 of realm and canonical root URL of the requested resource the 151 use of which is authorized by the RADIUS server. In the case 152 of SIP, the realm string alone defines the protection space. 153 SIP UA 154 SIP User Agent, an Internet endpoint that uses the Session 155 Initiation Protocol. 156 SIP UAS 157 SIP User Agent Server, a logical entity that generates a 158 response to a SIP (Session Initiation Protocol) request. 160 1.2. Motivation 162 The HTTP Digest Authentication mechanism, defined in [RFC2617], was 163 subsequently adapted to use with SIP in [RFC2543] (obsoleted by 164 [RFC3261]). Due to the limitations and weaknesses of Digest 165 Authentication (see [RFC2617], section 4), additional authentication 166 and encryption mechanisms are defined in SIP [RFC3261], including TLS 167 [RFC2246] and S/MIME [RFC2633]. However, Digest Authentication 168 support is mandatory in SIP implementations and Digest Authentication 169 is the preferred way for a SIP UA to authenticate itself to a proxy 170 server. To support those clients there is a need for support of 171 Digest Authentication within AAA protocols such as RADIUS [RFC2865] 172 and Diameter [RFC3588]. 174 This document defines an extension to the RADIUS protocol to enable 175 support of Digest Authentication, for use with SIP, HTTP, and other 176 HTTP-style protocols using this authentication method. Support for 177 Digest mechanisms such as AKA [RFC3310] is also supported. A 178 companion document [I-D.ietf-aaa-diameter-sip-app] defines support 179 for Digest Authentication within Diameter. 181 1.3. Overview 183 HTTP digest is a challenge-response protocol used to authenticate a 184 client's request to access some resource on a server. Figure 1 shows 185 a single HTTP digest transaction. 187 HTTP/SIP.. 188 +------------+ (1) +------------+ 189 | |--------->| | 190 | HTTP-style | (2) | HTTP-style | 191 | Client |<---------| server | 192 | | (3) | | 193 | |--------->| | 194 | | (4) | | 195 | |<---------| | 196 +------------+ +------------+ 198 Figure 1: digest operation without RADIUS 200 If the client sends a request without any credentials (1), the server 201 will reply with an error response (2) containing a nonce. The client 202 creates a cryptographic digest from parts of the request, from the 203 nonce it received from the server, and a shared secret. The client 204 re-transmits the request (3) to the server, but now includes the 205 digest within the packet. The server does the same digest 206 calculation as the client and compares the result with the digest it 207 received in (3). If the digest values are identical, the server 208 grants access to the resource and sends a positive response to the 209 client (4). If the digest values differ, the server sends a negative 210 response to the client (4). 212 Instead of maintaining a local user database, the server could use 213 RADIUS to access a centralized user database. However, RADIUS 214 [RFC2865] does not include support for HTTP digest authentication. 215 The RADIUS client can not use the User-Password attribute, since it 216 does not receive a password from the HTTP-style client. The CHAP- 217 Challenge and CHAP-Password attributes described in [RFC1994] are 218 also not suitable since the CHAP algorithm is not compatible with 219 HTTP digest. 221 This document defines new attributes that enable the RADIUS server to 222 perform the digest calculation defined in [RFC2617], providing 223 support for Digest Authentication as a native authentication 224 mechanism within RADIUS. 226 This document defines new attributes that enable the RADIUS server to 227 perform the digest calculation defined in [RFC2617]. 229 The nonces required by the digest algorithm are either generated by 230 the RADIUS client or by the RADIUS server. A mix of nonce generation 231 modes is not supported. This specification assumes that both the 232 RADIUS client and server are appropriately configured to generate the 233 nonces in either the RADIUS client or the RADIUS server, but not in 234 both at the same time. Implementations, though, do not have the 235 means to verify this behavior. 237 1.3.1. Scenario 1, RADIUS client chooses nonces 239 HTTP/SIP RADIUS 241 +-----+ (1) +-----+ +-----+ 242 | |==========>| | | | 243 | | (2) | | | | 244 | |<==========| | | | 245 | | (3) | | | | 246 | |==========>| | | | 247 | A | | B | (4) | C | 248 | | | |---------->| | 249 | | | | (5) | | 250 | | | |<----------| | 251 | | (6) | | | | 252 | |<==========| | | | 253 +-----+ +-----+ +-----+ 255 ====> HTTP/SIP 256 ----> RADIUS 258 Figure 2: RADIUS client chooses nonces 260 The roles played by the entities in this scenario are as follows: 262 A: HTTP client / SIP UA 264 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 265 acting also as a RADIUS NAS (RADIUS client) 267 C: RADIUS server 269 The relevant order of messages sent in this scenario is as follows: 271 A sends B an HTTP/SIP request without authorization header (step 1). 272 B challenges A sending an HTTP/SIP "407 / 401 (Proxy) Authorization 273 required" response containing a locally generated nonce (step 2). A 274 sends B an HTTP/SIP request with authorization header (step 3). B 275 sends C a RADIUS Access-Request with attributes described in this 276 document (step 4). C responds to B with a RADIUS Access-Accept/ 277 Access-Reject response (step 5). If credentials were accepted, B 278 receives an Access-Accept response and the message sent from A is 279 considered authentic. If B receives an Access-Reject response, 280 however, B then responds to A with a "407 / 401 (Proxy) Authorization 281 required" response (step 6). 283 1.3.2. Scenario 2, RADIUS server chooses nonces 285 While the usage scenario described in Section 1.3.1 minimizes the 286 load on the RADIUS server, alternatives are required in some 287 situations. When using AKA [RFC3310] the nonce is partially derived 288 from a precomputed authentication vector, which is often stored 289 centrally. 291 Figure 3 depicts a scenario in which the RADIUS server chooses 292 nonces. In this case entities A and B communicate using HTTP or SIP, 293 while entities B and C communicate using RADIUS. 295 HTTP/SIP RADIUS 297 +-----+ (1) +-----+ +-----+ 298 | |==========>| | (2) | | 299 | | | |---------->| | 300 | | | | (3) | | 301 | | (4) | |<----------| | 302 | |<==========| | | | 303 | | (5) | | | | 304 | |==========>| | | | 305 | A | | B | (6) | C | 306 | | | |---------->| | 307 | | | | (7) | | 308 | | | |<----------| | 309 | | (8) | | | | 310 | |<==========| | | | 311 +-----+ +-----+ +-----+ 313 ====> HTTP/SIP 314 ----> RADIUS 316 Figure 3: RADIUS server chooses nonces 318 The roles played by the entities in this scenario are as follows: 320 A: HTTP client / SIP UA 321 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 322 acting also as a RADIUS NAS 324 C: RADIUS server 326 The following messages are sent in this scenario: 328 A sends B an HTTP/SIP request without an authorization header (step 329 1). B sends an Access-Request packet with the newly defined Digest- 330 Method and Digest-URI attributes but without a Digest-Nonce attribute 331 to the RADIUS server, C (step 2). C chooses a nonce and responds 332 with an Access-Challenge (step 3). This Access-Challenge contains 333 Digest attributes, from which B takes values to construct an HTTP/SIP 334 "(Proxy) Authorization required" response. The remaining steps are 335 identical with scenario 1 (Section 1.3.1): B sends this response to A 336 (step 4). A resends its request with its credentials (step 5). B 337 sends an Access-Request to C (step 6). C checks the credentials and 338 replies with Access-Accept or Access-Reject (step 7). Dependent on 339 the C's result, B processes A's request or rejects it with a "(Proxy) 340 Authorization required" response (step 8). 342 2. Interoperability 344 An implementation supporting this extension MUST include a Digest- 345 Response attribute within an Access-Request packet where Digest 346 Authentication is desired. An Access-Request MUST NOT contain both a 347 Digest-Response attribute and another authentication attribute, such 348 as User-Password, CHAP-Password, or EAP-Message. 350 RADIUS clients and servers MUST support both nonce generation modes. 351 As there is no automatic capability exchange, the operator must make 352 sure that the RADIUS client software uses the correct nonce 353 generation mode when accessing a specific RADIUS server: 354 o If the RADIUS server generates nonces, its RADIUS clients MUST NOT 355 try to generate nonces. 356 o If the RADIUS server does not generate nonces, its RADIUS clients 357 MUST generate nonces locally. 358 o If at least one HTTP-style client requires AKA authentication 359 [RFC3310], the RADIUS server MUST generate nonces and its RADIUS 360 clients MUST NOT generate nonces locally. 361 RADIUS implementations MUST offer respective configuration options. 363 3. Detailed Description 364 3.1. RADIUS Client Configuration 366 A RADIUS client choosing nonces has to maintain some configuration 367 data for each RADIUS server it may send requests to: 368 the algorithms (MD5, MD5-sess, etc) supported by the RADIUS server 369 the quality of protection (qop) levels supported by the RADIUS 370 server 371 This configuration may be done manually or by protocols not covered 372 in this document. 374 3.2. RADIUS Client Behavior 376 The attributes described in this document are sent in cleartext. 377 Therefore were a RADIUS client to accept secured connections (https 378 or sips) from HTTP-style clients, this could result in information 379 intentionally protected by HTTP-style clients being sent in the clear 380 during the RADIUS exchange. 382 3.2.1. Credential Selection 384 On reception of an HTTP-style request message, the RADIUS client 385 checks whether it is authorized to authenticate the request. Where 386 an HTTP-style request traverses several proxies and each of the 387 proxies requests to authenticate the HTTP-style client, the request 388 at the HTTP-style server may contain multiple credential sets. 390 The RADIUS client can use the 'realm' directive in HTTP to determine 391 which credentials are applicable. Where none of the realms are of 392 interest, the RADIUS client MUST behave as though no relevant 393 credentials were sent. In all situations the RADIUS client MUST send 394 zero or exactly one credential to the RADIUS server. The RADIUS 395 client MUST choose the credential of the (Proxy-)Authorization header 396 if the realm directive matches its locally configured realm. 398 3.2.2. Constructing an Access-Request 400 If a matching (Proxy-)Authorization header is present and contains 401 HTTP digest information, the RADIUS client checks the 'nonce' 402 parameter. If the RADIUS client generates nonces but did not issue 403 the received nonce, it responds with a 401 (Unauthorized) or 407 404 (Proxy Authentication Required) to the HTTP-style client. In this 405 error response, the RADIUS client sends a new nonce. 407 If the RADIUS client recognizes the nonce or does not generate 408 nonces, it takes the header directives and puts them into a RADIUS 409 Access-Request packet. It puts the 'response' directive into a 410 Digest-Response attribute and the realm, nonce, digest-uri, qop, 411 algorithm, cnonce, nc, username, and opaque directives into the 412 respective Digest-Realm, Digest-Nonce, Digest-URI, Digest-Qop, 413 Digest-Algorithm, Digest-CNonce, Digest-Nonce-Count, Digest- 414 Username, Digest-Opaque attributes. The request method is put into 415 the Digest-Method attribute. 417 If the qop directive's value is 'auth-int', the RADIUS client 418 calculates H(entity-body) as described in [RFC2617] 3.2.1 and puts 419 the result in a Digest-Entity-Body-Hash attribute. 421 The RADIUS client adds a Message- Authenticator attribute, defined in 422 [RFC3579] and sends the Access-Request packet to the RADIUS server. 424 The RADIUS server processes the packet and responds with an Access- 425 Accept or an Access-Reject. 427 3.2.3. Constructing an Authentication-Info header 429 After having received an Access-Accept from the RADIUS server, the 430 RADIUS client constructs an Authentication-Info header: 431 o If the Access-Accept packet contains a Digest-Response-Auth 432 attribute, the RADIUS client checks the Digest-Qop attribute: 433 * If the Digest-Qop attribute's value is 'auth' or not specified, 434 the RADIUS client puts the Digest-Response-Auth attribute's 435 content into the Authentication-Info header's 'rspauth' 436 directive of the HTTP-style response. 437 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 438 client ignores the Access-Accept packet and behaves like it had 439 received an Access-Reject packet (Digest-Response-Auth can't be 440 correct as the RADIUS server does not know the contents of the 441 HTTP-style response's body). 442 o If the Access-Accept packet contains a Digest-HA1 attribute, the 443 RADIUS client checks the 'qop' and 'algorithm' directives in the 444 Authorization header of the HTTP-style request it wants to 445 authorize: 446 * If the 'qop' directive is missing or its value is 'auth', the 447 RADIUS client ignores the Digest-HA1 attribute. It does not 448 include an Authentication-Info header into its HTTP-style 449 response. 450 * If the 'qop' directive's value is 'auth-int' and at least one 451 of the following conditions is true, the RADIUS client 452 calculates the contents of the HTTP-style response's 'rspauth' 453 directive: 454 + The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5- 455 sess'. 456 + IPsec is configured to protect traffic between RADIUS client 457 and RADIUS server with IPsec (see Section 9). 458 It creates the HTTP-style response message and calculates the 459 hash of this message's body. It uses the result and the 460 Digest-URI attribute's value of the corresponding Access- 461 Request packet to perform the H(A2) calculation. It takes the 462 Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop 463 values of the corresponding Access-Request and the Digest-HA1 464 attribute's value to finish the computation of the 'rspauth' 465 value. 466 o If the Access-Accept packet contains neither a Digest-Response- 467 Auth nor a Digest-HA1 attribute, the RADIUS client will not create 468 an Authentication-Info header for its HTTP-style response. 470 When the RADIUS server provides a Digest-Nextnonce attribute in the 471 Access-Accept packet, the RADIUS client puts the contents of this 472 attributes into a 'nextnonce' directive. Now it can send an HTTP- 473 style response. 475 3.2.4. Failed Authentication 477 If the RADIUS client did receive an HTTP-style request without a 478 (Proxy-)Authorization header matching its locally configured realm 479 value, it obtains a new nonce and sends an error response (401 or 480 407) containing a (Proxy-)Authenticate header. 482 If the RADIUS client receives an Access-Challenge packet in response 483 to an Access-Request containing a Digest-Nonce attribute, the RADIUS 484 server did not accept the nonce. If a Digest-Stale attribute is 485 present in the Access-Challenge and has a value of 'true' (without 486 surrounding quotes), the RADIUS client sends an error (401 or 407) 487 response containing WWW-/Proxy-Authenticate header with the directive 488 'stale' and the digest directives derived from the Digest-* 489 attributes. 491 If the RADIUS client receives an Access-Reject from the RADIUS 492 server, it sends an error response to the HTTP-style request it has 493 received. If the RADIUS client does not receive a response, it 494 retransmits or fails over to another RADIUS server as described in 495 [RFC2865]. 497 3.2.5. Obtaining Nonces 499 The RADIUS client has three ways to obtain nonces: it generates them 500 locally, it has received one in a Digest-Nextnonce attribute of a 501 previously received Access-Accept packet, or it asks the RADIUS 502 server for one. To do the latter, it sends an Access-Request 503 containing a Digest-Method and a Digest-URI attribute but without a 504 Digest-Nonce attribute. It adds a Message-Authenticator (see 505 [RFC3579]) attribute to the Access-Request packet. The RADIUS server 506 chooses a nonce and responds with an Access-Challenge containing a 507 Digest-Nonce attribute. 509 The RADIUS client constructs a (Proxy-)Authenticate header using the 510 received Digest-Nonce and Digest-Realm attributes to fill the nonce 511 and realm directives. The RADIUS server can send Digest-Qop, Digest- 512 Algorithm, Digest-Domain and Digest-Opaque attributes in the Access- 513 Challenge carrying the nonce. If these attributes are present, the 514 client MUST use them. 516 If the RADIUS client generates nonces, the nonce must contain a 517 sequence number. The nonce is constructed as follows: 519 nonce = concat(nonce-seq, nonce-opt) 520 nonce-seq = base64(r, concat(seq, hn(concat(r, seq), secret))) 522 where 524 'concat(a, b)' appends string b to string a 526 'nonce-opt' is an optional string of additional nonce 527 characters. 529 'base64(x)' encodes string x in base64 as described in 530 [RFC3548], section 3 532 'seq' is a signed integer of 4 bytes in network byte order. It 533 is a sequence number that is increased for every generated 534 nonce. The RADIUS client maintains a separate sequence number 535 for every RADIUS server it contacts. The sequence number MUST 536 be stored in memory that survives reboots. 538 'secret' is the shared secret between RADIUS client and server 540 'hn(secret, message)' produces a hash of 'message' using the 541 pass phrase 'secret'. The digest algorithm determines what 542 hash function must be used. For 'MD5', 'MD5-sess', 'AKAv1- 543 MD5', and 'AKAv1-MD5-sess' 'hn' is the HMAC MD5 function 544 described in [RFC2104]. Future digest algorithms may define 545 different hash functions to generate the nonce. If a digest 546 algorithm does not prescribe a hash function, HMAC MD5 is used. 548 'r' is a string of 28 random characters that is uniquely 549 generated for each nonce. 551 The sequence number 'seq' enables the RADIUS server to reject 552 replayed nonces. 554 3.3. RADIUS Server Behavior 556 If the RADIUS server receives an Access-Request packet with a Digest- 557 Method and a Digest-URI attribute but without a Digest-Nonce 558 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 559 attribute and sends it in an Access-Challenge packet to the RADIUS 560 client. The RADIUS server MUST add Digest-Realm, Message- 561 Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or 562 more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes 563 to the Access-Challenge packet. If the server cannot choose a nonce, 564 it replies with an Access-Reject packet. 566 3.3.1. General Attribute Checks 568 If the RADIUS server receives an Access-Request packet containing a 569 Digest-Response attribute, it looks for the following attributes: 570 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, 571 Digest-Algorithm, Digest-Username. Depending on the content of 572 Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- 573 Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and 574 [RFC3310] for details. If the Digest-Algorithm attribute is missing, 575 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque 576 attribute along with the nonce, the Access-Request MUST have a 577 matching Digest-Opaque attribute. 579 If mandatory attributes are missing, it MUST respond with an Access- 580 Reject packet. 582 If the mandatory attributes are present, the RADIUS server MUST check 583 if the RADIUS client is authorized to serve users of the realm 584 mentioned in the Digest-Realm attribute. If the RADIUS client is not 585 authorized, the RADIUS server MUST send an Access-Reject. The RADIUS 586 server SHOULD log the event so as to notify the operator, and MAY 587 take additional action such as sending an Access-Reject in response 588 to all future requests from this client, until this behavior is reset 589 by management action. 591 3.3.2. Checking the Nonce Validity 593 If the RADIUS server generates nonces, it will determine the age of a 594 nonce by using an embedded time-stamp, or by looking it up in a local 595 table. The RADIUS server MUST check the integrity of the nonce, if 596 it embeds the time-stamp in the nonce. Section 3.3.3 describes how 597 the server handles old nonces. 599 If the RADIUS client generates nonces, the RADIUS server checks the 600 integrity of the embedded sequence number. The RADIUS server 601 responds with an Access-Reject packet if an Access-Request has a 602 nonce that is invalid, or has an old sequence number. 604 A RADIUS client-generated nonce is considered invalid if the locally 605 calculated nonce-seq value differs from the received nonce-seq value. 607 To check the integrity of a received nonce, the RADIUS server 608 performs the following steps: 610 1. It decodes the base64 nonce as a string 'd'. 611 2. From 'd', it puts the first 28 bytes into a string 'r'. 612 3. From 'd', it decodes the next 4 bytes as a network byte order 613 sequence number 'seq'. 614 4. If 'd' exceeds 48 bytes, the exceeding bytes represent a string 615 'nonce-opt'. If not, 'nonce-opt' is an empty string. 616 5. It calculates a new nonce 'chk' as described in Section 3.2.5 617 using 'r', 'seq', the shared secret, and 'nonce-opt'. 618 6. The received nonce is valid if it equals 'chk' 620 An implementation may use the optional nonce-opt bytes to perform 621 additional checks. 623 The RADIUS server checks the sequence number 'seq' to detect replayed 624 nonces. It compares 'seq' to the sequence number it has received in 625 the last valid nonce from the RADIUS client identified by the NAS-IP- 626 Address or NAS-Identifier attribute. 628 If the sequence number of a RADIUS client is not known yet, the nonce 629 is considered valid. 631 If 'seq' is less than or equals the previous sequence number of the 632 RADIUS client, the nonce is considered stale. 634 If the difference between the received and the previous sequence 635 number of the RADIUS client is bigger than 100, the nonce is 636 considered invalid. 638 3.3.3. Authentication 640 If the Access-Request message has passed the checks described above, 641 the RADIUS server calculates the digest response as described in 642 [RFC2617]. To look up the password, the RADIUS server uses the 643 RADIUS User-Name attribute. The RADIUS server MUST check if the user 644 identified by the User-Name attribute 645 o is authorized to access the protection space 646 o is authorized to use the URI included in the SIP-AOR attribute, if 647 this attribute is present. 648 If any of those checks fails, the RADIUS server MUST send an Access- 649 Reject. 651 Correlation between User-Name and SIP-AOR AVP values is required just 652 to avoid that any user can register or misuse a SIP-AOR allocated to 653 another user. 655 All values required for the digest calculation are taken from the 656 Digest attributes described in this document. If the calculated 657 digest response equals the value received in the Digest-Response 658 attribute, the authentication was successful. 660 If the response values match and the RADIUS server issues nonces, but 661 considers the one in the Digest-Nonce attribute as too old, it sends 662 an Access-Challenge packet containing a new nonce and a Digest-Stale 663 attribute with a value of 'true' (without surrounding quotes). 665 If the response values don't match, the RADIUS server responds with 666 an Access-Reject. 668 3.3.4. Constructing the Reply 670 If the authentication was successful, the RADIUS server adds an 671 attribute to the Access-Accept packet which can be used by the RADIUS 672 client to construct an Authentication-Info header: 673 o If the Digest-Qop attribute's value is 'auth' or unspecified, the 674 RADIUS server SHOULD put a Digest-Response-Auth attribute into the 675 Access-Accept packet 676 o If the Digest-Qop attribute's value is 'auth-int' and at least one 677 of the following conditions is true, the RADIUS server SHOULD put 678 a Digest-HA1 attribute into the Access-Accept packet: 679 * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- 680 MD5-sess'. 681 * IPsec is configured to protect traffic between RADIUS client 682 and RADIUS server with IPsec (see Section 9). 683 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be 684 sent. 686 RADIUS servers issuing nonces MAY construct a Digest-Nextnonce 687 attribute and add it to the Access-Accept packet. This is useful to 688 limit the lifetime of a nonce and to save a round-trip in future 689 requests (see nextnonce discussion in [RFC2617], section 3.2.3). The 690 RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) 691 and sends the Access-Accept packet to the RADIUS client. 693 If the RADIUS server does not accept the nonce received in an Access- 694 Request packet but authentication was successful, the RADIUS server 695 MUST send an Access-Challenge packet containing a Digest-Stale 696 attribute set to 'true' (without surrounding quotes). The RADIUS 697 server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce, 698 Digest-Realm, SHOULD add Digest-Algorithm, one or more Digest-Qop and 699 MAY add Digest-Domain, Digest-Opaque attributes to the Access- 700 Challenge packet. 702 4. New RADIUS attributes 704 If not stated otherwise, the attributes have the following format: 706 0 1 2 707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Type | Length | Text ... 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 4.1. Digest-Response attribute 714 Description 715 If this attribute is present in an Access-Request message, a 716 RADIUS server implementing this specification MUST treat the 717 Access-Request as a request for Digest Authentication. When a 718 RADIUS client receives a (Proxy-)Authorization header, it puts 719 the request-digest value into a Digest-Response attribute. 720 This attribute (which enables the user to prove possession of 721 the password) MUST only be used in Access-Requests. 722 Type 723 [IANA TBD] for Digest-Response. 724 Length 725 >= 3 726 Text 727 When using HTTP digest, the text field is 32 octets long and 728 contains a hexadecimal representation of 16 octet digest value 729 as it was calculated by the authenticated client. Other digest 730 algorithms MAY define different digest lengths. The text field 731 MUST be copied from request-digest of digest-response 732 ([RFC2617]) without surrounding quotes. 734 4.2. Digest-Realm attribute 736 Description 737 This attribute describes the protection space of the RADIUS 738 server. See [RFC2617] 1.2 for details. It MUST only be used 739 in Access-Request and Access-Challenge packets. 740 Type 742 [IANA TBD] for Digest-Realm 743 Length 744 >=3 745 Text 746 In Access-Requests, the RADIUS client takes the value of the 747 realm directive (realm-value according to [RFC2617]) without 748 quotes from the HTTP-style request it wants to authenticate. 749 In Access-Challenge packets, the RADIUS server puts the 750 expected realm value into this attribute. 752 4.3. Digest-Nonce attribute 754 Description 755 This attribute holds a nonce to be used in the HTTP Digest 756 calculation. If the Access-Request had a Digest-Method and a 757 Digest-URI but no Digest-Nonce attribute and the RADIUS server 758 is configured to choose nonces, it MUST put a Digest-Nonce 759 attribute into its Access-Challenge packet. This attribute 760 MUST only be used in Access-Request and Access-Challenge 761 packets. 762 Type 763 [IANA TBD] for Digest-Nonce 764 Length 765 >=3 766 Text 767 In Access-Requests, the RADIUS client takes the value of the 768 nonce directive (nonce-value in [RFC2617]) without quotes from 769 the HTTP-style request it wants to authenticate. In Access- 770 Challenge packets, the attribute contains the nonce selected by 771 the RADIUS server. 773 4.4. Digest-Response-Auth attribute 775 Description 776 This attribute enables the RADIUS server to prove possession of 777 the password. If the previously received Digest-Qop attribute 778 was 'auth-int' (without surrounding quotes), the RADIUS server 779 MUST send a Digest-HA1 attribute instead of a Digest-Response- 780 Auth attribute. The Digest-Response-Auth attribute MUST only 781 be used in Access-Accept packets. The RADIUS client puts the 782 attribute value without surrounding quotes into the rspauth 783 directive of the Authentication-Info header. 784 Type 785 [IANA TBD] for Digest-Response-Auth. 787 Length 788 >= 3 789 Text 790 The RADIUS server calculates a digest according to section 791 3.2.3 of [RFC2617] and copies the result into this attribute. 792 Other digest algorithms than the one defined in [RFC2617] MAY 793 define digest lengths other than 32. 795 4.5. Digest-Nextnonce attribute 797 This attribute holds a nonce to be used in the HTTP Digest 798 calculation. 800 Description 801 If the RADIUS server is configured to choose nonces it MAY put 802 a Digest-Nextnonce attribute into an Access-Accept packet. If 803 this attribute is present, the RADIUS client MUST put the 804 contents of this attribute into the nextnonce directive of an 805 Authentication-Info header in its HTTP-style response. This 806 attribute MUST only be used in Access-Accept packets. 807 Type 808 [IANA TBD] for Digest-Nextnonce 809 Length 810 >=3 811 Text 812 It is recommended that this text be base64 or hexadecimal data. 814 4.6. Digest-Method attribute 816 Description 817 This attribute holds the method value to be used in the HTTP 818 Digest calculation. This attribute MUST only be used in 819 Access-Request packets. 820 Type 821 [IANA TBD] for Digest-Method 822 Length 823 >=3 824 Text 825 In Access-Requests, the RADIUS client takes the value of the 826 request method from the HTTP-style request it wants to 827 authenticate. 829 4.7. Digest-URI attribute 830 Description 831 This attribute is used to transport the contents of the digest- 832 uri directive or the URI of the HTTP-style request. It MUST 833 only be used in Access-Request packets. 834 Type 835 [IANA TBD] for Digest-URI 836 Length 837 >=3 838 Text 839 If the HTTP-style request has an Authorization header, the 840 RADIUS client puts the value of the "uri" directive in the 841 (known as "digest-uri-value" in section 3.2.2 of [RFC2617]) 842 without surrounding quotes into this attribute. If there is no 843 Authorization header, the RADIUS client takes the value of the 844 request URI from the HTTP-style request it wants to 845 authenticate. 847 4.8. Digest-Qop attribute 849 Description 850 This attribute holds the Quality of Protection parameter that 851 influences the HTTP Digest calculation. This attribute MUST 852 only be used in Access-Request and Access-Challenge packets. A 853 RADIUS client SHOULD insert one of the Digest-Qop attributes it 854 has received in a previous Access-Challenge packet. RADIUS 855 servers SHOULD insert at least one Digest-Qop attribute in an 856 Access-Challenge packet. Digest-Qop is optional in order to 857 preserve backward compatibility with a minimal implementation 858 of [RFC2069]. 859 Type 860 [IANA TBD] for Digest-Qop 861 Length 862 >=3 863 Text 864 In Access-Requests, the RADIUS client takes the value of the 865 qop directive (qop-value as described in [RFC2617]) without the 866 quotes from the HTTP-style request it wants to authenticate. 867 In Access-Challenge packets, the RADIUS server puts a desired 868 qop-value into this attribute. If the RADIUS server supports 869 more than one "quality of protection" value, it puts each qop- 870 value into a separate Digest-Qop attribute. 872 4.9. Digest-Algorithm attribute 873 Type 874 This attribute holds the algorithm parameter that influences 875 the HTTP Digest calculation. It MUST only be used in Access- 876 Request and Access-Challenge packets. If this attribute is 877 missing, "MD5" is assumed. 878 Type 879 [IANA TBD] for Digest-Algorithm 880 Length 881 >=3 882 Text 883 In Access-Requests, the RADIUS client takes the value of the 884 algorithm directive (as described in [RFC2617], section 3.2.1) 885 without the quotes from the HTTP-style request it wants to 886 authenticate. In Access-Challenge packets, the RADIUS server 887 SHOULD put the desired algorithm into this attribute. 889 4.10. Digest-Entity-Body-Hash attribute 891 Description 892 When using the qop level 'auth-int', a hash of the HTTP-style 893 message body's contents is required for digest calculation. 894 Instead of sending the complete body of the message, only its 895 hash value is sent. This hash value can be used directly in 896 the digest calculation. 897 The clarifications described in section 22.4 of [RFC2617] about 898 the hash of empty entity bodies apply to the Digest-Entity- 899 Body-Hash attribute. This attribute MUST only be sent in 900 Access-Request packets. 901 Type 902 [IANA TBD] for Digest-Entity-Body-Hash 903 Length 904 >=3 905 Text 906 The attribute holds the hexadecimal representation of H(entity- 907 body). This hash is required by certain authentication 908 mechanisms, such as HTTP Digest with quality of protection set 909 to "auth-int". RADIUS clients MUST use this attribute to 910 transport the hash of the entity body when HTTP Digest is the 911 authentication mechanism and the RADIUS server requires to 912 verify the integrity of the entity body (e.g., qop parameter 913 set to "auth-int"). Extensions to this document may define 914 support for authentication mechanisms other than HTTP Digest. 916 4.11. Digest-CNonce attribute 917 Description 918 This attribute holds the client nonce parameter that is used in 919 the HTTP Digest calculation. It MUST only be used in Access- 920 Request packets. 921 Type 922 [IANA TBD] for Digest-CNonce 923 Length 924 >=3 925 Text 926 This attribute includes the value of the cnonce-value [RFC2617] 927 without surrounding quotes, taken from the HTTP-style request. 929 4.12. Digest-Nonce-Count attribute 931 Description 932 This attribute includes the nonce count parameter that is used 933 to detect replay attacks. The attribute MUST only be used in 934 Access-Request packets. 935 Type 936 [IANA TBD] for Digest-Nonce-Count 937 Length 938 10 939 Text 940 In Access-Requests, the RADIUS client takes the value of the nc 941 directive (nc-value according to [RFC2617]) without quotes from 942 the HTTP-style request it wants to authenticate. 944 4.13. Digest-Username attribute 946 Description 947 This attribute holds the user name used in the HTTP digest 948 calculation. The RADIUS server MUST use this attribute only 949 for the purposes of calculating the digest. In order to 950 determine the appropriate user credentials, the RADIUS server 951 MUST use the User-Name (1) attribute, and MUST NOT use the 952 Digest-Username attribute. This attribute MUST only be used in 953 Access-Request packets. 954 Type 955 [IANA TBD] for Digest-Username 956 Length 957 >= 3 958 Text 959 In Access-Requests, the RADIUS client takes the value of the 960 username directive (username-value according to [RFC2617]) 961 without surrounding quotes from the HTTP-style request it wants 962 to authenticate. 964 4.14. Digest-Opaque attribute 966 Description 967 This attribute holds the opaque parameter that is passed to the 968 HTTP-style client. The HTTP-style client will pass this value 969 back to the server (i.e. the RADIUS client) without 970 modification. This attribute is only used when the RADIUS 971 server chooses nonces and MUST only be used in Access-Request 972 and Access-Challenge packets. 973 Type 974 [IANA TBD] for Digest-Opaque 975 Length 976 >=3 977 Text 978 In Access-Requests, the RADIUS client takes the value of the 979 opaque directive (opaque-value according to [RFC2617]) without 980 surrounding quotes from the HTTP-style request it wants to 981 authenticate and puts it into this attribute. In Access- 982 Challenge packets, the RADIUS server MAY include this 983 attribute. 985 4.15. Digest-Auth-Param attribute 987 Description 988 This attribute is a placeholder for future extensions and 989 corresponds to the "auth-param" parameter defined in section 990 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism 991 whereby the RADIUS client and RADIUS server can exchange auth- 992 param extension parameters contained within Digest headers that 993 are not understood by the RADIUS client and for which there are 994 no corresponding stand-alone attributes. 995 Unlike the previously listed Digest-* attributes, the Digest- 996 Auth-Param contains not only the value, but also the parameter 997 name, since the parameter name is unknown to the RADIUS client. 998 If the Digest header contains several unknown parameters, then 999 the RADIUS implementation MUST repeat this attribute and each 1000 instance MUST contain one different unknown Digest parameter/ 1001 value combination. This attribute MUST ONLY be used in Access- 1002 Request, Access-Challenge, or Access-Accept packets. 1003 Type 1004 [IANA TBD] for Digest-Auth-Param 1005 Length 1006 >=3 1007 Text 1008 The text consists of the whole parameter, including its name 1009 and the equal ('=') sign and quotes. 1011 4.16. Digest-AKA-Auts attribute 1013 Description 1014 This attribute holds the auts parameter that is used in the 1015 Digest AKA ([RFC3310]) calculation. It is only used if the 1016 algorithm of the digest-response denotes a version of AKA 1017 digest [RFC3310]. This attribute MUST only be used in Access- 1018 Request packets. 1019 Type 1020 [IANA TBD] for Digest-AKA-Auts 1021 Length 1022 >=3 1023 Text 1024 In Access-Requests, the RADIUS client takes the value of the 1025 auts directive (auts-param according to section 3.4 of 1026 [RFC3310]) without surrounding quotes from the HTTP-style 1027 request it wants to authenticate. 1029 4.17. Digest-Domain attribute 1031 Description 1032 When a RADIUS client has asked for a nonce, the RADIUS server 1033 MAY send one or more Digest-Domain attributes in its Access- 1034 Challenge packet. The RADIUS client puts them into the quoted, 1035 space-separated list of URIs of the 'domain' directive of a 1036 WWW-Authenticate header. The URIs in the list define the 1037 protection space (see [RFC2617], section 3.2.1). This 1038 attribute MUST only be used in Access-Challenge packets. 1039 Type 1040 [IANA TBD] for Digest-Domain 1041 Length 1042 3 1043 Text 1044 This attribute consists of a single URI, that defines a 1045 protection space. 1047 4.18. Digest-Stale attribute 1049 Description 1050 This attribute is sent by a RADIUS server in order to notify 1051 the RADIUS client whether it has accepted a nonce. If the 1052 nonce presented by the RADIUS client was stale, the value is 1053 'true' and is 'false' otherwise. The RADIUS client puts the 1054 content of this attribute into a 'stale' directive of the WWW- 1055 Authenticate header in the HTTP-style response to the request 1056 it wants to authenticate. The attribute MUST only be used in 1057 Access-Challenge packets and only if the RADIUS server chooses 1058 nonces. 1059 Type 1060 [IANA TBD] for Digest-Stale 1061 Length 1062 3 1063 Text 1064 The attribute has either the value 'true' or 'false' (both 1065 values without surrounding quotes). 1067 4.19. Digest-HA1 attribute 1069 Description 1070 This attribute is used to allow the generation of an 1071 Authentication-Info header, even if the HTTP-style response's 1072 body is required for the calculation of the rspauth value. It 1073 SHOULD be used in Access-Accept packets if the required quality 1074 of protection ('qop') is 'auth-int'. 1075 This attribute MUST NOT be sent if the qop parameter was not 1076 specified or has a value of 'auth' (in this case, use Digest- 1077 Response-Auth instead). 1078 The Digest-HA1 attribute MUST only be sent by the RADIUS server 1079 or processed by the RADIUS client if at least one of the 1080 following conditions is true: 1081 + The Digest-Algorithm attribute's value is 'MD5-sess' or 1082 'AKAv1-MD5-sess'. 1083 + IPsec is configured to protect traffic between RADIUS client 1084 and RADIUS server with IPsec (see Section 9). 1085 This attribute MUST only be used in Access-Accept packets. 1086 Type 1087 [IANA TBD] for Digest-HA1 1088 Length 1089 >= 3 1090 Text 1091 This attribute contains the hexadecimal representation of H(A1) 1092 as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2. 1094 4.20. SIP-AOR 1096 Description 1097 This attribute is used for the authorization of SIP messages. 1098 The SIP-AOR attribute identifies the URI the use of which must 1099 be authenticated and authorized. The RADIUS server uses this 1100 attribute to authorize the processing of the SIP request. The 1101 SIP-AOR can be derived from, e.g., the To header field in a SIP 1102 REGISTER request (user under registration), or the From header 1103 field in other SIP requests. However, the exact mapping of 1104 this attribute to SIP can change due to new developments in the 1105 protocol. This attribute MUST only be used when the RADIUS 1106 client wants to authorize SIP users and MUST only be used in 1107 Access-Request packets. 1108 Type 1109 [IANA TBD] for SIP-AOR 1110 Length 1111 >=3 1112 Text 1113 The syntax of this attribute corresponds either to a SIP URI 1114 (with the format defined in [RFC3261] or a TEL URI (with the 1115 format defined in [RFC3966]). 1116 The SIP-AOR attribute holds the complete URI, including 1117 parameters and other parts. It is up to the RADIUS server what 1118 components of the URI are regarded in the authorization 1119 decision. 1121 5. Diameter Compatibility 1123 This document defines support for Digest Authentication in RADIUS. A 1124 companion document "Diameter Session Initiation Protocol (SIP) 1125 Application" [I-D.ietf-aaa-diameter-sip-app] defines support for 1126 Digest Authentication in Diameter, and addresses compatibility issues 1127 between RADIUS and Diameter. 1129 6. Table of Attributes 1131 The following table provides a guide to which attributes may be found 1132 in which kinds of packets, and in what quantity. 1134 Req Accept Reject Challenge # Attribute 1135 1 0 0 0 1 User-Name 1136 1 1 1 1 80 Message-Authenticator 1137 0-1 0 0 0 TBD Digest-Response 1138 0-1 0 0 1 TBD Digest-Realm 1139 0-1 0 0 1 TBD Digest-Nonce 1140 0 0-1 0 0 TBD Digest-Response-Auth 1141 (see Note 1, 2) 1142 0 0-1 0 0 TBD Digest-Nextnonce 1143 0-1 0 0 0 TBD Digest-Method 1144 0-1 0 0 0 TBD Digest-URI 1145 0-1 0 0 0+ TBD Digest-Qop 1146 0-1 0 0 0-1 TBD Digest-Algorithm (see 1147 Note 3) 1148 0-1 0 0 0 TBD Digest-Entity-Body-Hash 1149 0-1 0 0 0 TBD Digest-CNonce 1150 0-1 0 0 0 TBD Digest-Nonce-Count 1151 0-1 0 0 0 TBD Digest-Username 1152 0-1 0 0 0-1 TBD Digest-Opaque 1153 0+ 0+ 0 0+ TBD Digest-Auth-Param 1154 0-1 0 0 0 TBD Digest-AKA-Auts 1155 0 0 0 0+ TBD Digest-Domain 1156 0 0 0 0-1 TBD Digest-Stale 1157 0 0-1 0 0 TBD Digest-HA1 (see Note 1, 1158 2) 1159 0-1 0 0 0 TBD SIP-AOR 1161 Table 1 1163 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if 1164 Digest-Qop is 'auth-int'. 1165 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if 1166 Digest-Qop is 'auth'. 1167 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed 1169 7. Examples 1171 This is an example sniffed from the traffic between a softphone (A), 1172 a Proxy Server (B) and example.com RADIUS server (C). The 1173 communication between the Proxy Server and a SIP PSTN gateway is 1174 omitted for brevity. The SIP messages are not shown completely. 1176 A->B 1178 INVITE sip:97226491335@example.com SIP/2.0 1179 From: 1180 To: 1182 B->A 1184 SIP/2.0 100 Trying 1186 B->A 1188 SIP/2.0 407 Proxy Authentication Required 1189 Proxy-Authenticate: Digest realm="example.com" 1190 ,nonce="3bada1a0", algorithm="md5" 1191 Content-Length: 0 1193 A->B 1195 ACK sip:97226491335@example.com SIP/2.0 1197 A->B 1199 INVITE sip:97226491335@example.com SIP/2.0 1200 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1201 ,opaque="",realm="example.com" 1202 ,response="f3ce87e6984557cd0fecc26f3c5e97a4" 1203 ,uri="sip:97226491335@example.com",username="12345678" 1204 From: 1205 To: 1207 B->C 1209 Code = 1 (Access-Request) 1210 Attributes: 1211 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1212 NAS-Port-Type = 5 (Virtual) 1213 User-Name = "12345678" 1214 Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" 1215 Digest-Realm = "example.com" 1216 Digest-Nonce = "3bada1a0" 1217 Digest-Method = "INVITE" 1218 Digest-URI = "sip:97226491335@example.com" 1219 Digest-Algorithm = "md5" 1220 Digest-Username = "12345678" 1221 SIP-AOR = "sip:12345678@example.com" 1222 Message-Authenticator = 1223 ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff 1225 C->B 1227 Code = 2 (Access-Accept) 1228 Attributes: 1229 Digest-Response-Auth = 1230 "6303c41b0e2c3e524e413cafe8cce954" 1231 Message-Authenticator = 1232 75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1 1234 B->A 1236 SIP/2.0 180 Ringing 1238 B->A 1240 SIP/2.0 200 OK 1242 A->B 1244 ACK sip:97226491335@example.com SIP/2.0 1246 A second example shows the traffic between a web browser (A), web 1247 server (B) and a RADIUS server (C). 1249 A->B 1251 GET /index.html HTTP/1.1 1253 B->A 1255 HTTP/1.1 401 Authentication Required 1256 WWW-Authenticate: Digest realm="example.com", 1257 domain="/index.html", 1258 nonce="a3086ac8", algorithm="md5" 1259 Content-Length: 0 1261 A->B 1263 GET /index.html HTTP/1.1 1264 Authorization: Digest algorithm="md5",nonce="a3086ac8" 1265 ,opaque="",realm="example.com" 1266 ,response="f052b68058b2987aba493857ae1ab002" 1267 ,uri="/index.html",username="12345678" 1269 B->C 1271 Code = 1 (Access-Request) 1272 Attributes: 1273 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1274 NAS-Port-Type = 5 (Virtual) 1275 User-Name = "12345678" 1276 Digest-Response = "f052b68058b2987aba493857ae1ab002" 1277 Digest-Realm = "example.com" 1278 Digest-Nonce = "a3086ac8" 1279 Digest-Method = "GET" 1280 Digest-URI = "/index.html" 1281 Digest-Algorithm = "md5" 1282 Digest-Username = "12345678" 1283 Message-Authenticator = 1284 06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b 1286 C->B 1288 Code = 2 (Access-Accept) 1289 Attributes: 1290 Digest-Response-Auth = 1291 "e644aa513effbfe1caff67103ff6433c" 1292 Message-Authenticator = 1293 7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7 1295 B->A 1297 HTTP/1.1 200 OK 1298 ... 1300 1301 ... 1303 8. IANA Considerations 1305 This document serves as IANA registration request for a number of 1306 values from the RADIUS attribute type number space: 1308 +-------------------------+------------------------+ 1309 | placeholder | value assigned by IANA | 1310 +-------------------------+------------------------+ 1311 | Digest-Response | TBD | 1312 | Digest-Realm | TBD | 1313 | Digest-Nonce | TBD | 1314 | Digest-Nextnonce | TBD | 1315 | Digest-Response-Auth | TBD | 1316 | Digest-Method | TBD | 1317 | Digest-URI | TBD | 1318 | Digest-Qop | TBD | 1319 | Digest-Algorithm | TBD | 1320 | Digest-Entity-Body-Hash | TBD | 1321 | Digest-CNonce | TBD | 1322 | Digest-Nonce-Count | TBD | 1323 | Digest-Username | TBD | 1324 | Digest-Opaque | TBD | 1325 | Digest-Auth-Param | TBD | 1326 | Digest-AKA-Auts | TBD | 1327 | Digest-Domain | TBD | 1328 | Digest-Stale | TBD | 1329 | Digest-HA1 | TBD | 1330 | SIP-AOR | TBD | 1331 +-------------------------+------------------------+ 1333 Table 2 1335 9. Security Considerations 1337 The RADIUS extensions described in this document enable RADIUS to 1338 transport the data that required to perform a digest calculation. As 1339 a result, RADIUS inherits the vulnerabilities of HTTP Digest (see 1340 [RFC2617], section 4) in addition to RADIUS security vulnerabilities 1341 described in [RFC2865] Section 8 and [RFC3579] Section 4. 1343 An attacker compromising a RADIUS client or proxy can carry out man- 1344 in-the-middle attacks even if the paths between A, B and B, C 1345 (Figure 2) have been secured with TLS or IPsec. 1347 The RADIUS server MUST check the Digest-Realm attribute it has 1348 received from a client. If the RADIUS client is not authorized to 1349 serve HTTP-style clients of that realm, it might be compromised. 1351 A compromised RADIUS client that is expected to generate nonces could 1352 replay successful exchanges to incur expenses in the name of a 1353 victim. To avoid this, RADIUS clients generating nonces MUST use a 1354 nonce format that allows the RADIUS server to detect nonce replays, 1355 as described in Section 3.2.5. 1357 9.1. Denial of Service 1359 RADIUS clients implementing the extension described in this document 1360 may authenticate HTTP-style requests received over the Internet. As 1361 compared with use of RADIUS to authenticate link layer network 1362 access, an attacker may find it easier to cover their tracks in such 1363 a scenario. 1365 An attacker can attempt a denial of service attack on one or more 1366 RADIUS servers by sending a large number of HTTP-style requests. To 1367 make simple denial of service attacks more difficult, the nonce 1368 issuer (RADIUS client or server) MUST check if it has generated the 1369 nonce received from an HTTP-style client. This SHOULD be done 1370 statelessly. For example, a nonce could consist of a 1371 cryptographically random part and some kind of signature provided by 1372 the RADIUS client, as described in [RFC2617], section 3.2.1. 1374 9.2. Confidentiality and Data Integrity 1376 The attributes described in this document are sent in cleartext. 1377 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm 1378 attributes in Access-Challenge messages. A man in the middle can 1379 modify or remove those attributes in a bidding down attack, causing 1380 the RADIUS client to use a weaker authentication scheme than 1381 intended. 1383 The Message-Authenticator attribute, described in [RFC3579] section 1384 3.2 MUST be included in Access-Request, Access-Challenge, Access- 1385 Reject and Access-Accept messages that contain attributes described 1386 in this specification. 1388 The Digest-HA1 attribute contains no random components if the 1389 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1390 attacks easier and enables replay attacks. 1392 Some parameter combinations require the protection of RADIUS packets 1393 against eavesdropping and tampering. Implementations SHOULD try to 1394 determine automatically whether IPsec is configured to protect 1395 traffic between the RADIUS client and the RADIUS server. If this is 1396 not possible, the implementation checks a configuration parameter 1397 telling it whether IPsec will protect RADIUS traffic. The default 1398 value of this configuration parameter tells the implementation that 1399 RADIUS packet will not be protected. 1401 HTTP-style clients can use TLS with server side certificates together 1402 with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, 1403 too. TLS or IPsec secure the connection while Digest Authentication 1404 authenticates the user. The RADIUS transaction can be regarded as 1405 one leg on the path between the HTTP-style client and the HTTP-style 1406 server. To prevent RADIUS from representing the weak link, a RADIUS 1407 client receiving an HTTP-style request via TLS or IPsec could use an 1408 equally secure connection to the RADIUS server. There are several 1409 ways to achieve this, for example: 1410 o the RADIUS client may reject HTTP-style requests received over TLS 1411 or IPsec 1412 o the RADIUS client require that traffic be sent and received over 1413 IPsec. 1414 RADIUS over IPsec, if used, MUST conform to the requirements 1415 described in [RFC3579] section 4.2. 1417 10. Acknowledgments 1419 We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or 1420 providing comments and experimental implementation. 1422 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1423 Arkko, Avi Lior and Jun Wang. 1425 11. References 1427 11.1. Normative References 1429 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1430 Hashing for Message Authentication", RFC 2104, 1431 February 1997. 1433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1434 Requirement Levels", BCP 14, RFC 2119, March 1997. 1436 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1437 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1438 Authentication: Basic and Digest Access Authentication", 1439 RFC 2617, June 1999. 1441 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1442 "Remote Authentication Dial In User Service (RADIUS)", 1443 RFC 2865, June 2000. 1445 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1446 A., Peterson, J., Sparks, R., Handley, M., and E. 1447 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1448 June 2002. 1450 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1451 Encodings", RFC 3548, July 2003. 1453 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1454 Dial In User Service) Support For Extensible 1455 Authentication Protocol (EAP)", RFC 3579, September 2003. 1457 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1458 RFC 3966, December 2004. 1460 11.2. Informative References 1462 [I-D.ietf-aaa-diameter-sip-app] 1463 Garcia-Martin, M., "Diameter Session Initiation Protocol 1464 (SIP) Application", draft-ietf-aaa-diameter-sip-app-11 1465 (work in progress), February 2006. 1467 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1468 Protocol (CHAP)", RFC 1994, August 1996. 1470 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 1471 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 1472 HTTP : Digest Access Authentication", RFC 2069, 1473 January 1997. 1475 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1476 RFC 2246, January 1999. 1478 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1479 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1480 March 1999. 1482 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1483 RFC 2633, June 1999. 1485 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1486 Protocol (HTTP) Digest Authentication Using Authentication 1487 and Key Agreement (AKA)", RFC 3310, September 2002. 1489 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1490 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1492 Appendix A. Change Log 1494 RFC editor: please remove this section prior to RFC publication. 1496 A.1. Changes from draft-ietf-radext-digest-auth-06 1498 o added a nonce format to avoid nonce replays by a hijacked RADIUS 1499 client 1500 o clarifications about conditions depending on IPsec availability 1501 o clarified protection space usage with different HTTP-style 1502 protocols 1503 o Mentioned Digest-Entity-Body-Hash in RADIUS Client Behavior 1504 section 1505 o Clarified server side authentication and nonce-checking sequence 1506 o added a RADIUS client configuration section for scenario 1 1507 parameters 1508 o Split Security Considerations sections into subsections to enhance 1509 readability. 1510 o adjusted Table of Attributes entry for Digest-Qop to 0+ 1511 o Split Client/Server Behavior sections into subsections to enhance 1512 readability. 1513 o adjusted Table of Attributes entry for Digest-Qop to 0+, as it is 1514 only a SHOULD in the text. 1515 o removed preferred IANA values 1516 o replaced 'without quotes' with 'without surrounding quotes' 1517 o added Message-Authenticator attribute to example packets 1518 o removed redundant sentence from Digest-Domain description in 4.17 1519 o removed more typos 1521 A.2. Changes from draft-ietf-radext-digest-auth-05 1523 o Removed interdependency between sips/https and RADIUS connection 1524 security. 1526 A.3. Changes from draft-ietf-radext-digest-auth-04 1528 o Short Diameter compatibility section 1530 A.4. Changes from draft-ietf-radext-digest-auth-03 1532 o new 'Interoperability' section, requiring support for both nonce 1533 generation modes. 1534 o removed Diameter migration path section (again) 1535 o reference to server behavior in Security Considerations section 1536 o fixed text/table mismatch regarding Digest-Domain attributes 1538 A.5. Changes from draft-ietf-radext-digest-auth-02 1540 o added Diameter migration path section (again) 1541 o various typos 1543 A.6. Changes from draft-ietf-radext-digest-auth-01 1545 o removed Diameter migration path section 1546 o Included Digest-URI and Digest-Realm in the authorization 1547 decision, not just in the digest calculation 1548 o RADIUS server must check if a RADIUS client is authorized to serve 1549 the realm mentioned in Digest-Realm 1550 o moved 'Detailed Description' sections in front of 'New RADIUS 1551 attributes' section 1552 o replaced 'IPsec or otherwise secured connection' with IPsec 1553 o changed MAY to SHOULD for Digest-Algorithm in Access-Challenge 1554 o changed type of Digest-Entity-Body-Hash to text (all other H(..) 1555 result attributes are hex and text, too) 1556 o new abstract 1557 o Terminology section changed 1558 o 'Changes' section as appendix 1560 A.7. Changes from draft-ietf-radext-digest-auth-00 1562 o SIP-AOR attribute added 1563 o clarified use of Digest-Qop 1564 o attribute overview table added 1566 A.8. Changes from draft-sterman-aaa-sip-04 1568 o clarified usage of Digest-HA1 1569 o clarified usage of Digest-Stale (is sent in an Access-Challenge 1570 now) 1571 o clarified allowed attribute usage for message types 1572 o changed attribute type to 'Text' where the corresponding Diameter 1573 AVPs have a UTF8String 1574 o added Diameter client - RADIUS server handling 1576 A.9. Changes from draft-sterman-aaa-sip-03 1578 o addressed 'auth-int' issue 1579 o New Digest-Nextnonce attribute 1580 o revised abstract, motivational section and examples 1581 o Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce 1582 attribute' 1583 o shortened SIP messages in example, removed real-world addresses 1584 and product names 1586 A.10. Changes from draft-sterman-aaa-sip-02 1588 o Relaxed restrictions for Digest-Domain, Digest-Realm, Digest- 1589 Opaque, Digest-Qop and Digest-Algorithm 1590 o Additional security considerations for Digest-Domain, Digest-Qop 1591 and Digest-Algorithm usage in Access-Accept messages 1593 A.11. Changes from draft-sterman-aaa-sip-01 1595 o Replaced Sub-attributes with flat attributes 1596 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1597 o Added how a server must treat unknown attributes. 1598 o Added a section 'Migration path to Diameter' 1599 o Added an optional attribute for support of the digest scheme 1600 described in informational [RFC3310]. 1601 o Added a mode of operation where the RADIUS server chooses the 1602 nonce. This was required for AKA [RFC3310], but can be useful for 1603 ordinary Digest Authentication when the qop directive is not used. 1604 This required the addition of several attributes. 1606 Authors' Addresses 1608 Baruch Sterman 1609 Kayote Networks 1610 P.O. Box 1373 1611 Efrat 90435 1612 Israel 1614 Email: baruch@kayote.com 1616 Daniel Sadolevsky 1617 SecureOL, Inc. 1618 Jerusalem Technology Park 1619 P.O. Box 16120 1620 Jerusalem 91160 1621 Israel 1623 Email: dscreat@dscreat.com 1625 David Schwartz 1626 Kayote Networks 1627 P.O. Box 1373 1628 Efrat 90435 1629 Israel 1631 Email: david@kayote.com 1633 David Williams 1634 Cisco Systems 1635 7025 Kit Creek Road 1636 P.O. Box 14987 1637 Research Triangle Park NC 27709 1638 USA 1640 Email: dwilli@cisco.com 1642 Wolfgang Beck 1643 Deutsche Telekom AG 1644 Am Kavalleriesand 3 1645 Darmstadt 64295 1646 Germany 1648 Email: beckw@t-systems.com 1650 Intellectual Property Statement 1652 The IETF takes no position regarding the validity or scope of any 1653 Intellectual Property Rights or other rights that might be claimed to 1654 pertain to the implementation or use of the technology described in 1655 this document or the extent to which any license under such rights 1656 might or might not be available; nor does it represent that it has 1657 made any independent effort to identify any such rights. Information 1658 on the procedures with respect to rights in RFC documents can be 1659 found in BCP 78 and BCP 79. 1661 Copies of IPR disclosures made to the IETF Secretariat and any 1662 assurances of licenses to be made available, or the result of an 1663 attempt made to obtain a general license or permission for the use of 1664 such proprietary rights by implementers or users of this 1665 specification can be obtained from the IETF on-line IPR repository at 1666 http://www.ietf.org/ipr. 1668 The IETF invites any interested party to bring to its attention any 1669 copyrights, patents or patent applications, or other proprietary 1670 rights that may cover technology that may be required to implement 1671 this standard. Please address the information to the IETF at 1672 ietf-ipr@ietf.org. 1674 Disclaimer of Validity 1676 This document and the information contained herein are provided on an 1677 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1678 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1679 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1680 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1681 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1682 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1684 Copyright Statement 1686 Copyright (C) The Internet Society (2006). This document is subject 1687 to the rights, licenses and restrictions contained in BCP 78, and 1688 except as set forth therein, the authors retain all their rights. 1690 Acknowledgment 1692 Funding for the RFC Editor function is currently provided by the 1693 Internet Society.