idnits 2.17.1 draft-zhou-emu-fast-gtc-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 446. 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 (November 1, 2008) is 5648 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Cam-Winget 3 Internet-Draft H. Zhou 4 Intended status: Informational Cisco Systems 5 Expires: May 5, 2009 November 1, 2008 7 Basic Password Exchange within the Flexible Authentication via Secure 8 Tunneling Extensible Authentication Protocol (EAP-FAST) 9 draft-zhou-emu-fast-gtc-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 5, 2009. 36 Abstract 38 The flexible authentication via secure tunneling EAP method (EAP- 39 FAST) enables secure communication between a peer and a server by 40 using Transport Layer Security (TLS) to establish a mutually 41 authenticated tunnel. Within this tunnel a basic password exchange, 42 based on the generic token card method (EAP-GTC), may be executed to 43 authenticate the peer. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Specification Requirements . . . . . . . . . . . . . . . . 3 50 2. EAP-FAST GTC Authentication . . . . . . . . . . . . . . . . . 4 52 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 53 3.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 8 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 61 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 64 Intellectual Property and Copyright Statements . . . . . . . . . . 13 66 1. Introduction 68 EAP-FAST [RFC4851] is an EAP method that can be used to mutually 69 authenticate peer and server. This document describes the EAP-FAST 70 inner EAP method, EAP-FAST-GTC, which is used to authenticate the 71 peer through a basic password exchange. EAP-FAST-GTC was developed 72 to support using clear text passwords to authenticate to legacy user 73 databases, to facilitate password change and to support one time 74 password features such as new pin mode. Message exchanges, including 75 user credentials, are clear text strings transferred within the 76 encrypted TLS tunnel and thus are considered secure. For historical 77 reasons, EAP-FAST-GTC uses EAP Type 6, originally allocated to EAP- 78 GTC [RFC3748]. Note that EAP-FAST-GTC payloads used in EAP-FAST 79 require specific formatting and therefore will not necessarily be 80 compatible with EAP-GTC mechanisms used outside of EAP-FAST. To 81 avoid interference between these two methods, EAP-FAST-GTC MUST NOT 82 be used outside an EAP-FAST tunnel, and EAP-GTC MUST NOT be used 83 inside an EAP-FAST tunnel. All EAP-FAST-GTC packets sent within the 84 TLS tunnel must be encapsulated in EAP Payload TLVs, described in 85 [RFC4851]. 87 It is assumed that reader of this document is familiar with EAP-FAST 88 [RFC4851]. 90 1.1. Specification Requirements 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. EAP-FAST GTC Authentication 98 All EAP-FAST-GTC packets inside EAP-FAST other than the empty 99 acknowledgment packet MUST follow the "LABEL=Value" format. All 100 Labels are in ASCII text and SHALL NOT contain the space character. 101 Currently, three Labels are defined: 103 o "CHALLENGE", the server request packet MUST be in the form of 104 "CHALLENGE=Value", where Value is the server challenge, such as 105 "please enter your password." 107 o "RESPONSE", the peer response packet MUST be in the form of 108 "RESPONSE=Value", where Value is the peer response. 110 o "E", the server failure packet MUST be in the form of "E=Value", 111 where Value is the error message generated by the server. 113 If the peer or the server receives an EAP-FAST-GTC request or 114 response that is not in the format specified above, it SHOULD fail 115 the authentication by sending a Result TLV with a failure. 117 After the TLS encryption tunnel is established and EAP-FAST 118 Authentication Phase 2 starts, the EAP Server sends an EAP-FAST-GTC 119 Request, which contains a server challenge. The server challenge is 120 a displayable message for use by the peer to prompt the user. 122 A peer MAY prompt the user for the user credentials, or decide to use 123 the user credentials gained through some other means without 124 prompting the user. The peer sends the user credentials back in the 125 EAP-FAST-GTC Response using the following format: 127 "RESPONSE=user@example.com\0secret" 129 where "user@example.com" is the actual user name and "secret" is the 130 actual password. The NULL character "\0" is used to separate the 131 user name and password. 133 The username and password are included in a single message in the 134 first response packet as an optimization by eliminating the inner 135 method EAP-Identity exchange to save an extra round trip. 137 Once the EAP-FAST server receives the user credentials, it SHOULD 138 first validate the user identity with the I-ID 139 [I-D.cam-winget-eap-fast-provisioning] in the PAC-Opaque and if it 140 matches, it will continue to authenticate the user with internal or 141 external user databases. 143 Additional exchanges MAY occur between the EAP-FAST server and peer 144 to facilitate various user authentications. The EAP-FAST server 145 might send additional challenges to prompt the peer for additional 146 information, such as request for next token or new pin in the one 147 time password case, or server failure packet to indicate error. The 148 peer displays the prompt to the user again and sends back the needed 149 information in an EAP-FAST-GTC Response. The exchange ends when a 150 Result TLV is received. 152 An EAP-FAST-GTC server implementation within EAP-FAST uses the 153 following format to indicate error if an authentication fails: 155 "E=eeeeeeeeee R=r M=" 157 where 159 The "eeeeeeeeee" is the ASCII representation of a decimal error code 160 corresponding to one of those listed below, though peer 161 implementations SHOULD deal with codes not on this list gracefully. 162 The error code need not be 10 digits long. 164 Below is a complete list of predefined error codes: 166 o 646 ERROR_RESTRICTED_LOGON_HOURS 168 Indicates that access is attempted outside the allowed hours. 169 Peer implementation SHOULD display the error message to the user 170 and ask the user to try in a later time. 172 o 647 ERROR_ACCT_DISABLED 174 Indicates the requested account is disabled. Peer implementation 175 SHOULD display the error message to the user, which helps the user 176 to resolve the issue with the administrator. 178 o 648 ERROR_PASSWD_EXPIRED 180 Indicates the password has expired and password change is 181 required. Peer implementation SHOULD prompt user for a new 182 password and send back the new password in the peer response 183 packet. 185 o 649 ERROR_NO_DIALIN_PERMISSION 187 Indicates that access has been denied due to lack of dial in 188 permission. Peer implementation SHOULD display the error message 189 to the user, which helps the user to resolve the issue with the 190 administrator. 192 o 691 ERROR_AUTHENTICATION_FAILURE 194 Indicates authentication failure due to incorrect user name or 195 password. Base on the retry flag described below, peer 196 implementation MAY prompt the user again for a new set of user 197 name and password or simply send back an empty acknowledgment 198 packet to acknowledge the failure and go into termination phase of 199 the authentication session. 201 o 709 ERROR_CHANGING_PASSWORD 203 Indicates password change failed, most likely because the new 204 password fails to meet the password complexity policy. Peer 205 implementation SHOULD display the error message and prompt the 206 user again for the new password. 208 o 755 ERROR_PAC_I-ID_NO_MATCH 210 Indicates that the PAC used to establish the EAP-FAST session 211 cannot be used to authenticate to this user account. Base on the 212 retry flag described below, peer implementation MAY prompt the 213 user again for a new set of user name and password or simply send 214 back an empty acknowledgment packet to acknowledge the failure and 215 go into termination phase of the authentication session. 217 The "r" is a single character ASCII flag set to '1' if a retry is 218 allowed, and '0' if not. When the server sets this flag to '1' it 219 disables short timeouts, expecting the peer to prompt the user for 220 new credentials and resubmit the response. When the server sets this 221 flag to '0' the peer SHOULD NOT prompt the user for new credentials 222 to try again without restarting the EAP-FAST authentication from the 223 beginning. 225 The is human-readable ASCII text. Current implementations only 226 support ASCII text. 228 The server failure packet can be broken into label/value pair using 229 the space character as the separator. The only value may contain the 230 space character is the value, which is always the last value 231 pair in the failure packet. Peer SHOULD ignore any unknown label/ 232 value pair in the failure packet. 234 The error format described above is similar to what are defined in 235 MSCHAPv2 [RFC2759], except for the omission of server challenge. So 236 if the EAP-FAST Server is distributing MSCHAPV2 exchanges to the 237 backend inner method server, it can simply just return what the 238 backend inner method server returns less the server challenge. In 239 the case of connecting to an one time password or LDAP [RFC4511] 240 server, the EAP-FAST Server can format the error message into this 241 format. With the addition of the retry count, peer can potentially 242 prompt the user for new credentials to try again without restarting 243 the EAP-FAST authentication from the beginning. Peer will respond to 244 the error code with another EAP-FAST-GTC Response packet with both 245 the new user name and password or in case of other unrecoverable 246 failures, an empty EAP-FAST-GTC packet for acknowledgement. Peer 247 uses empty EAP-FAST-GTC payload as an acknowledgment to the 248 unrecoverable failure. 250 If the EAP-FAST server finishes authentication for EAP-FAST-GTC inner 251 method, it will proceed to Protected Termination as described in 252 [RFC4851]. In the case of an unrecoverable EAP-FAST-GTC 253 authentication failure, the EAP server can send an EAP-FAST-GTC error 254 code as described above, along with the Result TLV for protected 255 termination. This way, no extra round trips will occur. The peer 256 can acknowledge the EAP-FAST-GTC failure as well as the Result TLV 257 within the same EAP-FAST packet. Once server receives the 258 acknowledgement, the TLS tunnel will be torn down and a clear text 259 EAP-Failure will be sent. 261 The user name and password, as well as server challenges MAY support 262 non-ASCII characters. In this case, international user name, 263 password, and messages are based on the use of Unicode characters, 264 encoded as UTF-8 [RFC3629] and processed with a certain algorithm to 265 ensure a canonical representation. The input SHOULD be processed 266 according to [RFC5198]. 268 Since EAP-FAST-GTC does not generate session keys, the MSKi used for 269 crypto-binding for EAP-FAST will be filled with all zeros. 271 3. Security Considerations 273 The EAP-FAST-GTC method sends password information in the clear and 274 MUST NOT be used outside of a protected tunnel providing strong 275 protection such as the one provided by EAP-FAST. Weak encryption 276 such as, 40-bit encryption or NULL cipher, MUST NOT be used. In 277 addition, the peer MUST authenticate the server before disclosing its 278 credentials. Since EAP-FAST Server-Unauthenticated Provisioning Mode 279 does not authenticate the server, EAP-FAST-GTC MUST NOT be used as 280 the inner method in this mode. EAP-FAST-GTC MAY be used in EAP-FAST 281 authentication and Server-Authenticated Provisioning Mode 282 [I-D.cam-winget-eap-fast-provisioning], where the server is 283 authenticated. Since EAP-FAST-GTC requires the server to have access 284 to the actual authentication secret, it is RECOMMENDED to vary the 285 stored authentication validation data by domain so that a compromise 286 of a server at one location does not compromise others. 288 3.1. Security Claims 290 This section provides the needed security claim requirement for EAP 291 [RFC3748]. 293 Auth. mechanism: Password based. 294 Ciphersuite negotiation: Yes. Provided by the EAP-FAST Tunnel. 295 Mutual authentication: Yes. Peer is authenticated by the password 296 and server is authenticated by certificate 297 or shared secret. 298 Integrity protection: Yes, Any method executed within the EAP-FAST 299 tunnel is integrity protected. The 300 cleartext EAP headers outside the tunnel are 301 not integrity protected. 302 Replay protection: Yes. Provided by the EAP-FAST Tunnel. 303 Confidentiality: Yes. Provided by the EAP-FAST Tunnel. 304 Key derivation: Yes. Provided by the EAP-FAST Tunnel. 305 Key strength: See Section 7.8 of [RFC4851]. 306 Dictionary attack prot.: Yes. Provided by the EAP-FAST Tunnel. 307 Fast reconnect: Yes. 308 Cryptographic binding: Yes. Provided by the EAP-FAST Tunnel. 309 Session independence: Yes. Provided by the EAP-FAST Tunnel. 310 Fragmentation: Yes. Provided by the EAP-FAST Tunnel. 311 Key Hierarchy: Yes. Provided by the EAP-FAST Tunnel. 312 Channel binding: No, but TLVs could be defined for this. 314 4. IANA Considerations 316 EAP-FAST-GTC uses the assigned value of 6 (EAP-GTC) for the EAP Type 317 in [RFC3748]. 319 The document defines a registry for EAP-FAST-GTC error codes when 320 running inside EAP-FAST, named "EAP-FAST GTC Error Codes". It may be 321 assigned by Specification Required as defined in [RFC5226]. A 322 summary of the error codes defined so far is given below: 324 o 646 ERROR_RESTRICTED_LOGON_HOURS 326 o 647 ERROR_ACCT_DISABLED 328 o 648 ERROR_PASSWD_EXPIRED 330 o 649 ERROR_NO_DIALIN_PERMISSION 332 o 691 ERROR_AUTHENTICATION_FAILURE 334 o 709 ERROR_CHANGING_PASSWORD 336 o 755 ERROR_PAC_I-ID_NO_MATCH 338 No IANA registry will be created for Labels, as current 339 implementations only support the Labels defined in this document and 340 new Labels are not expected; if necessary, new Labels can be defined 341 in documents updating this document. 343 5. Acknowledgments 345 The authors would like thank Joe Salowey, Amir Naftali for their 346 contributions of the problem space, and Jouni Malinen, Pasi Eronen, 347 Jari Arkko, Chris Newman for reviewing this document. 349 6. References 351 6.1. Normative References 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, March 1997. 356 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 357 10646", STD 63, RFC 3629, November 2003. 359 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 360 Levkowetz, "Extensible Authentication Protocol (EAP)", 361 RFC 3748, June 2004. 363 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 364 Flexible Authentication via Secure Tunneling Extensible 365 Authentication Protocol Method (EAP-FAST)", RFC 4851, 366 May 2007. 368 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 369 Interchange", RFC 5198, March 2008. 371 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 372 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 373 May 2008. 375 6.2. Informative References 377 [I-D.cam-winget-eap-fast-provisioning] 378 Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, 379 "Dynamic Provisioning using Flexible Authentication via 380 Secure Tunneling Extensible Authentication Protocol (EAP- 381 FAST)", draft-cam-winget-eap-fast-provisioning-10 (work in 382 progress), October 2008. 384 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 385 RFC 2759, January 2000. 387 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 388 (LDAP): The Protocol", RFC 4511, June 2006. 390 Authors' Addresses 392 Nancy Cam-Winget 393 Cisco Systems 394 3625 Cisco Way 395 San Jose, CA 95134 396 US 398 Email: ncamwing@cisco.com 400 Hao Zhou 401 Cisco Systems 402 4125 Highlander Parkway 403 Richfield, OH 44286 404 US 406 Email: hzhou@cisco.com 408 Full Copyright Statement 410 Copyright (C) The IETF Trust (2008). 412 This document is subject to the rights, licenses and restrictions 413 contained in BCP 78, and except as set forth therein, the authors 414 retain all their rights. 416 This document and the information contained herein are provided on an 417 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 418 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 419 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 420 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 421 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 422 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 424 Intellectual Property 426 The IETF takes no position regarding the validity or scope of any 427 Intellectual Property Rights or other rights that might be claimed to 428 pertain to the implementation or use of the technology described in 429 this document or the extent to which any license under such rights 430 might or might not be available; nor does it represent that it has 431 made any independent effort to identify any such rights. Information 432 on the procedures with respect to rights in RFC documents can be 433 found in BCP 78 and BCP 79. 435 Copies of IPR disclosures made to the IETF Secretariat and any 436 assurances of licenses to be made available, or the result of an 437 attempt made to obtain a general license or permission for the use of 438 such proprietary rights by implementers or users of this 439 specification can be obtained from the IETF on-line IPR repository at 440 http://www.ietf.org/ipr. 442 The IETF invites any interested party to bring to its attention any 443 copyrights, patents or patent applications, or other proprietary 444 rights that may cover technology that may be required to implement 445 this standard. Please address the information to the IETF at 446 ietf-ipr@ietf.org.