idnits 2.17.1 draft-haverinen-pppext-eap-sim-13.txt: -(3270): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3291): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 16 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 471 has weird spacing: '...tor and help ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 5, 2004) is 7326 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) ** 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 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) == 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: A later version (-16) exists of draft-arkko-pppext-eap-aka-12 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Haverinen, Ed. 2 Internet-Draft Nokia 3 Expires: October 4, 2004 J. Salowey, Ed. 4 Cisco Systems 5 April 5, 2004 7 Extensible Authentication Protocol Method for GSM Subscriber Identity 8 Modules (EAP-SIM) 9 draft-haverinen-pppext-eap-sim-13.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 GSM Subscriber Identity Module (SIM). The mechanism specifies 42 enhancements to GSM authentication and key agreement whereby multiple 43 authentication triplets can be combined to create authentication 44 responses and session keys of greater strength than the individual 45 GSM triplets. The mechanism also includes network authentication, 46 user anonymity support, result indications, and a fast 47 re-authentication procedure. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . 10 55 4.1 Version Negotiation . . . . . . . . . . . . . . . . . . . 10 56 4.2 Identity Management . . . . . . . . . . . . . . . . . . . 10 57 4.2.1 Format, Generation and Usage of Peer Identities . . . . . 10 58 4.2.2 Communicating the Peer Identity to the Server . . . . . . 17 59 4.2.3 Message Sequence Examples (Informative) . . . . . . . . . 22 60 4.3 Fast Re-Authentication . . . . . . . . . . . . . . . . . . 29 61 4.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 29 62 4.3.2 Comparison to UMTS AKA . . . . . . . . . . . . . . . . . . 30 63 4.3.3 Fast Re-authentication Identity . . . . . . . . . . . . . 31 64 4.3.4 Fast Re-authentication Procedure . . . . . . . . . . . . . 32 65 4.3.5 Fast Re-authentication Procedure when Counter is Too 66 Small . . . . . . . . . . . . . . . . . . . . . . . . . . 34 67 4.4 EAP-SIM Notifications . . . . . . . . . . . . . . . . . . 36 68 4.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 36 69 4.4.2 Result Indications . . . . . . . . . . . . . . . . . . . . 37 70 4.5 Error Cases . . . . . . . . . . . . . . . . . . . . . . . 38 71 4.5.1 Peer Operation . . . . . . . . . . . . . . . . . . . . . . 38 72 4.5.2 Server Operation . . . . . . . . . . . . . . . . . . . . . 39 73 4.5.3 EAP-Failure . . . . . . . . . . . . . . . . . . . . . . . 39 74 4.5.4 EAP-Success . . . . . . . . . . . . . . . . . . . . . . . 40 75 4.6 Key Generation . . . . . . . . . . . . . . . . . . . . . . 41 76 5. Message Format and Protocol Extensibility . . . . . . . . 43 77 5.1 Message Format . . . . . . . . . . . . . . . . . . . . . . 43 78 5.2 Protocol Extensibility . . . . . . . . . . . . . . . . . . 45 79 6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 46 80 6.1 EAP-Request/SIM/Start . . . . . . . . . . . . . . . . . . 46 81 6.2 EAP-Response/SIM/Start . . . . . . . . . . . . . . . . . . 46 82 6.3 EAP-Request/SIM/Challenge . . . . . . . . . . . . . . . . 47 83 6.4 EAP-Response/SIM/Challenge . . . . . . . . . . . . . . . . 48 84 6.5 EAP-Request/SIM/Re-authentication . . . . . . . . . . . . 48 85 6.6 EAP-Response/SIM/Re-authentication . . . . . . . . . . . . 49 86 6.7 EAP-Response/SIM/Client-Error . . . . . . . . . . . . . . 50 87 6.8 EAP-Request/SIM/Notification . . . . . . . . . . . . . . . 50 88 6.9 EAP-Response/SIM/Notification . . . . . . . . . . . . . . 50 89 7. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 51 90 7.1 Table of Attributes . . . . . . . . . . . . . . . . . . . 51 91 7.2 AT_VERSION_LIST . . . . . . . . . . . . . . . . . . . . . 52 92 7.3 AT_SELECTED_VERSION . . . . . . . . . . . . . . . . . . . 53 93 7.4 AT_NONCE_MT . . . . . . . . . . . . . . . . . . . . . . . 53 94 7.5 AT_PERMANENT_ID_REQ . . . . . . . . . . . . . . . . . . . 54 95 7.6 AT_ANY_ID_REQ . . . . . . . . . . . . . . . . . . . . . . 54 96 7.7 AT_FULLAUTH_ID_REQ . . . . . . . . . . . . . . . . . . . . 54 97 7.8 AT_IDENTITY . . . . . . . . . . . . . . . . . . . . . . . 55 98 7.9 AT_RAND . . . . . . . . . . . . . . . . . . . . . . . . . 55 99 7.10 AT_NEXT_PSEUDONYM . . . . . . . . . . . . . . . . . . . . 56 100 7.11 AT_NEXT_REAUTH_ID . . . . . . . . . . . . . . . . . . . . 57 101 7.12 AT_IV, AT_ENCR_DATA and AT_PADDING . . . . . . . . . . . . 57 102 7.13 AT_RESULT_IND . . . . . . . . . . . . . . . . . . . . . . 59 103 7.14 AT_MAC . . . . . . . . . . . . . . . . . . . . . . . . . . 59 104 7.15 AT_COUNTER . . . . . . . . . . . . . . . . . . . . . . . . 60 105 7.16 AT_COUNTER_TOO_SMALL . . . . . . . . . . . . . . . . . . . 61 106 7.17 AT_NONCE_S . . . . . . . . . . . . . . . . . . . . . . . . 61 107 7.18 AT_NOTIFICATION . . . . . . . . . . . . . . . . . . . . . 61 108 7.19 AT_CLIENT_ERROR_CODE . . . . . . . . . . . . . . . . . . . 62 109 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 63 110 9. Security Considerations . . . . . . . . . . . . . . . . . 65 111 9.1 Identity Protection . . . . . . . . . . . . . . . . . . . 65 112 9.2 Mutual Authentication and Triplet Exposure . . . . . . . . 65 113 9.3 Flooding the Authentication Centre . . . . . . . . . . . . 66 114 9.4 Key Derivation . . . . . . . . . . . . . . . . . . . . . . 67 115 9.5 Dictionary Attacks . . . . . . . . . . . . . . . . . . . . 68 116 9.6 Credentials Reuse . . . . . . . . . . . . . . . . . . . . 68 117 9.7 Integrity and Replay Protection, and Confidentiality . . . 68 118 9.8 Negotiation Attacks . . . . . . . . . . . . . . . . . . . 70 119 9.9 Protected Result Indications . . . . . . . . . . . . . . . 70 120 9.10 Man-in-the-middle Attacks . . . . . . . . . . . . . . . . 70 121 9.11 Generating Random Numbers . . . . . . . . . . . . . . . . 71 122 10. Security Claims . . . . . . . . . . . . . . . . . . . . . 71 123 11. Acknowledgements and Contributions . . . . . . . . . . . . 72 124 11.1 Contributors . . . . . . . . . . . . . . . . . . . . . . . 72 125 11.2 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 72 126 11.2.1 Contributors' Addresses . . . . . . . . . . . . . . . . . 73 127 Normative References . . . . . . . . . . . . . . . . . . . 73 128 Informative References . . . . . . . . . . . . . . . . . . 75 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 75 130 A. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 76 131 A.1 EAP-Request/Identity . . . . . . . . . . . . . . . . . . . 76 132 A.2 EAP-Response/Identity . . . . . . . . . . . . . . . . . . 76 133 A.3 EAP-Request/SIM/Start . . . . . . . . . . . . . . . . . . 77 134 A.4 EAP-Response/SIM/Start . . . . . . . . . . . . . . . . . . 77 135 A.5 EAP-Request/SIM/Challenge . . . . . . . . . . . . . . . . 78 136 A.6 EAP-Response/SIM/Challenge . . . . . . . . . . . . . . . . 80 137 A.7 EAP-Success . . . . . . . . . . . . . . . . . . . . . . . 81 138 A.8 Fast Re-authentication . . . . . . . . . . . . . . . . . . 81 139 A.9 EAP-Request/SIM/Re-authentication . . . . . . . . . . . . 81 140 A.10 EAP-Response/SIM/Re-authentication . . . . . . . . . . . . 84 141 B. Pseudo-Random Number Generator . . . . . . . . . . . . . . 85 142 Intellectual Property and Copyright Statements . . . . . . 86 144 1. Introduction 146 This document specifies an Extensible Authentication Protocol (EAP) 147 [EAP] mechanism for authentication and session key distribution using 148 the GSM Subscriber Identity Module (SIM). 150 GSM authentication is based on a challenge-response mechanism. The 151 A3/A8 authentication and key derivation algorithms that run on the 152 SIM can be given a 128-bit random number (RAND) as a challenge. The 153 SIM runs operator-specific algorithms, which take the RAND and a 154 secret key Ki stored on the SIM as input, and produce a 32-bit 155 response (SRES) and a 64-bit long key Kc as output. The Kc key is 156 originally intended to be used as an encryption key over the air 157 interface, but in this protocol it is used for deriving keying 158 material and not directly used. Hence the secrecy of Kc is critical 159 to the security of this protocol. Please find more information about 160 GSM authentication in [GSM 03.20]. 162 The lack of mutual authentication is a weakness in GSM 163 authentication. The 64 bit cipher key (Kc) that is derived is not 164 strong enough for data networks where stronger and longer keys are 165 required. Hence in EAP-SIM, several RAND challenges are used for 166 generating several 64-bit Kc keys, which are combined to constitute 167 stronger keying material. In EAP-SIM the client issues a random 168 number NONCE_MT to the network, in order to contribute to key 169 derivation, and to prevent replays of EAP-SIM requests from previous 170 exchanges. The NONCE_MT can be conceived as the client's challenge to 171 the network. EAP-SIM also extends the combined RAND challenges and 172 other messages with a message authentication code in order to provide 173 message integrity protection along with mutual authentication. 175 EAP-SIM specifies optional support for protecting the privacy of 176 subscriber identity using the same concept as GSM, which is using 177 pseudonyms/temporary identifiers. It also specifies an optional fast 178 re-authentication procedure. 180 The security of EAP-SIM builds on underlying GSM mechanisms. The 181 security properties of EAP-SIM are documented in Section 9 of this 182 document. Implementers and users of EAP-SIM are advised to carefully 183 study the security considerations in Section 9 in order to determine 184 whether the security properties are sufficient for the environment in 185 question, especially as the secrecy of Kc keys is key to the security 186 of EAP-SIM. In brief, EAP-SIM is in no sense weaker than the GSM 187 mechanisms. In some cases EAP-SIM provides better security properties 188 than the underlying GSM mechanisms, particularly if the SIM 189 credentials are only used for EAP-SIM and not re-used from GSM/GPRS. 190 Many of the security features of EAP_SIM rely upon the secrecy of the 191 Kc values in the SIM triplets, so protecting these values is key to 192 the security of the EAP-SIM protocol. In any case, if the GSM 193 authentication mechanisms are considered to be sufficient for use on 194 the cellular networks, then EAP-SIM is expected to be sufficiently 195 secure for other networks. 197 The 3rd Generation Partnership Project (3GPP) has specified an 198 enhanced Authentication and Key Agreement (AKA) architecture for the 199 Universal Mobile Telecommunications System (UMTS). The UMTS AKA 200 mechanism includes mutual authentication, replay protection and 201 derivation of longer session keys. EAP-AKA [EAP-AKA] specifies an 202 EAP method that is based on UMTS AKA. EAP-AKA, which is a more secure 203 protocol, may be used instead of EAP-SIM, if USIMs and 3G network 204 infrastructure are available. 206 2. Terms 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in [RFC2119]. 212 The terms and abbreviations "authenticator", "backend authentication 213 server", "EAP server", "peer", "Silently Discard", "Master Session 214 Key (MSK)", and "Extended Master Session Key (EMSK)" in this document 215 are to be interpreted as described in [EAP]. 217 This document frequently uses the following terms and abbreviations: 219 AAA protocol 221 Authentication, Authorization and Accounting protocol 223 AuC 225 Authentication Centre. The GSM network element that provides the 226 authentication triplets for authenticating the subscriber. 228 Authentication vector 230 GSM triplets can be alternatively called authentication vectors. 232 EAP 234 Extensible Authentication Protocol. 236 Fast Re-authentication Identity 238 A fast re-authentication identity of the peer, including an NAI realm 239 portion in environments where a realm is used. Used on fast re- 240 authentication only. 242 Fast Re-authentication Username 244 The username portion of fast re-authentication identity, ie. not 245 including any realm portions. 247 GSM 249 Global System for Mobile communications. 251 GSM Triplet 253 The tuple formed by the three GSM authentication values RAND, Kc 254 and SRES 256 IMSI 258 International Mobile Subscriber Identifier, used in GSM to 259 identify subscribers. 261 MAC 263 Message Authentication Code 265 NAI 267 Network Access Identifier 269 Nonce 271 A value that is used at most once or that is never repeated 272 within the same cryptographic context. In general, a nonce can be 273 predictable (e.g. a counter) or unpredictable (e.g. a random value). 274 Since some cryptographic properties may depend on the randomness of 275 the nonce, attention should be paid to whether a nonce is required 276 to be random or not. In this document, the term nonce is only 277 used to denote random nonces, and it is not used to denote counters. 279 Permanent Identity 281 The permanent identity of the peer, including an NAI realm 282 portion in environments where a realm is used. The permanent 283 identity is usually based on the IMSI. Used on full 284 authentication only. 286 Permanent Username 287 The username portion of permanent identity, ie. not including any 288 realm portions. 290 Pseudonym Identity 292 A pseudonym identity of the peer, including an NAI realm portion 293 in environments where a realm is used. Used on full authentication 294 only. 296 Pseudonym Username 298 The username portion of pseudonym identity, ie. not including any 299 realm portions. 301 SIM 303 Subscriber Identity Module. The SIM is traditionally a smart card 304 distributed by a GSM operator. 306 3. Overview 308 Figure 1 shows an overview of the EAP-SIM full authentication 309 procedure, when optional protected success indications are not used. 310 The authenticator typically communicates with an EAP server that is 311 located on a backend authentication server using an AAA protocol. The 312 authenticator shown in the figure is often simply relaying EAP 313 messages to and from the EAP server, but these back end AAA 314 communications are not shown. 316 Peer Authenticator 317 | EAP-Request/Identity | 318 |<---------------------------------------------------------| 319 | | 320 | EAP-Response/Identity | 321 |--------------------------------------------------------->| 322 | | 323 | EAP-Request/SIM/Start (AT_VERSION_LIST) | 324 |<---------------------------------------------------------| 325 | | 326 | EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)| 327 |--------------------------------------------------------->| 328 | | 329 | EAP-Request/SIM/Challenge (AT_RAND, AT_MAC) | 330 |<---------------------------------------------------------| 331 +-------------------------------------+ | 332 | Peer runs GSM algorithms, verifies | | 333 | AT_MAC and derives session keys | | 334 +-------------------------------------+ | 335 | EAP-Response/SIM/Challenge (AT_MAC) | 336 |--------------------------------------------------------->| 337 | | 338 | EAP-Success | 339 |<---------------------------------------------------------| 340 | | 342 Figure 1: EAP-SIM full authentication procedure 344 The first EAP Request issued by the authenticator is EAP-Request/ 345 Identity. On full authentication, the peer's response includes either 346 the user's International Mobile Subscriber Identity (IMSI) or a 347 temporary identity (pseudonym) if identity privacy is in effect, as 348 specified in Section 4.2. 350 Following the peer's EAP-Response/Identity packet, the peer receives 351 EAP Requests of type 18 (SIM) from the EAP server and sends the 352 corresponding EAP Responses. The EAP packets that are of the Type SIM 353 also have a Subtype field. On full authentication, the first 354 EAP-Request/SIM packet is of the Subtype 10 (Start). EAP-SIM packets 355 encapsulate parameters in attributes, encoded in a Type, Length, 356 Value format. The packet format and the use of attributes are 357 specified in Section 5. 359 The EAP-Request/SIM/Start packet contains the list of EAP-SIM version 360 supported by the EAP server in the AT_VERSION_LIST attribute. This 361 packet may also include attributes for requesting the subscriber 362 identity, as specified in Section 4.2. 364 The peer responds to EAP-Request/SIM/Start with the EAP-Response/SIM/ 365 Start packet, which includes the AT_NONCE_MT attribute that contains 366 a random number NONCE_MT, chosen by the peer, and the 367 AT_SELECTED_VERSION attribute that contains the version number 368 selected by the peer. The version negotiation is protected by 369 including the version list and the selected version in the 370 calculation of keying material (Section 4.6). 372 After receiving the EAP Response/SIM/Start, the EAP server obtains n 373 GSM triplets for use in authenticating the subscriber, where n = 2 or 374 n = 3. From the triplets, the EAP server derives the keying material, 375 as specified in Section 4.6. The triplets may be obtained by 376 contacting an Authentication Centre (AuC) on the GSM network; per GSM 377 specifications, between 1 and 5 triplets may be obtained at a time. 378 Triplets may be stored in the EAP server for use at a later time, but 379 triplets may not be reused, except in some error cases that are 380 specified in Section 7.9 382 The next EAP Request the EAP Server issues is of the type SIM and 383 subtype Challenge (11). It contains the RAND challenges and a message 384 authentication code attribute AT_MAC to cover the challenges. The 385 AT_MAC attribute is a general message authentication code attribute 386 that is used in many EAP-SIM messages. 388 On receipt of the EAP-Request/SIM/Challenge message, the peer runs 389 the GSM authentication algorithm and calculates a copy of the message 390 authentication code. The peer then verifies that the calculated MAC 391 equals the received MAC. If the MAC's do not match, then the peer 392 sends the EAP-Response/SIM/Client-Error packet and the authentication 393 exchange terminates. 395 Since the RAND's given to a peer are accompanied with the message 396 authentication code AT_MAC, and since the peer's NONCE_MT value 397 contributes to AT_MAC, the peer is able to verify that the EAP-SIM 398 message is fresh (not a replay) and that the sender possesses valid 399 GSM triplets for the subscriber. 401 If all checks out, the peer responds with the EAP-Response/SIM/ 402 Challenge, containing the AT_MAC attribute that covers the peer's 403 SRES response values (Section 6.4). The EAP server verifies that the 404 MAC is correct. Because protected success indications are not used in 405 this example, the EAP server sends the EAP-Success packet, indicating 406 that the authentication was successful. (Protected success 407 indications are discussed in Section 4.4.2.) The EAP server may also 408 include derived keying material in the message it sends to the 409 authenticator. The peer has derived the same keying material, so the 410 authenticator does not forward the keying material to the peer along 411 with EAP-Success. 413 EAP-SIM also includes a separate fast re-authentication procedure, 414 which does not make use of the A3/A8 algorithms or the GSM 415 infrastructure. Fast re-authentication is based on keys derived on 416 full authentication. If the peer has maintained state information for 417 fast re-authentication and wants to use fast re-authentication, then 418 the peer indicates this by using a specific fast re-authentication 419 identity instead of the permanent identity or a pseudonym identity. 420 The fast re-authentication procedure is described in Section 4.3. 422 4. Operation 424 4.1 Version Negotiation 426 EAP-SIM includes version negotiation so as to allow future 427 developments in the protocol. The version negotiation is performed on 428 full authentication and it uses two attributes, AT_VERSION_LIST, 429 which the server always includes in EAP-Request/SIM/Start, and 430 AT_SELECTED_VERSION, which the peer includes in EAP- Response/SIM/ 431 Start on full authentication. 433 AT_VERSION_LIST includes the EAP-SIM versions supported by the 434 server. If AT_VERSION_LIST does not include a version that is 435 implemented by the peer and allowed in the peer's security policy, 436 then the peer MUST send the EAP-Response/SIM/Client-Error packet 437 (Section 6.7) to the server with the error code "unsupported 438 version". If a suitable version is included, then the peer includes 439 the AT_SELECTED_VERSION attribute, containing the selected version, 440 in the EAP-Response/SIM/Start packet. The peer MUST only indicate a 441 version that is included in AT_VERSION_LIST. If several versions are 442 acceptable, then the peer SHOULD choose the version that occurs first 443 in the version list. 445 The version number list of AT_VERSION_LIST and the selected version 446 of AT_SELECTED_VERSION are included in the key derivation procedure 447 (Section 4.6). If an attacker modifies either one of these 448 attributes, then the peer and the server derive different keying 449 material. Because K_aut keys are different, the server and peer 450 calculate different AT_MAC values. Hence, the peer detects that 451 AT_MAC included in EAP-Request/SIM/Challenge is incorrect and sends 452 the EAP-Response/SIM/Client-Error packet. The authentication 453 procedure terminates. 455 4.2 Identity Management 457 4.2.1 Format, Generation and Usage of Peer Identities 458 4.2.1.1 General 460 In the beginning of EAP authentication, the Authenticator or the EAP 461 server usually issues the EAP-Request/Identity packet to the peer. 462 The peer responds with EAP-Response/Identity, which contains the 463 user's identity. The formats of these packets are specified in [EAP]. 465 GSM subscribers are identified with the International Mobile 466 Subscriber Identity (IMSI) [GSM 03.03]. The IMSI is composed of a 467 three digit Mobile Country Code (MCC), a two or three digit Mobile 468 Network Code (MNC) and a not more than 10 digit Mobile Subscriber 469 Identification Number (MSIN). In other words, the IMSI is a string of 470 not more than 15 digits. MCC and MNC uniquely identify the GSM 471 operator and help identify the AuC from which the authentication 472 vectors need to be retrieved for this subscriber. 474 Internet AAA protocols identify users with the Network Access 475 Identifier (NAI) [RFC2486]. When used in a roaming environment, the 476 NAI is composed of a username and a realm, separated with "@" 477 (username@realm). The username portion identifies the subscriber 478 within the realm. 480 This section specifies the peer identity format used in EAP-SIM. In 481 this document, the term identity or peer identity refers to the whole 482 identity string that is used to identify the peer. The peer identity 483 may include a realm portion. "Username" refers to the portion of the 484 peer identity that identifies the user, i.e. the username does not 485 include the realm portion. 487 4.2.1.2 Identity Privacy Support 489 EAP-SIM includes optional identity privacy (anonymity) support that 490 can be used to hide the cleartext permanent identity and thereby to 491 make the subscriber's EAP exchanges untraceable to eavesdroppers. 492 Because the permanent identity never changes, revealing it would help 493 observers to track the user. The permanent identity is usually based 494 on the IMSI, which may further help the tracking, because the same 495 identifier may be used in other contexts as well. Identity privacy is 496 based on temporary identities, or pseudonyms, which are equivalent to 497 but separate from the Temporary Mobile Subscriber Identities (TMSI) 498 that are used on cellular networks. Please see Section 9.1 for 499 security considerations regarding identity privacy. 501 4.2.1.3 Username Types in EAP-SIM identities 503 There are three types of usernames in EAP-SIM peer identities: 505 (1) Permanent usernames. For example, 1123456789098765@myoperator.com 506 might be a valid permanent identity. In this example, 507 1123456789098765 is the permanent username. 509 (2) Pseudonym usernames. For example, 3s7ah6n9q@myoperator.com might 510 be a valid pseudonym identity. In this example, 3s7ah6n9q is the 511 pseudonym username. 513 (3) Fast re-authentication usernames. For example, 514 53953754@myoperator.com might be a valid fast re-authentication 515 identity. In this case, 53953754 is the fast re-authentication 516 username. 518 The first two types of identities are only used on full 519 authentication and the last one only on fast re-authentication. When 520 the optional identity privacy support is not used, the non-pseudonym 521 permanent identity is used on full authentication. The fast 522 re-authentication exchange is specified in Section 4.3. 524 4.2.1.4 Username Decoration 526 In some environments, the peer may need to decorate the identity by 527 prepending or appending the username with a string, in order to 528 indicate supplementary AAA routing information in addition to the NAI 529 realm. (The usage of a NAI realm portion is not considered to be 530 decoration.) Username decoration is out of the scope of this 531 document. However, it should be noted that username decoration might 532 prevent the server from recognizing a valid username. Hence, although 533 the peer MAY use username decoration in the identities the peer 534 includes in EAP-Response/Identity, and the EAP server MAY accept a 535 decorated peer username in this message, the peer or the EAP server 536 MUST NOT decorate any other peer identities that are used in various 537 EAP-SIM attributes. Only the identity used in EAP-Response/Identity 538 may be decorated. 540 4.2.1.5 NAI Realm Portion 542 The peer MAY include a realm portion in the peer identity, as per the 543 NAI format. The use of a realm portion is not mandatory. 545 If a realm is used, the realm MAY be chosen by the subscriber's home 546 operator and it MAY be a configurable parameter in the EAP-SIM peer 547 implementation. In this case, the peer is typically configured with 548 the NAI realm of the home operator. Operators MAY reserve a specific 549 realm name for EAP-SIM users. This convention makes it easy to 550 recognize that the NAI identifies a GSM subscriber. Such reserved NAI 551 realm may be useful as a hint as to the first authentication method 552 to use during method negotiation. When the peer is using a pseudonym 553 username instead of the permanent username, the peer selects the 554 realm name portion similarly as it select the realm portion when 555 using the permanent username. 557 If no configured realm name is available, the peer MAY derive the 558 realm name from the MCC and MNC portions of the IMSI. A RECOMMENDED 559 way to derive the realm from the IMSI using the realm 3gppnetwork.org 560 will be specified in [Draft 3GPP TS 23.003]. 562 Some old implementations derive the realm name from the IMSI by 563 concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits 564 of IMSI and ".owlan.org". For example, if the IMSI is 565 123456789098765, and the MNC is three digits long, then the derived 566 realm name is "mnc456.mcc123.owlan.org". As there are no DNS servers 567 running at owlan.org, these realm names can only be used with 568 manually configured AAA routing. New implementations SHOULD use the 569 mechanism specified in [Draft 3GPP TS 23.003] instead of owlan.org as 570 soon as the 3GPP specification is finalized. 572 The IMSI is a string of digits without any explicit structure, so the 573 peer may not be able to determine the length of the MNC portion. If 574 the peer is not able to determine whether the MNC is two or three 575 digits long, the peer MAY use a 3-digit MNC. If the correct length of 576 the MNC is two, then the MNC used in the realm name includes the 577 first digit of MSIN. Hence, when configuring AAA networks for 578 operators that have 2-digit MNC's, the network SHOULD also be 579 prepared for realm names with incorrect 3-digit MNC's. 581 4.2.1.6 Format of the Permanent Username 583 The non-pseudonym permanent username SHOULD be derived from the IMSI. 584 In this case, the permanent username MUST be of the format "1" | 585 IMSI, where the character "|" denotes concatenation. In other words, 586 the first character of the username is the digit one (ASCII value 31 587 hexadecimal), followed by the IMSI. The IMSI is encoded as an ASCII 588 string that consists of not more than 15 decimal digits (ASCII values 589 between 30 and 39 hexadecimal), one character per IMSI digit, in the 590 order as specified in [GSM 03.03]. For example, a permanent username 591 derived from the IMSI 295023820005424 would be encoded as the ASCII 592 string "1295023820005424" (byte values in hexadecimal notation: 31 593 32 39 35 30 32 33 38 32 30 30 30 35 34 32 34) 595 The EAP server MAY use the leading "1" as a hint to try EAP-SIM as 596 the first authentication method during method negotiation, rather 597 than for example EAP/AKA. The EAP-SIM server MAY propose EAP-SIM even 598 if the leading character was not "1". 600 Alternatively, an implementation MAY choose a permanent username that 601 is not based on the IMSI. In this case the selection of the username, 602 its format, and its processing is out of the scope of this document. 603 In this case, the peer implementation MUST NOT prepend any leading 604 characters to the username. 606 4.2.1.7 Generating Pseudonyms and Fast Re-authentication Identities by 607 the Server 609 Pseudonym usernames and fast re-authentication identities are 610 generated by the EAP server. The EAP server produces pseudonym 611 usernames and fast re-authentication identities in an 612 implementation-dependent manner. Only the EAP server needs to be able 613 to map the pseudonym username to the permanent identity, or to 614 recognize a fast re-authentication identity. 616 EAP-SIM includes no provisions to ensure that the same EAP server 617 that generated a pseudonym username will be used on the 618 authentication exchange when the pseudonym username is used. It is 619 recommended that the EAP servers implement some centralized mechanism 620 to allow all EAP servers of the home operator to map pseudonyms 621 generated by other severs to the permanent identity. If no such 622 mechanism is available, then the EAP server failing to understand a 623 pseudonym issued by another server can request the peer to send the 624 permanent identity. 626 When issuing a fast re-authentication identity, the EAP server may 627 include a realm name in the identity to make the fast 628 re-authentication request be forwarded to the same EAP server. 630 When generating fast re-authentication identities, the server SHOULD 631 choose a fresh new fast re-authentication identity that is different 632 from the previous ones used within a same reauthentication context. 633 The fast re-authentication identity SHOULD include a random 634 component. The random component works as a full authentication 635 context identifier. A context-specific fast re-authentication 636 identity can help the server to detect whether its fast 637 re-authentication state information matches the peer's fast 638 re-authentication state information (in other words whether the state 639 information is from the same full authentication exchange). The 640 random component also makes the fast re-authentication identities 641 unpredictable, so an attacker cannot initiate a fast 642 re-authentication exchange to get the server's EAP-Request/SIM/ 643 Re-authentication packet. 645 Regardless of construction method, the pseudonym username MUST 646 conform to the grammar specified for the username portion of an NAI. 647 The fast re-authentication identity also MUST conform to the NAI 648 grammar. The EAP servers that the subscribers of an operator can use 649 MUST ensure that the pseudonym usernames and the username portions 650 used in fast re-authentication identities they generate are unique. 652 In any case, it is necessary that permanent usernames, pseudonym 653 usernames and fast re-authentication usernames are separate and 654 recognizable from each other. It is also desirable that EAP-SIM and 655 EAP-AKA [EAP-AKA] user names be recognizable from each other as an 656 aid for the server to which method to offer. 658 In general, it is the task of the EAP server and the policies of its 659 administrator to ensure sufficient separation in the usernames. 660 Pseudonym usernames and fast re-authentication usernames are both 661 produced and used by the EAP server. The EAP server MUST compose 662 pseudonym usernames and fast re-authentication usernames so that it 663 can recognize if a NAI username is an EAP-SIM pseudonym username or 664 an EAP-SIM fast re-authentication username. For instance, when the 665 usernames have been derived from the IMSI, the server could use 666 different leading characters in the pseudonym usernames and fast 667 re-authentication usernames (e.g. the pseudonym could begin with a 668 leading "3" character). When mapping a fast re-authentication 669 identity to a permanent identity, the server SHOULD only examine the 670 username portion of the fast re-authentication identity and ignore 671 the realm portion of the identity. 673 Because the peer may fail to save a pseudonym username sent to in an 674 EAP-Request/SIM/Challenge, for example due to malfunction, the EAP 675 server SHOULD maintain at least the most recently used pseudonym 676 username in addition to the most recently issued pseudonym username. 677 If the authentication exchange is not completed successfully, then 678 the server SHOULD NOT overwrite the pseudonym username that was 679 issued during the most recent successful authentication exchange. 681 4.2.1.8 Transmitting Pseudonyms and Fast Re-authentication Identities to 682 the Peer 684 The server transmits pseudonym usernames and fast re-authentication 685 identities to the peer in cipher, using the AT_ENCR_DATA attribute. 687 The EAP-Request/SIM/Challenge message MAY include an encrypted 688 pseudonym username and/or an encrypted fast re-authentication 689 identity in the value field of the AT_ENCR_DATA attribute. Because 690 identity privacy support and fast re-authentication are optional to 691 implement, the peer MAY ignore the AT_ENCR_DATA attribute and always 692 use the permanent identity. On fast re-authentication (discussed in 693 Section 4.3), the server MAY include a new encrypted fast 694 re-authentication identity in the EAP-Request/SIM/Re-authentication 695 message. 697 On receipt of the EAP-Request/SIM/Challenge, the peer MAY decrypt the 698 encrypted data in AT_ENCR_DATA. If the authentication exchange is 699 successful, and the the encrypted data includes a pseudonym username, 700 then the peer may use the obtained pseudonym username on the next 701 full authentication. If a fast re-authentication identity is 702 included, then the peer MAY save it together with other fast 703 re-authentication state information, as discussed in Section 4.3, for 704 the next re-authentication. If the authentication exchange does not 705 complete successfully, the peer MUST ignore the received pseudonym 706 username and the fast re-authentication identity. 708 If the peer does not receive a new pseudonym username in the 709 EAP-Request/SIM/Challenge message, the peer MAY use an old pseudonym 710 username instead of the permanent username on next full 711 authentication. The username portions of fast re-authentication 712 identities are one-time usernames, which the peer MUST NOT re-use. 713 When the peer uses a fast re-authentication identity in an EAP 714 exchange, the peer MUST discard the fast re-authentication identity 715 and not re-use it in another EAP authentication exchange, even if the 716 authentication exchange was not completed. 718 4.2.1.9 Usage of the Pseudonym by the Peer 720 When the optional identity privacy support is used on full 721 authentication, the peer MAY use a pseudonym username received as 722 part of a previous full authentication sequence as the username 723 portion of the NAI. The peer MUST NOT modify the pseudonym username 724 received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer 725 MAY need to decorate the username in some environments by appending 726 or prepending the username with a string that indicates supplementary 727 AAA routing information. 729 When using a pseudonym username in an environment where a realm 730 portion is used, the peer concatenates the received pseudonym 731 username with the "@" character and a NAI realm portion. The 732 selection of the NAI realm is discussed above. The peer can select 733 the realm portion similarly regardless of whether it uses the 734 permanent username or a pseudonym username. 736 4.2.1.10 Usage of the Fast Re-authentication Identity by the Peer 738 On fast re-authentication, the peer uses the fast re-authentication 739 identity, received as part of the previous authentication sequence. A 740 new re-authentication identity may be delivered as part of both full 741 authentication and fast re-authentication. The peer MUST NOT modify 742 the username part of the fast re-authentication identity received in 743 AT_NEXT_REAUTH_ID, except in cases when username decoration is 744 required. Even in these cases, the "root" fast re-authentication 745 username must not be modified, but it may be appended or prepended 746 with another string. 748 4.2.2 Communicating the Peer Identity to the Server 750 4.2.2.1 General 752 The peer identity MAY be communicated to the server with the 753 EAP-Response/Identity message. This message MAY contain the permanent 754 identity, a pseudonym identity, or a fast re-authentication identity. 755 If the peer uses the permanent identity or a pseudonym identity, 756 which the server is able to map to the permanent identity, then the 757 authentication proceeds as discussed in the overview of Section 3. If 758 the peer uses a fast re-authentication identity, and if the fast 759 re-authentication identity matches with a valid fast 760 re-authentication identity maintained by the server, and if the 761 server agrees on using fast re-authentication, then a fast 762 re-authentication exchange is performed, as described in Section 4.3. 764 The peer identity can also be transmitted from the peer to the server 765 using EAP-SIM messages instead of EAP-Response/Identity. In this 766 case, the server includes an identity requesting attribute 767 (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the 768 EAP-Request/SIM/Start message, and the peer includes the AT_IDENTITY 769 attribute, which contains the peer's identity, in the EAP-Response/ 770 SIM/Start message. The AT_ANY_ID_REQ attribute is a general identity 771 requesting attribute, which the server uses if it does not specify 772 which kind of an identity the peer should return in AT_IDENTITY. The 773 server uses the AT_FULLAUTH_ID_REQ attribute to request either the 774 permanent identity or a pseudonym identity. The server uses the 775 AT_PERMANENT_ID_REQ attribute to request the peer to send its 776 permanent identity. 778 The identity format in the AT_IDENTITY attribute is the same as in 779 the EAP-Response/Identity packet (except that identity decoration is 780 not allowed). The AT_IDENTITY attribute contains a permanent 781 identity, a pseudonym identity or a fast re-authentication identity. 783 Obtaining the subscriber identity via EAP-SIM messages is useful if 784 the server does not have any EAP-SIM peer identity at the beginning 785 of the EAP-SIM exchange or does not recognize the identity the peer 786 used in EAP-Response/Identity. This may happen if, for example, the 787 EAP-Response/Identity has been issued by some EAP method other than 788 EAP-SIM or if intermediate entities or software layers in the peer 789 have modified the identity string in the EAP-Response/Identity 790 packet. Also, some EAP layer implementations may cache the identity 791 string from the first EAP authentication and do not obtain a new 792 identity string from the EAP method implementation on subsequent 793 authentication exchanges. 795 As the identity string is used in key derivation, any of these cases 796 will result in failed authentication unless the EAP server uses 797 EAP-SIM attributes to obtain an unmodified copy of the identity 798 string. Therefore, unless the EAP server can be certain that no 799 intermediate element or software layer has modified the EAP-Response/ 800 Identity packet, the EAP server MUST use the EAP-SIM attributes to 801 obtain the identity, even if the identity received in EAP-Response/ 802 Identity was valid. 804 Please note that the EAP-SIM peer and the EAP-SIM server only process 805 the AT_IDENTITY attribute and entities that only pass through EAP 806 packets do not process this attribute. Hence, if the EAP server is 807 not co-located in the authenticator, then the authenticator and other 808 intermediate AAA elements (such as possible AAA proxy servers) will 809 continue to refer to the peer with the original identity from the 810 EAP-Response/Identity packet regardless of whether the AT_IDENTITY 811 attribute is used in EAP-SIM to transmit another identity. 813 4.2.2.2 Choice of Identity for the EAP-Response/Identity 815 If EAP-SIM peer is started upon receiving an EAP-Request/Identity 816 message, then the peer performs the following steps. 818 If the peer has maintained fast re-authentication state information 819 and if the peer wants to use fast re-authentication, then the peer 820 transmits the fast re-authentication identity in EAP-Response/ 821 Identity. 823 Else, if the peer has a pseudonym username available, then the peer 824 transmits the pseudonym identity in EAP-Response/Identity. 826 In other cases, the peer transmits the permanent identity in 827 EAP-Response/Identity. 829 4.2.2.3 Server Operation in the Beginning of EAP-SIM Exchange 831 If the EAP server has not received any EAP-SIM peer identity 832 (permanent identity, pseudonym identity or fast re-authentication 833 identity) from the peer when sending the first EAP-SIM request, or if 834 the EAP server has received an EAP-Response/Identity packet but the 835 contents do not appear to be a valid permanent identity, pseudonym 836 identity or a re-authentication identity, then the server MUST 837 request an identity from the peer using one of the methods below. 839 The server sends the EAP-Request/SIM/Start message with the 840 AT_PERMANENT_ID_REQ message to indicate that the server wants the 841 peer to include the permanent identity in the AT_IDENTITY attribute 842 of the EAP-Response/SIM/Start message. This is done in the following 843 cases: 845 o The server does not support fast re-authentication or identity 846 privacy. 847 o The server received an identity that it recognizes as a pseudonym 848 identity but the server is not able to map the pseudonym identity 849 to a permanent identity. 851 The server issues the EAP-Request/SIM/Start packet with the 852 AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the 853 peer to include a full authentication identity (pseudonym identity or 854 permanent identity) in the AT_IDENTITY attribute of the EAP-Response/ 855 SIM/Start message. This is done in the following cases: 857 o The server does not support fast re-authentication and the server 858 supports identity privacy 859 o The server received an identity that it recognizes as a 860 re-authentication identity but the server is not able to map the 861 re-authentication identity to a permanent identity 863 The server issues the EAP-Request/SIM/Start packet with the 864 AT_ANY_ID_REQ attribute to indicate that the server wants the peer to 865 include an identity in the AT_IDENTITY attribute of the EAP-Response/ 866 SIM/Start message, and the server does not indicate any preferred 867 type for the identity. This is done in other cases, such as when the 868 server does not have any identity, or the server does not recognize 869 the format of a received identity. 871 4.2.2.4 Processing of EAP-Request/SIM/Start by the Peer 873 Upon receipt of an EAP-Request/SIM/Start message, the peer MUST 874 perform the following steps. 876 If the EAP-Request/SIM/Start does not include any identity request 877 attribute, then the peer responds with EAP-Response/SIM/Start without 878 AT_IDENTITY. The peer includes the AT_SELECTED_VERSION and 879 AT_NONCE_MT attributes, because the exchange is a full authentication 880 exchange. 882 If the EAP-Request/SIM/Start includes AT_PERMANENT_ID_REQ, and if the 883 peer does not have a pseudonym available, then the peer MUST respond 884 with EAP-Response/SIM/Start and include the permanent identity in 885 AT_IDENTITY. If the peer has a pseudonym available then the peer MAY 886 refuse to send the permanent identity; hence in this case the peer 887 MUST either respond with EAP-Response/SIM/Start and include the 888 permanent identity in AT_IDENTITY or respond with EAP-Response/SIM/ 889 Client-Error packet with code "unable to process packet". 891 If the EAP-Request/SIM/Start includes AT_FULL_AUTH_ID_REQ, and if the 892 peer has a pseudonym available, then the peer SHOULD respond with 893 EAP-Response/SIM/Start and include the pseudonym identity in 894 AT_IDENTITY. If the peer does not have a pseudonym when it receives 895 this message, then the peer MUST respond with EAP- Response/SIM/Start 896 and include the permanent identity in AT_IDENTITY. The Peer MUST NOT 897 use a re-authentication identity in the AT_IDENTITY attribute. 899 If the EAP-Request/SIM/Start includes AT_ANY_ID_REQ, and if the peer 900 has maintained fast re-authentication state information and the peer 901 wants to use fast re-authentication, then the peer responds with 902 EAP-Response/SIM/Start and includes the fast re-authentication 903 identity in AT_IDENTITY. Else, if the peer has a pseudonym identity 904 available, then the peer responds with EAP-Response/SIM/Start and 905 includes the pseudonym identity in AT_IDENTITY. Else, the peer 906 responds with EAP-Response/SIM/Start and includes the permanent 907 identity in AT_IDENTITY. 909 An EAP-SIM exchange may include several EAP/SIM/Start rounds. The 910 server may issue a second EAP-Request/SIM/Start, if it was not able 911 to recognize the identity the peer used in the previous AT_IDENTITY 912 attribute. At most three EAP/SIM/Start rounds can be used, so the 913 peer MUST NOT respond to more than three EAP-Request/SIM/Start 914 messages within an EAP exchange. The peer MUST verify that the 915 sequence of EAP-Request/SIM/Start packets the peer receives comply 916 with the sequencing rules defined in this document. That is, 917 AT_ANY_ID_REQ can only be used in the first EAP-Request/SIM/Start, in 918 other words AT_ANY_ID_REQ MUST NOT be used in the second or third 919 EAP-Request/SIM/Start. AT_FULLAUTH_ID_REQ MUST NOT be used if the 920 previous EAP-Request/SIM/Start included AT_PERMANENT_ID_REQ. The peer 921 operation in cases when it receives an unexpected attribute or an 922 unexpected message is specified in Section 4.5.1. 924 4.2.2.5 Attacks against Identity Privacy 926 The section above specifies two possible ways the peer can operate 927 upon receipt of AT_PERMANENT_ID_REQ. This is because a received 928 AT_PERMANENT_ID_REQ does not necessarily originate from the valid 929 network, but an active attacker may transmit an EAP- Request/SIM/ 930 Start packet with an AT_PERMANENT_ID_REQ attribute to the peer, in an 931 effort to find out the true identity of the user. If the peer does 932 not want to reveal its permanent identity, then the peer sends the 933 EAP-Response/SIM/Client-Error packet with the error code "unable to 934 process packet", and the authentication exchange terminates. 936 Basically, there are two different policies that the peer can employ 937 with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes 938 that the network is able to maintain pseudonyms robustly. Therefore, 939 if a conservative peer has a pseudonym username, the peer responds 940 with EAP-Response/SIM/Client-Error to the EAP packet with 941 AT_PERMANENT_ID_REQ, because the peer believes that the valid network 942 is able to map the pseudonym identity to the peer's permanent 943 identity. (Alternatively, the conservative peer may accept 944 AT_PERMANENT_ID_REQ in certain circumstances, for example if the 945 pseudonym was received a long time ago.) The benefit of this policy 946 is that it protects the peer against active attacks on anonymity. On 947 the other hand, a "liberal" peer always accepts the 948 AT_PERMANENT_ID_REQ and responds with the permanent identity. The 949 benefit of this policy is that it works even if the valid network 950 sometimes loses pseudonyms and is not able to map them to the 951 permanent identity. 953 4.2.2.6 Processing of AT_IDENTITY by the Server 955 When the server receives an EAP-Response/SIM/Start message with the 956 AT_IDENTITY (in response to the server's identity requesting 957 attribute), the server MUST operate as follows. 959 If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does 960 not contain a valid permanent identity, then the server sends 961 EAP-Request/SIM/Notification with AT_NOTIFICATION code 16384, and the 962 EAP exchange terminates. If the server recognizes the permanent 963 identity and is able to continue, then the server proceeds with full 964 authentication by sending EAP-Request/SIM/Challenge. 966 If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a 967 valid permanent identity or a pseudonym identity that the server can 968 map to a valid permanent identity, then the server proceeds with full 969 authentication by sending EAP-Request/SIM/Challenge. If AT_IDENTITY 970 contains a pseudonym identity that the server is not able to map to a 971 valid permanent identity, or an identity that the server is not able 972 to recognize or classify, then the server sends EAP-Request/SIM/Start 973 with AT_PERMANENT_ID_REQ. 975 If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a 976 valid permanent identity or a pseudonym identity that the server can 977 map to a valid permanent identity, then the server proceeds with full 978 authentication by sending EAP-Request/SIM/Challenge. 980 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid 981 fast re-authentication identity and the server agrees on using re- 982 authentication, then the server proceeds with fast re-authentication 983 by sending EAP-Request/SIM/Re-authentication (Section 4.3). 985 If the server used AT_ANY_ID_REQ, and if the peer sent an 986 EAP-Response/SIM/Start with only AT_IDENTITY (indicating re- 987 authentication), but the server is not able to map the identity to a 988 permanent identity, then the server sends EAP-Request/SIM/Start with 989 AT_FULLAUTH_ID_REQ. 991 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid 992 fast re-authentication identity, which the server is able to map to a 993 permanent identity, and if the server does not want to use fast 994 re-authentication, then the server sends EAP-Request/SIM/Start 995 without any identity requesting attributes. 997 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an 998 identity that the server recognizes as a pseudonym identity but the 999 server is not able to map the pseudonym identity to a permanent 1000 identity, then the server sends EAP-Request/SIM/Start with 1001 AT_PERMANENT_ID_REQ. 1003 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an 1004 identity that the server is not able to recognize or classify, then 1005 the server sends EAP-Request/SIM/Start with AT_FULLAUTH_ID_REQ. 1007 4.2.3 Message Sequence Examples (Informative) 1009 This section contains non-normative message sequence examples to 1010 illustrate how the peer identity can be communicated to the server. 1012 4.2.3.1 Full Authentication 1014 This case for full authentication is illustrated below in Figure 2. 1015 In this case, AT_IDENTITY contains either the permanent identity or a 1016 pseudonym identity. The same sequence is also used in case the server 1017 uses the AT_FULLAUTH_ID_REQ in EAP-Request/SIM/Start. 1019 Peer Authenticator 1020 | | 1021 | +------------------------------+ 1022 | | Server does not have any | 1023 | | Subscriber identity available| 1024 | | When starting EAP-SIM | 1025 | +------------------------------+ 1026 | | 1027 | EAP-Request/SIM/Start | 1028 | (AT_ANY_ID_REQ, AT_VERSION_LIST) | 1029 |<------------------------------------------------------| 1030 | | 1031 | | 1032 | EAP-Response/SIM/Start | 1033 | (AT_IDENTITY, AT_NONCE_MT, | 1034 | AT_SELECTED_VERSION) | 1035 |------------------------------------------------------>| 1036 | | 1038 Figure 2: Requesting any identity, full authentication 1040 If the peer uses its full authentication identity and the AT_IDENTITY 1041 attribute contains a valid permanent identity or a valid pseudonym 1042 identity that the EAP server is able to map to the permanent 1043 identity, then the full authentication sequence proceeds as usual 1044 with the EAP Server issuing the EAP-Request/SIM/Challenge message. 1046 4.2.3.2 Fast Re-authentication 1048 The case when the server uses the AT_ANY_ID_REQ and the peer wants to 1049 perform fast re-authentication is illustrated below in Figure 3. 1051 Peer Authenticator 1052 | | 1053 | +------------------------------+ 1054 | | Server does not have any | 1055 | | Subscriber identity available| 1056 | | When starting EAP-SIM | 1057 | +------------------------------+ 1058 | | 1059 | EAP-Request/SIM/Start | 1060 | (AT_ANY_ID_REQ, AT_VERSION_LIST) | 1061 |<------------------------------------------------------| 1062 | | 1063 | | 1064 | EAP-Response/SIM/Start | 1065 | (AT_IDENTITY containing a fast re-auth. identity) | 1066 |------------------------------------------------------>| 1067 | | 1069 Figure 3: Requesting any identity, fast re-authentication 1071 On fast re-authentication, if the AT_IDENTITY attribute contains a 1072 valid fast re-authentication identity and the server agrees on using 1073 fast re-authentication, then the server proceeds with the fast 1074 re-authentication sequence and issues the EAP-Request/SIM/ 1075 Re-authentication packet, as specified in Section 4.3. 1077 4.2.3.3 Fall Back to Full Authentication 1079 The case when the server does not recognize the fast 1080 re-authentication identity the peer used in AT_IDENTITY, and issues a 1081 second EAP- Request/SIM/Start message is illustrated in Figure 4. 1083 Peer Authenticator 1084 | | 1085 | +------------------------------+ 1086 | | Server does not have any | 1087 | | Subscriber identity available| 1088 | | When starting EAP-SIM | 1089 | +------------------------------+ 1090 | | 1091 | EAP-Request/SIM/Start | 1092 | (AT_ANY_ID_REQ, AT_VERSION_LIST) | 1093 |<------------------------------------------------------| 1094 | | 1095 | | 1096 | EAP-Response/SIM/Start | 1097 | (AT_IDENTITY containing a fast re-auth. identity) | 1098 |------------------------------------------------------>| 1099 | | 1100 | +------------------------------+ 1101 | | Server does not recognize | 1102 | | The fast re-auth. | 1103 | | Identity | 1104 | +------------------------------+ 1105 | | 1106 | EAP-Request/SIM/Start | 1107 | (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) | 1108 |<------------------------------------------------------| 1109 | | 1110 | | 1111 | EAP-Response/SIM/Start | 1112 | (AT_IDENTITY with a full-auth. identity, AT_NONCE_MT, | 1113 | AT_SELECTED_VERSION) | 1114 |------------------------------------------------------>| 1115 | | 1117 Figure 4: Fall back to full authentication 1119 4.2.3.4 Requesting the Permanent Identity 1 1121 Figure 5 illustrates the case when the EAP server fails to map the 1122 pseudonym identity included in the EAP-Response/Identity packet to a 1123 valid permanent identity. 1125 Peer Authenticator 1126 | | 1127 | EAP-Request/Identity | 1128 |<------------------------------------------------------| 1129 | | 1130 | EAP-Response/Identity | 1131 | (Includes a pseudonym) | 1132 |------------------------------------------------------>| 1133 | | 1134 | +------------------------------+ 1135 | | Server fails to map the | 1136 | | Pseudonym to a permanent id. | 1137 | +------------------------------+ 1138 | EAP-Request/SIM/Start | 1139 | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) | 1140 |<------------------------------------------------------| 1141 | | 1142 | EAP-Response/SIM/Start | 1143 | (AT_IDENTITY with permanent identity, AT_NONCE_MT, | 1144 | AT_SELECTED_VERSION) | 1145 |------------------------------------------------------>| 1146 | | 1148 Figure 5: Requesting the permanent identity 1150 If the server recognizes the permanent identity, then the 1151 authentication sequence proceeds as usual with the EAP Server issuing 1152 the EAP-Request/SIM/Challenge message. 1154 4.2.3.5 Requesting the Permanent Identity 2 1156 Figure 6 illustrates the case when the EAP server fails to map the 1157 pseudonym included in the AT_IDENTITY attribute to a valid permanent 1158 identity. 1160 Peer Authenticator 1161 | | 1162 | +------------------------------+ 1163 | | Server does not have any | 1164 | | Subscriber identity available| 1165 | | When starting EAP-SIM | 1166 | +------------------------------+ 1167 | EAP-Request/SIM/Start | 1168 | (AT_ANY_ID_REQ, AT_VERSION_LIST) | 1169 |<------------------------------------------------------| 1170 | | 1171 |EAP-Response/SIM/Start | 1172 |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, | 1173 | AT_SELECTED_VERSION) | 1174 |------------------------------------------------------>| 1175 | +-------------------------------+ 1176 | | Server fails to map the | 1177 | | Pseudonym in AT_IDENTITY | 1178 | | to a valid permanent identity | 1179 | +-------------------------------+ 1180 | | 1181 | EAP-Request/SIM/Start | 1182 | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) | 1183 |<------------------------------------------------------| 1184 | | 1185 | EAP-Response/SIM/Start | 1186 | (AT_IDENTITY with permanent identity, | 1187 | AT_NONCE_MT, AT_SELECTED_VERSION) | 1188 |------------------------------------------------------>| 1189 | | 1191 Figure 6: Requesting a permanent identity (two EAP-SIM Start rounds) 1193 4.2.3.6 Three EAP-SIM/Start Roundtrips 1195 In the worst case, there are three EAP/SIM/Start round trips before 1196 the server has obtained an acceptable identity. This case is 1197 illustrated in Figure 7. 1199 Peer Authenticator 1200 | | 1201 | +------------------------------+ 1202 | | Server does not have any | 1203 | | Subscriber identity available| 1204 | | When starting EAP-SIM | 1205 | +------------------------------+ 1206 | EAP-Request/SIM/Start | 1207 | (Includes AT_ANY_ID_REQ, AT_VERSION_LIST) | 1208 |<------------------------------------------------------| 1209 | | 1210 | EAP-Response/SIM/Start | 1211 | (AT_IDENTITY with fast re-auth. identity) | 1212 |------------------------------------------------------>| 1213 | | 1214 | +------------------------------+ 1215 | | Server does not accept | 1216 | | The fast re-auth. | 1217 | | Identity | 1218 | +------------------------------+ 1219 | EAP-Request/SIM/Start | 1220 | (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) | 1221 |<------------------------------------------------------| 1222 | | 1223 : : 1224 : : 1226 : : 1227 : : 1228 |EAP-Response/SIM/Start | 1229 |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, | 1230 | AT_SELECTED_VERSION) | 1231 |------------------------------------------------------>| 1232 | | 1233 | +-------------------------------+ 1234 | | Server fails to map the | 1235 | | Pseudonym in AT_IDENTITY | 1236 | | to a valid permanent identity | 1237 | +-------------------------------+ 1238 | EAP-Request/SIM/Start | 1239 | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) | 1240 |<------------------------------------------------------| 1241 | | 1242 | EAP-Response/SIM/Start | 1243 | (AT_IDENTITY with permanent identity, AT_NONCE_MT, | 1244 | AT_SELECTED_VERSION) | 1245 |------------------------------------------------------>| 1246 | | 1248 Figure 7: Three EAP-SIM Start rounds 1250 After the last EAP-Response/SIM/Start message, the full 1251 authentication sequence proceeds as usual. If the EAP Server 1252 recognizes the permanent identity and is able to proceed, the server 1253 issues the EAP-Request/SIM/Challenge message. 1255 4.3 Fast Re-Authentication 1257 4.3.1 General 1259 In some environments, EAP authentication may be performed frequently. 1260 Because the EAP-SIM full authentication procedure makes use of the 1261 GSM SIM A3/A8 algorithms, and it therefore requires 2 or 3 fresh 1262 triplets from the Authentication Centre, the full authentication 1263 procedure is not very well suitable for frequent use. Therefore, 1264 EAP-SIM includes a more inexpensive fast re-authentication procedure 1265 that does not make use of the SIM A3/A8 algorithms and does not need 1266 new triplets from the Authentication Centre. Re-authentication can be 1267 performed in fewer roundtrips than the full authentication. 1269 Fast re-authentication is optional to implement for both the EAP-SIM 1270 server and peer. On each EAP authentication, either one of the 1271 entities may also fall back on full authentication if they do not 1272 want to use fast re-authentication. 1274 Fast re-authentication is based on the keys derived on the preceding 1275 full authentication. The same K_aut and K_encr keys as in full 1276 authentication are used to protect EAP-SIM packets and attributes, 1277 and the original Master Key from full authentication is used to 1278 generate a fresh Master Session Key, as specified in Section 4.6. 1280 The fast re-authentication exchange makes use of an unsigned 16-bit 1281 counter, included in the AT_COUNTER attribute. The counter has three 1282 goals: 1) it can be used to limit the number of successive 1283 reauthentication exchanges without full authentication 2) it 1284 contributes to the keying material, and 3) it protects the peer and 1285 the server from replays. On full authentication, both the server and 1286 the peer initialize the counter to one. The counter value of at least 1287 one is used on the first fast re-authentication. On subsequent fast 1288 re-authentications, the counter MUST be greater than on any of the 1289 previous re-authentications. For example, on the second fast 1290 re-authentication, counter value is two or greater etc. The 1291 AT_COUNTER attribute is encrypted. 1293 Both the peer and the EAP server maintain a copy of the counter. The 1294 EAP server sends its counter value to the peer in the fast 1295 re-authentication request. The peer MUST verify that its counter 1296 value is less than or equal to the value sent by the EAP server. 1298 The server includes an encrypted server random nonce (AT_NONCE_S) in 1299 the fast re-authentication request. The AT_MAC attribute in the 1300 peer's response is calculated over NONCE_S to provide a challenge/ 1301 response authentication scheme. The NONCE_S also contributes to the 1302 new Master Session Key. 1304 Both the peer and the server SHOULD have an upper limit for the 1305 number of subsequent fast re-authentications allowed before a full 1306 authentication needs to be performed. Because a 16-bit counter is 1307 used in fast re-authentication, the theoretical maximum number of 1308 re-authentications is reached when the counter value reaches FFFF 1309 hexadecimal. 1311 In order to use fast re-authentication, the peer and the EAP server 1312 need to store the following values: Master Key, latest counter value 1313 and the next fast re-authentication identity. K_aut, K_encr may 1314 either be stored or derived again from MK. The server may also need 1315 to store the permanent identity of the user. 1317 4.3.2 Comparison to UMTS AKA 1319 When analyzing the fast re-authentication exchange, it may be helpful 1320 to compare it with the UMTS Authentication and Key Agreement (AKA) 1321 exchange, which it resembles closely. The counter corresponds to the 1322 UMTS AKA sequence number, NONCE_S corresponds to RAND, and AT_MAC in 1323 EAP-Request/SIM/Re-authentication corresponds to AUTN, the AT_MAC in 1324 EAP-Response/SIM/Re-authentication corresponds to RES, 1325 AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter 1326 corresponds to the usage of the Anonymity Key. Also the key 1327 generation on fast re-authentication with regard to random or fresh 1328 material is similar to UMTS AKA -- the server generates the NONCE_S 1329 and counter values, and the peer only verifies that the counter value 1330 is fresh. 1332 It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER or 1333 AT_COUNTER_TOO_SMALL attributes is not important to the security of 1334 the fast re-authentication exchange. 1336 4.3.3 Fast Re-authentication Identity 1338 The fast re-authentication procedure makes use of separate 1339 re-authentication user identities. Pseudonyms and the permanent 1340 identity are reserved for full authentication only. If a 1341 re-authentication identity is lost and the network does not recognize 1342 it, the EAP server can fall back on full authentication. 1344 If the EAP server supports fast re-authentication, it MAY include the 1345 skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of 1346 EAP-Request/SIM/Challenge message (Section 6.3). This attribute 1347 contains a new fast re-authentication identity for the next fast 1348 re-authentication. The attribute also works as a capability flag that 1349 indicates the fact that the server supports fast re-authentication, 1350 and that the server wants to continue using fast re-authentication 1351 within the current context. The peer MAY ignore this attribute, in 1352 which case it MUST use full authentication next time. If the peer 1353 wants to use re- authentication, it uses this fast re-authentication 1354 identity on next authentication. Even if the peer has a fast 1355 re-authentication identity, the peer MAY discard the fast 1356 re-authentication identity and use a pseudonym or the permanent 1357 identity instead, in which case full authentication MUST be 1358 performed. If the EAP server does not include the AT_NEXT_REAUTH_ID 1359 in the encrypted data of EAP-Request/SIM/Challenge or EAP-Request/ 1360 SIM/Re-authentication, then the peer MUST discard its current fast 1361 re-authentication state information and perform a full authentication 1362 next time. 1364 In environments where a realm portion is needed in the peer identity, 1365 the fast re-authentication identity received in AT_NEXT_REAUTH_ID 1366 MUST contain both a username portion and a realm portion, as per the 1367 NAI format. The EAP Server can choose an appropriate realm part in 1368 order to have the AAA infrastructure route subsequent fast 1369 re-authentication related requests to the same AAA server. For 1370 example, the realm part MAY include a portion that is specific to the 1371 AAA server. Hence, it is sufficient to store the context required for 1372 fast re-authentication in the AAA server that performed the full 1373 authentication. 1375 The peer MAY use the fast re-authentication identity in the 1376 EAP-Response/Identity packet or, in response to server's 1377 AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication 1378 identity in the AT_IDENTITY attribute of the EAP-Response/SIM/Start 1379 packet. The peer MUST NOT modify the username portion of the fast 1380 re-authentication identity, but the peer MAY modify the realm portion 1381 or replace it with another realm portion. 1383 Even if the peer uses a fast re-authentication identity, the server 1384 may want to fall back on full authentication, for example because the 1385 server does not recognize the fast re-authentication identity or does 1386 not want to use fast re-authentication. In this case, the server 1387 starts the full authentication procedure by issuing an EAP-Request/ 1388 SIM/Start packet. This packet always starts a full authentication 1389 sequence if it does not include the AT_ANY_ID_REQ attribute. If the 1390 server was not able to recover the peer's identity from the fast 1391 re-authentication identity, the server includes either the 1392 AT_FULLAUTH_ID_REQ or the AT_PERMANENT_ID_REQ attribute in this EAP 1393 request. 1395 4.3.4 Fast Re-authentication Procedure 1397 Figure 8 illustrates the fast re-authentication procedure. In this 1398 example, the optional protected success indication is not used. 1399 Encrypted attributes are denoted with '*'. The peer uses its 1400 re-authentication identity in the EAP-Response/Identity packet. As 1401 discussed above, an alternative way to communicate the re- 1402 authentication identity to the server is for the peer to use the 1403 AT_IDENTITY attribute in the EAP-Response/SIM/Start message. This 1404 latter case is not illustrated in the figure below, and it is only 1405 possible when the server requests the peer to send its identity by 1406 including the AT_ANY_ID_REQ attribute in the EAP-Request/SIM/Start 1407 packet. 1409 If the server recognizes the identity as a valid fast 1410 re-authentication identity, and if the server agrees on using fast 1411 re-authentication, then the server sends the EAP-Request/SIM/ 1412 Re-authentication packet to the peer. This packet MUST include the 1413 encrypted AT_COUNTER attribute, with a fresh counter value, the 1414 encrypted AT_NONCE_S attribute that contains a random number chosen 1415 by the server, the AT_ENCR_DATA and the AT_IV attributes used for 1416 encryption, and the AT_MAC attribute that contains a message 1417 authentication code over the packet. The packet MAY also include an 1418 encrypted AT_NEXT_REAUTH_ID attribute that contains the next fast 1419 re-authentication identity. 1421 Fast re-authentication identities are one-time identities. If the 1422 peer does not receive a new fast re-authentication identity, it MUST 1423 use either the permanent identity or a pseudonym identity on the next 1424 authentication to initiate full authentication. 1426 The peer verifies that AT_MAC is correct, and that the counter value 1427 is fresh (greater than any previously used value). The peer MAY save 1428 the next fast re-authentication identity from the encrypted 1429 AT_NEXT_REAUTH_ID for next time. If all checks are successful, the 1430 peer responds with the EAP-Response/SIM/Re-authentication packet, 1431 including the AT_COUNTER attribute with the same counter value and 1432 the AT_MAC attribute. 1434 The server verifies the AT_MAC attribute and also verifies that the 1435 counter value is the same that it used in the EAP-Request/SIM/ 1436 Re-authentication packet. If these checks are successful, the 1437 re-authentication has succeeded and the server sends the EAP-Success 1438 packet to the peer. 1440 If protected success indications (Section 4.4.2) were used, the 1441 EAP-Success packet would be preceded by an EAP-SIM notification 1442 round. 1444 Peer Authenticator 1445 | | 1446 | EAP-Request/Identity | 1447 |<------------------------------------------------------| 1448 | | 1449 | EAP-Response/Identity | 1450 | (Includes a fast re-authentication identity) | 1451 |------------------------------------------------------>| 1452 | | 1453 | +--------------------------------+ 1454 | | Server recognizes the identity | 1455 | | and agrees on using fast | 1456 | | re-authentication | 1457 | +--------------------------------+ 1458 | | 1459 : : 1460 : : 1462 : : 1463 : : 1464 | EAP-Request/SIM/Re-authentication | 1465 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1466 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1467 |<------------------------------------------------------| 1468 | | 1469 +-----------------------------------------------+ | 1470 | Peer verifies AT_MAC and the freshness of | | 1471 | the counter. Peer MAY store the new fast re- | | 1472 | authentication identity for next re-auth. | | 1473 +-----------------------------------------------+ | 1474 | | 1475 | EAP-Response/SIM/Re-authentication | 1476 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, | 1477 | AT_MAC) | 1478 |------------------------------------------------------>| 1479 | +--------------------------------+ 1480 | | Server verifies AT_MAC and | 1481 | | the counter | 1482 | +--------------------------------+ 1483 | | 1484 | EAP-Success | 1485 |<------------------------------------------------------| 1486 | | 1488 Figure 8: Fast Re-authentication 1490 4.3.5 Fast Re-authentication Procedure when Counter is Too Small 1492 If the peer does not accept the counter value of EAP-Request/SIM/ 1493 Re-authentication, it indicates the counter synchronization problem 1494 by including the encrypted AT_COUNTER_TOO_SMALL in EAP-Response/SIM/ 1495 Re-authentication. The server responds with EAP-Request/SIM/Start to 1496 initiate a normal full authentication procedure. This is illustrated 1497 in Figure 9. Encrypted attributes are denoted with '*'. 1499 Peer Authenticator 1500 | EAP-Request/Identity | 1501 |<------------------------------------------------------| 1502 | | 1503 | EAP-Response/Identity | 1504 | (Includes a fast re-authentication identity) | 1505 |------------------------------------------------------>| 1506 | | 1507 | EAP-Request/SIM/Re-authentication | 1508 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1509 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1510 |<------------------------------------------------------| 1511 +-----------------------------------------------+ | 1512 | AT_MAC is valid but the counter is not fresh. | | 1513 +-----------------------------------------------+ | 1514 | | 1515 | EAP-Response/SIM/Re-authentication | 1516 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, | 1517 | *AT_COUNTER, AT_MAC) | 1518 |------------------------------------------------------>| 1519 | +----------------------------------------------+ 1520 | | Server verifies AT_MAC but detects | 1521 | | That peer has included AT_COUNTER_TOO_SMALL | 1522 | +----------------------------------------------+ 1523 | | 1524 | EAP-Request/SIM/Start | 1525 | (AT_VERSION_LIST) | 1526 |<------------------------------------------------------| 1527 +---------------------------------------------------------------+ 1528 | Normal full authentication follows. | 1529 +---------------------------------------------------------------+ 1530 | | 1532 Figure 9: Fast Re-authentication, counter is not fresh 1534 In the figure above, the first three messages are similar to the 1535 basic fast re-authentication case. When the peer detects that the 1536 counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL 1537 attribute in EAP-Response/SIM/Re-authentication. This attribute 1538 doesn't contain any data but it is a request for the server to 1539 initiate full authentication. In this case, the peer MUST ignore the 1540 contents of the server's AT_NEXT_REAUTH_ID attribute. 1542 On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and 1543 verifies that AT_COUNTER contains the same counter value as in the 1544 EAP-Request/SIM/Re-authentication packet. If not, the server 1545 terminates the authentication exchange by sending the EAP-Request/ 1546 SIM/Notification with AT_NOTIFICATION code 16384. If all checks on 1547 the packet are successful, the server transmits a new EAP-Request/ 1548 SIM/Start packet and the full authentication procedure is performed 1549 as usual. Since the server already knows the subscriber identity, it 1550 MUST NOT include AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or 1551 AT_PERMANENT_ID_REQ in the EAP-Request/SIM/Start. 1553 4.4 EAP-SIM Notifications 1555 4.4.1 General 1557 The EAP server can use EAP-SIM notifications to convey localizable 1558 notifications and result indications (Section 4.4.2) to the peer. 1560 The server MUST use notifications in cases discussed in Section 1561 4.5.2. When the EAP server issues an EAP-Request/SIM/Notification 1562 packet to the peer, the peer MUST process the notification packet. 1563 The peer MAY show a notification message to the user and the peer 1564 MUST respond to the EAP server with an EAP-Response/SIM/Notification 1565 packet, even if the peer did not recognize the notification code. 1567 An EAP-SIM full authentication exchange or a fast re-authentication 1568 exchange MUST NOT include more than one EAP-SIM notification round. 1570 The notification code is a 16-bit number. The most significant bit is 1571 called the Failure bit (F bit). The F bit specifies whether the 1572 notification implies failure. The code values with the F bit set to 1573 zero (code values 0...32767) are used on unsuccessful cases. The 1574 receipt of a notification code from this range implies failed EAP 1575 exchange, so the peer can use the notification as a failure 1576 indication. After receiving the EAP-Response/SIM/Notification for 1577 these notification codes, the server MUST send the EAP-Failure 1578 packet. 1580 The receipt of a notification code with the F bit set to one (values 1581 32768...65536) does not imply failure. Notification code 32768 has 1582 been reserved as a general notification code to indicate successful 1583 authentication. 1585 The second most significant bit of the notification code is called 1586 the Phase bit (P bit). It specifies at which phase of the EAP-SIM 1587 exchange the notification can be used. If the P bit is set to zero, 1588 the notification can only be used after a successful EAP/SIM/ 1589 Challenge round in full authentication or a successful EAP/SIM/ 1590 Re-authentication round in reautentication. A re-authentication round 1591 is considered successful only if the peer has successfully verified 1592 AT_MAC and AT_COUNTER attributes, and does not include the 1593 AT_COUNTER_TOO_SMALL attribute in EAP-Response/SIM/Re-authentication. 1595 If the P bit is set to one, the notification can only by used before 1596 the EAP/SIM/Challenge round in full authentication, or before the 1597 EAP/SIM/Re-authentication round in reauthentication. 1599 Section 6.8 and Section 6.9 specify what other attributes must be 1600 included in the notification packets. 1602 Some of the notification codes are authorization related and hence 1603 not usually considered as part of the responsibility of an EAP 1604 method. However, they are included as part of EAP-SIM because there 1605 are currently no other ways to convey this information to the user in 1606 a localizable way, and the information is potentially useful for the 1607 user. An EAP-SIM server implementation may decide never to send these 1608 EAP-SIM notifications. 1610 4.4.2 Result Indications 1612 As discussed in Section 4.5, the server and the peer use explicit 1613 error messages in all error cases. If the server detects an error 1614 after successful authentication, the server uses an EAP-SIM 1615 notification to indicate failure to the peer. In this case, the 1616 result indication is integrity and replay protected. 1618 By sending an EAP-Response/SIM/Challenge packet or an EAP-Response/ 1619 SIM/Re-authentication packet (without AT_COUNTER_TOO_SMALL), the peer 1620 indicates that it has successfully authenticated the server and that 1621 the peer's local policy accepts the EAP exchange. In other words, 1622 these packets are implicit success indications from the peer to the 1623 server. 1625 EAP-SIM also supports optional protected success indications from the 1626 server to the peer. If the EAP server wants to use protected success 1627 indications, it includes the AT_RESULT_IND attribute in the 1628 EAP-Request/SIM/Challenge or the EAP-Request/SIM/Re-authentication 1629 packet. This attribute indicates that the EAP server would like to 1630 use result indications in both successful and unsuccessful cases. If 1631 the peer also wants this, the peer includes AT_RESULT_IND in 1632 EAP-Response/SIM/Challenge or EAP-Response/SIM/Re-authentication. The 1633 peer MUST NOT include AT_RESULT_IND if it did not receive 1634 AT_RESULT_IND from the server. If both the peer and the server used 1635 AT_RESULT_IND, then the EAP exchange is not complete yet, but an 1636 EAP-SIM notification round will follow. The following EAP-SIM 1637 notification may indicate either failure or success. 1639 Success indications with the AT_NOTIFICATION code 32768 can only be 1640 used if both the server and the peer indicate they want to use them 1641 with AT_RESULT_IND. If the server did not include AT_RESULT_IND in 1642 the EAP-Request/SIM/Challenge or EAP-Request/SIM/Re-authentication 1643 packet, or if the peer did not include AT_RESULT_IND in the 1644 corresponding response packet, then the server MUST NOT use protected 1645 success indications. 1647 Because the AT_NOTIFICATION code 32768 is used to indicate success, 1648 the server MUST ignore the contents of the EAP-SIM response it 1649 receives to the EAP-Request/SIM/Notification with this code. 1650 Regardless of the contents of the EAP-SIM response, the server MUST 1651 send EAP-Success as the next packet. 1653 4.5 Error Cases 1655 This section specifies the operation of the peer and the server in 1656 error cases. The subsections below require the EAP-SIM peer and 1657 server to send an error packet (EAP-Response/SIM/Client-Error or 1658 EAP-Request/SIM/Notification) in error cases. However, 1659 implementations SHOULD NOT rely upon the correct error reporting 1660 behavior of the peer, authenticator, or the server. It is possible 1661 for error and other messages to be lost in transit or for a malicious 1662 participant to attempt to consume resources by not issuing error 1663 messages. Both the peer and the EAP server SHOULD have a mechanism 1664 to clean up state even if an error message or EAP-Success is not 1665 received after a timeout period. 1667 4.5.1 Peer Operation 1669 In general, if an EAP-SIM peer detects an error in a received EAP-SIM 1670 packet, the EAP-SIM implementation responds with the EAP-Response/ 1671 SIM/Client-Error packet. In response to the EAP-Response/SIM/ 1672 Client-Error, the EAP server MUST issue the EAP-Failure packet and 1673 the authentication exchange terminates. 1675 By default, the peer uses the client error code 0, "unable to process 1676 packet". This error code is used in the following cases: 1678 o EAP exchange is not acceptable according to the peer's local 1679 policy. 1680 o the peer is not able to parse the EAP request, i.e. the EAP 1681 request is malformed 1682 o the peer encountered a malformed attribute 1683 o wrong attribute types or duplicate attributes have been included 1684 in the EAP request 1685 o a mandatory attribute is missing 1686 o unrecognized non-skippable attribute 1687 o unrecognized or unexpected EAP-SIM Subtype in the EAP request 1688 o A RAND challenge repeated in AT_RAND 1689 o invalid AT_MAC 1690 o invalid pad bytes in AT_PADDING 1691 o the peer does not want to process AT_PERMANENT_ID_REQ 1693 Separate error codes have been defined for the following error cases 1694 in Section 7.19: 1696 As specified in Section 4.1, when processing the AT_VERSION_LIST 1697 attribute, which lists the EAP-SIM versions supported by the server, 1698 if the attribute does not include a version that is implemented by 1699 the peer and allowed in the peer's security policy, then the peer 1700 MUST send the EAP-Response/SIM/Client-Error packet with the error 1701 code "unsupported version". 1703 When processing the AT_RAND attribute, the peer MUST send the EAP- 1704 Response/SIM/Client-Error packet with the error code "insufficient 1705 number of challenges", if the number of RAND challenges is smaller 1706 than what is required by peer's local policy. 1708 If the peer believes that the RAND challenges included in AT_RAND are 1709 not fresh e.g. because it is capable of remembering some previously 1710 used RANDs, the peer MUST send the EAP-Response/SIM/Client-Error 1711 packet with the error code "RANDs are not fresh". 1713 4.5.2 Server Operation 1715 If an EAP-SIM server detects an error in a received EAP-SIM response, 1716 the server MUST issue the EAP-Request/SIM/Notification packet with an 1717 AT_NOTIFICATION code that implies failure. By default, the server 1718 uses one of the general failure codes (0 or 16384). The choice 1719 between these two codes depends on the phase of the EAP-SIM exchange, 1720 see Section 4.4. The error cases when the server issues an 1721 EAP-Request/SIM/Notification that implies failure include the 1722 following: 1724 o the server is not able to parse the peer's EAP response 1725 o the server encounters a malformed attribute, a non-recognized 1726 non-skippable attribute, or a duplicate attribute 1727 o a mandatory attribute is missing or an invalid attribute was 1728 included 1729 o unrecognized or unexpected EAP-SIM Subtype in the EAP Response 1730 o invalid AT_MAC 1731 o invalid AT_COUNTER 1733 4.5.3 EAP-Failure 1735 The EAP-SIM server sends EAP-Failure in two cases: 1737 1) In response to an EAP-Response/SIM/Client-Error packet the server 1738 has received from the peer, or 1740 2) Following an EAP-SIM notification round, when the AT_NOTIFICATION 1741 code implies failure. 1743 The EAP-SIM server MUST NOT send EAP-Failure in other cases than 1744 these two. However, it should be noted that even though the EAP-SIM 1745 server would not send an EAP-Failure, an authorization decision that 1746 happens outside EAP-SIM, such as in the AAA server or in an 1747 intermediate AAA proxy, may result in a failed exchange. 1749 The peer MUST accept the EAP-Failure packet in case 1) and case 2) 1750 above. The peer SHOULD silently discard the EAP-Failure packet in 1751 other cases. 1753 4.5.4 EAP-Success 1755 On full authentication, the server can only send EAP-Success after 1756 the EAP/SIM/Challenge round. The peer MUST silently discard any 1757 EAP-Success packets if they are received before the peer has 1758 successfully authenticated the server and sent the EAP-Response/SIM/ 1759 Challenge packet. 1761 If the peer did not indicate that it wants to use protected success 1762 indications with AT_RESULT_IND (as discussed in Section 4.4.2) on 1763 full authentication, then the peer MUST accept EAP-Success after a 1764 successful EAP/SIM/Challenge round. 1766 If the peer indicated that it wants to use protected success 1767 indications with AT_RESULT_IND (as discussed in Section 4.4.2), then 1768 the peer MUST NOT accept EAP-Success after a successful EAP/SIM/ 1769 Challenge round. In this case, the peer MUST only accept EAP-Success 1770 after receiving an EAP-SIM Notification with the AT_NOTIFICATION code 1771 32768. 1773 On fast re-authentication, EAP-Success can only be sent after the 1774 EAP/SIM/Re-authentication round. The peer MUST silently discard any 1775 EAP-Success packets if they are received before the peer has 1776 successfully authenticated the server and sent the EAP-Response/SIM/ 1777 Re-authentication packet. 1779 If the peer did not indicate that it wants to use protected success 1780 indications with AT_RESULT_IND (as discussed in Section 4.4.2) on 1781 fast re-authentication, then the peer MUST accept EAP-Success after a 1782 successful EAP/SIM/Re-authentication round. 1784 If the peer indicated that it wants to use protected success 1785 indications with AT_RESULT_IND (as discussed in Section 4.4.2), then 1786 the peer MUST NOT accept EAP-Success after a successful EAP/SIM/ 1787 Re-authentication round. In this case, the peer MUST only accept 1788 EAP-Success after receiving an EAP-SIM Notification with the 1789 AT_NOTIFICATION code 32768. 1791 If the peer receives an EAP-SIM notification (Section 4.4) that 1792 indicates failure, then the peer MUST no longer accept the 1793 EAP-Success packet even if the server authentication was successfully 1794 completed. 1796 4.6 Key Generation 1798 This section specifies how keying material is generated. 1800 On EAP-SIM full authentication, a Master Key (MK) is derived from the 1801 underlying GSM authentication values (Kc keys), the NONCE_MT and 1802 other relevant context as follows. 1804 MK = SHA1(Identity|n*Kc| NONCE_MT| Version List| Selected Version) 1806 In the formula above, the "|" character denotes concatenation. 1807 Identity denotes the peer identity string without any terminating 1808 null characters. It is the identity from the AT_IDENTITY attribute 1809 from the last EAP-Response/SIM/Start packet, or, if AT_IDENTITY was 1810 not used, the identity from the EAP-Response/Identity packet. The 1811 identity string is included as-is, without any changes and including 1812 the possible identity decoration. The notation n*Kc denotes the n Kc 1813 values concatenated. The Kc keys are used in the same order as the 1814 RAND challenges in AT_RAND attribute. NONCE_MT denotes the NONCE_MT 1815 value (not the AT_NONCE_MT attribute but just the nonce value). The 1816 Version List includes the 2-byte supported version numbers from 1817 AT_VERSION_LIST, in the same order as in the attribute. The Selected 1818 Version is the 2-byte selected version from AT_SELECTED_VERSION. 1819 Network byte order is used, just as in the attributes. The hash 1820 function SHA-1 is specified in [SHA-1]. If several EAP/SIM/Start 1821 roundtrips are used in an EAP-SIM exchange, then the NONCE_MT, 1822 Version List and Selected version from the last EAP/SIM/Start round 1823 are used, and the previous EAP/SIM/Start rounds are ignored. 1825 The Master Key is fed into a Pseudo-Random number Function (PRF) 1826 which generates separate Transient EAP Keys (TEKs) for protecting 1827 EAP-SIM packets, as well as a Master Session Key (MSK) for link layer 1828 security and an Extended Master Session Key (EMSK) for other 1829 purposes. On fast re-authentication, the same TEKs MUST be used for 1830 protecting EAP packets, but a new MSK and a new EMSK MUST be derived 1831 from the original MK and new values exchanged in the fast 1832 re-authentication. 1834 EAP-SIM requires two TEKs for its own purposes, the authentication 1835 key K_aut to be used with the AT_MAC attribute, and the encryption 1836 key K_encr, to be used with the AT_ENCR_DATA attribute. The same 1837 K_aut and K_encr keys are used in full authentication and subsequent 1838 fast re-authentications. 1840 Key derivation is based on the random number generation specified in 1841 NIST Federal Information Processing Standards (FIPS) Publication 1842 186-2 [PRF]. The pseudo-random number generator is specified in the 1843 change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As specified 1844 in the change notice (page 74), when Algorithm 1 is used as a 1845 general-purpose pseudo-random number generator, the "mod q" term in 1846 step 3.3 is omitted. The function G used in the algorithm is 1847 constructed via Secure Hash Standard as specified in Appendix 3.3 of 1848 the standard. It should be noted that the function G is very similar 1849 to SHA-1, but the message padding is different. Please refer to [PRF] 1850 for full details. For convenience, the random number algorithm with 1851 the correct modification is cited in Appendix B. 1853 160-bit XKEY and XVAL values are used, so b = 160. On each full 1854 authentication, the Master Key is used as the initial secret seed-key 1855 XKEY. The optional user input values (XSEED_j) in step 3.1 are set to 1856 zero. 1858 On full authentication, the resulting 320-bit random numbers x_0, 1859 x_1, ..., x_m-1 are concatenated and partitioned into suitable-sized 1860 chunks and used as keys in the following order: K_encr (128 bits), 1861 K_aut (128 bits), Master Session Key (64 bytes), Extended Master 1862 Session Key (64 bytes). 1864 On fast re-authentication, the same pseudo-random number generator 1865 can be used to generate a new Master Session Key and a new Extended 1866 Master Session Key. The seed value XKEY' is calculated as follows: 1868 XKEY' = SHA1(Identity|counter|NONCE_S| MK) 1870 In the formula above, the Identity denotes the fast re-authentication 1871 identity, without any terminating null characters, from the 1872 AT_IDENTITY attribute of the EAP-Response/SIM/Start packet, or, if 1873 EAP-Response/SIM/Start was not used on fast re-authentication, the 1874 identity string from the EAP-Response/Identity packet. The counter 1875 denotes the counter value from AT_COUNTER attribute used in the 1876 EAP-Response/SIM/Re-authentication packet. The counter is used in 1877 network byte order. NONCE_S denotes the 16-byte NONCE_S value from 1878 the AT_NONCE_S attribute used in the EAP-Request/SIM/ 1879 Re-authentication packet. The MK is the Master Key derived on the 1880 preceding full authentication. 1882 On fast re-authentication, the pseudo-random number generator is run 1883 with the new seed value XKEY', and the resulting 320-bit random 1884 numbers x_0, x_1, ..., x_m-1 are concatenated and partitioned into 1885 two 64-byte chunks and used as the new 64-byte Master Session Key and 1886 the new 64-byte Extended Master Session Key. Note that because K_encr 1887 and K_aut are not derived on fast re-authentication, the Master 1888 Session Key and the Extended Master Session key are obtained from the 1889 beginning of the key stream x_0, x_1, .... 1891 The first 32 bytes of the MSK can be used as the Pairwise Master Key 1892 (PMK) for IEEE 802.11i. 1894 When the RADIUS attributes specified in [RFC2548] are used to 1895 transport keying material, then the first 32 bytes of the MSK 1896 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to 1897 MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material (the 1898 MSK) are used. 1900 When generating the initial Master Key, the hash function is used as 1901 a mixing function to combine several session keys (Kc's) generated by 1902 the GSM authentication procedure and the random number NONCE_MT into 1903 a single session key. There are several reasons for this. The current 1904 GSM session keys are at most 64 bits, so two or more of them are 1905 needed to generate a longer key. By using a one-way function to 1906 combine the keys, we are assured that even if an attacker managed to 1907 learn one of the EAP-SIM session keys, it wouldn't help him in 1908 learning the original GSM Kc's. In addition, since we include the 1909 random number NONCE_MT in the calculation, the peer is able to verify 1910 that the EAP-SIM packets it receives from the network are fresh and 1911 not a replay. (Please see also Section 9.) 1913 5. Message Format and Protocol Extensibility 1915 5.1 Message Format 1917 As specified in [EAP], EAP packets begin with the Code, Identifiers, 1918 Length, and Type fields, which are followed by EAP method specific 1919 Type-Data. The Code field in the EAP header is set to 1 for EAP 1920 requests, and to 2 for EAP Responses. The usage of the Length and 1921 Identifier fields in the EAP header are also specified in [EAP]. In 1922 EAP-SIM, the Type field is set to 18. 1924 In EAP-SIM, the Type-Data begins with an EAP-SIM header that consists 1925 of a 1-octet Subtype field and a 2-octet reserved field. The Subtype 1926 values used in EAP-SIM are defined in Section 8. The formats of the 1927 EAP header and the EAP-SIM header are shown below. 1929 0 1 2 3 1930 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 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Code | Identifier | Length | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | Type | Subtype | Reserved | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 The rest of the Type-Data, immediately following the EAP-SIM header, 1938 consists of attributes that are encoded in Type, Length, Value 1939 format. The figure below shows the generic format of an attribute. 1941 0 1 2 3 1942 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 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | Type | Length | Value... 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 Attribute Type 1949 Indicates the particular type of attribute. The attribute type 1950 values are listed in 1951 Section 8 1952 . 1954 Length 1956 Indicates the length of this attribute in multiples of four 1957 bytes. The maximum length of an attribute is 1024 bytes. The 1958 length includes the Attribute Type and Length bytes. 1960 Value 1962 The particular data associated with this attribute. This field is 1963 always included and it may be two or more bytes in length. The 1964 type and length fields determine the format and length of the 1965 value field. 1967 Attributes numbered within the range 0 through 127 are called 1968 non-skippable attributes. When an EAP-SIM peer encounters a 1969 non-skippable attribute that the peer does not recognize, the peer 1970 MUST send the EAP-Response/SIM/Client-Error packet which terminates 1971 the authentication exchange. If an EAP-SIM server encounters a 1972 non-skippable attribute that the server does not recognize, then the 1973 server sends the EAP-Request/SIM/Notification packet with an 1974 AT_NOTIFICATION code that implies general failure (0 or 16384 1975 depending on the phase of the exchange), which terminates the 1976 authentication exchange. 1978 Attributes within the range of 128 through 255 are called skippable 1979 attributes. When a skippable attribute is encountered that is not 1980 recognized it is ignored. The rest of the attributes and message data 1981 MUST still be processed. The Length field of the attribute is used to 1982 skip the attribute value in searching for the next attribute. 1984 Unless otherwise specified, the order of the attributes in an EAP-SIM 1985 message is insignificant and an EAP-SIM implementation should not 1986 assume a certain order to be used. 1988 Attributes can be encapsulated within other attributes. In other 1989 words, the value field of an attribute type can be specified to 1990 contain other attributes. 1992 5.2 Protocol Extensibility 1994 EAP-SIM can be extended by specifying new attribute types. If 1995 skippable attributes are used, it is possible to extend the protocol 1996 without breaking old implementations. 1998 However, any new attributes added to the EAP-Request/SIM/Start or 1999 EAP-Response/SIM/Start packets would not be integrity protected. 2000 Therefore, these messages MUST NOT be extended in the current version 2001 of EAP-SIM. If the list of supported EAP-SIM versions in 2002 AT_VERSION_LIST does not include other versions than 1, then the 2003 server MUST NOT include other attributes besides those specified in 2004 this document in the EAP-Request/SIM/Start message. Note that future 2005 versions of this protocol might specify new attributes for 2006 EAP-Request/SIM/Start and still support version 1 of the protocol. In 2007 this case, the server might send an EAP-Request/SIM/Start message 2008 that includes new attributes, and indicate support for protocol 2009 version 1 and some other version in the AT_VERSION_LIST attribute. If 2010 the peer selects version 1, then the peer MUST ignore any other 2011 attributes included in EAP-Request/SIM/Start besides those specified 2012 in this document. If the selected EAP-SIM version in peer's 2013 AT_SELECTED_VERSION is 1, then the peer MUST NOT include other 2014 attributes besides those specified in this document in the 2015 EAP-Response/SIM/Start message. 2017 When specifying new attributes, it should be noted that EAP-SIM does 2018 not support message fragmentation. Hence, the sizes of the new 2019 extensions MUST be limited so that the maximum transfer unit (MTU) of 2020 the underlying lower layer is not exceeded. According to [EAP], lower 2021 layers must provide an EAP MTU of 1020 bytes or greater, so any 2022 extensions to EAP-SIM SHOULD NOT exceed the EAP MTU of 1020 bytes. 2024 Because EAP-SIM supports version negotiation, new versions of the 2025 protocol can also be specified by using a new version number. 2027 6. Messages 2029 This section specifies the messages used in EAP-SIM. It specifies 2030 when a message may be transmitted or accepted, which attributes are 2031 allowed in a message, which attributes are required in a message, and 2032 other message specific details. The general message format is 2033 specified in Section 5.1. 2035 6.1 EAP-Request/SIM/Start 2037 In full authentication the first SIM specific EAP Request is EAP- 2038 Request/SIM/Start. The EAP/SIM/Start roundtrip is used for two 2039 purposes. In full authentication this packet is used to request the 2040 peer to send the AT_NONCE_MT attribute to the server. In addition, as 2041 specified in Section 4.2, the Start round trip may be used by the 2042 server for obtaining the peer identity. As discussed in Section 4.2, 2043 several Start rounds may be required in order to obtain a valid peer 2044 identity. 2046 The server MUST always include the AT_VERSION_LIST attribute. 2048 The server MAY include one of the following identity requesting 2049 attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, and 2050 AT_ANY_ID_REQ. These three attributes are mutually exclusive, so the 2051 server MUST NOT include more than one of the attributes. 2053 If the server has received a response from the peer, it MUST NOT 2054 issue a new EAP-Request/SIM/Start packet if it has either previously 2055 issued an EAP-Request/SIM/Start message without any identity 2056 requesting attributes or with the AT_PERMANENT_ID_REQ attribute. 2058 If the server has received a response from the peer, it MUST NOT 2059 issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ or 2060 AT_FULLAUTH_ID_REQ attributes if it has previously issued an 2061 EAP-Request/SIM/Start message with the AT_FULLAUTH_ID_REQ attribute 2063 If the server has received a response from the peer, it MUST NOT 2064 issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ 2065 attribute if the server has previously issued an EAP-Request/SIM/ 2066 Start message with the AT_ANY_ID_REQ attribute. 2068 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. 2070 6.2 EAP-Response/SIM/Start 2072 The peer sends EAP-Response/SIM/Start in response to a valid 2073 EAP-Request/SIM/Start from the server. 2075 If and only if the server's EAP-Request/SIM/Start includes one of the 2076 identity requesting attributes, then the peer MUST include the 2077 AT_IDENTITY attribute. The usage of AT_IDENITY is defined in Section 2078 4.2. 2080 The AT_NONCE_MT attribute MUST NOT be included if the AT_IDENTITY 2081 with a fast re-authentication identity is present for fast 2082 re-authentication. AT_NONCE_MT MUST be included in all other cases 2083 (full authentication). 2085 The AT_SELECTED_VERSION attribute MUST NOT be included if the 2086 AT_IDENTITY attribute with a fast re-authentication identity is 2087 present for fast re-authentication. In all other cases, 2088 AT_SELECTED_VERSION MUST be included (full authentication). This 2089 attribute is used in version negotiation, as specified in Section 2090 4.1. 2092 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. 2094 6.3 EAP-Request/SIM/Challenge 2096 The server sends the EAP-Request/SIM/Challenge after receiving a 2097 valid EAP-Response/SIM/Start, containing AT_NONCE_MT and 2098 AT_SELECTED_VERSION, and after successfully obtaining the subscriber 2099 identity. 2101 The AT_RAND attribute MUST be included. 2103 The AT_RESULT_IND attribute MAY be included. The usage of this 2104 attribute is discussed in Section 4.4.2. 2106 The AT_MAC attribute MUST be included. For EAP-Request/SIM/Challenge, 2107 the MAC code is calculated over the following data: 2109 EAP packet| NONCE_MT 2111 The EAP packet is represented as specified in Section 5.1. It is 2112 followed by the 16-byte NONCE_MT value from the peer's AT_NONCE_MT 2113 attribute. 2115 The EAP-Request/SIM/Challenge packet MAY include encrypted attributes 2116 for identity privacy and for communicating the next fast 2117 re-authentication identity. In this case, the AT_IV and AT_ENCR_DATA 2118 attributes are included (Section 7.12). 2120 The plaintext of the AT_ENCR_DATA value field consists of nested 2121 attributes. The nested attributes MAY include AT_PADDING (as 2122 specified in Section 7.12). If the server supports identity privacy 2123 and wants to communicate a pseudonym to the peer for the next full 2124 authentication, then the nested encrypted attributes include the 2125 AT_NEXT_PSEUDONYM attribute. If the server supports re- 2126 authentication and wants to communicate a fast re-authentication 2127 identity to the peer, then the nested encrypted attributes include 2128 the AT_NEXT_REAUTH_ID attribute. 2130 When processing this message, the peer MUST process AT_RAND before 2131 processing other attributes. Only if AT_RAND is verified to be valid, 2132 the peer derives keys and verifies AT_MAC. The operation in case an 2133 error occurs is specified in Section 4.5.1. 2135 6.4 EAP-Response/SIM/Challenge 2137 The peer sends EAP-Response/SIM/Challenge in response to a valid 2138 EAP-Request/SIM/Challenge. 2140 Sending this packet indicates, that the peer has successfully 2141 authenticated the server and that the EAP exchange will be accepted 2142 by the peer's local policy. Hence, if these conditions are not met, 2143 then the peer MUST NOT send EAP-Response/SIM/Challenge, but the peer 2144 MUST send EAP-Response/SIM/Client-Error. 2146 The AT_MAC attribute MUST be included. For EAP- Response/SIM/ 2147 Challenge, the MAC code is calculated over the following data: 2149 EAP packet| n*SRES 2151 The EAP packet is represented as specified in Section 5.1. The EAP 2152 packet bytes are immediately followed by the two or three SRES values 2153 concatenated, denoted above with the notation n*SRES. The SRES values 2154 are used in the same order as the corresponding RAND challenges in 2155 server's AT_RAND attribute. 2157 The AT_RESULT_IND attribute MAY be included, if it was included in 2158 EAP-Request/SIM/Challenge. The usage of this attribute is discussed 2159 in Section 4.4.2. 2161 Later versions of this protocol MAY make use of the AT_ENCR_DATA and 2162 AT_IV attributes in this message to include encrypted (skippable) 2163 attributes. The EAP server MUST process EAP-Response/SIM/Challenge 2164 messages that include these attributes even if the server did not 2165 implement these optional attributes. 2167 6.5 EAP-Request/SIM/Re-authentication 2169 The server sends the EAP-Request/SIM/Re-authentication message if it 2170 wants to use fast re-authentication, and if it has received a valid 2171 fast re-authentication identity in EAP-Response/Identity or 2172 EAP-Response/SIM/Start. 2174 AT_MAC MUST be included. No message-specific data is included in the 2175 MAC calculation. See Section 7.14. 2177 The AT_RESULT_IND attribute MAY be included. The usage of this 2178 attribute is discussed in Section 4.4.2. 2180 The AT_IV and AT_ENCR_DATA attributes MUST be included. The plaintext 2181 consists of the following nested encrypted attributes, which MUST be 2182 included: AT_COUNTER and AT_NONCE_S. In addition, the nested 2183 encrypted attributes MAY include the following attributes: 2184 AT_NEXT_REAUTH_ID and AT_PADDING. 2186 6.6 EAP-Response/SIM/Re-authentication 2188 The client sends the EAP-Response/SIM/Re-authentication packet in 2189 response to a valid EAP-Request/SIM/Re-authentication. 2191 The AT_MAC attribute MUST be included. For EAP-Response/SIM/ 2192 Re-authentication, the MAC code is calculated over the following 2193 data: 2195 EAP packet| NONCE_S 2197 The EAP packet is represented as specified in Section 5.1. It is 2198 followed by the 16-byte NONCE_S value from the server's AT_NONCE_S 2199 attribute. 2201 The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested 2202 encrypted attributes MUST include the AT_COUNTER attribute. The 2203 AT_COUNTER_TOO_SMALL attribute MAY be included in the nested 2204 encrypted attributes, and it is included in cases specified in 2205 Section 4.3. The AT_PADDING attribute MAY be included. 2207 The AT_RESULT_IND attribute MAY be included, if it was included in 2208 EAP-Request/SIM/Re-authentication. The usage of this attribute is 2209 discussed in Section 4.4.2. 2211 Sending this packet without AT_COUNTER_TOO_SMALL indicates, that the 2212 peer has successfully authenticated the server and that the EAP 2213 exchange will be accepted by the peer's local policy. Hence, if these 2214 conditions are not met, then the peer MUST NOT send EAP-Response/SIM/ 2215 Re-authentication, but the peer MUST send EAP-Response/SIM/ 2216 Client-Error. 2218 6.7 EAP-Response/SIM/Client-Error 2220 The peer sends EAP-Response/SIM/Client-Error in error cases, as 2221 specified in Section 4.5.1. 2223 The AT_CLIENT_ERROR_CODE attribute MUST be included. 2225 The AT_MAC, AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with 2226 this packet. 2228 6.8 EAP-Request/SIM/Notification 2230 The usage of this message is specified in Section 4.4. 2232 The AT_NOTIFICATION attribute MUST be included. 2234 The AT_MAC attribute MUST beincluded if the P bit of the notification 2235 code in AT_NOTIFICATION is set to zero, and MUST NOT be included in 2236 cases when the P bit is set to one. The P bit is discussed in Section 2237 4.4. 2239 No message-specific data is included in the MAC calculation. See 2240 Section 7.14. 2242 If EAP-Request/SIM/Notification is used on fast a re-authentication 2243 exchange, and if the P bit in AT_NOTIFICATION is set to zero, then 2244 AT_COUNTER is used for replay protection. In this case, the 2245 AT_ENCR_DATA and AT_IV attributes MUST be included, and the 2246 encapsulated plaintext attributes MUST include the AT_COUNTER 2247 attribute. The counter value included in AT_COUNTER MUST be the same 2248 as in the EAP-Request/SIM/Re-authentication packet on the same fast 2249 re-authentication exchange. 2251 6.9 EAP-Response/SIM/Notification 2253 The usage of this message is specified in Section 4.4. This packet is 2254 an acknowledgement of EAP-Request/SIM/Notification. 2256 The AT_MAC attribute MUST included in cases when the P bit of the 2257 notification code in AT_NOTIFICATION of EAP-Request/SIM/Notification 2258 is set to zero, and MUST NOT be included in cases when the P bit is 2259 set to one. The P bit is discussed in Section 4.4. 2261 No message-specific data is included in the MAC calculation, see 2262 Section 7.14. 2264 If EAP-Request/SIM/Notification is used on fast a re-authentication 2265 exchange, and if the P bit in AT_NOTIFICATION is set to zero, then 2266 AT_COUNTER is used for replay protection. In this case, the 2267 AT_ENCR_DATA and AT_IV attributes MUST be included, and the 2268 encapsulated plaintext attributes MUST include the AT_COUNTER 2269 attribute. The counter value included in AT_COUNTER MUST be the same 2270 as in the EAP-Request/SIM/Re-authentication packet on the same fast 2271 re-authentication exchange. 2273 7. Attributes 2275 This section specifies the format of message attributes. The 2276 attribute type numbers are specified in Section 8. 2278 7.1 Table of Attributes 2280 The following table provides a guide to which attributes may be found 2281 in which kinds of messages, and in what quantity. Messages are 2282 denoted with numbers in parentheses as follows: (1) EAP-Request/SIM/ 2283 Start, (2) EAP-Response/SIM/Start, (3) EAP-Request/SIM/Challenge, (4) 2284 EAP-Response/SIM/Challenge, (5) EAP-Request/SIM/Notification, (6) 2285 EAP-Response/SIM/Notification, (7) EAP-Response/SIM/Client-Error (8) 2286 EAP-Request/SIM/Re-authentication, and (9) EAP-Response/SIM/ 2287 Re-authentication. The column denoted with "Encr" indicates whether 2288 the attribute is a nested attribute that MUST be included within 2289 AT_ENCR_DATA, and the column denoted with "Skip" indicates whether 2290 the attribute is a skippable attribute. 2292 "0" indicates that the attribute MUST NOT be included in the message, 2293 "1" indicates that the attribute MUST be included in the message, 2294 "0-1" indicates that the attribute is sometimes included in the 2295 message, and "0*" indicates that the attribute is not included in the 2296 message in cases specified in this document, but MAY be included in 2297 the future versions of the protocol. 2299 Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) Encr Skip 2300 AT_VERSION_LIST 1 0 0 0 0 0 0 0 0 N N 2301 AT_SELECTED_VERSION 0 0-1 0 0 0 0 0 0 0 N N 2302 AT_NONCE_MT 0 0-1 0 0 0 0 0 0 0 N N 2303 AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N 2304 AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N 2305 AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N 2306 AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 N N 2307 AT_RAND 0 0 1 0 0 0 0 0 0 N N 2308 AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 Y Y 2309 AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 Y Y 2310 AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 N Y 2311 AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 N Y 2312 AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 Y N 2313 AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 N Y 2314 AT_MAC 0 0 1 1 0-1 0-1 0 1 1 N N 2315 AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 Y N 2316 AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 Y N 2317 AT_NONCE_S 0 0 0 0 0 0 0 1 0 Y N 2318 AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 N N 2319 AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 N N 2321 It should be noted that attributes AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ 2322 and AT_FULLAUTH_ID_REQ are mutually exclusive, so that only one of 2323 them can be included at the same time. If one of the attributes AT_IV 2324 and AT_ENCR_DATA is included, then both of the attributes MUST be 2325 included. 2327 7.2 AT_VERSION_LIST 2329 The format of the AT_VERSION_LIST attribute is shown below. 2331 0 1 2 3 2332 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 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | AT_VERSION_L..| Length | Actual Version List Length | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | Supported Version 1 | Supported Version 2 | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 . . 2339 . . 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 | Supported Version N | Padding | 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 This attribute is used in version negotiation, as specified in 2345 Section 4.1. The attribute contains the version numbers supported by 2346 the EAP-SIM server. The server MUST only include versions that it 2347 implements and that are allowed in its security policy. The server 2348 SHOULD list the versions in the order of preference, most preferred 2349 versions first. At least one version number MUST be included. The 2350 version number for the protocol described in this document is one 2351 (0001 hexadecimal). 2353 The value field of this attribute begins with 2-byte Actual Version 2354 List Length, which specifies the length of the Version List in bytes, 2355 not including the Actual Version List Length attribute length. This 2356 field is followed by the list of the versions supported by the 2357 server, which each have a length of 2 bytes. For example, if there is 2358 only one supported version, then the Actual Version List Length is 2. 2359 Because the length of the attribute must be a multiple of 4 bytes, 2360 the sender pads the value field with zero bytes when necessary. 2362 7.3 AT_SELECTED_VERSION 2364 The format of the AT_SELECTED_VERSION attribute is shown below. 2366 0 1 2 3 2367 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 2368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2369 | AT_SELECTED...| Length = 1 | Selected Version | 2370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 This attribute is used in version negotiation, as specified in 2373 Section 4.1. The value field of this attribute contains a two-byte 2374 version number, which indicates the EAP-SIM version that the peer 2375 wants to use. 2377 7.4 AT_NONCE_MT 2379 The format of the AT_NONCE_MT attribute is shown below. 2381 0 1 2 3 2382 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 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 |AT_NONCE_MT | Length = 5 | Reserved | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 | | 2387 | NONCE_MT | 2388 | | 2389 | | 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 The value field of the NONCE_MT attribute contains two reserved bytes 2393 followed by a random number generated by the peer (16 bytes long) 2394 freshly for this EAP-SIM authentication exchange. The random number 2395 is used as a seed value for the new keying material. The reserved 2396 bytes are set to zero upon sending and ignored upon reception. 2398 The peer MUST NOT re-use the NONCE_MT value from a previous EAP-SIM 2399 authentication exchange. If an EAP-SIM exchange includes several EAP/ 2400 SIM/Start rounds, then the peer SHOULD use the same NONCE_MT value in 2401 all EAP-Response/SIM/Start packets. The peer SHOULD use a good source 2402 of randomness to generate NONCE_MT. Please see [RFC1750] for more 2403 information about generating random numbers for security 2404 applications. 2406 7.5 AT_PERMANENT_ID_REQ 2408 The format of the AT_PERMANENT_ID_REQ attribute is shown below. 2410 0 1 2 3 2411 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 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 |AT_PERM..._REQ | Length = 1 | Reserved | 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 The use of the AT_PERMANENT_ID_REQ is defined in Section 4.2. The 2417 value field only contains two reserved bytes, which are set to zero 2418 on sending and ignored on reception. 2420 7.6 AT_ANY_ID_REQ 2422 The format of the AT_ANY_ID_REQ attribute is shown below. 2424 0 1 2 3 2425 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 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 |AT_ANY_ID_REQ | Length = 1 | Reserved | 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 The use of the AT_ANY_ID_REQ is defined in Section 4.2. The value 2431 field only contains two reserved bytes, which are set to zero on 2432 sending and ignored on reception. 2434 7.7 AT_FULLAUTH_ID_REQ 2436 The format of the AT_FULLAUTH_ID_REQ attribute is shown below. 2438 0 1 2 3 2439 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 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 |AT_FULLAUTH_...| Length = 1 | Reserved | 2442 +---------------+---------------+-------------------------------+ 2444 The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.2. The 2445 value field only contains two reserved bytes, which are set to zero 2446 on sending and ignored on reception. 2448 7.8 AT_IDENTITY 2450 The format of the AT_IDENTITY attribute is shown below. 2452 0 1 2 3 2453 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 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2455 | AT_IDENTITY | Length | Actual Identity Length | 2456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2457 | | 2458 . Identity (optional) . 2459 . . 2460 | | 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 The use of the AT_IDENTITY is defined in Section 4.2. The value field 2464 of this attribute begins with 2-byte actual identity length, which 2465 specifies the length of the identity in bytes. This field is followed 2466 by the subscriber identity of the indicated actual length. The 2467 identity is the permanent identity, a pseudonym identity or a fast 2468 re-authentication identity. The identity format is specified in 2469 Section 4.2.1. The same identity format is used in the AT_IDENTITY 2470 attribute and the EAP-Response/Identity packet, with the exception 2471 that the peer MUST NOT decorate the identity it includes in 2472 AT_IDENTITY. The identity does not include any terminating null 2473 characters. Because the length of the attribute must be a multiple of 2474 4 bytes, the sender pads the identity with zero bytes when necessary. 2476 7.9 AT_RAND 2478 The format of the AT_RAND attribute is shown below. 2480 0 1 2 3 2481 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 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 | AT_RAND | Length | Reserved | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | | 2486 . n*RAND . 2487 . . 2488 | | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 The value field of this attribute contains two reserved bytes 2492 followed by n GSM RANDs, each 16 bytes long. The value of n can be 2493 determined by the attribute length. The reserved bytes are set to 2494 zero upon sending and ignored upon reception. 2496 The number of RAND challenges (n) MUST be two or three. The peer MUST 2497 verify that the number of RAND challenges is sufficient according to 2498 the peer's policy. The server MUST use different RAND values. In 2499 other words, a RAND value can only be included once in AT_RAND. When 2500 processing the AT_RAND attribute, the peer MUST check that the RANDs 2501 are different. 2503 The EAP server MUST obtain fresh RANDs for each EAP-SIM full 2504 authentication exchange. More specifically, the server MUST consider 2505 RANDs it included in AT_RAND to be consumed if the server receives an 2506 EAP-Response/SIM/Challenge packet with a valid AT_MAC, or an 2507 EAP-Response/SIM/Client-Error with the code "insufficient number of 2508 challenges" or "RANDs are not fresh". However, in other cases (if the 2509 server does not receive any response to its EAP- Request/SIM/ 2510 Challenge packet, or if the server receives some other kind of 2511 response than the cases listed above), the server does not need to 2512 consider the RANDs to be consumed, and the server MAY re-use the 2513 RANDs in the AT_RAND attribute of the next full authentication 2514 attempt. 2516 7.10 AT_NEXT_PSEUDONYM 2518 The format of the AT_NEXT_PSEUDONYM attribute is shown below. 2520 0 1 2 3 2521 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 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 | AT_NEXT_PSEU..| Length | Actual Pseudonym Length | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 | | 2526 . Next Pseudonym . 2527 . . 2528 | | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 The value field of this attribute begins with 2-byte actual pseudonym 2532 length, which specifies the length of the following pseudonym in 2533 bytes. This field is followed by a pseudonym username that the peer 2534 can use in the next authentication. The username MUST NOT include any 2535 realm portion. The username does not include any terminating null 2536 characters. Because the length of the attribute must be a multiple of 2537 4 bytes, the sender pads the pseudonym with zero bytes when 2538 necessary. The username encoding MUST follow the UTF-8 transformation 2539 format [RFC2279]. This attribute MUST always be encrypted by 2540 encapsulating it within the AT_ENCR_DATA attribute. 2542 7.11 AT_NEXT_REAUTH_ID 2544 The format of the AT_NEXT_REAUTH_ID attribute is shown below. 2546 0 1 2 3 2547 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 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length| 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | | 2552 . Next Fast Re-authentication Username . 2553 . . 2554 | | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 The value field of this attribute begins with 2-byte actual 2558 re-authentication identity length which specifies the length of the 2559 following fast re-authentication identity in bytes. This field is 2560 followed by a fast re-authentication identity that the peer can use 2561 in the next fast re-authentication, as described in Section 4.3. In 2562 environments where a realm portion is required, the fast 2563 re-authentication identity includes both a username portion and a 2564 realm name portion. The fast re-authentication identity does not 2565 include any terminating null characters. Because the length of the 2566 attribute must be a multiple of 4 bytes, the sender pads the fast 2567 re-authentication identity with zero bytes when necessary. The 2568 identity encoding MUST follow the UTF-8 transformation format 2569 [RFC2279]. This attribute MUST always be encrypted by encapsulating 2570 it within the AT_ENCR_DATA attribute. 2572 7.12 AT_IV, AT_ENCR_DATA and AT_PADDING 2574 AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted 2575 information between the EAP-SIM peer and server. 2577 The value field of AT_IV contains two reserved bytes followed by a 2578 16-byte initialization vector required by the AT_ENCR_DATA attribute. 2579 The reserved bytes are set to zero when sending and ignored on 2580 reception. The AT_IV attribute MUST be included if and only if the 2581 AT_ENCR_DATA is included. Section 4.5 specifies the operation if a 2582 packet that does not meet this condition is encountered. 2584 The sender of the AT_IV attribute chooses the initialization vector 2585 at random. The sender MUST NOT reuse the initialization vector value 2586 from previous EAP-SIM packets. The sender SHOULD use a good source of 2587 randomness to generate the initialization vector. Please see 2589 [RFC1750] for more information about generating random numbers for 2590 security applications. The format of AT_IV is shown below. 2592 0 1 2 3 2593 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 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | AT_IV | Length = 5 | Reserved | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 | | 2598 | Initialization Vector | 2599 | | 2600 | | 2601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 The value field of the AT_ENCR_DATA attribute consists of two 2604 reserved bytes followed by cipher text bytes encrypted using the 2605 Advanced Encryption Standard (AES) [AES] with a 128-bit key in the 2606 Cipher Block Chaining (CBC) mode of operation using the 2607 initialization vector from the AT_IV attribute. The reserved bytes 2608 are set to zero when sending and ignored on reception. Please see 2609 [CBC] for a description of the CBC mode. The format of the 2610 AT_ENCR_DATA attribute is shown below. 2612 0 1 2 3 2613 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 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 | AT_ENCR_DATA | Length | Reserved | 2616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2617 | | 2618 . Encrypted Data . 2619 . . 2620 | | 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 The derivation of the encryption key (K_encr) is specified in Section 2624 4.6. 2626 The plaintext consists of nested EAP-SIM attributes. 2628 The encryption algorithm requires the length of the plaintext to be a 2629 multiple of 16 bytes. The sender may need to include the AT_PADDING 2630 attribute as the last attribute within AT_ENCR_DATA. The AT_PADDING 2631 attribute is not included if the total length of other nested 2632 attributes within the AT_ENCR_DATA attribute is a multiple of 16 2633 bytes. As usual, the Length of the Padding attribute includes the 2634 Attribute Type and Attribute Length fields. The length of the Padding 2635 attribute is 4, 8 or 12 bytes. It is chosen so that the length of the 2636 value field of the AT_ENCR_DATA attribute becomes a multiple of 16 2637 bytes. The actual pad bytes in the value field are set to zero (00 2638 hexadecimal) on sending. The recipient of the message MUST verify 2639 that the pad bytes are set to zero. If this verification fails on the 2640 peer, then it MUST send the EAP-Response/SIM/Client-Error packet with 2641 the error code "unable to process packet" to terminate the 2642 authentication exchange. If this verification fails on the server, 2643 then the server sends the peer the EAP-Request/SIM/Notification 2644 packet with an AT_NOTIFICATION code that implies failure to terminate 2645 the authentication exchange. The format of the AT_PADDING attribute 2646 is shown below. 2648 0 1 2 3 2649 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 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 | AT_PADDING | Length | Padding... | 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2653 | | 2654 | | 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 7.13 AT_RESULT_IND 2659 The format of the AT_RESULT_IND attribute is shown below. 2661 0 1 2 3 2662 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 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 | AT_RESULT_...| Length = 1 | Reserved | 2665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 The value field of this attribute consists of two reserved bytes, 2668 which are set to zero upon sending and ignored upon reception. This 2669 attribute is always sent unencrypted, so it MUST NOT be encapsulated 2670 within the AT_ENCR_DATA attribute. 2672 7.14 AT_MAC 2674 The AT_MAC attribute is used for EAP-SIM message authentication. 2675 Section 6 specifies which messages AT_MAC MUST be included. 2677 The value field of the AT_MAC attribute contains two reserved bytes 2678 followed by a keyed message authentication code (MAC). The MAC is 2679 calculated over the whole EAP packet concatenated with optional 2680 message-specific data, with the exception that the value field of the 2681 MAC attribute is set to zero when calculating the MAC. The EAP packet 2682 includes the EAP header that begins with the Code field, the EAP-SIM 2683 header that begins with the Subtype field, and all the attributes, as 2684 specified in Section 5.1. The reserved bytes in AT_MAC are set to 2685 zero when sending and ignored on reception. The contents of the 2686 message-specific data that may be included in the MAC calculation are 2687 specified separately for each EAP-SIM message in Section 6. 2689 The format of the AT_MAC attribute is shown below. 2691 0 1 2 3 2692 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 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 | AT_MAC | Length = 5 | Reserved | 2695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 | | 2697 | MAC | 2698 | | 2699 | | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The 2703 HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by 2704 truncating the output to the first 16 bytes. Hence, the length of the 2705 MAC is 16 bytes.) The derivation of the authentication key (K_aut) 2706 used in the calculation of the MAC is specified in Section 4.6. 2708 When the AT_MAC attribute is included in an EAP-SIM message, the 2709 recipient MUST process the AT_MAC attribute before looking at any 2710 other attributes, except when processing EAP-Request/SIM/Challenge. 2711 The processing of EAP-Request/SIM/Challenge is specified in Section 2712 6.3. If the message authentication code is invalid, then the 2713 recipient MUST ignore all other attributes in the message and operate 2714 as specified in Section 4.5. 2716 7.15 AT_COUNTER 2718 The format of the AT_COUNTER attribute is shown below. 2720 0 1 2 3 2721 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 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | AT_COUNTER | Length = 1 | Counter | 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 The value field of the AT_COUNTER attribute consists of a 16-bit 2727 unsigned integer counter value, represented in network byte order. 2728 This attribute MUST always be encrypted by encapsulating it within 2729 the AT_ENCR_DATA attribute. 2731 7.16 AT_COUNTER_TOO_SMALL 2733 The format of the AT_COUNTER_TOO_SMALL attribute is shown below. 2735 0 1 2 3 2736 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 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 | AT_COUNTER...| Length = 1 | Reserved | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 The value field of this attribute consists of two reserved bytes, 2742 which are set to zero upon sending and ignored upon reception. This 2743 attribute MUST always be encrypted by encapsulating it within the 2744 AT_ENCR_DATA attribute. 2746 7.17 AT_NONCE_S 2748 The format of the AT_NONCE_S attribute is shown below. 2750 0 1 2 3 2751 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 2752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 | AT_NONCE_S | Length = 5 | Reserved | 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2755 | | 2756 | | 2757 | NONCE_S | 2758 | | 2759 | | 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 The value field of the AT_NONCE_S attribute contains two reserved 2763 bytes followed by a random number generated by the server (16 bytes) 2764 freshly for this EAP-SIM fast re-authentication. The random number is 2765 used as challenge for the peer and also a seed value for the new 2766 keying material. The reserved bytes are set to zero upon sending and 2767 ignored upon reception. This attribute MUST always be encrypted by 2768 encapsulating it within the AT_ENCR_DATA attribute. 2770 The server MUST NOT reuse the NONCE_S value from any previous EAP-SIM 2771 fast re-authentication exchange. The server SHOULD use a good source 2772 of randomness to generate NONCE_S. Please see [RFC1750] for more 2773 information about generating random numbers for security 2774 applications. 2776 7.18 AT_NOTIFICATION 2778 The format of the AT_NOTIFICATION attribute is shown below. 2780 0 1 2 3 2781 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 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 |AT_NOTIFICATION| Length = 1 |F|P| Notification Code | 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 The value field of this attribute contains a two-byte notification 2787 code. The first and second bit (F and P) of the notification code are 2788 interpreted as described in Section 4.4. 2790 The notification code values listed below have been reserved. The 2791 descriptions below illustrate the semantics of the notifications. The 2792 peer implementation MAY use different wordings when presenting the 2793 notifications to the user. The "requested service" depends on the 2794 environment where EAP-SIM is applied. 2796 0 - General failure. (implies failure, used after successful 2797 authentication) 2799 16384 - General failure. (implies failure, used before 2800 authentication) 2802 32768 - User has been successfully authenticated. (does not imply 2803 failure, used after successful authentication). The usage of this 2804 code is discussed in Section 4.4.2. 2806 1026 - User has been temporarily denied access to the requested 2807 service. (Implies failure, used after successful authentication) 2809 1031 - User has not subscribed to the requested service (implies 2810 failure, used after successful authentication) 2812 7.19 AT_CLIENT_ERROR_CODE 2814 The format of the AT_CLIENT_ERROR_CODE attribute is shown below. 2816 0 1 2 3 2817 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 2818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 |AT_CLIENT_ERR..| Length = 1 | Client Error Code | 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 The value field of this attribute contains a two-byte client error 2823 code. The following error code values have been reserved. 2825 0 "unable to process packet": a general error code 2827 1 "unsupported version": the peer does not support any of 2828 the versions listed in AT_VERSION_LIST 2830 2 "insufficient number of challenges": the peer's policy 2831 requires more triplets than the server included in AT_RAND 2833 3 "RANDs are not fresh": the peer believes that the RAND 2834 challenges included in AT_RAND were not fresh 2836 8. IANA Considerations 2838 IANA has assigned the EAP type number 18 for this protocol. 2840 EAP-SIM messages include a Subtype field. The Subtype is a new 2841 numbering space for which IANA administration is required. The 2842 following Subtypes are specified in this document: 2844 Start..........................................10 2845 Challenge......................................11 2846 Notification...................................12 2847 Re-authentication..............................13 2848 Client-Error...................................14 2850 The messages are composed of attributes, which have attribute type 2851 numbers. The EAP-SIM attribute type number is a new numbering space 2852 for which IANA administration is required. The following attribute 2853 types are specified in this document: 2855 AT_RAND.........................................1 2856 AT_PADDING......................................6 2857 AT_NONCE_MT.....................................7 2858 AT_PERMANENT_ID_REQ............................10 2859 AT_MAC.........................................11 2860 AT_NOTIFICATION................................12 2861 AT_ANY_ID_REQ..................................13 2862 AT_IDENTITY....................................14 2863 AT_VERSION_LIST................................15 2864 AT_SELECTED_VERSION............................16 2865 AT_FULLAUTH_ID_REQ.............................17 2866 AT_COUNTER.....................................19 2867 AT_COUNTER_TOO_SMALL...........................20 2868 AT_NONCE_S.....................................21 2869 AT_CLIENT_ERROR_CODE...........................22 2870 AT_IV.........................................129 2871 AT_ENCR_DATA..................................130 2872 AT_NEXT_PSEUDONYM.............................132 2873 AT_NEXT_REAUTH_ID.............................133 2874 AT_RESULT_IND.................................135 2876 The AT_NOTIFICATION attribute contains a notification code value. The 2877 notification code is a new numbering space for which IANA 2878 administration is required. Values 0, 1024, 1026, 1031, 16384 and 2879 32768 have been specified in Section 7.18 of this document. 2881 The AT_VERSION_LIST and AT_SELECTED_VERSION attributes contain 2882 version numbers. The EAP-SIM version number is a new numbering space 2883 for which IANA administration is required. Version 1 has been 2884 specified in Section 7.2 of this document. 2886 The AT_CLIENT_ERROR_CODE attribute contains a client error code. The 2887 client error code is a new numbering space for which IANA 2888 administration is required. Values 0, 1, 2 and 3 have been specified 2889 in Section 7.19 of this document. 2891 All requests for value assignment from the various number spaces 2892 described in this document require proper documentation, according to 2893 the "Specification Required" policy described in [RFC2434]. Requests 2894 must be specified in sufficient detail so that interoperability 2895 between independent implementations is possible. Possible forms of 2896 documentation include, but are not limited to, RFCs, the products of 2897 another standards body (e.g. 3GPP), or permanently and readily 2898 available vendor design notes. 2900 EAP-SIM and EAP-AKA [EAP-AKA] are "sister" protocols with similar 2901 message structure and protocol numbering spaces. Many attributes and 2902 message Subtypes have the same protocol numbers in these two 2903 protocols. Hence, it is recommended that the same protocol number 2904 value SHOULD NOT be allocated for two different purposes in EAP-AKA 2905 and EAP-SIM. 2907 9. Security Considerations 2909 The EAP base protocol [EAP] highlights several attacks that are 2910 possible against the EAP protocol as there is no inherent security 2911 mechanisms provided. This section discusses the claimed security 2912 properties of EAP-SIM as well as vulnerabilities and security 2913 recommendations. 2915 9.1 Identity Protection 2917 EAP-SIM includes optional identity privacy support that protects the 2918 privacy of the subscriber identity against passive eavesdropping. 2919 This document only specifies a mechanism to deliver pseudonyms from 2920 the server to the peer as part of an EAP-SIM exchange. Hence, a peer 2921 that has not yet performed any EAP-SIM exchanges does not typically 2922 have a pseudonym available. If the peer does not have a pseudonym 2923 available, then the privacy mechanism cannot be used, but the 2924 permanent identity will have to be sent in the clear. The terminal 2925 SHOULD store the pseudonym in a non-volatile memory so that it can be 2926 maintained across reboots. An active attacker that impersonates the 2927 network may use the AT_PERMANENT_ID_REQ attribute to attempt to learn 2928 the subscriber's permanent identity. However, as discussed in Section 2929 4.2.2, the terminal can refuse to send the cleartext permanent 2930 identity if it believes that the network should be able to recognize 2931 the pseudonym. 2933 If the peer and server cannot guarantee that the pseudonym will be 2934 maintained reliably and identity privacy is required then additional 2935 protection from an external security mechanism such as Protected 2936 Extensible Authentication Protocol (PEAP) [PEAP] may be used. If an 2937 external security mechanism is in use the identity privacy features 2938 of EAP-SIM may not be useful. The security considerations of using an 2939 external security mechanism with EAP-SIM are beyond the scope of this 2940 document. 2942 9.2 Mutual Authentication and Triplet Exposure 2944 EAP-SIM provides mutual authentication. The peer believes that the 2945 network is authentic because the network can calculate a correct 2946 AT_MAC value in the EAP-Request/SIM/Challenge packet. To calculate 2947 AT_MAC it is sufficient to know the RAND and Kc values from the GSM 2948 triplets (RAND, SRES, Kc) used in the authentication. Because the 2949 network selects the RAND challenges and the triplets, an attacker 2950 that knows n (2 or 3) GSM triplets for the subscriber is able to 2951 impersonate a valid network to the peer. (Some peers MAY employ an 2952 implementation-specific counter-measure against impersonating a valid 2953 network by re-using a previously used RAND; see below.) Given 2954 physical access to the SIM card, it is easy to obtain any number of 2955 GSM triplets. Another way to obtain triplets is to mount an attack on 2956 the peer platform via a virus or other malicious piece of software. 2957 The peer SHOULD be protected against triplet querying attacks by 2958 malicious software. 2960 If the same SIM credentials are also used for GSM traffic, the 2961 triplets could be revealed in the GSM network; see Section 9.6. 2963 The security of EAP-SIM is based on the secrecy of Kc keys, which are 2964 considered secret intermediate results in the EAP-SIM cryptographic 2965 calculations. Care should be taken not to expose Kc keys to attackers 2966 when they are transmitted between entities, stored or handled. Steps 2967 should be taken to limit the transport, storage and handling of these 2968 values outside a protected environment. These considerations are 2969 important at both the peer and EAP server implementations. 2971 In GSM, the network is allowed to reuse the RAND challenge in 2972 consecutive authentication exchanges. This is not allowed in EAP-SIM. 2973 The EAP-SIM server is mandated to use fresh triplets (RAND 2974 challenges) in consecutive authentication exchanges, as specified in 2975 Section 3. EAP-SIM does not mandate any means for the peer to check 2976 if the RANDs are fresh, so the security of the scheme leans on the 2977 secrecy of the triplets. However, the peer MAY employ 2978 implementation-specific mechanisms to remember some of the previously 2979 used RANDs, and the peer MAY check the freshness of the server's 2980 RANDs. The operation in cases when the peer detects that the RANDs 2981 are not fresh is specified in Section 4.5.1. 2983 Preventing the re-use of authentication vectors has been taken into 2984 account in the design of the UMTS Authentication and Key Agreement 2985 (AKA), which is used in EAP-AKA [EAP-AKA]. In cases when the triplet 2986 re-use properties of EAP-SIM are not considered sufficient, it is 2987 advised to use EAP-AKA. 2989 9.3 Flooding the Authentication Centre 2991 The EAP-SIM server typically obtains authentication vectors from the 2992 Authentication Centre (AuC). EAP-SIM introduces a new usage for the 2993 AuC. The protocols between the EAP-SIM server and the AuC are out of 2994 the scope of this document. However, it should be noted that a 2995 malicious EAP-SIM peer may generate a lot of protocol requests to 2996 mount a denial of service attack. The EAP-SIM server implementation 2997 SHOULD take this into account and SHOULD take steps to limit the 2998 traffic that it generates towards the AuC, preventing the attacker 2999 from flooding the AuC and from extending the denial of service attack 3000 from EAP-SIM to other users of the AuC. 3002 9.4 Key Derivation 3004 EAP-SIM supports key derivation. The key hierarchy is specified in 3005 Section 4.6. EAP-SIM combines several GSM triplets in order to 3006 generate stronger keying material and stronger AT_MAC values. The 3007 actual strength of the resulting keys depends, among other things, on 3008 some operator specific parameters including authentication 3009 algorithms, the strength of the Ki key, and the quality of the RAND 3010 challenges. For example, some SIM cards generate Kc keys with 10 bits 3011 set to zero. Such restrictions may prevent the concatenation 3012 technique from yielding strong session keys. Because the strength of 3013 the Ki key is 128 bits, the ultimate strength of any derived secret 3014 key material is never more than 128 bits. 3016 It should also be noted that a security policy that allows n=2 to be 3017 used may compromise the security of a future policy that requires 3018 three triplets, because adversaries may be able to exploit the 3019 messages exchanged when the weaker policy was applied. 3021 There is no known way to obtain complete GSM triplets by mounting an 3022 attack against EAP-SIM. A passive eavesdropper can learn n*RAND and 3023 AT_MAC and may be able to link this information to the subscriber 3024 identity. An active attacker that impersonates a GSM subscriber can 3025 easily obtain n*RAND and AT_MAC values from the EAP server for any 3026 given subscriber identity. However, calculating the Kc and SRES 3027 values from AT_MAC would require the attacker to reverse the keyed 3028 message authentication code function HMAC-SHA1-128. 3030 As EAP-SIM does not expose any values calculated from an individual 3031 GSM Kc keys, it is not possible to mount a brute force attack on just 3032 one of the Kc keys in EAP-SIM. Therefore, when considering brute 3033 force attacks on the values exposed in EAP-SIM, the effective length 3034 of EAP-SIM session keys is not compromised by the fact that they are 3035 combined from several shorter keys, i.e the effective length of 128 3036 bits may be achieved. For additional considerations see Section 9.6. 3037 The EAP Transient Keys used to protect EAP-SIM packets (K_encr, 3038 K_aut) and the Master Session Key are cryptographically separate. An 3039 attacker cannot derive any non-trivial information from K_encr or 3040 K_aut based on the Master Session Key or vice versa. An attacker also 3041 cannot calculate the pre-shared secret from the GSM Kc keys used, 3042 EAP-SIM K_encr, EAP-SIM K_aut, or from the Master Session Key. 3044 Each EAP-SIM exchange generates fresh keying material. The EAP-SIM 3045 peer contributes to the keying material with the NONCE_MT parameter, 3046 which must be chosen freshly for each full authentication exchange. 3048 Hence, even if the RAND challenges were reused from a previous 3049 session, the session keys will be different. On fast 3050 re-authentication, freshness is provided with a counter. Please see 3051 Section 9.2 for more information about RAND reuse. 3053 9.5 Dictionary Attacks 3055 Because EAP-SIM is not a password protocol, it is not vulnerable to 3056 dictionary attacks. (The pre-shared symmetric secret stored on the 3057 SIM card shall not be a weak password.) 3059 9.6 Credentials Reuse 3061 EAP-SIM cannot prevent attacks over the GSM or GPRS radio networks. 3062 If the same SIM credentials are also used in GSM or GPRS, it is 3063 possible to mount attacks over the cellular interface. 3065 A passive attacker can eavesdrop GSM or GPRS traffic and obtain RAND, 3066 SRES pairs. He can then use a brute force attack or other 3067 cryptanalysis techniques to obtain the 64-bit Kc keys used to encrypt 3068 the GSM or GPRS data. This makes it possible to attack each 64-bit 3069 key separately. 3071 An active attacker can mount a "rogue GSM/GPRS base station attack", 3072 replaying previously seen RAND challenges to obtain SRES values. He 3073 can then use a brute force attack to obtain the Kc keys. If 3074 successful, the attacker can impersonate a valid network or decrypt 3075 previously seen traffic, because EAP-SIM does not provide perfect 3076 forward secrecy (PFS). 3078 Because this attack requires the attacker to build a rogue GSM base 3079 station (or at least eavesdrop the GSM traffic), the cost of the 3080 attack is not negligible; it is the same cost as usually in GSM. 3081 However, due to several weaknesses in the GSM encryption algorithms, 3082 the effective key strength of the Kc keys is much less than the 3083 expected 64 bits (no more than 40 bits if the A5/1 GSM encryption 3084 algorithm is used; an active attacker can force the peer to use the 3085 weaker A5/2 algorithm that can be broken in less than a second). 3087 Because the A5 encryption algorithm is not used in EAP-SIM, and 3088 because EAP-SIM does not expose any values calculated from individual 3089 Kc keys, it should be noted that these attacks are not possible if 3090 the SIM credentials used in EAP-SIM are not shared in GSM/GPRS. 3092 9.7 Integrity and Replay Protection, and Confidentiality 3094 AT_MAC, AT_IV, AT_ENCR_DATA and AT_COUNTER attributes are used to 3095 provide integrity, replay and confidentiality protection for EAP-SIM 3096 requests and responses. Integrity protection with AT_MAC includes the 3097 EAP header. These attributes cannot be used during the EAP/SIM/Start 3098 roundtrip. However, the protocol values (user identity string, 3099 NONCE_MT and version negotiation parameters) are (implicitly) 3100 protected by later EAP-SIM messages by including them in key 3101 derivation. 3103 Integrity protection (AT_MAC) is based on a keyed message 3104 authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is 3105 based on a block cipher. 3107 Confidentiality protection is applied only to a part of the protocol 3108 fields. The table of attributes in Section 7.1 summarizes which 3109 fields are confidentiality protected. It should be noted that the 3110 error and notification code attributes AT_CLIENT_ERROR_CODE and 3111 AT_NOTIFICATION are not confidential but they are transmitted in the 3112 clear. Identity protection is discussed in Section 9.1. 3114 On full authentication, replay protection of the EAP exchange is 3115 provided by the RAND values from the underlying GSM authentication 3116 scheme and the use of the NONCE_MT value. Protection against replays 3117 of EAP-SIM messages is also based on the fact that messages that can 3118 include AT_MAC can only be sent once with a certain EAP-SIM Subtype, 3119 and on the fact that a different K_aut key will be used for 3120 calculating AT_MAC in each full authentication exchange. 3122 On fast re-authentication, a counter included in AT_COUNTER and a 3123 server random nonce is used to provide replay protection. The 3124 AT_COUNTER attribute is also included in EAP-SIM notifications, if 3125 they are used after successful authentication in order to provide 3126 replay protection between re-authentication exchanges. 3128 Because EAP-SIM is not a tunneling method, EAP-Request/Notification, 3129 EAP-Response/Notification, EAP-Success or EAP-Failure packets are not 3130 confidential, integrity protected or replay protected in EAP-SIM. On 3131 physically insecure networks, this may enable an attacker to send 3132 false notifications to the peer and to mount denial of service 3133 attacks by spoofing these packets. As discussed in Section 4.5, the 3134 peer will only accept EAP-Success after successful authentication. 3135 Hence, the attacker cannot force the peer to believe successful 3136 authentication has occurred when mutual authentication failed or has 3137 not happened yet. 3139 The security considerations of EAP-SIM result indications are covered 3140 in Section 9.9 3142 An eavesdropper will see the EAP-Request/Notification, EAP-Response/ 3143 Notification, EAP-Success and EAP-Failure packets sent in the clear. 3145 With EAP-SIM, confidential information MUST NOT be transmitted in EAP 3146 Notification packets. 3148 9.8 Negotiation Attacks 3150 EAP-SIM does not protect the EAP-Response/Nak packet. Because EAP-SIM 3151 does not protect the EAP method negotiation, EAP method downgrading 3152 attacks may be possible, especially if the user uses the same 3153 identity with EAP-SIM and other EAP methods. 3155 EAP-SIM includes a version negotiation procedure. In EAP-SIM the 3156 keying material derivation includes the version list and selected 3157 version to ensure that the protocol cannot be downgraded and that the 3158 peer and server use the same version of EAP-SIM. 3160 EAP-SIM does not support ciphersuite negotiation. 3162 9.9 Protected Result Indications 3164 EAP-SIM supports optional protected success indications, and 3165 acknowledged failure indications. If a failure occurs after 3166 successful authentication, then the EAP-SIM failure indication is 3167 integrity and replay protected. 3169 Even if an EAP-Failure packet is lost when using EAP-SIM over an 3170 unreliable medium, then the EAP-SIM failure indications will help 3171 ensure that the peer and EAP server will know the other parties 3172 authentication decision. If protected success indications are used, 3173 then the loss of Success packet will also be addressed by the 3174 acknowledged, integrity and replay protected EAP-SIM success 3175 indication. If the optional success indications are not used, then 3176 the peer may end up believing the server succeeded authentication 3177 when it actually failed. Since access will not be granted in this 3178 case protected result indications are not needed unless the client is 3179 not able to realize it does not have access for an extended period of 3180 time. 3182 9.10 Man-in-the-middle Attacks 3184 In order to avoid man-in-the-middle attacks and session hijacking, 3185 user data SHOULD be integrity protected on physically insecure 3186 networks. The EAP-SIM Master Session Key or keys derived from it MAY 3187 be used as the integrity protection keys, or, if an external security 3188 mechanism such as PEAP is used, then the link integrity protection 3189 keys MAY be derived by the external security mechanism. 3191 There are man-in-the-middle attacks associated with the use of any 3192 EAP method within a tunneled protocol such as PEAP, or within a 3193 sequence of EAP methods followed by each other. This specification 3194 does not address these attacks. If EAP-SIM is used with a tunneling 3195 protocol or as part of a sequence of methods, there should be 3196 cryptographic binding provided between the protocols and EAP-SIM to 3197 prevent man-in-the-middle attacks through rogue authenticators being 3198 able to setup one-way authenticated tunnels. The EAP-SIM Master 3199 Session Key MAY be used to provide the cryptographic binding. However 3200 the mechanism how the binding is provided depends on the tunneling or 3201 sequencing protocol and is beyond the scope of this document. 3203 9.11 Generating Random Numbers 3205 An EAP-SIM implementation SHOULD use a good source of randomness to 3206 generate the random numbers required in the protocol. Please see 3207 [RFC1750] for more information on generating random numbers for 3208 security applications. 3210 10. Security Claims 3212 This section provides the security claims required by [EAP]. 3214 Auth. mechanism: EAP-SIM is based on the GSM SIM mechanism, which is 3215 a challenge/response authentication and key agreement mechanism based 3216 on a symmetric 128-bit pre-shared secret. EAP-SIM also makes use of a 3217 peer challenge to provide mutual authentication. 3219 Ciphersuite negotiation: No 3221 Mutual authentication: Yes (Section 9.2) 3223 Integrity protection: Yes (Section 9.7) 3225 Replay protection: Yes (Section 9.7) 3227 Confidentiality: Yes, except method specific success and failure 3228 indications (Section 9.1, Section 9.7) 3230 Key derivation: Yes 3232 Key strength: EAP-SIM supports key derivation with 128-bit effective 3233 key strength. However, as discussed in Section 9, if the same 3234 credentials are used in GSM/GPRS and in EAP-SIM, then the key 3235 strength may be reduced considerably, basically to the same level as 3236 in GSM, by mounting attacks over GSM/GPRS. For example an active 3237 attack using a false GSM/GPRS base station reduces the effective key 3238 strength to almost zero. 3240 Description of key hierarchy: Please see Section 4.6. 3242 Dictinary attack protection: N/A (Section 9.5) 3244 Fast reconnect: Yes 3246 Cryptographic binding: N/A 3248 Session independence: Yes (Section 9.4, Section 9.2) 3250 Fragmentation: No 3252 Channel binding: No 3254 Indication of vulnerabilities: Vulnerabilities are discussed in 3255 Section 9. 3257 11. Acknowledgements and Contributions 3259 11.1 Contributors 3261 In addition to the editors, Nora Dabbous, Jose Puthenkulam, and 3262 Prasanna Satarasinghe were significant contributors to this document. 3264 Pasi Eronen and Jukka-Pekka Honkanen contributed Appendix A. 3266 11.2 Acknowledgements 3268 Juha Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt, Jukka- 3269 Pekka Honkanen, Antti Kuikka, Jukka Latva, Lassi Lehtinen, Jyri 3270 Rinnemaa, Timo Takam�ki and Raimo Vuonnala contributed many original 3271 ideas and concepts to this protocol. 3273 N. Asokan, Pasi Eronen and Jukka-Pekka Honkanen contributed and 3274 helped in innumerable ways during the development of the protocol. 3276 Valtteri Niemi and Kaisa Nyberg contributed substantially to the 3277 design of the key derivation and the fast re-authentication 3278 procedure, and have also provided their cryptographic expertise in 3279 many discussions related to this protocol. 3281 Simon Blake-Wilson provided most helpful comments on key derivation 3282 and version negotiation. 3284 Thanks to Greg Rose for his most valuable comments to an early 3285 version of this specification [S3-020125], and for reviewing and 3286 providing very useful comments on draft version 12. 3288 Thanks to Bernard Aboba, Vladimir Alperovich, Florent Bersani, 3289 Jacques Caron, Gopal Dommety, Augustin Farrugia, Mark Grayson, Max de 3290 Groot, Prakash Iyer, Nishi Kant, Victor Lortz, Sarvar Patel, Tom 3291 Porcher, Michael Richardson, Stefan Schr�der, Jesse Walker and Thomas 3292 Wieland for their contributions and critiques. Special thanks to Max 3293 for proposing improvements to the MAC calculation. 3295 Thanks to Glen Zorn for reviewing this document and for providing 3296 most useful comments on the protocol. 3298 The identity privacy support is based on the identity privacy support 3299 of [EAP-SRP]. The attribute format is based on the extension format 3300 of Mobile IPv4 [RFC3344]. 3302 This protocol has been partly developed in parallel with EAP-AKA 3303 [EAP-AKA], and hence this specification incorporates many ideas from 3304 Jari Arkko. 3306 11.2.1 Contributors' Addresses 3308 Nora Dabbous 3309 Gemplus 3310 34 rue Guynemer 3311 92447 Issy les Moulineaux 3312 France 3313 EMail: nora.dabbous@gemplus.com 3314 Phone: +33 1 4648 2000 3316 Jose Puthenkulam 3317 Intel Corporation 3318 2111 NE 25th Avenue, JF2-58 3319 Hillsboro, OR 97124 3320 USA 3321 EMail: jose.p.puthenkulam@intel.com 3322 Phone: +1 503 264 6121 3324 Prasanna Satarasinghe 3325 Transat Technologies 3326 180 State Street, Suite 240 3327 Southlake, TX 76092 3328 USA 3329 EMail: prasannas@transat-tech.com 3330 Phone: + 1 817 4814412 3332 Normative References 3334 [GSM 03.20] 3335 European Telecommunications Standards Institute, "GSM 3336 Technical Specification GSM 03.20 (ETS 300 534): "Digital 3337 cellular telecommunication system (Phase 2); Security 3338 related network functions"", August 1997. 3340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3341 Requirement Levels", BCP 14, RFC 2119, March 1997. 3343 [GSM 03.03] 3344 European Telecommunications Standards Institute, "GSM 3345 Technical Specification GSM 03.03 (ETS 300 523): "Digital 3346 cellular telecommunication system (Phase 2); Numbering, 3347 addressing and identification"", April 1997. 3349 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 3350 RFC 2486, January 1999. 3352 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 3353 Keyed-Hashing for Message Authentication", RFC 2104, 3354 February 1997. 3356 [AES] National Institute of Standards and Technology, "Federal 3357 Information Processing Standards (FIPS) Publication 197, 3358 "Advanced Encryption Standard (AES)"", November 2001. 3360 http://csrc.nist.gov/publications/fips/fips197/ 3361 fips-197.pdf 3363 [CBC] National Institute of Standards and Technology, "NIST 3364 Special Publication 800-38A, "Recommendation for Block 3365 Cipher Modes of Operation - Methods and Techniques"", 3366 December 2001. 3368 http://csrc.nist.gov/publications/nistpubs/800-38a/ 3369 sp800-38a.pdf 3371 [SHA-1] National Institute of Standards and Technology, U.S. 3372 Department of Commerce, "Federal Information Processing 3373 Standard (FIPS) Publication 180-1, "Secure Hash 3374 Standard"", April 1995. 3376 [PRF] National Institute of Standards and Technology, "Federal 3377 Information Processing Standards (FIPS) Publication 186-2 3378 (with change notice); Digital Signature Standard (DSS)", 3379 January 2000. 3381 Available on-line at: http://csrc.nist.gov/publications/ 3382 fips/fips186-2/fips186-2-change1.pdf 3384 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3385 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3386 October 1998. 3388 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 3389 10646", RFC 2279, January 1998. 3391 [EAP] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. 3392 Levkowetz, "Extensible Authentication Protocol (EAP)", 3393 draft-ietf-eap-rfc2284bis-09 (work in progress), February 3394 2004. 3396 Informative References 3398 [Draft 3GPP TS 23.003] 3399 3rd Generation Partnership Project, "Draft 3GPP Technical 3400 Specification 3GPP TS 23.003 V 6.1.0: "3rd Generation 3401 Partnership Project; Technical Specification Group Core 3402 Network; Numbering, addressing and identification (Release 3403 6)"", December 2003. 3405 work in progress 3407 [PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H. 3408 and S. Josefsson, "Protected EAP Protocol (PEAP)", 3409 draft-josefsson-pppext-eap-tls-eap-07 (work in progress), 3410 October 2003. 3412 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 3413 Recommendations for Security", RFC 1750, December 1994. 3415 [S3-020125] 3416 Qualcomm, "Comments on draft EAP/SIM, 3rd Generation 3417 Partnership Project document 3GPP TSG SA WG3 Security 3418 S3#22, S3-020125", February 2002. 3420 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 3421 August 2002. 3423 [EAP-AKA] Arkko, J. and H. Haverinen, "EAP-AKA Authentication", 3424 draft-arkko-pppext-eap-aka-12 (work in progress), Arpil 3425 2004. 3427 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 3428 RFC 2548, March 1999. 3430 [EAP-SRP] Carlson, J., Aboba, B. and H. Haverinen, "EAP SRP-SHA1 3431 Authentication Protocol", Internet-Draft 3432 draft-ietf-pppext-eap-srp-03, July 2001. 3434 Authors' Addresses 3436 Henry Haverinen (editor) 3437 Nokia Enterprise Solutions 3438 P.O. Box 12 3439 FIN-40101 Jyvaskyla 3440 Finland 3442 EMail: henry.haverinen@nokia.com 3444 Joseph Salowey (editor) 3445 Cisco Systems 3446 2901 Third Avenue 3447 Seattle, WA 98121 3448 USA 3450 Phone: +1 206 256 3380 3451 EMail: jsalowey@cisco.com 3453 Appendix A. Test Vectors 3455 Test vectors for the NIST FIPS 186-2 pseudo-random number generator 3456 [PRF] are available at the following URL: http://csrc.nist.gov/ 3457 encryption/dss/Examples-1024bit.pdf 3459 The following examples show the contents of EAP-SIM packets on full 3460 authentication and fast re-authentication. 3462 A.1 EAP-Request/Identity 3464 The first packet is a plain Identity Request: 3466 01 ; Code: Request 3467 00 ; Identifier: 0 3468 00 05 ; Length: 5 octets 3469 01 ; Type: Identity 3471 A.2 EAP-Response/Identity 3473 The client's identity is "1244070100000001@eapsim.foo", so it 3474 responds with the following packet: 3476 02 ; Code: Response 3477 00 ; Identifier: 0 3478 00 20 ; Length: 32 octets 3479 01 ; Type: Identity 3480 31 32 34 34 ; "1244070100000001@eapsim.foo" 3481 30 37 30 31 3482 30 30 30 30 3483 30 30 30 31 3484 40 65 61 70 3485 73 69 6d 2e 3486 66 6f 6f 3488 A.3 EAP-Request/SIM/Start 3490 The server's first packet looks like this: 3492 01 ; Code: Request 3493 01 ; Identifier: 1 3494 00 10 ; Length: 16 octets 3495 12 ; Type: EAP-SIM 3496 0a ; EAP-SIM subtype: Start 3497 00 00 ; (reserved) 3498 0f ; Attribute type: AT_VERSION_LIST 3499 02 ; Attribute length: 8 octets (2*4) 3500 00 02 ; Actual version list length: 2 octets 3501 00 01 ; Version: 1 3502 00 00 ; (attribute padding) 3504 A.4 EAP-Response/SIM/Start 3506 The client selects a nonce and responds with the following packet: 3508 02 ; Code: Response 3509 01 ; Identifier: 1 3510 00 20 ; Length: 32 octets 3511 12 ; Type: EAP-SIM 3512 0a ; EAP-SIM subtype: Start 3513 00 00 ; (reserved) 3514 07 ; Attribute type: AT_NONCE_MT 3515 05 ; Attribute length: 20 octets (5*4) 3516 00 00 ; (reserved) 3517 01 23 45 67 ; NONCE_MT value 3518 89 ab cd ef 3519 fe dc ba 98 3520 76 54 32 10 3521 10 ; Attribute type: AT_SELECTED_VERSION 3522 01 ; Attribute length: 4 octets (1*4) 3523 00 01 ; Version: 1 3525 A.5 EAP-Request/SIM/Challenge 3527 Next, the server selects three authentication triplets 3529 (RAND1,SRES1,Kc1) = (10111213 14151617 18191a1b 1c1d1e1f, 3530 d1d2d3d4, 3531 a0a1a2a3 a4a5a6a7) 3532 (RAND2,SRES2,Kc2) = (20212223 24252627 28292a2b 2c2d2e2f, 3533 e1e2e3e4, 3534 b0b1b2b3 b4b5b6b7) 3535 (RAND3,SRES3,Kc3) = (30313233 34353637 38393a3b 3c3d3e3f, 3536 f1f2f3f4, 3537 c0c1c2c3 c4c5c6c7) 3539 Next, the MK is calculated as specified in Section 4.6. 3541 MK = e576d5ca 332e9930 018bf1ba ee2763c7 95b3c712 3543 And the other keys are derived using the PRNG: 3545 K_encr = 536e5ebc 4465582a a6a8ec99 86ebb620 3546 K_aut = 25af1942 efcbf4bc 72b39434 21f2a974 3547 MSK = 39d45aea f4e30601 983e972b 6cfd46d1 3548 c3637733 65690d09 cd44976b 525f47d3 3549 a60a985e 955c53b0 90b2e4b7 3719196a 3550 40254296 8fd14a88 8f46b9a7 886e4488 3551 EMSK = 5949eab0 fff69d52 315c6c63 4fd14a7f 3552 0d52023d 56f79698 fa6596ab eed4f93f 3553 bb48eb53 4d985414 ceed0d9a 8ed33c38 3554 7c9dfdab 92ffbdf2 40fcecf6 5a2c93b9 3556 Next, the server selects a pseudonym and a fast re-authentication 3557 identity (in this case, "w8w49PexCazWJ&xCIARmxuMKht5S1sxR 3558 DqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G" and 3559 "Y24fNSrz8BP274jOJaF17WfxI8YO7QX0 3560 0pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo", respectively). 3562 The following plaintext will be encrypted and stored in the 3563 AT_ENCR_DATA attribute: 3565 84 ; Attribute type: AT_NEXT_PSEUDONYM 3566 13 ; Attribute length: 76 octets (19*4) 3567 00 46 ; Actual pseudonym length: 70 octets 3568 77 38 77 34 39 50 65 78 43 61 7a 57 4a 26 78 43 3569 49 41 52 6d 78 75 4d 4b 68 74 35 53 31 73 78 52 3570 44 71 58 53 45 46 42 45 67 33 44 63 5a 50 39 63 3571 49 78 54 65 35 4a 34 4f 79 49 77 4e 47 56 7a 78 3572 65 4a 4f 55 31 47 3573 00 00 ; (attribute padding) 3574 85 ; Attribute type: AT_NEXT_REAUTH_ID 3575 16 ; Attribute length: 88 octets (22*4) 3576 00 51 ; Actual re-auth identity length: 81 octets 3577 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f 3578 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30 3579 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f 3580 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b 3581 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f 3582 6f 3583 00 00 00 ; (attribute padding) 3584 06 ; Attribute type: AT_PADDING 3585 03 ; Attribute length: 12 octets (3*4) 3586 00 00 00 00 3587 00 00 00 00 3588 00 00 3590 The EAP packet looks like this: 3592 01 ; Code: Request 3593 02 ; Identifier: 2 3594 01 18 ; Length: 280 octets 3595 12 ; Type: EAP-SIM 3596 0b ; EAP-SIM subtype: Challenge 3597 00 00 ; (reserved) 3598 01 ; Attribute type: AT_RAND 3599 0d ; Attribute length: 52 octets (13*4) 3600 00 00 ; (reserved) 3601 10 11 12 13 ; first RAND 3602 14 15 16 17 3603 18 19 1a 1b 3604 1c 1d 1e 1f 3605 20 21 22 23 ; second RAND 3606 24 25 26 27 3607 28 29 2a 2b 3608 2c 2d 2e 2f 3609 30 31 32 33 ; third RAND 3610 34 35 36 37 3611 38 39 3a 3b 3612 3c 3d 3e 3f 3614 81 ; Attribute type: AT_IV 3615 05 ; Attribute length: 20 octets (5*4) 3616 00 00 ; (reserved) 3617 9e 18 b0 c2 ; IV value 3618 9a 65 22 63 3619 c0 6e fb 54 3620 dd 00 a8 95 3621 82 ; Attribute type: AT_ENCR_DATA 3622 2d ; Attribute length: 180 octets (45*4) 3623 00 00 ; (reserved) 3624 55 f2 93 9b bd b1 b1 9e a1 b4 7f c0 b3 e0 be 4c 3625 ab 2c f7 37 2d 98 e3 02 3c 6b b9 24 15 72 3d 58 3626 ba d6 6c e0 84 e1 01 b6 0f 53 58 35 4b d4 21 82 3627 78 ae a7 bf 2c ba ce 33 10 6a ed dc 62 5b 0c 1d 3628 5a a6 7a 41 73 9a e5 b5 79 50 97 3f c7 ff 83 01 3629 07 3c 6f 95 31 50 fc 30 3e a1 52 d1 e1 0a 2d 1f 3630 4f 52 26 da a1 ee 90 05 47 22 52 bd b3 b7 1d 6f 3631 0c 3a 34 90 31 6c 46 92 98 71 bd 45 cd fd bc a6 3632 11 2f 07 f8 be 71 79 90 d2 5f 6d d7 f2 b7 b3 20 3633 bf 4d 5a 99 2e 88 03 31 d7 29 94 5a ec 75 ae 5d 3634 43 c8 ed a5 fe 62 33 fc ac 49 4e e6 7a 0d 50 4d 3635 0b ; Attribute type: AT_MAC 3636 05 ; Attribute length: 20 octets (5*4) 3637 00 00 ; (reserved) 3638 fe f3 24 ac ; MAC value 3639 39 62 b5 9f 3640 3b d7 82 53 3641 ae 4d cb 6a 3643 The MAC is calculated over the EAP packet above (with MAC value set 3644 to zero), followed by the NONCE_MT value (a total of 296 bytes). 3646 A.6 EAP-Response/SIM/Challenge 3648 The client's response looks like this: 3650 02 ; Code: Response 3651 02 ; Identifier: 2 3652 00 1c ; Length: 28 octets 3653 12 ; Type: EAP-SIM 3654 0b ; EAP-SIM subtype: Challenge 3655 00 00 ; (reserved) 3656 0b ; Attribute type: AT_MAC 3657 05 ; Attribute length: 20 octets (5*4) 3658 00 00 ; (reserved) 3659 f5 6d 64 33 ; MAC value 3660 e6 8e d2 97 3661 6a c1 19 37 3662 fc 3d 11 54 3664 The MAC is calculated over the EAP packet above (with MAC value set 3665 to zero), followed by the SRES values (a total of 40 bytes). 3667 A.7 EAP-Success 3669 The last packet is an EAP-Success: 3671 03 ; Code: Success 3672 02 ; Identifier: 2 3673 00 04 ; Length: 4 octets 3675 A.8 Fast Re-authentication 3677 When performing fast re-authentication, the EAP-Request/Identity 3678 packet is the same as usual. The EAP-Response/Identity contains the 3679 fast re-authentication identity (from AT_ENCR_DATA attribute above): 3681 02 ; Code: Response 3682 00 ; Identifier: 0 3683 00 56 ; Length: 86 octets 3684 01 ; Type: Identity 3685 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f 3686 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30 3687 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f 3688 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b 3689 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f 3690 6f 3692 A.9 EAP-Request/SIM/Re-authentication 3694 The server recognizes the reauthentication identity, so it will 3695 respond with EAP-Request/SIM/Re-authentication. It retrieves the 3696 associated counter value, generates a nonce, and picks a new 3697 reauthentication identity (in this case, 3698 "uta0M0iyIsMwWp5TTdSdnOLvg2XDVf21OYt1vnfiMcs5dnIDHOIFVavIRzMR 3699 yzW6vFzdHW@eapsim.foo"). 3701 The following plaintext will be encrypted and stored in the 3702 AT_ENCR_DATA attribute. Note that AT_PADDING is not used because the 3703 length of the plaintext is a multiple of 16 bytes. 3705 13 ; Attribute type: AT_COUNTER 3706 01 ; Attribute length: 4 octets (1*4) 3707 00 01 ; Counter value 3708 15 ; Attribute type: AT_NONCE_S 3709 05 ; Attribute length: 20 octets (5*4) 3710 00 00 ; (reserved) 3711 01 23 45 67 ; NONCE_S value 3712 89 ab cd ef 3713 fe dc ba 98 3714 76 54 32 10 3715 85 ; Attribute type: AT_NEXT_REAUTH_ID 3716 16 ; Attribute length: 88 octets (22*4) 3717 00 51 ; Actual re-auth identity length: 81 octets 3718 75 74 61 30 4d 30 69 79 49 73 4d 77 57 70 35 54 3719 54 64 53 64 6e 4f 4c 76 67 32 58 44 56 66 32 31 3720 4f 59 74 31 76 6e 66 69 4d 63 73 35 64 6e 49 44 3721 48 4f 49 46 56 61 76 49 52 7a 4d 52 79 7a 57 36 3722 76 46 7a 64 48 57 40 65 61 70 73 69 6d 2e 66 6f 3723 6f 3724 00 00 00 ; (attribute padding) 3726 The EAP packet looks like this: 3728 01 ; Code: Request 3729 01 ; Identifier: 1 3730 00 a4 ; Length: 164 octets 3731 12 ; Type: EAP-SIM 3732 0d ; EAP-SIM subtype: Re-authentication 3733 00 00 ; (reserved) 3734 81 ; Attribute type: AT_IV 3735 05 ; Attribute length: 20 octets (5*4) 3736 00 00 ; (reserved) 3737 d5 85 ac 77 ; IV value 3738 86 b9 03 36 3739 65 7c 77 b4 3740 65 75 b9 c4 3741 82 ; Attribute type: AT_ENCR_DATA 3742 1d ; Attribute length: 116 octets (29*4) 3743 00 00 ; (reserved) 3744 68 62 91 a9 d2 ab c5 8c aa 32 94 b6 e8 5b 44 84 3745 6c 44 e5 dc b2 de 8b 9e 80 d6 9d 49 85 8a 5d b8 3746 4c dc 1c 9b c9 5c 01 b9 6b 6e ca 31 34 74 ae a6 3747 d3 14 16 e1 9d aa 9d f7 0f 05 00 88 41 ca 80 14 3748 96 4d 3b 30 a4 9b cf 43 e4 d3 f1 8e 86 29 5a 4a 3749 2b 38 d9 6c 97 05 c2 bb b0 5c 4a ac e9 7d 5e af 3750 f5 64 04 6c 8b d3 0b c3 9b e5 e1 7a ce 2b 10 a6 3751 0b ; Attribute type: AT_MAC 3752 05 ; Attribute length: 20 octets (5*4) 3753 00 00 ; (reserved) 3754 48 3a 17 99 ; MAC value 3755 b8 3d 7c d3 3756 d0 a1 e4 01 3757 d9 ee 47 70 3759 The MAC is calculated over the EAP packet above (with MAC value set 3760 to zero; a total of 164 bytes). 3762 Finally, the server derives new keys. The XKEY' is calculated as 3763 described in Section 4.6: 3765 XKEY' = 863dc120 32e08343 c1a2308d b48377f6 801f58d4 3767 The new MSK and EMSK are derived using the PRNG (note that K_encr and 3768 K_aut stay the same). 3770 MSK = 6263f614 973895e1 335f7e30 cff028ee 3771 2176f519 002c9abe 732fe0ef 00cf167c 3772 756d9e4c ed6d5ed6 40eb3fe3 8565ca07 3773 6e7fb8a8 17cfe8d9 adbce441 d47c4f5e 3774 EMSK = 3d8ff786 3a630b2b 06e2cf20 9684c13f 3775 6b82f992 f2b06f1b 54bf51ef 237f2a40 3776 1ef5e0d7 e098a34c 533eaebf 34578854 3777 b7721526 20a777f0 e0340884 a294fb73 3779 A.10 EAP-Response/SIM/Re-authentication 3781 The client's response includes the counter as well. The following 3782 plaintext will be encrypted and stored in the AT_ENCR_DATA attribute: 3784 13 ; Attribute type: AT_COUNTER 3785 01 ; Attribute length: 4 octets (1*4) 3786 00 01 ; Counter value 3787 06 ; Attribute type: AT_PADDING 3788 03 ; Attribute length: 12 octets (3*4) 3789 00 00 00 00 3790 00 00 00 00 3791 00 00 3793 The EAP packet looks like this: 3795 02 ; Code: Response 3796 01 ; Identifier: 1 3797 00 44 ; Length: 68 octets 3798 12 ; Type: EAP-SIM 3799 0d ; EAP-SIM subtype: Re-authentication 3800 00 00 ; (reserved) 3801 81 ; Attribute type: AT_IV 3802 05 ; Attribute length: 20 octets (5*4) 3803 00 00 ; (reserved) 3804 cd f7 ff a6 ; IV value 3805 5d e0 4c 02 3806 6b 56 c8 6b 3807 76 b1 02 ea 3808 82 ; Attribute type: AT_ENCR_DATA 3809 05 ; Attribute length: 20 octets (5*4) 3810 00 00 ; (reserved) 3811 b6 ed d3 82 3812 79 e2 a1 42 3813 3c 1a fc 5c 3814 45 5c 7d 56 3815 0b ; Attribute type: AT_MAC 3816 05 ; Attribute length: 20 octets (5*4) 3817 00 00 ; (reserved) 3818 fa f7 6b 71 ; MAC value 3819 fb e2 d2 55 3820 b9 6a 35 66 3821 c9 15 c6 17 3823 The MAC is calculated over the EAP packet above (with MAC value set 3824 to zero), followed by the NONCE_S value (a total of 84 bytes). 3826 The next packet will be EAP-Success: 3828 03 ; Code: Success 3829 01 ; Identifier: 1 3830 00 04 ; Length: 4 octets 3832 Appendix B. Pseudo-Random Number Generator 3834 The "|" character denotes concatenation, and "^" denotes 3835 exponentiation. 3837 Step 1: Choose a new, secret value for the seed-key, XKEY 3839 Step 2: In hexadecimal notation let 3840 t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 3841 This is the initial value for H0|H1|H2|H3|H4 3842 in the FIPS SHS 3844 Step 3: For j = 0 to m - 1 do 3845 3.1 XSEED_j = 0 /* no optional user input */ 3846 3.2 For i = 0 to 1 do 3847 a. XVAL = (XKEY + XSEED_j) mod 2^b 3848 b. w_i = G(t, XVAL) 3849 c. XKEY = (1 + XKEY + w_i) mod 2^b 3850 3.3 x_j = w_0|w_1 3852 Intellectual Property Statement 3854 The IETF takes no position regarding the validity or scope of any 3855 intellectual property or other rights that might be claimed to 3856 pertain to the implementation or use of the technology described in 3857 this document or the extent to which any license under such rights 3858 might or might not be available; neither does it represent that it 3859 has made any effort to identify any such rights. Information on the 3860 IETF's procedures with respect to rights in standards-track and 3861 standards-related documentation can be found in BCP-11. Copies of 3862 claims of rights made available for publication and any assurances of 3863 licenses to be made available, or the result of an attempt made to 3864 obtain a general license or permission for the use of such 3865 proprietary rights by implementors or users of this specification can 3866 be obtained from the IETF Secretariat. 3868 The IETF invites any interested party to bring to its attention any 3869 copyrights, patents or patent applications, or other proprietary 3870 rights which may cover technology that may be required to practice 3871 this standard. Please address the information to the IETF Executive 3872 Director. 3874 The IETF has been notified of intellectual property rights claimed in 3875 regard to some or all of the specification contained in this 3876 document. For more information consult the online list of claimed 3877 rights. 3879 Full Copyright Statement 3881 Copyright (C) The Internet Society (2004). All Rights Reserved. 3883 This document and translations of it may be copied and furnished to 3884 others, and derivative works that comment on or otherwise explain it 3885 or assist in its implementation may be prepared, copied, published 3886 and distributed, in whole or in part, without restriction of any 3887 kind, provided that the above copyright notice and this paragraph are 3888 included on all such copies and derivative works. However, this 3889 document itself may not be modified in any way, such as by removing 3890 the copyright notice or references to the Internet Society or other 3891 Internet organizations, except as needed for the purpose of 3892 developing Internet standards in which case the procedures for 3893 copyrights defined in the Internet Standards process must be 3894 followed, or as required to translate it into languages other than 3895 English. 3897 The limited permissions granted above are perpetual and will not be 3898 revoked by the Internet Society or its successors or assignees. 3900 This document and the information contained herein is provided on an 3901 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3902 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3903 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3904 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3905 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3907 Acknowledgment 3909 Funding for the RFC Editor function is currently provided by the 3910 Internet Society.