Add.

2 files changed, 3832 insertions, 0 deletions

diff --git a/doc/protocol/draft-funk-tls-inner-application-extension-00.txt b/doc/protocol/draft-funk-tls-inner-application-extension-00.txt
new file mode 100644
index 0000000000..d9c056db79
--- /dev/null
+++ b/doc/protocol/draft-funk-tls-inner-application-extension-00.txt
@@ -0,0 +1,1947 @@
+
+
+
+
+
+TLS Working Group                                             Paul Funk 
+Internet-Draft                                      Funk Software, Inc. 
+Category: Standards Track                            Simon Blake-Wilson 
+<draft-funk-tls-inner-application-extension-00.txt>    Basic Commerce &  
+                                                       Industries, Inc. 
+                                                              Ned Smith 
+                                                            Intel Corp. 
+                                                      Hannes Tschofenig 
+                                                             Siemens AG 
+                                                           October 2004 
+
+                                     
+
+                    TLS Inner Application Extension 
+                               (TLS/IA) 
+
+                                     
+
+Status of this Memo 
+
+   This document is an Internet-Draft and is subject to all provisions 
+   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with 
+   RFC 3668. 
+
+   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. 
+
+    
+
+Copyright Notice 
+
+   Copyright (C) The Internet Society (2001 - 2004). All Rights 
+   Reserved. 
+
+Abstract 
+
+Internet-Draft                                            October 2004         
+
+
+   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 during the TLS 
+   handshake, each of which is 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 within the TLS 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 handshake in EAP as a means to mutually 
+   authenticate a client and server and establish keys for a separate 
+   data connection. 
+
+Table of Contents 
+
+1   Introduction......................................................3 
+1.1    A Bit of History..............................................4 
+1.2    Handshake-Only vs. Full TLS Usage.............................5 
+2   The InnerApplication Extension to TLS.............................5 
+2.1    TLS/IA Overview...............................................6 
+2.2    Message Exchange..............................................8 
+2.3    Master Key Permutation........................................8 
+2.3.1      Application Session Key Material.........................10 
+2.4    Session Resumption...........................................11 
+2.5    Error Termination............................................12 
+2.6    Computing Verification Data..................................12 
+2.7    TLS/IA Messages..............................................14 
+2.8    Negotiating the Inner Application Extension..................14 
+2.8.1      ClientInnerApplication...................................14 
+2.8.2      ServerInnerApplication...................................15 
+2.9    The PhaseFinished Handshake Message..........................16 
+2.10   The ApplicationPayload Handshake Message.....................16 
+2.11   The InnerApplicationFailure Alert............................16 
+3   Encapsulation of AVPs within ApplicationPayload Messages.........16 
+3.1    AVP Format...................................................17 
+3.2    AVP Sequences................................................18 
+3.3    Guidelines for Maximum Compatibility with AAA Servers........18 
+4   Tunneled Authentication within Application Phases................19 
+4.1    Implicit challenge...........................................19 
+
+
+
+Paul Funk                 expires April 2005                  [Page 2] 
+
+Internet-Draft                                            October 2004         
+
+
+4.2    Tunneled Authentication Protocols............................20 
+4.2.1      EAP ......................................................20 
+4.2.2      CHAP .....................................................21 
+4.2.3      MS-CHAP..................................................22 
+4.2.4      MS-CHAP-V2...............................................22 
+4.2.5      PAP ......................................................24 
+4.3    Performing Multiple Authentications..........................24 
+5   Example Message Sequences........................................25 
+5.1    Full Initial Handshake with Intermediate and Final Application 
+Phases 25 
+5.2    Resumed Session with Single Application Phase................26 
+5.3    Resumed Session with No Application Phase....................27 
+6   Security Considerations..........................................27 
+7   References.......................................................30 
+7.1    Normative References.........................................30 
+7.2    Informative References.......................................31 
+8   Authors' Addresses...............................................31 
+9   Intellectual Property Statement..................................32 
+    
+
+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 TLS handshake is extended to allow an arbitrary 
+   exchange of information between client and server within a protected 
+   tunnel established during the handshake but prior to its completion. 
+   The initial phase of the TLS handshake is virtually identical to 
+   that of a standard TLS handshake; subsequent phases are conducted 
+   under the confidentiality and integrity protection afforded by that 
+   initial phase. 
+
+   The primary motivation for providing such communication is to allow 
+   robust user authentication to occur as part of the 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, Extensible Authentication Protocol (EAP) may be used to 
+   authenticate using any of a wide variety of methods as part of the 
+   TLS handshake. The multi-phase 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; for example [TLS-PSK]. 
+
+   The protected exchange accommodates any type of client-server 
+   application, not just authentication, though authentication may 
+   often be the prerequisite that allows other applications to proceed. 
+   For example, TLS/IA may be used to set up HTTP connections, 
+
+
+
+Paul Funk                 expires April 2005                  [Page 3] 
+
+Internet-Draft                                            October 2004         
+
+
+   establish IPsec security associations (as an alternative to IKE), 
+   obtain credentials for single sign-on, provide for 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. 
+
+1.1  A Bit of History 
+
+   The TLS protocol has its roots in the Netscape SSL protocol, which 
+   was originally intended to secure HTTP. It provides either one-way 
+   or mutual authentication of client and server based on certificates. 
+   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 the certificate of 
+   each.  
+
+   Subsequent 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, then utilize the tunnel established by the 
+   TLS handshake to perform user authentication, typically based on 
+   password credentials. 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. 
+
+   TLS/IA is in effect a merger of the two types of TLS usage described 
+   above, based on the recognition that tunneled authentication would 
+
+
+
+Paul Funk                 expires April 2005                  [Page 4] 
+
+Internet-Draft                                            October 2004         
+
+
+   be useful in other contexts besides EAP. However, the tunneled 
+   protocols mentioned above are not directly compatible with a more 
+   generic use of TLS, because they utilize the tunneled data portion 
+   of TLS, thus precluding its use for other purposes such as carrying 
+   HTTP traffic. 
+
+   The TLS/IA solution to this problem is to fold the tunneled 
+   authentication into the TLS handshake itself, making the data 
+   portion of the TLS exchange available for HTTP or any other protocol 
+   or connection that needs to be secured. 
+
+1.2  Handshake-Only vs. Full TLS Usage 
+
+   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 
+   within the TLS 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 handshake in EAP as a 
+   means to mutually authenticate a client and server and establish 
+   keys for a separate data connection; no subsequent data portion is 
+   required. Another example might be use of TLS/IA directly over TCP 
+   to provide a user with credentials for single sign-on. 
+
+2  The InnerApplication Extension to TLS 
+
+   The InnerApplication extension to TLS follows the guidelines of RFC 
+   3546. The client proposes use of this extension by including a 
+   ClientInnerApplication message in its ClientHello handshake message, 
+   and the server confirms its use by including a 
+   ServerInnerApplication message in its ServerHello handshake message.  
+
+   Two new handshake messages are defined for use in TLS/IA: 
+
+   -  The PhaseFinished message. This message is similar to the 
+      standard TLS Finished message; it allows the TLS/IA handshake to 
+      operate in phases, with message and key confirmation occurring at 
+      the end of each phase. 
+
+   -  The ApplicationPayload message. This message is used to carry AVP 
+      (Attribute-Value Pair) sequences within the TLS/IA handshake, in 
+      support of client-server applications such as authentication. 
+
+   A new alert code is also defined for use in TLS/IA: 
+
+   -  The InnerApplicationFailure alert. This error alert allows either 
+
+
+
+Paul Funk                 expires April 2005                  [Page 5] 
+
+Internet-Draft                                            October 2004         
+
+
+      party to terminate the handshake due to a failure in an 
+      application implemented via AVP sequences carried in 
+      ApplicationPayload messages. 
+
+2.1  TLS/IA Overview 
+
+   In TLS/IA, the handshake is divided into phases. The first phase, 
+   called the "initial phase", is a standard TLS handshake; it is 
+   followed by zero or more "application phases". The last phase is 
+   called the "final phase"; this will be an application phase if a 
+   such a phase is present, otherwise the standard TLS handshake is 
+   both the initial and final phase. Any application phases between the 
+   initial and final phase are called "intermediate phases". 
+
+   A typical handshake consists of an initial phase and a final phase, 
+   with no intermediate phases. Intermediate phases are only necessary 
+   if interim confirmation key material 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. 
+
+   All application phases are encrypted. A new master secret and cipher 
+   spec are negotiated at the conclusion of each phase, to be applied 
+   in the subsequent phase. The master secret and cipher spec 
+   negotiated at the conclusion of the final phase are applied to the 
+   data exchange following the handshake. 
+
+   All phases prior to the final phase use PhaseFinished rather than 
+   Finished as the concluding message. The final phase concludes with 
+   the Finished 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. 
+
+   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, a ChangeCipherSpec and PhaseFinished 
+   sequence to conclude an intermediate phase, or a ChangeCipherSpec 
+   and Finished sequence to conclude the final phase. The client then 
+   responds with its own ChangeCipherSpec and PhaseFinished sequence, 
+   or ChangeCipherSpec and Finished sequence.  
+
+
+
+
+
+Paul Funk                 expires April 2005                  [Page 6] 
+
+Internet-Draft                                            October 2004         
+
+
+   Note that the server MUST NOT send a ChangeCipherSpec plus Finished 
+   or PhaseFinished 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 PhaseFinished or Finished, and the client MUST echo the same 
+   type of concluding message. Each PhaseFinished or Finished message 
+   provides cryptographic confirmation of the integrity of all 
+   handshake messages and keys generated from the start of the 
+   handshake through the current phase. 
+
+   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. 
+
+   The TLS master secret undergoes multiple permutations until a final 
+   master secret is computed at the end of the entire handshake. Each 
+   phase of the handshake results in a new master secret; the master 
+   secret for each phase is confirmed by the PhaseFinished or Finished 
+   message exchange that concludes that phase. 
+
+   The initial master secret is computed during the initial phase of 
+   the handshake, using the standard TLS-defined procedure. This 
+   initial master secret is confirmed via the first exchange of 
+   ChangeCipherSpec and PhaseFinished messages, or, in the case of a 
+   resumed session with no subsequence application phase, the exchange 
+   of ChangeCipherSpec and Finished messages. 
+
+   Each subsequent master secret for an application phase is computed 
+   using a PRF based on the current master secret, then mixing into the 
+   result any session key material generated during authentications 
+   during that phase. Each party computes a new master secret prior to 
+   the conclusion of each application phase, and uses that new master 
+   secret is to compute fresh keying material (that is, a TLS 
+   "key_block", consisting of client and server MAC secrets, write keys 
+   and IVs). The new master secret and keying material become part of 
+   the pending read and write connection states. Following standard TLS 
+   procedures, these connection states become current states upon 
+   sending or receiving ChangeCipherSpec, and are confirmed via the 
+   PhaseFinished or Finished message. 
+
+
+
+Paul Funk                 expires April 2005                  [Page 7] 
+
+Internet-Draft                                            October 2004         
+
+
+   The final master secret, computed during the final handshake phase 
+   and confirmed by an exchange of ChangeCipherSpec and Finished 
+   messages, becomes the actual TLS master secret that defines the 
+   session. This final master secret is the surviving master secret, 
+   and each prior master secrets SHOULD be discarded when a new 
+   connection state is instantiated. The final master secret is used 
+   for session resumption, as well as for any session key derivation 
+   that protocols defined over TLS may require.  
+
+2.2  Message Exchange 
+
+   Each intermediate handshake phase consists of ApplicationPayload 
+   messages sent alternately by client and server, and a concluding 
+   exchange of {ChangeCipherSpec, PhaseFinished} messages. The first 
+   and last ApplicationPayload message in each intermediate phase is 
+   sent by the client; the first {ChangeCipherSpec, PhaseFinished} 
+   message sequence is sent by the server. Thus the client begins the 
+   exchange with an ApplicationPayload message and the server 
+   determines when to conclude it by sending {ChangeCipherSpec, 
+   PhaseFinished}. When it receives the server's {ChangeCipherSpec, 
+   PhaseFinished} messages, the client sends its own {ChangeCipherSpec, 
+   PhaseFinished} messages, followed by an ApplicationPayload message 
+   to begin the next handshake phase.  
+
+   The final handshake proceeds in the same manner as the intermediate 
+   handshake, except that the Finished message is used rather than the 
+   PhaseFinished message, 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 handshake phase, the server MUST 
+   wait for the client's opening ApplicationPayload message before it 
+   sends its own ApplicationPayload message to the client. The client 
+   MAY NOT initiate conclusion of an application handshake phase by 
+   sending the first {ChangeCipherSpec, PhaseFinished} or 
+   {ChangeCipherSpec, Finished message} sequence; it MUST allow the 
+   server to initiate the conclusion of the phase. 
+
+2.3  Master Key Permutation 
+
+   Each permutation of the master secret from one phase to the next 
+   begins with the calculation of a preliminary 48 octet vector 
+   (pre_vector) based on the current master secret: 
+
+      pre_vector = PRF(SecurityParameters.master_secret,  
+                          "inner application preliminary vector",  
+                          SecurityParameters.server_random + 
+                          SecurityParameters.client_random) [0..48]; 
+
+   Session key material generated by applications during the current 
+   application phase are mixed into the preliminary vector by 
+
+
+
+Paul Funk                 expires April 2005                  [Page 8] 
+
+Internet-Draft                                            October 2004         
+
+
+   arithmetically adding each session key to it to compute the new 
+   master secret. The preliminary vector is treated as a 48-octet 
+   integer in big-endian order; that is, the first octet is of the 
+   highest significance. Each session key is also treated as a big-
+   endian integer of whatever size it happens to be. Arithmetic carry 
+   past the most significant octet is discarded; that is, the addition 
+   is performed modulo 2 ^ 384.  
+
+   Thus, the logical procedure for computing the next master secret 
+   (which may also be a convenient implementation procedure) is as 
+   follows: 
+
+   1  At the start of each application handshake phase, use the current 
+      master secret to compute pre_vector for the next master secret. 
+
+   2  Each time session key material is generated from an 
+      authentication or other exchange, arithmetically add that session 
+      key material to pre_vector. 
+
+   3  At the conclusion of the application handshake phase, copy the 
+      current contents of pre_vector (which now includes addition of 
+      all session key material) into the master secret, prior to 
+      computing verify_data. 
+
+   Note that the master secret is the only element of the TLS 
+   SecurityParameters that is permuted from phase to phase. The 
+   client_random, server_random, bulk_cipher_algorithm, mac_algorithm, 
+   etc. remain constant throughout all phases of the handshake. 
+
+   The purpose of using a PRF to compute a preliminary vector is to 
+   ensure that, even in the absence of session keys, the master secret 
+   is cryptographically distinct in each phase of the handshake. 
+
+   The purpose of adding session keys into the preliminary vector is to 
+   ensure that the same client entity that negotiated the original 
+   master secret also negotiated the inner authentication(s). In the 
+   absence of such mixing of keys generated from the standard TLS 
+   handshake with keys generated from inner authentication, it is 
+   possible for a hostile agent to mount a man-in-the-middle attack, 
+   acting as server to an unsuspecting client to induce it to perform 
+   an authentication with it, which it can then pass through the TLS 
+   tunnel to allow it to pose as that client. 
+
+   An application phase may include no authentications that produce a 
+   session key, may include one such authentication, or may include 
+   several. Arithmetic addition was chosen as the mixing method because 
+   it is commutative, that is, it does not depend on the order of 
+   operations. This allows multiple authentications to proceed 
+   concurrently if desired, without having to synchronize the order of 
+   master secret updates between client and server. 
+
+
+
+
+Paul Funk                 expires April 2005                  [Page 9] 
+
+Internet-Draft                                            October 2004         
+
+
+   Addition was chosen rather than XOR in order to avoid what is 
+   probably a highly unlikely problem; namely, that two separate 
+   authentications produce the same session key, which, if XORed, would 
+   mutually cancel. This might occur, for example, if two instances of 
+   an authentication method were to be applied against different forms 
+   of a user identity that turn out in a some cases to devolve to the 
+   same identity. 
+
+   Finally, it was decided that a more complex mixing mechanism for 
+   session key material, such as hashing, besides not being 
+   commutative, would not provide any additional security, due to the 
+   pseudo-random character of the preliminary vector and the powerful 
+   PRF function which is applied to create derivative secrets. 
+
+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 its alter ego EAP-
+   MS-CHAP-V2 each generate session keys. 
+
+   Session keying material generated during an application phase MUST 
+   be used to permute the TLS/IA master secret between one phase and 
+   the next, and MUST NOT be used for any other purpose. Permuting the 
+   master secret based on session keying material is necessary  to 
+   preclude man-in-the-middle attacks, in which an unsuspecting client 
+   is induced to perform an authentication outside a tunnel with an 
+   attacker posing as a server; the attacker can then introduce the 
+   authentication protocol into a tunnel such as provided by TLS/IA, 
+   fooling an authentic server into believing that the attacker is the 
+   authentic user. 
+
+   By mixing keying material generated during application phase 
+   authentication into the master secret, such attacks are thwarted, 
+   since only a single client identity could both authenticate 
+   successfully and have derived the session keying material. Note that 
+   the keying material generated during authentication must be 
+   cryptographically related 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 master secret cryptographically 
+   incorporates keying material from application phase authentications 
+   provides additional protection when the master secret is used as a 
+   basis for generating additional keys for use outside of the TLS 
+   exchange. If the master 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 master 
+   secret and hence would be able to compute the additional keys that 
+   are based on it. When inner authentication keying material is 
+
+
+
+Paul Funk                 expires April 2005                 [Page 10] 
+
+Internet-Draft                                            October 2004         
+
+
+   incorporated into the master secret, such an attack becomes 
+   impossible. 
+
+   The RECOMMENDED amount of keying material to mix into the master 
+   secret is 32 octets. Up to 48 octets MAY be used.  
+
+   Each authentication protocol may define how the keying material it 
+   generates is mapped to an octet sequence of some length for the 
+   purpose of TLS/IA mixing. However, for protocols which do not 
+   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 keying material: 
+
+   -  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), the concatenated 
+      sequence is truncated to 32 octets if longer, and the result is 
+      used as keying material. (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 32 
+      octets for use as keying material. 
+
+2.4  Session Resumption 
+
+   A TLS/IA initial handshake phase may be resumed using standard 
+   mechanisms defined in RFC 2246. When the initial handshake phase 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 all the security needed. 
+
+   The client indicates within the InnerApplication extension whether 
+   it requires AVP exchange when session resumption occurs. If it 
+   indicates that it does not, then the server may at its option omit 
+   subsequent application phases and complete the resumed handshake in 
+   a single phase. 
+
+   Note that RFC 3546 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 RFC 3546 provision is specifically overridden for the single 
+   case of the Inner Application extension, which is considered an 
+   exception to this rule.  
+
+
+
+
+
+
+Paul Funk                 expires April 2005                 [Page 11] 
+
+Internet-Draft                                            October 2004         
+
+
+2.5  Error Termination 
+
+   The TLS/IA handshake may be terminated by either party sending a 
+   fatal alert, following standard TLS procedures.  
+
+2.6  Computing Verification Data 
+
+   In standard TLS, the "verify_data" vector of the Finished message is 
+   computed as follows: 
+
+      PRF(master_secret, finished_label, MD5(handshake_messages) +  
+              SHA-1(handshake_messages)) [0..11]; 
+
+   This allows both parties to confirm the master secret as well as the 
+   integrity of all handshake messages that have been exchanged. 
+
+   In TLS/IA, verify_data for the initial handshake phase is computed 
+   in exactly the same manner. 
+
+   In the subsequent application phases, a slight variation of this 
+   formula is used. The data that is hashed is the hash of the 
+   handshake messages computed in the previous phase plus all handshake 
+   messages that have been exchanged since that previous hash was 
+   computed. Thus, for each application phase, the MD5 hash input to 
+   the PRF is a hash of the MD5 hash computed in the previous phase 
+   concatenated with all subsequent handshake messages through the 
+   current phase; the SHA-1 hash is computed in the same way, but using 
+   the SHA-1 hash computed for the previous phase. 
+
+   Also, the master secret used in the PRF computation in each 
+   application phase is the new master secret generated at the 
+   conclusion of that phase. 
+
+   For clarity, this is best expressed in formal notation. 
+
+   Let phases be numbered from 0, where phase 0 is the initial phase. 
+
+   Let: 
+
+      Secret[n] be the master secret determined at the conclusion of 
+      phase n. 
+
+      Messages[n] be the additional handshake messages exchanged since 
+      the hashes were computed in phase n - 1, where n > 0; or all 
+      handshake messages exchanged to date starting from ClientHello, 
+      where n = 0. 
+
+      MD5[n] be the MD5 hash of handshake message material for phase n. 
+
+      SHA-1[n] be the SHA-1 hash of handshake message material for 
+      phase n. 
+
+
+
+Paul Funk                 expires April 2005                 [Page 12] 
+
+Internet-Draft                                            October 2004         
+
+
+      PRF[n] be the verify_data generated via PRF in phase n. 
+
+   Hash computations for phase 0 are as follows: 
+
+      MD5[0] = MD5(Messages[0]) 
+
+      SHA-1[0] = SHA-1(Messages[0]) 
+
+   Hash computations for phase i, where i > 0 (i.e. application phases) 
+   are as follows: 
+
+      MD5[i] = MD5(MD5[i-1] + Messages[i]) 
+
+      SHA-1[i] = SHA-1(SHA-1[i-1] + Messages[i]) 
+
+   The PRF computation to generate verify_data for any phase i 
+   (including i = 0) is as follows: 
+
+      PRF[i] = PRF(Secret[i], finished_label, MD5[i] + SHA-1[i]) 
+      [0..11] 
+
+   Note that for phase 0, the PRF computation is identical to the 
+   standard TLS computation. Variations to the algorithm occur only in 
+   application phases, in the use of new master secrets and the 
+   inclusion of hashes of previous handshake messages as input to the 
+   hashing algorithms. 
+
+   During an application phase, the handshake messages input to the 
+   hashing algorithm include all handshake messages exchanged since the 
+   last PRF computation was performed. This will always include either 
+   one or two PhaseFinished messages from the previous phase. To see 
+   why, assume that in the previous phase the client issued its 
+   PhaseFinished message first, and the server's PhaseFinished message 
+   in response thus included the client's PhaseFinished message. This 
+   means that the server has not yet fed its PhaseFinished message into 
+   the PRF, and the client has fed neither its own PhaseFinished 
+   message nor the server's PhaseFinished response message into the 
+   PRF. Therefore these messages from the previous phase must be fed 
+   into the PhaseFinished messages along with handshake messages from 
+   the current phase into the PRF that validates the current phase. 
+
+   Note that the only handshake messages that appear in an application 
+   phase are InnerApplication messages and Finished or Phase Finished 
+   messages. ChangeCipherSpec messages are not handshake messages and 
+   are therefore never included in the hash computations. 
+
+   Note also that for TLS/IA, just as for standard TLS, client and 
+   server include a somewhat different set of handshake messages in 
+   hash computations. Therefore, both client and server must compute 
+   two PRFs for each handshake phase: one to include the verify_data 
+
+
+
+
+Paul Funk                 expires April 2005                 [Page 13] 
+
+Internet-Draft                                            October 2004         
+
+
+   that it transmits, and one to use to check the verify_data received 
+   from the other party. 
+
+2.7  TLS/IA Messages 
+
+   All specifications of TLS/IA messages follow the usage defined in 
+   RFC 2246. 
+
+   TLS/IA defines a new TLS extension, two new handshake messages, and 
+   a new alert code. The new types and codes are (decimal): 
+
+   -  "InnerApplication" extension type:    37703 
+
+   -  "PhaseFinished" type:                    78 
+
+   -  "ApplicationPayload" type:               79 
+
+   -  "InnerApplicationFailure" code:         208 
+
+   [Note: I have not checked these types yet against types defined in 
+   RFCs or drafts. pf] 
+
+2.8  Negotiating the Inner Application Extension 
+
+   Use of the InnerApplication extension follows RFC 3546. The client 
+   proposes use of this extension by including the 
+   ClientInnerApplication 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 
+   ServerInnerApplication 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 
+   variations to the TLS handshake described here MUST NOT be used. 
+
+2.8.1 ClientInnerApplication 
+
+   When the client wishes to propose use of the Inner Application 
+   extension, it must include ClientInnerApplication in the 
+   "extension_data" vector in the Extension structure in its extended 
+   ClientHello message, where: 
+
+   enum { 
+       not_required(0), required(1), (255) 
+   } AppPhaseOnResumption; 
+
+   struct { 
+      AppPhaseOnResumption app_phase_on_resumption; 
+   } ClientInnerApplication; 
+
+   The AppPhaseOnResumption enumeration allow client and server to 
+   negotiate an abbreviated, single-phase handshake when session 
+
+
+
+Paul Funk                 expires April 2005                 [Page 14] 
+
+Internet-Draft                                            October 2004         
+
+
+   resumption is employed. If the server is able to resume a previous 
+   session, and if the client sets app_phase_on_resumption to 
+   not_required, then the server MAY conclude the initial handshake 
+   phase with a Finished message, thus completing the handshake in a 
+   single phase. If the client sets app_phase_on_resumption to 
+   required, then the server MUST conclude the initial handshake phase 
+   with PhaseFinished, thus allowing one or more subsequent application 
+   phases to follow the initial handshake phase. 
+
+   The value of app_phase_on_resumption applies to the current 
+   handshake only. For example, 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. 
+
+   Note that the server may initiate one or more application phases 
+   even if the client sets app_phase_on_resumption to not_required, as 
+   the server itself may have reason to proceed with one or more 
+   application phases. 
+
+   Note also that if session resumption does not occur, the 
+   app_phase_on_resumption variable is ignored, the server MUST 
+   conclude the initial phase with a PhaseFinished message and one or 
+   more application phases MUST follow the initial handshake phase. 
+
+2.8.2 ServerInnerApplication 
+
+   When the server wishes to confirm use of the Inner Application 
+   extension that has been proposed by the client, it must include 
+   ServerInnerApplication in the "extension_data" vector in the 
+   Extension structure in its extended ServerHello message, where: 
+
+   struct { 
+   } ServerInnerApplication; 
+
+   Note that the ServerInnerApplication message contains no data; 
+   however, it's presence is required to confirm use of the Inner 
+   Application extension when proposed by the client. 
+
+   If the client set app_phase_on_resumption to not_required and the 
+   server agrees and will not initiate an application phase, the server 
+   MUST NOT include ServerInnerApplication in its ServerHello and it 
+   must conclude the initial (and only) handshake phase with the 
+   Finished message. If, the server includes ServerInnerApplication, it 
+   MUST conclude the initial handshake phase with PhaseFinished, 
+   indicating that one or more application phases will follow the 
+   initial handshake phase. 
+
+
+
+
+
+
+
+
+Paul Funk                 expires April 2005                 [Page 15] 
+
+Internet-Draft                                            October 2004         
+
+
+2.9  The PhaseFinished Handshake Message 
+
+   The PhaseFinished message concludes all handshake phases prior to 
+   the final handshake phase. It MUST be immediately preceded by a 
+   ChangeCipherSpec message. It is defined as follows: 
+
+   struct { 
+      opaque verify_data[12]; 
+   } PhaseFinished; 
+
+2.10 The ApplicationPayload Handshake Message 
+
+   The ApplicationPayload message carries an AVP sequence during an 
+   application handshake phase. It is defined as follows: 
+
+   struct { 
+      opaque avps[Handshake.length]; 
+   } ApplicationPayload; 
+
+   where Handshake.length is the 24-bit length field in the 
+   encapsulating Handshake 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 the having the length of 
+   the AVP sequence specified redundantly both in the encapsulating 
+   Handshake message and as a length prefix in the avps element itself. 
+
+2.11 The InnerApplicationFailure Alert 
+
+   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. 
+
+   The AlertLevel for an InnerApplicationFailure alert MUST be set to 
+   "fatal". 
+
+   Note that other alerts are possible during an application phase; for 
+   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. 
+
+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 then-current 
+   cipher state established during the preceding handshake phase. 
+
+
+
+Paul Funk                 expires April 2005                 [Page 16] 
+
+Internet-Draft                                            October 2004         
+
+
+   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 all 
+   commonly used password authentication protocols, including EAP. 
+
+   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 
+   easily translate between AVPs it uses to communicate with clients 
+   and the protocol requirements of AAA servers that are widely 
+   deployed. Plus, 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 ... 
+   +-+-+-+-+-+-+-+-+ 
+
+   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.  
+
+
+
+
+Paul Funk                 expires April 2005                 [Page 17] 
+
+Internet-Draft                                            October 2004         
+
+
+      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. If this bit is set to 0, this indicates that the AVP 
+      may be safely ignored if the receiving party does not understand 
+      or support it. If set to 1, this indicates that the receiving 
+      party must fail the negotiation if it does not understand the 
+      AVP; for a server, this would imply returning EAP-Failure, for a 
+      client, this would imply abandoning the negotiation. 
+
+      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 
+   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 
+
+
+
+Paul Funk                 expires April 2005                 [Page 18] 
+
+Internet-Draft                                            October 2004         
+
+
+      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. 
+
+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 
+   security of the authentication information against active and 
+   passive attack.  
+
+   Any type of password or other authentication may be tunneled. Also, 
+   multiple tunneled authentications may be performed. Normally, 
+   tunneled authentication is used when the client has not been issued 
+   a certificate and the TLS handshake provides only one-way 
+   authentication of the server to the client; however, in certain 
+   cases it may be desired 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 common 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.  
+
+   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.  
+
+
+
+
+Paul Funk                 expires April 2005                 [Page 19] 
+
+Internet-Draft                                            October 2004         
+
+
+   To make these protocols secure in TLS/IA, it is necessary to provide 
+   a mechanism to produce 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 then-current master secret and 
+   random values established during the initial handshake phase: 
+
+      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 [AAA-EAP]. 
+
+4.2.1 EAP 
+
+   EAP is described in [RFC3784]; RADIUS attribute formats are 
+   described in [RFC3579]. 
+
+
+
+
+
+
+Paul Funk                 expires April 2005                 [Page 20] 
+
+Internet-Draft                                            October 2004         
+
+
+   When EAP is the tunneled authentication protocol, each tunneled EAP 
+   packet between the client and server is encapsulated in an EAP-
+   Message AVP. 
+
+   Either client or 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 actual username; the 
+   privacy of the user's identity is now guaranteed by the TLS 
+   encryption. This username must be a Network 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, 
+
+
+
+Paul Funk                 expires April 2005                 [Page 21] 
+
+Internet-Draft                                            October 2004         
+
+
+   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 
+   exactly, 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]. 
+
+   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 
+
+
+
+Paul Funk                 expires April 2005                 [Page 22] 
+
+Internet-Draft                                            October 2004         
+
+
+   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 
+   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. 
+
+
+
+
+
+
+Paul Funk                 expires April 2005                 [Page 23] 
+
+Internet-Draft                                            October 2004         
+
+
+   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 
+   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 AAA/H may want first to authenticate 
+   the user by password, then by token card. 
+
+   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. 
+
+
+
+Paul Funk                 expires April 2005                 [Page 24] 
+
+Internet-Draft                                            October 2004         
+
+
+5  Example Message Sequences 
+
+   This section presents a variety of possible TLS/IA message 
+   sequences. These examples do not attempt to exhaustively depict all 
+   possible scenarios.  
+
+   Parentheses indicate optional TLS messages. Brackets indicate 
+   optional message exchanges. Ellipsis (. . .) indicates optional 
+   repetition of preceding messages. 
+
+5.1  Full Initial Handshake with Intermediate and Final Application 
+Phases 
+
+   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.  
+
+         Client                                               Server 
+         ------                                               ------ 
+    
+   *** Initial Phase:  
+         ClientHello                  --------> 
+                                                         ServerHello 
+                                                       (Certificate) 
+                                                   ServerKeyExchange 
+                                                (CertificateRequest) 
+                                      <--------      ServerHelloDone 
+         (Certificate) 
+         ClientKeyExchange 
+         (CertificateVerify) 
+         ChangeCipherSpec 
+         PhaseFinished                --------> 
+                                                    ChangeCipherSpec 
+                                      <--------        PhaseFinished 
+    
+   *** Intermediate Phase: 
+         ApplicationPayload           -------->  
+    
+       [ 
+                                      <--------   ApplicationPayload  
+    
+         ApplicationPayload           -------->  
+    
+                                         ... 
+       ] 
+                                                    ChangeCipherSpec 
+                                      <--------        PhaseFinished 
+
+
+
+Paul Funk                 expires April 2005                 [Page 25] 
+
+Internet-Draft                                            October 2004         
+
+
+         ChangeCipherSpec 
+         PhaseFinished 
+   *** Final Phase: 
+         ApplicationPayload           -------->  
+                                          
+       [ 
+                                      <--------   ApplicationPayload  
+    
+         ApplicationPayload           -------->  
+    
+                                         ... 
+       ] 
+                                      <--------     ChangeCipherSpec 
+                                                            Finished 
+         ChangeCipherSpec 
+         Finished                     --------> 
+    
+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 
+         ------                                               ------ 
+    
+   *** Initial Phase:  
+         ClientHello                  --------> 
+                                                         ServerHello 
+                                                    ChangeCipherSpec 
+                                      <--------        PhaseFinished 
+         ChangeCipherSpec 
+         PhaseFinished 
+   *** Final Phase: 
+         ApplicationPayload           -------->  
+                                          
+       [ 
+                                      <--------   ApplicationPayload  
+    
+         ApplicationPayload           -------->  
+    
+                                         ... 
+       ] 
+                                      <--------     ChangeCipherSpec 
+                                                            Finished 
+         ChangeCipherSpec 
+         Finished                     --------> 
+
+
+
+Paul Funk                 expires April 2005                 [Page 26] 
+
+Internet-Draft                                            October 2004         
+
+
+    
+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. 
+
+         Client                                               Server 
+         ------                                               ------ 
+    
+   *** Initial/Final Phase:  
+         ClientHello                  --------> 
+                                                         ServerHello 
+                                                    ChangeCipherSpec 
+                                      <--------             Finished 
+         ChangeCipherSpec 
+         Finished 
+    
+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 many 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 
+   vulnerability to man-in-the-middle attacks if the two sessions 
+   cannot be bound to each other as shown in [MITM].  
+
+   Subsequently, 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 
+
+
+
+Paul Funk                 expires April 2005                 [Page 27] 
+
+Internet-Draft                                            October 2004         
+
+
+     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 [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 [IKEv2]). 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).  
+
+   - 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 and 2.6).  
+
+   - 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 
+
+
+
+Paul Funk                 expires April 2005                 [Page 28] 
+
+Internet-Draft                                            October 2004         
+
+
+     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 [AAA-EAP].  
+
+   - 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.8. To avoid downgrading attacks whereby an adversary 
+
+
+
+
+Paul Funk                 expires April 2005                 [Page 29] 
+
+Internet-Draft                                            October 2004         
+
+
+     removes a capability from the list is avoided by the usage of the 
+     Finish or PhaseFinished message as described in Section 2.6. 
+
+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", RFC 2119, March 1997. 
+
+   [RFC2246]  Dierks, T., and C. Allen, "The TLS Protocol Version 
+               1.0", RFC 2246, November 1998. 
+
+   [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, July 2003. 
+
+   [RFC3784]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 
+               H. Levkowetz, "PPP Extensible Authentication Protocol 
+               (EAP)", RFC 3784, June 2004. 
+
+
+
+
+Paul Funk                 expires April 2005                 [Page 30] 
+
+Internet-Draft                                            October 2004         
+
+
+ 
+7.2  Informative References 
+
+   [RFC1661]  Simpson, W. (Editor), "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. 
+
+   [EAP-TTLS] Funk, P., and S. Blake-Wilson, " EAP Tunneled TLS 
+               Authentication Protocol (EAP-TTLS)", draft-ietf-pppext-
+               eap-ttls-05.txt, July 2004. 
+
+   [EAP-PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., 
+               and S. Josefsson, "Protected EAP Protocol (PEAP) Version 
+               2", draft-josefsson-pppext-eap-tls-eap-08.txt, July 
+               2004. 
+
+   [TLS-PSK]  Eronen, P., and H. Tschofenig, "Pre-Shared Key 
+               Ciphersuites for Transport Layer Security (TLS)", draft-
+               ietf-tls-psk-01.txt, August 2004. 
+
+   [802.1X]   IEEE Standards for Local and Metropolitan Area Networks:  
+               Port based Network Access Control, IEEE Std 802.1X-2001, 
+               June 2001. 
+
+   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 
+               in Tunneled Authentication", 
+               http://www.saunalahti.fi/~asokan/research/mitm.html, 
+               Nokia Research Center, Finland, October 24 2002. 
+
+   [KEYING]   Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP 
+               Key Management Framework", draft-ietf-eap-keying-01.txt 
+               (work in progress), October 2003. 
+
+   [IKEv2]    C.Kaufman, "Internet Key Exchange (IKEv2) Protocol", 
+               draft-ietf-ipsec-ikev2-16.txt (work in progress), 
+               September 2004. 
+
+   [AAA-EAP]  Eronen, P., Hiller, T. and G. Zorn, "Diameter Exntesible 
+               Authentication Protocol (EAP) Application", draft-ietf-
+               aaa-eap-03.txt (work in progress), October 2003. 
+
+8  Authors' Addresses 
+
+   Questions about this memo can be directed to: 
+
+      Paul Funk 
+      Funk Software, Inc. 
+      222 Third Street 
+      Cambridge, MA 02142 
+
+
+
+Paul Funk                 expires April 2005                 [Page 31] 
+
+Internet-Draft                                            October 2004         
+
+
+      USA 
+      Phone: +1 617 497-6339 
+      E-mail: 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 
+      E-mail: sblakewilson@bcisse.com 
+
+      Ned Smith 
+      Intel Corporation 
+      MS: JF1-229 
+      2111 N.E. 25th Ave. 
+      Hillsboro, OR 97124 
+      Phone: +1 503 264-2692  
+      E-mail: ned.smith@intel.com 
+
+      Hannes Tschofenig 
+      Siemens 
+      Otto-Hahn-Ring 6 
+      Munich, Bayern  81739\ 
+      Germany 
+      Phone: +49 89 636 40390 
+      E-mail: Hannes.Tschofenig@siemens.com 
+
+9  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. 
+
+
+
+Paul Funk                 expires April 2005                 [Page 32] 
+
+Internet-Draft                                            October 2004         
+
+
+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 (2001 - 2004).  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. 
+
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Paul Funk                 expires April 2005                 [Page 33] 
+
+
+
diff --git a/doc/protocol/draft-funk-tls-inner-application-extension-01.txt b/doc/protocol/draft-funk-tls-inner-application-extension-01.txt
new file mode 100644
index 0000000000..39404fc40c
--- /dev/null
+++ b/doc/protocol/draft-funk-tls-inner-application-extension-01.txt
@@ -0,0 +1,1885 @@
+
+
+
+
+TLS Working Group                                             Paul Funk 
+Internet-Draft                                      Funk Software, Inc. 
+Category: Standards Track                            Simon Blake-Wilson 
+<draft-funk-tls-inner-application-extension-01.txt>    Basic Commerce &  
+                                                       Industries, Inc. 
+                                                              Ned Smith 
+                                                            Intel Corp. 
+                                                      Hannes Tschofenig 
+                                                             Siemens AG 
+                                                        Thomas Hardjono 
+                                                          VeriSign Inc. 
+                                                          February 2005 
+
+                                     
+
+                    TLS Inner Application Extension 
+                               (TLS/IA) 
+
+                                     
+
+Status of this Memo 
+
+   This document is an Internet-Draft and is subject to all provisions 
+   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with 
+   RFC 3668. 
+
+   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. 
+
+Copyright Notice 
+
+   Copyright (C) The Internet Society (2001 - 2005). All Rights 
+   Reserved. 
+
+Abstract 
+
+Internet-Draft                                           February 2005         
+
+
+   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. 
+
+Table of Contents 
+
+1    Introduction...................................................  3 
+1.1    A Bit of History .......................................... .. 4 
+1.2    TLS With or Without Upper Layer Data Communications..........  5 
+2    The Inner Application Extension to TLS.........................  5 
+2.1    TLS/IA Overview..............................................  7 
+2.2    Message Exchange ............................................  8 
+2.3    Inner Secret.................................................  9 
+2.3.1    Computing the Inner Secret.................................  9 
+2.3.2    Exporting the Final Inner Secret........................... 10 
+2.3.3    Application Session Key Material........................... 10 
+2.4    Session Resumption........................................... 12 
+2.5    Error Termination............................................ 12 
+2.6    Negotiating the Inner Application Extension.................. 12 
+2.7    InnerApplication Protocol.................................... 13 
+2.7.1    InnerApplicationExtension.................................. 13 
+2.7.2    InnerApplication Message................................... 14 
+2.7.3    IntermediatePhaseFinished and FinalPhaseFinished Messages.. 14 
+2.7.4    The ApplicationPayload Message ............................ 15 
+2.8    Alerts....................................................... 15 
+3    Encapsulation of AVPs within ApplicationPayload Messages....... 16 
+3.1    AVP Format................................................... 16 
+3.2    AVP Sequences................................................ 17 
+3.3    Guidelines for Maximum Compatibility with AAA Servers........ 18 
+
+
+
+Paul Funk                 expires August 2005                  [Page 2] 
+
+Internet-Draft                                           February 2005         
+
+
+4    Tunneled Authentication within Application Phases ............. 18 
+4.1    Implicit challenge........................................... 18 
+4.2    Tunneled Authentication Protocols............................ 19 
+4.2.1    EAP........................................................ 20 
+4.2.2    CHAP....................................................... 20 
+4.2.3    MS-CHAP.................................................... 21 
+4.2.4    MS-CHAP-V2................................................. 21 
+4.2.5    PAP........................................................ 23 
+4.3    Performing Multiple Authentications.......................... 23 
+5    Example Message Sequences...................................... 24 
+5.1    Full Initial Handshake with Multiple Application Phases ..... 24 
+5.2    Resumed Session with Single Application Phase................ 25 
+5.3    Resumed Session with No Application Phase.................... 26 
+6    Security Considerations........................................ 26 
+7    References .................................................... 29 
+7.1    Normative References......................................... 29 
+7.2    Informative References....................................... 30 
+8     Authors' Addresses ........................................... 30 
+9     Intellectual Property Statement............................... 31 
+    
+
+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 
+   afforded by the TLS handshake. 
+
+   The primary motivation for providing such communication 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, Extensible Authentication Protocol (EAP) 
+   may be used to authenticate 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 protect a password-based 
+   authentication, distinguishes it from other TLS variants that rely 
+   entirely on a pre-shared key or password for security; for example 
+   [TLS-PSK]. 
+
+   The protected exchange accommodates any type of client-server 
+   application, not just authentication, though authentication may 
+
+
+
+Paul Funk                 expires August 2005                  [Page 3] 
+
+Internet-Draft                                           February 2005         
+
+
+   often be the prerequisite that allows 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 for 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 
+   assurances are required prior to 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 secure HTTP. It provides either one-way 
+   or mutual authentication of client and server based on certificates. 
+   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 the certificate of 
+   each.  
+
+   Subsequent protocols, such EAP-TTLSv0 and EAP-PEAP, utilize the TLS 
+   handshake to allow the client to authenticate the server based on 
+
+
+
+Paul Funk                 expires August 2005                  [Page 4] 
+
+Internet-Draft                                           February 2005         
+
+
+   the latter's certificate, then utilize the tunnel established by the 
+   TLS handshake to perform user authentication, typically based on 
+   password credentials. 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. 
+
+   TLS/IA is in effect a merger of the two types of TLS usage described 
+   above, based on the recognition that tunneled authentication would 
+   be useful in other contexts besides EAP. However, the tunneled 
+   protocols mentioned above are not directly compatible with a more 
+   generic use of TLS, because they utilize the tunneled data portion 
+   of TLS, thus precluding its use for other purposes such as carrying 
+   HTTP traffic. 
+
+   The TLS/IA solution to this problem is to insert an additional 
+   message exchange between the TLS handshake and the subsequent data 
+   communications phase, carried in a new record type distinct from the 
+   record type that carries upper layer data. Thus, the data portion of 
+   the TLS exchange becomes available for HTTP or any other protocol or 
+   connection 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 secure an HTTP data 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 use of TLS/IA 
+   directly over TCP to provide a user with credentials for single 
+   sign-on. 
+
+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 
+
+
+
+Paul Funk                 expires August 2005                  [Page 5] 
+
+Internet-Draft                                           February 2005         
+
+
+      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 implement the inner application extension. These 
+      messages will occur 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 
+      three 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. 
+
+   -  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 
+
+
+
+
+Paul Funk                 expires August 2005                  [Page 6] 
+
+Internet-Draft                                           February 2005         
+
+
+   [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 
+   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. 
+
+
+
+
+
+Paul Funk                 expires August 2005                  [Page 7] 
+
+Internet-Draft                                           February 2005         
+
+
+   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 
+   mixes 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 and 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 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 MAY NOT 
+   initiate conclusion of an application handshake phase by sending the 
+
+
+
+Paul Funk                 expires August 2005                  [Page 8] 
+
+Internet-Draft                                           February 2005         
+
+
+   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 at the conclusion of the TLS 
+   handshake and permuted at the conclusion of each application phase.  
+
+   The inner secret that results from the final application phase is 
+   the final inner secret. 
+
+   When a new (non-resumed) session is negotiated, the resulting final 
+   inner secret is saved as part of the session state for use in 
+   session resumption. 
+
+2.3.1 Computing the Inner Secret 
+
+   At the conclusion of the TLS handshake, each party initializes the 
+   inner secret to: 
+
+   -  the master secret, if this is a new session 
+
+   -  the previously computed final inner secret of the original 
+      session, if this is a resumed session 
+
+   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: 
+
+
+
+
+Paul Funk                 expires August 2005                  [Page 9] 
+
+Internet-Draft                                           February 2005         
+
+
+      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. 
+
+2.3.2 Exporting the Final Inner Secret 
+
+   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 as a session 
+   key. Instead, additional keys should be derived from the inner 
+   secret, for example by using a PRF, and the client and server 
+   randoms should be incorporated into the derivation. This ensures 
+   cryptographic separation between use of the inner secret for session 
+   key confirmation and additional use of the inner secret outside 
+   TLS/IA. 
+
+   Note that for a resumed session that does not include an application 
+   phase, the final inner secret of that session is identical to that 
+   of the original session; hence, incorporation of randoms becomes 
+   critically important to ensure the cryptographic separation of the 
+   keys derived from sessions sharing a common original session. 
+
+2.3.3 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 its alter ego EAP-
+   MS-CHAP-V2 each generate session keys. 
+
+
+
+
+Paul Funk                 expires August 2005                 [Page 10] 
+
+Internet-Draft                                           February 2005         
+
+
+   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 
+   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 both terminated the TLS handshake 
+   and performed the application phase authentication. Note that the 
+   session keys generated during authentication must be 
+   cryptographically related 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 
+
+
+
+Paul Funk                 expires August 2005                 [Page 11] 
+
+Internet-Draft                                           February 2005         
+
+
+   exported secret and hence would be able to compute the additional 
+   keys that are based on it. When inner authentication keying material 
+   is incorporated into the exported secret, such an attack becomes 
+   impossible. 
+
+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 all the security needed. 
+
+   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 specifically 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 succeed. 
+
+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 
+   InnerApplicationExtension message in the server_hello_extension_list 
+
+
+
+Paul Funk                 expires August 2005                 [Page 12] 
+
+Internet-Draft                                           February 2005         
+
+
+   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 
+   session, then the client MUST initiate an application phase at the 
+   conclusion of the TLS handshake. 
+
+
+
+
+
+Paul Funk                 expires August 2005                 [Page 13] 
+
+Internet-Draft                                           February 2005         
+
+
+   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" 
+
+   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. 
+
+
+
+
+
+Paul Funk                 expires August 2005                 [Page 14] 
+
+Internet-Draft                                           February 2005         
+
+
+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, that 
+      is, contains verification data that does not match what is 
+      expected. 
+
+   Note that other alerts are possible during an application phase; for 
+   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. 
+
+
+
+
+
+Paul Funk                 expires August 2005                 [Page 15] 
+
+Internet-Draft                                           February 2005         
+
+
+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 then-current 
+   cipher state established during the preceding handshake phase. 
+
+   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 all 
+   commonly used password authentication protocols, including EAP. 
+
+   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 
+   easily translate between AVPs it uses to communicate with clients 
+   and the protocol requirements of AAA servers that are widely 
+   deployed. Plus, 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 ... 
+   +-+-+-+-+-+-+-+-+ 
+
+   AVP Code 
+
+      The AVP Code is four octets and, combined with the Vendor-ID 
+      field if present, identifies the attribute uniquely. The first 
+
+
+
+
+Paul Funk                 expires August 2005                 [Page 16] 
+
+Internet-Draft                                           February 2005         
+
+
+      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 
+   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. 
+
+
+
+
+
+Paul Funk                 expires August 2005                 [Page 17] 
+
+Internet-Draft                                           February 2005         
+
+
+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. 
+
+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 
+   security of the authentication information against active and 
+   passive attack.  
+
+   Any type of password or other authentication may be tunneled. Also, 
+   multiple tunneled authentications may be performed. Normally, 
+   tunneled authentication is used when the client has not been issued 
+   a certificate and the TLS handshake provides only one-way 
+   authentication of the server to the client; however, in certain 
+   cases it may be desired 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 common 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 
+
+
+
+Paul Funk                 expires August 2005                 [Page 18] 
+
+Internet-Draft                                           February 2005         
+
+
+   generate the challenge, such protocols are susceptible to replay 
+   attack.  
+
+   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 to produce 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 then-current master secret and 
+   random values established during the initial handshake phase: 
+
+      IA_challenge = PRF(final_inner_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 [AAA-EAP]. 
+
+
+
+Paul Funk                 expires August 2005                 [Page 19] 
+
+Internet-Draft                                           February 2005         
+
+
+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 client or 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 actual username; the 
+   privacy of the user's identity is now guaranteed by the TLS 
+   encryption. This username must be a Network 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] 
+
+
+
+Paul Funk                 expires August 2005                 [Page 20] 
+
+Internet-Draft                                           February 2005         
+
+
+   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 
+   exactly, 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]. 
+
+   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: 
+
+
+
+
+
+Paul Funk                 expires August 2005                 [Page 21] 
+
+Internet-Draft                                           February 2005         
+
+
+      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 
+   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 
+
+
+
+Paul Funk                 expires August 2005                 [Page 22] 
+
+Internet-Draft                                           February 2005         
+
+
+   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 
+   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 token card. 
+
+   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 
+
+
+
+Paul Funk                 expires August 2005                 [Page 23] 
+
+Internet-Draft                                           February 2005         
+
+
+   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. 
+
+5  Example Message Sequences 
+
+   This section presents a variety of possible TLS/IA message 
+   sequences. These examples do not attempt to exhaustively depict all 
+   possible scenarios.  
+
+   Parentheses indicate optional TLS messages. Brackets indicate 
+   optional message exchanges. Ellipsis (. . .) indicates optional 
+   repetition of preceding messages. 
+
+5.1  Full Initial Handshake with Multiple Application Phases 
+
+   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.  
+
+         Client                                               Server 
+         ------                                               ------ 
+    
+   *** TLS Handshake:  
+         ClientHello                  --------> 
+                                                         ServerHello 
+                                                       (Certificate) 
+                                                   ServerKeyExchange 
+                                                (CertificateRequest) 
+                                      <--------      ServerHelloDone 
+         (Certificate) 
+         ClientKeyExchange 
+         (CertificateVerify) 
+         ChangeCipherSpec 
+         Finished                     --------> 
+                                                    ChangeCipherSpec 
+                                      <--------        Finished 
+    
+   *** Intermediate Phase: 
+         ApplicationPayload           -------->  
+    
+       [ 
+                                      <--------   ApplicationPayload  
+    
+         ApplicationPayload           -------->  
+    
+
+
+
+
+Paul Funk                 expires August 2005                 [Page 24] 
+
+Internet-Draft                                           February 2005         
+
+
+                                         ... 
+       ] 
+                                      <--------        
+   IntermediatePhaseFinished 
+         IntermediatePhaseFinished 
+   *** Final Phase: 
+         ApplicationPayload           -------->  
+                                          
+       [ 
+                                      <--------   ApplicationPayload  
+    
+         ApplicationPayload           -------->  
+    
+                                         ... 
+       ] 
+                                      <--------   FinalPhaseFinished 
+    
+         FinalPhaseFinished           --------> 
+    
+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 
+                      
+
+
+
+Paul Funk                 expires August 2005                 [Page 25] 
+
+Internet-Draft                                           February 2005         
+
+
+         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. 
+
+         Client                                               Server 
+         ------                                               ------ 
+    
+   *** TLS Handshake:  
+         ClientHello                  --------> 
+                                                         ServerHello 
+                                                    ChangeCipherSpec 
+                                      <--------             Finished 
+         ChangeCipherSpec 
+         Finished                     --------> 
+    
+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 many 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 
+   vulnerability to man-in-the-middle attacks if the two sessions 
+   cannot be bound to each other as shown in [MITM].  
+
+   Subsequently, 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 
+
+
+
+Paul Funk                 expires August 2005                 [Page 26] 
+
+Internet-Draft                                           February 2005         
+
+
+     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 [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 [IKEv2]). 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).  
+
+   - 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 and Error! Reference source not found.).  
+
+   - 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 
+
+
+
+Paul Funk                 expires August 2005                 [Page 27] 
+
+Internet-Draft                                           February 2005         
+
+
+     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 [AAA-EAP].  
+
+   - 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 
+
+
+
+Paul Funk                 expires August 2005                 [Page 28] 
+
+Internet-Draft                                           February 2005         
+
+
+     removes a capability from the list is avoided by the usage of the 
+     Finish or PhaseFinished message as described in Section Error! 
+     Reference source not found.. 
+
+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", RFC 2119, March 1997. 
+
+   [RFC2246]  Dierks, T., and C. Allen, "The TLS Protocol Version 
+               1.0", RFC 2246, November 1998. 
+
+   [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, July 2003. 
+
+   [RFC3784]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 
+               H. Levkowetz, "PPP Extensible Authentication Protocol 
+               (EAP)", RFC 3784, June 2004. 
+
+
+
+Paul Funk                 expires August 2005                 [Page 29] 
+
+Internet-Draft                                           February 2005         
+
+
+ 
+7.2  Informative References 
+
+   [RFC1661]  Simpson, W. (Editor), "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. 
+
+   [EAP-TTLS] Funk, P., and S. Blake-Wilson, " EAP Tunneled TLS 
+               Authentication Protocol (EAP-TTLS)", draft-ietf-pppext-
+               eap-ttls-05.txt, July 2004. 
+
+   [EAP-PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., 
+               and S. Josefsson, "Protected EAP Protocol (PEAP) Version 
+               2", draft-josefsson-pppext-eap-tls-eap-08.txt, July 
+               2004. 
+
+   [TLS-PSK]  Eronen, P., and H. Tschofenig, "Pre-Shared Key 
+               Ciphersuites for Transport Layer Security (TLS)", draft-
+               ietf-tls-psk-01.txt, August 2004. 
+
+   [802.1X]   IEEE Standards for Local and Metropolitan Area Networks:  
+               Port based Network Access Control, IEEE Std 802.1X-2001, 
+               June 2001. 
+
+   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 
+               in Tunneled Authentication", 
+               http://www.saunalahti.fi/~asokan/research/mitm.html, 
+               Nokia Research Center, Finland, October 24 2002. 
+
+   [KEYING]   Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP 
+               Key Management Framework", draft-ietf-eap-keying-01.txt 
+               (work in progress), October 2003. 
+
+   [IKEv2]    C.Kaufman, "Internet Key Exchange (IKEv2) Protocol", 
+               draft-ietf-ipsec-ikev2-16.txt (work in progress), 
+               September 2004. 
+
+   [AAA-EAP]  Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 
+               Authentication Protocol (EAP) Application", draft-ietf-
+               aaa-eap-03.txt (work in progress), October 2003. 
+
+8  Authors' Addresses 
+
+   Questions about this memo can be directed to: 
+
+      Paul Funk 
+      Funk Software, Inc. 
+      222 Third Street 
+      Cambridge, MA 02142 
+
+
+
+Paul Funk                 expires August 2005                 [Page 30] 
+
+Internet-Draft                                           February 2005         
+
+
+      USA 
+      Phone: +1 617 497-6339 
+      E-mail: 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 
+      E-mail: sblakewilson@bcisse.com 
+
+      Ned Smith 
+      Intel Corporation 
+      MS: JF1-229 
+      2111 N.E. 25th Ave. 
+      Hillsboro, OR 97124 
+      USA 
+      Phone: +1 503 264-2692  
+      E-mail: ned.smith@intel.com 
+
+      Hannes Tschofenig 
+      Siemens 
+      Otto-Hahn-Ring 6 
+      Munich, Bayern  81739\ 
+      Germany 
+      Phone: +49 89 636 40390 
+      E-mail: Hannes.Tschofenig@siemens.com 
+
+      Thomas Hardjono 
+      VeriSign Inc. 
+      487 East Middlefield Road 
+      M/S MV6-2-1 
+      Mountain View, CA 94043 
+      USA 
+      Phone: +1 650 426-3204 
+      E-mail: thardjono@verisign.com 
+
+9  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 
+
+
+
+Paul Funk                 expires August 2005                 [Page 31] 
+
+Internet-Draft                                           February 2005         
+
+
+   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 (2001 - 2005).  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. 
+
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Paul Funk                 expires August 2005                 [Page 32] 
+