diff options
Diffstat (limited to 'doc/protocol/draft-funk-tls-inner-application-extension-00.txt')
| -rw-r--r-- | doc/protocol/draft-funk-tls-inner-application-extension-00.txt | 1947 |
1 files changed, 0 insertions, 1947 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 deleted file mode 100644 index d9c056db79..0000000000 --- a/doc/protocol/draft-funk-tls-inner-application-extension-00.txt +++ /dev/null @@ -1,1947 +0,0 @@ - - - - - -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] - - - |