draft-ietf-tls-rfc4366-bis-03.txt   draft-ietf-tls-rfc4366-bis-04.txt 
TLS Working Group Donald Eastlake 3rd TLS Working Group Donald Eastlake 3rd
INTERNET-DRAFT Eastlake Enterprises INTERNET-DRAFT Stellar Switches
Obsoletes: RFC 4366 Obsoletes: RFC 4366
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: April 4, 2009 October 5, 2008 Expires: October 19, 2009 April 20, 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-03.txt>
Status of This Document Status of This Document
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. 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
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the TLS working group mailing list <tls@ietf.org>. to the TLS working group mailing list <tls@ietf.org>.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
Abstract Abstract
This document provides documentation for existing specific TLS This document provides specifications for existing TLS extensions. It
extensions. It is a companion document for the TLS 1.2 specification is a companion document for the TLS 1.2 specification [RFC5246]. The
[RFC5246]. The extensions specified are server_name, extensions specified are server_name, max_fragment_length,
max_fragment_length, client_certificate_url, trusted_ca_keys, client_certificate_url, trusted_ca_keys, truncated_hmac, and
truncated_hmac, and status_request. status_request.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Acknowledgements Acknowledgements
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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1 Abstract...................................................1
Acknowledgements...........................................2 Acknowledgements...........................................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...........22
12. Normative References..................................23 12. Normative References..................................23
13. Informative References................................23 13. Informative References................................23
Annex A: pkipath MIME Type Registration...................25
Copyright, Disclaimer, and Additional IPR Provisions......27 Annex A: pkipath MIME Type Registration...................25
Author's Address..........................................28 Author's Address..........................................27
Expiration and File Name..................................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
Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the
allocation of new extension code points; however, it does not specify allocation of new extension code points; however, it does not specify
skipping to change at page 10, line 39 skipping to change at page 10, line 39
After negotiation of the use of client certificate URLs has been After negotiation of the use of client certificate URLs has been
successfully completed (by exchanging hellos including successfully completed (by exchanging hellos including
"client_certificate_url" extensions), clients MAY send a "client_certificate_url" extensions), clients MAY send a
"CertificateURL" message in place of a "Certificate" message as "CertificateURL" message in place of a "Certificate" message as
follows (see also Section 2): follows (see also Section 2):
enum { enum {
individual_certs(0), pkipath(1), (255) individual_certs(0), pkipath(1), (255)
} CertChainType; } CertChainType;
enum {
false(0), true(1)
} Boolean;
struct { struct {
CertChainType type; CertChainType type;
URLAndOptionalHash 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>;
Boolean hash_present;
select (hash_present) {
case false: struct {};
case true: SHA1Hash;
} hash;
} URLAndOptionalHash;
INTERNET-DRAFT TLS Extension Definitions
opaque SHA1Hash[20]; opaque SHA1Hash[20];
} URLAndHash;
Here "url_and_hash_list" contains a sequence of URLs and optional Here "url_and_hash_list" contains a sequence of URLs and hashes.
hashes. Each "url" MUST be an absolute URI reference according to Each "url" MUST be an absolute URI reference according to [RFC3986]
[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 single DER-encoded X.509v3 certificate, with the URL for the client's
INTERNET-DRAFT TLS Extension Definitions
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 hash corresponding to each URL at the client's discretion either The hash corresponding to each URL is the SHA-1 hash of the
is not present or is the SHA-1 hash of the certificate or certificate certificate or certificate chain (in the case of X.509 certificates,
chain (in the case of X.509 certificates, the DER-encoded certificate the DER-encoded certificate or the DER-encoded PkiPath).
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
validate it. validate it.
Servers receiving "CertificateURL" SHALL attempt to retrieve the Servers receiving "CertificateURL" SHALL attempt to retrieve the
client's certificate chain from the URLs and then process 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 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 in the chain MAY be used, provided that the SHA-1 hash matches the
that URL and it matches the hash of the cached copy. hash of the cached copy.
Servers that support this extension MUST support the 'http' URI Servers that support this extension MUST support the 'http' URI
scheme for certificate URLs, and MAY support other schemes. Use of scheme for certificate URLs, and MAY support other schemes. Use of
other schemes than 'http', 'https', or 'ftp' may create unexpected other schemes than 'http', 'https', or 'ftp' may create unexpected
problems. problems.
If the protocol used is HTTP, then the HTTP server can be configured If the protocol used is HTTP, then the HTTP server can be configured
to use the Cache-Control and Expires directives described in to use the Cache-Control and Expires directives described in
[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.
INTERNET-DRAFT TLS Extension Definitions
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
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.
If a SHA-1 hash is present for an URL, then the server MUST check INTERNET-DRAFT TLS Extension Definitions
that the SHA-1 hash of the contents of the object retrieved from that
URL (after decoding any MIME Content-Transfer-Encoding) matches the The server MUST check that the SHA-1 hash of the contents of the
given hash. If any retrieved object does not have the correct SHA-1 object retrieved from that URL (after decoding any MIME Content-
hash, the server MUST abort the handshake with a Transfer-Encoding) matches the given hash. If any retrieved object
bad_certificate_hash_value(114) alert. This alert is always fatal. 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" 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
to clients possessing multiple certificates. to clients possessing multiple certificates.
If a server encounters an unreasonable delay in obtaining If a server encounters an unreasonable delay in obtaining
certificates in a given CertificateURL, it SHOULD time out and signal certificates in a given CertificateURL, it SHOULD time out and signal
a certificate_unobtainable(111) error alert. This alert MAY be fatal; a certificate_unobtainable(111) error alert. This alert MAY be fatal;
for example, if client authentication is required by the server for for example, if client authentication is required by the server for
skipping to change at page 20, line 12 skipping to change at page 20, line 12
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 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 11.3 Security Considerations for client_certificate_url
There are two major issues with this extension. There were two major issues with this extension.
The first major issue is whether or not clients should include The first major issue was whether or not clients must include
certificate hashes when they send certificate URLs. certificate hashes when they send certificate URLs.
When client authentication is used *without* the When client authentication is used *without* the
client_certificate_url extension, the client certificate chain is client_certificate_url extension, the client certificate chain is
covered by the Finished message hashes. The purpose of including covered by the Finished message hashes. The purpose of including
hashes and checking them against the retrieved certificate chain is hashes and checking them against the retrieved certificate chain is
to ensure that the same property holds when this extension is used, to ensure that the same property holds when this extension is used,
i.e., that all of the information in the certificate chain retrieved i.e., that all of the information in the certificate chain retrieved
by the server is as the client intended. by the server is as the client intended.
On the other hand, omitting certificate hashes enables functionality On the other hand, allowing the omission of certificate hashes
that is desirable in some circumstances; for example, clients can be enables functionality that is desirable in some circumstances; for
issued daily certificates that are stored at a fixed URL and need not example, clients could be issued daily certificates that are stored
be provided to the client. Clients that choose to omit certificate at a fixed URL and need not be provided to the client. However, this
hashes should be aware of the possibility of an attack in which the enables an attack in which the attacker obtains a valid certificate
attacker obtains a valid certificate on the client's key that is on the client's key that is different from the certificate the client
different from the certificate the client intended to provide. intended to provide. It was decided to make hashes mandatory. Hash
Although TLS uses both MD5 and SHA-1 hashes in several other places, agility was not believed to be necessary here. The property required
this was not believed to be necessary here. The property required of of SHA-1 is second pre-image resistance.
SHA-1 is second pre-image resistance.
The second major issue is that support for client_certificate_url The second major issue is that support for client_certificate_url
involves the server's acting as a client in another URI scheme involves the server's acting as a client in another URI scheme
dependent protocol. The server therefore becomes subject to many of dependent protocol. The server therefore becomes subject to many of
the same security concerns that clients of the URI scheme are subject the same security concerns that clients of the URI scheme are subject
to, with the added concern that the client can attempt to prompt the to, with the added concern that the client can attempt to prompt the
server to connect to some (possibly weird-looking) URL. server to connect to some (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
skipping to change at page 27, line 7 skipping to change at page 27, 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
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.
INTERNET-DRAFT TLS Extension Definitions
Author's Address Author's Address
Donald Eastlake 3rd Donald Eastlake 3rd
Eastlake Enterprises 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
Expiration and File Name INTERNET-DRAFT TLS Extension Definitions
This draft expires in April 2009. Copyright and IPR Provisions
Its file name is draft-ietf-tls-rfc4366-bis-03.txt. Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions. For
the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
 End of changes. 30 change blocks. 
108 lines changed or deleted 60 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/