draft-ietf-tls-rfc4366-bis-04.txt   draft-ietf-tls-rfc4366-bis-05.txt 
TLS Working Group Donald Eastlake 3rd TLS Working Group Donald Eastlake 3rd
INTERNET-DRAFT Stellar Switches INTERNET-DRAFT Stellar Switches
Obsoletes: RFC 4366 Obsoletes: RFC 4366
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: October 19, 2009 April 20, 2009 Expires: December 21, 2009 June 22, 2009
Transport Layer Security (TLS) Extensions: Extension Definitions Transport Layer Security (TLS) Extensions: Extension Definitions
<draft-ietf-tls-rfc4366-bis-04.txt> <draft-ietf-tls-rfc4366-bis-05.txt>
Status of This Document Status of This Document
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 18 skipping to change at page 2, line 18
This draft is based on material from RFC 4366 for which the authors 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. were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T.
Wright. Wright.
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1 Abstract...................................................1
Acknowledgements...........................................2 Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3 1. Introduction............................................3
1.1 Specific Extensions Covered............................3 1.1 Specific Extensions Covered............................3
1.2 Conventions Used in This Document......................4 1.2 Conventions Used in This Document......................4
2. Extensions to the Handshake Protocol....................5 2. Extensions to the Handshake Protocol....................5
3. Server Name Indication..................................6 3. Server Name Indication..................................6
4. Maximum Fragment Length Negotiation.....................8 4. Maximum Fragment Length Negotiation.....................8
5. Client Certificate URLs................................10 5. Client Certificate URLs................................10
6. Trusted CA Indication..................................13 6. Trusted CA Indication..................................13
7. Truncated HMAC.........................................15 7. Truncated HMAC.........................................15
8. Certificate Status Request.............................16 8. Certificate Status Request.............................16
9. Error Alerts...........................................18 9. Error Alerts...........................................18
10. IANA Considerations...................................19 10. IANA Considerations...................................19
11. Security Considerations...............................19 11. Security Considerations...............................19
11.1 Security Considerations for server_name..............19 11.1 Security Considerations for server_name..............19
11.2 Security Considerations for max_fragment_length......19 11.2 Security Considerations for max_fragment_length......19
11.3 Security Considerations for client_certificate_url...20 11.3 Security Considerations for client_certificate_url...20
11.4 Security Considerations for trusted_ca_keys..........21 11.4 Security Considerations for trusted_ca_keys..........21
11.5 Security Considerations for truncated_hmac...........21 11.5 Security Considerations for truncated_hmac...........21
11.6 Security Considerations for status_request...........22 11.6 Security Considerations for status_request...........21
12. Normative References..................................23
13. Informative References................................23
Annex A: pkipath MIME Type Registration...................25 12. Normative References..................................22
13. Informative References................................22
Annex A: pkipath MIME Type Registration...................24
Annex B: Changes from RFC 4366............................26
Author's Address..........................................27 Author's Address..........................................27
Copyright and IPR Provisions..............................28 Copyright and IPR Provisions..............................28
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
1. Introduction 1. Introduction
The TLS (Transport Layer Security) Protocol Version 1.2 is specified The TLS (Transport Layer Security) Protocol Version 1.2 is specified
in [RFC5246]. That specification includes the framework for in [RFC5246]. That specification includes the framework for
extensions to TLS, considerations in designing such extensions (see extensions to TLS, considerations in designing such extensions (see
skipping to change at page 6, line 15 skipping to change at page 6, line 15
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
3. Server Name Indication 3. Server Name Indication
TLS does not provide a mechanism for a client to tell a server the 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 name of the server it is contacting. It may be desirable for clients
to provide this information to facilitate secure connections to to provide this information to facilitate secure connections to
servers that host multiple 'virtual' servers at a single underlying servers that host multiple 'virtual' servers at a single underlying
network address. network address.
In order to provide the server name, clients MAY include an extension In order to provide any of the server names, clients MAY include an
of type "server_name" in the (extended) client hello. The extension of type "server_name" in the (extended) client hello. The
"extension_data" field of this extension SHALL contain "extension_data" field of this extension SHALL contain
"ServerNameList" where: "ServerNameList" where:
struct { struct {
NameType name_type; NameType name_type;
select (name_type) { select (name_type) {
case host_name: HostName; case host_name: HostName;
} name; } name;
} ServerName; } ServerName;
skipping to change at page 10, line 46 skipping to change at page 10, line 46
individual_certs(0), pkipath(1), (255) individual_certs(0), pkipath(1), (255)
} CertChainType; } CertChainType;
struct { struct {
CertChainType type; CertChainType type;
URLAndHash url_and_hash_list<1..2^16-1>; URLAndHash url_and_hash_list<1..2^16-1>;
} CertificateURL; } CertificateURL;
struct { struct {
opaque url<1..2^16-1>; opaque url<1..2^16-1>;
opaque padding<1>;
opaque SHA1Hash[20]; opaque SHA1Hash[20];
} URLAndHash; } URLAndHash;
Here "url_and_hash_list" contains a sequence of URLs and hashes. Here "url_and_hash_list" contains a sequence of URLs and hashes.
Each "url" MUST be an absolute URI reference according to [RFC3986] Each "url" MUST be an absolute URI reference according to [RFC3986]
that can be immediately used to fetch the certificate(s). that can be immediately used to fetch the certificate(s).
When X.509 certificates are used, there are two possibilities: When X.509 certificates are used, there are two possibilities:
- If CertificateURL.type is "individual_certs", each URL refers to a - If CertificateURL.type is "individual_certs", each URL refers to a
single DER-encoded X.509v3 certificate, with the URL for the client's
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
single DER-encoded X.509v3 certificate, with the URL for the client's
certificate first. certificate first.
- If CertificateURL.type is "pkipath", the list contains a single - If CertificateURL.type is "pkipath", the list contains a single
URL referring to a DER-encoded certificate chain, using the type URL referring to a DER-encoded certificate chain, using the type
PkiPath described in Annex A. PkiPath described in Annex A.
When any other certificate format is used, the specification that When any other certificate format is used, the specification that
describes use of that format in TLS should define the encoding format describes use of that format in TLS should define the encoding format
of certificates or certificate chains, and any constraint on their of certificates or certificate chains, and any constraint on their
ordering. ordering.
The "padding" byte MUST be 0x01. It is present to make the structure
backwards compatible.
The hash corresponding to each URL is the SHA-1 hash of the The hash corresponding to each URL is the SHA-1 hash of the
certificate or certificate chain (in the case of X.509 certificates, certificate or certificate chain (in the case of X.509 certificates,
the DER-encoded certificate or the DER-encoded PkiPath). the DER-encoded certificate or the DER-encoded PkiPath).
Note that when a list of URLs for X.509 certificates is used, the 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 ordering of URLs is the same as that used in the TLS Certificate
message (see [RFC5246], Section 7.4.2), but opposite to the order in message (see [RFC5246], Section 7.4.2), but opposite to the order in
which certificates are encoded in PkiPath. In either case, the self- which certificates are encoded in PkiPath. In either case, the self-
signed root certificate MAY be omitted from the chain, under the signed root certificate MAY be omitted from the chain, under the
assumption that the server must already possess it in order to assumption that the server must already possess it in order to
skipping to change at page 11, line 53 skipping to change at page 12, line 4
[RFC2616] to specify whether and for how long certificates or [RFC2616] to specify whether and for how long certificates or
certificate chains should be cached. certificate chains should be cached.
The TLS server is not required to follow HTTP redirects when The TLS server is not required to follow HTTP redirects when
retrieving the certificates or certificate chain. The URLs used in retrieving the certificates or certificate chain. The URLs used in
this extension SHOULD therefore be chosen not to depend on such this extension SHOULD therefore be chosen not to depend on such
redirects. redirects.
If the protocol used to retrieve certificates or certificate chains If the protocol used to retrieve certificates or certificate chains
returns a MIME-formatted response (as HTTP does), then the following returns a MIME-formatted response (as HTTP does), then the following
INTERNET-DRAFT TLS Extension Definitions
MIME Content-Types SHALL be used: when a single X.509v3 certificate MIME Content-Types SHALL be used: when a single X.509v3 certificate
is returned, the Content-Type is "application/pkix-cert" [RFC2585], is returned, the Content-Type is "application/pkix-cert" [RFC2585],
and when a chain of X.509v3 certificates is returned, the Content- and when a chain of X.509v3 certificates is returned, the Content-
Type is "application/pkix-pkipath" Annex A. Type is "application/pkix-pkipath" Annex A.
INTERNET-DRAFT TLS Extension Definitions
The server MUST check that the SHA-1 hash of the contents of the The server MUST check that the SHA-1 hash of the contents of the
object retrieved from that URL (after decoding any MIME Content- object retrieved from that URL (after decoding any MIME Content-
Transfer-Encoding) matches the given hash. If any retrieved object Transfer-Encoding) matches the given hash. If any retrieved object
does not have the correct SHA-1 hash, the server MUST abort the 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 handshake with a bad_certificate_hash_value(114) alert. This alert is
always fatal. always fatal.
Clients may choose to send either "Certificate" or "CertificateURL" Clients may choose to send either "Certificate" or "CertificateURL"
after successfully negotiating the option to send certificate URLs. after successfully negotiating the option to send certificate URLs.
The option to send a certificate is included to provide flexibility The option to send a certificate is included to provide flexibility
skipping to change at page 15, line 10 skipping to change at page 15, line 10
their selection of an appropriate certificate chain to return to the their selection of an appropriate certificate chain to return to the
client. In this event, the server SHALL include an extension of type client. In this event, the server SHALL include an extension of type
"trusted_ca_keys" in the (extended) server hello. The "trusted_ca_keys" in the (extended) server hello. The
"extension_data" field of this extension SHALL be empty. "extension_data" field of this extension SHALL be empty.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
7. Truncated HMAC 7. Truncated HMAC
Currently defined TLS cipher suites use the MAC construction HMAC Currently defined TLS cipher suites use the MAC construction HMAC
with either MD5 or SHA-1 [RFC2104] to authenticate record layer [RFC2104] to authenticate record layer communications. In TLS, the
communications. In TLS, the entire output of the hash function is entire output of the hash function is used as the MAC tag. However,
used as the MAC tag. However, it may be desirable in constrained it may be desirable in constrained environments to save bandwidth by
environments to save bandwidth by truncating the output of the hash truncating the output of the hash function to 80 bits when forming
function to 80 bits when forming MAC tags. MAC tags.
In order to negotiate the use of 80-bit truncated HMAC, clients MAY In order to negotiate the use of 80-bit truncated HMAC, clients MAY
include an extension of type "truncated_hmac" in the extended client include an extension of type "truncated_hmac" in the extended client
hello. The "extension_data" field of this extension SHALL be empty. hello. The "extension_data" field of this extension SHALL be empty.
Servers that receive an extended hello containing a "truncated_hmac" Servers that receive an extended hello containing a "truncated_hmac"
extension MAY agree to use a truncated HMAC by including an extension extension MAY agree to use a truncated HMAC by including an extension
of type "truncated_hmac", with empty "extension_data", in the of type "truncated_hmac", with empty "extension_data", in the
extended server hello. extended server hello.
skipping to change at page 19, line 28 skipping to change at page 19, line 28
11. Security Considerations 11. Security Considerations
General Security Considerations for TLS Extensions are covered in General Security Considerations for TLS Extensions are covered in
[RFC5246]. Security Considerations for particular extensions [RFC5246]. Security Considerations for particular extensions
specified in this document are given below. specified in this document are given below.
In general, implementers should continue to monitor the state of the In general, implementers should continue to monitor the state of the
art and address any weaknesses identified. 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].
11.1 Security Considerations for server_name 11.1 Security Considerations for server_name
If a single server hosts several domains, then clearly it is If a single server hosts several domains, then clearly it is
necessary for the owners of each domain to ensure that this satisfies necessary for the owners of each domain to ensure that this satisfies
their security needs. Apart from this, server_name does not appear to their security needs. Apart from this, server_name does not appear to
introduce significant security issues. introduce significant security issues.
Implementations MUST ensure that a buffer overflow does not occur, Implementations MUST ensure that a buffer overflow does not occur,
whatever the values of the length fields in server_name. whatever the values of the length fields in server_name.
11.2 Security Considerations for max_fragment_length 11.2 Security Considerations for max_fragment_length
The maximum fragment length takes effect immediately, including for The maximum fragment length takes effect immediately, including for
handshake messages. However, that does not introduce any security handshake messages. However, that does not introduce any security
complications that are not already present in TLS, since TLS requires complications that are not already present in TLS, since TLS requires
implementations to be able to handle fragmented handshake messages. implementations to be able to handle fragmented handshake messages.
Note that as described in Section 4, once a non-null cipher suite has Note that as described in Section 4, once a non-null cipher suite has
been activated, the effective maximum fragment length depends on the been activated, the effective maximum fragment length depends on the
cipher suite and compression method, as well as on the negotiated cipher suite and compression method, as well as on the negotiated
INTERNET-DRAFT TLS Extension Definitions
max_fragment_length. This must be taken into account when sizing max_fragment_length. This must be taken into account when sizing
buffers, and checking for buffer overflow. buffers, and checking for buffer overflow.
11.3 Security Considerations for client_certificate_url INTERNET-DRAFT TLS Extension Definitions
There were two major issues with this extension.
The first major issue was whether or not clients must 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, allowing the omission of certificate hashes 11.3 Security Considerations for client_certificate_url
enables functionality that is desirable in some circumstances; for
example, clients could be issued daily certificates that are stored
at a fixed URL and need not be provided to the client. However, this
enables 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. It was decided to make hashes mandatory. Hash
agility 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 Support for client_certificate_url involves the server's acting as a
involves the server's acting as a client in another URI scheme client in another URI scheme dependent protocol. The server
dependent protocol. The server therefore becomes subject to many of therefore becomes subject to many of the same security concerns that
the same security concerns that clients of the URI scheme are subject clients of the URI scheme are subject to, with the added concern that
to, with the added concern that the client can attempt to prompt the the client can attempt to prompt the server to connect to some
server to connect to some (possibly weird-looking) URL. (possibly weird-looking) URL.
In general, this issue means that an attacker might use the server to In general, this issue means that an attacker might use the server to
indirectly attack another host that is vulnerable to some security indirectly attack another host that is vulnerable to some security
flaw. It also introduces the possibility of denial of service attacks flaw. It also introduces the possibility of denial of service attacks
in which an attacker makes many connections to the server, each of in which an attacker makes many connections to the server, each of
which results in the server's attempting a connection to the target which results in the server's attempting a connection to the target
of the attack. of the attack.
Note that the server may be behind a firewall or otherwise able to Note that the server may be behind a firewall or otherwise able to
access hosts that would not be directly accessible from the public access hosts that would not be directly accessible from the public
Internet. This could exacerbate the potential security and denial of Internet. This could exacerbate the potential security and denial of
service problems described above, as well as allow the existence of service problems described above, as well as allow the existence of
internal hosts to be confirmed when they would otherwise be hidden. internal hosts to be confirmed when they would otherwise be hidden.
INTERNET-DRAFT TLS Extension Definitions
The detailed security concerns involved will depend on the URI The detailed security concerns involved will depend on the URI
schemes supported by the server. In the case of HTTP, the concerns schemes supported by the server. In the case of HTTP, the concerns
are similar to those that apply to a publicly accessible HTTP proxy 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 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 this should be addressed. In the case of FTP, attacks arise that are
similar to FTP bounce attacks. similar to FTP bounce attacks.
As a result of this issue, it is RECOMMENDED that the As a result of this issue, it is RECOMMENDED that the
client_certificate_url extension should have to be specifically client_certificate_url extension should have to be specifically
enabled by a server administrator, rather than be enabled by default. enabled by a server administrator, rather than be enabled by default.
skipping to change at page 21, line 32 skipping to change at page 21, line 5
As discussed in [RFC3986], URLs that specify ports other than the As discussed in [RFC3986], URLs that specify ports other than the
default may cause problems, as may very long URLs (which are more default may cause problems, as may very long URLs (which are more
likely to be useful in exploiting buffer overflow bugs). likely to be useful in exploiting buffer overflow bugs).
Also note that HTTP caching proxies are common on the Internet, and Also note that HTTP caching proxies are common on the Internet, and
some proxies do not check for the latest version of an object some proxies do not check for the latest version of an object
correctly. If a request using HTTP (or another caching protocol) goes correctly. If a request using HTTP (or another caching protocol) goes
through a misconfigured or otherwise broken proxy, the proxy may through a misconfigured or otherwise broken proxy, the proxy may
return an out-of-date response. return an out-of-date response.
INTERNET-DRAFT TLS Extension Definitions
11.4 Security Considerations for trusted_ca_keys 11.4 Security Considerations for trusted_ca_keys
It is possible that which CA root keys a client possesses could be It is possible that which CA root keys a client possesses could be
regarded as confidential information. As a result, the CA root key regarded as confidential information. As a result, the CA root key
indication extension should be used with care. indication extension should be used with care.
The use of the SHA-1 certificate hash alternative ensures that each The use of the SHA-1 certificate hash alternative ensures that each
certificate is specified unambiguously. As for the previous certificate is specified unambiguously. As for the previous
extension, it was not believed necessary to use both MD5 and SHA-1 extension, it was not believed necessary to use both MD5 and SHA-1
hashes. hashes.
skipping to change at page 22, line 5 skipping to change at page 21, line 29
It is possible that truncated MACs are weaker than "un-truncated" It is possible that truncated MACs are weaker than "un-truncated"
MACs. However, no significant weaknesses are currently known or MACs. However, no significant weaknesses are currently known or
expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. 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 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 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 be done off-line: in TLS, a single failed MAC guess will cause the
immediate termination of the TLS session. immediate termination of the TLS session.
INTERNET-DRAFT TLS Extension Definitions
Since the MAC algorithm only takes effect after all handshake Since the MAC algorithm only takes effect after all handshake
messages that affect extension parameters have been authenticated by messages that affect extension parameters have been authenticated by
the hashes in the Finished messages, it is not possible for an active the hashes in the Finished messages, it is not possible for an active
attacker to force negotiation of the truncated HMAC extension where attacker to force negotiation of the truncated HMAC extension where
it would not otherwise be used (to the extent that the handshake it would not otherwise be used (to the extent that the handshake
authentication is secure). Therefore, in the event that any security authentication is secure). Therefore, in the event that any security
problem were found with truncated HMAC in the future, if either the 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 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. problem into account, it would be able to veto use of this extension.
skipping to change at page 27, line 7 skipping to change at page 26, line 7
Person & email address to contact for further information: Person & email address to contact for further information:
Magnus Nystrom <magnus@rsasecurity.com> Magnus Nystrom <magnus@rsasecurity.com>
Intended usage: COMMON Intended usage: COMMON
Change controller: IESG <iesg@ietf.org> Change controller: IESG <iesg@ietf.org>
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Annex B: 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
extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The
client and server Hello extension mechanisms have been moved into RFC
5246, TLS 1.2, so this document, which is associated with RFC 5246,
includes only the handshake extension mechanisms and the specific
extensions from RFC 4366. RFC 5246 also specifies the unknown
extension error and new extension specification considerations so
that material has been removed from this document.
The Server Name extension now specifies only ASCII representation,
eliminating UTF-8.
The Client Certificate URLs extension has been changed to make the
presence of a hash mandatory.
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 Author's Address
Donald Eastlake 3rd Donald Eastlake 3rd
Stellar Switches, Inc. Stellar Switches, Inc.
155 Beaver Street 155 Beaver Street
Milford, MA 01757 USA Milford, MA 01757 USA
Tel: +1-508-634-2066 Tel: +1-508-634-2066
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
 End of changes. 24 change blocks. 
55 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/