draft-ietf-tls-rfc4366-bis-07.txt   draft-ietf-tls-rfc4366-bis-08.txt 
TLS Working Group Donald Eastlake 3rd TLS Working Group Donald Eastlake 3rd
INTERNET-DRAFT Stellar Switches INTERNET-DRAFT Stellar Switches
Obsoletes: 4366 Obsoletes: 4366
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: November 13, 2010 May 14, 2010 Expires: November 29, 2010 May 30, 2010
Transport Layer Security (TLS) Extensions: Extension Definitions Transport Layer Security (TLS) Extensions: Extension Definitions
<draft-ietf-tls-rfc4366-bis-07.txt> <draft-ietf-tls-rfc4366-bis-08.txt>
Abstract Abstract
This document provides specifications for existing TLS extensions. It This document provides specifications for existing TLS extensions. It
is a companion document for the TLS 1.2 specification [RFC5246]. The is a companion document for the TLS 1.2 specification [RFC5246]. The
extensions specified are server_name, max_fragment_length, extensions specified are server_name, max_fragment_length,
client_certificate_url, trusted_ca_keys, truncated_hmac, and client_certificate_url, trusted_ca_keys, truncated_hmac, and
status_request. status_request.
Status of This Memo Status of This Memo
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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
1. Introduction............................................4 1. Introduction............................................4
1.1 Specific Extensions Covered............................4 1.1 Specific Extensions Covered............................4
1.2 Conventions Used in This Document......................5 1.2 Conventions Used in This Document......................6
2. Extensions to the Handshake Protocol....................6 2. Extensions to the Handshake Protocol....................7
3. Server Name Indication..................................7 3. Server Name Indication..................................8
4. Maximum Fragment Length Negotiation.....................9 4. Maximum Fragment Length Negotiation....................10
5. Client Certificate URLs................................11 5. Client Certificate URLs................................12
6. Trusted CA Indication..................................14 6. Trusted CA Indication..................................15
7. Truncated HMAC.........................................16 7. Truncated HMAC.........................................17
8. Certificate Status Request.............................17 8. Certificate Status Request.............................18
9. Error Alerts...........................................19 9. Error Alerts...........................................20
10. IANA Considerations...................................20
11. Security Considerations...............................20 10. IANA Considerations...................................21
11.1 Security Considerations for server_name..............20 11. Security Considerations...............................21
11.2 Security Considerations for max_fragment_length......20 11.1 Security Considerations for server_name..............21
11.3 Security Considerations for client_certificate_url...21 11.2 Security Considerations for max_fragment_length......21
11.4 Security Considerations for trusted_ca_keys..........22 11.3 Security Considerations for client_certificate_url...22
11.5 Security Considerations for truncated_hmac...........22 11.4 Security Considerations for trusted_ca_keys..........23
11.6 Security Considerations for status_request...........23 11.5 Security Considerations for truncated_hmac...........23
11.6 Security Considerations for status_request...........24
12. Normative References..................................24 12. Normative References..................................25
13. Informative References................................24 13. Informative References................................25
Annex A: pkipath MIME Type Registration...................26 Annex A: pkipath MIME Type Registration...................27
Annex B: Changes from RFC 4366............................28 Annex B: Changes from RFC 4366............................29
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 5, line 31 skipping to change at page 5, line 31
TLS clients and servers may use the extensions described in this TLS clients and servers may use the extensions described in this
document. The extensions are designed to be backwards compatible, document. The extensions are designed to be backwards compatible,
meaning that TLS clients that support the extensions can talk to TLS meaning that TLS clients that support the extensions can talk to TLS
servers that do not support the extensions, and vice versa. servers that do not support the extensions, and vice versa.
Note that any messages associated with these extensions that are sent Note that any messages associated with these extensions that are sent
during the TLS handshake MUST be included in the hash calculations during the TLS handshake MUST be included in the hash calculations
involved in "Finished" messages. involved in "Finished" messages.
Note also that all the extensions defined in this section are Note also that all the extensions defined in this section are
relevant only when a session is initiated. When a client includes relevant only when a session is initiated. A client that requests
one or more of the defined extension types in an extended client session resumption does not in general know whether the server will
hello while requesting session resumption: accept this request, and therefore it SHOULD send the same extensions
as it would send if it were not attempting resumption. When a client
includes one or more of the defined extension types in an extended
client hello while requesting session resumption:
- The server name indication extension MAY be used by the server
when deciding whether or not to resume a session as described
in section 3.
- If the resumption request is denied, the use of the extensions - If the resumption request is denied, the use of the extensions
is negotiated as normal. is negotiated as normal.
- If, on the other hand, the older session is resumed, then the - If, on the other hand, the older session is resumed, then the
server MUST ignore the extensions and send a server hello server MUST ignore the extensions and send a server hello
containing none of the extension types. In this case, the containing none of the extension types. In this case, the
functionality of these extensions negotiated during the functionality of these extensions negotiated during the
original session initiation is applied to the resumed session. original session initiation is applied to the resumed session.
INTERNET-DRAFT TLS Extension Definitions
1.2 Conventions Used in This Document 1.2 Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in RFC 2119.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
2. Extensions to the Handshake Protocol 2. Extensions to the Handshake Protocol
This document specifies the use of two new handshake messages, This document specifies the use of two new handshake messages,
"CertificateURL" and "CertificateStatus". These messages are "CertificateURL" and "CertificateStatus". These messages are
described in Section 5 and Section 8, respectively. The new described in Section 5 and Section 8, respectively. The new
handshake message structure therefore becomes: handshake message structure therefore becomes:
skipping to change at page 8, line 23 skipping to change at page 9, line 23
supported name type. supported name type.
A server that receives a client hello containing the "server_name" A server that receives a client hello containing the "server_name"
extension MAY use the information contained in the extension to guide extension MAY use the information contained in the extension to guide
its selection of an appropriate certificate to return to the client, its selection of an appropriate certificate to return to the client,
and/or other aspects of security policy. In this event, the server and/or other aspects of security policy. In this event, the server
SHALL include an extension of type "server_name" in the (extended) SHALL include an extension of type "server_name" in the (extended)
server hello. The "extension_data" field of this extension SHALL be server hello. The "extension_data" field of this extension SHALL be
empty. empty.
When the server resumes a session, the server_name extension is When the server is deciding whether or not to accept a request to
ignored. resume a session, the contents of a server_name extension MAY be used
in the lookup of the session in the session cache. The client SHOULD
include the same server_name extension in session resumption request
as it did in the full handshake that established the session. A
server that implements this extension MUST NOT accept the request to
resume the session if the server_name extension contains a different
name. Instead, it proceeds with a full handshake to establish a new
session. When resuming a session, the server MUST NOT include a
server_name extension in the server hello.
If an application negotiates a server name using an application If an application negotiates a server name using an application
protocol and then upgrades to TLS, and if a server_name extension is protocol and then upgrades to TLS, and if a server_name extension is
sent, then the extension SHOULD contain the same name that was sent, then the extension SHOULD contain the same name that was
negotiated in the application protocol. If the server_name is negotiated in the application protocol. If the server_name is
established in the TLS session handshake, the client SHOULD NOT established in the TLS session handshake, the client SHOULD NOT
attempt to request a different server name at the application layer. attempt to request a different server name at the application layer.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
skipping to change at page 24, line 54 skipping to change at page 26, line 5
[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366,
April 2006. April 2006.
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
"Information Systems - Open Systems Interconnection - The Directory: "Information Systems - Open Systems Interconnection - The Directory:
Public key and attribute certificate frameworks." Public key and attribute certificate frameworks."
[X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC
9594:8:2001. 9594:8:2001.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Annex A: pkipath MIME Type Registration Annex A: pkipath MIME Type Registration
skipping to change at page 28, line 24 skipping to change at page 29, line 24
extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The
client and server Hello extension mechanisms have been moved into RFC client and server Hello extension mechanisms have been moved into RFC
5246, TLS 1.2, so this document, which is associated with RFC 5246, 5246, TLS 1.2, so this document, which is associated with RFC 5246,
includes only the handshake extension mechanisms and the specific includes only the handshake extension mechanisms and the specific
extensions from RFC 4366. RFC 5246 also specifies the unknown extensions from RFC 4366. RFC 5246 also specifies the unknown
extension error and new extension specification considerations so extension error and new extension specification considerations so
that material has been removed from this document. that material has been removed from this document.
The Server Name extension now specifies only ASCII representation, The Server Name extension now specifies only ASCII representation,
eliminating UTF-8. It is provided that the ServerNameList can contain eliminating UTF-8. It is provided that the ServerNameList can contain
more only one name of any particular name_type. more only one name of any particular name_type. Provision was added
for the user using the server_name extension in deciding whether or
not to resume a session. Furthermores, this extensions should be the
same in a session resumption request as it was in the full handshake
that established the session. Such a resumption request must not be
accepted if the server_name extension is different but instead a full
handshake must be done to possibly establish a new session.
The Client Certificate URLs extension has been changed to make the The Client Certificate URLs extension has been changed to make the
presence of a hash mandatory. presence of a hash mandatory.
For the case of DTLS, the requirement to report an overflow of the For the case of DTLS, the requirement to report an overflow of the
negotiated maximum fragment length is made conditional on passing negotiated maximum fragment length is made conditional on passing
authentication. authentication.
The material was also re-organized in minor ways. For example, The material was also re-organized in minor ways. For example,
information as to which errors are fatal is moved from the one "Error information as to which errors are fatal is moved from the one "Error
skipping to change at page 29, line 14 skipping to change at page 30, line 14
INTERNET-DRAFT TLS Extension Definitions 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-333-2270
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Copyright and IPR Provisions Copyright and IPR Provisions
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
 End of changes. 15 change blocks. 
33 lines changed or deleted 55 lines changed or added

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