in Index   Prev   Next

RFC 2246

The TLS Protocol Version 1.0

Pages: 80
Obsoleted by:  4346
Updated by:  354657466176746575077919
Part 1 of 3 – Pages 1 to 23
None   None   Next

ToP   noToC   RFC2246 - Page 1
Network Working Group                                         T. Dierks
Request for Comments: 2246                                     Certicom
Category: Standards Track                                      C. Allen
                                                           January 1999

                            The TLS Protocol
                              Version 1.0

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.


   This document specifies Version 1.0 of the Transport Layer Security
   (TLS) protocol. The TLS protocol provides communications privacy over
   the Internet. The protocol allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping,
   tampering, or message forgery.

Table of Contents

   1.       Introduction                                              3
   2.       Goals                                                     4
   3.       Goals of this document                                    5
   4.       Presentation language                                     5
   4.1.     Basic block size                                          6
   4.2.     Miscellaneous                                             6
   4.3.     Vectors                                                   6
   4.4.     Numbers                                                   7
   4.5.     Enumerateds                                               7
   4.6.     Constructed types                                         8
   4.6.1.   Variants                                                  9
   4.7.     Cryptographic attributes                                 10
   4.8.     Constants                                                11
   5.       HMAC and the pseudorandom function                       11
   6.       The TLS Record Protocol                                  13
   6.1.     Connection states                                        14
ToP   noToC   RFC2246 - Page 2
   6.2.     Record layer                                             16
   6.2.1.   Fragmentation                                            16
   6.2.2.   Record compression and decompression                     17
   6.2.3.   Record payload protection                                18 Null or standard stream cipher                           19 CBC block cipher                                         19
   6.3.     Key calculation                                          21
   6.3.1.   Export key generation example                            22
   7.       The TLS Handshake Protocol                               23
   7.1.     Change cipher spec protocol                              24
   7.2.     Alert protocol                                           24
   7.2.1.   Closure alerts                                           25
   7.2.2.   Error alerts                                             26
   7.3.     Handshake Protocol overview                              29
   7.4.     Handshake protocol                                       32
   7.4.1.   Hello messages                                           33 Hello request                                            33 Client hello                                             34 Server hello                                             36
   7.4.2.   Server certificate                                       37
   7.4.3.   Server key exchange message                              39
   7.4.4.   Certificate request                                      41
   7.4.5.   Server hello done                                        42
   7.4.6.   Client certificate                                       43
   7.4.7.   Client key exchange message                              43 RSA encrypted premaster secret message                   44 Client Diffie-Hellman public value                       45
   7.4.8.   Certificate verify                                       45
   7.4.9.   Finished                                                 46
   8.       Cryptographic computations                               47
   8.1.     Computing the master secret                              47
   8.1.1.   RSA                                                      48
   8.1.2.   Diffie-Hellman                                           48
   9.       Mandatory Cipher Suites                                  48
   10.      Application data protocol                                48
   A.       Protocol constant values                                 49
   A.1.     Record layer                                             49
   A.2.     Change cipher specs message                              50
   A.3.     Alert messages                                           50
   A.4.     Handshake protocol                                       51
   A.4.1.   Hello messages                                           51
   A.4.2.   Server authentication and key exchange messages          52
   A.4.3.   Client authentication and key exchange messages          53
   A.4.4.   Handshake finalization message                           54
   A.5.     The CipherSuite                                          54
   A.6.     The Security Parameters                                  56
   B.       Glossary                                                 57
   C.       CipherSuite definitions                                  61
ToP   noToC   RFC2246 - Page 3
   D.       Implementation Notes                                     64
   D.1.     Temporary RSA keys                                       64
   D.2.     Random Number Generation and Seeding                     64
   D.3.     Certificates and authentication                          65
   D.4.     CipherSuites                                             65
   E.       Backward Compatibility With SSL                          66
   E.1.     Version 2 client hello                                   67
   E.2.     Avoiding man-in-the-middle version rollback              68
   F.       Security analysis                                        69
   F.1.     Handshake protocol                                       69
   F.1.1.   Authentication and key exchange                          69
   F.1.1.1. Anonymous key exchange                                   69
   F.1.1.2. RSA key exchange and authentication                      70
   F.1.1.3. Diffie-Hellman key exchange with authentication          71
   F.1.2.   Version rollback attacks                                 71
   F.1.3.   Detecting attacks against the handshake protocol         72
   F.1.4.   Resuming sessions                                        72
   F.1.5.   MD5 and SHA                                              72
   F.2.     Protecting application data                              72
   F.3.     Final notes                                              73
   G.       Patent Statement                                         74
            Security Considerations                                  75
            References                                               75
            Credits                                                  77
            Comments                                                 78
            Full Copyright Statement                                 80

1. Introduction

   The primary goal of the TLS Protocol is to provide privacy and data
   integrity between two communicating applications. The protocol is
   composed of two layers: the TLS Record Protocol and the TLS Handshake
   Protocol. At the lowest level, layered on top of some reliable
   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
   TLS Record Protocol provides connection security that has two basic

     - The connection is private. Symmetric cryptography is used for
       data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for
       this symmetric encryption are generated uniquely for each
       connection and are based on a secret negotiated by another
       protocol (such as the TLS Handshake Protocol). The Record
       Protocol can also be used without encryption.

     - The connection is reliable. Message transport includes a message
       integrity check using a keyed MAC. Secure hash functions (e.g.,
       SHA, MD5, etc.) are used for MAC computations. The Record
       Protocol can operate without a MAC, but is generally only used in
ToP   noToC   RFC2246 - Page 4
       this mode while another protocol is using the Record Protocol as
       a transport for negotiating security parameters.

   The TLS Record Protocol is used for encapsulation of various higher
   level protocols. One such encapsulated protocol, the TLS Handshake
   Protocol, allows the server and client to authenticate each other and
   to negotiate an encryption algorithm and cryptographic keys before
   the application protocol transmits or receives its first byte of
   data. The TLS Handshake Protocol provides connection security that
   has three basic properties:

     - The peer's identity can be authenticated using asymmetric, or
       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
       authentication can be made optional, but is generally required
       for at least one of the peers.

     - The negotiation of a shared secret is secure: the negotiated
       secret is unavailable to eavesdroppers, and for any authenticated
       connection the secret cannot be obtained, even by an attacker who
       can place himself in the middle of the connection.

     - The negotiation is reliable: no attacker can modify the
       negotiation communication without being detected by the parties
       to the communication.

   One advantage of TLS is that it is application protocol independent.
   Higher level protocols can layer on top of the TLS Protocol
   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 judgment of the designers and
   implementors of protocols which run on top of TLS.

2. Goals

   The goals of TLS Protocol, in order of their priority, are:

    1. Cryptographic security: TLS should be used to establish a secure
       connection between two parties.

    2. Interoperability: Independent programmers should be able to
       develop applications utilizing TLS that will then be able to
       successfully exchange cryptographic parameters without knowledge
       of one another's code.

    3. Extensibility: TLS seeks to provide a framework into which new
       public key and bulk encryption methods can be incorporated as
       necessary. This will also accomplish two sub-goals: to prevent
ToP   noToC   RFC2246 - Page 5
       the need to create a new protocol (and risking the introduction
       of possible new weaknesses) and to avoid the need to implement an
       entire new security library.

    4. Relative efficiency: Cryptographic operations tend to be highly
       CPU intensive, particularly public key operations. For this
       reason, the TLS protocol has incorporated an optional session
       caching scheme to reduce the number of connections that need to
       be established from scratch. Additionally, care has been taken to
       reduce network activity.

3. Goals of this document

   This document and the TLS protocol itself are based on the SSL 3.0
   Protocol Specification as published by Netscape. The differences
   between this protocol and SSL 3.0 are not dramatic, but they are
   significant enough that TLS 1.0 and SSL 3.0 do not interoperate
   (although TLS 1.0 does incorporate a mechanism by which a TLS
   implementation can back down to SSL 3.0). This document is intended
   primarily for readers who will be implementing the protocol and those
   doing cryptographic analysis of it. The specification has been
   written with this in mind, and it is intended to reflect the needs of
   those two groups. For that reason, many of the algorithm-dependent
   data structures and rules are included in the body of the text (as
   opposed to in an appendix), providing easier access to them.

   This document is not intended to supply any details of service
   definition nor interface definition, although it does cover select
   areas of policy as they are required for the maintenance of solid

4. Presentation language

   This document deals with the formatting of data in an external
   representation. The following very basic and somewhat casually
   defined presentation syntax will be used. The syntax draws from
   several sources in its structure. Although it resembles the
   programming language "C" in its syntax and XDR [XDR] in both its
   syntax and intent, it would be risky to draw too many parallels. The
   purpose of this presentation language is to document TLS only, not to
   have general application beyond that particular goal.
ToP   noToC   RFC2246 - Page 6
4.1. Basic block size

   The representation of all data items is explicitly specified. The
   basic data block size is one byte (i.e. 8 bits). Multiple byte data
   items are concatenations of bytes, from left to right, from top to
   bottom. From the bytestream a multi-byte item (a numeric in the
   example) is formed (using C notation) by:

       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
               ... | byte[n-1];

   This byte ordering for multi-byte values is the commonplace network
   byte order or big endian format.

4.2. Miscellaneous

   Comments begin with "/*" and end with "*/".

   Optional components are denoted by enclosing them in "[[ ]]" double

   Single byte entities containing uninterpreted data are of type

4.3. Vectors

   A vector (single dimensioned array) is a stream of homogeneous data
   elements. The size of the vector may be specified at documentation
   time or left unspecified until runtime. In either case the length
   declares the number of bytes, not the number of elements, in the
   vector. The syntax for specifying a new type T' that is a fixed
   length vector of type T is

       T T'[n];

   Here T' occupies n bytes in the data stream, where n is a multiple of
   the size of T. The length of the vector is not included in the
   encoded stream.

   In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

       opaque Datum[3];      /* three uninterpreted bytes */
       Datum Data[9];        /* 3 consecutive 3 byte vectors */
ToP   noToC   RFC2246 - Page 7
   Variable length vectors are defined by specifying a subrange of legal
   lengths, inclusively, using the notation <floor..ceiling>.  When
   encoded, the actual length precedes the vector's contents in the byte
   stream. The length will be in the form of a number consuming as many
   bytes as required to hold the vector's specified maximum (ceiling)
   length. A variable length vector with an actual length field of zero
   is referred to as an empty vector.

       T T'<floor..ceiling>;

   In the following example, mandatory is a vector that must contain
   between 300 and 400 bytes of type opaque. It can never be empty. The
   actual length field consumes two bytes, a uint16, sufficient to
   represent the value 400 (see Section 4.4). On the other hand, longer
   can represent up to 800 bytes of data, or 400 uint16 elements, and it
   may be empty. Its encoding will include a two byte actual length
   field prepended to the vector. The length of an encoded vector must
   be an even multiple of the length of a single element (for example, a
   17 byte vector of uint16 would be illegal).

       opaque mandatory<300..400>;
             /* length field is 2 bytes, cannot be empty */
       uint16 longer<0..800>;
             /* zero to 400 16-bit unsigned integers */

4.4. Numbers

   The basic numeric data type is an unsigned byte (uint8). All larger
   numeric data types are formed from fixed length series of bytes
   concatenated as described in Section 4.1 and are also unsigned. The
   following numeric types are predefined.

       uint8 uint16[2];
       uint8 uint24[3];
       uint8 uint32[4];
       uint8 uint64[8];

   All values, here and elsewhere in the specification, are stored in
   "network" or "big-endian" order; the uint32 represented by the hex
   bytes 01 02 03 04 is equivalent to the decimal value 16909060.

4.5. Enumerateds

   An additional sparse data type is available called enum. A field of
   type enum can only assume the values declared in the definition.
   Each definition is a different type. Only enumerateds of the same
   type may be assigned or compared. Every element of an enumerated must
ToP   noToC   RFC2246 - Page 8
   be assigned a value, as demonstrated in the following example.  Since
   the elements of the enumerated are not ordered, they can be assigned
   any unique value, in any order.

       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

   Enumerateds occupy as much space in the byte stream as would its
   maximal defined ordinal value. The following definition would cause
   one byte to be used to carry fields of type Color.

       enum { red(3), blue(5), white(7) } Color;

   One may optionally specify a value without its associated tag to
   force the width definition without defining a superfluous element.
   In the following example, Taste will consume two bytes in the data
   stream but can only assume the values 1, 2 or 4.

       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

   The names of the elements of an enumeration are scoped within the
   defined type. In the first example, a fully qualified reference to
   the second element of the enumeration would be Such
   qualification is not required if the target of the assignment is well

       Color color =;     /* overspecified, legal */
       Color color = blue;           /* correct, type implicit */

   For enumerateds that are never converted to external representation,
   the numerical information may be omitted.

       enum { low, medium, high } Amount;

4.6. Constructed types

   Structure types may be constructed from primitive types for
   convenience. Each specification declares a new, unique type. The
   syntax for definition is much like that of C.

       struct {
         T1 f1;
         T2 f2;
         Tn fn;
       } [[T]];
ToP   noToC   RFC2246 - Page 9
   The fields within a structure may be qualified using the type's name
   using a syntax much like that available for enumerateds. For example,
   T.f2 refers to the second field of the previous declaration.
   Structure definitions may be embedded.

4.6.1. Variants

   Defined structures may have variants based on some knowledge that is
   available within the environment. The selector must be an enumerated
   type that defines the possible variants the structure defines. There
   must be a case arm for every element of the enumeration declared in
   the select. The body of the variant structure may be given a label
   for reference. The mechanism by which the variant is selected at
   runtime is not prescribed by the presentation language.

       struct {
           T1 f1;
           T2 f2;
           Tn fn;
           select (E) {
               case e1: Te1;
               case e2: Te2;
               case en: Ten;
           } [[fv]];
       } [[Tv]];

   For example:

       enum { apple, orange } VariantTag;
       struct {
           uint16 number;
           opaque string<0..10>; /* variable length */
       } V1;
       struct {
           uint32 number;
           opaque string[10];    /* fixed length */
       } V2;
       struct {
           select (VariantTag) { /* value of selector is implicit */
               case apple: V1;   /* VariantBody, tag = apple */
               case orange: V2;  /* VariantBody, tag = orange */
           } variant_body;       /* optional label on variant */
       } VariantRecord;

   Variant structures may be qualified (narrowed) by specifying a value
   for the selector prior to the type. For example, a
ToP   noToC   RFC2246 - Page 10
       orange VariantRecord

   is a narrowed type of a VariantRecord containing a variant_body of
   type V2.

4.7. Cryptographic attributes

   The four cryptographic operations digital signing, stream cipher
   encryption, block cipher encryption, and public key encryption are
   designated digitally-signed, stream-ciphered, block-ciphered, and
   public-key-encrypted, respectively. A field's cryptographic
   processing is specified by prepending an appropriate key word
   designation before the field's type specification. Cryptographic keys
   are implied by the current session state (see Section 6.1).

   In digital signing, one-way hash functions are used as input for a
   signing algorithm. A digitally-signed element is encoded as an opaque
   vector <0..2^16-1>, where the length is specified by the signing
   algorithm and key.

   In RSA signing, a 36-byte structure of two hashes (one SHA and one
   MD5) is signed (encrypted with the private key). It is encoded with
   PKCS #1 block type 0 or type 1 as described in [PKCS1].

   In DSS, the 20 bytes of the SHA hash are run directly through the
   Digital Signing Algorithm with no additional hashing. This produces
   two values, r and s. The DSS signature is an opaque vector, as above,
   the contents of which are the DER encoding of:

       Dss-Sig-Value  ::=  SEQUENCE  {
            r       INTEGER,
            s       INTEGER

   In stream cipher encryption, the plaintext is exclusive-ORed with an
   identical amount of output generated from a cryptographically-secure
   keyed pseudorandom number generator.

   In block cipher encryption, every block of plaintext encrypts to a
   block of ciphertext. All block cipher encryption is done in CBC
   (Cipher Block Chaining) mode, and all items which are block-ciphered
   will be an exact multiple of the cipher block length.

   In public key encryption, a public key algorithm is used to encrypt
   data in such a way that it can be decrypted only with the matching
   private key. A public-key-encrypted element is encoded as an opaque
   vector <0..2^16-1>, where the length is specified by the signing
   algorithm and key.
ToP   noToC   RFC2246 - Page 11
   An RSA encrypted value is encoded with PKCS #1 block type 2 as
   described in [PKCS1].

   In the following example:

       stream-ciphered struct {
           uint8 field1;
           uint8 field2;
           digitally-signed opaque hash[20];
       } UserType;

   The contents of hash are used as input for the signing algorithm,
   then the entire structure is encrypted with a stream cipher. The
   length of this structure, in bytes would be equal to 2 bytes for
   field1 and field2, plus two bytes for the length of the signature,
   plus the length of the output of the signing algorithm. This is known
   due to the fact that the algorithm and key used for the signing are
   known prior to encoding or decoding this structure.

4.8. Constants

   Typed constants can be defined for purposes of specification by
   declaring a symbol of the desired type and assigning values to it.
   Under-specified types (opaque, variable length vectors, and
   structures that contain opaque) cannot be assigned values. No fields
   of a multi-element structure or vector may be elided.

   For example,

       struct {
           uint8 f1;
           uint8 f2;
       } Example1;

       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */

5. HMAC and the pseudorandom function

   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
   secret. Forging the MAC is infeasible without knowledge of the MAC
   secret. The construction we use for this operation is known as 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,
ToP   noToC   RFC2246 - Page 12
   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
   into blocks of data for the purposes of key generation or validation.
   This pseudo-random function (PRF) takes as input a secret, a seed,
   and an identifying label and produces an output of arbitrary length.

   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.

   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:

       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
                              HMAC_hash(secret, A(2) + seed) +
                              HMAC_hash(secret, A(3) + seed) + ...

   Where + indicates concatenation.

   A() is defined as:
       A(0) = seed
       A(i) = HMAC_hash(secret, A(i-1))

   P_hash can be iterated as many times as is necessary to produce the
   required quantity of data. For example, if P_SHA-1 was being used to
   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_SHA-1, 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);
ToP   noToC   RFC2246 - Page 13
   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, label, seed) = P_MD5(S1, label + seed) XOR
                                  P_SHA-1(S2, label + seed);

   The label is an ASCII string. It should be included in the exact form
   it is given without a length byte or trailing null character.  For
   example, the label "slithy toves" would be processed by hashing the
   following bytes:

       73 6C 69 74 68 79 20 74 6F 76 65 73

   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).

6. The TLS Record Protocol

   The TLS Record Protocol is a layered protocol. At each layer,
   messages may include fields for length, description, and content.
   The Record Protocol takes messages to be transmitted, fragments the
   data into manageable blocks, optionally compresses the data, applies
   a MAC, encrypts, and transmits the result. Received data is
   decrypted, verified, decompressed, and reassembled, then delivered to
   higher level clients.

   Four record protocol clients are described in this document: the
   handshake protocol, the alert protocol, the change cipher spec
   protocol, and the application data protocol. In order to allow
   extension of the TLS protocol, additional record types can be
   supported by the record protocol. Any new record types should
   allocate type values immediately beyond the ContentType values for
   the four record types described here (see Appendix A.2). If a TLS
   implementation receives a record type it does not understand, it
   should just ignore it. Any protocol designed for use over TLS must be
   carefully designed to deal with all possible attacks against it.
   Note that because the type and length of a record are not protected
   by encryption, care should be take to minimize the value of traffic
   analysis of these values.
ToP   noToC   RFC2246 - Page 14
6.1. Connection states

   A TLS connection state is the operating environment of the TLS Record
   Protocol. It specifies a compression algorithm, encryption algorithm,
   and MAC algorithm. In addition, the parameters for these algorithms
   are known: the MAC secret and the bulk encryption keys and IVs for
   the connection in both the read and the write directions. Logically,
   there are always four connection states outstanding: the current read
   and write states, and the pending read and write states. All records
   are processed under the current read and write states. The security
   parameters for the pending states can be set by the TLS Handshake
   Protocol, and the Handshake Protocol can selectively make either of
   the pending states current, in which case the appropriate current
   state is disposed of and replaced with the pending state; the pending
   state is then reinitialized to an empty state. It is illegal to make
   a state which has not been initialized with security parameters a
   current state. The initial current state always specifies that no
   encryption, compression, or MAC will be used.

   The security parameters for a TLS Connection read and write state are
   set by providing the following values:

   connection end
       Whether this entity is considered the "client" or the "server" in
       this connection.

   bulk encryption algorithm
       An algorithm to be used for bulk encryption. This specification
       includes the key size of this algorithm, how much of that key is
       secret, whether it is a block or stream cipher, the block size of
       the cipher (if appropriate), and whether it is considered an
       "export" cipher.

   MAC algorithm
       An algorithm to be used for message authentication. This
       specification includes the size of the hash which is returned by
       the MAC algorithm.

   compression algorithm
       An algorithm to be used for data compression. This specification
       must include all information the algorithm requires to do

   master secret
       A 48 byte secret shared between the two peers in the connection.

   client random
       A 32 byte value provided by the client.
ToP   noToC   RFC2246 - Page 15
   server random
       A 32 byte value provided by the server.

   These parameters are defined in the presentation language as:

       enum { server, client } ConnectionEnd;

       enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;

       enum { stream, block } CipherType;

       enum { true, false } IsExportable;

       enum { null, md5, sha } MACAlgorithm;

       enum { null(0), (255) } CompressionMethod;

       /* The algorithms specified in CompressionMethod,
          BulkCipherAlgorithm, and MACAlgorithm may be added to. */

       struct {
           ConnectionEnd          entity;
           BulkCipherAlgorithm    bulk_cipher_algorithm;
           CipherType             cipher_type;
           uint8                  key_size;
           uint8                  key_material_length;
           IsExportable           is_exportable;
           MACAlgorithm           mac_algorithm;
           uint8                  hash_size;
           CompressionMethod      compression_algorithm;
           opaque                 master_secret[48];
           opaque                 client_random[32];
           opaque                 server_random[32];
       } SecurityParameters;

   The record layer will use the security parameters to generate the
   following six items:

       client write MAC secret
       server write MAC secret
       client write key
       server write key
       client write IV (for block ciphers only)
       server write IV (for block ciphers only)

   The client write parameters are used by the server when receiving and
   processing records and vice-versa. The algorithm used for generating
   these items from the security parameters is described in section 6.3.
ToP   noToC   RFC2246 - Page 16
   Once the security parameters have been set and the keys have been
   generated, the connection states can be instantiated by making them
   the current states. These current states must be updated for each
   record processed. Each connection state includes the following

   compression state
       The current state of the compression algorithm.

   cipher state
       The current state of the encryption algorithm. This will consist
       of the scheduled key for that connection. In addition, for block
       ciphers running in CBC mode (the only mode specified for TLS),
       this will initially contain the IV for that connection state and
       be updated to contain the ciphertext of the last block encrypted
       or decrypted as records are processed. For stream ciphers, this
       will contain whatever the necessary state information is to allow
       the stream to continue to encrypt or decrypt data.

   MAC secret
       The MAC secret for this connection as generated above.

   sequence number
       Each connection state contains a sequence number, which is
       maintained separately for read and write states. The sequence
       number must be set to zero whenever a connection state is made
       the active state. Sequence numbers are of type uint64 and may not
       exceed 2^64-1. A sequence number is incremented after each
       record: specifically, the first record which is transmitted under
       a particular connection state should use sequence number 0.

6.2. Record layer

   The TLS Record Layer receives uninterpreted data from higher layers
   in non-empty blocks of arbitrary size.

6.2.1. Fragmentation

   The record layer fragments information blocks into TLSPlaintext
   records carrying data in chunks of 2^14 bytes or less. Client message
   boundaries are not preserved in the record layer (i.e., multiple
   client messages of the same ContentType may be coalesced into a
   single TLSPlaintext record, or a single message may be fragmented
   across several records).

       struct {
           uint8 major, minor;
       } ProtocolVersion;
ToP   noToC   RFC2246 - Page 17
       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;

       The higher level protocol used to process the enclosed fragment.

       The version of the protocol being employed. This document
       describes TLS Version 1.0, which uses the version { 3, 1 }. The
       version value 3.1 is historical: TLS version 1.0 is a minor
       modification to the SSL 3.0 protocol, which bears the version
       value 3.0. (See Appendix A.1).

       The length (in bytes) of the following TLSPlaintext.fragment.
       The length should not exceed 2^14.

       The application data. This data is transparent and treated as an
       independent block to be dealt with by the higher level protocol
       specified by the type field.

 Note: Data of different TLS Record layer content types may be
       interleaved. Application data is generally of lower precedence
       for transmission than other content types.

6.2.2. Record compression and decompression

   All records are compressed using the compression algorithm defined in
   the current session state. There is always an active compression
   algorithm; however, initially it is defined as
   CompressionMethod.null. The compression algorithm translates a
   TLSPlaintext structure into a TLSCompressed structure. Compression
   functions are initialized with default state information whenever a
   connection state is made active.
ToP   noToC   RFC2246 - Page 18
   Compression must be lossless and may not increase the content length
   by more than 1024 bytes. If the decompression function encounters a
   TLSCompressed.fragment that would decompress to a length in excess of
   2^14 bytes, it should report a fatal decompression failure error.

       struct {
           ContentType type;       /* same as TLSPlaintext.type */
           ProtocolVersion version;/* same as TLSPlaintext.version */
           uint16 length;
           opaque fragment[TLSCompressed.length];
       } TLSCompressed;

       The length (in bytes) of the following TLSCompressed.fragment.
       The length should not exceed 2^14 + 1024.

       The compressed form of TLSPlaintext.fragment.

 Note: A CompressionMethod.null operation is an identity operation; no
       fields are altered.

   Implementation note:
       Decompression functions are responsible for ensuring that
       messages cannot cause internal buffer overflows.

6.2.3. Record payload protection

   The encryption and MAC functions translate a TLSCompressed structure
   into a TLSCiphertext. The decryption functions reverse the process.
   The MAC of the record also includes a sequence number so that
   missing, extra or repeated messages are detectable.

       struct {
           ContentType type;
           ProtocolVersion version;
           uint16 length;
           select (CipherSpec.cipher_type) {
               case stream: GenericStreamCipher;
               case block: GenericBlockCipher;
           } fragment;
       } TLSCiphertext;

       The type field is identical to TLSCompressed.type.

       The version field is identical to TLSCompressed.version.
ToP   noToC   RFC2246 - Page 19
       The length (in bytes) of the following TLSCiphertext.fragment.
       The length may not exceed 2^14 + 2048.

       The encrypted form of TLSCompressed.fragment, with the MAC. Null or standard stream cipher

   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
   A.6) convert TLSCompressed.fragment structures to and from stream
   TLSCiphertext.fragment structures.

       stream-ciphered struct {
           opaque content[TLSCompressed.length];
           opaque MAC[CipherSpec.hash_size];
       } GenericStreamCipher;

   The MAC is generated as:

       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
                     TLSCompressed.version + TLSCompressed.length +

   where "+" denotes concatenation.

       The sequence number for this record.

       The hashing algorithm specified by

   Note that the MAC is computed before encryption. The stream cipher
   encrypts the entire block, including the MAC. For stream ciphers that
   do not use a synchronization vector (such as RC4), the stream cipher
   state from the end of one record is simply used on the subsequent
   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
   consists of the identity operation (i.e., the data is not encrypted
   and the MAC size is zero implying that no MAC is used).
   TLSCiphertext.length is TLSCompressed.length plus
   CipherSpec.hash_size. CBC block cipher

   For block ciphers (such as RC2 or DES), the encryption and MAC
   functions convert TLSCompressed.fragment structures to and from block
   TLSCiphertext.fragment structures.
ToP   noToC   RFC2246 - Page 20
       block-ciphered struct {
           opaque content[TLSCompressed.length];
           opaque MAC[CipherSpec.hash_size];
           uint8 padding[GenericBlockCipher.padding_length];
           uint8 padding_length;
       } GenericBlockCipher;

   The MAC is generated as described in Section

       Padding that is added to force the length of the plaintext to be
       an integral multiple of the block cipher's block length. The
       padding may be any length up to 255 bytes long, as long as it
       results in the TLSCiphertext.length being an integral multiple of
       the block length. Lengths longer than necessary might be
       desirable to frustrate attacks on a protocol based on analysis of
       the lengths of exchanged messages. Each uint8 in the padding data
       vector must be filled with the padding length value.

       The padding length should be such that the total size of the
       GenericBlockCipher structure is a multiple of the cipher's block
       length. Legal values range from zero to 255, inclusive. This
       length specifies the length of the padding field exclusive of the
       padding_length field itself.

   The encrypted data length (TLSCiphertext.length) is one more than the
   sum of TLSCompressed.length, CipherSpec.hash_size, and

 Example: If the block length is 8 bytes, the content length
          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
          bytes, the length before padding is 82 bytes. Thus, the
          padding length modulo 8 must be equal to 6 in order to make
          the total length an even multiple of 8 bytes (the block
          length). The padding length can be 6, 14, 22, and so on,
          through 254. If the padding length were the minimum necessary,
          6, the padding would be 6 bytes, each containing the value 6.
          Thus, the last 8 octets of the GenericBlockCipher before block
          encryption would be xx 06 06 06 06 06 06 06, where xx is the
          last octet of the MAC.

 Note: With block ciphers in CBC mode (Cipher Block Chaining) the
       initialization vector (IV) for the first record is generated with
       the other keys and secrets when the security parameters are set.
       The IV for subsequent records is the last ciphertext block from
       the previous record.
ToP   noToC   RFC2246 - Page 21
6.3. Key calculation

   The Record Protocol requires an algorithm to generate keys, IVs, and
   MAC secrets from the security parameters provided by the handshake

   The master secret is hashed into a sequence of secure bytes, which
   are assigned to the MAC secrets, keys, and non-export IVs required by
   the current connection state (see Appendix A.6). CipherSpecs require
   a client write MAC secret, a server write MAC secret, 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 order. Unused
   values are empty.

   When generating keys and MAC secrets, the master secret is used as an
   entropy source, and the random values provide unencrypted salt
   material and IVs for exportable ciphers.

   To generate the key material, compute

       key_block = PRF(SecurityParameters.master_secret,
                          "key expansion",
                          SecurityParameters.server_random +

   until enough output has been generated. Then the key_block is
   partitioned as follows:


   The client_write_IV and server_write_IV are only generated for non-
   export block ciphers. For exportable block ciphers, the
   initialization vectors are generated later, as described below. Any
   extra key_block material is discarded.

   Implementation note:
       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
       keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of
       104 bytes of key material.
ToP   noToC   RFC2246 - Page 22
   Exportable encryption algorithms (for which CipherSpec.is_exportable
   is true) require additional processing as follows to derive their
   final write keys:

       final_client_write_key =
                                  "client write key",
                                  SecurityParameters.client_random +
       final_server_write_key =
                                  "server write key",
                                  SecurityParameters.client_random +

   Exportable encryption algorithms derive their IVs solely from the
   random values from the hello messages:

       iv_block = PRF("", "IV block", SecurityParameters.client_random +

   The iv_block is partitioned into two initialization vectors as the
   key_block was above:


   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
   nothing to the hashing in the PRF.

6.3.1. Export key generation example

   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
   keys, for a total of 42 bytes of key material. The PRF output is
   stored in the key_block. The key_block is partitioned, and the write
   keys are salted because this is an exportable encryption algorithm.

       key_block               = PRF(master_secret,
                                     "key expansion",
                                     server_random +
       client_write_MAC_secret = key_block[0..15]
       server_write_MAC_secret = key_block[16..31]
       client_write_key        = key_block[32..36]
       server_write_key        = key_block[37..41]
ToP   noToC   RFC2246 - Page 23
       final_client_write_key  = PRF(client_write_key,
                                     "client write key",
                                     client_random +
       final_server_write_key  = PRF(server_write_key,
                                     "server write key",
                                     client_random +

       iv_block                = PRF("", "IV block", client_random +
       client_write_IV = iv_block[0..7]
       server_write_IV = iv_block[8..15]

(page 23 continued on part 2)

Next Section