| blob | d9c056db79215962de9a9fc26956bf2f1fe2859f |
6 TLS Working Group Paul Funk
7 Internet-Draft Funk Software, Inc.
8 Category: Standards Track Simon Blake-Wilson
9 <draft-funk-tls-inner-application-extension-00.txt> Basic Commerce &
10 Industries, Inc.
11 Ned Smith
12 Intel Corp.
13 Hannes Tschofenig
14 Siemens AG
15 October 2004
19 TLS Inner Application Extension
20 (TLS/IA)
24 Status of this Memo
26 This document is an Internet-Draft and is subject to all provisions
27 of section 3 of RFC 3667. By submitting this Internet-Draft, each
28 author represents that any applicable patent or other IPR claims of
29 which he or she is aware have been or will be disclosed, and any of
30 which he or she become aware will be disclosed, in accordance with
31 RFC 3668.
33 Internet-Drafts are working documents of the Internet Engineering
34 Task Force (IETF), its areas, and its working groups. Note that
35 other groups may also distribute working documents as Internet-
36 Drafts.
38 Internet-Drafts are draft documents valid for a maximum of six
39 months and may be updated, replaced, or obsoleted by other documents
40 at any time. It is inappropriate to use Internet-Drafts as
41 reference material or to cite them other than as "work in progress."
43 The list of current Internet-Drafts can be accessed at
44 http://www.ietf.org/ietf/1id-abstracts.txt.
46 The list of Internet-Draft Shadow Directories can be accessed at
47 http://www.ietf.org/shadow.html.
51 Copyright Notice
53 Copyright (C) The Internet Society (2001 - 2004). All Rights
54 Reserved.
56 Abstract
57 \f
58 Internet-Draft October 2004
61 This document defines a new TLS extension called "Inner
62 Application". When TLS is used with the Inner Application extension
63 (TLS/IA), additional messages are exchanged during the TLS
64 handshake, each of which is an encrypted sequence of Attribute-
65 Value-Pairs (AVPs) from the RADIUS/Diameter namespace. Hence, the
66 AVPs defined in RADIUS and Diameter have the same meaning in TLS/AI;
67 that is, each attribute code point refers to the same logical
68 attribute in any of these protocols. Arbitrary "applications" may be
69 implemented using the AVP exchange. Possible applications include
70 EAP or other forms of user authentication, client integrity
71 checking, provisioning of additional tunnels, and the like. Use of
72 the RADIUS/Diameter namespace provides natural compatibility between
73 TLS/IA applications and widely deployed AAA infrastructures.
75 It is anticipated that TLS/IA will be used with and without
76 subsequent protected data communication within the tunnel
77 established by the handshake. For example, TLS/IA may be used to
78 secure an HTTP data connection, allowing more robust password-based
79 user authentication to occur within the TLS handshake than would
80 otherwise be possible using mechanisms available in HTTP. TLS/IA may
81 also be used for its handshake portion alone; for example, EAP-
82 TTLSv1 encapsulates a TLS/IA handshake in EAP as a means to mutually
83 authenticate a client and server and establish keys for a separate
84 data connection.
86 Table of Contents
88 1 Introduction......................................................3
89 1.1 A Bit of History..............................................4
90 1.2 Handshake-Only vs. Full TLS Usage.............................5
91 2 The InnerApplication Extension to TLS.............................5
92 2.1 TLS/IA Overview...............................................6
93 2.2 Message Exchange..............................................8
94 2.3 Master Key Permutation........................................8
95 2.3.1 Application Session Key Material.........................10
96 2.4 Session Resumption...........................................11
97 2.5 Error Termination............................................12
98 2.6 Computing Verification Data..................................12
99 2.7 TLS/IA Messages..............................................14
100 2.8 Negotiating the Inner Application Extension..................14
101 2.8.1 ClientInnerApplication...................................14
102 2.8.2 ServerInnerApplication...................................15
103 2.9 The PhaseFinished Handshake Message..........................16
104 2.10 The ApplicationPayload Handshake Message.....................16
105 2.11 The InnerApplicationFailure Alert............................16
106 3 Encapsulation of AVPs within ApplicationPayload Messages.........16
107 3.1 AVP Format...................................................17
108 3.2 AVP Sequences................................................18
109 3.3 Guidelines for Maximum Compatibility with AAA Servers........18
110 4 Tunneled Authentication within Application Phases................19
111 4.1 Implicit challenge...........................................19
115 Paul Funk expires April 2005 [Page 2]
116 \f
117 Internet-Draft October 2004
120 4.2 Tunneled Authentication Protocols............................20
121 4.2.1 EAP ......................................................20
122 4.2.2 CHAP .....................................................21
123 4.2.3 MS-CHAP..................................................22
124 4.2.4 MS-CHAP-V2...............................................22
125 4.2.5 PAP ......................................................24
126 4.3 Performing Multiple Authentications..........................24
127 5 Example Message Sequences........................................25
128 5.1 Full Initial Handshake with Intermediate and Final Application
129 Phases 25
130 5.2 Resumed Session with Single Application Phase................26
131 5.3 Resumed Session with No Application Phase....................27
132 6 Security Considerations..........................................27
133 7 References.......................................................30
134 7.1 Normative References.........................................30
135 7.2 Informative References.......................................31
136 8 Authors' Addresses...............................................31
137 9 Intellectual Property Statement..................................32
140 1 Introduction
142 This specification defines the TLS "Inner Application" extension.
143 The term "TLS/IA" refers to the TLS protocol when used with the
144 Inner Application extension.
146 In TLS/IA, the TLS handshake is extended to allow an arbitrary
147 exchange of information between client and server within a protected
148 tunnel established during the handshake but prior to its completion.
149 The initial phase of the TLS handshake is virtually identical to
150 that of a standard TLS handshake; subsequent phases are conducted
151 under the confidentiality and integrity protection afforded by that
152 initial phase.
154 The primary motivation for providing such communication is to allow
155 robust user authentication to occur as part of the handshake, in
156 particular, user authentication that is based on password
157 credentials, which is best conducted under the protection of an
158 encrypted tunnel to preclude dictionary attack by eavesdroppers. For
159 example, Extensible Authentication Protocol (EAP) may be used to
160 authenticate using any of a wide variety of methods as part of the
161 TLS handshake. The multi-phase approach of TLS/IA, in which a strong
162 authentication, typically based on a server certificate, is used to
163 protected a password-based authentication, distinguishes it from
164 other TLS variants that rely entirely on a pre-shared key or
165 password for security; for example [TLS-PSK].
167 The protected exchange accommodates any type of client-server
168 application, not just authentication, though authentication may
169 often be the prerequisite that allows other applications to proceed.
170 For example, TLS/IA may be used to set up HTTP connections,
174 Paul Funk expires April 2005 [Page 3]
175 \f
176 Internet-Draft October 2004
179 establish IPsec security associations (as an alternative to IKE),
180 obtain credentials for single sign-on, provide for client integrity
181 verification, and so on.
183 The new messages that are exchanged between client and server are
184 encoded as sequences of Attribute-Value-Pairs (AVPs) from the
185 RADIUS/Diameter namespace. Use of the RADIUS/Diameter namespace
186 provides natural compatibility between TLS/IA applications and
187 widely deployed AAA infrastructures. This namespace is extensible,
188 allowing new AVPs and, thus, new applications to be defined as
189 needed, either by standards bodies or by vendors wishing to define
190 proprietary applications.
192 1.1 A Bit of History
194 The TLS protocol has its roots in the Netscape SSL protocol, which
195 was originally intended to secure HTTP. It provides either one-way
196 or mutual authentication of client and server based on certificates.
197 In its most typical use in HTTP, the client authenticates the server
198 based on the server's certificate and establishes a tunnel through
199 which HTTP traffic is passed.
201 For the server to authenticate the client within the TLS handshake,
202 the client must have its own certificate. In cases where the client
203 must be authenticated without a certificate, HTTP, not TLS,
204 mechanisms would have to be employed. For example, HTTP headers have
205 been defined to perform user authentications. However, these
206 mechanisms are primitive compared to other mechanisms, most notably
207 EAP, that have been defined for contexts other than HTTP.
208 Furthermore, any mechanisms defined for HTTP cannot be utilized when
209 TLS is used to protect non-HTTP traffic.
211 The TLS protocol has also found an important use in authentication
212 for network access, originally within PPP for dial-up access and
213 later for wireless and wired 802.1X access. Several EAP types have
214 been defined that utilize TLS to perform mutual client-server
215 authentication. The first to appear, EAP-TLS, uses the TLS handshake
216 to authenticate both client and server based on the certificate of
217 each.
219 Subsequent protocols, such EAP-TTLSv0 and EAP-PEAP, utilize the TLS
220 handshake to allow the client to authenticate the server based on
221 the latter's certificate, then utilize the tunnel established by the
222 TLS handshake to perform user authentication, typically based on
223 password credentials. Such protocols are called "tunneled" EAP
224 protocols. The authentication mechanism used inside the tunnel may
225 itself be EAP, and the tunnel may also be used to convey additional
226 information between client and server.
228 TLS/IA is in effect a merger of the two types of TLS usage described
229 above, based on the recognition that tunneled authentication would
233 Paul Funk expires April 2005 [Page 4]
234 \f
235 Internet-Draft October 2004
238 be useful in other contexts besides EAP. However, the tunneled
239 protocols mentioned above are not directly compatible with a more
240 generic use of TLS, because they utilize the tunneled data portion
241 of TLS, thus precluding its use for other purposes such as carrying
242 HTTP traffic.
244 The TLS/IA solution to this problem is to fold the tunneled
245 authentication into the TLS handshake itself, making the data
246 portion of the TLS exchange available for HTTP or any other protocol
247 or connection that needs to be secured.
249 1.2 Handshake-Only vs. Full TLS Usage
251 It is anticipated that TLS/IA will be used with and without
252 subsequent protected data communication within the tunnel
253 established by the handshake.
255 For example, TLS/IA may be used to secure an HTTP data connection,
256 allowing more robust password-based user authentication to occur
257 within the TLS handshake than would otherwise be possible using
258 mechanisms available in HTTP.
260 TLS/IA may also be used for its handshake portion alone. For
261 example, EAP-TTLSv1 encapsulates a TLS/IA handshake in EAP as a
262 means to mutually authenticate a client and server and establish
263 keys for a separate data connection; no subsequent data portion is
264 required. Another example might be use of TLS/IA directly over TCP
265 to provide a user with credentials for single sign-on.
267 2 The InnerApplication Extension to TLS
269 The InnerApplication extension to TLS follows the guidelines of RFC
270 3546. The client proposes use of this extension by including a
271 ClientInnerApplication message in its ClientHello handshake message,
272 and the server confirms its use by including a
273 ServerInnerApplication message in its ServerHello handshake message.
275 Two new handshake messages are defined for use in TLS/IA:
277 - The PhaseFinished message. This message is similar to the
278 standard TLS Finished message; it allows the TLS/IA handshake to
279 operate in phases, with message and key confirmation occurring at
280 the end of each phase.
282 - The ApplicationPayload message. This message is used to carry AVP
283 (Attribute-Value Pair) sequences within the TLS/IA handshake, in
284 support of client-server applications such as authentication.
286 A new alert code is also defined for use in TLS/IA:
288 - The InnerApplicationFailure alert. This error alert allows either
292 Paul Funk expires April 2005 [Page 5]
293 \f
294 Internet-Draft October 2004
297 party to terminate the handshake due to a failure in an
298 application implemented via AVP sequences carried in
299 ApplicationPayload messages.
301 2.1 TLS/IA Overview
303 In TLS/IA, the handshake is divided into phases. The first phase,
304 called the "initial phase", is a standard TLS handshake; it is
305 followed by zero or more "application phases". The last phase is
306 called the "final phase"; this will be an application phase if a
307 such a phase is present, otherwise the standard TLS handshake is
308 both the initial and final phase. Any application phases between the
309 initial and final phase are called "intermediate phases".
311 A typical handshake consists of an initial phase and a final phase,
312 with no intermediate phases. Intermediate phases are only necessary
313 if interim confirmation key material generated during an application
314 phase is desired.
316 Each application phase consists of ApplicationPayload handshake
317 messages exchanged by client and server to implement applications
318 such as authentication, plus concluding messages for cryptographic
319 confirmation.
321 All application phases are encrypted. A new master secret and cipher
322 spec are negotiated at the conclusion of each phase, to be applied
323 in the subsequent phase. The master secret and cipher spec
324 negotiated at the conclusion of the final phase are applied to the
325 data exchange following the handshake.
327 All phases prior to the final phase use PhaseFinished rather than
328 Finished as the concluding message. The final phase concludes with
329 the Finished message.
331 Application phases may be omitted entirely only when session
332 resumption is used, provided both client and server agree that no
333 application phase is required. The client indicates in its
334 ClientHello whether it is willing to omit application phases in a
335 resumed session.
337 In each application phase, the client sends the first
338 ApplicationPayload message. ApplicationPayload messages are then
339 traded one at a time between client and server, until the server
340 concludes the phase by sending, in response to an ApplicationPayload
341 message from the client, a ChangeCipherSpec and PhaseFinished
342 sequence to conclude an intermediate phase, or a ChangeCipherSpec
343 and Finished sequence to conclude the final phase. The client then
344 responds with its own ChangeCipherSpec and PhaseFinished sequence,
345 or ChangeCipherSpec and Finished sequence.
351 Paul Funk expires April 2005 [Page 6]
352 \f
353 Internet-Draft October 2004
356 Note that the server MUST NOT send a ChangeCipherSpec plus Finished
357 or PhaseFinished message immediately after sending an
358 ApplicationPayload message. It must allow the client to send an
359 ApplicationPayload message prior to concluding the phase. Thus,
360 within any application phase, there will be one more
361 ApplicationPayload message sent by the client than sent by the
362 server.
364 The server determines which type of concluding message is used,
365 either PhaseFinished or Finished, and the client MUST echo the same
366 type of concluding message. Each PhaseFinished or Finished message
367 provides cryptographic confirmation of the integrity of all
368 handshake messages and keys generated from the start of the
369 handshake through the current phase.
371 Each ApplicationPayload message contains opaque data interpreted as
372 an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence
373 contains a typed data element. The exchanged AVPs allow client and
374 server to implement "applications" within a secure tunnel. An
375 application may be any procedure that someone may usefully define. A
376 typical application might be authentication; for example, the server
377 may authenticate the client based on password credentials using EAP.
378 Other possible applications include distribution of keys, validating
379 client integrity, setting up IPsec parameters, setting up SSL VPNs,
380 and so on.
382 The TLS master secret undergoes multiple permutations until a final
383 master secret is computed at the end of the entire handshake. Each
384 phase of the handshake results in a new master secret; the master
385 secret for each phase is confirmed by the PhaseFinished or Finished
386 message exchange that concludes that phase.
388 The initial master secret is computed during the initial phase of
389 the handshake, using the standard TLS-defined procedure. This
390 initial master secret is confirmed via the first exchange of
391 ChangeCipherSpec and PhaseFinished messages, or, in the case of a
392 resumed session with no subsequence application phase, the exchange
393 of ChangeCipherSpec and Finished messages.
395 Each subsequent master secret for an application phase is computed
396 using a PRF based on the current master secret, then mixing into the
397 result any session key material generated during authentications
398 during that phase. Each party computes a new master secret prior to
399 the conclusion of each application phase, and uses that new master
400 secret is to compute fresh keying material (that is, a TLS
401 "key_block", consisting of client and server MAC secrets, write keys
402 and IVs). The new master secret and keying material become part of
403 the pending read and write connection states. Following standard TLS
404 procedures, these connection states become current states upon
405 sending or receiving ChangeCipherSpec, and are confirmed via the
406 PhaseFinished or Finished message.
410 Paul Funk expires April 2005 [Page 7]
411 \f
412 Internet-Draft October 2004
415 The final master secret, computed during the final handshake phase
416 and confirmed by an exchange of ChangeCipherSpec and Finished
417 messages, becomes the actual TLS master secret that defines the
418 session. This final master secret is the surviving master secret,
419 and each prior master secrets SHOULD be discarded when a new
420 connection state is instantiated. The final master secret is used
421 for session resumption, as well as for any session key derivation
422 that protocols defined over TLS may require.
424 2.2 Message Exchange
426 Each intermediate handshake phase consists of ApplicationPayload
427 messages sent alternately by client and server, and a concluding
428 exchange of {ChangeCipherSpec, PhaseFinished} messages. The first
429 and last ApplicationPayload message in each intermediate phase is
430 sent by the client; the first {ChangeCipherSpec, PhaseFinished}
431 message sequence is sent by the server. Thus the client begins the
432 exchange with an ApplicationPayload message and the server
433 determines when to conclude it by sending {ChangeCipherSpec,
434 PhaseFinished}. When it receives the server's {ChangeCipherSpec,
435 PhaseFinished} messages, the client sends its own {ChangeCipherSpec,
436 PhaseFinished} messages, followed by an ApplicationPayload message
437 to begin the next handshake phase.
439 The final handshake proceeds in the same manner as the intermediate
440 handshake, except that the Finished message is used rather than the
441 PhaseFinished message, and the client does not send an
442 ApplicationPayload message for the next phase because there is no
443 next phase.
445 At the start of each application handshake phase, the server MUST
446 wait for the client's opening ApplicationPayload message before it
447 sends its own ApplicationPayload message to the client. The client
448 MAY NOT initiate conclusion of an application handshake phase by
449 sending the first {ChangeCipherSpec, PhaseFinished} or
450 {ChangeCipherSpec, Finished message} sequence; it MUST allow the
451 server to initiate the conclusion of the phase.
453 2.3 Master Key Permutation
455 Each permutation of the master secret from one phase to the next
456 begins with the calculation of a preliminary 48 octet vector
457 (pre_vector) based on the current master secret:
459 pre_vector = PRF(SecurityParameters.master_secret,
460 "inner application preliminary vector",
461 SecurityParameters.server_random +
462 SecurityParameters.client_random) [0..48];
464 Session key material generated by applications during the current
465 application phase are mixed into the preliminary vector by
469 Paul Funk expires April 2005 [Page 8]
470 \f
471 Internet-Draft October 2004
474 arithmetically adding each session key to it to compute the new
475 master secret. The preliminary vector is treated as a 48-octet
476 integer in big-endian order; that is, the first octet is of the
477 highest significance. Each session key is also treated as a big-
478 endian integer of whatever size it happens to be. Arithmetic carry
479 past the most significant octet is discarded; that is, the addition
480 is performed modulo 2 ^ 384.
482 Thus, the logical procedure for computing the next master secret
483 (which may also be a convenient implementation procedure) is as
484 follows:
486 1 At the start of each application handshake phase, use the current
487 master secret to compute pre_vector for the next master secret.
489 2 Each time session key material is generated from an
490 authentication or other exchange, arithmetically add that session
491 key material to pre_vector.
493 3 At the conclusion of the application handshake phase, copy the
494 current contents of pre_vector (which now includes addition of
495 all session key material) into the master secret, prior to
496 computing verify_data.
498 Note that the master secret is the only element of the TLS
499 SecurityParameters that is permuted from phase to phase. The
500 client_random, server_random, bulk_cipher_algorithm, mac_algorithm,
501 etc. remain constant throughout all phases of the handshake.
503 The purpose of using a PRF to compute a preliminary vector is to
504 ensure that, even in the absence of session keys, the master secret
505 is cryptographically distinct in each phase of the handshake.
507 The purpose of adding session keys into the preliminary vector is to
508 ensure that the same client entity that negotiated the original
509 master secret also negotiated the inner authentication(s). In the
510 absence of such mixing of keys generated from the standard TLS
511 handshake with keys generated from inner authentication, it is
512 possible for a hostile agent to mount a man-in-the-middle attack,
513 acting as server to an unsuspecting client to induce it to perform
514 an authentication with it, which it can then pass through the TLS
515 tunnel to allow it to pose as that client.
517 An application phase may include no authentications that produce a
518 session key, may include one such authentication, or may include
519 several. Arithmetic addition was chosen as the mixing method because
520 it is commutative, that is, it does not depend on the order of
521 operations. This allows multiple authentications to proceed
522 concurrently if desired, without having to synchronize the order of
523 master secret updates between client and server.
528 Paul Funk expires April 2005 [Page 9]
529 \f
530 Internet-Draft October 2004
533 Addition was chosen rather than XOR in order to avoid what is
534 probably a highly unlikely problem; namely, that two separate
535 authentications produce the same session key, which, if XORed, would
536 mutually cancel. This might occur, for example, if two instances of
537 an authentication method were to be applied against different forms
538 of a user identity that turn out in a some cases to devolve to the
539 same identity.
541 Finally, it was decided that a more complex mixing mechanism for
542 session key material, such as hashing, besides not being
543 commutative, would not provide any additional security, due to the
544 pseudo-random character of the preliminary vector and the powerful
545 PRF function which is applied to create derivative secrets.
547 2.3.1 Application Session Key Material
549 Many authentication protocols used today generate session keys that
550 are bound to the authentication. Such keying material is normally
551 intended for use in a subsequent data connection for encryption and
552 validation. For example, EAP-TLS, MS-CHAP-V2 and its alter ego EAP-
553 MS-CHAP-V2 each generate session keys.
555 Session keying material generated during an application phase MUST
556 be used to permute the TLS/IA master secret between one phase and
557 the next, and MUST NOT be used for any other purpose. Permuting the
558 master secret based on session keying material is necessary to
559 preclude man-in-the-middle attacks, in which an unsuspecting client
560 is induced to perform an authentication outside a tunnel with an
561 attacker posing as a server; the attacker can then introduce the
562 authentication protocol into a tunnel such as provided by TLS/IA,
563 fooling an authentic server into believing that the attacker is the
564 authentic user.
566 By mixing keying material generated during application phase
567 authentication into the master secret, such attacks are thwarted,
568 since only a single client identity could both authenticate
569 successfully and have derived the session keying material. Note that
570 the keying material generated during authentication must be
571 cryptographically related to the authentication and not derivable
572 from data exchanged during authentication in order for the keying
573 material to be useful in thwarting such attacks.
575 In addition, the fact that the master secret cryptographically
576 incorporates keying material from application phase authentications
577 provides additional protection when the master secret is used as a
578 basis for generating additional keys for use outside of the TLS
579 exchange. If the master secret did not include keying material from
580 inner authentications, an eavesdropper who somehow knew the server's
581 private key could, in an RSA-based handshake, determine the master
582 secret and hence would be able to compute the additional keys that
583 are based on it. When inner authentication keying material is
587 Paul Funk expires April 2005 [Page 10]
588 \f
589 Internet-Draft October 2004
592 incorporated into the master secret, such an attack becomes
593 impossible.
595 The RECOMMENDED amount of keying material to mix into the master
596 secret is 32 octets. Up to 48 octets MAY be used.
598 Each authentication protocol may define how the keying material it
599 generates is mapped to an octet sequence of some length for the
600 purpose of TLS/IA mixing. However, for protocols which do not
601 specify this (including the multitude of protocols that pre-date
602 TLS/IA) the following rules are defined. The first rule that applies
603 SHALL be the method for determining keying material:
605 - If the authentication protocol maps its keying material to the
606 RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key
607 [RFC2548], then the keying material for those attributes are
608 concatenated (with MS-MPPE-Recv-Key first), the concatenated
609 sequence is truncated to 32 octets if longer, and the result is
610 used as keying material. (Note that this rule applies to MS-CHAP-
611 V2 and EAP-MS-CHAP-V2.)
613 - If the authentication protocol uses a pseudo-random function to
614 generate keying material, that function is used to generate 32
615 octets for use as keying material.
617 2.4 Session Resumption
619 A TLS/IA initial handshake phase may be resumed using standard
620 mechanisms defined in RFC 2246. When the initial handshake phase is
621 resumed, client and server may not deem it necessary to exchange
622 AVPs in one or more additional application phases, as the resumption
623 itself may provide all the security needed.
625 The client indicates within the InnerApplication extension whether
626 it requires AVP exchange when session resumption occurs. If it
627 indicates that it does not, then the server may at its option omit
628 subsequent application phases and complete the resumed handshake in
629 a single phase.
631 Note that RFC 3546 specifically states that when session resumption
632 is used, the server MUST ignore any extensions in the ClientHello.
633 However, it is not possible to comply with this requirement for the
634 Inner Application extension, since even in a resumed session it may
635 be necessary to include application phases, and whether they must be
636 included is negotiated in the extension message itself. Therefore,
637 the RFC 3546 provision is specifically overridden for the single
638 case of the Inner Application extension, which is considered an
639 exception to this rule.
646 Paul Funk expires April 2005 [Page 11]
647 \f
648 Internet-Draft October 2004
651 2.5 Error Termination
653 The TLS/IA handshake may be terminated by either party sending a
654 fatal alert, following standard TLS procedures.
656 2.6 Computing Verification Data
658 In standard TLS, the "verify_data" vector of the Finished message is
659 computed as follows:
661 PRF(master_secret, finished_label, MD5(handshake_messages) +
662 SHA-1(handshake_messages)) [0..11];
664 This allows both parties to confirm the master secret as well as the
665 integrity of all handshake messages that have been exchanged.
667 In TLS/IA, verify_data for the initial handshake phase is computed
668 in exactly the same manner.
670 In the subsequent application phases, a slight variation of this
671 formula is used. The data that is hashed is the hash of the
672 handshake messages computed in the previous phase plus all handshake
673 messages that have been exchanged since that previous hash was
674 computed. Thus, for each application phase, the MD5 hash input to
675 the PRF is a hash of the MD5 hash computed in the previous phase
676 concatenated with all subsequent handshake messages through the
677 current phase; the SHA-1 hash is computed in the same way, but using
678 the SHA-1 hash computed for the previous phase.
680 Also, the master secret used in the PRF computation in each
681 application phase is the new master secret generated at the
682 conclusion of that phase.
684 For clarity, this is best expressed in formal notation.
686 Let phases be numbered from 0, where phase 0 is the initial phase.
688 Let:
690 Secret[n] be the master secret determined at the conclusion of
691 phase n.
693 Messages[n] be the additional handshake messages exchanged since
694 the hashes were computed in phase n - 1, where n > 0; or all
695 handshake messages exchanged to date starting from ClientHello,
696 where n = 0.
698 MD5[n] be the MD5 hash of handshake message material for phase n.
700 SHA-1[n] be the SHA-1 hash of handshake message material for
701 phase n.
705 Paul Funk expires April 2005 [Page 12]
706 \f
707 Internet-Draft October 2004
710 PRF[n] be the verify_data generated via PRF in phase n.
712 Hash computations for phase 0 are as follows:
714 MD5[0] = MD5(Messages[0])
716 SHA-1[0] = SHA-1(Messages[0])
718 Hash computations for phase i, where i > 0 (i.e. application phases)
719 are as follows:
721 MD5[i] = MD5(MD5[i-1] + Messages[i])
723 SHA-1[i] = SHA-1(SHA-1[i-1] + Messages[i])
725 The PRF computation to generate verify_data for any phase i
726 (including i = 0) is as follows:
728 PRF[i] = PRF(Secret[i], finished_label, MD5[i] + SHA-1[i])
729 [0..11]
731 Note that for phase 0, the PRF computation is identical to the
732 standard TLS computation. Variations to the algorithm occur only in
733 application phases, in the use of new master secrets and the
734 inclusion of hashes of previous handshake messages as input to the
735 hashing algorithms.
737 During an application phase, the handshake messages input to the
738 hashing algorithm include all handshake messages exchanged since the
739 last PRF computation was performed. This will always include either
740 one or two PhaseFinished messages from the previous phase. To see
741 why, assume that in the previous phase the client issued its
742 PhaseFinished message first, and the server's PhaseFinished message
743 in response thus included the client's PhaseFinished message. This
744 means that the server has not yet fed its PhaseFinished message into
745 the PRF, and the client has fed neither its own PhaseFinished
746 message nor the server's PhaseFinished response message into the
747 PRF. Therefore these messages from the previous phase must be fed
748 into the PhaseFinished messages along with handshake messages from
749 the current phase into the PRF that validates the current phase.
751 Note that the only handshake messages that appear in an application
752 phase are InnerApplication messages and Finished or Phase Finished
753 messages. ChangeCipherSpec messages are not handshake messages and
754 are therefore never included in the hash computations.
756 Note also that for TLS/IA, just as for standard TLS, client and
757 server include a somewhat different set of handshake messages in
758 hash computations. Therefore, both client and server must compute
759 two PRFs for each handshake phase: one to include the verify_data
764 Paul Funk expires April 2005 [Page 13]
765 \f
766 Internet-Draft October 2004
769 that it transmits, and one to use to check the verify_data received
770 from the other party.
772 2.7 TLS/IA Messages
774 All specifications of TLS/IA messages follow the usage defined in
775 RFC 2246.
777 TLS/IA defines a new TLS extension, two new handshake messages, and
778 a new alert code. The new types and codes are (decimal):
780 - "InnerApplication" extension type: 37703
782 - "PhaseFinished" type: 78
784 - "ApplicationPayload" type: 79
786 - "InnerApplicationFailure" code: 208
788 [Note: I have not checked these types yet against types defined in
789 RFCs or drafts. pf]
791 2.8 Negotiating the Inner Application Extension
793 Use of the InnerApplication extension follows RFC 3546. The client
794 proposes use of this extension by including the
795 ClientInnerApplication message in the client_hello_extension_list of
796 the extended ClientHello. If this message is included in the
797 ClientHello, the server MAY accept the proposal by including the
798 ServerInnerApplication message in the server_hello_extension_list of
799 the extended ServerHello. If use of this extension is either not
800 proposed by the client or not confirmed by the server, the
801 variations to the TLS handshake described here MUST NOT be used.
803 2.8.1 ClientInnerApplication
805 When the client wishes to propose use of the Inner Application
806 extension, it must include ClientInnerApplication in the
807 "extension_data" vector in the Extension structure in its extended
808 ClientHello message, where:
810 enum {
811 not_required(0), required(1), (255)
812 } AppPhaseOnResumption;
814 struct {
815 AppPhaseOnResumption app_phase_on_resumption;
816 } ClientInnerApplication;
818 The AppPhaseOnResumption enumeration allow client and server to
819 negotiate an abbreviated, single-phase handshake when session
823 Paul Funk expires April 2005 [Page 14]
824 \f
825 Internet-Draft October 2004
828 resumption is employed. If the server is able to resume a previous
829 session, and if the client sets app_phase_on_resumption to
830 not_required, then the server MAY conclude the initial handshake
831 phase with a Finished message, thus completing the handshake in a
832 single phase. If the client sets app_phase_on_resumption to
833 required, then the server MUST conclude the initial handshake phase
834 with PhaseFinished, thus allowing one or more subsequent application
835 phases to follow the initial handshake phase.
837 The value of app_phase_on_resumption applies to the current
838 handshake only. For example, it is possible for
839 app_phase_on_resumption to have different values in two handshakes
840 that are both resumed from the same original TLS session.
842 Note that the server may initiate one or more application phases
843 even if the client sets app_phase_on_resumption to not_required, as
844 the server itself may have reason to proceed with one or more
845 application phases.
847 Note also that if session resumption does not occur, the
848 app_phase_on_resumption variable is ignored, the server MUST
849 conclude the initial phase with a PhaseFinished message and one or
850 more application phases MUST follow the initial handshake phase.
852 2.8.2 ServerInnerApplication
854 When the server wishes to confirm use of the Inner Application
855 extension that has been proposed by the client, it must include
856 ServerInnerApplication in the "extension_data" vector in the
857 Extension structure in its extended ServerHello message, where:
859 struct {
860 } ServerInnerApplication;
862 Note that the ServerInnerApplication message contains no data;
863 however, it's presence is required to confirm use of the Inner
864 Application extension when proposed by the client.
866 If the client set app_phase_on_resumption to not_required and the
867 server agrees and will not initiate an application phase, the server
868 MUST NOT include ServerInnerApplication in its ServerHello and it
869 must conclude the initial (and only) handshake phase with the
870 Finished message. If, the server includes ServerInnerApplication, it
871 MUST conclude the initial handshake phase with PhaseFinished,
872 indicating that one or more application phases will follow the
873 initial handshake phase.
882 Paul Funk expires April 2005 [Page 15]
883 \f
884 Internet-Draft October 2004
887 2.9 The PhaseFinished Handshake Message
889 The PhaseFinished message concludes all handshake phases prior to
890 the final handshake phase. It MUST be immediately preceded by a
891 ChangeCipherSpec message. It is defined as follows:
893 struct {
894 opaque verify_data[12];
895 } PhaseFinished;
897 2.10 The ApplicationPayload Handshake Message
899 The ApplicationPayload message carries an AVP sequence during an
900 application handshake phase. It is defined as follows:
902 struct {
903 opaque avps[Handshake.length];
904 } ApplicationPayload;
906 where Handshake.length is the 24-bit length field in the
907 encapsulating Handshake message.
909 Note that the "avps" element has its length defined in square
910 bracket rather than angle bracket notation, implying a fixed rather
911 than variable length vector. This avoids the having the length of
912 the AVP sequence specified redundantly both in the encapsulating
913 Handshake message and as a length prefix in the avps element itself.
915 2.11 The InnerApplicationFailure Alert
917 An InnerApplicationFailure error alert may be sent by either party
918 during an application phase. This indicates that the sending party
919 considers the negotiation to have failed due to an application
920 carried in the AVP sequences, for example, a failed authentication.
922 The AlertLevel for an InnerApplicationFailure alert MUST be set to
923 "fatal".
925 Note that other alerts are possible during an application phase; for
926 example, decrypt_error. The InnerApplicationFailure alert relates
927 specifically to the failure of an application implemented via AVP
928 sequences; for example, failure of an EAP or other authentication
929 method, or information passed within the AVP sequence that is found
930 unsatisfactory.
932 3 Encapsulation of AVPs within ApplicationPayload Messages
934 During application phases of the TLS handshake, information is
935 exchanged between client and server through the use of attribute-
936 value pairs (AVPs). This data is encrypted using the then-current
937 cipher state established during the preceding handshake phase.
941 Paul Funk expires April 2005 [Page 16]
942 \f
943 Internet-Draft October 2004
946 The AVP format chosen for TLS/IA is compatible with the Diameter AVP
947 format. This does not in any way represent a requirement that
948 Diameter be supported by any of the devices or servers participating
949 in the TLS/IA conversation, whether directly as client or server or
950 indirectly as a backend authenticator. Use of this format is merely
951 a convenience. Diameter is a superset of RADIUS and includes the
952 RADIUS attribute namespace by definition, though it does not limit
953 the size of an AVP as does RADIUS. RADIUS, in turn, is a widely
954 deployed AAA protocol and attribute definitions exist for all
955 commonly used password authentication protocols, including EAP.
957 Thus, Diameter is not considered normative except as specified in
958 this document. Specifically, the AVP Codes used in TLS/IA are
959 semantically equivalent to those defined for Diameter, and, by
960 extension, RADIUS.
962 Use of the RADIUS/Diameter namespace allows a TLS/IA server to
963 easily translate between AVPs it uses to communicate with clients
964 and the protocol requirements of AAA servers that are widely
965 deployed. Plus, it provides a well-understood mechanism to allow
966 vendors to extend that namespace for their particular requirements.
968 3.1 AVP Format
970 The format of an AVP is shown below. All items are in network, or
971 big-endian, order; that is, they have most significant octet first.
973 0 1 2 3
974 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
975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
976 | AVP Code |
977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
978 |V M r r r r r r| AVP Length |
979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
980 | Vendor-ID (opt) |
981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
982 | Data ...
983 +-+-+-+-+-+-+-+-+
985 AVP Code
987 The AVP Code is four octets and, combined with the Vendor-ID
988 field if present, identifies the attribute uniquely. The first
989 256 AVP numbers represent attributes defined in RADIUS. AVP
990 numbers 256 and above are defined in Diameter.
992 AVP Flags
994 The AVP Flags field is one octet, and provides the receiver with
995 information necessary to interpret the AVP.
1000 Paul Funk expires April 2005 [Page 17]
1001 \f
1002 Internet-Draft October 2004
1005 The 'V' (Vendor-Specific) bit indicates whether the optional
1006 Vendor-ID field is present. When set to 1, the Vendor-ID field is
1007 present and the AVP Code is interpreted according to the
1008 namespace defined by the vendor indicated in the Vendor-ID field.
1010 The 'M' (Mandatory) bit indicates whether support of the AVP is
1011 required. If this bit is set to 0, this indicates that the AVP
1012 may be safely ignored if the receiving party does not understand
1013 or support it. If set to 1, this indicates that the receiving
1014 party must fail the negotiation if it does not understand the
1015 AVP; for a server, this would imply returning EAP-Failure, for a
1016 client, this would imply abandoning the negotiation.
1018 The 'r' (reserved) bits are unused and must be set to 0.
1020 AVP Length
1022 The AVP Length field is three octets, and indicates the length of
1023 this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID
1024 (if present) and Data.
1026 Vendor-ID
1028 The Vendor-ID field is present if and only if the 'V' bit is set
1029 in the AVP Flags field. It is four octets, and contains the
1030 vendor's IANA-assigned "SMI Network Management Private Enterprise
1031 Codes" [RFC1700] value. Vendors defining their own AVPs must
1032 maintain a consistent namespace for use of those AVPs within
1033 RADIUS, Diameter and TLS/IA.
1035 A Vendor-ID value of zero is semantically equivalent to absence
1036 of the Vendor-ID field altogether.
1038 3.2 AVP Sequences
1040 Data encapsulated within the TLS Record Layer must consist entirely
1041 of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet
1042 boundary relative to the first AVP in the sequence. If an AVP is not
1043 a multiple of 4 octets, it must be padded with 0s to the next 4-
1044 octet boundary.
1046 Note that the AVP Length does not include the padding.
1048 3.3 Guidelines for Maximum Compatibility with AAA Servers
1050 When maximum compatibility with AAA servers is desired, the
1051 following guidelines for AVP usage are suggested:
1053 - Non-vendor-specific AVPs should be selected from the set of
1054 attributes defined for RADIUS; that is, attributes with codes
1055 less than 256. This provides compatibility with both RADIUS and
1059 Paul Funk expires April 2005 [Page 18]
1060 \f
1061 Internet-Draft October 2004
1064 Diameter.
1066 - Vendor-specific AVPs should be defined in terms of RADIUS.
1067 Vendor-specific RADIUS attributes translate to Diameter
1068 automatically; the reverse is not true. RADIUS vendor-specific
1069 attributes use RADIUS attribute 26 and include vendor ID, vendor-
1070 specific attribute code and length; see [RFC2865] for details.
1072 4 Tunneled Authentication within Application Phases
1074 TLS/IA permits user authentication information to be tunneled within
1075 an application phase between client and server, protecting the
1076 security of the authentication information against active and
1077 passive attack.
1079 Any type of password or other authentication may be tunneled. Also,
1080 multiple tunneled authentications may be performed. Normally,
1081 tunneled authentication is used when the client has not been issued
1082 a certificate and the TLS handshake provides only one-way
1083 authentication of the server to the client; however, in certain
1084 cases it may be desired to perform certificate authentication of the
1085 client during the initial handshake phase as well as tunneled user
1086 authentication in a subsequent application phase.
1088 This section establishes rules for using common authentication
1089 mechanisms within TLS/IA. Any new authentication mechanism should in
1090 general be covered by these rules if it is defined as an EAP type.
1091 Authentication mechanisms whose use within TLS/IA is not covered
1092 within this specification may require separate standardization,
1093 preferably within the standard that describes the authentication
1094 mechanism in question.
1096 4.1 Implicit challenge
1098 Certain authentication protocols that use a challenge/response
1099 mechanism rely on challenge material that is not generated by the
1100 authentication server, and therefore require special handling.
1102 In PPP protocols such CHAP, MS-CHAP and MS-CHAP-V2, for example, the
1103 Network Access Server (NAS) issues a challenge to the client, the
1104 client then hashes the challenge with the password and forwards the
1105 response to the NAS. The NAS then forwards both challenge and
1106 response to a AAA server. But because the AAA server did not itself
1107 generate the challenge, such protocols are susceptible to replay
1108 attack.
1110 If the client were able to create both challenge and response,
1111 anyone able to observe a CHAP or MS-CHAP exchange could pose as that
1112 user by replaying that challenge and response into a TLS/IA
1113 conversation.
1118 Paul Funk expires April 2005 [Page 19]
1119 \f
1120 Internet-Draft October 2004
1123 To make these protocols secure in TLS/IA, it is necessary to provide
1124 a mechanism to produce a challenge that the client cannot control or
1125 predict.
1127 When a challenge-based authentication mechanism is used, both client
1128 and server use the TLS PRF function to generate as many octets as
1129 are required for the challenge, using the constant string "inner
1130 application challenge", based on the then-current master secret and
1131 random values established during the initial handshake phase:
1133 IA_challenge = PRF(SecurityParameters.master_secret,
1134 "inner application challenge",
1135 SecurityParameters.server_random +
1136 SecurityParameters.client_random);
1138 4.2 Tunneled Authentication Protocols
1140 This section describes the rules for tunneling specific
1141 authentication protocols within TLS/IA.
1143 For each protocol, the RADIUS RFC that defines the relevant
1144 attribute formats is cited. Note that these attributes are
1145 encapsulated as described in section 3.1; that is, as Diameter
1146 attributes, not as RADIUS attributes. In other words, the AVP Code,
1147 Length, Flags and optional Vendor-ID are formatted as described in
1148 section 3.1, while the Data is formatted as described by the cited
1149 RADIUS RFC.
1151 All tunneled authentication protocols except EAP must be initiated
1152 by the client in the first ApplicationPayload message of an
1153 application phase. EAP may be initiated by the client in the first
1154 ApplicationPayload message of an application phase; it may also be
1155 initiated by the server in any ApplicationPayload message.
1157 The authentication protocols described below may be performed
1158 directly by the TLS/IA server or may be forwarded to a backend AAA
1159 server. For authentication protocols that generate session keys, the
1160 backend server must return those session keys to the TLS/IA server
1161 in order to allow the protocol to succeed within TLS/IA. RADIUS or
1162 Diameter servers are suitable backend AAA servers for this purpose.
1163 RADIUS servers typically return session keys in MS-MPPE-Recv-Key and
1164 MS-MPPE-Send-Key attributes [RFC2548]; Diameter servers return
1165 session keys in the EAP-Master-Session-Key AVP [AAA-EAP].
1167 4.2.1 EAP
1169 EAP is described in [RFC3784]; RADIUS attribute formats are
1170 described in [RFC3579].
1177 Paul Funk expires April 2005 [Page 20]
1178 \f
1179 Internet-Draft October 2004
1182 When EAP is the tunneled authentication protocol, each tunneled EAP
1183 packet between the client and server is encapsulated in an EAP-
1184 Message AVP.
1186 Either client or server may initiate EAP.
1188 The client is the first to transmit within any application phase,
1189 and it may include an EAP-Response/Identity AVP in its
1190 ApplicationPayload message to begin an EAP conversation.
1191 Alternatively, if the client does not initiate EAP the server may,
1192 by including an EAP-Request/Identity AVP in its ApplicationPayload
1193 message.
1195 The client's EAP-Response/Identity provides the actual username; the
1196 privacy of the user's identity is now guaranteed by the TLS
1197 encryption. This username must be a Network Access Identifier (NAI)
1198 [RFC2486]; that is, it must be in the following format:
1200 username@realm
1202 The @realm portion is optional, and is used to allow the server to
1203 forward the EAP message sequence to the appropriate server in the
1204 AAA infrastructure when necessary.
1206 The EAP authentication between client and server proceeds normally,
1207 as described in [RFC3784]. However, upon completion the server does
1208 not send an EAP-Success or EAP-Failure AVP. Instead, the server
1209 signals success when it concludes the application phase by issuing a
1210 Finished or PhaseFinished message, or it signals failure by issuing
1211 an InnerApplicationFailure alert.
1213 Note that the client may also issue an InnerApplicationFailure
1214 alert, for example, when authentication of the server fails in a
1215 method providing mutual authentication.
1217 4.2.2 CHAP
1219 The CHAP algorithm is described in [RFC1994]; RADIUS attribute
1220 formats are described in [RFC2865].
1222 Both client and server generate 17 octets of challenge material,
1223 using the constant string "inner application challenge" as described
1224 above. These octets are used as follows:
1226 CHAP-Challenge [16 octets]
1227 CHAP Identifier [1 octet]
1229 The client initiates CHAP by including User-Name, CHAP-Challenge and
1230 CHAP-Password AVPs in the first ApplicationPayload message in any
1231 application phase. The CHAP-Challenge value is taken from the
1232 challenge material. The CHAP-Password consists of CHAP Identifier,
1236 Paul Funk expires April 2005 [Page 21]
1237 \f
1238 Internet-Draft October 2004
1241 taken from the challenge material; and CHAP response, computed
1242 according to the CHAP algorithm.
1244 Upon receipt of these AVPs from the client, the server must verify
1245 that the value of the CHAP-Challenge AVP and the value of the CHAP
1246 Identifier in the CHAP-Password AVP are equal to the values
1247 generated as challenge material. If either item does not match
1248 exactly, the server must reject the client. Otherwise, it validates
1249 the CHAP-Challenge to determine the result of the authentication.
1251 4.2.3 MS-CHAP
1253 The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute
1254 formats are described in [RFC2548].
1256 Both client and server generate 9 octets of challenge material,
1257 using the constant string "inner application challenge" as described
1258 above. These octets are used as follows:
1260 MS-CHAP-Challenge [8 octets]
1261 Ident [1 octet]
1263 The client initiates MS-CHAP by including User-Name, MS-CHAP-
1264 Challenge and MS-CHAP-Response AVPs in the first ApplicationPayload
1265 message in any application phase. The MS-CHAP-Challenge value is
1266 taken from the challenge material. The MS-CHAP-Response consists of
1267 Ident, taken from the challenge material; Flags, set according the
1268 client preferences; and LM-Response and NT-Response, computed
1269 according to the MS-CHAP algorithm.
1271 Upon receipt of these AVPs from the client, the server must verify
1272 that the value of the MS-CHAP-Challenge AVP and the value of the
1273 Ident in the client's MS-CHAP-Response AVP are equal to the values
1274 generated as challenge material. If either item does not match
1275 exactly, the server must reject the client. Otherwise, it validates
1276 the MS-CHAP-Challenge to determine the result of the authentication.
1278 4.2.4 MS-CHAP-V2
1280 The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute
1281 formats are described in [RFC2548].
1283 Both client and server generate 17 octets of challenge material,
1284 using the constant string "inner application challenge" as described
1285 above. These octets are used as follows:
1287 MS-CHAP-Challenge [16 octets]
1288 Ident [1 octet]
1290 The client initiates MS-CHAP-V2 by including User-Name, MS-CHAP-
1291 Challenge and MS-CHAP2-Response AVPs in the first ApplicationPayload
1295 Paul Funk expires April 2005 [Page 22]
1296 \f
1297 Internet-Draft October 2004
1300 message in any application phase. The MS-CHAP-Challenge value is
1301 taken from the challenge material. The MS-CHAP2-Response consists of
1302 Ident, taken from the challenge material; Flags, set to 0; Peer-
1303 Challenge, set to a random value; and Response, computed according
1304 to the MS-CHAP-V2 algorithm.
1306 Upon receipt of these AVPs from the client, the server must verify
1307 that the value of the MS-CHAP-Challenge AVP and the value of the
1308 Ident in the client's MS-CHAP2-Response AVP are equal to the values
1309 generated as challenge material. If either item does not match
1310 exactly, the server must reject the client. Otherwise, it validates
1311 the MS-CHAP2-Challenge.
1313 If the MS-CHAP2-Challenge received from the client is correct, the
1314 server tunnels the MS-CHAP2-Success AVP to the client.
1316 Upon receipt of the MS-CHAP2-Success AVP, the client is able to
1317 authenticate the server. In its next InnerApplicationPayload message
1318 to the server, the client does not include any MS-CHAP-V2 AVPs.
1319 (This may result in an empty InnerApplicationPayload if no other
1320 AVPs need to be sent.)
1322 If the MS-CHAP2-Challenge received from the client is not correct,
1323 the server tunnels an MS-CHAP2-Error AVP to the client. This AVP
1324 contains a new Ident and a string with additional information such
1325 as error reason and whether a retry is allowed. If the error reason
1326 is an expired password and a retry is allowed, the client may
1327 proceed to change the user's password. If the error reason is not an
1328 expired password or if the client does not wish to change the user's
1329 password, it issues an InnerApplicationFailure alert.
1331 If the client does wish to change the password, it tunnels MS-CHAP-
1332 NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the server.
1333 The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge
1334 received in the MS-CHAP2-Error AVP. The MS-CHAP-Challenge AVP simply
1335 echoes the new Challenge.
1337 Upon receipt of these AVPs from the client, the server must verify
1338 that the value of the MS-CHAP-Challenge AVP and the value of the
1339 Ident in the client's MS-CHAP2-CPW AVP match the values it sent in
1340 the MS-CHAP2-Error AVP. If either item does not match exactly, the
1341 server must reject the client. Otherwise, it validates the MS-CHAP2-
1342 CPW AVP.
1344 If the MS-CHAP2-CPW AVP received from the client is correct, and the
1345 server is able to change the user's password, the server tunnels the
1346 MS-CHAP2-Success AVP to the client and the negotiation proceeds as
1347 described above.
1354 Paul Funk expires April 2005 [Page 23]
1355 \f
1356 Internet-Draft October 2004
1359 Note that additional AVPs associated with MS-CHAP-V2 may be sent by
1360 the server; for example, MS-CHAP-Domain. The server must tunnel such
1361 authentication-related AVPs along with the MS-CHAP2-Success.
1363 4.2.5 PAP
1365 PAP RADIUS attribute formats are described in [RFC2865].
1367 The client initiates PAP by including User-Name and User-Password
1368 AVPs in the first ApplicationPayload message in any application
1369 phase.
1371 In RADIUS, User-Password is padded with nulls to a multiple of 16
1372 octets, then encrypted using a shared secret and other packet
1373 information.
1375 A TLS/IA, however, does not RADIUS-encrypt the password since all
1376 application phase data is already encrypted. The client SHOULD,
1377 however, null-pad the password to a multiple of 16 octets, to
1378 obfuscate its length.
1380 Upon receipt of these AVPs from the client, the server may be able
1381 to decide whether to authenticate the client immediately, or it may
1382 need to challenge the client for more information.
1384 If the server wishes to issue a challenge to the client, it MUST
1385 tunnel the Reply-Message AVP to the client; this AVP normally
1386 contains a challenge prompt of some kind. It may also tunnel
1387 additional AVPs if necessary, such the Prompt AVP. Upon receipt of
1388 the Reply-Message AVPs, the client tunnels User-Name and User-
1389 Password AVPs again, with the User-Password AVP containing new
1390 information in response to the challenge. This process continues
1391 until the server determines the authentication has succeeded or
1392 failed.
1394 4.3 Performing Multiple Authentications
1396 In some cases, it is desirable to perform multiple user
1397 authentications. For example, a AAA/H may want first to authenticate
1398 the user by password, then by token card.
1400 The server may perform any number of additional user authentications
1401 using EAP, simply by issuing a EAP-Request with a new protocol type
1402 once the previous authentication has completed..
1404 For example, a server wishing to perform MD5-Challenge followed by
1405 Generic Token Card would first issue an EAP-Request/MD5-Challenge
1406 AVP and receive a response. If the response is satisfactory, it
1407 would then issue EAP-Request/Generic Token Card AVP and receive a
1408 response. If that response were also satisfactory, it would consider
1409 the user authenticated.
1413 Paul Funk expires April 2005 [Page 24]
1414 \f
1415 Internet-Draft October 2004
1418 5 Example Message Sequences
1420 This section presents a variety of possible TLS/IA message
1421 sequences. These examples do not attempt to exhaustively depict all
1422 possible scenarios.
1424 Parentheses indicate optional TLS messages. Brackets indicate
1425 optional message exchanges. Ellipsis (. . .) indicates optional
1426 repetition of preceding messages.
1428 5.1 Full Initial Handshake with Intermediate and Final Application
1429 Phases
1431 The diagram below depicts a full initial handshake phase followed by
1432 two application phases.
1434 Note that the client concludes the intermediate phase and starts the
1435 final phase in an uninterrupted sequence of three messages:
1436 ChangeCipherSpec and PhaseFinished belong to the intermediate phase,
1437 and ApplicationPayload belongs to the final phase.
1439 Client Server
1440 ------ ------
1442 *** Initial Phase:
1443 ClientHello -------->
1444 ServerHello
1445 (Certificate)
1446 ServerKeyExchange
1447 (CertificateRequest)
1448 <-------- ServerHelloDone
1449 (Certificate)
1450 ClientKeyExchange
1451 (CertificateVerify)
1452 ChangeCipherSpec
1453 PhaseFinished -------->
1454 ChangeCipherSpec
1455 <-------- PhaseFinished
1457 *** Intermediate Phase:
1458 ApplicationPayload -------->
1460 [
1461 <-------- ApplicationPayload
1463 ApplicationPayload -------->
1465 ...
1466 ]
1467 ChangeCipherSpec
1468 <-------- PhaseFinished
1472 Paul Funk expires April 2005 [Page 25]
1473 \f
1474 Internet-Draft October 2004
1477 ChangeCipherSpec
1478 PhaseFinished
1479 *** Final Phase:
1480 ApplicationPayload -------->
1482 [
1483 <-------- ApplicationPayload
1485 ApplicationPayload -------->
1487 ...
1488 ]
1489 <-------- ChangeCipherSpec
1490 Finished
1491 ChangeCipherSpec
1492 Finished -------->
1494 5.2 Resumed Session with Single Application Phase
1496 The diagram below depicts a resumed session followed by a single
1497 application phase.
1499 Note that the client concludes the initial phase and starts the
1500 final phase in an uninterrupted sequence of three messages:
1501 ChangeCipherSpec and PhaseFinished belong to the initial phase, and
1502 ApplicationPayload belongs to the final phase.
1504 Client Server
1505 ------ ------
1507 *** Initial Phase:
1508 ClientHello -------->
1509 ServerHello
1510 ChangeCipherSpec
1511 <-------- PhaseFinished
1512 ChangeCipherSpec
1513 PhaseFinished
1514 *** Final Phase:
1515 ApplicationPayload -------->
1517 [
1518 <-------- ApplicationPayload
1520 ApplicationPayload -------->
1522 ...
1523 ]
1524 <-------- ChangeCipherSpec
1525 Finished
1526 ChangeCipherSpec
1527 Finished -------->
1531 Paul Funk expires April 2005 [Page 26]
1532 \f
1533 Internet-Draft October 2004
1537 5.3 Resumed Session with No Application Phase
1539 The diagram below depicts a resumed session without any subsequent
1540 application phase. This will occur if the client indicates in its
1541 ClientInnerApplication message that no application phase is required
1542 and the server concurs.
1544 Note that this message sequence is identical to that of a standard
1545 TLS resumed session.
1547 Client Server
1548 ------ ------
1550 *** Initial/Final Phase:
1551 ClientHello -------->
1552 ServerHello
1553 ChangeCipherSpec
1554 <-------- Finished
1555 ChangeCipherSpec
1556 Finished
1558 6 Security Considerations
1560 This document introduces a new TLS extension called "Inner
1561 Application". When TLS is used with the Inner Application extension
1562 (TLS/IA), additional messages are exchanged during the TLS
1563 handshake. Hence a number of security issues need to be taken into
1564 consideration. Since the security heavily depends on the information
1565 (called "applications") which are exchanged between the TLS client
1566 and the TLS server as part of the TLS/IA extension we try to
1567 classify them into two categories: The first category considers the
1568 case where the exchange results in the generation of keying
1569 material. This is, for example, the case with many EAP methods. EAP
1570 is one of the envisioned main "applications". The second category
1571 focuses on cases where no session key is generated. The security
1572 treatment of the latter category is discouraged since it is
1573 vulnerability to man-in-the-middle attacks if the two sessions
1574 cannot be bound to each other as shown in [MITM].
1576 Subsequently, we investigate a number of security issues:
1578 - Architecture and Trust Model
1580 For many of the use cases in this document we assume that three
1581 functional entities participate in the protocol exchange: TLS
1582 client, TLS server and a AAA infrastructure (typically consisting
1583 of a AAA server and possibly a AAA broker). The protocol exchange
1584 described in this document takes place between the TLS client and
1585 the TLS server. The interaction between the AAA client (which
1586 corresponds to the TLS server) and the AAA server is described in
1590 Paul Funk expires April 2005 [Page 27]
1591 \f
1592 Internet-Draft October 2004
1595 the respective AAA protocol documents and therefore outside the
1596 scope of this document. The trust model behind this architecture
1597 with respect to the authentication, authorization, session key
1598 establishment and key transport within the AAA infrastructure is
1599 discussed in [KEYING].
1601 - Authentication
1603 This document assumes that the TLS server is authenticated to the
1604 TLS client as part of the authentication procedure of the initial
1605 TLS Handshake. This approach is similar to the one chosen with
1606 the EAP support in IKEv2 (see [IKEv2]). Typically, public key
1607 based server authentication is used for this purpose. More
1608 interesting is the client authentication property whereby
1609 information exchanged as part of the Inner Application is used to
1610 authenticate (or authorize) the client. For example, if EAP is
1611 used as an inner application then EAP methods are used to perform
1612 authentication and key agreement between the EAP peer (most
1613 likely the TLS client) and the EAP server (i.e., AAA server).
1615 - Authorization
1617 Throughout this document it is assumed that the TLS server can be
1618 authorized by the TLS client as a legitimate server as part of
1619 the authentication procedure of the initial TLS Handshake. The
1620 entity acting as TLS client can be authorized either by the TLS
1621 server or by the AAA server (if the authorization decision is
1622 offloaded). Typically, the authenticated identity is used to
1623 compute the authorization decision but credential-based
1624 authorization mechanisms may be used as well.
1626 - Man-in-the-Middle Attack
1628 Man-in-the-middle attacks have become a concern with tunneled
1629 authentication protocols because of the discovered
1630 vulnerabilities (see [MITM]) of a missing cryptographic binding
1631 between the independent protocol sessions. This document also
1632 proposes a tunneling protocol, namely individual inner
1633 application sessions are tunneled within a previously executed
1634 session. The first protocol session in this exchange is the
1635 initial TLS Handshake. To avoid man-in-the-middle attacks a
1636 number of sections address how to establish such a cryptographic
1637 binding (see Section 2.3 and 2.6).
1639 - User Identity Confidentiality
1641 The TLS/IA extension allows splitting the authentication of the
1642 TLS server from the TLS client into two separate sessions. As one
1643 of the advantages, this provides active user identity
1644 confidentiality since the TLS client is able to authenticate the
1645 TLS server and to establish a unilateral authenticated and
1649 Paul Funk expires April 2005 [Page 28]
1650 \f
1651 Internet-Draft October 2004
1654 confidentiality-protected channel prior to starting the client-
1655 side authentication.
1657 - Session Key Establishment
1659 TLS [RFC2246] defines how session key material produced during
1660 the TLS Handshake is generated with the help of a pseudo-random
1661 function to expand it to keying material of the desired length
1662 for later usage in the TLS Record Layer. Section 2.3 gives some
1663 guidelines with regard to the master key generation. Since the
1664 TLS/IA extension supports multiple exchanges whereby each phase
1665 concludes with a generated keying material. In addition to the
1666 keying material established as part of TLS itself, most inner
1667 applications will produce their keying material. For example,
1668 keying material established as part of an EAP method must be
1669 carried from the AAA server to the AAA client. Details are
1670 subject to the specific AAA protocol (for example, EAP usage in
1671 Diameter [AAA-EAP].
1673 - Denial of Service Attacks
1675 This document does not modify the initial TLS Handshake and as
1676 such, does not introduce new vulnerabilities with regard to DoS
1677 attacks. Since the TLS/IA extension allows to postpone the
1678 client-side authentication to a later stage in the protocol
1679 phase. As such, it allows malicious TLS clients to initiate a
1680 number of exchanges while remaining anonymous. As a consequence,
1681 state at the server is allocated and computational efforts are
1682 required at the server side. Since the TLS client cannot be
1683 stateless this is not strictly a DoS attack.
1685 - Confidentiality Protection and Dictionary Attack Resistance
1687 Similar to the user identity confidentiality property the usage
1688 of the TLS/IA extension allows to establish a unilateral
1689 authenticated tunnel which is confidentiality protected. This
1690 tunnel protects the inner application information elements to be
1691 protected against active adversaries and therefore provides
1692 resistance against dictionary attacks when password-based
1693 authentication protocols are used inside the tunnel. In general,
1694 information exchanged inside the tunnel experiences
1695 confidentiality protection.
1697 - Downgrading Attacks
1699 This document defines a new extension. The TLS client and the TLS
1700 server indicate the capability to support the TLS/IA extension as
1701 part of the client_hello_extension_list and the
1702 server_hello_extension_list payload. More details can be found in
1703 Section 2.8. To avoid downgrading attacks whereby an adversary
1708 Paul Funk expires April 2005 [Page 29]
1709 \f
1710 Internet-Draft October 2004
1713 removes a capability from the list is avoided by the usage of the
1714 Finish or PhaseFinished message as described in Section 2.6.
1716 7 References
1718 7.1 Normative References
1720 [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
1721 1700, October 1994.
1723 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
1724 Protocol (CHAP)", RFC 1994, August 1996.
1726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1727 Requirement Levels", RFC 2119, March 1997.
1729 [RFC2246] Dierks, T., and C. Allen, "The TLS Protocol Version
1730 1.0", RFC 2246, November 1998.
1732 [RFC2433] Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions",
1733 RFC 2433, October 1998.
1735 [RFC2486] Aboba, B., and M. Beadles, "The Network Access
1736 Identifier", RFC 2486, January 1999.
1738 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
1739 RFC 2548, March 1999.
1741 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
1742 RFC 2759, January 2000.
1744 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1745 "Remote Authentication Dial In User Service (RADIUS)",
1746 RFC 2865, June 2000.
1748 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
1749 J., and T. Wright, "Transport Layer Security (TLS)
1750 Extensions", RFC 3546, June 2003.
1752 [RFC3579] Aboba, B., and P.Calhoun, "RADIUS (Remote Authentication
1753 Dial In User Service) Support For Extensible
1754 Authentication Protocol (EAP)", RFC 3579, September
1755 2003.
1757 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
1758 Arkko, "Diameter Base Protocol", RFC 3588, July 2003.
1760 [RFC3784] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
1761 H. Levkowetz, "PPP Extensible Authentication Protocol
1762 (EAP)", RFC 3784, June 2004.
1767 Paul Funk expires April 2005 [Page 30]
1768 \f
1769 Internet-Draft October 2004
1773 7.2 Informative References
1775 [RFC1661] Simpson, W. (Editor), "The Point-to-Point Protocol
1776 (PPP)", STD 51, RFC 1661, July 1994.
1778 [RFC2716] Aboba, B., and D. Simon, "PPP EAP TLS Authentication
1779 Protocol", RFC 2716, October 1999.
1781 [EAP-TTLS] Funk, P., and S. Blake-Wilson, " EAP Tunneled TLS
1782 Authentication Protocol (EAP-TTLS)", draft-ietf-pppext-
1783 eap-ttls-05.txt, July 2004.
1785 [EAP-PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G.,
1786 and S. Josefsson, "Protected EAP Protocol (PEAP) Version
1787 2", draft-josefsson-pppext-eap-tls-eap-08.txt, July
1788 2004.
1790 [TLS-PSK] Eronen, P., and H. Tschofenig, "Pre-Shared Key
1791 Ciphersuites for Transport Layer Security (TLS)", draft-
1792 ietf-tls-psk-01.txt, August 2004.
1794 [802.1X] IEEE Standards for Local and Metropolitan Area Networks:
1795 Port based Network Access Control, IEEE Std 802.1X-2001,
1796 June 2001.
1798 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
1799 in Tunneled Authentication",
1800 http://www.saunalahti.fi/~asokan/research/mitm.html,
1801 Nokia Research Center, Finland, October 24 2002.
1803 [KEYING] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP
1804 Key Management Framework", draft-ietf-eap-keying-01.txt
1805 (work in progress), October 2003.
1807 [IKEv2] C.Kaufman, "Internet Key Exchange (IKEv2) Protocol",
1808 draft-ietf-ipsec-ikev2-16.txt (work in progress),
1809 September 2004.
1811 [AAA-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter Exntesible
1812 Authentication Protocol (EAP) Application", draft-ietf-
1813 aaa-eap-03.txt (work in progress), October 2003.
1815 8 Authors' Addresses
1817 Questions about this memo can be directed to:
1819 Paul Funk
1820 Funk Software, Inc.
1821 222 Third Street
1822 Cambridge, MA 02142
1826 Paul Funk expires April 2005 [Page 31]
1827 \f
1828 Internet-Draft October 2004
1831 USA
1832 Phone: +1 617 497-6339
1833 E-mail: paul@funk.com
1835 Simon Blake-Wilson
1836 Basic Commerce & Industries, Inc.
1837 96 Spadina Ave, Unit 606
1838 Toronto, Ontario M5V 2J6
1839 Canada
1840 Phone: +1 416 214-5961
1841 E-mail: sblakewilson@bcisse.com
1843 Ned Smith
1844 Intel Corporation
1845 MS: JF1-229
1846 2111 N.E. 25th Ave.
1847 Hillsboro, OR 97124
1848 Phone: +1 503 264-2692
1849 E-mail: ned.smith@intel.com
1851 Hannes Tschofenig
1852 Siemens
1853 Otto-Hahn-Ring 6
1854 Munich, Bayern 81739\
1855 Germany
1856 Phone: +49 89 636 40390
1857 E-mail: Hannes.Tschofenig@siemens.com
1859 9 Intellectual Property Statement
1861 The IETF takes no position regarding the validity or scope of any
1862 Intellectual Property Rights or other rights that might be claimed
1863 to pertain to the implementation or use of the technology described
1864 in this document or the extent to which any license under such
1865 rights might or might not be available; nor does it represent that
1866 it has made any independent effort to identify any such rights.
1867 Information on the procedures with respect to rights in RFC
1868 documents can be found in BCP 78 and BCP 79.
1870 Copies of IPR disclosures made to the IETF Secretariat and any
1871 assurances of licenses to be made available, or the result of an
1872 attempt made to obtain a general license or permission for the use
1873 of such proprietary rights by implementers or users of this
1874 specification can be obtained from the IETF on-line IPR repository
1875 at http://www.ietf.org/ipr.
1877 The IETF invites any interested party to bring to its attention any
1878 copyrights, patents or patent applications, or other proprietary
1879 rights that may cover technology that may be required to implement
1880 this standard. Please address the information to the IETF at ietf-
1881 ipr@ietf.org.
1885 Paul Funk expires April 2005 [Page 32]
1886 \f
1887 Internet-Draft October 2004
1890 Disclaimer of Validity
1892 This document and the information contained herein are provided on
1893 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
1894 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
1895 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
1896 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1897 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1898 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1900 Copyright Statement
1902 Copyright (C) The Internet Society (2001 - 2004). This document is
1903 subject to the rights, licenses and restrictions contained in BCP
1904 78, and except as set forth therein, the authors retain all their
1905 rights.
1907 Acknowledgment
1909 Funding for the RFC Editor function is currently provided by the
1910 Internet Society.
1944 Paul Funk expires April 2005 [Page 33]
1945 \f