draft-ietf-tls-rfc4366-bis-01.txt   draft-ietf-tls-rfc4366-bis-02.txt 
TLS Working Group Donald Eastlake 3rd TLS Working Group Donald Eastlake 3rd
INTERNET-DRAFT Motorola Laboratories INTERNET-DRAFT Motorola Laboratories
Obsoletes: RFC 4366 Obsoletes: RFC 4366
Updates: RFC 2246, RFC 4346
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: July 2008 January 14, 2009 Expires: August 2008 February 20, 2008
Transport Layer Security (TLS) Extensions: Extension Definitions Transport Layer Security (TLS) Extensions: Extension Definitions
<draft-ietf-tls-rfc4366-bis-01.txt> <draft-ietf-tls-rfc4366-bis-02.txt>
Status of This Document Status of This Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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>.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1 Abstract...................................................1
Acknowledgements...........................................2 Acknowledgements...........................................2
Table of Contents..........................................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
3. Server Name Indication..................................5 2. Extensions to the Handshake Protocol....................5
4. Maximum Fragment Length Negotiation.....................6
5. Client Certificate URLs.................................7
6. Trusted CA Indication..................................10
7. Truncated HMAC.........................................11
8. Certificate Status Request.............................12
9. IANA Considerations....................................15 3. Server Name Indication..................................6
10. Security Considerations...............................15 4. Maximum Fragment Length Negotiation.....................7
10.1 Security Considerations for server_name..............15 5. Client Certificate URLs.................................8
10.2 Security Considerations for max_fragment_length......15 6. Trusted CA Indication..................................11
10.3 Security Considerations for client_certificate_url...16 7. Truncated HMAC.........................................12
10.4 Security Considerations for trusted_ca_keys..........17 8. Certificate Status Request.............................13
10.5 Security Considerations for truncated_hmac...........17
10.6 Security Considerations for status_request...........18
11. Internationalization Considerations...................18
12. Normative References..................................19 9. Error Alerts...........................................16
13. Informative References................................19
Copyright, Disclaimer, and Additional IPR Provisions......21 10. IANA Considerations...................................17
11. Security Considerations...............................17
11.1 Security Considerations for server_name..............17
11.2 Security Considerations for max_fragment_length......17
11.3 Security Considerations for client_certificate_url...18
11.4 Security Considerations for trusted_ca_keys..........19
11.5 Security Considerations for truncated_hmac...........19
11.6 Security Considerations for status_request...........20
Author's Address..........................................22 12. Normative References..................................21
Expiration and File Name..................................22 13. Informative References................................21
Copyright, Disclaimer, and Additional IPR Provisions......22
Author's Address..........................................23
Expiration and File Name..................................23
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 [RFCTLS]. That specification includes the framework for extensions in [RFCTLS]. That specification includes the framework for extensions
to TLS, considerations in designing such extensions (see Section to TLS, considerations in designing such extensions (see Section
7.4.1.4 of [RFCTLS]), and IANA Considerations for the allocation of 7.4.1.4 of [RFCTLS]), and IANA Considerations for the allocation of
new extension code points; however, it does not specify any new extension code points; however, it does not specify any
particular extensions other than CertHashTypes (see Section particular extensions other than Signature Algorithms (see Section
7.4.1.4.1of [RFCTLS]). 7.4.1.4.1of [RFCTLS]).
This document provides the specifications for existing TLS This document provides the specifications for existing TLS
extensions. It is, for the most part, the mere adaptation and editing extensions. It is, for the most part, the adaptation and editing of
of material from [RFC4366], which covered all aspects of TLS material from [RFC4366], which covered TLS extensions for TLS 1.0
extensions for TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346]. [RFC2246] and TLS 1.1 [RFC4346].
1.1 Specific Extensions Covered 1.1 Specific Extensions Covered
The extensions described here focus on extending the functionality The extensions described here focus on extending the functionality
provided by the TLS protocol message formats. Other issues, such as provided by the TLS protocol message formats. Other issues, such as
the addition of new cipher suites, are deferred. the addition of new cipher suites, are deferred.
Specifically, the extensions described in this document: Specifically, the extensions described in this document:
- Allow TLS clients to provide to the TLS server the name of the - Allow TLS clients to provide to the TLS server the name of the
skipping to change at page 4, line 16 skipping to change at page 4, line 16
the client certificate status information (e.g., an Online the client certificate status information (e.g., an Online
Certificate Status Protocol (OCSP) [RFC2560] response) during a Certificate Status Protocol (OCSP) [RFC2560] response) during a
TLS handshake. This functionality is desirable in order to avoid TLS handshake. This functionality is desirable in order to avoid
sending a Certificate Revocation List (CRL) over a constrained sending a Certificate Revocation List (CRL) over a constrained
access network and therefore save bandwidth. access network and therefore save bandwidth.
The extensions described in this document may be used by TLS clients The extensions described in this document may be used by TLS clients
and servers. The extensions are designed to be backwards compatible, and servers. 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. The servers that do not support the extensions, and vice versa.
document therefore updates TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346].
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 [RFC2119].
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
2. Extensions to the Handshake Protocol
This document specifies the use of two new handshake messages,
"CertificateURL" and "CertificateStatus". These messages are
described in Section 5 and Section 8, respectively. The new
handshake message structure therefore becomes:
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), certificate_url(21), certificate_status(22),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case certificate_url: CertificateURL;
case certificate_status: CertificateStatus;
} body;
} Handshake;
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 the server name, clients MAY include an extension
of type "server_name" in the (extended) client hello. The of type "server_name" in the (extended) client hello. The
skipping to change at page 5, line 37 skipping to change at page 6, line 37
enum { enum {
host_name(0), (255) host_name(0), (255)
} NameType; } NameType;
opaque HostName<1..2^16-1>; opaque HostName<1..2^16-1>;
struct { struct {
ServerName server_name_list<1..2^16-1> ServerName server_name_list<1..2^16-1>
} ServerNameList; } ServerNameList;
If the server understood the client hello extension but does not
recognize any of the server names, it SHOULD send an
unrecognized_name(112) alert (which MAY be fatal).
Currently, the only server names supported are DNS hostnames; Currently, the only server names supported are DNS hostnames;
however, this does not imply any dependency of TLS on DNS, and other however, this does not imply any dependency of TLS on DNS, and other
name types may be added in the future (by an RFC that updates this name types may be added in the future (by an RFC that updates this
document). TLS MAY treat provided server names as opaque data and document). TLS MAY treat provided server names as opaque data and
pass the names and types to the application. pass the names and types to the application.
"HostName" contains the fully qualified DNS hostname of the server, "HostName" contains the fully qualified DNS hostname of the server,
as understood by the client. The hostname is represented as a byte as understood by the client. The hostname is represented as a byte
string using UTF-8 encoding [RFC3629], without a trailing dot. string using ASCII encoding without a trailing dot.
If the hostname labels contain only US-ASCII characters, then the
client MUST ensure that labels are separated only by the byte 0x2E,
representing the dot character U+002E (requirement 1 in Section 3.1
of [RFC3490] notwithstanding). If the server needs to match the
HostName against names that contain non-US-ASCII characters, it MUST
perform the conversion operation described in Section 4 of [RFC3490],
treating the HostName as a "query string" (i.e., the AllowUnassigned
flag MUST be set). Note that IDNA allows labels to be separated by
any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61;
therefore, servers MUST accept any of these characters as a label
INTERNET-DRAFT TLS Extension Definitions
separator. If the server only needs to match the HostName against
names containing exclusively ASCII characters, it MUST compare ASCII
names case-insensitively.
Literal IPv4 and IPv6 addresses are not permitted in "HostName". Literal IPv4 and IPv6 addresses are not permitted in "HostName".
It is RECOMMENDED that clients include an extension of type It is RECOMMENDED that clients include an extension of type
"server_name" in the client hello whenever they locate a server by a "server_name" in the client hello whenever they locate a server by a
supported name type. supported name type.
INTERNET-DRAFT TLS Extension Definitions
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.
If the server understood the client hello extension but does not If the server understood the client hello extension but does not
recognize the server name, it SHOULD send an "unrecognized_name" recognize the server name, it SHOULD send an "unrecognized_name"
skipping to change at page 7, line 5 skipping to change at page 7, line 45
client hello. The "extension_data" field of this extension SHALL client hello. The "extension_data" field of this extension SHALL
contain: contain:
enum{ enum{
2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
} MaxFragmentLength; } MaxFragmentLength;
whose value is the desired maximum fragment length. The allowed whose value is the desired maximum fragment length. The allowed
values for this field are: 2^9, 2^10, 2^11, and 2^12. values for this field are: 2^9, 2^10, 2^11, and 2^12.
INTERNET-DRAFT TLS Extension Definitions
Servers that receive an extended client hello containing a Servers that receive an extended client hello containing a
"max_fragment_length" extension MAY accept the requested maximum "max_fragment_length" extension MAY accept the requested maximum
fragment length by including an extension of type fragment length by including an extension of type
"max_fragment_length" in the (extended) server hello. The "max_fragment_length" in the (extended) server hello. The
"extension_data" field of this extension SHALL contain a "extension_data" field of this extension SHALL contain a
"MaxFragmentLength" whose value is the same as the requested maximum "MaxFragmentLength" whose value is the same as the requested maximum
fragment length. fragment length.
If a server receives a maximum fragment length negotiation request If a server receives a maximum fragment length negotiation request
for a value other than the allowed values, it MUST abort the for a value other than the allowed values, it MUST abort the
INTERNET-DRAFT TLS Extension Definitions
handshake with an "illegal_parameter" alert. Similarly, if a client handshake with an "illegal_parameter" alert. Similarly, if a client
receives a maximum fragment length negotiation response that differs receives a maximum fragment length negotiation response that differs
from the length it requested, it MUST also abort the handshake with from the length it requested, it MUST also abort the handshake with
an "illegal_parameter" alert. an "illegal_parameter" alert.
Once a maximum fragment length other than 2^14 has been successfully Once a maximum fragment length other than 2^14 has been successfully
negotiated, the client and server MUST immediately begin fragmenting negotiated, the client and server MUST immediately begin fragmenting
messages (including handshake messages), to ensure that no fragment messages (including handshake messages), to ensure that no fragment
larger than the negotiated length is sent. Note that TLS already larger than the negotiated length is sent. Note that TLS already
requires clients and servers to support fragmentation of handshake requires clients and servers to support fragmentation of handshake
skipping to change at page 7, line 39 skipping to change at page 8, line 29
The negotiated length applies for the duration of the session The negotiated length applies for the duration of the session
including session resumptions. including session resumptions.
The negotiated length limits the input that the record layer may The negotiated length limits the input that the record layer may
process without fragmentation (that is, the maximum value of process without fragmentation (that is, the maximum value of
TLSPlaintext.length; see [RFCTLS], Section 6.2.1). Note that the TLSPlaintext.length; see [RFCTLS], Section 6.2.1). Note that the
output of the record layer may be larger. For example, if the output of the record layer may be larger. For example, if the
negotiated length is 2^9=512, then for currently defined cipher negotiated length is 2^9=512, then for currently defined cipher
suites (those defined in [RFCTLS], [RFC2712], and [RFC3268]), and suites (those defined in [RFCTLS], [RFC2712], and [RFC3268]), and
when null compression is used, the record layer output can be at most when null compression is used, the record layer output can be at most
793 bytes: 5 bytes of headers, 512 bytes of application data, 256 805 bytes: 5 bytes of headers, 512 bytes of application data, 256
bytes of padding, and 20 bytes of MAC. This means that in this event bytes of padding, and 32 bytes of MAC. This means that in this event
a TLS record layer peer receiving a TLS record layer message larger a TLS record layer peer receiving a TLS record layer message larger
than 793 bytes may discard the message and send a "record_overflow" than 805 bytes may discard the message and send a "record_overflow"
alert, without decrypting the message. alert, without decrypting the message.
5. Client Certificate URLs 5. Client Certificate URLs
Without this extension, TLS specifies that when client authentication Without this extension, TLS specifies that when client authentication
is performed, client certificates are sent by clients to servers is performed, client certificates are sent by clients to servers
during the TLS handshake. It may be desirable for constrained clients during the TLS handshake. It may be desirable for constrained clients
to send certificate URLs in place of certificates, so that they do to send certificate URLs in place of certificates, so that they do
not need to store their certificates and can therefore save memory. not need to store their certificates and can therefore save memory.
In order to negotiate sending certificate URLs to a server, clients In order to negotiate sending certificate URLs to a server, clients
MAY include an extension of type "client_certificate_url" in the MAY include an extension of type "client_certificate_url" in the
INTERNET-DRAFT TLS Extension Definitions
(extended) client hello. The "extension_data" field of this extension (extended) client hello. The "extension_data" field of this extension
SHALL be empty. SHALL be empty.
(Note that it is necessary to negotiate use of client certificate (Note that it is necessary to negotiate use of client certificate
URLs in order to avoid "breaking" existing TLS servers.) URLs in order to avoid "breaking" existing TLS servers.)
Servers that receive an extended client hello containing a Servers that receive an extended client hello containing a
"client_certificate_url" extension MAY indicate that they are willing "client_certificate_url" extension MAY indicate that they are willing
to accept certificate URLs by including an extension of type to accept certificate URLs by including an extension of type
"client_certificate_url" in the (extended) server hello. The "client_certificate_url" in the (extended) server hello. The
INTERNET-DRAFT TLS Extension Definitions
"extension_data" field of this extension SHALL be empty. "extension_data" field of this extension SHALL be empty.
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: "CertificateURL" message in place of a "Certificate" message as
follows (see also Section 2):
enum { enum {
individual_certs(0), pkipath(1), (255) individual_certs(0), pkipath(1), (255)
} CertChainType; } CertChainType;
enum { enum {
false(0), true(1) false(0), true(1)
} Boolean; } Boolean;
struct { struct {
skipping to change at page 9, line 5 skipping to change at page 9, line 48
Here "url_and_hash_list" contains a sequence of URLs and optional Here "url_and_hash_list" contains a sequence of URLs and optional
hashes. hashes.
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
certificate first. certificate first.
INTERNET-DRAFT TLS Extension Definitions
- 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 Section 8 of [RFCTLS]. PkiPath described in Section 8 of [RFCTLS].
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.
INTERNET-DRAFT TLS Extension Definitions
The hash corresponding to each URL at the client's discretion either The hash corresponding to each URL at the client's discretion either
is not present or is the SHA-1 hash of the certificate or certificate is not present or is the SHA-1 hash of the certificate or certificate
chain (in the case of X.509 certificates, the DER-encoded certificate chain (in the case of X.509 certificates, 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 [RFCTLS], Section 7.4.2), but opposite to the order in message (see [RFCTLS], 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
skipping to change at page 10, line 5 skipping to change at page 10, line 48
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" (see Section 8 of [RFCTLS]). Type is "application/pkix-pkipath" (see Section 8 of [RFCTLS]).
INTERNET-DRAFT TLS Extension Definitions
If a SHA-1 hash is present for an URL, then the server MUST check If a SHA-1 hash is present for an URL, then the server MUST check
that the SHA-1 hash of the contents of the object retrieved from that that the SHA-1 hash of the contents of the object retrieved from that
URL (after decoding any MIME Content-Transfer-Encoding) matches the URL (after decoding any MIME Content-Transfer-Encoding) matches the
given hash. If any retrieved object does not have the correct SHA-1 given hash. If any retrieved object does not have the correct SHA-1
hash, the server MUST abort the handshake with a hash, the server MUST abort the handshake with a
"bad_certificate_hash_value" alert. bad_certificate_hash_value(114) alert. This alert is always fatal.
Note that clients may choose to send either "Certificate" or Clients may choose to send either "Certificate" or "CertificateURL"
"CertificateURL" after successfully negotiating the option to send after successfully negotiating the option to send certificate URLs.
certificate URLs. The option to send a certificate is included to
provide flexibility to clients possessing multiple certificates. INTERNET-DRAFT TLS Extension Definitions
The option to send a certificate is included to provide flexibility
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" error alert. a certificate_unobtainable(111) error alert. This alert MAY be fatal;
for example, if client authentication is required by the server for
the handshake to continue.
6. Trusted CA Indication 6. Trusted CA Indication
Constrained clients that, due to memory limitations, possess only a Constrained clients that, due to memory limitations, possess only a
small number of CA root keys may wish to indicate to servers which small number of CA root keys may wish to indicate to servers which
root keys they possess, in order to avoid repeated handshake root keys they possess, in order to avoid repeated handshake
failures. failures.
In order to indicate which CA root keys they possess, clients MAY In order to indicate which CA root keys they possess, clients MAY
include an extension of type "trusted_ca_keys" in the (extended) include an extension of type "trusted_ca_keys" in the (extended)
skipping to change at page 11, line 5 skipping to change at page 11, line 49
} identifier; } identifier;
} TrustedAuthority; } TrustedAuthority;
enum { enum {
pre_agreed(0), key_sha1_hash(1), x509_name(2), pre_agreed(0), key_sha1_hash(1), x509_name(2),
cert_sha1_hash(3), (255) cert_sha1_hash(3), (255)
} IdentifierType; } IdentifierType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
INTERNET-DRAFT TLS Extension Definitions
Here "TrustedAuthorities" provides a list of CA root key identifiers Here "TrustedAuthorities" provides a list of CA root key identifiers
that the client possesses. Each CA root key is identified via either: that the client possesses. Each CA root key is identified via either:
- "pre_agreed": no CA root key identity supplied. - "pre_agreed": no CA root key identity supplied.
- "key_sha1_hash": contains the SHA-1 hash of the CA root key. For - "key_sha1_hash": contains the SHA-1 hash of the CA root key. For
INTERNET-DRAFT TLS Extension Definitions
Digital Signature Algorithm (DSA) and Elliptic Curve Digital Digital Signature Algorithm (DSA) and Elliptic Curve Digital
Signature Algorithm (ECDSA) keys, this is the hash of the Signature Algorithm (ECDSA) keys, this is the hash of the
"subjectPublicKey" value. For RSA keys, the hash is of the big- "subjectPublicKey" value. For RSA keys, the hash is of the big-
endian byte string representation of the modulus without any endian byte string representation of the modulus without any
initial 0-valued bytes. (This copies the key hash formats deployed initial 0-valued bytes. (This copies the key hash formats deployed
in other environments.) in other environments.)
- "x509_name": contains the DER-encoded X.509 DistinguishedName of - "x509_name": contains the DER-encoded X.509 DistinguishedName of
the CA. the CA.
skipping to change at page 12, line 4 skipping to change at page 12, line 49
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 with either MD5 or SHA-1 [RFC2104] to authenticate record layer
communications. In TLS, the entire output of the hash function is communications. In TLS, the entire output of the hash function is
used as the MAC tag. However, it may be desirable in constrained used as the MAC tag. However, it may be desirable in constrained
environments to save bandwidth by truncating the output of the hash environments to save bandwidth by truncating the output of the hash
function to 80 bits when forming MAC tags. function to 80 bits when forming 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
INTERNET-DRAFT TLS Extension Definitions
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
INTERNET-DRAFT TLS Extension Definitions
extended server hello. extended server hello.
Note that if new cipher suites are added that do not use HMAC, and Note that if new cipher suites are added that do not use HMAC, and
the session negotiates one of these cipher suites, this extension the session negotiates one of these cipher suites, this extension
will have no effect. It is strongly recommended that any new cipher will have no effect. It is strongly recommended that any new cipher
suites using other MACs consider the MAC size an integral part of the suites using other MACs consider the MAC size an integral part of the
cipher suite definition, taking into account both security and cipher suite definition, taking into account both security and
bandwidth considerations. bandwidth considerations.
If HMAC truncation has been successfully negotiated during a TLS If HMAC truncation has been successfully negotiated during a TLS
handshake, and the negotiated cipher suite uses HMAC, both the client handshake, and the negotiated cipher suite uses HMAC, both the client
and the server pass this fact to the TLS record layer along with the and the server pass this fact to the TLS record layer along with the
other negotiated security parameters. Subsequently during the other negotiated security parameters. Subsequently during the
session, clients and servers MUST use truncated HMACs, calculated as session, clients and servers MUST use truncated HMACs, calculated as
specified in [RFC2104]. That is, CipherSpec.hash_size is 10 bytes, specified in [RFC2104]. That is, SecurityParameters.mac_length is 10
and only the first 10 bytes of the HMAC output are transmitted and bytes, and only the first 10 bytes of the HMAC output are transmitted
checked. Note that this extension does not affect the calculation of and checked. Note that this extension does not affect the calculation
the pseudo-random function (PRF) as part of handshaking or key of the pseudo-random function (PRF) as part of handshaking or key
derivation. derivation.
The negotiated HMAC truncation size applies for the duration of the The negotiated HMAC truncation size applies for the duration of the
session including session resumptions. session including session resumptions.
8. Certificate Status Request 8. Certificate Status Request
Constrained clients may wish to use a certificate-status protocol Constrained clients may wish to use a certificate-status protocol
such as OCSP [RFC2560] to check the validity of server certificates, such as OCSP [RFC2560] to check the validity of server certificates,
in order to avoid transmission of CRLs and therefore save bandwidth in order to avoid transmission of CRLs and therefore save bandwidth
skipping to change at page 13, line 4 skipping to change at page 13, line 49
information, clients MAY include an extension of type information, clients MAY include an extension of type
"status_request" in the (extended) client hello. The "extension_data" "status_request" in the (extended) client hello. The "extension_data"
field of this extension SHALL contain "CertificateStatusRequest" field of this extension SHALL contain "CertificateStatusRequest"
where: where:
struct { struct {
CertificateStatusType status_type; CertificateStatusType status_type;
select (status_type) { select (status_type) {
case ocsp: OCSPStatusRequest; case ocsp: OCSPStatusRequest;
} request; } request;
INTERNET-DRAFT TLS Extension Definitions
} CertificateStatusRequest; } CertificateStatusRequest;
enum { ocsp(1), (255) } CertificateStatusType; enum { ocsp(1), (255) } CertificateStatusType;
struct { struct {
ResponderID responder_id_list<0..2^16-1>; ResponderID responder_id_list<0..2^16-1>;
INTERNET-DRAFT TLS Extension Definitions
Extensions request_extensions; Extensions request_extensions;
} OCSPStatusRequest; } OCSPStatusRequest;
opaque ResponderID<1..2^16-1>; opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>; opaque Extensions<0..2^16-1>;
In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
responders that the client trusts. A zero-length "responder_id_list" responders that the client trusts. A zero-length "responder_id_list"
sequence has the special meaning that the responders are implicitly sequence has the special meaning that the responders are implicitly
known to the server, e.g., by prior arrangement. "Extensions" is a known to the server, e.g., by prior arrangement. "Extensions" is a
skipping to change at page 13, line 50 skipping to change at page 14, line 44
SHOULD use the information contained in the extension when selecting SHOULD use the information contained in the extension when selecting
an OCSP responder and SHOULD include request_extensions in the OCSP an OCSP responder and SHOULD include request_extensions in the OCSP
request. request.
Servers return a certificate response along with their certificate by Servers return a certificate response along with their certificate by
sending a "CertificateStatus" message immediately after the sending a "CertificateStatus" message immediately after the
"Certificate" message (and before any "ServerKeyExchange" or "Certificate" message (and before any "ServerKeyExchange" or
"CertificateRequest" messages). If a server returns a "CertificateRequest" messages). If a server returns a
"CertificateStatus" message, then the server MUST have included an "CertificateStatus" message, then the server MUST have included an
extension of type "status_request" with empty "extension_data" in the extension of type "status_request" with empty "extension_data" in the
extended server hello. extended server hello. The "CertificateStatus" message is conveyed
using the handshake message type "certificate_status" as follows (see
also Section 2):
struct { struct {
CertificateStatusType status_type; CertificateStatusType status_type;
select (status_type) { select (status_type) {
case ocsp: OCSPResponse; case ocsp: OCSPResponse;
} response; } response;
INTERNET-DRAFT TLS Extension Definitions
} CertificateStatus; } CertificateStatus;
opaque OCSPResponse<1..2^24-1>; opaque OCSPResponse<1..2^24-1>;
An "ocsp_response" contains a complete, DER-encoded OCSP response INTERNET-DRAFT TLS Extension Definitions
(using the ASN.1 type OCSPResponse defined in [RFC2560]). Note that
only one OCSP response may be sent.
The "CertificateStatus" message is conveyed using the handshake An "ocsp_response" contains a complete, DER-encoded OCSP response
message type "certificate_status". (using the ASN.1 type OCSPResponse defined in [RFC2560]). Only one
OCSP response may be sent.
Note that a server MAY also choose not to send a "CertificateStatus" Note that a server MAY also choose not to send a "CertificateStatus"
message, even if it receives a "status_request" extension in the message, even if it receives a "status_request" extension in the
client hello message. client hello message.
Note in addition that servers MUST NOT send the "CertificateStatus" Note in addition that servers MUST NOT send the "CertificateStatus"
message unless it received a "status_request" extension in the client message unless it received a "status_request" extension in the client
hello message. hello message.
Clients requesting an OCSP response and receiving an OCSP response in Clients requesting an OCSP response and receiving an OCSP response in
a "CertificateStatus" message MUST check the OCSP response and abort a "CertificateStatus" message MUST check the OCSP response and abort
the handshake if the response is not satisfactory. the handshake if the response is not satisfactory with
bad_certificate_status_response(113) alert. This alert is always
fatal.
INTERNET-DRAFT TLS Extension Definitions
9. Error Alerts
This section defines new error alerts for use with the TLS extensions
defined in this document.
Four new error alerts are defined. To avoid "breaking" existing
clients and servers, these alerts MUST NOT be sent unless the sending
party has received an extended hello message from the party they are
communicating with. These error alerts are conveyed using the
following syntax:
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
/* 41 is not defined, for historical reasons */
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110),
certificate_unobtainable(111), /* new */ certificate_unobtainable(111), /* new */
unrecognized_name(112), /* new */ unrecognized_name(112), /* new */
bad_certificate_status_response(113), /* new */ bad_certificate_status_response(113), /* new */
bad_certificate_hash_value(114), /* new */ bad_certificate_hash_value(114), /* new */
(255) (255)
} AlertDescription; } AlertDescription;
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
9. IANA Considerations 10. IANA Considerations
IANA Considerations for TLS Extensions and the creation of a Registry IANA Considerations for TLS Extensions and the creation of a Registry
therefore are all covered in Section 12 of [RFCTLS].. therefore are all covered in Section 12 of [RFCTLS]..
10. Security Considerations 11. Security Considerations
General Security Considerations for TLS Extensions are covered in General Security Considerations for TLS Extensions are covered in
[RFCTLS]. Security Considerations for particular extensions specified [RFCTLS]. Security Considerations for particular extensions specified
in this document are given below. 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 Additional security considerations are described in the TLS 1.0 RFC
[RFC2246] and the TLS 1.1 RFC [RFC4346]. [RFC2246] and the TLS 1.1 RFC [RFC4346].
10.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.
Although this document specifies an encoding for internationalized Although this document specifies an encoding for internationalized
hostnames in the server_name extension, it does not address any hostnames in the server_name extension, it does not address any
security issues associated with the use of internationalized security issues associated with the use of internationalized
hostnames in TLS (in particular, the consequences of "spoofed" names hostnames in TLS (in particular, the consequences of "spoofed" names
that are indistinguishable from another name when displayed or that are indistinguishable from another name when displayed or
printed). It is recommended that server certificates not be issued printed). It is recommended that server certificates not be issued
for internationalized hostnames unless procedures are in place to for internationalized hostnames unless procedures are in place to
mitigate the risk of spoofed hostnames. mitigate the risk of spoofed hostnames.
10.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
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
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
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.
10.3 Security Considerations for client_certificate_url 11.3 Security Considerations for client_certificate_url
There are two major issues with this extension. There are two major issues with this extension.
The first major issue is whether or not clients should include The first major issue is whether or not clients should 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
skipping to change at page 17, line 35 skipping to change at page 19, line 35
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.
10.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.
10.5 Security Considerations for truncated_hmac 11.5 Security Considerations for truncated_hmac
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
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
length of a symmetric cipher key, since forging of MAC values cannot length of a symmetric cipher key, since forging of MAC values cannot
skipping to change at page 18, line 21 skipping to change at page 20, line 21
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.
10.6 Security Considerations for status_request 11.6 Security Considerations for status_request
If a client requests an OCSP response, it must take into account that If a client requests an OCSP response, it must take into account that
an attacker's server using a compromised key could (and probably an attacker's server using a compromised key could (and probably
would) pretend not to support the extension. In this case, a client would) pretend not to support the extension. In this case, a client
that requires OCSP validation of certificates SHOULD either contact that requires OCSP validation of certificates SHOULD either contact
the OCSP server directly or abort the handshake. the OCSP server directly or abort the handshake.
Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
improve security against attacks that attempt to replay OCSP improve security against attacks that attempt to replay OCSP
responses; see Section 4.4.1 of [RFC2560] for further details. responses; see Section 4.4.1 of [RFC2560] for further details.
11. Internationalization Considerations
None of the extensions defined here directly use strings subject to
localization. Domain Name System (DNS) hostnames are encoded using
UTF-8. If future extensions use text strings, then
internationalization should be considered in their design.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
12. Normative References 12. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February 1997. Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 19, line 31 skipping to change at page 21, line 31
1999. 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and Certificate X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", RFC 3490,
March 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January
2005. 2005.
[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.
[RFCTLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2", [RFCTLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2",
draft-ietf-tls-rfc4346-bis-*.txt, March 2007. draft-ietf-tls-rfc4346-bis-*.txt, March 2007.
13. Informative References 13. Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[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.
INTERNET-DRAFT TLS Extension Definitions
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
for Transport Layer Security (TLS)", RFC 3268, June 2002. for Transport Layer Security (TLS)", RFC 3268, June 2002.
[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.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Copyright, Disclaimer, and Additional IPR Provisions Copyright, Disclaimer, and Additional IPR Provisions
skipping to change at page 22, line 19 skipping to change at page 23, line 19
Donald Eastlake 3rd Donald Eastlake 3rd
Motorola Laboratories Motorola Laboratories
111 Locke Drive 111 Locke Drive
Marlborough, MA 01752 Marlborough, MA 01752
Tel: +1-508-786-7554 Tel: +1-508-786-7554
Email: Donald.Eastlake@motorola.com Email: Donald.Eastlake@motorola.com
Expiration and File Name Expiration and File Name
This draft expires in July 2008. This draft expires in August 2008.
Its file name is draft-ietf-tls-rfc4366-bis-01.txt. Its file name is draft-ietf-tls-rfc4366-bis-02.txt.
 End of changes. 55 change blocks. 
113 lines changed or deleted 170 lines changed or added

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