7Internet Engineering Task Force (IETF) D. Eastlake 3rd
8Request for Comments: 6066 Huawei
9Obsoletes: 4366 January 2011
10Category: Standards Track
14 Transport Layer Security (TLS) Extensions: Extension Definitions
18 This document provides specifications for existing TLS extensions.
19 It is a companion document for RFC 5246, "The Transport Layer
20 Security (TLS) Protocol Version 1.2". The extensions specified are
21 server_name, max_fragment_length, client_certificate_url,
22 trusted_ca_keys, truncated_hmac, and status_request.
26 This is an Internet Standards Track document.
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 Internet Standards is available in Section 2 of RFC 5741.
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 http://www.rfc-editor.org/info/rfc6066.
40 Copyright (c) 2011 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
58Eastlake Standards Track [Page 1]
60RFC 6066 TLS Extension Definitions January 2011
63 This document may contain material from IETF Documents or IETF
64 Contributions published or made publicly available before November
65 10, 2008. The person(s) controlling the copyright in some of this
66 material may not have granted the IETF Trust the right to allow
67 modifications of such material outside the IETF Standards Process.
68 Without obtaining an adequate license from the person(s) controlling
69 the copyright in such materials, this document may not be modified
70 outside the IETF Standards Process, and derivative works of it may
71 not be created outside the IETF Standards Process, except to format
72 it for publication as an RFC or to translate it into languages other
77 1. Introduction ....................................................3
78 1.1. Specific Extensions Covered ................................3
79 1.2. Conventions Used in This Document ..........................5
80 2. Extensions to the Handshake Protocol ............................5
81 3. Server Name Indication ..........................................6
82 4. Maximum Fragment Length Negotiation .............................8
83 5. Client Certificate URLs .........................................9
84 6. Trusted CA Indication ..........................................12
85 7. Truncated HMAC .................................................13
86 8. Certificate Status Request .....................................14
87 9. Error Alerts ...................................................16
88 10. IANA Considerations ...........................................17
89 10.1. pkipath MIME Type Registration ...........................17
90 10.2. Reference for TLS Alerts, TLS HandshakeTypes, and
91 ExtensionTypes ...........................................19
92 11. Security Considerations .......................................19
93 11.1. Security Considerations for server_name ..................19
94 11.2. Security Considerations for max_fragment_length ..........20
95 11.3. Security Considerations for client_certificate_url .......20
96 11.4. Security Considerations for trusted_ca_keys ..............21
97 11.5. Security Considerations for truncated_hmac ...............21
98 11.6. Security Considerations for status_request ...............22
99 12. Normative References ..........................................22
100 13. Informative References ........................................23
101 Appendix A. Changes from RFC 4366 .................................24
102 Appendix B. Acknowledgements ......................................25
114Eastlake Standards Track [Page 2]
116RFC 6066 TLS Extension Definitions January 2011
121 The Transport Layer Security (TLS) Protocol Version 1.2 is specified
122 in [RFC5246]. That specification includes the framework for
123 extensions to TLS, considerations in designing such extensions (see
124 Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the
125 allocation of new extension code points; however, it does not specify
126 any particular extensions other than Signature Algorithms (see
127 Section 7.4.1.4.1 of [RFC5246]).
129 This document provides the specifications for existing TLS
130 extensions. It is, for the most part, the adaptation and editing of
131 material from RFC 4366, which covered TLS extensions for TLS 1.0 (RFC
132 2246) and TLS 1.1 (RFC 4346).
1341.1. Specific Extensions Covered
136 The extensions described here focus on extending the functionality
137 provided by the TLS protocol message formats. Other issues, such as
138 the addition of new cipher suites, are deferred.
140 The extension types defined in this document are:
143 server_name(0), max_fragment_length(1),
144 client_certificate_url(2), trusted_ca_keys(3),
145 truncated_hmac(4), status_request(5), (65535)
148 Specifically, the extensions described in this document:
150 - Allow TLS clients to provide to the TLS server the name of the
151 server they are contacting. This functionality is desirable in
152 order to facilitate secure connections to servers that host
153 multiple 'virtual' servers at a single underlying network address.
155 - Allow TLS clients and servers to negotiate the maximum fragment
156 length to be sent. This functionality is desirable as a result of
157 memory constraints among some clients, and bandwidth constraints
158 among some access networks.
160 - Allow TLS clients and servers to negotiate the use of client
161 certificate URLs. This functionality is desirable in order to
162 conserve memory on constrained clients.
170Eastlake Standards Track [Page 3]
172RFC 6066 TLS Extension Definitions January 2011
175 - Allow TLS clients to indicate to TLS servers which certification
176 authority (CA) root keys they possess. This functionality is
177 desirable in order to prevent multiple handshake failures
178 involving TLS clients that are only able to store a small number
179 of CA root keys due to memory limitations.
181 - Allow TLS clients and servers to negotiate the use of truncated
182 Message Authentication Codes (MACs). This functionality is
183 desirable in order to conserve bandwidth in constrained access
186 - Allow TLS clients and servers to negotiate that the server sends
187 the client certificate status information (e.g., an Online
188 Certificate Status Protocol (OCSP) [RFC2560] response) during a
189 TLS handshake. This functionality is desirable in order to avoid
190 sending a Certificate Revocation List (CRL) over a constrained
191 access network and therefore saving bandwidth.
193 TLS clients and servers may use the extensions described in this
194 document. The extensions are designed to be backwards compatible,
195 meaning that TLS clients that support the extensions can talk to TLS
196 servers that do not support the extensions, and vice versa.
198 Note that any messages associated with these extensions that are sent
199 during the TLS handshake MUST be included in the hash calculations
200 involved in "Finished" messages.
202 Note also that all the extensions defined in this document are
203 relevant only when a session is initiated. A client that requests
204 session resumption does not in general know whether the server will
205 accept this request, and therefore it SHOULD send the same extensions
206 as it would send if it were not attempting resumption. When a client
207 includes one or more of the defined extension types in an extended
208 client hello while requesting session resumption:
210 - The server name indication extension MAY be used by the server
211 when deciding whether or not to resume a session as described in
214 - If the resumption request is denied, the use of the extensions is
215 negotiated as normal.
217 - If, on the other hand, the older session is resumed, then the
218 server MUST ignore the extensions and send a server hello
219 containing none of the extension types. In this case, the
220 functionality of these extensions negotiated during the original
221 session initiation is applied to the resumed session.
226Eastlake Standards Track [Page 4]
228RFC 6066 TLS Extension Definitions January 2011
2311.2. Conventions Used in This Document
233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
235 "OPTIONAL" in this document are to be interpreted as described in
2382. Extensions to the Handshake Protocol
240 This document specifies the use of two new handshake messages,
241 "CertificateURL" and "CertificateStatus". These messages are
242 described in Sections 5 and 8, respectively. The new handshake
243 message structure therefore becomes:
246 hello_request(0), client_hello(1), server_hello(2),
247 certificate(11), server_key_exchange (12),
248 certificate_request(13), server_hello_done(14),
249 certificate_verify(15), client_key_exchange(16),
250 finished(20), certificate_url(21), certificate_status(22),
255 HandshakeType msg_type; /* handshake type */
256 uint24 length; /* bytes in message */
257 select (HandshakeType) {
258 case hello_request: HelloRequest;
259 case client_hello: ClientHello;
260 case server_hello: ServerHello;
261 case certificate: Certificate;
262 case server_key_exchange: ServerKeyExchange;
263 case certificate_request: CertificateRequest;
264 case server_hello_done: ServerHelloDone;
265 case certificate_verify: CertificateVerify;
266 case client_key_exchange: ClientKeyExchange;
267 case finished: Finished;
268 case certificate_url: CertificateURL;
269 case certificate_status: CertificateStatus;
282Eastlake Standards Track [Page 5]
284RFC 6066 TLS Extension Definitions January 2011
2873. Server Name Indication
289 TLS does not provide a mechanism for a client to tell a server the
290 name of the server it is contacting. It may be desirable for clients
291 to provide this information to facilitate secure connections to
292 servers that host multiple 'virtual' servers at a single underlying
295 In order to provide any of the server names, clients MAY include an
296 extension of type "server_name" in the (extended) client hello. The
297 "extension_data" field of this extension SHALL contain
298 "ServerNameList" where:
303 case host_name: HostName;
311 opaque HostName<1..2^16-1>;
314 ServerName server_name_list<1..2^16-1>
317 The ServerNameList MUST NOT contain more than one name of the same
318 name_type. If the server understood the ClientHello extension but
319 does not recognize the server name, the server SHOULD take one of two
320 actions: either abort the handshake by sending a fatal-level
321 unrecognized_name(112) alert or continue the handshake. It is NOT
322 RECOMMENDED to send a warning-level unrecognized_name(112) alert,
323 because the client's behavior in response to warning-level alerts is
324 unpredictable. If there is a mismatch between the server name used
325 by the client application and the server name of the credential
326 chosen by the server, this mismatch will become apparent when the
327 client application performs the server endpoint identification, at
328 which point the client application will have to decide whether to
329 proceed with the communication. TLS implementations are encouraged
330 to make information available to application callers about warning-
331 level alerts that were received or sent during a TLS handshake. Such
332 information can be useful for diagnostic purposes.
338Eastlake Standards Track [Page 6]
340RFC 6066 TLS Extension Definitions January 2011
343 Note: Earlier versions of this specification permitted multiple
344 names of the same name_type. In practice, current client
345 implementations only send one name, and the client cannot
346 necessarily find out which name the server selected. Multiple
347 names of the same name_type are therefore now prohibited.
349 Currently, the only server names supported are DNS hostnames;
350 however, this does not imply any dependency of TLS on DNS, and other
351 name types may be added in the future (by an RFC that updates this
352 document). The data structure associated with the host_name NameType
353 is a variable-length vector that begins with a 16-bit length. For
354 backward compatibility, all future data structures associated with
355 new NameTypes MUST begin with a 16-bit length field. TLS MAY treat
356 provided server names as opaque data and pass the names and types to
359 "HostName" contains the fully qualified DNS hostname of the server,
360 as understood by the client. The hostname is represented as a byte
361 string using ASCII encoding without a trailing dot. This allows the
362 support of internationalized domain names through the use of A-labels
363 defined in [RFC5890]. DNS hostnames are case-insensitive. The
364 algorithm to compare hostnames is described in [RFC5890], Section
369 It is RECOMMENDED that clients include an extension of type
370 "server_name" in the client hello whenever they locate a server by a
373 A server that receives a client hello containing the "server_name"
374 extension MAY use the information contained in the extension to guide
375 its selection of an appropriate certificate to return to the client,
376 and/or other aspects of security policy. In this event, the server
377 SHALL include an extension of type "server_name" in the (extended)
378 server hello. The "extension_data" field of this extension SHALL be
381 When the server is deciding whether or not to accept a request to
382 resume a session, the contents of a server_name extension MAY be used
383 in the lookup of the session in the session cache. The client SHOULD
384 include the same server_name extension in the session resumption
385 request as it did in the full handshake that established the session.
386 A server that implements this extension MUST NOT accept the request
387 to resume the session if the server_name extension contains a
388 different name. Instead, it proceeds with a full handshake to
389 establish a new session. When resuming a session, the server MUST
390 NOT include a server_name extension in the server hello.
394Eastlake Standards Track [Page 7]
396RFC 6066 TLS Extension Definitions January 2011
399 If an application negotiates a server name using an application
400 protocol and then upgrades to TLS, and if a server_name extension is
401 sent, then the extension SHOULD contain the same name that was
402 negotiated in the application protocol. If the server_name is
403 established in the TLS session handshake, the client SHOULD NOT
404 attempt to request a different server name at the application layer.
4064. Maximum Fragment Length Negotiation
408 Without this extension, TLS specifies a fixed maximum plaintext
409 fragment length of 2^14 bytes. It may be desirable for constrained
410 clients to negotiate a smaller maximum fragment length due to memory
411 limitations or bandwidth limitations.
413 In order to negotiate smaller maximum fragment lengths, clients MAY
414 include an extension of type "max_fragment_length" in the (extended)
415 client hello. The "extension_data" field of this extension SHALL
419 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
422 whose value is the desired maximum fragment length. The allowed
423 values for this field are: 2^9, 2^10, 2^11, and 2^12.
425 Servers that receive an extended client hello containing a
426 "max_fragment_length" extension MAY accept the requested maximum
427 fragment length by including an extension of type
428 "max_fragment_length" in the (extended) server hello. The
429 "extension_data" field of this extension SHALL contain a
430 "MaxFragmentLength" whose value is the same as the requested maximum
433 If a server receives a maximum fragment length negotiation request
434 for a value other than the allowed values, it MUST abort the
435 handshake with an "illegal_parameter" alert. Similarly, if a client
436 receives a maximum fragment length negotiation response that differs
437 from the length it requested, it MUST also abort the handshake with
438 an "illegal_parameter" alert.
440 Once a maximum fragment length other than 2^14 has been successfully
441 negotiated, the client and server MUST immediately begin fragmenting
442 messages (including handshake messages) to ensure that no fragment
443 larger than the negotiated length is sent. Note that TLS already
444 requires clients and servers to support fragmentation of handshake
450Eastlake Standards Track [Page 8]
452RFC 6066 TLS Extension Definitions January 2011
455 The negotiated length applies for the duration of the session
456 including session resumptions.
458 The negotiated length limits the input that the record layer may
459 process without fragmentation (that is, the maximum value of
460 TLSPlaintext.length; see [RFC5246], Section 6.2.1). Note that the
461 output of the record layer may be larger. For example, if the
462 negotiated length is 2^9=512, then, when using currently defined
463 cipher suites (those defined in [RFC5246] and [RFC2712]) and null
464 compression, the record-layer output can be at most 805 bytes: 5
465 bytes of headers, 512 bytes of application data, 256 bytes of
466 padding, and 32 bytes of MAC. This means that in this event a TLS
467 record-layer peer receiving a TLS record-layer message larger than
468 805 bytes MUST discard the message and send a "record_overflow"
469 alert, without decrypting the message. When this extension is used
470 with Datagram Transport Layer Security (DTLS), implementations SHOULD
471 NOT generate record_overflow alerts unless the packet passes message
4745. Client Certificate URLs
476 Without this extension, TLS specifies that when client authentication
477 is performed, client certificates are sent by clients to servers
478 during the TLS handshake. It may be desirable for constrained
479 clients to send certificate URLs in place of certificates, so that
480 they do not need to store their certificates and can therefore save
483 In order to negotiate sending certificate URLs to a server, clients
484 MAY include an extension of type "client_certificate_url" in the
485 (extended) client hello. The "extension_data" field of this
486 extension SHALL be empty.
488 (Note that it is necessary to negotiate the use of client certificate
489 URLs in order to avoid "breaking" existing TLS servers.)
491 Servers that receive an extended client hello containing a
492 "client_certificate_url" extension MAY indicate that they are willing
493 to accept certificate URLs by including an extension of type
494 "client_certificate_url" in the (extended) server hello. The
495 "extension_data" field of this extension SHALL be empty.
497 After negotiation of the use of client certificate URLs has been
498 successfully completed (by exchanging hellos including
499 "client_certificate_url" extensions), clients MAY send a
500 "CertificateURL" message in place of a "Certificate" message as
501 follows (see also Section 2):
506Eastlake Standards Track [Page 9]
508RFC 6066 TLS Extension Definitions January 2011
512 individual_certs(0), pkipath(1), (255)
517 URLAndHash url_and_hash_list<1..2^16-1>;
521 opaque url<1..2^16-1>;
526 Here, "url_and_hash_list" contains a sequence of URLs and hashes.
527 Each "url" MUST be an absolute URI reference according to [RFC3986]
528 that can be immediately used to fetch the certificate(s).
530 When X.509 certificates are used, there are two possibilities:
532 - If CertificateURL.type is "individual_certs", each URL refers to a
533 single DER-encoded X.509v3 certificate, with the URL for the
534 client's certificate first.
536 - If CertificateURL.type is "pkipath", the list contains a single
537 URL referring to a DER-encoded certificate chain, using the type
538 PkiPath described in Section 10.1.
540 When any other certificate format is used, the specification that
541 describes use of that format in TLS should define the encoding format
542 of certificates or certificate chains, and any constraint on their
545 The "padding" byte MUST be 0x01. It is present to make the structure
546 backwards compatible.
548 The hash corresponding to each URL is the SHA-1 hash of the
549 certificate or certificate chain (in the case of X.509 certificates,
550 the DER-encoded certificate or the DER-encoded PkiPath).
552 Note that when a list of URLs for X.509 certificates is used, the
553 ordering of URLs is the same as that used in the TLS Certificate
554 message (see [RFC5246], Section 7.4.2), but opposite to the order in
555 which certificates are encoded in PkiPath. In either case, the self-
556 signed root certificate MAY be omitted from the chain, under the
557 assumption that the server must already possess it in order to
562Eastlake Standards Track [Page 10]
564RFC 6066 TLS Extension Definitions January 2011
567 Servers receiving "CertificateURL" SHALL attempt to retrieve the
568 client's certificate chain from the URLs and then process the
569 certificate chain as usual. A cached copy of the content of any URL
570 in the chain MAY be used, provided that the SHA-1 hash matches the
571 hash of the cached copy.
573 Servers that support this extension MUST support the 'http' URI
574 scheme for certificate URLs and MAY support other schemes. Use of
575 other schemes than 'http', 'https', or 'ftp' may create unexpected
578 If the protocol used is HTTP, then the HTTP server can be configured
579 to use the Cache-Control and Expires directives described in
580 [RFC2616] to specify whether and for how long certificates or
581 certificate chains should be cached.
583 The TLS server MUST NOT follow HTTP redirects when retrieving the
584 certificates or certificate chain. The URLs used in this extension
585 MUST NOT be chosen to depend on such redirects.
587 If the protocol used to retrieve certificates or certificate chains
588 returns a MIME-formatted response (as HTTP does), then the following
589 MIME Content-Types SHALL be used: when a single X.509v3 certificate
590 is returned, the Content-Type is "application/pkix-cert" [RFC2585],
591 and when a chain of X.509v3 certificates is returned, the Content-
592 Type is "application/pkix-pkipath" (Section 10.1).
594 The server MUST check that the SHA-1 hash of the contents of the
595 object retrieved from that URL (after decoding any MIME Content-
596 Transfer-Encoding) matches the given hash. If any retrieved object
597 does not have the correct SHA-1 hash, the server MUST abort the
598 handshake with a bad_certificate_hash_value(114) alert. This alert
601 Clients may choose to send either "Certificate" or "CertificateURL"
602 after successfully negotiating the option to send certificate URLs.
603 The option to send a certificate is included to provide flexibility
604 to clients possessing multiple certificates.
606 If a server is unable to obtain certificates in a given
607 CertificateURL, it MUST send a fatal certificate_unobtainable(111)
608 alert if it requires the certificates to complete the handshake. If
609 the server does not require the certificates, then the server
610 continues the handshake. The server MAY send a warning-level alert
611 in this case. Clients receiving such an alert SHOULD log the alert
612 and continue with the handshake if possible.
618Eastlake Standards Track [Page 11]
620RFC 6066 TLS Extension Definitions January 2011
6236. Trusted CA Indication
625 Constrained clients that, due to memory limitations, possess only a
626 small number of CA root keys may wish to indicate to servers which
627 root keys they possess, in order to avoid repeated handshake
630 In order to indicate which CA root keys they possess, clients MAY
631 include an extension of type "trusted_ca_keys" in the (extended)
632 client hello. The "extension_data" field of this extension SHALL
633 contain "TrustedAuthorities" where:
636 TrustedAuthority trusted_authorities_list<0..2^16-1>;
637 } TrustedAuthorities;
640 IdentifierType identifier_type;
641 select (identifier_type) {
642 case pre_agreed: struct {};
643 case key_sha1_hash: SHA1Hash;
644 case x509_name: DistinguishedName;
645 case cert_sha1_hash: SHA1Hash;
650 pre_agreed(0), key_sha1_hash(1), x509_name(2),
651 cert_sha1_hash(3), (255)
654 opaque DistinguishedName<1..2^16-1>;
656 Here, "TrustedAuthorities" provides a list of CA root key identifiers
657 that the client possesses. Each CA root key is identified via
660 - "pre_agreed": no CA root key identity supplied.
662 - "key_sha1_hash": contains the SHA-1 hash of the CA root key. For
663 Digital Signature Algorithm (DSA) and Elliptic Curve Digital
664 Signature Algorithm (ECDSA) keys, this is the hash of the
665 "subjectPublicKey" value. For RSA keys, the hash is of the big-
666 endian byte string representation of the modulus without any
667 initial zero-valued bytes. (This copies the key hash formats
668 deployed in other environments.)
674Eastlake Standards Track [Page 12]
676RFC 6066 TLS Extension Definitions January 2011
679 - "x509_name": contains the DER-encoded X.509 DistinguishedName of
682 - "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded
683 Certificate containing the CA root key.
685 Note that clients may include none, some, or all of the CA root keys
686 they possess in this extension.
688 Note also that it is possible that a key hash or a Distinguished Name
689 alone may not uniquely identify a certificate issuer (for example, if
690 a particular CA has multiple key pairs). However, here we assume
691 this is the case following the use of Distinguished Names to identify
692 certificate issuers in TLS.
694 The option to include no CA root keys is included to allow the client
695 to indicate possession of some pre-defined set of CA root keys.
697 Servers that receive a client hello containing the "trusted_ca_keys"
698 extension MAY use the information contained in the extension to guide
699 their selection of an appropriate certificate chain to return to the
700 client. In this event, the server SHALL include an extension of type
701 "trusted_ca_keys" in the (extended) server hello. The
702 "extension_data" field of this extension SHALL be empty.
706 Currently defined TLS cipher suites use the MAC construction HMAC
707 [RFC2104] to authenticate record-layer communications. In TLS, the
708 entire output of the hash function is used as the MAC tag. However,
709 it may be desirable in constrained environments to save bandwidth by
710 truncating the output of the hash function to 80 bits when forming
713 In order to negotiate the use of 80-bit truncated HMAC, clients MAY
714 include an extension of type "truncated_hmac" in the extended client
715 hello. The "extension_data" field of this extension SHALL be empty.
717 Servers that receive an extended hello containing a "truncated_hmac"
718 extension MAY agree to use a truncated HMAC by including an extension
719 of type "truncated_hmac", with empty "extension_data", in the
720 extended server hello.
722 Note that if new cipher suites are added that do not use HMAC, and
723 the session negotiates one of these cipher suites, this extension
724 will have no effect. It is strongly recommended that any new cipher
725 suites using other MACs consider the MAC size an integral part of the
730Eastlake Standards Track [Page 13]
732RFC 6066 TLS Extension Definitions January 2011
735 cipher suite definition, taking into account both security and
736 bandwidth considerations.
738 If HMAC truncation has been successfully negotiated during a TLS
739 handshake, and the negotiated cipher suite uses HMAC, both the client
740 and the server pass this fact to the TLS record layer along with the
741 other negotiated security parameters. Subsequently during the
742 session, clients and servers MUST use truncated HMACs, calculated as
743 specified in [RFC2104]. That is, SecurityParameters.mac_length is 10
744 bytes, and only the first 10 bytes of the HMAC output are transmitted
745 and checked. Note that this extension does not affect the
746 calculation of the pseudo-random function (PRF) as part of
747 handshaking or key derivation.
749 The negotiated HMAC truncation size applies for the duration of the
750 session including session resumptions.
7528. Certificate Status Request
754 Constrained clients may wish to use a certificate-status protocol
755 such as OCSP [RFC2560] to check the validity of server certificates,
756 in order to avoid transmission of CRLs and therefore save bandwidth
757 on constrained networks. This extension allows for such information
758 to be sent in the TLS handshake, saving roundtrips and resources.
760 In order to indicate their desire to receive certificate status
761 information, clients MAY include an extension of type
762 "status_request" in the (extended) client hello. The
763 "extension_data" field of this extension SHALL contain
764 "CertificateStatusRequest" where:
767 CertificateStatusType status_type;
768 select (status_type) {
769 case ocsp: OCSPStatusRequest;
771 } CertificateStatusRequest;
773 enum { ocsp(1), (255) } CertificateStatusType;
776 ResponderID responder_id_list<0..2^16-1>;
777 Extensions request_extensions;
780 opaque ResponderID<1..2^16-1>;
781 opaque Extensions<0..2^16-1>;
786Eastlake Standards Track [Page 14]
788RFC 6066 TLS Extension Definitions January 2011
791 In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
792 responders that the client trusts. A zero-length "responder_id_list"
793 sequence has the special meaning that the responders are implicitly
794 known to the server, e.g., by prior arrangement. "Extensions" is a
795 DER encoding of OCSP request extensions.
797 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
798 defined in [RFC2560]. "Extensions" is imported from [RFC5280]. A
799 zero-length "request_extensions" value means that there are no
800 extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not
801 valid for the "Extensions" type).
803 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is
804 unclear about its encoding; for clarification, the nonce MUST be a
805 DER-encoded OCTET STRING, which is encapsulated as another OCTET
806 STRING (note that implementations based on an existing OCSP client
807 will need to be checked for conformance to this requirement).
809 Servers that receive a client hello containing the "status_request"
810 extension MAY return a suitable certificate status response to the
811 client along with their certificate. If OCSP is requested, they
812 SHOULD use the information contained in the extension when selecting
813 an OCSP responder and SHOULD include request_extensions in the OCSP
816 Servers return a certificate response along with their certificate by
817 sending a "CertificateStatus" message immediately after the
818 "Certificate" message (and before any "ServerKeyExchange" or
819 "CertificateRequest" messages). If a server returns a
820 "CertificateStatus" message, then the server MUST have included an
821 extension of type "status_request" with empty "extension_data" in the
822 extended server hello. The "CertificateStatus" message is conveyed
823 using the handshake message type "certificate_status" as follows (see
827 CertificateStatusType status_type;
828 select (status_type) {
829 case ocsp: OCSPResponse;
833 opaque OCSPResponse<1..2^24-1>;
835 An "ocsp_response" contains a complete, DER-encoded OCSP response
836 (using the ASN.1 type OCSPResponse defined in [RFC2560]). Only one
837 OCSP response may be sent.
842Eastlake Standards Track [Page 15]
844RFC 6066 TLS Extension Definitions January 2011
847 Note that a server MAY also choose not to send a "CertificateStatus"
848 message, even if has received a "status_request" extension in the
849 client hello message and has sent a "status_request" extension in the
850 server hello message.
852 Note in addition that a server MUST NOT send the "CertificateStatus"
853 message unless it received a "status_request" extension in the client
854 hello message and sent a "status_request" extension in the server
857 Clients requesting an OCSP response and receiving an OCSP response in
858 a "CertificateStatus" message MUST check the OCSP response and abort
859 the handshake if the response is not satisfactory with
860 bad_certificate_status_response(113) alert. This alert is always
865 Four new error alerts are defined for use with the TLS extensions
866 defined in this document. To avoid "breaking" existing clients and
867 servers, these alerts MUST NOT be sent unless the sending party has
868 received an extended hello message from the party they are
869 communicating with. These error alerts are conveyed using the
870 following syntax. The new alerts are the last four, as indicated by
871 the comments on the same line as the error alert number.
875 unexpected_message(10),
877 decryption_failed(21),
879 decompression_failure(30),
880 handshake_failure(40),
881 /* 41 is not defined, for historical reasons */
883 unsupported_certificate(43),
884 certificate_revoked(44),
885 certificate_expired(45),
886 certificate_unknown(46),
887 illegal_parameter(47),
892 export_restriction(60),
893 protocol_version(70),
894 insufficient_security(71),
898Eastlake Standards Track [Page 16]
900RFC 6066 TLS Extension Definitions January 2011
905 no_renegotiation(100),
906 unsupported_extension(110),
907 certificate_unobtainable(111), /* new */
908 unrecognized_name(112), /* new */
909 bad_certificate_status_response(113), /* new */
910 bad_certificate_hash_value(114), /* new */
914 "certificate_unobtainable" is described in Section 5.
915 "unrecognized_name" is described in Section 3.
916 "bad_certificate_status_response" is described in Section 8.
917 "bad_certificate_hash_value" is described in Section 5.
91910. IANA Considerations
921 IANA Considerations for TLS extensions and the creation of a registry
922 are covered in Section 12 of [RFC5246] except for the registration of
923 MIME type application/pkix-pkipath, which appears below.
925 The IANA TLS extensions and MIME type application/pkix-pkipath
926 registry entries that reference RFC 4366 have been updated to
927 reference this document.
92910.1. pkipath MIME Type Registration
931 MIME media type name: application
932 MIME subtype name: pkix-pkipath
933 Required parameters: none
935 Optional parameters: version (default value is "1")
937 Encoding considerations:
938 Binary; this MIME type is a DER encoding of the ASN.1 type
939 PkiPath, defined as follows:
940 PkiPath ::= SEQUENCE OF Certificate
941 PkiPath is used to represent a certification path. Within the
942 sequence, the order of certificates is such that the subject of
943 the first certificate is the issuer of the second certificate,
945 This is identical to the definition published in [X509-4th-TC1];
946 note that it is different from that in [X509-4th].
948 All Certificates MUST conform to [RFC5280]. (This should be
949 interpreted as a requirement to encode only PKIX-conformant
950 certificates using this type. It does not necessarily require
954Eastlake Standards Track [Page 17]
956RFC 6066 TLS Extension Definitions January 2011
959 that all certificates that are not strictly PKIX-conformant must
960 be rejected by relying parties, although the security consequences
961 of accepting any such certificates should be considered
964 DER (as opposed to BER) encoding MUST be used. If this type is
965 sent over a 7-bit transport, base64 encoding SHOULD be used.
967 Security considerations:
968 The security considerations of [X509-4th] and [RFC5280] (or any
969 updates to them) apply, as well as those of any protocol that uses
970 this type (e.g., TLS).
972 Note that this type only specifies a certificate chain that can be
973 assessed for validity according to the relying party's existing
974 configuration of trusted CAs; it is not intended to be used to
975 specify any change to that configuration.
977 Interoperability considerations:
978 No specific interoperability problems are known with this type,
979 but for recommendations relating to X.509 certificates in general,
982 Published specification: This document and [RFC5280].
984 Applications that use this media type:
985 TLS. It may also be used by other protocols or for general
986 interchange of PKIX certificate chains.
988 Additional information:
989 Magic number(s): DER-encoded ASN.1 can be easily recognized.
990 Further parsing is required to distinguish it from other ASN.1
992 File extension(s): .pkipath
993 Macintosh File Type Code(s): not specified
995 Person & email address to contact for further information:
996 Magnus Nystrom <mnystrom@microsoft.com>
998 Intended usage: COMMON
1000 Change controller: IESG <iesg@ietf.org>
1010Eastlake Standards Track [Page 18]
1012RFC 6066 TLS Extension Definitions January 2011
101510.2. Reference for TLS Alerts, TLS HandshakeTypes, and ExtensionTypes
1017 The following values in the TLS Alert Registry have been updated to
1018 reference this document:
1020 111 certificate_unobtainable
1021 112 unrecognized_name
1022 113 bad_certificate_status_response
1023 114 bad_certificate_hash_value
1025 The following values in the TLS HandshakeType Registry have been
1026 updated to reference this document:
1029 22 certificate_status
1031 The following ExtensionType values have been updated to reference
1035 1 max_fragment_length
1036 2 client_certificate_url
104111. Security Considerations
1043 General security considerations for TLS extensions are covered in
1044 [RFC5246]. Security Considerations for particular extensions
1045 specified in this document are given below.
1047 In general, implementers should continue to monitor the state of the
1048 art and address any weaknesses identified.
105011.1. Security Considerations for server_name
1052 If a single server hosts several domains, then clearly it is
1053 necessary for the owners of each domain to ensure that this satisfies
1054 their security needs. Apart from this, server_name does not appear
1055 to introduce significant security issues.
1057 Since it is possible for a client to present a different server_name
1058 in the application protocol, application server implementations that
1059 rely upon these names being the same MUST check to make sure the
1060 client did not present a different name in the application protocol.
1066Eastlake Standards Track [Page 19]
1068RFC 6066 TLS Extension Definitions January 2011
1071 Implementations MUST ensure that a buffer overflow does not occur,
1072 whatever the values of the length fields in server_name.
107411.2. Security Considerations for max_fragment_length
1076 The maximum fragment length takes effect immediately, including for
1077 handshake messages. However, that does not introduce any security
1078 complications that are not already present in TLS, since TLS requires
1079 implementations to be able to handle fragmented handshake messages.
1081 Note that, as described in Section 4, once a non-null cipher suite
1082 has been activated, the effective maximum fragment length depends on
1083 the cipher suite and compression method, as well as on the negotiated
1084 max_fragment_length. This must be taken into account when sizing
1085 buffers and checking for buffer overflow.
108711.3. Security Considerations for client_certificate_url
1089 Support for client_certificate_url involves the server's acting as a
1090 client in another URI-scheme-dependent protocol. The server
1091 therefore becomes subject to many of the same security concerns that
1092 clients of the URI scheme are subject to, with the added concern that
1093 the client can attempt to prompt the server to connect to some
1094 (possibly weird-looking) URL.
1096 In general, this issue means that an attacker might use the server to
1097 indirectly attack another host that is vulnerable to some security
1098 flaw. It also introduces the possibility of denial-of-service
1099 attacks in which an attacker makes many connections to the server,
1100 each of which results in the server's attempting a connection to the
1101 target of the attack.
1103 Note that the server may be behind a firewall or otherwise able to
1104 access hosts that would not be directly accessible from the public
1105 Internet. This could exacerbate the potential security and denial-
1106 of-service problems described above, as well as allow the existence
1107 of internal hosts to be confirmed when they would otherwise be
1110 The detailed security concerns involved will depend on the URI
1111 schemes supported by the server. In the case of HTTP, the concerns
1112 are similar to those that apply to a publicly accessible HTTP proxy
1113 server. In the case of HTTPS, loops and deadlocks may be created,
1114 and this should be addressed. In the case of FTP, attacks arise that
1115 are similar to FTP bounce attacks.
1122Eastlake Standards Track [Page 20]
1124RFC 6066 TLS Extension Definitions January 2011
1127 As a result of this issue, it is RECOMMENDED that the
1128 client_certificate_url extension should have to be specifically
1129 enabled by a server administrator, rather than be enabled by default.
1130 It is also RECOMMENDED that URI schemes be enabled by the
1131 administrator individually, and only a minimal set of schemes be
1132 enabled. Unusual protocols that offer limited security or whose
1133 security is not well understood SHOULD be avoided.
1135 As discussed in [RFC3986], URLs that specify ports other than the
1136 default may cause problems, as may very long URLs (which are more
1137 likely to be useful in exploiting buffer overflow bugs).
1139 This extension continues to use SHA-1 (as in RFC 4366) and does not
1140 provide algorithm agility. The property required of SHA-1 in this
1141 case is second pre-image resistance, not collision resistance.
1142 Furthermore, even if second pre-image attacks against SHA-1 are found
1143 in the future, an attack against client_certificate_url would require
1144 a second pre-image that is accepted as a valid certificate by the
1145 server and contains the same public key.
1147 Also note that HTTP caching proxies are common on the Internet, and
1148 some proxies do not check for the latest version of an object
1149 correctly. If a request using HTTP (or another caching protocol)
1150 goes through a misconfigured or otherwise broken proxy, the proxy may
1151 return an out-of-date response.
115311.4. Security Considerations for trusted_ca_keys
1155 Potentially, the CA root keys a client possesses could be regarded as
1156 confidential information. As a result, the CA root key indication
1157 extension should be used with care.
1159 The use of the SHA-1 certificate hash alternative ensures that each
1160 certificate is specified unambiguously. This context does not
1161 require a cryptographic hash function, so the use of SHA-1 is
1162 considered acceptable, and no algorithm agility is provided.
116411.5. Security Considerations for truncated_hmac
1166 It is possible that truncated MACs are weaker than "un-truncated"
1167 MACs. However, no significant weaknesses are currently known or
1168 expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
1170 Note that the output length of a MAC need not be as long as the
1171 length of a symmetric cipher key, since forging of MAC values cannot
1172 be done off-line: in TLS, a single failed MAC guess will cause the
1173 immediate termination of the TLS session.
1178Eastlake Standards Track [Page 21]
1180RFC 6066 TLS Extension Definitions January 2011
1183 Since the MAC algorithm only takes effect after all handshake
1184 messages that affect extension parameters have been authenticated by
1185 the hashes in the Finished messages, it is not possible for an active
1186 attacker to force negotiation of the truncated HMAC extension where
1187 it would not otherwise be used (to the extent that the handshake
1188 authentication is secure). Therefore, in the event that any security
1189 problems were found with truncated HMAC in the future, if either the
1190 client or the server for a given session were updated to take the
1191 problem into account, it would be able to veto use of this extension.
119311.6. Security Considerations for status_request
1195 If a client requests an OCSP response, it must take into account that
1196 an attacker's server using a compromised key could (and probably
1197 would) pretend not to support the extension. In this case, a client
1198 that requires OCSP validation of certificates SHOULD either contact
1199 the OCSP server directly or abort the handshake.
1201 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
1202 improve security against attacks that attempt to replay OCSP
1203 responses; see Section 4.4.1 of [RFC2560] for further details.
120512. Normative References
1207 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
1208 Keyed-Hashing for Message Authentication", RFC 2104,
1211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1212 Requirement Levels", BCP 14, RFC 2119, March 1997.
1214 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
1215 C. Adams, "X.509 Internet Public Key Infrastructure
1216 Online Certificate Status Protocol - OCSP", RFC 2560,
1219 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
1220 Infrastructure Operational Protocols: FTP and HTTP",
1223 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1224 Masinter, L., Leach, P., and T. Berners-Lee,
1225 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
1228 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
1229 "Uniform Resource Identifier (URI): Generic Syntax",
1230 STD 66, RFC 3986, January 2005.
1234Eastlake Standards Track [Page 22]
1236RFC 6066 TLS Extension Definitions January 2011
1239 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
1240 Security (TLS) Protocol Version 1.2", RFC 5246, August
1243 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1244 Housley, R., and W. Polk, "Internet X.509 Public Key
1245 Infrastructure Certificate and Certificate Revocation
1246 List (CRL) Profile", RFC 5280, May 2008.
1248 [RFC5890] Klensin, J., "Internationalized Domain Names for
1249 Applications (IDNA): Definitions and Document
1250 Framework", RFC 5890, August 2010.
125213. Informative References
1254 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
1255 Suites to Transport Layer Security (TLS)", RFC 2712,
1258 [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC
1259 9594-8:2001, "Information Systems - Open Systems
1260 Interconnection - The Directory: Public key and
1261 attribute certificate frameworks".
1263 [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
1264 ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum
1265 1 to ISO/IEC 9594:8:2001.
1290Eastlake Standards Track [Page 23]
1292RFC 6066 TLS Extension Definitions January 2011
1295Appendix A. Changes from RFC 4366
1297 The significant changes between RFC 4366 and this document are
1300 RFC 4366 described both general extension mechanisms (for the TLS
1301 handshake and client and server hellos) as well as specific
1302 extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The
1303 client and server hello extension mechanisms have been moved into RFC
1304 5246, TLS 1.2, so this document, which is associated with RFC 5246,
1305 includes only the handshake extension mechanisms and the specific
1306 extensions from RFC 4366. RFC 5246 also specifies the unknown
1307 extension error and new extension specification considerations, so
1308 that material has been removed from this document.
1310 The Server Name extension now specifies only ASCII representation,
1311 eliminating UTF-8. It is provided that the ServerNameList can
1312 contain more than only one name of any particular name_type. If a
1313 server name is provided but not recognized, the server should either
1314 continue the handshake without an error or send a fatal error.
1315 Sending a warning-level message is not recommended because client
1316 behavior will be unpredictable. Provision was added for the user
1317 using the server_name extension in deciding whether or not to resume
1318 a session. Furthermore, this extension should be the same in a
1319 session resumption request as it was in the full handshake that
1320 established the session. Such a resumption request must not be
1321 accepted if the server_name extension is different, but instead a
1322 full handshake must be done to possibly establish a new session.
1324 The Client Certificate URLs extension has been changed to make the
1325 presence of a hash mandatory.
1327 For the case of DTLS, the requirement to report an overflow of the
1328 negotiated maximum fragment length is made conditional on passing
1331 TLS servers are now prohibited from following HTTP redirects when
1332 retrieving certificates.
1334 The material was also re-organized in minor ways. For example,
1335 information as to which errors are fatal is moved from the "Error
1336 Alerts" section to the individual extension specifications.
1346Eastlake Standards Track [Page 24]
1348RFC 6066 TLS Extension Definitions January 2011
1351Appendix B. Acknowledgements
1353 This document is based on material from RFC 4366 for which the
1354 authors were S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
1355 and T. Wright. Other contributors include Joseph Salowey, Alexey
1356 Melnikov, Peter Saint-Andre, and Adrian Farrel.
1363 Milford, MA 01757 USA
1365 Phone: +1-508-333-2270
1366 EMail: d3e3e3@gmail.com
1402Eastlake Standards Track [Page 25]