


TLS Working Group                                                P. Funk
Internet-Draft                                       Funk Software, Inc.
Expires: December 27, 2006                               S. Blake-Wilson
                                            Basic Commerce & Industries,
                                                                    Inc.
                                                                N. Smith
                                                       Intel Corporation
                                                           H. Tschofenig
                                                                 Siemens
                                                             T. Hardjono
                                                            Verisign Inc
                                                           June 25, 2006


                TLS Inner Application Extension (TLS/IA)
           draft-funk-tls-inner-application-extension-03.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 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract




Funk, et al.            Expires December 27, 2006               [Page 1]

Internet-Draft            TLS inner Application                June 2006


   This document defines a new TLS extension called "Inner Application".
   When TLS is used with the Inner Application extension (TLS/IA),
   additional messages are exchanged after completion of the TLS
   handshake, in effect providing an extended handshake prior to the
   start of upper layer data communications.  Each TLS/IA message
   contains an encrypted sequence of Attribute-Value-Pairs (AVPs) from
   the RADIUS/Diameter namespace.  Hence, the AVPs defined in RADIUS and
   Diameter have the same meaning in TLS/AI; that is, each attribute
   code point refers to the same logical attribute in any of these
   protocols.  Arbitrary "applications" may be implemented using the AVP
   exchange.  Possible applications include EAP or other forms of user
   authentication, client integrity checking, provisioning of additional
   tunnels, and the like.  Use of the RADIUS/Diameter namespace provides
   natural compatibility between TLS/IA applications and widely deployed
   AAA infrastructures.

   It is anticipated that TLS/IA will be used with and without
   subsequent protected data communication within the tunnel established
   by the handshake.  For example, TLS/IA may be used to secure an HTTP
   data connection, allowing more robust password-based user
   authentication to occur than would otherwise be possible using
   mechanisms available in HTTP.  TLS/IA may also be used for its
   handshake portion alone; for example, EAP-TTLSv1 encapsulates a
   TLS/IA handshake in EAP as a means to mutually authenticate a client
   and server and establish keys for a separate data connection.


























Funk, et al.            Expires December 27, 2006               [Page 2]

Internet-Draft            TLS inner Application                June 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  A bit of History . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  TLS With or Without Upper Layer Data Communications  . . .  6
   2.  The Inner Application Extension to TLS . . . . . . . . . . . .  7
     2.1.  TLS/IA Overview  . . . . . . . . . . . . . . . . . . . . .  8
     2.2.  Message Exchange . . . . . . . . . . . . . . . . . . . . .  9
     2.3.  Inner Secret . . . . . . . . . . . . . . . . . . . . . . . 10
       2.3.1.  Application Session Key Material . . . . . . . . . . . 11
     2.4.  Session Resumption . . . . . . . . . . . . . . . . . . . . 13
     2.5.  Error Termination  . . . . . . . . . . . . . . . . . . . . 13
     2.6.  Negotiating the Inner Application Extension  . . . . . . . 13
     2.7.  InnerApplication Protocol  . . . . . . . . . . . . . . . . 14
       2.7.1.  InnerApplicationExtension  . . . . . . . . . . . . . . 14
       2.7.2.  InnerApplication Message . . . . . . . . . . . . . . . 15
       2.7.3.  IntermediatePhaseFinished and FinalPhaseFinished
               Messages . . . . . . . . . . . . . . . . . . . . . . . 15
       2.7.4.  The ApplicationPayload Message . . . . . . . . . . . . 16
     2.8.  Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   3.  Encapsulation of AVPs within ApplicationPayload Messages . . . 18
     3.1.  AVP Format . . . . . . . . . . . . . . . . . . . . . . . . 18
     3.2.  AVP Sequences  . . . . . . . . . . . . . . . . . . . . . . 19
     3.3.  Guidelines for Maximum Compatibility with AAA Servers  . . 20
   4.  Tunneled Authentication within Application Phases  . . . . . . 21
     4.1.  Implicit challenge . . . . . . . . . . . . . . . . . . . . 21
     4.2.  Tunneled Authentication Protocols  . . . . . . . . . . . . 22
       4.2.1.  EAP  . . . . . . . . . . . . . . . . . . . . . . . . . 22
       4.2.2.  CHAP . . . . . . . . . . . . . . . . . . . . . . . . . 23
       4.2.3.  MS-CHAP  . . . . . . . . . . . . . . . . . . . . . . . 23
       4.2.4.  MS-CHAP-V2 . . . . . . . . . . . . . . . . . . . . . . 24
       4.2.5.  PAP  . . . . . . . . . . . . . . . . . . . . . . . . . 25
     4.3.  Performing Multiple Authentications  . . . . . . . . . . . 26
   5.  Example Message Sequences  . . . . . . . . . . . . . . . . . . 27
     5.1.  Full Initial Handshake with Intermediate and Final
           Application Phasess  . . . . . . . . . . . . . . . . . . . 27
     5.2.  Resumed Session with Single Application Phase  . . . . . . 29
     5.3.  Resumed Session with No Application Phase  . . . . . . . . 29
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 34
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 37







Funk, et al.            Expires December 27, 2006               [Page 3]

Internet-Draft            TLS inner Application                June 2006


1.  Introduction

   This specification defines the TLS "Inner Application" extension.
   The term "TLS/IA" refers to the TLS protocol when used with the Inner
   Application extension.

   In TLS/IA, the setup portion of TLS is extended to allow an arbitrary
   exchange of information between client and server within a protected
   tunnel established during the TLS handshake and prior to the start of
   upper layer TLS data communications.  The TLS handshake itself is
   unchanged; the subsequent Inner Application exchange is conducted
   under the confidentiality and integrity protection that is afforded
   by the TLS handshake.

   The primary motivation for providing this facility is to allow robust
   user authentication to occur as part of an "extended" handshake, in
   particular, user authentication that is based on password
   credentials, which is best conducted under the protection of an
   encrypted tunnel to preclude dictionary attack by eavesdroppers.  For
   example, the Extensible Authentication Protocol (EAP) may be used for
   authentication using any of a wide variety of methods as part of this
   extended handshake.  The multi-layer approach of TLS/IA, in which a
   strong authentication, typically based on a server certificate, is
   used to protected a password-based authentication, distinguishes it
   from other TLS variants that rely entirely on a pre-shared key or
   password for security (such as [I-D.ietf-tls-psk]).

   The protected exchange accommodates any type of client-server
   application, not just authentication, though authentication may often
   be the prerequisite for other applications to proceed.  For example,
   TLS/IA may be used to set up HTTP connections, establish IPsec
   security associations (as an alternative to IKE), obtain credentials
   for single sign-on, provide client integrity verification, and so on.

   The new messages that are exchanged between client and server are
   encoded as sequences of Attribute-Value-Pairs (AVPs) from the RADIUS/
   Diameter namespace.  Use of the RADIUS/Diameter namespace provides
   natural compatibility between TLS/IA applications and widely deployed
   AAA infrastructures.  This namespace is extensible, allowing new AVPs
   and, thus, new applications to be defined as needed, either by
   standards bodies or by vendors wishing to define proprietary
   applications.

   The TLS/IA exchange comprises one or more "phases", each of which
   consists of an arbitrary number of AVP exchanges followed by a
   confirmation exchange.  Authentications occurring in any phase must
   be confirmed prior to continuing to the next phase.  This allows
   applications to implement security dependencies in which particular



Funk, et al.            Expires December 27, 2006               [Page 4]

Internet-Draft            TLS inner Application                June 2006


   assurances are required prior to the exchange of additional
   information.

1.1.  A bit of History

   The TLS protocol has its roots in the Netscape SSL protocol, which
   was originally intended to protect HTTP traffic.  It provides either
   one-way or mutual certificate-based authentication of client and
   server.  In its most typical use in HTTP, the client authenticates
   the server based on the server's certificate and establishes a tunnel
   through which HTTP traffic is passed.

   For the server to authenticate the client within the TLS handshake,
   the client must have its own certificate.  In cases where the client
   must be authenticated without a certificate, HTTP, not TLS,
   mechanisms would have to be employed.  For example, HTTP headers have
   been defined to perform user authentications.  However, these
   mechanisms are primitive compared to other mechanisms, most notably
   EAP, that have been defined for contexts other than HTTP.
   Furthermore, any mechanisms defined for HTTP cannot be utilized when
   TLS is used to protect non-HTTP traffic.

   The TLS protocol has also found an important use in authentication
   for network access, originally within PPP for dial-up access and
   later for wireless and wired 802.1X access.  Several EAP types have
   been defined that utilize TLS to perform mutual client-server
   authentication.  The first to appear, EAP-TLS, uses the TLS handshake
   to authenticate both client and server based on their certificates.

   Subsequently proposed protocols, such EAP-TTLSv0 and EAP-PEAP,
   utilize the TLS handshake to allow the client to authenticate the
   server based on the latter's certificate, and then use the protected
   channel established by the TLS handshake to perform user
   authentication, typically based on a password.  Such protocols are
   called "tunneled" EAP protocols.  The authentication mechanism used
   inside the tunnel may itself be EAP, and the tunnel may also be used
   to convey additional information between client and server.

   While tunneled authentication would be useful in other contexts
   besides EAP, the tunneled protocols mentioned above cannot be
   employed in a more general use of TLS, since the outermost protocol
   is EAP, not TLS.  Furthermore, these protocols use the TLS tunnel to
   carry authentication exchanges, and thus preclude use of the TLS
   tunnel for other purposes such as carrying HTTP traffic.

   TLS/IA provides a means to perform user authentication and other
   message exchanges between client and server strictly within TLS.
   TLS/IA can thus be used both for flexible user authentication within



Funk, et al.            Expires December 27, 2006               [Page 5]

Internet-Draft            TLS inner Application                June 2006


   a TLS session and as a basis for tunneled authentication within EAP.

   The TLS/IA approach is to insert an additional message exchange
   between the TLS handshake and the subsequent data communications
   phase.  This message exchange is carried in a new record type, which
   is distinct from the record type that carries upper layer data.
   Thus, the data portion of the TLS exchange becomes available for HTTP
   or another protocol that needs to be secured.

1.2.  TLS With or Without Upper Layer Data Communications

   It is anticipated that TLS/IA will be used with and without
   subsequent protected data communication within the tunnel established
   by the handshake.

   For example, TLS/IA may be used to protect an HTTP connection,
   allowing more robust password-based user authentication to occur
   within the TLS/IA extended handshake than would otherwise be possible
   using mechanisms available in HTTP.

   TLS/IA may also be used for its handshake portion alone.  For
   example, EAP-TTLSv1 encapsulates a TLS/IA extended handshake in EAP
   as a means to mutually authenticate a client and server and establish
   keys for a separate data connection; no subsequent TLS data portion
   is required.  Another example might be the use of TLS/IA directly
   over TCP in order to provide a user with credentials for single
   sign-on.
























Funk, et al.            Expires December 27, 2006               [Page 6]

Internet-Draft            TLS inner Application                June 2006


2.  The Inner Application Extension to TLS

   The Inner Application extension to TLS follows the guidelines of
   [RFC3546].

   A new extension type is defined for negotiating use of TLS/IA:
      The InnerApplicationExtension extension type.  The client proposes
      use of this extension by including a InnerApplicationExtension
      message in its ClientHello handshake message, and the server
      confirms its use by including a InnerApplicationExtension message
      in its ServerHello handshake message.


   A new record type (ContentType) is defined for use in TLS/IA:
      The InnerApplication record type.  This record type carries all
      messages that are exchanged after the TLS handshake and prior to
      exchange of data.


   A new message type is defined for use within the InnerApplication
   record type:

      The InnerApplication message.  This message may encapsulate any of
      the three following subtypes:

         The ApplicationPayload message.  This message is used to carry
         AVP (Attribute-Value Pair) sequences within the TLS/IA extended
         handshake, in support of client-server applications such as
         authentication.

         The IntermediatePhaseFinished message.  This message confirms
         session keys established during the current TLS/IA phase, and
         indicates that at least one additional phase is to follow.

         The FinalPhaseFinished message.  This message confirms session
         keys established during the current TLS/IA phase, and indicates
         that no further phases are to follow.


   Two new alert codes are defined for use in TLS/IA:

      The InnerApplicationFailure alert.  This error alert allows either
      party to terminate the TLS/IA extended handshake due to a failure
      in an application implemented via AVP sequences carried in
      ApplicationPayload messages.






Funk, et al.            Expires December 27, 2006               [Page 7]

Internet-Draft            TLS inner Application                June 2006


      The InnerApplicationVerification alert.  This error alert allows
      either party to terminate the TLS/IA extended handshake due to
      incorrect verification data in a received
      IntermediatePhaseFinished or FinalPhaseFinished message.


   The following new assigned numbers are used in TLS/IA:
      "InnerApplicationExtension" extension type: 37703
      "InnerApplication" record type: 24
      "InnerApplicationFailure" alert code: 208
      "InnerApplicationVerification" alert code: 209

   [Editor's note: I have not checked these types yet against types
   defined in RFCs or drafts.  The TLS RFC specifies that new record
   types use the next number after ones already defined; hence I used
   24, though I don't know if that is already taken.]

2.1.  TLS/IA Overview

   In TLS/IA, zero or more "application phases are inserted after the
   TLS handshake and prior to ordinary data exchange.  The last such
   application phase is called the "final phase"; any application phases
   prior to the final phase are called "intermediate phases".
   Intermediate phases are only necessary if interim confirmation of
   session keys generated during an application phase is desired.

   Each application phase consists of ApplicationPayload handshake
   messages exchanged by client and server to implement applications
   such as authentication, plus concluding messages for cryptographic
   confirmation.  These messages are encapsulated in records with
   ContentType of InnerApplication.  All application phases prior to the
   final phase use IntermediatePhaseFinished rather than
   FinalPhaseFinished as the concluding message.  The final phase
   concludes with the FinalPhaseFinished message.

   Application phases may be omitted entirely only when session
   resumption is used, provided both client and server agree that no
   application phase is required.  The client indicates in its
   ClientHello whether it is willing to omit application phases in a
   resumed session, and the server indicates in its ServerHello whether
   any application phases are to ensue.

   In each application phase, the client sends the first
   ApplicationPayload message.  ApplicationPayload messages are then
   traded one at a time between client and server, until the server
   concludes the phase by sending, in response to an ApplicationPayload
   message from the client, an IntermediatePhaseFinished sequence to
   conclude an intermediate phase, or a FinalPhaseFinished sequence to



Funk, et al.            Expires December 27, 2006               [Page 8]

Internet-Draft            TLS inner Application                June 2006


   conclude the final phase.  The client then responds with its own
   IntermediatePhaseFinished or FinalPhaseFinished message.

   Note that the server MUST NOT send an IntermediatePhaseFinished or
   FinalPhaseFinished message immediately after sending an
   ApplicationPayload message.  It must allow the client to send an
   ApplicationPayload message prior to concluding the phase.  Thus,
   within any application phase, there will be one more
   ApplicationPayload message sent by the client than sent by the
   server.

   The server determines which type of concluding message is used,
   either IntermediatePhaseFinished or FinalPhaseFinished, and the
   client MUST echo the same type of concluding message.  Each
   IntermediatePhaseFinished or FinalPhaseFinished message provides
   cryptographic confirmation of any session keys generated during the
   current and any prior applications phases.

   Each ApplicationPayload message contains opaque data interpreted as
   an AVP (Attribute-Value Pair) sequence.  Each AVP in the sequence
   contains a typed data element.  The exchanged AVPs allow client and
   server to implement "applications" within a secure tunnel.  An
   application may be any procedure that someone may usefully define.  A
   typical application might be authentication; for example, the server
   may authenticate the client based on password credentials using EAP.
   Other possible applications include distribution of keys, validating
   client integrity, setting up IPsec parameters, setting up SSL VPNs,
   and so on.

   An "inner secret" is computed during each application phase that
   cryptographically combines the TLS master secret with any session
   keys that have been generated during the current and any previous
   application phases.  At the conclusion of each application phase, a
   new inner secret is computed a nd is used to create verification data
   that is exchanged via the IntermediatePhaseFinished or
   FinalPhaseFinished messages.  By mixing session keys of inner
   authentications with the TLS master secret, certain man-in-the-middle
   attacks are thwarted [MITM].

2.2.  Message Exchange

   Each intermediate application phase consists of ApplicationPayload
   messages sent alternately by client and server, and a concluding
   exchange of IntermediatePhaseFinished messages.  The first and last
   ApplicationPayload message in each intermediate phase is sent by the
   client; the first IntermediatePhaseFinished message is sent by the
   server.  Thus the client begins the exchange with an
   ApplicationPayload message and the server determines when to conclude



Funk, et al.            Expires December 27, 2006               [Page 9]

Internet-Draft            TLS inner Application                June 2006


   it by sending IntermediatePhaseFinished.  When it receives the
   server's IntermediatePhaseFinished message, the client sends its own
   IntermediatePhaseFinished message, followed by an ApplicationPayload
   message to begin the next handshake phase.

   The final application proceeds in the same manner as the intermediate
   phase, except that the FinalPhaseFinished message is sent by the
   server and echoed by the client, and the client does not send an
   ApplicationPayload message for the next phase because there is no
   next phase.

   At the start of each application phase, the server MUST wait for the
   client's opening ApplicationPayload message before it sends its own
   ApplicationPayload message to the client.  The client MUST NOT
   initiate conclusion of an application phase by sending the first
   IntermediatePhaseFinished or FinalPhaseFinished message; it MUST
   allow the server to initiate the conclusion of the phase.

   Note that it is perfectly acceptable for either client or server to
   send an ApplicationPayload message containing no AVPs.  The client,
   for example, may have no AVPs to send in its first or last
   ApplicationPayload message during an application phase.

2.3.  Inner Secret

   The inner secret is a 48-octet value used to confirm that the
   endpoints of the TLS handshake are the same entities as the endpoints
   of the inner authentications that may have been performed during each
   application phase.

   The inner secret is initialized to the master secret at the
   conclusion of the TLS handshake.  At the conclusion of each
   application phase, prior to computing verification data for inclusion
   in the IntermediatePhaseFinished or FinalPhaseFinished message, each
   party permutes the inner secret using a PRF that includes session
   keys produced during the current application phase.  The value that
   results replaces the current inner secret and is used to compute the
   verification data.


   inner_secret = PRF(inner_secret,
                      "inner secret permutation",
                      SecurityParameters.server_random +
                      SecurityParameters.client_random +
                                     session_key_material) [0..48];

   session_key_material is the concatenation of session_key vectors,
   one for each session key generated during the current phase, where:



Funk, et al.            Expires December 27, 2006              [Page 10]

Internet-Draft            TLS inner Application                June 2006


           opaque session_key<1..2^16-1>;


   In other words, each session key is prefixed by a 2-octet length to
   produce the session_key vector.

   Since multiple session keys may be produced during a single
   application phase, the following method is used to determine the
   order of concatenation: Each session key is treated as an unsigned
   big-endian numeric value, and the set of session keys is ordered from
   lowest to highest.  The session keys are then converted to
   session_key vectors and concatenated in the determined order to form
   session_key_material.

   If no session keys were generated during the current phase,
   session_key_material will be null.

   Note that session_key_material itself is not a vector and therefore
   not prefixed with the length of the entire collection of session_key
   vectors.  Note that, within TLS itself, the inner secret is used for
   verification only, not for encryption.  However, the inner secret
   resulting from the final application phase may be exported for use as
   a key from which additional session keys may be derived for arbitrary
   purposes, including encryption of data communications separate from
   TLS.

   An exported inner secret should not be used directly for any
   cryptographic purpose.  Instead, additional keys should be derived
   from the inner secret, for example by using a PRF.  This ensures
   cryptographic separation between use of the inner secret for session
   key confirmation and additional use of the inner secret outside
   TLS/IA.

2.3.1.  Application Session Key Material

   Many authentication protocols used today generate session keys that
   are bound to the authentication.  Such keying material is normally
   intended for use in a subsequent data connection for encryption and
   validation.  For example, EAP-TLS, MS-CHAP-V2, and EAP-MS-CHAP-V2
   generate session keys.

   Any session keys generated during an application phase MUST be used
   to permute the TLS/IA inner secret between one phase and the next,
   and MUST NOT be used for any other purpose.

   Each authentication protocol may define how the session key it
   generates is mapped to an octet sequence of some length for the
   purpose of TLS/IA mixing.  However, for protocols which do not



Funk, et al.            Expires December 27, 2006              [Page 11]

Internet-Draft            TLS inner Application                June 2006


   specify this (including the multitude of protocols that pre-date
   TLS/IA) the following rules are defined.  The first rule that applies
   SHALL be the method for determining the session key.

      If the authentication protocol produces an MSK (as defined in
      [RFC3784]), the MSK is used as the session key.  Note that an MSK
      is 64 octets.


      If the authentication protocol maps its keying material to the
      RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key
      [RFC2548]], then the keying material for those attributes are
      concatenated, with MS-MPPE-Recv-Key first (Note that this rule
      applies to MS-CHAP-V2 and EAP-MS-CHAP-V2.)


      If the authentication protocol uses a pseudo-random function to
      generate keying material, that function is used to generate 64
      octets for use as keying material.

   Providing verification of the binding of session keys to the TLS
   master secret is necessary to preclude man-in-the-middle attacks
   against tunneled authentication protocols, as described in [MITM].
   In such an attack, an unsuspecting client is induced to perform an
   untunneled authentication with an attacker posing as a server; the
   attacker then introduces the authentication protocol into a tunneled
   authentication protocol, fooling an authentic server into believing
   that the attacker is the authentic user.

   By mixing both the TLS master secret and session keys generated
   during application phase authentication into the inner secret used
   for application phase verification, such attacks are thwarted, as it
   guarantees that the same client acted as the endpoint for both the
   TLS handshake and the application phase authentication.  Note that
   the session keys generated during authentication must be
   cryptographically bound to the authentication and not derivable from
   data exchanged during authentication in order for the keying material
   to be useful in thwarting such attacks.

   In addition, the fact that the inner secret cryptographically
   incorporates session keys from application phase authentications
   provides additional protection when the inner secret is exported for
   the purpose of generating additional keys for use outside of the TLS
   exchange.  If such an exported secret did not include keying material
   from inner authentications, an eavesdropper who somehow knew the
   server's private key could, in an RSA-based handshake, determine the
   exported secret and hence would be able to compute the additional
   keys that are based on it.  When inner authentication keying



Funk, et al.            Expires December 27, 2006              [Page 12]

Internet-Draft            TLS inner Application                June 2006


   material, unknown to the attacker, is incorporated into the exported
   secret, such an attack becomes infeasible.

2.4.  Session Resumption

   A TLS/IA initial handshake phase may be resumed using standard
   mechanisms defined in [RFC2246].  When the TLS session is resumed,
   client and server may not deem it necessary to exchange AVPs in one
   or more additional application phases, as the resumption itself may
   provide the necessary security.

   The client indicates within the InnerApplicationExtension message in
   ClientHello whether it requires AVP exchange when session resumption
   occurs.  If it indicates that it does not, then the server may at its
   option omit application phases and the two parties proceed to upper
   layer data communications immediately upon completion of the TLS
   handshake.  The server indicates whether application phases are to
   follow the TLS handshake in its InnerApplication extension message in
   ServerHello.

   Note that [RFC3546] specifically states that when session resumption
   is used, the server MUST ignore any extensions in the ClientHello.
   However, it is not possible to comply with this requirement for the
   Inner Application extension, since even in a resumed session it may
   be necessary to include application phases, and whether they must be
   included is negotiated in the extension message itself.  Therefore,
   the [RFC3546] provision is explicitly overridden for the single case
   of the Inner Application extension, which is considered an exception
   to this rule.

   A TLS/IA session MAY NOT be resumed if an application phase resulted
   in failure, even though the TLS handshake itself succeeded.  Both
   client and server MUST NOT save session state for possible future
   resumption unless the TLS handshake and all subsequent application
   phases have been successfully executed.

2.5.  Error Termination

   The TLS/IA handshake may be terminated by either party sending a
   fatal alert, following standard TLS procedures.

2.6.  Negotiating the Inner Application Extension

   Use of the InnerApplication extension follows [RFC3546].  The client
   proposes use of this extension by including the
   InnerApplicationExtension message in the client_hello_extension_list
   of the extended ClientHello.  If this message is included in the
   ClientHello, the server MAY accept the proposal by including the



Funk, et al.            Expires December 27, 2006              [Page 13]

Internet-Draft            TLS inner Application                June 2006


   InnerApplicationExtension message in the server_hello_extension_list
   of the extended ServerHello.  If use of this extension is either not
   proposed by the client or not confirmed by the server, the
   InnerApplication record type MUST NOT be used.

2.7.  InnerApplication Protocol

   All specifications of TLS/IA messages follow the usage defined in
   [RFC2246].

2.7.1.  InnerApplicationExtension


     enum {
           no(0), yes(1), (255)
     } AppPhaseOnResumption;

     struct {
           AppPhaseOnResumption app_phase_on_resumption;
     } InnerApplicationExtension;

   If the client wishes to propose use of the Inner Application
   extension, it must include the InnerApplicationExtension message in
   the extension_data vector in the Extension structure in its extended
   ClientHello message.

   If the server wishes to confirm use of the Inner Application
   extension that has been proposed by the client, it must include the
   InnerApplicationExtension message in the extension_data vector in the
   Extension structure in its extended ServerHello message.  The
   AppPhaseOnResumption enumeration allow client and server to negotiate
   an abbreviated, single-phase handshake when session resumption is
   employed.  If the client sets app_phase_on_resumption to "no", and if
   the server resumes the previous session, then the server MAY set
   app_phase_on_resumption to "no" in the InnerApplication message it
   sends to the client.  If the server sets app_phase_on_resumption to
   "no", no application phases occur and the TLS connection proceeds to
   upper layer data exchange immediately upon conclusion of the TLS
   handshake.

   The server MUST set app_phase_on_resumption to "yes" if the client
   set app_phase_on_resumption to "yes" or if the server does not resume
   the session.  The server MAY set app_phase_on_resumption to "yes" for
   a resumed session even if the client set app_phase_on_resumption to
   "no", as the server may have reason to proceed with one or more
   application phases.

   If the server sets app_phase_on_resumption to "yes" for a resumed



Funk, et al.            Expires December 27, 2006              [Page 14]

Internet-Draft            TLS inner Application                June 2006


   session, then the client MUST initiate an application phase at the
   conclusion of the TLS handshake.

   The value of app_phase_on_resumption applies to the current handshake
   only; that is, it is possible for app_phase_on_resumption to have
   different values in two handshakes that are both resumed from the
   same original TLS session.

2.7.2.  InnerApplication Message


         enum {
            application_payload(0), intermediate_phase_finished(1),
            final_phase_finished(2), (255)
         } InnerApplicationType;

         struct {
            InnerApplicationType msg_type;
            uint24 length;
            select (InnerApplicationType) {
               case application_payload:       ApplicationPayload;
               case intermediate_phase_finished:
            IntermediatePhaseFinished;
               case final_phase_finished:      FinalPhaseFinished;
               } body;
            } InnerApplication;

   The InnerApplication message carries any of the message types defined
   for the InnerApplication protocol.

2.7.3.  IntermediatePhaseFinished and FinalPhaseFinished Messages


         struct {
            opaque verify_data[12];
         } PhaseFinished;

         PhaseFinished IntermediatePhaseFinished;

         PhaseFinished FinalPhaseFinished;

         verify_data
            PRF(inner_secret, finished_label) [0..11];

         finished_label
            when sent by the client, the string "client phase finished"
            when sent by the server, the string "server phase finished"




Funk, et al.            Expires December 27, 2006              [Page 15]

Internet-Draft            TLS inner Application                June 2006


   The IntermediatePhaseFinished and FinalPhaseFinished messages have
   the same structure and include verification data based on the current
   inner secret.  IntermediatePhaseFinished is sent by the server and
   echoed by the client to conclude an intermediate application phase,
   and FinalPhaseFinished is used in the same manner to conclude the
   final application phase.

2.7.4.  The ApplicationPayload Message

   The ApplicationPayload message carries an AVP sequence during an
   application handshake phase.  It is defined as follows:

         struct {
            opaque avps[InnerApplication.length];
         } ApplicationPayload;

         avps
            The AVP sequence, treated as an opaque sequence of octets.

         InnerApplication.length
            The length field in the encapsulating InnerApplication
         message.

   Note that the "avps" element has its length defined in square bracket
   rather than angle bracket notation, implying a fixed rather than
   variable length vector.  This avoids having the length of the AVP
   sequence specified redundantly both in the encapsulating
   InnerApplication message and as a length prefix in the avps element
   itself.

2.8.  Alerts

   Two new alert codes are defined for use during an application phase.
   The AlertLevel for either of these alert codes MUST be set to
   "fatal".

   InnerApplicationFailure: An InnerApplicationFailure error alert may
   be sent by either party during an application phase.  This indicates
   that the sending party considers the negotiation to have failed due
   to an application carried in the AVP sequences, for example, a failed
   authentication.

   InnerApplicationVerification: An InnerApplicationVerification error
   alert is sent by either party during an application phase to indicate
   that the received IntermediatePhaseFinished or FinalPhaseFinished is
   invalid.

   Note that other alerts are possible during an application phase; for



Funk, et al.            Expires December 27, 2006              [Page 16]

Internet-Draft            TLS inner Application                June 2006


   example, decrypt_error.  The InnerApplicationFailure alert relates
   specifically to the failure of an application implemented via AVP
   sequences; for example, failure of an EAP or other authentication
   method, or information passed within the AVP sequence that is found
   unsatisfactory.














































Funk, et al.            Expires December 27, 2006              [Page 17]

Internet-Draft            TLS inner Application                June 2006


3.  Encapsulation of AVPs within ApplicationPayload Messages

   During application phases of the TLS handshake, information is
   exchanged between client and server through the use of attribute-
   value pairs (AVPs).  This data is encrypted using the current cipher
   state.

   The AVP format chosen for TLS/IA is compatible with the Diameter AVP
   format.  This does not in any way represent a requirement that
   Diameter be supported by any of the devices or servers participating
   in the TLS/IA conversation, whether directly as client or server or
   indirectly as a backend authenticator.  Use of this format is merely
   a convenience.  Diameter is a superset of RADIUS and includes the
   RADIUS attribute namespace by definition, though it does not limit
   the size of an AVP as does RADIUS.  RADIUS, in turn, is a widely
   deployed AAA protocol and attribute definitions exist for the
   encapsulation of EAP as well as all commonly used non-EAP password
   authentication protocols.

   Thus, Diameter is not considered normative except as specified in
   this document.  Specifically, the AVP Codes used in TLS/IA are
   semantically equivalent to those defined for Diameter, and, by
   extension, RADIUS.

   Use of the RADIUS/Diameter namespace allows a TLS/IA server to
   translate between AVPs it uses to communicate with clients and the
   protocol requirements of AAA servers that are widely deployed.
   Additionally, it provides a well-understood mechanism to allow
   vendors to extend that namespace for their particular requirements.

3.1.  AVP Format

   The format of an AVP is shown below.  All items are in network, or
   big-endian, order; that is, they have most significant octet first.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r|                  AVP Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Vendor-ID (opt)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+-+-+-+-+





Funk, et al.            Expires December 27, 2006              [Page 18]

Internet-Draft            TLS inner Application                June 2006


   AVP Code

      The AVP Code is four octets and, combined with the Vendor-ID field
      if present, identifies the attribute uniquely.  The first 256 AVP
      numbers represent attributes defined in RADIUS.  AVP numbers 256
      and above are defined in Diameter.

   AVP Flags

      The AVP Flags field is one octet, and provides the receiver with
      information necessary to interpret the AVP.

      The 'V' (Vendor-Specific) bit indicates whether the optional
      Vendor-ID field is present.  When set to 1, the Vendor-ID field is
      present and the AVP Code is interpreted according to the namespace
      defined by the vendor indicated in the Vendor-ID field.

      The 'M' (Mandatory) bit indicates whether support of the AVP is
      required.  When set to 0, this indicates that the AVP may be
      safely ignored if the receiving party does not understand or
      support it.  When set to 1, if the receiving party does not
      understand or support the AVP it MUST fail the negotiation by
      sending an InnerApplicationFailure error alert.  The 'r'
      (reserved) bits are unused and must be set to 0.

   AVP Length

      The AVP Length field is three octets, and indicates the length of
      this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID
      (if present) and Data.

   Vendor-ID

      The Vendor-ID field is present if and only if the 'V' bit is set
      in the AVP Flags field.  It is four octets, and contains the
      vendor's IANA-assigned "SMI Network Management Private Enterprise
      Codes" [RFC1700] value.  Vendors defining their own AVPs must
      maintain a consistent namespace for use of those AVPs within
      RADIUS, Diameter and TLS/IA.  A Vendor-ID value of zero is
      semantically equivalent to absence of the Vendor-ID field
      altogether.


3.2.  AVP Sequences

   Data encapsulated within the TLS Record Layer must consist entirely
   of a sequence of zero or more AVPs.  Each AVP must begin on a 4-octet
   boundary relative to the first AVP in the sequence.  If an AVP is not



Funk, et al.            Expires December 27, 2006              [Page 19]

Internet-Draft            TLS inner Application                June 2006


   a multiple of 4 octets, it must be padded with 0s to the next 4-octet
   boundary.  Note that the AVP Length does not include the padding.


3.3.  Guidelines for Maximum Compatibility with AAA Servers

   When maximum compatibility with AAA servers is desired, the following
   guidelines for AVP usage are suggested:
      Non-vendor-specific AVPs should be selected from the set of
      attributes defined for RADIUS; that is, attributes with codes less
      than 256.  This provides compatibility with both RADIUS and
      Diameter.
      Vendor-specific AVPs should be defined in terms of RADIUS.
      Vendor-specific RADIUS attributes translate to Diameter
      automatically; the reverse is not true.  RADIUS vendor-specific
      attributes use RADIUS attribute 26 and include vendor ID, vendor-
      specific attribute code and length; see[RFC2865] for details.


































Funk, et al.            Expires December 27, 2006              [Page 20]

Internet-Draft            TLS inner Application                June 2006


4.  Tunneled Authentication within Application Phases

   TLS/IA permits user authentication information to be tunneled within
   an application phase between client and server, protecting the
   authentication information against active and passive attack.

   Any type of authentication method may be tunneled.  Also, multiple
   tunneled authentications may be performed.  Normally, tunneled
   authentication is used when the TLS handshake provides only one-way
   authentication of the server to the client; however, in certain cases
   it may be desirable to perform certificate authentication of the
   client during the initial handshake phase as well as tunneled user
   authentication in a subsequent application phase.

   This section establishes rules for using well known authentication
   mechanisms within TLS/IA.  Any new authentication mechanism should,
   in general, be covered by these rules if it is defined as an EAP
   type.  Authentication mechanisms whose use within TLS/IA is not
   covered within this specification may require separate
   standardization, preferably within the standard that describes the
   authentication mechanism in question.

4.1.  Implicit challenge

   Certain authentication protocols that use a challenge/response
   mechanism rely on challenge material that is not generated by the
   authentication server, and therefore require special handling.

   In PPP protocols such CHAP, MS-CHAP and MS-CHAP-V2, for example, the
   Network Access Server (NAS) issues a challenge to the client, the
   client then hashes the challenge with the password and forwards the
   response to the NAS.  The NAS then forwards both challenge and
   response to a AAA server.  But because the AAA server did not itself
   generate the challenge, such protocols are susceptible to replay
   attack.

   Since within TLS/IA the client also plays the role of NAS, the replay
   problem is exacerbated.  If the client were able to create both
   challenge and response, anyone able to observe a CHAP or MS-CHAP
   exchange could pose as that user by replaying that challenge and
   response into a TLS/IA conversation.

   To make these protocols secure in TLS/IA, it is necessary to provide
   a mechanism that produces a challenge that the client cannot control
   or predict.  When a challenge-based authentication mechanism is used,
   both client and server use the TLS PRF function to generate as many
   octets as are required for the challenge, using the constant string
   "inner application challenge", based on the master secret and random



Funk, et al.            Expires December 27, 2006              [Page 21]

Internet-Draft            TLS inner Application                June 2006


   values established during the TLS handshake, as follows.

           IA_challenge = PRF(SecurityParameters.master_secret,
                             "inner application challenge",
                             SecurityParameters.server_random +
                             SecurityParameters.client_random);

4.2.  Tunneled Authentication Protocols

   This section describes the rules for tunneling specific
   authentication protocols within TLS/IA.  For each protocol, the
   RADIUS RFC that defines the relevant attribute formats is cited.
   Note that these attributes are encapsulated as described in section
   3.1; that is, as Diameter attributes, not as RADIUS attributes.  In
   other words, the AVP Code, Length, Flags and optional Vendor-ID are
   formatted as described in section 3.1, while the Data is formatted as
   described by the cited RADIUS RFC.

   All tunneled authentication protocols except EAP must be initiated by
   the client in the first ApplicationPayload message of an application
   phase.  EAP may be initiated by the client in the first
   ApplicationPayload message of an application phase; it may also be
   initiated by the server in any ApplicationPayload message.

   The authentication protocols described below may be performed
   directly by the TLS/IA server or may be forwarded to a backend AAA
   server.  For authentication protocols that generate session keys, the
   backend server must return those session keys to the TLS/IA server in
   order to allow the protocol to succeed within TLS/IA.  RADIUS or
   Diameter servers are suitable backend AAA servers for this purpose.
   RADIUS servers typically return session keys in MS-MPPE-Recv-Key and
   MS-MPPE-Send-Key attributes [RFC2548]; Diameter servers return
   session keys in the EAP-Master-Session-Key AVP [I-D.ietf-aaa-eap].

4.2.1.  EAP

   EAP is described in [RFC3784]; RADIUS attribute formats are described
   in [RFC3579].  When EAP is the tunneled authentication protocol, each
   tunneled EAP packet between the client and server is encapsulated in
   an EAP-Message AVP.  Either the client or the server may initiate
   EAP.

   The client is the first to transmit within any application phase, and
   it may include an EAP-Response/Identity AVP in its ApplicationPayload
   message to begin an EAP conversation.  Alternatively, if the client
   does not initiate EAP the server may, by including an EAP-Request/
   Identity AVP in its ApplicationPayload message.  The client's EAP-
   Response/Identity provides the username, which MUST be a Network



Funk, et al.            Expires December 27, 2006              [Page 22]

Internet-Draft            TLS inner Application                June 2006


   Access Identifier (NAI) [RFC2486]; that is, it MUST be in the
   following format: username@realm

   The @realm portion is optional, and is used to allow the server to
   forward the EAP message sequence to the appropriate server in the AAA
   infrastructure when necessary.

   The EAP authentication between client and server proceeds normally,
   as described in [RFC3784].  However, upon completion the server does
   not send an EAP-Success or EAP-Failure AVP.  Instead, the server
   signals success when it concludes the application phase by issuing a
   Finished or PhaseFinished message, or it signals failure by issuing
   an InnerApplicationFailure alert.

   Note that the client may also issue an InnerApplicationFailure alert,
   for example, when authentication of the server fails in a method
   providing mutual authentication.

4.2.2.  CHAP

   The CHAP algorithm is described in [RFC1994]; RADIUS attribute
   formats are described in [RFC2865].

   Both client and server generate 17 octets of challenge material,
   using the constant string "inner application challenge" as described
   above.  These octets are used as follows:
      CHAP-Challenge [16 octets]
      CHAP Identifier [1 octet]

   The client initiates CHAP by including User-Name, CHAP-Challenge and
   CHAP-Password AVPs in the first ApplicationPayload message in any
   application phase.  The CHAP-Challenge value is taken from the
   challenge material.  The CHAP-Password consists of CHAP Identifier,
   taken from the challenge material; and CHAP response, computed
   according to the CHAP algorithm.

   Upon receipt of these AVPs from the client, the server must verify
   that the value of the CHAP-Challenge AVP and the value of the CHAP
   Identifier in the CHAP-Password AVP are equal to the values generated
   as challenge material.  If either item does not match, the server
   must reject the client.  Otherwise, it validates the CHAP-Challenge
   to determine the result of the authentication.

4.2.3.  MS-CHAP

   The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute
   formats are described in [RFC2548].




Funk, et al.            Expires December 27, 2006              [Page 23]

Internet-Draft            TLS inner Application                June 2006


   Both client and server generate 9 octets of challenge material, using
   the constant string "inner application challenge" as described above.
   These octets are used as follows:
      MS-CHAP-Challenge [8 octets]
      Ident [1 octet]

   The client initiates MS-CHAP by including User-Name, MS-CHAP-
   Challenge and MS-CHAP-Response AVPs in the first ApplicationPayload
   message in any application phase.  The MS-CHAP-Challenge value is
   taken from the challenge material.  The MS-CHAP-Response consists of
   Ident, taken from the challenge material; Flags, set according the
   client preferences; and LM-Response and NT-Response, computed
   according to the MS-CHAP algorithm.

   Upon receipt of these AVPs from the client, the server must verify
   that the value of the MS-CHAP-Challenge AVP and the value of the
   Ident in the client's MS-CHAP-Response AVP are equal to the values
   generated as challenge material.  If either item does not match
   exactly, the server must reject the client.  Otherwise, it validates
   the MS-CHAP-Challenge to determine the result of the authentication.

4.2.4.  MS-CHAP-V2

   The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute
   formats are described in [RFC2548].

   Both client and server generate 17 octets of challenge material,
   using the constant string "inner application challenge" as described
   above.  These octets are used as follows:
      MS-CHAP-Challenge [16 octets]
      Ident [1 octet]

   The client initiates MS-CHAP-V2 by including User-Name, MS-CHAP-
   Challenge and MS-CHAP2-Response AVPs in the first ApplicationPayload
   message in any application phase.  The MS-CHAP-Challenge value is
   taken from the challenge material.  The MS-CHAP2-Response consists of
   Ident, taken from the challenge material; Flags, set to 0; Peer-
   Challenge, set to a random value; and Response, computed according to
   the MS-CHAP-V2 algorithm.

   Upon receipt of these AVPs from the client, the server must verify
   that the value of the MS-CHAP-Challenge AVP and the value of the
   Ident in the client's MS-CHAP2-Response AVP are equal to the values
   generated as challenge material.  If either item does not match
   exactly, the server must reject the client.  Otherwise, it validates
   the MS-CHAP2-Challenge.

   If the MS-CHAP2-Challenge received from the client is correct, the



Funk, et al.            Expires December 27, 2006              [Page 24]

Internet-Draft            TLS inner Application                June 2006


   server tunnels the MS-CHAP2-Success AVP to the client.

   Upon receipt of the MS-CHAP2-Success AVP, the client is able to
   authenticate the server.  In its next InnerApplicationPayload message
   to the server, the client does not include any MS-CHAP-V2 AVPs.
   (This may result in an empty InnerApplicationPayload if no other AVPs
   need to be sent.)

   If the MS-CHAP2-Challenge received from the client is not correct,
   the server tunnels an MS-CHAP2-Error AVP to the client.  This AVP
   contains a new Ident and a string with additional information such as
   error reason and whether a retry is allowed.  If the error reason is
   an expired password and a retry is allowed, the client may proceed to
   change the user's password.  If the error reason is not an expired
   password or if the client does not wish to change the user's
   password, it issues an InnerApplicationFailure alert.

   If the client does wish to change the password, it tunnels MS-CHAP-
   NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the server.
   The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge
   received in the MS-CHAP2-Error AVP.  The MS-CHAP-Challenge AVP simply
   echoes the new Challenge.

   Upon receipt of these AVPs from the client, the server must verify
   that the value of the MS-CHAP-Challenge AVP and the value of the
   Ident in the client's MS-CHAP2-CPW AVP match the values it sent in
   the MS-CHAP2-Error AVP.  If either item does not match exactly, the
   server must reject the client.  Otherwise, it validates the MS-CHAP2-
   CPW AVP.

   If the MS-CHAP2-CPW AVP received from the client is correct, and the
   server is able to change the user's password, the server tunnels the
   MS-CHAP2-Success AVP to the client and the negotiation proceeds as
   described above.

   Note that additional AVPs associated with MS-CHAP-V2 may be sent by
   the server; for example, MS-CHAP-Domain.  The server must tunnel such
   authentication-related AVPs along with the MS-CHAP2-Success.

4.2.5.  PAP

   PAP RADIUS attribute formats are described in [RFC2865].

   The client initiates PAP by including User-Name and User-Password
   AVPs in the first ApplicationPayload message in any application
   phase.

   In RADIUS, User-Password is padded with nulls to a multiple of 16



Funk, et al.            Expires December 27, 2006              [Page 25]

Internet-Draft            TLS inner Application                June 2006


   octets, then encrypted using a shared secret and other packet
   information.

   A TLS/IA, however, does not RADIUS-encrypt the password since all
   application phase data is already encrypted.  The client SHOULD,
   however, null-pad the password to a multiple of 16 octets, to
   obfuscate its length.

   Upon receipt of these AVPs from the client, the server may be able to
   decide whether to authenticate the client immediately, or it may need
   to challenge the client for more information.

   If the server wishes to issue a challenge to the client, it MUST
   tunnel the Reply-Message AVP to the client; this AVP normally
   contains a challenge prompt of some kind.  It may also tunnel
   additional AVPs if necessary, such the Prompt AVP.  Upon receipt of
   the Reply-Message AVPs, the client tunnels User-Name and User-
   Password AVPs again, with the User-Password AVP containing new
   information in response to the challenge.  This process continues
   until the server determines the authentication has succeeded or
   failed.

4.3.  Performing Multiple Authentications

   In some cases, it is desirable to perform multiple user
   authentications.  For example, a server may want first to
   authenticate the user by password, then by a hardware token.

   The server may perform any number of additional user authentications
   using EAP, simply by issuing a EAP-Request with a new protocol type
   once the previous authentication has completed.

   For example, a server wishing to perform MD5-Challenge followed by
   Generic Token Card would first issue an EAP-Request/MD5-Challenge AVP
   and receive a response.  If the response is satisfactory, it would
   then issue EAP-Request/Generic Token Card AVP and receive a response.
   If that response were also satisfactory, it would consider the user
   authenticated.













Funk, et al.            Expires December 27, 2006              [Page 26]

Internet-Draft            TLS inner Application                June 2006


5.  Example Message Sequences

   This section presents a variety of possible TLS/IA message sequences.
   These examples are not meant to exhaustively depict all possible
   scenarios.

   Parentheses indicate optional TLS messages.  Brackets indicate
   optional message exchanges.  An ellipsis (. . .) indicates optional
   repetition of preceding messages.

5.1.  Full Initial Handshake with Intermediate and Final Application
      Phasess

   The diagram below depicts a full initial handshake phase followed by
   two application phases.

   Note that the client concludes the intermediate phase and starts the
   final phase in an uninterrupted sequence of three messages:
   ChangeCipherSpec and PhaseFinished belong to the intermediate phase,
   and ApplicationPayload belongs to the final phase.































Funk, et al.            Expires December 27, 2006              [Page 27]

Internet-Draft            TLS inner Application                June 2006


         Client                                               Server
         ------                                               ------

   *** TLS Handshake:
         ClientHello                -------->
                                                         ServerHello
                                                       (Certificate)
                                                   ServerKeyExchange
                                                (CertificateRequest)
                                     <--------      ServerHelloDone
         (Certificate)
         ClientKeyExchange
         (CertificateVerify)
         ChangeCipherSpec
         Finished                   -------->
                                                    ChangeCipherSpec
                                    <--------        Finished

   *** Intermediate Phase:
         ApplicationPayload         -------->

       [
                                    <--------  ApplicationPayload

         ApplicationPayload         -------->

                                         ...
       ]
                                    <-------- IntermediatePhaseFinished
         IntermediatePhaseFinished
   *** Final Phase:
         ApplicationPayload         -------->

       [
                                    <--------   ApplicationPayload

         ApplicationPayload         -------->

                                         ...
       ]
                                    <--------   FinalPhaseFinished

         FinalPhaseFinished         -------->








Funk, et al.            Expires December 27, 2006              [Page 28]

Internet-Draft            TLS inner Application                June 2006


5.2.  Resumed Session with Single Application Phase

   The diagram below depicts a resumed session followed by a single
   application phase.

   Note that the client concludes the initial phase and starts the final
   phase in an uninterrupted sequence of three messages:
   ChangeCipherSpec and PhaseFinished belong to the initial phase, and
   ApplicationPayload belongs to the final phase.


         Client                                               Server
         ------                                               ------

   *** TLS Handshake:
         ClientHello                  -------->
                                                         ServerHello
                                                    ChangeCipherSpec
                                      <--------             Finished
         ChangeCipherSpec
         Finished
   *** Final Phase:
         ApplicationPayload           -------->

       [
                                      <--------   ApplicationPayload

         ApplicationPayload           -------->

                                         ...
       ]
                                      <--------   FinalPhaseFinished

         FinalPhaseFinished           -------->



5.3.  Resumed Session with No Application Phase

   The diagram below depicts a resumed session without any subsequent
   application phase.  This will occur if the client indicates in its
   ClientInnerApplication message that no application phase is required
   and the server concurs.  Note that this message sequence is identical
   to that of a standard TLS resumed session.







Funk, et al.            Expires December 27, 2006              [Page 29]

Internet-Draft            TLS inner Application                June 2006


         Client                                               Server
         ------                                               ------

   *** TLS Handshake:
         ClientHello                  -------->
                                                         ServerHello
                                                    ChangeCipherSpec
                                      <--------             Finished
         ChangeCipherSpec
         Finished                     -------->









































Funk, et al.            Expires December 27, 2006              [Page 30]

Internet-Draft            TLS inner Application                June 2006


6.  Security Considerations

   This document introduces a new TLS extension called "Inner
   Application".  When TLS is used with the Inner Application extension
   (TLS/IA), additional messages are exchanged during the TLS handshake.
   Hence a number of security issues need to be taken into
   consideration.  Since the security heavily depends on the information
   (called "applications") which are exchanged between the TLS client
   and the TLS server as part of the TLS/IA extension we try to classify
   them into two categories: The first category considers the case where
   the exchange results in the generation of keying material.  This is,
   for example, the case with certain EAP methods.  EAP is one of the
   envisioned main "applications".  The second category focuses on cases
   where no session key is generated.  The security treatment of the
   latter category is discouraged since it is subject to man-in-the-
   middle attacks if the two sessions cannot be bound to each other as
   suggested in [MITM].

   In the following, we investigate a number of security issues:

   Architecture and Trust Model

      For many of the use cases in this document we assume that three
      functional entities participate in the protocol exchange: TLS
      client, TLS server and a AAA infrastructure (typically consisting
      of a AAA server and possibly a AAA broker).  The protocol exchange
      described in this document takes place between the TLS client and
      the TLS server.  The interaction between the AAA client (which
      corresponds to the TLS server) and the AAA server is described in
      the respective AAA protocol documents and therefore outside the
      scope of this document.  The trust model behind this architecture
      with respect to the authentication, authorization, session key
      establishment and key transport within the AAA infrastructure is
      discussed in [I-D.ietf-eap-keying].

   Authentication

      This document assumes that the TLS server is authenticated to the
      TLS client as part of the authentication procedure of the initial
      TLS Handshake.  This approach is similar to the one chosen with
      the EAP support in IKEv2 (see [RFC4306].  Typically, public key
      based server authentication is used for this purpose.  More
      interesting is the client authentication property whereby
      information exchanged as part of the Inner Application is used to
      authenticate (or authorize) the client.  For example, if EAP is
      used as an inner application then EAP methods are used to perform
      authentication and key agreement between the EAP peer (most likely
      the TLS client) and the EAP server (i.e., AAA server).



Funk, et al.            Expires December 27, 2006              [Page 31]

Internet-Draft            TLS inner Application                June 2006


   Authorization

      Throughout this document it is assumed that the TLS server can be
      authorized by the TLS client as a legitimate server as part of the
      authentication procedure of the initial TLS Handshake.  The entity
      acting as TLS client can be authorized either by the TLS server or
      by the AAA server (if the authorization decision is offloaded).
      Typically, the authenticated identity is used to compute the
      authorization decision but credential-based authorization
      mechanisms may be used as well.

   Man-in-the-Middle Attack

      Man-in-the-middle attacks have become a concern with tunneled
      authentication protocols because of the discovered vulnerabilities
      (see [MITM]) of a missing cryptographic binding between the
      independent protocol sessions.  This document also proposes a
      tunneling protocol, namely individual inner application sessions
      are tunneled within a previously executed session.  The first
      protocol session in this exchange is the initial TLS Handshake.
      To avoid man-in-the-middle attacks a number of sections address
      how to establish such a cryptographic binding (see Section 2.3).

   User Identity Confidentiality

      The TLS/IA extension allows splitting the authentication of the
      TLS server from the TLS client into two separate sessions.  As one
      of the advantages, this provides active user identity
      confidentiality since the TLS client is able to authenticate the
      TLS server and to establish a unilateral authenticated and
      confidentiality-protected channel prior to starting the client-
      side authentication.

   Session Key Establishment

      TLS [RFC2246] defines how session key material produced during the
      TLS Handshake is generated with the help of a pseudo-random
      function to expand it to keying material of the desired length for
      later usage in the TLS Record Layer.  Section 2.3 gives some
      guidelines with regard to the master key generation.  Since the
      TLS/IA extension supports multiple exchanges whereby each phase
      concludes with a generated keying material.  In addition to the
      keying material established as part of TLS itself, most inner
      applications will produce their keying material.  For example,
      keying material established as part of an EAP method must be
      carried from the AAA server to the AAA client.  Details are
      subject to the specific AAA protocol (for example, EAP usage in
      Diameter [I-D.ietf-aaa-eap]).



Funk, et al.            Expires December 27, 2006              [Page 32]

Internet-Draft            TLS inner Application                June 2006


   Denial of Service Attacks

      This document does not modify the initial TLS Handshake and as
      such, does not introduce new vulnerabilities with regard to DoS
      attacks.  Since the TLS/IA extension allows to postpone the
      client-side authentication to a later stage in the protocol phase.
      As such, it allows malicious TLS clients to initiate a number of
      exchanges while remaining anonymous.  As a consequence, state at
      the server is allocated and computational efforts are required at
      the server side.  Since the TLS client cannot be stateless this is
      not strictly a DoS attack.

   Confidentiality Protection and Dictionary Attack Resistance

      Similar to the user identity confidentiality property the usage of
      the TLS/IA extension allows to establish a unilateral
      authenticated tunnel which is confidentiality protected.  This
      tunnel protects the inner application information elements to be
      protected against active adversaries and therefore provides
      resistance against dictionary attacks when password-based
      authentication protocols are used inside the tunnel.  In general,
      information exchanged inside the tunnel experiences
      confidentiality protection.

   Downgrading Attacks

      This document defines a new extension.  The TLS client and the TLS
      server indicate the capability to support the TLS/IA extension as
      part of the client_hello_extension_list and the
      server_hello_extension_list payload.  More details can be found in
      Section 2.6.  To avoid downgrading attacks whereby an adversary
      removes a capability from the list is avoided by the usage of the
      Finish or PhaseFinished message.


















Funk, et al.            Expires December 27, 2006              [Page 33]

Internet-Draft            TLS inner Application                June 2006


7.  References

7.1.  Normative References

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication
              Protocol (CHAP)", RFC 1994, August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2433]  Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
              RFC 2433, October 1998.

   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.

   [RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
              RFC 2548, March 1999.

   [RFC2759]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
              RFC 2759, January 2000.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3784]  Smit, H. and T. Li, "Intermediate System to Intermediate
              System (IS-IS) Extensions for Traffic Engineering (TE)",
              RFC 3784, June 2004.





Funk, et al.            Expires December 27, 2006              [Page 34]

Internet-Draft            TLS inner Application                June 2006


7.2.  Informative References

   [I-D.ietf-aaa-eap]
              Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
              Authentication Protocol (EAP) Application",
              draft-ietf-aaa-eap-10 (work in progress), November 2004.

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-13 (work in
              progress), May 2006.

   [I-D.ietf-pppext-eap-ttls]
              Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
              Authentication Protocol (EAP-TTLS)",
              draft-ietf-pppext-eap-ttls-05 (work in progress),
              July 2004.

   [I-D.ietf-tls-psk]
              Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
              for Transport Layer Security (TLS)", draft-ietf-tls-psk-09
              (work in progress), June 2005.

   [I-D.josefsson-pppext-eap-tls-eap]
              Josefsson, S., Palekar, A., Simon, D., and G. Zorn,
              "Protected EAP Protocol (PEAP) Version 2",
              draft-josefsson-pppext-eap-tls-eap-10 (work in progress),
              October 2004.

   [MITM]     Asokan, N., Niemi, V., Nyberg, K., and W. Dixon, "Man-in-
              the-Middle in Tunneled Authentication", October 2002.

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC2716]  Aboba, B. and D. Simon, "PPP EAP TLS Authentication
              Protocol", RFC 2716, October 1999.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [ieee]     "IEEE Standards for Local and Metropolitan Area Networks:
              Port based Network Access Control", E Std 802.1X-2001,
              June 2001.







Funk, et al.            Expires December 27, 2006              [Page 35]

Internet-Draft            TLS inner Application                June 2006


Authors' Addresses

   Paul Funk
   Funk Software, Inc.
   222 Third Street
   Cambridge, MA  02142
   USA

   Phone: +1 617 497-6339
   Email: paul@funk.com


   Simon Blake-Wilson
   Basic Commerce & Industries, Inc.
   96 Spadina Ave, Unit 606
   Toronto, Ontario  M5V 2J6
   Canada

   Phone: +1 416 214-5961
   Email: sblakewilson@bcisse.com


   Ned Smith
   Intel Corporation.
   2111 N.E. 25th Ave.
   Hillsboro, OR  97124
   USA

   Phone: +1 503 264-2692
   Email: ned.smith@intel.com


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com


   Thomas Hardjono
   Verisign Inc


   Email: thomas@signacert.com




Funk, et al.            Expires December 27, 2006              [Page 36]

Internet-Draft            TLS inner Application                June 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Funk, et al.            Expires December 27, 2006              [Page 37]


