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