16], EAP-POTP defines the following identifiers to be associated with generated key material: Peer-ID: The combined contents of the User Identifier TLV and the Token Key Identifier TLV. Server-ID: The contents of the Server Identifier field of the Server-Info TLV. Method-ID: The identifier of the established session (i.e., the contents of the Session Identifier field of the Server-Info TLV that defined the session). RFC 3748 , the following security claims are made for the EAP-POTP method: Authentication mechanism: Generic OTP Ciphersuite negotiation: Yes (No in basic variant) Mutual authentication: Yes (No in basic variant) Integrity protection: Yes (No in basic variant) Replay protection: Yes (see below) Confidentiality: Only in the OTP protection variant, and then only OTP values and any information sent after exchange of the Confirm TLV Key derivation: Yes (No in basic variant) Key strength: Depends on size of OTP value, strength of underlying shared secret, strength and characteristics of OTP algorithm, pepper length, iteration count, and whether the method is used within a tunnel such as PEAPv2. For some illustrative examples, and a further discussion of this, see Appendix D. Dictionary attack prot.: N/A (Human-selected passwords not used) Fast reconnect: Yes Crypt. binding: N/A (EAP-POTP is not a tunnel method) Session independence: Yes Fragmentation: N/A (Packets shall not exceed MTU of 1020) Channel binding: Yes (No in basic variant) Acknowledged S/F: Yes State Synchronization: Yes (No in basic variant)
17], for example. When the OTP protection variant is used, however, the EAP method provides privacy for OTPs and new PINs, negotiation of cryptographic algorithms, mutual authentication, and protection against replay attacks and protocol version downgrades. It also provides protection against man-in-the-middle attacks, not due to the infeasibility for a man-in-the-middle to solve for a valid OTP given an OTP TLV, but due to the computational expense of finding the OTP in the limited time period during which it is valid (this is mainly true for tokens, including the current time in their OTP calculations, or when a sent challenge has a certain lifetime). It should be noted, however, that a retrieved OTP, even if "old" and invalid, still may divulge some information about the user's PIN. Clearly, this is also true for the basic variant. Implementations of this EAP method, where user PINs are sent with OTPs, are therefore RECOMMENDED to ensure regular user PIN changes, regardless of whether the protected variant or the basic variant is employed. It should also be noted that, while it is possible for a rogue access point, e.g., to clone MAC addresses, and hence mount a man-in-the- middle attack, such an access point will not be able to calculate the session keys MSK and EMSK. This demonstrates the importance of using the derived key material properly to protect a subsequent session. Protected mode protects against version downgrade attacks due to the HMAC both parties transmit in this mode. As described, each party calculates the HMAC on sent and received EAP-POTP handshake messages. If an attacker were to modify a Version TLV, this would be reflected
in a difference between the calculated MACs (since the recipient of the Version TLV received a different value than the sender sent). Unless the attacker knows K_MAC, he cannot calculate the correct MAC, and hence the difference will be detected. The OTP protection variant also protects against session hijacking, if the derived key material is used (directly or indirectly) to protect a subsequent session. For these reasons, use of the OTP protection variant is RECOMMENDED. However, it should be noted that not even the OTP protection variant provides privacy for user names and/or token key identifiers. EAP- POTP MUST be used within a secure tunnel such as the one provided by PEAPv2  if privacy for these parameters is required. When resuming sessions created in the basic variant (which MUST only take place within a protected tunnel), the peer is authenticated by demonstrating knowledge of not just a valid session identifier, but also the OTP used when the session was created. Server nonces prevent replay attacks, but there still remains some likelihood of an attacker guessing the correct combination of session identifier and OTP value. Assuming OTPs with entropy about 32 bits, this means that the likelihood of succeeding with such an attack is about 1/2^48 due to the birthday paradox. Servers allowing session resumption for the basic variant MUST protect against such attacks, e.g., by keeping track of the rate of failed resumption attempts. Section 4.8, the use of pepper will slow down an attacker's search for a matching OTP. The ability to transfer a pepper value in encrypted form from the EAP server to the peer means that, even though there may be an initial computational cost for the EAP server to authenticate the peer, subsequent authentications will be efficient, while at the same time more secure, since a pre-shared, 128-bit-long pepper value will not be easily found by an attacker. An attacker, observing an EAP-Request containing an OTP TLV calculated using a pepper chosen by the peer, may, however, depending on available resources, be able to successfully attack that particular EAP-POTP session, since it most likely will be based on a
relatively short pepper value or only an iteration count. Once the correct OTP has been found, eavesdropping on the EAP server's Confirm TLV will potentially give the attacker access to the longer, server- provided pepper for the remaining lifetime of that pepper value. For this reason, initial exchanges with EAP servers SHOULD occur in a secure environment (e.g., in a PEAPv2 tunnel offering cryptographic binding with inner EAP methods). If initial exchanges do not occur in a secure environment, the iteration count MUST be significantly higher than for messages where a pre-shared pepper is used. The lifetime of the shared pepper must also be calculated with this in mind. Finally, the peer and the EAP server MUST store the pepper value securely and associated with the user. 14]; implementations MAY use this approach or MAY select an alternative defense. Note that the described defense relies on the user providing the identity in response to an initial Identity EAP- Request. One possible defense is to prevent a user from starting multiple simultaneous authentication sessions. This means that once the legitimate user has initiated authentication, an attacker would be blocked until the first authentication process has completed. In this approach, a timeout is necessary to thwart a denial-of-service attack.
Section 4.11.16. Assignment of new values for hash algorithms, encryption algorithms, and MAC algorithms in the Crypto Algorithm TLV MUST be done through IANA with "Specification Required" and "IESG Approval" (see  for the meaning of these terms). 17]. Special thanks to Oliver Tavakoli of Funk Software who provided numerous useful comments and suggestions, Randy Chou of Aruba Networks for good suggestions in the session resumption area, and Jim Burns of Meetinghouse who provided inspiration for the Protected TLV. Thanks also to the IESG reviewers, Pasi Eronen, David Black, and Uri Blumenthal, for insightful comments that helped to improve the document, and to Alfred Hoenes for a thorough editorial review.
 Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, February 2004.  National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001.  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.  Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.  Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.  The Institute of Electrical and Electronics Engineers, Inc., "IEEE Standard for Local and metropolitan area networks -- Port-Based Network Access Control", IEEE 802.1X-2001, July 2001.  Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
 Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.  Aboba, B., Simon, D., Eronen, P., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2006.  Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.  Internet Assigned Numbers Authority, "Private Enterprise Numbers", December 2006.  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
User Identifier TLV: User Identifier=V6 Token Key Identifier TLV: Token Key Identifier=V7 <- EAP-Request Type=OTP-X Confirm TLV: C=0 Authentication Data=V8 Pepper Identifier=V9 Encrypted Pepper=V10 EAP-Response -> Type=OTP-X Confirm TLV: (no data) <- EAP-Success
User Identifier TLV: User Identifier=V8 Token Key Identifier TLV: Token Key Identifier=V9 <- EAP-Request Type=OTP-X Confirm TLV: C=0 Authentication Data=V10 Pepper Identifier=V11 Encrypted Pepper=V12 EAP-Response -> Type=OTP-X Confirm TLV: (no data) <- EAP-Success
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5 EAP-Response -> Type=OTP-X Version TLV: Highest=0 OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2 Authentication Data=V6 User Identifier TLV: User Identifier=V7 Token Key Identifier TLV: Token Key Identifier=V8 <- EAP-Request Type=OTP-X Confirm TLV: C=0 Authentication Data=V9 EAP-Response -> Type=OTP-X (no data) <- EAP-Failure
EAP-Response -> Type=Identity <- EAP-Request Type=OTP-X Version TLV: Highest=0,Lowest=0 OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2 Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5 EAP-Response -> Type=OTP-X Version TLV: Highest=0 Resume TLV: Session Identifier=V6 (indicating earlier, protected mode, session) Authentication Data=V7 <- EAP-Request Type=OTP-X Confirm TLV: C=0 Authentication Data=V8 EAP-Response -> Type=OTP-X Confirm TLV: (no data) <- EAP-Success
Resume TLV: Session Identifier=V12 (indicating earlier session) Authentication Data=V13 <- EAP-Request Type=OTP-X OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V14 Iteration Count=V15 Server-Info TLV: N=1 (no resumption) Session Identifier=V3 Server Identifier=V4 Nonce=V16 EAP-Response -> Type=OTP-X OTP TLV: P=1,C=0,N=1,T=1,E=0,R=0 Pepper Length=V17 Iteration Count=V18 Authentication Data=V19 (with pepper identifier) User Identifier TLV: User Identifier=V20 <- EAP-Request Type=OTP-X Confirm TLV: C=0 Authentication Data=V21 Pepper Identifier=V22 Encrypted Pepper=V23 EAP-Response -> Type=OTP-X Confirm TLV: (no data) <- EAP-Success
Iteration Count=V7 Authentication Data=V8 (with pepper identifier) User Identifier TLV: User Identifier=V9 Token Key Identifier TLV: Token Key Identifier=V10 <- EAP-Request Type=OTP-X Confirm TLV: C=1 Authentication Data=V11 EAP-Response -> Type=OTP-X Confirm TLV: (no data) <- EAP-Request Type=OTP-X Protected TLV: MAC=V12 IV=V13 Encrypted TLVs=V14 (Contains: New PIN TLV: Q=0,A=1 PIN=V15 Min. PIN Length=6) EAP-Response -> Type=OTP-X Protected TLV: MAC=V16 IV=V17 Encrypted TLVs=V18 (Contains: Keep-Alive TLV: (no data)) <- EAP-Request Type=OTP-X
Protected TLV: MAC=V19 IV=V20 Encrypted TLVs=V21 (Contains: Keep-Alive TLV: (no data)) EAP-Response -> Type=OTP-X Protected TLV: MAC=V22 IV=V23 Encrypted TLVs=V24 (Contains: New PIN TLV: Q=0,A=0 PIN=V25) <- EAP-Request Type=OTP-X Protected TLV: MAC=V26 IV=V27 Encrypted TLVs=V28 (Contains: OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2) EAP-Response -> Type=OTP-X Protected TLV MAC=V29 IV=V30 Encrypted TLVs=V31 (Contains: OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V6 Iteration Count=V7 Authentication Data=V31)
<- EAP-Request Type=OTP-X Protected TLV MAC=V32 IV=V33 Encrypted TLVs=V34 (Contains: Confirm TLV: C=0 Authentication Data=V35) EAP-Response -> Type=OTP-X Protected TLV MAC=V36 IV=V37 Encrypted TLVs=V38 (Contains: Confirm TLV: (no data)) <- EAP-Success
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5 EAP-Response -> Type=OTP-X Version TLV: Highest=0 OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V6 Iteration Count=V7 Authentication Data=V8 User Identifier TLV: User Identifier=V9 <- EAP-Request Type=OTP-X OTP TLV: P=1,C=0,N=1,T=1,E=0,R=0 Pepper Length=V1 Iteration Count=V2 EAP-Response -> Type=OTP-X OTP TLV: P=1,C=0,N=1,T=1,E=0,R=0 Pepper Length=V6 Iteration Count=V7 Authentication Data=V10 <- EAP-Request Type=OTP-X Confirm TLV: C=0 Authentication Data=V11 EAP-Response -> Type=OTP-X
Confirm TLV: (no data) <- EAP-Success 19], using an MSK established in EAP-POTP. Section 6, the strength of keys generated in EAP-POTP protected mode depends on a number of factors. This appendix provides examples of actual key strengths achieved under various assumptions. It should be noted that, while some of the examples indicate that the strength of generated keys is relatively weak, the strength applies only to those EAP-POTP sessions between a peer and an EAP server that do not share a pepper. Once a pepper, provided by an EAP server to a peer, has been established, future sessions using this pepper will provide full-strength keys.
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.