idnits 2.17.1 draft-ietf-radext-digest-auth-08.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 1579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1569. ** 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 36 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 (April 19, 2006) is 6553 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 959, but not defined == Missing Reference: 'Note 1' is mentioned on line 1013, but not defined == Missing Reference: 'Note 2' is mentioned on line 1015, but not defined == Missing Reference: 'Note 3' is mentioned on line 1017, but not defined == Unused Reference: 'RFC2616' is defined on line 1368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** 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 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- 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: 5 errors (**), 0 flaws (~~), 10 warnings (==), 13 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: October 21, 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 April 19, 2006 14 RADIUS Extension for Digest Authentication 15 draft-ietf-radext-digest-auth-08.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 October 21, 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 2. Detailed Description . . . . . . . . . . . . . . . . . . . . . 8 60 2.1. RADIUS Client Behavior . . . . . . . . . . . . . . . . . . 8 61 2.1.1. Credential Selection . . . . . . . . . . . . . . . . . 8 62 2.1.2. Constructing an Access-Request . . . . . . . . . . . . 8 63 2.1.3. Constructing an Authentication-Info header . . . . . . 9 64 2.1.4. Failed Authentication . . . . . . . . . . . . . . . . 10 65 2.1.5. Obtaining Nonces . . . . . . . . . . . . . . . . . . . 10 66 2.2. RADIUS Server Behavior . . . . . . . . . . . . . . . . . . 11 67 2.2.1. General Attribute Checks . . . . . . . . . . . . . . . 11 68 2.2.2. Authentication . . . . . . . . . . . . . . . . . . . . 11 69 2.2.3. Constructing the Reply . . . . . . . . . . . . . . . . 12 70 3. New RADIUS attributes . . . . . . . . . . . . . . . . . . . . 13 71 3.1. Digest-Response attribute . . . . . . . . . . . . . . . . 14 72 3.2. Digest-Realm attribute . . . . . . . . . . . . . . . . . . 14 73 3.3. Digest-Nonce attribute . . . . . . . . . . . . . . . . . . 14 74 3.4. Digest-Response-Auth attribute . . . . . . . . . . . . . . 15 75 3.5. Digest-Nextnonce attribute . . . . . . . . . . . . . . . . 15 76 3.6. Digest-Method attribute . . . . . . . . . . . . . . . . . 16 77 3.7. Digest-URI attribute . . . . . . . . . . . . . . . . . . . 16 78 3.8. Digest-Qop attribute . . . . . . . . . . . . . . . . . . . 17 79 3.9. Digest-Algorithm attribute . . . . . . . . . . . . . . . . 17 80 3.10. Digest-Entity-Body-Hash attribute . . . . . . . . . . . . 17 81 3.11. Digest-CNonce attribute . . . . . . . . . . . . . . . . . 18 82 3.12. Digest-Nonce-Count attribute . . . . . . . . . . . . . . . 18 83 3.13. Digest-Username attribute . . . . . . . . . . . . . . . . 19 84 3.14. Digest-Opaque attribute . . . . . . . . . . . . . . . . . 19 85 3.15. Digest-Auth-Param attribute . . . . . . . . . . . . . . . 20 86 3.16. Digest-AKA-Auts attribute . . . . . . . . . . . . . . . . 20 87 3.17. Digest-Domain attribute . . . . . . . . . . . . . . . . . 20 88 3.18. Digest-Stale attribute . . . . . . . . . . . . . . . . . . 21 89 3.19. Digest-HA1 attribute . . . . . . . . . . . . . . . . . . . 21 90 3.20. SIP-AOR . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 4. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 23 92 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 23 93 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 96 8.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 29 97 8.2. Confidentiality and Data Integrity . . . . . . . . . . . . 30 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 101 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 102 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 103 A.1. Changes from draft-ietf-radext-digest-auth-07 . . . . . . 32 104 A.2. Changes from draft-ietf-radext-digest-auth-06 . . . . . . 33 105 A.3. Changes from draft-ietf-radext-digest-auth-05 . . . . . . 33 106 A.4. Changes from draft-ietf-radext-digest-auth-04 . . . . . . 33 107 A.5. Changes from draft-ietf-radext-digest-auth-03 . . . . . . 33 108 A.6. Changes from draft-ietf-radext-digest-auth-02 . . . . . . 33 109 A.7. Changes from draft-ietf-radext-digest-auth-01 . . . . . . 34 110 A.8. Changes from draft-ietf-radext-digest-auth-00 . . . . . . 34 111 A.9. Changes from draft-sterman-aaa-sip-04 . . . . . . . . . . 34 112 A.10. Changes from draft-sterman-aaa-sip-03 . . . . . . . . . . 34 113 A.11. Changes from draft-sterman-aaa-sip-02 . . . . . . . . . . 35 114 A.12. Changes from draft-sterman-aaa-sip-01 . . . . . . . . . . 35 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 116 Intellectual Property and Copyright Statements . . . . . . . . . . 37 118 1. Introduction 120 1.1. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 The use of normative requirement key words in this document shall 127 apply only to RADIUS Client and RADIUS Server implementations that 128 include the features described in this document. This document 129 creates no normative requirements for existing implementations. 131 HTTP-style protocol 132 The term 'HTTP-style' denotes any protocol that uses HTTP-like 133 headers and uses HTTP digest authentication as described in 134 [RFC2617]. Examples are HTTP and the Session Initiation 135 Protocol (SIP). 136 NAS 137 Network Access Server, the RADIUS client. 138 nonce 139 An unpredictable value used to prevent replay attacks. The 140 nonce generator may use cryptographic mechanisms to produce 141 nonces it can recognize without maintaining state. 142 protection space 143 HTTP-style protocols differ in their definition of the 144 protection space. For HTTP, it is defined as the combination 145 of realm and canonical root URL of the requested resource the 146 use of which is authorized by the RADIUS server. In the case 147 of SIP, the realm string alone defines the protection space. 148 SIP UA 149 SIP User Agent, an Internet endpoint that uses the Session 150 Initiation Protocol. 151 SIP UAS 152 SIP User Agent Server, a logical entity that generates a 153 response to a SIP (Session Initiation Protocol) request. 155 1.2. Motivation 157 The HTTP Digest Authentication mechanism, defined in [RFC2617], was 158 subsequently adapted to use with SIP in [RFC2543] (obsoleted by 159 [RFC3261]). Due to the limitations and weaknesses of Digest 160 Authentication (see [RFC2617], section 4), additional authentication 161 and encryption mechanisms are defined in SIP [RFC3261], including TLS 162 [RFC2246] and S/MIME [RFC2633]. However, Digest Authentication 163 support is mandatory in SIP implementations and Digest Authentication 164 is the preferred way for a SIP UA to authenticate itself to a proxy 165 server. Digest Authentication is used in other protocols as well. 167 To simplify the provisioning of users, there is a need for support 168 this authentication mechanism within AAA protocols such as RADIUS 169 [RFC2865] and Diameter [RFC3588]. 171 This document defines an extension to the RADIUS protocol to enable 172 support of Digest Authentication, for use with SIP, HTTP, and other 173 HTTP-style protocols using this authentication method. Support for 174 Digest mechanisms such as AKA [RFC3310] is also supported. A 175 companion document [I-D.ietf-aaa-diameter-sip-app] defines support 176 for Digest Authentication within Diameter. 178 1.3. Overview 180 HTTP digest is a challenge-response protocol used to authenticate a 181 client's request to access some resource on a server. Figure 1 shows 182 a single HTTP digest transaction. 184 HTTP/SIP.. 185 +------------+ (1) +------------+ 186 | |--------->| | 187 | HTTP-style | (2) | HTTP-style | 188 | Client |<---------| server | 189 | | (3) | | 190 | |--------->| | 191 | | (4) | | 192 | |<---------| | 193 +------------+ +------------+ 195 Figure 1: digest operation without RADIUS 197 If the client sends a request without any credentials (1), the server 198 will reply with an error response (2) containing a nonce. The client 199 creates a cryptographic digest from parts of the request, from the 200 nonce it received from the server, and a shared secret. The client 201 re-transmits the request (3) to the server, but now includes the 202 digest within the packet. The server does the same digest 203 calculation as the client and compares the result with the digest it 204 received in (3). If the digest values are identical, the server 205 grants access to the resource and sends a positive response to the 206 client (4). If the digest values differ, the server sends a negative 207 response to the client (4). 209 Instead of maintaining a local user database, the server could use 210 RADIUS to access a centralized user database. However, RADIUS 211 [RFC2865] does not include support for HTTP digest authentication. 212 The RADIUS client can not use the User-Password attribute, since it 213 does not receive a password from the HTTP-style client. The CHAP- 214 Challenge and CHAP-Password attributes described in [RFC1994] are 215 also not suitable since the CHAP algorithm is not compatible with 216 HTTP digest. 218 This document defines new attributes that enable the RADIUS server to 219 perform the digest calculation defined in [RFC2617], providing 220 support for Digest Authentication as a native authentication 221 mechanism within RADIUS. 223 This document defines new attributes that enable the RADIUS server to 224 perform the digest calculation defined in [RFC2617]. 226 The nonces required by the digest algorithm are generated by the 227 RADIUS server. Generating them in the RADIUS client would save a 228 round-trip, but introduce security and operational issues. Some 229 digest algorithms -- e.g. AKA [RFC3310] -- would not work. 231 Figure 2 depicts a scenario in which the HTTP-style server 232 authenticates a request by asking a RADIUS server. Entities A and B 233 communicate using HTTP or SIP, while entities B and C communicate 234 using RADIUS. 236 HTTP/SIP RADIUS 238 +-----+ (1) +-----+ +-----+ 239 | |==========>| | (2) | | 240 | | | |---------->| | 241 | | | | (3) | | 242 | | (4) | |<----------| | 243 | |<==========| | | | 244 | | (5) | | | | 245 | |==========>| | | | 246 | A | | B | (6) | C | 247 | | | |---------->| | 248 | | | | (7) | | 249 | | | |<----------| | 250 | | (8) | | | | 251 | |<==========| | | | 252 +-----+ +-----+ +-----+ 254 ====> HTTP/SIP 255 ----> RADIUS 257 Figure 2: HTTP digest over RADIUS 259 The entities have the following roles: 261 A: HTTP client / SIP UA 263 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 264 acting also as a RADIUS NAS 266 C: RADIUS server 268 The following messages are sent in this scenario: 270 A sends B an HTTP/SIP request without an authorization header (step 271 1). B sends an Access-Request packet with the newly defined Digest- 272 Method and Digest-URI attributes but without a Digest-Nonce attribute 273 to the RADIUS server, C (step 2). C chooses a nonce and responds 274 with an Access-Challenge (step 3). This Access-Challenge contains 275 Digest attributes, from which B takes values to construct an HTTP/SIP 276 "(Proxy) Authorization required" response. B sends this response to 277 A (step 4). A resends its request with its credentials (step 5). B 278 sends an Access-Request to C (step 6). C checks the credentials and 279 replies with Access-Accept or Access-Reject (step 7). Dependent on 280 the C's result, B processes A's request or rejects it with a "(Proxy) 281 Authorization required" response (step 8). 283 2. Detailed Description 285 2.1. RADIUS Client Behavior 287 The attributes described in this document are sent in cleartext. 288 Therefore were a RADIUS client to accept secured connections (https 289 or sips) from HTTP-style clients, this could result in information 290 intentionally protected by HTTP-style clients being sent in the clear 291 during the RADIUS exchange. 293 2.1.1. Credential Selection 295 On reception of an HTTP-style request message, the RADIUS client 296 checks whether it is authorized to authenticate the request. Where 297 an HTTP-style request traverses several proxies and each of the 298 proxies requests to authenticate the HTTP-style client, the request 299 at the HTTP-style server may contain multiple credential sets. 301 The RADIUS client can use the 'realm' directive in HTTP to determine 302 which credentials are applicable. Where none of the realms are of 303 interest, the RADIUS client MUST behave as though no relevant 304 credentials were sent. In all situations the RADIUS client MUST send 305 zero or exactly one credential to the RADIUS server. The RADIUS 306 client MUST choose the credential of the (Proxy-)Authorization header 307 if the realm directive matches its locally configured realm. 309 2.1.2. Constructing an Access-Request 311 If a matching (Proxy-)Authorization header is present and contains 312 HTTP digest information, the RADIUS client checks the 'nonce' 313 parameter. 315 If the RADIUS client recognizes the nonce, it takes the header 316 directives and puts them into a RADIUS Access-Request packet. It 317 puts the 'response' directive into a Digest-Response attribute and 318 the realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username, 319 and opaque directives into the respective Digest-Realm, Digest-Nonce, 320 Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce, Digest- 321 Nonce-Count, Digest- Username, Digest-Opaque attributes. The RADIUS 322 client puts the request method into the Digest-Method attribute. 324 Due to syntactic requirements, HTTP-style protocols have to escape 325 quote characters in contents of HTTP Digest directives. When 326 translating directives into RADIUS attributes, the RADIUS client only 327 removes the surrounding quotes where present. See Section 3 for an 328 example. 330 If the qop directive's value is 'auth-int', the RADIUS client 331 calculates H(entity-body) as described in [RFC2617] 3.2.1 and puts 332 the result in a Digest-Entity-Body-Hash attribute. 334 The RADIUS client adds a Message-Authenticator attribute, defined in 335 [RFC3579] and sends the Access-Request packet to the RADIUS server. 337 The RADIUS server processes the packet and responds with an Access- 338 Accept or an Access-Reject. 340 2.1.3. Constructing an Authentication-Info header 342 After having received an Access-Accept from the RADIUS server, the 343 RADIUS client constructs an Authentication-Info header: 344 o If the Access-Accept packet contains a Digest-Response-Auth 345 attribute, the RADIUS client checks the Digest-Qop attribute: 346 * If the Digest-Qop attribute's value is 'auth' or not specified, 347 the RADIUS client puts the Digest-Response-Auth attribute's 348 content into the Authentication-Info header's 'rspauth' 349 directive of the HTTP-style response. 350 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 351 client ignores the Access-Accept packet and behaves like it had 352 received an Access-Reject packet (Digest-Response-Auth can't be 353 correct as the RADIUS server does not know the contents of the 354 HTTP-style response's body). 355 o If the Access-Accept packet contains a Digest-HA1 attribute, the 356 RADIUS client checks the 'qop' and 'algorithm' directives in the 357 Authorization header of the HTTP-style request it wants to 358 authorize: 359 * If the 'qop' directive is missing or its value is 'auth', the 360 RADIUS client ignores the Digest-HA1 attribute. It does not 361 include an Authentication-Info header into its HTTP-style 362 response. 363 * If the 'qop' directive's value is 'auth-int' and at least one 364 of the following conditions is true, the RADIUS client 365 calculates the contents of the HTTP-style response's 'rspauth' 366 directive: 367 + The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5- 368 sess'. 369 + IPsec is configured to protect traffic between RADIUS client 370 and RADIUS server with IPsec (see Section 8). 371 It creates the HTTP-style response message and calculates the 372 hash of this message's body. It uses the result and the 373 Digest-URI attribute's value of the corresponding Access- 374 Request packet to perform the H(A2) calculation. It takes the 375 Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop 376 values of the corresponding Access-Request and the Digest-HA1 377 attribute's value to finish the computation of the 'rspauth' 378 value. 380 o If the Access-Accept packet contains neither a Digest-Response- 381 Auth nor a Digest-HA1 attribute, the RADIUS client will not create 382 an Authentication-Info header for its HTTP-style response. 384 When the RADIUS server provides a Digest-Nextnonce attribute in the 385 Access-Accept packet, the RADIUS client puts the contents of this 386 attributes into a 'nextnonce' directive. Now it can send an HTTP- 387 style response. 389 2.1.4. Failed Authentication 391 If the RADIUS client did receive an HTTP-style request without a 392 (Proxy-)Authorization header matching its locally configured realm 393 value, it obtains a new nonce and sends an error response (401 or 394 407) containing a (Proxy-)Authenticate header. 396 If the RADIUS client receives an Access-Challenge packet in response 397 to an Access-Request containing a Digest-Nonce attribute, the RADIUS 398 server did not accept the nonce. If a Digest-Stale attribute is 399 present in the Access-Challenge and has a value of 'true' (without 400 surrounding quotes), the RADIUS client sends an error (401 or 407) 401 response containing WWW-/Proxy-Authenticate header with the directive 402 'stale' and the digest directives derived from the Digest-* 403 attributes. 405 If the RADIUS client receives an Access-Reject from the RADIUS 406 server, it sends an error response to the HTTP-style request it has 407 received. If the RADIUS client does not receive a response, it 408 retransmits or fails over to another RADIUS server as described in 409 [RFC2865]. 411 2.1.5. Obtaining Nonces 413 The RADIUS client has two ways to obtain nonces: it has received one 414 in a Digest-Nextnonce attribute of a previously received Access- 415 Accept packet or it asks the RADIUS server for one. To do the 416 latter, it sends an Access-Request containing a Digest-Method and a 417 Digest-URI attribute but without a Digest-Nonce attribute. It adds a 418 Message-Authenticator (see [RFC3579]) attribute to the Access-Request 419 packet. The RADIUS server chooses a nonce and responds with an 420 Access-Challenge containing a Digest-Nonce attribute. 422 The RADIUS client constructs a (Proxy-)Authenticate header using the 423 received Digest-Nonce and Digest-Realm attributes to fill the nonce 424 and realm directives. The RADIUS server can send Digest-Qop, Digest- 425 Algorithm, Digest-Domain, and Digest-Opaque attributes in the Access- 426 Challenge carrying the nonce. If these attributes are present, the 427 client MUST use them. 429 2.2. RADIUS Server Behavior 431 If the RADIUS server receives an Access-Request packet with a Digest- 432 Method and a Digest-URI attribute but without a Digest-Nonce 433 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 434 attribute and sends it in an Access-Challenge packet to the RADIUS 435 client. The RADIUS server MUST add Digest-Realm, Message- 436 Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or 437 more Digest-Qop, and MAY add Digest-Domain or Digest-Opaque 438 attributes to the Access-Challenge packet. 440 2.2.1. General Attribute Checks 442 If the RADIUS server receives an Access-Request packet containing a 443 Digest-Response attribute, it looks for the following attributes: 444 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, 445 Digest-Algorithm, and Digest-Username. Depending on the content of 446 Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- 447 Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and 448 [RFC3310] for details. If the Digest-Algorithm attribute is missing, 449 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque 450 attribute along with the nonce, the Access-Request MUST have a 451 matching Digest-Opaque attribute. 453 If mandatory attributes are missing, it MUST respond with an Access- 454 Reject packet. 456 The RADIUS server removes '\' characters that escape quote characters 457 from the text values it has received in the Digest-* attributes. 459 If the mandatory attributes are present, the RADIUS server MUST check 460 if the RADIUS client is authorized to serve users of the realm 461 mentioned in the Digest-Realm attribute. If the RADIUS client is not 462 authorized, the RADIUS server MUST send an Access-Reject. The RADIUS 463 server SHOULD log the event so as to notify the operator, and MAY 464 take additional action such as sending an Access-Reject in response 465 to all future requests from this client, until this behavior is reset 466 by management action. 468 The RADIUS server determines the age of the nonce in Digest-Nonce by 469 using an embedded time-stamp, or by looking it up in a local table. 470 The RADIUS server MUST check the integrity of the nonce, if it embeds 471 the time-stamp in the nonce. Section 2.2.2 describes how the server 472 handles old nonces. 474 2.2.2. Authentication 476 If the Access-Request message has passed the checks described above, 477 the RADIUS server calculates the digest response as described in 478 [RFC2617]. To look up the password, the RADIUS server uses the 479 RADIUS User-Name attribute. The RADIUS server MUST check if the user 480 identified by the User-Name attribute 481 o is authorized to access the protection space 482 o is authorized to use the URI included in the SIP-AOR attribute, if 483 this attribute is present. 484 If any of those checks fails, the RADIUS server MUST send an Access- 485 Reject. 487 Correlation between User-Name and SIP-AOR AVP values is required just 488 to avoid that any user can register or misuse a SIP-AOR allocated to 489 a different user. 491 All values required for the digest calculation are taken from the 492 Digest attributes described in this document. If the calculated 493 digest response equals the value received in the Digest-Response 494 attribute, the authentication was successful. 496 If the response values match, but the RADIUS server considers the 497 nonce in the Digest-Nonce attribute as too old, it sends an Access- 498 Challenge packet containing a new nonce and a Digest-Stale attribute 499 with a value of 'true' (without surrounding quotes). 501 If the response values don't match, the RADIUS server responds with 502 an Access-Reject. 504 2.2.3. Constructing the Reply 506 If the authentication was successful, the RADIUS server adds an 507 attribute to the Access-Accept packet which can be used by the RADIUS 508 client to construct an Authentication-Info header: 509 o If the Digest-Qop attribute's value is 'auth' or unspecified, the 510 RADIUS server SHOULD put a Digest-Response-Auth attribute into the 511 Access-Accept packet 512 o If the Digest-Qop attribute's value is 'auth-int' and at least one 513 of the following conditions is true, the RADIUS server SHOULD put 514 a Digest-HA1 attribute into the Access-Accept packet: 515 * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- 516 MD5-sess'. 517 * IPsec is configured to protect traffic between RADIUS client 518 and RADIUS server with IPsec (see Section 8). 519 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be 520 sent. 522 RADIUS servers MAY construct a Digest-Nextnonce attribute and add it 523 to the Access-Accept packet. This is useful to limit the lifetime of 524 a nonce and to save a round-trip in future requests (see nextnonce 525 discussion in [RFC2617], section 3.2.3). The RADIUS server adds a 526 Message-Authenticator attribute (see [RFC3579]) and sends the Access- 527 Accept packet to the RADIUS client. 529 If the RADIUS server does not accept the nonce received in an Access- 530 Request packet but authentication was successful, the RADIUS server 531 MUST send an Access-Challenge packet containing a Digest-Stale 532 attribute set to 'true' (without surrounding quotes). The RADIUS 533 server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce, 534 Digest-Realm, SHOULD add Digest-Algorithm, one or more Digest-Qop and 535 MAY add Digest-Domain, Digest-Opaque attributes to the Access- 536 Challenge packet. 538 3. New RADIUS attributes 540 If not stated otherwise, the attributes have the following format: 542 0 1 2 543 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Type | Length | Text ... 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Quote characters in Digest-* attributes representing HTTP-style 549 directives with a quoted-string syntax are escaped. The surrounding 550 quotes are removed. They are syntactical delimiters which are 551 redundant in RADIUS. For example, the directive 553 realm="the \"example\" value" 555 is represented as: 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Digest-Realm | 23 | the \"example\" value | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 3.1. Digest-Response attribute 563 Description 564 If this attribute is present in an Access-Request message, a 565 RADIUS server implementing this specification MUST treat the 566 Access-Request as a request for Digest Authentication. When a 567 RADIUS client receives a (Proxy-)Authorization header, it puts 568 the request-digest value into a Digest-Response attribute. 569 This attribute (which enables the user to prove possession of 570 the password) MUST only be used in Access-Requests. 571 Type 572 [IANA TBD] for Digest-Response. 573 Length 574 >= 3 575 Text 576 When using HTTP digest, the text field is 32 octets long and 577 contains a hexadecimal representation of 16 octet digest value 578 as it was calculated by the authenticated client. Other digest 579 algorithms MAY define different digest lengths. The text field 580 MUST be copied from request-digest of digest-response 581 ([RFC2617]) without surrounding quotes. 583 3.2. Digest-Realm attribute 585 Description 586 This attribute describes a protection space component of the 587 RADIUS server. HTTP-style protocols differ in their definition 588 of the protection space. See [RFC2617] 1.2 for details. It 589 MUST only be used in Access-Request and Access-Challenge 590 packets. 591 Type 592 [IANA TBD] for Digest-Realm 593 Length 594 >=3 595 Text 596 In Access-Requests, the RADIUS client takes the value of the 597 realm directive (realm-value according to [RFC2617]) without 598 surrounding quotes from the HTTP-style request it wants to 599 authenticate. In Access-Challenge packets, the RADIUS server 600 puts the expected realm value into this attribute. 602 3.3. Digest-Nonce attribute 604 Description 605 This attribute holds a nonce to be used in the HTTP Digest 606 calculation. If the Access-Request had a Digest-Method and a 607 Digest-URI but no Digest-Nonce attribute, the RADIUS server 608 MUST put a Digest-Nonce attribute into its Access-Challenge 609 packet. This attribute MUST only be used in Access-Request and 610 Access-Challenge packets. 611 Type 612 [IANA TBD] for Digest-Nonce 613 Length 614 >=3 615 Text 616 In Access-Requests, the RADIUS client takes the value of the 617 nonce directive (nonce-value in [RFC2617]) without surrounding 618 quotes from the HTTP-style request it wants to authenticate. 619 In Access-Challenge packets, the attribute contains the nonce 620 selected by the RADIUS server. 622 3.4. Digest-Response-Auth attribute 624 Description 625 This attribute enables the RADIUS server to prove possession of 626 the password. If the previously received Digest-Qop attribute 627 was 'auth-int' (without surrounding quotes), the RADIUS server 628 MUST send a Digest-HA1 attribute instead of a Digest-Response- 629 Auth attribute. The Digest-Response-Auth attribute MUST only 630 be used in Access-Accept packets. The RADIUS client puts the 631 attribute value without surrounding quotes into the rspauth 632 directive of the Authentication-Info header. 633 Type 634 [IANA TBD] for Digest-Response-Auth. 635 Length 636 >= 3 637 Text 638 The RADIUS server calculates a digest according to section 639 3.2.3 of [RFC2617] and copies the result into this attribute. 640 Other digest algorithms than the one defined in [RFC2617] MAY 641 define digest lengths other than 32. 643 3.5. Digest-Nextnonce attribute 645 This attribute holds a nonce to be used in the HTTP Digest 646 calculation. 648 Description 649 The RADIUS server MAY put a Digest-Nextnonce attribute into an 650 Access-Accept packet. If this attribute is present, the RADIUS 651 client MUST put the contents of this attribute into the 652 nextnonce directive of an Authentication-Info header in its 653 HTTP-style response. This attribute MUST only be used in 654 Access-Accept packets. 655 Type 656 [IANA TBD] for Digest-Nextnonce 657 Length 658 >=3 659 Text 660 It is recommended that this text be base64 or hexadecimal data. 662 3.6. Digest-Method attribute 664 Description 665 This attribute holds the method value to be used in the HTTP 666 Digest calculation. This attribute MUST only be used in 667 Access-Request packets. 668 Type 669 [IANA TBD] for Digest-Method 670 Length 671 >=3 672 Text 673 In Access-Requests, the RADIUS client takes the value of the 674 request method from the HTTP-style request it wants to 675 authenticate. 677 3.7. Digest-URI attribute 679 Description 680 This attribute is used to transport the contents of the digest- 681 uri directive or the URI of the HTTP-style request. It MUST 682 only be used in Access-Request packets. 683 Type 684 [IANA TBD] for Digest-URI 685 Length 686 >=3 687 Text 688 If the HTTP-style request has an Authorization header, the 689 RADIUS client puts the value of the "uri" directive in the 690 (known as "digest-uri-value" in section 3.2.2 of [RFC2617]) 691 without surrounding quotes into this attribute. If there is no 692 Authorization header, the RADIUS client takes the value of the 693 request URI from the HTTP-style request it wants to 694 authenticate. 696 3.8. Digest-Qop attribute 698 Description 699 This attribute holds the Quality of Protection parameter that 700 influences the HTTP Digest calculation. This attribute MUST 701 only be used in Access-Request and Access-Challenge packets. A 702 RADIUS client SHOULD insert one of the Digest-Qop attributes it 703 has received in a previous Access-Challenge packet. RADIUS 704 servers SHOULD insert at least one Digest-Qop attribute in an 705 Access-Challenge packet. Digest-Qop is optional in order to 706 preserve backward compatibility with a minimal implementation 707 of [RFC2069]. 708 Type 709 [IANA TBD] for Digest-Qop 710 Length 711 >=3 712 Text 713 In Access-Requests, the RADIUS client takes the value of the 714 qop directive (qop-value as described in [RFC2617]) from the 715 HTTP-style request it wants to authenticate. In Access- 716 Challenge packets, the RADIUS server puts a desired qop-value 717 into this attribute. If the RADIUS server supports more than 718 one "quality of protection" value, it puts each qop-value into 719 a separate Digest-Qop attribute. 721 3.9. Digest-Algorithm attribute 723 Description 724 This attribute holds the algorithm parameter that influences 725 the HTTP Digest calculation. It MUST only be used in Access- 726 Request and Access-Challenge packets. If this attribute is 727 missing, MD5 is assumed. 728 Type 729 [IANA TBD] for Digest-Algorithm 730 Length 731 >=3 732 Text 733 In Access-Requests, the RADIUS client takes the value of the 734 algorithm directive (as described in [RFC2617], section 3.2.1) 735 from the HTTP-style request it wants to authenticate. In 736 Access-Challenge packets, the RADIUS server SHOULD put the 737 desired algorithm into this attribute. 739 3.10. Digest-Entity-Body-Hash attribute 740 Description 741 When using the qop level 'auth-int', a hash of the HTTP-style 742 message body's contents is required for digest calculation. 743 Instead of sending the complete body of the message, only its 744 hash value is sent. This hash value can be used directly in 745 the digest calculation. 746 The clarifications described in section 22.4 of [RFC2617] about 747 the hash of empty entity bodies apply to the Digest-Entity- 748 Body-Hash attribute. This attribute MUST only be sent in 749 Access-Request packets. 750 Type 751 [IANA TBD] for Digest-Entity-Body-Hash 752 Length 753 >=3 754 Text 755 The attribute holds the hexadecimal representation of H(entity- 756 body). This hash is required by certain authentication 757 mechanisms, such as HTTP Digest with quality of protection set 758 to "auth-int". RADIUS clients MUST use this attribute to 759 transport the hash of the entity body when HTTP Digest is the 760 authentication mechanism and the RADIUS server requires to 761 verify the integrity of the entity body (e.g., qop parameter 762 set to "auth-int"). Extensions to this document may define 763 support for authentication mechanisms other than HTTP Digest. 765 3.11. Digest-CNonce attribute 767 Description 768 This attribute holds the client nonce parameter that is used in 769 the HTTP Digest calculation. It MUST only be used in Access- 770 Request packets. 771 Type 772 [IANA TBD] for Digest-CNonce 773 Length 774 >=3 775 Text 776 This attribute includes the value of the cnonce-value [RFC2617] 777 without surrounding quotes, taken from the HTTP-style request. 779 3.12. Digest-Nonce-Count attribute 781 Description 782 This attribute includes the nonce count parameter that is used 783 to detect replay attacks. The attribute MUST only be used in 784 Access-Request packets. 786 Type 787 [IANA TBD] for Digest-Nonce-Count 788 Length 789 10 790 Text 791 In Access-Requests, the RADIUS client takes the value of the nc 792 directive (nc-value according to [RFC2617]) without surrounding 793 quotes from the HTTP-style request it wants to authenticate. 795 3.13. Digest-Username attribute 797 Description 798 This attribute holds the user name used in the HTTP digest 799 calculation. The RADIUS server MUST use this attribute only 800 for the purposes of calculating the digest. In order to 801 determine the appropriate user credentials, the RADIUS server 802 MUST use the User-Name (1) attribute, and MUST NOT use the 803 Digest-Username attribute. This attribute MUST only be used in 804 Access-Request packets. 805 Type 806 [IANA TBD] for Digest-Username 807 Length 808 >= 3 809 Text 810 In Access-Requests, the RADIUS client takes the value of the 811 username directive (username-value according to [RFC2617]) 812 without surrounding quotes from the HTTP-style request it wants 813 to authenticate. 815 3.14. Digest-Opaque attribute 817 Description 818 This attribute holds the opaque parameter that is passed to the 819 HTTP-style client. The HTTP-style client will pass this value 820 back to the server (i.e. the RADIUS client) without 821 modification. This attribute MUST only be used in Access- 822 Request and Access-Challenge packets. 823 Type 824 [IANA TBD] for Digest-Opaque 825 Length 826 >=3 827 Text 828 In Access-Requests, the RADIUS client takes the value of the 829 opaque directive (opaque-value according to [RFC2617]) without 830 surrounding quotes from the HTTP-style request it wants to 831 authenticate and puts it into this attribute. In Access- 832 Challenge packets, the RADIUS server MAY include this 833 attribute. 835 3.15. Digest-Auth-Param attribute 837 Description 838 This attribute is a placeholder for future extensions and 839 corresponds to the "auth-param" parameter defined in section 840 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism 841 whereby the RADIUS client and RADIUS server can exchange auth- 842 param extension parameters contained within Digest headers that 843 are not understood by the RADIUS client and for which there are 844 no corresponding stand-alone attributes. 845 Unlike the previously listed Digest-* attributes, the Digest- 846 Auth-Param contains not only the value, but also the parameter 847 name, since the parameter name is unknown to the RADIUS client. 848 If the Digest header contains several unknown parameters, then 849 the RADIUS implementation MUST repeat this attribute and each 850 instance MUST contain one different unknown Digest parameter/ 851 value combination. This attribute MUST ONLY be used in Access- 852 Request, Access-Challenge, or Access-Accept packets. 853 Type 854 [IANA TBD] for Digest-Auth-Param 855 Length 856 >=3 857 Text 858 The text consists of the whole parameter, including its name 859 and the equal ('=') sign and quotes. 861 3.16. Digest-AKA-Auts attribute 863 Description 864 This attribute holds the auts parameter that is used in the 865 Digest AKA ([RFC3310]) calculation. It is only used if the 866 algorithm of the digest-response denotes a version of AKA 867 digest [RFC3310]. This attribute MUST only be used in Access- 868 Request packets. 869 Type 870 [IANA TBD] for Digest-AKA-Auts 871 Length 872 >=3 873 Text 874 In Access-Requests, the RADIUS client takes the value of the 875 auts directive (auts-param according to section 3.4 of 876 [RFC3310]) without surrounding quotes from the HTTP-style 877 request it wants to authenticate. 879 3.17. Digest-Domain attribute 880 Description 881 When a RADIUS client has asked for a nonce, the RADIUS server 882 MAY send one or more Digest-Domain attributes in its Access- 883 Challenge packet. The RADIUS client puts them into the quoted, 884 space-separated list of URIs of the 'domain' directive of a 885 WWW-Authenticate header. Together with Digest-Realm, the URIs 886 in the list define the protection space (see [RFC2617], section 887 3.2.1) for some HTTP-style protocols. This attribute MUST only 888 be used in Access-Challenge packets. 889 Type 890 [IANA TBD] for Digest-Domain 891 Length 892 3 893 Text 894 This attribute consists of a single URI, that defines a 895 protection space component. 897 3.18. Digest-Stale attribute 899 Description 900 This attribute is sent by a RADIUS server in order to notify 901 the RADIUS client whether it has accepted a nonce. If the 902 nonce presented by the RADIUS client was stale, the value is 903 'true' and is 'false' otherwise. The RADIUS client puts the 904 content of this attribute into a 'stale' directive of the WWW- 905 Authenticate header in the HTTP-style response to the request 906 it wants to authenticate. The attribute MUST only be used in 907 Access-Challenge packets. 908 Type 909 [IANA TBD] for Digest-Stale 910 Length 911 3 912 Text 913 The attribute has either the value 'true' or 'false' (both 914 values without surrounding quotes). 916 3.19. Digest-HA1 attribute 918 Description 919 This attribute is used to allow the generation of an 920 Authentication-Info header, even if the HTTP-style response's 921 body is required for the calculation of the rspauth value. It 922 SHOULD be used in Access-Accept packets if the required quality 923 of protection ('qop') is 'auth-int'. 925 This attribute MUST NOT be sent if the qop parameter was not 926 specified or has a value of 'auth' (in this case, use Digest- 927 Response-Auth instead). 928 The Digest-HA1 attribute MUST only be sent by the RADIUS server 929 or processed by the RADIUS client if at least one of the 930 following conditions is true: 931 + The Digest-Algorithm attribute's value is 'MD5-sess' or 932 'AKAv1-MD5-sess'. 933 + IPsec is configured to protect traffic between RADIUS client 934 and RADIUS server with IPsec (see Section 8). 935 This attribute MUST only be used in Access-Accept packets. 936 Type 937 [IANA TBD] for Digest-HA1 938 Length 939 >= 3 940 Text 941 This attribute contains the hexadecimal representation of H(A1) 942 as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2. 944 3.20. SIP-AOR 946 Description 947 This attribute is used for the authorization of SIP messages. 948 The SIP-AOR attribute identifies the URI the use of which must 949 be authenticated and authorized. The RADIUS server uses this 950 attribute to authorize the processing of the SIP request. The 951 SIP-AOR can be derived from, e.g., the To header field in a SIP 952 REGISTER request (user under registration), or the From header 953 field in other SIP requests. However, the exact mapping of 954 this attribute to SIP can change due to new developments in the 955 protocol. This attribute MUST only be used when the RADIUS 956 client wants to authorize SIP users and MUST only be used in 957 Access-Request packets. 958 Type 959 [IANA TBD] for SIP-AOR 960 Length 961 >=3 962 Text 963 The syntax of this attribute corresponds either to a SIP URI 964 (with the format defined in [RFC3261] or a TEL URI (with the 965 format defined in [RFC3966]). 966 The SIP-AOR attribute holds the complete URI, including 967 parameters and other parts. It is up to the RADIUS server what 968 components of the URI are regarded in the authorization 969 decision. 971 4. Diameter Compatibility 973 This document defines support for Digest Authentication in RADIUS. A 974 companion document "Diameter Session Initiation Protocol (SIP) 975 Application" [I-D.ietf-aaa-diameter-sip-app] defines support for 976 Digest Authentication in Diameter, and addresses compatibility issues 977 between RADIUS and Diameter. 979 5. Table of Attributes 981 The following table provides a guide to which attributes may be found 982 in which kinds of packets, and in what quantity. 984 Req Accept Reject Challenge # Attribute 985 1 0 0 0 1 User-Name 986 1 1 1 1 80 Message-Authenticator 987 0-1 0 0 0 TBD Digest-Response 988 0-1 0 0 1 TBD Digest-Realm 989 0-1 0 0 1 TBD Digest-Nonce 990 0 0-1 0 0 TBD Digest-Response-Auth 991 (see Note 1, 2) 992 0 0-1 0 0 TBD Digest-Nextnonce 993 0-1 0 0 0 TBD Digest-Method 994 0-1 0 0 0 TBD Digest-URI 995 0-1 0 0 0+ TBD Digest-Qop 996 0-1 0 0 0-1 TBD Digest-Algorithm (see 997 Note 3) 998 0-1 0 0 0 TBD Digest-Entity-Body-Hash 999 0-1 0 0 0 TBD Digest-CNonce 1000 0-1 0 0 0 TBD Digest-Nonce-Count 1001 0-1 0 0 0 TBD Digest-Username 1002 0-1 0 0 0-1 TBD Digest-Opaque 1003 0+ 0+ 0 0+ TBD Digest-Auth-Param 1004 0-1 0 0 0 TBD Digest-AKA-Auts 1005 0 0 0 0+ TBD Digest-Domain 1006 0 0 0 0-1 TBD Digest-Stale 1007 0 0-1 0 0 TBD Digest-HA1 (see Note 1, 1008 2) 1009 0-1 0 0 0 TBD SIP-AOR 1011 Table 1 1013 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if 1014 Digest-Qop is 'auth-int'. 1015 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if 1016 Digest-Qop is 'auth'. 1017 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed 1019 6. Examples 1021 This is an example sniffed from the traffic between a softphone (A), 1022 a Proxy Server (B) and example.com RADIUS server (C). The 1023 communication between the Proxy Server and a SIP PSTN gateway is 1024 omitted for brevity. The SIP messages are not shown completely. 1026 A->B 1028 INVITE sip:97226491335@example.com SIP/2.0 1029 From: 1030 To: 1032 B->A 1034 SIP/2.0 100 Trying 1036 B->C 1038 Code = 1 (Access-Request) 1039 Attributes: 1040 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1041 NAS-Port-Type = 5 (Virtual) 1042 User-Name = "12345678" 1043 Digest-Method = "INVITE" 1044 Digest-URI ="sip:97226491335@example.com" 1045 Message-Authenticator = 1046 08 af 7e 01 b6 8d 74 c3 a4 3c 33 e1 56 2a 80 43 1048 C->B 1050 Code = 11 (Access-Challenge) 1051 Attributes: 1053 Digest-Nonce = "3bada1a0" 1054 Digest-Realm = "example.com" 1055 Digest-Qop = "auth" 1056 Digest-Algorithm = "MD5" 1057 Message-Authenticator = 1058 f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40 1060 B->A 1062 SIP/2.0 407 Proxy Authentication Required 1063 Proxy-Authenticate: Digest realm="example.com" 1064 ,nonce="3bada1a0",qop=auth,algorithm=MD5 1065 Content-Length: 0 1067 A->B 1069 ACK sip:97226491335@example.com SIP/2.0 1071 A->B 1073 INVITE sip:97226491335@example.com SIP/2.0 1074 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1075 ,realm="example.com" 1076 ,response="f3ce87e6984557cd0fecc26f3c5e97a4" 1077 ,uri="sip:97226491335@example.com",username="12345678" 1078 ,qop=auth,algorithm=MD5 1079 From: 1080 To: 1082 B->C 1084 Code = 1 (Access-Request) 1085 Attributes: 1086 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1087 NAS-Port-Type = 5 (Virtual) 1088 User-Name = "12345678" 1089 Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" 1090 Digest-Realm = "example.com" 1091 Digest-Nonce = "3bada1a0" 1092 Digest-Method = "INVITE" 1093 Digest-URI = "sip:97226491335@example.com" 1094 Digest-Qop = "auth" 1095 Digest-Algorithm = "md5" 1096 Digest-Username = "12345678" 1097 SIP-AOR = "sip:12345678@example.com" 1098 Message-Authenticator = 1099 ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff 1101 C->B 1103 Code = 2 (Access-Accept) 1104 Attributes: 1105 Digest-Response-Auth = 1106 "6303c41b0e2c3e524e413cafe8cce954" 1107 Message-Authenticator = 1108 75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1 1110 B->A 1112 SIP/2.0 180 Ringing 1114 B->A 1116 SIP/2.0 200 OK 1118 A->B 1120 ACK sip:97226491335@example.com SIP/2.0 1122 A second example shows the traffic between a web browser (A), web 1123 server (B) and a RADIUS server (C). 1125 A->B 1127 GET /index.html HTTP/1.1 1129 B->C 1131 Code = 1 (Access-Request) 1132 Attributes: 1133 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1134 NAS-Port-Type = 5 (Virtual) 1135 Digest-Method = "GET" 1136 Digest-URI ="/index.html" 1137 Message-Authenticator = 1138 34 a6 26 46 f3 81 f9 b4 97 c0 dd 9d 11 8f ca c7 1140 C->B 1142 Code = 11 (Access-Challenge) 1143 Attributes: 1144 Digest-Nonce = "a3086ac8" 1145 Digest-Realm = "example.com" 1146 Digest-Qop = "auth" 1147 Digest-Algorithm = "MD5" 1148 Message-Authenticator = 1149 f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40 1151 B->A 1153 HTTP/1.1 401 Authentication Required 1154 WWW-Authenticate: Digest realm="example.com", 1155 nonce="a3086ac8",qop=auth,algorithm=MD5 1156 Content-Length: 0 1158 A->B 1160 GET /index.html HTTP/1.1 1161 Authorization: Digest algorithm=MD5,nonce="a3086ac8" 1162 ,realm="example.com" 1163 ,response="f052b68058b2987aba493857ae1ab002" 1164 ,uri="/index.html",username="12345678" 1165 ,qop=auth,algorithm=MD5 1167 B->C 1169 Code = 1 (Access-Request) 1170 Attributes: 1171 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1172 NAS-Port-Type = 5 (Virtual) 1173 User-Name = "12345678" 1174 Digest-Response = "f052b68058b2987aba493857ae1ab002" 1175 Digest-Realm = "example.com" 1176 Digest-Nonce = "a3086ac8" 1177 Digest-Method = "GET" 1178 Digest-URI = "/index.html" 1179 Digest-Username = "12345678" 1180 Digest-Qop = "auth" 1181 Digest-Algorithm = "MD5" 1182 Message-Authenticator = 1183 06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b 1185 C->B 1187 Code = 2 (Access-Accept) 1188 Attributes: 1189 Digest-Response-Auth = 1190 "e644aa513effbfe1caff67103ff6433c" 1191 Message-Authenticator = 1192 7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7 1194 B->A 1196 HTTP/1.1 200 OK 1197 ... 1199 1200 ... 1202 7. IANA Considerations 1204 This document serves as IANA registration request for a number of 1205 values from the RADIUS attribute type number space: 1207 +-------------------------+------------------------+ 1208 | placeholder | value assigned by IANA | 1209 +-------------------------+------------------------+ 1210 | Digest-Response | TBD | 1211 | Digest-Realm | TBD | 1212 | Digest-Nonce | TBD | 1213 | Digest-Nextnonce | TBD | 1214 | Digest-Response-Auth | TBD | 1215 | Digest-Method | TBD | 1216 | Digest-URI | TBD | 1217 | Digest-Qop | TBD | 1218 | Digest-Algorithm | TBD | 1219 | Digest-Entity-Body-Hash | TBD | 1220 | Digest-CNonce | TBD | 1221 | Digest-Nonce-Count | TBD | 1222 | Digest-Username | TBD | 1223 | Digest-Opaque | TBD | 1224 | Digest-Auth-Param | TBD | 1225 | Digest-AKA-Auts | TBD | 1226 | Digest-Domain | TBD | 1227 | Digest-Stale | TBD | 1228 | Digest-HA1 | TBD | 1229 | SIP-AOR | TBD | 1230 +-------------------------+------------------------+ 1232 Table 2 1234 8. Security Considerations 1236 The RADIUS extensions described in this document enable RADIUS to 1237 transport the data that required to perform a digest calculation. As 1238 a result, RADIUS inherits the vulnerabilities of HTTP Digest (see 1239 [RFC2617], section 4) in addition to RADIUS security vulnerabilities 1240 described in [RFC2865] Section 8 and [RFC3579] Section 4. 1242 An attacker compromising a RADIUS client or proxy can carry out man- 1243 in-the-middle attacks even if the paths between A, B and B, C 1244 (Figure 2) have been secured with TLS or IPsec. 1246 The RADIUS server MUST check the Digest-Realm attribute it has 1247 received from a client. If the RADIUS client is not authorized to 1248 serve HTTP-style clients of that realm, it might be compromised. 1250 8.1. Denial of Service 1252 RADIUS clients implementing the extension described in this document 1253 may authenticate HTTP-style requests received over the Internet. As 1254 compared with use of RADIUS to authenticate link layer network 1255 access, an attacker may find it easier to cover their tracks in such 1256 a scenario. 1258 An attacker can attempt a denial of service attack on one or more 1259 RADIUS servers by sending a large number of HTTP-style requests. To 1260 make simple denial of service attacks more difficult, the nonce 1261 issuer (RADIUS client or server) MUST check if it has generated the 1262 nonce received from an HTTP-style client. This SHOULD be done 1263 statelessly. For example, a nonce could consist of a 1264 cryptographically random part and some kind of signature provided by 1265 the RADIUS client, as described in [RFC2617], section 3.2.1. 1267 8.2. Confidentiality and Data Integrity 1269 The attributes described in this document are sent in cleartext. 1270 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm 1271 attributes in Access-Challenge messages. A man in the middle can 1272 modify or remove those attributes in a bidding down attack, causing 1273 the RADIUS client to use a weaker authentication scheme than 1274 intended. 1276 The Message-Authenticator attribute, described in [RFC3579] section 1277 3.2 MUST be included in Access-Request, Access-Challenge, Access- 1278 Reject and Access-Accept messages that contain attributes described 1279 in this specification. 1281 The Digest-HA1 attribute contains no random components if the 1282 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1283 attacks easier and enables replay attacks. 1285 Some parameter combinations require the protection of RADIUS packets 1286 against eavesdropping and tampering. Implementations SHOULD try to 1287 determine automatically whether IPsec is configured to protect 1288 traffic between the RADIUS client and the RADIUS server. If this is 1289 not possible, the implementation checks a configuration parameter 1290 telling it whether IPsec will protect RADIUS traffic. The default 1291 value of this configuration parameter tells the implementation that 1292 RADIUS packet will not be protected. 1294 HTTP-style clients can use TLS with server side certificates together 1295 with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, 1296 too. TLS or IPsec secure the connection while Digest Authentication 1297 authenticates the user. The RADIUS transaction can be regarded as 1298 one leg on the path between the HTTP-style client and the HTTP-style 1299 server. To prevent RADIUS from representing the weak link, a RADIUS 1300 client receiving an HTTP-style request via TLS or IPsec could use an 1301 equally secure connection to the RADIUS server. There are several 1302 ways to achieve this, for example: 1303 o the RADIUS client may reject HTTP-style requests received over TLS 1304 or IPsec 1305 o the RADIUS client require that traffic be sent and received over 1306 IPsec. 1307 RADIUS over IPsec, if used, MUST conform to the requirements 1308 described in [RFC3579] section 4.2. 1310 9. Acknowledgments 1312 We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or 1313 providing comments and experimental implementation. 1315 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1316 Arkko, Avi Lior and Jun Wang. 1318 10. References 1320 10.1. Normative References 1322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1323 Requirement Levels", BCP 14, RFC 2119, March 1997. 1325 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1326 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1327 Authentication: Basic and Digest Access Authentication", 1328 RFC 2617, June 1999. 1330 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1331 "Remote Authentication Dial In User Service (RADIUS)", 1332 RFC 2865, June 2000. 1334 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1335 A., Peterson, J., Sparks, R., Handley, M., and E. 1336 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1337 June 2002. 1339 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1340 Dial In User Service) Support For Extensible 1341 Authentication Protocol (EAP)", RFC 3579, September 2003. 1343 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1344 RFC 3966, December 2004. 1346 10.2. Informative References 1348 [I-D.ietf-aaa-diameter-sip-app] 1349 Garcia-Martin, M., "Diameter Session Initiation Protocol 1350 (SIP) Application", draft-ietf-aaa-diameter-sip-app-11 1351 (work in progress), February 2006. 1353 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1354 Protocol (CHAP)", RFC 1994, August 1996. 1356 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 1357 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 1358 HTTP : Digest Access Authentication", RFC 2069, 1359 January 1997. 1361 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1362 RFC 2246, January 1999. 1364 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1365 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1366 March 1999. 1368 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1369 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1370 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1372 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1373 RFC 2633, June 1999. 1375 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1376 Protocol (HTTP) Digest Authentication Using Authentication 1377 and Key Agreement (AKA)", RFC 3310, September 2002. 1379 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1380 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1382 Appendix A. Change Log 1384 RFC editor: please remove this section prior to RFC publication. 1386 A.1. Changes from draft-ietf-radext-digest-auth-07 1388 o removed client nonce generation mode 1389 o clarified quoting issues 1390 o clarified protection space issues 1391 o fixed examples 1392 o some nits 1394 A.2. Changes from draft-ietf-radext-digest-auth-06 1396 o added a nonce format to avoid nonce replays by a hijacked RADIUS 1397 client 1398 o clarifications about conditions depending on IPsec availability 1399 o clarified protection space usage with different HTTP-style 1400 protocols 1401 o Mentioned Digest-Entity-Body-Hash in RADIUS Client Behavior 1402 section 1403 o Clarified server side authentication and nonce-checking sequence 1404 o added a RADIUS client configuration section for scenario 1 1405 parameters 1406 o Split Security Considerations sections into subsections to enhance 1407 readability. 1408 o adjusted Table of Attributes entry for Digest-Qop to 0+ 1409 o Split Client/Server Behavior sections into subsections to enhance 1410 readability. 1411 o adjusted Table of Attributes entry for Digest-Qop to 0+, as it is 1412 only a SHOULD in the text. 1413 o removed preferred IANA values 1414 o replaced 'without quotes' with 'without surrounding quotes' 1415 o added Message-Authenticator attribute to example packets 1416 o removed redundant sentence from Digest-Domain description in 4.17 1417 o removed more typos 1419 A.3. Changes from draft-ietf-radext-digest-auth-05 1421 o Removed interdependency between sips/https and RADIUS connection 1422 security. 1424 A.4. Changes from draft-ietf-radext-digest-auth-04 1426 o Short Diameter compatibility section 1428 A.5. Changes from draft-ietf-radext-digest-auth-03 1430 o new 'Interoperability' section, requiring support for both nonce 1431 generation modes. 1432 o removed Diameter migration path section (again) 1433 o reference to server behavior in Security Considerations section 1434 o fixed text/table mismatch regarding Digest-Domain attributes 1436 A.6. Changes from draft-ietf-radext-digest-auth-02 1437 o added Diameter migration path section (again) 1438 o various typos 1440 A.7. Changes from draft-ietf-radext-digest-auth-01 1442 o removed Diameter migration path section 1443 o Included Digest-URI and Digest-Realm in the authorization 1444 decision, not just in the digest calculation 1445 o RADIUS server must check if a RADIUS client is authorized to serve 1446 the realm mentioned in Digest-Realm 1447 o moved 'Detailed Description' sections in front of 'New RADIUS 1448 attributes' section 1449 o replaced 'IPsec or otherwise secured connection' with IPsec 1450 o changed MAY to SHOULD for Digest-Algorithm in Access-Challenge 1451 o changed type of Digest-Entity-Body-Hash to text (all other H(..) 1452 result attributes are hex and text, too) 1453 o new abstract 1454 o Terminology section changed 1455 o 'Changes' section as appendix 1457 A.8. Changes from draft-ietf-radext-digest-auth-00 1459 o SIP-AOR attribute added 1460 o clarified use of Digest-Qop 1461 o attribute overview table added 1463 A.9. Changes from draft-sterman-aaa-sip-04 1465 o clarified usage of Digest-HA1 1466 o clarified usage of Digest-Stale (is sent in an Access-Challenge 1467 now) 1468 o clarified allowed attribute usage for message types 1469 o changed attribute type to 'Text' where the corresponding Diameter 1470 AVPs have a UTF8String 1471 o added Diameter client - RADIUS server handling 1473 A.10. Changes from draft-sterman-aaa-sip-03 1475 o addressed 'auth-int' issue 1476 o New Digest-Nextnonce attribute 1477 o revised abstract, motivational section and examples 1478 o Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce 1479 attribute' 1480 o shortened SIP messages in example, removed real-world addresses 1481 and product names 1483 A.11. Changes from draft-sterman-aaa-sip-02 1485 o Relaxed restrictions for Digest-Domain, Digest-Realm, Digest- 1486 Opaque, Digest-Qop and Digest-Algorithm 1487 o Additional security considerations for Digest-Domain, Digest-Qop 1488 and Digest-Algorithm usage in Access-Accept messages 1490 A.12. Changes from draft-sterman-aaa-sip-01 1492 o Replaced Sub-attributes with flat attributes 1493 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1494 o Added how a server must treat unknown attributes. 1495 o Added a section 'Migration path to Diameter' 1496 o Added an optional attribute for support of the digest scheme 1497 described in informational [RFC3310]. 1498 o Added a mode of operation where the RADIUS server chooses the 1499 nonce. This was required for AKA [RFC3310], but can be useful for 1500 ordinary Digest Authentication when the qop directive is not used. 1501 This required the addition of several attributes. 1503 Authors' Addresses 1505 Baruch Sterman 1506 Kayote Networks 1507 P.O. Box 1373 1508 Efrat 90435 1509 Israel 1511 Email: baruch@kayote.com 1513 Daniel Sadolevsky 1514 SecureOL, Inc. 1515 Jerusalem Technology Park 1516 P.O. Box 16120 1517 Jerusalem 91160 1518 Israel 1520 Email: dscreat@dscreat.com 1522 David Schwartz 1523 Kayote Networks 1524 P.O. Box 1373 1525 Efrat 90435 1526 Israel 1528 Email: david@kayote.com 1530 David Williams 1531 Cisco Systems 1532 7025 Kit Creek Road 1533 P.O. Box 14987 1534 Research Triangle Park NC 27709 1535 USA 1537 Email: dwilli@cisco.com 1539 Wolfgang Beck 1540 Deutsche Telekom AG 1541 Deutsche Telekom Allee 7 1542 Darmstadt 64295 1543 Germany 1545 Email: beckw@t-systems.com 1547 Intellectual Property Statement 1549 The IETF takes no position regarding the validity or scope of any 1550 Intellectual Property Rights or other rights that might be claimed to 1551 pertain to the implementation or use of the technology described in 1552 this document or the extent to which any license under such rights 1553 might or might not be available; nor does it represent that it has 1554 made any independent effort to identify any such rights. Information 1555 on the procedures with respect to rights in RFC documents can be 1556 found in BCP 78 and BCP 79. 1558 Copies of IPR disclosures made to the IETF Secretariat and any 1559 assurances of licenses to be made available, or the result of an 1560 attempt made to obtain a general license or permission for the use of 1561 such proprietary rights by implementers or users of this 1562 specification can be obtained from the IETF on-line IPR repository at 1563 http://www.ietf.org/ipr. 1565 The IETF invites any interested party to bring to its attention any 1566 copyrights, patents or patent applications, or other proprietary 1567 rights that may cover technology that may be required to implement 1568 this standard. Please address the information to the IETF at 1569 ietf-ipr@ietf.org. 1571 Disclaimer of Validity 1573 This document and the information contained herein are provided on an 1574 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1575 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1576 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1577 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1578 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1579 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1581 Copyright Statement 1583 Copyright (C) The Internet Society (2006). This document is subject 1584 to the rights, licenses and restrictions contained in BCP 78, and 1585 except as set forth therein, the authors retain all their rights. 1587 Acknowledgment 1589 Funding for the RFC Editor function is currently provided by the 1590 Internet Society.