Add.

1 files changed, 1176 insertions, 0 deletions

diff --git a/doc/protocol/draft-nir-tls-eap-02.txt b/doc/protocol/draft-nir-tls-eap-02.txt
new file mode 100644
index 0000000000..fa56748dc1
--- /dev/null
+++ b/doc/protocol/draft-nir-tls-eap-02.txt
@@ -0,0 +1,1176 @@
+
+
+
+TLS Working Group                                                 Y. Nir
+Internet-Draft                                                Y. Sheffer
+Intended status: Standards Track                             Check Point
+Expires: April 16, 2008                                    H. Tschofenig
+                                                                     NSN
+                                                              P. Gutmann
+                                                  University of Auckland
+                                                        October 14, 2007
+
+
+                      TLS using EAP Authentication
+                        draft-nir-tls-eap-02.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 April 16, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                 [Page 1]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+Abstract
+
+   This document describes an extension to the TLS protocol to allow TLS
+   clients to authenticate with legacy credentials using the Extensible
+   Authentication Protocol (EAP).
+
+   This work follows the example of IKEv2, where EAP has been added to
+   the IKEv2 protocol to allow clients to use different credentials such
+   as passwords, token cards, and shared secrets.
+
+   When TLS is used with EAP, additional records are sent after the
+   ChangeCipherSpec protocol message and before the Finished message,
+   effectively creating an extended handshake before the application
+   layer data can be sent.  Each EapMsg handshake record contains
+   exactly one EAP message.  Using EAP for client authentication allows
+   TLS to be used with various AAA back-end servers, such as RADIUS or
+   Diameter.
+
+   TLS with EAP may be used for securing a data connection such as HTTP
+   or POP3.  We believe it has three main benefits:
+   o  The ability of EAP to work with backend servers can remove that
+      burden from the application layer.
+   o  Moving the user authentication into the TLS handshake protects the
+      presumably less secure application layer from attacks by
+      unauthenticated parties.
+   o  Using mutual authentication methods within EAP can help thwart
+      certain classes of phishing attacks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                 [Page 2]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  EAP Applicability  . . . . . . . . . . . . . . . . . . . .  5
+     1.2.  Comparison with Design Alternatives  . . . . . . . . . . .  5
+     1.3.  Conventions Used in This Document  . . . . . . . . . . . .  5
+   2.  Operating Environment  . . . . . . . . . . . . . . . . . . . .  6
+   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
+     3.1.  The tee_supported Extension  . . . . . . . . . . . . . . .  8
+     3.2.  The InterimAuth Handshake Message  . . . . . . . . . . . .  8
+     3.3.  The EapMsg Handshake Message . . . . . . . . . . . . . . .  8
+     3.4.  Calculating the Finished message . . . . . . . . . . . . .  9
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+     4.1.  InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10
+     4.2.  Identity Protection  . . . . . . . . . . . . . . . . . . . 10
+     4.3.  Mutual Authentication  . . . . . . . . . . . . . . . . . . 11
+   5.  Performance Considerations . . . . . . . . . . . . . . . . . . 12
+   6.  Operational Considerations . . . . . . . . . . . . . . . . . . 13
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
+   9.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 16
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
+   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 19
+     A.1.  Changes from Previous Versions . . . . . . . . . . . . . . 19
+       A.1.1.  Changes in version -02 . . . . . . . . . . . . . . . . 19
+       A.1.2.  Changes in version -01 . . . . . . . . . . . . . . . . 19
+       A.1.3.  Changes from the protocol model draft  . . . . . . . . 19
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
+   Intellectual Property and Copyright Statements . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                 [Page 3]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+1.  Introduction
+
+   This document describes a new extension to [TLS] that allows a TLS
+   client to authenticate using [EAP] instead of performing the
+   authentication at the application layer.  The extension follows
+   [TLS-EXT].  For the remainder of this document we will refer to this
+   extension as TEE (TLS with EAP Extension).
+
+   TEE extends the TLS handshake beyond the regular setup, to allow the
+   EAP protocol to run between the TLS server (called an "authenticator"
+   in EAP) and the TLS client (called a "supplicant").  This allows the
+   TLS architecture to handle client authentication before exposing the
+   server application software to an unauthenticated client.  In doing
+   this, we follow the approach taken for IKEv2 in [RFC4306].  However,
+   similar to regular TLS, we protect the user identity by only sending
+   the client identity after the server has authenticated.  In this our
+   solution differs from that of IKEv2.
+
+   Today, most applications that rely on symmetric credentials use TLS
+   to authenticate the server only.  After that, the application takes
+   over, and presents a login screen where the user is expected to
+   present their credentials.
+
+   This creates several problems.  It allows a client to access the
+   application before authentication, thus creating a potential for
+   anonymous attacks on non-hardened applications.  Additionally, web
+   pages are not particularly well suited for long shared secrets and
+   for interfacing with certain devices such as USB tokens.
+
+   TEE allows full mutual authentication to occur for all these
+   applications within the TLS exchange.  The application receives
+   control only when the user is identified and authenticated.  The
+   authentication can be built into the server infrastructure by
+   connecting to a AAA server.  The client side can be integrated into
+   client software such as web browsers and mail clients.  An EAP
+   infrastructure is already built into major operating systems
+   providing a user interface for each authentication method within EAP.
+
+   We intend TEE to be used for various protocols that use TLS such as
+   HTTPS, in cases where certificate based client authentication is not
+   practical.  This includes web-based mail services, online banking,
+   premium content websites and mail clients.
+
+   Another class of applications that may see benefit from TEE are TLS
+   based VPN clients used as part of so-called "SSL VPN" products.  No
+   such client protocols so far has been standardized.
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                 [Page 4]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+1.1.  EAP Applicability
+
+   Section 1.3 of [EAP] states that EAP is only applicable for network
+   access authentication, rather than for "bulk data transfer".  It then
+   goes on to explain why the transport properties of EAP indeed make it
+   unsuitable for bulk data transfer, e.g., for large file transport.
+   Our proposed use of EAP falls squarely within the applicability as
+   defined, since we make no further use of EAP beyond access
+   authentication.
+
+1.2.  Comparison with Design Alternatives
+
+   It has been suggested to implement EAP authentication as part of the
+   protected application, rather than as part of the TLS handshake.  A
+   BCP document could be used to describe a secure way of doing this.
+   The drawbacks we see in such an approach are listed below:
+   o  EAP does not have a pre-defined transport method.  Application
+      designers would need to specify an EAP transport for each
+      application.  Making this a part of TLS has the benefit of a
+      single specification for all protected applications.
+   o  The integration of EAP and TLS is security-sensitive and should be
+      standardized and interoperable.  We do not believe that it should
+      be left to application designers to do this in a secure manner.
+      Specifically on the server-side, integration with AAA servers adds
+      complexity and is more naturally part of the underlying
+      infrastrcture.
+   o  Our current proposal provides channel binding between TLS and EAP,
+      to counter the MITM attacks described in [MITM].  A draft for
+      allowing applications the access to keying material produced by
+      TLS is available with [I-D.rescorla-tls-extractor].  This type of
+      interworking between the TLS stack and the application layer is
+      necessary when EAP is run outside the TLS handshake and then the
+      two exchanges need to be linked together.  Since the key extractor
+      functionality is not yet available in TLS stacks it is difficult
+      for application designers to bind the user authentication to the
+      protected channel provided by TLS.
+
+1.3.  Conventions Used in This Document
+
+   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].
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                 [Page 5]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+2.  Operating Environment
+
+   TEE will work between a client application and a server application,
+   performing either client authentication or mutual authentication
+   within the TLS exchange.
+
+
+        Client                         Server
+    +-------------------------+     +------------------------+
+    |  |GUI| | Client | |TLS+-+-----+-+TLS|   |Server      | |
+    |  +-^-+ |Software| +-^-+ |     +-+-^-+   |Application | |
+    |    |   +--------+   |   |     |   |     |Software    | |
+    |    |                |   |     |   |     +------------+ |
+    |  +-v----------------v-+ |     |   |                    |
+    |  |   EAP              | |     +---|--------------------+
+    |  |  Infrastructure    | |         |
+    |  +--------------------+ |         |    +--------+
+    +-------------------------+         |    | AAA    |
+                                        |    | Server |
+                                        +-----        |
+                                             +--------+
+
+   The above diagram shows the typical deployment.  The client has
+   software that either includes a UI for some EAP methods, or else is
+   able to invoke some operating system EAP infrastructure that takes
+   care of the user interaction.  The server is configured with the
+   address and protocol of the AAA server.  Typically the AAA server
+   communicates using the RADIUS protocol with EAP ([RADIUS] and
+   [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).
+
+   As stated in the introduction, we expect TEE to be used in both
+   browsers and applications.  Further uses may be authentication and
+   key generation for other protocols, and tunneling clients, which so
+   far have not been standardized.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                 [Page 6]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+3.  Protocol Overview
+
+   The TEE extension defines the following:
+   o  A new extension type called tee_supported, used to indicate that
+      the communicating application (either client or server) supports
+      this extension.
+   o  A new message type for the handshake protocol, called InterimAuth,
+      which is used to sign previous messages.
+   o  A new message type for the handshake protocol, called EapMsg,
+      which is used to carry a single EAP message.
+
+   The diagram below outlines the protocol structure.  For illustration
+   purposes only, we use the GPSK EAP method [EAP-GPSK].
+
+         Client                                               Server
+         ------                                               ------
+
+         ClientHello(*)             -------->
+                                                      ServerHello(*)
+                                                       (Certificate)
+                                                   ServerKeyExchange
+                                            EapMsg(Identity-Request)
+                                     <--------       ServerHelloDone
+         ClientKeyExchange
+         (CertificateVerify)
+         ChangeCipherSpec
+         InterimAuth
+         EapMsg(Identity-Reply)     -------->
+                                                    ChangeCipherSpec
+                                                         InterimAuth
+                                                EapMsg(GPSK-Request)
+                                    <--------
+         EapMsg(GPSK-Reply)         -------->
+                                                EapMsg(GPSK-Request)
+                                    <--------
+         EapMsg(GPSK-Reply)         -------->
+                                                     EapMsg(Success)
+                                    <--------               Finished
+         Finished                   -------->
+
+       (*) The ClientHello and ServerHello include the tee_supported
+           extension to indicate support for TEE
+
+
+   The client indicates in the first message its support for TEE.  The
+   server sends an EAP identity request in the reply.  The client sends
+   the identity reply after the handshake completion.  The EAP request-
+   response sequence continues until the client is either authenticated
+
+
+
+Nir, et al.              Expires April 16, 2008                 [Page 7]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+   or rejected.
+
+3.1.  The tee_supported Extension
+
+   The tee_supported extension is a ClientHello and ServerHello
+   extension as defined in Section 2.3 of [TLS-EXT].  The extension_type
+   field is TBA by IANA.  The extension_data is zero-length.
+
+3.2.  The InterimAuth Handshake Message
+
+   The InterimAuth message is identical in syntax to the Finished
+   message described in Section 7.4.9 of [TLS].  It is calculated in
+   exactly the same way.
+
+   The semantics, however, are somewhat different.  The "Finished"
+   message indicates that application data may now be sent.  The
+   "InterimAuth" message does not indicate this.  Instead, further
+   handshake messages are needed.
+
+   The HandshakeType value for the InterimAuth handshake message is TBA
+   by IANA.
+
+3.3.  The EapMsg Handshake Message
+
+   The EapMsg handshake message carries exactly one EAP message as
+   defined in [EAP].
+
+   The HandshakeType value for the EapMsg handshake message is TBA by
+   IANA.
+
+   The EapMsg message is used to tunnel EAP messages between the
+   authentication server, which may be co-located with the TLS server,
+   or else may be a separate AAA server, and the supplicant, which is
+   co-located with the TLS client.  TLS on either side receives the EAP
+   data from the EAP infrastructure, and treats it as opaque.  TLS does
+   not make any changes to the EAP payload or make any decisions based
+   on the contents of an EapMsg handshake message.
+
+   Note that it is expected that the EAP server notifies the TLS server
+   about authentication success or failure, and TLS does not inspect the
+   eap_payload within the EapMsg to detect success or failure.
+
+         struct {
+             opaque eap_payload[4..65535];
+         } EapMsg;
+
+         eap_payload is defined in section 4 of RFC 3748. It includes
+         the Code, Identifier, Length and Data fields of the EAP
+
+
+
+Nir, et al.              Expires April 16, 2008                 [Page 8]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+         packet.
+
+3.4.  Calculating the Finished message
+
+   If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the
+   Finished message is calculated as follows:
+
+         struct {
+             opaque verify_data[12];
+         } Finished;
+
+         verify_data
+             PRF(MSK, finished_label, MD5(handshake_messages) +
+             SHA-1(handshake_messages)) [0..11];
+
+   The finished_label and the PRF are as defined in Section 7.4.9 of
+   [TLS].
+
+   The handshake_messages field, unlike regular TLS, does not sign all
+   the data in the handshake.  Instead it signs all the data that has
+   not been signed by the previous InterimAuth message.  The
+   handshake_messages field includes all of the octets beginning with
+   and including the InterimAuth message, up to but not including this
+   Finished message.  This is the concatenation of all the Handshake
+   structures exchanged thus far, and not yet signed, as defined in
+   Section 7.4 of [TLS]and in this document.
+
+   The Master Session Key (MSK) is derived by the AAA server and by the
+   client if the EAP method is key-generating.  On the server-side, it
+   is typically received from the AAA server over the RADIUS or Diameter
+   protocol.  On the client-side, it is passed to TLS by some other
+   method.
+
+   If the EAP method is not key-generating, then the master_secret is
+   used to sign the messages instead of the MSK.  For a discussion on
+   the use of such methods, see Section 4.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                 [Page 9]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+4.  Security Considerations
+
+4.1.  InterimAuth vs. Finished
+
+   In regular TLS, the Finished message provides two functions: it signs
+   all preceding messages, and it signals that application data can now
+   be sent.  In TEE, it only signs those messages that have not yet been
+   signed.
+
+   Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate
+   keys in addition to authenticating clients.  Such methods are said to
+   be resistant to man-in-the-middle (MITM) attacks as discussed in
+   [MITM].  Such methods are called key-generating methods.
+
+   To realize the benefit of such methods, we need to verify the key
+   that was generated within the EAP method.  This is referred to as the
+   MSK in EAP.  In TEE, the InterimAuth message signs all previous
+   messages with the master_secret, just like the Finished message in
+   regular TLS.  The Finished message signs the rest of the messages
+   using the MSK if such exists.  If not, then the messages are signed
+   with the master_secret as in regular TLS.
+
+   The need for signing twice arises from the fact that we need to use
+   both the master_secret and the MSK.  It was possible to use just one
+   Finished record and blend the MSK into the master_secret.  However,
+   this would needlessly complicate the protocol and make security
+   analysis more difficult.  Instead, we have decided to follow the
+   example of IKEv2, where two AUTH payloads are exchanged.
+
+   It should be noted that using non-key-generating methods may expose
+   the client to a MITM attack if the same method and credentials are
+   used in some other situation, in which the EAP is done outside of a
+   protected tunnel with an authenticated server.  Unless it can be
+   determined that the EAP method is never used in such a situation,
+   non-key-generating methods SHOULD NOT be used.  This issue is
+   discussed extensively in [Compound-Authentication].
+
+4.2.  Identity Protection
+
+   Unlike [TLS-PSK], TEE provides active user identity confidentiality
+   for the client.  The client's identity is hidden from an active and a
+   passive eavesdropper using the server-side authenticated TLS channel
+   (followed by encryption of the EAP-based handshake messages).  Active
+   attacks are discussed in Section 4.3.
+
+   We could save one round-trip by having the client send its identity
+   within the Client Hello message.  This is similar to TLS-PSK.
+   However, we believe that identity protection is a worthy enough goal,
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 10]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+   so as to justify the extra round-trip.
+
+4.3.  Mutual Authentication
+
+   In order to achieve our security goals, we need to have both the
+   server and the client authenticate.  Client authentication is
+   obviously done using the EAP method.  The server authentication can
+   be done in either of two ways:
+   1.  The client can verify the server certificate.  This may work well
+       depending on the scenario, but implies that the client or its
+       user can recognize the right DN or alternate name, and
+       distinguish it from plausible alternatives.  The introduction to
+       [I.D.Webauth-phishing] shows that at least in HTTPS, this is not
+       always the case.
+   2.  The client can use a mutually authenticated (MA) EAP method such
+       as GPSK.  In this case, server certificate verification does not
+       matter, and the TLS handshake may as well be anonymous.  Note
+       that in this case, the client identity is sent to the server
+       before server authentication.
+
+   To summarize:
+   o  Clients MUST NOT propose anonymous ciphersuites, unless they
+      support MA EAP methods.
+   o  Clients MUST NOT accept non-MA methods if the ciphersuite is
+      anonymous.
+   o  Clients MUST NOT accept non-MA methods if they are not able to
+      verify the server credentials.  Note that this document does not
+      define what verification involves.  If the server DN is known and
+      stored on the client, verifying certificate signature and checking
+      revocation may be enough.  For web browsers, the case is not as
+      clear cut, and MA methods SHOULD be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 11]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+5.  Performance Considerations
+
+   Regular TLS adds two round-trips to a TCP connection.  However,
+   because of the stream nature of TCP, the client does not really need
+   to wait for the server's Finished message, and can begin sending
+   application data immediately after its own Finished message.  In
+   practice, many clients do so, and TLS only adds one round-trip of
+   delay.
+
+   TEE adds as many round-trips as the EAP method requires.  For
+   example, EAP-MD5 requires 1 round-trip, while EAP-GPSK requires 2
+   round-trips.  Additionally, the client MUST wait for the EAP-Success
+   message before sending its own Finished message, so we need at least
+   3 round-trips for the entire handshake.  The best a client can do is
+   two round-trips plus however many round-trips the EAP method
+   requires.
+
+   It should be noted, though, that these extra round-trips save
+   processing time at the application level.  Two extra round-trips take
+   a lot less time than presenting a log-in web page and processing the
+   user's input.
+
+   It should also be noted, that TEE reverses the order of the Finished
+   messages.  In regular TLS the client sends the Finished message
+   first.  In TEE it is the server that sends the Finished message
+   first.  This should not affect performance, and it is clear that the
+   client may send application data immediately after the Finished
+   message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 12]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+6.  Operational Considerations
+
+   Section 4.3 defines a dependency between the TLS state and the EAP
+   state in that it mandates that certain EAP methods should not be used
+   with certain TLS ciphersuites.  To avoid such dependencies, there are
+   two approaches that implementations can take.  They can either not
+   use any anonymous ciphersuites, or else they can use only MA EAP
+   methods.
+
+   Where certificate validation is problematic, such as in browser-based
+   HTTPS, we recommend the latter approach.
+
+   In cases where the use of EAP within TLS is not known before opening
+   the connection, it is necessary to consider the implications of
+   requiring the user to type in credentials after the connection has
+   already started.  TCP sessions may time out, because of security
+   considerations, and this may lead to session setup failure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 13]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+7.  IANA Considerations
+
+   IANA is asked to assign an extension type value from the
+   "ExtensionType Values" registry for the tee_supported extension.
+
+   IANA is asked to assign two handshake message types from the "TLS
+   HandshakeType Registry", one for "EapMsg" and one for "InterimAuth".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 14]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+8.  Acknowledgments
+
+   The authors would like to thank Josh Howlett for his comments.
+
+   The TLS Inner Application Extension work ([TLS/IA]) has inspired the
+   authors to create this simplified work.  TLS/IA provides a somewhat
+   different approach to integrating non-certificate credentials into
+   the TLS protocol, in addition to several other features available
+   from the RADIUS namespace.
+
+   The authors would also like to thank the various contributors to
+   [RFC4306] whose work inspired this one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 15]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+9.  Open Issues
+
+   Some have suggested that since the protocol is identical to regular
+   TLS up to the InterimAuth message, we should call that the Finished
+   message, and call the last message in the extended handshake
+   something like "EapFinished".  This has the advantage that the
+   construction of Finished is already well defined and will not change.
+   However, the Finished message has a specific meaning as indicated by
+   its name.  It means that the handshake is over and that application
+   data can now be sent.  This is not true of what is in this draft
+   called InterimAuth.  We would like the opinions of reviewers about
+   this issue.
+
+   The MSK from the EAP exchange is only used to sign the Finished
+   message.  It is not used again in the data encryption.  In this we
+   followed the example of IKEv2.  The reason is that TLS already has
+   perfectly good ways of exchanging keys, and we do not need this
+   capability from EAP methods.  Also, using the MSK in keys would
+   require an additional ChangeCipherSpec and would complicate the
+   protocol.  We would like the opinions of reviewers about this issue.
+
+   Another response we got was that we should have a MUST requirement
+   that only mutually authenticated and key generating methods be used
+   in TEE.  This would simplify the security considerations section.
+   While we agree that this is a good idea, most EAP methods in common
+   use are not compliant.  Additionally, such requirements assume that
+   EAP packets are visible to a passive attacker.  As EAP is used in
+   protected tunnels such as in L2TP, in IKEv2 and here, this assumption
+   may not be required.  If we consider the server authenticated by its
+   certificate, it may be acceptable to use a non-MA method.
+
+   It has been suggested that identity protection is not important
+   enough to add a roundtrip, and so we should have the client send the
+   username in the ClientHello.  We are not sure about how others feel
+   about this, and would like to solicit the reviewers opinion.  Note
+   that if this is done, the client sends the user name before ever
+   receiving any indication that the server actually supports TEE.  This
+   might be acceptable in an email client, where the server is
+   preconfigured, but it may be unacceptable in other uses, such as web
+   browsers.
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 16]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+10.  References
+
+10.1.  Normative References
+
+   [EAP]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, "Extensible Authentication Protocol (EAP)",
+              RFC 3748, June 2004.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+   [TLS-EXT]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
+              and T. Wright, "Transport Layer Security (TLS)
+              Extensions", RFC 4366, April 2006.
+
+10.2.  Informative References
+
+   [Compound-Authentication]
+              Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
+              "The Compound Authentication Binding Problem",
+              draft-puthenkulam-eap-binding-04 (work in progress),
+              October 2003.
+
+   [Dia-EAP]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
+              Authentication Protocol (EAP) Application", RFC 4072,
+              August 2005.
+
+   [Diameter]
+              Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
+              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
+
+   [EAP-GPSK]
+              Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared
+              Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-05 (work in
+              progress), April 2007.
+
+   [I-D.ietf-eap-keying]
+              Aboba, B., "Extensible Authentication Protocol (EAP) Key
+              Management Framework", draft-ietf-eap-keying-18 (work in
+              progress), February 2007.
+
+   [I-D.rescorla-tls-extractor]
+              Rescorla, E., "Keying Material Extractors for Transport
+              Layer Security (TLS)", draft-rescorla-tls-extractor-00
+              (work in progress), January 2007.
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 17]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+   [I.D.Webauth-phishing]
+              Hartman, S., "Requirements for Web Authentication
+              Resistant to Phishing", draft-hartman-webauth-phishing-03
+              (work in progress), March 2007.
+
+   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
+              in Tunneled Authentication Protocols", IACR ePrint
+              Archive , October 2002.
+
+   [RAD-EAP]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
+              Dial In User Service) Support For Extensible
+              Authentication Protocol (EAP)", RFC 3579, September 2003.
+
+   [RADIUS]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+              "Remote Authentication Dial In User Service (RADIUS)",
+              RFC 2865, June 2000.
+
+   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+              RFC 4306, December 2005.
+
+   [TLS-PSK]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
+              for Transport Layer Security (TLS)", RFC 4279,
+              December 2005.
+
+   [TLS/IA]   Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and
+              T. Hardjono, "TLS Inner Application Extension (TLS/IA)",
+              draft-funk-tls-inner-application-extension-03 (work in
+              progress), June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 18]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+Appendix A.  Change History
+
+A.1.  Changes from Previous Versions
+
+A.1.1.  Changes in version -02
+
+   o  Added discussion of alternative designs.
+
+A.1.2.  Changes in version -01
+
+   o  Changed the construction of the Finished message
+   o  Replaced MS-CHAPv2 with GPSK in examples.
+   o  Added open issues section.
+   o  Added reference to [Compound-Authentication]
+   o  Fixed reference to MITM attack
+
+A.1.3.  Changes from the protocol model draft
+
+   o  Added diagram for EapMsg
+   o  Added discussion of EAP applicability
+   o  Added discussion of mutually-authenticated EAP methods vs other
+      methods in the security considerations.
+   o  Added operational considerations.
+   o  Other minor nits.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 19]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+Authors' Addresses
+
+   Yoav Nir
+   Check Point Software Technologies Ltd.
+   5 Hasolelim st.
+   Tel Aviv  67897
+   Israel
+
+   Email: ynir@checkpoint.com
+
+
+   Yaron Sheffer
+   Check Point Software Technologies Ltd.
+   5 Hasolelim st.
+   Tel Aviv  67897
+   Israel
+
+   Email: yaronf@checkpoint.com
+
+
+   Hannes Tschofenig
+   Nokia Siemens Networks
+   Otto-Hahn-Ring 6
+   Munich, Bavaria  81739
+   Germany
+
+   Email: Hannes.Tschofenig@siemens.com
+   URI:   http://www.tschofenig.com
+
+
+   Peter Gutmann
+   University of Auckland
+   Department of Computer Science
+   New Zealand
+
+   Email: pgut001@cs.auckland.ac.nz
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 20]
+
+Internet-Draft                 EAP-in-TLS                   October 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Nir, et al.              Expires April 16, 2008                [Page 21]
+