<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
    <!ENTITY rfc2119 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc2865 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml'>
    <!ENTITY rfc3547 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3547.xml'>
    <!ENTITY rfc3748 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
    <!ENTITY rfc4086 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml'>
    <!ENTITY rfc4013 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4013.xml'>
    <!ENTITY rfc4282 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml'>
    <!ENTITY rfc4301 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
    <!ENTITY rfc4306 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'>
    <!ENTITY rfc4718 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4718.xml'>
    <!ENTITY rfc4478 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4478.xml'>
    <!ENTITY rfc4507 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4507.xml'>
    <!ENTITY rfc4555 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4555.xml'>
    <!ENTITY draft-dekok-radext-dtls PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dekok-radext-dtls.xml'>
    <!ENTITY draft-nir-tls-eap PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nir-tls-eap.xml'>
    <!ENTITY draft-winter-radsec PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winter-radsec.xml'>
]>
<rfc category="info" ipr="trust200902"
docName="draft-sheffer-ipsecme-ikev2-gtc-02.txt">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <?rfc compact="yes" ?>
  <front>
    <title abbrev="EAP-GTC in IKEv2">Using EAP-GTC for Simple User
    Authentication in IKEv2</title>
    <author initials="Y." surname="Sheffer"
    fullname="Yaron Sheffer">
      <organization abbrev="Check Point">Check Point Software
      Technologies Ltd.</organization>
      <address>
        <postal>
          <street>5 Hasolelim St.</street>
          <city>Tel Aviv</city>
          <code>67897</code>
          <country>Israel</country>
        </postal>
        <email>yaronf@checkpoint.com</email>
      </address>
    </author>
    <date year="2010" />
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <middle>
    <!-- ************************************************************************************ -->
    <section title="Introduction">
    <t>"Oh dear! It's possible that we have added EAP to IKE to support a case that EAP can't support." -- C. Kaufman.</t>
    <t><vspace/></t>
      <t>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.</t>
      <t>IKEv2 <xref target="RFC4306" /> 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).</t>
      <t>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).</t>
      <t>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 <xref target="RFC3748" />:</t>
      <t><list style="hanging">
      <t>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.</t>
      </list></t>
      <t>IKEv2 does indeed provide "a protected tunnel with server
      authentication". The current document updates <xref target="RFC3748" /> by
      making an exception and allowing the use of GTC to carry
      secret credentials, in this specific situation. <xref target="security"/>
      further elaborates on the security properties of this
      solution.</t>
      <t>
      Other protocols provide a similar protected tunnel, for example TLS-EAP, described in
      <xref target="I-D.nir-tls-eap"/>.
      These protocols however are out of scope for this document.
      </t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Terminology">
      <t>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
      <xref target="RFC2119" />.</t>

    </section>
    <!-- ************************************************************************************ -->
    <section title="Alternatives to EAP-GTC in IKEv2">
    <t>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.</t>
      <section title="Non-password credentials">
        <t>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.</t>
      </section>
      <section title="Using the IKE preshared secret">
        <t>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.
        </t>
      </section>
      <section title="EAP-MD5 , EAP-MSCHAPv2 and mutual authentication schemes">

        <t>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.</t>
        <t>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.</t>
        <t>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.</t>
      </section>
	<section title='Mutual "Zero Knowledge" Authentication'>
	<t>Some newer EAP methods provide for mutual, password-based authentication, without
	exposing the password to dictionary attacks by either an eavesdropper or the (alleged)
	peer. An example is <xref target="I-D.sheffer-emu-eap-eke"/>.
	Such EAP methods can be cleanly integrated
	into IKEv2 by using the extension described in
	<xref target="I-D.ietf-ipsecme-eap-mutual"/>.</t>
	<t>In addition, the IPsecME working group is now chartered with producing a similar
	authetication method directly over IKE, without the need for supporting the EAP
	protocol.</t>
	<t>Neither of these options is widely implemented today, if at all. Either of them
	is superior to the method described in this document, and implementors are
	strongly encouraged to migrate to these methods as soon as they are standardized.</t>
	</section>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Using EAP-GTC in IKE: Details">
    <t>EAP-GTC is specified in <xref target="RFC3748"/>, Sec. 5.6.
    This section is non-normative,
    and is merely an interpretation of this specification in the context of IKEv2.</t>
    <t>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.</t>
    <t>In the case of EAP-GTC, the user name is conveyed in the IKE IDi payload.
    According to <xref target="RFC4718"/>, 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
    <xref target="RFC4282"/> 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.</t>
    <t>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.
    </t>
    <t>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.
    </t>
    <t>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, <xref target="RFC4013"/>.</t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="IANA Considerations">
      <t>This document does not require any action by IANA.</t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Security Considerations" anchor="security">
      <section title="Key generation and MITM protection">
      <t>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:</t>
      <t><list style="hanging">
      <t>
      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 <xref target="EAPMITM"/>
    if these EAP methods are used in other protocols that do not use a
    server-authenticated tunnel.
      </t>
      </list></t>
      <t>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.</t>
      </section>
      <section title="Protection of credentials between the IKE gateway and the AAA server">

        <t>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:
        <list style="symbols">
        <t>An IPsec tunnel between the gateway and the AAA
        server. </t>
        <t>RADIUS over TCP with TLS, <xref target="I-D.winter-radsec" />.</t>
        <t>RADIUS over UDP with DTLS, <xref target="I-D.dekok-radext-dtls" />
        (expired). </t>
        </list>
        The legacy RADIUS security mechanism (Sec. 5.2 of
        <xref target="RFC2865" />) is considered weak and SHOULD NOT be used when
        better alternatives are available.</t>
      </section>
      <section title="Server authentication">
        <t>The client may only send its cleartext credentials after
        it has positively authenticated the server. This
        authentication is specified, albeit rather vaguely, in <xref target="RFC4306" /> and is out of scope
        of the current document. Unauthenticated (BTNS) derivatives of IKE MUST NOT be used with EAP-GTC.</t>
      </section>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Acknowledgments">
      <t>I would like to thank Yoav Nir and Charlie Kaufman for their helpful
      comments.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">&rfc2119;
    &rfc3748; &rfc4013; &rfc4306;</references>
    <references title="Informative References">
    <?rfc include="reference.I-D.ietf-ipsecme-eap-mutual.xml"?>
    <?rfc include="reference.I-D.sheffer-emu-eap-eke.xml"?>
    &rfc2865; &rfc4282; &rfc4718;
    &draft-winter-radsec;
    &draft-dekok-radext-dtls;
    &draft-nir-tls-eap;
    <reference anchor="EAPMITM" target="http://eprint.iacr.org/2002/163">
        <front>
            <title>Man-in-the-Middle
              in Tunneled Authentication Protocols</title>
              <author initials="N." surname="Asokan" fullname="N. Asokan">
                <organization/>
             </author>
             <author initials="V." surname="Niemi" fullname="Valtteri Niemi">
                <organization/>
             </author>
              <author initials="K." surname="Nyberg" fullname="Kaisa Nyberg">
                <organization/>
              </author>
            <date month='November' year='2002' />
        </front>
    </reference>
    </references>
    <section title="Change Log">
      <section title="draft-sheffer-ipsecme-ikev2-gtc-02">
        <t>Added a short discussion of newer password-based methods.</t>
      </section>
      <section title="draft-sheffer-ipsecme-ikev2-gtc-01">
        <t>Republished.</t>
      </section>
      <section title="draft-sheffer-ipsecme-ikev2-gtc-00">
        <t>Document renamed.</t>
      </section>
      <section title="draft-sheffer-ikev2-gtc-00">
        <t>Initial version.</t>
      </section>
    </section>
  </back>
</rfc>
