idnits 2.17.00 (12 Aug 2021) /tmp/idnits17673/draft-neumann-dime-webauth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 206 has weird spacing: '...tweight and e...' == Line 212 has weird spacing: '...tection for s...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 4694 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) ** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Neumann 3 Internet-Draft X. Fu 4 Expires: January 14, 2010 University of Goettingen 5 July 13, 2009 7 Diameter Application for Authentication and Authorization in Web 8 Applications 9 draft-neumann-dime-webauth-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 14, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies the Diameter Application for Authentication 48 and Authorization in Web Applications (Diameter WebAuth). This 49 Diameter application is intended to be used by Diameter clients to 50 perform authentication and authorization operations with a Diameter 51 server in web-based environments. It provides facilities to allow 52 web sites to authenticate their web user clients using a number of 53 (HTTP) authentication schemes. In addition, it supports user 54 authorization using dedicated service identifiers. Diameter WebAuth 55 may also be used by non web-based Diameter clients and servers that 56 require a lightweight authentication and authorization Diameter 57 application. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Motivation and Goals . . . . . . . . . . . . . . . . . . . 4 63 1.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.2.1. A web site wants to authenticate a user . . . . . . . 6 65 1.2.2. A web site wants to authorize a user for a 66 specific service . . . . . . . . . . . . . . . . . . . 6 67 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 68 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 69 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 2.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 71 2.1.1. HTTP Basic Authentication . . . . . . . . . . . . . . 8 72 2.1.2. HTTP Digest Authentication . . . . . . . . . . . . . . 8 73 2.1.2.1. Quick Mode . . . . . . . . . . . . . . . . . . . . 9 74 2.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 75 2.3. Advertising Application Support . . . . . . . . . . . . . 11 76 3. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.1. AA-Request (AAR) Command . . . . . . . . . . . . . . . . . 11 78 3.2. AA-Answer (AAA) Command . . . . . . . . . . . . . . . . . 12 79 4. Diameter WebAuth AVPs . . . . . . . . . . . . . . . . . . . . 13 80 4.1. Authentication AVPs . . . . . . . . . . . . . . . . . . . 13 81 4.1.1. WebAuth-Authentication-Type AVP . . . . . . . . . . . 13 82 4.2. Authorization AVPs . . . . . . . . . . . . . . . . . . . . 14 83 4.2.1. WebAuth-Authorization-Request AVP . . . . . . . . . . 14 84 4.2.2. WebAuth-URI AVP . . . . . . . . . . . . . . . . . . . 15 85 4.2.3. WebAuth-Service AVP . . . . . . . . . . . . . . . . . 15 86 4.2.4. Remote-User AVP . . . . . . . . . . . . . . . . . . . 15 87 4.2.5. Remote-Address AVP . . . . . . . . . . . . . . . . . . 15 88 4.3. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 15 89 4.4. Diameter Network Access Server Application AVPs . . . . . 17 90 4.5. HTTP-Digest Authentication AVPs . . . . . . . . . . . . . 17 91 4.5.1. HTTP-Digest-Challenge AVP . . . . . . . . . . . . . . 17 92 4.5.2. HTTP-Digest-Response AVP . . . . . . . . . . . . . . . 17 93 4.5.3. HTTP-Authentication-Info AVP . . . . . . . . . . . . . 18 94 4.5.4. HTTP Digest AVPs . . . . . . . . . . . . . . . . . . . 18 95 4.6. Diameter Credit-Control Application AVPs . . . . . . . . . 19 96 4.6.1. Other Credit-Control Application AVPs . . . . . . . . 19 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 98 5.1. Application Identifier . . . . . . . . . . . . . . . . . . 20 99 5.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 100 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 20 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 102 7.1. HTTP Basic Authentication . . . . . . . . . . . . . . . . 22 103 7.2. HTTP Digest Authentication . . . . . . . . . . . . . . . . 23 104 7.2.1. Digest Quick Mode . . . . . . . . . . . . . . . . . . 23 105 7.3. Renegade or Compromised WebAuth Clients . . . . . . . . . 24 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 107 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 108 8.2. Informative References . . . . . . . . . . . . . . . . . . 26 109 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 26 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 112 1. Introduction 114 This document describes the Diameter Application for Authentication 115 and Authorization in Web Applications (Diameter WebAuth). The 116 intended area of application for Diameter WebAuth are web 117 applications that want to utilize a Diameter server for 118 authentication and authorization of their users. It enables a 119 Diameter server to supply web sites that implement a Diameter WebAuth 120 client with data to authenticate its user via common HTTP 121 authentication methods. Furthermore, it allows the Diameter client 122 to authorize the access to resources or services provided by the web 123 site. 125 A relevant usage scenario of Diameter WebAuth is deployment in 126 Identity Management Frameworks where there may be different trust 127 relationships between the user, the web application server and the 128 authentication server. This means 130 1. No re-usable authentication credentials are shared with the web 131 application server, 133 2. The authentication server can hold back authentication or 134 authorization information until they are actually needed by the 135 web application server. 137 Diameter WebAuth specifically addresses the authentication and 138 authorization requirements for the purpose of Identity Management. 140 Diameter WebAuth does not rely on other Diameter applications and is 141 intended to be lightweight and straightforward. This makes it 142 feasible in resource-constrained environments, such as authentication 143 and authorization within embedded systems. 145 1.1. Motivation and Goals 147 Several Diameter applications have been defined for various services, 148 like network access ([RFC4005]), Mobile IP ([RFC4004]) or the Session 149 Initiation Protocol ([RFC4740]). The existing applications however 150 are not particularly designed for the use in combination with web 151 applications, many of which require authentication and authorization. 152 Specifically, they do not offer methods suitable for authentication 153 and authorization in a web-based environment, for example the HTTP 154 Digest Authentication. Or they are intended for other applications 155 and require extensive and complex implementation work which, however, 156 is not needed for the intended use in web-based environments. Web 157 applications (or web servers itself for that matter), therefore, 158 implement proprietary authentication back-ends or use services that 159 are not primarily designed for extensive authentication operations. 161 Such services are, for example, LDAP servers, database servers or 162 IMAP servers. This is often the case, even though there is an AAA 163 service like Diameter available within their administrative domain. 164 The objective of this document is to specify a Diameter application 165 that allows web servers and web applications to utilize a Diameter 166 AAA infrastructure for authentication and authorization purposes. 168 Diameter WebAuth allows for a Diameter client and a Diameter server 169 to be located either in the same or in different administrative 170 domains. This allows for three party scenarios, for example, an end- 171 user that has signed up with a dedicated identity management provider 172 that operates a Diameter infrastructure providing authentication 173 services for web application providers. As shown in Figure 1 in such 174 three party scenarios, the end-user has a profound trust relationship 175 with the identity management provider but not with the provider of 176 the service he is accessing. Therefore special attention has to be 177 paid to assuring the privacy of the end-user towards the application 178 service provider while enabling the service provider to render its 179 service. 180 +------------+ 181 +--------| Web | 182 Authentication services -> |Diameter| Application| 183 +-------------------------- | Client | Provider | 184 | *Trust relationship* +--------+------------+ 185 | |Web | 186 | |Server| 187 +--------+ +------+ 188 |Diameter| | 189 | Server | | 190 +------------+ | *no* 191 | Identity | Application| Trust 192 | Management | Services | relationship 193 | Provider | | | 194 +------------+ v | 195 | +------+ 196 | |Web | 197 | |Client| 198 | Identity management -> +------------+ 199 +------------------------------------| End user | 200 *Trust relationship* +------------+ 202 Figure 1: Trust relationships in a three party scenario 204 Overall, the goals for this Diameter application are as follows: 206 Lightweight and easy to implement in Diameter clients as well as 207 Diameter servers. Examples for Diameter clients this application 208 is intended for, are web servers and web applications. In 209 general, every entity that provides services using a web-based 210 user interface. 212 Secure and Privacy protection for scenarios where the Diameter 213 server and the Diameter client are not part of the same 214 administrative Domain. This is, for example, the case when the 215 Diameter server is operated by a third party such as an identity 216 management provider. 218 1.2. Use cases 220 This section describes a number of typical use cases that this 221 document is intended to cover. Those are authentication and 222 authorization of a user by a web server or a web application. 224 1.2.1. A web site wants to authenticate a user 226 A user accessing a web site needs to be authenticated in order to 227 link him to an identity. This can be necessary, for example, if a 228 returning visitor ought to be matched to his profile or if access to 229 the site is limited to registered users only. Authentication is also 230 necessary to establish the identity of a user in order to perform 231 service-specific authorization. 233 1.2.2. A web site wants to authorize a user for a specific service 235 A resource that is requested by a user requires special access 236 privileges. The web site needs to authorize the user for this 237 resource before allowing him access. It is possible for the web site 238 to maintain different areas with different access requirements so 239 that authorization needs to be repeated for different services and 240 can yield different results. 242 1.3. Terminology 244 Basic Authentication: Verifying a users identity based on a plain 245 text password and user name. 247 User Client: End user client which is used to access the resource on 248 the protected server. Usually a web browser accessing a web 249 server. 251 Web Application: A computer program that is accessed via a web 252 interface. Usually served by an application server or a web 253 server. 255 Web Site: A collection of web pages that are intended to be accessed 256 by a web browser. They can be statically served by a web server 257 or dynamically generated by a web application. 259 1.4. Requirements Language 261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 263 document are to be interpreted as described in RFC 2119 [RFC2119]. 265 2. Overview 267 Diameter WebAuth provides a web server with the means to utilize an 268 AAA infrastructure to authenticate and authorize its users for the 269 access to its resources and services. The following sections detail 270 these functions. 272 2.1. Authentication 274 Diameter WebAuth extends the facilities provided by the Diameter Base 275 Protocol for a Diameter client to authenticate a user. Two 276 requirements are to be kept regarding the authentication. First, 277 Diameter WebAuth must use standard authentication methods that are 278 supported by the user client. The reason for that is, that Diameter 279 WebAuth only specifies the protocol between the Diameter client and 280 the Diameter server. It cannot alter or adjust the service specific 281 protocol between the user client and the Diameter client, HTTP in 282 this case. The second requirement is that the authentication method 283 needs to provide protection against unauthorized access to secret 284 credentials. In case of username/password authentication this would 285 be the password. Particularly this means that in scenarios where the 286 Diameter client is outside the trust domain of the Diameter server, 287 the secret credentials needs to be protected against the Diameter 288 client itself. 290 The most common authentication method supported by web browsers is 291 username/password authentication. RFC 2617 [RFC2617] specifies two 292 HTTP authentication methods which are widely supported by web 293 browsers: Basic Authentication and Digest Access Authentication. 294 While the basic authentication exchanges the credentials including 295 the password in cleartext, the digest access authentication uses a 296 one-way hash function to prevent sending the password in cleartext. 297 Although the digest authentication is not intended to be an 298 absolutely secure authentication scheme, it serves the purpose of 299 protecting the user password against snooping by any entity between 300 the user client and the authenticator, which in this case would be 301 the Diameter server. Besides HTTP digest access authentication, 302 Diameter WebAuth will, nevertheless, support basic authentication as 303 well. It can be used as a fall back in environments where digest 304 authentication is not available or not necessary and to more 305 generally support different authentication mechanisms, for example, 306 HTML-form-based authentication. The authentication methods supported 307 by this document are detailed in the following sections. 309 2.1.1. HTTP Basic Authentication 311 HTTP Basic Authentication as described in [RFC2617] is used when the 312 WebAuth-Authentication-Type AVP is set to HTTP_BASIC in an AA-Request 313 message. The HTTP basic authentication scheme uses a plain username/ 314 password combination for authentication. The client, therefore has 315 to include a User-Name AVP and a User-Password AVP in the request. 316 The Diameter server replies with an AA-Answer which MUST include a 317 WebAuth-Authentication-Type AVP also set to HTTP_BASIC and the result 318 of the request. The Diameter server replies with an AA-Answer 319 message that includes a copy of the User-Name AVP and has its Result- 320 Code AVP set to DIAMETER_SUCCESS if the username/password could be 321 verified and DIAMETER_AUTHENTICATION_REJECTED otherwise. 323 2.1.2. HTTP Digest Authentication 325 HTTP Basic Authentication as described in [RFC2617] is used when the 326 WebAuth-Authentication-Type AVP is set to HTTP_DIGEST in an AA- 327 Request message. The HTTP digest authentication scheme uses a 328 challenge/response mechanism, therefore, multiple protocol round- 329 trips are needed. An example of an authentication session using the 330 HTTP digest authentication scheme is shown in Figure 2. When a user 331 client sends a request for a protected resource without including any 332 credentials (1.), the Diameter client starts the authentication 333 process. it sends an AA-Request to the Diameter server (2.) which 334 includes a WebAuth-Authentication-Type AVP is set to HTTP_DIGEST. 335 The Diameter server then generates a HTTP-Digest-Challenge AVP and 336 sends it to the client in an AA-Answer with the Result-Code AVP set 337 to DIAMETER_MULTI_ROUND_AUTH (3.). Using the credentials provided by 338 the Diameter server, the Diameter client can construct an HTTP 339 response with the appropriate WWW-Authenticate header and send it to 340 the web user client (4.) to challenge an authentication. Next, the 341 client assembles his authentication credentials and sends another 342 request to the web server (5.) including the user's credentials. The 343 Diameter client assembles an AA-Request to the Diameter server with 344 the corresponding information from the clients request (6.). If the 345 credentials match the records in the Diameter server, it returns an 346 AA-Answer with the Result-Code AVP set to DIAMETER_SUCCESS (7.). 347 After receiving a positive authentication response, the web server 348 can respond to the user clients request (8.) and grant access to the 349 protected resource. 350 +--------+ +--------+ +--------+ 351 | User | (HTTP/S) |Diameter| (Diameter) |Diameter| 352 | Client | <---------------> | Client | <----------------> | Server | 353 +--------+ +--------+ +--------+ 354 | | | 355 | 1. GET /index.html | | 356 |--------------------------->| 2. AA-Request | 357 | |---------------------------->| 358 | | 3. AA-Answer | 359 | | (DIAMETER_MULTI_ROUND_AUTH)| 360 | 4. 401 Unauthorized |<----------------------------| 361 | (WWW-Authenticate: ...) | | 362 |<---------------------------| | 363 | 5. GET /index.html | | 364 | (Authorization: ...) | | 365 |--------------------------->| 6. AA-Request | 366 | |---------------------------->| 367 | | 7. AA-Answer | 368 | | (DIAMETER_SUCCESS) | 369 | 8. 200 OK |<----------------------------| 370 |<---------------------------| | 371 | | | 372 | | | 374 Figure 2: Diameter WebAuth using HTTP digest authentication 376 2.1.2.1. Quick Mode 378 Because the HTTP digest authentication scheme uses a challenge/ 379 response mechanism, usually at least two protocol round trips are 380 necessary: one to exchange the challenge and one for the response. 381 Besides the obvious additional costs in time, network utilization and 382 processing power this also obligates the Diameter server to maintain 383 a session with an associated state for the authentication procedure. 384 Although each Diameter application implementing this document MUST 385 support the HTTP digest authentication as described above, they CAN 386 employ facilities to speed up the authentication and reduce the 387 necessary protocol round trips to one. If Diameter server and 388 Diameter client both implement and apply these facilities we call 389 this the HTTP digest quick mode. 391 The HTTP digest quick mode aims at reducing the number of protocol 392 round trips by prematurely including information that is usually 393 exchanged in a subsequent round trip. If Diameter server and 394 Diameter client employ these facilities there are a number of 395 security relevant compromises implied that are discussed in Section 396 Section 7.2.1. 398 In order for a Diameter client to offer a quick mode digest 399 authentication to the Diameter server it will generate the digest 400 nonce itself and do the HTTP authentication with the user client 401 based on this nonce. Therefore it can start the Diameter WebAuth 402 session with an AA-Request that includes a complete HTTP-Digest- 403 Response AVP. The Diameter server can chose to continue the 404 authentication process using this AVP as if the request was following 405 an AA-Answer which included a server-generated HTTP-Digest-Challenge 406 AVP. If the Diameter server does not want to agree on using the 407 client side initiated quick mode, it MUST process the AA-Request as 408 if it is an initial request and ignore the HTTP-Digest-Response AVP. 409 Consequently, a Diameter client starting a digest quick mode 410 authentication MUST anticipate the server not to agree on the quick 411 mode and to reply with an AA-Answer containing a HTTP-Digest- 412 Challenge AVP. 414 The server side quick mode is employed by a Diameter server by 415 including a Digest-HA1 AVP in the HTTP-Digest-Challenge AVP in its 416 AA-Answer. The Digest-HA1 AVP contains the H(A1) value as defined in 417 [RFC2617] and allows the Diameter client to verify the user client's 418 HTTP authentication response directly and without the need for 419 another Diameter message exchange. The drawback of the server 420 initiated quick mode is that the server will not get a message about 421 the outcome of the authentication process. It therefore CANNOT 422 assume the authentication to be successful. Also, similar to the 423 client initiated quick mode, the Diameter server MUST anticipate the 424 client not to agree on the quick mode and replying to the AA-Answer 425 with another AA-Request that includes a HTTP-Digest-Response AVP with 426 the user client's response to the authentication challenge. 428 2.2. Authorization 430 To facilitate different roles and access levels, this document adopts 431 the specification of services made in RFC 4006 [RFC4006], namely the 432 Service-Context-Id and Service-Identifier AVPs. The service 433 identifiers can be used by web applications to request user 434 differentiated authorization. The Diameter credit-control 435 application introduces service description based on a service context 436 identifier combined with a service identifier. While the service 437 context identifier is used to describe the service specific document 438 that applies to the request, the service identifier designates the 439 exact service within that document. 441 2.3. Advertising Application Support 443 Diameter nodes conforming to this document MUST advertise support by 444 including the value of TBD in the Auth-Application-Id of the 445 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 446 command defined in [RFC3588]. 448 3. Command Codes 450 This section defines the Diameter message Command-Code values that 451 MUST be supported by all Diameter implementations conforming to this 452 document. The Command Codes are as follows: 454 +--------------+---------+------+-------------+ 455 | Command-Name | Abbrev. | Code | Reference | 456 +--------------+---------+------+-------------+ 457 | AA-Request | AAR | 265 | Section 3.1 | 458 | AA-Answer | AAA | 265 | Section 3.2 | 459 +--------------+---------+------+-------------+ 461 3.1. AA-Request (AAR) Command 463 The AA-Request (AAR) command is specified in RFC 4005, Section 3.1. 464 [RFC4005] and It is used by the Diameter client to request 465 authentication and/or authorization for its user. 467 If authentication is requested, depending on the authentication 468 scheme and the sequence of requests different attributes MUST be 469 present: User-Name and User-Password for basic authentication and a 470 HTTP-Digest-Response if it is an AA-Request following an AA-Answer 471 with its Result-Code set to DIAMETER_MULTI_ROUND_AUTH and including a 472 HTTP-Digest-Challenge. 474 If authorization is requested, the Service-Context-Id and Service- 475 Identifier attributes are used to identify the service for which 476 authorization is requested. If these attributes are missing in the 477 request and the Auth-Request-Type attribute is set to 478 AUTHORIZE_AUTHENTICATE, the Diameter server SHOULD handle the request 479 as if authorization has not been requested. 481 The AA-Request command has the following ABNF grammar (AVPs not 482 required by this document are omitted): 484 ::= < Diameter Header: 265, REQ, PXY > 485 < Session-Id > 486 { Auth-Application-Id } 487 { Origin-Host } 488 { Origin-Realm } 489 { Destination-Realm } 490 { Auth-Request-Type } 491 { WebAuth-Authentication-Type } 492 [ User-Name ] 493 [ User-Password ] 494 [ HTTP-Digest-Response ] 495 [ Destination-Host ] 496 [ Service-Context-Id ] 497 [ Service-Identifier ] 498 * [ Proxy-Info ] 499 * [ Route-Record ] 500 * [ AVP ] 502 3.2. AA-Answer (AAA) Command 504 The AA-Answer (AAA) command is specified in RFC 4005, Section 3.2. 505 [RFC4005] and is sent by the Diameter server in response to an AA- 506 Request. 508 If the AA-Answer is a response to a AA-Request initiating a digest 509 authentication, the Result-Code AVP MUST be set to 510 DIAMETER_MULTI_ROUND_AUTH and a HTTP-Digest-Challenge AVP MUST be 511 present. If the AA-Answer is a response to an authorization request, 512 the Service-Context-Id and Service-Identifier attributes identifying 513 the service for which authorization is granted or denied MUST be 514 present. 516 The Web-Authentication-Request command has the following ABNF grammar 517 (AVPs not required by this document are omitted): 519 ::= < Diameter Header: 265, PXY > 520 < Session-Id > 521 { Auth-Application-Id } 522 { Auth-Request-Type } 523 { Result-Code } 524 { Origin-Host } 525 { Origin-Realm } 526 { WebAuth-Authentication-Type } 527 [ User-Name ] 528 [ HTTP-Digest-Challenge ] 529 [ HTTP-Authentication-Info ] 530 [ Service-Context-Id ] 531 [ Service-Identifier ] 532 * [ Proxy-Info ] 533 * [ AVP ] 535 4. Diameter WebAuth AVPs 537 This section provides a listing of the AVPs used in Diameter WebAuth 538 commands and their values. 540 4.1. Authentication AVPs 542 Diameter WebAuth defines a new authentication AVP, namely the 543 WebAuth-Authentication-Type AVP, which is described below. 545 4.1.1. WebAuth-Authentication-Type AVP 547 The WebAuth-Authentication-Type AVP (AVP Code TBD) is of type 548 Enumerated. In an AA-Request it indicates the type of authentication 549 mechanism that is requested by the client while in an AA-Answer it 550 indicates the authentication mechanism the Diameter server used to 551 answer the initial request. The Diameter server MUST always use the 552 authentication type requested by the client in the request. The AVP 553 is mirrored in the answer to allow the client to be stateless 554 regarding the authentication type. 556 A Diameter server is not required to support all of the 557 authentication types. An unsupported authentication type can for 558 example not be implemented in the server or be disabled by a 559 configuration option due to security or policy constraints. If an 560 unknown or unsupported WebAuth-Authentication-Type is received in an 561 AA-Request, the Diameter server MUST reply with an AA-Answer with its 562 Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE including a copy of 563 the WebAuth-Authentication-Type AVP. 565 The following values are defined for the WebAuth-Authentication-Type 566 AVP: 568 HTTP_BASIC (0) 569 HTTP basic authentication as described in [RFC2617]. 571 HTTP_DIGEST (1) 572 HTTP digest authentication as described in [RFC2617]. 574 4.2. Authorization AVPs 576 Diameter WebAuth defines two new AVP used for authorization purposes, 577 namely the WebAuth-Authorization-Request and WebAuth-Authorization- 578 Response AVPs. The AVPs are described below. 580 4.2.1. WebAuth-Authorization-Request AVP 582 The WebAuth-Authorization-Request AVP is send by a client inside an 583 AA-Request which has its Auth-Request-Type AVP set to either 584 AUTHORIZE_ONLY or AUTHORIZE_AUTHENTICATE. If a WebAuth- 585 Authorization-Request AVP is present in such a request, it indicates 586 to the Diameter server, that the client wants to authorize its user 587 based on the values included in the AVP. The Diameter server 588 processes the request according to its configuration and includes an 589 appropriate Result-Code AVP in a subsequent AA-Response. 591 The exact manner in which the Diameter server processes the 592 authorization request is implementation and configuration dependent. 593 For example, the Diameter server can take every data that is provided 594 within the WebAuth-Authorization-Request AVP into account and only 595 grant authorization when the user qualifies for each and every one. 596 Opposed to that, the Diameter server can also authorize the user if 597 only one of the conditions is met. The definite authorization 598 procedure is expected to be arranged between the Diameter client 599 provider and the Diameter server provider. 601 The WebAuth-Authorization-Request AVP is of type Grouped and has the 602 following ABNF grammar: 603 WebAuth-Authorization-Request ::= < AVP Header: TBD > 604 [ WebAuth-URI ] 605 [ WebAuth-Service ] 606 [ Remote-User ] 607 [ User-Name ] 608 [ Remote-Address ] 609 * [ AVP ] 611 4.2.2. WebAuth-URI AVP 613 The WebAuth-URI AVP (AVP Code TBD) is of type UTF8String and contains 614 the URI the user tried to access when the authorization was triggered 615 by the Diameter client as described in RFC 1738. 617 4.2.3. WebAuth-Service AVP 619 The WebAuth-Service AVP (AVP Code TBD is of type UTF8String and 620 contains a name or identifier for the service the Diameter client 621 wants to authorize the user for. The valid service names or 622 identifiers are prearranged between the Web application provider and 623 the Diameter server provider. 625 4.2.4. Remote-User AVP 627 The Remote-User AVP (AVP Code TBD) is of type UTF8String and contains 628 the identification of the remote user that is trying to access the 629 service for which the Diameter client is requesting the 630 authorization. Contrary to the User-Name AVP the value in this AVP 631 can have been obtained by the Diameter client by Diameter-external 632 means. 634 4.2.5. Remote-Address AVP 636 The Remote Address AVP (AVP code TBD) is of type Address and contains 637 the network address (e.g. IPv4 or IPv6 address) of the remote user 638 that is trying to access the service for which the Diameter client is 639 requesting authorization. 641 4.3. Diameter Base Protocol AVPs 643 This Diameter application uses the following AVPs specified in 644 RFC 3588 [RFC3588]: 646 +------------------------+------+------------------+----------------+ 647 | Attribute Name | AVP | Value Type | Reference | 648 | | Code | | | 649 +------------------------+------+------------------+----------------+ 650 | Origin-Host | 264 | DiameterIdentity | RFC 3588, | 651 | | | | Section 6.3. | 652 | | | | [RFC3588] | 653 | Origin-Realm | 296 | DiameterIdentity | RFC 3588, | 654 | | | | Section 6.4. | 655 | | | | [RFC3588] | 656 | Destination-Host (??) | 293 | DiameterIdentity | RFC 3588, | 657 | | | | Section 6.5. | 658 | | | | [RFC3588] | 659 | Destination-Realm | 283 | DiameterIdentity | RFC 3588, | 660 | | | | Section 6.6. | 661 | | | | [RFC3588] | 662 | Auth-Application-Id | 258 | Unsigned32 | RFC 3588, | 663 | | | | Section 6.8. | 664 | | | | [RFC3588] | 665 | Acct-Application-Id | 259 | Unsigned32 | RFC 3588, | 666 | | | | Section 6.9. | 667 | | | | [RFC3588] | 668 | Result-Code | 268 | Unsigned32 | RFC 3588, | 669 | | | | Section 7.1. | 670 | | | | [RFC3588] | 671 | Auth-Request-Type | 274 | Enumerated | RFC 3588, | 672 | | | | Section 8.7. | 673 | | | | [RFC3588] | 674 | Session-Id | 263 | UTF8String | RFC 3588, | 675 | | | | Section 8.8. | 676 | | | | [RFC3588] | 677 | Authorization-Lifetime | 291 | Unsigned32 | RFC 3588, | 678 | | | | Section 8.9. | 679 | | | | [RFC3588] | 680 | Auth-Grace-Period | 276 | Unsigned32 | RFC 3588, | 681 | | | | Section 8.10. | 682 | | | | [RFC3588] | 683 | Auth-Session-State | 277 | Enumerated | RFC 3588, | 684 | | | | Section 8.11. | 685 | | | | [RFC3588] | 686 | User-Name | 1 | UTF8String | RFC 3588, | 687 | | | | Section 8.14. | 688 | | | | [RFC3588] | 689 | Event-Timestamp | 55 | Time | RFC 3588, | 690 | | | | Section 8.21. | 691 | | | | [RFC3588] | 692 +------------------------+------+------------------+----------------+ 694 4.4. Diameter Network Access Server Application AVPs 696 This Diameter application uses the following AVPs specified in 697 RFC 4005 [RFC4005]: 699 +---------------+---------+-------------+---------------------------+ 700 | Attribute | AVP | Value Type | Reference | 701 | Name | Code | | | 702 +---------------+---------+-------------+---------------------------+ 703 | User-Password | 2 | OctetString | RFC 4005, Section 5.1. | 704 | | | | [RFC4005] | 705 +---------------+---------+-------------+---------------------------+ 707 4.5. HTTP-Digest Authentication AVPs 709 The following section describes the AVPs used for the HTTP-Digest 710 Authentication in Web-Auth-Request and Web-Auth-Response commands. 712 4.5.1. HTTP-Digest-Challenge AVP 714 The HTTP-Digest-Challenge AVP is identical to the SIP-Authenticate 715 AVP specified in RFC 4740, Section 9.5.3. [RFC4740] and is renamed 716 here for descriptive reasons. 718 The HTTP-Digest-Challenge AVP has the following ABNF grammar: 719 HTTP-Digest-Challenge ::= < AVP Header: 379 > 720 { Digest-Realm } 721 { Digest-Nonce } 722 [ Digest-Domain ] 723 [ Digest-Opaque ] 724 [ Digest-Stale ] 725 [ Digest-Algorithm ] 726 [ Digest-QoP ] 727 [ Digest-HA1] 728 * [ Digest-Auth-Param ] 729 * [ AVP ] 731 4.5.2. HTTP-Digest-Response AVP 733 The HTTP-Digest-Response AVP is identical to the SIP-Authorization 734 AVP specified in RFC 4740, Section 9.5.4. [RFC4740] and is renamed 735 here for descriptive reasons. 737 The HTTP-Digest-Response AVP has the following ABNF grammar: 739 HTTP-Digest-Response ::= < AVP Header: 380 > 740 { Digest-Username } 741 { Digest-Realm } 742 { Digest-Nonce } 743 { Digest-URI } 744 { Digest-Response } 745 [ Digest-Algorithm ] 746 [ Digest-CNonce ] 747 [ Digest-Opaque ] 748 [ Digest-QoP ] 749 [ Digest-Nonce-Count ] 750 [ Digest-Method] 751 [ Digest-Entity-Body-Hash ] 752 * [ Digest-Auth-Param ] 753 * [ AVP ] 755 4.5.3. HTTP-Authentication-Info AVP 757 The HTTP-Digest-Info AVP is identical to the SIP-Authentication-Info 758 AVP specified in RFC 4740, Section 9.5.5. [RFC4740] and is renamed 759 here for descriptive reasons. 761 The HTTP-Digest-Info AVP has the following ABNF grammar: 762 HTTP-Digest-Info ::= < AVP Header: 381 > 763 [ Digest-Nextnonce ] 764 [ Digest-QoP ] 765 [ Digest-Response-Auth ] 766 [ Digest-CNonce ] 767 [ Digest-Nonce-Count ] 768 * [ AVP ] 770 4.5.4. HTTP Digest AVPs 772 The following table lists all AVPS that are RADIUS attributes defined 773 in RFC 5090 [RFC5090] and that are imported by RFC 4740 (see Section 774 9.5.6.) [RFC4740] to be used for the HTTP-Digest authentication. 776 +-------------------------+-------------+ 777 | Attribute Name | RADIUS Type | 778 +-------------------------+-------------+ 779 | Digest-Response | 103 | 780 | Digest-Realm | 104 | 781 | Digest-Nonce | 105 | 782 | Digest-Response-Auth | 106 | 783 | Digest-Nextnonce | 107 | 784 | Digest-Method | 108 | 785 | Digest-URI | 109 | 786 | Digest-QoP | 110 | 787 | Digest-Algorithm | 111 | 788 | Digest-Entity-Body-Hash | 112 | 789 | Digest-CNonce | 113 | 790 | Digest-Nonce-Count | 114 | 791 | Digest-Username | 115 | 792 | Digest-Opaque | 116 | 793 | Digest-Auth-Param | 117 | 794 | Digest-AKA-Auts | 118 | 795 | Digest-Domain | 119 | 796 | Digest-Stale | 120 | 797 | Digest-HA1 | 121 | 798 +-------------------------+-------------+ 800 4.6. Diameter Credit-Control Application AVPs 802 The following section describes the AVPs specified in RFC 4006 803 [RFC4006] and used by this application. 805 4.6.1. Other Credit-Control Application AVPs 807 The following AVPs are also used by this application: 809 +--------------------+--------+------------+------------------------+ 810 | Attribute Name | AVP | Value Type | Reference | 811 | | Code | | | 812 +--------------------+--------+------------+------------------------+ 813 | Service-Identifier | 439 | Unsigned32 | RFC 4006, Section | 814 | | | | 8.28. [RFC4006] | 815 | Service-Context-Id | 461 | UTF8String | RFC 4006, Section | 816 | | | | 8.42. [RFC4006] | 817 +--------------------+--------+------------+------------------------+ 819 5. IANA Considerations 821 This document serves as IANA registration request for a number of 822 items that should be registered in the AAA parameters registry. 824 5.1. Application Identifier 826 This document assigns the value TBD, "Diameter Application for 827 Authentication and Authorization in Web Applications", to the 828 Application Identifier namespace defined in (RFC 3588 [RFC3588]. See 829 Section Section 2.3 for more information. 831 5.2. AVP Codes 833 This document defines new standard AVPs, whose AVP Codes are to be 834 allocated within the AVP Codes address space defined in (RFC 3588, 835 Section 11.4. [RFC3588]. These AVP codes have been registered in 836 the AVP Codes sub-registry of the AAA parameters registry. The sole 837 new standard AVP that is specified for this Diameter application is 838 the WebAuth-Authentication-Type AVP. See Section Section 4.1.1 for 839 more information. 841 6. Privacy Considerations 843 The Diameter application aims at covering setups where Diameter 844 clients and Diameter servers belong to more than one administrative 845 domain. In those setups the end user often has a trust relationship 846 with the provider of the Diameter server but not with the provider of 847 the web applications that are the Diameter clients. In order to 848 allow a smooth operation of the services the user requested, the 849 Diameter server has to make certain personal information about the 850 user available to the application provider. And although the user 851 should be aware of that, it can be generally expected that access to 852 such personal information is kept on a minimum need-to-know basis 853 across different administrative domains. For example the application 854 provider may need to know if the user has a certain membership which 855 allows him to access the service he requested. The number and 856 details about further memberships the user may or may not have 857 however, is not relevant for the application provider at that moment. 858 This section therefore addresses a number of privacy consideration 859 that may arise in general or when dealing with a setup over multiple 860 administrative domains. Since usually there are no private 861 information that the client has but not the server, the privacy 862 considerations will focus on the issue to protect information that 863 are available in the Diameter server from access by the Diameter 864 client. 866 Generally, in setups where user privacy is an aspect, Diameter 867 servers SHOULD always require a user authentication before any kind 868 of personal information is made accessible to the Diameter client. 869 By requiring an authentication, user data probing by a rogue or 870 compromised Diameter client is made more difficult since only data 871 from users that are currently logged onto the client or whose login 872 credentials are known can be pried. If the authentication status for 873 a session is not maintained on the server, every action specified in 874 this chapter can be queried using an AA-Request command which then 875 MUST also include proper authentication credentials. However since 876 an authentication procedure possibly triggers some kind of user 877 interaction in the web client, it is RECOMMENDED to keep such AA- 878 Requests to a minimum. This can be achieved for example by querying 879 the Diameter server for all the data that is likely to be needed for 880 a session inside the first request. Although this may sound 881 counterintuitive to the objective of keeping private information 882 exposure on a minimum need-to-know basis, it doesn't make a 883 difference if data which a client is entitled to is transferred all 884 at once in the beginning of a session or gradually throughout the 885 session. Implementations of this document which want to allow 886 privacy protection SHOULD offer a configuration option to enforce 887 user authentication before any other operation is allowed. 889 A Diameter WebAuth implementation SHOULD protect personal data by 890 keeping authorization data service specific and by limiting available 891 authentication schemes to the ones which do not expose sensitive 892 data. Keeping authorization data service specific means that the 893 Diameter server SHOULD NOT authorize the user for services that the 894 Diameter client doesn't actually offer. This means that an AA-Answer 895 to an authorization request SHOULD NOT include Service-Identifiers 896 for services that are unavailable at the client the request came 897 from. Unfortunately, the Diameter server cannot directly influence 898 the authentication scheme that the Diameter client uses with its web 899 client (see also Section Section 7.3). However, limiting the 900 available authentication schemes to more secure ones will hopefully 901 encourage Diameter clients to be deployed using only the available 902 authentication schemes to begin with. This should make eavesdropping 903 on the Diameter client, web client connection more difficult and also 904 will require more changes to a compromised Diameter client in order 905 to gain access to plain text authentication credentials. The only 906 authentication scheme which can be considered reasonable secure and 907 is currently supported by this document is HTTP-Digest 908 authentication. 910 7. Security Considerations 912 This document describes a Diameter application which enables web 913 applications to access AAA services of a Diameter server. The 914 Diameter Base Protocol (RFC 3588) is used for the communication 915 between the Diameter client and the Diameter server. The security 916 considerations for the Base Protocol, therefore, apply to this 917 document as well (RFC 3588, Section 13) [RFC3588]. This document 918 assumes, that the message exchange between the Diameter client and 919 the Diameter server can be reasonably secured by respecting the 920 security considerations in RFC 3588. 922 For the communication between the end user and the Diameter client a 923 service specific protocol is used. When the Diameter client is 924 employed in a web application, usually this will be the Hypertext 925 Transfer Protocol (HTTP, RFC 2616). The security considerations for 926 the service specific protocol SHOULD be considered when a Diameter 927 WebAuth client is implemented. In case of a web application 928 employing HTTP, the correspondent security considerations are made in 929 RFC 2616, Section 15 [RFC2616]. In either case, since the service 930 protocol is used to exchange authentication information with the end 931 user, measures SHOULD be taken to secure the communication between 932 the Diameter client and the end user client. To secure HTTP message 933 exchanges, for example, HTTPS (HTTP over TLS, RFC 2818 [RFC2818]) 934 SHOULD be used. 936 7.1. HTTP Basic Authentication 938 The basic authentication scheme uses a cleartext user name/password 939 combination to authenticate a user. This makes the basic 940 authentication absolutely insecure. First of all, the password is 941 exposed to any third party which might be able to listen to the 942 message exchange between the user client and the Diameter client. 943 For example because the message exchange is not encrypted, the 944 encryption was broken of for other reasons. And second of all, the 945 password, inevitably, is exposed to the Diameter client. Especially 946 in setups where the Diameter client and the Diameter server are not 947 part of the same administrative domain this severely compromises the 948 end user's identity. Even in setups where Diameter client and server 949 are within the same administrative domain, user passwords should 950 never be accessible in cleartext. Otherwise in case of a compromised 951 Diameter client, all the user accounts are compromised too. Because 952 basic authentication is that insecure, it SHOULD NOT be employed in a 953 productive Diameter setup, unless absolutely no other option is 954 viable. Furthermore basic authentication SHOULD only be used over 955 encrypted and secure transport channels with some sort of server 956 authentication before the credentials are sent. Besides these 957 Diameter WebAuth oriented security considerations, those of the HTTP 958 Authentication specification (RFC 2617, Section 4 [RFC2617]) also 959 need to be considered. For example, they state explicitly that "the 960 Basic authentication scheme is not a secure method of user 961 authentication, nor does it in any way protect the entity, which is 962 transmitted in cleartext across the physical network used as the 963 carrier." 965 7.2. HTTP Digest Authentication 967 Like the basic authentication, the digest authentication uses a user 968 name in combination with a password to authenticate the user. In 969 contrast to the basic authentication, however, the digest 970 authentication does not exchange the password in cleartext. It uses 971 a one-way hash function to calculate a check value from the 972 combination of the user password and a nonce that was exchanged with 973 the authentication partner. Both authentication partners calculate 974 this value on their own, and the client which is to be authenticated 975 sends its value to the authenticator. If the values match, both used 976 the same password and, therefore, the authentication is successful. 978 The digest authentication, if implemented and executed correctly, 979 does provide a better authentication mechanism than basic 980 authentication. Especially an eavesdropping third party cannot 981 recover the cleartext password from an intercepted message exchange. 982 Nor can he use it for replay attacks when the server does not reuse 983 its nonce values. Nevertheless, the HTTP Authentication 984 specification (RFC 2617, RFC 2617, Section 4 [RFC2617]) has a number 985 of security considerations that must be considered. Especially is 986 the digest authentication scheme susceptible to man in the middle 987 attacks. It does provide some resilience against the attacker 988 recovering the cleartext password in those cases though. Also the 989 security considerations of the RADIUS Extension for Digest 990 Authentication specifications (RFC 5090) which the Diameter digest 991 authentication is derived from need to be considered RFC 5090, 992 Section 8 [RFC5090]. As a result, the digest authentication scheme 993 also SHOULD only be used over encrypted and secure communication 994 channels. This includes the authentication of the Diameter client to 995 the user client, for example HTTPS with public key certificates. 997 7.2.1. Digest Quick Mode 999 The HTTP digest quick mode (see Section Section 2.1.2.1) reduces the 1000 number of protocol round trips by prematurely including information 1001 that is otherwise exchanged in a subsequent round trip. The 1002 reduction in protocol round trips, however, needs to be balanced 1003 against the security compromises that come with it. The digest quick 1004 mode induces the release of control over the authentication process 1005 from the Diameter server to the Diameter client. Whether this is 1006 acceptable or not has to be carefully considered depending on the 1007 respective setup. 1009 A client initiated quick mode means that the digest nonce which is 1010 used during the HTTP authentication with the user client is generated 1011 by the Diameter client instead of the Diameter server. This allows 1012 the Diameter client to carry out a number of attacks against the user 1013 client and induces potential security risks for the secrecy of the 1014 user's password. A good nonce value is critical to the integrity of 1015 the HTTP digest authentication scheme. It is, therefore, imperative 1016 that the nonce generation on the Diameter client is as secure and 1017 reliable as the implementation on the Diameter server if no 1018 additional security risks are to be introduces. If a Diameter client 1019 is not implementing a secure and reliable nonce generation routine, 1020 from the security point of view it is better to use a server 1021 generated nonce and accept the additional protocol round trip. 1023 Permitting client initiated quick mode also might allow an attacker 1024 to use a compromised Diameter client to carry out chosen plaintext 1025 attacks, precomputed dictionary attacks, online dictionary attacks or 1026 other form of attacks using cryptanalysis. A countermeasure against 1027 those form of attack is for user clients to use a client-specific 1028 nonce (cnonce) during the HTTP authentication. The behavior of the 1029 user clients, however, is out of control of the Diameter server. 1030 Moreover, in case the Diameter client is compromised by an attacker 1031 it is reasonably to assume that the attacker can carry out those 1032 forms of attacks regardless of the security parameters of the 1033 Diameter server. 1035 The server initiated quick mode exposes the H(A1) value to the 1036 Diameter client. This allows for an attacker to carry out 1037 cryptanalysis attacks against this value instead of only the hash 1038 which is based on a one-time nonce. More importantly, the H(A1) 1039 value is the basis for the digest computation for a certain realm. 1040 This means that if an attacker gains access to this value the user 1041 password must be regarded as compromised for this realm. As a 1042 countermeasure, the names for realms that are secured by separate 1043 Diamter clients SHOULD be different. In general, realm names SHOULD 1044 always be unique within the domain of a Diameter server. In case a 1045 Diameter client was compromised, the realm name for the respective 1046 administrative domain needs to be changed, which in turn invalidates 1047 the compromised H(A1) value. The possibility to discover the 1048 original password from the H(A1) value, for example, by the means of 1049 a successful cryptanalysis attack, however, are not mitigated by this 1050 precaution. 1052 7.3. Renegade or Compromised WebAuth Clients 1054 Special considerations need to be made for the situation where a 1055 Diameter WebAuth client is compromised or renegade. In both cases 1056 the WebAuth client will try to exploit its natural position as man in 1057 the middle between the user client and the Diameter server to 1058 compromise user accounts. A natural goal of an attacker in this 1059 position is to gain access to cleartext user credentials. Since the 1060 Diameter WebAuth server does not allow direct querying of user names 1061 or passwords, the WebAuth client has two possibilities. It can probe 1062 for valid user name/password combination if the server accepts basic 1063 authentication AA-Requests or it can wait for user to authenticate 1064 themselves. Probing for valid combinations is not very promising and 1065 will not considered any further here. Having users to try and 1066 authenticate themselves to a WebAuth client that is trying to 1067 compromise their accounts, on the other hand, is a severe problem. 1069 As discussed above, when using digest authentication even a man in 1070 the middle attack has only limited chances of recovering the 1071 cleartext password. A man in the middle attacker, however, can 1072 simply switch the authentication scheme used towards the user client 1073 to basic authentication. This would give him unrestricted access to 1074 the cleartext user name and password for every user that logs in 1075 through the Diameter client. This kind of attack is described in 1076 RFC 2617, Section 4 [RFC2617] as well. Coinciding with the RFC, the 1077 only viable options to counteract such attacks lie within the user 1078 agent. For example, only if the user agent warns the user when basic 1079 authentication is requested, or in general indicates to the user what 1080 kind of authentication is about to be used, this kind of attack can 1081 be prevented by the user. Another possibility is for the client to 1082 offer a configuration option which either disables basic 1083 authentication completely or just for different web sites. For the 1084 future of this document it also SHOULD be considered to implement 1085 other authentication methods. This will not prevent renegade or 1086 compromised WebAuth clients from being able to switch authentication 1087 schemes, but from a user's perspective it is much more obvious when, 1088 for example, instead of the usual certificate based authentication a 1089 web server suddenly ask for a password 1091 8. References 1093 8.1. Normative References 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, March 1997. 1098 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1099 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1100 Authentication: Basic and Digest Access Authentication", 1101 RFC 2617, June 1999. 1103 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1104 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1106 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1107 "Diameter Network Access Server Application", RFC 4005, 1108 August 2005. 1110 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 1111 Loughney, "Diameter Credit-Control Application", RFC 4006, 1112 August 2005. 1114 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 1115 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 1116 Initiation Protocol (SIP) Application", RFC 4740, 1117 November 2006. 1119 [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., 1120 and W. Beck, "RADIUS Extension for Digest Authentication", 1121 RFC 5090, February 2008. 1123 8.2. Informative References 1125 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1126 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1127 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1129 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1131 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 1132 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 1133 August 2005. 1135 Appendix A. Open Issues 1137 o Add some attributes for WebAuth to better support web 1138 applications? Possible examples: Verification-Code (to use image 1139 verification) and attributes to convey pre- and/or post- 1140 authentication messages. 1142 o Service identification by the combination of the 1143 Service-Context-Id and Service-Identifier (which is a numerical 1144 value) attributes seems very cumbersome for the web application 1145 environment. Maybe we should add a new AVP which identifies 1146 services by its name. 1148 o Do we need an Interoperability section detailing the 1149 interoperability of WebAuth with other Diameter applications like 1150 Diameter EAP or Diameter CC? 1152 o Support for further authentication schemes like client 1153 certificates (SSL) 1155 Authors' Addresses 1157 Niklas Neumann 1158 University of Goettingen 1159 Computer Networks Group 1160 Goldschmidtstr. 7 1161 Goettingen 37077 1162 Germany 1164 Email: niklas.neumann@cs.uni-goettingen.de 1166 Xiaoming Fu 1167 University of Goettingen 1168 Computer Networks Group 1169 Goldschmidtstr. 7 1170 Goettingen 37077 1171 Germany 1173 Email: fu@cs.uni-goettingen.de