--- /dev/null
+\r
+TLS Working Group Donald Eastlake 3rd\r
+INTERNET-DRAFT Motorola Laboratories\r
+Obsoletes: RFC 4366\r
+Intended status: Proposed Standard\r
+Expires: August 2008 February 20, 2008\r
+\r
+\r
+ Transport Layer Security (TLS) Extensions: Extension Definitions\r
+\r
+ <draft-ietf-tls-rfc4366-bis-02.txt>\r
+\r
+\r
+Status of This Document\r
+\r
+ By submitting this Internet-Draft, each author represents that any\r
+ applicable patent or other IPR claims of which he or she is aware\r
+ have been or will be disclosed, and any of which he or she becomes\r
+ aware will be disclosed, in accordance with Section 6 of BCP 79.\r
+\r
+ Distribution of this document is unlimited. Comments should be sent\r
+ to the TLS working group mailing list <tls@ietf.org>.\r
+\r
+ Internet-Drafts are working documents of the Internet Engineering\r
+ Task Force (IETF), its areas, and its working groups. Note that\r
+ other groups may also distribute working documents as Internet-\r
+ Drafts.\r
+\r
+ Internet-Drafts are draft documents valid for a maximum of six months\r
+ and may be updated, replaced, or obsoleted by other documents at any\r
+ time. It is inappropriate to use Internet-Drafts as reference\r
+ material or to cite them other than as "work in progress."\r
+\r
+ The list of current Internet-Drafts can be accessed at\r
+ http://www.ietf.org/1id-abstracts.html\r
+\r
+ The list of Internet-Draft Shadow Directories can be accessed at\r
+ http://www.ietf.org/shadow.html\r
+\r
+\r
+Abstract\r
+\r
+ This document provides documentation for existing specific TLS\r
+ extensions. It is a companion document for the TLS 1.2 specification,\r
+ draft-ietf-tls-rfc4346-bis-07.txt.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 1]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+Acknowledgements\r
+\r
+ This draft is based on material from RFC 4366 for which the authors\r
+ were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T.\r
+ Wright.\r
+\r
+\r
+\r
+Table of Contents\r
+\r
+ Status of This Document....................................1\r
+ Abstract...................................................1\r
+\r
+ Acknowledgements...........................................2\r
+ Table of Contents..........................................2\r
+\r
+ 1. Introduction............................................3\r
+ 1.1 Specific Extensions Covered............................3\r
+ 1.2 Conventions Used in This Document......................4\r
+\r
+ 2. Extensions to the Handshake Protocol....................5\r
+\r
+ 3. Server Name Indication..................................6\r
+ 4. Maximum Fragment Length Negotiation.....................7\r
+ 5. Client Certificate URLs.................................8\r
+ 6. Trusted CA Indication..................................11\r
+ 7. Truncated HMAC.........................................12\r
+ 8. Certificate Status Request.............................13\r
+\r
+ 9. Error Alerts...........................................16\r
+\r
+ 10. IANA Considerations...................................17\r
+ 11. Security Considerations...............................17\r
+ 11.1 Security Considerations for server_name..............17\r
+ 11.2 Security Considerations for max_fragment_length......17\r
+ 11.3 Security Considerations for client_certificate_url...18\r
+ 11.4 Security Considerations for trusted_ca_keys..........19\r
+ 11.5 Security Considerations for truncated_hmac...........19\r
+ 11.6 Security Considerations for status_request...........20\r
+\r
+ 12. Normative References..................................21\r
+ 13. Informative References................................21\r
+\r
+ Copyright, Disclaimer, and Additional IPR Provisions......22\r
+\r
+ Author's Address..........................................23\r
+ Expiration and File Name..................................23\r
+\r
+\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 2]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+1. Introduction\r
+\r
+ The TLS (Transport Layer Security) Protocol Version 1.2 is specified\r
+ in [RFCTLS]. That specification includes the framework for extensions\r
+ to TLS, considerations in designing such extensions (see Section\r
+ 7.4.1.4 of [RFCTLS]), and IANA Considerations for the allocation of\r
+ new extension code points; however, it does not specify any\r
+ particular extensions other than Signature Algorithms (see Section\r
+ 7.4.1.4.1 of [RFCTLS]).\r
+\r
+ This document provides the specifications for existing TLS\r
+ extensions. It is, for the most part, the adaptation and editing of\r
+ material from [RFC4366], which covered TLS extensions for TLS 1.0\r
+ [RFC2246] and TLS 1.1 [RFC4346].\r
+\r
+\r
+\r
+1.1 Specific Extensions Covered\r
+\r
+ The extensions described here focus on extending the functionality\r
+ provided by the TLS protocol message formats. Other issues, such as\r
+ the addition of new cipher suites, are deferred.\r
+\r
+ Specifically, the extensions described in this document:\r
+\r
+ - Allow TLS clients to provide to the TLS server the name of the\r
+ server they are contacting. This functionality is desirable in\r
+ order to facilitate secure connections to servers that host\r
+ multiple 'virtual' servers at a single underlying network address.\r
+\r
+ - Allow TLS clients and servers to negotiate the maximum fragment\r
+ length to be sent. This functionality is desirable as a result of\r
+ memory constraints among some clients, and bandwidth constraints\r
+ among some access networks.\r
+\r
+ - Allow TLS clients and servers to negotiate the use of client\r
+ certificate URLs. This functionality is desirable in order to\r
+ conserve memory on constrained clients.\r
+\r
+ - Allow TLS clients to indicate to TLS servers which CA root keys\r
+ they possess. This functionality is desirable in order to prevent\r
+ multiple handshake failures involving TLS clients that are only\r
+ able to store a small number of CA root keys due to memory\r
+ limitations.\r
+\r
+ - Allow TLS clients and servers to negotiate the use of truncated\r
+ MACs. This functionality is desirable in order to conserve\r
+ bandwidth in constrained access networks.\r
+\r
+ - Allow TLS clients and servers to negotiate that the server sends\r
+\r
+\r
+Donald Eastlake 3rd [Page 3]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ the client certificate status information (e.g., an Online\r
+ Certificate Status Protocol (OCSP) [RFC2560] response) during a\r
+ TLS handshake. This functionality is desirable in order to avoid\r
+ sending a Certificate Revocation List (CRL) over a constrained\r
+ access network and therefore save bandwidth.\r
+\r
+ The extensions described in this document may be used by TLS clients\r
+ and servers. The extensions are designed to be backwards compatible,\r
+ meaning that TLS clients that support the extensions can talk to TLS\r
+ servers that do not support the extensions, and vice versa.\r
+\r
+\r
+\r
+1.2 Conventions Used in This Document\r
+\r
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
+ document are to be interpreted as described in [RFC2119].\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 4]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+2. Extensions to the Handshake Protocol\r
+\r
+ This document specifies the use of two new handshake messages,\r
+ "CertificateURL" and "CertificateStatus". These messages are\r
+ described in Section 5 and Section 8, respectively. The new\r
+ handshake message structure therefore becomes:\r
+\r
+ enum {\r
+ hello_request(0), client_hello(1), server_hello(2),\r
+ certificate(11), server_key_exchange (12),\r
+ certificate_request(13), server_hello_done(14),\r
+ certificate_verify(15), client_key_exchange(16),\r
+ finished(20), certificate_url(21), certificate_status(22),\r
+ (255)\r
+ } HandshakeType;\r
+\r
+ struct {\r
+ HandshakeType msg_type; /* handshake type */\r
+ uint24 length; /* bytes in message */\r
+ select (HandshakeType) {\r
+ case hello_request: HelloRequest;\r
+ case client_hello: ClientHello;\r
+ case server_hello: ServerHello;\r
+ case certificate: Certificate;\r
+ case server_key_exchange: ServerKeyExchange;\r
+ case certificate_request: CertificateRequest;\r
+ case server_hello_done: ServerHelloDone;\r
+ case certificate_verify: CertificateVerify;\r
+ case client_key_exchange: ClientKeyExchange;\r
+ case finished: Finished;\r
+ case certificate_url: CertificateURL;\r
+ case certificate_status: CertificateStatus;\r
+ } body;\r
+ } Handshake;\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 5]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+3. Server Name Indication\r
+\r
+ TLS does not provide a mechanism for a client to tell a server the\r
+ name of the server it is contacting. It may be desirable for clients\r
+ to provide this information to facilitate secure connections to\r
+ servers that host multiple 'virtual' servers at a single underlying\r
+ network address.\r
+\r
+ In order to provide the server name, clients MAY include an extension\r
+ of type "server_name" in the (extended) client hello. The\r
+ "extension_data" field of this extension SHALL contain\r
+ "ServerNameList" where:\r
+\r
+ struct {\r
+ NameType name_type;\r
+ select (name_type) {\r
+ case host_name: HostName;\r
+ } name;\r
+ } ServerName;\r
+\r
+ enum {\r
+ host_name(0), (255)\r
+ } NameType;\r
+\r
+ opaque HostName<1..2^16-1>;\r
+\r
+ struct {\r
+ ServerName server_name_list<1..2^16-1>\r
+ } ServerNameList;\r
+\r
+ If the server understood the client hello extension but does not\r
+ recognize any of the server names, it SHOULD send an\r
+ unrecognized_name(112) alert (which MAY be fatal).\r
+\r
+ Currently, the only server names supported are DNS hostnames;\r
+ however, this does not imply any dependency of TLS on DNS, and other\r
+ name types may be added in the future (by an RFC that updates this\r
+ document). TLS MAY treat provided server names as opaque data and\r
+ pass the names and types to the application.\r
+\r
+ "HostName" contains the fully qualified DNS hostname of the server,\r
+ as understood by the client. The hostname is represented as a byte\r
+ string using ASCII encoding without a trailing dot.\r
+\r
+ Literal IPv4 and IPv6 addresses are not permitted in "HostName".\r
+\r
+ It is RECOMMENDED that clients include an extension of type\r
+ "server_name" in the client hello whenever they locate a server by a\r
+ supported name type.\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 6]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ A server that receives a client hello containing the "server_name"\r
+ extension MAY use the information contained in the extension to guide\r
+ its selection of an appropriate certificate to return to the client,\r
+ and/or other aspects of security policy. In this event, the server\r
+ SHALL include an extension of type "server_name" in the (extended)\r
+ server hello. The "extension_data" field of this extension SHALL be\r
+ empty.\r
+\r
+ If the server understood the client hello extension but does not\r
+ recognize the server name, it SHOULD send an "unrecognized_name"\r
+ alert (which MAY be fatal).\r
+\r
+ If an application negotiates a server name using an application\r
+ protocol and then upgrades to TLS, and if a server_name extension is\r
+ sent, then the extension SHOULD contain the same name that was\r
+ negotiated in the application protocol. If the server_name is\r
+ established in the TLS session handshake, the client SHOULD NOT\r
+ attempt to request a different server name at the application layer.\r
+\r
+\r
+\r
+4. Maximum Fragment Length Negotiation\r
+\r
+ Without this extension, TLS specifies a fixed maximum plaintext\r
+ fragment length of 2^14 bytes. It may be desirable for constrained\r
+ clients to negotiate a smaller maximum fragment length due to memory\r
+ limitations or bandwidth limitations.\r
+\r
+ In order to negotiate smaller maximum fragment lengths, clients MAY\r
+ include an extension of type "max_fragment_length" in the (extended)\r
+ client hello. The "extension_data" field of this extension SHALL\r
+ contain:\r
+\r
+ enum{\r
+ 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)\r
+ } MaxFragmentLength;\r
+\r
+ whose value is the desired maximum fragment length. The allowed\r
+ values for this field are: 2^9, 2^10, 2^11, and 2^12.\r
+\r
+ Servers that receive an extended client hello containing a\r
+ "max_fragment_length" extension MAY accept the requested maximum\r
+ fragment length by including an extension of type\r
+ "max_fragment_length" in the (extended) server hello. The\r
+ "extension_data" field of this extension SHALL contain a\r
+ "MaxFragmentLength" whose value is the same as the requested maximum\r
+ fragment length.\r
+\r
+ If a server receives a maximum fragment length negotiation request\r
+ for a value other than the allowed values, it MUST abort the\r
+\r
+\r
+Donald Eastlake 3rd [Page 7]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ handshake with an "illegal_parameter" alert. Similarly, if a client\r
+ receives a maximum fragment length negotiation response that differs\r
+ from the length it requested, it MUST also abort the handshake with\r
+ an "illegal_parameter" alert.\r
+\r
+ Once a maximum fragment length other than 2^14 has been successfully\r
+ negotiated, the client and server MUST immediately begin fragmenting\r
+ messages (including handshake messages), to ensure that no fragment\r
+ larger than the negotiated length is sent. Note that TLS already\r
+ requires clients and servers to support fragmentation of handshake\r
+ messages.\r
+\r
+ The negotiated length applies for the duration of the session\r
+ including session resumptions.\r
+\r
+ The negotiated length limits the input that the record layer may\r
+ process without fragmentation (that is, the maximum value of\r
+ TLSPlaintext.length; see [RFCTLS], Section 6.2.1). Note that the\r
+ output of the record layer may be larger. For example, if the\r
+ negotiated length is 2^9=512, then for currently defined cipher\r
+ suites (those defined in [RFCTLS], [RFC2712], and [RFC3268]), and\r
+ when null compression is used, the record layer output can be at most\r
+ 805 bytes: 5 bytes of headers, 512 bytes of application data, 256\r
+ bytes of padding, and 32 bytes of MAC. This means that in this event\r
+ a TLS record layer peer receiving a TLS record layer message larger\r
+ than 805 bytes may discard the message and send a "record_overflow"\r
+ alert, without decrypting the message.\r
+\r
+\r
+\r
+5. Client Certificate URLs\r
+\r
+ Without this extension, TLS specifies that when client authentication\r
+ is performed, client certificates are sent by clients to servers\r
+ during the TLS handshake. It may be desirable for constrained clients\r
+ to send certificate URLs in place of certificates, so that they do\r
+ not need to store their certificates and can therefore save memory.\r
+\r
+ In order to negotiate sending certificate URLs to a server, clients\r
+ MAY include an extension of type "client_certificate_url" in the\r
+ (extended) client hello. The "extension_data" field of this extension\r
+ SHALL be empty.\r
+\r
+ (Note that it is necessary to negotiate use of client certificate\r
+ URLs in order to avoid "breaking" existing TLS servers.)\r
+\r
+ Servers that receive an extended client hello containing a\r
+ "client_certificate_url" extension MAY indicate that they are willing\r
+ to accept certificate URLs by including an extension of type\r
+ "client_certificate_url" in the (extended) server hello. The\r
+\r
+\r
+Donald Eastlake 3rd [Page 8]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ "extension_data" field of this extension SHALL be empty.\r
+\r
+ After negotiation of the use of client certificate URLs has been\r
+ successfully completed (by exchanging hellos including\r
+ "client_certificate_url" extensions), clients MAY send a\r
+ "CertificateURL" message in place of a "Certificate" message as\r
+ follows (see also Section 2):\r
+\r
+ enum {\r
+ individual_certs(0), pkipath(1), (255)\r
+ } CertChainType;\r
+\r
+ enum {\r
+ false(0), true(1)\r
+ } Boolean;\r
+\r
+ struct {\r
+ CertChainType type;\r
+ URLAndOptionalHash url_and_hash_list<1..2^16-1>;\r
+ } CertificateURL;\r
+\r
+ struct {\r
+ opaque url<1..2^16-1>;\r
+ Boolean hash_present;\r
+ select (hash_present) {\r
+ case false: struct {};\r
+ case true: SHA1Hash;\r
+ } hash;\r
+ } URLAndOptionalHash;\r
+\r
+ opaque SHA1Hash[20];\r
+\r
+ Here "url_and_hash_list" contains a sequence of URLs and optional\r
+ hashes.\r
+\r
+ When X.509 certificates are used, there are two possibilities:\r
+\r
+ - If CertificateURL.type is "individual_certs", each URL refers to a\r
+ single DER-encoded X.509v3 certificate, with the URL for the client's\r
+ certificate first.\r
+\r
+ - If CertificateURL.type is "pkipath", the list contains a single\r
+ URL referring to a DER-encoded certificate chain, using the type\r
+ PkiPath described in Section 8 of [RFCTLS].\r
+\r
+ When any other certificate format is used, the specification that\r
+ describes use of that format in TLS should define the encoding format\r
+ of certificates or certificate chains, and any constraint on their\r
+ ordering.\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 9]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ The hash corresponding to each URL at the client's discretion either\r
+ is not present or is the SHA-1 hash of the certificate or certificate\r
+ chain (in the case of X.509 certificates, the DER-encoded certificate\r
+ or the DER-encoded PkiPath).\r
+\r
+ Note that when a list of URLs for X.509 certificates is used, the\r
+ ordering of URLs is the same as that used in the TLS Certificate\r
+ message (see [RFCTLS], Section 7.4.2), but opposite to the order in\r
+ which certificates are encoded in PkiPath. In either case, the self-\r
+ signed root certificate MAY be omitted from the chain, under the\r
+ assumption that the server must already possess it in order to\r
+ validate it.\r
+\r
+ Servers receiving "CertificateURL" SHALL attempt to retrieve the\r
+ client's certificate chain from the URLs and then process the\r
+ certificate chain as usual. A cached copy of the content of any URL\r
+ in the chain MAY be used, provided that a SHA-1 hash is present for\r
+ that URL and it matches the hash of the cached copy.\r
+\r
+ Servers that support this extension MUST support the http: URL scheme\r
+ for certificate URLs, and MAY support other schemes. Use of other\r
+ schemes than "http", "https", or "ftp" may create unexpected\r
+ problems.\r
+\r
+ If the protocol used is HTTP, then the HTTP server can be configured\r
+ to use the Cache-Control and Expires directives described in\r
+ [RFC2616] to specify whether and for how long certificates or\r
+ certificate chains should be cached.\r
+\r
+ The TLS server is not required to follow HTTP redirects when\r
+ retrieving the certificates or certificate chain. The URLs used in\r
+ this extension SHOULD therefore be chosen not to depend on such\r
+ redirects.\r
+\r
+ If the protocol used to retrieve certificates or certificate chains\r
+ returns a MIME-formatted response (as HTTP does), then the following\r
+ MIME Content-Types SHALL be used: when a single X.509v3 certificate\r
+ is returned, the Content-Type is "application/pkix-cert" [RFC2585],\r
+ and when a chain of X.509v3 certificates is returned, the Content-\r
+ Type is "application/pkix-pkipath" (see Section 8 of [RFCTLS]).\r
+\r
+ If a SHA-1 hash is present for an URL, then the server MUST check\r
+ that the SHA-1 hash of the contents of the object retrieved from that\r
+ URL (after decoding any MIME Content-Transfer-Encoding) matches the\r
+ given hash. If any retrieved object does not have the correct SHA-1\r
+ hash, the server MUST abort the handshake with a\r
+ bad_certificate_hash_value(114) alert. This alert is always fatal.\r
+\r
+ Clients may choose to send either "Certificate" or "CertificateURL"\r
+ after successfully negotiating the option to send certificate URLs.\r
+\r
+\r
+Donald Eastlake 3rd [Page 10]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ The option to send a certificate is included to provide flexibility\r
+ to clients possessing multiple certificates.\r
+\r
+ If a server encounters an unreasonable delay in obtaining\r
+ certificates in a given CertificateURL, it SHOULD time out and signal\r
+ a certificate_unobtainable(111) error alert. This alert MAY be fatal;\r
+ for example, if client authentication is required by the server for\r
+ the handshake to continue.\r
+\r
+\r
+\r
+6. Trusted CA Indication\r
+\r
+ Constrained clients that, due to memory limitations, possess only a\r
+ small number of CA root keys may wish to indicate to servers which\r
+ root keys they possess, in order to avoid repeated handshake\r
+ failures.\r
+\r
+ In order to indicate which CA root keys they possess, clients MAY\r
+ include an extension of type "trusted_ca_keys" in the (extended)\r
+ client hello. The "extension_data" field of this extension SHALL\r
+ contain "TrustedAuthorities" where:\r
+\r
+ struct {\r
+ TrustedAuthority trusted_authorities_list<0..2^16-1>;\r
+ } TrustedAuthorities;\r
+\r
+ struct {\r
+ IdentifierType identifier_type;\r
+ select (identifier_type) {\r
+ case pre_agreed: struct {};\r
+ case key_sha1_hash: SHA1Hash;\r
+ case x509_name: DistinguishedName;\r
+ case cert_sha1_hash: SHA1Hash;\r
+ } identifier;\r
+ } TrustedAuthority;\r
+\r
+ enum {\r
+ pre_agreed(0), key_sha1_hash(1), x509_name(2),\r
+ cert_sha1_hash(3), (255)\r
+ } IdentifierType;\r
+\r
+ opaque DistinguishedName<1..2^16-1>;\r
+\r
+ Here "TrustedAuthorities" provides a list of CA root key identifiers\r
+ that the client possesses. Each CA root key is identified via either:\r
+\r
+ - "pre_agreed": no CA root key identity supplied.\r
+\r
+ - "key_sha1_hash": contains the SHA-1 hash of the CA root key. For\r
+\r
+\r
+Donald Eastlake 3rd [Page 11]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ Digital Signature Algorithm (DSA) and Elliptic Curve Digital\r
+ Signature Algorithm (ECDSA) keys, this is the hash of the\r
+ "subjectPublicKey" value. For RSA keys, the hash is of the big-\r
+ endian byte string representation of the modulus without any\r
+ initial 0-valued bytes. (This copies the key hash formats deployed\r
+ in other environments.)\r
+\r
+ - "x509_name": contains the DER-encoded X.509 DistinguishedName of\r
+ the CA.\r
+\r
+ - "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded\r
+ Certificate containing the CA root key.\r
+\r
+ Note that clients may include none, some, or all of the CA root keys\r
+ they possess in this extension.\r
+\r
+ Note also that it is possible that a key hash or a Distinguished Name\r
+ alone may not uniquely identify a certificate issuer (for example, if\r
+ a particular CA has multiple key pairs). However, here we assume this\r
+ is the case following the use of Distinguished Names to identify\r
+ certificate issuers in TLS.\r
+\r
+ The option to include no CA root keys is included to allow the client\r
+ to indicate possession of some pre-defined set of CA root keys.\r
+\r
+ Servers that receive a client hello containing the "trusted_ca_keys"\r
+ extension MAY use the information contained in the extension to guide\r
+ their selection of an appropriate certificate chain to return to the\r
+ client. In this event, the server SHALL include an extension of type\r
+ "trusted_ca_keys" in the (extended) server hello. The\r
+ "extension_data" field of this extension SHALL be empty.\r
+\r
+\r
+\r
+7. Truncated HMAC\r
+\r
+ Currently defined TLS cipher suites use the MAC construction HMAC\r
+ with either MD5 or SHA-1 [RFC2104] to authenticate record layer\r
+ communications. In TLS, the entire output of the hash function is\r
+ used as the MAC tag. However, it may be desirable in constrained\r
+ environments to save bandwidth by truncating the output of the hash\r
+ function to 80 bits when forming MAC tags.\r
+\r
+ In order to negotiate the use of 80-bit truncated HMAC, clients MAY\r
+ include an extension of type "truncated_hmac" in the extended client\r
+ hello. The "extension_data" field of this extension SHALL be empty.\r
+\r
+ Servers that receive an extended hello containing a "truncated_hmac"\r
+ extension MAY agree to use a truncated HMAC by including an extension\r
+ of type "truncated_hmac", with empty "extension_data", in the\r
+\r
+\r
+Donald Eastlake 3rd [Page 12]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ extended server hello.\r
+\r
+ Note that if new cipher suites are added that do not use HMAC, and\r
+ the session negotiates one of these cipher suites, this extension\r
+ will have no effect. It is strongly recommended that any new cipher\r
+ suites using other MACs consider the MAC size an integral part of the\r
+ cipher suite definition, taking into account both security and\r
+ bandwidth considerations.\r
+\r
+ If HMAC truncation has been successfully negotiated during a TLS\r
+ handshake, and the negotiated cipher suite uses HMAC, both the client\r
+ and the server pass this fact to the TLS record layer along with the\r
+ other negotiated security parameters. Subsequently during the\r
+ session, clients and servers MUST use truncated HMACs, calculated as\r
+ specified in [RFC2104]. That is, SecurityParameters.mac_length is 10\r
+ bytes, and only the first 10 bytes of the HMAC output are transmitted\r
+ and checked. Note that this extension does not affect the calculation\r
+ of the pseudo-random function (PRF) as part of handshaking or key\r
+ derivation.\r
+\r
+ The negotiated HMAC truncation size applies for the duration of the\r
+ session including session resumptions.\r
+\r
+\r
+\r
+8. Certificate Status Request\r
+\r
+ Constrained clients may wish to use a certificate-status protocol\r
+ such as OCSP [RFC2560] to check the validity of server certificates,\r
+ in order to avoid transmission of CRLs and therefore save bandwidth\r
+ on constrained networks. This extension allows for such information\r
+ to be sent in the TLS handshake, saving roundtrips and resources.\r
+\r
+ In order to indicate their desire to receive certificate status\r
+ information, clients MAY include an extension of type\r
+ "status_request" in the (extended) client hello. The "extension_data"\r
+ field of this extension SHALL contain "CertificateStatusRequest"\r
+ where:\r
+\r
+ struct {\r
+ CertificateStatusType status_type;\r
+ select (status_type) {\r
+ case ocsp: OCSPStatusRequest;\r
+ } request;\r
+ } CertificateStatusRequest;\r
+\r
+ enum { ocsp(1), (255) } CertificateStatusType;\r
+\r
+ struct {\r
+ ResponderID responder_id_list<0..2^16-1>;\r
+\r
+\r
+Donald Eastlake 3rd [Page 13]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ Extensions request_extensions;\r
+ } OCSPStatusRequest;\r
+\r
+ opaque ResponderID<1..2^16-1>;\r
+ opaque Extensions<0..2^16-1>;\r
+\r
+ In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP\r
+ responders that the client trusts. A zero-length "responder_id_list"\r
+ sequence has the special meaning that the responders are implicitly\r
+ known to the server, e.g., by prior arrangement. "Extensions" is a\r
+ DER encoding of OCSP request extensions.\r
+\r
+ Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as\r
+ defined in [RFC2560]. "Extensions" is imported from [RFC3280]. A\r
+ zero-length "request_extensions" value means that there are no\r
+ extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not\r
+ valid for the "Extensions" type).\r
+\r
+ In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is\r
+ unclear about its encoding; for clarification, the nonce MUST be a\r
+ DER-encoded OCTET STRING, which is encapsulated as another OCTET\r
+ STRING (note that implementations based on an existing OCSP client\r
+ will need to be checked for conformance to this requirement).\r
+\r
+ Servers that receive a client hello containing the "status_request"\r
+ extension MAY return a suitable certificate status response to the\r
+ client along with their certificate. If OCSP is requested, they\r
+ SHOULD use the information contained in the extension when selecting\r
+ an OCSP responder and SHOULD include request_extensions in the OCSP\r
+ request.\r
+\r
+ Servers return a certificate response along with their certificate by\r
+ sending a "CertificateStatus" message immediately after the\r
+ "Certificate" message (and before any "ServerKeyExchange" or\r
+ "CertificateRequest" messages). If a server returns a\r
+ "CertificateStatus" message, then the server MUST have included an\r
+ extension of type "status_request" with empty "extension_data" in the\r
+ extended server hello. The "CertificateStatus" message is conveyed\r
+ using the handshake message type "certificate_status" as follows (see\r
+ also Section 2):\r
+\r
+ struct {\r
+ CertificateStatusType status_type;\r
+ select (status_type) {\r
+ case ocsp: OCSPResponse;\r
+ } response;\r
+ } CertificateStatus;\r
+\r
+ opaque OCSPResponse<1..2^24-1>;\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 14]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ An "ocsp_response" contains a complete, DER-encoded OCSP response\r
+ (using the ASN.1 type OCSPResponse defined in [RFC2560]). Only one\r
+ OCSP response may be sent.\r
+\r
+ Note that a server MAY also choose not to send a "CertificateStatus"\r
+ message, even if it receives a "status_request" extension in the\r
+ client hello message.\r
+\r
+ Note in addition that servers MUST NOT send the "CertificateStatus"\r
+ message unless it received a "status_request" extension in the client\r
+ hello message.\r
+\r
+ Clients requesting an OCSP response and receiving an OCSP response in\r
+ a "CertificateStatus" message MUST check the OCSP response and abort\r
+ the handshake if the response is not satisfactory with\r
+ bad_certificate_status_response(113) alert. This alert is always\r
+ fatal.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 15]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+9. Error Alerts\r
+\r
+ This section defines new error alerts for use with the TLS extensions\r
+ defined in this document.\r
+\r
+ Four new error alerts are defined. To avoid "breaking" existing\r
+ clients and servers, these alerts MUST NOT be sent unless the sending\r
+ party has received an extended hello message from the party they are\r
+ communicating with. These error alerts are conveyed using the\r
+ following syntax:\r
+\r
+ enum {\r
+ close_notify(0),\r
+ unexpected_message(10),\r
+ bad_record_mac(20),\r
+ decryption_failed(21),\r
+ record_overflow(22),\r
+ decompression_failure(30),\r
+ handshake_failure(40),\r
+ /* 41 is not defined, for historical reasons */\r
+ bad_certificate(42),\r
+ unsupported_certificate(43),\r
+ certificate_revoked(44),\r
+ certificate_expired(45),\r
+ certificate_unknown(46),\r
+ illegal_parameter(47),\r
+ unknown_ca(48),\r
+ access_denied(49),\r
+ decode_error(50),\r
+ decrypt_error(51),\r
+ export_restriction(60),\r
+ protocol_version(70),\r
+ insufficient_security(71),\r
+ internal_error(80),\r
+ user_canceled(90),\r
+ no_renegotiation(100),\r
+ unsupported_extension(110),\r
+ certificate_unobtainable(111), /* new */\r
+ unrecognized_name(112), /* new */\r
+ bad_certificate_status_response(113), /* new */\r
+ bad_certificate_hash_value(114), /* new */\r
+ (255)\r
+ } AlertDescription;\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 16]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+10. IANA Considerations\r
+\r
+ IANA Considerations for TLS Extensions and the creation of a Registry\r
+ therefore are all covered in Section 12 of [RFCTLS]..\r
+\r
+\r
+\r
+11. Security Considerations\r
+\r
+ General Security Considerations for TLS Extensions are covered in\r
+ [RFCTLS]. Security Considerations for particular extensions specified\r
+ in this document are given below.\r
+\r
+ In general, implementers should continue to monitor the state of the\r
+ art and address any weaknesses identified.\r
+\r
+ Additional security considerations are described in the TLS 1.0 RFC\r
+ [RFC2246] and the TLS 1.1 RFC [RFC4346].\r
+\r
+\r
+\r
+11.1 Security Considerations for server_name\r
+\r
+ If a single server hosts several domains, then clearly it is\r
+ necessary for the owners of each domain to ensure that this satisfies\r
+ their security needs. Apart from this, server_name does not appear to\r
+ introduce significant security issues.\r
+\r
+ Implementations MUST ensure that a buffer overflow does not occur,\r
+ whatever the values of the length fields in server_name.\r
+\r
+ Although this document specifies an encoding for internationalized\r
+ hostnames in the server_name extension, it does not address any\r
+ security issues associated with the use of internationalized\r
+ hostnames in TLS (in particular, the consequences of "spoofed" names\r
+ that are indistinguishable from another name when displayed or\r
+ printed). It is recommended that server certificates not be issued\r
+ for internationalized hostnames unless procedures are in place to\r
+ mitigate the risk of spoofed hostnames.\r
+\r
+\r
+\r
+11.2 Security Considerations for max_fragment_length\r
+\r
+ The maximum fragment length takes effect immediately, including for\r
+ handshake messages. However, that does not introduce any security\r
+ complications that are not already present in TLS, since TLS requires\r
+ implementations to be able to handle fragmented handshake messages.\r
+\r
+ Note that as described in Section 4, once a non-null cipher suite has\r
+\r
+\r
+Donald Eastlake 3rd [Page 17]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ been activated, the effective maximum fragment length depends on the\r
+ cipher suite and compression method, as well as on the negotiated\r
+ max_fragment_length. This must be taken into account when sizing\r
+ buffers, and checking for buffer overflow.\r
+\r
+\r
+\r
+11.3 Security Considerations for client_certificate_url\r
+\r
+ There are two major issues with this extension.\r
+\r
+ The first major issue is whether or not clients should include\r
+ certificate hashes when they send certificate URLs.\r
+\r
+ When client authentication is used *without* the\r
+ client_certificate_url extension, the client certificate chain is\r
+ covered by the Finished message hashes. The purpose of including\r
+ hashes and checking them against the retrieved certificate chain is\r
+ to ensure that the same property holds when this extension is used,\r
+ i.e., that all of the information in the certificate chain retrieved\r
+ by the server is as the client intended.\r
+\r
+ On the other hand, omitting certificate hashes enables functionality\r
+ that is desirable in some circumstances; for example, clients can be\r
+ issued daily certificates that are stored at a fixed URL and need not\r
+ be provided to the client. Clients that choose to omit certificate\r
+ hashes should be aware of the possibility of an attack in which the\r
+ attacker obtains a valid certificate on the client's key that is\r
+ different from the certificate the client intended to provide.\r
+ Although TLS uses both MD5 and SHA-1 hashes in several other places,\r
+ this was not believed to be necessary here. The property required of\r
+ SHA-1 is second pre-image resistance.\r
+\r
+ The second major issue is that support for client_certificate_url\r
+ involves the server's acting as a client in another URL protocol.\r
+ The server therefore becomes subject to many of the same security\r
+ concerns that clients of the URL scheme are subject to, with the\r
+ added concern that the client can attempt to prompt the server to\r
+ connect to some (possibly weird-looking) URL.\r
+\r
+ In general, this issue means that an attacker might use the server to\r
+ indirectly attack another host that is vulnerable to some security\r
+ flaw. It also introduces the possibility of denial of service attacks\r
+ in which an attacker makes many connections to the server, each of\r
+ which results in the server's attempting a connection to the target\r
+ of the attack.\r
+\r
+ Note that the server may be behind a firewall or otherwise able to\r
+ access hosts that would not be directly accessible from the public\r
+ Internet. This could exacerbate the potential security and denial of\r
+\r
+\r
+Donald Eastlake 3rd [Page 18]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ service problems described above, as well as allow the existence of\r
+ internal hosts to be confirmed when they would otherwise be hidden.\r
+\r
+ The detailed security concerns involved will depend on the URL\r
+ schemes supported by the server. In the case of HTTP, the concerns\r
+ are similar to those that apply to a publicly accessible HTTP proxy\r
+ server. In the case of HTTPS, loops and deadlocks may be created, and\r
+ this should be addressed. In the case of FTP, attacks arise that are\r
+ similar to FTP bounce attacks.\r
+\r
+ As a result of this issue, it is RECOMMENDED that the\r
+ client_certificate_url extension should have to be specifically\r
+ enabled by a server administrator, rather than be enabled by default.\r
+ It is also RECOMMENDED that URI protocols be enabled by the\r
+ administrator individually, and only a minimal set of protocols be\r
+ enabled. Unusual protocols that offer limited security or whose\r
+ security is not well-understood SHOULD be avoided.\r
+\r
+ As discussed in [RFC3986], URLs that specify ports other than the\r
+ default may cause problems, as may very long URLs (which are more\r
+ likely to be useful in exploiting buffer overflow bugs).\r
+\r
+ Also note that HTTP caching proxies are common on the Internet, and\r
+ some proxies do not check for the latest version of an object\r
+ correctly. If a request using HTTP (or another caching protocol) goes\r
+ through a misconfigured or otherwise broken proxy, the proxy may\r
+ return an out-of-date response.\r
+\r
+\r
+\r
+11.4 Security Considerations for trusted_ca_keys\r
+\r
+ It is possible that which CA root keys a client possesses could be\r
+ regarded as confidential information. As a result, the CA root key\r
+ indication extension should be used with care.\r
+\r
+ The use of the SHA-1 certificate hash alternative ensures that each\r
+ certificate is specified unambiguously. As for the previous\r
+ extension, it was not believed necessary to use both MD5 and SHA-1\r
+ hashes.\r
+\r
+\r
+\r
+11.5 Security Considerations for truncated_hmac\r
+\r
+ It is possible that truncated MACs are weaker than "un-truncated"\r
+ MACs. However, no significant weaknesses are currently known or\r
+ expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.\r
+\r
+ Note that the output length of a MAC need not be as long as the\r
+\r
+\r
+Donald Eastlake 3rd [Page 19]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+ length of a symmetric cipher key, since forging of MAC values cannot\r
+ be done off-line: in TLS, a single failed MAC guess will cause the\r
+ immediate termination of the TLS session.\r
+\r
+ Since the MAC algorithm only takes effect after all handshake\r
+ messages that affect extension parameters have been authenticated by\r
+ the hashes in the Finished messages, it is not possible for an active\r
+ attacker to force negotiation of the truncated HMAC extension where\r
+ it would not otherwise be used (to the extent that the handshake\r
+ authentication is secure). Therefore, in the event that any security\r
+ problem were found with truncated HMAC in the future, if either the\r
+ client or the server for a given session were updated to take the\r
+ problem into account, it would be able to veto use of this extension.\r
+\r
+\r
+\r
+11.6 Security Considerations for status_request\r
+\r
+ If a client requests an OCSP response, it must take into account that\r
+ an attacker's server using a compromised key could (and probably\r
+ would) pretend not to support the extension. In this case, a client\r
+ that requires OCSP validation of certificates SHOULD either contact\r
+ the OCSP server directly or abort the handshake.\r
+\r
+ Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may\r
+ improve security against attacks that attempt to replay OCSP\r
+ responses; see Section 4.4.1 of [RFC2560] for further details.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 20]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+12. Normative References\r
+\r
+ [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-\r
+ Hashing for Message Authentication", RFC 2104, February 1997.\r
+\r
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
+ Requirement Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+ [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.\r
+ Adams, "X.509 Internet Public Key Infrastructure Online Certificate\r
+ Status Protocol - OCSP", RFC 2560, June 1999.\r
+\r
+ [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key\r
+ Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May\r
+ 1999.\r
+\r
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,\r
+ L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --\r
+ HTTP/1.1", RFC 2616, June 1999.\r
+\r
+ [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet\r
+ X.509 Public Key Infrastructure Certificate and Certificate\r
+ Revocation List (CRL) Profile", RFC 3280, April 2002.\r
+\r
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform\r
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January\r
+ 2005.\r
+\r
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security\r
+ (TLS) Protocol Version 1.1", RFC 4346, April 2006.\r
+\r
+ [RFCTLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2",\r
+ draft-ietf-tls-rfc4346-bis-*.txt, March 2007.\r
+\r
+\r
+\r
+13. Informative References\r
+\r
+ [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",\r
+ RFC 2246, January 1999.\r
+\r
+ [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher\r
+ Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.\r
+\r
+ [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites\r
+ for Transport Layer Security (TLS)", RFC 3268, June 2002.\r
+\r
+ [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,\r
+ and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366,\r
+ April 2006.\r
+\r
+\r
+Donald Eastlake 3rd [Page 21]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+Copyright, Disclaimer, and Additional IPR Provisions\r
+\r
+ Copyright (C) The IETF Trust (2008).\r
+\r
+ This document is subject to the rights, licenses and restrictions\r
+ contained in BCP 78, and except as set forth therein, the authors\r
+ retain all their rights.\r
+\r
+\r
+ This document and the information contained herein are provided on an\r
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS\r
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND\r
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS\r
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF\r
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED\r
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
+\r
+ The IETF takes no position regarding the validity or scope of any\r
+ Intellectual Property Rights or other rights that might be claimed to\r
+ pertain to the implementation or use of the technology described in\r
+ this document or the extent to which any license under such rights\r
+ might or might not be available; nor does it represent that it has\r
+ made any independent effort to identify any such rights. Information\r
+ on the procedures with respect to rights in RFC documents can be\r
+ found in BCP 78 and BCP 79.\r
+\r
+ Copies of IPR disclosures made to the IETF Secretariat and any\r
+ assurances of licenses to be made available, or the result of an\r
+ attempt made to obtain a general license or permission for the use of\r
+ such proprietary rights by implementers or users of this\r
+ specification can be obtained from the IETF on-line IPR repository at\r
+ http://www.ietf.org/ipr.\r
+\r
+ The IETF invites any interested party to bring to its attention any\r
+ copyrights, patents or patent applications, or other proprietary\r
+ rights that may cover technology that may be required to implement\r
+ this standard. Please address the information to the IETF at ietf-\r
+ ipr@ietf.org.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 22]\r
+\f\r
+INTERNET-DRAFT TLS Extension Definitions\r
+\r
+\r
+Author's Address\r
+\r
+ Donald Eastlake 3rd\r
+ Motorola Laboratories\r
+ 111 Locke Drive\r
+ Marlborough, MA 01752\r
+\r
+ Tel: +1-508-786-7554\r
+ Email: Donald.Eastlake@motorola.com\r
+\r
+\r
+\r
+Expiration and File Name\r
+\r
+ This draft expires in August 2008.\r
+\r
+ Its file name is draft-ietf-tls-rfc4366-bis-02.txt.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Donald Eastlake 3rd [Page 23]\r
+\f\r
projects / thirdparty / gnutls.git / commitdiff
