Add.

1 files changed, 1254 insertions, 0 deletions

diff --git a/doc/protocol/draft-ietf-tls-rfc4366-bis-01.txt b/doc/protocol/draft-ietf-tls-rfc4366-bis-01.txt
new file mode 100644
index 0000000000..367d6667f3
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-rfc4366-bis-01.txt
@@ -0,0 +1,1254 @@
+TLS Working Group                                    Donald Eastlake 3rd
+INTERNET-DRAFT                                     Motorola Laboratories
+Obsoletes: RFC 4366
+Updates: RFC 2246, RFC 4346
+Intended status: Proposed Standard
+Expires: July 2008                                      January 14, 2009
+
+
+    Transport Layer Security (TLS) Extensions: Extension Definitions
+
+                  <draft-ietf-tls-rfc4366-bis-01.txt>
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Distribution of this document is unlimited.  Comments should be sent
+   to the TLS working group mailing list <tls@ietf.org>.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   This document provides documentation for existing specific TLS
+   extensions. It is a companion document for the TLS 1.2 specification,
+   draft-ietf-tls-rfc4346-bis-07.txt.
+
+
+
+
+
+
+
+
+
+
+Donald Eastlake 3rd                                             [Page 1]
+
+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.
+
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+
+      Acknowledgements...........................................2
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      1.1 Specific Extensions Covered............................3
+      1.2 Conventions Used in This Document......................4
+
+      3. Server Name Indication..................................5
+      4. Maximum Fragment Length Negotiation.....................6
+      5. Client Certificate URLs.................................7
+      6. Trusted CA Indication..................................10
+      7. Truncated HMAC.........................................11
+      8. Certificate Status Request.............................12
+
+      9. IANA Considerations....................................15
+      10. Security Considerations...............................15
+      10.1 Security Considerations for server_name..............15
+      10.2 Security Considerations for max_fragment_length......15
+      10.3 Security Considerations for client_certificate_url...16
+      10.4 Security Considerations for trusted_ca_keys..........17
+      10.5 Security Considerations for truncated_hmac...........17
+      10.6 Security Considerations for status_request...........18
+      11. Internationalization Considerations...................18
+
+      12. Normative References..................................19
+      13. Informative References................................19
+
+      Copyright, Disclaimer, and Additional IPR Provisions......21
+
+      Author's Address..........................................22
+      Expiration and File Name..................................22
+
+
+
+
+
+
+
+
+Donald Eastlake 3rd                                             [Page 2]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+1. Introduction
+
+   The TLS (Transport Layer Security) Protocol Version 1.2 is specified
+   in [RFCTLS]. That specification includes the framework for extensions
+   to TLS, considerations in designing such extensions (see Section
+   7.4.1.4 of [RFCTLS]), and IANA Considerations for the allocation of
+   new extension code points; however, it does not specify any
+   particular extensions other than CertHashTypes (see Section
+   7.4.1.4.1of [RFCTLS]).
+
+   This document provides the specifications for existing TLS
+   extensions. It is, for the most part, the mere adaptation and editing
+   of material from [RFC4366], which covered all aspects of TLS
+   extensions for TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346].
+
+
+
+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.
+
+   Specifically, the extensions described in this document:
+
+   -  Allow TLS clients to provide to the TLS server the name of the
+      server they are contacting. This functionality is desirable in
+      order 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
+
+
+Donald Eastlake 3rd                                             [Page 3]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+      the client certificate status information (e.g., an Online
+      Certificate Status Protocol (OCSP) [RFC2560] 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.
+
+   The extensions described in this document may be used by TLS clients
+   and servers. The extensions are designed to be backwards compatible,
+   meaning that TLS clients that support the extensions can talk to TLS
+   servers that do not support the extensions, and vice versa. The
+   document therefore updates TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346].
+
+
+
+1.2 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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donald Eastlake 3rd                                             [Page 4]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+3. 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.
+
+   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 [RFC3629], 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 [RFC3490] 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 [RFC3490],
+   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
+
+
+Donald Eastlake 3rd                                             [Page 5]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   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".
+
+   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 and then upgrades to TLS, and if 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.
+
+
+
+4. Maximum Fragment Length Negotiation
+
+   Without this extension, 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.
+
+
+
+Donald Eastlake 3rd                                             [Page 6]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   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 a
+   "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 [RFCTLS], 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 [RFCTLS], [RFC2712], and [RFC3268]), 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. This 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.
+
+
+
+5. Client Certificate URLs
+
+   Without this extension, 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.
+
+   In order to negotiate sending certificate URLs to a server, clients
+   MAY include an extension of type "client_certificate_url" in the
+
+
+Donald Eastlake 3rd                                             [Page 7]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   (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 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.
+
+   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.
+
+
+
+Donald Eastlake 3rd                                             [Page 8]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   -  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 of [RFCTLS].
+
+   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 either
+   is 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 [RFCTLS], 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. 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.
+
+   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" [RFC2585],
+   and when a chain of X.509v3 certificates is returned, the Content-
+   Type is "application/pkix-pkipath" (see Section 8 of [RFCTLS]).
+
+
+
+Donald Eastlake 3rd                                             [Page 9]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   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.
+
+
+
+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.
+
+   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>;
+
+
+Donald Eastlake 3rd                                            [Page 10]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   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
+      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
+      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.
+
+
+
+7. Truncated HMAC
+
+   Currently defined TLS cipher suites use the MAC construction HMAC
+   with either MD5 or SHA-1 [RFC2104] 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.
+
+   In order to negotiate the use of 80-bit truncated HMAC, clients MAY
+
+
+Donald Eastlake 3rd                                            [Page 11]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   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 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 [RFC2104]. 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 pseudo-random function (PRF) as part of handshaking or key
+   derivation.
+
+   The negotiated HMAC truncation size applies for the duration of the
+   session including session resumptions.
+
+
+
+8. Certificate Status Request
+
+   Constrained clients may wish to use a certificate-status protocol
+   such as OCSP [RFC2560] 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:
+
+      struct {
+          CertificateStatusType status_type;
+          select (status_type) {
+              case ocsp: OCSPStatusRequest;
+          } request;
+
+
+Donald Eastlake 3rd                                            [Page 12]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+      } 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 [RFC2560]. "Extensions" is imported from [RFC3280].  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, [RFC2560] 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
+   "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;
+
+
+Donald Eastlake 3rd                                            [Page 13]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+      } 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 [RFC2560]). 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.
+
+          certificate_unobtainable(111),        /* new */
+          unrecognized_name(112),               /* new */
+          bad_certificate_status_response(113), /* new */
+          bad_certificate_hash_value(114),      /* new */
+          (255)
+      } AlertDescription;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donald Eastlake 3rd                                            [Page 14]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+9. IANA Considerations
+
+   IANA Considerations for TLS Extensions and the creation of a Registry
+   therefore are all covered in Section 12 of [RFCTLS]..
+
+
+
+10. Security Considerations
+
+   General Security Considerations for TLS Extensions are covered in
+   [RFCTLS]. Security Considerations for particular extensions specified
+   in this document are 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
+   [RFC2246] and the TLS 1.1 RFC [RFC4346].
+
+
+
+10.1 Security Considerations for 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.
+
+
+
+10.2 Security Considerations for 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.
+
+   Note that as described in Section 4, once a non-null cipher suite has
+
+
+Donald Eastlake 3rd                                            [Page 15]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   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.
+
+
+
+10.3 Security Considerations for 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's 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's attempting a connection to the target
+   of the attack.
+
+   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
+
+
+Donald Eastlake 3rd                                            [Page 16]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   service problems described above, as well as allow 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, loops and deadlocks may be created, and
+   this should be addressed. In the case of FTP, attacks arise that are
+   similar to FTP bounce attacks.
+
+   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 be 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. Unusual protocols that offer limited security or whose
+   security is not well-understood SHOULD be avoided.
+
+   As discussed in [RFC3986], 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.
+
+
+
+10.4 Security Considerations for 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.
+
+
+
+10.5 Security Considerations for 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.
+
+   Note that the output length of a MAC need not be as long as the
+
+
+Donald Eastlake 3rd                                            [Page 17]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   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 all handshake
+   messages that affect extension parameters 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 the future, if either the
+   client or the server for a given session were updated to take the
+   problem into account, it would be able to veto use of this extension.
+
+
+
+10.6 Security Considerations for 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. In this case, a client
+   that requires OCSP validation of certificates SHOULD either contact
+   the OCSP server directly 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 [RFC2560] for further details.
+
+
+
+11. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donald Eastlake 3rd                                            [Page 18]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+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.
+
+   [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
+   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.
+
+   [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+   X.509 Public Key Infrastructure Certificate and Certificate
+   Revocation List (CRL) Profile", RFC 3280, April 2002.
+
+   [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+   "Internationalizing Domain Names in Applications (IDNA)", RFC 3490,
+   March 2003.
+
+   [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+   STD 63, RFC 3629, November 2003.
+
+   [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+   Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January
+   2005.
+
+   [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
+   (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+   [RFCTLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2",
+   draft-ietf-tls-rfc4346-bis-*.txt, March 2007.
+
+
+
+13. Informative References
+
+   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+   RFC 2246, January 1999.
+
+   [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
+   Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
+
+
+Donald Eastlake 3rd                                            [Page 19]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+   [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
+   for Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
+   and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366,
+   April 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donald Eastlake 3rd                                            [Page 20]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+Copyright, Disclaimer, and Additional IPR Provisions
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donald Eastlake 3rd                                            [Page 21]
+
+INTERNET-DRAFT                                 TLS Extension Definitions
+
+
+Author's Address
+
+   Donald Eastlake 3rd
+   Motorola Laboratories
+   111 Locke Drive
+   Marlborough, MA 01752
+
+   Tel:   +1-508-786-7554
+   Email: Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires in July 2008.
+
+   Its file name is draft-ietf-tls-rfc4366-bis-01.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donald Eastlake 3rd                                            [Page 22]
+