idnits 2.17.1 draft-arkko-pppext-eap-aka-15.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 3552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3537. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 7065 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PRF' ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-09 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-02 -- Duplicate reference: draft-josefsson-pppext-eap-tls-eap, mentioned in 'PEAP-02', was also mentioned in 'PEAP'. -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) == Outdated reference: A later version (-16) exists of draft-haverinen-pppext-eap-sim-15 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Arkko 2 Internet-Draft Ericsson 3 Expires: June 21, 2005 H. Haverinen 4 Nokia 5 December 21, 2004 7 Extensible Authentication Protocol Method for 3rd Generation 8 Authentication and Key Agreement (EAP-AKA) 9 draft-arkko-pppext-eap-aka-15.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-AKA protocol was developed by 3GPP. The documentation of 45 EAP-AKA is provided as information to the Internet community. While 46 the EAP WG has verified that EAP-AKA 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 Authentication and Key Agreement (AKA) mechanism used in the 3rd 55 generation mobile networks Universal Mobile Telecommunications System 56 (UMTS) and cdma2000. AKA is based on symmetric keys, and runs 57 typically in a Subscriber Identity Module (UMTS Subscriber Identity 58 Module USIM, or (Removable) User Identity Module (R)UIM), a smart 59 card like device. 61 EAP-AKA includes optional identity privacy support, optional result 62 indications, and an optional fast re-authentication procedure. 64 Table of Contents 66 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 5 67 2. Terms and Conventions Used in This Document . . . . . . . . . 6 68 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 69 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4.1 Identity Management . . . . . . . . . . . . . . . . . . . 15 71 4.1.1 Format, Generation and Usage of Peer Identities . . . 16 72 4.1.2 Communicating the Peer Identity to the Server . . . . 22 73 4.1.3 Choice of Identity for the EAP-Response/Identity . . . 23 74 4.1.4 Server Operation in the Beginning of EAP-AKA 75 Exchange . . . . . . . . . . . . . . . . . . . . . . . 24 76 4.1.5 Processing of EAP-Request/AKA-Identity by the Peer . . 24 77 4.1.6 Attacks against Identity Privacy . . . . . . . . . . . 26 78 4.1.7 Processing of AT_IDENTITY by the Server . . . . . . . 26 79 4.2 Message Sequence Examples (Informative) . . . . . . . . . 27 80 4.2.1 Usage of AT_ANY_ID_REQ . . . . . . . . . . . . . . . . 27 81 4.2.2 Fall Back on Full Authentication . . . . . . . . . . . 28 82 4.2.3 Requesting the Permanent Identity 1 . . . . . . . . . 29 83 4.2.4 Requesting the Permanent Identity 2 . . . . . . . . . 30 84 4.2.5 Three EAP/AKA-Identity Round Trips . . . . . . . . . . 31 85 5. Fast Re-authentication . . . . . . . . . . . . . . . . . . . . 33 86 5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 33 87 5.2 Comparison to AKA . . . . . . . . . . . . . . . . . . . . 34 88 5.3 Fast Re-authentication Identity . . . . . . . . . . . . . 35 89 5.4 Fast Re-authentication Procedure . . . . . . . . . . . . . 36 90 5.5 Fast Re-authentication Procedure when Counter is Too 91 Small . . . . . . . . . . . . . . . . . . . . . . . . . . 38 92 6. EAP-AKA Notifications . . . . . . . . . . . . . . . . . . . . 40 93 6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 40 94 6.2 Result Indications . . . . . . . . . . . . . . . . . . . . 41 95 6.3 Error Cases . . . . . . . . . . . . . . . . . . . . . . . 42 96 6.3.1 Peer Operation . . . . . . . . . . . . . . . . . . . . 42 97 6.3.2 Server Operation . . . . . . . . . . . . . . . . . . . 43 98 6.3.3 EAP-Failure . . . . . . . . . . . . . . . . . . . . . 44 99 6.3.4 EAP-Success . . . . . . . . . . . . . . . . . . . . . 44 100 6.4 Key Generation . . . . . . . . . . . . . . . . . . . . . . 45 101 7. Message Format and Protocol Extensibility . . . . . . . . . . 47 102 7.1 Message Format . . . . . . . . . . . . . . . . . . . . . . 47 103 7.2 Protocol Extensibility . . . . . . . . . . . . . . . . . . 49 104 8. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 105 8.1 EAP-Request/AKA-Identity . . . . . . . . . . . . . . . . . 49 106 8.2 EAP-Response/AKA-Identity . . . . . . . . . . . . . . . . 50 107 8.3 EAP-Request/AKA-Challenge . . . . . . . . . . . . . . . . 50 108 8.4 EAP-Response/AKA-Challenge . . . . . . . . . . . . . . . . 51 109 8.5 EAP-Response/AKA-Authentication-Reject . . . . . . . . . . 52 110 8.6 EAP-Response/AKA-Synchronization-Failure . . . . . . . . . 52 111 8.7 EAP-Request/AKA-Reauthentication . . . . . . . . . . . . . 52 112 8.8 EAP-Response/AKA-Reauthentication . . . . . . . . . . . . 52 113 8.9 EAP-Response/AKA-Client-Error . . . . . . . . . . . . . . 53 114 8.10 EAP-Request/AKA-Notification . . . . . . . . . . . . . . . 53 115 8.11 EAP-Response/AKA-Notification . . . . . . . . . . . . . . 54 116 9. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 54 117 9.1 Table of Attributes . . . . . . . . . . . . . . . . . . . 54 118 9.2 AT_PERMANENT_ID_REQ . . . . . . . . . . . . . . . . . . . 55 119 9.3 AT_ANY_ID_REQ . . . . . . . . . . . . . . . . . . . . . . 56 120 9.4 AT_FULLAUTH_ID_REQ . . . . . . . . . . . . . . . . . . . . 56 121 9.5 AT_IDENTITY . . . . . . . . . . . . . . . . . . . . . . . 56 122 9.6 AT_RAND . . . . . . . . . . . . . . . . . . . . . . . . . 57 123 9.7 AT_AUTN . . . . . . . . . . . . . . . . . . . . . . . . . 57 124 9.8 AT_RES . . . . . . . . . . . . . . . . . . . . . . . . . . 58 125 9.9 AT_AUTS . . . . . . . . . . . . . . . . . . . . . . . . . 58 126 9.10 AT_NEXT_PSEUDONYM . . . . . . . . . . . . . . . . . . . . 58 127 9.11 AT_NEXT_REAUTH_ID . . . . . . . . . . . . . . . . . . . . 59 128 9.12 AT_IV, AT_ENCR_DATA and AT_PADDING . . . . . . . . . . . . 60 129 9.13 AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . . . . 62 130 9.14 AT_RESULT_IND . . . . . . . . . . . . . . . . . . . . . . 64 131 9.15 AT_MAC . . . . . . . . . . . . . . . . . . . . . . . . . . 64 132 9.16 AT_COUNTER . . . . . . . . . . . . . . . . . . . . . . . . 65 133 9.17 AT_COUNTER_TOO_SMALL . . . . . . . . . . . . . . . . . . . 65 134 9.18 AT_NONCE_S . . . . . . . . . . . . . . . . . . . . . . . . 66 135 9.19 AT_NOTIFICATION . . . . . . . . . . . . . . . . . . . . . 66 136 9.20 AT_CLIENT_ERROR_CODE . . . . . . . . . . . . . . . . . . . 67 137 10. IANA and Protocol Numbering Considerations . . . . . . . . . 68 138 11. Security Considerations . . . . . . . . . . . . . . . . . . 70 139 11.1 Identity Protection . . . . . . . . . . . . . . . . . . . 70 140 11.2 Mutual Authentication . . . . . . . . . . . . . . . . . . 71 141 11.3 Flooding the Authentication Centre . . . . . . . . . . . . 71 142 11.4 Key Derivation . . . . . . . . . . . . . . . . . . . . . . 71 143 11.5 Brute-Force and Dictionary Attacks . . . . . . . . . . . . 71 144 11.6 Protection, Replay Protection and Confidentiality . . . . 72 145 11.7 Negotiation Attacks . . . . . . . . . . . . . . . . . . . 73 146 11.8 Protected Result Indications . . . . . . . . . . . . . . . 73 147 11.9 Man-in-the-middle Attacks . . . . . . . . . . . . . . . . 74 148 11.10 Generating Random Numbers . . . . . . . . . . . . . . . 74 149 12. Security Claims . . . . . . . . . . . . . . . . . . . . . . 74 150 13. Acknowledgements and Contributions . . . . . . . . . . . . . 75 151 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 75 152 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 75 153 14.2 Informative References . . . . . . . . . . . . . . . . . . . 77 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 78 155 A. Pseudo-Random Number Generator . . . . . . . . . . . . . . . . 78 156 Intellectual Property and Copyright Statements . . . . . . . . 79 158 1. Introduction and Motivation 160 This document specifies an Extensible Authentication Protocol (EAP) 161 mechanism for authentication and session key distribution using the 162 3rd generation Authentication and Key Agreement mechanism, specified 163 for Universal Mobile Telecommunications System (UMTS) in [TS 33.102] 164 and for cdma2000 in [S.S0055-A]. UMTS and cdma2000 are global third 165 generation mobile network standards that use the same AKA mechanism. 167 Second generation mobile networks and third generation mobile 168 networks use different authentication and key agreement mechanisms. 169 The Global System for Mobile communications (GSM) is a 2nd generation 170 mobile network standard, and EAP-SIM [EAP-SIM] specifies an EAP 171 mechanism that is based on the GSM authentication and key agreement 172 primitives. 174 AKA is based on challenge-response mechanisms and symmetric 175 cryptography. AKA typically runs in a UMTS Subscriber Identity 176 Module (USIM) or a cdma2000 (Removable) User Identity Module 177 ((R)UIM). In this document, both modules are referred to as identity 178 modules. Compared to the 2nd generation mechanisms such as GSM AKA, 179 the 3rd generation AKA provides substantially longer key lengths and 180 mutual authentication. 182 The introduction of AKA inside EAP allows several new applications. 183 These include the following: 185 o The use of the AKA also as a secure PPP authentication method in 186 devices that already contain an identity module. 187 o The use of the third generation mobile network authentication 188 infrastructure in the context of wireless LANs 189 o Relying on AKA and the existing infrastructure in a seamless way 190 with any other technology that can use EAP. 192 AKA works in the following manner: 194 o The identity module and the home environment have agreed on a 195 secret key beforehand. (The "home environment" refers to the home 196 operator's authentication network infrastructure.) 197 o The actual authentication process starts by having the home 198 environment produce an authentication vector, based on the secret 199 key and a sequence number. The authentication vector contains a 200 random part RAND, an authenticator part AUTN used for 201 authenticating the network to the identity module, an expected 202 result part XRES, a 128-bit session key for integrity check IK, 203 and a 128-bit session key for encryption CK. 204 o The RAND and the AUTN are delivered to the identity module. 206 o The identity module verifies the AUTN, again based on the secret 207 key and the sequence number. If this process is successful (the 208 AUTN is valid and the sequence number used to generate AUTN is 209 within the correct range), the identity moduleproduces an 210 authentication result, RES and sends this to the home environment. 211 o The home environment verifies the correct result from the identity 212 module. If the result is correct, IK and CK can be used to 213 protect further communications between the identity module and the 214 home environment. 216 When verifying AUTN, the identity module may detect that the sequence 217 number the network uses is not within the correct range. In this 218 case, the identity module calculates a sequence number 219 synchronization parameter AUTS and sends it to the network. AKA 220 authentication may then be retried with a new authentication vector 221 generated using the synchronized sequence number. 223 For a specification of the AKA mechanisms and how the cryptographic 224 values AUTN, RES, IK, CK and AUTS are calculated, see [TS 33.102] for 225 UMTS and [S.S0055-A] for cdma2000. 227 In EAP-AKA, the EAP server node obtains the authentication vectors, 228 compares RES and XRES, and uses CK and IK in key derivation. 230 In the third generation mobile networks, AKA is used both for radio 231 network authentication and IP multimedia service authentication 232 purposes. Different user identities and formats are used for these; 233 the radio network uses the International Mobile Subscriber Identifier 234 (IMSI), whereas the IP multimedia service uses the Network Access 235 Identifier (NAI) [RFC2486]. 237 2. Terms and Conventions Used in This Document 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in [RFC2119]. 243 The terms and abbreviations "authenticator", "backend authentication 244 server", "EAP server", "peer", "Silently Discard", "Master Session 245 Key (MSK)", and "Extended Master Session Key (EMSK)" in this document 246 are to be interpreted as described in [RFC3748]. 248 This document frequently uses the following terms and abbreviations. 249 The AKA parameters are specified in detail in [TS 33.102] for UMTS 250 and [S.S0055-A] for cdma2000. 252 AAA protocol 253 Authentication, Authorization and Accounting protocol 255 AKA 257 Authentication and Key Agreement 259 AuC 261 Authentication Centre. The mobile network element that can 262 authenticate subscribers in the mobile networks. 264 AUTN 266 AKA parameter. AUTN is an authentication value generated by 267 the AuC which together with the RAND authenticates the server 268 to the peer, 128 bits 270 AUTS 272 AKA parameter. A value generated by the peer upon 273 experiencing a synchronization failure, 112 bits. 275 EAP 277 Extensible Authentication Protocol 278 [RFC3748] 280 Fast re-authentication 282 An EAP-AKA authentication exchange that is based on keys 283 derived upon a preceding full authentication exchange. The 284 3rd Generation AKA is not used in the fast re-authentication 285 procedure. 287 Fast Re-authentication Identity 289 A fast re-authentication identity of the peer, including an 290 NAI realm portion in environments where a realm is used. 291 Used on re-authentication only. 293 Fast Re-authentication Username 295 The username portion of fast re-authentication identity, 296 ie. not including any realm portions. 298 Full authentication 300 An EAP-AKA authentication exchange that is based on the 301 3rd Generation AKA procedure. 303 GSM 305 Global System for Mobile communications. 307 NAI 309 Network Access Identifier 310 [RFC2486] 312 Identity module 314 Identity module is used in this document to refer to the 315 part of the mobile device that contains authentication and 316 key agreement primitives. The identity module may be an 317 integral part of the mobile device or it can be an application 318 on a smart card distributed by a mobile operator. USIM and 319 (R)UIM are identity modules. 321 Nonce 323 A value that is used at most once or that is never repeated 324 within the same cryptographic context. In general, a nonce can 325 be predictable (e.g. a counter) or unpredictable (e.g. a random 326 value). Since some cryptographic properties may depend on the 327 randomness of the nonce, attention should be paid to whether a 328 nonce is required to be random or not. In this document, the 329 term nonce is only used to denote random nonces, and it is not 330 used to denote counters. 332 Permanent Identity 334 The permanent identity of the peer, including an NAI realm 335 portion in environments where a realm is used. The permanent 336 identity is usually based on the IMSI. Used on full 337 authentication only. 339 Permanent Username 341 The username portion of permanent identity, ie. not including 342 any realm portions. 344 Pseudonym Identity 346 A pseudonym identity of the peer, including an NAI realm 347 portion in environments where a realm is used. Used on full 348 authentication only. 350 Pseudonym Username 352 The username portion of pseudonym identity, ie. not including 353 any realm portions. 355 RAND 357 An AKA parameter. Random number generated by the AuC, 128 bits 359 RES 361 Authentication result from the peer, which together with 362 the RAND authenticates the peer to the server, 363 128 bits 365 (R)UIM 367 cdma2000 (Removable) User Identity Module. (R)UIM is an 368 application that is resident e.g. on smart cards which may 369 be fixed in the terminal or distributed by cdma2000 370 operators (when removable) 372 SQN 374 An AKA parameter. Sequence number used in the authentication 375 process, 48 bits 377 SIM 379 Subscriber Identity Module. The SIM is traditionally a smart 380 card distributed by a GSM operator. 382 SRES 384 The authentication result parameter in GSM, corresponds to 385 the RES parameter in 3G AKA, 32 bits. 387 UAK 389 UIM Authentication Key, used in cdma2000 AKA. Both the identity 390 module and the network can optionally generate the UAK during 391 the AKA computation in cdma2000. UAK is not used in this 392 version of EAP-AKA. 394 UIM 396 Please see (R)UIM 398 USIM 400 UMTS Subscriber Identity Module. USIM is an application that 401 is resident e.g. on smart cards distributed by UMTS operators. 403 3. Protocol Overview 405 Figure 1 shows the basic successful full authentication exchange in 406 EAP-AKA, when optional result indications are not used. The 407 authenticator typically communicates with an EAP server that is 408 located on a backend authentication server using an AAA protocol. 409 The authenticator shown in the figure is often simply relaying EAP 410 messages to and from the EAP server, but these back end AAA 411 communications are not shown. At the minimum, EAP-AKA uses two 412 roundtrips to authenticate and authorize the peer and generate 413 session keys. As in other EAP schemes, an identity request/response 414 message pair is usually exchanged first. On full authentication, the 415 peer's identity response includes either the user's International 416 Mobile Subscriber Identity (IMSI), or a temporary identity 417 (pseudonym) if identity privacy is in effect, as specified in Section 418 4.1. (As specified in [RFC3748], the initial identity request is not 419 required, and MAY be bypassed in cases where the network can presume 420 the identity, such as when using leased lines, dedicated dial-ups, 421 etc. Please see also Section 4.1.2 for specification how to obtain 422 the identity via EAP AKA messages.) 424 After obtaining the subscriber identity, the EAP server obtains an 425 authentication vector (RAND, AUTN, RES, CK, IK) for use in 426 authenticating the subscriber. From the vector, the EAP server 427 derives the keying material, as specified in Section 6.4. The vector 428 may be obtained by contacting an Authentication Centre (AuC) on the 429 mobile network; for example per UMTS specifications, several vectors 430 may be obtained at a time. Vectors may be stored in the EAP server 431 for use at a later time, but they may not be reused. 433 In cdma2000, the vector may include a sixth value called the User 434 Identity Module Authentication Key (UAK). This key is not used in 435 EAP-AKA. 437 Next, the EAP server starts the actual AKA protocol by sending an 438 EAP-Request/AKA-Challenge message. EAP-AKA packets encapsulate 439 parameters in attributes, encoded in a Type, Length, Value format. 440 The packet format and the use of attributes are specified in Section 441 7. The EAP-Request/AKA-Challenge message contains a RAND random 442 number (AT_RAND) and a network authentication token (AT_AUTN), and a 443 message authentication code AT_MAC. The EAP-Request/AKA-Challenge 444 message MAY optionally contain encrypted data, which is used for 445 identity privacy and fast re-authentication support, as described in 446 Section 4.1. The AT_MAC attribute contains a message authentication 447 code covering the EAP packet. The encrypted data is not shown in the 448 figures of this section. 450 The peer runs the AKA algorithm (typically using an identity module) 451 and verifies the AUTN. If this is successful, the peer is talking to 452 a legitimate EAP server and proceeds to send the 453 EAP-Response/AKA-Challenge. This message contains a result parameter 454 that allows the EAP server in turn to authenticate the peer, and the 455 AT_MAC attribute to integrity protect the EAP message. 457 The EAP server verifies that the RES and the MAC in the 458 EAP-Response/AKA-Challenge packet are correct. Because protected 459 success indications are not used in this example, the EAP server 460 sends the EAP-Success packet, indicating that the authentication was 461 successful. (Protected success indications are discussed in Section 462 6.2.) The EAP server may also include derived keying material in the 463 message it sends to the authenticator. The peer has derived the same 464 keying material, so the authenticator does not forward the keying 465 material to the peer along with EAP-Success. 467 Peer Authenticator 468 | EAP-Request/Identity | 469 |<------------------------------------------------------| 470 | | 471 | EAP-Response/Identity | 472 | (Includes user's NAI) | 473 |------------------------------------------------------>| 474 | +------------------------------+ 475 | | Server runs AKA algorithms, | 476 | | generates RAND and AUTN. | 477 | +------------------------------+ 478 | EAP-Request/AKA-Challenge | 479 | (AT_RAND, AT_AUTN, AT_MAC) | 480 |<------------------------------------------------------| 481 +-------------------------------------+ | 482 | Peer runs AKA algorithms, | | 483 | verifies AUTN and MAC, derives RES | | 484 | and session key | | 485 +-------------------------------------+ | 486 | EAP-Response/AKA-Challenge | 487 | (AT_RES, AT_MAC) | 488 |------------------------------------------------------>| 489 | +--------------------------------+ 490 | | Server checks the given RES, | 491 | | and MAC and finds them correct.| 492 | +--------------------------------+ 493 | EAP-Success | 494 |<------------------------------------------------------| 496 Figure 1: EAP-AKA full authentication procedure 498 Figure 2 shows how the EAP server rejects the Peer due to a failed 499 authentication. 501 Peer Authenticator 502 | EAP-Request/Identity | 503 |<------------------------------------------------------| 504 | | 505 | EAP-Response/Identity | 506 | (Includes user's NAI) | 507 |------------------------------------------------------>| 508 | +------------------------------+ 509 | | Server runs AKA algorithms, | 510 | | generates RAND and AUTN. | 511 | +------------------------------+ 512 | EAP-Request/AKA-Challenge | 513 | (AT_RAND, AT_AUTN, AT_MAC) | 514 |<------------------------------------------------------| 515 +-------------------------------------+ | 516 | Peer runs AKA algorithms, | | 517 | possibly verifies AUTN, and sends an| | 518 | invalid response | | 519 +-------------------------------------+ | 520 | EAP-Response/AKA-Challenge | 521 | (AT_RES, AT_MAC) | 522 |------------------------------------------------------>| 523 | +------------------------------------------+ 524 | | Server checks the given RES and the MAC, | 525 | | and finds one of them incorrct. | 526 | +------------------------------------------+ 527 | EAP-Request/AKA-Notification | 528 |<------------------------------------------------------| 529 | EAP-Response/AKA-Notification | 530 |------------------------------------------------------>| 531 | EAP-Failure | 532 |<------------------------------------------------------| 534 Figure 2: Peer authentication fails 536 Figure 3 shows the peer rejecting the AUTN of the EAP server. 538 The peer sends an explicit error message 539 (EAP-Response/AKA-Authentication-Reject) to the EAP server, as usual 540 in AKA when AUTN is incorrect. This allows the EAP server to produce 541 the same error statistics as AKA in general produces in UMTS or 542 cdma2000. 544 Peer Authenticator 545 | EAP-Request/Identity | 546 |<------------------------------------------------------| 547 | EAP-Response/Identity | 548 | (Includes user's NAI) | 549 |------------------------------------------------------>| 550 | +------------------------------+ 551 | | Server runs AKA algorithms, | 552 | | generates RAND and a bad AUTN| 553 | +------------------------------+ 554 | EAP-Request/AKA-Challenge | 555 | (AT_RAND, AT_AUTN, AT_MAC) | 556 |<------------------------------------------------------| 557 +-------------------------------------+ | 558 | Peer runs AKA algorithms | | 559 | and discovers AUTN that can not be | | 560 | verified | | 561 +-------------------------------------+ | 562 | EAP-Response/AKA-Authentication-Reject | 563 |------------------------------------------------------>| 564 | EAP-Failure | 565 |<------------------------------------------------------| 567 Figure 3: Network authentication fails 569 The AKA uses shared secrets between the Peer and the Peer's home 570 operator together with a sequence number to actually perform an 571 authentication. In certain circumstances it is possible for the 572 sequence numbers to get out of sequence. Figure 4 shows what happens 573 then. 575 Peer Authenticator 576 | EAP-Request/Identity | 577 |<------------------------------------------------------| 578 | EAP-Response/Identity | 579 | (Includes user's NAI) | 580 |------------------------------------------------------>| 581 | +------------------------------+ 582 | | Server runs AKA algorithms, | 583 | | generates RAND and AUTN. | 584 | +------------------------------+ 585 | EAP-Request/AKA-Challenge | 586 | (AT_RAND, AT_AUTN, AT_MAC) | 587 |<------------------------------------------------------| 588 +-------------------------------------+ | 589 | Peer runs AKA algorithms | | 590 | and discovers AUTN that contains an | | 591 | inappropriate sequence number | | 592 +-------------------------------------+ | 593 | EAP-Response/AKA-Synchronization-Failure | 594 | (AT_AUTS) | 595 |------------------------------------------------------>| 596 | +---------------------------+ 597 | | Perform resynchronization | 598 | | Using AUTS and | 599 | | the sent RAND | 600 | +---------------------------+ 601 | | 603 Figure 4: Sequence number synchronization 605 After the resynchronization process has taken place in the server and 606 AAA side, the process continues by the server side sending a new 607 EAP-Request/AKA-Challenge message. 609 In addition to the full authentication scenarios described above, 610 EAP-AKA includes a fast re-authentication procedure, which is 611 specified in Section 5. Fast re-authentication is based on keys 612 derived on full authentication. If the peer has maintained state 613 information for re-authentication and wants to use fast 614 re-authentication, then the peer indicates this by using a specific 615 fast re-authentication identity instead of the permanent identity or 616 a pseudonym identity. 618 4. Operation 620 4.1 Identity Management 621 4.1.1 Format, Generation and Usage of Peer Identities 623 4.1.1.1 General 625 In the beginning of EAP authentication, the Authenticator or the EAP 626 server usually issues the EAP-Request/Identity packet to the peer. 627 The peer responds with EAP-Response/Identity, which contains the 628 user's identity. The formats of these packets are specified in 629 [RFC3748]. 631 Subscribers of mobile networks are identified with the International 632 Mobile Subscriber Identity (IMSI) [TS 23.003]. The IMSI is a string 633 of not more than 15 digits. It is composed of a three digit Mobile 634 Country Code (MCC), a two or three digit Mobile Network Code (MNC) 635 and a not more than 10 digit Mobile Subscriber Identification Number 636 (MSIN). MCC and MNC uniquely identify the GSM operator and help 637 identify the AuC from which the authentication vectors need to be 638 retrieved for this subscriber. 640 Internet AAA protocols identify users with the Network Access 641 Identifier (NAI) [RFC2486]. When used in a roaming environment, the 642 NAI is composed of a username and a realm, separated with "@" 643 (username@realm). The username portion identifies the subscriber 644 within the realm. 646 This section specifies the peer identity format used in EAP-AKA. In 647 this document, the term identity or peer identity refers to the whole 648 identity string that is used to identify the peer. The peer identity 649 may include a realm portion. "Username" refers to the portion of the 650 peer identity that identifies the user, i.e. the username does not 651 include the realm portion. 653 4.1.1.2 Identity Privacy Support 655 EAP-AKA includes optional identity privacy (anonymity) support that 656 can be used to hide the cleartext permanent identity and thereby to 657 make the subscriber's EAP exchanges untraceable to eavesdroppers. 658 Because the permanent identity never changes, revealing it would help 659 observers to track the user. The permanent identity is usually based 660 on the IMSI, which may further help the tracking, because the same 661 identifier may be used in other contexts as well. Identity privacy 662 is based on temporary identities, or pseudonyms, which are equivalent 663 to but separate from the Temporary Mobile Subscriber Identities 664 (TMSI) that are used on cellular networks. Please see Section 11.1 665 for security considerations regarding identity privacy. 667 4.1.1.3 Username Types in EAP-AKA Identities 669 There are three types of usernames in EAP-AKA peer identities: 671 (1) Permanent usernames. For example, 672 0123456789098765@myoperator.com might be a valid permanent identity. 673 In this example, 0123456789098765 is the permanent username. 675 (2) Pseudonym usernames. For example, 2s7ah6n9q@myoperator.com might 676 be a valid pseudonym identity. In this example, 2s7ah6n9q is the 677 pseudonym username. 679 (3) Fast re-authentication usernames. For example, 680 43953754@myoperator.com might be a valid fast re-authentication 681 identity. In this case, 43953754 is the fast re-authentication 682 username. Unlike permanent usernames and pseudonym usernames, fast 683 re-authentication usernames are one-time identifiers, which are not 684 re-used across EAP exchanges. 686 The first two types of identities are only used on full 687 authentication and the last one only on fast re-authentication. When 688 the optional identity privacy support is not used, the non-pseudonym 689 permanent identity is used on full authentication. The fast 690 re-authentication exchange is specified in Section 5. 692 4.1.1.4 Username Decoration 694 In some environments, the peer may need to decorate the identity by 695 prepending or appending the username with a string, in order to 696 indicate supplementary AAA routing information in addition to the NAI 697 realm. (The usage of a NAI realm portion is not considered to be 698 decoration.) Username decoration is out of the scope of this 699 document. However, it should be noted that username decoration might 700 prevent the server from recognizing a valid username. Hence, 701 although the peer MAY use username decoration in the identities the 702 peer includes in EAP-Response/Identity, and the EAP server MAY accept 703 a decorated peer username in this message, the peer or the EAP server 704 MUST NOT decorate any other peer identities that are used in various 705 EAP-AKA attributes. Only the identity used in EAP-Response/Identity 706 may be decorated. 708 4.1.1.5 NAI Realm Portion 710 The peer MAY include a realm portion in the peer identity, as per the 711 NAI format. The use of a realm portion is not mandatory. 713 If a realm is used, the realm MAY be chosen by the subscriber's home 714 operator and it MAY a configurable parameter in the EAP-AKA peer 715 implementation. In this case, the peer is typically configured with 716 the NAI realm of the home operator. Operators MAY reserve a specific 717 realm name for EAP-AKA users. This convention makes it easy to 718 recognize that the NAI identifies an AKA subscriber. Such reserved 719 NAI realm may be useful as a hint as to the first authentication 720 method to use during method negotiation. When the peer is using a 721 pseudonym username instead of the permanent username, the peer 722 selects the realm name portion similarly as it select the realm 723 portion when using the permanent username. 725 If no configured realm name is available, the peer MAY derive the 726 realm name from the MCC and MNC portions of the IMSI. A RECOMMENDED 727 way to derive the realm from the IMSI using the realm 3gppnetwork.org 728 will be specified in [Draft 3GPP TS 23.003]. 730 Some old implementations derive the realm name from the IMSI by 731 concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits 732 of IMSI and ".owlan.org". For example, if the IMSI is 733 123456789098765, and the MNC is three digits long, then the derived 734 realm name is "mnc456.mcc123.owlan.org". As there are no DNS servers 735 running at owlan.org, these realm names can only be used with 736 manually configured AAA routing. New implementations SHOULD use the 737 mechanism specified in [Draft 3GPP TS 23.003] instead of owlan.org as 738 soon as the 3GPP specification is finalized. 740 The IMSI is a string of digits without any explicit structure, so the 741 peer may not be able to determine the length of the MNC portion. If 742 the peer is not able to determine whether the MNC is two or three 743 digits long, the peer MAY use a 3-digit MNC. If the correct length 744 of the MNC is two, then the MNC used in the realm name includes the 745 first digit of MSIN. Hence, when configuring AAA networks for 746 operators that have 2-digit MNC's, the network SHOULD also be 747 prepared for realm names with incorrect 3-digit MNC's. 749 4.1.1.6 Format of the Permanent Username 751 The non-pseudonym permanent username SHOULD be derived from the IMSI. 752 In this case, the permanent username MUST be of the format "0" | 753 IMSI, where the character "|" denotes concatenation. In other words, 754 the first character of the username is the digit zero (ASCII value 30 755 hexadecimal), followed by the IMSI. The IMSI is an ASCII string that 756 consists of not more than 15 decimal digits (ASCII values between 30 757 and 39 hexadecimal), one character per IMSI digit, in the order as 758 specified in [TS 23.003]. For example, a permanent username derived 759 from the IMSI 295023820005424 would be encoded as the ASCII string 760 "0295023820005424" (byte values in hexadecimal notation: 30 32 39 35 761 30 32 33 38 32 30 30 30 35 34 32 34) 762 The EAP server MAY use the leading "0" as a hint to try EAP-AKA as 763 the first authentication method during method negotiation, rather 764 than for example EAP-SIM. The EAP-AKA server MAY propose EAP-AKA 765 even if the leading character was not "0". 767 Alternatively, an implementation MAY choose a permanent username that 768 is not based on the IMSI. In this case the selection of the 769 username, its format, and its processing is out of the scope of this 770 document. In this case, the peer implementation MUST NOT prepend any 771 leading characters to the username. 773 4.1.1.7 Generating Pseudonyms and Fast Re-authentication Identities by 774 the Server 776 Pseudonym usernames and fast re-authentication identities are 777 generated by the EAP server. The EAP server produces pseudonym 778 usernames and fast re-authentication identities in an 779 implementation-dependent manner. Only the EAP server needs to be 780 able to map the pseudonym username to the permanent identity, or to 781 recognize a fast re-authentication identity. 783 EAP-AKA includes no provisions to ensure that the same EAP server 784 that generated a pseudonym username will be used on the 785 authentication exchange when the pseudonym username is used. It is 786 recommended that the EAP servers implement some centralized mechanism 787 to allow all EAP servers of the home operator to map pseudonyms 788 generated by other severs to the permanent identity. If no such 789 mechanism is available, then the EAP server failing to understand a 790 pseudonym issued by another server can request the peer to send the 791 permanent identity. 793 When issuing a fast re-authentication identity, the EAP server may 794 include a realm name in the identity to make the fast 795 re-authentication request be forwarded to the same EAP server. 797 When generating fast re-authentication identities, the server SHOULD 798 choose a fresh new fast re-authentication identity that is different 799 from the previous ones used after the same full authentication 800 exchange. A full authentication exchange and the associated fast 801 re-authentication exchanges are referred to here as the same "full 802 authentication context". The fast re-authentication identity SHOULD 803 include a random component. The random component works as a full 804 authentication context identifier. A context-specific fast 805 re-authentication identity can help the server to detect whether its 806 fast re-authentication state information matches the peer's fast 807 re-authentication state information (in other words whether the state 808 information is from the same full authentication exchange). The 809 random component also makes the fast re-authentication identities 810 unpredictable, so an attacker cannot initiate a fast 811 re-authentication exchange to get the server's 812 EAP-Request/AKA-Reauthentication packet. 814 Transmitting pseudonyms and fast re-authentication identities from 815 the server to the peer is discussed in Section 4.1.1.8. The 816 pseudonym is transmitted as a username, without an NAI realm, and the 817 fast re-authentication identity is transmitted as a complete NAI, 818 including a realm portion if a realm is required. The realm is 819 included in the fast re-authentication identity in order to allow the 820 server to include a server-specific realm. 822 Regardless of construction method, the pseudonym username MUST 823 conform to the grammar specified for the username portion of an NAI. 824 The fast re-authentication identity also MUST conform to the NAI 825 grammar. The EAP servers that the subscribers of an operator can use 826 MUST ensure that the pseudonym usernames and the username portions 827 used in fast re-authentication identities they generate are unique. 829 In any case, it is necessary that permanent usernames, pseudonym 830 usernames and fast re-authentication usernames are separate and 831 recognizable from each other. It is also desirable that EAP-SIM and 832 EAP-AKA user names be recognizable from each other as an aid for the 833 server to which method to offer. 835 In general, it is the task of the EAP server and the policies of its 836 administrator to ensure sufficient separation in the usernames. 837 Pseudonym usernames and fast re-authentication usernames are both 838 produced and used by the EAP server. The EAP server MUST compose 839 pseudonym usernames and fast re-authentication usernames so that it 840 can recognize if a NAI username is an EAP-AKA pseudonym username or 841 an EAP-AKA fast re-authentication username. For instance, when the 842 usernames have been derived from the IMSI, the server could use 843 different leading characters in the pseudonym usernames and fast 844 re-authentication usernames (e.g. the pseudonym could begin with a 845 leading "2" character). When mapping a fast re-authentication 846 identity to a permanent identity, the server SHOULD only examine the 847 username portion of the fast re-authentication identity and ignore 848 the realm portion of the identity. 850 Because the peer may fail to save a pseudonym username sent to in an 851 EAP-Request/AKA-Challenge, for example due to malfunction, the EAP 852 server SHOULD maintain at least the most recently used pseudonym 853 username in addition to the most recently issued pseudonym username. 854 If the authentication exchange is not completed successfully, then 855 the server SHOULD NOT overwrite the pseudonym username that was 856 issued during the most recent successful authentication exchange. 858 4.1.1.8 Transmitting Pseudonyms and Fast Re-authentication Identities 859 to the Peer 861 The server transmits pseudonym usernames and fast re-authentication 862 identities to the peer in cipher, using the AT_ENCR_DATA attribute. 864 The EAP-Request/AKA-Challenge message MAY include an encrypted 865 pseudonym username and/or an encrypted fast re-authentication 866 identity in the value field of the AT_ENCR_DATA attribute. Because 867 identity privacy support and fast re-authentication are optional to 868 implement, the peer MAY ignore the AT_ENCR_DATA attribute and always 869 use the permanent identity. On fast re-authentication (discussed in 870 Section 5), the server MAY include a new encrypted fast 871 re-authentication identity in the EAP-Request/AKA-Reauthentication 872 message. 874 On receipt of the EAP-Request/AKA-Challenge, the peer MAY decrypt the 875 encrypted data in AT_ENCR_DATA and if a pseudonym username is 876 included, the peer may use the obtained pseudonym username on the 877 next full authentication. If a fast re-authentication identity is 878 included, then the peer MAY save it together with other fast 879 re-authentication state information, as discussed in Section 5, for 880 the next fast re-authentication. 882 If the peer does not receive a new pseudonym username in the EAP- 883 Request/AKA-Challenge message, the peer MAY use an old pseudonym 884 username instead of the permanent username on next full 885 authentication. The username portions of fast re-authentication 886 identities are one-time usernames, which the peer MUST NOT re-use. 887 When the peer uses a fast re-authentication identity in an EAP 888 exchange, the peer MUST discard the fast re-authentication identity 889 and not re-use it in another EAP authentication exchange, even if the 890 authentication exchange was not completed. 892 4.1.1.9 Usage of the Pseudonym by the Peer 894 When the optional identity privacy support is used on full 895 authentication, the peer MAY use a pseudonym username received as 896 part of a previous full authentication sequence as the username 897 portion of the NAI. The peer MUST NOT modify the pseudonym username 898 received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer 899 MAY need to decorate the username in some environments by appending 900 or prepending the username with a string that indicates supplementary 901 AAA routing information. 903 When using a pseudonym username in an environment where a realm 904 portion is used, the peer concatenates the received pseudonym 905 username with the "@" character and a NAI realm portion. The 906 selection of the NAI realm is discussed above. The peer can select 907 the realm portion similarly regardless of whether it uses the 908 permanent username or a pseudonym username. 910 4.1.1.10 Usage of the Fast Re-authentication Identity by the Peer 912 On fast re-authentication, the peer uses the fast re-authentication 913 identity, received as part of the previous authentication sequence. 914 A new fast re-authentication identity may be delivered as part of 915 both full authentication and fast re-authentication. The peer MUST 916 NOT modify the username part of the fast re-authentication identity 917 received in AT_NEXT_REAUTH_ID, except in cases when username 918 decoration is required. Even in these cases, the "root" fast 919 re-authentication username must not be modified, but it may be 920 appended or prepended with another string. 922 4.1.2 Communicating the Peer Identity to the Server 924 4.1.2.1 General 926 The peer identity MAY be communicated to the server with the 927 EAP-Response/Identity message. This message MAY contain the 928 permanent identity, a pseudonym identity, or a fast re-authentication 929 identity. If the peer uses the permanent identity or a pseudonym 930 identity, which the server is able to map to the permanent identity, 931 then the authentication proceeds as discussed in the overview of 932 Section 3. If the peer uses a fast re-authentication identity, and 933 if the fast re-authentication identity matches with a valid fast 934 re-authentication identity maintained by the server , then a fast 935 re-authentication exchange is performed, as described in Section 5. 937 The peer identity can also be transmitted from the peer to the server 938 using EAP-AKA messages instead of EAP-Response/Identity. In this 939 case, the server includes an identity requesting attribute 940 (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the 941 EAP-Request/AKA-Identity message, and the peer includes the 942 AT_IDENTITY attribute, which contains the peer's identity, in the 943 EAP-Response/AKA-Identity message. The AT_ANY_ID_REQ attribute is a 944 general identity requesting attribute, which the server uses if it 945 does not specify which kind of an identity the peer should return in 946 AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to 947 request either the permanent identity or a pseudonym identity. The 948 server uses the AT_PERMANENT_ID_REQ attribute to request the peer to 949 send its permanent identity. The EAP-Request/AKA-Challenge, 950 EAP-Response/AKA-Challenge, or the packets used on fast 951 re-authentication may optionally include the AT_CHECKCODE attribute, 952 which enables the protocol peers to ensure the integrity of the 953 AKA-Identity packets. AT_CHECKCODE is specified in Section 9.13. 955 The identity format in the AT_IDENTITY attribute is the same as in 956 the EAP-Response/Identity packet (except that identity decoration is 957 not allowed). The AT_IDENTITY attribute contains a permanent 958 identity, a pseudonym identity or a fast re-authentication identity. 960 Please note that the EAP-AKA peer and the EAP-AKA server only process 961 the AT_IDENTITY attribute and entities that only pass through EAP 962 packets do not process this attribute. Hence, the authenticator and 963 other intermediate AAA elements (such as possible AAA proxy servers) 964 will continue to refer to the peer with the original identity from 965 the EAP-Response/Identity packet unless the identity authenticated in 966 the AT_IDENTITY attribute is communicated to them in another way 967 within the AAA protocol. 969 4.1.2.2 Relying on EAP-Response/Identity Discouraged 971 The EAP-Response/Identity packet is not method specific so in many 972 implementations it may be handled by an EAP Framework. This 973 introduces an additional layer of processing between the EAP peer and 974 EAP server. The extra layer of processing may cache identity 975 responses or add decorations to the identity. A modification of the 976 identity response will cause the EAP peer and EAP server to use 977 different identities in the key derivation which will cause the 978 protocol to fail. 980 For this reason, it is RECOMMENDED that the EAP peer and server use 981 the method specific identity attributes in EAP-AKA and the server is 982 strongly discouraged from relying upon the EAP-Response/Identity. 984 In particular, if the EAP server receives a decorated identity in 985 EAP-Response/Identity, then the EAP server MUST use the 986 identity-requesting attributes to request the peer to send an 987 unmodified and undecorated copy of the identity in AT_IDENTITY. 989 4.1.3 Choice of Identity for the EAP-Response/Identity 991 If EAP-AKA peer is started upon receiving an EAP-Request/Identity 992 message, then the peer performs the following steps. 994 If the peer has maintained fast re-authentication state information 995 and if the peer wants to use fast re-authentication, then the peer 996 transmits the fast re-authentication identity in 997 EAP-Response/Identity. 999 Else, if the peer has a pseudonym username available, then the peer 1000 transmits the pseudonym identity in EAP-Response/Identity. 1002 In other cases, the peer transmits the permanent identity in 1003 EAP-Response/Identity. 1005 4.1.4 Server Operation in the Beginning of EAP-AKA Exchange 1007 If the EAP server has not received any EAP-AKA peer identity 1008 (permanent identity, pseudonym identity or fast re-authentication 1009 identity) from the peer when sending the first EAP-AKA request, or if 1010 the EAP server has received an EAP-Response/Identity packet but the 1011 contents do not appear to be a valid permanent identity, pseudonym 1012 identity or a re-authentication identity, then the server MUST 1013 request an identity from the peer using one of the methods below. 1015 The server sends the EAP-Request/AKA-Identity message with the 1016 AT_PERMANENT_ID_REQ attribute to indicate that the server wants the 1017 peer to include the permanent identity in the AT_IDENTITY attribute 1018 of the EAP-Response/AKA-Identity message. This is done in the 1019 following cases: 1021 o The server does not support fast re-authentication or identity 1022 privacy. 1023 o The server received an identity that it recognizes as a pseudonym 1024 identity but the server is not able to map the pseudonym identity 1025 to a permanent identity. 1027 The server issues the EAP-Request/AKA-Identity packet with the 1028 AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the 1029 peer to include a full authentication identity (pseudonym identity or 1030 permanent identity) in the AT_IDENTITY attribute of the 1031 EAP-Response/AKA-Identity message. This is done in the following 1032 cases: 1034 o The server does not support fast re-authentication and the server 1035 supports identity privacy 1036 o The server received an identity that it recognizes as a 1037 re-authentication identity but the server is not able to map the 1038 re-authentication identity to a permanent identity 1040 The server issues the EAP-Request/AKA-Identity packet with the 1041 AT_ANY_ID_REQ attribute to indicate that the server wants the peer to 1042 include an identity in the AT_IDENTITY attribute of the 1043 EAP-Response/AKA-Identity message, and the server does not indicate 1044 any preferred type for the identity. This is done in other cases, 1045 such as when the server does not have any identity, or the server 1046 does not recognize the format of a received identity. 1048 4.1.5 Processing of EAP-Request/AKA-Identity by the Peer 1050 Upon receipt of an EAP-Request/AKA-Identity message, the peer MUST 1051 perform the following steps. 1053 If the EAP-Request/AKA-Identity includes AT_PERMANENT_ID_REQ, and if 1054 the peer does not have a pseudonym available, then the peer MUST 1055 respond with EAP-Response/AKA-Identity and include the permanent 1056 identity in AT_IDENTITY. If the peer has a pseudonym available, then 1057 the peer MAY refuse to send the permanent identity; hence in this 1058 case the peer MUST either respond with EAP-Response/AKA-Identity and 1059 include the permanent identity in AT_IDENTITY or respond with 1060 EAP-Response/AKA-Client-Error packet with code "unable to process 1061 packet". 1063 If the EAP-Request/AKA-Identity includes AT_FULL_AUTH_ID_REQ, and if 1064 the peer has a pseudonym available, then the peer SHOULD respond with 1065 EAP-Response/AKA-Identity and include the pseudonym identity in 1066 AT_IDENTITY. If the peer does not have a pseudonym when it receives 1067 this message, then the peer MUST respond with 1068 EAP-Response/AKA-Identity and include the permanent identity in 1069 AT_IDENTITY. The Peer MUST NOT use a fast re-authentication identity 1070 in the AT_IDENTITY attribute. 1072 If the EAP-Request/AKA-Identity includes AT_ANY_ID_REQ, and if the 1073 peer has maintained fast re-authentication state information and the 1074 peer wants to use fast re-authentication, then the peer responds with 1075 EAP- Response/AKA-Identity and includes the fast re-authentication 1076 identity in AT_IDENTITY. Else, if the peer has a pseudonym identity 1077 available, then the peer responds with EAP-Response/AKA-Identity and 1078 includes the pseudonym identity in AT_IDENTITY. Else, the peer 1079 responds with EAP-Response/AKA-Identity and includes the permanent 1080 identity in AT_IDENTITY. 1082 An EAP-AKA exchange may include several EAP/AKA-Identity rounds. The 1083 server may issue a second EAP-Request/AKA-Identity, if it was not 1084 able to recognize the identity the peer used in the previous 1085 AT_IDENTITY attribute. At most three EAP/AKA-Identity rounds can be 1086 used, so the peer MUST NOT respond to more than three 1087 EAP-Request/AKA-Identity messages within an EAP exchange. The peer 1088 MUST verify that the sequence of EAP-Request/AKA-Identity packets the 1089 peer receives comply with the sequencing rules defined in this 1090 document. That is, AT_ANY_ID_REQ can only be used in the first 1091 EAP-Request/AKA-Identity, in other words AT_ANY_ID_REQ MUST NOT be 1092 used in the second or third EAP-Request/AKA-Identity. 1093 AT_FULLAUTH_ID_REQ MUST NOT be used if the previous 1094 EAP-Request/AKA-Identity included AT_PERMANENT_ID_REQ. The peer 1095 operation in cases when it receives an unexpected attribute or an 1096 unexpected message is specified in Section 6.3.1. 1098 4.1.6 Attacks against Identity Privacy 1100 The section above specifies two possible ways the peer can operate 1101 upon receipt of AT_PERMANENT_ID_REQ. This is because a received 1102 AT_PERMANENT_ID_REQ does not necessarily originate from the valid 1103 network, but an active attacker may transmit an 1104 EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute 1105 to the peer, in an effort to find out the true identity of the user. 1106 If the peer does not want to reveal its permanent identity, then the 1107 peer sends the EAP-Response/AKA-Client-Error packet with the error 1108 code "unable to process packet", and the authentication exchange 1109 terminates. 1111 Basically, there are two different policies that the peer can employ 1112 with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes 1113 that the network is able to maintain pseudonyms robustly. Therefore, 1114 if a conservative peer has a pseudonym username, the peer responds 1115 with EAP-Response/AKA-Client-Error to the EAP packet with 1116 AT_PERMANENT_ID_REQ, because the peer believes that the valid network 1117 is able to map the pseudonym identity to the peer's permanent 1118 identity. (Alternatively, the conservative peer may accept 1119 AT_PERMANENT_ID_REQ in certain circumstances, for example if the 1120 pseudonym was received a long time ago.) The benefit of this policy 1121 is that it protects the peer against active attacks on anonymity. On 1122 the other hand, a "liberal" peer always accepts the 1123 AT_PERMANENT_ID_REQ and responds with the permanent identity. The 1124 benefit of this policy is that it works even if the valid network 1125 sometimes loses pseudonyms and is not able to map them to the 1126 permanent identity. 1128 4.1.7 Processing of AT_IDENTITY by the Server 1130 When the server receives an EAP-Response/AKA-Identity message with 1131 the AT_IDENTITY (in response to the server's identity requesting 1132 attribute), the server MUST operate as follows. 1134 If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does 1135 not contain a valid permanent identity, then the server sends an 1136 EAP-Request/AKA-Notification packet with AT_NOTIFICATION code 1137 "General failure" (16384) to terminate the EAP exchange. If the 1138 server recognizes the permanent identity and is able to continue, 1139 then the server proceeds with full authentication by sending 1140 EAP-Request/AKA-Challenge. 1142 If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a 1143 valid permanent identity or a pseudonym identity that the server can 1144 map to a valid permanent identity, then the server proceeds with full 1145 authentication by sending EAP-Request/AKA-Challenge. If AT_IDENTITY 1146 contains a pseudonym identity that the server is not able to map to a 1147 valid permanent identity, or an identity that the server is not able 1148 to recognize or classify, then the server sends EAP-Request/ 1149 AKA-Identity with AT_PERMANENT_ID_REQ. 1151 If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a 1152 valid permanent identity or a pseudonym identity that the server can 1153 map to a valid permanent identity, then the server proceeds with full 1154 authentication by sending EAP-Request/ AKA-Challenge. 1156 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid 1157 fast re-authentication identity and the server agrees on using 1158 re-authentication, then the server proceeds with fast 1159 re-authentication by sending EAP-Request/AKA-Reauthentication 1160 (Section 5). 1162 If the server used AT_ANY_ID_REQ, and if the peer sent an 1163 EAP-Response/AKA-Identity with AT_IDENTITY that contains an identity 1164 that the server recognizes as a fast re-authentication identity, but 1165 the server is not able to map the identity to a permanent identity, 1166 then the server sends EAP-Request/AKA-Identity with 1167 AT_FULLAUTH_ID_REQ. 1169 If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid 1170 fast re-authentication identity, which the server is able to map to a 1171 permanent identity, and if the server does not want to use fast 1172 re-authentication, then the server proceeds with full authentication 1173 by sending EAP-Request/AKA-Challenge. 1175 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an 1176 identity that the server recognizes as a pseudonym identity but the 1177 server is not able to map the pseudonym identity to a permanent 1178 identity, then the server sends EAP-Request/AKA-Identity with 1179 AT_PERMANENT_ID_REQ. 1181 If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an 1182 identity that the server is not able to recognize or classify, then 1183 the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ. 1185 4.2 Message Sequence Examples (Informative) 1187 This section contains non-normative message sequence examples to 1188 illustrate how the peer identity can be communicated to the server. 1190 4.2.1 Usage of AT_ANY_ID_REQ 1192 Obtaining the peer identity with EAP-AKA attributes is illustrated in 1193 Figure 5 below. 1195 Peer Authenticator 1196 | | 1197 | +------------------------------+ 1198 | | Server does not have any | 1199 | | Subscriber identity available| 1200 | | When starting EAP-AKA | 1201 | +------------------------------+ 1202 | EAP-Request/AKA-Identity | 1203 | (AT_ANY_ID_REQ) | 1204 |<------------------------------------------------------| 1205 | | 1206 | EAP-Response/AKA-Identity | 1207 | (AT_IDENTITY) | 1208 |------------------------------------------------------>| 1209 | | 1211 Figure 5: Usage of AT_ANY_ID_REQ 1213 4.2.2 Fall Back on Full Authentication 1215 Figure 6 illustrates the case when the server does not recognize the 1216 fast re-authentication identity the peer used in AT_IDENTITY. 1218 Peer Authenticator 1219 | | 1220 | +------------------------------+ 1221 | | Server does not have any | 1222 | | Subscriber identity available| 1223 | | When starting EAP-AKA | 1224 | +------------------------------+ 1225 | EAP-Request/AKA-Identity | 1226 | (AT_ANY_ID_REQ) | 1227 |<------------------------------------------------------| 1228 | | 1229 | EAP-Response/AKA-Identity | 1230 | (AT_IDENTITY containing a fast re-auth. identity) | 1231 |------------------------------------------------------>| 1232 | +------------------------------+ 1233 | | Server does not recognize | 1234 | | The fast re-auth. | 1235 | | Identity | 1236 | +------------------------------+ 1237 | EAP-Request/AKA-Identity | 1238 | (AT_FULLAUTH_ID_REQ) | 1239 |<------------------------------------------------------| 1240 | EAP-Response/AKA-Identity | 1241 | (AT_IDENTITY with a full-auth. Identity) | 1242 |------------------------------------------------------>| 1243 | | 1245 Figure 6: Fall back on full authentication 1247 If the server recognizes the fast re-authentication identity, but 1248 still wants to fall back on full authentication, the server may issue 1249 the EAP-Request/AKA-Challenge packet. In this case, the full 1250 authentication procedure proceeds as usual. 1252 4.2.3 Requesting the Permanent Identity 1 1254 Figure 7 illustrates the case when the EAP server fails to decode a 1255 pseudonym identity included in the EAP-Response/Identity packet. 1257 Peer Authenticator 1258 | EAP-Request/Identity | 1259 |<------------------------------------------------------| 1260 | EAP-Response/Identity | 1261 | (Includes a pseudonym) | 1262 |------------------------------------------------------>| 1263 | +------------------------------+ 1264 | | Server fails to decode the | 1265 | | Pseudonym. | 1266 | +------------------------------+ 1267 | EAP-Request/AKA-Identity | 1268 | (AT_PERMANENT_ID_REQ) | 1269 |<------------------------------------------------------| 1270 | | 1271 | EAP-Response/AKA-Identity | 1272 | (AT_IDENTITY with permanent identity) | 1273 |------------------------------------------------------>| 1274 | | 1276 Figure 7: Requesting the permanent identity 1 1278 If the server recognizes the permanent identity, then the 1279 authentication sequence proceeds as usual with the EAP Server issuing 1280 the EAP-Request/AKA-Challenge message. 1282 4.2.4 Requesting the Permanent Identity 2 1284 Figure 8 illustrates the case when the EAP server fails to decode the 1285 pseudonym included in the AT_IDENTITY attribute. 1287 Peer Authenticator 1288 | | 1289 | +------------------------------+ 1290 | | Server does not have any | 1291 | | Subscriber identity available| 1292 | | When starting EAP-AKA | 1293 | +------------------------------+ 1294 | EAP-Request/AKA-Identity | 1295 | (AT_ANY_ID_REQ) | 1296 |<------------------------------------------------------| 1297 | | 1298 |EAP-Response/AKA-Identity | 1299 |(AT_IDENTITY with a pseudonym identity) | 1300 |------------------------------------------------------>| 1301 | +------------------------------+ 1302 | | Server fails to decode the | 1303 | | Pseudonym in AT_IDENTITY | 1304 | +------------------------------+ 1305 | EAP-Request/AKA-Identity | 1306 | (AT_PERMANENT_ID_REQ) | 1307 |<------------------------------------------------------| 1308 | EAP-Response/AKA-Identity | 1309 | (AT_IDENTITY with permanent identity) | 1310 |------------------------------------------------------>| 1311 | | 1313 Figure 8: Requesting the permanent identity 2 1315 4.2.5 Three EAP/AKA-Identity Round Trips 1317 Figure 9 illustrates the case with three EAP/AKA-Identity round 1318 trips. 1320 Peer Authenticator 1321 | | 1322 | +------------------------------+ 1323 | | Server does not have any | 1324 | | Subscriber identity available| 1325 | | When starting EAP-AKA | 1326 | +------------------------------+ 1327 | EAP-Request/AKA-Identity | 1328 | (AT_ANY_ID_REQ) | 1329 |<------------------------------------------------------| 1330 | | 1331 | EAP-Response/AKA-Identity | 1332 | (AT_IDENTITY with fast re-auth. identity) | 1333 |------------------------------------------------------>| 1334 | +------------------------------+ 1335 | | Server does not accept | 1336 | | The fast re-authentication | 1337 | | Identity | 1338 | +------------------------------+ 1339 | | 1340 : : 1341 : : 1343 : : 1344 : : 1345 | EAP-Request/AKA-Identity | 1346 | (AT_FULLAUTH_ID_REQ) | 1347 |<------------------------------------------------------| 1348 |EAP-Response/AKA-Identity | 1349 |(AT_IDENTITY with a pseudonym identity) | 1350 |------------------------------------------------------>| 1351 | +------------------------------+ 1352 | | Server fails to decode the | 1353 | | Pseudonym in AT_IDENTITY | 1354 | +------------------------------+ 1355 | EAP-Request/AKA-Identity | 1356 | (AT_PERMANENT_ID_REQ) | 1357 |<------------------------------------------------------| 1358 | EAP-Response/AKA-Identity | 1359 | (AT_IDENTITY with permanent identity) | 1360 |------------------------------------------------------>| 1361 | | 1363 Figure 9: Three EAP-AKA Start rounds 1365 After the last EAP-Response/AKA-Identity message, the full 1366 authentication sequence proceeds as usual. 1368 5. Fast Re-authentication 1370 5.1 General 1372 In some environments, EAP authentication may be performed frequently. 1373 Because the EAP-AKA full authentication procedure makes use of the 1374 AKA algorithms, and it therefore requires fresh authentication 1375 vectors from the Authentication Centre, the full authentication 1376 procedure may result in many network operations when used very 1377 frequently. Therefore, EAP-AKA includes a more inexpensive fast 1378 re-authentication procedure that does not make use of the AKA 1379 algorithms and does not need new vectors from the Authentication 1380 Centre. 1382 Fast re-authentication is optional to implement for both the EAP-AKA 1383 server and peer. On each EAP authentication, either one of the 1384 entities may also fall back on full authentication if they do not 1385 want to use fast re-authentication. 1387 Fast re-authentication is based on the keys derived on the preceding 1388 full authentication. The same K_aut and K_encr keys as in full 1389 authentication are used to protect EAP-AKA packets and attributes, 1390 and the original Master Key from full authentication is used to 1391 generate a fresh Master Session Key, as specified in Section 6.4. 1393 The fast re-authentication exchange makes use of an unsigned 16-bit 1394 counter, included in the AT_COUNTER attribute. The counter has three 1395 goals: 1) it can be used to limit the number of successive 1396 reauthentication exchanges without full-authentication 2) it 1397 contributes to the keying material, and 3) it protects the peer and 1398 the server from replays. On full authentication, both the server and 1399 the peer initialize the counter to one. The counter value of at 1400 least one is used on the first fast re-authentication. On subsequent 1401 fast re-authentications, the counter MUST be greater than on any of 1402 the previous fast re-authentications. For example, on the second 1403 fast re-authentication, counter value is two or greater etc. The 1404 AT_COUNTER attribute is encrypted. 1406 Both the peer and the EAP server maintain a copy of the counter. The 1407 EAP server sends its counter value to the peer in the fast 1408 re-authentication request. The peer MUST verify that its counter 1409 value is less than or equal to the value sent by the EAP server. 1411 The server includes an encrypted server random nonce (AT_NONCE_S) in 1412 the fast re-authentication request. The AT_MAC attribute in the 1413 peer's response is calculated over NONCE_S to provide a 1414 challenge/response authentication scheme. The NONCE_S also 1415 contributes to the new Master Session Key. 1417 Both the peer and the server SHOULD have an upper limit for the 1418 number of subsequent fast re-authentications allowed before a full 1419 authentication needs to be performed. Because a 16-bit counter is 1420 used in fast re-authentication, the theoretical maximum number of 1421 re-authentications is reached when the counter value reaches FFFF 1422 hexadecimal. In order to use fast re-authentication, the peer and 1423 the EAP server need to store the following values: Master Key, latest 1424 counter value and the next fast re-authentication identity. K_aut, 1425 K_encr may either be stored or derived again from MK. The server may 1426 also need to store the permanent identity of the user. 1428 5.2 Comparison to AKA 1430 When analyzing the fast re-authentication exchange, it may be helpful 1431 to compare it with the 3rd generation Authentication and Key 1432 Agreement (AKA) exchange used on full authentication. The counter 1433 corresponds to the AKA sequence number, NONCE_S corresponds to RAND, 1434 and AT_MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN, 1435 the AT_MAC in EAP-Response/AKA-Reauthentication corresponds to RES, 1436 AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter 1437 corresponds to the usage of the Anonymity Key. Also the key 1438 generation on fast re-authentication with regard to random or fresh 1439 material is similar to AKA -- the server generates the NONCE_S and 1440 counter values, and the peer only verifies that the counter value is 1441 fresh. 1443 It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER or 1444 AT_COUNTER_TOO_SMALL attributes is not important to the security of 1445 the fast re-authentication exchange. 1447 5.3 Fast Re-authentication Identity 1449 The fast re-authentication procedure makes use of separate 1450 re-authentication user identities. Pseudonyms and the permanent 1451 identity are reserved for full authentication only. If a fast 1452 re-authentication identity is lost and the network does not recognize 1453 it, the EAP server can fall back on full authentication. If the EAP 1454 server supports fast re-authentication, it MAY include the skippable 1455 AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP- 1456 Request/AKA-Challenge message. This attribute contains a new 1457 re-authentication identity for the next fast re-authentication. The 1458 attribute also works as a capability flag that indicates the fact 1459 that the server supports fast re-authentication, and that the server 1460 wants to continue using fast re-authentication within the current 1461 context. The peer MAY ignore this attribute, in which case it will 1462 use full authentication next time. If the peer wants to use fast 1463 re-authentication, it uses this fast re-authentication identity on 1464 next authentication. Even if the peer has a fast re-authentication 1465 identity, the peer MAY discard the re-authentication identity and use 1466 a pseudonym or the permanent identity instead, in which case full 1467 authentication MUST be performed. If the EAP server does not include 1468 the AT_NEXT_REAUTH_ID in the encrypted data of 1469 EAP-Request/AKA-Challenge or EAP-Request/AKA-Reauthentication, then 1470 the peer MUST discard its current fast re-authentication state 1471 information and perform a full authentication next time. 1473 In environments where a realm portion is needed in the peer identity, 1474 the fast re-authentication identity received in AT_NEXT_REAUTH_ID 1475 MUST contain both a username portion and a realm portion, as per the 1476 NAI format. The EAP Server can choose an appropriate realm part in 1477 order to have the AAA infrastructure route subsequent fast 1478 re-authentication related requests to the same AAA server. For 1479 example, the realm part MAY include a portion that is specific to the 1480 AAA server. Hence, it is sufficient to store the context required 1481 for fast re-authentication in the AAA server that performed the full 1482 authentication. 1484 The peer MAY use the fast re-authentication identity in the 1485 EAP-Response/Identity packet or, in response to server's 1486 AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication 1487 identity in the AT_IDENTITY attribute of the 1488 EAP-Response/AKA-Identity packet. 1490 The peer MUST NOT modify the username portion of the fast 1491 re-authentication identity, but the peer MAY modify the realm portion 1492 or replace it with another realm portion. The peer might need to 1493 modify the realm in order to influence the AAA routing, for example 1494 to make sure that the correct server is reached. It should be noted 1495 that sharing the same fast re-authentication key among several 1496 servers may have security risks, so changing the realm portion of the 1497 NAI in order to change the EAP server is not desirable. 1499 Even if the peer uses a fast re-authentication identity, the server 1500 may want to fall back on full authentication, for example because the 1501 server does not recognize the fast re-authentication identity or does 1502 not want to use fast re-authentication. If the server was able to 1503 decode the fast re-authentication identity to the permanent identity, 1504 the server issues the EAP-Request/AKA-Challenge packet to initiate 1505 full authentication. If the server was not able to recover the 1506 peer's identity from the fast re-authentication identity, the server 1507 starts the full authentication procedure by issuing an 1508 EAP-Request/AKA-Identity packet. This packet always starts a full 1509 authentication sequence if it does not include the AT_ANY_ID_REQ 1510 attribute. 1512 5.4 Fast Re-authentication Procedure 1514 Figure 10 illustrates the fast re-authentication procedure. In this 1515 example, the optional protected success indication is not used. 1516 Encrypted attributes are denoted with '*'. The peer uses its fast 1517 re-authentication identity in the EAP-Response/Identity packet. As 1518 discussed above, an alternative way to communicate the fast 1519 re-authentication identity to the server is for the peer to use the 1520 AT_IDENTITY attribute in the EAP-Response/AKA-Identity message. This 1521 latter case is not illustrated in the figure below, and it is only 1522 possible when the server requests the peer to send its identity by 1523 including the AT_ANY_ID_REQ attribute in the EAP-Request/AKA-Identity 1524 packet. 1526 If the server recognizes the identity as a valid fast 1527 re-authentication identity, and if the server agrees on using fast 1528 re-authentication, then the server sends the EAP- 1529 Request/AKA-Reauthentication packet to the peer. This packet MUST 1530 include the encrypted AT_COUNTER attribute, with a fresh counter 1531 value, the encrypted AT_NONCE_S attribute that contains a random 1532 number chosen by the server, the AT_ENCR_DATA and the AT_IV 1533 attributes used for encryption, and the AT_MAC attribute that 1534 contains a message authentication code over the packet. The packet 1535 MAY also include an encrypted AT_NEXT_REAUTH_ID attribute that 1536 contains the next fast re-authentication identity. 1538 Fast re-authentication identities are one-time identities. If the 1539 peer does not receive a new fast re-authentication identity, it MUST 1540 use either the permanent identity or a pseudonym identity on the next 1541 authentication to initiate full authentication. 1543 The peer verifies that AT_MAC is correct and that the counter value 1544 is fresh (greater than any previously used value). The peer MAY save 1545 the next fast re-authentication identity from the encrypted 1546 AT_NEXT_REAUTH_ID for next time. If all checks are successful, the 1547 peer responds with the EAP-Response/AKA-Reauthentication packet, 1548 including the AT_COUNTER attribute with the same counter value and 1549 the AT_MAC attribute. 1551 The server verifies the AT_MAC attribute and also verifies that the 1552 counter value is the same that it used in the EAP-Request/AKA- 1553 Reauthentication packet. If these checks are successful, the fast 1554 re-authentication has succeeded and the server sends the EAP-Success 1555 packet to the peer. 1557 If protected success indications (Section 6.2) were used, the 1558 EAP-Success packet would be preceded by an EAP-AKA notification 1559 round. 1561 Peer Authenticator 1562 | | 1563 | EAP-Request/Identity | 1564 |<------------------------------------------------------| 1565 | | 1566 | EAP-Response/Identity | 1567 | (Includes a fast re-authentication identity) | 1568 |------------------------------------------------------>| 1569 | +--------------------------------+ 1570 | | Server recognizes the identity | 1571 | | and agrees on using fast | 1572 | | re-authentication | 1573 | +--------------------------------+ 1574 | EAP-Request/AKA-Reauthentication | 1575 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1576 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1577 |<------------------------------------------------------| 1578 | | 1579 : : 1580 : : 1582 : : 1583 : : 1584 | | 1585 +-----------------------------------------------+ | 1586 | Peer verifies AT_MAC and the freshness of | | 1587 | the counter. Peer MAY store the new re- | | 1588 | authentication identity for next re-auth. | | 1589 +-----------------------------------------------+ | 1590 | | 1591 | EAP-Response/AKA-Reauthentication | 1592 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, | 1593 | AT_MAC) | 1594 |------------------------------------------------------>| 1595 | +--------------------------------+ 1596 | | Server verifies AT_MAC and | 1597 | | the counter | 1598 | +--------------------------------+ 1599 | EAP-Success | 1600 |<------------------------------------------------------| 1601 | | 1603 Figure 10: Reauthentication 1605 5.5 Fast Re-authentication Procedure when Counter is Too Small 1607 If the peer does not accept the counter value of 1608 EAP-Request/AKA-Reauthentication, it indicates the counter 1609 synchronization problem by including the encrypted 1610 AT_COUNTER_TOO_SMALL in EAP-Response/AKA-Reauthentication. The 1611 server responds with EAP-Request/AKA-Challenge to initiate a normal 1612 full authentication procedure. This is illustrated in Figure 11. 1613 Encrypted attributes are denoted with '*'. 1615 Peer Authenticator 1616 | EAP-Request/AKA-Identity | 1617 | (AT_ANY_ID_REQ) | 1618 |<------------------------------------------------------| 1619 | | 1620 | EAP-Response/AKA-Identity | 1621 | (AT_IDENTITY) | 1622 | (Includes a fast re-authentication identity) | 1623 |------------------------------------------------------>| 1624 | | 1625 | EAP-Request/AKA-Reauthentication | 1626 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | 1627 | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | 1628 |<------------------------------------------------------| 1629 +-----------------------------------------------+ | 1630 | AT_MAC is valid but the counter is not fresh. | | 1631 +-----------------------------------------------+ | 1632 | EAP-Response/AKA-Reauthentication | 1633 | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, | 1634 | *AT_COUNTER, AT_MAC) | 1635 |------------------------------------------------------>| 1636 | +----------------------------------------------+ 1637 | | Server verifies AT_MAC but detects | 1638 | | That peer has included AT_COUNTER_TOO_SMALL| 1639 | +----------------------------------------------+ 1640 | EAP-Request/AKA-Challenge | 1641 |<------------------------------------------------------| 1642 +---------------------------------------------------------------+ 1643 | Normal full authentication follows. | 1644 +---------------------------------------------------------------+ 1645 | | 1647 Figure 11: Fast re-authentication counter too small 1649 In the figure above, the first three messages are similar to the 1650 basic fast re-authentication case. When the peer detects that the 1651 counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL 1652 attribute in EAP-Response/AKA-Reauthentication. This attribute 1653 doesn't contain any data but it is a request for the server to 1654 initiate full authentication. In this case, the peer MUST ignore the 1655 contents of the server's AT_NEXT_REAUTH_ID attribute. 1657 On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and 1658 verifies that AT_COUNTER contains the same counter value as in the 1659 EAP-Request/AKA-Reauthentication packet. If not, the server 1660 terminates the authentication exchange by sending the 1661 EAP-Request/AKA-Notification packet with AT_NOTIFICATION code 1662 "General failure" (16384). If all checks on the packet are 1663 successful, the server transmits a EAP-Request/AKA-Challenge packet 1664 and the full authentication procedure is performed as usual. Since 1665 the server already knows the subscriber identity, it MUST NOT use the 1666 EAP-Request/AKA-Identity packet to request the identity. 1668 It should be noted that in this case, peer identity is only 1669 transmitted in the AT_IDENTITY attribute at the beginning of the 1670 whole EAP exchange. The fast re-authentication identity used in this 1671 AT_IDENTITY attribute will be used in key derivation (see Section 1672 Section 6.4). 1674 6. EAP-AKA Notifications 1676 6.1 General 1678 EAP-AKA does not prohibit the use of the EAP Notifications as 1679 specified in [RFC3748]. EAP Notifications can be used at any time in 1680 the EAP-AKA exchange. It should be noted that EAP-AKA does not 1681 protect EAP Notifications. EAP-AKA also specifies method specific 1682 EAP-AKA notifications, which are protected in some cases. 1684 The EAP server can use EAP-AKA notifications to convey notifications 1685 and result indications (Section 6.2) to the peer. 1687 The server MUST use notifications in cases discussed in Section 1688 6.3.2. When the EAP server issues an EAP-Request/AKA-Notification 1689 packet to the peer, the peer MUST process the notification packet.The 1690 peer MAY show a notification message to the user and the peer MUST 1691 respond to the EAP server with an EAP-Response/AKA-Notification 1692 packet, even if the peer did not recognize the notification code. 1694 An EAP-AKA full authentication exchange or a fast re-authentication 1695 exchange MUST NOT include more than one EAP-AKA notification round. 1697 The notification code is a 16-bit number. The most significant bit 1698 is called the Success bit (S bit). The S bit specifies whether the 1699 notification implies failure. The code values with the S bit set to 1700 zero (code values 0...32767) are used on unsuccessful cases. The 1701 receipt of a notification code from this range implies failed EAP 1702 exchange, so the peer can use the notification as a failure 1703 indication. After receiving the EAP-Response/AKA-Notification for 1704 these notification codes, the server MUST send the EAP-Failure 1705 packet. 1707 The receipt of a notification code with the S bit set to one (values 1708 32768...65536) does not imply failure. Notification code "Success" 1709 (32768) has been reserved as a general notification code to indicate 1710 successful authentication. 1712 The second most significant bit of the notification code is called 1713 the Phase bit (P bit). It specifies at which phase of the EAP-AKA 1714 exchange the notification can be used. If the P bit is set to zero, 1715 the notification can only be used after a successful 1716 EAP/AKA-Challenge round in full authentication or a successful 1717 EAP/AKA-Reauthentication round in reautentication. A 1718 re-authentication round is considered successful only if the peer has 1719 successfully verified AT_MAC and AT_COUNTER attributes, and does not 1720 include the AT_COUNTER_TOO_SMALL attribute in 1721 EAP-Response/AKA-Reauthentication. 1723 If the P bit is set to one, the notification can only by used before 1724 the EAP/AKA-Challenge round in full authentication or before the 1725 EAP/AKA-Reauthentication round in reauthentication. These 1726 notifications can only be used to indicate various failure cases. In 1727 other words, if the P bit is set to one, then the S bit MUST be set 1728 to zero. 1730 Section 8.10 and Section 8.11 specify what other attributes must be 1731 included in the notification packets. 1733 Some of the notification codes are authorization related and hence 1734 not usually considered as part of the responsibility of an EAP 1735 method. However, they are included as part of EAP-AKA because there 1736 are currently no other ways to convey this information to the user in 1737 a localizable way, and the information is potentially useful for the 1738 user. An EAP-AKA server implementation may decide never to send 1739 these EAP-AKA notifications. 1741 6.2 Result Indications 1743 As discussed in Section 6.3, the server and the peer use explicit 1744 error messages in all error cases. If the server detects an error 1745 after successful authentication, the server uses an EAP-AKA 1746 notification to indicate failure to the peer. In this case, the 1747 result indication is integrity and replay protected. 1749 By sending an EAP-Response/AKA-Challenge packet or an 1750 EAP-Response/AKA-Reauthentication packet (without 1751 AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully 1752 authenticated the server and that the peer's local policy accepts the 1753 EAP exchange. In other words, these packets are implicit success 1754 indications from the peer to the server. 1756 EAP-AKA also supports optional protected success indications from the 1757 server to the peer. If the EAP server wants to use protected success 1758 indications, it includes the AT_RESULT_IND attribute in the 1759 EAP-Request/AKA-Challenge or the EAP-Request/AKA-Reauthentication 1760 packet. This attribute indicates, that the EAP server would like to 1761 use result indications in both successful and unsuccessful cases. If 1762 the peer also wants this, the peer includes AT_RESULT_IND in 1763 EAP-Response/AKA-Challenge or EAP-Response/AKA-Re-authentication. 1764 The peer MUST NOT include AT_RESULT_IND if it did not receive 1765 AT_RESULT_IND from the server. If both the peer and the server used 1766 AT_RESULT_IND, then the EAP exchange is not complete yet, but an 1767 EAP-AKA notification round will follow. The following EAP-AKA 1768 notification may indicate either failure or success. 1770 Success indications with the AT_NOTIFICATION code "Success" (32768) 1771 can only be used if both the server and the peer indicate they want 1772 to use them with AT_RESULT_IND. If the server did not include 1773 AT_RESULT_IND in the EAP-Request/AKA-Challenge or 1774 EAP-Request/AKA-Reauthentication packet, or if the peer did not 1775 include AT_RESULT_IND in the corresponding response packet, then the 1776 server MUST NOT use protected success indications. 1778 Because the server uses the AT_NOTIFICATION code "Success" (32768) to 1779 indicate that the EAP exchange has completed successfully, the EAP 1780 exchange cannot fail when the server processes the EAP-AKA response 1781 to this notification. Hence, the server MUST ignore the contents of 1782 the EAP-AKA response it receives to the EAP-Request/AKA-Notification 1783 with this code. Regardless of the contents of the EAP-AKA response, 1784 the server MUST send EAP-Success as the next packet. 1786 6.3 Error Cases 1788 This section specifies the operation of the peer and the server in 1789 error cases. The subsections below require the EAP-AKA peer and 1790 server to send an error packet (EAP-Response/AKA-Client-Error, 1791 EAP-Response/AKA-Authentication-Reject or 1792 EAP-Response/AKA-Synchronization-Failure from the peer and 1793 EAP-Request/AKA-Notification from the server) in error cases. 1794 However, implementations SHOULD NOT rely upon the correct error 1795 reporting behavior of the peer, authenticator, or the server. It is 1796 possible for error and other messages to be lost in transit or for a 1797 malicious participant to attempt to consume resources by not issuing 1798 error messages. Both the peer and the EAP server SHOULD have a 1799 mechanism to clean up state even if an error message or EAP-Success 1800 is not received after a timeout period. 1802 6.3.1 Peer Operation 1804 Two special error messages have been specified for error cases that 1805 are related to the processing of the AKA AUTN parameter, as described 1806 in Section 3: (1) if the peer does not accept AUTN, the peer responds 1807 with EAP-Response/AKA-Authentication-Reject (Section 8.5), and the 1808 server issues EAP-Failure, and (2) if the peer detects that the 1809 sequence number in AUTN is not correct, the peer responds with 1810 EAP-Response/AKA-Synchronization-Failure (Section 8.6), and the 1811 server proceeds with a new EAP-Request/AKA-Challenge. 1813 In other error cases, when an EAP-AKA peer detects an error in a 1814 received EAP-AKA packet, the EAP-AKA peer responds with the 1815 EAP-Response/AKA-Client-Error packet. In response to the 1816 EAP-Response/AKA-Client-Error, the EAP server MUST issue the 1817 EAP-Failure packet and the authentication exchange terminates. 1819 By default, the peer uses the client error code 0, "unable to process 1820 packet". This error code is used in the following cases: 1822 o EAP exchange is not acceptable according to the peer's local 1823 policy. 1824 o the peer is not able to parse the EAP request, i.e. the EAP 1825 request is malformed 1826 o the peer encountered a malformed attribute 1827 o wrong attribute types or duplicate attributes have been included 1828 in the EAP request 1829 o a mandatory attribute is missing 1830 o unrecognized non-skippable attribute 1831 o unrecognized or unexpected EAP-AKA Subtype in the EAP request 1832 o invalid AT_MAC. The peer SHOULD log this event. 1833 o invalid AT_CHECKCODE. The peer SHOULD log this event. 1834 o invalid pad bytes in AT_PADDING 1835 o the peer does not want to process AT_PERMANENT_ID_REQ 1837 6.3.2 Server Operation 1839 If an EAP-AKA server detects an error in a received EAP-AKA response, 1840 the server MUST issue the EAP-Request/AKA-Notification packet with an 1841 AT_NOTIFICATION code that implies failure. By default, the server 1842 uses one of the general failure codes ("General failure after 1843 authentication" (0), or "General failure" (16384)). The choice 1844 between these two codes depends on the phase of the EAP-AKA exchange, 1845 see Section 6. The errors cases when the server issues an 1846 EAP-Request/AKA-Notification that implies failure include the 1847 following: 1849 o the server is not able to parse the peer's EAP response 1850 o the server encounters a malformed attribute, a non-recognized 1851 non-skippable attribute, or a duplicate attribute 1852 o a mandatory attribute is missing or an invalid attribute was 1853 included 1854 o unrecognized or unexpected EAP-AKA Subtype in the EAP Response 1855 o invalid AT_MAC. The server SHOULD log this event. 1856 o invalid AT_CHECKCODE. The server SHOULD log this event. 1857 o invalid AT_COUNTER 1859 6.3.3 EAP-Failure 1861 The EAP-AKA server sends EAP-Failure in three cases: 1863 1) In response to an EAP-Response/AKA-Client-Error packet the server 1864 has received from the peer, or 1866 2) In response to an EAP-Response/AKA-Authentication-Reject packet 1867 the server has received from the peer, or 1869 3) Following an EAP-AKA notification round, when the AT_NOTIFICATION 1870 code implies failure. 1872 The EAP-AKA server MUST NOT send EAP-Failure in other cases than 1873 these three. However, it should be noted that even though the 1874 EAP-AKA server would not send an EAP-Failure, an authorization 1875 decision that happens outside EAP-AKA, such as in the AAA server or 1876 in an intermediate AAA proxy, may result in a failed exchange. 1878 The peer MUST accept the EAP-Failure packet in case 1), case 2) and 1879 case 3) above. The peer SHOULD silently discard the EAP-Failure 1880 packet in other cases. 1882 6.3.4 EAP-Success 1884 On full authentication, the server can only send EAP-Success after 1885 the EAP/AKA-Challenge round. The peer MUST silently discard any 1886 EAP-Success packets if they are received before the peer has 1887 successfully authenticated the server and sent the 1888 EAP-Response/AKA-Challenge packet. 1890 If the peer did not indicate that it wants to use protected success 1891 indications with AT_RESULT_IND (as discussed in Section 6.2) on full 1892 authentication, then the peer MUST accept EAP-Success after a 1893 successful EAP/AKA-Challenge round. 1895 If the peer indicated that it wants to use protected success 1896 indications with AT_RESULT_IND (as discussed in Section 6.2), then 1897 the peer MUST NOT accept EAP-Success after a successful 1898 EAP/AKA-Challenge round. In this case, the peer MUST only accept 1899 EAP-Success after receiving an EAP-AKA Notification with the 1900 AT_NOTIFICATION code "Success" (32768). 1902 On fast re-authentication, EAP-Success can only be sent after the 1903 EAP/AKA-Reauthentication round. The peer MUST silently discard any 1904 EAP-Success packets if they are received before the peer has 1905 successfully authenticated the server and sent the 1906 EAP-Response/AKA-Reauthentication packet. 1908 If the peer did not indicate that it wants to use protected success 1909 indications with AT_RESULT_IND (as discussed in Section 6.2) on fast 1910 re-authentication, then the peer MUST accept EAP-Success after a 1911 successful EAP/AKA-Reauthentication round. 1913 If the peer indicated that it wants to use protected success 1914 indications with AT_RESULT_IND (as discussed in Section 6.2), then 1915 the peer MUST NOT accept EAP-Success after a successful 1916 EAP/AKA-Reauthentication round. In this case, the peer MUST only 1917 accept EAP-Success after receiving an EAP-AKA Notification with the 1918 AT_NOTIFICATION code "Success" (32768). 1920 If the peer receives an EAP-AKA notification (Section 6) that 1921 indicates failure, then the peer MUST no longer accept the EAP- 1922 Success packet even if the server authentication was successfully 1923 completed. 1925 6.4 Key Generation 1927 This section specifies how keying material is generated. 1929 On EAP-AKA full authentication, a Master Key (MK) is derived from the 1930 underlying AKA values (CK and IK keys), and the identity as follows. 1932 MK = SHA1(Identity|IK|CK) 1934 In the formula above, the "|" character denotes concatenation. 1935 Identity denotes the peer identity string without any terminating 1936 null characters. It is the identity from the last AT_IDENTITY 1937 attribute sent by the peer in this exchange, or, if AT_IDENTITY was 1938 not used, the identity from the EAP-Response/Identity packet. The 1939 identity string is included as-is, without any changes. As discussed 1940 in Section 4.1.2.2, relying on EAP-Response/Identity for conveying 1941 the EAP-AKA peer identity is discouraged, and the server SHOULD use 1942 the EAP-AKA method specific identity attributes. The hash function 1943 SHA-1 is specified in [SHA-1]. 1945 The Master Key is fed into a Pseudo-Random number Function (PRF), 1946 which generates separate Transient EAP Keys (TEKs) for protecting 1947 EAP-AKA packets, as well as a Master Session Key (MSK) for link layer 1948 security and an Extended Master Session Key (EMSK) for other 1949 purposes. On fast re-authentication, the same TEKs MUST be used for 1950 protecting EAP packets, but a new MSK and a new EMSK MUST be derived 1951 from the original MK and new values exchanged in the fast 1952 re-authentication. 1954 EAP-AKA requires two TEKs for its own purposes, the authentication 1955 key K_aut to be used with the AT_MAC attribute, and the encryption 1956 key K_encr, to be used with the AT_ENCR_DATA attribute. The same 1957 K_aut and K_encr keys are used in full authentication and subsequent 1958 fast re-authentications. 1960 Key derivation is based on the random number generation specified in 1961 NIST Federal Information Processing Standards (FIPS) Publication 1962 186-2 [PRF]. The pseudo-random number generator is specified in the 1963 change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As 1964 specified in the change notice (page 74), when Algorithm 1 is used as 1965 a general-purpose pseudo-random number generator, the "mod q" term in 1966 step 3.3 is omitted. The function G used in the algorithm is 1967 constructed via Secure Hash Standard as specified in Appendix 3.3 of 1968 the standard. It should be noted that the function G is very similar 1969 to SHA-1, but the message padding is different. Please refer to 1970 [PRF] for full details. For convenience, the random number algorithm 1971 with the correct modification is cited in Annex A. 1973 160-bit XKEY and XVAL values are used, so b = 160. On each full 1974 authentication, the Master Key is used as the initial secret seed-key 1975 XKEY. The optional user input values (XSEED_j) in step 3.1 are set 1976 to zero. 1978 On full authentication, the resulting 320-bit random numbers x_0, 1979 x_1, ..., x_m-1 are concatenated and partitioned into suitable-sized 1980 chunks and used as keys in the following order: K_encr (128 bits), 1981 K_aut (128 bits), Master Session Key (64 bytes), Extended Master 1982 Session Key (64 bytes). 1984 On fast re-authentication, the same pseudo-random number generator 1985 can be used to generate a new Master Session Key and a new Extended 1986 Master Session Key. The seed value XKEY' is calculated as follows: 1988 XKEY' = SHA1(Identity|counter|NONCE_S| MK) 1990 In the formula above, the Identity denotes the fast re-authentication 1991 identity, without any terminating null characters, from the 1992 AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, if 1993 EAP-Response/AKA-Identity was not used on fast re-authentication, the 1994 identity string from the EAP-Response/Identity packet. The counter 1995 denotes the counter value from AT_COUNTER attribute used in the 1996 EAP-Response/AKA-Reauthentication packet. The counter is used in 1997 network byte order. NONCE_S denotes the 16-byte random NONCE_S value 1998 from the AT_NONCE_S attribute used in the 1999 EAP-Request/AKA-Reauthentication packet. The MK is the Master Key 2000 derived on the preceding full authentication. 2002 On fast re-authentication, the pseudo-random number generator is run 2003 with the new seed value XKEY', and the resulting 320-bit random 2004 numbers x_0, x_1, ..., x_m-1 are concatenated and partitioned into 2005 64-byte chunks and used as the new 64-byte Master Session Key and the 2006 new 64-byte Extended Master Session Key. Note that because K_encr 2007 and K_aut are not derived on fast re-authentication, the Master 2008 Session Key and the Extended Master Session key are obtained from the 2009 beginning of the key stream x_0, x_1, .... 2011 The first 32 bytes of the MSK can be used as the Pairwise Master Key 2012 (PMK) for IEEE 802.11i. 2014 When the RADIUS attributes specified in [RFC2548] are used to 2015 transport keying material, then the first 32 bytes of the MSK 2016 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to 2017 MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material 2018 (the MSK) are used. 2020 7. Message Format and Protocol Extensibility 2022 7.1 Message Format 2024 As specified in [RFC3748], EAP packets begin with the Code, 2025 Identifiers, Length, and Type fields, which are followed by EAP 2026 method specific Type-Data. The Code field in the EAP header is set 2027 to 1 for EAP requests, and to 2 for EAP Responses. The usage of the 2028 Length and Identifier fields in the EAP header is also specified in 2029 [RFC3748]. In EAP-AKA, the Type field is set to 23. 2031 In EAP-AKA, the Type-Data begins with an EAP-AKA header that consists 2032 of a 1-octet Subtype field, and a 2-octet reserved field. The 2033 Subtype values used in EAP-AKA are defined in Section 10. The 2034 formats of the EAP header and the EAP-AKA header are shown below. 2036 0 1 2 3 2037 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 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 | Code | Identifier | Length | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Type | Subtype | Reserved | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 The rest of the Type-Data, immediately following the EAP-AKA header, 2045 consists of attributes that are encoded in Type, Length, Value 2046 format. The figure below shows the generic format of an attribute. 2048 0 1 2 3 2049 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 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 |Attribute Type | Length | Value... 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 Attribute Type 2056 Indicates the particular type of attribute. The attribute type 2057 values are listed in 2058 Section 10 2059 . 2061 Length 2063 Indicates the length of this attribute in multiples of 4 bytes. 2064 The maximum length of an attribute is 1024 bytes. The length 2065 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 is two or more bytes in length. The 2071 type and length fields determine the format and length of the 2072 value field. 2074 Attributes numbered within the range 0 through 127 are called 2075 non-skippable attributes. When an EAP-AKA peer encounters a 2076 non-skippable attribute type that the peer does not recognize, the 2077 peer MUST send the EAP-Response/AKA-Client-Error packet, and the 2078 authentication exchange terminates. If an EAP-AKA server encounters 2079 a non-skippable attribute that the server does not recognize, then 2080 the server sends EAP-Request/AKA-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), and the authentication exchange 2084 terminates. 2086 When an attribute numbered in the range 128 through 255 is 2087 encountered but not recognized that particular attribute is ignored, 2088 but the rest of the attributes and message data MUST still be 2089 processed. The Length field of the attribute is used to skip the 2090 attribute value when searching for the next attribute. These 2091 attributes are called skippable attributes. 2093 Unless otherwise specified, the order of the attributes in an EAP AKA 2094 message is insignificant, and an EAP-AKA implementation should not 2095 assume a certain order to be used. 2097 Attributes can be encapsulated within other attributes. In other 2098 words, the value field of an attribute type can be specified to 2099 contain other attributes. 2101 7.2 Protocol Extensibility 2103 EAP-AKA can be extended by specifying new attribute types. If 2104 skippable attributes are used, it is possible to extend the protocol 2105 without breaking old implementations. As specified in Section 9.13, 2106 if new attributes are specified for EAP-Request/AKA-Identity or 2107 EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to 2108 integrity protect the new attributes. 2110 When specifying new attributes, it should be noted that EAP-AKA does 2111 not support message fragmentation. Hence, the sizes of the new 2112 extensions MUST be limited so that the maximum transfer unit (MTU) of 2113 the underlying lower layer is not exceeded. According to [RFC3748], 2114 lower layers must provide an EAP MTU of 1020 bytes or greater, so any 2115 extensions to EAP-AKA SHOULD NOT exceed the EAP MTU of 1020 bytes. 2117 EAP-AKA packets do not include a version field. However, should 2118 there be a reason to revise this protocol in the future, new 2119 non-skippable or skippable attributes could be specified in order to 2120 implement revised EAP-AKA versions in a backward-compatible manner. 2121 It is possible to introduce version negotiation in the 2122 EAP-Request/AKA-Identity and EAP-Response/AKA-Identity messages by 2123 specifying new skippable attributes. 2125 8. Messages 2127 This section specifies the messages used in EAP-AKA. It specifies 2128 when a message may be transmitted or accepted, which attributes are 2129 allowed in a message, which attributes are required in a message, and 2130 other message specific details. Message format is specified in 2131 Section 7.1. 2133 8.1 EAP-Request/AKA-Identity 2135 The EAP/AKA-Identity roundtrip MAY used for obtaining the peer 2136 identity to the server. As discussed in Section 4.1, several 2137 AKA-Identity rounds may be required in order to obtain a valid peer 2138 identity. 2140 The server MUST include one of the following identity requesting 2141 attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, AT_ANY_ID_REQ. 2142 These three attributes are mutually exclusive, so the server MUST NOT 2143 include more than one of the attributes. 2145 If the server has previously issued an EAP-Request/AKA-Identity 2146 message with the AT_PERMANENT_ID_REQ attribute, and if the server has 2147 received a response from the peer, then the server MUST NOT issue a 2148 new EAP-Request/AKA-Identity packet. 2150 If the server has previously issued an EAP-Request/AKA-Identity 2151 message with the AT_FULLAUTH_ID_REQ attribute, and if the server has 2152 received a response from the peer, then the server MUST NOT issue a 2153 new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ or 2154 AT_FULLAUTH_ID_REQ attributes. 2156 If the server has previously issued an EAP-Request/AKA-Identity 2157 message with the AT_ANY_ID_REQ attribute, and if the server has 2158 received a response from the peer, then the server MUST NOT issue a 2159 new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ. 2161 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. 2163 8.2 EAP-Response/AKA-Identity 2165 The peer sends EAP-Response/AKA-Identity in response to a valid EAP- 2166 Request/AKA-Identity from the server. 2168 The peer MUST include the AT_IDENTITY attribute. The usage of 2169 AT_IDENITY is defined in Section 4.1. 2171 This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. 2173 8.3 EAP-Request/AKA-Challenge 2175 The server sends the EAP-Request/AKA-Challenge on full authentication 2176 after successfully obtaining the subscriber identity. 2178 The AT_RAND attribute MUST be included. 2180 AT_MAC MUST be included. In EAP-Request/AKA-Challenge, there is no 2181 message-specific data covered by the MAC, see Section 9.15. 2183 The AT_RESULT_IND attribute MAY be included. The usage of this 2184 attribute is discussed in Section 6.2. 2186 The AT_CHECKCODE attribute MAY be included, and in certain cases 2187 specified in Section 9.13, it MUST be included. 2189 The EAP-Request/AKA-Challenge packet MAY include encrypted attributes 2190 for identity privacy and for communicating the next re-authentication 2191 identity. In this case, the AT_IV and AT_ENCR_DATA attributes are 2192 included (Section 9.12). 2194 The plaintext of the AT_ENCR_DATA value field consist of nested 2195 attributes. The nested attributes MAY include AT_PADDING (as 2196 specified in Section 9.12). If the server supports identity privacy 2197 and wants to communicate a pseudonym to the peer for the next full 2198 authentication, then the nested encrypted attributes include the 2199 AT_NEXT_PSEUDONYM attribute. If the server supports 2200 re-authentication and wants to communicate a fast re-authentication 2201 identity to the peer, then the nested encrypted attributes include 2202 the AT_NEXT_REAUTH_ID attribute. Later versions of this protocol MAY 2203 specify additional attributes to be included within the encrypted 2204 data. 2206 When processing this message, the peer MUST process AT_RAND and 2207 AT_AUTN before processing other attributes. Only if these attributes 2208 are verified to be valid, the peer derives keys and verifies AT_MAC. 2209 The operation in case an error occurs is specified in Section 6.3.1. 2211 8.4 EAP-Response/AKA-Challenge 2213 The peer sends EAP-Response/AKA-Challenge in response to a valid 2214 EAP-Request/AKA-Challenge. 2216 Sending this packet indicates, that the peer has successfully 2217 authenticated the server and that the EAP exchange will be accepted 2218 by the peer's local policy. Hence, if these conditions are not met, 2219 then the peer MUST NOT send EAP-Response/AKA-Challenge, but the peer 2220 MUST send EAP-Response/AKA-Client-Error. 2222 The AT_MAC attribute MUST be included. In 2223 EAP-Response/AKA-Challenge, there is no message-specific data covered 2224 by the MAC, see Section 9.15. 2226 The AT_RES attribute MUST be included. 2228 The AT_CHECKCODE attribute MAY be included, and in certain cases 2229 specified in Section 9.13, it MUST be included. 2231 The AT_RESULT_IND attribute MAY be included, if it was included in 2232 EAP-Request/AKA-Challenge. The usage of this attribute is discussed 2233 in Section 6.2. 2235 Later versions of this protocol MAY make use of the AT_ENCR_DATA and 2236 AT_IV attributes in this message to include encrypted (skippable) 2237 attributes. The EAP server MUST process EAP-Response/AKA-Challenge 2238 messages that include these attributes even if the server did not 2239 implement these optional attributes. 2241 8.5 EAP-Response/AKA-Authentication-Reject 2243 The peer sends the EAP-Response/AKA-Authentication-Reject packet if 2244 it does not accept the AUTN parameter. This version of the protocol 2245 does not specify any attributes for this message. Future versions of 2246 the protocol MAY specify attributes for this message. 2248 The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in 2249 this message. 2251 8.6 EAP-Response/AKA-Synchronization-Failure 2253 The peer sends the EAP-Response/AKA-Synchronization-Failure, when the 2254 sequence number in the AUTN parameter is incorrect. 2256 The peer MUST include the AT_AUTS attribute. Future versions of the 2257 protocol MAY specify other additional attributes for this message. 2259 The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in 2260 this message. 2262 8.7 EAP-Request/AKA-Reauthentication 2264 The server sends the EAP-Request/AKA-Reauthentication message if it 2265 wants to use fast re-authentication, and if it has received a valid 2266 fast re-authentication identity in EAP-Response/Identity or 2267 EAP-Response/AKA-Identity. 2269 The AT_MAC attribute MUST be included. No message-specific data is 2270 included in the MAC calculation, see Section 9.15. 2272 The AT_RESULT_IND attribute MAY be included. The usage of this 2273 attribute is discussed in Section 6.2. 2275 The AT_CHECKCODE attribute MAY be included, and in certain cases 2276 specified in Section 9.13, it MUST be included. 2278 The AT_IV and AT_ENCR_DATA attributes MUST be included. The 2279 plaintext consists of the following nested encrypted attributes, 2280 which MUST be included: AT_COUNTER and AT_NONCE_S. In addition, the 2281 nested encrypted attributes MAY include the following attributes: 2282 AT_NEXT_REAUTH_ID and AT_PADDING. 2284 8.8 EAP-Response/AKA-Reauthentication 2286 The client sends the EAP-Response/AKA-Reauthentication packet in 2287 response to a valid EAP-Request/AKA-Reauthentication. 2289 The AT_MAC attribute MUST be included. For EAP-Response/AKA- 2290 Reauthentication, the MAC code is calculated over the following data: 2291 EAP packet| NONCE_S. The EAP packet is represented as specified in 2292 Section 7.1. It is followed by the 16-byte NONCE_S value from the 2293 server's AT_NONCE_S attribute. 2295 The AT_CHECKCODE attribute MAY be included, and in certain cases 2296 specified in Section 9.13, it MUST be included. 2298 The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested 2299 encrypted attributes MUST include the AT_COUNTER attribute. The 2300 AT_COUNTER_TOO_SMALL attribute MAY be included in the nested 2301 encrypted attributes, and it is included in cases specified in 2302 Section 5. The AT_PADDING attribute MAY be included. 2304 The AT_RESULT_IND attribute MAY be included, if it was included in 2305 EAP-Request/AKA-Reauthentication. The usage of this attribute is 2306 discussed in Section 6.2. 2308 Sending this packet without AT_COUNTER_TOO_SMALL indicates, that the 2309 peer has successfully authenticated the server and that the EAP 2310 exchange will be accepted by the peer's local policy. Hence, if 2311 these conditions are not met, then the peer MUST NOT send 2312 EAP-Response/AKA-Reauthentication, but the peer MUST send 2313 EAP-Response/AKA-Client-Error. 2315 8.9 EAP-Response/AKA-Client-Error 2317 The peer sends EAP-Response/AKA-Client-Error in error cases, as 2318 specified in Section 6.3.1. 2320 The AT_CLIENT_ERROR_CODE attribute MUST be included. The AT_MAC, 2321 AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with this packet. 2323 8.10 EAP-Request/AKA-Notification 2325 The usage of this message is specified in Section 6. 2327 The AT_NOTIFICATION attribute MUST be included. 2329 The AT_MAC attribute MUST be included if the P bit of the 2330 AT_NOTIFICATION code is set to zero, and MUST NOT be included if the 2331 P bit is set to one. The P bit is discussed in in Section 6. 2333 No message-specific data is included in the MAC calculation. See 2334 Section 9.15. 2336 If EAP-Request/AKA-Notification is used on a fast re-authentication 2337 exchange, and if the P bit in AT_NOTIFICATION is set to zero, then 2338 AT_COUNTER is used for replay protection. In this case, the 2339 AT_ENCR_DATA and AT_IV attributes MUST be included, and the 2340 encapsulated plaintext attributes MUST include the AT_COUNTER 2341 attribute. The counter value included in AT_COUNTER MUST be the same 2342 as in the EAP-Request/AKA-Reauthentication packet on the same fast 2343 re-authentication exchange. 2345 8.11 EAP-Response/AKA-Notification 2347 The usage of this message is specified in Section 6. This packet is 2348 an acknowledgement of EAP-Request/AKA-Notification. 2350 The AT_MAC attribute MUST included in cases when the P bit of the 2351 notification code in AT_NOTIFICATION of EAP-Request/AKA-Notification 2352 is set to zero, and MUST NOT be included in cases when the P bit is 2353 set to one. The P bit is discussed in Section 6. 2355 If EAP-Request/AKA-Notification is used on fast a re-authentication 2356 exchange, and if the P bit in AT_NOTIFICATION is set to zero, then 2357 AT_COUNTER is used for replay protection. In this case, the 2358 AT_ENCR_DATA and AT_IV attributes MUST be included, and the 2359 encapsulated plaintext attributes MUST include the AT_COUNTER 2360 attribute. The counter value included in AT_COUNTER MUST be the same 2361 as in the EAP-Request/AKA-Reauthentication packet on the same fast 2362 re-authentication exchange. 2364 9. Attributes 2366 This section specifies the format of message attributes. The 2367 attribute type numbers are specified in Section 10. 2369 9.1 Table of Attributes 2371 The following table provides a guide to which attributes may be found 2372 in which kinds of messages, and in what quantity. Messages are 2373 denoted with numbers in parentheses as follows: (1) 2374 EAP-Request/AKA-Identity, (2) EAP-Response/AKA-Identity, (3) 2375 EAP-Request/AKA-Challenge, (4) EAP-Response/AKA-Challenge, (5) 2376 EAP-Request/AKA-Notification, (6) EAP-Response/AKA-Notification, (7) 2377 EAP- Response/AKA-Client-Error (8) EAP-Request/AKA-Reauthentication, 2378 (9) EAP-Response/AKA-Re-authentication, (10) 2379 EAP-Response/AKA-Authentication-Reject, and (11) 2380 EAP-Response/AKA-Synchronization-Failure. The column denoted with 2381 "E" indicates whether the attribute is a nested attribute that MUST 2382 be included within AT_ENCR_DATA. 2384 "0" indicates that the attribute MUST NOT be included in the message, 2385 "1" indicates that the attribute MUST be included in the message, 2386 "0-1" indicates that the attribute is sometimes included in the 2387 message, and "0*" indicates that the attribute is not included in the 2388 message in cases specified in this document, but MAY be included in 2389 the future versions of the protocol. 2391 Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E 2392 AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 2393 AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 2394 AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 2395 AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 0 0 N 2396 AT_RAND 0 0 1 0 0 0 0 0 0 0 0 N 2397 AT_AUTN 0 0 1 0 0 0 0 0 0 0 0 N 2398 AT_RES 0 0 0 1 0 0 0 0 0 0 0 N 2399 AT_AUTS 0 0 0 0 0 0 0 0 0 0 1 N 2400 AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 0 0 Y 2401 AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 0 0 Y 2402 AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N 2403 AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N 2404 AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 0 0 Y 2405 AT_CHECKCODE 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N 2406 AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N 2407 AT_MAC 0 0 1 1 0-1 0-1 0 1 1 0 0 N 2408 AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 0 0 Y 2409 AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 0 0 Y 2410 AT_NONCE_S 0 0 0 0 0 0 0 1 0 0 0 Y 2411 AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 0 0 N 2412 AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 0 0 N 2414 It should be noted that attributes AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ 2415 and AT_FULLAUTH_ID_REQ are mutually exclusive, so that only one of 2416 them can be included at the same time. If one of the attributes 2417 AT_IV and AT_ENCR_DATA is included, then both of the attributes MUST 2418 be included. 2420 9.2 AT_PERMANENT_ID_REQ 2422 The format of the AT_PERMANENT_ID_REQ attribute is shown below. 2424 0 1 2 3 2425 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 |AT_PERM..._REQ | Length = 1 | Reserved | 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 The use of the AT_PERMANENT_ID_REQ is defined in Section 4.1. The 2431 value field only contains two reserved bytes, which are set to zero 2432 on sending and ignored on reception. 2434 9.3 AT_ANY_ID_REQ 2436 The format of the AT_ANY_ID_REQ attribute is shown below. 2438 0 1 2 3 2439 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 |AT_ANY_ID_REQ | Length = 1 | Reserved | 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 The use of the AT_ANY_ID_REQ is defined in Section 4.1. The value 2445 field only contains two reserved bytes, which are set to zero on 2446 sending and ignored on reception. 2448 9.4 AT_FULLAUTH_ID_REQ 2450 The format of the AT_FULLAUTH_ID_REQ attribute is shown below. 2452 0 1 2 3 2453 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2455 |AT_FULLAUTH_...| Length = 1 | Reserved | 2456 +---------------+---------------+-------------------------------+ 2458 The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.1. The 2459 value field only contains two reserved bytes, which are set to zero 2460 on sending and ignored on reception. 2462 9.5 AT_IDENTITY 2464 The format of the AT_IDENTITY attribute is shown below. 2466 0 1 2 3 2467 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 2468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 | AT_IDENTITY | Length | Actual Identity Length | 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 | | 2472 . Identity . 2473 . . 2474 | | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 The use of the AT_IDENTITY is defined in Section 4.1. The value 2478 field of this attribute begins with 2-byte actual identity length, 2479 which specifies the length of the identity in bytes. This field is 2480 followed by the subscriber identity of the indicated actual length. 2481 The identity is the permanent identity, a pseudonym identity or a 2482 fast re-authentication identity. The identity format is specified in 2483 Section 4.1.1. The same identity format is used in the AT_IDENTITY 2484 attribute and the EAP-Response/Identity packet, with the exception 2485 that the peer MUST NOT decorate the identity it includes in 2486 AT_IDENTITY. The identity does not include any terminating null 2487 characters. Because the length of the attribute must be a multiple 2488 of 4 bytes, the sender pads the identity with zero bytes when 2489 necessary. 2491 9.6 AT_RAND 2493 The format of the AT_RAND attribute is shown below. 2495 0 1 2 3 2496 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 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2498 | AT_RAND | Length = 5 | Reserved | 2499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2500 | | 2501 | RAND | 2502 | | 2503 | | 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 The value field of this attribute contains two reserved bytes 2507 followed by the AKA RAND parameter, 16 bytes (128 bits). The 2508 reserved bytes are set to zero when sending and ignored on reception. 2510 9.7 AT_AUTN 2512 The format of the AT_AUTN attribute is shown below. 2514 0 1 2 3 2515 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 | AT_AUTN | Length = 5 | Reserved | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 | | 2520 | AUTN | 2521 | | 2522 | | 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 The value field of this attribute contains two reserved bytes 2526 followed by the AKA AUTN parameter, 16 bytes (128 bits). The 2527 reserved bytes are set to zero when sending and ignored on reception. 2529 9.8 AT_RES 2531 The format of the AT_RES attribute is shown below. 2533 0 1 2 3 2534 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 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 | AT_RES | Length | RES Length | 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2538 | | 2539 | RES | 2540 | | 2541 | | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2544 The value field of this attribute begins with the 2-byte RES Length, 2545 which is identifies the exact length of the RES in bits. The RES 2546 length is followed by the AKA RES parameter. According to [TS 2547 33.105] the length of the AKA RES can vary between 32 and 128 bits. 2548 Because the length of the AT_RES attribute must be a multiple of 4 2549 bytes, the sender pads the RES with zero bits where necessary. 2551 9.9 AT_AUTS 2553 The format of the AT_AUTS attribute is shown below. 2555 0 1 2 3 2556 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 2558 | AT_AUTS | Length = 4 | | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2560 | | 2561 | AUTS | 2562 | | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 The value field of this attribute contains the AKA AUTS parameter, 2566 112 bits (14 bytes). 2568 9.10 AT_NEXT_PSEUDONYM 2570 The format of the AT_NEXT_PSEUDONYM attribute is shown below. 2572 0 1 2 3 2573 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 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 | AT_NEXT_PSEU..| Length | Actual Pseudonym Length | 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 | | 2578 . Next Pseudonym . 2579 . . 2580 | | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 The value field of this attribute begins with 2-byte actual pseudonym 2584 length which specifies the length of the following pseudonym in 2585 bytes. This field is followed by a pseudonym username that the peer 2586 can use in the next authentication. The username MUST NOT include 2587 any realm portion. The username does not include any terminating 2588 null characters. Because the length of the attribute must be a 2589 multiple of 4 bytes, the sender pads the pseudonym with zero bytes 2590 when necessary. The username encoding MUST follow the UTF-8 2591 transformation format [RFC2279]. This attribute MUST always be 2592 encrypted by encapsulating it within the AT_ENCR_DATA attribute. 2594 9.11 AT_NEXT_REAUTH_ID 2596 The format of the AT_NEXT_REAUTH_ID attribute is shown below. 2598 0 1 2 3 2599 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 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length| 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 | | 2604 . Next Fast Re-authentication Username . 2605 . . 2606 | | 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 The value field of this attribute begins with 2-byte actual 2610 re-authentication identity length which specifies the length of the 2611 following fast re-authentication identity in bytes. This field is 2612 followed by a fast re-authentication identity that the peer can use 2613 in the next fast re-authentication, as described in Section 5. In 2614 environments where a realm portion is required, the fast 2615 re-authentication identity includes both a username portion and a 2616 realm name portion. The fast re-authentication identity does not 2617 include any terminating null characters. Because the length of the 2618 attribute must be a multiple of 4 bytes, the sender pads the fast 2619 re-authentication identity with zero bytes when necessary. The 2620 identity encoding MUST follow the UTF-8 transformation format 2621 [RFC2279]. This attribute MUST always be encrypted by encapsulating 2622 it within the AT_ENCR_DATA attribute. 2624 9.12 AT_IV, AT_ENCR_DATA and AT_PADDING 2626 AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted 2627 information between the EAP-AKA peer and server. 2629 The value field of AT_IV contains two reserved bytes followed by a 2630 16-byte initialization vector required by the AT_ENCR_DATA attribute. 2631 The reserved bytes are set to zero when sending and ignored on 2632 reception. The AT_IV attribute MUST be included if and only if the 2633 AT_ENCR_DATA is included. Section 6.3 specifies the operation if a 2634 packet that does not meet this condition is encountered. 2636 The sender of the AT_IV attribute chooses the initialization vector 2637 by random. The sender MUST NOT reuse the initialization vector value 2638 from previous EAP-AKA packets. The sender SHOULD use a good source 2639 of randomness to generate the initialization vector. Please see 2640 [RFC1750] for more information about generating random numbers for 2641 security applications. The format of AT_IV is shown below. 2643 0 1 2 3 2644 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 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 | AT_IV | Length = 5 | Reserved | 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 | | 2649 | Initialization Vector | 2650 | | 2651 | | 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2654 The value field of the AT_ENCR_DATA attribute consists of two 2655 reserved bytes followed by cipher text bytes encrypted using the 2656 Advanced Encryption Standard (AES) [AES] with a 128-bit key in the 2657 Cipher Block Chaining (CBC) mode of operation using the 2658 initialization vector from the AT_IV attribute. The reserved bytes 2659 are set to zero when sending and ignored on reception. Please see 2660 [CBC] for a description of the CBC mode. The format of the 2661 AT_ENCR_DATA attribute is shown below. 2663 0 1 2 3 2664 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 2665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2666 | AT_ENCR_DATA | Length | Reserved | 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 | | 2669 . Encrypted Data . 2670 . . 2671 | | 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 The derivation of the encryption key (K_encr) is specified in Section 2675 6.4. 2677 The plaintext consists of nested EAP-AKA attributes. 2679 The encryption algorithm requires the length of the plaintext to be a 2680 multiple of 16 bytes. The sender may need to include the AT_PADDING 2681 attribute as the last attribute within AT_ENCR_DATA. The AT_PADDING 2682 attribute is not included if the total length of other nested 2683 attributes within the AT_ENCR_DATA attribute is a multiple of 16 2684 bytes. As usual, the Length of the Padding attribute includes the 2685 Attribute Type and Attribute Length fields. The length of the 2686 Padding attribute is 4, 8 or 12 bytes. It is chosen so that the 2687 length of the value field of the AT_ENCR_DATA attribute becomes a 2688 multiple of 16 bytes. The actual pad bytes in the value field are 2689 set to zero (00 hexadecimal) on sending. The recipient of the 2690 message MUST verify that the pad bytes are set to zero. If this 2691 verification fails on the peer, then it MUST send the 2692 EAP-Response/AKA-Client- Error packet with the error code "unable to 2693 process packet" to terminate the authentication exchange. If this 2694 verification fails on the server, then the server sends the 2695 EAP-Response/AKA-Notification packet with an AT_NOTIFICATION code 2696 that implies failure to terminate the authentication exchange. The 2697 format of the AT_PADDING attribute is shown below. 2699 0 1 2 3 2700 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 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 | AT_PADDING | Length | Padding... | 2703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2704 | | 2705 | | 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 9.13 AT_CHECKCODE 2710 The AT_MAC attribute is not used in the very first EAP-AKA messages 2711 during the AKA-Identity round, because keying material has not been 2712 derived yet. The peer and the server may exchange one or more pairs 2713 of EAP-AKA messages of the Subtype AKA-Identity before keys are 2714 derived and before the AT_MAC attribute can be applied. The 2715 EAP/AKA-Identity messages may also be used upon fast 2716 re-authentication. 2718 The AT_CHECKCODE attribute MAY be used to protect the 2719 EAP/AKA-Identity messages. In full authentication, the server MAY 2720 include the AT_CHECKCODE in EAP-Request/AKA-Challenge, and the peer 2721 MAY include AT_CHECKCODE in EAP-Response/AKA-Challenge. In fast 2722 re-authentication, the server MAY include AT_CHECKCODE in 2723 EAP-Request/AKA-Reauthentication, and the peer MAY include 2724 AT_CHECKCODE in EAP-Response/AKA-Reauthentication. The fact that the 2725 peer receives an EAP-Request with AT_CHECKCODE does not imply that 2726 the peer would have to include AT_CHECKCODE in the corresponding 2727 response. The peer MAY include AT_CHECKCODE even if the server did 2728 not include AT_CHECKCODE in the EAP request. Because the AT_MAC 2729 attribute is used in these messages, AT_CHECKCODE will be integrity 2730 protected with AT_MAC. The format of the AT_CHECKCODE attribute is 2731 shown below. 2733 0 1 2 3 2734 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 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 | AT_CHECKCODE | Length | Reserved | 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 | | 2739 | Checkcode (0 or 20 bytes) | 2740 | | 2741 | | 2742 | | 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 The value field of AT_CHECKCODE begins with two reserved bytes, which 2746 may be followed by a 20-byte checkcode. If the checkcode is not 2747 included in AT_CHECKCODE, then the attribute indicates that no 2748 EAP/AKA-Identity messages were exchanged. This may occur in both 2749 full authentication and fast re-authentication. The reserved bytes 2750 are set to zero when sending and ignored on reception. 2752 The checkcode is a hash value, calculated with SHA1 [SHA-1], over all 2753 EAP-Request/AKA-Identity and EAP-Response/ AKA-Identity packets 2754 exchanged in this authentication exchange. The packets are included 2755 in the order that they were transmitted, that is, starting with the 2756 first EAP-Request/ AKA-Identity message, followed by the 2757 corresponding EAP-Response/ AKA-Identity, followed by the second 2758 EAP-Request/ AKA-Identity (if used) etc. 2760 EAP packets are included in the hash calculation "as-is", as they 2761 were transmitted or received. All reserved bytes, padding bytes etc. 2762 that are specified for various attributes are included as such, and 2763 the receiver must not reset them to zero. No delimiter bytes, 2764 padding or any other framing are included between the EAP packets 2765 when calculating the checkcode. 2767 Messages are included in request/response pairs; in other words only 2768 full "round trips" are included. Packets that are silently discarded 2769 are not included, and retransmitted packets (that have the same 2770 Identifier value) are only included once. (The base EAP protocol 2771 [RFC3748] ensures that requests and responses "match".) The EAP 2772 server must only include an EAP-Request/AKA-Identity in the 2773 calculation once it has received a corresponding response, with the 2774 same Identifier value. 2776 The peer must include the EAP-Request/AKA-Identity and the 2777 corresponding response in the calculation only if the peer receives a 2778 subsequent EAP-Request/AKA-Challenge, or a follow-up 2779 EAP-Request/AKA-Identity with a different Identifier value than in 2780 the first EAP-Request/AKA-Identity. 2782 The AT_CHECKCODE attribute is optional to implement. It is specified 2783 in order to allow protecting the EAP/AKA-Identity messages and any 2784 future extensions to them. The implementation of AT_CHECKCODE is 2785 RECOMMENDED. 2787 If the receiver of AT_CHECKCODE implements this attribute, then the 2788 receiver MUST check that the checkcode is correct. If the checkcode 2789 is invalid, the receiver must operate as specified in Section 6.3. 2791 If the EAP/AKA-Identity messages are extended with new attributes 2792 then AT_CHECKCODE MUST be implemented and used. More specifically, 2793 if the server includes any other attributes than AT_PERMANENT_ID_REQ, 2794 AT_FULLAUTH_ID_REQ or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity 2795 packet, then the server MUST include AT_CHECKCODE in 2796 EAP-Request/AKA-Challenge or EAP-Request/AKA-Reauthentication. If 2797 the peer includes any other attributes than AT_IDENTITY in the 2798 EAP-Response/AKA-Identity message, then the peer MUST include 2799 AT_CHECKCODE in EAP-Response/AKA-Challenge or 2800 EAP-Response/AKA-Reauthentication. 2802 If the server implements the processing of any other attribute than 2803 AT_IDENTITY for the EAP-Response/AKA-Identity message, then the 2804 server MUST implement AT_CHECKCODE. In this case, if the server 2805 receives any other attribute than AT_IDENTITY in the EAP- 2806 Response/AKA-Identity message, then the server MUST check that 2807 AT_CHECKCODE is present in EAP-Response/AKA-Challenge or EAP- 2808 Response/AKA-Reauthentication. The operation when a mandatory 2809 attribute is missing is specified in Section 6.3. 2811 Similarly, if the peer implements the processing of any other 2812 attribute than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ or 2813 AT_ANY_ID_REQ for the EAP-Request/AKA-Identity packet, then the peer 2814 MUST implement AT_CHECKCODE. In this case, if the peer receives any 2815 other attribute than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ or 2816 AT_ANY_ID_REQ in the EAP-Request/AKA-Identity packet, then the peer 2817 MUST check that AT_CHECKCODE is present in EAP-Request/AKA-Challenge 2818 or EAP-Request/AKA-Reauthentication. The operation when a mandatory 2819 attribute is missing is specified in Section 6.3. 2821 9.14 AT_RESULT_IND 2823 The format of the AT_RESULT_IND attribute is shown below. 2825 0 1 2 3 2826 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 2827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2828 | AT_RESULT_...| Length = 1 | Reserved | 2829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2831 The value field of this attribute consists of two reserved bytes, 2832 which are set to zero upon sending and ignored upon reception. This 2833 attribute is always sent unencrypted, so it MUST NOT be encapsulated 2834 within the AT_ENCR_DATA attribute. 2836 9.15 AT_MAC 2838 The AT_MAC attribute is used for EAP-AKA message authentication. 2839 Section 8 specifies which messages AT_MAC MUST be included. 2841 The value field of the AT_MAC attribute contains two reserved bytes 2842 followed by a keyed message authentication code (MAC). The MAC is 2843 calculated over the whole EAP packet, concatenated with optional 2844 message-specific data, with the exception that the value field of the 2845 MAC attribute is set to zero when calculating the MAC. The EAP 2846 packet includes the EAP header that begins with the Code field, the 2847 EAP-AKA header that begins with the Subtype field, and all the 2848 attributes, as specified in Section 7.1. The reserved bytes in 2849 AT_MAC are set to zero when sending and ignored on reception. The 2850 contents of the message-specific data that may be included in the MAC 2851 calculation are specified separately for each EAP-AKA message in 2852 Section 8. 2854 The format of the AT_MAC attribute is shown below. 2856 0 1 2 3 2857 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 2858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2859 | AT_MAC | Length = 5 | Reserved | 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2861 | | 2862 | MAC | 2863 | | 2864 | | 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2867 The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The 2868 HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by 2869 truncating the output to 16 bytes. Hence, the length of the MAC is 2870 16 bytes.) The derivation of the authentication key (K_aut) used in 2871 the calculation of the MAC is specified in Section 6.4. 2873 When the AT_MAC attribute is included in an EAP-AKA message, the 2874 recipient MUST process the AT_MAC attribute before looking at any 2875 other attributes, except when processing EAP-Request/AKA-Challenge. 2876 The processing of EAP-Request/AKA-Challenge is specified in Section 2877 8.3. If the message authentication code is invalid, then the 2878 recipient MUST ignore all other attributes in the message and operate 2879 as specified in Section 6.3. 2881 9.16 AT_COUNTER 2883 The format of the AT_COUNTER attribute is shown below. 2885 0 1 2 3 2886 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 2887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 | AT_COUNTER | Length = 1 | Counter | 2889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 The value field of the AT_COUNTER attribute consists of a 16-bit 2892 unsigned integer counter value, represented in network byte order. 2893 This attribute MUST always be encrypted by encapsulating it within 2894 the AT_ENCR_DATA attribute. 2896 9.17 AT_COUNTER_TOO_SMALL 2898 The format of the AT_COUNTER_TOO_SMALL attribute is shown below. 2900 0 1 2 3 2901 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 2902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2903 | AT_COUNTER...| Length = 1 | Reserved | 2904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2906 The value field of this attribute consists of two reserved bytes, 2907 which are set to zero upon sending and ignored upon reception. This 2908 attribute MUST always be encrypted by encapsulating it within the 2909 AT_ENCR_DATA attribute. 2911 9.18 AT_NONCE_S 2913 The format of the AT_NONCE_S attribute is shown below. 2915 0 1 2 3 2916 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 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2918 | AT_NONCE_S | Length = 5 | Reserved | 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2920 | | 2921 | | 2922 | NONCE_S | 2923 | | 2924 | | 2925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2927 The value field of the AT_NONCE_S attribute contains two reserved 2928 bytes followed by a random number generated by the server (16 bytes) 2929 freshly for this EAP-AKA fast re-authentication. The random number 2930 is used as challenge for the peer and also a seed value for the new 2931 keying material. The reserved bytes are set to zero upon sending and 2932 ignored upon reception. This attribute MUST always be encrypted by 2933 encapsulating it within the AT_ENCR_DATA attribute. 2935 The server MUST NOT reuse the NONCE_S value from a previous EAP-AKA 2936 fast re-authentication exchange. The server SHOULD use a good source 2937 of randomness to generate NONCE_S. Please see [RFC1750] for more 2938 information about generating random numbers for security 2939 applications. 2941 9.19 AT_NOTIFICATION 2943 The format of the AT_NOTIFICATION attribute is shown below. 2945 0 1 2 3 2946 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 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2948 |AT_NOTIFICATION| Length = 1 |S|P| Notification Code | 2949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 The value field of this attribute contains a two-byte notification 2952 code. The first and second bit (S and P) of the notification code 2953 are interpreted as described in Section 6. 2955 The notification code values listed below have been reserved. The 2956 descriptions below illustrate the semantics of the notifications. 2957 The peer implementation MAY use different wordings when presenting 2958 the notifications to the user. The "requested service" depends on 2959 the environment where EAP-AKA is applied. 2961 0 - General failure after authentication. (Implies failure, used 2962 after successful authentication.) 2964 16384 - General failure. (Implies failure, used before 2965 authentication.) 2967 32768 - Success. User has been successfully authenticated. (Does 2968 not imply failure, used after successful authentication.) The usage 2969 of this code is discussed in Section 6.2. 2971 1026 - User has been temporarily denied access to the requested 2972 service. (Implies failure, used after successful authentication.) 2974 1031 - User has not subscribed to the requested service. (Implies 2975 failure, used after successful authentication.) 2977 9.20 AT_CLIENT_ERROR_CODE 2979 The format of the AT_CLIENT_ERROR_CODE attribute is shown below. 2981 0 1 2 3 2982 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 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2984 |AT_CLIENT_ERR..| Length = 1 | Client Error Code | 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2987 The value field of this attribute contains a two-byte client error 2988 code. The following error code values have been reserved. 2990 0 "unable to process packet": a general error code 2992 10. IANA and Protocol Numbering Considerations 2994 IANA has assigned the EAP type number 23 for EAP-AKA authentication. 2996 EAP-AKA shares most of the protocol design, such as attributes and 2997 message Subtypes, with EAP-SIM [EAP-SIM]. EAP-AKA protocol numbers 2998 should be administered in the same IANA registry with EAP-SIM. This 2999 document establishes the registers and lists the initial protocol 3000 numbers for both protocols. 3002 EAP-AKA and EAP-SIM messages include a Subtype field. The Subtype is 3003 a new numbering space for which IANA administration is required. The 3004 Subtype is an 8-bit integer. The following Subtypes are specified in 3005 this document and in [EAP-SIM]: 3007 AKA-Challenge...................................1 3008 AKA-Authentication-Reject.......................2 3009 AKA-Synchronization-Failure.....................4 3010 AKA-Identity....................................5 3011 SIM-Start......................................10 3012 SIM-Challenge..................................11 3013 AKA-Notification and SIM-Notification..........12 3014 AKA-Reauthentication and SIM-Reauthentication..13 3015 AKA-Client-Error and SIM-Client-Error..........14 3017 The messages are composed of attributes, which have 8-bit attribute 3018 type numbers. Attributes numbered within the range 0 through 127 are 3019 called non-skippable attributes, and attributes within the range of 3020 128 through 255 are called skippable attributes. The EAP-AKA and 3021 EAP-SIM attribute type number is a new numbering space for which IANA 3022 administration is required. The following attribute types are 3023 specified in this document in [EAP-SIM]: 3025 AT_RAND.........................................1 3026 AT_AUTN.........................................2 3027 AT_RES..........................................3 3028 AT_AUTS.........................................4 3029 AT_PADDING......................................6 3030 AT_NONCE_MT.....................................7 3031 AT_PERMANENT_ID_REQ............................10 3032 AT_MAC.........................................11 3033 AT_NOTIFICATION................................12 3034 AT_ANY_ID_REQ..................................13 3035 AT_IDENTITY....................................14 3036 AT_VERSION_LIST................................15 3037 AT_SELECTED_VERSION............................16 3038 AT_FULLAUTH_ID_REQ.............................17 3039 AT_COUNTER.....................................19 3040 AT_COUNTER_TOO_SMALL...........................20 3041 AT_NONCE_S.....................................21 3042 AT_CLIENT_ERROR_CODE...........................22 3043 AT_IV.........................................129 3044 AT_ENCR_DATA..................................130 3045 AT_NEXT_PSEUDONYM.............................132 3046 AT_NEXT_REAUTH_ID.............................133 3047 AT_CHECKCODE..................................134 3048 AT_RESULT_IND.................................135 3050 The AT_NOTIFICATION attribute contains a 16-bit notification code 3051 value. The most significant bit of the notification code is called 3052 the S bit (success) and the second most significant bit is called the 3053 P bit (phase). If the S bit is set to zero, then the notification 3054 code indicates failure; notification codes with the S bit set to one 3055 do not indicate failure. If the P bit is set to zero, then the 3056 notification code can only be used before authentication has 3057 occurred. If the P bit is set to one, then the notification code can 3058 only be used after authentication. The notification code is a new 3059 numbering space for which IANA administration is required. The 3060 following values have been specified in this document and in 3061 [EAP-SIM]. 3063 General failure after authentication......................0 3064 User has been temporarily denied access................1026 3065 User has not subscribed to the requested service.......1031 3066 General failure.......................................16384 3067 Success...............................................32768 3069 The AT_VERSION_LIST and AT_SELECTED_VERSION attributes, specified in 3070 [EAP-SIM], contain 16-bit EAP method version numbers. The EAP method 3071 version number is a new numbering space for which IANA administration 3072 is required. Value 1 for "EAP-SIM Version 1" has been specified in 3073 [EAP-SIM]. Version numbers are not currently used in EAP-AKA. 3075 The AT_CLIENT_ERROR_CODE attribute contains a 16-bit client error 3076 code. The client error code is a new numbering space for which IANA 3077 administration is required. Values 0, 1, 2, and 3 have been 3078 specified in this document and in [EAP-SIM]. 3080 All requests for value assignment from the various number spaces 3081 described in this document require proper documentation, according to 3082 the "Specification Required" policy described in [RFC2434]. Requests 3083 must be specified in sufficient detail so that interoperability 3084 between independent implementations is possible. Possible forms of 3085 documentation include, but are not limited to, RFCs, the products of 3086 another standards body (e.g. 3GPP), or permanently and readily 3087 available vendor design notes. 3089 11. Security Considerations 3091 The EAP specification [RFC3748] describes the security 3092 vulnerabilities of EAP, which does not include its own security 3093 mechanisms. This section discusses the claimed security properties 3094 of EAP-AKA as well as vulnerabilities and security recommendations. 3096 11.1 Identity Protection 3098 EAP-AKA includes optional Identity privacy support that protects the 3099 privacy of the subscriber identity against passive eavesdropping. 3100 This document only specifies a mechanism to deliver pseudonyms from 3101 the server to the peer as part of an EAP-AKA exchange. Hence, a peer 3102 that has not yet performed any EAP-AKA exchanges does not typically 3103 have a pseudonym available. If the peer does not have a pseudonym 3104 available, then the privacy mechanism cannot be used, but the 3105 permanent identity will have to be sent in the clear. The terminal 3106 SHOULD store the pseudonym in a non-volatile memory so that it can be 3107 maintained across reboots. An active attacker that impersonates the 3108 network may use the AT_PERMANENT_ID_REQ attribute (Section 4.1.2) to 3109 learn the subscriber's IMSI. However, as discussed in Section 4.1.2, 3110 the terminal can refuse to send the cleartext IMSI if it believes 3111 that the network should be able to recognize the pseudonym. 3113 If the peer and server cannot guarantee that the pseudonym will be 3114 maintained reliably and Identity privacy is required then additional 3115 protection from an external security mechanism such as Protected 3116 Extensible Authentication Protocol (PEAP) [PEAP] may be used. The 3117 benefits and the security considerations of using an external 3118 security mechanism with EAP-AKA are beyond the scope of this 3119 document. 3121 11.2 Mutual Authentication 3123 EAP-AKA provides mutual authentication via the 3rd generation AKA 3124 mechanisms [TS 33.102] and [S.S0055-A]. 3126 Note that this mutual authentication is with the EAP server. In 3127 general, EAP methods do not authenticate the identity or services 3128 provided by the EAP authenticator (if distinct from the EAP server) 3129 unless they provide the so-called channel bindings property. The 3130 vulnerabilities related to this have been discussed in [RFC3748], 3131 [EAP Keying], [Service Identity]. 3133 EAP-AKA does not provide the channel bindings property, so it only 3134 authenticates the EAP server. However, ongoing work such as [Service 3135 Identity] may provide such support as an extension to popular EAP 3136 methods such as EAP-TLS, EAP-SIM, or EAP-AKA. 3138 11.3 Flooding the Authentication Centre 3140 The EAP-AKA server typically obtains authentication vectors from the 3141 Authentication Centre (AuC). EAP-AKA introduces a new usage for the 3142 AuC. The protocols between the EAP-AKA server and the AuC are out of 3143 the scope of this document. However, it should be noted that a 3144 malicious EAP-AKA peer may generate a lot of protocol requests to 3145 mount a denial of service attack. The EAP-AKA server implementation 3146 SHOULD take this into account and SHOULD take steps to limit the 3147 traffic that it generates towards the AuC, preventing the attacker 3148 from flooding the AuC and from extending the denial of service attack 3149 from EAP-AKA to other users of the AuC. 3151 11.4 Key Derivation 3153 EAP-AKA supports key derivation with 128-bit effective key strength. 3154 The key hierarchy is specified in Section 6.4. 3156 The Transient EAP Keys used to protect EAP-AKA packets (K_encr, 3157 K_aut), the Master Session Keys, and the Extended Master Session Keys 3158 are cryptographically separate. An attacker cannot derive any 3159 non-trivial information about any of these keys based on the other 3160 keys. An attacker also cannot calculate the pre-shared secret from 3161 AKA IK, from AKA CK, from EAP-AKA K_encr, from EAP-AKA K_aut, from 3162 the Master Session Key, or from the Extended Master Session Key. 3164 11.5 Brute-Force and Dictionary Attacks 3166 The effective strength of EAP-AKA values is 128 bits, and there are 3167 no known computationally feasible brute-force attacks. Because AKA 3168 is not a password protocol (the pre-shared secret is not a 3169 passphrase, or derived from a passphrase), EAP-AKA is not vulnerable 3170 to dictionary attacks. 3172 11.6 Protection, Replay Protection and Confidentiality 3174 AT_MAC, AT_IV, AT_ENCR_DATA and AT_COUNTER attributes are used to 3175 provide integrity, replay and confidentiality protection for EAP-AKA 3176 Requests and Responses. Integrity protection with AT_MAC includes 3177 the EAP header. Integrity protection (AT_MAC) is based on a keyed 3178 message authentication code. Confidentiality (AT_ENCR_DATA and 3179 AT_IV) is based on a block cipher. 3181 Because keys are not available in the beginning of the EAP methods, 3182 the AT_MAC attribute cannot be used for protecting EAP/AKA-Identity 3183 messages. However, the AT_CHECKCODE attribute can optionally be used 3184 to protect the integrity of the EAP/AKA-Identity roundtrip. 3186 Confidentiality protection is applied only to a part of the protocol 3187 fields. The table of attributes in Section 9.1 summarizes which 3188 fields are confidentiality protected. It should be noted that the 3189 error and notification code attributes AT_CLIENT_ERROR_CODE and 3190 AT_NOTIFICATION are not confidential but they are transmitted in the 3191 clear. Identity protection is discussed in Section 11.1. 3193 On full authentication, replay protection of the EAP exchange is 3194 provided by RAND and AUTN values from the underlying AKA scheme. 3195 Protection against replays of EAP-AKA messages is also based on the 3196 fact that messages that can include AT_MAC can only be sent once with 3197 a certain EAP-AKA Subtype, and on the fact that a different K_aut key 3198 will be used for calculating AT_MAC in each full authentication 3199 exchange. 3201 On fast re-authentication, a counter included in AT_COUNTER and a 3202 server random nonce is used to provide replay protection. The 3203 AT_COUNTER attribute is also included in EAP-AKA notifications, if 3204 they are used after successful authentication in order to provide 3205 replay protection between re-authentication exchanges. 3207 The contents of the user identity string are implicitly integrity 3208 protected by including them in key derivation. 3210 Because EAP-AKA is not a tunneling method, EAP-Request/Notification, 3211 EAP-Response/Notification, EAP-Success or EAP-Failure packets are not 3212 confidential, integrity protected or replay protected. On physically 3213 insecure networks, this may enable an attacker to mount denial of 3214 service attacks by spoofing these packets. As discussed in Section 3215 6.3, the peer will only accept EAP-Success after the peer 3216 successfully authenticates the server. Hence, the attacker cannot 3217 force the peer to believe successful mutual authentication has 3218 occurred before the peer successfully authenticates the server or 3219 after the peer failed to authenticate the server. 3221 The security considerations of EAP-AKA result indications are covered 3222 in Section 11.8 3224 An eavesdropper will see the EAP Notification, EAP_Success and 3225 EAP-Failure packets sent in the clear. With EAP-AKA, confidential 3226 information MUST NOT be transmitted in EAP Notification packets. 3228 11.7 Negotiation Attacks 3230 EAP-AKA does not protect the EAP-Response/Nak packet. Because 3231 EAP-AKA does not protect the EAP method negotiation, EAP method 3232 downgrading attacks may be possible, especially if the user uses the 3233 same identity with EAP-AKA and other EAP methods. 3235 As described in Section 7, EAP-AKA allows the protocol to be extended 3236 by defining new attribute types. When defining such attributes, it 3237 should be noted that any extra attributes included in 3238 EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not 3239 included in the MACs later on, and thus some other precautions must 3240 be taken to avoid modifications to them. 3242 EAP-AKA does not support ciphersuite negotiation or EAP-AKA protocol 3243 version negotiation. 3245 11.8 Protected Result Indications 3247 EAP-AKA supports optional protected success indications, and 3248 acknowledged failure indications. If a failure occurs after 3249 successful authentication, then the EAP-AKA failure indication is 3250 integrity and replay protected. 3252 Even if an EAP-Failure packet is lost when using EAP-AKA over an 3253 unreliable medium, then the EAP-AKA failure indications will help 3254 ensure that the peer and EAP server will know the other parties 3255 authentication decision. If protected success indications are used, 3256 then the loss of Success packet will also be addressed by the 3257 acknowledged, integrity and replay protected EAP-AKA success 3258 indication. If the optional success indications are not used, then 3259 the peer may end up believing the server succeeded authentication 3260 when it actually failed. Since access will not be granted in this 3261 case protected result indications are not needed unless the client is 3262 not able to realize it does not have access for an extended period of 3263 time. 3265 11.9 Man-in-the-middle Attacks 3267 In order to avoid man-in-the-middle attacks and session hijacking, 3268 user data SHOULD be integrity protected on physically insecure 3269 networks. The EAP-AKA Master Session Key or keys derived from it MAY 3270 be used as the integrity protection keys, or, if an external security 3271 mechanism such as PEAP is used, then the link integrity protection 3272 keys MAY be derived by the external security mechanism. 3274 There are man-in-the-middle attacks associated with the use of any 3275 EAP method within a tunneled protocol. For instance, an early 3276 version of PEAP [PEAP-02] was vulnerable to this attack. This 3277 specification does not address these attacks. If EAP-AKA is used 3278 with a tunneling protocol, there should be cryptographic binding 3279 provided between the protocol and EAP-AKA to prevent 3280 man-in-the-middle attacks through rogue authenticators being able to 3281 setup one-way authenticated tunnels. For example, newer versions of 3282 PEAP include such cryptographic binding. The EAP-AKA Master Session 3283 Key MAY be used to provide the cryptographic binding. However the 3284 mechanism how the binding is provided depends on the tunneling 3285 protocol and is beyond the scope of this document. 3287 11.10 Generating Random Numbers 3289 An EAP-AKA implementation SHOULD use a good source of randomness to 3290 generate the random numbers required in the protocol. Please see 3291 [RFC1750] for more information on generating random numbers for 3292 security applications. 3294 12. Security Claims 3296 This section provides the security claims required by [RFC3748]. 3298 Auth. Mechanism: EAP-AKA is based on the AKA mechanism, which is an 3299 authentication and key agreement mechanism based on a symmetric 3300 128-bit pre-shared secret. 3302 Ciphersuite negotiation: No 3304 Mutual authentication: Yes (Section 11.2) 3306 Integrity protection: Yes (Section 11.6) 3308 Replay protection: Yes (Section 11.6) 3310 Confidentiality: Yes, except method specific success and failure 3311 indications (Section 11.1, Section 11.6) 3312 Key derivation: Yes 3314 Key strength: EAP-AKA supports key derivation with 128-bit effective 3315 key strength. 3317 Description of key hierarchy: Please see Section 6.4. 3319 Dictinary attack protection: N/A (Section 11.5) 3321 Fast reconnect: Yes 3323 Cryptographic binding: N/A 3325 Session independence: Yes (Section 11.4) 3327 Fragmentation: No 3329 Channel binding: No 3331 Indication of vulnerabilities. Vulnerabilities are discussed in 3332 Section 11. 3334 13. Acknowledgements and Contributions 3336 The authors wish to thank Rolf Blom of Ericsson, Bernard Aboba of 3337 Microsoft, Arne Norefors of Ericsson, N.Asokan of Nokia, Valtteri 3338 Niemi of Nokia, Kaisa Nyberg of Nokia, Jukka-Pekka Honkanen of Nokia, 3339 Pasi Eronen of Nokia, Olivier Paridaens of Alcatel and Ilkka Uusitalo 3340 of Ericsson for interesting discussions in this problem space. 3342 Many thanks to Yoshihiro Ohba for reviewing the document. 3344 This protocol has been partly developed in parallel with EAP-SIM 3345 [EAP-SIM], and hence this specification incorporates many ideas from 3346 EAP-SIM, and many contributions from the reviewer's of EAP-SIM. 3348 The attribute format is based on the extension format of Mobile IPv4 3349 [RFC3344]. 3351 14. References 3353 14.1 Normative References 3355 [TS 33.102] 3356 3rd Generation Partnership Project, "3GPP Technical 3357 Specification 3GPP TS 33.102 V5.1.0: "Technical 3358 Specification Group Services and System Aspects; 3G 3359 Security; Security Architecture (Release 5)"", December 3360 2002. 3362 [S.S0055-A] 3363 3rd Generation Partnership Project 2, "3GPP2 Enhanced 3364 Cryptographic Algorithms", September 2003. 3366 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 3367 RFC 2486, January 1999. 3369 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 3370 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3371 3748, June 2004. 3373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3374 Requirement Levels", BCP 14, RFC 2119, March 1997. 3376 [TS 23.003] 3377 3rd Generation Partnership Project, "3GPP Technical 3378 Specification 3GPP TS 23.003 V5.5.1: "3rd Generation 3379 Parnership Project; Technical Specification Group Core 3380 Network; Numbering, addressing and identification (Release 3381 5)"", January 2003. 3383 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 3384 Keyed-Hashing for Message Authentication", RFC 2104, 3385 February 1997. 3387 [AES] National Institute of Standards and Technology, "Federal 3388 Information Processing Standards (FIPS) Publication 197, 3389 "Advanced Encryption Standard (AES)"", November 2001. 3391 http://csrc.nist.gov/publications/fips/fips197/fips-197.pd 3392 f 3394 [CBC] National Institute of Standards and Technology, "NIST 3395 Special Publication 800-38A, "Recommendation for Block 3396 Cipher Modes of Operation - Methods and Techniques"", 3397 December 2001. 3399 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-3 3400 8a.pdf 3402 [SHA-1] National Institute of Standards and Technology, U.S. 3403 Department of Commerce, "Federal Information Processing 3404 Standard (FIPS) Publication 180-1, "Secure Hash 3405 Standard"", April 1995. 3407 [PRF] National Institute of Standards and Technology, "Federal 3408 Information Processing Standards (FIPS) Publication 186-2 3409 (with change notice); Digital Signature Standard (DSS)", 3410 January 2000. 3412 Available on-line at: 3413 http://csrc.nist.gov/publications/fips/fips186-2/fips186-2 3414 -change1.pdf 3416 [TS 33.105] 3417 3rd Generation Partnership Project, "3GPP Technical 3418 Specification 3GPP TS 33.105 4.1.0: "Technical 3419 Specification Group Services and System Aspects; 3G 3420 Security; Cryptographic Algorithm Requirements (Release 3421 4)"", June 2001. 3423 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 3424 10646", RFC 2279, January 1998. 3426 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3427 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3428 October 1998. 3430 14.2 Informative References 3432 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 3433 RFC 2548, March 1999. 3435 [PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H. 3436 and S. Josefsson, "Protected EAP Protocol (PEAP) Version 3437 2", draft-josefsson-pppext-eap-tls-eap-09 (work in 3438 progress), October 2004. 3440 [PEAP-02] Anderson, H., Josefsson, S., Zorn, G., Simon, D. and A. 3441 Palekar, "Protected EAP Protocol (PEAP)", 3442 draft-josefsson-pppext-eap-tls-eap-02 (work in progress), 3443 February 2002. 3445 [EAP Keying] 3446 Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. 3447 Levkowetz, "Extensible Authentication Protocol (EAP) Key 3448 Management Framework", draft-ietf-eap-keying-04 (work in 3449 progress), November 2004. 3451 [Service Identity] 3452 Arkko, J. and P. Eronen, "Authenticated Service 3453 Information for the Extensible Authentication Protocol 3454 (EAP)", draft-arkko-service-identity-auth-01 (work in 3455 progress), October 2004. 3457 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 3458 Recommendations for Security", RFC 1750, December 1994. 3460 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 3461 August 2002. 3463 [EAP-SIM] Haverinen, H. and J. Salowey, "Extensible Authentication 3464 Protocol Method for GSM Subscriber Identity Modules 3465 (EAP-SIM)", draft-haverinen-pppext-eap-sim-15 (work in 3466 progress), November 2004. 3468 [Draft 3GPP TS 23.003] 3469 3rd Generation Partnership Project, "Draft 3GPP Technical 3470 Specification 3GPP TS 23.003 V 6.1.0: "3rd Generation 3471 Partnership Project; Technical Specification Group Core 3472 Network; Numbering, addressing and identification (Release 3473 6)", December 2003. 3475 work in progress 3477 Authors' Addresses 3479 Jari Arkko 3480 Ericsson 3481 FIN-02420 Jorvas 3482 Finland 3484 Phone: +358 40 5079256 3485 EMail: jari.Arkko@ericsson.com 3487 Henry Haverinen 3488 Nokia Enterprise Solutions 3489 P.O. Box 12 3490 FIN-40101 Jyvaskyla 3491 Finland 3493 EMail: henry.haverinen@nokia.com 3495 Appendix A. Pseudo-Random Number Generator 3497 The "|" character denotes concatenation, and "^" denotes 3498 exponentiation. 3500 Step 1: Choose a new, secret value for the seed-key, XKEY 3502 Step 2: In hexadecimal notation let 3503 t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 3504 This is the initial value for H0|H1|H2|H3|H4 3505 in the FIPS SHS [SHA-1] 3507 Step 3: For j = 0 to m - 1 do 3508 3.1 XSEED_j = 0 /* no optional user input */ 3509 3.2 For i = 0 to 1 do 3510 a. XVAL = (XKEY + XSEED_j) mod 2^b 3511 b. w_i = G(t, XVAL) 3512 c. XKEY = (1 + XKEY + w_i) mod 2^b 3513 3.3 x_j = w_0|w_1 3515 Intellectual Property Statement 3517 The IETF takes no position regarding the validity or scope of any 3518 Intellectual Property Rights or other rights that might be claimed to 3519 pertain to the implementation or use of the technology described in 3520 this document or the extent to which any license under such rights 3521 might or might not be available; nor does it represent that it has 3522 made any independent effort to identify any such rights. Information 3523 on the procedures with respect to rights in RFC documents can be 3524 found in BCP 78 and BCP 79. 3526 Copies of IPR disclosures made to the IETF Secretariat and any 3527 assurances of licenses to be made available, or the result of an 3528 attempt made to obtain a general license or permission for the use of 3529 such proprietary rights by implementers or users of this 3530 specification can be obtained from the IETF on-line IPR repository at 3531 http://www.ietf.org/ipr. 3533 The IETF invites any interested party to bring to its attention any 3534 copyrights, patents or patent applications, or other proprietary 3535 rights that may cover technology that may be required to implement 3536 this standard. Please address the information to the IETF at 3537 ietf-ipr@ietf.org. 3539 The IETF has been notified of intellectual property rights claimed in 3540 regard to some or all of the specification contained in this 3541 document. For more information consult the online list of claimed 3542 rights. 3544 Disclaimer of Validity 3546 This document and the information contained herein are provided on an 3547 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3548 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3549 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3550 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3551 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3552 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3554 Copyright Statement 3556 Copyright (C) The Internet Society (2004). This document is subject 3557 to the rights, licenses and restrictions contained in BCP 78, and 3558 except as set forth therein, the authors retain all their rights. 3560 Acknowledgment 3562 Funding for the RFC Editor function is currently provided by the 3563 Internet Society.