draft-ietf-tls-protocol-01.txt   draft-ietf-tls-protocol-02.txt 
Transport Layer Security Working Group Tim Dierks Transport Layer Security Working Group Tim Dierks
INTERNET-DRAFT Consensus Development INTERNET-DRAFT Consensus Development
Expires September 22, 1997 Christopher Allen
Christopher Allen
Consensus Development Consensus Development
March 24, 1997
Expires August 31, 1997 March 6, 1997
The TLS Protocol The TLS Protocol
Version 1.0 Version 1.0
<draft-ietf-tls-protocol-01.txt> <draft-ietf-tls-protocol-02.txt>
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other months and may be updated, replaced, or made obsolete by other
skipping to change at page 2, line 26 skipping to change at page 2, line 26
4.3. Vectors 6 4.3. Vectors 6
4.4. Numbers 7 4.4. Numbers 7
4.5. Enumerateds 7 4.5. Enumerateds 7
4.6. Constructed types 8 4.6. Constructed types 8
4.6.1. Variants 8 4.6.1. Variants 8
4.7. Cryptographic attributes 9 4.7. Cryptographic attributes 9
4.8. Constants 10 4.8. Constants 10
5. The TLS Record Protocol 11 5. The TLS Record Protocol 11
5.1. Connection states 11 5.1. Connection states 11
5.2. HMAC and the pseudorandom function 14 5.2. HMAC and the pseudorandom function 14
5.3. Record layer 14 5.3. Record layer 15
5.3.1. Fragmentation 14 5.3.1. Fragmentation 15
5.3.2. Record compression and decompression 15 5.3.2. Record compression and decompression 16
5.3.3. Record payload protection 16 5.3.3. Record payload protection 17
5.3.3.1. Null or standard stream cipher 17 5.3.3.1. Null or standard stream cipher 17
5.3.3.2. CBC block cipher 17 5.3.3.2. CBC block cipher 18
5.4. Key calculation 18 5.4. Key calculation 19
5.4.1. Export key generation example 20 5.4.1. Export key generation example 21
6. The TLS Handshake Protocol 20 6. The TLS Handshake Protocol 21
6.1. Change cipher spec protocol 21 6.1. Change cipher spec protocol 22
6.2. Alert protocol 22 6.2. Alert protocol 22
6.2.1. Closure alerts 22 6.2.1. Closure alerts 23
6.2.2. Error alerts 23 6.2.2. Error alerts 24
6.3. Handshake Protocol overview 25 6.3. Handshake Protocol overview 26
6.4. Handshake protocol 28 6.4. Handshake protocol 29
6.4.1. Hello messages 29 6.4.1. Hello messages 30
6.4.1.1. Hello request 29 6.4.1.1. Hello request 30
6.4.1.2. Client hello 29 6.4.1.2. Client hello 31
6.4.1.3. Server hello 32 6.4.1.3. Server hello 33
6.4.2. Server certificate 33 6.4.2. Server certificate 34
6.4.3. Server key exchange message 34 6.4.3. Server key exchange message 36
6.4.4. Certificate request 36 6.4.4. Certificate request 38
6.4.5. Server hello done 37 6.4.5. Server hello done 39
6.4.6. Client certificate 38 6.4.6. Client certificate 39
6.4.7. Client key exchange message 38 6.4.7. Client key exchange message 40
6.4.7.1. RSA encrypted premaster secret message 39 6.4.7.1. RSA encrypted premaster secret message 40
6.4.7.2. Client Diffie-Hellman public value 39 6.4.7.2. Client Diffie-Hellman public value 41
6.4.8. Certificate verify 40 6.4.8. Certificate verify 41
6.4.9. Finished 40 6.4.9. Finished 42
7. Cryptographic computations 41 7. Cryptographic computations 43
7.1. Computing the master secret 42 7.1. Computing the master secret 43
7.1.1. RSA 42 7.1.1. RSA 44
7.1.2. Diffie-Hellman 42 7.1.2. Diffie-Hellman 44
8. Application data protocol 42 8. Application data protocol 44
A. Protocol constant values 42 A. Protocol constant values 44
A.1. Reserved port assignments 43 A.1. Reserved port assignments 44
A.2. Record layer 43 A.2. Record layer 45
A.3. Change cipher specs message 44 A.3. Change cipher specs message 46
A.4. Alert messages 44 A.4. Alert messages 46
A.5. Handshake protocol 45 A.5. Handshake protocol 46
A.5.1. Hello messages 45 A.5.1. Hello messages 47
A.5.2. Server authentication and key exchange messages 46 A.5.2. Server authentication and key exchange messages 47
A.5.3. Client authentication and key exchange messages 47 A.5.3. Client authentication and key exchange messages 49
A.5.4. Handshake finalization message 47 A.5.4. Handshake finalization message 49
A.6. The CipherSuite 48 A.6. The CipherSuite 49
A.7. The Security Parameters 49 A.7. The Security Parameters 51
B. Glossary 50 B. Glossary 51
C. CipherSuite definitions 53 C. CipherSuite definitions 55
D. Implementation Notes 55 D. Implementation Notes 57
D.1. Temporary RSA keys 55 D.1. Temporary RSA keys 57
D.2. Random Number Generation and Seeding 55 D.2. Random Number Generation and Seeding 57
D.3. Certificates and authentication 56 D.3. Certificates and authentication 58
D.4. CipherSuites 56 D.4. CipherSuites 58
E. Backward Compatibility With SSL 56 E. Backward Compatibility With SSL 58
E.1. Version 2 client hello 58 E.1. Version 2 client hello 59
E.2. Avoiding man-in-the-middle version rollback 59 E.2. Avoiding man-in-the-middle version rollback 61
F. Security analysis 59 F. Security analysis 61
F.1. Handshake protocol 59 F.1. Handshake protocol 61
F.1.1. Authentication and key exchange 60 F.1.1. Authentication and key exchange 61
F.1.1.1. Anonymous key exchange 60 F.1.1.1. Anonymous key exchange 62
F.1.1.2. RSA key exchange and authentication 61 F.1.1.2. RSA key exchange and authentication 62
F.1.1.3. Diffie-Hellman key exchange with authentication 61 F.1.1.3. Diffie-Hellman key exchange with authentication 63
F.1.2. Version rollback attacks 62 F.1.2. Version rollback attacks 63
F.1.3. Detecting attacks against the handshake protocol 62 F.1.3. Detecting attacks against the handshake protocol 64
F.1.4. Resuming sessions 62 F.1.4. Resuming sessions 64
F.1.5. MD5 and SHA 63 F.1.5. MD5 and SHA 64
F.2. Protecting application data 63 F.2. Protecting application data 65
F.3. Final notes 63 F.3. Final notes 65
G. Patent Statement 64 G. Patent Statement 65
References 64 References 66
Credits 66 Credits 68
Comments 67 Comments 69
1. Introduction 1. Introduction
The primary goal of the TLS Protocol is to provide privacy and The primary goal of the TLS Protocol is to provide privacy and
reliability between two communicating applications. The protocol is reliability between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS composed of two layers: the TLS Record Protocol and the TLS
Handshake Protocol. At the lowest level, layered on top of some Handshake Protocol. At the lowest level, layered on top of some
reliable transport protocol (e.g., TCP[TCP]), is the TLS Record reliable transport protocol (e.g., TCP[TCP]), is the TLS Record
Protocol. The TLS Record Protocol provides connection security that Protocol. The TLS Record Protocol provides connection security that
has two basic properties: has two basic properties:
skipping to change at page 4, line 44 skipping to change at page 4, line 44
| authenticated connection the secret cannot be obtained, even by | authenticated connection the secret cannot be obtained, even by
| an attacker who can place himself in the middle of the | an attacker who can place himself in the middle of the
| connection. | connection.
- The negotiation is reliable: no attacker can modify the - The negotiation is reliable: no attacker can modify the
| negotiation communication without being detected by the parties | negotiation communication without being detected by the parties
| to the communication. | to the communication.
One advantage of TLS is that it is application protocol independent. One advantage of TLS is that it is application protocol independent.
| Higher level protocols can layer on top of the TLS Protocol | Higher level protocols can layer on top of the TLS Protocol
transparently. ] transparently. The TLS standard, however, does not specify how
] protocols add security with TLS; the decisions on how to initiate
] TLS handshaking and how to interpret the authentication certificates
] exchanged are left up to the judgement of the designers and
] implementors of protocols which run on top of TLS.
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:
1. Cryptographic security: TLS should be used to establish a secure 1. Cryptographic security: TLS should be used to establish a secure
connection between two parties. connection between two parties.
2. Interoperability: Independent programmers should be able to 2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that will then be able to develop applications utilizing TLS that will then be able to
skipping to change at page 14, line 15 skipping to change at page 14, line 17
5.2. HMAC and the pseudorandom function 5.2. HMAC and the pseudorandom function
| A number of operations in the TLS record and handshake layer | A number of operations in the TLS record and handshake layer
| required a keyed MAC; this is a secure digest of some data protected | required a keyed MAC; this is a secure digest of some data protected
| by a secret. Forging the MAC is infeasible without knowledge of the | by a secret. Forging the MAC is infeasible without knowledge of the
| MAC secret. Finding two data messages which have the same MAC is | MAC secret. Finding two data messages which have the same MAC is
| also cryptographically infeasible. The construction we use for this | also cryptographically infeasible. The construction we use for this
| operation is known as HMAC, described in [HMAC]. | operation is known as HMAC, described in [HMAC].
| HMAC can be used with a variety of different hash algorithms. TLS | HMAC can be used with a variety of different hash algorithms. TLS
| uses it with two different algorithms: MD5 and SHA-1, denoting these ] uses it in the handshake with two different algorithms: MD5 and
| as HMAC_MD5(secret, data) and HMAC_SHA(secret, data). In order to ] SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
| extend the security even further, an additional construction is ] data). Additional hash algorithms can be defined by cipher suites
| defined which uses both MD5 and SHA-1: HMAC_mix(secret, data) = ] and used to protect record data, but these hashes are hard coded
| HMAC_MD5(secret, HMAC_SHA(secret, data)). This provides some ] into the description of the handshaking for this version of the
| protection against either of the algorithms being completely broken. ] protocol.
| In addition, TLS needs the ability to generate a chunk of random ] In addition, a construction is required to do expansion of secrets
| data of arbitrary length from a secret and a seed. To do this, a ] into blocks of data for the purposes of key generation or
| pseudorandom function (PRF) is defined. This function generates data ] validation. This pseudo-random function (PRF) takes as input a
| by repeatedly applying HMAC_mix to the secret and seed, generating ] secret and a seed and produces an output of arbitrary length.
| 16 bytes at a time.
| PRF(secret, seed) = HMAC_mix(secret, 'A' + seed) + ] In order to make the PRF as secure as possible, it uses two hash
] algorithms in a way which should guarantee its security if either
] algorithm remains secure.
| HMAC_mix(secret, 'BB' + seed) + ] 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 arbitrary quantity of output:
| HMAC_mix(secret, 'CCC' + seed) + ... ] P_hash(secret, seed) = HMAC_hash(secret, A(1) + data) +
] HMAC_hash(secret, A(2) + data) +
] HMAC_hash(secret, A(3) + data) + ...
| Where + indicates concatenation ] Where + indicates concatenation.
| Where each iteration of PRF generates 16 bytes of output and ] A() is defined as:
| consists of the HMAC_mix of the secret and the seed, where the seed ] A(0) = seed
| is varied by prepending a string of bytes, where the first iteration ] A(i) = HMAC_hash(secret, A(i-1))
| uses a one byte string with the single value 'A' (0x40), the second
| uses a two byte string containing the value 'B' (0x41) twice, and so ] P_hash can be iterated as many times as is necessary to produce the
| on. This can be repeated to generate up to 26 16-byte blocks, which ] required quantity of data. For example, if P_SHA-1 was being used to
| is more than TLS ever requires. ] create 64 bytes of data, it would have to be iterated 4 times
] (through A(4)), creating 80 bytes of output data; the last 16 bytes
] of the final iteration would then be discarded, leaving 64 bytes of
] output data.
] TLS's PRF is created by splitting the secret into two halves and
] using one half to generate data with P_MD5 and the other half to
] generate data with P_SHA1, then exclusive-or'ing the outputs of
] these two expansion functions together.
] S1 and S2 are the two halves of the secret and each is the same
] length. S1 is taken from the first half of the secret, S2 from the
] second half. Their length is created by rounding up the length of
] the overall secret divided by two; thus, if the original secret is
] an odd number of bytes long, the last byte of S1 will be the same as
] the first byte of S2.
] L_S = length in bytes of secret;
] L_S1 = L_S2 = ceil(L_S / 2);
] The secret is partitioned into two halves (with the possibility of
] one shared byte) as described above, S1 taking the first L_S1 bytes
] and S2 the last L_S2 bytes.
] The PRF is then defined as the result of mixing the two pseudorandom
] streams by exclusive-or'ing them together.
] PRF(secret, seed) = P_MD5(S1, seed) XOR P_SHA-1(S2, seed);
] Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
] byte outputs, the boundaries of their internal iterations will not
] be aligned; to generate a 80 byte output will involve P_MD5 being
] iterated through A(5), while P_SHA-1 will only iterate through A(4).
5.3. Record layer 5.3. Record layer
The TLS Record Layer receives uninterpreted data from higher layers The TLS Record Layer receives uninterpreted data from higher layers
in non-empty blocks of arbitrary size. in non-empty blocks of arbitrary size.
5.3.1. Fragmentation 5.3.1. Fragmentation
The record layer fragments information blocks into TLSPlaintext The record layer fragments information blocks into TLSPlaintext
records of 2^14 bytes or less. Client message boundaries are not records of 2^14 bytes or less. Client message boundaries are not
skipping to change at page 19, line 11 skipping to change at page 19, line 53
client write key, a server write key, a client write IV, and a client write key, a server write key, a client write IV, and a
server write IV, which are generated from the master secret in that server write IV, which are generated from the master secret in that
order. Unused values are empty. order. Unused values are empty.
When generating keys and MAC secrets, the master secret is used as When generating keys and MAC secrets, the master secret is used as
an entropy source, and the random values provide unencrypted salt an entropy source, and the random values provide unencrypted salt
material and IVs for exportable ciphers. material and IVs for exportable ciphers.
To generate the key material, compute To generate the key material, compute
| key_block = PRF(SecurityParameters.master_secret, ] key_block = PRF(SecurityParameters.master_secret,
| SecurityParameters.master_secret + ] SecurityParameters.server_random +
| SecurityParameters.server_random + ] SecurityParameters.client_random);
| SecurityParameters.client_random);
until enough output has been generated. Then the key_block is until enough output has been generated. Then the key_block is
partitioned as follows: partitioned as follows:
client_write_MAC_secret[SecurityParameters.hash_size] client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size] server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material] client_write_key[SecurityParameters.key_material]
server_write_key[SecurityParameters.key_material] server_write_key[SecurityParameters.key_material]
client_write_IV[SecurityParameters.IV_size] client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size] server_write_IV[SecurityParameters.IV_size]
The client_write_IV and server_write_IV are only generated for The client_write_IV and server_write_IV are only generated for
non-export block ciphers. For exportable block ciphers, the non-export block ciphers. For exportable block ciphers, the
initialization vectors are generated later, as described below. Any initialization vectors are generated later, as described below. Any
extra key_block material is discarded. extra key_block material is discarded.
Implementation note: Implementation note:
The cipher spec which is defined in this document which requires The cipher spec which is defined in this document which requires
the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte
keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total
of 104 bytes of key material. This will require iterating the ] of 104 bytes of key material.
| PRF algorithm seven times, through 'GGGGGGG'.
Exportable encryption algorithms (for which CipherSpec.is_exportable Exportable encryption algorithms (for which CipherSpec.is_exportable
is true) require additional processing as follows to derive their is true) require additional processing as follows to derive their
final write keys: final write keys:
| final_client_write_key = | final_client_write_key =
| PRF(SecurityParameters.client_write_key, | PRF(SecurityParameters.client_write_key,
| SecurityParameters.client_random + | SecurityParameters.client_random +
| SecurityParameters.server_random); | SecurityParameters.server_random);
| final_server_write_key = | final_server_write_key =
| PRF(SecurityParameters.server_write_key, | PRF(SecurityParameters.server_write_key,
| SecurityParameters.client_random + | SecurityParameters.client_random +
| SecurityParameters.server_random); | SecurityParameters.server_random);
| Exportable encryption algorithms derive their IVs solely from the | Exportable encryption algorithms derive their IVs solely from the
| random messages: ] random values from the hello messages:
| iv_block = PRF("", SecurityParameters.client_random + | iv_block = PRF("", SecurityParameters.client_random +
| SecurityParameters.server_random); | SecurityParameters.server_random);
| The iv_block is partitioned into two initialization vectors as the | The iv_block is partitioned into two initialization vectors as the
| key_block was above: | key_block was above:
| client_write_IV[SecurityParameters.IV_size] | client_write_IV[SecurityParameters.IV_size]
| server_write_IV[SecurityParameters.IV_size] | server_write_IV[SecurityParameters.IV_size]
| Note that the PRF is used without a secret in this case: this just | Note that the PRF is used without a secret in this case: this just
| means that the secret has a length of zero bytes and contributes | means that the secret has a length of zero bytes and contributes
| nothing to the hashing in the PRF. | nothing to the hashing in the PRF.
5.4.1. Export key generation example 5.4.1. Export key generation example
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for
each of the two encryption keys and 16 bytes for each of the MAC each of the two encryption keys and 16 bytes for each of the MAC
keys, for a total of 42 bytes of key material. MD5 produces 16 bytes ] keys, for a total of 42 bytes of key material. The PRF output is
| of output per call, so the PRF will iterate three times internally. ] stored in the key_block. The key_block is partitioned, and the write
| The PRF output is stored in the key_block. The key_block is ] keys are salted because this is an exportable encryption algorithm.
| partitioned, and the write keys are salted because this is an
| exportable encryption algorithm.
| key_block = PRF(master_secret, | key_block = PRF(master_secret,
| master_secret + | master_secret +
| server_random + | server_random +
| client_random)[0..41] | client_random)[0..41]
client_write_MAC_secret = key_block[0..15] client_write_MAC_secret = key_block[0..15]
server_write_MAC_secret = key_block[16..31] server_write_MAC_secret = key_block[16..31]
client_write_key = key_block[32..36] client_write_key = key_block[32..36]
server_write_key = key_block[37..41] server_write_key = key_block[37..41]
| final_client_write_key = PRF(client_write_key, | final_client_write_key = PRF(client_write_key,
skipping to change at page 26, line 25 skipping to change at page 27, line 20
- Generate a master secret from the premaster secret and exchanged - Generate a master secret from the premaster secret and exchanged
random values. random values.
- Provide security paramers to the record layer. - Provide security paramers to the record layer.
- Allow the client and server to verify that their peer has - Allow the client and server to verify that their peer has
calculated the same security parameters and that the handshake calculated the same security parameters and that the handshake
occured without tampering by an attacker. occured without tampering by an attacker.
] Note that higher layers should not be overly reliant on TLS always
] negotiating the strongest possible connection between two peers:
] there are a number of ways a man in the middle attacker can attempt
] to make two entities drop down to the least secure method they
] support. The protocol has been designed to minimize this risk, but
] there are still attacks available: for example, an attacker could
] block access to the port a secure service runs on, or attempt to get
] the peers to negotiate an unauthenticated connection. The
] fundamental rule is that higher levels must be cognizant of what
] their security requirements are and never transmit information over
] a channel less secure than what they require. The TLS protocol is
] secure, in that any cipher suite offers its promised level of
] security: if you negotiate 3DES with a 1024 bit RSA key exchange
] with a host whose certificate you have verified, you can expect to
] be that secure. However, you should never send data over a link
] encrypted with 40 bit security unless you feel that data is worth no
] more than the effort required to break that encryption.
These goals are achieved by the handshake protocol, which can be These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a client hello message to summarized as follows: The client sends a client hello message to
which the server must respond with a server hello message, or else a which the server must respond with a server hello message, or else a
fatal error will occur and the connection will fail. The client fatal error will occur and the connection will fail. The client
hello and server hello are used to establish security enhancement hello and server hello are used to establish security enhancement
capabilities between client and server. The client hello and server capabilities between client and server. The client hello and server
hello establish the following attributes: Protocol Version, Session hello establish the following attributes: Protocol Version, Session
ID, Cipher Suite, and Compression Method. Additionally, two random ID, Cipher Suite, and Compression Method. Additionally, two random
values are generated and exchanged: ClientHello.random and values are generated and exchanged: ClientHello.random and
ServerHello.random. ServerHello.random.
skipping to change at page 31, line 14 skipping to change at page 32, line 24
suite or, if no acceptable choices are presented, return a handshake suite or, if no acceptable choices are presented, return a handshake
failure alert and close the connection. failure alert and close the connection.
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
The client hello includes a list of compression algorithms supported The client hello includes a list of compression algorithms supported
by the client, ordered according to the client's preference. by the client, ordered according to the client's preference.
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
] It also contains a vendor identification string, intended to
] identify the manufacturer, platform, and/or version of the TLS
] implementation running on the Client. While these are the intended
] uses, this field is not specified and may contain any data thought
] useful by the implementor, or no data at all. This string consists
] of between 0 and 64 ISO Latin 1 characters.
] opaque VendorID<0..64>; /* Vendor-specified ID string */
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>; CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
] VendorID client_vendor;
} ClientHello; } ClientHello;
client_version client_version
The version of the TLS protocol by which the client wishes to The version of the TLS protocol by which the client wishes to
communicate during this session. This should be the latest communicate during this session. This should be the latest
(highest valued) version supported by the client. For this (highest valued) version supported by the client. For this
| version of the specification, the version will be 3.1 (See | version of the specification, the version will be 3.1 (See
Appendix E for details about backward compatibility). Appendix E for details about backward compatibility).
random random
skipping to change at page 32, line 5 skipping to change at page 33, line 21
compression_methods compression_methods
This is a list of the compression methods supported by the This is a list of the compression methods supported by the
client, sorted by client preference. If the session_id field is client, sorted by client preference. If the session_id field is
not empty (implying a session resumption request) it must not empty (implying a session resumption request) it must
include the compression_method from that session. This vector include the compression_method from that session. This vector
must contain, and all implementations must support, must contain, and all implementations must support,
CompressionMethod.null. Thus, a client and server will always be CompressionMethod.null. Thus, a client and server will always be
able to agree on a compression method. able to agree on a compression method.
] client_vendor
] This freeform string contains ISO Latin 1 characters specifying
] the implementation of TLS being used by the client. This is
] intended solely for compatibility and debugging work and should
] not be used by the server as a part of the protocol.
After sending the client hello message, the client waits for a After sending the client hello message, the client waits for a
server hello message. Any other handshake message returned by the server hello message. Any other handshake message returned by the
server except for a hello request is treated as a fatal error. server except for a hello request is treated as a fatal error.
Forward compatibility note: Forward compatibility note:
In the interests of forward compatibility, it is permitted for a In the interests of forward compatibility, it is permitted for a
client hello message to include extra data after the compression client hello message to include extra data after the compression
methods. This data must be included in the handshake hashes, but methods. This data must be included in the handshake hashes, but
must otherwise be ignored. This is the only handshake message must otherwise be ignored. This is the only handshake message
for which this is legal; for all other messages, the amount of for which this is legal; for all other messages, the amount of
skipping to change at page 32, line 33 skipping to change at page 33, line 55
algorithms. If it cannot find such a match, it will respond with algorithms. If it cannot find such a match, it will respond with
a handshake failure alert. a handshake failure alert.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suite; CipherSuite cipher_suite;
CompressionMethod compression_method; CompressionMethod compression_method;
] VendorID server_vendor;
} ServerHello; } ServerHello;
server_version server_version
This field will contain the lower of that suggested by the This field will contain the lower of that suggested by the
client in the client hello and the highest supported by the client in the client hello and the highest supported by the
| server. For this version of the specification, the version is | server. For this version of the specification, the version is
| 3.1 (See Appendix E for details about backward compatibility). | 3.1 (See Appendix E for details about backward compatibility).
random random
This structure is generated by the server and must be different This structure is generated by the server and must be different
from (and independent of) ClientHello.random. from (and independent of) ClientHello.random.
skipping to change at page 32, line 56 skipping to change at page 34, line 25
This is the identity of the session corresponding to this This is the identity of the session corresponding to this
connection. If the ClientHello.session_id was non-empty, the connection. If the ClientHello.session_id was non-empty, the
server will look in its session cache for a match. If a match is server will look in its session cache for a match. If a match is
found and the server is willing to establish the new connection found and the server is willing to establish the new connection
using the specified session state, the server will respond with using the specified session state, the server will respond with
the same value as was supplied by the client. This indicates a the same value as was supplied by the client. This indicates a
resumed session and dictates that the parties must proceed resumed session and dictates that the parties must proceed
directly to the finished messages. Otherwise this field will directly to the finished messages. Otherwise this field will
contain a different value identifying the new session. The contain a different value identifying the new session. The
server may return an empty session_id to indicate that the server may return an empty session_id to indicate that the
session will not be cached and therefore cannot be resumed. ] session will not be cached and therefore cannot be resumed. If a
] session is resumed, it must be resumed using the same cipher
] suite it was originally negotiated with.
cipher_suite cipher_suite
The single cipher suite selected by the server from the list in The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions this field is ClientHello.cipher_suites. For resumed sessions this field is
the value from the state of the session being resumed. the value from the state of the session being resumed.
compression_method compression_method
The single compression algorithm selected by the server from the The single compression algorithm selected by the server from the
list in ClientHello.compression_methods. For resumed sessions list in ClientHello.compression_methods. For resumed sessions
this field is the value from the resumed session state. this field is the value from the resumed session state.
] server_vendor
] This freeform string contains ISO Latin 1 characters specifying
] the implementation of TLS being used by the server. This is
] intended solely for compatibility and debugging work and should
] not be used by the client as a part of the protocol.
6.4.2. Server certificate 6.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 exchange method is not an anonymous one. This message will
always 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
skipping to change at page 34, line 5 skipping to change at page 35, line 35
DHE_RSA_EXPORT RSA public key which can be used for DHE_RSA_EXPORT RSA public key which can be used for
signing. signing.
DH_DSS Diffie-Hellman key. The algorithm used DH_DSS Diffie-Hellman key. The algorithm used
to sign the certificate should be DSS. to sign the certificate should be DSS.
DH_RSA Diffie-Hellman key. The algorithm used DH_RSA Diffie-Hellman key. The algorithm used
to sign the certificate should be RSA. to sign the certificate should be RSA.
] All certificate profiles, key and cryptographic formats are defined
] by the IETF PKIX working group [PKIX].
As CipherSuites which specify new key exchange methods are specified As CipherSuites which specify new key exchange methods are specified
for the TLS Protocol, they will imply certificate format and the for the TLS Protocol, they will imply certificate format and the
required encoded keying information. required encoded keying information.
Structure of this message: Structure of this message:
opaque ASN.1Cert<1..2^24-1>; opaque ASN.1Cert<1..2^24-1>;
struct { struct {
ASN.1Cert certificate_list<0..2^24-1>; ASN.1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
skipping to change at page 37, line 4 skipping to change at page 38, line 37
opaque sha_hash[20]; opaque sha_hash[20];
}; };
} Signature; } Signature;
6.4.4. Certificate request 6.4.4. 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 | message, if sent, will immediately follow the Server Key
| Exchange message (if it is sent; otherwise, the Server | Exchange message (if it is sent; otherwise, the Server
| Certificate message). | Certificate 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(5), dss_ephemeral_dh(6),
(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>;
DistinguishedName certificate_authorities<3..2^16-1>; DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest; } CertificateRequest;
skipping to change at page 41, line 7 skipping to change at page 42, line 38
When this message will be sent: When this message will be sent:
A finished message is always sent immediately after a change A finished message is always sent immediately after a change
cipher spec message to verify that the key exchange and cipher spec message to verify that the key exchange and
authentication processes were successful. It is essential that a authentication processes were successful. It is essential that a
change cipher spec message be received between the other change cipher spec message be received between the other
handshake messages and the Finished message. handshake messages and the Finished message.
Meaning of this message: Meaning of this message:
The finished message is the first protected with the The finished message is the first protected with the
just-negotiated algorithms, keys, and secrets. No acknowledgment ] just-negotiated algorithms, keys, and secrets. Recipients of
of the finished message is required; parties may begin sending ] finished messages must verify that the contents are correct.
encrypted data immediately after sending the finished message. ] Once a side has sent its Finished message and received and
Recipients of finished messages must verify that the contents ] validated the Finished message from its peer, it may begin to
are correct. ] send and receive application data over the connection.
enum { client(0x434C4E54), server(0x53525652) } Sender; enum { client(0x434C4E54), server(0x53525652) } Sender;
struct { struct {
opaque md5_hash[16]; opaque md5_hash[16];
opaque sha_hash[20]; opaque sha_hash[20];
} Finished; } Finished;
md5_hash md5_hash
| HMAC_MD5(master_secret, handshake_messages + Sender); | HMAC_MD5(master_secret, handshake_messages + Sender);
skipping to change at page 42, line 17 skipping to change at page 43, line 51
random values are exchanged in the hello messages. All that remains random values are exchanged in the hello messages. All that remains
is to calculate the master secret. is to calculate the master secret.
7.1. Computing the master secret 7.1. Computing the master secret
For all key exchange methods, the same algorithm is used to convert For all key exchange methods, the same algorithm is used to convert
the pre_master_secret into the master_secret. The pre_master_secret the pre_master_secret into the master_secret. The pre_master_secret
should be deleted from memory once the master_secret has been should be deleted from memory once the master_secret has been
computed. computed.
| master_secret = PRF(pre_master_secret, pre_master_secret + ] master_secret = PRF(pre_master_secret,
| ClientHello.random + ServerHello.random); ] ClientHello.random + ServerHello.random);
The master secret is always exactly 48 bytes in length. The length The master secret is always exactly 48 bytes in length. The length
of the premaster secret will vary depending on key exchange method. of the premaster secret will vary depending on key exchange method.
7.1.1. RSA 7.1.1. RSA
When RSA is used for server authentication and key exchange, a When RSA is used for server authentication and key exchange, a
48-byte pre_master_secret is generated by the client, encrypted 48-byte pre_master_secret is generated by the client, encrypted
under the server's public key, and sent to the server. The server 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 uses its private key to decrypt the pre_master_secret. Both parties
then convert the pre_master_secret into the master_secret, as then convert the pre_master_secret into the master_secret, as
skipping to change at page 45, line 53 skipping to change at page 47, line 37
uint8 CipherSuite[2]; uint8 CipherSuite[2];
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suites<0..2^16-1>; CipherSuite cipher_suites<0..2^16-1>;
CompressionMethod compression_methods<0..2^8-1>; CompressionMethod compression_methods<0..2^8-1>;
] VendorID client_vendor;
} ClientHello; } ClientHello;
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suite; CipherSuite cipher_suite;
CompressionMethod compression_method; CompressionMethod compression_method;
] VendorID server_vendor;
} ServerHello; } ServerHello;
A.5.2. Server authentication and key exchange messages A.5.2. Server authentication and key exchange messages
opaque ASN.1Cert<2^24-1>; opaque ASN.1Cert<2^24-1>;
struct { struct {
ASN.1Cert certificate_list<1..2^24-1>; ASN.1Cert certificate_list<1..2^24-1>;
} Certificate; } Certificate;
enum { rsa, diffie_hellman } KeyExchangeAlgorithm; enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct { struct {
opaque RSA_modulus<1..2^16-1>; opaque RSA_modulus<1..2^16-1>;
opaque RSA_exponent<1..2^16-1>; opaque RSA_exponent<1..2^16-1>;
} ServerRSAParams; } ServerRSAParams;
struct { struct {
opaque DH_p<1..2^16-1>; opaque DH_p<1..2^16-1>;
opaque DH_g<1..2^16-1>; opaque DH_g<1..2^16-1>;
skipping to change at page 47, line 4 skipping to change at page 48, line 42
case rsa: case rsa:
digitally-signed struct { digitally-signed struct {
opaque md5_hash[16]; opaque md5_hash[16];
opaque sha_hash[20]; opaque sha_hash[20];
}; };
case dsa: case dsa:
digitally-signed struct { digitally-signed struct {
opaque sha_hash[20]; opaque sha_hash[20];
}; };
} Signature; } Signature;
enum {
RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3), ] enum {
DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6), ] rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
(255) ] (255)
} CertificateType; ] } ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
CertificateType certificate_types<1..2^8-1>; CertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>; DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest; } CertificateRequest;
struct { } ServerHelloDone; struct { } ServerHelloDone;
skipping to change at page 49, line 21 skipping to change at page 51, line 7
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
Note: All cipher suites whose first byte is 0xFF are considered Note: All cipher suites whose first byte is 0xFF are considered
private and can be used for defining local/experimental private and can be used for defining local/experimental
algorithms. Interoperability of such types is a local matter. algorithms. Interoperability of such types is a local matter.
Note: Additional cipher suites will be considered for implementation Note: Additional cipher suites will be considered for implementation
only with submission of notarized letters from two independent only with submission of notarized letters from two independent
entities. Netscape Communications Corp. will act as an interim ] entities. Consensus Development Corp. will act as an interim
registration office, until a public standards body assumes registration office, until a public standards body assumes
control of TLS. ] control of TLS cipher suites.
A.7. The Security Parameters A.7. The Security Parameters
These security parameters are determined by the TLS Handshake These security parameters are determined by the TLS Handshake
Protocol and provided as parameters to the TLS Record Layer in order Protocol and provided as parameters to the TLS Record Layer in order
to initialize a connection state. SecurityParameters includes: to initialize a connection state. SecurityParameters includes:
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd; enum { server, client } ConnectionEnd;
skipping to change at page 64, line 49 skipping to change at page 66, line 36
Initiatives take no position on the validity or scope of the patents Initiatives take no position on the validity or scope of the patents
and patent applications, nor on the appropriateness of the terms of and patent applications, nor on the appropriateness of the terms of
the assurance. The Internet Society and other groups mentioned above the assurance. The Internet Society and other groups mentioned above
have not made any determination as to any other intellectual have not made any determination as to any other intellectual
property rights which may apply to the practice of this standard. property rights which may apply to the practice of this standard.
Any further consideration of these matters is the user's own Any further consideration of these matters is the user's own
responsibility. responsibility.
References References
[SSL3] Frier, Karton and Kocher,
internet-draft-tls-ssl-version3-00.txt: "The SSL 3.0 Protocol", Nov
18 1996.
[DH1] W. Diffie and M. E. Hellman, "New Directions in Cryptography,"
IEEE Transactions on Information Theory, V. IT-22, n. 6, Jun 1977,
pp. 74-84.
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
[DES] ANSI X3.106, "American National Standard for Information [DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption," American National Standards Systems-Data Link Encryption," American National Standards
Institute, 1983. Institute, 1983.
[DH1] W. Diffie and M. E. Hellman, "New Directions in Cryptography,"
IEEE Transactions on Information Theory, V. IT-22, n. 6, Jun 1977,
pp. 74-84.
[DSS] NIST FIPS PUB 186, "Digital Signature Standard," National [DSS] NIST FIPS PUB 186, "Digital Signature Standard," National
Institute of Standards and Technology, U.S. Department of Commerce, Institute of Standards and Technology, U.S. Department of Commerce,
18 May 1994. 18 May 1994.
[FTP] J. Postel and J. Reynolds, RFC 959: File Transfer Protocol, [FTP] J. Postel and J. Reynolds, RFC 959: File Transfer Protocol,
October 1985. October 1985.
[HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer
Protocol -- HTTP/1.0, October, 1995. Protocol -- HTTP/1.0, October, 1995.
] [HMAC] H. Krawczyk, RFC 2104, HMAC: Keyed-Hashing for Message
] Authentication, February, 1997.
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Series in Information Processing, v. 1, Konstanz: Hartung-Gorre
Verlag, 1992. Verlag, 1992.
[KRAW] H. Krawczyk, IETF Draft: Keyed-MD5 for Message
Authentication, November 1995.
[MD2] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April [MD2] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April
1992. 1992.
[MD5] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April [MD5] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April
1992. 1992.
[PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard," [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
version 1.5, November 1993. version 1.5, November 1993.
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
Standard," version 1.5, November 1993. Standard," version 1.5, November 1993.
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
Standard," version 1.5, November 1993. Standard," version 1.5, November 1993.
] [PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key
] Infrastructure: Part I: X.509 Certificate and CRL Profile,
] <draft-ietf-pkix-ipki-part1-03.txt>, December 1996.
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems," Obtaining Digital Signatures and Public-Key Cryptosystems,"
Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126. Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126.
[RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 [SCH] B. [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 [SCH] B.
Schneier. Applied Cryptography: Protocols, Algorithms, and Source Schneier. Applied Cryptography: Protocols, Algorithms, and Source
Code in C, Published by John Wiley & Sons, Inc. 1994. Code in C, Published by John Wiley & Sons, Inc. 1994.
[SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of Commerce, Institute of Standards and Technology, U.S. Department of Commerce,
DRAFT, 31 May 1994. DRAFT, 31 May 1994.
[SSL3] Frier, Karton and Kocher,
internet-draft-tls-ssl-version3-00.txt: "The SSL 3.0 Protocol", Nov
18 1996.
[TCP] ISI for DARPA, RFC 793: Transport Control Protocol, September [TCP] ISI for DARPA, RFC 793: Transport Control Protocol, September
1981. 1981.
[TEL] J. Postel and J. Reynolds, RFC 854/5, May, 1993. [TEL] J. Postel and J. Reynolds, RFC 854/5, May, 1993.
[X509] CCITT. Recommendation X.509: "The Directory - Authentication [X509] CCITT. Recommendation X.509: "The Directory - Authentication
Framework". 1988. Framework". 1988.
[XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data
Representation Standard, August 1995. Representation Standard, August 1995.
skipping to change at page 67, line 32 skipping to change at page 69, line 26
Stuart Haber Don Stephenson Stuart Haber Don Stephenson
Bellcore Sun Microsystems Bellcore Sun Microsystems
stuart@bellcore.com don.stephenson@eng.sun.com stuart@bellcore.com don.stephenson@eng.sun.com
Burt Kaliski Joe Tardo Burt Kaliski Joe Tardo
RSA Data Security, Inc. General Magic RSA Data Security, Inc. General Magic
burt@rsa.com tardo@genmagic.com burt@rsa.com tardo@genmagic.com
Comments Comments
Comments on this draft should be sent to the editors, Tim Dierks ] Comments on this draft should be sent to the editors, Tim Dierks and
<timd@consensus.com> and Christopher Allen ] Christopher Allen at the address <ietf-tls-editors@consensus.com>,
<christophera@consensus.com>, or to the IETF Transport Layer ] or to the IETF Transport Layer Security (TLS) Working Group.
Security (TLS) Working Group.
The discussion list for IETF-TLS is at IETF-TLS@W3.ORG. You ] The discussion list for the IETF TLS working group is located at the
subscribe and unsubscribe by sending to IETF-TLS-REQUEST@W3.ORG with ] e-mail address <ietf-tls@consensus.com>. Information on the group
subscribe or unsubscribe in the SUBJECT of the message. ] and information on how to subscribe to the list is at
] <http://www.consensus.com/ietf-tls/>.
] You can subscribe to the list by sending a message to
] <ietf-tls@consensus.com> with the subject "SUBSCRIBE". You can
] subscribe to a digested variant of the list by sending a message to
] <ietf-tls@consensus.com> with the subject "SUBSCRIBE DIGEST". To
] remove yourself from the list, send a message to
] <ietf-tls@consensus.com> with the subject "UNSUBSCRIBE".
Archives of the list are at: Archives of the list are at:
<http://lists.w3.org/Archives/Public/ietf-tls> ] <http://www.imc.org/ietf-tls/mail-archive/>
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/