idnits 2.17.00 (12 Aug 2021) /tmp/idnits36258/draft-sheffer-ikev2-gtc-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 364. 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 (July 6, 2008) is 5060 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-03) exists of draft-dekok-radext-dtls-00 == Outdated reference: A later version (-13) exists of draft-nir-tls-eap-03 -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Check Point 4 Intended status: Informational July 6, 2008 5 Expires: January 7, 2009 7 Using EAP-GTC for Simple User Authentication in IKEv2 8 draft-sheffer-ikev2-gtc-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2009. 35 Abstract 37 Despite many years of effort, simple username-password authentication 38 is still prevalent. In many cases a password is the only credential 39 available to the end user. IKEv2 uses EAP as a sub-protocol for user 40 authentication. This provides a well-specified and extensible 41 architecture. To this day EAP does not provide a simple password- 42 based authentication method. The only existing password 43 authentication methods either require the peer to know the password 44 in advance (EAP-MD5), or are needlessly complex when used within 45 IKEv2 (e.g. PEAP). This document codifies the common practice of 46 using EAP-GTC for this type of authentication, with the goal of 47 achieving maximum interoperability. The various security issues are 48 extensively analyzed. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Alternatives to EAP-GTC in IKEv2 . . . . . . . . . . . . . . . 4 55 3.1. Non-password credentials . . . . . . . . . . . . . . . . . 4 56 3.2. Using the IKE preshared secret . . . . . . . . . . . . . . 4 57 3.3. EAP-MD5 , EAP-MSCHAPv2 and mutual authentication 58 schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Using EAP-GTC in IKE: Details . . . . . . . . . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Key generation and MITM protection . . . . . . . . . . . . 6 63 6.2. Protection of credentials between the IKE gateway and 64 the AAA server . . . . . . . . . . . . . . . . . . . . . . 6 65 6.3. Server authentication . . . . . . . . . . . . . . . . . . . 6 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8 71 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 Intellectual Property and Copyright Statements . . . . . . . . . . 9 75 1. Introduction 77 "Oh dear! It's possible that we have added EAP to IKE to support a 78 case that EAP can't support." -- C. Kaufman. 80 Despite many years of effort, simple username-password authentication 81 is still prevalent. In many cases a password is the only credential 82 available to the end user. 84 IKEv2 [RFC4306] uses the Extensible Authentication Protocol (EAP) as 85 a sub-protocol for user authentication. This provides a well- 86 specified and extensible architecture and enables useful capabilities 87 like SIM authentication. Unfortunately, for a number of reasons EAP 88 still does not provide a simple password-based authentication method. 89 The only existing password authentication methods either require the 90 peer to know the password in advance (EAP-MD5), or are needlessly 91 complex when used within IKEv2 (e.g. PEAP). 93 Technically, the IKE preshared secret authentication mode can be used 94 for password authentication. In fact even the IKEv2 RFC winks at 95 this practice. But this use jeopardizes the protocol's security and 96 should clearly be avoided (more details below). 98 EAP is used in IKEv2 at a stage when the remote access gateway has 99 already been authenticated. At this point the user has a high enough 100 level of trust to send his or her password to the gateway. Such an 101 exchange is enabled by the EAP Generic Token Card (GTC) method, which 102 is a simple text transport between the two EAP peers. To quote 103 [RFC3748]: 105 The EAP GTC method is intended for use with the Token Cards 106 supporting challenge/response authentication and MUST NOT be used 107 to provide support for cleartext passwords in the absence of a 108 protected tunnel with server authentication. 110 IKEv2 does indeed provide "a protected tunnel with server 111 authentication". The current document updates [RFC3748] by making an 112 exception and allowing the use of GTC to carry secret credentials, in 113 this specific situation. Section 6 further elaborates on the 114 security properties of this solution. 116 Other protocols provide a similar protected tunnel, for example TLS- 117 EAP, described in [I-D.nir-tls-eap]. These protocols however are out 118 of scope for this document. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Alternatives to EAP-GTC in IKEv2 128 This section presents a few of the alternatives to EAP-GTC, and 129 explains why they are either insecure or impractical given today's 130 common identity management infrastructure. 132 3.1. Non-password credentials 134 Certificate-based authentication, especially when combined with 135 hardware protection (e.g. a hardware token), can be deployed in a 136 more secure manner than the form of password authentication which we 137 discuss. However, due to a host of issues to do with cost, 138 inconvenience and reliability this solution has not gained wide 139 market acceptance over the last 10 years. 141 3.2. Using the IKE preshared secret 143 Sec. 2.15 of RFC 4306 points out that the generation of the IKE 144 preshared secret from a weak password is insecure. Such use is 145 vulnerable to off line password guessing by an active attacker. All 146 the attacker needs to do is respond correctly to the first IKE_INIT 147 message, and then record the third IKE message. This is then 148 followed by a dictionary attack to obtain the password. 150 3.3. EAP-MD5 , EAP-MSCHAPv2 and mutual authentication schemes 152 Challenge-response schemes, like EAP-MD5 and EAP-MSCHAPv2, have a 153 clear security advantage over sending the plaintext password to the 154 gateway. Password-based mutual authentication schemes like SRP have 155 a further advantage in that the gateway's authentication is much 156 stronger than when using certificates alone, since the AAA server 157 proves its knowledge of a per-client credential, and the gateway 158 proves that it has been authorized by the AAA server for that 159 particular client. 161 Unfortunately all of these methods also suffer from a major drawback: 162 the gateway must have a priori access to the plaintext password. 163 While many RADIUS servers may indeed have such access, other very 164 common deployments do not provide it. One typical example is when 165 the gateway directly accesses an LDAP directory (or a Microsoft 166 Active Directory) to authenticate the user. The usual way to do that 167 is by issuing an LDAP Bind operation into the directory, using the 168 just-received plaintext password. Often in this case it is the IKE 169 gateway that terminates the EAP protocol, and it needs a way to 170 obtain the raw password. 172 An additional issue with mutual authentication schemes is their heavy 173 IP encumbrance, which has resulted in a scarcity of standards using 174 them and a low rate of market adoption. 176 4. Using EAP-GTC in IKE: Details 178 EAP-GTC is specified in [RFC3748], Sec. 5.6. This section is non- 179 normative, and is merely an interpretation of this specification in 180 the context of IKEv2. 182 Simple authentication requires a non secret identity ("user name") 183 and a secret credential ("password"). Both of these are arbitrary 184 Unicode strings, although implementations may impose length 185 constraints. 187 In the case of EAP-GTC, the user name is conveyed in the IKE IDi 188 payload. According to [RFC4718], Sec. 3.4, the user name can be 189 encoded in one of two ways: as a simple user name, in which case the 190 ID_KEY_ID identification type is used; or as a combination user name 191 plus realm, in which case the format is a NAI [RFC4282] and the 192 identification type is ID_RFC822_ADDR. In either case, the user name 193 is a Unicode string encoded as UTF-8. Using the EAP Identity payload 194 is redundant, and if it is used, it should be identical to the IDi 195 payload. 197 EAP-GTC consists of a simple 2-message exchange. The contents of the 198 Type-Data field in the Request should not be interpreted in any way, 199 and should be displayed to the user. This field contains a Unicode 200 string, encoded as UTF-8. 202 The password is sent in the EAP Response. The Type-Data field of the 203 Response is also a Unicode string encoded as UTF-8. Note that none 204 of the IDi payload, the EAP Request or the EAP Response is null- 205 terminated. 207 If either or both the user name and the password are non-ASCII, they 208 should be normalized by the IKE client before the IKE/EAP message is 209 constructed. The normalization method is SASLprep, [RFC4013]. 211 5. IANA Considerations 213 This document does not require any action by IANA. 215 6. Security Considerations 217 6.1. Key generation and MITM protection 219 Modern EAP methods generate a key shared between the two protocol 220 peers. GTC does not (and cannot) generate such a key. RFC 4306 221 mandates that: 223 EAP methods that do not establish a shared key SHOULD NOT be used, 224 as they are subject to a number of man-in-the-middle attacks 225 [EAPMITM] if these EAP methods are used in other protocols that do 226 not use a server-authenticated tunnel. 228 However GTC must never be used in such a situation, since the client 229 would be sending its credentials openly to an unauthenticated server. 230 When using GTC with IKEv2, the implementation (or local 231 administrators) MUST ensure that the same credentials are never used 232 in such a manner. 234 6.2. Protection of credentials between the IKE gateway and the AAA 235 server 237 In the proposed solution, the raw credentials are sent from the IKE 238 gateway to a AAA server, typically a RADIUS server. These 239 credentials and the associated messaging MUST be strongly protected. 240 Some of the existing options include: 241 o An IPsec tunnel between the gateway and the AAA server. 242 o RADIUS over TCP with TLS, [I-D.winter-radsec]. 243 o RADIUS over UDP with DTLS, [I-D.dekok-radext-dtls] (expired). 244 The legacy RADIUS security mechanism (Sec. 5.2 of [RFC2865]) is 245 considered weak and SHOULD NOT be used when better alternatives are 246 available. 248 6.3. Server authentication 250 The client may only send its cleartext credentials after it has 251 positively authenticated the server. This authentication is 252 specified, albeit rather vaguely, in [RFC4306] and is out of scope of 253 the current document. Unauthenticated (BTNS) derivatives of IKE MUST 254 NOT be used with EAP-GTC. 256 7. Acknowledgments 258 I would like to thank Yoav Nir and Charlie Kaufman for their helpful 259 comments. 261 8. References 263 8.1. Normative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, March 1997. 268 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 269 Levkowetz, "Extensible Authentication Protocol (EAP)", 270 RFC 3748, June 2004. 272 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 273 and Passwords", RFC 4013, February 2005. 275 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 276 RFC 4306, December 2005. 278 8.2. Informative References 280 [EAPMITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 281 in Tunneled Authentication Protocols", November 2002, 282 . 284 [I-D.dekok-radext-dtls] 285 DeKok, A., "DTLS as a Transport Layer for RADIUS", 286 draft-dekok-radext-dtls-00 (work in progress), 287 February 2007. 289 [I-D.nir-tls-eap] 290 Nir, Y., Tschofenig, H., and P. Gutmann, "TLS using EAP 291 Authentication", draft-nir-tls-eap-03 (work in progress), 292 April 2008. 294 [I-D.winter-radsec] 295 Winter, S., McCauley, M., and S. Venaas, "RadSec Version 2 296 - A Secure and Reliable Transport for the RADIUS 297 Protocol", draft-winter-radsec-01 (work in progress), 298 February 2008. 300 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 301 "Remote Authentication Dial In User Service (RADIUS)", 302 RFC 2865, June 2000. 304 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 305 Network Access Identifier", RFC 4282, December 2005. 307 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 308 Implementation Guidelines", RFC 4718, October 2006. 310 Appendix A. Change Log 312 A.1. -00 314 Initial version. 316 Author's Address 318 Yaron Sheffer 319 Check Point Software Technologies Ltd. 320 5 Hasolelim St. 321 Tel Aviv 67897 322 Israel 324 Email: yaronf@checkpoint.com 326 Full Copyright Statement 328 Copyright (C) The IETF Trust (2008). 330 This document is subject to the rights, licenses and restrictions 331 contained in BCP 78, and except as set forth therein, the authors 332 retain all their rights. 334 This document and the information contained herein are provided on an 335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 337 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 338 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 339 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 342 Intellectual Property 344 The IETF takes no position regarding the validity or scope of any 345 Intellectual Property Rights or other rights that might be claimed to 346 pertain to the implementation or use of the technology described in 347 this document or the extent to which any license under such rights 348 might or might not be available; nor does it represent that it has 349 made any independent effort to identify any such rights. Information 350 on the procedures with respect to rights in RFC documents can be 351 found in BCP 78 and BCP 79. 353 Copies of IPR disclosures made to the IETF Secretariat and any 354 assurances of licenses to be made available, or the result of an 355 attempt made to obtain a general license or permission for the use of 356 such proprietary rights by implementers or users of this 357 specification can be obtained from the IETF on-line IPR repository at 358 http://www.ietf.org/ipr. 360 The IETF invites any interested party to bring to its attention any 361 copyrights, patents or patent applications, or other proprietary 362 rights that may cover technology that may be required to implement 363 this standard. Please address the information to the IETF at 364 ietf-ipr@ietf.org.