idnits 2.17.1 draft-ietf-http-digest-auth-a3a8-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 535. 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 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 4, 2008) is 5919 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 478, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (ref. '2') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF B. Wallis 3 Internet-Draft Mavenir Systems 4 Intended status: Standards Track February 4, 2008 5 Expires: August 7, 2008 7 Hypertext Transfer Protocol (HTTP) Digest Authentication using Global 8 System for Mobile Communications (GSM) A3 and A8 9 draft-ietf-http-digest-auth-a3a8-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This memo specifies a one-time password generation mechanism for 43 Hypertext Transfer Protocol (HTTP) Digest access authentication based 44 on Global System for Mobile Communications (GSM) authentication and 45 key generation functions A3 and A8. The HTTP Authentication 46 Framework includes two authentication schemes: Basic and Digest. 47 Both schemes employ a shared secret based mechanism for access 48 authentication. The A3-A8 mechanism performs user authentication and 49 session key distribution in GSM and Universal Mobile 50 Telecommunications System (UMTS) networks. A3-A8 is a challenge- 51 response based mechanism that uses symmetric cryptography. 53 Table of Contents 55 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 2. A3-A8 Mechanism Overview . . . . . . . . . . . . . . . . . . . 4 59 3. Specification of Digest A3-A8 . . . . . . . . . . . . . . . . 5 60 3.1. Algorithm Directive . . . . . . . . . . . . . . . . . . . 5 61 3.2. Creating a Challenge . . . . . . . . . . . . . . . . . . . 6 62 3.3. Client Authentication . . . . . . . . . . . . . . . . . . 6 63 3.4. Server Authentication . . . . . . . . . . . . . . . . . . 6 64 4. Example Digest A3-A8 Operation . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 5.1. Authentication of Clients using Digest A3-A8 . . . . . . . 8 67 5.2. Limited Use of Nonce Values . . . . . . . . . . . . . . . 9 68 5.3. Multiple Authentication Schemes and Algorithms . . . . . . 9 69 5.4. Online Dictionary Attacks . . . . . . . . . . . . . . . . 9 70 5.5. Session Protection . . . . . . . . . . . . . . . . . . . . 10 71 5.6. Replay Protection . . . . . . . . . . . . . . . . . . . . 10 72 5.7. Improvements to A3-A8 Security . . . . . . . . . . . . . . 10 73 5.8. AKA Securityy . . . . . . . . . . . . . . . . . . . . . . 10 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 Intellectual Property and Copyright Statements . . . . . . . . . . 12 82 1. Introduction and Motivation 84 The Hypertext Transfer Protocol (HTTP) Authentication Framework, 85 described in RFC 2617 [1], includes two authentication schemes: Basic 86 and Digest. Both schemes employ a shared secret based mechanism for 87 access authentication. The Basic scheme is inherently insecure in 88 that it transmits user credentials in plain text. The Digest scheme 89 improves security by hiding user credentials with cryptographic 90 hashes, and additionally by providing limited message integrity. 92 The GSM A3 and A8 functions [2] perform authentication and session 93 key distribution in Global System for Mobile Communication (GSM) and 94 Universal Mobile Telecommunications System (UMTS) networks. A3-A8 is 95 a challenge- response based mechanism that uses summetric 96 cryptography. A3-A8 is typically run in a GSM Services Identity 97 Module (SIM), which resides on a smart card like device that also 98 provices tamper resistant storage of shared secrets. The 99 Authentication and Key Agreement (AKA) mechanism is most closely 100 associated with UMTS; however, mobile operators commonly distribute 101 GSM SIMs with UMTS mobile phones, resulting in the use of GSM A3-A8 102 in place of AKA. 104 This document specifies a mapping of A3-A8 parameters onto HTTP 105 Digest authentication. In essence, this mapping enables the usage of 106 A3-A8 as a one-time password generation mechanism for Digest 107 authentication. 109 As the Session Initiation Protocol (SIP) [3] Authentication Framework 110 closely follows the HTTP Authentication Framework, Digest A3-A8 is 111 directly applicable to SIP as well as any other embodiment of HTTP 112 Digest. This in turn allows A3-A8 authentication and key generation 113 within the 3GPP IP Multimedia Subsystem (IMS) or other SIP-based core 114 networks. This is of particular use for GSM mobile operators who 115 wish to deploy IMS or other SIP-based core networks while providing 116 support for existing deployed SIMs, which could number in the tens of 117 millions. 119 This document is based heavily on [5] which specified a mapping of 120 Authentication and Key Agreement (AKA) onto HTTP Digest 121 authentication. 123 1.1. Terminology 125 This section explains the terminology used in this document. 127 AuC Authentication Center. 129 GSM Global System for Mobile Communication. 131 IMS IP Multimedia Subsystem. 133 ISIM IP Multimedia Services Identity Module. IMS counterpart to 134 SIM. 136 Kc Cypher Key. 138 Ki Subscriber Key. 140 RAND Random Challenge. Generated by the AuC. 142 SIM Subscriber Identity Module. 144 SRES Signed Authentication Response. Generated by the SIM. 146 UMTS Universal Mobile Telecommunications System. 148 USIM Universal Mobile Telecommunications System. UMTS counterpart 149 to SIM. 151 1.2. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [1]. 157 2. A3-A8 Mechanism Overview 159 This chapter describes the GSM A3-A8 operation in detail: 161 1. A shared secret Ki is established beforehand between the SIM and 162 the Authentication Center (AuC). The secret is stored in the 163 SIM, which resides on a smart card like, tamper resistant device. 165 2. The AuC of the home network produces an authentication vector AV, 166 based on the shared secret Ki. The authentication vector 167 contains a random challenge RAND, an expected authentication 168 result, and a session key for ciphering Kc. 170 3. The authentication vector is downloaded to a server. Optionally, 171 the server can also download a batch of AVs, containing more than 172 one authentication vector. 174 4. The server creates an authentication request, which contains the 175 random challenge RAND. 177 5. The authentication request is delivered to the client. 179 6. The client produces a signed authentication response SRES, using 180 the shared secret Ki and the random challenge RAND. 182 7. The authentication response SRES is delivered to the server. 184 8. The server compares the authentication response SRES with the 185 expected response. If the two match, the user has been 186 successfully authenticated, and the session key Kc can be used 187 for protecting further communication between the client and the 188 server. 190 3. Specification of Digest A3-A8 192 In general, the Digest A3-A8 operation is identical to the Digest 193 operation in RFC 2617 [1]. This chapter specifies the parts in which 194 Digest A3-A8 extends the Digest operation. The notation used in the 195 Augmented BNF definitions for the new and modified syntax elements in 196 this section is as used in SIP [3], and any elements not defined in 197 this section are as defined in SIP and the documents to which it 198 refers. 200 3.1. Algorithm Directive 202 In order to direct the client to use A3-A8 for authentication instead 203 of the standard password system, the RFC 2617 defined algorithm 204 directive specifies Digest A3A8. 206 algorithm = "algorithm" EQUAL ( a3a8-namespace 207 / algorithm-value ) 208 a3a8-namespace = "A3-A8" "-" algorithm-value 209 algorithm-value = ( "MD5" / "MD5-sess" / token ) 211 algorithm 212 A string indicating the algorithm used in producing the digest 213 and the checksum. If the directive is not understood, the nonce 214 SHOULD be ignored, and another challenge (if one is present) 215 should be used instead. 217 Reuse of the same SRES value in authenticating subsequent 218 requests and responses is NOT RECOMMENDED. An SRES value SHOULD 219 only be used as a one-time password, and algorithms such as "MD5- 220 sess", which limit the amount of material hashed with a single 221 key, by producing a session key for authentication, SHOULD NOT be 222 used. 224 3.2. Creating a Challenge 226 In order to deliver the A3-A8 authentication challenge to the client 227 in Digest Ae-A8, the nonce directive defined in [2] is extended: 229 nonce = "nonce" EQUAL ( a3a8-nonce / nonce-value ) 230 a3a8-nonce = LDQUOT a3a8-nonce-value RDQUOT 231 a3a8-value-value = 233 nonce 234 A parameter which is populated with the Base64 [4] encoding of 235 the A3-A8 authentication random challenge RAND. 237 3.3. Client Authentication 239 When a client receives a Digest A3-A8 authentication challenge, it 240 extracts the RAND from the "nonce" parameter an druns the A3-A8 241 algorithms with the RAND challenge and shared secret Ki. 243 The resulting A3-A8 SRES parameter is treated as a "password" when 244 calculating the response directive of [2]. Due to the fact that that 245 the SRES parameter is 32 bits and the response directive of [2] is 246 defined as 32 hex digits, SRES is encoded in the low order (i.e. 247 rightmost) 32 bits of "response", padded with leading zeroes. 249 Example: 251 response="0000000000000000000000007018d8a1" 253 3.4. Server Authentication 255 With Digest A3-A8, the server uses the expected response received in 256 the authentication vector as "password" when calculating the 257 "response-auth" of the "Authentication-Info" header defined in [2]. 259 4. Example Digest A3-A8 Operation 261 Figure 2 below describes a message flow describing a Digest A3-A8 262 process of authenticating a SIP request, namely the SIP REGISTER 263 request. 265 Client Server 267 | 1) REGISTER | 268 |---------------------------------------------------------->| 269 | | 270 | +-------------------------------+ 271 | | Server runs A3-A8 algorithms, | 272 | | generates RAND. | 273 | +-------------------------------+ 274 | | 275 | 2) 401 Unauthroized | 276 | WWW-Authenticate: Digest (RAND delivered) | 277 |<----------------------------------------------------------| 278 | | 279 +-------------------------------------+ | 280 | Client runs A3-A8 algorithm on SIM, | | 281 | derives SRES and session keys. | | 282 +-------------------------------------+ | 283 | | 284 | 3) REGISTER | 285 | Authorization: Digest (SRES is used) | 286 |---------------------------------------------------------->| 287 | | 288 | +-------------------------------+ 289 | | Server checks the given SERS | 290 | | and finds it correct. | 291 | +-------------------------------+ 292 | | 293 | 4) 200 OK | 294 | Authentication-Info: (SRES is used) | 295 |<----------------------------------------------------------| 296 | | 298 Figure 1: Message flow representing a successful authentication 300 1) Initial request 302 REGISTER sip:home.mobile.example.com SIP/2.0 304 2) Response containing a challenge 306 SIP/2.0 401 Unauthorized 307 WWW-Authenticate: Digest 308 realm="RoamingUsers@example.com", 309 nonce="I1U8vpY3pJ0hiuZNrke/NQ==", 310 qop="auth,auth-int", 311 opaque="6dae728da9089dab9112373c9f0a9731", 312 algorithm=A3-A8-MD5 314 3) Request containing credentials 316 REGISTER sip:home.mobile.example.com SIP/2.0 317 Authorization: Digest 318 username="adam.smith@example.com", 319 realm="RoamingUsers@example.com", 320 nonce="I1U8vpY3pJ0hiuZNrke/NQ==", 321 qop=auth-int, 322 nc=00000001, 323 cnonce="0b8f29d6", 324 response="00000000000000000000000046f8416a", 325 opaque="6dae728da9089dab9112373c9f0a9731" 327 4) Successful response 329 SIP/2.0 200 OK 330 Authentication-Info: 331 qop=auth-int, 332 rspauth="00000000000000000000000046f8416a", 333 cnonce="0b8f29d6", 334 nc=00000001 336 5. Security Considerations 338 In general, Digest A3-A8 is vulnerable to the same security threats 339 as HTTP authentication [2]. This chapter discusses the relevant 340 exceptions. 342 5.1. Authentication of Clients using Digest A3-A8 344 A3-A8 is typically -- though this isn't a theoretical limitation -- 345 run on a SIM application that usually resides in a tamper resistant 346 smart card. Interfaces to the SIM exist, which enable the host 347 device to request authentication to be performed on the card. 348 However, these interfaces do not allow access to the long-term secret 349 outside the SIM, and the authentication can only be performed if the 350 device accessing the SIM has knowledge of a PIN code, shared between 351 the user and the SIM. Such PIN codes are typically obtained from 352 user input, and are usually required when the device is powered on. 354 The use of tamper resistant cards with secure interfaces implies that 355 Digest A3-A8 is typically more secure than regular Digest 356 implementations, as neither possession of the host device nor Trojan 357 Horses in the software give access to the long-term secret. Where a 358 PIN scheme is used, the user is also authenticated when the device is 359 powered on. However, there may be a difference in the resulting 360 security of Digest A3-A8, compared to traditional Digest 361 implementations, depending on whether those implementations cache/ 362 store passwords that are received from the user. 364 5.2. Limited Use of Nonce Values 366 The Digest scheme uses server-specified nonce values to seed the 367 generation of the request-digest value. The server is free to 368 construct the nonce in such a way that it may only be used from a 369 particular client, for a particular resource, for a limited period of 370 time or number or uses, or any other restrictions. Doing so 371 strengthens the protection provided against, for example, replay 372 attacks. 374 Digest A3-A8 limits the applicability of a nonce value to a 375 particular SIM. Typically, the SIM is accessible only to one client 376 device at a time. However, the nonce values are strong and secure 377 even though limited to a particular SIM. Additionally, this requires 378 that the server is provided with the client identity before an 379 authentication challenge can be generated. If a client identity is 380 not available, an additional round trip is needed to acquire it. 382 5.3. Multiple Authentication Schemes and Algorithms 384 In HTTP authentication, a user agent MUST choose the strongest 385 authentication scheme it understands and request credentials from the 386 user, based upon that challenge. 388 In general, using passwords generated by Digest A3-A8 with other HTTP 389 authentication schemes is not recommended even though the realm 390 values or protection domains would coincide. In these cases, a 391 password should be requested from the end-user instead. Digest A3-A8 392 passwords MUST NOT be re-used with such HTTP authentication schemes, 393 which send the password in the clear. In particular, A3-A8 passwords 394 must not be re-used with HTTP Basic. 396 The same principle must be applied within a scheme if several 397 algorithms are supported. A client receiving an HTTP Digest 398 challenge with several available algorithms MUST choose the strongest 399 algorithm it understands. For example, Digest with "A3-A8-MD5" would 400 be stronger than Digest with "MD5". 402 5.4. Online Dictionary Attacks 404 Since user-selected passwords are typically quite simple, it has been 405 proposed that servers should not accept passwords for HTTP Digest 406 which are in the dictionary [2]. This potential threat does not 407 exist in HTTP Digest A3-A8 because the algorithm will use SIM 408 originated passwords. However, the end-user must still be careful 409 with PIN codes. Even though HTTP Digest A3-A8 password requests are 410 never displayed to the end-user, she will be authenticated to the SIM 411 via a PIN code. Commonly known initial PIN codes are typically 412 installed to the SIM during manufacturing and if the end-users do not 413 change them, there is a danger than an unauthorized user may be able 414 to use the device. Naturally this requirse that the unauthorized 415 user has access to the physical device, and that the end-user has not 416 changed the initial PIN code. For this reason, end-users are 417 strongly encouraged to change their PIN codes when they receive a 418 SIM. 420 5.5. Session Protection 422 Digest A3-A8 is able to generate an additional session key for 423 integrity (Kc) protection. Even though this document does not 424 specify the use of these additional keys, they may be used for 425 creating additional security within HTTP authentication or some other 426 security mechanisms. 428 5.6. Replay Protection 430 5.7. Improvements to A3-A8 Security 432 Even though A3-A8 is perceived as a secure mechanism, Digest A3-A8 is 433 able to improve it. More specifically, the A3-A8 parameters carried 434 between the client and the server during authentication may be 435 protected along with other parts of the message by using Digest 436 A3-A8. This is not possible with plain A3-A8. 438 5.8. AKA Securityy 440 Evolutions of GSM networks, specifically Universal Mobile 441 Telecommunications System (UMTS) and IP Multimedia System (IMS) 442 networks, use an enhanced shared secret based mechanism for 443 authentication known as Authentication and Key Agreement (AKA). In 444 these networks, AKA is typically run in a UMTS Services Identity 445 Module (USIM) or IP Multimedia Services Identity Module (ISIM). GSM 446 phones can also be equipped with a USIM, in which case AKA is used 447 for authentication as opposed to A3-A8. 449 6. IANA Considerations 451 This memo includes no request to IANA. 453 7. References 455 7.1. Normative References 457 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 458 Levels", BCP 14, RFC 2119, March 1997 460 [2] Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., 461 Luotonen, A.,, Stewart, L., "HTTP Authentication: Basic and 462 Digest Access Authentication", RFC 2617, June 1999 464 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 465 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 466 Session Initiation Protocol", RFC 3261, June 2002. 468 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 469 Extensions (MIME) Part One: Format of Internet Message Bodies", 470 RFC 2045, November 1996. 472 7.2. Informative References 474 [5] Niemi, A. and V. Torvinen, "Hypertext Transfer Protocol (HTTP) 475 Digest Authentication Using Authentication and Key Agreement 476 (AKA)", RFC 3310, September 2002. 478 [6] 3rd Generation Partnership Project, "Specification of the GSM- 479 MILENAGE algorithms (Release 7)", TS 55.205, June 2007 481 Appendix A. Acknowledgements 483 This template was derived from an initial version written by Pekka 484 Savola and contributed by him to the xml2rfc project. 486 Author's Address 488 Brett Wallis 489 Mavenir Systems 490 1651 N. Glenville Dr., Ste #201 491 Richardson, TX 75081 492 US 494 Phone: +1 469 916 4393 x5048 495 Email: brett@mavenir.com 497 Full Copyright Statement 499 Copyright (C) The IETF Trust (2008). 501 This document is subject to the rights, licenses and restrictions 502 contained in BCP 78, and except as set forth therein, the authors 503 retain all their rights. 505 This document and the information contained herein are provided on an 506 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 507 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 508 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 509 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 510 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 511 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 513 Intellectual Property 515 The IETF takes no position regarding the validity or scope of any 516 Intellectual Property Rights or other rights that might be claimed to 517 pertain to the implementation or use of the technology described in 518 this document or the extent to which any license under such rights 519 might or might not be available; nor does it represent that it has 520 made any independent effort to identify any such rights. Information 521 on the procedures with respect to rights in RFC documents can be 522 found in BCP 78 and BCP 79. 524 Copies of IPR disclosures made to the IETF Secretariat and any 525 assurances of licenses to be made available, or the result of an 526 attempt made to obtain a general license or permission for the use of 527 such proprietary rights by implementers or users of this 528 specification can be obtained from the IETF on-line IPR repository at 529 http://www.ietf.org/ipr. 531 The IETF invites any interested party to bring to its attention any 532 copyrights, patents or patent applications, or other proprietary 533 rights that may cover technology that may be required to implement 534 this standard. Please address the information to the IETF at 535 ietf-ipr@ietf.org. 537 Acknowledgment 539 Funding for the RFC Editor function is provided by the IETF 540 Administrative Support Activity (IASA).