idnits 2.17.1 draft-ietf-radext-rfc4590bis-00.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 1485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1475. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 31 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages 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. -- 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) == Missing Reference: 'Note 1' is mentioned on line 1038, but not defined == Missing Reference: 'Note 2' is mentioned on line 1041, but not defined == Missing Reference: 'Note 3' is mentioned on line 1044, but not defined == Missing Reference: 'Note 4' is mentioned on line 1046, but not defined == Missing Reference: 'RFC4590' is mentioned on line 1449, but not defined ** Obsolete undefined reference: RFC 4590 (Obsoleted by RFC 5090) ** 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 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sterman 3 INTERNET-DRAFT Kayote Networks 4 Obsoletes: 4590 D. Sadolevsky 5 Category: Standards Track SecureOL, Inc. 6 D. Schwartz 7 1 January 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 July 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 ....................................................2 52 1.1. Terminology ................................................2 53 1.2. Motivation .................................................3 54 1.3. Overview ...................................................4 55 2. Detailed Description ............................................6 56 2.1. RADIUS Client Behavior .....................................6 57 2.1.1. Credential Selection ................................6 58 2.1.2. Constructing an Access-Request ......................7 59 2.1.3. Constructing an Authentication-Info Header ..........7 60 2.1.4. Failed Authentication ...............................9 61 2.1.5. Obtaining Nonces ....................................9 62 2.2. RADIUS Server Behavior .....................................9 63 2.2.1. General Attribute Checks ...........................10 64 2.2.2. Authentication .....................................10 65 2.2.3. Constructing the Reply .............................11 66 3. New RADIUS Attributes ..........................................12 67 3.1. Digest-Response attribute .................................12 68 3.2. Digest-Realm Attribute ....................................13 69 3.3. Digest-Nonce Attribute ....................................13 70 3.4. Digest-Response-Auth Attribute ............................14 71 3.5. Digest-Nextnonce Attribute ................................14 72 3.6. Digest-Method Attribute ...................................15 73 3.7. Digest-URI Attribute ......................................15 74 3.8. Digest-Qop Attribute ......................................15 75 3.9. Digest-Algorithm Attribute ................................16 76 3.10. Digest-Entity-Body-Hash Attribute ........................16 77 3.11. Digest-CNonce Attribute ..................................17 78 3.12. Digest-Nonce-Count Attribute .............................17 79 3.13. Digest-Username Attribute ................................17 80 3.14. Digest-Opaque Attribute ..................................18 81 3.15. Digest-Auth-Param Attribute ..............................18 82 3.16. Digest-AKA-Auts Attribute ................................19 83 3.17. Digest-Domain Attribute ..................................19 84 3.18. Digest-Stale Attribute ...................................20 85 3.19. Digest-HA1 Attribute .....................................20 86 3.20. SIP-AOR Attribute ........................................21 87 4. Diameter Compatibility .........................................21 88 5. Table of Attributes ............................................21 89 6. Examples .......................................................22 90 7. IANA Considerations ............................................26 91 8. Security Considerations ........................................27 92 8.1. Denial of Service .........................................27 93 8.2. Confidentiality and Data Integrity ........................28 94 9. References .....................................................29 95 9.1. Normative References ......................................29 96 9.2. Informative References ....................................29 98 1. Introduction 100 1.1. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 The use of normative requirement key words in this document shall 107 apply only to RADIUS client and RADIUS server implementations that 108 include the features described in this document. This document 109 creates no normative requirements for existing implementations. 111 HTTP-style protocol 112 The term 'HTTP-style' denotes any protocol that uses HTTP-like 113 headers and uses HTTP Digest Authentication as described in 114 [RFC2617]. Examples are HTTP and the Session Initiation Protocol 115 (SIP). 117 NAS Network Access Server, the RADIUS client. 119 nonce 120 An unpredictable value used to prevent replay attacks. The nonce 121 generator may use cryptographic mechanisms to produce nonces it can 122 recognize without maintaining state. 124 protection space 125 HTTP-style protocols differ in their definition of the protection 126 space. For HTTP, it is defined as the combination of realm and 127 canonical root URL of the requested resource for which the use is 128 authorized by the RADIUS server. In the case of SIP, the realm 129 string alone defines the protection space. 131 SIP UA 132 SIP User Agent, an Internet endpoint that uses the Session 133 Initiation Protocol. 135 SIP UAS 136 SIP User Agent Server, a logical entity that generates a response 137 to a SIP (Session Initiation Protocol) request. 139 1.2. Motivation 141 The HTTP Digest Authentication mechanism, defined in [RFC2617], was 142 subsequently adapted for use with SIP [RFC3261]. Due to the 143 limitations and weaknesses of Digest Authentication (see [RFC2617], 144 section 4), additional authentication and encryption mechanisms are 145 defined in SIP [RFC3261], including Transport Layer Security (TLS) 147 [RFC4346] and Secure MIME (S/MIME) [RFC3851]. However, Digest 148 Authentication support is mandatory in SIP implementations, and 149 Digest Authentication is the preferred way for a SIP UA to 150 authenticate itself to a proxy server. Digest Authentication is used 151 in other protocols as well. 153 To simplify the provisioning of users, there is a need to support 154 this authentication mechanism within Authentication, Authorization, 155 and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter 156 [RFC3588]. 158 This document defines an extension to the RADIUS protocol to enable 159 support of Digest Authentication for use with SIP, HTTP, and other 160 HTTP-style protocols using this authentication method. Support for 161 Digest mechanisms such as Authentication and Key Agreement (AKA) 162 [RFC3310] is also supported. A companion document [RFC4740] defines 163 support for Digest Authentication within Diameter. 165 1.3. Overview 167 HTTP Digest is a challenge-response protocol used to authenticate a 168 client's request to access some resource on a server. Figure 1 shows 169 a single HTTP Digest transaction. 171 HTTP/SIP.. 172 +------------+ (1) +------------+ 173 | |--------->| | 174 | HTTP-style | (2) | HTTP-style | 175 | client |<---------| server | 176 | | (3) | | 177 | |--------->| | 178 | | (4) | | 179 | |<---------| | 180 +------------+ +------------+ 182 Figure 1: Digest operation without RADIUS 184 If the client sends a request without any credentials (1), the server 185 will reply with an error response (2) containing a nonce. The client 186 creates a cryptographic digest from parts of the request, from the 187 nonce it received from the server, and from a shared secret. The 188 client re-transmits the request (3) to the server, but now includes 189 the digest within the packet. The server does the same digest 190 calculation as the client and compares the result with the digest it 191 received in (3). If the digest values are identical, the server 192 grants access to the resource and sends a positive response to the 193 client (4). If the digest values differ, the server sends a negative 194 response to the client (4). 196 Instead of maintaining a local user database, the server could use 197 RADIUS to access a centralized user database. However, RADIUS 198 [RFC2865] does not include support for HTTP Digest Authentication. 199 The RADIUS client cannot use the User-Password attribute, since it 200 does not receive a password from the HTTP-style client. The CHAP- 201 Challenge and CHAP-Password attributes described in [RFC1994] are 202 also not suitable since the CHAP algorithm is not compatible with 203 HTTP Digest. 205 This document defines new attributes that enable the RADIUS server to 206 perform the digest calculation defined in [RFC2617], providing 207 support for Digest Authentication as a native authentication 208 mechanism within RADIUS. 210 The nonces required by the digest algorithm are generated by the 211 RADIUS server. Generating them in the RADIUS client would save a 212 round-trip, but introduce security and operational issues. Some 213 digest algorithms -- e.g., AKA [RFC3310] -- would not work. 215 Figure 2 depicts a scenario in which the HTTP-style server defers 216 authentication to a RADIUS server. Entities A and B communicate 217 using HTTP or SIP, while entities B and C communicate using RADIUS. 219 HTTP/SIP RADIUS 221 +-----+ (1) +-----+ +-----+ 222 | |==========>| | (2) | | 223 | | | |---------->| | 224 | | | | (3) | | 225 | | (4) | |<----------| | 226 | |<==========| | | | 227 | | (5) | | | | 228 | |==========>| | | | 229 | A | | B | (6) | C | 230 | | | |---------->| | 231 | | | | (7) | | 232 | | | |<----------| | 233 | | (8) | | | | 234 | |<==========| | | | 235 +-----+ +-----+ +-----+ 237 ====> HTTP/SIP 238 ----> RADIUS 240 Figure 2: HTTP Digest over RADIUS 242 The entities have the following roles: 244 A: HTTP client / SIP UA 246 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 247 acting also as a RADIUS NAS 249 C: RADIUS server 251 The following messages are sent in this scenario: 253 A sends B an HTTP/SIP request without an authorization header (step 254 1). B sends an Access-Request packet with the newly defined Digest- 255 Method and Digest-URI attributes but without a Digest-Nonce attribute 256 to the RADIUS server, C (step 2). C chooses a nonce and responds 257 with an Access-Challenge (step 3). This Access-Challenge contains 258 Digest attributes, from which B takes values to construct an HTTP/SIP 259 "(Proxy) Authorization required" response. B sends this response to 260 A (step 4). A resends its request with its credentials (step 5). B 261 sends an Access-Request to C (step 6). C checks the credentials and 262 replies with Access-Accept or Access-Reject (step 7). Depending on 263 C's result, B processes A's request or rejects it with a "(Proxy) 264 Authorization required" response (step 8). 266 2. Detailed Description 268 2.1. RADIUS Client Behavior 270 The attributes described in this document are sent in cleartext. 271 Therefore, were a RADIUS client to accept secure connections (HTTPS 272 or SIPS) from HTTP-style clients, this could result in information 273 intentionally protected by HTTP-style clients being sent in the clear 274 during RADIUS exchange. 276 2.1.1. Credential Selection 278 On reception of an HTTP-style request message, the RADIUS client 279 checks whether it is authorized to authenticate the request. Where 280 an HTTP-style request traverses several proxies and each of the 281 proxies requests to authenticate the HTTP-style client, the request 282 at the HTTP-style server may contain multiple credential sets. 284 The RADIUS client can use the 'realm' directive in HTTP to determine 285 which credentials are applicable. Where none of the realms are of 286 interest, the RADIUS client MUST behave as though no relevant 287 credentials were sent. In all situations, the RADIUS client MUST 288 send zero or exactly one credential to the RADIUS server. The RADIUS 289 client MUST choose the credential of the (Proxy-)Authorization header 290 if the realm directive matches its locally configured realm. 292 2.1.2. Constructing an Access-Request 294 If a matching (Proxy-)Authorization header is present and contains 295 HTTP Digest information, the RADIUS client checks the 'nonce' 296 parameter. 298 If the RADIUS client recognizes the nonce, it takes the header 299 directives and puts them into a RADIUS Access-Request packet. It 300 puts the 'response' directive into a Digest-Response attribute and 301 the realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username, 302 and opaque directives into the respective Digest-Realm, Digest-Nonce, 303 Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce, Digest- 304 Nonce-Count, Digest-Username, and Digest-Opaque attributes. The 305 RADIUS client puts the request method into the Digest-Method 306 attribute. 308 Due to syntactic requirements, HTTP-style protocols have to escape 309 with backslash all quote and backslash characters in contents of HTTP 310 Digest directives. When translating directives into RADIUS 311 attributes, the RADIUS client only removes the surrounding quotes 312 where present. See Section 3 for an example. 314 If the Quality of Protection (qop) directive's value is 'auth-int', 315 the RADIUS client calculates H(entity-body) as described in 316 [RFC2617], Section 3.2.1, and puts the result in a Digest-Entity- 317 Body-Hash attribute. 319 The RADIUS client adds a Message-Authenticator attribute, defined in 320 [RFC3579], and sends the Access-Request packet to the RADIUS server. 322 The RADIUS server processes the packet and responds with an Access- 323 Accept or an Access-Reject. 325 2.1.3. Constructing an Authentication-Info Header 327 After having received an Access-Accept from the RADIUS server, the 328 RADIUS client constructs an Authentication-Info header: 330 o If the Access-Accept packet contains a Digest-Response-Auth 331 attribute, the RADIUS client checks the Digest-Qop attribute: 333 * If the Digest-Qop attribute's value is 'auth' or not specified, 334 the RADIUS client puts the Digest-Response-Auth attribute's 335 content into the Authentication-Info header's 'rspauth' 336 directive of the HTTP-style response. 338 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS 339 client ignores the Access-Accept packet and behaves as if it 340 had received an Access-Reject packet (Digest-Response-Auth 341 can't be correct as the RADIUS server does not know the 342 contents of the HTTP-style response's body). 344 o If the Access-Accept packet contains a Digest-HA1 attribute, the 345 RADIUS client checks the 'qop' and 'algorithm' directives in the 346 Authorization header of the HTTP-style request it wants to 347 authorize: 349 * If the 'qop' directive is missing or its value is 'auth', the 350 RADIUS client ignores the Digest-HA1 attribute. It does not 351 include an Authentication-Info header in its HTTP-style 352 response. 354 * If the 'qop' directive's value is 'auth-int' and at least one 355 of the following conditions is true, the RADIUS client 356 calculates the contents of the HTTP-style response's 'rspauth' 357 directive: 359 + The algorithm directive's value is 'MD5-sess' or 360 'AKAv1-MD5-sess'. 362 + IP Security (IPsec) is configured to protect traffic between 363 the RADIUS client and RADIUS server with IPsec (see 364 Section 8). 366 It creates the HTTP-style response message and calculates the 367 hash of this message's body. It uses the result and the 368 Digest-URI attribute's value of the corresponding 369 Access-Request packet to perform the H(A2) calculation. It 370 takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and 371 Digest-Qop values of the corresponding Access-Request and the 372 Digest-HA1 attribute's value to finish the computation of the 373 'rspauth' value. 375 o If the Access-Accept packet contains neither a 376 Digest-Response-Auth nor a Digest-HA1 attribute, the RADIUS client 377 will not create an Authentication-Info header for its HTTP-style 378 response. 380 When the RADIUS server provides a Digest-Nextnonce attribute in the 381 Access-Accept packet, the RADIUS client puts the contents of this 382 attribute into a 'nextnonce' directive. Now it can send an HTTP- 383 style response. 385 2.1.4. Failed Authentication 387 If the RADIUS client did receive an HTTP-style request without a 388 (Proxy-)Authorization header matching its locally configured realm 389 value, it obtains a new nonce and sends an error response (401 or 390 407) containing a (Proxy-)Authenticate header. 392 If the RADIUS client receives an Access-Challenge packet in response 393 to an Access-Request containing a Digest-Nonce attribute, the RADIUS 394 server did not accept the nonce. If a Digest-Stale attribute is 395 present in the Access-Challenge and has a value of 'true' (without 396 surrounding quotes), the RADIUS client sends an error response (401 397 or 407) containing a WWW-/Proxy-Authenticate header with the 398 directive 'stale' and the digest directives derived from the Digest-* 399 attributes. 401 If the RADIUS client receives an Access-Reject from the RADIUS 402 server, it sends an error response to the HTTP-style request it has 403 received. If the RADIUS client does not receive a response, it 404 retransmits or fails over to another RADIUS server as described in 405 [RFC2865]. 407 2.1.5. Obtaining Nonces 409 The RADIUS client has two ways to obtain nonces: it has received one 410 in a Digest-Nextnonce attribute of a previously received Access- 411 Accept packet or it asks the RADIUS server for one. To do the 412 latter, it sends an Access-Request containing a Digest-Method and a 413 Digest-URI attribute but without a Digest-Nonce attribute. It adds a 414 Message-Authenticator (see [RFC3579]) attribute to the Access-Request 415 packet. The RADIUS server chooses a nonce and responds with an 416 Access-Challenge containing a Digest-Nonce attribute. 418 The RADIUS client constructs a (Proxy-)Authenticate header using the 419 received Digest-Nonce and Digest-Realm attributes to fill the nonce 420 and realm directives. The RADIUS server can send Digest-Qop, Digest- 421 Algorithm, Digest-Domain, and Digest-Opaque attributes in the Access- 422 Challenge carrying the nonce. If these attributes are present, the 423 client MUST use them. 425 2.2. RADIUS Server Behavior 427 If the RADIUS server receives an Access-Request packet with a Digest- 428 Method and a Digest-URI attribute but without a Digest-Nonce 429 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce 430 attribute and sends it in an Access-Challenge packet to the RADIUS 431 client. The RADIUS server MUST add Digest-Realm, Message- 432 Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm and one or 433 more Digest-Qop, and MAY add Digest-Domain or Digest-Opaque 434 attributes to the Access-Challenge packet. 436 2.2.1. General Attribute Checks 438 If the RADIUS server receives an Access-Request packet containing a 439 Digest-Response attribute, it looks for the following attributes: 441 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, 442 Digest-Algorithm, and Digest-Username. Depending on the content of 443 Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- 444 Hash, Digest-CNonce, and Digest-AKA-Auts, too. See [RFC2617] and 445 [RFC3310] for details. If the Digest-Algorithm attribute is missing, 446 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque 447 attribute along with the nonce, the Access-Request MUST have a 448 matching Digest-Opaque attribute. 450 If mandatory attributes are missing, it MUST respond with an Access- 451 Reject packet. 453 The RADIUS server removes '' characters that escape quote and '' 454 characters from the text values it has received in the Digest-* 455 attributes. 457 If the mandatory attributes are present, the RADIUS server MUST check 458 if the RADIUS client is authorized to serve users of the realm 459 mentioned in the Digest-Realm attribute. If the RADIUS client is not 460 authorized, the RADIUS server MUST send an Access-Reject. The RADIUS 461 server SHOULD log the event so as to notify the operator, and MAY 462 take additional action such as sending an Access-Reject in response 463 to all future requests from this client, until this behavior is reset 464 by management action. 466 The RADIUS server determines the age of the nonce in Digest-Nonce by 467 using an embedded time-stamp or by looking it up in a local table. 468 The RADIUS server MUST check the integrity of the nonce if it embeds 469 the time-stamp in the nonce. Section 2.2.2 describes how the server 470 handles old nonces. 472 2.2.2. Authentication 474 If the Access-Request message has passed the checks described above, 475 the RADIUS server calculates the digest response as described in 476 [RFC2617]. To look up the password, the RADIUS server uses the 477 RADIUS User-Name attribute. The RADIUS server MUST check if the user 478 identified by the User-Name attribute: 480 o is authorized to access the protection space and 481 o is authorized to use the URI included in the SIP-AOR attribute, if 482 this attribute is present. 484 If any of those checks fails, the RADIUS server MUST send an Access- 485 Reject. 487 Correlation between User-Name and SIP-AOR AVP values is required just 488 to avoid that any user can register or misuse a SIP-AOR allocated to 489 a different user. 491 All values required for the digest calculation are taken from the 492 Digest attributes described in this document. If the calculated 493 digest response equals the value received in the Digest-Response 494 attribute, the authentication was successful. 496 If the response values match, but the RADIUS server considers the 497 nonce in the Digest-Nonce attribute as too old, it sends an Access- 498 Challenge packet containing a new nonce and a Digest-Stale attribute 499 with a value of 'true' (without surrounding quotes). 501 If the response values don't match, the RADIUS server responds with 502 an Access-Reject. 504 2.2.3. Constructing the Reply 506 If the authentication was successful, the RADIUS server adds an 507 attribute to the Access-Accept packet that can be used by the RADIUS 508 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. 514 o If the Digest-Qop attribute's value is 'auth-int' and at least one 515 of the following conditions is true, the RADIUS server SHOULD put 516 a Digest-HA1 attribute into the Access-Accept packet: 518 * The Digest-Algorithm attribute's value is 'MD5-sess' or 519 'AKAv1-MD5-sess'. 521 * IPsec is configured to protect traffic between the RADIUS 522 client and RADIUS server with IPsec (see Section 8). 524 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be 525 sent. 527 RADIUS servers MAY construct a Digest-Nextnonce attribute and add it 528 to the Access-Accept packet. This is useful to limit the lifetime of 529 a nonce and to save a round-trip in future requests (see nextnonce 530 discussion in [RFC2617], section 3.2.3). The RADIUS server adds a 531 Message-Authenticator attribute (see [RFC3579]) and sends the Access- 532 Accept packet to the RADIUS client. 534 If the RADIUS server does not accept the nonce received in an Access- 535 Request packet but authentication was successful, the RADIUS server 536 MUST send an Access-Challenge packet containing a Digest-Stale 537 attribute set to 'true' (without surrounding quotes). The RADIUS 538 server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce, 539 Digest-Realm, SHOULD add Digest-Algorithm and one or more Digest-Qop 540 and MAY add Digest-Domain, Digest-Opaque attributes to the Access- 541 Challenge packet. 543 3. New RADIUS Attributes 545 If not stated otherwise, the attributes have the following format: 547 0 1 2 548 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type | Length | Text ... 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Quote and backslash characters in Digest-* attributes representing 554 HTTP-style directives with a quoted-string syntax are escaped. The 555 surrounding quotes are removed. They are syntactical delimiters that 556 are redundant in RADIUS. For example, the directive 558 realm="the 560 is represented as follows: 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Digest-Realm | 23 | the 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 3.1. Digest-Response attribute 568 Description 569 If this attribute is present in an Access-Request message, a 570 RADIUS server implementing this specification MUST treat the 571 Access-Request as a request for Digest Authentication. When a 572 RADIUS client receives a (Proxy-)Authorization header, it puts 573 the request-digest value into a Digest-Response attribute. 574 This attribute (which enables the user to prove possession of 575 the password) MUST only be used in Access-Requests. 576 Type 577 103 for Digest-Response. 578 Length 579 >= 3 580 Text 581 When using HTTP Digest, the text field is 32 octets long and 582 contains a hexadecimal representation of a 16-octet digest 583 value as it was calculated by the authenticated client. Other 584 digest algorithms MAY define different digest lengths. The 585 text field MUST be copied from request-digest of 586 digest-response ([RFC2617]) without surrounding quotes. 588 3.2. Digest-Realm Attribute 590 Description 591 This attribute describes a protection space component of the 592 RADIUS server. HTTP-style protocols differ in their definition 593 of the protection space. See [RFC2617], Section 1.2, for 594 details. It MUST only be used in Access-Request and 595 Access-Challenge packets. 596 Type 597 104 for Digest-Realm 598 Length 599 >=3 600 Text 601 In Access-Requests, the RADIUS client takes the value of the 602 realm directive (realm-value according to [RFC2617]) without 603 surrounding quotes from the HTTP-style request it wants to 604 authenticate. In Access-Challenge packets, the RADIUS server 605 puts the expected realm value into this attribute. 607 3.3. Digest-Nonce Attribute 609 Description 611 This attribute holds a nonce to be used in the HTTP Digest 612 calculation. If the Access-Request had a Digest-Method and a 613 Digest-URI but no Digest-Nonce attribute, the RADIUS server 614 MUST put a Digest-Nonce attribute into its Access-Challenge 615 packet. This attribute MUST only be used in Access-Request and 616 Access-Challenge packets. 617 Type 618 105 for Digest-Nonce 619 Length 620 >=3 621 Text 622 In Access-Requests, the RADIUS client takes the value of the 623 nonce directive (nonce-value in [RFC2617]) without surrounding 624 quotes from the HTTP-style request it wants to authenticate. 626 In Access-Challenge packets, the attribute contains the nonce 627 selected by the RADIUS server. 629 3.4. Digest-Response-Auth Attribute 631 Description 632 This attribute enables the RADIUS server to prove possession of 633 the password. If the previously received Digest-Qop attribute 634 was 'auth-int' (without surrounding quotes), the RADIUS server 635 MUST send a Digest-HA1 attribute instead of a 636 Digest-Response-Auth attribute. The Digest-Response-Auth 637 attribute MUST only be used in Access-Accept packets. The 638 RADIUS client puts the attribute value without surrounding 639 quotes into the rspauth directive of the Authentication-Info 640 header. 641 Type 642 106 for Digest-Response-Auth. 643 Length 644 >= 3 645 Text 646 The RADIUS server calculates a digest according to section 647 3.2.3 of [RFC2617] and copies the result into this attribute. 648 Digest algorithms other than the one defined in [RFC2617] MAY 649 define digest lengths other than 32. 651 3.5. Digest-Nextnonce Attribute 653 This attribute holds a nonce to be used in the HTTP Digest 654 calculation. 656 Description 658 The RADIUS server MAY put a Digest-Nextnonce attribute into an 659 Access-Accept packet. If this attribute is present, the RADIUS 660 client MUST put the contents of this attribute into the 661 nextnonce directive of an Authentication-Info header in its 662 HTTP-style response. This attribute MUST only be used in 663 Access-Accept packets. 664 Type 665 107 for Digest-Nextnonce 666 Length 667 >=3 668 Text 669 It is recommended that this text be base64 or hexadecimal data. 671 3.6. Digest-Method Attribute 673 Description 674 This attribute holds the method value to be used in the HTTP 675 Digest calculation. This attribute MUST only be used in 676 Access-Request packets. 677 Type 678 108 for Digest-Method 679 Length 680 >=3 681 Text 682 In Access-Requests, the RADIUS client takes the value of the 683 request method from the HTTP-style request it wants to 684 authenticate. 686 3.7. Digest-URI Attribute 688 Description 689 This attribute is used to transport the contents of the 690 digest-uri directive or the URI of the HTTP-style request. It 691 MUST only be used in Access-Request packets. 692 Type 693 109 for Digest-URI 694 Length 695 >=3 696 Text 697 If the HTTP-style request has an Authorization header, the 698 RADIUS client puts the value of the "uri" directive found in 699 the HTTP-style request Authorization header (known as 700 "digest-uri-value" in section 3.2.2 of [RFC2617]) without 701 surrounding quotes into this attribute. If there is no 702 Authorization header, the RADIUS client takes the value of the 703 request URI from the HTTP-style request it wants to 704 authenticate. 706 3.8. Digest-Qop Attribute 708 Description 709 This attribute holds the Quality of Protection parameter that 710 influences the HTTP Digest calculation. This attribute MUST 711 only be used in Access-Request and Access-Challenge packets. A 712 RADIUS client SHOULD insert one of the Digest-Qop attributes it 713 has received in a previous Access-Challenge packet. RADIUS 714 servers SHOULD insert at least one Digest-Qop attribute in an 715 Access-Challenge packet. Digest-Qop is optional in order to 716 preserve backward compatibility with a minimal implementation 717 of [RFC2069]. 718 Type 719 110 for Digest-Qop 720 Length 721 >=3 722 Text 723 In Access-Requests, the RADIUS client takes the value of the 724 qop directive (qop-value as described in [RFC2617]) from the 725 HTTP-style request it wants to authenticate. In 726 Access-Challenge packets, the RADIUS server puts a desired 727 qop-value into this attribute. If the RADIUS server supports 728 more than one "quality of protection" value, it puts each 729 qop-value into a separate Digest-Qop attribute. 731 3.9. Digest-Algorithm Attribute 733 Description 734 This attribute holds the algorithm parameter that influences 735 the HTTP Digest calculation. It MUST only be used in 736 Access-Request and Access-Challenge packets. If this attribute 737 is missing, MD5 is assumed. 738 Type 739 111 for Digest-Algorithm 740 Length 741 >=3 742 Text 743 In Access-Requests, the RADIUS client takes the value of the 744 algorithm directive (as described in [RFC2617], section 3.2.1) 745 from the HTTP-style request it wants to authenticate. In 746 Access-Challenge packets, the RADIUS server SHOULD put the 747 desired algorithm into this attribute. 749 3.10. Digest-Entity-Body-Hash Attribute 751 Description 752 When using the qop-level 'auth-int', a hash of the HTTP-style 753 message body's contents is required for digest calculation. 754 Instead of sending the complete body of the message, only its 755 hash value is sent. This hash value can be used directly in 756 the digest calculation. 758 The clarifications described in section 22.4 of [RFC3261] about 759 the hash of empty entity bodies apply to the 760 Digest-Entity-Body-Hash attribute. This attribute MUST only be 761 sent in Access-Request packets. 762 Type 763 112 for Digest-Entity-Body-Hash 764 Length 765 >=3 766 Text 767 The attribute holds the hexadecimal representation of 768 H(entity-body). This hash is required by certain 769 authentication mechanisms, such as HTTP Digest with quality of 770 protection set to "auth-int". RADIUS clients MUST use this 771 attribute to transport the hash of the entity body when HTTP 772 Digest is the authentication mechanism and the RADIUS server 773 requires that the integrity of the entity body (e.g., qop 774 parameter set to "auth-int") be verified. Extensions to this 775 document may define support for authentication mechanisms other 776 than HTTP Digest. 778 3.11. Digest-CNonce Attribute 780 Description 781 This attribute holds the client nonce parameter that is used in 782 the HTTP Digest calculation. It MUST only be used in 783 Access-Request packets. 784 Type 785 113 for Digest-CNonce 786 Length 787 >=3 788 Text 789 This attribute includes the value of the cnonce-value [RFC2617] 790 without surrounding quotes, taken from the HTTP-style request. 792 3.12. Digest-Nonce-Count Attribute 794 Description 795 This attribute includes the nonce count parameter that is used 796 to detect replay attacks. The attribute MUST only be used in 797 Access-Request packets. 799 Type 800 114 for Digest-Nonce-Count 801 Length 802 10 803 Text 804 In Access-Requests, the RADIUS client takes the value of the nc 805 directive (nc-value according to [RFC2617]) without surrounding 806 quotes from the HTTP-style request it wants to authenticate. 808 3.13. Digest-Username Attribute 810 Description 811 This attribute holds the user name used in the HTTP Digest 812 calculation. The RADIUS server MUST use this attribute only 813 for the purposes of calculating the digest. In order to 814 determine the appropriate user credentials, the RADIUS server 815 MUST use the User-Name (1) attribute, and MUST NOT use the 816 Digest-Username attribute. This attribute MUST only be used in 817 Access-Request packets. 818 Type 819 115 for Digest-Username 820 Length 821 >= 3 822 Text 823 In Access-Requests, the RADIUS client takes the value of the 824 username directive (username-value according to [RFC2617]) 825 without surrounding quotes from the HTTP-style request it wants 826 to authenticate. 828 3.14. Digest-Opaque Attribute 830 Description 831 This attribute holds the opaque parameter that is passed to the 832 HTTP-style client. The HTTP-style client will pass this value 833 back to the server (i.e., the RADIUS client) without 834 modification. This attribute MUST only be used in 835 Access-Request and Access-Challenge packets. 836 Type 837 116 for Digest-Opaque 838 Length 839 >=3 840 Text 841 In Access-Requests, the RADIUS client takes the value of the 842 opaque directive (opaque-value according to [RFC2617]) without 843 surrounding quotes from the HTTP-style request it wants to 844 authenticate and puts it into this attribute. In 845 Access-Challenge packets, the RADIUS server MAY include this 846 attribute. 848 3.15. Digest-Auth-Param Attribute 850 Description 851 This attribute is a placeholder for future extensions and 852 corresponds to the "auth-param" parameter defined in section 853 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism 854 whereby the RADIUS client and RADIUS server can exchange 855 auth-param extension parameters contained within Digest headers 856 that are not understood by the RADIUS client and for which 857 there are no corresponding stand-alone attributes. 859 Unlike the previously listed Digest-* attributes, the 860 Digest-Auth-Param contains not only the value but also the 861 parameter name, since the parameter name is unknown to the 862 RADIUS client. If the Digest header contains several unknown 863 parameters, then the RADIUS implementation MUST repeat this 864 attribute and each instance MUST contain one different unknown 865 Digest parameter/value combination. This attribute MUST ONLY 866 be used in Access-Request, Access-Challenge, or Access-Accept 867 packets. 868 Type 869 117 for Digest-Auth-Param 870 Length 871 >=3 872 Text 873 The text consists of the whole parameter, including its name 874 and the equal sign ('=') and quotes. 876 3.16. Digest-AKA-Auts Attribute 878 Description 879 This attribute holds the auts parameter that is used in the 880 Digest AKA ([RFC3310]) calculation. It is only used if the 881 algorithm of the digest-response denotes a version of AKA 882 Digest [RFC3310]. This attribute MUST only be used in 883 Access-Request packets. 884 Type 885 118 for Digest-AKA-Auts 886 Length 887 >=3 888 Text 889 In Access-Requests, the RADIUS client takes the value of the 890 auts directive (auts-param according to section 3.4 of 891 [RFC3310]) without surrounding quotes from the HTTP-style 892 request it wants to authenticate. 894 3.17. Digest-Domain Attribute 896 Description 897 When a RADIUS client has asked for a nonce, the RADIUS server 898 MAY send one or more Digest-Domain attributes in its 899 Access-Challenge packet. The RADIUS client puts them into the 900 quoted, space-separated list of URIs of the 'domain' directive 901 of a WWW-Authenticate header. Together with Digest-Realm, the 902 URIs in the list define the protection space (see [RFC2617], 903 section 3.2.1) for some HTTP-style protocols. This attribute 904 MUST only be used in Access-Challenge packets. 905 Type 906 119 for Digest-Domain 907 Length 908 3 909 Text 910 This attribute consists of a single URI that defines a 911 protection space component. 913 3.18. Digest-Stale Attribute 915 Description 916 This attribute is sent by a RADIUS server in order to notify 917 the RADIUS client whether it has accepted a nonce. If the 918 nonce presented by the RADIUS client was stale, the value is 919 'true' and is 'false' otherwise. The RADIUS client puts the 920 content of this attribute into a 'stale' directive of the 921 WWW-Authenticate header in the HTTP-style response to the 922 request it wants to authenticate. The attribute MUST only be 923 used in Access-Challenge packets. 924 Type 925 120 for Digest-Stale 926 Length 927 3 928 Text 929 The attribute has either the value 'true' or 'false' (both 930 values without surrounding quotes). 932 3.19. Digest-HA1 Attribute 934 Description 935 This attribute is used to allow the generation of an 936 Authentication-Info header, even if the HTTP-style response's 937 body is required for the calculation of the rspauth value. It 938 SHOULD be used in Access-Accept packets if the required quality 939 of protection ('qop') is 'auth-int'. 941 This attribute MUST NOT be sent if the qop parameter was not 942 specified or has a value of 'auth' (in this case, use 943 Digest-Response-Auth instead). 945 The Digest-HA1 attribute MUST only be sent by the RADIUS server 946 or processed by the RADIUS client if at least one of the 947 following conditions is true: 949 + The Digest-Algorithm attribute's value is 'MD5-sess' or 950 'AKAv1-MD5-sess'. 952 + IPsec is configured to protect traffic between RADIUS client 953 and RADIUS server with IPsec (see Section 8). 955 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 +-----+--------+--------+-----------+-----+-------------------------+ 1006 | Req | Accept | Reject | Challenge | # | Attribute | 1007 +-----+--------+--------+-----------+-----+-------------------------+ 1008 | 1 | 0 | 0 | 0 | 1 | User-Name | 1009 | 1 | 1 | 1 | 1 | 80 | Message-Authenticator | 1010 | 0-1 | 0 | 0 | 0 | 103 | Digest-Response | 1011 | 0-1 | 0 | 0 | 1 | 104 | Digest-Realm | 1012 | 0-1 | 0 | 0 | 1 | 105 | Digest-Nonce | 1013 | 0 | 0-1 | 0 | 0 | 106 | Digest-Response-Auth | 1014 | | | | | | (see Note 1, 2) | 1015 | 0 | 0-1 | 0 | 0 | 107 | Digest-Nextnonce | 1016 | 1 | 0 | 0 | 0 | 108 | Digest-Method | 1017 | 0-1 | 0 | 0 | 0 | 109 | Digest-URI | 1018 | 0-1 | 0 | 0 | 0+ | 110 | Digest-Qop | 1019 | 0-1 | 0 | 0 | 0-1 | 111 | Digest-Algorithm (see | 1020 | | | | | | Note 3) | 1021 | 0-1 | 0 | 0 | 0 | 112 | Digest-Entity-Body-Hash | 1022 | 0-1 | 0 | 0 | 0 | 113 | Digest-CNonce | 1023 | 0-1 | 0 | 0 | 0 | 114 | Digest-Nonce-Count | 1024 | 0-1 | 0 | 0 | 0 | 115 | Digest-Username | 1025 | 0-1 | 0 | 0 | 0-1 | 116 | Digest-Opaque | 1026 | 0+ | 0+ | 0 | 0+ | 117 | Digest-Auth-Param | 1027 | 0-1 | 0 | 0 | 0 | 118 | Digest-AKA-Auts | 1028 | 0 | 0 | 0 | 0+ | 119 | Digest-Domain | 1029 | 0 | 0 | 0 | 0-1 | 120 | Digest-Stale | 1030 | 0 | 0-1 | 0 | 0 | 121 | Digest-HA1 (see Note 1, | 1031 | | | | | | 2) | 1032 | 0-1 | 0 | 0 | 0 | 122 | SIP-AOR | 1033 | 0-1 | 0 | 0 | 1 | 24 | State (see Note 4) | 1034 +-----+--------+--------+-----------+-----+-------------------------+ 1036 Table 1 1038 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if 1039 Digest-Qop is 'auth-int'. 1041 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if 1042 Digest-Qop is 'auth'. 1044 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed. 1046 [Note 4] An Access-Challenge MUST contain a State attribute, which is 1047 copied to the subsequent Access-Request. A server receiving an 1048 Access-Request that contains a State attribute MUST respond with 1049 either an Access-Accept or an Access-Reject; the server MUST NOT 1050 respond with an Access-Challenge. 1052 6. Examples 1054 This is an example selected from the traffic between a softphone (A), 1055 a Proxy Server (B), and an example.com RADIUS server (C). The 1056 communication between the Proxy Server and a SIP Public Switched 1057 Telephone Network (PSTN) gateway is omitted for brevity. The SIP 1058 messages are not shown completely. 1060 A->B 1062 INVITE sip:97226491335@example.com SIP/2.0 1063 From: 1064 To: 1066 B->A 1068 SIP/2.0 100 Trying 1070 B->C 1072 Code = 1 (Access-Request) 1073 Attributes: 1074 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1075 NAS-Port-Type = 5 (Virtual) 1076 User-Name = 12345678 1077 Digest-Method = INVITE 1078 Digest-URI = sip:97226491335@example.com 1079 Message-Authenticator = 1080 08 af 7e 01 b6 8d 74 c3 a4 3c 33 e1 56 2a 80 43 1082 C->B 1084 Code = 11 (Access-Challenge) 1085 Attributes: 1086 Digest-Nonce = 3bada1a0 1087 Digest-Realm = example.com 1088 Digest-Qop = auth 1089 Digest-Algorithm = MD5 1090 Message-Authenticator = 1091 f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40 1093 B->A 1095 SIP/2.0 407 Proxy Authentication Required 1096 Proxy-Authenticate: Digest realm="example.com" 1097 ,nonce="3bada1a0",qop=auth,algorithm=MD5 1098 Content-Length: 0 1100 A->B 1102 ACK sip:97226491335@example.com SIP/2.0 1104 A->B 1106 INVITE sip:97226491335@example.com SIP/2.0 1107 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" 1108 ,realm="example.com" 1109 ,response="f3ce87e6984557cd0fecc26f3c5e97a4" 1110 ,uri="sip:97226491335@example.com",username="12345678" 1111 ,qop=auth,algorithm=MD5 1112 From: 1113 To: 1115 B->C 1117 Code = 1 (Access-Request) 1118 Attributes: 1119 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1120 NAS-Port-Type = 5 (Virtual) 1121 User-Name = 12345678 1122 Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4 1123 Digest-Realm = example.com 1124 Digest-Nonce = 3bada1a0 1125 Digest-Method = INVITE 1126 Digest-URI = sip:97226491335@example.com 1127 Digest-Qop = auth 1128 Digest-Algorithm = md5 1129 Digest-Username = 12345678 1130 SIP-AOR = sip:12345678@example.com 1131 Message-Authenticator = 1132 ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff 1134 C->B 1136 Code = 2 (Access-Accept) 1137 Attributes: 1138 Digest-Response-Auth = 1139 6303c41b0e2c3e524e413cafe8cce954 1140 Message-Authenticator = 1141 75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1 1143 B->A 1145 SIP/2.0 180 Ringing 1147 B->A 1148 SIP/2.0 200 OK 1150 A->B 1152 ACK sip:97226491335@example.com SIP/2.0 1154 A second example shows the traffic between a web browser (A), web 1155 server (B), and a RADIUS server (C). 1157 A->B 1159 GET /index.html HTTP/1.1 1161 B->C 1163 Code = 1 (Access-Request) 1164 Attributes: 1165 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1166 NAS-Port-Type = 5 (Virtual) 1167 Digest-Method = GET 1168 Digest-URI = /index.html 1169 Message-Authenticator = 1170 34 a6 26 46 f3 81 f9 b4 97 c0 dd 9d 11 8f ca c7 1172 C->B 1174 Code = 11 (Access-Challenge) 1175 Attributes: 1176 Digest-Nonce = a3086ac8 1177 Digest-Realm = example.com 1178 Digest-Qop = auth 1179 Digest-Algorithm = MD5 1180 Message-Authenticator = 1181 f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40 1183 B->A 1185 HTTP/1.1 401 Authentication Required 1186 WWW-Authenticate: Digest realm="example.com", 1187 nonce="a3086ac8",qop=auth,algorithm=MD5 1188 Content-Length: 0 1190 A->B 1192 GET /index.html HTTP/1.1 1193 Authorization: Digest algorithm=MD5,nonce="a3086ac8" 1194 ,realm="example.com" 1195 ,response="f052b68058b2987aba493857ae1ab002" 1196 ,uri="/index.html",username="12345678" 1197 ,qop=auth,algorithm=MD5 1199 B->C 1201 Code = 1 (Access-Request) 1202 Attributes: 1203 NAS-IP-Address = c0 0 2 26 (192.0.2.38) 1204 NAS-Port-Type = 5 (Virtual) 1205 User-Name = 12345678 1206 Digest-Response = f052b68058b2987aba493857ae1ab002 1207 Digest-Realm = example.com 1208 Digest-Nonce = a3086ac8 1209 Digest-Method = GET 1210 Digest-URI = /index.html 1211 Digest-Username = 12345678 1212 Digest-Qop = auth 1213 Digest-Algorithm = MD5 1214 Message-Authenticator = 1215 06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b 1217 C->B 1219 Code = 2 (Access-Accept) 1220 Attributes: 1221 Digest-Response-Auth = 1222 e644aa513effbfe1caff67103ff6433c 1223 Message-Authenticator = 1224 7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7 1226 B->A 1228 HTTP/1.1 200 OK 1229 ... 1231 1232 ... 1234 7. IANA Considerations 1236 This document serves as an IANA registration request for a number of 1237 values from the RADIUS attribute type number space. The IANA has 1238 assigned the following: 1240 Attribute # 1241 --------------- ---- 1242 Digest-Response 103 1243 Digest-Realm 104 1244 Digest-Nonce 105 1245 Digest-Response-Auth 106 1246 Digest-Nextnonce 107 1247 Digest-Method 108 1248 Digest-URI 109 1249 Digest-Qop 110 1250 Digest-Algorithm 111 1251 Digest-Entity-Body-Hash 112 1252 Digest-CNonce 113 1253 Digest-Nonce-Count 114 1254 Digest-Username 115 1255 Digest-Opaque 116 1256 Digest-Auth-Param 117 1257 Digest-AKA-Auts 118 1258 Digest-Domain 119 1259 Digest-Stale 120 1260 Digest-HA1 121 1261 SIP-AOR 122 1263 8. Security Considerations 1265 The RADIUS extensions described in this document enable RADIUS to 1266 transport the data that is required to perform a digest calculation. 1267 As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see 1268 [RFC2617], section 4) in addition to RADIUS security vulnerabilities 1269 described in [RFC2865], section 8, and [RFC3579], section 4. 1271 An attacker compromising a RADIUS client or proxy can carry out man- 1272 in-the-middle attacks even if the paths between A, B and B, C (Figure 1273 2) have been secured with TLS or IPsec. 1275 The RADIUS server MUST check the Digest-Realm attribute it has 1276 received from a client. If the RADIUS client is not authorized to 1277 serve HTTP-style clients of that realm, it might be compromised. 1279 8.1. Denial of Service 1281 RADIUS clients implementing the extension described in this document 1282 may authenticate HTTP-style requests received over the Internet. As 1283 compared with the use of RADIUS to authenticate link-layer network 1284 access, attackers may find it easier to cover their tracks in such a 1285 scenario. 1287 An attacker can attempt a denial-of-service attack on one or more 1288 RADIUS servers by sending a large number of HTTP-style requests. To 1289 make simple denial-of-service attacks more difficult, the RADIUS 1290 server MUST check whether it has generated the nonce received from an 1291 HTTP-style client. This SHOULD be done statelessly. For example, a 1292 nonce could consist of a cryptographically random part and some kind 1293 of signature provided by the RADIUS client, as described in 1294 [RFC2617], section 3.2.1. 1296 8.2. Confidentiality and Data Integrity 1298 The attributes described in this document are sent in cleartext. 1299 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm 1300 attributes in Access-Challenge messages. A man in the middle can 1301 modify or remove those attributes in a bidding down attack, causing 1302 the RADIUS client to use a weaker authentication scheme than 1303 intended. 1305 The Message-Authenticator attribute, described in [RFC3579], section 1306 3.2 MUST be included in Access-Request, Access-Challenge, Access- 1307 Reject, and Access-Accept messages that contain attributes described 1308 in this specification. 1310 The Digest-HA1 attribute contains no random components if the 1311 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary 1312 attacks easier and enables replay attacks. 1314 Some parameter combinations require the protection of RADIUS packets 1315 against eavesdropping and tampering. Implementations SHOULD try to 1316 determine automatically whether IPsec is configured to protect 1317 traffic between the RADIUS client and the RADIUS server. If this is 1318 not possible, the implementation checks a configuration parameter 1319 telling it whether IPsec will protect RADIUS traffic. The default 1320 value of this configuration parameter tells the implementation that 1321 RADIUS packets will not be protected. 1323 HTTP-style clients can use TLS with server side certificates together 1324 with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, 1325 too. TLS or IPsec secure the connection while Digest Authentication 1326 authenticates the user. The RADIUS transaction can be regarded as 1327 one leg on the path between the HTTP-style client and the HTTP-style 1328 server. To prevent RADIUS from representing the weak link, a RADIUS 1329 client receiving an HTTP-style request via TLS or IPsec could use an 1330 equally secure connection to the RADIUS server. There are several 1331 ways to achieve this, for example: 1333 o The RADIUS client may reject HTTP-style requests received over TLS 1334 or IPsec. 1336 o The RADIUS client may require that traffic be sent and received 1337 over IPsec. 1339 RADIUS over IPsec, if used, MUST conform to the requirements 1340 described in [RFC3579], section 4.2. 1342 9. References 1344 9.1. Normative References 1346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1347 Requirement Levels", BCP 14, RFC 2119, March 1997. 1349 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1350 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 1351 Basic and Digest Access Authentication", RFC 2617, June 1999. 1353 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1354 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1355 2000. 1357 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1358 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1359 Session Initiation Protocol", RFC 3261, June 2002. 1361 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1362 In User Service) Support For Extensible Authentication 1363 Protocol (EAP)", RFC 3579, September 2003. 1365 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 1366 3966, December 2004. 1368 9.2. Informative References 1370 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol 1371 (CHAP)", RFC 1994, August 1996. 1373 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 1374 Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP 1375 : Digest Access Authentication", RFC 2069, January 1997. 1377 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1378 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1380 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 1381 (S/MIME) Version 3.1 Message Specification", RFC 3851, July 1382 2004. 1384 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1385 Protocol (HTTP) Digest Authentication Using Authentication and 1386 Key Agreement (AKA)", RFC 3310, September 2002. 1388 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1389 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1391 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- 1392 Valenzuela, C. and K. Tammik, "Diameter Session Initiation 1393 Protocol (SIP) Application", RFC 4740, November 2006. 1395 Acknowledgments 1397 We would like to acknowledge Kevin McDermott (Cisco Systems) for 1398 providing comments and experimental implementation. 1400 Many thanks to all reviewers, especially to Miguel Garcia, Jari 1401 Arkko, Avi Lior, and Jun Wang. 1403 Authors' Addresses 1405 Baruch Sterman 1406 Kayote Networks 1407 P.O. Box 1373 1408 Efrat 90435 1409 Israel 1411 EMail: baruch@kayote.com 1413 Daniel Sadolevsky 1414 SecureOL, Inc. 1415 Jerusalem Technology Park 1416 P.O. Box 16120 1417 Jerusalem 91160 1418 Israel 1420 EMail: dscreat@dscreat.com 1422 David Schwartz 1423 Kayote Networks 1424 P.O. Box 1373 1425 Efrat 90435 1426 Israel 1428 EMail: david@kayote.com 1430 David Williams 1431 Cisco Systems 1432 7025 Kit Creek Road 1433 P.O. Box 14987 1434 Research Triangle Park NC 27709 1435 USA 1437 EMail: dwilli@cisco.com 1439 Wolfgang Beck 1440 Deutsche Telekom AG 1441 Deutsche Telekom Allee 7 1442 Darmstadt 64295 1443 Germany 1445 EMail: beckw@t-systems.com 1447 Appendix A - Changes from RFC 4590 1449 This Appendix lists the major changes between [RFC4590] and this 1450 document. Minor changes, including style, grammar, spelling, and 1451 editorial changes are not mentioned here. 1453 Intellectual Property Statement 1455 The IETF takes no position regarding the validity or scope of any 1456 Intellectual Property Rights or other rights that might be claimed to 1457 pertain to the implementation or use of the technology described in 1458 this document or the extent to which any license under such rights 1459 might or might not be available; nor does it represent that it has 1460 made any independent effort to identify any such rights. Information 1461 on the procedures with respect to rights in RFC documents can be 1462 found in BCP 78 and BCP 79. 1464 Copies of IPR disclosures made to the IETF Secretariat and any 1465 assurances of licenses to be made available, or the result of an 1466 attempt made to obtain a general license or permission for the use of 1467 such proprietary rights by implementers or users of this 1468 specification can be obtained from the IETF on-line IPR repository at 1469 http://www.ietf.org/ipr. 1471 The IETF invites any interested party to bring to its attention any 1472 copyrights, patents or patent applications, or other proprietary 1473 rights that may cover technology that may be required to implement 1474 this standard. Please address the information to the IETF at ietf- 1475 ipr@ietf.org. 1477 Disclaimer of Validity 1479 This document and the information contained herein are provided on an 1480 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1481 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1482 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1483 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1484 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1485 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1487 Copyright Statement 1489 Copyright (C) The IETF Trust (2007). This document is subject to the 1490 rights, licenses and restrictions contained in BCP 78, and except as 1491 set forth therein, the authors retain all their rights. 1493 Acknowledgment 1495 Funding for the RFC Editor function is currently provided by the 1496 Internet Society. 1498 Open issues 1500 Open issues relating to this specification are tracked on the 1501 following web site: 1503 http://www.drizzle.com/~aboba/RADEXT/