idnits 2.17.1 draft-arkko-pppext-eap-aka-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 2001) is 8381 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2486 (ref. '5') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2284 (ref. '6') (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 J. Arkko 3 Internet Draft Ericsson 4 Document: draft-arkko-pppext-eap-aka-00.txt H. Haverinen 5 Expires: December 2001 Nokia 6 May 2001 8 EAP AKA Authentication 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document specifies an Extensible Authentication Protocol (EAP) 33 mechanism for authentication and session key distribution using the 34 UMTS AKA authentication mechanism. AKA is based on symmetric keys, 35 and runs in a UMTS Subscriber Identity Module, a smart card like 36 device. AKA provides also backward compatibility to GSM 37 authentication, making it possible to use EAP AKA for authenticating 38 both GSM and UMTS subscribers. 40 Table of Contents 42 Status of this Memo................................................1 43 Abstract...........................................................1 44 1. Introduction and Motivation.....................................3 45 2. Conventions used in this document...............................4 46 3. Protocol Overview...............................................5 47 4. Messages.......................................................11 48 4.1. EAP-Response/Identity........................................11 50 EAP AKA Authentication May 2001 52 4.2. EAP-Request/USIM-Challenge...................................12 53 4.3. EAP-Response/USIM-Challenge..................................14 54 4.4. EAP-Response/USIM-Authentication-Reject......................15 55 4.5. EAP-Response/USIM-GSM-Authentication-Reject..................15 56 4.6. EAP-Response/USIM-Synchronization-Failure....................16 57 5. Interoperability with GSM......................................17 58 6. IANA Considerations............................................18 59 7. Security Considerations........................................18 60 8. Intellectual Property Right Notices............................18 61 Acknowledgements..................................................18 62 Authors' Addresses................................................18 64 EAP AKA Authentication May 2001 66 1. Introduction and Motivation 68 This document specifies an Extensible Authentication Protocol (EAP) 69 mechanism for authentication and session key distribution using the 70 UMTS AKA authentication mechanism [1]. The Universal Mobile 71 Telecommunications System (UMTS) is a global third generation mobile 72 network standard. 74 AKA is based on challenge-response mechanisms and symmetric 75 cryptography. AKA runs in a UMTS Subscriber Identity Module (USIM), 76 a smart card like device. AKA provides also backwards compatibility 77 to the GSM authentication mechanism [2]. Compared to the GSM 78 mechanism, AKA provides substantially longer key lengths and the 79 authentication of the server side as well as the client side. 81 The introduction of AKA inside EAP allows several new applications. 82 These include the following: 84 - The use of the AKA also as a secure PPP authentication method in 85 devices that already contain an USIM. 87 - The use of the third generation mobile network authentication 88 infrastructure in the context of wireless LANs and IEEE 801.1x 89 technology through EAP over Wireless [3, 4]. 91 - Relying on AKA and the existing infrastructure in a seamless way 92 with any other technology that can use EAP. 94 AKA works in the following manner: 96 - The USIM and the home environment have agreed on a secret key 97 beforehand. 99 - The actual authentication process starts by having the home 100 environment produce an authentication vector, based on the secret 101 key and a sequence number. The authentication vector contains a 102 random part RAND, an authenticator part AUTN used for 103 authenticating the network to the USIM, an expected result part 104 XRES, a session key for integrity check IK, and a session key for 105 encryption CK. 107 - The RAND and the AUTN are delivered to the USIM. 109 - The USIM verifies the AUTN, again based on the secret key and the 110 sequence number. If this process is successful (the AUTN is valid 111 and the sequence number used to generate AUTN is within the 112 correct range), the USIM produces an authentication result, RES 113 and sends this to the home environment. 115 - The home environment verifies the correct result from the USIM. If 116 the result is correct, IK and CK can be used to protect further 117 communications between the USIM and the home environment. 119 EAP AKA Authentication May 2001 121 When verifying AUTN, the USIM may detect that the sequence number 122 the network uses is not within the correct range. In this case, the 123 USIM calculates a sequence number synchronization parameter AUTS and 124 sends it to the network. AKA authentication may then be retried with 125 a new authentication vector generated using the synchronized 126 sequence number. 128 For a full specification of the AKA algorithms and how the 129 cryptographic values AUTN, RES, IK, CK and AUTS are calculated, see 130 reference [1]. 132 It is also possible that the home environment delegates the actual 133 authentication task to an intermediate node. In this case the 134 authentication vector or parts of it are delivered to the 135 intermediate node, enabling it to perform the comparison between RES 136 and XRES, and possibly also use CK and IK. 138 In the third generation mobile networks, AKA is used both for radio 139 network authentication and IP multimedia service authentication 140 purposes. Different user identities and formats are used for these; 141 the radio network uses the International Mobile Subscriber 142 Identifier (IMSI), whereas the IP multimedia service uses the 143 Network Access Identifier (NAI) [5]. 145 2. Conventions used in this document 147 The following terms will be used through this document: 149 AAA protocol 151 Authentication, Authorization and Accounting protocol 153 AAA server 155 In this document, AAA server refers to the network element 156 that resides on the border of Internet AAA network and GSM 157 network. 159 AKA 161 Authentication and Key Agreement 163 AuC 165 Authentication Centre. The mobile network element that can 166 authorize subscribers either in GSM or in UMTS networks. 168 EAP 170 Extensible Authentication Protocol [6]. 172 GSM 174 EAP AKA Authentication May 2001 176 Global System for Mobile communications. 178 NAI 180 Network Access Identifier [5]. 182 AUTN 184 Authentication value generated by the AuC which together with 185 the RAND authenticates the server to the client, 128 bits [1]. 187 AUTS 189 A value generated by the client upon experiencing a 190 synchronization failure, 112 bits. 192 RAND 194 Random number generated by the AuC, 128 bits [1]. 196 RES 198 Authentication result from the client, which together with the 199 RAND authenticates the client to the server, 128 bits [1]. 201 SQN 203 Sequence number used in the authentication process, 48 bits 204 [1]. 206 SIM 208 Subscriber Identity Module. SIM cards are smart cards 209 distributed by GSM operators. 211 SRES 213 The authentication result parameter in GSM, corresponds to the 214 RES parameter in UMTS aka, 32 bits. 216 USIM 218 UMTS Subscriber Identity Module. These cards are smart cards 219 Similar to SIMs and are distributed by UMTS operators. 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 223 this document are to be interpreted as described in RFC 2119 [8] 225 3. Protocol Overview 227 EAP AKA Authentication May 2001 229 The EAP AKA uses two roundtrips to authorize the user and generate 230 session keys. The authenticator typically communicates with the 231 user's AAA server using an AAA protocol. (The exact AAA 232 communications outside the scope of this document, however.) 234 The below message flow shows the basic successful authentication 235 case with the EAP AKA. As in other EAP schemes, first an identity 236 request/response message pair is exchanged. (For this particular EAP 237 protocol, the identity request is defined to be optional, to shorten 238 the authentication process to a minimal one.) 240 Next, the authenticator starts the actual AKA protocol by sending an 241 EAP-Request/USIM-Challenge message. This message contains a random 242 number and an authorization vector. The client runs the AKA 243 algorithm (perhaps inside an USIM) and verifies the AUTN. If this is 244 successful, the client is talking to a legitimate authenticator and 245 proceeds to send the EAP-Response/USIM-Challenge. This message 246 contains a result parameter that allows the authenticator in turn to 247 verify that the client is a legitimate one. 249 EAP AKA Authentication May 2001 251 Client Authenticator 252 | | 253 | EAP-Request/Identity (optional) | 254 |<------------------------------------------------------| 255 | | 256 | EAP-Response/Identity | 257 | (Includes user's NAI) | 258 |------------------------------------------------------>| 259 | | 260 | +------------------------------+ 261 | | Server runs UMTS algorithms, | 262 | | generates RAND and AUTN. | 263 | +------------------------------+ 264 | | 265 | EAP-Request/USIM-Challenge | 266 | (Lifetime, RAND, AUTN) | 267 |<------------------------------------------------------| 268 | | 269 +-------------------------------------+ | 270 | Client runs UMTS algorithms on USIM,| | 271 | verifies AUTN, derives RES | | 272 | and session key | | 273 +-------------------------------------+ | 274 | | 275 | EAP-Response/USIM-Challenge | 276 | (RES) | 277 |------------------------------------------------------>| 278 | | 279 | +------------------------------+ 280 | | Server checks the given RES, | 281 | | and finds it correct. | 282 | +------------------------------+ 283 | | 284 | EAP-Success | 285 |<------------------------------------------------------| 287 When EAP AKA is run in the GSM compatible mode, the message flow is 288 otherwise identical to the message flow below except that the AUTN 289 parameter is not included in EAP-Request/USIM-Challenge packet. 291 An optional lifetime may be associated to the challenge message. 292 This specifies the server side's limit on how long the ciphering and 293 integrity keys generated as a part of the authentication process can 294 be used. (The use of such keys is outside the scope of this 295 document.) 297 The second message flow shows how the Authenticator rejects the 298 Client due to failed authentication. The same flow is also used in 299 the GSM compatible mode, except that the AUTN parameter is not 300 included in the EAP-Request/USIM-Challenge packet. 302 EAP AKA Authentication May 2001 304 Client Authenticator 305 | | 306 | EAP-Request/Identity | 307 |<------------------------------------------------------| 308 | | 309 | EAP-Response/Identity | 310 | (Includes user's NAI) | 311 |------------------------------------------------------>| 312 | | 313 | +------------------------------+ 314 | | Server runs UMTS algorithms, | 315 | | generates RAND and AUTN. | 316 | +------------------------------+ 317 | | 318 | EAP-Request/USIM-Challenge | 319 | (Lifetime, RAND, AUTN) | 320 |<------------------------------------------------------| 321 | | 322 +-------------------------------------+ | 323 | Client runs UMTS algorithms on USIM,| | 324 | possibly verifies AUTN, and sends an| | 325 | invalid response | | 326 +-------------------------------------+ | 327 | | 328 | EAP-Response/USIM-Challenge | 329 | (RES) | 330 |------------------------------------------------------>| 331 | | 332 | +------------------------------+ 333 | | Server checks the given RES, | 334 | | and finds it incorrect. | 335 | +------------------------------+ 336 | | 337 | EAP-Failure | 338 |<------------------------------------------------------| 340 The next message flow shows the client rejecting the AUTN of the 341 Authenticator. This flow is not used in the GSM compatible mode. 343 EAP AKA Authentication May 2001 345 Client Authenticator 346 | | 347 | EAP-Request/Identity | 348 |<------------------------------------------------------| 349 | | 350 | EAP-Response/Identity | 351 | (Includes user's NAI) | 352 |------------------------------------------------------>| 353 | | 354 | +------------------------------+ 355 | | Server runs UMTS algorithms, | 356 | | generates RAND and a bad AUTN| 357 | +------------------------------+ 358 | | 359 | EAP-Request/USIM-Challenge | 360 | (Lifetime, RAND, AUTN) | 361 |<------------------------------------------------------| 362 | | 363 +-------------------------------------+ | 364 | Client runs UMTS algorithms on USIM | | 365 | and discovers AUTN that can not be | | 366 | verified | | 367 +-------------------------------------+ | 368 | | 369 | EAP-Response/USIM-Authentication-Reject | 370 |------------------------------------------------------>| 371 | | 372 | | 373 | EAP-Failure | 374 |<------------------------------------------------------| 376 Networks that are not UMTS aware use the GSM compatible version of 377 this protocol even for UMTS subscribers. In this case, the AUTN 378 parameter is not included in the EAP-Request/USIM-Challenge packet. 379 If a UMTS capable client does not want to accept the use of the GSM 380 compatible mode, the client can reject the authentication with the 381 EAP-Response/USIM-GSM-Authentication-Reject message, as shown in the 382 following figure: 384 EAP AKA Authentication May 2001 386 Client Authenticator 387 | | 388 | EAP-Request/Identity | 389 |<------------------------------------------------------| 390 | | 391 | EAP-Response/Identity | 392 | (Includes user's NAI) | 393 |------------------------------------------------------>| 394 | | 395 | +------------------------------+ 396 | | Server runs GSM algorithms, | 397 | | generates RAND | 398 | +------------------------------+ 399 | | 400 | EAP-Request/USIM-Challenge | 401 | (Lifetime, RAND) | 402 |<------------------------------------------------------| 403 | | 404 +-------------------------------------+ | 405 | Client does not accept the GSM | | 406 | compatible version of this protocol.| | 407 +-------------------------------------+ | 408 | | 409 | EAP-Response/USIM-GSM-Authentication-Reject | 410 |------------------------------------------------------>| 411 | | 412 | | 413 | EAP-Failure | 414 |<------------------------------------------------------| 416 The AKA uses shared secrets between the Client and the Authenticator 417 together with a sequence number to actually perform an 418 authentication. In certain circumstances it is possible for the 419 sequence numbers to get out of sequence. Here's what happens then: 421 EAP AKA Authentication May 2001 423 Client Authenticator 424 | | 425 | EAP-Request/Identity | 426 |<------------------------------------------------------| 427 | | 428 | EAP-Response/Identity | 429 | (Includes user's NAI) | 430 |------------------------------------------------------>| 431 | | 432 | +------------------------------+ 433 | | Server runs UMTS algorithms, | 434 | | generates RAND and AUTN. | 435 | +------------------------------+ 436 | | 437 | EAP-Request/USIM-Challenge | 438 | (Lifetime, RAND, AUTN) | 439 |<------------------------------------------------------| 440 | | 441 +-------------------------------------+ | 442 | Client runs UMTS algorithms on USIM | | 443 | and discovers AUTN that contains an | | 444 | inappropriate sequence number | | 445 +-------------------------------------+ | 446 | | 447 | EAP-Response/USIM-Synchronization-Failure | 448 | (AUTS) | 449 |------------------------------------------------------>| 450 | | 451 | +---------------------------+ 452 | | Perform resynchronization | 453 | | towards the AAA using | 454 | | AUTS and the sent RAND | 455 | +---------------------------+ 456 | | 458 After the resynchronization process takes place in the server and 459 AAA side, the process continues by the server side sending a new 460 EAP-Request/USIM-Challenge message. 462 4. Messages 464 4.1. EAP-Response/Identity 466 In the beginning of EAP authentication, the Authenticator issues the 467 EAP-Request/Identity packet to the client. The client responds with 468 EAP-Response/Identity, which contains the user's identity. The 469 formats of these packets are specified in [6]. 471 The EAP AKA mechanism uses the NAI format [5] as the identity. 472 In order to facilitate the use of the existing cellular roaming 473 infrastructure, the EAP AKA client transmits the user's IMSI within 474 the NAI in the EAP Response/Identity packet. The NAI is of the 475 format "0imsi@realm". In other words, the first character is the 476 digit zero (ASCII 0x30), followed by the IMSI, followed by the @ 478 EAP AKA Authentication May 2001 480 character and the realm. The IMSI is an ASCII string that consists 481 of not more than 15 decimal digits (ASCII values between 0x30 and 482 0x39) as specified in [9]. 484 The AAA network routes AAA requests to the correct AAA server using 485 the realm part of the NAI. Because cellular roaming can be used with 486 EAP AKA, the AAA request can be routed to an AAA server in the 487 visited network instead of the server indicated in the NAI realm. 488 The operators need to agree on this special AAA routing in advance. 489 It is recommended that operators should reserve the realm portion of 490 NAI used with EAP AKA to UMTS and GSM subscribers only, so that 491 exactly the same realm is not used with other authentication 492 methods. This convention makes it easy to recognize that the NAI 493 identifies a UMTS or GSM subscriber of this operator, which may be 494 useful when configuring the routing rules in the visited AAA 495 networks. 497 In the EAP AKA protocol, the EAP-Request/Identity message is 498 optional when applicable. If the client can positively determine 499 that it has to authenticate, it MAY send an unsolicited EAP- 500 Response/Identity to the authenticator with an Identifier value it 501 has picked up itself. The client MUST NOT send an unsolicited EAP- 502 Response/Identity if it has already received an EAP-Request/Identity 503 packet. The client MUST send an EAP-Response/Identity to all 504 received EAP-Request/Identity packets, using the Identifier value in 505 the EAP-Request/Identity. If the authenticator receives an 506 unsolicited EAP-Response/Identity, it SHOULD process the packet as 507 if it had requested it. If the authenticator receives an EAP- 508 Response/Identity with an incorrect Identifier value in response to 509 the first EAP-Request/Identity it has sent to the client, then the 510 authenticator SHOULD still accept the EAP-Response/Identity packet. 512 4.2. EAP-Request/USIM-Challenge 514 The format of the EAP-Request/USIM-Challenge packet is shown below. 516 EAP AKA Authentication May 2001 518 0 1 2 3 519 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Code | Identifier | Length | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Type | Subtype | Reserved | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Key Lifetime | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | 528 | RAND | 529 | | 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | | 533 | AUTN (optional) | 534 | | 535 | | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 The semantics of the fields is described below: 540 Code 542 1 for Request 544 Identifier 546 See [6] 548 Length 550 The length of the EAP Request packet. 551 44, if AUTN is included (UMTS AKA). 552 28, if AUTN is excluded (GSM compatible mode). 554 Type 556 TBD 558 Subtype 560 1 for USIM-Challenge 562 Reserved 564 Set to zero when sending, ignored on reception. 566 Key lifetime 568 This expresses how long the cipher and integrity keys may be 569 used. This value is expressed in seconds, and the value of 570 zero means they may be used indefinitely. 572 EAP AKA Authentication May 2001 574 RAND 576 The AKA RAND parameter, 16 bytes (128 bits). 578 AUTN 580 The AKA AUTN parameter, 16 bytes (128 bits). 582 4.3. EAP-Response/USIM-Challenge 584 The format of the EAP-Response/USIM-Challenge packet is shown below. 586 0 1 2 3 587 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Code | Identifier | Length | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type | Subtype | ResLength | Reserved | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | | 594 | RES | 595 | | 596 | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 The semantics of the fields is described below: 601 Code 603 2 for Response 605 Identifier 607 See [6] 609 Length 611 The length of the EAP Response packet, 12..40. 613 Type 615 TBD 617 Subtype 619 1 for USIM-Challenge 621 ResLength 623 This is the length of the RES parameter in bits. According to 624 the specification [10] this parameter can vary between 32 and 625 128 bits. In the GSM compatible mode, the RES field contains 626 the GSM SRES parameter which is always 32 bits long. 628 EAP AKA Authentication May 2001 630 Reserved 632 Set to zero when sending, ignored on reception. 634 RES 636 The AKA RES parameter, 32..128 bits. The Length parameter 637 specifies the total length of the payload and identifies the 638 at the same time indirectly also the size of the RES in bytes. 639 The ResLength field identifies the exact length in bits. The 640 sender may pad the RES with zero bits and bytes where 641 necessary. In the GSM compatible mode, the RES field contains 642 the GSM SRES parameter. 644 4.4. EAP-Response/USIM-Authentication-Reject 646 The format of the EAP-Response/USIM-Authentication-Reject packet is 647 shown below. 649 0 1 2 3 650 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Code | Identifier | Length | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Type | Subtype | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 The semantics of the fields is described below: 659 Code 661 2 for Response 663 Identifier 665 See [6] 667 Length 669 The length of the EAP Response packet, 12. 671 Type 673 TBD 675 Subtype 677 2 for USIM-Authentication-Reject 679 4.5. EAP-Response/USIM-GSM-Authentication-Reject 681 EAP AKA Authentication May 2001 683 The format of the EAP-Response/USIM-GSM-Authentication-Reject packet 684 is shown below. 686 0 1 2 3 687 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Code | Identifier | Length | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Type | Subtype | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 The semantics of the fields is described below: 696 Code 698 2 for Response 700 Identifier 702 See [6] 704 Length 706 The length of the EAP Response packet, 6. 708 Type 710 TBD 712 Subtype 714 3 for USIM-GSM-Authentication-Reject 716 4.6. EAP-Response/USIM-Synchronization-Failure 718 The format of the EAP-Response/USIM-Synchronization-Failure packet 719 is shown below. 721 0 1 2 3 722 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Code | Identifier | Length | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Type | Subtype | AUTS | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 728 | | 729 | | 730 | | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 The semantics of the fields is described below: 735 EAP AKA Authentication May 2001 737 Code 739 2 for Response 741 Identifier 743 See [6] 745 Length 747 The length of the EAP Response packet, 20. 749 Type 751 TBD 753 Subtype 755 4 for USIM-Synchronization-Failure 757 AUTS 759 The AKA AUTS parameter, 112 bits (14 bytes). 761 5. Interoperability with GSM 763 The EAP AKA protocol is able to authenticate both UMTS and GSM 764 users, if the subscriber's operator's network is UMTS aware. This is 765 because the home network will be able to determine from the 766 subscriber records whether the subscriber is equipped with a UMTS 767 USIM or a GSM SIM. A UMTS aware home network will hence always use 768 UMTS AKA with UMTS subscribers and GSM authentication with GSM 769 subscribers. With GSM subscribers, the EAP AKA protocol is always 770 used in the GSM compatible mode. 772 It is not possible to use a GSM AuC to authenticate UMTS 773 subscribers. (Note that if the home network doesn't support an 774 authentication method it should not distribute SIMs for that 775 method.) 777 However, it is possible that the node actually terminating EAP and 778 the node that stores the authentication keys (AuC) are separate, and 779 support different authentication types. If the node terminating EAP 780 is GSM-only but AuC is UMTS-aware, then authentication can still be 781 achieved using the GSM compatible version of EAP AKA. This 782 authentication will be weaker, since the GSM compatible mode does 783 not provide for mutual authentication. Section 6.8.1.1 in [1] 784 specifies how the GSM SRES parameter and the Kc key can be 785 calculated on the USIM and the AuC. If a UMTS terminal does not want 786 to accept the GSM compatible version of this protocol, then it can 787 reject the authentication with the EAP-Response/USIM-GSM- 788 Authentication-Reject packet. 790 EAP AKA Authentication May 2001 792 In conclusion, the following table shows which variant of the EAP 793 AKA protocol should be run under different conditions: 795 SIM EAP node AuC EAP AKA mode 796 ---------------------------------------------------- 797 GSM (any) (any) GSM 798 UMTS (any) GSM (illegal) 799 UMTS GSM GSM+UMTS GSM 800 UMTS GSM+UMTS GSM+UMTS UMTS 802 6. IANA Considerations 804 IANA has assigned the number TBD for EAP AKA authentication. 806 7. Security Considerations 808 Implementations running the EAP AKA protocol will rely on the 809 security of the AKA scheme, and the secrecy of the symmetric keys 810 stored in the USIM and the AuC. 812 8. Intellectual Property Right Notices 814 On IPR related issues, Nokia and Ericsson refer to the their 815 respective statements on patent licensing. Please see 816 http://www.ietf.org/ietf/IPR/NOKIA and 817 http://www.ietf.org/ietf/IPR/ERICSSON-General 819 Acknowledgements 821 The authors wish to thank Rolf Blom of Ericsson, Bernard Aboba of 822 Microsoft and Arne Norefors of Ericsson for interesting discussions 823 in this problem space. 825 Authors' Addresses 827 Jari Arkko 828 Ericsson 829 02420 Jorvas Phone: +358 40 5079256 830 Finland Email: jari.arkko@ericsson.com 832 Henry Haverinen 833 Nokia Mobile Phones 834 P.O. Box 88 835 33721 Tampere Phone: +358 50 594 4899 836 Finland E-mail: henry.haverinen@nokia.com 838 References 840 [1] 3GPP Technical Specification 3GPP TS 33.102 V3.6.0: "Technical 841 Specification Group Services and System Aspects; 3G Security; 842 Security Architecture (Release 1999)", 3rd Generation 843 Partnership Project, November 2000. 845 EAP AKA Authentication May 2001 847 [2] GSM Technical Specification GSM 03.20 (ETS 300 534): "Digital 848 cellular telecommunication system (Phase 2); Security related 849 network functions", European Telecommunications Standards, 850 Institute, August 1997. 852 [3] IEEE Draft P802.1X/D11, "Standards for Local Area and 853 Metropolitan Area Networks: Standard for Port Based Network 854 Access Control", March 2001 856 [4] IEEE Draft 802.11eS/D1, "Draft Supplement to STANDARD FOR 857 Telecommunications and Information Exchange between Systems - 858 LAN/MAN Specific Requirements - Part 11: Wireless Medium 859 Access Control (MAC) and physical layer (PHY) specifications: 860 Specification for Enhanced Security", March 2001 862 [5] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 863 2486, January 1999. 865 [6] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication 866 Protocol (EAP)", RFC 2284, March 1998. 868 [8] S. Bradner, "Key words for use in RFCs to indicate Requirement 869 Levels", RFC 2119, March 1997. 871 [9] GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital 872 cellular telecommunication system (Phase 2); Numbering, 873 addressing and identification", European Telecommunications 874 Standards Institute, April 1997. 876 [10] 3GPP Technical Specification 3GPP TS 33.105 V3.5.0: "Technical 877 Specification Group Services and System Aspects; 3G Security; 878 Cryptographic Algorithm Requirements (Release 1999)", 879 3rdGeneration Partnership Project, October 2000