diff options
Diffstat (limited to 'doc/rfc/rfc3546.txt')
| -rw-r--r-- | doc/rfc/rfc3546.txt | 1627 |
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc3546.txt b/doc/rfc/rfc3546.txt new file mode 100644 index 0000000..4392449 --- /dev/null +++ b/doc/rfc/rfc3546.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group S. Blake-Wilson +Request for Comments: 3546 BCI +Updates: 2246 M. Nystrom +Category: Standards Track RSA Security + D. Hopwood + Independent Consultant + J. Mikkelsen + Transactionware + T. Wright + Vodafone + June 2003 + + + Transport Layer Security (TLS) Extensions + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes extensions that may be used to add + functionality to Transport Layer Security (TLS). It provides both + generic extension mechanisms for the TLS handshake client and server + hellos, and specific extensions using these generic mechanisms. + + The extensions may be used by TLS clients and servers. The + extensions are backwards compatible - communication is possible + between TLS 1.0 clients that support the extensions and TLS 1.0 + servers that do not support the extensions, and vice versa. + +Conventions used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [KEYWORDS]. + + + + + + +Blake-Wilson, et. al. Standards Track [Page 1] + +RFC 3546 TLS Extensions June 2003 + + +Table of Contents + + 1. Introduction ............................................. 2 + 2. General Extension Mechanisms ............................. 4 + 2.1. Extended Client Hello ............................... 5 + 2.2. Extended Server Hello ............................... 5 + 2.3. Hello Extensions .................................... 6 + 2.4. Extensions to the handshake protocol ................ 7 + 3. Specific Extensions ...................................... 8 + 3.1. Server Name Indication .............................. 8 + 3.2. Maximum Fragment Length Negotiation ................. 10 + 3.3. Client Certificate URLs ............................. 11 + 3.4. Trusted CA Indication ............................... 14 + 3.5. Truncated HMAC ...................................... 15 + 3.6. Certificate Status Request........................... 16 + 4. Error alerts .............................................. 18 + 5. Procedure for Defining New Extensions...................... 20 + 6. Security Considerations .................................. 21 + 6.1. Security of server_name ............................. 21 + 6.2. Security of max_fragment_length ..................... 21 + 6.3. Security of client_certificate_url .................. 22 + 6.4. Security of trusted_ca_keys ......................... 23 + 6.5. Security of truncated_hmac .......................... 23 + 6.6. Security of status_request .......................... 24 + 7. Internationalization Considerations ...................... 24 + 8. IANA Considerations ...................................... 24 + 9. Intellectual Property Rights ............................. 26 + 10. Acknowledgments .......................................... 26 + 11. Normative References ..................................... 27 + 12. Informative References ................................... 28 + 13. Authors' Addresses ....................................... 28 + 14. Full Copyright Statement ................................. 29 + +1. Introduction + + This document describes extensions that may be used to add + functionality to Transport Layer Security (TLS). It provides both + generic extension mechanisms for the TLS handshake client and server + hellos, and specific extensions using these generic mechanisms. + + TLS is now used in an increasing variety of operational environments + - many of which were not envisioned when the original design criteria + for TLS were determined. The extensions introduced in this document + are designed to enable TLS to operate as effectively as possible in + new environments like wireless networks. + + + + + + +Blake-Wilson, et. al. Standards Track [Page 2] + +RFC 3546 TLS Extensions June 2003 + + + Wireless environments often suffer from a number of constraints not + commonly present in wired environments. These constraints may + include bandwidth limitations, computational power limitations, + memory limitations, and battery life limitations. + + The extensions described here focus on extending the functionality + provided by the TLS protocol message formats. Other issues, such as + the addition of new cipher suites, are deferred. + + Specifically, the extensions described in this document are designed + to: + + - Allow TLS clients to provide to the TLS server the name of the + server they are contacting. This functionality is desirable to + facilitate secure connections to servers that host multiple + 'virtual' servers at a single underlying network address. + + - Allow TLS clients and servers to negotiate the maximum fragment + length to be sent. This functionality is desirable as a result of + memory constraints among some clients, and bandwidth constraints + among some access networks. + + - Allow TLS clients and servers to negotiate the use of client + certificate URLs. This functionality is desirable in order to + conserve memory on constrained clients. + + - Allow TLS clients to indicate to TLS servers which CA root keys + they possess. This functionality is desirable in order to prevent + multiple handshake failures involving TLS clients that are only + able to store a small number of CA root keys due to memory + limitations. + + - Allow TLS clients and servers to negotiate the use of truncated + MACs. This functionality is desirable in order to conserve + bandwidth in constrained access networks. + + - Allow TLS clients and servers to negotiate that the server sends + the client certificate status information (e.g., an Online + Certificate Status Protocol (OCSP) [OCSP] response) during a TLS + handshake. This functionality is desirable in order to avoid + sending a Certificate Revocation List (CRL) over a constrained + access network and therefore save bandwidth. + + In order to support the extensions above, general extension + mechanisms for the client hello message and the server hello message + are introduced. + + + + + +Blake-Wilson, et. al. Standards Track [Page 3] + +RFC 3546 TLS Extensions June 2003 + + + The extensions described in this document may be used by TLS 1.0 + clients and TLS 1.0 servers. The extensions are designed to be + backwards compatible - meaning that TLS 1.0 clients that support the + extensions can talk to TLS 1.0 servers that do not support the + extensions, and vice versa. + + Backwards compatibility is primarily achieved via two considerations: + + - Clients typically request the use of extensions via the extended + client hello message described in Section 2.1. TLS 1.0 [TLS] + requires servers to accept extended client hello messages, even if + the server does not "understand" the extension. + + - For the specific extensions described here, no mandatory server + response is required when clients request extended functionality. + + Note however, that although backwards compatibility is supported, + some constrained clients may be forced to reject communications with + servers that do not support the extensions as a result of the limited + capabilities of such clients. + + The remainder of this document is organized as follows. Section 2 + describes general extension mechanisms for the client hello and + server hello handshake messages. Section 3 describes specific + extensions to TLS 1.0. Section 4 describes new error alerts for use + with the TLS extensions. The final sections of the document address + IPR, security considerations, registration of the application/pkix- + pkipath MIME type, acknowledgements, and references. + +2. General Extension Mechanisms + + This section presents general extension mechanisms for the TLS + handshake client hello and server hello messages. + + These general extension mechanisms are necessary in order to enable + clients and servers to negotiate whether to use specific extensions, + and how to use specific extensions. The extension formats described + are based on [MAILING LIST]. + + Section 2.1 specifies the extended client hello message format, + Section 2.2 specifies the extended server hello message format, and + Section 2.3 describes the actual extension format used with the + extended client and server hellos. + + + + + + + + +Blake-Wilson, et. al. Standards Track [Page 4] + +RFC 3546 TLS Extensions June 2003 + + +2.1. Extended Client Hello + + Clients MAY request extended functionality from servers by sending + the extended client hello message format in place of the client hello + message format. The extended client hello message format is: + + struct { + ProtocolVersion client_version; + Random random; + SessionID session_id; + CipherSuite cipher_suites<2..2^16-1>; + CompressionMethod compression_methods<1..2^8-1>; + Extension client_hello_extension_list<0..2^16-1>; + } ClientHello; + + Here the new "client_hello_extension_list" field contains a list of + extensions. The actual "Extension" format is defined in Section 2.3. + + In the event that a client requests additional functionality using + the extended client hello, and this functionality is not supplied by + the server, the client MAY abort the handshake. + + Note that [TLS], Section 7.4.1.2, allows additional information to be + added to the client hello message. Thus the use of the extended + client hello defined above should not "break" existing TLS 1.0 + servers. + + A server that supports the extensions mechanism MUST accept only + client hello messages in either the original or extended ClientHello + format, and (as for all other messages) MUST check that the amount of + data in the message precisely matches one of these formats; if not + then it MUST send a fatal "decode_error" alert. This overrides the + "Forward compatibility note" in [TLS]. + +2.2. Extended Server Hello + + The extended server hello message format MAY be sent in place of the + server hello message when the client has requested extended + functionality via the extended client hello message specified in + Section 2.1. The extended server hello message format is: + + + + + + + + + + + +Blake-Wilson, et. al. Standards Track [Page 5] + +RFC 3546 TLS Extensions June 2003 + + + struct { + ProtocolVersion server_version; + Random random; + SessionID session_id; + CipherSuite cipher_suite; + CompressionMethod compression_method; + Extension server_hello_extension_list<0..2^16-1>; + } ServerHello; + + Here the new "server_hello_extension_list" field contains a list of + extensions. The actual "Extension" format is defined in Section 2.3. + + Note that the extended server hello message is only sent in response + to an extended client hello message. This prevents the possibility + that the extended server hello message could "break" existing TLS 1.0 + clients. + +2.3. Hello Extensions + + The extension format for extended client hellos and extended server + hellos is: + + struct { + ExtensionType extension_type; + opaque extension_data<0..2^16-1>; + } Extension; + + Here: + + - "extension_type" identifies the particular extension type. + + - "extension_data" contains information specific to the particular + extension type. + + The extension types defined in this document are: + + enum { + server_name(0), max_fragment_length(1), + client_certificate_url(2), trusted_ca_keys(3), + truncated_hmac(4), status_request(5), (65535) + } ExtensionType; + + Note that for all extension types (including those defined in + future), the extension type MUST NOT appear in the extended server + hello unless the same extension type appeared in the corresponding + client hello. Thus clients MUST abort the handshake if they receive + an extension type in the extended server hello that they did not + request in the associated (extended) client hello. + + + +Blake-Wilson, et. al. Standards Track [Page 6] + +RFC 3546 TLS Extensions June 2003 + + + Nonetheless "server initiated" extensions may be provided in the + future within this framework by requiring the client to first send an + empty extension to indicate that it supports a particular extension. + + Also note that when multiple extensions of different types are + present in the extended client hello or the extended server hello, + the extensions may appear in any order. There MUST NOT be more than + one extension of the same type. + + Finally note that all the extensions defined in this document are + relevant only when a session is initiated. However, a client that + requests resumption of a session does not in general know whether the + server will accept this request, and therefore it SHOULD send an + extended client hello if it would normally do so for a new session. + If the resumption request is denied, then a new set of extensions + will be negotiated as normal. If, on the other hand, the older + session is resumed, then the server MUST ignore extensions appearing + in the client hello, and send a server hello containing no + extensions; in this case the extension functionality negotiated + during the original session initiation is applied to the resumed + session. + +2.4. Extensions to the handshake protocol + + This document suggests the use of two new handshake messages, + "CertificateURL" and "CertificateStatus". These messages are + described in Section 3.3 and Section 3.6, respectively. The new + handshake message structure therefore becomes: + + enum { + hello_request(0), client_hello(1), server_hello(2), + certificate(11), server_key_exchange (12), + certificate_request(13), server_hello_done(14), + certificate_verify(15), client_key_exchange(16), + finished(20), certificate_url(21), certificate_status(22), + (255) + } HandshakeType; + + + + + + + + + + + + + + +Blake-Wilson, et. al. Standards Track [Page 7] + +RFC 3546 TLS Extensions June 2003 + + + struct { + HandshakeType msg_type; /* handshake type */ + uint24 length; /* bytes in message */ + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + case certificate_url: CertificateURL; + case certificate_status: CertificateStatus; + } body; + } Handshake; + +3. Specific Extensions + + This section describes the specific TLS extensions specified in this + document. + + Note that any messages associated with these extensions that are sent + during the TLS handshake MUST be included in the hash calculations + involved in "Finished" messages. + + Section 3.1 describes the extension of TLS to allow a client to + indicate which server it is contacting. Section 3.2 describes the + extension to provide maximum fragment length negotiation. Section + 3.3 describes the extension to allow client certificate URLs. + Section 3.4 describes the extension to allow a client to indicate + which CA root keys it possesses. Section 3.5 describes the extension + to allow the use of truncated HMAC. Section 3.6 describes the + extension to support integration of certificate status information + messages into TLS handshakes. + +3.1. Server Name Indication + + [TLS] does not provide a mechanism for a client to tell a server the + name of the server it is contacting. It may be desirable for clients + to provide this information to facilitate secure connections to + servers that host multiple 'virtual' servers at a single underlying + network address. + + + + + + +Blake-Wilson, et. al. Standards Track [Page 8] + +RFC 3546 TLS Extensions June 2003 + + + In order to provide the server name, clients MAY include an extension + of type "server_name" in the (extended) client hello. The + "extension_data" field of this extension SHALL contain + "ServerNameList" where: + + struct { + NameType name_type; + select (name_type) { + case host_name: HostName; + } name; + } ServerName; + + enum { + host_name(0), (255) + } NameType; + + opaque HostName<1..2^16-1>; + + struct { + ServerName server_name_list<1..2^16-1> + } ServerNameList; + + Currently the only server names supported are DNS hostnames, however + this does not imply any dependency of TLS on DNS, and other name + types may be added in the future (by an RFC that Updates this + document). TLS MAY treat provided server names as opaque data and + pass the names and types to the application. + + "HostName" contains the fully qualified DNS hostname of the server, + as understood by the client. The hostname is represented as a byte + string using UTF-8 encoding [UTF8], without a trailing dot. + + If the hostname labels contain only US-ASCII characters, then the + client MUST ensure that labels are separated only by the byte 0x2E, + representing the dot character U+002E (requirement 1 in section 3.1 + of [IDNA] notwithstanding). If the server needs to match the HostName + against names that contain non-US-ASCII characters, it MUST perform + the conversion operation described in section 4 of [IDNA], treating + the HostName as a "query string" (i.e. the AllowUnassigned flag MUST + be set). Note that IDNA allows labels to be separated by any of the + Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore + servers MUST accept any of these characters as a label separator. If + the server only needs to match the HostName against names containing + exclusively ASCII characters, it MUST compare ASCII names case- + insensitively. + + Literal IPv4 and IPv6 addresses are not permitted in "HostName". + + + + +Blake-Wilson, et. al. Standards Track [Page 9] + +RFC 3546 TLS Extensions June 2003 + + + It is RECOMMENDED that clients include an extension of type + "server_name" in the client hello whenever they locate a server by a + supported name type. + + A server that receives a client hello containing the "server_name" + extension, MAY use the information contained in the extension to + guide its selection of an appropriate certificate to return to the + client, and/or other aspects of security policy. In this event, the + server SHALL include an extension of type "server_name" in the + (extended) server hello. The "extension_data" field of this + extension SHALL be empty. + + If the server understood the client hello extension but does not + recognize the server name, it SHOULD send an "unrecognized_name" + alert (which MAY be fatal). + + If an application negotiates a server name using an application + protocol, then upgrades to TLS, and a server_name extension is sent, + then the extension SHOULD contain the same name that was negotiated + in the application protocol. If the server_name is established in + the TLS session handshake, the client SHOULD NOT attempt to request a + different server name at the application layer. + +3.2. Maximum Fragment Length Negotiation + + [TLS] specifies a fixed maximum plaintext fragment length of 2^14 + bytes. It may be desirable for constrained clients to negotiate a + smaller maximum fragment length due to memory limitations or + bandwidth limitations. + + In order to negotiate smaller maximum fragment lengths, clients MAY + include an extension of type "max_fragment_length" in the (extended) + client hello. The "extension_data" field of this extension SHALL + contain: + + enum{ + 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) + } MaxFragmentLength; + + whose value is the desired maximum fragment length. The allowed + values for this field are: 2^9, 2^10, 2^11, and 2^12. + + + + + + + + + + +Blake-Wilson, et. al. Standards Track [Page 10] + +RFC 3546 TLS Extensions June 2003 + + + Servers that receive an extended client hello containing a + "max_fragment_length" extension, MAY accept the requested maximum + fragment length by including an extension of type + "max_fragment_length" in the (extended) server hello. The + "extension_data" field of this extension SHALL contain + "MaxFragmentLength" whose value is the same as the requested maximum + fragment length. + + If a server receives a maximum fragment length negotiation request + for a value other than the allowed values, it MUST abort the + handshake with an "illegal_parameter" alert. Similarly, if a client + receives a maximum fragment length negotiation response that differs + from the length it requested, it MUST also abort the handshake with + an "illegal_parameter" alert. + + Once a maximum fragment length other than 2^14 has been successfully + negotiated, the client and server MUST immediately begin fragmenting + messages (including handshake messages), to ensure that no fragment + larger than the negotiated length is sent. Note that TLS already + requires clients and servers to support fragmentation of handshake + messages. + + The negotiated length applies for the duration of the session + including session resumptions. + + The negotiated length limits the input that the record layer may + process without fragmentation (that is, the maximum value of + TLSPlaintext.length; see [TLS] section 6.2.1). Note that the output + of the record layer may be larger. For example, if the negotiated + length is 2^9=512, then for currently defined cipher suites (those + defined in [TLS], [KERB], and [AESSUITES]), and when null compression + is used, the record layer output can be at most 793 bytes: 5 bytes of + headers, 512 bytes of application data, 256 bytes of padding, and 20 + bytes of MAC. That means that in this event a TLS record layer peer + receiving a TLS record layer message larger than 793 bytes may + discard the message and send a "record_overflow" alert, without + decrypting the message. + +3.3. Client Certificate URLs + + [TLS] specifies that when client authentication is performed, client + certificates are sent by clients to servers during the TLS handshake. + It may be desirable for constrained clients to send certificate URLs + in place of certificates, so that they do not need to store their + certificates and can therefore save memory. + + + + + + +Blake-Wilson, et. al. Standards Track [Page 11] + +RFC 3546 TLS Extensions June 2003 + + + In order to negotiate to send certificate URLs to a server, clients + MAY include an extension of type "client_certificate_url" in the + (extended) client hello. The "extension_data" field of this + extension SHALL be empty. + + (Note that it is necessary to negotiate use of client certificate + URLs in order to avoid "breaking" existing TLS 1.0 servers.) + + Servers that receive an extended client hello containing a + "client_certificate_url" extension, MAY indicate that they are + willing to accept certificate URLs by including an extension of type + "client_certificate_url" in the (extended) server hello. The + "extension_data" field of this extension SHALL be empty. + + After negotiation of the use of client certificate URLs has been + successfully completed (by exchanging hellos including + "client_certificate_url" extensions), clients MAY send a + "CertificateURL" message in place of a "Certificate" message: + + enum { + individual_certs(0), pkipath(1), (255) + } CertChainType; + + enum { + false(0), true(1) + } Boolean; + + struct { + CertChainType type; + URLAndOptionalHash url_and_hash_list<1..2^16-1>; + } CertificateURL; + + struct { + opaque url<1..2^16-1>; + Boolean hash_present; + select (hash_present) { + case false: struct {}; + case true: SHA1Hash; + } hash; + } URLAndOptionalHash; + + opaque SHA1Hash[20]; + + Here "url_and_hash_list" contains a sequence of URLs and optional + hashes. + + + + + + +Blake-Wilson, et. al. Standards Track [Page 12] + +RFC 3546 TLS Extensions June 2003 + + + When X.509 certificates are used, there are two possibilities: + + - if CertificateURL.type is "individual_certs", each URL refers to a + single DER-encoded X.509v3 certificate, with the URL for the + client's certificate first, or + + - if CertificateURL.type is "pkipath", the list contains a single + URL referring to a DER-encoded certificate chain, using the type + PkiPath described in Section 8. + + When any other certificate format is used, the specification that + describes use of that format in TLS should define the encoding format + of certificates or certificate chains, and any constraint on their + ordering. + + The hash corresponding to each URL at the client's discretion is + either not present or is the SHA-1 hash of the certificate or + certificate chain (in the case of X.509 certificates, the DER-encoded + certificate or the DER-encoded PkiPath). + + Note that when a list of URLs for X.509 certificates is used, the + ordering of URLs is the same as that used in the TLS Certificate + message (see [TLS] Section 7.4.2), but opposite to the order in which + certificates are encoded in PkiPath. In either case, the self-signed + root certificate MAY be omitted from the chain, under the assumption + that the server must already possess it in order to validate it. + + Servers receiving "CertificateURL" SHALL attempt to retrieve the + client's certificate chain from the URLs, and then process the + certificate chain as usual. A cached copy of the content of any URL + in the chain MAY be used, provided that a SHA-1 hash is present for + that URL and it matches the hash of the cached copy. + + Servers that support this extension MUST support the http: URL scheme + for certificate URLs, and MAY support other schemes. + + If the protocol used to retrieve certificates or certificate chains + returns a MIME formatted response (as HTTP does), then the following + MIME Content-Types SHALL be used: when a single X.509v3 certificate + is returned, the Content-Type is "application/pkix-cert" [PKIOP], and + when a chain of X.509v3 certificates is returned, the Content-Type is + "application/pkix-pkipath" (see Section 8). + + + + + + + + + +Blake-Wilson, et. al. Standards Track [Page 13] + +RFC 3546 TLS Extensions June 2003 + + + If a SHA-1 hash is present for an URL, then the server MUST check + that the SHA-1 hash of the contents of the object retrieved from that + URL (after decoding any MIME Content-Transfer-Encoding) matches the + given hash. If any retrieved object does not have the correct SHA-1 + hash, the server MUST abort the handshake with a + "bad_certificate_hash_value" alert. + + Note that clients may choose to send either "Certificate" or + "CertificateURL" after successfully negotiating the option to send + certificate URLs. The option to send a certificate is included to + provide flexibility to clients possessing multiple certificates. + + If a server encounters an unreasonable delay in obtaining + certificates in a given CertificateURL, it SHOULD time out and signal + a "certificate_unobtainable" error alert. + +3.4. Trusted CA Indication + + Constrained clients that, due to memory limitations, possess only a + small number of CA root keys, may wish to indicate to servers which + root keys they possess, in order to avoid repeated handshake + failures. + + In order to indicate which CA root keys they possess, clients MAY + include an extension of type "trusted_ca_keys" in the (extended) + client hello. The "extension_data" field of this extension SHALL + contain "TrustedAuthorities" where: + + struct { + TrustedAuthority trusted_authorities_list<0..2^16-1>; + } TrustedAuthorities; + + struct { + IdentifierType identifier_type; + select (identifier_type) { + case pre_agreed: struct {}; + case key_sha1_hash: SHA1Hash; + case x509_name: DistinguishedName; + case cert_sha1_hash: SHA1Hash; + } identifier; + } TrustedAuthority; + + enum { + pre_agreed(0), key_sha1_hash(1), x509_name(2), + cert_sha1_hash(3), (255) + } IdentifierType; + + opaque DistinguishedName<1..2^16-1>; + + + +Blake-Wilson, et. al. Standards Track [Page 14] + +RFC 3546 TLS Extensions June 2003 + + + Here "TrustedAuthorities" provides a list of CA root key identifiers + that the client possesses. Each CA root key is identified via + either: + + - "pre_agreed" - no CA root key identity supplied. + + - "key_sha1_hash" - contains the SHA-1 hash of the CA root key. For + DSA and ECDSA keys, this is the hash of the "subjectPublicKey" + value. For RSA keys, the hash is of the big-endian byte string + representation of the modulus without any initial 0-valued bytes. + (This copies the key hash formats deployed in other environments.) + + - "x509_name" - contains the DER-encoded X.509 DistinguishedName of + the CA. + + - "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded + Certificate containing the CA root key. + + Note that clients may include none, some, or all of the CA root keys + they possess in this extension. + + Note also that it is possible that a key hash or a Distinguished Name + alone may not uniquely identify a certificate issuer - for example if + a particular CA has multiple key pairs - however here we assume this + is the case following the use of Distinguished Names to identify + certificate issuers in TLS. + + The option to include no CA root keys is included to allow the client + to indicate possession of some pre-defined set of CA root keys. + + Servers that receive a client hello containing the "trusted_ca_keys" + extension, MAY use the information contained in the extension to + guide their selection of an appropriate certificate chain to return + to the client. In this event, the server SHALL include an extension + of type "trusted_ca_keys" in the (extended) server hello. The + "extension_data" field of this extension SHALL be empty. + +3.5. Truncated HMAC + + Currently defined TLS cipher suites use the MAC construction HMAC + with either MD5 or SHA-1 [HMAC] to authenticate record layer + communications. In TLS the entire output of the hash function is + used as the MAC tag. However it may be desirable in constrained + environments to save bandwidth by truncating the output of the hash + function to 80 bits when forming MAC tags. + + + + + + +Blake-Wilson, et. al. Standards Track [Page 15] + +RFC 3546 TLS Extensions June 2003 + + + In order to negotiate the use of 80-bit truncated HMAC, clients MAY + include an extension of type "truncated_hmac" in the extended client + hello. The "extension_data" field of this extension SHALL be empty. + + Servers that receive an extended hello containing a "truncated_hmac" + extension, MAY agree to use a truncated HMAC by including an + extension of type "truncated_hmac", with empty "extension_data", in + the extended server hello. + + Note that if new cipher suites are added that do not use HMAC, and + the session negotiates one of these cipher suites, this extension + will have no effect. It is strongly recommended that any new cipher + suites using other MACs consider the MAC size as an integral part of + the cipher suite definition, taking into account both security and + bandwidth considerations. + + If HMAC truncation has been successfully negotiated during a TLS + handshake, and the negotiated cipher suite uses HMAC, both the client + and the server pass this fact to the TLS record layer along with the + other negotiated security parameters. Subsequently during the + session, clients and servers MUST use truncated HMACs, calculated as + specified in [HMAC]. That is, CipherSpec.hash_size is 10 bytes, and + only the first 10 bytes of the HMAC output are transmitted and + checked. Note that this extension does not affect the calculation of + the PRF as part of handshaking or key derivation. + + The negotiated HMAC truncation size applies for the duration of the + session including session resumptions. + +3.6. Certificate Status Request + + Constrained clients may wish to use a certificate-status protocol + such as OCSP [OCSP] to check the validity of server certificates, in + order to avoid transmission of CRLs and therefore save bandwidth on + constrained networks. This extension allows for such information to + be sent in the TLS handshake, saving roundtrips and resources. + + In order to indicate their desire to receive certificate status + information, clients MAY include an extension of type + "status_request" in the (extended) client hello. The + "extension_data" field of this extension SHALL contain + "CertificateStatusRequest" where: + + + + + + + + + +Blake-Wilson, et. al. Standards Track [Page 16] + +RFC 3546 TLS Extensions June 2003 + + + struct { + CertificateStatusType status_type; + select (status_type) { + case ocsp: OCSPStatusRequest; + } request; + } CertificateStatusRequest; + + enum { ocsp(1), (255) } CertificateStatusType; + + struct { + ResponderID responder_id_list<0..2^16-1>; + Extensions request_extensions; + } OCSPStatusRequest; + + opaque ResponderID<1..2^16-1>; + opaque Extensions<0..2^16-1>; + + In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP + responders that the client trusts. A zero-length "responder_id_list" + sequence has the special meaning that the responders are implicitly + known to the server - e.g., by prior arrangement. "Extensions" is a + DER encoding of OCSP request extensions. + + Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as + defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero- + length "request_extensions" value means that there are no extensions + (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for + the "Extensions" type). + + In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is + unclear about its encoding; for clarification, the nonce MUST be a + DER-encoded OCTET STRING, which is encapsulated as another OCTET + STRING (note that implementations based on an existing OCSP client + will need to be checked for conformance to this requirement). + + Servers that receive a client hello containing the "status_request" + extension, MAY return a suitable certificate status response to the + client along with their certificate. If OCSP is requested, they + SHOULD use the information contained in the extension when selecting + an OCSP responder, and SHOULD include request_extensions in the OCSP + request. + + Servers return a certificate response along with their certificate by + sending a "CertificateStatus" message immediately after the + "Certificate" message (and before any "ServerKeyExchange" or + "CertificateRequest" messages). If a server returns a + + + + + +Blake-Wilson, et. al. Standards Track [Page 17] + +RFC 3546 TLS Extensions June 2003 + + + "CertificateStatus" message, then the server MUST have included an + extension of type "status_request" with empty "extension_data" in the + extended server hello. + + struct { + CertificateStatusType status_type; + select (status_type) { + case ocsp: OCSPResponse; + } response; + } CertificateStatus; + + opaque OCSPResponse<1..2^24-1>; + + An "ocsp_response" contains a complete, DER-encoded OCSP response + (using the ASN.1 type OCSPResponse defined in [OCSP]). Note that + only one OCSP response may be sent. + + The "CertificateStatus" message is conveyed using the handshake + message type "certificate_status". + + Note that a server MAY also choose not to send a "CertificateStatus" + message, even if it receives a "status_request" extension in the + client hello message. + + Note in addition that servers MUST NOT send the "CertificateStatus" + message unless it received a "status_request" extension in the client + hello message. + + Clients requesting an OCSP response, and receiving an OCSP response + in a "CertificateStatus" message MUST check the OCSP response and + abort the handshake if the response is not satisfactory. + +4. Error Alerts + + This section defines new error alerts for use with the TLS extensions + defined in this document. + + The following new error alerts are defined. To avoid "breaking" + existing clients and servers, these alerts MUST NOT be sent unless + the sending party has received an extended hello message from the + party they are communicating with. + + - "unsupported_extension" - this alert is sent by clients that + receive an extended server hello containing an extension that they + did not put in the corresponding client hello (see Section 2.3). + This message is always fatal. + + + + + +Blake-Wilson, et. al. Standards Track [Page 18] + +RFC 3546 TLS Extensions June 2003 + + + - "unrecognized_name" - this alert is sent by servers that receive a + server_name extension request, but do not recognize the server + name. This message MAY be fatal. + + - "certificate_unobtainable" - this alert is sent by servers who are + unable to retrieve a certificate chain from the URL supplied by + the client (see Section 3.3). This message MAY be fatal - for + example if client authentication is required by the server for the + handshake to continue and the server is unable to retrieve the + certificate chain, it may send a fatal alert. + + - "bad_certificate_status_response" - this alert is sent by clients + that receive an invalid certificate status response (see Section + 3.6). This message is always fatal. + + - "bad_certificate_hash_value" - this alert is sent by servers when + a certificate hash does not match a client provided + certificate_hash. This message is always fatal. + + These error alerts are conveyed using the following syntax: + + enum { + close_notify(0), + unexpected_message(10), + bad_record_mac(20), + decryption_failed(21), + record_overflow(22), + decompression_failure(30), + handshake_failure(40), + /* 41 is not defined, for historical reasons */ + bad_certificate(42), + unsupported_certificate(43), + certificate_revoked(44), + certificate_expired(45), + certificate_unknown(46), + illegal_parameter(47), + unknown_ca(48), + access_denied(49), + decode_error(50), + decrypt_error(51), + export_restriction(60), + protocol_version(70), + insufficient_security(71), + internal_error(80), + user_canceled(90), + no_renegotiation(100), + unsupported_extension(110), /* new */ + certificate_unobtainable(111), /* new */ + + + +Blake-Wilson, et. al. Standards Track [Page 19] + +RFC 3546 TLS Extensions June 2003 + + + unrecognized_name(112), /* new */ + bad_certificate_status_response(113), /* new */ + bad_certificate_hash_value(114), /* new */ + (255) + } AlertDescription; + +5. Procedure for Defining New Extensions + + Traditionally for Internet protocols, the Internet Assigned Numbers + Authority (IANA) handles the allocation of new values for future + expansion, and RFCs usually define the procedure to be used by the + IANA. However, there are subtle (and not so subtle) interactions + that may occur in this protocol between new features and existing + features which may result in a significant reduction in overall + security. + + Therefore, requests to define new extensions (including assigning + extension and error alert numbers) must be approved by IETF Standards + Action. + + The following considerations should be taken into account when + designing new extensions: + + - All of the extensions defined in this document follow the + convention that for each extension that a client requests and that + the server understands, the server replies with an extension of + the same type. + + - Some cases where a server does not agree to an extension are error + conditions, and some simply a refusal to support a particular + feature. In general error alerts should be used for the former, + and a field in the server extension response for the latter. + + - Extensions should as far as possible be designed to prevent any + attack that forces use (or non-use) of a particular feature by + manipulation of handshake messages. This principle should be + followed regardless of whether the feature is believed to cause a + security problem. + + Often the fact that the extension fields are included in the + inputs to the Finished message hashes will be sufficient, but + extreme care is needed when the extension changes the meaning of + messages sent in the handshake phase. Designers and implementors + should be aware of the fact that until the handshake has been + authenticated, active attackers can modify messages and insert, + remove, or replace extensions. + + + + + +Blake-Wilson, et. al. Standards Track [Page 20] + +RFC 3546 TLS Extensions June 2003 + + + - It would be technically possible to use extensions to change major + aspects of the design of TLS; for example the design of cipher + suite negotiation. This is not recommended; it would be more + appropriate to define a new version of TLS - particularly since + the TLS handshake algorithms have specific protection against + version rollback attacks based on the version number, and the + possibility of version rollback should be a significant + consideration in any major design change. + +6. Security Considerations + + Security considerations for the extension mechanism in general, and + the design of new extensions, are described in the previous section. + A security analysis of each of the extensions defined in this + document is given below. + + In general, implementers should continue to monitor the state of the + art, and address any weaknesses identified. + + Additional security considerations are described in the TLS 1.0 RFC + [TLS]. + +6.1. Security of server_name + + If a single server hosts several domains, then clearly it is + necessary for the owners of each domain to ensure that this satisfies + their security needs. Apart from this, server_name does not appear + to introduce significant security issues. + + Implementations MUST ensure that a buffer overflow does not occur + whatever the values of the length fields in server_name. + + Although this document specifies an encoding for internationalized + hostnames in the server_name extension, it does not address any + security issues associated with the use of internationalized + hostnames in TLS - in particular, the consequences of "spoofed" names + that are indistinguishable from another name when displayed or + printed. It is recommended that server certificates not be issued + for internationalized hostnames unless procedures are in place to + mitigate the risk of spoofed hostnames. + +6.2. Security of max_fragment_length + + The maximum fragment length takes effect immediately, including for + handshake messages. However, that does not introduce any security + complications that are not already present in TLS, since [TLS] + requires implementations to be able to handle fragmented handshake + messages. + + + +Blake-Wilson, et. al. Standards Track [Page 21] + +RFC 3546 TLS Extensions June 2003 + + + Note that as described in section 3.2, once a non-null cipher suite + has been activated, the effective maximum fragment length depends on + the cipher suite and compression method, as well as on the negotiated + max_fragment_length. This must be taken into account when sizing + buffers, and checking for buffer overflow. + +6.3. Security of client_certificate_url + + There are two major issues with this extension. + + The first major issue is whether or not clients should include + certificate hashes when they send certificate URLs. + + When client authentication is used *without* the + client_certificate_url extension, the client certificate chain is + covered by the Finished message hashes. The purpose of including + hashes and checking them against the retrieved certificate chain, is + to ensure that the same property holds when this extension is used - + i.e., that all of the information in the certificate chain retrieved + by the server is as the client intended. + + On the other hand, omitting certificate hashes enables functionality + that is desirable in some circumstances - for example clients can be + issued daily certificates that are stored at a fixed URL and need not + be provided to the client. Clients that choose to omit certificate + hashes should be aware of the possibility of an attack in which the + attacker obtains a valid certificate on the client's key that is + different from the certificate the client intended to provide. + Although TLS uses both MD5 and SHA-1 hashes in several other places, + this was not believed to be necessary here. The property required of + SHA-1 is second pre-image resistance. + + The second major issue is that support for client_certificate_url + involves the server acting as a client in another URL protocol. The + server therefore becomes subject to many of the same security + concerns that clients of the URL scheme are subject to, with the + added concern that the client can attempt to prompt the server to + connect to some, possibly weird-looking URL. + + In general this issue means that an attacker might use the server to + indirectly attack another host that is vulnerable to some security + flaw. It also introduces the possibility of denial of service + attacks in which an attacker makes many connections to the server, + each of which results in the server attempting a connection to the + target of the attack. + + + + + + +Blake-Wilson, et. al. Standards Track [Page 22] + +RFC 3546 TLS Extensions June 2003 + + + Note that the server may be behind a firewall or otherwise able to + access hosts that would not be directly accessible from the public + Internet; this could exacerbate the potential security and denial of + service problems described above, as well as allowing the existence + of internal hosts to be confirmed when they would otherwise be + hidden. + + The detailed security concerns involved will depend on the URL + schemes supported by the server. In the case of HTTP, the concerns + are similar to those that apply to a publicly accessible HTTP proxy + server. In the case of HTTPS, the possibility for loops and + deadlocks to be created exists and should be addressed. In the case + of FTP, attacks similar to FTP bounce attacks arise. + + As a result of this issue, it is RECOMMENDED that the + client_certificate_url extension should have to be specifically + enabled by a server administrator, rather than being enabled by + default. It is also RECOMMENDED that URI protocols be enabled by the + administrator individually, and only a minimal set of protocols be + enabled, with unusual protocols offering limited security or whose + security is not well-understood being avoided. + + As discussed in [URI], URLs that specify ports other than the default + may cause problems, as may very long URLs (which are more likely to + be useful in exploiting buffer overflow bugs). + + Also note that HTTP caching proxies are common on the Internet, and + some proxies do not check for the latest version of an object + correctly. If a request using HTTP (or another caching protocol) + goes through a misconfigured or otherwise broken proxy, the proxy may + return an out-of-date response. + +6.4. Security of trusted_ca_keys + + It is possible that which CA root keys a client possesses could be + regarded as confidential information. As a result, the CA root key + indication extension should be used with care. + + The use of the SHA-1 certificate hash alternative ensures that each + certificate is specified unambiguously. As for the previous + extension, it was not believed necessary to use both MD5 and SHA-1 + hashes. + +6.5. Security of truncated_hmac + + It is possible that truncated MACs are weaker than "un-truncated" + MACs. However, no significant weaknesses are currently known or + expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. + + + +Blake-Wilson, et. al. Standards Track [Page 23] + +RFC 3546 TLS Extensions June 2003 + + + Note that the output length of a MAC need not be as long as the + length of a symmetric cipher key, since forging of MAC values cannot + be done off-line: in TLS, a single failed MAC guess will cause the + immediate termination of the TLS session. + + Since the MAC algorithm only takes effect after the handshake + messages have been authenticated by the hashes in the Finished + messages, it is not possible for an active attacker to force + negotiation of the truncated HMAC extension where it would not + otherwise be used (to the extent that the handshake authentication is + secure). Therefore, in the event that any security problem were + found with truncated HMAC in future, if either the client or the + server for a given session were updated to take into account the + problem, they would be able to veto use of this extension. + +6.6. Security of status_request + + If a client requests an OCSP response, it must take into account that + an attacker's server using a compromised key could (and probably + would) pretend not to support the extension. A client that requires + OCSP validation of certificates SHOULD either contact the OCSP server + directly in this case, or abort the handshake. + + Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may + improve security against attacks that attempt to replay OCSP + responses; see section 4.4.1 of [OCSP] for further details. + +7. Internationalization Considerations + + None of the extensions defined here directly use strings subject to + localization. Domain Name System (DNS) hostnames are encoded using + UTF-8. If future extensions use text strings, then + internationalization should be considered in their design. + +8. IANA Considerations + + The MIME type "application/pkix-pkipath" has been registered by the + IANA with the following template: + + To: ietf-types@iana.org Subject: Registration of MIME media type + application/pkix-pkipath + + MIME media type name: application + + MIME subtype name: pkix-pkipath + + Required parameters: none + + + + +Blake-Wilson, et. al. Standards Track [Page 24] + +RFC 3546 TLS Extensions June 2003 + + + Optional parameters: version (default value is "1") + + Encoding considerations: + This MIME type is a DER encoding of the ASN.1 type PkiPath, + defined as follows: + PkiPath ::= SEQUENCE OF Certificate + PkiPath is used to represent a certification path. Within the + sequence, the order of certificates is such that the subject of + the first certificate is the issuer of the second certificate, + etc. + + This is identical to the definition that will be published in + [X509-4th-TC1]; note that it is different from that in [X509-4th]. + + All Certificates MUST conform to [PKIX]. (This should be + interpreted as a requirement to encode only PKIX-conformant + certificates using this type. It does not necessarily require + that all certificates that are not strictly PKIX-conformant must + be rejected by relying parties, although the security consequences + of accepting any such certificates should be considered + carefully.) + + DER (as opposed to BER) encoding MUST be used. If this type is + sent over a 7-bit transport, base64 encoding SHOULD be used. + + Security considerations: + The security considerations of [X509-4th] and [PKIX] (or any + updates to them) apply, as well as those of any protocol that uses + this type (e.g., TLS). + + Note that this type only specifies a certificate chain that can be + assessed for validity according to the relying party's existing + configuration of trusted CAs; it is not intended to be used to + specify any change to that configuration. + + Interoperability considerations: + No specific interoperability problems are known with this type, + but for recommendations relating to X.509 certificates in general, + see [PKIX]. + + Published specification: this memo, and [PKIX]. + + Applications which use this media type: TLS. It may also be used by + other protocols, or for general interchange of PKIX certificate + chains. + + + + + + +Blake-Wilson, et. al. Standards Track [Page 25] + +RFC 3546 TLS Extensions June 2003 + + + Additional information: + Magic number(s): DER-encoded ASN.1 can be easily recognized. + Further parsing is required to distinguish from other ASN.1 + types. + File extension(s): .pkipath + Macintosh File Type Code(s): not specified + + Person & email address to contact for further information: + Magnus Nystrom <magnus@rsasecurity.com> + + Intended usage: COMMON + + Author/Change controller: + Magnus Nystrom <magnus@rsasecurity.com> + +9. Intellectual Property Rights + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in RFC 2028. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this document. Please address the information to the IETF Executive + Director. + +10. Acknowledgments + + The authors wish to thank the TLS Working Group and the WAP Security + Group. This document is based on discussion within these groups. + + + + + + + + + + +Blake-Wilson, et. al. Standards Track [Page 26] + +RFC 3546 TLS Extensions June 2003 + + +11. Normative References + + [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: + Keyed-hashing for message authentication", RFC 2104, + February 1997. + + [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, + "Internationalizing Domain Names in Applications + (IDNA)", RFC 3490, March 2003. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and + C. Adams, "Internet X.509 Public Key Infrastructure: + Online Certificate Status Protocol - OCSP", RFC 2560, + June 1999. + + [PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key + Infrastructure - Operation Protocols: FTP and HTTP", + RFC 2585, May 1999. + + [PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet + Public Key Infrastructure - Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version + 1.0", RFC 2246, January 1999. + + [URI] Berners-Lee, T., Fielding, R. and L. Masinter, + "Uniform Resource Identifiers (URI): Generic Syntax", + RFC 2396, August 1998. + + [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- + 8:2001, "Information Systems - Open Systems + Interconnection - The Directory: Public key and + attribute certificate frameworks." + + + + + + +Blake-Wilson, et. al. Standards Track [Page 27] + +RFC 3546 TLS Extensions June 2003 + + + [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | + ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum + 1 to ISO/IEC 9594:8:2001. + +12. Informative References + + [KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher + Suites to Transport Layer Security (TLS)", RFC 2712, + October 1999. + + [MAILING LIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General + ClientHello extension mechanism and virtual hosting," + ietf-tls mailing list posting, August 14, 2000. + + [AESSUITES] Chown, P., "Advanced Encryption Standard (AES) + Ciphersuites for Transport Layer Security (TLS)", RFC + 3268, June 2002. + +13. Authors' Addresses + + Simon Blake-Wilson + BCI + EMail: sblakewilson@bcisse.com + + Magnus Nystrom + RSA Security + EMail: magnus@rsasecurity.com + + David Hopwood + Independent Consultant + EMail: david.hopwood@zetnet.co.uk + + Jan Mikkelsen + Transactionware + EMail: janm@transactionware.com + + Tim Wright + Vodafone + EMail: timothy.wright@vodafone.com + + + + + + + + + + + + +Blake-Wilson, et. al. Standards Track [Page 28] + +RFC 3546 TLS Extensions June 2003 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Blake-Wilson, et. al. Standards Track [Page 29] + |