idnits 2.17.1 draft-morand-http-digest-2g-aka-05.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 3 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 (April 14, 2014) is 3658 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 671, 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 2818 (Obsoleted by RFC 9110) -- 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 (==), 4 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 April 14, 2014 5 Expires: October 16, 2014 7 Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G 8 Authentication and Key Agreement (AKA) 9 draft-morand-http-digest-2g-aka-05 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 October 16, 2014. 41 Copyright Notice 43 Copyright (c) 2014 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 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.2. Relationship with 3GPP authentication mechanism over HTTP 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. GSM 2G AKA Mechanism Overview . . . . . . . . . . . . . . . . 4 64 5. Example of Digest 2G AKA operations . . . . . . . . . . . . . 6 65 6. Specification of Digest 2G AKA . . . . . . . . . . . . . . . 8 66 6.1. Algorithm Directive . . . . . . . . . . . . . . . . . . . 9 67 6.2. Creating a Challenge . . . . . . . . . . . . . . . . . . 9 68 6.3. Client Authentication . . . . . . . . . . . . . . . . . . 10 69 6.4. Server Authentication . . . . . . . . . . . . . . . . . . 10 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8.1. Authentication of Clients using Digest 2G AKA . . . . . . 10 73 8.2. Limited Use of Nonce Values . . . . . . . . . . . . . . . 11 74 8.3. Multiple Authentication Schemes and Algorithms . . . . . 11 75 8.4. Online Dictionary Attacks . . . . . . . . . . . . . . . . 12 76 8.5. Session Protection . . . . . . . . . . . . . . . . . . . 12 77 8.6. Replay Protection . . . . . . . . . . . . . . . . . . . . 12 78 8.7. Mutual Authentication . . . . . . . . . . . . . . . . . . 13 79 8.8. Flooding the Authentication Centre . . . . . . . . . . . 13 80 8.9. AKA Security . . . . . . . . . . . . . . . . . . . . . . 13 81 8.10. TLS Profile . . . . . . . . . . . . . . . . . . . . . . . 14 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 85 10.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction and Motivations 90 1.1. 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 1.2. Relationship with 3GPP authentication mechanism over HTTP 135 3GPP has defined the Generic Bootstrapping Architecture (GBA) that 136 enables the authentication of mobile subscriber based on AKA protocol 137 [TS33.220]. This architecture is originally designed to allow 3G AKA 138 authentication over HTTP [RFC3310], involving the user's mobile 139 smartcard, a bootstrapping server function (BSF) and the 140 authentication center (AuC) colocated with the mobile subscriber 141 profile repository in the mobile operator network (HLR/HSS). GBA 142 also provides the optional support of authentication of 2G mobile 143 users with the procedure called 2G GBA. This document does not 144 intend to define a new standard mechanism for 3GPP. The aim of this 145 document is to provide mobile operators with an 2G-AKA authentication 146 mechanism over HTTP in networks when no GBA is deployed in the mobile 147 operator network. When the GBA architecture is deployed in the 148 mobile operator network, it is recomment to rely on the 3GPP TS 149 33.220 [TS33.220] to perform 2G-AKA autentication over HTTP instead 150 of the mechanism described in this document. 152 2. Terminology 154 3. Acronyms 156 AuC Authentication Center. 158 AKA Authentication and Key Agreement. 160 GSM Global System for Mobile Communication. 162 IMS IP Multimedia Subsystem. 164 IMSI International Mobile Subscriber Identity 166 ISIM IMS Subscriber Identity Module. 168 Kc Cipher Key. 170 Ki Subscriber Key. 172 RAND Random Challenge. 174 SIM Subscriber Identity Module. 176 SRES Signed Authentication Response. 178 UMTS Universal Mobile Telecommunications System. 180 USIM UMTS Subscriber Identity Module. 182 4. GSM 2G AKA Mechanism Overview 184 This following figure (Fig. 1) provides an overview of the GSM 2G AKA 185 mechanism, which is based on a shared secret key (Ki) and the use of 186 A3/A8 algorithms. 188 The GSM 2G AKA mechanism is a challenge-response mechanism that 189 allows the authentication of the mobile subscriber/device in the 190 network. This mechanism involves the Subscriber Identity Module 191 (SIM) hosted by the mobile subscriber's device, a server in the 192 serving network and the Authentication Centre (AuC) in the mobile 193 subscriber's home network. When required, the authentication of the 194 mobile subscriber is performed by the serving network using 195 authentication material provided by the AuC. 197 A shared secret (Ki) is established beforehand between the SIM and 198 the AuC. The secret is stored in the SIM, which resides on a smart 199 card like, tamper resistant device. The SIM is identified by the 200 IMSI (International Mobile Subscriber Identity), which is also used 201 to identify the mobile subscriber/device in the network and the 202 shared secret (Ki) in the AuC (Authentication Center). 204 SIM Server AuC 205 (Ki) (Ki) 207 | | | 208 |---- 1.Request (IMSI) ----->| | 209 | | 2.Authen. Data Request (IMSI) | 210 | |------------------------------>| 211 | | | 212 | | +-----------------+----+ 213 | | | (3) | 214 | | | IMSI --> Ki | 215 | | | A3(RAND,Ki) = SRES | 216 | | | A8(RAND,Ki) = Kc | 217 | | +----------------+-----+ 218 | | | 219 | |<--- 4.AV (RAND, SRES, Kc) ---| 220 |<-- 5.Auth. Request (RAND) -| | 221 | | | 222 +-----+---------------+ | | 223 | (6) | | | 224 | A3(RAND,Ki) = SRES* | | | 225 | A8(RAND,Ki) = Kc | | | 226 +-----+---------------+ | | 227 | | | 228 |- 7.Auth. Response (SRES*)->| | 229 | | | 230 | +-------+------+ | 231 | | (8) | | 232 | | SRES*= SRES? | | 233 | +-------+------+ | 234 | | | 236 Figure 1. GSM 2G AKA overview 238 1. The mobile subscriber initiates a access/service request towards a 239 server in the serving network. The request contains the IMSI. 241 2. When the request needs to be authenticated, the server queries 242 the AuC of the mobile subscriber's home network to retrieve the 243 necessary material for authenticating the mobile subscriber 244 identified by the IMSI. 246 3. The IMSI received from the server is used as key entry by the AuC 247 to select the corresponding shared secret Ki. The AuC uses the 248 shared secret Ki and a generated random value (RAND) for calculating 249 the expected response (SRES) using the A3 algorithm and the cipher 250 key Kc using the A8 algorithm. the triple RAND, SRES and Kc form an 251 Authentication Vector (AV). 253 4. The authentication vector (RAND, SRES, Kc) is downloaded to a 254 server. Optionally, if request by the server, the AuC can 255 also download more than one authentication vector, each AV generated 256 with a different RAND value. 258 5. The server creates an authentication request, which contains the 259 random challenge RAND and the authentication request is delivered 260 to the client. 262 6. The client produces a authentication response RES, using 263 the shared secret Ki and the random challenge RAND provided in 264 the authentication request received from the server. 266 7. The authentication response RES is delivered to the server. 268 8. The server compares the authentication response RES with the 269 expected response SRES. If the two match, the user has been 270 successfully authenticated, and the session key Kc can be used 271 for protecting further communication between the client and the 272 server 274 5. Example of Digest 2G AKA operations 276 Figure 2 below describes a message flow describing a Digest 2G AKA 277 process of authenticating a SIP request, namely the SIP REGISTER 278 request. 280 SIM HTTP Server AuC 281 (Ki) (Ki) 283 | 1) GET (IMSI) | | 284 |--------------------------->| | 285 | | 2) Authen. Data Request (IMSI)| 286 | |------------------------------>| 287 | | | 288 | | +-----------------+--+ 289 | | | IMSI --> Ki | 290 | | | A3(RAND,Ki) = SRES | 291 | | | A8(RAND,Ki) = Kc | 292 | | +-----------------+--+ 293 | | | 294 | | 3) AV (RAND, SRES, Kc) | 295 | |<------------------------------| 296 | 4) 401 Unauthorized (RAND) | | 297 |<---------------------------| | 298 | | | 299 +-----+---------------+ | | 300 | A3(RAND,Ki) = SRES* | | | 301 | A8(RAND,Ki) = Kc | | | 302 +-----+---------------+ | | 303 | | | 304 | 5) GET (IMSI, RAND, SRES) | | 305 |--------------------------->| | 306 | | | 307 | +-------+------+ | 308 | | SRES*= SRES? | | 309 | +-------+------+ | 310 | | | 311 | 6) 200 OK | | 312 |<---------------------------| | 313 | | | 315 Figure 2: Message flow representing a successful authentication 317 1) Initial request 319 GET / HTTP/1.1 320 Authorization: Digest 321 username="user1_private@home1.net", 322 realm="service1.home1.net", 323 nonce="", 324 uri="/", 325 response="" 327 2) Request to the AuC for 2G AKA authentication vector (AV) for the 328 given IMSI 330 3) Response from the AuC providing 2G AKA AV (RAND, SRES, Kc) 331 associated with the IMSI 333 4) Response containing a challenge 335 HTTP/1.1 401 Unauthorized 336 WWW-Authenticate: Digest 337 realm="service1.home1.net", 338 nonce="base64(RAND)", 339 qop="auth,auth-int", 340 opaque="6dae728da9089dab9112373c9f0a9731", 341 algorithm=2GAKA-MD5 343 5) Request containing credentials 345 GET / HTTP/1.1 346 Authorization: Digest 347 username="user1_private@home1.net", 348 realm="service1.home1.net", 349 nonce="base64(RAND)", 350 uri="/", 351 nc=00000001, 352 cnonce="0b8f29d6", 353 response="6629fae49393a05397450978507c4ef1", 354 opaque="6dae728da9089dab9112373c9f0a9731", 355 algorithm=2GAKA-MD5 357 6) Successful response 359 HTTP/1.1 200 OK 360 Authentication-Info: 361 qop=auth-int, 362 rspauth="6629fae49394a05397450978507c4ef1", 363 cnonce="6629fae49393a05397450978507c4ef1", 364 nc=00000001, 365 opaque="6dae728da9089dab9112373c9f0a9731", 366 nonce="base64(RAND)" 368 6. Specification of Digest 2G AKA 370 In general, the Digest 2G AKA operation is identical to the Digest 371 operation in [RFC2617]. This chapter specifies the parts in which 372 Digest 2G AKA extends the Digest operation. The notation used in the 373 Augmented BNF definitions for the new and modified syntax elements in 374 this section is as used in SIP [RFC3261], and any elements not 375 defined in this section are as defined in SIP and the documents to 376 which it refers. 378 6.1. Algorithm Directive 380 In order to direct the client into using 2G AKA for authentication 381 instead of the standard password system, the RFC 2617 defined 382 algorithm directive is overloaded in Digest 2G AKA: 384 algorithm = "algorithm" EQUAL ( 2GAKA-namespace / algorithm-value 385 ) 387 2GAKA-namespace = "2GAKA" "-" algorithm-value 389 algorithm-value = ( "MD5" / "MD5-sess" / token ) 391 algorithm 393 A string indicating the algorithm used in producing the digest and 394 the checksum. If the directive is not understood, the nonce 395 SHOULD be ignored, and another challenge (if one is present) 396 should be used instead. Reuse of the same SRES value in 397 authenticating subsequent requests and responses is NOT 398 RECOMMENDED. An SRES value SHOULD only be used as a one-time 399 password, and algorithms such as "MD5-sess", which limit the 400 amount of material hashed with a single key, by producing a 401 session key for authentication, SHOULD NOT be used. 403 6.2. Creating a Challenge 405 In order to deliver the GSM 2G AKA authentication challenge to the 406 client in Digest 2G AKA, the nonce directive defined in [RFC2617] is 407 extended: 409 nonce = "nonce" EQUAL ( 2GAKA-nonce / nonce-value ) 411 2GAKA-nonce = LDQUOT 2GAKA-nonce-value RDQUOT 413 2GAKA-nonce-value = 415 nonce 417 A parameter which is populated with the Base64 [RFC2045] encoding 418 of the 2G AKA authentication random challenge RAND. 420 6.3. Client Authentication 422 When a client receives a Digest 2G AKA authentication challenge, it 423 extracts the RAND from the "nonce" parameter and runs the A3-A8 424 algorithms with the RAND challenge and shared secret Ki. 426 The resulting A3-A8 SRES parameter is treated as a "password" when 427 calculating the response directive of [RFC2617]. Due to the fact 428 that the SRES parameter is 32 bits and the response directive of 429 [RFC2617] is defined as 32 hex digits, SRES is encoded in the low 430 order (i.e. rightmost) 32 bits of "response", padded with leading 431 zeroes. 433 Example: 435 SRES="0000000000000000000000007018d8a1" 437 6.4. Server Authentication 439 With Digest 2G AKA, the server MUST use the expected response SRES 440 received in the authentication vector as "password" when calculating 441 the "response-auth" of the "Authentication-Info" header defined in 442 [RFC2617]. 444 7. IANA Considerations 446 IANA is kinly requested to register the following fields in the HTTP 447 Authentication Scheme Registry: 449 o Authentication Scheme Name: Digest-2G-AKA 451 o Pointer to specification text: draft-morand-http-digest-2g-aka-05 453 o Notes: This document specifies a mapping of GSM AKA parameters 454 onto HTTP Digest authentication independent of the GBA 455 architecture defined by 3GPP. 457 8. Security Considerations 459 In general, Digest 2G AKA is vulnerable to the same security threats 460 as HTTP authentication [RFC2617]. This chapter discusses the 461 relevant exceptions. 463 8.1. Authentication of Clients using Digest 2G AKA 465 2G AKA is typically -- though this isn't a theoretical limitation -- 466 run on a SIM application that usually resides in a tamper resistant 467 smart card. Interfaces to the SIM exist, which enable the host 468 device to request authentication to be performed on the card. 469 However, these interfaces do not allow access to the long-term secret 470 outside the SIM, and the authentication can only be performed if the 471 device accessing the SIM has knowledge of a PIN code, shared between 472 the user and the SIM. Such PIN codes are typically obtained from 473 user input, and are usually required when the device is powered on. 475 The use of tamper resistant cards with secure interfaces implies that 476 Digest 2G AKA is typically more secure than regular Digest 477 implementations, as neither possession of the host device nor Trojan 478 Horses in the software give access to the long-term secret. Where a 479 PIN scheme is used, the user is also authenticated when the device is 480 powered on. However, there may be a difference in the resulting 481 security of Digest 2G AKA, compared to traditional Digest 482 implementations, depending on whether those implementations cache/ 483 store passwords that are received from the user. 485 8.2. Limited Use of Nonce Values 487 The Digest scheme uses server-specified nonce values to seed the 488 generation of the request-digest value. The server is free to 489 construct the nonce in such a way that it may only be used from a 490 particular client, for a particular resource, for a limited period of 491 time or number or uses, or any other restrictions. Doing so 492 strengthens the protection provided against, for example, replay 493 attacks. 495 Digest 2G AKA limits the applicability of a nonce value to a 496 particular SIM. Typically, the SIM is accessible only to one client 497 device at a time. However, the nonce values are strong and secure 498 even though limited to a particular SIM. Additionally, this requires 499 that the server is provided with the client identity before an 500 authentication challenge can be generated. If a client identity is 501 not available, an additional round trip is needed to acquire it. 503 8.3. Multiple Authentication Schemes and Algorithms 505 In HTTP authentication, a user agent MUST choose the strongest 506 authentication scheme it understands and request credentials from the 507 user, based upon that challenge. 509 In general, using passwords generated by Digest 2G AKA with other 510 HTTP authentication schemes is not recommended even though the realm 511 values or protection domains would coincide. In these cases, a 512 password should be requested from the end-user instead. Digest 2G 513 AKA passwords MUST NOT be re-used with such HTTP authentication 514 schemes, which send the password in the clear. In particular, 2G AKA 515 passwords must not be re-used with HTTP Basic. 517 The same principle must be applied within a scheme if several 518 algorithms are supported. A client receiving an HTTP Digest 519 challenge with several available algorithms MUST choose the strongest 520 algorithm it understands. For example, Digest with "2GAKA-MD5" would 521 be stronger than Digest with "MD5". 523 8.4. Online Dictionary Attacks 525 Since user-selected passwords are typically quite simple, it has been 526 proposed that servers should not accept passwords for HTTP Digest 527 which are in the dictionary [RFC2617]. This potential threat does 528 not exist in HTTP Digest 2G AKA because the algorithm will use SIM 529 originated passwords. However, the end-user must still be careful 530 with PIN codes. Even though HTTP Digest 2G AKA password requests are 531 never displayed to the end-user, the end-user will be authenticated 532 to the SIM via a PIN code. Commonly known initial PIN codes are 533 typically installed to the SIM during manufacturing and if the end- 534 users do not change them, there is a danger than an unauthorized user 535 may be able to use the device. Naturally this requires that the 536 unauthorized user has access to the physical device, and that the 537 end-user has not changed the initial PIN code. For this reason, end- 538 users are strongly encouraged to change their PIN codes when they 539 receive a SIM. 541 8.5. Session Protection 543 Digest 2G AKA is able to generate an additional session key for 544 integrity (Kc) protection. Even though this document does not 545 specify the use of these additional keys, they may be used for 546 creating additional security within HTTP authentication or some other 547 security mechanisms. 549 8.6. Replay Protection 551 The generation of RAND used as one-time or very limited-use nonces 552 and the use of the integrity protection of qop=auth-int will limit 553 the possibility of replay attacks. 555 In GSM, the network is allowed to re-use the RAND challenge in 556 consecutive authentication exchanges. This is not allowed in Digest 557 2G AKA. The server is mandated to use fresh triplets (RAND 558 challenges) in consecutive authentication exchanges. Digest 2G AKA 559 does not mandate any means for the client to check if the RANDs are 560 fresh, so the security of the scheme leans on the secrecy of the 561 triplets. However, the peer MAY employ implementation-specific 562 mechanisms to remember some of the previously used RANDs, and the 563 client MAY check the freshness of the server's RANDs. 565 8.7. Mutual Authentication 567 With Digest 2G AKA, network authentication is performed only after 568 client authentication, in contrary to Digest AKA [RFC3310] in which 569 the UE authenticates the network before responding to the challenge. 570 To prevent an impersonation attack of the server to the client, the 571 authentication of the server to the UE SHOULD be improved by 572 protecting the communication with Transport Layer Security (TLS). An 573 attacker succeeds only if he can break both, the certificate-based 574 TLS authentication to the client and mutual authentication provided 575 by HTTP Digest using a password derived from GSM procedures. One way 576 to break TLS is to compromise the certificate. However, the risk of 577 clients using the root certificates associated with a compromised 578 Certification Authority (CA) is minimized if the clients use a 579 preconfigured list of trusted root certificates restricted to a low 580 number of CAs trusted by the operator, as opposed to the list of all 581 root certificates in a browser's key store, as described in section 582 8.10. 584 When TLS is used for server authentication, the recommendations given 585 in section 8.10 apply. 587 8.8. Flooding the Authentication Centre 589 The server typically obtains authentication vectors from the 590 Authentication Centre (AuC). Digest 2G AKA introduces a new usage 591 for the AuC. The protocols between the server and the AuC are out of 592 the scope of this document. However, it should be noted that a 593 malicious client may generate a lot of protocol requests to mount a 594 denial of service attack. The server implementation SHOULD take this 595 into account and SHOULD take steps to limit the traffic that it 596 generates towards the AuC, preventing the attacker from flooding the 597 AuC and from extending the denial of service attack from Digest 2G 598 AKA to other users of the AuC. 600 8.9. AKA Security 602 Evolutions of GSM networks, specifically Universal Mobile 603 Telecommunications System (UMTS) and IP Multimedia System (IMS) 604 networks, use an enhanced shared secret based mechanism for 605 authentication known as Authentication and Key Agreement (AKA). In 606 these networks, AKA is typically run in a UMTS Services Identity 607 Module (USIM) or IP Multimedia Services Identity Module (ISIM). GSM 608 phones can also be equipped with a USIM or ISIM. In that case, 609 Digest AKA as described in [RFC3310] is used for authentication as 610 opposed to Digest 2G AKA. 612 8.10. TLS Profile 614 When TLS is used for server authentication prior to the Digest 2G AKA 615 authentication procedures, the following recommendations apply. 617 o The TLS endpoints MUST support TLS version 1.1 as specified in RFC 618 4346 [RFC4346] and SHOULD support TLS version 1.2 as specified in 619 RFC 5246 [RFC5246] should be supported. - 621 o The highest TLS version supported on both TLS endpoints MUST be 622 used. 624 o The TLS endpoints MUST comply with the 3GPP TLS profile given in 625 3GPP TS 33.310, Annex E [TS33.310] is . The only difference is 626 that TLS cipher suites without encryption MUST not be used. 628 o The certificates used for TLS MUST comply with the 3GPP 629 certificate profile defined in the section 6.1 of 3GPP TS 33.310 630 [TS33.310] is . 632 o Support of certificate revocation and of the related fields in 633 certificates is recommended. 635 o Server name matching MUST be performed by the client using the 636 matching rules specified by RFC 2818 [RFC2818] is . 638 o The client MUST use a preconfigured list of trusted root 639 certificates for server certificate validation. 641 o Server certificate validation MUST not require manual user 642 interaction. 644 o The server MUST not request a certificate in a Server Hello 645 Message from the client (as the client is authenticated using 646 Digest 2G AKA as described in section 5). 648 o The TLS endpoints MUST allow for resuming a session. The lifetime 649 of a Session ID is subject to local policies set on the TLS 650 endpoints. 652 9. Acknowledgements 654 This memo is based on an initial draft written by Brett Wallis 655 (draft-ietf-http-digest-auth-a3a8-01). 657 The authors would like to thank Yoav Nir, Yaron Sheffer, Mark 658 Nottingham, Sean Turner, Jari Arkko, Barry Leiba, Adrian Farrel, 659 Stephen Farrell, Nevil Brownlee, Loic Habermacher, Bengt Sahlin and 660 Stefan Schroeder for their valuable comments before, during and after 661 IESG review. 663 10. References 665 10.1. Normative References 667 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 668 Extensions (MIME) Part One: Format of Internet Message 669 Bodies", RFC 2045, November 1996. 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, March 1997. 674 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 675 Leach, P., Luotonen, A., and L. Stewart, "HTTP 676 Authentication: Basic and Digest Access Authentication", 677 RFC 2617, June 1999. 679 10.2. Informative References 681 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 683 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 684 A., Peterson, J., Sparks, R., Handley, M., and E. 685 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 686 June 2002. 688 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 689 Protocol (HTTP) Digest Authentication Using Authentication 690 and Key Agreement (AKA)", RFC 3310, September 2002. 692 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 693 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 695 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 696 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 698 [TS33.220] 699 "Generic Bootstrapping Architecture (GBA)", December 2013. 701 [TS33.310] 702 "Network Domain Security (NDS); Authentication Framework 703 (AF) (Release 12)", June 2013. 705 [TS55.205] 706 "Specification of the GSM- MILENAGE algorithms (Release 707 11)", September 2012. 709 Author's Address 711 Lionel Morand 712 Orange Labs 713 38/40 rue du General Leclerc 714 Issy-Les-Moulineaux Cedex 9 92794 715 France 717 Phone: +33145296257 718 Email: lionel.morand@orange.com