idnits 2.17.1 draft-ietf-radext-rfc4590bis-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1525. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The draft header indicates that this document obsoletes RFC4590, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 1008 -- Looks like a reference, but probably isn't: '1' on line 1028 -- Looks like a reference, but probably isn't: '2' on line 1028 -- Looks like a reference, but probably isn't: '3' on line 1018 == Missing Reference: 'Note 1' is mentioned on line 1039, but not defined == Missing Reference: 'Note 2' is mentioned on line 1042, but not defined == Missing Reference: 'Note 3' is mentioned on line 1045, but not defined == Missing Reference: 'Note 4' is mentioned on line 1047, 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 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4590 (Obsoleted by RFC 5090) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 17 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 Obsoletes: 4590 D. Sadolevsky 5 Category: Standards Track SecureOL, Inc. 6 D. Schwartz 7 2 July 2007 Kayote Networks 8 D. Williams 9 Cisco Systems 10 W. Beck 11 Deutsche Telekom AG 13 RADIUS Extension for Digest Authentication 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 17, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). All Rights Reserved. 42 Abstract 44 This document defines an extension to the Remote Authentication Dial- 45 In User Service (RADIUS) protocol to enable support of Digest 46 Authentication, for use with HTTP-style protocols like the Session 47 Initiation Protocol (SIP) and HTTP. 49 Table of Contents 51 1. Introduction ....................................................3 52 1.1. Terminology ................................................3 53 1.2. Motivation .................................................3 54 1.3. Overview ...................................................4 55 2. Detailed Description ............................................6 56 2.1. RADIUS Client Behavior .....................................6 57 2.2. RADIUS Server Behavior .....................................9 58 3. New RADIUS Attributes ..........................................12 59 3.1. Digest-Response attribute .................................12 60 3.2. Digest-Realm Attribute ....................................13 61 3.3. Digest-Nonce Attribute ....................................13 62 3.4. Digest-Response-Auth Attribute ............................14 63 3.5. Digest-Nextnonce Attribute ................................14 64 3.6. Digest-Method Attribute ...................................15 65 3.7. Digest-URI Attribute ......................................15 66 3.8. Digest-Qop Attribute ......................................15 67 3.9. Digest-Algorithm Attribute ................................16 68 3.10. Digest-Entity-Body-Hash Attribute ........................16 69 3.11. Digest-CNonce Attribute ..................................17 70 3.12. Digest-Nonce-Count Attribute .............................17 71 3.13. Digest-Username Attribute ................................17 72 3.14. Digest-Opaque Attribute ..................................18 73 3.15. Digest-Auth-Param Attribute ..............................18 74 3.16. Digest-AKA-Auts Attribute ................................19 75 3.17. Digest-Domain Attribute ..................................19 76 3.18. Digest-Stale Attribute ...................................20 77 3.19. Digest-HA1 Attribute .....................................20 78 3.20. SIP-AOR Attribute ........................................21 79 4. Diameter Compatibility .........................................21 80 5. Table of Attributes ............................................21 81 6. Examples .......................................................23 82 7. IANA Considerations ............................................26 83 8. Security Considerations ........................................27 84 8.1. Denial of Service .........................................27 85 8.2. Confidentiality and Data Integrity ........................28 86 9. References .....................................................29 87 9.1. Normative References ......................................29 88 9.2. Informative References ....................................29 89 Acknowledgements ..................................................30 90 Author's Addresses ................................................30 91 Appendix A - Changes from RFC 4590 ................................31 92 Full Copyright Statement ..........................................32 93 Intellectual Property .............................................32 94 1. Introduction 96 1.1. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 The use of normative requirement key words in this document shall 103 apply only to RADIUS client and RADIUS server implementations that 104 include the features described in this document. This document 105 creates no normative requirements for existing implementations. 107 HTTP-style protocol 108 The term 'HTTP-style' denotes any protocol that uses HTTP-like 109 headers and uses HTTP Digest Authentication as described in 110 [RFC2617]. Examples are HTTP and the Session Initiation Protocol 111 (SIP). 113 NAS Network Access Server, the RADIUS client. 115 nonce 116 An unpredictable value used to prevent replay attacks. The nonce 117 generator may use cryptographic mechanisms to produce nonces it can 118 recognize without maintaining state. 120 protection space 121 HTTP-style protocols differ in their definition of the protection 122 space. For HTTP, it is defined as the combination of realm and 123 canonical root URL of the requested resource for which the use is 124 authorized by the RADIUS server. In the case of SIP, the realm 125 string alone defines the protection space. 127 SIP UA 128 SIP User Agent, an Internet endpoint that uses the Session 129 Initiation Protocol. 131 SIP UAS 132 SIP User Agent Server, a logical entity that generates a response 133 to a SIP (Session Initiation Protocol) request. 135 1.2. Motivation 137 The HTTP Digest Authentication mechanism, defined in [RFC2617], was 138 subsequently adapted for use with SIP [RFC3261]. Due to the 139 limitations and weaknesses of Digest Authentication (see [RFC2617], 140 section 4), additional authentication and encryption mechanisms are 141 defined in SIP [RFC3261], including Transport Layer Security (TLS) 143 [RFC4346] and Secure MIME (S/MIME) [RFC3851]. However, Digest 144 Authentication support is mandatory in SIP implementations, and 145 Digest Authentication is the preferred way for a SIP UA to 146 authenticate itself to a proxy server. Digest Authentication is used 147 in other protocols as well. 149 To simplify the provisioning of users, there is a need to support 150 this authentication mechanism within Authentication, Authorization, 151 and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter 152 [RFC3588]. 154 This document defines an extension to the RADIUS protocol to enable 155 support of Digest Authentication for use with SIP, HTTP, and other 156 HTTP-style protocols using this authentication method. Support for 157 Digest mechanisms such as Authentication and Key Agreement (AKA) 158 [RFC3310] is also supported. A companion document [RFC4740] defines 159 support for Digest Authentication within Diameter. 161 1.3. Overview 163 HTTP Digest is a challenge-response protocol used to authenticate a 164 client's request to access some resource on a server. Figure 1 shows 165 a single HTTP Digest transaction. 167 HTTP/SIP.. 168 +------------+ (1) +------------+ 169 | |--------->| | 170 | HTTP-style | (2) | HTTP-style | 171 | client |<---------| server | 172 | | (3) | | 173 | |--------->| | 174 | | (4) | | 175 | |<---------| | 176 +------------+ +------------+ 178 Figure 1: Digest operation without RADIUS 180 If the client sends a request without any credentials (1), the server 181 will reply with an error response (2) containing a nonce. The client 182 creates a cryptographic digest from parts of the request, from the 183 nonce it received from the server, and from a shared secret. The 184 client re-transmits the request (3) to the server, but now includes 185 the digest within the packet. The server does the same digest 186 calculation as the client and compares the result with the digest it 187 received in (3). If the digest values are identical, the server 188 grants access to the resource and sends a positive response to the 189 client (4). If the digest values differ, the server sends a negative 190 response to the client (4). 192 Instead of maintaining a local user database, the server could use 193 RADIUS to access a centralized user database. However, RADIUS 194 [RFC2865] does not include support for HTTP Digest Authentication. 195 The RADIUS client cannot use the User-Password attribute, since it 196 does not receive a password from the HTTP-style client. The CHAP- 197 Challenge and CHAP-Password attributes described in [RFC1994] are 198 also not suitable since the CHAP algorithm is not compatible with 199 HTTP Digest. 201 This document defines new attributes that enable the RADIUS server to 202 perform the digest calculation defined in [RFC2617], providing 203 support for Digest Authentication as a native authentication 204 mechanism within RADIUS. 206 The nonces required by the digest algorithm are generated by the 207 RADIUS server. Generating them in the RADIUS client would save a 208 round-trip, but introduce security and operational issues. Some 209 digest algorithms -- e.g., AKA [RFC3310] -- would not work. 211 Figure 2 depicts a scenario in which the HTTP-style server defers 212 authentication to a RADIUS server. Entities A and B communicate 213 using HTTP or SIP, while entities B and C communicate using RADIUS. 215 HTTP/SIP RADIUS 217 +-----+ (1) +-----+ +-----+ 218 | |==========>| | (2) | | 219 | | | |---------->| | 220 | | | | (3) | | 221 | | (4) | |<----------| | 222 | |<==========| | | | 223 | | (5) | | | | 224 | |==========>| | | | 225 | A | | B | (6) | C | 226 | | | |---------->| | 227 | | | | (7) | | 228 | | | |<----------| | 229 | | (8) | | | | 230 | |<==========| | | | 231 +-----+ +-----+ +-----+ 233 ====> HTTP/SIP 234 ----> RADIUS 236 Figure 2: HTTP Digest over RADIUS 238 The entities have the following roles: 240 A: HTTP client / SIP UA 242 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 243 acting also as a RADIUS NAS 245 C: RADIUS server 247 The following messages are sent in this scenario: 249 A sends B an HTTP/SIP request without an authorization header (step 250 1). B sends an Access-Request packet with the newly defined Digest- 251 Method and Digest-URI attributes but without a Digest-Nonce attribute 252 to the RADIUS server, C (step 2). C chooses a nonce and responds 253 with an Access-Challenge (step 3). This Access-Challenge contains 254 Digest attributes, from which B takes values to construct an HTTP/SIP 255 "(Proxy) Authorization required" response. B sends this response to 256 A (step 4). A resends its request with its credentials (step 5). B 257 sends an Access-Request to C (step 6). C checks the credentials and 258 replies with Access-Accept or Access-Reject (step 7). Depending on 259 C's result, B processes A's request or rejects it with a "(Proxy) 260 Authorization required" response (step 8). 262 2. Detailed Description 264 2.1. RADIUS Client Behavior 266 The attributes described in this document are sent in cleartext. 267 Therefore, were a RADIUS client to accept secure connections (HTTPS 268 or SIPS) from HTTP-style clients, this could result in information 269 intentionally protected by HTTP-style clients being sent in the clear 270 during RADIUS exchange. 272 2.1.1. Credential Selection 274 On reception of an HTTP-style request message, the RADIUS client 275 checks whether it is authorized to authenticate the request. Where 276 an HTTP-style request traverses several proxies and each of the 277 proxies requests to authenticate the HTTP-style client, the request 278 at the HTTP-style server may contain multiple credential sets. 280 The RADIUS client can use the 'realm' directive in HTTP to determine 281 which credentials are applicable. Where none of the realms are of 282 interest, the RADIUS client MUST behave as though no relevant 283 credentials were sent. In all situations, the RADIUS client MUST 284 send zero or exactly one credential to the RADIUS server. The RADIUS 285 client MUST choose the credential of the (Proxy-)Authorization header 286 if the realm directive matches its locally configured realm. 288 2.1.2. Constructing an Access-Request 290 If a matching (Proxy-)Authorization header is present and contains 291 HTTP Digest information, the RADIUS client checks the 'nonce' 292 parameter. 294 If the RADIUS client recognizes the nonce, it takes the header 295 directives and puts them into a RADIUS Access-Request packet. It 296 puts the 'response' directive into a Digest-Response attribute and 297 the realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username, 298 and opaque directives into the respective Digest-Realm, Digest-Nonce, 299 Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce, Digest- 300 Nonce-Count, Digest-Username, and Digest-Opaque attributes. The 301 RADIUS client puts the request method into the Digest-Method 302 attribute. 304 Due to syntactic requirements, HTTP-style protocols have to escape 305 with backslash all quote and backslash characters in contents of HTTP 306 Digest directives. When translating directives into RADIUS 307 attributes, the RADIUS client only removes the surrounding quotes 308 where present. See Section 3 for an example. 310 If the Quality of Protection (qop) directive's value is 'auth-int', 311 the RADIUS client calculates H(entity-body) as described in 312 [RFC2617], Section 3.2.1, and puts the result in a Digest-Entity- 313 Body-Hash attribute. 315 The RADIUS client adds a Message-Authenticator attribute, defined in 316 [RFC3579], and sends the Access-Request packet to the RADIUS server. 318 The RADIUS server processes the packet and responds with an Access- 319 Accept or an Access-Reject. 321 2.1.3. Constructing an Authentication-Info Header 323 After having received an Access-Accept from the RADIUS server, the 324 RADIUS client constructs an Authentication-Info header: 326 o If the Access-Accept packet contains a Digest-Response-Auth 327 attribute, the RADIUS client checks the Digest-Qop attribute: 329 * If the Digest-Qop attribute's value is 'auth' or not specified, 330 the RADIUS client puts the Digest-Response-Auth attribute's 331 content into the Authentication-Info header's 'rspauth' 332 directive of the HTTP-style response. 334 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 335 client ignores the Access-Accept packet and behaves as if it 336 had received an Access-Reject packet (Digest-Response-Auth 337 can't be correct as the RADIUS server does not know the 338 contents of the HTTP-style response's body). 340 o If the Access-Accept packet contains a Digest-HA1 attribute, the 341 RADIUS client checks the 'qop' and 'algorithm' directives in the 342 Authorization header of the HTTP-style request it wants to 343 authorize: 345 * If the 'qop' directive is missing or its value is 'auth', the 346 RADIUS client ignores the Digest-HA1 attribute. It does not 347 include an Authentication-Info header in its HTTP-style 348 response. 350 * If the 'qop' directive's value is 'auth-int' and at least one 351 of the following conditions is true, the RADIUS client 352 calculates the contents of the HTTP-style response's 'rspauth' 353 directive: 355 + The algorithm directive's value is 'MD5-sess' or 356 'AKAv1-MD5-sess'. 358 + IP Security (IPsec) is configured to protect traffic between 359 the RADIUS client and RADIUS server with IPsec (see 360 Section 8). 362 It creates the HTTP-style response message and calculates the 363 hash of this message's body. It uses the result and the 364 Digest-URI attribute's value of the corresponding 365 Access-Request packet to perform the H(A2) calculation. It 366 takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and 367 Digest-Qop values of the corresponding Access-Request and the 368 Digest-HA1 attribute's value to finish the computation of the 369 'rspauth' value. 371 o If the Access-Accept packet contains neither a 372 Digest-Response-Auth nor a Digest-HA1 attribute, the RADIUS client 373 will not create an Authentication-Info header for its HTTP-style 374 response. 376 When the RADIUS server provides a Digest-Nextnonce attribute in the 377 Access-Accept packet, the RADIUS client puts the contents of this 378 attribute into a 'nextnonce' directive. Now it can send an HTTP- 379 style response. 381 2.1.4. Failed Authentication 383 If the RADIUS client did receive an HTTP-style request without a 384 (Proxy-)Authorization header matching its locally configured realm 385 value, it obtains a new nonce and sends an error response (401 or 386 407) containing a (Proxy-)Authenticate header. 388 If the RADIUS client receives an Access-Challenge packet in response 389 to an Access-Request containing a Digest-Nonce attribute, the RADIUS 390 server did not accept the nonce. If a Digest-Stale attribute is 391 present in the Access-Challenge and has a value of 'true' (without 392 surrounding quotes), the RADIUS client sends an error response (401 393 or 407) containing a WWW-/Proxy-Authenticate header with the 394 directive 'stale' and the digest directives derived from the Digest-* 395 attributes. 397 If the RADIUS client receives an Access-Reject from the RADIUS 398 server, it sends an error response to the HTTP-style request it has 399 received. If the RADIUS client does not receive a response, it 400 retransmits or fails over to another RADIUS server as described in 401 [RFC2865]. 403 2.1.5. Obtaining Nonces 405 The RADIUS client has two ways to obtain nonces: it has received one 406 in a Digest-Nextnonce attribute of a previously received Access- 407 Accept packet or it asks the RADIUS server for one. To do the 408 latter, it sends an Access-Request containing a Digest-Method and a 409 Digest-URI attribute but without a Digest-Nonce attribute. It adds a 410 Message-Authenticator (see [RFC3579]) attribute to the Access-Request 411 packet. The RADIUS server chooses a nonce and responds with an 412 Access-Challenge containing a Digest-Nonce attribute. 414 The RADIUS client constructs a (Proxy-)Authenticate header using the 415 received Digest-Nonce and Digest-Realm attributes to fill the nonce 416 and realm directives. The RADIUS server can send Digest-Qop, Digest- 417 Algorithm, Digest-Domain, and Digest-Opaque attributes in the Access- 418 Challenge carrying the nonce. If these attributes are present, the 419 client MUST use them. 421 2.2. RADIUS Server Behavior 423 If the RADIUS server receives an Access-Request packet with a Digest- 424 Method and a Digest-URI attribute but without a Digest-Nonce 425 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 426 attribute and sends it in an Access-Challenge packet to the RADIUS 427 client. The RADIUS server MUST add Digest-Realm, Message- 428 Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm and one or 429 more Digest-Qop, and MAY add Digest-Domain or Digest-Opaque 430 attributes to the Access-Challenge packet. 432 2.2.1. General Attribute Checks 434 If the RADIUS server receives an Access-Request packet containing a 435 Digest-Response attribute, it looks for the following attributes: 437 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, 438 Digest-Algorithm, and Digest-Username. Depending on the content of 439 Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- 440 Hash, Digest-CNonce, and Digest-AKA-Auts, too. See [RFC2617] and 441 [RFC3310] for details. If the Digest-Algorithm attribute is missing, 442 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque 443 attribute along with the nonce, the Access-Request MUST have a 444 matching Digest-Opaque attribute. 446 If mandatory attributes are missing, it MUST respond with an Access- 447 Reject packet. 449 The RADIUS server removes '\' characters that escape quote and '\' 450 characters from the text values it has received in the Digest-* 451 attributes. 453 If the mandatory attributes are present, the RADIUS server MUST check 454 if the RADIUS client is authorized to serve users of the realm 455 mentioned in the Digest-Realm attribute. If the RADIUS client is not 456 authorized, the RADIUS server MUST send an Access-Reject. The RADIUS 457 server SHOULD log the event so as to notify the operator, and MAY 458 take additional action such as sending an Access-Reject in response 459 to all future requests from this client, until this behavior is reset 460 by management action. 462 The RADIUS server determines the age of the nonce in Digest-Nonce by 463 using an embedded time-stamp or by looking it up in a local table. 464 The RADIUS server MUST check the integrity of the nonce if it embeds 465 the time-stamp in the nonce. Section 2.2.2 describes how the server 466 handles old nonces. 468 2.2.2. Authentication 470 If the Access-Request message has passed the checks described above, 471 the RADIUS server calculates the digest response as described in 472 [RFC2617]. To look up the password, the RADIUS server uses the 473 RADIUS User-Name attribute. The RADIUS server MUST check if the user 474 identified by the User-Name attribute: 476 o is authorized to access the protection space and 477 o is authorized to use the URI included in the SIP-AOR attribute, if 478 this attribute is present. 480 If any of those checks fails, the RADIUS server MUST send an Access- 481 Reject. 483 Correlation between User-Name and SIP-AOR AVP values is required just 484 to avoid that any user can register or misuse a SIP-AOR allocated to 485 a different user. 487 All values required for the digest calculation are taken from the 488 Digest attributes described in this document. If the calculated 489 digest response equals the value received in the Digest-Response 490 attribute, the authentication was successful. 492 If the response values match, but the RADIUS server considers the 493 nonce in the Digest-Nonce attribute as too old, it sends an Access- 494 Challenge packet containing a new nonce and a Digest-Stale attribute 495 with a value of 'true' (without surrounding quotes). 497 If the response values don't match, the RADIUS server responds with 498 an Access-Reject. 500 2.2.3. Constructing the Reply 502 If the authentication was successful, the RADIUS server adds an 503 attribute to the Access-Accept packet that can be used by the RADIUS 504 client to construct an Authentication-Info header: 506 o If the Digest-Qop attribute's value is 'auth' or unspecified, the 507 RADIUS server SHOULD put a Digest-Response-Auth attribute into the 508 Access-Accept packet. 510 o If the Digest-Qop attribute's value is 'auth-int' and at least one 511 of the following conditions is true, the RADIUS server SHOULD put 512 a Digest-HA1 attribute into the Access-Accept packet: 514 * The Digest-Algorithm attribute's value is 'MD5-sess' or 515 'AKAv1-MD5-sess'. 517 * IPsec is configured to protect traffic between the RADIUS 518 client 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 and one or more Digest-Qop 536 and 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 that 552 are redundant in RADIUS. For example, the directive 554 realm="the \"example\" value" 556 is represented as follows: 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-Request packets. 572 Type 573 103 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 a 16-octet digest 579 value as it was calculated by the authenticated client. Other 580 digest algorithms MAY define different digest lengths. The 581 text field MUST be copied from request-digest of 582 digest-response ([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], Section 1.2, for 590 details. It MUST only be used in Access-Request, 591 Access-Challenge, and Accounting-Request packets. 592 Type 593 104 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 607 This attribute holds a nonce to be used in the HTTP Digest 608 calculation. If the Access-Request had a Digest-Method and a 609 Digest-URI but no Digest-Nonce attribute, the RADIUS server 610 MUST put a Digest-Nonce attribute into its Access-Challenge 611 packet. This attribute MUST only be used in Access-Request 612 and Access-Challenge packets. 613 Type 614 105 for Digest-Nonce 615 Length 616 >=3 617 Text 618 In Access-Requests, the RADIUS client takes the value of the 619 nonce directive (nonce-value in [RFC2617]) without surrounding 620 quotes from the HTTP-style request it wants to authenticate. 622 In Access-Challenge packets, the attribute contains the nonce 623 selected by the RADIUS server. 625 3.4. Digest-Response-Auth Attribute 627 Description 628 This attribute enables the RADIUS server to prove possession of 629 the password. If the previously received Digest-Qop attribute 630 was 'auth-int' (without surrounding quotes), the RADIUS server 631 MUST send a Digest-HA1 attribute instead of a 632 Digest-Response-Auth attribute. The Digest-Response-Auth 633 attribute MUST only be used in Access-Accept packets. The 634 RADIUS client puts the attribute value without surrounding 635 quotes into the rspauth directive of the Authentication-Info 636 header. 637 Type 638 106 for Digest-Response-Auth. 639 Length 640 >= 3 641 Text 642 The RADIUS server calculates a digest according to section 643 3.2.3 of [RFC2617] and copies the result into this attribute. 644 Digest algorithms other than the one defined in [RFC2617] MAY 645 define digest lengths other than 32. 647 3.5. Digest-Nextnonce Attribute 649 This attribute holds a nonce to be used in the HTTP Digest 650 calculation. 652 Description 654 The RADIUS server MAY put a Digest-Nextnonce attribute into an 655 Access-Accept packet. If this attribute is present, the RADIUS 656 client MUST put the contents of this attribute into the 657 nextnonce directive of an Authentication-Info header in its 658 HTTP-style response. This attribute MUST only be used in 659 Access-Accept packets. 660 Type 661 107 for Digest-Nextnonce 662 Length 663 >=3 664 Text 665 It is recommended that this text be base64 or hexadecimal data. 667 3.6. Digest-Method Attribute 669 Description 670 This attribute holds the method value to be used in the HTTP 671 Digest calculation. This attribute MUST only be used in 672 Access-Request and Accounting-Request packets. 673 Type 674 108 for Digest-Method 675 Length 676 >=3 677 Text 678 In Access-Requests, the RADIUS client takes the value of the 679 request method from the HTTP-style request it wants to 680 authenticate. 682 3.7. Digest-URI Attribute 684 Description 685 This attribute is used to transport the contents of the 686 digest-uri directive or the URI of the HTTP-style request. 687 It MUST only be used in Access-Request and 688 Accounting-Request packets. 689 Type 690 109 for Digest-URI 691 Length 692 >=3 693 Text 694 If the HTTP-style request has an Authorization header, the 695 RADIUS client puts the value of the "uri" directive found in 696 the HTTP-style request Authorization header (known as 697 "digest-uri-value" in section 3.2.2 of [RFC2617]) without 698 surrounding quotes into this attribute. If there is no 699 Authorization header, the RADIUS client takes the value of 700 the request URI from the HTTP-style request it wants to 701 authenticate. 703 3.8. Digest-Qop Attribute 705 Description 706 This attribute holds the Quality of Protection parameter that 707 influences the HTTP Digest calculation. This attribute MUST 708 only be used in Access-Request, Access-Challenge and 709 Accounting-Request packets. A RADIUS client SHOULD insert 710 one of the Digest-Qop attributes it has received in a previous 711 Access-Challenge packet. RADIUS servers SHOULD insert at 712 least one Digest-Qop attribute in an Access-Challenge 713 packet. Digest-Qop is optional in order to preserve 714 backward compatibility with a minimal implementation 715 of [RFC2069]. 716 Type 717 110 for Digest-Qop 718 Length 719 >=3 720 Text 721 In Access-Requests, the RADIUS client takes the value of the 722 qop directive (qop-value as described in [RFC2617]) from the 723 HTTP-style request it wants to authenticate. In 724 Access-Challenge packets, the RADIUS server puts a desired 725 qop-value into this attribute. If the RADIUS server supports 726 more than one "quality of protection" value, it puts each 727 qop-value into a separate Digest-Qop attribute. 729 3.9. Digest-Algorithm Attribute 731 Description 732 This attribute holds the algorithm parameter that influences 733 the HTTP Digest calculation. It MUST only be used in 734 Access-Request, Access-Challenge and Accounting-Request 735 packets. If this attribute is missing, MD5 is assumed. 736 Type 737 111 for Digest-Algorithm 738 Length 739 >=3 740 Text 741 In Access-Requests, the RADIUS client takes the value of the 742 algorithm directive (as described in [RFC2617], section 3.2.1) 743 from the HTTP-style request it wants to authenticate. In 744 Access-Challenge packets, the RADIUS server SHOULD put the 745 desired algorithm into this attribute. 747 3.10. Digest-Entity-Body-Hash Attribute 749 Description 750 When using the qop-level 'auth-int', a hash of the HTTP-style 751 message body's contents is required for digest calculation. 752 Instead of sending the complete body of the message, only its 753 hash value is sent. This hash value can be used directly in 754 the digest calculation. 756 The clarifications described in section 22.4 of [RFC3261] about 757 the hash of empty entity bodies apply to the 758 Digest-Entity-Body-Hash attribute. This attribute MUST only be 759 sent in Access-Request packets. 760 Type 761 112 for Digest-Entity-Body-Hash 762 Length 763 >=3 764 Text 765 The attribute holds the hexadecimal representation of 766 H(entity-body). This hash is required by certain 767 authentication mechanisms, such as HTTP Digest with quality of 768 protection set to "auth-int". RADIUS clients MUST use this 769 attribute to transport the hash of the entity body when HTTP 770 Digest is the authentication mechanism and the RADIUS server 771 requires that the integrity of the entity body (e.g., qop 772 parameter set to "auth-int") be verified. Extensions to this 773 document may define support for authentication mechanisms 774 other than HTTP Digest. 776 3.11. Digest-CNonce Attribute 778 Description 779 This attribute holds the client nonce parameter that is used in 780 the HTTP Digest calculation. It MUST only be used in 781 Access-Request packets. 782 Type 783 113 for Digest-CNonce 784 Length 785 >=3 786 Text 787 This attribute includes the value of the cnonce-value [RFC2617] 788 without surrounding quotes, taken from the HTTP-style request. 790 3.12. Digest-Nonce-Count Attribute 792 Description 793 This attribute includes the nonce count parameter that is used 794 to detect replay attacks. The attribute MUST only be used in 795 Access-Request packets. 797 Type 798 114 for Digest-Nonce-Count 799 Length 800 10 801 Text 802 In Access-Requests, the RADIUS client takes the value of the nc 803 directive (nc-value according to [RFC2617]) without surrounding 804 quotes from the HTTP-style request it wants to authenticate. 806 3.13. Digest-Username Attribute 808 Description 809 This attribute holds the user name used in the HTTP Digest 810 calculation. The RADIUS server MUST use this attribute only 811 for the purposes of calculating the digest. In order to 812 determine the appropriate user credentials, the RADIUS server 813 MUST use the User-Name (1) attribute, and MUST NOT use the 814 Digest-Username attribute. This attribute MUST only be used in 815 Access-Request and Accounting-Request packets. 816 Type 817 115 for Digest-Username 818 Length 819 >= 3 820 Text 821 In Access-Requests, the RADIUS client takes the value of the 822 username directive (username-value according to [RFC2617]) 823 without surrounding quotes from the HTTP-style request it wants 824 to authenticate. 826 3.14. Digest-Opaque Attribute 828 Description 829 This attribute holds the opaque parameter that is passed to the 830 HTTP-style client. The HTTP-style client will pass this value 831 back to the server (i.e., the RADIUS client) without 832 modification. This attribute MUST only be used in 833 Access-Request and Access-Challenge packets. 834 Type 835 116 for Digest-Opaque 836 Length 837 >=3 838 Text 839 In Access-Requests, the RADIUS client takes the value of the 840 opaque directive (opaque-value according to [RFC2617]) without 841 surrounding quotes from the HTTP-style request it wants to 842 authenticate and puts it into this attribute. In 843 Access-Challenge packets, the RADIUS server MAY include this 844 attribute. 846 3.15. Digest-Auth-Param Attribute 848 Description 849 This attribute is a placeholder for future extensions and 850 corresponds to the "auth-param" parameter defined in section 851 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism 852 whereby the RADIUS client and RADIUS server can exchange 853 auth-param extension parameters contained within Digest headers 854 that are not understood by the RADIUS client and for which 855 there are no corresponding stand-alone attributes. 857 Unlike the previously listed Digest-* attributes, the 858 Digest-Auth-Param contains not only the value but also the 859 parameter name, since the parameter name is unknown to the 860 RADIUS client. If the Digest header contains several unknown 861 parameters, then the RADIUS implementation MUST repeat this 862 attribute and each instance MUST contain one different unknown 863 Digest parameter/value combination. This attribute MUST ONLY 864 be used in Access-Request, Access-Challenge, Access-Accept 865 and Accounting-Request packets. 866 Type 867 117 for Digest-Auth-Param 868 Length 869 >=3 870 Text 871 The text consists of the whole parameter, including its name 872 and the equal sign ('=') and quotes. 874 3.16. Digest-AKA-Auts Attribute 876 Description 877 This attribute holds the auts parameter that is used in the 878 Digest AKA ([RFC3310]) calculation. It is only used if the 879 algorithm of the digest-response denotes a version of AKA 880 Digest [RFC3310]. This attribute MUST only be used in 881 Access-Request packets. 882 Type 883 118 for Digest-AKA-Auts 884 Length 885 >=3 886 Text 887 In Access-Requests, the RADIUS client takes the value of the 888 auts directive (auts-param according to section 3.4 of 889 [RFC3310]) without surrounding quotes from the HTTP-style 890 request it wants to authenticate. 892 3.17. Digest-Domain Attribute 894 Description 895 When a RADIUS client has asked for a nonce, the RADIUS server 896 MAY send one or more Digest-Domain attributes in its 897 Access-Challenge packet. The RADIUS client puts them into the 898 quoted, space-separated list of URIs of the 'domain' directive 899 of a WWW-Authenticate header. Together with Digest-Realm, the 900 URIs in the list define the protection space (see [RFC2617], 901 section 3.2.1) for some HTTP-style protocols. This attribute 902 MUST only be used in Access-Challenge and Accounting-Request 903 packets. 904 Type 905 119 for Digest-Domain 906 Length 907 3 908 Text 909 This attribute consists of a single URI that defines a 910 protection space component. 912 3.18. Digest-Stale Attribute 914 Description 915 This attribute is sent by a RADIUS server in order to notify 916 the RADIUS client whether it has accepted a nonce. If the 917 nonce presented by the RADIUS client was stale, the value is 918 'true' and is 'false' otherwise. The RADIUS client puts the 919 content of this attribute into a 'stale' directive of the 920 WWW-Authenticate header in the HTTP-style response to the 921 request it wants to authenticate. The attribute MUST only be 922 used in Access-Challenge packets. 923 Type 924 120 for Digest-Stale 925 Length 926 3 927 Text 928 The attribute has either the value 'true' or 'false' (both 929 values without surrounding quotes). 931 3.19. Digest-HA1 Attribute 933 Description 934 This attribute is used to allow the generation of an 935 Authentication-Info header, even if the HTTP-style response's 936 body is required for the calculation of the rspauth value. It 937 SHOULD be used in Access-Accept packets if the required quality 938 of protection ('qop') is 'auth-int'. 940 This attribute MUST NOT be sent if the qop parameter was not 941 specified or has a value of 'auth' (in this case, use 942 Digest-Response-Auth instead). 944 The Digest-HA1 attribute MUST only be sent by the RADIUS server 945 or processed by the RADIUS client if at least one of the 946 following conditions is true: 948 + The Digest-Algorithm attribute's value is 'MD5-sess' or 949 'AKAv1-MD5-sess'. 951 + IPsec is configured to protect traffic between RADIUS client 952 and RADIUS server with IPsec (see Section 8). 954 This attribute MUST only be used in Access-Accept packets. 956 Type 957 121 for Digest-HA1 958 Length 959 >= 3 960 Text 961 This attribute contains the hexadecimal representation of H(A1) 962 as described in [RFC2617], sections 3.1.3, 3.2.1, and 3.2.2.2. 964 3.20. SIP-AOR Attribute 966 Description 967 This attribute is used for the authorization of SIP messages. 968 The SIP-AOR attribute identifies the URI, the use of which must 969 be authenticated and authorized. The RADIUS server uses this 970 attribute to authorize the processing of the SIP request. The 971 SIP-AOR can be derived from, for example, the To header field 972 in a SIP REGISTER request (user under registration), or the 973 From header field in other SIP requests. However, the exact 974 mapping of this attribute to SIP can change due to new 975 developments in the protocol. This attribute MUST only be used 976 when the RADIUS client wants to authorize SIP users and MUST 977 only be used in Access-Request packets. 978 Type 979 122 for SIP-AOR 980 Length 981 >=3 982 Text 983 The syntax of this attribute corresponds either to a SIP URI 984 (with the format defined in [RFC3261] or a tel URI (with the 985 format defined in [RFC3966]). 987 The SIP-AOR attribute holds the complete URI, including 988 parameters and other parts. It is up to the RADIUS server what 989 components of the URI are regarded in the authorization 990 decision. 992 4. Diameter Compatibility 994 This document defines support for Digest Authentication in RADIUS. A 995 companion document "Diameter Session Initiation Protocol (SIP) 996 Application" [RFC4740] defines support for Digest Authentication in 997 Diameter, and addresses compatibility issues between RADIUS and 998 Diameter. 1000 5. Table of Attributes 1002 The following table provides a guide to which attributes may be found 1003 in which kinds of packets, and in what quantity. 1005 Access- Access- Access- Access- Acct- 1006 Request Accept Reject Challenge Req # Attribute 1007 0-1 0 0 0 0-1 1 User-Name 1008 0-1 0 0 1 0 24 State [4] 1009 1 1 1 1 0-1 80 Message-Authenticator 1010 0-1 0 0 0 0 103 Digest-Response 1011 0-1 0 0 1 0-1 104 Digest-Realm 1012 0-1 0 0 1 0 105 Digest-Nonce 1013 0 0-1 0 0 0 106 Digest-Response-Auth [1][2] 1014 0 0-1 0 0 0 107 Digest-Nextnonce 1015 1 0 0 0 0-1 108 Digest-Method 1016 0-1 0 0 0 0-1 109 Digest-URI 1017 0-1 0 0 0+ 0-1 110 Digest-Qop 1018 0-1 0 0 0-1 0-1 111 Digest-Algorithm [3] 1019 0-1 0 0 0 0 112 Digest-Entity-Body-Hash 1020 0-1 0 0 0 0 113 Digest-CNonce 1021 0-1 0 0 0 0 114 Digest-Nonce-Count 1022 0-1 0 0 0 0-1 115 Digest-Username 1023 0-1 0 0 0-1 0 116 Digest-Opaque 1024 0+ 0+ 0 0+ 0+ 117 Digest-Auth-Param 1025 0-1 0 0 0 0 118 Digest-AKA-Auts 1026 0 0 0 0+ 0+ 119 Digest-Domain 1027 0 0 0 0-1 0 120 Digest-Stale 1028 0 0-1 0 0 0 121 Digest-HA1 [1][2] 1029 0-1 0 0 0 0 122 SIP-AOR 1031 The following table defines the meaning of the above table entries. 1033 0 This attribute MUST NOT be present in the packet. 1034 0+ Zero or more instances of this attribute MAY be 1035 present in the packet. 1036 0-1 Zero or one instance of this attribute MAY be 1037 present in the packet. 1039 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if 1040 Digest-Qop is 'auth-int'. 1042 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if 1043 Digest-Qop is 'auth'. 1045 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed. 1047 [Note 4] An Access-Challenge MUST contain a State attribute, which is 1048 copied to the subsequent Access-Request. A server receiving an 1049 Access-Request that contains a State attribute MUST respond with 1050 either an Access-Accept or an Access-Reject; the server MUST NOT 1051 respond with an Access-Challenge. 1053 6. Examples 1055 This is an example selected from the traffic between a softphone (A), 1056 a Proxy Server (B), and an example.com RADIUS server (C). The 1057 communication between the Proxy Server and a SIP Public Switched 1058 Telephone Network (PSTN) gateway is omitted for brevity. The SIP 1059 messages are not shown completely. 1061 The password of user '12345678' is 'secret'. The shared secret 1062 between RADIUS client and server is 'secret'. To ease testing, only 1063 the last byte of the RADIUS authenticator changes between Access- 1064 Requests. In a real implementation, this would be a serious flaw. 1066 A->B 1068 INVITE sip:97226491335@example.com SIP/2.0 1069 From: 1070 To: 1072 B->A 1074 SIP/2.0 100 Trying 1076 B->C 1078 Code = Access-Request (1) 1079 Packet identifier = 0x7c (124) 1080 Length = 97 1081 Authenticator = F5E55840E324AA49D216D9DBD069807C 1082 NAS-IP-Address = 192.168.2.38 1083 NAS-Port = 5 1084 User-Name = 12345678 1085 Digest-Method = INVITE 1086 Digest-URI = sip:97226491335@example.com 1087 Message-Authenticator = 26039915C2A55FF51D7DF4D4608738BD 1089 C->B 1091 Code = Access-Challenge (11) 1092 Packet identifier = 0x7c (124) 1093 Length = 72 1094 Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D 1095 Digest-Nonce = 3bada1a0 1096 Digest-Realm = example.com 1097 Digest-Qop = auth 1098 Digest-Algorithm = MD5 1099 Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3 1101 B->A 1103 SIP/2.0 407 Proxy Authentication Required 1104 Proxy-Authenticate: Digest realm="example.com" 1105 ,nonce="3bada1a0",qop=auth,algorithm=MD5 1106 Content-Length: 0 1108 A->B 1110 ACK sip:97226491335@example.com SIP/2.0 1112 A->B 1114 INVITE sip:97226491335@example.com SIP/2.0 1115 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1116 ,realm="example.com" 1117 ,response="7679b84a560835846ec553174dbabb69" 1118 ,uri="sip:97226491335@example.com",username="12345678" 1119 ,qop=auth,algorithm=MD5 1120 ,cnonce="56593a80,nc="00000001" 1122 From: 1123 To: 1125 B->C 1127 Code = Access-Request (1) 1128 Packet identifier = 0x7d (125) 1129 Length = 221 1130 Authenticator = F5E55840E324AA49D216D9DBD069807D 1131 NAS-IP-Address = 192.168.2.38 1132 NAS-Port = 5 1133 User-Name = 12345678 1134 Digest-Method = INVITE 1135 Digest-URI = sip:97226491335@example.com 1136 Digest-Realm = example.com 1137 Digest-Qop = auth 1138 Digest-Algorithm = MD5 1139 Digest-CNonce = 56593a80 1140 Digest-Nonce = 3bada1a0 1141 Digest-Nonce-Count = 00000001 1142 Digest-Response = 7679b84a560835846ec553174dbabb69 1143 Digest-Username = 12345678 1144 SIP-AOR = sip:12345678@example.com 1145 Message-Authenticator = 60832893BCB19D85DDF9836506F9C0D6 1147 C->B 1148 Code = Access-Accept (2) 1149 Packet identifier = 0x7d (125) 1150 Length = 72 1151 Authenticator = 36E1201AD4377664E720184CE7B3D8C6 1152 Digest-Response-Auth = 3792d3109224eb67213659e2d789f10d 1153 Message-Authenticator = 9B79B410CEBD335176DAEB24735DCF64 1155 B->A 1157 SIP/2.0 180 Ringing 1159 B->A 1161 SIP/2.0 200 OK 1163 A->B 1165 ACK sip:97226491335@example.com SIP/2.0 1167 A second example shows the traffic between a web browser (A), web 1168 server (B), and a RADIUS server (C). 1170 A->B 1172 GET /index.html HTTP/1.1 1174 B->C 1176 Code = Access-Request (1) 1177 Packet identifier = 0x7e (126) 1178 Length = 68 1179 Authenticator = F5E55840E324AA49D216D9DBD069807E 1180 NAS-IP-Address = 192.168.2.38 1181 NAS-Port = 5 1182 Digest-Method = GET 1183 Digest-URI = /index.html 1184 Message-Authenticator = A78C0D4FEF57CAD5EEE922AC3562B1F3 1186 C->B 1188 Code = Access-Challenge (11) 1189 Packet identifier = 0x7e (126) 1190 Length = 72 1191 Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E 1192 Digest-Nonce = a3086ac8 1193 Digest-Realm = example.com 1194 Digest-Qop = auth 1195 Digest-Algorithm = MD5 1196 Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A 1198 B->A 1200 HTTP/1.1 401 Authentication Required 1201 WWW-Authenticate: Digest realm="example.com", 1202 nonce="a3086ac8",qop=auth,algorithm=MD5 1203 Content-Length: 0 1205 A->B 1207 GET /index.html HTTP/1.1 1208 Authorization: Digest algorithm=MD5,qop=auth,nonce="a3086ac8" 1209 ,nc="00000001",cnonce="56593a78" 1210 ,realm="example.com" 1211 ,response="ba623217b5ec024d30c4aaef9d8494de" 1212 ,uri="/index.html",username="12345678" 1214 B->C 1216 Code = Access-Request (1) 1217 Packet identifier = 0x7f (127) 1218 Length = 176 1219 Authenticator = F5E55840E324AA49D216D9DBD069807F 1220 NAS-IP-Address = 192.168.2.38 1221 NAS-Port = 5 1222 User-Name = 12345678 1223 Digest-Method = GET 1224 Digest-URI = /index.html 1225 Digest-Realm = example.com 1226 Digest-Qop = auth 1227 Digest-Algorithm = MD5 1228 Digest-CNonce = 56593a80 1229 Digest-Nonce = a3086ac8 1230 Digest-Nonce-Count = 00000001 1231 Digest-Response = ba623217b5ec024d30c4aaef9d8494de 1232 Digest-Username = 12345678 1233 Message-Authenticator = 932B7565467F028AD399B8FBE57BE98C 1235 C->B 1237 Code = Access-Accept (2) 1238 Packet identifier = 0x7f (127) 1239 Length = 72 1240 Authenticator = F1ECAC22D3C88E0260B287FA35595F80 1241 Digest-Response-Auth = 29624e0bee4342994d041d07f7bcd44c 1242 Message-Authenticator = 956312EC57AF51ABC4F6965270F34982 1244 B->A 1246 HTTP/1.1 200 OK 1247 ... 1249 1250 ... 1252 7. IANA Considerations 1254 The following values from the RADIUS attribute type number space were 1255 assigned in [RFC4590]. This document requests that the values in the 1256 table below be entered within the existing registry. 1258 Attribute # 1259 --------------- ---- 1260 Digest-Response 103 1261 Digest-Realm 104 1262 Digest-Nonce 105 1263 Digest-Response-Auth 106 1264 Digest-Nextnonce 107 1265 Digest-Method 108 1266 Digest-URI 109 1267 Digest-Qop 110 1268 Digest-Algorithm 111 1269 Digest-Entity-Body-Hash 112 1270 Digest-CNonce 113 1271 Digest-Nonce-Count 114 1272 Digest-Username 115 1273 Digest-Opaque 116 1274 Digest-Auth-Param 117 1275 Digest-AKA-Auts 118 1276 Digest-Domain 119 1277 Digest-Stale 120 1278 Digest-HA1 121 1279 SIP-AOR 122 1281 8. Security Considerations 1283 The RADIUS extensions described in this document enable RADIUS to 1284 transport the data that is required to perform a digest calculation. 1285 As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see 1286 [RFC2617], section 4) in addition to RADIUS security vulnerabilities 1287 described in [RFC2865], section 8, and [RFC3579], section 4. 1289 An attacker compromising a RADIUS client or proxy can carry out man- 1290 in-the-middle attacks even if the paths between A, B and B, C (Figure 1291 2) have been secured with TLS or IPsec. 1293 The RADIUS server MUST check the Digest-Realm attribute it has 1294 received from a client. If the RADIUS client is not authorized to 1295 serve HTTP-style clients of that realm, it might be compromised. 1297 8.1. Denial of Service 1299 RADIUS clients implementing the extension described in this document 1300 may authenticate HTTP-style requests received over the Internet. As 1301 compared with the use of RADIUS to authenticate link-layer network 1302 access, attackers may find it easier to cover their tracks in such a 1303 scenario. 1305 An attacker can attempt a denial-of-service attack on one or more 1306 RADIUS servers by sending a large number of HTTP-style requests. To 1307 make simple denial-of-service attacks more difficult, the RADIUS 1308 server MUST check whether it has generated the nonce received from an 1309 HTTP-style client. This SHOULD be done statelessly. For example, a 1310 nonce could consist of a cryptographically random part and some kind 1311 of signature provided by the RADIUS client, as described in 1312 [RFC2617], section 3.2.1. 1314 8.2. Confidentiality and Data Integrity 1316 The attributes described in this document are sent in cleartext. 1317 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm 1318 attributes in Access-Challenge messages. A man in the middle can 1319 modify or remove those attributes in a bidding down attack, causing 1320 the RADIUS client to use a weaker authentication scheme than 1321 intended. 1323 The Message-Authenticator attribute, described in [RFC3579], section 1324 3.2 MUST be included in Access-Request, Access-Challenge, Access- 1325 Reject, and Access-Accept messages that contain attributes described 1326 in this specification. 1328 The Digest-HA1 attribute contains no random components if the 1329 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1330 attacks easier and enables replay attacks. 1332 Some parameter combinations require the protection of RADIUS packets 1333 against eavesdropping and tampering. Implementations SHOULD try to 1334 determine automatically whether IPsec is configured to protect 1335 traffic between the RADIUS client and the RADIUS server. If this is 1336 not possible, the implementation checks a configuration parameter 1337 telling it whether IPsec will protect RADIUS traffic. The default 1338 value of this configuration parameter tells the implementation that 1339 RADIUS packets will not be protected. 1341 HTTP-style clients can use TLS with server side certificates together 1342 with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, 1343 too. TLS or IPsec secure the connection while Digest Authentication 1344 authenticates the user. The RADIUS transaction can be regarded as 1345 one leg on the path between the HTTP-style client and the HTTP-style 1346 server. To prevent RADIUS from representing the weak link, a RADIUS 1347 client receiving an HTTP-style request via TLS or IPsec could use an 1348 equally secure connection to the RADIUS server. There are several 1349 ways to achieve this, for example: 1351 o The RADIUS client may reject HTTP-style requests received over TLS 1352 or IPsec. 1354 o The RADIUS client may require that traffic be sent and received 1355 over IPsec. 1357 RADIUS over IPsec, if used, MUST conform to the requirements 1358 described in [RFC3579], section 4.2. 1360 9. References 1362 9.1. Normative References 1364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1365 Requirement Levels", BCP 14, RFC 2119, March 1997. 1367 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1368 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 1369 Basic and Digest Access Authentication", RFC 2617, June 1999. 1371 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1372 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1373 2000. 1375 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1376 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1377 Session Initiation Protocol", RFC 3261, June 2002. 1379 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1380 In User Service) Support For Extensible Authentication 1381 Protocol (EAP)", RFC 3579, September 2003. 1383 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 1384 3966, December 2004. 1386 9.2. Informative References 1388 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol 1389 (CHAP)", RFC 1994, August 1996. 1391 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 1392 Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP 1393 : Digest Access Authentication", RFC 2069, January 1997. 1395 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1396 Protocol (HTTP) Digest Authentication Using Authentication and 1397 Key Agreement (AKA)", RFC 3310, September 2002. 1399 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1400 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1402 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 1403 (S/MIME) Version 3.1 Message Specification", RFC 3851, July 1404 2004. 1406 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1407 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1409 [RFC4590] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and 1410 W. Beck, "RADIUS Extension for Digest Authentication", RFC 1411 4590, July 2006. 1413 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- 1414 Valenzuela, C. and K. Tammik, "Diameter Session Initiation 1415 Protocol (SIP) Application", RFC 4740, November 2006. 1417 Acknowledgments 1419 We would like to acknowledge Kevin McDermott (Cisco Systems) for 1420 providing comments and experimental implementation. 1422 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1423 Arkko, Avi Lior, and Jun Wang. 1425 Authors' Addresses 1427 Baruch Sterman 1428 Kayote Networks 1429 P.O. Box 1373 1430 Efrat 90435 1431 Israel 1433 EMail: baruch@kayote.com 1435 Daniel Sadolevsky 1436 SecureOL, Inc. 1437 Jerusalem Technology Park 1438 P.O. Box 16120 1439 Jerusalem 91160 1440 Israel 1442 EMail: dscreat@dscreat.com 1444 David Schwartz 1445 Kayote Networks 1446 P.O. Box 1373 1447 Efrat 90435 1448 Israel 1449 EMail: david@kayote.com 1451 David Williams 1452 Cisco Systems 1453 7025 Kit Creek Road 1454 P.O. Box 14987 1455 Research Triangle Park NC 27709 1456 USA 1458 EMail: dwilli@cisco.com 1460 Wolfgang Beck 1461 Deutsche Telekom AG 1462 Deutsche Telekom Allee 7 1463 Darmstadt 64295 1464 Germany 1466 EMail: beckw@t-systems.com 1468 Appendix A - Changes from RFC 4590 1470 This Appendix lists the major changes between [RFC4590] and this 1471 document. Minor changes, including style, grammar, spelling, and 1472 editorial changes are not mentioned here. 1474 o The Table of Attributes (Section 5) now indicates that the Digest- 1475 Method attribute is required within an Access-Request. Also, an 1476 entry has been added for the State attribute. The table also 1477 includes entries for Accounting-Request messages. As noted in the 1478 examples, the User-Name attribute is not necessary when requesting a 1479 nonce. 1481 o Two errors in attribute assignment have been corrected within the 1482 IANA Considerations (Section 7). Digest-Response-Auth is assigned 1483 attribute 106, and Digest-Nextnonce is assigned attribute 107. 1485 o Several errors in the examples section have been corrected. 1487 Full Copyright Statement 1489 Copyright (C) The IETF Trust (2007). 1491 This document is subject to the rights, licenses and restrictions 1492 contained in BCP 78, and except as set forth therein, the authors 1493 retain all their rights. 1495 This document and the information contained herein are provided on an 1496 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1497 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1498 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1499 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1500 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1501 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1503 Intellectual Property 1505 The IETF takes no position regarding the validity or scope of any 1506 Intellectual Property Rights or other rights that might be claimed to 1507 pertain to the implementation or use of the technology described in 1508 this document or the extent to which any license under such rights 1509 might or might not be available; nor does it represent that it has 1510 made any independent effort to identify any such rights. Information 1511 on the procedures with respect to rights in RFC documents can be 1512 found in BCP 78 and BCP 79. 1514 Copies of IPR disclosures made to the IETF Secretariat and any 1515 assurances of licenses to be made available, or the result of an 1516 attempt made to obtain a general license or permission for the use of 1517 such proprietary rights by implementers or users of this 1518 specification can be obtained from the IETF on-line IPR repository at 1519 http://www.ietf.org/ipr. 1521 The IETF invites any interested party to bring to its attention any 1522 copyrights, patents or patent applications, or other proprietary 1523 rights that may cover technology that may be required to implement 1524 this standard. Please address the information to the IETF at ietf- 1525 ipr@ietf.org. 1527 Acknowledgment 1529 Funding for the RFC Editor function is provided by the IETF 1530 Administrative Support Activity (IASA). 1532 Open issues 1534 Open issues relating to this specification are tracked on the 1535 following web site: 1537 http://www.drizzle.com/~aboba/RADEXT/