idnits 2.17.1 draft-vanderveen-eap-sake-02.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1942. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1919. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1932. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 41 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 2006) is 6549 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE802.11i' is mentioned on line 622, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBC' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Obsolete informational reference (is this intentional?): RFC 4282 (ref. 'NAI') (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M. Vanderveen 3 H. Soliman 4 Expires: November 2006 Qualcomm Flarion Technologies 5 May 2006 7 Extensible Authentication Protocol Method for 8 Shared-secret Authentication and Key Establishment (EAP-SAKE) 10 Status of this memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document specifies an Extensible Authentication Protocol (EAP) 35 mechanism for shared-secret authentication and key establishment 36 (SAKE). 38 Table of Contents 40 1. Introduction.....................................................3 41 2. Terminology......................................................3 42 3. Protocol Description.............................................3 43 3.1. Overview and Motivation of EAP-SAKE.........................3 44 3.2. Protocol Operation..........................................4 45 3.2.1. Successful Exchange....................................4 46 3.2.2. Authentication Failure.................................7 47 3.2.3. Identity Management....................................9 48 3.2.4. Obtaining Peer Identity...............................10 49 3.2.5. Key Hierarchy.........................................12 50 3.2.6. Key Derivation........................................13 51 3.2.7. Ciphersuite Negotiation...............................14 52 3.2.8. Message Integrity and Encryption......................15 53 3.2.9. Fragmentation.........................................18 54 3.2.10. Error Cases..........................................18 55 3.3. Message Formats............................................19 56 3.3.1. Message Format Summary................................19 57 3.3.2. Attribute Format......................................21 58 3.3.3. Use of AT_ENCR_DATA Attribute.........................22 59 3.3.4. EAP.Request/SAKE/Challenge Format.....................22 60 3.3.5. EAP.Response/SAKE/Challenge Format....................24 61 3.3.6. EAP.Request/SAKE/Confirm Format.......................26 62 3.3.7. EAP.Response/SAKE/Confirm Format......................28 63 3.3.8. EAP.Response/SAKE/Auth-Reject Format..................29 64 3.3.9. EAP.Request/SAKE/Identity Format......................30 65 3.3.10. EAP.Response/SAKE/Identity Format....................31 66 3.3.11. Other EAP Messages Format............................32 67 4. IANA Considerations.............................................33 68 5. Security Considerations.........................................33 69 5.1. Denial-of-service Attacks..................................33 70 5.2. Root Secret Considerations.................................34 71 5.3. Mutual Authentication......................................34 72 5.4. Integrity Protection.......................................34 73 5.5. Replay Protection..........................................35 74 5.6. Confidentiality............................................35 75 5.7. Key Derivation, Strength...................................36 76 5.8. Dictionary Attacks.........................................36 77 5.9. Man-in-the-middle Attacks..................................36 78 5.10. Result Indication Protection..............................36 79 5.11. Cryptographic Separation of Keys..........................36 80 5.12. Session Independence......................................36 81 5.13. Identity Protection.......................................37 82 5.14. Channel Binding...........................................37 83 5.15. Negotiation Attacks.......................................37 84 5.16. Random Number Generation..................................38 85 6. Security Claims.................................................38 86 7. Acknowledgements................................................39 87 8. References......................................................39 88 8.1. Normative References.......................................39 89 8.2. Informative References.....................................40 91 1. Introduction 93 The Extensible Authentication Protocol (EAP), described in [EAP], 94 provides a standard mechanism for support of multiple authentication 95 methods. EAP is also used within IEEE 802 networks through the IEEE 96 802.11i [IEEE802.11i] framework. 98 EAP supports several authentication schemes, including smart cards, 99 Kerberos, Public Key, One Time Passwords, TLS, and others. This 100 document defines an authentication scheme, called the EAP-SAKE. 101 EAP-SAKE supports mutual authentication and session key derivation, 102 based on a static pre-shared secret data. 104 2. Terminology 106 In this document, several words are used to signify the requirements 107 of the specification. These words are often capitalized. The key 108 words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", "SHOULD", 109 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 110 are to be interpreted as described in BCP 14 [KEYWORDS]. 112 In addition to the terms used in [EAP], this document frequently uses 113 the following terms and abbreviations: 115 MIC 116 Message Integrity Check 118 SMS 119 SAKE Master Secret 121 NAI 122 Network Access Identifier 124 3. Protocol Description 126 3.1. Overview and Motivation of EAP-SAKE 128 The EAP-SAKE authentication protocol is a native EAP authentication 129 method. That is, a stand-alone version of EAP-SAKE outside of EAP is 130 not defined. EAP-SAKE is designed to enable mutual authentication, 131 based on pre-shared keys and well-known public cryptographic 132 algorithms. This method is ideal for subscription-based public access 133 networks, e.g. cellular networks. 135 EAP-SAKE assumes a long-term or pre-shared secret known only to the 136 Peer and the Server. This pre-shared secret is called the Root 137 Secret. The Root Secret consists of a 16-byte part Root-Secret-A, and 138 16-byte part Root-Secret-B. The Root-Secret-A secret is reserved for 139 use local to the EAP-SAKE method, i.e. to mutually authenticate the 140 EAP Peer and EAP Server. The Root-Secret-B secret is used to derive 141 other quantities such as the Master Session Key (MSK) and Extended 142 Master Session Key (EMSK). Root-Secret-B and Root-Secret-A MUST be 143 cryptographically separate. 145 When a Backend Authentication Server is used, the Server typically 146 communicates with the Authenticator using an AAA protocol. The AAA 147 communications are outside the scope of this draft. 149 Some of the advantages of EAP-SAKE consist of: 151 o based on well-established Bellare-Rogaway mutual authentication 152 protocol. 153 o supports key derivation for local EAP method use and for export 154 to other third parties to use them independently of EAP. 155 o employs only two request/response exchanges. 156 o relies on the (corrected) IEEE 802.11i function for key 157 derivation and message integrity. This way a device implementing a 158 lower-layer secure association protocol compliant with IEEE 802.11i 159 standard will not need additional cryptographic code. 160 o encryption algorithm is securely negotiated (with no extra 161 messages), yet encryption use is optional. 162 o keys used for authentication and those used for encryption are 163 cryptographically separate. 164 o user identity anonymity can be optionally supported. 165 o no synchronization (e.g. of counters) needed between server and 166 peer. 167 o no one-time key pre-processing step. 169 3.2. Protocol Operation 171 EAP-SAKE uses four messages consisting of two EAP request/response 172 exchanges. The EAP.Success and EAP.Failure messages shown in the 173 figures are not part of the EAP-SAKE method. As a convention, method 174 attributes are named AT_XX, where XX is the name of the parameter the 175 attribute value is set to. 177 3.2.1. Successful Exchange 179 A successful EAP-SAKE authentication exchange is depicted in 180 Figure 1. The following steps take place: 182 Peer Server 183 | | 184 | EAP.Request/SAKE/Challenge | 185 | (AT_RAND_S, AT_SERVERID) | 186 1 |<---------------------------------------------------------| 187 | | 188 | EAP.Response/SAKE/Challenge | 189 | (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) | 190 2 |--------------------------------------------------------->| 191 | | 192 | EAP.Request/SAKE/Confirm | 193 | (AT_SPI_S, AT_ENCR_DATA, AT_MIC_S)| 194 3 |<---------------------------------------------------------| 195 | | 196 | EAP.Response/SAKE/Confirm | 197 | (AT_MIC_P) | 198 4 |--------------------------------------------------------->| 199 | | 200 | | 201 | EAP-Success | 202 5 |<---------------------------------------------------------| 203 | | 205 Figure 1. EAP-SAKE authentication procedure (with ciphersuite 206 negotiation). 208 1. The EAP server sends the first message of the EAP-SAKE 209 exchange. This message is an EAP.Request message of type SAKE 210 and subtype Challenge. The EAP.Request/SAKE/Challenge message 211 contains the attributes: AT_RAND_S, whose value is a nonce 212 freshly generated by the Server; and AT_SERVERID, which carries 213 an identifier of the Server (a fully-qualified domain name, 214 such as the realm of the user NAI [NAI]). The AT_SERVERID 215 attribute is OPTIONAL but SHOULD be included in this message. 216 The purpose of the AT_SERVERID is to aid the Peer in selecting 217 the correct security association (i.e., Root-Secret, PEERID and 218 SERVERID) to use during this EAP phase. 220 2. The Peer responds by sending an EAP.Response message of type 221 SAKE and subtype Challenge. The EAP.Response/SAKE/Challenge 222 message contains the attributes: AT_RAND_P, which carries a 223 nonce freshly generated by the Peer; AT_PEERID, which carries a 224 Peer identifier; AT_SPI_P, which carries a list of one or more 225 ciphersuites supported by the Peer; and AT_MIC_P, containing a 226 message integrity check. The AT_SPI_P and AT_PEERID attributes 227 are OPTIONAL. The AT_PEERID attribute SHOULD be included, in 228 order to cover the case of multi-homed hosts. A supported 229 ciphersuite is represented by a value local to the EAP-SAKE 230 method, or "Security Parameter Index", see section 3.2.8.3. The 231 Peer uses both nonces, along with the Root-Secret-A key, to 232 derive a SAKE Master Secret (SMS) and Temporary EAP Keys 233 (TEKs), which also include the TEK-Auth and TEK-Cipher keys. 234 The MIC_P value is computed based on both nonces RAND_S and 235 RAND_P and the entire EAP packet, using the key TEK-Auth, see 236 section 3.2.6. 238 3. Upon receipt of the EAP.Response/SAKE/Challenge message, the 239 Server uses both nonces RAND_S and RAND_P, along with the Root- 240 Secret-A key, to compute the SMS and TEK in exactly the same 241 way the Peer did. Following that, the Server computes the 242 Peer's MIC_P in exactly the same way the Peer did. 243 The Server then compares the computed MIC_P with the MIC_P it 244 received from the Peer. If they match, the Server considers the 245 Peer authenticated. If encryption is needed, the Server selects 246 the strongest ciphersuite from the Peer's ciphersuite list 247 SPI_P, or a suitable ciphersuite if the Peer did not include 248 the AT_SPI_P attribute. The Server sends an EAP. Request 249 message of type SAKE and subtype Confirm, containing the 250 attributes: AT_SPI_S, carrying the ciphersuite chosen by the 251 Server; AT_ENCR_DATA, containing encrypted data; and AT_MIC_S, 252 carrying a message integrity check. The AT_SPI_S and 253 AT_ENCR_DATA are OPTIONAL attributes, included if 254 confidentiality and/or user identity anonymity is desired. 255 Other OPTIONAL attributes that MAY be included are 256 AT_NEXT_TMPID, AT_MSK_LIFE. As before, the MIC_S value is 257 computed using both nonces RAND_S and RAND_P and the entire EAP 258 packet, using the key TEK-Auth. 260 4. If the Peer receives the EAP.Request/SAKE/Confirm message 261 indicating successful authentication by the Server, the Peer 262 computes the MIC_S in the same manner as the Server did. The 263 Peer then compares the received MIC_S with the MIC_S it 264 computed. If they match, the Peer considers the Server 265 authenticated, and it sends an EAP.Response message of type 266 SAKE and subtype Confirm, with the attribute AT_MIC_P 267 containing a message integrity check, computed in the same 268 manner as before. 270 5. After a successful EAP-SAKE exchange, the Server 271 concludes the EAP conversation by sending an EAP.Success 272 message to the Peer. 274 All EAP-SAKE messages contain a Session ID, which is chosen by the 275 Server and sent in the first message, and replicated in subsequent 276 messages until an EAP.Success or EAP.Failure is sent. Upon receipt of 277 an EAP-SAKE message, both Peer and Server MUST check the format of 278 the message to ensure it is both well-formed and contains a valid 279 Session ID. 281 Note that the Session ID is introduced mainly for replay protection 282 purposes, as it helps to uniquely identifies a session between a Peer 283 and a Server. In most cases, there is a one-to-one relationship 284 between the Session ID and the Peer/Server pair. 286 The parameters used by the EAP-SAKE method are summarized in the 287 table below: 289 Name Length(bytes) Description 290 ---------+---------------+------------- 291 RAND_P 16 Peer nonce 292 RAND_S 16 Server nonce 293 MIC_P 16 Peer MIC 294 MIC_S 16 Server MIC 295 SPI_P variable Peer ciphersuite preference(s) 296 SPI_S variable Server chosen ciphersuite 297 PEERID variable Peer identifier 298 SERVERID variable Server identifier (FQDN) 300 3.2.2. Authentication Failure 302 If the Authenticator receives an EAP Failure message from the Server, 303 the Authenticator MUST terminate the connection with the Peer 304 immediately. 306 The Server considers the Peer to have failed authentication if 307 either of the two received MIC_P values does not match the 308 computed MIC_P. 310 The Server SHOULD deny authorization for a Peer that does not 311 advertise any of the ciphersuites that are considered acceptable 312 (e.g. by local system policy), and send an EAP.Failure message. 314 In case of authentication failure, the Server MUST send an 315 EAP.Failure message to the Peer as in Figure 2. The following steps 316 take place: 318 Peer Server 319 | | 320 | EAP.Request/SAKE/Challenge | 321 | (AT_RAND_S, AT_SERVERID) | 322 1 |<---------------------------------------------------------| 323 | | 324 | EAP.Response/SAKE/Challenge | 325 | (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) | 326 2 |--------------------------------------------------------->| 327 | | 328 | +-------------------------------------------+ 329 | | Server finds MIC_P invalid. | 330 | +-------------------------------------------+ 331 | | 332 | EAP-Failure | 333 3 |<---------------------------------------------------------| 334 Figure 2. EAP-SAKE authentication procedure, Peer fails 335 authentication. 337 1. As in step 1 of Figure 1. 338 2. As in step 2 of Figure 2. 339 3. Upon receipt of the EAP.Response/SAKE/Challenge message, the 340 Server uses both nonces RAND_S and RAND_P, along with the Root- 341 Secret-A key, to compute the SMS and TEK in exactly the same way 342 the Peer did. Following that, the Server computes the Peer's 343 MIC in exactly the same way the Peer did. The Server 344 then compares the computed MIC_P with the MIC_P it received from 345 the Peer. Since they do not match, the Server considers the Peer 346 to have failed authentication, and sends an EAP.Failure message 347 back to the Peer. 349 If the AT_SPI_S attribute does not contain one of the SPI values that 350 the Peer listed in the previous message, or if the Peer did not 351 include an AT_SPI_P attribute and yet it does not accept the 352 ciphersuite the Server has chosen, then the Peer SHOULD silently 353 discard this message. Alternatively, the Peer MAY send a SAKE/Auth- 354 Reject message back to the Server; in response to this message, the 355 Server MUST send an EAP.Failure message to the Peer. 357 The AT_SPI_S attribute MUST be included if encryption is to be used. 358 The Server knows whether encryption is to be used or not, as it is 359 usually the Server that needs to protect some data intended for the 360 Peer (e.g. temporary ID, group keys, etc). If the Peer receives an 361 AT_SPI_S attribute and yet there is no AT_ENCR_DATA attribute, the 362 Peer SHOULD process the message and skip the AT_SPI_S attribute. 364 The Peer considers the Server to have failed authentication if 365 the received and the computed MIC_S values do not match. In this 366 case, the Peer MUST send to the Server an EAP.Response message of 367 type SAKE and subtype Auth-Reject, indicating an authentication 368 failure. In this case the Server MUST send an EAP.Failure message 369 to the Peer as in Figure 3. The following steps take place: 371 Peer Server 372 | | 373 | EAP.Request/SAKE/Challenge | 374 | (AT_RAND_S, AT_SERVERID) | 375 1 |<---------------------------------------------------------| 376 | | 377 | EAP.Response/SAKE/Challenge | 378 | (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) | 379 2 |--------------------------------------------------------->| 380 | | 381 | EAP.Request/SAKE/Confirm | 382 | (AT_SPI_S, AT_ENCR_DATA, AT_MIC_S)| 383 3 |<---------------------------------------------------------| 384 | | 385 +-----------------------------------------------+ | 386 | Peer finds MIC_S invalid. | | 387 +-----------------------------------------------+ | 388 | | 389 | EAP.Response/SAKE/Auth-Reject | 390 4 |--------------------------------------------------------->| 391 | | 392 | EAP-Failure | 393 5 |<---------------------------------------------------------| 394 | | 396 Figure 3. EAP-SAKE authentication procedure, Server fails 397 authentication. 399 1. As in step 1 of Figure 1. 400 2. As in step 2 of Figure 1. 401 3. As in step 3 of Figure 1. 402 4. The Peer receives a EAP.Request/SAKE/Confirm message indicating 403 successful authentication by the Server. The Peer computes the 404 MIC_S in the same manner as the Server did. The Peer then compares 405 the received MIC_S with the MIC_S it computed. Since they do not 406 match, the Peer considers the Server to have failed 407 authentication. In this case the Peer responds with an 408 EAP.Response message of type SAKE and subtype Auth-Reject, 409 indicating authentication failure. 410 5. Upon receipt of a EAP.Response/SAKE/Auth-Reject message, the 411 Server sends an EAP.Failure message back to the Peer. 413 3.2.3. Identity Management 415 It may be advisable to assign a temporary identifier (TempID) to a 416 Peer when user anonymity is desired. The TempID is delivered to the 417 Peer in the EAP.Request/SAKE/Confirm message. The TempID follows the 418 format any NAI [NAI] and is generated by the EAP Server that engages 419 in the EAP-SAKE authentication task with the Peer. EAP servers SHOULD 420 be configurable with TempID spaces that can be distinguished from the 421 permanent identity space. For instance, a specific realm could be 422 assigned for TempIDs (e.g. tmp.example.biz). 424 A TempID is not assigned an explicit lifetime. The TempID is valid 425 until the Server requests the permanent identifier, or the Peer 426 triggers the start of a new EAP session by sending in its permanent 427 identifier. A Peer MUST be able to trigger an EAP session at any time 428 using its permanent identifier. A new TempID assigned during a 429 successful EAP session MUST replace the existing TempID for future 430 transactions between the Peer and the Server. 432 Note that the delivery of a TempID does not imply that the Server 433 considers the Peer authenticated; the Server still has to check the 434 MIC in the EAP.Response/SAKE/Confirm message. In case the EAP phase 435 ends with an EAP.Failure message, then the Server and the Peer MUST 436 consider the TempID that was just delivered as invalid. Hence, the 437 Peer MUST NOT use this TempID next time it tries to authenticate with 438 the Server. 440 3.2.4. Obtaining Peer Identity 442 The types of identities that a Peer may possess are permanent and 443 temporary identities, referred to as PermID and TempID, respectively. 444 A PermID can be an NAI associated with the Root Secret, and is long- 445 lived. A TempID is an identifier generated through the EAP method and 446 that the Peer can use to identify itself during subsequent EAP 447 sessions with the Server. The purpose of the TempID is to allow for 448 user anonymity support. The use of TempIDs is optional in the EAP- 449 SAKE method. 451 The Server MAY request the Peer ID via the EAP.Request/SAKE/Identity 452 message, as shown in Figure 4. This case may happen if, for example, 453 the Server wishes to initiate an EAP-SAKE session for a Peer it does 454 not have a subscriber identifier for. The following steps take place: 456 Peer Server 457 | | 458 | +---------------------------------+ 459 | | Server wishes to initiate | 460 | | an EAP-SAKE session | 461 | | | 462 | +---------------------------------+ 463 | | 464 | EAP.Request/SAKE/Identity | 465 | (AT_ANY_ID_REQ, AT_SERVERID) | 466 1 |<---------------------------------------------------------| 467 | | 468 | EAP.Response/SAKE/Identity | 469 | (AT_PEERID) | 470 2 |--------------------------------------------------------->| 471 | | 472 +--------------------------------------------------------------+ 473 | If identity found, normal EAP-SAKE authentication follows. | 474 +--------------------------------------------------------------+ 476 Figure 4: Server requests Peer identity. 478 1. The Server sends an EAP.Request message of type SAKE and subtype 479 Identity, with the attribute AT_ANY_ID_REQ, indicating a request 480 for any Peer identifier. 481 2. The Peer constructs an EAP.Response message of type SAKE and 482 subtype Identity, with the attribute AT_PEER_ID containing any 483 Peer identifier (PermID or TempID). 485 If the Server cannot find the Peer identity reported in the 486 EAP.Response/SAKE/Identity message, or it does not recognize the 487 format of the Peer identifier, the Server MAY send an EAP.Failure 488 message to the Peer. 490 If the Server is unable to look up a Peer by its TempID, or if policy 491 dictates that the Peer should now use its permanent id, then the 492 Server may specifically ask for the permanent identifier, as in 493 Figure 5. The following steps occur: 495 Peer Server 496 | | 497 | +---------------------------------+ 498 1 | | Server obtains TempID but | 499 | | requires PermID | 500 | +---------------------------------+ 501 | | 502 | EAP.Request/SAKE/Identity | 503 | (AT_PERM_ID_REQ, AT_SERVERID) | 504 2 |<---------------------------------------------------------| 505 | | 506 | EAP.Response/SAKE/Identity | 507 | (AT_PEERID) | 508 3 |--------------------------------------------------------->| 509 | | 510 | +---------------------------------+ 511 | | Server finds and uses | 512 | | Peer PermID to start a | 513 | | EAP-SAKE authentication phase | 514 | +---------------------------------+ 515 | 516 +---------------------------------------------------------------+ 517 | Normal EAP-SAKE authentication follows. | 518 +---------------------------------------------------------------+ 520 Figure 5. Server is given a TempID as Peer Identity. Server 521 requires a PermID. 523 1. The Peer (or the Authenticator on behalf of the Peer) sends an 524 EAP.Request message of type Identity and includes the TempID. 525 2. The Server requires a PermID instead, so it sends an 526 EAP.Request message of type SAKE and subtype Identity with 527 attributes AT_PERM_ID_REQ and AT_SERVERID. 529 3. The Peer sends an EAP.Response message of type SAKE and subtype 530 Identity containing the attribute AT_PEERID carrying the Peer 531 PermID. 533 3.2.5. Key Hierarchy 535 EAP-SAKE uses a three-level key hierarchy. 537 Level 1 contains the pre-shared secret called Root Secret. This is a 538 32-byte high-entropy string partitioned into the Root-Secret-A part 539 (16 bytes) and the Root-Secret-B part (16 bytes). 541 Level 2 contains the key derivation key called the SAKE Master Secret 542 (SMS). SMS-A is derived from the Root-Secret-A key and the Peer and 543 Server nonces using the EAP-SAKE Key-Derivation Function (KDF), and 544 similarly for SMS-B. The SMS is known only to the Peer and Server, 545 and is not made known to other parties. 547 Level 3 contains session keys, such as Transient EAP Keys (TEK), 548 Master Session Key (MSK) and Extended MSK (EMSK). TEKs are keys for 549 use local to the EAP method only. They are derived from the SMS-A and 550 the nonces using the EAP-SAKE KDF. They are partitioned into a 16- 551 byte TEK-Auth, used to compute the MICs, and a 16-byte TEK-Cipher, 552 used to encrypt selected attributes. Since the SMS is fresh, so are 553 the derived TEKs. 555 +--------------------+ +--------------------+ 556 | Root-Secret-A | | Root-Secret-B | 557 | (pre-shared secret)| | (pre-shared secret)| 558 +--------------------+ +--------------------+ 559 | | 560 V V 561 +-------------------+ +--------------------+ 562 | SAKE Master Secret|<---RAND_S------------->| SAKE Master Secret | 563 | (SMS-A) | | | (SMS-B) | 564 | |<-------]---RAND_P----->| | 565 +-------------------+ | | +--------------------+ 566 | | | | 567 V | | V 568 +--------------------+ | | +--------------------+ 569 | Transient EAP Keys |<------+-----+-------->| Session Keys: | 570 | TEK-Auth,TEK-Cipher|<------------+-------->| MSK, EMSK | 571 +--------------------+ +--------------------+ 573 Figure 6. Key hierarchy for the EAP-SAKE method. 575 On another branch of level 3 of the key hierarchy are the MSK and 576 EMSK, each mandated to be 64 bytes long. They are derived from the 577 SMS-B and the nonces using the EAP-SAKE KDF. Again, since the SMS is 578 fresh, so are the derived MSK/EMSK. The MSK is meant to be exported 579 and relayed to other parties. The EMSK is reserved for future use, 580 such as derivation of application-specific keys, and is not shared 581 with other parties. 583 The EAP-SAKE key material is summarized in the table below. 585 =================================================================== 586 Key Size Scope Lifetime Use 587 (bytes) 588 =================================================================== 589 Root-Secret-A 16 Peer, Server Device Derive TEK 590 -------------------------------------------------------------------- 591 Root-Secret-B 16 Peer, Server Device Derive MSK, EMSK 592 -------------------------------------------------------------------- 593 TEK-Auth 16 Peer, Server MSK Life Compute MICs 594 -------------------------------------------------------------------- 595 TEK-Cipher 16 Peer, Server MSK Life Encrypt attribute 596 -------------------------------------------------------------------- 597 MSK 64 Peer, Server, MSK Life Derive keys for 598 Authenticator lower-layer use 599 -------------------------------------------------------------------- 600 EMSK 64 Peer, Server MSK Life Reserved 601 -------------------------------------------------------------------- 603 A key name format is not provided in this version. 605 Since this version of EAP-SAKE does not support fast re- 606 authentication, the lifetime of the TEKs is to extend only until the 607 next EAP mutual authentication. The MSK lifetime dictates when the 608 next mutual authentication is to take place. The Server MAY convey 609 the MSK lifetime to the Peer in the AT_MSK_LIFE attribute. Note that 610 EAP-SAKE does not support key lifetime negotiation. 612 The EAP-SAKE Method-Id is the contents of the RAND_S field from the 613 AT_RAND_S attribute, followed by the contents of the RAND_P field in 614 the AT_RAND_P attribute. 616 3.2.6. Key Derivation 618 3.2.6.1. Key-Derivation Function 620 For the rest of this document, KDF-X denotes the EAP-SAKE Key- 621 Derivation Function whose output is X bytes. This function is 622 the pseudo-random function of [IEEE802.11i]. 624 The function takes three strings of bytes of arbitrary lengths: a 625 Key, a Label, and a Msg, and outputs a string Out of length X 626 bytes as follows: 628 Out = KDF-X (Key, Label, Msg) 629 The KDF is a keyed hash function with key "Key" and operating on 630 input "Label | Msg". The convention followed herein is that 631 concatenation is denoted by |, FLOOR denotes the floor function 632 and [x...y] denotes bytes x through y. 633 The label is an ASCII character string. It is included in the exact 634 form it is given without a length byte or trailing null character. 636 Below, "Length" denotes a single unsigned octet with values between 0 637 and 255 (bytes). The following functions are defined (see [HMAC], 638 [SHA1]): 640 H-SHA1(Key, Label, Msg, Length) := HMAC-SHA1(Key, Label|Y|Msg|Length) 641 where Y := 0x00 642 KDF-16(Key, Label, Msg) := KDF(Key, Label, Msg, 16) 643 KDF-32(Key, Label, Msg) := KDF(Key, Label, Msg, 32) 644 KDF-128(Key, Label, Msg) := KDF(Key, Label, Msg, 128) 646 KDF(Key, Label, Msg, Length) 647 R := [] ;; null string 648 for i := 0 to FLOOR(Length/20)-1 do 649 R := R | H-SHA1(Key, Label, Msg, i) 650 return R[0...(Length-1)] 652 3.2.6.2. Transient EAP Keys Derivation 654 The Peer and Server derive the SMS and then the TEK as follows: 656 SMS-A = KDF-16 (Root-Secret-A, "SAKE Master Secret A", RAND_P|RAND_S) 657 TEK = KDF-32 (SMS-A, "Transient EAP Key", RAND_S | RAND_P) 658 TEK-Auth = TEK[0...15] 659 TEK-Cipher = TEK[16...31] 661 3.2.6.3. Extended/Master Session Key Derivation 663 The Peer and the Server derive the MSK/EMSK, as follows: 665 SMS-B = KDF-16 (Root-Secret-B, "SAKE Master Secret B", RAND_P|RAND_S) 666 Session-Key-Block=KDF-128(SMS-B, "Master Session Key", RAND_S|RAND_P) 667 MSK = Session-Key-Block[0...63] 668 EMSK = Session-Key-Block[64...127] 670 The derivation above affords the required cryptographic separation 671 between the MSK and EMSK. That is, knowledge of the EMSK does not 672 immediately lead to knowledge of the MSK, nor does knowledge of the 673 MSK immediately lead to knowledge of the EMSK. 675 3.2.7. Ciphersuite Negotiation 677 A ciphersuite is identified by a numeric value called the Security 678 Parameter Index (SPI). The SPI is used here in the EAP-SAKE method in 679 order to negotiate a ciphersuite between the Peer and the Server for 680 EAP data protection only. Obviously, this ciphersuite can only be 681 used late in the EAP conversation, after it has been agreed upon by 682 both the Peer and the Server. 684 The EAP method may or may not need to use this ciphersuite, since 685 attribute encryption is optional. For example, if the temporary 686 identifier needs to be delivered to the Peer and needs to be 687 encrypted, then the negotiated ciphersuite will be used for this 688 task. If there are no attributes that need encryption as they are 689 passed to the Peer, then this ciphersuite is never used. 691 As with most other methods employing ciphersuite negotiation, the 692 following exchange is employed: the Peer sends an ordered list of one 693 or more supported ciphersuites, starting with the most preferred one, 694 in a field SPI_P. The Server then sends back the one ciphersuite 695 chosen in a field SPI_S. The Server SHOULD choose the strongest 696 ciphersuite supported by both of them. 698 Ciphersuite negotiation for data protection is achieved via SAKE 699 Signaling as follows. In the EAP.Response/SAKE/Challenge the 700 Peer sends a list of supported ciphersuites, SPI_P, and protects that 701 with a MIC. In the EAP.Request/SAKE/Confirm, the Server sends one 702 selected ciphersuite, SPI_S, and signs that with a MIC. Finally, the 703 Peer confirms the selected ciphersuite and readiness to use it in a 704 signed EAP.Response/SAKE/Confirm message. The negotiation is secure 705 because of the Message Integrity Checks that cover the entire EAP 706 message. 708 3.2.8. Message Integrity and Encryption 710 This section specifies the EAP/SAKE attributes used for message 711 integrity and attribute encryption: AT_MIC_S, AT_MIC_P, AT_IV, 712 AT_ENCR_DATA and AT_PADDING. Only the AT_MIC_S and AT_MIC_P are 713 mandatory to use during the EAP-SAKE exchange. 715 Because the TEKs necessary for protection of the attributes and for 716 message authentication are derived using the nonces RAND_S and 717 RAND_P, the AT_MIC_S and AT_MIC_P attributes can only be used in the 718 EAP.Response/SAKE/Challenge message and any messages sent thereafter. 720 3.2.8.1. The AT_MIC_S and AT_MIC_P Attributes 722 The AT_MIC_S and AT_MIC_P attributes are used for EAP-SAKE message 723 integrity. The AT_MIC_S attribute MUST be included in all EAP-SAKE 724 packets that the Server sends whenever key material (TEK) has been 725 derived. That is, the AT_MIC_S attribute MUST be included in the 726 EAP.Request/SAKE/Confirm message. The AT_MIC_S MUST NOT be included 727 in EAP.Request/SAKE/Challenge messages, or EAP.Request/SAKE/Identity 728 messages. 730 The AT_MIC_P attribute MUST be included in all EAP-SAKE packets the 731 Peer sends whenever key material (TEK) has been derived. That is, the 732 AT_MIC_P attribute MUST be included in the 733 EAP.Response/SAKE/Challenge and EAP.Response/SAKE/Confirm messages. 735 The AT_MIC_P attribute MUST NOT be included in the 736 EAP.Response/SAKE/Auth-Reject message since the Peer has not 737 confirmed that it has the same TEK as the Server. 739 Messages that do not meet the conditions specified above MUST be 740 silently discarded upon reception. 742 The value field of the AT_MIC_S and AT_MIC_P attributes contain a 743 message integrity check (MIC). The MIC is calculated over the entire 744 EAP packet, prepended with the Server nonce and identifier and the 745 Peer nonce and identifier. The value field of the MIC attribute is 746 set to zero when calculating the MIC. Including the Server and Peer 747 nonces and identifiers aids in detecting replay and man-in-the-middle 748 attacks. 750 The Peer computes its MIC as follows: 752 MIC_P = KDF-16 (TEK-Auth, "Peer MIC", RAND_S | RAND_P | 753 PEERID | 0x00 | SERVERID | 0x00 | ), 755 while the Server computes its MIC as 757 MIC_S = KDF-16 (TEK-Auth, "Server MIC", RAND_P |RAND_S | 758 SERVERID | 0x00 | PEERID | 0x00 | ). 760 Here denotes the entire EAP packet, used as a string of 761 bytes, with the MIC value field set to zero. 0x00 denotes a single 762 octet value used to delimit SERVERID and PEERID. The PEERID and 763 SERVERID respectively are the ones carried in the corresponding 764 attributes in the SAKE/Challenge messages. 766 In case the SAKE/Challenge exchange was preceded by an 767 EAP.Request/SAKE/Identity message containing the AT_SERVERID 768 Attribute, then the SERVERID value in the MIC_P and MIC_S computation 769 MUST be set to the value of this attribute. 771 If the AT_SERVERID was not included in either the SAKE/Challenge 772 message or the SAKE/Identity message, then the value of the SERVERID 773 used in the computation of MIC_P and MIC_S MUST be empty. If the 774 AT_PEERID was not included in the SAKE/Challenge message, and there 775 was no EAP.Response/SAKE/Identity message preceding the SAKE/Challenge 776 messages, then the value of the PEERID used in the computation of 777 MIC_P and MIC_S MUST be empty. 779 The Server and Peer identity are included in the computation of the 780 signed responses so that the Peer and Server can verify each other's 781 identities, and the possession of a common secret, the TEK-Auth. 782 However, since the AT_SERVERID is not explicitly signed with a MIC by 783 the Server, EAP-SAKE does not claim channel binding. 785 3.2.8.2. The AT_IV, AT_ENCR_DATA and AT_PADDING Attributes 787 The AT_IV and AT_ENCR_DATA attributes can be used to transmit 788 encrypted information between the Server and the Peer. The value 789 field of AT_IV contains an initialization vector (IV) if one is 790 required by the encryption algorithm used. The AT_IV attribute is not 791 mandatory to be included whenever the AT_ENCR_DATA attribute is. 793 However, the AT_IV attribute MUST NOT be included unless the 794 AT_ENCR_DATA is included. Messages that do not meet this condition 795 MUST be silently discarded. 797 Attributes can be encrypted only after a ciphersuite has been agreed 798 on, i.e. in any message starting with the Server's 799 EAP.Request/SAKE/Confirm message. The attributes MUST be encrypted 800 using algorithms corresponding to the SPI value specified by the 801 AT_SPI_S attribute. The attributes MUST be encrypted using the TEK- 802 Cipher key, whose derivation is specified in Section 3.2.6.2. 804 If an IV is required by the encryption algorithm, then the sender of 805 the AT_IV attribute MUST NOT reuse the IV value from previous EAP- 806 SAKE packets. The sender MUST choose a new value for each AT_IV 807 attribute. The sender SHOULD use a good random number generator to 808 generate the initialization vector (see [RFC1750] for guidelines). 810 The value field of the AT_ENCR_DATA attribute consists of bytes 811 encrypted using the ciphersuite specified in the AT_SPI_S attribute. 812 The encryption key is the TEK-Cipher and the plaintext consists of 813 one or more concatenated EAP-SAKE attributes. 815 The default encryption algorithm, as described in Section 3.2.8.3, 816 requires the length of the plaintext to be a multiple of 16 bytes. 817 The sender MAY need to include the AT_PADDING attribute as the last 818 attribute within the value field of the AT_ENCR_DATA attribute. The 819 length of the padding is chosen so that the length of the value field 820 of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes. The 821 AT_PADDING attribute SHOULD NOT be included if the total length of 822 other attributes present within the AT_ENCR_DATA attribute is a 823 multiple of 16 bytes. The length of the AT_PADDING attribute includes 824 the Attribute Type and Attribute Length fields. The actual pad bytes 825 in the value field are set to zero (0x00) on sending. The recipient 826 of the message MUST verify that the pad bytes are zero after 827 decryption and MUST silently discard the message otherwise. 829 The MIC computed on the entire EAP message can be used to obviate the 830 need for special integrity protection or message authentication of 831 the encrypted attributes. 833 An example of the AT_ENCR_DATA attribute is shown in Section 3.3.3. 835 3.2.8.3. Security Parameter Index (SPI) Considerations 837 An SPI value is a variable-length string identifying at least an 838 encryption algorithm and possibly a "security association". EAP-SAKE 839 does not mandate the format of the SPI; it only mandates that the 840 default encryption algorithm be supported if encryption is supported. 841 That is, if an implementation compliant with this draft supports 842 encryption, then it MUST support the AES-CBC cipher. 844 The default encryption algorithm AES-CBC involves the AES block 845 cipher [AES] in the Cipher-Block-Chaining (CBC) mode of operation 846 [CBC]. 848 The Peer in the EAP-SAKE method can send up to four SPI values in its 849 SPI_P field. Because the length of the AT_SPI_P and AT_SPI_S 850 attributes must each be a multiple of 2 bytes, the sender pads the 851 value field with zero bytes when necessary (the AT_PADDING attribute 852 is not used here). For example, the value field of the AT_SPI_S 853 contains one byte with the chosen SPI, followed by one byte of zeros. 855 3.2.9. Fragmentation 857 The EAP-SAKE method does not require fragmentation, as the messages 858 do not get excessively long. That is, EAP packets are well within the 859 limit of the maximum transmission unit of other layers (link, 860 network). The only variable fields are those carrying NAIs, which are 861 limited by their length field to 256 bytes. 863 3.2.10. Error Cases 865 Malformed messages: As a general rule, if a Peer or Server receives 866 an EAP-SAKE packet that contains an error, the implementation SHOULD 867 silently discard this packet, not change state, nor send any EAP 868 messages to the other party. Examples of such errors include a 869 missing mandatory attribute, an attribute that is not allowed in this 870 type of message, and unrecognized subtypes or attributes. 872 Non-matching Session Id: If a Peer or Server receives an EAP-SAKE 873 packet with a Session Id field not matching the Session Id from the 874 previous packet in this session, that entity SHOULD silently discard 875 this packet (not applicable for the first message of an EAP-SAKE 876 session). 878 Peer Authorization Failure: It may be possible that a Peer is not 879 authorized for services, such as when the terminal device is reported 880 stolen. In that case, the Server SHOULD send an EAP.Failure message. 882 Unexpected EAP.Success: A Server MUST NOT send an EAP-Success message 883 before the SAKE/Challenge and SAKE/Confirm rounds. The Peer MUST 884 silently discard any EAP.Success packets before the Peer has 885 successfully authenticated the Server via the 886 EAP.Response/SAKE/Confirm packet. 888 The Peer and Server SHOULD log all error cases. 890 3.3. Message Formats 892 3.3.1. Message Format Summary 894 A summary of the EAP packet format [EAP] is shown below for 895 convenience. The fields are transmitted from left to right. 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Code | Identifier | Length | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 |Type=EAP-SAKE | Version=2 | Session ID | Subtype | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 Code 907 1 - Request 909 2 - Response 911 Identifier 913 The identifier field is one octet and aids in matching 914 responses with requests. 916 Length 918 The Length field is two octets and indicates the number of 919 octets in an EAP message including the Code, Identifier, 920 Length, Type, and Data fields. 921 Type 923 To be assigned. 925 Version 927 The EAP-SAKE method as described herein is version 2. 929 Session ID 931 The Session ID is a 1-byte random number that MUST be freshly 932 generated by the Server that must match all EAP messages in a 933 particular EAP conversation. 935 Subtype 936 EAP-SAKE subtype: SAKE/Challenge, SAKE/Confirm, SAKE/Auth- 937 Reject, and SAKE/Identity. All messages of type "EAP-SAKE" that 938 are not of these subtypes MUST silently discarded. 940 Message Name Subtype Value (decimal) 941 ============================================= 942 SAKE/Challenge 1 943 SAKE/Confirm 2 944 SAKE/Auth-Reject 3 945 SAKE/Identity 4 947 3.3.2. Attribute Format 949 The EAP-SAKE attributes that are part of the EAP-SAKE packet follow 950 the Type-Length-Value format with 1-byte Type, 1-byte Length, and 951 variable-length Value (up to 255 bytes). The Length field is in 952 octets and includes the length of the Type and Length fields. The 953 EAP-SAKE attribute format is as follows: 955 0 1 2 3 956 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 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Type | Length | Value... | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 Type 963 1-byte unsigned integer, see Table below. 965 Length 967 The total number of octets in the attribute, including Type and 968 Length. 970 Value 972 Attribute-specific. 974 The following attribute types are allocated. 976 ----------------------------------------------------------------- 977 Attr. Name Length 978 (bytes) Skippable Description 979 ----------------------------------------------------------------- 980 AT_RAND_S 18 No Server Nonce RAND_S 981 AT_RAND_P 18 No Peer Nonce RAND_P 982 AT_MIC_S 10 No Server MIC 983 AT_MIC_P 10 No Peer MIC 984 AT_SERVERID variable No Server FQDN 985 AT_PEERID variable No Peer NAI (tmp, perm) 986 AT_SPI_S variable No Server chosen SPI SPI_S 987 AT_SPI_P variable No Peer SPI list SPI_P 988 AT_ANY_ID_REQ 4 No Requires any Peer Id (tmp, perm) 989 AT_PERM_ID_REQ 4 No Requires Peer's permanent Id/NAI 990 AT_ENCR_DATA Variable Yes Contains encrypted attributes 991 AT_IV Variable Yes IV for encrypted attributes 992 AT_PADDING 2 to 18 Yes Padding for encrypted attributes 993 AT_NEXT_TMPID variable Yes TempID for next EAP-SAKE phase 995 AT_MSK_LIFE 6 Yes MSK Lifetime in seconds 996 ----------------------------------------------------------------- 998 3.3.3. Use of AT_ENCR_DATA Attribute 1000 An example of the AT_ENCR_DATA attribute as used in the 1001 EAP.Request/SAKE/Confirm message is shown below: 1003 0 1 2 3 1004 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 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | AT_IV | Length = 18 | | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1008 | | 1009 | Initialization Vector | 1010 | | 1011 | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | |AT_ENCR_DATA | Length | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}e 1014 | AT_NEXT_TMPID | Length | |}n 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |}c 1016 | |}r 1017 . Peer TempID |}y 1018 . |}p 1019 . |}t 1020 |}e 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}d 1022 | AT_MIC_S | Length = 10 | | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1024 | MIC_S | 1025 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1026 | |AT_PADDING | Length=2 | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 3.3.4. EAP.Request/SAKE/Challenge Format 1031 The format of the EAP.Request/SAKE/Challenge packet is shown below. 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Code | Identifier | Length | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 |Type=EAP-SAKE | Version=2 | Session ID | Subtype=1 | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | AT_RAND_S | Length = 18 | | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1042 | | 1043 | RAND_S | 1044 | | 1045 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1046 | | AT_SERVERID | Length | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | | 1049 : : 1050 | Server ID | 1051 | | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 The semantics of the fields is described below: 1056 Code 1058 1 for Request 1060 Identifier 1062 A random number. See [EAP]. 1064 Length 1066 The length of the entire EAP packet in octets. 1068 Type 1070 EAP-SAKE 1072 Version 1074 2 1076 Session ID 1078 A random number chosen by the server to identify this EAP- 1079 Session. 1081 Subtype 1082 1 for SAKE/Challenge 1084 AT_RAND_S 1086 The value field of this attribute contains the Server nonce 1087 RAND_S parameter. The RAND_S attribute MUST be present in 1088 EAP.Request/SAKE/Challenge. 1090 AT_SERVERID 1092 The value field of this attribute contains the Server identifier 1093 (e.g. a non-null terminated string). The AT_SERVERID attribute 1094 SHOULD be present in EAP.Request/SAKE Challenge. 1096 3.3.5. EAP.Response/SAKE/Challenge Format 1098 The format of the EAP.Response/SAKE/Challenge packet is shown below. 1100 0 1 2 3 1101 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 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Code | Identifier | Length | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 |Type=EAP-SAKE | Version=2 | Session ID | Subtype=1 | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | AT_RAND_P | Length = 18 | | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1109 | | 1110 | RAND_P | 1111 | | 1112 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1113 | | AT_PEERID | Length | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | | 1116 : Peer NAI : 1117 | | 1118 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1119 | | AT_SPI_P | Length | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | SPIP | AT_MIC_P | Length = 18 | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | | 1124 | MIC_P | 1125 | | 1126 | | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 The semantics of the fields is described below: 1131 Code 1133 2 for Response 1135 Identifier 1137 A number that MUST match the Identifier field from the 1138 corresponding Request. 1140 Length 1142 The length of the entire EAP packet in octets. 1144 Type 1146 EAP-SAKE 1148 Version 1150 2 1152 Session ID 1154 A number matching all other EAP messages in this EAP session. 1156 Subtype 1158 1 for SAKE/Challenge 1160 AT_RAND_P 1162 The value field of this attribute contains the Peer nonce RAND_P 1163 parameter. The AT_RAND_P attribute MUST be present in the 1164 EAP.Response/SAKE/Challenge. 1166 AT_PEERID 1168 The value field of this attribute contains the NAI of the Peer. 1169 The Peer identity follows the same Network Access Identifier 1170 format that is used in EAP.Response/Identity, i.e. including the 1171 NAI realm portion. The identity is the permanent identity, or a 1172 temporary identity. The identity does not include any 1173 terminating null characters. The AT_PEERID attribute is optional 1174 in the EAP.Response/SAKE/Challenge. 1176 AT_SPI_P 1177 The value field of this attribute contains the Peer's 1178 ciphersuite list SPI_P parameter. The AT_SPI_P attribute is 1179 optional in the EAP.Response/SAKE/Challenge. 1181 AT_MIC_P 1183 The value field of this attribute contains the Peer 1184 MIC_P parameter. The AT_MIC_P attribute MUST be present in the 1185 EAP.Response/SAKE/Challenge. 1187 3.3.6. EAP.Request/SAKE/Confirm Format 1189 The format of the EAP.Request/SAKE/Confirm packet is shown below. 1191 0 1 2 3 1192 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 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Code | Identifier | Length | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 |Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | AT_SPI_S | Length | SPI_S | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | AT_IV | Length | Initialization Vector ... | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 1203 | | 1204 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | | AT_ENCR_DATA | Length | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Encrypted Data... | 1208 | | 1209 | | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | AT_MSK_LIFE | Length=6 | MSK Lifetime... | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | | AT_MIC_S | Length=18 | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | | 1216 | MIC_S | 1217 | | 1218 | | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 The semantics of the fields is described below: 1223 Code 1224 1 for Request 1226 Identifier 1228 A random number. See [EAP]. 1230 Length 1232 The length of the entire EAP packet in octets. 1234 Type 1236 EAP-SAKE 1238 Version 1240 2 1242 Session ID 1244 A number matching all other EAP messages in this EAP session. 1246 Subtype 1248 2 for SAKE Confirm 1250 AT_SPI_S 1252 The value field of this attribute contains the Server chosen 1253 ciphersuite SPI_S parameter. The AT_SPI_S attribute is optional 1254 in the EAP.Request/SAKE/Confirm. 1256 AT_IV 1258 This attribute is optional to use in this message. The value 1259 field of this attribute contains the Initialization Vector that 1260 is used with the encrypted data following. 1262 AT_ENCR_DATA 1264 This attribute is optional to use in this message. The encrypted 1265 data, if present, may contain an attribute AT_NEXT_TMPID, 1266 containing the NAI the Peer should use in the next EAP 1267 authentication. 1269 AT_MSK_LIFE 1271 This attribute is optional to use in this message. The value 1272 field of this attribute contains the MSK Lifetime in seconds. 1274 AT_MIC_S 1276 The value field of this attribute contains the Server 1277 MIC_S parameter. The AT_MIC_S attribute MUST be present in the 1278 EAP.Request/SAKE/Confirm. 1280 3.3.7. EAP.Response/SAKE/Confirm Format 1282 The format of the EAP.Response/SAKE/Confirm packet is shown below. 1284 0 1 2 3 1285 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 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Code | Identifier | Length | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 |Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | AT_MIC_P | Length = 18 | | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1293 | MIC_P | 1294 | | 1295 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | | AT_PADDING | Length = 2 | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 The semantics of the fields is described below: 1301 Code 1303 2 for Response 1305 Identifier 1307 A number that MUST match the Identifier field from the 1308 corresponding Request. 1310 Length 1312 The length of the entire EAP packet in octets. 1314 Type 1316 EAP-SAKE 1318 Version 1320 2 1322 Session ID 1324 A number matching all other EAP messages in this EAP session. 1326 Subtype 1328 2 for SAKE Confirm 1330 AT_MIC_P 1332 The value field of this attribute contains the Peer's 1333 MIC_P parameter. The AT_MIC_P attribute MUST be present in the 1334 EAP.Response/SAKE/Confirm. 1336 AT_PADDING 1338 The value field is set to zero. Added to achieve 32-bit 1339 alignment of the EAP-SAKE packet. 1341 3.3.8. EAP.Response/SAKE/Auth-Reject Format 1343 The format of the EAP.Response/SAKE/Auth-Reject packet is shown 1344 below. 1346 0 1 2 3 1347 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 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Code | Identifier | Length | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 |Type=EAP-SAKE | Version=2 | Session ID | Subtype=3 | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 The semantics of the fields is described below: 1356 Code 1358 2 for Response 1360 Identifier 1362 A number that MUST match the Identifier field from the 1363 corresponding Request. 1365 Length 1367 The length of the entire EAP packet in octets. 1369 Type 1371 EAP-SAKE 1373 Version 1375 2 1377 Session ID 1379 A number matching all other EAP messages in this EAP session. 1381 Subtype 1383 3 for SAKE/Auth-Reject 1385 3.3.9. EAP.Request/SAKE/Identity Format 1387 The format of the EAP.Request/SAKE/Identity is shown below. 1389 0 1 2 3 1390 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 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Code | Identifier | Length | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 |Type=EAP-SAKE | Version=2 | Session ID | Subtype=4 | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 |AT_PERM_ID_REQ | Length = 4 | Reserved | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 |AT_ANY_ID_REQ | Length = 4 | Reserved | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 |AT_SERVERID | Length | | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 1402 | Server ID | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 The semantics of the fields is described below: 1407 Code 1409 1 for Request 1411 Identifier 1413 A random number. See [EAP]. 1415 Length 1417 The length of the entire EAP packet in octets. 1419 Type 1420 EAP-SAKE 1422 Version 1424 2 1425 Session ID 1427 A number matching all other EAP messages in this EAP session. 1429 Subtype 1431 4 for SAKE/Identity 1433 AT_PERM_ID_REQ 1435 The AT_PERM_ID_REQ attribute is optional, to be included in 1436 cases where the Server requires the Peer to give its permanent 1437 identifier (i.e. PermID). The AT_PERM_ID_REQ MUST NOT be 1438 included if the AT_ANY_ID_REQ attribute is included. The value 1439 field only contains two reserved bytes, which are set to zero 1440 on sending and ignored on reception. 1442 AT_ANY_ID_REQ 1444 The AT_ANY_ID_REQ attribute is optional, to be included in cases 1445 where the Server requires the Peer to send any identifier (e.g. 1446 PermID, TempID). The AT_ANY_ID_REQ MUST NOT be included if 1447 AT_PERM_ID_REQ is included. The value field only contains two 1448 reserved bytes, which are set to zero on sending and ignored on 1449 reception. One of the AT_PERM_ID_REQ and AT_ANY_ID_REQ MUST be 1450 included. 1452 AT_SERVERID 1454 The value field of this attribute contains the identifier/realm 1455 of the Server. The AT_SERVERID attribute is optional but 1456 RECOMMENDED to include in the EAP.Request/SAKE/Identity. 1458 3.3.10. EAP.Response/SAKE/Identity Format 1460 The format of the EAP.Response/SAKE/Identity is shown below: 1462 0 1 2 3 1463 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 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Code | Identifier | Length | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 |Type=EAP-SAKE | Version=2 | Session ID | Subtype=4 | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | AT_PEERID | Length | | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 1471 | Peer NAI | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 The semantics of the fields is described below: 1476 Code 1478 2 for Response 1480 Identifier 1482 A number that MUST match the Identifier field from the 1483 corresponding Request. 1485 Length 1487 The length of the entire EAP packet. 1489 Type 1491 EAP-SAKE 1493 Version 1495 2 1497 Session ID 1499 A number matching all other EAP messages in this EAP session. 1501 Subtype 1503 4 for SAKE/Identity 1505 AT_PEERID 1507 The value field of this attribute contains the NAI of the Peer. 1508 The AT_PEERID attribute MUST be present in 1509 EAP.Response/SAKE/Identity. 1511 3.3.11. Other EAP Messages Formats 1513 The format of the EAP.Request/Identity and EAP.Response/Identity 1514 packets is described in [EAP]. The user ID (e.g. NAI) SHOULD be 1515 present in this packet. 1517 The format of the EAP-Success and EAP-Failure packet is also shown in 1518 [EAP]. 1520 4. IANA Considerations 1522 This memo requires IANA to allocate a new EAP Type for EAP-SAKE. 1524 EAP-SAKE messages include an 8-bit Subtype field. The Subtype is a 1525 new numbering space for which IANA administration is required. The 1526 following subtypes are specified in this memo: 1528 SAKE/Challenge.................1 1529 SAKE/Confirm...................2 1530 SAKE/Auth-Reject...............3 1531 SAKE/Identity..................4 1533 The Subtype-specific data is composed of attributes, which have an 1534 8-bit type number. Attributes numbered within the range 0 through 1535 127 are called non-skippable attributes, and attributes within the 1536 range of 128 through 255 are called skippable attributes. The EAP- 1537 SAKE attribute type number is a new numbering space for which IANA 1538 administration is required. The following attribute types are 1539 specified: 1541 AT_RAND_S.......................................1 1542 AT_RAND_P.......................................2 1543 AT_MIC_S........................................3 1544 AT_MIC_P........................................4 1545 AT_SERVERID.....................................5 1546 AT_PEERID.......................................6 1547 AT_SPI_S........................................7 1548 AT_SPI_P........................................8 1549 AT_ANY_ID_REQ...................................9 1550 AT_PERM_ID_REQ.................................10 1552 AT_ENCR_DATA..................................128 1553 AT_IV.........................................129 1554 AT_PADDING....................................130 1555 AT_NEXT_TMPID.................................131 1556 AT_MSK_LIFE... ...............................132 1558 All requests for value assignment from the two number spaces 1559 described in this memo require proper documentation, according to 1560 the "Specification Required" policy described in [IANA]. 1562 All assignments of values from the two number spaces described in this 1563 memo require IETF consensus. 1565 5. Security Considerations 1567 The EAP specification [EAP] describes the security vulnerabilities of 1568 EAP, which does not include its method-specific security mechanisms. 1569 This section discusses the claimed security properties of the EAP- 1570 SAKE method, along with vulnerabilities and security recommendations. 1572 5.1. Denial-of-service Attacks 1574 Since EAP-SAKE is not a tunneling method, the EAP.Response/SAKE/Auth- 1575 Reject, EAP.Success and EAP.Failure packets are not integrity or 1576 replay protected. This makes it possible for an attacker to spoof 1577 such messages. Note that EAP.Response/SAKE/Auth-Reject cannot be 1578 protected with a MIC since an authentication failure indicates that 1579 the Server and Peer do not agree on a common key. 1581 Most importantly, an attacker cannot cause a Peer to accept an 1582 EAP.Success packet as indication that the Server considers the mutual 1583 authentication to have been achieved. This is because a Peer does not 1584 accept EAP.Success packets before it has authenticated the Server or 1585 after it has considered the Server to have failed authentication. 1587 5.2. Root Secret Considerations 1589 If the Root Secret is known to any party other than the Server and 1590 Peer, then the mutual authentication and key establishment using EAP- 1591 SAKE is compromised. 1593 EAP-SAKE does not address how the Root Secret is generated or 1594 distributed to the Server and Peer. It is RECOMMENDED that the 1595 entropy of the Root Secret be maximized. The Root Secret SHOULD be 1596 machine-generated. 1598 If the Root Secret is derived from a low-entropy, guessable quantity 1599 such as a human-selected password, then the EAP-SAKE key derivation 1600 is subject to on-line and off-line dictionary attacks. To help 1601 identify whether such a password has been compromised, 1602 implementations SHOULD keep a log of the number of EAP-SAKE messages 1603 received with invalid MIC fields. In these cases, a procedure for 1604 updating the Root Secret securely SHOULD be in place. 1606 5.3. Mutual Authentication 1608 Mutual authentication is accomplished via the SAKE/Challenge and 1609 SAKE/Confirm messages. The EAP.Request/SAKE/Challenge contains the 1610 Server nonce RAND_S, the EAP.Response/SAKE/Challenge contains the 1611 Peer nonce RAND_P, along with the Peer MIC (MIC_P), and 1612 the EAP.Request/SAKE/Confirm contains the Server MIC (MIC_S). 1613 Both MICs (MIC_S and MIC_P) are computed using both nonces 1614 RAND_S and RAND_P and keyed by the TEK, a shared secret derived from 1615 the Root Secret. The Server considers the Peer authenticated if the 1616 MIC_P it computes matches the one that the Peer sends. Similarly, the 1617 Peer considers the Server authenticated if the MIC_S it computes 1618 matches the one that the Server sends. The way the MICs are computed 1619 involves a keyed one-way hash function, which makes it 1620 computationally hard for an attacker to produce the correct MIC 1621 without knowledge of the shared secret. 1623 5.4. Integrity Protection 1625 Integrity protection of EAP-SAKE messages is accomplished through the 1626 use of the Message Integrity Checks (MIC), which are present in every 1627 message as soon as a common shared secret (TEK) is available, i.e. 1628 any message after the EAP.Request/SAKE/Challenge. An adversary cannot 1629 modify any of the MIC-protected messages without causing the 1630 recipient to encounter a MIC failure. The extent of the integrity 1631 protection is commensurate with the security of the KDF used to 1632 derive the MIC, the length and entropy of the shared secret used by 1633 the KDF, and the length of the MIC. 1635 5.5. Replay Protection 1637 The first message of most session establishment protocols such as 1638 EAP-SAKE is subject to replay. A replayed EAP.Request/SAKE/Challenge 1639 message results in the Peer sending an EAP.Response/SAKE/Challenge 1640 message back, which contains a MIC that was computed using the 1641 attacker's chosen nonce. This poses a minimal risk to the compromise 1642 of the TEK-Auth key, and this EAP Session cannot proceed successfully 1643 as the Peer will find the Server's MIC invalid. 1645 Replay protection is achieved via the RAND_S and RAND_P values, 1646 together with the Session ID field, which are included in the 1647 calculation of the MIC present in each packet subsequent to the EAP- 1648 SAKE/Challenge request packet. The Session ID MUST be generated anew 1649 by the Server for each EAP session. Session Ids also aid in 1650 identification of possible multiple EAP sessions between a Peer and 1651 a Server. Within the same session, messages can be replayed by an 1652 attacker, but the state machine SHOULD be able to handle these cases. 1653 Note that a replay within a session is indistinguishable to a 1654 recipient from a network malfunction (e.g. message first lost, then 1655 re-transmitted, so the recipient thinks it is a duplicate message). 1657 Replay protection between EAP sessions and within an EAP session is 1658 also accomplished via the MIC, which cover not only the entire EAP 1659 packet (including the Session ID) but also the nonces RAND_S and 1660 RAND_P. Thus, the recipient of an EAP message can be assured that the 1661 message it just received is the one just sent by the other Peer and 1662 not a replay, since it contains a valid MIC of the 1663 recipient's nonce and the other Peer nonce. As before, the extent of 1664 replay protection is commensurate with the security of the KDF used 1665 to derive the MIC, the length and entropy of the shared secret used 1666 by the KDF, and the length of the MIC. 1668 5.6. Confidentiality 1670 Confidentiality of EAP-SAKE attributes is supported through the use 1671 of the AT_ENCR_DATA and AT_IV attributes. A ciphersuite is negotiated 1672 securely (see section 3.2.7) and can be used to encrypt any 1673 attributes as needed. The default ciphersuite contains a strong 1674 cipher based on AES. 1676 5.7. Key Derivation, Strength 1678 EAP-SAKE derives a Master Key (for EAP use) and Master Session Key, 1679 as well as other lower-level keys such as TEKs. Some of the lower 1680 level keys may or may not be used. The strength (entropy) of all 1681 these keys is at most the strength of the Root Secret. 1683 The entropy of the MSK and of the EMSK, assuming that the Server and 1684 Peer 128-bit nonces are generated using good random number 1685 generators, is at most 256-bits. 1687 5.8. Dictionary Attacks 1689 Dictionary attacks are not feasible to mount on the EAP-SAKE method 1690 because passwords are not used: instead, the Root Secret is machine- 1691 generated. This does not necessarily pose provisioning problems. 1693 5.9. Man-in-the-middle Attacks 1695 Resistance to man-in-the-middle attacks is provided through the 1696 integrity protection that each EAP message carries (i.e. Message 1697 Integrity Check field) as soon as a common key for this EAP session 1698 has been derived through mutual authentication. As before, the extent 1699 of this resistance is commensurate with the strength of the MIC 1700 itself. Man-in-the-middle attacks associated with the use of any EAP 1701 method within a tunneling or sequencing protocol are beyond the scope 1702 of this document. 1704 5.10. Result Indication Protection 1706 EAP-SAKE provides result indication protection in that it provides 1707 result indications, integrity protection, and replay protection. The 1708 Server indicates that it has successfully authenticated the Peer by 1709 sending the EAP.Request/SAKE/Confirm message which is integrity and 1710 replay protected. The Peer indicates that it has successfully 1711 authenticated the Server by sending the EAP.Response/SAKE/Confirm 1712 message, which is also integrity and replay protected. 1714 5.11. Cryptographic Separation of Keys 1716 The TEKs used to protect EAP-SAKE packets (TEK-Auth, TEK-Cipher), the 1717 Master Session Key, and the Extended Master Session Key are 1718 cryptographically separate. Information about any of these keys does 1719 not lead to information about any other keys. We also note that it is 1720 infeasible to calculate the Root Secret from any or all of the TEKs, 1721 the MSK, or the EMSK. 1723 5.12. Session Independence 1725 Within each EAP-SAKE session, fresh keying material is generated. The 1726 keying material exported by this method from two independent EAP-SAKE 1727 sessions is cryptographically separate, as explained below. 1729 Both the Server and the Peer SHOULD generate fresh random numbers 1730 (i.e. nonces) for the EAP-SAKE exchange. If either entity re-uses a 1731 random number from a previous session, then the fact that the other 1732 does use a freshly generated random number implies that the TEKs, 1733 MSK, and EMSK derived within this session are cryptographically 1734 separate from the corresponding keys derived in the previous 1735 exchange. 1737 Therefore, compromise of MSK or EMSK on one exchange does not 1738 compromise the MSK and EMSK of previous or subsequent exchanges 1739 between a Peer and a Server. 1741 5.13. Identity Protection 1743 As seen from Section 3.2.3., the Server may assign a temporary NAI to 1744 a Peer in order to achieve user anonymity. This identifier may be 1745 used by the Peer next time it engages in an EAP-SAKE authentication 1746 phase with the Server. The TempID is protected by sending it 1747 encrypted, within an AT_ENCR_DATA attribute, and signed by the Server 1748 with a MIC. Thus, an eavesdropper cannot link the original PermID 1749 that the Peer first sends (e.g. on power-up) to any subsequent TempID 1750 values sent in the clear to the Server. 1752 The Server and Peer MAY be configured such that only TempID 1753 identities are exchanged after one initial EAP-SAKE phase that uses 1754 the Peer permanent identity. In this case, in order to achieve 1755 maximum identity protection, the TempID SHOULD be stored in non- 1756 volatile memory in the Peer and Server. Thus compliance with this 1757 draft does not preclude nor mandates Peer identity protection across 1758 the lifetime of the Peer. 1760 5.14. Channel Binding 1762 The Server identifier and Peer identifier MAY be sent in the 1763 SAKE/Challenge messages. However, since there is no established 1764 authentication key at the time of the first message, the Server 1765 identifier is not integrity protected here. 1767 All subsequent EAP-SAKE messages exchanged during a successful EAP- 1768 SAKE phase are integrity-protected as they contain a Message 1769 Integrity Check (MIC). The MIC is computed over the EAP message and 1770 also over the Server and Peer identities. In that, both EAP endpoints 1771 can verify the identity of the other party. 1773 5.15. Ciphersuite Negotiation 1775 EAP-SAKE does not support negotiation of the ciphersuite used to 1776 integrity-protect the EAP conversation. However, negotiation of a 1777 ciphersuite for data protection is supported. This ciphersuite 1778 negotiation is protected in order to minimize the risk of down- 1779 negotiation or man-in-the-middle attacks. 1781 This negotiation is secure because of the Message Integrity Checks 1782 (MICs) that cover the entire EAP messages used for ciphersuite 1783 negotiation (see Section 3.2.7.). The extent of the security of the 1784 negotiation is commensurate with the security of the KDF used to 1785 derive the MICs, the length and entropy of the shared secret used by 1786 the KDF, and the length of the MICs. 1788 5.16. Random Number Generation 1790 EAP-SAKE supports key derivation from a 32-byte Root Secret. The 1791 entropy of all other keys derived from it is reduced somewhat through 1792 the use of keyed hash functions (e.g. KDF). Thus, assuming 1793 optimistically that the effective key strength of the Root Secret is 1794 32 bytes, the effective key strengths of the derived keys is at most 1795 the effective key strength of the Root Secret quantities they are 1796 derived from: EMSK, at most 16 bytes; MSK, at most 16 bytes. 1798 6. Security Claims 1800 This section provides the security claims as required by [EAP]. 1802 [a] Mechanism: EAP-SAKE is a challenge/response authentication and 1803 key establishment mechanism based on a symmetric pre-shared 1804 secret. 1806 [b] Security claims. EAP-SAKE provides: 1808 Mutual authentication (Section 5.3) 1810 Integrity protection (Section 5.4) 1812 Replay protection (Section 5.5) 1814 Confidentiality (optional, Section 5.6 and Section 5.13) 1816 Key derivation (Section 5.7) 1818 Dictionary attack protection (Section 5.8) 1820 Protected result indication of successful authentication from 1821 Server and from Peer (Section 5.10) 1823 Session independence (Section 5.12) 1825 [c] Key strength. EAP-SAKE supports key derivation with 256-bit 1826 effective key strength (Section 5.7.) 1828 [d] Description of key hierarchy: see Section 3.2.5. 1830 [e] Indication of vulnerabilities: EAP-Make does not provide: 1832 Fast reconnect 1834 Fragmentation 1836 Channel binding 1838 Cryptographic binding 1840 7. Acknowledgements 1842 Thanks to R. Dynarski for his helpful comments. 1844 8. References 1846 8.1. Normative References 1848 [AES] National Institute of Standards and Technology, "Federal 1849 Information Processing Standards (FIPS) Publication 197, 1850 Advanced Encryption Standard (AES)", November 2001. 1851 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 1853 [CBC] National Institute of Standards and Technology, NIST 1854 Special Publication 800-38A, "Recommendation for Block 1855 Cipher Modes of Operation - Methods and Techniques", 1856 December 2001. 1857 http://csrc.nist.gov/publications/nistpubs/800-a/sp800-38a.pdf 1859 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and 1860 Levkowetz, H. "Extensible Authentication Protocol (EAP) 1861 ", RFC 3748, June 2004. 1863 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- 1864 Hashing for Message Authentication", RFC 2104, February 1865 1997. 1867 [IANA] Narten, T. and H. Alvestrand, "Guidelines for 1868 Writing an IANA Considerations Section in RFCs", 1869 BCP 26, RFC 2434, October 1998. 1871 [IEEE802.11i]"IEEE Standard for Information Technology- 1872 Telecommunications and Information Exchange between 1873 Systems - LAN/MAN Specific Requirements - Part 11: 1874 Wireless Medium Access Control (MAC) and physical layer 1875 (PHY) specifications: Amendment 6: Medium Access Control 1876 (MAC) Security Enhancements", June 2004. 1878 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1879 Requirement Levels", BCP 14, RFC 2119, March 1997. 1881 [SHA1] National Institute of Standards and Technology, U.S. 1882 Department of Commerce, Federal Information Processing 1883 Standard (FIPS) Publication 180-1, "Secure Hash 1884 Standard", April 1995. 1886 8.2. Informative References 1888 [NAI] Aboba, B., and Beadles, M., "The Network Access 1889 Identifier", RFC 4282, April 1999. 1891 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1892 Recommendations for Security", RFC 1750, December 1994. 1894 Authors' Addresses 1896 Michaela Vanderveen 1897 Qualcomm Flarion Technologies 1898 135 Rte. 202/206 South 1899 Bedminster, NJ 07921 1900 USA 1901 E-mail: mvandervn@yahoo.com 1903 Hesham Soliman 1904 Qualcomm Flarion Technologies 1905 135 Rte. 202/206 South 1906 Bedminster, NJ 07921 1907 USA 1908 E-mail: solimanhs@gmail.com 1910 Intellectual Property Statement 1912 The IETF takes no position regarding the validity or scope of any 1913 Intellectual Property Rights or other rights that might be claimed to 1914 pertain to the implementation or use of the technology described in 1915 this document or the extent to which any license under such rights 1916 might or might not be available; nor does it represent that it has 1917 made any independent effort to identify any such rights. Information 1918 on the procedures with respect to rights in RFC documents can be 1919 found in BCP 78 and BCP 79. 1921 Copies of IPR disclosures made to the IETF Secretariat and any 1922 assurances of licenses to be made available, or the result of an 1923 attempt made to obtain a general license or permission for the use of 1924 such proprietary rights by implementers or users of this 1925 specification can be obtained from the IETF on-line IPR repository at 1926 http://www.ietf.org/ipr. 1928 The IETF invites any interested party to bring to its attention any 1929 copyrights, patents or patent applications, or other proprietary 1930 rights that may cover technology that may be required to implement 1931 this standard. Please address the information to the IETF at ietf- 1932 ipr@ietf.org. 1934 Disclaimer of Validity 1936 This document and the information contained herein are provided on an 1937 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1938 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1939 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1940 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1941 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1942 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1944 Copyright Statement 1946 Copyright (C) The Internet Society (2006). This document is subject 1947 to the rights, licenses and restrictions contained in BCP 78, and 1948 except as set forth therein, the authors retain all their rights.