idnits 2.17.1 draft-haverinen-pppext-eap-sim-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4093. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4078. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 21, 2004) is 7066 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) == Unused Reference: 'RFC2434' is defined on line 3542, but no explicit reference was found in the text ** 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 (-16) exists of draft-arkko-pppext-eap-aka-14 ** Downref: Normative reference to an Informational draft: draft-arkko-pppext-eap-aka (ref. 'EAP-AKA') == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-09 -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 14 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: June 21, 2005 J. Salowey, Ed. 4 Cisco Systems 5 December 21, 2004 7 Extensible Authentication Protocol Method for GSM Subscriber Identity 8 Modules (EAP-SIM) 9 draft-haverinen-pppext-eap-sim-16.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 21, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 IESG Note 44 The EAP-SIM protocol was developed by 3GPP. The documentation of 45 EAP-SIM is provided as information to the Internet community. While 46 the EAP WG has verified that EAP-SIM is compatible with EAP as 47 defined in RFC 3748, no other review has been done, including 48 validation of the security claims. 50 Abstract 52 This document specifies an Extensible Authentication Protocol (EAP) 53 mechanism for authentication and session key distribution using the 54 Global System for Mobile Communications (GSM) Subscriber Identity 55 Module (SIM). GSM is a second generation mobile network standard. 56 The EAP-SIM mechanism specifies enhancements to GSM authentication 57 and key agreement whereby multiple authentication triplets can be 58 combined to create authentication responses and session keys of 59 greater strength than the individual GSM triplets. The mechanism 60 also includes network authentication, user anonymity support, result 61 indications, and a fast re-authentication procedure. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.1 Version Negotiation . . . . . . . . . . . . . . . . . . . 11 70 4.2 Identity Management . . . . . . . . . . . . . . . . . . . 12 71 4.2.1 Format, Generation and Usage of Peer Identities . . . 12 72 4.2.2 Communicating the Peer Identity to the Server . . . . 18 73 4.2.3 Choice of Identity for the EAP-Response/Identity . . . 19 74 4.2.4 Server Operation in the Beginning of EAP-SIM 75 Exchange . . . . . . . . . . . . . . . . . . . . . . . 20 76 4.2.5 Processing of EAP-Request/SIM/Start by the Peer . . . 20 77 4.2.6 Attacks against Identity Privacy . . . . . . . . . . . 22 78 4.2.7 Processing of AT_IDENTITY by the Server . . . . . . . 22 79 4.3 Message Sequence Examples (Informative) . . . . . . . . . 23 80 4.3.1 Full Authentication . . . . . . . . . . . . . . . . . 23 81 4.3.2 Fast Re-authentication . . . . . . . . . . . . . . . . 24 82 4.3.3 Fall Back to Full Authentication . . . . . . . . . . . 25 83 4.3.4 Requesting the Permanent Identity 1 . . . . . . . . . 26 84 4.3.5 Requesting the Permanent Identity 2 . . . . . . . . . 27 85 4.3.6 Three EAP-SIM/Start Roundtrips . . . . . . . . . . . . 28 86 5. Fast Re-Authentication . . . . . . . . . . . . . . . . . . . 30 87 5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 30 88 5.2 Comparison to UMTS AKA . . . . . . . . . . . . . . . . . . 31 89 5.3 Fast Re-authentication Identity . . . . . . . . . . . . . 32 90 5.4 Fast Re-authentication Procedure . . . . . . . . . . . . . 33 91 5.5 Fast Re-authentication Procedure when Counter is Too 92 Small . . . . . . . . . . . . . . . . . . . . . . . . . . 36 93 6. EAP-SIM Notifications . . . . . . . . . . . . . . . . . . . 38 94 6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 38 95 6.2 Result Indications . . . . . . . . . . . . . . . . . . . . 39 96 6.3 Error Cases . . . . . . . . . . . . . . . . . . . . . . . 40 97 6.3.1 Peer Operation . . . . . . . . . . . . . . . . . . . . 40 98 6.3.2 Server Operation . . . . . . . . . . . . . . . . . . . 41 99 6.3.3 EAP-Failure . . . . . . . . . . . . . . . . . . . . . 42 100 6.3.4 EAP-Success . . . . . . . . . . . . . . . . . . . . . 42 101 6.4 Key Generation . . . . . . . . . . . . . . . . . . . . . . 43 102 7. Message Format and Protocol Extensibility . . . . . . . . . 46 103 7.1 Message Format . . . . . . . . . . . . . . . . . . . . . . 46 104 7.2 Protocol Extensibility . . . . . . . . . . . . . . . . . . 47 105 8. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 48 106 8.1 EAP-Request/SIM/Start . . . . . . . . . . . . . . . . . . 48 107 8.2 EAP-Response/SIM/Start . . . . . . . . . . . . . . . . . . 49 108 8.3 EAP-Request/SIM/Challenge . . . . . . . . . . . . . . . . 50 109 8.4 EAP-Response/SIM/Challenge . . . . . . . . . . . . . . . . 50 110 8.5 EAP-Request/SIM/Re-authentication . . . . . . . . . . . . 51 111 8.6 EAP-Response/SIM/Re-authentication . . . . . . . . . . . . 52 112 8.7 EAP-Response/SIM/Client-Error . . . . . . . . . . . . . . 52 113 8.8 EAP-Request/SIM/Notification . . . . . . . . . . . . . . . 52 114 8.9 EAP-Response/SIM/Notification . . . . . . . . . . . . . . 53 115 9. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 53 116 9.1 Table of Attributes . . . . . . . . . . . . . . . . . . . 53 117 9.2 AT_VERSION_LIST . . . . . . . . . . . . . . . . . . . . . 55 118 9.3 AT_SELECTED_VERSION . . . . . . . . . . . . . . . . . . . 55 119 9.4 AT_NONCE_MT . . . . . . . . . . . . . . . . . . . . . . . 56 120 9.5 AT_PERMANENT_ID_REQ . . . . . . . . . . . . . . . . . . . 56 121 9.6 AT_ANY_ID_REQ . . . . . . . . . . . . . . . . . . . . . . 57 122 9.7 AT_FULLAUTH_ID_REQ . . . . . . . . . . . . . . . . . . . . 57 123 9.8 AT_IDENTITY . . . . . . . . . . . . . . . . . . . . . . . 57 124 9.9 AT_RAND . . . . . . . . . . . . . . . . . . . . . . . . . 58 125 9.10 AT_NEXT_PSEUDONYM . . . . . . . . . . . . . . . . . . . 59 126 9.11 AT_NEXT_REAUTH_ID . . . . . . . . . . . . . . . . . . . 59 127 9.12 AT_IV, AT_ENCR_DATA and AT_PADDING . . . . . . . . . . . 60 128 9.13 AT_RESULT_IND . . . . . . . . . . . . . . . . . . . . . 62 129 9.14 AT_MAC . . . . . . . . . . . . . . . . . . . . . . . . . 62 130 9.15 AT_COUNTER . . . . . . . . . . . . . . . . . . . . . . . 63 131 9.16 AT_COUNTER_TOO_SMALL . . . . . . . . . . . . . . . . . . 63 132 9.17 AT_NONCE_S . . . . . . . . . . . . . . . . . . . . . . . 63 133 9.18 AT_NOTIFICATION . . . . . . . . . . . . . . . . . . . . 64 134 9.19 AT_CLIENT_ERROR_CODE . . . . . . . . . . . . . . . . . . 65 135 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 65 136 11. Security Considerations . . . . . . . . . . . . . . . . . . 66 137 11.1 A3 and A8 Algorithms . . . . . . . . . . . . . . . . . . 66 138 11.2 Identity Protection . . . . . . . . . . . . . . . . . . 66 139 11.3 Mutual Authentication and Triplet Exposure . . . . . . . 67 140 11.4 Flooding the Authentication Centre . . . . . . . . . . . 68 141 11.5 Key Derivation . . . . . . . . . . . . . . . . . . . . . 69 142 11.6 Cryptographic Separation of Keys and Session 143 Independence . . . . . . . . . . . . . . . . . . . . . . 69 144 11.7 Dictionary Attacks . . . . . . . . . . . . . . . . . . . 70 145 11.8 Credentials Reuse . . . . . . . . . . . . . . . . . . . 70 146 11.9 Integrity and Replay Protection, and Confidentiality . . 71 147 11.10 Negotiation Attacks . . . . . . . . . . . . . . . . . . 73 148 11.11 Protected Result Indications . . . . . . . . . . . . . . 73 149 11.12 Man-in-the-middle Attacks . . . . . . . . . . . . . . . 73 150 11.13 Generating Random Numbers . . . . . . . . . . . . . . . 74 151 12. Security Claims . . . . . . . . . . . . . . . . . . . . . . 74 152 13. Acknowledgements and Contributions . . . . . . . . . . . . . 75 153 13.1 Contributors . . . . . . . . . . . . . . . . . . . . . . 75 154 13.2 Acknowledgements . . . . . . . . . . . . . . . . . . . . 75 155 13.2.1 Contributors' Addresses . . . . . . . . . . . . . . 76 156 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 157 14.1 Normative References . . . . . . . . . . . . . . . . . . . 77 158 14.2 Informative References . . . . . . . . . . . . . . . . . . 78 159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 79 160 A. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 80 161 A.1 EAP-Request/Identity . . . . . . . . . . . . . . . . . . . 80 162 A.2 EAP-Response/Identity . . . . . . . . . . . . . . . . . . 80 163 A.3 EAP-Request/SIM/Start . . . . . . . . . . . . . . . . . . 81 164 A.4 EAP-Response/SIM/Start . . . . . . . . . . . . . . . . . . 81 165 A.5 EAP-Request/SIM/Challenge . . . . . . . . . . . . . . . . 81 166 A.6 EAP-Response/SIM/Challenge . . . . . . . . . . . . . . . . 84 167 A.7 EAP-Success . . . . . . . . . . . . . . . . . . . . . . . 85 168 A.8 Fast Re-authentication . . . . . . . . . . . . . . . . . . 85 169 A.9 EAP-Request/SIM/Re-authentication . . . . . . . . . . . . 85 170 A.10 EAP-Response/SIM/Re-authentication . . . . . . . . . . . 88 171 B. Pseudo-Random Number Generator . . . . . . . . . . . . . . . 89 172 Intellectual Property and Copyright Statements . . . . . . . 90 174 1. Introduction 176 This document specifies an Extensible Authentication Protocol (EAP) 177 [RFC3748] mechanism for authentication and session key distribution 178 using the Global System for Mobile Communications (GSM) Subscriber 179 Identity Module (SIM). 181 GSM is a second generation mobile network standard. Second 182 generation mobile networks and third generation mobile networks use 183 different authentication and key agreement mechanisms. EAP-AKA 184 [EAP-AKA] specifies an EAP method that is based on the authentication 185 and key agreement mechanism used in 3rd generation mobile networks. 187 GSM authentication is based on a challenge-response mechanism. The 188 A3/A8 authentication and key derivation algorithms that run on the 189 SIM can be given a 128-bit random number (RAND) as a challenge. The 190 SIM runs operator-specific algorithms, which take the RAND and a 191 secret key Ki stored on the SIM as input, and produce a 32-bit 192 response (SRES) and a 64-bit long key Kc as output. The Kc key is 193 originally intended to be used as an encryption key over the air 194 interface, but in this protocol it is used for deriving keying 195 material and not directly used. Hence the secrecy of Kc is critical 196 to the security of this protocol. Please find more information about 197 GSM authentication in [GSM 03.20]. Please see Section 11.1 for more 198 discussion about the GSM algorithms used in EAP-SIM. 200 The lack of mutual authentication is a weakness in GSM 201 authentication. The 64 bit cipher key (Kc) that is derived is not 202 strong enough for data networks where stronger and longer keys are 203 required. Hence in EAP-SIM, several RAND challenges are used for 204 generating several 64-bit Kc keys, which are combined to constitute 205 stronger keying material. In EAP-SIM the client issues a random 206 number NONCE_MT to the network, in order to contribute to key 207 derivation, and to prevent replays of EAP-SIM requests from previous 208 exchanges. The NONCE_MT can be conceived as the client's challenge 209 to the network. EAP-SIM also extends the combined RAND challenges 210 and other messages with a message authentication code in order to 211 provide message integrity protection along with mutual 212 authentication. 214 EAP-SIM specifies optional support for protecting the privacy of 215 subscriber identity using the same concept as GSM, which is using 216 pseudonyms/temporary identifiers. It also specifies an optional fast 217 re-authentication procedure. 219 The security of EAP-SIM builds on underlying GSM mechanisms. The 220 security properties of EAP-SIM are documented in Section 11 of this 221 document. Implementers and users of EAP-SIM are advised to carefully 222 study the security considerations in Section 11 in order to determine 223 whether the security properties are sufficient for the environment in 224 question, especially as the secrecy of Kc keys is key to the security 225 of EAP-SIM. In brief, EAP-SIM is in no sense weaker than the GSM 226 mechanisms. In some cases EAP-SIM provides better security 227 properties than the underlying GSM mechanisms, particularly if the 228 SIM credentials are only used for EAP-SIM and not re-used from 229 GSM/GPRS. Many of the security features of EAP-SIM rely upon the 230 secrecy of the Kc values in the SIM triplets, so protecting these 231 values is key to the security of the EAP-SIM protocol. 233 The 3rd Generation Partnership Project (3GPP) has specified an 234 enhanced Authentication and Key Agreement (AKA) architecture for the 235 Universal Mobile Telecommunications System (UMTS). The 3rd 236 generation AKA mechanism includes mutual authentication, replay 237 protection and derivation of longer session keys. EAP-AKA [EAP-AKA] 238 specifies an EAP method that is based on the 3rd generation AKA. 239 EAP-AKA, which is a more secure protocol, may be used instead of 240 EAP-SIM, if 3rd generation identity modules and 3G network 241 infrastructure are available. 243 2. Terms 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in [RFC2119]. 249 The terms and abbreviations "authenticator", "backend authentication 250 server", "EAP server", "peer", "Silently Discard", "Master Session 251 Key (MSK)", and "Extended Master Session Key (EMSK)" in this document 252 are to be interpreted as described in [RFC3748]. 254 This document frequently uses the following terms and abbreviations: 256 AAA protocol 258 Authentication, Authorization and Accounting protocol 260 AuC 262 Authentication Centre. The GSM network element that provides 263 the authentication triplets for authenticating 264 the subscriber. 266 Authentication vector 268 GSM triplets can be alternatively called authentication 269 vectors 271 EAP 273 Extensible Authentication Protocol. 275 Fast re-authentication 277 An EAP-SIM authentication exchange that is based on keys 278 derived upon a preceding full authentication exchange. 279 The GSM authentication and key exchange algorithms are not 280 used in the fast re-authentication procedure. 282 Fast Re-authentication Identity 284 A fast re-authentication identity of the peer, including an NAI 285 realm portion in environments where a realm is used. Used on 286 fast re-authentication only. 288 Fast Re-authentication Username 290 The username portion of fast re-authentication identity, 291 ie. not including any realm portions. 293 Full authentication 295 An EAP-SIM authentication exchange based on the GSM 296 authentication and key agreement algorithms. 298 GSM 300 Global System for Mobile communications. 302 GSM Triplet 304 The tuple formed by the three GSM authentication values RAND, 305 Kc and SRES 307 IMSI 309 International Mobile Subscriber Identifier, used in GSM to 310 identify subscribers. 312 MAC 314 Message Authentication Code 316 NAI 318 Network Access Identifier 320 Nonce 322 A value that is used at most once or that is never repeated 323 within the same cryptographic context. In general, a nonce can 324 be predictable (e.g. a counter) or unpredictable (e.g. a 325 random value). Since some cryptographic properties may depend 326 on the randomness of the nonce, attention should be paid to 327 whether a nonce is required to be random or not. In this 328 document, the term nonce is only used to denote random nonces, 329 and it is not used to denote counters. 331 Permanent Identity 333 The permanent identity of the peer, including an NAI realm 334 portion in environments where a realm is used. The permanent 335 identity is usually based on the IMSI. Used on full 336 authentication only. 338 Permanent Username 340 The username portion of permanent identity, ie. not including 341 any realm portions. 343 Pseudonym Identity 345 A pseudonym identity of the peer, including an NAI realm 346 portion in environments where a realm is used. Used on 347 full authentication only. 349 Pseudonym Username 351 The username portion of pseudonym identity, ie. not including 352 any realm portions. 354 SIM 356 Subscriber Identity Module. The SIM is traditionally a smart 357 card distributed by a GSM operator. 359 3. Overview 361 Figure 1 shows an overview of the EAP-SIM full authentication 362 procedure, when optional protected success indications are not used. 363 The authenticator typically communicates with an EAP server that is 364 located on a backend authentication server using an AAA protocol. 365 The authenticator shown in the figure is often simply relaying EAP 366 messages to and from the EAP server, but these back end AAA 367 communications are not shown. 369 Peer Authenticator 370 | EAP-Request/Identity | 371 |<---------------------------------------------------------| 372 | | 373 | EAP-Response/Identity | 374 |--------------------------------------------------------->| 375 | | 376 | EAP-Request/SIM/Start (AT_VERSION_LIST) | 377 |<---------------------------------------------------------| 378 | | 379 | EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)| 380 |--------------------------------------------------------->| 381 | | 382 | EAP-Request/SIM/Challenge (AT_RAND, AT_MAC) | 383 |<---------------------------------------------------------| 384 +-------------------------------------+ | 385 | Peer runs GSM algorithms, verifies | | 386 | AT_MAC and derives session keys | | 387 +-------------------------------------+ | 388 | EAP-Response/SIM/Challenge (AT_MAC) | 389 |--------------------------------------------------------->| 390 | | 391 | EAP-Success | 392 |<---------------------------------------------------------| 393 | | 395 Figure 1: EAP-SIM full authentication procedure 397 The first EAP Request issued by the authenticator is 398 EAP-Request/Identity. On full authentication, the peer's response 399 includes either the user's International Mobile Subscriber Identity 400 (IMSI) or a temporary identity (pseudonym) if identity privacy is in 401 effect, as specified in Section 4.2. 403 Following the peer's EAP-Response/Identity packet, the peer receives 404 EAP Requests of type 18 (SIM) from the EAP server and sends the 405 corresponding EAP Responses. The EAP packets that are of the Type 406 SIM also have a Subtype field. On full authentication, the first 407 EAP-Request/SIM packet is of the Subtype 10 (Start). EAP-SIM packets 408 encapsulate parameters in attributes, encoded in a Type, Length, 409 Value format. The packet format and the use of attributes are 410 specified in Section 7. 412 The EAP-Request/SIM/Start packet contains the list of EAP-SIM version 413 supported by the EAP server in the AT_VERSION_LIST attribute. This 414 packet may also include attributes for requesting the subscriber 415 identity, as specified in Section 4.2. 417 The peer responds to EAP-Request/SIM/Start with the 418 EAP-Response/SIM/Start packet, which includes the AT_NONCE_MT 419 attribute that contains a random number NONCE_MT, chosen by the peer, 420 and the AT_SELECTED_VERSION attribute that contains the version 421 number selected by the peer. The version negotiation is protected by 422 including the version list and the selected version in the 423 calculation of keying material (Section 6.4). 425 After receiving the EAP Response/SIM/Start, the EAP server obtains n 426 GSM triplets for use in authenticating the subscriber, where n = 2 or 427 n = 3. From the triplets, the EAP server derives the keying 428 material, as specified in Section 6.4. The triplets may be obtained 429 by contacting an Authentication Centre (AuC) on the GSM network; per 430 GSM specifications, between 1 and 5 triplets may be obtained at a 431 time. Triplets may be stored in the EAP server for use at a later 432 time, but triplets MUST NOT be reused, except in some error cases 433 that are specified in Section 9.9 435 The next EAP Request the EAP Server issues is of the type SIM and 436 subtype Challenge (11). It contains the RAND challenges and a 437 message authentication code attribute AT_MAC to cover the challenges. 438 The AT_MAC attribute is a general message authentication code 439 attribute that is used in many EAP-SIM messages. 441 On receipt of the EAP-Request/SIM/Challenge message, the peer runs 442 the GSM authentication algorithm and calculates a copy of the message 443 authentication code. The peer then verifies that the calculated MAC 444 equals the received MAC. If the MAC's do not match, then the peer 445 sends the EAP-Response/SIM/Client-Error packet and the authentication 446 exchange terminates. 448 Since the RAND's given to a peer are accompanied with the message 449 authentication code AT_MAC, and since the peer's NONCE_MT value 450 contributes to AT_MAC, the peer is able to verify that the EAP-SIM 451 message is fresh (not a replay) and that the sender possesses valid 452 GSM triplets for the subscriber. 454 If all checks out, the peer responds with the 455 EAP-Response/SIM/Challenge, containing the AT_MAC attribute that 456 covers the peer's SRES response values (Section 8.4). The EAP server 457 verifies that the MAC is correct. Because protected success 458 indications are not used in this example, the EAP server sends the 459 EAP-Success packet, indicating that the authentication was 460 successful. (Protected success indications are discussed in Section 461 6.2.) The EAP server may also include derived keying material in the 462 message it sends to the authenticator. The peer has derived the same 463 keying material, so the authenticator does not forward the keying 464 material to the peer along with EAP-Success. 466 EAP-SIM also includes a separate fast re-authentication procedure, 467 which does not make use of the A3/A8 algorithms or the GSM 468 infrastructure. Fast re-authentication is based on keys derived on 469 full authentication. If the peer has maintained state information 470 for fast re-authentication and wants to use fast re-authentication, 471 then the peer indicates this by using a specific fast 472 re-authentication identity instead of the permanent identity or a 473 pseudonym identity. The fast re-authentication procedure is 474 described in Section 5. 476 4. Operation 478 4.1 Version Negotiation 480 EAP-SIM includes version negotiation so as to allow future 481 developments in the protocol. The version negotiation is performed 482 on full authentication and it uses two attributes, AT_VERSION_LIST, 483 which the server always includes in EAP-Request/SIM/Start, and 484 AT_SELECTED_VERSION, which the peer includes in EAP- 485 Response/SIM/Start on full authentication. 487 AT_VERSION_LIST includes the EAP-SIM versions supported by the 488 server. If AT_VERSION_LIST does not include a version that is 489 implemented by the peer and allowed in the peer's security policy, 490 then the peer MUST send the EAP-Response/SIM/Client-Error packet 491 (Section 8.7) to the server with the error code "unsupported 492 version". If a suitable version is included, then the peer includes 493 the AT_SELECTED_VERSION attribute, containing the selected version, 494 in the EAP-Response/SIM/Start packet. The peer MUST only indicate a 495 version that is included in AT_VERSION_LIST. If several versions are 496 acceptable, then the peer SHOULD choose the version that occurs first 497 in the version list. 499 The version number list of AT_VERSION_LIST and the selected version 500 of AT_SELECTED_VERSION are included in the key derivation procedure 501 (Section 6.4). If an attacker modifies either one of these 502 attributes, then the peer and the server derive different keying 503 material. Because K_aut keys are different, the server and peer 504 calculate different AT_MAC values. Hence, the peer detects that 505 AT_MAC included in EAP-Request/SIM/Challenge is incorrect and sends 506 the EAP-Response/SIM/Client-Error packet. The authentication 507 procedure terminates. 509 4.2 Identity Management 511 4.2.1 Format, Generation and Usage of Peer Identities 513 4.2.1.1 General 515 In the beginning of EAP authentication, the Authenticator or the EAP 516 server usually issues the EAP-Request/Identity packet to the peer. 517 The peer responds with EAP-Response/Identity, which contains the 518 user's identity. The formats of these packets are specified in 519 [RFC3748]. 521 GSM subscribers are identified with the International Mobile 522 Subscriber Identity (IMSI) [GSM 03.03]. The IMSI is a string of not 523 more than 15 digits. It is composed of a three digit Mobile Country 524 Code (MCC), a two or three digit Mobile Network Code (MNC) and a not 525 more than 10 digit Mobile Subscriber Identification Number (MSIN). 526 MCC and MNC uniquely identify the GSM operator and help identify the 527 AuC from which the authentication vectors need to be retrieved for 528 this subscriber. 530 Internet AAA protocols identify users with the Network Access 531 Identifier (NAI) [RFC2486]. When used in a roaming environment, the 532 NAI is composed of a username and a realm, separated with "@" 533 (username@realm). The username portion identifies the subscriber 534 within the realm. 536 This section specifies the peer identity format used in EAP-SIM. In 537 this document, the term identity or peer identity refers to the whole 538 identity string that is used to identify the peer. The peer identity 539 may include a realm portion. "Username" refers to the portion of the 540 peer identity that identifies the user, i.e. the username does not 541 include the realm portion. 543 4.2.1.2 Identity Privacy Support 545 EAP-SIM includes optional identity privacy (anonymity) support that 546 can be used to hide the cleartext permanent identity and thereby to 547 make the subscriber's EAP exchanges untraceable to eavesdroppers. 548 Because the permanent identity never changes, revealing it would help 549 observers to track the user. The permanent identity is usually based 550 on the IMSI, which may further help the tracking, because the same 551 identifier may be used in other contexts as well. Identity privacy 552 is based on temporary identities, or pseudonyms, which are equivalent 553 to but separate from the Temporary Mobile Subscriber Identities 554 (TMSI) that are used on cellular networks. Please see Section 11.2 555 for security considerations regarding identity privacy. 557 4.2.1.3 Username Types in EAP-SIM identities 559 There are three types of usernames in EAP-SIM peer identities: 561 (1) Permanent usernames. For example, 562 1123456789098765@myoperator.com might be a valid permanent identity. 563 In this example, 1123456789098765 is the permanent username. 565 (2) Pseudonym usernames. For example, 3s7ah6n9q@myoperator.com might 566 be a valid pseudonym identity. In this example, 3s7ah6n9q is the 567 pseudonym username. 569 (3) Fast re-authentication usernames. For example, 570 53953754@myoperator.com might be a valid fast re-authentication 571 identity. In this case, 53953754 is the fast re-authentication 572 username. Unlike permanent usernames and pseudonym usernames, fast 573 re-authentication usernames are one-time identifiers, which are not 574 re-used across EAP exchanges. 576 The first two types of identities are only used on full 577 authentication and the last one only on fast re-authentication. When 578 the optional identity privacy support is not used, the non-pseudonym 579 permanent identity is used on full authentication. The fast 580 re-authentication exchange is specified in Section 5. 582 4.2.1.4 Username Decoration 584 In some environments, the peer may need to decorate the identity by 585 prepending or appending the username with a string, in order to 586 indicate supplementary AAA routing information in addition to the NAI 587 realm. (The usage of a NAI realm portion is not considered to be 588 decoration.) Username decoration is out of the scope of this 589 document. However, it should be noted that username decoration might 590 prevent the server from recognizing a valid username. Hence, 591 although the peer MAY use username decoration in the identities the 592 peer includes in EAP-Response/Identity, and the EAP server MAY accept 593 a decorated peer username in this message, the peer or the EAP server 594 MUST NOT decorate any other peer identities that are used in various 595 EAP-SIM attributes. Only the identity used in EAP-Response/Identity 596 may be decorated. 598 4.2.1.5 NAI Realm Portion 600 The peer MAY include a realm portion in the peer identity, as per the 601 NAI format. The use of a realm portion is not mandatory. 603 If a realm is used, the realm MAY be chosen by the subscriber's home 604 operator and it MAY be a configurable parameter in the EAP-SIM peer 605 implementation. In this case, the peer is typically configured with 606 the NAI realm of the home operator. Operators MAY reserve a specific 607 realm name for EAP-SIM users. This convention makes it easy to 608 recognize that the NAI identifies a GSM subscriber. Such reserved 609 NAI realm may be useful as a hint as to the first authentication 610 method to use during method negotiation. When the peer is using a 611 pseudonym username instead of the permanent username, the peer 612 selects the realm name portion similarly as it select the realm 613 portion when using the permanent username. 615 If no configured realm name is available, the peer MAY derive the 616 realm name from the MCC and MNC portions of the IMSI. A RECOMMENDED 617 way to derive the realm from the IMSI using the realm 3gppnetwork.org 618 will be specified in [Draft 3GPP TS 23.003]. 620 Some old implementations derive the realm name from the IMSI by 621 concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits 622 of IMSI and ".owlan.org". For example, if the IMSI is 623 123456789098765, and the MNC is three digits long, then the derived 624 realm name is "mnc456.mcc123.owlan.org". As there are no DNS servers 625 running at owlan.org, these realm names can only be used with 626 manually configured AAA routing. New implementations SHOULD use the 627 mechanism specified in [Draft 3GPP TS 23.003] instead of owlan.org as 628 soon as the 3GPP specification is finalized. 630 The IMSI is a string of digits without any explicit structure, so the 631 peer may not be able to determine the length of the MNC portion. If 632 the peer is not able to determine whether the MNC is two or three 633 digits long, the peer MAY use a 3-digit MNC. If the correct length 634 of the MNC is two, then the MNC used in the realm name includes the 635 first digit of MSIN. Hence, when configuring AAA networks for 636 operators that have 2-digit MNC's, the network SHOULD also be 637 prepared for realm names with incorrect 3-digit MNC's. 639 4.2.1.6 Format of the Permanent Username 641 The non-pseudonym permanent username SHOULD be derived from the IMSI. 642 In this case, the permanent username MUST be of the format "1" | 643 IMSI, where the character "|" denotes concatenation. In other words, 644 the first character of the username is the digit one (ASCII value 31 645 hexadecimal), followed by the IMSI. The IMSI is encoded as an ASCII 646 string that consists of not more than 15 decimal digits (ASCII values 647 between 30 and 39 hexadecimal), one character per IMSI digit, in the 648 order as specified in [GSM 03.03]. For example, a permanent username 649 derived from the IMSI 295023820005424 would be encoded as the ASCII 650 string "1295023820005424" (byte values in hexadecimal notation: 31 651 32 39 35 30 32 33 38 32 30 30 30 35 34 32 34) 652 The EAP server MAY use the leading "1" as a hint to try EAP-SIM as 653 the first authentication method during method negotiation, rather 654 than for example EAP/AKA. The EAP-SIM server MAY propose EAP-SIM 655 even if the leading character was not "1". 657 Alternatively, an implementation MAY choose a permanent username that 658 is not based on the IMSI. In this case the selection of the 659 username, its format, and its processing is out of the scope of this 660 document. In this case, the peer implementation MUST NOT prepend any 661 leading characters to the username. 663 4.2.1.7 Generating Pseudonyms and Fast Re-authentication Identities by 664 the Server 666 Pseudonym usernames and fast re-authentication identities are 667 generated by the EAP server. The EAP server produces pseudonym 668 usernames and fast re-authentication identities in an 669 implementation-dependent manner. Only the EAP server needs to be 670 able to map the pseudonym username to the permanent identity, or to 671 recognize a fast re-authentication identity. 673 EAP-SIM includes no provisions to ensure that the same EAP server 674 that generated a pseudonym username will be used on the 675 authentication exchange when the pseudonym username is used. It is 676 recommended that the EAP servers implement some centralized mechanism 677 to allow all EAP servers of the home operator to map pseudonyms 678 generated by other severs to the permanent identity. If no such 679 mechanism is available, then the EAP server failing to understand a 680 pseudonym issued by another server can request the peer to send the 681 permanent identity. 683 When issuing a fast re-authentication identity, the EAP server may 684 include a realm name in the identity to make the fast 685 re-authentication request be forwarded to the same EAP server. 687 When generating fast re-authentication identities, the server SHOULD 688 choose a fresh new fast re-authentication identity that is different 689 from the previous ones used after the same full authentication 690 exchange. A full authentication exchange and the associated fast 691 re-authentication exchanges are referred to here as the same "full 692 authentication context". The fast re-authentication identity SHOULD 693 include a random component. The random component works as a full 694 authentication context identifier. A context-specific fast 695 re-authentication identity can help the server to detect whether its 696 fast re-authentication state information matches the peer's fast 697 re-authentication state information (in other words whether the state 698 information is from the same full authentication exchange). The 699 random component also makes the fast re-authentication identities 700 unpredictable, so an attacker cannot initiate a fast 701 re-authentication exchange to get the server's 702 EAP-Request/SIM/Re-authentication packet. 704 Transmitting pseudonyms and fast re-authentication identities from 705 the server to the peer is discussed in Section 4.2.1.8. The 706 pseudonym is transmitted as a username, without an NAI realm, and the 707 fast re-authentication identity is transmitted as a complete NAI, 708 including a realm portion if a realm is required. The realm is 709 included in the fast re-authentication identity in order to allow the 710 server to include a server-specific realm. 712 Regardless of construction method, the pseudonym username MUST 713 conform to the grammar specified for the username portion of an NAI. 714 The fast re-authentication identity also MUST conform to the NAI 715 grammar. The EAP servers that the subscribers of an operator can use 716 MUST ensure that the pseudonym usernames and the username portions 717 used in fast re-authentication identities they generate are unique. 719 In any case, it is necessary that permanent usernames, pseudonym 720 usernames and fast re-authentication usernames are separate and 721 recognizable from each other. It is also desirable that EAP-SIM and 722 EAP-AKA [EAP-AKA] user names be recognizable from each other as an 723 aid for the server to which method to offer. 725 In general, it is the task of the EAP server and the policies of its 726 administrator to ensure sufficient separation in the usernames. 727 Pseudonym usernames and fast re-authentication usernames are both 728 produced and used by the EAP server. The EAP server MUST compose 729 pseudonym usernames and fast re-authentication usernames so that it 730 can recognize if a NAI username is an EAP-SIM pseudonym username or 731 an EAP-SIM fast re-authentication username. For instance, when the 732 usernames have been derived from the IMSI, the server could use 733 different leading characters in the pseudonym usernames and fast 734 re-authentication usernames (e.g. the pseudonym could begin with a 735 leading "3" character). When mapping a fast re-authentication 736 identity to a permanent identity, the server SHOULD only examine the 737 username portion of the fast re-authentication identity and ignore 738 the realm portion of the identity. 740 Because the peer may fail to save a pseudonym username sent to in an 741 EAP-Request/SIM/Challenge, for example due to malfunction, the EAP 742 server SHOULD maintain at least the most recently used pseudonym 743 username in addition to the most recently issued pseudonym username. 744 If the authentication exchange is not completed successfully, then 745 the server SHOULD NOT overwrite the pseudonym username that was 746 issued during the most recent successful authentication exchange. 748 4.2.1.8 Transmitting Pseudonyms and Fast Re-authentication Identities 749 to the Peer 751 The server transmits pseudonym usernames and fast re-authentication 752 identities to the peer in cipher, using the AT_ENCR_DATA attribute. 754 The EAP-Request/SIM/Challenge message MAY include an encrypted 755 pseudonym username and/or an encrypted fast re-authentication 756 identity in the value field of the AT_ENCR_DATA attribute. Because 757 identity privacy support and fast re-authentication are optional to 758 implement, the peer MAY ignore the AT_ENCR_DATA attribute and always 759 use the permanent identity. On fast re-authentication (discussed in 760 Section 5), the server MAY include a new encrypted fast 761 re-authentication identity in the EAP-Request/SIM/Re-authentication 762 message. 764 On receipt of the EAP-Request/SIM/Challenge, the peer MAY decrypt the 765 encrypted data in AT_ENCR_DATA. If the authentication exchange is 766 successful, and the the encrypted data includes a pseudonym username, 767 then the peer may use the obtained pseudonym username on the next 768 full authentication. If a fast re-authentication identity is 769 included, then the peer MAY save it together with other fast 770 re-authentication state information, as discussed in Section 5, for 771 the next fast re-authentication. If the authentication exchange does 772 not complete successfully, the peer MUST ignore the received 773 pseudonym username and the fast re-authentication identity. 775 If the peer does not receive a new pseudonym username in the 776 EAP-Request/SIM/Challenge message, the peer MAY use an old pseudonym 777 username instead of the permanent username on next full 778 authentication. The username portions of fast re-authentication 779 identities are one-time usernames, which the peer MUST NOT re-use. 780 When the peer uses a fast re-authentication identity in an EAP 781 exchange, the peer MUST discard the fast re-authentication identity 782 and not re-use it in another EAP authentication exchange, even if the 783 authentication exchange was not completed. 785 4.2.1.9 Usage of the Pseudonym by the Peer 787 When the optional identity privacy support is used on full 788 authentication, the peer MAY use a pseudonym username received as 789 part of a previous full authentication sequence as the username 790 portion of the NAI. The peer MUST NOT modify the pseudonym username 791 received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer 792 MAY need to decorate the username in some environments by appending 793 or prepending the username with a string that indicates supplementary 794 AAA routing information. 796 When using a pseudonym username in an environment where a realm 797 portion is used, the peer concatenates the received pseudonym 798 username with the "@" character and a NAI realm portion. The 799 selection of the NAI realm is discussed above. The peer can select 800 the realm portion similarly regardless of whether it uses the 801 permanent username or a pseudonym username. 803 4.2.1.10 Usage of the Fast Re-authentication Identity by the Peer 805 On fast re-authentication, the peer uses the fast re-authentication 806 identity, received as part of the previous authentication sequence. 807 A new re-authentication identity may be delivered as part of both 808 full authentication and fast re-authentication. The peer MUST NOT 809 modify the username part of the fast re-authentication identity 810 received in AT_NEXT_REAUTH_ID, except in cases when username 811 decoration is required. Even in these cases, the "root" fast 812 re-authentication username must not be modified, but it may be 813 appended or prepended with another string. 815 4.2.2 Communicating the Peer Identity to the Server 817 4.2.2.1 General 819 The peer identity MAY be communicated to the server with the 820 EAP-Response/Identity message. This message MAY contain the 821 permanent identity, a pseudonym identity, or a fast re-authentication 822 identity. If the peer uses the permanent identity or a pseudonym 823 identity, which the server is able to map to the permanent identity, 824 then the authentication proceeds as discussed in the overview of 825 Section 3. If the peer uses a fast re-authentication identity, and 826 if the fast re-authentication identity matches with a valid fast 827 re-authentication identity maintained by the server, and if the 828 server agrees on using fast re-authentication, then a fast 829 re-authentication exchange is performed, as described in Section 5. 831 The peer identity can also be transmitted from the peer to the server 832 using EAP-SIM messages instead of EAP-Response/Identity. In this 833 case, the server includes an identity requesting attribute 834 (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the 835 EAP-Request/SIM/Start message, and the peer includes the AT_IDENTITY 836 attribute, which contains the peer's identity, in the 837 EAP-Response/SIM/Start message. The AT_ANY_ID_REQ attribute is a 838 general identity requesting attribute, which the server uses if it 839 does not specify which kind of an identity the peer should return in 840 AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to 841 request either the permanent identity or a pseudonym identity. The 842 server uses the AT_PERMANENT_ID_REQ attribute to request the peer to 843 send its permanent identity. 845 The identity format in the AT_IDENTITY attribute is the same as in 846 the EAP-Response/Identity packet (except that identity decoration is 847 not allowed). The AT_IDENTITY attribute contains a permanent 848 identity, a pseudonym identity or a fast re-authentication identity. 850 Please note that the EAP-SIM peer and the EAP-SIM server only process 851 the AT_IDENTITY attribute and entities that only pass through EAP 852 packets do not process this attribute. Hence, the authenticator and 853 other intermediate AAA elements (such as possible AAA proxy servers) 854 will continue to refer to the peer with the original identity from 855 the EAP-Response/Identity packet unless the identity authenticated in 856 the AT_IDENTITY attribute is communicated to them in another way 857 within the AAA protocol. 859 4.2.2.2 Relying on EAP-Response/Identity Discouraged 861 The EAP-Response/Identity packet is not method specific so in many 862 implementations it may be handled by an EAP Framework. This 863 introduces an additional layer of processing between the EAP peer and 864 EAP server. The extra layer of processing may cache identity 865 responses or add decorations to the identity. A modification of the 866 identity response will cause the EAP peer and EAP server to use 867 different identities in the key derivation which will cause the 868 protocol to fail. 870 For this reason, it is RECOMMENDED that the EAP peer and server use 871 the method specific identity attributes in EAP-SIM and the server is 872 strongly discouraged from relying upon the EAP-Response/Identity. 874 In particular, if the EAP server receives a decorated identity in 875 EAP-Response/Identity, then the EAP server MUST use the 876 identity-requesting attributes to request the peer to send an 877 unmodified and undecorated copy of the identity in AT_IDENTITY. 879 4.2.3 Choice of Identity for the EAP-Response/Identity 881 If EAP-SIM peer is started upon receiving an EAP-Request/Identity 882 message, then the peer performs the following steps. 884 If the peer has maintained fast re-authentication state information 885 and if the peer wants to use fast re-authentication, then the peer 886 transmits the fast re-authentication identity in 887 EAP-Response/Identity. 889 Else, if the peer has a pseudonym username available, then the peer 890 transmits the pseudonym identity in EAP-Response/Identity. 892 In other cases, the peer transmits the permanent identity in 893 EAP-Response/Identity. 895 4.2.4 Server Operation in the Beginning of EAP-SIM Exchange 897 If the EAP server has not received any EAP-SIM peer identity 898 (permanent identity, pseudonym identity or fast re-authentication 899 identity) from the peer when sending the first EAP-SIM request, or if 900 the EAP server has received an EAP-Response/Identity packet but the 901 contents do not appear to be a valid permanent identity, pseudonym 902 identity or a re-authentication identity, then the server MUST 903 request an identity from the peer using one of the methods below. 905 The server sends the EAP-Request/SIM/Start message with the 906 AT_PERMANENT_ID_REQ attribute to indicate that the server wants the 907 peer to include the permanent identity in the AT_IDENTITY attribute 908 of the EAP-Response/SIM/Start message. This is done in the following 909 cases: 911 o The server does not support fast re-authentication or identity 912 privacy. 913 o The server received an identity that it recognizes as a pseudonym 914 identity but the server is not able to map the pseudonym identity 915 to a permanent identity. 917 The server issues the EAP-Request/SIM/Start packet with the 918 AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the 919 peer to include a full authentication identity (pseudonym identity or 920 permanent identity) in the AT_IDENTITY attribute of the 921 EAP-Response/SIM/Start message. This is done in the following cases: 923 o The server does not support fast re-authentication and the server 924 supports identity privacy 925 o The server received an identity that it recognizes as a 926 re-authentication identity but the server is not able to map the 927 re-authentication identity to a permanent identity 929 The server issues the EAP-Request/SIM/Start packet with the 930 AT_ANY_ID_REQ attribute to indicate that the server wants the peer to 931 include an identity in the AT_IDENTITY attribute of the 932 EAP-Response/SIM/Start message, and the server does not indicate any 933 preferred type for the identity. This is done in other cases, such 934 as when the server does not have any identity, or the server does not 935 recognize the format of a received identity. 937 4.2.5 Processing of EAP-Request/SIM/Start by the Peer 939 Upon receipt of an EAP-Request/SIM/Start message, the peer MUST 940 perform the following steps. 942 If the EAP-Request/SIM/Start does not include any identity request 943 attribute, then the peer responds with EAP-Response/SIM/Start without 944 AT_IDENTITY. The peer includes the AT_SELECTED_VERSION and 945 AT_NONCE_MT attributes, because the exchange is a full authentication 946 exchange. 948 If the EAP-Request/SIM/Start includes AT_PERMANENT_ID_REQ, and if the 949 peer does not have a pseudonym available, then the peer MUST respond 950 with EAP-Response/SIM/Start and include the permanent identity in 951 AT_IDENTITY. If the peer has a pseudonym available then the peer MAY 952 refuse to send the permanent identity; hence in this case the peer 953 MUST either respond with EAP-Response/SIM/Start and include the 954 permanent identity in AT_IDENTITY or respond with 955 EAP-Response/SIM/Client-Error packet with code "unable to process 956 packet". 958 If the EAP-Request/SIM/Start includes AT_FULL_AUTH_ID_REQ, and if the 959 peer has a pseudonym available, then the peer SHOULD respond with 960 EAP-Response/SIM/Start and include the pseudonym identity in 961 AT_IDENTITY. If the peer does not have a pseudonym when it receives 962 this message, then the peer MUST respond with EAP- Response/SIM/Start 963 and include the permanent identity in AT_IDENTITY. The Peer MUST NOT 964 use a re-authentication identity in the AT_IDENTITY attribute. 966 If the EAP-Request/SIM/Start includes AT_ANY_ID_REQ, and if the peer 967 has maintained fast re-authentication state information and the peer 968 wants to use fast re-authentication, then the peer responds with 969 EAP-Response/SIM/Start and includes the fast re-authentication 970 identity in AT_IDENTITY. Else, if the peer has a pseudonym identity 971 available, then the peer responds with EAP-Response/SIM/Start and 972 includes the pseudonym identity in AT_IDENTITY. Else, the peer 973 responds with EAP-Response/SIM/Start and includes the permanent 974 identity in AT_IDENTITY. 976 An EAP-SIM exchange may include several EAP/SIM/Start rounds. The 977 server may issue a second EAP-Request/SIM/Start, if it was not able 978 to recognize the identity the peer used in the previous AT_IDENTITY 979 attribute. At most three EAP/SIM/Start rounds can be used, so the 980 peer MUST NOT respond to more than three EAP-Request/SIM/Start 981 messages within an EAP exchange. The peer MUST verify that the 982 sequence of EAP-Request/SIM/Start packets the peer receives comply 983 with the sequencing rules defined in this document. That is, 984 AT_ANY_ID_REQ can only be used in the first EAP-Request/SIM/Start, in 985 other words AT_ANY_ID_REQ MUST NOT be used in the second or third 986 EAP-Request/SIM/Start. AT_FULLAUTH_ID_REQ MUST NOT be used if the 987 previous EAP-Request/SIM/Start included AT_PERMANENT_ID_REQ. The 988 peer operation in cases when it receives an unexpected attribute or 989 an unexpected message is specified in Section 6.3.1. 991 4.2.6 Attacks against Identity Privacy 993 The section above specifies two possible ways the peer can operate 994 upon receipt of AT_PERMANENT_ID_REQ. This is because a received 995 AT_PERMANENT_ID_REQ does not necessarily originate from the valid 996 network, but an active attacker may transmit an EAP- 997 Request/SIM/Start packet with an AT_PERMANENT_ID_REQ attribute to the 998 peer, in an effort to find out the true identity of the user. If the 999 peer does not want to reveal its permanent identity, then the peer 1000 sends the EAP-Response/SIM/Client-Error packet with the error code 1001 "unable to process packet", and the authentication exchange 1002 terminates. 1004 Basically, there are two different policies that the peer can employ 1005 with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes 1006 that the network is able to maintain pseudonyms robustly. Therefore, 1007 if a conservative peer has a pseudonym username, the peer responds 1008 with EAP-Response/SIM/Client-Error to the EAP packet with 1009 AT_PERMANENT_ID_REQ, because the peer believes that the valid network 1010 is able to map the pseudonym identity to the peer's permanent 1011 identity. (Alternatively, the conservative peer may accept 1012 AT_PERMANENT_ID_REQ in certain circumstances, for example if the 1013 pseudonym was received a long time ago.) The benefit of this policy 1014 is that it protects the peer against active attacks on anonymity. On 1015 the other hand, a "liberal" peer always accepts the 1016 AT_PERMANENT_ID_REQ and responds with the permanent identity. The 1017 benefit of this policy is that it works even if the valid network 1018 sometimes loses pseudonyms and is not able to map them to the 1019 permanent identity. 1021 4.2.7 Processing of AT_IDENTITY by the Server 1023 When the server receives an EAP-Response/SIM/Start message with the 1024 AT_IDENTITY (in response to the server's identity requesting 1025 attribute), the server MUST operate as follows. 1027 If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does 1028 not contain a valid permanent identity, then the server sends 1029 EAP-Request/SIM/Notification with AT_NOTIFICATION code "General 1030 failure" (16384), and the EAP exchange terminates. If the server 1031 recognizes the permanent identity and is able to continue, then the 1032 server proceeds with full authentication by sending 1033 EAP-Request/SIM/Challenge. 1035 If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a 1036 valid permanent identity or a pseudonym identity that the server can 1037 map to a valid permanent identity, then the server proceeds with full 1038 authentication by sending EAP-Request/SIM/Challenge. If AT_IDENTITY 1039 contains a pseudonym identity that the server is not able to map to a 1040 valid permanent identity, or an identity that the server is not able 1041 to recognize or classify, then the server sends EAP-Request/SIM/Start 1042 with AT_PERMANENT_ID_REQ. 1044 If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a 1045 valid permanent identity or a pseudonym identity that the server can 1046 map to a valid permanent identity, then the server proceeds with full 1047 authentication by sending EAP-Request/SIM/Challenge. 1049 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid 1050 fast re-authentication identity and the server agrees on using 1051 re-authentication, then the server proceeds with fast 1052 re-authentication by sending EAP-Request/SIM/Re-authentication 1053 (Section 5). 1055 If the server used AT_ANY_ID_REQ, and if the peer sent an 1056 EAP-Response/SIM/Start with only AT_IDENTITY (indicating 1057 re-authentication), but the server is not able to map the identity to 1058 a permanent identity, then the server sends EAP-Request/SIM/Start 1059 with AT_FULLAUTH_ID_REQ. 1061 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid 1062 fast re-authentication identity, which the server is able to map to a 1063 permanent identity, and if the server does not want to use fast 1064 re-authentication, then the server sends EAP-Request/SIM/Start 1065 without any identity requesting attributes. 1067 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an 1068 identity that the server recognizes as a pseudonym identity but the 1069 server is not able to map the pseudonym identity to a permanent 1070 identity, then the server sends EAP-Request/SIM/Start with 1071 AT_PERMANENT_ID_REQ. 1073 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an 1074 identity that the server is not able to recognize or classify, then 1075 the server sends EAP-Request/SIM/Start with AT_FULLAUTH_ID_REQ. 1077 4.3 Message Sequence Examples (Informative) 1079 This section contains non-normative message sequence examples to 1080 illustrate how the peer identity can be communicated to the server. 1082 4.3.1 Full Authentication 1084 This case for full authentication is illustrated below in Figure 2. 1085 In this case, AT_IDENTITY contains either the permanent identity or a 1086 pseudonym identity. The same sequence is also used in case the 1087 server uses the AT_FULLAUTH_ID_REQ in EAP-Request/SIM/Start. 1089 Peer Authenticator 1090 | | 1091 | +------------------------------+ 1092 | | Server does not have any | 1093 | | Subscriber identity available| 1094 | | When starting EAP-SIM | 1095 | +------------------------------+ 1096 | | 1097 | EAP-Request/SIM/Start | 1098 | (AT_ANY_ID_REQ, AT_VERSION_LIST) | 1099 |<------------------------------------------------------| 1100 | | 1101 | | 1102 | EAP-Response/SIM/Start | 1103 | (AT_IDENTITY, AT_NONCE_MT, | 1104 | AT_SELECTED_VERSION) | 1105 |------------------------------------------------------>| 1106 | | 1108 Figure 2: Requesting any identity, full authentication 1110 If the peer uses its full authentication identity and the AT_IDENTITY 1111 attribute contains a valid permanent identity or a valid pseudonym 1112 identity that the EAP server is able to map to the permanent 1113 identity, then the full authentication sequence proceeds as usual 1114 with the EAP Server issuing the EAP-Request/SIM/Challenge message. 1116 4.3.2 Fast Re-authentication 1118 The case when the server uses the AT_ANY_ID_REQ and the peer wants to 1119 perform fast re-authentication is illustrated below in Figure 3. 1121 Peer Authenticator 1122 | | 1123 | +------------------------------+ 1124 | | Server does not have any | 1125 | | Subscriber identity available| 1126 | | When starting EAP-SIM | 1127 | +------------------------------+ 1128 | | 1129 | EAP-Request/SIM/Start | 1130 | (AT_ANY_ID_REQ, AT_VERSION_LIST) | 1131 |<------------------------------------------------------| 1132 | | 1133 | | 1134 | EAP-Response/SIM/Start | 1135 | (AT_IDENTITY containing a fast re-auth. identity) | 1136 |------------------------------------------------------>| 1137 | | 1139 Figure 3: Requesting any identity, fast re-authentication 1141 On fast re-authentication, if the AT_IDENTITY attribute contains a 1142 valid fast re-authentication identity and the server agrees on using 1143 fast re-authentication, then the server proceeds with the fast 1144 re-authentication sequence and issues the 1145 EAP-Request/SIM/Re-authentication packet, as specified in Section 5. 1147 4.3.3 Fall Back to Full Authentication 1149 The case when the server does not recognize the fast 1150 re-authentication identity the peer used in AT_IDENTITY, and issues a 1151 second EAP- Request/SIM/Start message is illustrated in Figure 4. 1153 Peer Authenticator 1154 | | 1155 | +------------------------------+ 1156 | | Server does not have any | 1157 | | Subscriber identity available| 1158 | | When starting EAP-SIM | 1159 | +------------------------------+ 1160 | | 1161 | EAP-Request/SIM/Start | 1162 | (AT_ANY_ID_REQ, AT_VERSION_LIST) | 1163 |<------------------------------------------------------| 1164 | | 1165 | | 1166 | EAP-Response/SIM/Start | 1167 | (AT_IDENTITY containing a fast re-auth. identity) | 1168 |------------------------------------------------------>| 1169 | | 1170 | +------------------------------+ 1171 | | Server does not recognize | 1172 | | The fast re-auth. | 1173 | | Identity | 1174 | +------------------------------+ 1175 | | 1176 | EAP-Request/SIM/Start | 1177 | (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) | 1178 |<------------------------------------------------------| 1179 | | 1180 | | 1181 | EAP-Response/SIM/Start | 1182 | (AT_IDENTITY with a full-auth. identity, AT_NONCE_MT, | 1183 | AT_SELECTED_VERSION) | 1184 |------------------------------------------------------>| 1185 | | 1187 Figure 4: Fall back to full authentication 1189 4.3.4 Requesting the Permanent Identity 1 1191 Figure 5 illustrates the case when the EAP server fails to map the 1192 pseudonym identity included in the EAP-Response/Identity packet to a 1193 valid permanent identity. 1195 Peer Authenticator 1196 | | 1197 | EAP-Request/Identity | 1198 |<------------------------------------------------------| 1199 | | 1200 | EAP-Response/Identity | 1201 | (Includes a pseudonym) | 1202 |------------------------------------------------------>| 1203 | | 1204 | +------------------------------+ 1205 | | Server fails to map the | 1206 | | Pseudonym to a permanent id. | 1207 | +------------------------------+ 1208 | EAP-Request/SIM/Start | 1209 | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) | 1210 |<------------------------------------------------------| 1211 | | 1212 | EAP-Response/SIM/Start | 1213 | (AT_IDENTITY with permanent identity, AT_NONCE_MT, | 1214 | AT_SELECTED_VERSION) | 1215 |------------------------------------------------------>| 1216 | | 1218 Figure 5: Requesting the permanent identity 1220 If the server recognizes the permanent identity, then the 1221 authentication sequence proceeds as usual with the EAP Server issuing 1222 the EAP-Request/SIM/Challenge message. 1224 4.3.5 Requesting the Permanent Identity 2 1226 Figure 6 illustrates the case when the EAP server fails to map the 1227 pseudonym included in the AT_IDENTITY attribute to a valid permanent 1228 identity. 1230 Peer Authenticator 1231 | | 1232 | +------------------------------+ 1233 | | Server does not have any | 1234 | | Subscriber identity available| 1235 | | When starting EAP-SIM | 1236 | +------------------------------+ 1237 | EAP-Request/SIM/Start | 1238 | (AT_ANY_ID_REQ, AT_VERSION_LIST) | 1239 |<------------------------------------------------------| 1240 | | 1241 |EAP-Response/SIM/Start | 1242 |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, | 1243 | AT_SELECTED_VERSION) | 1244 |------------------------------------------------------>| 1245 | +-------------------------------+ 1246 | | Server fails to map the | 1247 | | Pseudonym in AT_IDENTITY | 1248 | | to a valid permanent identity | 1249 | +-------------------------------+ 1250 | | 1251 | EAP-Request/SIM/Start | 1252 | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) | 1253 |<------------------------------------------------------| 1254 | | 1255 | EAP-Response/SIM/Start | 1256 | (AT_IDENTITY with permanent identity, | 1257 | AT_NONCE_MT, AT_SELECTED_VERSION) | 1258 |------------------------------------------------------>| 1259 | | 1261 Figure 6: Requesting a permanent identity (two EAP-SIM Start rounds) 1263 4.3.6 Three EAP-SIM/Start Roundtrips 1265 In the worst case, there are three EAP/SIM/Start round trips before 1266 the server has obtained an acceptable identity. This case is 1267 illustrated in Figure 7. 1269 Peer Authenticator 1270 | | 1271 | +------------------------------+ 1272 | | Server does not have any | 1273 | | Subscriber identity available| 1274 | | When starting EAP-SIM | 1275 | +------------------------------+ 1276 | EAP-Request/SIM/Start | 1277 | (Includes AT_ANY_ID_REQ, AT_VERSION_LIST) | 1278 |<------------------------------------------------------| 1279 | | 1280 | EAP-Response/SIM/Start | 1281 | (AT_IDENTITY with fast re-auth. identity) | 1282 |------------------------------------------------------>| 1283 | | 1284 | +------------------------------+ 1285 | | Server does not accept | 1286 | | The fast re-auth. | 1287 | | Identity | 1288 | +------------------------------+ 1289 | EAP-Request/SIM/Start | 1290 | (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) | 1291 |<------------------------------------------------------| 1292 | | 1293 : : 1294 : : 1296 : : 1297 : : 1298 |EAP-Response/SIM/Start | 1299 |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, | 1300 | AT_SELECTED_VERSION) | 1301 |------------------------------------------------------>| 1302 | | 1303 | +-------------------------------+ 1304 | | Server fails to map the | 1305 | | Pseudonym in AT_IDENTITY | 1306 | | to a valid permanent identity | 1307 | +-------------------------------+ 1308 | EAP-Request/SIM/Start | 1309 | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) | 1310 |<------------------------------------------------------| 1311 | | 1312 | EAP-Response/SIM/Start | 1313 | (AT_IDENTITY with permanent identity, AT_NONCE_MT, | 1314 | AT_SELECTED_VERSION) | 1315 |------------------------------------------------------>| 1316 | | 1318 Figure 7: Three EAP-SIM Start rounds 1320 After the last EAP-Response/SIM/Start message, the full 1321 authentication sequence proceeds as usual. If the EAP Server 1322 recognizes the permanent identity and is able to proceed, the server 1323 issues the EAP-Request/SIM/Challenge message. 1325 5. Fast Re-Authentication 1327 5.1 General 1329 In some environments, EAP authentication may be performed frequently. 1330 Because the EAP-SIM full authentication procedure makes use of the 1331 GSM SIM A3/A8 algorithms, and it therefore requires 2 or 3 fresh 1332 triplets from the Authentication Centre, the full authentication 1333 procedure is not very well suitable for frequent use. Therefore, 1334 EAP-SIM includes a more inexpensive fast re-authentication procedure 1335 that does not make use of the SIM A3/A8 algorithms and does not need 1336 new triplets from the Authentication Centre. Re-authentication can 1337 be performed in fewer roundtrips than the full authentication. 1339 Fast re-authentication is optional to implement for both the EAP-SIM 1340 server and peer. On each EAP authentication, either one of the 1341 entities may also fall back on full authentication if they do not 1342 want to use fast re-authentication. 1344 Fast re-authentication is based on the keys derived on the preceding 1345 full authentication. The same K_aut and K_encr keys as in full 1346 authentication are used to protect EAP-SIM packets and attributes, 1347 and the original Master Key from full authentication is used to 1348 generate a fresh Master Session Key, as specified in Section 6.4. 1350 The fast re-authentication exchange makes use of an unsigned 16-bit 1351 counter, included in the AT_COUNTER attribute. The counter has three 1352 goals: 1) it can be used to limit the number of successive 1353 reauthentication exchanges without full authentication 2) it 1354 contributes to the keying material, and 3) it protects the peer and 1355 the server from replays. On full authentication, both the server and 1356 the peer initialize the counter to one. The counter value of at 1357 least one is used on the first fast re-authentication. On subsequent 1358 fast re-authentications, the counter MUST be greater than on any of 1359 the previous re-authentications. For example, on the second fast 1360 re-authentication, counter value is two or greater etc. The 1361 AT_COUNTER attribute is encrypted. 1363 Both the peer and the EAP server maintain a copy of the counter. The 1364 EAP server sends its counter value to the peer in the fast 1365 re-authentication request. The peer MUST verify that its counter 1366 value is less than or equal to the value sent by the EAP server. 1368 The server includes an encrypted server random nonce (AT_NONCE_S) in 1369 the fast re-authentication request. The AT_MAC attribute in the 1370 peer's response is calculated over NONCE_S to provide a 1371 challenge/response authentication scheme. The NONCE_S also 1372 contributes to the new Master Session Key. 1374 Both the peer and the server SHOULD have an upper limit for the 1375 number of subsequent fast re-authentications allowed before a full 1376 authentication needs to be performed. Because a 16-bit counter is 1377 used in fast re-authentication, the theoretical maximum number of 1378 re-authentications is reached when the counter value reaches FFFF 1379 hexadecimal. 1381 In order to use fast re-authentication, the peer and the EAP server 1382 need to store the following values: Master Key, latest counter value 1383 and the next fast re-authentication identity. K_aut, K_encr may 1384 either be stored or derived again from MK. The server may also need 1385 to store the permanent identity of the user. 1387 5.2 Comparison to UMTS AKA 1389 When analyzing the fast re-authentication exchange, it may be helpful 1390 to compare it with the UMTS Authentication and Key Agreement (AKA) 1391 exchange, which it resembles closely. The counter corresponds to the 1392 UMTS AKA sequence number, NONCE_S corresponds to RAND, and AT_MAC in 1393 EAP-Request/SIM/Re-authentication corresponds to AUTN, the AT_MAC in 1394 EAP-Response/SIM/Re-authentication corresponds to RES, 1395 AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter 1396 corresponds to the usage of the Anonymity Key. Also the key 1397 generation on fast re-authentication with regard to random or fresh 1398 material is similar to UMTS AKA -- the server generates the NONCE_S 1399 and counter values, and the peer only verifies that the counter value 1400 is fresh. 1402 It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER or 1403 AT_COUNTER_TOO_SMALL attributes is not important to the security of 1404 the fast re-authentication exchange. 1406 5.3 Fast Re-authentication Identity 1408 The fast re-authentication procedure makes use of separate 1409 re-authentication user identities. Pseudonyms and the permanent 1410 identity are reserved for full authentication only. If a 1411 re-authentication identity is lost and the network does not recognize 1412 it, the EAP server can fall back on full authentication. 1414 If the EAP server supports fast re-authentication, it MAY include the 1415 skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of 1416 EAP-Request/SIM/Challenge message (Section 8.3). This attribute 1417 contains a new fast re-authentication identity for the next fast 1418 re-authentication. The attribute also works as a capability flag 1419 that indicates the fact that the server supports fast 1420 re-authentication, and that the server wants to continue using fast 1421 re-authentication within the current context. The peer MAY ignore 1422 this attribute, in which case it MUST use full authentication next 1423 time. If the peer wants to use re-authentication, it uses this fast 1424 re-authentication identity on next authentication. Even if the peer 1425 has a fast re-authentication identity, the peer MAY discard the fast 1426 re-authentication identity and use a pseudonym or the permanent 1427 identity instead, in which case full authentication MUST be 1428 performed. If the EAP server does not include the AT_NEXT_REAUTH_ID 1429 in the encrypted data of EAP-Request/SIM/Challenge or 1430 EAP-Request/SIM/Re-authentication, then the peer MUST discard its 1431 current fast re-authentication state information and perform a full 1432 authentication next time. 1434 In environments where a realm portion is needed in the peer identity, 1435 the fast re-authentication identity received in AT_NEXT_REAUTH_ID 1436 MUST contain both a username portion and a realm portion, as per the 1437 NAI format. The EAP Server can choose an appropriate realm part in 1438 order to have the AAA infrastructure route subsequent fast 1439 re-authentication related requests to the same AAA server. For 1440 example, the realm part MAY include a portion that is specific to the 1441 AAA server. Hence, it is sufficient to store the context required 1442 for fast re-authentication in the AAA server that performed the full 1443 authentication. 1445 The peer MAY use the fast re-authentication identity in the 1446 EAP-Response/Identity packet or, in response to server's 1447 AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication 1448 identity in the AT_IDENTITY attribute of the EAP-Response/SIM/Start 1449 packet. 1451 The peer MUST NOT modify the username portion of the fast 1452 re-authentication identity, but the peer MAY modify the realm portion 1453 or replace it with another realm portion. The peer might need to 1454 modify the realm in order to influence the AAA routing, for example 1455 to make sure that the correct server is reached. It should be noted 1456 that sharing the same fast re-authentication key among several 1457 servers may have security risks, so changing the realm portion of the 1458 NAI in order to change the EAP server is not desirable. 1460 Even if the peer uses a fast re-authentication identity, the server 1461 may want to fall back on full authentication, for example because the 1462 server does not recognize the fast re-authentication identity or does 1463 not want to use fast re-authentication. In this case, the server 1464 starts the full authentication procedure by issuing an 1465 EAP-Request/SIM/Start packet. This packet always starts a full 1466 authentication sequence if it does not include the AT_ANY_ID_REQ 1467 attribute. If the server was not able to recover the peer's identity 1468 from the fast re-authentication identity, the server includes either 1469 the AT_FULLAUTH_ID_REQ or the AT_PERMANENT_ID_REQ attribute in this 1470 EAP request. 1472 5.4 Fast Re-authentication Procedure 1474 Figure 8 illustrates the fast re-authentication procedure. In this 1475 example, the optional protected success indication is not used. 1476 Encrypted attributes are denoted with '*'. The peer uses its 1477 re-authentication identity in the EAP-Response/Identity packet. As 1478 discussed above, an alternative way to communicate the 1479 re-authentication identity to the server is for the peer to use the 1480 AT_IDENTITY attribute in the EAP-Response/SIM/Start message. This 1481 latter case is not illustrated in the figure below, and it is only 1482 possible when the server requests the peer to send its identity by 1483 including the AT_ANY_ID_REQ attribute in the EAP-Request/SIM/Start 1484 packet. 1486 If the server recognizes the identity as a valid fast 1487 re-authentication identity, and if the server agrees on using fast 1488 re-authentication, then the server sends the 1489 EAP-Request/SIM/Re-authentication packet to the peer. This packet 1490 MUST include the encrypted AT_COUNTER attribute, with a fresh counter 1491 value, the encrypted AT_NONCE_S attribute that contains a random 1492 number chosen by the server, the AT_ENCR_DATA and the AT_IV 1493 attributes used for encryption, and the AT_MAC attribute that 1494 contains a message authentication code over the packet. The packet 1495 MAY also include an encrypted AT_NEXT_REAUTH_ID attribute that 1496 contains the next fast re-authentication identity. 1498 Fast re-authentication identities are one-time identities. If the 1499 peer does not receive a new fast re-authentication identity, it MUST 1500 use either the permanent identity or a pseudonym identity on the next 1501 authentication to initiate full authentication. 1503 The peer verifies that AT_MAC is correct, and that the counter value 1504 is fresh (greater than any previously used value). The peer MAY save 1505 the next fast re-authentication identity from the encrypted 1506 AT_NEXT_REAUTH_ID for next time. If all checks are successful, the 1507 peer responds with the EAP-Response/SIM/Re-authentication packet, 1508 including the AT_COUNTER attribute with the same counter value and 1509 the AT_MAC attribute. 1511 The server verifies the AT_MAC attribute and also verifies that the 1512 counter value is the same that it used in the 1513 EAP-Request/SIM/Re-authentication packet. If these checks are 1514 successful, the re-authentication has succeeded and the server sends 1515 the EAP-Success packet to the peer. 1517 If protected success indications (Section 6.2) were used, the 1518 EAP-Success packet would be preceded by an EAP-SIM notification 1519 round. 1521 Peer Authenticator 1522 | | 1523 | EAP-Request/Identity | 1524 |<------------------------------------------------------| 1525 | | 1526 | EAP-Response/Identity | 1527 | (Includes a fast re-authentication identity) | 1528 |------------------------------------------------------>| 1529 | | 1530 | +--------------------------------+ 1531 | | Server recognizes the identity | 1532 | | and agrees on using fast | 1533 | | re-authentication | 1534 | +--------------------------------+ 1535 | | 1536 : : 1537 : : 1539 : : 1540 : : 1541 | EAP-Request/SIM/Re-authentication | 1542 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1543 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1544 |<------------------------------------------------------| 1545 | | 1546 +-----------------------------------------------+ | 1547 | Peer verifies AT_MAC and the freshness of | | 1548 | the counter. Peer MAY store the new fast re- | | 1549 | authentication identity for next re-auth. | | 1550 +-----------------------------------------------+ | 1551 | | 1552 | EAP-Response/SIM/Re-authentication | 1553 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, | 1554 | AT_MAC) | 1555 |------------------------------------------------------>| 1556 | +--------------------------------+ 1557 | | Server verifies AT_MAC and | 1558 | | the counter | 1559 | +--------------------------------+ 1560 | | 1561 | EAP-Success | 1562 |<------------------------------------------------------| 1563 | | 1565 Figure 8: Fast Re-authentication 1567 5.5 Fast Re-authentication Procedure when Counter is Too Small 1569 If the peer does not accept the counter value of 1570 EAP-Request/SIM/Re-authentication, it indicates the counter 1571 synchronization problem by including the encrypted 1572 AT_COUNTER_TOO_SMALL in EAP-Response/SIM/Re-authentication. The 1573 server responds with EAP-Request/SIM/Start to initiate a normal full 1574 authentication procedure. This is illustrated in Figure 9. 1575 Encrypted attributes are denoted with '*'. 1577 Peer Authenticator 1578 | EAP-Request/SIM/Start | 1579 | (AT_ANY_ID_REQ, AT_VERSION_LIST) | 1580 |<------------------------------------------------------| 1581 | | 1582 | EAP-Response/SIM/Start | 1583 | (AT_IDENTITY, AT_NONCE_MT | 1584 | AT_SELECTED_VERSION) | 1585 | (Includes a fast re-authentication identity) | 1586 |------------------------------------------------------>| 1587 | | 1588 | EAP-Request/SIM/Re-authentication | 1589 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1590 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1591 |<------------------------------------------------------| 1592 +-----------------------------------------------+ | 1593 | AT_MAC is valid but the counter is not fresh. | | 1594 +-----------------------------------------------+ | 1595 | | 1596 | EAP-Response/SIM/Re-authentication | 1597 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, | 1598 | *AT_COUNTER, AT_MAC) | 1599 |------------------------------------------------------>| 1600 | +----------------------------------------------+ 1601 | | Server verifies AT_MAC but detects | 1602 | | That peer has included AT_COUNTER_TOO_SMALL | 1603 | +----------------------------------------------+ 1604 | | 1605 | EAP-Request/SIM/Start | 1606 | (AT_VERSION_LIST) | 1607 |<------------------------------------------------------| 1608 +---------------------------------------------------------------+ 1609 | Normal full authentication follows. | 1610 +---------------------------------------------------------------+ 1611 | | 1613 Figure 9: Fast Re-authentication, counter is not fresh 1615 In the figure above, the first three messages are similar to the 1616 basic fast re-authentication case. When the peer detects that the 1617 counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL 1618 attribute in EAP-Response/SIM/Re-authentication. This attribute 1619 doesn't contain any data but it is a request for the server to 1620 initiate full authentication. In this case, the peer MUST ignore the 1621 contents of the server's AT_NEXT_REAUTH_ID attribute. 1623 On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and 1624 verifies that AT_COUNTER contains the same counter value as in the 1625 EAP-Request/SIM/Re-authentication packet. If not, the server 1626 terminates the authentication exchange by sending the 1627 EAP-Request/SIM/Notification with AT_NOTIFICATION code "General 1628 failure" (16384). If all checks on the packet are successful, the 1629 server transmits a new EAP-Request/SIM/Start packet and the full 1630 authentication procedure is performed as usual. Since the server 1631 already knows the subscriber identity, it MUST NOT include 1632 AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ in the 1633 EAP-Request/SIM/Start. 1635 It should be noted that in this case, peer identity is only 1636 transmitted in the AT_IDENTITY attribute at the beginning of the 1637 whole EAP exchange. The fast re-authentication identity used in this 1638 AT_IDENTITY attribute will be used in key derivation (see Section 1639 Section 6.4). 1641 6. EAP-SIM Notifications 1643 6.1 General 1645 EAP-SIM does not prohibit the use of the EAP Notifications as 1646 specified in [RFC3748]. EAP Notifications can be used at any time in 1647 the EAP-SIM exchange. It should be noted that EAP-SIM does not 1648 protect EAP Notifications. EAP-SIM also specifies method specific 1649 EAP-SIM notifications, which are protected in some cases. 1651 The EAP server can use EAP-SIM notifications to convey notifications 1652 and result indications (Section 6.2) to the peer. 1654 The server MUST use notifications in cases discussed in Section 1655 6.3.2. When the EAP server issues an EAP-Request/SIM/Notification 1656 packet to the peer, the peer MUST process the notification packet. 1657 The peer MAY show a notification message to the user and the peer 1658 MUST respond to the EAP server with an EAP-Response/SIM/Notification 1659 packet, even if the peer did not recognize the notification code. 1661 An EAP-SIM full authentication exchange or a fast re-authentication 1662 exchange MUST NOT include more than one EAP-SIM notification round. 1664 The notification code is a 16-bit number. The most significant bit 1665 is called the Success bit (S bit). The S bit specifies whether the 1666 notification implies failure. The code values with the S bit set to 1667 zero (code values 0...32767) are used on unsuccessful cases. The 1668 receipt of a notification code from this range implies failed EAP 1669 exchange, so the peer can use the notification as a failure 1670 indication. After receiving the EAP-Response/SIM/Notification for 1671 these notification codes, the server MUST send the EAP-Failure 1672 packet. 1674 The receipt of a notification code with the S bit set to one (values 1675 32768...65536) does not imply failure. Notification code "Success" 1676 (32768) has been reserved as a general notification code to indicate 1677 successful authentication. 1679 The second most significant bit of the notification code is called 1680 the Phase bit (P bit). It specifies at which phase of the EAP-SIM 1681 exchange the notification can be used. If the P bit is set to zero, 1682 the notification can only be used after a successful 1683 EAP/SIM/Challenge round in full authentication or a successful 1684 EAP/SIM/Re-authentication round in reautentication. A 1685 re-authentication round is considered successful only if the peer has 1686 successfully verified AT_MAC and AT_COUNTER attributes, and does not 1687 include the AT_COUNTER_TOO_SMALL attribute in 1688 EAP-Response/SIM/Re-authentication. 1690 If the P bit is set to one, the notification can only by used before 1691 the EAP/SIM/Challenge round in full authentication, or before the 1692 EAP/SIM/Re-authentication round in reauthentication. These 1693 notifications can only be used to indicate various failure cases. In 1694 other words, if the P bit is set to one, then the S bit MUST be set 1695 to zero. 1697 Section 8.8 and Section 8.9 specify what other attributes must be 1698 included in the notification packets. 1700 Some of the notification codes are authorization related and hence 1701 not usually considered as part of the responsibility of an EAP 1702 method. However, they are included as part of EAP-SIM because there 1703 are currently no other ways to convey this information to the user in 1704 a localizable way, and the information is potentially useful for the 1705 user. An EAP-SIM server implementation may decide never to send 1706 these EAP-SIM notifications. 1708 6.2 Result Indications 1710 As discussed in Section 6.3, the server and the peer use explicit 1711 error messages in all error cases. If the server detects an error 1712 after successful authentication, the server uses an EAP-SIM 1713 notification to indicate failure to the peer. In this case, the 1714 result indication is integrity and replay protected. 1716 By sending an EAP-Response/SIM/Challenge packet or an 1717 EAP-Response/SIM/Re-authentication packet (without 1718 AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully 1719 authenticated the server and that the peer's local policy accepts the 1720 EAP exchange. In other words, these packets are implicit success 1721 indications from the peer to the server. 1723 EAP-SIM also supports optional protected success indications from the 1724 server to the peer. If the EAP server wants to use protected success 1725 indications, it includes the AT_RESULT_IND attribute in the 1726 EAP-Request/SIM/Challenge or the EAP-Request/SIM/Re-authentication 1727 packet. This attribute indicates that the EAP server would like to 1728 use result indications in both successful and unsuccessful cases. If 1729 the peer also wants this, the peer includes AT_RESULT_IND in 1730 EAP-Response/SIM/Challenge or EAP-Response/SIM/Re-authentication. 1731 The peer MUST NOT include AT_RESULT_IND if it did not receive 1732 AT_RESULT_IND from the server. If both the peer and the server used 1733 AT_RESULT_IND, then the EAP exchange is not complete yet, but an 1734 EAP-SIM notification round will follow. The following EAP-SIM 1735 notification may indicate either failure or success. 1737 Success indications with the AT_NOTIFICATION code "Success" (32768) 1738 can only be used if both the server and the peer indicate they want 1739 to use them with AT_RESULT_IND. If the server did not include 1740 AT_RESULT_IND in the EAP-Request/SIM/Challenge or 1741 EAP-Request/SIM/Re-authentication packet, or if the peer did not 1742 include AT_RESULT_IND in the corresponding response packet, then the 1743 server MUST NOT use protected success indications. 1745 Because the server uses the AT_NOTIFICATION code "Success" (32768) to 1746 indicate that the EAP exchange has completed successfully, the EAP 1747 exchange cannot fail when the server processes the EAP-SIM response 1748 to this notification. Hence, the server MUST ignore the contents of 1749 the EAP-SIM response it receives to the EAP-Request/SIM/Notification 1750 with this code. Regardless of the contents of the EAP-SIM response, 1751 the server MUST send EAP-Success as the next packet. 1753 6.3 Error Cases 1755 This section specifies the operation of the peer and the server in 1756 error cases. The subsections below require the EAP-SIM peer and 1757 server to send an error packet (EAP-Response/SIM/Client-Error from 1758 the peer or EAP-Request/SIM/Notification from the server) in error 1759 cases. However, implementations SHOULD NOT rely upon the correct 1760 error reporting behavior of the peer, authenticator, or the server. 1761 It is possible for error and other messages to be lost in transit or 1762 for a malicious participant to attempt to consume resources by not 1763 issuing error messages. Both the peer and the EAP server SHOULD have 1764 a mechanism to clean up state even if an error message or EAP-Success 1765 is not received after a timeout period. 1767 6.3.1 Peer Operation 1769 In general, if an EAP-SIM peer detects an error in a received EAP-SIM 1770 packet, the EAP-SIM implementation responds with the 1771 EAP-Response/SIM/Client-Error packet. In response to the 1772 EAP-Response/SIM/Client-Error, the EAP server MUST issue the 1773 EAP-Failure packet and the authentication exchange terminates. 1775 By default, the peer uses the client error code 0, "unable to process 1776 packet". This error code is used in the following cases: 1778 o EAP exchange is not acceptable according to the peer's local 1779 policy. 1780 o the peer is not able to parse the EAP request, i.e. the EAP 1781 request is malformed 1782 o the peer encountered a malformed attribute 1783 o wrong attribute types or duplicate attributes have been included 1784 in the EAP request 1785 o a mandatory attribute is missing 1786 o unrecognized non-skippable attribute 1787 o unrecognized or unexpected EAP-SIM Subtype in the EAP request 1788 o A RAND challenge repeated in AT_RAND 1789 o invalid AT_MAC. The peer SHOULD log this event. 1790 o invalid pad bytes in AT_PADDING 1791 o the peer does not want to process AT_PERMANENT_ID_REQ 1793 Separate error codes have been defined for the following error cases 1794 in Section 9.19: 1796 As specified in Section 4.1, when processing the AT_VERSION_LIST 1797 attribute, which lists the EAP-SIM versions supported by the server, 1798 if the attribute does not include a version that is implemented by 1799 the peer and allowed in the peer's security policy, then the peer 1800 MUST send the EAP-Response/SIM/Client-Error packet with the error 1801 code "unsupported version". 1803 When processing the AT_RAND attribute, the peer MUST send the EAP- 1804 Response/SIM/Client-Error packet with the error code "insufficient 1805 number of challenges", if the number of RAND challenges is smaller 1806 than what is required by peer's local policy. 1808 If the peer believes that the RAND challenges included in AT_RAND are 1809 not fresh e.g. because it is capable of remembering some previously 1810 used RANDs, the peer MUST send the EAP-Response/SIM/Client-Error 1811 packet with the error code "RANDs are not fresh". 1813 6.3.2 Server Operation 1815 If an EAP-SIM server detects an error in a received EAP-SIM response, 1816 the server MUST issue the EAP-Request/SIM/Notification packet with an 1817 AT_NOTIFICATION code that implies failure. By default, the server 1818 uses one of the general failure codes ("General failure after 1819 authentication" (0), or "General failure" (16384)). The choice 1820 between these two codes depends on the phase of the EAP-SIM exchange, 1821 see Section 6. The error cases when the server issues an 1822 EAP-Request/SIM/Notification that implies failure include the 1823 following: 1825 o the server is not able to parse the peer's EAP response 1826 o the server encounters a malformed attribute, a non-recognized 1827 non-skippable attribute, or a duplicate attribute 1828 o a mandatory attribute is missing or an invalid attribute was 1829 included 1830 o unrecognized or unexpected EAP-SIM Subtype in the EAP Response 1831 o invalid AT_MAC. The server SHOULD log this event. 1832 o invalid AT_COUNTER 1834 6.3.3 EAP-Failure 1836 The EAP-SIM server sends EAP-Failure in two cases: 1838 1) In response to an EAP-Response/SIM/Client-Error packet the server 1839 has received from the peer, or 1841 2) Following an EAP-SIM notification round, when the AT_NOTIFICATION 1842 code implies failure. 1844 The EAP-SIM server MUST NOT send EAP-Failure in other cases than 1845 these two. However, it should be noted that even though the EAP-SIM 1846 server would not send an EAP-Failure, an authorization decision that 1847 happens outside EAP-SIM, such as in the AAA server or in an 1848 intermediate AAA proxy, may result in a failed exchange. 1850 The peer MUST accept the EAP-Failure packet in case 1) and case 2) 1851 above. The peer SHOULD silently discard the EAP-Failure packet in 1852 other cases. 1854 6.3.4 EAP-Success 1856 On full authentication, the server can only send EAP-Success after 1857 the EAP/SIM/Challenge round. The peer MUST silently discard any 1858 EAP-Success packets if they are received before the peer has 1859 successfully authenticated the server and sent the 1860 EAP-Response/SIM/Challenge packet. 1862 If the peer did not indicate that it wants to use protected success 1863 indications with AT_RESULT_IND (as discussed in Section 6.2) on full 1864 authentication, then the peer MUST accept EAP-Success after a 1865 successful EAP/SIM/Challenge round. 1867 If the peer indicated that it wants to use protected success 1868 indications with AT_RESULT_IND (as discussed in Section 6.2), then 1869 the peer MUST NOT accept EAP-Success after a successful 1870 EAP/SIM/Challenge round. In this case, the peer MUST only accept 1871 EAP-Success after receiving an EAP-SIM Notification with the 1872 AT_NOTIFICATION code "Success" (32768). 1874 On fast re-authentication, EAP-Success can only be sent after the 1875 EAP/SIM/Re-authentication round. The peer MUST silently discard any 1876 EAP-Success packets if they are received before the peer has 1877 successfully authenticated the server and sent the 1878 EAP-Response/SIM/Re-authentication packet. 1880 If the peer did not indicate that it wants to use protected success 1881 indications with AT_RESULT_IND (as discussed in Section 6.2) on fast 1882 re-authentication, then the peer MUST accept EAP-Success after a 1883 successful EAP/SIM/Re-authentication round. 1885 If the peer indicated that it wants to use protected success 1886 indications with AT_RESULT_IND (as discussed in Section 6.2), then 1887 the peer MUST NOT accept EAP-Success after a successful 1888 EAP/SIM/Re-authentication round. In this case, the peer MUST only 1889 accept EAP-Success after receiving an EAP-SIM Notification with the 1890 AT_NOTIFICATION code "Success" (32768). 1892 If the peer receives an EAP-SIM notification (Section 6) that 1893 indicates failure, then the peer MUST no longer accept the 1894 EAP-Success packet even if the server authentication was successfully 1895 completed. 1897 6.4 Key Generation 1899 This section specifies how keying material is generated. 1901 On EAP-SIM full authentication, a Master Key (MK) is derived from the 1902 underlying GSM authentication values (Kc keys), the NONCE_MT and 1903 other relevant context as follows. 1905 MK = SHA1(Identity|n*Kc| NONCE_MT| Version List| Selected Version) 1907 In the formula above, the "|" character denotes concatenation. 1908 Identity denotes the peer identity string without any terminating 1909 null characters. It is the identity from the last AT_IDENTITY 1910 attribute sent by the peer in this exchange, or, if AT_IDENTITY was 1911 not used, the identity from the EAP-Response/Identity packet. The 1912 identity string is included as-is, without any changes. As discussed 1913 in Section 4.2.2.2, relying on EAP-Response/Identity for conveying 1914 the EAP-SIM peer identity is discouraged, and the server SHOULD use 1915 the EAP-SIM method specific identity attributes. 1917 The notation n*Kc in the formula above denotes the n Kc values 1918 concatenated. The Kc keys are used in the same order as the RAND 1919 challenges in AT_RAND attribute. NONCE_MT denotes the NONCE_MT value 1920 (not the AT_NONCE_MT attribute but just the nonce value). The 1921 Version List includes the 2-byte supported version numbers from 1922 AT_VERSION_LIST, in the same order as in the attribute. The Selected 1923 Version is the 2-byte selected version from AT_SELECTED_VERSION. 1924 Network byte order is used, just as in the attributes. The hash 1925 function SHA-1 is specified in [SHA-1]. If several EAP/SIM/Start 1926 roundtrips are used in an EAP-SIM exchange, then the NONCE_MT, 1927 Version List and Selected version from the last EAP/SIM/Start round 1928 are used, and the previous EAP/SIM/Start rounds are ignored. 1930 The Master Key is fed into a Pseudo-Random number Function (PRF) 1931 which generates separate Transient EAP Keys (TEKs) for protecting 1932 EAP-SIM packets, as well as a Master Session Key (MSK) for link layer 1933 security and an Extended Master Session Key (EMSK) for other 1934 purposes. On fast re-authentication, the same TEKs MUST be used for 1935 protecting EAP packets, but a new MSK and a new EMSK MUST be derived 1936 from the original MK and new values exchanged in the fast 1937 re-authentication. 1939 EAP-SIM requires two TEKs for its own purposes, the authentication 1940 key K_aut to be used with the AT_MAC attribute, and the encryption 1941 key K_encr, to be used with the AT_ENCR_DATA attribute. The same 1942 K_aut and K_encr keys are used in full authentication and subsequent 1943 fast re-authentications. 1945 Key derivation is based on the random number generation specified in 1946 NIST Federal Information Processing Standards (FIPS) Publication 1947 186-2 [PRF]. The pseudo-random number generator is specified in the 1948 change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As 1949 specified in the change notice (page 74), when Algorithm 1 is used as 1950 a general-purpose pseudo-random number generator, the "mod q" term in 1951 step 3.3 is omitted. The function G used in the algorithm is 1952 constructed via Secure Hash Standard as specified in Appendix 3.3 of 1953 the standard. It should be noted that the function G is very similar 1954 to SHA-1, but the message padding is different. Please refer to 1955 [PRF] for full details. For convenience, the random number algorithm 1956 with the correct modification is cited in Appendix B. 1958 160-bit XKEY and XVAL values are used, so b = 160. On each full 1959 authentication, the Master Key is used as the initial secret seed-key 1960 XKEY. The optional user input values (XSEED_j) in step 3.1 are set 1961 to zero. 1963 On full authentication, the resulting 320-bit random numbers x_0, 1964 x_1, ..., x_m-1 are concatenated and partitioned into suitable-sized 1965 chunks and used as keys in the following order: K_encr (128 bits), 1966 K_aut (128 bits), Master Session Key (64 bytes), Extended Master 1967 Session Key (64 bytes). 1969 On fast re-authentication, the same pseudo-random number generator 1970 can be used to generate a new Master Session Key and a new Extended 1971 Master Session Key. The seed value XKEY' is calculated as follows: 1973 XKEY' = SHA1(Identity|counter|NONCE_S| MK) 1975 In the formula above, the Identity denotes the fast re-authentication 1976 identity, without any terminating null characters, from the 1977 AT_IDENTITY attribute of the EAP-Response/SIM/Start packet, or, if 1978 EAP-Response/SIM/Start was not used on fast re-authentication, the 1979 identity string from the EAP-Response/Identity packet. The counter 1980 denotes the counter value from AT_COUNTER attribute used in the 1981 EAP-Response/SIM/Re-authentication packet. The counter is used in 1982 network byte order. NONCE_S denotes the 16-byte NONCE_S value from 1983 the AT_NONCE_S attribute used in the 1984 EAP-Request/SIM/Re-authentication packet. The MK is the Master Key 1985 derived on the preceding full authentication. 1987 On fast re-authentication, the pseudo-random number generator is run 1988 with the new seed value XKEY', and the resulting 320-bit random 1989 numbers x_0, x_1, ..., x_m-1 are concatenated and partitioned into 1990 two 64-byte chunks and used as the new 64-byte Master Session Key and 1991 the new 64-byte Extended Master Session Key. Note that because 1992 K_encr and K_aut are not derived on fast re-authentication, the 1993 Master Session Key and the Extended Master Session key are obtained 1994 from the beginning of the key stream x_0, x_1, .... 1996 The first 32 bytes of the MSK can be used as the Pairwise Master Key 1997 (PMK) for IEEE 802.11i. 1999 When the RADIUS attributes specified in [RFC2548] are used to 2000 transport keying material, then the first 32 bytes of the MSK 2001 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to 2002 MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material 2003 (the MSK) are used. 2005 When generating the initial Master Key, the hash function is used as 2006 a mixing function to combine several session keys (Kc's) generated by 2007 the GSM authentication procedure and the random number NONCE_MT into 2008 a single session key. There are several reasons for this. The 2009 current GSM session keys are at most 64 bits, so two or more of them 2010 are needed to generate a longer key. By using a one-way function to 2011 combine the keys, we are assured that even if an attacker managed to 2012 learn one of the EAP-SIM session keys, it wouldn't help him in 2013 learning the original GSM Kc's. In addition, since we include the 2014 random number NONCE_MT in the calculation, the peer is able to verify 2015 that the EAP-SIM packets it receives from the network are fresh and 2016 not a replay. (Please see also Section 11.) 2018 7. Message Format and Protocol Extensibility 2020 7.1 Message Format 2022 As specified in [RFC3748], EAP packets begin with the Code, 2023 Identifiers, Length, and Type fields, which are followed by EAP 2024 method specific Type-Data. The Code field in the EAP header is set 2025 to 1 for EAP requests, and to 2 for EAP Responses. The usage of the 2026 Length and Identifier fields in the EAP header are also specified in 2027 [RFC3748]. In EAP-SIM, the Type field is set to 18. 2029 In EAP-SIM, the Type-Data begins with an EAP-SIM header that consists 2030 of a 1-octet Subtype field and a 2-octet reserved field. The Subtype 2031 values used in EAP-SIM are defined in the IANA considerations section 2032 of the EAP-AKA specification [EAP-AKA]. The formats of the EAP 2033 header and the EAP-SIM header are shown below. 2035 0 1 2 3 2036 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 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | Code | Identifier | Length | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | Type | Subtype | Reserved | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 The rest of the Type-Data, immediately following the EAP-SIM header, 2044 consists of attributes that are encoded in Type, Length, Value 2045 format. The figure below shows the generic format of an attribute. 2047 0 1 2 3 2048 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 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | Type | Length | Value... 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 Attribute Type 2055 Indicates the particular type of attribute. The attribute type 2056 values are listed in the IANA considerations section of the 2057 EAP-AKA specification. 2059 [EAP-AKA] 2061 Length 2063 Indicates the length of this attribute in multiples of four 2064 bytes. The maximum length of an attribute is 1024 bytes. The 2065 length includes the Attribute Type and Length bytes. 2067 Value 2069 The particular data associated with this attribute. This field 2070 is always included and it may be two or more bytes in length. 2071 The type and length fields determine the format and length 2072 of the value field. 2074 Attributes numbered within the range 0 through 127 are called 2075 non-skippable attributes. When an EAP-SIM peer encounters a 2076 non-skippable attribute that the peer does not recognize, the peer 2077 MUST send the EAP-Response/SIM/Client-Error packet which terminates 2078 the authentication exchange. If an EAP-SIM server encounters a 2079 non-skippable attribute that the server does not recognize, then the 2080 server sends the EAP-Request/SIM/Notification packet with an 2081 AT_NOTIFICATION code that implies general failure ("General failure 2082 after authentication" (0), or "General failure" (16384), depending on 2083 the phase of the exchange), which terminates the authentication 2084 exchange. 2086 Attributes within the range of 128 through 255 are called skippable 2087 attributes. When a skippable attribute is encountered that is not 2088 recognized it is ignored. The rest of the attributes and message 2089 data MUST still be processed. The Length field of the attribute is 2090 used to skip the attribute value in searching for the next attribute. 2092 Unless otherwise specified, the order of the attributes in an EAP-SIM 2093 message is insignificant and an EAP-SIM implementation should not 2094 assume a certain order to be used. 2096 Attributes can be encapsulated within other attributes. In other 2097 words, the value field of an attribute type can be specified to 2098 contain other attributes. 2100 7.2 Protocol Extensibility 2102 EAP-SIM can be extended by specifying new attribute types. If 2103 skippable attributes are used, it is possible to extend the protocol 2104 without breaking old implementations. 2106 However, any new attributes added to the EAP-Request/SIM/Start or 2107 EAP-Response/SIM/Start packets would not be integrity protected. 2108 Therefore, these messages MUST NOT be extended in the current version 2109 of EAP-SIM. If the list of supported EAP-SIM versions in 2110 AT_VERSION_LIST does not include other versions than 1, then the 2111 server MUST NOT include other attributes besides those specified in 2112 this document in the EAP-Request/SIM/Start message. Note that future 2113 versions of this protocol might specify new attributes for 2114 EAP-Request/SIM/Start and still support version 1 of the protocol. 2115 In this case, the server might send an EAP-Request/SIM/Start message 2116 that includes new attributes, and indicate support for protocol 2117 version 1 and some other version in the AT_VERSION_LIST attribute. 2118 If the peer selects version 1, then the peer MUST ignore any other 2119 attributes included in EAP-Request/SIM/Start besides those specified 2120 in this document. If the selected EAP-SIM version in peer's 2121 AT_SELECTED_VERSION is 1, then the peer MUST NOT include other 2122 attributes besides those specified in this document in the 2123 EAP-Response/SIM/Start message. 2125 When specifying new attributes, it should be noted that EAP-SIM does 2126 not support message fragmentation. Hence, the sizes of the new 2127 extensions MUST be limited so that the maximum transfer unit (MTU) of 2128 the underlying lower layer is not exceeded. According to [RFC3748], 2129 lower layers must provide an EAP MTU of 1020 bytes or greater, so any 2130 extensions to EAP-SIM SHOULD NOT exceed the EAP MTU of 1020 bytes. 2132 Because EAP-SIM supports version negotiation, new versions of the 2133 protocol can also be specified by using a new version number. 2135 8. Messages 2137 This section specifies the messages used in EAP-SIM. It specifies 2138 when a message may be transmitted or accepted, which attributes are 2139 allowed in a message, which attributes are required in a message, and 2140 other message specific details. The general message format is 2141 specified in Section 7.1. 2143 8.1 EAP-Request/SIM/Start 2145 In full authentication the first SIM specific EAP Request is EAP- 2146 Request/SIM/Start. The EAP/SIM/Start roundtrip is used for two 2147 purposes. In full authentication this packet is used to request the 2148 peer to send the AT_NONCE_MT attribute to the server. In addition, 2149 as specified in Section 4.2, the Start round trip may be used by the 2150 server for obtaining the peer identity. As discussed in Section 4.2, 2151 several Start rounds may be required in order to obtain a valid peer 2152 identity. 2154 The server MUST always include the AT_VERSION_LIST attribute. 2156 The server MAY include one of the following identity requesting 2157 attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, and 2158 AT_ANY_ID_REQ. These three attributes are mutually exclusive, so the 2159 server MUST NOT include more than one of the attributes. 2161 If the server has received a response from the peer, it MUST NOT 2162 issue a new EAP-Request/SIM/Start packet if it has either previously 2163 issued an EAP-Request/SIM/Start message without any identity 2164 requesting attributes or with the AT_PERMANENT_ID_REQ attribute. 2166 If the server has received a response from the peer, it MUST NOT 2167 issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ or 2168 AT_FULLAUTH_ID_REQ attributes if it has previously issued an 2169 EAP-Request/SIM/Start message with the AT_FULLAUTH_ID_REQ attribute 2171 If the server has received a response from the peer, it MUST NOT 2172 issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ 2173 attribute if the server has previously issued an 2174 EAP-Request/SIM/Start message with the AT_ANY_ID_REQ attribute. 2176 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. 2178 8.2 EAP-Response/SIM/Start 2180 The peer sends EAP-Response/SIM/Start in response to a valid 2181 EAP-Request/SIM/Start from the server. 2183 If and only if the server's EAP-Request/SIM/Start includes one of the 2184 identity requesting attributes, then the peer MUST include the 2185 AT_IDENTITY attribute. The usage of AT_IDENITY is defined in Section 2186 4.2. 2188 The AT_NONCE_MT attribute MUST NOT be included if the AT_IDENTITY 2189 with a fast re-authentication identity is present for fast 2190 re-authentication. AT_NONCE_MT MUST be included in all other cases 2191 (full authentication). 2193 The AT_SELECTED_VERSION attribute MUST NOT be included if the 2194 AT_IDENTITY attribute with a fast re-authentication identity is 2195 present for fast re-authentication. In all other cases, 2196 AT_SELECTED_VERSION MUST be included (full authentication). This 2197 attribute is used in version negotiation, as specified in Section 2198 4.1. 2200 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. 2202 8.3 EAP-Request/SIM/Challenge 2204 The server sends the EAP-Request/SIM/Challenge after receiving a 2205 valid EAP-Response/SIM/Start, containing AT_NONCE_MT and 2206 AT_SELECTED_VERSION, and after successfully obtaining the subscriber 2207 identity. 2209 The AT_RAND attribute MUST be included. 2211 The AT_RESULT_IND attribute MAY be included. The usage of this 2212 attribute is discussed in Section 6.2. 2214 The AT_MAC attribute MUST be included. For 2215 EAP-Request/SIM/Challenge, the MAC code is calculated over the 2216 following data: 2218 EAP packet| NONCE_MT 2220 The EAP packet is represented as specified in Section 7.1. It is 2221 followed by the 16-byte NONCE_MT value from the peer's AT_NONCE_MT 2222 attribute. 2224 The EAP-Request/SIM/Challenge packet MAY include encrypted attributes 2225 for identity privacy and for communicating the next fast 2226 re-authentication identity. In this case, the AT_IV and AT_ENCR_DATA 2227 attributes are included (Section 9.12). 2229 The plaintext of the AT_ENCR_DATA value field consists of nested 2230 attributes. The nested attributes MAY include AT_PADDING (as 2231 specified in Section 9.12). If the server supports identity privacy 2232 and wants to communicate a pseudonym to the peer for the next full 2233 authentication, then the nested encrypted attributes include the 2234 AT_NEXT_PSEUDONYM attribute. If the server supports 2235 re-authentication and wants to communicate a fast re-authentication 2236 identity to the peer, then the nested encrypted attributes include 2237 the AT_NEXT_REAUTH_ID attribute. 2239 When processing this message, the peer MUST process AT_RAND before 2240 processing other attributes. Only if AT_RAND is verified to be 2241 valid, the peer derives keys and verifies AT_MAC. The operation in 2242 case an error occurs is specified in Section 6.3.1. 2244 8.4 EAP-Response/SIM/Challenge 2246 The peer sends EAP-Response/SIM/Challenge in response to a valid 2247 EAP-Request/SIM/Challenge. 2249 Sending this packet indicates, that the peer has successfully 2250 authenticated the server and that the EAP exchange will be accepted 2251 by the peer's local policy. Hence, if these conditions are not met, 2252 then the peer MUST NOT send EAP-Response/SIM/Challenge, but the peer 2253 MUST send EAP-Response/SIM/Client-Error. 2255 The AT_MAC attribute MUST be included. For EAP- 2256 Response/SIM/Challenge, the MAC code is calculated over the following 2257 data: 2259 EAP packet| n*SRES 2261 The EAP packet is represented as specified in Section 7.1. The EAP 2262 packet bytes are immediately followed by the two or three SRES values 2263 concatenated, denoted above with the notation n*SRES. The SRES 2264 values are used in the same order as the corresponding RAND 2265 challenges in server's AT_RAND attribute. 2267 The AT_RESULT_IND attribute MAY be included, if it was included in 2268 EAP-Request/SIM/Challenge. The usage of this attribute is discussed 2269 in Section 6.2. 2271 Later versions of this protocol MAY make use of the AT_ENCR_DATA and 2272 AT_IV attributes in this message to include encrypted (skippable) 2273 attributes. The EAP server MUST process EAP-Response/SIM/Challenge 2274 messages that include these attributes even if the server did not 2275 implement these optional attributes. 2277 8.5 EAP-Request/SIM/Re-authentication 2279 The server sends the EAP-Request/SIM/Re-authentication message if it 2280 wants to use fast re-authentication, and if it has received a valid 2281 fast re-authentication identity in EAP-Response/Identity or 2282 EAP-Response/SIM/Start. 2284 AT_MAC MUST be included. No message-specific data is included in the 2285 MAC calculation. See Section 9.14. 2287 The AT_RESULT_IND attribute MAY be included. The usage of this 2288 attribute is discussed in Section 6.2. 2290 The AT_IV and AT_ENCR_DATA attributes MUST be included. The 2291 plaintext consists of the following nested encrypted attributes, 2292 which MUST be included: AT_COUNTER and AT_NONCE_S. In addition, the 2293 nested encrypted attributes MAY include the following attributes: 2294 AT_NEXT_REAUTH_ID and AT_PADDING. 2296 8.6 EAP-Response/SIM/Re-authentication 2298 The client sends the EAP-Response/SIM/Re-authentication packet in 2299 response to a valid EAP-Request/SIM/Re-authentication. 2301 The AT_MAC attribute MUST be included. For 2302 EAP-Response/SIM/Re-authentication, the MAC code is calculated over 2303 the following data: 2305 EAP packet| NONCE_S 2307 The EAP packet is represented as specified in Section 7.1. It is 2308 followed by the 16-byte NONCE_S value from the server's AT_NONCE_S 2309 attribute. 2311 The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested 2312 encrypted attributes MUST include the AT_COUNTER attribute. The 2313 AT_COUNTER_TOO_SMALL attribute MAY be included in the nested 2314 encrypted attributes, and it is included in cases specified in 2315 Section 5. The AT_PADDING attribute MAY be included. 2317 The AT_RESULT_IND attribute MAY be included, if it was included in 2318 EAP-Request/SIM/Re-authentication. The usage of this attribute is 2319 discussed in Section 6.2. 2321 Sending this packet without AT_COUNTER_TOO_SMALL indicates, that the 2322 peer has successfully authenticated the server and that the EAP 2323 exchange will be accepted by the peer's local policy. Hence, if 2324 these conditions are not met, then the peer MUST NOT send 2325 EAP-Response/SIM/Re-authentication, but the peer MUST send 2326 EAP-Response/SIM/Client-Error. 2328 8.7 EAP-Response/SIM/Client-Error 2330 The peer sends EAP-Response/SIM/Client-Error in error cases, as 2331 specified in Section 6.3.1. 2333 The AT_CLIENT_ERROR_CODE attribute MUST be included. 2335 The AT_MAC, AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with 2336 this packet. 2338 8.8 EAP-Request/SIM/Notification 2340 The usage of this message is specified in Section 6. 2342 The AT_NOTIFICATION attribute MUST be included. 2344 The AT_MAC attribute MUST beincluded if the P bit of the notification 2345 code in AT_NOTIFICATION is set to zero, and MUST NOT be included in 2346 cases when the P bit is set to one. The P bit is discussed in 2347 Section 6. 2349 No message-specific data is included in the MAC calculation. See 2350 Section 9.14. 2352 If EAP-Request/SIM/Notification is used on fast a re-authentication 2353 exchange, and if the P bit in AT_NOTIFICATION is set to zero, then 2354 AT_COUNTER is used for replay protection. In this case, the 2355 AT_ENCR_DATA and AT_IV attributes MUST be included, and the 2356 encapsulated plaintext attributes MUST include the AT_COUNTER 2357 attribute. The counter value included in AT_COUNTER MUST be the same 2358 as in the EAP-Request/SIM/Re-authentication packet on the same fast 2359 re-authentication exchange. 2361 8.9 EAP-Response/SIM/Notification 2363 The usage of this message is specified in Section 6. This packet is 2364 an acknowledgement of EAP-Request/SIM/Notification. 2366 The AT_MAC attribute MUST included in cases when the P bit of the 2367 notification code in AT_NOTIFICATION of EAP-Request/SIM/Notification 2368 is set to zero, and MUST NOT be included in cases when the P bit is 2369 set to one. The P bit is discussed in Section 6. 2371 No message-specific data is included in the MAC calculation, see 2372 Section 9.14. 2374 If EAP-Request/SIM/Notification is used on fast a re-authentication 2375 exchange, and if the P bit in AT_NOTIFICATION is set to zero, then 2376 AT_COUNTER is used for replay protection. In this case, the 2377 AT_ENCR_DATA and AT_IV attributes MUST be included, and the 2378 encapsulated plaintext attributes MUST include the AT_COUNTER 2379 attribute. The counter value included in AT_COUNTER MUST be the same 2380 as in the EAP-Request/SIM/Re-authentication packet on the same fast 2381 re-authentication exchange. 2383 9. Attributes 2385 This section specifies the format of message attributes. The 2386 attribute type numbers are specified in the IANA considerations 2387 section of the EAP-AKA specification [EAP-AKA]. 2389 9.1 Table of Attributes 2391 The following table provides a guide to which attributes may be found 2392 in which kinds of messages, and in what quantity. Messages are 2393 denoted with numbers in parentheses as follows: (1) 2394 EAP-Request/SIM/Start, (2) EAP-Response/SIM/Start, (3) 2395 EAP-Request/SIM/Challenge, (4) EAP-Response/SIM/Challenge, (5) 2396 EAP-Request/SIM/Notification, (6) EAP-Response/SIM/Notification, (7) 2397 EAP-Response/SIM/Client-Error (8) EAP-Request/SIM/Re-authentication, 2398 and (9) EAP-Response/SIM/Re-authentication. The column denoted with 2399 "Encr" indicates whether the attribute is a nested attribute that 2400 MUST be included within AT_ENCR_DATA, and the column denoted with 2401 "Skip" indicates whether the attribute is a skippable attribute. 2403 "0" indicates that the attribute MUST NOT be included in the message, 2404 "1" indicates that the attribute MUST be included in the message, 2405 "0-1" indicates that the attribute is sometimes included in the 2406 message, and "0*" indicates that the attribute is not included in the 2407 message in cases specified in this document, but MAY be included in 2408 the future versions of the protocol. 2410 Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) Encr Skip 2411 AT_VERSION_LIST 1 0 0 0 0 0 0 0 0 N N 2412 AT_SELECTED_VERSION 0 0-1 0 0 0 0 0 0 0 N N 2413 AT_NONCE_MT 0 0-1 0 0 0 0 0 0 0 N N 2414 AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N 2415 AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N 2416 AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N 2417 AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 N N 2418 AT_RAND 0 0 1 0 0 0 0 0 0 N N 2419 AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 Y Y 2420 AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 Y Y 2421 AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 N Y 2422 AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 N Y 2423 AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 Y N 2424 AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 N Y 2425 AT_MAC 0 0 1 1 0-1 0-1 0 1 1 N N 2426 AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 Y N 2427 AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 Y N 2428 AT_NONCE_S 0 0 0 0 0 0 0 1 0 Y N 2429 AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 N N 2430 AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 N N 2432 It should be noted that attributes AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ 2433 and AT_FULLAUTH_ID_REQ are mutually exclusive, so that only one of 2434 them can be included at the same time. If one of the attributes 2435 AT_IV and AT_ENCR_DATA is included, then both of the attributes MUST 2436 be included. 2438 9.2 AT_VERSION_LIST 2440 The format of the AT_VERSION_LIST attribute is shown below. 2442 0 1 2 3 2443 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 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 | AT_VERSION_L..| Length | Actual Version List Length | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Supported Version 1 | Supported Version 2 | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 . . 2450 . . 2451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 | Supported Version N | Padding | 2453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2455 This attribute is used in version negotiation, as specified in 2456 Section 4.1. The attribute contains the version numbers supported by 2457 the EAP-SIM server. The server MUST only include versions that it 2458 implements and that are allowed in its security policy. The server 2459 SHOULD list the versions in the order of preference, most preferred 2460 versions first. At least one version number MUST be included. The 2461 version number for the protocol described in this document is one 2462 (0001 hexadecimal). 2464 The value field of this attribute begins with 2-byte Actual Version 2465 List Length, which specifies the length of the Version List in bytes, 2466 not including the Actual Version List Length attribute length. This 2467 field is followed by the list of the versions supported by the 2468 server, which each have a length of 2 bytes. For example, if there 2469 is only one supported version, then the Actual Version List Length is 2470 2. Because the length of the attribute must be a multiple of 4 2471 bytes, the sender pads the value field with zero bytes when 2472 necessary. 2474 9.3 AT_SELECTED_VERSION 2476 The format of the AT_SELECTED_VERSION attribute is shown below. 2478 0 1 2 3 2479 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 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | AT_SELECTED...| Length = 1 | Selected Version | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 This attribute is used in version negotiation, as specified in 2485 Section 4.1. The value field of this attribute contains a two-byte 2486 version number, which indicates the EAP-SIM version that the peer 2487 wants to use. 2489 9.4 AT_NONCE_MT 2491 The format of the AT_NONCE_MT attribute is shown below. 2493 0 1 2 3 2494 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 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 |AT_NONCE_MT | Length = 5 | Reserved | 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2498 | | 2499 | NONCE_MT | 2500 | | 2501 | | 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 The value field of the NONCE_MT attribute contains two reserved bytes 2505 followed by a random number generated by the peer (16 bytes long) 2506 freshly for this EAP-SIM authentication exchange. The random number 2507 is used as a seed value for the new keying material. The reserved 2508 bytes are set to zero upon sending and ignored upon reception. 2510 The peer MUST NOT re-use the NONCE_MT value from a previous EAP-SIM 2511 authentication exchange. If an EAP-SIM exchange includes several 2512 EAP/SIM/Start rounds, then the peer SHOULD use the same NONCE_MT 2513 value in all EAP-Response/SIM/Start packets. The peer SHOULD use a 2514 good source of randomness to generate NONCE_MT. Please see [RFC1750] 2515 for more information about generating random numbers for security 2516 applications. 2518 9.5 AT_PERMANENT_ID_REQ 2520 The format of the AT_PERMANENT_ID_REQ attribute is shown below. 2522 0 1 2 3 2523 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 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 |AT_PERM..._REQ | Length = 1 | Reserved | 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 The use of the AT_PERMANENT_ID_REQ is defined in Section 4.2. The 2529 value field only contains two reserved bytes, which are set to zero 2530 on sending and ignored on reception. 2532 9.6 AT_ANY_ID_REQ 2534 The format of the AT_ANY_ID_REQ attribute is shown below. 2536 0 1 2 3 2537 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 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 |AT_ANY_ID_REQ | Length = 1 | Reserved | 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2542 The use of the AT_ANY_ID_REQ is defined in Section 4.2. The value 2543 field only contains two reserved bytes, which are set to zero on 2544 sending and ignored on reception. 2546 9.7 AT_FULLAUTH_ID_REQ 2548 The format of the AT_FULLAUTH_ID_REQ attribute is shown below. 2550 0 1 2 3 2551 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 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 |AT_FULLAUTH_...| Length = 1 | Reserved | 2554 +---------------+---------------+-------------------------------+ 2556 The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.2. The 2557 value field only contains two reserved bytes, which are set to zero 2558 on sending and ignored on reception. 2560 9.8 AT_IDENTITY 2562 The format of the AT_IDENTITY attribute is shown below. 2564 0 1 2 3 2565 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 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 | AT_IDENTITY | Length | Actual Identity Length | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | | 2570 . Identity (optional) . 2571 . . 2572 | | 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 The use of the AT_IDENTITY is defined in Section 4.2. The value 2576 field of this attribute begins with 2-byte actual identity length, 2577 which specifies the length of the identity in bytes. This field is 2578 followed by the subscriber identity of the indicated actual length. 2579 The identity is the permanent identity, a pseudonym identity or a 2580 fast re-authentication identity. The identity format is specified in 2581 Section 4.2.1. The same identity format is used in the AT_IDENTITY 2582 attribute and the EAP-Response/Identity packet, with the exception 2583 that the peer MUST NOT decorate the identity it includes in 2584 AT_IDENTITY. The identity does not include any terminating null 2585 characters. Because the length of the attribute must be a multiple 2586 of 4 bytes, the sender pads the identity with zero bytes when 2587 necessary. 2589 9.9 AT_RAND 2591 The format of the AT_RAND attribute is shown below. 2593 0 1 2 3 2594 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 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 | AT_RAND | Length | Reserved | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 | | 2599 . n*RAND . 2600 . . 2601 | | 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 The value field of this attribute contains two reserved bytes 2605 followed by n GSM RANDs, each 16 bytes long. The value of n can be 2606 determined by the attribute length. The reserved bytes are set to 2607 zero upon sending and ignored upon reception. 2609 The number of RAND challenges (n) MUST be two or three. The peer 2610 MUST verify that the number of RAND challenges is sufficient 2611 according to the peer's policy. The server MUST use different RAND 2612 values. In other words, a RAND value can only be included once in 2613 AT_RAND. When processing the AT_RAND attribute, the peer MUST check 2614 that the RANDs are different. 2616 The EAP server MUST obtain fresh RANDs for each EAP-SIM full 2617 authentication exchange. More specifically, the server MUST consider 2618 RANDs it included in AT_RAND to be consumed if the server receives an 2619 EAP-Response/SIM/Challenge packet with a valid AT_MAC, or an 2620 EAP-Response/SIM/Client-Error with the code "insufficient number of 2621 challenges" or "RANDs are not fresh". However, in other cases (if 2622 the server does not receive any response to its EAP- 2623 Request/SIM/Challenge packet, or if the server receives some other 2624 kind of response than the cases listed above), the server does not 2625 need to consider the RANDs to be consumed, and the server MAY re-use 2626 the RANDs in the AT_RAND attribute of the next full authentication 2627 attempt. 2629 9.10 AT_NEXT_PSEUDONYM 2631 The format of the AT_NEXT_PSEUDONYM attribute is shown below. 2633 0 1 2 3 2634 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 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 | AT_NEXT_PSEU..| Length | Actual Pseudonym Length | 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 | | 2639 . Next Pseudonym . 2640 . . 2641 | | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 The value field of this attribute begins with 2-byte actual pseudonym 2645 length, which specifies the length of the following pseudonym in 2646 bytes. This field is followed by a pseudonym username that the peer 2647 can use in the next authentication. The username MUST NOT include 2648 any realm portion. The username does not include any terminating 2649 null characters. Because the length of the attribute must be a 2650 multiple of 4 bytes, the sender pads the pseudonym with zero bytes 2651 when necessary. The username encoding MUST follow the UTF-8 2652 transformation format [RFC2279]. This attribute MUST always be 2653 encrypted by encapsulating it within the AT_ENCR_DATA attribute. 2655 9.11 AT_NEXT_REAUTH_ID 2657 The format of the AT_NEXT_REAUTH_ID attribute is shown below. 2659 0 1 2 3 2660 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 2661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2662 | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length| 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 | | 2665 . Next Fast Re-authentication Username . 2666 . . 2667 | | 2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2670 The value field of this attribute begins with 2-byte actual 2671 re-authentication identity length which specifies the length of the 2672 following fast re-authentication identity in bytes. This field is 2673 followed by a fast re-authentication identity that the peer can use 2674 in the next fast re-authentication, as described in Section 5. In 2675 environments where a realm portion is required, the fast 2676 re-authentication identity includes both a username portion and a 2677 realm name portion. The fast re-authentication identity does not 2678 include any terminating null characters. Because the length of the 2679 attribute must be a multiple of 4 bytes, the sender pads the fast 2680 re-authentication identity with zero bytes when necessary. The 2681 identity encoding MUST follow the UTF-8 transformation format 2682 [RFC2279]. This attribute MUST always be encrypted by encapsulating 2683 it within the AT_ENCR_DATA attribute. 2685 9.12 AT_IV, AT_ENCR_DATA and AT_PADDING 2687 AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted 2688 information between the EAP-SIM peer and server. 2690 The value field of AT_IV contains two reserved bytes followed by a 2691 16-byte initialization vector required by the AT_ENCR_DATA attribute. 2692 The reserved bytes are set to zero when sending and ignored on 2693 reception. The AT_IV attribute MUST be included if and only if the 2694 AT_ENCR_DATA is included. Section 6.3 specifies the operation if a 2695 packet that does not meet this condition is encountered. 2697 The sender of the AT_IV attribute chooses the initialization vector 2698 at random. The sender MUST NOT reuse the initialization vector value 2699 from previous EAP-SIM packets. The sender SHOULD use a good source 2700 of randomness to generate the initialization vector. Please see 2701 [RFC1750] for more information about generating random numbers for 2702 security applications. The format of AT_IV is shown below. 2704 0 1 2 3 2705 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 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 | AT_IV | Length = 5 | Reserved | 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | | 2710 | Initialization Vector | 2711 | | 2712 | | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 The value field of the AT_ENCR_DATA attribute consists of two 2716 reserved bytes followed by cipher text bytes encrypted using the 2717 Advanced Encryption Standard (AES) [AES] with a 128-bit key in the 2718 Cipher Block Chaining (CBC) mode of operation using the 2719 initialization vector from the AT_IV attribute. The reserved bytes 2720 are set to zero when sending and ignored on reception. Please see 2721 [CBC] for a description of the CBC mode. The format of the 2722 AT_ENCR_DATA attribute is shown below. 2724 0 1 2 3 2725 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 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | AT_ENCR_DATA | Length | Reserved | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | | 2730 . Encrypted Data . 2731 . . 2732 | | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 The derivation of the encryption key (K_encr) is specified in Section 2736 6.4. 2738 The plaintext consists of nested EAP-SIM attributes. 2740 The encryption algorithm requires the length of the plaintext to be a 2741 multiple of 16 bytes. The sender may need to include the AT_PADDING 2742 attribute as the last attribute within AT_ENCR_DATA. The AT_PADDING 2743 attribute is not included if the total length of other nested 2744 attributes within the AT_ENCR_DATA attribute is a multiple of 16 2745 bytes. As usual, the Length of the Padding attribute includes the 2746 Attribute Type and Attribute Length fields. The length of the 2747 Padding attribute is 4, 8 or 12 bytes. It is chosen so that the 2748 length of the value field of the AT_ENCR_DATA attribute becomes a 2749 multiple of 16 bytes. The actual pad bytes in the value field are 2750 set to zero (00 hexadecimal) on sending. The recipient of the 2751 message MUST verify that the pad bytes are set to zero. If this 2752 verification fails on the peer, then it MUST send the 2753 EAP-Response/SIM/Client-Error packet with the error code "unable to 2754 process packet" to terminate the authentication exchange. If this 2755 verification fails on the server, then the server sends the peer the 2756 EAP-Request/SIM/Notification packet with an AT_NOTIFICATION code that 2757 implies failure to terminate the authentication exchange. The format 2758 of the AT_PADDING attribute is shown below. 2760 0 1 2 3 2761 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 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 | AT_PADDING | Length | Padding... | 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2765 | | 2766 | | 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 9.13 AT_RESULT_IND 2771 The format of the AT_RESULT_IND attribute is shown below. 2773 0 1 2 3 2774 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 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 | AT_RESULT_...| Length = 1 | Reserved | 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 The value field of this attribute consists of two reserved bytes, 2780 which are set to zero upon sending and ignored upon reception. This 2781 attribute is always sent unencrypted, so it MUST NOT be encapsulated 2782 within the AT_ENCR_DATA attribute. 2784 9.14 AT_MAC 2786 The AT_MAC attribute is used for EAP-SIM message authentication. 2787 Section 8 specifies which messages AT_MAC MUST be included. 2789 The value field of the AT_MAC attribute contains two reserved bytes 2790 followed by a keyed message authentication code (MAC). The MAC is 2791 calculated over the whole EAP packet concatenated with optional 2792 message-specific data, with the exception that the value field of the 2793 MAC attribute is set to zero when calculating the MAC. The EAP 2794 packet includes the EAP header that begins with the Code field, the 2795 EAP-SIM header that begins with the Subtype field, and all the 2796 attributes, as specified in Section 7.1. The reserved bytes in 2797 AT_MAC are set to zero when sending and ignored on reception. The 2798 contents of the message-specific data that may be included in the MAC 2799 calculation are specified separately for each EAP-SIM message in 2800 Section 8. 2802 The format of the AT_MAC attribute is shown below. 2804 0 1 2 3 2805 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 2806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 | AT_MAC | Length = 5 | Reserved | 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 | | 2810 | MAC | 2811 | | 2812 | | 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2815 The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The 2816 HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by 2817 truncating the output to the first 16 bytes. Hence, the length of 2818 the MAC is 16 bytes.) The derivation of the authentication key 2819 (K_aut) used in the calculation of the MAC is specified in Section 2820 6.4. 2822 When the AT_MAC attribute is included in an EAP-SIM message, the 2823 recipient MUST process the AT_MAC attribute before looking at any 2824 other attributes, except when processing EAP-Request/SIM/Challenge. 2825 The processing of EAP-Request/SIM/Challenge is specified in Section 2826 8.3. If the message authentication code is invalid, then the 2827 recipient MUST ignore all other attributes in the message and operate 2828 as specified in Section 6.3. 2830 9.15 AT_COUNTER 2832 The format of the AT_COUNTER attribute is shown below. 2834 0 1 2 3 2835 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 2836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2837 | AT_COUNTER | Length = 1 | Counter | 2838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 The value field of the AT_COUNTER attribute consists of a 16-bit 2841 unsigned integer counter value, represented in network byte order. 2842 This attribute MUST always be encrypted by encapsulating it within 2843 the AT_ENCR_DATA attribute. 2845 9.16 AT_COUNTER_TOO_SMALL 2847 The format of the AT_COUNTER_TOO_SMALL attribute is shown below. 2849 0 1 2 3 2850 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 2851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 | AT_COUNTER...| Length = 1 | Reserved | 2853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2855 The value field of this attribute consists of two reserved bytes, 2856 which are set to zero upon sending and ignored upon reception. This 2857 attribute MUST always be encrypted by encapsulating it within the 2858 AT_ENCR_DATA attribute. 2860 9.17 AT_NONCE_S 2862 The format of the AT_NONCE_S attribute is shown below. 2864 0 1 2 3 2865 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 2866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2867 | AT_NONCE_S | Length = 5 | Reserved | 2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 | | 2870 | | 2871 | NONCE_S | 2872 | | 2873 | | 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 The value field of the AT_NONCE_S attribute contains two reserved 2877 bytes followed by a random number generated by the server (16 bytes) 2878 freshly for this EAP-SIM fast re-authentication. The random number 2879 is used as challenge for the peer and also a seed value for the new 2880 keying material. The reserved bytes are set to zero upon sending and 2881 ignored upon reception. This attribute MUST always be encrypted by 2882 encapsulating it within the AT_ENCR_DATA attribute. 2884 The server MUST NOT reuse the NONCE_S value from any previous EAP-SIM 2885 fast re-authentication exchange. The server SHOULD use a good source 2886 of randomness to generate NONCE_S. Please see [RFC1750] for more 2887 information about generating random numbers for security 2888 applications. 2890 9.18 AT_NOTIFICATION 2892 The format of the AT_NOTIFICATION attribute is shown below. 2894 0 1 2 3 2895 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 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2897 |AT_NOTIFICATION| Length = 1 |S|P| Notification Code | 2898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2900 The value field of this attribute contains a two-byte notification 2901 code. The first and second bit (S and P) of the notification code 2902 are interpreted as described in Section 6. 2904 The notification code values listed below have been reserved. The 2905 descriptions below illustrate the semantics of the notifications. 2906 The peer implementation MAY use different wordings when presenting 2907 the notifications to the user. The "requested service" depends on 2908 the environment where EAP-SIM is applied. 2910 0 - General failure after authentication. (Implies failure, used 2911 after successful authentication.) 2912 16384 - General failure. (Implies failure, used before 2913 authentication.) 2915 32768 - Success. User has been successfully authenticated. (Does 2916 not imply failure, used after successful authentication.) The usage 2917 of this code is discussed in Section 6.2. 2919 1026 - User has been temporarily denied access to the requested 2920 service. (Implies failure, used after successful authentication.) 2922 1031 - User has not subscribed to the requested service. (Implies 2923 failure, used after successful authentication.) 2925 9.19 AT_CLIENT_ERROR_CODE 2927 The format of the AT_CLIENT_ERROR_CODE attribute is shown below. 2929 0 1 2 3 2930 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 2931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2932 |AT_CLIENT_ERR..| Length = 1 | Client Error Code | 2933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2935 The value field of this attribute contains a two-byte client error 2936 code. The following error code values have been reserved. 2938 0 "unable to process packet": a general error code 2940 1 "unsupported version": the peer does not support any of 2941 the versions listed in AT_VERSION_LIST 2943 2 "insufficient number of challenges": the peer's policy 2944 requires more triplets than the server included in AT_RAND 2946 3 "RANDs are not fresh": the peer believes that the RAND 2947 challenges included in AT_RAND were not fresh 2949 10. IANA Considerations 2951 IANA has assigned the EAP type number 18 for this protocol. 2953 EAP-SIM shares most of the protocol design, such as attributes and 2954 message Subtypes, with EAP-AKA [EAP-AKA]. EAP-SIM protocol numbers 2955 should be administered in the same IANA registry with EAP-AKA. The 2956 initial values are listed in [EAP-AKA] for both protocols, so this 2957 document does not require any new registries or parameter allocation. 2959 As a common registry is used for EAP-SIM and EAP-AKA, the protocol 2960 number allocation policy for both protocols is specified in 2961 [EAP-AKA]. 2963 11. Security Considerations 2965 The EAP specification [RFC3748] describes the security 2966 vulnerabilities of EAP, which does not include its own security 2967 mechanisms. This section discusses the claimed security properties 2968 of EAP-SIM as well as vulnerabilities and security recommendations. 2970 11.1 A3 and A8 Algorithms 2972 The GSM A3 and A8 algorithms are used in EAP-SIM. [GSM 03.20] 2973 specifies the general GSM authentication procedure and the external 2974 interface (inputs and outputs) of the A3 and A8 algorithms. The 2975 operation of these functions falls completely within the domain of an 2976 individual operator, and the functions are therefore specified by 2977 each operator rather than being fully standardised. The GSM-MILENAGE 2978 algorithm, specified publicly in [3GPP TS 55.205], is an example 2979 algorithm set for A3 and A8 algorithms. 2981 The security of the A3 and A8 algorithms is important to the security 2982 of EAP-SIM. Some A3/A8 algorithms have been compromised; see for 2983 example [GSM Cloning] for discussion about the security of COMP-128 2984 version 1. Note that several revised versions of the COMP-128 A3/A8 2985 algorithm have been devised after the publication of these weaknesses 2986 and that the publicly specified GSM-MILENAGE algorithm is not 2987 vulnerable to any known attacks. 2989 11.2 Identity Protection 2991 EAP-SIM includes optional identity privacy support that protects the 2992 privacy of the subscriber identity against passive eavesdropping. 2993 This document only specifies a mechanism to deliver pseudonyms from 2994 the server to the peer as part of an EAP-SIM exchange. Hence, a peer 2995 that has not yet performed any EAP-SIM exchanges does not typically 2996 have a pseudonym available. If the peer does not have a pseudonym 2997 available, then the privacy mechanism cannot be used, but the 2998 permanent identity will have to be sent in the clear. The terminal 2999 SHOULD store the pseudonym in a non-volatile memory so that it can be 3000 maintained across reboots. An active attacker that impersonates the 3001 network may use the AT_PERMANENT_ID_REQ attribute to attempt to learn 3002 the subscriber's permanent identity. However, as discussed in 3003 Section 4.2.2, the terminal can refuse to send the cleartext 3004 permanent identity if it believes that the network should be able to 3005 recognize the pseudonym. 3007 If the peer and server cannot guarantee that the pseudonym will be 3008 maintained reliably and identity privacy is required then additional 3009 protection from an external security mechanism such as Protected 3010 Extensible Authentication Protocol (PEAP) [PEAP] may be used. If an 3011 external security mechanism is in use the identity privacy features 3012 of EAP-SIM may not be useful. The security considerations of using 3013 an external security mechanism with EAP-SIM are beyond the scope of 3014 this document. 3016 11.3 Mutual Authentication and Triplet Exposure 3018 EAP-SIM provides mutual authentication. The peer believes that the 3019 network is authentic because the network can calculate a correct 3020 AT_MAC value in the EAP-Request/SIM/Challenge packet. To calculate 3021 AT_MAC it is sufficient to know the RAND and Kc values from the GSM 3022 triplets (RAND, SRES, Kc) used in the authentication. Because the 3023 network selects the RAND challenges and the triplets, an attacker 3024 that knows n (2 or 3) GSM triplets for the subscriber is able to 3025 impersonate a valid network to the peer. (Some peers MAY employ an 3026 implementation-specific counter-measure against impersonating a valid 3027 network by re-using a previously used RAND; see below.) In other 3028 words, the security of EAP-SIM is based on the secrecy of Kc keys, 3029 which are considered secret intermediate results in the EAP-SIM 3030 cryptographic calculations. 3032 Given physical access to the SIM card, it is easy to obtain any 3033 number of GSM triplets. 3035 Another way to obtain triplets is to mount an attack on the peer 3036 platform via a virus or other malicious piece of software. The peer 3037 SHOULD be protected against triplet querying attacks by malicious 3038 software. Care should be taken not to expose Kc keys to attackers 3039 when they are stored or handled by the peer, or transmitted between 3040 the subsystems of the peer. Steps should be taken to limit the 3041 transport, storage and handling of these values outside a protected 3042 environment within the peer. However, the virus protection of the 3043 peer and the security capabilities of the peer's operating system are 3044 outside the scope of this document. 3046 The EAP-SIM server typically obtains the triplets from the Home 3047 Location Register (HLR). An attacker might try to obtain triplets by 3048 attacking against the network used between the EAP-SIM server and the 3049 HLR. Care should be taken not to expose Kc keys to attackers when 3050 they are stored or handled by the EAP-SIM server, or transmitted 3051 between the EAP server and the HLR. Steps should be taken to limit 3052 the transport, storage and handling of these values outside a 3053 protected environment. However, the protection of the communications 3054 between the EAP-SIM server and the HLR is outside the scope of this 3055 document. 3057 If the same SIM credentials are also used for GSM traffic, the 3058 triplets could be revealed in the GSM network; see Section 11.8. 3060 In GSM, the network is allowed to reuse the RAND challenge in 3061 consecutive authentication exchanges. This is not allowed in 3062 EAP-SIM. The EAP-SIM server is mandated to use fresh triplets (RAND 3063 challenges) in consecutive authentication exchanges, as specified in 3064 Section 3. EAP-SIM does not mandate any means for the peer to check 3065 if the RANDs are fresh, so the security of the scheme leans on the 3066 secrecy of the triplets. However, the peer MAY employ 3067 implementation-specific mechanisms to remember some of the previously 3068 used RANDs, and the peer MAY check the freshness of the server's 3069 RANDs. The operation in cases when the peer detects that the RANDs 3070 are not fresh is specified in Section 6.3.1. 3072 Preventing the re-use of authentication vectors has been taken into 3073 account in the design of the UMTS Authentication and Key Agreement 3074 (AKA), which is used in EAP-AKA [EAP-AKA]. In cases when the triplet 3075 re-use properties of EAP-SIM are not considered sufficient, it is 3076 advised to use EAP-AKA. 3078 Note that EAP-SIM mutual authentication is with the EAP server. In 3079 general, EAP methods do not authenticate the identity or services 3080 provided by the EAP authenticator (if distinct from the EAP server) 3081 unless they provide the so-called channel bindings property. The 3082 vulnerabilities related to this have been discussed in [RFC3748], 3083 [EAP Keying] , [Service Identity]. 3085 EAP-SIM does not provide the channel bindings property, so it only 3086 authenticates the EAP server. However, ongoing work such as [Service 3087 Identity] may provide such support as an extension to popular EAP 3088 methods such as EAP-TLS, EAP-SIM, or EAP-AKA. 3090 11.4 Flooding the Authentication Centre 3092 The EAP-SIM server typically obtains authentication vectors from the 3093 Authentication Centre (AuC). EAP-SIM introduces a new usage for the 3094 AuC. The protocols between the EAP-SIM server and the AuC are out of 3095 the scope of this document. However, it should be noted that a 3096 malicious EAP-SIM peer may generate a lot of protocol requests to 3097 mount a denial of service attack. The EAP-SIM server implementation 3098 SHOULD take this into account and SHOULD take steps to limit the 3099 traffic that it generates towards the AuC, preventing the attacker 3100 from flooding the AuC and from extending the denial of service attack 3101 from EAP-SIM to other users of the AuC. 3103 11.5 Key Derivation 3105 EAP-SIM supports key derivation. The key hierarchy is specified in 3106 Section 6.4. EAP-SIM combines several GSM triplets in order to 3107 generate stronger keying material and stronger AT_MAC values. The 3108 actual strength of the resulting keys depends, among other things, on 3109 some operator specific parameters including authentication 3110 algorithms, the strength of the Ki key, and the quality of the RAND 3111 challenges. For example, some SIM cards generate Kc keys with 10 3112 bits set to zero. Such restrictions may prevent the concatenation 3113 technique from yielding strong session keys. Because the strength of 3114 the Ki key is 128 bits, the ultimate strength of any derived secret 3115 key material is never more than 128 bits. 3117 It should also be noted that a security policy that allows n=2 to be 3118 used may compromise the security of a future policy that requires 3119 three triplets, because adversaries may be able to exploit the 3120 messages exchanged when the weaker policy was applied. 3122 There is no known way to obtain complete GSM triplets by mounting an 3123 attack against EAP-SIM. A passive eavesdropper can learn n*RAND and 3124 AT_MAC and may be able to link this information to the subscriber 3125 identity. An active attacker that impersonates a GSM subscriber can 3126 easily obtain n*RAND and AT_MAC values from the EAP server for any 3127 given subscriber identity. However, calculating the Kc and SRES 3128 values from AT_MAC would require the attacker to reverse the keyed 3129 message authentication code function HMAC-SHA1-128. 3131 As EAP-SIM does not expose any values calculated from an individual 3132 GSM Kc keys, it is not possible to mount a brute force attack on just 3133 one of the Kc keys in EAP-SIM. Therefore, when considering brute 3134 force attacks on the values exposed in EAP-SIM, the effective length 3135 of EAP-SIM session keys is not compromised by the fact that they are 3136 combined from several shorter keys, i.e the effective length of 128 3137 bits may be achieved. For additional considerations see Section 3138 11.8. 3140 11.6 Cryptographic Separation of Keys and Session Independence 3142 The EAP Transient Keys used to protect EAP-SIM packets (K_encr, 3143 K_aut), the Master Session Key, and the Extended Master Session Key 3144 are cryptographically separate in EAP-SIM. An attacker cannot derive 3145 any non-trivial information about any of these keys based on the 3146 other keys. An attacker also cannot calculate the pre-shared secret 3147 (Ki) from the GSM Kc keys, from EAP-SIM K_encr, from EAP-SIM K_aut, 3148 from the Master Session Key, or from the Extended Master Session Key. 3150 Each EAP-SIM exchange generates fresh keying material, and the keying 3151 material exported from the method upon separate EAP-SIM exchanges is 3152 cryptographically separate. The EAP-SIM peer contributes to the 3153 keying material with the NONCE_MT parameter, which must be chosen 3154 freshly for each full authentication exchange. The EAP server is 3155 mandated to choose the RAND challenges freshly for each full 3156 authentication exchange. If either the server or the peer chooses 3157 its random value (NONCE_MT or RAND challenges) freshly, even if the 3158 other entity reused its value from a previous exchange, then the EAP 3159 Transient Keys, the Master Session Key, and the Extended Master 3160 Session Key will be different and cryptographically separate from the 3161 corresponding values derived upon the previous full authentication 3162 exchange. 3164 On fast re-authentication, freshness of the Master Session Key and 3165 the Extended Master Session Key is provided with a counter 3166 (AT_COUNTER). The same EAP Transient Keys (K_encr, K_aut) as in the 3167 full authentication exchange are used to protect the EAP negotiation. 3168 However, replay and integrity protection across all the fast 3169 re-authentication exchanges that use the same EAP Transient Keys is 3170 provided with AT_COUNTER. 3172 [RFC3748] defines session independence as the "demonstration that 3173 passive attacks (such as capture of the EAP conversation) or active 3174 attacks (including compromise of the MSK or EMSK) do not enable 3175 compromise of subsequent or prior MSKs or EMSKs". As the MSKs and 3176 EMSKs are separate between EAP exchanges, EAP-SIM supports this 3177 security claim. 3179 It should be noted that [Patel 2003], which predates [RFC3748], uses 3180 a slightly different meaning for session independence. The EAP-SIM 3181 protocol does not allow the peer to ensure that different Kc key 3182 values would be used in different exchanges, but only the server is 3183 able to ensure that fresh RANDs and thereby fresh Kc keys are used. 3184 Hence, the peer cannot guarantee EAP-SIM sessions to be independent 3185 with regard to the internal Kc values. However, in EAP-SIM the Kc 3186 keys are considered to be secret intermediate results, which are not 3187 exported outside the method. Please see Section 11.3 for more 3188 information about RAND reuse. 3190 11.7 Dictionary Attacks 3192 Because EAP-SIM is not a password protocol, it is not vulnerable to 3193 dictionary attacks. (The pre-shared symmetric secret stored on the 3194 SIM card is not a passphrase, or derived from a passphrase.) 3196 11.8 Credentials Reuse 3198 EAP-SIM cannot prevent attacks over the GSM or GPRS radio networks. 3200 If the same SIM credentials are also used in GSM or GPRS, it is 3201 possible to mount attacks over the cellular interface. 3203 A passive attacker can eavesdrop GSM or GPRS traffic and obtain RAND, 3204 SRES pairs. He can then use a brute force attack or other 3205 cryptanalysis techniques to obtain the 64-bit Kc keys used to encrypt 3206 the GSM or GPRS data. This makes it possible to attack each 64-bit 3207 key separately. 3209 An active attacker can mount a "rogue GSM/GPRS base station attack", 3210 replaying previously seen RAND challenges to obtain SRES values. He 3211 can then use a brute force attack to obtain the Kc keys. If 3212 successful, the attacker can impersonate a valid network or decrypt 3213 previously seen traffic, because EAP-SIM does not provide perfect 3214 forward secrecy (PFS). 3216 Due to several weaknesses in the GSM encryption algorithms, the 3217 effective key strength of the Kc keys is much less than the expected 3218 64 bits (no more than 40 bits if the A5/1 GSM encryption algorithm is 3219 used; as documented in [Barkan et al. 2003], an active attacker can 3220 force the peer to use the weaker A5/2 algorithm that can be broken in 3221 less than a second). 3223 Because the A5 encryption algorithm is not used in EAP-SIM, and 3224 because EAP-SIM does not expose any values calculated from individual 3225 Kc keys, it should be noted that these attacks are not possible if 3226 the SIM credentials used in EAP-SIM are not shared in GSM/GPRS. 3228 At the time of writing this document, the 3rd Generation Partnership 3229 Project (3GPP) has started to work on fixes to these A5 3230 vulnerabilities. One of the solution proposals discussed in 3GPP is 3231 integrity protected A5 version negotiation, which would require the 3232 base station to prove knowledge of the Kc key before the terminal 3233 sends any values calculated from the Kc to the network. Another 3234 proposal is so-called special RANDs, where some bits of the RAND 3235 challenge would be used for cryptographic separation by indicating 3236 the allowed use of the triplet, such as the allowed A5 algorithm in 3237 GSM or the fact that the triplet is intended for EAP-SIM. This is 3238 currently work in progress, and the mechanisms have not been selected 3239 yet. 3241 11.9 Integrity and Replay Protection, and Confidentiality 3243 AT_MAC, AT_IV, AT_ENCR_DATA and AT_COUNTER attributes are used to 3244 provide integrity, replay and confidentiality protection for EAP-SIM 3245 requests and responses. Integrity protection with AT_MAC includes 3246 the EAP header. These attributes cannot be used during the 3247 EAP/SIM/Start roundtrip. However, the protocol values (user identity 3248 string, NONCE_MT and version negotiation parameters) are (implicitly) 3249 protected by later EAP-SIM messages by including them in key 3250 derivation. 3252 Integrity protection (AT_MAC) is based on a keyed message 3253 authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is 3254 based on a block cipher. 3256 Confidentiality protection is applied only to a part of the protocol 3257 fields. The table of attributes in Section 9.1 summarizes which 3258 fields are confidentiality protected. It should be noted that the 3259 error and notification code attributes AT_CLIENT_ERROR_CODE and 3260 AT_NOTIFICATION are not confidential but they are transmitted in the 3261 clear. Identity protection is discussed in Section 11.2. 3263 On full authentication, replay protection of the EAP exchange is 3264 provided by the RAND values from the underlying GSM authentication 3265 scheme and the use of the NONCE_MT value. Protection against replays 3266 of EAP-SIM messages is also based on the fact that messages that can 3267 include AT_MAC can only be sent once with a certain EAP-SIM Subtype, 3268 and on the fact that a different K_aut key will be used for 3269 calculating AT_MAC in each full authentication exchange. 3271 On fast re-authentication, a counter included in AT_COUNTER and a 3272 server random nonce is used to provide replay protection. The 3273 AT_COUNTER attribute is also included in EAP-SIM notifications, if 3274 they are used after successful authentication in order to provide 3275 replay protection between re-authentication exchanges. 3277 Because EAP-SIM is not a tunneling method, EAP-Request/Notification, 3278 EAP-Response/Notification, EAP-Success or EAP-Failure packets are not 3279 confidential, integrity protected or replay protected in EAP-SIM. On 3280 physically insecure networks, this may enable an attacker to send 3281 false notifications to the peer and to mount denial of service 3282 attacks by spoofing these packets. As discussed in Section 6.3, the 3283 peer will only accept EAP-Success after the peer successfully 3284 authenticates the server. Hence, the attacker cannot force the peer 3285 to believe successful mutual authentication has occurred before the 3286 peer successfully authenticates the server or after the peer failed 3287 to authenticate the server. 3289 The security considerations of EAP-SIM result indications are covered 3290 in Section 11.11 3292 An eavesdropper will see the EAP-Request/Notification, 3293 EAP-Response/Notification, EAP-Success and EAP-Failure packets sent 3294 in the clear. With EAP-SIM, confidential information MUST NOT be 3295 transmitted in EAP Notification packets. 3297 11.10 Negotiation Attacks 3299 EAP-SIM does not protect the EAP-Response/Nak packet. Because 3300 EAP-SIM does not protect the EAP method negotiation, EAP method 3301 downgrading attacks may be possible, especially if the user uses the 3302 same identity with EAP-SIM and other EAP methods. 3304 EAP-SIM includes a version negotiation procedure. In EAP-SIM the 3305 keying material derivation includes the version list and selected 3306 version to ensure that the protocol cannot be downgraded and that the 3307 peer and server use the same version of EAP-SIM. 3309 EAP-SIM does not support ciphersuite negotiation. 3311 11.11 Protected Result Indications 3313 EAP-SIM supports optional protected success indications, and 3314 acknowledged failure indications. If a failure occurs after 3315 successful authentication, then the EAP-SIM failure indication is 3316 integrity and replay protected. 3318 Even if an EAP-Failure packet is lost when using EAP-SIM over an 3319 unreliable medium, then the EAP-SIM failure indications will help 3320 ensure that the peer and EAP server will know the other parties 3321 authentication decision. If protected success indications are used, 3322 then the loss of Success packet will also be addressed by the 3323 acknowledged, integrity and replay protected EAP-SIM success 3324 indication. If the optional success indications are not used, then 3325 the peer may end up believing the server succeeded authentication 3326 when it actually failed. Since access will not be granted in this 3327 case protected result indications are not needed unless the client is 3328 not able to realize it does not have access for an extended period of 3329 time. 3331 11.12 Man-in-the-middle Attacks 3333 In order to avoid man-in-the-middle attacks and session hijacking, 3334 user data SHOULD be integrity protected on physically insecure 3335 networks. The EAP-SIM Master Session Key or keys derived from it MAY 3336 be used as the integrity protection keys, or, if an external security 3337 mechanism such as PEAP is used, then the link integrity protection 3338 keys MAY be derived by the external security mechanism. 3340 There are man-in-the-middle attacks associated with the use of any 3341 EAP method within a tunneled protocol. For instance, an early 3342 version of PEAP [PEAP-02] was vulnerable to this attack. This 3343 specification does not address these attacks. If EAP-SIM is used 3344 with a tunneling protocol, there should be cryptographic binding 3345 provided between the protocol and EAP-SIM to prevent 3346 man-in-the-middle attacks through rogue authenticators being able to 3347 setup one-way authenticated tunnels. For example, newer versions of 3348 PEAP include such cryptographic binding. The EAP-SIM Master Session 3349 Key MAY be used to provide the cryptographic binding. However the 3350 mechanism how the binding is provided depends on the tunneling 3351 protocol and is beyond the scope of this document. 3353 11.13 Generating Random Numbers 3355 An EAP-SIM implementation SHOULD use a good source of randomness to 3356 generate the random numbers required in the protocol. Please see 3357 [RFC1750] for more information on generating random numbers for 3358 security applications. 3360 12. Security Claims 3362 This section provides the security claims required by [RFC3748]. 3364 Auth. mechanism: EAP-SIM is based on the GSM SIM mechanism, which is 3365 a challenge/response authentication and key agreement mechanism based 3366 on a symmetric 128-bit pre-shared secret. EAP-SIM also makes use of 3367 a peer challenge to provide mutual authentication. 3369 Ciphersuite negotiation: No 3371 Mutual authentication: Yes (Section 11.3) 3373 Integrity protection: Yes (Section 11.9) 3375 Replay protection: Yes (Section 11.9) 3377 Confidentiality: Yes, except method specific success and failure 3378 indications (Section 11.2, Section 11.9) 3380 Key derivation: Yes 3382 Key strength: EAP-SIM supports key derivation with 128-bit effective 3383 key strength (Section 11.5). However, as discussed in Section 11, if 3384 the same credentials are used in GSM/GPRS and in EAP-SIM, then the 3385 key strength may be reduced considerably, basically to the same level 3386 as in GSM, by mounting attacks over GSM/GPRS. For example an active 3387 attack using a false GSM/GPRS base station reduces the effective key 3388 strength to almost zero. 3390 Description of key hierarchy: Please see Section 6.4. 3392 Dictinary attack protection: N/A (Section 11.7) 3393 Fast reconnect: Yes 3395 Cryptographic binding: N/A 3397 Session independence: Yes (Section 11.6) 3399 Fragmentation: No 3401 Channel binding: No 3403 Indication of vulnerabilities: Vulnerabilities are discussed in 3404 Section 11. 3406 13. Acknowledgements and Contributions 3408 13.1 Contributors 3410 In addition to the editors, Nora Dabbous, Jose Puthenkulam, and 3411 Prasanna Satarasinghe were significant contributors to this document. 3413 Pasi Eronen and Jukka-Pekka Honkanen contributed Appendix A. 3415 13.2 Acknowledgements 3417 Juha Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt, 3418 Jukka-Pekka Honkanen, Antti Kuikka, Jukka Latva, Lassi Lehtinen, Jyri 3419 Rinnemaa, Timo Takamaki and Raimo Vuonnala contributed many original 3420 ideas and concepts to this protocol. 3422 N. Asokan, Pasi Eronen and Jukka-Pekka Honkanen contributed and 3423 helped in innumerable ways during the development of the protocol. 3425 Valtteri Niemi and Kaisa Nyberg contributed substantially to the 3426 design of the key derivation and the fast re-authentication 3427 procedure, and have also provided their cryptographic expertise in 3428 many discussions related to this protocol. 3430 Simon Blake-Wilson provided most helpful comments on key derivation 3431 and version negotiation. 3433 Thanks to Greg Rose for his most valuable comments to an early 3434 version of this specification [S3-020125], and for reviewing and 3435 providing very useful comments on draft version 12. 3437 Thanks to Bernard Aboba, Vladimir Alperovich, Florent Bersani, 3438 Jacques Caron, Gopal Dommety, Augustin Farrugia, Mark Grayson, Max de 3439 Groot, Prakash Iyer, Nishi Kant, Victor Lortz, Jouni Malinen, Sarvar 3440 Patel, Tom Porcher, Michael Richardson, Stefan Schroeder, Uma 3441 Shankar, Jesse Walker and Thomas Wieland for their contributions and 3442 critiques. Special thanks to Max for proposing improvements to the 3443 MAC calculation. 3445 Thanks to Glen Zorn for reviewing this document and for providing 3446 most useful comments on the protocol. 3448 Thanks to Sarvar Patel for his review of the protocol [Patel 2003]. 3450 Thanks to Bernard Aboba for reviewing this document for RFC 3748 3451 compliance. 3453 The identity privacy support is based on the identity privacy support 3454 of [EAP-SRP]. The attribute format is based on the extension format 3455 of Mobile IPv4 [RFC3344]. 3457 This protocol has been partly developed in parallel with EAP-AKA 3458 [EAP-AKA], and hence this specification incorporates many ideas from 3459 Jari Arkko. 3461 13.2.1 Contributors' Addresses 3463 Nora Dabbous 3464 Gemplus 3465 34 rue Guynemer 3466 92447 Issy les Moulineaux 3467 France 3468 EMail: nora.dabbous@gemplus.com 3469 Phone: +33 1 4648 2000 3471 Jose Puthenkulam 3472 Intel Corporation 3473 2111 NE 25th Avenue, JF2-58 3474 Hillsboro, OR 97124 3475 USA 3476 EMail: jose.p.puthenkulam@intel.com 3477 Phone: +1 503 264 6121 3479 Prasanna Satarasinghe 3480 Transat Technologies 3481 180 State Street, Suite 240 3482 Southlake, TX 76092 3483 USA 3484 EMail: prasannas@transat-tech.com 3485 Phone: + 1 817 4814412 3487 14. References 3489 14.1 Normative References 3491 [GSM 03.20] 3492 European Telecommunications Standards Institute, "GSM 3493 Technical Specification GSM 03.20 (ETS 300 534): "Digital 3494 cellular telecommunication system (Phase 2); Security 3495 related network functions"", August 1997. 3497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3498 Requirement Levels", BCP 14, RFC 2119, March 1997. 3500 [GSM 03.03] 3501 European Telecommunications Standards Institute, "GSM 3502 Technical Specification GSM 03.03 (ETS 300 523): "Digital 3503 cellular telecommunication system (Phase 2); Numbering, 3504 addressing and identification"", April 1997. 3506 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 3507 RFC 2486, January 1999. 3509 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 3510 Keyed-Hashing for Message Authentication", RFC 2104, 3511 February 1997. 3513 [AES] National Institute of Standards and Technology, "Federal 3514 Information Processing Standards (FIPS) Publication 197, 3515 "Advanced Encryption Standard (AES)"", November 2001. 3517 http://csrc.nist.gov/publications/fips/fips197/fips-197.pd 3518 f 3520 [CBC] National Institute of Standards and Technology, "NIST 3521 Special Publication 800-38A, "Recommendation for Block 3522 Cipher Modes of Operation - Methods and Techniques"", 3523 December 2001. 3525 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-3 3526 8a.pdf 3528 [SHA-1] National Institute of Standards and Technology, U.S. 3529 Department of Commerce, "Federal Information Processing 3530 Standard (FIPS) Publication 180-1, "Secure Hash 3531 Standard"", April 1995. 3533 [PRF] National Institute of Standards and Technology, "Federal 3534 Information Processing Standards (FIPS) Publication 186-2 3535 (with change notice); Digital Signature Standard (DSS)", 3536 January 2000. 3538 Available on-line at: 3539 http://csrc.nist.gov/publications/fips/fips186-2/fips186-2 3540 -change1.pdf 3542 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3543 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3544 October 1998. 3546 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 3547 10646", RFC 2279, January 1998. 3549 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 3550 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3551 3748, June 2004. 3553 [EAP-AKA] Arkko, J. and H. Haverinen, "EAP-AKA Authentication", 3554 draft-arkko-pppext-eap-aka-14 (work in progress), November 3555 2004. 3557 14.2 Informative References 3559 [Draft 3GPP TS 23.003] 3560 3rd Generation Partnership Project, "Draft 3GPP Technical 3561 Specification 3GPP TS 23.003 V 6.1.0: "3rd Generation 3562 Partnership Project; Technical Specification Group Core 3563 Network; Numbering, addressing and identification (Release 3564 6)"", December 2003. 3566 work in progress 3568 [3GPP TS 55.205] 3569 3rd Generation Partnership Project, "3GPP Technical 3570 Specification 3GPP TS 55.205 V 6.0.0: "3rd Generation 3571 Partnership Project; Technical Specification Group 3572 Services and System Aspects; Specification of the 3573 GSM-MILENAGE Algorithms: An example algorithm set for the 3574 GSM Authentication and Key Generation functions A3 and A8 3575 (Release 6)"", December 2002. 3577 [PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H. 3578 and S. Josefsson, "Protected EAP Protocol (PEAP) Version 3579 2", draft-josefsson-pppext-eap-tls-eap-09 (work in 3580 progress), October 2004. 3582 [PEAP-02] Anderson, H., Josefsson, S., Zorn, G., Simon, D. and A. 3584 Palekar, "Protected EAP Protocol (PEAP)", 3585 draft-josefsson-pppext-eap-tls-eap-02 (work in progress), 3586 February 2002. 3588 [EAP Keying] 3589 Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. 3590 Levkowetz, "Extensible Authentication Protocol (EAP) Key 3591 Management Framework", draft-ietf-eap-keying-04 (work in 3592 progress), November 2004. 3594 [Service Identity] 3595 Arkko, J. and P. Eronen, "Authenticated Service 3596 Information for the Extensible Authentication Protocol 3597 (EAP)", draft-arkko-service-identity-auth-01 (work in 3598 progress), October 2004. 3600 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 3601 Recommendations for Security", RFC 1750, December 1994. 3603 [S3-020125] 3604 Qualcomm, "Comments on draft EAP/SIM, 3rd Generation 3605 Partnership Project document 3GPP TSG SA WG3 Security 3606 S3#22, S3-020125", February 2002. 3608 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 3609 August 2002. 3611 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 3612 RFC 2548, March 1999. 3614 [EAP-SRP] Carlson, J., Aboba, B. and H. Haverinen, "EAP SRP-SHA1 3615 Authentication Protocol", Internet-Draft 3616 draft-ietf-pppext-eap-srp-03, July 2001. 3618 [GSM Cloning] 3619 Wagner, D., "GSM Cloning". 3621 Web page about COMP-128 version 1 vulnerabilities, 3622 available at 3623 http://www.isaac.cs.berkeley.edu/isaac/gsm.html 3625 [Barkan et al. 2003] 3626 Barkan, E., Biham, E. and N. Keller, "Instant 3627 Ciphertext-Only Cryptanalysis of GSM Encrypted 3628 Communications". 3630 available on-line at http://cryptome.org/gsm-crack-bbk.pdf 3632 [Patel 2003] 3633 Patel, S., "Analysis of EAP-SIM Session Key Agreement". 3635 Posted to the EAP mailing list 29 May,2003. 3636 http://mail.frascone.com/pipermail/public/eap/2003-May/001 3637 267.html 3639 Authors' Addresses 3641 Henry Haverinen (editor) 3642 Nokia Enterprise Solutions 3643 P.O. Box 12 3644 FIN-40101 Jyvaskyla 3645 Finland 3647 EMail: henry.haverinen@nokia.com 3649 Joseph Salowey (editor) 3650 Cisco Systems 3651 2901 Third Avenue 3652 Seattle, WA 98121 3653 USA 3655 Phone: +1 206 256 3380 3656 EMail: jsalowey@cisco.com 3658 Appendix A. Test Vectors 3660 Test vectors for the NIST FIPS 186-2 pseudo-random number generator 3661 [PRF] are available at the following URL: 3662 http://csrc.nist.gov/encryption/dss/Examples-1024bit.pdf 3664 The following examples show the contents of EAP-SIM packets on full 3665 authentication and fast re-authentication. 3667 A.1 EAP-Request/Identity 3669 The first packet is a plain Identity Request: 3671 01 ; Code: Request 3672 00 ; Identifier: 0 3673 00 05 ; Length: 5 octets 3674 01 ; Type: Identity 3676 A.2 EAP-Response/Identity 3678 The client's identity is "1244070100000001@eapsim.foo", so it 3679 responds with the following packet: 3681 02 ; Code: Response 3682 00 ; Identifier: 0 3683 00 20 ; Length: 32 octets 3684 01 ; Type: Identity 3685 31 32 34 34 ; "1244070100000001@eapsim.foo" 3686 30 37 30 31 3687 30 30 30 30 3688 30 30 30 31 3689 40 65 61 70 3690 73 69 6d 2e 3691 66 6f 6f 3693 A.3 EAP-Request/SIM/Start 3695 The server's first packet looks like this: 3697 01 ; Code: Request 3698 01 ; Identifier: 1 3699 00 10 ; Length: 16 octets 3700 12 ; Type: EAP-SIM 3701 0a ; EAP-SIM subtype: Start 3702 00 00 ; (reserved) 3703 0f ; Attribute type: AT_VERSION_LIST 3704 02 ; Attribute length: 8 octets (2*4) 3705 00 02 ; Actual version list length: 2 octets 3706 00 01 ; Version: 1 3707 00 00 ; (attribute padding) 3709 A.4 EAP-Response/SIM/Start 3711 The client selects a nonce and responds with the following packet: 3713 02 ; Code: Response 3714 01 ; Identifier: 1 3715 00 20 ; Length: 32 octets 3716 12 ; Type: EAP-SIM 3717 0a ; EAP-SIM subtype: Start 3718 00 00 ; (reserved) 3719 07 ; Attribute type: AT_NONCE_MT 3720 05 ; Attribute length: 20 octets (5*4) 3721 00 00 ; (reserved) 3722 01 23 45 67 ; NONCE_MT value 3723 89 ab cd ef 3724 fe dc ba 98 3725 76 54 32 10 3726 10 ; Attribute type: AT_SELECTED_VERSION 3727 01 ; Attribute length: 4 octets (1*4) 3728 00 01 ; Version: 1 3730 A.5 EAP-Request/SIM/Challenge 3732 Next, the server selects three authentication triplets 3734 (RAND1,SRES1,Kc1) = (10111213 14151617 18191a1b 1c1d1e1f, 3735 d1d2d3d4, 3736 a0a1a2a3 a4a5a6a7) 3737 (RAND2,SRES2,Kc2) = (20212223 24252627 28292a2b 2c2d2e2f, 3738 e1e2e3e4, 3739 b0b1b2b3 b4b5b6b7) 3740 (RAND3,SRES3,Kc3) = (30313233 34353637 38393a3b 3c3d3e3f, 3741 f1f2f3f4, 3742 c0c1c2c3 c4c5c6c7) 3744 Next, the MK is calculated as specified in Section 6.4. 3746 MK = e576d5ca 332e9930 018bf1ba ee2763c7 95b3c712 3748 And the other keys are derived using the PRNG: 3750 K_encr = 536e5ebc 4465582a a6a8ec99 86ebb620 3751 K_aut = 25af1942 efcbf4bc 72b39434 21f2a974 3752 MSK = 39d45aea f4e30601 983e972b 6cfd46d1 3753 c3637733 65690d09 cd44976b 525f47d3 3754 a60a985e 955c53b0 90b2e4b7 3719196a 3755 40254296 8fd14a88 8f46b9a7 886e4488 3756 EMSK = 5949eab0 fff69d52 315c6c63 4fd14a7f 3757 0d52023d 56f79698 fa6596ab eed4f93f 3758 bb48eb53 4d985414 ceed0d9a 8ed33c38 3759 7c9dfdab 92ffbdf2 40fcecf6 5a2c93b9 3761 Next, the server selects a pseudonym and a fast re-authentication 3762 identity (in this case, "w8w49PexCazWJ&xCIARmxuMKht5S1sxR 3763 DqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G" and 3764 "Y24fNSrz8BP274jOJaF17WfxI8YO7QX0 3765 0pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo", respectively). 3767 The following plaintext will be encrypted and stored in the 3768 AT_ENCR_DATA attribute: 3770 84 ; Attribute type: AT_NEXT_PSEUDONYM 3771 13 ; Attribute length: 76 octets (19*4) 3772 00 46 ; Actual pseudonym length: 70 octets 3773 77 38 77 34 39 50 65 78 43 61 7a 57 4a 26 78 43 3774 49 41 52 6d 78 75 4d 4b 68 74 35 53 31 73 78 52 3775 44 71 58 53 45 46 42 45 67 33 44 63 5a 50 39 63 3776 49 78 54 65 35 4a 34 4f 79 49 77 4e 47 56 7a 78 3777 65 4a 4f 55 31 47 3778 00 00 ; (attribute padding) 3779 85 ; Attribute type: AT_NEXT_REAUTH_ID 3780 16 ; Attribute length: 88 octets (22*4) 3781 00 51 ; Actual re-auth identity length: 81 octets 3782 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f 3783 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30 3784 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f 3785 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b 3786 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f 3787 6f 3788 00 00 00 ; (attribute padding) 3789 06 ; Attribute type: AT_PADDING 3790 03 ; Attribute length: 12 octets (3*4) 3791 00 00 00 00 3792 00 00 00 00 3793 00 00 3795 The EAP packet looks like this: 3797 01 ; Code: Request 3798 02 ; Identifier: 2 3799 01 18 ; Length: 280 octets 3800 12 ; Type: EAP-SIM 3801 0b ; EAP-SIM subtype: Challenge 3802 00 00 ; (reserved) 3803 01 ; Attribute type: AT_RAND 3804 0d ; Attribute length: 52 octets (13*4) 3805 00 00 ; (reserved) 3806 10 11 12 13 ; first RAND 3807 14 15 16 17 3808 18 19 1a 1b 3809 1c 1d 1e 1f 3810 20 21 22 23 ; second RAND 3811 24 25 26 27 3812 28 29 2a 2b 3813 2c 2d 2e 2f 3814 30 31 32 33 ; third RAND 3815 34 35 36 37 3816 38 39 3a 3b 3817 3c 3d 3e 3f 3818 81 ; Attribute type: AT_IV 3819 05 ; Attribute length: 20 octets (5*4) 3820 00 00 ; (reserved) 3821 9e 18 b0 c2 ; IV value 3822 9a 65 22 63 3823 c0 6e fb 54 3824 dd 00 a8 95 3825 82 ; Attribute type: AT_ENCR_DATA 3826 2d ; Attribute length: 180 octets (45*4) 3827 00 00 ; (reserved) 3828 55 f2 93 9b bd b1 b1 9e a1 b4 7f c0 b3 e0 be 4c 3829 ab 2c f7 37 2d 98 e3 02 3c 6b b9 24 15 72 3d 58 3830 ba d6 6c e0 84 e1 01 b6 0f 53 58 35 4b d4 21 82 3831 78 ae a7 bf 2c ba ce 33 10 6a ed dc 62 5b 0c 1d 3832 5a a6 7a 41 73 9a e5 b5 79 50 97 3f c7 ff 83 01 3833 07 3c 6f 95 31 50 fc 30 3e a1 52 d1 e1 0a 2d 1f 3834 4f 52 26 da a1 ee 90 05 47 22 52 bd b3 b7 1d 6f 3835 0c 3a 34 90 31 6c 46 92 98 71 bd 45 cd fd bc a6 3836 11 2f 07 f8 be 71 79 90 d2 5f 6d d7 f2 b7 b3 20 3837 bf 4d 5a 99 2e 88 03 31 d7 29 94 5a ec 75 ae 5d 3838 43 c8 ed a5 fe 62 33 fc ac 49 4e e6 7a 0d 50 4d 3839 0b ; Attribute type: AT_MAC 3840 05 ; Attribute length: 20 octets (5*4) 3841 00 00 ; (reserved) 3842 fe f3 24 ac ; MAC value 3843 39 62 b5 9f 3844 3b d7 82 53 3845 ae 4d cb 6a 3847 The MAC is calculated over the EAP packet above (with MAC value set 3848 to zero), followed by the NONCE_MT value (a total of 296 bytes). 3850 A.6 EAP-Response/SIM/Challenge 3852 The client's response looks like this: 3854 02 ; Code: Response 3855 02 ; Identifier: 2 3856 00 1c ; Length: 28 octets 3857 12 ; Type: EAP-SIM 3858 0b ; EAP-SIM subtype: Challenge 3859 00 00 ; (reserved) 3860 0b ; Attribute type: AT_MAC 3861 05 ; Attribute length: 20 octets (5*4) 3862 00 00 ; (reserved) 3863 f5 6d 64 33 ; MAC value 3864 e6 8e d2 97 3865 6a c1 19 37 3866 fc 3d 11 54 3868 The MAC is calculated over the EAP packet above (with MAC value set 3869 to zero), followed by the SRES values (a total of 40 bytes). 3871 A.7 EAP-Success 3873 The last packet is an EAP-Success: 3875 03 ; Code: Success 3876 02 ; Identifier: 2 3877 00 04 ; Length: 4 octets 3879 A.8 Fast Re-authentication 3881 When performing fast re-authentication, the EAP-Request/Identity 3882 packet is the same as usual. The EAP-Response/Identity contains the 3883 fast re-authentication identity (from AT_ENCR_DATA attribute above): 3885 02 ; Code: Response 3886 00 ; Identifier: 0 3887 00 56 ; Length: 86 octets 3888 01 ; Type: Identity 3889 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f 3890 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30 3891 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f 3892 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b 3893 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f 3894 6f 3896 A.9 EAP-Request/SIM/Re-authentication 3898 The server recognizes the reauthentication identity, so it will 3899 respond with EAP-Request/SIM/Re-authentication. It retrieves the 3900 associated counter value, generates a nonce, and picks a new 3901 reauthentication identity (in this case, 3902 "uta0M0iyIsMwWp5TTdSdnOLvg2XDVf21OYt1vnfiMcs5dnIDHOIFVavIRzMR 3903 yzW6vFzdHW@eapsim.foo"). 3905 The following plaintext will be encrypted and stored in the 3906 AT_ENCR_DATA attribute. Note that AT_PADDING is not used because the 3907 length of the plaintext is a multiple of 16 bytes. 3909 13 ; Attribute type: AT_COUNTER 3910 01 ; Attribute length: 4 octets (1*4) 3911 00 01 ; Counter value 3912 15 ; Attribute type: AT_NONCE_S 3913 05 ; Attribute length: 20 octets (5*4) 3914 00 00 ; (reserved) 3915 01 23 45 67 ; NONCE_S value 3916 89 ab cd ef 3917 fe dc ba 98 3918 76 54 32 10 3919 85 ; Attribute type: AT_NEXT_REAUTH_ID 3920 16 ; Attribute length: 88 octets (22*4) 3921 00 51 ; Actual re-auth identity length: 81 octets 3922 75 74 61 30 4d 30 69 79 49 73 4d 77 57 70 35 54 3923 54 64 53 64 6e 4f 4c 76 67 32 58 44 56 66 32 31 3924 4f 59 74 31 76 6e 66 69 4d 63 73 35 64 6e 49 44 3925 48 4f 49 46 56 61 76 49 52 7a 4d 52 79 7a 57 36 3926 76 46 7a 64 48 57 40 65 61 70 73 69 6d 2e 66 6f 3927 6f 3928 00 00 00 ; (attribute padding) 3930 The EAP packet looks like this: 3932 01 ; Code: Request 3933 01 ; Identifier: 1 3934 00 a4 ; Length: 164 octets 3935 12 ; Type: EAP-SIM 3936 0d ; EAP-SIM subtype: Re-authentication 3937 00 00 ; (reserved) 3938 81 ; Attribute type: AT_IV 3939 05 ; Attribute length: 20 octets (5*4) 3940 00 00 ; (reserved) 3941 d5 85 ac 77 ; IV value 3942 86 b9 03 36 3943 65 7c 77 b4 3944 65 75 b9 c4 3945 82 ; Attribute type: AT_ENCR_DATA 3946 1d ; Attribute length: 116 octets (29*4) 3947 00 00 ; (reserved) 3948 68 62 91 a9 d2 ab c5 8c aa 32 94 b6 e8 5b 44 84 3949 6c 44 e5 dc b2 de 8b 9e 80 d6 9d 49 85 8a 5d b8 3950 4c dc 1c 9b c9 5c 01 b9 6b 6e ca 31 34 74 ae a6 3951 d3 14 16 e1 9d aa 9d f7 0f 05 00 88 41 ca 80 14 3952 96 4d 3b 30 a4 9b cf 43 e4 d3 f1 8e 86 29 5a 4a 3953 2b 38 d9 6c 97 05 c2 bb b0 5c 4a ac e9 7d 5e af 3954 f5 64 04 6c 8b d3 0b c3 9b e5 e1 7a ce 2b 10 a6 3955 0b ; Attribute type: AT_MAC 3956 05 ; Attribute length: 20 octets (5*4) 3957 00 00 ; (reserved) 3958 48 3a 17 99 ; MAC value 3959 b8 3d 7c d3 3960 d0 a1 e4 01 3961 d9 ee 47 70 3963 The MAC is calculated over the EAP packet above (with MAC value set 3964 to zero; a total of 164 bytes). 3966 Finally, the server derives new keys. The XKEY' is calculated as 3967 described in Section 6.4: 3969 XKEY' = 863dc120 32e08343 c1a2308d b48377f6 801f58d4 3971 The new MSK and EMSK are derived using the PRNG (note that K_encr and 3972 K_aut stay the same). 3974 MSK = 6263f614 973895e1 335f7e30 cff028ee 3975 2176f519 002c9abe 732fe0ef 00cf167c 3976 756d9e4c ed6d5ed6 40eb3fe3 8565ca07 3977 6e7fb8a8 17cfe8d9 adbce441 d47c4f5e 3978 EMSK = 3d8ff786 3a630b2b 06e2cf20 9684c13f 3979 6b82f992 f2b06f1b 54bf51ef 237f2a40 3980 1ef5e0d7 e098a34c 533eaebf 34578854 3981 b7721526 20a777f0 e0340884 a294fb73 3983 A.10 EAP-Response/SIM/Re-authentication 3985 The client's response includes the counter as well. The following 3986 plaintext will be encrypted and stored in the AT_ENCR_DATA attribute: 3988 13 ; Attribute type: AT_COUNTER 3989 01 ; Attribute length: 4 octets (1*4) 3990 00 01 ; Counter value 3991 06 ; Attribute type: AT_PADDING 3992 03 ; Attribute length: 12 octets (3*4) 3993 00 00 00 00 3994 00 00 00 00 3995 00 00 3997 The EAP packet looks like this: 3999 02 ; Code: Response 4000 01 ; Identifier: 1 4001 00 44 ; Length: 68 octets 4002 12 ; Type: EAP-SIM 4003 0d ; EAP-SIM subtype: Re-authentication 4004 00 00 ; (reserved) 4005 81 ; Attribute type: AT_IV 4006 05 ; Attribute length: 20 octets (5*4) 4007 00 00 ; (reserved) 4008 cd f7 ff a6 ; IV value 4009 5d e0 4c 02 4010 6b 56 c8 6b 4011 76 b1 02 ea 4012 82 ; Attribute type: AT_ENCR_DATA 4013 05 ; Attribute length: 20 octets (5*4) 4014 00 00 ; (reserved) 4015 b6 ed d3 82 4016 79 e2 a1 42 4017 3c 1a fc 5c 4018 45 5c 7d 56 4019 0b ; Attribute type: AT_MAC 4020 05 ; Attribute length: 20 octets (5*4) 4021 00 00 ; (reserved) 4022 fa f7 6b 71 ; MAC value 4023 fb e2 d2 55 4024 b9 6a 35 66 4025 c9 15 c6 17 4027 The MAC is calculated over the EAP packet above (with MAC value set 4028 to zero), followed by the NONCE_S value (a total of 84 bytes). 4030 The next packet will be EAP-Success: 4032 03 ; Code: Success 4033 01 ; Identifier: 1 4034 00 04 ; Length: 4 octets 4036 Appendix B. Pseudo-Random Number Generator 4038 The "|" character denotes concatenation, and "^" denotes 4039 exponentiation. 4041 Step 1: Choose a new, secret value for the seed-key, XKEY 4043 Step 2: In hexadecimal notation let 4044 t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 4045 This is the initial value for H0|H1|H2|H3|H4 4046 in the FIPS SHS [SHA-1] 4048 Step 3: For j = 0 to m - 1 do 4049 3.1 XSEED_j = 0 /* no optional user input */ 4050 3.2 For i = 0 to 1 do 4051 a. XVAL = (XKEY + XSEED_j) mod 2^b 4052 b. w_i = G(t, XVAL) 4053 c. XKEY = (1 + XKEY + w_i) mod 2^b 4054 3.3 x_j = w_0|w_1 4056 Intellectual Property Statement 4058 The IETF takes no position regarding the validity or scope of any 4059 Intellectual Property Rights or other rights that might be claimed to 4060 pertain to the implementation or use of the technology described in 4061 this document or the extent to which any license under such rights 4062 might or might not be available; nor does it represent that it has 4063 made any independent effort to identify any such rights. Information 4064 on the procedures with respect to rights in RFC documents can be 4065 found in BCP 78 and BCP 79. 4067 Copies of IPR disclosures made to the IETF Secretariat and any 4068 assurances of licenses to be made available, or the result of an 4069 attempt made to obtain a general license or permission for the use of 4070 such proprietary rights by implementers or users of this 4071 specification can be obtained from the IETF on-line IPR repository at 4072 http://www.ietf.org/ipr. 4074 The IETF invites any interested party to bring to its attention any 4075 copyrights, patents or patent applications, or other proprietary 4076 rights that may cover technology that may be required to implement 4077 this standard. Please address the information to the IETF at 4078 ietf-ipr@ietf.org. 4080 The IETF has been notified of intellectual property rights claimed in 4081 regard to some or all of the specification contained in this 4082 document. For more information consult the online list of claimed 4083 rights. 4085 Disclaimer of Validity 4087 This document and the information contained herein are provided on an 4088 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4089 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4090 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4091 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4092 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4093 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4095 Copyright Statement 4097 Copyright (C) The Internet Society (2004). This document is subject 4098 to the rights, licenses and restrictions contained in BCP 78, and 4099 except as set forth therein, the authors retain all their rights. 4101 Acknowledgment 4103 Funding for the RFC Editor function is currently provided by the 4104 Internet Society.