a (incomplete) implementation of draft-sheffer-ikev2-gtc-00.txt using PAM
[strongswan.git] / doc / standards / draft-sheffer-ikev2-gtc-00.txt
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