Network Working Group D. Mitton Internet Draft RSA Security Category: Informational N. Cam-Winget Expires: November 2006 Cisco Systems June 16, 2006 Using the Protected One-Time Password Protocol for EAP-FAST Provisioning draft-cam-winget-eap-fast-potp-provisioning-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 2006. Copyright Notice Copyright (C) The Internet Society (2006). Cam-Winget, Mitton Expires December 2006 [Page 1] Internet-Draft Using POTP for EAP-FAST Provisioning June 2006 Abstract EAP-FAST is an extensible EAP method that enables the provisioning of credentials or other information by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. As the tunnel may be unauthenticated, EAP-FAST further enables the use of inner EAP methods to establish mutual authentication prior to provisioning. This document describes how EAP-POTP may be used as the EAP-FAST inner method for credential provisioning. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Cam-Winget, Mitton Expires December 2006 [Page 2] Internet-Draft Using POTP for EAP-FAST Provisioning June 2006 Table of Contents 1. Introduction...................................................4 2. Authenticating with EAP-POTP in EAP-FAST for provisioning......4 3. Cryptographic Calculations.....................................4 4. Security Considerations........................................5 5. IANA Considerations............................................5 6. Acknowledgments................................................6 7. References.....................................................6 7.1. Normative References......................................6 7.2. Informative References....................................6 8. Author's Addresses.............................................7 APPENDIX A: Example of a successful Tunnel PAC provisioning using EAP-POTP mutual authentication....................................8 Intellectual Property Statement..................................11 Disclaimer of Validity...........................................11 Copyright Statement..............................................11 Acknowledgment...................................................11 Cam-Winget, Mitton Expires December 2006 [Page 3] Internet-Draft Using POTP for EAP-FAST Provisioning June 2006 1. Introduction EAP-FAST [EAP-FAST] is an extensible EAP method that can be used to mutually authenticate peer and server as well as provisioning information such as user credentials. [FAST-PROVISION] defines how EAP-FAST is used to enable dynamic or in-band provisioning and demonstrates how other EAP authentication methods may be used inside the protected tunnel to ensure mutual authentication prior to provisioning. As EAP-FAST enables any inner EAP method to be used, this document describes how EAP Protected-OTP [EAP-POTP] may be employed within EAP-FAST Provisioning to ensure mutual authentication during in-band provisioning. 2. Authenticating with EAP-POTP in EAP-FAST for provisioning Once a protected tunnel is established as defined in [FAST- PROVISION], the peer must authenticate itself to the server before the server can provision the peer. Use of EAP-POTP is negotiated between the server and the peer. After the peer responds with a EAP Payload TLV containing the EAP Identity Response, the server MAY request the use of EAP-POTP as the inner EAP authentication method. EAP-POTP allows a protected authentication based on a pre-shared secret provisioned into a one-time password generating token. Possession of the token and an optional PIN value, provides a portable strong authenticator. The EAP-POTP method is an end-to-end authentication method that requires both parties to know the one-time password generated by the token based on that shared secret. This information allows a method of secure provisioning that does not require a user-memorized or static password. Details of the EAP-POTP method can be found in [EAP-POTP]. The server MAY use EAP-POTP as the inner EAP authentication in either Server-Authenticated or Server-Unauthenticated provisioning modes. 3. Cryptographic Calculations The Key derivations for establishing the tunnel are as defined in [EAP-FAST] Section 5. The Intermediate Compound Key Derivation following a successful EAP-POTP authentication within EAP-FAST for provisioning is defined in [FAST-PROVISION] Section 5.2 using the resulting MSK as described in [EAP-POTP] Section 4.5. Cam-Winget, Mitton Expires December 2006 [Page 4] Internet-Draft Using POTP for EAP-FAST Provisioning June 2006 4. Security Considerations Though EAP-POTP, like EAP-MSCHAPv2 is a username and password based authentication mechanism, it provides several features that strengthen its security: * The current one-time password is not exchanged, but instead, authentication is based on values derived from the password, nonces from each side and inputs including the session instance information. * The authentication processes can be configured for various sizes of hash and iteration inputs, to slow active attacks. * The method is resistant to man-in-the-middle attacks because of cryptographic bindings to the network messages. * The method requires mutual authentication of the derived values. EAP-POTP derives its session keys using a multi-state hashing function (PBKDF2) [PKCS5] whose input is based on the token code, PIN input, a random or pre-shared secret, an iteration count and information about the server, and derives an authentication value for transmittal. It also keeps a hash of the running EAP request and response messages, using an SHA256 function. The hash values are combined with the generated keys, to cryptographically bind the authentication to the current message stream and mutually authenticate. When using EAP-POTP as the inner method, the server can only validate this value by knowing all of the same inputs. Any man-in-the-middle change would affect the derived value and cause a failure. When using EAP-POTP during dynamic EAP-FAST provisioning, session resumption credentials MUST NOT be used for authentication. Due to the mutual authentication and key establishment provided by EAP-POTP, Server-Unauthenticated Provisioning Mode MAY be used when EAP-POTP is used for PAC provisioning 5. IANA Considerations This specification requires no new IANA values to be assigned. Cam-Winget, Mitton Expires December 2006 [Page 5] Internet-Draft Using POTP for EAP-FAST Provisioning June 2006 6. Acknowledgments Thanks to Hao Zhou, Magnus Nystrom, and Dmitri Pal for their valuable input. 7. References 7.1. Normative References [EAP-FAST] Cam-Winget, N., et al., "EAP Flexible Authentication via Secure Tunneling (EAP-FAST) ", draft-cam-winget-eap-fast- 03(work in progress), April 2006. [FAST-PROVISION] Cam-Winget, N., "Dynamic Provisioning using EAP- FAST", draft-cam-winget-eap-fast-provisioning-02 (work in progress), March 2006. [EAP-POTP] Nystrom M., "The Protected One-Time Password Protocol (EAP-POTP)", draft-nystrom-eap-potp-04 (work in progress), June 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC3748] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J., and H.Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [PKCS5] RSA Laboratories, "Password-Based Cryptography Standard", PKCS #5 v2.0, March 1999. Cam-Winget, Mitton Expires December 2006 [Page 6] Internet-Draft Using POTP for EAP-FAST Provisioning June 2006 8. Author's Addresses Nancy Cam-Winget Cisco Systems Inc. 3625 Cisco Way San Jose, CA 95134 Email: ncamwing@cisco.com David Mitton RSA Security Inc. 174 Middlesex Turnpike Bedford, MA 01730 Email: dmitton@rsasecurity.com Cam-Winget, Mitton Expires December 2006 [Page 7] Internet-Draft Using POTP for EAP-FAST Provisioning June 2006 APPENDIX A: Example of a successful Tunnel PAC provisioning using EAP- POTP mutual authentication The following exchanges show anonymous DH with a successful EAP-POTP exchange within Phase 2 to provision a Tunnel PAC, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID1) -> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (EAP-FAST Start, S bit set, A-ID) EAP-Response/ EAP-Type=EAP-FAST, V=1 (TLS client_hello without PAC-Opaque extension)-> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS server_hello, TLS Server Key Exchange TLS Server Hello Done) EAP-Response/ EAP-Type=EAP-FAST, V=1 -> (TLS Client Key Exchange TLS change_cipher_spec, TLS finished) <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS change_cipher_spec TLS finished) EAP-Response/ EAP-Type=EAP-FAST, V=1 -> (Acknowledgement) TLS channel established (messages sent within the TLS channel) <- EAP Payload TLV, EAP-Request/ EAP Identity Request Cam-Winget, Mitton Expires December 2006 [Page 8] Internet-Draft Using POTP for EAP-FAST Provisioning June 2006 EAP Payload TLV, EAP-Response/ EAP Identity Response -> <- EAP Payload TLV, EAP-Request, OTP-X, Version TLV: Highest=0, Lowest=0 Server-Info TLV: N=0 Session Identifier=V1 Session Identifier=V2 Nonce=V3 OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=0 Iteration Count=V4 EAP Payload TLV, -> EAP-Response, OTP-X, Version TLV: Highest=0 OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Iteration Count=V4 Authentication Data=V5 User Identifier TLV: User Identifier=V6 Token Key Identifier TLV: Token Key Identifier=V7 <- EAP Payload TLV, EAP-Request, OTP-X, Confirm TLV: C=0 Authentication Data=V8 Pepper Identifier=V9 Encrypted Pepper=V10 EAP Payload TLV, -> EAP-Response, OTP-X, Confirm TLV: (no data) Cam-Winget, Mitton Expires December 2006 [Page 9] Internet-Draft Using POTP for EAP-FAST Provisioning June 2006 <- Intermediate Result TLV (Success) Crypto-Binding-TLV(Version=1, EAP-FAST Version=1, SNonce, CompoundMAC) Intermediate Result TLV (Success) Crypto-Binding-TLV(Version=1, EAP-FAST Version=1, CNonce, CompoundMAC), PAC TLV (PAC-Type=User Authorization PAC)-> <- Result TLV (Success) PAC TLV Result TLV (Success) PAC Acknowledgment -> TLS channel torn down (messages sent in cleartext) <- EAP-Success Cam-Winget, Mitton Expires December 2006 [Page 10] Internet-Draft Using POTP for EAP-FAST Provisioning June 2006 Intellectual Property Statement 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 ietf-ipr@ietf.org. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cam-Winget, Mitton Expires December 2006 [Page 11]