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