idnits 2.17.1 draft-sheffer-ipsecme-ikev2-gtc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors Copyright Line does not match the current year -- The document date (February 27, 2010) is 5171 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-01 == Outdated reference: A later version (-05) exists of draft-ietf-ipsecme-eap-mutual-00 == Outdated reference: A later version (-13) exists of draft-nir-tls-eap-06 == Outdated reference: A later version (-09) exists of draft-sheffer-emu-eap-eke-04 -- 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 (~~), 5 warnings (==), 3 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 February 27, 2010 5 Expires: August 31, 2010 7 Using EAP-GTC for Simple User Authentication in IKEv2 8 draft-sheffer-ipsecme-ikev2-gtc-02.txt 10 Abstract 12 Despite many years of effort, simple username-password authentication 13 is still prevalent. In many cases a password is the only credential 14 available to the end user. IKEv2 uses EAP as a sub-protocol for user 15 authentication. This provides a well-specified and extensible 16 architecture. To this day EAP does not provide a simple password- 17 based authentication method. The only existing password 18 authentication methods either require the peer to know the password 19 in advance (EAP-MD5), or are needlessly complex when used within 20 IKEv2 (e.g. PEAP). This document codifies the common practice of 21 using EAP-GTC for this type of authentication, with the goal of 22 achieving maximum interoperability. The various security issues are 23 extensively analyzed. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 31, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Alternatives to EAP-GTC in IKEv2 . . . . . . . . . . . . . . . 4 67 3.1. Non-password credentials . . . . . . . . . . . . . . . . . 4 68 3.2. Using the IKE preshared secret . . . . . . . . . . . . . . 4 69 3.3. EAP-MD5 , EAP-MSCHAPv2 and mutual authentication 70 schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.4. Mutual "Zero Knowledge" Authentication . . . . . . . . . . 5 72 4. Using EAP-GTC in IKE: Details . . . . . . . . . . . . . . . . . 5 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 75 6.1. Key generation and MITM protection . . . . . . . . . . . . 6 76 6.2. Protection of credentials between the IKE gateway and 77 the AAA server . . . . . . . . . . . . . . . . . . . . . . 6 78 6.3. Server authentication . . . . . . . . . . . . . . . . . . . 7 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 83 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8 84 A.1. draft-sheffer-ipsecme-ikev2-gtc-02 . . . . . . . . . . . . 8 85 A.2. draft-sheffer-ipsecme-ikev2-gtc-01 . . . . . . . . . . . . 8 86 A.3. draft-sheffer-ipsecme-ikev2-gtc-00 . . . . . . . . . . . . 8 87 A.4. draft-sheffer-ikev2-gtc-00 . . . . . . . . . . . . . . . . 9 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 "Oh dear! It's possible that we have added EAP to IKE to support a 93 case that EAP can't support." -- C. Kaufman. 95 Despite many years of effort, simple username-password authentication 96 is still prevalent. In many cases a password is the only credential 97 available to the end user. 99 IKEv2 [RFC4306] uses the Extensible Authentication Protocol (EAP) as 100 a sub-protocol for user authentication. This provides a well- 101 specified and extensible architecture and enables useful capabilities 102 like SIM authentication. Unfortunately, for a number of reasons EAP 103 still does not provide a simple password-based authentication method. 104 The only existing password authentication methods either require the 105 peer to know the password in advance (EAP-MD5), or are needlessly 106 complex when used within IKEv2 (e.g. PEAP). 108 Technically, the IKE preshared secret authentication mode can be used 109 for password authentication. In fact even the IKEv2 RFC winks at 110 this practice. But this use jeopardizes the protocol's security and 111 should clearly be avoided (more details below). 113 EAP is used in IKEv2 at a stage when the remote access gateway has 114 already been authenticated. At this point the user has a high enough 115 level of trust to send his or her password to the gateway. Such an 116 exchange is enabled by the EAP Generic Token Card (GTC) method, which 117 is a simple text transport between the two EAP peers. To quote 118 [RFC3748]: 120 The EAP GTC method is intended for use with the Token Cards 121 supporting challenge/response authentication and MUST NOT be used 122 to provide support for cleartext passwords in the absence of a 123 protected tunnel with server authentication. 125 IKEv2 does indeed provide "a protected tunnel with server 126 authentication". The current document updates [RFC3748] by making an 127 exception and allowing the use of GTC to carry secret credentials, in 128 this specific situation. Section 6 further elaborates on the 129 security properties of this solution. 131 Other protocols provide a similar protected tunnel, for example TLS- 132 EAP, described in [I-D.nir-tls-eap]. These protocols however are out 133 of scope for this document. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Alternatives to EAP-GTC in IKEv2 143 This section presents a few of the alternatives to EAP-GTC, and 144 explains why they are either insecure or impractical given today's 145 common identity management infrastructure. 147 3.1. Non-password credentials 149 Certificate-based authentication, especially when combined with 150 hardware protection (e.g. a hardware token), can be deployed in a 151 more secure manner than the form of password authentication which we 152 discuss. However, due to a host of issues to do with cost, 153 inconvenience and reliability this solution has not gained wide 154 market acceptance over the last 10 years. 156 3.2. Using the IKE preshared secret 158 Sec. 2.15 of RFC 4306 points out that the generation of the IKE 159 preshared secret from a weak password is insecure. Such use is 160 vulnerable to off line password guessing by an active attacker. All 161 the attacker needs to do is respond correctly to the first IKE_INIT 162 message, and then record the third IKE message. This is then 163 followed by a dictionary attack to obtain the password. 165 3.3. EAP-MD5 , EAP-MSCHAPv2 and mutual authentication schemes 167 Challenge-response schemes, like EAP-MD5 and EAP-MSCHAPv2, have a 168 clear security advantage over sending the plaintext password to the 169 gateway. Password-based mutual authentication schemes like SRP have 170 a further advantage in that the gateway's authentication is much 171 stronger than when using certificates alone, since the AAA server 172 proves its knowledge of a per-client credential, and the gateway 173 proves that it has been authorized by the AAA server for that 174 particular client. 176 Unfortunately all of these methods also suffer from a major drawback: 177 the gateway must have a priori access to the plaintext password. 178 While many RADIUS servers may indeed have such access, other very 179 common deployments do not provide it. One typical example is when 180 the gateway directly accesses an LDAP directory (or a Microsoft 181 Active Directory) to authenticate the user. The usual way to do that 182 is by issuing an LDAP Bind operation into the directory, using the 183 just-received plaintext password. Often in this case it is the IKE 184 gateway that terminates the EAP protocol, and it needs a way to 185 obtain the raw password. 187 An additional issue with mutual authentication schemes is their heavy 188 IP encumbrance, which has resulted in a scarcity of standards using 189 them and a low rate of market adoption. 191 3.4. Mutual "Zero Knowledge" Authentication 193 Some newer EAP methods provide for mutual, password-based 194 authentication, without exposing the password to dictionary attacks 195 by either an eavesdropper or the (alleged) peer. An example is 196 [I-D.sheffer-emu-eap-eke]. Such EAP methods can be cleanly 197 integrated into IKEv2 by using the extension described in 198 [I-D.ietf-ipsecme-eap-mutual]. 200 In addition, the IPsecME working group is now chartered with 201 producing a similar authetication method directly over IKE, without 202 the need for supporting the EAP protocol. 204 Neither of these options is widely implemented today, if at all. 205 Either of them is superior to the method described in this document, 206 and implementors are strongly encouraged to migrate to these methods 207 as soon as they are standardized. 209 4. Using EAP-GTC in IKE: Details 211 EAP-GTC is specified in [RFC3748], Sec. 5.6. This section is non- 212 normative, and is merely an interpretation of this specification in 213 the context of IKEv2. 215 Simple authentication requires a non secret identity ("user name") 216 and a secret credential ("password"). Both of these are arbitrary 217 Unicode strings, although implementations may impose length 218 constraints. 220 In the case of EAP-GTC, the user name is conveyed in the IKE IDi 221 payload. According to [RFC4718], Sec. 3.4, the user name can be 222 encoded in one of two ways: as a simple user name, in which case the 223 ID_KEY_ID identification type is used; or as a combination user name 224 plus realm, in which case the format is a NAI [RFC4282] and the 225 identification type is ID_RFC822_ADDR. In either case, the user name 226 is a Unicode string encoded as UTF-8. Using the EAP Identity payload 227 is redundant, and if it is used, it should be identical to the IDi 228 payload. 230 EAP-GTC consists of a simple 2-message exchange. The contents of the 231 Type-Data field in the Request should not be interpreted in any way, 232 and should be displayed to the user. This field contains a Unicode 233 string, encoded as UTF-8. 235 The password is sent in the EAP Response. The Type-Data field of the 236 Response is also a Unicode string encoded as UTF-8. Note that none 237 of the IDi payload, the EAP Request or the EAP Response is null- 238 terminated. 240 If either or both the user name and the password are non-ASCII, they 241 should be normalized by the IKE client before the IKE/EAP message is 242 constructed. The normalization method is SASLprep, [RFC4013]. 244 5. IANA Considerations 246 This document does not require any action by IANA. 248 6. Security Considerations 250 6.1. Key generation and MITM protection 252 Modern EAP methods generate a key shared between the two protocol 253 peers. GTC does not (and cannot) generate such a key. RFC 4306 254 mandates that: 256 EAP methods that do not establish a shared key SHOULD NOT be used, 257 as they are subject to a number of man-in-the-middle attacks 258 [EAPMITM] if these EAP methods are used in other protocols that do 259 not use a server-authenticated tunnel. 261 However GTC must never be used in such a situation, since the client 262 would be sending its credentials openly to an unauthenticated server. 263 When using GTC with IKEv2, the implementation (or local 264 administrators) MUST ensure that the same credentials are never used 265 in such a manner. 267 6.2. Protection of credentials between the IKE gateway and the AAA 268 server 270 In the proposed solution, the raw credentials are sent from the IKE 271 gateway to a AAA server, typically a RADIUS server. These 272 credentials and the associated messaging MUST be strongly protected. 273 Some of the existing options include: 275 o An IPsec tunnel between the gateway and the AAA server. 276 o RADIUS over TCP with TLS, [I-D.winter-radsec]. 277 o RADIUS over UDP with DTLS, [I-D.dekok-radext-dtls] (expired). 278 The legacy RADIUS security mechanism (Sec. 5.2 of [RFC2865]) is 279 considered weak and SHOULD NOT be used when better alternatives are 280 available. 282 6.3. Server authentication 284 The client may only send its cleartext credentials after it has 285 positively authenticated the server. This authentication is 286 specified, albeit rather vaguely, in [RFC4306] and is out of scope of 287 the current document. Unauthenticated (BTNS) derivatives of IKE MUST 288 NOT be used with EAP-GTC. 290 7. Acknowledgments 292 I would like to thank Yoav Nir and Charlie Kaufman for their helpful 293 comments. 295 8. References 297 8.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 303 Levkowetz, "Extensible Authentication Protocol (EAP)", 304 RFC 3748, June 2004. 306 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 307 and Passwords", RFC 4013, February 2005. 309 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 310 RFC 4306, December 2005. 312 8.2. Informative References 314 [EAPMITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 315 in Tunneled Authentication Protocols", November 2002, 316 . 318 [I-D.dekok-radext-dtls] 319 DeKok, A., "DTLS as a Transport Layer for RADIUS", 320 draft-dekok-radext-dtls-01 (work in progress), June 2009. 322 [I-D.ietf-ipsecme-eap-mutual] 323 Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 324 for EAP-Only Authentication in IKEv2", 325 draft-ietf-ipsecme-eap-mutual-00 (work in progress), 326 February 2010. 328 [I-D.nir-tls-eap] 329 Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, "TLS 330 using EAP Authentication", draft-nir-tls-eap-06 (work in 331 progress), April 2009. 333 [I-D.sheffer-emu-eap-eke] 334 Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An 335 EAP Authentication Method Based on the EKE Protocol", 336 draft-sheffer-emu-eap-eke-04 (work in progress), 337 January 2010. 339 [I-D.winter-radsec] 340 Winter, S., McCauley, M., and S. Venaas, "RadSec Version 2 341 - A Secure and Reliable Transport for the RADIUS 342 Protocol", draft-winter-radsec-01 (work in progress), 343 February 2008. 345 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 346 "Remote Authentication Dial In User Service (RADIUS)", 347 RFC 2865, June 2000. 349 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 350 Network Access Identifier", RFC 4282, December 2005. 352 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 353 Implementation Guidelines", RFC 4718, October 2006. 355 Appendix A. Change Log 357 A.1. draft-sheffer-ipsecme-ikev2-gtc-02 359 Added a short discussion of newer password-based methods. 361 A.2. draft-sheffer-ipsecme-ikev2-gtc-01 363 Republished. 365 A.3. draft-sheffer-ipsecme-ikev2-gtc-00 367 Document renamed. 369 A.4. draft-sheffer-ikev2-gtc-00 371 Initial version. 373 Author's Address 375 Yaron Sheffer 376 Check Point Software Technologies Ltd. 377 5 Hasolelim St. 378 Tel Aviv 67897 379 Israel 381 Email: yaronf@checkpoint.com