idnits 2.17.1 draft-ietf-tls-extensions-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([KEYWORDS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 700 has weird spacing: '...ensions reque...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '20' on line 600 == Unused Reference: 'HTTP' is defined on line 1029, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'IDNWG' -- Possible downref: Non-RFC (?) normative reference: ref. 'MAILING LIST' ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2633 (ref. 'SMIME') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) Summary: 17 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Simon Blake-Wilson, Certicom 3 INTERNET-DRAFT Magnus Nystrom, RSA Security 4 February 22, 2002 David Hopwood, Independent Consultant 5 Expires August 22, 2002 Jan Mikkelsen, Transactionware 6 Intended Category: Standards track Tim Wright, Vodafone 8 TLS Extensions 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or made obsolete by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts may be found at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories may be found at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes extensions that may be used to add 34 functionality to TLS. It provides both generic extension mechanisms 35 for the TLS handshake client and server hellos, and specific 36 extensions using these generic mechanisms. 38 The extensions may be used by TLS clients and servers. The extensions 39 are backwards compatible - communication is possible between TLS 1.0 40 clients that support the extensions and TLS 1.0 servers that do not 41 support the extensions, and vice versa. 43 This document is based on discussions within the TLS working group 44 and within the WAP security group. 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 50 Please send comments on this document to the TLS mailing list. 52 Table of Contents 54 1. Introduction .............................................. 2 55 2. General Extension Mechanisms .............................. 4 56 2.1. Extended Client Hello ................................... 4 57 2.2. Extended Server Hello ................................... 5 58 2.3. Hello Extensions ........................................ 6 59 2.4. Extensions to the handshake protocol .................... 7 60 3. Specific Extensions ....................................... 7 61 3.1. Server Name Indication .................................. 8 62 3.2. Maximum Fragment Length Negotiation ..................... 9 63 3.3. Client Certificate URLs ................................ 11 64 3.4. Trusted CA Indication .................................. 12 65 3.5. Truncated HMAC ......................................... 14 66 3.6. Certificate Status Request.............................. 15 67 4. Error alerts ............................................. 16 68 5. Procedure for Defining New Extensions..................... 18 69 6. Security Considerations .................................. 19 70 6.1. Security of server_name ................................ 19 71 6.2. Security of max_fragment_length ........................ 19 72 6.3. Security of client_certificate_url ..................... 20 73 6.4. Security of trusted_ca_keys ............................ 20 74 6.5. Security of truncated_hmac ............................. 21 75 6.6. Security of status_request ............................. 21 76 7. Internationalization Considerations .......................21 77 8. Intellectual Property Rights ............................. 22 78 9. Acknowledgments .......................................... 22 79 10. References ............................................... 22 80 11. Authors' Addresses ....................................... 23 82 1. Introduction 84 This document describes extensions that may be used to add 85 functionality to TLS. It provides both generic extension mechanisms 86 for the TLS handshake client and server hellos, and specific 87 extensions using these generic mechanisms. 89 TLS is now used in an increasing variety of operational environments 90 - many of which were not envisioned when the original design criteria 91 for TLS were determined. The extensions introduced in this document 92 are designed to enable TLS to operate as effectively as possible in 93 new environments like wireless networks. 95 Wireless environments often suffer from a number of constraints not 96 commonly present in wired environments - these constraints may 97 include bandwidth limitations, computational power limitations, 98 memory limitations, and battery life limitations. 100 The extensions described here focus on extending the functionality 101 provided by the TLS protocol message formats. Other issues, such as 102 the addition of new cipher suites, are deferred. 104 Specifically, the extensions described in this document are designed 105 to: 107 - Allow TLS clients to provide to the TLS server the name of the 108 server they are contacting. This functionality is desirable to 109 facilitate secure connections to servers that host multiple 110 'virtual' servers at a single underlying network address. 112 - Allow TLS clients and servers to negotiate the maximum fragment 113 length to be sent. This functionality is desirable as a result of 114 memory constraints among some clients, and bandwidth constraints 115 among some access networks. 117 - Allow TLS clients and servers to negotiate the use of client 118 certificate URLs. This functionality is desirable in order to 119 conserve memory on constrained clients. 121 - Allow TLS clients to indicate to TLS servers which CA root keys 122 they possess. This functionality is desirable in order to prevent 123 multiple handshake failures involving TLS clients that are only 124 able to store a small number of CA root keys due to memory 125 limitations. 127 - Allow TLS clients and servers to negotiate the use of truncated 128 MACs. This functionality is desirable in order to conserve 129 bandwidth in constrained access networks. 131 - Allow TLS clients and servers to negotiate that the server sends 132 the client certificate status information (e.g. an OCSP [OCSP] 133 response) during a TLS handshake. This functionality is desirable 134 in order to avoid sending a CRL over a constrained access network 135 and therefore save bandwidth. 137 In order to support the extensions above, general extension 138 mechanisms for the client hello message and the server hello message 139 are introduced. 141 The extensions described in this document may be used by TLS 1.0 142 clients and TLS 1.0 servers. The extensions are designed to be 143 backwards compatible - meaning that TLS 1.0 clients that support the 144 extensions can talk to TLS 1.0 servers that do not support the 145 extensions, and vice versa. 147 Backwards compatibility is primarily achieved via two considerations: 149 - Clients typically request the use of extensions via the extended 150 client hello message described in Section 2.1. TLS 1.0 [TLS] 151 requires servers to "accept" extended client hello messages, even 152 if the server does not "understand" the extension. 154 - For the specific extensions described here, no mandatory server 155 response is required when clients request extended functionality. 157 Note however, that although backwards compatibility is supported, 158 some constrained clients may be forced to reject communications with 159 servers that do not support the extensions as a result of the limited 160 capabilities of such clients. 162 The remainder of this document is organized as follows. Section 2 163 describes general extension mechanisms for the client hello and 164 server hello handshake messages. Section 3 describes specific 165 extensions to TLS 1.0. Section 4 describes new error alerts for use 166 with the TLS extensions. The final sections of the document address 167 IPR, security considerations, acknowledgements, and references. 169 2. General Extension Mechanisms 171 This section presents general extension mechanisms for the TLS 172 handshake client hello and server hello messages. 174 These general extension mechanisms are necessary in order to enable 175 clients and servers to negotiate whether to use specific extensions, 176 and how to use specific extensions. The extension formats described 177 are based on [MAILING LIST]. 179 Section 2.1 specifies the extended client hello message format, 180 Section 2.2 specifies the extended server hello message format, and 181 Section 2.3 describes the actual extension format used with the 182 extended client and server hellos. 184 2.1. Extended Client Hello 186 Clients MAY request extended functionality from servers by sending 187 the extended client hello message format in place of the client hello 188 message format. The extended client hello message format is: 190 struct { 191 ProtocolVersion client_version; 192 Random random; 193 SessionID session_id; 194 CipherSuite cipher_suites<2..2^16-1>; 195 CompressionMethod compression_methods<1..2^8-1>; 196 Extension client_hello_extension_list<0..2^16-1>; 197 } ClientHello; 199 Here the new "client_hello_extension_list" field contains a list of 200 extensions. The actual "Extension" format is defined in Section 2.3. 202 In the event that clients request additional functionality using the 203 extended client hello, and this functionality is not supplied by the 204 server, clients MAY abort the handshake. 206 Note that [TLS], Section 7.4.1.2, allows additional information to be 207 added to the client hello message. Thus the use of the extended 208 client hello defined above should not "break" existing TLS 1.0 209 servers. 211 A server that supports the extensions mechanism MUST accept only 212 client hello messages in either the original or extended ClientHello 213 format, and (as for all other messages) MUST check that the amount of 214 data in the message precisely matches one of these formats; if not 215 then it MUST send a fatal "decode_error" alert. This overrides the 216 "Forward compatibility note" in [TLS]. 218 2.2. Extended Server Hello 220 The extended server hello message format MAY be sent in place of the 221 server hello message when the client has requested extended 222 functionality via the extended client hello message specified in 223 Section 2.1. The extended server hello message format is: 225 struct { 226 ProtocolVersion server_version; 227 Random random; 228 SessionID session_id; 229 CipherSuite cipher_suite; 230 CompressionMethod compression_method; 231 Extension server_hello_extension_list<0..2^16-1>; 232 } ServerHello; 234 Here the new "server_hello_extension_list" field contains a list of 235 extensions. The actual "Extension" format is defined in Section 2.3. 237 Note that the extended server hello message is only sent in response 238 to an extended client hello message. This prevents the possibility 239 that the extended server hello message could "break" existing TLS 1.0 240 clients. 242 2.3. Hello Extensions 244 The extension format for extended client hellos and extended server 245 hellos is: 247 struct { 248 ExtensionType extension_type; 249 opaque extension_data<0..2^16-1>; 250 } Extension; 252 Here: 254 - "extension_type" identifies the particular extension type. 256 - "extension_data" contains information specific to the particular 257 extension type. 259 The extension types defined in this document are: 261 enum { 262 server_name(0), max_fragment_length(1), 263 client_certificate_url(2), trusted_ca_keys(3), 264 truncated_hmac(4), status_request(5), (65535) 265 } ExtensionType; 267 Note that for all extension types (including those defined in 268 future), the extension type MUST NOT appear in the extended server 269 hello unless the same extension type appeared in the corresponding 270 client hello. Thus clients MUST abort the handshake if they receive 271 an extension type in the extended server hello that they did not 272 request in the associated (extended) client hello. 274 Nonetheless "server initiated" extensions may be provided in the 275 future within this framework by requiring the client to first send an 276 empty extension to indicate that it supports a particular extension. 278 Also note that when multiple extensions of different types are 279 present in the extended client hello or the extended server hello, 280 the extensions may appear in any order. There MUST NOT be more than 281 one extension of the same type. 283 Finally note that all the extensions defined in this document are 284 relevant only when a session is initiated. However, a client that 285 requests resumption of a session does not in general know whether the 286 server will accept this request, and therefore it SHOULD send an 287 extended client hello if it would normally do so for a new session. 288 If the resumption request is denied, then a new set of extensions 289 will be negotiated as normal. If, on the other hand, the older 290 session is resumed, then the server MUST ignore extensions appearing 291 in the client hello, and send a server hello containing no 292 extensions; in this case the extension functionality negotiated 293 during the original session initiation is applied to the resumed 294 session. 296 2.4. Extensions to the handshake protocol 298 This document suggests the use of two new handshake messages, 299 "CertificateURL" and "CertificateStatus". These messages are 300 described in Section 3.3 and Section 3.6, respectively. The new 301 handshake message structure therefore becomes: 303 enum { 304 hello_request(0), client_hello(1), server_hello(2), 305 certificate(11), server_key_exchange (12), 306 certificate_request(13), server_hello_done(14), 307 certificate_verify(15), client_key_exchange(16), 308 finished(20), certificate_url(21), certificate_status(22), 309 (255) 310 } HandshakeType; 312 struct { 313 HandshakeType msg_type; /* handshake type */ 314 uint24 length; /* bytes in message */ 315 select (HandshakeType) { 316 case hello_request: HelloRequest; 317 case client_hello: ClientHello; 318 case server_hello: ServerHello; 319 case certificate: Certificate; 320 case server_key_exchange: ServerKeyExchange; 321 case certificate_request: CertificateRequest; 322 case server_hello_done: ServerHelloDone; 323 case certificate_verify: CertificateVerify; 324 case client_key_exchange: ClientKeyExchange; 325 case finished: Finished; 326 case certificate_url: CertificateURL; 327 case certificate_status: CertificateStatus; 328 } body; 329 } Handshake; 331 3. Specific Extensions 333 This section describes the specific TLS extensions specified in this 334 document. 336 Note that any messages associated with these extensions that are sent 337 during the TLS handshake MUST be included in the hash calculations 338 involved in "Finished" messages. 340 Section 3.1 describes the extension of TLS to allow a client to 341 indicate which server it is contacting. Section 3.2 describes the 342 extension to provide maximum fragment length negotiation. Section 3.3 343 describes the extension to allow client certificate URLs. Section 3.4 344 describes the extension to allow a client to indicate which CA root 345 keys it possesses. Section 3.5 describes the extension to allow the 346 use of truncated HMAC. Section 3.6 describes the extension to 347 support integration of certificate status information messages into 348 TLS handshakes. 350 3.1. Server Name Indication 352 [TLS] does not provide a mechanism for a client to tell a server the 353 name of the server it is contacting. It may be desirable for clients 354 to provide this information to facilitate secure connections to 355 servers that host multiple 'virtual' servers at a single underlying 356 network address. 358 In order to provide the server name, clients MAY include an extension 359 of type "server_name" in the (extended) client hello. The 360 "extension_data" field of this extension SHALL contain 361 "ServerNameList" where: 363 struct { 364 NameType name_type; 365 select (name_type) { 366 case host_name: HostName; 367 } 368 } ServerName; 370 enum { 371 host_name(0), (255) 372 } NameType; 374 opaque HostName<1..2^16-1>; 376 struct { 377 ServerName server_name_list<1..2^16-1> 378 } ServerNameList; 380 Currently the only server names supported are DNS hostnames, however 381 this does not imply any dependency of TLS on DNS, and other name 382 types may be added in the future (by an RFC that Updates this 383 document). TLS MAY treat provided server names as opaque data and 384 pass the names and types to the application. 386 "HostName" contains the fully qualified DNS hostname of the server, 387 as understood by the client. The hostname is represented as a byte 388 string using UTF-8 encoding [UTF8], without a trailing dot. (Note 389 that the use of UTF-8 here for encoding internationalized hostnames 390 is independent of the choice of encoding for these names in the DNS 391 protocol. The latter has yet to be decided by the IETF 392 Internationalized Domain Name Working Group [IDNWG].) 394 If the server needs to match the HostName against names that contain 395 non-ASCII characters (that is, if it has one or more 396 internationalized virtual host names), it MUST take account of name 397 equivalence rules that will be defined by the IDN Working Group. If 398 the server only needs to match the HostName against names containing 399 exclusively ASCII characters, it MUST NOT treat a HostName that 400 contains a byte value >= 128 as matching any ASCII name, and it MUST 401 compare ASCII names case-insensitively. 403 Literal IPv4 and IPv6 addresses are not permitted in "HostName". 405 It is RECOMMENDED that clients include an extension of type 406 "server_name" in the client hello whenever they locate a server by a 407 supported name type. 409 A server that receives a client hello containing the "server_name" 410 extension, MAY use the information contained in the extension to 411 guide its selection of an appropriate certificate to return to the 412 client, and/or other aspects of security policy. In this event, the 413 server SHALL include an extension of type "server_name" in the 414 (extended) server hello. The "extension_data" field of this extension 415 SHALL be empty. 417 If the server understood the client hello extension but does not 418 recognize the server name, it SHOULD send an "unrecognized_name" 419 alert (which MAY be fatal). 421 If an application negotiates a server name using an application 422 protocol, then upgrades to TLS, and a server_name extension is sent, 423 then the extension SHOULD contain the same name that was negotiated 424 in the application protocol. If the server_name is established in the 425 TLS session handshake, the client SHOULD NOT attempt to request a 426 different server name at the application layer. 428 3.2. Maximum Fragment Length Negotiation 430 [TLS] specifies a fixed maximum plaintext fragment length of 2^14 431 bytes. It may be desirable for constrained clients to negotiate a 432 smaller maximum fragment length due to memory limitations or 433 bandwidth limitations. 435 In order to negotiate smaller maximum fragment lengths, clients MAY 436 include an extension of type "max_fragment_length" in the (extended) 437 client hello. The "extension_data" field of this extension SHALL 438 contain: 440 enum{ 441 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) 442 } MaxFragmentLength; 444 whose value is the desired maximum fragment length. The allowed 445 values for this field are: 2^9, 2^10, 2^11, and 2^12. 447 Servers that receive an extended client hello containing a 448 "max_fragment_length" extension, MAY accept the requested maximum 449 fragment length by including an extension of type 450 "max_fragment_length" in the (extended) server hello. The 451 "extension_data" field of this extension SHALL contain 452 "MaxFragmentLength" whose value is the same as the requested maximum 453 fragment length. 455 If a server receives a maximum fragment length negotiation request 456 for a value other than the allowed values, it MUST abort the 457 handshake with an "illegal_parameter" alert. Similarly, if a client 458 receives a maximum fragment length negotiation response that differs 459 from the length it requested, it MUST also abort the handshake with 460 an "illegal_parameter" alert. 462 Once a maximum fragment length other than 2^14 has been successfully 463 negotiated, the client and server MUST immediately begin fragmenting 464 messages (including handshake messages), to ensure that no fragment 465 larger than the negotiated length is sent. Note that TLS already 466 requires clients and servers to support fragmentation of handshake 467 messages. 469 The negotiated length applies for the duration of the session 470 including session resumptions. 472 The negotiated length limits the input that the record layer may 473 process without fragmentation (that is, the maximum value of 474 TLSPlaintext.length; see [TLS] section 6.2.1). Note that the output 475 of the record layer may be larger. For example, if the negotiated 476 length is 2^9=512, then for currently defined cipher suites (those 477 defined in [TLS], [KERB], and planned AES ciphersuites), the record 478 layer output can be at most 793 bytes: 5 bytes of headers, 512 bytes 479 of application data, 256 bytes of padding, and 20 bytes of MAC. That 480 means that in this event a TLS record layer peer receiving a TLS 481 record layer message larger than 793 bytes may discard the message 482 and send a "record_overflow" alert, without decrypting the message. 484 3.3. Client Certificate URLs 486 [TLS] specifies that when client authentication is performed, client 487 certificates are sent by clients to servers during the TLS handshake. 488 It may be desirable for constrained clients to send certificate URLs 489 in place of certificates, so that they do not need to store their 490 certificates and can therefore save memory. 492 In order to negotiate to send certificate URLs to a server, clients 493 MAY include an extension of type "client_certificate_url" in the 494 (extended) client hello. The "extension_data" field of this extension 495 SHALL be empty. 497 (Note that it is necessary to negotiate use of client certificate 498 URLs in order to avoid "breaking" existing TLS 1.0 servers.) 500 Servers that receive an extended client hello containing a 501 "client_certificate_url" extension, MAY indicate that they are 502 willing to accept certificate URLs by including an extension of type 503 "client_certificate_url" in the (extended) server hello. The 504 "extension_data" field of this extension SHALL be empty. 506 After negotiation of the use of client certificate URLs has been 507 successfully completed (by exchanging hellos including 508 "client_certificate_url" extensions), clients MAY send a 509 "CertificateURL" message in place of a "Certificate" message: 511 struct { 512 URLAndHash url_and_hash_list<1..2^16-1>; 513 } CertificateURL; 515 struct { 516 opaque URL<1..2^16-1>; 517 CertHash certificate_hash; 518 } URLAndHash; 520 opaque CertHash<0..20>; 522 Here "url_and_hash_list" contains a sequence of URLs and hashes. 524 When X.509 certificates are used, each URL refers either to a single, 525 DER-encoded X.509v3 certificate, or to a PKCS #7 certificate chain. 526 For ciphersuites using other certificate formats, the ciphersuite 527 specification must define the encoding format of certificates or 528 certificate chains, and any constraint on their ordering, if this 529 message is to be used. 531 The hash corresponding to each URL at the client's discretion is 532 either empty or it contains the SHA-1 hash of the certificate or 533 certificate chain (in the case of X.509 certificates, the DER-encoded 534 certificate or the DER-encoded CertificateSet, see [CMS]). 536 For X.509, URLs MUST occur in the list in the same order that the 537 corresponding certificates appear in the certificate chain. 539 Servers receiving "CertificateURL" SHALL attempt to retrieve the 540 client's certificate chain from the URLs, and then process the 541 certificate chain as usual. Servers that support this extension MUST 542 support the http: URL scheme for certificate URLs, and MAY support 543 other schemes. 545 In general, the format of the certificates retrieved by the server 546 will depend on the protocol used by the server to retrieve them, as 547 recommended by the PKIX working group. In the case of HTTP, the 548 response MUST be a MIME formatted response. When a single X.509v3 549 certificate is returned, the Content-type is application/pkix-cert 550 [PKIOP]. When a chain of X.509v3 certificates is returned, the 551 Content-type is application/pkcs7-mime [SMIME]. 553 Servers MUST check that the SHA-1 hash of any certificates retrieved 554 from a CertificateURL matches the given hash if it is present. If 555 any retrieved certificate does not have the correct SHA-1 hash, the 556 server MUST abort the handshake with a "bad_certificate_hash_value" 557 alert. 559 Note that clients may choose to send either "Certificate" or 560 "CertificateURL" after successfully negotiating the option to send 561 certificate URLs. The option to send a certificate is included to 562 provide flexibility to clients possessing multiple certificates. 564 If a server encounters an unreasonable delay in obtaining 565 certificates in a given CertificateURL, it SHOULD time out and signal 566 a "certificate_unobtainable" error alert. 568 3.4. Trusted CA Indication 570 Constrained clients that, due to memory limitations, possess only a 571 small number of CA root keys, may wish to indicate to servers which 572 root keys they possess, in order to avoid repeated handshake 573 failures. 575 In order to indicate which CA root keys they possess, clients MAY 576 include an extension of type "trusted_ca_keys" in the (extended) 577 client hello. The "extension_data" field of this extension SHALL 578 contain "TrustedAuthorities" where: 580 struct { 581 TrustedAuthority trusted_authorities_list<0..2^16-1>; 582 } TrustedAuthorities; 584 struct { 585 IdentifierType identifier_type; 586 select (identifier_type) { 587 case pre_agreed: struct {}; 588 case key_hash_sha: KeyHash; 589 case x509_name: DistinguishedName; 590 case cert_hash: CertHash; 591 } Identifier; 592 } TrustedAuthority; 594 enum { pre_agreed(0), key_hash_sha(1), x509_name(2), cert_hash(3), 595 (255)} 596 IdentifierType; 598 opaque DistinguishedName<1..2^16-1>; 600 opaque KeyHash[20]; 602 Here "TrustedAuthorities" provides a list of CA root key identifiers 603 that the client possesses. Each CA root key is identified via either: 605 - "pre_agreed" - no CA root key identity supplied. 607 - "key_hash_sha" - contains the SHA-1 hash of the CA root key. For 608 DSA and ECDSA keys, this is the hash of the "subjectPublicKey" 609 value. For RSA keys, this is the hash of the byte string 610 representation of the modulus (without any initial 0-valued 611 bytes). (This copies the key hash formats deployed in other 612 environments.) 614 - "cert_hash" - contains the SHA-1 hash of a certificate containing 615 the CA root key. 617 - "x509_name" - contains the X.509 Distinguished Name of the CA. 619 Note that clients may include none, some, or all of the CA root keys 620 they possess in this extension. 622 Note also that it is possible that a key hash or a Distinguished Name 623 alone may not uniquely identify a certificate issuer - for example if 624 a particular CA has multiple key pairs - however here we assume this 625 is the case following the use of Distinguished Names to identify 626 certificate issuers in TLS. 628 The option to include no CA root keys is included to allow the client 629 to indicate possession of some pre-defined set of CA root keys. 631 Servers that receive a client hello containing the "trusted_ca_keys" 632 extension, MAY use the information contained in the extension to 633 guide their selection of an appropriate certificate chain to return 634 to the client. In this event, the server SHALL include an extension 635 of type "trusted_ca_keys" in the (extended) server hello. The 636 "extension_data" field of this extension SHALL be empty. 638 3.5. Truncated HMAC 640 Currently defined TLS ciphersuites use the MAC construction HMAC with 641 either MD5 or SHA-1 [HMAC] to authenticate record layer 642 communications. In TLS the entire output of the hash function is used 643 as the MAC tag. However it may be desirable in constrained 644 environments to save bandwidth by truncating the output of the hash 645 function to 80 bits when forming MAC tags. 647 In order to negotiate the use of 80-bit truncated HMAC, clients MAY 648 include an extension of type "truncated_hmac" in the extended client 649 hello. The "extension_data" field of this extension SHALL be empty. 651 Servers that receive an extended hello containing a "truncated_hmac" 652 extension, MAY agree to use a truncated HMAC by including an 653 extension of type "truncated_hmac" in the extended server hello. 655 Note that if new ciphersuites are added that do not use HMAC, and the 656 session negotiates one of these ciphersuites, this extension will 657 have no effect. It is strongly recommended that any new cipher suites 658 using other MACs consider the MAC size as an integral part of the 659 cipher suite definition, taking into account both security and 660 bandwidth considerations. 662 If HMAC truncation has been successfully negotiated during a TLS 663 handshake, and the negotiated ciphersuite uses HMAC, both the client 664 and the server pass this fact to the TLS record layer along with the 665 other negotiated security parameters. Subsequently during the 666 session, clients and servers MUST use truncated HMACs, calculated as 667 specified in [HMAC]. That is, CipherSpec.hash_size is 10 bytes, and 668 only the first 10 bytes of the HMAC output are transmitted and 669 checked. Note that this extension does not affect the calculation of 670 the PRF as part of handshaking or key derivation. 672 The negotiated HMAC truncation size applies for the duration of the 673 session including session resumptions. 675 3.6. Certificate Status Request 677 Constrained clients may wish to use a certificate-status protocol 678 such as OCSP [OCSP] to check the validity of server certificates, in 679 order to avoid transmission of CRLs and therefore save bandwidth on 680 constrained networks. This extension allows for such information to 681 be sent in the TLS handshake, saving roundtrips and resources. 683 In order to indicate their desire to receive certificate status 684 information, clients MAY include an extension of type 685 "status_request" in the (extended) client hello. The "extension_data" 686 field of this extension SHALL contain "CertificateStatusRequest" 687 where: 689 struct { 690 CertificateStatusType status_type; 691 select (status_type) { 692 case ocsp: OCSPStatusRequest; 693 } 694 } CertificateStatusRequest; 696 enum { ocsp(1), 255) } CertificateStatusType; 698 struct { 699 ResponderID responder_id_list<0..2^16-1>; 700 Extensions request_extensions; 701 } OCSPStatusRequest; 703 opaque ResponderID<1..2^16-1>; 704 opaque Extensions<0..2^16-1>; 706 In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP 707 responders that the client trusts. A zero-length "responder_id_list" 708 sequence has the special meaning that the responders are implicitly 709 known to the server - e.g. by prior arrangement. "Extensions" is a 710 DER encoding of OCSP request extensions. 712 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as 713 defined in [OCSP]. 715 Servers that receive a client hello containing the "status_request" 716 extension, MAY return a suitable certificate status response to the 717 client along with their certificate. If OCSP is requested, they 718 SHOULD use the information contained in the extension when selecting 719 an OCSP responder, and SHOULD include request_extensions in the OCSP 720 request. 722 Servers return a certificate response along with their certificate by 723 sending a "CertificateStatus" message immediately after the 724 "Certificate" message (and before any "ServerKeyExchange" or 725 "CertificateRequest" messages). If a server returns a 726 "CertificateStatus" message, then the server MUST have included an 727 extension of type "status_request" with empty "extension_data" in the 728 extended server hello. 730 struct { 731 CertificateStatusType status_type; 732 select (status_type) { 733 case ocsp: OCSPResponse ocsp_response; 734 } 735 } CertificateStatus; 737 opaque OCSPResponse<1..2^24-1>; 739 An "ocsp_response" contains a complete, DER-encoded OCSP response 740 (using the ASN.1 type OCSPResponse defined in [OCSP]). Note that only 741 one OCSP response may be sent. 743 The "CertificateStatus" message is conveyed using the handshake 744 message type "certificate_status". 746 Note that a server MAY also choose not to send a "CertificateStatus" 747 message, even if it receives a "status_request" extension in the 748 client hello message. 750 Note in addition that servers MUST NOT send the "CertificateStatus" 751 message unless it received a "status_request" extension in the client 752 hello message. 754 Clients requesting an OCSP response, and receiving an OCSP response 755 in a "CertificateStatus" message MUST check the OCSP response and 756 abort the handshake if the response is not satisfactory. 758 4. Error Alerts 760 This section defines new error alerts for use with the TLS extensions 761 defined in this document. 763 The following new error alerts are defined. To avoid "breaking" 764 existing clients and servers, these alerts MUST NOT be sent unless 765 the sending party has received an extended hello message from the 766 party they are communicating with. 768 - "unsupported_extension" - this alert is sent by clients that 769 receive an extended server hello containing an extension that 770 they did not put in the corresponding client hello (see Section 771 2.3). This message is always fatal. 773 - "unrecognized_name" - this alert is sent by servers that 774 receive a server_name extension request, but do not recognize the 775 server name. This message MAY be fatal. 777 - "certificate_unobtainable" - this alert is sent by servers who are 778 unable to retrieve a certificate chain from the URL supplied by 779 the client (see Section 3.3). This message MAY be fatal - for 780 example if client authentication is required by the server for the 781 handshake to continue and the server is unable to retrieve the 782 certificate chain, it may send a fatal alert. 784 - "bad_certificate_status_response" - this alert is sent by clients 785 that receive an invalid certificate status response (see Section 786 3.6). This message is always fatal. 788 - "bad_certificate_hash_value" - this alert is sent by servers when 789 a certificate hash does not match a client provided 790 certificate_hash. This message is always fatal. 792 These error alerts are conveyed using the following syntax: 794 enum { 795 close_notify(0), 796 unexpected_message(10), 797 bad_record_mac(20), 798 decryption_failed(21), 799 record_overflow(22), 800 decompression_failure(30), 801 handshake_failure(40), 802 /* 41 is not defined, for historical reasons */ 803 bad_certificate(42), 804 unsupported_certificate(43), 805 certificate_revoked(44), 806 certificate_expired(45), 807 certificate_unknown(46), 808 illegal_parameter(47), 809 unknown_ca(48), 810 access_denied(49), 811 decode_error(50), 812 decrypt_error(51), 813 export_restriction(60), 814 protocol_version(70), 815 insufficient_security(71), 816 internal_error(80), 817 user_canceled(90), 818 no_renegotiation(100), 819 unsupported_extension(110), /* new */ 820 certificate_unobtainable(111), /* new */ 821 unrecognized_name(112), /* new */ 822 bad_certificate_status_response(113), /* new */ 823 bad_certificate_hash_value(114), /* new */ 824 (255) 825 } AlertDescription; 827 5. Procedure for Defining New Extensions 829 Traditionally for Internet protocols, the Internet Assigned Numbers 830 Authority (IANA) handles the allocation of new values for future 831 expansion, and RFCs usually define the procedure to be used by the 832 IANA. However, there are subtle (and not so subtle) interactions that 833 may occur in this protocol between new features and existing features 834 which may result in a significant reduction in overall security. 836 Therefore, requests to define new extensions (including assigning 837 extension and error alert numbers) should be forwarded to the IETF 838 TLS Working Group for discussion. 840 The following considerations should be taken into account when 841 designing new extensions: 843 - All of the extensions defined in this document follow the 844 convention that for each extension that a client requests 845 and that the server understands, the server replies with an 846 extension of the same type. 848 - Some cases where a server does not agree to an extension are 849 error conditions, and some simply a refusal to support a 850 particular feature. In general error alerts should be used for 851 the former, and a field in the server extension response for 852 the latter. 854 - Extensions should as far as possible be designed to prevent 855 any attack that forces use (or non-use) of a particular feature 856 by manipulation of handshake messages. This principle should 857 be followed regardless of whether the feature is believed 858 to cause a security problem. 860 Often the fact that the extension fields are included in the 861 inputs to the Finished message hashes will be sufficient, 862 but extreme care is needed when the extension changes the 863 meaning of messages sent in the handshake phase. 864 Designers and implementors should be aware of the fact that 865 until the handshake has been authenticated, active attackers 866 can modify messages and insert, remove, or replace extensions. 868 - It would be technically possible to use extensions to change 869 major aspects of the design of TLS; for example the design of 870 ciphersuite negotiation. This is not recommended; it 871 would be more appropriate to define a new version of TLS - 872 particularly since the TLS handshake algorithms have specific 873 protection against version rollback attacks based on the 874 version number, and the possibility of version rollback 875 should be a significant consideration in any major design 876 change. 878 6. Security Considerations 880 Security considerations for the extension mechanism in general, and 881 the design of new extensions, are described in the previous section. 882 A security analysis of each of the extensions defined in this 883 document is given below. 885 In general, implementers should continue to monitor the state of the 886 art, and address any weaknesses identified. 888 Additional security considerations are described in the TLS 1.0 RFC 889 [TLS]. 891 6.1. Security of server_name 893 If a single server hosts several domains, then clearly it is 894 necessary for the owners of each domain to ensure that this satisfies 895 their security needs. Apart from this, server_name does not appear to 896 introduce significant security issues. 898 Implementations MUST ensure that a buffer overflow does not occur 899 whatever the values of the length fields in server_name. 901 6.2. Security of max_fragment_length 903 The maximum fragment length takes effect immediately, including for 904 handshake messages. However, that does not introduce any security 905 complications that are not already present in TLS, since [TLS] 906 requires implementations to be able to handle fragmented handshake 907 messages. 909 Note that as described in section 3.2, once a non-null ciphersuite 910 has been activated, the effective maximum fragment length depends on 911 the ciphersuite, as well as on the negotiated max_fragment_length. 912 This must be taken into account when sizing buffers, and checking for 913 buffer overflow. 915 6.3. Security of client_certificate_url 917 The major issue with this extension is whether or not clients should 918 include certificate hashes when they send certificate URLs. 920 When client authentication is used *without* the 921 client_certificate_url extension, the client certificate chain is 922 covered by the Finished message hashes. The purpose of including 923 certificate hashes and checking them against the retrieved 924 certificate chain, is to ensure that the same property holds when 925 this extension is used - i.e. that all of the information in the 926 certificate chain retrieved by the server is as the client intended. 928 On the other hand, omitting certificate hashes enables functionality 929 that is desirable in some circumstances - for example clients can be 930 issued daily certificates that are stored at a fixed URL and need not 931 be provided to the client. Clients that choose to omit certificate 932 hashes should be aware of the possibility of an attack in which the 933 attacker obtains a valid certificate on the client's key that is 934 different from the certificate the client intended to provide. 936 Note that although TLS uses both MD5 and SHA-1 hashes in several 937 other places, this was not believed to be necessary here. The 938 property required of SHA-1 is second pre-image resistance. 940 Support for client_certificate_url involves the server acting as a 941 client in another protocol (usually HTTP, but other URL schemes are 942 not prohibited). It is therefore subject to many of the same security 943 considerations that apply to a publicly accessible HTTP proxy server. 944 This includes the possibility that an attacker might use the server 945 to indirectly attack another host that is vulnerable to some security 946 flaw. It also includes potentially increased exposure to denial of 947 service attacks: an attacker can make many connections, each of which 948 results in the server making an HTTP request. 950 It is RECOMMENDED that the client_certificate_url extension should 951 have to be specifically enabled by a server administrator, rather 952 than being enabled by default. 954 As discussed in [URI], URLs that specify ports other than the default 955 may cause problems, as may very long URLs (which are more likely to 956 be useful in exploiting buffer overflow bugs). 958 6.4. Security of trusted_ca_keys 960 It is possible that which CA root keys a client possesses could be 961 regarded as confidential information. As a result, the CA root key 962 indication extension should be used with care. 964 The use of the SHA-1 certificate hash alternative ensures that each 965 certificate is specified unambiguously. As for the previous 966 extension, it was not believed necessary to use both MD5 and SHA-1 967 hashes. 969 6.5. Security of truncated_hmac 971 It is possible that truncated MACs are weaker than "un-truncated" 972 MACs. However, no significant weaknesses are currently known or 973 expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. 974 Note that the output length of a MAC need not be as long as the 975 length of a symmetric cipher key, since forging of MAC values cannot 976 be done off-line: in TLS, a single failed MAC guess will cause the 977 immediate termination of the TLS session. 979 Since the MAC algorithm only takes effect after the handshake 980 messages have been authenticated by the hashes in the Finished 981 messages, it is not possible for an active attacker to force 982 negotiation of the truncated HMAC extension where it would not 983 otherwise be used (to the extent that the handshake authentication is 984 secure). Therefore, in the event that any security problem were found 985 with truncated HMAC in future, if either the client or the server for 986 a given session were updated to take into account the problem, they 987 would be able to veto use of this extension. 989 6.6. Security of status_request 991 If a client requests an OCSP response, it must take into account that 992 an attacker's server using a compromised key could (and probably 993 would) pretend not to support the extension. A client that requires 994 OCSP validation of certificates SHOULD be prepared to contact the 995 OCSP server directly in this case. 997 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may 998 improve security against attacks that attempt to replay OCSP 999 responses; see section 4.4.1 of [OCSP] for further details. 1001 7. Internationalization Considerations 1003 None of the extensions defined here directly use strings subject to 1004 localization. DNS hostnames are encoded using UTF-8. If future 1005 extensions use text strings, then internationalization should be 1006 considered in their design. 1008 8. Intellectual Property Rights 1010 The IETF invites any interested party to bring to its attention any 1011 copyrights, patents or patent applications, or other proprietary 1012 rights which may cover technology that may be required to practice 1013 this document. Please address the information to the IETF Executive 1014 Director. 1016 9. Acknowledgments 1018 The authors wish to thank the TLS Working Group and the WAP Security 1019 Group. This document is based on discussion within these groups. 1021 10. References 1023 [CMS] R. Housley, "Cryptographic Message Syntax," IETF RFC 2630, June 1024 1999. 1026 [HMAC] Krawczyk, H., Bellare, M., and Canetti, R. - HMAC: Keyed- 1027 hashing for message authentication. IETF RFC 2104, February 1997. 1029 [HTTP] J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. 1030 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1," IETF RFC 1031 2616, June 1999. 1033 [IDNWG] IETF Internationalized Domain Name Working Group, 1034 http://www.i-d-n.net/ 1036 [KERB] A. Medvinsky, M. Hur, "Addition of Kerberos Cipher Suites to 1037 Transport Layer Security (TLS)," IETF RFC 2712, October 1999. 1039 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 1040 Requirement Levels," IETF RFC 2119, March 1997. 1042 [MAILING LIST] Mikkelsen, J. Eberhard, R., and J. Kistler, "General 1043 ClientHello extension mechanism and virtual hosting," Ietf-tls 1044 mailing list posting, August 14, 2000. 1046 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1047 Adams, "Internet X.509 Public Key Infrastructure: Online Certificate 1048 Status Protocol - OCSP," IETF RFC 2560, June 1999. 1050 [PKIOP] Housley, R., and P. Hoffman, "Internet X.509 Public Key 1051 Infrastructure - Operation Protocols: FTP and HTTP," IETF RFC 2585, 1052 May 1999. 1054 [SMIME] B. Ramsdell, "S/MIME Version 3 Message Specification," IETF 1055 RFC 2633, June 1999. 1057 [TLS] Dierks, T., and C. Allen, "The TLS Protocol - Version 1.0," 1058 IETF RFC 2246, January 1999. 1060 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 1061 Identifiers (URI): Generic Syntax," IETF RFC 2396, August 1998. 1063 [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 10646," 1064 IETF RFC 2279, January 1998. 1066 11. Authors' Addresses 1068 Simon Blake-Wilson 1069 Certicom Corp. 1070 sblake-wilson@certicom.com 1072 Magnus Nystrom 1073 RSA Security 1074 magnus@rsasecurity.com 1076 David Hopwood 1077 Independent Consultant 1078 david.hopwood@zetnet.co.uk 1080 Jan Mikkelsen 1081 Transactionware 1082 janm@transactionware.com 1084 Tim Wright 1085 Vodafone 1086 timothy.wright@vf.vodafone.co.uk