TLS Working Group Simon Blake-Wilson, Certicom
INTERNET-DRAFT Magnus Nystrom, RSA Security
Expires May 16, 2001 November 17, 2000
Wireless Extensions to TLS
<draft-ietf-tls-wireless-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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 made obsolete 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 may be found at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories may be found at
http://www.ietf.org/shadow.html.
Abstract
This document suggests extensions to TLS designed to make TLS more
amenable to use within wireless environments. The extensions may be
used by TLS clients and servers. The extensions are backwards
compatible - communication is possible between TLS 1.0 clients
that support the extensions and TLS 1.0 servers that do not
support the extensions, and vice versa.
The document suggests extensions of two types: generic extension
mechanisms for the TLS client and server hellos, and specific
extensions using these generic mechanisms. It is hoped that the
structure of the document will allow each suggested extension to be
evaluated independently.
This document is based on discussions at the TLS working group
meeting during the Pittsburgh IETF meeting, and on discussions
within the WAP security group.
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 RFC 2119.
Please send comments on this document to the TLS mailing list.
Blake-Wilson, Nystrom [Page 1]
INTERNET-DRAFT 17 November 2000
Table of Contents
1. Introduction ............................................... 2
2. General Extension Mechanisms ............................... 4
2.1. Extended Client Hello .................................... 4
2.2. Extended Server Hello .................................... 4
2.3. Hello Extensions ......................................... 5
3. Wireless Extensions ........................................ 6
3.1. Maximum Record Size Negotiation .......................... 6
3.2. Client Certificate URLs .................................. 7
3.3. Trusted CA Indication .................................... 8
3.4. Small Session Identifiers ................................ 9
3.5. Truncated MACs .......................................... 10
3.6. OCSP .................................................... 11
4. Security Considerations ................................... 12
5. Intellectual Property Rights .............................. 12
6. Acknowledgments ........................................... 12
7. References ................................................ 12
8. Authors' Addresses ........................................ 13
1. Introduction
Wireless environments often suffer from a number of constraints not
commonly present in wired environments - these constraints may include
bandwidth limitations, computational power limitations, memory
limitations, and battery life limitations.
Use within wireless environments was not one of the initial design
criteria of the TLS protocol. As a result, implementations of TLS
within wireless environments face a number of challenges.
This document specifies extensions to the TLS 1.0 protocol designed to
make TLS more amenable to use within wireless environments. The
extensions described here focus on extending the functionality provided
by the TLS protocol message formats. Other issues, such as the addition
of "wireless-friendly" cipher suites, are deferred.
Specifically, the extensions described in this document are designed
to:
- Allow TLS clients and servers to negotiate the maximum record size to
be sent. This functionality is desirable as a result of memory
constraints common among wireless clients, and bandwidth constraints
common among wireless networks.
- Allow TLS clients and servers to negotiate the use of client
certificate URLs. This functionality is desirable in order to
conserve memory on wireless clients.
Blake-Wilson, Nystrom [Page 2]
INTERNET-DRAFT 17 November 2000
- 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 which are only able to store
a small number of CA root keys due to memory limitations.
- Encourage TLS servers to use small session identifiers. This
functionality is desirable in order to conserve memory on wireless
clients.
- Allow TLS clients and servers to negotiate the use of truncated MACs.
This functionality is desirable in order to conserve bandwidth in
wireless networks.
- Allow TLS clients and servers to negotiate that the server sends the
client an OCSP response during a TLS handshake. This functionality is
desirable in order to avoid sending a CRL over a wireless network and
therefore save bandwidth.
In order to support the extensions above, general extension mechanisms
for the client hello message and the server hello message are
introduced.
The extensions described in this document may be used by TLS 1.0
clients and TLS 1.0 servers. The extensions are designed to be
backwards compatible - meaning that TLS 1.0 clients that support the
extensions can talk to TLS 1.0 servers that do not support the
extensions, and vice versa.
Backwards compatibility is primarily achieved via two considerations:
- Clients typically request the use of extensions via the extended
client hello message described in Section 2.1. TLS 1.0 [TLS] requires
servers to "accept" extended client hello messages, even if the server
does not "understand" the extension.
- For the specific extensions described here, no mandatory server
response is required when clients request extended functionality.
Note however, that although backwards compatibility is supported, some
wireless clients may be forced to reject communications with servers
that do not support the extensions as a result of the limited
capabilities of the wireless clients.
The remainder of this document is organized as follows. Section 2
describes general extension mechanisms for the client hello and server
hello handshake messages. Section 3 describes specific extensions to
TLS 1.0. The final sections of the document address IPR, security
considerations, acknowledgements, and references.
Blake-Wilson, Nystrom [Page 3]
INTERNET-DRAFT 17 November 2000
2. General Extension Mechanisms
This section presents general extension mechanisms for the TLS
handshake client hello and server hello messages.
These general extension mechanisms are necessary in order to enable
clients and servers to negotiate whether to use specific extensions,
and how to use specific extensions. The extension formats described are
based on [MAILING LIST].
Section 2.1 specifies the extended client hello message format, Section
2.2 specifies the extended server hello message format, and Section 2.3
describes the actual extension format used with the extended client and
server hellos.
2.1. Extended Client Hello
The extended client hello message format MAY be sent in place of the
client hello message format when clients wish to request extended
functionality from servers. The extended client hello message format is:
struct {
ProtocolVersion client_version;
Random random;
SessionID session_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 clients request additional functionality using the
extended client hello, and this functionality is not supplied by the
server, clients 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 use of the extended client
hello defined above should not "break" existing TLS 1.0 servers.
2.2. Extended Server Hello
The extended server hello message format MAY be sent in place of the
server hello message when the client has requested extended
functionality via the extended client hello message specified in
Section 2.1. The extended server hello message format is:
Blake-Wilson, Nystrom [Page 4]
INTERNET-DRAFT 17 November 2000
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
Extension server_hello_extension_list<0..2^16-1>;
} ServerHello;
Here the new "server_hello_extension_list" field contains a list of
extensions. The actual "Extension" format is defined in Section 2.3.
Note that the extended server hello message is only sent in response to
an extended client hello message. This prevents the possibility that
the extended server hello message could "break" existing TLS 1.0
clients.
2.3. Hello Extensions
The extension format for extended client hellos and extended server
hellos is:
struct {
ExtensionType extensionType;
opaque unknown_extension<0..2^16-1>;
} Extension;
Here:
- "extensionType" identifies the particular extension type.
- "unknown_extension" contains information specific to the particular
extension type.
The extension types defined in this document are:
enum {
reserved(0), max_record_size(1),
client_certificate_url(2), trusted_key_ids(3),
truncated_MAC(4), status_request(5), (65535)
} ExtensionType;
Note that for all the extension types defined in this document, the
extension type should appear in the extended server hello only if 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 server hello that they did not request in the associated
(extended) client hello.
Blake-Wilson, Nystrom [Page 5]
INTERNET-DRAFT 17 November 2000
Also note that when multiple extensions are present in the extended
client hello or the extended server hello, the extensions must appear
in the order identified in "ExtensionType". Thus clients and servers
MUST abort the handshake if they receive an extended hello message in
which the extensions are not in the correct order.
Finally note that it is possible to alternatively define
"unknown_extension" using a selection on "extensionType" (instead of
just defining it as type "opaque"). This approach appears to have pros
and cons - using a selection is more restrictive and thus less prone to
implementation errors, but using "opaque" ensures inclusion of the
length and thus ensures that users can skip extensions they don't
understand. We would particularly welcome comments on this issue.
3. Wireless Extensions
This section describes the specific TLS extensions specified in this
document.
Note that any messages associated with these extensions that is sent
during the TLS handshake MUST be included in the hash calculations
involved in "Finished" messages.
Section 3.1 describes the extension of TLS to provide maximum record
size negotiation. Section 3.2 describes the extension to allow client
certificate URLs. Section 3.3 describes the extension to allow clients
to indicate which CA root keys they possess. Section 3.4 describes the
extension to restrict the size of session identifiers. Section 3.5
describes the extension to allow the use of truncated MACs. Section 3.6
describes the extension to support integration of OCSP into TLS
handshakes.
3.1. Maximum Record Size Negotiation
TLS specifies a fixed maximum record size of 2^14 bytes. It may be
desirable for wireless clients to negotiate a smaller maximum record
size due to memory limitations or bandwidth limitations.
In order to negotiate smaller maximum record sizes, clients MAY include
an extension of type "max_record_size" in the (extended) client hello.
The "unknown-extension" field of this extension shall contain:
enum{
2^8(1), 2^9(2), 2^10(3), 2^11(4), 2^12(5), (255)
} Negotiated_max_record_size ;
whose value is the desired maximum record size. The allowed values for
this field are: 2^8, 2^9, 2^10, 2^11, and 2^12.
Blake-Wilson, Nystrom [Page 6]
INTERNET-DRAFT 17 November 2000
Servers that receive an extended client hello containing a
"max_record_size" extension, MAY accept the requested maximum record
size by including an extension of type "max_record_size" in the
(extended) server hello. The "unknown_extension" field of this
extension shall contain "Negotiated_max_record_size" whose value is the
same as the requested maximum record size.
Servers receiving maximum record size negotiation requests for values
other than the allowed values MUST abort the handshake. Similarly,
clients receiving maximum record size negotiation responses that differ
from the size they requested MUST also abort the handshake.
Once a maximum record size other than 2^14 has been successfully
negotiated during a TLS handshake, both the client and server pass the
negotiated maximum record size value to the TLS record layer along with
the negotiated security parameters. (Note that it may be desirable in
the future to update the TLS security parameters to include the maximum
record size value.) During the subsequent session after exchange of
change cipher spec messages, the client and server MUST ensure that no
messages larger than the negotiated size are sent.
3.2. Client Certificate URLs
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 wireless clients to send a certificate URL in
place of a certificate so that they do not need to store their
certificate and can therefore save memory.
In order to negotiate to send a certificate URL to a server, clients
MAY include an extension of type "client_certificate_url" in the
(extended) client hello. The "unknown_extension" field of this
extension shall be empty.
(Note that it is necessary to negotiate use of a client certificate URL
in order to avoid "breaking" existing TLS 1.0 servers.)
Servers that receive an extended client hello containing a
"client_certificate_url" extension, MAY indicate that they are willing
to accept a certificate URL by including an extension of type
"client_certificate_url" in the (extended) server hello. The
"unknown_extension" field of this extension shall be empty.
After negotiation of the use of a client certificate URL has been
successfully completed (by exchanging hellos including
"client_certificate_url" extensions), clients send a "CertificateorURL"
message in place of a "Certificate" message:
Blake-Wilson, Nystrom [Page 7]
INTERNET-DRAFT 17 November 2000
struct{
Certificate_or_URL certificate_transport_type;
select (Certificate_or_URL) {
case certificate:
ASN.1Cert certificate_list<0..2^24-1>;
case url:
opaque url<0..2^8-1>;
} certificate_transport_body;
} CertificateorURL;
enum{ certificate(1), url(2), (255) } Certificate_or_URL ;
(Nevertheless, the handshake message is identified as being of type
"certificate".)
Here:
- "certificate_transport_type" indicates whether a certificate chain or
URL is being sent.
- "certificate_transport_body" contains either a certificate chain, or
a certificate URL.
Servers receiving "CertificateorURL" shall attempt to retrieve the
client's certificate chain from the URL (if necessary), and then process the
certificate chain as usual.
Note that "CertificateorURL" allows the client to send either a
certificate or a URL. The option to send a certificate, even after
successfully negotiating the possibility to send a URL, is included to
provide flexibility to clients possessing multiple certificates.
3.3. Trusted CA Indication
Wireless clients which, 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_key_ids" in the (extended) client
hello. The "unknown_extension" field of this extension shall contain
"TrustedAuthorities" where:
TrustedAuthority TrustedAuthorities<0..2^16-1>;
Blake-Wilson, Nystrom [Page 8]
INTERNET-DRAFT 17 November 2000
struct {
IdentifierType identifier_type;
select (identifier_type) {
case null: struct {};
case key_hash_sha: KeyHash;
case x509_name: DistinguishedName;
} identifier;
} TrustedAuthority;
enum { null(0), key_hash_sha(1), x509_name(2),(255)}
IdentifierType;
opaque DistinguishedName<1..2^16-1>;
opaque KeyHash[20];
Here "TrustedAuthorities" provides a list of CA root key identifiers
that the client possesses. Each CA root key is identified via either:
- "null" - no CA root key identity supplied.
- "key_hash_sha" - contains the SHA-1 hash of the CA root key. (For DSA
and ECDSA keys, this is the hash of the "subjectPublicKey" value. For
RSA keys, this is the hash of the byte string representation of the
modulus.)
- "x509_name" - contains the X.509 distinguished name of the CA.
Note that clients may include none, some, or all of the CA root keys
they possess in this extension.
(The option to include no CA root keys is included both to maintain
syntactical similarity with Section 3.6, and 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_key_ids"
extension, MAY use the information contained in the extension to guide
their selection of an appropriate certificate chain to return to the
client.
3.4. Small Session Identifiers
TLS specifies that session identifiers can be up to 32 bytes in length.
In order to save memory, it is desirable to restrict the size of
session identifiers which are stored by wireless clients.
The syntax used by TLS for session identifiers is:
opaque SessionID<0..32>;
Blake-Wilson, Nystrom [Page 9]
INTERNET-DRAFT 17 November 2000
In order to encourage use of small session identifiers, servers SHOULD
select session identifiers whose length is 8 bytes or less.
3.5. Truncated MACs
TLS uses the MAC construction HMAC with either MD5 or SHA-1 [HMAC] 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 wireless environments to save bandwidth by truncating the output of
the hash function when forming MAC tags.
In order to negotiate the use of truncated MACs, clients MAY include an
extension of type "truncated_MAC" in the extended client hello. The
"unknown_extension" field of this extension shall contain
"MACTruncations", where:
MACTruncation MACTruncations<0..2^8-1>;
struct {
MACAlgorithm mac_type;
uint16 trucation_size_in_bits
} MACTruncation;
enum { null(0), md5(1), sha1(2), (255) } MACAlgorithm;
Here "MACTruncations" contains a list of MAC truncation sizes suggested
by the client. Allowed values for suggested truncation sizes are: for
HMAC-with-SHA1 ("sha1") - 80 bits; and for HMAC-with-MD5 ("md5") - 80
bits.
Servers that receive an extended hello containing a "truncated_MAC"
extension, MAY agree to use a truncated MAC by including an extension
of type "truncated_MAC" in the extended server hello. The
"unknown_extension" field of this extension shall contain
"MACTruncation". Here "MACTruncation" shall contain the agreed MAC
truncation size, select from the list suggested by the client. Note
that the "MACAlgorithm" identified in "MACTruncation" must match the
MAC used by the established cipher suite.
Servers receiving MAC truncation negotiation requests requesting values
other than the allowed values, MUST abort the handshake. Similarly
clients receiving MAC truncation negotiation responses that differ from
the values they suggested, or that do not match the established cipher
suite, MUST abort the handshake.
Once MAC truncation has been successfully negotiated during a TLS
handshake, both the client and the server pass the negotiated
truncation size to the TLS record layer along with the other negotiated
security parameters. Subsequently during the session, clients and
Blake-Wilson, Nystrom [Page 10]
INTERNET-DRAFT 17 November 2000
servers MUST use truncated MACs. (Truncated MACs are calculated as
specified in [HMAC].)
3.6. OCSP
Wireless clients may wish to use OCSP [OCSP] to check the validity of
server certificates, in order to avoid transmission of CRLs and
therefore save bandwidth on wireless networks.
In order to indicate their desire to use OCSP, clients MAY include an
extension of type "status_request" in the (extended) client hello. The
"unknown_extension" field of this extension shall contain
"TrustedAuthorities" as defined in Section 3.3.
Here "TrustedAuthorities" provides a list of OCSP responders that the
client trusts. The "null" alternative in "TrustedAuthorities" can be
used to indicate that the responders are implicitly known to the server
- e.g. by prior arrangement.
Servers that receive a client hello containing the "status_request"
extension, MAY return an OCSP response to the client along with their
certificate, and MAY use the information contained in the extension
when selecting an OCSP responder.
Servers return an OCSP response along with their certificate by sending
"CertificateAndOCSPResponse" in place of the "Certificate" message. If
a server returns an OCSP response, then the server MUST include an
extension of type "status_request" with empty "unknown_extensions" in the
extended server hello.
struct {
ASN.1Cert certificate_list<0..2^24-1>;
OCSPResponse ocsp_response;
} CertificateAndOCSPResponse;
opaque ASN.1Cert<1..2^24-1>;
opaque OCSPResponse<1..2^24-1>;
(Nevertheless, the handshake message is identified as being of type
"certificate".)
Here "ocsp_response" contains a complete, DER-encoded OCSP response.
Note that only one OCSP response may be sent.
Note that a server MAY also choose not to send the
"CertificateAndOCSPResponse" message, and instead send the "Certificate"
message, even if it receives a "status_request" extension in the
client hello message.
Note in addition that servers MUST NOT send the
"CertificateAndOCSPResponse" 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 "CertificateAndOCSPResponse" field:
- MUST process the certificate as if it was received in a "Certificate"
message, and;
- MAY check the OCSP response and abort the handshake if the response
is not satisfactory.
Blake-Wilson, Nystrom [Page 11]
INTERNET-DRAFT 17 November 2000
4. Security Considerations
The use of the extensions specified in this document may introduce
security concerns for TLS clients and servers.
In particular, it is possible that truncated MACs are weaker than
"un-truncated" MACs. No such weaknesses are currently known for the
truncation sizes specified in this document.
In addition, 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.
Also, TLS entities must be aware of the fact that until the handshake
has been authenticated, active attackers can modify messages and
insert, remove, or replace extensions.
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 RFC [TLS].
5. Intellectual Property Rights
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
document. Please address the information to the IETF Executive Director.
6. Acknowledgments
The authors wish to thank the WAP Security Group. This document is
based on discussion within the WAP Security Group.
7. References
[HMAC] Krawczyk, H., Bellare, M., and Canetti, R. - HMAC: Keyed-hashing
for message authentication. IETF RFC 2104, February 1997.
[MAILING LIST] Mikkelsen, J. Eberhard, R., and J. Kistler, "General
ClientHello extension mechanism and virtual hosting," Ietf-tls
mailing list posting, August 14, 2000.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "Internet X.509 Public Key Infrastructure: Online Certificate
Status Protocol - OCSP," IETF RFC 2560, June 1999.
Blake-Wilson, Nystrom [Page 12]
INTERNET-DRAFT 17 November 2000
[TLS] Dierks, T., and C. Allen, "The TLS Protocol - Version 1.0,"
IETF RFC 2246, January 1999.
8. Authors' Addresses
Simon Blake-Wilson
Certicom Corp.
sblake-wilson@certicom.com
Magnus Nystrom
RSA Security
magnus@rsasecurity.com
Blake-Wilson, Nystrom [Page 13]
