idnits 2.17.00 (12 Aug 2021) /tmp/idnits31987/draft-arkko-pppext-eap-aka-11.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 58 longer pages, the longest (page 4) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 61 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 546 has weird spacing: '...tor and help ...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2279' is mentioned on line 2604, but not defined ** Obsolete undefined reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) == Outdated reference: draft-ietf-eap-rfc2284bis has been published as RFC 3748 ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBC' -- Possible downref: Non-RFC (?) normative reference: ref. 'PRF' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-05 -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) == Outdated reference: draft-haverinen-pppext-eap-sim has been published as RFC 4186 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet Draft Ericsson 4 Document: draft-arkko-pppext-eap-aka-11.txt H. Haverinen 5 Expires: 27 April, 2004 Nokia 6 27 October, 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 Comments should be submitted to the eap@frascone.com mailing list. 32 Abstract 34 This document specifies an Extensible Authentication Protocol (EAP) 35 mechanism for authentication and session key distribution using the 36 Universal Mobile Telecommunications System (UMTS) Authentication and 37 Key Agreement (AKA) mechanism. UMTS AKA is based on symmetric keys, 38 and runs typically in a UMTS Subscriber Identity Module, a smart 39 card like device. 41 EAP AKA includes optional identity privacy support and an optional 42 re-authentication procedure. 44 Table of Contents 46 Status of this Memo................................................1 47 Abstract...........................................................1 48 1. Introduction and Motivation.....................................3 49 2. Terms and Conventions Used in This Document.....................4 50 3. Protocol Overview...............................................6 51 4. Operation......................................................11 53 EAP AKA Authentication 27 October, 2003 55 4.1. Identity Management..........................................11 56 4.2. Re-authentication............................................25 57 4.3. EAP/AKA Notifications........................................31 58 4.4. Error Cases..................................................32 59 4.5. Key Generation...............................................34 60 5. Message Format and Protocol Extensibility......................35 61 5.1. Message Format...............................................35 62 5.2. Protocol Extensibility.......................................37 63 6. Messages.......................................................37 64 6.1. EAP-Request/AKA-Identity.....................................37 65 6.2. EAP-Response/AKA-Identity....................................38 66 6.3. EAP-Request/AKA-Challenge....................................38 67 6.4. EAP-Response/AKA-Challenge...................................39 68 6.5. EAP-Response/AKA-Authentication-Reject.......................39 69 6.6. EAP-Response/AKA-Synchronization-Failure.....................39 70 6.7. EAP-Request/AKA-Reauthentication.............................39 71 6.8. EAP-Response/AKA-Reauthentication............................40 72 6.9. EAP-Response/AKA-Client-Error................................40 73 6.10. EAP-Request/AKA-Notification................................40 74 6.11. EAP-Response/AKA-Notification...............................41 75 7. Attributes.....................................................41 76 7.1. Table of Attributes..........................................41 77 7.2. AT_MAC.......................................................42 78 7.3. AT_IV, AT_ENCR_DATA and AT_PADDING...........................43 79 7.4. AT_CHECKCODE.................................................45 80 7.5. AT_PERMANENT_ID_REQ..........................................47 81 7.6. AT_ANY_ID_REQ................................................47 82 7.7. AT_FULLAUTH_ID_REQ...........................................47 83 7.8. AT_IDENTITY..................................................48 84 7.9. AT_RAND......................................................48 85 7.10. AT_AUTN.....................................................49 86 7.11. AT_RES......................................................49 87 7.12. AT_AUTS.....................................................49 88 7.13. AT_NEXT_PSEUDONYM...........................................50 89 7.14. AT_NEXT_REAUTH_ID...........................................50 90 7.15. AT_COUNTER..................................................51 91 7.16. AT_COUNTER_TOO_SMALL........................................51 92 7.17. AT_NONCE_S..................................................51 93 7.18. AT_NOTIFICATION.............................................52 94 7.19. AT_CLIENT_ERROR_CODE........................................53 95 8. IANA and Protocol Numbering Considerations.....................53 96 9. Security Considerations........................................54 97 9.1. Identity Protection..........................................55 98 9.2. Mutual Authentication........................................55 99 9.3. Key Derivation...............................................55 100 9.4. Brute-Force and Dictionary Attacks...........................55 101 9.5. Integrity Protection, Replay Protection and Confidentiality..55 103 EAP AKA Authentication 27 October, 2003 105 9.6. Negotiation Attacks..........................................56 106 9.7. Fast Reconnect...............................................56 107 9.8. Acknowledged Result Indications..............................56 108 9.9. Man-in-the-middle Attacks....................................57 109 9.10. Generating Random Numbers...................................57 110 10. Security Claims...............................................57 111 11. Intellectual Property Right Notices...........................58 112 Acknowledgements and Contributions................................58 113 Authors' Addresses................................................58 114 Annex A. Pseudo-Random Number Generator...........................59 116 1. Introduction and Motivation 118 This document specifies an Extensible Authentication Protocol (EAP) 119 mechanism for authentication and session key distribution using the 120 UMTS AKA authentication mechanism [TS 33.102]. UMTS is a global 121 third generation mobile network standard. 123 AKA is based on challenge-response mechanisms and symmetric 124 cryptography. AKA typically runs in a UMTS Subscriber Identity 125 Module (USIM). Compared to the GSM mechanism, UMTS AKA provides 126 substantially longer key lengths and mutual authentication. 128 The introduction of AKA inside EAP allows several new applications. 129 These include the following: 131 - The use of the AKA also as a secure PPP authentication method in 132 devices that already contain an USIM. 134 - The use of the third generation mobile network authentication 135 infrastructure in the context of wireless LANs 137 - Relying on AKA and the existing infrastructure in a seamless way 138 with any other technology that can use EAP. 140 AKA works in the following manner: 142 - The USIM and the home environment have agreed on a secret key 143 beforehand. 145 - The actual authentication process starts by having the home 146 environment produce an authentication vector, based on the secret 147 key and a sequence number. The authentication vector contains a 148 random part RAND, an authenticator part AUTN used for 149 authenticating the network to the USIM, an expected result part 150 XRES, a session key for integrity check IK, and a session key for 151 encryption CK. 153 - The RAND and the AUTN are delivered to the USIM. 155 - The USIM verifies the AUTN, again based on the secret key and the 156 sequence number. If this process is successful (the AUTN is valid 158 EAP AKA Authentication 27 October, 2003 160 and the sequence number used to generate AUTN is within the 161 correct range), the USIM produces an authentication result, RES 162 and sends this to the home environment. 164 - The home environment verifies the correct result from the USIM. If 165 the result is correct, IK and CK can be used to protect further 166 communications between the USIM and the home environment. 168 When verifying AUTN, the USIM may detect that the sequence number 169 the network uses is not within the correct range. In this case, the 170 USIM calculates a sequence number synchronization parameter AUTS and 171 sends it to the network. AKA authentication may then be retried with 172 a new authentication vector generated using the synchronized 173 sequence number. 175 For a specification of the AKA mechanisms and how the cryptographic 176 values AUTN, RES, IK, CK and AUTS are calculated, see [TS 33.102]. 178 In EAP AKA, the EAP server node obtains the authentication vectors, 179 compares RES and XRES, and uses CK and IK in key derivation. 181 In the third generation mobile networks, AKA is used both for radio 182 network authentication and IP multimedia service authentication 183 purposes. Different user identities and formats are used for these; 184 the radio network uses the International Mobile Subscriber 185 Identifier (IMSI), whereas the IP multimedia service uses the 186 Network Access Identifier (NAI) [RFC 2486]. 188 2. Terms and Conventions Used in This Document 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC 2119]. 194 The terms and abbreviations "authenticator", "backend authentication 195 server", "EAP server", "Silently Discard", "Master Session Key 196 (MSK)", and "Extended Master Session Key (EMSK)" in this document 197 are to be interpreted as described in [EAP]. 199 This document frequently uses the following terms and abbreviations: 201 AAA protocol 203 Authentication, Authorization and Accounting protocol 205 AKA 207 Authentication and Key Agreement 209 EAP AKA Authentication 27 October, 2003 211 AuC 213 Authentication Centre. The mobile network element that can 214 authenticate subscribers either in GSM or in UMTS networks. 216 EAP 218 Extensible Authentication Protocol [EAP]. 220 GSM 222 Global System for Mobile communications. 224 NAI 226 Network Access Identifier [RFC 2486]. 228 AUTN 230 Authentication value generated by the AuC which together with the 231 RAND authenticates the server to the peer, 128 bits [TS 33.102]. 233 AUTS 235 A value generated by the peer upon experiencing a synchronization 236 failure, 112 bits. 238 Permanent Identity 240 The permanent identity of the peer, including an NAI realm 241 portion in environments where a realm is used. The permanent 242 identity is usually based on the IMSI. Used on full 243 authentication only. 245 Permanent Username 247 The username portion of permanent identity, ie. not including any 248 realm portions. 250 Pseudonym Identity 252 A pseudonym identity of the peer, including an NAI realm portion 253 in environments where a real is used. Used on full authentication 254 only. 256 Pseudonym Username 258 The username portion of pseudonym identity, ie. not including any 259 realm portions. 261 EAP AKA Authentication 27 October, 2003 263 Re-authentication Identity 265 A re-authentication identity of the peer, including an NAI realm 266 portion in environments where a real is used. Used on re- 267 authentication only. 269 Re-authentication Username 271 The username portion of re-authentication identity, ie. not 272 including any realm portions. 274 RAND 276 Random number generated by the AuC, 128 bits [TS 33.102]. 278 RES 280 Authentication result from the peer, which together with the RAND 281 authenticates the peer to the server, 128 bits [TS 33.102]. 283 SQN 285 Sequence number used in the authentication process, 48 bits [TS 286 33.102]. 288 SIM 290 Subscriber Identity Module. The SIM is an application 291 traditionally resident on smart cards distributed by GSM 292 operators. 294 SRES 296 The authentication result parameter in GSM, corresponds to the 297 RES parameter in UMTS aka, 32 bits. 299 USIM 301 UMTS Subscriber Identity Module. USIM is an application that is 302 resident e.g. on smart cards distributed by UMTS operators. 304 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 305 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 306 this document are to be interpreted as described in [RFC 2119] 308 3. Protocol Overview 310 The message flow below shows the basic successful full 311 authentication exchange in EAP AKA. At the minimum, EAP AKA uses two 312 roundtrips to authorize the user and generate session keys. As in 313 other EAP schemes, an identity request/response message pair is 314 usually exchanged first. On full authentication, the peer's identity 315 response includes either the user's International Mobile Subscriber 317 EAP AKA Authentication 27 October, 2003 319 Identity (IMSI), or a temporary identity (pseudonym) if identity 320 privacy is in effect, as specified in Section 4.1. (As specified in 321 [EAP], the initial identity request is not required, and MAY be 322 bypassed in cases where the network can presume the identity, such 323 as when using leased lines, dedicated dial-ups, etc. Please see also 324 Section 4.1.2 for specification how to obtain the identity via EAP 325 AKA messages.) 327 Next, the EAP server starts the actual AKA protocol by sending an 328 EAP-Request/AKA-Challenge message. EAP AKA packets encapsulate 329 parameters in attributes, encoded in a Type, Length, Value format. 330 The packet format and the use of attributes are specified in Section 331 5. The EAP-Request/AKA-Challenge message contains a random number 332 (AT_RAND) and a network authentication token (AT_AUTN), and a 333 message authentication code AT_MAC. The EAP-Request/AKA-Challenge 334 message MAY optionally contain encrypted data, which is used for 335 identity privacy and re-authentication support, as described in 336 Section 4.1. The AT_MAC attribute contains a message authentication 337 code covering the EAP packet. The encrypted data is not shown in the 338 figures of this section. 340 The peer runs the AKA algorithm (typically using a USIM) and 341 verifies the AUTN. If this is successful, the peer is talking to a 342 legitimate EAP server and proceeds to send the EAP-Response/AKA- 343 Challenge. This message contains a result parameter that allows the 344 EAP server in turn to authenticate the peer, and the AT_MAC 345 attribute to integrity protect the EAP message. 347 EAP AKA Authentication 27 October, 2003 349 Peer Authenticator 350 | | 351 | EAP-Request/Identity | 352 |<------------------------------------------------------| 353 | | 354 | EAP-Response/Identity | 355 | (Includes user's NAI) | 356 |------------------------------------------------------>| 357 | | 358 | +------------------------------+ 359 | | Server runs UMTS algorithms, | 360 | | generates RAND and AUTN. | 361 | +------------------------------+ 362 | | 363 | EAP-Request/AKA-Challenge | 364 | (AT_RAND, AT_AUTN, AT_MAC) | 365 |<------------------------------------------------------| 366 | | 367 +-------------------------------------+ | 368 | Peer runs UMTS algorithms on USIM, | | 369 | verifies AUTN and MAC, derives RES | | 370 | and session key | | 371 +-------------------------------------+ | 372 | | 373 | EAP-Response/AKA-Challenge | 374 | (AT_RES, AT_MAC) | 375 |------------------------------------------------------>| 376 | | 377 | +--------------------------------+ 378 | | Server checks the given RES, | 379 | | and MAC and finds them correct.| 380 | +--------------------------------+ 381 | | 382 | EAP-Success | 383 |<------------------------------------------------------| 385 The second message flow shows how the EAP server rejects the Peer 386 due to a failed authentication. The same flow is also used in the 387 GSM compatible mode, except that the AT_AUTN attribute and AT_MAC 388 attribute are not used in the messages. 390 EAP AKA Authentication 27 October, 2003 392 Peer Authenticator 393 | | 394 | EAP-Request/Identity | 395 |<------------------------------------------------------| 396 | | 397 | EAP-Response/Identity | 398 | (Includes user's NAI) | 399 |------------------------------------------------------>| 400 | | 401 | +------------------------------+ 402 | | Server runs UMTS algorithms, | 403 | | generates RAND and AUTN. | 404 | +------------------------------+ 405 | | 406 | EAP-Request/AKA-Challenge | 407 | (AT_RAND, AT_AUTN, AT_MAC) | 408 |<------------------------------------------------------| 409 | | 410 +-------------------------------------+ | 411 | Peer runs UMTS algorithms on USIM, | | 412 | possibly verifies AUTN, and sends an| | 413 | invalid response | | 414 +-------------------------------------+ | 415 | | 416 | EAP-Response/AKA-Challenge | 417 | (AT_RES, AT_MAC) | 418 |------------------------------------------------------>| 419 | | 420 | +------------------------------------------+ 421 | | Server checks the given RES and the MAC, | 422 | | and finds one of them incorrct. | 423 | +------------------------------------------+ 424 | | 425 | EAP-Failure | 426 |<------------------------------------------------------| 428 The next message flow shows the peer rejecting the AUTN of the EAP 429 server. 431 The peer sends an explicit error message (EAP-Response/AKA- 432 Authentication-Reject) to the EAP server, as usual in AKA when AUTN 433 is incorrect. This allows the EAP server to produce the same error 434 statistics as AKA in general produces in UMTS. 436 EAP AKA Authentication 27 October, 2003 438 Peer Authenticator 439 | | 440 | EAP-Request/Identity | 441 |<------------------------------------------------------| 442 | | 443 | EAP-Response/Identity | 444 | (Includes user's NAI) | 445 |------------------------------------------------------>| 446 | | 447 | +------------------------------+ 448 | | Server runs UMTS algorithms, | 449 | | generates RAND and a bad AUTN| 450 | +------------------------------+ 451 | | 452 | EAP-Request/AKA-Challenge | 453 | (AT_RAND, AT_AUTN, AT_MAC) | 454 |<------------------------------------------------------| 455 | | 456 +-------------------------------------+ | 457 | Peer runs UMTS algorithms on USIM | | 458 | and discovers AUTN that can not be | | 459 | verified | | 460 +-------------------------------------+ | 461 | | 462 | EAP-Response/AKA-Authentication-Reject | 463 |------------------------------------------------------>| 464 | | 465 | | 466 | EAP-Failure | 467 |<------------------------------------------------------| 469 The AKA uses shared secrets between the Peer and the Peer's home 470 operator together with a sequence number to actually perform an 471 authentication. In certain circumstances it is possible for the 472 sequence numbers to get out of sequence. Here's what happens then: 474 EAP AKA Authentication 27 October, 2003 476 Peer Authenticator 477 | | 478 | EAP-Request/Identity | 479 |<------------------------------------------------------| 480 | | 481 | EAP-Response/Identity | 482 | (Includes user's NAI) | 483 |------------------------------------------------------>| 484 | | 485 | +------------------------------+ 486 | | Server runs UMTS algorithms, | 487 | | generates RAND and AUTN. | 488 | +------------------------------+ 489 | | 490 | EAP-Request/AKA-Challenge | 491 | (AT_RAND, AT_AUTN, AT_MAC) | 492 |<------------------------------------------------------| 493 | | 494 +-------------------------------------+ | 495 | Peer runs UMTS algorithms on USIM | | 496 | and discovers AUTN that contains an | | 497 | inappropriate sequence number | | 498 +-------------------------------------+ | 499 | | 500 | EAP-Response/AKA-Synchronization-Failure | 501 | (AT_AUTS) | 502 |------------------------------------------------------>| 503 | | 504 | +---------------------------+ 505 | | Perform resynchronization | 506 | | Using AUTS and | 507 | | the sent RAND | 508 | +---------------------------+ 509 | | 511 After the resynchronization process has taken place in the server 512 and AAA side, the process continues by the server side sending a new 513 EAP-Request/AKA-Challenge message. 515 In addition to the full authentication scenarios described above, 516 EAP AKA includes a re-authentication procedure, which is specified 517 in Section 4.2. Re-authentication is based on keys derived on full 518 authentication. If the peer has maintained state information for re- 519 authentication and wants to use re-authentication, then the peer 520 indicates this by using a specific re-authentication identity 521 instead of the permanent identity or a pseudonym identity. The re- 522 authentication procedure is described in Section 4.2. 524 4. Operation 526 4.1. Identity Management 528 4.1.1. Format, Generation and Usage of Peer Identities 530 EAP AKA Authentication 27 October, 2003 532 General 534 In the beginning of EAP authentication, the Authenticator or the EAP 535 server usually issues the EAP-Request/Identity packet to the peer. 536 The peer responds with EAP-Response/Identity, which contains the 537 user's identity. The formats of these packets are specified in 538 [EAP]. 540 UMTS subscribers are identified with the International Mobile 541 Subscriber Identity (IMSI) [TS 23.003]. The IMSI is composed of a 542 three digit Mobile Country Code (MCC), a two or three digit Mobile 543 Network Code (MNC) and a not more than 10 digit Mobile Subscriber 544 Identification Number (MSIN). In other words, the IMSI is a string 545 of not more than 15 digits. MCC and MNC uniquely identify the GSM 546 operator and help identify the AuC from which the authentication 547 vectors need to be retrieved for this subscriber. 549 Internet AAA protocols identify users with the Network Access 550 Identifier (NAI) [RFC 2486]. When used in a roaming environment, the 551 NAI is composed of a username and a realm, separated with "@" 552 (username@realm). The username portion identifies the subscriber 553 within the realm. 555 This section specifies the peer identity format used in EAP/AKA. In 556 this document, the term identity or peer identity refers to the 557 whole identity string that is used to identify the peer. The peer 558 identity may include a realm portion. "Username" refers to the 559 portion of the peer identity that identifies the user, i.e. the 560 username does not include the realm portion. 562 Identity Privacy Support 564 EAP/AKA includes optional identity privacy (anonymity) support that 565 can be used to hide the cleartext permanent identity and thereby to 566 make the subscriber's EAP exchanges untraceable to eavesdroppers. 567 Because the permanent identity never changes, revealing it would 568 help observers to track the user. The permanent identity is usually 569 based on the IMSI, which may further help the tracking, because the 570 same identifier may used in other contexts as well. Identity privacy 571 is based on temporary identities, or pseudonyms, which are 572 equivalent to but separate from the Temporary Mobile Subscriber 573 Identities (TMSI) that are used on cellular networks. Please see 574 Section 9.1 for security considerations regarding identity privacy. 576 Username Types in EAP/AKA Identities 578 There are three types of usernames in EAP/AKA peer identities: 580 (1) Permanent usernames. For example, 581 0123456789098765@myoperator.com might be a valid permanent identity. 582 In this example, 0123456789098765 is the permanent username. 584 EAP AKA Authentication 27 October, 2003 586 (2) Pseudonym usernames. For example, 2s7ah6n9q@myoperator.com might 587 be a valid pseudonym identity. In this example, 2s7ah6n9q is the 588 pseudonym username. 590 (3) Re-authentication usernames. For example, 591 43953754a@myoperator.com might be a valid re-authentication 592 identity. In this case, 43953754 is the re-authentication username. 594 The first two types of identities are only used on full 595 authentication and the last one only on re-authentication. When the 596 optional identity privacy support is not used, the non-pseudonym 597 permanent identity is used on full authentication. The re- 598 authentication exchange is specified in Section 4.2. 600 sername Decoration 602 In some environments, the peer may need to decorate the identity by 603 prepending or appending the username with a string, in order to 604 indicate supplementary AAA routing information in addition to the 605 NAI realm. (The usage of a NAI realm portion is not considered to be 606 decoration.) Username decoration is out of the scope of this 607 document. However, it should be noted that username decoration might 608 prevent the server from recognizing a valid username. Hence, 609 although the peer MAY use username decoration in the identities the 610 peer includes in EAP-Response/Identity, and the EAP server MAY 611 accept a decorated peer username in this message, the peer or the 612 EAP server MUST NOT decorate any other peer identities that are used 613 in various EAP/AKA attributes. Only the identity used in EAP- 614 Response/Identity may be decorated. 616 NAI Realm Portion 618 The peer MAY include a realm portion in the peer identity, as per 619 the NAI format. The use of a realm portion is not mandatory. 621 If a realm is used, the realm MAY be chosen by the operator and it 622 MAY a configurable parameter in the EAP/SIM peer implementation. In 623 this case, the peer is typically configured with the NAI realm of 624 the home operator. Operators MAY reserve a specific realm name for 625 EAP/AKA users. This convention makes it easy to recognize that the 626 NAI identifies a UMTS subscriber. Such reserved NAI realm may be 627 useful as a hint as to the first authentication method to use during 628 method negotiation. When the peer is using a pseudonym username 629 instead of the permanent username, the peer selects the realm name 630 portion similarly as it select the realm portion when using the 631 permanent username. 633 If no configured realm name is available, the peer MAY derive the 634 realm name from the MCC and MNC portions of the IMSI. A recommended 635 way to derive the realm from the IMSI using the realm 636 3gppnetwork.org will be specified in [Draft 3GPP TS 23.234]. 637 Alternatively, the realm name may be obtained by concatenating 638 "mnc", the MNC digits of IMSI, ".mcc", the MCC digits of IMSI and 639 ".owlan.org". For example, if the IMSI is 123456789098765, and the 641 EAP AKA Authentication 27 October, 2003 643 MNC is three digits long, then the derived realm name is 644 "mnc456.mcc123.owlan.org". 646 The IMSI is a string of digits without any explicit structure, so 647 the peer may not be able to determine the length of the MNC portion. 648 If the peer is not able to determine whether the MNC is two or three 649 digits long, the peer MAY use a 3-digit MNC. If the correct length 650 of the MNC is two, then the MNC used in the realm name includes the 651 first digit of MSIN. Hence, when configuring AAA networks for 652 operators that have 2-digit MNC's, the network SHOULD also be 653 prepared for realm names with incorrect 3-digit MNC's. 655 Format of the Permanent Username 657 The non-pseudonym permanent username SHOULD be derived from the 658 IMSI. In this case, the permanent username MUST be of the format "0" 659 | IMSI, where the character "|" denotes concatenation. In other 660 words, the first character of the username is the digit zero (ASCII 661 value 0x30), followed by the IMSI. The IMSI is an ASCII string that 662 consists of not more than 15 decimal digits (ASCII values between 663 0x30 and 0x39) as specified in [TS 23.003]. 665 The EAP server MAY use the leading "0" as a hint to try EAP/AKA as 666 the first authentication method during method negotiation, rather 667 than for example EAP/SIM. The EAP/AKA server MAY propose EAP/AKA 668 even if the leading character was not "0". 670 Alternatively, an implementation MAY choose a permanent username 671 that is not based on the IMSI. In this case the selection of the 672 username, its format, and its processing is out of the scope of this 673 document. In this case, the peer implementation MUST NOT prepend any 674 leading characters to the username. 676 Generating Pseudonyms and Re-authentication Identities by the Server 678 Pseudonym usernames and re-authentication identities are generated 679 by the EAP server. The EAP server produces pseudonym usernames and 680 re-authentication identities in an implementation-dependent manner. 681 Only the EAP server needs to be able to map the pseudonym username 682 to the permanent identity, or to recognize a re-authentication 683 identity. Regardless of construction method, the pseudonym username 684 MUST conform to the grammar specified for the username portion of an 685 NAI. The re-authentication identity also MUST conform to the NAI 686 grammar. The EAP servers that the subscribers of an operator can use 687 MUST ensure that the pseudonym usernames and the username portions 688 used in re-authentication identities they generate are unique. 690 In any case, it is necessary that permanent usernames, pseudonym 691 usernames and re-authentication usernames are separate and 692 recognizable from each other. It is also desirable that EAP SIM and 693 EAP AKA user names be recognizable from each other as an aid for the 694 server to which method to offer. 696 EAP AKA Authentication 27 October, 2003 698 In general, it is the task of the EAP server and the policies of its 699 administrator to ensure sufficient separation in the usernames. 700 Pseudonym usernames and re-authentication usernames are both 701 produced and used by the EAP server. The EAP server MUST compose 702 pseudonym usernames and re-authentication usernames so that it can 703 recognize if a NAI username is an EAP AKA pseudonym username or an 704 EAP AKA re-authentication username. For instance, when the usernames 705 have been derived from the IMSI, the server could use different 706 leading characters in the pseudonym usernames and re-authentication 707 usernames (e.g. the pseudonym could begin with a leading "2" 708 character). When mapping a re-authentication identity to a permanent 709 identity, the server SHOULD only examine the username portion of the 710 re-authentication identity and ignore the realm portion of the 711 identity. 713 Because the peer may fail to save a pseudonym username sent to in an 714 EAP-Request/AKA-Challenge, for example due to malfunction, the EAP 715 server SHOULD maintain at least one old pseudonym username in 716 addition to the most recent pseudonym username. 718 Transmitting Pseudonyms and Re-authentication Identities to the Peer 720 The server transmits pseudonym usernames and re-authentication 721 identities to the peer in cipher, using the AT_ENCR_DATA attribute. 723 The EAP-Request/AKA-Challenge message MAY include an encrypted 724 pseudonym username and/or an encrypted re-authentication identity in 725 the value field of the AT_ENCR_DATA attribute. Because identity 726 privacy support and re-authentication are optional to implement, the 727 peer MAY ignore the AT_ENCR_DATA attribute and always use the 728 permanent identity. On re-authentication (discussed in Section 4.2), 729 the server MAY include a new encrypted re-authentication identity in 730 the EAP-Request/AKA-Reauthentication message. 732 On receipt of the EAP-Request/AKA-Challenge, the peer MAY decrypt 733 the encrypted data in AT_ENCR_DATA and if a pseudonym username is 734 included, the peer may use the obtained pseudonym username on the 735 next full authentication. If a re-authentication identity is 736 included, then the peer MAY save it and other re-authentication 737 state information, as discussed in Section 4.2, for the next re- 738 authentication. 740 If the peer does not receive a new pseudonym username in the EAP- 741 Request/AKA-Challenge message, the peer MAY use an old pseudonym 742 username instead of the permanent username on next full 743 authentication. The username portions of re-authentication 744 identities are one-time usernames, which the peer MUST NOT re-use. 746 Usage of the Pseudonym by the Peer 748 When the optional identity privacy support is used on full 749 authentication, the peer MAY use the pseudonym username received as 750 part of the previous full authentication sequence as the username 751 portion of the NAI. The peer MUST NOT modify the pseudonym username 753 EAP AKA Authentication 27 October, 2003 755 received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer 756 MAY need to decorate the username in some environments by appending 757 or prepending the username with a string that indicates 758 supplementary AAA routing information. 760 When using a pseudonym username in an environment where a realm 761 portion is used, the peer concatenates the received pseudonym 762 username with the "@" character and a NAI realm portion. The 763 selection of the NAI realm is discussed above. 765 Usage of the Re-authentication Identity by the Peer 767 On re-authentication, the peer uses the re-authentication identity, 768 received as part of the previous authentication sequence. A new re- 769 authentication identity may be delivered as part of both full 770 authentication and re-authentication. The peer MUST NOT modify the 771 username part of the re-authentication identity received in 772 AT_NEXT_REAUTH_ID, except in cases when username decoration is 773 required. Even in these cases, the "root" re-authentication username 774 must not be modified, but it may be appended or prepended with 775 another string. 777 4.1.2. Communicating the Peer Identity to the Server 779 General 781 The peer identity MAY be communicated to the server with the EAP- 782 Response/Identity message. This message MAY contain the permanent 783 identity, a pseudonym identity, or a re-authentication identity. If 784 the peer uses the permanent identity or a pseudonym identity, which 785 the server is able to map to the permanent identity, then the 786 authentication proceeds as discussed in the overview of Section 3. 787 If the peer uses a re-authentication identity, and the server 788 recognized the identity and agrees on using re-authentication, then 789 a re-authentication exchange is performed, as described in Section 790 4.2. 792 The peer identity can also be transmitted from the peer to the 793 server using EAP/AKA messages instead of EAP-Response/Identity. In 794 this case, the server includes an identity requesting attribute 795 (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the 796 EAP-Request/AKA-Identity message, and the peer includes the 797 AT_IDENTITY attribute, which contains the peer's identity, in the 798 EAP-Response/AKA-Identity message. The AT_ANY_ID_REQ attribute is a 799 general identity requesting attribute, which the server uses if it 800 does not specify which kind of an identity the peer should return in 801 AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to 802 request either the permanent identity or a pseudonym identity. The 803 server uses the AT_PERMANENT_ID_REQ attribute to request the peer to 804 send its permanent identity. The EAP-Request/AKA-Challenge, EAP- 805 Response/AKA-Challenge, or the packets used on re-authentication may 806 optionally include the AT_CHECKCODE attribute, which enables the 807 protocol peers to ensure the integrity of the AKA-Identity packets. 808 AT_CHECKCODE is specified in Section 0. 810 EAP AKA Authentication 27 October, 2003 812 The identity format in the AT_IDENTITY attribute is the same as in 813 the EAP-Response/Identity packet (except that identity decoration is 814 not allowed). The AT_IDENTITY attribute contains a permanent 815 identity, a pseudonym identity or a re-authentication identity. 817 Obtaining the subscriber identity via EAP/AKA messages is useful if 818 the server does not have any EAP/AKA peer identity at the beginning 819 of the EAP/AKA exchange or does not recognize the identity the peer 820 used in EAP-Response/Identity. This may happen if, for example, the 821 EAP-Response/Identity has been issued by some EAP method other than 822 EAP/AKA or if intermediate entities or software layers in the peer 823 have modified the identity string in the EAP-Response/Identity 824 packet. Also, some EAP layer implementations may cache the identity 825 string from the first EAP authentication and do not obtain a new 826 identity string from the EAP method implementation on subsequent 827 authentication exchanges. 829 As the identity string is used in key derivation, any of these cases 830 will result in failed authentication unless the EAP server uses 831 EAP/AKA attributes to obtain an unmodified copy of the identity 832 string. Therefore, unless the EAP server can be certain that no 833 intermediate element or software layer has modified the EAP- 834 Response/Identity packet, the EAP server SHOULD always use the 835 EAP/AKA attributes to obtain the identity, even if the identity 836 received in EAP-Response/Identity was valid. 838 Please note that the EAP/AKA peer and the EAP/AKA server only 839 process the AT_IDENTITY attribute and entities that only pass 840 through EAP packets do not process this attribute. Hence, if the EAP 841 server is not co-located in the authenticator, then the 842 authenticator and other intermediate AAA elements (such as possible 843 AAA proxy servers) will continue to refer to the peer with the 844 original identity from the EAP-Response/Identity packet regardless 845 of whether the AT_IDENTITY attribute is used in EAP/AKA to transmit 846 another identity. 848 Choice of Identity for the EAP-Response/Identity 850 If EAP/AKA peer is started upon receiving an EAP-Request/Identity 851 message, then the peer performs the following steps. 853 If the peer has maintained re-authentication state information and 854 if the peer wants to use re-authentication, then the peer transmits 855 the re-authentication identity in EAP-Response/Identity. 857 Else, if the peer has a pseudonym username available, then the peer 858 transmits the pseudonym identity in EAP-Response/Identity. 860 In other cases, the peer transmits the permanent identity in EAP- 861 Response/Identity. 863 EAP AKA Authentication 27 October, 2003 865 Server Operation in the Beginning of EAP/AKA Exchange 867 If the EAP server has not received any identity (permanent identity, 868 pseudonym identity or re-authentication identity) from the peer when 869 sending the first EAP/AKA request, or if the EAP server has received 870 an EAP-Response/Identity packet but the contents do not appear to be 871 a valid permanent identity, pseudonym identity or a re- 872 authentication identity, then the server MUST request an identity 873 from the peer using one of the methods below. 875 The server sends the EAP-Request/AKA-Identity message with the 876 AT_PERMANENT_ID_REQ message to indicate that the server wants the 877 peer to include the permanent identity in the AT_IDENTITY attribute 878 of the EAP-Response/AKA-Identity message. This is done in the 879 following cases: 881 - The server does not support re-authentication or identity privacy. 883 - The server received an identity that it recognizes as a pseudonym 884 identity but the server is not able to map the pseudonym identity to 885 a permanent identity. 887 The server issues the EAP-Request/AKA-Identity packet with the 888 AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the 889 peer to include a full authentication identity (pseudonym identity 890 or permanent identity) in the AT_IDENTITY attribute of the EAP- 891 Response/AKA-Identity message. This is done in the following cases: 893 - The server does not support re-authentication and the server 894 supports identity privacy 896 - The server received an identity that it recognizes as a re- 897 authentication identity but the server is not able to map the re- 898 authentication identity to a permanent identity 900 The server issues the EAP-Request/AKA-Identity packet with the 901 AT_ANY_ID_REQ attribute to indicate that the server wants the peer 902 to include an identity in the AT_IDENTITY attribute of the EAP- 903 Response/SIM/Start message, and the server does not indicate any 904 preferred type for the identity. This is done in other cases, such 905 as when the server does not have any identity, or the server does 906 not recognize the format of a received identity. 908 Processing of EAP-Request/AKA-Identity by the Peer 910 Upon receipt of an EAP-Request/AKA-Identity message, the peer MUST 911 perform the following steps. 913 If the EAP-Request/AKA-Identity includes AT_PERMANENT_ID_REQ the 914 peer MUST either respond with EAP-Response/AKA-Identity and include 915 the permanent identity in AT_IDENTITY or respond with EAP- 916 Response/AKA-Client-Error packet with code "unable to process 917 packet". 919 EAP AKA Authentication 27 October, 2003 921 If the EAP-Request/AKA-Identity includes AT_FULL_AUTH_ID_REQ, and if 922 the peer has a pseudonym available, then the peer SHOULD respond 923 with EAP-Response/AKA-Identity and includes the pseudonym identity 924 in AT_IDENTITY. If the peer does not have a pseudonym when it 925 receives this message, then the peer MUST either respond with EAP- 926 Response/AKA-Identity and include the permanent identity in 927 AT_IDENTITY or respond with EAP-Response/AKA-Client-Error packet 928 with code "unable to process packet." The Peer MUST NOT use a re- 929 authentication identity in the AT_IDENTITY attribute. 931 If the EAP-Request/AKA-Identity includes AT_ANY_ID_REQ, and if the 932 peer has maintained re-authentication state information and the peer 933 wants to use re-authentication, then the peer responds with EAP- 934 Response/AKA-Identity and includes the re-authentication identity in 935 AT_IDENTITY. Else, if the peer has a pseudonym identity available, 936 then the peer responds with EAP-Response/AKA-Identity and includes 937 the pseudonym identity in AT_IDENTITY. Else, the peer responds with 938 EAP-Response/AKA-Identity and includes the permanent identity in 939 AT_IDENTITY. 941 An EAP/AKA exchange may include several EAP/AKA-Identity rounds. The 942 server may issue a second EAP-Request/AKA-Identity, if it was not 943 able to recognize the identity the peer used in the previous 944 AT_IDENTITY attribute. At most three EAP/AKA-Identity rounds can be 945 used. AT_ANY_ID_REQ can only be used in the first EAP-Request/AKA- 946 Identity, in other words AT_ANY_ID_REQ MUST NOT be used in the 947 second or third EAP-Request/AKA-Identity. AT_FULLAUTH_ID_REQ MUST 948 NOT be used if the previous EAP-Request/AKA-Identity included 949 AT_PERMANENT_ID_REQ. The peer operation in cases when it receives an 950 unexpected attribute is specified in Section 4.4.1. 952 Attacks against Identity Privacy 954 The section above specifies two possible ways the peer can operate 955 upon receipt of AT_PERMANENT_ID_REQ. This is because a received 956 AT_PERMANENT_ID_REQ does not necessarily originate from the valid 957 network, but an active attacker may transmit an EAP-Request/AKA- 958 Identity packet with an AT_PERMANENT_ID_REQ attribute to the peer, 959 in an effort to find out the true identity of the user. If the peer 960 does not want to reveal its permanent identity, then the peer sends 961 the EAP-Response/AKA-Client-Error packet with the error code "unable 962 to process packet", and the authentication exchange terminates. 964 Basically, there are two different policies that the peer can employ 965 with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes 966 that the network is able to maintain pseudonyms robustly. Therefore, 967 if a conservative peer has a pseudonym username, the peer responds 968 with EAP-Response/AKA-Client-Error to the EAP packet with 969 AT_PERMANENT_ID_REQ, because the peer believes that the valid 970 network is able to map the pseudonym identity to the peer's 971 permanent identity. (Alternatively, the conservative peer may accept 972 AT_PERMANENT_ID_REQ in certain circumstances, for example if the 973 pseudonym was received a long time ago.) The benefit of this policy 974 is that it protects the peer against active attacks on anonymity. On 976 EAP AKA Authentication 27 October, 2003 978 the other hand, a "liberal" peer always accepts the 979 AT_PERMANENT_ID_REQ and responds with the permanent identity. The 980 benefit of this policy is that it works even if the valid network 981 sometimes loses pseudonyms and is not able to map them to the 982 permanent identity. 984 Processing of AT_IDENTITY by the Server 986 When the server receives an EAP-Response/AKA-Identity message with 987 the AT_IDENTITY (in response to the server's identity requesting 988 attribute), the server MUST operate as follows. 990 If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does 991 not contain a valid permanent identity, then the server sends EAP 992 Failure and the EAP exchange terminates. If the server recognizes 993 the permanent identity and is able to continue, then the server 994 proceeds with full authentication by sending EAP-Request/AKA- 995 Challenge. 997 If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a 998 valid permanent identity or a pseudonym identity that the server can 999 map to a valid permanent identity, then the server proceeds with 1000 full authentication by sending EAP-Request/AKA-Challenge. If 1001 AT_IDENTITY contains a pseudonym identity that the server is not 1002 able to map to a valid permanent identity, or an identity that the 1003 server is not able to recognize or classify, then the server sends 1004 EAP-Request/ AKA-Identity with AT_PERMANENT_ID_REQ. 1006 If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a 1007 valid permanent identity or a pseudonym identity that the server can 1008 map to a valid permanent identity, then the server proceeds with 1009 full authentication by sending EAP-Request/ AKA-Challenge. 1011 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a 1012 valid re-authentication identity and the server agrees on using re- 1013 authentication, then the server proceeds with re-authentication by 1014 sending EAP-Request/ AKA-Reauthentication (Section 4.2). 1016 If the server used AT_ANY_ID_REQ, and if the peer sent an EAP- 1017 Response/AKA-Identity with AT_IDENTITY that contains an identity 1018 that the server recognizes as a re-authentication identity, but the 1019 server is not able to map the identity to a permanent identity, then 1020 the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ. 1022 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a 1023 valid re-authentication identity, which the server is able to map to 1024 a permanent identity, and if the server does not want to use re- 1025 authentication, then the server proceeds with full authentication by 1026 sending EAP-Request/AKA-Challenge. 1028 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an 1029 identity that the server recognizes as a pseudonym identity but the 1030 server is not able to map the pseudonym identity to a permanent 1032 EAP AKA Authentication 27 October, 2003 1034 identity, then the server sends EAP-Request/AKA-Identity with 1035 AT_PERMANENT_ID_REQ. 1037 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an 1038 identity that the server is not able to recognize or classify, then 1039 the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ. 1041 4.1.3. Message Sequence Examples (Informative) 1043 This section contains non-normative message sequence examples to 1044 illustrate how the peer identity can be communicated to the server. 1046 sage of AT_ANY_ID_REQ 1048 Obtaining the peer identity with EAP/AKA attributes is illustrated 1049 in the figure below. 1051 Peer Authenticator 1052 | | 1053 | +------------------------------+ 1054 | | Server does not have any | 1055 | | Subscriber identity available| 1056 | | When starting EAP/AKA | 1057 | +------------------------------+ 1058 | | 1059 | EAP-Request/AKA-Identity | 1060 | (AT_ANY_ID_REQ) | 1061 |<------------------------------------------------------| 1062 | | 1063 | | 1064 | EAP-Response/AKA-Identity | 1065 | (AT_IDENTITY) | 1066 |------------------------------------------------------>| 1067 | | 1069 all Back on Full Authentication 1071 The figure below illustrates the case when the server does not 1072 recognize the re-authentication identity the peer used in 1073 AT_IDENTITY. 1075 EAP AKA Authentication 27 October, 2003 1077 Peer Authenticator 1078 | | 1079 | +------------------------------+ 1080 | | Server does not have any | 1081 | | Subscriber identity available| 1082 | | When starting EAP/AKA | 1083 | +------------------------------+ 1084 | | 1085 | EAP-Request/AKA-Identity | 1086 | (AT_ANY_ID_REQ) | 1087 |<------------------------------------------------------| 1088 | | 1089 | | 1090 | EAP-Response/AKA-Identity | 1091 | (AT_IDENTITY containing a re-authentication identity) | 1092 |------------------------------------------------------>| 1093 | | 1094 | +------------------------------+ 1095 | | Server does not recognize | 1096 | | The re-authentication | 1097 | | Identity | 1098 | +------------------------------+ 1099 | | 1100 | EAP-Request/AKA-Identity | 1101 | (AT_FULLAUTH_ID_REQ) | 1102 |<------------------------------------------------------| 1103 | | 1104 | | 1105 | EAP-Response/AKA-Identity | 1106 | (AT_IDENTITY with a full-auth. Identity) | 1107 |------------------------------------------------------>| 1108 | | 1110 If the server recognizes the re-authentication identity, but still 1111 wants to fall back on full authentication, the server may issue the 1112 EAP-Request/AKA-Challenge packet. In this case, the full 1113 authentication procedure proceeds as usual. 1115 Requesting the Permanent Identity 1 1117 The figure below illustrates the case when the EAP server fails to 1118 decode a pseudonym identity included in the EAP-Response/Identity 1119 packet. 1121 EAP AKA Authentication 27 October, 2003 1123 Peer Authenticator 1124 | | 1125 | EAP-Request/Identity | 1126 |<------------------------------------------------------| 1127 | | 1128 | EAP-Response/Identity | 1129 | (Includes a pseudonym) | 1130 |------------------------------------------------------>| 1131 | | 1132 | +------------------------------+ 1133 | | Server fails to decode the | 1134 | | Pseudonym. | 1135 | +------------------------------+ 1136 | | 1137 | EAP-Request/AKA-Identity | 1138 | (AT_PERMANENT_ID_REQ) | 1139 |<------------------------------------------------------| 1140 | | 1141 | | 1142 | EAP-Response/AKA-Identity | 1143 | (AT_IDENTITY with permanent identity) | 1144 |------------------------------------------------------>| 1145 | | 1147 If the server recognizes the permanent identity, then the 1148 authentication sequence proceeds as usual with the EAP Server 1149 issuing the EAP-Request/AKA-Challenge message. 1151 Requesting the Permanent Identity 2 1153 The figure below illustrates the case when the EAP server fails to 1154 decode the pseudonym included in the AT_IDENTITY attribute. 1156 EAP AKA Authentication 27 October, 2003 1158 Peer Authenticator 1159 | | 1160 | +------------------------------+ 1161 | | Server does not have any | 1162 | | Subscriber identity available| 1163 | | When starting EAP/AKA | 1164 | +------------------------------+ 1165 | | 1166 | EAP-Request/AKA-Identity | 1167 | (AT_ANY_ID_REQ) | 1168 |<------------------------------------------------------| 1169 | | 1170 | | 1171 |EAP-Response/AKA-Identity | 1172 |(AT_IDENTITY with a pseudonym identity) | 1173 |------------------------------------------------------>| 1174 | | 1175 | | 1176 | +------------------------------+ 1177 | | Server fails to decode the | 1178 | | Pseudonym in AT_IDENTITY | 1179 | +------------------------------+ 1180 | | 1181 | EAP-Request/AKA-Identity | 1182 | (AT_PERMANENT_ID_REQ) | 1183 |<------------------------------------------------------| 1184 | | 1185 | | 1186 | EAP-Response/AKA-Identity | 1187 | (AT_IDENTITY with permanent identity) | 1188 |------------------------------------------------------>| 1189 | | 1191 Three EAP/AKA-Identity Round Trips 1193 The figure below illustrates the case with three EAP/AKA-Identity 1194 round trips. 1196 EAP AKA Authentication 27 October, 2003 1198 Peer Authenticator 1199 | | 1200 | +------------------------------+ 1201 | | Server does not have any | 1202 | | Subscriber identity available| 1203 | | When starting EAP/AKA | 1204 | +------------------------------+ 1205 | | 1206 | EAP-Request/AKA-Identity | 1207 | (AT_ANY_ID_REQ) | 1208 |<------------------------------------------------------| 1209 | | 1210 | EAP-Response/AKA-Identity | 1211 | (AT_IDENTITY with re-authentication identity) | 1212 |------------------------------------------------------>| 1213 | | 1214 | +------------------------------+ 1215 | | Server does not accept | 1216 | | The re-authentication | 1217 | | Identity | 1218 | +------------------------------+ 1219 | | 1220 | EAP-Request/AKA-Identity | 1221 | (AT_FULLAUTH_ID_REQ) | 1222 |<------------------------------------------------------| 1223 | | 1224 |EAP-Response/AKA-Identity | 1225 |(AT_IDENTITY with a pseudonym identity) | 1226 |------------------------------------------------------>| 1227 | | 1228 | +------------------------------+ 1229 | | Server fails to decode the | 1230 | | Pseudonym in AT_IDENTITY | 1231 | +------------------------------+ 1232 | | 1233 | EAP-Request/AKA-Identity | 1234 | (AT_PERMANENT_ID_REQ) | 1235 |<------------------------------------------------------| 1236 | | 1237 | | 1238 | EAP-Response/AKA-Identity | 1239 | (AT_IDENTITY with permanent identity) | 1240 |------------------------------------------------------>| 1241 | | 1243 After the last EAP-Response/AKA-Identity message, the full 1244 authentication sequence proceeds as usual. 1246 4.2. Re-authentication 1248 4.2.1. General 1250 In some environments, EAP authentication may be performed 1251 frequently. Because the EAP AKA full authentication procedure makes 1253 EAP AKA Authentication 27 October, 2003 1255 use of the UMTS AKA algorithms, and it therefore requires fresh 1256 authentication vectors from the Authentication Centre, the full 1257 authentication procedure may result in many network operations when 1258 used very frequently. Therefore, EAP AKA includes a more inexpensive 1259 re-authentication procedure that does not make use of the UMTS AKA 1260 algorithms and does not need new vectors from the Authentication 1261 Centre. 1263 Re-authentication is optional to implement for both the EAP AKA 1264 server and peer. On each EAP authentication, either one of the 1265 entities may also fall back on full authentication if they do not 1266 want to use re-authentication. 1268 Re-authentication is based on the keys derived on the preceding full 1269 authentication. The same K_aut and K_encr keys as in full 1270 authentication are used to protect EAP AKA packets and attributes, 1271 and the original Master Key from full authentication is used to 1272 generate a fresh Master Session Key, as specified in Section 4.5. 1274 On re-authentication, the peer protects against replays with an 1275 unsigned 16-bit counter, included in the AT_COUNTER attribute. On 1276 full authentication, both the server and the peer initialize the 1277 counter to one. The counter value of at least one is used on the 1278 first re-authentication. On subsequent re-authentications, the 1279 counter MUST be greater than on any of the previous re- 1280 authentications. For example, on the second re-authentication, 1281 counter value is two or greater etc. The AT_COUNTER attribute is 1282 encrypted. 1284 The server includes an encrypted server nonce (AT_NONCE_S) in the 1285 re-authentication request. The AT_MAC attribute in the peer's 1286 response is calculated over NONCE_S to provide a challenge/response 1287 authentication scheme. The NONCE_S also contributes to the new 1288 Master Session Key. 1290 Both the peer and the server SHOULD have an upper limit for the 1291 number of subsequent re-authentications allowed before a full 1292 authentication needs to be performed. Because a 16-bit counter is 1293 used in re-authentication, the theoretical maximum number of re- 1294 authentications is reached when the counter value reaches 0xFFFF. 1295 In order to use re-authentication, the peer and the EAP server need 1296 to store the following values: Master Key, latest counter value and 1297 the next re-authentication identity. K_aut, K_encr may either be 1298 stored or derived again from MK. The server may also need to store 1299 the permanent identity of the user. 1301 4.2.2. Re-authentication Identity 1303 The re-authentication procedure makes use of separate re- 1304 authentication user identities. Pseudonyms and the permanent 1305 identity are reserved for full authentication only. If a re- 1306 authentication identity is lost and the network does not recognize 1307 it, the EAP server can fall back on full authentication. 1309 EAP AKA Authentication 27 October, 2003 1311 If the EAP server supports re-authentication, it MAY include the 1312 skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP- 1313 Request/AKA-Challenge message. This attribute contains a new re- 1314 authentication identity for the next re-authentication. The peer MAY 1315 ignore this attribute, in which case it will use full authentication 1316 next time. If the peer wants to use re-authentication, it uses this 1317 re-authentication identity on next authentication. Even if the peer 1318 has a re-authentication identity, the peer MAY discard the re- 1319 authentication identity and use a pseudonym or the permanent 1320 identity instead, in which case full authentication MUST be 1321 performed. 1323 In environments where a real portion is needed in the peer identity, 1324 the re-authentication identity received in AT_NEXT_REAUTH_ID MUST 1325 contain both a username portion and a realm portion, as per the NAI 1326 format. The EAP Server can choose an appropriate realm part in order 1327 to have the AAA infrastructure route subsequent re-authentication 1328 related requests to the same AAA server. For example, the realm part 1329 MAY include a portion that is specific to the AAA server. Hence, it 1330 is sufficient to store the context required for re-authentication in 1331 the AAA server that performed the full authentication. 1333 The peer MAY use the re-authentication identity in the EAP- 1334 Response/Identity packet or, in response to server's AT_ANY_ID_REQ 1335 attribute, the peer MAY use the re-authentication identity in the 1336 AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet. The 1337 peer MUST NOT modify the username portion of the re-authentication 1338 identity, but the peer MAY modify the realm portion or replace it 1339 with another realm portion. 1341 Even if the peer uses a re-authentication identity, the server may 1342 want to fall back on full authentication, for example because the 1343 server does not recognize the re-authentication identity or does not 1344 want to use re-authentication. If the server was able to decode the 1345 re-authentication identity to the permanent identity, the server 1346 issues the EAP-Request/AKA-Challenge packet to initiate full 1347 authentication. If the server was not able to recover the peer's 1348 identity from the re-authentication identity, the server starts the 1349 full authentication procedure by issuing an EAP-Request/AKA-Identity 1350 packet. This packet always starts a full authentication sequence if 1351 it does not include the AT_ANY_ID_REQ attribute. 1353 4.2.3. Re-authentication Procedure 1355 The following figure illustrates the re-authentication procedure. 1356 Encrypted attributes are denoted with '*'. The peer uses its re- 1357 authentication identity in the EAP-Response/Identity packet. As 1358 discussed above, an alternative way to communicate the re- 1359 authentication identity to the server is for the peer to use the 1360 AT_IDENTITY attribute in the EAP-Response/AKA-Identity message. This 1361 latter case is not illustrated in the figure below, and it is only 1362 possible when the server requests the peer to send its identity by 1363 including the AT_ANY_ID_REQ attribute in the EAP-Request/AKA- 1364 Identity packet. 1366 EAP AKA Authentication 27 October, 2003 1368 If the server recognizes the re-authentication identity and agrees 1369 on using re-authentication, then the server sends the EAP- 1370 Request/AKA-Reauthentication packet to the peer. This packet MUST 1371 include the encrypted AT_COUNTER attribute, with a fresh counter 1372 value, the encrypted AT_NONCE_S attribute that contains a random 1373 number chosen by the server, the AT_ENCR_DATA and the AT_IV 1374 attributes used for encryption, and the AT_MAC attribute that 1375 contains a message authentication code over the packet. The packet 1376 MAY also include an encrypted AT_NEXT_REAUTH_ID attribute that 1377 contains the next re-authentication identity. 1379 Re-authentication identities are one-time identities. If the peer 1380 does not receive a new re-authentication identity, it MUST use 1381 either the permanent identity or a pseudonym identity on the next 1382 authentication to initiate full authentication. 1384 The peer verifies that the counter value is fresh (greater than any 1385 previously used value). The peer also verifies that AT_MAC is 1386 correct. The peer MAY save the next re-authentication identity from 1387 the encrypted AT_NEXT_REAUTH_ID for next time. If all checks are 1388 successful, the peer responds with the EAP-Response/AKA- 1389 Reauthentication packet, including the AT_COUNTER attribute with the 1390 same counter value and the AT_MAC attribute. 1392 The server verifies the AT_MAC attribute and also verifies that the 1393 counter value is the same that it used in the EAP-Request/AKA- 1394 Reauthentication packet. If these checks are successful, the re- 1395 authentication has succeeded and the server sends the EAP-Success 1396 packet to the peer. 1398 EAP AKA Authentication 27 October, 2003 1400 Peer Authenticator 1401 | | 1402 | EAP-Request/Identity | 1403 |<------------------------------------------------------| 1404 | | 1405 | EAP-Response/Identity | 1406 | (Includes a re-authentication identity) | 1407 |------------------------------------------------------>| 1408 | | 1409 | +--------------------------------+ 1410 | | Server recognizes the identity | 1411 | | and agrees on using fast | 1412 | | re-authentication | 1413 | +--------------------------------+ 1414 | | 1415 | EAP-Request/AKA-Reauthentication | 1416 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1417 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1418 |<------------------------------------------------------| 1419 | | 1420 | | 1421 +-----------------------------------------------+ | 1422 | Peer verifies AT_MAC and the freshness of | | 1423 | the counter. Peer MAY store the new re- | | 1424 | authentication identity for next re-auth. | | 1425 +-----------------------------------------------+ | 1426 | | 1427 | EAP-Response/AKA-Reauthentication | 1428 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, | 1429 | AT_MAC) | 1430 |------------------------------------------------------>| 1431 | | 1432 | +--------------------------------+ 1433 | | Server verifies AT_MAC and | 1434 | | the counter | 1435 | +--------------------------------+ 1436 | | 1437 | EAP-Success | 1438 |<------------------------------------------------------| 1439 | | 1441 4.2.4. Re-authentication Procedure when Counter is Too Small 1443 If the peer does not accept the counter value of EAP-Request/AKA- 1444 Reauthentication, it indicates the counter synchronization problem 1445 by including the encrypted AT_COUNTER_TOO_SMALL in EAP-Response/AKA- 1446 Reauthentication. The server responds with EAP-Request/AKA-Challenge 1447 to initiate a normal full authentication procedure. This is 1448 illustrated in the following figure. Encrypted attributes are 1449 denoted with '*'. 1451 EAP AKA Authentication 27 October, 2003 1453 Peer Authenticator 1454 | | 1455 | EAP-Request/Identity | 1456 |<------------------------------------------------------| 1457 | | 1458 | EAP-Response/Identity | 1459 | (Includes a re-authentication identity) | 1460 |------------------------------------------------------>| 1461 | | 1462 | EAP-Request/AKA-Reauthentication | 1463 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1464 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1465 |<------------------------------------------------------| 1466 | | 1467 +-----------------------------------------------+ | 1468 | AT_MAC is valid but the counter is not fresh. | | 1469 +-----------------------------------------------+ | 1470 | | 1471 | EAP-Response/AKA-Reauthentication | 1472 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, | 1473 | *AT_COUNTER, AT_MAC) | 1474 |------------------------------------------------------>| 1475 | | 1476 | +----------------------------------------------+ 1477 | | Server verifies AT_MAC but detects | 1478 | | That peer has included AT_COUNTER_TOO_SMALL| 1479 | +----------------------------------------------+ 1480 | | 1481 | EAP-Request/AKA-Challenge | 1482 |<------------------------------------------------------| 1483 | | 1484 +---------------------------------------------------------------+ 1485 | Normal full authentication follows. | 1486 +---------------------------------------------------------------+ 1487 | | 1489 In the figure above, the first three messages are similar to the 1490 basic re-authentication case. When the peer detects that the counter 1491 value is not fresh, it includes the AT_COUNTER_TOO_SMALL attribute 1492 in EAP-Response/AKA-Reauthentication. This attribute doesn't contain 1493 any data but it is a request for the server to initiate full 1494 authentication. In this case, the peer MUST ignore the contents of 1495 the server's AT_NEXT_REAUTH_ID attribute. 1497 On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and 1498 verifies that AT_COUNTER contains the same as in the EAP- 1499 Request/AKA-Reauthentication packet. If not, the server silently 1500 discards the EAP-Response/AKA-Reauthentication packet. If all checks 1501 on the packet are successful, the server transmits a EAP- 1502 Request/AKA-Challenge packet and the full authentication procedure 1503 is performed as usual. Since the server already knows the subscriber 1504 identity, it MUST NOT use the EAP-Request/AKA-Identity packet to 1505 request the identity. 1507 EAP AKA Authentication 27 October, 2003 1509 4.3. EAP/AKA Notifications 1511 The EAP-Request/Notification, specified in [EAP], can be used to 1512 convey a displayable message from the EAP server to the peer. 1513 Because these messages are textual messages, it may be hard for the 1514 peer to present them in the user's preferred language. Therefore, 1515 EAP/AKA uses a separate EAP/AKA message subtype to transmit 1516 localizable notification codes instead of the EAP- 1517 Request/Notification packet. 1519 The EAP server MAY issue an EAP-Request/AKA-Notification packet to 1520 the peer. The peer MAY show a notification message to the user and 1521 the peer MUST respond to the EAP server with an EAP-Response/AKA- 1522 Notification packet, even if the peer did not recognize the 1523 notification code. 1525 The notification code is a 16-bit number. The most significant bit 1526 is called the Failure bit (F bit). The F bit specifies whether the 1527 notification implies failure. The code values with the F bit set to 1528 zero (code values 0...32767) are used on unsuccessful cases. The 1529 receipt of a notification code from this range implies failed 1530 authentication, so the peer can use the notification as a failure 1531 indication. After receiving the EAP-Response/AKA-Notification for 1532 these notification codes, the server MUST send the EAP-Failure 1533 packet. 1535 The receipt of a notification code with the F bit set to one (values 1536 32768...65536) does not imply failure, so the peer MUST NOT change 1537 its state when it receives such a notification. (This version of the 1538 protocol does not specify any notification codes with the F bit set 1539 to one.) 1541 The second most significant bit of the notification code is called 1542 the Phase bit (P bit). It specifies at which phase of the EAP/AKA 1543 exchange the notification can be used. If the P bit is set to zero, 1544 the notification can only be used after the EAP/AKA-Challenge round 1545 in full authentication or the EAP/AKA-Reauthentication round in 1546 reautentication. For these notifications, the AT_MAC attribute MUST 1547 be included in both EAP-Request/AKA-Notification and EAP- 1548 Response/AKA-Notification. 1550 If the P bit is set to one, the notification can only by used before 1551 the EAP/AKA-Challenge round in full authentication or the EAP/AKA- 1552 Reauthentication round in reauthentication. For these notifications, 1553 the AT_MAC attribute MUST NOT be included in either EAP-Request/AKA- 1554 Notification or EAP-Response/AKA-Notification. (This version of the 1555 protocol does not specify any notification codes with the P bit set 1556 to one.) 1558 Some of the notification codes are authorization related and hence 1559 not usually considered as part of the responsibility of an EAP 1560 method. However, they are included as part of EAP/AKA because there 1561 are currently no other ways to convey this information to the user 1563 EAP AKA Authentication 27 October, 2003 1565 in a localizable way, and the information is potentially useful for 1566 the user. An EAP/AKA server implementation may decide never to send 1567 these EAP/AKA notifications. 1569 4.4. Error Cases 1571 This section specifies the operation of the peer and the server in 1572 error cases. The subsections below require the EAP/AKA peer and 1573 server to send an error packet (EAP-Response/AKA-Client-Error or EAP 1574 Failure) in error cases. However, implementations SHOULD NOT rely 1575 upon the correct error reporting behavior of the peer, 1576 authenticator, or the server. It is possible for error and other 1577 messages to be lost in transit or for a malicious participant to 1578 attempt to consume resources by not issuing error messages. Both 1579 the peer and the EAP server SHOULD have a mechanism to clean up 1580 state even if an error message or EAP Success is not received after 1581 a timeout period. 1583 4.4.1. Peer Operation 1585 Two special error messages have been specified for error cases that 1586 are related to the processing of the UMTS AKA AUTN parameter, as 1587 described in Section 3: (1) if the peer does not accept AUTN, the 1588 peer responds with EAP-Response/AKA-Authentication-Reject (Section 1589 6.5), and the server issues EAP Failure, and (2) if the peer detects 1590 that the sequence number in AUTN is not correct, the peer responds 1591 with EAP-Response/AKA-Synchronization-Failure (Section 6.6), and the 1592 server proceeds with a new EAP-Request/AKA-Challenge. 1594 In other error cases, when an EAP/AKA peer detects an error in a 1595 received EAP/AKA packet, the EAP/AKA peer responds with the EAP- 1596 Response/AKA-Client-Error packet. In response to the EAP- 1597 Response/AKA-Client-Error, the EAP server MUST issue the EAP Failure 1598 packet and the authentication exchange terminates. 1600 By default, the peer uses the client error code 0, "unable to 1601 process packet". This error code is used in the following cases: 1603 - the peer is not able to parse the EAP request, i.e. the EAP 1604 request is malformed 1606 - the peer encountered a malformed attribute 1608 - wrong attribute types or duplicate attributes have been included 1609 in the EAP request 1611 - a mandatory attribute is missing 1613 - unrecognized non-skippable attribute 1615 - unrecognized or unexpected EAP/AKA Subtype in the EAP request 1617 - invalid AT_MAC 1619 EAP AKA Authentication 27 October, 2003 1621 - invalid AT_CHECKCODE 1623 - invalid pad bytes in AT_PADDING 1625 - the peer does not want to process AT_PERMANENT_ID_REQ 1627 4.4.2. Server Operation 1629 If an EAP/AKA server detects an error in a received EAP/AKA 1630 response, the server MUST issue the EAP Failure packet and the 1631 authentication exchange terminates. The errors cases when the server 1632 issues an EAP Failure include the following: 1634 - the server is not able to parse the peer's EAP response 1636 - the server encounters a malformed attribute, a non-recognized non- 1637 skippable attribute, or a duplicate attribute 1639 - a mandatory attribute is missing or an invalid attribute was 1640 included 1642 - unrecognized or unexpected EAP/AKA Subtype in the EAP Response 1644 - invalid AT_MAC 1646 - invalid AT_CHECKCODE 1648 - invalid AT_COUNTER 1650 4.4.3. Failure 1652 As normally in EAP, the EAP server sends the EAP-Failure packet to 1653 the peer when the authentication procedure fails on the EAP Server. 1654 In EAP/AKA, this may occur for example if the EAP server does not 1655 recognize the peer identity, or if the EAP server is not able to 1656 obtain the authentication vectors for the subscriber or the 1657 authentication exchange times out. The server may also send EAP 1658 Failure if there is an error in the received EAP/AKA response, as 1659 discussed in Section 4.4.2. 1661 The server can send EAP-Failure at any time in the EAP exchange. The 1662 peer MUST process EAP-Failure. 1664 4.4.4. EAP Success 1666 On full authentication, the server can only send EAP-Success after 1667 the EAP/AKA-Challenge round. The peer MUST silently discard any EAP- 1668 Success packets if they are received before the peer has 1669 successfully authenticated the server and sent the EAP-Response/AKA- 1670 Challenge packet. 1672 On re-authentication, EAP-Success can only be sent after the 1673 EAP/AKA-Reauthentication round. The peer MUST silently discard any 1674 EAP-Success packets if they are received before the peer has 1676 EAP AKA Authentication 27 October, 2003 1678 successfully authenticated the server and sent the EAP-Response/AKA- 1679 Reauthentication packet. 1681 If the peer receives an EAP/AKA notification (section 4.3) that 1682 indicates failure, then the peer MUST no longer accept the EAP- 1683 Success packet even if the server authentication was successfully 1684 completed. 1686 4.5. Key Generation 1688 This section specifies how keying material is generated. 1690 On EAP AKA full authentication, a Master Key (MK) is derived from 1691 the underlying UMTS AKA values (CK and IK keys), and the identity as 1692 follows. 1694 MK = SHA1(Identity|IK|CK) 1696 In the formula above, the "|" character denotes concatenation. 1697 Identity denotes the peer identity string without any terminating 1698 null characters. It is the identity from the AT_IDENTITY attribute 1699 from the last EAP-Response/AKA-Identity packet, or, if AT_IDENTITY 1700 was not used, the identity from the EAP-Response/Identity packet. 1701 The identity string is included as-is, without any changes and 1702 including the possible identity decoration. The hash function SHA-1 1703 is specified in [SHA-1]. 1705 The Master Key is fed into a Pseudo-Random number Function (PRF), 1706 which generates separate Transient EAP Keys (TEKs) for protecting 1707 EAP AKA packets, as well as a Master Session Key (MSK) for link 1708 layer security and an Extended Master Session Key (EMSK) for other 1709 purposes. On re-authentication, the same TEKs MUST be used for 1710 protecting EAP packets, but a new MSK and a new EMSK MUST be derived 1711 from the original MK and new values exchanged in the re- 1712 authentication. 1714 EAP AKA requires two TEKs for its own purposes, the authentication 1715 key K_aut to be used with the AT_MAC attribute, and the encryption 1716 key K_encr, to be used with the AT_ENCR_DATA attribute. The same 1717 K_aut and K_encr keys are used in full authentication and subsequent 1718 re-authentications. 1720 Key derivation is based on the random number generation specified in 1721 NIST Federal Information Processing Standards (FIPS) Publication 1722 186-2 [PRF]. The pseudo-random number generator is specified in the 1723 change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As 1724 specified in the change notice (page 74), when Algorithm 1 is used 1725 as a general-purpose pseudo-random number generator, the "mod q" 1726 term in step 3.3 is omitted. The function G used in the algorithm is 1727 constructed via Secure Hash Standard as specified in Appendix 3.3 of 1728 the standard. It should be noted that the function G is very similar 1729 to SHA-1, but the message padding is different. Please refer to 1730 [PRF] for full details. For convenience, the random number algorithm 1731 with the correct modification is cited in Annex A. 1733 EAP AKA Authentication 27 October, 2003 1735 160-bit XKEY and XVAL values are used, so b = 160. On each full 1736 authentication, the Master Key is used as the initial secret seed- 1737 key XKEY. The optional user input values (XSEED_j) in step 3.1 are 1738 set to zero. 1740 The resulting 320-bit random numbers x_0, x_1, ..., x_m-1 are 1741 concatenated and partitioned into suitable-sized chunks and used as 1742 keys in the following order: K_encr (128 bits), K_aut (128 bits), 1743 Master Session Key (64 bytes), Extended Master Session Key (64 1744 bytes). 1746 On re-authentication, the same pseudo-random number generator can be 1747 used to generate a new Master Session Key and new Initialization 1748 Vectors. The seed value XKEY' is calculated as follows: 1749 XKEY' = SHA1(Identity|counter|NONCE_S| MK) 1751 In the formula above, the Identity denotes the re-authentication 1752 identity, without any terminating null characters, from the 1753 AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, 1754 if EAP-Response/AKA-Identity was not used on re-authentication, the 1755 identity string from the EAP-Response/Identity packet. The counter 1756 denotes the counter value from AT_COUNTER attribute used in the EAP- 1757 Response/AKA-Reauthentication packet. The counter is used in network 1758 byte order. NONCE_S denotes the 16-byte NONCE_S value from the 1759 AT_NONCE_S attribute used in the EAP-Request/AKA-Reauthentication 1760 packet. The MK is the Master Key derived on the preceding full 1761 authentication. The pseudo-random number generator is run with the 1762 new seed value XKEY', and the resulting 320-bit random numbers x_0, 1763 x_1, ..., x_m-1 are concatenated and partitioned into 64-byte chunks 1764 and used as the new 64-byte Master Session Key and the new 64-byte 1765 Extended Master Session Key. 1767 The first 32 bytes of the MSK can be used as the Pairwise Master Key 1768 (PMK) for IEEE 802.11i. 1770 When the RADIUS attributes specified in [RFC 2548] are used to 1771 transport keying material, then the first 32 bytes of the MSK 1772 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE- 1773 SEND-KEY. In this case, only 64 bytes of keying material (the MSK) 1774 are used. 1776 5. Message Format and Protocol Extensibility 1778 5.1. Message Format 1780 As specified in [EAP], EAP packets begin with the Code, Identifiers, 1781 Length, and Type fields, which are followed by EAP method specific 1782 Type-Data. The Code field in the EAP header is set to 1 for EAP 1783 requests, and to 2 for EAP Responses. The usage of the Length and 1784 Identifier fields in the EAP header is also specified in [EAP]. In 1785 EAP/AKA, the Type field is set to 23. 1787 EAP AKA Authentication 27 October, 2003 1789 In EAP/AKA, the Type-Data begins with an EAP/AKA header that 1790 consists of a 1-octet Subtype field, and a 2-octet reserved field. 1791 The Subtype values used in EAP/AKA are defined in Section 8. The 1792 formats of the EAP header and the EAP/AKA header are shown below. 1794 0 1 2 3 1795 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 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 | Code | Identifier | Length | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | Type | Subtype | Reserved | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 The rest of the Type-Data, immediately following the EAP/AKA header, 1803 consists of attributes that are encoded in Type, Length, Value 1804 format. The figure below shows the generic format of an attribute. 1806 0 1 2 3 1807 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 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 |Attribute Type | Length | Value... 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 Attribute Type 1814 Indicates the particular type of attribute. The attribute type 1815 values are listed in Section 8. 1817 Length 1819 Indicates the length of this attribute in multiples of 4 bytes. 1820 The maximum length of an attribute is 1024 bytes. The length 1821 includes the Attribute Type and Length bytes. 1823 Value 1825 The particular data associated with this attribute. This field is 1826 always included and it is two or more bytes in length. The type 1827 and length fields determine the format and length of the value 1828 field. 1830 Attributes numbered within the range 0 through 127 are called non- 1831 skippable attributes. When an EAP/AKA peer encounters a non- 1832 skippable attribute type that the peer does not recognize, the peer 1833 MUST send the EAP-Response/AKA-Client-Error packet, and the 1834 authentication exchange terminates. If an EAP/AKA server encounters 1835 a non-skippable attribute that the server does not recognize, then 1836 the server sends the EAP Failure packet and the authentication 1837 exchange terminates. 1839 When an attribute numbered in the range 128 through 255 is 1840 encountered but not recognized that particular attribute is ignored, 1842 EAP AKA Authentication 27 October, 2003 1844 but the rest of the attributes and message data MUST still be 1845 processed. The Length field of the attribute is used to skip the 1846 attribute value when searching for the next attribute. These 1847 attributes are called skippable attributes. 1849 Unless otherwise specified, the order of the attributes in an EAP 1850 AKA message is insignificant, and an EAP AKA implementation should 1851 not assume a certain order to be used. 1853 Attributes can be encapsulated within other attributes. In other 1854 words, the value field of an attribute type can be specified to 1855 contain other attributes. 1857 5.2. Protocol Extensibility 1859 EAP/AKA can be extended by specifying new attribute types. If 1860 skippable attributes are used, it is possible to extend the protocol 1861 without breaking old implementations. As specified in Section 7.4, 1862 if new attributes are specified for EAP-Request/AKA-Identity or EAP- 1863 Response/AKA-Identity, then the AT_CHECKCODE MUST be used to 1864 integrity protect the new attributes. 1866 When specifying new attributes, it should be noted that EAP/AKA does 1867 not support message fragmentation. Hence, the sizes of the new 1868 extensions MUST be limited so that the maximum transfer unit (MTU) 1869 of the underlying lower layer is not exceeded. According to [EAP], 1870 lower layers must provide an EAP MTU of 1020 bytes or greater, so 1871 any extensions to EAP/AKA SHOULD NOT exceed the EAP MTU of 1020 1872 bytes. 1874 EAP/AKA packets do not include a version field. However, should 1875 there be a reason to revise this protocol in the future, new non- 1876 skippable or skippable attributes could be specified in order to 1877 implement revised EAP/AKA versions in a backward-compatible manner. 1878 It is possible to introduce version negotiation in the EAP- 1879 Request/AKA-Identity and EAP-Response/AKA-Identity messages by 1880 specifying new skippable attributes. 1882 6. Messages 1884 This section specifies the messages used in EAP/AKA. It specifies 1885 when a message may be transmitted or accepted, which attributes are 1886 allowed in a message, which attributes are required in a message, 1887 and other message specific details. Message format is specified in 1888 Section 5.1. 1890 6.1. EAP-Request/AKA-Identity 1892 The EAP/AKA-Identity roundtrip MAY used for obtaining the peer 1893 identity to the server. As discussed in Section 4.1, several AKA- 1894 Identity rounds may be required in order to obtain a valid peer 1895 identity. 1897 EAP AKA Authentication 27 October, 2003 1899 The server MUST include one of the following identity requesting 1900 attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, AT_ANY_ID_REQ. 1901 These three attributes are mutually exclusive, so the server MUST 1902 NOT include more than one of the attributes. 1904 If the server has previously issued an EAP-Request/AKA-Identity 1905 message with the AT_PERMANENT_ID_REQ attribute, and if the server 1906 has received a response from the peer, then the server MUST NOT 1907 issue a new EAP-Request/AKA-Identity packet. 1909 If the server has previously issued an EAP-Request/AKA-Identity 1910 message with the AT_FULLAUTH_ID_REQ attribute, and if the server has 1911 received a response from the peer, then the server MUST NOT issue a 1912 new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ or 1913 AT_FULLAUTH_ID_REQ attributes. 1915 If the server has previously issued an EAP-Request/AKA-Identity 1916 message with the AT_ANY_ID_REQ attribute, and if the server has 1917 received a response from the peer, then the server MUST NOT issue a 1918 new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ. 1920 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. 1922 6.2. EAP-Response/AKA-Identity 1924 The peer sends EAP-Response/AKA-Identity in response to a valid EAP- 1925 Request/AKA-Identity from the server. 1927 The peer MUST include the AT_IDENTITY attribute. The usage of 1928 AT_IDENITY is defined in Section 4.1. 1930 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. 1932 6.3. EAP-Request/AKA-Challenge 1934 The server sends the EAP-Request/AKA-Challenge on full 1935 authentication after successfully obtaining the subscriber identity. 1937 The AT_RAND attribute MUST be included. 1939 AT_MAC MUST be included. In EAP-Request/AKA-Challenge, there is no 1940 message-specific data covered by the MAC, see Section 7.2. 1942 The AT_CHECKCODE attribute MAY be included, and in certain cases 1943 specified in Section 7.4, it MUST be included. 1945 The EAP-Request/AKA-Challenge packet MAY include encrypted 1946 attributes for identity privacy and for communicating the next re- 1947 authentication identity. In this case, the AT_IV and AT_ENCR_DATA 1948 attributes are included (Section 7.3). 1950 The plaintext of the AT_ENCR_DATA value field consist of nested 1951 attributes. The nested attributes MAY include AT_PADDING (as 1952 specified in Section 7.3). If the server supports identity privacy 1954 EAP AKA Authentication 27 October, 2003 1956 and wants to communicate a pseudonym to the peer for the next full 1957 authentication, then the nested encrypted attributes include the 1958 AT_NEXT_PSEUDONYM attribute. If the server supports re- 1959 authentication and wants to communicate a re-authentication identity 1960 to the peer, then the nested encrypted attributes include the 1961 AT_NEXT_REAUTH_ID attribute. Later versions of this protocol MAY 1962 specify additional attributes to be included within the encrypted 1963 data. 1965 6.4. EAP-Response/AKA-Challenge 1967 The peer sends EAP-Response/AKA-Challenge in response to a valid 1968 EAP-Request/AKA-Challenge. 1970 The AT_MAC attribute MUST be included. In EAP-Response/AKA- 1971 Challenge, there is no message-specific data covered by the MAC, see 1972 Section 7.2. 1974 The AT_RES attribute MUST be included. 1976 The AT_CHECKCODE attribute MAY be included, and in certain cases 1977 specified in Section 7.4, it MUST be included. 1979 Later versions of this protocol MAY make use of the AT_ENCR_DATA and 1980 AT_IV attributes in this message to include encrypted (skippable) 1981 attributes. The EAP server MUST process EAP-Response/AKA-Challenge 1982 messages that include these attributes even if the server did not 1983 implement these optional attributes. 1985 6.5. EAP-Response/AKA-Authentication-Reject 1987 The peer sends the EAP-Response/AKA-Authentication-Reject packet if 1988 it does not accept the AUTN parameter. This version of the protocol 1989 does not specify any attributes for this message. Future versions of 1990 the protocol MAY specify attributes for this message. 1992 The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in 1993 this message. 1995 6.6. EAP-Response/AKA-Synchronization-Failure 1997 The peer sends the EAP-Response/AKA-Synchronization-Failure, when 1998 the sequence number in the AUTN parameter is incorrect. 2000 The peer MUST include the AT_AUTS attribute. Future versions of the 2001 protocol MAY specify other additional attributes for this message. 2003 The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in 2004 this message. 2006 6.7. EAP-Request/AKA-Reauthentication 2008 EAP AKA Authentication 27 October, 2003 2010 The server sends the EAP-Request/AKA-Reauthentication message if it 2011 wants to use re-authentication, and if it has received a valid re- 2012 authentication identity in EAP-Response/Identity or EAP- 2013 Response/AKA-Identity. 2015 The AT_MAC attribute MUST be included. No message-specific data is 2016 included in the MAC calculation, see Section 7.2. 2018 The AT_CHECKCODE attribute MAY be included, and in certain cases 2019 specified in Section 7.4, it MUST be included. 2021 The AT_IV and AT_ENCR_DATA attributes MUST be included. The 2022 plaintext consists of the following nested encrypted attributes, 2023 which MUST be included: AT_COUNTER and AT_NONCE_S. In addition, the 2024 nested encrypted attributes MAY include the following attributes: 2025 AT_NEXT_REAUTH_ID and AT_PADDING. 2027 6.8. EAP-Response/AKA-Reauthentication 2029 The client sends the EAP-Response/AKA-Reauthentication packet in 2030 response to a valid EAP-Request/AKA-Reauthentication. 2032 The AT_MAC attribute MUST be included. For EAP-Response/AKA- 2033 Reauthentication, the MAC code is calculated over the following 2034 data: EAP packet| NONCE_S. The EAP packet is represented as 2035 specified in Section 5.1. It is followed by the 16-byte NONCE_S 2036 value from the server's AT_NONCE_S attribute. 2038 The AT_CHECKCODE attribute MAY be included, and in certain cases 2039 specified in Section 7.4, it MUST be included. 2041 The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested 2042 encrypted attributes MUST include the AT_COUNTER attribute. The 2043 AT_COUNTER_TOO_SMALL attribute MAY be included in the nested 2044 encrypted attributes, and it is included in cases specified in 2045 Section 4.2. The AT_PADDING attribute MAY be included. 2047 6.9. EAP-Response/AKA-Client-Error 2049 The peer sends EAP-Response/AKA-Client-Error in error cases, as 2050 specified in Section 4.4.1. 2052 The AT_CLIENT_ERROR_CODE attribute MUST be included. 2053 The AT_MAC, AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with 2054 this packet. 2056 6.10. EAP-Request/AKA-Notification 2058 The usage of this message is specified in Section 4.3. 2060 The AT_NOTIFICATION attribute MUST be included. 2062 EAP AKA Authentication 27 October, 2003 2064 The AT_MAC attribute is included in cases discussed in Section 4.3. 2065 No message-specific data is included in the MAC calculation. See 2066 Section 7.2. 2068 Later versions of this protocol MAY make use of the AT_ENCR_DATA and 2069 AT_IV attributes in this message to include encrypted (skippable) 2070 attributes. These attributes MAY be included only if the P bit of 2071 the notification code in AT_NOTIFICATION is set to zero. 2073 6.11. EAP-Response/AKA-Notification 2075 The usage of this message is specified in Section 4.3. Because this 2076 packet is only an acknowledgement of EAP-Request/AKA-Notification, 2077 it does not contain any mandatory attributes. 2079 The AT_MAC attribute is included in cases described in Section 4.3. 2080 No message-specific data is included in the MAC calculation. See 2081 Section 7.2. 2083 Later versions of this protocol MAY make use of the AT_ENCR_DATA and 2084 AT_IV attributes in this message to include encrypted (skippable) 2085 attributes. These attributes MAY be included only if the P bit of 2086 the notification code in the AT_NOTIFICATION attribute of the 2087 server's EAP-Request/AKA-Notification packet is set to zero. 2089 7. Attributes 2091 This section specifies the format of message attributes. The 2092 attribute type numbers are specified in Section 8. 2094 7.1. Table of Attributes 2096 The following table provides a guide to which attributes may be 2097 found in which kinds of messages, and in what quantity. Messages are 2098 denoted with numbers in parentheses as follows: (1) EAP-Request/AKA- 2099 Identity, (2) EAP-Response/AKA-Identity, (3) EAP-Request/AKA- 2100 Challenge, (4) EAP-Response/AKA-Challenge, (5) EAP-Request/AKA- 2101 Notification, (6) EAP-Response/AKA-Notification, (7) EAP- 2102 Response/AKA-Client-Error (8) EAP-Request/AKA-Reauthentication, (9) 2103 EAP-Response/AKA-Re-authentication, (10) EAP-Response/AKA- 2104 Authentication-Reject, and (11) EAP-Response/AKA-Synchronization- 2105 Failure. The column denoted with "E" indicates whether the attribute 2106 is a nested attribute that MUST be included within AT_ENCR_DATA. 2108 "0" indicates that the attribute MUST NOT be included in the 2109 message, "1" indicates that the attribute MUST be included in the 2110 message, "0-1" indicates that the attribute is sometimes included in 2111 the message, and "0*" indicates that the attribute is not included 2112 in the message in cases specified in this document, but MAY be 2113 included in the future versions of the protocol. 2115 EAP AKA Authentication 27 October, 2003 2117 Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E 2118 AT_MAC 0 0 1 1 0-1 0-1 0 1 1 0 0 N 2119 AT_IV 0 0 0-1 0* 0* 0* 0 1 1 0 0 N 2120 AT_ENCR_DATA 0 0 0-1 0* 0* 0* 0 1 1 0 0 N 2121 AT_PADDING 0 0 0-1 0* 0* 0* 0 0-1 0-1 0 0 Y 2122 AT_CHECKCODE 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N 2123 AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 2124 AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 2125 AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 2126 AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 0 0 N 2127 AT_RAND 0 0 1 0 0 0 0 0 0 0 0 N 2128 AT_AUTN 0 0 1 0 0 0 0 0 0 0 0 N 2129 AT_RES 0 0 0 1 0 0 0 0 0 0 0 N 2130 AT_AUTS 0 0 0 0 0 0 0 0 0 0 1 N 2131 AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 0 0 Y 2132 AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 0 0 Y 2133 AT_COUNTER 0 0 0 0 0 0 0 1 1 0 0 Y 2134 AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 0 0 Y 2135 AT_NONCE_S 0 0 0 0 0 0 0 1 0 0 0 Y 2136 AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 0 0 N 2137 AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 0 0 N 2139 It should be noted that attributes AT_PERMANENT_ID_REQ, 2140 AT_ANY_ID_REQ and AT_FULLAUTH_ID_REQ are mutually exclusive, so that 2141 only one of them can be included at the same time. If one of the 2142 attributes AT_IV and AT_ENCR_DATA is included, then both of the 2143 attributes MUST be included. 2145 7.2. AT_MAC 2147 The AT_MAC attribute is used for EAP/AKA message authentication. 2148 Section 6 specifies which messages AT_MAC MUST be included. 2150 The value field of the AT_MAC attribute contains two reserved bytes 2151 followed by a keyed message authentication code (MAC). The MAC is 2152 calculated over the whole EAP packet, concatenated with optional 2153 message-specific data, with the exception that the value field of 2154 the MAC attribute is set to zero when calculating the MAC. The EAP 2155 packet includes the EAP header that begins with the Code field, the 2156 EAP/AKA header that begins with the Subtype field, and all the 2157 attributes, as specified in Section 5.1. The reserved bytes in 2158 AT_MAC are set to zero when sending and ignored on reception. The 2159 contents of the message-specific data that may be included in the 2160 MAC calculation are specified separately for each EAP/AKA message in 2161 Section 6. 2163 The format of the AT_MAC attribute is shown below. 2165 EAP AKA Authentication 27 October, 2003 2167 0 1 2 3 2168 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 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | AT_MAC | Length = 5 | Reserved | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | | 2173 | MAC | 2174 | | 2175 | | 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 The MAC algorithm is HMAC-SHA1-128 [RFC 2104] keyed hash value. (The 2179 HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by 2180 truncating the output to 16 bytes. Hence, the length of the MAC is 2181 16 bytes.) The derivation of the authentication key (K_aut) used in 2182 the calculation of the MAC is specified in Section 4.5. 2184 When the AT_MAC attribute is included in an EAP/AKA message, the 2185 recipient MUST process the AT_MAC attribute before looking at any 2186 other attributes. If the message authentication code is invalid, 2187 then the recipient MUST ignore all other attributes in the message 2188 and operate as specified in Section 4.4. 2190 7.3. AT_IV, AT_ENCR_DATA and AT_PADDING 2192 AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted 2193 information between the EAP/SIM peer and server. 2195 The value field of AT_IV contains two reserved bytes followed by a 2196 16-byte initialization vector required by the AT_ENCR_DATA 2197 attribute. The reserved bytes are set to zero when sending and 2198 ignored on reception. The AT_IV attribute MUST be included if and 2199 only if the AT_ENCR_DATA is included. Section 4.4 specifies the 2200 operation if a packet that does not meet this condition is 2201 encountered. 2203 The sender of the AT_IV attribute chooses the initialization vector 2204 by random. The sender MUST NOT reuse the initialization vector value 2205 from previous EAP AKA packets and the sender MUST choose it freshly 2206 for each AT_IV attribute. The sender SHOULD use a good source of 2207 randomness to generate the initialization vector. Please see [RFC 2208 1750] for more information about generating random numbers for 2209 security applications. The format of AT_IV is shown below. 2211 EAP AKA Authentication 27 October, 2003 2213 0 1 2 3 2214 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 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 | AT_IV | Length = 5 | Reserved | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | | 2219 | Initialization Vector | 2220 | | 2221 | | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 The value field of the AT_ENCR_DATA attribute consists of two 2225 reserved bytes followed by cipher text bytes encrypted using the 2226 Advanced Encryption Standard (AES) [AES] in the Cipher Block 2227 Chaining (CBC) mode of operation using the initialization vector 2228 from the AT_IV attribute. The reserved bytes are set to zero when 2229 sending and ignored on reception. Please see [CBC] for a description 2230 of the CBC mode. The format of the AT_ENCR_DATA attribute is shown 2231 below. 2233 0 1 2 3 2234 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 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | AT_ENCR_DATA | Length | Reserved | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | | 2239 . Encrypted Data . 2240 . . 2241 | | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 The derivation of the encryption key (K_encr) is specified in 2245 Section 4.5. 2247 The plaintext consists of nested EAP/AKA attributes. 2249 The encryption algorithm requires the length of the plaintext to be 2250 a multiple of 16 bytes. The sender may need to include the 2251 AT_PADDING attribute as the last attribute within AT_ENCR_DATA. The 2252 AT_PADDING attribute is not included if the total length of other 2253 nested attributes within the AT_ENCR_DATA attribute is a multiple of 2254 16 bytes. As usual, the Length of the Padding attribute includes the 2255 Attribute Type and Attribute Length fields. The length of the 2256 Padding attribute is 4, 8 or 12 bytes. It is chosen so that the 2257 length of the value field of the AT_ENCR_DATA attribute becomes a 2258 multiple of 16 bytes. The actual pad bytes in the value field are 2259 set to zero (0x00) on sending. The recipient of the message MUST 2260 verify that the pad bytes are set to zero. If this verification 2261 fails on the peer, then it MUST send the EAP-Response/AKA-Client- 2262 Error packet with the error code "unable to process packet" to 2263 terminate the authentication exchange. If this verification fails on 2264 the server, then the server sends EAP Failure, and the 2265 authentication exchange terminates. The format of the AT_PADDING 2266 attribute is shown below. 2268 EAP AKA Authentication 27 October, 2003 2270 0 1 2 3 2271 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 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | AT_PADDING | Length | Padding... | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2275 | | 2276 | | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 7.4. AT_CHECKCODE 2281 The AT_MAC attribute is not used in the very first EAP/AKA messages 2282 during the AKA-Identity round, because keying material has not been 2283 derived yet. The peer and the server may exchange one or more pairs 2284 of EAP/AKA messages of the Subtype AKA-Identity before keys are 2285 derived and before the AT_MAC attribute can be applied. The EAP/AKA- 2286 Identity messages may also be used upon re-authentication. 2288 The AT_CHECKCODE attribute MAY be used to protect the EAP/AKA- 2289 Identity messages. AT_CHECKCODE is included in EAP-Request/AKA- 2290 Challenge and/or EAP-Response/AKA-Challenge upon full 2291 authentication. In re-authentication, AT_CHECKCODE MAY be included 2292 in EAP-Request/AKA-Reauthentication and/or EAP-Response/AKA- 2293 Reauthentication. Because the AT_MAC attribute is used in these 2294 messages, AT_CHECKCODE will be integrity protected with AT_MAC. 2295 The format of the AT_CHECKCODE attribute is shown below. 2297 0 1 2 3 2298 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 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | AT_CHECKCODE | Length | Reserved | 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2302 | | 2303 | Checkcode (0 or 20 bytes) | 2304 | | 2305 | | 2306 | | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 The value field of AT_CHECKCODE begins with two reserved bytes, 2310 which may be followed by a 20-byte checkcode. If the checkcode is 2311 not included in AT_CHECKCODE, then the attribute indicates that no 2312 EAP/AKA-Identity messages were exchanged. This may occur in both 2313 full authentication and re-authentication. The reserved bytes are 2314 set to zero when sending and ignored on reception. 2316 The checkcode is a hash value, calculated with SHA1 [SHA-1], over 2317 all EAP-Request/AKA-Identity and EAP-Response/ AKA-Identity packets 2318 exchanged in this authentication exchange. The packets are included 2319 in the order that they were transmitted, that is, starting with the 2320 first EAP-Request/ AKA-Identity message, followed by the 2322 EAP AKA Authentication 27 October, 2003 2324 corresponding EAP-Response/ AKA-Identity, followed by the second 2325 EAP-Request/ AKA-Identity (if used) etc. 2327 EAP packets are included in the hash calculation "as-is", as they 2328 were transmitted or received. All reserved bytes, padding bytes etc. 2329 that are specified for various attributes are included as such, and 2330 the receiver must not reset them to zero. No delimiter bytes, 2331 padding or any other framing are included between the EAP packets 2332 when calculating the checkcode. 2334 Messages are included in request/response pairs; in other words only 2335 full "round trips" are included. Packets that are silently discarded 2336 are not included. The EAP server must only include an EAP- 2337 Request/AKA-Identity in the calculation once it has received a 2338 corresponding response, with the same Identifier value. 2339 Retransmissions or requests to which the server does not receive 2340 response are not included. 2342 The peer must include the EAP-Request/AKA-Identity and the 2343 corresponding response in the calculation only if the peer receives 2344 a subsequent EAP-Request/AKA-Challenge, or a follow-up EAP- 2345 Request/AKA-Identity with different attributes (attribute types) 2346 than in the first EAP-Request/AKA-Identity. After sending EAP- 2347 Response/AKA-Identity, if the peer receives another EAP-Request/AKA- 2348 Identity with the same attributes as in the previous request, then 2349 the peer's response to the first request must have been lost. In 2350 this case the peer must not include the first request and its 2351 response in the calculation of the checkcode. 2353 The AT_CHECKCODE attribute is optional to implement. It is specified 2354 in order to allow protecting the EAP/ AKA-Identity messages and any 2355 future extensions to them. The implementation of AT_CHECKCODE is 2356 RECOMMENDED. 2358 If the receiver of AT_CHECKCODE implements this attribute, then the 2359 receiver MUST check that the checkcode is correct. If the checkcode 2360 is invalid, the receiver must operate as specified in Section 4.4. 2362 If the EAP/AKA-Identity messages are extended with new attributes 2363 then AT_CHECKCODE MUST be implemented and used. More specifically, 2364 if the server includes any other attributes than 2365 AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ or AT_ANY_ID_REQ in the EAP- 2366 Request/AKA-Identity packet, then the server MUST include 2367 AT_CHECKCODE in EAP-Request/AKA-Challenge or EAP-Request/AKA- 2368 Reauthentication. If the peer includes any other attributes than 2369 AT_IDENTITY in the EAP-Response/AKA-Identity message, then the peer 2370 MUST include AT_CHECKCODE in EAP-Response/AKA-Challenge or EAP- 2371 Response/AKA-Reauthentication. 2373 If the server implements the processing of any other attribute than 2374 AT_IDENTITY for the EAP-Response/AKA-Identity message, then the 2375 server MUST implement AT_CHECKCODE. In this case, if the server 2376 receives any other attribute than AT_IDENTITY in the EAP- 2377 Response/AKA-Identity message, then the server MUST check that 2379 EAP AKA Authentication 27 October, 2003 2381 AT_CHECKCODE is present in EAP-Response/AKA-Challenge or EAP- 2382 Response/AKA-Reauthentication. The operation when a mandatory 2383 attribute is missing is specified in Section 4.4. 2385 Similarly, if the peer implements the processing of any other 2386 attribute than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ or 2387 AT_ANY_ID_REQ for the EAP-Request/AKA-Identity packet, then the peer 2388 MUST implement AT_CHECKCODE. In this case, if the peer receives any 2389 other attribute than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ or 2390 AT_ANY_ID_REQ in the EAP-Request/AKA-Identity packet, then the peer 2391 MUST check that AT_CHECKCODE is present in EAP-Request/AKA-Challenge 2392 or EAP-Request/AKA-Reauthentication. The operation when a mandatory 2393 attribute is missing is specified in Section 4.4. 2395 7.5. AT_PERMANENT_ID_REQ 2397 The format of the AT_PERMANENT_ID_REQ attribute is shown below. 2399 0 1 2 3 2400 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 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 |AT_PERM..._REQ | Length = 1 | Reserved | 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 The use of the AT_PERMANENT_ID_REQ is defined in Section 4.1. The 2406 value field only contains two reserved bytes, which are set to zero 2407 on sending and ignored on reception. 2409 7.6. AT_ANY_ID_REQ 2411 The format of the AT_ANY_ID_REQ attribute is shown below. 2413 0 1 2 3 2414 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 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 |AT_ANY_ID_REQ | Length = 1 | Reserved | 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 The use of the AT_ANY_ID_REQ is defined in Section 4.1. The value 2420 field only contains two reserved bytes, which are set to zero on 2421 sending and ignored on reception. 2423 7.7. AT_FULLAUTH_ID_REQ 2425 The format of the AT_FULLAUTH_ID_REQ attribute is shown below. 2427 0 1 2 3 2428 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 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 |AT_ANY_ID_REQ | Length = 1 | Reserved | 2431 +---------------+---------------+-------------------------------+ 2433 EAP AKA Authentication 27 October, 2003 2435 The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.1. The 2436 value field only contains two reserved bytes, which are set to zero 2437 on sending and ignored on reception. 2439 7.8. AT_IDENTITY 2441 The format of the AT_IDENTITY attribute is shown below. 2443 0 1 2 3 2444 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 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 | AT_IDENTITY | Length | Actual Identity Length | 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | | 2449 . Identity . 2450 . . 2451 | | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2454 The use of the AT_IDENTITY is defined in Section 4.1. The value 2455 field of this attribute begins with 2-byte actual identity length, 2456 which specifies the length of the identity in bytes. This field is 2457 followed by the subscriber identity of the indicated actual length. 2458 The identity is the permanent identity, a pseudonym identity or a 2459 re-authentication identity. The identity format is specified in 2460 Section 4.1.1. The same identity format is used in the AT_IDENTITY 2461 attribute and the EAP-Response/Identity packet, with the exception 2462 that the peer MUST NOT decorate the identity it includes in 2463 AT_IDENTITY. The identity does not include any terminating null 2464 characters. Because the length of the attribute must be a multiple 2465 of 4 bytes, the sender pads the identity with zero bytes when 2466 necessary. 2468 7.9. AT_RAND 2470 The format of the AT_RAND attribute is shown below. 2472 0 1 2 3 2473 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 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 | AT_RAND | Length = 5 | Reserved | 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 | | 2478 | RAND | 2479 | | 2480 | | 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 The value field of this attribute contains two reserved bytes 2484 followed by the AKA RAND parameter, 16 bytes (128 bits). The 2485 reserved bytes are set to zero when sending and ignored on 2486 reception. 2488 EAP AKA Authentication 27 October, 2003 2490 7.10. AT_AUTN 2492 The format of the AT_AUTN attribute is shown below. 2494 0 1 2 3 2495 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 2496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2497 | AT_AUTN | Length = 5 | Reserved | 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 | | 2500 | AUTN | 2501 | | 2502 | | 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 The value field of this attribute contains two reserved bytes 2506 followed by the AKA AUTN parameter, 16 bytes (128 bits). The 2507 reserved bytes are set to zero when sending and ignored on 2508 reception. 2510 7.11. AT_RES 2512 The format of the AT_RES attribute is shown below. 2514 0 1 2 3 2515 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 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 | AT_RES | Length | RES Length | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2519 | | 2520 | RES | 2521 | | 2522 | | 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 The value field of this attribute begins with the 2-byte RES Length, 2526 which is identifies the exact length of the RES in bits. The RES 2527 length is followed by the UMTS AKA RES parameter. According to [TS 2528 33.105] the length of the AKA RES can vary between 32 and 128 bits. 2529 Because the length of the AT_RES attribute must be a multiple of 4 2530 bytes, the sender pads the RES with zero bits where necessary. 2532 7.12. AT_AUTS 2534 The format of the AT_AUTS attribute is shown below. 2536 EAP AKA Authentication 27 October, 2003 2538 0 1 2 3 2539 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 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 2541 | AT_AUTS | Length = 4 | | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2543 | | 2544 | AUTS | 2545 | | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2548 The value field of this attribute contains the AKA AUTS parameter, 2549 112 bits (14 bytes). 2551 7.13. AT_NEXT_PSEUDONYM 2553 The format of the AT_NEXT_PSEUDONYM attribute is shown below. 2555 0 1 2 3 2556 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 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | AT_NEXT_PSEU..| Length | Actual Pseudonym Length | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | | 2561 . Next Pseudonym . 2562 . . 2563 | | 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 The value field of this attribute begins with 2-byte actual 2567 pseudonym length which specifies the length of the following 2568 pseudonym in bytes. This field is followed by a pseudonym username 2569 that the peer can use in the next authentication. The username MUST 2570 NOT include any realm portion. The username does not include any 2571 terminating null characters. Because the length of the attribute 2572 must be a multiple of 4 bytes, the sender pads the pseudonym with 2573 zero bytes when necessary. The username encoding MUST follow the 2574 UTF-8 transformation format [RFC2279]. 2576 7.14. AT_NEXT_REAUTH_ID 2578 The format of the AT_NEXT_REAUTH_ID attribute is shown below. 2580 0 1 2 3 2581 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 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length| 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 | | 2586 . Next Re-authentication Username . 2587 . . 2588 | | 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 EAP AKA Authentication 27 October, 2003 2593 The value field of this attribute begins with 2-byte actual re- 2594 authentication identity length which specifies the length of the 2595 following re-authentication identity in bytes. This field is 2596 followed by a re-authentication identity that the peer can use in 2597 the next re-authentication, as described in Section 4.2. In 2598 environments where a realm portion is required, the re- 2599 authentication identity includes both a username portion and a realm 2600 name portion. The re-authentication identity does not include any 2601 terminating null characters. Because the length of the attribute 2602 must be a multiple of 4 bytes, the sender pads the re-authentication 2603 identity with zero bytes when necessary. The identity encoding MUST 2604 follow the UTF-8 transformation format [RFC2279]. 2606 7.15. AT_COUNTER 2608 The format of the AT_COUNTER attribute is shown below. 2610 0 1 2 3 2611 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 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 | AT_COUNTER | Length = 1 | Counter | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 The value field of the AT_COUNTER attribute consists of a 16-bit 2617 unsigned integer counter value, represented in network byte order. 2619 7.16. AT_COUNTER_TOO_SMALL 2621 The format of the AT_COUNTER_TOO_SMALL attribute is shown below. 2623 0 1 2 3 2624 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 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 | AT_COUNTER...| Length = 1 | Reserved | 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2629 The value field of this attribute consists of two reserved bytes, 2630 which are set to zero upon sending and ignored upon reception. 2632 7.17. AT_NONCE_S 2634 The format of the AT_NONCE_S attribute is shown below. 2636 EAP AKA Authentication 27 October, 2003 2638 0 1 2 3 2639 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 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | AT_COUNTER | Length = 1 | Counter | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | AT_NONCE_S | Length = 5 | Reserved | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 | | 2646 | | 2647 | NONCE_S | 2648 | | 2649 | | 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2652 The value field of the AT_NONCE_S attribute contains two reserved 2653 bytes followed by a random number generated by the server (16 bytes) 2654 freshly for this EAP/AKA re-authentication. The random number is 2655 used as challenge for the peer and also a seed value for the new 2656 keying material. The reserved bytes are set to zero upon sending and 2657 ignored upon reception. 2659 The server MUST choose the NONCE_S value freshly for each EAP/AKA 2660 re-authentication exchange. The server SHOULD use a good source of 2661 randomness to generate NONCE_S. Please see [RFC 1750] for more 2662 information about generating random numbers for security 2663 applications. 2665 7.18. AT_NOTIFICATION 2667 The format of the AT_NOTIFICATION attribute is shown below. 2669 0 1 2 3 2670 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 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 |AT_NOTIFICATION| Length = 1 |F|P| Notification Code | 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 The value field of this attribute contains a two-byte notification 2676 code. The first and second bit (F and P) of the notification code 2677 are interpreted as described in Section 4.3. 2679 The notification code values listed below have been reserved. The 2680 descriptions below illustrate the semantics of the notifications. 2681 The peer implementation MAY use different wordings when presenting 2682 the notifications to the user. The "requested service" depends on 2683 the environment where EAP/AKA is applied. 2685 1026 - User has been temporarily denied access to the requested 2686 service. (Implies failure, used after the challenge round) 2688 1031 - User has not subscribed to the requested service (implies 2689 failure, used after the challenge round) 2691 EAP AKA Authentication 27 October, 2003 2693 7.19. AT_CLIENT_ERROR_CODE 2695 The format of the AT_CLIENT_ERROR_CODE attribute is shown below. 2697 0 1 2 3 2698 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 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 |AT_CLIENT_ERR..| Length = 1 | Client Error Code | 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 The value field of this attribute contains a two-byte client error 2704 code. The following error code values have been reserved. 2706 0 "unable to process packet": a general error code 2708 8. IANA and Protocol Numbering Considerations 2710 The realm name "owlan.org" has been reserved for NAI realm names 2711 generated from the IMSI. 2713 IANA has assigned the number 23 for EAP AKA authentication. 2715 EAP AKA messages include a Subtype field. The following Subtypes are 2716 specified: 2718 AKA-Challenge...................................1 2719 AKA-Authentication-Reject.......................2 2720 AKA-Synchronization-Failure.....................4 2721 AKA-Identity....................................5 2722 AKA-Notification...............................12 2723 AKA-Reauthentication...........................13 2724 AKA-Client-Error...............................14 2726 EAP AKA Authentication 27 October, 2003 2728 The Subtype-specific data is composed of attributes, which have 2729 attribute type numbers. The following attribute types are specified: 2731 AT_RAND.........................................1 2732 AT_AUTN.........................................2 2733 AT_RES..........................................3 2734 AT_AUTS.........................................4 2735 AT_PADDING......................................6 2736 AT_PERMANENT_ID_REQ............................10 2737 AT_MAC.........................................11 2738 AT_NOTIFICATION................................12 2739 AT_ANY_ID_REQ..................................13 2740 AT_IDENTITY....................................14 2741 AT_FULLAUTH_ID_REQ.............................17 2742 AT_COUNTER.....................................19 2743 AT_COUNTER_TOO_SMALL...........................20 2744 AT_NONCE_S.....................................21 2745 AT_CLIENT_ERROR_CODE...........................22 2747 AT_IV.........................................129 2748 AT_ENCR_DATA..................................130 2749 AT_NEXT_PSEUDONYM.............................132 2750 AT_NEXT_REAUTH_ID.............................133 2751 AT_CHECKCODE..................................134 2753 The AT_NOTIFICATION attribute contains a notification code value. 2754 Values 1024, 1026 and 1031 have been specified in Section 7.18 of 2755 this document. 2757 The AT_CLIENT_ERROR_CODE attribute contains a client error code. 2758 Value 0 has been specified in Section 7.19 of this document. 2760 All requests for value assignment from the various number spaces 2761 described in this document require proper documentation, according 2762 to the "Specification Required" policy described in [RFC 2434]. 2763 Requests must be specified in sufficient detail so that 2764 interoperability between independent implementations is possible. 2765 Possible forms of documentation include, but are not limited to, 2766 RFCs, the products of another standards body (e.g. 3GPP), or 2767 permanently and readily available vendor design notes. 2769 EAP AKA and EAP SIM [EAP SIM] are "sister" protocols with similar 2770 message structure and protocol numbering spaces. Many attributes and 2771 message Subtypes have the same protocol numbers in these two 2772 protocols. Hence, it is recommended that the same protocol number 2773 value SHOULD NOT be allocated for two different purposes in EAP AKA 2774 and EAP SIM. 2776 9. Security Considerations 2778 The EAP base protocol specification [EAP] highlights several attacks 2779 that are possible against the EAP protocol. This section discusses 2781 EAP AKA Authentication 27 October, 2003 2783 the claimed security properties of EAP AKA as well as 2784 vulnerabilities and security recommendations. 2786 9.1. Identity Protection 2788 EAP/AKA includes optional Identity privacy support that protects the 2789 privacy of the subscriber identity against passive eavesdropping. 2790 The mechanism cannot be used on the first exchange with a given 2791 server, when the IMSI will have to be sent in the clear. The 2792 terminal SHOULD store the pseudonym in a non-volatile memory so that 2793 it can be maintained across reboots. An active attacker that 2794 impersonates the network may use the AT_PERMANENT_ID_REQ attribute 2795 (Section 1.1) to learn the subscriber's IMSI. However, as discussed 2796 in Section 1.1, the terminal can refuse to send the cleartext IMSI 2797 if it believes that the network should be able to recognize the 2798 pseudonym. 2800 If the peer and server cannot guarantee that the pseudonym will be 2801 maintained reliably and Identity privacy is required then additional 2802 protection from an external security mechanism such as Protected 2803 Extensible Authentication Protocol (PEAP) [PEAP] may be used. The 2804 benefits and the security considerations of using an external 2805 security mechanism with EAP/AKA are beyond the scope of this 2806 document. 2808 9.2. Mutual Authentication 2810 EAP/AKA provides mutual authentication via the UMTS AKA mechanisms. 2812 9.3. Key Derivation 2814 EAP/AKA supports key derivation with 128-bit effective key strength. 2815 The key hierarchy is specified in Section 0. 2817 The Transient EAP Keys used to protect EAP AKA packets (K_encr, 2818 K_aut) and the Master Session Keys are cryptographically separate. 2819 An attacker cannot derive any non-trivial information from K_encr or 2820 K_aut based on the Master Session Key or vice versa. An attacker 2821 also cannot calculate the pre-shared secret from the UMTS AKA IK, 2822 UMTS AKA CK, EAP AKA K_encr, EAP AKA K_aut or from the Master 2823 Session Key. 2825 9.4. Brute-Force and Dictionary Attacks 2827 The effective strength of EAP/AKA values is 128 bits, and there are 2828 no known computationally feasible brute-force attacks. Because UMTS 2829 AKA is not a password protocol (the pre-shared secret must not be a 2830 weak password), EAP/AKA is not vulnerable to dictionary attacks. 2832 9.5. Integrity Protection, Replay Protection and Confidentiality 2834 AT_MAC, AT_IV and AT_ENCR_DATA attributes are used to provide 2835 integrity, replay and confidentiality protection for EAP/AKA 2836 Requests and Responses. Integrity protection includes the EAP 2838 EAP AKA Authentication 27 October, 2003 2840 header. Integrity protection (AT_MAC) is based on a keyed message 2841 authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is 2842 based on a block cipher. 2844 Because keys are not available in the beginning of the EAP methods, 2845 the AT_MAC attribute cannot be used for protecting EAP/AKA-Identity 2846 messages. However, the AT_CHECKCODE attribute can optionally be used 2847 to protect the integrity of the EAP/AKA-Identity roundtrip. 2849 On full authentication, replay protection is provided by RAND and 2850 AUTN values from the underlying UMTS AKA scheme. On re- 2851 authentication, a counter and a server nonce is used to provide 2852 replay protection. 2853 The contents of the EAP-Response/Identity packet are implicitly 2854 integrity protected by including them in key derivation. 2856 Because EAP/AKA is not a tunneling method, EAP Notification, EAP 2857 Success or EAP Failure packets are not confidential, integrity 2858 protected or replay protected. On physically insecure networks, this 2859 may enable an attacker to mount denial of service attacks by sending 2860 false EAP Notification, EAP Success or EAP Failure packets. However, 2861 the attacker cannot force the peers to believe successful 2862 authentication has occurred when mutual authentication failed or has 2863 not happened yet. 2865 An eavesdropper will see the EAP Notification, EAP Success and EAP 2866 Failure packets sent in the clear. With EAP AKA, confidential 2867 information MUST NOT be transmitted in EAP Notification packets. 2869 9.6. Negotiation Attacks 2871 EAP/AKA does not protect the EAP-Response/Nak packet. Because 2872 EAP/AKA does not protect the EAP method negotiation, EAP method 2873 downgrading attacks may be possible, especially if the user uses the 2874 same identity with EAP/AKA and other EAP methods. 2876 As described in Section 5, EAP/AKA allows the protocol to be 2877 extended by defining new attribute types. When defining such 2878 attributes, it should be noted that any extra attributes included in 2879 EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are 2880 not included in the MACs later on, and thus some other precautions 2881 must be taken to avoid modifications to them. 2883 EAP/AKA does not support ciphersuite negotiation or EAP/AKA protocol 2884 version negotiation. 2886 9.7. Fast Reconnect 2888 EAP/AKA includes an optional re-authentication ("fast reconnect") 2889 procedure, as recommended in [EAP] for EAP types that are intended 2890 for physically insecure networks. 2892 9.8. Acknowledged Result Indications 2894 EAP AKA Authentication 27 October, 2003 2896 EAP/AKA does not provide acknowledged or integrity protected Success 2897 or Failure indications. 2899 If an EAP Success or an EAP Failure packet is lost when using 2900 EAP/AKA over an unreliable medium, and if the protocol over which 2901 EAP/AKA is transported does not address the possible loss of Success 2902 or Failure, then the peer and EAP server may end up having a 2903 different interpretation of the state of the authentication 2904 conversation. 2906 On physically insecure networks, an attacker may mount denial of 2907 service attacks by sending false EAP Success or EAP Failure 2908 indications. However, the attacker cannot force the peer or the EAP 2909 server to believe successful authentication has occurred when mutual 2910 authentication failed or has not happened yet. 2912 9.9. Man-in-the-middle Attacks 2914 In order to avoid man-in-the-middle attacks and session hijacking, 2915 user data SHOULD be integrity protected on physically insecure 2916 networks. The EAP/AKA Master Session Key or keys derived from it MAY 2917 be used as the integrity protection keys, or, if an external 2918 security mechanism such as PEAP is used, then the link integrity 2919 protection keys MAY be derived by the external security mechanism. 2921 There are man-in-the-middle attacks associated with the use of any 2922 EAP method within a tunneled protocol such as PEAP, or within a 2923 sequence of EAP methods followed by each other. This specification 2924 does not address these attacks. If EAP/AKA is used with a tunneling 2925 protocol or as part of a sequence of methods, there should be 2926 cryptographic binding provided between the protocols and EAP/AKA to 2927 prevent man-in-the-middle attacks through rogue authenticators being 2928 able to setup one-way authenticated tunnels. EAP/AKA Master Session 2929 Key MAY be used to provide the cryptographic binding. However the 2930 mechanism how the binding is provided depends on the tunneling or 2931 sequencing protocol, and it is beyond the scope of this document. 2933 9.10. Generating Random Numbers 2935 An EAP/AKA implementation SHOULD use a good source of randomness to 2936 generate the random numbers required in the protocol. Please see 2937 [RFC 1750] for more information on generating random numbers for 2938 security applications. 2940 10. Security Claims 2942 This section provides the security claims required by [EAP]. 2944 [a] Intended use. EAP AKA is intended for use over both physically 2945 insecure networks and physically or otherwise secure networks. 2946 Applicable media include but are not limited to PPP, IEEE 802 wired 2947 networks and IEEE 802.11. 2949 EAP AKA Authentication 27 October, 2003 2951 [b] Mechanism. EAP AKA is based on the UMTS AKA mechanism, which is 2952 an authentication and key agreement mechanism based on a symmetric 2953 128-bit pre-shared secret. 2955 [c] Security claims. The security properties of the method are 2956 discussed in Section 9. 2958 [d] Key strength. EAP/AKA supports key derivation with 128-bit 2959 effective key strength. 2961 [e] Description of key hierarchy. Please see Section 0. 2963 [f] Indication of vulnerabilities. Vulnerabilities are discussed in 2964 Section 9. 2966 11. Intellectual Property Right Notices 2968 On IPR related issues, Nokia and Ericsson refer to the their 2969 respective statements on patent licensing. Please see 2970 http://www.ietf.org/ietf/IPR/NOKIA and 2971 http://www.ietf.org/ietf/IPR/ERICSSON-General 2973 Acknowledgements and Contributions 2975 The authors wish to thank Rolf Blom of Ericsson, Bernard Aboba of 2976 Microsoft, Arne Norefors of Ericsson, N.Asokan of Nokia, Valtteri 2977 Niemi of Nokia, Kaisa Nyberg of Nokia, Jukka-Pekka Honkanen of 2978 Nokia, Pasi Eronen of Nokia, Olivier Paridaens of Alcatel and Ilkka 2979 Uusitalo of Ericsson for interesting discussions in this problem 2980 space. 2982 The attribute format is based on the extension format of Mobile IPv4 2983 [RFC 3344]. 2985 Authors' Addresses 2987 Jari Arkko 2988 Ericsson 2989 02420 Jorvas Phone: +358 40 5079256 2990 Finland Email: jari.arkko@ericsson.com 2992 Henry Haverinen 2993 Nokia Mobile Phones 2994 P.O. Box 88 2995 33721 Tampere Phone: +358 50 594 4899 2996 Finland E-mail: henry.haverinen@nokia.com 2998 EAP AKA Authentication 27 October, 2003 3000 Annex A. Pseudo-Random Number Generator 3002 The "|" character denotes concatenation, and "^" denotes involution. 3004 Step 1: Choose a new, secret value for the seed-key, XKEY 3006 Step 2: In hexadecimal notation let 3007 t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 3008 This is the initial value for H0|H1|H2|H3|H4 3009 in the FIPS SHS [SHA-1] 3011 Step 3: For j = 0 to m - 1 do 3012 3.1 XSEED_j = 0 /* no optional user input */ 3013 3.2 For i = 0 to 1 do 3014 a. XVAL = (XKEY + XSEED_j) mod 2^b 3015 b. w_i = G(t, XVAL) 3016 c. XKEY = (1 + XKEY + w_i) mod 2^b 3017 3.3 x_j = w_0|w_1 3019 EAP AKA Authentication 27 October, 2003 3021 Normative References 3023 [TS 33.102] 3GPP Technical Specification 3GPP TS 33.102 V5.1.0: 3024 "Technical Specification Group Services and System Aspects; 3G 3025 Security; Security Architecture (Release 5)", 3rd Generation 3026 Partnership Project, December 2002. 3028 [RFC 2486] Aboba, B. and M. Beadles, "The Network Access 3029 Identifier", RFC 2486, January 1999. 3031 [EAP] L. Blunk et al., "Extensible Authentication Protocol (EAP)", 3032 draft-ietf-eap-rfc2284bis-05.txt, work-in-progress, September 2003. 3034 [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate 3035 Requirement Levels", RFC 2119, March 1997. 3037 [TS 23.003] 3GPP Technical Specification 3GPP TS 23.003 V5.5.1: "3rd 3038 Generation Parnership Project; Technical Specification Group Core 3039 Network; Numbering, addressing and identification (Release 5)", 3rd 3040 Generation Partnership Project, January 2003 3042 [RFC 2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 3043 for Message Authentication", RFC2104, February 1997. 3045 [SHA-1] Federal Information Processing Standard (FIPS) Publication 3046 180-1, "Secure Hash Standard," National Institute of Standards and 3047 Technology, U.S. Department of Commerce, April 17, 1995. 3049 [AES] Federal Information Processing Standards (FIPS) Publication 3050 197, "Advanced Encryption Standard (AES)", National Institute of 3051 Standards and Technology, November 26, 2001. 3052 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 3054 [CBC] NIST Special Publication 800-38A, "Recommendation for Block 3055 Cipher Modes of Operation - Methods and Techniques", National 3056 Institute of Standards and Technology, December 2001. 3057 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf 3059 [TS 33.105] 3GPP Technical Specification 3GPP TS 33.105 4.1.0: 3060 "Technical Specification Group Services and System Aspects; 3G 3061 Security; Cryptographic Algorithm Requirements (Release 4)", 3rd 3062 Generation Partnership Project, June 2001 3064 [PRF] Federal Information Processing Standards (FIPS) Publication 3065 186-2 (with change notice), "Digital Signature Standard (DSS)", 3066 National Institute of Standards and Technology, January 27, 2000 3067 Available on-line at: 3068 http://csrc.nist.gov/publications/fips/fips186-2/fips186-2- 3069 change1.pdf 3071 EAP AKA Authentication 27 October, 2003 3073 [RFC 2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 3074 Considerations Section in RFCs", RFC 2434, October 1998. 3076 Informative References 3078 [RFC 2548] G. Zorn, "Microsoft Vendor-specific RADIUS Attributes", 3079 RFC 2548, March 1999 3081 [PEAP] H. Andersson, S. Josefsson, G. Zorn, D. Simon, A. Palekar, 3082 "Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap- 3083 05.txt, work-in-progress, September 2002. 3085 [RFC 1750] D. Eastlake, 3rd, S. Crocker, J. Schiller, "Randomness 3086 Recommendations for Security", RFC 1750 (Informational), December 3087 1994. 3089 [RFC 3344] C. Perkins (editor), "IP Mobility Support", RFC 3344, 3090 August 2002. 3092 [EAP SIM] H. Haverinen, J. Salowey, "EAP SIM Authentication", draft- 3093 haverinen-pppext-eap-sim-12.txt, October 2003, work in progress 3095 [TS 23.234] Draft 3GPP Technical Specification 3GPP TS 23.234 V 3096 1.4.0: "Technical Specification Group Services and System Aspects; 3097 3GPP system to Wireless Local Area Network (WLAN) Interworking; 3098 System Description", 3rd Generation Partnership Project, work in 3099 progress, January 2003.