idnits 2.17.1 draft-ietf-tls-rfc4366-bis-03.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 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1017. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1023. 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 abstract seems to contain references ([RFC5246]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 581 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.) -- The document date (October 5, 2008) is 5679 days in the past. Is this intentional? -- 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 366 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3268 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TLS Working Group Donald Eastlake 3rd 2 INTERNET-DRAFT Eastlake Enterprises 3 Obsoletes: RFC 4366 4 Intended status: Proposed Standard 5 Expires: April 4, 2009 October 5, 2008 7 Transport Layer Security (TLS) Extensions: Extension Definitions 9 11 Status of This Document 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Distribution of this document is unlimited. Comments should be sent 19 to the TLS working group mailing list . 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document provides documentation for existing specific TLS 40 extensions. It is a companion document for the TLS 1.2 specification 41 [RFC5246]. The extensions specified are server_name, 42 max_fragment_length, client_certificate_url, trusted_ca_keys, 43 truncated_hmac, and status_request. 45 Acknowledgements 47 This draft is based on material from RFC 4366 for which the authors 48 were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T. 49 Wright. 51 Table of Contents 53 Status of This Document....................................1 54 Abstract...................................................1 55 Acknowledgements...........................................2 57 1. Introduction............................................3 58 1.1 Specific Extensions Covered............................3 59 1.2 Conventions Used in This Document......................4 61 2. Extensions to the Handshake Protocol....................5 62 3. Server Name Indication..................................6 63 4. Maximum Fragment Length Negotiation.....................8 64 5. Client Certificate URLs................................10 65 6. Trusted CA Indication..................................13 66 7. Truncated HMAC.........................................15 67 8. Certificate Status Request.............................16 68 9. Error Alerts...........................................18 69 10. IANA Considerations...................................19 71 11. Security Considerations...............................19 72 11.1 Security Considerations for server_name..............19 73 11.2 Security Considerations for max_fragment_length......19 74 11.3 Security Considerations for client_certificate_url...20 75 11.4 Security Considerations for trusted_ca_keys..........21 76 11.5 Security Considerations for truncated_hmac...........21 77 11.6 Security Considerations for status_request...........22 79 12. Normative References..................................23 80 13. Informative References................................23 81 Annex A: pkipath MIME Type Registration...................25 83 Copyright, Disclaimer, and Additional IPR Provisions......27 84 Author's Address..........................................28 85 Expiration and File Name..................................28 87 1. Introduction 89 The TLS (Transport Layer Security) Protocol Version 1.2 is specified 90 in [RFC5246]. That specification includes the framework for 91 extensions to TLS, considerations in designing such extensions (see 92 Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the 93 allocation of new extension code points; however, it does not specify 94 any particular extensions other than Signature Algorithms (see 95 Section 7.4.1.4.1 of [RFC5246]). 97 This document provides the specifications for existing TLS 98 extensions. It is, for the most part, the adaptation and editing of 99 material from [RFC4366], which covered TLS extensions for TLS 1.0 100 [RFC2246] and TLS 1.1 [RFC4346]. 102 1.1 Specific Extensions Covered 104 The extensions described here focus on extending the functionality 105 provided by the TLS protocol message formats. Other issues, such as 106 the addition of new cipher suites, are deferred. 108 The extension types defined in this document are: 110 enum { 111 server_name(0), max_fragment_length(1), 112 client_certificate_url(2), trusted_ca_keys(3), 113 truncated_hmac(4), status_request(5), (65535) 114 } ExtensionType; 116 Specifically, the extensions described in this document: 118 - Allow TLS clients to provide to the TLS server the name of the 119 server they are contacting. This functionality is desirable in 120 order to facilitate secure connections to servers that host 121 multiple 'virtual' servers at a single underlying network address. 123 - Allow TLS clients and servers to negotiate the maximum fragment 124 length to be sent. This functionality is desirable as a result of 125 memory constraints among some clients, and bandwidth constraints 126 among some access networks. 128 - Allow TLS clients and servers to negotiate the use of client 129 certificate URLs. This functionality is desirable in order to 130 conserve memory on constrained clients. 132 - Allow TLS clients to indicate to TLS servers which CA root keys 133 they possess. This functionality is desirable in order to prevent 134 multiple handshake failures involving TLS clients that are only 135 able to store a small number of CA root keys due to memory 136 limitations. 138 - Allow TLS clients and servers to negotiate the use of truncated 139 MACs. This functionality is desirable in order to conserve 140 bandwidth in constrained access networks. 142 - Allow TLS clients and servers to negotiate that the server sends 143 the client certificate status information (e.g., an Online 144 Certificate Status Protocol (OCSP) [RFC2560] response) during a 145 TLS handshake. This functionality is desirable in order to avoid 146 sending a Certificate Revocation List (CRL) over a constrained 147 access network and therefore save bandwidth. 149 TLS clients and servers may use the extensions described in this 150 document. The extensions are designed to be backwards compatible, 151 meaning that TLS clients that support the extensions can talk to TLS 152 servers that do not support the extensions, and vice versa. 154 1.2 Conventions Used in This Document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 2. Extensions to the Handshake Protocol 162 This document specifies the use of two new handshake messages, 163 "CertificateURL" and "CertificateStatus". These messages are 164 described in Section 5 and Section 8, respectively. The new 165 handshake message structure therefore becomes: 167 enum { 168 hello_request(0), client_hello(1), server_hello(2), 169 certificate(11), server_key_exchange (12), 170 certificate_request(13), server_hello_done(14), 171 certificate_verify(15), client_key_exchange(16), 172 finished(20), certificate_url(21), certificate_status(22), 173 (255) 174 } HandshakeType; 176 struct { 177 HandshakeType msg_type; /* handshake type */ 178 uint24 length; /* bytes in message */ 179 select (HandshakeType) { 180 case hello_request: HelloRequest; 181 case client_hello: ClientHello; 182 case server_hello: ServerHello; 183 case certificate: Certificate; 184 case server_key_exchange: ServerKeyExchange; 185 case certificate_request: CertificateRequest; 186 case server_hello_done: ServerHelloDone; 187 case certificate_verify: CertificateVerify; 188 case client_key_exchange: ClientKeyExchange; 189 case finished: Finished; 190 case certificate_url: CertificateURL; 191 case certificate_status: CertificateStatus; 192 } body; 193 } Handshake; 195 3. Server Name Indication 197 TLS does not provide a mechanism for a client to tell a server the 198 name of the server it is contacting. It may be desirable for clients 199 to provide this information to facilitate secure connections to 200 servers that host multiple 'virtual' servers at a single underlying 201 network address. 203 In order to provide the server name, clients MAY include an extension 204 of type "server_name" in the (extended) client hello. The 205 "extension_data" field of this extension SHALL contain 206 "ServerNameList" where: 208 struct { 209 NameType name_type; 210 select (name_type) { 211 case host_name: HostName; 212 } name; 213 } ServerName; 215 enum { 216 host_name(0), (255) 217 } NameType; 219 opaque HostName<1..2^16-1>; 221 struct { 222 ServerName server_name_list<1..2^16-1> 223 } ServerNameList; 225 If the server understood the client hello extension but does not 226 recognize any of the server names, it SHOULD send an 227 unrecognized_name(112) alert (which MAY be fatal). 229 Currently, the only server names supported are DNS hostnames; 230 however, this does not imply any dependency of TLS on DNS, and other 231 name types may be added in the future (by an RFC that updates this 232 document). TLS MAY treat provided server names as opaque data and 233 pass the names and types to the application. 235 "HostName" contains the fully qualified DNS hostname of the server, 236 as understood by the client. The hostname is represented as a byte 237 string using ASCII encoding without a trailing dot. 239 Literal IPv4 and IPv6 addresses are not permitted in "HostName". 241 It is RECOMMENDED that clients include an extension of type 242 "server_name" in the client hello whenever they locate a server by a 243 supported name type. 245 A server that receives a client hello containing the "server_name" 246 extension MAY use the information contained in the extension to guide 247 its selection of an appropriate certificate to return to the client, 248 and/or other aspects of security policy. In this event, the server 249 SHALL include an extension of type "server_name" in the (extended) 250 server hello. The "extension_data" field of this extension SHALL be 251 empty. 253 If an application negotiates a server name using an application 254 protocol and then upgrades to TLS, and if a server_name extension is 255 sent, then the extension SHOULD contain the same name that was 256 negotiated in the application protocol. If the server_name is 257 established in the TLS session handshake, the client SHOULD NOT 258 attempt to request a different server name at the application layer. 260 4. Maximum Fragment Length Negotiation 262 Without this extension, TLS specifies a fixed maximum plaintext 263 fragment length of 2^14 bytes. It may be desirable for constrained 264 clients to negotiate a smaller maximum fragment length due to memory 265 limitations or bandwidth limitations. 267 In order to negotiate smaller maximum fragment lengths, clients MAY 268 include an extension of type "max_fragment_length" in the (extended) 269 client hello. The "extension_data" field of this extension SHALL 270 contain: 272 enum{ 273 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) 274 } MaxFragmentLength; 276 whose value is the desired maximum fragment length. The allowed 277 values for this field are: 2^9, 2^10, 2^11, and 2^12. 279 Servers that receive an extended client hello containing a 280 "max_fragment_length" extension MAY accept the requested maximum 281 fragment length by including an extension of type 282 "max_fragment_length" in the (extended) server hello. The 283 "extension_data" field of this extension SHALL contain a 284 "MaxFragmentLength" whose value is the same as the requested maximum 285 fragment length. 287 If a server receives a maximum fragment length negotiation request 288 for a value other than the allowed values, it MUST abort the 289 handshake with an "illegal_parameter" alert. Similarly, if a client 290 receives a maximum fragment length negotiation response that differs 291 from the length it requested, it MUST also abort the handshake with 292 an "illegal_parameter" alert. 294 Once a maximum fragment length other than 2^14 has been successfully 295 negotiated, the client and server MUST immediately begin fragmenting 296 messages (including handshake messages), to ensure that no fragment 297 larger than the negotiated length is sent. Note that TLS already 298 requires clients and servers to support fragmentation of handshake 299 messages. 301 The negotiated length applies for the duration of the session 302 including session resumptions. 304 The negotiated length limits the input that the record layer may 305 process without fragmentation (that is, the maximum value of 306 TLSPlaintext.length; see [RFC5246], Section 6.2.1). Note that the 307 output of the record layer may be larger. For example, if the 308 negotiated length is 2^9=512, then for currently defined cipher 309 suites (those defined in [RFC5246], [RFC2712], and [RFC3268]), and 310 when null compression is used, the record layer output can be at most 311 805 bytes: 5 bytes of headers, 512 bytes of application data, 256 312 bytes of padding, and 32 bytes of MAC. This means that in this event 313 a TLS record layer peer receiving a TLS record layer message larger 314 than 805 bytes may discard the message and send a "record_overflow" 315 alert, without decrypting the message. 317 5. Client Certificate URLs 319 Without this extension, TLS specifies that when client authentication 320 is performed, client certificates are sent by clients to servers 321 during the TLS handshake. It may be desirable for constrained clients 322 to send certificate URLs in place of certificates, so that they do 323 not need to store their certificates and can therefore save memory. 325 In order to negotiate sending certificate URLs to a server, clients 326 MAY include an extension of type "client_certificate_url" in the 327 (extended) client hello. The "extension_data" field of this extension 328 SHALL be empty. 330 (Note that it is necessary to negotiate use of client certificate 331 URLs in order to avoid "breaking" existing TLS servers.) 333 Servers that receive an extended client hello containing a 334 "client_certificate_url" extension MAY indicate that they are willing 335 to accept certificate URLs by including an extension of type 336 "client_certificate_url" in the (extended) server hello. The 337 "extension_data" field of this extension SHALL be empty. 339 After negotiation of the use of client certificate URLs has been 340 successfully completed (by exchanging hellos including 341 "client_certificate_url" extensions), clients MAY send a 342 "CertificateURL" message in place of a "Certificate" message as 343 follows (see also Section 2): 345 enum { 346 individual_certs(0), pkipath(1), (255) 347 } CertChainType; 349 enum { 350 false(0), true(1) 351 } Boolean; 353 struct { 354 CertChainType type; 355 URLAndOptionalHash url_and_hash_list<1..2^16-1>; 356 } CertificateURL; 358 struct { 359 opaque url<1..2^16-1>; 360 Boolean hash_present; 361 select (hash_present) { 362 case false: struct {}; 363 case true: SHA1Hash; 364 } hash; 365 } URLAndOptionalHash; 366 opaque SHA1Hash[20]; 368 Here "url_and_hash_list" contains a sequence of URLs and optional 369 hashes. Each "url" MUST be an absolute URI reference according to 370 [RFC3986] that can be immediately used to fetch the certificate(s). 372 When X.509 certificates are used, there are two possibilities: 374 - If CertificateURL.type is "individual_certs", each URL refers to a 375 single DER-encoded X.509v3 certificate, with the URL for the client's 376 certificate first. 378 - If CertificateURL.type is "pkipath", the list contains a single 379 URL referring to a DER-encoded certificate chain, using the type 380 PkiPath described in Annex A. 382 When any other certificate format is used, the specification that 383 describes use of that format in TLS should define the encoding format 384 of certificates or certificate chains, and any constraint on their 385 ordering. 387 The hash corresponding to each URL at the client's discretion either 388 is not present or is the SHA-1 hash of the certificate or certificate 389 chain (in the case of X.509 certificates, the DER-encoded certificate 390 or the DER-encoded PkiPath). 392 Note that when a list of URLs for X.509 certificates is used, the 393 ordering of URLs is the same as that used in the TLS Certificate 394 message (see [RFC5246], Section 7.4.2), but opposite to the order in 395 which certificates are encoded in PkiPath. In either case, the self- 396 signed root certificate MAY be omitted from the chain, under the 397 assumption that the server must already possess it in order to 398 validate it. 400 Servers receiving "CertificateURL" SHALL attempt to retrieve the 401 client's certificate chain from the URLs and then process the 402 certificate chain as usual. A cached copy of the content of any URL 403 in the chain MAY be used, provided that a SHA-1 hash is present for 404 that URL and it matches the hash of the cached copy. 406 Servers that support this extension MUST support the 'http' URI 407 scheme for certificate URLs, and MAY support other schemes. Use of 408 other schemes than 'http', 'https', or 'ftp' may create unexpected 409 problems. 411 If the protocol used is HTTP, then the HTTP server can be configured 412 to use the Cache-Control and Expires directives described in 413 [RFC2616] to specify whether and for how long certificates or 414 certificate chains should be cached. 416 The TLS server is not required to follow HTTP redirects when 417 retrieving the certificates or certificate chain. The URLs used in 418 this extension SHOULD therefore be chosen not to depend on such 419 redirects. 421 If the protocol used to retrieve certificates or certificate chains 422 returns a MIME-formatted response (as HTTP does), then the following 423 MIME Content-Types SHALL be used: when a single X.509v3 certificate 424 is returned, the Content-Type is "application/pkix-cert" [RFC2585], 425 and when a chain of X.509v3 certificates is returned, the Content- 426 Type is "application/pkix-pkipath" Annex A. 428 If a SHA-1 hash is present for an URL, then the server MUST check 429 that the SHA-1 hash of the contents of the object retrieved from that 430 URL (after decoding any MIME Content-Transfer-Encoding) matches the 431 given hash. If any retrieved object does not have the correct SHA-1 432 hash, the server MUST abort the handshake with a 433 bad_certificate_hash_value(114) alert. This alert is always fatal. 435 Clients may choose to send either "Certificate" or "CertificateURL" 436 after successfully negotiating the option to send certificate URLs. 437 The option to send a certificate is included to provide flexibility 438 to clients possessing multiple certificates. 440 If a server encounters an unreasonable delay in obtaining 441 certificates in a given CertificateURL, it SHOULD time out and signal 442 a certificate_unobtainable(111) error alert. This alert MAY be fatal; 443 for example, if client authentication is required by the server for 444 the handshake to continue. 446 6. Trusted CA Indication 448 Constrained clients that, due to memory limitations, possess only a 449 small number of CA root keys may wish to indicate to servers which 450 root keys they possess, in order to avoid repeated handshake 451 failures. 453 In order to indicate which CA root keys they possess, clients MAY 454 include an extension of type "trusted_ca_keys" in the (extended) 455 client hello. The "extension_data" field of this extension SHALL 456 contain "TrustedAuthorities" where: 458 struct { 459 TrustedAuthority trusted_authorities_list<0..2^16-1>; 460 } TrustedAuthorities; 462 struct { 463 IdentifierType identifier_type; 464 select (identifier_type) { 465 case pre_agreed: struct {}; 466 case key_sha1_hash: SHA1Hash; 467 case x509_name: DistinguishedName; 468 case cert_sha1_hash: SHA1Hash; 469 } identifier; 470 } TrustedAuthority; 472 enum { 473 pre_agreed(0), key_sha1_hash(1), x509_name(2), 474 cert_sha1_hash(3), (255) 475 } IdentifierType; 477 opaque DistinguishedName<1..2^16-1>; 479 Here "TrustedAuthorities" provides a list of CA root key identifiers 480 that the client possesses. Each CA root key is identified via either: 482 - "pre_agreed": no CA root key identity supplied. 484 - "key_sha1_hash": contains the SHA-1 hash of the CA root key. For 485 Digital Signature Algorithm (DSA) and Elliptic Curve Digital 486 Signature Algorithm (ECDSA) keys, this is the hash of the 487 "subjectPublicKey" value. For RSA keys, the hash is of the big- 488 endian byte string representation of the modulus without any 489 initial 0-valued bytes. (This copies the key hash formats deployed 490 in other environments.) 492 - "x509_name": contains the DER-encoded X.509 DistinguishedName of 493 the CA. 495 - "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded 496 Certificate containing the CA root key. 498 Note that clients may include none, some, or all of the CA root keys 499 they possess in this extension. 501 Note also that it is possible that a key hash or a Distinguished Name 502 alone may not uniquely identify a certificate issuer (for example, if 503 a particular CA has multiple key pairs). However, here we assume this 504 is the case following the use of Distinguished Names to identify 505 certificate issuers in TLS. 507 The option to include no CA root keys is included to allow the client 508 to indicate possession of some pre-defined set of CA root keys. 510 Servers that receive a client hello containing the "trusted_ca_keys" 511 extension MAY use the information contained in the extension to guide 512 their selection of an appropriate certificate chain to return to the 513 client. In this event, the server SHALL include an extension of type 514 "trusted_ca_keys" in the (extended) server hello. The 515 "extension_data" field of this extension SHALL be empty. 517 7. Truncated HMAC 519 Currently defined TLS cipher suites use the MAC construction HMAC 520 with either MD5 or SHA-1 [RFC2104] to authenticate record layer 521 communications. In TLS, the entire output of the hash function is 522 used as the MAC tag. However, it may be desirable in constrained 523 environments to save bandwidth by truncating the output of the hash 524 function to 80 bits when forming MAC tags. 526 In order to negotiate the use of 80-bit truncated HMAC, clients MAY 527 include an extension of type "truncated_hmac" in the extended client 528 hello. The "extension_data" field of this extension SHALL be empty. 530 Servers that receive an extended hello containing a "truncated_hmac" 531 extension MAY agree to use a truncated HMAC by including an extension 532 of type "truncated_hmac", with empty "extension_data", in the 533 extended server hello. 535 Note that if new cipher suites are added that do not use HMAC, and 536 the session negotiates one of these cipher suites, this extension 537 will have no effect. It is strongly recommended that any new cipher 538 suites using other MACs consider the MAC size an integral part of the 539 cipher suite definition, taking into account both security and 540 bandwidth considerations. 542 If HMAC truncation has been successfully negotiated during a TLS 543 handshake, and the negotiated cipher suite uses HMAC, both the client 544 and the server pass this fact to the TLS record layer along with the 545 other negotiated security parameters. Subsequently during the 546 session, clients and servers MUST use truncated HMACs, calculated as 547 specified in [RFC2104]. That is, SecurityParameters.mac_length is 10 548 bytes, and only the first 10 bytes of the HMAC output are transmitted 549 and checked. Note that this extension does not affect the calculation 550 of the pseudo-random function (PRF) as part of handshaking or key 551 derivation. 553 The negotiated HMAC truncation size applies for the duration of the 554 session including session resumptions. 556 8. Certificate Status Request 558 Constrained clients may wish to use a certificate-status protocol 559 such as OCSP [RFC2560] to check the validity of server certificates, 560 in order to avoid transmission of CRLs and therefore save bandwidth 561 on constrained networks. This extension allows for such information 562 to be sent in the TLS handshake, saving roundtrips and resources. 564 In order to indicate their desire to receive certificate status 565 information, clients MAY include an extension of type 566 "status_request" in the (extended) client hello. The "extension_data" 567 field of this extension SHALL contain "CertificateStatusRequest" 568 where: 570 struct { 571 CertificateStatusType status_type; 572 select (status_type) { 573 case ocsp: OCSPStatusRequest; 574 } request; 575 } CertificateStatusRequest; 577 enum { ocsp(1), (255) } CertificateStatusType; 579 struct { 580 ResponderID responder_id_list<0..2^16-1>; 581 Extensions request_extensions; 582 } OCSPStatusRequest; 584 opaque ResponderID<1..2^16-1>; 585 opaque Extensions<0..2^16-1>; 587 In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP 588 responders that the client trusts. A zero-length "responder_id_list" 589 sequence has the special meaning that the responders are implicitly 590 known to the server, e.g., by prior arrangement. "Extensions" is a 591 DER encoding of OCSP request extensions. 593 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as 594 defined in [RFC2560]. "Extensions" is imported from [RFC5280]. A 595 zero-length "request_extensions" value means that there are no 596 extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not 597 valid for the "Extensions" type). 599 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is 600 unclear about its encoding; for clarification, the nonce MUST be a 601 DER-encoded OCTET STRING, which is encapsulated as another OCTET 602 STRING (note that implementations based on an existing OCSP client 603 will need to be checked for conformance to this requirement). 605 Servers that receive a client hello containing the "status_request" 606 extension MAY return a suitable certificate status response to the 607 client along with their certificate. If OCSP is requested, they 608 SHOULD use the information contained in the extension when selecting 609 an OCSP responder and SHOULD include request_extensions in the OCSP 610 request. 612 Servers return a certificate response along with their certificate by 613 sending a "CertificateStatus" message immediately after the 614 "Certificate" message (and before any "ServerKeyExchange" or 615 "CertificateRequest" messages). If a server returns a 616 "CertificateStatus" message, then the server MUST have included an 617 extension of type "status_request" with empty "extension_data" in the 618 extended server hello. The "CertificateStatus" message is conveyed 619 using the handshake message type "certificate_status" as follows (see 620 also Section 2): 622 struct { 623 CertificateStatusType status_type; 624 select (status_type) { 625 case ocsp: OCSPResponse; 626 } response; 627 } CertificateStatus; 629 opaque OCSPResponse<1..2^24-1>; 631 An "ocsp_response" contains a complete, DER-encoded OCSP response 632 (using the ASN.1 type OCSPResponse defined in [RFC2560]). Only one 633 OCSP response may be sent. 635 Note that a server MAY also choose not to send a "CertificateStatus" 636 message, even if has received a "status_request" extension in the 637 client hello message and has sent a "status_request" extension in the 638 server hello message. 640 Note in addition that a server MUST NOT send the "CertificateStatus" 641 message unless it received a "status_request" extension in the client 642 hello message and sent a "status_request" extension in the server 643 hello message. 645 Clients requesting an OCSP response and receiving an OCSP response in 646 a "CertificateStatus" message MUST check the OCSP response and abort 647 the handshake if the response is not satisfactory with 648 bad_certificate_status_response(113) alert. This alert is always 649 fatal. 651 9. Error Alerts 653 Four new error alerts are defined for use with the TLS extensions 654 defined in this document. To avoid "breaking" existing clients and 655 servers, these alerts MUST NOT be sent unless the sending party has 656 received an extended hello message from the party they are 657 communicating with. These error alerts are conveyed using the 658 following syntax. The new alerts are the last four, as indicated by 659 the comments on the same line as the error alert number. 661 enum { 662 close_notify(0), 663 unexpected_message(10), 664 bad_record_mac(20), 665 decryption_failed(21), 666 record_overflow(22), 667 decompression_failure(30), 668 handshake_failure(40), 669 /* 41 is not defined, for historical reasons */ 670 bad_certificate(42), 671 unsupported_certificate(43), 672 certificate_revoked(44), 673 certificate_expired(45), 674 certificate_unknown(46), 675 illegal_parameter(47), 676 unknown_ca(48), 677 access_denied(49), 678 decode_error(50), 679 decrypt_error(51), 680 export_restriction(60), 681 protocol_version(70), 682 insufficient_security(71), 683 internal_error(80), 684 user_canceled(90), 685 no_renegotiation(100), 686 unsupported_extension(110), 687 certificate_unobtainable(111), /* new */ 688 unrecognized_name(112), /* new */ 689 bad_certificate_status_response(113), /* new */ 690 bad_certificate_hash_value(114), /* new */ 691 (255) 692 } AlertDescription; 694 "certificate_unobtainable" is described in Section 5. 695 "unrecognized_name" is described in Section 3. 696 "bad_certificate_status_response" is described in Section 8. 697 "bad_certificate_hash_value" is described in Section 5. 699 10. IANA Considerations 701 IANA Considerations for TLS Extensions and the creation of a Registry 702 therefore are covered in Section 12 of [RFC5246] except for the 703 registration of MIME type application/pkix-pkipath. This MIME type 704 has already been registered but is reproduced in Annex A for 705 convenience. 707 The IANA TLS extensions registry entries that reference [RFC4366] 708 should be updated to reference this document on its publication as an 709 RFC. 711 11. Security Considerations 713 General Security Considerations for TLS Extensions are covered in 714 [RFC5246]. Security Considerations for particular extensions 715 specified in this document are given below. 717 In general, implementers should continue to monitor the state of the 718 art and address any weaknesses identified. 720 Additional security considerations are described in the TLS 1.0 RFC 721 [RFC2246] and the TLS 1.1 RFC [RFC4346]. 723 11.1 Security Considerations for server_name 725 If a single server hosts several domains, then clearly it is 726 necessary for the owners of each domain to ensure that this satisfies 727 their security needs. Apart from this, server_name does not appear to 728 introduce significant security issues. 730 Implementations MUST ensure that a buffer overflow does not occur, 731 whatever the values of the length fields in server_name. 733 11.2 Security Considerations for max_fragment_length 735 The maximum fragment length takes effect immediately, including for 736 handshake messages. However, that does not introduce any security 737 complications that are not already present in TLS, since TLS requires 738 implementations to be able to handle fragmented handshake messages. 740 Note that as described in Section 4, once a non-null cipher suite has 741 been activated, the effective maximum fragment length depends on the 742 cipher suite and compression method, as well as on the negotiated 743 max_fragment_length. This must be taken into account when sizing 744 buffers, and checking for buffer overflow. 746 11.3 Security Considerations for client_certificate_url 748 There are two major issues with this extension. 750 The first major issue is whether or not clients should include 751 certificate hashes when they send certificate URLs. 753 When client authentication is used *without* the 754 client_certificate_url extension, the client certificate chain is 755 covered by the Finished message hashes. The purpose of including 756 hashes and checking them against the retrieved certificate chain is 757 to ensure that the same property holds when this extension is used, 758 i.e., that all of the information in the certificate chain retrieved 759 by the server is as the client intended. 761 On the other hand, omitting certificate hashes enables functionality 762 that is desirable in some circumstances; for example, clients can be 763 issued daily certificates that are stored at a fixed URL and need not 764 be provided to the client. Clients that choose to omit certificate 765 hashes should be aware of the possibility of an attack in which the 766 attacker obtains a valid certificate on the client's key that is 767 different from the certificate the client intended to provide. 768 Although TLS uses both MD5 and SHA-1 hashes in several other places, 769 this was not believed to be necessary here. The property required of 770 SHA-1 is second pre-image resistance. 772 The second major issue is that support for client_certificate_url 773 involves the server's acting as a client in another URI scheme 774 dependent protocol. The server therefore becomes subject to many of 775 the same security concerns that clients of the URI scheme are subject 776 to, with the added concern that the client can attempt to prompt the 777 server to connect to some (possibly weird-looking) URL. 779 In general, this issue means that an attacker might use the server to 780 indirectly attack another host that is vulnerable to some security 781 flaw. It also introduces the possibility of denial of service attacks 782 in which an attacker makes many connections to the server, each of 783 which results in the server's attempting a connection to the target 784 of the attack. 786 Note that the server may be behind a firewall or otherwise able to 787 access hosts that would not be directly accessible from the public 788 Internet. This could exacerbate the potential security and denial of 789 service problems described above, as well as allow the existence of 790 internal hosts to be confirmed when they would otherwise be hidden. 792 The detailed security concerns involved will depend on the URI 793 schemes supported by the server. In the case of HTTP, the concerns 794 are similar to those that apply to a publicly accessible HTTP proxy 795 server. In the case of HTTPS, loops and deadlocks may be created, and 796 this should be addressed. In the case of FTP, attacks arise that are 797 similar to FTP bounce attacks. 799 As a result of this issue, it is RECOMMENDED that the 800 client_certificate_url extension should have to be specifically 801 enabled by a server administrator, rather than be enabled by default. 802 It is also RECOMMENDED that URI schemes be enabled by the 803 administrator individually, and only a minimal set of schemes be 804 enabled. Unusual protocols that offer limited security or whose 805 security is not well understood SHOULD be avoided. 807 As discussed in [RFC3986], URLs that specify ports other than the 808 default may cause problems, as may very long URLs (which are more 809 likely to be useful in exploiting buffer overflow bugs). 811 Also note that HTTP caching proxies are common on the Internet, and 812 some proxies do not check for the latest version of an object 813 correctly. If a request using HTTP (or another caching protocol) goes 814 through a misconfigured or otherwise broken proxy, the proxy may 815 return an out-of-date response. 817 11.4 Security Considerations for trusted_ca_keys 819 It is possible that which CA root keys a client possesses could be 820 regarded as confidential information. As a result, the CA root key 821 indication extension should be used with care. 823 The use of the SHA-1 certificate hash alternative ensures that each 824 certificate is specified unambiguously. As for the previous 825 extension, it was not believed necessary to use both MD5 and SHA-1 826 hashes. 828 11.5 Security Considerations for truncated_hmac 830 It is possible that truncated MACs are weaker than "un-truncated" 831 MACs. However, no significant weaknesses are currently known or 832 expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. 834 Note that the output length of a MAC need not be as long as the 835 length of a symmetric cipher key, since forging of MAC values cannot 836 be done off-line: in TLS, a single failed MAC guess will cause the 837 immediate termination of the TLS session. 839 Since the MAC algorithm only takes effect after all handshake 840 messages that affect extension parameters have been authenticated by 841 the hashes in the Finished messages, it is not possible for an active 842 attacker to force negotiation of the truncated HMAC extension where 843 it would not otherwise be used (to the extent that the handshake 844 authentication is secure). Therefore, in the event that any security 845 problem were found with truncated HMAC in the future, if either the 846 client or the server for a given session were updated to take the 847 problem into account, it would be able to veto use of this extension. 849 11.6 Security Considerations for status_request 851 If a client requests an OCSP response, it must take into account that 852 an attacker's server using a compromised key could (and probably 853 would) pretend not to support the extension. In this case, a client 854 that requires OCSP validation of certificates SHOULD either contact 855 the OCSP server directly or abort the handshake. 857 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may 858 improve security against attacks that attempt to replay OCSP 859 responses; see Section 4.4.1 of [RFC2560] for further details. 861 12. Normative References 863 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 864 Hashing for Message Authentication", RFC 2104, February 1997. 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, March 1997. 869 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 870 Adams, "X.509 Internet Public Key Infrastructure Online Certificate 871 Status Protocol - OCSP", RFC 2560, June 1999. 873 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 874 Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 875 1999. 877 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 878 L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 879 HTTP/1.1", RFC 2616, June 1999. 881 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 882 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 883 2005. 885 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 886 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 888 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 889 Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure 890 Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, 891 May 2008 893 13. Informative References 895 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 896 RFC 2246, January 1999. 898 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 899 Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. 901 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites 902 for Transport Layer Security (TLS)", RFC 3268, June 2002. 904 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 905 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 907 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 908 and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, 909 April 2006. 911 [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, 912 "Information Systems - Open Systems Interconnection - The Directory: 913 Public key and attribute certificate frameworks." 915 [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | 916 ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC 917 9594:8:2001. 919 Annex A: pkipath MIME Type Registration 921 The MIME type application/pkix-pkipath has been registered. A copy 922 of its template is included here for convenience: 924 MIME media type name: application 925 MIME subtype name: pkix-pkipath 926 Required parameters: none 928 Optional parameters: version (default value is "1") 930 Encoding considerations: 931 This MIME type is a DER encoding of the ASN.1 type PkiPath, 932 defined as follows: 933 PkiPath ::= SEQUENCE OF Certificate 934 PkiPath is used to represent a certification path. Within the 935 sequence, the order of certificates is such that the subject of 936 the first certificate is the issuer of the second certificate, 937 etc. 938 This is identical to the definition published in [X509-4th-TC1]; 939 note that it is different from that in [X509-4th]. 941 All Certificates MUST conform to [RFC5280]. (This should be 942 interpreted as a requirement to encode only PKIX-conformant 943 certificates using this type. It does not necessarily require 944 that all certificates that are not strictly PKIX-conformant must 945 be rejected by relying parties, although the security consequences 946 of accepting any such certificates should be considered 947 carefully.) 949 DER (as opposed to BER) encoding MUST be used. If this type is 950 sent over a 7-bit transport, base64 encoding SHOULD be used. 952 Security considerations: 953 The security considerations of [X509-4th] and [RFC5280] (or any 954 updates to them) apply, as well as those of any protocol that uses 955 this type (e.g., TLS). 957 Note that this type only specifies a certificate chain that can be 958 assessed for validity according to the relying party's existing 959 configuration of trusted CAs; it is not intended to be used to 960 specify any change to that configuration. 962 Interoperability considerations: 963 No specific interoperability problems are known with this type, 964 but for recommendations relating to X.509 certificates in general, 965 see [RFC5280]. 967 Published specification: [RFC4366], and [RFC5280]. 969 Applications which use this media type: TLS. It may also be used by 970 other protocols, or for general interchange of PKIX certificate 971 chains. 973 Additional information: 974 Magic number(s): DER-encoded ASN.1 can be easily recognized. 975 Further parsing is required to distinguish it from other ASN.1 976 types. 977 File extension(s): .pkipath 978 Macintosh File Type Code(s): not specified 980 Person & email address to contact for further information: 981 Magnus Nystrom 983 Intended usage: COMMON 985 Change controller: IESG 987 Copyright, Disclaimer, and Additional IPR Provisions 989 Copyright (C) The IETF Trust (2008). 991 This document is subject to the rights, licenses and restrictions 992 contained in BCP 78, and except as set forth therein, the authors 993 retain all their rights. 995 This document and the information contained herein are provided on an 996 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 997 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 998 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 999 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1000 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1001 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1003 The IETF takes no position regarding the validity or scope of any 1004 Intellectual Property Rights or other rights that might be claimed to 1005 pertain to the implementation or use of the technology described in 1006 this document or the extent to which any license under such rights 1007 might or might not be available; nor does it represent that it has 1008 made any independent effort to identify any such rights. Information 1009 on the procedures with respect to rights in RFC documents can be 1010 found in BCP 78 and BCP 79. 1012 Copies of IPR disclosures made to the IETF Secretariat and any 1013 assurances of licenses to be made available, or the result of an 1014 attempt made to obtain a general license or permission for the use of 1015 such proprietary rights by implementers or users of this 1016 specification can be obtained from the IETF on-line IPR repository at 1017 http://www.ietf.org/ipr. 1019 The IETF invites any interested party to bring to its attention any 1020 copyrights, patents or patent applications, or other proprietary 1021 rights that may cover technology that may be required to implement 1022 this standard. Please address the information to the IETF at ietf- 1023 ipr@ietf.org. 1025 Author's Address 1027 Donald Eastlake 3rd 1028 Eastlake Enterprises 1029 155 Beaver Street 1030 Milford, MA 01757 USA 1032 Tel: +1-508-634-2066 1033 Email: d3e3e3@gmail.com 1035 Expiration and File Name 1037 This draft expires in April 2009. 1039 Its file name is draft-ietf-tls-rfc4366-bis-03.txt.