idnits 2.17.1 draft-ietf-radext-digest-auth-09.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 1575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1565. ** 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 (May 22, 2006) is 6547 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 960, but not defined == Missing Reference: 'Note 1' is mentioned on line 1014, but not defined == Missing Reference: 'Note 2' is mentioned on line 1016, but not defined == Missing Reference: 'Note 3' is mentioned on line 1018, but not defined ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 3579 -- 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: 5 errors (**), 0 flaws (~~), 8 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: November 23, 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 May 22, 2006 14 RADIUS Extension for Digest Authentication 15 draft-ietf-radext-digest-auth-09.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 November 23, 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 . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . 32 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 . . . . . . 33 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 . . . . . . . . . . 34 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 with backslash all quote and backslash characters in contents of HTTP 326 Digest directives. When translating directives into RADIUS 327 attributes, the RADIUS client only removes the surrounding quotes 328 where present. See Section 3 for an 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 and '\' 457 characters from the text values it has received in the Digest-* 458 attributes. 460 If the mandatory attributes are present, the RADIUS server MUST check 461 if the RADIUS client is authorized to serve users of the realm 462 mentioned in the Digest-Realm attribute. If the RADIUS client is not 463 authorized, the RADIUS server MUST send an Access-Reject. The RADIUS 464 server SHOULD log the event so as to notify the operator, and MAY 465 take additional action such as sending an Access-Reject in response 466 to all future requests from this client, until this behavior is reset 467 by management action. 469 The RADIUS server determines the age of the nonce in Digest-Nonce by 470 using an embedded time-stamp, or by looking it up in a local table. 471 The RADIUS server MUST check the integrity of the nonce, if it embeds 472 the time-stamp in the nonce. Section 2.2.2 describes how the server 473 handles old nonces. 475 2.2.2. Authentication 477 If the Access-Request message has passed the checks described above, 478 the RADIUS server calculates the digest response as described in 479 [RFC2617]. To look up the password, the RADIUS server uses the 480 RADIUS User-Name attribute. The RADIUS server MUST check if the user 481 identified by the User-Name attribute 482 o is authorized to access the protection space 483 o is authorized to use the URI included in the SIP-AOR attribute, if 484 this attribute is present. 485 If any of those checks fails, the RADIUS server MUST send an Access- 486 Reject. 488 Correlation between User-Name and SIP-AOR AVP values is required just 489 to avoid that any user can register or misuse a SIP-AOR allocated to 490 a different user. 492 All values required for the digest calculation are taken from the 493 Digest attributes described in this document. If the calculated 494 digest response equals the value received in the Digest-Response 495 attribute, the authentication was successful. 497 If the response values match, but the RADIUS server considers the 498 nonce in the Digest-Nonce attribute as too old, it sends an Access- 499 Challenge packet containing a new nonce and a Digest-Stale attribute 500 with a value of 'true' (without surrounding quotes). 502 If the response values don't match, the RADIUS server responds with 503 an Access-Reject. 505 2.2.3. Constructing the Reply 507 If the authentication was successful, the RADIUS server adds an 508 attribute to the Access-Accept packet which can be used by the RADIUS 509 client to construct an Authentication-Info header: 510 o If the Digest-Qop attribute's value is 'auth' or unspecified, the 511 RADIUS server SHOULD put a Digest-Response-Auth attribute into the 512 Access-Accept packet 513 o If the Digest-Qop attribute's value is 'auth-int' and at least one 514 of the following conditions is true, the RADIUS server SHOULD put 515 a Digest-HA1 attribute into the Access-Accept packet: 516 * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- 517 MD5-sess'. 518 * IPsec is configured to protect traffic between RADIUS client 519 and RADIUS server with IPsec (see Section 8). 520 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be 521 sent. 523 RADIUS servers MAY construct a Digest-Nextnonce attribute and add it 524 to the Access-Accept packet. This is useful to limit the lifetime of 525 a nonce and to save a round-trip in future requests (see nextnonce 526 discussion in [RFC2617], section 3.2.3). The RADIUS server adds a 527 Message-Authenticator attribute (see [RFC3579]) and sends the Access- 528 Accept packet to the RADIUS client. 530 If the RADIUS server does not accept the nonce received in an Access- 531 Request packet but authentication was successful, the RADIUS server 532 MUST send an Access-Challenge packet containing a Digest-Stale 533 attribute set to 'true' (without surrounding quotes). The RADIUS 534 server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce, 535 Digest-Realm, SHOULD add Digest-Algorithm, one or more Digest-Qop and 536 MAY add Digest-Domain, Digest-Opaque attributes to the Access- 537 Challenge packet. 539 3. New RADIUS attributes 541 If not stated otherwise, the attributes have the following format: 543 0 1 2 544 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Length | Text ... 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Quote and backslash characters in Digest-* attributes representing 550 HTTP-style directives with a quoted-string syntax are escaped. The 551 surrounding quotes are removed. They are syntactical delimiters 552 which are redundant in RADIUS. For example, the directive 554 realm="the \"example\" value" 556 is represented as: 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Digest-Realm | 23 | the \"example\" value | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 3.1. Digest-Response attribute 564 Description 565 If this attribute is present in an Access-Request message, a 566 RADIUS server implementing this specification MUST treat the 567 Access-Request as a request for Digest Authentication. When a 568 RADIUS client receives a (Proxy-)Authorization header, it puts 569 the request-digest value into a Digest-Response attribute. 570 This attribute (which enables the user to prove possession of 571 the password) MUST only be used in Access-Requests. 572 Type 573 [IANA TBD] for Digest-Response. 574 Length 575 >= 3 576 Text 577 When using HTTP digest, the text field is 32 octets long and 578 contains a hexadecimal representation of 16 octet digest value 579 as it was calculated by the authenticated client. Other digest 580 algorithms MAY define different digest lengths. The text field 581 MUST be copied from request-digest of digest-response 582 ([RFC2617]) without surrounding quotes. 584 3.2. Digest-Realm attribute 586 Description 587 This attribute describes a protection space component of the 588 RADIUS server. HTTP-style protocols differ in their definition 589 of the protection space. See [RFC2617] 1.2 for details. It 590 MUST only be used in Access-Request and Access-Challenge 591 packets. 592 Type 593 [IANA TBD] for Digest-Realm 594 Length 595 >=3 596 Text 597 In Access-Requests, the RADIUS client takes the value of the 598 realm directive (realm-value according to [RFC2617]) without 599 surrounding quotes from the HTTP-style request it wants to 600 authenticate. In Access-Challenge packets, the RADIUS server 601 puts the expected realm value into this attribute. 603 3.3. Digest-Nonce attribute 605 Description 606 This attribute holds a nonce to be used in the HTTP Digest 607 calculation. If the Access-Request had a Digest-Method and a 608 Digest-URI but no Digest-Nonce attribute, the RADIUS server 609 MUST put a Digest-Nonce attribute into its Access-Challenge 610 packet. This attribute MUST only be used in Access-Request and 611 Access-Challenge packets. 612 Type 613 [IANA TBD] for Digest-Nonce 614 Length 615 >=3 616 Text 617 In Access-Requests, the RADIUS client takes the value of the 618 nonce directive (nonce-value in [RFC2617]) without surrounding 619 quotes from the HTTP-style request it wants to authenticate. 620 In Access-Challenge packets, the attribute contains the nonce 621 selected by the RADIUS server. 623 3.4. Digest-Response-Auth attribute 625 Description 626 This attribute enables the RADIUS server to prove possession of 627 the password. If the previously received Digest-Qop attribute 628 was 'auth-int' (without surrounding quotes), the RADIUS server 629 MUST send a Digest-HA1 attribute instead of a Digest-Response- 630 Auth attribute. The Digest-Response-Auth attribute MUST only 631 be used in Access-Accept packets. The RADIUS client puts the 632 attribute value without surrounding quotes into the rspauth 633 directive of the Authentication-Info header. 634 Type 635 [IANA TBD] for Digest-Response-Auth. 636 Length 637 >= 3 638 Text 639 The RADIUS server calculates a digest according to section 640 3.2.3 of [RFC2617] and copies the result into this attribute. 641 Other digest algorithms than the one defined in [RFC2617] MAY 642 define digest lengths other than 32. 644 3.5. Digest-Nextnonce attribute 646 This attribute holds a nonce to be used in the HTTP Digest 647 calculation. 649 Description 650 The RADIUS server MAY put a Digest-Nextnonce attribute into an 651 Access-Accept packet. If this attribute is present, the RADIUS 652 client MUST put the contents of this attribute into the 653 nextnonce directive of an Authentication-Info header in its 654 HTTP-style response. This attribute MUST only be used in 655 Access-Accept packets. 656 Type 657 [IANA TBD] for Digest-Nextnonce 658 Length 659 >=3 660 Text 661 It is recommended that this text be base64 or hexadecimal data. 663 3.6. Digest-Method attribute 665 Description 666 This attribute holds the method value to be used in the HTTP 667 Digest calculation. This attribute MUST only be used in 668 Access-Request packets. 669 Type 670 [IANA TBD] for Digest-Method 671 Length 672 >=3 673 Text 674 In Access-Requests, the RADIUS client takes the value of the 675 request method from the HTTP-style request it wants to 676 authenticate. 678 3.7. Digest-URI attribute 680 Description 681 This attribute is used to transport the contents of the digest- 682 uri directive or the URI of the HTTP-style request. It MUST 683 only be used in Access-Request packets. 684 Type 685 [IANA TBD] for Digest-URI 686 Length 687 >=3 688 Text 689 If the HTTP-style request has an Authorization header, the 690 RADIUS client puts the value of the "uri" directive in the 691 (known as "digest-uri-value" in section 3.2.2 of [RFC2617]) 692 without surrounding quotes into this attribute. If there is no 693 Authorization header, the RADIUS client takes the value of the 694 request URI from the HTTP-style request it wants to 695 authenticate. 697 3.8. Digest-Qop attribute 699 Description 700 This attribute holds the Quality of Protection parameter that 701 influences the HTTP Digest calculation. This attribute MUST 702 only be used in Access-Request and Access-Challenge packets. A 703 RADIUS client SHOULD insert one of the Digest-Qop attributes it 704 has received in a previous Access-Challenge packet. RADIUS 705 servers SHOULD insert at least one Digest-Qop attribute in an 706 Access-Challenge packet. Digest-Qop is optional in order to 707 preserve backward compatibility with a minimal implementation 708 of [RFC2069]. 709 Type 710 [IANA TBD] for Digest-Qop 711 Length 712 >=3 713 Text 714 In Access-Requests, the RADIUS client takes the value of the 715 qop directive (qop-value as described in [RFC2617]) from the 716 HTTP-style request it wants to authenticate. In Access- 717 Challenge packets, the RADIUS server puts a desired qop-value 718 into this attribute. If the RADIUS server supports more than 719 one "quality of protection" value, it puts each qop-value into 720 a separate Digest-Qop attribute. 722 3.9. Digest-Algorithm attribute 724 Description 725 This attribute holds the algorithm parameter that influences 726 the HTTP Digest calculation. It MUST only be used in Access- 727 Request and Access-Challenge packets. If this attribute is 728 missing, MD5 is assumed. 729 Type 730 [IANA TBD] for Digest-Algorithm 731 Length 732 >=3 733 Text 734 In Access-Requests, the RADIUS client takes the value of the 735 algorithm directive (as described in [RFC2617], section 3.2.1) 736 from the HTTP-style request it wants to authenticate. In 737 Access-Challenge packets, the RADIUS server SHOULD put the 738 desired algorithm into this attribute. 740 3.10. Digest-Entity-Body-Hash attribute 741 Description 742 When using the qop level 'auth-int', a hash of the HTTP-style 743 message body's contents is required for digest calculation. 744 Instead of sending the complete body of the message, only its 745 hash value is sent. This hash value can be used directly in 746 the digest calculation. 747 The clarifications described in section 22.4 of [RFC2617] about 748 the hash of empty entity bodies apply to the Digest-Entity- 749 Body-Hash attribute. This attribute MUST only be sent in 750 Access-Request packets. 751 Type 752 [IANA TBD] for Digest-Entity-Body-Hash 753 Length 754 >=3 755 Text 756 The attribute holds the hexadecimal representation of H(entity- 757 body). This hash is required by certain authentication 758 mechanisms, such as HTTP Digest with quality of protection set 759 to "auth-int". RADIUS clients MUST use this attribute to 760 transport the hash of the entity body when HTTP Digest is the 761 authentication mechanism and the RADIUS server requires to 762 verify the integrity of the entity body (e.g., qop parameter 763 set to "auth-int"). Extensions to this document may define 764 support for authentication mechanisms other than HTTP Digest. 766 3.11. Digest-CNonce attribute 768 Description 769 This attribute holds the client nonce parameter that is used in 770 the HTTP Digest calculation. It MUST only be used in Access- 771 Request packets. 772 Type 773 [IANA TBD] for Digest-CNonce 774 Length 775 >=3 776 Text 777 This attribute includes the value of the cnonce-value [RFC2617] 778 without surrounding quotes, taken from the HTTP-style request. 780 3.12. Digest-Nonce-Count attribute 782 Description 783 This attribute includes the nonce count parameter that is used 784 to detect replay attacks. The attribute MUST only be used in 785 Access-Request packets. 787 Type 788 [IANA TBD] for Digest-Nonce-Count 789 Length 790 10 791 Text 792 In Access-Requests, the RADIUS client takes the value of the nc 793 directive (nc-value according to [RFC2617]) without surrounding 794 quotes from the HTTP-style request it wants to authenticate. 796 3.13. Digest-Username attribute 798 Description 799 This attribute holds the user name used in the HTTP digest 800 calculation. The RADIUS server MUST use this attribute only 801 for the purposes of calculating the digest. In order to 802 determine the appropriate user credentials, the RADIUS server 803 MUST use the User-Name (1) attribute, and MUST NOT use the 804 Digest-Username attribute. This attribute MUST only be used in 805 Access-Request packets. 806 Type 807 [IANA TBD] for Digest-Username 808 Length 809 >= 3 810 Text 811 In Access-Requests, the RADIUS client takes the value of the 812 username directive (username-value according to [RFC2617]) 813 without surrounding quotes from the HTTP-style request it wants 814 to authenticate. 816 3.14. Digest-Opaque attribute 818 Description 819 This attribute holds the opaque parameter that is passed to the 820 HTTP-style client. The HTTP-style client will pass this value 821 back to the server (i.e. the RADIUS client) without 822 modification. This attribute MUST only be used in Access- 823 Request and Access-Challenge packets. 824 Type 825 [IANA TBD] for Digest-Opaque 826 Length 827 >=3 828 Text 829 In Access-Requests, the RADIUS client takes the value of the 830 opaque directive (opaque-value according to [RFC2617]) without 831 surrounding quotes from the HTTP-style request it wants to 832 authenticate and puts it into this attribute. In Access- 833 Challenge packets, the RADIUS server MAY include this 834 attribute. 836 3.15. Digest-Auth-Param attribute 838 Description 839 This attribute is a placeholder for future extensions and 840 corresponds to the "auth-param" parameter defined in section 841 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism 842 whereby the RADIUS client and RADIUS server can exchange auth- 843 param extension parameters contained within Digest headers that 844 are not understood by the RADIUS client and for which there are 845 no corresponding stand-alone attributes. 846 Unlike the previously listed Digest-* attributes, the Digest- 847 Auth-Param contains not only the value, but also the parameter 848 name, since the parameter name is unknown to the RADIUS client. 849 If the Digest header contains several unknown parameters, then 850 the RADIUS implementation MUST repeat this attribute and each 851 instance MUST contain one different unknown Digest parameter/ 852 value combination. This attribute MUST ONLY be used in Access- 853 Request, Access-Challenge, or Access-Accept packets. 854 Type 855 [IANA TBD] for Digest-Auth-Param 856 Length 857 >=3 858 Text 859 The text consists of the whole parameter, including its name 860 and the equal ('=') sign and quotes. 862 3.16. Digest-AKA-Auts attribute 864 Description 865 This attribute holds the auts parameter that is used in the 866 Digest AKA ([RFC3310]) calculation. It is only used if the 867 algorithm of the digest-response denotes a version of AKA 868 digest [RFC3310]. This attribute MUST only be used in Access- 869 Request packets. 870 Type 871 [IANA TBD] for Digest-AKA-Auts 872 Length 873 >=3 874 Text 875 In Access-Requests, the RADIUS client takes the value of the 876 auts directive (auts-param according to section 3.4 of 877 [RFC3310]) without surrounding quotes from the HTTP-style 878 request it wants to authenticate. 880 3.17. Digest-Domain attribute 881 Description 882 When a RADIUS client has asked for a nonce, the RADIUS server 883 MAY send one or more Digest-Domain attributes in its Access- 884 Challenge packet. The RADIUS client puts them into the quoted, 885 space-separated list of URIs of the 'domain' directive of a 886 WWW-Authenticate header. Together with Digest-Realm, the URIs 887 in the list define the protection space (see [RFC2617], section 888 3.2.1) for some HTTP-style protocols. This attribute MUST only 889 be used in Access-Challenge packets. 890 Type 891 [IANA TBD] for Digest-Domain 892 Length 893 3 894 Text 895 This attribute consists of a single URI, that defines a 896 protection space component. 898 3.18. Digest-Stale attribute 900 Description 901 This attribute is sent by a RADIUS server in order to notify 902 the RADIUS client whether it has accepted a nonce. If the 903 nonce presented by the RADIUS client was stale, the value is 904 'true' and is 'false' otherwise. The RADIUS client puts the 905 content of this attribute into a 'stale' directive of the WWW- 906 Authenticate header in the HTTP-style response to the request 907 it wants to authenticate. The attribute MUST only be used in 908 Access-Challenge packets. 909 Type 910 [IANA TBD] for Digest-Stale 911 Length 912 3 913 Text 914 The attribute has either the value 'true' or 'false' (both 915 values without surrounding quotes). 917 3.19. Digest-HA1 attribute 919 Description 920 This attribute is used to allow the generation of an 921 Authentication-Info header, even if the HTTP-style response's 922 body is required for the calculation of the rspauth value. It 923 SHOULD be used in Access-Accept packets if the required quality 924 of protection ('qop') is 'auth-int'. 926 This attribute MUST NOT be sent if the qop parameter was not 927 specified or has a value of 'auth' (in this case, use Digest- 928 Response-Auth instead). 929 The Digest-HA1 attribute MUST only be sent by the RADIUS server 930 or processed by the RADIUS client if at least one of the 931 following conditions is true: 932 + The Digest-Algorithm attribute's value is 'MD5-sess' or 933 'AKAv1-MD5-sess'. 934 + IPsec is configured to protect traffic between RADIUS client 935 and RADIUS server with IPsec (see Section 8). 936 This attribute MUST only be used in Access-Accept packets. 937 Type 938 [IANA TBD] for Digest-HA1 939 Length 940 >= 3 941 Text 942 This attribute contains the hexadecimal representation of H(A1) 943 as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2. 945 3.20. SIP-AOR 947 Description 948 This attribute is used for the authorization of SIP messages. 949 The SIP-AOR attribute identifies the URI the use of which must 950 be authenticated and authorized. The RADIUS server uses this 951 attribute to authorize the processing of the SIP request. The 952 SIP-AOR can be derived from, e.g., the To header field in a SIP 953 REGISTER request (user under registration), or the From header 954 field in other SIP requests. However, the exact mapping of 955 this attribute to SIP can change due to new developments in the 956 protocol. This attribute MUST only be used when the RADIUS 957 client wants to authorize SIP users and MUST only be used in 958 Access-Request packets. 959 Type 960 [IANA TBD] for SIP-AOR 961 Length 962 >=3 963 Text 964 The syntax of this attribute corresponds either to a SIP URI 965 (with the format defined in [RFC3261] or a TEL URI (with the 966 format defined in [RFC3966]). 967 The SIP-AOR attribute holds the complete URI, including 968 parameters and other parts. It is up to the RADIUS server what 969 components of the URI are regarded in the authorization 970 decision. 972 4. Diameter Compatibility 974 This document defines support for Digest Authentication in RADIUS. A 975 companion document "Diameter Session Initiation Protocol (SIP) 976 Application" [I-D.ietf-aaa-diameter-sip-app] defines support for 977 Digest Authentication in Diameter, and addresses compatibility issues 978 between RADIUS and Diameter. 980 5. Table of Attributes 982 The following table provides a guide to which attributes may be found 983 in which kinds of packets, and in what quantity. 985 Req Accept Reject Challenge # Attribute 986 1 0 0 0 1 User-Name 987 1 1 1 1 80 Message-Authenticator 988 0-1 0 0 0 TBD Digest-Response 989 0-1 0 0 1 TBD Digest-Realm 990 0-1 0 0 1 TBD Digest-Nonce 991 0 0-1 0 0 TBD Digest-Response-Auth 992 (see Note 1, 2) 993 0 0-1 0 0 TBD Digest-Nextnonce 994 0-1 0 0 0 TBD Digest-Method 995 0-1 0 0 0 TBD Digest-URI 996 0-1 0 0 0+ TBD Digest-Qop 997 0-1 0 0 0-1 TBD Digest-Algorithm (see 998 Note 3) 999 0-1 0 0 0 TBD Digest-Entity-Body-Hash 1000 0-1 0 0 0 TBD Digest-CNonce 1001 0-1 0 0 0 TBD Digest-Nonce-Count 1002 0-1 0 0 0 TBD Digest-Username 1003 0-1 0 0 0-1 TBD Digest-Opaque 1004 0+ 0+ 0 0+ TBD Digest-Auth-Param 1005 0-1 0 0 0 TBD Digest-AKA-Auts 1006 0 0 0 0+ TBD Digest-Domain 1007 0 0 0 0-1 TBD Digest-Stale 1008 0 0-1 0 0 TBD Digest-HA1 (see Note 1, 1009 2) 1010 0-1 0 0 0 TBD SIP-AOR 1012 Table 1 1014 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if 1015 Digest-Qop is 'auth-int'. 1016 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if 1017 Digest-Qop is 'auth'. 1018 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed 1020 6. Examples 1022 This is an example sniffed from the traffic between a softphone (A), 1023 a Proxy Server (B) and example.com RADIUS server (C). The 1024 communication between the Proxy Server and a SIP PSTN gateway is 1025 omitted for brevity. The SIP messages are not shown completely. 1027 A->B 1029 INVITE sip:97226491335@example.com SIP/2.0 1030 From: 1031 To: 1033 B->A 1035 SIP/2.0 100 Trying 1037 B->C 1039 Code = 1 (Access-Request) 1040 Attributes: 1041 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1042 NAS-Port-Type = 5 (Virtual) 1043 User-Name = 12345678 1044 Digest-Method = INVITE 1045 Digest-URI = sip:97226491335@example.com 1046 Message-Authenticator = 1047 08 af 7e 01 b6 8d 74 c3 a4 3c 33 e1 56 2a 80 43 1049 C->B 1051 Code = 11 (Access-Challenge) 1052 Attributes: 1054 Digest-Nonce = 3bada1a0 1055 Digest-Realm = example.com 1056 Digest-Qop = auth 1057 Digest-Algorithm = MD5 1058 Message-Authenticator = 1059 f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40 1061 B->A 1063 SIP/2.0 407 Proxy Authentication Required 1064 Proxy-Authenticate: Digest realm="example.com" 1065 ,nonce="3bada1a0",qop=auth,algorithm=MD5 1066 Content-Length: 0 1068 A->B 1070 ACK sip:97226491335@example.com SIP/2.0 1072 A->B 1074 INVITE sip:97226491335@example.com SIP/2.0 1075 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1076 ,realm="example.com" 1077 ,response="f3ce87e6984557cd0fecc26f3c5e97a4" 1078 ,uri="sip:97226491335@example.com",username="12345678" 1079 ,qop=auth,algorithm=MD5 1080 From: 1081 To: 1083 B->C 1085 Code = 1 (Access-Request) 1086 Attributes: 1087 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1088 NAS-Port-Type = 5 (Virtual) 1089 User-Name = 12345678 1090 Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4 1091 Digest-Realm = example.com 1092 Digest-Nonce = 3bada1a0 1093 Digest-Method = INVITE 1094 Digest-URI = sip:97226491335@example.com 1095 Digest-Qop = auth 1096 Digest-Algorithm = md5 1097 Digest-Username = 12345678 1098 SIP-AOR = sip:12345678@example.com 1099 Message-Authenticator = 1100 ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff 1102 C->B 1104 Code = 2 (Access-Accept) 1105 Attributes: 1106 Digest-Response-Auth = 1107 6303c41b0e2c3e524e413cafe8cce954 1108 Message-Authenticator = 1109 75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1 1111 B->A 1113 SIP/2.0 180 Ringing 1115 B->A 1117 SIP/2.0 200 OK 1119 A->B 1121 ACK sip:97226491335@example.com SIP/2.0 1123 A second example shows the traffic between a web browser (A), web 1124 server (B) and a RADIUS server (C). 1126 A->B 1128 GET /index.html HTTP/1.1 1130 B->C 1132 Code = 1 (Access-Request) 1133 Attributes: 1134 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1135 NAS-Port-Type = 5 (Virtual) 1136 Digest-Method = GET 1137 Digest-URI = /index.html 1138 Message-Authenticator = 1139 34 a6 26 46 f3 81 f9 b4 97 c0 dd 9d 11 8f ca c7 1141 C->B 1143 Code = 11 (Access-Challenge) 1144 Attributes: 1145 Digest-Nonce = a3086ac8 1146 Digest-Realm = example.com 1147 Digest-Qop = auth 1148 Digest-Algorithm = MD5 1149 Message-Authenticator = 1150 f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40 1152 B->A 1154 HTTP/1.1 401 Authentication Required 1155 WWW-Authenticate: Digest realm="example.com", 1156 nonce="a3086ac8",qop=auth,algorithm=MD5 1157 Content-Length: 0 1159 A->B 1161 GET /index.html HTTP/1.1 1162 Authorization: Digest algorithm=MD5,nonce="a3086ac8" 1163 ,realm="example.com" 1164 ,response="f052b68058b2987aba493857ae1ab002" 1165 ,uri="/index.html",username="12345678" 1166 ,qop=auth,algorithm=MD5 1168 B->C 1170 Code = 1 (Access-Request) 1171 Attributes: 1172 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1173 NAS-Port-Type = 5 (Virtual) 1174 User-Name = 12345678 1175 Digest-Response = f052b68058b2987aba493857ae1ab002 1176 Digest-Realm = example.com 1177 Digest-Nonce = a3086ac8 1178 Digest-Method = GET 1179 Digest-URI = /index.html 1180 Digest-Username = 12345678 1181 Digest-Qop = auth 1182 Digest-Algorithm = MD5 1183 Message-Authenticator = 1184 06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b 1186 C->B 1188 Code = 2 (Access-Accept) 1189 Attributes: 1190 Digest-Response-Auth = 1191 e644aa513effbfe1caff67103ff6433c 1192 Message-Authenticator = 1193 7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7 1195 B->A 1197 HTTP/1.1 200 OK 1198 ... 1200 1201 ... 1203 7. IANA Considerations 1205 This document serves as IANA registration request for a number of 1206 values from the RADIUS attribute type number space: 1208 +-------------------------+------------------------+ 1209 | placeholder | value assigned by IANA | 1210 +-------------------------+------------------------+ 1211 | Digest-Response | TBD | 1212 | Digest-Realm | TBD | 1213 | Digest-Nonce | TBD | 1214 | Digest-Nextnonce | TBD | 1215 | Digest-Response-Auth | TBD | 1216 | Digest-Method | TBD | 1217 | Digest-URI | TBD | 1218 | Digest-Qop | TBD | 1219 | Digest-Algorithm | TBD | 1220 | Digest-Entity-Body-Hash | TBD | 1221 | Digest-CNonce | TBD | 1222 | Digest-Nonce-Count | TBD | 1223 | Digest-Username | TBD | 1224 | Digest-Opaque | TBD | 1225 | Digest-Auth-Param | TBD | 1226 | Digest-AKA-Auts | TBD | 1227 | Digest-Domain | TBD | 1228 | Digest-Stale | TBD | 1229 | Digest-HA1 | TBD | 1230 | SIP-AOR | TBD | 1231 +-------------------------+------------------------+ 1233 Table 2 1235 8. Security Considerations 1237 The RADIUS extensions described in this document enable RADIUS to 1238 transport the data that required to perform a digest calculation. As 1239 a result, RADIUS inherits the vulnerabilities of HTTP Digest (see 1240 [RFC2617], section 4) in addition to RADIUS security vulnerabilities 1241 described in [RFC2865] Section 8 and [RFC3579] Section 4. 1243 An attacker compromising a RADIUS client or proxy can carry out man- 1244 in-the-middle attacks even if the paths between A, B and B, C 1245 (Figure 2) have been secured with TLS or IPsec. 1247 The RADIUS server MUST check the Digest-Realm attribute it has 1248 received from a client. If the RADIUS client is not authorized to 1249 serve HTTP-style clients of that realm, it might be compromised. 1251 8.1. Denial of Service 1253 RADIUS clients implementing the extension described in this document 1254 may authenticate HTTP-style requests received over the Internet. As 1255 compared with use of RADIUS to authenticate link layer network 1256 access, an attacker may find it easier to cover their tracks in such 1257 a scenario. 1259 An attacker can attempt a denial of service attack on one or more 1260 RADIUS servers by sending a large number of HTTP-style requests. To 1261 make simple denial of service attacks more difficult, the RADIUS 1262 server MUST check if it has generated the nonce received from an 1263 HTTP-style client. This SHOULD be done statelessly. For example, a 1264 nonce could consist of a cryptographically random part and some kind 1265 of signature provided by the RADIUS client, as described in 1266 [RFC2617], section 3.2.1. 1268 8.2. Confidentiality and Data Integrity 1270 The attributes described in this document are sent in cleartext. 1271 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm 1272 attributes in Access-Challenge messages. A man in the middle can 1273 modify or remove those attributes in a bidding down attack, causing 1274 the RADIUS client to use a weaker authentication scheme than 1275 intended. 1277 The Message-Authenticator attribute, described in [RFC3579] section 1278 3.2 MUST be included in Access-Request, Access-Challenge, Access- 1279 Reject and Access-Accept messages that contain attributes described 1280 in this specification. 1282 The Digest-HA1 attribute contains no random components if the 1283 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1284 attacks easier and enables replay attacks. 1286 Some parameter combinations require the protection of RADIUS packets 1287 against eavesdropping and tampering. Implementations SHOULD try to 1288 determine automatically whether IPsec is configured to protect 1289 traffic between the RADIUS client and the RADIUS server. If this is 1290 not possible, the implementation checks a configuration parameter 1291 telling it whether IPsec will protect RADIUS traffic. The default 1292 value of this configuration parameter tells the implementation that 1293 RADIUS packet will not be protected. 1295 HTTP-style clients can use TLS with server side certificates together 1296 with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, 1297 too. TLS or IPsec secure the connection while Digest Authentication 1298 authenticates the user. The RADIUS transaction can be regarded as 1299 one leg on the path between the HTTP-style client and the HTTP-style 1300 server. To prevent RADIUS from representing the weak link, a RADIUS 1301 client receiving an HTTP-style request via TLS or IPsec could use an 1302 equally secure connection to the RADIUS server. There are several 1303 ways to achieve this, for example: 1304 o the RADIUS client may reject HTTP-style requests received over TLS 1305 or IPsec 1306 o the RADIUS client require that traffic be sent and received over 1307 IPsec. 1308 RADIUS over IPsec, if used, MUST conform to the requirements 1309 described in [RFC3579] section 4.2. 1311 9. Acknowledgments 1313 We would like to acknowledge Kevin Mcdermott (Cisco Systems) for 1314 providing comments and experimental implementation. 1316 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1317 Arkko, Avi Lior and Jun Wang. 1319 10. References 1321 10.1. Normative References 1323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1324 Requirement Levels", BCP 14, RFC 2119, March 1997. 1326 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1327 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1328 Authentication: Basic and Digest Access Authentication", 1329 RFC 2617, June 1999. 1331 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1332 "Remote Authentication Dial In User Service (RADIUS)", 1333 RFC 2865, June 2000. 1335 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1336 A., Peterson, J., Sparks, R., Handley, M., and E. 1337 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1338 June 2002. 1340 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1341 Dial In User Service) Support For Extensible 1342 Authentication Protocol (EAP)", RFC 3579, September 2003. 1344 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1345 RFC 3966, December 2004. 1347 10.2. Informative References 1349 [I-D.ietf-aaa-diameter-sip-app] 1350 Garcia-Martin, M., "Diameter Session Initiation Protocol 1351 (SIP) Application", draft-ietf-aaa-diameter-sip-app-12 1352 (work in progress), April 2006. 1354 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1355 Protocol (CHAP)", RFC 1994, August 1996. 1357 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 1358 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 1359 HTTP : Digest Access Authentication", RFC 2069, 1360 January 1997. 1362 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1363 RFC 2246, January 1999. 1365 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1366 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1367 March 1999. 1369 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1370 RFC 2633, June 1999. 1372 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1373 Protocol (HTTP) Digest Authentication Using Authentication 1374 and Key Agreement (AKA)", RFC 3310, September 2002. 1376 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1377 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1379 Appendix A. Change Log 1381 RFC editor: please remove this section prior to RFC publication. 1383 A.1. Changes from draft-ietf-radext-digest-auth-07 1385 o removed client nonce generation mode 1386 o clarified quoting issues 1387 o clarified protection space issues 1388 o fixed examples 1389 o some nits 1391 A.2. Changes from draft-ietf-radext-digest-auth-06 1392 o added a nonce format to avoid nonce replays by a hijacked RADIUS 1393 client 1394 o clarifications about conditions depending on IPsec availability 1395 o clarified protection space usage with different HTTP-style 1396 protocols 1397 o Mentioned Digest-Entity-Body-Hash in RADIUS Client Behavior 1398 section 1399 o Clarified server side authentication and nonce-checking sequence 1400 o added a RADIUS client configuration section for scenario 1 1401 parameters 1402 o Split Security Considerations sections into subsections to enhance 1403 readability. 1404 o adjusted Table of Attributes entry for Digest-Qop to 0+ 1405 o Split Client/Server Behavior sections into subsections to enhance 1406 readability. 1407 o adjusted Table of Attributes entry for Digest-Qop to 0+, as it is 1408 only a SHOULD in the text. 1409 o removed preferred IANA values 1410 o replaced 'without quotes' with 'without surrounding quotes' 1411 o added Message-Authenticator attribute to example packets 1412 o removed redundant sentence from Digest-Domain description in 4.17 1413 o removed more typos 1415 A.3. Changes from draft-ietf-radext-digest-auth-05 1417 o Removed interdependency between sips/https and RADIUS connection 1418 security. 1420 A.4. Changes from draft-ietf-radext-digest-auth-04 1422 o Short Diameter compatibility section 1424 A.5. Changes from draft-ietf-radext-digest-auth-03 1426 o new 'Interoperability' section, requiring support for both nonce 1427 generation modes. 1428 o removed Diameter migration path section (again) 1429 o reference to server behavior in Security Considerations section 1430 o fixed text/table mismatch regarding Digest-Domain attributes 1432 A.6. Changes from draft-ietf-radext-digest-auth-02 1434 o added Diameter migration path section (again) 1435 o various typos 1437 A.7. Changes from draft-ietf-radext-digest-auth-01 1438 o removed Diameter migration path section 1439 o Included Digest-URI and Digest-Realm in the authorization 1440 decision, not just in the digest calculation 1441 o RADIUS server must check if a RADIUS client is authorized to serve 1442 the realm mentioned in Digest-Realm 1443 o moved 'Detailed Description' sections in front of 'New RADIUS 1444 attributes' section 1445 o replaced 'IPsec or otherwise secured connection' with IPsec 1446 o changed MAY to SHOULD for Digest-Algorithm in Access-Challenge 1447 o changed type of Digest-Entity-Body-Hash to text (all other H(..) 1448 result attributes are hex and text, too) 1449 o new abstract 1450 o Terminology section changed 1451 o 'Changes' section as appendix 1453 A.8. Changes from draft-ietf-radext-digest-auth-00 1455 o SIP-AOR attribute added 1456 o clarified use of Digest-Qop 1457 o attribute overview table added 1459 A.9. Changes from draft-sterman-aaa-sip-04 1461 o clarified usage of Digest-HA1 1462 o clarified usage of Digest-Stale (is sent in an Access-Challenge 1463 now) 1464 o clarified allowed attribute usage for message types 1465 o changed attribute type to 'Text' where the corresponding Diameter 1466 AVPs have a UTF8String 1467 o added Diameter client - RADIUS server handling 1469 A.10. Changes from draft-sterman-aaa-sip-03 1471 o addressed 'auth-int' issue 1472 o New Digest-Nextnonce attribute 1473 o revised abstract, motivational section and examples 1474 o Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce 1475 attribute' 1476 o shortened SIP messages in example, removed real-world addresses 1477 and product names 1479 A.11. Changes from draft-sterman-aaa-sip-02 1481 o Relaxed restrictions for Digest-Domain, Digest-Realm, Digest- 1482 Opaque, Digest-Qop and Digest-Algorithm 1483 o Additional security considerations for Digest-Domain, Digest-Qop 1484 and Digest-Algorithm usage in Access-Accept messages 1486 A.12. Changes from draft-sterman-aaa-sip-01 1488 o Replaced Sub-attributes with flat attributes 1489 o aligned naming with [I-D.ietf-aaa-diameter-sip-app] 1490 o Added how a server must treat unknown attributes. 1491 o Added a section 'Migration path to Diameter' 1492 o Added an optional attribute for support of the digest scheme 1493 described in informational [RFC3310]. 1494 o Added a mode of operation where the RADIUS server chooses the 1495 nonce. This was required for AKA [RFC3310], but can be useful for 1496 ordinary Digest Authentication when the qop directive is not used. 1497 This required the addition of several attributes. 1499 Authors' Addresses 1501 Baruch Sterman 1502 Kayote Networks 1503 P.O. Box 1373 1504 Efrat 90435 1505 Israel 1507 Email: baruch@kayote.com 1509 Daniel Sadolevsky 1510 SecureOL, Inc. 1511 Jerusalem Technology Park 1512 P.O. Box 16120 1513 Jerusalem 91160 1514 Israel 1516 Email: dscreat@dscreat.com 1518 David Schwartz 1519 Kayote Networks 1520 P.O. Box 1373 1521 Efrat 90435 1522 Israel 1524 Email: david@kayote.com 1526 David Williams 1527 Cisco Systems 1528 7025 Kit Creek Road 1529 P.O. Box 14987 1530 Research Triangle Park NC 27709 1531 USA 1533 Email: dwilli@cisco.com 1535 Wolfgang Beck 1536 Deutsche Telekom AG 1537 Deutsche Telekom Allee 7 1538 Darmstadt 64295 1539 Germany 1541 Email: beckw@t-systems.com 1543 Intellectual Property Statement 1545 The IETF takes no position regarding the validity or scope of any 1546 Intellectual Property Rights or other rights that might be claimed to 1547 pertain to the implementation or use of the technology described in 1548 this document or the extent to which any license under such rights 1549 might or might not be available; nor does it represent that it has 1550 made any independent effort to identify any such rights. Information 1551 on the procedures with respect to rights in RFC documents can be 1552 found in BCP 78 and BCP 79. 1554 Copies of IPR disclosures made to the IETF Secretariat and any 1555 assurances of licenses to be made available, or the result of an 1556 attempt made to obtain a general license or permission for the use of 1557 such proprietary rights by implementers or users of this 1558 specification can be obtained from the IETF on-line IPR repository at 1559 http://www.ietf.org/ipr. 1561 The IETF invites any interested party to bring to its attention any 1562 copyrights, patents or patent applications, or other proprietary 1563 rights that may cover technology that may be required to implement 1564 this standard. Please address the information to the IETF at 1565 ietf-ipr@ietf.org. 1567 Disclaimer of Validity 1569 This document and the information contained herein are provided on an 1570 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1571 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1572 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1573 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1574 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1575 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1577 Copyright Statement 1579 Copyright (C) The Internet Society (2006). This document is subject 1580 to the rights, licenses and restrictions contained in BCP 78, and 1581 except as set forth therein, the authors retain all their rights. 1583 Acknowledgment 1585 Funding for the RFC Editor function is currently provided by the 1586 Internet Society.