Using EAP-GTC for Simple User Authentication in IKEv2
draft-sheffer-ikev2-gtc-00.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 7, 2009.

Abstract

Despite many years of effort, simple username-password authentication is still prevalent. In many cases a password is the only credential available to the end user. IKEv2 uses EAP as a sub-protocol for user authentication. This provides a well-specified and extensible architecture. To this day EAP does not provide a simple password-based authentication method. The only existing password authentication methods either require the peer to know the password in advance (EAP-MD5), or are needlessly complex when used within IKEv2 (e.g. PEAP). This document codifies the common practice of using EAP-GTC for this type of authentication, with the goal of achieving maximum interoperability. The various security issues are extensively analyzed.

Table of Contents

1.  Introduction
2.  Terminology
3.  Alternatives to EAP-GTC in IKEv2
    3.1.  Non-password credentials
    3.2.  Using the IKE preshared secret
    3.3.  EAP-MD5 , EAP-MSCHAPv2 and mutual authentication schemes
4.  Using EAP-GTC in IKE: Details
5.  IANA Considerations
6.  Security Considerations
    6.1.  Key generation and MITM protection
    6.2.  Protection of credentials between the IKE gateway and the AAA server
    6.3.  Server authentication
7.  Acknowledgments
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Change Log
    A.1.  -00
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

"Oh dear! It's possible that we have added EAP to IKE to support a case that EAP can't support." -- C. Kaufman.

Despite many years of effort, simple username-password authentication is still prevalent. In many cases a password is the only credential available to the end user.

IKEv2 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) uses the Extensible Authentication Protocol (EAP) as a sub-protocol for user authentication. This provides a well-specified and extensible architecture and enables useful capabilities like SIM authentication. Unfortunately, for a number of reasons EAP still does not provide a simple password-based authentication method. The only existing password authentication methods either require the peer to know the password in advance (EAP-MD5), or are needlessly complex when used within IKEv2 (e.g. PEAP).

Technically, the IKE preshared secret authentication mode can be used for password authentication. In fact even the IKEv2 RFC winks at this practice. But this use jeopardizes the protocol's security and should clearly be avoided (more details below).

EAP is used in IKEv2 at a stage when the remote access gateway has already been authenticated. At this point the user has a high enough level of trust to send his or her password to the gateway. Such an exchange is enabled by the EAP Generic Token Card (GTC) method, which is a simple text transport between the two EAP peers. To quote [RFC3748] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.):

The EAP GTC method is intended for use with the Token Cards supporting challenge/response authentication and MUST NOT be used to provide support for cleartext passwords in the absence of a protected tunnel with server authentication.

IKEv2 does indeed provide "a protected tunnel with server authentication". The current document updates [RFC3748] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.) by making an exception and allowing the use of GTC to carry secret credentials, in this specific situation. Section 6 (Security Considerations) further elaborates on the security properties of this solution.

Other protocols provide a similar protected tunnel, for example TLS-EAP, described in [I‑D.nir‑tls‑eap] (Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, “TLS using EAP Authentication,” March 2010.). These protocols however are out of scope for this document.

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Alternatives to EAP-GTC in IKEv2

This section presents a few of the alternatives to EAP-GTC, and explains why they are either insecure or impractical given today's common identity management infrastructure.

3.1.  Non-password credentials

Certificate-based authentication, especially when combined with hardware protection (e.g. a hardware token), can be deployed in a more secure manner than the form of password authentication which we discuss. However, due to a host of issues to do with cost, inconvenience and reliability this solution has not gained wide market acceptance over the last 10 years.

3.2.  Using the IKE preshared secret

Sec. 2.15 of RFC 4306 points out that the generation of the IKE preshared secret from a weak password is insecure. Such use is vulnerable to off line password guessing by an active attacker. All the attacker needs to do is respond correctly to the first IKE_INIT message, and then record the third IKE message. This is then followed by a dictionary attack to obtain the password.

3.3.  EAP-MD5 , EAP-MSCHAPv2 and mutual authentication schemes

Challenge-response schemes, like EAP-MD5 and EAP-MSCHAPv2, have a clear security advantage over sending the plaintext password to the gateway. Password-based mutual authentication schemes like SRP have a further advantage in that the gateway's authentication is much stronger than when using certificates alone, since the AAA server proves its knowledge of a per-client credential, and the gateway proves that it has been authorized by the AAA server for that particular client.

Unfortunately all of these methods also suffer from a major drawback: the gateway must have a priori access to the plaintext password. While many RADIUS servers may indeed have such access, other very common deployments do not provide it. One typical example is when the gateway directly accesses an LDAP directory (or a Microsoft Active Directory) to authenticate the user. The usual way to do that is by issuing an LDAP Bind operation into the directory, using the just-received plaintext password. Often in this case it is the IKE gateway that terminates the EAP protocol, and it needs a way to obtain the raw password.

An additional issue with mutual authentication schemes is their heavy IP encumbrance, which has resulted in a scarcity of standards using them and a low rate of market adoption.

4.  Using EAP-GTC in IKE: Details

EAP-GTC is specified in [RFC3748] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.), Sec. 5.6. This section is non-normative, and is merely an interpretation of this specification in the context of IKEv2.

Simple authentication requires a non secret identity ("user name") and a secret credential ("password"). Both of these are arbitrary Unicode strings, although implementations may impose length constraints.

In the case of EAP-GTC, the user name is conveyed in the IKE IDi payload. According to [RFC4718] (Eronen, P. and P. Hoffman, “IKEv2 Clarifications and Implementation Guidelines,” October 2006.), Sec. 3.4, the user name can be encoded in one of two ways: as a simple user name, in which case the ID_KEY_ID identification type is used; or as a combination user name plus realm, in which case the format is a NAI [RFC4282] (Aboba, B., Beadles, M., Arkko, J., and P. Eronen, “The Network Access Identifier,” December 2005.) and the identification type is ID_RFC822_ADDR. In either case, the user name is a Unicode string encoded as UTF-8. Using the EAP Identity payload is redundant, and if it is used, it should be identical to the IDi payload.

EAP-GTC consists of a simple 2-message exchange. The contents of the Type-Data field in the Request should not be interpreted in any way, and should be displayed to the user. This field contains a Unicode string, encoded as UTF-8.

The password is sent in the EAP Response. The Type-Data field of the Response is also a Unicode string encoded as UTF-8. Note that none of the IDi payload, the EAP Request or the EAP Response is null-terminated.

If either or both the user name and the password are non-ASCII, they should be normalized by the IKE client before the IKE/EAP message is constructed. The normalization method is SASLprep, [RFC4013] (Zeilenga, K., “SASLprep: Stringprep Profile for User Names and Passwords,” February 2005.).

5.  IANA Considerations

This document does not require any action by IANA.

6.  Security Considerations

6.1.  Key generation and MITM protection

Modern EAP methods generate a key shared between the two protocol peers. GTC does not (and cannot) generate such a key. RFC 4306 mandates that:

EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject to a number of man-in-the-middle attacks [EAPMITM] (Asokan, N., Niemi, V., and K. Nyberg, “Man-in-the-Middle in Tunneled Authentication Protocols,” November 2002.) if these EAP methods are used in other protocols that do not use a server-authenticated tunnel.

However GTC must never be used in such a situation, since the client would be sending its credentials openly to an unauthenticated server. When using GTC with IKEv2, the implementation (or local administrators) MUST ensure that the same credentials are never used in such a manner.

6.2.  Protection of credentials between the IKE gateway and the AAA server

In the proposed solution, the raw credentials are sent from the IKE gateway to a AAA server, typically a RADIUS server. These credentials and the associated messaging MUST be strongly protected. Some of the existing options include:

• An IPsec tunnel between the gateway and the AAA server.
• RADIUS over TCP with TLS, [I‑D.winter‑radsec] (Winter, S., McCauley, M., and S. Venaas, “RadSec Version 2 - A Secure and Reliable Transport for the RADIUS Protocol,” February 2008.).
• RADIUS over UDP with DTLS, [I‑D.dekok‑radext‑dtls] (DeKok, A., “DTLS as a Transport Layer for RADIUS,” March 2010.) (expired).

The legacy RADIUS security mechanism (Sec. 5.2 of [RFC2865] (Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” June 2000.)) is considered weak and SHOULD NOT be used when better alternatives are available.

6.3.  Server authentication

The client may only send its cleartext credentials after it has positively authenticated the server. This authentication is specified, albeit rather vaguely, in [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) and is out of scope of the current document. Unauthenticated (BTNS) derivatives of IKE MUST NOT be used with EAP-GTC.

7.  Acknowledgments

I would like to thank Yoav Nir and Charlie Kaufman for their helpful comments.

8.  References

8.1. Normative References

8.2. Informative References

Appendix A.  Change Log

A.1.  -00

Initial version.

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.