idnits 2.17.00 (12 Aug 2021) /tmp/idnits12448/draft-funk-tls-inner-application-extension-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1542. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1558), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A TLS/IA session MAY NOT be resumed if an application phase resulted in failure, even though the TLS handshake itself succeeded. Both client and server MUST NOT save session state for possible future resumption unless the TLS handshake and all subsequent application phases have been successfully executed. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 5910 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '12' on line 649 == Unused Reference: 'RFC2119' is defined on line 1393, but no explicit reference was found in the text == Unused Reference: 'RFC3588' is defined on line 1424, but no explicit reference was found in the text == Unused Reference: 'RFC1661' is defined on line 1433, but no explicit reference was found in the text == Unused Reference: 'RFC2716' is defined on line 1436, but no explicit reference was found in the text == Unused Reference: 'EAP-TTLS' is defined on line 1439, but no explicit reference was found in the text == Unused Reference: 'EAP-PEAP' is defined on line 1443, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Downref: Normative reference to an Informational RFC: RFC 2433 ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2548 ** Downref: Normative reference to an Informational RFC: RFC 2759 ** Obsolete normative reference: RFC 3546 (Obsoleted by RFC 4366) ** Downref: Normative reference to an Informational RFC: RFC 3579 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-08 == Outdated reference: draft-ietf-tls-psk has been published as RFC 4279 == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-aaa-eap has been published as RFC 4072 Summary: 16 errors (**), 0 flaws (~~), 14 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Paul Funk 3 Internet-Draft Juniper Networks 4 Category: Standards Track Simon Blake-Wilson 5 Basic Commerce & 6 Industries, Inc. 7 Ned Smith 8 Intel Corp. 9 Hannes Tschofenig 10 Siemens AG 11 Thomas Hardjono 12 VeriSign Inc. 13 March 2006 15 TLS Inner Application Extension 16 (TLS/IA) 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). All Rights Reserved. 45 Abstract 47 This document defines a new TLS extension called "Inner 48 Application". When TLS is used with the Inner Application extension 49 (TLS/IA), additional messages are exchanged after completion of the 50 TLS handshake, in effect providing an extended handshake prior to 51 the start of upper layer data communications. Each TLS/IA message 52 contains an encrypted sequence of Attribute-Value-Pairs (AVPs) from 53 the RADIUS/Diameter namespace. Hence, the AVPs defined in RADIUS and 54 Diameter have the same meaning in TLS/AI; that is, each attribute 55 code point refers to the same logical attribute in any of these 56 protocols. Arbitrary "applications" may be implemented using the AVP 57 exchange. Possible applications include EAP or other forms of user 58 authentication, client integrity checking, provisioning of 59 additional tunnels, and the like. Use of the RADIUS/Diameter 60 namespace provides natural compatibility between TLS/IA applications 61 and widely deployed AAA infrastructures. 63 It is anticipated that TLS/IA will be used with and without 64 subsequent protected data communication within the tunnel 65 established by the handshake. For example, TLS/IA may be used to 66 secure an HTTP data connection, allowing more robust password-based 67 user authentication to occur than would otherwise be possible using 68 mechanisms available in HTTP. TLS/IA may also be used for its 69 handshake portion alone; for example, EAP-TTLSv1 encapsulates a 70 TLS/IA handshake in EAP as a means to mutually authenticate a client 71 and server and establish keys for a separate data connection. 73 Table of Contents 75 1 Introduction......................................................3 76 1.1 A Bit of History..............................................4 77 1.2 TLS With or Without Upper Layer Data Communications...........5 78 2 The Inner Application Extension to TLS............................5 79 2.1 TLS/IA Message Exchange.......................................7 80 2.2 Inner Secret..................................................9 81 2.2.1 Application Session Key Material.........................10 82 2.3 Session Resumption...........................................11 83 2.4 Error Termination............................................12 84 2.5 Negotiating the Inner Application Extension..................12 85 2.6 InnerApplication Protocol....................................12 86 2.6.1 InnerApplicationExtension................................12 87 2.6.2 InnerApplication Message.................................13 88 2.6.3 IntermediatePhaseFinished and FinalPhaseFinished Messages13 89 2.6.4 The ApplicationPayload Message...........................14 90 2.7 Alerts .......................................................14 91 3 Encapsulation of AVPs within ApplicationPayload Messages.........15 92 3.1 AVP Format...................................................15 93 3.2 AVP Sequences................................................17 94 3.3 Guidelines for Maximum Compatibility with AAA Servers........17 95 4 Tunneled Authentication within Application Phases................17 96 4.1 Implicit challenge...........................................18 97 4.2 Tunneled Authentication Protocols............................18 98 4.2.1 EAP ......................................................19 99 4.2.2 CHAP .....................................................20 100 4.2.3 MS-CHAP..................................................20 101 4.2.4 MS-CHAP-V2...............................................21 102 4.2.5 PAP ......................................................22 103 4.3 Performing Multiple Authentications..........................23 104 5 Example Message Sequences........................................23 105 5.1 Full Initial Handshake with Intermediate and Final Application 106 Phases 23 107 5.2 Resumed Session with Single Application Phase................24 108 5.3 Resumed Session with No Application Phase....................25 109 6 Security Considerations..........................................25 110 7 References.......................................................28 111 7.1 Normative References.........................................28 112 7.2 Informative References.......................................29 113 8 Authors' Addresses...............................................30 114 9 Intellectual Property Statement..................................31 116 1 Introduction 118 This specification defines the TLS "Inner Application" extension. 119 The term "TLS/IA" refers to the TLS protocol when used with the 120 Inner Application extension. 122 In TLS/IA, the setup portion of TLS is extended to allow an 123 arbitrary exchange of information between client and server within a 124 protected tunnel established during the TLS handshake and prior to 125 the start of upper layer TLS data communications. The TLS handshake 126 itself is unchanged; the subsequent Inner Application exchange is 127 conducted under the confidentiality and integrity protection that is 128 afforded by the TLS handshake. 130 The primary motivation for providing this facility is to allow 131 robust user authentication to occur as part of an "extended" 132 handshake, in particular, user authentication that is based on 133 password credentials, which is best conducted under the protection 134 of an encrypted tunnel to preclude dictionary attack by 135 eavesdroppers. For example, the Extensible Authentication Protocol 136 (EAP) may be used for authentication using any of a wide variety of 137 methods as part of this extended handshake. The multi-layer approach 138 of TLS/IA, in which a strong authentication, typically based on a 139 server certificate, is used to protected a password-based 140 authentication, distinguishes it from other TLS variants that rely 141 entirely on a pre-shared key or password for security (such as [TLS- 142 PSK]). 144 The protected exchange accommodates any type of client-server 145 application, not just authentication, though authentication may 146 often be the prerequisite for other applications to proceed. For 147 example, TLS/IA may be used to set up HTTP connections, establish 148 IPsec security associations (as an alternative to IKE), obtain 149 credentials for single sign-on, provide client integrity 150 verification, and so on. 152 The new messages that are exchanged between client and server are 153 encoded as sequences of Attribute-Value-Pairs (AVPs) from the 154 RADIUS/Diameter namespace. Use of the RADIUS/Diameter namespace 155 provides natural compatibility between TLS/IA applications and 156 widely deployed AAA infrastructures. This namespace is extensible, 157 allowing new AVPs and, thus, new applications to be defined as 158 needed, either by standards bodies or by vendors wishing to define 159 proprietary applications. 161 The TLS/IA exchange comprises one or more "phases", each of which 162 consists of an arbitrary number of AVP exchanges followed by a 163 confirmation exchange. Authentications occurring in any phase must 164 be confirmed prior to continuing to the next phase. This allows 165 applications to implement security dependencies in which particular 166 assurances are required prior to the exchange of additional 167 information. 169 1.1 A Bit of History 171 The TLS protocol has its roots in the Netscape SSL protocol, which 172 was originally intended to protect HTTP traffic. It provides either 173 one-way or mutual certificate-based authentication of client and 174 server. In its most typical use in HTTP, the client authenticates 175 the server based on the server's certificate and establishes a 176 tunnel through which HTTP traffic is passed. 178 For the server to authenticate the client within the TLS handshake, 179 the client must have its own certificate. In cases where the client 180 must be authenticated without a certificate, HTTP, not TLS, 181 mechanisms would have to be employed. For example, HTTP headers have 182 been defined to perform user authentications. However, these 183 mechanisms are primitive compared to other mechanisms, most notably 184 EAP, that have been defined for contexts other than HTTP. 185 Furthermore, any mechanisms defined for HTTP cannot be utilized when 186 TLS is used to protect non-HTTP traffic. 188 The TLS protocol has also found an important use in authentication 189 for network access, originally within PPP for dial-up access and 190 later for wireless and wired 802.1X access. Several EAP types have 191 been defined that utilize TLS to perform mutual client-server 192 authentication. The first to appear, EAP-TLS, uses the TLS handshake 193 to authenticate both client and server based on their certificates. 195 Subsequently proposed protocols, such EAP-TTLSv0 and EAP-PEAP, 196 utilize the TLS handshake to allow the client to authenticate the 197 server based on the latter's certificate, and then use the protected 198 channel established by the TLS handshake to perform user 199 authentication, typically based on a password. Such protocols are 200 called "tunneled" EAP protocols. The authentication mechanism used 201 inside the tunnel may itself be EAP, and the tunnel may also be used 202 to convey additional information between client and server. 204 While tunneled authentication would be useful in other contexts 205 besides EAP, the tunneled protocols mentioned above cannot be 206 employed in a more general use of TLS, since the outermost protocol 207 is EAP, not TLS. Furthermore, these protocols use the TLS tunnel to 208 carry authentication exchanges, and thus preclude use of the TLS 209 tunnel for other purposes such as carrying HTTP traffic. 211 TLS/IA provides a means to perform user authentication and other 212 message exchanges between client and server strictly within TLS. 213 TLS/IA can thus be used both for flexible user authentication within 214 a TLS session and as a basis for tunneled authentication within EAP. 216 The TLS/IA approach is to insert an additional message exchange 217 between the TLS handshake and the subsequent data communications 218 phase. This message exchange is carried in a new record type, which 219 is distinct from the record type that carries upper layer data. 220 Thus, the data portion of the TLS exchange becomes available for 221 HTTP or another protocol that needs to be secured. 223 1.2 TLS With or Without Upper Layer Data Communications 225 It is anticipated that TLS/IA will be used with and without 226 subsequent protected data communication within the tunnel 227 established by the handshake. 229 For example, TLS/IA may be used to protect an HTTP connection, 230 allowing more robust password-based user authentication to occur 231 within the TLS/IA extended handshake than would otherwise be 232 possible using mechanisms available in HTTP. 234 TLS/IA may also be used for its handshake portion alone. For 235 example, EAP-TTLSv1 encapsulates a TLS/IA extended handshake in EAP 236 as a means to mutually authenticate a client and server and 237 establish keys for a separate data connection; no subsequent TLS 238 data portion is required. Another example might be the use of TLS/IA 239 directly over TCP in order to provide a user with credentials for 240 single sign-on. 242 2 The Inner Application Extension to TLS 244 The Inner Application extension to TLS follows the guidelines of 245 [RFC3546]. 247 A new extension type is defined for negotiating use of TLS/IA: 249 - The InnerApplicationExtension extension type. The client proposes 250 use of this extension by including a InnerApplicationExtension 251 message in its ClientHello handshake message, and the server 252 confirms its use by including a InnerApplicationExtension message 253 in its ServerHello handshake message. 255 A new record type (ContentType) is defined for use in TLS/IA: 257 - The InnerApplication record type. This record type carries all 258 messages that are exchanged after the TLS handshake and prior to 259 exchange of data. 261 A new message type is defined for use within the InnerApplication 262 record type: 264 - The InnerApplication message. This message may encapsulate any of 265 the three following subtypes: 267 - The ApplicationPayload message. This message is used to carry 268 AVP (Attribute-Value Pair) sequences within the TLS/IA 269 extended handshake, in support of client-server applications 270 such as authentication. 272 - The IntermediatePhaseFinished message. This message confirms 273 session keys established during the current TLS/IA phase, and 274 indicates that at least one additional phase is to follow. 276 - The FinalPhaseFinished message. This message confirms session 277 keys established during the current TLS/IA phase, and 278 indicates that no further phases are to follow. 280 Two new alert codes are defined for use in TLS/IA: 282 - The InnerApplicationFailure alert. This error alert allows either 283 party to terminate the TLS/IA extended handshake due to a failure 284 in an application implemented via AVP sequences carried in 285 ApplicationPayload messages. 287 - The InnerApplicationVerification alert. This error alert allows 288 either party to terminate the TLS/IA extended handshake due to 289 incorrect verification data in a received 290 IntermediatePhaseFinished or FinalPhaseFinished message. 292 The following new assigned numbers are used in TLS/IA: 294 - "InnerApplicationExtension" extension type: 37703 296 - "InnerApplication" record type: 24 298 - "InnerApplicationFailure" alert code: 208 300 - "InnerApplicationVerification" alert code: 209 302 [Editor's note: I have not checked these types yet against types 303 defined in RFCs or drafts. The TLS RFC specifies that new record 304 types use the next number after ones already defined; hence I used 305 24, though I don't know if that is already taken.] 307 2.1 TLS/IA Message Exchange 309 In TLS/IA, zero or more "application phases are inserted after the 310 TLS handshake and prior to ordinary data exchange. The last such 311 application phase is called the "final phase"; any application 312 phases prior to the final phase are called "intermediate phases". 314 Intermediate phases are only necessary if interim confirmation of 315 session keys generated during an application phase is desired. 317 Each application phase consists of ApplicationPayload handshake 318 messages exchanged by client and server to implement applications 319 such as authentication, plus concluding messages for cryptographic 320 confirmation. These messages are encapsulated in records with 321 ContentType of InnerApplication. 323 All application phases prior to the final phase conclude with an 324 exchange of IntermediatePhaseFinished messages, or conclude with a 325 FinalPhaseFinished message from the server and an 326 IntermediatePhaseFinished message from the client, by which the 327 client indicates its desire to keep the handshake open for one or 328 more additional phases. The final phase concludes with an exchange 329 of FinalPhaseFinished messages. 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, and the server indicates in its ServerHello whether 336 any application phases are to ensue. 338 In each application phase, the client sends the first 339 ApplicationPayload message. ApplicationPayload messages are traded 340 one at a time between client and server, until the server concludes 341 the phase by sending, in response to an ApplicationPayload message 342 from the client, an IntermediatePhaseFinished or FinalPhaseFinished 343 sequence to conclude the phase. The client then responds with its 344 own IntermediatePhaseFinished or FinalPhaseFinished message. 346 The server determines which type of concluding message it wants to 347 use, either IntermediatePhaseFinished or FinalPhaseFinished. If the 348 server sent an IntermediatePhaseFinished, the client MUST respond 349 with an IntermediatePhaseFinished. If the server sent a 350 FinalPhaseFinished, the client MAY respond with a FinalPhaseFinished 351 to complete the handshake, or MAY respond with an 352 IntermediatePhaseFinished to cause the handshake to continue. Thus, 353 conclusion of the entire handshake occurs only when both client and 354 server have been satisfied. 356 Note that the server MUST NOT send an IntermediatePhaseFinished or 357 FinalPhaseFinished 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 At the start of each application phase, the server MUST wait for the 365 client's opening ApplicationPayload message before it sends its own 366 ApplicationPayload message to the client. The client MUST NOT 367 initiate conclusion of an application phase by sending the first 368 IntermediatePhaseFinished or FinalPhaseFinished message; it MUST 369 allow the server to initiate the conclusion of the phase. 371 Each IntermediatePhaseFinished or FinalPhaseFinished message 372 provides cryptographic confirmation of any session keys generated 373 during the current and any prior applications phases. 375 Each ApplicationPayload message contains opaque data interpreted as 376 an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence 377 contains a typed data element. The exchanged AVPs allow client and 378 server to implement "applications" within a secure tunnel. An 379 application may be any procedure that someone may usefully define. A 380 typical application might be authentication; for example, the server 381 may authenticate the client based on password credentials using EAP. 382 Other possible applications include distribution of keys, validating 383 client integrity, setting up IPsec parameters, setting up SSL VPNs, 384 and so on. 386 Note that it is perfectly acceptable for either client or server to 387 send an ApplicationPayload message containing no AVPs. The client, 388 for example, may have no AVPs to send in its first or last 389 ApplicationPayload message during an application phase. 391 An "inner secret" is computed during each application phase that 392 cryptographically combines the TLS master secret with any session 393 keys that have been generated during the current and any previous 394 application phases. At the conclusion of each application phase, a 395 new inner secret is computed and is used to create verification data 396 that is exchanged via the IntermediatePhaseFinished or 397 FinalPhaseFinished messages. By mixing session keys of inner 398 authentications with the TLS master secret, certain man-in-the- 399 middle attacks are thwarted [MITM]. 401 2.2 Inner Secret 403 The inner secret is a 48-octet value used to confirm that the 404 endpoints of the TLS handshake are the same entities as the 405 endpoints of the inner authentications that may have been performed 406 during each application phase. 408 The inner secret is initialized to the master secret at the 409 conclusion of the TLS handshake. At the conclusion of each 410 application phase, prior to computing verification data for 411 inclusion in the IntermediatePhaseFinished or FinalPhaseFinished 412 message, each party permutes the inner secret using a PRF that 413 includes session keys produced during the current application phase. 414 The value that results replaces the current inner secret and is used 415 to compute the verification data. 417 inner_secret = PRF(inner_secret, 418 "inner secret permutation", 419 SecurityParameters.server_random + 420 SecurityParameters.client_random + 421 session_key_material) [0..48]; 423 session_key_material is the concatenation of session_key vectors, 424 one for each session key generated during the current phase, where: 426 opaque session_key<1..2^16-1>; 428 In other words, each session key is prefixed by a 2-octet length to 429 produce the session_key vector. 431 Since multiple session keys may be produced during a single 432 application phase, the following method is used to determine the 433 order of concatenation: Each session key is treated as an unsigned 434 big-endian numeric value, and the set of session keys is ordered 435 from lowest to highest. The session keys are then converted to 436 session_key vectors and concatenated in the determined order to form 437 session_key_material. 439 If no session keys were generated during the current phase, 440 session_key_material will be null. 442 Note that session_key_material itself is not a vector and therefore 443 not prefixed with the length of the entire collection of session_key 444 vectors. 446 Note that, within TLS itself, the inner secret is used for 447 verification only, not for encryption. However, the inner secret 448 resulting from the final application phase may be exported for use 449 as a key from which additional session keys may be derived for 450 arbitrary purposes, including encryption of data communications 451 separate from TLS. 453 An exported inner secret should not be used directly for any 454 cryptographic purpose. Instead, additional keys should be derived 455 from the inner secret, for example by using a PRF. This ensures 456 cryptographic separation between use of the inner secret for session 457 key confirmation and additional use of the inner secret outside 458 TLS/IA. 460 2.2.1 Application Session Key Material 462 Many authentication protocols used today generate session keys that 463 are bound to the authentication. Such keying material is normally 464 intended for use in a subsequent data connection for encryption and 465 validation. For example, EAP-TLS, MS-CHAP-V2, and EAP-MS-CHAP-V2 466 generate session keys. 468 Any session keys generated during an application phase MUST be used 469 to permute the TLS/IA inner secret between one phase and the next, 470 and MUST NOT be used for any other purpose. 472 Each authentication protocol may define how the session key it 473 generates is mapped to an octet sequence of some length for the 474 purpose of TLS/IA mixing. However, for protocols which do not 475 specify this (including the multitude of protocols that pre-date 476 TLS/IA) the following rules are defined. The first rule that applies 477 SHALL be the method for determining the session key. 479 - If the authentication protocol produces an MSK (as defined in 480 [RFC3784]), the MSK is used as the session key. Note that an MSK 481 is 64 octets. 483 - If the authentication protocol maps its keying material to the 484 RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key 485 [RFC2548], then the keying material for those attributes are 486 concatenated, with MS-MPPE-Recv-Key first (Note that this rule 487 applies to MS-CHAP-V2 and EAP-MS-CHAP-V2.) 489 - If the authentication protocol uses a pseudo-random function to 490 generate keying material, that function is used to generate 64 491 octets for use as keying material. 493 Providing verification of the binding of session keys to the TLS 494 master secret is necessary to preclude man-in-the-middle attacks 495 against tunneled authentication protocols, as described in [MITM]. 496 In such an attack, an unsuspecting client is induced to perform an 497 untunneled authentication with an attacker posing as a server; the 498 attacker then introduces the authentication protocol into a tunneled 499 authentication protocol, fooling an authentic server into believing 500 that the attacker is the authentic user. 502 By mixing both the TLS master secret and session keys generated 503 during application phase authentication into the inner secret used 504 for application phase verification, such attacks are thwarted, as it 505 guarantees that the same client acted as the endpoint for both the 506 TLS handshake and the application phase authentication. Note that 507 the session keys generated during authentication must be 508 cryptographically bound to the authentication and not derivable from 509 data exchanged during authentication in order for the keying 510 material to be useful in thwarting such attacks. 512 In addition, the fact that the inner secret cryptographically 513 incorporates session keys from application phase authentications 514 provides additional protection when the inner secret is exported for 515 the purpose of generating additional keys for use outside of the TLS 516 exchange. If such an exported secret did not include keying material 517 from inner authentications, an eavesdropper who somehow knew the 518 server's private key could, in an RSA-based handshake, determine the 519 exported secret and hence would be able to compute the additional 520 keys that are based on it. When inner authentication keying 521 material, unknown to the attacker, is incorporated into the exported 522 secret, such an attack becomes infeasible. 524 2.3 Session Resumption 526 A TLS/IA initial handshake phase may be resumed using standard 527 mechanisms defined in [RFC2246]. When the TLS session is resumed, 528 client and server may not deem it necessary to exchange AVPs in one 529 or more additional application phases, as the resumption itself may 530 provide the necessary security. 532 The client indicates within the InnerApplicationExtension message in 533 ClientHello whether it requires AVP exchange when session resumption 534 occurs. If it indicates that it does not, then the server may at its 535 option omit application phases and the two parties proceed to upper 536 layer data communications immediately upon completion of the TLS 537 handshake. The server indicates whether application phases are to 538 follow the TLS handshake in its InnerApplication extension message 539 in ServerHello. 541 Note that [RFC3546] specifically states that when session resumption 542 is used, the server MUST ignore any extensions in the ClientHello. 543 However, it is not possible to comply with this requirement for the 544 Inner Application extension, since even in a resumed session it may 545 be necessary to include application phases, and whether they must be 546 included is negotiated in the extension message itself. Therefore, 547 the [RFC3546] provision is explicitly overridden for the single case 548 of the Inner Application extension, which is considered an exception 549 to this rule. 551 A TLS/IA session MAY NOT be resumed if an application phase resulted 552 in failure, even though the TLS handshake itself succeeded. Both 553 client and server MUST NOT save session state for possible future 554 resumption unless the TLS handshake and all subsequent application 555 phases have been successfully executed. 557 2.4 Error Termination 559 The TLS/IA handshake may be terminated by either party sending a 560 fatal alert, following standard TLS procedures. 562 2.5 Negotiating the Inner Application Extension 564 Use of the InnerApplication extension follows [RFC3546]. The client 565 proposes use of this extension by including the 566 InnerApplicationExtension message in the client_hello_extension_list 567 of the extended ClientHello. If this message is included in the 568 ClientHello, the server MAY accept the proposal by including the 569 InnerApplicationExtension message in the server_hello_extension_list 570 of the extended ServerHello. If use of this extension is either not 571 proposed by the client or not confirmed by the server, the 572 InnerApplication record type MUST NOT be used. 574 2.6 InnerApplication Protocol 576 All specifications of TLS/IA messages follow the usage defined in 577 [RFC2246]. 579 2.6.1 InnerApplicationExtension 581 enum { 582 no(0), yes(1), (255) 583 } AppPhaseOnResumption; 585 struct { 586 AppPhaseOnResumption app_phase_on_resumption; 587 } InnerApplicationExtension; 589 If the client wishes to propose use of the Inner Application 590 extension, it must include the InnerApplicationExtension message in 591 the extension_data vector in the Extension structure in its extended 592 ClientHello message. 594 If the server wishes to confirm use of the Inner Application 595 extension that has been proposed by the client, it must include the 596 InnerApplicationExtension message in the extension_data vector in 597 the Extension structure in its extended ServerHello message. 599 The AppPhaseOnResumption enumeration allow client and server to 600 negotiate an abbreviated, single-phase handshake when session 601 resumption is employed. If the client sets app_phase_on_resumption 602 to "no", and if the server resumes the previous session, then the 603 server MAY set app_phase_on_resumption to "no" in the 604 InnerApplication message it sends to the client. If the server sets 605 app_phase_on_resumption to "no", no application phases occur and the 606 TLS connection proceeds to upper layer data exchange immediately 607 upon conclusion of the TLS handshake. 609 The server MUST set app_phase_on_resumption to "yes" if the client 610 set app_phase_on_resumption to "yes" or if the server does not 611 resume the session. The server MAY set app_phase_on_resumption to 612 "yes" for a resumed session even if the client set 613 app_phase_on_resumption to "no", as the server may have reason to 614 proceed with one or more application phases. 616 If the server sets app_phase_on_resumption to "yes" for a resumed 617 session, then the client MUST initiate an application phase at the 618 conclusion of the TLS handshake. 620 The value of app_phase_on_resumption applies to the current 621 handshake only; that is, it is possible for app_phase_on_resumption 622 to have different values in two handshakes that are both resumed 623 from the same original TLS session. 625 2.6.2 InnerApplication Message 627 enum { 628 application_payload(0), intermediate_phase_finished(1), 629 final_phase_finished(2), (255) 630 } InnerApplicationType; 632 struct { 633 InnerApplicationType msg_type; 634 uint24 length; 635 select (InnerApplicationType) { 636 case application_payload: ApplicationPayload; 637 case intermediate_phase_finished: 638 IntermediatePhaseFinished; 639 case final_phase_finished: FinalPhaseFinished; 640 } body; 641 } InnerApplication; 643 The InnerApplication message carries any of the message types 644 defined for the InnerApplication protocol. 646 2.6.3 IntermediatePhaseFinished and FinalPhaseFinished Messages 648 struct { 649 opaque verify_data[12]; 650 } PhaseFinished; 652 PhaseFinished IntermediatePhaseFinished; 654 PhaseFinished FinalPhaseFinished; 655 verify_data 656 PRF(inner_secret, finished_label) [0..11]; 658 finished_label 659 when sent by the client, the string "client phase finished" 660 when sent by the server, the string "server phase finished" 662 The IntermediatePhaseFinished and FinalPhaseFinished messages have 663 the same structure and include verification data based on the 664 current inner secret. IntermediatePhaseFinished is sent by the 665 server and echoed by the client to conclude an intermediate 666 application phase, and FinalPhaseFinished is used in the same manner 667 to conclude the final application phase. 669 2.6.4 The ApplicationPayload Message 671 The ApplicationPayload message carries an AVP sequence during an 672 application handshake phase. It is defined as follows: 674 struct { 675 opaque avps[InnerApplication.length]; 676 } ApplicationPayload; 678 avps 679 The AVP sequence, treated as an opaque sequence of octets. 681 InnerApplication.length 682 The length field in the encapsulating InnerApplication 683 message. 685 Note that the "avps" element has its length defined in square 686 bracket rather than angle bracket notation, implying a fixed rather 687 than variable length vector. This avoids having the length of the 688 AVP sequence specified redundantly both in the encapsulating 689 InnerApplication message and as a length prefix in the avps element 690 itself. 692 2.7 Alerts 694 Two new alert codes are defined for use during an application phase. 695 The AlertLevel for either of these alert codes MUST be set to 696 "fatal". 698 InnerApplicationFailure 699 An InnerApplicationFailure error alert may be sent by either 700 party during an application phase. This indicates that the 701 sending party considers the negotiation to have failed due to an 702 application carried in the AVP sequences, for example, a failed 703 authentication. 705 InnerApplicationVerification 706 An InnerApplicationVerification error alert is sent by either 707 party during an application phase to indicate that the received 708 IntermediatePhaseFinished or FinalPhaseFinished is invalid. 710 Note that other alerts are possible during an application phase; for 711 example, decrypt_error. The InnerApplicationFailure alert relates 712 specifically to the failure of an application implemented via AVP 713 sequences; for example, failure of an EAP or other authentication 714 method, or information passed within the AVP sequence that is found 715 unsatisfactory. 717 3 Encapsulation of AVPs within ApplicationPayload Messages 719 During application phases of the TLS handshake, information is 720 exchanged between client and server through the use of attribute- 721 value pairs (AVPs). This data is encrypted using the current cipher 722 state. 724 The AVP format chosen for TLS/IA is compatible with the Diameter AVP 725 format. This does not in any way represent a requirement that 726 Diameter be supported by any of the devices or servers participating 727 in the TLS/IA conversation, whether directly as client or server or 728 indirectly as a backend authenticator. Use of this format is merely 729 a convenience. Diameter is a superset of RADIUS and includes the 730 RADIUS attribute namespace by definition, though it does not limit 731 the size of an AVP as does RADIUS. RADIUS, in turn, is a widely 732 deployed AAA protocol and attribute definitions exist for the 733 encapsulation of EAP as well as all commonly used non-EAP password 734 authentication protocols. 736 Thus, Diameter is not considered normative except as specified in 737 this document. Specifically, the AVP Codes used in TLS/IA are 738 semantically equivalent to those defined for Diameter, and, by 739 extension, RADIUS. 741 Use of the RADIUS/Diameter namespace allows a TLS/IA server to 742 translate between AVPs it uses to communicate with clients and the 743 protocol requirements of AAA servers that are widely deployed. 744 Additionally, it provides a well-understood mechanism to allow 745 vendors to extend that namespace for their particular requirements. 747 3.1 AVP Format 749 The format of an AVP is shown below. All items are in network, or 750 big-endian, order; that is, they have most significant octet first. 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | AVP Code | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 |V M r r r r r r| AVP Length | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Vendor-ID (opt) | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Data ... 762 +-+-+-+-+-+-+-+-+ 764 AVP Code 766 The AVP Code is four octets and, combined with the Vendor-ID 767 field if present, identifies the attribute uniquely. The first 768 256 AVP numbers represent attributes defined in RADIUS. AVP 769 numbers 256 and above are defined in Diameter. 771 AVP Flags 773 The AVP Flags field is one octet, and provides the receiver with 774 information necessary to interpret the AVP. 776 The 'V' (Vendor-Specific) bit indicates whether the optional 777 Vendor-ID field is present. When set to 1, the Vendor-ID field is 778 present and the AVP Code is interpreted according to the 779 namespace defined by the vendor indicated in the Vendor-ID field. 781 The 'M' (Mandatory) bit indicates whether support of the AVP is 782 required. When set to 0, this indicates that the AVP may be 783 safely ignored if the receiving party does not understand or 784 support it. When set to 1, if the receiving party does not 785 understand or support the AVP it MUST fail the negotiation by 786 sending an InnerApplicationFailure error alert. 788 The 'r' (reserved) bits are unused and must be set to 0. 790 AVP Length 792 The AVP Length field is three octets, and indicates the length of 793 this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID 794 (if present) and Data. 796 Vendor-ID 798 The Vendor-ID field is present if and only if the 'V' bit is set 799 in the AVP Flags field. It is four octets, and contains the 800 vendor's IANA-assigned "SMI Network Management Private Enterprise 801 Codes" [RFC1700] value. Vendors defining their own AVPs must 802 maintain a consistent namespace for use of those AVPs within 803 RADIUS, Diameter and TLS/IA. 805 A Vendor-ID value of zero is semantically equivalent to absence 806 of the Vendor-ID field altogether. 808 3.2 AVP Sequences 810 Data encapsulated within the TLS Record Layer must consist entirely 811 of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet 812 boundary relative to the first AVP in the sequence. If an AVP is not 813 a multiple of 4 octets, it must be padded with 0s to the next 4- 814 octet boundary. 816 Note that the AVP Length does not include the padding. 818 3.3 Guidelines for Maximum Compatibility with AAA Servers 820 When maximum compatibility with AAA servers is desired, the 821 following guidelines for AVP usage are suggested: 823 - Non-vendor-specific AVPs should be selected from the set of 824 attributes defined for RADIUS; that is, attributes with codes 825 less than 256. This provides compatibility with both RADIUS and 826 Diameter. 828 - Vendor-specific AVPs should be defined in terms of RADIUS. 829 Vendor-specific RADIUS attributes translate to Diameter 830 automatically; the reverse is not true. RADIUS vendor-specific 831 attributes use RADIUS attribute 26 and include vendor ID, vendor- 832 specific attribute code and length; see [RFC2865] for details. 834 4 Tunneled Authentication within Application Phases 836 TLS/IA permits user authentication information to be tunneled within 837 an application phase between client and server, protecting the 838 authentication information against active and passive attack. 840 Any type of authentication method may be tunneled. Also, multiple 841 tunneled authentications may be performed. Normally, tunneled 842 authentication is used when the TLS handshake provides only one-way 843 authentication of the server to the client; however, in certain 844 cases it may be desirable to perform certificate authentication of 845 the client during the initial handshake phase as well as tunneled 846 user authentication in a subsequent application phase. 848 This section establishes rules for using well known authentication 849 mechanisms within TLS/IA. Any new authentication mechanism should, 850 in general, be covered by these rules if it is defined as an EAP 851 type. Authentication mechanisms whose use within TLS/IA is not 852 covered within this specification may require separate 853 standardization, preferably within the standard that describes the 854 authentication mechanism in question. 856 4.1 Implicit challenge 858 Certain authentication protocols that use a challenge/response 859 mechanism rely on challenge material that is not generated by the 860 authentication server, and therefore require special handling. 862 In PPP protocols such CHAP, MS-CHAP and MS-CHAP-V2, for example, the 863 Network Access Server (NAS) issues a challenge to the client, the 864 client then hashes the challenge with the password and forwards the 865 response to the NAS. The NAS then forwards both challenge and 866 response to a AAA server. But because the AAA server did not itself 867 generate the challenge, such protocols are susceptible to replay 868 attack. 870 Since within TLS/IA the client also plays the role of NAS, the 871 replay problem is exacerbated. If the client were able to create 872 both challenge and response, anyone able to observe a CHAP or MS- 873 CHAP exchange could pose as that user by replaying that challenge 874 and response into a TLS/IA conversation. 876 To make these protocols secure in TLS/IA, it is necessary to provide 877 a mechanism that produces a challenge that the client cannot control 878 or predict. 880 When a challenge-based authentication mechanism is used, both client 881 and server use the TLS PRF function to generate as many octets as 882 are required for the challenge, using the constant string "inner 883 application challenge", based on the master secret and random values 884 established during the TLS handshake, as follows. 886 IA_challenge = PRF(SecurityParameters.master_secret, 887 "inner application challenge", 888 SecurityParameters.server_random + 889 SecurityParameters.client_random); 891 4.2 Tunneled Authentication Protocols 893 This section describes the rules for tunneling specific 894 authentication protocols within TLS/IA. 896 For each protocol, the RADIUS RFC that defines the relevant 897 attribute formats is cited. Note that these attributes are 898 encapsulated as described in section 3.1; that is, as Diameter 899 attributes, not as RADIUS attributes. In other words, the AVP Code, 900 Length, Flags and optional Vendor-ID are formatted as described in 901 section 3.1, while the Data is formatted as described by the cited 902 RADIUS RFC. 904 All tunneled authentication protocols except EAP must be initiated 905 by the client in the first ApplicationPayload message of an 906 application phase. EAP may be initiated by the client in the first 907 ApplicationPayload message of an application phase; it may also be 908 initiated by the server in any ApplicationPayload message. 910 The authentication protocols described below may be performed 911 directly by the TLS/IA server or may be forwarded to a backend AAA 912 server. For authentication protocols that generate session keys, the 913 backend server must return those session keys to the TLS/IA server 914 in order to allow the protocol to succeed within TLS/IA. RADIUS or 915 Diameter servers are suitable backend AAA servers for this purpose. 916 RADIUS servers typically return session keys in MS-MPPE-Recv-Key and 917 MS-MPPE-Send-Key attributes [RFC2548]; Diameter servers return 918 session keys in the EAP-Master-Session-Key AVP [AAA-EAP]. 920 4.2.1 EAP 922 EAP is described in [RFC3784]; RADIUS attribute formats are 923 described in [RFC3579]. 925 When EAP is the tunneled authentication protocol, each tunneled EAP 926 packet between the client and server is encapsulated in an EAP- 927 Message AVP. 929 Either the client or the server may initiate EAP. 931 The client is the first to transmit within any application phase, 932 and it may include an EAP-Response/Identity AVP in its 933 ApplicationPayload message to begin an EAP conversation. 934 Alternatively, if the client does not initiate EAP the server may, 935 by including an EAP-Request/Identity AVP in its ApplicationPayload 936 message. 938 The client's EAP-Response/Identity provides the username, which MUST 939 be a Network Access Identifier (NAI) [RFC2486]; that is, it MUST be 940 in the following format: 942 username@realm 944 The @realm portion is optional, and is used to allow the server to 945 forward the EAP message sequence to the appropriate server in the 946 AAA infrastructure when necessary. 948 The EAP authentication between client and server proceeds normally, 949 as described in [RFC3784]. However, upon completion the server does 950 not send an EAP-Success or EAP-Failure AVP. Instead, the server 951 signals success when it concludes the application phase by issuing a 952 Finished or PhaseFinished message, or it signals failure by issuing 953 an InnerApplicationFailure alert. 955 Note that the client may also issue an InnerApplicationFailure 956 alert, for example, when authentication of the server fails in a 957 method providing mutual authentication. 959 4.2.2 CHAP 961 The CHAP algorithm is described in [RFC1994]; RADIUS attribute 962 formats are described in [RFC2865]. 964 Both client and server generate 17 octets of challenge material, 965 using the constant string "inner application challenge" as described 966 above. These octets are used as follows: 968 CHAP-Challenge [16 octets] 969 CHAP Identifier [1 octet] 971 The client initiates CHAP by including User-Name, CHAP-Challenge and 972 CHAP-Password AVPs in the first ApplicationPayload message in any 973 application phase. The CHAP-Challenge value is taken from the 974 challenge material. The CHAP-Password consists of CHAP Identifier, 975 taken from the challenge material; and CHAP response, computed 976 according to the CHAP algorithm. 978 Upon receipt of these AVPs from the client, the server must verify 979 that the value of the CHAP-Challenge AVP and the value of the CHAP 980 Identifier in the CHAP-Password AVP are equal to the values 981 generated as challenge material. If either item does not match, the 982 server must reject the client. Otherwise, it validates the CHAP- 983 Challenge to determine the result of the authentication. 985 4.2.3 MS-CHAP 987 The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute 988 formats are described in [RFC2548]. 990 Both client and server generate 9 octets of challenge material, 991 using the constant string "inner application challenge" as described 992 above. These octets are used as follows: 994 MS-CHAP-Challenge [8 octets] 995 Ident [1 octet] 997 The client initiates MS-CHAP by including User-Name, MS-CHAP- 998 Challenge and MS-CHAP-Response AVPs in the first ApplicationPayload 999 message in any application phase. The MS-CHAP-Challenge value is 1000 taken from the challenge material. The MS-CHAP-Response consists of 1001 Ident, taken from the challenge material; Flags, set according the 1002 client preferences; and LM-Response and NT-Response, computed 1003 according to the MS-CHAP algorithm. 1005 Upon receipt of these AVPs from the client, the server must verify 1006 that the value of the MS-CHAP-Challenge AVP and the value of the 1007 Ident in the client's MS-CHAP-Response AVP are equal to the values 1008 generated as challenge material. If either item does not match 1009 exactly, the server must reject the client. Otherwise, it validates 1010 the MS-CHAP-Challenge to determine the result of the authentication. 1012 4.2.4 MS-CHAP-V2 1014 The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute 1015 formats are described in [RFC2548]. 1017 Both client and server generate 17 octets of challenge material, 1018 using the constant string "inner application challenge" as described 1019 above. These octets are used as follows: 1021 MS-CHAP-Challenge [16 octets] 1022 Ident [1 octet] 1024 The client initiates MS-CHAP-V2 by including User-Name, MS-CHAP- 1025 Challenge and MS-CHAP2-Response AVPs in the first ApplicationPayload 1026 message in any application phase. The MS-CHAP-Challenge value is 1027 taken from the challenge material. The MS-CHAP2-Response consists of 1028 Ident, taken from the challenge material; Flags, set to 0; Peer- 1029 Challenge, set to a random value; and Response, computed according 1030 to the MS-CHAP-V2 algorithm. 1032 Upon receipt of these AVPs from the client, the server must verify 1033 that the value of the MS-CHAP-Challenge AVP and the value of the 1034 Ident in the client's MS-CHAP2-Response AVP are equal to the values 1035 generated as challenge material. If either item does not match 1036 exactly, the server must reject the client. Otherwise, it validates 1037 the MS-CHAP2-Challenge. 1039 If the MS-CHAP2-Challenge received from the client is correct, the 1040 server tunnels the MS-CHAP2-Success AVP to the client. 1042 Upon receipt of the MS-CHAP2-Success AVP, the client is able to 1043 authenticate the server. In its next InnerApplicationPayload message 1044 to the server, the client does not include any MS-CHAP-V2 AVPs. 1045 (This may result in an empty InnerApplicationPayload if no other 1046 AVPs need to be sent.) 1048 If the MS-CHAP2-Challenge received from the client is not correct, 1049 the server tunnels an MS-CHAP2-Error AVP to the client. This AVP 1050 contains a new Ident and a string with additional information such 1051 as error reason and whether a retry is allowed. If the error reason 1052 is an expired password and a retry is allowed, the client may 1053 proceed to change the user's password. If the error reason is not an 1054 expired password or if the client does not wish to change the user's 1055 password, it issues an InnerApplicationFailure alert. 1057 If the client does wish to change the password, it tunnels MS-CHAP- 1058 NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the server. 1059 The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge 1060 received in the MS-CHAP2-Error AVP. The MS-CHAP-Challenge AVP simply 1061 echoes the new Challenge. 1063 Upon receipt of these AVPs from the client, the server must verify 1064 that the value of the MS-CHAP-Challenge AVP and the value of the 1065 Ident in the client's MS-CHAP2-CPW AVP match the values it sent in 1066 the MS-CHAP2-Error AVP. If either item does not match exactly, the 1067 server must reject the client. Otherwise, it validates the MS-CHAP2- 1068 CPW AVP. 1070 If the MS-CHAP2-CPW AVP received from the client is correct, and the 1071 server is able to change the user's password, the server tunnels the 1072 MS-CHAP2-Success AVP to the client and the negotiation proceeds as 1073 described above. 1075 Note that additional AVPs associated with MS-CHAP-V2 may be sent by 1076 the server; for example, MS-CHAP-Domain. The server must tunnel such 1077 authentication-related AVPs along with the MS-CHAP2-Success. 1079 4.2.5 PAP 1081 PAP RADIUS attribute formats are described in [RFC2865]. 1083 The client initiates PAP by including User-Name and User-Password 1084 AVPs in the first ApplicationPayload message in any application 1085 phase. 1087 In RADIUS, User-Password is padded with nulls to a multiple of 16 1088 octets, then encrypted using a shared secret and other packet 1089 information. 1091 A TLS/IA, however, does not RADIUS-encrypt the password since all 1092 application phase data is already encrypted. The client SHOULD, 1093 however, null-pad the password to a multiple of 16 octets, to 1094 obfuscate its length. 1096 Upon receipt of these AVPs from the client, the server may be able 1097 to decide whether to authenticate the client immediately, or it may 1098 need to challenge the client for more information. 1100 If the server wishes to issue a challenge to the client, it MUST 1101 tunnel the Reply-Message AVP to the client; this AVP normally 1102 contains a challenge prompt of some kind. It may also tunnel 1103 additional AVPs if necessary, such the Prompt AVP. Upon receipt of 1104 the Reply-Message AVPs, the client tunnels User-Name and User- 1105 Password AVPs again, with the User-Password AVP containing new 1106 information in response to the challenge. This process continues 1107 until the server determines the authentication has succeeded or 1108 failed. 1110 4.3 Performing Multiple Authentications 1112 In some cases, it is desirable to perform multiple user 1113 authentications. For example, a server may want first to 1114 authenticate the user by password, then by a hardware token. 1116 The server may perform any number of additional user authentications 1117 using EAP, simply by issuing a EAP-Request with a new protocol type 1118 once the previous authentication has completed. 1120 For example, a server wishing to perform MD5-Challenge followed by 1121 Generic Token Card would first issue an EAP-Request/MD5-Challenge 1122 AVP and receive a response. If the response is satisfactory, it 1123 would then issue EAP-Request/Generic Token Card AVP and receive a 1124 response. If that response were also satisfactory, it would consider 1125 the user authenticated. 1127 5 Example Message Sequences 1129 This section presents a variety of possible TLS/IA message 1130 sequences. These examples are not meant to exhaustively depict all 1131 possible scenarios. 1133 Parentheses indicate optional TLS messages. Brackets indicate 1134 optional message exchanges. An ellipsis (. . .) indicates optional 1135 repetition of preceding messages. 1137 5.1 Full Initial Handshake with Intermediate and Final Application 1138 Phases 1140 The diagram below depicts a full initial handshake phase followed by 1141 two application phases. 1143 Note that the client concludes the intermediate phase and starts the 1144 final phase in an uninterrupted sequence of three messages: 1145 ChangeCipherSpec and PhaseFinished belong to the intermediate phase, 1146 and ApplicationPayload belongs to the final phase. 1148 Client Server 1149 ------ ------ 1151 *** TLS Handshake: 1152 ClientHello --------> 1153 ServerHello 1154 (Certificate) 1155 ServerKeyExchange 1156 (CertificateRequest) 1157 <-------- ServerHelloDone 1159 (Certificate) 1160 ClientKeyExchange 1161 (CertificateVerify) 1162 ChangeCipherSpec 1163 Finished --------> 1164 ChangeCipherSpec 1165 <-------- Finished 1167 *** Intermediate Phase: 1168 ApplicationPayload --------> 1170 [ 1171 <-------- ApplicationPayload 1173 ApplicationPayload --------> 1175 ... 1176 ] 1177 <-------- 1178 IntermediatePhaseFinished 1179 IntermediatePhaseFinished 1180 *** Final Phase: 1181 ApplicationPayload --------> 1183 [ 1184 <-------- ApplicationPayload 1186 ApplicationPayload --------> 1188 ... 1189 ] 1190 <-------- FinalPhaseFinished 1192 FinalPhaseFinished --------> 1194 5.2 Resumed Session with Single Application Phase 1196 The diagram below depicts a resumed session followed by a single 1197 application phase. 1199 Note that the client concludes the initial phase and starts the 1200 final phase in an uninterrupted sequence of three messages: 1201 ChangeCipherSpec and PhaseFinished belong to the initial phase, and 1202 ApplicationPayload belongs to the final phase. 1204 Client Server 1205 ------ ------ 1207 *** TLS Handshake: 1208 ClientHello --------> 1209 ServerHello 1211 ChangeCipherSpec 1212 <-------- Finished 1213 ChangeCipherSpec 1214 Finished 1215 *** Final Phase: 1216 ApplicationPayload --------> 1218 [ 1219 <-------- ApplicationPayload 1221 ApplicationPayload --------> 1223 ... 1224 ] 1225 <-------- FinalPhaseFinished 1227 FinalPhaseFinished --------> 1229 5.3 Resumed Session with No Application Phase 1231 The diagram below depicts a resumed session without any subsequent 1232 application phase. This will occur if the client indicates in its 1233 ClientInnerApplication message that no application phase is required 1234 and the server concurs. 1236 Note that this message sequence is identical to that of a standard 1237 TLS resumed session. 1239 Client Server 1240 ------ ------ 1242 *** TLS Handshake: 1243 ClientHello --------> 1244 ServerHello 1245 ChangeCipherSpec 1246 <-------- Finished 1247 ChangeCipherSpec 1248 Finished --------> 1250 6 Security Considerations 1252 This document introduces a new TLS extension called "Inner 1253 Application". When TLS is used with the Inner Application extension 1254 (TLS/IA), additional messages are exchanged during the TLS 1255 handshake. Hence a number of security issues need to be taken into 1256 consideration. Since the security heavily depends on the information 1257 (called "applications") which are exchanged between the TLS client 1258 and the TLS server as part of the TLS/IA extension we try to 1259 classify them into two categories: The first category considers the 1260 case where the exchange results in the generation of keying 1261 material. This is, for example, the case with certain EAP methods. 1263 EAP is one of the envisioned main "applications". The second 1264 category focuses on cases where no session key is generated. The 1265 security treatment of the latter category is discouraged since it is 1266 subject to man-in-the-middle attacks if the two sessions cannot be 1267 bound to each other as suggested in [MITM]. 1269 In the following, we investigate a number of security issues: 1271 - Architecture and Trust Model 1273 For many of the use cases in this document we assume that three 1274 functional entities participate in the protocol exchange: TLS 1275 client, TLS server and a AAA infrastructure (typically consisting 1276 of a AAA server and possibly a AAA broker). The protocol exchange 1277 described in this document takes place between the TLS client and 1278 the TLS server. The interaction between the AAA client (which 1279 corresponds to the TLS server) and the AAA server is described in 1280 the respective AAA protocol documents and therefore outside the 1281 scope of this document. The trust model behind this architecture 1282 with respect to the authentication, authorization, session key 1283 establishment and key transport within the AAA infrastructure is 1284 discussed in [KEYING]. 1286 - Authentication 1288 This document assumes that the TLS server is authenticated to the 1289 TLS client as part of the authentication procedure of the initial 1290 TLS Handshake. This approach is similar to the one chosen with 1291 the EAP support in IKEv2 (see [IKEv2]). Typically, public key 1292 based server authentication is used for this purpose. More 1293 interesting is the client authentication property whereby 1294 information exchanged as part of the Inner Application is used to 1295 authenticate (or authorize) the client. For example, if EAP is 1296 used as an inner application then EAP methods are used to perform 1297 authentication and key agreement between the EAP peer (most 1298 likely the TLS client) and the EAP server (i.e., AAA server). 1300 - Authorization 1302 Throughout this document it is assumed that the TLS server can be 1303 authorized by the TLS client as a legitimate server as part of 1304 the authentication procedure of the initial TLS Handshake. The 1305 entity acting as TLS client can be authorized either by the TLS 1306 server or by the AAA server (if the authorization decision is 1307 offloaded). Typically, the authenticated identity is used to 1308 compute the authorization decision but credential-based 1309 authorization mechanisms may be used as well. 1311 - Man-in-the-Middle Attack 1312 Man-in-the-middle attacks have become a concern with tunneled 1313 authentication protocols because of the discovered 1314 vulnerabilities (see [MITM]) of a missing cryptographic binding 1315 between the independent protocol sessions. This document also 1316 proposes a tunneling protocol, namely individual inner 1317 application sessions are tunneled within a previously executed 1318 session. The first protocol session in this exchange is the 1319 initial TLS Handshake. To avoid man-in-the-middle attacks, 1320 Section 2.2 addresses how to establish such a cryptographic 1321 binding. 1323 - User Identity Confidentiality 1325 The TLS/IA extension allows splitting the authentication of the 1326 TLS server from the TLS client into two separate sessions. As one 1327 of the advantages, this provides active user identity 1328 confidentiality since the TLS client is able to authenticate the 1329 TLS server and to establish a unilateral authenticated and 1330 confidentiality-protected channel prior to starting the client- 1331 side authentication. 1333 - Session Key Establishment 1335 TLS [RFC2246] defines how session key material produced during 1336 the TLS Handshake is generated with the help of a pseudo-random 1337 function to expand it to keying material of the desired length 1338 for later usage in the TLS Record Layer. Section 2.2 gives some 1339 guidelines with regard to the master key generation. Since the 1340 TLS/IA extension supports multiple exchanges whereby each phase 1341 concludes with a generated keying material. In addition to the 1342 keying material established as part of TLS itself, most inner 1343 applications will produce their keying material. For example, 1344 keying material established as part of an EAP method must be 1345 carried from the AAA server to the AAA client. Details are 1346 subject to the specific AAA protocol (for example, EAP usage in 1347 Diameter [AAA-EAP]. 1349 - Denial of Service Attacks 1351 This document does not modify the initial TLS Handshake and as 1352 such, does not introduce new vulnerabilities with regard to DoS 1353 attacks. Since the TLS/IA extension allows to postpone the 1354 client-side authentication to a later stage in the protocol 1355 phase. As such, it allows malicious TLS clients to initiate a 1356 number of exchanges while remaining anonymous. As a consequence, 1357 state at the server is allocated and computational efforts are 1358 required at the server side. Since the TLS client cannot be 1359 stateless this is not strictly a DoS attack. 1361 - Confidentiality Protection and Dictionary Attack Resistance 1362 Similar to the user identity confidentiality property the usage 1363 of the TLS/IA extension allows to establish a unilateral 1364 authenticated tunnel which is confidentiality protected. This 1365 tunnel protects the inner application information elements to be 1366 protected against active adversaries and therefore provides 1367 resistance against dictionary attacks when password-based 1368 authentication protocols are used inside the tunnel. In general, 1369 information exchanged inside the tunnel experiences 1370 confidentiality protection. 1372 - Downgrading Attacks 1374 This document defines a new extension. The TLS client and the TLS 1375 server indicate the capability to support the TLS/IA extension as 1376 part of the client_hello_extension_list and the 1377 server_hello_extension_list payload. More details can be found in 1378 Section 2.5. To avoid downgrading attacks whereby an adversary 1379 removes a capability from the list is avoided by the usage of the 1380 IntermediatePhaseFinished or FinalPhaseFinished message as 1381 described in Section 2.1. 1383 7 References 1385 7.1 Normative References 1387 [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1388 1700, October 1994. 1390 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1391 Protocol (CHAP)", RFC 1994, August 1996. 1393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1394 Requirement Levels", RFC 2119, March 1997. 1396 [RFC2246] Dierks, T., and C. Allen, "The TLS Protocol Version 1397 1.0", RFC 2246, November 1998. 1399 [RFC2433] Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", 1400 RFC 2433, October 1998. 1402 [RFC2486] Aboba, B., and M. Beadles, "The Network Access 1403 Identifier", RFC 2486, January 1999. 1405 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1406 RFC 2548, March 1999. 1408 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1409 RFC 2759, January 2000. 1411 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1412 "Remote Authentication Dial In User Service (RADIUS)", 1413 RFC 2865, June 2000. 1415 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 1416 J., and T. Wright, "Transport Layer Security (TLS) 1417 Extensions", RFC 3546, June 2003. 1419 [RFC3579] Aboba, B., and P.Calhoun, "RADIUS (Remote Authentication 1420 Dial In User Service) Support For Extensible 1421 Authentication Protocol (EAP)", RFC 3579, September 1422 2003. 1424 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1425 Arkko, "Diameter Base Protocol", RFC 3588, July 2003. 1427 [RFC3784] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 1428 H. Levkowetz, "PPP Extensible Authentication Protocol 1429 (EAP)", RFC 3784, June 2004. 1431 7.2 Informative References 1433 [RFC1661] Simpson, W. (Editor), "The Point-to-Point Protocol 1434 (PPP)", STD 51, RFC 1661, July 1994. 1436 [RFC2716] Aboba, B., and D. Simon, "PPP EAP TLS Authentication 1437 Protocol", RFC 2716, October 1999. 1439 [EAP-TTLS] Funk, P., and S. Blake-Wilson, " EAP Tunneled TLS 1440 Authentication Protocol (EAP-TTLS)", draft-ietf-pppext- 1441 eap-ttls-05.txt, July 2004. 1443 [EAP-PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., 1444 and S. Josefsson, "Protected EAP Protocol (PEAP) Version 1445 2", draft-josefsson-pppext-eap-tls-eap-08.txt, July 1446 2004. 1448 [TLS-PSK] Eronen, P., and H. Tschofenig, "Pre-Shared Key 1449 Ciphersuites for Transport Layer Security (TLS)", draft- 1450 ietf-tls-psk-01.txt, August 2004. 1452 [802.1X] IEEE Standards for Local and Metropolitan Area Networks: 1453 Port based Network Access Control, IEEE Std 802.1X-2001, 1454 June 2001. 1456 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 1457 in Tunneled Authentication", 1458 http://www.saunalahti.fi/~asokan/research/mitm.html, 1459 Nokia Research Center, Finland, October 24 2002. 1461 [KEYING] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP 1462 Key Management Framework", draft-ietf-eap-keying-01.txt 1463 (work in progress), October 2003. 1465 [IKEv2] C.Kaufman, "Internet Key Exchange (IKEv2) Protocol", 1466 draft-ietf-ipsec-ikev2-16.txt (work in progress), 1467 September 2004. 1469 [AAA-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 1470 Authentication Protocol (EAP) Application", draft-ietf- 1471 aaa-eap-03.txt (work in progress), October 2003. 1473 8 Authors' Addresses 1475 Questions about this memo can be directed to: 1477 Paul Funk 1478 Juniper Networks 1479 222 Third Street 1480 Cambridge, MA 02142 1481 USA 1482 Phone: +1 617 497-6339 1483 E-mail: pfunk@juniper.net 1485 Simon Blake-Wilson 1486 Basic Commerce & Industries, Inc. 1487 96 Spadina Ave, Unit 606 1488 Toronto, Ontario M5V 2J6 1489 Canada 1490 Phone: +1 416 214-5961 1491 E-mail: sblakewilson@bcisse.com 1493 Ned Smith 1494 Intel Corporation 1495 MS: JF1-229 1496 2111 N.E. 25th Ave. 1497 Hillsboro, OR 97124 1498 USA 1499 Phone: +1 503 264-2692 1500 E-mail: ned.smith@intel.com 1502 Hannes Tschofenig 1503 Siemens 1504 Otto-Hahn-Ring 6 1505 Munich, Bayern 81739\ 1506 Germany 1507 Phone: +49 89 636 40390 1508 E-mail: Hannes.Tschofenig@siemens.com 1510 Thomas Hardjono 1511 VeriSign Inc. 1513 487 East Middlefield Road 1514 M/S MV6-2-1 1515 Mountain View, CA 94043 1516 USA 1517 Phone: +1 650 426-3204 1518 E-mail: thardjono@verisign.com 1520 9 Intellectual Property Statement 1522 The IETF takes no position regarding the validity or scope of any 1523 Intellectual Property Rights or other rights that might be claimed 1524 to pertain to the implementation or use of the technology described 1525 in this document or the extent to which any license under such 1526 rights might or might not be available; nor does it represent that 1527 it has made any independent effort to identify any such rights. 1528 Information on the procedures with respect to rights in RFC 1529 documents can be found in BCP 78 and BCP 79. 1531 Copies of IPR disclosures made to the IETF Secretariat and any 1532 assurances of licenses to be made available, or the result of an 1533 attempt made to obtain a general license or permission for the use 1534 of such proprietary rights by implementers or users of this 1535 specification can be obtained from the IETF on-line IPR repository 1536 at http://www.ietf.org/ipr. 1538 The IETF invites any interested party to bring to its attention any 1539 copyrights, patents or patent applications, or other proprietary 1540 rights that may cover technology that may be required to implement 1541 this standard. Please address the information to the IETF at ietf- 1542 ipr@ietf.org. 1544 Disclaimer of Validity 1546 This document and the information contained herein are provided on 1547 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1548 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1549 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1550 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1551 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1552 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1554 Copyright Statement 1556 Copyright (C) The Internet Society (2006). This document is subject 1557 to the rights, licenses and restrictions contained in BCP 78, and 1558 except as set forth therein, the authors retain all their rights. 1560 Acknowledgment 1562 Funding for the RFC Editor function is currently provided by the 1563 Internet Society.