idnits 2.17.1 draft-nystrom-eap-potp-07.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 3692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3682. ** 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 document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (September 26, 2006) is 6415 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2279 (ref. '7') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2806 (ref. '8') (Obsoleted by RFC 3966) ** Obsolete normative reference: RFC 2434 (ref. '9') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '12') (Obsoleted by RFC 5996) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-14 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nystroem 3 Internet-Draft RSA Security 4 Expires: March 30, 2007 September 26, 2006 6 The Protected One-Time Password Protocol (EAP-POTP) 7 draft-nystrom-eap-potp-07 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 March 30, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes a general EAP method suitable for use with 41 One-Time Password (OTP) tokens, and offers particular advantages for 42 tokens with direct electronic interfaces to their associated clients. 43 The method can be used to provide unilateral or mutual 44 authentication, and key material, in protocols utilizing EAP, such as 45 PPP, IEEE 802.1X and IKEv2. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.3. Rationale behind the design . . . . . . . . . . . . . . . 4 53 1.4. Relationship with EAP methods in RFC 3748 . . . . . . . . 5 54 2. Conventions used in this document . . . . . . . . . . . . . . 6 55 3. Authentication model . . . . . . . . . . . . . . . . . . . . . 7 56 4. Description of the EAP-POTP method . . . . . . . . . . . . . . 8 57 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.2. Version negotiation . . . . . . . . . . . . . . . . . . . 11 59 4.3. Cryptographic algorithm negotiation . . . . . . . . . . . 12 60 4.4. Session resumption . . . . . . . . . . . . . . . . . . . . 13 61 4.5. Key derivation and session identifiers . . . . . . . . . . 14 62 4.6. Error handling and result indications . . . . . . . . . . 15 63 4.7. Use of the EAP Notification method . . . . . . . . . . . . 16 64 4.8. Protection against brute-force attacks . . . . . . . . . . 16 65 4.9. MAC calculations in EAP-POTP . . . . . . . . . . . . . . . 17 66 4.10. EAP-POTP packet format . . . . . . . . . . . . . . . . . . 19 67 4.11. EAP-POTP TLV objects . . . . . . . . . . . . . . . . . . . 21 68 4.11.1. Version TLV . . . . . . . . . . . . . . . . . . . . . 21 69 4.11.2. Server-Info TLV . . . . . . . . . . . . . . . . . . . 23 70 4.11.3. OTP TLV . . . . . . . . . . . . . . . . . . . . . . . 25 71 4.11.4. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 34 72 4.11.5. New PIN TLV . . . . . . . . . . . . . . . . . . . . . 36 73 4.11.6. Confirm TLV . . . . . . . . . . . . . . . . . . . . . 38 74 4.11.7. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 42 75 4.11.8. Resume TLV . . . . . . . . . . . . . . . . . . . . . 44 76 4.11.9. User Identifier TLV . . . . . . . . . . . . . . . . . 47 77 4.11.10. Token Key Identifier TLV . . . . . . . . . . . . . . 48 78 4.11.11. Time Stamp TLV . . . . . . . . . . . . . . . . . . . 49 79 4.11.12. Counter TLV . . . . . . . . . . . . . . . . . . . . . 50 80 4.11.13. Challenge TLV . . . . . . . . . . . . . . . . . . . . 51 81 4.11.14. Keep-Alive TLV . . . . . . . . . . . . . . . . . . . 52 82 4.11.15. Protected TLV . . . . . . . . . . . . . . . . . . . . 53 83 4.11.16. Crypto Algorithm TLV . . . . . . . . . . . . . . . . 54 84 5. EAP Key Management Framework considerations . . . . . . . . . 58 85 6. Security considerations . . . . . . . . . . . . . . . . . . . 59 86 6.1. Security claims . . . . . . . . . . . . . . . . . . . . . 59 87 6.2. Passive and active attacks . . . . . . . . . . . . . . . . 59 88 6.3. Denial of service attacks . . . . . . . . . . . . . . . . 61 89 6.4. The use of pepper . . . . . . . . . . . . . . . . . . . . 61 90 6.5. The race attack . . . . . . . . . . . . . . . . . . . . . 61 91 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 63 92 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 63 93 7.2. Cryptographic algorithm identifier octets . . . . . . . . 63 94 8. Intellectual property considerations . . . . . . . . . . . . . 64 95 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 97 10.1. Normative references . . . . . . . . . . . . . . . . . . . 66 98 10.2. Informative references . . . . . . . . . . . . . . . . . . 66 99 Appendix A. Profile of EAP-POTP for RSA SecurID . . . . . . . . . 68 100 Appendix B. Examples of EAP-POTP exchanges . . . . . . . . . . . 69 101 B.1. Basic mode, unilateral authentication . . . . . . . . . . 69 102 B.2. Basic mode, session resumption . . . . . . . . . . . . . . 69 103 B.3. Mutual authentication without session resumption . . . . . 70 104 B.4. Mutual authentication with transfer of pepper . . . . . . 72 105 B.5. Failed mutual authentication . . . . . . . . . . . . . . . 73 106 B.6. Session resumption . . . . . . . . . . . . . . . . . . . . 75 107 B.7. Failed session resumption . . . . . . . . . . . . . . . . 76 108 B.8. Mutual authentication, and new PIN requested. . . . . . . 78 109 B.9. Use of next OTP mode . . . . . . . . . . . . . . . . . . . 81 110 Appendix C. Use of the MPPE-Send/Receive-Key RADIUS attributes . 84 111 C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 84 112 C.2. MPPE key attribute population . . . . . . . . . . . . . . 84 113 Appendix D. Key strength considerations . . . . . . . . . . . . . 85 114 D.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 85 115 D.2. Example 1: 6-digit One-Time Passwords . . . . . . . . . . 85 116 D.3. Example 2: 8-digit One-Time Passwords . . . . . . . . . . 85 117 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 87 118 Intellectual Property and Copyright Statements . . . . . . . . . . 88 120 1. Introduction 122 1.1. Scope 124 This document describes an Extensible Authentication Protocol (EAP) 125 [1] method suitable for use with One-Time Password (OTP) tokens, and 126 offers particular advantages for tokens that are electronically 127 connected to a user's computer, e.g. through a USB interface. The 128 method can be used to provide unilateral or mutual authentication, 129 and key material, in protocols utilizing EAP, such as PPP [10], IEEE 130 802.1X [11] and IKEv2 [12]. 132 1.2. Background 134 A One-Time Password (OTP) token may be a handheld hardware device, a 135 hardware device connected to a personal computer through an 136 electronic interface such as USB, or a software module resident on a 137 personal computer, which generates one-time passwords that may be 138 used to authenticate a user towards some service. This document 139 describes an EAP method intended to meet the needs of organizations 140 wishing to use OTP tokens in an interoperable manner to authenticate 141 users over EAP. The method is designed to be independent of 142 particular OTP algorithms and to meet the requirements on modern EAP 143 methods (see e.g. [13]). 145 The basic variant of this method provides client authentication only. 146 This mode is only to be used within a secured tunnel. A more 147 advanced variant provides mutual authentication, integrity protection 148 of the exchange, protection against eavesdroppers, and establishment 149 of authenticated keying material. Both variants allow for fast 150 session resumption. 152 While this document also includes a profile of the general method for 153 the RSA SecurID(TM) mechanism, it is described in terms of general 154 constructions. It is therefore intended that the document will serve 155 as a framework for use also by other OTP algorithms. 157 Note: The term "OTP" as used herein shall not be confused with the 158 EAP OTP method defined in [1]. 160 1.3. Rationale behind the design 162 EAP-POTP has been designed with the intent that its messages and data 163 elements be easily parsed by EAP implementations. This makes it 164 easier to programmatically use the EAP method in the peer and the 165 authenticator, reducing the need for user interactions and allowing 166 for local generation of user prompts, when needed. In contrast, the 167 Generic Token Card (GTC) method from [1], which uses text strings 168 generated by the EAP server, is intended to be interpreted and acted 169 upon by humans. Furthermore, EAP-POTP allows for mutual 170 authentication and establishment of keying material, which GTC does 171 not. To retain the generic nature of GTC, the EAP-POTP method has 172 been designed to support a wide range of OTP algorithms, with 173 profiling expected for specific such algorithms. This document 174 provides a profile of EAP-POTP for RSA SecurID tokens. 176 1.4. Relationship with EAP methods in RFC 3748 178 The EAP OTP method defined in [1], which builds on [14], is an 179 example of a particular OTP algorithm and is not related to the EAP 180 method defined in this document other than that a profile of EAP-POTP 181 may be created for the OTP algorithm from [14]. 183 The Generic Token Card EAP method defined in [1] is intended to work 184 with a variety of OTP algorithms. The same is true for EAP-POTP, the 185 EAP method defined herein. Advantages of profiling a particular OTP 186 algorithm for use with EAP-POTP compared to using EAP GTC are 187 described in Section 1.3. 189 2. Conventions used in this document 191 The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", 192 "SHOULD NOT", "RECOMMENDED", and "MAY", in this document are to be 193 interpreted as described in RFC 2119 [2]. 195 3. Authentication model 197 The EAP-POTP method provides user authentication as defined below. 198 Additionally, it may provide mutual authentication (authenticating 199 the EAP server to the EAP client) and establish keying material. 201 There are basically three entities in the authentication method 202 described here: 204 o A client, or "peer", using EAP terminology, acting on behalf of a 205 user possessing an OTP token; 207 o A server, or "authenticator", using EAP terminology, to which the 208 user needs to authenticate; and 210 o A backend authentication server, providing an authentication 211 service to the authenticator. 213 The term "EAP server" is used here with the same meaning as in [1]. 214 Any protocol used between the authenticator and the backend 215 authentication server is outside the scope of this document, although 216 RADIUS [15] is a typical choice. It is assumed that the EAP client 217 and the peer are located on the same host, and hence only the term 218 "peer" is used in the following for these entities. 220 The EAP-POTP method assumes the use of a shared secret key, or 221 "seed", which is known both by the user and the backend 222 authentication server. The secret seed is stored on an OTP token 223 that the user possesses, as well as on the authentication server. 225 In its most basic variant, the EAP-POTP method provides only one 226 service, namely user authentication where the user provides 227 information to the authentication server, so that the server can 228 authenticate the user. A more advanced variant provides mutual 229 authentication, protection against eavesdropping and establishment of 230 authenticated keying material. 232 4. Description of the EAP-POTP method 234 4.1. Overview 236 Note: Since the EAP-POTP method is general in nature, the term 237 "POTP-X" is used below as a placeholder for an EAP method type 238 identifier, identifying the use of a particular OTP algorithm with 239 EAP-POTP. As an example, in the case of using RSA SecurID tokens 240 within EAP-POTP, the EAP method type shall be 32 (see Appendix A). 242 A typical EAP-POTP authentication is performed as follows (Appendix B 243 provides more detailed examples): 245 a. The optional EAP Identity Request/Response is exchanged, as per 246 RFC 3748 [1]. An identity provided here may alleviate the need 247 for a "User Identifier" or a "Token Key Identifier" triplet 248 ("TLV") (defined below) later in the exchange. 250 b. The EAP server sends an EAP-Request of type POTP-X with a Version 251 TLV. The Version TLV indicates the highest and lowest version of 252 this method supported by the server. The EAP server typically 253 also includes an OTP TLV in the EAP-Request. The OTP TLV 254 instructs the peer to respond with the current OTP (possibly in 255 protected form), and may contain a challenge and some other 256 information, like server policies. The EAP server should also 257 include a Server-Info TLV in the request, and must do so if it 258 supports session resumption. The Server-Info TLV identifies the 259 authentication server, contains an identifier for this (new) 260 session, and may be used by the peer to find an already existing 261 session with the EAP server. 263 c. The peer responds with an EAP-Response of type Nak (3) if it does 264 not support POTP-X or if it does not support a version of this 265 method that is also supported by the server, as indicated in the 266 server's Version TLV. 268 If the peer supports a version of this method that is also 269 supported by the EAP server, the peer generates an EAP-Response 270 of type POTP-X as follows: 272 * First, it generates a Version TLV which indicates the peer's 273 highest supported version within the range of versions offered 274 by the server. This Version TLV will be part of the EAP- 275 Response to the EAP server. 277 * Next, if the peer's highest supported version equals that of 278 the EAP server, and the EAP server sent a Server-Info TLV, the 279 peer checks if it has a saved session with the EAP server. If 280 an existing session with the server is found, and session 281 resumption is possible (the Server-Info TLV may explicitly 282 disallow it) the peer calculates new session keys (if the 283 session is a protected-mode session) and responds with a 284 Resume TLV and the Version TLV. 286 * Otherwise, if the peer's highest supported version equals that 287 of the EAP server, and the received EAP-Request message 288 contains an OTP TLV, the peer requests (possibly through user 289 interaction) the OTP token to calculate a one-time password 290 based on the information in the received EAP-Request message 291 (which could, for example, carry a challenge), the current 292 token state (e.g. token time), a shared secret (the "seed"), 293 and a user-provided PIN (note that, depending on the OTP token 294 type, some of the information in the EAP-Request may not be 295 used in the OTP calculation, and the PIN may be optional too). 296 If the received OTP TLV has the P bit set (see below), the 297 peer then combines the token-provided OTP with other 298 information, and provides the combined data to a key 299 derivation function. The key derivation function generates 300 several keys, of which one is used to calculate a MAC on the 301 received message together with some other information. The 302 resulting MAC together with some additional information is 303 then placed in an OTP TLV (with the P bit set) that is sent in 304 a response to the EAP server together with the Version TLV. 305 If the P bit is not set in the received OTP TLV, the peer 306 instead inserts the calculated OTP value directly in an OTP 307 TLV, which then is sent to the EAP server together with the 308 Version TLV. 310 * Finally, if the peer's highest supported version differs from 311 the server's, or if the server did not provide any TLVs 312 besides the Version TLV in its initial request, the peer just 313 sends back the generated Version TLV as an EAP-Response to the 314 EAP server. 316 d. If the EAP server receives an EAP-Response of type Nak (3) the 317 session negotiation failed and the EAP server may try with 318 another EAP method. Otherwise, the EAP server checks the peer's 319 supported version. If the peer did not support the highest 320 version supported by the server, the server will send a new EAP- 321 Request with TLVs adjusted for that version. Otherwise, and 322 assuming the EAP server did send additional TLVs in its initial 323 EAP-Request, the EAP server will attempt to authenticate the peer 324 based on the response provided in c). Depending on the result of 325 this authentication, the EAP server may either: 327 * send a new EAP-Request of type POTP-X to the peer indicating 328 that session resumption was not possible, and ask for a new 329 OTP (this would be the case when the peer responded with a 330 Resume TLV and the session indicated in the Resume TLV was not 331 valid), 333 * send a new EAP-Request of type POTP-X to the peer (e.g. to ask 334 for the next OTP), 336 * accept the authentication (and send an EAP-Request message 337 containing a Confirm TLV to the peer if the received response 338 has the P bit set or was a successful attempt at a protected- 339 mode session resumption, or otherwise send an EAP-Success 340 message to the peer), or 342 * fail the authentication (and send an EAP-Failure message - 343 possibly preceded by an EAP-Request message of type 344 Notification (2) - to the peer). 346 e. If the peer receives an EAP-Success or an EAP-Failure message the 347 protocol run is finished. If the peer receives an EAP-Request of 348 type Notification it responds as specified by RFC 3748 [1]. If 349 the peer receives an EAP-Request of type POTP-X with a Confirm 350 TLV it attempts to authenticate the EAP server using the provided 351 data. If the authentication is successful the peer responds with 352 an EAP-Response of type POTP-X with a Confirm TLV. If it is 353 unsuccessful, the peer responds with an empty EAP-Response of 354 type POTP-X. If the peer receives an EAP-Request of type POTP-X 355 containing some other TLVs it continues as specified in c) above 356 (though no version negotiation will take place in this case) or 357 as described for those TLVs. 359 f. When an EAP server, which has sent an EAP-Request of type POTP-X 360 with a Confirm TLV receives an EAP-Response of type POTP-X with a 361 Confirm TLV present, it can proceed in one of two ways: If it has 362 detected that there is a need to send additional EAP-Requests of 363 type POTP-X, it shall enter a "protected state" where from now on 364 all POTP-X TLVs must be encrypted and integrity protected before 365 being sent (at this point the parties shall have calculated a 366 master session key as described in Section 4.5). One reason to 367 continue the POTP-X conversation after exchange of the Confirm 368 TLV could be that the user needs to update her OTP PIN, and hence 369 the EAP server needs to send a New PIN TLV at which point the 370 handshake is back at step c) above (save for the version 371 negotiation and that all TLVs shall be protected). If there is 372 no need to send additional EAP-Request packets, the EAP server 373 shall instead send an EAP-Success method to the peer to indicate 374 successful protocol completion. The EAP server may not continue 375 the conversation unless it indicate its intent to do so in the 376 Confirm TLV. 378 An EAP server, which has sent an EAP-Request of type POTP-X with 379 a Confirm TLV and receives an EAP-Response of type POTP-X which 380 is empty (i.e. does not contain any TLVs), shall respond with an 381 EAP-Failure and terminate the handshake. 383 As implied by the description, steps c) through f) may be carried out 384 a number of times before completion of the exchange. One example of 385 this is when the authentication server initially requests an OTP, 386 accepts the response from the peer, performs an (intermediary) 387 Confirm TLV exchange, requests the peer to select a new PIN, and 388 finally asks the peer to authenticate with an OTP based on the new 389 PIN (which again will be followed with a final Confirm TLV exchange). 391 4.2. Version negotiation 393 The EAP-POTP method provides a version negotiation mechanism that 394 enables implementations to be backward compatible with previous 395 versions of the protocol. This specification documents the EAP-POTP 396 protocol version 1. Version negotiation proceeds as follows: 398 a. In the first EAP-Request of type POTP-X, the EAP server MUST send 399 a Version TLV in which it sets the "Highest supported" version 400 field to its highest supported version number, and the "Lowest 401 supported" version field to its lowest supported version number. 402 The EAP server MAY include other TLV triplets as described below 403 and compatible with the "Highest" supported version number to 404 optimize the number of round-trips in the case of a peer 405 supporting the server's "Highest" version number. 407 b. If the peer supports a version of the protocol that falls within 408 the range of versions indicated by the EAP server, it MUST 409 respond with an EAP-Response of type POTP-X, and containing a 410 Version TLV with the "Highest supported" version field set to the 411 highest version supported by the peer. The peer MUST also 412 respond to any TLV triplets included in the EAP-Request, if it 413 supported the "Highest supported" version indicated in the 414 server's Version TLV. 416 The EAP peer MUST respond with an EAP-Response of type Nak (3) if 417 it does not support a version that falls within the range of 418 versions indicated by the EAP server. This will allow the EAP 419 server to use another EAP method for peer authentication. 421 c. When the EAP server receives an EAP-Response containing a Version 422 TLV from the peer, but the "Highest supported" version field in 423 the TLV differs from the "Highest supported" version field sent 424 by the EAP server, or when the version is the same as the one 425 originally proposed by the EAP server, but the EAP server did not 426 include any TLV triplets in the initial request, the EAP server 427 sends a new EAP-Request of type POTP-X with the negotiated 428 version and TLV triplets as desired and described herein. 430 The version negotiation procedure guarantees that the EAP peer and 431 server will agree to the highest version supported by both parties. 432 If version negotiation fails, use of EAP-POTP will not be possible, 433 and another mutually acceptable EAP method will need to be negotiated 434 if authentication is to proceed. 436 The EAP-POTP version field may be modified in transit by an attacker. 437 It is therefore important that EAP entities only accept EAP-POTP 438 versions according to an explicit policy. 440 4.3. Cryptographic algorithm negotiation 442 Cryptographic algorithms are negotiated through the use of the Crypto 443 Algorithm TLV. EAP-POTP provides a default digest algorithm (SHA- 444 256) [3], a default encryption algorithm (AES-CBC) [4] , and a 445 default MAC algorithm (HMAC) [5], and these algorithms MUST be 446 supported by all EAP-POTP implementations. An EAP server that does 447 not want to make use of any other algorithms than the default ones 448 need not send a Crypto Algorithm TLV. An EAP server that does want 449 to negotiate use of some other algorithms MUST send the Crypto 450 Algorithm TLV in the initial EAP-Request of type POTP-X that also 451 contains an OTP TLV with the P bit set. The TLV MUST NOT be present 452 in any other EAP-Request in the session (the two exception to this 453 are if the client attempted a session resumption which failed and 454 therefore did not evaluate a sent Crypto Algorithm TLV, or if the 455 Crypto Algorithm TLV was part of the initial message from the EAP 456 server and the client negotiated another EAP-POTP version than the 457 highest one supported by the EAP server. When either of these cases 458 apply, the server MUST include the Crypto Algorithm TLV in the first 459 EAP-Request that also contains an OTP TLV with the P bit set 460 subsequent to the failed session resumption/protocol version 461 negotiation). In the Crypto Algorithm TLV, the EAP server suggests 462 some combination of digest, encryption, and MAC algorithms (if the 463 server only wants to negotiate a particular class of algorithms then 464 suggestions for the other classes need not be present, since the 465 default applies). 467 The peer MUST include a Crypto Algorithm TLV in an EAP-Response if 468 and only if an EAP-Request of type POTP-X has been received 469 containing a Crypto Algorithm TLV, it was legal for that EAP-Request 470 to contain a Crypto Algorithm TLV, the peer does not try to resume an 471 existing session, and the peer and the EAP server agrees on at least 472 one algorithm not being the default one. If the peer does not supply 473 a value for a particular class of algorithms in a responding Crypto 474 Algorithm TLV, then the default algorithm applies for that class. 475 When resuming an existing session (see the next Section), there is no 476 need for the peer to negotiate since the session already is 477 associated with a set of algorithms. Servers MUST fail a session 478 (i.e. send an EAP-Failure) if they receive an EAP-Response TLV 479 containing both a Resume TLV and a Crypto Algorithm TLV). 481 Clearly, EAP servers and peers MUST NOT suggest any other algorithms 482 than the ones their policy allows them to use. Policies may also 483 restrict what combinations of cryptographic algorithms are 484 acceptable. 486 4.4. Session resumption 488 This method makes use of session identifiers and server identifiers 489 to allow for improved efficiency in the case where a peer repeatedly 490 attempts to authenticate to an EAP server within a short period of 491 time. This capability is particularly useful for support of wireless 492 roaming. 494 In order to help the peer find a session associated with the EAP 495 server, an EAP server that supports session resumption MUST send a 496 Server-Info TLV containing a server identifier in its initial EAP- 497 Request of type POTP-X that also contains an OTP TLV. The identifier 498 may then be used by the peer for lookup purposes. 500 It is left to the peer whether to attempt to continue a previous 501 session, thus shortening the negotiation, or not. Typically the 502 peer's decision will be made based on the time elapsed since the 503 previous authentication attempt to that EAP server. If the peer 504 decides to attempt to resume a session with the EAP server, it sends 505 a Resume TLV identifying the chosen session and other contents as 506 described below to the EAP server. 508 Based on the session identifier chosen by the peer, and the time 509 elapsed since the previous authentication, the EAP server will decide 510 whether to allow the session resumption, or whether to continue with 511 a new session. 513 o If the EAP server is willing to resume a previously established 514 session, it MUST authenticate the peer based on the contents of 515 the Resume TLV. If the authentication succeeds, the handshake 516 will continue in one of two ways: 518 * If the session is a protected-mode session, then the server 519 MUST respond with a request containing a Confirm TLV. If the 520 Confirm TLV authenticates the EAP server then the peer responds 521 with an empty Confirm TLV, to which the EAP server responds 522 with an EAP-Success message. If the Confirm TLV does not 523 authenticate the EAP server, the peer responds with an empty 524 EAP-Response of type POTP-X. 526 * If the session is not a protected-mode session, i.e. it is a 527 session created from a basic-mode peer authentication, then the 528 server MUST respond with an EAP-Success message. 530 If the authentication of the peer fails, the EAP server SHOULD 531 send another EAP-Request containing an OTP TLV and a Server-Info 532 TLV with the N bit set to indicate that no session resumption is 533 possible. The EAP server MAY also send an EAP-Failure message, 534 possibly preceded by an EAP-Request of type Notification (2), in 535 which case the EAP run will terminate. 537 o If the EAP server is not willing or able to resume a previously 538 established session, it will respond with another EAP-Request 539 containing an OTP TLV and a Server-Info TLV with the N bit set 540 (indicating no session resumption). 542 Sessions SHOULD NOT be maintained longer than the security of the 543 exchange which created the session permits. E.g. if it is estimated 544 that an attacker could be successful in brute-force searching for the 545 OTP in 24 hours, then EAP-POTP session lifetimes should be clearly 546 less than this value. 548 4.5. Key derivation and session identifiers 550 The EAP-POTP method described herein makes use of a key derivation 551 function denoted "PBKDF2". PBKDF2 is described in [6], Section 5.2. 552 The PBKDF2 PRF SHALL be set to the negotiated MAC algorithm. The 553 default MAC algorithm, which MUST be supported, is HMAC-SHA256. HMAC 554 is defined in [5] and SHA-256 is defined in [3]. HMAC-SHA256 is the 555 HMAC construct from [5] with SHA-256 as the hash function H. The 556 output length of HMAC-SHA256 when used as a PRF for PBKDF2 shall be 557 32 octets (i.e. the full output length). 559 The output from PBKDF2 as described here will consist of five keys: 561 o K_MAC, a MAC key used for mutual authentication and integrity 562 protection, 564 o K_ENC, an encryption key used to protect certain data during the 565 authentication, 567 o SRK, a session resumption key only used for session resumption 568 purposes, 570 o MSK, a Master Session Key as defined in [1], and 572 o EMSK, an Extended Master Session Key, also as defined in [1]. 574 For the default algorithms, K_MAC, K_ENC, and SRK SHALL be 16 octets. 575 For other cases, the key lengths will be as determined by the 576 negotiated algorithms. The MSK and the EMSK SHALL each be 64 octets, 577 in conformance with [1]. The "dkLen" parameter from Section 5.2 of 578 [6] SHALL therefore in the case of default algorithms be set to 176 579 (the combined length of K_MAC, K_ENC, SRK, MSK, and EMSK). 581 [1] and [16] define usage of the MSK and the EMSK . For a particular 582 use case, see also Appendix C. 584 4.6. Error handling and result indications 586 EAP does not allow for the sending of an EAP-Response of type Nak (3) 587 within a method after the initial EAP-Request and EAP-Response pair 588 of that particular method has been exchanged (see [1], Section 2.1). 589 Instead, when a peer is unable to continue an EAP-POTP session, the 590 peer MAY respond to an outstanding EAP-Request by sending an empty 591 EAP-Response of type POTP-X rather than immediately terminating the 592 conversation. This allows the EAP server to log the cause of the 593 error. 595 To ensure that the EAP server receives the empty EAP-Response, the 596 peer SHOULD wait for the EAP server to reply before terminating the 597 conversation. The EAP server MUST reply with an EAP-Failure. 599 When EAP-POTP is run in protected mode, the exchange of the Confirm 600 TLV (Section 4.11.6) serves as a success result indication - when the 601 peer receives a Confirm TLV it knows that the EAP server has 602 successfully authenticated it. Similarly, when the EAP server 603 receives the Confirm TLV response from the peer it knows that the 604 peer has authenticated it. In protected mode, the peer will not 605 accept an EAP-Success packet unless it has received and validated a 606 Confirm TLV. The Confirm TLV sent from the EAP server to the peer is 607 a "protected result indication" as defined in [1], as it is integrity 608 protected and cannot be replayed. The Confirm TLV sent from the peer 609 to the EAP server is however not a protected result indication. An 610 empty EAP-POTP response sent from the peer to the EAP server serves 611 as a failure result indication. 613 4.7. Use of the EAP Notification method 615 Except where explicitly allowed in the following, the EAP 616 Notification method MUST NOT be used within an EAP-POTP session. The 617 EAP Notification method MAY be used within an EAP-POTP session in the 618 following situations: 620 o The EAP server MAY send an EAP-Request of type Notification (2) 621 when it has received an EAP-Response containing an OTP TLV and is 622 unable to authenticate the user. In this case, once the EAP- 623 Response of type Notification is received, the EAP server MAY 624 retry the authentication and send a new EAP-Request containing an 625 OTP TLV, or it MAY fail the session and send an EAP-Failure 626 message. 628 o The EAP server MAY send an EAP-Request of type Notification (2) 629 when it has received an unacceptable New PIN TLV. In this case, 630 once the EAP-Response of type Notification is received, the EAP 631 server MAY retry the PIN update and send a new EAP-Request with a 632 New PIN TLV, or it MAY fail the session and send an EAP-Failure 633 message. 635 4.8. Protection against brute-force attacks 637 Since OTPs may be relatively short, it is important to slow down an 638 attacker sufficiently so that it is economically unattractive to 639 brute-force search for an OTP given an observed EAP-POTP handshake in 640 protected mode. One way to do this is to do a high number of 641 iterated hashes in the PBKDF2 function. Another is for the client to 642 include a value ("pepper") unknown to the attacker in the hash 643 computation. Whereas a traditional "salt" value normally is sent in 644 the clear, this "pepper" value will not be sent in the clear, but may 645 instead be transferred to the EAP server in encrypted form. In 646 practice, the procedure is as follows: 648 a. The EAP server indicates in its OTP TLV whether it supports 649 pepper searching. Additionally, it may indicate to the peer that 650 a new pepper shall be chosen. 652 b. If the peer supports the use of pepper, the peer checks whether 653 it already has established a shared pepper with this server: 655 If it does have a pepper stored for this server, and the server 656 did not indicate that a new pepper shall be generated, then it 657 uses the existing pepper value as specified in Section 4.11.3 658 below to calculate an OTP TLV response. In this case the 659 iteration count shall be kept to a minimum as the security of the 660 scheme is provided through the pepper and efficiency otherwise is 661 lost. 663 If the peer does not have a pepper stored for this server, but 664 the server indicated support for pepper searching, or the server 665 indicated that a new pepper shall be generated, then the peer 666 generates a random and uniformly distributed pepper of sufficient 667 length (the maximum length supported by the server is provided in 668 the server's OTP TLV), and includes the new pepper in the PBKDF2 669 computation. 671 If the peer does not have a pepper stored for this server, and 672 the server did not indicate support for pepper searching, then a 673 pepper will not be used in the response computation. 675 Clearly, if the peer itself does not support the use of pepper 676 then a pepper will not be used in the response computation. 678 c. The EAP server may, in its subsequent Confirm TLV, provide a 679 pepper to the peer for later use. In this case, the pepper will 680 be substantially longer than a peer-chosen pepper, and encrypted 681 with a key derived from the PBKDF2 computation. 683 The above procedure allows for pepper updates to be initiated by 684 either side, e.g. based on policy. Since the pepper can be seen as a 685 MAC key, its lifetime should be limited. 687 An EAP server which is not capable of storing pepper values for each 688 user it is authenticating may still support the use of pepper - the 689 cost for this will be the extra computation time to do pepper 690 searches. This cost is still substantially lower than the cost for 691 an attacker, however, since the server already knows the underlying 692 OTP. 694 4.9. MAC calculations in EAP-POTP 696 4.9.1. Introduction 698 In protected mode, EAP-POTP uses MACs for authentication purposes as 699 well as to ensure the integrity of protocol sessions. This section 700 defines how the MACs are calculated and the rationale for the design. 702 4.9.2. MAC calculation 704 In protected mode, and when resuming a previous session, rather than 705 sending authenticating credentials such as one-time passwords or 706 shared keys directly, evidence of knowledge of the credentials is 707 sent. This evidence is a MAC on the hash of (certain parts of) EAP- 708 POTP messages exchanged so far in a session using a key K_MAC: 710 mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n)) 712 where 714 "MAC" is the negotiated MAC algorithm, "K_MAC" is a key derived as 715 specified in Section 4.5, and "msg_hash(msg_1, msg_2, ..., msg_n)" is 716 the message hash defined below of messages msg_1, msg_2, ..., msg_n. 718 4.9.3. Message hash algorithm 720 To compute a message hash for the MAC, given a sequence of EAP 721 messages msg_1, msg_2, ..., msg_n, the following operations shall be 722 carried out: 724 a. Re-transmissions messages are removed from the sequence of 725 messages. 727 b. The contents (i.e. starting with the EAP "Type" field and 728 excluding the EAP "Code", "Identifier", and "Length" fields) of 729 each message msg_1, msg_2, ..., msg_n is concatenated together. 731 c. User identifier TLVs MUST NOT be included in the hash (this is to 732 allow for a back-end service that does not know about individual 733 user names), i.e. any such TLV is removed from the message which 734 it appeared in. 736 d. The resulting string is hashed using the negotiated hash 737 algorithm. 739 4.9.4. Design rationale 741 The reason for excluding the "Identifier" field is that the actual, 742 transmitted, "Identifier" field is not always known to the EAP method 743 layer. The reason for excluding the "Length" field is to allow the 744 possibility for an intermediary to remove or replace a Username TLV 745 (e.g. for anonymity or service reasons) before passing a received 746 response on to an authentication server. While this on the surface 747 may appear as bad security practice, it may in practice only result 748 in denial of service, something which always may be achieved by an 749 attacker able to modify messages in transit. By excluding the "Code" 750 field, the hash is simply calculated on applicable sent and received 751 message contents. Excluding the "Code" field is regarded as harmless 752 since the hash is to be made on the set of POTP-X messages, all 753 having the same (known) Code value. 755 4.9.5. Implementation considerations 757 To save on storage space, each EAP entity may partially hash messages 758 as they are sent and received (e.g. HashInit(); HashUpdate(message 759 1); ...; HashUpdate(message n-1); HashFinal(message n)). This 760 reduces the amount of state needed for this purpose to the internal 761 state required for the negotiated hash algorithm. 763 4.10. EAP-POTP packet format 765 A summary of the EAP-POTP packet format is shown below. The fields 766 are transmitted from left to right. 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Code | Identifier | Length | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Type | Reserved | TLV-based EAP-POTP message ... 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 Code 778 1 - Request 780 2 - Response 782 Identifier 784 The Identifier field is one octet and aids in matching responses 785 with requests. For a more detailed description of this field, and 786 how to use it, see [1]. 788 Length 790 The Length field is two octets and indicates the length of the EAP 791 packet including the Code, Identifier, Length, Type, Version, 792 Flags, and TLV-based EAP-POTP message fields. 794 Type 796 Identifies use of a particular OTP algorithm with EAP-POTP. 798 Reserved 800 This octet is reserved for future use. It SHALL be set to zero 801 for this version. Recipients SHALL ignore this octet for this 802 version of EAP-POTP. 804 TLV-based EAP-POTP message 805 This field will contain 0, 1, or more Type-Length-Value triplets 806 defined as follows (this is similar to the EAP-TLV TLVs defined in 807 PEAPv2 [17], and the explanation of the generic fields is borrowed 808 from that document). 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 |M|R| TLV Type | Length | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Value ... 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 M 820 0 - Non-mandatory TLV 822 1 - Mandatory TLV 824 The TLVs within EAP POTP-X are used to carry parameters between 825 the EAP peer and the EAP server. An EAP peer may not 826 necessarily implement all the TLVs supported by an EAP server, 827 and to allow for interoperability, a special TLV allows an EAP 828 server to discover if a TLV is supported by the EAP peer. 830 The mandatory bit in a TLV indicates that if the peer or server 831 does not support the TLV, it MUST send a NAK TLV in response; 832 and all the other TLVs in the message MUST be ignored. If an 833 EAP peer or server finds an unsupported TLV which is marked as 834 non-mandatory (i.e. optional), it MUST NOT send a NAK TLV on 835 this ground only. 837 The mandatory bit does not imply that the peer or server is 838 required to understand the contents of the TLV. The 839 appropriate response to a supported TLV with content that is 840 not understood is defined by the specification of the 841 particular TLV. 843 R 845 Reserved for future use. This bit SHALL be set to zero (0) for 846 this version. Recipients SHALL ignore this bit for this 847 version of the EAP-POTP. 849 TLV Type 851 The following TLV types are defined for use with EAP-POTP: 853 0 - Reserved for future use 854 1 - Version 855 2 - Server-Info 856 3 - OTP 857 4 - NAK 858 5 - New PIN 859 6 - Confirm 860 7 - Vendor-Specific 861 8 - Resume 862 9 - User Identifier 863 10 - Token Key Identifier 864 11 - Time Stamp 865 12 - Counter 866 13 - Keep-Alive 867 14 - Protected 868 15 - Crypto Algorithm 869 16 - Challenge 871 These TLVs are defined in the following. With the exception of 872 the NAK TLV, a particular TLV type MUST NOT appear more than 873 once in a message of type POTP-X. 875 Length 877 The length of the Value field in octets. 879 Value 881 The value of the TLV. 883 4.11. EAP-POTP TLV objects 885 4.11.1. Version TLV 887 The Version TLV carries information about the supported EAP-POTP 888 method version. 890 This TLV MUST be present in the initial EAP-Request of type POTP-X 891 from the EAP server and in the initial response of type POTP-X from 892 the peer. It MUST NOT be present in any subsequent EAP-Request or 893 EAP-Response in the session. The Version TLV MUST be supported by 894 all peers and all EAP servers conforming to this specification and 895 MUST NOT be responded to with a NAK TLV. The version negotiation 896 procedure is described in detail in Section 4.2 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 |M|R| TLV Type | Length | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Reserved | Highest | Lowest | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 M 907 1 - Mandatory TLV 909 R 911 Reserved for future use. This bit SHALL be set to zero (0) for 912 this version. Recipients SHALL ignore this bit for this version 913 of EAP-POTP. 915 TLV Type 917 1 919 Length 921 3 in EAP-Requests, 2 in EAP-Responses 923 Reserved 925 Reserved for future use. This octet MUST be set to zero for this 926 version. Recipients SHALL ignore this octet for this version of 927 EAP-POTP. 929 Highest 931 This field SHALL be interpreted as an unsigned integer in network 932 byte order representing the highest protocol version supported by 933 the sender. If a value provided by a peer to an EAP server falls 934 between the server's "Highest" and "Lowest" supported version 935 (inclusive) then that value will be the negotiated version for the 936 authentication session. 938 Lowest 940 This field SHALL be interpreted as an unsigned integer in network 941 byte order representing the lowest version acceptable by the EAP 942 server. The field MUST be present in an EAP-Request. The field 943 MUST NOT be present in an EAP-Response. A peer SHALL respond to 944 an EAP-Request of type POTP-X with an EAP-Response of type Nak (3) 945 if the peer's highest supported version is lower than the value of 946 this field. 948 This document defines version 1 of the protocol. EAP server 949 implementations conforming to this document SHALL therefore set the 950 Highest field to 1. Peer implementations conforming to this document 951 SHALL set the Highest field to 1. 953 4.11.2. Server-Info TLV 955 The Server-Info TLV carries information about the EAP server and the 956 session (when applicable). It provides one piece in the framework 957 for fast session resumption. 959 This TLV SHOULD always be present in an EAP-Request of type POTP-X 960 that also carries an OTP TLV, as long as the peer has not been 961 authenticated, and MUST be present in such a request if the server 962 supports session resumption. It MUST NOT be present in any other 963 EAP-Request of type POTP-X or in any EAP-Response packets. This TLV 964 type MUST be supported by all peers conforming to this specification 965 and MUST NOT be responded to with a NAK TLV (this is not to say that 966 all peers need to support session resumption, only that they cannot 967 respond to this TLV with a NAK TLV). 969 0 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 |M|R| TLV Type | Length | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Reserved |N| Session Identifier | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Session Identifier (continued) | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 |Sess.Id (cont.)| Nonce ... (16 octets) 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Server Identifier ... 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 M 985 1 - Mandatory TLV 987 R 989 Reserved for future use. This bit SHALL be set to zero (0) for 990 this version. Recipients SHALL ignore this bit for this version 991 of EAP-POTP. 993 TLV Type 995 2 997 Length 999 >25 1001 Reserved 1003 Reserved for future use. All 7 bits MUST be set to zero for this 1004 version. Recipients SHALL ignore this bit for this version of 1005 EAP-POTP. 1007 N 1009 The N bit signals that the peer MUST NOT attempt to resume any 1010 session it has stored associated with this server. 1012 Session Identifier 1014 An eight-octet identifier for the session about to be negotiated. 1015 Note that, in the case of session resumption, this session 1016 identifier will not be used (the session identifier for the 1017 resumed session will continue to be used). 1019 Nonce 1021 A sixteen-octet nonce chosen by the server. During session 1022 resumption, this nonce is used when calculating new K_ENC, K_MAC, 1023 SRK, MSK, and EMSK keys as specified below. 1025 Server Identifier 1027 An identifier for the authentication server. The peer MAY use 1028 this identifier to search for a stored session associated with 1029 this server, or to associate the session to be negotiated with the 1030 server. The value of the identifier SHOULD be chosen so as to 1031 reduce the risk of collisions with other EAP server identifiers as 1032 much as possible. One possibility is to use the DNS name of the 1033 EAP server. The identifier MAY also be used by the peer to select 1034 a suitable key on the OTP token (when there are multiple keys 1035 available). 1037 The identifier MUST NOT be longer than 128 octets. The identifier 1038 SHALL be a UTF-8 [7] encoded string of printable characters 1039 (without any terminating NULL character). 1041 4.11.3. OTP TLV 1043 In an EAP-Request, the OTP TLV is used to request an OTP (or a value 1044 derived from an OTP) from the peer. In an EAP-Response, the OTP TLV 1045 carries an OTP or a value derived from an OTP. 1047 This TLV type MUST be supported by all peers and all EAP servers 1048 conforming to this specification and MUST NOT be responded to with a 1049 NAK TLV. The OTP TLV MUST NOT be present in an EAP-Request of type 1050 POTP-X which contains a New PIN TLV. Further, the OTP TLV MUST NOT 1051 be present in an EAP-Response of type POTP-X unless the preceding 1052 EAP-Request of type POTP-X contained an OTP TLV and it was valid for 1053 it to do so. Finally, an OTP TLV MUST NOT be present in an EAP- 1054 Response of type POTP-X that also contains a Resume TLV. The OTP TLV 1055 is defined as follows: 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 |M|R| TLV Type | Length | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Reserved |A|P|C|N|T|E|R| Pepper Length |Iteration Count| 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Iteration Count (cont.) | Auth. Data | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Authentication Data (cont.) ... 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 M 1071 1 - Mandatory TLV 1073 R 1075 Reserved for future use. This bit SHALL be set to zero (0) for 1076 this version. Recipients SHALL ignore this bit for this version 1077 of EAP-POTP. 1079 TLV Type 1081 3 1083 Length 1085 7 + length of Authentication Data field 1087 Reserved 1088 Reserved for future use. All nine bits SHALL be set to zero (0) 1089 for this version. Recipients SHALL ignore these bits for this 1090 version of EAP-POTP. 1092 A 1094 The A bit MUST be set in an EAP-Request if and only if the request 1095 immediately follows an EAP-Response of type POTP-X containing a 1096 New PIN TLV (see Section 4.11.5), and the new PIN in the response 1097 was accepted by the EAP server. In this case, the A bit signals 1098 that the EAP-server has accepted the PIN, and that the peer SHALL 1099 use the newly established PIN when calculating the response (when 1100 applicable). The A bit MUST NOT be set if the R bit is set. A 1101 peer SHALL regard a request where both the R bit and the A bit is 1102 set as invalid and return an empty POTP-X EAP-Response message. 1104 In an EAP-Response, the A bit, when set, indicates that the OTP 1105 was calculated with the use of the newly selected user PIN. The A 1106 bit MUST be set in a response if and only if the EAP-Request which 1107 triggered the response contained an OTP TLV with the A bit set. 1109 P 1111 In an EAP-Request, the P bit indicates that the OTP in the 1112 response MUST be protected. Use of this bit also indicates that 1113 mutual authentication will take place as well as generation of 1114 keying material. It is RECOMMENDED to always set the P bit. If a 1115 peer receives an EAP-Request with an OTP TLV that does not have 1116 the P bit set, and the peer's policy dictates protected mode, the 1117 peer MUST respond with an empty POTP-X EAP-Response message. All 1118 peers MUST support protected mode. 1120 In an EAP-Response, this bit indicates that the provided OTP has 1121 been protected (see below). The P bit MUST be set in a response 1122 (and hence the OTP MUST be protected) if and only if the EAP- 1123 Request which triggered the response contained an OTP TLV with the 1124 P bit set. 1126 In an 802.1x EAP over LAN (EAPOL) environment (this includes 1127 wireless LAN environments), the P bit MUST be set, or, 1128 alternatively, the EAP-POTP method MUST be carried out inside an 1129 authenticated tunnel that provides a cryptographic binding with 1130 inner EAP methods such as the one provided by PEAPv2 ([17]). 1132 C 1133 The C bit carries meaning only when the OTP algorithm in question 1134 makes use of server challenges. For other OTP algorithms, the C 1135 bit SHALL always be set to zero. 1137 In an EAP-Request, the C bit ("Combine") indicates that the OTP 1138 SHALL be calculated using both the provided challenge and internal 1139 state (e.g. current token time). The OTP SHALL be calculated 1140 based only on the provided challenge (and the shared secret) if 1141 the C bit is not set and a challenge is present. The returned OTP 1142 SHALL always be calculated based on the peer's current state (and 1143 the shared secret) if no challenge is present. If the C bit is 1144 set but no challenge is provided, the peer SHALL regard the 1145 request as invalid, and return an empty POTP-X EAP-Response 1146 message. 1148 In an EAP response, this bit indicates that the provided OTP has 1149 been calculated using a provided challenge and the token state. 1150 The C bit MUST be set in a response if and only if the EAP-Request 1151 which triggered the response contained an OTP TLV with the C bit 1152 set and a challenge. 1154 N 1156 In an EAP-Request, the N bit, when set, indicates that the OTP to 1157 calculate SHALL be based on the next token "state", and not the 1158 current one. As an example, for a time-based token, this means 1159 the next time slot. For an event-based token, this could mean the 1160 next counter value, if counter values are used. This bit will 1161 normally not be set in initial EAP-Request messages, but may be 1162 set in subsequent ones. Further, the N bit carries no meaning in 1163 an EAP-Request if a challenge is present and the C bit is not set, 1164 and SHALL be set to 0 in this case. A peer SHALL regard a request 1165 containing a challenge and where the N bit is set but not the C 1166 bit as invalid, and return an empty POTP-X EAP-Response message. 1167 Note that setting the N bit in an EAP-Request will normally 1168 advance the internal state of the token. 1170 In an EAP-Response, the N bit, when set, indicates that the OTP 1171 was calculated based on the next token "state" (as explained 1172 above), and not the current one. The N bit MUST be set in a 1173 response if and only if the EAP-Request which triggered the 1174 response contained an OTP TLV with the N bit set. 1176 T 1178 The T bit only carries meaning for OTP methods normally 1179 incorporating a user PIN in the OTP computation. 1181 In an EAP-Request, the T bit, when set, indicates that the OTP to 1182 calculate MUST NOT include a user PIN. 1184 In an EAP-Response, the T bit, when set, indicates that the OTP 1185 was calculated without the use of a user PIN. The T bit MUST be 1186 set in a response if and only if the EAP-Request which triggered 1187 the response contained an OTP TLV with the T bit set. Note that 1188 client policy may prohibit PIN-less calculations and in these 1189 cases the client MAY respond with an empty POTP-X EAP response 1190 message. 1192 E 1194 In an EAP-Request, the E bit, when set, indicates that the peer 1195 MUST NOT use any stored pepper value associated with this server 1196 in the PBKDF2 computation. Rather, it MUST generate a new pepper 1197 (if supported by the peer) and/or use the iteration count 1198 parameter to protect the OTP (if the server's Max Pepper Length is 1199 0, then the peer MUST rely on the iteration count only to protect 1200 the OTP). This bit will usually not be set in initial EAP-Request 1201 messages, but may be set in subsequent ones, e.g. if the server 1202 upon receipt of an OTP TLV with a pepper identifier detects that 1203 it does not have a pepper with that identifier in storage. This 1204 bit carries no meaning, and MUST be set to zero, when the P bit is 1205 not set. A peer SHALL regard a request where the E bit is set but 1206 not the P bit as invalid, and return an empty POTP-X EAP-Response 1207 message. 1209 In an EAP-Response, the E bit indicates that the response has been 1210 calculated without use of any stored pepper value. 1212 R 1214 In an EAP-Request, the R bit ("Repeat"), when set, indicates that 1215 the peer SHOULD calculate its response based on the same OTP value 1216 as was used for the preceding response. This bit MAY be set when 1217 the EAP server has received an OTP TLV from the peer protected 1218 with a pepper which the server no longer is in possession of. 1219 Since the server has not attempted validation of the provided 1220 data, there is no need for the EAP peer to retrieve a new OTP 1221 value. This bit carries no meaning, and MUST be set to zero, when 1222 the E bit is not set. A peer SHALL regard a request where the R 1223 bit is set but not the E bit as invalid, and return an empty 1224 POTP-X EAP-Response message. Further, the R bit MUST NOT be set 1225 when the A bit also is set, see above. 1227 In an EAP-Response, the R bit is never set. 1229 Pepper Length 1231 This octet SHALL be present if and only if the P bit is set. When 1232 present, it SHALL be interpreted as an unsigned integer in 1233 network-byte order, having a value between 0...255 (inclusive). 1234 In an EAP-Request, the integer represents the maximum length (in 1235 bits) of a client-generated pepper the server is prepared to 1236 search for. Peers MUST NOT generate peppers longer than this 1237 value. If the value is set to zero, it means the peer MUST NOT 1238 generate a pepper for the PBKDF2 calculation. In an EAP-Response, 1239 it indicates the length of the used pepper. 1241 Iteration Count 1243 These four octets SHALL be present if and only if the P bit is 1244 set. When present, they SHALL be interpreted as an unsigned, 1245 four-octet integer in network-byte order. In an EAP-Request, the 1246 integer represents the maximum iteration count the peer may use in 1247 the PBKDF2 computation. Peers MUST NOT use iteration counts 1248 higher than this value. In an EAP-Response, it indicates the 1249 actual iteration count used. 1251 Note regarding the Pepper Length and Iteration Count parameters: A 1252 peer MUST compare these policy parameters provided by the EAP server 1253 with local policy and MUST NOT continue the handshake if use of the 1254 EAP server's suggested parameters would result in a lower security 1255 than the client's acceptable policy. If the security given by the 1256 EAP server's provided policy parameters surpasses the security level 1257 given by the peer's local policy the client SHOULD use the server's 1258 parameters (subject to reason - active attackers could otherwise 1259 mount simple denial-of-service attacks against peers or servers, e.g. 1260 by providing unreasonably high values for the iteration count). Note 1261 that the server-provided parameters only applies to the case where 1262 the peer cannot use or does not have a previously provided server- 1263 provided pepper. If a peer cannot continue the handshake due to the 1264 server's policy being unacceptable, it MUST return an empty POTP-X 1265 EAP-Response message. 1267 Authentication Data 1269 EAP-Request: In an EAP-Request, the Authentication Data, when 1270 present, contains an optional "challenge". The challenge is an 1271 optional octet string that SHOULD be uniquely generated for each 1272 request it is present in (i.e. it is a "nonce"), and SHOULD be 1273 eight octets or longer when present. To avoid fragmentation (i.e. 1274 EAP messages longer than the minimum EAP MTU size, see [1]), the 1275 challenge MUST NOT be longer than 64 octets. When the challenge 1276 is not present, the OTP will be calculated on the current token 1277 state only. The peer MAY ignore a provided challenge if and only 1278 if the OTP token the peer is interacting with is not capable of 1279 including a challenge in the OTP calculation. In this case, EAP 1280 server policies will determine whether to accept a provided OTP 1281 value or not. 1283 EAP-Response: The following applies to the Authentication Data field 1284 in an EAP-Response: 1286 * When the P bit is not set, the peer SHALL directly place the 1287 OTP value calculated by the token in the Authentication Data 1288 field. In this case, the EAP server MUST NOT send a Confirm 1289 TLV upon successful authentication of the peer (instead, it 1290 sends an EAP-Success message). 1292 * When the P bit is set, the peer SHALL populate this field as 1293 follows. After the token has calculated the OTP value, the 1294 peer SHALL compute: 1296 K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(otp, salt | pepper 1297 | auth_id, iteration_count, key_length) 1299 where 1301 "|" denotes concatenation, 1303 "otp" is the already computed OTP value, 1305 "salt" is a sixteen-octet nonce, 1307 "pepper" is an optional nonce (at most 255 bits long, and if 1308 necessary padded to be a multiple of 8 bits long, see below) 1309 included to complicate the task of finding a matching "otp" 1310 value for an attacker, 1312 "auth_id" is an identifier (at most 255 octets in length) 1313 for the authenticator (i.e. the network access server) as 1314 reported by lower layers and as specified below, 1316 "iteration_count" is an iteration count chosen such that the 1317 computation time on the peer is acceptable (based on the 1318 server's indicated policy and the peer's local policy), 1319 while an attacker, having observed the response and 1320 initiating a search for a matching OTP will be sufficiently 1321 slowed down. The "iteration_count" value MUST be chosen to 1322 provide a suitable level of protection (e.g. at least 1323 100,000) unless a server-provided pepper is being used, in 1324 which case it SHOULD be 1. 1326 "key_length" is the combined length of the desired key 1327 material, in octets. When default algorithms are used, 1328 key_length SHALL be 176. 1330 The "pepper" values are only included in PBKDF2 calculations 1331 and are never sent to EAP servers (though the peers do send 1332 their length, in bits). The purpose of the pepper values 1333 are, as mentioned above, to slow down an attacker's search 1334 for a matching OTP, while not slowing down the peer (which 1335 iterated hashes do). If the pepper has been generated by 1336 the peer and the chosen pepper length in bits is not a 1337 multiple of 8 then the pepper value SHALL be padded to the 1338 left with '0' bits to the nearest multiple of 8 before being 1339 used in the PBKDF2 calculation. This is to ensure the input 1340 to the calculation consists only of whole octets. As an 1341 example, if the chosen pepper length is four, the pepper 1342 value will be padded to the left with four '0' bits to form 1343 an octet before being used in the PBKDF2 calculation. 1345 When pepper is used, it is RECOMMENDED that the length of 1346 the pepper and the iteration count are chosen in such a way 1347 that it is computationally infeasible/unattractive for an 1348 attacker to brute-force search for the given OTP within 1349 lifetime of that OTP. 1351 As mentioned previously, a peer MUST NOT include a newly 1352 generated pepper value in the PBKDF2 computation if the 1353 server did not indicate its support for pepper searching in 1354 this session. If the server did not indicate support for 1355 pepper searching, then the PBKDF2 computation MUST be 1356 carried out with a sufficiently higher number of iterations 1357 so as to compensate for the lack of pepper (see further 1358 Appendix D). 1360 A server may, in an earlier session, have transferred a 1361 pepper value to the peer in a Confirm TLV (see below). When 1362 this is the case, and the peer still has that pepper value 1363 stored for this server, the peer MUST NOT generate a new 1364 pepper but MUST instead use this transferred pepper value in 1365 the PBKDF2 calculations. The only exception to this is when 1366 a local policy (e.g. timer) dictates that the peer must 1367 switch to a new pepper (and the server indicated support for 1368 pepper searching). 1370 The following applies to the auth_id component: 1372 - For dial-up, "auth_id" SHALL either be the empty string 1373 or the phone number called by the peer. The phone number 1374 SHALL be specified in the form of a URL conformant with 1375 RFC 2806 ([8]), e.g. "tel:+16175550101". Processing of 1376 received phone numbers SHALL be conformant with RFC 2806 1377 (this assumes that "tel" URIs will be shorter than 256 1378 octets, which would normally be the case). 1380 - For use with IEEE 802.1X, "auth_id" SHALL either be the 1381 empty string or the MAC address of the authenticator in 1382 binary format (six octets). 1384 - For IP-based EAP, "auth_id" SHALL either be the empty 1385 string or the IPv4 or IPv6 address of the authenticator 1386 as seen by the peer and in binary format (4 respectively 1387 16 octets). As an example, the IPv4 address "192.0.2.5" 1388 would be represented as (in hex) C0 00 02 05, whereas the 1389 IPv6 address "2001:DB8::101" would be represented as (in 1390 hex) 20 01 0D B8 00 00 00 00 00 00 00 00 00 00 01 01. 1392 Note: Use of the authenticator's identifying information 1393 within the computation aids in protection against man-in- 1394 the-middle attacks where a rogue authenticator seeks to 1395 intercept and forward the Authentication Data in order to 1396 impersonate the peer at a legitimate authenticator (but see 1397 also the discussion around spoofed authenticator addresses 1398 in Section 6). For these reasons, a peer SHOULD NOT set the 1399 auth_id component to the empty string unless it is unable to 1400 learn the identifying information of the authenticator. In 1401 these cases, the EAP server's policy will determine whether 1402 the session may continue or not. 1404 As an example, when otp = "12345678", salt = 1405 0x54434534543445435465768789099880, pepper is not used, 1406 auth_id = "192.0.2.5", iteration_count = 2000, and 1407 key_length = 176, the input to the PBKDF2 calculation will 1408 be (first two parameters in hex, line wrap for readability): 1410 (3132333435363738, 54434534543445435465768789099880 | 1411 c0000205, 2000, 176) 1413 As described, when the default algorithms are used, K_MAC is 1414 the first 16 octets of the output from PBKDF2, K_ENC the 1415 next 16 octets, MSK the following 64 octets, EMSK the next 1416 64 octets, and SRK the final 16 octets. Using K_MAC, the 1417 peer calculates: 1419 mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n)) 1420 as specified in Section 4.9 and where msg_1, msg_2, ..., 1421 msg_n is a sequence of all EAP messages of type POTP-X 1422 exchanged so far in this session, as sent and received by 1423 the peer (for the peer's initial MAC it will typically be 1424 just one message, the EAP server's initial EAP-Request of 1425 type POTP-X). 1427 The peer then places the first 16 octets of "mac" in the 1428 Authentication Data field, followed by the "salt" value, 1429 followed by one octet representing the length of the 1430 "auth_id" value in octets, followed by the actual "auth_id" 1431 value in binary form, optionally followed by a pepper 1432 identifier (only when the peer made use of a pepper value 1433 previously provided by the EAP server). Pepper identifiers, 1434 when present, are always four octets. All variables SHALL 1435 be present in the form they were input to the PBKDF2 1436 algorithm. This will result in the Authentication Data 1437 field being 33 + (length of auth_id in octets) + (4, for 1438 pepper identifier, when present) octets in length. 1440 Continuing the previous example, the Authentication Data 1441 field will be populated with (in hex, line wrap for 1442 readability): 1444 < 16 octets of mac > | 54434534543445435465768789099880 | 04 1445 | c0000205 1447 Note: Since in this case (i.e. when the P bit is set) 1448 successful authentication of the peer by the EAP server will 1449 be followed by the transmission of an EAP-Request of type 1450 POTP-X containing a Confirm TLV for mutual authentication, 1451 the peer MUST save either all the input parameters to the 1452 PBKDF2 computation or the keys K_MAC, K_ENC, SRK, MSK, and 1453 EMSK (recommended, since they will be used later). This is 1454 because the peer cannot be guaranteed to be able to generate 1455 the same OTP value again. For the same reason (the Confirm- 1456 TLV from the EAP server), the peer MUST also store either 1457 the hash of the contents of the sent EAP-Response or the 1458 EAP-Response itself (but see the note above about not 1459 including any User Identifier TLVs in the hash computation). 1461 Given a set of possible OTP values, the authentication 1462 server verifies an authentication request from the peer by 1463 computing 1465 K_MAC' | K_ENC' | MSK' | EMSK' | SRK' = PBKDF2(otp', salt | 1466 pepper' | auth_id, iteration_count, 176) 1467 for each possible OTP value otp', and each possible pepper 1468 value pepper' and the provided values for salt, 1469 authenticator identity, and iteration count. Note that the 1470 EAP server may accept more than one OTP value at a given 1471 time, e.g. due to clock drift in the token. If the given 1472 pepper length is not a multiple of eight, each tested pepper 1473 value will be padded to the left to the nearest multiple of 1474 eight, in the same manner as was done by the peer. If the 1475 server already shares a secret pepper value with this peer 1476 then obviously there will only be one possible pepper value, 1477 and the server will find it based on the pepper_identifier 1478 provided by the peer. The server SHALL send a new EAP- 1479 Request of type POTP-X with an OTP TLV with the E bit set if 1480 the peer provided a pepper identifier unknown to the server. 1482 For each K_MAC', the EAP server computes 1484 mac' = MAC(K_MAC', msg_hash(msg_1', msg_2', ..., msg_n')) 1486 where MAC is the negotiated MAC algorithm, msg_hash is the 1487 message hash algorithm defined in Section 4.9, and msg_1', 1488 msg_2', ... msg_n' are the same messages as the peer 1489 calculated its message hash on, but this time as sent and 1490 received by the EAP server. If the first 16 octets of mac' 1491 matches the first 16 octets in the Authentication Data field 1492 of the EAP-Response in question, and the provided 1493 authenticator identity is acceptable (e.g. matches the EAP 1494 server's view of the authenticator's identity) then the peer 1495 is authenticated. 1497 If the authentication was successful, the authentication 1498 server then attempts to authenticate itself to the peer by 1499 use of the Confirm TLV (see below). If the authentication 1500 fails, the EAP server MAY send another EAP-Request of type 1501 POTP-X containing an OTP TLV to the peer, or it MAY send an 1502 EAP-Failure message (in both cases possibly preceded by an 1503 EAP-Request of type Notification). 1505 4.11.4. NAK TLV 1507 Presence of this TLV indicates that the peer did not support a 1508 received TLV with the M bit set. This TLV may occur 0, 1, or more 1509 times in an EAP-Response of type POTP-X. Each occurrence flags the 1510 non-support of a particular received TLV. 1512 The NAK TLV MUST be supported by all peers and all EAP servers 1513 conforming to this specification and MUST NOT be responded to with a 1514 NAK TLV. Receipt of a NAK TLV by an EAP server MAY cause an 1515 authentication to fail, and the EAP server to send an EAP-Failure 1516 message to the peer. 1518 Note: The definition of the NAK TLV herein matches the definition 1519 made in [17], and has the same type number. Field descriptions are 1520 copied from that document, with some minor modifications. 1522 0 1 2 3 1523 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 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 |M|R| TLV Type | Length | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | Vendor-Id | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | NAK-Type | TLVs ... 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 M 1534 1 - Mandatory TLV 1536 R 1538 Reserved for future use. This bit SHALL be set to zero (0) for 1539 this version. Recipients SHALL ignore this bit for this version 1540 of EAP-POTP. 1542 TLV Type 1544 4 1546 Length 1548 >= 6 1550 Vendor-Id 1552 The Vendor-Id field is four octets, and contains the Vendor-Id of 1553 the TLV that was not supported. The high-order octet is 0 and the 1554 low-order 3 octets are the SMI Network Management Private 1555 Enterprise Code of the Vendor in network byte order. The 1556 Vendor-Id field MUST be zero for TLVs that are not Vendor-Specific 1557 TLVs. For Vendor-Specific TLVs, the Vendor-ID MUST be set to the 1558 SMI code. 1560 NAK-Type 1561 The type of the unsupported TLV. The TLV MUST have been included 1562 in the most recently received EAP message. 1564 TLVs 1566 This field contains a list of TLVs, each of which MUST NOT have 1567 the mandatory bit set. These optional TLVs can be used in the 1568 future to communicate why the offending TLV was determined to be 1569 unsupported. 1571 4.11.5. New PIN TLV 1573 In an EAP-Request, the New PIN TLV is used to request a new user PIN 1574 from the peer. The EAP server MAY provide a new PIN as described 1575 below. In an EAP-Response, the New PIN TLV carries a chosen new user 1576 PIN. This TLV may be used by an EAP server when policy dictates that 1577 the peer (user) needs to change a PIN associated with the OTP Token. 1579 This TLV type SHOULD be supported by peers and EAP servers conforming 1580 to this specification. The New PIN TLV MUST NOT be sent by an EAP 1581 server unless the peer has been authenticated. If the peer was 1582 authenticated in protected mode, then the New PIN TLV MUST NOT be 1583 present in an EAP-Request until after the exchange of the Confirm TLV 1584 (i.e. until after mutual authentication has occurred and keys are in 1585 place to protect the TLV). The New PIN TLV MUST be sent by a peer if 1586 and only if the EAP-Request which triggered the response contained a 1587 New PIN TLV, it was valid for the EAP server to send such a TLV in 1588 that request, and the TLV is supported by the peer. 1590 0 1 2 3 1591 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 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 |M|R| TLV Type | Length | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Reserved |Q|A| PIN Length | PIN ... 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 |Min. PIN Length|Max. PIN Length| 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 M 1602 1 - Mandatory TLV 1604 R 1606 Reserved for future use. This bit SHALL be set to zero (0) for 1607 this version. Recipients SHALL ignore this bit for this version 1608 of EAP-POTP. 1610 TLV Type 1612 5 1614 Length 1616 >=2 (the PIN may or may not be present.) 1618 Reserved 1620 Reserved for future use. All six bits SHALL be set to zero for 1621 this version. Recipients SHALL ignore these bits for this version 1622 of EAP-POTP. 1624 Q 1626 The Q bit, when set in an EAP-Request, indicates that an 1627 accompanying PIN is required, i.e. the peer (user) is not free to 1628 choose another PIN. When the Q bit is set, there MUST be an 1629 accompanying PIN and the provided PIN MUST be used in subsequent 1630 OTP generations. A peer SHALL respond with an empty POTP-X EAP- 1631 Response message if the Q bit is set but there is not any 1632 accompanying PIN. When the Q bit is not set, any provided PIN is 1633 suggested only, and the peer is free to choose another PIN, 1634 subject to local policy. 1636 The Q bit carries no meaning, and SHALL be set to zero, in an EAP- 1637 Response. 1639 A 1641 This bit allows methods that distinguish between two different PIN 1642 types (e.g., decimal vs. alphanumeric) to designate whether the 1643 augmented set is to be used (when set) or not (when not set). The 1644 A bit carries no meaning, and SHALL be set to zero, in an EAP- 1645 Response. 1647 PIN Length 1649 This field SHALL be interpreted as an unsigned integer in network 1650 byte order representing the length of the provided PIN (this 1651 implies that the maximum length of a PIN will be 255 octets). 1653 PIN 1655 In an EAP-Request, subject to the setting of the Q bit, the PIN 1656 field MAY be empty. If empty, the peer (user) will need to choose 1657 a PIN subject to local and (any) provided policy. When the PIN 1658 field is not empty, it MUST consist of UTF-8 encoded printable 1659 characters without a terminating NULL character. 1661 In an EAP-Response, the PIN value SHALL consist of a UTF-8 encoded 1662 string of printable characters without a terminating NULL 1663 character. 1665 The peer accepts a PIN suggested by the EAP server by replying 1666 with the same PIN, but MAY replace it with another one, depending 1667 on the server's setting of the Q bit. The length of the PIN is 1668 application-dependent as are any other requirements for the PIN, 1669 e.g., allowed characters. The peer MUST be prepared to receive a 1670 repeated request for a new PIN as described above if the EAP 1671 server for some reason does not accept the received PIN. Such a 1672 request MAY be preceded by an EAP-Request of type Notification (2) 1673 providing information to the user about the reason for the 1674 rejection. Mechanisms for transferring knowledge about PIN 1675 requirements from the EAP server to the peer (beyond those 1676 specified for this TLV, such as maximal and minimal PIN length) 1677 are outside the scope of this document. However, some information 1678 MAY be provided in notification messages transferred from the EAP 1679 server to the peer as per above. 1681 Min. PIN Length 1683 This field MAY be present in an EAP-Request. This field MUST NOT 1684 be present in an EAP-Response. It SHALL be interpreted as an 1685 unsigned integer in network byte order representing the minimum 1686 length allowed for a new PIN. 1688 Max. PIN Length 1690 This field MUST NOT be present in an EAP-Request unless the Min. 1691 PIN Length field is present, in which case it MAY be present. The 1692 field MUST NOT be present in an EAP-Response. It SHALL be 1693 interpreted as an unsigned integer in network byte order 1694 representing the maximum length allowed for a new PIN. The value 1695 of this field, when present, MUST be equal to, or larger, than the 1696 value of the Min. PIN Length field. 1698 4.11.6. Confirm TLV 1700 Presence of this TLV in a request indicates that the EAP server has 1701 successfully authenticated the peer and now attempts to authenticate 1702 itself to the peer. Presence of this TLV in a response indicates 1703 that the peer successfully authenticated the EAP server, and that 1704 calculated keys (K_MAC, K_ENC, MSK, EMSK, and SRK) now become 1705 available for use. 1707 The Confirm TLV MUST NOT appear together with any other TLV in an 1708 EAP-Request message of type POTP-X and MUST NOT be sent unless the 1709 peer has been authenticated through an OTP TLV with the P bit set or 1710 through a Resume TLV for which the underlying session was established 1711 in protected mode. The Confirm TLV MUST be present in an EAP- 1712 Response if and only if the request that triggered the response 1713 contained a Confirm TLV, it was legal for it to do so, and the 1714 Confirm TLV authenticated the EAP server to the peer. If the peer 1715 was not able to authenticate the server, then it MUST send an empty 1716 (i.e. no TLVs present) EAP-Response of type POTP-X. 1718 An EAP server MUST send an EAP-Success message after receiving an 1719 EAP-Response of type POTP-X containing a valid Confirm TLV, sent in 1720 response to an EAP-Request containing a Confirm TLV where the C bit 1721 was not set. A peer MUST NOT accept an EAP-Success message when it 1722 has sent an OTP TLV with the P bit set unless it has received an 1723 acceptable Confirm TLV from the EAP server. 1725 This TLV type MUST be supported by all peers and EAP servers 1726 conforming to this specification and MUST NOT be responded to with a 1727 NAK TLV. 1729 0 1 2 3 1730 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 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 |M|R| TLV Type | Length | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Reserved |C| Authentication Data ... (16 octets) 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Pepper Identifier | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | IV ... 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | Encrypted Pepper ... (16 octets) 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 M 1745 1 - Mandatory TLV 1747 R 1749 Reserved for future use. This bit SHALL be set to zero (0) for 1750 this version. Recipients SHALL ignore this bit for this version 1751 of EAP-POTP. 1753 TLV Type 1754 6 1756 Length 1758 17 or 37 + length of IV in requests, 1 in responses. 1760 Reserved 1762 Reserved for future use. These seven bits SHALL be set to zero 1763 (0) for this version. Recipients SHALL ignore these bits for this 1764 version of EAP-POTP. 1766 C 1768 The C bit, when set in an EAP-Request, indicates that the EAP 1769 server intends to send more EAP-Requests of type POTP-X in this 1770 session, after receipt of a Confirm TLV from the peer. 1772 The C bit carries no meaning in EAP-Responses, and MUST NOT be set 1773 within them. 1775 Note: An EAP-Response containing a Confirm TLV, sent in response 1776 to an EAP-Request containing a Confirm TLV that did not have the C 1777 bit set, MUST be followed by an EAP-Success message from the EAP 1778 server concluding the handshake. The response MAY however be 1779 followed by another EAP-Request from the EAP server, containing 1780 e.g. a New PIN TLV (wrapped in a Protected TLV), if the C bit was 1781 set in the EAP-Request. Therefore, peers MUST NOT assume that the 1782 only EAP message following an EAP-Response of type POTP-X 1783 containing a Confirm TLV is EAP-Success. The C bit gives EAP 1784 servers a way to indicate their intent to follow the Confirm TLV 1785 with more requests, and allows the peer's state machine to adapt 1786 to this. 1788 Authentication Data 1790 EAP-Request: 1792 In a request, this field consists of the first 16 octets of 1793 (see also Section 4.11.3): 1795 mac_a = MAC(K_MAC', msg_hash(trig_msg)) 1797 where 1798 MAC is the negotiated MAC algorithm, 1800 "K_MAC'" has been calculated as described in Section 4.11.3 or 1801 (in the case of session resumption) Section 4.11.8, and 1803 "msg_hash" is the message hash algorithm defined in 1804 Section 4.9, and "trig_msg" the latest EAP-Response of type 1805 POTP-X received from the peer (the one which triggered this 1806 request). 1808 Given a saved or recomputed value for K_MAC, the peer 1809 authenticates the EAP server by computing 1811 mac'' = MAC(K_MAC, msg_hash(trig_msg')) 1813 where "msg_hash(trig_msg')" is the peer's hash of the same EAP- 1814 Response as the EAP server calculated its message hash on, but 1815 this time as it was sent by the peer. If the first 16 octets 1816 of mac'' matches the first 16 octets in the Authentication Data 1817 field of the EAP-Request in question, then the EAP server is 1818 authenticated. 1820 EAP-Response: 1822 Not used in this version, and SHALL NOT be present in EAP- 1823 Responses. 1825 Pepper Identifier 1827 In an EAP-Request, the truncated MAC MAY optionally be followed by 1828 an encrypted pepper and its identifier. This initial, four-octet 1829 field identifies a pepper generated by the server. 1831 For this version of EAP-POTP, this field SHALL NOT be present in 1832 EAP-Responses. 1834 IV (Initialization Vector) 1836 An initialization vector for the encryption. The length of the 1837 vector is dependent on the negotiated encryption algorithm. E.g. 1838 for AES-CBC it SHALL be 16 octets. The IV is only present if a 1839 pepper is present and the negotiated encryption algorithm makes 1840 use of IVs. This field SHALL NOT be present in EAP-Response 1841 messages for this version of EAP-POTP. 1843 Encrypted Pepper 1844 When present in an EAP-Request, this will be a uniformly 1845 distributed and randomly chosen sixteen-octet pepper generated by 1846 the EAP server and encrypted with the negotiated encryption 1847 algorithm, using K_ENC as the encryption key and possibly 1848 (depending on the encryption algorithm) using an IV (stored in the 1849 IV field). This field MUST be present if and only if the Pepper 1850 Identifier field is present. 1852 EAP servers are RECOMMENDED to include a freshly generated 1853 encrypted pepper (and a corresponding Pepper Identifier) in every 1854 Confirm TLV. 1856 This field SHALL NOT be present in EAP-Response messages for this 1857 version of EAP-POTP. 1859 When a new pepper was generated by the server and transferred in 1860 encrypted form to the peer, then this new pepper value will be stored 1861 in the EAP server upon receipt of the Confirm TLV from the peer, and 1862 SHOULD be stored with its identifier and associated with the EAP 1863 server and the current user in the peer upon receipt of the EAP- 1864 Success message. If the peer already had a pepper stored for the EAP 1865 server it SHALL replace it with the newly received one. 1867 4.11.7. Vendor-Specific TLV 1869 The Vendor-Specific TLV is available to allow vendors to support 1870 their own extended attributes not suitable for general usage. A 1871 Vendor-Specific-TLV can contain one or more inner TLVs, referred to 1872 as Vendor TLVs. The TLV-type of a Vendor-TLV will be defined by the 1873 vendor. All the Vendor TLVs inside a single Vendor-Specific TLV 1874 SHALL belong to the same vendor. 1876 This TLV type MAY be sent by EAP servers as well as by peers and MUST 1877 be supported by all entities conforming to this specification. 1878 Conforming implementations may not support specific Vendor TLVs 1879 inside a Vendor-Specific TLV however, and MAY in this case respond to 1880 the Vendor TLVs with a NAK TLV containing the appropriate Vendor-ID 1881 and Vendor TLV type. 1883 The presence of a Vendor-Specific TLV in an EAP-Request or EAP- 1884 Response of type POTP-X MUST NOT violate any existing rules for co- 1885 existence of TLVs in such requests or responses. If it does, then it 1886 will result in an EAP-Failure (when the peer made the violation) or 1887 an empty EAP-POTP response (when the EAP-server made the violation). 1888 It is left to the definition of specific Vendor-Specific TLVs to 1889 further constrain when they are allowed to appear. In particular, 1890 EAP-POTP implementations may have policies that completely disallow 1891 use of the Vendor-Specific TLV before protected mode mutual 1892 authentication has occurred (since the Protected TLV, Section 4.11.15 1893 then can be used to protect all TLVs). 1895 Note: This TLV type has the same definition and TLV type number as 1896 the Vendor-Specific TLV in [17], and the description of it is largely 1897 borrowed from that document. 1899 0 1 2 3 1900 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 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 |M|R| TLV Type | Length | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | Vendor-Id | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Vendor TLVs ... 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 M 1911 1 - Mandatory TLV 1913 R 1915 Reserved for future use. This bit SHALL be set to zero (0) for 1916 this version. Recipients SHALL ignore this bit for this version 1917 of EAP-POTP. 1919 TLV Type 1921 7 1923 Length 1925 >4 1927 Vendor-ID 1929 The Vendor-Id field is four octets. The high-order octet SHALL be 1930 set to 0 and the low-order 3 octets SHALL be set to the SMI 1931 Network Management Private Enterprise Code (see [18]) of the 1932 Vendor in network byte order. The Vendor-Id MUST be zero for TLVs 1933 that are not Vendor-Specific TLVs. For Vendor-Specific TLVs, the 1934 Vendor-ID MUST be set to the SMI code. 1936 Vendor TLVs 1937 This field shall contain vendor-specific TLVs, in a format defined 1938 by the vendor. To avoid fragmentation (i.e. EAP messages longer 1939 than the minimum EAP MTU size), the field SHOULD NOT be longer 1940 than 256 octets. 1942 To ensure interoperability when a peer from vendor A sends a vendor- 1943 specific TLV that is not understood by the recipient, the vendor A 1944 peer SHALL, upon receipt of the NAK TLV from the recipient, refrain 1945 from usage of the vendor-specific TLV in question for the rest of the 1946 handshake, and MUST NOT fail the session due to the receipt of the 1947 NAK TLV for the Vendor TLV (i.e., the peer SHALL continue as if the 1948 vendor-specific TLV had not been sent). Additionally, all 1949 implementations conformant with this document SHOULD allow use of 1950 vendor-specific extensions to be turned off via configuration. 1952 4.11.8. Resume TLV 1954 The Resume TLV MAY be sent by a peer to an authentication server to 1955 attempt session resumption. 1957 This TLV type MUST only be sent in response to an EAP-Request of type 1958 POTP-X containing a Server-Info TLV allowing session resumption. The 1959 Resume TLV MUST be supported by all EAP servers that send a Server- 1960 Info TLV allowing session resumption. 1962 0 1 2 3 1963 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 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 |M|R| TLV Type | Length | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | Reserved | Session Identifier | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | Session Identifier (continued) | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 |Sess.Id (cont.)| Authentication Data | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | Authentication Data (cont.) ... 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 M 1978 0 - Non-mandatory TLV 1980 R 1982 Reserved for future use. This bit SHALL be set to zero (0) for 1983 this version. Recipients SHALL ignore this bit for this version 1984 of EAP-POTP. 1986 TLV Type 1988 8 1990 Length 1992 45 1994 Reserved 1996 Reserved for future use. This octet SHALL be set to zero (0) for 1997 this version. Recipients SHALL ignore this octet for this version 1998 of EAP-POTP. 2000 Session Identifier 2002 An eight-octet identifier for the session the peer is trying to 2003 resume. 2005 Authentication Data 2007 Upon receipt of the Server-Info TLV, and if the N bit is not set, 2008 the peer searches for any stored sessions associated with the 2009 server identified by the Server Name field. If a stored session 2010 is found, the peer generates a random, sixteen-octet nonce, 2011 "c_nonce", and calculates: 2013 K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(base_key, c_nonce | 2014 s_nonce, iteration_count, key_length) 2016 where 2018 "|" denotes concatenation, 2020 "base_key" is either the current SRK for the session (if the 2021 session was created in protected mode) or the OTP used when the 2022 session was created (if the session was created in basic mode), 2024 "c_nonce" is the generated 16-octet nonce, 2026 "s_nonce" the server nonce from the Server-Info TLV, 2028 "iteration_count" is the iteration count as determined by local 2029 policy, and 2031 "key_length" is the combined length of the desired key material, 2032 in octets. When default algorithms are being used, key_length 2033 SHALL be 176. 2035 The iteration count need only be 1 (one) when resuming a session 2036 established in protected mode, but MUST be chosen to provide a 2037 suitable level of protection when resuming a session established 2038 in basic mode (see also Section 4.11.3). 2040 Note: Session resumption for basic mode MUST only be carried out 2041 in a server-authenticated and protected tunnel that also provides 2042 a cryptographic binding for inner EAP methods. 2044 The peer then calculates: 2046 MAC = MAC(K_MAC, msg_hash(resume_req)) 2048 where 2050 "MAC" is the negotiated MAC algorithm, and 2052 "msg_hash(resume_req) is the message hash algorithm defined in 2053 Section 4.9 applied on resume_req, the EAP server's EAP-Request of 2054 type POTP-X containing the Server-Info TLV which allowed session 2055 resumption. 2057 The peer then places the first 16 octets of the MAC followed by 2058 the c_nonce value followed by the iteration count value (as a 2059 4-byte unsigned integer in network byte order) in the 2060 Authentication Data field. As an example, when c_nonce = 2061 0x2b3b1b12babdebebfb43bd7bdfbeb8df and iteration_count = 1, the 2062 Authentication Data field will be populated with (in hex, line 2063 wrap for readability): 2065 < 16 octets of mac > | 2b3b1b12babdebebfb43bd7bdfbeb8df | 00000001 2067 The server authenticates the peer by performing the corresponding 2068 calculations. If the authentication is successful, the server 2069 MUST send an EAP-Request of type POTP-X containing a Confirm TLV 2070 to the peer. If the authentication fails, the server MUST send 2071 either an EAP-Request of type POTP-X containing an OTP TLV and a 2072 Server-Info TLV where the Server-Info TLV indicates that session 2073 resumption is not possible, or send an EAP-Failure. 2075 When resuming in basic mode, all calculated keys SHALL be 2076 discarded after the MAC has been calculated and verified. When 2077 resuming in protected mode, the new SRK will replace the stored 2078 SRK, and the new MSK and EMSK will be exported upon successful 2079 completion of the method. 2081 4.11.9. User Identifier TLV 2083 The User Identifier TLV carries an identifier, typically the 2084 username, for the holder of the OTP token used to generate the OTP. 2086 At least one of the User Identifier TLV and the Token Key Identifier 2087 TLV SHOULD be present in the session's first EAP-Response of type 2088 POTP-X that also carries an OTP TLV unless a suitable identity has 2089 been provided in a preceding EAP-Response of type Identity (1) or is 2090 determined by some other means (see [1], Section 2). Use of the User 2091 Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED 2092 even when an EAP-Response of type Identity (1) has been sent. If a 2093 peer sends both a User Identifier TLV and a Token Key Identifier TLV 2094 then the EAP server SHALL interpret the Token Key Identifier TLV as 2095 specifying a particular token key for the given user. The EAP server 2096 MUST respond with an EAP-Failure if it cannot find a token key for 2097 the provided user. 2099 This TLV type is sent by peers and MUST be supported by all EAP 2100 servers conforming to this specification. The User Identifier TLV 2101 MUST NOT be present in a response that does not also carry an OTP 2102 TLV. 2104 0 1 2 3 2105 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 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 |M|R| TLV Type | Length | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | User Identifier ... 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 M 2114 1 - Mandatory TLV 2116 R 2118 Reserved for future use. This bit SHALL be set to zero (0) for 2119 this version. Recipients SHALL ignore this bit for this version 2120 of EAP-POTP. 2122 TLV Type 2124 9 2126 Length 2127 >=1 2129 User Identifier 2131 The value SHALL be an UTF-8 encoded string representing the holder 2132 of the token (MUST NOT be NULL-terminated). The string MUST be 2133 less than 128 octets in length. 2135 4.11.10. Token Key Identifier TLV 2137 The Token Key Identifier TLV carries an identifier for the token key 2138 used to generate the OTP. 2140 At least one of the User Identifier TLV and the Token Key Identifier 2141 TLV SHOULD be present in the session's first EAP-Response of type 2142 POTP-X which also carries the OTP TLV unless a suitable identity has 2143 been provided in a preceding EAP-Response of type Identity (1) or is 2144 determined by some other means (see [1], Section 2). Use of the User 2145 Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED 2146 even when an EAP-Response of type Identity (1) has been sent. If a 2147 peer sends both a User Identifier TLV and a Token Key Identifier TLV 2148 then the EAP server SHALL interpret the Token Key Identifier TLV as 2149 specifying a particular token key for the given user. The EAP server 2150 MUST respond with an EAP-Failure if it cannot find a token key 2151 corresponding to the provided token key identifier. 2153 This TLV type is sent by peers and MUST be supported by all EAP 2154 servers conforming to this specification. The Token Key Identifier 2155 TLV MUST NOT be present in a response that does not also carry an OTP 2156 TLV. 2158 0 1 2 3 2159 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 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 |M|R| TLV Type | Length | 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 | Token Key Identifier ... 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 M 2168 1 - Mandatory TLV 2170 R 2172 Reserved for future use. This bit SHALL be set to zero (0) for 2173 this version. Recipients SHALL ignore this bit for this version 2174 of EAP-POTP. 2176 TLV Type 2178 10 2180 Length 2182 >=1 2184 Token Key Identifier 2186 An identifier for the OTP token key used to generate the OTP. The 2187 field MUST be less than 128 octets in length. 2189 4.11.11. Time Stamp TLV 2191 The Time Stamp TLV MAY be sent by peers to simplify authentications. 2192 When present, it carries the time as reported by the OTP Token. 2194 An EAP server conformant with this specification SHOULD support (i.e. 2195 recognize) this TLV, but need not be able to process or act on it. 2196 An EAP server that does not support this TLV but receives an EAP- 2197 Response with the TLV present MAY ignore the value. The Time Stamp 2198 TLV MUST NOT be present in any EAP-Responses of type POTP-X other 2199 than those that also carries an OTP TLV. 2201 0 1 2 3 2202 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 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 |M|R| TLV Type | Length | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 | Time Stamp ... 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 M 2211 0 - Non-mandatory TLV 2213 R 2215 Reserved for future use. This bit SHALL be set to zero (0) for 2216 this version. Recipients SHALL ignore this bit for this version 2217 of EAP-POTP. 2219 TLV Type 2221 11 2223 Length 2224 >= 20 (depending on precision) 2226 Time Stamp 2228 The time, as reported by the OTP token, at which the OTP used for 2229 the accompanying OTP TLV was calculated. The field SHALL contain 2230 a UTF-8 encoded value of the XML simple type "dateTime" with time 2231 zone information and precision down to at least seconds. E.g. 2232 "2004-06-16T15:20:02Z". 2234 4.11.12. Counter TLV 2236 The Counter TLV MAY be sent by peers to simplify authentications. 2237 When present, it carries the token counter value, as reported by the 2238 OTP Token. 2240 An EAP server conformant with this specification SHOULD support (i.e. 2241 recognize) this TLV, but need not be able to process or act on it. 2242 An EAP server that does not support this TLV but receives an EAP- 2243 Response with the TLV present MAY ignore the value. The Counter TLV 2244 MUST NOT be present in any EAP-Responses of type POTP-X other than 2245 those that also carries an OTP TLV. 2247 0 1 2 3 2248 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 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 |M|R| TLV Type | Length | 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 | Counter ... 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2255 M 2257 0 - Non-mandatory TLV 2259 R 2261 Reserved for future use. This bit SHALL be set to zero (0) for 2262 this version. Recipients SHALL ignore this bit for this version 2263 of EAP-POTP. 2265 TLV Type 2267 12 2269 Length 2270 >= 1 (depending on precision) 2272 Counter 2274 The counter value, as reported by the OTP token, at which the OTP 2275 used for the accompanying OTP TLV was calculated. The counter 2276 value SHALL be represented as an unsigned integer in network-byte 2277 order. E.g. a counter value of 1030 may be sent as the two octets 2278 (in hex) 04 06. 2280 4.11.13. Challenge TLV 2282 The Challenge TLV carries the challenge used by the token to 2283 calculate the OTP, as reported by the token to the peer. In The 2284 Challenge TLV MUST be sent by a peer if and only if the challenge 2285 otherwise would be unknown to the EAP server (e.g. the token or peer 2286 modified a received challenge or generated its own challenge). 2288 An EAP server conformant with this specification SHOULD support (i.e. 2289 recognize) this TLV, but need not be able to process or act on it. 2290 An EAP server that does not support this TLV but receives an EAP- 2291 Response with the TLV present MAY ignore the value. The Challenge 2292 TLV MUST NOT be present in any EAP-Responses of type POTP-X other 2293 than those that also carries an OTP TLV. 2295 0 1 2 3 2296 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 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 |M|R| TLV Type | Length | 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | Challenge ... 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 M 2305 0 - Non-mandatory TLV 2307 R 2309 Reserved for future use. This bit SHALL be set to zero (0) for 2310 this version. Recipients SHALL ignore this bit for this version 2311 of EAP-POTP. 2313 TLV Type 2315 16 2317 Length 2318 >= 1 2320 Challenge 2322 The challenge value that was used to calculate the OTP used for 2323 the accompanying OTP TLV. 2325 4.11.14. Keep-Alive TLV 2327 The Keep-Alive is used to avoid EAP-POTP timeouts. 2329 The Keep-Alive TLV MAY be sent by a peer to avoid time-outs when the 2330 peer has received an EAP-Request containing an OTP TLV or a New PIN 2331 TLV and is waiting for a response from the user. 2333 An EAP-Request containing a Keep-Alive TLV MUST be sent by an EAP 2334 server when the server receives an EAP-Response containing a Keep- 2335 Alive TLV, and the server has an outstanding request which did not 2336 contain a Keep-Alive TLV. In this situation, the server does not 2337 need to re-transmit its latest outstanding request, but due to the 2338 synchronous nature of EAP it needs to send another request. Re- 2339 transmission of the latest outstanding request could be confusing for 2340 the peer since the request would get a new Identifier value. The 2341 Keep-Alive TLV MAY also be sent by an EAP server when the server 2342 detects that its processing time will exceed some locally configured 2343 threshold and may cause a network timeout. In this case, the peer 2344 MUST respond with an EAP-Response containing a Keep-Alive TLV. 2346 This TLV type MUST be supported by all peers and all EAP servers 2347 conforming to this specification and MUST NOT be responded to with a 2348 NAK TLV. The Keep-Alive TLV MUST NOT be sent in any other situations 2349 than the ones described above. The Keep-Alive TLV MUST NOT be sent 2350 together with any other TLVs defined herein. Implementations SHOULD 2351 also follow recommendations made in Section 4.3 of [1]. 2353 0 1 2 3 2354 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 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 |M|R| TLV Type | Length | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 M 2361 1 - Mandatory TLV 2363 R 2364 Reserved for future use. This bit SHALL be set to zero (0) for 2365 this version. Recipients SHALL ignore this bit for this version 2366 of EAP-POTP. 2368 TLV Type 2370 13 2372 Length 2374 0 2376 4.11.15. Protected TLV 2378 The Protected TLV SHALL be used to encrypt individual or multiple 2379 TLVs after successful exchange of the Confirm TLV (i.e. as soon as 2380 calculated keys have been confirmed). The Protected TLV therefore 2381 wraps "ordinary" TLVs. 2383 This TLV type may be sent by EAP servers as well as by peers and MUST 2384 be supported by all peers conforming to this specification. It 2385 SHOULD be supported by all EAP servers conforming to this 2386 specification (it need not be supported if a server never will have a 2387 need to continue a POTP-X conversation after exchange of the Confirm 2388 TLV). 2390 0 1 2 3 2391 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 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 |M|R| TLV Type | Length | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | Message Authentication Code ... (16 octets) 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | IV ... 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Encrypted TLVs ... 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 M 2404 1 - Mandatory TLV 2406 R 2408 Reserved for future use. This bit SHALL be set to zero (0) for 2409 this version. Recipients SHALL ignore this bit for this version 2410 of EAP-POTP. 2412 TLV Type 2414 14 2416 Length 2418 >32 2420 Message Authentication Code (MAC) 2422 This field integrity-protects the TLV. The MAC SHALL be 2423 calculated over the IV and the Encrypted TLVs field in the 2424 following manner: 2426 mac = MAC(K_MAC, iv | encrypted_tlvs) 2428 where 2430 MAC is the negotiated MAC algorithm, "iv" is the IV field's value, 2431 and "encrypted_tlvs" is the value of the Encrypted TLVs field. 2432 The first 16 octets of the MAC is placed in the Message 2433 Authentication Code field. 2435 Recipients MUST verify the MAC. If the verification fails, the 2436 conversation SHALL be terminated (i.e. peers send an empty POTP-X 2437 EAP-Response message, EAP servers send an EAP-Failure message 2438 possibly preceded by an EAP-Request of type Notification). 2440 IV 2442 An initialization vector for the encryption, see below. The 2443 length of the vector is dependent on the negotiated encryption 2444 algorithm. E.g. for AES-CBC it shall be 16 octets. For some 2445 encryption algorithms there may not be any initialization vector. 2446 IVs, when present, shall be randomly chosen and non-predictable. 2448 Encrypted TLVs 2450 This field SHALL contain one or more encrypted POTP-X TLVs. The 2451 encryption algorithm SHALL be as negotiated, use K_ENC as the 2452 encryption key, and use the IV field as the initialization vector 2453 (when applicable). 2455 4.11.16. Crypto Algorithm TLV 2457 The Crypto Algorithm TLV allows for negotiation of cryptographic 2458 algorithms. Cryptographic Algorithm negotiation is described in 2459 detail in Section 4.3. 2461 This TLV MUST be present in the initial EAP-Request of type POTP-X 2462 that also carries an OTP TLV indicating protected mode, assuming the 2463 EAP server wants to negotiate use of any other algorithms than the 2464 default ones. It MAY also be present in an EAP-Request of type 2465 POTP-X that carries an OTP TLV that is sent as a result of a failed 2466 session resumption (in this case, the peer has not yet responded to 2467 this TLV), or when the Crypto Algorithm TLV was part of the initial 2468 message from the EAP server and the client negotiated another EAP- 2469 POTP version than the highest one supported by the EAP server. The 2470 Crypto Algorithm TLV MUST NOT be present in any other EAP-Requests. 2471 Further, the Crypto Algorithm TLV MUST NOT be present in an EAP- 2472 Response of type POTP-X unless the preceding EAP-Request also 2473 contained it and it was legal for it to do so. This TLV MUST be 2474 supported by all peers and all EAP servers conforming to this 2475 specification and MUST NOT be responded to with a NAK TLV. 2477 0 1 2 3 2478 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 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 |M|R| TLV Type | Length | 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 | Reserved |Hash Alg.Length| Hash Algorithms ... 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 |Encr.Alg.Length| Encryption Algorithms ... 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 |MAC Alg. Length| MAC Algorithms ... 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 M 2491 1 - Mandatory TLV 2493 R 2495 Reserved for future use. This bit SHALL be set to zero (0) for 2496 this version. Recipients SHALL ignore this bit for this version 2497 of EAP-POTP. 2499 TLV Type 2501 15 2503 Length 2505 >=4 (at least one class of algorithms and one algorithm for that 2506 class needs to be present) 2508 Reserved 2509 Reserved for future use. This octet MUST be set to zero for this 2510 version. Recipients SHALL ignore this octet for this version of 2511 EAP-POTP. 2513 Hash Alg. Length 2515 The length of the Hash Algorithms field in octets. 2517 Hash Algorithms 2519 Each octet pair of this field represents a hash algorithm as 2520 follows. An EAP server MAY supply several suggestions for hash 2521 algorithms. Each algorithm MUST appear only once. The algorithms 2522 SHALL be supplied in order of priority. Peers MUST supply at most 2523 one algorithm (if none is present the default applies). The 2524 defined values are: 2526 Value Hash algorithm 2527 ------------------------------ 2528 0x00 0x00 Reserved 2529 0x00 0x01 SHA-1 2530 0x00 0x02 SHA-224 2531 0x00 0x03 SHA-256 (default) 2532 0x00 0x04 SHA-384 2533 0x00 0x05 SHA-512 2534 0x80 - Vendor-specific (or experimental) 2536 As indicated, values 0x8000 and higher are for proprietary vendor- 2537 specific algorithms. Values in the range 0x0006 - 0x7fff are to 2538 be assigned through IANA, see Section 7. 2540 Encr Alg. Length 2542 The length of the Encryption Algorithms field in bytes. 2544 Encryption Algorithms 2546 Each octet pair of this field represents an encryption algorithm 2547 as follows. An EAP server MAY supply several suggestions for 2548 encryption algorithms. Each algorithm MUST appear only once. The 2549 algorithms SHALL be supplied in order of priority. Peers MUST 2550 supply at most one algorithm (if none is present the default 2551 applies). The defined values are: 2553 Value Encryption algorithm 2554 ------------------------------ 2555 0x00 0x00 Reserved 2556 0x00 0x01 AES-CBC (default) with 128-bit keys and 16-octet IVs 2557 0x00 0x02 3DES-CBC with 112-bit keys and 8-octet IVs 2558 0x80 - Vendor-specific 2560 As indicated, values 0x8000 and higher are for vendor-specific 2561 proprietary algorithms. Values in the range 0x0003 - 0x7fff are 2562 to be assigned through IANA, see Section 7. 2564 MAC Alg. Length 2566 The length of the MAC Algorithms field in bytes. 2568 MAC Algorithms 2570 Each octet pair of this field represents a MAC algorithm as 2571 follows. An EAP server MAY supply several suggestions for MAC 2572 algorithms. Each algorithm MUST appear only once. The algorithms 2573 SHALL be supplied in order of priority. Peers MUST supply at most 2574 one algorithm (if none is present the default applies). The 2575 defined values are: 2577 Oct.1 Oct.2 MAC Algorithm 2578 ------------------------------ 2579 0x00 0x00 Reserved 2580 0x00 0x01 HMAC (default) 2581 0x80 - Vendor-specific 2583 As indicated, values 0x8000 and higher are for vendor-specific 2584 proprietary algorithms. Values in the range 0x0002 - 0x7fff are 2585 to be assigned through IANA, see Section 7. 2587 When HMAC is negotiated, the hash algorithm used for HMAC SHALL be 2588 the negotiated hash algorithm. 2590 5. EAP Key Management Framework considerations 2592 In line with recommendations made in [16], EAP-POTP defines the 2593 following identifiers to be associated with generated key material: 2595 Peer-ID: The combined contents of the User Identifier TLV and the 2596 Token Key Identifier TLV. 2598 Server-ID: The contents of the Server Identifier field of the 2599 Server-Info TLV. 2601 Method-ID: The identifier of the established session (i.e. the 2602 contents of the Session Identifier field of the Server-Info TLV 2603 that defined the session). 2605 6. Security considerations 2607 6.1. Security claims 2609 In conformance with RFC 3748 [1], the following security claims are 2610 made for the EAP-POTP method: 2612 Authentication mechanism: Generic OTP 2613 Ciphersuite negotiation: Yes (No in basic variant) 2614 Mutual authentication: Yes (No in basic variant) 2615 Integrity protection: Yes (No in basic variant) 2616 Replay protection: Yes (see below) 2617 Confidentiality: Only in the OTP protection variant, and 2618 then only OTP values and any information 2619 sent after exchange of the Confirm TLV 2620 Key derivation: Yes (No in basic variant) 2621 Key strength: Depends on size of OTP value, strength of 2622 underlying shared secret, strength and 2623 characteristics of OTP algorithm, pepper 2624 length, iteration count, and whether the 2625 method is used within a tunnel such as 2626 PEAPv2. For some illustrative examples, 2627 and a further discussion of this, see 2628 Appendix D. 2629 Dictionary attack prot.: N/A (Human-selected passwords not used) 2630 Fast reconnect: Yes 2631 Crypt. binding: N/A (EAP-POTP is not a tunnel method) 2632 Session independence: Yes 2633 Fragmentation: N/A (Packets shall not exceed MTU of 1020) 2634 Channel binding: Yes (No in basic variant) 2635 Acknowledged S/F: Yes 2636 State Synchronization: Yes (No in basic variant) 2638 6.2. Passive and active attacks 2640 The basic variant (i.e. when the protection of OTPs and mutual 2641 authentication is not used) of this EAP method does not provide 2642 session privacy, session integrity, server authentication or 2643 protection from active attacks. In particular, man-in-the-middle 2644 attacks, where an attacker acts as an authenticator in order to 2645 acquire a valid OTP are possible. 2647 Similarly, the basic variant of this EAP method does not protect 2648 against session hijacking taking place after authentication. Nor 2649 does it in itself protect against replay attacks, where the attacker 2650 gains access by replaying a previous, valid request, but see also the 2651 next subsection. When PIN codes are transmitted, they are sent 2652 without protection and are also subject to replay attacks. 2654 In order to protect against these attacks, the peer MUST only use the 2655 basic variant of this method over a server-authenticated and 2656 confidentiality-protected connection. This can be achieved via use 2657 of, e.g., PEAPv2 [17]. 2659 When the OTP protection variant is used however, the EAP method 2660 provides privacy for OTPs and new PINs, negotiation of cryptographic 2661 algorithms, mutual authentication, and protection against replay 2662 attacks and protocol version downgrades. It also provides protection 2663 against man-in-the-middle attacks, not due to the infeasibility for a 2664 man-in-the-middle to solve for a valid OTP given an OTP TLV, but due 2665 to the computational expense of finding the OTP in the limited time 2666 period during which it is valid (this is mainly true for tokens 2667 including the current time in their OTP calculations or when a sent 2668 challenge has a certain lifetime). It should be noted, however, that 2669 a retrieved OTP, even if "old" and invalid, still may divulge some 2670 information about the user's PIN. Clearly this is also true for the 2671 basic variant. Implementations of this EAP method where user PINs 2672 are sent with OTPs are therefore RECOMMENDED to ensure regular user 2673 PIN changes, regardless of whether the protected variant or the basic 2674 variant is employed. 2676 It should also be noted, that while it is possible for a rogue access 2677 point e.g. to clone MAC addresses, and hence mount a man-in-the- 2678 middle attack, such an access point will not be able to calculate the 2679 session keys MSK and EMSK. This demonstrates the importance of using 2680 the derived key material properly to protect a subsequent session. 2682 Protected mode protects against version downgrade attacks due to the 2683 HMAC both parties transmit in this mode. As described, each party 2684 calculates the HMAC on sent and received EAP-POTP handshake messages. 2685 If an attacker were to modify a Version TLV, this would be reflected 2686 in a difference between the calculated MACs (since the recipient of 2687 the Version TLV received a different value than the sender sent). 2688 Unless the attacker knows K_MAC, he cannot calculate the correct MAC, 2689 and hence the difference will be detected. 2691 The OTP protection variant also protects against session hijacking, 2692 if the derived key material is used (directly or indirectly) to 2693 protect a subsequent session. For these reasons, use of the OTP 2694 protection variant is RECOMMENDED. 2696 It should be noted that not even the OTP protection variant provides 2697 privacy for user names and/or token key identifiers however. EAP- 2698 POTP MUST be used within a secure tunnel such as the one provided by 2699 PEAPv2 ([17]) if privacy for these parameters is required. 2701 When resuming sessions created in the basic variant (which MUST only 2702 take place within a protected tunnel), the peer is authenticated by 2703 demonstrating knowledge of not just a valid session identifier but 2704 also of the OTP used when the session was created. Server nonces 2705 prevents replay attacks but there still remains some likelihood of an 2706 attacker guessing the correct combination of session identifier and 2707 OTP value. Assuming OTPs with entropy about 32 bits this means that 2708 the likelihood of succeeding with such an attack is about 1/2^48 due 2709 to the birthday paradox. Servers allowing session resumption for the 2710 basic variant MUST protect against such attacks, e.g. by keeping 2711 track of the rate of failed resumption attempts. 2713 6.3. Denial of service attacks 2715 An active attacker may replace the iteration count value in OTP TLVs 2716 sent by the peer to slow down an authentication server. 2717 Authentication servers SHOULD protect against this, e.g. by 2718 disregarding OTP TLVs with an iteration count value higher than some 2719 pre- or dynamically- (depending on load) set number. 2721 6.4. The use of pepper 2723 As described in Section 4.8, the use of pepper will slow down an 2724 attacker's search for a matching OTP. The ability to transfer a 2725 pepper value in encrypted form from the EAP server to the peer means 2726 that, even though there may be an initial computational cost for the 2727 EAP server to authenticate the peer, subsequent authentications will 2728 be efficient, while at the same time more secure, since a pre-shared, 2729 128 bits long, pepper value will not be easily found by an attacker. 2730 An attacker observing an EAP-Request containing an OTP TLV calculated 2731 using a pepper chosen by the peer may however, depending on available 2732 resources, be able to successfully attack that particular EAP-POTP 2733 session, since it most likely will be based on a relatively short 2734 pepper value or only an iteration count. Once the correct OTP has 2735 been found, eavesdropping on the EAP server's Confirm TLV will 2736 potentially give the attacker access to the longer, server-provided 2737 pepper for the remaining lifetime of that pepper value. For this 2738 reason, initial exchanges with EAP servers SHOULD occur in a secure 2739 environment (e.g. in a PEAPv2 tunnel offering cryptographic binding 2740 with inner EAP methods), and if not, the iteration count MUST be 2741 significantly higher than for messages where a pre-shared pepper is 2742 used. The lifetime of the shared pepper must also be calculated with 2743 this in mind. Finally, the pepper value MUST be securely stored by 2744 the peer and the EAP server, associated with the user. 2746 6.5. The race attack 2748 In the case of fragmentation of EAP messages, it is possible (in the 2749 basic variant of this method) for an attacker to listen to most of an 2750 OTP, guess the remainder, and then race the legitimate user to 2751 complete the authentication. Conforming backend authentication 2752 server implementations MUST protect against this race condition. One 2753 defense against this attack is outlined below and borrowed from [14]; 2754 implementations MAY use this approach or MAY select an alternative 2755 defense. Note that the described defense relies on the user 2756 providing the identity in response to an initial Identity EAP- 2757 Request. 2759 One possible defense is to prevent a user from starting multiple 2760 simultaneous authentication sessions. This means that once the 2761 legitimate user has initiated authentication, an attacker would be 2762 blocked until the first authentication process has completed. In 2763 this approach, a timeout is necessary to thwart a denial of service 2764 attack. 2766 7. IANA considerations 2768 7.1. General 2770 This document is a description of a general EAP method for OTP 2771 tokens. It also defines EAP method 32 as a profile of the general 2772 method. Extending the set of EAP-POTP TLVs or the set of EAP-POTP 2773 cryptographic algorithms shall be seen as revisions of the protocol 2774 and hence requiring an RFC that updates, or obsoletes this document. 2776 7.2. Cryptographic algorithm identifier octets 2778 A new registry for EAP-POTP cryptographic algorithm identifier octets 2779 shall be created. The initial contents of this registry shall be as 2780 specified in Section 4.11.16. 2782 Assignment of new values for hash algorithms, encryption algorithms, 2783 and MAC algorithms in the Crypto Algorithm TLV MUST be done through 2784 IANA with "Specification Required" and "IESG Approval" (see [9] for 2785 the meaning of these terms). 2787 8. Intellectual property considerations 2789 RSA Security has filed an IETF IPR Disclosure for IPR related to this 2790 document. The IETF IPR Disclosure number is 569 and it can be found 2791 at the IETF IPR Disclosure page. RSA Security makes no 2792 representations regarding intellectual property claims by other 2793 parties. Such determination is the responsibility of the user. 2795 RSA, RSA Security and SecurID are either registered trademarks or 2796 trademarks of RSA Security Inc. in the United States and/or other 2797 countries. The names of other products and services mentioned may be 2798 the trademarks of their respective owners. 2800 9. Acknowledgments 2802 This document was improved by comments from, and discussion with, a 2803 number of RSA Security employees. Simon Josefsson drafted the 2804 initial versions of an RSA SecurID EAP method while working for RSA 2805 Laboratories. The inspiration for the TLV-type of information 2806 exchange comes from [17]. Special thanks to Oliver Tavakoli of Funk 2807 Software who has provided numerous useful comments and suggestions, 2808 Randy Chou of Aruba Networks for good suggestions in the session 2809 resumption area, and Jim Burns of Meetinghouse who provided 2810 inspiration for the Protected TLV. Thanks also to the IESG 2811 reviewers, Pasi Eronen, David Black, and Uri Blumenthal, for 2812 insightful comments that helped to improve the document. 2814 10. References 2816 10.1. Normative references 2818 [1] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J., and H. 2819 Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", 2820 RFC 3748, June 2004. 2822 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2823 Levels", RFC 2119, March 1997. 2825 [3] National Institute of Standards and Technology, "Secure Hash 2826 Standard", FIPS 180-2, February 2004. 2828 [4] National Institute of Standards and Technology, "Specification 2829 for the Advanced Encryption Standard (AES)", FIPS 197, 2830 November 2001. 2832 [5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2833 for Message Authentication", RFC 2104, February 1997. 2835 [6] RSA Laboratories, "Password-Based Cryptography Standard", 2836 PKCS #5 v2.0, March 1999. 2838 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 2839 RFC 2279, January 1998. 2841 [8] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, 2842 April 2000. 2844 [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2845 Considerations Section in RFCs", RFC 2434, October 1998. 2847 10.2. Informative references 2849 [10] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 2850 RFC 1661, July 1994. 2852 [11] The Institute of Electrical and Electronics Engineers, Inc., 2853 "IEEE Standard for Local and metropolitan area networks -- 2854 Port-Based Network Access Control", IEEE 802.1X-2001, 2855 July 2001. 2857 [12] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", 2858 RFC 4306, December 2005. 2860 [13] Stanley, D., Walker, J., and B. Aboba, "Extensible 2861 Authentication Protocol (EAP) Method Requirements for Wireless 2862 LANs", RFC 4017, March 2005. 2864 [14] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time 2865 Password System", RFC 2289, February 1998. 2867 [15] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 2868 Dial In User Service (RADIUS)", RFC 2865, June 2000. 2870 [16] Aboba, B., Simon, D., Eronen, P., and H. Levkowetz, Ed., 2871 "Extensible Authentication Protocol (EAP) Key Management 2872 Framework", Work in progress draft-ietf-eap-keying-14.txt, 2873 June 2006. 2875 [17] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S. 2876 Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in 2877 progress draft-josefsson-pppext-eap-tls-eap-10.txt, 2878 October 2004. 2880 [18] Internet Assigned Numbers Authority, "Private Enterprise 2881 Numbers", January 2005. 2883 [19] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 2884 RFC 2548, March 1999. 2886 Appendix A. Profile of EAP-POTP for RSA SecurID 2888 Note: The RSA SecurID product is a hardware token card (or software 2889 emulation thereof) produced by RSA Security Inc., which is used for 2890 end-user authentication. 2892 The EAP method type identifier for the RSA SecurID profile of EAP- 2893 POTP SHALL be 32. 2895 Peers and EAP servers implementing the SecurID profile of EAP-POTP 2896 SHALL conform to all EAP-POTP normative requirements in this 2897 document, and, in addition, the New PIN TLV and the Protected TLV 2898 MUST be supported by peers. 2900 Appendix B. Examples of EAP-POTP exchanges 2902 In the examples, "V1","V2","V3", etc. stand for arbitrary values of 2903 the correct type. 2905 B.1. Basic mode, unilateral authentication 2907 This mode should only be used within a secured tunnel. The peer 2908 identifies itself with a User Identifier TLV. 2910 Peer EAP server 2912 <- EAP-Request 2913 Type=Identity 2915 EAP-Response -> 2916 Type=Identity 2918 <- EAP-Request 2919 Type=OTP-X 2921 Version TLV: 2922 Highest=0,Lowest=0 2924 OTP TLV: 2925 P=0,C=0,N=0,T=0,E=0,R=0 2927 EAP-Response -> 2928 Type=OTP-X 2930 Version TLV: 2931 Highest=0 2933 OTP TLV: 2934 P=0,C=0,N=0,T=0,E=0,R=0 2935 Authentication Data=V1 2937 User Identifier TLV: 2938 User Identifier=V2 2940 <- EAP-Success 2942 B.2. Basic mode, session resumption 2944 This example illustrates successful resumption of a basic mode 2945 session. It must be carried out only in a protected tunnel. 2947 Peer EAP server 2949 <- EAP-Request 2950 Type=Identity 2952 EAP-Response -> 2953 Type=Identity 2955 <- EAP-Request 2956 Type=OTP-X 2958 Version TLV: 2959 Highest=0,Lowest=0 2961 OTP TLV: 2962 P=0,C=0,N=0,T=0,E=0,R=0 2964 Server-Info TLV: 2965 N=0 2966 Session Identifier=V1 2967 Server Identifier=V2 2968 Nonce=V3 2969 EAP-Response -> 2970 Type=OTP-X 2972 Version TLV: 2973 Highest=0 2975 Resume TLV: 2976 Session Identifier=V4 (indicating earlier, basic mode, session) 2977 Authentication Data=V5 2979 <- EAP-Success 2981 B.3. Mutual authentication without session resumption 2983 In this case, the peer uses the token key identifier in addition to 2984 the user identifier. The initial EAP-Identity exchange may also 2985 provide user information, or may be restricted to only general domain 2986 information. Pepper is not used, but will be used in a subsequent 2987 session since the server provides the peer with an encrypted pepper 2988 in its Confirm TLV. Absence of the Crypto Algorithm TLV indicates 2989 use of default cryptographic algorithms. 2991 Peer EAP server 2993 <- EAP-Request 2994 Type=Identity 2996 EAP-Response -> 2997 Type=Identity 2999 <- EAP-Request 3000 Type=OTP-X 3002 Version TLV: 3003 Highest=0,Lowest=0 3005 Server-Info TLV: 3006 N=0 3007 Session Identifier=V1 3008 Server Identifier=V2 3009 Nonce=V3 3011 OTP TLV: 3012 P=1,C=0,N=0,T=0,E=0,R=0 3013 Pepper Length=0 3014 Iteration Count=V4 3016 EAP-Response -> 3017 Type=OTP-X 3019 Version TLV: 3020 Highest=0 3022 OTP TLV: 3023 P=1,C=0,N=0,T=0,E=0,R=0 3024 Pepper Length=0 3025 Iteration Count=V4 3026 Authentication Data=V5 3028 User Identifier TLV: 3029 User Identifier=V6 3031 Token Key Identifier TLV: 3032 Token Key Identifier=V7 3034 <- EAP-Request 3035 Type=OTP-X 3037 Confirm TLV: 3038 C=0 3039 Authentication Data=V8 3040 Pepper Identifier=V9 3041 Encrypted Pepper=V10 3043 EAP-Response -> 3044 Type=OTP-X 3046 Confirm TLV: 3047 (no data) 3049 <- EAP-Success 3051 B.4. Mutual authentication with transfer of pepper 3053 The difference between this example and the previous one is that the 3054 peer makes use of an existing pepper in the PBKDF2 computation. The 3055 EAP server provides a new pepper to the peer in the Confirm TLV. 3056 Note that the peer had not been able to use a pepper in the response 3057 calculation unless it had found the existing pepper, since the server 3058 specified a maximum (new) pepper length of zero. 3060 Peer EAP server 3062 <- EAP-Request 3063 Type=Identity 3065 EAP-Response -> 3066 Type=Identity 3068 <- EAP-Request 3069 Type=OTP-X 3071 Version TLV: 3072 Highest=0,Lowest=0 3074 Server-Info TLV: 3075 N=0 3076 Session Identifier=V1 3077 Server Identifier=V2 3078 Nonce=V3 3080 OTP TLV: 3081 P=1,C=0,N=0,T=0,E=0,R=0 3082 Pepper Length=0 3083 Iteration Count=V4 3085 EAP-Response -> 3086 Type=OTP-X 3088 Version TLV: 3089 Highest=0 3091 OTP TLV: 3093 P=1,C=0,N=0,T=0,E=0,R=0 3094 Pepper Length=V5 3095 Iteration Count=V6 3096 Authentication Data=V7 3097 (includes a pepper identifier) 3099 User Identifier TLV: 3100 User Identifier=V8 3102 Token Key Identifier TLV: 3103 Token Key Identifier=V9 3105 <- EAP-Request 3106 Type=OTP-X 3108 Confirm TLV: 3109 C=0 3110 Authentication Data=V10 3111 Pepper Identifier=V11 3112 Encrypted Pepper=V12 3114 EAP-Response -> 3115 Type=OTP-X 3117 Confirm TLV: 3118 (no data) 3120 <- EAP-Success 3122 B.5. Failed mutual authentication 3124 This example differs from the previous one in that the peer is not 3125 able to authenticate the server. It therefore sends an empty EAP- 3126 Response of type POTP-X, which the EAP server acknowledges by 3127 responding with an EAP-Failure. Pepper is not used. 3129 Peer EAP server 3131 <- EAP-Request 3132 Type=Identity 3134 EAP-Response -> 3135 Type=Identity 3137 <- EAP-Request 3138 Type=OTP-X 3140 Version TLV: 3142 Highest=0,Lowest=0 3144 OTP TLV: 3145 P=1,C=0,N=0,T=0,E=0,R=0 3146 Pepper Length=V1 3147 Iteration Count=V2 3149 Server-Info TLV: 3150 N=0 3151 Session Identifier=V3 3152 Server Identifier=V4 3153 Nonce=V5 3155 EAP-Response -> 3156 Type=OTP-X 3158 Version TLV: 3159 Highest=0 3161 OTP TLV: 3162 P=1,C=0,N=0,T=0,E=0,R=0 3163 Pepper Length=V1 3164 Iteration Count=V2 3165 Authentication Data=V6 3167 User Identifier TLV: 3168 User Identifier=V7 3170 Token Key Identifier TLV: 3171 Token Key Identifier=V8 3173 <- EAP-Request 3174 Type=OTP-X 3176 Confirm TLV: 3177 C=0 3178 Authentication Data=V9 3180 EAP-Response -> 3181 Type=OTP-X 3183 (no data) 3185 <- EAP-Failure 3187 B.6. Session resumption 3189 This example illustrates successful session resumption. 3191 Peer EAP server 3193 <- EAP-Request 3194 Type=Identity 3196 EAP-Response -> 3197 Type=Identity 3199 <- EAP-Request 3200 Type=OTP-X 3202 Version TLV: 3203 Highest=0,Lowest=0 3205 OTP TLV: 3206 P=1,C=0,N=0,T=0,E=0,R=0 3207 Pepper Length=V1 3208 Iteration Count=V2 3210 Server-Info TLV: 3211 N=0 3212 Session Identifier=V3 3213 Server Identifier=V4 3214 Nonce=V5 3216 EAP-Response -> 3217 Type=OTP-X 3219 Version TLV: 3220 Highest=0 3222 Resume TLV: 3223 Session Identifier=V6 (indicating earlier, protected mode, session) 3224 Authentication Data=V7 3226 <- EAP-Request 3227 Type=OTP-X 3229 Confirm TLV: 3230 C=0 3231 Authentication Data=V8 3233 EAP-Response -> 3234 Type=OTP-X 3235 Confirm TLV: 3236 (no data) 3238 <- EAP-Success 3240 B.7. Failed session resumption 3242 This example illustrates a failed session resumption, followed by a 3243 complete mutual authentication. The user is identified through the 3244 User Identifier TLV. The client is able to re-use an older pepper. 3245 The server sends a new pepper for subsequent use in its Confirm TLV. 3246 The server suggests some non-default cryptographic algorithms but the 3247 client only supports the default ones. 3249 Peer EAP server 3251 <- EAP-Request 3252 Type=Identity 3254 EAP-Response -> 3255 Type=Identity 3257 <- EAP-Request 3258 Type=OTP-X 3260 Version TLV: 3261 Highest=0,Lowest=0 3263 OTP TLV: 3264 P=1,C=0,N=0,T=0,E=0,R=0 3265 Pepper Length=V1 3266 Iteration Count=V2 3268 Server-Info TLV: 3269 N=0 3270 Session Identifier=V3 3271 Server Identifier=V4 3272 Nonce=V5 3274 Crypto Algorithm TLV: 3275 Hash Alg. Length=V6 3276 Hash Algorithms=V7 3277 Encr. Alg. Length=V8 3278 Encr. Algorithms=V9 3279 MAC Alg. Length=V10 3280 MAC Algorithms=V11 3282 EAP-Response -> 3283 Type=OTP-X 3285 Version TLV: 3286 Highest=0 3288 Resume TLV: 3289 Session Identifier=V12 (indicating earlier session) 3290 Authentication Data=V13 3292 <- EAP-Request 3293 Type=OTP-X 3295 OTP TLV: 3296 P=1,C=0,N=0,T=0,E=0,R=0 3297 Pepper Length=V14 3298 Iteration Count=V15 3300 Server-Info TLV: 3301 N=1 (no resumption) 3302 Session Identifier=V3 3303 Server Identifier=V4 3304 Nonce=V16 3306 EAP-Response -> 3307 Type=OTP-X 3309 OTP TLV: 3310 P=1,C=0,N=1,T=1,E=0,R=0 3311 Pepper Length=V17 3312 Iteration Count=V18 3313 Authentication Data=V19 (with pepper identifier) 3315 User Identifier TLV: 3316 User Identifier=V20 3318 <- EAP-Request 3319 Type=OTP-X 3321 Confirm TLV: 3322 C=0 3323 Authentication Data=V21 3324 Pepper Identifier=V22 3325 Encrypted Pepper=V23 3326 EAP-Response -> 3327 Type=OTP-X 3329 Confirm TLV: 3330 (no data) 3331 <- EAP-Success 3333 B.8. Mutual authentication, and new PIN requested. 3335 In this example, the user is also requested to select a new PIN. The 3336 new PIN is allowed to be alphanumeric, and must be at least 6 3337 characters long. The user selects another PIN than the one suggested 3338 by the server. The token key is identified through a combination of 3339 the user identifier and the token key identifier. While waiting for 3340 the user input, to avoid network timeouts, the peer sends an EAP- 3341 Response containing a Keep-Alive TLV to the EAP server. The EAP 3342 server responds by sending an EAP-Request containing a Keep-Alive TLV 3343 back to the peer. Note that all TLVs exchanged after the Confirm TLV 3344 exchange are wrapped in the Protected TLV. Absence of the Crypto 3345 Algorithm TLV indicates use of default cryptographic algorithms. 3347 Peer EAP server 3349 <- EAP-Request 3350 Type=Identity 3352 EAP-Response -> 3353 Type=Identity 3355 <- EAP-Request 3356 Type=OTP-X 3358 Version TLV: 3359 Highest=0,Lowest=0 3361 OTP TLV: 3362 P=1,C=0,N=0,T=0,E=0,R=0 3363 Pepper Length=V1 3364 Iteration Count=V2 3366 Server-Info TLV: 3367 N=0 3368 Session Identifier=V3 3369 Server Identifier=V4 3370 Nonce=V5 3372 EAP-Response -> 3373 Type=OTP-X 3375 Version TLV: 3376 Highest=0 3378 OTP TLV: 3380 P=1,C=0,N=0,T=0,E=0,R=0 3381 Pepper Length=V6 3382 Iteration Count=V7 3383 Authentication Data=V8 (with pepper identifier) 3385 User Identifier TLV: 3386 User Identifier=V9 3388 Token Key Identifier TLV: 3389 Token Key Identifier=V10 3391 <- EAP-Request 3392 Type=OTP-X 3394 Confirm TLV: 3395 C=1 3396 Authentication Data=V11 3398 EAP-Response -> 3399 Type=OTP-X 3401 Confirm TLV: 3402 (no data) 3404 <- EAP-Request 3405 Type=OTP-X 3407 Protected TLV: 3408 MAC=V12 3409 IV=V13 3410 Encrypted TLVs=V14 3411 (Contains: 3412 New PIN TLV: 3413 Q=0,A=1 3414 PIN=V15 3415 Min. PIN Length=6) 3417 EAP-Response -> 3418 Type=OTP-X 3420 Protected TLV: 3421 MAC=V16 3422 IV=V17 3423 Encrypted TLVs=V18 3424 (Contains: 3425 Keep-Alive TLV: 3426 (no data)) 3427 <- EAP-Request 3428 Type=OTP-X 3430 Protected TLV: 3431 MAC=V19 3432 IV=V20 3433 Encrypted TLVs=V21 3434 (Contains: 3435 Keep-Alive TLV: 3436 (no data)) 3438 EAP-Response -> 3439 Type=OTP-X 3441 Protected TLV: 3442 MAC=V22 3443 IV=V23 3444 Encrypted TLVs=V24 3445 (Contains: 3446 New PIN TLV: 3447 Q=0,A=0 3448 PIN=V25) 3450 <- EAP-Request 3451 Type=OTP-X 3453 Protected TLV: 3454 MAC=V26 3455 IV=V27 3456 Encrypted TLVs=V28 3457 (Contains: 3458 OTP TLV: 3459 P=1,C=0,N=0,T=0,E=0,R=0 3460 Pepper Length=V1 3461 Iteration Count=V2) 3463 EAP-Response -> 3464 Type=OTP-X 3466 Protected TLV 3467 MAC=V29 3468 IV=V30 3469 Encrypted TLVs=V31 3470 (Contains: 3471 OTP TLV: 3472 P=1,C=0,N=0,T=0,E=0,R=0 3473 Pepper Length=V6 3474 Iteration Count=V7 3475 Authentication Data=V31) 3477 <- EAP-Request 3478 Type=OTP-X 3480 Protected TLV 3481 MAC=V32 3482 IV=V33 3483 Encrypted TLVs=V34 3484 (Contains: 3485 Confirm TLV: 3486 C=0 3487 Authentication Data=V35) 3489 EAP-Response -> 3490 Type=OTP-X 3492 Protected TLV 3493 MAC=V36 3494 IV=V37 3495 Encrypted TLVs=V38 3496 (Contains: 3497 Confirm TLV: 3498 (no data)) 3500 <- EAP-Success 3502 B.9. Use of next OTP mode 3504 In this example, the peer is requested to provide a second OTP to the 3505 EAP server. 3507 Peer EAP server 3509 <- EAP-Request 3510 Type=Identity 3512 EAP-Response -> 3513 Type=Identity 3515 <- EAP-Request 3516 Type=OTP-X 3518 Version TLV: 3519 Highest=0,Lowest=0 3521 OTP TLV: 3522 P=1,C=0,N=0,T=0,E=0,R=0 3523 Pepper Length=V1 3524 Iteration Count=V2 3526 Server-Info TLV: 3527 N=0 3528 Session Identifier=V3 3529 Server Identifier=V4 3530 Nonce=V5 3532 EAP-Response -> 3533 Type=OTP-X 3535 Version TLV: 3536 Highest=0 3538 OTP TLV: 3539 P=1,C=0,N=0,T=0,E=0,R=0 3540 Pepper Length=V6 3541 Iteration Count=V7 3542 Authentication Data=V8 3544 User Identifier TLV: 3545 User Identifier=V9 3547 <- EAP-Request 3548 Type=OTP-X 3550 OTP TLV: 3551 P=1,C=0,N=1,T=1,E=0,R=0 3552 Pepper Length=V1 3553 Iteration Count=V2 3555 EAP-Response -> 3556 Type=OTP-X 3558 OTP TLV: 3559 P=1,C=0,N=1,T=1,E=0,R=0 3560 Pepper Length=V6 3561 Iteration Count=V7 3562 Authentication Data=V10 3564 <- EAP-Request 3565 Type=OTP-X 3567 Confirm TLV: 3568 C=0 3569 Authentication Data=V11 3571 EAP-Response -> 3572 Type=OTP-X 3574 Confirm TLV: 3575 (no data) 3577 <- EAP-Success 3579 Appendix C. Use of the MPPE-Send/Receive-Key RADIUS attributes 3581 C.1. Introduction 3583 This section describes how to populate the MPPE-Send-Key and the 3584 MPPE-Receive-Key RADIUS attributes defined in [19] using an MSK 3585 established in EAP-POTP. 3587 C.2. MPPE key attribute population 3589 Once the EAP-POTP MSK has been generated, it is used as follows to 3590 populate the MPPE-Send-Key and the MPPE-Receive-Key attributes: 3592 Use the initial 32 octets of the MSK as the value for the "Key" sub- 3593 field in the plaintext "String" field of the MPPE-Send-Key attribute, 3594 and use the final 32 octets of the MSK as the "Key" sub-field in the 3595 plaintext "String" field of the MPPE-Receive-Key attribute (Note: 3596 "Send" and "Receive" here refers to the Authenticator, for the peer 3597 they are reversed). 3599 Appendix D. Key strength considerations 3601 D.1. Introduction 3603 As described in Section 6, the strength of keys generated in EAP-POTP 3604 protected mode depends on a number of factors. This appendix 3605 provides examples of actual key strengths achieved under various 3606 assumptions. 3608 It should be noted, that while some of the examples indicate that the 3609 strength of generated keys is relatively weak, the strength applies 3610 only to those EAP-POTP sessions between a peer and an EAP server that 3611 do not share a pepper. Once a pepper, provided by an EAP server to a 3612 peer has been established, future sessions using this pepper will 3613 provide full-strength keys. 3615 D.2. Example 1: 6-digit One-Time Passwords 3617 In this example we assume the following: 3619 OTPs are six decimal digits long; 3621 4-digit PINs are added to generated OTPs; and 3623 OTP hardening (iteration count and pepper searching combined) 3624 effectively adds 10 bits of entropy. One way of achieving this 3625 without use of pepper searching is to have the iteration count in 3626 PBKDF2 set to 1,000,000. 3628 The effective key strength then becomes roughly: 3630 log_2(10**6) + log_2(10**4) + log_2(2**10) = 43 bits 3632 The above assumes the entopy of the underlying shared secret is >43 3633 bits and that there are no other weaknesses in the OTP algorithm. 3635 D.3. Example 2: 8-digit One-Time Passwords 3637 In this example we assume the following: 3639 OTPs are six decimal digits long; 3641 4-character alphanumeric PINs are added to generated OTPs; and 3643 OTP hardening (iteration count and pepper searching combined) 3644 effectively adds 10 bits of entropy. 3646 The effective key strength then becomes roughly: 3648 log_2(10**8) + log_2(26**4) + log_2(2**10) = 55 bits 3650 The above assumes the entopy of the underlying shared secret is >55 3651 bits and that there are no other weaknesses in the OTP algorithm. 3653 Author's Address 3655 Magnus Nystroem 3656 RSA Security 3658 Email: magnus@rsasecurity.com 3660 Intellectual Property Statement 3662 The IETF takes no position regarding the validity or scope of any 3663 Intellectual Property Rights or other rights that might be claimed to 3664 pertain to the implementation or use of the technology described in 3665 this document or the extent to which any license under such rights 3666 might or might not be available; nor does it represent that it has 3667 made any independent effort to identify any such rights. Information 3668 on the procedures with respect to rights in RFC documents can be 3669 found in BCP 78 and BCP 79. 3671 Copies of IPR disclosures made to the IETF Secretariat and any 3672 assurances of licenses to be made available, or the result of an 3673 attempt made to obtain a general license or permission for the use of 3674 such proprietary rights by implementers or users of this 3675 specification can be obtained from the IETF on-line IPR repository at 3676 http://www.ietf.org/ipr. 3678 The IETF invites any interested party to bring to its attention any 3679 copyrights, patents or patent applications, or other proprietary 3680 rights that may cover technology that may be required to implement 3681 this standard. Please address the information to the IETF at 3682 ietf-ipr@ietf.org. 3684 Disclaimer of Validity 3686 This document and the information contained herein are provided on an 3687 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3688 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3689 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3690 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3691 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3692 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3694 Copyright Statement 3696 Copyright (C) The Internet Society (2006). This document is subject 3697 to the rights, licenses and restrictions contained in BCP 78, and 3698 except as set forth therein, the authors retain all their rights. 3700 Acknowledgment 3702 Funding for the RFC Editor function is currently provided by the 3703 Internet Society.