diff options
Diffstat (limited to 'doc/protocol/draft-ietf-tls-rfc4346-bis-01.txt')
| -rw-r--r-- | doc/protocol/draft-ietf-tls-rfc4346-bis-01.txt | 5994 |
1 files changed, 0 insertions, 5994 deletions
diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-01.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-01.txt deleted file mode 100644 index 1bf30d4cc8..0000000000 --- a/doc/protocol/draft-ietf-tls-rfc4346-bis-01.txt +++ /dev/null @@ -1,5994 +0,0 @@ - - Tim Dierks - Independent - Eric Rescorla -INTERNET-DRAFT Network Resonance, Inc. -<draft-ietf-tls-rfc4346-bis-01.txt> June 2006 (Expires December 2006) - - The TLS Protocol - Version 1.2 - -Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - 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." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document specifies Version 1.2 of the Transport Layer Security - (TLS) protocol. The TLS protocol provides communications security - 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 4 - 1.1 Differences from TLS 1.1 5 - 1.1 Requirements Terminology 5 - - - -Dierks & Rescorla Standards Track [Page 1] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 2. Goals 5 - 3. Goals of this document 6 - 4. Presentation language 6 - 4.1. Basic block size 7 - 4.2. Miscellaneous 7 - 4.3. Vectors 7 - 4.4. Numbers 8 - 4.5. Enumerateds 8 - 4.6. Constructed types 9 - 4.6.1. Variants 10 - 4.7. Cryptographic attributes 11 - 4.8. Constants 12 - 5. HMAC and the pseudorandom function 12 - 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 18 - 6.2.3. Record payload protection 18 - 6.2.3.1. Null or standard stream cipher 19 - 6.2.3.2. CBC block cipher 20 - 6.3. Key calculation 22 - 7. The TLS Handshaking Protocols 23 - 7.1. Change cipher spec protocol 25 - 7.2. Alert protocol 25 - 7.2.1. Closure alerts 26 - 7.2.2. Error alerts 27 - 7.3. Handshake Protocol overview 31 - 7.4. Handshake protocol 35 - 7.4.1. Hello messages 36 - 7.4.1.1. Hello request 36 - 7.4.1.2. Client hello 37 - 7.4.1.3. Server hello 40 - 7.4.1.4 Hello Extensions 41 - 7.4.1.4.1 Server Name Indication 43 - 7.4.1.4.2 Maximum Fragment Length Negotiation 44 - 7.4.1.4.3 Client Certificate URLs 46 - 7.4.1.4.4 Trusted CA Indication 46 - 7.4.1.4.5 Truncated HMAC 48 - 7.4.1.4.6 Certificate Status Request 49 - 7.4.1.4.7 Cert Hash Types 50 - 7.4.1.4.8 Procedure for Defining New Extensions 51 - 7.4.2. Server certificate 52 - 7.4.3. Server key exchange message 53 - 7.4.4. CertificateStatus 56 - 7.4.5. Certificate request 56 - 7.4.6. Server hello done 58 - 7.4.7. Client certificate 59 - - - -Dierks & Rescorla Standards Track [Page 2] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 7.4.8. Client Certificate URLs 59 - 7.4.9. Client key exchange message 61 - 7.4.9.1. RSA encrypted premaster secret message 62 - 7.4.9.2. Client Diffie-Hellman public value 64 - 7.4.10. Certificate verify 65 - 7.4.10. Finished 65 - 8. Cryptographic computations 66 - 8.1. Computing the master secret 67 - 8.1.1. RSA 68 - 8.1.2. Diffie-Hellman 68 - 9. Mandatory Cipher Suites 68 - A. Protocol constant values 72 - A.1. Record layer 72 - A.2. Change cipher specs message 73 - A.3. Alert messages 73 - A.4. Handshake protocol 75 - A.4.1. Hello messages 75 - A.4.2. Server authentication and key exchange messages 78 - A.4.3. Client authentication and key exchange messages 79 - A.4.4. Handshake finalization message 80 - A.5. The CipherSuite 81 - A.6. The Security Parameters 84 - B. Glossary 85 - C. CipherSuite definitions 89 - D. Implementation Notes 91 - D.1 Random Number Generation and Seeding 91 - D.2 Certificates and authentication 91 - D.3 CipherSuites 91 - E. Backward Compatibility With SSL 92 - E.1. Version 2 client hello 93 - E.2. Avoiding man-in-the-middle version rollback 94 - F. Security analysis 96 - F.1. Handshake protocol 96 - F.1.1. Authentication and key exchange 96 - F.1.1.1. Anonymous key exchange 96 - F.1.1.2. RSA key exchange and authentication 97 - F.1.1.3. Diffie-Hellman key exchange with authentication 98 - F.1.2. Version rollback attacks 98 - F.1.3. Detecting attacks against the handshake protocol 99 - F.1.4. Resuming sessions 99 - F.1.5 Extensions 100 - F.1.5.1 Security of server_name 100 - F.1.5.2 Security of client_certificate_url 101 - F.1.5.4. Security of trusted_ca_keys 102 - F.1.5.5. Security of truncated_hmac 102 - F.1.5.6. Security of status_request 103 - F.2. Protecting application data 103 - F.3. Explicit IVs 104 - - - -Dierks & Rescorla Standards Track [Page 3] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - F.4 Security of Composite Cipher Modes 104 - F.5 Denial of Service 105 - F.6. Final notes 105 - - -Change history - - 18-Feb-06 First draft by ekr@rtfm.com - - -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 [SCH], 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 - - - -Dierks & Rescorla Standards Track [Page 4] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - secret is unavailable to eavesdroppers, and for any authenticated - connection the secret cannot be obtained, even by an attacker who - can place himself in the middle of the connection. - - - The negotiation is reliable: no attacker can modify the - negotiation communication without being detected by the parties - to the communication. - - One advantage of TLS is that it is application protocol independent. - Higher level protocols can layer on top of the TLS Protocol - transparently. The TLS standard, however, does not specify how - protocols add security with TLS; the decisions on how to initiate TLS - handshaking and how to interpret the authentication certificates - exchanged are left up to the judgment of the designers and - implementors of protocols which run on top of TLS. - -1.1 Differences from TLS 1.1 - This document is a revision of the TLS 1.1 [TLS1.1] protocol which - contains improved flexibility, particularly for negotiation of - cryptographic algorithms. The major changes are: - - - Merged in TLS Extensions and AES Cipher Suites from external - documents. - - - Replacement of MD5/SHA-1 combination in the PRF - - - Replacement of MD5/SHA-1 combination in the digitally-signed - element. - - - Allow the client to indicate which hash functions it supports. - - - Allow the server to indicate which has functions it supports - -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 - - - -Dierks & Rescorla Standards Track [Page 5] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 the various versions of TLS and SSL 3.0 do - not interoperate (although each protocol incorporates a mechanism by - which an implementation can back down prior versions. This document - is intended primarily for readers who will be implementing the - protocol and those doing cryptographic analysis of it. The - specification has been written with this in mind, and it is intended - to reflect the needs of those two groups. For that reason, many of - the algorithm-dependent data structures and rules are included in the - body of the text (as opposed to in an appendix), providing easier - access to them. - - This document is not intended to supply any details of service - definition nor interface definition, although it does cover select - areas of policy as they are required for the maintenance of solid - 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 6] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -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 7] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 8] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 9] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 10] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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, the output of the chosen hash function is encoded as - a PKCS #1 DigestInfo and then signed using block type 01 as described - in Section 8.1 as described in [PKCS1A]. - - Note: the standard reference for PKCS#1 is now RFC 3447 [PKCS1B]. - However, to minimize differences with TLS 1.0 text, we are using the - terminology of RFC 2313 [PKCS1A]. - - In DSS, the 20 bytes of the SHA-1 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 - - - -Dierks & Rescorla Standards Track [Page 11] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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. - - An RSA encrypted value is encoded with PKCS #1 block type 2 as - described in [PKCS1A]. - - 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]. - - - -Dierks & Rescorla Standards Track [Page 12] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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. - - 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 applying P_hash to the secret S. The hash - function used in P MUST be the same hash function selected for the - HMAC in the cipher suite. - - 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 - - -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. - - - - -Dierks & Rescorla Standards Track [Page 13] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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.1). All such - values must be defined by RFC 2434 Standards Action. See section 11 - for IANA Considerations for ContentType values. - - 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. - -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 Change Cipher Spec 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). - - - -Dierks & Rescorla Standards Track [Page 14] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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. - - 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, idea, aes } BulkCipherAlgorithm; - - enum { stream, block } CipherType; - - 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; - MACAlgorithm mac_algorithm; - uint8 hash_size; - CompressionMethod compression_algorithm; - opaque master_secret[48]; - opaque client_random[32]; - opaque server_random[32]; - } SecurityParameters; - - - - -Dierks & Rescorla Standards Track [Page 15] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 - 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 - - - - -Dierks & Rescorla Standards Track [Page 16] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 { - 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.2, which uses the version { 3, 3 }. The - version value 3.3 is historical, deriving from the use of 3.1 for - TLS 1.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. However, records MUST - be delivered to the network in the same order as they are - protected by the record layer. Recipients MUST receive and - process interleaved application layer traffic during handshakes - - - -Dierks & Rescorla Standards Track [Page 17] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - subsequent to the first one on a connection. - - -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. - - 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; - - - -Dierks & Rescorla Standards Track [Page 18] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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. - - 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 - - - -Dierks & Rescorla Standards Track [Page 19] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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, DES, or AES), the encryption and MAC - functions convert TLSCompressed.fragment structures to and from block - TLSCiphertext.fragment structures. - - 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. See Sections 6.1, 6.2.3.2 and 6.3, - of [TLS1.0] for details of TLS 1.0 IV handling. - - One of the following two algorithms SHOULD be used to generate the - per-record IV: - - (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 - - - -Dierks & Rescorla Standards Track [Page 20] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 2(a) or 2(b) 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) - - 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 - - - -Dierks & Rescorla Standards Track [Page 21] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 - 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. - - - - -Dierks & Rescorla Standards Track [Page 22] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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. - - 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 - 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 currently defined which requires the most material is - AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte - keys and 2 x 20 byte MAC secrets, for a total 104 bytes of key - material. - -7. The TLS Handshaking Protocols - - TLS has three subprotocols 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 - - - -Dierks & Rescorla Standards Track [Page 23] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 - - 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.11 - - Note: if a rehandshake occurs while data is flowing on a connection, - the communicating parties may continue to send data using the old - CipherSpec. However, once the ChangeCipherSpec has been sent, the new - - - -Dierks & Rescorla Standards Track [Page 24] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - CipherSpec MUST be used. The first side to send the ChangeCipherSpec - does not know that the other side has finished computing the new - keying material (e.g. if it has to perform a time consuming public - key operation). Thus, a small window of time during which the - recipient must buffer the data MAY exist. In practice, with modern - machines this interval is likely to be fairly short. - -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), - illegal_parameter(47), - unknown_ca(48), - access_denied(49), - decode_error(50), - decrypt_error(51), - export_restriction_RESERVED(60), - protocol_version(70), - insufficient_security(71), - internal_error(80), - user_canceled(90), - no_renegotiation(100), - unsupported_extension(110), /* new */ - certificate_unobtainable(111), /* new */ - - - -Dierks & Rescorla Standards Track [Page 25] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - unrecognized_name(112), /* new */ - bad_certificate_status_response(113), /* new */ - bad_certificate_hash_value(114), /* new */ - (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. Note that as of TLS 1.1, - failure to properly close a connection no longer requires that a - session not be resumed. This is a change from TLS 1.0 to conform - with widespread implementation practice. - - 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 - 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. - - Note: It is assumed that closing a connection reliably delivers - - - -Dierks & Rescorla Standards Track [Page 26] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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. Thus, any connection terminated with a fatal alert - MUST NOT be resumed. 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 MUST be returned if an alert is sent because - 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. - - Note: 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 - 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 - - - -Dierks & Rescorla Standards Track [Page 27] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 - 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. - - - -Dierks & Rescorla Standards Track [Page 28] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - export_restriction_RESERVED - This alert was used in TLS 1.0 but not TLS 1.1. - - 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 - point. This message is always a warning. - - The following error alerts apply only to the extensions described - in Section XXX. To avoid "breaking" existing clients and servers, - these alerts MUST NOT be sent unless the sending party has - received an extended hello message from the party they are - communicating with. - - unsupported_extension - sent by clients that receive an extended server hello containing - - - -Dierks & Rescorla Standards Track [Page 29] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - an extension that they did not put in the corresponding client - hello (see Section 2.3). This message is always fatal. - - unrecognized_name - sent by servers that receive a server_name extension request, but - do not recognize the server name. This message MAY be fatal. - - certificate_unobtainable - sent by servers who are unable to retrieve a certificate chain - from the URL supplied by the client (see Section 3.3). This - message MAY be fatal - for example if client authentication is - required by the server for the handshake to continue and the - server is unable to retrieve the certificate chain, it may send a - fatal alert. - - bad_certificate_status_response - sent by clients that receive an invalid certificate status - response (see Section 3.6). This message is always fatal. - - bad_certificate_hash_value - sent by servers when a certificate hash does not match a client - provided certificate_hash. This message is always fatal. - - 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 - 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. - - New alerts values MUST be defined by RFC 2434 Standards Action. See - Section 11 for IANA Considerations for alert values. - -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 - - - -Dierks & Rescorla Standards Track [Page 30] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 31] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 32] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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.) Application data MUST NOT be sent prior to the - completion of the first handshake (before a cipher suite other - TLS_NULL_WITH_NULL_NULL is established). - Client Server - - ClientHello --------> - ServerHello - Certificate* - CertificateStatus* - ServerKeyExchange* - CertificateRequest* - <-------- ServerHelloDone - Certificate* - CertificateURL* - 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 33] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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), certificate_url(21), certificate_status(22), - (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; - case certificate_url: CertificateURL; - - - -Dierks & Rescorla Standards Track [Page 34] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - case certificate_status: CertificateStatus; - } body; - } Handshake; - - 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. - - New Handshake message type values MUST be defined via RFC 2434 - Standards Action. See Section 11 for IANA Considerations for these - values. - -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. - - - - -Dierks & Rescorla Standards Track [Page 35] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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. - -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, ignoring leap - seconds) 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 - - - -Dierks & Rescorla Standards Track [Page 36] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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>; - - 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; - - If the client wishes to use extensions (see Section XXX), - it may send an ExtendedClientHello: - - 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 37] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - Extension client_hello_extension_list<0..2^16-1>; - } ExtendedClientHello; - - These two messages can be distinguished by determining whether there - are bytes following what would be the end of the 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. - - 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. - - client_hello_extension_list - Clients MAY request extended functionality from servers by - sending data in the client_hello_extension_list. Here the new - "client_hello_extension_list" field contains a list of - extensions. The actual "Extension" format is defined in Section - XXX. - - In the event that a client requests additional functionality - using the extended client hello, and this functionality is not - supplied by the server, the client MAY abort the handshake. - - - -Dierks & Rescorla Standards Track [Page 38] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - A server that supports the extensions mechanism MUST accept only - client hello messages in either the original or extended - ClientHello ormat, and (as for all other messages) MUST check - that the amount of data in the message precisely matches one of - these formats; if not then it MUST send a fatal "decode_error" - alert. - - - 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. - - -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; - - If the server is sending an extension, it should use the - ExtendedServerHello: - - struct { - ProtocolVersion server_version; - Random random; - SessionID session_id; - CipherSuite cipher_suite; - CompressionMethod compression_method; - Extension server_hello_extension_list<0..2^16-1>; - } ExtendedServerHello; - - These two messages can be distinguished by determining whether there - are bytes following what would be the end of the ServerHello. - - - - - - - -Dierks & Rescorla Standards Track [Page 39] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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. - - server_hello_extension_list - A list of extensions. Note that only extensions offered by the client - can appear in the server's list. - -7.4.1.4 Hello Extensions - - The extension format for extended client hellos and extended server - hellos is: - - struct { - ExtensionType extension_type; - opaque extension_data<0..2^16-1>; - } Extension; - - - - -Dierks & Rescorla Standards Track [Page 40] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - Here: - - - "extension_type" identifies the particular extension type. - - - "extension_data" contains information specific to the particular - extension type. - - The extension types defined in this document are: - - enum { - server_name(0), max_fragment_length(1), - client_certificate_url(2), trusted_ca_keys(3), - truncated_hmac(4), status_request(5), - cert_hash_types(6), (65535) - } ExtensionType; - - The list of defined extension types is maintained by the IANA. The - current list can be found at XXX (suggest - http://www.iana.org/assignments/tls-extensions). See sections XXX and - YYY for more information on how new values are added. - - - Note that for all extension types (including those defined in - future), the extension type MUST NOT appear in the extended server - hello unless the same extension type appeared in the corresponding - client hello. Thus clients MUST abort the handshake if they receive - an extension type in the extended server hello that they did not - request in the associated (extended) client hello. - - Nonetheless "server oriented" extensions may be provided in the - future within this framework - such an extension, say of type x, - would require the client to first send an extension of type x in the - (extended) client hello with empty extension_data to indicate that it - supports the extension type. In this case the client is offering the - capability to understand the extension type, and the server is taking - the client up on its offer. - - Also note that when multiple extensions of different types are - present in the extended client hello or the extended server hello, - the extensions may appear in any order. There MUST NOT be more than - one extension of the same type. - - An extended client hello may be sent both when starting a new session - and when requesting session resumption. Indeed a client that - requests resumption of a session does not in general know whether the - server will accept this request, and therefore it SHOULD send an - extended client hello if it would normally do so for a new session. - In general the specification of each extension type must include a - - - -Dierks & Rescorla Standards Track [Page 41] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - discussion of the effect of the extension both during new sessions - and during resumed sessions. - - Note also that all the extensions defined in this document are - relevant only when a session is initiated. When a client includes one - or more of the defined extension types in an extended client hello - while requesting session resumption: - - - If the resumption request is denied, the use of the extensions - is negotiated as normal. - - - If, on the other hand, the older session is resumed, then the - server MUST ignore the extensions and send a server hello - containing none of the extension types; in this case the - functionality of these extensions negotiated during the original - session initiation is applied to the resumed session. - -7.4.1.4.1 Server Name Indication - - [TLS1.1] does not provide a mechanism for a client to tell a server - the name of the server it is contacting. It may be desirable for - clients to provide this information to facilitate secure connections - to servers that host multiple 'virtual' servers at a single - underlying network address. - - In order to provide the server name, clients MAY include an extension - of type "server_name" in the (extended) client hello. The - "extension_data" field of this extension SHALL contain - "ServerNameList" where: - - struct { - NameType name_type; - select (name_type) { - case host_name: HostName; - } name; - } ServerName; - - enum { - host_name(0), (255) - } NameType; - - opaque HostName<1..2^16-1>; - - struct { - ServerName server_name_list<1..2^16-1> - } ServerNameList; - - Currently the only server names supported are DNS hostnames, however - - - -Dierks & Rescorla Standards Track [Page 42] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - this does not imply any dependency of TLS on DNS, and other name - types may be added in the future (by an RFC that Updates this - document). TLS MAY treat provided server names as opaque data and - pass the names and types to the application. - - "HostName" contains the fully qualified DNS hostname of the server, - as understood by the client. The hostname is represented as a byte - string using UTF-8 encoding [UTF8], without a trailing dot. - - If the hostname labels contain only US-ASCII characters, then the - client MUST ensure that labels are separated only by the byte 0x2E, - representing the dot character U+002E (requirement 1 in section 3.1 - of [IDNA] notwithstanding). If the server needs to match the HostName - against names that contain non-US-ASCII characters, it MUST perform - the conversion operation described in section 4 of [IDNA], treating - the HostName as a "query string" (i.e. the AllowUnassigned flag MUST - be set). Note that IDNA allows labels to be separated by any of the - Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore - servers MUST accept any of these characters as a label separator. If - the server only needs to match the HostName against names containing - exclusively ASCII characters, it MUST compare ASCII names case- - insensitively. - - Literal IPv4 and IPv6 addresses are not permitted in "HostName". It - is RECOMMENDED that clients include an extension of type - "server_name" in the client hello whenever they locate a server by a - supported name type. - - A server that receives a client hello containing the "server_name" - extension, MAY use the information contained in the extension to - guide its selection of an appropriate certificate to return to the - client, and/or other aspects of security policy. In this event, the - server SHALL include an extension of type "server_name" in the - (extended) server hello. The "extension_data" field of this - extension SHALL be empty. - - If the server understood the client hello extension but does not - recognize the server name, it SHOULD send an "unrecognized_name" - alert (which MAY be fatal). - - If an application negotiates a server name using an application - protocol, then upgrades to TLS, and a server_name extension is sent, - then the extension SHOULD contain the same name that was negotiated - in the application protocol. If the server_name is established in - the TLS session handshake, the client SHOULD NOT attempt to request a - different server name at the application layer. - -7.4.1.4.2 Maximum Fragment Length Negotiation - - - -Dierks & Rescorla Standards Track [Page 43] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - By default, TLS uses fixed maximum plaintext fragment length of 2^14 - bytes. It may be desirable for constrained clients to negotiate a - smaller maximum fragment length due to memory limitations or - bandwidth limitations. - - In order to negotiate smaller maximum fragment lengths, clients MAY - include an extension of type "max_fragment_length" in the (extended) - client hello. The "extension_data" field of this extension SHALL - contain: - - enum{ - 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) - } MaxFragmentLength; - - whose value is the desired maximum fragment length. The allowed - values for this field are: 2^9, 2^10, 2^11, and 2^12. - - Servers that receive an extended client hello containing a - "max_fragment_length" extension, MAY accept the requested maximum - fragment length by including an extension of type - "max_fragment_length" in the (extended) server hello. The - "extension_data" field of this extension SHALL contain - "MaxFragmentLength" whose value is the same as the requested maximum - fragment length. - - If a server receives a maximum fragment length negotiation request - for a value other than the allowed values, it MUST abort the - handshake with an "illegal_parameter" alert. Similarly, if a client - receives a maximum fragment length negotiation response that differs - from the length it requested, it MUST also abort the handshake with - an "illegal_parameter" alert. - - Once a maximum fragment length other than 2^14 has been successfully - negotiated, the client and server MUST immediately begin fragmenting - messages (including handshake messages), to ensure that no fragment - larger than the negotiated length is sent. Note that TLS already - requires clients and servers to support fragmentation of handshake - messages. - - The negotiated length applies for the duration of the session - including session resumptions. - - The negotiated length limits the input that the record layer may - process without fragmentation (that is, the maximum value of - TLSPlaintext.length; see [TLS] section 6.2.1). Note that the output - of the record layer may be larger. For example, if the negotiated - length is 2^9=512, then for currently defined cipher suites and when - null compression is used, the record layer output can be at most 793 - - - -Dierks & Rescorla Standards Track [Page 44] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes - of padding, and 20 bytes of MAC. That means that in this event a TLS - record layer peer receiving a TLS record layer message larger than - 793 bytes may discard the message and send a "record_overflow" alert, - without decrypting the message. - -7.4.1.4.3 Client Certificate URLs - - Ordinarily, when client authentication is performed, client - certificates are sent by clients to servers during the TLS handshake. - It may be desirable for constrained clients to send certificate URLs - in place of certificates, so that they do not need to store their - certificates and can therefore save memory. - - In order to negotiate to send certificate URLs to a server, clients - MAY include an extension of type "client_certificate_url" in the - (extended) client hello. The "extension_data" field of this - extension SHALL be empty. - - (Note that it is necessary to negotiate use of client certificate - URLs in order to avoid "breaking" existing TLS 1.0 servers.) - - Servers that receive an extended client hello containing a - "client_certificate_url" extension, MAY indicate that they are - willing to accept certificate URLs by including an extension of type - "client_certificate_url" in the (extended) server hello. The - "extension_data" field of this extension SHALL be empty. - - After negotiation of the use of client certificate URLs has been - successfully completed (by exchanging hellos including - "client_certificate_url" extensions), clients MAY send a - "CertificateURL" message in place of a "Certificate" message. See - Section XXX. - -7.4.1.4.4 Trusted CA Indication - - Constrained clients that, due to memory limitations, possess only a - small number of CA root keys, may wish to indicate to servers which - root keys they possess, in order to avoid repeated handshake - failures. - - In order to indicate which CA root keys they possess, clients MAY - include an extension of type "trusted_ca_keys" in the (extended) - client hello. The "extension_data" field of this extension SHALL - contain "TrustedAuthorities" where: - - struct { - TrustedAuthority trusted_authorities_list<0..2^16-1>; - - - -Dierks & Rescorla Standards Track [Page 45] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - } TrustedAuthorities; - - struct { - IdentifierType identifier_type; - select (identifier_type) { - case pre_agreed: struct {}; - case key_sha1_hash: SHA1Hash; - case x509_name: DistinguishedName; - case cert_sha1_hash: SHA1Hash; - } identifier; - } TrustedAuthority; - - enum { - pre_agreed(0), key_sha1_hash(1), x509_name(2), - cert_sha1_hash(3), (255) - } IdentifierType; - - opaque DistinguishedName<1..2^16-1>; - - Here "TrustedAuthorities" provides a list of CA root key identifiers - that the client possesses. Each CA root key is identified via - either: - - - "pre_agreed" - no CA root key identity supplied. - - - "key_sha1_hash" - contains the SHA-1 hash of the CA root key. - For - DSA and ECDSA keys, this is the hash of the "subjectPublicKey" - value. For RSA keys, the hash is of the big-endian byte string - representation of the modulus without any initial 0-valued bytes. - (This copies the key hash formats deployed in other - environments.) - - - "x509_name" - contains the DER-encoded X.509 DistinguishedName - of - the CA. - - - "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded - Certificate containing the CA root key. - - Note that clients may include none, some, or all of the CA root keys - they possess in this extension. - - Note also that it is possible that a key hash or a Distinguished Name - alone may not uniquely identify a certificate issuer - for example if - a particular CA has multiple key pairs - however here we assume this - is the case following the use of Distinguished Names to identify - certificate issuers in TLS. - - - -Dierks & Rescorla Standards Track [Page 46] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - The option to include no CA root keys is included to allow the client - to indicate possession of some pre-defined set of CA root keys. - - Servers that receive a client hello containing the "trusted_ca_keys" - extension, MAY use the information contained in the extension to - guide their selection of an appropriate certificate chain to return - to the client. In this event, the server SHALL include an extension - of type "trusted_ca_keys" in the (extended) server hello. The - "extension_data" field of this extension SHALL be empty. - -7.4.1.4.5 Truncated HMAC - - Currently defined TLS cipher suites use the MAC construction HMAC - with either MD5 or SHA-1 [HMAC] to authenticate record layer - communications. In TLS the entire output of the hash function is - used as the MAC tag. However it may be desirable in constrained - environments to save bandwidth by truncating the output of the hash - function to 80 bits when forming MAC tags. - - In order to negotiate the use of 80-bit truncated HMAC, clients MAY - include an extension of type "truncated_hmac" in the extended client - hello. The "extension_data" field of this extension SHALL be empty. - - Servers that receive an extended hello containing a "truncated_hmac" - extension, MAY agree to use a truncated HMAC by including an - extension of type "truncated_hmac", with empty "extension_data", in - the extended server hello. - - Note that if new cipher suites are added that do not use HMAC, and - the session negotiates one of these cipher suites, this extension - will have no effect. It is strongly recommended that any new cipher - suites using other MACs consider the MAC size as an integral part of - the cipher suite definition, taking into account both security and - bandwidth considerations. - - If HMAC truncation has been successfully negotiated during a TLS - handshake, and the negotiated cipher suite uses HMAC, both the client - and the server pass this fact to the TLS record layer along with the - other negotiated security parameters. Subsequently during the - session, clients and servers MUST use truncated HMACs, calculated as - specified in [HMAC]. That is, CipherSpec.hash_size is 10 bytes, and - only the first 10 bytes of the HMAC output are transmitted and - checked. Note that this extension does not affect the calculation of - the PRF as part of handshaking or key derivation. - - The negotiated HMAC truncation size applies for the duration of the - session including session resumptions. - - - - -Dierks & Rescorla Standards Track [Page 47] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -7.4.1.4.6 Certificate Status Request - - Constrained clients may wish to use a certificate-status protocol - such as OCSP [OCSP] to check the validity of server certificates, in - order to avoid transmission of CRLs and therefore save bandwidth on - constrained networks. This extension allows for such information to - be sent in the TLS handshake, saving roundtrips and resources. - - In order to indicate their desire to receive certificate status - information, clients MAY include an extension of type - "status_request" in the (extended) client hello. The - "extension_data" field of this extension SHALL contain - "CertificateStatusRequest" where: - - struct { - CertificateStatusType status_type; - select (status_type) { - case ocsp: OCSPStatusRequest; - } request; - } CertificateStatusRequest; - - enum { ocsp(1), (255) } CertificateStatusType; - - struct { - ResponderID responder_id_list<0..2^16-1>; - Extensions request_extensions; - } OCSPStatusRequest; - - opaque ResponderID<1..2^16-1>; - - In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP - responders that the client trusts. A zero-length "responder_id_list" - sequence has the special meaning that the responders are implicitly - known to the server - e.g., by prior arrangement. "Extensions" is a - DER encoding of OCSP request extensions. - - Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as - defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero- - length "request_extensions" value means that there are no extensions - (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for - the "Extensions" type). - - In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is - unclear about its encoding; for clarification, the nonce MUST be a - DER-encoded OCTET STRING, which is encapsulated as another OCTET - STRING (note that implementations based on an existing OCSP client - will need to be checked for conformance to this requirement). - - - - -Dierks & Rescorla Standards Track [Page 48] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - Servers that receive a client hello containing the "status_request" - extension, MAY return a suitable certificate status response to the - client along with their certificate. If OCSP is requested, they - SHOULD use the information contained in the extension when selecting - an OCSP responder, and SHOULD include request_extensions in the OCSP - request. - - Servers return a certificate response along with their certificate by - sending a "CertificateStatus" message immediately after the - "Certificate" message (and before any "ServerKeyExchange" or - "CertificateRequest" messages). Section XXX describes the - CertificateStatus message. - -7.4.1.4.7 Cert Hash Types - - The client MAY use the "cert_hash_types" to indicate to the server - which hash functions may be used in the signature on the server's - certificate. The "extension_data" field of this extension contains: - - enum{ - md5(0), sha1(1), sha256(2), sha512(3), (255) - } HashType; - - struct { - HashType<255> types; - } CertHashTypes; - - These values indicate support for MD5 [MD5], SHA-1, SHA-256, and - SHA-512 [SHA] respectively. The server MUST NOT send this extension. - - Clients SHOULD send this extension if they support any algorithm - other than SHA-1. If this extension is not used, servers SHOULD - assume that the client supports only SHA-1. Note: this is a change - from TLS 1.1 where there are no explicit rules but as a practical - matter one can assume that the peer supports MD5 and SHA-1. - - HashType values are divided into three groups: - - 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are - reserved for IETF Standards Track protocols. - - 2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive - are reserved for assignment for non-Standards Track methods. - - 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) - inclusive are reserved for private use. - - Additional information describing the role of IANA in the - - - -Dierks & Rescorla Standards Track [Page 49] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - allocation of HashType code points is described - in Section 11. - - -7.4.1.4.8 Procedure for Defining New Extensions - - The list of extension types, as defined in Section 2.3, is - maintained by the Internet Assigned Numbers Authority (IANA). Thus - an application needs to be made to the IANA in order to obtain a new - extension type value. Since there are subtle (and not so subtle) - interactions that may occur in this protocol between new features and - existing features which may result in a significant reduction in - overall security, new values SHALL be defined only through the IETF - Consensus process specified in [IANA]. - - (This means that new assignments can be made only via RFCs approved - by the IESG.) - - The following considerations should be taken into account when - designing new extensions: - - - All of the extensions defined in this document follow the - convention that for each extension that a client requests and that - the server understands, the server replies with an extension of - the same type. - - - Some cases where a server does not agree to an extension are error - conditions, and some simply a refusal to support a particular - feature. In general error alerts should be used for the former, - and a field in the server extension response for the latter. - - - Extensions should as far as possible be designed to prevent any - attack that forces use (or non-use) of a particular feature by - manipulation of handshake messages. This principle should be - followed regardless of whether the feature is believed to cause a - security problem. - - Often the fact that the extension fields are included in the - inputs to the Finished message hashes will be sufficient, but - extreme care is needed when the extension changes the meaning of - messages sent in the handshake phase. Designers and implementors - should be aware of the fact that until the handshake has been - authenticated, active attackers can modify messages and insert, - remove, or replace extensions. - - - It would be technically possible to use extensions to change major - aspects of the design of TLS; for example the design of cipher - suite negotiation. This is not recommended; it would be more - - - -Dierks & Rescorla Standards Track [Page 50] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - appropriate to define a new version of TLS - particularly since - the TLS handshake algorithms have specific protection against - version rollback attacks based on the version number, and the - possibility of version rollback should be a significant - consideration in any major design change. - - -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 - 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. - - DHE_DSS DSS public key. - - DHE_RSA 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 - - - -Dierks & Rescorla Standards Track [Page 51] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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; - - 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: - - DHE_DSS - DHE_RSA - DH_anon - - It is not legal to send the server key exchange message for the - following key exchange methods: - - - -Dierks & Rescorla Standards Track [Page 52] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - RSA - DH_DSS - DH_RSA - - 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. - - If the SignatureAlgorithm being used to sign the ServerKeyExchange - message is DSA, the hash function used MUST be SHA-1. If the - SignatureAlgorithm it must be the same hash function used in the - signature of the server's certificate (found in the Certificate) - message. This algorithm is denoted Hash below. Hash.length is the - length of the output of that algorithm. - - 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 - - - -Dierks & Rescorla Standards Track [Page 53] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - The generator used for the Diffie-Hellman operation. - - dh_Ys - The server's Diffie-Hellman public value (g^X mod p). - - 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. - - hash - Hash(ClientHello.random + ServerHello.random + ServerParams) - - sha_hash - SHA1(ClientHello.random + ServerHello.random + ServerParams) - - enum { anonymous, rsa, dsa } SignatureAlgorithm; - - - struct { - select (SignatureAlgorithm) { - case anonymous: struct { }; - case rsa: - digitally-signed struct { - opaque hash[Hash.length]; - - - -Dierks & Rescorla Standards Track [Page 54] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - }; - case dsa: - digitally-signed struct { - opaque sha_hash[20]; - }; - }; - }; - } Signature; - -7.4.4. CertificateStatus - - If a server returns a - "CertificateStatus" message, then the server MUST have included an - extension of type "status_request" with empty "extension_data" in the - extended server hello. - - struct { - CertificateStatusType status_type; - select (status_type) { - case ocsp: OCSPResponse; - } response; - } CertificateStatus; - - opaque OCSPResponse<1..2^24-1>; - - An "ocsp_response" contains a complete, DER-encoded OCSP response - (using the ASN.1 type OCSPResponse defined in [OCSP]). Note that - only one OCSP response may be sent. - - The "CertificateStatus" message is conveyed using the handshake - message type "certificate_status". - - Note that a server MAY also choose not to send a "CertificateStatus" - message, even if it receives a "status_request" extension in the - client hello message. - - Note in addition that servers MUST NOT send the "CertificateStatus" - message unless it received a "status_request" extension in the client - hello message. - - Clients requesting an OCSP response, and receiving an OCSP response - in a "CertificateStatus" message MUST check the OCSP response and - abort the handshake if the response is not satisfactory. - - -7.4.5. Certificate request - - When this message will be sent: - - - -Dierks & Rescorla Standards Track [Page 55] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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>; - HashType certificate_hash<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_types - A list of the types of certificate types which the client may - offer. - rsa_sign a certificate containing an RSA key - dss_sign a certificate containing a DSS key - rsa_fixed_dh a certificate signed with RSA and containing - a static DH key. - dss_fixed_dh a certificate signed with DSS and containing - a static DH key - - Certificate types rsa_sign and dss_sign SHOULD contain - certificates signed with the same algorithm. However, this is - not required. This is a holdover from TLS 1.0 and 1.1. - - - certificate_hash - A list of acceptable hash algorithms to be used in - certificate signatures. - - certificate_authorities - A list of the distinguished names of acceptable certificate - - - -Dierks & Rescorla Standards Track [Page 56] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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. - - - ClientCertificateType values are divided into three groups: - - 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are - reserved for IETF Standards Track protocols. - - 2. Values from 64 decimal (0x40) through 223 decimal (0xDF) - inclusive are reserved for assignment for non-Standards - Track methods. - - 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) - inclusive are reserved for private use. - - Additional information describing the role of IANA in the - allocation of ClientCertificateType code points is described - in Section 11. - - Note: Values listed as RESERVED may not be used. They were used in - SSLv3. - - - Note: DistinguishedName is derived from [X501]. DistinguishedNames are - represented in DER-encoded format. - - Note: It is a fatal handshake_failure alert for an anonymous server to - request client authentication. - -7.4.6. 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. - - - - -Dierks & Rescorla Standards Track [Page 57] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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.7. Client certificate - - When this message will be sent: - This is the first message the client can send after receiving a - server hello done message. This message is only sent if the - server requests a certificate. If no suitable certificate is - available, the client SHOULD send a certificate message - containing no certificates. That is, the certificate_list - structure has a length of zero. If client authentication is - required by the server for the handshake to continue, it may - respond with a fatal handshake failure alert. Client certificates - are sent using the Certificate structure defined in Section - 7.4.2. - - - Note: When using a static Diffie-Hellman based key exchange method - (DH_DSS or DH_RSA), if client authentication is requested, the - Diffie-Hellman group and generator encoded in the client's - certificate MUST match the server specified Diffie-Hellman - parameters if the client's parameters are to be used for the key - exchange. - -7.4.8. Client Certificate URLs - - After negotiation of the use of client certificate URLs has been - successfully completed (by exchanging hellos including - "client_certificate_url" extensions), clients MAY send a - "CertificateURL" message in place of a "Certificate" message. - - enum { - individual_certs(0), pkipath(1), (255) - } CertChainType; - - enum { - false(0), true(1) - } Boolean; - - struct { - CertChainType type; - URLAndOptionalHash url_and_hash_list<1..2^16-1>; - } CertificateURL; - - - -Dierks & Rescorla Standards Track [Page 58] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - struct { - opaque url<1..2^16-1>; - Boolean hash_present; - select (hash_present) { - case false: struct {}; - case true: SHA1Hash; - } hash; - } URLAndOptionalHash; - - opaque SHA1Hash[20]; - - Here "url_and_hash_list" contains a sequence of URLs and optional - hashes. - - When X.509 certificates are used, there are two possibilities: - - - if CertificateURL.type is "individual_certs", each URL refers to - a single DER-encoded X.509v3 certificate, with the URL for the - client's certificate first, or - - - if CertificateURL.type is "pkipath", the list contains a single - URL referring to a DER-encoded certificate chain, using the type - PkiPath described in Section 8. - - When any other certificate format is used, the specification that - describes use of that format in TLS should define the encoding format - of certificates or certificate chains, and any constraint on their - ordering. - - The hash corresponding to each URL at the client's discretion is - either not present or is the SHA-1 hash of the certificate or - certificate chain (in the case of X.509 certificates, the DER-encoded - certificate or the DER-encoded PkiPath). - - Note that when a list of URLs for X.509 certificates is used, the - ordering of URLs is the same as that used in the TLS Certificate - message (see [TLS] Section 7.4.2), but opposite to the order in which - certificates are encoded in PkiPath. In either case, the self-signed - root certificate MAY be omitted from the chain, under the assumption - that the server must already possess it in order to validate it. - - Servers receiving "CertificateURL" SHALL attempt to retrieve the - client's certificate chain from the URLs, and then process the - certificate chain as usual. A cached copy of the content of any URL - in the chain MAY be used, provided that a SHA-1 hash is present for - that URL and it matches the hash of the cached copy. - - Servers that support this extension MUST support the http: URL scheme - - - -Dierks & Rescorla Standards Track [Page 59] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - for certificate URLs, and MAY support other schemes. Use of other - schemes than "http", "https", or "ftp" may create unexpected - problems. - - If the protocol used is HTTP, then the HTTP server can be configured - to use the Cache-Control and Expires directives described in [HTTP] - to specify whether and for how long certificates or certificate - chains should be cached. - - The TLS server is not required to follow HTTP redirects when - retrieving the certificates or certificate chain. The URLs used in - this extension SHOULD therefore be chosen not to depend on such - redirects. - - If the protocol used to retrieve certificates or certificate chains - returns a MIME formatted response (as HTTP does), then the following - MIME Content-Types SHALL be used: when a single X.509v3 certificate - is returned, the Content-Type is "application/pkix-cert" [PKIOP], and - when a chain of X.509v3 certificates is returned, the Content-Type is - "application/pkix-pkipath" (see Section XXX). - - If a SHA-1 hash is present for an URL, then the server MUST check - that the SHA-1 hash of the contents of the object retrieved from that - URL (after decoding any MIME Content-Transfer-Encoding) matches the - given hash. If any retrieved object does not have the correct SHA-1 - hash, the server MUST abort the handshake with a - "bad_certificate_hash_value" alert. - - Note that clients may choose to send either "Certificate" or - "CertificateURL" after successfully negotiating the option to send - certificate URLs. The option to send a certificate is included to - provide flexibility to clients possessing multiple certificates. - - If a server encounters an unreasonable delay in obtaining - certificates in a given CertificateURL, it SHOULD time out and signal - a "certificate_unobtainable" error alert. - -7.4.9. Client key exchange message - - When this message will be sent: - This message is always sent by the client. It MUST immediately follow - the client certificate message, if it is sent. Otherwise it MUST be - the first message sent by the client after it receives the server - hello done message. - - Meaning of this message: - With this message, the premaster secret is set, either though direct - transmission of the RSA-encrypted secret, or by the transmission of - - - -Dierks & Rescorla Standards Track [Page 60] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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.9.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 - 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; - - - -Dierks & Rescorla Standards Track [Page 61] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 v 1.5 encoded RSA. - The attack takes advantage of the fact that by failing in - different ways, a TLS server can be coerced into revealing - whether a particular message, when decrypted, is properly PKCS#1 - v1.5 formatted or not. - - The best way to avoid vulnerability to this attack is to treat - incorrectly formatted messages in a manner indistinguishable from - correctly formatted RSA blocks. Thus, when 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. - - [PKCS1B] defines a newer version of PKCS#1 encoding that is more - secure against the Bleichenbacher attack. However, for maximal - compatibility with TLS 1.0, TLS 1.1 retains the original - encoding. No variants of the Bleichenbacher attack are known to - exist provided that the above recommendations are followed. - - Implementation Note: public-key-encrypted data is represented as an - opaque vector <0..2^16-1> (see section 4.7). Thus the RSA- - encrypted PreMasterSecret in a ClientKeyExchange is preceded by - two length bytes. These bytes are redundant in the case of RSA - because the EncryptedPreMasterSecret is the only data in the - ClientKeyExchange and its length can therefore be unambiguously - determined. The SSLv3 specification was not clear about the - encoding of public-key-encrypted data and therefore many SSLv3 - implementations do not include the the length bytes, encoding the - RSA encrypted data directly in the ClientKeyExchange message. - - This specification requires correct encoding of the - EncryptedPreMasterSecret complete with length bytes. The - resulting PDU is incompatible with many SSLv3 implementations. - Implementors upgrading from SSLv3 must modify their - implementations to generate and accept the correct encoding. - Implementors who wish to be compatible with both SSLv3 and TLS - should make their implementation's behavior dependent on the - protocol version. - - Implementation Note: It is now known that remote timing-based attacks - on SSL are possible, at least when the client and server are on - the same LAN. Accordingly, implementations which use static RSA - - - -Dierks & Rescorla Standards Track [Page 62] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - keys SHOULD use RSA blinding or some other anti-timing technique, - as described in [TIMING]. - - Note: The version number in the PreMasterSecret MUST be the version - offered by the client in the ClientHello, not the version - negotiated for the connection. This feature is designed to - prevent rollback attacks. Unfortunately, many implementations use - the negotiated version instead and therefore checking the version - number may lead to failure to interoperate with such incorrect - client implementations. Client implementations MUST and Server - implementations MAY check the version number. In practice, since - the TLS handshake MACs prevent downgrade and no good attacks are - known on those MACs, ambiguity is not considered a serious - security risk. Note that if servers choose to 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.9.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 MUST be empty. - - explicit - Yc needs to be sent. - - struct { - select (PublicValueEncoding) { - case implicit: struct { }; - case explicit: opaque dh_Yc<1..2^16-1>; - } dh_public; - } ClientDiffieHellmanPublic; - - dh_Yc - The client's Diffie-Hellman public value (Yc). - - - -Dierks & Rescorla Standards Track [Page 63] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -7.4.10. Certificate verify - - When this message will be sent: - This message is used to provide explicit verification of a client - certificate. This message is only sent following a client - certificate that has signing capability (i.e. all certificates - except those containing fixed Diffie-Hellman parameters). When - sent, it MUST immediately follow the client key exchange message. - - Structure of this message: - struct { - Signature signature; - } CertificateVerify; - - The Signature type is defined in 7.4.3. If the SignatureAlgorithm - is DSA, then the sha_hash value must be used. If it is RSA, - the same function (denoted Hash) must be used as was used to - create the signature for the client's certificate. - - CertificateVerify.signature.hash - Hash(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.10. Finished - - When this message will be sent: - A finished message is always sent immediately after a change - cipher spec message to verify that the key exchange and - authentication processes were successful. It is essential that a - change cipher spec message be received between the other - handshake messages and the Finished message. - - Meaning of this message: - The finished message is the first protected with the just- - negotiated algorithms, keys, and secrets. Recipients of finished - messages MUST verify that the contents are correct. Once a side - has sent its Finished message and received and validated the - Finished message from its peer, it may begin to send and receive - application data over the connection. - - - - -Dierks & Rescorla Standards Track [Page 64] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - struct { - opaque verify_data[12]; - } Finished; - - verify_data - PRF(master_secret, finished_label, MD5(handshake_messages) + - SHA-1(handshake_messages)) [0..11]; - - finished_label - For Finished messages sent by the client, the string "client - finished". For Finished messages sent by the server, the - string "server finished". - - handshake_messages - All of the data from all messages in this handshake (not - including any HelloRequest messages) up to but not including - this message. This is only data visible at the handshake - layer and does not include record layer headers. This is the - concatenation of all the Handshake structures as defined in - 7.4 exchanged thus far. - - It is a fatal error if a finished message is not preceded by a change - cipher spec message at the appropriate point in the handshake. - - The value handshake_messages includes all handshake messages starting - at client hello up to, but not including, this finished message. This - may be different from handshake_messages in Section 7.4.10 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 65] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -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 66] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -8.1.1. RSA - - When RSA is used for server authentication and key exchange, a - 48-byte pre_master_secret is generated by the client, encrypted under - the server's public key, and sent to the server. The server uses its - private key to decrypt the pre_master_secret. Both parties then - convert the pre_master_secret into the master_secret, as specified - above. - - RSA digital signatures are performed using PKCS #1 [PKCS1] block type - 1. RSA public key encryption is performed using PKCS #1 block type 2. - -8.1.2. Diffie-Hellman - - A conventional Diffie-Hellman computation is performed. The - negotiated key (Z) is used as the pre_master_secret, and is converted - into the master_secret, as specified above. Leading bytes of Z that - contain all zero bits are stripped before it is used as the - pre_master_secret. - - Note: Diffie-Hellman parameters are specified by the server, and may - be either ephemeral or contained within the server's certificate. - -9. Mandatory Cipher Suites - - In the absence of an application profile standard specifying - otherwise, a TLS compliant application MUST implement the cipher - suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. - -10. Application data protocol - - Application data messages are carried by the Record Layer and are - fragmented, compressed and encrypted based on the current connection - state. The messages are treated as transparent data to the record - layer. - -11. IANA Considerations - - This document describes a number of new registries to be created by - IANA. We recommend that they be placed as individual registries items - under a common TLS category. - - Section 7.4.5 describes a TLS HashType Registry to be maintained by - the IANA, as defining a number of such code point identifiers. - HashType identifiers with values in the range 0-63 (decimal) - inclusive are assigned via RFC 2434 Standards Action. Values from the - range 64-223 (decimal) inclusive are assigned via [RFC 2434] - Specification Required. Identifier values from 224-255 (decimal) - - - -Dierks & Rescorla Standards Track [Page 67] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - inclusive are reserved for RFC 2434 Private Use. The registry will be - initially populated with the values in this document, Section 7.4.5. - - Section 7.4.5 describes a TLS ClientCertificateType Registry to be - maintained by the IANA, as defining a number of such code point - identifiers. ClientCertificateType identifiers with values in the - range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards - Action. Values from the range 64-223 (decimal) inclusive are assigned - via [RFC 2434] Specification Required. Identifier values from - 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use. - The registry will be initially populated with the values in this - document, Section 7.4.5. - - Section A.5 describes a TLS Cipher Suite Registry to be maintained by - the IANA, as well as defining a number of such cipher suite - identifiers. Cipher suite values with the first byte in the range - 0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action. - Values with the first byte in the range 192-254 (decimal) are - assigned via RFC 2434 Specification Required. Values with the first - byte 255 (decimal) are reserved for RFC 2434 Private Use. The - registry will be initially populated with the values from Section A.5 - of this document, [TLSAES], and Section 3 of [TLSKRB]. - - Section 6 requires that all ContentType values be defined by RFC 2434 - Standards Action. IANA SHOULD create a TLS ContentType registry, - initially populated with values from Section 6.2.1 of this document. - Future values MUST be allocated via Standards Action as described in - [RFC 2434]. - - Section 7.2.2 requires that all Alert values be defined by RFC 2434 - Standards Action. IANA SHOULD create a TLS Alert registry, initially - populated with values from Section 7.2 of this document and Section 4 - of [TLSEXT]. Future values MUST be allocated via Standards Action as - described in [RFC 2434]. - - Section 7.4 requires that all HandshakeType values be defined by RFC - 2434 Standards Action. IANA SHOULD create a TLS HandshakeType - registry, initially populated with values from Section 7.4 of this - document and Section 2.4 of [TLSEXT]. Future values MUST be - allocated via Standards Action as described in [RFC2434]. - - -11.1 Extensions - - Sections XXX and XXX describes a registry of ExtensionType values to - be maintained by the IANA. ExtensionType values are to be assigned - via IETF Consensus as defined in RFC 2434 [IANA]. The initial - registry corresponds to the definition of "ExtensionType" in Section - - - -Dierks & Rescorla Standards Track [Page 68] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 2.3. - - The MIME type "application/pkix-pkipath" has been registered by the - IANA with the following template: - - To: ietf-types@iana.org Subject: Registration of MIME media type - application/pkix-pkipath - - MIME media type name: application - MIME subtype name: pkix-pkipath - - Optional parameters: version (default value is "1") - - Encoding considerations: - This MIME type is a DER encoding of the ASN.1 type PkiPath, - defined as follows: - PkiPath ::= SEQUENCE OF Certificate - PkiPath is used to represent a certification path. Within the - sequence, the order of certificates is such that the subject of - the first certificate is the issuer of the second certificate, - etc. - - This is identical to the definition published in [X509-4th-TC1]; - note that it is different from that in [X509-4th]. - - All Certificates MUST conform to [PKIX]. (This should be - interpreted as a requirement to encode only PKIX-conformant - certificates using this type. It does not necessarily require - that all certificates that are not strictly PKIX-conformant must - be rejected by relying parties, although the security consequences - of accepting any such certificates should be considered - carefully.) - - DER (as opposed to BER) encoding MUST be used. If this type is - sent over a 7-bit transport, base64 encoding SHOULD be used. - - Security considerations: - The security considerations of [X509-4th] and [PKIX] (or any - updates to them) apply, as well as those of any protocol that uses - this type (e.g., TLS). - - Note that this type only specifies a certificate chain that can be - assessed for validity according to the relying party's existing - configuration of trusted CAs; it is not intended to be used to - specify any change to that configuration. - - Interoperability considerations: - No specific interoperability problems are known with this type, - - - -Dierks & Rescorla Standards Track [Page 69] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - but for recommendations relating to X.509 certificates in general, - see [PKIX]. - - Published specification: this memo, and [PKIX]. - - Applications which use this media type: TLS. It may also be used by - other protocols, or for general interchange of PKIX certificate - - Additional information: - Magic number(s): DER-encoded ASN.1 can be easily recognized. - Further parsing is required to distinguish from other ASN.1 - types. - File extension(s): .pkipath - Macintosh File Type Code(s): not specified - - Person & email address to contact for further information: - Magnus Nystrom <magnus@rsasecurity.com> - - Intended usage: COMMON - - Change controller: - IESG <iesg@ietf.org> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dierks & Rescorla Standards Track [Page 70] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -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 71] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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_RESERVED(60), - protocol_version(70), - insufficient_security(71), - internal_error(80), - user_canceled(90), - no_renegotiation(100), - unsupported_extension(110), /* new */ - certificate_unobtainable(111), /* new */ - unrecognized_name(112), /* new */ - bad_certificate_status_response(113), /* new */ - bad_certificate_hash_value(114), /* new */ - (255) - } AlertDescription; - - - -Dierks & Rescorla Standards Track [Page 72] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - struct { - AlertLevel level; - AlertDescription description; - } Alert; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dierks & Rescorla Standards Track [Page 73] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -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), certificate_url(21), certificate_status(22), - (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; - case certificate_url: CertificateURL; - case certificate_status: CertificateStatus; - } 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; - - - -Dierks & Rescorla Standards Track [Page 74] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - SessionID session_id; - CipherSuite cipher_suites<2..2^16-1>; - CompressionMethod compression_methods<1..2^8-1>; - Extension client_hello_extension_list<0..2^16-1>; - } ClientHello; - - struct { - ProtocolVersion client_version; - Random random; - SessionID session_id; - CipherSuite cipher_suites<2..2^16-1>; - CompressionMethod compression_methods<1..2^8-1>; - Extension client_hello_extension_list<0..2^16-1>; - } ExtendedClientHello; - - struct { - ProtocolVersion server_version; - Random random; - SessionID session_id; - CipherSuite cipher_suite; - CompressionMethod compression_method; - } ServerHello; - - struct { - ProtocolVersion server_version; - Random random; - SessionID session_id; - CipherSuite cipher_suite; - CompressionMethod compression_method; - Extension server_hello_extension_list<0..2^16-1>; - } ExtendedServerHello; - - struct { - ExtensionType extension_type; - opaque extension_data<0..2^16-1>; - } Extension; - - enum { - server_name(0), max_fragment_length(1), - client_certificate_url(2), trusted_ca_keys(3), - truncated_hmac(4), status_request(5), - cert_hash_types(6), (65535) - } ExtensionType; - - struct { - NameType name_type; - select (name_type) { - case host_name: HostName; - - - -Dierks & Rescorla Standards Track [Page 75] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - } name; - } ServerName; - - enum { - host_name(0), (255) - } NameType; - - opaque HostName<1..2^16-1>; - - struct { - ServerName server_name_list<1..2^16-1> - } ServerNameList; - - enum{ - 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) - } MaxFragmentLength; - - struct { - TrustedAuthority trusted_authorities_list<0..2^16-1>; - } TrustedAuthorities; - - struct { - IdentifierType identifier_type; - select (identifier_type) { - case pre_agreed: struct {}; - case key_sha1_hash: SHA1Hash; - case x509_name: DistinguishedName; - case cert_sha1_hash: SHA1Hash; - } identifier; - } TrustedAuthority; - - enum { - pre_agreed(0), key_sha1_hash(1), x509_name(2), - cert_sha1_hash(3), (255) - } IdentifierType; - - struct { - CertificateStatusType status_type; - select (status_type) { - case ocsp: OCSPStatusRequest; - } request; - } CertificateStatusRequest; - - enum { ocsp(1), (255) } CertificateStatusType; - - struct { - ResponderID responder_id_list<0..2^16-1>; - Extensions request_extensions; - - - -Dierks & Rescorla Standards Track [Page 76] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - } OCSPStatusRequest; - - opaque ResponderID<1..2^16-1>; -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; - - struct { - CertificateStatusType status_type; - select (status_type) { - case ocsp: OCSPResponse; - } response; - } CertificateStatus; - - opaque OCSPResponse<1..2^24-1>; - - 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) { - - - -Dierks & Rescorla Standards Track [Page 77] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - case diffie_hellman: - ServerDHParams params; - case rsa: - ServerRSAParams params; - }; - } ServerParams; - - struct { - select (SignatureAlgorithm) { - case anonymous: struct { }; - case rsa: - digitally-signed struct { - opaque hash[Hash.length]; - }; - 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: ClientDiffieHellmanPublic; - } exchange_keys; - } ClientKeyExchange; - - struct { - - - -Dierks & Rescorla Standards Track [Page 78] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - ProtocolVersion client_version; - opaque random[46]; - } PreMasterSecret; - - 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; - - enum { - individual_certs(0), pkipath(1), (255) - } CertChainType; - - enum { - false(0), true(1) - } Boolean; - - struct { - CertChainType type; - URLAndOptionalHash url_and_hash_list<1..2^16-1>; - } CertificateURL; - - struct { - opaque url<1..2^16-1>; - Boolean hash_present; - select (hash_present) { - case false: struct {}; - case true: SHA1Hash; - } hash; - } URLAndOptionalHash; - - opaque SHA1Hash[20]; - - struct { - Signature signature; - } CertificateVerify; - -A.4.4. Handshake finalization message - - struct { - - - -Dierks & Rescorla Standards Track [Page 79] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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_WITH_RC4_128_MD5 = { 0x00,0x04 }; - CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; - CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; - CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; - CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; - CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F }; - CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 }; - 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_WITH_DES_CBC_SHA = { 0x00,0x0C }; - CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; - CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; - - - -Dierks & Rescorla Standards Track [Page 80] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; - 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_WITH_DES_CBC_SHA = { 0x00,0x15 }; - CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; - CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 }; - CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 }; - CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 }; - CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 }; - CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; - CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 }; - CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 }; - CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 }; - CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 }; - CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; - - 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_WITH_RC4_128_MD5 = { 0x00,0x18 }; - CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; - CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; - - When SSLv3 and TLS 1.0 were designed, the United States restricted - the export of cryptographic software containing certain strong - encryption algorithms. A series of cipher suites were designed to - operate at reduced key lengths in order to comply with those - regulations. Due to advances in computer performance, these - algorithms are now unacceptably weak and export restrictions have - since been loosened. TLS 1.1 implementations MUST NOT negotiate these - cipher suites in TLS 1.1 mode. However, for backward compatibility - they may be offered in the ClientHello for use with TLS 1.0 or SSLv3 - only servers. TLS 1.1 clients MUST check that the server did not - choose one of these cipher suites during the handshake. These - ciphersuites are listed below for informational purposes and to - reserve the numbers. - - CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; - CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; - CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; - CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; - CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; - CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; - CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; - CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; - CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; - - - -Dierks & Rescorla Standards Track [Page 81] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - The following cipher suites were defined in [TLSKRB] and are included - here for completeness. See [TLSKRB] for details: - - CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }; - CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F }; - CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 }; - CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 }; - CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 }; - CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 }; - CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 }; - CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 }; - - The following exportable cipher suites were defined in [TLSKRB] and - are included here for completeness. TLS 1.1 implementations MUST NOT - negotiate these cipher suites. - - CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 - }; - CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 - }; - CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 - }; - CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 - }; - CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A - }; - CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B - }; - - - The cipher suite space is divided into three regions: - - 1. Cipher suite values with first byte 0x00 (zero) - through decimal 191 (0xBF) inclusive are reserved for the IETF - Standards Track protocols. - - 2. Cipher suite values with first byte decimal 192 (0xC0) - through decimal 254 (0xFE) inclusive are reserved - for assignment for non-Standards Track methods. - - 3. Cipher suite values with first byte 0xFF are - reserved for private use. - Additional information describing the role of IANA in the allocation - of cipher suite code points is described in Section 11. - - Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are - reserved to avoid collision with Fortezza-based cipher suites in SSL - 3. - - - -Dierks & Rescorla Standards Track [Page 82] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -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, aes, idea } - BulkCipherAlgorithm; - - enum { stream, block } CipherType; - - 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; - MACAlgorithm mac_algorithm; - uint8 hash_size; - CompressionMethod compression_algorithm; - opaque master_secret[48]; - opaque client_random[32]; - opaque server_random[32]; - } SecurityParameters; - - - - - - - - - - - - - - - - - - -Dierks & Rescorla Standards Track [Page 83] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -B. Glossary - - Advanced Encryption Standard (AES) - AES is a widely used symmetric encryption algorithm. - AES is - a block cipher with a 128, 192, or 256 bit keys and a 16 byte - block size. [AES] TLS currently only supports the 128 and 256 - bit key sizes. - - 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 - - - -Dierks & Rescorla Standards Track [Page 84] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - generally authenticated, while the client is only optionally - authenticated. - - client write key - The key used to encrypt data written by the client. - - 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. - - - - -Dierks & Rescorla Standards Track [Page 85] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - IDEA - A 64-bit block cipher designed by Xuejia Lai and James Massey. - [IDEA] - - 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 invented by Ron Rivest. A compatible cipher is - described in [SCH]. - - RSA - A very widely used public-key algorithm that can be used for - either encryption or digital signing. [RSA] - - server - The server is the application entity that responds to requests - for connections from clients. See also under client. - - - - - - -Dierks & Rescorla Standards Track [Page 86] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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-2. 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 87] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -C. CipherSuite definitions - -CipherSuite Key Cipher Hash - 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_WITH_RC4_128_MD5 RSA RC4_128 MD5 -TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA -TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_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_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA -TLS_RSA_WITH_AES_256_SHA RSA AES_256_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_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_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_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_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 -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 -TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA -TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA -TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA -TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA -TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA -TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA -TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA -TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA -TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA -TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA - - Key - Exchange - Algorithm Description Key size limit - - DHE_DSS Ephemeral DH with DSS signatures None - DHE_RSA Ephemeral DH with RSA signatures None - DH_anon Anonymous DH, no signatures None - DH_DSS DH with DSS-based certificates None - DH_RSA DH with RSA-based certificates None - RSA = none - NULL No key exchange N/A - - - -Dierks & Rescorla Standards Track [Page 88] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - RSA RSA key exchange None - - Key Expanded IV Block - Cipher Type Material Key Material Size Size - - NULL Stream 0 0 0 N/A - IDEA_CBC Block 16 16 8 8 - RC2_CBC_40 Block 5 16 8 8 - RC4_40 Stream 5 16 0 N/A - RC4_128 Stream 16 16 0 N/A - DES40_CBC Block 5 8 8 8 - DES_CBC Block 8 8 8 8 - 3DES_EDE_CBC Block 24 24 8 8 - - 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 - - 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. - - 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 89] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -D. Implementation Notes - - The TLS protocol cannot prevent many common security mistakes. This - section provides several recommendations to assist implementors. - -D.1 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. - - [RANDOM] provides guidance on the generation of random values. - -D.2 Certificates and authentication - - 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.3 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 90] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -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 91] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 }; - - Note: TLS 1.2 clients may generate the SSLv2 EXPORT cipher suites in - handshakes for backward compatibility but MUST NOT negotiate them in - TLS 1.2 mode. - -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 - - - -Dierks & Rescorla Standards Track [Page 92] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - version 2 client hello message. The value SHOULD be one (1). - - version - The highest version of the protocol supported by the client - (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 - - - -Dierks & Rescorla Standards Track [Page 93] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 - receiving blocks padded in this manner will proceed normally. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dierks & Rescorla Standards Track [Page 94] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -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.10, 7.4.11 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 95] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 96] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - the certificate verify message (see Section 7.4.10). 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 97] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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. - - 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 - force a full handshake. An upper limit of 24 hours is suggested for - session ID lifetimes, since an attacker who obtains a master_secret - - - -Dierks & Rescorla Standards Track [Page 98] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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 Extensions - - Security considerations for the extension mechanism in general, and - the design of new extensions, are described in the previous section. - A security analysis of each of the extensions defined in this - document is given below. - - In general, implementers should continue to monitor the state of the - art, and address any weaknesses identified. - - -F.1.5.1 Security of server_name - - If a single server hosts several domains, then clearly it is - necessary for the owners of each domain to ensure that this satisfies - their security needs. Apart from this, server_name does not appear - to introduce significant security issues. - - Implementations MUST ensure that a buffer overflow does not occur - whatever the values of the length fields in server_name. - - Although this document specifies an encoding for internationalized - hostnames in the server_name extension, it does not address any - security issues associated with the use of internationalized - hostnames in TLS - in particular, the consequences of "spoofed" names - that are indistinguishable from another name when displayed or - printed. It is recommended that server certificates not be issued - for internationalized hostnames unless procedures are in place to - mitigate the risk of spoofed hostnames. - - 6.2. Security of max_fragment_length - - The maximum fragment length takes effect immediately, including for - handshake messages. However, that does not introduce any security - complications that are not already present in TLS, since [TLS] - requires implementations to be able to handle fragmented handshake - messages. - - Note that as described in section XXX, once a non-null cipher suite - has been activated, the effective maximum fragment length depends on - the cipher suite and compression method, as well as on the negotiated - max_fragment_length. This must be taken into account when sizing - buffers, and checking for buffer overflow. - - - -Dierks & Rescorla Standards Track [Page 99] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -F.1.5.2 Security of client_certificate_url - - There are two major issues with this extension. - - The first major issue is whether or not clients should include - certificate hashes when they send certificate URLs. - - When client authentication is used *without* the - client_certificate_url extension, the client certificate chain is - covered by the Finished message hashes. The purpose of including - hashes and checking them against the retrieved certificate chain, is - to ensure that the same property holds when this extension is used - - i.e., that all of the information in the certificate chain retrieved - by the server is as the client intended. - - On the other hand, omitting certificate hashes enables functionality - that is desirable in some circumstances - for example clients can be - issued daily certificates that are stored at a fixed URL and need not - be provided to the client. Clients that choose to omit certificate - hashes should be aware of the possibility of an attack in which the - attacker obtains a valid certificate on the client's key that is - different from the certificate the client intended to provide. - Although TLS uses both MD5 and SHA-1 hashes in several other places, - this was not believed to be necessary here. The property required of - SHA-1 is second pre-image resistance. - - The second major issue is that support for client_certificate_url - involves the server acting as a client in another URL protocol. The - server therefore becomes subject to many of the same security - concerns that clients of the URL scheme are subject to, with the - added concern that the client can attempt to prompt the server to - connect to some, possibly weird-looking URL. - - In general this issue means that an attacker might use the server to - indirectly attack another host that is vulnerable to some security - flaw. It also introduces the possibility of denial of service - attacks in which an attacker makes many connections to the server, - each of which results in the server attempting a connection to the - target of the attack. - - Note that the server may be behind a firewall or otherwise able to - access hosts that would not be directly accessible from the public - Internet; this could exacerbate the potential security and denial of - service problems described above, as well as allowing the existence - of internal hosts to be confirmed when they would otherwise be - hidden. - - The detailed security concerns involved will depend on the URL - - - -Dierks & Rescorla Standards Track [Page 100] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - schemes supported by the server. In the case of HTTP, the concerns - are similar to those that apply to a publicly accessible HTTP proxy - server. In the case of HTTPS, the possibility for loops and - deadlocks to be created exists and should be addressed. In the case - of FTP, attacks similar to FTP bounce attacks arise. - - As a result of this issue, it is RECOMMENDED that the - client_certificate_url extension should have to be specifically - enabled by a server administrator, rather than being enabled by - default. It is also RECOMMENDED that URI protocols be enabled by the - administrator individually, and only a minimal set of protocols be - enabled, with unusual protocols offering limited security or whose - security is not well-understood being avoided. - - As discussed in [URI], URLs that specify ports other than the default - may cause problems, as may very long URLs (which are more likely to - be useful in exploiting buffer overflow bugs). - - Also note that HTTP caching proxies are common on the Internet, and - some proxies do not check for the latest version of an object - correctly. If a request using HTTP (or another caching protocol) - goes through a misconfigured or otherwise broken proxy, the proxy may - return an out-of-date response. - -F.1.5.4. Security of trusted_ca_keys - - It is possible that which CA root keys a client possesses could be - regarded as confidential information. As a result, the CA root key - indication extension should be used with care. - - The use of the SHA-1 certificate hash alternative ensures that each - certificate is specified unambiguously. As for the previous - extension, it was not believed necessary to use both MD5 and SHA-1 - hashes. - -F.1.5.5. Security of truncated_hmac - - It is possible that truncated MACs are weaker than "un-truncated" - MACs. However, no significant weaknesses are currently known or - expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. - - Note that the output length of a MAC need not be as long as the - length of a symmetric cipher key, since forging of MAC values cannot - be done off-line: in TLS, a single failed MAC guess will cause the - immediate termination of the TLS session. - - Since the MAC algorithm only takes effect after the handshake - messages have been authenticated by the hashes in the Finished - - - -Dierks & Rescorla Standards Track [Page 101] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - messages, it is not possible for an active attacker to force - negotiation of the truncated HMAC extension where it would not - otherwise be used (to the extent that the handshake authentication is - secure). Therefore, in the event that any security problem were - found with truncated HMAC in future, if either the client or the - server for a given session were updated to take into account the - problem, they would be able to veto use of this extension. - -F.1.5.6. Security of status_request - - If a client requests an OCSP response, it must take into account that - an attacker's server using a compromised key could (and probably - would) pretend not to support the extension. A client that requires - OCSP validation of certificates SHOULD either contact the OCSP server - directly in this case, or abort the handshake. - - Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may - improve security against attacks that attempt to replay OCSP - responses; see section 4.4.1 of [OCSP] for further details. - - -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. - - - -Dierks & Rescorla Standards Track [Page 102] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -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. - -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 - - - -Dierks & Rescorla Standards Track [Page 103] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 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]. - -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 104] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - -Security Considerations - - Security issues are discussed throughout this memo, especially in - Appendices D, E, and F. - -Normative References - [AES] National Institute of Standards and Technology, - "Specification for the Advanced Encryption Standard (AES)" - FIPS 197. November 26, 2001. - - [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. - - [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National - Institute of Standards and Technology, U.S. Department of - Commerce, 2000. - - - [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication," RFC 2104, February - 1997. - - [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, - L., Leach, P. and T. Berners-Lee, "Hypertext Transfer - Protocol -- HTTP/1.1", RFC 2616, June 1999. - - [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH - Series in Information Processing, v. 1, Konstanz: Hartung- - Gorre Verlag, 1992. - - [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", - RFC 3490, March 2003. - - [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, - April 1992. - - [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. - Adams, "Internet X.509 Public Key Infrastructure: Online - Certificate Status Protocol - OCSP", RFC 2560, June 1999. - - [PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: - RSA Cryptography Specifications Version 1.5", RFC 2313, - March 1998. - - - -Dierks & Rescorla Standards Track [Page 105] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards - (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC - 3447, February 2003. - - [PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key - Infrastructure - Operation Protocols: FTP and HTTP", RFC - 2585, May 1999. - - - [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet - Public Key Infrastructure: Part I: X.509 Certificate and CRL - Profile", RFC 3280, April 2002. - - [RC2] Rivest, R., "A Description of the RC2(r) Encryption - Algorithm", RFC 2268, January 1998. - - [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, - and Source Code in C, 2ed", Published by John Wiley & Sons, - Inc. 1996. - - [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National - Institute of Standards and Technology, U.S. Department of - Commerce., August 2001. - - [REQ] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", RFC 3434, October 1998. - - [TLSAES] Chown, P. "Advanced Encryption Standard (AES) Ciphersuites - for Transport Layer Security (TLS)", RFC 3268, June 2002. - - [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J., - Wright, T., "Transport Layer Security (TLS) Extensions", RFC - 3546, June 2003. - [TLSKRB] A. Medvinsky, M. Hur, "Addition of Kerberos Cipher Suites to - Transport Layer Security (TLS)", RFC 2712, October 1999. - - - [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. - - [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", - RFC 3629, November 2003. - - [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001, - - - -Dierks & Rescorla Standards Track [Page 106] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - "Information Systems - Open Systems Interconnection - The - Directory: Public key and Attribute certificate - frameworks." - - [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | - ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to - ISO/IEC 9594:8:2001. - -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. - - [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based - Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, - March 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. - - [RANDOM] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness - Recommendations for Security", RFC 1750, December 1994. - - [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. - - - -Dierks & Rescorla Standards Track [Page 107] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - 120-126. - - [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks", - RFC 1948, May 1996. - - [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. - - [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. - - [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are - practical", USENIX Security Symposium 2003. - - [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0", - RFC 2246, January 1999. - - [TLS1.1] Dierks, T., and Rescorla, E., "The TLS Protocol, Version - 1.1", RFC 4346, April, 2006. - - [X501] ITU-T Recommendation X.501: Information Technology - Open - Systems Interconnection - The Directory: Models, 1993. - - [X509] ITU-T Recommendation X.509 (1997 E): Information Technology - - Open Systems Interconnection - "The Directory - - Authentication Framework". 1988. - - [XDR] R. Srinivansan, Sun Microsystems, "XDR: External Data - Representation Standard", RFC 1832, August 1995. - - -Credits - - Working Group Chairs - Eric Rescorla - EMail: ekr@rtfm.com - - Pasi Eronen - pasi.eronen@nokia.com - - - - - -Dierks & Rescorla Standards Track [Page 108] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - Editors - - Tim Dierks Eric Rescorla - Independent Network Resonance, Inc. - - EMail: tim@dierks.org EMail: ekr@networkresonance.com - - - - Other contributors - - Christopher Allen (co-editor of TLS 1.0) - Alacrity Ventures - ChristopherA@AlacrityManagement.com - - Martin Abadi - University of California, Santa Cruz - abadi@cs.ucsc.edu - - Steven M. Bellovin - Columbia University - smb@cs.columbia.edu - - Simon Blake-Wilson - BCI - EMail: sblakewilson@bcisse.com - - Ran Canetti - IBM - canetti@watson.ibm.com - - Pete Chown - Skygate Technology Ltd - pc@skygate.co.uk - - Taher Elgamal - taher@securify.com - Securify - - Anil Gangolli - anil@busybuddha.org - - Kipp Hickman - - David Hopwood - Independent Consultant - EMail: david.hopwood@blueyonder.co.uk - - - - -Dierks & Rescorla Standards Track [Page 109] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - Phil Karlton (co-author of SSLv3) - - Paul Kocher (co-author of SSLv3) - Cryptography Research - paul@cryptography.com - - Hugo Krawczyk - Technion Israel Institute of Technology - hugo@ee.technion.ac.il - - Jan Mikkelsen - Transactionware - EMail: janm@transactionware.com - - Magnus Nystrom - RSA Security - EMail: magnus@rsasecurity.com - - 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 - - Tim Wright - Vodafone - EMail: timothy.wright@vodafone.com - -Comments - - The discussion list for the IETF TLS working group is located at the - e-mail address <tls@ietf.org>. Information on the group and - information on how to subscribe to the list is at - <https://www1.ietf.org/mailman/listinfo/tls> - - Archives of the list can be found at: - <http://www.ietf.org/mail-archive/web/tls/current/index.html> - - - - -Dierks & Rescorla Standards Track [Page 110] draft-ietf-tls-rfc4346-bis-01.txt TLS June 2006 - - - Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM 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. - - - Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Dierks & Rescorla Standards Track [Page 111] - |