idnits 2.17.1 draft-hanna-eap-ttls-agility-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1016. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '... implementations MUST accept the new s...' RFC 2119 keyword, line 146: '... Codes, MAY accept the vendor-specif...' RFC 2119 keyword, line 149: '...or-Specific) bit MUST be set to 1 when...' RFC 2119 keyword, line 150: '...d. Otherwise, it MUST be set to 0. Whe...' RFC 2119 keyword, line 151: '... Vendor-ID field MUST be present. Othe...' (44 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [KEYWORDS], but that reference does not seem to mention RFC 2119 either. -- 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 (September 24, 2007) is 6059 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) == Missing Reference: 'KEYWORDS' is mentioned on line 115, but not defined == Missing Reference: 'RFC3588' is mentioned on line 143, but not defined ** Obsolete undefined reference: RFC 3588 (Obsoleted by RFC 6733) == Missing Reference: 'Assigned-AVP-Code' is mentioned on line 884, but not defined ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) == Outdated reference: A later version (-05) exists of draft-funk-eap-ttls-v0-01 ** Downref: Normative reference to an Informational draft: draft-funk-eap-ttls-v0 (ref. 'TTLSv0') -- Obsolete informational reference (is this intentional?): RFC 2716 (ref. 'EAPTLS') (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- No information found for draft-ietf-tls-rfc4346bis - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Steve Hanna 2 Internet Draft Juniper Networks 3 Intended status: Standards Track Paul Funk 4 Expires: March 2008 Juniper Networks 5 September 24, 2007 7 Key Agility Extensions for EAP-TTLSv0 8 draft-hanna-eap-ttls-agility-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on March 24, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines new Attribute Value Pairs (AVPs) that add 43 cryptographic algorithm agility and other security features 44 (protected results and cryptographic binding of inner authentications 45 to the outer tunnel) to EAP-TTLSv0. 47 Table of Contents 49 1. Introduction............................................ 2 50 2. Terminology ............................................ 3 51 3. AVP Format.............................................. 3 52 4. Negotiating MSK and EMSK Computation.................... 5 53 4.1. MSK-Computation AVP................................ 6 54 MSK Computation Method................................. 7 55 4.2. Values ............................................ 7 56 5. Key Confirmation........................................ 7 57 5.1. Key-Confirmation-Option AVP........................ 9 58 5.2. Key-Confirmation AVP.............................. 10 59 6. Secure Completion ..................................... 11 60 6.1. Secure-Completion-Option AVP ..................... 13 61 6.2. TTLS-Success AVP.................................. 14 62 6.3. TTLS-Failure AVP.................................. 15 63 7. Cryptographic Computations............................. 15 64 7.1. Use of TLS PRF.................................... 15 65 7.2. Composite Key Computation......................... 16 66 7.3. MSK/EMSK computation using the "Mixed" mechanism.. 17 67 7.4. Key Confirmation computation ..................... 17 68 8. Security Considerations................................ 18 69 8.1. Cryptographic Algorithm Agility................... 18 70 8.2. Protection Against MITM Attacks................... 18 71 8.3. Protection Against Truncation Attacks............. 19 72 8.4. Protection Against Forged Results................. 19 73 9. IANA Considerations.................................... 19 74 9.1. Allocation of AVP Codes .......................... 19 75 9.2. Creation of New Registries........................ 20 76 10. References ........................................... 21 77 10.1. Normative References............................. 21 78 10.2. Informative References .......................... 21 79 Authors' Addresses........................................ 22 80 Intellectual Property Statement .......................... 22 82 1. Introduction 84 EAP-TTLSv0 [TTLSv0] is a "tunneled EAP method". This means that it 85 defines an authentication protocol for use with the Extensible 86 Authentication Protocol [EAP] and that this authentication protocol 87 creates a secure tunnel that can carry other authentication protocols 88 and other data exchanges. EAP-TTLSv0 has many advantages such as 89 extensibility, the ability to more securely carry legacy 90 authentication protocols, and widespread usage. But it also has 91 several issues: lack of cryptographic algorithm agility, 92 vulnerability to possible Man-in-the-Middle attacks when used with 93 certain legacy protocols as described in [MITM], and vulnerability to 94 truncation attacks. 96 This specification defines three extensions to EAP-TTLSv0 that 97 address these issues by adding algorithm agility, protected results, 98 and cryptographic binding of inner authentications to the outer 99 tunnel. The extensions are defined using AVPs with semantics that 100 allow for a gradual transition as clients and servers are upgraded to 101 support the extensions. At first, clients can request the extensions 102 in a backward-compatible manner but proceed with the authentication 103 if the server does not support them. Servers can allow clients to use 104 the extensions or not. Over time, clients and servers can change 105 their policy to require the extensions, thus protecting against 106 downgrade attacks. For a description of how the extensions defined in 107 this document provide algorithm agility, protected results, and 108 cryptobinding, see the Security Considerations section. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [KEYWORDS]. 116 3. AVP Format 118 This document defines several AVPs to be used with EAP-TTLSv0. All of 119 these AVPs begin with the AVP header fields defined in [TTLSv0] and 120 use those fields in the same way. This section describes how those 121 fields are used and interpreted so that each AVP definition below 122 does not need to duplicate this text. Any normative text in this 123 section is normative with respect to all AVPs defined in this 124 document. 126 The format of an EAP-TTLSv0 AVP is shown below. All items are in 127 network (i.e. big-endian) order. 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | AVP Code | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 |V M r r r r r r| AVP Length | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Vendor-ID (when V bit is 1) | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Data ... 139 +-+-+-+-+-+-+-+-+ 141 The IANA will assign AVP Codes for the AVPs defined in this document 142 when this document moves to RFC status (as defined in [TTLSv0] and 143 [RFC3588]). In the mean time, this document defines vendor-specific 144 AVP Codes that may be used by setting the 'V' bit. Once this document 145 moves to RFC status, implementations MUST accept the new standard AVP 146 Codes, MAY accept the vendor-specific AVP Codes, and SHOULD only send 147 the standard AVP Codes. 149 The 'V' (Vendor-Specific) bit MUST be set to 1 when a vendor-specific 150 AVP Code is used. Otherwise, it MUST be set to 0. When this bit is 151 set to 1, the Vendor-ID field MUST be present. Otherwise, it MUST be 152 absent. 154 The 'M' (Mandatory) bit may be set to 0 or 1, depending on the 155 preferences and policies of the party sending this AVP. If the M bit 156 is set to 1, the party receiving this AVP MUST either support this 157 AVP Code or fail the authentication. If the M bit is set to 0, the 158 receiving party may safely ignore this AVP. 160 The 'r' (reserved) bits MUST be set to 0 by the sending party and 161 MUST be ignored by the receiving party, at least for this version of 162 this specification. Future versions of this specification may use 163 these bits for extensibility. 165 The AVP Length field MUST be set to the length in octets of this AVP 166 including the AVP Code, AVP Length, AVP Flags (V, M, and r), Vendor- 167 ID (if present) and Data. 169 The Vendor-ID field is omitted when the V flag is 0. The vendor- 170 specific AVP Codes defined in this specification all have a Vendor-ID 171 of 2636. 173 The contents and meaning of the Data field are different for each AVP 174 defined below. 176 4. Negotiating MSK and EMSK Computation 178 Secure computation of a Master Session Key (MSK) and Extended Master 179 Session Key (EMSK) is a critical part of any strong EAP method. The 180 mechanism defined in [TTLSv0] for computing the MSK and EMSK always 181 uses the TLS 1.1 PRF based on MD5 and SHA1. This is not algorithm 182 agile. Also, the MSK and EMSK computation method defined in [TTLSv0] 183 does not mix in keying material from inner authentications so 184 cryptographic binding of the inner and outer authentications is not 185 achieved. 187 The new MSK-Computation AVP allows the TTLS client and TTLS server to 188 negotiate the MSK and EMSK computation method to be used. A new MSK 189 and EMSK computation method defined in section 7.3 of this 190 specification achieves algorithm agility and adds cryptographic 191 binding. To ensure maximum flexibility for the future, other MSK and 192 EMSK computation methods can be defined and negotiated using the same 193 MSK-Computation AVP. 195 Options for MSK and EMSK computation defined in this specification 196 include: 198 - Default computation, as defined in [TTLSv0] 200 - Mixed computation method as defined in section 7.3 202 In order to negotiate a computation method other than the TTLSv0 203 default, the client sends an MSK-Computation AVP in the first phase 2 204 TTLS message sent to the TTLS server. This AVP indicates which MSK 205 computation methods the client is willing to use. If the client does 206 not include an MSK-Computation AVP in the first phase 2 TTLS message 207 sent to the TTLS server, the default computation methods (as 208 specified in [TTLSv0]) are used. 210 If the default MSK computation method (as specified in [TTLSv0]) is 211 not acceptable to the client, the client SHOULD set the M (Mandatory) 212 bit in the MSK-Computation AVP to indicate that the server must 213 support this AVP or terminate the authentication. 215 A TTLS server that supports the MSK-Computation AVP MUST respond to 216 an MSK-Computation AVP received from the client by selecting one of 217 those computations or by failing the authentication if it will not 218 accept any of the computations listed by the client. The server MAY 219 make its selection by sending an MSK-Computation AVP in any TTLS 220 message prior to the completion of the authentication; that is, the 221 server is allowed to defer its selection if necessary. 223 Note that when the TTLS server relays an inner authentication to 224 another server, its ability to mix inner method MSKs with the TLS 225 master secret depends on the MSK of the relayed authentication being 226 conveyed by the other server to the TTLS server. For example, a 227 RADIUS TTLS server may proxy an inner authentication to a home RADIUS 228 server, which would normally return the MSK to the TTLS server via 229 MPPE-Recv-Key and MPPE-Send-Key attributes. Some RADIUS servers may 230 not return the MSK in this manner. In that case, the RADIUS TTLS 231 server will not be able to use an MSK computation method that 232 requires mixing in the inner MSK. That's why the TTLS server is 233 allowed to delay committing to a particular MSK computation method 234 until the end of the handshake. It may not know whether the home 235 RADIUS server will return the MSK (or even whether a home RADIUS 236 server will be used). The TTLS server SHOULD commit to an MSK 237 computation method as soon as possible. The TTLS client MAY refuse to 238 continue with an authentication if the TTLS server has not committed 239 to an MSK computation method by a particular point (e.g. when 240 particularly sensitive credentials are requested). 242 4.1. MSK-Computation AVP 244 The basic format of the MSK-Computation AVP is defined in section 3 245 above. This section only describes aspects that are specific to the 246 MSK-Computation AVP. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | AVP Code | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |V M r r r r r r| AVP Length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Vendor-ID (when V bit is 1) | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | MSK Computation Method 1 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | ... | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 The AVP Code for the MSK-Computation AVP will be assigned by IANA 263 when this document moves to RFC status. In the mean time, a vendor- 264 specific AVP Code of 256 with a Vendor-ID field of 2636 should be 265 used for experimental purposes. 267 The body of the MSK-Computation AVP contains one or more 32-bit MSK 268 computation method values (defined in section 4.3 below), each of 269 which specifies a mechanism for computing the MSK and EMSK. 271 The client MAY list multiple values, in order from most to least 272 preferred. The TTLS server MUST list only one value. 274 4.2. MSK Computation Method Values 276 A standard set of MSK computation method values for use in the MSK- 277 Computation AVP is defined in this section. To enable extensibility, 278 each value contains a vendor-id in the first (high order) 24 bits and 279 a selector in the last (low order) 8 bits. Values defined in this 280 specification use a vendor-id of 0. Vendors MUST use the vendor's 281 IANA-assigned Private Enterprise Number [PEN]. 283 The following set of standard MSK computation method values are 284 defined at this time: 286 - 0 Default computation as defined in [TTLSv0] 288 - 1 Mixed computation mechanism as defined in section 7.3 290 Additional standard MSK computation method values may be defined at a 291 later time by publishing an RFC that defines these values. 293 5. Key Confirmation 295 Key Confirmation permits the client and TTLS server each to prove to 296 the other that it is in possession of all keys resulting from inner 297 authentications, in addition to the TLS master secret. This is done 298 to preclude a type of man-in-the-middle attack in which the attacker, 299 acting as a server, induces a legitimate client to perform an 300 authentication which the attacker then acts as a client to feed into 301 the EAP-TTLS negotiation as an inner method (as described in [MITM]). 303 Note that use of the Mixed mechanism for MSK computation may provide 304 a comparable safeguard, by ensuring that the MSK resulting from the 305 EAP-TTLS negotiation cannot be known by such a man-in-the-middle 306 attacker, and therefore cannot be used in a subsequent data 307 connection, thus allowing authentication to succeed but denying the 308 attacker the fruits of that successful authentication. 310 Key Confirmation is negotiated using the Key-Confirmation-Option AVP 311 and implemented using the Key-Confirmation AVP. The client MAY issue 312 a Key-Confirmation-Option AVP in its first phase 2 TTLS message to 313 the TTLS server, indicating one or both of the following Key 314 Confirmation Option values: 316 - Disabled 317 - Enabled 319 By listing both Disabled and Enabled options, the client can indicate 320 that it is willing to proceed with or without Key Confirmation. If 321 this is the case, the client should set the M bit for the Key- 322 Confirmation-Option AVP to 0 so that servers that do not support this 323 AVP can be supported. If, on the other hand, the client requires Key 324 Confirmation to be used, it may set the M bit for the Key- 325 Confirmation-Option AVP to 1 so that servers that do not support this 326 AVP will fail the authentication. 328 The Key-Confirmation-Option AVP MUST appear in the client's first 329 phase 2 TTLS message to the TTLS server if it appears at all. Absence 330 of the Key-Confirmation-Option AVP is equivalent to selecting the 331 "Disabled" option. 333 If the client transmits a Key-Confirmation-Option AVP that includes 334 an option acceptable to the TTLS server, the TTLS server MUST respond 335 with a Key-Confirmation-Option AVP in its first phase 2 TTLS message 336 to the client indicating its selection (Enabled or Disabled). If the 337 TTLS server is unwilling to accommodate the client's Key Confirmation 338 preference, it MUST fail the authentication. 340 Once negotiated, Key Confirmation MAY be initiated by the TTLS server 341 in any TTLS message, by issuing a Key-Confirmation AVP to the client. 342 A Key Confirmation that occurs after all MSK-generating inner 343 authentication methods have completed is called the "final Key 344 Confirmation", and any Key Confirmation that occurs early (with fewer 345 than all inner MSKs) is called an "intermediate Key Confirmation". 347 If the TTLS server indicated "Enabled" in its Key-Confirmation-Option 348 AVP, the TTLS server MAY initiate one or more intermediate Key 349 Confirmations and MUST initiate a final Key Confirmation. If the TTLS 350 server indicated "Disabled" in its Key-Confirmation-Option AP, the 351 TTLS server MUST NOT initiate any intermediate Key Confirmations or 352 final Key Confirmations. 354 When the client receives a valid Key-Confirmation AVP from the TTLS 355 server, it MUST include its own Key-Confirmation AVP in its next TTLS 356 message to the TTLS server. If the client receives an invalid Key- 357 Confirmation AVP from the TTLS server, it MUST abandon the 358 authentication or otherwise cause it to fail. 360 If the client wants to require the server to send a final Key 361 Confirmation, it should set the M (Mandatory) bit on the Key- 362 Confirmation-Option AVP to ensure that servers that do not support 363 this AVP will terminate the authentication. If the client sets the M 364 bit and then the server responds with a first EAP-TTLS message that 365 does not include a Key-Confirmation-Option AVP or includes an invalid 366 or unacceptable Key-Confirmation-Option AVP , or the TTLS server 367 sends an invalid Key-Confirmation AVP at any point, the TTLS client 368 should consider the authentication failed. If the TTLS server sends a 369 Key-Confirmation-Option AVP indicating that key confirmation is 370 Enabled and then the TTLS client receives an EAP-Success message 371 without receiving a final Key Confirmation, the client SHOULD NOT 372 consider the session properly established. 374 If the TTLS server receives an invalid Key-Confirmation AVP from the 375 TTLS client or fails to receive any Key-Confirmation AVP in response 376 to one sent, the TTLS server SHOULD fail the authentication and send 377 an EAP-Failure message. If secure completion has been negotiated and 378 no TTLS-Success or TTLS-Failure message has been sent, a TTLS-Failure 379 message should be sent before the EAP-Failure message. If secure 380 completion has been negotiated and a TTLS-Success or TTLS-Failure 381 message has already been sent, only an EAP-Failure message should be 382 sent. 384 Intermediate Key Confirmation might be used when multiple inner 385 authentications are performed and it is desirable to validate the 386 results of a first authentication prior to performing a subsequent 387 authentication, possibly for security or performance reasons. Use of 388 intermediate Key Confirmation is anticipated to be atypical. 390 Because intermediate Key Confirmations expose information about the 391 results of previous EAP methods, clients SHOULD NOT engage in an 392 intermediate Key Confirmation unless they have already authenticated 393 the server and determined that it is sufficiently trusted to expose 394 this information. 396 5.1. Key-Confirmation-Option AVP 398 The basic format of the Key-Confirmation-Option AVP is defined in 399 section 3 above. This section only describes aspects that are 400 specific to the Key-Confirmation-Option AVP. 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | AVP Code | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |V M r r r r r r| AVP Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Vendor-ID (when V bit is 1) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Key Confirmation Option Value 1 | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | ... | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 The AVP Code for the Key-Confirmation-Option AVP will be assigned by 417 IANA when this document moves to RFC status. In the mean time, a 418 vendor-specific AVP Code of 257 with a Vendor-ID field of 2636 should 419 be used for experimental purposes. 421 The body of the Key-Confirmation-Option AVP contains one or more 32- 422 bit Key Confirmation Option Values. To enable extensibility, each 423 value contains a vendor-id in the first (high order) 24 bits and a 424 selector in the last (low order) 8 bits. Standard values (defined in 425 this or future IETF specifications) use a vendor-id of 0. Vendors 426 MUST use the vendor's IANA-assigned Private Enterprise Number [PEN]. 428 The following standard Key Confirmation Option values are defined at 429 this time: 431 0 Disabled 433 1 Enabled 435 Additional standard Key Confirmation Option values may be defined at 436 a later time by publishing an RFC that defines these values. 438 The client MAY list multiple Key Confirmation Option values, in order 439 from most to least preferred. The server MUST list only one value. 441 5.2. Key-Confirmation AVP 443 The basic format of the Key-Confirmation AVP is defined in section 3 444 above. This section only describes aspects that are specific to the 445 Key-Confirmation AVP. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | AVP Code | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |V M r r r r r r| AVP Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Vendor-ID (when V bit is 1) | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Key Confirmation Data ... | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Key Confirmation Data (continued) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Key Confirmation Data (continued) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Key Confirmation Data (continued) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Key Confirmation Data (continued) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Key Confirmation Data (continued) | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Key Confirmation Data (continued) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Key Confirmation Data (continued) | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 The AVP Code for the Key-Confirmation AVP will be assigned by IANA 474 when this document moves to RFC status. In the mean time, a vendor- 475 specific AVP Code of 258 with a Vendor-ID field of 2636 should be 476 used for experimental purposes. 478 The body of the Key-Confirmation AVP contains 32 octets of binary Key 479 Confirmation Data, computed as described in section 7.4. 481 6. Secure Completion 483 As defined in [EAP], the EAP-Success and EAP-Failure messages, which 484 indicate the result of an EAP authentication, are unprotected 485 messages sent by the EAP authenticator to the client and not 486 acknowledged by the client. Thus these messages can be changed in 487 transit. 489 In addition, while the TLS protocol provides a means to securely 490 terminate a conversation, [TTLSv0] does not utilize that mechanism, 491 leaving it vulnerable to possible truncation attack. For example, an 492 attacker might insert a counterfeit EAP-Success to the client prior 493 to completion of the TTLS exchange, or the attacker might contrive to 494 substitute empty TTLS payloads for real ones to either client or TTLS 495 server in the final TTLS payloads. This substitution would go 496 undetected. 498 Whether such vulnerabilities could lead to real damage beyond denial 499 of service depends on the underlying inner protocols used within 500 TTLS. However, for maximum security it is advisable to use the Secure 501 Completion mechanism to thwart possible attacks. 503 In Secure Completion, the TTLS server issues a TTLS-Success or TTLS- 504 Failure AVP as the final AVP of its final TTLS message to the client. 505 The client responds with either a TTLS-Success or TTLS-Failure AVP as 506 the final AVP of its final TTLS message to the TTLS server. Once the 507 TTLS server receives the client's final TTLS message, the unprotected 508 EAP-Success or EAP-Failure (as appropriate) is sent to the client to 509 complete the EAP exchange. 511 Note that other AVPs may appear in the same TTLS message as TTLS- 512 Success or TTLS-Failure, provided they appear earlier in the message. 513 The TTLS server, for example, could piggyback a TTLS-Success at the 514 end of a final inner EAP-Request message. 516 The client MUST respond to a TTLS-Success from the TTLS server with 517 either a TTLS-Success or TTLS-Failure. The client MUST respond to a 518 TTLS-Failure from the TTLS server with a TTLS-Failure. If the client 519 fails to include such a value as the final AVP in its final EAP- 520 Response or if the client sends a TTLS-Failure AVP in its final EAP- 521 Response, the server SHOULD send an EAP-Failure. The server SHOULD 522 NOT send an EAP-Failure if both the server and client have just sent 523 TTLS-Success messages since an untrusted intermediary could easily 524 change this EAP-Failure to an EAP-Success without the client 525 detecting that change. In any case, the server SHOULD send only one 526 TTLS-Success or TTLS-Failure message during a particular EAP-TTLSv0 527 handshake. 529 When session resumption is employed with EAP-TTLS and secure 530 completion had been negotiated in the prior session, the TTLS server 531 and client MUST still send TTLS-Success or TTLS-Failure AVPs to each 532 other as their last AVPs. This will often result in an additional 533 round trip but the client and server have previously negotiated 534 secure completion and this is the price to be paid for that extra 535 measure of security. 537 The client MAY issue a Secure-Completion-Option AVP in its first 538 phase 2 TTLS message to the TTLS server, listing one or both of the 539 following Secure Completion Option values (defined in section 6.1 540 below): 542 - Disabled 544 - Enabled 546 By listing both Disabled and Enabled options, the client can indicate 547 that it is willing to proceed with or without Secure Completion. If 548 this is the case, the client should set the M bit for the Secure- 549 Completion-Option AVP to 0 so that servers that do not support this 550 AVP can be supported. If, on the other hand, the client requires 551 Secure Completion to be used, it may set the M bit for the Secure- 552 Completion-Option AVP to 1 so that servers that do not support this 553 AVP will fail the authentication. 555 The Secure-Completion-Option AVP MUST appear in the client's first 556 phase 2 TTLS message to the TTLS server if it appears at all. Absence 557 of the Secure-Completion-Option AVP is equivalent to selecting the 558 "Disabled" option. 560 If the client transmits a Secure-Completion-Option AVP that includes 561 an option acceptable to the TTLS server, the TTLS server MUST respond 562 with a Secure-Completion-Option AVP in its first phase 2 TTLS message 563 to the client indicating its selection (Enabled or Disabled). If the 564 TTLS server is unwilling to accommodate the client's Secure 565 Completion preferences, it MUST fail the authentication. 567 6.1. Secure-Completion-Option AVP 569 The basic format of the Secure-Completion-Option AVP is defined in 570 section 3 above. This section only describes aspects that are 571 specific to the Secure-Completion-Option AVP. 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | AVP Code | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |V M r r r r r r| AVP Length | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Vendor-ID (when V bit is 1) | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Secure Completion Option Value 1 | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | ... | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 The AVP Code for the Secure-Completion-Option AVP will be assigned by 588 IANA when this document moves to RFC status. In the mean time, a 589 vendor-specific AVP Code of 259 with a Vendor-ID field of 2636 should 590 be used for experimental purposes. 592 The body of the Secure-Completion-Option AVP contains one or more 32- 593 bit Secure Completion Option Values. To enable extensibility, each 594 value contains a vendor-id in the first (high order) 24 bits and a 595 selector in the last (low order) 8 bits. Standard values (defined in 596 this or future IETF specifications) use a vendor-id of 0. Vendors 597 MUST use the vendor's IANA-assigned Private Enterprise Number [PEN]. 599 The following standard Secure Completion Option values are defined: 601 - 0 Disabled (default behavior of [TTLSv0]) 603 - 1 Enabled 605 The client MAY list multiple Secure Completion Option values, in 606 order from most to least preferred. The server MUST list only one 607 value. 609 6.2. TTLS-Success AVP 611 The basic format of the TTLS-Success AVP is defined in section 3 612 above. This section only describes aspects that are specific to the 613 TTLS-Success AVP. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | AVP Code | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 |V M r r r r r r| AVP Length | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Vendor-ID (when V bit is 1) | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 The AVP Code for the TTLS-Success AVP will be assigned by IANA when 626 this document moves to RFC status. In the mean time, a vendor- 627 specific AVP Code of 260 with a Vendor-ID field of 2636 should be 628 used for experimental purposes. 630 The body of the TTLS-Success AVP is empty (zero length). 632 6.3. TTLS-Failure AVP 634 The basic format of the TTLS-Failure AVP is defined in section 3 635 above. This section only describes aspects that are specific to the 636 TTLS-Failure AVP. 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | AVP Code | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 |V M r r r r r r| AVP Length | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Vendor-ID (when V bit is 1) | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 The AVP Code for the TTLS-Failure AVP will be assigned by IANA when 649 this document moves to RFC status. In the mean time, a vendor- 650 specific AVP Code of 261 with a Vendor-ID field of 2636 should be 651 used for experimental purposes. 653 The body of the TTLS-Failure AVP is empty (zero length). 655 7. Cryptographic Computations 657 7.1. Use of TLS PRF 659 All of the cryptographic mechanisms described in this section use the 660 PRF function used in the TLS handshake negotiation that initiates the 661 TTLS exchange. In many cases, this will be the standard PRF function 662 defined in TLS 1.1 [TLS]; however, it is expected that future 663 versions of or extensions to the TLS protocol will permit alternative 664 PRF functions to be negotiated. If an alternative PRF function has 665 been negotiated during the TLS handshake negotiation, then these 666 mechanisms use that alternative PRF function instead of the TLS 1.1 667 PRF. This provides algorithm agility since these mechanisms are not 668 tied to the MD5 and SHA-1 hashes used in the TLS 1.1 PRF. 670 The TLS PRF function used for cryptography described in this 671 specification is denoted as follows: 673 TLS-PRF-nn(secret, label, seed) 675 where: 677 nn is the number of generated octets 678 secret is a secret key 680 label is a string (without null-terminator) 682 seed is a binary sequence. 684 The same PRF function that is used in the TLS handshake MUST be used 685 for all cryptographic operations described in this manner. 687 The TLS 1.1 PRF has invariant output regardless of how many octets 688 are generated. However, it is possible that alternative PRF functions 689 will include the size of the output sequence as input to the PRF 690 function; this means generating 32 octets and generating 64 octets 691 from the same input parameters will no longer result in the first 32 692 octets being identical. For this reason, the PRF is always specified 693 with an "nn", indicating the number of generated octets. 695 7.2. Composite Key Computation 697 The Composite Key is a 40-octet secret derived by cryptographically 698 mixing the TLS master secret and all inner MSKs. It is used as a 699 basis for computing the MSK and/or EMSK when the "Mixed" computation 700 mechanism has been negotiated, as well as for computing Key 701 Confirmation values. 703 Note that when an intermediate Key Confirmation is performed, an 704 intermediate Composite Key must be computed using only those inner 705 MSKs whose values are available at the time that the TTLS server 706 issues the intermediate Key Confirmation. A subsequent Key 707 Confirmation exchange or MSK/EMSK computation using the "Mixed" 708 mechanism will require a new Composite Key computation, as one or 709 more additional inner MSKs will have become available. 711 Composite Key = TLS-PRF-40(master_secret, 712 "ttls composite key", 713 client_random + 714 server_random + 715 inner_session_keys) 717 master_secret, client_random and server_random are security 718 parameters from the TLS handshake. 720 inner_session_keys is the concatenation of all session keys produced 721 by inner authentication methods. This value is calculated as follows. 722 Treating each session key as an unsigned big-endian binary numeric 723 value (perhaps a rather long number), sort this set of session keys 724 from lowest numeric value to highest. Prefix each session key with a 725 2-octet big-endian value indicating the length of that session key in 726 octets. Then concatenate the length-prefixed session keys in the 727 determined (sorted) order. Finally, append two octets of zero to 728 terminate the sequence. 730 If there are no inner authentication methods that produce a session 731 key, inner_session_keys will consist only of two octets of zero. 733 The session keys are ordered by value rather than by the sequence in 734 which they are produced in order to avoid imposing any restrictions 735 against multiple concurrent inner authentications, which might result 736 in ambiguous orderings. 738 7.3. MSK/EMSK computation using the "Mixed" mechanism 740 The "Mixed" mechanism for computing the MSK and EMSK uses the 741 following formula: 743 Keying Material = TLS-PRF-128(composite_key, 744 "ttls mixed keying material", 745 ) 747 MSK = Keying Material [0..63] 749 EMSK = Keying Material [64..127] 751 where indicates that the seed value is of zero-length. 753 7.4. Key Confirmation computation 755 The Key Confirmation value transmitted by the client is computed 756 according to the following formula: 758 client_key_confirmation = TLS-PRF-32(composite_key, 759 "ttls client key confirmation", 760 ) 762 The Key Confirmation value transmitted by the TTLS server is computed 763 according to the following formula: 765 server_key_confirmation = TLS-PRF-32(composite_key, 766 "ttls server key confirmation", 767 ) 769 8. Security Considerations 771 The EAP-TTLSv0 extensions defined in this document supplement the 772 security protection provided by EAP-TTLSv0 by adding algorithm 773 agility, cryptographic binding of inner authentications to the outer 774 tunnel, and protected results. These additional security features 775 provide protection against failures in cryptographic algorithms, 776 protection against particular kinds of MITM attacks, protection 777 against truncation attacks, and protection against forged results. 778 The following sections show how this protection is provided. 780 8.1. Cryptographic Algorithm Agility 782 EAP-TTLS uses cryptographic algorithms in several places. First, it 783 is based on EAP-TLS [EAPTLS] which is based on TLS which uses 784 asymmetric and symmetric encryption algorithms and hash algorithms. 785 Some algorithm agility is provided by the ciphersuite negotiation 786 included in TLS 1.1 but the TLS PRF always uses MD5 and SHA1. 787 Fortunately, TLS 1.2 [TLS12] can be used with EAP-TTLS to provide 788 algorithm agility for the TLS PRF. This can be negotiated with the 789 standard TLS version negotiation mechanism. 791 However, the original design of EAP-TTLSv0 always uses the TLS 1.1 792 PRF to calculate the Master Session Key (MSK) and Extended Master 793 Session Key (EMSK). This leaves the system open to attacks based on 794 weaknesses in MD5 and SHA1. The MSK-Computation AVP allows the PRF 795 negotiated during the TLS handshake to be used for calculating MSK 796 and EMSK values, thus allowing a smooth transition to other 797 cryptographic algorithms if MD5 and SHA1 are judged to be inadequate. 799 8.2. Protection Against MITM Attacks 801 As described in [MITM], if a malicious EAP server can convince a 802 client to authenticate using a particular EAP authentication method 803 and then pass this method through a standard tunneled EAP method, the 804 malicious party can typically gain access as if it had performed the 805 authentication itself. Several countermeasures are possible, such as 806 ensuring that clients only authenticate with trusted servers. But one 807 good way to solve the problem is to modify tunneled EAP methods to 808 verify that the same client is terminating both the inner and the 809 outer authentication method. 811 The MSK-Computation AVP allows the client and/or server to require 812 that the MSK and EMSK is computed using a mixture of the TLS master 813 secret and the MSKs exported from inner methods. If the MSK and EMSK 814 are used to derive keys necessary for later access (as with 802.1X 815 [8021X]), this will ensure that the attack described above will fail 816 since the attacker will not know the MSKs exported from the inner 817 methods. The KeyConfirmation AVPs provide even stronger protection 818 against this attack, allowing the TTLS server and TTLS client each to 819 verify that the other party knows the MSKs from all inner methods and 820 the TLS master secret before the authentication terminates. When 821 intermediate key confirmation is used, the TTLS server can verify 822 this at any point in the authentication process. If a MITM attack is 823 detected, the TTLS server can terminate authentication promptly to 824 prevent the later authentication steps from taking place. This can 825 avoid revealing sensitive information to the attacker, such as one- 826 time passwords or biometric data. 828 8.3. Protection Against Truncation Attacks 830 By truncating an EAP-TTLSv0 session, an attacker could cause the 831 client to believe that the session completed successfully when in 832 fact it was unsuccessful or incomplete. The implications of such an 833 attack depend on the particular inner methods in use and the 834 circumstances of the deployment but they could perhaps result in the 835 client using the wrong keying material for later communications, for 836 example. The Secure-Completion-Option, TTLS-Success, and TTLS-Failure 837 AVPs allow the client to require or request that the server and 838 client securely confirm the results of the authentication to each 839 other before the authentication is considered complete. Thus, any 840 truncation can easily be detected. 842 8.4. Protection Against Forged Results 844 EAP results (EAP-Success and EAP-Failure) are not generally protected 845 in transit from the server to the client. This means that the client 846 can be led to believe that an authentication failed when it actually 847 succeeded or vice versa. The Secure-Completion, TTLS-Success, and 848 TTLS-Failure AVPs allow the client to securely determine the results 849 of the authentication, thus foiling any attempt to forge or modify 850 the results of the authentication. 852 9. IANA Considerations 854 This section provides guidance to the Internet Assigned Numbers 855 Authority (IANA) regarding registration of values related to this 856 specification, in accordance with [IANA]. The term "IETF Consensus" 857 is used in this section with the meaning defined in [IANA]. 859 9.1. Allocation of AVP Codes 861 This specification requires the allocation and assignment of six AVP 862 Codes to identify new AVPs identified in this specification. As 863 described in RFC 3588, release of blocks of AVPs requires IETF 864 Consensus. 866 Once this document is approved as an RFC, the IANA is requested to 867 allocate and assign unique AVP Codes for the following six AVPs 868 defined in this specification: MSK-Computation, Key-Confirmation- 869 Option, Key-Confirmation, Secure-Completion-Option, TTLS-Success, and 870 TTLS-Failure. 872 Once these allocations and assignments have been made, they should be 873 added to this specification. For each AVP Code, there is a paragraph 874 like this one: 876 The AVP Code for the MSK-Computation AVP will be assigned by IANA 877 when this document moves to RFC status. In the mean time, a vendor- 878 specific AVP Code of 256 with a Vendor-ID field of 2636 should be 879 used for experimental purposes. 881 Once the AVP Code for the MSK-Computation AVP has been assigned, this 882 paragraph should be changed to read: 884 The AVP Code for the MSK-Computation AVP is [Assigned-AVP-Code]. In 885 order to allow implementation of this specification before assignment 886 of that code, a vendor-specific AVP Code of 256 with a Vendor-ID 887 field of 2636 has been used for experimental purposes. 888 Implementations of this RFC MUST accept the new standard AVP Code for 889 the MSK-Computation AVP, MAY accept the vendor-specific AVP Code, and 890 SHOULD only send the standard AVP Code. 892 This subsection (subsection 9.1) of the IANA Considerations section 893 may be removed once the AVP Codes have been assigned and the document 894 is ready to move to RFC status. 896 9.2. Creation of New Registries 898 This specification requires the creation of three new registries to 899 be managed by IANA: MSK Computation Methods, Key Confirmation 900 Options, and Secure Completion Options. 902 Each of these registries should be composed of numeric values in the 903 range 0 to 255. Each value should also have a name. Because of the 904 limited number of values available in each of these registries, 905 values should only be added to these registries if they achieve IETF 906 Consensus as defined in [IANA]. 908 A vendor extension mechanism has been defined to allow vendors to 909 define their own values similar in function to the IANA-reserved 910 values in these registries. This vendor extension mechanism is 911 described earlier in this specification. Such vendor-specific values 912 are not to be tracked or managed by IANA. 914 Certain values defined in this specification should be prepopulated 915 into these registries. The next three paragraphs enumerate those 916 values. 918 For the MSK Computation Methods registry, the values to be 919 prepopulated are 0 (with a name of "Default computation as defined in 920 RFC XXXX") and 1 (with a name of "Mixed computation mechanism as 921 defined in RFC YYYY"), where XXXX is replaced by the RFC number 922 assigned to [TTLSv0] and YYYY is replaced by the RFC number assigned 923 to this specification. 925 For the Key Confirmation Options registry, the values to be 926 prepopulated are 0 (with a name of "Disabled") and 1 (with a name of 927 "Enabled"). 929 For the Secure Completion Options registry, the values to be 930 prepopulated are 0 (with a name of "Disabled") and 1 (with a name of 931 "Enabled"). 933 When this document is ready to become an RFC, this paragraph and the 934 preceding four paragraphs can be deleted. 936 10. References 938 10.1. Normative References 940 [KEYWORDS]S. Bradner, "Key words for use in RFCs to Indicate 941 Requirement Levels", RFC 2119, March 1997. 943 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 944 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 946 [TTLSv0] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 947 Authentication Protocol Version 0", Internet Draft (work in 948 progress), draft-funk-eap-ttls-v0-01.txt, April 2007. 950 10.2. Informative References 952 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 953 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 954 3748, June 2004. 956 [EAPTLS] Simon, D. and B. Aboba, "PPP EAP TLS Authentication 957 Protocol", RFC 2716, October 1999. 959 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 960 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 961 October 1998. 963 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in 964 Tunnelled Authentication Protocols", Cryptology ePrint 965 Archive, Report 2002/163, http://eprint.iacr.org, 2002. 967 [PEN] IANA Private Enterprise Numbers, 968 http://www.iana.org/assignments/enterprise-numbers. 970 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 971 (TLS) Protocol Version 1.2", Internet Draft (work in 972 progress), draft-ietf-tls-rfc4346bis-04.txt, July 2007. 974 [8021X] IEEE Standards for Local and Metropolitan Area Networks: 975 Port based Network Access Control, IEEE Std 802.1X-2001, 976 June 2001. 978 Authors' Addresses 980 Steve Hanna 981 Juniper Networks, Inc. 982 1194 North Mathilda Avenue 983 Sunnyvale, CA 94089 USA 985 Email: shanna@juniper.net 987 Paul Funk 988 Juniper Networks, Inc. 989 1194 North Mathilda Avenue 990 Sunnyvale, CA 94089 USA 992 Email: pfunk@juniper.net 994 Intellectual Property Statement 996 The IETF takes no position regarding the validity or scope of any 997 Intellectual Property Rights or other rights that might be claimed to 998 pertain to the implementation or use of the technology described in 999 this document or the extent to which any license under such rights 1000 might or might not be available; nor does it represent that it has 1001 made any independent effort to identify any such rights. Information 1002 on the procedures with respect to rights in RFC documents can be 1003 found in BCP 78 and BCP 79. 1005 Copies of IPR disclosures made to the IETF Secretariat and any 1006 assurances of licenses to be made available, or the result of an 1007 attempt made to obtain a general license or permission for the use of 1008 such proprietary rights by implementers or users of this 1009 specification can be obtained from the IETF on-line IPR repository at 1010 http://www.ietf.org/ipr. 1012 The IETF invites any interested party to bring to its attention any 1013 copyrights, patents or patent applications, or other proprietary 1014 rights that may cover technology that may be required to implement 1015 this standard. Please address the information to the IETF at 1016 ietf-ipr@ietf.org. 1018 Copyright Statement 1020 Copyright (C) The IETF Trust (2007). 1022 This document is subject to the rights, licenses and restrictions 1023 contained in BCP 78, and except as set forth therein, the authors 1024 retain all their rights. 1026 Disclaimer of Validity 1028 This document and the information contained herein are provided on an 1029 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1030 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1031 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1032 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1033 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1034 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1036 Acknowledgment 1038 Funding for the RFC Editor function is currently provided by the 1039 Internet Society.