idnits 2.17.1 draft-arkko-pppext-eap-aka-10.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 57 longer pages, the longest (page 3) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 59 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 541 has weird spacing: '...ely, an imple...' == 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 (June 2003) is 7614 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: '15' is defined on line 3067, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2486 (ref. '4') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2284 (ref. '5') (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Obsolete normative reference: RFC 2716 (ref. '15') (Obsoleted by RFC 5216) ** Downref: Normative reference to an Informational RFC: RFC 2548 (ref. '16') ** Obsolete normative reference: RFC 2434 (ref. '17') (Obsoleted by RFC 5226) == Outdated reference: A later version (-10) exists of draft-ietf-pppext-rfc2284bis-07 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-05 -- Possible downref: Normative reference to a draft: ref. '19' ** Obsolete normative reference: RFC 1750 (ref. '20') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 3344 (ref. '21') (Obsoleted by RFC 5944) Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 13 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-10.txt H. Haverinen 5 Expires: December 2003 Nokia 6 June 2003 8 EAP AKA Authentication 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 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 Universal Mobile Telecommunications System (UMTS) Authentication and 35 Key Agreement (AKA) mechanism. UMTS AKA is based on symmetric keys, 36 and runs typically in a UMTS Subscriber Identity Module, a smart 37 card like device. 39 EAP AKA includes optional identity privacy support and an optional 40 re-authentication procedure. 42 Table of Contents 44 Status of this Memo................................................1 45 Abstract...........................................................1 46 1. Introduction and Motivation.....................................2 47 2. Terms and Conventions Used in This Document.....................4 48 3. Protocol Overview...............................................6 49 4. Identity Management............................................10 50 4.1. User Identity in EAP-Response/Identity.......................10 52 EAP AKA Authentication June 2003 54 4.2. Obtaining Subscriber Identity via EAP AKA Messages...........12 55 4.3. Identity Privacy Support.....................................15 56 5. Re-authentication..............................................21 57 6. Message Format.................................................26 58 7. Message Authentication and Encryption..........................27 59 7.1. AT_MAC Attribute.............................................27 60 7.2. AT_CHECKCODE Attribute.......................................28 61 7.3. AT_IV, AT_ENCR_DATA and AT_PADDING Attributes................30 62 8. Messages.......................................................31 63 8.1. EAP-Request/AKA-Challenge....................................31 64 8.2. EAP-Response/AKA-Challenge...................................35 65 8.3. EAP-Response/AKA-Authentication-Reject.......................36 66 8.4. EAP-Response/AKA-Synchronization-Failure.....................37 67 8.5. EAP-Request/AKA-Identity.....................................38 68 8.6. EAP-Response/AKA-Identity....................................39 69 8.7. EAP-Request/AKA-Reauthentication.............................41 70 8.8. EAP-Response/AKA-Reauthentication............................43 71 8.9. EAP/AKA Notifications........................................46 72 9. Error Cases and the Usage of EAP-Failure and EAP-Success.......49 73 9.1. Processing Erroneous Packets.................................49 74 9.2. EAP-Failure..................................................49 75 9.3. EAP-Success..................................................50 76 10. Key Derivation................................................50 77 11. IANA and Protocol Numbering Considerations....................52 78 12. Security Considerations.......................................53 79 12.1. Identity Protection.........................................53 80 12.2. Mutual Authentication.......................................53 81 12.3. Key Derivation..............................................53 82 12.4. Brute-Force and Dictionary Attacks..........................53 83 12.5. Integrity Protection, Replay Protection and Confidentiality.54 84 12.6. Negotiation Attacks.........................................54 85 12.7. Fast Reconnect..............................................55 86 12.8. Acknowledged Result Indications.............................55 87 12.9. Man-in-the-middle Attacks...................................55 88 12.10. Generating Random Numbers..................................55 89 13. Security Claims...............................................55 90 14. Intellectual Property Right Notices...........................56 91 Acknowledgements and Contributions................................56 92 Authors' Addresses................................................56 93 Annex A. Pseudo-Random Number Generator...........................57 95 1. Introduction and Motivation 97 This document specifies an Extensible Authentication Protocol (EAP) 98 mechanism for authentication and session key distribution using the 99 UMTS AKA authentication mechanism [1]. UMTS is a global third 100 generation mobile network standard. 102 EAP AKA Authentication June 2003 104 AKA is based on challenge-response mechanisms and symmetric 105 cryptography. AKA typically runs in a UMTS Subscriber Identity 106 Module (USIM). Compared to the GSM mechanism, UMTS AKA provides 107 substantially longer key lengths and mutual authentication. 109 The introduction of AKA inside EAP allows several new applications. 110 These include the following: 112 - The use of the AKA also as a secure PPP authentication method in 113 devices that already contain an USIM. 115 - The use of the third generation mobile network authentication 116 infrastructure in the context of wireless LANs and IEEE 802.1x 117 technology through EAP over Wireless [2, 3]. 119 - Relying on AKA and the existing infrastructure in a seamless way 120 with any other technology that can use EAP. 122 AKA works in the following manner: 124 - The USIM and the home environment have agreed on a secret key 125 beforehand. 127 - The actual authentication process starts by having the home 128 environment produce an authentication vector, based on the secret 129 key and a sequence number. The authentication vector contains a 130 random part RAND, an authenticator part AUTN used for 131 authenticating the network to the USIM, an expected result part 132 XRES, a session key for integrity check IK, and a session key for 133 encryption CK. 135 - The RAND and the AUTN are delivered to the USIM. 137 - The USIM verifies the AUTN, again based on the secret key and the 138 sequence number. If this process is successful (the AUTN is valid 139 and the sequence number used to generate AUTN is within the 140 correct range), the USIM produces an authentication result, RES 141 and sends this to the home environment. 143 - The home environment verifies the correct result from the USIM. If 144 the result is correct, IK and CK can be used to protect further 145 communications between the USIM and the home environment. 147 When verifying AUTN, the USIM may detect that the sequence number 148 the network uses is not within the correct range. In this case, the 149 USIM calculates a sequence number synchronization parameter AUTS and 150 sends it to the network. AKA authentication may then be retried with 151 a new authentication vector generated using the synchronized 152 sequence number. 154 For a specification of the AKA mechanisms and how the cryptographic 155 values AUTN, RES, IK, CK and AUTS are calculated, see reference [1]. 157 EAP AKA Authentication June 2003 159 It is also possible that the home environment delegates the actual 160 authentication task to an intermediate node. In this case the 161 authentication vector or parts of it are delivered to the 162 intermediate node, enabling it to perform the comparison between RES 163 and XRES, and possibly also use CK and IK. Such delivery MUST be 164 done in a secure manner. In EAP AKA, the EAP server node is such an 165 intermediate node. 167 In the third generation mobile networks, AKA is used both for radio 168 network authentication and IP multimedia service authentication 169 purposes. Different user identities and formats are used for these; 170 the radio network uses the International Mobile Subscriber 171 Identifier (IMSI), whereas the IP multimedia service uses the 172 Network Access Identifier (NAI) [4]. 174 2. Terms and Conventions Used in This Document 176 The following terms will be used through this document: 178 AAA protocol 180 Authentication, Authorization and Accounting protocol 182 AAA server 184 The AAA server is responsible for storing shared secrets and 185 other credential information necessary for the authentication of 186 users. Cf. EAP server 188 AKA 190 Authentication and Key Agreement 192 AuC 194 Authentication Centre. The mobile network element that can 195 authenticate subscribers either in GSM or in UMTS networks. 197 Authenticator 199 The entity that terminates the protocol carrying EAP used by the 200 client, such as a Network Access Server (NAS) terminating the PPP 201 link. The EAP server may be co-located in the Authenticator. In 202 this case, the Authenticator may actually authenticate the user 203 based on information received from the AAA server. 205 EAP 207 Extensible Authentication Protocol [5]. 209 EAP AKA Authentication June 2003 211 EAP server 213 The network element that terminates the EAP protocol. Typically, 214 the EAP server functionality is implemented in a AAA server. 216 GSM 218 Global System for Mobile communications. 220 NAI 222 Network Access Identifier [4]. 224 AUTN 226 Authentication value generated by the AuC which together with the 227 RAND authenticates the server to the client, 128 bits [1]. 229 AUTS 231 A value generated by the client upon experiencing a 232 synchronization failure, 112 bits. 234 RAND 236 Random number generated by the AuC, 128 bits [1]. 238 RES 240 Authentication result from the client, which together with the 241 RAND authenticates the client to the server, 128 bits [1]. 243 SQN 245 Sequence number used in the authentication process, 48 bits [1]. 247 SIM 249 Subscriber Identity Module. The SIM is an application 250 traditionally resident on smart cards distributed by GSM 251 operators. 253 SRES 255 The authentication result parameter in GSM, corresponds to the 256 RES parameter in UMTS aka, 32 bits. 258 USIM 260 UMTS Subscriber Identity Module. USIM is an application that is 261 resident e.g. on smart cards distributed by UMTS operators. 263 EAP AKA Authentication June 2003 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 267 this document are to be interpreted as described in RFC 2119 [6] 269 3. Protocol Overview 271 In this document, the term EAP Server refers to the network element 272 that terminates the EAP protocol. Usually the EAP server is separate 273 from the authenticator device, which is the network element closest 274 to the client, such as a Network Access Server (NAS) or an IEEE 275 802.1X bridge. Alternatively, the EAP server functionality may be 276 co-located in the authenticator although typically, the EAP server 277 functionality is implemented on a separate AAA server with whom the 278 authenticator communicates using an AAA protocol. (The exact AAA 279 communications are outside the scope of this document, however.) 281 The message flow below shows the basic successful full 282 authentication case with the EAP AKA. The EAP AKA uses two 283 roundtrips to authorize the user and generate session keys. As in 284 other EAP schemes, first an identity request/response message pair 285 is exchanged. (As specified in [5], the initial identity request is 286 not required, and MAY be bypassed in cases where the authenticator 287 can presume the identity, such as when using leased lines, dedicated 288 dial-ups, etc. Please see also Section 4.2 for specification how to 289 obtain the identity via EAP AKA messages.) 291 Next, the EAP server starts the actual AKA protocol by sending an 292 EAP-Request/AKA-Challenge message. EAP AKA packets encapsulate 293 parameters in attributes, encoded in a Type, Length, Value format. 294 The packet format and the use of attributes are specified in Section 295 6. The EAP-Request/AKA-Challenge message contains a random number 296 (AT_RAND) and an authorization vector (AT_AUTN), and a message 297 authentication code AT_MAC. The EAP-Request/AKA-Challenge message 298 MAY optionally contain encrypted data, which is used for Identity 299 privacy support, as described in Section 4.3. The AT_MAC attribute 300 contains a message authentication code covering the EAP packet. The 301 encrypted data is not shown in the figures of this section. 303 The client runs the AKA algorithm (perhaps inside an USIM) and 304 verifies the AUTN. If this is successful, the client is talking to a 305 legitimate EAP server and proceeds to send the EAP-Response/AKA- 306 Challenge. This message contains a result parameter that allows the 307 EAP server in turn to authenticate the client, and the AT_MAC 308 attribute to integrity protect the EAP message. 310 EAP AKA Authentication June 2003 312 Client Authenticator 313 | | 314 | EAP-Request/Identity | 315 |<------------------------------------------------------| 316 | | 317 | EAP-Response/Identity | 318 | (Includes user's NAI) | 319 |------------------------------------------------------>| 320 | | 321 | +------------------------------+ 322 | | Server runs UMTS algorithms, | 323 | | generates RAND and AUTN. | 324 | +------------------------------+ 325 | | 326 | EAP-Request/AKA-Challenge | 327 | (AT_RAND, AT_AUTN, AT_MAC) | 328 |<------------------------------------------------------| 329 | | 330 +-------------------------------------+ | 331 | Client runs UMTS algorithms on USIM,| | 332 | verifies AUTN and MAC, derives RES | | 333 | and session key | | 334 +-------------------------------------+ | 335 | | 336 | EAP-Response/AKA-Challenge | 337 | (AT_RES, AT_MAC) | 338 |------------------------------------------------------>| 339 | | 340 | +--------------------------------+ 341 | | Server checks the given RES, | 342 | | and MAC and finds them correct.| 343 | +--------------------------------+ 344 | | 345 | EAP-Success | 346 |<------------------------------------------------------| 348 The second message flow shows how the EAP server rejects the Client 349 due to a failed authentication. The same flow is also used in the 350 GSM compatible mode, except that the AT_AUTN attribute and AT_MAC 351 attribute are not used in the messages. 353 EAP AKA Authentication June 2003 355 Client Authenticator 356 | | 357 | EAP-Request/Identity | 358 |<------------------------------------------------------| 359 | | 360 | EAP-Response/Identity | 361 | (Includes user's NAI) | 362 |------------------------------------------------------>| 363 | | 364 | +------------------------------+ 365 | | Server runs UMTS algorithms, | 366 | | generates RAND and AUTN. | 367 | +------------------------------+ 368 | | 369 | EAP-Request/AKA-Challenge | 370 | (AT_RAND, AT_AUTN, AT_MAC) | 371 |<------------------------------------------------------| 372 | | 373 +-------------------------------------+ | 374 | Client runs UMTS algorithms on USIM,| | 375 | possibly verifies AUTN, and sends an| | 376 | invalid response | | 377 +-------------------------------------+ | 378 | | 379 | EAP-Response/AKA-Challenge | 380 | (AT_RES, AT_MAC) | 381 |------------------------------------------------------>| 382 | | 383 | +------------------------------------------+ 384 | | Server checks the given RES and the MAC, | 385 | | and finds one of them incorrct. | 386 | +------------------------------------------+ 387 | | 388 | EAP-Failure | 389 |<------------------------------------------------------| 391 The next message flow shows the client rejecting the AUTN of the EAP 392 server. 394 The client sends an explicit error message (EAP-Response/AKA- 395 Authentication-Reject) to the Authenticator, as usual in AKA when 396 AUTN is incorrect. This allows the EAP server to produce the same 397 error statistics as AKA in general produces in UMTS. Please note 398 that this behavior is different from other EAP/AKA error cases, such 399 as when encountering an incorrect AT_MAC attribute, the client 400 silently discards the EAP/AKA message. 402 EAP AKA Authentication June 2003 404 Client Authenticator 405 | | 406 | EAP-Request/Identity | 407 |<------------------------------------------------------| 408 | | 409 | EAP-Response/Identity | 410 | (Includes user's NAI) | 411 |------------------------------------------------------>| 412 | | 413 | +------------------------------+ 414 | | Server runs UMTS algorithms, | 415 | | generates RAND and a bad AUTN| 416 | +------------------------------+ 417 | | 418 | EAP-Request/AKA-Challenge | 419 | (AT_RAND, AT_AUTN, AT_MAC) | 420 |<------------------------------------------------------| 421 | | 422 +-------------------------------------+ | 423 | Client runs UMTS algorithms on USIM | | 424 | and discovers AUTN that can not be | | 425 | verified | | 426 +-------------------------------------+ | 427 | | 428 | EAP-Response/AKA-Authentication-Reject | 429 |------------------------------------------------------>| 430 | | 431 | | 432 | EAP-Failure | 433 |<------------------------------------------------------| 435 The AKA uses shared secrets between the Client and the Client's home 436 operator together with a sequence number to actually perform an 437 authentication. In certain circumstances it is possible for the 438 sequence numbers to get out of sequence. Here's what happens then: 440 EAP AKA Authentication June 2003 442 Client Authenticator 443 | | 444 | EAP-Request/Identity | 445 |<------------------------------------------------------| 446 | | 447 | EAP-Response/Identity | 448 | (Includes user's NAI) | 449 |------------------------------------------------------>| 450 | | 451 | +------------------------------+ 452 | | Server runs UMTS algorithms, | 453 | | generates RAND and AUTN. | 454 | +------------------------------+ 455 | | 456 | EAP-Request/AKA-Challenge | 457 | (AT_RAND, AT_AUTN, AT_MAC) | 458 |<------------------------------------------------------| 459 | | 460 +-------------------------------------+ | 461 | Client runs UMTS algorithms on USIM | | 462 | and discovers AUTN that contains an | | 463 | inappropriate sequence number | | 464 +-------------------------------------+ | 465 | | 466 | EAP-Response/AKA-Synchronization-Failure | 467 | (AT_AUTS) | 468 |------------------------------------------------------>| 469 | | 470 | +---------------------------+ 471 | | Perform resynchronization | 472 | | Using AUTS and | 473 | | the sent RAND | 474 | +---------------------------+ 475 | | 477 After the resynchronization process has taken place in the server 478 and AAA side, the process continues by the server side sending a new 479 EAP-Request/AKA-Challenge message. 481 In addition to the full authentication scenarios described above, 482 EAP AKA includes a re-authentication procedure, which is specified 483 in Section 5. 485 4. Identity Management 487 This section specifies user identity management and identity privacy 488 support. 490 4.1. User Identity in EAP-Response/Identity 492 In the beginning of an EAP authentication, the Authenticator issues 493 the EAP-Request/Identity packet to the client. The client responds 494 with EAP-Response/Identity, which contains the user's identity. The 495 formats of these packets are specified in [5]. 497 EAP AKA Authentication June 2003 499 UMTS subscribers are identified with the International Mobile 500 Subscriber Identity (IMSI) [7]. The IMSI is composed of a three 501 digit Mobile Country Code (MCC), a two or three digit Mobile Network 502 Code (MNC) and a not more than 10 digit Mobile Subscriber 503 Identification Number (MSIN). In other words, the IMSI is a string 504 of not more than 15 digits. MCC and MNC uniquely identify the 505 operator. 507 Internet AAA protocols identify users with the Network Access 508 Identifier (NAI) [4]. When used in a roaming environment, the NAI is 509 composed of a username and a realm, separated with "@" 510 (username@realm). The username portion identifies the subscriber 511 within the realm. The AAA nodes use the realm portion of the NAI to 512 route AAA requests to the correct AAA server. The realm name used in 513 this protocol MAY be chosen by the operator and it MAY be a 514 configurable parameter in the EAP/AKA client implementation. In this 515 case, the client is typically configured with the NAI realm of the 516 home operator. Operators MAY reserve a specific realm name for 517 EAP/AKA users. This convention makes it easy to recognize that the 518 NAI identifies a subscriber that uses EAP/AKA. Such a reserved NAI 519 realm may be a useful hint to the first authentication method to use 520 during method negotiation. 522 There are three types of NAI username portions in EAP/AKA: non- 523 pseudonym permanent usernames, pseudonym usernames and re- 524 authentication usernames. The first two are only used on full 525 authentication and the last one only on re-authentication. When the 526 optional identity privacy support is not used, the non-pseudonym 527 permanent username is used. 529 The non-pseudonym permanent username MAY be derived from the IMSI. 530 In this case, the permanent username MUST be of the format "0imsi". 531 In other words, the first character of the username is the digit 532 zero (ASCII value 0x30), followed by the IMSI. The IMSI is an ASCII 533 string that consists of not more than 15 decimal digits (ASCII 534 values between 0x30 and 0x39) as specified in [7] 536 The EAP server MAY use the leading "0" as a hint to try EAP/AKA as 537 the first authentication method during method negotiation. The 538 EAP/AKA server MAY propose EAP/AKA even if the leading character was 539 not "0". 541 Alternatively, an implementation may choose a permanent username 542 that is not based on the IMSI. In this case the selection of the 543 username, its format, and its processing is a local matter. In this 544 case, the client implementation MUST NOT prepend any leading 545 characters to the username. 547 When the optional identity privacy support is used on full 548 authentication, the client MAY use the pseudonym received upon the 549 previous full authentication sequence as the username portion of the 550 NAI, as specified in Section 4.3. The client MUST NOT modify the 552 EAP AKA Authentication June 2003 554 pseudonym received in AT_NEXT_PSEUDONYM. For example, the client 555 MUST NOT prepend any leading characters in the pseudonym. 557 On re-authentication, the client uses the re-authentication identity 558 received upon the previous authentication sequence as the NAI. A new 559 re-authentication identity may be delivered as part of both full 560 authentication and re-authentication. The client MUST NOT modify the 561 re-authentication identity received in AT_NEXT_REAUTH_ID but the 562 client must use the re-authentication identity as it is. For 563 example, the client MUST NOT prepend any leading characters in the 564 re-authentication identity. 566 If no configured realm name is available, the client MAY derive the 567 realm name from the MCC and MNC portions of the IMSI. A recommended 568 way to derive the realm from the IMSI will be specified in [8]. 569 Alternatively, the realm name may be obtained by concatenating 570 "mnc", the MNC digits of IMSI, ".mcc", the MCC digits of IMSI and 571 ".owlan.org". For example, if the IMSI is 123456789098765, and the 572 MNC is three digits long, then the derived realm name is 573 "mnc456.mcc123.owlan.org". 575 If the client is not able to determine whether the MNC is two or 576 three digits long, the client MAY use a 3-digit MNC. If the correct 577 length of the MNC is two, then the MNC used in the realm name will 578 include the first digit of MSIN. Hence, when configuring AAA 579 networks for operators that have 2-digit MNCs, the network SHOULD 580 also be prepared for realm names with incorrect 3-digit MNCs. 582 4.2. Obtaining Subscriber Identity via EAP AKA Messages 584 It may be useful to obtain the identity of the subscriber through 585 means other than EAP Request/Identity. This can eliminate the need 586 for an identity request when using EAP method negotiation. If this 587 was not possible then it might not be possible to negotiate EAP/AKA 588 as the second method since not all EAP implementations support 589 multiple EAP Identity requests. 591 EAP-Request/AKA-Identity and EAP-Response/AKA-Identity packets may 592 be used for obtaining the subscriber identity. The EAP-Request/AKA- 593 Challenge, EAP-Response/AKA-Challenge, or the packets used on re- 594 authentication may optionally include the AT_CHECKCODE attribute, 595 which enables the protocol peers to ensure the integrity of the AKA- 596 Identity packets. AT_CHECKCODE is specified in Section 7.2. 598 If the EAP server has not received any identity (permanent identity, 599 pseudonym or re-authentication identity) from the client when 600 sending the first EAP/AKA request, then the EAP server SHOULD issue 601 the EAP-Request/AKA-Identity packet and includes the AT_ANY_ID_REQ 602 attribute (specified in Section 8.5). This attribute does not 603 contain any data. 605 If the EAP server has received an EAP-Response/Identity packet but 606 the contents do not appear to be a valid permanent identity, 607 pseudonym or a re-authentication identity, the EAP server SHOULD 609 EAP AKA Authentication June 2003 611 issue an EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ 612 attribute. 614 In some environments the intermediate entities or software layers in 615 the client may modify the identity string in the EAP- 616 Response/Identity packet. For example, some EAP layer 617 implementations may cache the identity string from the first 618 authentication and do not obtain a new identity string from the EAP 619 method implementation on subsequent authentication exchanges. 620 Because the identity string is used in key derivation, such 621 modifications will result in failed authentication unless the EAP 622 server uses the AT_ANY_ID_REQ attribute to obtain an unmodified copy 623 of the identity string. Therefore, in cases when there is a 624 possibility that an intermediate element or software layer may 625 modify the EAP-Response/Identity packet, the EAP server SHOULD 626 always use the EAP-Request/AKA-Identity packet with the 627 AT_ANY_ID_REQ attribute, even if the identity received in EAP- 628 Response/Identity was valid. 630 The AT_ANY_ID_REQ attribute requests the client to include the 631 AT_IDENTITY attribute (specified in Section 8.6) in the EAP- 632 Response/AKA-Identity packet. The identity format in the AT_IDENTITY 633 attribute is the same as in the Type-Data field of the EAP- 634 Response/Identity packet. The AT_IDENTITY attribute contains a 635 permanent identity, a pseudonym identity or a re-authentication 636 identity. If the server does not support re-authentication, it uses 637 the AT_FULLAUTH_ID_REQ attribute instead of the AT_ANY_ID_REQ 638 attribute to directly request for a full authentication identity 639 (either the permanent identity or a pseudonym identity). If the 640 server uses the AT_FULLAUTH_ID_REQ attribute, the client MUST NOT 641 use a re-authentication identity in the AT_IDENTITY attribute. 643 The use of pseudonyms for anonymity is specified in Section 4.3. The 644 use of re-authentication identities is specified in Section 5. 646 The full authentication case is illustrated in the figure below. In 647 this case, AT_IDENTITY contains either the permanent identity or a 648 pseudonym identity. The same sequence is also used in case the 649 server uses the AT_FULLAUTH_ID_REQ in EAP-Request/AKA-Identity 651 EAP AKA Authentication June 2003 653 Client Authenticator 654 | | 655 | +------------------------------+ 656 | | Server does not have any | 657 | | Subscriber identity available| 658 | | When starting EAP/AKA | 659 | +------------------------------+ 660 | | 661 | EAP-Request/AKA-Identity | 662 | (AT_ANY_ID_REQ) | 663 |<------------------------------------------------------| 664 | | 665 | | 666 | EAP-Response/AKA-Identity | 667 | (AT_IDENTITY) | 668 |------------------------------------------------------>| 669 | | 671 If the client wants to perform full authentication, it includes the 672 permanent identity or a pseudonym identity in the AT_IDENTITY 673 attribute. The client may use these identities in response to either 674 AT_ANY_ID_REQ or AT_FULLAUTH_ID_REQ. If the server uses the 675 AT_ANY_ID_REQ and the client wants to perform re-authentication, 676 then the client includes a re-authentication identity in the 677 AT_IDENTITY attribute. 679 If the client uses its full authentication identity and the 680 AT_IDENTITY attribute contains a valid permanent identity or a valid 681 pseudonym identity that the EAP server is able to decode to the 682 permanent identity, then the full authentication sequence proceeds 683 as usual with the EAP Server issuing the EAP-Request/AKA-Challenge 684 message. 686 On re-authentication, if the AT_IDENTITY attribute contains a valid 687 re-authentication identity and the server agrees on using re- 688 authentication, then the server proceeds with the re-authentication 689 sequence and issues the EAP-Request/AKA-Reauthentication packet, as 690 specified in Section 5. If the server does not recognize the re- 691 authentication identity, then it issues a second EAP-Request/AKA- 692 Identity message and includes the AT_FULLAUTH_ID_REQ attribute. In 693 this case, a second EAP/AKA-Identity round trip is required. The 694 messages used on the first roundtrip are ignored. (However all AKA- 695 Identity round trips are included in the calculation of the 696 AT_CHECKCODE attribute, as specified in Section 7.2). This is 697 illustrated below. 699 EAP AKA Authentication June 2003 701 Client Authenticator 702 | | 703 | +------------------------------+ 704 | | Server does not have any | 705 | | Subscriber identity available| 706 | | When starting EAP/AKA | 707 | +------------------------------+ 708 | | 709 | EAP-Request/AKA-Identity | 710 | (AT_ANY_ID_REQ) | 711 |<------------------------------------------------------| 712 | | 713 | | 714 | EAP-Response/AKA-Identity | 715 | (AT_IDENTITY containing a re-authentication identity) | 716 |------------------------------------------------------>| 717 | | 718 | +------------------------------+ 719 | | Server does not recognize | 720 | | The re-authentication | 721 | | Identity | 722 | +------------------------------+ 723 | | 724 | EAP-Request/AKA-Identity | 725 | (AT_FULLAUTH_ID_REQ) | 726 |<------------------------------------------------------| 727 | | 728 | | 729 | EAP-Response/AKA-Identity | 730 | (AT_IDENTITY with a full-auth. Identity) | 731 |------------------------------------------------------>| 732 | | 734 If the server recognizes the re-authentication identity, but still 735 wants to fall back on full authentication, the server may issue the 736 EAP-Request/AKA-Challenge packet. In this case, the full 737 authentication procedure proceeds as usual. 739 An extra EAP/AKA-Identity round trip is also required in cases when 740 the AT_IDENTITY attribute contains a pseudonym identity that the EAP 741 server fails to decode. The operation in this case is specified in 742 Section 4.3. 744 4.3. Identity Privacy Support 746 EAP/AKA includes optional identity privacy (anonymity) support that 747 can be used to hide the cleartext permanent identity and to make the 748 subscriber's connections unlinkable to eavesdroppers. Identity 749 privacy is based on temporary identities, or pseudonyms, which are 750 equivalent to but separate from the Temporary Mobile Subscriber 751 Identities (TMSI) that are used on cellular networks. Please see 752 Section 12.1 for security considerations concerning identity 753 privacy. 755 EAP AKA Authentication June 2003 757 If identity privacy is not used or if the client does not have any 758 pseudonyms or re-authentication identities available, the client 759 transmits the permanent identity in the EAP-Response/Identity packet 760 or in the AT_IDENTITY attribute. 762 The EAP-Request/AKA-Challenge message MAY include an encrypted 763 pseudonym in the value field of the AT_ENCR_DATA attribute. The 764 AT_IV and AT_MAC attributes are also used to transport the pseudonym 765 to the client, as described in Section 8.1. Because the identity 766 privacy support is optional to implement, the client MAY ignore the 767 AT_IV and AT_ENCR_DATA attributes and always transmit the permanent 768 identity in the EAP-Response/Identity packet and in the AT_IDENTITY 769 attribute. 771 On receipt of the EAP-Request/AKA-Challenge, the client verifies the 772 AT_MAC attribute before looking at the AT_ENCR_DATA attribute. If 773 the AT_MAC is invalid, then the client MUST silently discard the EAP 774 packet. If the AT_MAC attribute is valid, then the client MAY 775 decrypt the encrypted data in AT_ENCR_DATA and use the obtained 776 pseudonym on the next full authentication. 778 If the client does not receive a new pseudonym in the EAP- 779 Request/AKA-Challenge message, the client MAY use an old pseudonym 780 instead of the permanent identity on next full authentication. 782 The EAP server produces pseudonyms in an implementation-dependent 783 manner. Only the EAP server needs to be able to map the pseudonym to 784 the permanent identity. Regardless of construction method, the 785 pseudonym MUST conform to the grammar specified for the username 786 portion of an NAI. 788 In any case, it is necessary that permanent usernames and pseudonyms 789 are separate and recognizable from each other. It is also desirable 790 that EAP SIM and EAP AKA usernames be recognizable from each other 791 as an aid for the server to which method to offer. 793 In general, it is the task of the EAP server and the policies of its 794 administrator to ensure sufficient separation in the usernames. 795 Pseudonyms, for instance, are both produced and used by the EAP 796 server. The EAP server MUST compose pseudonyms so that it can 797 recognize if a NAI username is an EAP AKA pseudonym. For instance, 798 when the usernames have been derived from the IMSI, the pseudonym 799 could begin with a leading "2" character. 801 The client MAY transmit the received pseudonym in the first EAP- 802 Response/Identity packet of the next full authentication with the 803 EAP server. The client concatenates the received pseudonym with the 804 "@" character and the NAI realm portion. The client selects the 805 realm name portion similarly as it select the realm name portion 806 when using the permanent identity. If the EAP server successfully 807 decodes the pseudonym received in the EAP-Response/Identity packet 808 to a known client permanent identity, the authentication proceeds 809 with the EAP-Request/AKA-Challenge message as usual. 811 EAP AKA Authentication June 2003 813 Because the client may fail to save a pseudonym sent to in an EAP- 814 Request/AKA-Challenge, for example due to malfunction, the EAP 815 server SHOULD maintain at least one old pseudonym in addition to the 816 most recent pseudonym. 818 If the EAP server requests the client to include its identity in the 819 EAP-Response/AKA-Identity packet, as specified in Section 4.2, the 820 client MAY transmit the received pseudonym in the AT_IDENTITY 821 attribute. If the EAP server successfully decodes the pseudonym to a 822 known identity, then the authentication proceeds with the EAP- 823 Request/AKA-Challenge packet as usual. 824 If the EAP server fails to decode the pseudonym to a known identity, 825 then the EAP server requests the permanent identity (non-pseudonym 826 identity) by including the AT_PERMANENT_ID_REQ attribute (Section 827 8.5) in the EAP-Request/AKA-Identity message. Because another EAP 828 server may have generated the pseudonym using a different coding 829 scheme, the EAP server SHOULD use AT_PERMANENT_ID_REQ also in cases 830 when it does not recognize the format of the client identity. 832 The EAP server issues the EAP-Request/AKA-Identity message also in 833 the case when it received the undecodable pseudonym in AT_IDENTITY 834 included in the EAP-Response/AKA-Identity packet. In this case, a 835 second EAP/AKA-Identity round trip is required. 837 A received AT_PERMANENT_ID_REQ does not necessarily originate from 838 the valid network, but an active attacker may transmit an EAP- 839 Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute to 840 the client, in an effort to find out the true identity of the user. 841 The client MAY silently discard any EAP-Request/AKA-Identity 842 messages that include AT_PERMANENT_ID_REQ for a while in order to 843 wait for an EAP-Request/AKA-Identity packet without 844 AT_PERMANENT_ID_REQ. If the valid network sent the message, the 845 message will be retransmitted, so the client can reconsider replying 846 to the message when it receives a retransmission. 848 Basically, there are two different policies that the client can 849 employ with regard to AT_PERMANENT_ID_REQ. A "conservative" client 850 assumes that the network is able to maintain pseudonyms robustly. 851 Therefore, if a conservative client has a pseudonym, the client 852 silently ignores the EAP packet with AT_PERMANENT_ID_REQ, because 853 the client believes that the valid network is able to decode the 854 pseudonym. (Alternatively, the conservative client may respond to 855 AT_PERMANENT_ID_REQ in certain circumstances, for example if the 856 pseudonym was received a long time ago.) The benefit of this policy 857 is that it protects the client against active attacks on anonymity. 858 On the other hand, a "liberal" client always accepts the 859 AT_PERMANENT_ID_REQ and responds with the permanent identity. The 860 benefit of this policy is that it works even if the valid network 861 sometimes loses pseudonyms and is not able to decode them to the 862 permanent identity. 864 The value field of the AT_PERMANENT_ID_REQ does not contain any data 865 but the attribute is included to request the client to include the 866 AT_IDENTITY attribute (Section 8.6) with the permanent 868 EAP AKA Authentication June 2003 870 authentication identity in the EAP-Response/AKA-Identity message. In 871 this case, the AT_IDENTITY attribute contains the client's permanent 872 identity in the clear. 874 Please note that the EAP/AKA client and the EAP/AKA server only 875 process the AT_IDENTITY attribute. Entities that only pass EAP 876 packets through do not process this attribute. Hence, if the EAP 877 server is not co-located in the authenticator, then the 878 authenticator and other intermediate AAA elements (such as possible 879 AAA proxy servers) will continue to refer to the client with the 880 original identity from the EAP-Response/Identity packet regardless 881 if the decoding fails in the EAP server. 883 The figure below illustrates the case when the EAP server fails to 884 decode the pseudonym included in the EAP-Response/Identity packet. 886 Client Authenticator 887 | | 888 | EAP-Request/Identity | 889 |<------------------------------------------------------| 890 | | 891 | EAP-Response/Identity | 892 | (Includes a pseudonym) | 893 |------------------------------------------------------>| 894 | | 895 | +------------------------------+ 896 | | Server fails to decode the | 897 | | Pseudonym. | 898 | +------------------------------+ 899 | | 900 | EAP-Request/AKA-Identity | 901 | (AT_PERMANENT_ID_REQ) | 902 |<------------------------------------------------------| 903 | | 904 | | 905 | EAP-Response/AKA-Identity | 906 | (AT_IDENTITY with permanent identity) | 907 |------------------------------------------------------>| 908 | | 910 If the server recognizes the permanent identity, then the 911 authentication sequence proceeds as usual with the EAP Server 912 issuing the EAP-Request/AKA-Challenge message. 914 If the server does not recognize the permanent identity, or if the 915 server is not able to continue the authentication exchange with the 916 client after receiving the permanent identity, then the server 917 issues the EAP Failure packet and the authentication exchange 918 terminates. 920 The figure below illustrates the case when the EAP server fails to 921 decode the pseudonym included in the AT_IDENTITY attribute. 923 EAP AKA Authentication June 2003 925 Client Authenticator 926 | | 927 | +------------------------------+ 928 | | Server does not have any | 929 | | Subscriber identity available| 930 | | When starting EAP/AKA | 931 | +------------------------------+ 932 | | 933 | EAP-Request/AKA-Identity | 934 | (AT_ANY_ID_REQ) | 935 |<------------------------------------------------------| 936 | | 937 | | 938 |EAP-Response/AKA-Identity | 939 |(AT_IDENTITY with a pseudonym identity) | 940 |------------------------------------------------------>| 941 | | 942 | | 943 | +------------------------------+ 944 | | Server fails to decode the | 945 | | Pseudonym in AT_IDENTITY | 946 | +------------------------------+ 947 | | 948 | EAP-Request/AKA-Identity | 949 | (AT_PERMANENT_ID_REQ) | 950 |<------------------------------------------------------| 951 | | 952 | | 953 | EAP-Response/AKA-Identity | 954 | (AT_IDENTITY with permanent identity) | 955 |------------------------------------------------------>| 956 | | 958 In the worst case, there are three EAP/AKA-Identity round trips 959 before the server has obtained an acceptable identity: on the first 960 round, the client sends its re-authentication identity in 961 AT_IDENTITY. The server fails to accept it and request a full 962 authentication identity with a second EAP-Request/AKA-Identity. The 963 client responds with a pseudonym identity in AT_IDENTITY. The server 964 fails to decode the pseudonym and has to issue a third EAP- 965 Request/AKA-Identity, including AT_PERMANENT_ID_REQ. Finally, the 966 server accepts the client's EAP-Response/AKA-Identity with the 967 AT_IDENTITY attribute and proceeds with full authentication. This is 968 illustrated in the figure below. 970 EAP AKA Authentication June 2003 972 Client Authenticator 973 | | 974 | +------------------------------+ 975 | | Server does not have any | 976 | | Subscriber identity available| 977 | | When starting EAP/AKA | 978 | +------------------------------+ 979 | | 980 | EAP-Request/AKA-Identity | 981 | (AT_ANY_ID_REQ) | 982 |<------------------------------------------------------| 983 | | 984 | EAP-Response/AKA-Identity | 985 | (AT_IDENTITY with re-authentication identity) | 986 |------------------------------------------------------>| 987 | | 988 | +------------------------------+ 989 | | Server does not accept | 990 | | The re-authentication | 991 | | Identity | 992 | +------------------------------+ 993 | | 994 | EAP-Request/AKA-Identity | 995 | (AT_FULLAUTH_ID_REQ) | 996 |<------------------------------------------------------| 997 | | 998 |EAP-Response/AKA-Identity | 999 |(AT_IDENTITY with a pseudonym identity) | 1000 |------------------------------------------------------>| 1001 | | 1002 | +------------------------------+ 1003 | | Server fails to decode the | 1004 | | Pseudonym in AT_IDENTITY | 1005 | +------------------------------+ 1006 | | 1007 | EAP-Request/AKA-Identity | 1008 | (AT_PERMANENT_ID_REQ) | 1009 |<------------------------------------------------------| 1010 | | 1011 | | 1012 | EAP-Response/AKA-Identity | 1013 | (AT_IDENTITY with permanent identity) | 1014 |------------------------------------------------------>| 1015 | | 1017 After the last EAP-Response/AKA-Identity message, the full 1018 authentication sequence proceeds as usual. If the EAP Server 1019 recognizes the permanent identity and is able to proceed, the server 1020 issues the EAP-Request/AKA-Challenge message. If the server does not 1021 recognize the permanent identity, or if the server is not able to 1022 continue the authentication exchange with the client after receiving 1023 the permanent identity, then the server issues the EAP Failure 1024 packet and the authentication exchange terminates. 1026 EAP AKA Authentication June 2003 1028 5. Re-authentication 1030 In some environments, EAP authentication may be performed 1031 frequently. Because the EAP AKA full authentication procedure makes 1032 use of the UMTS AKA algorithms, and it therefore requires fresh 1033 authentication vectors from the Authentication Centre, the full 1034 authentication procedure may result in many network operations when 1035 used very frequently. Therefore, EAP AKA includes a more inexpensive 1036 re-authentication procedure that does not make use of the UMTS AKA 1037 algorithms and does not need new vectors from the Authentication 1038 Centre. 1040 Re-authentication is optional to implement for both the EAP AKA 1041 server and client. On each EAP authentication, either one of the 1042 entities may also fall back on full authentication if they do not 1043 want to use re-authentication. 1045 Re-authentication is based on the keys derived on the preceding full 1046 authentication. The same K_aut and K_encr keys as in full 1047 authentication are used to protect EAP AKA packets and attributes, 1048 and the original Master Key from full authentication is used to 1049 generate a fresh Master Session Key, as specified in Section 10. 1051 On re-authentication, the client protects against replays with an 1052 unsigned 16-bit counter, included in the AT_COUNTER attribute. On 1053 full authentication, both the server and the client initialize the 1054 counter to one. The counter value of at least one is used on the 1055 first re-authentication. On subsequent re-authentications, the 1056 counter MUST be greater than on any of the previous re- 1057 authentications. For example, on the second re-authentication, 1058 counter value is two or greater etc. The AT_COUNTER attribute is 1059 encrypted. 1061 The server includes an encrypted server nonce (AT_NONCE_S) in the 1062 re-authentication request. The AT_MAC attribute in the client's 1063 response is calculated over NONCE_S to provide a challenge/response 1064 authentication scheme. The NONCE_S also contributes to the new 1065 Master Session Key. 1067 As discussed in Section 4.3, in some environments the client may 1068 assume that the network can reliably store pseudonyms and therefore 1069 the client may fail to respond to the AT_PERMANENT_ID_REQ attribute. 1070 The network SHOULD store pseudonyms on a reliable database. Because 1071 one of the objectives of the re-authentication procedure is to 1072 reduce load on the network, the re-authentication procedure does not 1073 require the EAP server to contact a reliable database. Therefore, 1074 the re-authentication procedure makes use of separate re- 1075 authentication user identities. Pseudonyms and the permanent 1076 identity are reserved for full authentication only. The network does 1077 not need to store re-authentication identities as carefully as 1078 pseudonyms. If a re-authentication identity is lost and the network 1079 does not recognize it, the EAP server can fall back on full 1080 authentication. 1082 EAP AKA Authentication June 2003 1084 If the EAP server supports re-authentication, it MAY include the 1085 skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP- 1086 Request/AKA-Challenge message. This attribute contains a new re- 1087 authentication identity for the next re-authentication. The client 1088 MAY ignore this attribute, in which case it will use full 1089 authentication next time. If the client wants to use re- 1090 authentication, it uses this re-authentication identity on next 1091 authentication. Even if the client has a re-authentication identity, 1092 the client MAY discard the re-authentication identity and use a 1093 pseudonym or the permanent identity instead, in which case full 1094 authentication will be performed. 1096 The re-authentication identity received in AT_NEXT_REAUTH_ID 1097 contains both the username portion and the realm portion of the 1098 Network Access Identifier. The EAP Server can choose an appropriate 1099 realm part in order to have the AAA infrastructure route subsequent 1100 re-authentication related requests to the same AAA server. For 1101 example, the realm part MAY include a portion that is specific to 1102 the AAA server. Hence, it is sufficient to store the context 1103 required for re-authentication in the AAA server that performed the 1104 full authentication. 1106 The client MAY use the re-authentication identity in the EAP- 1107 Response/Identity packet or, in response to server's AT_ANY_ID_REQ 1108 attribute, the client MAY use the re-authentication identity in the 1109 AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet. 1111 Even if the client uses a re-authentication identity, the server may 1112 want to fall back on full authentication, for example because the 1113 server does not recognize the re-authentication identity or does not 1114 want to use re-authentication. If the server was able to decode the 1115 re-authentication identity to the permanent identity, the server 1116 issues the EAP-Request/AKA-Challenge packet to initiate full 1117 authentication. If the server was not able to recover the client's 1118 identity from the re-authentication identity, the server starts the 1119 full authentication procedure by issuing an EAP-Request/AKA-Identity 1120 packet. This packet always starts a full authentication sequence if 1121 it does not include the AT_ANY_ID_REQ attribute. (As specified in 1122 Sections 4.2 and 4.3, the server MAY use AT_ANY_ID_REQ, 1123 AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ attributes if it does not 1124 know the client's identity.) 1126 Both the client and the server SHOULD have an upper limit for the 1127 number of subsequent re-authentications allowed before a full 1128 authentication needs to be performed. Because a 16-bit counter is 1129 used in re-authentication, the theoretical maximum number of re- 1130 authentications is reached when the counter value reaches 0xFFFF. 1132 In order to use re-authentication, the client and the server need to 1133 store the following values: original Master Key, K_aut, K_encr, 1134 latest counter value and the next re-authentication identity. 1136 The following figure illustrates the re-authentication procedure. 1137 Encrypted attributes are denoted with '*'. The client uses its re- 1139 EAP AKA Authentication June 2003 1141 authentication identity in the EAP-Response/Identity packet. As 1142 discussed above, an alternative way to communicate the re- 1143 authentication identity to the server is for the client to use the 1144 AT_IDENTITY attribute in the EAP-Response/AKA-Identity message. This 1145 latter case is not illustrated in the figure below, and it is only 1146 possible when the server requests the client to send its identity by 1147 including the AT_ANY_ID_REQ attribute in the EAP-Request/AKA- 1148 Identity packet. 1150 If the server recognizes the re-authentication identity and agrees 1151 on using re-authentication, then the server sends the EAP- 1152 Request/AKA-Reauthentication packet to the client. This packet MUST 1153 include the encrypted AT_COUNTER attribute, with a fresh counter 1154 value, the encrypted AT_NONCE_S attribute that contains a random 1155 number chosen by the server, the AT_ENCR_DATA and the AT_IV 1156 attributes used for encryption, and the AT_MAC attribute that 1157 contains a message authentication code over the packet. The packet 1158 MAY also include an encrypted AT_NEXT_REAUTH_ID attribute that 1159 contains the next re-authentication identity. 1161 Re-authentication identities are one-time identities. If the client 1162 does not receive a new re-authentication identity, it MUST use 1163 either the permanent identity or a pseudonym identity on the next 1164 authentication to initiate full authentication. 1166 The client verifies that the counter value is fresh (greater than 1167 any previously used value). The client also verifies that AT_MAC is 1168 correct. The client MAY save the next re-authentication identity 1169 from the encrypted AT_NEXT_REAUTH_ID for next time. If all checks 1170 are successful, the client responds with the EAP-Response/AKA- 1171 Reauthentication packet, including the AT_COUNTER attribute with the 1172 same counter value and the AT_MAC attribute. 1174 The server verifies the AT_MAC attribute and also verifies that the 1175 counter value is the same that it used in the EAP-Request/AKA- 1176 Reauthentication packet. If these checks are successful, the re- 1177 authentication has succeeded and the server sends the EAP-Success 1178 packet to the client. 1180 EAP AKA Authentication June 2003 1182 Client Authenticator 1183 | | 1184 | EAP-Request/Identity | 1185 |<------------------------------------------------------| 1186 | | 1187 | EAP-Response/Identity | 1188 | (Includes a re-authentication identity) | 1189 |------------------------------------------------------>| 1190 | | 1191 | +--------------------------------+ 1192 | | Server recognizes the identity | 1193 | | and agrees on using fast | 1194 | | re-authentication | 1195 | +--------------------------------+ 1196 | | 1197 | EAP-Request/AKA-Reauthentication | 1198 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1199 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1200 |<------------------------------------------------------| 1201 | | 1202 | | 1203 +-----------------------------------------------+ | 1204 | Client verifies AT_MAC and the freshness of | | 1205 | the counter. Client MAY store the new re- | | 1206 | authentication identity for next re-auth. | | 1207 +-----------------------------------------------+ | 1208 | | 1209 | EAP-Response/AKA-Reauthentication | 1210 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, | 1211 | AT_MAC) | 1212 |------------------------------------------------------>| 1213 | | 1214 | +--------------------------------+ 1215 | | Server verifies AT_MAC and | 1216 | | the counter | 1217 | +--------------------------------+ 1218 | | 1219 | EAP-Success | 1220 |<------------------------------------------------------| 1221 | | 1223 If the client does not accept the counter value of EAP-Request/AKA- 1224 Reauthentication, it indicates the counter synchronization problem 1225 by including the encrypted AT_COUNTER_TOO_SMALL in EAP-Response/AKA- 1226 Reauthentication. The server responds with EAP-Request/AKA-Challenge 1227 to initiate a normal full authentication procedure. This is 1228 illustrated in the following figure. Encrypted attributes are 1229 denoted with '*'. 1231 EAP AKA Authentication June 2003 1233 Client Authenticator 1234 | | 1235 | EAP-Request/Identity | 1236 |<------------------------------------------------------| 1237 | | 1238 | EAP-Response/Identity | 1239 | (Includes a re-authentication identity) | 1240 |------------------------------------------------------>| 1241 | | 1242 | EAP-Request/AKA-Reauthentication | 1243 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1244 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1245 |<------------------------------------------------------| 1246 | | 1247 +-----------------------------------------------+ | 1248 | AT_MAC is valid but the counter is not fresh. | | 1249 +-----------------------------------------------+ | 1250 | | 1251 | EAP-Response/AKA-Reauthentication | 1252 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, | 1253 | *AT_COUNTER, AT_MAC) | 1254 |------------------------------------------------------>| 1255 | | 1256 | +----------------------------------------------+ 1257 | | Server verifies AT_MAC but detects | 1258 | | That client has included AT_COUNTER_TOO_SMALL| 1259 | +----------------------------------------------+ 1260 | | 1261 | EAP-Request/AKA-Challenge | 1262 |<------------------------------------------------------| 1263 | | 1264 +---------------------------------------------------------------+ 1265 | Normal full authentication follows. | 1266 +---------------------------------------------------------------+ 1267 | | 1269 In the figure above, the first three messages are similar to the 1270 basic re-authentication case. When the client detects that the 1271 counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL 1272 attribute in EAP-Response/AKA-Reauthentication. This attribute 1273 doesn't contain any data but it is a request for the server to 1274 initiate full authentication. In this case, the client MUST ignore 1275 the contents of the server's AT_NEXT_REAUTH_ID attribute. 1277 On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and 1278 verifies that AT_COUNTER contains the same as in the EAP- 1279 Request/AKA-Reauthentication packet. If not, the server silently 1280 discards the EAP-Response/AKA-Reauthentication packet. If all checks 1281 on the packet are successful, the server transmits a EAP- 1282 Request/AKA-Challenge packet and the full authentication procedure 1283 is performed as usual. Since the server already knows the subscriber 1284 identity, it MUST NOT use the EAP-Request/AKA-Identity packet to 1285 request the identity. 1287 EAP AKA Authentication June 2003 1289 6. Message Format 1291 The Type-Data of the EAP AKA packets begins with a 1-octet Subtype 1292 field, which is followed by a 2-octet reserved field. The rest of 1293 the Type-Data consists of attributes that are encoded in Type, 1294 Length, Value format. The figure below shows the generic format of 1295 an attribute. 1297 0 1 2 3 1298 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 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 |Attribute Type | Length | Value... 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 Attribute Type 1305 Indicates the particular type of attribute. The attribute type 1306 values are listed in Section 11. 1308 Length 1310 Indicates the length of this attribute in multiples of 4 bytes. 1311 The maximum length of an attribute is 1024 bytes. The length 1312 includes the Attribute Type and Length bytes. 1314 Value 1316 The particular data associated with this attribute. This field is 1317 always included and it is two or more bytes in length. The type 1318 and length fields determine the format and length of the value 1319 field. 1321 When an attribute numbered within the range 0 through 127 is 1322 encountered but not recognized, the EAP/AKA message containing that 1323 attribute MUST be silently discarded. These attributes are called 1324 non-skippable attributes. 1326 When an attribute numbered in the range 128 through 255 is 1327 encountered but not recognized that particular attribute is ignored, 1328 but the rest of the attributes and message data MUST still be 1329 processed. The Length field of the attribute is used to skip the 1330 attribute value when searching for the next attribute. These 1331 attributes are called skippable attributes. 1333 EAP/AKA packets do not include a version field. However, should 1334 there be a reason to revise this protocol in the future, new non- 1335 skippable or skippable attributes could be specified in order to 1336 implement revised EAP/AKA versions in a backward-compatible manner. 1338 Unless otherwise specified, the order of the attributes in an EAP 1339 AKA message is insignificant, and an EAP AKA implementation should 1340 not assume a certain order to be used. 1342 EAP AKA Authentication June 2003 1344 Attributes can be encapsulated within other attributes. In other 1345 words, the value field of an attribute type can be specified to 1346 contain other attributes. 1348 7. Message Authentication and Encryption 1350 This section specifies EAP/AKA attributes for attribute encryption 1351 and EAP/AKA message authentication. 1353 Encryption and integrity protection are based on the AKA session 1354 keys CK and IK. Because the CK and IK keys are derived from the RAND 1355 challenge, these attributes can only be used in the EAP-Request/AKA- 1356 Challenge message and any EAP/AKA messages sent after it. For 1357 example, these attributes cannot be used in EAP-Request/AKA- 1358 Identity, because the RAND challenge has not yet been transmitted at 1359 that point. Integrity protection with AT_MAC MUST be used in all 1360 messages when keys have been derived. 1362 7.1. AT_MAC Attribute 1364 The AT_MAC attribute can be used for EAP/AKA message integrity 1365 protection. Whenever AT_ENCR_DATA (Section 7.3) is included in an 1366 EAP message, it MUST be followed (not necessarily immediately) by an 1367 AT_MAC attribute. Messages that do not meet this condition MUST be 1368 silently discarded. 1370 The value field of the AT_MAC attribute contains two reserved bytes 1371 followed by a message authentication code (MAC). The MAC is 1372 calculated over the whole EAP packet, concatenated with optional 1373 message-specific data, with the exception that the value field of 1374 the MAC attribute is set to zero when calculating the MAC. The 1375 reserved bytes are set to zero when sending and ignored on 1376 reception. 1378 The contents of the message-specific data, if present, are specified 1379 separately for each EAP/AKA message. The message-specific data is 1380 included in order to protect data that is not transmitted with the 1381 EAP packet. 1383 The format of the AT_MAC attribute is shown below. 1385 0 1 2 3 1386 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 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | AT_MAC | Length = 5 | Reserved | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | | 1391 | MAC | 1392 | | 1393 | | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 The MAC algorithm is HMAC-SHA1-128 [9] keyed hash value. (The HMAC- 1397 SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by 1399 EAP AKA Authentication June 2003 1401 truncating the output to 16 bytes. Hence, the length of the MAC is 1402 16 bytes.) The message authentication key (K_aut) used in the 1403 calculation of the MAC is derived from the AKA integrity key (IK) 1404 and cipher key (CK), as specified in Section 10. 1406 7.2. AT_CHECKCODE Attribute 1408 The AT_MAC attribute is not used in the very first EAP/AKA messages, 1409 because keying material has not been derived yet. The client and the 1410 server may exchange one or more pairs of EAP/AKA messages of the 1411 Subtype AKA-Identity before keys are derived and before the AT_MAC 1412 attribute can be applied. The EAP/AKA-Identity messages may also be 1413 used upon re-authentication. 1415 The AT_CHECKCODE attribute MAY be used to protect the EAP/AKA- 1416 Identity messages. AT_CHECKCODE is included in EAP-Request/AKA- 1417 Challenge and/or EAP-Response/AKA-Challenge upon full 1418 authentication. In re-authentication, AT_CHECKCODE can be included 1419 in EAP-Request/AKA-Reauthentication and/or EAP-Response/AKA- 1420 Reauthentication. Because the AT_MAC attribute is used in these 1421 messages, AT_CHECKCODE will be integrity protected with AT_MAC. 1422 The format of the AT_CHECKCODE attribute is shown below. 1424 0 1 2 3 1425 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 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | AT_CHECKCODE | Length | Reserved | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | | 1430 | Checkcode (0 or 20 bytes) | 1431 | | 1432 | | 1433 | | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 The value field of AT_CHECKCODE begins with two reserved bytes, 1437 which may be followed by a 20-byte checkcode. If the checkcode is 1438 not included in AT_CHECKCODE, then the attribute indicates that no 1439 EAP/AKA-Identity messages were exchanged. This may occur in both 1440 full authentication and re-authentication. The reserved bytes are 1441 set to zero when sending and ignored on reception. 1443 The checkcode is a hash value, calculated with SHA1 [10], over all 1444 EAP-Request/AKA-Identity and EAP-Response/ AKA-Identity packets 1445 exchanged in this authentication exchange. The packets are included 1446 in the order that they were transmitted, that is, starting with the 1447 first EAP-Request/ AKA-Identity message, followed by the 1448 corresponding EAP-Response/ AKA-Identity, followed by the second 1449 EAP-Request/ AKA-Identity (if used) etc. 1451 EAP packets are included in the hash calculation "as-is", as they 1452 were transmitted or received. All reserved bytes, padding bytes etc. 1453 that are specified for various attributes are included as such, and 1454 the receiver must not reset them to zero. No delimiter bytes, 1456 EAP AKA Authentication June 2003 1458 padding or any other framing are included between the EAP packets 1459 when calculating the checkcode. 1461 Messages are included in request/response pairs; in other words only 1462 full "round trips" are included. Packets that are silently discarded 1463 are not included. The EAP server must only include an EAP- 1464 Request/AKA-Identity in the calculation once it has received a 1465 corresponding response, with the same Identifier value. 1466 Retransmissions or requests to which the server does not receive 1467 response are not included. 1469 The client must include the EAP-Request/AKA-Identity and the 1470 corresponding response in the calculation only if the client 1471 receives a subsequent EAP-Request/AKA-Challenge, or a follow-up EAP- 1472 Request/AKA-Identity with different attributes (attribute types) 1473 than in the first EAP-Request/AKA-Identity. After sending EAP- 1474 Response/AKA-Identity, if the client receives another EAP- 1475 Request/AKA-Identity with the same attributes as in the previous 1476 request, then the client's response to the first request must have 1477 been lost. In this case the client must not include the first 1478 request and its response in the calculation of the checkcode. 1480 The AT_CHECKCODE attribute is optional to implement. It is specified 1481 in order to allow protecting the EAP/ AKA-Identity messages and any 1482 future extensions to them. The implementation of AT_CHECKCODE is 1483 recommended. 1485 If the receiver of AT_CHECKCODE implements this attribute, then the 1486 receiver MUST check that the checkcode is correct. If the checkcode 1487 is invalid, the receiver must terminate the authentication exchange. 1489 If the EAP/AKA-Identity messages are extended with new attributes 1490 then AT_CHECKCODE must be implemented and used. More specifically, 1491 if the server includes any other attributes than 1492 AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ or AT_ANY_ID_REQ in the EAP- 1493 Request/AKA-Identity packet, then the server MUST include 1494 AT_CHECKCODE in EAP-Request/AKA-Challenge or EAP-Request/AKA- 1495 Reauthentication. If the client includes any other attributes than 1496 AT_IDENTITY in the EAP-Response/AKA-Identity message, then the 1497 client MUST include AT_CHECKCODE in EAP-Response/AKA-Challenge or 1498 EAP-Response/AKA-Reauthentication. 1500 If the server implements the processing of any other attribute than 1501 AT_IDENTITY for the EAP-Response/AKA-Identity message, then the 1502 server MUST implement AT_CHECKCODE. In this case, if the server 1503 receives any other attribute than AT_IDENTITY in the EAP- 1504 Response/AKA-Identity message, then the server MUST check that 1505 AT_CHECKCODE is present in EAP-Response/AKA-Challenge or EAP- 1506 Response/AKA-Reauthentication. If AT_CHECKCODE is not included, the 1507 server must terminate the authentication exchange. 1509 Similarly, if the client implements the processing of any other 1510 attribute than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ or 1511 AT_ANY_ID_REQ for the EAP-Request/AKA-Identity packet, then the 1513 EAP AKA Authentication June 2003 1515 client MUST implement AT_CHECKCODE. In this case, if the client 1516 receives any other attribute than AT_PERMANENT_ID_REQ, 1517 AT_FULLAUTH_ID_REQ or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity 1518 packet, then the client MUST check that AT_CHECKCODE is present in 1519 EAP-Request/AKA-Challenge or EAP-Request/AKA-Reauthentication. If 1520 the attribute was not included, the client must terminate the 1521 authentication exchange. 1523 7.3. AT_IV, AT_ENCR_DATA and AT_PADDING Attributes 1525 AT_IV and AT_ENCR_DATA attributes can be optionally used to transmit 1526 encrypted information between the EAP/AKA client and server. 1528 The value field of AT_IV contains two reserved bytes followed by a 1529 16-byte initialization vector required by the AT_ENCR_DATA 1530 attribute. The reserved bytes are set to zero when sending and 1531 ignored on reception. The AT_IV attribute MUST be included if and 1532 only if the AT_ENCR_DATA is included. Messages that do not meet this 1533 condition MUST be silently discarded. 1535 The sender of the AT_IV attribute chooses the initialization vector 1536 by random. The sender MUST NOT reuse the initialization vector value 1537 from previous EAP AKA packets but the sender MUST choose it freshly 1538 for each AT_IV attribute. The sends SHOULD use a good source of 1539 randomness to generate the initialization vector. The format of 1540 AT_IV is shown below. 1542 0 1 2 3 1543 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 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | AT_IV | Length = 5 | Reserved | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | | 1548 | Initialization Vector | 1549 | | 1550 | | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 The value field of the AT_ENCR_DATA attribute consists of two 1554 reserved bytes followed by bytes encrypted using the Advanced 1555 Encryption Standard (AES) [11] in the Cipher Block Chaining (CBC) 1556 mode of operation, using the initialization vector from the AT_IV 1557 attribute. The reserved bytes are set to zero when sending and 1558 ignored on reception. Please see [12] for a description of the CBC 1559 mode. The format of the AT_ENCR_DATA attribute is shown below. 1561 EAP AKA Authentication June 2003 1563 0 1 2 3 1564 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 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | AT_ENCR_DATA | Length | Reserved | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | | 1569 . Encrypted Data . 1570 . . 1571 | | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 The encryption key (K_encr) is derived is derived from the AKA 1575 integrity key (IK) and cipher key (CK), as specified in Section10. 1576 The plaintext consists of nested EAP/AKA attributes. 1578 The encryption algorithm requires the length of the plaintext to be 1579 a multiple of 16 bytes. The sender may need to include the 1580 AT_PADDING attribute as the last attribute within AT_ENCR_DATA. The 1581 AT_PADDING attribute is not included if the total length of other 1582 nested attributes within the AT_ENCR_DATA attribute is a multiple of 1583 16 bytes. As usual, the Length of the Padding attribute includes the 1584 Attribute Type and Attribute Length fields. The Length of the 1585 Padding attribute is 4, 8 or 12 bytes. It is chosen so that the 1586 length of the value field of the AT_ENCR_DATA attribute becomes a 1587 multiple of 16 bytes. The actual pad bytes in the value field are 1588 set to zero (0x00) on sending. The recipient of the message MUST 1589 verify that the pad bytes are set to zero, and silently drop the 1590 message if this verification fails. The format of the AT_PADDING 1591 attribute is shown below. 1593 0 1 2 3 1594 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 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | AT_PADDING | Length | Padding... | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1598 | | 1599 | | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 8. Messages 1604 8.1. EAP-Request/AKA-Challenge 1606 The format of the EAP-Request/AKA-Challenge packet is shown below. 1608 EAP AKA Authentication June 2003 1610 0 1 2 3 1611 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 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Code | Identifier | Length | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | Type | Subtype | Reserved | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | AT_RAND | Length = 5 | Reserved | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 | | 1620 | RAND | 1621 | | 1622 | | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | AT_AUTN | Length = 5 | Reserved | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | | 1627 | AUTN | 1628 | | 1629 | | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | AT_IV | Length = 5 | Reserved | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | | 1634 | Initialization Vector (optional) | 1635 | | 1636 | | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | AT_ENCR_DATA | Length | Reserved | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | | 1641 | Encrypted Data (optional) | 1642 | | 1643 | | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | AT_CHECKCODE | Length | Reserved | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | | 1648 | Checkcode (optional) | 1649 | | 1650 | | 1651 | | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | AT_MAC | Length = 5 | Reserved | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | | 1656 | MAC | 1657 | | 1658 | | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 The semantics of the fields is described below: 1663 EAP AKA Authentication June 2003 1665 Code 1667 1 for Request 1669 Identifier 1671 See [5] 1673 Length 1675 The length of the EAP Request packet. 1677 Type 1679 23 1681 Subtype 1683 1 for AKA-Challenge 1685 Reserved 1687 Set to zero when sending, ignored on reception. 1689 AT_RAND 1691 The value field of this attribute contains two reserved bytes 1692 followed by the AKA RAND parameter, 16 bytes (128 bits). The 1693 reserved bytes are set to zero when sending and ignored on 1694 reception. The AT_RAND attribute MUST be present in EAP- 1695 Request/AKA-Challenge. 1697 AT_AUTN 1699 The value field of this attribute contains two reserved bytes 1700 followed by the AKA AUTN parameter, 16 bytes (128 bits). The 1701 reserved bytes are set to zero when sending and ignored on 1702 reception. The AT_AUTN attribute MUST be included. 1704 AT_IV 1706 See Section 7.3. 1708 AT_ENCR_DATA 1710 See Section 7.3. The nested attributes that are included in the 1711 plaintext of AT_ENCR_DATA are described below. 1713 AT_CHECKCODE 1715 The AT_CHECKCODE attribute is optional to include. See section 1716 7.2 1718 EAP AKA Authentication June 2003 1720 AT_MAC 1722 AT_MAC MUST be included. In EAP-Request/AKA-Challenge, there is 1723 no message-specific data covered by the MAC. See Section 7.1. 1725 In the EAP-Request/AKA-Challege message, the AT_IV, AT_ENCR_DATA and 1726 AT_MAC attributes are used for Identity privacy and for 1727 communicating the next re-authentication identity. The plaintext of 1728 the AT_ENCR_DATA value field consists of nested attributes, which 1729 are shown below. Later versions of this protocol MAY specify 1730 additional attributes to be included within the encrypted data. 1732 0 1 2 3 1733 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 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | AT_NEXT_PS... | Length | Actual Pseudonym Length | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | | 1738 . Next Pseudonym . 1739 . . 1740 | | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length| 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | | 1745 . Next Re-authentication Username . 1746 . . 1747 | | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 | AT_PADDING | Length | Padding... | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1751 | | 1752 | | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 AT_NEXT_PSEUDONYM 1757 This attribute is optional. The value field of this attribute 1758 begins with a 2-byte actual pseudonym length, which specifies the 1759 length of the pseudonym in bytes. This field is followed by a 1760 pseudonym user name, of the indicated actual length, that the 1761 client can use in the next authentication, as described in 1762 Section 4.3. The user name does not include any terminating null 1763 characters. Because the length of the attribute must be a 1764 multiple of 4 bytes, the sender pads the pseudonym with zero 1765 bytes when necessary. 1767 AT_NEXT_REAUTH_ID 1769 The AT_NEXT_REAUTH_ID attribute is optional to include. The value 1770 field of this attribute begins with a 2-byte actual re- 1771 authentication identity length, which specifies the length of the 1772 re-authentication identity in bytes. This field is followed by a 1773 re-authentication identity, of the indicated actual length, that 1775 EAP AKA Authentication June 2003 1777 the client can use in the next re-authentication, as described in 1778 Section 5. The re-authentication identity includes both a 1779 username portion and a realm name portion. The re-authentication 1780 identity does not include any terminating null characters. 1781 Because the length of the attribute must be a multiple of 4 1782 bytes, the sender pads the re-authentication identity with zero 1783 bytes when necessary. 1785 AT_PADDING 1787 AT_PADDING is optional to include. See Section 7.3. 1789 8.2. EAP-Response/AKA-Challenge 1791 The format of the EAP-Response/AKA-Challenge packet is shown below. 1793 Later versions of this protocol MAY make use of the AT_ENCR_DATA and 1794 AT_IV attributes in this message to include encrypted (skippable) 1795 attributes. AT_MAC, AT_ENCR_DATA and AT_IV attributes are not shown 1796 in the figure below. If present, they are processed as in EAP- 1797 Request/AKA-Challenge packet. The EAP server MUST process EAP- 1798 Response/AKA-Challenge messages that include these attributes even 1799 if the server did not implement these optional attributes. 1801 0 1 2 3 1802 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 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Code | Identifier | Length | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Type | Subtype | Reserved | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | AT_RES | Length | RES Length | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1810 | | 1811 | RES | 1812 | | 1813 | | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | AT_CHECKCODE | Length | Reserved | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | | 1818 | Checkcode (optional) | 1819 | | 1820 | | 1821 | | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | AT_MAC | Length = 5 | Reserved | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | | 1826 | MAC | 1827 | | 1828 | | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 EAP AKA Authentication June 2003 1833 The semantics of the fields is described below: 1835 Code 1837 2 for Response 1839 Identifier 1841 See [5] 1843 Length 1845 The length of the EAP Response packet. 1847 Type 1849 23 1851 Subtype 1853 1 for AKA-Challenge 1855 Reserved 1857 Set to zero when sending, ignored on reception. 1859 AT_RES 1861 This attribute MUST be included in EAP-Response/AKA-Challenge. 1862 The value field of this attribute begins with the 2-byte RES 1863 Length, which is identifies the exact length of the RES in bits. 1864 The RES length is followed by the UMTS AKA RES parameter. 1865 According to the specification [13] the length of the AKA RES can 1866 vary between 32 and 128 bits. Because the length of the AT_RES 1867 attribute must be a multiple of 4 bytes, the sender pads the RES 1868 with zero bits where necessary. 1870 AT_CHECKCODE 1872 The AT_CHECKCODE attribute is optional to include. See section 1873 7.2 1875 AT_MAC 1877 AT_MAC MUST be included. In EAP-Response/AKA-Challenge, there is 1878 no message-specific data covered by the MAC. See Section 7.1. 1880 8.3. EAP-Response/AKA-Authentication-Reject 1882 The format of the EAP-Response/AKA-Authentication-Reject packet is 1883 shown below. 1885 EAP AKA Authentication June 2003 1887 0 1 2 3 1888 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 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | Code | Identifier | Length | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | Type | Subtype | Reserved | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 The semantics of the fields is described below: 1897 Code 1899 2 for Response 1901 Identifier 1903 See [5] 1905 Length 1907 The length of the EAP Response packet. 1909 Type 1911 23 1913 Subtype 1915 2 for AKA-Authentication-Reject 1917 Reserved 1919 Set to zero on sending, ignored on reception. 1921 8.4. EAP-Response/AKA-Synchronization-Failure 1923 The format of the EAP-Response/AKA-Synchronization-Failure packet is 1924 shown below. 1926 0 1 2 3 1927 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 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | Code | Identifier | Length | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | Type | Subtype | Reserved | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 1933 | AT_AUTS | Length = 4 | | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1935 | | 1936 | AUTS | 1937 | | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 EAP AKA Authentication June 2003 1942 The semantics of the fields is described below: 1944 Code 1946 2 for Response 1948 Identifier 1950 See [5] 1952 Length 1954 The length of the EAP Response packet, 20. 1956 Type 1958 23 1960 Subtype 1962 4 for AKA-Synchronization-Failure 1964 AT_AUTS 1966 This attribute MUST be included in EAP-Response/AKA- 1967 Synchronization-Failure. The value field of this attribute 1968 contains the AKA AUTS parameter, 112 bits (14 bytes). 1970 8.5. EAP-Request/AKA-Identity 1972 The format of the EAP-Request/AKA-Identity packet is shown below. 1974 0 1 2 3 1975 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 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 | Code | Identifier | Length | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | Type | Subtype | Reserved | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 |AT_PERM..._REQ | Length = 1 | Reserved | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 |AT_FULL..._REQ | Length = 1 | Reserved | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 |AT_ANY_ID_REQ | Length = 1 | Reserved | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 The semantics of the fields is described below: 1990 Code 1992 1 for Request 1994 EAP AKA Authentication June 2003 1996 Identifier 1998 See [5] 2000 Length 2002 The length of the EAP Request packet. 2004 Type 2006 23 2008 Subtype 2010 5 for AKA-Identity 2012 Reserved 2014 Set to zero on sending, ignored on reception. 2016 AT_PERMANENT_ID_REQ 2018 The AT_PERMANENT_ID_REQ attribute is optional to include and it 2019 is included in the cases defined in Section 4.3. It MUST NOT be 2020 included if AT_ANY_ID_REQ or AT_FULLAUTH_ID_REQ is included. The 2021 value field only contains two reserved bytes, which are set to 2022 zero on sending and ignored on reception. 2024 AT_FULLAUTH_ID_REQ 2026 The AT_FULLAUTH_ID_REQ attribute is optional to include and it is 2027 included in the cases defined in Section 4.2. It MUST NOT be 2028 included if AT_ANY_ID_REQ or AT_PERMANENT_ID_REQ is included. The 2029 value field only contains two reserved bytes, which are set to 2030 zero on sending and ignored on reception. 2032 AT_ANY_ID_REQ 2034 The AT_ANY_ID_REQ attribute is optional and it is included in the 2035 cases defined in Section 4.2. It MUST NOT be included if 2036 AT_PERMANENT_ID_REQ or AT_FULLAUTH_ID_REQ is included. The value 2037 field only contains two reserved bytes, which are set to zero on 2038 sending and ignored on reception. 2040 8.6. EAP-Response/AKA-Identity 2042 The format of the EAP-Response/AKA-Identity packet is shown below. 2044 EAP AKA Authentication June 2003 2046 0 1 2 3 2047 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 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 | Code | Identifier | Length | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | Type | Subtype | Reserved | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | AT_IDENTITY | Length | Actual Identity Length | 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 | | 2056 . Current Identity . 2057 . . 2058 | | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 The semantics of the fields is described below: 2063 Code 2065 2 for Response 2067 Identifier 2069 See [5] 2071 Length 2073 The length of the EAP Response packet. 2075 Type 2077 23 2079 Subtype 2081 5 for AKA-Identity 2083 Reserved 2085 Set to zero on sending, ignored on reception. 2087 AT_IDENTITY 2089 The AT_IDENTITY attribute is optional to include and it is 2090 included in cases defined in Section 4.2 and 4.3. The value field 2091 of this attribute begins with 2-byte actual identity length, 2092 which specifies the length of the identity in bytes. This field 2093 is followed by the subscriber identity of the indicated actual 2094 length, in the same Network Access Identifier format that is used 2095 in EAP-Response/Identity, i.e. including the NAI realm portion. 2096 The identity is the permanent identity, a pseudonym identity or a 2097 re-authentication identity. The identity format is specified in 2098 Section 4.1. The identity does not include any terminating null 2099 characters. Because the length of the attribute must be a 2101 EAP AKA Authentication June 2003 2103 multiple of 4 bytes, the sender pads the identity with zero bytes 2104 when necessary. 2106 8.7. EAP-Request/AKA-Reauthentication 2108 The format of the EAP-Request/AKA-Reauthentication packet is shown 2109 below. 2111 0 1 2 3 2112 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 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | Code | Identifier | Length | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 | Type | Subtype | Reserved | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | AT_IV | Length = 5 | Reserved | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 | | 2121 | Initialization Vector | 2122 | | 2123 | | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2125 | AT_ENCR_DATA | Length | Reserved | 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 | | 2128 . Encrypted Data . 2129 . . 2130 | | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | AT_CHECKCODE | Length | Reserved | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | | 2135 | Checkcode (optional) | 2136 | | 2137 | | 2138 | | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | AT_MAC | Length = 5 | Reserved | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | | 2143 | | 2144 | MAC | 2145 | | 2146 | | 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 Code 2151 1 for Request 2153 Identifier 2155 See [5]. 2157 EAP AKA Authentication June 2003 2159 Length 2161 The length of the EAP packet. 2163 Type 2165 23 2167 Subtype 2169 13 2171 Reserved 2173 Set to zero when sending, ignored on reception. 2175 AT_IV 2177 The AT_IV attribute is MUST be included. See Section 7.3. 2179 AT_ENCR_DATA 2181 The AT_ENCR_DATA attribute MUST be included. See Section 7.3. The 2182 plaintext consists of nested attributes as described below. 2184 AT_CHECKCODE 2186 The AT_CHECKCODE attribute is optional to include. See section 2187 7.2 2189 AT_MAC 2191 AT_MAC MUST be included. No message-specific data is included in 2192 the MAC calculation. See Section 7.1. 2194 The AT_IV and AT_ENCR_DATA attributes are used for communicating 2195 encrypted attributes. The plaintext of the AT_ENCR_DATA value field 2196 consists of nested attributes, which are shown below. 2198 EAP AKA Authentication June 2003 2200 0 1 2 3 2201 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 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | AT_COUNTER | Length = 1 | Counter | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | AT_NONCE_S | Length = 5 | Reserved | 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | | 2208 | | 2209 | NONCE_S | 2210 | | 2211 | | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length| 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 | | 2216 . Next Re-authentication Username . 2217 . . 2218 | | 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 | AT_PADDING | Length | Padding... | 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2222 | | 2223 | | 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 AT_COUNTER 2228 The AT_COUNTER attribute MUST be included. The value field 2229 consists of a 16-bit unsigned integer counter value, represented 2230 in network byte order. 2232 AT_NONCE_S 2234 The AT_NONCE_S attribute MUST be included. The value field 2235 contains two reserved bytes followed by a random number generated 2236 by the server (16 bytes) freshly for this EAP/AKA re- 2237 authentication. The random number is used as challenge for the 2238 client and also a seed value for the new keying material. The 2239 reserved bytes are set to zero upon sending and ignored upon 2240 reception. 2242 AT_NEXT_REAUTH_ID 2244 The AT_NEXT_REAUTH_ID attribute is optional to include. The 2245 attribute is described in Section 8.1. 2247 AT_PADDING 2249 The AT_PADDING attribute is optional to include. See section 7.3 2251 8.8. EAP-Response/AKA-Reauthentication 2253 EAP AKA Authentication June 2003 2255 The format of the EAP-Response/AKA-Reauthentication packet is shown 2256 below. 2258 0 1 2 3 2259 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 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 | Code | Identifier | Length | 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 | Type | Subtype | Reserved | 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 | AT_IV | Length = 5 | Reserved | 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 | | 2268 | Initialization Vector | 2269 | | 2270 | | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 | AT_ENCR_DATA | Length | Reserved | 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | | 2275 . Encrypted Data . 2276 . . 2277 | | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | AT_CHECKCODE | Length | Reserved | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | | 2282 | Checkcode (optional) | 2283 | | 2284 | | 2285 | | 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 | AT_MAC | Length = 5 | Reserved | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | | 2290 | | 2291 | MAC | 2292 | | 2293 | | 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 Code 2298 2 for Response 2300 Identifier 2302 See [5]. 2304 Length 2306 The length of the EAP packet. 2308 EAP AKA Authentication June 2003 2310 Type 2312 23 2314 Subtype 2316 13 2318 Reserved 2320 Set to zero when sending, ignored on reception. 2322 AT_IV 2324 The AT_IV attribute is MUST be included. See Section 7.3. 2326 AT_ENCR_DATA 2328 The AT_ENCR_DATA attribute MUST be included. See Section 7.3. The 2329 plaintext consists of nested attributes as described below. 2331 AT_CHECKCODE 2333 The AT_CHECKCODE attribute is optional to include. See section 2334 7.2 2336 AT_MAC 2338 For EAP-Response/AKA-Reauthentication, the MAC code is calculated 2339 over the following data: 2341 EAP packet| NONCE_S 2343 The EAP packet is represented as specified in Section 7.1. It is 2344 followed by the 16-byte NONCE_S value from the server's 2345 AT_NONCE_S attribute. 2347 The AT_IV and AT_ENCR_DATA attributes are used for communicating 2348 encrypted attributes. The plaintext of the AT_ENCR_DATA value field 2349 consists of nested attributes, which are shown below. 2351 0 1 2 3 2352 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 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | AT_COUNTER | Length = 1 | Counter | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | AT_COUNTER...| Length = 1 | Reserved | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | AT_PADDING | Length | Padding... | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2360 | | 2361 | | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 EAP AKA Authentication June 2003 2366 AT_COUNTER 2368 The AT_COUNTER attribute MUST be included. The format of this 2369 attribute is specified in Section 8.7. 2371 AT_COUNTER_TOO_SMALL 2373 The AT_COUNTER_TOO_SMALL attribute is optional to include, and it 2374 is included in cases specified in Section 5. 2376 AT_PADDING 2378 The AT_PADDING attribute is optional to include. See section 7.3 2380 8.9. EAP/AKA Notifications 2382 The EAP-Request/Notification, specified in [5], can be used to 2383 convey a displayable message from the authenticator to the client. 2384 Because these messages are textual messages, it may be hard for the 2385 client to present them in the user's preferred language. Therefore, 2386 EAP/AKA uses a separate EAP/AKA message subtype to transmit 2387 localizable notification codes instead of the EAP- 2388 Request/Notification packet. 2390 The EAP server MAY issue an EAP-Request/AKA-Notification packet to 2391 the client. The client MAY show a notification message to the user 2392 and the client MUST respond to the EAP server with an EAP- 2393 Response/AKA-Notification packet, even if the client did not 2394 recognize the notification code. 2396 The notification code is a 16-bit number. The most significant bit 2397 is called the Failure bit (F bit). The F bit specifies whether the 2398 notification implies failure. The code values with the F bit set to 2399 zero (code values 0...32767) are used on unsuccessful cases. The 2400 receipt of a notification code from this range implies failed 2401 authentication, so the client can use the notification as a failure 2402 indication. After receiving the EAP-Response/AKA-Notification for 2403 these notification codes, the server MUST send the EAP-Failure 2404 packet. 2406 The receipt of a notification code with the F bit set to one (values 2407 32768...65536) does not imply failure, so the client MUST NOT change 2408 its state when it receives such a notification. 2410 The second most significant bit of the notification code is called 2411 the Phase bit (P bit). It specifies at which phase of the EAP/AKA 2412 exchange the notification can be used. If the P bit is set to zero, 2413 the notification can only be used after the EAP/AKA-Challenge round 2414 in full authentication or the EAP/AKA-Reauthentication round in re- 2415 autentication. For these notifications, the AT_MAC attribute MUST be 2416 included in both EAP-Request/AKA-Notification and EAP-Response/AKA- 2417 Notification. 2419 EAP AKA Authentication June 2003 2421 If the P bit of the notification code is set to one, the 2422 notification can only by used before the EAP/AKA-Challenge round in 2423 full authentication or the EAP/AKA-Reauthentication round in 2424 reauthentication. For these notifications, the AT_MAC attribute MUST 2425 NOT be included in either EAP-Request/AKA-Notification or EAP- 2426 Response/AKA-Notification. 2428 Some of the notification codes are authorization related and hence 2429 not usually considered as part of the responsibility of an EAP 2430 method. However, they are included as part of EAP/AKA because there 2431 are currently no other ways to convey this information to the user 2432 in a localizable way, and the information is potentially useful for 2433 the user. An EAP/AKA server implementation may decide never to send 2434 these EAP/AKA notifications. 2436 The format of the EAP-Request/AKA-Notification packet is shown 2437 below. 2439 0 1 2 3 2440 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 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 | Code | Identifier | Length | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 | Type | Subtype | Reserved | 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 |AT_NOTIFICATION| Length = 1 |F|P| Notification Code | 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | AT_MAC | Length = 5 | Reserved | 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 | | 2451 | | 2452 | MAC | 2453 | | 2454 | | 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2457 Code 2459 1 for Request 2461 Identifier 2463 See [5]. 2465 Length 2467 The length of the EAP packet. 2469 Type 2471 23 2473 EAP AKA Authentication June 2003 2475 Subtype 2477 12 2479 Reserved 2481 Set to zero when sending, ignored on reception. 2483 AT_NOTIFICATION 2485 The AT_NOTIFICATION attribute MUST be included. The value field 2486 of this attribute contains a two-byte notification code. The 2487 first and second bit (F and P) of the notification code are 2488 interpreted as described above. 2490 The following code values have been reserved. The descriptions 2491 below illustrate the semantics of the notifications. The client 2492 implementation MAY use different wordings when presenting the 2493 notifications to the user. The "requested service" depends on the 2494 environment where EAP/AKA is applied. 2496 1026 - User has been temporarily denied access to the requested 2497 service (Implies failure, used after the challenge round) 2499 1031 - User has not subscribed to the requested service (Implies 2500 failure, used after the challenge round) 2502 AT_MAC 2504 AT_MAC is included in cases described above. No message-specific 2505 data is included in the MAC calculation. See Section 7.1. 2507 The format of the EAP-Response/AKA-Notification packet is shown 2508 below. Because this packet is only an acknowledgement of EAP- 2509 Request/AKA-Notification, it does not contain any mandatory 2510 attributes. 2512 0 1 2 3 2513 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 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 | Code | Identifier | Length | 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 | Type | Subtype | Reserved | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 | AT_MAC | Length = 5 | Reserved | 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 | | 2522 | | 2523 | MAC | 2524 | | 2525 | | 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 EAP AKA Authentication June 2003 2530 Code 2532 2 for Response 2534 Identifier 2536 See [5]. 2538 Length 2540 The length of the EAP packet. 2542 Type 2544 23 2546 Subtype 2548 12 2550 Reserved 2552 Set to zero when sending, ignored on reception. 2554 AT_MAC 2556 AT_MAC is included in cases described above. No message-specific 2557 data is included in the MAC calculation. See Section 7.1. 2559 9. Error Cases and the Usage of EAP-Failure and EAP-Success 2561 9.1. Processing Erroneous Packets 2563 In general, if an EAP/AKA client or server implementation detects an 2564 error in a received EAP/AKA packet, the EAP/AKA implementation 2565 silently ignores the EAP packet, does not change its state and does 2566 not send any EAP messages to its peer. Examples of such errors, 2567 specified in detail elsewhere in this document, are an invalid 2568 AT_MAC value, a mandatory attribute is missing, illegal attributes 2569 included and an unrecognized non-skippable attribute. If no valid 2570 packets are received, the authentication exchange will eventually 2571 time out. 2573 If the EAP/AKA client receives an EAP/AKA Request of an unrecognized 2574 subtype, the EAP/AKA client MUST silently discard the EAP request. 2576 9.2. EAP-Failure 2578 As normally in EAP, the EAP server sends the EAP-Failure packet to 2579 the client when the authentication procedure fails on the EAP 2580 Server. In EAP/AKA, this may occur for example if the EAP server 2581 does not recognize the user identity, or if the EAP server is not 2583 EAP AKA Authentication June 2003 2585 able to obtain authentication vectors for the subscriber or the 2586 authentication exchange times out. 2588 The server can send EAP-Failure at any time in the EAP exchange. The 2589 client MUST process EAP-Failure. 2591 9.3. EAP-Success 2593 On full authentication, the server can only send EAP-Success after 2594 the EAP/AKA-Challenge round. The client MUST silently discard any 2595 EAP-Success packets if they are received before the client has 2596 successfully authenticated the server and sent the EAP-Response/AKA- 2597 Challenge packet. 2599 On re-authentication, EAP-Success can only be sent after the 2600 EAP/AKA-Reauthentication round. The client MUST silently discard any 2601 EAP-Success packets if they are received before the client has 2602 successfully authenticated the server and sent the EAP-Response/AKA- 2603 Reauthentication packet. 2605 If the client receives an EAP/AKA notification (section 8.9) that 2606 indicates failure, then the client MUST no longer accept the EAP- 2607 Success packet even if the server authentication was successfully 2608 completed. 2610 10. Key Derivation 2612 This section specifies how EAP AKA keying material is derived. 2614 On EAP AKA full authentication, a Master Key (MK) is derived from 2615 the underlying UMTS AKA values (IK and CK keys) and the Identity as 2616 follows. 2618 MK = SHA1(Identity|IK|CK) 2620 The hash function SHA1 is specified in [10]. In the formula above, 2621 the "|" character denotes concatenation. Identity denotes the user 2622 identity string without any terminating null characters. It is the 2623 identity from the AT_IDENTITY attribute from the last EAP- 2624 Response/AKA-Identity packet, or, if AT_IDENTITY was not used, the 2625 identity from the EAP-Response/Identity packet. 2627 The Master Key is fed into a Pseudo-Random number Function (PRF), 2628 which generates separate Transient EAP Keys (TEKs) for protecting 2629 EAP AKA packets, as well as a Master Session Key (MSK) for link 2630 layer security and an Extended Master Session Key (EMSK) for other 2631 purposes. On re-authentication, the same TEKs will be used for 2632 protecting EAP packets, but a new MSK and a new EMSK will be derived 2633 from the original MK and new values exchanged in the re- 2634 authentication. 2636 EAP AKA requires two TEKs for its own purposes, a message 2637 authentication key K_aut and an encryption key K_encr, to be used 2639 EAP AKA Authentication June 2003 2641 with the AT_MAC and AT_ENCR_DATA attributes. The same K_aut and 2642 K_encr keys are used in full authentication and subsequent re- 2643 authentications. 2645 Key derivation is based on the pseudo-random number generator 2646 specified in NIST Federal Information Processing Standards 2647 Publication 186-2 [14]. The pseudo-random number generator is 2648 specified in the change notice 1 (2001 October 5)of [14] (Algorithm 2649 1). As specified in the change notice (page 74), when Algorithm 1 is 2650 used as a general-purpose random number generator, the "mod q" term 2651 in step 3.2 is omitted. The function G used in the algorithm is 2652 constructed via Secure Hash Standard as specified in Appendix 3.3 of 2653 the standard. For convenience, the pseudo-random number algorithm 2654 with the correct modification is cited in Annex A. 2656 160-bit XKEY and XVAL values are used, so b = 160. On full 2657 authentication, the Master Key is used as the initial secret seed 2658 value XKEY 2660 The optional user input values (XSEED_j) in Step 3.1 are set to 2661 zero. 2663 The resulting 320-bit random numbers x_0, x_1, ..., x_m-1 are 2664 concatenated and partitioned into suitable-sized chunks and used as 2665 keys in the following order: K_encr (128 bits), K_aut (128 bits), 2666 Master Session Key (64 bytes), Extended Master Session Key (64 2667 bytes). 2669 On re-authentication, the same pseudo-random number generator can be 2670 used to generate a new Master Session Key and a new Extended Master 2671 Session Key. The seed value XKEY' is calculated as follows: 2673 XKEY' = SHA1(Identity|counter|NONCE_S|MK) 2675 In the formula above, the Identity denotes the re-authentication 2676 user identity, without any terminating null characters, from the 2677 AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, 2678 if EAP-Response/AKA-Identity was not used on re-authentication, the 2679 identity string from the EAP-Response/Identity packet. The counter 2680 denotes the counter value from AT_COUNTER attribute used in the EAP- 2681 Response/AKA-Reauthentication packet. The counter is used in network 2682 byte order. NONCE_S denotes the 16-byte NONCE_S value from the 2683 AT_NONCE_S attribute used in the EAP-Request/AKA-Reauthentication 2684 packet. The MK is the Master Key from the preceding full 2685 authentication. The pseudo-random number generator is run with the 2686 new seed value XKEY', and the resulting 320-bit random numbers x_0, 2687 x_1, ..., x_m-1 are concatenated and partitioned into 64-byte chunks 2688 and used as the new Master Session Key and the new Extended Master 2689 Session Key. 2691 The first 32 bytes of the MSK can be used as the Pairwise Master Key 2692 (PMK) for IEEE 802.11i. 2694 EAP AKA Authentication June 2003 2696 When the RADIUS attributes specified in [16] are used to transport 2697 keying material, then the first 32 bytes of the MSK correspond to 2698 MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE-SEND-KEY. In 2699 this case, only 64 bytes of keying material are used. 2701 11. IANA and Protocol Numbering Considerations 2703 The realm name "owlan.org" has been reserved for NAI realm names 2704 generated from the IMSI. 2706 IANA has assigned the number 23 for EAP AKA authentication. 2708 EAP AKA messages include a Subtype field. The following Subtypes are 2709 specified: 2711 AKA-Challenge...................................1 2712 AKA-Authentication-Reject.......................2 2713 AKA-Synchronization-Failure.....................4 2714 AKA-Identity....................................5 2715 AKA-Notification...............................12 2716 AKA-Reauthentication...........................13 2718 The Subtype-specific data is composed of attributes, which have 2719 attribute type numbers. The following attribute types are specified: 2721 AT_RAND.........................................1 2722 AT_AUTN.........................................2 2723 AT_RES..........................................3 2724 AT_AUTS.........................................4 2725 AT_PADDING......................................6 2726 AT_PERMANENT_ID_REQ............................10 2727 AT_MAC.........................................11 2728 AT_ANY_ID_REQ..................................13 2729 AT_IDENTITY....................................14 2730 AT_FULLAUTH_ID_REQ.............................17 2731 AT_COUNTER.....................................19 2732 AT_COUNTER_TOO_SMALL...........................20 2733 AT_NONCE_S.....................................21 2735 AT_IV.........................................129 2736 AT_ENCR_DATA..................................130 2737 AT_NEXT_PSEUDONYM.............................132 2738 AT_NEXT_REAUTH_ID.............................133 2739 AT_CHECKCODE..................................134 2741 All requests for value assignment from the various number spaces 2742 described in this document require proper documentation, according 2743 to the "Specification Required" policy described in [17]. Requests 2744 must be specified in sufficient detail so that interoperability 2745 between independent implementations is possible. Possible forms of 2746 documentation include, but are not limited to, RFCs, the products of 2748 EAP AKA Authentication June 2003 2750 another standards body (e.g. 3GPP), or permanently and readily 2751 available vendor design notes. 2753 12. Security Considerations 2755 The revised EAP base protocol [18] highlights several attacks that 2756 are possible against the EAP protocol. This section discusses the 2757 claimed security properties of EAP AKA as well as vulnerabilities 2758 and security recommendations. 2760 12.1. Identity Protection 2762 EAP/AKA includes optional Identity privacy support that protects the 2763 privacy of the subscriber identity against passive eavesdropping. 2764 The mechanism cannot be used on the first connection with a given 2765 server, when the IMSI will have to be sent in the clear. The 2766 terminal SHOULD store the pseudonym in a non-volatile memory so that 2767 it can be maintained across reboots. An active attacker that 2768 impersonates the network may use the AT_PERMANENT_ID_REQ attribute 2769 (Section 4.3) to learn the subscriber's IMSI. However, as discussed 2770 in Section 4.3, the terminal can refuse to send the cleartext IMSI 2771 if it believes that the network should be able to recognize the 2772 pseudonym. 2774 If the client and server cannot guarantee that the pseudonym will be 2775 maintained reliably and Identity privacy is required then additional 2776 protection from an external security mechanism such as Protected 2777 Extensible Authentication Protocol (PEAP) [19] may be used. The 2778 benefits and the security considerations of using an external 2779 security mechanism with EAP/AKA are beyond the scope of this 2780 document. 2782 12.2. Mutual Authentication 2784 EAP/AKA provides mutual authentication via the UMTS AKA mechanisms. 2786 12.3. Key Derivation 2788 EAP/AKA supports key derivation with 128-bit effective key strength. 2789 The key hierarchy is specified in Section 10. 2791 The Transient EAP Keys used to protect EAP AKA packets (K_encr, 2792 K_aut) and the Master Session Keys are cryptographically separate. 2793 An attacker cannot derive any non-trivial information from K_encr or 2794 K_aut based on the Master Session Key or vice versa. An attacker 2795 also cannot calculate the pre-shared secret from the UMTS AKA IK, 2796 UMTS AKA CK, EAP AKA K_encr, EAP AKA K_aut or from the Master 2797 Session Key. 2799 12.4. Brute-Force and Dictionary Attacks 2801 The effective strength of EAP/AKA values is 128 bits, and there are 2802 no known computationally feasible brute-force attacks. Because UMTS 2804 EAP AKA Authentication June 2003 2806 AKA is not a password protocol (the pre-shared secret must not be a 2807 weak password), EAP/AKA is not vulnerable to dictionary attacks. 2809 12.5. Integrity Protection, Replay Protection and Confidentiality 2811 AT_MAC, AT_IV and AT_ENCR_DATA attributes are used to provide 2812 integrity, replay and confidentiality protection for EAP/AKA 2813 Requests and Responses. Integrity protection includes the EAP 2814 header. Integrity protection (AT_MAC) is based on a keyed message 2815 authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is 2816 based on a block cipher. 2818 Because keys are not available in the beginning of the EAP methods, 2819 the AT_MAC attribute cannot be used for protecting EAP/AKA-Identity 2820 messages. However, the AT_CHECKCODE attribute can optionally be used 2821 to protect the integrity of the EAP/AKA-Identity roundtrip. 2823 On full authentication, replay protection is provided by the 2824 underlying UMTS AKA scheme, which makes use of the RAND and AUTN 2825 values. On re-authentication, a counter and a server nonce is used 2826 to provide replay protection. 2827 The contents of the EAP-Response/Identity packet are implicitly 2828 integrity protected by including them in key derivation. 2830 Because EAP/AKA is not a tunneling method, EAP Notification, EAP 2831 Success or EAP Failure packets are not confidential, integrity 2832 protected or replay protected. On physically insecure networks, this 2833 may enable an attacker to mount denial of service attacks by sending 2834 false EAP Notification, EAP Success or EAP Failure packets. However, 2835 the attacker cannot force the peers to believe successful 2836 authentication has occurred when mutual authentication failed or has 2837 not happened yet. 2839 An eavesdropper will see the EAP Notification, EAP Success and EAP 2840 Failure packets sent in the clear. With EAP AKA, confidential 2841 information MUST NOT be transmitted in EAP Notification packets. 2843 12.6. Negotiation Attacks 2845 EAP/AKA does not protect the EAP-Response/Nak packet. Because 2846 EAP/AKA does not protect the EAP method negotiation, EAP method 2847 downgrading attacks may be possible, especially if the user uses the 2848 same identity with EAP/AKA and other EAP methods. 2850 As described in Section 6, EAP/AKA allows the protocol to be 2851 extended by defining new attribute types. When defining such 2852 attributes, it should be noted that any extra attributes included in 2853 EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are 2854 not included in the MACs later on, and thus some other precautions 2855 must be taken to avoid modifications to them. 2857 EAP/AKA does not support ciphersuite negotiation or EAP/AKA protocol 2858 version negotiation. 2860 EAP AKA Authentication June 2003 2862 12.7. Fast Reconnect 2864 EAP/AKA includes an optional re-authentication ("fast reconnect") 2865 procedure, as recommended in [18] for EAP types that are intended 2866 for physically insecure networks. 2868 12.8. Acknowledged Result Indications 2870 EAP/AKA does not provide acknowledged or integrity protected Success 2871 or Failure indications. 2873 If an EAP Success or an EAP Failure packet is lost when using 2874 EAP/AKA over an unreliable medium, and if the protocol over which 2875 EAP/AKA is transported does not address the possible loss of Success 2876 or Failure, then the peer and authenticator may end up having a 2877 different interpretation of the state of the authentication 2878 conversation. 2880 On physically insecure networks, an attacker may mount denial of 2881 service attacks by sending false EAP Success or EAP Failure 2882 indications. However, the attacker cannot force the client or the 2883 authenticator to believe successful authentication has occurred when 2884 mutual authentication failed or has not happened yet. 2886 12.9. Man-in-the-middle Attacks 2888 In order to avoid man-in-the-middle attacks and session hijacking, 2889 user data SHOULD be integrity protected on physically insecure 2890 networks. The EAP/AKA Master Session Key or keys derived from it MAY 2891 be used as the integrity protection keys, or, if an external 2892 security mechanism such as PEAP is used, then the link integrity 2893 protection keys MAY be derived by the external security mechanism. 2895 There are man-in-the-middle attacks associated with the use of any 2896 EAP method within a tunneled protocol such as PEAP, or within a 2897 sequence of EAP methods followed by each other. This specification 2898 does not address these attacks. If EAP/AKA is used with a tunneling 2899 protocol or as part of a sequence of methods, there should be 2900 cryptographic binding provided between the protocols and EAP/AKA to 2901 prevent man-in-the-middle attacks through rogue authenticators being 2902 able to setup one-way authenticated tunnels. EAP/AKA Master Session 2903 Key MAY be used to provide the cryptographic binding. However the 2904 mechanism how the binding is provided depends on the tunneling or 2905 sequencing protocol, and it is beyond the scope of this document. 2907 12.10. Generating Random Numbers 2909 An EAP/AKA implementation SHOULD use a good source of randomness to 2910 generate the random numbers required in the protocol. Please see 2911 [20] for more information on generating random numbers for security 2912 applications. 2914 13. Security Claims 2916 EAP AKA Authentication June 2003 2918 This section provides the security claims required by [18]. 2920 [a] Intended use. EAP AKA is intended for use over both physically 2921 insecure networks and physically or otherwise secure networks. 2922 Applicable media include but are not limited to PPP, IEEE 802 wired 2923 networks and IEEE 802.11. 2925 [b] Mechanism. EAP AKA is based on the UMTS AKA mechanism, which is 2926 an authentication and key agreement mechanism based on a symmetric 2927 128-bit pre-shared secret. 2929 [c] Security claims. The security properties of the method are 2930 discussed in Section 12. 2932 [d] Key strength. EAP/AKA supports key derivation with 128-bit 2933 effective key strength. 2935 [e] Description of key hierarchy. Please see Section 10. 2937 [f] Indication of vulnerabilities. Vulnerabilities are discussed in 2938 Section 12. 2940 14. Intellectual Property Right Notices 2942 On IPR related issues, Nokia and Ericsson refer to the their 2943 respective statements on patent licensing. Please see 2944 http://www.ietf.org/ietf/IPR/NOKIA and 2945 http://www.ietf.org/ietf/IPR/ERICSSON-General 2947 Acknowledgements and Contributions 2949 The authors wish to thank Rolf Blom of Ericsson, Bernard Aboba of 2950 Microsoft, Arne Norefors of Ericsson, N.Asokan of Nokia, Valtteri 2951 Niemi of Nokia, Kaisa Nyberg of Nokia, Jukka-Pekka Honkanen of 2952 Nokia, Pasi Eronen of Nokia, Olivier Paridaens of Alcatel and Ilkka 2953 Uusitalo of Ericsson for interesting discussions in this problem 2954 space. 2956 The attribute format is based on the extension format of Mobile IPv4 2957 [21]. 2959 Authors' Addresses 2961 Jari Arkko 2962 Ericsson 2963 02420 Jorvas Phone: +358 40 5079256 2964 Finland Email: jari.arkko@ericsson.com 2966 Henry Haverinen 2967 Nokia Mobile Phones 2968 P.O. Box 88 2969 33721 Tampere Phone: +358 50 594 4899 2970 Finland E-mail: henry.haverinen@nokia.com 2972 EAP AKA Authentication June 2003 2974 Annex A. Pseudo-Random Number Generator 2976 The "|" character denotes concatenation, and "^" denotes involution. 2978 Step 1: Choose a new, secret value for the seed-key, XKEY 2980 Step 2: In hexadecimal notation let 2981 t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 2982 This is the initial value for H0|H1|H2|H3|H4 2983 in the FIPS SHS [10] 2985 Step 3: For j = 0 to m - 1 do 2986 3.1 XSEED_j = optional user input 2987 3.2 For i = 0 to 1 do 2988 a. XVAL = (XKEY + XSEED_j) mod 2^b 2989 b. w_i = G(t, XVAL) 2990 c. XKEY = (1 + XKEY + w_i) mod 2^b 2991 3.3 x_j = w_0|w_1 2993 EAP AKA Authentication June 2003 2995 References 2997 [1] 3GPP Technical Specification 3GPP TS 33.102 V5.1.0: "Technical 2998 Specification Group Services and System Aspects; 3G Security; 2999 Security Architecture (Release 5)", 3rd Generation Partnership 3000 Project, December 2002. (NORMATIVE) 3002 [2] IEEE P802.1X/D11, "Standards for Local Area and Metropolitan 3003 Area Networks: Standard for Port Based Network Access 3004 Control", March 2001. (INFORMATIVE) 3006 [3] IEEE Draft 802.11eS/D1, "Draft Supplement to STANDARD FOR 3007 Telecommunications and Information Exchange between Systems - 3008 LAN/MAN Specific Requirements - Part 11: Wireless Medium 3009 Access Control (MAC) and physical layer (PHY) specifications: 3010 Specification for Enhanced Security", March 2001. 3011 (INFORMATIVE) 3013 [4] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 3014 2486, January 1999. (NORMATIVE) 3016 [5] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication 3017 Protocol (EAP)", RFC 2284, March 1998. (NORMATIVE) 3019 [6] S. Bradner, "Key words for use in RFCs to indicate Requirement 3020 Levels", RFC 2119, March 1997. (NORMATIVE) 3022 [7] 3GPP Technical Specification 3GPP TS 23.003 V5.5.1: "3rd 3023 Generation Parnership Project; Technical Specification Group 3024 Core Network; Numbering, addressing and identification 3025 (Release 5)", 3rd Generation Parnership Project, January 2003 3026 (NORMATIVE) 3028 [8] Draft 3GPP Technical Specification 3GPP TS 23.234 V 1.4.0: 3029 "Technical Specification Group Services and System Aspects; 3030 3GPP system to Wireless Local Area Network (WLAN) 3031 Interworking; System Description", 3rd Generation Partnership 3032 Project, work in progress, January 2003. (INFORMATIVE) 3034 [9] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for 3035 Message Authentication", RFC2104, February 1997. (NORMATIVE) 3037 [10] Federal Information Processing Standard (FIPS) Publication 3038 180-1, "Secure Hash Standard," National Institute of Standards 3039 and Technology, U.S. Department of Commerce, April 17, 1995. 3040 (NORMATIVE) 3042 [11] Federal Information Processing Standard (FIPS) draft standard, 3043 "Advanced Encryption Standard (AES)", 3045 EAP AKA Authentication June 2003 3047 http://csrc.nist.gov/publications/drafts/dfips-AES.pdf, 3048 September 2001. (NORMATIVE) 3050 [12] US National Bureau of Standards, "DES Modes of Operation", 3051 Federal Information Processing Standard (FIPS) Publication 81, 3052 December 1980. (NORMATIVE) 3054 [13] 3GPP Technical Specification 3GPP TS 33.105 4.1.0: "Technical 3055 Specification Group Services and System Aspects; 3G Security; 3056 Cryptographic Algorithm Requirements (Release 4)", 3rd 3057 Generation Partnership Project, June 2001 (NORMATIVE) 3059 [14] Federal Information Processing Standards (FIPS) Publication 3060 186-2 (with change notice), "Digital Signature Standard 3061 (DSS)", National Institute of Standards and Technology, 3062 January 27, 2000, (NORMATIVE) 3063 Available on-line at: 3064 http://csrc.nist.gov/publications/fips/fips186-2/ 3065 fips186-2-change1.pdf 3067 [15] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol", RFC 3068 2716, October 1999 (INFORMATIVE) 3070 [16] G. Zorn, "Microsoft Vendor-specific RADIUS Attributes", RFC 3071 2548, March 1999 (INFORMATIVE) 3073 [17] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 3074 Considerations Section in RFCs", RFC 2434, October 1998. 3075 (NORMATIVE) 3077 [18] L. Blunk, J. Vollbrecht, B. Aboba, "Extensible Authentication 3078 Protocol (EAP)", draft-ietf-pppext-rfc2284bis-07.txt, work-in- 3079 progress, October 2002. (NORMATIVE) 3081 [19] H. Andersson, S. Josefsson, G. Zorn, D. Simon, A. Palekar, 3082 "Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap- 3083 tls-eap-05.txt, work-in-progress, September 2002. 3084 (IMFORMATIVE) 3086 [20] D. Eastlake, 3rd, S. Crocker, J. Schiller, "Randomness 3087 Recommendations for Security", RFC 1750 (Informational), 3088 December 1994. (INFORMATIVE) 3090 [21] C. Perkins (editor), "IP Mobility Support", RFC 3344, August 3091 2002. (INFORMATIVE)