idnits 2.17.1 draft-cam-winget-eap-fast-potp-provisioning-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 365. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 25, 2008) is 5897 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3979' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC3978' is defined on line 208, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 211, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-cam-winget-eap-fast-provisioning-06 -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Mitton 2 Internet Draft RSA Security Divison of EMC 3 Category: Informational N. Cam-Winget 4 Expires: August 2008 Cisco Systems 5 February 25, 2008 7 Using the Protected One-Time Password Protocol for 8 EAP-FAST Provisioning 9 draft-cam-winget-eap-fast-potp-provisioning-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on August 25, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 EAP-FAST is an extensible EAP method that enables the provisioning of 44 credentials or other information by using the Transport Layer 45 Security (TLS) to establish a mutually authenticated tunnel. As the 46 tunnel may be unauthenticated, EAP-FAST further enables the use of 47 inner EAP methods to establish mutual authentication prior to 48 provisioning. This document describes how EAP-POTP may be used as 49 the EAP-FAST inner method for credential provisioning. 51 Conventions used in this document 53 In examples, "C:" and "S:" indicate lines sent by the client and 54 server respectively. 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 Table of Contents 62 1. Introduction...................................................4 63 2. Authenticating with EAP-POTP in EAP-FAST for provisioning......4 64 3. Cryptographic Calculations.....................................4 65 4. Security Considerations........................................5 66 5. IANA Considerations............................................5 67 6. Acknowledgments................................................6 68 7. References.....................................................6 69 7.1. Normative References......................................6 70 7.2. Informative References....................................6 72 8. Author's Addresses.............................................7 73 APPENDIX A: Example of a successful Tunnel PAC provisioning using 74 EAP-POTP mutual authentication....................................8 75 Intellectual Property Statement..................................11 76 Disclaimer of Validity...........................................11 77 Copyright Statement..............................................11 78 Acknowledgment...................................................11 80 1. Introduction 82 EAP-FAST [EAP-FAST] is an extensible EAP method [RFC3748] that can be 83 used to mutually authenticate peer and server as well as provisioning 84 information such as user credentials. [FAST-PROVISION] defines how 85 EAP-FAST is used to enable dynamic or in-band provisioning and 86 demonstrates how other EAP authentication methods may be used inside 87 the protected tunnel to ensure mutual authentication prior to 88 provisioning. 90 As EAP-FAST enables any inner EAP method to be used, this document 91 describes how EAP Protected-OTP [EAP-POTP] may be employed within 92 EAP-FAST Provisioning to ensure mutual authentication during in-band 93 provisioning. 95 2. Authenticating with EAP-POTP in EAP-FAST for provisioning 97 Once a protected tunnel is established as defined in [FAST- 98 PROVISION], the peer must authenticate itself to the server before 99 the server can provision the peer. Use of EAP-POTP is negotiated 100 between the server and the peer. After the peer responds with a EAP 101 Payload TLV containing the EAP Identity Response, the server MAY 102 request the use of EAP-POTP as the inner EAP authentication method. 104 EAP-POTP allows a protected authentication based on a pre-shared 105 secret provisioned into a one-time password generating token. 106 Possession of the token and an optional PIN value, provides a 107 portable strong authenticator. The EAP-POTP method is an end-to-end 108 authentication method that requires both parties to know the one-time 109 password generated by the token based on that shared secret. This 110 information allows a method of secure provisioning that does not 111 require a user-memorized or static password. Details of the EAP-POTP 112 method can be found in [EAP-POTP]. 114 The server MAY use EAP-POTP as the inner EAP authentication in either 115 Server-Authenticated or Server-Unauthenticated provisioning modes. 117 3. Cryptographic Calculations 119 The Key derivations for establishing the tunnel are as defined in 120 [EAP-FAST] Section 5. The Intermediate Compound Key Derivation 121 following a successful EAP-POTP authentication within EAP-FAST for 122 provisioning is defined in [FAST-PROVISION] Section 5.2 using the 123 resulting MSK as described in [EAP-POTP] Section 4.5. 125 4. Security Considerations 127 Though EAP-POTP, like EAP-MSCHAPv2 is a username and password based 128 authentication mechanism, it provides several features that 129 strengthen its security: 131 * The current one-time password is not exchanged, but instead, 132 authentication is based on values derived from the password, nonces 133 from each side and inputs including the session instance information. 135 * The authentication processes can be configured for various sizes of 136 hash and iteration inputs, to slow active attacks. 138 * The method is resistant to man-in-the-middle attacks because of 139 cryptographic bindings to the network messages. 141 * The method requires mutual authentication of the derived values. 143 EAP-POTP derives its session keys using a multi-state hashing 144 function (PBKDF2) [PKCS5] whose input is based on the token code, PIN 145 input, a random or pre-shared secret, an iteration count and 146 information about the server, and derives an authentication value for 147 transmittal. 149 It also keeps a hash of the running EAP request and response 150 messages, using an SHA256 function. The hash values are combined with 151 the generated keys, to cryptographically bind the authentication to 152 the current message stream and mutually authenticate. 154 When using EAP-POTP as the inner method, the server can only validate 155 this value by knowing all of the same inputs. Any man-in-the-middle 156 change would affect the derived value and cause a failure. 158 When using EAP-POTP during dynamic EAP-FAST provisioning, session 159 resumption credentials MUST NOT be used for authentication. 161 Due to the mutual authentication and key establishment provided by 162 EAP-POTP, Server-Unauthenticated Provisioning Mode MAY be used when 163 EAP-POTP is used for PAC provisioning 165 5. IANA Considerations 167 This specification requires no new IANA values to be assigned. [RFC 168 2434] 170 6. Acknowledgments 172 Thanks to Hao Zhou, Magnus Nystrom, and Dmitri Pal for their valuable 173 input. 175 This document was prepared using 2-Word-v2.0.template.dot. 177 7. References 179 7.1. Normative References 181 [EAP-FAST] Cam-Winget, N., et al., "The Flexible Authentication via 182 Secure Tunneling Extensible Authentication Protocol (EAP- 183 FAST)", RFC 4851, May 2007. 185 [FAST-PROVISION] Cam-Winget, N. et al., "Dynamic Provisioning via 186 Secure Tunneling Extensible Authentication Protocol (EAP- 187 FAST)", draft-cam-winget-eap-fast-provisioning-06 (work in 188 progress), February 2008. 190 [EAP-POTP] Nystrom M., "The EAP Protected One-Time Password Protocol 191 (EAP-POTP)", RFC 4793, February 2007. 193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, March 1997. 196 7.2. Informative References 198 [RFC3748] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J., and 199 H.Levkowetz, Ed., "Extensible Authentication Protocol 200 (EAP)", RFC 3748, June 2004. 202 [PKCS5] RSA Laboratories, "Password-Based Cryptography Standard", 203 PKCS #5 v2.0, March 1999. 205 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 206 Technology", RFC 3979, March 2005. 208 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, 209 March 2005. 211 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an 212 IANA Considerations Section in RFCs", RFC 2434, October 213 1998. 215 8. Author's Addresses 217 Nancy Cam-Winget 218 Cisco Systems Inc. 219 3625 Cisco Way 220 San Jose, CA 95134 222 Email: ncamwing@cisco.com 224 David Mitton 225 RSA Security Division of EMC 226 174 Middlesex Turnpike 227 Bedford, MA 01730 229 Email: dmitton@rsasecurity.com 231 APPENDIX A: Example of a successful Tunnel PAC provisioning using EAP- 232 POTP mutual authentication 234 The following exchanges show anonymous DH with a successful EAP-POTP 235 exchange within Phase 2 to provision a Tunnel PAC, the conversation 236 will appear as follows: 238 Authenticating Peer Authenticator 239 ------------------- ------------- 240 <- EAP-Request/ 241 Identity 242 EAP-Response/ 243 Identity (MyID1) -> 244 <- EAP-Request/ 245 EAP-Type=EAP-FAST, V=1 246 (EAP-FAST Start, S bit set, A-ID) 248 EAP-Response/ 249 EAP-Type=EAP-FAST, V=1 250 (TLS client_hello without 251 PAC-Opaque extension)-> 252 <- EAP-Request/ 253 EAP-Type=EAP-FAST, V=1 254 (TLS server_hello, 255 TLS Server Key Exchange 256 TLS Server Hello Done) 257 EAP-Response/ 258 EAP-Type=EAP-FAST, V=1 -> 259 (TLS Client Key Exchange 260 TLS change_cipher_spec, 261 TLS finished) 263 <- EAP-Request/ 264 EAP-Type=EAP-FAST, V=1 265 (TLS change_cipher_spec 266 TLS finished) 267 EAP-Response/ 268 EAP-Type=EAP-FAST, V=1 -> 269 (Acknowledgement) 271 TLS channel established 272 (messages sent within the TLS channel) 274 <- EAP Payload TLV, 275 EAP-Request/ 276 EAP Identity Request 278 EAP Payload TLV, EAP-Response/ 279 EAP Identity Response -> 281 <- EAP Payload TLV, 282 EAP-Request, 283 OTP-X, 284 Version TLV: 285 Highest=0, Lowest=0 286 Server-Info TLV: N=0 287 Session Identifier=V1 288 Session Identifier=V2 289 Nonce=V3 290 OTP TLV: 291 P=1,C=0,N=0,T=0,E=0,R=0 292 Pepper Length=0 293 Iteration Count=V4 295 EAP Payload TLV, -> 296 EAP-Response, 297 OTP-X, 298 Version TLV: 299 Highest=0 300 OTP TLV: 301 P=1,C=0,N=0,T=0,E=0,R=0 302 Iteration Count=V4 303 Authentication Data=V5 304 User Identifier TLV: 305 User Identifier=V6 306 Token Key Identifier TLV: 307 Token Key Identifier=V7 308 <- EAP Payload TLV, 309 EAP-Request, 310 OTP-X, 311 Confirm TLV: 312 C=0 313 Authentication Data=V8 314 Pepper Identifier=V9 315 Encrypted Pepper=V10 317 EAP Payload TLV, -> 318 EAP-Response, 319 OTP-X, 320 Confirm TLV: 321 (no data) 322 <- Intermediate Result TLV (Success) 323 Crypto-Binding-TLV(Version=1, 324 EAP-FAST Version=1, SNonce, 325 CompoundMAC) 327 Intermediate Result TLV (Success) 328 Crypto-Binding-TLV(Version=1, 329 EAP-FAST Version=1, 330 CNonce, CompoundMAC), 331 PAC TLV (PAC-Type=User Authorization PAC)-> 332 <- Result TLV (Success) 333 PAC TLV 335 Result TLV (Success) 336 PAC Acknowledgment -> 338 TLS channel torn down 339 (messages sent in cleartext) 341 <- EAP-Success 343 Intellectual Property Statement 345 The IETF takes no position regarding the validity or scope of any 346 Intellectual Property Rights or other rights that might be claimed to 347 pertain to the implementation or use of the technology described in 348 this document or the extent to which any license under such rights 349 might or might not be available; nor does it represent that it has 350 made any independent effort to identify any such rights. Information 351 on the procedures with respect to rights in RFC documents can be 352 found in BCP 78 and BCP 79. 354 Copies of IPR disclosures made to the IETF Secretariat and any 355 assurances of licenses to be made available, or the result of an 356 attempt made to obtain a general license or permission for the use of 357 such proprietary rights by implementers or users of this 358 specification can be obtained from the IETF on-line IPR repository at 359 http://www.ietf.org/ipr. 361 The IETF invites any interested party to bring to its attention any 362 copyrights, patents or patent applications, or other proprietary 363 rights that may cover technology that may be required to implement 364 this standard. Please address the information to the IETF at 365 ietf-ipr@ietf.org. 367 Disclaimer of Validity 369 This document and the information contained herein are provided on an 370 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 371 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 372 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 373 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 374 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 375 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 377 Copyright Statement 379 Copyright (C) The IETF Trust (2008). 381 This document is subject to the rights, licenses and restrictions 382 contained in BCP 78, and except as set forth therein, the authors 383 retain all their rights. 385 Acknowledgment 387 Funding for the RFC Editor function is currently provided by the 388 Internet Society.