idnits 2.17.00 (12 Aug 2021) /tmp/idnits3135/draft-morand-http-digest-2g-aka-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 (September 7, 2010) is 4274 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Hypertext Transfer Protocol Bis L. Morand 3 (httpbis) France Telecom - Orange 4 Internet-Draft September 7, 2010 5 Intended status: Informational 6 Expires: March 11, 2011 8 Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G 9 Authentication and Key Agreement (AKA) 10 draft-morand-http-digest-2g-aka-00 12 Abstract 14 This memo specifies a one-time password generation mechanism for 15 Hypertext Transfer Protocol (HTTP) Digest access authentication based 16 on Global System for Mobile Communications (GSM) authentication and 17 key generation functions A3 and A8, also known as GSM AKA or 2G AKA. 18 The HTTP Authentication Framework includes two authentication 19 schemes: Basic and Digest. Both schemes employ a shared secret based 20 mechanism for access authentication. The GSM AKA mechanism performs 21 user authentication and session key distribution in GSM and Universal 22 Mobile Telecommunications System (UMTS) networks. GSM AKA is a 23 challenge-response based mechanism that uses symmetric cryptography. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 11, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. GSM 2G AKA Mechanism Overview . . . . . . . . . . . . . . . . 4 68 5. Specification of Digest 2G AKA . . . . . . . . . . . . . . . . 6 69 5.1. Algorithm Directive . . . . . . . . . . . . . . . . . . . 6 70 5.2. Creating a Challenge . . . . . . . . . . . . . . . . . . . 7 71 5.3. Client Authentication . . . . . . . . . . . . . . . . . . 7 72 5.4. Server Authentication . . . . . . . . . . . . . . . . . . 8 73 6. Example of Digest 2G AKA operations . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 8.1. Authentication of Clients using Digest 2G AKA . . . . . . 11 77 8.2. Limited Use of Nonce Values . . . . . . . . . . . . . . . 11 78 8.3. Multiple Authentication Schemes and Algorithms . . . . . . 12 79 8.4. Online Dictionary Attacks . . . . . . . . . . . . . . . . 12 80 8.5. Session Protection . . . . . . . . . . . . . . . . . . . . 12 81 8.6. Replay Protection . . . . . . . . . . . . . . . . . . . . 13 82 8.7. Mutual Authentication . . . . . . . . . . . . . . . . . . 13 83 8.8. Flooding the Authentication Centre . . . . . . . . . . . . 13 84 8.9. AKA Security . . . . . . . . . . . . . . . . . . . . . . . 13 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction and Motivation 93 The Hypertext Transfer Protocol (HTTP) Authentication Framework, 94 described in [RFC2617], includes two authentication schemes: Basic 95 and Digest. Both schemes employ a shared secret based mechanism for 96 access authentication. The Basic scheme is inherently insecure in 97 that it transmits user credentials in plain text. The Digest scheme 98 improves security by hiding user credentials with cryptographic 99 hashes, and additionally by providing limited message integrity. 101 The 2G AKA functions [TS55.205] perform authentication and session 102 key distribution in Global System for Mobile Communication (GSM) and 103 Universal Mobile Telecommunications System (UMTS) networks. 2G AKA is 104 a challenge-response based mechanism that uses symmetric 105 cryptography. GSM AKA is typically run in a GSM Subscriber Identity 106 Module (SIM), which resides in a smart card like device that also 107 provides tamper resistant storage of shared secrets. The 3G 108 Authentication and Key Agreement (AKA) mechanism, also known as UMTS 109 AKA, relying on the use of the UMTS Subscriber Identity Module (USIM) 110 instead of the GSM SIM, is most closely associated with UMTS; 111 however, mobile operators commonly distribute GSM SIMs with UMTS 112 mobile phones, resulting in the use of GSM 2G AKA in place of UMTS 113 AKA. 115 This document specifies a mapping of GSM AKA parameters onto HTTP 116 Digest authentication. In essence, this mapping enables the usage of 117 GSM 2G AKA as a one-time password generation mechanism for Digest 118 authentication. 120 This document is based heavily on [RFC3310] which specified a mapping 121 of Authentication and Key Agreement (AKA) onto HTTP Digest 122 authentication. While Digest AKA can be generally used when the 123 mobile phones are equipped with a UMTS SIM card, it may be useful for 124 mobile operators who have not yet fully deployed USIMs and have still 125 millions of SIMs deployed in the network. Digest 2G AKA allows 126 access to applications in a more secure way than would be possible 127 with the use of passwords or with GSM without enhancements. 129 Moreover, as the Session Initiation Protocol (SIP) [RFC3261] 130 Authentication Framework closely follows the HTTP Authentication 131 Framework, Digest 2G AKA is directly applicable to SIP as well as to 132 any other embodiment of HTTP Digest. 134 2. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 3. Terminology 142 This section explains the terminology used in this document. 144 AuC Authentication Center. 146 AKA Authentication and Key Agreement. 148 GSM Global System for Mobile Communication. 150 IMS IP Multimedia Subsystem. 152 ISIM IMS Subscriber Identity Module. 154 Kc Cypher Key. Ki Subscriber Key. 156 RAND Random Challenge. 158 SIM Subscriber Identity Module. 160 SRES Signed Authentication Response. 162 UMTS Universal Mobile Telecommunications System. 164 USIM UMTS Subscriber Identity Module. 166 4. GSM 2G AKA Mechanism Overview 168 This chapter describes the GSM AKA mechanism based on a shared secret 169 key (Ki) and the use of A3/A8 algorithms: 171 1. A shared secret Ki is established beforehand between the SIM and 172 the Authentication Center (AuC). The secret is stored in the 173 SIM, which resides on a smart card like, tamper resistant device. 175 2. The AuC of the home network produces an authentication vector 176 (AV), based on the shared secret Ki and a generated random value 177 (RAND). Using Ki and RAND, the A3 algorihm is used for 178 calculating the expected response (SRES) and the A8 algorithm is 179 used for calculating the ciffering key Kc. 181 3. The authentication vector (RAND, SRES, Kc) is downloaded to a 182 server. Optionally, the server can also download a batch of AVs, 183 containing more than one authentication vector generated by 184 adding different RAND values. 186 4. The server creates an authentication request, which contains the 187 random challenge RAND. 189 5. The authentication request is delivered to the client. 191 6. The client produces a signed authentication response RES, using 192 the shared secret Ki and the random challenge RAND. 194 7. The authentication response RES is delivered to the server. 196 8. The server compares the authentication response RES with the 197 expected response SRES. If the two match, the user has been 198 successfully authenticated, and the session key Kc can be used 199 for protecting further communication between the client and the 200 server 201 SIM Server AuC 202 (Ki) (Ki) 204 | | | 205 |--- Request (IMSI) ------>| | 206 | | Authen. Data Request (IMSI) | 207 | |---------------------------->| 208 | | | 209 | | +-----------------+----+ 210 | | | IMSI --> Ki | 211 | | | A3(RAND,Ki) = SRES | 212 | | | A8(RAND,Ki) = Kc | 213 | | +----------------+-----+ 214 | | | 215 | |<--- AV (RAND, SRES, Kc) ---| 216 |<-- Auth. Request (RAND) -| | 217 | | | 218 +-----+---------------+ | | 219 | A3(RAND,Ki) = SRES* | | | 220 | A8(RAND,Ki) = Kc | | | 221 +-----+---------------+ | | 222 | | | 223 |- Auth. Response (SRES*)->| | 224 | | | 225 | +-------+------+ | 226 | | SRES*= SRES? | | 227 | +-------+------+ | 228 | | | 230 Figure 1. GSM 2G AKA overview 232 5. Specification of Digest 2G AKA 234 In general, the Digest GSM AKA operation is identical to the Digest 235 operation in [RFC2617]. This chapter specifies the parts in which 236 Digest 2G AKA extends the Digest operation. The notation used in the 237 Augmented BNF definitions for the new and modified syntax elements in 238 this section is as used in SIP [RFC3261], and any elements not 239 defined in this section are as defined in SIP and the documents to 240 which it refers. 242 5.1. Algorithm Directive 244 In order to direct the client into using 2G AKA for authentication 245 instead of the standard password system, the RFC 2617 defined 246 algorithm directive is overloaded in Digest 2G AKA: 248 algorithm = "algorithm" EQUAL ( 2GAKA-namespace / algorithm-value 249 ) 251 2GAKA-namespace = "2GAKA" "-" algorithm-value 253 algorithm-value = ( "MD5" / "MD5-sess" / token ) 255 algorithm 257 A string indicating the algorithm used in producing the digest and 258 the checksum. If the directive is not understood, the nonce 259 SHOULD be ignored, and another challenge (if one is present) 260 should be used instead. Reuse of the same SRES value in 261 authenticating subsequent requests and responses is NOT 262 RECOMMENDED. An SRES value SHOULD only be used as a one-time 263 password, and algorithms such as "MD5-sess", which limit the 264 amount of material hashed with a single key, by producing a 265 session key for authentication, SHOULD NOT be used. 267 5.2. Creating a Challenge 269 In order to deliver the GSM AKA authentication challenge to the 270 client in Digest 2G AKA, the nonce directive defined in [RFC2617] is 271 extended: 273 nonce = "nonce" EQUAL ( 2GAKA-nonce / nonce-value ) 275 2GAKA-nonce = LDQUOT 2GAKA-nonce-value RDQUOT 277 2GAKA-nonce-value = 279 nonce 281 A parameter which is populated with the Base64 [RFC2045] encoding 282 of the 2G AKA authentication random challenge RAND. 284 5.3. Client Authentication 286 When a client receives a Digest 2G AKA authentication challenge, it 287 extracts the RAND from the "nonce" parameter and runs the A3-A8 288 algorithms with the RAND challenge and shared secret Ki. 290 The resulting A3-A8 SRES parameter is treated as a "password" when 291 calculating the response directive of [RFC2617]. Due to the fact 292 that the SRES parameter is 32 bits and the response directive of 293 [RFC2617] is defined as 32 hex digits, SRES is encoded in the low 294 order (i.e. rightmost) 32 bits of "response", padded with leading 295 zeroes. 297 Example: 299 SRES="0000000000000000000000007018d8a1" 301 5.4. Server Authentication 303 With Digest 2G AKA, the server MUST use the expected response SRES 304 received in the authentication vector as "password" when calculating 305 the "response-auth" of the "Authentication-Info" header defined in 306 [RFC2617]. 308 6. Example of Digest 2G AKA operations 310 Figure 2 below describes a message flow describing a Digest 2G AKA 311 process of authenticating a SIP request, namely the SIP REGISTER 312 request. 314 SIM HTTP Server AuC 315 (Ki) (Ki) 317 | 1) GET (IMSI) | | 318 |--------------------------->| | 319 | | 2) Authen. Data Request (IMSI)| 320 | |------------------------------>| 321 | | | 322 | | +-----------------+--+ 323 | | | IMSI --> Ki | 324 | | | A3(RAND,Ki) = SRES | 325 | | | A8(RAND,Ki) = Kc | 326 | | +-----------------+--+ 327 | | | 328 | | 3) AV (RAND, SRES, Kc) | 329 | |<------------------------------| 330 | 4) 401 Unauthorized (RAND) | | 331 |<---------------------------| | 332 | | | 333 +-----+---------------+ | | 334 | A3(RAND,Ki) = SRES* | | | 335 | A8(RAND,Ki) = Kc | | | 336 +-----+---------------+ | | 337 | | | 338 | 5) GET (IMSI, RAND, SRES) | | 339 |--------------------------->| | 340 | | | 341 | +-------+------+ | 342 | | SRES*= SRES? | | 343 | +-------+------+ | 344 | | | 345 | 6) 200 OK | | 346 |<---------------------------| | 347 | | | 349 Figure 2: Message flow representing a successful authentication 351 1) Initial request 353 GET / HTTP/1.1 354 Authorization: Digest 355 username="user1_private@home1.net", 356 realm="service1.home1.net", 357 nonce="", 358 uri="/", 359 response="" 361 2) Request to the AuC for 2G AKA authentication vector (AV) for the 362 given IMSI 364 3) Response from the AuC providing 2G AKA AV (RAND, SRES, Kc) 365 associated with the IMSI 367 4) Response containing a challenge 369 HTTP/1.1 401 Unauthorized 370 WWW-Authenticate: Digest 371 realm="service1.home1.net", 372 nonce="base64(RAND)", 373 qop="auth,auth-int", 374 opaque="6dae728da9089dab9112373c9f0a9731", 375 algorithm=2GAKA-MD5 377 5) Request containing credentials 379 GET / HTTP/1.1 380 Authorization: Digest 381 username="user1_private@home1.net", 382 realm="service1.home1.net", 383 nonce="base64(RAND)", 384 uri="/", 385 nc=00000001, 386 cnonce="0b8f29d6", 387 response="6629fae49393a05397450978507c4ef1", 388 opaque="6dae728da9089dab9112373c9f0a9731", 389 algorithm=2GAKA-MD5 391 6) Successful response 393 HTTP/1.1 200 OK 394 Authentication-Info: 395 qop=auth-int, 396 rspauth="6629fae49394a05397450978507c4ef1", 397 cnonce="6629fae49393a05397450978507c4ef1", 398 nc=00000001, 399 opaque="6dae728da9089dab9112373c9f0a9731", 400 nonce="base64(RAND)" 402 7. IANA Considerations 404 This document has no actions for IANA. 406 Note to RFC Editor: this section may be removed on publication as an 407 RFC. 409 8. Security Considerations 411 In general, Digest 2G AKA is vulnerable to the same security threats 412 as HTTP authentication [RFC2617]. This chapter discusses the 413 relevant exceptions. 415 8.1. Authentication of Clients using Digest 2G AKA 417 2G AKA is typically -- though this isn't a theoretical limitation -- 418 run on a SIM application that usually resides in a tamper resistant 419 smart card. Interfaces to the SIM exist, which enable the host 420 device to request authentication to be performed on the card. 421 However, these interfaces do not allow access to the long-term secret 422 outside the SIM, and the authentication can only be performed if the 423 device accessing the SIM has knowledge of a PIN code, shared between 424 the user and the SIM. Such PIN codes are typically obtained from 425 user input, and are usually required when the device is powered on. 427 The use of tamper resistant cards with secure interfaces implies that 428 Digest 2G AKA is typically more secure than regular Digest 429 implementations, as neither possession of the host device nor Trojan 430 Horses in the software give access to the long-term secret. Where a 431 PIN scheme is used, the user is also authenticated when the device is 432 powered on. However, there may be a difference in the resulting 433 security of Digest 2G AKA, compared to traditional Digest 434 implementations, depending on whether those implementations cache/ 435 store passwords that are received from the user. 437 8.2. Limited Use of Nonce Values 439 The Digest scheme uses server-specified nonce values to seed the 440 generation of the request-digest value. The server is free to 441 construct the nonce in such a way that it may only be used from a 442 particular client, for a particular resource, for a limited period of 443 time or number or uses, or any other restrictions. Doing so 444 strengthens the protection provided against, for example, replay 445 attacks. 447 Digest 2G AKA limits the applicability of a nonce value to a 448 particular SIM. Typically, the SIM is accessible only to one client 449 device at a time. However, the nonce values are strong and secure 450 even though limited to a particular SIM. Additionally, this requires 451 that the server is provided with the client identity before an 452 authentication challenge can be generated. If a client identity is 453 not available, an additional round trip is needed to acquire it. 455 8.3. Multiple Authentication Schemes and Algorithms 457 In HTTP authentication, a user agent MUST choose the strongest 458 authentication scheme it understands and request credentials from the 459 user, based upon that challenge. 461 In general, using passwords generated by Digest 2G AKA with other 462 HTTP authentication schemes is not recommended even though the realm 463 values or protection domains would coincide. In these cases, a 464 password should be requested from the end-user instead. Digest 2G 465 AKA passwords MUST NOT be re-used with such HTTP authentication 466 schemes, which send the password in the clear. In particular, 2G AKA 467 passwords must not be re-used with HTTP Basic. 469 The same principle must be applied within a scheme if several 470 algorithms are supported. A client receiving an HTTP Digest 471 challenge with several available algorithms MUST choose the strongest 472 algorithm it understands. For example, Digest with "2GAKA-MD5" would 473 be stronger than Digest with "MD5". 475 8.4. Online Dictionary Attacks 477 Since user-selected passwords are typically quite simple, it has been 478 proposed that servers should not accept passwords for HTTP Digest 479 which are in the dictionary [RFC2617]. This potential threat does 480 not exist in HTTP Digest 2G AKA because the algorithm will use SIM 481 originated passwords. However, the end-user must still be careful 482 with PIN codes. Even though HTTP Digest 2G AKA password requests are 483 never displayed to the end-user, the end-user will be authenticated 484 to the SIM via a PIN code. Commonly known initial PIN codes are 485 typically installed to the SIM during manufacturing and if the end- 486 users do not change them, there is a danger than an unauthorized user 487 may be able to use the device. Naturally this requires that the 488 unauthorized user has access to the physical device, and that the 489 end-user has not changed the initial PIN code. For this reason, end- 490 users are strongly encouraged to change their PIN codes when they 491 receive a SIM. 493 8.5. Session Protection 495 Digest 2G AKA is able to generate an additional session key for 496 integrity (Kc) protection. Even though this document does not 497 specify the use of these additional keys, they may be used for 498 creating additional security within HTTP authentication or some other 499 security mechanisms. 501 8.6. Replay Protection 503 The generation of RAND used as one-time or very limited-use nonces 504 and the use of the integrity protection of qop=auth-int will limit 505 the possibility of replay attacks. 507 In GSM, the network is allowed to re-use the RAND challenge in 508 consecutive authentication exchanges. This is not allowed in Digest 509 2G AKA. The server is mandated to use fresh triplets (RAND 510 challenges) in consecutive authentication exchanges. Digest 2G AKA 511 does not mandate any means for the client to check if the RANDs are 512 fresh, so the security of the scheme leans on the secrecy of the 513 triplets. However, the peer MAY employ implementation-specific 514 mechanisms to remember some of the previously used RANDs, and the 515 client MAY check the freshness of the server's RANDs. 517 8.7. Mutual Authentication 519 With Digest 2G AKA, network authentication is performed only after UE 520 authentication, in contrary to Digest AKA [RFC3310] in which the UE 521 authenticates the network before responding to the challenge. To 522 prevent an impersonation attack of the server to the UE, the 523 authentication of the server to the UE SHOULD be improved by 524 protecting the communication with TLS. An attacker succeeds only if 525 he can break both, the certificate-based TLS authentication to the UE 526 and mutual authentication provided by HTTP Digest using a password 527 derived from GSM procedures. One way to break TLS is to compromise 528 the certificate. 530 8.8. Flooding the Authentication Centre 532 The server typically obtains authentication vectors from the 533 Authentication Centre (AuC). Digest 2G AKA introduces a new usage 534 for the AuC. The protocols between the server and the AuC are out of 535 the scope of this document. However, it should be noted that a 536 malicious client may generate a lot of protocol requests to mount a 537 denial of service attack. The server implementation SHOULD take this 538 into account and SHOULD take steps to limit the traffic that it 539 generates towards the AuC, preventing the attacker from flooding the 540 AuC and from extending the denial of service attack from Digest 2G 541 AKA to other users of the AuC. 543 8.9. AKA Security 545 Evolutions of GSM networks, specifically Universal Mobile 546 Telecommunications System (UMTS) and IP Multimedia System (IMS) 547 networks, use an enhanced shared secret based mechanism for 548 authentication known as Authentication and Key Agreement (AKA). In 549 these networks, AKA is typically run in a UMTS Services Identity 550 Module (USIM) or IP Multimedia Services Identity Module (ISIM). GSM 551 phones can also be equipped with a USIM or ISIM. In that case, 552 Digest AKA as described in [RFC3310] is used for authentication as 553 opposed to Digest 2G AKA. 555 9. Acknowledgements 557 This memo is based on an initial draft written by Brett Wallis 558 (draft-ietf-http-digest-auth-a3a8-01). 560 10. References 562 10.1. Normative References 564 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 565 Extensions (MIME) Part One: Format of Internet Message 566 Bodies", RFC 2045, November 1996. 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 572 Leach, P., Luotonen, A., and L. Stewart, "HTTP 573 Authentication: Basic and Digest Access Authentication", 574 RFC 2617, June 1999. 576 10.2. Informative References 578 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 579 A., Peterson, J., Sparks, R., Handley, M., and E. 580 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 581 June 2002. 583 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 584 Protocol (HTTP) Digest Authentication Using Authentication 585 and Key Agreement (AKA)", RFC 3310, September 2002. 587 [TS55.205] 588 "Specification of the GSM- MILENAGE algorithms (Release 589 9)", December 2009. 591 Author's Address 593 Lionel Morand 594 France Telecom - Orange 595 38-40 rue du general Leclerc 596 Issy-Les-Moulineaux Cedex 9 92794 597 France 599 Phone: +33 1 4529 6257 600 Email: lionel.morand@orange-ftgroup.com