< draft-ietf-tls-rfc4346-bis-00.txt   draft-ietf-tls-rfc4346-bis-01.txt >
Tim Dierks Tim Dierks
Independent Independent
Eric Rescorla Eric Rescorla
INTERNET-DRAFT Network Resonance, Inc. INTERNET-DRAFT Network Resonance, Inc.
<draft-ietf-tls-rfc4346-bis-00.txt> February 2006 (Expires August 2006) <draft-ietf-tls-rfc4346-bis-01.txt> June 2006 (Expires December 2006)
The TLS Protocol The TLS Protocol
Version 1.2 Version 1.2
Status of this Memo Status of this Memo
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.
skipping to change at page 112, line ? skipping to change at page 111, line ?
4.1. Basic block size 7 4.1. Basic block size 7
4.2. Miscellaneous 7 4.2. Miscellaneous 7
4.3. Vectors 7 4.3. Vectors 7
4.4. Numbers 8 4.4. Numbers 8
4.5. Enumerateds 8 4.5. Enumerateds 8
4.6. Constructed types 9 4.6. Constructed types 9
4.6.1. Variants 10 4.6.1. Variants 10
4.7. Cryptographic attributes 11 4.7. Cryptographic attributes 11
4.8. Constants 12 4.8. Constants 12
5. HMAC and the pseudorandom function 12 5. HMAC and the pseudorandom function 12
6. The TLS Record Protocol 14 6. The TLS Record Protocol 13
6.1. Connection states 15 6.1. Connection states 14
6.2. Record layer 17 6.2. Record layer 16
6.2.1. Fragmentation 18 6.2.1. Fragmentation 16
6.2.2. Record compression and decompression 19 6.2.2. Record compression and decompression 18
6.2.3. Record payload protection 19 6.2.3. Record payload protection 18
6.2.3.1. Null or standard stream cipher 20 6.2.3.1. Null or standard stream cipher 19
6.2.3.2. CBC block cipher 21 6.2.3.2. CBC block cipher 20
6.3. Key calculation 23 6.3. Key calculation 22
7. The TLS Handshaking Protocols 24 7. The TLS Handshaking Protocols 23
7.1. Change cipher spec protocol 26 7.1. Change cipher spec protocol 25
7.2. Alert protocol 26 7.2. Alert protocol 25
7.2.1. Closure alerts 27 7.2.1. Closure alerts 26
7.2.2. Error alerts 28 7.2.2. Error alerts 27
7.3. Handshake Protocol overview 32 7.3. Handshake Protocol overview 31
7.4. Handshake protocol 36 7.4. Handshake protocol 35
7.4.1. Hello messages 37 7.4.1. Hello messages 36
7.4.1.1. Hello request 37 7.4.1.1. Hello request 36
7.4.1.2. Client hello 38 7.4.1.2. Client hello 37
7.4.1.3. Server hello 41 7.4.1.3. Server hello 40
7.4.1.4 Hello Extensions 42 7.4.1.4 Hello Extensions 41
7.4.1.4.1 Server Name Indication 44 7.4.1.4.1 Server Name Indication 43
7.4.1.4.2 Maximum Fragment Length Negotiation 45 7.4.1.4.2 Maximum Fragment Length Negotiation 44
7.4.1.4.3 Client Certificate URLs 47 7.4.1.4.3 Client Certificate URLs 46
7.4.1.4.4 Trusted CA Indication 47 7.4.1.4.4 Trusted CA Indication 46
7.4.1.4.5 Truncated HMAC 49 7.4.1.4.5 Truncated HMAC 48
7.4.1.4.6 Certificate Status Request 50 7.4.1.4.6 Certificate Status Request 49
7.4.1.4.7 Procedure for Defining New Extensions 51 7.4.1.4.7 Cert Hash Types 50
7.4.1.4.8 Procedure for Defining New Extensions 51
7.4.2. Server certificate 52 7.4.2. Server certificate 52
7.4.3. Server key exchange message 53 7.4.3. Server key exchange message 53
7.4.4. CertificateStatus 56 7.4.4. CertificateStatus 56
7.4.5. Certificate request 57 7.4.5. Certificate request 56
7.4.6. Server hello done 58 7.4.6. Server hello done 58
7.4.7. Client certificate 58 7.4.7. Client certificate 59
7.4.8. Client Certificate URLs 59 7.4.8. Client Certificate URLs 59
7.4.9. Client key exchange message 61 7.4.9. Client key exchange message 61
7.4.9.1. RSA encrypted premaster secret message 62 7.4.9.1. RSA encrypted premaster secret message 62
7.4.9.2. Client Diffie-Hellman public value 64 7.4.9.2. Client Diffie-Hellman public value 64
7.4.10. Certificate verify 64 7.4.10. Certificate verify 65
7.4.10. Finished 65 7.4.10. Finished 65
8. Cryptographic computations 66 8. Cryptographic computations 66
8.1. Computing the master secret 66 8.1. Computing the master secret 67
8.1.1. RSA 67 8.1.1. RSA 68
8.1.2. Diffie-Hellman 67 8.1.2. Diffie-Hellman 68
9. Mandatory Cipher Suites 67 9. Mandatory Cipher Suites 68
A. Protocol constant values 71 A. Protocol constant values 72
A.1. Record layer 71 A.1. Record layer 72
A.2. Change cipher specs message 72 A.2. Change cipher specs message 73
A.3. Alert messages 72 A.3. Alert messages 73
A.4. Handshake protocol 74 A.4. Handshake protocol 75
A.4.1. Hello messages 74 A.4.1. Hello messages 75
A.4.2. Server authentication and key exchange messages 77 A.4.2. Server authentication and key exchange messages 78
A.4.3. Client authentication and key exchange messages 78 A.4.3. Client authentication and key exchange messages 79
A.4.4. Handshake finalization message 79 A.4.4. Handshake finalization message 80
A.5. The CipherSuite 80 A.5. The CipherSuite 81
A.6. The Security Parameters 82 A.6. The Security Parameters 84
B. Glossary 84 B. Glossary 85
C. CipherSuite definitions 88 C. CipherSuite definitions 89
D. Implementation Notes 90 D. Implementation Notes 91
D.1 Random Number Generation and Seeding 90 D.1 Random Number Generation and Seeding 91
D.2 Certificates and authentication 90 D.2 Certificates and authentication 91
D.3 CipherSuites 90 D.3 CipherSuites 91
E. Backward Compatibility With SSL 91 E. Backward Compatibility With SSL 92
E.1. Version 2 client hello 92 E.1. Version 2 client hello 93
E.2. Avoiding man-in-the-middle version rollback 93 E.2. Avoiding man-in-the-middle version rollback 94
F. Security analysis 95 F. Security analysis 96
F.1. Handshake protocol 95 F.1. Handshake protocol 96
F.1.1. Authentication and key exchange 95 F.1.1. Authentication and key exchange 96
F.1.1.1. Anonymous key exchange 95 F.1.1.1. Anonymous key exchange 96
F.1.1.2. RSA key exchange and authentication 96 F.1.1.2. RSA key exchange and authentication 97
F.1.1.3. Diffie-Hellman key exchange with authentication 97 F.1.1.3. Diffie-Hellman key exchange with authentication 98
F.1.2. Version rollback attacks 97 F.1.2. Version rollback attacks 98
F.1.3. Detecting attacks against the handshake protocol 98 F.1.3. Detecting attacks against the handshake protocol 99
F.1.4. Resuming sessions 98 F.1.4. Resuming sessions 99
F.1.5 Extensions 99 F.1.5 Extensions 100
F.1.5.1 Security of server_name 99 F.1.5.1 Security of server_name 100
F.1.5.2 Security of client_certificate_url 100 F.1.5.2 Security of client_certificate_url 101
F.1.5.4. Security of trusted_ca_keys 101 F.1.5.4. Security of trusted_ca_keys 102
F.1.5.5. Security of truncated_hmac 101 F.1.5.5. Security of truncated_hmac 102
F.1.5.6. Security of status_request 102 F.1.5.6. Security of status_request 103
F.2. Protecting application data 102 F.2. Protecting application data 103
F.3. Explicit IVs 103 F.3. Explicit IVs 104
F.4 Security of Composite Cipher Modes 103 F.4 Security of Composite Cipher Modes 104
F.5 Denial of Service 104 F.5 Denial of Service 105
F.6. Final notes 104 F.6. Final notes 105
Change history Change history
18-Feb-06 First draft by ekr@rtfm.com 18-Feb-06 First draft by ekr@rtfm.com
1. Introduction 1. Introduction
The primary goal of the TLS Protocol is to provide privacy and data The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications. The protocol is integrity between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS Handshake composed of two layers: the TLS Record Protocol and the TLS Handshake
skipping to change at page 112, line ? skipping to change at page 111, line ?
- Merged in TLS Extensions and AES Cipher Suites from external - Merged in TLS Extensions and AES Cipher Suites from external
documents. documents.
- Replacement of MD5/SHA-1 combination in the PRF - Replacement of MD5/SHA-1 combination in the PRF
- Replacement of MD5/SHA-1 combination in the digitally-signed - Replacement of MD5/SHA-1 combination in the digitally-signed
element. element.
- Allow the client to indicate which hash functions it supports. - Allow the client to indicate which hash functions it supports.
- Allow the server to indicate which has functions it supports
1.1 Requirements Terminology 1.1 Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described "MAY" that appear in this document are to be interpreted as described
in RFC 2119 [REQ]. in RFC 2119 [REQ].
2. Goals 2. Goals
The goals of TLS Protocol, in order of their priority, are: The goals of TLS Protocol, in order of their priority, are:
skipping to change at page 112, line ? skipping to change at page 111, line ?
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
5. HMAC and the pseudorandom function 5. HMAC and the pseudorandom function
A number of operations in the TLS record and handshake layer required A number of operations in the TLS record and handshake layer required
a keyed MAC; this is a secure digest of some data protected by a a keyed MAC; this is a secure digest of some data protected by a
secret. Forging the MAC is infeasible without knowledge of the MAC secret. Forging the MAC is infeasible without knowledge of the MAC
secret. The construction we use for this operation is known as HMAC, secret. The construction we use for this operation is known as HMAC,
described in [HMAC]. described in [HMAC].
HMAC can be used with a variety of different hash algorithms. TLS
uses it in the handshake with two different algorithms: MD5 and
SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
data). Additional hash algorithms can be defined by cipher suites and
used to protect record data, but MD5 and SHA-1 are hard coded into
the description of the handshaking for this version of the protocol.
In addition, a construction is required to do expansion of secrets In addition, a construction is required to do expansion of secrets
into blocks of data for the purposes of key generation or validation. into blocks of data for the purposes of key generation or validation.
This pseudo-random function (PRF) takes as input a secret, a seed, This pseudo-random function (PRF) takes as input a secret, a seed,
and an identifying label and produces an output of arbitrary length. and an identifying label and produces an output of arbitrary length.
First, we define a data expansion function, P_hash(secret, data) First, we define a data expansion function, P_hash(secret, data)
which uses a single hash function to expand a secret and seed into an which uses a single hash function to expand a secret and seed into an
arbitrary quantity of output: arbitrary quantity of output:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
skipping to change at page 112, line ? skipping to change at page 111, line ?
ProtocolVersion version; ProtocolVersion version;
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
} TLSPlaintext; } TLSPlaintext;
type type
The higher level protocol used to process the enclosed fragment. The higher level protocol used to process the enclosed fragment.
version version
The version of the protocol being employed. This document The version of the protocol being employed. This document
describes TLS Version 1.1, which uses the version { 3, 2 }. The describes TLS Version 1.2, which uses the version { 3, 3 }. The
version value 3.2 is historical: TLS version 1.1 is a minor version value 3.3 is historical, deriving from the use of 3.1 for
modification to the TLS 1.0 protocol, which was itself a minor TLS 1.0. (See Appendix A.1).
modification to the SSL 3.0 protocol, which bears the version
value 3.0. (See Appendix A.1).
length length
The length (in bytes) of the following TLSPlaintext.fragment. The length (in bytes) of the following TLSPlaintext.fragment.
The length should not exceed 2^14. The length should not exceed 2^14.
fragment fragment
The application data. This data is transparent and treated as an The application data. This data is transparent and treated as an
independent block to be dealt with by the higher level protocol independent block to be dealt with by the higher level protocol
specified by the type field. specified by the type field.
Note: Data of different TLS Record layer content types MAY be Note: Data of different TLS Record layer content types MAY be
interleaved. Application data is generally of higher precedence interleaved. Application data is generally of lower precedence
for transmission than other content types and therefore handshake for transmission than other content types. However, records MUST
records may be held if application data is pending. However, be delivered to the network in the same order as they are
records MUST be delivered to the network in the same order as protected by the record layer. Recipients MUST receive and
they are protected by the record layer. Recipients MUST receive process interleaved application layer traffic during handshakes
and process interleaved application layer traffic during subsequent to the first one on a connection.
handshakes subsequent to the first one on a connection.
6.2.2. Record compression and decompression 6.2.2. Record compression and decompression
All records are compressed using the compression algorithm defined in All records are compressed using the compression algorithm defined in
the current session state. There is always an active compression the current session state. There is always an active compression
algorithm; however, initially it is defined as algorithm; however, initially it is defined as
CompressionMethod.null. The compression algorithm translates a CompressionMethod.null. The compression algorithm translates a
TLSPlaintext structure into a TLSCompressed structure. Compression TLSPlaintext structure into a TLSCompressed structure. Compression
functions are initialized with default state information whenever a functions are initialized with default state information whenever a
connection state is made active. connection state is made active.
skipping to change at page 112, line ? skipping to change at page 111, line ?
The change cipher spec message is sent by both the client and server The change cipher spec message is sent by both the client and server
to notify the receiving party that subsequent records will be to notify the receiving party that subsequent records will be
protected under the newly negotiated CipherSpec and keys. Reception protected under the newly negotiated CipherSpec and keys. Reception
of this message causes the receiver to instruct the Record Layer to of this message causes the receiver to instruct the Record Layer to
immediately copy the read pending state into the read current state. immediately copy the read pending state into the read current state.
Immediately after sending this message, the sender MUST instruct the Immediately after sending this message, the sender MUST instruct the
record layer to make the write pending state the write active state. record layer to make the write pending state the write active state.
(See section 6.1.) The change cipher spec message is sent during the (See section 6.1.) The change cipher spec message is sent during the
handshake after the security parameters have been agreed upon, but handshake after the security parameters have been agreed upon, but
before the verifying finished message is sent (see section 7.4.9). before the verifying finished message is sent (see section 7.4.11
Note: if a rehandshake occurs while data is flowing on a connection, Note: if a rehandshake occurs while data is flowing on a connection,
the communicating parties may continue to send data using the old the communicating parties may continue to send data using the old
CipherSpec. However, once the ChangeCipherSpec has been sent, the new CipherSpec. However, once the ChangeCipherSpec has been sent, the new
CipherSpec MUST be used. The first side to send the ChangeCipherSpec CipherSpec MUST be used. The first side to send the ChangeCipherSpec
does not know that the other side has finished computing the new does not know that the other side has finished computing the new
keying material (e.g. if it has to perform a time consuming public keying material (e.g. if it has to perform a time consuming public
key operation). Thus, a small window of time during which the key operation). Thus, a small window of time during which the
recipient must buffer the data MAY exist. In practice, with modern recipient must buffer the data MAY exist. In practice, with modern
machines this interval is likely to be fairly short. machines this interval is likely to be fairly short.
skipping to change at page 112, line ? skipping to change at page 111, line ?
struct { struct {
HashType<255> types; HashType<255> types;
} CertHashTypes; } CertHashTypes;
These values indicate support for MD5 [MD5], SHA-1, SHA-256, and These values indicate support for MD5 [MD5], SHA-1, SHA-256, and
SHA-512 [SHA] respectively. The server MUST NOT send this extension. SHA-512 [SHA] respectively. The server MUST NOT send this extension.
Clients SHOULD send this extension if they support any algorithm Clients SHOULD send this extension if they support any algorithm
other than SHA-1. If this extension is not used, servers SHOULD other than SHA-1. If this extension is not used, servers SHOULD
assume that the client supports only SHA-1. assume that the client supports only SHA-1. Note: this is a change
from TLS 1.1 where there are no explicit rules but as a practical
matter one can assume that the peer supports MD5 and SHA-1.
HashType values are divided into three groups:
1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
reserved for IETF Standards Track protocols.
2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
are reserved for assignment for non-Standards Track methods.
3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
inclusive are reserved for private use.
Additional information describing the role of IANA in the
allocation of HashType code points is described
in Section 11.
7.4.1.4.8 Procedure for Defining New Extensions 7.4.1.4.8 Procedure for Defining New Extensions
The list of extension types, as defined in Section 2.3, is maintained The list of extension types, as defined in Section 2.3, is
by the Internet Assigned Numbers Authority (IANA). Thus an maintained by the Internet Assigned Numbers Authority (IANA). Thus
application needs to be made to the IANA in order to obtain a new an application needs to be made to the IANA in order to obtain a new
extension type value. Since there are subtle (and not so subtle) extension type value. Since there are subtle (and not so subtle)
interactions that may occur in this protocol between new features and interactions that may occur in this protocol between new features and
existing features which may result in a significant reduction in existing features which may result in a significant reduction in
overall security, new values SHALL be defined only through the IETF overall security, new values SHALL be defined only through the IETF
Consensus process specified in [IANA]. Consensus process specified in [IANA].
(This means that new assignments can be made only via RFCs approved (This means that new assignments can be made only via RFCs approved
by the IESG.) by the IESG.)
The following considerations should be taken into account when The following considerations should be taken into account when
designing new extensions: designing new extensions:
- All of the extensions defined in this document follow the - All of the extensions defined in this document follow the
convention that for each extension that a client requests and convention that for each extension that a client requests and that
that the server understands, the server replies with an extension the server understands, the server replies with an extension of
of the same type. the same type.
- Some cases where a server does not agree to an extension are - Some cases where a server does not agree to an extension are error
error
conditions, and some simply a refusal to support a particular conditions, and some simply a refusal to support a particular
feature. In general error alerts should be used for the former, feature. In general error alerts should be used for the former,
and a field in the server extension response for the latter. and a field in the server extension response for the latter.
- Extensions should as far as possible be designed to prevent any - Extensions should as far as possible be designed to prevent any
attack that forces use (or non-use) of a particular feature by attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages. This principle should be manipulation of handshake messages. This principle should be
followed regardless of whether the feature is believed to cause a followed regardless of whether the feature is believed to cause a
security problem. security problem.
Often the fact that the extension fields are included in the Often the fact that the extension fields are included in the
inputs to the Finished message hashes will be sufficient, but inputs to the Finished message hashes will be sufficient, but
extreme care is needed when the extension changes the meaning of extreme care is needed when the extension changes the meaning of
messages sent in the handshake phase. Designers and implementors messages sent in the handshake phase. Designers and implementors
should be aware of the fact that until the handshake has been should be aware of the fact that until the handshake has been
authenticated, active attackers can modify messages and insert, authenticated, active attackers can modify messages and insert,
remove, or replace extensions. remove, or replace extensions.
- It would be technically possible to use extensions to change - It would be technically possible to use extensions to change major
major
aspects of the design of TLS; for example the design of cipher aspects of the design of TLS; for example the design of cipher
suite negotiation. This is not recommended; it would be more suite negotiation. This is not recommended; it would be more
appropriate to define a new version of TLS - particularly since appropriate to define a new version of TLS - particularly since
the TLS handshake algorithms have specific protection against the TLS handshake algorithms have specific protection against
version rollback attacks based on the version number, and the version rollback attacks based on the version number, and the
possibility of version rollback should be a significant possibility of version rollback should be a significant
consideration in any major design change. consideration in any major design change.
7.4.2. Server certificate 7.4.2. Server certificate
When this message will be sent: When this message will be sent:
The server MUST send a certificate whenever the agreed-upon key The server MUST send a certificate whenever the agreed-upon key
exchange method is not an anonymous one. This message will always exchange method is not an anonymous one. This message will
immediately follow the server hello message. always immediately follow the server hello message.
Meaning of this message: Meaning of this message:
The certificate type MUST be appropriate for the selected cipher The certificate type MUST be appropriate for the selected cipher
suite's key exchange algorithm, and is generally an X.509v3 suite's key exchange algorithm, and is generally an X.509v3
certificate. It MUST contain a key which matches the key exchange certificate. It MUST contain a key which matches the key
method, as follows. Unless otherwise specified, the signing exchange method, as follows. Unless otherwise specified, the
algorithm for the certificate MUST be the same as the algorithm signing
for the certificate key. Unless otherwise specified, the public algorithm for the certificate MUST be the same as the
key MAY be of any length. algorithm for the certificate key. Unless otherwise specified,
the public key MAY be of any length.
Key Exchange Algorithm Certificate Key Type Key Exchange Algorithm Certificate Key Type
RSA RSA public key; the certificate MUST RSA RSA public key; the certificate MUST
allow the key to be used for encryption. allow the key to be used for encryption.
DHE_DSS DSS public key. DHE_DSS DSS public key.
DHE_RSA RSA public key which can be used for DHE_RSA RSA public key which can be used for
signing. signing.
skipping to change at page 112, line ? skipping to change at page 111, line ?
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 Clients requesting an OCSP response, and receiving an OCSP response
in a "CertificateStatus" message MUST check the OCSP response and in a "CertificateStatus" message MUST check the OCSP response and
abort the handshake if the response is not satisfactory. abort the handshake if the response is not satisfactory.
7.4.5. Certificate request 7.4.5. Certificate request
When this message will be sent: When this message will be sent:
A non-anonymous server can optionally request a certificate from A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the Server Key Exchange message, if sent, will immediately follow the Server Key Exchange
message (if it is sent; otherwise, the Server Certificate message (if it is sent; otherwise, the Server Certificate
message). message).
Structure of this message: Structure of this message:
enum { enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20), fortezza_dms_RESERVED(20),
(255) (255)
} ClientCertificateType; } ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; ClientCertificateType certificate_types<1..2^8-1>;
HashType certificate_hash<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
certificate_types certificate_types
This field is a list of the types of certificates requested, This field is a list of the types of certificates requested,
sorted in order of the server's preference. sorted in order of the server's preference.
certificate_types
A list of the types of certificate types which the client may
offer.
rsa_sign a certificate containing an RSA key
dss_sign a certificate containing a DSS key
rsa_fixed_dh a certificate signed with RSA and containing
a static DH key.
dss_fixed_dh a certificate signed with DSS and containing
a static DH key
Certificate types rsa_sign and dss_sign SHOULD contain
certificates signed with the same algorithm. However, this is
not required. This is a holdover from TLS 1.0 and 1.1.
certificate_hash
A list of acceptable hash algorithms to be used in
certificate signatures.
certificate_authorities certificate_authorities
A list of the distinguished names of acceptable certificate A list of the distinguished names of acceptable certificate
authorities. These distinguished names may specify a desired authorities. These distinguished names may specify a desired
distinguished name for a root CA or for a subordinate CA; distinguished name for a root CA or for a subordinate CA;
thus, this message can be used both to describe known roots thus, this message can be used both to describe known roots
and a desired authorization space. If the and a desired authorization space. If the
certificate_authorities list is empty then the client MAY certificate_authorities list is empty then the client MAY
send any certificate of the appropriate send any certificate of the appropriate
ClientCertificateType, unless there is some external ClientCertificateType, unless there is some external
arrangement to the contrary. arrangement to the contrary.
ClientCertificateType values are divided into three groups: ClientCertificateType values are divided into three groups:
1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
reserved for IETF Standards Track protocols. reserved for IETF Standards Track protocols.
2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive 2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
are reserved for assignment for non-Standards Track methods. inclusive are reserved for assignment for non-Standards
Track methods.
3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
inclusive are reserved for private use. inclusive are reserved for private use.
Additional information describing the role of IANA in the Additional information describing the role of IANA in the
allocation of ClientCertificateType code points is described allocation of ClientCertificateType code points is described
in Section 11. in Section 11.
Note: Values listed as RESERVED may not be used. They were used in SSLv3. Note: Values listed as RESERVED may not be used. They were used in
SSLv3.
Note: DistinguishedName is derived from [X501]. DistinguishedNames are Note: DistinguishedName is derived from [X501]. DistinguishedNames are
represented in DER-encoded format. represented in DER-encoded format.
Note: It is a fatal handshake_failure alert for an anonymous server to Note: It is a fatal handshake_failure alert for an anonymous server to
request client authentication. request client authentication.
7.4.6. Server hello done 7.4.6. Server hello done
When this message will be sent: When this message will be sent:
skipping to change at page 112, line ? skipping to change at page 111, line ?
} CertChainType; } CertChainType;
enum { enum {
false(0), true(1) false(0), true(1)
} Boolean; } Boolean;
struct { struct {
CertChainType type; CertChainType type;
URLAndOptionalHash url_and_hash_list<1..2^16-1>; URLAndOptionalHash url_and_hash_list<1..2^16-1>;
} CertificateURL; } CertificateURL;
struct { struct {
opaque url<1..2^16-1>; opaque url<1..2^16-1>;
Boolean hash_present; Boolean hash_present;
select (hash_present) { select (hash_present) {
case false: struct {}; case false: struct {};
case true: SHA1Hash; case true: SHA1Hash;
} hash; } hash;
} URLAndOptionalHash; } URLAndOptionalHash;
opaque SHA1Hash[20]; opaque SHA1Hash[20];
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 - if CertificateURL.type is "individual_certs", each URL refers to
a a single DER-encoded X.509v3 certificate, with the URL for the
single DER-encoded X.509v3 certificate, with the URL for the
client's certificate first, or client's certificate first, or
- 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. PkiPath described in Section 8.
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.
skipping to change at page 112, line ? skipping to change at page 111, line ?
this message. This is only data visible at the handshake this message. This is only data visible at the handshake
layer and does not include record layer headers. This is the layer and does not include record layer headers. This is the
concatenation of all the Handshake structures as defined in concatenation of all the Handshake structures as defined in
7.4 exchanged thus far. 7.4 exchanged thus far.
It is a fatal error if a finished message is not preceded by a change It is a fatal error if a finished message is not preceded by a change
cipher spec message at the appropriate point in the handshake. cipher spec message at the appropriate point in the handshake.
The value handshake_messages includes all handshake messages starting The value handshake_messages includes all handshake messages starting
at client hello up to, but not including, this finished message. This at client hello up to, but not including, this finished message. This
may be different from handshake_messages in Section 7.4.8 because it may be different from handshake_messages in Section 7.4.10 because it
would include the certificate verify message (if sent). Also, the would include the certificate verify message (if sent). Also, the
handshake_messages for the finished message sent by the client will handshake_messages for the finished message sent by the client will
be different from that for the finished message sent by the server, be different from that for the finished message sent by the server,
because the one which is sent second will include the prior one. because the one which is sent second will include the prior one.
Note: Change cipher spec messages, alerts and any other record types Note: Change cipher spec messages, alerts and any other record types
are not handshake messages and are not included in the hash are not handshake messages and are not included in the hash
computations. Also, Hello Request messages are omitted from computations. Also, Hello Request messages are omitted from
handshake hashes. handshake hashes.
skipping to change at page 112, line ? skipping to change at page 111, line ?
fragmented, compressed and encrypted based on the current connection fragmented, compressed and encrypted based on the current connection
state. The messages are treated as transparent data to the record state. The messages are treated as transparent data to the record
layer. layer.
11. IANA Considerations 11. IANA Considerations
This document describes a number of new registries to be created by This document describes a number of new registries to be created by
IANA. We recommend that they be placed as individual registries items IANA. We recommend that they be placed as individual registries items
under a common TLS category. under a common TLS category.
Section 7.4.3 describes a TLS ClientCertificateType Registry to be Section 7.4.5 describes a TLS HashType Registry to be maintained by
the IANA, as defining a number of such code point identifiers.
HashType identifiers with values in the range 0-63 (decimal)
inclusive are assigned via RFC 2434 Standards Action. Values from the
range 64-223 (decimal) inclusive are assigned via [RFC 2434]
Specification Required. Identifier values from 224-255 (decimal)
inclusive are reserved for RFC 2434 Private Use. The registry will be
initially populated with the values in this document, Section 7.4.5.
Section 7.4.5 describes a TLS ClientCertificateType Registry to be
maintained by the IANA, as defining a number of such code point maintained by the IANA, as defining a number of such code point
identifiers. ClientCertificateType identifiers with values in the identifiers. ClientCertificateType identifiers with values in the
range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
Action. Values from the range 64-223 (decimal) inclusive are assigned Action. Values from the range 64-223 (decimal) inclusive are assigned
via [RFC 2434] Specification Required. Identifier values from via [RFC 2434] Specification Required. Identifier values from
224-255 (decimal) inclusive are reserved for RFC 2434 Private Use. 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
The registry will be initially populated with the values in this The registry will be initially populated with the values in this
document, Section 7.4.4. document, Section 7.4.5.
Section A.5 describes a TLS Cipher Suite Registry to be maintained by Section A.5 describes a TLS Cipher Suite Registry to be maintained by
the IANA, as well as defining a number of such cipher suite the IANA, as well as defining a number of such cipher suite
identifiers. Cipher suite values with the first byte in the range identifiers. Cipher suite values with the first byte in the range
0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action. 0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action.
Values with the first byte in the range 192-254 (decimal) are Values with the first byte in the range 192-254 (decimal) are
assigned via RFC 2434 Specification Required. Values with the first assigned via RFC 2434 Specification Required. Values with the first
byte 255 (decimal) are reserved for RFC 2434 Private Use. The byte 255 (decimal) are reserved for RFC 2434 Private Use. The
registry will be initially populated with the values from Section A.5 registry will be initially populated with the values from Section A.5
of this document, [TLSAES], and Section 3 of [TLSKRB]. of this document, [TLSAES], and Section 3 of [TLSKRB].
skipping to change at page 112, line ? skipping to change at page 111, line ?
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
Cipher specifications native to TLS can be included in Version 2.0 Cipher specifications native to TLS can be included in Version 2.0
client hello messages using the syntax below. Any V2CipherSpec client hello messages using the syntax below. Any V2CipherSpec
element with its first byte equal to zero will be ignored by Version element with its first byte equal to zero will be ignored by Version
2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD 2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
also include the TLS equivalent (see Appendix A.5): also include the TLS equivalent (see Appendix A.5):
V2CipherSpec (see TLS name) = { 0x00, CipherSuite }; V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
Note: TLS 1.1 clients may generate the SSLv2 EXPORT cipher suites in Note: TLS 1.2 clients may generate the SSLv2 EXPORT cipher suites in
handshakes for backward compatibility but MUST NOT negotiate them in handshakes for backward compatibility but MUST NOT negotiate them in
TLS 1.1 mode. TLS 1.2 mode.
E.1. Version 2 client hello E.1. Version 2 client hello
The Version 2.0 client hello message is presented below using this The Version 2.0 client hello message is presented below using this
document's presentation model. The true definition is still assumed document's presentation model. The true definition is still assumed
to be the SSL Version 2.0 specification. Note that this message MUST to be the SSL Version 2.0 specification. Note that this message MUST
be sent directly on the wire, not wrapped as an SSLv3 record be sent directly on the wire, not wrapped as an SSLv3 record
uint8 V2CipherSpec[3]; uint8 V2CipherSpec[3];
skipping to change at page 112, line ? skipping to change at page 111, line ?
leading to an acceptable certificate authority. Similarly, leading to an acceptable certificate authority. Similarly,
authenticated clients must supply an acceptable certificate to the authenticated clients must supply an acceptable certificate to the
server. Each party is responsible for verifying that the other's server. Each party is responsible for verifying that the other's
certificate is valid and has not expired or been revoked. certificate is valid and has not expired or been revoked.
The general goal of the key exchange process is to create a The general goal of the key exchange process is to create a
pre_master_secret known to the communicating parties and not to pre_master_secret known to the communicating parties and not to
attackers. The pre_master_secret will be used to generate the attackers. The pre_master_secret will be used to generate the
master_secret (see Section 8.1). The master_secret is required to master_secret (see Section 8.1). The master_secret is required to
generate the finished messages, encryption keys, and MAC secrets (see generate the finished messages, encryption keys, and MAC secrets (see
Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished Sections 7.4.10, 7.4.11 and 6.3). By sending a correct finished
message, parties thus prove that they know the correct message, parties thus prove that they know the correct
pre_master_secret. pre_master_secret.
F.1.1.1. Anonymous key exchange F.1.1.1. Anonymous key exchange
Completely anonymous sessions can be established using RSA or Diffie- Completely anonymous sessions can be established using RSA or Diffie-
Hellman for key exchange. With anonymous RSA, the client encrypts a Hellman for key exchange. With anonymous RSA, the client encrypts a
pre_master_secret with the server's uncertified public key extracted pre_master_secret with the server's uncertified public key extracted
from the server key exchange message. The result is sent in a client from the server key exchange message. The result is sent in a client
key exchange message. Since eavesdroppers do not know the server's key exchange message. Since eavesdroppers do not know the server's
skipping to change at page 112, line ? skipping to change at page 111, line ?
a private key can be limited by changing one's private key (and a private key can be limited by changing one's private key (and
certificate) frequently. certificate) frequently.
After verifying the server's certificate, the client encrypts a After verifying the server's certificate, the client encrypts a
pre_master_secret with the server's public key. By successfully pre_master_secret with the server's public key. By successfully
decoding the pre_master_secret and producing a correct finished decoding the pre_master_secret and producing a correct finished
message, the server demonstrates that it knows the private key message, the server demonstrates that it knows the private key
corresponding to the server certificate. corresponding to the server certificate.
When RSA is used for key exchange, clients are authenticated using When RSA is used for key exchange, clients are authenticated using
the certificate verify message (see Section 7.4.8). The client signs the certificate verify message (see Section 7.4.10). The client signs
a value derived from the master_secret and all preceding handshake a value derived from the master_secret and all preceding handshake
messages. These handshake messages include the server certificate, messages. These handshake messages include the server certificate,
which binds the signature to the server, and ServerHello.random, which binds the signature to the server, and ServerHello.random,
which binds the signature to the current handshake process. which binds the signature to the current handshake process.
F.1.1.3. Diffie-Hellman key exchange with authentication F.1.1.3. Diffie-Hellman key exchange with authentication
When Diffie-Hellman key exchange is used, the server can either When Diffie-Hellman key exchange is used, the server can either
supply a certificate containing fixed Diffie-Hellman parameters or supply a certificate containing fixed Diffie-Hellman parameters or
can use the server key exchange message to send a set of temporary can use the server key exchange message to send a set of temporary
skipping to change at page 112, line ? skipping to change at page 111, line ?
[TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
September 1981. September 1981.
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
practical", USENIX Security Symposium 2003. practical", USENIX Security Symposium 2003.
[TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0", [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[TLS1.1] Dierks, T., and Rescorla, E., "The TLS Protocol, Version
1.1", RFC 4346, April, 2006.
[X501] ITU-T Recommendation X.501: Information Technology - Open [X501] ITU-T Recommendation X.501: Information Technology - Open
Systems Interconnection - The Directory: Models, 1993. Systems Interconnection - The Directory: Models, 1993.
[X509] ITU-T Recommendation X.509 (1997 E): Information Technology - [X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
Open Systems Interconnection - "The Directory - Open Systems Interconnection - "The Directory -
Authentication Framework". 1988. Authentication Framework". 1988.
[XDR] R. Srinivansan, Sun Microsystems, "XDR: External Data [XDR] R. Srinivansan, Sun Microsystems, "XDR: External Data
Representation Standard", RFC 1832, August 1995. Representation Standard", RFC 1832, August 1995.
 End of changes. 34 change blocks. 
127 lines changed or deleted 169 lines changed or added

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