--- 1/draft-ietf-tls-rfc4366-bis-10.txt 2010-09-19 23:13:04.000000000 +0200 +++ 2/draft-ietf-tls-rfc4366-bis-11.txt 2010-09-19 23:13:04.000000000 +0200 @@ -1,27 +1,27 @@ TLS Working Group Donald Eastlake 3rd INTERNET-DRAFT Stellar Switches Obsoletes: 4366 Intended status: Proposed Standard -Expires: January 29, 2011 July 30, 2010 +Expires: March 18, 2011 September 19, 2010 Transport Layer Security (TLS) Extensions: Extension Definitions - + Abstract This document provides specifications for existing TLS extensions. It - is a companion document for the TLS 1.2 specification [RFC5246]. The - extensions specified are server_name, max_fragment_length, - client_certificate_url, trusted_ca_keys, truncated_hmac, and - status_request. + is a companion document for RFC 5246, "The Transport Layer Security + (TLS) Protocol Version 1.2". The extensions specified are + server_name, max_fragment_length, client_certificate_url, + trusted_ca_keys, truncated_hmac, and status_request. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from @@ -49,21 +49,22 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html INTERNET-DRAFT TLS Extension Definitions Acknowledgements This draft is based on material from RFC 4366 for which the authors were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T. - Wright. + Wright. Other contributors include Joseph Salowey, and Alexey + Melnikov, Peter Saint-Andre, and Adrian Farrel. Table of Contents 1. Introduction............................................3 1.1 Specific Extensions Covered............................3 1.2 Conventions Used in This Document......................5 2. Extensions to the Handshake Protocol....................6 3. Server Name Indication..................................7 4. Maximum Fragment Length Negotiation.....................9 @@ -96,22 +97,22 @@ The TLS (Transport Layer Security) Protocol Version 1.2 is specified in [RFC5246]. That specification includes the framework for extensions to TLS, considerations in designing such extensions (see Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the allocation of new extension code points; however, it does not specify any particular extensions other than Signature Algorithms (see Section 7.4.1.4.1 of [RFC5246]). This document provides the specifications for existing TLS extensions. It is, for the most part, the adaptation and editing of - material from [RFC4366], which covered TLS extensions for TLS 1.0 - [RFC2246] and TLS 1.1 [RFC4346]. + material from RFC 4366, which covered TLS extensions for TLS 1.0 (RFC + 2246) and TLS 1.1 (RFC 4346). 1.1 Specific Extensions Covered 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. The extension types defined in this document are: enum { @@ -185,22 +186,22 @@ containing none of the extension types. In this case, the functionality of these extensions negotiated during the original session initiation is applied to the resumed session. INTERNET-DRAFT TLS Extension Definitions 1.2 Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in RFC - 2119. + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. INTERNET-DRAFT TLS Extension Definitions 2. Extensions to the Handshake Protocol This document specifies the use of two new handshake messages, "CertificateURL" and "CertificateStatus". These messages are described in Section 5 and Section 8, respectively. The new handshake message structure therefore becomes: @@ -286,27 +287,32 @@ implementations only send one name, and the client cannot INTERNET-DRAFT TLS Extension Definitions necessarily find out which name the server selected. Multiple names of the same name_type are therefore now prohibited. 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). However, for backward compatibility, all future NameTypes - MUST begin with a 16-bit length field. TLS MAY treat provided server - names as opaque data and pass the names and types to the application. + document). The data structure associated with the host_name NameType + is a variable-length vector that begins with a 16-bit length. For + backward compatibility, all future data structures associated with + new NameTypes MUST begin with a 16-bit length field 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 ASCII encoding without a trailing dot. + string using ASCII encoding without a trailing dot. This allows the + support of internationalized domain names through the use of A-labels + defined in [RFC5890]. Literal IPv4 and IPv6 addresses are not permitted in "HostName". 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, @@ -488,52 +494,53 @@ Servers that support this extension MUST support the 'http' URI scheme for certificate URLs, and MAY support other schemes. Use of other schemes than 'http', 'https', or 'ftp' may create unexpected problems. If the protocol used is HTTP, then the HTTP server can be configured to use the Cache-Control and Expires directives described in [RFC2616] to specify whether and for how long certificates or certificate chains should be cached. - The TLS server is not required to follow HTTP redirects when - retrieving the certificates or certificate chain. The URLs used in - this extension SHOULD therefore be chosen not to depend on such - redirects. + The TLS server MUST NOT follow HTTP redirects when retrieving the + certificates or certificate chain. The URLs used in this extension + MUST NOT be chosen to depend on such redirects. 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 INTERNET-DRAFT TLS Extension Definitions - MIME Content-Types SHALL be used: when a single X.509v3 certificate is returned, the Content-Type is "application/pkix-cert" [RFC2585], and when a chain of X.509v3 certificates is returned, the Content- Type is "application/pkix-pkipath" Section 10.1. 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(114) alert. This alert is always fatal. 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(111) error alert. This alert MAY be fatal; - for example, if client authentication is required by the server for - the handshake to continue. + If a server is unable to obtain certificates in a given + CertificateURL, it MUST send a fatal certificate_unobtainable(111) + alert if it requires the certificates to complete the handshake. If + the server does not require the certificates then the server + continues the handshake. The server MAY send a warning level alert in + this case. Clients receiving such an alert SHOULD log the alert and + continue with the handshake if possible INTERNET-DRAFT TLS Extension Definitions 6. 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. @@ -572,24 +579,23 @@ Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (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 - INTERNET-DRAFT TLS Extension Definitions + - "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. @@ -798,21 +804,21 @@ INTERNET-DRAFT TLS Extension Definitions 10. IANA Considerations IANA Considerations for TLS Extensions and the creation of a Registry therefore are covered in Section 12 of [RFC5246] except for the registration of MIME type application/pkix-pkipath which appears below. The IANA TLS extensions and MIME type application/pkix-pkipath - registry entries that reference [RFC4366] should be updated to + registry entries that reference RFC 4366 should be updated to reference this document on its publication as an RFC. 10.1 pkipath MIME Type Registration MIME media type name: application MIME subtype name: pkix-pkipath Required parameters: none Optional parameters: version (default value is "1") @@ -848,35 +854,35 @@ 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 [RFC5280]. - Published specification: [RFC4366], and [RFC5280]. + Published specification: This document and [RFC5280]. Applications which use this media type: TLS. It may also be used by other protocols, or for general interchange of PKIX certificate chains. Additional information: Magic number(s): DER-encoded ASN.1 can be easily recognized. Further parsing is required to distinguish it 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 Nystrom Intended usage: COMMON Change controller: IESG INTERNET-DRAFT TLS Extension Definitions 11. Security Considerations General Security Considerations for TLS Extensions are covered in @@ -1022,67 +1028,62 @@ 12. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. - Adams, "X.509 Internet Public Key Infrastructure Online Certificate - Status Protocol - OCSP", RFC 2560, June 1999. + Adams, "X.509 Internet Public Key Infrastructure Online + Certificate Status Protocol - OCSP", RFC 2560, June 1999. [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key - Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May - 1999. + Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, + May 1999. [RFC2616] 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. + L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol + -- HTTP/1.1", RFC 2616, June 1999. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January - 2005. + Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, + January 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., - Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, - May 2008 + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, May 2008 -13. Informative References + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", RFC + 5890, August 2010. - [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", - RFC 2246, January 1999. +13. Informative References [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher - Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. - - [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.1", RFC 4346, April 2006. + Suites to Transport Layer Security (TLS)", RFC 2712, October + 1999. - [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., - and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, - April 2006. + [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." INTERNET-DRAFT TLS Extension Definitions - [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." - [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. + ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to + ISO/IEC 9594:8:2001. INTERNET-DRAFT TLS Extension Definitions Annex A: Changes from RFC 4366 The significant changes between RFC 4366 and this document are described below. RFC 4366 described both general extension mechanisms (for the TLS handshake and client and server hellos) as well as specific @@ -1108,20 +1109,23 @@ server_name extension is different but instead a full handshake must be done to possibly establish a new session. The Client Certificate URLs extension has been changed to make the presence of a hash mandatory. For the case of DTLS, the requirement to report an overflow of the negotiated maximum fragment length is made conditional on passing authentication. + TLS servers are now prohibited from following HTTP redirects when + retrieving certificates. + The material was also re-organized in minor ways. For example, information as to which errors are fatal is moved from the one "Error Alerts" section to the individual extension specifications. INTERNET-DRAFT TLS Extension Definitions Author's Address Donald Eastlake 3rd Stellar Switches, Inc.