draft-ietf-tls-rfc4366-bis-09.txt   draft-ietf-tls-rfc4366-bis-10.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: December 10, 2010 June 11, 2010 Expires: January 29, 2011 July 30, 2010
Transport Layer Security (TLS) Extensions: Extension Definitions Transport Layer Security (TLS) Extensions: Extension Definitions
<draft-ietf-tls-rfc4366-bis-09.txt> <draft-ietf-tls-rfc4366-bis-10.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 2, line 5 skipping to change at page 1, line 51
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
INTERNET-DRAFT TLS Extension Definitions
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Acknowledgements Acknowledgements
This draft is based on material from RFC 4366 for which the authors This draft is based on material from RFC 4366 for which the authors
were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T. were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T.
Wright. Wright.
Table of Contents Table of Contents
1. Introduction............................................4 1. Introduction............................................3
1.1 Specific Extensions Covered............................4 1.1 Specific Extensions Covered............................3
1.2 Conventions Used in This Document......................6 1.2 Conventions Used in This Document......................5
2. Extensions to the Handshake Protocol....................7 2. Extensions to the Handshake Protocol....................6
3. Server Name Indication..................................8 3. Server Name Indication..................................7
4. Maximum Fragment Length Negotiation....................10 4. Maximum Fragment Length Negotiation.....................9
5. Client Certificate URLs................................12 5. Client Certificate URLs................................11
6. Trusted CA Indication..................................15 6. Trusted CA Indication..................................14
7. Truncated HMAC.........................................17 7. Truncated HMAC.........................................16
8. Certificate Status Request.............................18 8. Certificate Status Request.............................17
9. Error Alerts...........................................20 9. Error Alerts...........................................19
10. IANA Considerations...................................21 10. IANA Considerations...................................20
11. Security Considerations...............................21 10.1 pkipath MIME Type Registration.......................20
11.1 Security Considerations for server_name..............21
11.2 Security Considerations for max_fragment_length......21 11. Security Considerations...............................22
11.1 Security Considerations for server_name..............22
11.2 Security Considerations for max_fragment_length......22
11.3 Security Considerations for client_certificate_url...22 11.3 Security Considerations for client_certificate_url...22
11.4 Security Considerations for trusted_ca_keys..........23 11.4 Security Considerations for trusted_ca_keys..........24
11.5 Security Considerations for truncated_hmac...........23 11.5 Security Considerations for truncated_hmac...........24
11.6 Security Considerations for status_request...........24 11.6 Security Considerations for status_request...........24
12. Normative References..................................25 12. Normative References..................................25
13. Informative References................................25 13. Informative References................................25
Annex A: pkipath MIME Type Registration...................27 Annex A: Changes from RFC 4366............................27
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 13, line 12 skipping to change at page 12, line 12
- If CertificateURL.type is "individual_certs", each URL refers to a - If CertificateURL.type is "individual_certs", each URL refers to a
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
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.
- If CertificateURL.type is "pkipath", the list contains a single - If CertificateURL.type is "pkipath", the list contains a single
URL referring to a DER-encoded certificate chain, using the type URL referring to a DER-encoded certificate chain, using the type
PkiPath described in Annex A. PkiPath described in Section 10.1.
When any other certificate format is used, the specification that When any other certificate format is used, the specification that
describes use of that format in TLS should define the encoding format describes use of that format in TLS should define the encoding format
of certificates or certificate chains, and any constraint on their of certificates or certificate chains, and any constraint on their
ordering. ordering.
The "padding" byte MUST be 0x01. It is present to make the structure The "padding" byte MUST be 0x01. It is present to make the structure
backwards compatible. backwards compatible.
The hash corresponding to each URL is the SHA-1 hash of the The hash corresponding to each URL is the SHA-1 hash of the
skipping to change at page 14, line 10 skipping to change at page 13, line 10
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
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
MIME Content-Types SHALL be used: when a single X.509v3 certificate MIME Content-Types SHALL be used: when a single X.509v3 certificate
is returned, the Content-Type is "application/pkix-cert" [RFC2585], is returned, the Content-Type is "application/pkix-cert" [RFC2585],
and when a chain of X.509v3 certificates is returned, the Content- and when a chain of X.509v3 certificates is returned, the Content-
Type is "application/pkix-pkipath" Annex A. Type is "application/pkix-pkipath" Section 10.1.
The server MUST check that the SHA-1 hash of the contents of the The server MUST check that the SHA-1 hash of the contents of the
object retrieved from that URL (after decoding any MIME Content- object retrieved from that URL (after decoding any MIME Content-
Transfer-Encoding) matches the given hash. If any retrieved object Transfer-Encoding) matches the given hash. If any retrieved object
does not have the correct SHA-1 hash, the server MUST abort the does not have the correct SHA-1 hash, the server MUST abort the
handshake with a bad_certificate_hash_value(114) alert. This alert is handshake with a bad_certificate_hash_value(114) alert. This alert is
always fatal. always fatal.
Clients may choose to send either "Certificate" or "CertificateURL" Clients may choose to send either "Certificate" or "CertificateURL"
after successfully negotiating the option to send certificate URLs. after successfully negotiating the option to send certificate URLs.
skipping to change at page 21, line 11 skipping to change at page 20, line 11
"unrecognized_name" is described in Section 3. "unrecognized_name" is described in Section 3.
"bad_certificate_status_response" is described in Section 8. "bad_certificate_status_response" is described in Section 8.
"bad_certificate_hash_value" is described in Section 5. "bad_certificate_hash_value" is described in Section 5.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
10. 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 covered in Section 12 of [RFC5246] except for the therefore are covered in Section 12 of [RFC5246] except for the
registration of MIME type application/pkix-pkipath. This MIME type registration of MIME type application/pkix-pkipath which appears
has already been registered but is reproduced in Annex A for below.
convenience.
The IANA TLS extensions registry entries that reference [RFC4366] The IANA TLS extensions and MIME type application/pkix-pkipath
should be updated to reference this document on its publication as an registry entries that reference [RFC4366] should be updated to
RFC. reference this document on its publication as an RFC.
10.1 pkipath MIME Type Registration
MIME media type name: application
MIME subtype name: pkix-pkipath
Required parameters: none
Optional parameters: version (default value is "1")
Encoding considerations:
This MIME type is a DER encoding of the ASN.1 type PkiPath,
defined as follows:
PkiPath ::= SEQUENCE OF Certificate
PkiPath is used to represent a certification path. Within the
sequence, the order of certificates is such that the subject of
the first certificate is the issuer of the second certificate,
etc.
This is identical to the definition published in [X509-4th-TC1];
note that it is different from that in [X509-4th].
All Certificates MUST conform to [RFC5280]. (This should be
interpreted as a requirement to encode only PKIX-conformant
certificates using this type. It does not necessarily require
that all certificates that are not strictly PKIX-conformant must
be rejected by relying parties, although the security consequences
of accepting any such certificates should be considered
carefully.)
DER (as opposed to BER) encoding MUST be used. If this type is
sent over a 7-bit transport, base64 encoding SHOULD be used.
Security considerations:
The security considerations of [X509-4th] and [RFC5280] (or any
updates to them) apply, as well as those of any protocol that uses
this type (e.g., TLS).
INTERNET-DRAFT TLS Extension Definitions
Note that this type only specifies a certificate chain that can be
assessed for validity according to the relying party's existing
configuration of trusted CAs; it is not intended to be used to
specify any change to that configuration.
Interoperability considerations:
No specific interoperability problems are known with this type,
but for recommendations relating to X.509 certificates in general,
see [RFC5280].
Published specification: [RFC4366], and [RFC5280].
Applications which use this media type: TLS. It may also be used by
other protocols, or for general interchange of PKIX certificate
chains.
Additional information:
Magic number(s): DER-encoded ASN.1 can be easily recognized.
Further parsing is required to distinguish it from other ASN.1
types.
File extension(s): .pkipath
Macintosh File Type Code(s): not specified
Person & email address to contact for further information:
Magnus Nystrom <magnus@rsasecurity.com>
Intended usage: COMMON
Change controller: IESG <iesg@ietf.org>
INTERNET-DRAFT TLS Extension Definitions
11. Security Considerations 11. Security Considerations
General Security Considerations for TLS Extensions are covered in General Security Considerations for TLS Extensions are covered in
[RFC5246]. Security Considerations for particular extensions [RFC5246]. Security Considerations for particular extensions
specified in this document are given below. specified 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.
skipping to change at page 22, line 5 skipping to change at page 22, line 38
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.
11.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.
INTERNET-DRAFT TLS Extension Definitions
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
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.
11.3 Security Considerations for client_certificate_url 11.3 Security Considerations for client_certificate_url
Support for client_certificate_url involves the server's acting as a Support for client_certificate_url involves the server's acting as a
client in another URI scheme dependent protocol. The server client in another URI scheme dependent protocol. The server
therefore becomes subject to many of the same security concerns that therefore becomes subject to many of the same security concerns that
clients of the URI scheme are subject to, with the added concern that clients of the URI scheme are subject to, with the added concern that
INTERNET-DRAFT TLS Extension Definitions
the client can attempt to prompt the server to connect to some the client can attempt to prompt the server to connect to some
(possibly weird-looking) URL. (possibly weird-looking) URL.
In general, this issue means that an attacker might use the server to In general, this issue means that an attacker might use the server to
indirectly attack another host that is vulnerable to some security indirectly attack another host that is vulnerable to some security
flaw. It also introduces the possibility of denial of service attacks flaw. It also introduces the possibility of denial of service attacks
in which an attacker makes many connections to the server, each of in which an attacker makes many connections to the server, each of
which results in the server's attempting a connection to the target which results in the server's attempting a connection to the target
of the attack. of the attack.
skipping to change at page 23, line 4 skipping to change at page 23, line 43
It is also RECOMMENDED that URI schemes be enabled by the It is also RECOMMENDED that URI schemes be enabled by the
administrator individually, and only a minimal set of schemes be administrator individually, and only a minimal set of schemes be
enabled. Unusual protocols that offer limited security or whose enabled. Unusual protocols that offer limited security or whose
security is not well understood SHOULD be avoided. security is not well understood SHOULD be avoided.
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).
This extension continues to use SHA-1 (as in RFC 4366) and does not This extension continues to use SHA-1 (as in RFC 4366) and does not
INTERNET-DRAFT TLS Extension Definitions
provide algorithm agility. The property required of SHA-1 in this provide algorithm agility. The property required of SHA-1 in this
case is second pre-image resistance, not collision resistance. case is second pre-image resistance, not collision resistance.
Furthermore, even if second pre-image attacks against SHA-1 are found Furthermore, even if second pre-image attacks against SHA-1 are found
in the future, an attack against client_certificate_url would require in the future, an attack against client_certificate_url would require
a second pre-image that is accepted as a valid certificate by the a second pre-image that is accepted as a valid certificate by the
server, and contains the same public key. server, and contains the same public key.
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.
INTERNET-DRAFT TLS Extension Definitions
11.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. This context does not require certificate is specified unambiguously. This context does not require
a cryptographic hash function, so the use of SHA-1 is considered a cryptographic hash function, so the use of SHA-1 is considered
acceptable, and no algorithm agility is provided. acceptable, and no algorithm agility is provided.
skipping to change at page 24, line 5 skipping to change at page 24, line 39
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.
INTERNET-DRAFT TLS Extension Definitions
11.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
skipping to change at page 27, line 7 skipping to change at page 27, line 7
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, [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: Changes from RFC 4366
The MIME type application/pkix-pkipath has been registered. A copy
of its template is included here for convenience:
MIME media type name: application
MIME subtype name: pkix-pkipath
Required parameters: none
Optional parameters: version (default value is "1")
Encoding considerations:
This MIME type is a DER encoding of the ASN.1 type PkiPath,
defined as follows:
PkiPath ::= SEQUENCE OF Certificate
PkiPath is used to represent a certification path. Within the
sequence, the order of certificates is such that the subject of
the first certificate is the issuer of the second certificate,
etc.
This is identical to the definition published in [X509-4th-TC1];
note that it is different from that in [X509-4th].
All Certificates MUST conform to [RFC5280]. (This should be
interpreted as a requirement to encode only PKIX-conformant
certificates using this type. It does not necessarily require
that all certificates that are not strictly PKIX-conformant must
be rejected by relying parties, although the security consequences
of accepting any such certificates should be considered
carefully.)
DER (as opposed to BER) encoding MUST be used. If this type is
sent over a 7-bit transport, base64 encoding SHOULD be used.
Security considerations:
The security considerations of [X509-4th] and [RFC5280] (or any
updates to them) apply, as well as those of any protocol that uses
this type (e.g., TLS).
Note that this type only specifies a certificate chain that can be
assessed for validity according to the relying party's existing
configuration of trusted CAs; it is not intended to be used to
specify any change to that configuration.
Interoperability considerations:
No specific interoperability problems are known with this type,
but for recommendations relating to X.509 certificates in general,
see [RFC5280].
Published specification: [RFC4366], and [RFC5280].
INTERNET-DRAFT TLS Extension Definitions
Applications which use this media type: TLS. It may also be used by
other protocols, or for general interchange of PKIX certificate
chains.
Additional information:
Magic number(s): DER-encoded ASN.1 can be easily recognized.
Further parsing is required to distinguish it from other ASN.1
types.
File extension(s): .pkipath
Macintosh File Type Code(s): not specified
Person & email address to contact for further information:
Magnus Nystrom <magnus@rsasecurity.com>
Intended usage: COMMON
Change controller: IESG <iesg@ietf.org>
INTERNET-DRAFT TLS Extension Definitions
Annex B: Changes from RFC 4366
The significant changes between RFC 4366 and this document are The significant changes between RFC 4366 and this document are
described below. described below.
RFC 4366 described both general extension mechanisms (for the TLS RFC 4366 described both general extension mechanisms (for the TLS
handshake and client and server hellos) as well as specific handshake and client and server hellos) as well as specific
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
 End of changes. 18 change blocks. 
111 lines changed or deleted 104 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/