enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} Signature;
7.4.4. Certificate request
When this message will be sent:
A non-anonymous server can optionally request a certificate from
the client, if it is appropriate for the selected cipher suite.
This message, if sent, will immediately follow the Server Key
Exchange message (if it is sent; otherwise, the Server Certificate
message).
Structure of this message:
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
(255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
certificate_types
This field is a list of the types of certificates requested,
sorted in order of the server’s preference.
certificate_authorities
A list of the distinguished names of acceptable certificate
authorities. These distinguished names may specify a desired
distinguished name for a root CA or for a subordinate CA; thus,
this message can be used to describe both known roots and a
desired authorization space. If the certificate_authorities
list is empty then the client MAY send any certificate of the
appropriate ClientCertificateType, unless there is some
external arrangement to the contrary.
ClientCertificateType 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 ClientCertificateType code points is described in Section 11.
Note: Values listed as RESERVED may not be used. They were used in
SSLv3.
Note: DistinguishedName is derived from [X501]. DistinguishedNames
are represented in DER-encoded format.
Note: It is a fatal handshake_failure alert for an anonymous server
to request client authentication.
7.4.5. Server Hello Done
When this message will be sent:
The server hello done message is sent by the server to indicate
the end of the server hello and associated messages. After
sending this message, the server will wait for a client response.
Meaning of this message:
This message means that the server is done sending messages to
support the key exchange, and the client can proceed with its
phase of the key exchange.
Upon receipt of the server hello done message, the client SHOULD
verify that the server provided a valid certificate, if required
and check that the server hello parameters are acceptable.
Structure of this message:
struct { } ServerHelloDone;
7.4.6. Client certificate
When this message will be sent:
This is the first message the client can send after receiving a
server hello done message. This message is only sent if the
server requests a certificate. If no suitable certificate is
available, the client SHOULD send a certificate message containing
no certificates. That is, the certificate_list structure has a
length of zero. If client authentication is required by the
server for the handshake to continue, it may respond with a fatal
handshake failure alert. Client certificates are sent using the
Certificate structure defined in Section 7.4.2.
Note: When using a static Diffie-Hellman based key exchange method
(DH_DSS or DH_RSA), if client authentication is requested, the
Diffie-Hellman group and generator encoded in the client’s
certificate MUST match the server specified Diffie-Hellman
parameters if the client’s parameters are to be used for the key
exchange.
7.4.7. Client Key Exchange Message
When this message will be sent:
This message is always sent by the client. It MUST immediately
follow the client certificate message, if it is sent. Otherwise
it MUST be the first message sent by the client after it receives
the server hello done message.
Meaning of this message:
With this message, the premaster secret is set, either though
direct transmission of the RSA-encrypted secret or by the
transmission of Diffie-Hellman parameters that will allow each
side to agree upon the same premaster secret. When the key
exchange method is DH_RSA or DH_DSS, client certification has been
requested, and the client was able to respond with a certificate
that contained a Diffie-Hellman public key whose parameters (group
and generator) matched those specified by the server in its
certificate, this message MUST not contain any data.
Structure of this message:
The choice of messages depends on which key exchange method has
been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
definition.
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
7.4.7.1. RSA Encrypted Premaster Secret Message
Meaning of this message:
If RSA is being used for key agreement and authentication, the
client generates a 48-byte premaster secret, encrypts it using the
public key from the server’s certificate or the temporary RSA key
provided in a server key exchange message, and sends the result in
an encrypted premaster secret message. This structure is a
variant of the client key exchange message and is not a message in
itself.
Structure of this message:
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
client_version The latest (newest) version supported by the
client. This is used to detect version roll-back attacks.
Upon receiving the premaster secret, the server SHOULD check
that this value matches the value transmitted by the client in
the client hello message.
random
46 securely-generated random bytes.
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
pre_master_secret
This random value is generated by the client and is used to
generate the master secret, as specified in Section 8.1.
Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be
used to attack a TLS server that is using PKCS#1 v 1.5 encoded
RSA. The attack takes advantage of the fact that, by failing
in different ways, a TLS server can be coerced into revealing
whether a particular message, when decrypted, is properly
PKCS#1 v1.5 formatted or not.
The best way to avoid vulnerability to this attack is to treat
incorrectly formatted messages in a manner indistinguishable
from correctly formatted RSA blocks. Thus, when a server
receives an incorrectly formatted RSA block, it should generate
a random 48-byte value and proceed using it as the premaster
secret. Thus, the server will act identically whether the
received RSA block is correctly encoded or not.
[PKCS1B] defines a newer version of PKCS#1 encoding that is
more secure against the Bleichenbacher attack. However, for
maximal compatibility with TLS 1.0, TLS 1.1 retains the
original encoding. No variants of the Bleichenbacher attack
are known to exist provided that the above recommendations are
followed.
Implementation Note: Public-key-encrypted data is represented as an
opaque vector <0..2^16-1> (see Section 4.7).
Thus, the RSA-encrypted PreMasterSecret in a
ClientKeyExchange is preceded by two length
bytes. These bytes are redundant in the case of
RSA because the EncryptedPreMasterSecret is the
only data in the ClientKeyExchange and its
length can therefore be unambiguously
determined. The SSLv3 specification was not
clear about the encoding of public-key-encrypted
data, and therefore many SSLv3 implementations
do not include the length bytes, encoding the
RSA encrypted data directly in the
ClientKeyExchange message.
This specification requires correct encoding of
the EncryptedPreMasterSecret complete with
length bytes. The resulting PDU is incompatible
with many SSLv3 implementations. Implementors
upgrading from SSLv3 must modify their
implementations to generate and accept the
correct encoding. Implementors who wish to be
compatible with both SSLv3 and TLS should make
their implementation’s behavior dependent on the
protocol version.
Implementation Note: It is now known that remote timing-based attacks
on SSL are possible, at least when the client
and server are on the same LAN. Accordingly,
implementations that use static RSA keys SHOULD
use RSA blinding or some other anti-timing
technique, as described in [TIMING].
Note: The version number in the PreMasterSecret MUST be the version
offered by the client in the ClientHello, not the version
negotiated for the connection. This feature is designed to
prevent rollback attacks. Unfortunately, many implementations
use the negotiated version instead, and therefore checking the
version number may lead to failure to interoperate with such
incorrect client implementations. Client implementations, MUST
and Server implementations MAY, check the version number. In
practice, since the TLS handshake MACs prevent downgrade and no
good attacks are known on those MACs, ambiguity is not
considered a serious security risk. Note that if servers
choose to check the version number, they should randomize the
PreMasterSecret in case of error, rather than generate an
alert, in order to avoid variants on the Bleichenbacher attack.
[KPR03]
7.4.7.2. Client Diffie-Hellman Public Value
Meaning of this message:
This structure conveys the client’s Diffie-Hellman public value
(Yc) if it was not already included in the client’s certificate.
The encoding used for Yc is determined by the enumerated
PublicValueEncoding. This structure is a variant of the client
key exchange message and not a message in itself.
Structure of this message:
enum { implicit, explicit } PublicValueEncoding;
implicit
If the client certificate already contains a suitable Diffie-
Hellman key, then Yc is implicit and does not need to be sent
again. In this case, the client key exchange message will be
sent, but it MUST be empty.
explicit
Yc needs to be sent.
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: opaque dh_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
dh_Yc
The client’s Diffie-Hellman public value (Yc).
7.4.8. Certificate verify
When this message will be sent:
This message is used to provide explicit verification of a client
certificate. This message is only sent following a client
certificate that has signing capability (i.e., all certificates
except those containing fixed Diffie-Hellman parameters). When
sent, it MUST immediately follow the client key exchange message.
Structure of this message:
struct {
Signature signature;
} CertificateVerify;
The Signature type is defined in 7.4.3.
CertificateVerify.signature.md5_hash
MD5(handshake_messages);
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
Here handshake_messages refers to all handshake messages sent or
received starting at client hello up to but not including this
message, including the type and length fields of the handshake
messages. This is the concatenation of all the Handshake structures,
as defined in 7.4, exchanged thus far.
7.4.9. Finished
When this message will be sent:
A finished message is always sent immediately after a change
cipher spec message to verify that the key exchange and
authentication processes were successful. It is essential that a
change cipher spec message be received between the other handshake
messages and the Finished message.
Meaning of this message:
The finished message is the first protected with the just-
negotiated algorithms, keys, and secrets. Recipients of finished
messages MUST verify that the contents are correct. Once a side
has sent its Finished message and received and validated the
Finished message from its peer, it may begin to send and receive
application data over the connection.
struct {
opaque verify_data[12];
} Finished;
verify_data
PRF(master_secret, finished_label, MD5(handshake_messages) +
SHA-1(handshake_messages)) [0..11];
finished_label
For Finished messages sent by the client, the string "client
finished". For Finished messages sent by the server, the
string "server finished".
handshake_messages
All of the data from all messages in this handshake (not
including any HelloRequest messages) up to but not including
this message. This is only data visible at the handshake
layer and does not include record layer headers. This is the
concatenation of all the Handshake structures, as defined in
7.4, exchanged thus far.
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.
The value handshake_messages includes all handshake messages starting
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 would include the certificate verify message (if sent).
Also, the handshake_messages for the finished message sent by the
client will be different from that for the finished message sent by
the server, because the one that is sent second will include the
prior one.
Note: Change cipher spec messages, alerts, and any other record types
are not handshake messages and are not included in the hash
computations. Also, Hello Request messages are omitted from
handshake hashes.
8. Cryptographic Computations
In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and
the client and server random values. The authentication, encryption,
and MAC algorithms are determined by the cipher_suite selected by the
server and revealed in the server hello message. The compression
algorithm is negotiated in the hello messages, and the random values
are exchanged in the hello messages. All that remains is to
calculate the master secret.
8.1. Computing the Master Secret
For all key exchange methods, the same algorithm is used to convert
the pre_master_secret into the master_secret. The pre_master_secret
should be deleted from memory once the master_secret has been
computed.
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
The master secret is always exactly 48 bytes in length. The length
of the premaster secret will vary depending on key exchange method.
8.1.1. RSA
When RSA is used for server authentication and key exchange, a 48-
byte pre_master_secret is generated by the client, encrypted under
the server’s public key, and sent to the server. The server uses its
private key to decrypt the pre_master_secret. Both parties then
convert the pre_master_secret into the master_secret, as specified
above.
RSA digital signatures are performed using PKCS #1 [PKCS1] block type
1. RSA public key encryption is performed using PKCS #1 block type 2.
8.1.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The
negotiated key (Z) is used as the pre_master_secret, and is converted
into the master_secret, as specified above. Leading bytes of Z that
contain all zero bits are stripped before it is used as the
pre_master_secret.
Note: Diffie-Hellman parameters are specified by the server and may
be either ephemeral or contained within the server’s
certificate.
9. Mandatory Cipher Suites
In the absence of an application profile standard specifying
otherwise, a TLS compliant application MUST implement the cipher
suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
10. Application Data Protocol
Application data messages are carried by the Record Layer and are
fragmented, compressed, and encrypted based on the current connection
state. The messages are treated as transparent data to the record
layer.
11. Security Considerations
Security issues are discussed throughout this memo, especially in
Appendices D, E, and F.
12. IANA Considerations
This document describes a number of new registries that have been
created by IANA. We recommended that they be placed as individual
registries items under a common TLS category.
Section 7.4.3 describes a TLS ClientCertificateType Registry to be
maintained by the IANA, defining a number of such code point
identifiers. ClientCertificateType 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 [RFC2434] Specification Required. Identifier values
from 224-255 (decimal) inclusive are reserved for RFC 2434 Private
Use. The registry will initially be populated with the values in
this document, Section 7.4.4.
Section A.5 describes a TLS Cipher Suite Registry to be maintained by
the IANA, and it defines a number of such cipher suite identifiers.
Cipher suite values with the first byte in the range 0-191 (decimal)
inclusive are assigned via RFC 2434 Standards Action. Values with
the first byte in the range 192-254 (decimal) are assigned via RFC
2434 Specification Required. Values with the first byte 255
(decimal) are reserved for RFC 2434 Private Use. The registry will
initially be populated with the values from Section A.5 of this
document, [TLSAES], and from Section 3 of [TLSKRB].
Section 6 requires that all ContentType values be defined by RFC 2434
Standards Action. IANA has created a TLS ContentType registry,
initially populated with values from Section 6.2.1 of this document.
Future values MUST be allocated via Standards Action as described in
[RFC2434].
Section 7.2.2 requires that all Alert values be defined by RFC 2434
Standards Action. IANA has created a TLS Alert registry, initially
populated with values from Section 7.2 of this document and from
Section 4 of [TLSEXT]. Future values MUST be allocated via Standards
Action as described in [RFC2434].
Section 7.4 requires that all HandshakeType values be defined by RFC
2434 Standards Action. IANA has created a TLS HandshakeType
registry, initially populated with values from Section 7.4 of this
document and from Section 2.4 of [TLSEXT]. Future values MUST be
allocated via Standards Action as described in [RFC2434].
Appendix A. Protocol Constant Values
This section describes protocol types and constants.
A.1. Record Layer
struct {
uint8 major, minor;
} ProtocolVersion;
ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSCompressed.length];