idnits 2.17.00 (12 Aug 2021) /tmp/idnits23628/draft-otto-eap-skl-03.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 722. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 712. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Fragmentation: An EAP method may assume a mimimum EAP MTU of 1020 byte. Message (4) is the largest one. An EAP Request or Response packet begins with four fields (Code, Identifier, Length and Type), with total 5 byte, followed by the payload. value_P as modulo 3072 can be at most 384 byte, and finally HMAC-SHA1 produces a 20-byte MAC. These are 409 byte, so that AT_ID MAY NOT exceed 1020-409=611 byte. The encapsulated id_P thus may not exceed 611-4=607 byte. -- 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 (October 6, 2005) is 6070 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) == Unused Reference: 'I-D.cam-winget-eap-fast' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC4017' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'I-D.bersani-eap-psk' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'I-D.clancy-eap-pax' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'I-D.tschofenig-eap-ikev2' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'PRF' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'RFC2284' is defined on line 639, but no explicit reference was found in the text == Outdated reference: draft-cam-winget-eap-fast has been published as RFC 4851 ** Downref: Normative reference to an Informational draft: draft-cam-winget-eap-fast (ref. 'I-D.cam-winget-eap-fast') ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 4017 -- Possible downref: Non-RFC (?) normative reference: ref. 'SKEME' == Outdated reference: draft-bersani-eap-psk has been published as RFC 4764 == Outdated reference: draft-clancy-eap-pax has been published as RFC 4746 == Outdated reference: draft-tschofenig-eap-ikev2 has been published as RFC 5106 -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Otto 3 Internet-Draft TU Braunschweig 4 Expires: April 9, 2006 October 6, 2005 6 The EAP-SKL protocol 7 draft-otto-eap-skl-03.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 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 This Internet-Draft will expire on April 9, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes EAP-SKL, an Extensible Authentication 41 Protocol (EAP) method which provides mutual authentication and key 42 derivation based on a pre-shared secret. EAP-SKL relies on the 43 cryptographic protocol SKEME (Secure Key Exchange MEchanism 44 protocol), and hence may benefit from its simplicity and the provable 45 security. EAP-SKL complies with the mandatory requirements for an 46 EAP method which is intented for deployment in Wireless LAN 47 environments. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 53 1.2. EAP Terminology . . . . . . . . . . . . . . . . . . . . . 4 54 2. Cryptographic Considerations . . . . . . . . . . . . . . . . . 6 55 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 56 4. Packet formats . . . . . . . . . . . . . . . . . . . . . . . . 11 57 5. Computational costs . . . . . . . . . . . . . . . . . . . . . 12 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 60 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 17 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 64 Appendix A. T-PRF . . . . . . . . . . . . . . . . . . . . . . . . 20 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 66 Intellectual Property and Copyright Statements . . . . . . . . . . 22 68 1. Introduction 70 IEEE 802.11i makes use of IEEE 802.1X which in turn chooses the 71 Extensible Authentication Protocol (EAP) for carrying authentication 72 messages. EAP itself is only a framework, and runs over various link 73 layers, like IEEE 802.3 Ethernet, IEEE 802.11 Wireless LAN or PPP. 74 In fact, the proper authentication is performed by so called EAP 75 methods. 77 In 1998, when RFC 2284 was adopted, an usage of EAP outside of wired 78 networks was not taken into account. EAP was thoroughly reviewed, 79 which yielded in May 2004 in RFC 3748. For compatibility reasons, 80 these three EAP methods are still part of the EAP specification, even 81 if declared as deprecated. EAP-MD5, for instance, lacks of mutual 82 authentication and derivation of session keying material, as mandated 83 in [RFC3748]. 85 It has been widely recognized that this state is dissatisfying. In 86 particular, it lacks of a pre-shared key EAP method, which is simple 87 (that is lightweight in terms of bandwidth, latency and computational 88 costs as well as easy in deployment) and, at the same time, provides 89 enough security strength to be used in hostile environments like the 90 Internet or Wireless LAN. Such an EAP method could possibly serve as 91 a replacement for the deprecated EAP-MD5. 93 EAP-SKL attempts to be an straightforward EAP method with as much 94 features as needed but as few as possible. More precisely, EAP-SKL 95 takes all mandatory requirements into account, with main focus on 96 mutual authentication and adequate session key derivation. Current 97 pre-shared key EAP methods are EAP-FAST, EAP-SIM/AKA, EAP-PSK, EAP- 98 PAX, EAP-TLS (with appropriate extensions) as well as EAP-IKEv2, 99 where EAP-SKL claims to be the simplest one. Further informations 100 about EAP methods can be found in the comprehensive compilation 101 [I-D.bersani-eap-synthesis-sharedkeymethods]. 103 Furthermore, EAP-SKL relies on only one cryptographic primitive, 104 namely the hash function SHA-1 ([FIPS.180-1.1994]) and optionally the 105 Diffie-Hellman key agreement protocol ([RFC2631]). The choice of 106 SKEME as an appropriate key establishment protocol makes it possible 107 to fully abstain from block ciphers and stream ciphers. Of course, 108 this restricts EAP-SKL's ability to solely perform the mutual 109 authentication task, and does not allow for encrypted communication, 110 like, for instance, EAP-PSK does so. The author is convinced that 111 there are many deployment scenarios, where indeed nothing more than 112 minimalistic functionality is required and desired. Consequently, 113 and in contrast to many other EAP methods, EAP-SKL does not 114 implement, for instance, version negotiation, fragmentation, session 115 resuming, protected result indication or end-user identity hiding. 117 Nevertheless, there is a single feature which is highly desireable in 118 some cases, namely Perfect Forward Secrecy. 120 The rest of this document is organized as follows. In the remaining 121 section 1, some terminology is introduced. Section 2 highlights the 122 cryptographic background of EAP-SKL. Section 3 and 4 cover the EAP- 123 SKL protocol and the packet format of the messages. Section 5 and 6 124 are IANA Considerations and Security Considerations, respectively. 126 1.1. Requirements notation 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 1.2. EAP Terminology 134 This section contains variables and abbreviations which will be 135 referenced in later sections. For the exact meaning of the roles 136 "peer", "Supplicant", "backend authentication server" and "EAP 137 server" please refer to the EAP specification [RFC3748]. In this 138 document, the words peer and client are used equivalently. The EAP 139 conversation takes place between the client and the EAP server. 141 Ko: 160-bit symmetric key; shared between client and EAP server. Ko 142 is the most longlife credential within EAP-SKL. 144 MK: Master Key; shared between the client and EAP server from which 145 all other EAP method session keys are derived. 147 MSK: Master Session Key; generated from the MK and exported by the 148 EAP method to the authenticator. 150 EMSK: Extended Master Session Key; also generated from the MK. It 151 contains additional keying material. 153 G: public Diffie-Hellman group 155 g: public generator of group G 157 x: 256-bit nonce generated by the client 159 y: 256-bit nonce generated by the server 161 .: (dot); string or binary data concatenation. 163 ^: modular exponentiation 164 "": NULL string 166 PRF: Pseudo-random function 168 F_Ko: pseudorandom function (PRF) keyed with Ko 170 H: hash function 172 SK: session key 174 id_P: client's identity 176 id_S: EAP server's identity 178 PFS: Perfect forward secrecy 180 The corresponding instantiation by EAP-SKL is described in Section 2. 182 2. Cryptographic Considerations 184 This section describes the cryptographic design of EAP-SKL. The 185 cryptographic protocol SKEME was chosen to realize mutual 186 authentication and session key establishment. SKEME provides four 187 operational modes, which offers high flexibility. More precisely, it 188 allows the usage of PKIs, KDC and manual (pre-shared) distribution of 189 keying material for an initial keying relationship. 191 Since EAP-SKL is a pre-shared key authentication method, only the 192 corresponding two modes of SKEME are implemented. The one, from now 193 on referred to as "mode 1", provides Perfect Forward Secrecy (PFS) 194 and hence incorporates a Diffie-Hellman (DH) Key Exchange, which is 195 known to be computational expensive. If this property is not needed, 196 the other mode, referred to as "mode 2", is chosen. This mode 197 achieves freshness by exchanging random values (nonces), and in 198 absence of asymmetric cryptography mode 2 is notably efficient. In a 199 nutshell, mode 1 provides a better security strength but higher 200 computational costs, whereas mode 2 performs very fast but with fewer 201 security strength. See section 4 for more details. 203 The notation introduced by [SKEME] is maintained to avoid confusion. 204 There is a collision-resistant hash function, H, a pseudorandom 205 function using key Ko, F_Ko, and as parameters for the DH key 206 exchange g, x, y, m, where g is the generator, m the modulus, and x 207 and y are the client's and EAP server's private DH key, respectively. 208 In EAP-SKL, H is SHA-1 and F_Ko over message M is SHA-1(Ko.M). 210 In the next section, the two modes of EAP-SKL are described. For 211 mode 2, the session key is computed via 213 SK =F_Ko(F_Ko(value_S.value_P.id_P.id_S)), 215 that is, a keyed PRF is applied twice on an input. This idea has 216 finally lead to the HMAC-construction. A HMAC (hash-based MAC) over 217 the input "text" is defined as 219 HMAC(K;text) = H(K XOR opad . H(K XOR ipad . text)). 221 The output of SHA-1 and subsequently of HMAC-SHA1 is 160 bit. 223 As recommended in [RFC2104], the length of K should be equal to the 224 hash output length, less is explicitely discouraged (as itwould 225 decrease the the security strength). Therefore, EAP-SKL mandates the 226 length of Ko to be 160 bit. 228 Furthermore, SK corresponds to the EAP Master Key (MK), which remains 229 solely within the EAP method. 231 Finally, the DH key exchange parameters have been chosen in 232 accordance to [RFC3766]. The strength of the DH key exchange is 233 based on the modulus size as well as the exponent size. An 3000-bit 234 MODP public-key scheme corresponds roughly to a 128-bit symmetric-key 235 scheme. EAP-SKL utilizes the 3072-bit MODP Group (id 15), defined in 236 [RFC3526]. According to [RFC3526], the exponent size used in the DH 237 key exchange should have double the entropy of the strength of the 238 entire system, in particular the size of any symmetric key that will 239 be derived from it (SK, MSK, EMSK). Since EAP-SKL has an effective 240 key strength of 128 bit, the DH exponents (private keys) MUST have at 241 least 256 bit. As cyclic group, g=2 is chosen (has advantage for 242 hardware accelerated computation). 244 SKEME | EAP-SKL 245 -------------+-------------------- 246 g | 2 247 m | 3072-bit MODP Group 248 x, y | 256 bit 249 H | SHA-1 250 F_Ko(M) | SHA-1(Ko.M) 251 F_Ko(F_Ko(M))| HMAC-SHA1(Ko;arg) 252 -------------+-------------------- 254 Figure 1 256 The rest of this section provides further details about the two 257 modes. 259 Before any run of EAP-SKL, client and EAP server must agree on some 260 160-bit pre-shared key, referred to as Ko. How Ko is established, is 261 beyond the scope of EAP-SKL and thus must be realized by some secure 262 out-of-band mechanism. At the end of a successful authentication, 263 both client and EAP server have independently derived a session key, 264 SK, in length of 160 bit. This key in turn is adequately expanded to 265 generate the required keying material, that is a 64-byte MSK and a 266 64-byte EMSK. 268 This is realized by a pseudorandom function, T-PRF, which is based on 269 SHA-1 and widely accepted. EAP-FAST and PEAP make, for instance, use 270 of this function. Please see Appendix A for internals of T-PRF. 272 T-PRF is invoked with the parameters (Key, S, OutputLength), where S 273 = label + 0x00 + seed. 275 EAP-SKL calls T-PRF with the following parameters: TPRF(Ko, "EAP-SKL" 276 +0x00+ SK, 128). 278 Since T-PRF generates in each iteration 20 byte random data, EAP-SKL 279 let T-PRF iterate 7 times and then skip the last 12 byte. Figure 2 280 illustrates the keying material in EAP-SKL. 282 +---------+ 283 | Ko | 160 bit 284 +---------+ 285 | 286 +===================+ 287 | | 288 | EAP-SKL | 289 | | 290 +===================+ 291 | 292 +---------+ 293 | SK | 160 bit 294 +---------+ 295 | 296 | 297 +---------+ 298 | T-PRF | pseudorandom function 299 +---------+ 300 | 301 | 7*20 byte, 0..139 302 | 303 | +---------+ -+ 304 +-----------| MSK | 64 byte | 305 | 0..63 +---------+ | exported 306 | | by EAP-SKL 307 | +---------+ | 308 +-----------| EMSK | 64 byte | 309 64..127 +---------+ -+ 311 Figure 2 313 3. Protocol Overview 315 The message flow of EAP-SKL is shown in Figure 3. The conversation 316 begins with the exchange of EAP Identity messages, where "id" is 317 reserved for special tasks, like routing purposes or session 318 resumption. 320 P <--- S: EAP-Request/Identity (1) 321 P ---> S: EAP-Response/Identity(id) (2) 322 P <--- S: EAP-Request/EAP-SKL (Start) (3) 323 P ---> S: EAP-Response/EAP-SKL (id_P,value_P) (4) 324 P <--- S: EAP-Request/EAP-SKL(id_S,value_S, 325 F_Ko(value_P.value_S.id_S.id_P)) (5) 326 P ---> S: EAP-Response(F_Ko(value_S.value_P.id_P.id_S)) (6) 327 P <--- S: EAP-Success (7) 329 Figure 3 331 The respective values of value_S and value_P and thus the derivation 332 of SK depend on the chosen mode (Figure 4). 334 | PFS | value_P | value_S | SK | H(M) | F_Ko(M) 335 -------+-----+---------+---------+-----------+---------+----------- 336 mode 1 | yes | g^x | g^y | H(g^xy) | | 337 -------+-----+---------+---------+-----------+ SHA-1(M)| SHA-1(Ko.M) 338 mode 2 | no | nonce_P | nonce_S | F_Ko(arg) | | 339 -------+-----+---------+---------+-----------+---------+----------- 341 where arg = F_Ko(value_S.value_P.id_P.id_S). 343 Figure 4 345 The choice of the mode is left solely to the EAP server. The client 346 finds this out by the type of the received TLV payload in message 347 (3). If the client does not agree with the proposed mode, he 348 indicates this by sending EAP-Response/Nak. Subsequently, the 349 authentication conversation is aborted. 351 After the initial identity request/response, the EAP server sends in 352 message 3 an indication which mode to choose. In Message 4, the peer 353 sends his freshness parameter (either a DH public key or a nonce). 354 Message 5 contains the server`s identity, the server`s freshness 355 parameter, and a MAC. This is verified by the peer, if the 356 verification is successful, it responds with message 6, which also 357 contains a MAC. The EAP server does the same computatation. If the 358 outcome is equal to received MAC, the EAP server is sure to talk to a 359 legitimate client and finish the EAP conversation with an EAP- 360 Success. Otherwise, the authentication has failed and an EAP-Failure 361 is sent. 363 The derivation of SK is, in general SK=F_Ko(arg). But for mode 1, 364 [SKEME] offers the alternative SK=H(g^xy), which is chosen here. 366 For mode 1, it holds SK = H(g^(xy)) = SHA-1(g^xy). 368 For mode 2, we have 370 SK = F_Ko(arg) = F_Ko(F_Ko(value_S.value_P.id_P.id_S)) =^! HMAC- 371 SHA1(Ko;arg). 373 Note that the client has already computed "arg" in message (4) and 374 thus can reuse the result, which would save computational costs. 376 4. Packet formats 378 EAP-SKL messages are encapsulated within the payload of EAP-Request 379 and EAP-Response frames, respectively. Therefore, a generic Type- 380 length-value (TLV) attribute format is chosen (figure Figure 5). 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | type | length | value : 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 : value (contd.) | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 5 392 Length contains the length of the TLV in byte. 394 +---------------+--------+-------------------------+---------------+ 395 | attribute name| type | used for | payload size | 396 +---------------+--------+-------------------------+---------------+ 397 | AT_START | 0 | start | 1 byte | 398 | AT_ID | 1 | id_P | max. 607 byte | 399 | AT_NONCE | 2 | nonce_P, nonce_S | 384 byte | 400 | AT_DH | 3 | DH public key, g^x, g^y | 384 byte | 401 | AT_MAC | 4 | HMAC-SHA1 | 20 byte | 402 +---------------+--------+-------------------------+---------------+ 404 Figure 6 406 That is, the EAP packet payload of messages (2)-(6) consists of one 407 or more TLVs, as shown in Figure 7. In case of mode 1, messages (3) 408 and (4) contain AT_DH TLVs, in case of mode 2 AT_NONCE TLVs. 409 AT_START has a payload of one byte, 0x01 for mode 1, 0x02 for mode 2. 411 P <--- S: AT_START (3) 412 P ---> S: AT_ID . AT_NONCE/AT_DH (4) 413 P <--- S: AT_ID . AT_NONCE/AT_DH . AT_MAC (5) 414 P ---> S: AT_MAC (6) 416 Figure 7 418 5. Computational costs 420 This section briefly considers the computational costs for the 421 client. Modular exponentiations are known to be computationally 422 expensive, SHA-1 computations are in contrast to this very 423 lightweight. 425 | mod exp. | SHA-1 426 -------+----------+------ 427 mode 1 | 2 | 9 428 -------+----------+------ 429 mode 2 | 0 | 11 430 -------+----------+------ 432 Figure 8 434 In mode 1, the peer performs 9 SHA-1 calculations, namely 1x for 435 computing the MAC in message 6, 1x for verification of the MAC in 436 message 5, and 7x for T-PRF. In mode 2, the peer requires 11 SHA-1 437 calculations. Overall, especially the computational costs of mode 2 438 become obvious. 440 Next, we consider the amount of bytes what each side generates and 441 transmits. Only messages 3 to 6 are analyzed. An EAP-Request or 442 EAP-Response frame consists of the fields Code, Identifier, Length, 443 Type, which are 1+1+2+1=5 bytes in total, followed by a variable 444 length payload. Only this payload is considered. 446 size/byte | | mode 1 | mode 2 447 -----------+--------+---------+--------- 448 | msg 4 | 390+idP | 390+idP 449 peer +--------+---------+--------- 450 | msg 6 | 23 | 23 451 -----------+--------+---------+--------- 452 | msg 3 | 4 | 4 453 EAP +--------+---------+--------- 454 server | msg 5 | 413+idS | 413+idS 455 -----------+--------+---------+---------- 457 Figure 9 459 The Diffie-Hellman public key with 384 byte (=3072 bit) size must be 460 considered as heavyweight, compared to the lightweight EAP frame 461 structure. An EAP-Request (resp. Response) has 5+sizeof(payload) 462 bytes length, an EAP-Success or EAP-Failure only 4 bytes. 464 6. Security Considerations 466 This section analyzes the security of EAP-SKL. In particular, it is 467 shown that EAP-SKL complies with all mandatory requirements for EAP 468 methods used in IEEE 802.11 wireless LAN deployments, as outlined in 469 RFC 4017. 471 Mechanism: 473 EAP-SKL belongs to the category of pre-shared key EAP methods. 475 Mutual authentication: 477 EAP-SKL provides mutual authentication. If both parties can 478 verify the received HMAC, the other side is identified and 479 authenticated. Since the MAC is computed over a string which 480 contains fresh random values previously generated, both MACs are 481 interlocked adequately. 483 Key derivation: 484 EAP-SKL generates the required keying material, namely a 64 byte 485 MSK and a 64 byte EMSK, which are exported for derivation of 486 further keying material. 488 Replay protection: 489 EAP-SKL is resistant to replay attacks. 490 Assume an attacker has captured a whole, successful conversation 491 of EAP-SKL. First, we investigate what happens if the attacker 492 wants to impersonate the legitimate client. If value_S of the 493 captured session is different from the current one, the attack 494 fails in computing the MAC in message (4). Suppose now, value_S 495 is the same. It follows that replay of the captures message (4) 496 as well as (6) are recognized as valid ones by the EAP server and 497 thus the attacker will receive an EAP-Success. Unfortunately, he 498 can not derive from HMAC-SHA1(Ko;"success".SK) the session key SK 499 and thus can not derive MSK and EMSK. The attack ends here, that 500 is although the EAP authentication has been successful, subsequent 501 conversation attempts will fail. 503 This replay attack is avoided by strengthening the server's 504 implementation. The space for value_P is large enough to reject 505 any authentication request with the same value_P. Therefore, the 506 server implementation should maintain a table with all previously 507 received (id_P,value_P) pairs. With this precaution, a replayed 508 session is recognized as a such and appropriate countermeasures 509 can take place. 511 Confidentiality: 512 EAP-SKL does not provide confidentiality in terms of [RFC3748], 513 section 7.2.1. The term "confidentiality" refers to encryption of 514 EAP messages and successful and failure result indications. 516 Key strength: 517 The effective key strength of EAP-SKL is 128 bit (see also Section 518 2). 520 Resistance to dictionary attacks: 521 EAP-SKL relies on a pre-shared key, which consists of random data. 522 It is highly discouraged to generate this random data from a 523 dictionary entry by applying some pseudorandom function. 525 Protection against man-in-the-middle attacks: 526 If the link layer is a shared media, there is generally a 527 possibility for a third party (MitM) to place between two parties 528 who want to communicate. The trust relation is established by 529 deriving some common secret, which a third party can not derive 530 from the captured conversation. For EAP-SKL, this is the session 531 key SK, whose lifetime is the session. Without knowledge of Ko 532 this common secret can not be derived. And without knowledge of 533 Ko and SK, both MSK and EMSK can not be derived. 535 Assume now, a MitM sits between peer and EAP Server, and 536 intercepts all server messages and relays them to the peer. This 537 works fine for the whole conversation, that is for messages (1) to 538 (7). But, since the MitM does not know SK, this attack has only 539 denial-of-service character. 541 Protected ciphersuite negotiation: 542 EAP-SKL does not support ciphersuite negotiation. 544 Fast reconnect: 545 EAP-SKL does not support fast reconnect. 547 Cryptographic binding: 548 EAP-SKL performs exactly one authentication and hence this 549 technique is not applicable. 551 Fragmentation: 552 An EAP method may assume a mimimum EAP MTU of 1020 byte. Message 553 (4) is the largest one. An EAP Request or Response packet begins 554 with four fields (Code, Identifier, Length and Type), with total 5 555 byte, followed by the payload. value_P as modulo 3072 can be at 556 most 384 byte, and finally HMAC-SHA1 produces a 20-byte MAC. 557 These are 409 byte, so that AT_ID MAY NOT exceed 1020-409=611 558 byte. The encapsulated id_P thus may not exceed 611-4=607 byte. 560 End-user identity hiding: 561 EAP-SKL does not provide end-user identity hiding. The identity 562 of the client is sent in plaintext. 564 7. IANA Considerations 566 This document introduces one new IANA consideration. It requires 567 IANA to allocate a new EAP Type for EAP-SKL. 569 8. Acknowledgment 571 The author would like to thank Dieter Stolte for useful comments on 572 the initial version of this draft. 574 9. References 576 9.1. Normative References 578 [FIPS.180-1.1994] 579 National Institute of Standards and Technology, "Secure 580 Hash Standard", FIPS PUB 180-1, May 1994. 582 [I-D.cam-winget-eap-fast] 583 Salowey, J., "EAP Flexible Authentication via Secure 584 Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-02 (work 585 in progress), April 2005. 587 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 588 Hashing for Message Authentication", RFC 2104, 589 February 1997. 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 595 Diffie-Hellman groups for Internet Key Exchange (IKE)", 596 RFC 3526, May 2003. 598 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 599 Levkowetz, "Extensible Authentication Protocol (EAP)", 600 RFC 3748, June 2004. 602 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 603 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 604 RFC 3766, April 2004. 606 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 607 Authentication Protocol (EAP) Method Requirements for 608 Wireless LANs", RFC 4017, March 2005. 610 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 611 Mechanism for Internet", June 1996. 613 9.2. Informative References 615 [I-D.bersani-eap-psk] 616 Tschofenig, H. and F. Bersani, "The EAP-PSK Protocol: a 617 Pre-Shared Key EAP Method", draft-bersani-eap-psk-09 (work 618 in progress), August 2005. 620 [I-D.bersani-eap-synthesis-sharedkeymethods] 621 Bersani, F., "EAP shared key methods: a tentative 622 synthesis of those proposed so far", 623 draft-bersani-eap-synthesis-sharedkeymethods-00 (work in 624 progress), April 2004. 626 [I-D.clancy-eap-pax] 627 Clancy, C. and W. Arbaugh, "EAP Password Authenticated 628 Exchange", draft-clancy-eap-pax-04 (work in progress), 629 June 2005. 631 [I-D.tschofenig-eap-ikev2] 632 Tschofenig, H., "EAP IKEv2 Method (EAP-IKEv2)", 633 draft-tschofenig-eap-ikev2-07 (work in progress), 634 July 2005. 636 [PRF] Adams, Carlisle et al., "On the Security of Key Derivation 637 Functions, LNCS 3225, Springer", 2004. 639 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 640 Authentication Protocol (EAP)", RFC 2284, March 1998. 642 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 643 RFC 2631, June 1999. 645 Appendix A. T-PRF 647 The following description of T-PRF corresponds to [I-D.cam-winget- 648 eap-fast], Appendix A. 650 PRF(key, label, seed) = HMAC-SHA1(key, label + "\0" + seed) 652 Where '+' indicates concatenation and "\0" is a NULL character. 653 Label is intended to be a unique label for each different use of the 654 T-PRF. 656 To generate the desired OutputLength octet length of key material, 657 the T-PRF is iterated as follows: 659 T-PRF (Key, S, OutputLength) = T1 + T2 + T3 + T4 + ... 661 Where S = label + 0x00 + seed; and 663 T1 = HMAC-SHA1 (Key, S + OutputLength + 0x01) 665 T2 = HMAC-SHA1 (Key, T1 + S + OutputLength + 0x02) 667 T3 = HMAC-SHA1 (Key, T2 + S + OutputLength + 0x03) 669 T4 = HMAC-SHA1 (Key, T3 + S + OutputLength + 0x04) 671 OutputLength is a two octet value that is represented in big endian 672 order. The NULL character, 0x00 shall be present when a label string 673 is provided. 675 Since each Ti generates 20 byte of keying material, the last Tn is 676 truncated to accommodate the desired length specified by 677 OutputLength. EAP-SKL has to derive 128 byte, so i is set to 7 and 678 the last 12 byte are skipped. 680 Author's Address 682 Thomas Otto 683 TU Braunschweig 684 38106 Braunschweig 685 Germany 687 Phone: 688 Email: t.otto@tu-bs.de 690 Intellectual Property Statement 692 The IETF takes no position regarding the validity or scope of any 693 Intellectual Property Rights or other rights that might be claimed to 694 pertain to the implementation or use of the technology described in 695 this document or the extent to which any license under such rights 696 might or might not be available; nor does it represent that it has 697 made any independent effort to identify any such rights. Information 698 on the procedures with respect to rights in RFC documents can be 699 found in BCP 78 and BCP 79. 701 Copies of IPR disclosures made to the IETF Secretariat and any 702 assurances of licenses to be made available, or the result of an 703 attempt made to obtain a general license or permission for the use of 704 such proprietary rights by implementers or users of this 705 specification can be obtained from the IETF on-line IPR repository at 706 http://www.ietf.org/ipr. 708 The IETF invites any interested party to bring to its attention any 709 copyrights, patents or patent applications, or other proprietary 710 rights that may cover technology that may be required to implement 711 this standard. Please address the information to the IETF at 712 ietf-ipr@ietf.org. 714 Disclaimer of Validity 716 This document and the information contained herein are provided on an 717 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 718 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 719 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 720 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 721 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 722 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 724 Copyright Statement 726 Copyright (C) The Internet Society (2005). This document is subject 727 to the rights, licenses and restrictions contained in BCP 78, and 728 except as set forth therein, the authors retain all their rights. 730 Acknowledgment 732 Funding for the RFC Editor function is currently provided by the 733 Internet Society.