idnits 2.17.1 draft-ietf-tls-rfc4366-bis-01.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 867. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 889. 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. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2246, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 551 has weird spacing: '...ensions reque...' (Using the creation date from RFC2246, updated by this document, for RFC5378 checks: 1996-12-03) -- 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 (January 14, 2009) is 5575 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 338 ** 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 3490 (Obsoleted by RFC 5890, RFC 5891) ** 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: 7 errors (**), 0 flaws (~~), 5 warnings (==), 15 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 Motorola Laboratories 3 Obsoletes: RFC 4366 4 Updates: RFC 2246, RFC 4346 5 Intended status: Proposed Standard 6 Expires: July 2008 January 14, 2009 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 3. Server Name Indication..................................5 63 4. Maximum Fragment Length Negotiation.....................6 64 5. Client Certificate URLs.................................7 65 6. Trusted CA Indication..................................10 66 7. Truncated HMAC.........................................11 67 8. Certificate Status Request.............................12 69 9. IANA Considerations....................................15 70 10. Security Considerations...............................15 71 10.1 Security Considerations for server_name..............15 72 10.2 Security Considerations for max_fragment_length......15 73 10.3 Security Considerations for client_certificate_url...16 74 10.4 Security Considerations for trusted_ca_keys..........17 75 10.5 Security Considerations for truncated_hmac...........17 76 10.6 Security Considerations for status_request...........18 77 11. Internationalization Considerations...................18 79 12. Normative References..................................19 80 13. Informative References................................19 82 Copyright, Disclaimer, and Additional IPR Provisions......21 84 Author's Address..........................................22 85 Expiration and File Name..................................22 87 1. Introduction 89 The TLS (Transport Layer Security) Protocol Version 1.2 is specified 90 in [RFCTLS]. That specification includes the framework for extensions 91 to TLS, considerations in designing such extensions (see Section 92 7.4.1.4 of [RFCTLS]), and IANA Considerations for the allocation of 93 new extension code points; however, it does not specify any 94 particular extensions other than CertHashTypes (see Section 95 7.4.1.4.1of [RFCTLS]). 97 This document provides the specifications for existing TLS 98 extensions. It is, for the most part, the mere adaptation and editing 99 of material from [RFC4366], which covered all aspects of TLS 100 extensions for TLS 1.0 [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 Specifically, the extensions described in this document: 110 - Allow TLS clients to provide to the TLS server the name of the 111 server they are contacting. This functionality is desirable in 112 order to facilitate secure connections to servers that host 113 multiple 'virtual' servers at a single underlying network address. 115 - Allow TLS clients and servers to negotiate the maximum fragment 116 length to be sent. This functionality is desirable as a result of 117 memory constraints among some clients, and bandwidth constraints 118 among some access networks. 120 - Allow TLS clients and servers to negotiate the use of client 121 certificate URLs. This functionality is desirable in order to 122 conserve memory on constrained clients. 124 - Allow TLS clients to indicate to TLS servers which CA root keys 125 they possess. This functionality is desirable in order to prevent 126 multiple handshake failures involving TLS clients that are only 127 able to store a small number of CA root keys due to memory 128 limitations. 130 - Allow TLS clients and servers to negotiate the use of truncated 131 MACs. This functionality is desirable in order to conserve 132 bandwidth in constrained access networks. 134 - Allow TLS clients and servers to negotiate that the server sends 135 the client certificate status information (e.g., an Online 136 Certificate Status Protocol (OCSP) [RFC2560] response) during a 137 TLS handshake. This functionality is desirable in order to avoid 138 sending a Certificate Revocation List (CRL) over a constrained 139 access network and therefore save bandwidth. 141 The extensions described in this document may be used by TLS clients 142 and servers. The extensions are designed to be backwards compatible, 143 meaning that TLS clients that support the extensions can talk to TLS 144 servers that do not support the extensions, and vice versa. The 145 document therefore updates TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346]. 147 1.2 Conventions Used in This Document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 3. Server Name Indication 155 TLS does not provide a mechanism for a client to tell a server the 156 name of the server it is contacting. It may be desirable for clients 157 to provide this information to facilitate secure connections to 158 servers that host multiple 'virtual' servers at a single underlying 159 network address. 161 In order to provide the server name, clients MAY include an extension 162 of type "server_name" in the (extended) client hello. The 163 "extension_data" field of this extension SHALL contain 164 "ServerNameList" where: 166 struct { 167 NameType name_type; 168 select (name_type) { 169 case host_name: HostName; 170 } name; 171 } ServerName; 173 enum { 174 host_name(0), (255) 175 } NameType; 177 opaque HostName<1..2^16-1>; 179 struct { 180 ServerName server_name_list<1..2^16-1> 181 } ServerNameList; 183 Currently, the only server names supported are DNS hostnames; 184 however, this does not imply any dependency of TLS on DNS, and other 185 name types may be added in the future (by an RFC that updates this 186 document). TLS MAY treat provided server names as opaque data and 187 pass the names and types to the application. 189 "HostName" contains the fully qualified DNS hostname of the server, 190 as understood by the client. The hostname is represented as a byte 191 string using UTF-8 encoding [RFC3629], without a trailing dot. 193 If the hostname labels contain only US-ASCII characters, then the 194 client MUST ensure that labels are separated only by the byte 0x2E, 195 representing the dot character U+002E (requirement 1 in Section 3.1 196 of [RFC3490] notwithstanding). If the server needs to match the 197 HostName against names that contain non-US-ASCII characters, it MUST 198 perform the conversion operation described in Section 4 of [RFC3490], 199 treating the HostName as a "query string" (i.e., the AllowUnassigned 200 flag MUST be set). Note that IDNA allows labels to be separated by 201 any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61; 202 therefore, servers MUST accept any of these characters as a label 203 separator. If the server only needs to match the HostName against 204 names containing exclusively ASCII characters, it MUST compare ASCII 205 names case-insensitively. 207 Literal IPv4 and IPv6 addresses are not permitted in "HostName". 209 It is RECOMMENDED that clients include an extension of type 210 "server_name" in the client hello whenever they locate a server by a 211 supported name type. 213 A server that receives a client hello containing the "server_name" 214 extension MAY use the information contained in the extension to guide 215 its selection of an appropriate certificate to return to the client, 216 and/or other aspects of security policy. In this event, the server 217 SHALL include an extension of type "server_name" in the (extended) 218 server hello. The "extension_data" field of this extension SHALL be 219 empty. 221 If the server understood the client hello extension but does not 222 recognize the server name, it SHOULD send an "unrecognized_name" 223 alert (which MAY be fatal). 225 If an application negotiates a server name using an application 226 protocol and then upgrades to TLS, and if a server_name extension is 227 sent, then the extension SHOULD contain the same name that was 228 negotiated in the application protocol. If the server_name is 229 established in the TLS session handshake, the client SHOULD NOT 230 attempt to request a different server name at the application layer. 232 4. Maximum Fragment Length Negotiation 234 Without this extension, TLS specifies a fixed maximum plaintext 235 fragment length of 2^14 bytes. It may be desirable for constrained 236 clients to negotiate a smaller maximum fragment length due to memory 237 limitations or bandwidth limitations. 239 In order to negotiate smaller maximum fragment lengths, clients MAY 240 include an extension of type "max_fragment_length" in the (extended) 241 client hello. The "extension_data" field of this extension SHALL 242 contain: 244 enum{ 245 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) 246 } MaxFragmentLength; 248 whose value is the desired maximum fragment length. The allowed 249 values for this field are: 2^9, 2^10, 2^11, and 2^12. 251 Servers that receive an extended client hello containing a 252 "max_fragment_length" extension MAY accept the requested maximum 253 fragment length by including an extension of type 254 "max_fragment_length" in the (extended) server hello. The 255 "extension_data" field of this extension SHALL contain a 256 "MaxFragmentLength" whose value is the same as the requested maximum 257 fragment length. 259 If a server receives a maximum fragment length negotiation request 260 for a value other than the allowed values, it MUST abort the 261 handshake with an "illegal_parameter" alert. Similarly, if a client 262 receives a maximum fragment length negotiation response that differs 263 from the length it requested, it MUST also abort the handshake with 264 an "illegal_parameter" alert. 266 Once a maximum fragment length other than 2^14 has been successfully 267 negotiated, the client and server MUST immediately begin fragmenting 268 messages (including handshake messages), to ensure that no fragment 269 larger than the negotiated length is sent. Note that TLS already 270 requires clients and servers to support fragmentation of handshake 271 messages. 273 The negotiated length applies for the duration of the session 274 including session resumptions. 276 The negotiated length limits the input that the record layer may 277 process without fragmentation (that is, the maximum value of 278 TLSPlaintext.length; see [RFCTLS], Section 6.2.1). Note that the 279 output of the record layer may be larger. For example, if the 280 negotiated length is 2^9=512, then for currently defined cipher 281 suites (those defined in [RFCTLS], [RFC2712], and [RFC3268]), and 282 when null compression is used, the record layer output can be at most 283 793 bytes: 5 bytes of headers, 512 bytes of application data, 256 284 bytes of padding, and 20 bytes of MAC. This means that in this event 285 a TLS record layer peer receiving a TLS record layer message larger 286 than 793 bytes may discard the message and send a "record_overflow" 287 alert, without decrypting the message. 289 5. Client Certificate URLs 291 Without this extension, TLS specifies that when client authentication 292 is performed, client certificates are sent by clients to servers 293 during the TLS handshake. It may be desirable for constrained clients 294 to send certificate URLs in place of certificates, so that they do 295 not need to store their certificates and can therefore save memory. 297 In order to negotiate sending certificate URLs to a server, clients 298 MAY include an extension of type "client_certificate_url" in the 299 (extended) client hello. The "extension_data" field of this extension 300 SHALL be empty. 302 (Note that it is necessary to negotiate use of client certificate 303 URLs in order to avoid "breaking" existing TLS servers.) 305 Servers that receive an extended client hello containing a 306 "client_certificate_url" extension MAY indicate that they are willing 307 to accept certificate URLs by including an extension of type 308 "client_certificate_url" in the (extended) server hello. The 309 "extension_data" field of this extension SHALL be empty. 311 After negotiation of the use of client certificate URLs has been 312 successfully completed (by exchanging hellos including 313 "client_certificate_url" extensions), clients MAY send a 314 "CertificateURL" message in place of a "Certificate" message: 316 enum { 317 individual_certs(0), pkipath(1), (255) 318 } CertChainType; 320 enum { 321 false(0), true(1) 322 } Boolean; 324 struct { 325 CertChainType type; 326 URLAndOptionalHash url_and_hash_list<1..2^16-1>; 327 } CertificateURL; 329 struct { 330 opaque url<1..2^16-1>; 331 Boolean hash_present; 332 select (hash_present) { 333 case false: struct {}; 334 case true: SHA1Hash; 335 } hash; 336 } URLAndOptionalHash; 338 opaque SHA1Hash[20]; 340 Here "url_and_hash_list" contains a sequence of URLs and optional 341 hashes. 343 When X.509 certificates are used, there are two possibilities: 345 - If CertificateURL.type is "individual_certs", each URL refers to a 346 single DER-encoded X.509v3 certificate, with the URL for the client's 347 certificate first. 349 - If CertificateURL.type is "pkipath", the list contains a single 350 URL referring to a DER-encoded certificate chain, using the type 351 PkiPath described in Section 8 of [RFCTLS]. 353 When any other certificate format is used, the specification that 354 describes use of that format in TLS should define the encoding format 355 of certificates or certificate chains, and any constraint on their 356 ordering. 358 The hash corresponding to each URL at the client's discretion either 359 is not present or is the SHA-1 hash of the certificate or certificate 360 chain (in the case of X.509 certificates, the DER-encoded certificate 361 or the DER-encoded PkiPath). 363 Note that when a list of URLs for X.509 certificates is used, the 364 ordering of URLs is the same as that used in the TLS Certificate 365 message (see [RFCTLS], Section 7.4.2), but opposite to the order in 366 which certificates are encoded in PkiPath. In either case, the self- 367 signed root certificate MAY be omitted from the chain, under the 368 assumption that the server must already possess it in order to 369 validate it. 371 Servers receiving "CertificateURL" SHALL attempt to retrieve the 372 client's certificate chain from the URLs and then process the 373 certificate chain as usual. A cached copy of the content of any URL 374 in the chain MAY be used, provided that a SHA-1 hash is present for 375 that URL and it matches the hash of the cached copy. 377 Servers that support this extension MUST support the http: URL scheme 378 for certificate URLs, and MAY support other schemes. Use of other 379 schemes than "http", "https", or "ftp" may create unexpected 380 problems. 382 If the protocol used is HTTP, then the HTTP server can be configured 383 to use the Cache-Control and Expires directives described in 384 [RFC2616] to specify whether and for how long certificates or 385 certificate chains should be cached. 387 The TLS server is not required to follow HTTP redirects when 388 retrieving the certificates or certificate chain. The URLs used in 389 this extension SHOULD therefore be chosen not to depend on such 390 redirects. 392 If the protocol used to retrieve certificates or certificate chains 393 returns a MIME-formatted response (as HTTP does), then the following 394 MIME Content-Types SHALL be used: when a single X.509v3 certificate 395 is returned, the Content-Type is "application/pkix-cert" [RFC2585], 396 and when a chain of X.509v3 certificates is returned, the Content- 397 Type is "application/pkix-pkipath" (see Section 8 of [RFCTLS]). 399 If a SHA-1 hash is present for an URL, then the server MUST check 400 that the SHA-1 hash of the contents of the object retrieved from that 401 URL (after decoding any MIME Content-Transfer-Encoding) matches the 402 given hash. If any retrieved object does not have the correct SHA-1 403 hash, the server MUST abort the handshake with a 404 "bad_certificate_hash_value" alert. 406 Note that clients may choose to send either "Certificate" or 407 "CertificateURL" after successfully negotiating the option to send 408 certificate URLs. The option to send a certificate is included to 409 provide flexibility to clients possessing multiple certificates. 411 If a server encounters an unreasonable delay in obtaining 412 certificates in a given CertificateURL, it SHOULD time out and signal 413 a "certificate_unobtainable" error alert. 415 6. Trusted CA Indication 417 Constrained clients that, due to memory limitations, possess only a 418 small number of CA root keys may wish to indicate to servers which 419 root keys they possess, in order to avoid repeated handshake 420 failures. 422 In order to indicate which CA root keys they possess, clients MAY 423 include an extension of type "trusted_ca_keys" in the (extended) 424 client hello. The "extension_data" field of this extension SHALL 425 contain "TrustedAuthorities" where: 427 struct { 428 TrustedAuthority trusted_authorities_list<0..2^16-1>; 429 } TrustedAuthorities; 431 struct { 432 IdentifierType identifier_type; 433 select (identifier_type) { 434 case pre_agreed: struct {}; 435 case key_sha1_hash: SHA1Hash; 436 case x509_name: DistinguishedName; 437 case cert_sha1_hash: SHA1Hash; 438 } identifier; 439 } TrustedAuthority; 441 enum { 442 pre_agreed(0), key_sha1_hash(1), x509_name(2), 443 cert_sha1_hash(3), (255) 444 } IdentifierType; 446 opaque DistinguishedName<1..2^16-1>; 448 Here "TrustedAuthorities" provides a list of CA root key identifiers 449 that the client possesses. Each CA root key is identified via either: 451 - "pre_agreed": no CA root key identity supplied. 453 - "key_sha1_hash": contains the SHA-1 hash of the CA root key. For 454 Digital Signature Algorithm (DSA) and Elliptic Curve Digital 455 Signature Algorithm (ECDSA) keys, this is the hash of the 456 "subjectPublicKey" value. For RSA keys, the hash is of the big- 457 endian byte string representation of the modulus without any 458 initial 0-valued bytes. (This copies the key hash formats deployed 459 in other environments.) 461 - "x509_name": contains the DER-encoded X.509 DistinguishedName of 462 the CA. 464 - "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded 465 Certificate containing the CA root key. 467 Note that clients may include none, some, or all of the CA root keys 468 they possess in this extension. 470 Note also that it is possible that a key hash or a Distinguished Name 471 alone may not uniquely identify a certificate issuer (for example, if 472 a particular CA has multiple key pairs). However, here we assume this 473 is the case following the use of Distinguished Names to identify 474 certificate issuers in TLS. 476 The option to include no CA root keys is included to allow the client 477 to indicate possession of some pre-defined set of CA root keys. 479 Servers that receive a client hello containing the "trusted_ca_keys" 480 extension MAY use the information contained in the extension to guide 481 their selection of an appropriate certificate chain to return to the 482 client. In this event, the server SHALL include an extension of type 483 "trusted_ca_keys" in the (extended) server hello. The 484 "extension_data" field of this extension SHALL be empty. 486 7. Truncated HMAC 488 Currently defined TLS cipher suites use the MAC construction HMAC 489 with either MD5 or SHA-1 [RFC2104] to authenticate record layer 490 communications. In TLS, the entire output of the hash function is 491 used as the MAC tag. However, it may be desirable in constrained 492 environments to save bandwidth by truncating the output of the hash 493 function to 80 bits when forming MAC tags. 495 In order to negotiate the use of 80-bit truncated HMAC, clients MAY 496 include an extension of type "truncated_hmac" in the extended client 497 hello. The "extension_data" field of this extension SHALL be empty. 499 Servers that receive an extended hello containing a "truncated_hmac" 500 extension MAY agree to use a truncated HMAC by including an extension 501 of type "truncated_hmac", with empty "extension_data", in the 502 extended server hello. 504 Note that if new cipher suites are added that do not use HMAC, and 505 the session negotiates one of these cipher suites, this extension 506 will have no effect. It is strongly recommended that any new cipher 507 suites using other MACs consider the MAC size an integral part of the 508 cipher suite definition, taking into account both security and 509 bandwidth considerations. 511 If HMAC truncation has been successfully negotiated during a TLS 512 handshake, and the negotiated cipher suite uses HMAC, both the client 513 and the server pass this fact to the TLS record layer along with the 514 other negotiated security parameters. Subsequently during the 515 session, clients and servers MUST use truncated HMACs, calculated as 516 specified in [RFC2104]. That is, CipherSpec.hash_size is 10 bytes, 517 and only the first 10 bytes of the HMAC output are transmitted and 518 checked. Note that this extension does not affect the calculation of 519 the pseudo-random function (PRF) as part of handshaking or key 520 derivation. 522 The negotiated HMAC truncation size applies for the duration of the 523 session including session resumptions. 525 8. Certificate Status Request 527 Constrained clients may wish to use a certificate-status protocol 528 such as OCSP [RFC2560] to check the validity of server certificates, 529 in order to avoid transmission of CRLs and therefore save bandwidth 530 on constrained networks. This extension allows for such information 531 to be sent in the TLS handshake, saving roundtrips and resources. 533 In order to indicate their desire to receive certificate status 534 information, clients MAY include an extension of type 535 "status_request" in the (extended) client hello. The "extension_data" 536 field of this extension SHALL contain "CertificateStatusRequest" 537 where: 539 struct { 540 CertificateStatusType status_type; 541 select (status_type) { 542 case ocsp: OCSPStatusRequest; 543 } request; 545 } CertificateStatusRequest; 547 enum { ocsp(1), (255) } CertificateStatusType; 549 struct { 550 ResponderID responder_id_list<0..2^16-1>; 551 Extensions request_extensions; 552 } OCSPStatusRequest; 554 opaque ResponderID<1..2^16-1>; 555 opaque Extensions<0..2^16-1>; 557 In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP 558 responders that the client trusts. A zero-length "responder_id_list" 559 sequence has the special meaning that the responders are implicitly 560 known to the server, e.g., by prior arrangement. "Extensions" is a 561 DER encoding of OCSP request extensions. 563 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as 564 defined in [RFC2560]. "Extensions" is imported from [RFC3280]. A 565 zero-length "request_extensions" value means that there are no 566 extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not 567 valid for the "Extensions" type). 569 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is 570 unclear about its encoding; for clarification, the nonce MUST be a 571 DER-encoded OCTET STRING, which is encapsulated as another OCTET 572 STRING (note that implementations based on an existing OCSP client 573 will need to be checked for conformance to this requirement). 575 Servers that receive a client hello containing the "status_request" 576 extension MAY return a suitable certificate status response to the 577 client along with their certificate. If OCSP is requested, they 578 SHOULD use the information contained in the extension when selecting 579 an OCSP responder and SHOULD include request_extensions in the OCSP 580 request. 582 Servers return a certificate response along with their certificate by 583 sending a "CertificateStatus" message immediately after the 584 "Certificate" message (and before any "ServerKeyExchange" or 585 "CertificateRequest" messages). If a server returns a 586 "CertificateStatus" message, then the server MUST have included an 587 extension of type "status_request" with empty "extension_data" in the 588 extended server hello. 590 struct { 591 CertificateStatusType status_type; 592 select (status_type) { 593 case ocsp: OCSPResponse; 594 } response; 596 } CertificateStatus; 598 opaque OCSPResponse<1..2^24-1>; 600 An "ocsp_response" contains a complete, DER-encoded OCSP response 601 (using the ASN.1 type OCSPResponse defined in [RFC2560]). Note that 602 only one OCSP response may be sent. 604 The "CertificateStatus" message is conveyed using the handshake 605 message type "certificate_status". 607 Note that a server MAY also choose not to send a "CertificateStatus" 608 message, even if it receives a "status_request" extension in the 609 client hello message. 611 Note in addition that servers MUST NOT send the "CertificateStatus" 612 message unless it received a "status_request" extension in the client 613 hello message. 615 Clients requesting an OCSP response and receiving an OCSP response in 616 a "CertificateStatus" message MUST check the OCSP response and abort 617 the handshake if the response is not satisfactory. 619 certificate_unobtainable(111), /* new */ 620 unrecognized_name(112), /* new */ 621 bad_certificate_status_response(113), /* new */ 622 bad_certificate_hash_value(114), /* new */ 623 (255) 624 } AlertDescription; 626 9. IANA Considerations 628 IANA Considerations for TLS Extensions and the creation of a Registry 629 therefore are all covered in Section 12 of [RFCTLS].. 631 10. Security Considerations 633 General Security Considerations for TLS Extensions are covered in 634 [RFCTLS]. Security Considerations for particular extensions specified 635 in this document are given below. 637 In general, implementers should continue to monitor the state of the 638 art and address any weaknesses identified. 640 Additional security considerations are described in the TLS 1.0 RFC 641 [RFC2246] and the TLS 1.1 RFC [RFC4346]. 643 10.1 Security Considerations for server_name 645 If a single server hosts several domains, then clearly it is 646 necessary for the owners of each domain to ensure that this satisfies 647 their security needs. Apart from this, server_name does not appear to 648 introduce significant security issues. 650 Implementations MUST ensure that a buffer overflow does not occur, 651 whatever the values of the length fields in server_name. 653 Although this document specifies an encoding for internationalized 654 hostnames in the server_name extension, it does not address any 655 security issues associated with the use of internationalized 656 hostnames in TLS (in particular, the consequences of "spoofed" names 657 that are indistinguishable from another name when displayed or 658 printed). It is recommended that server certificates not be issued 659 for internationalized hostnames unless procedures are in place to 660 mitigate the risk of spoofed hostnames. 662 10.2 Security Considerations for max_fragment_length 664 The maximum fragment length takes effect immediately, including for 665 handshake messages. However, that does not introduce any security 666 complications that are not already present in TLS, since TLS requires 667 implementations to be able to handle fragmented handshake messages. 669 Note that as described in Section 4, once a non-null cipher suite has 670 been activated, the effective maximum fragment length depends on the 671 cipher suite and compression method, as well as on the negotiated 672 max_fragment_length. This must be taken into account when sizing 673 buffers, and checking for buffer overflow. 675 10.3 Security Considerations for client_certificate_url 677 There are two major issues with this extension. 679 The first major issue is whether or not clients should include 680 certificate hashes when they send certificate URLs. 682 When client authentication is used *without* the 683 client_certificate_url extension, the client certificate chain is 684 covered by the Finished message hashes. The purpose of including 685 hashes and checking them against the retrieved certificate chain is 686 to ensure that the same property holds when this extension is used, 687 i.e., that all of the information in the certificate chain retrieved 688 by the server is as the client intended. 690 On the other hand, omitting certificate hashes enables functionality 691 that is desirable in some circumstances; for example, clients can be 692 issued daily certificates that are stored at a fixed URL and need not 693 be provided to the client. Clients that choose to omit certificate 694 hashes should be aware of the possibility of an attack in which the 695 attacker obtains a valid certificate on the client's key that is 696 different from the certificate the client intended to provide. 697 Although TLS uses both MD5 and SHA-1 hashes in several other places, 698 this was not believed to be necessary here. The property required of 699 SHA-1 is second pre-image resistance. 701 The second major issue is that support for client_certificate_url 702 involves the server's acting as a client in another URL protocol. 703 The server therefore becomes subject to many of the same security 704 concerns that clients of the URL scheme are subject to, with the 705 added concern that the client can attempt to prompt the server to 706 connect to some (possibly weird-looking) URL. 708 In general, this issue means that an attacker might use the server to 709 indirectly attack another host that is vulnerable to some security 710 flaw. It also introduces the possibility of denial of service attacks 711 in which an attacker makes many connections to the server, each of 712 which results in the server's attempting a connection to the target 713 of the attack. 715 Note that the server may be behind a firewall or otherwise able to 716 access hosts that would not be directly accessible from the public 717 Internet. This could exacerbate the potential security and denial of 718 service problems described above, as well as allow the existence of 719 internal hosts to be confirmed when they would otherwise be hidden. 721 The detailed security concerns involved will depend on the URL 722 schemes supported by the server. In the case of HTTP, the concerns 723 are similar to those that apply to a publicly accessible HTTP proxy 724 server. In the case of HTTPS, loops and deadlocks may be created, and 725 this should be addressed. In the case of FTP, attacks arise that are 726 similar to FTP bounce attacks. 728 As a result of this issue, it is RECOMMENDED that the 729 client_certificate_url extension should have to be specifically 730 enabled by a server administrator, rather than be enabled by default. 731 It is also RECOMMENDED that URI protocols be enabled by the 732 administrator individually, and only a minimal set of protocols be 733 enabled. Unusual protocols that offer limited security or whose 734 security is not well-understood SHOULD be avoided. 736 As discussed in [RFC3986], URLs that specify ports other than the 737 default may cause problems, as may very long URLs (which are more 738 likely to be useful in exploiting buffer overflow bugs). 740 Also note that HTTP caching proxies are common on the Internet, and 741 some proxies do not check for the latest version of an object 742 correctly. If a request using HTTP (or another caching protocol) goes 743 through a misconfigured or otherwise broken proxy, the proxy may 744 return an out-of-date response. 746 10.4 Security Considerations for trusted_ca_keys 748 It is possible that which CA root keys a client possesses could be 749 regarded as confidential information. As a result, the CA root key 750 indication extension should be used with care. 752 The use of the SHA-1 certificate hash alternative ensures that each 753 certificate is specified unambiguously. As for the previous 754 extension, it was not believed necessary to use both MD5 and SHA-1 755 hashes. 757 10.5 Security Considerations for truncated_hmac 759 It is possible that truncated MACs are weaker than "un-truncated" 760 MACs. However, no significant weaknesses are currently known or 761 expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. 763 Note that the output length of a MAC need not be as long as the 764 length of a symmetric cipher key, since forging of MAC values cannot 765 be done off-line: in TLS, a single failed MAC guess will cause the 766 immediate termination of the TLS session. 768 Since the MAC algorithm only takes effect after all handshake 769 messages that affect extension parameters have been authenticated by 770 the hashes in the Finished messages, it is not possible for an active 771 attacker to force negotiation of the truncated HMAC extension where 772 it would not otherwise be used (to the extent that the handshake 773 authentication is secure). Therefore, in the event that any security 774 problem were found with truncated HMAC in the future, if either the 775 client or the server for a given session were updated to take the 776 problem into account, it would be able to veto use of this extension. 778 10.6 Security Considerations for status_request 780 If a client requests an OCSP response, it must take into account that 781 an attacker's server using a compromised key could (and probably 782 would) pretend not to support the extension. In this case, a client 783 that requires OCSP validation of certificates SHOULD either contact 784 the OCSP server directly or abort the handshake. 786 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may 787 improve security against attacks that attempt to replay OCSP 788 responses; see Section 4.4.1 of [RFC2560] for further details. 790 11. Internationalization Considerations 792 None of the extensions defined here directly use strings subject to 793 localization. Domain Name System (DNS) hostnames are encoded using 794 UTF-8. If future extensions use text strings, then 795 internationalization should be considered in their design. 797 12. Normative References 799 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 800 Hashing for Message Authentication", RFC 2104, February 1997. 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, March 1997. 805 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 806 Adams, "X.509 Internet Public Key Infrastructure Online Certificate 807 Status Protocol - OCSP", RFC 2560, June 1999. 809 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 810 Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 811 1999. 813 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 814 L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 815 HTTP/1.1", RFC 2616, June 1999. 817 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 818 X.509 Public Key Infrastructure Certificate and Certificate 819 Revocation List (CRL) Profile", RFC 3280, April 2002. 821 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 822 "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, 823 March 2003. 825 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 826 STD 63, RFC 3629, November 2003. 828 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 829 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 830 2005. 832 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 833 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 835 [RFCTLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2", 836 draft-ietf-tls-rfc4346-bis-*.txt, March 2007. 838 13. Informative References 840 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 841 RFC 2246, January 1999. 843 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 844 Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. 846 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites 847 for Transport Layer Security (TLS)", RFC 3268, June 2002. 849 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 850 and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, 851 April 2006. 853 Copyright, Disclaimer, and Additional IPR Provisions 855 Copyright (C) The IETF Trust (2008). 857 This document is subject to the rights, licenses and restrictions 858 contained in BCP 78, and except as set forth therein, the authors 859 retain all their rights. 861 This document and the information contained herein are provided on an 862 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 863 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 864 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 865 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 866 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 867 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 869 The IETF takes no position regarding the validity or scope of any 870 Intellectual Property Rights or other rights that might be claimed to 871 pertain to the implementation or use of the technology described in 872 this document or the extent to which any license under such rights 873 might or might not be available; nor does it represent that it has 874 made any independent effort to identify any such rights. Information 875 on the procedures with respect to rights in RFC documents can be 876 found in BCP 78 and BCP 79. 878 Copies of IPR disclosures made to the IETF Secretariat and any 879 assurances of licenses to be made available, or the result of an 880 attempt made to obtain a general license or permission for the use of 881 such proprietary rights by implementers or users of this 882 specification can be obtained from the IETF on-line IPR repository at 883 http://www.ietf.org/ipr. 885 The IETF invites any interested party to bring to its attention any 886 copyrights, patents or patent applications, or other proprietary 887 rights that may cover technology that may be required to implement 888 this standard. Please address the information to the IETF at ietf- 889 ipr@ietf.org. 891 Author's Address 893 Donald Eastlake 3rd 894 Motorola Laboratories 895 111 Locke Drive 896 Marlborough, MA 01752 898 Tel: +1-508-786-7554 899 Email: Donald.Eastlake@motorola.com 901 Expiration and File Name 903 This draft expires in July 2008. 905 Its file name is draft-ietf-tls-rfc4366-bis-01.txt.