idnits 2.17.00 (12 Aug 2021) /tmp/idnits53646/draft-arkko-pppext-eap-aka-12.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 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.) ** There are 15 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 548 has weird spacing: '...tor and help ...' == Line 1590 has weird spacing: '...d after a suc...' == Line 1733 has weird spacing: '...-Reject packe...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 5, 2004) is 6619 days in the past. Is this intentional? -- 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) ** 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. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PRF' ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-07 -- 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: 7 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Arkko 2 Internet-Draft Ericsson 3 Expires: October 4, 2004 H. Haverinen 4 Nokia 5 April 5, 2004 7 Extensible Authentication Protocol Method for UMTS Authentication and 8 Key Agreement (EAP-AKA) 9 draft-arkko-pppext-eap-aka-12.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 4, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document specifies an Extensible Authentication Protocol (EAP) 40 mechanism for authentication and session key distribution using the 41 Universal Mobile Telecommunications System (UMTS) Authentication and 42 Key Agreement (AKA) mechanism. UMTS AKA is based on symmetric keys, 43 and runs typically in a UMTS Subscriber Identity Module, a smart card 44 like device. 46 EAP-AKA includes optional identity privacy support, optional result 47 indications, and an optional fast re-authentication procedure. 49 Table of Contents 51 1. Introduction and Motivation . . . . . . . . . . . . . . . . 4 52 2. Terms and Conventions Used in This Document . . . . . . . . 5 53 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 8 54 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 12 55 4.1 Identity Management . . . . . . . . . . . . . . . . . . . . 13 56 4.1.1 Format, Generation and Usage of Peer Identities . . . . . . 13 57 4.1.2 Communicating the Peer Identity to the Server . . . . . . . 19 58 4.1.3 Message Sequence Examples (Informative) . . . . . . . . . . 24 59 4.2 Fast Re-authentication . . . . . . . . . . . . . . . . . . . 30 60 4.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . 30 61 4.2.2 Comparison to UMTS AKA . . . . . . . . . . . . . . . . . . . 31 62 4.2.3 Fast Re-authentication Identity . . . . . . . . . . . . . . 32 63 4.2.4 Fast Re-authentication Procedure . . . . . . . . . . . . . . 33 64 4.2.5 Fast Re-authentication Procedure when Counter is Too 65 Small . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 66 4.3 EAP-AKA Notifications . . . . . . . . . . . . . . . . . . . 37 67 4.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . 37 68 4.3.2 Result Indications . . . . . . . . . . . . . . . . . . . . . 38 69 4.4 Error Cases . . . . . . . . . . . . . . . . . . . . . . . . 39 70 4.4.1 Peer Operation . . . . . . . . . . . . . . . . . . . . . . . 39 71 4.4.2 Server Operation . . . . . . . . . . . . . . . . . . . . . . 40 72 4.4.3 EAP-Failure . . . . . . . . . . . . . . . . . . . . . . . . 40 73 4.4.4 EAP-Success . . . . . . . . . . . . . . . . . . . . . . . . 41 74 4.5 Key Generation . . . . . . . . . . . . . . . . . . . . . . . 42 75 5. Message Format and Protocol Extensibility . . . . . . . . . 44 76 5.1 Message Format . . . . . . . . . . . . . . . . . . . . . . . 44 77 5.2 Protocol Extensibility . . . . . . . . . . . . . . . . . . . 45 78 6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 46 79 6.1 EAP-Request/AKA-Identity . . . . . . . . . . . . . . . . . . 46 80 6.2 EAP-Response/AKA-Identity . . . . . . . . . . . . . . . . . 46 81 6.3 EAP-Request/AKA-Challenge . . . . . . . . . . . . . . . . . 47 82 6.4 EAP-Response/AKA-Challenge . . . . . . . . . . . . . . . . . 47 83 6.5 EAP-Response/AKA-Authentication-Reject . . . . . . . . . . . 48 84 6.6 EAP-Response/AKA-Synchronization-Failure . . . . . . . . . . 48 85 6.7 EAP-Request/AKA-Reauthentication . . . . . . . . . . . . . . 49 86 6.8 EAP-Response/AKA-Reauthentication . . . . . . . . . . . . . 49 87 6.9 EAP-Response/AKA-Client-Error . . . . . . . . . . . . . . . 50 88 6.10 EAP-Request/AKA-Notification . . . . . . . . . . . . . . . . 50 89 6.11 EAP-Response/AKA-Notification . . . . . . . . . . . . . . . 50 90 7. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 51 91 7.1 Table of Attributes . . . . . . . . . . . . . . . . . . . . 51 92 7.2 AT_PERMANENT_ID_REQ . . . . . . . . . . . . . . . . . . . . 52 93 7.3 AT_ANY_ID_REQ . . . . . . . . . . . . . . . . . . . . . . . 52 94 7.4 AT_FULLAUTH_ID_REQ . . . . . . . . . . . . . . . . . . . . . 53 95 7.5 AT_IDENTITY . . . . . . . . . . . . . . . . . . . . . . . . 53 96 7.6 AT_RAND . . . . . . . . . . . . . . . . . . . . . . . . . . 54 97 7.7 AT_AUTN . . . . . . . . . . . . . . . . . . . . . . . . . . 54 98 7.8 AT_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 99 7.9 AT_AUTS . . . . . . . . . . . . . . . . . . . . . . . . . . 55 100 7.10 AT_NEXT_PSEUDONYM . . . . . . . . . . . . . . . . . . . . . 55 101 7.11 AT_NEXT_REAUTH_ID . . . . . . . . . . . . . . . . . . . . . 56 102 7.12 AT_IV, AT_ENCR_DATA and AT_PADDING . . . . . . . . . . . . . 56 103 7.13 AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . . . . . 58 104 7.14 AT_RESULT_IND . . . . . . . . . . . . . . . . . . . . . . . 60 105 7.15 AT_MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 106 7.16 AT_COUNTER . . . . . . . . . . . . . . . . . . . . . . . . . 62 107 7.17 AT_COUNTER_TOO_SMALL . . . . . . . . . . . . . . . . . . . . 62 108 7.18 AT_NONCE_S . . . . . . . . . . . . . . . . . . . . . . . . . 62 109 7.19 AT_NOTIFICATION . . . . . . . . . . . . . . . . . . . . . . 63 110 7.20 AT_CLIENT_ERROR_CODE . . . . . . . . . . . . . . . . . . . . 64 111 8. IANA and Protocol Numbering Considerations . . . . . . . . . 64 112 9. Security Considerations . . . . . . . . . . . . . . . . . . 66 113 9.1 Identity Protection . . . . . . . . . . . . . . . . . . . . 66 114 9.2 Mutual Authentication . . . . . . . . . . . . . . . . . . . 66 115 9.3 Flooding the Authentication Centre . . . . . . . . . . . . . 66 116 9.4 Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 67 117 9.5 Brute-Force and Dictionary Attacks . . . . . . . . . . . . . 67 118 9.6 Protection, Replay Protection and Confidentiality . . . . . 67 119 9.7 Negotiation Attacks . . . . . . . . . . . . . . . . . . . . 68 120 9.8 Protected Result Indications . . . . . . . . . . . . . . . . 68 121 9.9 Man-in-the-middle Attacks . . . . . . . . . . . . . . . . . 69 122 9.10 Generating Random Numbers . . . . . . . . . . . . . . . . . 69 123 10. Security Claims . . . . . . . . . . . . . . . . . . . . . . 69 124 11. Acknowledgements and Contributions . . . . . . . . . . . . . 70 125 Normative References . . . . . . . . . . . . . . . . . . . . 71 126 Informative References . . . . . . . . . . . . . . . . . . . 72 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 73 128 A. Pseudo-Random Number Generator . . . . . . . . . . . . . . . 73 129 Intellectual Property and Copyright Statements . . . . . . . 74 131 1. Introduction and Motivation 133 This document specifies an Extensible Authentication Protocol (EAP) 134 mechanism for authentication and session key distribution using the 135 UMTS AKA authentication mechanism [TS 33.102]. UMTS is a global third 136 generation mobile network standard. 138 AKA is based on challenge-response mechanisms and symmetric 139 cryptography. AKA typically runs in a UMTS Subscriber Identity Module 140 (USIM). Compared to the GSM mechanism, UMTS AKA provides 141 substantially longer key lengths and mutual authentication. 143 The introduction of AKA inside EAP allows several new applications. 144 These include the following: 146 o The use of the AKA also as a secure PPP authentication method in 147 devices that already contain an USIM. 148 o The use of the third generation mobile network authentication 149 infrastructure in the context of wireless LANs 150 o Relying on AKA and the existing infrastructure in a seamless way 151 with any other technology that can use EAP. 153 AKA works in the following manner: 155 o The USIM and the home environment have agreed on a secret key 156 beforehand. 157 o The actual authentication process starts by having the home 158 environment produce an authentication vector, based on the secret 159 key and a sequence number. The authentication vector contains a 160 random part RAND, an authenticator part AUTN used for 161 authenticating the network to the USIM, an expected result part 162 XRES, a session key for integrity check IK, and a session key for 163 encryption CK. 164 o The RAND and the AUTN are delivered to the USIM. 165 o The USIM verifies the AUTN, again based on the secret key and the 166 sequence number. If this process is successful (the AUTN is valid 167 and the sequence number used to generate AUTN is within the 168 correct range), the USIM produces an authentication result, RES 169 and sends this to the home environment. 170 o The home environment verifies the correct result from the USIM. If 171 the result is correct, IK and CK can be used to protect further 172 communications between the USIM and the home environment. 174 When verifying AUTN, the USIM may detect that the sequence number the 175 network uses is not within the correct range. In this case, the USIM 176 calculates a sequence number synchronization parameter AUTS and sends 177 it to the network. AKA authentication may then be retried with a new 178 authentication vector generated using the synchronized sequence 179 number. 181 For a specification of the AKA mechanisms and how the cryptographic 182 values AUTN, RES, IK, CK and AUTS are calculated, see [TS 33.102]. 184 In EAP-AKA, the EAP server node obtains the authentication vectors, 185 compares RES and XRES, and uses CK and IK in key derivation. 187 In the third generation mobile networks, AKA is used both for radio 188 network authentication and IP multimedia service authentication 189 purposes. Different user identities and formats are used for these; 190 the radio network uses the International Mobile Subscriber Identifier 191 (IMSI), whereas the IP multimedia service uses the Network Access 192 Identifier (NAI) [RFC2486]. 194 2. Terms and Conventions Used in This Document 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 The terms and abbreviations "authenticator", "backend authentication 201 server", "EAP server", "peer", "Silently Discard", "Master Session 202 Key (MSK)", and "Extended Master Session Key (EMSK)" in this document 203 are to be interpreted as described in [EAP]. 205 This document frequently uses the following terms and abbreviations: 207 AAA protocol 209 Authentication, Authorization and Accounting protocol 211 AKA 213 Authentication and Key Agreement 215 AuC 217 Authentication Centre. The mobile network element that can 218 authenticate subscribers either in GSM or in UMTS networks. 220 EAP 222 Extensible Authentication Protocol 223 [EAP] 225 GSM 226 Global System for Mobile communications. 228 NAI 230 Network Access Identifier 231 [RFC2486] 233 AUTN 235 Authentication value generated by the AuC which together with the 236 RAND authenticates the server to the peer, 128 bits 237 [TS 33.102] 239 AUTS 241 A value generated by the peer upon experiencing a synchronization 242 failure, 112 bits. 244 Fast Re-authentication Identity 246 A fast re-authentication identity of the peer, including an NAI realm 247 portion in environments where a realm is used. Used on re- 248 authentication only. 250 Fast Re-authentication Username 252 The username portion of fast re-authentication identity, ie. not 253 including any realm portions. 255 Nonce 257 A value that is used at most once or that is never repeated 258 within the same cryptographic context. In general, a nonce can be 259 predictable (e.g. a counter) or unpredictable (e.g. a random value). 260 Since some cryptographic properties may depend on the randomness of 261 the nonce, attention should be paid to whether a nonce is required 262 to be random or not. In this document, the term nonce is only 263 used to denote random nonces, and it is not used to denote counters. 265 Permanent Identity 267 The permanent identity of the peer, including an NAI realm 268 portion in environments where a realm is used. The permanent 269 identity is usually based on the IMSI. Used on full 270 authentication only. 272 Permanent Username 273 The username portion of permanent identity, ie. not including any 274 realm portions. 276 Pseudonym Identity 278 A pseudonym identity of the peer, including an NAI realm portion 279 in environments where a realm is used. Used on full authentication 280 only. 282 Pseudonym Username 284 The username portion of pseudonym identity, ie. not including any 285 realm portions. 287 RAND 289 Random number generated by the AuC, 128 bits 290 [TS 33.102] 291 . 293 RES 295 Authentication result from the peer, which together with the RAND 296 authenticates the peer to the server, 128 bits 297 [TS 33.102] 299 SQN 301 Sequence number used in the authentication process, 48 bits 302 [TS 33.102] 304 SIM 306 Subscriber Identity Module. The SIM is traditionally a smart 307 card distributed by a GSM operator. 309 SRES 311 The authentication result parameter in GSM, corresponds to the 312 RES parameter in UMTS aka, 32 bits. 314 USIM 316 UMTS Subscriber Identity Module. USIM is an application that is 317 resident e.g. on smart cards distributed by UMTS operators. 319 3. Protocol Overview 321 Figure 1 shows the basic successful full authentication exchange in 322 EAP-AKA, when optional result indications are not used. The 323 authenticator typically communicates with an EAP server that is 324 located on a backend authentication server using an AAA protocol. The 325 authenticator shown in the figure is often simply relaying EAP 326 messages to and from the EAP server, but these back end AAA 327 communications are not shown. At the minimum, EAP-AKA uses two 328 roundtrips to authorize the user and generate session keys. As in 329 other EAP schemes, an identity request/response message pair is 330 usually exchanged first. On full authentication, the peer's identity 331 response includes either the user's International Mobile Subscriber 332 Identity (IMSI), or a temporary identity (pseudonym) if identity 333 privacy is in effect, as specified in Section 4.1. (As specified in 334 [EAP], the initial identity request is not required, and MAY be 335 bypassed in cases where the network can presume the identity, such as 336 when using leased lines, dedicated dial-ups, etc. Please see also 337 Section 4.1.2 for specification how to obtain the identity via EAP 338 AKA messages.) 340 After obtaining the subscriber identity, the EAP server obtains an 341 authentication vector (RAND, AUTN, RES, CK, IK) for use in 342 authenticating the subscriber. From the vector, the EAP server 343 derives the keying material, as specified in Section 4.5. The vector 344 may be obtained by contacting an Authentication Centre (AuC) on the 345 UMTS network; per UMTS specifications, several vectors may be 346 obtained at a time. Vectors may be stored in the EAP server for use 347 at a later time, but they may not be reused. 349 Next, the EAP server starts the actual AKA protocol by sending an 350 EAP-Request/AKA-Challenge message. EAP-AKA packets encapsulate 351 parameters in attributes, encoded in a Type, Length, Value format. 352 The packet format and the use of attributes are specified in Section 353 5. The EAP-Request/AKA-Challenge message contains a RAND random 354 number (AT_RAND) and a network authentication token (AT_AUTN), and a 355 message authentication code AT_MAC. The EAP-Request/AKA-Challenge 356 message MAY optionally contain encrypted data, which is used for 357 identity privacy and fast re-authentication support, as described in 358 Section 4.1. The AT_MAC attribute contains a message authentication 359 code covering the EAP packet. The encrypted data is not shown in the 360 figures of this section. 362 The peer runs the AKA algorithm (typically using a USIM) and verifies 363 the AUTN. If this is successful, the peer is talking to a legitimate 364 EAP server and proceeds to send the EAP-Response/AKA-Challenge. This 365 message contains a result parameter that allows the EAP server in 366 turn to authenticate the peer, and the AT_MAC attribute to integrity 367 protect the EAP message. 369 The EAP server verifies that the RES and the MAC in the EAP-Response/ 370 AKA-Challenge packet are correct. Because protected success 371 indications are not used in this example, the EAP server sends the 372 EAP-Success packet, indicating that the authentication was 373 successful. (Protected success indications are discussed in Section 374 4.3.2.) The EAP server may also include derived keying material in 375 the message it sends to the authenticator. The peer has derived the 376 same keying material, so the authenticator does not forward the 377 keying material to the peer along with EAP-Success. 379 Peer Authenticator 380 | EAP-Request/Identity | 381 |<------------------------------------------------------| 382 | | 383 | EAP-Response/Identity | 384 | (Includes user's NAI) | 385 |------------------------------------------------------>| 386 | +------------------------------+ 387 | | Server runs UMTS algorithms, | 388 | | generates RAND and AUTN. | 389 | +------------------------------+ 390 | EAP-Request/AKA-Challenge | 391 | (AT_RAND, AT_AUTN, AT_MAC) | 392 |<------------------------------------------------------| 393 +-------------------------------------+ | 394 | Peer runs UMTS algorithms on USIM, | | 395 | verifies AUTN and MAC, derives RES | | 396 | and session key | | 397 +-------------------------------------+ | 398 | EAP-Response/AKA-Challenge | 399 | (AT_RES, AT_MAC) | 400 |------------------------------------------------------>| 401 | +--------------------------------+ 402 | | Server checks the given RES, | 403 | | and MAC and finds them correct.| 404 | +--------------------------------+ 405 | EAP-Success | 406 |<------------------------------------------------------| 408 Figure 1: EAP-AKA full authentication procedure 410 Figure 2 shows how the EAP server rejects the Peer due to a failed 411 authentication. 413 Peer Authenticator 414 | EAP-Request/Identity | 415 |<------------------------------------------------------| 416 | | 417 | EAP-Response/Identity | 418 | (Includes user's NAI) | 419 |------------------------------------------------------>| 420 | +------------------------------+ 421 | | Server runs UMTS algorithms, | 422 | | generates RAND and AUTN. | 423 | +------------------------------+ 424 | EAP-Request/AKA-Challenge | 425 | (AT_RAND, AT_AUTN, AT_MAC) | 426 |<------------------------------------------------------| 427 +-------------------------------------+ | 428 | Peer runs UMTS algorithms on USIM, | | 429 | possibly verifies AUTN, and sends an| | 430 | invalid response | | 431 +-------------------------------------+ | 432 | EAP-Response/AKA-Challenge | 433 | (AT_RES, AT_MAC) | 434 |------------------------------------------------------>| 435 | +------------------------------------------+ 436 | | Server checks the given RES and the MAC, | 437 | | and finds one of them incorrct. | 438 | +------------------------------------------+ 439 | EAP-Request/AKA-Notification | 440 |<------------------------------------------------------| 441 | EAP-Response/AKA-Notification | 442 |------------------------------------------------------>| 443 | EAP-Failure | 444 |<------------------------------------------------------| 446 Figure 2: Peer authentication fails 448 Figure 3 shows the peer rejecting the AUTN of the EAP server. 450 The peer sends an explicit error message (EAP-Response/ 451 AKA-Authentication-Reject) to the EAP server, as usual in AKA when 452 AUTN is incorrect. This allows the EAP server to produce the same 453 error statistics as AKA in general produces in UMTS. 455 Peer Authenticator 456 | EAP-Request/Identity | 457 |<------------------------------------------------------| 458 | EAP-Response/Identity | 459 | (Includes user's NAI) | 460 |------------------------------------------------------>| 461 | +------------------------------+ 462 | | Server runs UMTS algorithms, | 463 | | generates RAND and a bad AUTN| 464 | +------------------------------+ 465 | EAP-Request/AKA-Challenge | 466 | (AT_RAND, AT_AUTN, AT_MAC) | 467 |<------------------------------------------------------| 468 +-------------------------------------+ | 469 | Peer runs UMTS algorithms on USIM | | 470 | and discovers AUTN that can not be | | 471 | verified | | 472 +-------------------------------------+ | 473 | EAP-Response/AKA-Authentication-Reject | 474 |------------------------------------------------------>| 475 | EAP-Failure | 476 |<------------------------------------------------------| 478 Figure 3: Network authentication fails 480 The AKA uses shared secrets between the Peer and the Peer's home 481 operator together with a sequence number to actually perform an 482 authentication. In certain circumstances it is possible for the 483 sequence numbers to get out of sequence. Figure 4 shows what happens 484 then. 486 Peer Authenticator 487 | EAP-Request/Identity | 488 |<------------------------------------------------------| 489 | EAP-Response/Identity | 490 | (Includes user's NAI) | 491 |------------------------------------------------------>| 492 | +------------------------------+ 493 | | Server runs UMTS algorithms, | 494 | | generates RAND and AUTN. | 495 | +------------------------------+ 496 | EAP-Request/AKA-Challenge | 497 | (AT_RAND, AT_AUTN, AT_MAC) | 498 |<------------------------------------------------------| 499 +-------------------------------------+ | 500 | Peer runs UMTS algorithms on USIM | | 501 | and discovers AUTN that contains an | | 502 | inappropriate sequence number | | 503 +-------------------------------------+ | 504 | EAP-Response/AKA-Synchronization-Failure | 505 | (AT_AUTS) | 506 |------------------------------------------------------>| 507 | +---------------------------+ 508 | | Perform resynchronization | 509 | | Using AUTS and | 510 | | the sent RAND | 511 | +---------------------------+ 512 | | 514 Figure 4: Sequence number synchronization 516 After the resynchronization process has taken place in the server and 517 AAA side, the process continues by the server side sending a new 518 EAP-Request/AKA-Challenge message. 520 In addition to the full authentication scenarios described above, 521 EAP-AKA includes a fast re-authentication procedure, which is 522 specified in Section 4.2. Fast re-authentication is based on keys 523 derived on full authentication. If the peer has maintained state 524 information for re- authentication and wants to use fast 525 re-authentication, then the peer indicates this by using a specific 526 fast re-authentication identity instead of the permanent identity or 527 a pseudonym identity. The fast re-authentication procedure is 528 described in Section 4.2. 530 4. Operation 531 4.1 Identity Management 533 4.1.1 Format, Generation and Usage of Peer Identities 535 4.1.1.1 General 537 In the beginning of EAP authentication, the Authenticator or the EAP 538 server usually issues the EAP-Request/Identity packet to the peer. 539 The peer responds with EAP-Response/Identity, which contains the 540 user's identity. The formats of these packets are specified in [EAP]. 542 UMTS subscribers are identified with the International Mobile 543 Subscriber Identity (IMSI) [TS 23.003]. The IMSI is composed of a 544 three digit Mobile Country Code (MCC), a two or three digit Mobile 545 Network Code (MNC) and a not more than 10 digit Mobile Subscriber 546 Identification Number (MSIN). In other words, the IMSI is a string of 547 not more than 15 digits. MCC and MNC uniquely identify the GSM 548 operator and help identify the AuC from which the authentication 549 vectors need to be retrieved for this subscriber. 551 Internet AAA protocols identify users with the Network Access 552 Identifier (NAI) [RFC2486]. When used in a roaming environment, the 553 NAI is composed of a username and a realm, separated with "@" 554 (username@realm). The username portion identifies the subscriber 555 within the realm. 557 This section specifies the peer identity format used in EAP-AKA. In 558 this document, the term identity or peer identity refers to the whole 559 identity string that is used to identify the peer. The peer identity 560 may include a realm portion. "Username" refers to the portion of the 561 peer identity that identifies the user, i.e. the username does not 562 include the realm portion. 564 4.1.1.2 Identity Privacy Support 566 EAP-AKA includes optional identity privacy (anonymity) support that 567 can be used to hide the cleartext permanent identity and thereby to 568 make the subscriber's EAP exchanges untraceable to eavesdroppers. 569 Because the permanent identity never changes, revealing it would help 570 observers to track the user. The permanent identity is usually based 571 on the IMSI, which may further help the tracking, because the same 572 identifier may be used in other contexts as well. Identity privacy is 573 based on temporary identities, or pseudonyms, which are equivalent to 574 but separate from the Temporary Mobile Subscriber Identities (TMSI) 575 that are used on cellular networks. Please see Section 9.1 for 576 security considerations regarding identity privacy. 578 4.1.1.3 Username Types in EAP-AKA Identities 580 There are three types of usernames in EAP-AKA peer identities: 582 (1) Permanent usernames. For example, 0123456789098765@myoperator.com 583 might be a valid permanent identity. In this example, 584 0123456789098765 is the permanent username. 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) Fast re-authentication usernames. For example, 591 43953754@myoperator.com might be a valid fast re-authentication 592 identity. In this case, 43953754 is the fast re-authentication 593 username. 595 The first two types of identities are only used on full 596 authentication and the last one only on fast re-authentication. When 597 the optional identity privacy support is not used, the non-pseudonym 598 permanent identity is used on full authentication. The fast 599 re-authentication exchange is specified in Section 4.2. 601 4.1.1.4 Username Decoration 603 In some environments, the peer may need to decorate the identity by 604 prepending or appending the username with a string, in order to 605 indicate supplementary AAA routing information in addition to the NAI 606 realm. (The usage of a NAI realm portion is not considered to be 607 decoration.) Username decoration is out of the scope of this 608 document. However, it should be noted that username decoration might 609 prevent the server from recognizing a valid username. Hence, although 610 the peer MAY use username decoration in the identities the peer 611 includes in EAP-Response/Identity, and the EAP server MAY accept a 612 decorated peer username in this message, the peer or the EAP server 613 MUST NOT decorate any other peer identities that are used in various 614 EAP-AKA attributes. Only the identity used in EAP-Response/Identity 615 may be decorated. 617 4.1.1.5 NAI Realm Portion 619 The peer MAY include a realm portion in the peer identity, as per the 620 NAI format. The use of a realm portion is not mandatory. 622 If a realm is used, the realm MAY be chosen by the subscriber's home 623 operator and it MAY a configurable parameter in the EAP-SIM peer 624 implementation. In this case, the peer is typically configured with 625 the NAI realm of the home operator. Operators MAY reserve a specific 626 realm name for EAP-AKA users. This convention makes it easy to 627 recognize that the NAI identifies a UMTS subscriber. Such reserved 628 NAI realm may be useful as a hint as to the first authentication 629 method to use during method negotiation. When the peer is using a 630 pseudonym username instead of the permanent username, the peer 631 selects the realm name portion similarly as it select the realm 632 portion when using the permanent username. 634 If no configured realm name is available, the peer MAY derive the 635 realm name from the MCC and MNC portions of the IMSI. A RECOMMENDED 636 way to derive the realm from the IMSI using the realm 3gppnetwork.org 637 will be specified in [Draft 3GPP TS 23.003]. 639 Some old implementations derive the realm name from the IMSI by 640 concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits 641 of IMSI and ".owlan.org". For example, if the IMSI is 642 123456789098765, and the MNC is three digits long, then the derived 643 realm name is "mnc456.mcc123.owlan.org". As there are no DNS servers 644 running at owlan.org, these realm names can only be used with 645 manually configured AAA routing. New implementations SHOULD use the 646 mechanism specified in [Draft 3GPP TS 23.003] instead of owlan.org as 647 soon as the 3GPP specification is finalized. 649 The IMSI is a string of digits without any explicit structure, so the 650 peer may not be able to determine the length of the MNC portion. If 651 the peer is not able to determine whether the MNC is two or three 652 digits long, the peer MAY use a 3-digit MNC. If the correct length of 653 the MNC is two, then the MNC used in the realm name includes the 654 first digit of MSIN. Hence, when configuring AAA networks for 655 operators that have 2-digit MNC's, the network SHOULD also be 656 prepared for realm names with incorrect 3-digit MNC's. 658 4.1.1.6 Format of the Permanent Username 660 The non-pseudonym permanent username SHOULD be derived from the IMSI. 661 In this case, the permanent username MUST be of the format "0" | 662 IMSI, where the character "|" denotes concatenation. In other words, 663 the first character of the username is the digit zero (ASCII value 30 664 hexadecimal), followed by the IMSI. The IMSI is an ASCII string that 665 consists of not more than 15 decimal digits (ASCII values between 30 666 and 39 hexadecimal), one character per IMSI digit, in the order as 667 specified in [TS 23.003]. For example, a permanent username derived 668 from the IMSI 295023820005424 would be encoded as the ASCII string 669 "0295023820005424" (byte values in hexadecimal notation: 30 32 39 35 670 30 32 33 38 32 30 30 30 35 34 32 34) 672 The EAP server MAY use the leading "0" as a hint to try EAP-AKA as 673 the first authentication method during method negotiation, rather 674 than for example EAP-SIM. The EAP-AKA server MAY propose EAP-AKA even 675 if the leading character was not "0". 677 Alternatively, an implementation MAY choose a permanent username that 678 is not based on the IMSI. In this case the selection of the username, 679 its format, and its processing is out of the scope of this document. 680 In this case, the peer implementation MUST NOT prepend any leading 681 characters to the username. 683 4.1.1.7 Generating Pseudonyms and Fast Re-authentication Identities by 684 the Server 686 Pseudonym usernames and fast re-authentication identities are 687 generated by the EAP server. The EAP server produces pseudonym 688 usernames and fast re-authentication identities in an 689 implementation-dependent manner. Only the EAP server needs to be able 690 to map the pseudonym username to the permanent identity, or to 691 recognize a fast re-authentication identity. 693 EAP-AKA includes no provisions to ensure that the same EAP server 694 that generated a pseudonym username will be used on the 695 authentication exchange when the pseudonym username is used. It is 696 recommended that the EAP servers implement some centralized mechanism 697 to allow all EAP servers of the home operator to map pseudonyms 698 generated by other severs to the permanent identity. If no such 699 mechanism is available, then the EAP server failing to understand a 700 pseudonym issued by another server can request the peer to send the 701 permanent identity. 703 When issuing a fast re-authentication identity, the EAP server may 704 include a realm name in the identity to make the fast 705 re-authentication request be forwarded to the same EAP server. 707 When generating fast re-authentication identities, the server SHOULD 708 choose a fresh new fast re-authentication identity that is different 709 from the previous ones used within a same reauthentication context. 710 The fast re-authentication identity SHOULD include a random 711 component. The random component works as a full authentication 712 context identifier. A context-specific fast re-authentication 713 identity can help the server to detect whether its fast 714 re-authentication state information matches the peer's fast 715 re-authentication state information (in other words whether the state 716 information is from the same full authentication exchange). The 717 random component also makes the fast re-authentication identities 718 unpredictable, so an attacker cannot initiate a fast 719 re-authentication exchange to get the server's EAP-Request/SIM/ 720 Re-authentication packet. 722 Regardless of construction method, the pseudonym username MUST 723 conform to the grammar specified for the username portion of an NAI. 724 The fast re-authentication identity also MUST conform to the NAI 725 grammar. The EAP servers that the subscribers of an operator can use 726 MUST ensure that the pseudonym usernames and the username portions 727 used in fast re-authentication identities they generate are unique. 729 In any case, it is necessary that permanent usernames, pseudonym 730 usernames and fast re-authentication usernames are separate and 731 recognizable from each other. It is also desirable that EAP-SIM and 732 EAP-AKA user names be recognizable from each other as an aid for the 733 server to which method to offer. 735 In general, it is the task of the EAP server and the policies of its 736 administrator to ensure sufficient separation in the usernames. 737 Pseudonym usernames and fast re-authentication usernames are both 738 produced and used by the EAP server. The EAP server MUST compose 739 pseudonym usernames and fast re-authentication usernames so that it 740 can recognize if a NAI username is an EAP-AKA pseudonym username or 741 an EAP-AKA fast re-authentication username. For instance, when the 742 usernames have been derived from the IMSI, the server could use 743 different leading characters in the pseudonym usernames and fast 744 re-authentication usernames (e.g. the pseudonym could begin with a 745 leading "2" character). When mapping a fast re-authentication 746 identity to a permanent identity, the server SHOULD only examine the 747 username portion of the fast re-authentication identity and ignore 748 the realm portion of the identity. 750 Because the peer may fail to save a pseudonym username sent to in an 751 EAP-Request/AKA-Challenge, for example due to malfunction, the EAP 752 server SHOULD maintain at least the most recently used pseudonym 753 username in addition to the most recently issued pseudonym username. 754 If the authentication exchange is not completed successfully, then 755 the server SHOULD NOT overwrite the pseudonym username that was 756 issued during the most recent successful authentication exchange. 758 4.1.1.8 Transmitting Pseudonyms and Fast Re-authentication Identities to 759 the Peer 761 The server transmits pseudonym usernames and fast re-authentication 762 identities to the peer in cipher, using the AT_ENCR_DATA attribute. 764 The EAP-Request/AKA-Challenge message MAY include an encrypted 765 pseudonym username and/or an encrypted fast re-authentication 766 identity in the value field of the AT_ENCR_DATA attribute. Because 767 identity privacy support and fast re-authentication are optional to 768 implement, the peer MAY ignore the AT_ENCR_DATA attribute and always 769 use the permanent identity. On fast re-authentication (discussed in 770 Section 4.2), the server MAY include a new encrypted fast 771 re-authentication identity in the EAP-Request/AKA-Reauthentication 772 message. 774 On receipt of the EAP-Request/AKA-Challenge, the peer MAY decrypt the 775 encrypted data in AT_ENCR_DATA and if a pseudonym username is 776 included, the peer may use the obtained pseudonym username on the 777 next full authentication. If a fast re-authentication identity is 778 included, then the peer MAY save it together with other fast 779 re-authentication state information, as discussed in Section 4.2, for 780 the next re- authentication. 782 If the peer does not receive a new pseudonym username in the EAP- 783 Request/AKA-Challenge message, the peer MAY use an old pseudonym 784 username instead of the permanent username on next full 785 authentication. The username portions of fast re-authentication 786 identities are one-time usernames, which the peer MUST NOT re-use. 787 When the peer uses a fast re-authentication identity in an EAP 788 exchange, the peer MUST discard the fast re-authentication identity 789 and not re-use it in another EAP authentication exchange, even if the 790 authentication exchange was not completed. 792 4.1.1.9 Usage of the Pseudonym by the Peer 794 When the optional identity privacy support is used on full 795 authentication, the peer MAY use a pseudonym username received as 796 part of a previous full authentication sequence as the username 797 portion of the NAI. The peer MUST NOT modify the pseudonym username 798 received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer 799 MAY need to decorate the username in some environments by appending 800 or prepending the username with a string that indicates supplementary 801 AAA routing information. 803 When using a pseudonym username in an environment where a realm 804 portion is used, the peer concatenates the received pseudonym 805 username with the "@" character and a NAI realm portion. The 806 selection of the NAI realm is discussed above. The peer can select 807 the realm portion similarly regardless of whether it uses the 808 permanent username or a pseudonym username. 810 4.1.1.10 Usage of the Fast Re-authentication Identity by the Peer 812 On fast re-authentication, the peer uses the fast re-authentication 813 identity, received as part of the previous authentication sequence. A 814 new fast re-authentication identity may be delivered as part of both 815 full authentication and fast re-authentication. The peer MUST NOT 816 modify the username part of the fast re-authentication identity 817 received in AT_NEXT_REAUTH_ID, except in cases when username 818 decoration is required. Even in these cases, the "root" fast 819 re-authentication username must not be modified, but it may be 820 appended or prepended with another string. 822 4.1.2 Communicating the Peer Identity to the Server 824 4.1.2.1 General 826 The peer identity MAY be communicated to the server with the 827 EAP-Response/Identity message. This message MAY contain the permanent 828 identity, a pseudonym identity, or a fast re-authentication identity. 829 If the peer uses the permanent identity or a pseudonym identity, 830 which the server is able to map to the permanent identity, then the 831 authentication proceeds as discussed in the overview of Section 3. If 832 the peer uses a fast re-authentication identity, and if the fast 833 re-authentication identity matches with a valid fast 834 re-authentication identity maintained by the server , then a fast 835 re-authentication exchange is performed, as described in Section 4.2. 837 The peer identity can also be transmitted from the peer to the server 838 using EAP-AKA messages instead of EAP-Response/Identity. In this 839 case, the server includes an identity requesting attribute 840 (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the 841 EAP-Request/AKA-Identity message, and the peer includes the 842 AT_IDENTITY attribute, which contains the peer's identity, in the 843 EAP-Response/AKA-Identity message. The AT_ANY_ID_REQ attribute is a 844 general identity requesting attribute, which the server uses if it 845 does not specify which kind of an identity the peer should return in 846 AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to 847 request either the permanent identity or a pseudonym identity. The 848 server uses the AT_PERMANENT_ID_REQ attribute to request the peer to 849 send its permanent identity. The EAP-Request/AKA-Challenge, 850 EAP-Response/AKA-Challenge, or the packets used on fast 851 re-authentication may optionally include the AT_CHECKCODE attribute, 852 which enables the protocol peers to ensure the integrity of the 853 AKA-Identity packets. AT_CHECKCODE is specified in Section 7.13. 855 The identity format in the AT_IDENTITY attribute is the same as in 856 the EAP-Response/Identity packet (except that identity decoration is 857 not allowed). The AT_IDENTITY attribute contains a permanent 858 identity, a pseudonym identity or a fast re-authentication identity. 860 Obtaining the subscriber identity via EAP-AKA messages is useful if 861 the server does not have any EAP-AKA peer identity at the beginning 862 of the EAP-AKA exchange or does not recognize the identity the peer 863 used in EAP-Response/Identity. This may happen if, for example, the 864 EAP-Response/Identity has been issued by some EAP method other than 865 EAP-AKA or if intermediate entities or software layers in the peer 866 have modified the identity string in the EAP-Response/Identity 867 packet. Also, some EAP layer implementations may cache the identity 868 string from the first EAP authentication and do not obtain a new 869 identity string from the EAP method implementation on subsequent 870 authentication exchanges. 872 As the identity string is used in key derivation, any of these cases 873 will result in failed authentication unless the EAP server uses 874 EAP-AKA attributes to obtain an unmodified copy of the identity 875 string. Therefore, unless the EAP server can be certain that no 876 intermediate element or software layer has modified the EAP- 877 Response/Identity packet, the EAP server MUST use the EAP-AKA 878 attributes to obtain the identity, even if the identity received in 879 EAP-Response/Identity was valid. 881 Please note that the EAP-AKA peer and the EAP-AKA server only process 882 the AT_IDENTITY attribute and entities that only pass through EAP 883 packets do not process this attribute. Hence, if the EAP server is 884 not co-located in the authenticator, then the authenticator and other 885 intermediate AAA elements (such as possible AAA proxy servers) will 886 continue to refer to the peer with the original identity from the 887 EAP-Response/Identity packet regardless of whether the AT_IDENTITY 888 attribute is used in EAP-AKA to transmit another identity. 890 4.1.2.2 Choice of Identity for the EAP-Response/Identity 892 If EAP-AKA peer is started upon receiving an EAP-Request/Identity 893 message, then the peer performs the following steps. 895 If the peer has maintained fast re-authentication state information 896 and if the peer wants to use fast re-authentication, then the peer 897 transmits the fast re-authentication identity in EAP-Response/ 898 Identity. 900 Else, if the peer has a pseudonym username available, then the peer 901 transmits the pseudonym identity in EAP-Response/Identity. 903 In other cases, the peer transmits the permanent identity in 904 EAP-Response/Identity. 906 4.1.2.3 Server Operation in the Beginning of EAP-AKA Exchange 908 If the EAP server has not received any EAP-AKA peer identity 909 (permanent identity, pseudonym identity or fast re-authentication 910 identity) from the peer when sending the first EAP-AKA request, or if 911 the EAP server has received an EAP-Response/Identity packet but the 912 contents do not appear to be a valid permanent identity, pseudonym 913 identity or a re- authentication identity, then the server MUST 914 request an identity from the peer using one of the methods below. 916 The server sends the EAP-Request/AKA-Identity message with the 917 AT_PERMANENT_ID_REQ message to indicate that the server wants the 918 peer to include the permanent identity in the AT_IDENTITY attribute 919 of the EAP-Response/AKA-Identity message. This is done in the 920 following cases: 922 o The server does not support fast re-authentication or identity 923 privacy. 924 o The server received an identity that it recognizes as a pseudonym 925 identity but the server is not able to map the pseudonym identity 926 to a permanent identity. 928 o The server issues the EAP-Request/AKA-Identity packet with the 929 AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the 930 peer to include a full authentication identity (pseudonym identity 931 or permanent identity) in the AT_IDENTITY attribute of the 932 EAP-Response/AKA-Identity message. This is done in the following 933 cases: 934 o The server does not support fast re-authentication and the server 935 supports identity privacy 936 o The server received an identity that it recognizes as a re- 937 authentication identity but the server is not able to map the re- 938 authentication identity to a permanent identity 940 The server issues the EAP-Request/AKA-Identity packet with the 941 AT_ANY_ID_REQ attribute to indicate that the server wants the peer to 942 include an identity in the AT_IDENTITY attribute of the EAP-Response/ 943 SIM/Start message, and the server does not indicate any preferred 944 type for the identity. This is done in other cases, such as when the 945 server does not have any identity, or the server does not recognize 946 the format of a received identity. 948 4.1.2.4 Processing of EAP-Request/AKA-Identity by the Peer 950 Upon receipt of an EAP-Request/AKA-Identity message, the peer MUST 951 perform the following steps. 953 If the EAP-Request/AKA-Identity includes AT_PERMANENT_ID_REQ, and if 954 the peer does not have a pseudonym available, then the peer MUST 955 respond with EAP-Response/AKA-Identity and include the permanent 956 identity in AT_IDENTITY. If the peer has a pseudonym available, then 957 the peer MAY refuse to send the permanent identity; hence in this 958 case the peer MUST either respond with EAP-Response/AKA-Identity and 959 include the permanent identity in AT_IDENTITY or respond with 960 EAP-Response/AKA-Client-Error packet with code "unable to process 961 packet". 963 If the EAP-Request/AKA-Identity includes AT_FULL_AUTH_ID_REQ, and if 964 the peer has a pseudonym available, then the peer SHOULD respond with 965 EAP-Response/AKA-Identity and include the pseudonym identity in 966 AT_IDENTITY. If the peer does not have a pseudonym when it receives 967 this message, then the peer MUST respond with EAP-Response/ 968 AKA-Identity and include the permanent identity in AT_IDENTITY. The 969 Peer MUST NOT use a fast re-authentication identity in the 970 AT_IDENTITY attribute. 972 If the EAP-Request/AKA-Identity includes AT_ANY_ID_REQ, and if the 973 peer has maintained fast re-authentication state information and the 974 peer wants to use fast re-authentication, then the peer responds with 975 EAP- Response/AKA-Identity and includes the fast re-authentication 976 identity in AT_IDENTITY. Else, if the peer has a pseudonym identity 977 available, then the peer responds with EAP-Response/AKA-Identity and 978 includes the pseudonym identity in AT_IDENTITY. Else, the peer 979 responds with EAP-Response/AKA-Identity and includes the permanent 980 identity in AT_IDENTITY. 982 An EAP-AKA exchange may include several EAP/AKA-Identity rounds. The 983 server may issue a second EAP-Request/AKA-Identity, if it was not 984 able to recognize the identity the peer used in the previous 985 AT_IDENTITY attribute. At most three EAP/AKA-Identity rounds can be 986 used, so the peer MUST NOT respond to more than three EAP-Request/ 987 AKA-Identity messages within an EAP exchange. The peer MUST verify 988 that the sequence of EAP-Request/AKA-Identity packets the peer 989 receives comply with the sequencing rules defined in this document. 990 That is, AT_ANY_ID_REQ can only be used in the first EAP-Request/ 991 AKA-Identity, in other words AT_ANY_ID_REQ MUST NOT be used in the 992 second or third EAP-Request/AKA-Identity. AT_FULLAUTH_ID_REQ MUST NOT 993 be used if the previous EAP-Request/AKA-Identity included 994 AT_PERMANENT_ID_REQ. The peer operation in cases when it receives an 995 unexpected attribute or an unexpected message is specified in Section 996 4.4.1. 998 4.1.2.5 Attacks against Identity Privacy 1000 The section above specifies two possible ways the peer can operate 1001 upon receipt of AT_PERMANENT_ID_REQ. This is because a received 1002 AT_PERMANENT_ID_REQ does not necessarily originate from the valid 1003 network, but an active attacker may transmit an EAP-Request/ 1004 AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute to the 1005 peer, in an effort to find out the true identity of the user. If the 1006 peer does not want to reveal its permanent identity, then the peer 1007 sends the EAP-Response/AKA-Client-Error packet with the error code 1008 "unable to process packet", and the authentication exchange 1009 terminates. 1011 Basically, there are two different policies that the peer can employ 1012 with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes 1013 that the network is able to maintain pseudonyms robustly. Therefore, 1014 if a conservative peer has a pseudonym username, the peer responds 1015 with EAP-Response/AKA-Client-Error to the EAP packet with 1016 AT_PERMANENT_ID_REQ, because the peer believes that the valid network 1017 is able to map the pseudonym identity to the peer's permanent 1018 identity. (Alternatively, the conservative peer may accept 1019 AT_PERMANENT_ID_REQ in certain circumstances, for example if the 1020 pseudonym was received a long time ago.) The benefit of this policy 1021 is that it protects the peer against active attacks on anonymity. On 1022 the other hand, a "liberal" peer always accepts the 1023 AT_PERMANENT_ID_REQ and responds with the permanent identity. The 1024 benefit of this policy is that it works even if the valid network 1025 sometimes loses pseudonyms and is not able to map them to the 1026 permanent identity. 1028 4.1.2.6 Processing of AT_IDENTITY by the Server 1030 When the server receives an EAP-Response/AKA-Identity message with 1031 the AT_IDENTITY (in response to the server's identity requesting 1032 attribute), the server MUST operate as follows. 1034 If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does 1035 not contain a valid permanent identity, then the server sends an 1036 EAP-Request/AKA-Notification packet with AT_NOTIFICATION code 16384 1037 to terminate the EAP exchange. If the server recognizes the permanent 1038 identity and is able to continue, then the server proceeds with full 1039 authentication by sending EAP-Request/AKA-Challenge. 1041 If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a 1042 valid permanent identity or a pseudonym identity that the server can 1043 map to a valid permanent identity, then the server proceeds with full 1044 authentication by sending EAP-Request/AKA-Challenge. If AT_IDENTITY 1045 contains a pseudonym identity that the server is not able to map to a 1046 valid permanent identity, or an identity that the server is not able 1047 to recognize or classify, then the server sends EAP-Request/ 1048 AKA-Identity with AT_PERMANENT_ID_REQ. 1050 If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a 1051 valid permanent identity or a pseudonym identity that the server can 1052 map to a valid permanent identity, then the server proceeds with full 1053 authentication by sending EAP-Request/ AKA-Challenge. 1055 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid 1056 fast re-authentication identity and the server agrees on using re- 1057 authentication, then the server proceeds with fast re-authentication 1058 by sending EAP-Request/AKA-Reauthentication (Section 4.2). 1060 If the server used AT_ANY_ID_REQ, and if the peer sent an 1061 EAP-Response/AKA-Identity with AT_IDENTITY that contains an identity 1062 that the server recognizes as a fast re-authentication identity, but 1063 the server is not able to map the identity to a permanent identity, 1064 then the server sends EAP-Request/AKA-Identity with 1065 AT_FULLAUTH_ID_REQ. 1067 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid 1068 fast re-authentication identity, which the server is able to map to a 1069 permanent identity, and if the server does not want to use fast 1070 re-authentication, then the server proceeds with full authentication 1071 by sending EAP-Request/AKA-Challenge. 1073 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an 1074 identity that the server recognizes as a pseudonym identity but the 1075 server is not able to map the pseudonym identity to a permanent 1076 identity, then the server sends EAP-Request/AKA-Identity with 1077 AT_PERMANENT_ID_REQ. 1079 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an 1080 identity that the server is not able to recognize or classify, then 1081 the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ. 1083 4.1.3 Message Sequence Examples (Informative) 1085 This section contains non-normative message sequence examples to 1086 illustrate how the peer identity can be communicated to the server. 1088 4.1.3.1 Usage of AT_ANY_ID_REQ 1090 Obtaining the peer identity with EAP-AKA attributes is illustrated in 1091 Figure 5 below. 1093 Peer Authenticator 1094 | | 1095 | +------------------------------+ 1096 | | Server does not have any | 1097 | | Subscriber identity available| 1098 | | When starting EAP-AKA | 1099 | +------------------------------+ 1100 | EAP-Request/AKA-Identity | 1101 | (AT_ANY_ID_REQ) | 1102 |<------------------------------------------------------| 1103 | | 1104 | EAP-Response/AKA-Identity | 1105 | (AT_IDENTITY) | 1106 |------------------------------------------------------>| 1107 | | 1109 Figure 5: Usage of AT_ANY_ID_REQ 1111 4.1.3.2 Fall Back on Full Authentication 1113 Figure 6 illustrates the case when the server does not recognize the 1114 fast re-authentication identity the peer used in AT_IDENTITY. 1116 Peer Authenticator 1117 | | 1118 | +------------------------------+ 1119 | | Server does not have any | 1120 | | Subscriber identity available| 1121 | | When starting EAP-AKA | 1122 | +------------------------------+ 1123 | EAP-Request/AKA-Identity | 1124 | (AT_ANY_ID_REQ) | 1125 |<------------------------------------------------------| 1126 | | 1127 | EAP-Response/AKA-Identity | 1128 | (AT_IDENTITY containing a fast re-auth. identity) | 1129 |------------------------------------------------------>| 1130 | +------------------------------+ 1131 | | Server does not recognize | 1132 | | The fast re-auth. | 1133 | | Identity | 1134 | +------------------------------+ 1135 | EAP-Request/AKA-Identity | 1136 | (AT_FULLAUTH_ID_REQ) | 1137 |<------------------------------------------------------| 1138 | EAP-Response/AKA-Identity | 1139 | (AT_IDENTITY with a full-auth. Identity) | 1140 |------------------------------------------------------>| 1141 | | 1143 Figure 6: Fall back on full authentication 1145 If the server recognizes the fast re-authentication identity, but 1146 still wants to fall back on full authentication, the server may issue 1147 the EAP-Request/AKA-Challenge packet. In this case, the full 1148 authentication procedure proceeds as usual. 1150 4.1.3.3 Requesting the Permanent Identity 1 1152 Figure 7 illustrates the case when the EAP server fails to decode a 1153 pseudonym identity included in the EAP-Response/Identity packet. 1155 Peer Authenticator 1156 | EAP-Request/Identity | 1157 |<------------------------------------------------------| 1158 | EAP-Response/Identity | 1159 | (Includes a pseudonym) | 1160 |------------------------------------------------------>| 1161 | +------------------------------+ 1162 | | Server fails to decode the | 1163 | | Pseudonym. | 1164 | +------------------------------+ 1165 | EAP-Request/AKA-Identity | 1166 | (AT_PERMANENT_ID_REQ) | 1167 |<------------------------------------------------------| 1168 | | 1169 | EAP-Response/AKA-Identity | 1170 | (AT_IDENTITY with permanent identity) | 1171 |------------------------------------------------------>| 1172 | | 1174 Figure 7: Requesting the permanent identity 1 1176 If the server recognizes the permanent identity, then the 1177 authentication sequence proceeds as usual with the EAP Server issuing 1178 the EAP-Request/AKA-Challenge message. 1180 4.1.3.4 Requesting the Permanent Identity 2 1182 Figure 8 illustrates the case when the EAP server fails to decode the 1183 pseudonym included in the AT_IDENTITY attribute. 1185 Peer Authenticator 1186 | | 1187 | +------------------------------+ 1188 | | Server does not have any | 1189 | | Subscriber identity available| 1190 | | When starting EAP-AKA | 1191 | +------------------------------+ 1192 | EAP-Request/AKA-Identity | 1193 | (AT_ANY_ID_REQ) | 1194 |<------------------------------------------------------| 1195 | | 1196 |EAP-Response/AKA-Identity | 1197 |(AT_IDENTITY with a pseudonym identity) | 1198 |------------------------------------------------------>| 1199 | +------------------------------+ 1200 | | Server fails to decode the | 1201 | | Pseudonym in AT_IDENTITY | 1202 | +------------------------------+ 1203 | EAP-Request/AKA-Identity | 1204 | (AT_PERMANENT_ID_REQ) | 1205 |<------------------------------------------------------| 1206 | EAP-Response/AKA-Identity | 1207 | (AT_IDENTITY with permanent identity) | 1208 |------------------------------------------------------>| 1209 | | 1211 Figure 8: Requesting the permanent identity 2 1213 4.1.3.5 Three EAP/AKA-Identity Round Trips 1215 Figure 9 illustrates the case with three EAP/AKA-Identity round 1216 trips. 1218 Peer Authenticator 1219 | | 1220 | +------------------------------+ 1221 | | Server does not have any | 1222 | | Subscriber identity available| 1223 | | When starting EAP-AKA | 1224 | +------------------------------+ 1225 | EAP-Request/AKA-Identity | 1226 | (AT_ANY_ID_REQ) | 1227 |<------------------------------------------------------| 1228 | | 1229 | EAP-Response/AKA-Identity | 1230 | (AT_IDENTITY with fast re-auth. identity) | 1231 |------------------------------------------------------>| 1232 | +------------------------------+ 1233 | | Server does not accept | 1234 | | The fast re-authentication | 1235 | | Identity | 1236 | +------------------------------+ 1237 | | 1238 : : 1239 : : 1241 : : 1242 : : 1243 | EAP-Request/AKA-Identity | 1244 | (AT_FULLAUTH_ID_REQ) | 1245 |<------------------------------------------------------| 1246 |EAP-Response/AKA-Identity | 1247 |(AT_IDENTITY with a pseudonym identity) | 1248 |------------------------------------------------------>| 1249 | +------------------------------+ 1250 | | Server fails to decode the | 1251 | | Pseudonym in AT_IDENTITY | 1252 | +------------------------------+ 1253 | EAP-Request/AKA-Identity | 1254 | (AT_PERMANENT_ID_REQ) | 1255 |<------------------------------------------------------| 1256 | EAP-Response/AKA-Identity | 1257 | (AT_IDENTITY with permanent identity) | 1258 |------------------------------------------------------>| 1259 | | 1261 Figure 9: Three EAP-AKA Start rounds 1263 After the last EAP-Response/AKA-Identity message, the full 1264 authentication sequence proceeds as usual. 1266 4.2 Fast Re-authentication 1268 4.2.1 General 1270 In some environments, EAP authentication may be performed frequently. 1271 Because the EAP-AKA full authentication procedure makes use of the 1272 UMTS AKA algorithms, and it therefore requires fresh authentication 1273 vectors from the Authentication Centre, the full authentication 1274 procedure may result in many network operations when used very 1275 frequently. Therefore, EAP-AKA includes a more inexpensive fast 1276 re-authentication procedure that does not make use of the UMTS AKA 1277 algorithms and does not need new vectors from the Authentication 1278 Centre. 1280 Fast re-authentication is optional to implement for both the EAP-AKA 1281 server and peer. On each EAP authentication, either one of the 1282 entities may also fall back on full authentication if they do not 1283 want to use fast re-authentication. 1285 Fast re-authentication is based on the keys derived on the preceding 1286 full authentication. The same K_aut and K_encr keys as in full 1287 authentication are used to protect EAP-AKA packets and attributes, 1288 and the original Master Key from full authentication is used to 1289 generate a fresh Master Session Key, as specified in Section 4.5. 1291 The fast re-authentication exchange makes use of an unsigned 16-bit 1292 counter, included in the AT_COUNTER attribute. The counter has three 1293 goals: 1) it can be used to limit the number of successive 1294 reauthentication exchanges without full-authentication 2) it 1295 contributes to the keying material, and 3) it protects the peer and 1296 the server from replays. On full authentication, both the server and 1297 the peer initialize the counter to one. The counter value of at least 1298 one is used on the first fast re-authentication. On subsequent fast 1299 re-authentications, the counter MUST be greater than on any of the 1300 previous fast re-authentications. For example, on the second fast 1301 re-authentication, counter value is two or greater etc. The 1302 AT_COUNTER attribute is encrypted. 1304 Both the peer and the EAP server maintain a copy of the counter. The 1305 EAP server sends its counter value to the peer in the fast 1306 re-authentication request. The peer MUST verify that its counter 1307 value is less than or equal to the value sent by the EAP server. 1309 The server includes an encrypted server random nonce (AT_NONCE_S) in 1310 the fast re-authentication request. The AT_MAC attribute in the 1311 peer's response is calculated over NONCE_S to provide a challenge/ 1312 response authentication scheme. The NONCE_S also contributes to the 1313 new Master Session Key. 1315 Both the peer and the server SHOULD have an upper limit for the 1316 number of subsequent fast re-authentications allowed before a full 1317 authentication needs to be performed. Because a 16-bit counter is 1318 used in fast re-authentication, the theoretical maximum number of re- 1319 authentications is reached when the counter value reaches FFFF 1320 hexadecimal. In order to use fast re-authentication, the peer and the 1321 EAP server need to store the following values: Master Key, latest 1322 counter value and the next fast re-authentication identity. K_aut, 1323 K_encr may either be stored or derived again from MK. The server may 1324 also need to store the permanent identity of the user. 1326 4.2.2 Comparison to UMTS AKA 1328 When analyzing the fast re-authentication exchange, it may be helpful 1329 to compare it with the UMTS Authentication and Key Agreement (AKA) 1330 exchange, which it resembles closely. The counter corresponds to the 1331 UMTS AKA sequence number, NONCE_S corresponds to RAND, and AT_MAC in 1332 EAP-Request/AKA-Reauthentication corresponds to AUTN, the AT_MAC in 1333 EAP-Response/AKA-Reauthentication corresponds to RES, 1334 AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter 1335 corresponds to the usage of the Anonymity Key. Also the key 1336 generation on fast re-authentication with regard to random or fresh 1337 material is similar to UMTS AKA -- the server generates the NONCE_S 1338 and counter values, and the peer only verifies that the counter value 1339 is fresh. 1341 It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER or 1342 AT_COUNTER_TOO_SMALL attributes is not important to the security of 1343 the fast re-authentication exchange. 1345 4.2.3 Fast Re-authentication Identity 1347 The fast re-authentication procedure makes use of separate re- 1348 authentication user identities. Pseudonyms and the permanent identity 1349 are reserved for full authentication only. If a fast 1350 re-authentication identity is lost and the network does not recognize 1351 it, the EAP server can fall back on full authentication. If the EAP 1352 server supports fast re-authentication, it MAY include the skippable 1353 AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP- Request/ 1354 AKA-Challenge message. This attribute contains a new re- 1355 authentication identity for the next fast re-authentication. The 1356 attribute also works as a capability flag that indicates the fact 1357 that the server supports fast re-authentication, and that the server 1358 wants to continue using fast re-authentication within the current 1359 context. The peer MAY ignore this attribute, in which case it will 1360 use full authentication next time. If the peer wants to use fast 1361 re-authentication, it uses this fast re-authentication identity on 1362 next authentication. Even if the peer has a fast re-authentication 1363 identity, the peer MAY discard the re- authentication identity and 1364 use a pseudonym or the permanent identity instead, in which case full 1365 authentication MUST be performed. If the EAP server does not include 1366 the AT_NEXT_REAUTH_ID in the encrypted data of EAP-Request/ 1367 AKA-Challenge or EAP-Request/AKA-Reauthentication, then the peer MUST 1368 discard its current fast re-authentication state information and 1369 perform a full authentication next time. 1371 In environments where a realm portion is needed in the peer identity, 1372 the fast re-authentication identity received in AT_NEXT_REAUTH_ID 1373 MUST contain both a username portion and a realm portion, as per the 1374 NAI format. The EAP Server can choose an appropriate realm part in 1375 order to have the AAA infrastructure route subsequent fast 1376 re-authentication related requests to the same AAA server. For 1377 example, the realm part MAY include a portion that is specific to the 1378 AAA server. Hence, it is sufficient to store the context required for 1379 fast re-authentication in the AAA server that performed the full 1380 authentication. 1382 The peer MAY use the fast re-authentication identity in the 1383 EAP-Response/Identity packet or, in response to server's 1384 AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication 1385 identity in the AT_IDENTITY attribute of the EAP-Response/ 1386 AKA-Identity packet. The peer MUST NOT modify the username portion of 1387 the fast re-authentication identity, but the peer MAY modify the 1388 realm portion or replace it with another realm portion. 1390 Even if the peer uses a fast re-authentication identity, the server 1391 may want to fall back on full authentication, for example because the 1392 server does not recognize the fast re-authentication identity or does 1393 not want to use fast re-authentication. If the server was able to 1394 decode the fast re-authentication identity to the permanent identity, 1395 the server issues the EAP-Request/AKA-Challenge packet to initiate 1396 full authentication. If the server was not able to recover the peer's 1397 identity from the fast re-authentication identity, the server starts 1398 the full authentication procedure by issuing an EAP-Request/ 1399 AKA-Identity packet. This packet always starts a full authentication 1400 sequence if it does not include the AT_ANY_ID_REQ attribute. 1402 4.2.4 Fast Re-authentication Procedure 1404 Figure 10 illustrates the fast re-authentication procedure. In this 1405 example, the optional protected success indication is not used. 1406 Encrypted attributes are denoted with '*'. The peer uses its fast 1407 re-authentication identity in the EAP-Response/Identity packet. As 1408 discussed above, an alternative way to communicate the fast 1409 re-authentication identity to the server is for the peer to use the 1410 AT_IDENTITY attribute in the EAP-Response/AKA-Identity message. This 1411 latter case is not illustrated in the figure below, and it is only 1412 possible when the server requests the peer to send its identity by 1413 including the AT_ANY_ID_REQ attribute in the EAP-Request/AKA-Identity 1414 packet. 1416 If the server recognizes the identity as a valid fast 1417 re-authentication identity, and if the server agrees on using fast 1418 re-authentication, then the server sends the EAP- Request/ 1419 AKA-Reauthentication packet to the peer. This packet MUST include the 1420 encrypted AT_COUNTER attribute, with a fresh counter value, the 1421 encrypted AT_NONCE_S attribute that contains a random number chosen 1422 by the server, the AT_ENCR_DATA and the AT_IV attributes used for 1423 encryption, and the AT_MAC attribute that contains a message 1424 authentication code over the packet. The packet MAY also include an 1425 encrypted AT_NEXT_REAUTH_ID attribute that contains the next fast 1426 re-authentication identity. 1428 Fast re-authentication identities are one-time identities. If the 1429 peer does not receive a new fast re-authentication identity, it MUST 1430 use either the permanent identity or a pseudonym identity on the next 1431 authentication to initiate full authentication. 1433 The peer verifies that AT_MAC is correct and that the counter value 1434 is fresh (greater than any previously used value). The peer MAY save 1435 the next fast re-authentication identity from the encrypted 1436 AT_NEXT_REAUTH_ID for next time. If all checks are successful, the 1437 peer responds with the EAP-Response/AKA-Reauthentication packet, 1438 including the AT_COUNTER attribute with the same counter value and 1439 the AT_MAC attribute. 1441 The server verifies the AT_MAC attribute and also verifies that the 1442 counter value is the same that it used in the EAP-Request/AKA- 1443 Reauthentication packet. If these checks are successful, the fast 1444 re-authentication has succeeded and the server sends the EAP-Success 1445 packet to the peer. 1447 If protected success indications (Section 4.3.2) were used, the 1448 EAP-Success packet would be preceded by an EAP-SIM notification 1449 round. 1451 Peer Authenticator 1452 | | 1453 | EAP-Request/Identity | 1454 |<------------------------------------------------------| 1455 | | 1456 | EAP-Response/Identity | 1457 | (Includes a fast re-authentication identity) | 1458 |------------------------------------------------------>| 1459 | +--------------------------------+ 1460 | | Server recognizes the identity | 1461 | | and agrees on using fast | 1462 | | re-authentication | 1463 | +--------------------------------+ 1464 | EAP-Request/AKA-Reauthentication | 1465 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1466 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1467 |<------------------------------------------------------| 1468 | | 1469 : : 1470 : : 1472 : : 1473 : : 1474 | | 1475 +-----------------------------------------------+ | 1476 | Peer verifies AT_MAC and the freshness of | | 1477 | the counter. Peer MAY store the new re- | | 1478 | authentication identity for next re-auth. | | 1479 +-----------------------------------------------+ | 1480 | | 1481 | EAP-Response/AKA-Reauthentication | 1482 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, | 1483 | AT_MAC) | 1484 |------------------------------------------------------>| 1485 | +--------------------------------+ 1486 | | Server verifies AT_MAC and | 1487 | | the counter | 1488 | +--------------------------------+ 1489 | EAP-Success | 1490 |<------------------------------------------------------| 1491 | | 1493 Figure 10: Reauthentication 1495 4.2.5 Fast Re-authentication Procedure when Counter is Too Small 1497 If the peer does not accept the counter value of EAP-Request/ 1498 AKA-Reauthentication, it indicates the counter synchronization 1499 problem by including the encrypted AT_COUNTER_TOO_SMALL in 1500 EAP-Response/AKA-Reauthentication. The server responds with 1501 EAP-Request/AKA-Challenge to initiate a normal full authentication 1502 procedure. This is illustrated in Figure 11. Encrypted attributes are 1503 denoted with '*'. 1505 Peer Authenticator 1506 | EAP-Request/Identity | 1507 |<------------------------------------------------------| 1508 | EAP-Response/Identity | 1509 | (Includes a fast re-authentication identity) | 1510 |------------------------------------------------------>| 1511 | | 1512 | EAP-Request/AKA-Reauthentication | 1513 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1514 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1515 |<------------------------------------------------------| 1516 +-----------------------------------------------+ | 1517 | AT_MAC is valid but the counter is not fresh. | | 1518 +-----------------------------------------------+ | 1519 | EAP-Response/AKA-Reauthentication | 1520 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, | 1521 | *AT_COUNTER, AT_MAC) | 1522 |------------------------------------------------------>| 1523 | +----------------------------------------------+ 1524 | | Server verifies AT_MAC but detects | 1525 | | That peer has included AT_COUNTER_TOO_SMALL| 1526 | +----------------------------------------------+ 1527 | EAP-Request/AKA-Challenge | 1528 |<------------------------------------------------------| 1529 +---------------------------------------------------------------+ 1530 | Normal full authentication follows. | 1531 +---------------------------------------------------------------+ 1532 | | 1534 Figure 11: Fast re-authentication counter too small 1536 In the figure above, the first three messages are similar to the 1537 basic fast re-authentication case. When the peer detects that the 1538 counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL 1539 attribute in EAP-Response/AKA-Reauthentication. This attribute 1540 doesn't contain any data but it is a request for the server to 1541 initiate full authentication. In this case, the peer MUST ignore the 1542 contents of the server's AT_NEXT_REAUTH_ID attribute. 1544 On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and 1545 verifies that AT_COUNTER contains the same counter value as in the 1546 EAP-Request/AKA-Reauthentication packet. If not, the server 1547 terminates the authentication exchange by sending the EAP-Request/ 1548 AKA-Notification packet with AT_NOTIFICATION code 16384. If all 1549 checks on the packet are successful, the server transmits a 1550 EAP-Request/AKA-Challenge packet and the full authentication 1551 procedure is performed as usual. Since the server already knows the 1552 subscriber identity, it MUST NOT use the EAP-Request/AKA-Identity 1553 packet to request the identity. 1555 4.3 EAP-AKA Notifications 1557 4.3.1 General 1559 The EAP server can use EAP-AKA notifications to convey localizable 1560 notifications and result indications (Section 4.3.2) to the peer. 1562 The server MUST use notifications in cases discussed in Section 1563 4.4.2. When the EAP server issues an EAP-Request/AKA-Notification 1564 packet to the peer, the peer MUST process the notification packet.The 1565 peer MAY show a notification message to the user and the peer MUST 1566 respond to the EAP server with an EAP-Response/AKA-Notification 1567 packet, even if the peer did not recognize the notification code. 1569 An EAP-AKA full authentication exchange or a fast re-authentication 1570 exchange MUST NOT include more than one EAP-AKA notification round. 1572 The notification code is a 16-bit number. The most significant bit is 1573 called the Failure bit (F bit). The F bit specifies whether the 1574 notification implies failure. The code values with the F bit set to 1575 zero (code values 0...32767) are used on unsuccessful cases. The 1576 receipt of a notification code from this range implies failed EAP 1577 exchange, so the peer can use the notification as a failure 1578 indication. After receiving the EAP-Response/AKA-Notification for 1579 these notification codes, the server MUST send the EAP-Failure 1580 packet. 1582 The receipt of a notification code with the F bit set to one (values 1583 32768...65536) does not imply failure. Notification code 32768 has 1584 been reserved as a general notification code to indicate successful 1585 authentication. 1587 The second most significant bit of the notification code is called 1588 the Phase bit (P bit). It specifies at which phase of the EAP-AKA 1589 exchange the notification can be used. If the P bit is set to zero, 1590 the notification can only be used after a successful EAP/ 1591 AKA-Challenge round in full authentication or a successful EAP/ 1592 AKA-Reauthentication round in reautentication. A re-authentication 1593 round is considered successful only if the peer has successfully 1594 verified AT_MAC and AT_COUNTER attributes, and does not include the 1595 AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-Reauthentication. 1597 If the P bit is set to one, the notification can only by used before 1598 the EAP/AKA-Challenge round in full authentication or before the EAP/ 1599 AKA-Reauthentication round in reauthentication. 1601 Section 6.10 and Section 6.11 specify what other attributes must be 1602 included in the notification packets. 1604 Some of the notification codes are authorization related and hence 1605 not usually considered as part of the responsibility of an EAP 1606 method. However, they are included as part of EAP-AKA because there 1607 are currently no other ways to convey this information to the user in 1608 a localizable way, and the information is potentially useful for the 1609 user. An EAP-AKA server implementation may decide never to send these 1610 EAP-AKA notifications. 1612 4.3.2 Result Indications 1614 As discussed in Section 4.4, the server and the peer use explicit 1615 error messages in all error cases. If the server detects an error 1616 after successful authentication, the server uses an EAP-AKA 1617 notification to indicate failure to the peer. In this case, the 1618 result indication is integrity and replay protected. 1620 By sending an EAP-Response/AKA-Challenge packet or an EAP-Response/ 1621 AKA-Reauthentication packet (without AT_COUNTER_TOO_SMALL), the peer 1622 indicates that it has successfully authenticated the server and that 1623 the peer's local policy accepts the EAP exchange. In other words, 1624 these packets are implicit success indications from the peer to the 1625 server. 1627 EAP-AKA also supports optional protected success indications from the 1628 server to the peer. If the EAP server wants to use protected success 1629 indications, it includes the AT_RESULT_IND attribute in the 1630 EAP-Request/AKA-Challenge or the EAP-Request/AKA-Reauthentication 1631 packet. This attribute indicates, that the EAP server would like to 1632 use result indications in both successful and unsuccessful cases. If 1633 the peer also wants this, the peer includes AT_RESULT_IND in 1634 EAP-Response/AKA-Challenge or EAP-Response/AKA-Re-authentication. The 1635 peer MUST NOT include AT_RESULT_IND if it did not receive 1636 AT_RESULT_IND from the server. If both the peer and the server used 1637 AT_RESULT_IND, then the EAP exchange is not complete yet, but an 1638 EAP-AKA notification round will follow. The following EAP-SIM 1639 notification may indicate either failure or success. 1641 Success indications with the AT_NOTIFICATION code 32768 can only be 1642 used if both the server and the peer indicate they want to use them 1643 with AT_RESULT_IND. If the server did not include AT_RESULT_IND in 1644 the EAP-Request/AKA-Challenge or EAP-Request/AKA-Reauthentication 1645 packet, or if the peer did not include AT_RESULT_IND in the 1646 corresponding response packet, then the server MUST NOT use protected 1647 success indications. 1649 Because the AT_NOTIFICATION code 32768 is used to indicate success, 1650 the server MUST ignore the contents of the EAP-AKA response it 1651 receives to the EAP-Request/AKA-Notification with this code. 1652 Regardless of the contents of the EAP-AKA response, the server MUST 1653 send EAP-Success as the next packet. 1655 4.4 Error Cases 1657 This section specifies the operation of the peer and the server in 1658 error cases. The subsections below require the EAP-AKA peer and 1659 server to send an error packet (EAP-Response/AKA-Client-Error or 1660 EAP-Request/AKA-Notification) in error cases. However, 1661 implementations SHOULD NOT rely upon the correct error reporting 1662 behavior of the peer, authenticator, or the server. It is possible 1663 for error and other messages to be lost in transit or for a malicious 1664 participant to attempt to consume resources by not issuing error 1665 messages. Both the peer and the EAP server SHOULD have a mechanism 1666 to clean up state even if an error message or EAP-Success is not 1667 received after a timeout period. 1669 4.4.1 Peer Operation 1671 Two special error messages have been specified for error cases that 1672 are related to the processing of the UMTS AKA AUTN parameter, as 1673 described in Section 3: (1) if the peer does not accept AUTN, the 1674 peer responds with EAP-Response/AKA-Authentication-Reject (Section 1675 6.5), and the server issues EAP-Failure, and (2) if the peer detects 1676 that the sequence number in AUTN is not correct, the peer responds 1677 with EAP-Response/AKA-Synchronization-Failure (Section 6.6), and the 1678 server proceeds with a new EAP-Request/AKA-Challenge. 1680 In other error cases, when an EAP-AKA peer detects an error in a 1681 received EAP-AKA packet, the EAP-AKA peer responds with the 1682 EAP-Response/AKA-Client-Error packet. In response to the 1683 EAP-Response/AKA-Client-Error, the EAP server MUST issue the 1684 EAP-Failure packet and the authentication exchange terminates. 1686 By default, the peer uses the client error code 0, "unable to process 1687 packet". This error code is used in the following cases: 1689 o EAP exchange is not acceptable according to the peer's local 1690 policy. 1691 o the peer is not able to parse the EAP request, i.e. the EAP 1692 request is malformed 1693 o the peer encountered a malformed attribute 1694 o wrong attribute types or duplicate attributes have been included 1695 in the EAP request 1697 o a mandatory attribute is missing 1698 o unrecognized non-skippable attribute 1699 o unrecognized or unexpected EAP-AKA Subtype in the EAP request 1700 o invalid AT_MAC 1701 o invalid AT_CHECKCODE 1702 o invalid pad bytes in AT_PADDING 1703 o the peer does not want to process AT_PERMANENT_ID_REQ 1705 4.4.2 Server Operation 1707 If an EAP-AKA server detects an error in a received EAP-AKA response, 1708 the server MUST issue the EAP-Request/AKA-Notification packet with an 1709 AT_NOTIFICATION code that implies failure. By default, the server 1710 uses one of the general failure codes (0 or 16384). The choice 1711 between these two codes depends on the phase of the EAP-AKA exchange, 1712 see Section 4.3. The errors cases when the server issues an 1713 EAP-Request/AKA-Notification that implies failure include the 1714 following: 1716 o the server is not able to parse the peer's EAP response 1717 o the server encounters a malformed attribute, a non-recognized non- 1718 skippable attribute, or a duplicate attribute 1719 o a mandatory attribute is missing or an invalid attribute was 1720 included 1721 o unrecognized or unexpected EAP-AKA Subtype in the EAP Response 1722 o invalid AT_MAC 1723 o invalid AT_CHECKCODE 1724 o invalid AT_COUNTER 1726 4.4.3 EAP-Failure 1728 The EAP-AKA server sends EAP-Failure in three cases: 1730 1) In response to an EAP-Response/AKA-Client-Error packet the server 1731 has received from the peer, or 1733 2) In response to an EAP-Response/AKA-Authentication-Reject packet 1734 the server has received from the peer, or 1736 3) Following an EAP-AKA notification round, when the AT_NOTIFICATION 1737 code implies failure. 1739 The EAP-AKA server MUST NOT send EAP-Failure in other cases than 1740 these three. However, it should be noted that even though the EAP-AKA 1741 server would not send an EAP-Failure, an authorization decision that 1742 happens outside EAP-AKA, such as in the AAA server or in an 1743 intermediate AAA proxy, may result in a failed exchange. 1745 The peer MUST accept the EAP-Failure packet in case 1), case 2) and 1746 case 3) above. The peer SHOULD silently discard the EAP-Failure 1747 packet in other cases. 1749 4.4.4 EAP-Success 1751 On full authentication, the server can only send EAP-Success after 1752 the EAP/AKA-Challenge round. The peer MUST silently discard any 1753 EAP-Success packets if they are received before the peer has 1754 successfully authenticated the server and sent the EAP-Response/ 1755 AKA-Challenge packet. 1757 If the peer did not indicate that it wants to use protected success 1758 indications with AT_RESULT_IND (as discussed in Section 4.3.2) on 1759 full authentication, then the peer MUST accept EAP-Success after a 1760 successful EAP/AKA-Challenge round. 1762 If the peer indicated that it wants to use protected success 1763 indications with AT_RESULT_IND (as discussed in Section 4.3.2), then 1764 the peer MUST NOT accept EAP-Success after a successful EAP/ 1765 AKA-Challenge round. In this case, the peer MUST only accept 1766 EAP-Success after receiving an EAP-AKA Notification with the 1767 AT_NOTIFICATION code 32768. 1769 On fast re-authentication, EAP-Success can only be sent after the 1770 EAP/AKA-Reauthentication round. The peer MUST silently discard any 1771 EAP-Success packets if they are received before the peer has 1772 successfully authenticated the server and sent the EAP-Response/ 1773 AKA-Reauthentication packet. 1775 If the peer did not indicate that it wants to use protected success 1776 indications with AT_RESULT_IND (as discussed in Section 4.3.2) on 1777 fast re-authentication, then the peer MUST accept EAP-Success after a 1778 successful EAP/AKA-Reauthentication round. 1780 If the peer indicated that it wants to use protected success 1781 indications with AT_RESULT_IND (as discussed in Section 4.3.2), then 1782 the peer MUST NOT accept EAP-Success after a successful EAP/ 1783 AKA-Reauthentication round. In this case, the peer MUST only accept 1784 EAP-Success after receiving an EAP-AKA Notification with the 1785 AT_NOTIFICATION code 32768. 1787 If the peer receives an EAP-AKA notification (Section 4.3) that 1788 indicates failure, then the peer MUST no longer accept the EAP- 1789 Success packet even if the server authentication was successfully 1790 completed. 1792 4.5 Key Generation 1794 This section specifies how keying material is generated. 1796 On EAP-AKA full authentication, a Master Key (MK) is derived from the 1797 underlying UMTS AKA values (CK and IK keys), and the identity as 1798 follows. 1800 MK = SHA1(Identity|IK|CK) 1802 In the formula above, the "|" character denotes concatenation. 1803 Identity denotes the peer identity string without any terminating 1804 null characters. It is the identity from the AT_IDENTITY attribute 1805 from the last EAP-Response/AKA-Identity packet, or, if AT_IDENTITY 1806 was not used, the identity from the EAP-Response/Identity packet. The 1807 identity string is included as-is, without any changes and including 1808 the possible identity decoration. The hash function SHA-1 is 1809 specified in [SHA-1]. 1811 The Master Key is fed into a Pseudo-Random number Function (PRF), 1812 which generates separate Transient EAP Keys (TEKs) for protecting 1813 EAP-AKA packets, as well as a Master Session Key (MSK) for link layer 1814 security and an Extended Master Session Key (EMSK) for other 1815 purposes. On fast re-authentication, the same TEKs MUST be used for 1816 protecting EAP packets, but a new MSK and a new EMSK MUST be derived 1817 from the original MK and new values exchanged in the fast 1818 re-authentication. 1820 EAP-AKA requires two TEKs for its own purposes, the authentication 1821 key K_aut to be used with the AT_MAC attribute, and the encryption 1822 key K_encr, to be used with the AT_ENCR_DATA attribute. The same 1823 K_aut and K_encr keys are used in full authentication and subsequent 1824 fast re-authentications. 1826 Key derivation is based on the random number generation specified in 1827 NIST Federal Information Processing Standards (FIPS) Publication 1828 186-2 [PRF]. The pseudo-random number generator is specified in the 1829 change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As specified 1830 in the change notice (page 74), when Algorithm 1 is used as a 1831 general-purpose pseudo-random number generator, the "mod q" term in 1832 step 3.3 is omitted. The function G used in the algorithm is 1833 constructed via Secure Hash Standard as specified in Appendix 3.3 of 1834 the standard. It should be noted that the function G is very similar 1835 to SHA-1, but the message padding is different. Please refer to [PRF] 1836 for full details. For convenience, the random number algorithm with 1837 the correct modification is cited in Annex A. 1839 160-bit XKEY and XVAL values are used, so b = 160. On each full 1840 authentication, the Master Key is used as the initial secret seed-key 1841 XKEY. The optional user input values (XSEED_j) in step 3.1 are set to 1842 zero. 1844 On full authentication, the resulting 320-bit random numbers x_0, 1845 x_1, ..., x_m-1 are concatenated and partitioned into suitable-sized 1846 chunks and used as keys in the following order: K_encr (128 bits), 1847 K_aut (128 bits), Master Session Key (64 bytes), Extended Master 1848 Session Key (64 bytes). 1850 On fast re-authentication, the same pseudo-random number generator 1851 can be used to generate a new Master Session Key and a new Extended 1852 Master Session Key. The seed value XKEY' is calculated as follows: 1854 XKEY' = SHA1(Identity|counter|NONCE_S| MK) 1856 In the formula above, the Identity denotes the fast re-authentication 1857 identity, without any terminating null characters, from the 1858 AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, if 1859 EAP-Response/AKA-Identity was not used on fast re-authentication, the 1860 identity string from the EAP-Response/Identity packet. The counter 1861 denotes the counter value from AT_COUNTER attribute used in the 1862 EAP-Response/AKA-Reauthentication packet. The counter is used in 1863 network byte order. NONCE_S denotes the 16-byte random NONCE_S value 1864 from the AT_NONCE_S attribute used in the EAP-Request/ 1865 AKA-Reauthentication packet. The MK is the Master Key derived on the 1866 preceding full authentication. 1868 On fast re-authentication, the pseudo-random number generator is run 1869 with the new seed value XKEY', and the resulting 320-bit random 1870 numbers x_0, x_1, ..., x_m-1 are concatenated and partitioned into 1871 64-byte chunks and used as the new 64-byte Master Session Key and the 1872 new 64-byte Extended Master Session Key. Note that because K_encr and 1873 K_aut are not derived on fast re-authentication, the Master Session 1874 Key and the Extended Master Session key are obtained from the 1875 beginning of the key stream x_0, x_1, .... 1877 The first 32 bytes of the MSK can be used as the Pairwise Master Key 1878 (PMK) for IEEE 802.11i. 1880 When the RADIUS attributes specified in [RFC2548] are used to 1881 transport keying material, then the first 32 bytes of the MSK 1882 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to 1883 MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material (the 1884 MSK) are used. 1886 5. Message Format and Protocol Extensibility 1888 5.1 Message Format 1890 As specified in [EAP], EAP packets begin with the Code, Identifiers, 1891 Length, and Type fields, which are followed by EAP method specific 1892 Type-Data. The Code field in the EAP header is set to 1 for EAP 1893 requests, and to 2 for EAP Responses. The usage of the Length and 1894 Identifier fields in the EAP header is also specified in [EAP]. In 1895 EAP-AKA, the Type field is set to 23. 1897 In EAP-AKA, the Type-Data begins with an EAP-AKA header that consists 1898 of a 1-octet Subtype field, and a 2-octet reserved field. The Subtype 1899 values used in EAP-AKA are defined in Section 8. The formats of the 1900 EAP header and the EAP-AKA header are shown below. 1902 0 1 2 3 1903 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 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | Code | Identifier | Length | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Type | Subtype | Reserved | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 The rest of the Type-Data, immediately following the EAP-AKA header, 1911 consists of attributes that are encoded in Type, Length, Value 1912 format. The figure below shows the generic format of an attribute. 1914 0 1 2 3 1915 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 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 |Attribute Type | Length | Value... 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 Attribute Type 1922 Indicates the particular type of attribute. The attribute type 1923 values are listed in 1924 Section 8 1925 . 1927 Length 1929 Indicates the length of this attribute in multiples of 4 bytes. 1930 The maximum length of an attribute is 1024 bytes. The length 1931 includes the Attribute Type and Length bytes. 1933 Value 1934 The particular data associated with this attribute. This field is 1935 always included and it is two or more bytes in length. The type 1936 and length fields determine the format and length of the value 1937 field. 1939 Attributes numbered within the range 0 through 127 are called 1940 non-skippable attributes. When an EAP-AKA peer encounters a 1941 non-skippable attribute type that the peer does not recognize, the 1942 peer MUST send the EAP-Response/AKA-Client-Error packet, and the 1943 authentication exchange terminates. If an EAP-AKA server encounters a 1944 non-skippable attribute that the server does not recognize, then the 1945 server sends EAP-Request/AKA-Notification packet with an 1946 AT_NOTIFICATION code that implies general failure (0 or 16384 1947 depending on the phase of the exchange), and the authentication 1948 exchange terminates. 1950 When an attribute numbered in the range 128 through 255 is 1951 encountered but not recognized that particular attribute is ignored, 1952 but the rest of the attributes and message data MUST still be 1953 processed. The Length field of the attribute is used to skip the 1954 attribute value when searching for the next attribute. These 1955 attributes are called skippable attributes. 1957 Unless otherwise specified, the order of the attributes in an EAP AKA 1958 message is insignificant, and an EAP-AKA implementation should not 1959 assume a certain order to be used. 1961 Attributes can be encapsulated within other attributes. In other 1962 words, the value field of an attribute type can be specified to 1963 contain other attributes. 1965 5.2 Protocol Extensibility 1967 EAP-AKA can be extended by specifying new attribute types. If 1968 skippable attributes are used, it is possible to extend the protocol 1969 without breaking old implementations. As specified in Section 7.13, 1970 if new attributes are specified for EAP-Request/AKA-Identity or 1971 EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to 1972 integrity protect the new attributes. 1974 When specifying new attributes, it should be noted that EAP-AKA does 1975 not support message fragmentation. Hence, the sizes of the new 1976 extensions MUST be limited so that the maximum transfer unit (MTU) of 1977 the underlying lower layer is not exceeded. According to [EAP], lower 1978 layers must provide an EAP MTU of 1020 bytes or greater, so any 1979 extensions to EAP-AKA SHOULD NOT exceed the EAP MTU of 1020 bytes. 1981 EAP-AKA packets do not include a version field. However, should there 1982 be a reason to revise this protocol in the future, new non-skippable 1983 or skippable attributes could be specified in order to implement 1984 revised EAP-AKA versions in a backward-compatible manner. It is 1985 possible to introduce version negotiation in the EAP-Request/ 1986 AKA-Identity and EAP-Response/AKA-Identity messages by specifying new 1987 skippable attributes. 1989 6. Messages 1991 This section specifies the messages used in EAP-AKA. It specifies 1992 when a message may be transmitted or accepted, which attributes are 1993 allowed in a message, which attributes are required in a message, and 1994 other message specific details. Message format is specified in 1995 Section 5.1. 1997 6.1 EAP-Request/AKA-Identity 1999 The EAP/AKA-Identity roundtrip MAY used for obtaining the peer 2000 identity to the server. As discussed in Section 4.1, several 2001 AKA-Identity rounds may be required in order to obtain a valid peer 2002 identity. 2004 The server MUST include one of the following identity requesting 2005 attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, AT_ANY_ID_REQ. 2006 These three attributes are mutually exclusive, so the server MUST NOT 2007 include more than one of the attributes. 2009 If the server has previously issued an EAP-Request/AKA-Identity 2010 message with the AT_PERMANENT_ID_REQ attribute, and if the server has 2011 received a response from the peer, then the server MUST NOT issue a 2012 new EAP-Request/AKA-Identity packet. 2014 If the server has previously issued an EAP-Request/AKA-Identity 2015 message with the AT_FULLAUTH_ID_REQ attribute, and if the server has 2016 received a response from the peer, then the server MUST NOT issue a 2017 new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ or 2018 AT_FULLAUTH_ID_REQ attributes. 2020 If the server has previously issued an EAP-Request/AKA-Identity 2021 message with the AT_ANY_ID_REQ attribute, and if the server has 2022 received a response from the peer, then the server MUST NOT issue a 2023 new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ. 2025 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. 2027 6.2 EAP-Response/AKA-Identity 2029 The peer sends EAP-Response/AKA-Identity in response to a valid EAP- 2030 Request/AKA-Identity from the server. 2032 The peer MUST include the AT_IDENTITY attribute. The usage of 2033 AT_IDENITY is defined in Section 4.1. 2035 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. 2037 6.3 EAP-Request/AKA-Challenge 2039 The server sends the EAP-Request/AKA-Challenge on full authentication 2040 after successfully obtaining the subscriber identity. 2042 The AT_RAND attribute MUST be included. 2044 AT_MAC MUST be included. In EAP-Request/AKA-Challenge, there is no 2045 message-specific data covered by the MAC, see Section 7.15. 2047 The AT_RESULT_IND attribute MAY be included. The usage of this 2048 attribute is discussed in Section 4.3.2. 2050 The AT_CHECKCODE attribute MAY be included, and in certain cases 2051 specified in Section 7.13, it MUST be included. 2053 The EAP-Request/AKA-Challenge packet MAY include encrypted attributes 2054 for identity privacy and for communicating the next re- 2055 authentication identity. In this case, the AT_IV and AT_ENCR_DATA 2056 attributes are included (Section 7.12). 2058 The plaintext of the AT_ENCR_DATA value field consist of nested 2059 attributes. The nested attributes MAY include AT_PADDING (as 2060 specified in Section 7.12). If the server supports identity privacy 2061 and wants to communicate a pseudonym to the peer for the next full 2062 authentication, then the nested encrypted attributes include the 2063 AT_NEXT_PSEUDONYM attribute. If the server supports re- 2064 authentication and wants to communicate a fast re-authentication 2065 identity to the peer, then the nested encrypted attributes include 2066 the AT_NEXT_REAUTH_ID attribute. Later versions of this protocol MAY 2067 specify additional attributes to be included within the encrypted 2068 data. 2070 When processing this message, the peer MUST process AT_RAND and 2071 AT_AUTN before processing other attributes. Only if these attributes 2072 are verified to be valid, the peer derives keys and verifies AT_MAC. 2073 The operation in case an error occurs is specified in Section 4.4.1. 2075 6.4 EAP-Response/AKA-Challenge 2077 The peer sends EAP-Response/AKA-Challenge in response to a valid 2078 EAP-Request/AKA-Challenge. 2080 Sending this packet indicates, that the peer has successfully 2081 authenticated the server and that the EAP exchange will be accepted 2082 by the peer's local policy. Hence, if these conditions are not met, 2083 then the peer MUST NOT send EAP-Response/AKA-Challenge, but the peer 2084 MUST send EAP-Response/AKA-Client-Error. 2086 The AT_MAC attribute MUST be included. In EAP-Response/AKA-Challenge, 2087 there is no message-specific data covered by the MAC, see Section 2088 7.15. 2090 The AT_RES attribute MUST be included. 2092 The AT_CHECKCODE attribute MAY be included, and in certain cases 2093 specified in Section 7.13, it MUST be included. 2095 The AT_RESULT_IND attribute MAY be included, if it was included in 2096 EAP-Request/AKA-Challenge. The usage of this attribute is discussed 2097 in Section 4.3.2. 2099 Later versions of this protocol MAY make use of the AT_ENCR_DATA and 2100 AT_IV attributes in this message to include encrypted (skippable) 2101 attributes. The EAP server MUST process EAP-Response/AKA-Challenge 2102 messages that include these attributes even if the server did not 2103 implement these optional attributes. 2105 6.5 EAP-Response/AKA-Authentication-Reject 2107 The peer sends the EAP-Response/AKA-Authentication-Reject packet if 2108 it does not accept the AUTN parameter. This version of the protocol 2109 does not specify any attributes for this message. Future versions of 2110 the protocol MAY specify attributes for this message. 2112 The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in 2113 this message. 2115 6.6 EAP-Response/AKA-Synchronization-Failure 2117 The peer sends the EAP-Response/AKA-Synchronization-Failure, when the 2118 sequence number in the AUTN parameter is incorrect. 2120 The peer MUST include the AT_AUTS attribute. Future versions of the 2121 protocol MAY specify other additional attributes for this message. 2123 The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in 2124 this message. 2126 6.7 EAP-Request/AKA-Reauthentication 2128 The server sends the EAP-Request/AKA-Reauthentication message if it 2129 wants to use fast re-authentication, and if it has received a valid 2130 fast re-authentication identity in EAP-Response/Identity or 2131 EAP-Response/AKA-Identity. 2133 The AT_MAC attribute MUST be included. No message-specific data is 2134 included in the MAC calculation, see Section 7.15. 2136 The AT_RESULT_IND attribute MAY be included. The usage of this 2137 attribute is discussed in Section 4.3.2. 2139 The AT_CHECKCODE attribute MAY be included, and in certain cases 2140 specified in Section 7.13, it MUST be included. 2142 The AT_IV and AT_ENCR_DATA attributes MUST be included. The plaintext 2143 consists of the following nested encrypted attributes, which MUST be 2144 included: AT_COUNTER and AT_NONCE_S. In addition, the nested 2145 encrypted attributes MAY include the following attributes: 2146 AT_NEXT_REAUTH_ID and AT_PADDING. 2148 6.8 EAP-Response/AKA-Reauthentication 2150 The client sends the EAP-Response/AKA-Reauthentication packet in 2151 response to a valid EAP-Request/AKA-Reauthentication. 2153 The AT_MAC attribute MUST be included. For EAP-Response/AKA- 2154 Reauthentication, the MAC code is calculated over the following data: 2155 EAP packet| NONCE_S. The EAP packet is represented as specified in 2156 Section 5.1. It is followed by the 16-byte NONCE_S value from the 2157 server's AT_NONCE_S attribute. 2159 The AT_CHECKCODE attribute MAY be included, and in certain cases 2160 specified in Section 7.13, it MUST be included. 2162 The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested 2163 encrypted attributes MUST include the AT_COUNTER attribute. The 2164 AT_COUNTER_TOO_SMALL attribute MAY be included in the nested 2165 encrypted attributes, and it is included in cases specified in 2166 Section 4.2. The AT_PADDING attribute MAY be included. 2168 The AT_RESULT_IND attribute MAY be included, if it was included in 2169 EAP-Request/AKA-Reauthentication. The usage of this attribute is 2170 discussed in Section 4.3.2. 2172 Sending this packet without AT_COUNTER_TOO_SMALL indicates, that the 2173 peer has successfully authenticated the server and that the EAP 2174 exchange will be accepted by the peer's local policy. Hence, if these 2175 conditions are not met, then the peer MUST NOT send EAP-Response/ 2176 AKA-Reauthentication, but the peer MUST send EAP-Response/ 2177 AKA-Client-Error. 2179 6.9 EAP-Response/AKA-Client-Error 2181 The peer sends EAP-Response/AKA-Client-Error in error cases, as 2182 specified in Section 4.4.1. 2184 The AT_CLIENT_ERROR_CODE attribute MUST be included. The AT_MAC, 2185 AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with this packet. 2187 6.10 EAP-Request/AKA-Notification 2189 The usage of this message is specified in Section 4.3. 2191 The AT_NOTIFICATION attribute MUST be included. 2193 The AT_MAC attribute MUST be included if the P bit of the 2194 AT_NOTIFICATION code is set to zero, and MUST NOT be included if the 2195 P bit is set to one. The P bit is discussed in in Section 4.3. 2197 No message-specific data is included in the MAC calculation. See 2198 Section 7.15. 2200 If EAP-Request/AKA-Notification is used on a fast re-authentication 2201 exchange, and if the P bit in AT_NOTIFICATION is set to zero, then 2202 AT_COUNTER is used for replay protection. In this case, the 2203 AT_ENCR_DATA and AT_IV attributes MUST be included, and the 2204 encapsulated plaintext attributes MUST include the AT_COUNTER 2205 attribute. The counter value included in AT_COUNTER MUST be the same 2206 as in the EAP-Request/AKA-Reauthentication packet on the same fast 2207 re-authentication exchange. 2209 6.11 EAP-Response/AKA-Notification 2211 The usage of this message is specified in Section 4.3. This packet is 2212 an acknowledgement of EAP-Request/AKA-Notification. 2214 The AT_MAC attribute MUST included in cases when the P bit of the 2215 notification code in AT_NOTIFICATION of EAP-Request/AKA-Notification 2216 is set to zero, and MUST NOT be included in cases when the P bit is 2217 set to one. The P bit is discussed in Section 4.3. 2219 If EAP-Request/AKA-Notification is used on fast a re-authentication 2220 exchange, and if the P bit in AT_NOTIFICATION is set to zero, then 2221 AT_COUNTER is used for replay protection. In this case, the 2222 AT_ENCR_DATA and AT_IV attributes MUST be included, and the 2223 encapsulated plaintext attributes MUST include the AT_COUNTER 2224 attribute. The counter value included in AT_COUNTER MUST be the same 2225 as in the EAP-Request/AKA-Reauthentication packet on the same fast 2226 re-authentication exchange. 2228 7. Attributes 2230 This section specifies the format of message attributes. The 2231 attribute type numbers are specified in Section 8. 2233 7.1 Table of Attributes 2235 The following table provides a guide to which attributes may be found 2236 in which kinds of messages, and in what quantity. Messages are 2237 denoted with numbers in parentheses as follows: (1) EAP-Request/ 2238 AKA-Identity, (2) EAP-Response/AKA-Identity, (3) EAP-Request/ 2239 AKA-Challenge, (4) EAP-Response/AKA-Challenge, (5) EAP-Request/ 2240 AKA-Notification, (6) EAP-Response/AKA-Notification, (7) EAP- 2241 Response/AKA-Client-Error (8) EAP-Request/AKA-Reauthentication, (9) 2242 EAP-Response/AKA-Re-authentication, (10) EAP-Response/ 2243 AKA-Authentication-Reject, and (11) EAP-Response/ 2244 AKA-Synchronization-Failure. The column denoted with "E" indicates 2245 whether the attribute is a nested attribute that MUST be included 2246 within AT_ENCR_DATA. 2248 "0" indicates that the attribute MUST NOT be included in the message, 2249 "1" indicates that the attribute MUST be included in the message, 2250 "0-1" indicates that the attribute is sometimes included in the 2251 message, and "0*" indicates that the attribute is not included in the 2252 message in cases specified in this document, but MAY be included in 2253 the future versions of the protocol. 2255 Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E 2256 AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 2257 AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 2258 AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 2259 AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 0 0 N 2260 AT_RAND 0 0 1 0 0 0 0 0 0 0 0 N 2261 AT_AUTN 0 0 1 0 0 0 0 0 0 0 0 N 2262 AT_RES 0 0 0 1 0 0 0 0 0 0 0 N 2263 AT_AUTS 0 0 0 0 0 0 0 0 0 0 1 N 2264 AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 0 0 Y 2265 AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 0 0 Y 2266 AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N 2267 AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N 2268 AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 0 0 Y 2269 AT_CHECKCODE 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N 2270 AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N 2271 AT_MAC 0 0 1 1 0-1 0-1 0 1 1 0 0 N 2272 AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 0 0 Y 2273 AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 0 0 Y 2274 AT_NONCE_S 0 0 0 0 0 0 0 1 0 0 0 Y 2275 AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 0 0 N 2276 AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 0 0 N 2278 It should be noted that attributes AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ 2279 and AT_FULLAUTH_ID_REQ are mutually exclusive, so that only one of 2280 them can be included at the same time. If one of the attributes AT_IV 2281 and AT_ENCR_DATA is included, then both of the attributes MUST be 2282 included. 2284 7.2 AT_PERMANENT_ID_REQ 2286 The format of the AT_PERMANENT_ID_REQ attribute is shown below. 2288 0 1 2 3 2289 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 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 |AT_PERM..._REQ | Length = 1 | Reserved | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 The use of the AT_PERMANENT_ID_REQ is defined in Section 4.1. The 2295 value field only contains two reserved bytes, which are set to zero 2296 on sending and ignored on reception. 2298 7.3 AT_ANY_ID_REQ 2300 The format of the AT_ANY_ID_REQ attribute is shown below. 2302 0 1 2 3 2303 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 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 |AT_ANY_ID_REQ | Length = 1 | Reserved | 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 The use of the AT_ANY_ID_REQ is defined in Section 4.1. The value 2309 field only contains two reserved bytes, which are set to zero on 2310 sending and ignored on reception. 2312 7.4 AT_FULLAUTH_ID_REQ 2314 The format of the AT_FULLAUTH_ID_REQ attribute is shown below. 2316 0 1 2 3 2317 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 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 |AT_FULLAUTH_...| Length = 1 | Reserved | 2320 +---------------+---------------+-------------------------------+ 2322 The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.1. The 2323 value field only contains two reserved bytes, which are set to zero 2324 on sending and ignored on reception. 2326 7.5 AT_IDENTITY 2328 The format of the AT_IDENTITY attribute is shown below. 2330 0 1 2 3 2331 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 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | AT_IDENTITY | Length | Actual Identity Length | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 | | 2336 . Identity . 2337 . . 2338 | | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 The use of the AT_IDENTITY is defined in Section 4.1. The value field 2342 of this attribute begins with 2-byte actual identity length, which 2343 specifies the length of the identity in bytes. This field is followed 2344 by the subscriber identity of the indicated actual length. The 2345 identity is the permanent identity, a pseudonym identity or a fast 2346 re-authentication identity. The identity format is specified in 2347 Section 4.1.1. The same identity format is used in the AT_IDENTITY 2348 attribute and the EAP-Response/Identity packet, with the exception 2349 that the peer MUST NOT decorate the identity it includes in 2350 AT_IDENTITY. The identity does not include any terminating null 2351 characters. Because the length of the attribute must be a multiple of 2352 4 bytes, the sender pads the identity with zero bytes when necessary. 2354 7.6 AT_RAND 2356 The format of the AT_RAND attribute is shown below. 2358 0 1 2 3 2359 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 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 | AT_RAND | Length = 5 | Reserved | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 | | 2364 | RAND | 2365 | | 2366 | | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2369 The value field of this attribute contains two reserved bytes 2370 followed by the AKA RAND parameter, 16 bytes (128 bits). The reserved 2371 bytes are set to zero when sending and ignored on reception. 2373 7.7 AT_AUTN 2375 The format of the AT_AUTN attribute is shown below. 2377 0 1 2 3 2378 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 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 | AT_AUTN | Length = 5 | Reserved | 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 | | 2383 | AUTN | 2384 | | 2385 | | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 The value field of this attribute contains two reserved bytes 2389 followed by the AKA AUTN parameter, 16 bytes (128 bits). The reserved 2390 bytes are set to zero when sending and ignored on reception. 2392 7.8 AT_RES 2394 The format of the AT_RES attribute is shown below. 2396 0 1 2 3 2397 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 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | AT_RES | Length | RES Length | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2401 | | 2402 | RES | 2403 | | 2404 | | 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 The value field of this attribute begins with the 2-byte RES Length, 2408 which is identifies the exact length of the RES in bits. The RES 2409 length is followed by the UMTS AKA RES parameter. According to [TS 2410 33.105] the length of the AKA RES can vary between 32 and 128 bits. 2411 Because the length of the AT_RES attribute must be a multiple of 4 2412 bytes, the sender pads the RES with zero bits where necessary. 2414 7.9 AT_AUTS 2416 The format of the AT_AUTS attribute is shown below. 2418 0 1 2 3 2419 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 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 2421 | AT_AUTS | Length = 4 | | 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2423 | | 2424 | AUTS | 2425 | | 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 The value field of this attribute contains the AKA AUTS parameter, 2429 112 bits (14 bytes). 2431 7.10 AT_NEXT_PSEUDONYM 2433 The format of the AT_NEXT_PSEUDONYM attribute is shown below. 2435 0 1 2 3 2436 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 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | AT_NEXT_PSEU..| Length | Actual Pseudonym Length | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 | | 2441 . Next Pseudonym . 2442 . . 2443 | | 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 The value field of this attribute begins with 2-byte actual pseudonym 2447 length which specifies the length of the following pseudonym in 2448 bytes. This field is followed by a pseudonym username that the peer 2449 can use in the next authentication. The username MUST NOT include any 2450 realm portion. The username does not include any terminating null 2451 characters. Because the length of the attribute must be a multiple of 2452 4 bytes, the sender pads the pseudonym with zero bytes when 2453 necessary. The username encoding MUST follow the UTF-8 transformation 2454 format [RFC2279]. This attribute MUST always be encrypted by 2455 encapsulating it within the AT_ENCR_DATA attribute. 2457 7.11 AT_NEXT_REAUTH_ID 2459 The format of the AT_NEXT_REAUTH_ID attribute is shown below. 2461 0 1 2 3 2462 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 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length| 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 | | 2467 . Next Fast Re-authentication Username . 2468 . . 2469 | | 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 The value field of this attribute begins with 2-byte actual 2473 re-authentication identity length which specifies the length of the 2474 following fast re-authentication identity in bytes. This field is 2475 followed by a fast re-authentication identity that the peer can use 2476 in the next fast re-authentication, as described in Section 4.2. In 2477 environments where a realm portion is required, the fast 2478 re-authentication identity includes both a username portion and a 2479 realm name portion. The fast re-authentication identity does not 2480 include any terminating null characters. Because the length of the 2481 attribute must be a multiple of 4 bytes, the sender pads the fast 2482 re-authentication identity with zero bytes when necessary. The 2483 identity encoding MUST follow the UTF-8 transformation format 2484 [RFC2279]. This attribute MUST always be encrypted by encapsulating 2485 it within the AT_ENCR_DATA attribute. 2487 7.12 AT_IV, AT_ENCR_DATA and AT_PADDING 2489 AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted 2490 information between the EAP-SIM peer and server. 2492 The value field of AT_IV contains two reserved bytes followed by a 2493 16-byte initialization vector required by the AT_ENCR_DATA attribute. 2494 The reserved bytes are set to zero when sending and ignored on 2495 reception. The AT_IV attribute MUST be included if and only if the 2496 AT_ENCR_DATA is included. Section 4.4 specifies the operation if a 2497 packet that does not meet this condition is encountered. 2499 The sender of the AT_IV attribute chooses the initialization vector 2500 by random. The sender MUST NOT reuse the initialization vector value 2501 from previous EAP-AKA packets. The sender SHOULD use a good source of 2502 randomness to generate the initialization vector. Please see 2503 [RFC1750] for more information about generating random numbers for 2504 security applications. The format of AT_IV is shown below. 2506 0 1 2 3 2507 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 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 | AT_IV | Length = 5 | Reserved | 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | | 2512 | Initialization Vector | 2513 | | 2514 | | 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 The value field of the AT_ENCR_DATA attribute consists of two 2518 reserved bytes followed by cipher text bytes encrypted using the 2519 Advanced Encryption Standard (AES) [AES] with a 128-bit key in the 2520 Cipher Block Chaining (CBC) mode of operation using the 2521 initialization vector from the AT_IV attribute. The reserved bytes 2522 are set to zero when sending and ignored on reception. Please see 2523 [CBC] for a description of the CBC mode. The format of the 2524 AT_ENCR_DATA attribute is shown below. 2526 0 1 2 3 2527 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 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 | AT_ENCR_DATA | Length | Reserved | 2530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 | | 2532 . Encrypted Data . 2533 . . 2534 | | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 The derivation of the encryption key (K_encr) is specified in Section 2538 4.5. 2540 The plaintext consists of nested EAP-AKA attributes. 2542 The encryption algorithm requires the length of the plaintext to be a 2543 multiple of 16 bytes. The sender may need to include the AT_PADDING 2544 attribute as the last attribute within AT_ENCR_DATA. The AT_PADDING 2545 attribute is not included if the total length of other nested 2546 attributes within the AT_ENCR_DATA attribute is a multiple of 16 2547 bytes. As usual, the Length of the Padding attribute includes the 2548 Attribute Type and Attribute Length fields. The length of the Padding 2549 attribute is 4, 8 or 12 bytes. It is chosen so that the length of the 2550 value field of the AT_ENCR_DATA attribute becomes a multiple of 16 2551 bytes. The actual pad bytes in the value field are set to zero (00 2552 hexadecimal) on sending. The recipient of the message MUST verify 2553 that the pad bytes are set to zero. If this verification fails on the 2554 peer, then it MUST send the EAP-Response/AKA-Client- Error packet 2555 with the error code "unable to process packet" to terminate the 2556 authentication exchange. If this verification fails on the server, 2557 then the server sends the EAP-Response/AKA-Notification packet with 2558 an AT_NOTIFICATION code that implies failure to terminate the 2559 authentication exchange. The format of the AT_PADDING attribute is 2560 shown below. 2562 0 1 2 3 2563 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 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 | AT_PADDING | Length | Padding... | 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2567 | | 2568 | | 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 7.13 AT_CHECKCODE 2573 The AT_MAC attribute is not used in the very first EAP-AKA messages 2574 during the AKA-Identity round, because keying material has not been 2575 derived yet. The peer and the server may exchange one or more pairs 2576 of EAP-AKA messages of the Subtype AKA-Identity before keys are 2577 derived and before the AT_MAC attribute can be applied. The EAP/ 2578 AKA-Identity messages may also be used upon fast re-authentication. 2580 The AT_CHECKCODE attribute MAY be used to protect the EAP/ 2581 AKA-Identity messages. AT_CHECKCODE is included in EAP-Request/ 2582 AKA-Challenge and/or EAP-Response/AKA-Challenge upon full 2583 authentication. In fast re-authentication, AT_CHECKCODE MAY be 2584 included in EAP-Request/AKA-Reauthentication and/or EAP-Response/ 2585 AKA-Reauthentication. Because the AT_MAC attribute is used in these 2586 messages, AT_CHECKCODE will be integrity protected with AT_MAC. The 2587 format of the AT_CHECKCODE attribute is shown below. 2589 0 1 2 3 2590 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 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 | AT_CHECKCODE | Length | Reserved | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 | | 2595 | Checkcode (0 or 20 bytes) | 2596 | | 2597 | | 2598 | | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 The value field of AT_CHECKCODE begins with two reserved bytes, which 2602 may be followed by a 20-byte checkcode. If the checkcode is not 2603 included in AT_CHECKCODE, then the attribute indicates that no EAP/ 2604 AKA-Identity messages were exchanged. This may occur in both full 2605 authentication and fast re-authentication. The reserved bytes are set 2606 to zero when sending and ignored on reception. 2608 The checkcode is a hash value, calculated with SHA1 [SHA-1], over all 2609 EAP-Request/AKA-Identity and EAP-Response/ AKA-Identity packets 2610 exchanged in this authentication exchange. The packets are included 2611 in the order that they were transmitted, that is, starting with the 2612 first EAP-Request/ AKA-Identity message, followed by the 2613 corresponding EAP-Response/ AKA-Identity, followed by the second 2614 EAP-Request/ AKA-Identity (if used) etc. 2616 EAP packets are included in the hash calculation "as-is", as they 2617 were transmitted or received. All reserved bytes, padding bytes etc. 2618 that are specified for various attributes are included as such, and 2619 the receiver must not reset them to zero. No delimiter bytes, padding 2620 or any other framing are included between the EAP packets when 2621 calculating the checkcode. 2623 Messages are included in request/response pairs; in other words only 2624 full "round trips" are included. Packets that are silently discarded 2625 are not included. The EAP server must only include an EAP-Request/ 2626 AKA-Identity in the calculation once it has received a corresponding 2627 response, with the same Identifier value. Retransmissions or requests 2628 to which the server does not receive response are not included. 2630 The peer must include the EAP-Request/AKA-Identity and the 2631 corresponding response in the calculation only if the peer receives a 2632 subsequent EAP-Request/AKA-Challenge, or a follow-up EAP-Request/ 2633 AKA-Identity with different attributes (attribute types) than in the 2634 first EAP-Request/AKA-Identity. After sending EAP-Response/ 2635 AKA-Identity, if the peer receives another EAP-Request/AKA-Identity 2636 with the same attributes as in the previous request, then the peer's 2637 response to the first request must have been lost. In this case the 2638 peer must not include the first request and its response in the 2639 calculation of the checkcode. 2641 The AT_CHECKCODE attribute is optional to implement. It is specified 2642 in order to allow protecting the EAP/AKA-Identity messages and any 2643 future extensions to them. The implementation of AT_CHECKCODE is 2644 RECOMMENDED. 2646 If the receiver of AT_CHECKCODE implements this attribute, then the 2647 receiver MUST check that the checkcode is correct. If the checkcode 2648 is invalid, the receiver must operate as specified in Section 4.4. 2650 If the EAP/AKA-Identity messages are extended with new attributes 2651 then AT_CHECKCODE MUST be implemented and used. More specifically, if 2652 the server includes any other attributes than AT_PERMANENT_ID_REQ, 2653 AT_FULLAUTH_ID_REQ or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity 2654 packet, then the server MUST include AT_CHECKCODE in EAP-Request/ 2655 AKA-Challenge or EAP-Request/AKA-Reauthentication. If the peer 2656 includes any other attributes than AT_IDENTITY in the EAP-Response/ 2657 AKA-Identity message, then the peer MUST include AT_CHECKCODE in 2658 EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication. 2660 If the server implements the processing of any other attribute than 2661 AT_IDENTITY for the EAP-Response/AKA-Identity message, then the 2662 server MUST implement AT_CHECKCODE. In this case, if the server 2663 receives any other attribute than AT_IDENTITY in the EAP- Response/ 2664 AKA-Identity message, then the server MUST check that AT_CHECKCODE is 2665 present in EAP-Response/AKA-Challenge or EAP- Response/ 2666 AKA-Reauthentication. The operation when a mandatory attribute is 2667 missing is specified in Section 4.4. 2669 Similarly, if the peer implements the processing of any other 2670 attribute than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ or 2671 AT_ANY_ID_REQ for the EAP-Request/AKA-Identity packet, then the peer 2672 MUST implement AT_CHECKCODE. In this case, if the peer receives any 2673 other attribute than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ or 2674 AT_ANY_ID_REQ in the EAP-Request/AKA-Identity packet, then the peer 2675 MUST check that AT_CHECKCODE is present in EAP-Request/AKA-Challenge 2676 or EAP-Request/AKA-Reauthentication. The operation when a mandatory 2677 attribute is missing is specified in Section 4.4. 2679 7.14 AT_RESULT_IND 2681 The format of the AT_RESULT_IND attribute is shown below. 2683 0 1 2 3 2684 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 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 | AT_RESULT_...| Length = 1 | Reserved | 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2689 The value field of this attribute consists of two reserved bytes, 2690 which are set to zero upon sending and ignored upon reception. This 2691 attribute is always sent unencrypted, so it MUST NOT be encapsulated 2692 within the AT_ENCR_DATA attribute. 2694 7.15 AT_MAC 2696 The AT_MAC attribute is used for EAP-AKA message authentication. 2697 Section 6 specifies which messages AT_MAC MUST be included. 2699 The value field of the AT_MAC attribute contains two reserved bytes 2700 followed by a keyed message authentication code (MAC). The MAC is 2701 calculated over the whole EAP packet, concatenated with optional 2702 message-specific data, with the exception that the value field of the 2703 MAC attribute is set to zero when calculating the MAC. The EAP packet 2704 includes the EAP header that begins with the Code field, the EAP-AKA 2705 header that begins with the Subtype field, and all the attributes, as 2706 specified in Section 5.1. The reserved bytes in AT_MAC are set to 2707 zero when sending and ignored on reception. The contents of the 2708 message-specific data that may be included in the MAC calculation are 2709 specified separately for each EAP-AKA message in Section 6. 2711 The format of the AT_MAC attribute is shown below. 2713 0 1 2 3 2714 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 2715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 | AT_MAC | Length = 5 | Reserved | 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 | | 2719 | MAC | 2720 | | 2721 | | 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The 2725 HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by 2726 truncating the output to 16 bytes. Hence, the length of the MAC is 16 2727 bytes.) The derivation of the authentication key (K_aut) used in the 2728 calculation of the MAC is specified in Section 4.5. 2730 When the AT_MAC attribute is included in an EAP-AKA message, the 2731 recipient MUST process the AT_MAC attribute before looking at any 2732 other attributes, except when processing EAP-Request/AKA-Challenge. 2733 The processing of EAP-Request/AKA-Challenge is specified in Section 2734 6.3. If the message authentication code is invalid, then the 2735 recipient MUST ignore all other attributes in the message and operate 2736 as specified in Section 4.4. 2738 7.16 AT_COUNTER 2740 The format of the AT_COUNTER attribute is shown below. 2742 0 1 2 3 2743 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 2744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 | AT_COUNTER | Length = 1 | Counter | 2746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2748 The value field of the AT_COUNTER attribute consists of a 16-bit 2749 unsigned integer counter value, represented in network byte order. 2750 This attribute MUST always be encrypted by encapsulating it within 2751 the AT_ENCR_DATA attribute. 2753 7.17 AT_COUNTER_TOO_SMALL 2755 The format of the AT_COUNTER_TOO_SMALL attribute is shown below. 2757 0 1 2 3 2758 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 2759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 | AT_COUNTER...| Length = 1 | Reserved | 2761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 The value field of this attribute consists of two reserved bytes, 2764 which are set to zero upon sending and ignored upon reception. This 2765 attribute MUST always be encrypted by encapsulating it within the 2766 AT_ENCR_DATA attribute. 2768 7.18 AT_NONCE_S 2770 The format of the AT_NONCE_S attribute is shown below. 2772 0 1 2 3 2773 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 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 | AT_NONCE_S | Length = 5 | Reserved | 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 | | 2778 | | 2779 | NONCE_S | 2780 | | 2781 | | 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 The value field of the AT_NONCE_S attribute contains two reserved 2785 bytes followed by a random number generated by the server (16 bytes) 2786 freshly for this EAP-AKA fast re-authentication. The random number is 2787 used as challenge for the peer and also a seed value for the new 2788 keying material. The reserved bytes are set to zero upon sending and 2789 ignored upon reception. This attribute MUST always be encrypted by 2790 encapsulating it within the AT_ENCR_DATA attribute. 2792 The server MUST NOT reuse the NONCE_S value from a previous EAP-AKA 2793 fast re-authentication exchange. The server SHOULD use a good source 2794 of randomness to generate NONCE_S. Please see [RFC1750] for more 2795 information about generating random numbers for security 2796 applications. 2798 7.19 AT_NOTIFICATION 2800 The format of the AT_NOTIFICATION attribute is shown below. 2802 0 1 2 3 2803 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 2804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2805 |AT_NOTIFICATION| Length = 1 |F|P| Notification Code | 2806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2808 The value field of this attribute contains a two-byte notification 2809 code. The first and second bit (F and P) of the notification code are 2810 interpreted as described in Section 4.3. 2812 The notification code values listed below have been reserved. The 2813 descriptions below illustrate the semantics of the notifications. The 2814 peer implementation MAY use different wordings when presenting the 2815 notifications to the user. The "requested service" depends on the 2816 environment where EAP-AKA is applied. 2818 0 - General failure. (implies failure, used after successful 2819 authentication) 2820 16384 - General failure. (implies failure, used before 2821 authentication) 2823 32768 - User has been successfully authenticated. (does not imply 2824 failure, used after successful authentication). The usage of this 2825 code is discussed in Section 4.3.2. 2827 1026 - User has been temporarily denied access to the requested 2828 service. (Implies failure, used after successful authentication) 2830 1031 - User has not subscribed to the requested service (implies 2831 failure, used after successful authentication) 2833 7.20 AT_CLIENT_ERROR_CODE 2835 The format of the AT_CLIENT_ERROR_CODE attribute is shown below. 2837 0 1 2 3 2838 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 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 |AT_CLIENT_ERR..| Length = 1 | Client Error Code | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 The value field of this attribute contains a two-byte client error 2844 code. The following error code values have been reserved. 2846 0 "unable to process packet": a general error code 2848 8. IANA and Protocol Numbering Considerations 2850 IANA has assigned the EAP type number 23 for EAP-AKA authentication. 2852 EAP-AKA messages include a Subtype field. The Subtype is a new 2853 numbering space for which IANA administration is required. The 2854 following Subtypes are specified in this document: 2856 AKA-Challenge...................................1 2857 AKA-Authentication-Reject.......................2 2858 AKA-Synchronization-Failure.....................4 2859 AKA-Identity....................................5 2860 AKA-Notification...............................12 2861 AKA-Reauthentication...........................13 2862 AKA-Client-Error...............................14 2864 The messages are composed of attributes, which have attribute type 2865 numbers. The EAP-AKA attribute type number is a new numbering space 2866 for which IANA administration is required. The following attribute 2867 types are specified in this document: 2869 AT_RAND.........................................1 2870 AT_AUTN.........................................2 2871 AT_RES..........................................3 2872 AT_AUTS.........................................4 2873 AT_PADDING......................................6 2874 AT_PERMANENT_ID_REQ............................10 2875 AT_MAC.........................................11 2876 AT_NOTIFICATION................................12 2877 AT_ANY_ID_REQ..................................13 2878 AT_IDENTITY....................................14 2879 AT_FULLAUTH_ID_REQ.............................17 2880 AT_COUNTER.....................................19 2881 AT_COUNTER_TOO_SMALL...........................20 2882 AT_NONCE_S.....................................21 2883 AT_CLIENT_ERROR_CODE...........................22 2884 AT_IV.........................................129 2885 AT_ENCR_DATA..................................130 2886 AT_NEXT_PSEUDONYM.............................132 2887 AT_NEXT_REAUTH_ID.............................133 2888 AT_CHECKCODE..................................134 2889 AT_RESULT_IND.................................135 2891 The AT_NOTIFICATION attribute contains a notification code value. The 2892 notification code is a new numbering space for which IANA 2893 administration is required. Values 0, 1024, 1026, 1031, 16384 and 2894 32768 have been specified in Section 7.19 of this document. 2896 The AT_CLIENT_ERROR_CODE attribute contains a client error code. The 2897 client error code is a new numbering space for which IANA 2898 administration is required. Value 0 has been specified in Section 2899 7.20 of this document. 2901 All requests for value assignment from the various number spaces 2902 described in this document require proper documentation, according to 2903 the "Specification Required" policy described in [RFC2434]. Requests 2904 must be specified in sufficient detail so that interoperability 2905 between independent implementations is possible. Possible forms of 2906 documentation include, but are not limited to, RFCs, the products of 2907 another standards body (e.g. 3GPP), or permanently and readily 2908 available vendor design notes. 2910 EAP-AKA and EAP-SIM [EAP-SIM] are "sister" protocols with similar 2911 message structure and protocol numbering spaces. Many attributes and 2912 message Subtypes have the same protocol numbers in these two 2913 protocols. Hence, it is recommended that the same protocol number 2914 value SHOULD NOT be allocated for two different purposes in EAP-AKA 2915 and EAP-SIM. 2917 9. Security Considerations 2919 The EAP base protocol specification [EAP] highlights several attacks 2920 that are possible against the EAP protocol. This section discusses 2921 the claimed security properties of EAP-AKA as well as vulnerabilities 2922 and security recommendations. 2924 9.1 Identity Protection 2926 EAP-AKA includes optional Identity privacy support that protects the 2927 privacy of the subscriber identity against passive eavesdropping. 2928 This document only specifies a mechanism to deliver pseudonyms from 2929 the server to the peer as part of an EAP-SIM exchange. Hence, a peer 2930 that has not yet performed any EAP-SIM exchanges does not typically 2931 have a pseudonym available. If the peer does not have a pseudonym 2932 available, then the privacy mechanism cannot be used, but the 2933 permanent identity will have to be sent in the clear. The terminal 2934 SHOULD store the pseudonym in a non-volatile memory so that it can be 2935 maintained across reboots. An active attacker that impersonates the 2936 network may use the AT_PERMANENT_ID_REQ attribute (Section 4.1.2) to 2937 learn the subscriber's IMSI. However, as discussed in Section 4.1.2, 2938 the terminal can refuse to send the cleartext IMSI if it believes 2939 that the network should be able to recognize the pseudonym. 2941 If the peer and server cannot guarantee that the pseudonym will be 2942 maintained reliably and Identity privacy is required then additional 2943 protection from an external security mechanism such as Protected 2944 Extensible Authentication Protocol (PEAP) [PEAP] may be used. The 2945 benefits and the security considerations of using an external 2946 security mechanism with EAP-AKA are beyond the scope of this 2947 document. 2949 9.2 Mutual Authentication 2951 EAP-AKA provides mutual authentication via the UMTS AKA mechanisms. 2953 9.3 Flooding the Authentication Centre 2955 The EAP-AKA server typically obtains authentication vectors from the 2956 Authentication Centre (AuC). EAP-AKA introduces a new usage for the 2957 AuC. The protocols between the EAP-AKA server and the AuC are out of 2958 the scope of this document. However, it should be noted that a 2959 malicious EAP-AKA peer may generate a lot of protocol requests to 2960 mount a denial of service attack. The EAP-AKA server implementation 2961 SHOULD take this into account and SHOULD take steps to limit the 2962 traffic that it generates towards the AuC, preventing the attacker 2963 from flooding the AuC and from extending the denial of service attack 2964 from EAP-AKA to other users of the AuC. 2966 9.4 Key Derivation 2968 EAP-AKA supports key derivation with 128-bit effective key strength. 2969 The key hierarchy is specified in Section 4.5. 2971 The Transient EAP Keys used to protect EAP-AKA packets (K_encr, 2972 K_aut) and the Master Session Keys are cryptographically separate. An 2973 attacker cannot derive any non-trivial information from K_encr or 2974 K_aut based on the Master Session Key or vice versa. An attacker also 2975 cannot calculate the pre-shared secret from the UMTS AKA IK, UMTS AKA 2976 CK, EAP-AKA K_encr, EAP-AKA K_aut or from the Master Session Key. 2978 9.5 Brute-Force and Dictionary Attacks 2980 The effective strength of EAP-AKA values is 128 bits, and there are 2981 no known computationally feasible brute-force attacks. Because UMTS 2982 AKA is not a password protocol (the pre-shared secret must not be a 2983 weak password), EAP-AKA is not vulnerable to dictionary attacks. 2985 9.6 Protection, Replay Protection and Confidentiality 2987 AT_MAC, AT_IV, AT_ENCR_DATA and AT_COUNTER attributes are used to 2988 provide integrity, replay and confidentiality protection for EAP-AKA 2989 Requests and Responses. Integrity protection with AT_MAC includes the 2990 EAP header. Integrity protection (AT_MAC) is based on a keyed message 2991 authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is 2992 based on a block cipher. 2994 Because keys are not available in the beginning of the EAP methods, 2995 the AT_MAC attribute cannot be used for protecting EAP/AKA-Identity 2996 messages. However, the AT_CHECKCODE attribute can optionally be used 2997 to protect the integrity of the EAP/AKA-Identity roundtrip. 2999 Confidentiality protection is applied only to a part of the protocol 3000 fields. The table of attributes in Section 7.1 summarizes which 3001 fields are confidentiality protected. It should be noted that the 3002 error and notification code attributes AT_CLIENT_ERROR_CODE and 3003 AT_NOTIFICATION are not confidential but they are transmitted in the 3004 clear. Identity protection is discussed in Section 9.1. 3006 On full authentication, replay protection of the EAP exchange is 3007 provided by RAND and AUTN values from the underlying UMTS AKA scheme. 3008 Protection against replays of EAP-AKA messages is also based on the 3009 fact that messages that can include AT_MAC can only be sent once with 3010 a certain EAP-AKA Subtype, and on the fact that a different K_aut key 3011 will be used for calculating AT_MAC in each full authentication 3012 exchange. 3014 On fast re-authentication, a counter included in AT_COUNTER and a 3015 server random nonce is used to provide replay protection. The 3016 AT_COUNTER attribute is also included in EAP-AKA notifications, if 3017 they are used after successful authentication in order to provide 3018 replay protection between re-authentication exchanges. 3020 The contents of the user identity string are implicitly integrity 3021 protected by including them in key derivation. 3023 Because EAP-AKA is not a tunneling method, EAP-Request/Notification, 3024 EAP-Response/Notification, EAP-Success or EAP-Failure packets are not 3025 confidential, integrity protected or replay protected. On physically 3026 insecure networks, this may enable an attacker to mount denial of 3027 service attacks by spoofing these packets. As discussed in Section 3028 4.4, the peer will only accept EAP-Success after successful 3029 authentication. Hence, the attacker cannot force the peer to believe 3030 successful authentication has occurred when mutual authentication 3031 failed or has not happened yet. 3033 The security considerations of EAP-AKA result indications are covered 3034 in Section 9.8 3036 An eavesdropper will see the EAP Notification, EAP_Success and 3037 EAP-Failure packets sent in the clear. With EAP-AKA, confidential 3038 information MUST NOT be transmitted in EAP Notification packets. 3040 9.7 Negotiation Attacks 3042 EAP-AKA does not protect the EAP-Response/Nak packet. Because EAP-AKA 3043 does not protect the EAP method negotiation, EAP method downgrading 3044 attacks may be possible, especially if the user uses the same 3045 identity with EAP-AKA and other EAP methods. 3047 As described in Section 5, EAP-AKA allows the protocol to be extended 3048 by defining new attribute types. When defining such attributes, it 3049 should be noted that any extra attributes included in EAP-Request/ 3050 AKA-Identity or EAP-Response/AKA-Identity packets are not included in 3051 the MACs later on, and thus some other precautions must be taken to 3052 avoid modifications to them. 3054 EAP-AKA does not support ciphersuite negotiation or EAP-AKA protocol 3055 version negotiation. 3057 9.8 Protected Result Indications 3059 EAP-AKA supports optional protected success indications, and 3060 acknowledged failure indications. If a failure occurs after 3061 successful authentication, then the EAP-AKA failure indication is 3062 integrity and replay protected. 3064 Even if an EAP-Failure packet is lost when using EAP-SIM over an 3065 unreliable medium, then the EAP-SIM failure indications will help 3066 ensure that the peer and EAP server will know the other parties 3067 authentication decision. If protected success indications are used, 3068 then the loss of Success packet will also be addressed by the 3069 acknowledged, integrity and replay protected EAP-SIM success 3070 indication. If the optional success indications are not used, then 3071 the peer may end up believing the server succeeded authentication 3072 when it actually failed. Since access will not be granted in this 3073 case protected result indications are not needed unless the client is 3074 not able to realize it does not have access for an extended period of 3075 time. 3077 9.9 Man-in-the-middle Attacks 3079 In order to avoid man-in-the-middle attacks and session hijacking, 3080 user data SHOULD be integrity protected on physically insecure 3081 networks. The EAP-AKA Master Session Key or keys derived from it MAY 3082 be used as the integrity protection keys, or, if an external security 3083 mechanism such as PEAP is used, then the link integrity protection 3084 keys MAY be derived by the external security mechanism. 3086 There are man-in-the-middle attacks associated with the use of any 3087 EAP method within a tunneled protocol such as PEAP, or within a 3088 sequence of EAP methods followed by each other. This specification 3089 does not address these attacks. If EAP-AKA is used with a tunneling 3090 protocol or as part of a sequence of methods, there should be 3091 cryptographic binding provided between the protocols and EAP-AKA to 3092 prevent man-in-the-middle attacks through rogue authenticators being 3093 able to setup one-way authenticated tunnels. EAP-AKA Master Session 3094 Key MAY be used to provide the cryptographic binding. However the 3095 mechanism how the binding is provided depends on the tunneling or 3096 sequencing protocol, and it is beyond the scope of this document. 3098 9.10 Generating Random Numbers 3100 An EAP-AKA implementation SHOULD use a good source of randomness to 3101 generate the random numbers required in the protocol. Please see 3102 [RFC1750] for more information on generating random numbers for 3103 security applications. 3105 10. Security Claims 3107 This section provides the security claims required by [EAP]. 3109 Auth. Mechanism: EAP-AKA is based on the UMTS AKA mechanism, which is 3110 an authentication and key agreement mechanism based on a symmetric 3111 128-bit pre-shared secret. 3113 Ciphersuite negotiation: No 3115 Mutual authentication: Yes 3117 Integrity protection: Yes (Section 9.6) 3119 Replay protection: Yes (Section 9.6) 3121 Confidentiality: Yes, except method specific success and failure 3122 indications (Section 9.1, Section 9.6) 3124 Key derivation: Yes 3126 Key strength: EAP-AKA supports key derivation with 128-bit effective 3127 key strength. 3129 Description of key hierarchy: Please see Section 4.5. 3131 Dictinary attack protection: N/A (Section 9.5) 3133 Fast reconnect: Yes 3135 Cryptographic binding: N/A 3137 Session independence: Yes (Section 9.4) 3139 Fragmentation: No 3141 Channel binding: No 3143 Indication of vulnerabilities. Vulnerabilities are discussed in 3144 Section 9. 3146 11. Acknowledgements and Contributions 3148 The authors wish to thank Rolf Blom of Ericsson, Bernard Aboba of 3149 Microsoft, Arne Norefors of Ericsson, N.Asokan of Nokia, Valtteri 3150 Niemi of Nokia, Kaisa Nyberg of Nokia, Jukka-Pekka Honkanen of Nokia, 3151 Pasi Eronen of Nokia, Olivier Paridaens of Alcatel and Ilkka Uusitalo 3152 of Ericsson for interesting discussions in this problem space. 3154 This protocol has been partly developed in parallel with EAP-SIM 3155 [EAP-SIM], and hence this specification incorporates many ideas from 3156 EAP-SIM, and many contributions from the reviewer's of EAP-SIM. 3158 The attribute format is based on the extension format of Mobile IPv4 3159 [RFC3344]. 3161 Normative References 3163 [TS 33.102] 3164 3rd Generation Partnership Project, "3GPP Technical 3165 Specification 3GPP TS 33.102 V5.1.0: "Technical 3166 Specification Group Services and System Aspects; 3G 3167 Security; Security Architecture (Release 5)"", December 3168 2002. 3170 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 3171 RFC 2486, January 1999. 3173 [EAP] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. 3174 Levkowetz, "Extensible Authentication Protocol (EAP)", 3175 draft-ietf-eap-rfc2284bis-09 (work in progress), February 3176 2004. 3178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3179 Requirement Levels", BCP 14, RFC 2119, March 1997. 3181 [TS 23.003] 3182 3rd Generation Partnership Project, "3GPP Technical 3183 Specification 3GPP TS 23.003 V5.5.1: "3rd Generation 3184 Parnership Project; Technical Specification Group Core 3185 Network; Numbering, addressing and identification (Release 3186 5)"", January 2003. 3188 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 3189 Keyed-Hashing for Message Authentication", RFC 2104, 3190 February 1997. 3192 [AES] National Institute of Standards and Technology, "Federal 3193 Information Processing Standards (FIPS) Publication 197, 3194 "Advanced Encryption Standard (AES)"", November 2001. 3196 http://csrc.nist.gov/publications/fips/fips197/ 3197 fips-197.pdf 3199 [CBC] National Institute of Standards and Technology, "NIST 3200 Special Publication 800-38A, "Recommendation for Block 3201 Cipher Modes of Operation - Methods and Techniques"", 3202 December 2001. 3204 http://csrc.nist.gov/publications/nistpubs/800-38a/ 3205 sp800-38a.pdf 3207 [SHA-1] National Institute of Standards and Technology, U.S. 3208 Department of Commerce, "Federal Information Processing 3209 Standard (FIPS) Publication 180-1, "Secure Hash 3210 Standard"", April 1995. 3212 [PRF] National Institute of Standards and Technology, "Federal 3213 Information Processing Standards (FIPS) Publication 186-2 3214 (with change notice); Digital Signature Standard (DSS)", 3215 January 2000. 3217 Available on-line at: http://csrc.nist.gov/publications/ 3218 fips/fips186-2/fips186-2-change1.pdf 3220 [TS 33.105] 3221 3rd Generation Partnership Project, "3GPP Technical 3222 Specification 3GPP TS 33.105 4.1.0: "Technical 3223 Specification Group Services and System Aspects; 3G 3224 Security; Cryptographic Algorithm Requirements (Release 3225 4)"", June 2001. 3227 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 3228 10646", RFC 2279, January 1998. 3230 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3231 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3232 October 1998. 3234 Informative References 3236 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 3237 RFC 2548, March 1999. 3239 [PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H. 3240 and S. Josefsson, "Protected EAP Protocol (PEAP)", 3241 draft-josefsson-pppext-eap-tls-eap-07 (work in progress), 3242 October 2003. 3244 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 3245 Recommendations for Security", RFC 1750, December 1994. 3247 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 3248 August 2002. 3250 [EAP-SIM] Haverinen, H. and J. Salowey, "Extensible Authentication 3251 Protocol Method for GSM Subscriber Identity Modules 3252 (EAP-SIM)", draft-haverinen-pppext-eap-sim-13 (work in 3253 progress), April 2004. 3255 [Draft 3GPP TS 23.003] 3256 3rd Generation Partnership Project, "Draft 3GPP Technical 3257 Specification 3GPP TS 23.003 V 6.1.0: "3rd Generation 3258 Partnership Project; Technical Specification Group Core 3259 Network; Numbering, addressing and identification (Release 3260 6)", December 2003. 3262 work in progress 3264 Authors' Addresses 3266 Jari Arkko 3267 Ericsson 3268 FIN-02420 Jorvas 3269 Finland 3271 Phone: +358 40 5079256 3272 EMail: jari.Arkko@ericsson.com 3274 Henry Haverinen 3275 Nokia Enterprise Solutions 3276 P.O. Box 12 3277 FIN-40101 Jyvaskyla 3278 Finland 3280 EMail: henry.haverinen@nokia.com 3282 Appendix A. Pseudo-Random Number Generator 3284 The "|" character denotes concatenation, and "^" denotes 3285 exponentiation. 3287 Step 1: Choose a new, secret value for the seed-key, XKEY 3289 Step 2: In hexadecimal notation let 3290 t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 3291 This is the initial value for H0|H1|H2|H3|H4 3292 in the FIPS SHS 3294 Step 3: For j = 0 to m - 1 do 3295 3.1 XSEED_j = 0 /* no optional user input */ 3296 3.2 For i = 0 to 1 do 3297 a. XVAL = (XKEY + XSEED_j) mod 2^b 3298 b. w_i = G(t, XVAL) 3299 c. XKEY = (1 + XKEY + w_i) mod 2^b 3300 3.3 x_j = w_0|w_1 3302 Intellectual Property Statement 3304 The IETF takes no position regarding the validity or scope of any 3305 intellectual property or other rights that might be claimed to 3306 pertain to the implementation or use of the technology described in 3307 this document or the extent to which any license under such rights 3308 might or might not be available; neither does it represent that it 3309 has made any effort to identify any such rights. Information on the 3310 IETF's procedures with respect to rights in standards-track and 3311 standards-related documentation can be found in BCP-11. Copies of 3312 claims of rights made available for publication and any assurances of 3313 licenses to be made available, or the result of an attempt made to 3314 obtain a general license or permission for the use of such 3315 proprietary rights by implementors or users of this specification can 3316 be obtained from the IETF Secretariat. 3318 The IETF invites any interested party to bring to its attention any 3319 copyrights, patents or patent applications, or other proprietary 3320 rights which may cover technology that may be required to practice 3321 this standard. Please address the information to the IETF Executive 3322 Director. 3324 The IETF has been notified of intellectual property rights claimed in 3325 regard to some or all of the specification contained in this 3326 document. For more information consult the online list of claimed 3327 rights. 3329 Full Copyright Statement 3331 Copyright (C) The Internet Society (2004). All Rights Reserved. 3333 This document and translations of it may be copied and furnished to 3334 others, and derivative works that comment on or otherwise explain it 3335 or assist in its implementation may be prepared, copied, published 3336 and distributed, in whole or in part, without restriction of any 3337 kind, provided that the above copyright notice and this paragraph are 3338 included on all such copies and derivative works. However, this 3339 document itself may not be modified in any way, such as by removing 3340 the copyright notice or references to the Internet Society or other 3341 Internet organizations, except as needed for the purpose of 3342 developing Internet standards in which case the procedures for 3343 copyrights defined in the Internet Standards process must be 3344 followed, or as required to translate it into languages other than 3345 English. 3347 The limited permissions granted above are perpetual and will not be 3348 revoked by the Internet Society or its successors or assignees. 3350 This document and the information contained herein is provided on an 3351 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3352 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3353 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3354 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3355 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3357 Acknowledgment 3359 Funding for the RFC Editor function is currently provided by the 3360 Internet Society.