Network Working Group S. Blake-Wilson Request for Comments: 3546 BCI Updates: 2246 M. Nystrom Category: Standards Track RSA Security D. Hopwood Independent Consultant J. Mikkeln Transactionware T. Wright Vodafone June 2003 Transport Layer Security (TLS) Extensions
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for
improvements. Plea refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Rerved.
Abstract
This document describes extensions that may be ud to add
functionality to Transport Layer Security (TLS). It provides both
generic extension mechanisms for the TLS handshake client and rver hellos, and specific extensions using the generic mechanisms.芹菜豆干
The extensions may be ud by TLS clients and rvers. The
extensions are backwards compatible - communication is possible
between TLS 1.0 clients that support the extensions and TLS 1.0
rvers that do not support the extensions, and vice versa.
Conventions ud 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 BCP 14, RFC 2119
[KEYWORDS].
Blake-Wilson, et. al. Standards Track [Page 1]
Table of Contents
1. Introduction (2)
2. General Extension Mechanisms (4)
2.1. Extended Client Hello (5)
2.2. Extended Server Hello (5)
2.3. Hello Extensions (6)
2.4. Extensions to the handshake protocol (7)
3. Specific Extensions (8)
3.1. Server Name Indication (8)
3.2. Maximum Fragment Length Negotiation (10)
3.3. Client Certificate URLs (11)
3.4. Trusted CA Indication (14)
肾宝片3.5. Truncated HMAC (15)
3.6. Certificate Status Request (16)
4. Error alerts (18)
5. Procedure for Defining New Extensions (20)
6. Security Considerations (21)
6.1. Security of rver_name (21)
6.2. Security of max_fragment_length (21)
6.3. Security of client_certificate_url (22)
6.4. Security of trusted_ca_keys (23)
6.5. Security of truncated_hmac (23)
6.6. Security of status_request (24)
7. Internationalization Considerations (24)
8. IANA Considerations (24)
9. Intellectual Property Rights (26)
10. Acknowledgments (26)
奔流不息意思11. Normative References (27)
12. Informative References (28)
13. Authors’ Address (28)
14. Full Copyright Statement (29)本位主义是什么意思
1. Introduction
This document describes extensions that may be ud to add
functionality to Transport Layer Security (TLS). It provides both
generic extension mechanisms for the TLS handshake client and rver hellos, and specific extensions using the generic mechanisms.
TLS is now ud in an increasing variety of operational environments - many of which were not envisioned when the original design criteria for TLS were determined. The extensions introduced in this document are designed to enable TLS to operate as effectively as possible in
new environments like wireless networks.
Blake-Wilson, et. al. Standards Track [Page 2]
Wireless environments often suffer from a number of constraints not
commonly prent in wired environments. The constraints may
include bandwidth limitations, computational power limitations,
memory limitations, and battery life limitations.
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 are designed to:钙缺乏
- Allow TLS clients to provide to the TLS rver the name of the
rver they are contacting. This functionality is desirable to
facilitate cure connections to rvers that host multiple
’virtual’ rvers at a single underlying network address.
- Allow TLS clients and rvers to negotiate the maximum fragment
length to be nt. This functionality is desirable as a result of memory constraints among some clients, and bandwidth constraints
among some access networks.
- Allow TLS clients and rvers to negotiate the u of client
certificate URLs. This functionality is desirable in order to
conrve memory on constrained clients.
- Allow TLS clients to indicate to TLS rvers which CA root keys
they posss. 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 rvers to negotiate the u of truncated
MACs. This functionality is desirable in order to conrve
bandwidth in constrained access networks.
- Allow TLS clients and rvers to negotiate that the rver nds
the client certificate status information (e.g., an Online
Certificate Status Protocol (OCSP) [OCSP] respon) during a TLS
我家的小白兔handshake. This functionality is desirable in order to avoid
nding a Certificate Revocation List (CRL) over a constrained
access network and therefore save bandwidth.
In order to support the extensions above, general extension
mechanisms for the client hello message and the rver hello message are introduced.
Blake-Wilson, et. al. Standards Track [Page 3]
The extensions described in this document may be ud by TLS 1.0
clients and TLS 1.0 rvers. The extensions are designed to be
backwards compatible - meaning that TLS 1.0 clients that support the extensions can talk to TLS 1.0 rvers that do not support the
extensions, and vice versa.
Backwards compatibility is primarily achieved via two considerations: - Clients typically request the u of extensions via the extended
client hello message described in Section 2.1. TLS 1.0 [TLS]
requires rvers to accept extended client hello messages, even if the rver does not "understand" the extension.
- For the specific extensions described here, no mandatory rver
respon is required when clients request extended functionality. Note however, that although backwards compatibility is supported,
some constrained clients may be forced to reject communications with rvers that do not support the extensions as a result of the limited capabilities of such clients.
The remainder of this document is organized as follows. Section 2
describes general extension mechanisms for the client hello and
rver hello handshake messages. Section 3 describes specific
extensions to TLS 1.0. Section 4 describes new error alerts for u with the TLS extensions. The final ctions of the document address IPR, curity considerations, registration of the application/pkix-
pkipath MIME type, acknowledgements, and references.
2. General Extension Mechanisms
我是丑小鸭This ction prents general extension mechanisms for the TLS
handshake client hello and rver hello messages.
The general extension mechanisms are necessary in order to enable
clients and rvers to negotiate whether to u specific extensions, and how to u specific extensions. The extension formats described are bad on [MAILING LIST].
Section 2.1 specifies the extended client hello message format,
Section 2.2 specifies the extended rver hello message format, and
Section 2.3 describes the actual extension format ud with the
extended client and rver hellos.
Blake-Wilson, et. al. Standards Track [Page 4]
2.1. Extended Client Hello
Clients MAY request extended functionality from rvers by nding
the extended client hello message format in place of the client hello message format. The extended client hello message format is:
struct {
ProtocolVersion client_version;
Random random;
SessionID ssion_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>;
} ClientHello;
Here the new "client_hello_extension_list" field contains a list of
佛陀的故事
extensions. The actual "Extension" format is defined in Section 2.3. In the event that a client requests additional functionality using
the extended client hello, and this functionality is not supplied by the rver, the client MAY abort the handshake.
Note that [TLS], Section 7.4.1.2, allows additional information to be added to the client hello message. Thus the u of the extended
client hello defined above should not "break" existing TLS 1.0
rvers.
A rver that supports the extensions mechanism MUST accept only
client hello messages in either the original or extended ClientHello format, and (as for all other messages) MUST check that the amount of data in the message precily matches one of the formats; if not
then it MUST nd a fatal "decode_error" alert. This overrides the
"Forward compatibility note" in [TLS].
2.2. Extended Server Hello
The extended rver hello message format MAY be nt in place of the rver hello message when the client has requested extended
functionality via the extended client hello message specified in
Section 2.1. The extended rver hello message format is:
Blake-Wilson, et. al. Standards Track [Page 5]
struct {
ProtocolVersion rver_version;
Random random;
SessionID ssion_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
Extension rver_hello_extension_list<0..2^16-1>;
} ServerHello;
Here the new "rver_hello_extension_list" field contains a list of
extensions. The actual "Extension" format is defined in Section 2.3. Note that the extended rver hello message is only nt in respon to an extended client hello message. This prevents the possibility
that the extended rver hello message could "break" existing TLS 1.0 clients.
2.3. Hello Extensions
The extension format for extended client hellos and extended rver
hellos is:
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
Here:
- "extension_type" identifies the particular extension type.
- "extension_data" contains information specific to the particular
extension type.
The extension types defined in this document are:
enum {
rver_name(0), max_fragment_length(1),
client_certificate_url(2), trusted_ca_keys(3),
truncated_hmac(4), status_request(5), (65535)
} ExtensionType;
Note that for all extension types (including tho defined in
future), the extension type MUST NOT appear in the extended rver
hello unless the same extension type appeared in the corresponding
client hello. Thus clients MUST abort the handshake if they receive an extension type in the extended rver hello that they did not
request in the associated (extended) client hello.
Blake-Wilson, et. al. Standards Track [Page 6]
