-
-
-
-
-
-
- Tim Dierks |
- Independent |
- Eric Rescorla |
-INTERNET-DRAFT RTFM, Inc. |
-<draft-ietf-tls-rfc2246-bis-05.txt> June 2003 (Expires December 2003) |
-
- The TLS Protocol
- Version 1.1 |
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with |
- all provisions of Section 10 of RFC2026. Internet-Drafts are working |
- documents of the Internet Engineering Task Force (IETF), its areas, |
- and its working groups. Note that other groups may also distribute |
- working documents as Internet-Drafts. |
-
- Internet-Drafts are draft documents valid for a maximum of six months |
- and may be updated, replaced, or obsoleted by other documents at any |
- time. It is inappropriate to use Internet-Drafts as reference |
- material or to cite them other than as "work in progress." |
-
- To learn the current status of any Internet-Draft, please check the |
- "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow |
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), |
- munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or |
- ftp.isi.edu (US West Coast).
-Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-Abstract
-
- This document specifies Version 1.1 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
-
-
-
-Dierks & Rescorla Standards Track [Page 1]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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
- 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
- 6.2.3.1. Null or standard stream cipher 19
- 6.2.3.2. 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
- 7.4.1.1. Hello request 33
- 7.4.1.2. Client hello 34
- 7.4.1.3. 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
- 7.4.7.1. RSA encrypted premaster secret message 44
- 7.4.7.2. 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
-
-
-
-Dierks & Rescorla Standards Track [Page 2]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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
- 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
-
-Change history |
-
- Note: Change bars in this draft are from RFC 2246, not draft-00 |
-
- 26-Jun-03 ekr@rtfm.com |
- * Incorporated Last Call comments from Franke Marcus, Jack Lloyd, |
- Brad Wetmore, and others. |
-
- 22-Apr-03 ekr@rtfm.com |
- * coverage of the Vaudenay, Boneh-Brumley, and KPR attacks |
- * cleaned up IV text a bit. |
- * Added discussion of Denial of Service attacks. |
-
-
-
-Dierks & Rescorla Standards Track [Page 3]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- |
- 11-Feb-02 ekr@rtfm.com |
- * Clarified the behavior of empty certificate lists [Nelson Bolyard] |
- * Added text explaining the security implications of authenticate |
- then encrypt. |
- * Cleaned up the explicit IV text. |
- * Added some more acknowledgement names |
-
- 02-Nov-02 ekr@rtfm.com |
- * Changed this to be TLS 1.1. |
- * Added fixes for the Rogaway and Vaudenay CBC attacks |
- * Separated references into normative and informative |
-
- 01-Mar-02 ekr@rtfm.com |
- * Tightened up the language in F.1.1.2 [Peter Watkins] |
- * Fixed smart quotes [Bodo Moeller] |
- * Changed handling of padding errors to prevent CBC-based attack |
- [Bodo Moeller] |
- * Fixed certificate_list spec in the appendix [Aman Sawrup] |
- * Fixed a bug in the V2 definitions [Aman Sawrup] |
- * Fixed S 7.2.1 to point out that you don't need a close notify |
- if you just sent some other fatal alert [Andreas Sterbenz] |
- * Marked alert 41 reserved [Andreas Sterbenz] |
- * Changed S 7.4.2 to point out that 512-bit keys cannot be used for |
- signing [Andreas Sterbenz] |
- * Added reserved client key types from SSLv3 [Andreas Sterbenz] |
- * Changed EXPORT40 to "40-bit EXPORT" in S 9 [Andreas Sterbenz] |
- * Removed RSA patent statement [Andreas Sterbenz] |
- * Removed references to BSAFE and RSAREF [Andreas Sterbenz] |
-
- 14-Feb-02 ekr@rtfm.com |
- * Re-converted to I-D from RFC |
- * Made RSA/3DES the mandatory cipher suite. |
- * Added discussion of the EncryptedPMS encoding and PMS version number|
- issues to 7.4.7.1 |
- * Removed the requirement in 7.4.1.3 that the Server random must be |
- different from the Client random, since these are randomly generated|
- and we don't expect servers to reject Server random values which |
- coincidentally are the same as the Client random. |
- * Replaced may/should/must with MAY/SHOULD/MUST where appropriate. |
- In many cases, shoulds became MUSTs, where I believed that was the |
- actual sense of the text. Added an RFC 2119 bulletin. |
- * Clarified the meaning of "empty certificate" message. [Peter Gutmann]|
- * Redid the CertificateRequest grammar to allow no distinguished names.|
- [Peter Gutmann] |
- * Removed the reference to requiring the master secret to generate |
- the CertificateVerify in F.1.1 [Bodo Moeller] |
- * Deprecated EXPORT40. |
-
-
-
-Dierks & Rescorla Standards Track [Page 4]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- * Fixed a bunch of errors in the SSLv2 backward compatible client hello.|
-
-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
- properties:
-
- - - 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
- 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.
-
-
-
-
-Dierks & Rescorla Standards Track [Page 5]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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.
-
-1.1 Requirements Terminology |
-
- Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and |
- "MAY" that appear in this document are to be interpreted as described |
- in RFC 2119 [REQ]. |
-
-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
- 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
-
-
-
-Dierks & Rescorla Standards Track [Page 6]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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
- security.
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 7]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-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
- brackets.
-
- Single byte entities containing uninterpreted data are of type
- opaque.
-
-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 */
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 8]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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
-
-
-
-
-Dierks & Rescorla Standards Track [Page 9]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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 Color.blue. Such
- qualification is not required if the target of the assignment is well
- specified.
-
- Color color = Color.blue; /* 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]];
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 10]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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
-
-
-
-Dierks & Rescorla Standards Track [Page 11]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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.
-
-
-
-Dierks & Rescorla Standards Track [Page 12]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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,
-
-
-
-
-Dierks & Rescorla Standards Track [Page 13]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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);
-
-
-
-Dierks & Rescorla Standards Track [Page 14]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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 taken to minimize the value of traffic
- analysis of these values.
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 15]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-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 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
- compression.
-
- master secret
- A 48 byte secret shared between the two peers in the connection.
-
- client random
- A 32 byte value provided by the client.
-
-
-
-Dierks & Rescorla Standards Track [Page 16]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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 four items:
-
- client write MAC secret
- server write MAC secret
- client write key
- server write key
-
- 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.
-
- Once the security parameters have been set and the keys have been
-
-
-
-Dierks & Rescorla Standards Track [Page 17]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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
- elements:
-
- 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. For stream ciphers, |
- this will also 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. Sequence numbers do not wrap. If a TLS |
- implementation would need to wrap a sequence number it must |
- renegotiate instead. A sequence number is incremented after each
- record: specifically, the first record which is transmitted under |
- a particular connection state MUST 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;
-
- enum {
-
-
-
-Dierks & Rescorla Standards Track [Page 18]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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;
-
- type
- The higher level protocol used to process the enclosed fragment.
-
- version
- The version of the protocol being employed. This document |
- describes TLS Version 1.1, which uses the version { 3, 2 }. The |
- version value 3.2 is historical: TLS version 1.1 is a minor |
- modification to the TLS 1.0 protocol, which was itself a minor |
- modification to the SSL 3.0 protocol, which bears the version
- value 3.0. (See Appendix A.1).
-
- length
- The length (in bytes) of the following TLSPlaintext.fragment.
- The length should not exceed 2^14.
-
- fragment
- 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 and therefore handshake |
- records may be held if application data is pending. However, |
- records MUST be delivered to the network in the same order as |
- they are protected by the record layer. |
-
-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.
-
-
-
-
-Dierks & Rescorla Standards Track [Page 19]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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;
-
- length
- The length (in bytes) of the following TLSCompressed.fragment.
- The length should not exceed 2^14 + 1024.
-
- fragment
- 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;
-
- type
- The type field is identical to TLSCompressed.type.
-
- version
- The version field is identical to TLSCompressed.version.
-
-
-
-Dierks & Rescorla Standards Track [Page 20]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- length
- The length (in bytes) of the following TLSCiphertext.fragment.
- The length may not exceed 2^14 + 2048.
-
- fragment |
- The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. 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 +
- TLSCompressed.fragment));
-
- where "+" denotes concatenation.
-
- seq_num
- The sequence number for this record.
-
- hash
- The hashing algorithm specified by
- SecurityParameters.mac_algorithm.
-
- 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.
-
-6.2.3.2. 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.
-
-
-
-Dierks & Rescorla Standards Track [Page 21]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- block-ciphered struct {
- opaque IV[CipherSpec.block_length]; |
- 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 6.2.3.1.
-
- IV |
- Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit |
- IV in order to prevent the attacks described by [CBCATT]. |
- We recommend the following equivalently strong procedures. |
- For clarity we use the following notation. |
-
- IV -- the transmitted value of the IV field in the |
- GenericBlockCipher structure. |
- CBC residue -- the last ciphertext block of the previous record |
- mask -- the actual value which the cipher XORs with the |
- plaintext prior to encryption of the first cipher block |
- of the record. |
-
- In prior versions of TLS, there was no IV field and the CBC residue|
- and mask were one and the same. |
-
-
- (1) Generate a cryptographically strong random string R of |
- length CipherSpec.block_length. Place R |
- in the IV field. Set the mask to R. Thus, the first |
- cipher block will be encrypted as E(R XOR Data). |
-
- (2) Generate a cryptographically strong random number R of |
- length CipherSpec.block_length and prepend it to the plaintext|
- prior to encryption. In |
- this case either: |
-
- (a) The cipher may use a fixed mask such as zero. |
- (b) The CBC residue from the previous record may be used |
- as the mask. This preserves maximum code compatibility |
- with TLS 1.0 and SSL 3. It also has the advantage that |
- it does not require the ability to quickly reset the IV, |
- which is known to be a problem on some systems. |
-
- In either case, the data (R || data) is fed into the |
- encryption process. The first cipher block (containing |
- E(mask XOR R) is placed in the IV field. The first |
- block of content contains E(IV XOR data) |
-
-
-
-Dierks & Rescorla Standards Track [Page 22]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- The following alternative procedure MAY be used: However, it has |
- not been demonstrated to be equivalently cryptographically strong |
- to the above procedures. The sender prepends a fixed block F to |
- the plaintext (or alternatively a block generated with a weak |
- PRNG). He then encrypts as in (2) above, using the CBC residue |
- from the previous block as the mask for the prepended block. Note |
- that in this case the mask for the first record transmitted by |
- the application (the Finished) MUST be generated using a |
- cryptographically strong PRNG. |
-
- The decryption operation for all three alternatives is the same. |
- The receiver decrypts the entire GenericBlockCipher structure and |
- then discards the first cipher block, corresponding to the IV |
- component. |
-
- padding
- 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 receiver |
- MUST check this padding and SHOULD use the bad_record_mac alert |
- to indicate padding errors.
-
- padding_length
- The padding length MUST 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
- padding_length.
-
- 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 (this does not |
- include the IV, which may or may not be encrypted, as |
- discussed above). 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
-
-
-
-Dierks & Rescorla Standards Track [Page 23]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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), |
- it is critical that the entire plaintext of the record be known |
- before any ciphertext is transmitted. Otherwise it is possible |
- for the attacker to mount the attack described in [CBCATT]. |
-
- Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a |
- timing attack on CBC padding based on the time required to |
- compute the MAC. In order to defend against this attack, |
- implementations MUST ensure that record processing time is |
- essentially the same whether or not the padding is correct. In |
- general, the best way to to do this is to compute the MAC even if |
- the padding is incorrect, and only then reject the packet. For |
- instance, if the pad appears to be incorrect the implementation |
- might assume a zero-length pad and then compute the MAC. This |
- leaves a small timing channel, since MAC performance depends to |
- some extent on the size of the data fragment, but it is not |
- believed to be large enough to be exploitable due to the large |
- block size of existing MACs and the small size of the timing |
- signal.
-
-6.3. Key calculation
-
- The Record Protocol requires an algorithm to generate keys, and MAC |
- secrets from the security parameters provided by the handshake
- protocol.
-
- The master secret is hashed into a sequence of secure bytes, which |
- are assigned to the MAC secrets and keys 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, and |
- a server write key, 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 for exportable ciphers.
-
- To generate the key material, compute
-
- key_block = PRF(SecurityParameters.master_secret,
- "key expansion",
- SecurityParameters.server_random +
- SecurityParameters.client_random);
-
- until enough output has been generated. Then the key_block is
-
-
-
-Dierks & Rescorla Standards Track [Page 24]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- partitioned as follows:
-
- client_write_MAC_secret[SecurityParameters.hash_size]
- server_write_MAC_secret[SecurityParameters.hash_size]
- client_write_key[SecurityParameters.key_material_length]
- server_write_key[SecurityParameters.key_material_length]
-
-
- 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, for a total 88 bytes of key |
- material.
-
- 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 =
- PRF(SecurityParameters.client_write_key,
- "client write key",
- SecurityParameters.client_random +
- SecurityParameters.server_random);
- final_server_write_key =
- PRF(SecurityParameters.server_write_key,
- "server write key",
- SecurityParameters.client_random +
- SecurityParameters.server_random);
-
-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_random)[0..41]
- 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]
- final_client_write_key = PRF(client_write_key,
- "client write key",
- client_random +
-
-
-
-Dierks & Rescorla Standards Track [Page 25]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- server_random)[0..15]
- final_server_write_key = PRF(server_write_key,
- "server write key",
- client_random +
- server_random)[0..15]
-
-
-7. The TLS Handshake Protocol
-
- The TLS Handshake Protocol consists of a suite of three sub-protocols
- which are used to allow peers to agree upon security parameters for
- the record layer, authenticate themselves, instantiate negotiated
- security parameters, and report error conditions to each other.
-
- The Handshake Protocol is responsible for negotiating a session,
- which consists of the following items:
-
- session identifier
- An arbitrary byte sequence chosen by the server to identify an
- active or resumable session state.
-
- peer certificate
- X509v3 [X509] certificate of the peer. This element of the state
- may be null.
-
- compression method
- The algorithm used to compress data prior to encryption.
-
- cipher spec
- Specifies the bulk data encryption algorithm (such as null, DES,
- etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
- cryptographic attributes such as the hash_size. (See Appendix A.6
- for formal definition)
-
- master secret
- 48-byte secret shared between the client and server.
-
- is resumable
- A flag indicating whether the session can be used to initiate new
- connections.
-
- These items are then used to create security parameters for use by
- the Record Layer when protecting application data. Many connections
- can be instantiated using the same session through the resumption
- feature of the TLS Handshake Protocol.
-
-7.1. Change cipher spec protocol
-
-
-
-
-Dierks & Rescorla Standards Track [Page 26]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- The change cipher spec protocol exists to signal transitions in
- ciphering strategies. The protocol consists of a single message,
- which is encrypted and compressed under the current (not the pending)
- connection state. The message consists of a single byte of value 1.
-
- struct {
- enum { change_cipher_spec(1), (255) } type;
- } ChangeCipherSpec;
-
- The change cipher spec message is sent by both the client and server
- to notify the receiving party that subsequent records will be
- protected under the newly negotiated CipherSpec and keys. Reception
- of this message causes the receiver to instruct the Record Layer to
- immediately copy the read pending state into the read current state. |
- Immediately after sending this message, the sender MUST instruct the
- record layer to make the write pending state the write active state.
- (See section 6.1.) The change cipher spec message is sent during the
- handshake after the security parameters have been agreed upon, but
- before the verifying finished message is sent (see section 7.4.9).
-
-7.2. Alert protocol
-
- One of the content types supported by the TLS Record layer is the
- alert type. Alert messages convey the severity of the message and a
- description of the alert. Alert messages with a level of fatal result
- in the immediate termination of the connection. In this case, other
- connections corresponding to the session may continue, but the |
- session identifier MUST be invalidated, preventing the failed session
- from being used to establish new connections. Like other messages,
- alert messages are encrypted and compressed, as specified by the
- current connection state.
-
- enum { warning(1), fatal(2), (255) } AlertLevel;
-
- enum {
- close_notify(0),
- unexpected_message(10),
- bad_record_mac(20),
- decryption_failed(21),
- record_overflow(22),
- decompression_failure(30),
- handshake_failure(40),
- no_certificate_RESERVED (41), |
- bad_certificate(42),
- unsupported_certificate(43),
- certificate_revoked(44),
- certificate_expired(45),
- certificate_unknown(46),
-
-
-
-Dierks & Rescorla Standards Track [Page 27]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- illegal_parameter(47),
- unknown_ca(48),
- access_denied(49),
- decode_error(50),
- decrypt_error(51),
- export_restriction(60),
- protocol_version(70),
- insufficient_security(71),
- internal_error(80),
- user_canceled(90),
- no_renegotiation(100),
- (255)
- } AlertDescription;
-
- struct {
- AlertLevel level;
- AlertDescription description;
- } Alert;
-
-7.2.1. Closure alerts
-
- The client and the server must share knowledge that the connection is
- ending in order to avoid a truncation attack. Either party may
- initiate the exchange of closing messages.
-
- close_notify
- This message notifies the recipient that the sender will not send |
- any more messages on this connection. The session MUST not be |
- resumed if any connection is terminated without proper
- close_notify messages with level equal to warning.
-
- Either party may initiate a close by sending a close_notify alert.
- Any data received after a closure alert is ignored.
-
- Unless some other fatal alert has been transmitted, each party is |
- required to send a close_notify alert before closing the write side |
- of the connection. The other party MUST respond with a close_notify |
- alert of its own and close down the connection immediately,
- discarding any pending writes. It is not required for the initiator
- of the close to wait for the responding close_notify alert before
- closing the read side of the connection.
-
- If the application protocol using TLS provides that any data may be
- carried over the underlying transport after the TLS connection is
- closed, the TLS implementation must receive the responding
- close_notify alert before indicating to the application layer that
- the TLS connection has ended. If the application protocol will not
- transfer any additional data, but will only close the underlying |
-
-
-
-Dierks & Rescorla Standards Track [Page 28]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- transport connection, then the implementation MAY choose to close the
- transport without waiting for the responding close_notify. No part of
- this standard should be taken to dictate the manner in which a usage
- profile for TLS manages its data transport, including when
- connections are opened or closed.
-
- NB: It is assumed that closing a connection reliably delivers
- pending data before destroying the transport.
-
-7.2.2. Error alerts
-
- Error handling in the TLS Handshake protocol is very simple. When an
- error is detected, the detecting party sends a message to the other
- party. Upon transmission or receipt of an fatal alert message, both |
- parties immediately close the connection. Servers and clients MUST |
- forget any session-identifiers, keys, and secrets associated with a
- failed connection. The following error alerts are defined:
-
- unexpected_message
- An inappropriate message was received. This alert is always fatal
- and should never be observed in communication between proper
- implementations.
-
- bad_record_mac
- This alert is returned if a record is received with an incorrect |
- MAC. This alert also SHOULD be returned if a TLSCiphertext |
- decrypted in an invalid way: either it wasn't an even multiple of |
- the block length, or its padding values, when checked, weren't |
- correct. This message is always fatal.
-
- decryption_failed
- This alert MAY be returned if a TLSCiphertext decrypted in an |
- invalid way: either it wasn't an even multiple of the block |
- length, or its padding values, when checked, weren't correct. |
- This message is always fatal. |
-
- NB: Differentiating between bad_record_mac and decryption_failed |
- alerts may permit certain attacks against CBC mode as used in TLS |
- [CBCATT]. It is preferable to uniformly use the bad_record_mac |
- alert to hide the specific type of the error. |
-
-
- record_overflow
- A TLSCiphertext record was received which had a length more than
- 2^14+2048 bytes, or a record decrypted to a TLSCompressed record
- with more than 2^14+1024 bytes. This message is always fatal.
-
- decompression_failure
-
-
-
-Dierks & Rescorla Standards Track [Page 29]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- The decompression function received improper input (e.g. data
- that would expand to excessive length). This message is always
- fatal.
-
- handshake_failure
- Reception of a handshake_failure alert message indicates that the
- sender was unable to negotiate an acceptable set of security
- parameters given the options available. This is a fatal error.
-
- no_certificate_RESERVED |
- This alert was used in SSLv3 but not in TLS. It should not be |
- sent by compliant implementations. |
-
- bad_certificate
- A certificate was corrupt, contained signatures that did not
- verify correctly, etc.
-
- unsupported_certificate
- A certificate was of an unsupported type.
-
- certificate_revoked
- A certificate was revoked by its signer.
-
- certificate_expired
- A certificate has expired or is not currently valid.
-
- certificate_unknown
- Some other (unspecified) issue arose in processing the
- certificate, rendering it unacceptable.
-
- illegal_parameter
- A field in the handshake was out of range or inconsistent with
- other fields. This is always fatal.
-
- unknown_ca
- A valid certificate chain or partial chain was received, but the
- certificate was not accepted because the CA certificate could not |
- be located or couldn't be matched with a known, trusted CA. This
- message is always fatal.
-
- access_denied
- A valid certificate was received, but when access control was
- applied, the sender decided not to proceed with negotiation.
- This message is always fatal.
-
- decode_error
- A message could not be decoded because some field was out of the
- specified range or the length of the message was incorrect. This
-
-
-
-Dierks & Rescorla Standards Track [Page 30]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- message is always fatal.
-
- decrypt_error
- A handshake cryptographic operation failed, including being
- unable to correctly verify a signature, decrypt a key exchange,
- or validate a finished message.
-
- export_restriction
- A negotiation not in compliance with export restrictions was
- detected; for example, attempting to transfer a 1024 bit
- ephemeral RSA key for the RSA_EXPORT handshake method. This
- message is always fatal.
-
- protocol_version
- The protocol version the client has attempted to negotiate is
- recognized, but not supported. (For example, old protocol
- versions might be avoided for security reasons). This message is
- always fatal.
-
- insufficient_security
- Returned instead of handshake_failure when a negotiation has
- failed specifically because the server requires ciphers more
- secure than those supported by the client. This message is always
- fatal.
-
- internal_error
- An internal error unrelated to the peer or the correctness of the
- protocol makes it impossible to continue (such as a memory
- allocation failure). This message is always fatal.
-
- user_canceled
- This handshake is being canceled for some reason unrelated to a
- protocol failure. If the user cancels an operation after the
- handshake is complete, just closing the connection by sending a
- close_notify is more appropriate. This alert should be followed
- by a close_notify. This message is generally a warning.
-
- no_renegotiation
- Sent by the client in response to a hello request or by the
- server in response to a client hello after initial handshaking.
- Either of these would normally lead to renegotiation; when that
- is not appropriate, the recipient should respond with this alert;
- at that point, the original requester can decide whether to
- proceed with the connection. One case where this would be
- appropriate would be where a server has spawned a process to
- satisfy a request; the process might receive security parameters
- (key length, authentication, etc.) at startup and it might be
- difficult to communicate changes to these parameters after that
-
-
-
-Dierks & Rescorla Standards Track [Page 31]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- point. This message is always a warning.
-
- For all errors where an alert level is not explicitly specified, the |
- sending party MAY determine at its discretion whether this is a fatal
- error or not; if an alert with a level of warning is received, the
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 32]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- receiving party MAY decide at its discretion whether to treat this as |
- a fatal error or not. However, all messages which are transmitted |
- with a level of fatal MUST be treated as fatal messages.
-
-7.3. Handshake Protocol overview
-
- The cryptographic parameters of the session state are produced by the
- TLS Handshake Protocol, which operates on top of the TLS Record
- Layer. When a TLS client and server first start communicating, they
- agree on a protocol version, select cryptographic algorithms,
- optionally authenticate each other, and use public-key encryption
- techniques to generate shared secrets.
-
- The TLS Handshake Protocol involves the following steps:
-
- - - Exchange hello messages to agree on algorithms, exchange random
- values, and check for session resumption.
-
- - - Exchange the necessary cryptographic parameters to allow the
- client and server to agree on a premaster secret.
-
- - - Exchange certificates and cryptographic information to allow
- the client and server to authenticate themselves.
-
- - - Generate a master secret from the premaster secret and
- exchanged random values.
-
- - - Provide security parameters to the record layer.
-
- - - Allow the client and server to verify that their peer has
- calculated the same security parameters and that the handshake
- occurred 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.
-
-
-
-
-Dierks & Rescorla Standards Track [Page 33]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- 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
- summarized as follows: The client sends a client hello message to
- which the server must respond with a server hello message, or else a
- fatal error will occur and the connection will fail. The client hello
- and server hello are used to establish security enhancement
- capabilities between client and server. The client hello and server
- hello establish the following attributes: Protocol Version, Session
- ID, Cipher Suite, and Compression Method. Additionally, two random
- values are generated and exchanged: ClientHello.random and
- ServerHello.random.
-
- The actual key exchange uses up to four messages: the server
- certificate, the server key exchange, the client certificate, and the
- client key exchange. New key exchange methods can be created by
- specifying a format for these messages and defining the use of the
- messages to allow the client and server to agree upon a shared |
- secret. This secret MUST be quite long; currently defined key
- exchange methods exchange secrets which range from 48 to 128 bytes in
- length.
-
- Following the hello messages, the server will send its certificate,
- if it is to be authenticated. Additionally, a server key exchange
- message may be sent, if it is required (e.g. if their server has no
- certificate, or if its certificate is for signing only). If the
- server is authenticated, it may request a certificate from the
- client, if that is appropriate to the cipher suite selected. Now the
- server will send the server hello done message, indicating that the
- hello-message phase of the handshake is complete. The server will
- then wait for a client response. If the server has sent a certificate
- request message, the client must send the certificate message. The
- client key exchange message is now sent, and the content of that
- message will depend on the public key algorithm selected between the
- client hello and the server hello. If the client has sent a
- certificate with signing ability, a digitally-signed certificate
- verify message is sent to explicitly verify the certificate.
-
- At this point, a change cipher spec message is sent by the client,
- and the client copies the pending Cipher Spec into the current Cipher
- Spec. The client then immediately sends the finished message under
- the new algorithms, keys, and secrets. In response, the server will
- send its own change cipher spec message, transfer the pending to the
- current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 34]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- Cipher Spec. At this point, the handshake is complete and the client
- and server may begin to exchange application layer data. (See flow
- chart below.)
-
- Client Server
-
- ClientHello -------->
- ServerHello
- Certificate*
- ServerKeyExchange*
- CertificateRequest*
- <-------- ServerHelloDone
- Certificate*
- ClientKeyExchange
- CertificateVerify*
- [ChangeCipherSpec]
- Finished -------->
- [ChangeCipherSpec]
- <-------- Finished
- Application Data <-------> Application Data
-
- Fig. 1 - Message flow for a full handshake
-
- * Indicates optional or situation-dependent messages that are not
- always sent.
-
- Note: To help avoid pipeline stalls, ChangeCipherSpec is an
- independent TLS Protocol content type, and is not actually a TLS
- handshake message.
-
- When the client and server decide to resume a previous session or
- duplicate an existing session (instead of negotiating new security
- parameters) the message flow is as follows:
-
- The client sends a ClientHello using the Session ID of the session to
- be resumed. The server then checks its session cache for a match. If
- a match is found, and the server is willing to re-establish the
- connection under the specified session state, it will send a
- ServerHello with the same Session ID value. At this point, both |
- client and server MUST send change cipher spec messages and proceed
- directly to finished messages. Once the re-establishment is complete, |
- the client and server MAY begin to exchange application layer data.
- (See flow chart below.) If a Session ID match is not found, the
- server generates a new session ID and the TLS client and server
- perform a full handshake.
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 35]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- Client Server
-
- ClientHello -------->
- ServerHello
- [ChangeCipherSpec]
- <-------- Finished
- [ChangeCipherSpec]
- Finished -------->
- Application Data <-------> Application Data
-
- Fig. 2 - Message flow for an abbreviated handshake
-
- The contents and significance of each message will be presented in
- detail in the following sections.
-
-7.4. Handshake protocol
-
- The TLS Handshake Protocol is one of the defined higher level clients
- of the TLS Record Protocol. This protocol is used to negotiate the
- secure attributes of a session. Handshake messages are supplied to
- the TLS Record Layer, where they are encapsulated within one or more
- TLSPlaintext structures, which are processed and transmitted as
- specified by the current active session state.
-
- enum {
- hello_request(0), client_hello(1), server_hello(2),
- certificate(11), server_key_exchange (12),
- certificate_request(13), server_hello_done(14),
- certificate_verify(15), client_key_exchange(16),
- finished(20), (255)
- } HandshakeType;
-
- struct {
- HandshakeType msg_type; /* handshake type */
- uint24 length; /* bytes in message */
- select (HandshakeType) {
- case hello_request: HelloRequest;
- case client_hello: ClientHello;
- case server_hello: ServerHello;
- case certificate: Certificate;
- case server_key_exchange: ServerKeyExchange;
- case certificate_request: CertificateRequest;
- case server_hello_done: ServerHelloDone;
- case certificate_verify: CertificateVerify;
- case client_key_exchange: ClientKeyExchange;
- case finished: Finished;
- } body;
- } Handshake;
-
-
-
-Dierks & Rescorla Standards Track [Page 36]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- The handshake protocol messages are presented below in the order they |
- MUST be sent; sending handshake messages in an unexpected order
- results in a fatal error. Unneeded handshake messages can be omitted,
- however. Note one exception to the ordering: the Certificate message
- is used twice in the handshake (from server to client, then from
- client to server), but described only in its first position. The one
- message which is not bound by these ordering rules is the Hello |
- Request message, which can be sent at any time, but which should be
- ignored by the client if it arrives in the middle of a handshake.
-
-7.4.1. Hello messages
-
- The hello phase messages are used to exchange security enhancement
- capabilities between the client and server. When a new session
- begins, the Record Layer's connection state encryption, hash, and
- compression algorithms are initialized to null. The current
- connection state is used for renegotiation messages.
-
-7.4.1.1. Hello request
-
- When this message will be sent:
- The hello request message MAY be sent by the server at any time. |
-
- Meaning of this message:
- Hello request is a simple notification that the client should
- begin the negotiation process anew by sending a client hello
- message when convenient. This message will be ignored by the
- client if the client is currently negotiating a session. This
- message may be ignored by the client if it does not wish to
- renegotiate a session, or the client may, if it wishes, respond
- with a no_renegotiation alert. Since handshake messages are
- intended to have transmission precedence over application data,
- it is expected that the negotiation will begin before no more
- than a few records are received from the client. If the server
- sends a hello request but does not receive a client hello in
- response, it may close the connection with a fatal alert.
-
- After sending a hello request, servers SHOULD not repeat the request |
- until the subsequent handshake negotiation is complete.
-
- Structure of this message:
- struct { } HelloRequest;
-
- Note: This message MUST NOT be included in the message hashes which are |
- maintained throughout the handshake and used in the finished
- messages and the certificate verify message.
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 37]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-7.4.1.2. Client hello
-
- When this message will be sent:
- When a client first connects to a server it is required to send
- the client hello as its first message. The client can also send a
- client hello in response to a hello request or on its own
- initiative in order to renegotiate the security parameters in an
- existing connection.
-
- Structure of this message:
- The client hello message includes a random structure, which is
- used later in the protocol.
-
- struct {
- uint32 gmt_unix_time;
- opaque random_bytes[28];
- } Random;
-
- gmt_unix_time
- The current time and date in standard UNIX 32-bit format (seconds
- since the midnight starting Jan 1, 1970, GMT) according to the
- sender's internal clock. Clocks are not required to be set
- correctly by the basic TLS Protocol; higher level or application
- protocols may define additional requirements.
-
- random_bytes
- 28 bytes generated by a secure random number generator.
-
- The client hello message includes a variable length session |
- identifier. If not empty, the value identifies a session between the
- same client and server whose security parameters the client wishes to |
- reuse. The session identifier MAY be from an earlier connection, this
- connection, or another currently active connection. The second option
- is useful if the client only wishes to update the random structures
- and derived values of a connection, while the third option makes it
- possible to establish several independent secure connections without
- repeating the full handshake protocol. These independent connections
- may occur sequentially or simultaneously; a SessionID becomes valid
- when the handshake negotiating it completes with the exchange of
- Finished messages and persists until removed due to aging or because
- a fatal error was encountered on a connection associated with the
- session. The actual contents of the SessionID are defined by the
- server.
-
- opaque SessionID<0..32>;
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 38]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- Warning:
- Because the SessionID is transmitted without encryption or |
- immediate MAC protection, servers MUST not place confidential
- information in session identifiers or let the contents of fake
- session identifiers cause any breach of security. (Note that the
- content of the handshake as a whole, including the SessionID, is
- protected by the Finished messages exchanged at the end of the
- handshake.)
-
- The CipherSuite list, passed from the client to the server in the |
- client hello message, contains the combinations of cryptographic
- algorithms supported by the client in order of the client's
- preference (favorite choice first). Each CipherSuite defines a key
- exchange algorithm, a bulk encryption algorithm (including secret key
- length) and a MAC algorithm. The server will select a cipher suite
- or, if no acceptable choices are presented, return a handshake
- failure alert and close the connection.
-
- uint8 CipherSuite[2]; /* Cryptographic suite selector */
-
- The client hello includes a list of compression algorithms supported
- by the client, ordered according to the client's preference.
-
- enum { null(0), (255) } CompressionMethod;
-
- struct {
- ProtocolVersion client_version;
- Random random;
- SessionID session_id;
- CipherSuite cipher_suites<2..2^16-1>;
- CompressionMethod compression_methods<1..2^8-1>;
- } ClientHello;
-
- client_version
- The version of the TLS protocol by which the client wishes to |
- communicate during this session. This SHOULD be the latest
- (highest valued) version supported by the client. For this |
- version of the specification, the version will be 3.2 (See
- Appendix E for details about backward compatibility).
-
- random
- A client-generated random structure.
-
- session_id
- The ID of a session the client wishes to use for this connection.
- This field should be empty if no session_id is available or the
- client wishes to generate new security parameters.
-
-
-
-
-Dierks & Rescorla Standards Track [Page 39]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- cipher_suites
- This is a list of the cryptographic options supported by the
- client, with the client's first preference first. If the
- session_id field is not empty (implying a session resumption |
- request) this vector MUST include at least the cipher_suite from
- that session. Values are defined in Appendix A.5.
-
- compression_methods
- This is a list of the compression methods supported by the
- client, sorted by client preference. If the session_id field is
- not empty (implying a session resumption request) it must include
- the compression_method from that session. This vector must
- contain, and all implementations must support,
- CompressionMethod.null. Thus, a client and server will always be
- able to agree on a compression method.
-
- After sending the client hello message, the client waits for a server
- hello message. Any other handshake message returned by the server
- except for a hello request is treated as a fatal error.
-
- Forward compatibility note:
- In the interests of forward compatibility, it is permitted for a
- client hello message to include extra data after the compression |
- methods. This data MUST be included in the handshake hashes, but
- must otherwise be ignored. This is the only handshake message for
- which this is legal; for all other messages, the amount of data |
- in the message MUST match the description of the message
- precisely.
-
-Note: For the intended use of trailing data in the ClientHello, see RFC |
- 3546 [TLSEXT]. |
-
-7.4.1.3. Server hello
-
- When this message will be sent:
- The server will send this message in response to a client hello
- message when it was able to find an acceptable set of algorithms.
- If it cannot find such a match, it will respond with a handshake
- failure alert.
-
- Structure of this message:
- struct {
- ProtocolVersion server_version;
- Random random;
- SessionID session_id;
- CipherSuite cipher_suite;
- CompressionMethod compression_method;
- } ServerHello;
-
-
-
-Dierks & Rescorla Standards Track [Page 40]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- server_version
- This field will contain the lower of that suggested by the client
- in the client hello and the highest supported by the server. For
- this version of the specification, the version is 3.2 (See |
- Appendix E for details about backward compatibility).
-
- random
- This structure is generated by the server and MUST be |
- independently generated from the ClientHello.random.
-
- session_id
- This is the identity of the session corresponding to this
- connection. If the ClientHello.session_id was non-empty, the
- 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
- using the specified session state, the server will respond with
- the same value as was supplied by the client. This indicates a
- resumed session and dictates that the parties must proceed
- directly to the finished messages. Otherwise this field will
- contain a different value identifying the new session. The server
- may return an empty session_id to indicate that the 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
- The single cipher suite selected by the server from the list in
- ClientHello.cipher_suites. For resumed sessions this field is the
- value from the state of the session being resumed.
-
- compression_method |
- The single compression algorithm selected by the server from the
- list in ClientHello.compression_methods. For resumed sessions
- this field is the value from the resumed session state.
-
-7.4.2. Server certificate
-
- When this message will be sent:
- The server MUST send a certificate whenever the agreed-upon key |
- exchange method is not an anonymous one. This message will always
- immediately follow the server hello message.
-
- Meaning of this message:
- The certificate type MUST be appropriate for the selected cipher |
- suite's key exchange algorithm, and is generally an X.509v3 |
- certificate. It MUST contain a key which matches the key exchange
- method, as follows. Unless otherwise specified, the signing
-
-
-
-
-Dierks & Rescorla Standards Track [Page 41]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- algorithm for the certificate MUST be the same as the algorithm |
- for the certificate key. Unless otherwise specified, the public |
- key MAY be of any length.
-
- Key Exchange Algorithm Certificate Key Type
-
- RSA RSA public key; the certificate MUST |
- allow the key to be used for encryption.
-
- RSA_EXPORT RSA public key of length greater than
- 512 bits which can be used for signing,
- or a key of 512 bits or shorter which
- can be used for encryption. |
-
- DHE_DSS DSS public key.
-
- DHE_DSS_EXPORT DSS public key.
-
- DHE_RSA RSA public key which can be used for
- signing.
-
- DHE_RSA_EXPORT RSA public key which can be used for
- signing.
-
- DH_DSS Diffie-Hellman key. The algorithm used
- to sign the certificate MUST be DSS. |
-
- DH_RSA Diffie-Hellman key. The algorithm used
- to sign the certificate MUST be RSA. |
-
- All certificate profiles, key and cryptographic formats are defined
- by the IETF PKIX working group [PKIX]. When a key usage extension is |
- present, the digitalSignature bit MUST be set for the key to be
- eligible for signing, as described above, and the keyEncipherment bit |
- MUST be present to allow encryption, as described above. The
- keyAgreement bit must be set on Diffie-Hellman certificates.
-
- As CipherSuites which specify new key exchange methods are specified
- for the TLS Protocol, they will imply certificate format and the
- required encoded keying information.
-
- Structure of this message:
- opaque ASN.1Cert<1..2^24-1>;
-
- struct {
- ASN.1Cert certificate_list<0..2^24-1>;
- } Certificate;
-
-
-
-
-Dierks & Rescorla Standards Track [Page 42]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- certificate_list
- This is a sequence (chain) of X.509v3 certificates. The sender's
- certificate must come first in the list. Each following
- certificate must directly certify the one preceding it. Because
- certificate validation requires that root keys be distributed
- independently, the self-signed certificate which specifies the
- root certificate authority may optionally be omitted from the
- chain, under the assumption that the remote end must already
- possess it in order to validate it in any case.
-
- The same message type and structure will be used for the client's |
- response to a certificate request message. Note that a client MAY
- send no certificates if it does not have an appropriate certificate
- to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
- vector because PKCS #6 [PKCS6] extended certificates are not
- used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
- the task of parsing the list more difficult.
-
-7.4.3. Server key exchange message
-
- When this message will be sent:
- This message will be sent immediately after the server
- certificate message (or the server hello message, if this is an
- anonymous negotiation).
-
- The server key exchange message is sent by the server only when
- the server certificate message (if sent) does not contain enough
- data to allow the client to exchange a premaster secret. This is
- true for the following key exchange methods:
-
- RSA_EXPORT (if the public key in the server certificate is
- longer than 512 bits)
- DHE_DSS
- DHE_DSS_EXPORT
- DHE_RSA
- DHE_RSA_EXPORT
- DH_anon
-
- It is not legal to send the server key exchange message for the
- following key exchange methods:
-
- RSA
- RSA_EXPORT (when the public key in the server certificate is
- less than or equal to 512 bits in length)
- DH_DSS
- DH_RSA
-
-
-
-Dierks & Rescorla Standards Track [Page 43]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- Meaning of this message:
- This message conveys cryptographic information to allow the
- client to communicate the premaster secret: either an RSA public
- key to encrypt the premaster secret with, or a Diffie-Hellman
- public key with which the client can complete a key exchange
- (with the result being the premaster secret.)
-
- As additional CipherSuites are defined for TLS which include new key |
- exchange algorithms, the server key exchange message will be sent if
- and only if the certificate type associated with the key exchange
- algorithm does not provide enough information for the client to
- exchange a premaster secret.
-
- Note: According to current US export law, RSA moduli larger than 512
- bits may not be used for key exchange in software exported from
- the US. With this message, the larger RSA keys encoded in
- certificates may be used to sign temporary shorter RSA keys for
- the RSA_EXPORT key exchange method.
-
- Structure of this message:
- enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
- struct {
- opaque rsa_modulus<1..2^16-1>;
- opaque rsa_exponent<1..2^16-1>;
- } ServerRSAParams;
-
- rsa_modulus
- The modulus of the server's temporary RSA key.
-
- rsa_exponent
- The public exponent of the server's temporary RSA key.
-
- struct {
- opaque dh_p<1..2^16-1>;
- opaque dh_g<1..2^16-1>;
- opaque dh_Ys<1..2^16-1>;
- } ServerDHParams; /* Ephemeral DH parameters */
-
- dh_p
- The prime modulus used for the Diffie-Hellman operation.
-
- dh_g
- The generator used for the Diffie-Hellman operation.
-
- dh_Ys
- The server's Diffie-Hellman public value (g^X mod p).
-
-
-
-
-Dierks & Rescorla Standards Track [Page 44]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- struct {
- select (KeyExchangeAlgorithm) {
- case diffie_hellman:
- ServerDHParams params;
- Signature signed_params;
- case rsa:
- ServerRSAParams params;
- Signature signed_params;
- };
- } ServerKeyExchange;
-
- struct { |
- select (KeyExchangeAlgorithm) { |
- case diffie_hellman: |
- ServerDHParams params; |
- case rsa: |
- ServerRSAParams params; |
- }; |
- } ServerParams; |
-
- params
- The server's key exchange parameters.
-
- signed_params
- For non-anonymous key exchanges, a hash of the corresponding
- params value, with the signature appropriate to that hash
- applied.
-
- md5_hash
- MD5(ClientHello.random + ServerHello.random + ServerParams);
-
- sha_hash
- SHA(ClientHello.random + ServerHello.random + ServerParams);
-
- enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
- select (SignatureAlgorithm) |
- { |
- case anonymous: struct { }; |
- case rsa:
- digitally-signed struct {
- opaque md5_hash[16];
- opaque sha_hash[20];
- };
- case dsa:
- digitally-signed struct {
- opaque sha_hash[20];
-
-
-
-Dierks & Rescorla Standards Track [Page 45]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- };
- } Signature;
-
-7.4.4. Certificate request
-
- When this message will be sent:
- A non-anonymous server can optionally request a certificate from
- the client, if appropriate for the selected cipher suite. This
- message, if sent, will immediately follow the Server Key Exchange
- message (if it is sent; otherwise, the Server Certificate
- message).
-
- Structure of this message:
- enum {
- rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
- rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), |
- fortezza_dms_RESERVED(20), |
- (255)
- } ClientCertificateType;
-
- opaque DistinguishedName<1..2^16-1>;
-
- struct {
- ClientCertificateType certificate_types<1..2^8-1>;
- DistinguishedName certificate_authorities<0..2^16-1>; |
- } CertificateRequest;
-
- certificate_types
- This field is a list of the types of certificates requested, |
- sorted in order of the server's preference. |
-
- certificate_authorities
- A list of the distinguished names of acceptable certificate
- authorities. These distinguished names may specify a desired
- distinguished name for a root CA or for a subordinate CA;
- thus, this message can be used both to describe known roots |
- and a desired authorization space. If the |
- certificate_authorities list is empty then the client MAY |
- send any certificate of the appropriate |
- ClientCertificateType, unless there is some external |
- arrangement to the contrary. |
-
-
- Note: Values listed as RESERVED may not be used. They were used in |
- SSLv3.
-
- Note: DistinguishedName is derived from [X509].
-
-
-
-
-Dierks & Rescorla Standards Track [Page 46]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
- request client authentication. |
-
-7.4.5. Server hello done
-
- When this message will be sent:
- The server hello done message is sent by the server to indicate
- the end of the server hello and associated messages. After
- sending this message the server will wait for a client response.
-
- Meaning of this message:
- This message means that the server is done sending messages to
- support the key exchange, and the client can proceed with its
- phase of the key exchange.
-
- Upon receipt of the server hello done message the client SHOULD |
- verify that the server provided a valid certificate if required
- and check that the server hello parameters are acceptable.
-
- Structure of this message:
- struct { } ServerHelloDone;
-
-7.4.6. Client certificate
-
- When this message will be sent:
- This is the first message the client can send after receiving a
- server hello done message. This message is only sent if the
- server requests a certificate. If no suitable certificate is
- available, the client should send a certificate message |
- containing no certificates: I.e. the certificate_list structure |
- should have a length of zero. If client authentication is |
- required by the server for the handshake to continue, it may
- respond with a fatal handshake failure alert. Client certificates
- are sent using the Certificate structure defined in Section
- 7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method |
- (DH_DSS or DH_RSA), if client authentication is requested, the
- Diffie-Hellman group and generator encoded in the client's
- certificate must match the server specified Diffie-Hellman
- parameters if the client's parameters are to be used for the key
- exchange.
-
-7.4.7. Client key exchange message
-
- When this message will be sent:
- This message is always sent by the client. It will immediately
-
-
-
-Dierks & Rescorla Standards Track [Page 47]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- follow the client certificate message, if it is sent. Otherwise
- it will be the first message sent by the client after it receives
- the server hello done message.
-
- Meaning of this message:
- With this message, the premaster secret is set, either though
- direct transmission of the RSA-encrypted secret, or by the
- transmission of Diffie-Hellman parameters which will allow each
- side to agree upon the same premaster secret. When the key
- exchange method is DH_RSA or DH_DSS, client certification has
- been requested, and the client was able to respond with a
- certificate which contained a Diffie-Hellman public key whose
- parameters (group and generator) matched those specified by the |
- server in its certificate, this message MUST not contain any
- data.
-
- Structure of this message:
- The choice of messages depends on which key exchange method has
- been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
- definition.
-
- struct {
- select (KeyExchangeAlgorithm) {
- case rsa: EncryptedPreMasterSecret;
- case diffie_hellman: ClientDiffieHellmanPublic;
- } exchange_keys;
- } ClientKeyExchange;
-
-7.4.7.1. RSA encrypted premaster secret message
-
- Meaning of this message:
- If RSA is being used for key agreement and authentication, the
- client generates a 48-byte premaster secret, encrypts it using
- the public key from the server's certificate or the temporary RSA
- key provided in a server key exchange message, and sends the
- result in an encrypted premaster secret message. This structure
- is a variant of the client key exchange message, not a message in
- itself.
-
- Structure of this message:
- struct {
- ProtocolVersion client_version;
- opaque random[46];
- } PreMasterSecret;
-
- client_version
- The latest (newest) version supported by the client. This is
- used to detect version roll-back attacks. Upon receiving the |
-
-
-
-Dierks & Rescorla Standards Track [Page 48]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- premaster secret, the server SHOULD check that this value
- matches the value transmitted by the client in the client
- hello message.
-
- random
- 46 securely-generated random bytes.
-
- struct {
- public-key-encrypted PreMasterSecret pre_master_secret;
- } EncryptedPreMasterSecret;
-
- pre_master_secret |
- This random value is generated by the client and is used to |
- generate the master secret, as specified in Section 8.1. |
-
- Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
- to attack a TLS server which is using PKCS#1 encoded RSA. The
- attack takes advantage of the fact that by failing in different
- ways, a TLS server can be coerced into revealing whether a
- particular message, when decrypted, is properly PKCS#1 formatted
- or not.
-
- The best way to avoid vulnerability to this attack is to treat
- incorrectly formatted messages in a manner indistinguishable from
- correctly formatted RSA blocks. Thus, when it receives an
- incorrectly formatted RSA block, a server should generate a
- random 48-byte value and proceed using it as the premaster
- secret. Thus, the server will act identically whether the |
- received RSA block is correctly encoded or not. |
-
- Implementation Note: public-key-encrypted data is represented as an |
- opaque vector <0..2^16-1> (see S. 4.7). Thus the RSA-encrypted |
- PreMaster Secret in a ClientKeyExchange is preceded by two length |
- bytes. These bytes are redundant in the case of RSA because the |
- EncryptedPreMasterSecret is the only data in the |
- ClientKeyExchange and its length can therefore be unambiguously |
- determined. The SSLv3 specification was not clear about the |
- encoding of public-key-encrypted data and therefore many SSLv3 |
- implementations do not include the the length bytes, encoding the |
- RSA encrypted data directly in the ClientKeyExchange message. |
-
- This specification requires correct encoding of the |
- EncryptedPreMasterSecret complete with length bytes. The |
- resulting PDU is incompatible with many SSLv3 implementations. |
- Implementors upgrading from SSLv3 must modify their |
- implementations to generate and accept the correct encoding. |
- Implementors who wish to be compatible with both SSLv3 and TLS |
- should make their implementation's behavior dependent on the |
-
-
-
-Dierks & Rescorla Standards Track [Page 49]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- protocol version. |
-
- Implementation Note: It is now known that remote timing-based attacks |
- on SSL are possible, at least when the client and server are on |
- the same LAN. Accordingly, implementations which use static RSA |
- keys SHOULD use RSA blinding or some other anti-timing technique, |
- as described in [TIMING].
-
- Note: The version number in the PreMasterSecret is that offered by the |
- client, NOT the version negotiated for the connection. This |
- feature is designed to prevent rollback attacks. Unfortunately, |
- many implementations use the negotiated version instead and |
- therefore checking the version number may lead to failure to |
- interoperate with such incorrect client implementations. Client |
- implementations MUST and Server implementations MAY check the |
- version number. In practice, since there are no significant known |
- security differences between TLS and SSLv3, rollback to SSLv3 is |
- not believed to be a serious security risk. Note that if servers |
- choose to to check the version number, they should randomize the |
- PreMasterSecret in case of error, rather than generate an alert, |
- in order to avoid variants on the Bleichenbacher attack. [KPR03]
-
-7.4.7.2. Client Diffie-Hellman public value
-
- Meaning of this message:
- This structure conveys the client's Diffie-Hellman public value
- (Yc) if it was not already included in the client's certificate.
- The encoding used for Yc is determined by the enumerated
- PublicValueEncoding. This structure is a variant of the client
- key exchange message, not a message in itself.
-
- Structure of this message:
- enum { implicit, explicit } PublicValueEncoding;
-
- implicit
- If the client certificate already contains a suitable Diffie-
- Hellman key, then Yc is implicit and does not need to be sent
- again. In this case, the Client Key Exchange message will be
- sent, but will be empty.
-
- explicit
- Yc needs to be sent.
-
- struct {
- select (PublicValueEncoding) {
- case implicit: struct { };
- case explicit: opaque dh_Yc<1..2^16-1>;
- } dh_public;
-
-
-
-Dierks & Rescorla Standards Track [Page 50]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- } ClientDiffieHellmanPublic;
-
- dh_Yc
- The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
- When this message will be sent:
- This message is used to provide explicit verification of a client
- certificate. This message is only sent following a client
- certificate that has signing capability (i.e. all certificates
- except those containing fixed Diffie-Hellman parameters). When
- sent, it will immediately follow the client key exchange message.
-
- Structure of this message:
- struct {
- Signature signature;
- } CertificateVerify;
-
- The Signature type is defined in 7.4.3.
-
- CertificateVerify.signature.md5_hash
- MD5(handshake_messages);
-
- CertificateVerify.signature.sha_hash |
- SHA(handshake_messages);
-
- Here handshake_messages refers to all handshake messages sent or
- received starting at client hello up to but not including this
- message, including the type and length fields of the handshake
- messages. This is the concatenation of all the Handshake structures
- as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
- When this message will be sent:
- A finished message is always sent immediately after a change
- cipher spec message to verify that the key exchange and
- authentication processes were successful. It is essential that a
- change cipher spec message be received between the other
- handshake messages and the Finished message.
-
- Meaning of this message:
- The finished message is the first protected with the just-
- negotiated algorithms, keys, and secrets. Recipients of finished |
- messages MUST verify that the contents are correct. Once a side
- has sent its Finished message and received and validated the
- Finished message from its peer, it may begin to send and receive
-
-
-
-Dierks & Rescorla Standards Track [Page 51]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- application data over the connection.
-
- struct {
- opaque verify_data[12];
- } Finished;
-
- verify_data
- PRF(master_secret, finished_label, MD5(handshake_messages) +
- SHA-1(handshake_messages)) [0..11];
-
- finished_label
- For Finished messages sent by the client, the string "client
- finished". For Finished messages sent by the server, the
- string "server finished".
-
- handshake_messages
- All of the data from all handshake messages up to but not
- including this message. This is only data visible at the
- handshake layer and does not include record layer headers.
- This is the concatenation of all the Handshake structures as
- defined in 7.4 exchanged thus far.
-
- It is a fatal error if a finished message is not preceded by a change
- cipher spec message at the appropriate point in the handshake.
-
- The value handshake_messages includes all handshake messages starting |
- at client hello up to, but not including, this finished message. This
- may be different from handshake_messages in Section 7.4.8 because it
- would include the certificate verify message (if sent). Also, the
- handshake_messages for the finished message sent by the client will
- be different from that for the finished message sent by the server,
- because the one which is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts and any other record types
- are not handshake messages and are not included in the hash
- computations. Also, Hello Request messages are omitted from
- handshake hashes.
-
-8. Cryptographic computations
-
- In order to begin connection protection, the TLS Record Protocol
- requires specification of a suite of algorithms, a master secret, and
- the client and server random values. The authentication, encryption,
- and MAC algorithms are determined by the cipher_suite selected by the
- server and revealed in the server hello message. The compression
- algorithm is negotiated in the hello messages, and the random values
- are exchanged in the hello messages. All that remains is to calculate
- the master secret.
-
-
-
-Dierks & Rescorla Standards Track [Page 52]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-8.1. Computing the master secret
-
- For all key exchange methods, the same algorithm is used to convert
- the pre_master_secret into the master_secret. The pre_master_secret
- should be deleted from memory once the master_secret has been
- computed.
-
- master_secret = PRF(pre_master_secret, "master secret",
- ClientHello.random + ServerHello.random)
- [0..47];
-
- The master secret is always exactly 48 bytes in length. The length of
- the premaster secret will vary depending on key exchange method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 53]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-8.1.1. RSA
-
- When RSA is used for server authentication and key exchange, a
- 48-byte pre_master_secret is generated by the client, encrypted under
- the server's public key, and sent to the server. The server uses its
- private key to decrypt the pre_master_secret. Both parties then
- convert the pre_master_secret into the master_secret, as specified
- above.
-
- RSA digital signatures are performed using PKCS #1 [PKCS1] block type
- 1. RSA public key encryption is performed using PKCS #1 block type 2.
-
-8.1.2. Diffie-Hellman
-
- A conventional Diffie-Hellman computation is performed. The
- negotiated key (Z) is used as the pre_master_secret, and is converted
- into the master_secret, as specified above. Leading 0 bytes of Z are |
- stripped before it is used as the pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server, and may
- be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
- In the absence of an application profile standard specifying
- otherwise, a TLS compliant application MUST implement the cipher |
- suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. |
-
- The 40-bit cipher suites are known to be susceptible to exhaustive |
- search attack by commercial attackers. Implementations of this |
- document SHOULD disable them by default if they are supported at all. |
- A future version of this document may remove them entirely.
-
-10. Application data protocol
-
- Application data messages are carried by the Record Layer and are
- fragmented, compressed and encrypted based on the current connection
- state. The messages are treated as transparent data to the record
- layer.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 54]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-A. Protocol constant values
-
- This section describes protocol types and constants.
-
-A.1. Record layer
-
- struct {
- uint8 major, minor;
- } ProtocolVersion;
-
- ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */ |
-
- enum {
- change_cipher_spec(20), alert(21), handshake(22),
- application_data(23), (255)
- } ContentType;
-
- struct {
- ContentType type;
- ProtocolVersion version;
- uint16 length;
- opaque fragment[TLSPlaintext.length];
- } TLSPlaintext;
-
- struct {
- ContentType type;
- ProtocolVersion version;
- uint16 length;
- opaque fragment[TLSCompressed.length];
- } TLSCompressed;
-
- struct {
- ContentType type;
- ProtocolVersion version;
- uint16 length;
- select (CipherSpec.cipher_type) {
- case stream: GenericStreamCipher;
- case block: GenericBlockCipher;
- } fragment;
- } TLSCiphertext;
-
- stream-ciphered struct {
- opaque content[TLSCompressed.length];
- opaque MAC[CipherSpec.hash_size];
- } GenericStreamCipher;
-
- block-ciphered struct {
- opaque IV[CipherSpec.block_length]; |
-
-
-
-Dierks & Rescorla Standards Track [Page 55]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- opaque content[TLSCompressed.length];
- opaque MAC[CipherSpec.hash_size];
- uint8 padding[GenericBlockCipher.padding_length];
- uint8 padding_length;
- } GenericBlockCipher;
-
-A.2. Change cipher specs message
-
- struct {
- enum { change_cipher_spec(1), (255) } type;
- } ChangeCipherSpec;
-
-A.3. Alert messages
-
- enum { warning(1), fatal(2), (255) } AlertLevel;
-
- enum {
- close_notify(0),
- unexpected_message(10),
- bad_record_mac(20),
- decryption_failed(21),
- record_overflow(22),
- decompression_failure(30),
- handshake_failure(40),
- no_certificate_RESERVED (41), |
- bad_certificate(42),
- unsupported_certificate(43),
- certificate_revoked(44),
- certificate_expired(45),
- certificate_unknown(46),
- illegal_parameter(47),
- unknown_ca(48),
- access_denied(49),
- decode_error(50),
- decrypt_error(51),
- export_restriction(60),
- protocol_version(70),
- insufficient_security(71),
- internal_error(80),
- user_canceled(90),
- no_renegotiation(100),
- (255)
- } AlertDescription;
-
- struct {
- AlertLevel level;
- AlertDescription description;
- } Alert;
-
-
-
-Dierks & Rescorla Standards Track [Page 56]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-A.4. Handshake protocol
-
- enum {
- hello_request(0), client_hello(1), server_hello(2),
- certificate(11), server_key_exchange (12),
- certificate_request(13), server_hello_done(14),
- certificate_verify(15), client_key_exchange(16),
- finished(20), (255)
- } HandshakeType;
-
- struct {
- HandshakeType msg_type;
- uint24 length;
- select (HandshakeType) {
- case hello_request: HelloRequest;
- case client_hello: ClientHello;
- case server_hello: ServerHello;
- case certificate: Certificate;
- case server_key_exchange: ServerKeyExchange;
- case certificate_request: CertificateRequest;
- case server_hello_done: ServerHelloDone;
- case certificate_verify: CertificateVerify;
- case client_key_exchange: ClientKeyExchange;
- case finished: Finished;
- } body;
- } Handshake;
-
-A.4.1. Hello messages
-
- struct { } HelloRequest;
-
- struct {
- uint32 gmt_unix_time;
- opaque random_bytes[28];
- } Random;
-
- opaque SessionID<0..32>;
-
- uint8 CipherSuite[2];
-
- enum { null(0), (255) } CompressionMethod;
-
- struct {
- ProtocolVersion client_version;
- Random random;
- SessionID session_id;
- CipherSuite cipher_suites<2..2^16-1>;
- CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Rescorla Standards Track [Page 57]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- } ClientHello;
-
- struct {
- ProtocolVersion server_version;
- Random random;
- SessionID session_id;
- CipherSuite cipher_suite;
- CompressionMethod compression_method;
- } ServerHello;
-
-A.4.2. Server authentication and key exchange messages
-
- opaque ASN.1Cert<2^24-1>;
-
- struct {
- ASN.1Cert certificate_list<0..2^24-1>; |
- } Certificate;
-
- enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
- struct {
- opaque RSA_modulus<1..2^16-1>;
- opaque RSA_exponent<1..2^16-1>;
- } ServerRSAParams;
-
- struct {
- opaque DH_p<1..2^16-1>;
- opaque DH_g<1..2^16-1>;
- opaque DH_Ys<1..2^16-1>;
- } ServerDHParams;
-
- struct {
- select (KeyExchangeAlgorithm) {
- case diffie_hellman:
- ServerDHParams params;
- Signature signed_params;
- case rsa:
- ServerRSAParams params;
- Signature signed_params;
- };
- } ServerKeyExchange;
-
- enum { anonymous, rsa, dsa } SignatureAlgorithm; |
-
- struct { |
- select (KeyExchangeAlgorithm) { |
- case diffie_hellman: |
- ServerDHParams params; |
-
-
-
-Dierks & Rescorla Standards Track [Page 58]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- case rsa: |
- ServerRSAParams params; |
- }; |
- } ServerParams; |
-
- select (SignatureAlgorithm)
- { case anonymous: struct { };
- case rsa:
- digitally-signed struct {
- opaque md5_hash[16];
- opaque sha_hash[20];
- };
- case dsa:
- digitally-signed struct {
- opaque sha_hash[20];
- };
- } Signature;
-
- enum {
- rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
- rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), |
- fortezza_dms_RESERVED(20), |
- (255) |
- } ClientCertificateType;
-
- opaque DistinguishedName<1..2^16-1>;
-
- struct {
- ClientCertificateType certificate_types<1..2^8-1>;
- DistinguishedName certificate_authorities<0..2^16-1>; |
- } CertificateRequest;
-
- struct { } ServerHelloDone;
-
-A.4.3. Client authentication and key exchange messages
-
- struct {
- select (KeyExchangeAlgorithm) {
- case rsa: EncryptedPreMasterSecret;
- case diffie_hellman: DiffieHellmanClientPublicValue;
- } exchange_keys;
- } ClientKeyExchange;
-
- struct {
- ProtocolVersion client_version;
- opaque random[46];
- } PreMasterSecret;
-
-
-
-
-Dierks & Rescorla Standards Track [Page 59]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- struct {
- public-key-encrypted PreMasterSecret pre_master_secret;
- } EncryptedPreMasterSecret;
-
- enum { implicit, explicit } PublicValueEncoding;
-
- struct {
- select (PublicValueEncoding) {
- case implicit: struct {};
- case explicit: opaque DH_Yc<1..2^16-1>;
- } dh_public;
- } ClientDiffieHellmanPublic;
-
- struct {
- Signature signature;
- } CertificateVerify;
-
-A.4.4. Handshake finalization message
-
- struct {
- opaque verify_data[12];
- } Finished;
-
-A.5. The CipherSuite
-
- The following values define the CipherSuite codes used in the client
- hello and server hello messages.
-
- A CipherSuite defines a cipher specification supported in TLS Version |
- 1.1.
-
- TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
- TLS connection during the first handshake on that channel, but must
- not be negotiated, as it provides no more protection than an
- unsecured connection.
-
- CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
-
- The following CipherSuite definitions require that the server provide
- an RSA certificate that can be used for key exchange. The server may
- request either an RSA or a DSS signature-capable certificate in the
- certificate request message.
-
- CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
- CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
- CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
- CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
- CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
-
-
-
-Dierks & Rescorla Standards Track [Page 60]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
- CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
- CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
- CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
- CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
-
- The following CipherSuite definitions are used for server-
- authenticated (and optionally client-authenticated) Diffie-Hellman.
- DH denotes cipher suites in which the server's certificate contains
- the Diffie-Hellman parameters signed by the certificate authority
- (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
- parameters are signed by a DSS or RSA certificate, which has been
- signed by the CA. The signing algorithm used is specified after the
- DH or DHE parameter. The server can request an RSA or DSS signature-
- capable certificate from the client for client authentication or it
- may request a Diffie-Hellman certificate. Any Diffie-Hellman
- certificate provided by the client must use the parameters (group and
- generator) described by the server.
-
- CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
- CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
- CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
- CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
- CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
- CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
- CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
- CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
- CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
- CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
- CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
- CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
-
- The following cipher suites are used for completely anonymous Diffie-
- Hellman communications in which neither party is authenticated. Note
- that this mode is vulnerable to man-in-the-middle attacks and is
- therefore deprecated.
-
- CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
- CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
- 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_3DES_EDE_CBC_SHA = { 0x00,0x1B };
-
- Note: All cipher suites whose first byte is 0xFF are considered
- private and can be used for defining local/experimental
- algorithms. Interoperability of such types is a local matter.
-
- Note: Additional cipher suites can be registered by publishing an RFC
-
-
-
-Dierks & Rescorla Standards Track [Page 61]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- which specifies the cipher suites, including the necessary TLS
- protocol information, including message encoding, premaster
- secret derivation, symmetric encryption and MAC calculation and
- appropriate reference information for the algorithms involved.
- The RFC editor's office may, at its discretion, choose to publish
- specifications for cipher suites which are not completely
- described (e.g., for classified algorithms) if it finds the
- specification to be of technical interest and completely
- specified.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
- reserved to avoid collision with Fortezza-based cipher suites in
- SSL 3.
-
-A.6. The Security Parameters
-
- These security parameters are determined by the TLS Handshake
- Protocol and provided as parameters to the TLS Record Layer in order
- to initialize a connection state. SecurityParameters includes:
-
- enum { null(0), (255) } CompressionMethod;
-
- enum { server, client } ConnectionEnd;
-
- enum { null, rc4, rc2, des, 3des, des40, idea }
- BulkCipherAlgorithm;
-
- enum { stream, block } CipherType;
-
- enum { true, false } IsExportable;
-
- enum { null, md5, sha } MACAlgorithm;
-
- /* 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];
-
-
-
-Dierks & Rescorla Standards Track [Page 62]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- opaque server_random[32];
- } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 63]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-B. Glossary
-
- application protocol
- An application protocol is a protocol that normally layers
- directly on top of the transport layer (e.g., TCP/IP). Examples
- include HTTP, TELNET, FTP, and SMTP.
-
- asymmetric cipher
- See public key cryptography.
-
- authentication
- Authentication is the ability of one entity to determine the
- identity of another entity.
-
- block cipher
- A block cipher is an algorithm that operates on plaintext in
- groups of bits, called blocks. 64 bits is a common block size.
-
- bulk cipher
- A symmetric encryption algorithm used to encrypt large quantities
- of data.
-
- cipher block chaining (CBC)
- CBC is a mode in which every plaintext block encrypted with a
- block cipher is first exclusive-ORed with the previous ciphertext
- block (or, in the case of the first block, with the
- initialization vector). For decryption, every block is first
- decrypted, then exclusive-ORed with the previous ciphertext block
- (or IV).
-
- certificate
- As part of the X.509 protocol (a.k.a. ISO Authentication
- framework), certificates are assigned by a trusted Certificate
- Authority and provide a strong binding between a party's identity
- or some other attributes and its public key.
-
- client
- The application entity that initiates a TLS connection to a
- server. This may or may not imply that the client initiated the
- underlying transport connection. The primary operational
- difference between the server and client is that the server is
- generally authenticated, while the client is only optionally
- authenticated.
-
- client write key
- The key used to encrypt data written by the client.
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 64]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- client write MAC secret
- The secret data used to authenticate data written by the client.
-
- connection
- A connection is a transport (in the OSI layering model
- definition) that provides a suitable type of service. For TLS,
- such connections are peer to peer relationships. The connections
- are transient. Every connection is associated with one session.
-
- Data Encryption Standard
- DES is a very widely used symmetric encryption algorithm. DES is
- a block cipher with a 56 bit key and an 8 byte block size. Note
- that in TLS, for key generation purposes, DES is treated as
- having an 8 byte key length (64 bits), but it still only provides
- 56 bits of protection. (The low bit of each key byte is presumed
- to be set to produce odd parity in that key byte.) DES can also
- be operated in a mode where three independent keys and three
- encryptions are used for each block of data; this uses 168 bits
- of key (24 bytes in the TLS key generation method) and provides
- the equivalent of 112 bits of security. [DES], [3DES]
-
- Digital Signature Standard (DSS)
- A standard for digital signing, including the Digital Signing
- Algorithm, approved by the National Institute of Standards and
- Technology, defined in NIST FIPS PUB 186, "Digital Signature
- Standard," published May, 1994 by the U.S. Dept. of Commerce.
- [DSS]
-
- digital signatures |
- Digital signatures utilize public key cryptography and one-way
- hash functions to produce a signature of the data that can be
- authenticated, and is difficult to forge or repudiate.
-
- handshake
- An initial negotiation between client and server that establishes
- the parameters of their transactions.
-
- Initialization Vector (IV)
- When a block cipher is used in CBC mode, the initialization
- vector is exclusive-ORed with the first plaintext block prior to
- encryption.
-
- IDEA
- A 64-bit block cipher designed by Xuejia Lai and James Massey.
- [IDEA]
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 65]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- Message Authentication Code (MAC)
- A Message Authentication Code is a one-way hash computed from a
- message and some secret data. It is difficult to forge without
- knowing the secret data. Its purpose is to detect if the message
- has been altered.
-
- master secret
- Secure secret data used for generating encryption keys, MAC
- secrets, and IVs.
-
- MD5
- MD5 is a secure hashing function that converts an arbitrarily
- long data stream into a digest of fixed size (16 bytes). [MD5]
-
- public key cryptography
- A class of cryptographic techniques employing two-key ciphers.
- Messages encrypted with the public key can only be decrypted with
- the associated private key. Conversely, messages signed with the
- private key can be verified with the public key.
-
- one-way hash function
- A one-way transformation that converts an arbitrary amount of
- data into a fixed-length hash. It is computationally hard to
- reverse the transformation or to find collisions. MD5 and SHA are
- examples of one-way hash functions.
-
- RC2
- A block cipher developed by Ron Rivest at RSA Data Security, Inc.
- [RSADSI] described in [RC2].
-
- RC4
- A stream cipher licensed by RSA Data Security [RSADSI]. A
- compatible cipher is described in [RC4].
-
- RSA
- A very widely used public-key algorithm that can be used for
- either encryption or digital signing. [RSA]
-
- salt
- Non-secret random data used to make export encryption keys resist
- precomputation attacks.
-
- server
- The server is the application entity that responds to requests
- for connections from clients. See also under client.
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 66]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- session
- A TLS session is an association between a client and a server.
- Sessions are created by the handshake protocol. Sessions define a
- set of cryptographic security parameters, which can be shared
- among multiple connections. Sessions are used to avoid the
- expensive negotiation of new security parameters for each
- connection.
-
- session identifier
- A session identifier is a value generated by a server that
- identifies a particular session.
-
- server write key
- The key used to encrypt data written by the server.
-
- server write MAC secret
- The secret data used to authenticate data written by the server.
-
- SHA
- The Secure Hash Algorithm is defined in FIPS PUB 180-1. It
- produces a 20-byte output. Note that all references to SHA
- actually use the modified SHA-1 algorithm. [SHA]
-
- SSL
- Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
- SSL Version 3.0
-
- stream cipher
- An encryption algorithm that converts a key into a
- cryptographically-strong keystream, which is then exclusive-ORed
- with the plaintext.
-
- symmetric cipher |
- See bulk cipher.
-
- Transport Layer Security (TLS)
- This protocol; also, the Transport Layer Security working group
- of the Internet Engineering Task Force (IETF). See "Comments" at
- the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 67]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-C. CipherSuite definitions
-
-CipherSuite Is Key Cipher Hash
- Exportable Exchange
-
-TLS_NULL_WITH_NULL_NULL * NULL NULL NULL
-TLS_RSA_WITH_NULL_MD5 * RSA NULL MD5
-TLS_RSA_WITH_NULL_SHA * RSA NULL SHA
-TLS_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5
-TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
-TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
-TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5
-TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
-TLS_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA
-TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
-TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
-TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
-TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
-TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
-TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5
-TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
-TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA
-TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
-
-
- * Indicates IsExportable is True
-
- Key
- Exchange
- Algorithm Description Key size limit
-
- DHE_DSS Ephemeral DH with DSS signatures None
- DHE_DSS_EXPORT Ephemeral DH with DSS signatures DH = 512 bits
- DHE_RSA Ephemeral DH with RSA signatures None
- DHE_RSA_EXPORT Ephemeral DH with RSA signatures DH = 512 bits,
- RSA = none
- DH_anon Anonymous DH, no signatures None
- DH_anon_EXPORT Anonymous DH, no signatures DH = 512 bits
-
-
-
-Dierks & Rescorla Standards Track [Page 68]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- DH_DSS DH with DSS-based certificates None
- DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits
- DH_RSA DH with RSA-based certificates None
- DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits,
- RSA = none
- NULL No key exchange N/A
- RSA RSA key exchange None
- RSA_EXPORT RSA key exchange RSA = 512 bits
-
- Key size limit
- The key size limit gives the size of the largest public key that
- can be legally used for encryption or key agreement in |
- cipher suites that are exportable. |
-
- Key Expanded Effective IV Block
- Cipher Type Material Key Material Key Bits Size Size
-
- NULL * Stream 0 0 0 0 N/A
- IDEA_CBC Block 16 16 128 8 8
- RC2_CBC_40 * Block 5 16 40 8 8
- RC4_40 * Stream 5 16 40 0 N/A
- RC4_128 Stream 16 16 128 0 N/A
- DES40_CBC * Block 5 8 40 8 8
- DES_CBC Block 8 8 56 8 8
- 3DES_EDE_CBC Block 24 24 168 8 8
-
- * Indicates IsExportable is true.
-
- Type
- Indicates whether this is a stream cipher or a block cipher
- running in CBC mode.
-
- Key Material
- The number of bytes from the key_block that are used for
- generating the write keys.
-
- Expanded Key Material
- The number of bytes actually fed into the encryption algorithm
-
- Effective Key Bits
- How much entropy material is in the key material being fed into
- the encryption routines.
-
- IV Size
- How much data needs to be generated for the initialization
- vector. Zero for stream ciphers; equal to the block size for
- block ciphers.
-
-
-
-
-Dierks & Rescorla Standards Track [Page 69]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- Block Size
- The amount of data a block cipher enciphers in one chunk; a
- block cipher running in CBC mode can only encrypt an even
- multiple of its block size.
-
- Hash Hash Padding
- function Size Size
- NULL 0 0
- MD5 16 48
- SHA 20 40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 70]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-D. Implementation Notes
-
- The TLS protocol cannot prevent many common security mistakes. This
- section provides several recommendations to assist implementors.
-
-D.1. Temporary RSA keys
-
- US Export restrictions limit RSA keys used for encryption to 512
- bits, but do not place any limit on lengths of RSA keys used for
- signing operations. Certificates often need to be larger than 512
- bits, since 512-bit RSA keys are not secure enough for high-value
- transactions or for applications requiring long-term security. Some
- certificates are also designated signing-only, in which case they
- cannot be used for key exchange.
-
- When the public key in the certificate cannot be used for encryption,
- the server signs a temporary RSA key, which is then exchanged. In
- exportable applications, the temporary RSA key should be the maximum
- allowable length (i.e., 512 bits). Because 512-bit RSA keys are
- relatively insecure, they should be changed often. For typical
- electronic commerce applications, it is suggested that keys be
- changed daily or every 500 transactions, and more often if possible.
- Note that while it is acceptable to use the same temporary key for
- multiple transactions, it must be signed each time it is used.
-
- RSA key generation is a time-consuming process. In many cases, a low-
- priority process can be assigned the task of key generation.
-
- Whenever a new key is completed, the existing temporary key can be
- replaced with the new one.
-
-D.2. Random Number Generation and Seeding
-
- TLS requires a cryptographically-secure pseudorandom number generator
- (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
- based on secure hash operations, most notably MD5 and/or SHA, are
- acceptable, but cannot provide more security than the size of the
- random number generator state. (For example, MD5-based PRNGs usually
- provide 128 bits of state.)
-
- To estimate the amount of seed material being produced, add the
- number of bits of unpredictable information in each seed byte. For
- example, keystroke timing values taken from a PC compatible's 18.2 Hz
- timer provide 1 or 2 secure bits each, even though the total size of
- the counter value is 16 bits or more. To seed a 128-bit PRNG, one
- would thus require approximately 100 such timer values.
-
-D.3. Certificates and authentication
-
-
-
-Dierks & Rescorla Standards Track [Page 71]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- Implementations are responsible for verifying the integrity of
- certificates and should generally support certificate revocation
- messages. Certificates should always be verified to ensure proper
- signing by a trusted Certificate Authority (CA). The selection and
- addition of trusted CAs should be done very carefully. Users should
- be able to view information about the certificate and root CA.
-
-D.4. CipherSuites
-
- TLS supports a range of key sizes and security levels, including some
- which provide no or minimal security. A proper implementation will
- probably not support many cipher suites. For example, 40-bit
- encryption is easily broken, so implementations requiring strong
- security should not allow 40-bit keys. Similarly, anonymous Diffie-
- Hellman is strongly discouraged because it cannot prevent man-in-the-
- middle attacks. Applications should also enforce minimum and maximum
- key sizes. For example, certificate chains containing 512-bit RSA
- keys or signatures are not appropriate for high-security
- applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 72]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-E. Backward Compatibility With SSL
-
- For historical reasons and in order to avoid a profligate consumption
- of reserved port numbers, application protocols which are secured by |
- TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
- connection port: for example, the https protocol (HTTP secured by SSL
- or TLS) uses port 443 regardless of which security protocol it is
- using. Thus, some mechanism must be determined to distinguish and
- negotiate among the various protocols.
-
- TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting |
- both is easy. TLS clients who wish to negotiate with such older |
- servers SHOULD send client hello messages using the SSL 3.0 record |
- format and client hello structure, sending {3, 2} for the version |
- field to note that they support TLS 1.1. If the server supports only |
- TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello; |
- if it supports TLS 1.1 it will respond with a TLS 1.1 server hello. |
- The negotiation then proceeds as appropriate for the negotiated
- protocol.
-
- Similarly, a TLS 1.1 server which wishes to interoperate with TLS |
- 1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages |
- and respond with a SSL 3.0 server hello if an SSL 3.0 client hello |
- with a version field of {3, 0} is received, denoting that this client |
- does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a |
- version field of {3, 1} is received, the server SHOULD respond with a |
- TLS 1.0 hello with a version field of {3, 1}.
-
- Whenever a client already knows the highest protocol known to a |
- server (for example, when resuming a session), it SHOULD initiate the
- connection in that native protocol.
-
- TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL |
- Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
- either client hello format if they wish to support SSL 2.0 clients on
- the same connection port. The only deviations from the Version 2.0
- specification are the ability to specify a version with a value of
- three and the support for more ciphering types in the CipherSpec.
-
- Warning: The ability to send Version 2.0 client hello messages will be
- phased out with all due haste. Implementors SHOULD make every |
- effort to move forward as quickly as possible. Version 3.0
- provides better mechanisms for moving to newer versions.
-
- The following cipher specifications are carryovers from SSL Version
- 2.0. These are assumed to use RSA for key exchange and
- authentication.
-
-
-
-
-Dierks & Rescorla Standards Track [Page 73]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
- V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
- V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
- V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
- = { 0x04,0x00,0x80 };
- V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
- V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
- V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
- Cipher specifications native to TLS can be included in Version 2.0
- client hello messages using the syntax below. Any V2CipherSpec
- element with its first byte equal to zero will be ignored by Version |
- 2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
- also include the TLS equivalent (see Appendix A.5):
-
- V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
-
-E.1. Version 2 client hello
-
- The Version 2.0 client hello message is presented below using this
- document's presentation model. The true definition is still assumed |
- to be the SSL Version 2.0 specification. Note that this message MUST |
- be sent directly on the wire, not wrapped as an SSLv3 record
-
- uint8 V2CipherSpec[3];
-
- struct {
- uint16 msg_length; |
- uint8 msg_type;
- Version version;
- uint16 cipher_spec_length;
- uint16 session_id_length;
- uint16 challenge_length;
- V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
- opaque session_id[V2ClientHello.session_id_length];
- opaque challenge[V2ClientHello.challenge_length; |
- } V2ClientHello;
-
- msg_length |
- This field is the length of the following data in bytes. The high |
- bit MUST be 1 and is not part of the length. |
-
- msg_type
- This field, in conjunction with the version field, identifies a |
- version 2 client hello message. The value SHOULD be one (1).
-
- version
- The highest version of the protocol supported by the client
-
-
-
-Dierks & Rescorla Standards Track [Page 74]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- (equals ProtocolVersion.version, see Appendix A.1).
-
- cipher_spec_length
- This field is the total length of the field cipher_specs. It |
- cannot be zero and MUST be a multiple of the V2CipherSpec length
- (3).
-
- session_id_length
- This field MUST have a value of zero. |
-
- challenge_length
- The length in bytes of the client's challenge to the server to |
- authenticate itself. When using the SSLv2 backward compatible |
- handshake the client MUST use a 32-byte challenge.
-
- cipher_specs
- This is a list of all CipherSpecs the client is willing and able |
- to use. There MUST be at least one CipherSpec acceptable to the
- server.
-
- session_id
- This field MUST be empty. |
-
- challenge
- The client challenge to the server for the server to identify
- itself is a (nearly) arbitrary length random. The TLS server will
- right justify the challenge data to become the ClientHello.random
- data (padded with leading zeroes, if necessary), as specified in
- this protocol specification. If the length of the challenge is
- greater than 32 bytes, only the last 32 bytes are used. It is
- legitimate (but not necessary) for a V3 server to reject a V2
- ClientHello that has fewer than 16 bytes of challenge data.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello. |
-
-E.2. Avoiding man-in-the-middle version rollback
-
- When TLS clients fall back to Version 2.0 compatibility mode, they |
- SHOULD use special PKCS #1 block formatting. This is done so that TLS
- servers will reject Version 2.0 sessions with TLS-capable clients.
-
- When TLS clients are in Version 2.0 compatibility mode, they set the
- right-hand (least-significant) 8 random bytes of the PKCS padding
- (not including the terminal null of the padding) for the RSA
- encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
- to 0x03 (the other padding bytes are random). After decrypting the |
- ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
- error if these eight padding bytes are 0x03. Version 2.0 servers
-
-
-
-Dierks & Rescorla Standards Track [Page 75]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- receiving blocks padded in this manner will proceed normally.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 76]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-F. Security analysis
-
- The TLS protocol is designed to establish a secure connection between
- a client and a server communicating over an insecure channel. This
- document makes several traditional assumptions, including that
- attackers have substantial computational resources and cannot obtain
- secret information from sources outside the protocol. Attackers are
- assumed to have the ability to capture, modify, delete, replay, and
- otherwise tamper with messages sent over the communication channel.
- This appendix outlines how TLS has been designed to resist a variety
- of attacks.
-
-F.1. Handshake protocol
-
- The handshake protocol is responsible for selecting a CipherSpec and
- generating a Master Secret, which together comprise the primary
- cryptographic parameters associated with a secure session. The
- handshake protocol can also optionally authenticate parties who have
- certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and key exchange
-
- TLS supports three authentication modes: authentication of both
- parties, server authentication with an unauthenticated client, and
- total anonymity. Whenever the server is authenticated, the channel is
- secure against man-in-the-middle attacks, but completely anonymous
- sessions are inherently vulnerable to such attacks. Anonymous
- servers cannot authenticate clients. If the server is authenticated,
- its certificate message must provide a valid certificate chain
- leading to an acceptable certificate authority. Similarly,
- authenticated clients must supply an acceptable certificate to the
- server. Each party is responsible for verifying that the other's
- certificate is valid and has not expired or been revoked.
-
- The general goal of the key exchange process is to create a
- pre_master_secret known to the communicating parties and not to
- attackers. The pre_master_secret will be used to generate the
- master_secret (see Section 8.1). The master_secret is required to |
- generate the finished messages, encryption keys, and MAC secrets (see
- Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished
- message, parties thus prove that they know the correct
- pre_master_secret.
-
-F.1.1.1. Anonymous key exchange
-
- Completely anonymous sessions can be established using RSA or Diffie-
- Hellman for key exchange. With anonymous RSA, the client encrypts a
- pre_master_secret with the server's uncertified public key extracted
-
-
-
-Dierks & Rescorla Standards Track [Page 77]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- from the server key exchange message. The result is sent in a client
- key exchange message. Since eavesdroppers do not know the server's
- private key, it will be infeasible for them to decode the |
- pre_master_secret. |
-
- Note: No anonymous RSA Cipher Suites are defined in this document.
-
- With Diffie-Hellman, the server's public parameters are contained in
- the server key exchange message and the client's are sent in the
- client key exchange message. Eavesdroppers who do not know the
- private values should not be able to find the Diffie-Hellman result
- (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
- against passive eavesdropping. Unless an independent tamper-
- proof channel is used to verify that the finished messages
- were not replaced by an attacker, server authentication is
- required in environments where active man-in-the-middle
- attacks are a concern.
-
-F.1.1.2. RSA key exchange and authentication
-
- With RSA, key exchange and server authentication are combined. The
- public key may be either contained in the server's certificate or may
- be a temporary RSA key sent in a server key exchange message. When
- temporary RSA keys are used, they are signed by the server's RSA |
- certificate. The signature includes the current ClientHello.random,
- so old signatures and temporary keys cannot be replayed. Servers may
- use a single temporary RSA key for multiple negotiation sessions.
-
- Note: The temporary RSA key option is useful if servers need large
- certificates but must comply with government-imposed size limits
- on keys used for key exchange.
-
- Note that if ephemeral RSA is not used, compromise of the server's |
- static RSA key results in a loss of confidentiality for all sessions |
- protected under that static key. TLS users desiring Perfect Forward |
- Secrecy should use DHE cipher suites. The damage done by exposure of |
- a private key can be limited by changing one's private key (and |
- certificate) frequently. |
-
- After verifying the server's certificate, the client encrypts a
- pre_master_secret with the server's public key. By successfully
- decoding the pre_master_secret and producing a correct finished
- message, the server demonstrates that it knows the private key
- corresponding to the server certificate.
-
- When RSA is used for key exchange, clients are authenticated using
-
-
-
-Dierks & Rescorla Standards Track [Page 78]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- the certificate verify message (see Section 7.4.8). The client signs
- a value derived from the master_secret and all preceding handshake
- messages. These handshake messages include the server certificate,
- which binds the signature to the server, and ServerHello.random,
- which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman key exchange with authentication
-
- When Diffie-Hellman key exchange is used, the server can either
- supply a certificate containing fixed Diffie-Hellman parameters or
- can use the server key exchange message to send a set of temporary
- Diffie-Hellman parameters signed with a DSS or RSA certificate.
- Temporary parameters are hashed with the hello.random values before
- signing to ensure that attackers do not replay old parameters. In
- either case, the client can verify the certificate or signature to
- ensure that the parameters belong to the server.
-
- If the client has a certificate containing fixed Diffie-Hellman
- parameters, its certificate contains the information required to
- complete the key exchange. Note that in this case the client and
- server will generate the same Diffie-Hellman result (i.e.,
- pre_master_secret) every time they communicate. To prevent the
- pre_master_secret from staying in memory any longer than necessary,
- it should be converted into the master_secret as soon as possible.
- Client Diffie-Hellman parameters must be compatible with those
- supplied by the server for the key exchange to work.
-
- If the client has a standard DSS or RSA certificate or is
- unauthenticated, it sends a set of temporary parameters to the server
- in the client key exchange message, then optionally uses a
- certificate verify message to authenticate itself.
-
- If the same DH keypair is to be used for multiple handshakes, either |
- because the client or server has a certificate containing a fixed DH |
- keypair or because the server is reusing DH keys, care must be taken |
- to prevent small subgroup attacks. Implementations SHOULD follow the |
- guidelines found in [SUBGROUP]. |
-
- Small subgroup attacks are most easily avoided by using one of the |
- DHE ciphersuites and generating a fresh DH private key (X) for each |
- handshake. If a suitable base (such as 2) is chosen, g^X mod p can be |
- computed very quickly so the performance cost is minimized. |
- Additionally, using a fresh key for each handshake provides Perfect |
- Forward Secrecy. Implementations SHOULD generate a new X for each |
- handshake when using DHE ciphersuites. |
-
-F.1.2. Version rollback attacks
-
-
-
-
-Dierks & Rescorla Standards Track [Page 79]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- Because TLS includes substantial improvements over SSL Version 2.0,
- attackers may try to make TLS-capable clients and servers fall back
- to Version 2.0. This attack can occur if (and only if) two TLS-
- capable parties use an SSL 2.0 handshake.
-
- Although the solution using non-random PKCS #1 block type 2 message
- padding is inelegant, it provides a reasonably secure way for Version
- 3.0 servers to detect the attack. This solution is not secure against
- attackers who can brute force the key and substitute a new ENCRYPTED-
- KEY-DATA message containing the same key (but with normal padding)
- before the application specified wait threshold has expired. Parties
- concerned about attacks of this scale should not be using 40-bit
- encryption keys anyway. Altering the padding of the least-significant
- 8 bytes of the PKCS padding does not impact security for the size of
- the signed hashes and RSA key lengths used in the protocol, since
- this is essentially equivalent to increasing the input block size by
- 8 bytes.
-
-F.1.3. Detecting attacks against the handshake protocol
-
- An attacker might try to influence the handshake exchange to make the
- parties select different encryption algorithms than they would |
- normally chooses. Because many implementations will support 40-bit
- exportable encryption and some may even support null encryption or
- MAC algorithms, this attack is of particular concern.
-
- For this attack, an attacker must actively change one or more
- handshake messages. If this occurs, the client and server will
- compute different values for the handshake message hashes. As a
- result, the parties will not accept each others' finished messages.
- Without the master_secret, the attacker cannot repair the finished
- messages, so the attack will be discovered.
-
-F.1.4. Resuming sessions
-
- When a connection is established by resuming a session, new
- ClientHello.random and ServerHello.random values are hashed with the
- session's master_secret. Provided that the master_secret has not been
- compromised and that the secure hash operations used to produce the
- encryption keys and MAC secrets are secure, the connection should be
- secure and effectively independent from previous connections.
- Attackers cannot use known encryption keys or MAC secrets to
- compromise the master_secret without breaking the secure hash
- operations (which use both SHA and MD5).
-
- Sessions cannot be resumed unless both the client and server agree.
- If either party suspects that the session may have been compromised,
- or that certificates may have expired or been revoked, it should
-
-
-
-Dierks & Rescorla Standards Track [Page 80]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- force a full handshake. An upper limit of 24 hours is suggested for
- session ID lifetimes, since an attacker who obtains a master_secret
- may be able to impersonate the compromised party until the
- corresponding session ID is retired. Applications that may be run in
- relatively insecure environments should not write session IDs to
- stable storage.
-
-F.1.5. MD5 and SHA
-
- TLS uses hash functions very conservatively. Where possible, both MD5
- and SHA are used in tandem to ensure that non-catastrophic flaws in
- one algorithm will not break the overall protocol.
-
-F.2. Protecting application data
-
- The master_secret is hashed with the ClientHello.random and
- ServerHello.random to produce unique data encryption keys and MAC
- secrets for each connection.
-
- Outgoing data is protected with a MAC before transmission. To prevent
- message replay or modification attacks, the MAC is computed from the
- MAC secret, the sequence number, the message length, the message
- contents, and two fixed character strings. The message type field is
- necessary to ensure that messages intended for one TLS Record Layer
- client are not redirected to another. The sequence number ensures
- that attempts to delete or reorder messages will be detected. Since
- sequence numbers are 64-bits long, they should never overflow.
- Messages from one party cannot be inserted into the other's output,
- since they use independent MAC secrets. Similarly, the server-write
- and client-write keys are independent so stream cipher keys are used
- only once.
-
- If an attacker does break an encryption key, all messages encrypted
- with it can be read. Similarly, compromise of a MAC key can make
- message modification attacks possible. Because MACs are also
- encrypted, message-alteration attacks generally require breaking the
- encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
- remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs |
-
- [CBCATT] describes a chosen plaintext attack on TLS that depends |
- on knowing the IV for a record. Previous versions of TLS [TLS1.0] |
- used the CBC residue of the previous record as the IV and |
- therefore enabled this attack. This version uses an explicit IV |
- in order to protect against this attack. |
-
-
-
-Dierks & Rescorla Standards Track [Page 81]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-F.4 Security of Composite Cipher Modes |
-
- TLS secures transmitted application data via the use of symmetric |
- encryption and authentication functions defined in the negotiated |
- ciphersuite. The objective is to protect both the integrity and |
- confidentiality of the transmitted data from malicious actions by |
- active attackers in the network. It turns out that the order in |
- which encryption and authentication functions are applied to the |
- data plays an important role for achieving this goal [ENCAUTH]. |
-
- The most robust method, called encrypt-then-authenticate, first |
- applies encryption to the data and then applies a MAC to the |
- ciphertext. This method ensures that the integrity and |
- confidentiality goals are obtained with ANY pair of encryption |
- and MAC functions provided that the former is secure against |
- chosen plaintext attacks and the MAC is secure against chosen- |
- message attacks. TLS uses another method, called authenticate- |
- then-encrypt, in which first a MAC is computed on the plaintext |
- and then the concatenation of plaintext and MAC is encrypted. |
- This method has been proven secure for CERTAIN combinations of |
- encryption functions and MAC functions, but is not guaranteed to |
- be secure in general. In particular, it has been shown that there |
- exist perfectly secure encryption functions (secure even in the |
- information theoretic sense) that combined with any secure MAC |
- function fail to provide the confidentiality goal against an |
- active attack. Therefore, new ciphersuites and operation modes |
- adopted into TLS need to be analyzed under the authenticate-then- |
- encrypt method to verify that they achieve the stated integrity |
- and confidentiality goals. |
-
- Currently, the security of the authenticate-then-encrypt method |
- has been proven for some important cases. One is the case of |
- stream ciphers in which a computationally unpredictable pad of |
- the length of the message plus the length of the MAC tag is |
- produced using a pseudo-random generator and this pad is xor-ed |
- with the concatenation of plaintext and MAC tag. The other is |
- the case of CBC mode using a secure block cipher. In this case, |
- security can be shown if one applies one CBC encryption pass to |
- the concatenation of plaintext and MAC and uses a new, |
- independent and unpredictable, IV for each new pair of plaintext |
- and MAC. In previous versions of SSL, CBC mode was used properly |
- EXCEPT that it used a predictable IV in the form of the last |
- block of the previous ciphertext. This made TLS open to chosen |
- plaintext attacks. This verson of the protocol is immune to |
- those attacks. For exact details in the encryption modes proven |
- secure see [ENCAUTH]. |
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 82]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-F.5 Denial of Service |
-
- TLS is susceptible to a number of denial of service (DoS) |
- attacks. In particular, an attacker who initiates a large number |
- of TCP connections can cause a server to consume large amounts of |
- CPU doing RSA decryption. However, because TLS is generally used |
- over TCP, it is difficult for the attacker to hide his point of |
- origin if proper TCP SYN randomization is used [SEQNUM] by the |
- TCP stack. |
-
- Because TLS runs over TCP, it is also susceptible to a number of |
- denial of service attacks on individual connections. In |
- particular, attackers can forge RSTs, terminating connections, or |
- forge partial TLS records, causing the connection to stall. |
- These attacks cannot in general be defended against by a TCP- |
- using protocol. Implementors or users who are concerned with this |
- class of attack should use IPsec AH [AH] or ESP [ESP]. |
-
-F.6. Final notes
-
- For TLS to be able to provide a secure connection, both the client
- and server systems, keys, and applications must be secure. In
- addition, the implementation must be free of security errors.
-
- The system is only as strong as the weakest key exchange and
- authentication algorithm supported, and only trustworthy
- cryptographic functions should be used. Short public keys, 40-bit
- bulk encryption keys, and anonymous servers should be used with great
- caution. Implementations and users must be careful when deciding
- which certificates and certificate authorities are acceptable; a
- dishonest certificate authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 83]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-G. Patent Statement
-
- Netscape Communications Corporation (now America Online) has a patent |
- claim on the Secure Sockets Layer (SSL) work that this standard is |
- based on. The Internet Standards Process as defined in RFC 2026 |
- requests that a statement be obtained from a Patent holder indicating |
- that a license will be made available to applicants under reasonable |
- terms and conditions.
-
- Secure Socket Layer Application Program Apparatus And Method
- ("SSL"), No. 5,657,390
-
- Netscape Communications has issued the following statement:
-
- Intellectual Property Rights
-
- Secure Sockets Layer
-
- The United States Patent and Trademark Office ("the PTO")
- recently issued U.S. Patent No. 5,657,390 ("the SSL Patent") to
- Netscape for inventions described as Secure Sockets Layers
- ("SSL"). The IETF is currently considering adopting SSL as a
- transport protocol with security features. Netscape encourages
- the royalty-free adoption and use of the SSL protocol upon the
- following terms and conditions:
-
- * If you already have a valid SSL Ref license today which
- includes source code from Netscape, an additional patent
- license under the SSL patent is not required.
-
- * If you don't have an SSL Ref license, you may have a royalty
- free license to build implementations covered by the SSL
- Patent Claims or the IETF TLS specification provided that you
- do not to assert any patent rights against Netscape or other
- companies for the implementation of SSL or the IETF TLS
- recommendation.
-
- What are "Patent Claims":
-
- Patent claims are claims in an issued foreign or domestic patent
- that:
-
- 1) must be infringed in order to implement methods or build
- products according to the IETF TLS specification; or
-
- 2) patent claims which require the elements of the SSL patent
- claims and/or their equivalents to be infringed.
-
-
-
-
-Dierks & Rescorla Standards Track [Page 84]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- The Internet Society, Internet Architecture Board, Internet
- Engineering Steering Group and the Corporation for National Research
- Initiatives take no position on the validity or scope of the patents
- and patent applications, nor on the appropriateness of the terms of
- the assurance. The Internet Society and other groups mentioned above
- have not made any determination as to any other intellectual property
- rights which may apply to the practice of this standard. Any further
- consideration of these matters is the user's own responsibility.
-
-Security Considerations
-
- Security issues are discussed throughout this memo, especially in |
- Appendices D, E, and F.
-
-Normative References |
-
- [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," |
- IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
-
- [DES] ANSI X3.106, "American National Standard for Information
- Systems-Data Link Encryption," American National Standards
- 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
- Institute of Standards and Technology, U.S. Department of
- Commerce, May 18, 1994.
-
- [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication," RFC 2104, February
- 1997.
-
- [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
- Series in Information Processing, v. 1, Konstanz: Hartung-
- Gorre Verlag, 1992.
-
- [MD2] Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,
- April 1992.
-
- [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
- April 1992.
-
- [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
- version 1.5, November 1993.
-
-
-
-
-Dierks & Rescorla Standards Track [Page 85]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
- Standard," version 1.5, November 1993.
-
- [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
- Standard," version 1.5, November 1993.
-
- [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
- Public Key Infrastructure: Part I: X.509 Certificate and CRL
- Profile", RFC 2459, January 1999.
-
- [RC2] Rivest, R., "A Description of the RC2(r) Encryption
- Algorithm", RFC 2268, January 1998.
-
- [RC4] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption
- Algorithm, Work in Progress.
-
- [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
- Obtaining Digital Signatures and Public-Key Cryptosystems,"
- Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
- 120-126.
-
- [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National
- Institute of Standards and Technology, U.S. Department of
- Commerce, Work in Progress, May 31, 1994.
-
- [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
- Corp., Feb 9, 1995.
-
- [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
- Netscape Communications Corp., Nov 18, 1996.
-
- [REQ] Bradner, S., "Key words for use in RFCs to Indicate |
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0", |
- RFC 2246, January 1999.
-
- [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J., |
- Wright, T., "Transport Layer Security (TLS) Extensions", RFC |
- 3546, June 2003.
- [X509] CCITT. Recommendation X.509: "The Directory - Authentication
- Framework". 1988.
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 86]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-Informative References |
-
- [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC |
- 2402, November 1998. |
-
- [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against |
- Protocols Based on RSA Encryption Standard PKCS #1" in |
- Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: |
- 1--12, 1998. |
-
- [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: |
- Problems and Countermeasures", |
- http://www.openssl.org/~bodo/tls-cbc.txt. |
-
- [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel", |
- http://lasecwww.epfl.ch/memo_ssl.shtml, 2003. |
-
- [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication |
- for Protecting Communications (Or: How Secure is SSL?)", |
- Crypto 2001. |
-
- [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security |
- Payload (ESP)", RFC 2406, November 1998. |
-
- [FTP] Postel J., and J. Reynolds, "File Transfer Protocol", STD 9, |
- RFC 959, October 1985. |
-
- [HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext |
- Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |
-
- [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based |
- Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, |
- March 2003. |
- [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 |
-
- [SCH] B. Schneier. Applied Cryptography: Protocols, Algorithms, |
- and Source Code in C, Published by John Wiley & Sons, Inc. |
- 1994. |
-
- [SEQNUM] Bellovim. S., "Defending Against Sequence Number Attacks", |
- RFC 1948, May 1996. |
-
- [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup |
- Attacks on the Diffie-Hellman Key Agreement Method for |
- S/MIME", RFC 2785, March 2000. |
-
- [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, |
- September 1981. |
-
-
-
-Dierks & Rescorla Standards Track [Page 87]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are |
- practical", USENIX Security Symposium 2003. |
-
- [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External
- Data Representation Standard, August 1995.
-
-
-Credits |
-
- Working Group Chair |
- Win Treese
-
- EMail: treese@acm.org |
-
-
- Editors
-
- Tim Dierks Eric Rescorla |
- RTFM, Inc. |
-
- EMail: tim@dierks.org EMail: ekr@rtfm.com |
-
-
-
- Other contributors
-
- Christopher Allen (co-editor of TLS 1.0) |
- Alacrity Ventures |
- ChristopherA@AlacrityVentures.com |
-
- Martin Abadi |
- University of California, Santa Cruz |
- abadi@cs.ucsc.edu |
-
- Ran Canetti |
- IBM |
- canetti@watson.ibm.com |
-
- Taher Elgamal |
- taher@securify.com |
- Securify |
-
- Anil Gangolli |
- Structured Arts |
-
- Kipp Hickman |
-
- Phil Karlton (co-author of SSLv3) |
-
-
-
-Dierks & Rescorla Standards Track [Page 88]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
- Paul Kocher (co-author of SSLv3) |
- Cryptography Research |
- paul@cryptography.com |
-
- Hugo Krawczyk |
- Technion Israel Institute of Technology |
- hugo@ee.technion.ac.il |
-
- Robert Relyea |
- Netscape Communications |
- relyea@netscape.com |
-
- Jim Roskind |
- Netscape Communications |
- jar@netscape.com |
-
- Michael Sabin |
-
- Dan Simon |
- Microsoft, Inc. |
- dansimon@microsoft.com |
-
- Tom Weinstein |
-
-Comments
-
- The discussion list for the IETF TLS working group is located at the
- e-mail address <ietf-tls@lists.consensus.com>. Information on the
- group and information on how to subscribe to the list is at
- <http://lists.consensus.com/>.
-
- Archives of the list can be found at:
- <http://www.imc.org/ietf-tls/mail-archive/>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 89]\fdraft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla Standards Track [Page 90]\f
+\r
+\r
+ Tim Dierks |\r
+ Google |\r
+ Eric Rescorla |\r
+INTERNET-DRAFT RTFM, Inc. |\r
+<draft-ietf-tls-rfc2246-bis-06.txt> March 2004 (Expires September 2004) |\r
+\r
+\r
+ The TLS Protocol\r
+ Version 1.1 |\r
+\r
+\r
+Status of this Memo\r
+\r
+\r
+ This document is an Internet-Draft and is in full conformance with |\r
+ all provisions of Section 10 of RFC2026. Internet-Drafts are working |\r
+ documents of the Internet Engineering Task Force (IETF), its areas, |\r
+ and its working groups. Note that other groups may also distribute |\r
+ working documents as Internet-Drafts. |\r
+\r
+\r
+ Internet-Drafts are draft documents valid for a maximum of six months |\r
+ and may be updated, replaced, or obsoleted by other documents at any |\r
+ time. It is inappropriate to use Internet-Drafts as reference |\r
+ material or to cite them other than as "work in progress." |\r
+\r
+\r
+ To learn the current status of any Internet-Draft, please check the |\r
+ "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow |\r
+ Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), |\r
+ munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or |\r
+ ftp.isi.edu (US West Coast).\r
+Copyright Notice\r
+\r
+\r
+ Copyright (C) The Internet Society (1999-2004). All Rights Reserved. |\r
+\r
+\r
+Abstract\r
+\r
+\r
+ This document specifies Version 1.1 of the Transport Layer Security |\r
+ (TLS) protocol. The TLS protocol provides communications security\r
+ over the Internet. The protocol allows client/server applications to\r
+ communicate in a way that is designed to prevent eavesdropping,\r
+ tampering, or message forgery.\r
+\r
+\r
+Table of Contents\r
+\r
+\r
+ 1. Introduction 3\r
+ 2. Goals 4\r
+ 3. Goals of this document 5\r
+ 4. Presentation language 5\r
+ 4.1. Basic block size 6\r
+ 4.2. Miscellaneous 6\r
+ 4.3. Vectors 6\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 1] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ 4.4. Numbers 7\r
+ 4.5. Enumerateds 7\r
+ 4.6. Constructed types 8\r
+ 4.6.1. Variants 9\r
+ 4.7. Cryptographic attributes 10\r
+ 4.8. Constants 11\r
+ 5. HMAC and the pseudorandom function 11\r
+ 6. The TLS Record Protocol 13\r
+ 6.1. Connection states 14\r
+ 6.2. Record layer 16\r
+ 6.2.1. Fragmentation 16\r
+ 6.2.2. Record compression and decompression 17\r
+ 6.2.3. Record payload protection 18\r
+ 6.2.3.1. Null or standard stream cipher 19\r
+ 6.2.3.2. CBC block cipher 19\r
+ 6.3. Key calculation 21\r
+ 6.3.1. Export key generation example 22\r
+ 7. The TLS Handshake Protocol 23\r
+ 7.1. Change cipher spec protocol 24\r
+ 7.2. Alert protocol 24\r
+ 7.2.1. Closure alerts 25\r
+ 7.2.2. Error alerts 26\r
+ 7.3. Handshake Protocol overview 29\r
+ 7.4. Handshake protocol 32\r
+ 7.4.1. Hello messages 33\r
+ 7.4.1.1. Hello request 33\r
+ 7.4.1.2. Client hello 34\r
+ 7.4.1.3. Server hello 36\r
+ 7.4.2. Server certificate 37\r
+ 7.4.3. Server key exchange message 39\r
+ 7.4.4. Certificate request 41\r
+ 7.4.5. Server hello done 42\r
+ 7.4.6. Client certificate 43\r
+ 7.4.7. Client key exchange message 43\r
+ 7.4.7.1. RSA encrypted premaster secret message 44\r
+ 7.4.7.2. Client Diffie-Hellman public value 45\r
+ 7.4.8. Certificate verify 45\r
+ 7.4.9. Finished 46\r
+ 8. Cryptographic computations 47\r
+ 8.1. Computing the master secret 47\r
+ 8.1.1. RSA 48\r
+ 8.1.2. Diffie-Hellman 48\r
+ 9. Mandatory Cipher Suites 48\r
+ 10. Application data protocol 48\r
+ A. Protocol constant values 49\r
+ A.1. Record layer 49\r
+ A.2. Change cipher specs message 50\r
+ A.3. Alert messages 50\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 2] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ A.4. Handshake protocol 51\r
+ A.4.1. Hello messages 51\r
+ A.4.2. Server authentication and key exchange messages 52\r
+ A.4.3. Client authentication and key exchange messages 53\r
+ A.4.4. Handshake finalization message 54\r
+ A.5. The CipherSuite 54\r
+ A.6. The Security Parameters 56\r
+ B. Glossary 57\r
+ C. CipherSuite definitions 61\r
+ D. Implementation Notes 64\r
+ D.1. Temporary RSA keys 64\r
+ D.2. Random Number Generation and Seeding 64\r
+ D.3. Certificates and authentication 65\r
+ D.4. CipherSuites 65\r
+ E. Backward Compatibility With SSL 66\r
+ E.1. Version 2 client hello 67\r
+ E.2. Avoiding man-in-the-middle version rollback 68\r
+ F. Security analysis 69\r
+ F.1. Handshake protocol 69\r
+ F.1.1. Authentication and key exchange 69\r
+ F.1.1.1. Anonymous key exchange 69\r
+ F.1.1.2. RSA key exchange and authentication 70\r
+ F.1.1.3. Diffie-Hellman key exchange with authentication 71\r
+ F.1.2. Version rollback attacks 71\r
+ F.1.3. Detecting attacks against the handshake protocol 72\r
+ F.1.4. Resuming sessions 72\r
+ F.1.5. MD5 and SHA 72\r
+ F.2. Protecting application data 72\r
+ F.3. Final notes 73\r
+ G. Patent Statement 74\r
+ Security Considerations 75\r
+ References 75\r
+ Credits 77\r
+ Comments 78\r
+ Full Copyright Statement 80\r
+\r
+\r
+Change history |\r
+\r
+\r
+ Note: Change bars in this draft are from RFC 2246, not draft-00 |\r
+\r
+\r
+ 26-Jun-03 ekr@rtfm.com |\r
+ * Incorporated Last Call comments from Franke Marcus, Jack Lloyd, |\r
+ Brad Wetmore, and others. |\r
+\r
+\r
+ 22-Apr-03 ekr@rtfm.com |\r
+ * coverage of the Vaudenay, Boneh-Brumley, and KPR attacks |\r
+ * cleaned up IV text a bit. |\r
+ * Added discussion of Denial of Service attacks. |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 3] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ |\r
+ 11-Feb-02 ekr@rtfm.com |\r
+ * Clarified the behavior of empty certificate lists [Nelson Bolyard] |\r
+ * Added text explaining the security implications of authenticate |\r
+ then encrypt. |\r
+ * Cleaned up the explicit IV text. |\r
+ * Added some more acknowledgement names |\r
+\r
+\r
+ 02-Nov-02 ekr@rtfm.com |\r
+ * Changed this to be TLS 1.1. |\r
+ * Added fixes for the Rogaway and Vaudenay CBC attacks |\r
+ * Separated references into normative and informative |\r
+\r
+\r
+ 01-Mar-02 ekr@rtfm.com |\r
+ * Tightened up the language in F.1.1.2 [Peter Watkins] |\r
+ * Fixed smart quotes [Bodo Moeller] |\r
+ * Changed handling of padding errors to prevent CBC-based attack |\r
+ [Bodo Moeller] |\r
+ * Fixed certificate_list spec in the appendix [Aman Sawrup] |\r
+ * Fixed a bug in the V2 definitions [Aman Sawrup] |\r
+ * Fixed S 7.2.1 to point out that you don't need a close notify |\r
+ if you just sent some other fatal alert [Andreas Sterbenz] |\r
+ * Marked alert 41 reserved [Andreas Sterbenz] |\r
+ * Changed S 7.4.2 to point out that 512-bit keys cannot be used for |\r
+ signing [Andreas Sterbenz] |\r
+ * Added reserved client key types from SSLv3 [Andreas Sterbenz] |\r
+ * Changed EXPORT40 to "40-bit EXPORT" in S 9 [Andreas Sterbenz] |\r
+ * Removed RSA patent statement [Andreas Sterbenz] |\r
+ * Removed references to BSAFE and RSAREF [Andreas Sterbenz] |\r
+\r
+\r
+ 14-Feb-02 ekr@rtfm.com |\r
+ * Re-converted to I-D from RFC |\r
+ * Made RSA/3DES the mandatory cipher suite. |\r
+ * Added discussion of the EncryptedPMS encoding and PMS version number|\r
+ issues to 7.4.7.1 |\r
+ * Removed the requirement in 7.4.1.3 that the Server random must be |\r
+ different from the Client random, since these are randomly generated|\r
+ and we don't expect servers to reject Server random values which |\r
+ coincidentally are the same as the Client random. |\r
+ * Replaced may/should/must with MAY/SHOULD/MUST where appropriate. |\r
+ In many cases, shoulds became MUSTs, where I believed that was the |\r
+ actual sense of the text. Added an RFC 2119 bulletin. |\r
+ * Clarified the meaning of "empty certificate" message. [Peter Gutmann]|\r
+ * Redid the CertificateRequest grammar to allow no distinguished names.|\r
+ [Peter Gutmann] |\r
+ * Removed the reference to requiring the master secret to generate |\r
+ the CertificateVerify in F.1.1 [Bodo Moeller] |\r
+ * Deprecated EXPORT40. |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 4] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ * Fixed a bunch of errors in the SSLv2 backward compatible client hello.|\r
+\r
+\r
+1. Introduction\r
+\r
+\r
+ The primary goal of the TLS Protocol is to provide privacy and data\r
+ integrity between two communicating applications. The protocol is\r
+ composed of two layers: the TLS Record Protocol and the TLS Handshake\r
+ Protocol. At the lowest level, layered on top of some reliable\r
+ transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The\r
+ TLS Record Protocol provides connection security that has two basic\r
+ properties:\r
+\r
+\r
+ - - The connection is private. Symmetric cryptography is used for\r
+ data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for\r
+ this symmetric encryption are generated uniquely for each\r
+ connection and are based on a secret negotiated by another\r
+ protocol (such as the TLS Handshake Protocol). The Record\r
+ Protocol can also be used without encryption.\r
+\r
+\r
+ - - The connection is reliable. Message transport includes a\r
+ message integrity check using a keyed MAC. Secure hash functions\r
+ (e.g., SHA, MD5, etc.) are used for MAC computations. The Record\r
+ Protocol can operate without a MAC, but is generally only used in\r
+ this mode while another protocol is using the Record Protocol as\r
+ a transport for negotiating security parameters.\r
+\r
+\r
+ The TLS Record Protocol is used for encapsulation of various higher\r
+ level protocols. One such encapsulated protocol, the TLS Handshake\r
+ Protocol, allows the server and client to authenticate each other and\r
+ to negotiate an encryption algorithm and cryptographic keys before\r
+ the application protocol transmits or receives its first byte of\r
+ data. The TLS Handshake Protocol provides connection security that\r
+ has three basic properties:\r
+\r
+\r
+ - - The peer's identity can be authenticated using asymmetric, or\r
+ public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This\r
+ authentication can be made optional, but is generally required\r
+ for at least one of the peers.\r
+\r
+\r
+ - - The negotiation of a shared secret is secure: the negotiated |\r
+ secret is unavailable to eavesdroppers, and for any authenticated\r
+ connection the secret cannot be obtained, even by an attacker who\r
+ can place himself in the middle of the connection.\r
+\r
+\r
+ - - The negotiation is reliable: no attacker can modify the\r
+ negotiation communication without being detected by the parties\r
+ to the communication.\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 5] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ One advantage of TLS is that it is application protocol independent.\r
+ Higher level protocols can layer on top of the TLS Protocol\r
+ transparently. The TLS standard, however, does not specify how\r
+ protocols add security with TLS; the decisions on how to initiate TLS\r
+ handshaking and how to interpret the authentication certificates\r
+ exchanged are left up to the judgment of the designers and\r
+ implementors of protocols which run on top of TLS.\r
+\r
+\r
+1.1 Requirements Terminology |\r
+\r
+\r
+ Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and |\r
+ "MAY" that appear in this document are to be interpreted as described |\r
+ in RFC 2119 [REQ]. |\r
+\r
+\r
+2. Goals\r
+\r
+\r
+ The goals of TLS Protocol, in order of their priority, are:\r
+\r
+\r
+ 1. Cryptographic security: TLS should be used to establish a secure\r
+ connection between two parties.\r
+\r
+\r
+ 2. Interoperability: Independent programmers should be able to\r
+ develop applications utilizing TLS that will then be able to\r
+ successfully exchange cryptographic parameters without knowledge\r
+ of one another's code.\r
+\r
+\r
+ 3. Extensibility: TLS seeks to provide a framework into which new\r
+ public key and bulk encryption methods can be incorporated as\r
+ necessary. This will also accomplish two sub-goals: to prevent\r
+ the need to create a new protocol (and risking the introduction\r
+ of possible new weaknesses) and to avoid the need to implement an\r
+ entire new security library.\r
+\r
+\r
+ 4. Relative efficiency: Cryptographic operations tend to be highly\r
+ CPU intensive, particularly public key operations. For this\r
+ reason, the TLS protocol has incorporated an optional session\r
+ caching scheme to reduce the number of connections that need to\r
+ be established from scratch. Additionally, care has been taken to\r
+ reduce network activity.\r
+\r
+\r
+3. Goals of this document\r
+\r
+\r
+ This document and the TLS protocol itself are based on the SSL 3.0\r
+ Protocol Specification as published by Netscape. The differences\r
+ between this protocol and SSL 3.0 are not dramatic, but they are\r
+ significant enough that TLS 1.0 and SSL 3.0 do not interoperate\r
+ (although TLS 1.0 does incorporate a mechanism by which a TLS\r
+ implementation can back down to SSL 3.0). This document is intended\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 6] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ primarily for readers who will be implementing the protocol and those\r
+ doing cryptographic analysis of it. The specification has been\r
+ written with this in mind, and it is intended to reflect the needs of\r
+ those two groups. For that reason, many of the algorithm-dependent\r
+ data structures and rules are included in the body of the text (as\r
+ opposed to in an appendix), providing easier access to them.\r
+\r
+\r
+ This document is not intended to supply any details of service\r
+ definition nor interface definition, although it does cover select\r
+ areas of policy as they are required for the maintenance of solid\r
+ security.\r
+\r
+\r
+4. Presentation language\r
+\r
+\r
+ This document deals with the formatting of data in an external\r
+ representation. The following very basic and somewhat casually\r
+ defined presentation syntax will be used. The syntax draws from\r
+ several sources in its structure. Although it resembles the\r
+ programming language "C" in its syntax and XDR [XDR] in both its\r
+ syntax and intent, it would be risky to draw too many parallels. The\r
+ purpose of this presentation language is to document TLS only, not to\r
+ have general application beyond that particular goal.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 7] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+4.1. Basic block size\r
+\r
+\r
+ The representation of all data items is explicitly specified. The\r
+ basic data block size is one byte (i.e. 8 bits). Multiple byte data\r
+ items are concatenations of bytes, from left to right, from top to\r
+ bottom. From the bytestream a multi-byte item (a numeric in the\r
+ example) is formed (using C notation) by:\r
+\r
+\r
+ value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |\r
+ ... | byte[n-1];\r
+\r
+\r
+ This byte ordering for multi-byte values is the commonplace network\r
+ byte order or big endian format.\r
+\r
+\r
+4.2. Miscellaneous\r
+\r
+\r
+ Comments begin with "/*" and end with "*/".\r
+\r
+\r
+ Optional components are denoted by enclosing them in "[[ ]]" double\r
+ brackets.\r
+\r
+\r
+ Single byte entities containing uninterpreted data are of type\r
+ opaque.\r
+\r
+\r
+4.3. Vectors\r
+\r
+\r
+ A vector (single dimensioned array) is a stream of homogeneous data\r
+ elements. The size of the vector may be specified at documentation\r
+ time or left unspecified until runtime. In either case the length\r
+ declares the number of bytes, not the number of elements, in the\r
+ vector. The syntax for specifying a new type T' that is a fixed\r
+ length vector of type T is\r
+\r
+\r
+ T T'[n];\r
+\r
+\r
+ Here T' occupies n bytes in the data stream, where n is a multiple of\r
+ the size of T. The length of the vector is not included in the\r
+ encoded stream.\r
+\r
+\r
+ In the following example, Datum is defined to be three consecutive\r
+ bytes that the protocol does not interpret, while Data is three\r
+ consecutive Datum, consuming a total of nine bytes.\r
+\r
+\r
+ opaque Datum[3]; /* three uninterpreted bytes */\r
+ Datum Data[9]; /* 3 consecutive 3 byte vectors */\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 8] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Variable length vectors are defined by specifying a subrange of legal\r
+ lengths, inclusively, using the notation <floor..ceiling>. When\r
+ encoded, the actual length precedes the vector's contents in the byte\r
+ stream. The length will be in the form of a number consuming as many\r
+ bytes as required to hold the vector's specified maximum (ceiling)\r
+ length. A variable length vector with an actual length field of zero\r
+ is referred to as an empty vector.\r
+\r
+\r
+ T T'<floor..ceiling>;\r
+\r
+\r
+ In the following example, mandatory is a vector that must contain\r
+ between 300 and 400 bytes of type opaque. It can never be empty. The\r
+ actual length field consumes two bytes, a uint16, sufficient to\r
+ represent the value 400 (see Section 4.4). On the other hand, longer\r
+ can represent up to 800 bytes of data, or 400 uint16 elements, and it\r
+ may be empty. Its encoding will include a two byte actual length\r
+ field prepended to the vector. The length of an encoded vector must\r
+ be an even multiple of the length of a single element (for example, a\r
+ 17 byte vector of uint16 would be illegal).\r
+\r
+\r
+ opaque mandatory<300..400>;\r
+ /* length field is 2 bytes, cannot be empty */\r
+ uint16 longer<0..800>;\r
+ /* zero to 400 16-bit unsigned integers */\r
+\r
+\r
+4.4. Numbers\r
+\r
+\r
+ The basic numeric data type is an unsigned byte (uint8). All larger\r
+ numeric data types are formed from fixed length series of bytes\r
+ concatenated as described in Section 4.1 and are also unsigned. The\r
+ following numeric types are predefined.\r
+\r
+\r
+ uint8 uint16[2];\r
+ uint8 uint24[3];\r
+ uint8 uint32[4];\r
+ uint8 uint64[8];\r
+\r
+\r
+ All values, here and elsewhere in the specification, are stored in\r
+ "network" or "big-endian" order; the uint32 represented by the hex\r
+ bytes 01 02 03 04 is equivalent to the decimal value 16909060.\r
+\r
+\r
+4.5. Enumerateds\r
+\r
+\r
+ An additional sparse data type is available called enum. A field of\r
+ type enum can only assume the values declared in the definition.\r
+ Each definition is a different type. Only enumerateds of the same\r
+ type may be assigned or compared. Every element of an enumerated must\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 9] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ be assigned a value, as demonstrated in the following example. Since\r
+ the elements of the enumerated are not ordered, they can be assigned\r
+ any unique value, in any order.\r
+\r
+\r
+ enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;\r
+\r
+\r
+ Enumerateds occupy as much space in the byte stream as would its\r
+ maximal defined ordinal value. The following definition would cause\r
+ one byte to be used to carry fields of type Color.\r
+\r
+\r
+ enum { red(3), blue(5), white(7) } Color;\r
+\r
+\r
+ One may optionally specify a value without its associated tag to\r
+ force the width definition without defining a superfluous element.\r
+ In the following example, Taste will consume two bytes in the data\r
+ stream but can only assume the values 1, 2 or 4.\r
+\r
+\r
+ enum { sweet(1), sour(2), bitter(4), (32000) } Taste;\r
+\r
+\r
+ The names of the elements of an enumeration are scoped within the\r
+ defined type. In the first example, a fully qualified reference to\r
+ the second element of the enumeration would be Color.blue. Such\r
+ qualification is not required if the target of the assignment is well\r
+ specified.\r
+\r
+\r
+ Color color = Color.blue; /* overspecified, legal */\r
+ Color color = blue; /* correct, type implicit */\r
+\r
+\r
+ For enumerateds that are never converted to external representation,\r
+ the numerical information may be omitted.\r
+\r
+\r
+ enum { low, medium, high } Amount;\r
+\r
+\r
+4.6. Constructed types\r
+\r
+\r
+ Structure types may be constructed from primitive types for\r
+ convenience. Each specification declares a new, unique type. The\r
+ syntax for definition is much like that of C.\r
+\r
+\r
+ struct {\r
+ T1 f1;\r
+ T2 f2;\r
+ ...\r
+ Tn fn;\r
+ } [[T]];\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 10] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ The fields within a structure may be qualified using the type's name\r
+ using a syntax much like that available for enumerateds. For example,\r
+ T.f2 refers to the second field of the previous declaration.\r
+ Structure definitions may be embedded.\r
+\r
+\r
+4.6.1. Variants\r
+\r
+\r
+ Defined structures may have variants based on some knowledge that is\r
+ available within the environment. The selector must be an enumerated\r
+ type that defines the possible variants the structure defines. There\r
+ must be a case arm for every element of the enumeration declared in\r
+ the select. The body of the variant structure may be given a label\r
+ for reference. The mechanism by which the variant is selected at\r
+ runtime is not prescribed by the presentation language.\r
+\r
+\r
+ struct {\r
+ T1 f1;\r
+ T2 f2;\r
+ ....\r
+ Tn fn;\r
+ select (E) {\r
+ case e1: Te1;\r
+ case e2: Te2;\r
+ ....\r
+ case en: Ten;\r
+ } [[fv]];\r
+ } [[Tv]];\r
+\r
+\r
+ For example:\r
+\r
+\r
+ enum { apple, orange } VariantTag;\r
+ struct {\r
+ uint16 number;\r
+ opaque string<0..10>; /* variable length */\r
+ } V1;\r
+ struct {\r
+ uint32 number;\r
+ opaque string[10]; /* fixed length */\r
+ } V2;\r
+ struct {\r
+ select (VariantTag) { /* value of selector is implicit */\r
+ case apple: V1; /* VariantBody, tag = apple */\r
+ case orange: V2; /* VariantBody, tag = orange */\r
+ } variant_body; /* optional label on variant */\r
+ } VariantRecord;\r
+\r
+\r
+ Variant structures may be qualified (narrowed) by specifying a value\r
+ for the selector prior to the type. For example, a\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 11] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ orange VariantRecord\r
+\r
+\r
+ is a narrowed type of a VariantRecord containing a variant_body of\r
+ type V2.\r
+\r
+\r
+4.7. Cryptographic attributes\r
+\r
+\r
+ The four cryptographic operations digital signing, stream cipher\r
+ encryption, block cipher encryption, and public key encryption are\r
+ designated digitally-signed, stream-ciphered, block-ciphered, and\r
+ public-key-encrypted, respectively. A field's cryptographic\r
+ processing is specified by prepending an appropriate key word\r
+ designation before the field's type specification. Cryptographic keys\r
+ are implied by the current session state (see Section 6.1).\r
+\r
+\r
+ In digital signing, one-way hash functions are used as input for a\r
+ signing algorithm. A digitally-signed element is encoded as an opaque\r
+ vector <0..2^16-1>, where the length is specified by the signing\r
+ algorithm and key.\r
+\r
+\r
+ In RSA signing, a 36-byte structure of two hashes (one SHA and one\r
+ MD5) is signed (encrypted with the private key). It is encoded with\r
+ PKCS #1 block type 0 or type 1 as described in [PKCS1].\r
+\r
+\r
+ In DSS, the 20 bytes of the SHA hash are run directly through the\r
+ Digital Signing Algorithm with no additional hashing. This produces\r
+ two values, r and s. The DSS signature is an opaque vector, as above,\r
+ the contents of which are the DER encoding of:\r
+\r
+\r
+ Dss-Sig-Value ::= SEQUENCE {\r
+ r INTEGER,\r
+ s INTEGER\r
+ }\r
+\r
+\r
+ In stream cipher encryption, the plaintext is exclusive-ORed with an\r
+ identical amount of output generated from a cryptographically-secure\r
+ keyed pseudorandom number generator.\r
+\r
+\r
+ In block cipher encryption, every block of plaintext encrypts to a\r
+ block of ciphertext. All block cipher encryption is done in CBC\r
+ (Cipher Block Chaining) mode, and all items which are block-ciphered\r
+ will be an exact multiple of the cipher block length.\r
+\r
+\r
+ In public key encryption, a public key algorithm is used to encrypt\r
+ data in such a way that it can be decrypted only with the matching\r
+ private key. A public-key-encrypted element is encoded as an opaque\r
+ vector <0..2^16-1>, where the length is specified by the signing\r
+ algorithm and key.\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 12] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ An RSA encrypted value is encoded with PKCS #1 block type 2 as\r
+ described in [PKCS1].\r
+\r
+\r
+ In the following example:\r
+\r
+\r
+ stream-ciphered struct {\r
+ uint8 field1;\r
+ uint8 field2;\r
+ digitally-signed opaque hash[20];\r
+ } UserType;\r
+\r
+\r
+ The contents of hash are used as input for the signing algorithm,\r
+ then the entire structure is encrypted with a stream cipher. The\r
+ length of this structure, in bytes would be equal to 2 bytes for\r
+ field1 and field2, plus two bytes for the length of the signature,\r
+ plus the length of the output of the signing algorithm. This is known\r
+ due to the fact that the algorithm and key used for the signing are\r
+ known prior to encoding or decoding this structure.\r
+\r
+\r
+4.8. Constants\r
+\r
+\r
+ Typed constants can be defined for purposes of specification by\r
+ declaring a symbol of the desired type and assigning values to it.\r
+ Under-specified types (opaque, variable length vectors, and\r
+ structures that contain opaque) cannot be assigned values. No fields\r
+ of a multi-element structure or vector may be elided.\r
+\r
+\r
+ For example,\r
+\r
+\r
+ struct {\r
+ uint8 f1;\r
+ uint8 f2;\r
+ } Example1;\r
+\r
+\r
+ Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */\r
+\r
+\r
+5. HMAC and the pseudorandom function\r
+\r
+\r
+ A number of operations in the TLS record and handshake layer required\r
+ a keyed MAC; this is a secure digest of some data protected by a\r
+ secret. Forging the MAC is infeasible without knowledge of the MAC\r
+ secret. The construction we use for this operation is known as HMAC,\r
+ described in [HMAC].\r
+\r
+\r
+ HMAC can be used with a variety of different hash algorithms. TLS\r
+ uses it in the handshake with two different algorithms: MD5 and\r
+ SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 13] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ data). Additional hash algorithms can be defined by cipher suites and\r
+ used to protect record data, but MD5 and SHA-1 are hard coded into\r
+ the description of the handshaking for this version of the protocol.\r
+\r
+\r
+ In addition, a construction is required to do expansion of secrets\r
+ into blocks of data for the purposes of key generation or validation.\r
+ This pseudo-random function (PRF) takes as input a secret, a seed,\r
+ and an identifying label and produces an output of arbitrary length.\r
+\r
+\r
+ In order to make the PRF as secure as possible, it uses two hash\r
+ algorithms in a way which should guarantee its security if either\r
+ algorithm remains secure.\r
+\r
+\r
+ First, we define a data expansion function, P_hash(secret, data)\r
+ which uses a single hash function to expand a secret and seed into an\r
+ arbitrary quantity of output:\r
+\r
+\r
+ P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +\r
+ HMAC_hash(secret, A(2) + seed) +\r
+ HMAC_hash(secret, A(3) + seed) + ...\r
+\r
+\r
+ Where + indicates concatenation.\r
+\r
+\r
+ A() is defined as:\r
+ A(0) = seed\r
+ A(i) = HMAC_hash(secret, A(i-1))\r
+\r
+\r
+ P_hash can be iterated as many times as is necessary to produce the\r
+ required quantity of data. For example, if P_SHA-1 was being used to\r
+ create 64 bytes of data, it would have to be iterated 4 times\r
+ (through A(4)), creating 80 bytes of output data; the last 16 bytes\r
+ of the final iteration would then be discarded, leaving 64 bytes of\r
+ output data.\r
+\r
+\r
+ TLS's PRF is created by splitting the secret into two halves and\r
+ using one half to generate data with P_MD5 and the other half to\r
+ generate data with P_SHA-1, then exclusive-or'ing the outputs of\r
+ these two expansion functions together.\r
+\r
+\r
+ S1 and S2 are the two halves of the secret and each is the same\r
+ length. S1 is taken from the first half of the secret, S2 from the\r
+ second half. Their length is created by rounding up the length of the\r
+ overall secret divided by two; thus, if the original secret is an odd\r
+ number of bytes long, the last byte of S1 will be the same as the\r
+ first byte of S2.\r
+\r
+\r
+ L_S = length in bytes of secret;\r
+ L_S1 = L_S2 = ceil(L_S / 2);\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 14] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ The secret is partitioned into two halves (with the possibility of\r
+ one shared byte) as described above, S1 taking the first L_S1 bytes\r
+ and S2 the last L_S2 bytes.\r
+\r
+\r
+ The PRF is then defined as the result of mixing the two pseudorandom\r
+ streams by exclusive-or'ing them together.\r
+\r
+\r
+ PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR\r
+ P_SHA-1(S2, label + seed);\r
+\r
+\r
+ The label is an ASCII string. It should be included in the exact form\r
+ it is given without a length byte or trailing null character. For\r
+ example, the label "slithy toves" would be processed by hashing the\r
+ following bytes:\r
+\r
+\r
+ 73 6C 69 74 68 79 20 74 6F 76 65 73\r
+\r
+\r
+ Note that because MD5 produces 16 byte outputs and SHA-1 produces 20\r
+ byte outputs, the boundaries of their internal iterations will not be\r
+ aligned; to generate a 80 byte output will involve P_MD5 being\r
+ iterated through A(5), while P_SHA-1 will only iterate through A(4).\r
+\r
+\r
+6. The TLS Record Protocol\r
+\r
+\r
+ The TLS Record Protocol is a layered protocol. At each layer,\r
+ messages may include fields for length, description, and content.\r
+ The Record Protocol takes messages to be transmitted, fragments the\r
+ data into manageable blocks, optionally compresses the data, applies\r
+ a MAC, encrypts, and transmits the result. Received data is\r
+ decrypted, verified, decompressed, and reassembled, then delivered to\r
+ higher level clients.\r
+\r
+\r
+ Four record protocol clients are described in this document: the\r
+ handshake protocol, the alert protocol, the change cipher spec\r
+ protocol, and the application data protocol. In order to allow\r
+ extension of the TLS protocol, additional record types can be |\r
+ supported by the record protocol. Any new record types SHOULD\r
+ allocate type values immediately beyond the ContentType values for\r
+ the four record types described here (see Appendix A.2). If a TLS\r
+ implementation receives a record type it does not understand, it |\r
+ SHOULD just ignore it. Any protocol designed for use over TLS MUST be\r
+ carefully designed to deal with all possible attacks against it.\r
+ Note that because the type and length of a record are not protected |\r
+ by encryption, care SHOULD be taken to minimize the value of traffic\r
+ analysis of these values.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 15] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+6.1. Connection states\r
+\r
+\r
+ A TLS connection state is the operating environment of the TLS Record\r
+ Protocol. It specifies a compression algorithm, encryption algorithm,\r
+ and MAC algorithm. In addition, the parameters for these algorithms\r
+ are known: the MAC secret and the bulk encryption keys for the |\r
+ connection in both the read and the write directions. Logically,\r
+ there are always four connection states outstanding: the current read\r
+ and write states, and the pending read and write states. All records\r
+ are processed under the current read and write states. The security\r
+ parameters for the pending states can be set by the TLS Handshake\r
+ Protocol, and the Handshake Protocol can selectively make either of\r
+ the pending states current, in which case the appropriate current\r
+ state is disposed of and replaced with the pending state; the pending\r
+ state is then reinitialized to an empty state. It is illegal to make\r
+ a state which has not been initialized with security parameters a\r
+ current state. The initial current state always specifies that no\r
+ encryption, compression, or MAC will be used.\r
+\r
+\r
+ The security parameters for a TLS Connection read and write state are\r
+ set by providing the following values:\r
+\r
+\r
+ connection end\r
+ Whether this entity is considered the "client" or the "server" in\r
+ this connection.\r
+\r
+\r
+ bulk encryption algorithm\r
+ An algorithm to be used for bulk encryption. This specification\r
+ includes the key size of this algorithm, how much of that key is\r
+ secret, whether it is a block or stream cipher, the block size of\r
+ the cipher (if appropriate), and whether it is considered an\r
+ "export" cipher.\r
+\r
+\r
+ MAC algorithm\r
+ An algorithm to be used for message authentication. This\r
+ specification includes the size of the hash which is returned by\r
+ the MAC algorithm.\r
+\r
+\r
+ compression algorithm\r
+ An algorithm to be used for data compression. This specification\r
+ must include all information the algorithm requires to do\r
+ compression.\r
+\r
+\r
+ master secret\r
+ A 48 byte secret shared between the two peers in the connection.\r
+\r
+\r
+ client random\r
+ A 32 byte value provided by the client.\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 16] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ server random\r
+ A 32 byte value provided by the server.\r
+\r
+\r
+ These parameters are defined in the presentation language as:\r
+\r
+\r
+ enum { server, client } ConnectionEnd;\r
+\r
+\r
+ enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;\r
+\r
+\r
+ enum { stream, block } CipherType;\r
+\r
+\r
+ enum { true, false } IsExportable;\r
+\r
+\r
+ enum { null, md5, sha } MACAlgorithm;\r
+\r
+\r
+ enum { null(0), (255) } CompressionMethod;\r
+\r
+\r
+ /* The algorithms specified in CompressionMethod,\r
+ BulkCipherAlgorithm, and MACAlgorithm may be added to. */\r
+\r
+\r
+ struct {\r
+ ConnectionEnd entity;\r
+ BulkCipherAlgorithm bulk_cipher_algorithm;\r
+ CipherType cipher_type;\r
+ uint8 key_size;\r
+ uint8 key_material_length;\r
+ IsExportable is_exportable;\r
+ MACAlgorithm mac_algorithm;\r
+ uint8 hash_size;\r
+ CompressionMethod compression_algorithm;\r
+ opaque master_secret[48];\r
+ opaque client_random[32];\r
+ opaque server_random[32];\r
+ } SecurityParameters;\r
+\r
+\r
+ The record layer will use the security parameters to generate the |\r
+ following four items:\r
+\r
+\r
+ client write MAC secret\r
+ server write MAC secret\r
+ client write key\r
+ server write key\r
+\r
+\r
+ The client write parameters are used by the server when receiving and\r
+ processing records and vice-versa. The algorithm used for generating\r
+ these items from the security parameters is described in section 6.3.\r
+\r
+\r
+ Once the security parameters have been set and the keys have been\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 17] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ generated, the connection states can be instantiated by making them |\r
+ the current states. These current states MUST be updated for each\r
+ record processed. Each connection state includes the following\r
+ elements:\r
+\r
+\r
+ compression state\r
+ The current state of the compression algorithm.\r
+\r
+\r
+ cipher state\r
+ The current state of the encryption algorithm. This will consist |\r
+ of the scheduled key for that connection. For stream ciphers, |\r
+ this will also contain whatever the necessary state information |\r
+ is to allow the stream to continue to encrypt or decrypt data.\r
+\r
+\r
+ MAC secret\r
+ The MAC secret for this connection as generated above.\r
+\r
+\r
+ sequence number\r
+ Each connection state contains a sequence number, which is\r
+ maintained separately for read and write states. The sequence |\r
+ number MUST be set to zero whenever a connection state is made\r
+ the active state. Sequence numbers are of type uint64 and may not |\r
+ exceed 2^64-1. Sequence numbers do not wrap. If a TLS |\r
+ implementation would need to wrap a sequence number it must |\r
+ renegotiate instead. A sequence number is incremented after each\r
+ record: specifically, the first record which is transmitted under |\r
+ a particular connection state MUST use sequence number 0.\r
+\r
+\r
+6.2. Record layer\r
+\r
+\r
+ The TLS Record Layer receives uninterpreted data from higher layers\r
+ in non-empty blocks of arbitrary size.\r
+\r
+\r
+6.2.1. Fragmentation\r
+\r
+\r
+ The record layer fragments information blocks into TLSPlaintext\r
+ records carrying data in chunks of 2^14 bytes or less. Client message\r
+ boundaries are not preserved in the record layer (i.e., multiple |\r
+ client messages of the same ContentType MAY be coalesced into a |\r
+ single TLSPlaintext record, or a single message MAY be fragmented |\r
+ across several records). |\r
+\r
+\r
+\r
+ struct {\r
+ uint8 major, minor;\r
+ } ProtocolVersion;\r
+\r
+\r
+ enum {\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 18] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ change_cipher_spec(20), alert(21), handshake(22),\r
+ application_data(23), (255)\r
+ } ContentType;\r
+\r
+\r
+ struct {\r
+ ContentType type;\r
+ ProtocolVersion version;\r
+ uint16 length;\r
+ opaque fragment[TLSPlaintext.length];\r
+ } TLSPlaintext;\r
+\r
+\r
+ type\r
+ The higher level protocol used to process the enclosed fragment.\r
+\r
+\r
+ version\r
+ The version of the protocol being employed. This document |\r
+ describes TLS Version 1.1, which uses the version { 3, 2 }. The |\r
+ version value 3.2 is historical: TLS version 1.1 is a minor |\r
+ modification to the TLS 1.0 protocol, which was itself a minor |\r
+ modification to the SSL 3.0 protocol, which bears the version\r
+ value 3.0. (See Appendix A.1).\r
+\r
+\r
+ length\r
+ The length (in bytes) of the following TLSPlaintext.fragment.\r
+ The length should not exceed 2^14.\r
+\r
+\r
+ fragment\r
+ The application data. This data is transparent and treated as an\r
+ independent block to be dealt with by the higher level protocol\r
+ specified by the type field.\r
+\r
+\r
+ Note: Data of different TLS Record layer content types MAY be |\r
+ interleaved. Application data is generally of lower precedence |\r
+ for transmission than other content types and therefore handshake |\r
+ records may be held if application data is pending. However, |\r
+ records MUST be delivered to the network in the same order as |\r
+ they are protected by the record layer. |\r
+\r
+\r
+6.2.2. Record compression and decompression\r
+\r
+\r
+ All records are compressed using the compression algorithm defined in\r
+ the current session state. There is always an active compression\r
+ algorithm; however, initially it is defined as\r
+ CompressionMethod.null. The compression algorithm translates a\r
+ TLSPlaintext structure into a TLSCompressed structure. Compression\r
+ functions are initialized with default state information whenever a\r
+ connection state is made active.\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 19] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Compression must be lossless and may not increase the content length\r
+ by more than 1024 bytes. If the decompression function encounters a\r
+ TLSCompressed.fragment that would decompress to a length in excess of\r
+ 2^14 bytes, it should report a fatal decompression failure error.\r
+\r
+\r
+ struct {\r
+ ContentType type; /* same as TLSPlaintext.type */\r
+ ProtocolVersion version;/* same as TLSPlaintext.version */\r
+ uint16 length;\r
+ opaque fragment[TLSCompressed.length];\r
+ } TLSCompressed;\r
+\r
+\r
+ length\r
+ The length (in bytes) of the following TLSCompressed.fragment.\r
+ The length should not exceed 2^14 + 1024.\r
+\r
+\r
+ fragment\r
+ The compressed form of TLSPlaintext.fragment.\r
+\r
+\r
+ Note: A CompressionMethod.null operation is an identity operation; no\r
+ fields are altered.\r
+\r
+\r
+ Implementation note:\r
+ Decompression functions are responsible for ensuring that\r
+ messages cannot cause internal buffer overflows.\r
+\r
+\r
+6.2.3. Record payload protection\r
+\r
+\r
+ The encryption and MAC functions translate a TLSCompressed structure\r
+ into a TLSCiphertext. The decryption functions reverse the process.\r
+ The MAC of the record also includes a sequence number so that\r
+ missing, extra or repeated messages are detectable.\r
+\r
+\r
+ struct {\r
+ ContentType type;\r
+ ProtocolVersion version;\r
+ uint16 length;\r
+ select (CipherSpec.cipher_type) {\r
+ case stream: GenericStreamCipher;\r
+ case block: GenericBlockCipher;\r
+ } fragment;\r
+ } TLSCiphertext;\r
+\r
+\r
+ type\r
+ The type field is identical to TLSCompressed.type.\r
+\r
+\r
+ version\r
+ The version field is identical to TLSCompressed.version.\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 20] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ length\r
+ The length (in bytes) of the following TLSCiphertext.fragment.\r
+ The length may not exceed 2^14 + 2048.\r
+\r
+\r
+ fragment |\r
+ The encrypted form of TLSCompressed.fragment, with the MAC.\r
+\r
+\r
+6.2.3.1. Null or standard stream cipher\r
+\r
+\r
+ Stream ciphers (including BulkCipherAlgorithm.null - see Appendix\r
+ A.6) convert TLSCompressed.fragment structures to and from stream\r
+ TLSCiphertext.fragment structures.\r
+\r
+\r
+ stream-ciphered struct {\r
+ opaque content[TLSCompressed.length];\r
+ opaque MAC[CipherSpec.hash_size];\r
+ } GenericStreamCipher;\r
+\r
+\r
+ The MAC is generated as:\r
+\r
+\r
+ HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +\r
+ TLSCompressed.version + TLSCompressed.length +\r
+ TLSCompressed.fragment));\r
+\r
+\r
+ where "+" denotes concatenation.\r
+\r
+\r
+ seq_num\r
+ The sequence number for this record.\r
+\r
+\r
+ hash\r
+ The hashing algorithm specified by\r
+ SecurityParameters.mac_algorithm.\r
+\r
+\r
+ Note that the MAC is computed before encryption. The stream cipher\r
+ encrypts the entire block, including the MAC. For stream ciphers that\r
+ do not use a synchronization vector (such as RC4), the stream cipher\r
+ state from the end of one record is simply used on the subsequent\r
+ packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption\r
+ consists of the identity operation (i.e., the data is not encrypted\r
+ and the MAC size is zero implying that no MAC is used).\r
+ TLSCiphertext.length is TLSCompressed.length plus\r
+ CipherSpec.hash_size.\r
+\r
+\r
+6.2.3.2. CBC block cipher\r
+\r
+\r
+ For block ciphers (such as RC2 or DES), the encryption and MAC\r
+ functions convert TLSCompressed.fragment structures to and from block\r
+ TLSCiphertext.fragment structures.\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 21] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ block-ciphered struct {\r
+ opaque IV[CipherSpec.block_length]; |\r
+ opaque content[TLSCompressed.length];\r
+ opaque MAC[CipherSpec.hash_size];\r
+ uint8 padding[GenericBlockCipher.padding_length];\r
+ uint8 padding_length;\r
+ } GenericBlockCipher;\r
+\r
+\r
+ The MAC is generated as described in Section 6.2.3.1.\r
+\r
+\r
+ IV |\r
+ Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit |\r
+ IV in order to prevent the attacks described by [CBCATT]. |\r
+ We recommend the following equivalently strong procedures. |\r
+ For clarity we use the following notation. |\r
+\r
+\r
+ IV -- the transmitted value of the IV field in the |\r
+ GenericBlockCipher structure. |\r
+ CBC residue -- the last ciphertext block of the previous record |\r
+ mask -- the actual value which the cipher XORs with the |\r
+ plaintext prior to encryption of the first cipher block |\r
+ of the record. |\r
+\r
+\r
+ In prior versions of TLS, there was no IV field and the CBC residue|\r
+ and mask were one and the same. |\r
+\r
+\r
+\r
+ (1) Generate a cryptographically strong random string R of |\r
+ length CipherSpec.block_length. Place R |\r
+ in the IV field. Set the mask to R. Thus, the first |\r
+ cipher block will be encrypted as E(R XOR Data). |\r
+\r
+\r
+ (2) Generate a cryptographically strong random number R of |\r
+ length CipherSpec.block_length and prepend it to the plaintext|\r
+ prior to encryption. In |\r
+ this case either: |\r
+\r
+\r
+ (a) The cipher may use a fixed mask such as zero. |\r
+ (b) The CBC residue from the previous record may be used |\r
+ as the mask. This preserves maximum code compatibility |\r
+ with TLS 1.0 and SSL 3. It also has the advantage that |\r
+ it does not require the ability to quickly reset the IV, |\r
+ which is known to be a problem on some systems. |\r
+\r
+\r
+ In either case, the data (R || data) is fed into the |\r
+ encryption process. The first cipher block (containing |\r
+ E(mask XOR R) is placed in the IV field. The first |\r
+ block of content contains E(IV XOR data) |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 22] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ The following alternative procedure MAY be used: However, it has |\r
+ not been demonstrated to be equivalently cryptographically strong |\r
+ to the above procedures. The sender prepends a fixed block F to |\r
+ the plaintext (or alternatively a block generated with a weak |\r
+ PRNG). He then encrypts as in (2) above, using the CBC residue |\r
+ from the previous block as the mask for the prepended block. Note |\r
+ that in this case the mask for the first record transmitted by |\r
+ the application (the Finished) MUST be generated using a |\r
+ cryptographically strong PRNG. |\r
+\r
+\r
+ The decryption operation for all three alternatives is the same. |\r
+ The receiver decrypts the entire GenericBlockCipher structure and |\r
+ then discards the first cipher block, corresponding to the IV |\r
+ component. |\r
+\r
+\r
+ padding\r
+ Padding that is added to force the length of the plaintext to be\r
+ an integral multiple of the block cipher's block length. The |\r
+ padding MAY be any length up to 255 bytes long, as long as it\r
+ results in the TLSCiphertext.length being an integral multiple of\r
+ the block length. Lengths longer than necessary might be\r
+ desirable to frustrate attacks on a protocol based on analysis of\r
+ the lengths of exchanged messages. Each uint8 in the padding data |\r
+ vector MUST be filled with the padding length value. The receiver |\r
+ MUST check this padding and SHOULD use the bad_record_mac alert |\r
+ to indicate padding errors.\r
+\r
+\r
+ padding_length\r
+ The padding length MUST be such that the total size of the |\r
+ GenericBlockCipher structure is a multiple of the cipher's block\r
+ length. Legal values range from zero to 255, inclusive. This\r
+ length specifies the length of the padding field exclusive of the\r
+ padding_length field itself.\r
+\r
+\r
+ The encrypted data length (TLSCiphertext.length) is one more than the\r
+ sum of TLSCompressed.length, CipherSpec.hash_size, and\r
+ padding_length.\r
+\r
+\r
+ Example: If the block length is 8 bytes, the content length\r
+ (TLSCompressed.length) is 61 bytes, and the MAC length is 20 |\r
+ bytes, the length before padding is 82 bytes (this does not |\r
+ include the IV, which may or may not be encrypted, as |\r
+ discussed above). Thus, the padding length modulo 8 must be\r
+ equal to 6 in order to make the total length an even multiple\r
+ of 8 bytes (the block length). The padding length can be 6,\r
+ 14, 22, and so on, through 254. If the padding length were the\r
+ minimum necessary, 6, the padding would be 6 bytes, each\r
+ containing the value 6. Thus, the last 8 octets of the\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 23] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ GenericBlockCipher before block encryption would be xx 06 06\r
+ 06 06 06 06 06, where xx is the last octet of the MAC.\r
+\r
+\r
+ Note: With block ciphers in CBC mode (Cipher Block Chaining), |\r
+ it is critical that the entire plaintext of the record be known |\r
+ before any ciphertext is transmitted. Otherwise it is possible |\r
+ for the attacker to mount the attack described in [CBCATT]. |\r
+\r
+\r
+ Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a |\r
+ timing attack on CBC padding based on the time required to |\r
+ compute the MAC. In order to defend against this attack, |\r
+ implementations MUST ensure that record processing time is |\r
+ essentially the same whether or not the padding is correct. In |\r
+ general, the best way to to do this is to compute the MAC even if |\r
+ the padding is incorrect, and only then reject the packet. For |\r
+ instance, if the pad appears to be incorrect the implementation |\r
+ might assume a zero-length pad and then compute the MAC. This |\r
+ leaves a small timing channel, since MAC performance depends to |\r
+ some extent on the size of the data fragment, but it is not |\r
+ believed to be large enough to be exploitable due to the large |\r
+ block size of existing MACs and the small size of the timing |\r
+ signal.\r
+\r
+\r
+6.3. Key calculation\r
+\r
+\r
+ The Record Protocol requires an algorithm to generate keys, and MAC |\r
+ secrets from the security parameters provided by the handshake\r
+ protocol.\r
+\r
+\r
+ The master secret is hashed into a sequence of secure bytes, which |\r
+ are assigned to the MAC secrets and keys required by the current\r
+ connection state (see Appendix A.6). CipherSpecs require a client\r
+ write MAC secret, a server write MAC secret, a client write key, and |\r
+ a server write key, which are generated from the master secret in |\r
+ that order. Unused values are empty.\r
+\r
+\r
+ When generating keys and MAC secrets, the master secret is used as an\r
+ entropy source, and the random values provide unencrypted salt |\r
+ material for exportable ciphers.\r
+\r
+\r
+ To generate the key material, compute\r
+\r
+\r
+ key_block = PRF(SecurityParameters.master_secret,\r
+ "key expansion",\r
+ SecurityParameters.server_random +\r
+ SecurityParameters.client_random);\r
+\r
+\r
+ until enough output has been generated. Then the key_block is\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 24] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ partitioned as follows:\r
+\r
+\r
+ client_write_MAC_secret[SecurityParameters.hash_size]\r
+ server_write_MAC_secret[SecurityParameters.hash_size]\r
+ client_write_key[SecurityParameters.key_material_length]\r
+ server_write_key[SecurityParameters.key_material_length]\r
+\r
+\r
+\r
+ Implementation note:\r
+ The cipher spec which is defined in this document which requires\r
+ the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte |\r
+ keys, 2 x 20 byte MAC secrets, for a total 88 bytes of key |\r
+ material.\r
+\r
+\r
+ Exportable encryption algorithms (for which CipherSpec.is_exportable\r
+ is true) require additional processing as follows to derive their\r
+ final write keys:\r
+\r
+\r
+ final_client_write_key =\r
+ PRF(SecurityParameters.client_write_key,\r
+ "client write key",\r
+ SecurityParameters.client_random +\r
+ SecurityParameters.server_random);\r
+ final_server_write_key =\r
+ PRF(SecurityParameters.server_write_key,\r
+ "server write key",\r
+ SecurityParameters.client_random +\r
+ SecurityParameters.server_random);\r
+\r
+\r
+6.3.1. Export key generation example\r
+\r
+\r
+ TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for\r
+ each of the two encryption keys and 16 bytes for each of the MAC\r
+ keys, for a total of 42 bytes of key material. The PRF output is\r
+ stored in the key_block. The key_block is partitioned, and the write\r
+ keys are salted because this is an exportable encryption algorithm.\r
+\r
+\r
+ key_block = PRF(master_secret,\r
+ "key expansion",\r
+ server_random +\r
+ client_random)[0..41]\r
+ client_write_MAC_secret = key_block[0..15]\r
+ server_write_MAC_secret = key_block[16..31]\r
+ client_write_key = key_block[32..36]\r
+ server_write_key = key_block[37..41]\r
+ final_client_write_key = PRF(client_write_key,\r
+ "client write key",\r
+ client_random +\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 25] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ server_random)[0..15]\r
+ final_server_write_key = PRF(server_write_key,\r
+ "server write key",\r
+ client_random +\r
+ server_random)[0..15]\r
+\r
+\r
+\r
+7. The TLS Handshake Protocol\r
+\r
+\r
+ The TLS Handshake Protocol consists of a suite of three sub-protocols\r
+ which are used to allow peers to agree upon security parameters for\r
+ the record layer, authenticate themselves, instantiate negotiated\r
+ security parameters, and report error conditions to each other.\r
+\r
+\r
+ The Handshake Protocol is responsible for negotiating a session,\r
+ which consists of the following items:\r
+\r
+\r
+ session identifier\r
+ An arbitrary byte sequence chosen by the server to identify an\r
+ active or resumable session state.\r
+\r
+\r
+ peer certificate\r
+ X509v3 [X509] certificate of the peer. This element of the state\r
+ may be null.\r
+\r
+\r
+ compression method\r
+ The algorithm used to compress data prior to encryption.\r
+\r
+\r
+ cipher spec\r
+ Specifies the bulk data encryption algorithm (such as null, DES,\r
+ etc.) and a MAC algorithm (such as MD5 or SHA). It also defines\r
+ cryptographic attributes such as the hash_size. (See Appendix A.6\r
+ for formal definition)\r
+\r
+\r
+ master secret\r
+ 48-byte secret shared between the client and server.\r
+\r
+\r
+ is resumable\r
+ A flag indicating whether the session can be used to initiate new\r
+ connections.\r
+\r
+\r
+ These items are then used to create security parameters for use by\r
+ the Record Layer when protecting application data. Many connections\r
+ can be instantiated using the same session through the resumption\r
+ feature of the TLS Handshake Protocol.\r
+\r
+\r
+7.1. Change cipher spec protocol\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 26] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ The change cipher spec protocol exists to signal transitions in\r
+ ciphering strategies. The protocol consists of a single message,\r
+ which is encrypted and compressed under the current (not the pending)\r
+ connection state. The message consists of a single byte of value 1.\r
+\r
+\r
+ struct {\r
+ enum { change_cipher_spec(1), (255) } type;\r
+ } ChangeCipherSpec;\r
+\r
+\r
+ The change cipher spec message is sent by both the client and server\r
+ to notify the receiving party that subsequent records will be\r
+ protected under the newly negotiated CipherSpec and keys. Reception\r
+ of this message causes the receiver to instruct the Record Layer to\r
+ immediately copy the read pending state into the read current state. |\r
+ Immediately after sending this message, the sender MUST instruct the\r
+ record layer to make the write pending state the write active state.\r
+ (See section 6.1.) The change cipher spec message is sent during the\r
+ handshake after the security parameters have been agreed upon, but\r
+ before the verifying finished message is sent (see section 7.4.9).\r
+\r
+\r
+7.2. Alert protocol\r
+\r
+\r
+ One of the content types supported by the TLS Record layer is the\r
+ alert type. Alert messages convey the severity of the message and a\r
+ description of the alert. Alert messages with a level of fatal result\r
+ in the immediate termination of the connection. In this case, other\r
+ connections corresponding to the session may continue, but the |\r
+ session identifier MUST be invalidated, preventing the failed session\r
+ from being used to establish new connections. Like other messages,\r
+ alert messages are encrypted and compressed, as specified by the\r
+ current connection state.\r
+\r
+\r
+ enum { warning(1), fatal(2), (255) } AlertLevel;\r
+\r
+\r
+ enum {\r
+ close_notify(0),\r
+ unexpected_message(10),\r
+ bad_record_mac(20),\r
+ decryption_failed(21),\r
+ record_overflow(22),\r
+ decompression_failure(30),\r
+ handshake_failure(40),\r
+ no_certificate_RESERVED (41), |\r
+ bad_certificate(42),\r
+ unsupported_certificate(43),\r
+ certificate_revoked(44),\r
+ certificate_expired(45),\r
+ certificate_unknown(46),\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 27] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ illegal_parameter(47),\r
+ unknown_ca(48),\r
+ access_denied(49),\r
+ decode_error(50),\r
+ decrypt_error(51),\r
+ export_restriction(60),\r
+ protocol_version(70),\r
+ insufficient_security(71),\r
+ internal_error(80),\r
+ user_canceled(90),\r
+ no_renegotiation(100),\r
+ (255)\r
+ } AlertDescription;\r
+\r
+\r
+ struct {\r
+ AlertLevel level;\r
+ AlertDescription description;\r
+ } Alert;\r
+\r
+\r
+7.2.1. Closure alerts\r
+\r
+\r
+ The client and the server must share knowledge that the connection is\r
+ ending in order to avoid a truncation attack. Either party may\r
+ initiate the exchange of closing messages.\r
+\r
+\r
+ close_notify\r
+ This message notifies the recipient that the sender will not send |\r
+ any more messages on this connection. The session MUST not be |\r
+ resumed if any connection is terminated without proper\r
+ close_notify messages with level equal to warning.\r
+\r
+\r
+ Either party may initiate a close by sending a close_notify alert.\r
+ Any data received after a closure alert is ignored.\r
+\r
+\r
+ Unless some other fatal alert has been transmitted, each party is |\r
+ required to send a close_notify alert before closing the write side |\r
+ of the connection. The other party MUST respond with a close_notify |\r
+ alert of its own and close down the connection immediately,\r
+ discarding any pending writes. It is not required for the initiator\r
+ of the close to wait for the responding close_notify alert before\r
+ closing the read side of the connection.\r
+\r
+\r
+ If the application protocol using TLS provides that any data may be\r
+ carried over the underlying transport after the TLS connection is\r
+ closed, the TLS implementation must receive the responding\r
+ close_notify alert before indicating to the application layer that\r
+ the TLS connection has ended. If the application protocol will not\r
+ transfer any additional data, but will only close the underlying |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 28] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ transport connection, then the implementation MAY choose to close the\r
+ transport without waiting for the responding close_notify. No part of\r
+ this standard should be taken to dictate the manner in which a usage\r
+ profile for TLS manages its data transport, including when\r
+ connections are opened or closed.\r
+\r
+\r
+ NB: It is assumed that closing a connection reliably delivers\r
+ pending data before destroying the transport.\r
+\r
+\r
+7.2.2. Error alerts\r
+\r
+\r
+ Error handling in the TLS Handshake protocol is very simple. When an\r
+ error is detected, the detecting party sends a message to the other\r
+ party. Upon transmission or receipt of an fatal alert message, both |\r
+ parties immediately close the connection. Servers and clients MUST |\r
+ forget any session-identifiers, keys, and secrets associated with a\r
+ failed connection. The following error alerts are defined:\r
+\r
+\r
+ unexpected_message\r
+ An inappropriate message was received. This alert is always fatal\r
+ and should never be observed in communication between proper\r
+ implementations.\r
+\r
+\r
+ bad_record_mac\r
+ This alert is returned if a record is received with an incorrect |\r
+ MAC. This alert also SHOULD be returned if a TLSCiphertext |\r
+ decrypted in an invalid way: either it wasn't an even multiple of |\r
+ the block length, or its padding values, when checked, weren't |\r
+ correct. This message is always fatal.\r
+\r
+\r
+ decryption_failed\r
+ This alert MAY be returned if a TLSCiphertext decrypted in an |\r
+ invalid way: either it wasn't an even multiple of the block |\r
+ length, or its padding values, when checked, weren't correct. |\r
+ This message is always fatal. |\r
+\r
+\r
+ NB: Differentiating between bad_record_mac and decryption_failed |\r
+ alerts may permit certain attacks against CBC mode as used in TLS |\r
+ [CBCATT]. It is preferable to uniformly use the bad_record_mac |\r
+ alert to hide the specific type of the error. |\r
+\r
+\r
+\r
+ record_overflow\r
+ A TLSCiphertext record was received which had a length more than\r
+ 2^14+2048 bytes, or a record decrypted to a TLSCompressed record\r
+ with more than 2^14+1024 bytes. This message is always fatal.\r
+\r
+\r
+ decompression_failure\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 29] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ The decompression function received improper input (e.g. data\r
+ that would expand to excessive length). This message is always\r
+ fatal.\r
+\r
+\r
+ handshake_failure\r
+ Reception of a handshake_failure alert message indicates that the\r
+ sender was unable to negotiate an acceptable set of security\r
+ parameters given the options available. This is a fatal error.\r
+\r
+\r
+ no_certificate_RESERVED |\r
+ This alert was used in SSLv3 but not in TLS. It should not be |\r
+ sent by compliant implementations. |\r
+\r
+\r
+ bad_certificate\r
+ A certificate was corrupt, contained signatures that did not\r
+ verify correctly, etc.\r
+\r
+\r
+ unsupported_certificate\r
+ A certificate was of an unsupported type.\r
+\r
+\r
+ certificate_revoked\r
+ A certificate was revoked by its signer.\r
+\r
+\r
+ certificate_expired\r
+ A certificate has expired or is not currently valid.\r
+\r
+\r
+ certificate_unknown\r
+ Some other (unspecified) issue arose in processing the\r
+ certificate, rendering it unacceptable.\r
+\r
+\r
+ illegal_parameter\r
+ A field in the handshake was out of range or inconsistent with\r
+ other fields. This is always fatal.\r
+\r
+\r
+ unknown_ca\r
+ A valid certificate chain or partial chain was received, but the\r
+ certificate was not accepted because the CA certificate could not |\r
+ be located or couldn't be matched with a known, trusted CA. This\r
+ message is always fatal.\r
+\r
+\r
+ access_denied\r
+ A valid certificate was received, but when access control was\r
+ applied, the sender decided not to proceed with negotiation.\r
+ This message is always fatal.\r
+\r
+\r
+ decode_error\r
+ A message could not be decoded because some field was out of the\r
+ specified range or the length of the message was incorrect. This\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 30] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ message is always fatal.\r
+\r
+\r
+ decrypt_error\r
+ A handshake cryptographic operation failed, including being\r
+ unable to correctly verify a signature, decrypt a key exchange,\r
+ or validate a finished message.\r
+\r
+\r
+ export_restriction\r
+ A negotiation not in compliance with export restrictions was\r
+ detected; for example, attempting to transfer a 1024 bit\r
+ ephemeral RSA key for the RSA_EXPORT handshake method. This\r
+ message is always fatal.\r
+\r
+\r
+ protocol_version\r
+ The protocol version the client has attempted to negotiate is\r
+ recognized, but not supported. (For example, old protocol\r
+ versions might be avoided for security reasons). This message is\r
+ always fatal.\r
+\r
+\r
+ insufficient_security\r
+ Returned instead of handshake_failure when a negotiation has\r
+ failed specifically because the server requires ciphers more\r
+ secure than those supported by the client. This message is always\r
+ fatal.\r
+\r
+\r
+ internal_error\r
+ An internal error unrelated to the peer or the correctness of the\r
+ protocol makes it impossible to continue (such as a memory\r
+ allocation failure). This message is always fatal.\r
+\r
+\r
+ user_canceled\r
+ This handshake is being canceled for some reason unrelated to a\r
+ protocol failure. If the user cancels an operation after the\r
+ handshake is complete, just closing the connection by sending a\r
+ close_notify is more appropriate. This alert should be followed\r
+ by a close_notify. This message is generally a warning.\r
+\r
+\r
+ no_renegotiation\r
+ Sent by the client in response to a hello request or by the\r
+ server in response to a client hello after initial handshaking.\r
+ Either of these would normally lead to renegotiation; when that\r
+ is not appropriate, the recipient should respond with this alert;\r
+ at that point, the original requester can decide whether to\r
+ proceed with the connection. One case where this would be\r
+ appropriate would be where a server has spawned a process to\r
+ satisfy a request; the process might receive security parameters\r
+ (key length, authentication, etc.) at startup and it might be\r
+ difficult to communicate changes to these parameters after that\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 31] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ point. This message is always a warning.\r
+\r
+\r
+ For all errors where an alert level is not explicitly specified, the |\r
+ sending party MAY determine at its discretion whether this is a fatal\r
+ error or not; if an alert with a level of warning is received, the\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 32] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ receiving party MAY decide at its discretion whether to treat this as |\r
+ a fatal error or not. However, all messages which are transmitted |\r
+ with a level of fatal MUST be treated as fatal messages.\r
+\r
+\r
+7.3. Handshake Protocol overview\r
+\r
+\r
+ The cryptographic parameters of the session state are produced by the\r
+ TLS Handshake Protocol, which operates on top of the TLS Record\r
+ Layer. When a TLS client and server first start communicating, they\r
+ agree on a protocol version, select cryptographic algorithms,\r
+ optionally authenticate each other, and use public-key encryption\r
+ techniques to generate shared secrets.\r
+\r
+\r
+ The TLS Handshake Protocol involves the following steps:\r
+\r
+\r
+ - - Exchange hello messages to agree on algorithms, exchange random\r
+ values, and check for session resumption.\r
+\r
+\r
+ - - Exchange the necessary cryptographic parameters to allow the\r
+ client and server to agree on a premaster secret.\r
+\r
+\r
+ - - Exchange certificates and cryptographic information to allow\r
+ the client and server to authenticate themselves.\r
+\r
+\r
+ - - Generate a master secret from the premaster secret and\r
+ exchanged random values.\r
+\r
+\r
+ - - Provide security parameters to the record layer.\r
+\r
+\r
+ - - Allow the client and server to verify that their peer has\r
+ calculated the same security parameters and that the handshake\r
+ occurred without tampering by an attacker.\r
+\r
+\r
+ Note that higher layers should not be overly reliant on TLS always\r
+ negotiating the strongest possible connection between two peers:\r
+ there are a number of ways a man in the middle attacker can attempt\r
+ to make two entities drop down to the least secure method they\r
+ support. The protocol has been designed to minimize this risk, but\r
+ there are still attacks available: for example, an attacker could\r
+ block access to the port a secure service runs on, or attempt to get\r
+ the peers to negotiate an unauthenticated connection. The fundamental\r
+ rule is that higher levels must be cognizant of what their security\r
+ requirements are and never transmit information over a channel less\r
+ secure than what they require. The TLS protocol is secure, in that\r
+ any cipher suite offers its promised level of security: if you\r
+ negotiate 3DES with a 1024 bit RSA key exchange with a host whose\r
+ certificate you have verified, you can expect to be that secure.\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 33] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ However, you SHOULD never send data over a link encrypted with 40 bit |\r
+ security unless you feel that data is worth no more than the effort\r
+ required to break that encryption.\r
+\r
+\r
+ These goals are achieved by the handshake protocol, which can be\r
+ summarized as follows: The client sends a client hello message to\r
+ which the server must respond with a server hello message, or else a\r
+ fatal error will occur and the connection will fail. The client hello\r
+ and server hello are used to establish security enhancement\r
+ capabilities between client and server. The client hello and server\r
+ hello establish the following attributes: Protocol Version, Session\r
+ ID, Cipher Suite, and Compression Method. Additionally, two random\r
+ values are generated and exchanged: ClientHello.random and\r
+ ServerHello.random.\r
+\r
+\r
+ The actual key exchange uses up to four messages: the server\r
+ certificate, the server key exchange, the client certificate, and the\r
+ client key exchange. New key exchange methods can be created by\r
+ specifying a format for these messages and defining the use of the\r
+ messages to allow the client and server to agree upon a shared |\r
+ secret. This secret MUST be quite long; currently defined key\r
+ exchange methods exchange secrets which range from 48 to 128 bytes in\r
+ length.\r
+\r
+\r
+ Following the hello messages, the server will send its certificate,\r
+ if it is to be authenticated. Additionally, a server key exchange\r
+ message may be sent, if it is required (e.g. if their server has no\r
+ certificate, or if its certificate is for signing only). If the\r
+ server is authenticated, it may request a certificate from the\r
+ client, if that is appropriate to the cipher suite selected. Now the\r
+ server will send the server hello done message, indicating that the\r
+ hello-message phase of the handshake is complete. The server will\r
+ then wait for a client response. If the server has sent a certificate\r
+ request message, the client must send the certificate message. The\r
+ client key exchange message is now sent, and the content of that\r
+ message will depend on the public key algorithm selected between the\r
+ client hello and the server hello. If the client has sent a\r
+ certificate with signing ability, a digitally-signed certificate\r
+ verify message is sent to explicitly verify the certificate.\r
+\r
+\r
+ At this point, a change cipher spec message is sent by the client,\r
+ and the client copies the pending Cipher Spec into the current Cipher\r
+ Spec. The client then immediately sends the finished message under\r
+ the new algorithms, keys, and secrets. In response, the server will\r
+ send its own change cipher spec message, transfer the pending to the\r
+ current Cipher Spec, and send its finished message under the new\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 34] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Cipher Spec. At this point, the handshake is complete and the client\r
+ and server may begin to exchange application layer data. (See flow\r
+ chart below.)\r
+\r
+\r
+ Client Server\r
+\r
+\r
+ ClientHello -------->\r
+ ServerHello\r
+ Certificate*\r
+ ServerKeyExchange*\r
+ CertificateRequest*\r
+ <-------- ServerHelloDone\r
+ Certificate*\r
+ ClientKeyExchange\r
+ CertificateVerify*\r
+ [ChangeCipherSpec]\r
+ Finished -------->\r
+ [ChangeCipherSpec]\r
+ <-------- Finished\r
+ Application Data <-------> Application Data\r
+\r
+\r
+ Fig. 1 - Message flow for a full handshake\r
+\r
+\r
+ * Indicates optional or situation-dependent messages that are not\r
+ always sent.\r
+\r
+\r
+ Note: To help avoid pipeline stalls, ChangeCipherSpec is an\r
+ independent TLS Protocol content type, and is not actually a TLS\r
+ handshake message.\r
+\r
+\r
+ When the client and server decide to resume a previous session or\r
+ duplicate an existing session (instead of negotiating new security\r
+ parameters) the message flow is as follows:\r
+\r
+\r
+ The client sends a ClientHello using the Session ID of the session to\r
+ be resumed. The server then checks its session cache for a match. If\r
+ a match is found, and the server is willing to re-establish the\r
+ connection under the specified session state, it will send a\r
+ ServerHello with the same Session ID value. At this point, both |\r
+ client and server MUST send change cipher spec messages and proceed\r
+ directly to finished messages. Once the re-establishment is complete, |\r
+ the client and server MAY begin to exchange application layer data.\r
+ (See flow chart below.) If a Session ID match is not found, the\r
+ server generates a new session ID and the TLS client and server\r
+ perform a full handshake.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 35] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Client Server\r
+\r
+\r
+ ClientHello -------->\r
+ ServerHello\r
+ [ChangeCipherSpec]\r
+ <-------- Finished\r
+ [ChangeCipherSpec]\r
+ Finished -------->\r
+ Application Data <-------> Application Data\r
+\r
+\r
+ Fig. 2 - Message flow for an abbreviated handshake\r
+\r
+\r
+ The contents and significance of each message will be presented in\r
+ detail in the following sections.\r
+\r
+\r
+7.4. Handshake protocol\r
+\r
+\r
+ The TLS Handshake Protocol is one of the defined higher level clients\r
+ of the TLS Record Protocol. This protocol is used to negotiate the\r
+ secure attributes of a session. Handshake messages are supplied to\r
+ the TLS Record Layer, where they are encapsulated within one or more\r
+ TLSPlaintext structures, which are processed and transmitted as\r
+ specified by the current active session state.\r
+\r
+\r
+ enum {\r
+ hello_request(0), client_hello(1), server_hello(2),\r
+ certificate(11), server_key_exchange (12),\r
+ certificate_request(13), server_hello_done(14),\r
+ certificate_verify(15), client_key_exchange(16),\r
+ finished(20), (255)\r
+ } HandshakeType;\r
+\r
+\r
+ struct {\r
+ HandshakeType msg_type; /* handshake type */\r
+ uint24 length; /* bytes in message */\r
+ select (HandshakeType) {\r
+ case hello_request: HelloRequest;\r
+ case client_hello: ClientHello;\r
+ case server_hello: ServerHello;\r
+ case certificate: Certificate;\r
+ case server_key_exchange: ServerKeyExchange;\r
+ case certificate_request: CertificateRequest;\r
+ case server_hello_done: ServerHelloDone;\r
+ case certificate_verify: CertificateVerify;\r
+ case client_key_exchange: ClientKeyExchange;\r
+ case finished: Finished;\r
+ } body;\r
+ } Handshake;\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 36] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ The handshake protocol messages are presented below in the order they |\r
+ MUST be sent; sending handshake messages in an unexpected order\r
+ results in a fatal error. Unneeded handshake messages can be omitted,\r
+ however. Note one exception to the ordering: the Certificate message\r
+ is used twice in the handshake (from server to client, then from\r
+ client to server), but described only in its first position. The one\r
+ message which is not bound by these ordering rules is the Hello |\r
+ Request message, which can be sent at any time, but which should be\r
+ ignored by the client if it arrives in the middle of a handshake.\r
+\r
+\r
+7.4.1. Hello messages\r
+\r
+\r
+ The hello phase messages are used to exchange security enhancement\r
+ capabilities between the client and server. When a new session\r
+ begins, the Record Layer's connection state encryption, hash, and\r
+ compression algorithms are initialized to null. The current\r
+ connection state is used for renegotiation messages.\r
+\r
+\r
+7.4.1.1. Hello request\r
+\r
+\r
+ When this message will be sent:\r
+ The hello request message MAY be sent by the server at any time. |\r
+\r
+\r
+ Meaning of this message:\r
+ Hello request is a simple notification that the client should\r
+ begin the negotiation process anew by sending a client hello\r
+ message when convenient. This message will be ignored by the\r
+ client if the client is currently negotiating a session. This\r
+ message may be ignored by the client if it does not wish to\r
+ renegotiate a session, or the client may, if it wishes, respond\r
+ with a no_renegotiation alert. Since handshake messages are\r
+ intended to have transmission precedence over application data,\r
+ it is expected that the negotiation will begin before no more\r
+ than a few records are received from the client. If the server\r
+ sends a hello request but does not receive a client hello in\r
+ response, it may close the connection with a fatal alert.\r
+\r
+\r
+ After sending a hello request, servers SHOULD not repeat the request |\r
+ until the subsequent handshake negotiation is complete.\r
+\r
+\r
+ Structure of this message:\r
+ struct { } HelloRequest;\r
+\r
+\r
+ Note: This message MUST NOT be included in the message hashes which are |\r
+ maintained throughout the handshake and used in the finished\r
+ messages and the certificate verify message.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 37] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+7.4.1.2. Client hello\r
+\r
+\r
+ When this message will be sent:\r
+ When a client first connects to a server it is required to send\r
+ the client hello as its first message. The client can also send a\r
+ client hello in response to a hello request or on its own\r
+ initiative in order to renegotiate the security parameters in an\r
+ existing connection.\r
+\r
+\r
+ Structure of this message:\r
+ The client hello message includes a random structure, which is\r
+ used later in the protocol.\r
+\r
+\r
+ struct {\r
+ uint32 gmt_unix_time;\r
+ opaque random_bytes[28];\r
+ } Random;\r
+\r
+\r
+ gmt_unix_time\r
+ The current time and date in standard UNIX 32-bit format (seconds\r
+ since the midnight starting Jan 1, 1970, GMT) according to the\r
+ sender's internal clock. Clocks are not required to be set\r
+ correctly by the basic TLS Protocol; higher level or application\r
+ protocols may define additional requirements.\r
+\r
+\r
+ random_bytes\r
+ 28 bytes generated by a secure random number generator.\r
+\r
+\r
+ The client hello message includes a variable length session |\r
+ identifier. If not empty, the value identifies a session between the\r
+ same client and server whose security parameters the client wishes to |\r
+ reuse. The session identifier MAY be from an earlier connection, this\r
+ connection, or another currently active connection. The second option\r
+ is useful if the client only wishes to update the random structures\r
+ and derived values of a connection, while the third option makes it\r
+ possible to establish several independent secure connections without\r
+ repeating the full handshake protocol. These independent connections\r
+ may occur sequentially or simultaneously; a SessionID becomes valid\r
+ when the handshake negotiating it completes with the exchange of\r
+ Finished messages and persists until removed due to aging or because\r
+ a fatal error was encountered on a connection associated with the\r
+ session. The actual contents of the SessionID are defined by the\r
+ server.\r
+\r
+\r
+ opaque SessionID<0..32>;\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 38] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Warning:\r
+ Because the SessionID is transmitted without encryption or |\r
+ immediate MAC protection, servers MUST not place confidential\r
+ information in session identifiers or let the contents of fake\r
+ session identifiers cause any breach of security. (Note that the\r
+ content of the handshake as a whole, including the SessionID, is\r
+ protected by the Finished messages exchanged at the end of the\r
+ handshake.)\r
+\r
+\r
+ The CipherSuite list, passed from the client to the server in the |\r
+ client hello message, contains the combinations of cryptographic\r
+ algorithms supported by the client in order of the client's\r
+ preference (favorite choice first). Each CipherSuite defines a key\r
+ exchange algorithm, a bulk encryption algorithm (including secret key\r
+ length) and a MAC algorithm. The server will select a cipher suite\r
+ or, if no acceptable choices are presented, return a handshake\r
+ failure alert and close the connection.\r
+\r
+\r
+ uint8 CipherSuite[2]; /* Cryptographic suite selector */\r
+\r
+\r
+ The client hello includes a list of compression algorithms supported\r
+ by the client, ordered according to the client's preference.\r
+\r
+\r
+ enum { null(0), (255) } CompressionMethod;\r
+\r
+\r
+ struct {\r
+ ProtocolVersion client_version;\r
+ Random random;\r
+ SessionID session_id;\r
+ CipherSuite cipher_suites<2..2^16-1>;\r
+ CompressionMethod compression_methods<1..2^8-1>;\r
+ } ClientHello;\r
+\r
+\r
+ client_version\r
+ The version of the TLS protocol by which the client wishes to |\r
+ communicate during this session. This SHOULD be the latest\r
+ (highest valued) version supported by the client. For this |\r
+ version of the specification, the version will be 3.2 (See\r
+ Appendix E for details about backward compatibility).\r
+\r
+\r
+ random\r
+ A client-generated random structure.\r
+\r
+\r
+ session_id\r
+ The ID of a session the client wishes to use for this connection.\r
+ This field should be empty if no session_id is available or the\r
+ client wishes to generate new security parameters.\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 39] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ cipher_suites\r
+ This is a list of the cryptographic options supported by the\r
+ client, with the client's first preference first. If the\r
+ session_id field is not empty (implying a session resumption |\r
+ request) this vector MUST include at least the cipher_suite from\r
+ that session. Values are defined in Appendix A.5.\r
+\r
+\r
+ compression_methods\r
+ This is a list of the compression methods supported by the\r
+ client, sorted by client preference. If the session_id field is\r
+ not empty (implying a session resumption request) it must include\r
+ the compression_method from that session. This vector must\r
+ contain, and all implementations must support,\r
+ CompressionMethod.null. Thus, a client and server will always be\r
+ able to agree on a compression method.\r
+\r
+\r
+ After sending the client hello message, the client waits for a server\r
+ hello message. Any other handshake message returned by the server\r
+ except for a hello request is treated as a fatal error.\r
+\r
+\r
+ Forward compatibility note:\r
+ In the interests of forward compatibility, it is permitted for a\r
+ client hello message to include extra data after the compression |\r
+ methods. This data MUST be included in the handshake hashes, but\r
+ must otherwise be ignored. This is the only handshake message for\r
+ which this is legal; for all other messages, the amount of data |\r
+ in the message MUST match the description of the message\r
+ precisely.\r
+\r
+\r
+Note: For the intended use of trailing data in the ClientHello, see RFC |\r
+ 3546 [TLSEXT]. |\r
+\r
+\r
+7.4.1.3. Server hello\r
+\r
+\r
+ When this message will be sent:\r
+ The server will send this message in response to a client hello\r
+ message when it was able to find an acceptable set of algorithms.\r
+ If it cannot find such a match, it will respond with a handshake\r
+ failure alert.\r
+\r
+\r
+ Structure of this message:\r
+ struct {\r
+ ProtocolVersion server_version;\r
+ Random random;\r
+ SessionID session_id;\r
+ CipherSuite cipher_suite;\r
+ CompressionMethod compression_method;\r
+ } ServerHello;\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 40] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ server_version\r
+ This field will contain the lower of that suggested by the client\r
+ in the client hello and the highest supported by the server. For\r
+ this version of the specification, the version is 3.2 (See |\r
+ Appendix E for details about backward compatibility).\r
+\r
+\r
+ random\r
+ This structure is generated by the server and MUST be |\r
+ independently generated from the ClientHello.random.\r
+\r
+\r
+ session_id\r
+ This is the identity of the session corresponding to this\r
+ connection. If the ClientHello.session_id was non-empty, the\r
+ server will look in its session cache for a match. If a match is\r
+ found and the server is willing to establish the new connection\r
+ using the specified session state, the server will respond with\r
+ the same value as was supplied by the client. This indicates a\r
+ resumed session and dictates that the parties must proceed\r
+ directly to the finished messages. Otherwise this field will\r
+ contain a different value identifying the new session. The server\r
+ may return an empty session_id to indicate that the session will\r
+ not be cached and therefore cannot be resumed. If a session is\r
+ resumed, it must be resumed using the same cipher suite it was\r
+ originally negotiated with.\r
+\r
+\r
+ cipher_suite\r
+ The single cipher suite selected by the server from the list in\r
+ ClientHello.cipher_suites. For resumed sessions this field is the\r
+ value from the state of the session being resumed.\r
+\r
+\r
+ compression_method |\r
+ The single compression algorithm selected by the server from the\r
+ list in ClientHello.compression_methods. For resumed sessions\r
+ this field is the value from the resumed session state.\r
+\r
+\r
+7.4.2. Server certificate\r
+\r
+\r
+ When this message will be sent:\r
+ The server MUST send a certificate whenever the agreed-upon key |\r
+ exchange method is not an anonymous one. This message will always\r
+ immediately follow the server hello message.\r
+\r
+\r
+ Meaning of this message:\r
+ The certificate type MUST be appropriate for the selected cipher |\r
+ suite's key exchange algorithm, and is generally an X.509v3 |\r
+ certificate. It MUST contain a key which matches the key exchange\r
+ method, as follows. Unless otherwise specified, the signing\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 41] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ algorithm for the certificate MUST be the same as the algorithm |\r
+ for the certificate key. Unless otherwise specified, the public |\r
+ key MAY be of any length.\r
+\r
+\r
+ Key Exchange Algorithm Certificate Key Type\r
+\r
+\r
+ RSA RSA public key; the certificate MUST |\r
+ allow the key to be used for encryption.\r
+\r
+\r
+ RSA_EXPORT RSA public key of length greater than\r
+ 512 bits which can be used for signing,\r
+ or a key of 512 bits or shorter which\r
+ can be used for encryption. |\r
+\r
+\r
+ DHE_DSS DSS public key.\r
+\r
+\r
+ DHE_DSS_EXPORT DSS public key.\r
+\r
+\r
+ DHE_RSA RSA public key which can be used for\r
+ signing.\r
+\r
+\r
+ DHE_RSA_EXPORT RSA public key which can be used for\r
+ signing.\r
+\r
+\r
+ DH_DSS Diffie-Hellman key. The algorithm used\r
+ to sign the certificate MUST be DSS. |\r
+\r
+\r
+ DH_RSA Diffie-Hellman key. The algorithm used\r
+ to sign the certificate MUST be RSA. |\r
+\r
+\r
+ All certificate profiles, key and cryptographic formats are defined\r
+ by the IETF PKIX working group [PKIX]. When a key usage extension is |\r
+ present, the digitalSignature bit MUST be set for the key to be\r
+ eligible for signing, as described above, and the keyEncipherment bit |\r
+ MUST be present to allow encryption, as described above. The\r
+ keyAgreement bit must be set on Diffie-Hellman certificates.\r
+\r
+\r
+ As CipherSuites which specify new key exchange methods are specified\r
+ for the TLS Protocol, they will imply certificate format and the\r
+ required encoded keying information.\r
+\r
+\r
+ Structure of this message:\r
+ opaque ASN.1Cert<1..2^24-1>;\r
+\r
+\r
+ struct {\r
+ ASN.1Cert certificate_list<0..2^24-1>;\r
+ } Certificate;\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 42] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ certificate_list\r
+ This is a sequence (chain) of X.509v3 certificates. The sender's\r
+ certificate must come first in the list. Each following\r
+ certificate must directly certify the one preceding it. Because\r
+ certificate validation requires that root keys be distributed\r
+ independently, the self-signed certificate which specifies the\r
+ root certificate authority may optionally be omitted from the\r
+ chain, under the assumption that the remote end must already\r
+ possess it in order to validate it in any case.\r
+\r
+\r
+ The same message type and structure will be used for the client's |\r
+ response to a certificate request message. Note that a client MAY\r
+ send no certificates if it does not have an appropriate certificate\r
+ to send in response to the server's authentication request.\r
+\r
+\r
+ Note: PKCS #7 [PKCS7] is not used as the format for the certificate\r
+ vector because PKCS #6 [PKCS6] extended certificates are not\r
+ used. Also PKCS #7 defines a SET rather than a SEQUENCE, making\r
+ the task of parsing the list more difficult.\r
+\r
+\r
+7.4.3. Server key exchange message\r
+\r
+\r
+ When this message will be sent:\r
+ This message will be sent immediately after the server\r
+ certificate message (or the server hello message, if this is an\r
+ anonymous negotiation).\r
+\r
+\r
+ The server key exchange message is sent by the server only when\r
+ the server certificate message (if sent) does not contain enough\r
+ data to allow the client to exchange a premaster secret. This is\r
+ true for the following key exchange methods:\r
+\r
+\r
+ RSA_EXPORT (if the public key in the server certificate is\r
+ longer than 512 bits)\r
+ DHE_DSS\r
+ DHE_DSS_EXPORT\r
+ DHE_RSA\r
+ DHE_RSA_EXPORT\r
+ DH_anon\r
+\r
+\r
+ It is not legal to send the server key exchange message for the\r
+ following key exchange methods:\r
+\r
+\r
+ RSA\r
+ RSA_EXPORT (when the public key in the server certificate is\r
+ less than or equal to 512 bits in length)\r
+ DH_DSS\r
+ DH_RSA\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 43] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Meaning of this message:\r
+ This message conveys cryptographic information to allow the\r
+ client to communicate the premaster secret: either an RSA public\r
+ key to encrypt the premaster secret with, or a Diffie-Hellman\r
+ public key with which the client can complete a key exchange\r
+ (with the result being the premaster secret.)\r
+\r
+\r
+ As additional CipherSuites are defined for TLS which include new key |\r
+ exchange algorithms, the server key exchange message will be sent if\r
+ and only if the certificate type associated with the key exchange\r
+ algorithm does not provide enough information for the client to\r
+ exchange a premaster secret.\r
+\r
+\r
+ Note: According to current US export law, RSA moduli larger than 512\r
+ bits may not be used for key exchange in software exported from\r
+ the US. With this message, the larger RSA keys encoded in\r
+ certificates may be used to sign temporary shorter RSA keys for\r
+ the RSA_EXPORT key exchange method.\r
+\r
+\r
+ Structure of this message:\r
+ enum { rsa, diffie_hellman } KeyExchangeAlgorithm;\r
+\r
+\r
+ struct {\r
+ opaque rsa_modulus<1..2^16-1>;\r
+ opaque rsa_exponent<1..2^16-1>;\r
+ } ServerRSAParams;\r
+\r
+\r
+ rsa_modulus\r
+ The modulus of the server's temporary RSA key.\r
+\r
+\r
+ rsa_exponent\r
+ The public exponent of the server's temporary RSA key.\r
+\r
+\r
+ struct {\r
+ opaque dh_p<1..2^16-1>;\r
+ opaque dh_g<1..2^16-1>;\r
+ opaque dh_Ys<1..2^16-1>;\r
+ } ServerDHParams; /* Ephemeral DH parameters */\r
+\r
+\r
+ dh_p\r
+ The prime modulus used for the Diffie-Hellman operation.\r
+\r
+\r
+ dh_g\r
+ The generator used for the Diffie-Hellman operation.\r
+\r
+\r
+ dh_Ys\r
+ The server's Diffie-Hellman public value (g^X mod p).\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 44] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ struct {\r
+ select (KeyExchangeAlgorithm) {\r
+ case diffie_hellman:\r
+ ServerDHParams params;\r
+ Signature signed_params;\r
+ case rsa:\r
+ ServerRSAParams params;\r
+ Signature signed_params;\r
+ };\r
+ } ServerKeyExchange;\r
+\r
+\r
+ struct { |\r
+ select (KeyExchangeAlgorithm) { |\r
+ case diffie_hellman: |\r
+ ServerDHParams params; |\r
+ case rsa: |\r
+ ServerRSAParams params; |\r
+ }; |\r
+ } ServerParams; |\r
+\r
+\r
+ params\r
+ The server's key exchange parameters.\r
+\r
+\r
+ signed_params\r
+ For non-anonymous key exchanges, a hash of the corresponding\r
+ params value, with the signature appropriate to that hash\r
+ applied.\r
+\r
+\r
+ md5_hash\r
+ MD5(ClientHello.random + ServerHello.random + ServerParams);\r
+\r
+\r
+ sha_hash\r
+ SHA(ClientHello.random + ServerHello.random + ServerParams);\r
+\r
+\r
+ enum { anonymous, rsa, dsa } SignatureAlgorithm;\r
+\r
+\r
+\r
+ select (SignatureAlgorithm) |\r
+ { |\r
+ case anonymous: struct { }; |\r
+ case rsa:\r
+ digitally-signed struct {\r
+ opaque md5_hash[16];\r
+ opaque sha_hash[20];\r
+ };\r
+ case dsa:\r
+ digitally-signed struct {\r
+ opaque sha_hash[20];\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 45] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ };\r
+ } Signature;\r
+\r
+\r
+7.4.4. Certificate request\r
+\r
+\r
+ When this message will be sent:\r
+ A non-anonymous server can optionally request a certificate from\r
+ the client, if appropriate for the selected cipher suite. This\r
+ message, if sent, will immediately follow the Server Key Exchange\r
+ message (if it is sent; otherwise, the Server Certificate\r
+ message).\r
+\r
+\r
+ Structure of this message:\r
+ enum {\r
+ rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),\r
+ rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), |\r
+ fortezza_dms_RESERVED(20), |\r
+ (255)\r
+ } ClientCertificateType;\r
+\r
+\r
+ opaque DistinguishedName<1..2^16-1>;\r
+\r
+\r
+ struct {\r
+ ClientCertificateType certificate_types<1..2^8-1>;\r
+ DistinguishedName certificate_authorities<0..2^16-1>; |\r
+ } CertificateRequest;\r
+\r
+\r
+ certificate_types\r
+ This field is a list of the types of certificates requested, |\r
+ sorted in order of the server's preference. |\r
+\r
+\r
+ certificate_authorities\r
+ A list of the distinguished names of acceptable certificate\r
+ authorities. These distinguished names may specify a desired\r
+ distinguished name for a root CA or for a subordinate CA;\r
+ thus, this message can be used both to describe known roots |\r
+ and a desired authorization space. If the |\r
+ certificate_authorities list is empty then the client MAY |\r
+ send any certificate of the appropriate |\r
+ ClientCertificateType, unless there is some external |\r
+ arrangement to the contrary. |\r
+\r
+\r
+\r
+ Note: Values listed as RESERVED may not be used. They were used in |\r
+ SSLv3.\r
+\r
+\r
+ Note: DistinguishedName is derived from [X509].\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 46] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Note: It is a fatal handshake_failure alert for an anonymous server to\r
+ request client authentication. |\r
+\r
+\r
+7.4.5. Server hello done\r
+\r
+\r
+ When this message will be sent:\r
+ The server hello done message is sent by the server to indicate\r
+ the end of the server hello and associated messages. After\r
+ sending this message the server will wait for a client response.\r
+\r
+\r
+ Meaning of this message:\r
+ This message means that the server is done sending messages to\r
+ support the key exchange, and the client can proceed with its\r
+ phase of the key exchange.\r
+\r
+\r
+ Upon receipt of the server hello done message the client SHOULD |\r
+ verify that the server provided a valid certificate if required\r
+ and check that the server hello parameters are acceptable.\r
+\r
+\r
+ Structure of this message:\r
+ struct { } ServerHelloDone;\r
+\r
+\r
+7.4.6. Client certificate\r
+\r
+\r
+ When this message will be sent:\r
+ This is the first message the client can send after receiving a\r
+ server hello done message. This message is only sent if the\r
+ server requests a certificate. If no suitable certificate is\r
+ available, the client should send a certificate message |\r
+ containing no certificates: I.e. the certificate_list structure |\r
+ should have a length of zero. If client authentication is |\r
+ required by the server for the handshake to continue, it may\r
+ respond with a fatal handshake failure alert. Client certificates\r
+ are sent using the Certificate structure defined in Section\r
+ 7.4.2.\r
+\r
+\r
+\r
+ Note: When using a static Diffie-Hellman based key exchange method |\r
+ (DH_DSS or DH_RSA), if client authentication is requested, the\r
+ Diffie-Hellman group and generator encoded in the client's\r
+ certificate must match the server specified Diffie-Hellman\r
+ parameters if the client's parameters are to be used for the key\r
+ exchange.\r
+\r
+\r
+7.4.7. Client key exchange message\r
+\r
+\r
+ When this message will be sent:\r
+ This message is always sent by the client. It will immediately\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 47] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ follow the client certificate message, if it is sent. Otherwise\r
+ it will be the first message sent by the client after it receives\r
+ the server hello done message.\r
+\r
+\r
+ Meaning of this message:\r
+ With this message, the premaster secret is set, either though\r
+ direct transmission of the RSA-encrypted secret, or by the\r
+ transmission of Diffie-Hellman parameters which will allow each\r
+ side to agree upon the same premaster secret. When the key\r
+ exchange method is DH_RSA or DH_DSS, client certification has\r
+ been requested, and the client was able to respond with a\r
+ certificate which contained a Diffie-Hellman public key whose\r
+ parameters (group and generator) matched those specified by the |\r
+ server in its certificate, this message MUST not contain any\r
+ data.\r
+\r
+\r
+ Structure of this message:\r
+ The choice of messages depends on which key exchange method has\r
+ been selected. See Section 7.4.3 for the KeyExchangeAlgorithm\r
+ definition.\r
+\r
+\r
+ struct {\r
+ select (KeyExchangeAlgorithm) {\r
+ case rsa: EncryptedPreMasterSecret;\r
+ case diffie_hellman: ClientDiffieHellmanPublic;\r
+ } exchange_keys;\r
+ } ClientKeyExchange;\r
+\r
+\r
+7.4.7.1. RSA encrypted premaster secret message\r
+\r
+\r
+ Meaning of this message:\r
+ If RSA is being used for key agreement and authentication, the\r
+ client generates a 48-byte premaster secret, encrypts it using\r
+ the public key from the server's certificate or the temporary RSA\r
+ key provided in a server key exchange message, and sends the\r
+ result in an encrypted premaster secret message. This structure\r
+ is a variant of the client key exchange message, not a message in\r
+ itself.\r
+\r
+\r
+ Structure of this message:\r
+ struct {\r
+ ProtocolVersion client_version;\r
+ opaque random[46];\r
+ } PreMasterSecret;\r
+\r
+\r
+ client_version\r
+ The latest (newest) version supported by the client. This is\r
+ used to detect version roll-back attacks. Upon receiving the |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 48] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ premaster secret, the server SHOULD check that this value\r
+ matches the value transmitted by the client in the client\r
+ hello message.\r
+\r
+\r
+ random\r
+ 46 securely-generated random bytes.\r
+\r
+\r
+ struct {\r
+ public-key-encrypted PreMasterSecret pre_master_secret;\r
+ } EncryptedPreMasterSecret;\r
+\r
+\r
+ pre_master_secret |\r
+ This random value is generated by the client and is used to |\r
+ generate the master secret, as specified in Section 8.1. |\r
+\r
+\r
+ Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used\r
+ to attack a TLS server which is using PKCS#1 encoded RSA. The\r
+ attack takes advantage of the fact that by failing in different\r
+ ways, a TLS server can be coerced into revealing whether a\r
+ particular message, when decrypted, is properly PKCS#1 formatted\r
+ or not.\r
+\r
+\r
+ The best way to avoid vulnerability to this attack is to treat\r
+ incorrectly formatted messages in a manner indistinguishable from\r
+ correctly formatted RSA blocks. Thus, when it receives an\r
+ incorrectly formatted RSA block, a server should generate a\r
+ random 48-byte value and proceed using it as the premaster\r
+ secret. Thus, the server will act identically whether the |\r
+ received RSA block is correctly encoded or not. |\r
+\r
+\r
+ Implementation Note: public-key-encrypted data is represented as an |\r
+ opaque vector <0..2^16-1> (see S. 4.7). Thus the RSA-encrypted |\r
+ PreMaster Secret in a ClientKeyExchange is preceded by two length |\r
+ bytes. These bytes are redundant in the case of RSA because the |\r
+ EncryptedPreMasterSecret is the only data in the |\r
+ ClientKeyExchange and its length can therefore be unambiguously |\r
+ determined. The SSLv3 specification was not clear about the |\r
+ encoding of public-key-encrypted data and therefore many SSLv3 |\r
+ implementations do not include the the length bytes, encoding the |\r
+ RSA encrypted data directly in the ClientKeyExchange message. |\r
+\r
+\r
+ This specification requires correct encoding of the |\r
+ EncryptedPreMasterSecret complete with length bytes. The |\r
+ resulting PDU is incompatible with many SSLv3 implementations. |\r
+ Implementors upgrading from SSLv3 must modify their |\r
+ implementations to generate and accept the correct encoding. |\r
+ Implementors who wish to be compatible with both SSLv3 and TLS |\r
+ should make their implementation's behavior dependent on the |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 49] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ protocol version. |\r
+\r
+\r
+ Implementation Note: It is now known that remote timing-based attacks |\r
+ on SSL are possible, at least when the client and server are on |\r
+ the same LAN. Accordingly, implementations which use static RSA |\r
+ keys SHOULD use RSA blinding or some other anti-timing technique, |\r
+ as described in [TIMING].\r
+\r
+\r
+ Note: The version number in the PreMasterSecret is that offered by the |\r
+ client, NOT the version negotiated for the connection. This |\r
+ feature is designed to prevent rollback attacks. Unfortunately, |\r
+ many implementations use the negotiated version instead and |\r
+ therefore checking the version number may lead to failure to |\r
+ interoperate with such incorrect client implementations. Client |\r
+ implementations MUST and Server implementations MAY check the |\r
+ version number. In practice, since there are no significant known |\r
+ security differences between TLS and SSLv3, rollback to SSLv3 is |\r
+ not believed to be a serious security risk. Note that if servers |\r
+ choose to to check the version number, they should randomize the |\r
+ PreMasterSecret in case of error, rather than generate an alert, |\r
+ in order to avoid variants on the Bleichenbacher attack. [KPR03]\r
+\r
+\r
+7.4.7.2. Client Diffie-Hellman public value\r
+\r
+\r
+ Meaning of this message:\r
+ This structure conveys the client's Diffie-Hellman public value\r
+ (Yc) if it was not already included in the client's certificate.\r
+ The encoding used for Yc is determined by the enumerated\r
+ PublicValueEncoding. This structure is a variant of the client\r
+ key exchange message, not a message in itself.\r
+\r
+\r
+ Structure of this message:\r
+ enum { implicit, explicit } PublicValueEncoding;\r
+\r
+\r
+ implicit\r
+ If the client certificate already contains a suitable Diffie-\r
+ Hellman key, then Yc is implicit and does not need to be sent\r
+ again. In this case, the Client Key Exchange message will be\r
+ sent, but will be empty.\r
+\r
+\r
+ explicit\r
+ Yc needs to be sent.\r
+\r
+\r
+ struct {\r
+ select (PublicValueEncoding) {\r
+ case implicit: struct { };\r
+ case explicit: opaque dh_Yc<1..2^16-1>;\r
+ } dh_public;\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 50] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ } ClientDiffieHellmanPublic;\r
+\r
+\r
+ dh_Yc\r
+ The client's Diffie-Hellman public value (Yc).\r
+\r
+\r
+7.4.8. Certificate verify\r
+\r
+\r
+ When this message will be sent:\r
+ This message is used to provide explicit verification of a client\r
+ certificate. This message is only sent following a client\r
+ certificate that has signing capability (i.e. all certificates\r
+ except those containing fixed Diffie-Hellman parameters). When\r
+ sent, it will immediately follow the client key exchange message.\r
+\r
+\r
+ Structure of this message:\r
+ struct {\r
+ Signature signature;\r
+ } CertificateVerify;\r
+\r
+\r
+ The Signature type is defined in 7.4.3.\r
+\r
+\r
+ CertificateVerify.signature.md5_hash\r
+ MD5(handshake_messages);\r
+\r
+\r
+ CertificateVerify.signature.sha_hash |\r
+ SHA(handshake_messages);\r
+\r
+\r
+ Here handshake_messages refers to all handshake messages sent or\r
+ received starting at client hello up to but not including this\r
+ message, including the type and length fields of the handshake\r
+ messages. This is the concatenation of all the Handshake structures\r
+ as defined in 7.4 exchanged thus far.\r
+\r
+\r
+7.4.9. Finished\r
+\r
+\r
+ When this message will be sent:\r
+ A finished message is always sent immediately after a change\r
+ cipher spec message to verify that the key exchange and\r
+ authentication processes were successful. It is essential that a\r
+ change cipher spec message be received between the other\r
+ handshake messages and the Finished message.\r
+\r
+\r
+ Meaning of this message:\r
+ The finished message is the first protected with the just-\r
+ negotiated algorithms, keys, and secrets. Recipients of finished |\r
+ messages MUST verify that the contents are correct. Once a side\r
+ has sent its Finished message and received and validated the\r
+ Finished message from its peer, it may begin to send and receive\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 51] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ application data over the connection.\r
+\r
+\r
+ struct {\r
+ opaque verify_data[12];\r
+ } Finished;\r
+\r
+\r
+ verify_data\r
+ PRF(master_secret, finished_label, MD5(handshake_messages) +\r
+ SHA-1(handshake_messages)) [0..11];\r
+\r
+\r
+ finished_label\r
+ For Finished messages sent by the client, the string "client\r
+ finished". For Finished messages sent by the server, the\r
+ string "server finished".\r
+\r
+\r
+ handshake_messages\r
+ All of the data from all handshake messages up to but not\r
+ including this message. This is only data visible at the\r
+ handshake layer and does not include record layer headers.\r
+ This is the concatenation of all the Handshake structures as\r
+ defined in 7.4 exchanged thus far.\r
+\r
+\r
+ It is a fatal error if a finished message is not preceded by a change\r
+ cipher spec message at the appropriate point in the handshake.\r
+\r
+\r
+ The value handshake_messages includes all handshake messages starting |\r
+ at client hello up to, but not including, this finished message. This\r
+ may be different from handshake_messages in Section 7.4.8 because it\r
+ would include the certificate verify message (if sent). Also, the\r
+ handshake_messages for the finished message sent by the client will\r
+ be different from that for the finished message sent by the server,\r
+ because the one which is sent second will include the prior one.\r
+\r
+\r
+ Note: Change cipher spec messages, alerts and any other record types\r
+ are not handshake messages and are not included in the hash\r
+ computations. Also, Hello Request messages are omitted from\r
+ handshake hashes.\r
+\r
+\r
+8. Cryptographic computations\r
+\r
+\r
+ In order to begin connection protection, the TLS Record Protocol\r
+ requires specification of a suite of algorithms, a master secret, and\r
+ the client and server random values. The authentication, encryption,\r
+ and MAC algorithms are determined by the cipher_suite selected by the\r
+ server and revealed in the server hello message. The compression\r
+ algorithm is negotiated in the hello messages, and the random values\r
+ are exchanged in the hello messages. All that remains is to calculate\r
+ the master secret.\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 52] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+8.1. Computing the master secret\r
+\r
+\r
+ For all key exchange methods, the same algorithm is used to convert\r
+ the pre_master_secret into the master_secret. The pre_master_secret\r
+ should be deleted from memory once the master_secret has been\r
+ computed.\r
+\r
+\r
+ master_secret = PRF(pre_master_secret, "master secret",\r
+ ClientHello.random + ServerHello.random)\r
+ [0..47];\r
+\r
+\r
+ The master secret is always exactly 48 bytes in length. The length of\r
+ the premaster secret will vary depending on key exchange method.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 53] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+8.1.1. RSA\r
+\r
+\r
+ When RSA is used for server authentication and key exchange, a\r
+ 48-byte pre_master_secret is generated by the client, encrypted under\r
+ the server's public key, and sent to the server. The server uses its\r
+ private key to decrypt the pre_master_secret. Both parties then\r
+ convert the pre_master_secret into the master_secret, as specified\r
+ above.\r
+\r
+\r
+ RSA digital signatures are performed using PKCS #1 [PKCS1] block type\r
+ 1. RSA public key encryption is performed using PKCS #1 block type 2.\r
+\r
+\r
+8.1.2. Diffie-Hellman\r
+\r
+\r
+ A conventional Diffie-Hellman computation is performed. The\r
+ negotiated key (Z) is used as the pre_master_secret, and is converted\r
+ into the master_secret, as specified above. Leading 0 bytes of Z are |\r
+ stripped before it is used as the pre_master_secret.\r
+\r
+\r
+ Note: Diffie-Hellman parameters are specified by the server, and may\r
+ be either ephemeral or contained within the server's certificate.\r
+\r
+\r
+9. Mandatory Cipher Suites\r
+\r
+\r
+ In the absence of an application profile standard specifying\r
+ otherwise, a TLS compliant application MUST implement the cipher |\r
+ suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. |\r
+\r
+\r
+ The 40-bit cipher suites are known to be susceptible to exhaustive |\r
+ search attack by commercial attackers. Implementations of this |\r
+ document SHOULD disable them by default if they are supported at all. |\r
+ A future version of this document may remove them entirely.\r
+\r
+\r
+10. Application data protocol\r
+\r
+\r
+ Application data messages are carried by the Record Layer and are\r
+ fragmented, compressed and encrypted based on the current connection\r
+ state. The messages are treated as transparent data to the record\r
+ layer.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 54] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+A. Protocol constant values\r
+\r
+\r
+ This section describes protocol types and constants.\r
+\r
+\r
+A.1. Record layer\r
+\r
+\r
+ struct {\r
+ uint8 major, minor;\r
+ } ProtocolVersion;\r
+\r
+\r
+ ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */ |\r
+\r
+\r
+ enum {\r
+ change_cipher_spec(20), alert(21), handshake(22),\r
+ application_data(23), (255)\r
+ } ContentType;\r
+\r
+\r
+ struct {\r
+ ContentType type;\r
+ ProtocolVersion version;\r
+ uint16 length;\r
+ opaque fragment[TLSPlaintext.length];\r
+ } TLSPlaintext;\r
+\r
+\r
+ struct {\r
+ ContentType type;\r
+ ProtocolVersion version;\r
+ uint16 length;\r
+ opaque fragment[TLSCompressed.length];\r
+ } TLSCompressed;\r
+\r
+\r
+ struct {\r
+ ContentType type;\r
+ ProtocolVersion version;\r
+ uint16 length;\r
+ select (CipherSpec.cipher_type) {\r
+ case stream: GenericStreamCipher;\r
+ case block: GenericBlockCipher;\r
+ } fragment;\r
+ } TLSCiphertext;\r
+\r
+\r
+ stream-ciphered struct {\r
+ opaque content[TLSCompressed.length];\r
+ opaque MAC[CipherSpec.hash_size];\r
+ } GenericStreamCipher;\r
+\r
+\r
+ block-ciphered struct {\r
+ opaque IV[CipherSpec.block_length]; |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 55] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ opaque content[TLSCompressed.length];\r
+ opaque MAC[CipherSpec.hash_size];\r
+ uint8 padding[GenericBlockCipher.padding_length];\r
+ uint8 padding_length;\r
+ } GenericBlockCipher;\r
+\r
+\r
+A.2. Change cipher specs message\r
+\r
+\r
+ struct {\r
+ enum { change_cipher_spec(1), (255) } type;\r
+ } ChangeCipherSpec;\r
+\r
+\r
+A.3. Alert messages\r
+\r
+\r
+ enum { warning(1), fatal(2), (255) } AlertLevel;\r
+\r
+\r
+ enum {\r
+ close_notify(0),\r
+ unexpected_message(10),\r
+ bad_record_mac(20),\r
+ decryption_failed(21),\r
+ record_overflow(22),\r
+ decompression_failure(30),\r
+ handshake_failure(40),\r
+ no_certificate_RESERVED (41), |\r
+ bad_certificate(42),\r
+ unsupported_certificate(43),\r
+ certificate_revoked(44),\r
+ certificate_expired(45),\r
+ certificate_unknown(46),\r
+ illegal_parameter(47),\r
+ unknown_ca(48),\r
+ access_denied(49),\r
+ decode_error(50),\r
+ decrypt_error(51),\r
+ export_restriction(60),\r
+ protocol_version(70),\r
+ insufficient_security(71),\r
+ internal_error(80),\r
+ user_canceled(90),\r
+ no_renegotiation(100),\r
+ (255)\r
+ } AlertDescription;\r
+\r
+\r
+ struct {\r
+ AlertLevel level;\r
+ AlertDescription description;\r
+ } Alert;\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 56] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+A.4. Handshake protocol\r
+\r
+\r
+ enum {\r
+ hello_request(0), client_hello(1), server_hello(2),\r
+ certificate(11), server_key_exchange (12),\r
+ certificate_request(13), server_hello_done(14),\r
+ certificate_verify(15), client_key_exchange(16),\r
+ finished(20), (255)\r
+ } HandshakeType;\r
+\r
+\r
+ struct {\r
+ HandshakeType msg_type;\r
+ uint24 length;\r
+ select (HandshakeType) {\r
+ case hello_request: HelloRequest;\r
+ case client_hello: ClientHello;\r
+ case server_hello: ServerHello;\r
+ case certificate: Certificate;\r
+ case server_key_exchange: ServerKeyExchange;\r
+ case certificate_request: CertificateRequest;\r
+ case server_hello_done: ServerHelloDone;\r
+ case certificate_verify: CertificateVerify;\r
+ case client_key_exchange: ClientKeyExchange;\r
+ case finished: Finished;\r
+ } body;\r
+ } Handshake;\r
+\r
+\r
+A.4.1. Hello messages\r
+\r
+\r
+ struct { } HelloRequest;\r
+\r
+\r
+ struct {\r
+ uint32 gmt_unix_time;\r
+ opaque random_bytes[28];\r
+ } Random;\r
+\r
+\r
+ opaque SessionID<0..32>;\r
+\r
+\r
+ uint8 CipherSuite[2];\r
+\r
+\r
+ enum { null(0), (255) } CompressionMethod;\r
+\r
+\r
+ struct {\r
+ ProtocolVersion client_version;\r
+ Random random;\r
+ SessionID session_id;\r
+ CipherSuite cipher_suites<2..2^16-1>;\r
+ CompressionMethod compression_methods<1..2^8-1>;\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 57] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ } ClientHello;\r
+\r
+\r
+ struct {\r
+ ProtocolVersion server_version;\r
+ Random random;\r
+ SessionID session_id;\r
+ CipherSuite cipher_suite;\r
+ CompressionMethod compression_method;\r
+ } ServerHello;\r
+\r
+\r
+A.4.2. Server authentication and key exchange messages\r
+\r
+\r
+ opaque ASN.1Cert<2^24-1>;\r
+\r
+\r
+ struct {\r
+ ASN.1Cert certificate_list<0..2^24-1>; |\r
+ } Certificate;\r
+\r
+\r
+ enum { rsa, diffie_hellman } KeyExchangeAlgorithm;\r
+\r
+\r
+ struct {\r
+ opaque RSA_modulus<1..2^16-1>;\r
+ opaque RSA_exponent<1..2^16-1>;\r
+ } ServerRSAParams;\r
+\r
+\r
+ struct {\r
+ opaque DH_p<1..2^16-1>;\r
+ opaque DH_g<1..2^16-1>;\r
+ opaque DH_Ys<1..2^16-1>;\r
+ } ServerDHParams;\r
+\r
+\r
+ struct {\r
+ select (KeyExchangeAlgorithm) {\r
+ case diffie_hellman:\r
+ ServerDHParams params;\r
+ Signature signed_params;\r
+ case rsa:\r
+ ServerRSAParams params;\r
+ Signature signed_params;\r
+ };\r
+ } ServerKeyExchange;\r
+\r
+\r
+ enum { anonymous, rsa, dsa } SignatureAlgorithm; |\r
+\r
+\r
+ struct { |\r
+ select (KeyExchangeAlgorithm) { |\r
+ case diffie_hellman: |\r
+ ServerDHParams params; |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 58] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ case rsa: |\r
+ ServerRSAParams params; |\r
+ }; |\r
+ } ServerParams; |\r
+\r
+\r
+ select (SignatureAlgorithm)\r
+ { case anonymous: struct { };\r
+ case rsa:\r
+ digitally-signed struct {\r
+ opaque md5_hash[16];\r
+ opaque sha_hash[20];\r
+ };\r
+ case dsa:\r
+ digitally-signed struct {\r
+ opaque sha_hash[20];\r
+ };\r
+ } Signature;\r
+\r
+\r
+ enum {\r
+ rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),\r
+ rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), |\r
+ fortezza_dms_RESERVED(20), |\r
+ (255) |\r
+ } ClientCertificateType;\r
+\r
+\r
+ opaque DistinguishedName<1..2^16-1>;\r
+\r
+\r
+ struct {\r
+ ClientCertificateType certificate_types<1..2^8-1>;\r
+ DistinguishedName certificate_authorities<0..2^16-1>; |\r
+ } CertificateRequest;\r
+\r
+\r
+ struct { } ServerHelloDone;\r
+\r
+\r
+A.4.3. Client authentication and key exchange messages\r
+\r
+\r
+ struct {\r
+ select (KeyExchangeAlgorithm) {\r
+ case rsa: EncryptedPreMasterSecret;\r
+ case diffie_hellman: DiffieHellmanClientPublicValue;\r
+ } exchange_keys;\r
+ } ClientKeyExchange;\r
+\r
+\r
+ struct {\r
+ ProtocolVersion client_version;\r
+ opaque random[46];\r
+ } PreMasterSecret;\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 59] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ struct {\r
+ public-key-encrypted PreMasterSecret pre_master_secret;\r
+ } EncryptedPreMasterSecret;\r
+\r
+\r
+ enum { implicit, explicit } PublicValueEncoding;\r
+\r
+\r
+ struct {\r
+ select (PublicValueEncoding) {\r
+ case implicit: struct {};\r
+ case explicit: opaque DH_Yc<1..2^16-1>;\r
+ } dh_public;\r
+ } ClientDiffieHellmanPublic;\r
+\r
+\r
+ struct {\r
+ Signature signature;\r
+ } CertificateVerify;\r
+\r
+\r
+A.4.4. Handshake finalization message\r
+\r
+\r
+ struct {\r
+ opaque verify_data[12];\r
+ } Finished;\r
+\r
+\r
+A.5. The CipherSuite\r
+\r
+\r
+ The following values define the CipherSuite codes used in the client\r
+ hello and server hello messages.\r
+\r
+\r
+ A CipherSuite defines a cipher specification supported in TLS Version |\r
+ 1.1.\r
+\r
+\r
+ TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a\r
+ TLS connection during the first handshake on that channel, but must\r
+ not be negotiated, as it provides no more protection than an\r
+ unsecured connection.\r
+\r
+\r
+ CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };\r
+\r
+\r
+ The following CipherSuite definitions require that the server provide\r
+ an RSA certificate that can be used for key exchange. The server may\r
+ request either an RSA or a DSS signature-capable certificate in the\r
+ certificate request message.\r
+\r
+\r
+ CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };\r
+ CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };\r
+ CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };\r
+ CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };\r
+ CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 60] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };\r
+ CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };\r
+ CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };\r
+ CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };\r
+ CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };\r
+\r
+\r
+ The following CipherSuite definitions are used for server-\r
+ authenticated (and optionally client-authenticated) Diffie-Hellman.\r
+ DH denotes cipher suites in which the server's certificate contains\r
+ the Diffie-Hellman parameters signed by the certificate authority\r
+ (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman\r
+ parameters are signed by a DSS or RSA certificate, which has been\r
+ signed by the CA. The signing algorithm used is specified after the\r
+ DH or DHE parameter. The server can request an RSA or DSS signature-\r
+ capable certificate from the client for client authentication or it\r
+ may request a Diffie-Hellman certificate. Any Diffie-Hellman\r
+ certificate provided by the client must use the parameters (group and\r
+ generator) described by the server.\r
+\r
+\r
+ CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };\r
+ CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };\r
+ CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };\r
+ CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };\r
+ CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };\r
+ CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };\r
+ CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };\r
+ CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };\r
+ CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };\r
+ CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };\r
+ CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };\r
+ CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };\r
+\r
+\r
+ The following cipher suites are used for completely anonymous Diffie-\r
+ Hellman communications in which neither party is authenticated. Note\r
+ that this mode is vulnerable to man-in-the-middle attacks and is\r
+ therefore deprecated.\r
+\r
+\r
+ CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };\r
+ CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };\r
+ CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };\r
+ CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };\r
+ CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };\r
+\r
+\r
+ Note: All cipher suites whose first byte is 0xFF are considered\r
+ private and can be used for defining local/experimental\r
+ algorithms. Interoperability of such types is a local matter.\r
+\r
+\r
+ Note: Additional cipher suites can be registered by publishing an RFC\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 61] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ which specifies the cipher suites, including the necessary TLS\r
+ protocol information, including message encoding, premaster\r
+ secret derivation, symmetric encryption and MAC calculation and\r
+ appropriate reference information for the algorithms involved.\r
+ The RFC editor's office may, at its discretion, choose to publish\r
+ specifications for cipher suites which are not completely\r
+ described (e.g., for classified algorithms) if it finds the\r
+ specification to be of technical interest and completely\r
+ specified.\r
+\r
+\r
+ Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are\r
+ reserved to avoid collision with Fortezza-based cipher suites in\r
+ SSL 3.\r
+\r
+\r
+A.6. The Security Parameters\r
+\r
+\r
+ These security parameters are determined by the TLS Handshake\r
+ Protocol and provided as parameters to the TLS Record Layer in order\r
+ to initialize a connection state. SecurityParameters includes:\r
+\r
+\r
+ enum { null(0), (255) } CompressionMethod;\r
+\r
+\r
+ enum { server, client } ConnectionEnd;\r
+\r
+\r
+ enum { null, rc4, rc2, des, 3des, des40, idea }\r
+ BulkCipherAlgorithm;\r
+\r
+\r
+ enum { stream, block } CipherType;\r
+\r
+\r
+ enum { true, false } IsExportable;\r
+\r
+\r
+ enum { null, md5, sha } MACAlgorithm;\r
+\r
+\r
+ /* The algorithms specified in CompressionMethod,\r
+ BulkCipherAlgorithm, and MACAlgorithm may be added to. */\r
+\r
+\r
+ struct {\r
+ ConnectionEnd entity;\r
+ BulkCipherAlgorithm bulk_cipher_algorithm;\r
+ CipherType cipher_type;\r
+ uint8 key_size;\r
+ uint8 key_material_length;\r
+ IsExportable is_exportable;\r
+ MACAlgorithm mac_algorithm;\r
+ uint8 hash_size;\r
+ CompressionMethod compression_algorithm;\r
+ opaque master_secret[48];\r
+ opaque client_random[32];\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 62] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ opaque server_random[32];\r
+ } SecurityParameters;\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 63] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+B. Glossary\r
+\r
+\r
+ application protocol\r
+ An application protocol is a protocol that normally layers\r
+ directly on top of the transport layer (e.g., TCP/IP). Examples\r
+ include HTTP, TELNET, FTP, and SMTP.\r
+\r
+\r
+ asymmetric cipher\r
+ See public key cryptography.\r
+\r
+\r
+ authentication\r
+ Authentication is the ability of one entity to determine the\r
+ identity of another entity.\r
+\r
+\r
+ block cipher\r
+ A block cipher is an algorithm that operates on plaintext in\r
+ groups of bits, called blocks. 64 bits is a common block size.\r
+\r
+\r
+ bulk cipher\r
+ A symmetric encryption algorithm used to encrypt large quantities\r
+ of data.\r
+\r
+\r
+ cipher block chaining (CBC)\r
+ CBC is a mode in which every plaintext block encrypted with a\r
+ block cipher is first exclusive-ORed with the previous ciphertext\r
+ block (or, in the case of the first block, with the\r
+ initialization vector). For decryption, every block is first\r
+ decrypted, then exclusive-ORed with the previous ciphertext block\r
+ (or IV).\r
+\r
+\r
+ certificate\r
+ As part of the X.509 protocol (a.k.a. ISO Authentication\r
+ framework), certificates are assigned by a trusted Certificate\r
+ Authority and provide a strong binding between a party's identity\r
+ or some other attributes and its public key.\r
+\r
+\r
+ client\r
+ The application entity that initiates a TLS connection to a\r
+ server. This may or may not imply that the client initiated the\r
+ underlying transport connection. The primary operational\r
+ difference between the server and client is that the server is\r
+ generally authenticated, while the client is only optionally\r
+ authenticated.\r
+\r
+\r
+ client write key\r
+ The key used to encrypt data written by the client.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 64] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ client write MAC secret\r
+ The secret data used to authenticate data written by the client.\r
+\r
+\r
+ connection\r
+ A connection is a transport (in the OSI layering model\r
+ definition) that provides a suitable type of service. For TLS,\r
+ such connections are peer to peer relationships. The connections\r
+ are transient. Every connection is associated with one session.\r
+\r
+\r
+ Data Encryption Standard\r
+ DES is a very widely used symmetric encryption algorithm. DES is\r
+ a block cipher with a 56 bit key and an 8 byte block size. Note\r
+ that in TLS, for key generation purposes, DES is treated as\r
+ having an 8 byte key length (64 bits), but it still only provides\r
+ 56 bits of protection. (The low bit of each key byte is presumed\r
+ to be set to produce odd parity in that key byte.) DES can also\r
+ be operated in a mode where three independent keys and three\r
+ encryptions are used for each block of data; this uses 168 bits\r
+ of key (24 bytes in the TLS key generation method) and provides\r
+ the equivalent of 112 bits of security. [DES], [3DES]\r
+\r
+\r
+ Digital Signature Standard (DSS)\r
+ A standard for digital signing, including the Digital Signing\r
+ Algorithm, approved by the National Institute of Standards and\r
+ Technology, defined in NIST FIPS PUB 186, "Digital Signature\r
+ Standard," published May, 1994 by the U.S. Dept. of Commerce.\r
+ [DSS]\r
+\r
+\r
+ digital signatures |\r
+ Digital signatures utilize public key cryptography and one-way\r
+ hash functions to produce a signature of the data that can be\r
+ authenticated, and is difficult to forge or repudiate.\r
+\r
+\r
+ handshake\r
+ An initial negotiation between client and server that establishes\r
+ the parameters of their transactions.\r
+\r
+\r
+ Initialization Vector (IV)\r
+ When a block cipher is used in CBC mode, the initialization\r
+ vector is exclusive-ORed with the first plaintext block prior to\r
+ encryption.\r
+\r
+\r
+ IDEA\r
+ A 64-bit block cipher designed by Xuejia Lai and James Massey.\r
+ [IDEA]\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 65] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Message Authentication Code (MAC)\r
+ A Message Authentication Code is a one-way hash computed from a\r
+ message and some secret data. It is difficult to forge without\r
+ knowing the secret data. Its purpose is to detect if the message\r
+ has been altered.\r
+\r
+\r
+ master secret\r
+ Secure secret data used for generating encryption keys, MAC\r
+ secrets, and IVs.\r
+\r
+\r
+ MD5\r
+ MD5 is a secure hashing function that converts an arbitrarily\r
+ long data stream into a digest of fixed size (16 bytes). [MD5]\r
+\r
+\r
+ public key cryptography\r
+ A class of cryptographic techniques employing two-key ciphers.\r
+ Messages encrypted with the public key can only be decrypted with\r
+ the associated private key. Conversely, messages signed with the\r
+ private key can be verified with the public key.\r
+\r
+\r
+ one-way hash function\r
+ A one-way transformation that converts an arbitrary amount of\r
+ data into a fixed-length hash. It is computationally hard to\r
+ reverse the transformation or to find collisions. MD5 and SHA are\r
+ examples of one-way hash functions.\r
+\r
+\r
+ RC2\r
+ A block cipher developed by Ron Rivest at RSA Data Security, Inc.\r
+ [RSADSI] described in [RC2].\r
+\r
+\r
+ RC4\r
+ A stream cipher licensed by RSA Data Security [RSADSI]. A\r
+ compatible cipher is described in [RC4].\r
+\r
+\r
+ RSA\r
+ A very widely used public-key algorithm that can be used for\r
+ either encryption or digital signing. [RSA]\r
+\r
+\r
+ salt\r
+ Non-secret random data used to make export encryption keys resist\r
+ precomputation attacks.\r
+\r
+\r
+ server\r
+ The server is the application entity that responds to requests\r
+ for connections from clients. See also under client.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 66] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ session\r
+ A TLS session is an association between a client and a server.\r
+ Sessions are created by the handshake protocol. Sessions define a\r
+ set of cryptographic security parameters, which can be shared\r
+ among multiple connections. Sessions are used to avoid the\r
+ expensive negotiation of new security parameters for each\r
+ connection.\r
+\r
+\r
+ session identifier\r
+ A session identifier is a value generated by a server that\r
+ identifies a particular session.\r
+\r
+\r
+ server write key\r
+ The key used to encrypt data written by the server.\r
+\r
+\r
+ server write MAC secret\r
+ The secret data used to authenticate data written by the server.\r
+\r
+\r
+ SHA\r
+ The Secure Hash Algorithm is defined in FIPS PUB 180-1. It\r
+ produces a 20-byte output. Note that all references to SHA\r
+ actually use the modified SHA-1 algorithm. [SHA]\r
+\r
+\r
+ SSL\r
+ Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on\r
+ SSL Version 3.0\r
+\r
+\r
+ stream cipher\r
+ An encryption algorithm that converts a key into a\r
+ cryptographically-strong keystream, which is then exclusive-ORed\r
+ with the plaintext.\r
+\r
+\r
+ symmetric cipher |\r
+ See bulk cipher.\r
+\r
+\r
+ Transport Layer Security (TLS)\r
+ This protocol; also, the Transport Layer Security working group\r
+ of the Internet Engineering Task Force (IETF). See "Comments" at\r
+ the end of this document.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 67] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+C. CipherSuite definitions\r
+\r
+\r
+CipherSuite Is Key Cipher Hash\r
+ Exportable Exchange\r
+\r
+\r
+TLS_NULL_WITH_NULL_NULL * NULL NULL NULL\r
+TLS_RSA_WITH_NULL_MD5 * RSA NULL MD5\r
+TLS_RSA_WITH_NULL_SHA * RSA NULL SHA\r
+TLS_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5\r
+TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5\r
+TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA\r
+TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5\r
+TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA\r
+TLS_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA\r
+TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA\r
+TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA\r
+TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA\r
+TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA\r
+TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA\r
+TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA\r
+TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA\r
+TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA\r
+TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA\r
+TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA\r
+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA\r
+TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA\r
+TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA\r
+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA\r
+TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5\r
+TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5\r
+TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA\r
+TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA\r
+TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA\r
+\r
+\r
+\r
+ * Indicates IsExportable is True\r
+\r
+\r
+ Key\r
+ Exchange\r
+ Algorithm Description Key size limit\r
+\r
+\r
+ DHE_DSS Ephemeral DH with DSS signatures None\r
+ DHE_DSS_EXPORT Ephemeral DH with DSS signatures DH = 512 bits\r
+ DHE_RSA Ephemeral DH with RSA signatures None\r
+ DHE_RSA_EXPORT Ephemeral DH with RSA signatures DH = 512 bits,\r
+ RSA = none\r
+ DH_anon Anonymous DH, no signatures None\r
+ DH_anon_EXPORT Anonymous DH, no signatures DH = 512 bits\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 68] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ DH_DSS DH with DSS-based certificates None\r
+ DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits\r
+ DH_RSA DH with RSA-based certificates None\r
+ DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits,\r
+ RSA = none\r
+ NULL No key exchange N/A\r
+ RSA RSA key exchange None\r
+ RSA_EXPORT RSA key exchange RSA = 512 bits\r
+\r
+\r
+ Key size limit\r
+ The key size limit gives the size of the largest public key that\r
+ can be legally used for encryption or key agreement in |\r
+ cipher suites that are exportable. |\r
+\r
+\r
+ Key Expanded Effective IV Block\r
+ Cipher Type Material Key Material Key Bits Size Size\r
+\r
+\r
+ NULL * Stream 0 0 0 0 N/A\r
+ IDEA_CBC Block 16 16 128 8 8\r
+ RC2_CBC_40 * Block 5 16 40 8 8\r
+ RC4_40 * Stream 5 16 40 0 N/A\r
+ RC4_128 Stream 16 16 128 0 N/A\r
+ DES40_CBC * Block 5 8 40 8 8\r
+ DES_CBC Block 8 8 56 8 8\r
+ 3DES_EDE_CBC Block 24 24 168 8 8\r
+\r
+\r
+ * Indicates IsExportable is true.\r
+\r
+\r
+ Type\r
+ Indicates whether this is a stream cipher or a block cipher\r
+ running in CBC mode.\r
+\r
+\r
+ Key Material\r
+ The number of bytes from the key_block that are used for\r
+ generating the write keys.\r
+\r
+\r
+ Expanded Key Material\r
+ The number of bytes actually fed into the encryption algorithm\r
+\r
+\r
+ Effective Key Bits\r
+ How much entropy material is in the key material being fed into\r
+ the encryption routines.\r
+\r
+\r
+ IV Size\r
+ How much data needs to be generated for the initialization\r
+ vector. Zero for stream ciphers; equal to the block size for\r
+ block ciphers.\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 69] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Block Size\r
+ The amount of data a block cipher enciphers in one chunk; a\r
+ block cipher running in CBC mode can only encrypt an even\r
+ multiple of its block size.\r
+\r
+\r
+ Hash Hash Padding\r
+ function Size Size\r
+ NULL 0 0\r
+ MD5 16 48\r
+ SHA 20 40\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 70] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+D. Implementation Notes\r
+\r
+\r
+ The TLS protocol cannot prevent many common security mistakes. This\r
+ section provides several recommendations to assist implementors.\r
+\r
+\r
+D.1. Temporary RSA keys\r
+\r
+\r
+ US Export restrictions limit RSA keys used for encryption to 512\r
+ bits, but do not place any limit on lengths of RSA keys used for\r
+ signing operations. Certificates often need to be larger than 512\r
+ bits, since 512-bit RSA keys are not secure enough for high-value\r
+ transactions or for applications requiring long-term security. Some\r
+ certificates are also designated signing-only, in which case they\r
+ cannot be used for key exchange.\r
+\r
+\r
+ When the public key in the certificate cannot be used for encryption,\r
+ the server signs a temporary RSA key, which is then exchanged. In\r
+ exportable applications, the temporary RSA key should be the maximum\r
+ allowable length (i.e., 512 bits). Because 512-bit RSA keys are\r
+ relatively insecure, they should be changed often. For typical\r
+ electronic commerce applications, it is suggested that keys be\r
+ changed daily or every 500 transactions, and more often if possible.\r
+ Note that while it is acceptable to use the same temporary key for\r
+ multiple transactions, it must be signed each time it is used.\r
+\r
+\r
+ RSA key generation is a time-consuming process. In many cases, a low-\r
+ priority process can be assigned the task of key generation.\r
+\r
+\r
+ Whenever a new key is completed, the existing temporary key can be\r
+ replaced with the new one.\r
+\r
+\r
+D.2. Random Number Generation and Seeding\r
+\r
+\r
+ TLS requires a cryptographically-secure pseudorandom number generator\r
+ (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs\r
+ based on secure hash operations, most notably MD5 and/or SHA, are\r
+ acceptable, but cannot provide more security than the size of the\r
+ random number generator state. (For example, MD5-based PRNGs usually\r
+ provide 128 bits of state.)\r
+\r
+\r
+ To estimate the amount of seed material being produced, add the\r
+ number of bits of unpredictable information in each seed byte. For\r
+ example, keystroke timing values taken from a PC compatible's 18.2 Hz\r
+ timer provide 1 or 2 secure bits each, even though the total size of\r
+ the counter value is 16 bits or more. To seed a 128-bit PRNG, one\r
+ would thus require approximately 100 such timer values.\r
+\r
+\r
+D.3. Certificates and authentication\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 71] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Implementations are responsible for verifying the integrity of\r
+ certificates and should generally support certificate revocation\r
+ messages. Certificates should always be verified to ensure proper\r
+ signing by a trusted Certificate Authority (CA). The selection and\r
+ addition of trusted CAs should be done very carefully. Users should\r
+ be able to view information about the certificate and root CA.\r
+\r
+\r
+D.4. CipherSuites\r
+\r
+\r
+ TLS supports a range of key sizes and security levels, including some\r
+ which provide no or minimal security. A proper implementation will\r
+ probably not support many cipher suites. For example, 40-bit\r
+ encryption is easily broken, so implementations requiring strong\r
+ security should not allow 40-bit keys. Similarly, anonymous Diffie-\r
+ Hellman is strongly discouraged because it cannot prevent man-in-the-\r
+ middle attacks. Applications should also enforce minimum and maximum\r
+ key sizes. For example, certificate chains containing 512-bit RSA\r
+ keys or signatures are not appropriate for high-security\r
+ applications.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 72] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+E. Backward Compatibility With SSL\r
+\r
+\r
+ For historical reasons and in order to avoid a profligate consumption\r
+ of reserved port numbers, application protocols which are secured by |\r
+ TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same\r
+ connection port: for example, the https protocol (HTTP secured by SSL\r
+ or TLS) uses port 443 regardless of which security protocol it is\r
+ using. Thus, some mechanism must be determined to distinguish and\r
+ negotiate among the various protocols.\r
+\r
+\r
+ TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting |\r
+ both is easy. TLS clients who wish to negotiate with such older |\r
+ servers SHOULD send client hello messages using the SSL 3.0 record |\r
+ format and client hello structure, sending {3, 2} for the version |\r
+ field to note that they support TLS 1.1. If the server supports only |\r
+ TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello; |\r
+ if it supports TLS 1.1 it will respond with a TLS 1.1 server hello. |\r
+ The negotiation then proceeds as appropriate for the negotiated\r
+ protocol.\r
+\r
+\r
+ Similarly, a TLS 1.1 server which wishes to interoperate with TLS |\r
+ 1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages |\r
+ and respond with a SSL 3.0 server hello if an SSL 3.0 client hello |\r
+ with a version field of {3, 0} is received, denoting that this client |\r
+ does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a |\r
+ version field of {3, 1} is received, the server SHOULD respond with a |\r
+ TLS 1.0 hello with a version field of {3, 1}.\r
+\r
+\r
+ Whenever a client already knows the highest protocol known to a |\r
+ server (for example, when resuming a session), it SHOULD initiate the\r
+ connection in that native protocol.\r
+\r
+\r
+ TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL |\r
+ Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept\r
+ either client hello format if they wish to support SSL 2.0 clients on\r
+ the same connection port. The only deviations from the Version 2.0\r
+ specification are the ability to specify a version with a value of\r
+ three and the support for more ciphering types in the CipherSpec.\r
+\r
+\r
+ Warning: The ability to send Version 2.0 client hello messages will be\r
+ phased out with all due haste. Implementors SHOULD make every |\r
+ effort to move forward as quickly as possible. Version 3.0\r
+ provides better mechanisms for moving to newer versions.\r
+\r
+\r
+ The following cipher specifications are carryovers from SSL Version\r
+ 2.0. These are assumed to use RSA for key exchange and\r
+ authentication.\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 73] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };\r
+ V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };\r
+ V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };\r
+ V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5\r
+ = { 0x04,0x00,0x80 };\r
+ V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };\r
+ V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };\r
+ V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };\r
+\r
+\r
+ Cipher specifications native to TLS can be included in Version 2.0\r
+ client hello messages using the syntax below. Any V2CipherSpec\r
+ element with its first byte equal to zero will be ignored by Version |\r
+ 2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD\r
+ also include the TLS equivalent (see Appendix A.5):\r
+\r
+\r
+ V2CipherSpec (see TLS name) = { 0x00, CipherSuite };\r
+\r
+\r
+E.1. Version 2 client hello\r
+\r
+\r
+ The Version 2.0 client hello message is presented below using this\r
+ document's presentation model. The true definition is still assumed |\r
+ to be the SSL Version 2.0 specification. Note that this message MUST |\r
+ be sent directly on the wire, not wrapped as an SSLv3 record\r
+\r
+\r
+ uint8 V2CipherSpec[3];\r
+\r
+\r
+ struct {\r
+ uint16 msg_length; |\r
+ uint8 msg_type;\r
+ Version version;\r
+ uint16 cipher_spec_length;\r
+ uint16 session_id_length;\r
+ uint16 challenge_length;\r
+ V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];\r
+ opaque session_id[V2ClientHello.session_id_length];\r
+ opaque challenge[V2ClientHello.challenge_length; |\r
+ } V2ClientHello;\r
+\r
+\r
+ msg_length |\r
+ This field is the length of the following data in bytes. The high |\r
+ bit MUST be 1 and is not part of the length. |\r
+\r
+\r
+ msg_type\r
+ This field, in conjunction with the version field, identifies a |\r
+ version 2 client hello message. The value SHOULD be one (1).\r
+\r
+\r
+ version\r
+ The highest version of the protocol supported by the client\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 74] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ (equals ProtocolVersion.version, see Appendix A.1).\r
+\r
+\r
+ cipher_spec_length\r
+ This field is the total length of the field cipher_specs. It |\r
+ cannot be zero and MUST be a multiple of the V2CipherSpec length\r
+ (3).\r
+\r
+\r
+ session_id_length\r
+ This field MUST have a value of zero. |\r
+\r
+\r
+ challenge_length\r
+ The length in bytes of the client's challenge to the server to |\r
+ authenticate itself. When using the SSLv2 backward compatible |\r
+ handshake the client MUST use a 32-byte challenge.\r
+\r
+\r
+ cipher_specs\r
+ This is a list of all CipherSpecs the client is willing and able |\r
+ to use. There MUST be at least one CipherSpec acceptable to the\r
+ server.\r
+\r
+\r
+ session_id\r
+ This field MUST be empty. |\r
+\r
+\r
+ challenge\r
+ The client challenge to the server for the server to identify\r
+ itself is a (nearly) arbitrary length random. The TLS server will\r
+ right justify the challenge data to become the ClientHello.random\r
+ data (padded with leading zeroes, if necessary), as specified in\r
+ this protocol specification. If the length of the challenge is\r
+ greater than 32 bytes, only the last 32 bytes are used. It is\r
+ legitimate (but not necessary) for a V3 server to reject a V2\r
+ ClientHello that has fewer than 16 bytes of challenge data.\r
+\r
+\r
+ Note: Requests to resume a TLS session MUST use a TLS client hello. |\r
+\r
+\r
+E.2. Avoiding man-in-the-middle version rollback\r
+\r
+\r
+ When TLS clients fall back to Version 2.0 compatibility mode, they |\r
+ SHOULD use special PKCS #1 block formatting. This is done so that TLS\r
+ servers will reject Version 2.0 sessions with TLS-capable clients.\r
+\r
+\r
+ When TLS clients are in Version 2.0 compatibility mode, they set the\r
+ right-hand (least-significant) 8 random bytes of the PKCS padding\r
+ (not including the terminal null of the padding) for the RSA\r
+ encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY\r
+ to 0x03 (the other padding bytes are random). After decrypting the |\r
+ ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an\r
+ error if these eight padding bytes are 0x03. Version 2.0 servers\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 75] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ receiving blocks padded in this manner will proceed normally.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 76] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+F. Security analysis\r
+\r
+\r
+ The TLS protocol is designed to establish a secure connection between\r
+ a client and a server communicating over an insecure channel. This\r
+ document makes several traditional assumptions, including that\r
+ attackers have substantial computational resources and cannot obtain\r
+ secret information from sources outside the protocol. Attackers are\r
+ assumed to have the ability to capture, modify, delete, replay, and\r
+ otherwise tamper with messages sent over the communication channel.\r
+ This appendix outlines how TLS has been designed to resist a variety\r
+ of attacks.\r
+\r
+\r
+F.1. Handshake protocol\r
+\r
+\r
+ The handshake protocol is responsible for selecting a CipherSpec and\r
+ generating a Master Secret, which together comprise the primary\r
+ cryptographic parameters associated with a secure session. The\r
+ handshake protocol can also optionally authenticate parties who have\r
+ certificates signed by a trusted certificate authority.\r
+\r
+\r
+F.1.1. Authentication and key exchange\r
+\r
+\r
+ TLS supports three authentication modes: authentication of both\r
+ parties, server authentication with an unauthenticated client, and\r
+ total anonymity. Whenever the server is authenticated, the channel is\r
+ secure against man-in-the-middle attacks, but completely anonymous\r
+ sessions are inherently vulnerable to such attacks. Anonymous\r
+ servers cannot authenticate clients. If the server is authenticated,\r
+ its certificate message must provide a valid certificate chain\r
+ leading to an acceptable certificate authority. Similarly,\r
+ authenticated clients must supply an acceptable certificate to the\r
+ server. Each party is responsible for verifying that the other's\r
+ certificate is valid and has not expired or been revoked.\r
+\r
+\r
+ The general goal of the key exchange process is to create a\r
+ pre_master_secret known to the communicating parties and not to\r
+ attackers. The pre_master_secret will be used to generate the\r
+ master_secret (see Section 8.1). The master_secret is required to |\r
+ generate the finished messages, encryption keys, and MAC secrets (see\r
+ Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished\r
+ message, parties thus prove that they know the correct\r
+ pre_master_secret.\r
+\r
+\r
+F.1.1.1. Anonymous key exchange\r
+\r
+\r
+ Completely anonymous sessions can be established using RSA or Diffie-\r
+ Hellman for key exchange. With anonymous RSA, the client encrypts a\r
+ pre_master_secret with the server's uncertified public key extracted\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 77] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ from the server key exchange message. The result is sent in a client\r
+ key exchange message. Since eavesdroppers do not know the server's\r
+ private key, it will be infeasible for them to decode the |\r
+ pre_master_secret. |\r
+\r
+\r
+ Note: No anonymous RSA Cipher Suites are defined in this document.\r
+\r
+\r
+ With Diffie-Hellman, the server's public parameters are contained in\r
+ the server key exchange message and the client's are sent in the\r
+ client key exchange message. Eavesdroppers who do not know the\r
+ private values should not be able to find the Diffie-Hellman result\r
+ (i.e. the pre_master_secret).\r
+\r
+\r
+ Warning: Completely anonymous connections only provide protection\r
+ against passive eavesdropping. Unless an independent tamper-\r
+ proof channel is used to verify that the finished messages\r
+ were not replaced by an attacker, server authentication is\r
+ required in environments where active man-in-the-middle\r
+ attacks are a concern.\r
+\r
+\r
+F.1.1.2. RSA key exchange and authentication\r
+\r
+\r
+ With RSA, key exchange and server authentication are combined. The\r
+ public key may be either contained in the server's certificate or may\r
+ be a temporary RSA key sent in a server key exchange message. When\r
+ temporary RSA keys are used, they are signed by the server's RSA |\r
+ certificate. The signature includes the current ClientHello.random,\r
+ so old signatures and temporary keys cannot be replayed. Servers may\r
+ use a single temporary RSA key for multiple negotiation sessions.\r
+\r
+\r
+ Note: The temporary RSA key option is useful if servers need large\r
+ certificates but must comply with government-imposed size limits\r
+ on keys used for key exchange.\r
+\r
+\r
+ Note that if ephemeral RSA is not used, compromise of the server's |\r
+ static RSA key results in a loss of confidentiality for all sessions |\r
+ protected under that static key. TLS users desiring Perfect Forward |\r
+ Secrecy should use DHE cipher suites. The damage done by exposure of |\r
+ a private key can be limited by changing one's private key (and |\r
+ certificate) frequently. |\r
+\r
+\r
+ After verifying the server's certificate, the client encrypts a\r
+ pre_master_secret with the server's public key. By successfully\r
+ decoding the pre_master_secret and producing a correct finished\r
+ message, the server demonstrates that it knows the private key\r
+ corresponding to the server certificate.\r
+\r
+\r
+ When RSA is used for key exchange, clients are authenticated using\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 78] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ the certificate verify message (see Section 7.4.8). The client signs\r
+ a value derived from the master_secret and all preceding handshake\r
+ messages. These handshake messages include the server certificate,\r
+ which binds the signature to the server, and ServerHello.random,\r
+ which binds the signature to the current handshake process.\r
+\r
+\r
+F.1.1.3. Diffie-Hellman key exchange with authentication\r
+\r
+\r
+ When Diffie-Hellman key exchange is used, the server can either\r
+ supply a certificate containing fixed Diffie-Hellman parameters or\r
+ can use the server key exchange message to send a set of temporary\r
+ Diffie-Hellman parameters signed with a DSS or RSA certificate.\r
+ Temporary parameters are hashed with the hello.random values before\r
+ signing to ensure that attackers do not replay old parameters. In\r
+ either case, the client can verify the certificate or signature to\r
+ ensure that the parameters belong to the server.\r
+\r
+\r
+ If the client has a certificate containing fixed Diffie-Hellman\r
+ parameters, its certificate contains the information required to\r
+ complete the key exchange. Note that in this case the client and\r
+ server will generate the same Diffie-Hellman result (i.e.,\r
+ pre_master_secret) every time they communicate. To prevent the\r
+ pre_master_secret from staying in memory any longer than necessary,\r
+ it should be converted into the master_secret as soon as possible.\r
+ Client Diffie-Hellman parameters must be compatible with those\r
+ supplied by the server for the key exchange to work.\r
+\r
+\r
+ If the client has a standard DSS or RSA certificate or is\r
+ unauthenticated, it sends a set of temporary parameters to the server\r
+ in the client key exchange message, then optionally uses a\r
+ certificate verify message to authenticate itself.\r
+\r
+\r
+ If the same DH keypair is to be used for multiple handshakes, either |\r
+ because the client or server has a certificate containing a fixed DH |\r
+ keypair or because the server is reusing DH keys, care must be taken |\r
+ to prevent small subgroup attacks. Implementations SHOULD follow the |\r
+ guidelines found in [SUBGROUP]. |\r
+\r
+\r
+ Small subgroup attacks are most easily avoided by using one of the |\r
+ DHE ciphersuites and generating a fresh DH private key (X) for each |\r
+ handshake. If a suitable base (such as 2) is chosen, g^X mod p can be |\r
+ computed very quickly so the performance cost is minimized. |\r
+ Additionally, using a fresh key for each handshake provides Perfect |\r
+ Forward Secrecy. Implementations SHOULD generate a new X for each |\r
+ handshake when using DHE ciphersuites. |\r
+\r
+\r
+F.1.2. Version rollback attacks\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 79] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Because TLS includes substantial improvements over SSL Version 2.0,\r
+ attackers may try to make TLS-capable clients and servers fall back\r
+ to Version 2.0. This attack can occur if (and only if) two TLS-\r
+ capable parties use an SSL 2.0 handshake.\r
+\r
+\r
+ Although the solution using non-random PKCS #1 block type 2 message\r
+ padding is inelegant, it provides a reasonably secure way for Version\r
+ 3.0 servers to detect the attack. This solution is not secure against\r
+ attackers who can brute force the key and substitute a new ENCRYPTED-\r
+ KEY-DATA message containing the same key (but with normal padding)\r
+ before the application specified wait threshold has expired. Parties\r
+ concerned about attacks of this scale should not be using 40-bit\r
+ encryption keys anyway. Altering the padding of the least-significant\r
+ 8 bytes of the PKCS padding does not impact security for the size of\r
+ the signed hashes and RSA key lengths used in the protocol, since\r
+ this is essentially equivalent to increasing the input block size by\r
+ 8 bytes.\r
+\r
+\r
+F.1.3. Detecting attacks against the handshake protocol\r
+\r
+\r
+ An attacker might try to influence the handshake exchange to make the\r
+ parties select different encryption algorithms than they would |\r
+ normally chooses. Because many implementations will support 40-bit\r
+ exportable encryption and some may even support null encryption or\r
+ MAC algorithms, this attack is of particular concern.\r
+\r
+\r
+ For this attack, an attacker must actively change one or more\r
+ handshake messages. If this occurs, the client and server will\r
+ compute different values for the handshake message hashes. As a\r
+ result, the parties will not accept each others' finished messages.\r
+ Without the master_secret, the attacker cannot repair the finished\r
+ messages, so the attack will be discovered.\r
+\r
+\r
+F.1.4. Resuming sessions\r
+\r
+\r
+ When a connection is established by resuming a session, new\r
+ ClientHello.random and ServerHello.random values are hashed with the\r
+ session's master_secret. Provided that the master_secret has not been\r
+ compromised and that the secure hash operations used to produce the\r
+ encryption keys and MAC secrets are secure, the connection should be\r
+ secure and effectively independent from previous connections.\r
+ Attackers cannot use known encryption keys or MAC secrets to\r
+ compromise the master_secret without breaking the secure hash\r
+ operations (which use both SHA and MD5).\r
+\r
+\r
+ Sessions cannot be resumed unless both the client and server agree.\r
+ If either party suspects that the session may have been compromised,\r
+ or that certificates may have expired or been revoked, it should\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 80] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ force a full handshake. An upper limit of 24 hours is suggested for\r
+ session ID lifetimes, since an attacker who obtains a master_secret\r
+ may be able to impersonate the compromised party until the\r
+ corresponding session ID is retired. Applications that may be run in\r
+ relatively insecure environments should not write session IDs to\r
+ stable storage.\r
+\r
+\r
+F.1.5. MD5 and SHA\r
+\r
+\r
+ TLS uses hash functions very conservatively. Where possible, both MD5\r
+ and SHA are used in tandem to ensure that non-catastrophic flaws in\r
+ one algorithm will not break the overall protocol.\r
+\r
+\r
+F.2. Protecting application data\r
+\r
+\r
+ The master_secret is hashed with the ClientHello.random and\r
+ ServerHello.random to produce unique data encryption keys and MAC\r
+ secrets for each connection.\r
+\r
+\r
+ Outgoing data is protected with a MAC before transmission. To prevent\r
+ message replay or modification attacks, the MAC is computed from the\r
+ MAC secret, the sequence number, the message length, the message\r
+ contents, and two fixed character strings. The message type field is\r
+ necessary to ensure that messages intended for one TLS Record Layer\r
+ client are not redirected to another. The sequence number ensures\r
+ that attempts to delete or reorder messages will be detected. Since\r
+ sequence numbers are 64-bits long, they should never overflow.\r
+ Messages from one party cannot be inserted into the other's output,\r
+ since they use independent MAC secrets. Similarly, the server-write\r
+ and client-write keys are independent so stream cipher keys are used\r
+ only once.\r
+\r
+\r
+ If an attacker does break an encryption key, all messages encrypted\r
+ with it can be read. Similarly, compromise of a MAC key can make\r
+ message modification attacks possible. Because MACs are also\r
+ encrypted, message-alteration attacks generally require breaking the\r
+ encryption algorithm as well as the MAC.\r
+\r
+\r
+ Note: MAC secrets may be larger than encryption keys, so messages can\r
+ remain tamper resistant even if encryption keys are broken.\r
+\r
+\r
+F.3. Explicit IVs |\r
+\r
+\r
+ [CBCATT] describes a chosen plaintext attack on TLS that depends |\r
+ on knowing the IV for a record. Previous versions of TLS [TLS1.0] |\r
+ used the CBC residue of the previous record as the IV and |\r
+ therefore enabled this attack. This version uses an explicit IV |\r
+ in order to protect against this attack. |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 81] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+F.4 Security of Composite Cipher Modes |\r
+\r
+\r
+ TLS secures transmitted application data via the use of symmetric |\r
+ encryption and authentication functions defined in the negotiated |\r
+ ciphersuite. The objective is to protect both the integrity and |\r
+ confidentiality of the transmitted data from malicious actions by |\r
+ active attackers in the network. It turns out that the order in |\r
+ which encryption and authentication functions are applied to the |\r
+ data plays an important role for achieving this goal [ENCAUTH]. |\r
+\r
+\r
+ The most robust method, called encrypt-then-authenticate, first |\r
+ applies encryption to the data and then applies a MAC to the |\r
+ ciphertext. This method ensures that the integrity and |\r
+ confidentiality goals are obtained with ANY pair of encryption |\r
+ and MAC functions provided that the former is secure against |\r
+ chosen plaintext attacks and the MAC is secure against chosen- |\r
+ message attacks. TLS uses another method, called authenticate- |\r
+ then-encrypt, in which first a MAC is computed on the plaintext |\r
+ and then the concatenation of plaintext and MAC is encrypted. |\r
+ This method has been proven secure for CERTAIN combinations of |\r
+ encryption functions and MAC functions, but is not guaranteed to |\r
+ be secure in general. In particular, it has been shown that there |\r
+ exist perfectly secure encryption functions (secure even in the |\r
+ information theoretic sense) that combined with any secure MAC |\r
+ function fail to provide the confidentiality goal against an |\r
+ active attack. Therefore, new ciphersuites and operation modes |\r
+ adopted into TLS need to be analyzed under the authenticate-then- |\r
+ encrypt method to verify that they achieve the stated integrity |\r
+ and confidentiality goals. |\r
+\r
+\r
+ Currently, the security of the authenticate-then-encrypt method |\r
+ has been proven for some important cases. One is the case of |\r
+ stream ciphers in which a computationally unpredictable pad of |\r
+ the length of the message plus the length of the MAC tag is |\r
+ produced using a pseudo-random generator and this pad is xor-ed |\r
+ with the concatenation of plaintext and MAC tag. The other is |\r
+ the case of CBC mode using a secure block cipher. In this case, |\r
+ security can be shown if one applies one CBC encryption pass to |\r
+ the concatenation of plaintext and MAC and uses a new, |\r
+ independent and unpredictable, IV for each new pair of plaintext |\r
+ and MAC. In previous versions of SSL, CBC mode was used properly |\r
+ EXCEPT that it used a predictable IV in the form of the last |\r
+ block of the previous ciphertext. This made TLS open to chosen |\r
+ plaintext attacks. This verson of the protocol is immune to |\r
+ those attacks. For exact details in the encryption modes proven |\r
+ secure see [ENCAUTH]. |\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 82] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+F.5 Denial of Service |\r
+\r
+\r
+ TLS is susceptible to a number of denial of service (DoS) |\r
+ attacks. In particular, an attacker who initiates a large number |\r
+ of TCP connections can cause a server to consume large amounts of |\r
+ CPU doing RSA decryption. However, because TLS is generally used |\r
+ over TCP, it is difficult for the attacker to hide his point of |\r
+ origin if proper TCP SYN randomization is used [SEQNUM] by the |\r
+ TCP stack. |\r
+\r
+\r
+ Because TLS runs over TCP, it is also susceptible to a number of |\r
+ denial of service attacks on individual connections. In |\r
+ particular, attackers can forge RSTs, terminating connections, or |\r
+ forge partial TLS records, causing the connection to stall. |\r
+ These attacks cannot in general be defended against by a TCP- |\r
+ using protocol. Implementors or users who are concerned with this |\r
+ class of attack should use IPsec AH [AH] or ESP [ESP]. |\r
+\r
+\r
+F.6. Final notes\r
+\r
+\r
+ For TLS to be able to provide a secure connection, both the client\r
+ and server systems, keys, and applications must be secure. In\r
+ addition, the implementation must be free of security errors.\r
+\r
+\r
+ The system is only as strong as the weakest key exchange and\r
+ authentication algorithm supported, and only trustworthy\r
+ cryptographic functions should be used. Short public keys, 40-bit\r
+ bulk encryption keys, and anonymous servers should be used with great\r
+ caution. Implementations and users must be careful when deciding\r
+ which certificates and certificate authorities are acceptable; a\r
+ dishonest certificate authority can do tremendous damage.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 83] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+G. Patent Statement\r
+\r
+\r
+ Netscape Communications Corporation (now America Online) has a patent |\r
+ claim on the Secure Sockets Layer (SSL) work that this standard is |\r
+ based on. The Internet Standards Process as defined in RFC 2026 |\r
+ requests that a statement be obtained from a Patent holder indicating |\r
+ that a license will be made available to applicants under reasonable |\r
+ terms and conditions.\r
+\r
+\r
+ Secure Socket Layer Application Program Apparatus And Method\r
+ ("SSL"), No. 5,657,390\r
+\r
+\r
+ Netscape Communications has issued the following statement:\r
+\r
+\r
+ Intellectual Property Rights\r
+\r
+\r
+ Secure Sockets Layer\r
+\r
+\r
+ The United States Patent and Trademark Office ("the PTO")\r
+ recently issued U.S. Patent No. 5,657,390 ("the SSL Patent") to\r
+ Netscape for inventions described as Secure Sockets Layers\r
+ ("SSL"). The IETF is currently considering adopting SSL as a\r
+ transport protocol with security features. Netscape encourages\r
+ the royalty-free adoption and use of the SSL protocol upon the\r
+ following terms and conditions:\r
+\r
+\r
+ * If you already have a valid SSL Ref license today which\r
+ includes source code from Netscape, an additional patent\r
+ license under the SSL patent is not required.\r
+\r
+\r
+ * If you don't have an SSL Ref license, you may have a royalty\r
+ free license to build implementations covered by the SSL\r
+ Patent Claims or the IETF TLS specification provided that you\r
+ do not to assert any patent rights against Netscape or other\r
+ companies for the implementation of SSL or the IETF TLS\r
+ recommendation.\r
+\r
+\r
+ What are "Patent Claims":\r
+\r
+\r
+ Patent claims are claims in an issued foreign or domestic patent\r
+ that:\r
+\r
+\r
+ 1) must be infringed in order to implement methods or build\r
+ products according to the IETF TLS specification; or\r
+\r
+\r
+ 2) patent claims which require the elements of the SSL patent\r
+ claims and/or their equivalents to be infringed.\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 84] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ The Internet Society, Internet Architecture Board, Internet\r
+ Engineering Steering Group and the Corporation for National Research\r
+ Initiatives take no position on the validity or scope of the patents\r
+ and patent applications, nor on the appropriateness of the terms of\r
+ the assurance. The Internet Society and other groups mentioned above\r
+ have not made any determination as to any other intellectual property\r
+ rights which may apply to the practice of this standard. Any further\r
+ consideration of these matters is the user's own responsibility.\r
+\r
+\r
+Security Considerations\r
+\r
+\r
+ Security issues are discussed throughout this memo, especially in |\r
+ Appendices D, E, and F.\r
+\r
+\r
+Normative References |\r
+\r
+\r
+ [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," |\r
+ IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.\r
+\r
+\r
+ [DES] ANSI X3.106, "American National Standard for Information\r
+ Systems-Data Link Encryption," American National Standards\r
+ Institute, 1983.\r
+\r
+\r
+ [DH1] W. Diffie and M. E. Hellman, "New Directions in\r
+ Cryptography," IEEE Transactions on Information Theory, V.\r
+ IT-22, n. 6, Jun 1977, pp. 74-84.\r
+\r
+\r
+ [DSS] NIST FIPS PUB 186, "Digital Signature Standard," National\r
+ Institute of Standards and Technology, U.S. Department of\r
+ Commerce, May 18, 1994.\r
+\r
+\r
+ [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-\r
+ Hashing for Message Authentication," RFC 2104, February\r
+ 1997.\r
+\r
+\r
+ [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH\r
+ Series in Information Processing, v. 1, Konstanz: Hartung-\r
+ Gorre Verlag, 1992.\r
+\r
+\r
+ [MD2] Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,\r
+ April 1992.\r
+\r
+\r
+ [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,\r
+ April 1992.\r
+\r
+\r
+ [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard,"\r
+ version 1.5, November 1993.\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 85] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax\r
+ Standard," version 1.5, November 1993.\r
+\r
+\r
+ [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax\r
+ Standard," version 1.5, November 1993.\r
+\r
+\r
+ [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet\r
+ Public Key Infrastructure: Part I: X.509 Certificate and CRL\r
+ Profile", RFC 2459, January 1999.\r
+\r
+\r
+ [RC2] Rivest, R., "A Description of the RC2(r) Encryption\r
+ Algorithm", RFC 2268, January 1998.\r
+\r
+\r
+ [RC4] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption\r
+ Algorithm, Work in Progress.\r
+\r
+\r
+ [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for\r
+ Obtaining Digital Signatures and Public-Key Cryptosystems,"\r
+ Communications of the ACM, v. 21, n. 2, Feb 1978, pp.\r
+ 120-126.\r
+\r
+\r
+ [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National\r
+ Institute of Standards and Technology, U.S. Department of\r
+ Commerce, Work in Progress, May 31, 1994.\r
+\r
+\r
+ [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications\r
+ Corp., Feb 9, 1995.\r
+\r
+\r
+ [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",\r
+ Netscape Communications Corp., Nov 18, 1996.\r
+\r
+\r
+ [REQ] Bradner, S., "Key words for use in RFCs to Indicate |\r
+ Requirement Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+\r
+ [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0", |\r
+ RFC 2246, January 1999.\r
+\r
+\r
+ [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J., |\r
+ Wright, T., "Transport Layer Security (TLS) Extensions", RFC |\r
+ 3546, June 2003.\r
+ [X509] CCITT. Recommendation X.509: "The Directory - Authentication\r
+ Framework". 1988.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 86] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+Informative References |\r
+\r
+\r
+ [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC |\r
+ 2402, November 1998. |\r
+\r
+\r
+ [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against |\r
+ Protocols Based on RSA Encryption Standard PKCS #1" in |\r
+ Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: |\r
+ 1-12, 1998. |\r
+\r
+\r
+ [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: |\r
+ Problems and Countermeasures", |\r
+ http://www.openssl.org/~bodo/tls-cbc.txt. |\r
+\r
+\r
+ [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel", |\r
+ http://lasecwww.epfl.ch/memo_ssl.shtml, 2003. |\r
+\r
+\r
+ [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication |\r
+ for Protecting Communications (Or: How Secure is SSL?)", |\r
+ Crypto 2001. |\r
+\r
+\r
+ [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security |\r
+ Payload (ESP)", RFC 2406, November 1998. |\r
+\r
+\r
+ [FTP] Postel J., and J. Reynolds, "File Transfer Protocol", STD 9, |\r
+ RFC 959, October 1985. |\r
+\r
+\r
+ [HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext |\r
+ Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |\r
+\r
+\r
+ [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based |\r
+ Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, |\r
+ March 2003. |\r
+ [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 |\r
+\r
+\r
+ [SCH] B. Schneier. Applied Cryptography: Protocols, Algorithms, |\r
+ and Source Code in C, Published by John Wiley & Sons, Inc. |\r
+ 1994. |\r
+\r
+\r
+ [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks", |\r
+ RFC 1948, May 1996. |\r
+\r
+\r
+ [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup |\r
+ Attacks on the Diffie-Hellman Key Agreement Method for |\r
+ S/MIME", RFC 2785, March 2000. |\r
+\r
+\r
+ [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, |\r
+ September 1981. |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 87] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are |\r
+ practical", USENIX Security Symposium 2003. |\r
+\r
+\r
+ [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External\r
+ Data Representation Standard, August 1995.\r
+\r
+\r
+\r
+Credits |\r
+\r
+\r
+ Working Group Chairs |\r
+ Win Treese\r
+ EMail: treese@acm.org |\r
+\r
+\r
+ Eric Rescorla |\r
+ EMail: ekr@rtfm.com |\r
+\r
+\r
+\r
+ Editors\r
+\r
+\r
+ Tim Dierks Eric Rescorla |\r
+ Google RTFM, Inc. |\r
+\r
+\r
+ EMail: tim@dierks.org EMail: ekr@rtfm.com |\r
+\r
+\r
+\r
+\r
+ Other contributors\r
+\r
+\r
+ Christopher Allen (co-editor of TLS 1.0) |\r
+ Alacrity Ventures |\r
+ ChristopherA@AlacrityVentures.com |\r
+\r
+\r
+ Martin Abadi |\r
+ University of California, Santa Cruz |\r
+ abadi@cs.ucsc.edu |\r
+\r
+\r
+ Ran Canetti |\r
+ IBM |\r
+ canetti@watson.ibm.com |\r
+\r
+\r
+ Taher Elgamal |\r
+ taher@securify.com |\r
+ Securify |\r
+\r
+\r
+ Anil Gangolli |\r
+ Structured Arts |\r
+\r
+\r
+ Kipp Hickman |\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 88] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+ Phil Karlton (co-author of SSLv3) |\r
+\r
+\r
+ Paul Kocher (co-author of SSLv3) |\r
+ Cryptography Research |\r
+ paul@cryptography.com |\r
+\r
+\r
+ Hugo Krawczyk |\r
+ Technion Israel Institute of Technology |\r
+ hugo@ee.technion.ac.il |\r
+\r
+\r
+ Robert Relyea |\r
+ Netscape Communications |\r
+ relyea@netscape.com |\r
+\r
+\r
+ Jim Roskind |\r
+ Netscape Communications |\r
+ jar@netscape.com |\r
+\r
+\r
+ Michael Sabin |\r
+\r
+\r
+ Dan Simon |\r
+ Microsoft, Inc. |\r
+ dansimon@microsoft.com |\r
+\r
+\r
+ Tom Weinstein |\r
+\r
+\r
+Comments\r
+\r
+\r
+ The discussion list for the IETF TLS working group is located at the\r
+ e-mail address <ietf-tls@lists.consensus.com>. Information on the\r
+ group and information on how to subscribe to the list is at\r
+ <http://lists.consensus.com/>.\r
+\r
+\r
+ Archives of the list can be found at:\r
+ <http://www.imc.org/ietf-tls/mail-archive/>\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 89] draft-ietf-tls-rfc2246-bis-06.txt TLS March 2004\r
+\r
+\r
+\r
+Full Copyright Statement\r
+\r
+\r
+ Copyright (C) The Internet Society (1999). All Rights Reserved.\r
+\r
+\r
+ This document and translations of it may be copied and furnished to\r
+ others, and derivative works that comment on or otherwise explain it\r
+ or assist in its implementation may be prepared, copied, published\r
+ and distributed, in whole or in part, without restriction of any\r
+ kind, provided that the above copyright notice and this paragraph are\r
+ included on all such copies and derivative works. However, this\r
+ document itself may not be modified in any way, such as by removing\r
+ the copyright notice or references to the Internet Society or other\r
+ Internet organizations, except as needed for the purpose of\r
+ developing Internet standards in which case the procedures for\r
+ copyrights defined in the Internet Standards process must be\r
+ followed, or as required to translate it into languages other than\r
+ English.\r
+\r
+\r
+ The limited permissions granted above are perpetual and will not be\r
+ revoked by the Internet Society or its successors or assigns.\r
+\r
+\r
+ This document and the information contained herein is provided on an\r
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Dierks & Rescorla Standards Track [Page 90]
\ No newline at end of file
projects / thirdparty / gnutls.git / commitdiff
