idnits 2.17.1 draft-ietf-tls-rfc4366-bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 929. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 936. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 942. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 (February 20, 2008) is 5908 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 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) -- No information found for draft-ietf-tls-rfc4346-bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFCTLS' -- 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 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Donald Eastlake 3rd 3 INTERNET-DRAFT Motorola Laboratories 4 Obsoletes: RFC 4366 5 Intended status: Proposed Standard 6 Expires: August 2008 February 20, 2008 8 Transport Layer Security (TLS) Extensions: Extension Definitions 10 12 Status of This Document 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Distribution of this document is unlimited. Comments should be sent 20 to the TLS working group mailing list . 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document provides documentation for existing specific TLS 41 extensions. It is a companion document for the TLS 1.2 specification, 42 draft-ietf-tls-rfc4346-bis-07.txt. 44 Acknowledgements 46 This draft is based on material from RFC 4366 for which the authors 47 were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T. 48 Wright. 50 Table of Contents 52 Status of This Document....................................1 53 Abstract...................................................1 55 Acknowledgements...........................................2 56 Table of Contents..........................................2 58 1. Introduction............................................3 59 1.1 Specific Extensions Covered............................3 60 1.2 Conventions Used in This Document......................4 62 2. Extensions to the Handshake Protocol....................5 64 3. Server Name Indication..................................6 65 4. Maximum Fragment Length Negotiation.....................7 66 5. Client Certificate URLs.................................8 67 6. Trusted CA Indication..................................11 68 7. Truncated HMAC.........................................12 69 8. Certificate Status Request.............................13 71 9. Error Alerts...........................................16 73 10. IANA Considerations...................................17 74 11. Security Considerations...............................17 75 11.1 Security Considerations for server_name..............17 76 11.2 Security Considerations for max_fragment_length......17 77 11.3 Security Considerations for client_certificate_url...18 78 11.4 Security Considerations for trusted_ca_keys..........19 79 11.5 Security Considerations for truncated_hmac...........19 80 11.6 Security Considerations for status_request...........20 82 12. Normative References..................................21 83 13. Informative References................................21 85 Copyright, Disclaimer, and Additional IPR Provisions......22 87 Author's Address..........................................23 88 Expiration and File Name..................................23 90 1. Introduction 92 The TLS (Transport Layer Security) Protocol Version 1.2 is specified 93 in [RFCTLS]. That specification includes the framework for extensions 94 to TLS, considerations in designing such extensions (see Section 95 7.4.1.4 of [RFCTLS]), and IANA Considerations for the allocation of 96 new extension code points; however, it does not specify any 97 particular extensions other than Signature Algorithms (see Section 98 7.4.1.4.1 of [RFCTLS]). 100 This document provides the specifications for existing TLS 101 extensions. It is, for the most part, the adaptation and editing of 102 material from [RFC4366], which covered TLS extensions for TLS 1.0 103 [RFC2246] and TLS 1.1 [RFC4346]. 105 1.1 Specific Extensions Covered 107 The extensions described here focus on extending the functionality 108 provided by the TLS protocol message formats. Other issues, such as 109 the addition of new cipher suites, are deferred. 111 Specifically, the extensions described in this document: 113 - Allow TLS clients to provide to the TLS server the name of the 114 server they are contacting. This functionality is desirable in 115 order to facilitate secure connections to servers that host 116 multiple 'virtual' servers at a single underlying network address. 118 - Allow TLS clients and servers to negotiate the maximum fragment 119 length to be sent. This functionality is desirable as a result of 120 memory constraints among some clients, and bandwidth constraints 121 among some access networks. 123 - Allow TLS clients and servers to negotiate the use of client 124 certificate URLs. This functionality is desirable in order to 125 conserve memory on constrained clients. 127 - Allow TLS clients to indicate to TLS servers which CA root keys 128 they possess. This functionality is desirable in order to prevent 129 multiple handshake failures involving TLS clients that are only 130 able to store a small number of CA root keys due to memory 131 limitations. 133 - Allow TLS clients and servers to negotiate the use of truncated 134 MACs. This functionality is desirable in order to conserve 135 bandwidth in constrained access networks. 137 - Allow TLS clients and servers to negotiate that the server sends 138 the client certificate status information (e.g., an Online 139 Certificate Status Protocol (OCSP) [RFC2560] response) during a 140 TLS handshake. This functionality is desirable in order to avoid 141 sending a Certificate Revocation List (CRL) over a constrained 142 access network and therefore save bandwidth. 144 The extensions described in this document may be used by TLS clients 145 and servers. The extensions are designed to be backwards compatible, 146 meaning that TLS clients that support the extensions can talk to TLS 147 servers that do not support the extensions, and vice versa. 149 1.2 Conventions Used in This Document 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 2. Extensions to the Handshake Protocol 157 This document specifies the use of two new handshake messages, 158 "CertificateURL" and "CertificateStatus". These messages are 159 described in Section 5 and Section 8, respectively. The new 160 handshake message structure therefore becomes: 162 enum { 163 hello_request(0), client_hello(1), server_hello(2), 164 certificate(11), server_key_exchange (12), 165 certificate_request(13), server_hello_done(14), 166 certificate_verify(15), client_key_exchange(16), 167 finished(20), certificate_url(21), certificate_status(22), 168 (255) 169 } HandshakeType; 171 struct { 172 HandshakeType msg_type; /* handshake type */ 173 uint24 length; /* bytes in message */ 174 select (HandshakeType) { 175 case hello_request: HelloRequest; 176 case client_hello: ClientHello; 177 case server_hello: ServerHello; 178 case certificate: Certificate; 179 case server_key_exchange: ServerKeyExchange; 180 case certificate_request: CertificateRequest; 181 case server_hello_done: ServerHelloDone; 182 case certificate_verify: CertificateVerify; 183 case client_key_exchange: ClientKeyExchange; 184 case finished: Finished; 185 case certificate_url: CertificateURL; 186 case certificate_status: CertificateStatus; 187 } body; 188 } Handshake; 190 3. Server Name Indication 192 TLS does not provide a mechanism for a client to tell a server the 193 name of the server it is contacting. It may be desirable for clients 194 to provide this information to facilitate secure connections to 195 servers that host multiple 'virtual' servers at a single underlying 196 network address. 198 In order to provide the server name, clients MAY include an extension 199 of type "server_name" in the (extended) client hello. The 200 "extension_data" field of this extension SHALL contain 201 "ServerNameList" where: 203 struct { 204 NameType name_type; 205 select (name_type) { 206 case host_name: HostName; 207 } name; 208 } ServerName; 210 enum { 211 host_name(0), (255) 212 } NameType; 214 opaque HostName<1..2^16-1>; 216 struct { 217 ServerName server_name_list<1..2^16-1> 218 } ServerNameList; 220 If the server understood the client hello extension but does not 221 recognize any of the server names, it SHOULD send an 222 unrecognized_name(112) alert (which MAY be fatal). 224 Currently, the only server names supported are DNS hostnames; 225 however, this does not imply any dependency of TLS on DNS, and other 226 name types may be added in the future (by an RFC that updates this 227 document). TLS MAY treat provided server names as opaque data and 228 pass the names and types to the application. 230 "HostName" contains the fully qualified DNS hostname of the server, 231 as understood by the client. The hostname is represented as a byte 232 string using ASCII encoding without a trailing dot. 234 Literal IPv4 and IPv6 addresses are not permitted in "HostName". 236 It is RECOMMENDED that clients include an extension of type 237 "server_name" in the client hello whenever they locate a server by a 238 supported name type. 240 A server that receives a client hello containing the "server_name" 241 extension MAY use the information contained in the extension to guide 242 its selection of an appropriate certificate to return to the client, 243 and/or other aspects of security policy. In this event, the server 244 SHALL include an extension of type "server_name" in the (extended) 245 server hello. The "extension_data" field of this extension SHALL be 246 empty. 248 If the server understood the client hello extension but does not 249 recognize the server name, it SHOULD send an "unrecognized_name" 250 alert (which MAY be fatal). 252 If an application negotiates a server name using an application 253 protocol and then upgrades to TLS, and if a server_name extension is 254 sent, then the extension SHOULD contain the same name that was 255 negotiated in the application protocol. If the server_name is 256 established in the TLS session handshake, the client SHOULD NOT 257 attempt to request a different server name at the application layer. 259 4. Maximum Fragment Length Negotiation 261 Without this extension, TLS specifies a fixed maximum plaintext 262 fragment length of 2^14 bytes. It may be desirable for constrained 263 clients to negotiate a smaller maximum fragment length due to memory 264 limitations or bandwidth limitations. 266 In order to negotiate smaller maximum fragment lengths, clients MAY 267 include an extension of type "max_fragment_length" in the (extended) 268 client hello. The "extension_data" field of this extension SHALL 269 contain: 271 enum{ 272 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) 273 } MaxFragmentLength; 275 whose value is the desired maximum fragment length. The allowed 276 values for this field are: 2^9, 2^10, 2^11, and 2^12. 278 Servers that receive an extended client hello containing a 279 "max_fragment_length" extension MAY accept the requested maximum 280 fragment length by including an extension of type 281 "max_fragment_length" in the (extended) server hello. The 282 "extension_data" field of this extension SHALL contain a 283 "MaxFragmentLength" whose value is the same as the requested maximum 284 fragment length. 286 If a server receives a maximum fragment length negotiation request 287 for a value other than the allowed values, it MUST abort the 288 handshake with an "illegal_parameter" alert. Similarly, if a client 289 receives a maximum fragment length negotiation response that differs 290 from the length it requested, it MUST also abort the handshake with 291 an "illegal_parameter" alert. 293 Once a maximum fragment length other than 2^14 has been successfully 294 negotiated, the client and server MUST immediately begin fragmenting 295 messages (including handshake messages), to ensure that no fragment 296 larger than the negotiated length is sent. Note that TLS already 297 requires clients and servers to support fragmentation of handshake 298 messages. 300 The negotiated length applies for the duration of the session 301 including session resumptions. 303 The negotiated length limits the input that the record layer may 304 process without fragmentation (that is, the maximum value of 305 TLSPlaintext.length; see [RFCTLS], Section 6.2.1). Note that the 306 output of the record layer may be larger. For example, if the 307 negotiated length is 2^9=512, then for currently defined cipher 308 suites (those defined in [RFCTLS], [RFC2712], and [RFC3268]), and 309 when null compression is used, the record layer output can be at most 310 805 bytes: 5 bytes of headers, 512 bytes of application data, 256 311 bytes of padding, and 32 bytes of MAC. This means that in this event 312 a TLS record layer peer receiving a TLS record layer message larger 313 than 805 bytes may discard the message and send a "record_overflow" 314 alert, without decrypting the message. 316 5. Client Certificate URLs 318 Without this extension, TLS specifies that when client authentication 319 is performed, client certificates are sent by clients to servers 320 during the TLS handshake. It may be desirable for constrained clients 321 to send certificate URLs in place of certificates, so that they do 322 not need to store their certificates and can therefore save memory. 324 In order to negotiate sending certificate URLs to a server, clients 325 MAY include an extension of type "client_certificate_url" in the 326 (extended) client hello. The "extension_data" field of this extension 327 SHALL be empty. 329 (Note that it is necessary to negotiate use of client certificate 330 URLs in order to avoid "breaking" existing TLS servers.) 332 Servers that receive an extended client hello containing a 333 "client_certificate_url" extension MAY indicate that they are willing 334 to accept certificate URLs by including an extension of type 335 "client_certificate_url" in the (extended) server hello. The 336 "extension_data" field of this extension SHALL be empty. 338 After negotiation of the use of client certificate URLs has been 339 successfully completed (by exchanging hellos including 340 "client_certificate_url" extensions), clients MAY send a 341 "CertificateURL" message in place of a "Certificate" message as 342 follows (see also Section 2): 344 enum { 345 individual_certs(0), pkipath(1), (255) 346 } CertChainType; 348 enum { 349 false(0), true(1) 350 } Boolean; 352 struct { 353 CertChainType type; 354 URLAndOptionalHash url_and_hash_list<1..2^16-1>; 355 } CertificateURL; 357 struct { 358 opaque url<1..2^16-1>; 359 Boolean hash_present; 360 select (hash_present) { 361 case false: struct {}; 362 case true: SHA1Hash; 363 } hash; 364 } URLAndOptionalHash; 366 opaque SHA1Hash[20]; 368 Here "url_and_hash_list" contains a sequence of URLs and optional 369 hashes. 371 When X.509 certificates are used, there are two possibilities: 373 - If CertificateURL.type is "individual_certs", each URL refers to a 374 single DER-encoded X.509v3 certificate, with the URL for the client's 375 certificate first. 377 - If CertificateURL.type is "pkipath", the list contains a single 378 URL referring to a DER-encoded certificate chain, using the type 379 PkiPath described in Section 8 of [RFCTLS]. 381 When any other certificate format is used, the specification that 382 describes use of that format in TLS should define the encoding format 383 of certificates or certificate chains, and any constraint on their 384 ordering. 386 The hash corresponding to each URL at the client's discretion either 387 is not present or is the SHA-1 hash of the certificate or certificate 388 chain (in the case of X.509 certificates, the DER-encoded certificate 389 or the DER-encoded PkiPath). 391 Note that when a list of URLs for X.509 certificates is used, the 392 ordering of URLs is the same as that used in the TLS Certificate 393 message (see [RFCTLS], Section 7.4.2), but opposite to the order in 394 which certificates are encoded in PkiPath. In either case, the self- 395 signed root certificate MAY be omitted from the chain, under the 396 assumption that the server must already possess it in order to 397 validate it. 399 Servers receiving "CertificateURL" SHALL attempt to retrieve the 400 client's certificate chain from the URLs and then process the 401 certificate chain as usual. A cached copy of the content of any URL 402 in the chain MAY be used, provided that a SHA-1 hash is present for 403 that URL and it matches the hash of the cached copy. 405 Servers that support this extension MUST support the http: URL scheme 406 for certificate URLs, and MAY support other schemes. Use of other 407 schemes than "http", "https", or "ftp" may create unexpected 408 problems. 410 If the protocol used is HTTP, then the HTTP server can be configured 411 to use the Cache-Control and Expires directives described in 412 [RFC2616] to specify whether and for how long certificates or 413 certificate chains should be cached. 415 The TLS server is not required to follow HTTP redirects when 416 retrieving the certificates or certificate chain. The URLs used in 417 this extension SHOULD therefore be chosen not to depend on such 418 redirects. 420 If the protocol used to retrieve certificates or certificate chains 421 returns a MIME-formatted response (as HTTP does), then the following 422 MIME Content-Types SHALL be used: when a single X.509v3 certificate 423 is returned, the Content-Type is "application/pkix-cert" [RFC2585], 424 and when a chain of X.509v3 certificates is returned, the Content- 425 Type is "application/pkix-pkipath" (see Section 8 of [RFCTLS]). 427 If a SHA-1 hash is present for an URL, then the server MUST check 428 that the SHA-1 hash of the contents of the object retrieved from that 429 URL (after decoding any MIME Content-Transfer-Encoding) matches the 430 given hash. If any retrieved object does not have the correct SHA-1 431 hash, the server MUST abort the handshake with a 432 bad_certificate_hash_value(114) alert. This alert is always fatal. 434 Clients may choose to send either "Certificate" or "CertificateURL" 435 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 [RFC3280]. 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 it receives a "status_request" extension in the 637 client hello message. 639 Note in addition that servers MUST NOT send the "CertificateStatus" 640 message unless it received a "status_request" extension in the client 641 hello message. 643 Clients requesting an OCSP response and receiving an OCSP response in 644 a "CertificateStatus" message MUST check the OCSP response and abort 645 the handshake if the response is not satisfactory with 646 bad_certificate_status_response(113) alert. This alert is always 647 fatal. 649 9. Error Alerts 651 This section defines new error alerts for use with the TLS extensions 652 defined in this document. 654 Four new error alerts are defined. To avoid "breaking" existing 655 clients and servers, these alerts MUST NOT be sent unless the sending 656 party has received an extended hello message from the party they are 657 communicating with. These error alerts are conveyed using the 658 following syntax: 660 enum { 661 close_notify(0), 662 unexpected_message(10), 663 bad_record_mac(20), 664 decryption_failed(21), 665 record_overflow(22), 666 decompression_failure(30), 667 handshake_failure(40), 668 /* 41 is not defined, for historical reasons */ 669 bad_certificate(42), 670 unsupported_certificate(43), 671 certificate_revoked(44), 672 certificate_expired(45), 673 certificate_unknown(46), 674 illegal_parameter(47), 675 unknown_ca(48), 676 access_denied(49), 677 decode_error(50), 678 decrypt_error(51), 679 export_restriction(60), 680 protocol_version(70), 681 insufficient_security(71), 682 internal_error(80), 683 user_canceled(90), 684 no_renegotiation(100), 685 unsupported_extension(110), 686 certificate_unobtainable(111), /* new */ 687 unrecognized_name(112), /* new */ 688 bad_certificate_status_response(113), /* new */ 689 bad_certificate_hash_value(114), /* new */ 690 (255) 691 } AlertDescription; 693 10. IANA Considerations 695 IANA Considerations for TLS Extensions and the creation of a Registry 696 therefore are all covered in Section 12 of [RFCTLS].. 698 11. Security Considerations 700 General Security Considerations for TLS Extensions are covered in 701 [RFCTLS]. Security Considerations for particular extensions specified 702 in this document are given below. 704 In general, implementers should continue to monitor the state of the 705 art and address any weaknesses identified. 707 Additional security considerations are described in the TLS 1.0 RFC 708 [RFC2246] and the TLS 1.1 RFC [RFC4346]. 710 11.1 Security Considerations for server_name 712 If a single server hosts several domains, then clearly it is 713 necessary for the owners of each domain to ensure that this satisfies 714 their security needs. Apart from this, server_name does not appear to 715 introduce significant security issues. 717 Implementations MUST ensure that a buffer overflow does not occur, 718 whatever the values of the length fields in server_name. 720 Although this document specifies an encoding for internationalized 721 hostnames in the server_name extension, it does not address any 722 security issues associated with the use of internationalized 723 hostnames in TLS (in particular, the consequences of "spoofed" names 724 that are indistinguishable from another name when displayed or 725 printed). It is recommended that server certificates not be issued 726 for internationalized hostnames unless procedures are in place to 727 mitigate the risk of spoofed hostnames. 729 11.2 Security Considerations for max_fragment_length 731 The maximum fragment length takes effect immediately, including for 732 handshake messages. However, that does not introduce any security 733 complications that are not already present in TLS, since TLS requires 734 implementations to be able to handle fragmented handshake messages. 736 Note that as described in Section 4, once a non-null cipher suite has 737 been activated, the effective maximum fragment length depends on the 738 cipher suite and compression method, as well as on the negotiated 739 max_fragment_length. This must be taken into account when sizing 740 buffers, and checking for buffer overflow. 742 11.3 Security Considerations for client_certificate_url 744 There are two major issues with this extension. 746 The first major issue is whether or not clients should include 747 certificate hashes when they send certificate URLs. 749 When client authentication is used *without* the 750 client_certificate_url extension, the client certificate chain is 751 covered by the Finished message hashes. The purpose of including 752 hashes and checking them against the retrieved certificate chain is 753 to ensure that the same property holds when this extension is used, 754 i.e., that all of the information in the certificate chain retrieved 755 by the server is as the client intended. 757 On the other hand, omitting certificate hashes enables functionality 758 that is desirable in some circumstances; for example, clients can be 759 issued daily certificates that are stored at a fixed URL and need not 760 be provided to the client. Clients that choose to omit certificate 761 hashes should be aware of the possibility of an attack in which the 762 attacker obtains a valid certificate on the client's key that is 763 different from the certificate the client intended to provide. 764 Although TLS uses both MD5 and SHA-1 hashes in several other places, 765 this was not believed to be necessary here. The property required of 766 SHA-1 is second pre-image resistance. 768 The second major issue is that support for client_certificate_url 769 involves the server's acting as a client in another URL protocol. 770 The server therefore becomes subject to many of the same security 771 concerns that clients of the URL scheme are subject to, with the 772 added concern that the client can attempt to prompt the server to 773 connect to some (possibly weird-looking) URL. 775 In general, this issue means that an attacker might use the server to 776 indirectly attack another host that is vulnerable to some security 777 flaw. It also introduces the possibility of denial of service attacks 778 in which an attacker makes many connections to the server, each of 779 which results in the server's attempting a connection to the target 780 of the attack. 782 Note that the server may be behind a firewall or otherwise able to 783 access hosts that would not be directly accessible from the public 784 Internet. This could exacerbate the potential security and denial of 785 service problems described above, as well as allow the existence of 786 internal hosts to be confirmed when they would otherwise be hidden. 788 The detailed security concerns involved will depend on the URL 789 schemes supported by the server. In the case of HTTP, the concerns 790 are similar to those that apply to a publicly accessible HTTP proxy 791 server. In the case of HTTPS, loops and deadlocks may be created, and 792 this should be addressed. In the case of FTP, attacks arise that are 793 similar to FTP bounce attacks. 795 As a result of this issue, it is RECOMMENDED that the 796 client_certificate_url extension should have to be specifically 797 enabled by a server administrator, rather than be enabled by default. 798 It is also RECOMMENDED that URI protocols be enabled by the 799 administrator individually, and only a minimal set of protocols be 800 enabled. Unusual protocols that offer limited security or whose 801 security is not well-understood SHOULD be avoided. 803 As discussed in [RFC3986], URLs that specify ports other than the 804 default may cause problems, as may very long URLs (which are more 805 likely to be useful in exploiting buffer overflow bugs). 807 Also note that HTTP caching proxies are common on the Internet, and 808 some proxies do not check for the latest version of an object 809 correctly. If a request using HTTP (or another caching protocol) goes 810 through a misconfigured or otherwise broken proxy, the proxy may 811 return an out-of-date response. 813 11.4 Security Considerations for trusted_ca_keys 815 It is possible that which CA root keys a client possesses could be 816 regarded as confidential information. As a result, the CA root key 817 indication extension should be used with care. 819 The use of the SHA-1 certificate hash alternative ensures that each 820 certificate is specified unambiguously. As for the previous 821 extension, it was not believed necessary to use both MD5 and SHA-1 822 hashes. 824 11.5 Security Considerations for truncated_hmac 826 It is possible that truncated MACs are weaker than "un-truncated" 827 MACs. However, no significant weaknesses are currently known or 828 expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. 830 Note that the output length of a MAC need not be as long as the 831 length of a symmetric cipher key, since forging of MAC values cannot 832 be done off-line: in TLS, a single failed MAC guess will cause the 833 immediate termination of the TLS session. 835 Since the MAC algorithm only takes effect after all handshake 836 messages that affect extension parameters have been authenticated by 837 the hashes in the Finished messages, it is not possible for an active 838 attacker to force negotiation of the truncated HMAC extension where 839 it would not otherwise be used (to the extent that the handshake 840 authentication is secure). Therefore, in the event that any security 841 problem were found with truncated HMAC in the future, if either the 842 client or the server for a given session were updated to take the 843 problem into account, it would be able to veto use of this extension. 845 11.6 Security Considerations for status_request 847 If a client requests an OCSP response, it must take into account that 848 an attacker's server using a compromised key could (and probably 849 would) pretend not to support the extension. In this case, a client 850 that requires OCSP validation of certificates SHOULD either contact 851 the OCSP server directly or abort the handshake. 853 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may 854 improve security against attacks that attempt to replay OCSP 855 responses; see Section 4.4.1 of [RFC2560] for further details. 857 12. Normative References 859 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 860 Hashing for Message Authentication", RFC 2104, February 1997. 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, March 1997. 865 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 866 Adams, "X.509 Internet Public Key Infrastructure Online Certificate 867 Status Protocol - OCSP", RFC 2560, June 1999. 869 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 870 Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 871 1999. 873 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 874 L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 875 HTTP/1.1", RFC 2616, June 1999. 877 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 878 X.509 Public Key Infrastructure Certificate and Certificate 879 Revocation List (CRL) Profile", RFC 3280, April 2002. 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 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 886 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 888 [RFCTLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2", 889 draft-ietf-tls-rfc4346-bis-*.txt, March 2007. 891 13. Informative References 893 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 894 RFC 2246, January 1999. 896 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 897 Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. 899 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites 900 for Transport Layer Security (TLS)", RFC 3268, June 2002. 902 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 903 and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, 904 April 2006. 906 Copyright, Disclaimer, and Additional IPR Provisions 908 Copyright (C) The IETF Trust (2008). 910 This document is subject to the rights, licenses and restrictions 911 contained in BCP 78, and except as set forth therein, the authors 912 retain all their rights. 914 This document and the information contained herein are provided on an 915 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 916 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 917 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 918 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 919 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 920 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 922 The IETF takes no position regarding the validity or scope of any 923 Intellectual Property Rights or other rights that might be claimed to 924 pertain to the implementation or use of the technology described in 925 this document or the extent to which any license under such rights 926 might or might not be available; nor does it represent that it has 927 made any independent effort to identify any such rights. Information 928 on the procedures with respect to rights in RFC documents can be 929 found in BCP 78 and BCP 79. 931 Copies of IPR disclosures made to the IETF Secretariat and any 932 assurances of licenses to be made available, or the result of an 933 attempt made to obtain a general license or permission for the use of 934 such proprietary rights by implementers or users of this 935 specification can be obtained from the IETF on-line IPR repository at 936 http://www.ietf.org/ipr. 938 The IETF invites any interested party to bring to its attention any 939 copyrights, patents or patent applications, or other proprietary 940 rights that may cover technology that may be required to implement 941 this standard. Please address the information to the IETF at ietf- 942 ipr@ietf.org. 944 Author's Address 946 Donald Eastlake 3rd 947 Motorola Laboratories 948 111 Locke Drive 949 Marlborough, MA 01752 951 Tel: +1-508-786-7554 952 Email: Donald.Eastlake@motorola.com 954 Expiration and File Name 956 This draft expires in August 2008. 958 Its file name is draft-ietf-tls-rfc4366-bis-02.txt.