| blob | cc63d2e7531f7823985cf8257131b41ad1b8a658 |
4 TLS Working Group P. Funk
5 Internet-Draft Funk Software, Inc.
6 Expires: December 27, 2006 S. Blake-Wilson
7 Basic Commerce & Industries,
8 Inc.
9 N. Smith
10 Intel Corporation
11 H. Tschofenig
12 Siemens
13 T. Hardjono
14 Verisign Inc
15 June 25, 2006
18 TLS Inner Application Extension (TLS/IA)
19 draft-funk-tls-inner-application-extension-03.txt
21 Status of this Memo
23 By submitting this Internet-Draft, each author represents that any
24 applicable patent or other IPR claims of which he or she is aware
25 have been or will be disclosed, and any of which he or she becomes
26 aware will be disclosed, in accordance with Section 6 of BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF), its areas, and its working groups. Note that
30 other groups may also distribute working documents as Internet-
31 Drafts.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 The list of current Internet-Drafts can be accessed at
39 http://www.ietf.org/ietf/1id-abstracts.txt.
41 The list of Internet-Draft Shadow Directories can be accessed at
42 http://www.ietf.org/shadow.html.
44 This Internet-Draft will expire on December 27, 2006.
46 Copyright Notice
48 Copyright (C) The Internet Society (2006).
50 Abstract
55 Funk, et al. Expires December 27, 2006 [Page 1]
56 \f
57 Internet-Draft TLS inner Application June 2006
60 This document defines a new TLS extension called "Inner Application".
61 When TLS is used with the Inner Application extension (TLS/IA),
62 additional messages are exchanged after completion of the TLS
63 handshake, in effect providing an extended handshake prior to the
64 start of upper layer data communications. Each TLS/IA message
65 contains an encrypted sequence of Attribute-Value-Pairs (AVPs) from
66 the RADIUS/Diameter namespace. Hence, the AVPs defined in RADIUS and
67 Diameter have the same meaning in TLS/AI; that is, each attribute
68 code point refers to the same logical attribute in any of these
69 protocols. Arbitrary "applications" may be implemented using the AVP
70 exchange. Possible applications include EAP or other forms of user
71 authentication, client integrity checking, provisioning of additional
72 tunnels, and the like. Use of the RADIUS/Diameter namespace provides
73 natural compatibility between TLS/IA applications and widely deployed
74 AAA infrastructures.
76 It is anticipated that TLS/IA will be used with and without
77 subsequent protected data communication within the tunnel established
78 by the handshake. For example, TLS/IA may be used to secure an HTTP
79 data connection, allowing more robust password-based user
80 authentication to occur than would otherwise be possible using
81 mechanisms available in HTTP. TLS/IA may also be used for its
82 handshake portion alone; for example, EAP-TTLSv1 encapsulates a
83 TLS/IA handshake in EAP as a means to mutually authenticate a client
84 and server and establish keys for a separate data connection.
111 Funk, et al. Expires December 27, 2006 [Page 2]
112 \f
113 Internet-Draft TLS inner Application June 2006
116 Table of Contents
118 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
119 1.1. A bit of History . . . . . . . . . . . . . . . . . . . . . 5
120 1.2. TLS With or Without Upper Layer Data Communications . . . 6
121 2. The Inner Application Extension to TLS . . . . . . . . . . . . 7
122 2.1. TLS/IA Overview . . . . . . . . . . . . . . . . . . . . . 8
123 2.2. Message Exchange . . . . . . . . . . . . . . . . . . . . . 9
124 2.3. Inner Secret . . . . . . . . . . . . . . . . . . . . . . . 10
125 2.3.1. Application Session Key Material . . . . . . . . . . . 11
126 2.4. Session Resumption . . . . . . . . . . . . . . . . . . . . 13
127 2.5. Error Termination . . . . . . . . . . . . . . . . . . . . 13
128 2.6. Negotiating the Inner Application Extension . . . . . . . 13
129 2.7. InnerApplication Protocol . . . . . . . . . . . . . . . . 14
130 2.7.1. InnerApplicationExtension . . . . . . . . . . . . . . 14
131 2.7.2. InnerApplication Message . . . . . . . . . . . . . . . 15
132 2.7.3. IntermediatePhaseFinished and FinalPhaseFinished
133 Messages . . . . . . . . . . . . . . . . . . . . . . . 15
134 2.7.4. The ApplicationPayload Message . . . . . . . . . . . . 16
135 2.8. Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . 16
136 3. Encapsulation of AVPs within ApplicationPayload Messages . . . 18
137 3.1. AVP Format . . . . . . . . . . . . . . . . . . . . . . . . 18
138 3.2. AVP Sequences . . . . . . . . . . . . . . . . . . . . . . 19
139 3.3. Guidelines for Maximum Compatibility with AAA Servers . . 20
140 4. Tunneled Authentication within Application Phases . . . . . . 21
141 4.1. Implicit challenge . . . . . . . . . . . . . . . . . . . . 21
142 4.2. Tunneled Authentication Protocols . . . . . . . . . . . . 22
143 4.2.1. EAP . . . . . . . . . . . . . . . . . . . . . . . . . 22
144 4.2.2. CHAP . . . . . . . . . . . . . . . . . . . . . . . . . 23
145 4.2.3. MS-CHAP . . . . . . . . . . . . . . . . . . . . . . . 23
146 4.2.4. MS-CHAP-V2 . . . . . . . . . . . . . . . . . . . . . . 24
147 4.2.5. PAP . . . . . . . . . . . . . . . . . . . . . . . . . 25
148 4.3. Performing Multiple Authentications . . . . . . . . . . . 26
149 5. Example Message Sequences . . . . . . . . . . . . . . . . . . 27
150 5.1. Full Initial Handshake with Intermediate and Final
151 Application Phasess . . . . . . . . . . . . . . . . . . . 27
152 5.2. Resumed Session with Single Application Phase . . . . . . 29
153 5.3. Resumed Session with No Application Phase . . . . . . . . 29
154 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
155 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
156 7.1. Normative References . . . . . . . . . . . . . . . . . . . 34
157 7.2. Informative References . . . . . . . . . . . . . . . . . . 35
158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
159 Intellectual Property and Copyright Statements . . . . . . . . . . 37
167 Funk, et al. Expires December 27, 2006 [Page 3]
168 \f
169 Internet-Draft TLS inner Application June 2006
172 1. Introduction
174 This specification defines the TLS "Inner Application" extension.
175 The term "TLS/IA" refers to the TLS protocol when used with the Inner
176 Application extension.
178 In TLS/IA, the setup portion of TLS is extended to allow an arbitrary
179 exchange of information between client and server within a protected
180 tunnel established during the TLS handshake and prior to the start of
181 upper layer TLS data communications. The TLS handshake itself is
182 unchanged; the subsequent Inner Application exchange is conducted
183 under the confidentiality and integrity protection that is afforded
184 by the TLS handshake.
186 The primary motivation for providing this facility is to allow robust
187 user authentication to occur as part of an "extended" handshake, in
188 particular, user authentication that is based on password
189 credentials, which is best conducted under the protection of an
190 encrypted tunnel to preclude dictionary attack by eavesdroppers. For
191 example, the Extensible Authentication Protocol (EAP) may be used for
192 authentication using any of a wide variety of methods as part of this
193 extended handshake. The multi-layer approach of TLS/IA, in which a
194 strong authentication, typically based on a server certificate, is
195 used to protected a password-based authentication, distinguishes it
196 from other TLS variants that rely entirely on a pre-shared key or
197 password for security (such as [I-D.ietf-tls-psk]).
199 The protected exchange accommodates any type of client-server
200 application, not just authentication, though authentication may often
201 be the prerequisite for other applications to proceed. For example,
202 TLS/IA may be used to set up HTTP connections, establish IPsec
203 security associations (as an alternative to IKE), obtain credentials
204 for single sign-on, provide client integrity verification, and so on.
206 The new messages that are exchanged between client and server are
207 encoded as sequences of Attribute-Value-Pairs (AVPs) from the RADIUS/
208 Diameter namespace. Use of the RADIUS/Diameter namespace provides
209 natural compatibility between TLS/IA applications and widely deployed
210 AAA infrastructures. This namespace is extensible, allowing new AVPs
211 and, thus, new applications to be defined as needed, either by
212 standards bodies or by vendors wishing to define proprietary
213 applications.
215 The TLS/IA exchange comprises one or more "phases", each of which
216 consists of an arbitrary number of AVP exchanges followed by a
217 confirmation exchange. Authentications occurring in any phase must
218 be confirmed prior to continuing to the next phase. This allows
219 applications to implement security dependencies in which particular
223 Funk, et al. Expires December 27, 2006 [Page 4]
224 \f
225 Internet-Draft TLS inner Application June 2006
228 assurances are required prior to the exchange of additional
229 information.
231 1.1. A bit of History
233 The TLS protocol has its roots in the Netscape SSL protocol, which
234 was originally intended to protect HTTP traffic. It provides either
235 one-way or mutual certificate-based authentication of client and
236 server. In its most typical use in HTTP, the client authenticates
237 the server based on the server's certificate and establishes a tunnel
238 through which HTTP traffic is passed.
240 For the server to authenticate the client within the TLS handshake,
241 the client must have its own certificate. In cases where the client
242 must be authenticated without a certificate, HTTP, not TLS,
243 mechanisms would have to be employed. For example, HTTP headers have
244 been defined to perform user authentications. However, these
245 mechanisms are primitive compared to other mechanisms, most notably
246 EAP, that have been defined for contexts other than HTTP.
247 Furthermore, any mechanisms defined for HTTP cannot be utilized when
248 TLS is used to protect non-HTTP traffic.
250 The TLS protocol has also found an important use in authentication
251 for network access, originally within PPP for dial-up access and
252 later for wireless and wired 802.1X access. Several EAP types have
253 been defined that utilize TLS to perform mutual client-server
254 authentication. The first to appear, EAP-TLS, uses the TLS handshake
255 to authenticate both client and server based on their certificates.
257 Subsequently proposed protocols, such EAP-TTLSv0 and EAP-PEAP,
258 utilize the TLS handshake to allow the client to authenticate the
259 server based on the latter's certificate, and then use the protected
260 channel established by the TLS handshake to perform user
261 authentication, typically based on a password. Such protocols are
262 called "tunneled" EAP protocols. The authentication mechanism used
263 inside the tunnel may itself be EAP, and the tunnel may also be used
264 to convey additional information between client and server.
266 While tunneled authentication would be useful in other contexts
267 besides EAP, the tunneled protocols mentioned above cannot be
268 employed in a more general use of TLS, since the outermost protocol
269 is EAP, not TLS. Furthermore, these protocols use the TLS tunnel to
270 carry authentication exchanges, and thus preclude use of the TLS
271 tunnel for other purposes such as carrying HTTP traffic.
273 TLS/IA provides a means to perform user authentication and other
274 message exchanges between client and server strictly within TLS.
275 TLS/IA can thus be used both for flexible user authentication within
279 Funk, et al. Expires December 27, 2006 [Page 5]
280 \f
281 Internet-Draft TLS inner Application June 2006
284 a TLS session and as a basis for tunneled authentication within EAP.
286 The TLS/IA approach is to insert an additional message exchange
287 between the TLS handshake and the subsequent data communications
288 phase. This message exchange is carried in a new record type, which
289 is distinct from the record type that carries upper layer data.
290 Thus, the data portion of the TLS exchange becomes available for HTTP
291 or another protocol that needs to be secured.
293 1.2. TLS With or Without Upper Layer Data Communications
295 It is anticipated that TLS/IA will be used with and without
296 subsequent protected data communication within the tunnel established
297 by the handshake.
299 For example, TLS/IA may be used to protect an HTTP connection,
300 allowing more robust password-based user authentication to occur
301 within the TLS/IA extended handshake than would otherwise be possible
302 using mechanisms available in HTTP.
304 TLS/IA may also be used for its handshake portion alone. For
305 example, EAP-TTLSv1 encapsulates a TLS/IA extended handshake in EAP
306 as a means to mutually authenticate a client and server and establish
307 keys for a separate data connection; no subsequent TLS data portion
308 is required. Another example might be the use of TLS/IA directly
309 over TCP in order to provide a user with credentials for single
310 sign-on.
335 Funk, et al. Expires December 27, 2006 [Page 6]
336 \f
337 Internet-Draft TLS inner Application June 2006
340 2. The Inner Application Extension to TLS
342 The Inner Application extension to TLS follows the guidelines of
343 [RFC3546].
345 A new extension type is defined for negotiating use of TLS/IA:
346 The InnerApplicationExtension extension type. The client proposes
347 use of this extension by including a InnerApplicationExtension
348 message in its ClientHello handshake message, and the server
349 confirms its use by including a InnerApplicationExtension message
350 in its ServerHello handshake message.
353 A new record type (ContentType) is defined for use in TLS/IA:
354 The InnerApplication record type. This record type carries all
355 messages that are exchanged after the TLS handshake and prior to
356 exchange of data.
359 A new message type is defined for use within the InnerApplication
360 record type:
362 The InnerApplication message. This message may encapsulate any of
363 the three following subtypes:
365 The ApplicationPayload message. This message is used to carry
366 AVP (Attribute-Value Pair) sequences within the TLS/IA extended
367 handshake, in support of client-server applications such as
368 authentication.
370 The IntermediatePhaseFinished message. This message confirms
371 session keys established during the current TLS/IA phase, and
372 indicates that at least one additional phase is to follow.
374 The FinalPhaseFinished message. This message confirms session
375 keys established during the current TLS/IA phase, and indicates
376 that no further phases are to follow.
379 Two new alert codes are defined for use in TLS/IA:
381 The InnerApplicationFailure alert. This error alert allows either
382 party to terminate the TLS/IA extended handshake due to a failure
383 in an application implemented via AVP sequences carried in
384 ApplicationPayload messages.
391 Funk, et al. Expires December 27, 2006 [Page 7]
392 \f
393 Internet-Draft TLS inner Application June 2006
396 The InnerApplicationVerification alert. This error alert allows
397 either party to terminate the TLS/IA extended handshake due to
398 incorrect verification data in a received
399 IntermediatePhaseFinished or FinalPhaseFinished message.
402 The following new assigned numbers are used in TLS/IA:
403 "InnerApplicationExtension" extension type: 37703
404 "InnerApplication" record type: 24
405 "InnerApplicationFailure" alert code: 208
406 "InnerApplicationVerification" alert code: 209
408 [Editor's note: I have not checked these types yet against types
409 defined in RFCs or drafts. The TLS RFC specifies that new record
410 types use the next number after ones already defined; hence I used
411 24, though I don't know if that is already taken.]
413 2.1. TLS/IA Overview
415 In TLS/IA, zero or more "application phases are inserted after the
416 TLS handshake and prior to ordinary data exchange. The last such
417 application phase is called the "final phase"; any application phases
418 prior to the final phase are called "intermediate phases".
419 Intermediate phases are only necessary if interim confirmation of
420 session keys generated during an application phase is desired.
422 Each application phase consists of ApplicationPayload handshake
423 messages exchanged by client and server to implement applications
424 such as authentication, plus concluding messages for cryptographic
425 confirmation. These messages are encapsulated in records with
426 ContentType of InnerApplication. All application phases prior to the
427 final phase use IntermediatePhaseFinished rather than
428 FinalPhaseFinished as the concluding message. The final phase
429 concludes with the FinalPhaseFinished message.
431 Application phases may be omitted entirely only when session
432 resumption is used, provided both client and server agree that no
433 application phase is required. The client indicates in its
434 ClientHello whether it is willing to omit application phases in a
435 resumed session, and the server indicates in its ServerHello whether
436 any application phases are to ensue.
438 In each application phase, the client sends the first
439 ApplicationPayload message. ApplicationPayload messages are then
440 traded one at a time between client and server, until the server
441 concludes the phase by sending, in response to an ApplicationPayload
442 message from the client, an IntermediatePhaseFinished sequence to
443 conclude an intermediate phase, or a FinalPhaseFinished sequence to
447 Funk, et al. Expires December 27, 2006 [Page 8]
448 \f
449 Internet-Draft TLS inner Application June 2006
452 conclude the final phase. The client then responds with its own
453 IntermediatePhaseFinished or FinalPhaseFinished message.
455 Note that the server MUST NOT send an IntermediatePhaseFinished or
456 FinalPhaseFinished message immediately after sending an
457 ApplicationPayload message. It must allow the client to send an
458 ApplicationPayload message prior to concluding the phase. Thus,
459 within any application phase, there will be one more
460 ApplicationPayload message sent by the client than sent by the
461 server.
463 The server determines which type of concluding message is used,
464 either IntermediatePhaseFinished or FinalPhaseFinished, and the
465 client MUST echo the same type of concluding message. Each
466 IntermediatePhaseFinished or FinalPhaseFinished message provides
467 cryptographic confirmation of any session keys generated during the
468 current and any prior applications phases.
470 Each ApplicationPayload message contains opaque data interpreted as
471 an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence
472 contains a typed data element. The exchanged AVPs allow client and
473 server to implement "applications" within a secure tunnel. An
474 application may be any procedure that someone may usefully define. A
475 typical application might be authentication; for example, the server
476 may authenticate the client based on password credentials using EAP.
477 Other possible applications include distribution of keys, validating
478 client integrity, setting up IPsec parameters, setting up SSL VPNs,
479 and so on.
481 An "inner secret" is computed during each application phase that
482 cryptographically combines the TLS master secret with any session
483 keys that have been generated during the current and any previous
484 application phases. At the conclusion of each application phase, a
485 new inner secret is computed a nd is used to create verification data
486 that is exchanged via the IntermediatePhaseFinished or
487 FinalPhaseFinished messages. By mixing session keys of inner
488 authentications with the TLS master secret, certain man-in-the-middle
489 attacks are thwarted [MITM].
491 2.2. Message Exchange
493 Each intermediate application phase consists of ApplicationPayload
494 messages sent alternately by client and server, and a concluding
495 exchange of IntermediatePhaseFinished messages. The first and last
496 ApplicationPayload message in each intermediate phase is sent by the
497 client; the first IntermediatePhaseFinished message is sent by the
498 server. Thus the client begins the exchange with an
499 ApplicationPayload message and the server determines when to conclude
503 Funk, et al. Expires December 27, 2006 [Page 9]
504 \f
505 Internet-Draft TLS inner Application June 2006
508 it by sending IntermediatePhaseFinished. When it receives the
509 server's IntermediatePhaseFinished message, the client sends its own
510 IntermediatePhaseFinished message, followed by an ApplicationPayload
511 message to begin the next handshake phase.
513 The final application proceeds in the same manner as the intermediate
514 phase, except that the FinalPhaseFinished message is sent by the
515 server and echoed by the client, and the client does not send an
516 ApplicationPayload message for the next phase because there is no
517 next phase.
519 At the start of each application phase, the server MUST wait for the
520 client's opening ApplicationPayload message before it sends its own
521 ApplicationPayload message to the client. The client MUST NOT
522 initiate conclusion of an application phase by sending the first
523 IntermediatePhaseFinished or FinalPhaseFinished message; it MUST
524 allow the server to initiate the conclusion of the phase.
526 Note that it is perfectly acceptable for either client or server to
527 send an ApplicationPayload message containing no AVPs. The client,
528 for example, may have no AVPs to send in its first or last
529 ApplicationPayload message during an application phase.
531 2.3. Inner Secret
533 The inner secret is a 48-octet value used to confirm that the
534 endpoints of the TLS handshake are the same entities as the endpoints
535 of the inner authentications that may have been performed during each
536 application phase.
538 The inner secret is initialized to the master secret at the
539 conclusion of the TLS handshake. At the conclusion of each
540 application phase, prior to computing verification data for inclusion
541 in the IntermediatePhaseFinished or FinalPhaseFinished message, each
542 party permutes the inner secret using a PRF that includes session
543 keys produced during the current application phase. The value that
544 results replaces the current inner secret and is used to compute the
545 verification data.
548 inner_secret = PRF(inner_secret,
549 "inner secret permutation",
550 SecurityParameters.server_random +
551 SecurityParameters.client_random +
552 session_key_material) [0..48];
554 session_key_material is the concatenation of session_key vectors,
555 one for each session key generated during the current phase, where:
559 Funk, et al. Expires December 27, 2006 [Page 10]
560 \f
561 Internet-Draft TLS inner Application June 2006
564 opaque session_key<1..2^16-1>;
567 In other words, each session key is prefixed by a 2-octet length to
568 produce the session_key vector.
570 Since multiple session keys may be produced during a single
571 application phase, the following method is used to determine the
572 order of concatenation: Each session key is treated as an unsigned
573 big-endian numeric value, and the set of session keys is ordered from
574 lowest to highest. The session keys are then converted to
575 session_key vectors and concatenated in the determined order to form
576 session_key_material.
578 If no session keys were generated during the current phase,
579 session_key_material will be null.
581 Note that session_key_material itself is not a vector and therefore
582 not prefixed with the length of the entire collection of session_key
583 vectors. Note that, within TLS itself, the inner secret is used for
584 verification only, not for encryption. However, the inner secret
585 resulting from the final application phase may be exported for use as
586 a key from which additional session keys may be derived for arbitrary
587 purposes, including encryption of data communications separate from
588 TLS.
590 An exported inner secret should not be used directly for any
591 cryptographic purpose. Instead, additional keys should be derived
592 from the inner secret, for example by using a PRF. This ensures
593 cryptographic separation between use of the inner secret for session
594 key confirmation and additional use of the inner secret outside
595 TLS/IA.
597 2.3.1. Application Session Key Material
599 Many authentication protocols used today generate session keys that
600 are bound to the authentication. Such keying material is normally
601 intended for use in a subsequent data connection for encryption and
602 validation. For example, EAP-TLS, MS-CHAP-V2, and EAP-MS-CHAP-V2
603 generate session keys.
605 Any session keys generated during an application phase MUST be used
606 to permute the TLS/IA inner secret between one phase and the next,
607 and MUST NOT be used for any other purpose.
609 Each authentication protocol may define how the session key it
610 generates is mapped to an octet sequence of some length for the
611 purpose of TLS/IA mixing. However, for protocols which do not
615 Funk, et al. Expires December 27, 2006 [Page 11]
616 \f
617 Internet-Draft TLS inner Application June 2006
620 specify this (including the multitude of protocols that pre-date
621 TLS/IA) the following rules are defined. The first rule that applies
622 SHALL be the method for determining the session key.
624 If the authentication protocol produces an MSK (as defined in
625 [RFC3784]), the MSK is used as the session key. Note that an MSK
626 is 64 octets.
629 If the authentication protocol maps its keying material to the
630 RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key
631 [RFC2548]], then the keying material for those attributes are
632 concatenated, with MS-MPPE-Recv-Key first (Note that this rule
633 applies to MS-CHAP-V2 and EAP-MS-CHAP-V2.)
636 If the authentication protocol uses a pseudo-random function to
637 generate keying material, that function is used to generate 64
638 octets for use as keying material.
640 Providing verification of the binding of session keys to the TLS
641 master secret is necessary to preclude man-in-the-middle attacks
642 against tunneled authentication protocols, as described in [MITM].
643 In such an attack, an unsuspecting client is induced to perform an
644 untunneled authentication with an attacker posing as a server; the
645 attacker then introduces the authentication protocol into a tunneled
646 authentication protocol, fooling an authentic server into believing
647 that the attacker is the authentic user.
649 By mixing both the TLS master secret and session keys generated
650 during application phase authentication into the inner secret used
651 for application phase verification, such attacks are thwarted, as it
652 guarantees that the same client acted as the endpoint for both the
653 TLS handshake and the application phase authentication. Note that
654 the session keys generated during authentication must be
655 cryptographically bound to the authentication and not derivable from
656 data exchanged during authentication in order for the keying material
657 to be useful in thwarting such attacks.
659 In addition, the fact that the inner secret cryptographically
660 incorporates session keys from application phase authentications
661 provides additional protection when the inner secret is exported for
662 the purpose of generating additional keys for use outside of the TLS
663 exchange. If such an exported secret did not include keying material
664 from inner authentications, an eavesdropper who somehow knew the
665 server's private key could, in an RSA-based handshake, determine the
666 exported secret and hence would be able to compute the additional
667 keys that are based on it. When inner authentication keying
671 Funk, et al. Expires December 27, 2006 [Page 12]
672 \f
673 Internet-Draft TLS inner Application June 2006
676 material, unknown to the attacker, is incorporated into the exported
677 secret, such an attack becomes infeasible.
679 2.4. Session Resumption
681 A TLS/IA initial handshake phase may be resumed using standard
682 mechanisms defined in [RFC2246]. When the TLS session is resumed,
683 client and server may not deem it necessary to exchange AVPs in one
684 or more additional application phases, as the resumption itself may
685 provide the necessary security.
687 The client indicates within the InnerApplicationExtension message in
688 ClientHello whether it requires AVP exchange when session resumption
689 occurs. If it indicates that it does not, then the server may at its
690 option omit application phases and the two parties proceed to upper
691 layer data communications immediately upon completion of the TLS
692 handshake. The server indicates whether application phases are to
693 follow the TLS handshake in its InnerApplication extension message in
694 ServerHello.
696 Note that [RFC3546] specifically states that when session resumption
697 is used, the server MUST ignore any extensions in the ClientHello.
698 However, it is not possible to comply with this requirement for the
699 Inner Application extension, since even in a resumed session it may
700 be necessary to include application phases, and whether they must be
701 included is negotiated in the extension message itself. Therefore,
702 the [RFC3546] provision is explicitly overridden for the single case
703 of the Inner Application extension, which is considered an exception
704 to this rule.
706 A TLS/IA session MAY NOT be resumed if an application phase resulted
707 in failure, even though the TLS handshake itself succeeded. Both
708 client and server MUST NOT save session state for possible future
709 resumption unless the TLS handshake and all subsequent application
710 phases have been successfully executed.
712 2.5. Error Termination
714 The TLS/IA handshake may be terminated by either party sending a
715 fatal alert, following standard TLS procedures.
717 2.6. Negotiating the Inner Application Extension
719 Use of the InnerApplication extension follows [RFC3546]. The client
720 proposes use of this extension by including the
721 InnerApplicationExtension message in the client_hello_extension_list
722 of the extended ClientHello. If this message is included in the
723 ClientHello, the server MAY accept the proposal by including the
727 Funk, et al. Expires December 27, 2006 [Page 13]
728 \f
729 Internet-Draft TLS inner Application June 2006
732 InnerApplicationExtension message in the server_hello_extension_list
733 of the extended ServerHello. If use of this extension is either not
734 proposed by the client or not confirmed by the server, the
735 InnerApplication record type MUST NOT be used.
737 2.7. InnerApplication Protocol
739 All specifications of TLS/IA messages follow the usage defined in
740 [RFC2246].
742 2.7.1. InnerApplicationExtension
745 enum {
746 no(0), yes(1), (255)
747 } AppPhaseOnResumption;
749 struct {
750 AppPhaseOnResumption app_phase_on_resumption;
751 } InnerApplicationExtension;
753 If the client wishes to propose use of the Inner Application
754 extension, it must include the InnerApplicationExtension message in
755 the extension_data vector in the Extension structure in its extended
756 ClientHello message.
758 If the server wishes to confirm use of the Inner Application
759 extension that has been proposed by the client, it must include the
760 InnerApplicationExtension message in the extension_data vector in the
761 Extension structure in its extended ServerHello message. The
762 AppPhaseOnResumption enumeration allow client and server to negotiate
763 an abbreviated, single-phase handshake when session resumption is
764 employed. If the client sets app_phase_on_resumption to "no", and if
765 the server resumes the previous session, then the server MAY set
766 app_phase_on_resumption to "no" in the InnerApplication message it
767 sends to the client. If the server sets app_phase_on_resumption to
768 "no", no application phases occur and the TLS connection proceeds to
769 upper layer data exchange immediately upon conclusion of the TLS
770 handshake.
772 The server MUST set app_phase_on_resumption to "yes" if the client
773 set app_phase_on_resumption to "yes" or if the server does not resume
774 the session. The server MAY set app_phase_on_resumption to "yes" for
775 a resumed session even if the client set app_phase_on_resumption to
776 "no", as the server may have reason to proceed with one or more
777 application phases.
779 If the server sets app_phase_on_resumption to "yes" for a resumed
783 Funk, et al. Expires December 27, 2006 [Page 14]
784 \f
785 Internet-Draft TLS inner Application June 2006
788 session, then the client MUST initiate an application phase at the
789 conclusion of the TLS handshake.
791 The value of app_phase_on_resumption applies to the current handshake
792 only; that is, it is possible for app_phase_on_resumption to have
793 different values in two handshakes that are both resumed from the
794 same original TLS session.
796 2.7.2. InnerApplication Message
799 enum {
800 application_payload(0), intermediate_phase_finished(1),
801 final_phase_finished(2), (255)
802 } InnerApplicationType;
804 struct {
805 InnerApplicationType msg_type;
806 uint24 length;
807 select (InnerApplicationType) {
808 case application_payload: ApplicationPayload;
809 case intermediate_phase_finished:
810 IntermediatePhaseFinished;
811 case final_phase_finished: FinalPhaseFinished;
812 } body;
813 } InnerApplication;
815 The InnerApplication message carries any of the message types defined
816 for the InnerApplication protocol.
818 2.7.3. IntermediatePhaseFinished and FinalPhaseFinished Messages
821 struct {
822 opaque verify_data[12];
823 } PhaseFinished;
825 PhaseFinished IntermediatePhaseFinished;
827 PhaseFinished FinalPhaseFinished;
829 verify_data
830 PRF(inner_secret, finished_label) [0..11];
832 finished_label
833 when sent by the client, the string "client phase finished"
834 when sent by the server, the string "server phase finished"
839 Funk, et al. Expires December 27, 2006 [Page 15]
840 \f
841 Internet-Draft TLS inner Application June 2006
844 The IntermediatePhaseFinished and FinalPhaseFinished messages have
845 the same structure and include verification data based on the current
846 inner secret. IntermediatePhaseFinished is sent by the server and
847 echoed by the client to conclude an intermediate application phase,
848 and FinalPhaseFinished is used in the same manner to conclude the
849 final application phase.
851 2.7.4. The ApplicationPayload Message
853 The ApplicationPayload message carries an AVP sequence during an
854 application handshake phase. It is defined as follows:
856 struct {
857 opaque avps[InnerApplication.length];
858 } ApplicationPayload;
860 avps
861 The AVP sequence, treated as an opaque sequence of octets.
863 InnerApplication.length
864 The length field in the encapsulating InnerApplication
865 message.
867 Note that the "avps" element has its length defined in square bracket
868 rather than angle bracket notation, implying a fixed rather than
869 variable length vector. This avoids having the length of the AVP
870 sequence specified redundantly both in the encapsulating
871 InnerApplication message and as a length prefix in the avps element
872 itself.
874 2.8. Alerts
876 Two new alert codes are defined for use during an application phase.
877 The AlertLevel for either of these alert codes MUST be set to
878 "fatal".
880 InnerApplicationFailure: An InnerApplicationFailure error alert may
881 be sent by either party during an application phase. This indicates
882 that the sending party considers the negotiation to have failed due
883 to an application carried in the AVP sequences, for example, a failed
884 authentication.
886 InnerApplicationVerification: An InnerApplicationVerification error
887 alert is sent by either party during an application phase to indicate
888 that the received IntermediatePhaseFinished or FinalPhaseFinished is
889 invalid.
891 Note that other alerts are possible during an application phase; for
895 Funk, et al. Expires December 27, 2006 [Page 16]
896 \f
897 Internet-Draft TLS inner Application June 2006
900 example, decrypt_error. The InnerApplicationFailure alert relates
901 specifically to the failure of an application implemented via AVP
902 sequences; for example, failure of an EAP or other authentication
903 method, or information passed within the AVP sequence that is found
904 unsatisfactory.
951 Funk, et al. Expires December 27, 2006 [Page 17]
952 \f
953 Internet-Draft TLS inner Application June 2006
956 3. Encapsulation of AVPs within ApplicationPayload Messages
958 During application phases of the TLS handshake, information is
959 exchanged between client and server through the use of attribute-
960 value pairs (AVPs). This data is encrypted using the current cipher
961 state.
963 The AVP format chosen for TLS/IA is compatible with the Diameter AVP
964 format. This does not in any way represent a requirement that
965 Diameter be supported by any of the devices or servers participating
966 in the TLS/IA conversation, whether directly as client or server or
967 indirectly as a backend authenticator. Use of this format is merely
968 a convenience. Diameter is a superset of RADIUS and includes the
969 RADIUS attribute namespace by definition, though it does not limit
970 the size of an AVP as does RADIUS. RADIUS, in turn, is a widely
971 deployed AAA protocol and attribute definitions exist for the
972 encapsulation of EAP as well as all commonly used non-EAP password
973 authentication protocols.
975 Thus, Diameter is not considered normative except as specified in
976 this document. Specifically, the AVP Codes used in TLS/IA are
977 semantically equivalent to those defined for Diameter, and, by
978 extension, RADIUS.
980 Use of the RADIUS/Diameter namespace allows a TLS/IA server to
981 translate between AVPs it uses to communicate with clients and the
982 protocol requirements of AAA servers that are widely deployed.
983 Additionally, it provides a well-understood mechanism to allow
984 vendors to extend that namespace for their particular requirements.
986 3.1. AVP Format
988 The format of an AVP is shown below. All items are in network, or
989 big-endian, order; that is, they have most significant octet first.
991 0 1 2 3
992 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
993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
994 | AVP Code |
995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
996 |V M r r r r r r| AVP Length |
997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
998 | Vendor-ID (opt) |
999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1000 | Data ...
1001 +-+-+-+-+-+-+-+-+
1007 Funk, et al. Expires December 27, 2006 [Page 18]
1008 \f
1009 Internet-Draft TLS inner Application June 2006
1012 AVP Code
1014 The AVP Code is four octets and, combined with the Vendor-ID field
1015 if present, identifies the attribute uniquely. The first 256 AVP
1016 numbers represent attributes defined in RADIUS. AVP numbers 256
1017 and above are defined in Diameter.
1019 AVP Flags
1021 The AVP Flags field is one octet, and provides the receiver with
1022 information necessary to interpret the AVP.
1024 The 'V' (Vendor-Specific) bit indicates whether the optional
1025 Vendor-ID field is present. When set to 1, the Vendor-ID field is
1026 present and the AVP Code is interpreted according to the namespace
1027 defined by the vendor indicated in the Vendor-ID field.
1029 The 'M' (Mandatory) bit indicates whether support of the AVP is
1030 required. When set to 0, this indicates that the AVP may be
1031 safely ignored if the receiving party does not understand or
1032 support it. When set to 1, if the receiving party does not
1033 understand or support the AVP it MUST fail the negotiation by
1034 sending an InnerApplicationFailure error alert. The 'r'
1035 (reserved) bits are unused and must be set to 0.
1037 AVP Length
1039 The AVP Length field is three octets, and indicates the length of
1040 this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID
1041 (if present) and Data.
1043 Vendor-ID
1045 The Vendor-ID field is present if and only if the 'V' bit is set
1046 in the AVP Flags field. It is four octets, and contains the
1047 vendor's IANA-assigned "SMI Network Management Private Enterprise
1048 Codes" [RFC1700] value. Vendors defining their own AVPs must
1049 maintain a consistent namespace for use of those AVPs within
1050 RADIUS, Diameter and TLS/IA. A Vendor-ID value of zero is
1051 semantically equivalent to absence of the Vendor-ID field
1052 altogether.
1055 3.2. AVP Sequences
1057 Data encapsulated within the TLS Record Layer must consist entirely
1058 of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet
1059 boundary relative to the first AVP in the sequence. If an AVP is not
1063 Funk, et al. Expires December 27, 2006 [Page 19]
1064 \f
1065 Internet-Draft TLS inner Application June 2006
1068 a multiple of 4 octets, it must be padded with 0s to the next 4-octet
1069 boundary. Note that the AVP Length does not include the padding.
1072 3.3. Guidelines for Maximum Compatibility with AAA Servers
1074 When maximum compatibility with AAA servers is desired, the following
1075 guidelines for AVP usage are suggested:
1076 Non-vendor-specific AVPs should be selected from the set of
1077 attributes defined for RADIUS; that is, attributes with codes less
1078 than 256. This provides compatibility with both RADIUS and
1079 Diameter.
1080 Vendor-specific AVPs should be defined in terms of RADIUS.
1081 Vendor-specific RADIUS attributes translate to Diameter
1082 automatically; the reverse is not true. RADIUS vendor-specific
1083 attributes use RADIUS attribute 26 and include vendor ID, vendor-
1084 specific attribute code and length; see[RFC2865] for details.
1119 Funk, et al. Expires December 27, 2006 [Page 20]
1120 \f
1121 Internet-Draft TLS inner Application June 2006
1124 4. Tunneled Authentication within Application Phases
1126 TLS/IA permits user authentication information to be tunneled within
1127 an application phase between client and server, protecting the
1128 authentication information against active and passive attack.
1130 Any type of authentication method may be tunneled. Also, multiple
1131 tunneled authentications may be performed. Normally, tunneled
1132 authentication is used when the TLS handshake provides only one-way
1133 authentication of the server to the client; however, in certain cases
1134 it may be desirable to perform certificate authentication of the
1135 client during the initial handshake phase as well as tunneled user
1136 authentication in a subsequent application phase.
1138 This section establishes rules for using well known authentication
1139 mechanisms within TLS/IA. Any new authentication mechanism should,
1140 in general, be covered by these rules if it is defined as an EAP
1141 type. Authentication mechanisms whose use within TLS/IA is not
1142 covered within this specification may require separate
1143 standardization, preferably within the standard that describes the
1144 authentication mechanism in question.
1146 4.1. Implicit challenge
1148 Certain authentication protocols that use a challenge/response
1149 mechanism rely on challenge material that is not generated by the
1150 authentication server, and therefore require special handling.
1152 In PPP protocols such CHAP, MS-CHAP and MS-CHAP-V2, for example, the
1153 Network Access Server (NAS) issues a challenge to the client, the
1154 client then hashes the challenge with the password and forwards the
1155 response to the NAS. The NAS then forwards both challenge and
1156 response to a AAA server. But because the AAA server did not itself
1157 generate the challenge, such protocols are susceptible to replay
1158 attack.
1160 Since within TLS/IA the client also plays the role of NAS, the replay
1161 problem is exacerbated. If the client were able to create both
1162 challenge and response, anyone able to observe a CHAP or MS-CHAP
1163 exchange could pose as that user by replaying that challenge and
1164 response into a TLS/IA conversation.
1166 To make these protocols secure in TLS/IA, it is necessary to provide
1167 a mechanism that produces a challenge that the client cannot control
1168 or predict. When a challenge-based authentication mechanism is used,
1169 both client and server use the TLS PRF function to generate as many
1170 octets as are required for the challenge, using the constant string
1171 "inner application challenge", based on the master secret and random
1175 Funk, et al. Expires December 27, 2006 [Page 21]
1176 \f
1177 Internet-Draft TLS inner Application June 2006
1180 values established during the TLS handshake, as follows.
1182 IA_challenge = PRF(SecurityParameters.master_secret,
1183 "inner application challenge",
1184 SecurityParameters.server_random +
1185 SecurityParameters.client_random);
1187 4.2. Tunneled Authentication Protocols
1189 This section describes the rules for tunneling specific
1190 authentication protocols within TLS/IA. For each protocol, the
1191 RADIUS RFC that defines the relevant attribute formats is cited.
1192 Note that these attributes are encapsulated as described in section
1193 3.1; that is, as Diameter attributes, not as RADIUS attributes. In
1194 other words, the AVP Code, Length, Flags and optional Vendor-ID are
1195 formatted as described in section 3.1, while the Data is formatted as
1196 described by the cited RADIUS RFC.
1198 All tunneled authentication protocols except EAP must be initiated by
1199 the client in the first ApplicationPayload message of an application
1200 phase. EAP may be initiated by the client in the first
1201 ApplicationPayload message of an application phase; it may also be
1202 initiated by the server in any ApplicationPayload message.
1204 The authentication protocols described below may be performed
1205 directly by the TLS/IA server or may be forwarded to a backend AAA
1206 server. For authentication protocols that generate session keys, the
1207 backend server must return those session keys to the TLS/IA server in
1208 order to allow the protocol to succeed within TLS/IA. RADIUS or
1209 Diameter servers are suitable backend AAA servers for this purpose.
1210 RADIUS servers typically return session keys in MS-MPPE-Recv-Key and
1211 MS-MPPE-Send-Key attributes [RFC2548]; Diameter servers return
1212 session keys in the EAP-Master-Session-Key AVP [I-D.ietf-aaa-eap].
1214 4.2.1. EAP
1216 EAP is described in [RFC3784]; RADIUS attribute formats are described
1217 in [RFC3579]. When EAP is the tunneled authentication protocol, each
1218 tunneled EAP packet between the client and server is encapsulated in
1219 an EAP-Message AVP. Either the client or the server may initiate
1220 EAP.
1222 The client is the first to transmit within any application phase, and
1223 it may include an EAP-Response/Identity AVP in its ApplicationPayload
1224 message to begin an EAP conversation. Alternatively, if the client
1225 does not initiate EAP the server may, by including an EAP-Request/
1226 Identity AVP in its ApplicationPayload message. The client's EAP-
1227 Response/Identity provides the username, which MUST be a Network
1231 Funk, et al. Expires December 27, 2006 [Page 22]
1232 \f
1233 Internet-Draft TLS inner Application June 2006
1236 Access Identifier (NAI) [RFC2486]; that is, it MUST be in the
1237 following format: username@realm
1239 The @realm portion is optional, and is used to allow the server to
1240 forward the EAP message sequence to the appropriate server in the AAA
1241 infrastructure when necessary.
1243 The EAP authentication between client and server proceeds normally,
1244 as described in [RFC3784]. However, upon completion the server does
1245 not send an EAP-Success or EAP-Failure AVP. Instead, the server
1246 signals success when it concludes the application phase by issuing a
1247 Finished or PhaseFinished message, or it signals failure by issuing
1248 an InnerApplicationFailure alert.
1250 Note that the client may also issue an InnerApplicationFailure alert,
1251 for example, when authentication of the server fails in a method
1252 providing mutual authentication.
1254 4.2.2. CHAP
1256 The CHAP algorithm is described in [RFC1994]; RADIUS attribute
1257 formats are described in [RFC2865].
1259 Both client and server generate 17 octets of challenge material,
1260 using the constant string "inner application challenge" as described
1261 above. These octets are used as follows:
1262 CHAP-Challenge [16 octets]
1263 CHAP Identifier [1 octet]
1265 The client initiates CHAP by including User-Name, CHAP-Challenge and
1266 CHAP-Password AVPs in the first ApplicationPayload message in any
1267 application phase. The CHAP-Challenge value is taken from the
1268 challenge material. The CHAP-Password consists of CHAP Identifier,
1269 taken from the challenge material; and CHAP response, computed
1270 according to the CHAP algorithm.
1272 Upon receipt of these AVPs from the client, the server must verify
1273 that the value of the CHAP-Challenge AVP and the value of the CHAP
1274 Identifier in the CHAP-Password AVP are equal to the values generated
1275 as challenge material. If either item does not match, the server
1276 must reject the client. Otherwise, it validates the CHAP-Challenge
1277 to determine the result of the authentication.
1279 4.2.3. MS-CHAP
1281 The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute
1282 formats are described in [RFC2548].
1287 Funk, et al. Expires December 27, 2006 [Page 23]
1288 \f
1289 Internet-Draft TLS inner Application June 2006
1292 Both client and server generate 9 octets of challenge material, using
1293 the constant string "inner application challenge" as described above.
1294 These octets are used as follows:
1295 MS-CHAP-Challenge [8 octets]
1296 Ident [1 octet]
1298 The client initiates MS-CHAP by including User-Name, MS-CHAP-
1299 Challenge and MS-CHAP-Response AVPs in the first ApplicationPayload
1300 message in any application phase. The MS-CHAP-Challenge value is
1301 taken from the challenge material. The MS-CHAP-Response consists of
1302 Ident, taken from the challenge material; Flags, set according the
1303 client preferences; and LM-Response and NT-Response, computed
1304 according to the MS-CHAP 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-CHAP-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-CHAP-Challenge to determine the result of the authentication.
1313 4.2.4. MS-CHAP-V2
1315 The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute
1316 formats are described in [RFC2548].
1318 Both client and server generate 17 octets of challenge material,
1319 using the constant string "inner application challenge" as described
1320 above. These octets are used as follows:
1321 MS-CHAP-Challenge [16 octets]
1322 Ident [1 octet]
1324 The client initiates MS-CHAP-V2 by including User-Name, MS-CHAP-
1325 Challenge and MS-CHAP2-Response AVPs in the first ApplicationPayload
1326 message in any application phase. The MS-CHAP-Challenge value is
1327 taken from the challenge material. The MS-CHAP2-Response consists of
1328 Ident, taken from the challenge material; Flags, set to 0; Peer-
1329 Challenge, set to a random value; and Response, computed according to
1330 the MS-CHAP-V2 algorithm.
1332 Upon receipt of these AVPs from the client, the server must verify
1333 that the value of the MS-CHAP-Challenge AVP and the value of the
1334 Ident in the client's MS-CHAP2-Response AVP are equal to the values
1335 generated as challenge material. If either item does not match
1336 exactly, the server must reject the client. Otherwise, it validates
1337 the MS-CHAP2-Challenge.
1339 If the MS-CHAP2-Challenge received from the client is correct, the
1343 Funk, et al. Expires December 27, 2006 [Page 24]
1344 \f
1345 Internet-Draft TLS inner Application June 2006
1348 server tunnels the MS-CHAP2-Success AVP to the client.
1350 Upon receipt of the MS-CHAP2-Success AVP, the client is able to
1351 authenticate the server. In its next InnerApplicationPayload message
1352 to the server, the client does not include any MS-CHAP-V2 AVPs.
1353 (This may result in an empty InnerApplicationPayload if no other AVPs
1354 need to be sent.)
1356 If the MS-CHAP2-Challenge received from the client is not correct,
1357 the server tunnels an MS-CHAP2-Error AVP to the client. This AVP
1358 contains a new Ident and a string with additional information such as
1359 error reason and whether a retry is allowed. If the error reason is
1360 an expired password and a retry is allowed, the client may proceed to
1361 change the user's password. If the error reason is not an expired
1362 password or if the client does not wish to change the user's
1363 password, it issues an InnerApplicationFailure alert.
1365 If the client does wish to change the password, it tunnels MS-CHAP-
1366 NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the server.
1367 The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge
1368 received in the MS-CHAP2-Error AVP. The MS-CHAP-Challenge AVP simply
1369 echoes the new Challenge.
1371 Upon receipt of these AVPs from the client, the server must verify
1372 that the value of the MS-CHAP-Challenge AVP and the value of the
1373 Ident in the client's MS-CHAP2-CPW AVP match the values it sent in
1374 the MS-CHAP2-Error AVP. If either item does not match exactly, the
1375 server must reject the client. Otherwise, it validates the MS-CHAP2-
1376 CPW AVP.
1378 If the MS-CHAP2-CPW AVP received from the client is correct, and the
1379 server is able to change the user's password, the server tunnels the
1380 MS-CHAP2-Success AVP to the client and the negotiation proceeds as
1381 described above.
1383 Note that additional AVPs associated with MS-CHAP-V2 may be sent by
1384 the server; for example, MS-CHAP-Domain. The server must tunnel such
1385 authentication-related AVPs along with the MS-CHAP2-Success.
1387 4.2.5. PAP
1389 PAP RADIUS attribute formats are described in [RFC2865].
1391 The client initiates PAP by including User-Name and User-Password
1392 AVPs in the first ApplicationPayload message in any application
1393 phase.
1395 In RADIUS, User-Password is padded with nulls to a multiple of 16
1399 Funk, et al. Expires December 27, 2006 [Page 25]
1400 \f
1401 Internet-Draft TLS inner Application June 2006
1404 octets, then encrypted using a shared secret and other packet
1405 information.
1407 A TLS/IA, however, does not RADIUS-encrypt the password since all
1408 application phase data is already encrypted. The client SHOULD,
1409 however, null-pad the password to a multiple of 16 octets, to
1410 obfuscate its length.
1412 Upon receipt of these AVPs from the client, the server may be able to
1413 decide whether to authenticate the client immediately, or it may need
1414 to challenge the client for more information.
1416 If the server wishes to issue a challenge to the client, it MUST
1417 tunnel the Reply-Message AVP to the client; this AVP normally
1418 contains a challenge prompt of some kind. It may also tunnel
1419 additional AVPs if necessary, such the Prompt AVP. Upon receipt of
1420 the Reply-Message AVPs, the client tunnels User-Name and User-
1421 Password AVPs again, with the User-Password AVP containing new
1422 information in response to the challenge. This process continues
1423 until the server determines the authentication has succeeded or
1424 failed.
1426 4.3. Performing Multiple Authentications
1428 In some cases, it is desirable to perform multiple user
1429 authentications. For example, a server may want first to
1430 authenticate the user by password, then by a hardware token.
1432 The server may perform any number of additional user authentications
1433 using EAP, simply by issuing a EAP-Request with a new protocol type
1434 once the previous authentication has completed.
1436 For example, a server wishing to perform MD5-Challenge followed by
1437 Generic Token Card would first issue an EAP-Request/MD5-Challenge AVP
1438 and receive a response. If the response is satisfactory, it would
1439 then issue EAP-Request/Generic Token Card AVP and receive a response.
1440 If that response were also satisfactory, it would consider the user
1441 authenticated.
1455 Funk, et al. Expires December 27, 2006 [Page 26]
1456 \f
1457 Internet-Draft TLS inner Application June 2006
1460 5. Example Message Sequences
1462 This section presents a variety of possible TLS/IA message sequences.
1463 These examples are not meant to exhaustively depict all possible
1464 scenarios.
1466 Parentheses indicate optional TLS messages. Brackets indicate
1467 optional message exchanges. An ellipsis (. . .) indicates optional
1468 repetition of preceding messages.
1470 5.1. Full Initial Handshake with Intermediate and Final Application
1471 Phasess
1473 The diagram below depicts a full initial handshake phase followed by
1474 two application phases.
1476 Note that the client concludes the intermediate phase and starts the
1477 final phase in an uninterrupted sequence of three messages:
1478 ChangeCipherSpec and PhaseFinished belong to the intermediate phase,
1479 and ApplicationPayload belongs to the final phase.
1511 Funk, et al. Expires December 27, 2006 [Page 27]
1512 \f
1513 Internet-Draft TLS inner Application June 2006
1516 Client Server
1517 ------ ------
1519 *** TLS Handshake:
1520 ClientHello -------->
1521 ServerHello
1522 (Certificate)
1523 ServerKeyExchange
1524 (CertificateRequest)
1525 <-------- ServerHelloDone
1526 (Certificate)
1527 ClientKeyExchange
1528 (CertificateVerify)
1529 ChangeCipherSpec
1530 Finished -------->
1531 ChangeCipherSpec
1532 <-------- Finished
1534 *** Intermediate Phase:
1535 ApplicationPayload -------->
1537 [
1538 <-------- ApplicationPayload
1540 ApplicationPayload -------->
1542 ...
1543 ]
1544 <-------- IntermediatePhaseFinished
1545 IntermediatePhaseFinished
1546 *** Final Phase:
1547 ApplicationPayload -------->
1549 [
1550 <-------- ApplicationPayload
1552 ApplicationPayload -------->
1554 ...
1555 ]
1556 <-------- FinalPhaseFinished
1558 FinalPhaseFinished -------->
1567 Funk, et al. Expires December 27, 2006 [Page 28]
1568 \f
1569 Internet-Draft TLS inner Application June 2006
1572 5.2. Resumed Session with Single Application Phase
1574 The diagram below depicts a resumed session followed by a single
1575 application phase.
1577 Note that the client concludes the initial phase and starts the final
1578 phase in an uninterrupted sequence of three messages:
1579 ChangeCipherSpec and PhaseFinished belong to the initial phase, and
1580 ApplicationPayload belongs to the final phase.
1583 Client Server
1584 ------ ------
1586 *** TLS Handshake:
1587 ClientHello -------->
1588 ServerHello
1589 ChangeCipherSpec
1590 <-------- Finished
1591 ChangeCipherSpec
1592 Finished
1593 *** Final Phase:
1594 ApplicationPayload -------->
1596 [
1597 <-------- ApplicationPayload
1599 ApplicationPayload -------->
1601 ...
1602 ]
1603 <-------- FinalPhaseFinished
1605 FinalPhaseFinished -------->
1609 5.3. Resumed Session with No Application Phase
1611 The diagram below depicts a resumed session without any subsequent
1612 application phase. This will occur if the client indicates in its
1613 ClientInnerApplication message that no application phase is required
1614 and the server concurs. Note that this message sequence is identical
1615 to that of a standard TLS resumed session.
1623 Funk, et al. Expires December 27, 2006 [Page 29]
1624 \f
1625 Internet-Draft TLS inner Application June 2006
1628 Client Server
1629 ------ ------
1631 *** TLS Handshake:
1632 ClientHello -------->
1633 ServerHello
1634 ChangeCipherSpec
1635 <-------- Finished
1636 ChangeCipherSpec
1637 Finished -------->
1679 Funk, et al. Expires December 27, 2006 [Page 30]
1680 \f
1681 Internet-Draft TLS inner Application June 2006
1684 6. Security Considerations
1686 This document introduces a new TLS extension called "Inner
1687 Application". When TLS is used with the Inner Application extension
1688 (TLS/IA), additional messages are exchanged during the TLS handshake.
1689 Hence a number of security issues need to be taken into
1690 consideration. Since the security heavily depends on the information
1691 (called "applications") which are exchanged between the TLS client
1692 and the TLS server as part of the TLS/IA extension we try to classify
1693 them into two categories: The first category considers the case where
1694 the exchange results in the generation of keying material. This is,
1695 for example, the case with certain EAP methods. EAP is one of the
1696 envisioned main "applications". The second category focuses on cases
1697 where no session key is generated. The security treatment of the
1698 latter category is discouraged since it is subject to man-in-the-
1699 middle attacks if the two sessions cannot be bound to each other as
1700 suggested in [MITM].
1702 In the following, we investigate a number of security issues:
1704 Architecture and Trust Model
1706 For many of the use cases in this document we assume that three
1707 functional entities participate in the protocol exchange: TLS
1708 client, TLS server and a AAA infrastructure (typically consisting
1709 of a AAA server and possibly a AAA broker). The protocol exchange
1710 described in this document takes place between the TLS client and
1711 the TLS server. The interaction between the AAA client (which
1712 corresponds to the TLS server) and the AAA server is described in
1713 the respective AAA protocol documents and therefore outside the
1714 scope of this document. The trust model behind this architecture
1715 with respect to the authentication, authorization, session key
1716 establishment and key transport within the AAA infrastructure is
1717 discussed in [I-D.ietf-eap-keying].
1719 Authentication
1721 This document assumes that the TLS server is authenticated to the
1722 TLS client as part of the authentication procedure of the initial
1723 TLS Handshake. This approach is similar to the one chosen with
1724 the EAP support in IKEv2 (see [RFC4306]. Typically, public key
1725 based server authentication is used for this purpose. More
1726 interesting is the client authentication property whereby
1727 information exchanged as part of the Inner Application is used to
1728 authenticate (or authorize) the client. For example, if EAP is
1729 used as an inner application then EAP methods are used to perform
1730 authentication and key agreement between the EAP peer (most likely
1731 the TLS client) and the EAP server (i.e., AAA server).
1735 Funk, et al. Expires December 27, 2006 [Page 31]
1736 \f
1737 Internet-Draft TLS inner Application June 2006
1740 Authorization
1742 Throughout this document it is assumed that the TLS server can be
1743 authorized by the TLS client as a legitimate server as part of the
1744 authentication procedure of the initial TLS Handshake. The entity
1745 acting as TLS client can be authorized either by the TLS server or
1746 by the AAA server (if the authorization decision is offloaded).
1747 Typically, the authenticated identity is used to compute the
1748 authorization decision but credential-based authorization
1749 mechanisms may be used as well.
1751 Man-in-the-Middle Attack
1753 Man-in-the-middle attacks have become a concern with tunneled
1754 authentication protocols because of the discovered vulnerabilities
1755 (see [MITM]) of a missing cryptographic binding between the
1756 independent protocol sessions. This document also proposes a
1757 tunneling protocol, namely individual inner application sessions
1758 are tunneled within a previously executed session. The first
1759 protocol session in this exchange is the initial TLS Handshake.
1760 To avoid man-in-the-middle attacks a number of sections address
1761 how to establish such a cryptographic binding (see Section 2.3).
1763 User Identity Confidentiality
1765 The TLS/IA extension allows splitting the authentication of the
1766 TLS server from the TLS client into two separate sessions. As one
1767 of the advantages, this provides active user identity
1768 confidentiality since the TLS client is able to authenticate the
1769 TLS server and to establish a unilateral authenticated and
1770 confidentiality-protected channel prior to starting the client-
1771 side authentication.
1773 Session Key Establishment
1775 TLS [RFC2246] defines how session key material produced during the
1776 TLS Handshake is generated with the help of a pseudo-random
1777 function to expand it to keying material of the desired length for
1778 later usage in the TLS Record Layer. Section 2.3 gives some
1779 guidelines with regard to the master key generation. Since the
1780 TLS/IA extension supports multiple exchanges whereby each phase
1781 concludes with a generated keying material. In addition to the
1782 keying material established as part of TLS itself, most inner
1783 applications will produce their keying material. For example,
1784 keying material established as part of an EAP method must be
1785 carried from the AAA server to the AAA client. Details are
1786 subject to the specific AAA protocol (for example, EAP usage in
1787 Diameter [I-D.ietf-aaa-eap]).
1791 Funk, et al. Expires December 27, 2006 [Page 32]
1792 \f
1793 Internet-Draft TLS inner Application June 2006
1796 Denial of Service Attacks
1798 This document does not modify the initial TLS Handshake and as
1799 such, does not introduce new vulnerabilities with regard to DoS
1800 attacks. Since the TLS/IA extension allows to postpone the
1801 client-side authentication to a later stage in the protocol phase.
1802 As such, it allows malicious TLS clients to initiate a number of
1803 exchanges while remaining anonymous. As a consequence, state at
1804 the server is allocated and computational efforts are required at
1805 the server side. Since the TLS client cannot be stateless this is
1806 not strictly a DoS attack.
1808 Confidentiality Protection and Dictionary Attack Resistance
1810 Similar to the user identity confidentiality property the usage of
1811 the TLS/IA extension allows to establish a unilateral
1812 authenticated tunnel which is confidentiality protected. This
1813 tunnel protects the inner application information elements to be
1814 protected against active adversaries and therefore provides
1815 resistance against dictionary attacks when password-based
1816 authentication protocols are used inside the tunnel. In general,
1817 information exchanged inside the tunnel experiences
1818 confidentiality protection.
1820 Downgrading Attacks
1822 This document defines a new extension. The TLS client and the TLS
1823 server indicate the capability to support the TLS/IA extension as
1824 part of the client_hello_extension_list and the
1825 server_hello_extension_list payload. More details can be found in
1826 Section 2.6. To avoid downgrading attacks whereby an adversary
1827 removes a capability from the list is avoided by the usage of the
1828 Finish or PhaseFinished message.
1847 Funk, et al. Expires December 27, 2006 [Page 33]
1848 \f
1849 Internet-Draft TLS inner Application June 2006
1852 7. References
1854 7.1. Normative References
1856 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
1857 October 1994.
1859 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
1860 Protocol (CHAP)", RFC 1994, August 1996.
1862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1863 Requirement Levels", BCP 14, RFC 2119, March 1997.
1865 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1866 RFC 2246, January 1999.
1868 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
1869 RFC 2433, October 1998.
1871 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
1872 RFC 2486, January 1999.
1874 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
1875 RFC 2548, March 1999.
1877 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
1878 RFC 2759, January 2000.
1880 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1881 "Remote Authentication Dial In User Service (RADIUS)",
1882 RFC 2865, June 2000.
1884 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
1885 and T. Wright, "Transport Layer Security (TLS)
1886 Extensions", RFC 3546, June 2003.
1888 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
1889 Dial In User Service) Support For Extensible
1890 Authentication Protocol (EAP)", RFC 3579, September 2003.
1892 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
1893 Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
1895 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
1896 System (IS-IS) Extensions for Traffic Engineering (TE)",
1897 RFC 3784, June 2004.
1903 Funk, et al. Expires December 27, 2006 [Page 34]
1904 \f
1905 Internet-Draft TLS inner Application June 2006
1908 7.2. Informative References
1910 [I-D.ietf-aaa-eap]
1911 Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
1912 Authentication Protocol (EAP) Application",
1913 draft-ietf-aaa-eap-10 (work in progress), November 2004.
1915 [I-D.ietf-eap-keying]
1916 Aboba, B., "Extensible Authentication Protocol (EAP) Key
1917 Management Framework", draft-ietf-eap-keying-13 (work in
1918 progress), May 2006.
1920 [I-D.ietf-pppext-eap-ttls]
1921 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
1922 Authentication Protocol (EAP-TTLS)",
1923 draft-ietf-pppext-eap-ttls-05 (work in progress),
1924 July 2004.
1926 [I-D.ietf-tls-psk]
1927 Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
1928 for Transport Layer Security (TLS)", draft-ietf-tls-psk-09
1929 (work in progress), June 2005.
1931 [I-D.josefsson-pppext-eap-tls-eap]
1932 Josefsson, S., Palekar, A., Simon, D., and G. Zorn,
1933 "Protected EAP Protocol (PEAP) Version 2",
1934 draft-josefsson-pppext-eap-tls-eap-10 (work in progress),
1935 October 2004.
1937 [MITM] Asokan, N., Niemi, V., Nyberg, K., and W. Dixon, "Man-in-
1938 the-Middle in Tunneled Authentication", October 2002.
1940 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
1941 RFC 1661, July 1994.
1943 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
1944 Protocol", RFC 2716, October 1999.
1946 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
1947 RFC 4306, December 2005.
1949 [ieee] "IEEE Standards for Local and Metropolitan Area Networks:
1950 Port based Network Access Control", E Std 802.1X-2001,
1951 June 2001.
1959 Funk, et al. Expires December 27, 2006 [Page 35]
1960 \f
1961 Internet-Draft TLS inner Application June 2006
1964 Authors' Addresses
1966 Paul Funk
1967 Funk Software, Inc.
1968 222 Third Street
1969 Cambridge, MA 02142
1970 USA
1972 Phone: +1 617 497-6339
1973 Email: paul@funk.com
1976 Simon Blake-Wilson
1977 Basic Commerce & Industries, Inc.
1978 96 Spadina Ave, Unit 606
1979 Toronto, Ontario M5V 2J6
1980 Canada
1982 Phone: +1 416 214-5961
1983 Email: sblakewilson@bcisse.com
1986 Ned Smith
1987 Intel Corporation.
1988 2111 N.E. 25th Ave.
1989 Hillsboro, OR 97124
1990 USA
1992 Phone: +1 503 264-2692
1993 Email: ned.smith@intel.com
1996 Hannes Tschofenig
1997 Siemens
1998 Otto-Hahn-Ring 6
1999 Munich, Bavaria 81739
2000 Germany
2002 Email: Hannes.Tschofenig@siemens.com
2003 URI: http://www.tschofenig.com
2006 Thomas Hardjono
2007 Verisign Inc
2010 Email: thomas@signacert.com
2015 Funk, et al. Expires December 27, 2006 [Page 36]
2016 \f
2017 Internet-Draft TLS inner Application June 2006
2020 Intellectual Property Statement
2022 The IETF takes no position regarding the validity or scope of any
2023 Intellectual Property Rights or other rights that might be claimed to
2024 pertain to the implementation or use of the technology described in
2025 this document or the extent to which any license under such rights
2026 might or might not be available; nor does it represent that it has
2027 made any independent effort to identify any such rights. Information
2028 on the procedures with respect to rights in RFC documents can be
2029 found in BCP 78 and BCP 79.
2031 Copies of IPR disclosures made to the IETF Secretariat and any
2032 assurances of licenses to be made available, or the result of an
2033 attempt made to obtain a general license or permission for the use of
2034 such proprietary rights by implementers or users of this
2035 specification can be obtained from the IETF on-line IPR repository at
2036 http://www.ietf.org/ipr.
2038 The IETF invites any interested party to bring to its attention any
2039 copyrights, patents or patent applications, or other proprietary
2040 rights that may cover technology that may be required to implement
2041 this standard. Please address the information to the IETF at
2042 ietf-ipr@ietf.org.
2045 Disclaimer of Validity
2047 This document and the information contained herein are provided on an
2048 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2049 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2050 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2051 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2052 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2053 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2056 Copyright Statement
2058 Copyright (C) The Internet Society (2006). This document is subject
2059 to the rights, licenses and restrictions contained in BCP 78, and
2060 except as set forth therein, the authors retain all their rights.
2063 Acknowledgment
2065 Funding for the RFC Editor function is currently provided by the
2066 Internet Society.
2071 Funk, et al. Expires December 27, 2006 [Page 37]
2072 \f