idnits 2.17.00 (12 Aug 2021) /tmp/idnits3418/draft-morand-http-digest-2g-aka-04.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 24 instances of too long lines in the document, the longest one being 6 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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o The TLS endpoints MUST comply with the 3GPP TLS profile given in 3GPP TS 33.310, Annex E [TS33.310] is . The only difference is that TLS cipher suites without encryption MUST not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o Server certificate validation MUST not require manual user interaction. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o The server MUST not request a certificate in a Server Hello Message from the client (as the client is authenticated using Digest 2G AKA as described in section 5). -- The document date (October 03, 2013) is 3152 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 634, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Morand 3 Internet-Draft Orange Labs 4 Intended status: Informational October 03, 2013 5 Expires: April 06, 2014 7 Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G 8 Authentication and Key Agreement (AKA) 9 draft-morand-http-digest-2g-aka-04 11 Abstract 13 This document 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 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 06, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction and Motivations . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. GSM 2G AKA Mechanism Overview . . . . . . . . . . . . . . . . 4 62 5. Example of Digest 2G AKA operations . . . . . . . . . . . . . 6 63 6. Specification of Digest 2G AKA . . . . . . . . . . . . . . . 8 64 6.1. Algorithm Directive . . . . . . . . . . . . . . . . . . . 8 65 6.2. Creating a Challenge . . . . . . . . . . . . . . . . . . 9 66 6.3. Client Authentication . . . . . . . . . . . . . . . . . . 9 67 6.4. Server Authentication . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 8.1. Authentication of Clients using Digest 2G AKA . . . . . . 10 71 8.2. Limited Use of Nonce Values . . . . . . . . . . . . . . . 10 72 8.3. Multiple Authentication Schemes and Algorithms . . . . . 11 73 8.4. Online Dictionary Attacks . . . . . . . . . . . . . . . . 11 74 8.5. Session Protection . . . . . . . . . . . . . . . . . . . 11 75 8.6. Replay Protection . . . . . . . . . . . . . . . . . . . . 12 76 8.7. Mutual Authentication . . . . . . . . . . . . . . . . . . 12 77 8.8. Flooding the Authentication Centre . . . . . . . . . . . 12 78 8.9. AKA Security . . . . . . . . . . . . . . . . . . . . . . 13 79 8.10. TLS Profile . . . . . . . . . . . . . . . . . . . . . . . 13 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 10.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction and Motivations 88 The Hypertext Transfer Protocol (HTTP) Authentication Framework, 89 described in [RFC2617], includes two authentication schemes: Basic 90 and Digest. Both schemes employ a shared secret based mechanism for 91 access authentication. The Basic scheme is inherently insecure in 92 that it transmits user credentials in plain text. The Digest scheme 93 improves security by hiding user credentials with cryptographic 94 hashes, and additionally by providing limited message integrity. 96 The 2G AKA functions [TS55.205] perform authentication and session 97 key distribution in Global System for Mobile Communication (GSM) and 98 Universal Mobile Telecommunications System (UMTS) networks. 2G AKA is 99 a challenge-response based mechanism that uses symmetric 100 cryptography. 2G AKA is typically run in a GSM Subscriber Identity 101 Module (SIM), which resides in a smart card like device that also 102 provides tamper resistant storage of shared secrets. The 3G 103 Authentication and Key Agreement (AKA) mechanism, also known as UMTS 104 AKA, relying on the use of the UMTS Subscriber Identity Module (USIM) 105 instead of the GSM SIM, is most closely associated with UMTS; 106 however, mobile operators commonly distribute GSM SIMs with UMTS 107 mobile phones, resulting in the use of 2G (GSM) AKA in place of UMTS 108 AKA. 110 This document specifies a mapping of GSM AKA parameters onto HTTP 111 Digest authentication. In essence, this mapping enables the usage of 112 GSM 2G AKA as a one-time password generation mechanism for Digest 113 authentication. 115 This document is based heavily on [RFC3310] which specified a mapping 116 of Authentication and Key Agreement (AKA) onto HTTP Digest 117 authentication. While Digest AKA can be generally used when the 118 mobile phones are equipped with a UMTS SIM card, it may be useful for 119 mobile operators who have not yet fully deployed USIMs and have still 120 millions of SIMs deployed in the network. Digest 2G AKA allows 121 access to applications in a more secure way than would be possible 122 with the use of passwords or with GSM without enhancements. 124 Moreover, as the Session Initiation Protocol (SIP) [RFC3261] 125 Authentication Framework closely follows the HTTP Authentication 126 Framework, Digest 2G AKA is directly applicable to SIP as well as to 127 any other embodiment of HTTP Digest. 129 2. Terminology 131 3. Acronyms 133 AuC Authentication Center. 135 AKA Authentication and Key Agreement. 137 GSM Global System for Mobile Communication. 139 IMS IP Multimedia Subsystem. 141 IMSI International Mobile Subscriber Identity 143 ISIM IMS Subscriber Identity Module. 145 Kc Cipher Key. 147 Ki Subscriber Key. 149 RAND Random Challenge. 151 SIM Subscriber Identity Module. 153 SRES Signed Authentication Response. 155 UMTS Universal Mobile Telecommunications System. 157 USIM UMTS Subscriber Identity Module. 159 4. GSM 2G AKA Mechanism Overview 161 This following figure (Fig. 1) provides an overview of the GSM 2G AKA 162 mechanism, which is based on a shared secret key (Ki) and the use of 163 A3/A8 algorithms. 165 The GSM 2G AKA mechanism is a challenge-response mechanism that 166 allows the authentication of the mobile subscriber/device in the 167 network. This mechanism involves the Subscriber Identity Module 168 (SIM) hosted by the mobile subscriber's device, a server in the 169 serving network and the Authentication Centre (AuC) in the mobile 170 subscriber's home network. When required, the authentication of the 171 mobile subscriber is performed by the serving network using 172 authentication material provided by the AuC. 174 A shared secret (Ki) is established beforehand between the SIM and 175 the AuC. The secret is stored in the SIM, which resides on a smart 176 card like, tamper resistant device. The SIM is identified by the 177 IMSI (International Mobile Subscriber Identity), which is also used 178 to identify the mobile subscriber/device in the network and the 179 shared secret (Ki) in the AuC (Authentication Center). 181 SIM Server AuC 182 (Ki) (Ki) 184 | | | 185 |---- 1.Request (IMSI) ----->| | 186 | | 2.Authen. Data Request (IMSI) | 187 | |------------------------------>| 188 | | | 189 | | +-----------------+----+ 190 | | | (3) | 191 | | | IMSI --> Ki | 192 | | | A3(RAND,Ki) = SRES | 193 | | | A8(RAND,Ki) = Kc | 194 | | +----------------+-----+ 195 | | | 196 | |<--- 4.AV (RAND, SRES, Kc) ---| 197 |<-- 5.Auth. Request (RAND) -| | 198 | | | 199 +-----+---------------+ | | 200 | (6) | | | 201 | A3(RAND,Ki) = SRES* | | | 202 | A8(RAND,Ki) = Kc | | | 203 +-----+---------------+ | | 204 | | | 205 |- 7.Auth. Response (SRES*)->| | 206 | | | 207 | +-------+------+ | 208 | | (8) | | 209 | | SRES*= SRES? | | 210 | +-------+------+ | 211 | | | 213 Figure 1. GSM 2G AKA overview 215 1. The mobile subscriber initiates a access/service request towards a 216 server in the serving network. The request contains the IMSI. 218 2. When the request needs to be authenticated, the server queries 219 the AuC of the mobile subscriber's home network to retrieve the 220 necessary material for authenticating the mobile subscriber 221 identified by the IMSI. 223 3. The IMSI received from the server is used as key entry by the AuC 224 to select the corresponding shared secret Ki. The AuC uses the 225 shared secret Ki and a generated random value (RAND) for calculating 226 the expected response (SRES) using the A3 algorithm and the cipher 227 key Kc using the A8 algorithm. the triple RAND, SRES and Kc form an 228 Authentication Vector (AV). 230 4. The authentication vector (RAND, SRES, Kc) is downloaded to a 231 server. Optionally, if request by the server, the AuC can 232 also download more than one authentication vector, each AV generated 233 with a different RAND value. 235 5. The server creates an authentication request, which contains the 236 random challenge RAND and the authentication request is delivered 237 to the client. 239 6. The client produces a authentication response RES, using 240 the shared secret Ki and the random challenge RAND provided in 241 the authentication request received from the server. 243 7. The authentication response RES is delivered to the server. 245 8. The server compares the authentication response RES with the 246 expected response SRES. If the two match, the user has been 247 successfully authenticated, and the session key Kc can be used 248 for protecting further communication between the client and the 249 server 251 5. Example of Digest 2G AKA operations 253 Figure 2 below describes a message flow describing a Digest 2G AKA 254 process of authenticating a SIP request, namely the SIP REGISTER 255 request. 257 SIM HTTP Server AuC 258 (Ki) (Ki) 260 | 1) GET (IMSI) | | 261 |--------------------------->| | 262 | | 2) Authen. Data Request (IMSI)| 263 | |------------------------------>| 264 | | | 265 | | +-----------------+--+ 266 | | | IMSI --> Ki | 267 | | | A3(RAND,Ki) = SRES | 268 | | | A8(RAND,Ki) = Kc | 269 | | +-----------------+--+ 270 | | | 271 | | 3) AV (RAND, SRES, Kc) | 272 | |<------------------------------| 273 | 4) 401 Unauthorized (RAND) | | 274 |<---------------------------| | 275 | | | 276 +-----+---------------+ | | 277 | A3(RAND,Ki) = SRES* | | | 278 | A8(RAND,Ki) = Kc | | | 279 +-----+---------------+ | | 280 | | | 281 | 5) GET (IMSI, RAND, SRES) | | 282 |--------------------------->| | 283 | | | 284 | +-------+------+ | 285 | | SRES*= SRES? | | 286 | +-------+------+ | 287 | | | 288 | 6) 200 OK | | 289 |<---------------------------| | 290 | | | 292 Figure 2: Message flow representing a successful authentication 294 1) Initial request 296 GET / HTTP/1.1 297 Authorization: Digest 298 username="user1_private@home1.net", 299 realm="service1.home1.net", 300 nonce="", 301 uri="/", 302 response="" 304 2) Request to the AuC for 2G AKA authentication vector (AV) for the 305 given IMSI 307 3) Response from the AuC providing 2G AKA AV (RAND, SRES, Kc) 308 associated with the IMSI 310 4) Response containing a challenge 312 HTTP/1.1 401 Unauthorized 313 WWW-Authenticate: Digest 314 realm="service1.home1.net", 315 nonce="base64(RAND)", 316 qop="auth,auth-int", 317 opaque="6dae728da9089dab9112373c9f0a9731", 318 algorithm=2GAKA-MD5 320 5) Request containing credentials 322 GET / HTTP/1.1 323 Authorization: Digest 324 username="user1_private@home1.net", 325 realm="service1.home1.net", 326 nonce="base64(RAND)", 327 uri="/", 328 nc=00000001, 329 cnonce="0b8f29d6", 330 response="6629fae49393a05397450978507c4ef1", 331 opaque="6dae728da9089dab9112373c9f0a9731", 332 algorithm=2GAKA-MD5 334 6) Successful response 336 HTTP/1.1 200 OK 337 Authentication-Info: 338 qop=auth-int, 339 rspauth="6629fae49394a05397450978507c4ef1", 340 cnonce="6629fae49393a05397450978507c4ef1", 341 nc=00000001, 342 opaque="6dae728da9089dab9112373c9f0a9731", 343 nonce="base64(RAND)" 345 6. Specification of Digest 2G AKA 347 In general, the Digest 2G AKA operation is identical to the Digest 348 operation in [RFC2617]. This chapter specifies the parts in which 349 Digest 2G AKA extends the Digest operation. The notation used in the 350 Augmented BNF definitions for the new and modified syntax elements in 351 this section is as used in SIP [RFC3261], and any elements not 352 defined in this section are as defined in SIP and the documents to 353 which it refers. 355 6.1. Algorithm Directive 357 In order to direct the client into using 2G AKA for authentication 358 instead of the standard password system, the RFC 2617 defined 359 algorithm directive is overloaded in Digest 2G AKA: 361 algorithm = "algorithm" EQUAL ( 2GAKA-namespace / algorithm-value 362 ) 364 2GAKA-namespace = "2GAKA" "-" algorithm-value 366 algorithm-value = ( "MD5" / "MD5-sess" / token ) 368 algorithm 369 A string indicating the algorithm used in producing the digest and 370 the checksum. If the directive is not understood, the nonce 371 SHOULD be ignored, and another challenge (if one is present) 372 should be used instead. Reuse of the same SRES value in 373 authenticating subsequent requests and responses is NOT 374 RECOMMENDED. An SRES value SHOULD only be used as a one-time 375 password, and algorithms such as "MD5-sess", which limit the 376 amount of material hashed with a single key, by producing a 377 session key for authentication, SHOULD NOT be used. 379 6.2. Creating a Challenge 381 In order to deliver the GSM 2G AKA authentication challenge to the 382 client in Digest 2G AKA, the nonce directive defined in [RFC2617] is 383 extended: 385 nonce = "nonce" EQUAL ( 2GAKA-nonce / nonce-value ) 387 2GAKA-nonce = LDQUOT 2GAKA-nonce-value RDQUOT 389 2GAKA-nonce-value = 391 nonce 393 A parameter which is populated with the Base64 [RFC2045] encoding 394 of the 2G AKA authentication random challenge RAND. 396 6.3. Client Authentication 398 When a client receives a Digest 2G AKA authentication challenge, it 399 extracts the RAND from the "nonce" parameter and runs the A3-A8 400 algorithms with the RAND challenge and shared secret Ki. 402 The resulting A3-A8 SRES parameter is treated as a "password" when 403 calculating the response directive of [RFC2617]. Due to the fact 404 that the SRES parameter is 32 bits and the response directive of 405 [RFC2617] is defined as 32 hex digits, SRES is encoded in the low 406 order (i.e. rightmost) 32 bits of "response", padded with leading 407 zeroes. 409 Example: 411 SRES="0000000000000000000000007018d8a1" 413 6.4. Server Authentication 415 With Digest 2G AKA, the server MUST use the expected response SRES 416 received in the authentication vector as "password" when calculating 417 the "response-auth" of the "Authentication-Info" header defined in 418 [RFC2617]. 420 7. IANA Considerations 422 This document has no actions for IANA. 424 Note to RFC Editor: this section may be removed on publication as an 425 RFC. 427 8. Security Considerations 429 In general, Digest 2G AKA is vulnerable to the same security threats 430 as HTTP authentication [RFC2617]. This chapter discusses the 431 relevant exceptions. 433 8.1. Authentication of Clients using Digest 2G AKA 435 2G AKA is typically -- though this isn't a theoretical limitation -- 436 run on a SIM application that usually resides in a tamper resistant 437 smart card. Interfaces to the SIM exist, which enable the host 438 device to request authentication to be performed on the card. 439 However, these interfaces do not allow access to the long-term secret 440 outside the SIM, and the authentication can only be performed if the 441 device accessing the SIM has knowledge of a PIN code, shared between 442 the user and the SIM. Such PIN codes are typically obtained from 443 user input, and are usually required when the device is powered on. 445 The use of tamper resistant cards with secure interfaces implies that 446 Digest 2G AKA is typically more secure than regular Digest 447 implementations, as neither possession of the host device nor Trojan 448 Horses in the software give access to the long-term secret. Where a 449 PIN scheme is used, the user is also authenticated when the device is 450 powered on. However, there may be a difference in the resulting 451 security of Digest 2G AKA, compared to traditional Digest 452 implementations, depending on whether those implementations cache/ 453 store passwords that are received from the user. 455 8.2. Limited Use of Nonce Values 457 The Digest scheme uses server-specified nonce values to seed the 458 generation of the request-digest value. The server is free to 459 construct the nonce in such a way that it may only be used from a 460 particular client, for a particular resource, for a limited period of 461 time or number or uses, or any other restrictions. Doing so 462 strengthens the protection provided against, for example, replay 463 attacks. 465 Digest 2G AKA limits the applicability of a nonce value to a 466 particular SIM. Typically, the SIM is accessible only to one client 467 device at a time. However, the nonce values are strong and secure 468 even though limited to a particular SIM. Additionally, this requires 469 that the server is provided with the client identity before an 470 authentication challenge can be generated. If a client identity is 471 not available, an additional round trip is needed to acquire it. 473 8.3. Multiple Authentication Schemes and Algorithms 475 In HTTP authentication, a user agent MUST choose the strongest 476 authentication scheme it understands and request credentials from the 477 user, based upon that challenge. 479 In general, using passwords generated by Digest 2G AKA with other 480 HTTP authentication schemes is not recommended even though the realm 481 values or protection domains would coincide. In these cases, a 482 password should be requested from the end-user instead. Digest 2G 483 AKA passwords MUST NOT be re-used with such HTTP authentication 484 schemes, which send the password in the clear. In particular, 2G AKA 485 passwords must not be re-used with HTTP Basic. 487 The same principle must be applied within a scheme if several 488 algorithms are supported. A client receiving an HTTP Digest 489 challenge with several available algorithms MUST choose the strongest 490 algorithm it understands. For example, Digest with "2GAKA-MD5" would 491 be stronger than Digest with "MD5". 493 8.4. Online Dictionary Attacks 495 Since user-selected passwords are typically quite simple, it has been 496 proposed that servers should not accept passwords for HTTP Digest 497 which are in the dictionary [RFC2617]. This potential threat does 498 not exist in HTTP Digest 2G AKA because the algorithm will use SIM 499 originated passwords. However, the end-user must still be careful 500 with PIN codes. Even though HTTP Digest 2G AKA password requests are 501 never displayed to the end-user, the end-user will be authenticated 502 to the SIM via a PIN code. Commonly known initial PIN codes are 503 typically installed to the SIM during manufacturing and if the end- 504 users do not change them, there is a danger than an unauthorized user 505 may be able to use the device. Naturally this requires that the 506 unauthorized user has access to the physical device, and that the 507 end-user has not changed the initial PIN code. For this reason, end- 508 users are strongly encouraged to change their PIN codes when they 509 receive a SIM. 511 8.5. Session Protection 512 Digest 2G AKA is able to generate an additional session key for 513 integrity (Kc) protection. Even though this document does not 514 specify the use of these additional keys, they may be used for 515 creating additional security within HTTP authentication or some other 516 security mechanisms. 518 8.6. Replay Protection 520 The generation of RAND used as one-time or very limited-use nonces 521 and the use of the integrity protection of qop=auth-int will limit 522 the possibility of replay attacks. 524 In GSM, the network is allowed to re-use the RAND challenge in 525 consecutive authentication exchanges. This is not allowed in Digest 526 2G AKA. The server is mandated to use fresh triplets (RAND 527 challenges) in consecutive authentication exchanges. Digest 2G AKA 528 does not mandate any means for the client to check if the RANDs are 529 fresh, so the security of the scheme leans on the secrecy of the 530 triplets. However, the peer MAY employ implementation-specific 531 mechanisms to remember some of the previously used RANDs, and the 532 client MAY check the freshness of the server's RANDs. 534 8.7. Mutual Authentication 536 With Digest 2G AKA, network authentication is performed only after 537 client authentication, in contrary to Digest AKA [RFC3310] in which 538 the UE authenticates the network before responding to the challenge. 539 To prevent an impersonation attack of the server to the client, the 540 authentication of the server to the UE SHOULD be improved by 541 protecting the communication with Transport Layer Security (TLS). An 542 attacker succeeds only if he can break both, the certificate-based 543 TLS authentication to the client and mutual authentication provided 544 by HTTP Digest using a password derived from GSM procedures. One way 545 to break TLS is to compromise the certificate. However, the risk of 546 clients using the root certificates associated with a compromised 547 Certification Authority (CA) is minimized if the clients use a 548 preconfigured list of trusted root certificates restricted to a low 549 number of CAs trusted by the operator, as opposed to the list of all 550 root certificates in a browser's key store, as described in section 551 8.10. 553 When TLS is used for server authentication, the recommendations given 554 in section 8.10 apply. 556 8.8. Flooding the Authentication Centre 558 The server typically obtains authentication vectors from the 559 Authentication Centre (AuC). Digest 2G AKA introduces a new usage 560 for the AuC. The protocols between the server and the AuC are out of 561 the scope of this document. However, it should be noted that a 562 malicious client may generate a lot of protocol requests to mount a 563 denial of service attack. The server implementation SHOULD take this 564 into account and SHOULD take steps to limit the traffic that it 565 generates towards the AuC, preventing the attacker from flooding the 566 AuC and from extending the denial of service attack from Digest 2G 567 AKA to other users of the AuC. 569 8.9. AKA Security 571 Evolutions of GSM networks, specifically Universal Mobile 572 Telecommunications System (UMTS) and IP Multimedia System (IMS) 573 networks, use an enhanced shared secret based mechanism for 574 authentication known as Authentication and Key Agreement (AKA). In 575 these networks, AKA is typically run in a UMTS Services Identity 576 Module (USIM) or IP Multimedia Services Identity Module (ISIM). GSM 577 phones can also be equipped with a USIM or ISIM. In that case, 578 Digest AKA as described in [RFC3310] is used for authentication as 579 opposed to Digest 2G AKA. 581 8.10. TLS Profile 583 When TLS is used for server authentication prior to the Digest 2G AKA 584 authentication procedures, the following recommendations apply. 586 o The TLS endpoints MUST support TLS version 1.1 as specified in RFC 587 4346 [RFC4346] and SHOULD support TLS version 1.2 as specified in 588 RFC 5246 [RFC5246] should be supported. - 590 o The highest TLS version supported on both TLS endpoints MUST be 591 used. 593 o The TLS endpoints MUST comply with the 3GPP TLS profile given in 594 3GPP TS 33.310, Annex E [TS33.310] is . The only difference is 595 that TLS cipher suites without encryption MUST not be used. 597 o The certificates used for TLS MUST comply with the 3GPP 598 certificate profile defined in the section 6.1 of 3GPP TS 33.310 599 [TS33.310] is . 601 o Support of certificate revocation and of the related fields in 602 certificates is recommended. 604 o Server name matching MUST be performed by the client using the 605 matching rules specified by RFC 2818 [RFC2818] is . 607 o The client MUST use a preconfigured list of trusted root 608 certificates for server certificate validation. 610 o Server certificate validation MUST not require manual user 611 interaction. 613 o The server MUST not request a certificate in a Server Hello 614 Message from the client (as the client is authenticated using 615 Digest 2G AKA as described in section 5). 617 o The TLS endpoints MUST allow for resuming a session. The lifetime 618 of a Session ID is subject to local policies set on the TLS 619 endpoints. 621 9. Acknowledgements 623 This memo is based on an initial draft written by Brett Wallis 624 (draft-ietf-http-digest-auth-a3a8-01). 626 10. References 628 10.1. Normative References 630 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 631 Extensions (MIME) Part One: Format of Internet Message 632 Bodies", RFC 2045, November 1996. 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, March 1997. 637 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 638 Leach, P., Luotonen, A., and L. Stewart, "HTTP 639 Authentication: Basic and Digest Access Authentication", 640 RFC 2617, June 1999. 642 10.2. Informative References 644 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 646 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 647 A., Peterson, J., Sparks, R., Handley, M., and E. 648 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 649 June 2002. 651 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 652 Protocol (HTTP) Digest Authentication Using Authentication 653 and Key Agreement (AKA)", RFC 3310, September 2002. 655 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 656 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 658 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 659 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 661 [TS33.310] 662 , "Network Domain Security (NDS); Authentication Framework 663 (AF) (Release 12)", June 2013. 665 [TS55.205] 666 , "Specification of the GSM- MILENAGE algorithms (Release 667 11)", September 2012. 669 Author's Address 671 Lionel Morand 672 Orange Labs 673 38/40 rue du General Leclerc 674 Issy-Les-Moulineaux Cedex 9 92794 675 France 677 Phone: +33145296257 678 Email: lionel.morand@orange.com