idnits 2.17.00 (12 Aug 2021) /tmp/idnits1877/draft-morand-http-digest-2g-aka-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (January 21, 2013) is 3407 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Morand 3 Internet-Draft France Telecom - Orange 4 Intended status: Informational January 21, 2013 5 Expires: July 25, 2013 7 Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G 8 Authentication and Key Agreement (AKA) 9 draft-morand-http-digest-2g-aka-03 11 Abstract 13 This memo specifies a one-time password generation mechanism for 14 Hypertext Transfer Protocol (HTTP) Digest access authentication based 15 on Global System for Mobile Communications (GSM) authentication and 16 key generation functions A3 and A8, also known as GSM AKA or 2G AKA. 17 The HTTP Authentication Framework includes two authentication 18 schemes: Basic and Digest. Both schemes employ a shared secret based 19 mechanism for access authentication. The GSM AKA mechanism performs 20 user authentication and session key distribution in GSM and Universal 21 Mobile Telecommunications System (UMTS) networks. GSM AKA is a 22 challenge-response based mechanism that uses symmetric cryptography. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 25, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. GSM 2G AKA Mechanism Overview . . . . . . . . . . . . . . . . 4 67 5. Specification of Digest 2G AKA . . . . . . . . . . . . . . . . 6 68 5.1. Algorithm Directive . . . . . . . . . . . . . . . . . . . 7 69 5.2. Creating a Challenge . . . . . . . . . . . . . . . . . . . 7 70 5.3. Client Authentication . . . . . . . . . . . . . . . . . . 7 71 5.4. Server Authentication . . . . . . . . . . . . . . . . . . 8 72 6. Example of Digest 2G AKA operations . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 8.1. Authentication of Clients using Digest 2G AKA . . . . . . 11 76 8.2. Limited Use of Nonce Values . . . . . . . . . . . . . . . 11 77 8.3. Multiple Authentication Schemes and Algorithms . . . . . . 12 78 8.4. Online Dictionary Attacks . . . . . . . . . . . . . . . . 12 79 8.5. Session Protection . . . . . . . . . . . . . . . . . . . . 12 80 8.6. Replay Protection . . . . . . . . . . . . . . . . . . . . 13 81 8.7. Mutual Authentication . . . . . . . . . . . . . . . . . . 13 82 8.8. Flooding the Authentication Centre . . . . . . . . . . . . 13 83 8.9. AKA Security . . . . . . . . . . . . . . . . . . . . . . . 13 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction and Motivation 92 The Hypertext Transfer Protocol (HTTP) Authentication Framework, 93 described in [RFC2617], includes two authentication schemes: Basic 94 and Digest. Both schemes employ a shared secret based mechanism for 95 access authentication. The Basic scheme is inherently insecure in 96 that it transmits user credentials in plain text. The Digest scheme 97 improves security by hiding user credentials with cryptographic 98 hashes, and additionally by providing limited message integrity. 100 The 2G AKA functions [TS55.205] perform authentication and session 101 key distribution in Global System for Mobile Communication (GSM) and 102 Universal Mobile Telecommunications System (UMTS) networks. 2G AKA is 103 a challenge-response based mechanism that uses symmetric 104 cryptography. 2G AKA is typically run in a GSM Subscriber Identity 105 Module (SIM), which resides in a smart card like device that also 106 provides tamper resistant storage of shared secrets. The 3G 107 Authentication and Key Agreement (AKA) mechanism, also known as UMTS 108 AKA, relying on the use of the UMTS Subscriber Identity Module (USIM) 109 instead of the GSM SIM, is most closely associated with UMTS; 110 however, mobile operators commonly distribute GSM SIMs with UMTS 111 mobile phones, resulting in the use of 2G (GSM) AKA in place of UMTS 112 AKA. 114 This document specifies a mapping of GSM AKA parameters onto HTTP 115 Digest authentication. In essence, this mapping enables the usage of 116 GSM 2G AKA as a one-time password generation mechanism for Digest 117 authentication. 119 This document is based heavily on [RFC3310] which specified a mapping 120 of Authentication and Key Agreement (AKA) onto HTTP Digest 121 authentication. While Digest AKA can be generally used when the 122 mobile phones are equipped with a UMTS SIM card, it may be useful for 123 mobile operators who have not yet fully deployed USIMs and have still 124 millions of SIMs deployed in the network. Digest 2G AKA allows 125 access to applications in a more secure way than would be possible 126 with the use of passwords or with GSM without enhancements. 128 Moreover, as the Session Initiation Protocol (SIP) [RFC3261] 129 Authentication Framework closely follows the HTTP Authentication 130 Framework, Digest 2G AKA is directly applicable to SIP as well as to 131 any other embodiment of HTTP Digest. 133 2. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 3. Terminology 141 This section explains the terminology used in this document. 143 AuC Authentication Center. 145 AKA Authentication and Key Agreement. 147 GSM Global System for Mobile Communication. 149 IMS IP Multimedia Subsystem. 151 IMSI International Mobile Subscriber Identity 153 ISIM IMS Subscriber Identity Module. 155 Kc Cypher Key. Ki Subscriber Key. 157 RAND Random Challenge. 159 SIM Subscriber Identity Module. 161 SRES Signed Authentication Response. 163 UMTS Universal Mobile Telecommunications System. 165 USIM UMTS Subscriber Identity Module. 167 4. GSM 2G AKA Mechanism Overview 169 This following figure (Fig. 1) provides an overview of the GSM 2G AKA 170 mechanism, which is based on a shared secret key (Ki) and the use of 171 A3/A8 algorithms. 173 The GSM 2G AKA mechanism is a challenge-response mechanism that 174 allows the authentication of the mobile subscriber/device in the 175 network. This mechanism involves the Subscriber Identity Module 176 (SIM) hosted by the mobile subscriber's device, a server in the 177 serving network and the Authentication Centre (AuC) in the mobile 178 subscriber's home network. When required, the authentication of the 179 mobile subscriber is performed by the serving network using 180 authentification material provided by the AuC. 182 A shared secret (Ki) is established beforehand between the SIM and 183 the AuC. The secret is stored in the SIM, which resides on a smart 184 card like, tamper resistant device. The SIM is identified by the 185 IMSI (International Mobile Subscriber Identity), which is also used 186 to identify the mobile subscriber/device in the network and the 187 shared secret (Ki) in the AuC (Authentication Center). 189 SIM Server AuC 190 (Ki) (Ki) 192 | | | 193 |---- 1.Request (IMSI) ----->| | 194 | | 2.Authen. Data Request (IMSI) | 195 | |------------------------------>| 196 | | | 197 | | +-----------------+----+ 198 | | | (3) | 199 | | | IMSI --> Ki | 200 | | | A3(RAND,Ki) = SRES | 201 | | | A8(RAND,Ki) = Kc | 202 | | +----------------+-----+ 203 | | | 204 | |<--- 4.AV (RAND, SRES, Kc) ---| 205 |<-- 5.Auth. Request (RAND) -| | 206 | | | 207 +-----+---------------+ | | 208 | (6) | | | 209 | A3(RAND,Ki) = SRES* | | | 210 | A8(RAND,Ki) = Kc | | | 211 +-----+---------------+ | | 212 | | | 213 |- 7.Auth. Response (SRES*)->| | 214 | | | 215 | +-------+------+ | 216 | | (8) | | 217 | | SRES*= SRES? | | 218 | +-------+------+ | 219 | | | 221 Figure 1. GSM 2G AKA overview 223 1. The mobile subscriber initiates a access/service request towards a 224 server in the serving network. The request contains the IMSI. 226 2. When the request needs to be authenticated, the server queries 227 the AuC of the mobile subscriber's home network to retrieve the 228 necessary material for authenticating the mobile subscriber 229 identified by the IMSI. 231 3. The IMSI received from the server is used as key entry by the AuC 232 to select the corresponding shared secret Ki. The AuC uses the 233 shared secret Ki and a generated random value (RAND) for calculating 234 the expected response (SRES) using the A3 algorithm and the ciffering 235 key Kc using the A8 algorithm. the triple RAND, SRES and Kc form an 236 Authentication Vector (AV). 238 4. The authentication vector (RAND, SRES, Kc) is downloaded to a 239 server. Optionally, if request by the server, the AuC can 240 also download more than one authentication vector, each AV generated 241 with a different RAND value. 243 5. The server creates an authentication request, which contains the 244 random challenge RAND and the authentication request is delivered 245 to the client. 247 6. The client produces a authentication response RES, using 248 the shared secret Ki and the random challenge RAND provided in 249 the authentication request received from the server. 251 7. The authentication response RES is delivered to the server. 253 8. The server compares the authentication response RES with the 254 expected response SRES. If the two match, the user has been 255 successfully authenticated, and the session key Kc can be used 256 for protecting further communication between the client and the 257 server 259 5. Specification of Digest 2G AKA 261 In general, the Digest 2G AKA operation is identical to the Digest 262 operation in [RFC2617]. This chapter specifies the parts in which 263 Digest 2G AKA extends the Digest operation. The notation used in the 264 Augmented BNF definitions for the new and modified syntax elements in 265 this section is as used in SIP [RFC3261], and any elements not 266 defined in this section are as defined in SIP and the documents to 267 which it refers. 269 5.1. Algorithm Directive 271 In order to direct the client into using 2G AKA for authentication 272 instead of the standard password system, the RFC 2617 defined 273 algorithm directive is overloaded in Digest 2G AKA: 275 algorithm = "algorithm" EQUAL ( 2GAKA-namespace / algorithm-value 276 ) 278 2GAKA-namespace = "2GAKA" "-" algorithm-value 280 algorithm-value = ( "MD5" / "MD5-sess" / token ) 282 algorithm 284 A string indicating the algorithm used in producing the digest and 285 the checksum. If the directive is not understood, the nonce 286 SHOULD be ignored, and another challenge (if one is present) 287 should be used instead. Reuse of the same SRES value in 288 authenticating subsequent requests and responses is NOT 289 RECOMMENDED. An SRES value SHOULD only be used as a one-time 290 password, and algorithms such as "MD5-sess", which limit the 291 amount of material hashed with a single key, by producing a 292 session key for authentication, SHOULD NOT be used. 294 5.2. Creating a Challenge 296 In order to deliver the GSM 2G AKA authentication challenge to the 297 client in Digest 2G AKA, the nonce directive defined in [RFC2617] is 298 extended: 300 nonce = "nonce" EQUAL ( 2GAKA-nonce / nonce-value ) 302 2GAKA-nonce = LDQUOT 2GAKA-nonce-value RDQUOT 304 2GAKA-nonce-value = 306 nonce 308 A parameter which is populated with the Base64 [RFC2045] encoding 309 of the 2G AKA authentication random challenge RAND. 311 5.3. Client Authentication 313 When a client receives a Digest 2G AKA authentication challenge, it 314 extracts the RAND from the "nonce" parameter and runs the A3-A8 315 algorithms with the RAND challenge and shared secret Ki. 317 The resulting A3-A8 SRES parameter is treated as a "password" when 318 calculating the response directive of [RFC2617]. Due to the fact 319 that the SRES parameter is 32 bits and the response directive of 320 [RFC2617] is defined as 32 hex digits, SRES is encoded in the low 321 order (i.e. rightmost) 32 bits of "response", padded with leading 322 zeroes. 324 Example: 326 SRES="0000000000000000000000007018d8a1" 328 5.4. Server Authentication 330 With Digest 2G AKA, the server MUST use the expected response SRES 331 received in the authentication vector as "password" when calculating 332 the "response-auth" of the "Authentication-Info" header defined in 333 [RFC2617]. 335 6. Example of Digest 2G AKA operations 337 Figure 2 below describes a message flow describing a Digest 2G AKA 338 process of authenticating a SIP request, namely the SIP REGISTER 339 request. 341 SIM HTTP Server AuC 342 (Ki) (Ki) 344 | 1) GET (IMSI) | | 345 |--------------------------->| | 346 | | 2) Authen. Data Request (IMSI)| 347 | |------------------------------>| 348 | | | 349 | | +-----------------+--+ 350 | | | IMSI --> Ki | 351 | | | A3(RAND,Ki) = SRES | 352 | | | A8(RAND,Ki) = Kc | 353 | | +-----------------+--+ 354 | | | 355 | | 3) AV (RAND, SRES, Kc) | 356 | |<------------------------------| 357 | 4) 401 Unauthorized (RAND) | | 358 |<---------------------------| | 359 | | | 360 +-----+---------------+ | | 361 | A3(RAND,Ki) = SRES* | | | 362 | A8(RAND,Ki) = Kc | | | 363 +-----+---------------+ | | 364 | | | 365 | 5) GET (IMSI, RAND, SRES) | | 366 |--------------------------->| | 367 | | | 368 | +-------+------+ | 369 | | SRES*= SRES? | | 370 | +-------+------+ | 371 | | | 372 | 6) 200 OK | | 373 |<---------------------------| | 374 | | | 376 Figure 2: Message flow representing a successful authentication 378 1) Initial request 380 GET / HTTP/1.1 381 Authorization: Digest 382 username="user1_private@home1.net", 383 realm="service1.home1.net", 384 nonce="", 385 uri="/", 386 response="" 388 2) Request to the AuC for 2G AKA authentication vector (AV) for the 389 given IMSI 391 3) Response from the AuC providing 2G AKA AV (RAND, SRES, Kc) 392 associated with the IMSI 394 4) Response containing a challenge 396 HTTP/1.1 401 Unauthorized 397 WWW-Authenticate: Digest 398 realm="service1.home1.net", 399 nonce="base64(RAND)", 400 qop="auth,auth-int", 401 opaque="6dae728da9089dab9112373c9f0a9731", 402 algorithm=2GAKA-MD5 404 5) Request containing credentials 406 GET / HTTP/1.1 407 Authorization: Digest 408 username="user1_private@home1.net", 409 realm="service1.home1.net", 410 nonce="base64(RAND)", 411 uri="/", 412 nc=00000001, 413 cnonce="0b8f29d6", 414 response="6629fae49393a05397450978507c4ef1", 415 opaque="6dae728da9089dab9112373c9f0a9731", 416 algorithm=2GAKA-MD5 418 6) Successful response 420 HTTP/1.1 200 OK 421 Authentication-Info: 422 qop=auth-int, 423 rspauth="6629fae49394a05397450978507c4ef1", 424 cnonce="6629fae49393a05397450978507c4ef1", 425 nc=00000001, 426 opaque="6dae728da9089dab9112373c9f0a9731", 427 nonce="base64(RAND)" 429 7. IANA Considerations 431 This document has no actions for IANA. 433 Note to RFC Editor: this section may be removed on publication as an 434 RFC. 436 8. Security Considerations 438 In general, Digest 2G AKA is vulnerable to the same security threats 439 as HTTP authentication [RFC2617]. This chapter discusses the 440 relevant exceptions. 442 8.1. Authentication of Clients using Digest 2G AKA 444 2G AKA is typically -- though this isn't a theoretical limitation -- 445 run on a SIM application that usually resides in a tamper resistant 446 smart card. Interfaces to the SIM exist, which enable the host 447 device to request authentication to be performed on the card. 448 However, these interfaces do not allow access to the long-term secret 449 outside the SIM, and the authentication can only be performed if the 450 device accessing the SIM has knowledge of a PIN code, shared between 451 the user and the SIM. Such PIN codes are typically obtained from 452 user input, and are usually required when the device is powered on. 454 The use of tamper resistant cards with secure interfaces implies that 455 Digest 2G AKA is typically more secure than regular Digest 456 implementations, as neither possession of the host device nor Trojan 457 Horses in the software give access to the long-term secret. Where a 458 PIN scheme is used, the user is also authenticated when the device is 459 powered on. However, there may be a difference in the resulting 460 security of Digest 2G AKA, compared to traditional Digest 461 implementations, depending on whether those implementations cache/ 462 store passwords that are received from the user. 464 8.2. Limited Use of Nonce Values 466 The Digest scheme uses server-specified nonce values to seed the 467 generation of the request-digest value. The server is free to 468 construct the nonce in such a way that it may only be used from a 469 particular client, for a particular resource, for a limited period of 470 time or number or uses, or any other restrictions. Doing so 471 strengthens the protection provided against, for example, replay 472 attacks. 474 Digest 2G AKA limits the applicability of a nonce value to a 475 particular SIM. Typically, the SIM is accessible only to one client 476 device at a time. However, the nonce values are strong and secure 477 even though limited to a particular SIM. Additionally, this requires 478 that the server is provided with the client identity before an 479 authentication challenge can be generated. If a client identity is 480 not available, an additional round trip is needed to acquire it. 482 8.3. Multiple Authentication Schemes and Algorithms 484 In HTTP authentication, a user agent MUST choose the strongest 485 authentication scheme it understands and request credentials from the 486 user, based upon that challenge. 488 In general, using passwords generated by Digest 2G AKA with other 489 HTTP authentication schemes is not recommended even though the realm 490 values or protection domains would coincide. In these cases, a 491 password should be requested from the end-user instead. Digest 2G 492 AKA passwords MUST NOT be re-used with such HTTP authentication 493 schemes, which send the password in the clear. In particular, 2G AKA 494 passwords must not be re-used with HTTP Basic. 496 The same principle must be applied within a scheme if several 497 algorithms are supported. A client receiving an HTTP Digest 498 challenge with several available algorithms MUST choose the strongest 499 algorithm it understands. For example, Digest with "2GAKA-MD5" would 500 be stronger than Digest with "MD5". 502 8.4. Online Dictionary Attacks 504 Since user-selected passwords are typically quite simple, it has been 505 proposed that servers should not accept passwords for HTTP Digest 506 which are in the dictionary [RFC2617]. This potential threat does 507 not exist in HTTP Digest 2G AKA because the algorithm will use SIM 508 originated passwords. However, the end-user must still be careful 509 with PIN codes. Even though HTTP Digest 2G AKA password requests are 510 never displayed to the end-user, the end-user will be authenticated 511 to the SIM via a PIN code. Commonly known initial PIN codes are 512 typically installed to the SIM during manufacturing and if the end- 513 users do not change them, there is a danger than an unauthorized user 514 may be able to use the device. Naturally this requires that the 515 unauthorized user has access to the physical device, and that the 516 end-user has not changed the initial PIN code. For this reason, end- 517 users are strongly encouraged to change their PIN codes when they 518 receive a SIM. 520 8.5. Session Protection 522 Digest 2G AKA is able to generate an additional session key for 523 integrity (Kc) protection. Even though this document does not 524 specify the use of these additional keys, they may be used for 525 creating additional security within HTTP authentication or some other 526 security mechanisms. 528 8.6. Replay Protection 530 The generation of RAND used as one-time or very limited-use nonces 531 and the use of the integrity protection of qop=auth-int will limit 532 the possibility of replay attacks. 534 In GSM, the network is allowed to re-use the RAND challenge in 535 consecutive authentication exchanges. This is not allowed in Digest 536 2G AKA. The server is mandated to use fresh triplets (RAND 537 challenges) in consecutive authentication exchanges. Digest 2G AKA 538 does not mandate any means for the client to check if the RANDs are 539 fresh, so the security of the scheme leans on the secrecy of the 540 triplets. However, the peer MAY employ implementation-specific 541 mechanisms to remember some of the previously used RANDs, and the 542 client MAY check the freshness of the server's RANDs. 544 8.7. Mutual Authentication 546 With Digest 2G AKA, network authentication is performed only after UE 547 authentication, in contrary to Digest AKA [RFC3310] in which the UE 548 authenticates the network before responding to the challenge. To 549 prevent an impersonation attack of the server to the UE, the 550 authentication of the server to the UE SHOULD be improved by 551 protecting the communication with TLS. An attacker succeeds only if 552 he can break both, the certificate-based TLS authentication to the UE 553 and mutual authentication provided by HTTP Digest using a password 554 derived from GSM procedures. One way to break TLS is to compromise 555 the certificate. 557 8.8. Flooding the Authentication Centre 559 The server typically obtains authentication vectors from the 560 Authentication Centre (AuC). Digest 2G AKA introduces a new usage 561 for the AuC. The protocols between the server and the AuC are out of 562 the scope of this document. However, it should be noted that a 563 malicious client may generate a lot of protocol requests to mount a 564 denial of service attack. The server implementation SHOULD take this 565 into account and SHOULD take steps to limit the traffic that it 566 generates towards the AuC, preventing the attacker from flooding the 567 AuC and from extending the denial of service attack from Digest 2G 568 AKA to other users of the AuC. 570 8.9. AKA Security 572 Evolutions of GSM networks, specifically Universal Mobile 573 Telecommunications System (UMTS) and IP Multimedia System (IMS) 574 networks, use an enhanced shared secret based mechanism for 575 authentication known as Authentication and Key Agreement (AKA). In 576 these networks, AKA is typically run in a UMTS Services Identity 577 Module (USIM) or IP Multimedia Services Identity Module (ISIM). GSM 578 phones can also be equipped with a USIM or ISIM. In that case, 579 Digest AKA as described in [RFC3310] is used for authentication as 580 opposed to Digest 2G AKA. 582 9. Acknowledgements 584 This memo is based on an initial draft written by Brett Wallis 585 (draft-ietf-http-digest-auth-a3a8-01). 587 10. References 589 10.1. Normative References 591 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 592 Extensions (MIME) Part One: Format of Internet Message 593 Bodies", RFC 2045, November 1996. 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, March 1997. 598 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 599 Leach, P., Luotonen, A., and L. Stewart, "HTTP 600 Authentication: Basic and Digest Access Authentication", 601 RFC 2617, June 1999. 603 10.2. Informative References 605 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 606 A., Peterson, J., Sparks, R., Handley, M., and E. 607 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 608 June 2002. 610 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 611 Protocol (HTTP) Digest Authentication Using Authentication 612 and Key Agreement (AKA)", RFC 3310, September 2002. 614 [TS55.205] 615 "Specification of the GSM- MILENAGE algorithms (Release 616 9)", December 2009. 618 Author's Address 620 Lionel Morand 621 France Telecom - Orange 622 38-40 rue du general Leclerc 623 Issy-Les-Moulineaux Cedex 9 92794 624 France 626 Phone: +33 1 4529 6257 627 Email: lionel.morand@orange.com