Add.

1 files changed, 1120 insertions, 0 deletions

diff --git a/doc/protocol/draft-nir-tls-eap-00.txt b/doc/protocol/draft-nir-tls-eap-00.txt
new file mode 100644
index 0000000000..d740f04917
--- /dev/null
+++ b/doc/protocol/draft-nir-tls-eap-00.txt
@@ -0,0 +1,1120 @@
+
+
+
+TLS Working Group                                                 Y. Nir
+Internet-Draft                                                Y. Sheffer
+Intended status: Standards Track                             Check Point
+Expires: December 9, 2007                                  H. Tschofenig
+                                                                     NSN
+                                                              P. Gutmann
+                                                  University of Auckland
+                                                            June 7, 2007
+
+
+                      TLS using EAP Authentication
+                        draft-nir-tls-eap-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 December 9, 2007.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+Nir, et al.             Expires December 9, 2007                [Page 1]
+
+Internet-Draft                 EAP-in-TLS                      June 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 December 9, 2007                [Page 2]
+
+Internet-Draft                 EAP-in-TLS                      June 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  EAP Applicability  . . . . . . . . . . . . . . . . . . . .  5
+     1.2.  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.  Changes from Previous Versions . . . . . . . . . . . . . . . . 16
+     9.1.  Changes from the protocol model draft  . . . . . . . . . . 16
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
+   Intellectual Property and Copyright Statements . . . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.             Expires December 9, 2007                [Page 3]
+
+Internet-Draft                 EAP-in-TLS                      June 2007
+
+
+1.  Introduction
+
+   This document describes a new extension to [TLS].  This extension
+   allows a TLS client to authenticate using [EAP] instead of performing
+   the authentication at the application level.  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.
+
+   Currently used applications that rely on non-certificate user
+   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 an 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 some 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 have so far been standardized.
+
+
+
+
+
+Nir, et al.             Expires December 9, 2007                [Page 4]
+
+Internet-Draft                 EAP-in-TLS                      June 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.  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 December 9, 2007                [Page 5]
+
+Internet-Draft                 EAP-in-TLS                      June 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 December 9, 2007                [Page 6]
+
+Internet-Draft                 EAP-in-TLS                      June 2007
+
+
+3.  Protocol Overview
+
+   The TEE extension defines the following:
+   o  A new extension type called tee_supported, used to indicate that
+      the client 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 MSCHAPv2 EAP method
+   [I-D.dpotter-pppext-eap-mschap].
+
+         Client                                               Server
+         ------                                               ------
+
+         ClientHello(*)             -------->
+                                                      ServerHello(*)
+                                                       (Certificate)
+                                                   ServerKeyExchange
+                                            EapMsg(Identity-Request)
+                                     <--------       ServerHelloDone
+         ClientKeyExchange
+         (CertificateVerify)
+         ChangeCipherSpec
+         InterimAuth
+         EapMsg(Identity-Reply)     -------->
+                                                    ChangeCipherSpec
+                                                         InterimAuth
+                                          EapMsg(MS-CHAP-v2-Request)
+                                    <--------
+         EapMsg(MS-CHAP-v2-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
+   or rejected.
+
+
+
+
+
+Nir, et al.             Expires December 9, 2007                [Page 7]
+
+Internet-Draft                 EAP-in-TLS                      June 2007
+
+
+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 authentication server notifies the
+   TLS server about authentication success or failure, and so TLS need
+   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
+         packet.
+
+
+
+Nir, et al.             Expires December 9, 2007                [Page 8]
+
+Internet-Draft                 EAP-in-TLS                      June 2007
+
+
+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, similar to regular TLS, comprises all
+   of the data from all messages in this handshake, including any EapMsg
+   and InterimAuth messages, up to but not including this Finished
+   message.  This is the concatenation of all the Handshake structures
+   exchanged thus far, as defined in section 7.4 of [TLS].
+
+   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 Finished message is
+   calculated exactly as described in [TLS].  For a discussion on the
+   use of such methods, see Section 4.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir, et al.             Expires December 9, 2007                [Page 9]
+
+Internet-Draft                 EAP-in-TLS                      June 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, some of the messages are signed twice.
+
+   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 all previous 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.
+
+4.2.  Identity Protection
+
+   Unlike [TLS-PSK], TEE provides identity protection for the client.
+   The client's identity is hidden from a passive eavesdropper using TLS
+   encryption.  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,
+   so as to justify the extra round-trip.
+
+
+
+
+
+
+Nir, et al.             Expires December 9, 2007               [Page 10]
+
+Internet-Draft                 EAP-in-TLS                      June 2007
+
+
+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 MS-CHAPv2.  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  Servers MUST NOT accept anonymous ciphersuites, unless they
+      support MA EAP methods.  If they support both MA and non-MA
+      methods, they SHOULD prefer to use the MA methods.
+   o  Clients MUST NOT accept non-MA methods if the ciphersuite is
+      anonymous.
+   o  Clients MUST NOT accpet non-MA mehtods 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 December 9, 2007               [Page 11]
+
+Internet-Draft                 EAP-in-TLS                      June 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-SIM 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 December 9, 2007               [Page 12]
+
+Internet-Draft                 EAP-in-TLS                      June 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 December 9, 2007               [Page 13]
+
+Internet-Draft                 EAP-in-TLS                      June 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 December 9, 2007               [Page 14]
+
+Internet-Draft                 EAP-in-TLS                      June 2007
+
+
+8.  Acknowledgments
+
+   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 December 9, 2007               [Page 15]
+
+Internet-Draft                 EAP-in-TLS                      June 2007
+
+
+9.  Changes from Previous Versions
+
+9.1.  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 December 9, 2007               [Page 16]
+
+Internet-Draft                 EAP-in-TLS                      June 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
+
+   [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.
+
+   [I-D.dpotter-pppext-eap-mschap]
+              Potter, D. and J. Zamick, "PPP EAP MS-CHAP-V2
+              Authentication Protocol",
+              draft-dpotter-pppext-eap-mschap-01 (work in progress),
+              January 2002.
+
+   [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.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", October 2002.
+
+   [RAD-EAP]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
+
+
+
+Nir, et al.             Expires December 9, 2007               [Page 17]
+
+Internet-Draft                 EAP-in-TLS                      June 2007
+
+
+              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 December 9, 2007               [Page 18]
+
+Internet-Draft                 EAP-in-TLS                      June 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 at checkpoint dot 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 December 9, 2007               [Page 19]
+
+Internet-Draft                 EAP-in-TLS                      June 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 December 9, 2007               [Page 20]
+