| blob | e41c5b412bca727fef695747ee2454e019daf5dc |
7 Tim Dierks
8 Independent
9 Eric Rescorla
10 INTERNET-DRAFT Network Resonance, Inc.
11 <draft-ietf-tls-rfc4346-bis-03.txt> March 2007 (Expires September 2007)
13 The TLS Protocol
14 Version 1.2
16 Status of this Memo
17 By submitting this Internet-Draft, each author represents that any
18 applicable patent or other IPR claims of which he or she is aware
19 have been or will be disclosed, and any of which he or she becomes
20 aware will be disclosed, in accordance with Section 6 of BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as Internet-
25 Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 Copyright Notice
40 Copyright (C) The IETF Trust (2007).
42 Abstract
44 This document specifies Version 1.2 of the Transport Layer Security
45 (TLS) protocol. The TLS protocol provides communications security
46 over the Internet. The protocol allows client/server applications to
47 communicate in a way that is designed to prevent eavesdropping,
48 tampering, or message forgery.
50 Table of Contents
52 1. Introduction 3
53 1.1 Requirements Terminology 4
54 1.2 Major Differences from TLS 1.1 5
58 Dierks & Rescorla Standards Track [Page 1]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
61 2. Goals 5
62 3. Goals of This Document 6
63 4. Presentation Language 6
64 4.1. Basic Block Size 6
65 4.2. Miscellaneous 7
66 4.3. Vectors 7
67 4.4. Numbers 8
68 4.5. Enumerateds 8
69 4.6. Constructed Types 9
70 4.6.1. Variants 9
71 4.7. Cryptographic Attributes 10
72 4.8. Constants 12
73 5. HMAC and the Pseudorandom fFunction 12
74 6. The TLS Record Protocol 14
75 6.1. Connection States 14
76 6.2. Record layer 17
77 6.2.1. Fragmentation 17
78 6.2.2. Record Compression and Decompression 18
79 6.2.3. Record Payload Protection 19
80 6.2.3.1. Null or Standard Stream Cipher 19
81 6.2.3.2. CBC Block Cipher 20
82 6.2.3.3. AEAD ciphers 22
83 6.3. Key Calculation 23
84 7. The TLS Handshaking Protocols 24
85 7.1. Change Cipher Spec Protocol 25
86 7.2. Alert Protocol 25
87 7.2.1. Closure Alerts 26
88 7.2.2. Error Alerts 27
89 7.3. Handshake Protocol Overview 30
90 7.4. Handshake Protocol 34
91 7.4.1. Hello Messages 35
92 7.4.1.1. Hello Request 35
93 7.4.1.2. Client Hello 36
94 7.4.1.3. Server Hello 39
95 7.4.1.4 Hello Extensions 40
96 7.4.1.4.1 Cert Hash Types 42
97 7.4.2. Server Certificate 42
98 7.4.3. Server Key Exchange Message 44
99 7.4.4. Certificate Request 46
100 7.4.5 Server hello done 47
101 7.4.6. Client Certificate 48
102 7.4.7. Client Key Exchange Message 48
103 7.4.7.1. RSA Encrypted Premaster Secret Message 49
104 7.4.7.1. Client Diffie-Hellman Public Value 51
105 7.4.8. Certificate verify 52
106 7.4.9. Finished 52
107 8. Cryptographic Computations 53
108 8.1. Computing the Master Secret 54
112 Dierks & Rescorla Standards Track [Page 2]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
115 8.1.1. RSA 54
116 8.1.2. Diffie-Hellman 54
117 9. Mandatory Cipher Suites 54
118 A. Protocol Constant Values 58
119 A.1. Record Layer 58
120 A.2. Change Cipher Specs Message 59
121 A.3. Alert Messages 59
122 A.4. Handshake Protocol 61
123 A.4.1. Hello Messages 61
124 A.4.2. Server Authentication and Key Exchange Messages 62
125 A.4.3. Client Authentication and Key Exchange Messages 63
126 A.4.4. Handshake Finalization Message 64
127 A.5. The CipherSuite 64
128 A.6. The Security Parameters 67
129 B. Glossary 69
130 C. CipherSuite Definitions 73
131 D. Implementation Notes 75
132 D.1 Random Number Generation and Seeding 75
133 D.2 Certificates and Authentication 75
134 D.3 CipherSuites 75
135 E. Backward Compatibility 76
136 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 76
137 E.2 Compatibility with SSL 2.0 77
138 E.2. Avoiding Man-in-the-Middle Version Rollback 79
139 F. Security Analysis 80
140 F.1. Handshake Protocol 80
141 F.1.1. Authentication and Key Exchange 80
142 F.1.1.1. Anonymous Key Exchange 80
143 F.1.1.2. RSA Key Exchange and Authentication 81
144 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 81
145 F.1.2. Version Rollback Attacks 82
146 F.1.3. Detecting Attacks Against the Handshake Protocol 83
147 F.1.4. Resuming Sessions 83
148 F.1.5 Extensions 83
149 F.2. Protecting Application Data 84
150 F.3. Explicit IVs 84
151 F.4. Security of Composite Cipher Modes 84
152 F.5 Denial of Service 85
153 F.6. Final Notes 86
156 1. Introduction
158 The primary goal of the TLS Protocol is to provide privacy and data
159 integrity between two communicating applications. The protocol is
160 composed of two layers: the TLS Record Protocol and the TLS Handshake
161 Protocol. At the lowest level, layered on top of some reliable
162 transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
166 Dierks & Rescorla Standards Track [Page 3]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
169 TLS Record Protocol provides connection security that has two basic
170 properties:
172 - The connection is private. Symmetric cryptography is used for
173 data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for
174 this symmetric encryption are generated uniquely for each
175 connection and are based on a secret negotiated by another
176 protocol (such as the TLS Handshake Protocol). The Record
177 Protocol can also be used without encryption.
179 - The connection is reliable. Message transport includes a message
180 integrity check using a keyed MAC. Secure hash functions (e.g.,
181 SHA, MD5, etc.) are used for MAC computations. The Record
182 Protocol can operate without a MAC, but is generally only used in
183 this mode while another protocol is using the Record Protocol as
184 a transport for negotiating security parameters.
186 The TLS Record Protocol is used for encapsulation of various higher
187 level protocols. One such encapsulated protocol, the TLS Handshake
188 Protocol, allows the server and client to authenticate each other and
189 to negotiate an encryption algorithm and cryptographic keys before
190 the application protocol transmits or receives its first byte of
191 data. The TLS Handshake Protocol provides connection security that
192 has three basic properties:
194 - The peer's identity can be authenticated using asymmetric, or
195 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
196 authentication can be made optional, but is generally required
197 for at least one of the peers.
199 - The negotiation of a shared secret is secure: the negotiated
200 secret is unavailable to eavesdroppers, and for any authenticated
201 connection the secret cannot be obtained, even by an attacker who
202 can place himself in the middle of the connection.
204 - The negotiation is reliable: no attacker can modify the
205 negotiation communication without being detected by the parties
206 to the communication.
208 One advantage of TLS is that it is application protocol independent.
209 Higher-level protocols can layer on top of the TLS Protocol
210 transparently. The TLS standard, however, does not specify how
211 protocols add security with TLS; the decisions on how to initiate TLS
212 handshaking and how to interpret the authentication certificates
213 exchanged are left to the judgment of the designers and implementors
214 of protocols which run on top of TLS.
216 1.1 Requirements Terminology
220 Dierks & Rescorla Standards Track [Page 4]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
225 document are to be interpreted as described in RFC 2119 [RFC2119].
227 1.2 Major Differences from TLS 1.1
228 This document is a revision of the TLS 1.1 [TLS1.1] protocol which
229 contains improved flexibility, particularly for negotiation of
230 cryptographic algorithms. The major changes are:
232 - Merged in TLS Extensions definition and AES Cipher Suites from
233 external documents.
235 - Replacement of MD5/SHA-1 combination in the PRF. Addition
236 of cipher-suite specified PRFs.
238 - Replacement of MD5/SHA-1 combination in the digitally-signed
239 element.
241 - Allow the client to indicate which hash functions it supports
242 for digital signature.
244 - Allow the server to indicate which hash functions it supports
245 for digital signature.
247 - Addition of support for authenticated encryption with additional
248 data modes.
250 - Tightened up a number of requirements.
252 - The usual clarifications and editorial work.
255 2. Goals
257 The goals of TLS Protocol, in order of their priority, are as
258 follows:
260 1. Cryptographic security: TLS should be used to establish a secure
261 connection between two parties.
263 2. Interoperability: Independent programmers should be able to
264 develop applications utilizing TLS that can successfully exchange
265 cryptographic parameters without knowledge of one another's code.
267 3. Extensibility: TLS seeks to provide a framework into which new
268 public key and bulk encryption methods can be incorporated as
269 necessary. This will also accomplish two sub-goals: preventing
270 the need to create a new protocol (and risking the introduction
274 Dierks & Rescorla Standards Track [Page 5]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
277 of possible new weaknesses) and avoiding the need to implement an
278 entire new security library.
280 4. Relative efficiency: Cryptographic operations tend to be highly
281 CPU intensive, particularly public key operations. For this
282 reason, the TLS protocol has incorporated an optional session
283 caching scheme to reduce the number of connections that need to
284 be established from scratch. Additionally, care has been taken to
285 reduce network activity.
287 3. Goals of This Document
289 This document and the TLS protocol itself are based on the SSL 3.0
290 Protocol Specification as published by Netscape. The differences
291 between this protocol and SSL 3.0 are not dramatic, but they are
292 significant enough that the various versions of TLS and SSL 3.0 do
293 not interoperate (although each protocol incorporates a mechanism by
294 which an implementation can back down to prior versions). This
295 document is intended primarily for readers who will be implementing
296 the protocol and for those doing cryptographic analysis of it. The
297 specification has been written with this in mind, and it is intended
298 to reflect the needs of those two groups. For that reason, many of
299 the algorithm-dependent data structures and rules are included in the
300 body of the text (as opposed to in an appendix), providing easier
301 access to them.
303 This document is not intended to supply any details of service
304 definition or of interface definition, although it does cover select
305 areas of policy as they are required for the maintenance of solid
306 security.
308 4. Presentation Language
310 This document deals with the formatting of data in an external
311 representation. The following very basic and somewhat casually
312 defined presentation syntax will be used. The syntax draws from
313 several sources in its structure. Although it resembles the
314 programming language "C" in its syntax and XDR [XDR] in both its
315 syntax and intent, it would be risky to draw too many parallels. The
316 purpose of this presentation language is to document TLS only; it has
317 no have general application beyond that particular goal.
319 4.1. Basic Block Size
321 The representation of all data items is explicitly specified. The
322 basic data block size is one byte (i.e., 8 bits). Multiple byte data
323 items are concatenations of bytes, from left to right, from top to
324 bottom. From the bytestream, a multi-byte item (a numeric in the
328 Dierks & Rescorla Standards Track [Page 6]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
331 example) is formed (using C notation) by:
333 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
334 ... | byte[n-1];
336 This byte ordering for multi-byte values is the commonplace network
337 byte order or big endian format.
339 4.2. Miscellaneous
341 Comments begin with "/*" and end with "*/".
343 Optional components are denoted by enclosing them in "[[ ]]" double
344 brackets.
346 Single-byte entities containing uninterpreted data are of type
347 opaque.
349 4.3. Vectors
351 A vector (single dimensioned array) is a stream of homogeneous data
352 elements. The size of the vector may be specified at documentation
353 time or left unspecified until runtime. In either case, the length
354 declares the number of bytes, not the number of elements, in the
355 vector. The syntax for specifying a new type, T' that is a fixed-
356 length vector of type T is
358 T T'[n];
360 Here, T' occupies n bytes in the data stream, where n is a multiple
361 of the size of T. The length of the vector is not included in the
362 encoded stream.
364 In the following example, Datum is defined to be three consecutive
365 bytes that the protocol does not interpret, while Data is three
366 consecutive Datum, consuming a total of nine bytes.
368 opaque Datum[3]; /* three uninterpreted bytes */
369 Datum Data[9]; /* 3 consecutive 3 byte vectors */
371 Variable-length vectors are defined by specifying a subrange of legal
372 lengths, inclusively, using the notation <floor..ceiling>. When
373 these are encoded, the actual length precedes the vector's contents
374 in the byte stream. The length will be in the form of a number
375 consuming as many bytes as required to hold the vector's specified
376 maximum (ceiling) length. A variable-length vector with an actual
377 length field of zero is referred to as an empty vector.
382 Dierks & Rescorla Standards Track [Page 7]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
385 T T'<floor..ceiling>;
387 In the following example, mandatory is a vector that must contain
388 between 300 and 400 bytes of type opaque. It can never be empty. The
389 actual length field consumes two bytes, a uint16, sufficient to
390 represent the value 400 (see Section 4.4). On the other hand, longer
391 can represent up to 800 bytes of data, or 400 uint16 elements, and it
392 may be empty. Its encoding will include a two-byte actual length
393 field prepended to the vector. The length of an encoded vector must
394 be an even multiple of the length of a single element (for example, a
395 17-byte vector of uint16 would be illegal).
397 opaque mandatory<300..400>;
398 /* length field is 2 bytes, cannot be empty */
399 uint16 longer<0..800>;
400 /* zero to 400 16-bit unsigned integers */
402 4.4. Numbers
404 The basic numeric data type is an unsigned byte (uint8). All larger
405 numeric data types are formed from fixed-length series of bytes
406 concatenated as described in Section 4.1 and are also unsigned. The
407 following numeric types are predefined.
409 uint8 uint16[2];
410 uint8 uint24[3];
411 uint8 uint32[4];
412 uint8 uint64[8];
414 All values, here and elsewhere in the specification, are stored in
415 "network" or "big-endian" order; the uint32 represented by the hex
416 bytes 01 02 03 04 is equivalent to the decimal value 16909060.
418 Note that in some cases (e.g., DH parameters) it is necessary to
419 represent integers as opaque vectors. In such cases, they are
420 represented as unsigned integers (i.e., leading zero octets are not
421 required even if the most significant bit is set).
423 4.5. Enumerateds
425 An additional sparse data type is available called enum. A field of
426 type enum can only assume the values declared in the definition.
427 Each definition is a different type. Only enumerateds of the same
428 type may be assigned or compared. Every element of an enumerated must
429 be assigned a value, as demonstrated in the following example. Since
430 the elements of the enumerated are not ordered, they can be assigned
431 any unique value, in any order.
436 Dierks & Rescorla Standards Track [Page 8]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
439 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
441 Enumerateds occupy as much space in the byte stream as would its
442 maximal defined ordinal value. The following definition would cause
443 one byte to be used to carry fields of type Color.
445 enum { red(3), blue(5), white(7) } Color;
447 One may optionally specify a value without its associated tag to
448 force the width definition without defining a superfluous element.
449 In the following example, Taste will consume two bytes in the data
450 stream but can only assume the values 1, 2, or 4.
452 enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
454 The names of the elements of an enumeration are scoped within the
455 defined type. In the first example, a fully qualified reference to
456 the second element of the enumeration would be Color.blue. Such
457 qualification is not required if the target of the assignment is well
458 specified.
460 Color color = Color.blue; /* overspecified, legal */
461 Color color = blue; /* correct, type implicit */
463 For enumerateds that are never converted to external representation,
464 the numerical information may be omitted.
466 enum { low, medium, high } Amount;
468 4.6. Constructed Types
470 Structure types may be constructed from primitive types for
471 convenience. Each specification declares a new, unique type. The
472 syntax for definition is much like that of C.
474 struct {
475 T1 f1;
476 T2 f2;
477 ...
478 Tn fn;
479 } [[T]];
481 The fields within a structure may be qualified using the type's name,
482 with a syntax much like that available for enumerateds. For example,
483 T.f2 refers to the second field of the previous declaration.
484 Structure definitions may be embedded.
486 4.6.1. Variants
490 Dierks & Rescorla Standards Track [Page 9]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
493 Defined structures may have variants based on some knowledge that is
494 available within the environment. The selector must be an enumerated
495 type that defines the possible variants the structure defines. There
496 must be a case arm for every element of the enumeration declared in
497 the select. The body of the variant structure may be given a label
498 for reference. The mechanism by which the variant is selected at
499 runtime is not prescribed by the presentation language.
501 struct {
502 T1 f1;
503 T2 f2;
504 ....
505 Tn fn;
506 select (E) {
507 case e1: Te1;
508 case e2: Te2;
509 ....
510 case en: Ten;
511 } [[fv]];
512 } [[Tv]];
514 For example:
516 enum { apple, orange } VariantTag;
517 struct {
518 uint16 number;
519 opaque string<0..10>; /* variable length */
520 } V1;
521 struct {
522 uint32 number;
523 opaque string[10]; /* fixed length */
524 } V2;
525 struct {
526 select (VariantTag) { /* value of selector is implicit */
527 case apple: V1; /* VariantBody, tag = apple */
528 case orange: V2; /* VariantBody, tag = orange */
529 } variant_body; /* optional label on variant */
530 } VariantRecord;
532 Variant structures may be qualified (narrowed) by specifying a value
533 for the selector prior to the type. For example, a
535 orange VariantRecord
537 is a narrowed type of a VariantRecord containing a variant_body of
538 type V2.
540 4.7. Cryptographic Attributes
544 Dierks & Rescorla Standards Track [Page 10]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
547 The five cryptographic operations digital signing, stream cipher
548 encryption, block cipher encryption, authenticated encryption with
549 additional data (AEAD) encryption and public key encryption are
550 designated digitally-signed, stream-ciphered, block-ciphered, aead-
551 ciphered, and public-key-encrypted, respectively. A field's
552 cryptographic processing is specified by prepending an appropriate
553 key word designation before the field's type specification.
554 Cryptographic keys are implied by the current session state (see
555 Section 6.1).
557 In digital signing, one-way hash functions are used as input for a
558 signing algorithm. A digitally-signed element is encoded as an opaque
559 vector <0..2^16-1>, where the length is specified by the signing
560 algorithm and key.
562 In RSA signing, the opaque vector contains the signature generated
563 using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1B]. As
564 discussed in [PKCS1B], the DigestInfo MUST be DER encoded and for
565 digest algorithms without parameters (which include SHA-1) the
566 DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted but
567 implementations MUST accept both without parameters and with NULL
568 parameters. Note that earlier versions of TLS used a different RSA
569 signature scheme which did not include a DigestInfo encoding.
571 In DSS, the 20 bytes of the SHA-1 hash are run directly through the
572 Digital Signing Algorithm with no additional hashing. This produces
573 two values, r and s. The DSS signature is an opaque vector, as above,
574 the contents of which are the DER encoding of:
576 Dss-Sig-Value ::= SEQUENCE {
577 r INTEGER,
578 s INTEGER
579 }
581 In stream cipher encryption, the plaintext is exclusive-ORed with an
582 identical amount of output generated from a cryptographically secure
583 keyed pseudorandom number generator.
585 In block cipher encryption, every block of plaintext encrypts to a
586 block of ciphertext. All block cipher encryption is done in CBC
587 (Cipher Block Chaining) mode, and all items that are block-ciphered
588 will be an exact multiple of the cipher block length.
590 In AEAD encryption, the plaintext is simultaneously encrypted and
591 integrity protected. The input may be of any length and the output is
592 generally larger than the input in order to accomodate the integrity
593 check value.
598 Dierks & Rescorla Standards Track [Page 11]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
601 In public key encryption, a public key algorithm is used to encrypt
602 data in such a way that it can be decrypted only with the matching
603 private key. A public-key-encrypted element is encoded as an opaque
604 vector <0..2^16-1>, where the length is specified by the signing
605 algorithm and key.
607 RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
608 defined in [PKCS1B].
610 In the following example
612 stream-ciphered struct {
613 uint8 field1;
614 uint8 field2;
615 digitally-signed opaque hash[20];
616 } UserType;
618 the contents of hash are used as input for the signing algorithm, and
619 then the entire structure is encrypted with a stream cipher. The
620 length of this structure, in bytes would be equal to two bytes for
621 field1 and field2, plus two bytes for the length of the signature,
622 plus the length of the output of the signing algorithm. This is known
623 because the algorithm and key used for the signing are known prior to
624 encoding or decoding this structure.
626 4.8. Constants
628 Typed constants can be defined for purposes of specification by
629 declaring a symbol of the desired type and assigning values to it.
630 Under-specified types (opaque, variable length vectors, and
631 structures that contain opaque) cannot be assigned values. No fields
632 of a multi-element structure or vector may be elided.
634 For example:
636 struct {
637 uint8 f1;
638 uint8 f2;
639 } Example1;
641 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
643 5. HMAC and the Pseudorandom fFunction
645 A number of operations in the TLS record and handshake layer requires
646 a keyed MAC; this is a secure digest of some data protected by a
647 secret. Forging the MAC is infeasible without knowledge of the MAC
648 secret. The construction TLS provides for this operation is known as
652 Dierks & Rescorla Standards Track [Page 12]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
655 HMAC and is described in [HMAC]. Cipher suites MAY define their own
656 MACs.
658 In addition, a construction is required to do expansion of secrets
659 into blocks of data for the purposes of key generation or validation.
660 This pseudo-random function (PRF) takes as input a secret, a seed,
661 and an identifying label and produces an output of arbitrary length.
662 We define one PRF, based on HMAC, which is used for all cipher suites
663 in this document. Cipher suites MAY define their own PRFs.
665 First, we define a data expansion function, P_hash(secret, data) that
666 uses a single hash function to expand a secret and seed into an
667 arbitrary quantity of output:
669 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
670 HMAC_hash(secret, A(2) + seed) +
671 HMAC_hash(secret, A(3) + seed) + ...
673 Where + indicates concatenation.
675 A() is defined as:
676 A(0) = seed
677 A(i) = HMAC_hash(secret, A(i-1))
679 P_hash can be iterated as many times as is necessary to produce the
680 required quantity of data. For example, if P_SHA-1 is being used to
681 create 64 bytes of data, it will have to be iterated 4 times (through
682 A(4)), creating 80 bytes of output data; the last 16 bytes of the
683 final iteration will then be discarded, leaving 64 bytes of output
684 data.
686 TLS's PRF is created by applying P_hash to the secret S as:
688 PRF(secret, label, seed) = P_<hash>(secret, label + seed)
690 All the cipher suites defined in this document and in TLS documents
691 prior to this document MUST use SHA-256 as the basis for their PRF.
692 New cipher suites MUST specify a PRF and in general SHOULD use the
693 TLS PRF with SHA-256 or a stronger standard hash function.
695 The label is an ASCII string. It should be included in the exact form
696 it is given without a length byte or trailing null character. For
697 example, the label "slithy toves" would be processed by hashing the
698 following bytes:
700 73 6C 69 74 68 79 20 74 6F 76 65 73
706 Dierks & Rescorla Standards Track [Page 13]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
709 6. The TLS Record Protocol
711 The TLS Record Protocol is a layered protocol. At each layer,
712 messages may include fields for length, description, and content.
713 The Record Protocol takes messages to be transmitted, fragments the
714 data into manageable blocks, optionally compresses the data, applies
715 a MAC, encrypts, and transmits the result. Received data is
716 decrypted, verified, decompressed, and reassembled, and then
717 delivered to higher-level clients.
719 Four record protocol clients are described in this document: the
720 handshake protocol, the alert protocol, the change cipher spec
721 protocol, and the application data protocol. In order to allow
722 extension of the TLS protocol, additional record types can be
723 supported by the record protocol. New record type values are assigned
724 by IANA as described in Section 11.
727 If a TLS implementation receives a record type it does not
728 understand, it SHOULD just ignore it. Any protocol designed for use
729 over TLS MUST be carefully designed to deal with all possible attacks
730 against it. Note that because the type and length of a record are
731 not protected by encryption, care SHOULD be taken to minimize the
732 value of traffic analysis of these values. Implementations MUST not
733 send record types not defined in this document unless negotiated by
734 some extension.
736 6.1. Connection States
738 A TLS connection state is the operating environment of the TLS Record
739 Protocol. It specifies a compression algorithm, encryption algorithm,
740 and MAC algorithm. In addition, the parameters for these algorithms
741 are known: the MAC secret and the bulk encryption keys for the
742 connection in both the read and the write directions. Logically,
743 there are always four connection states outstanding: the current read
744 and write states, and the pending read and write states. All records
745 are processed under the current read and write states. The security
746 parameters for the pending states can be set by the TLS Handshake
747 Protocol, and the Change Cipher Spec can selectively make either of
748 the pending states current, in which case the appropriate current
749 state is disposed of and replaced with the pending state; the pending
750 state is then reinitialized to an empty state. It is illegal to make
751 a state that has not been initialized with security parameters a
752 current state. The initial current state always specifies that no
753 encryption, compression, or MAC will be used.
755 The security parameters for a TLS Connection read and write state are
756 set by providing the following values:
760 Dierks & Rescorla Standards Track [Page 14]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
763 connection end
764 Whether this entity is considered the "client" or the "server" in
765 this connection.
767 bulk encryption algorithm
768 An algorithm to be used for bulk encryption. This specification
769 includes the key size of this algorithm, how much of that key is
770 secret, whether it is a block, stream, or AEAD cipher, and the
771 block size of the cipher (if appropriate).
773 MAC algorithm
774 An algorithm to be used for message authentication. This
775 specification includes the size of the hash that is returned by
776 the MAC algorithm.
778 compression algorithm
779 An algorithm to be used for data compression. This specification
780 must include all information the algorithm requires to do
781 compression.
783 master secret
784 A 48-byte secret shared between the two peers in the connection.
786 client random
787 A 32-byte value provided by the client.
789 server random
790 A 32-byte value provided by the server.
792 These parameters are defined in the presentation language as:
794 enum { server, client } ConnectionEnd;
796 enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
798 enum { stream, block, aead } CipherType;
800 enum { null, md5, sha, sha256, sha384, sha512} MACAlgorithm;
802 /* The use of "sha" above is historical and denotes SHA-1 */
804 enum { null(0), (255) } CompressionMethod;
806 /* The algorithms specified in CompressionMethod,
807 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
809 struct {
810 ConnectionEnd entity;
814 Dierks & Rescorla Standards Track [Page 15]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
817 BulkCipherAlgorithm bulk_cipher_algorithm;
818 CipherType cipher_type;
819 uint8 enc_key_length;
820 uint8 block_length;
821 uint8 iv_length;
822 MACAlgorithm mac_algorithm;
823 uint8 mac_length;
824 uint8 mac_key_length;
825 CompressionMethod compression_algorithm;
826 opaque master_secret[48];
827 opaque client_random[32];
828 opaque server_random[32];
829 } SecurityParameters;
831 The record layer will use the security parameters to generate the
832 following four items:
834 client write MAC secret
835 server write MAC secret
836 client write key
837 server write key
839 The client write parameters are used by the server when receiving and
840 processing records and vice-versa. The algorithm used for generating
841 these items from the security parameters is described in Section 6.3.
843 Once the security parameters have been set and the keys have been
844 generated, the connection states can be instantiated by making them
845 the current states. These current states MUST be updated for each
846 record processed. Each connection state includes the following
847 elements:
849 compression state
850 The current state of the compression algorithm.
852 cipher state
853 The current state of the encryption algorithm. This will consist
854 of the scheduled key for that connection. For stream ciphers,
855 this will also contain whatever state information is necessary to
856 allow the stream to continue to encrypt or decrypt data.
858 MAC secret
859 The MAC secret for this connection, as generated above.
861 sequence number
862 Each connection state contains a sequence number, which is
863 maintained separately for read and write states. The sequence
864 number MUST be set to zero whenever a connection state is made
868 Dierks & Rescorla Standards Track [Page 16]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
871 the active state. Sequence numbers are of type uint64 and may not
872 exceed 2^64-1. Sequence numbers do not wrap. If a TLS
873 implementation would need to wrap a sequence number, it must
874 renegotiate instead. A sequence number is incremented after each
875 record: specifically, the first record transmitted under a
876 particular connection state MUST use sequence number 0.
878 6.2. Record layer
880 The TLS Record Layer receives uninterpreted data from higher layers
881 in non-empty blocks of arbitrary size.
883 6.2.1. Fragmentation
885 The record layer fragments information blocks into TLSPlaintext
886 records carrying data in chunks of 2^14 bytes or less. Client message
887 boundaries are not preserved in the record layer (i.e., multiple
888 client messages of the same ContentType MAY be coalesced into a
889 single TLSPlaintext record, or a single message MAY be fragmented
890 across several records).
893 struct {
894 uint8 major, minor;
895 } ProtocolVersion;
897 enum {
898 change_cipher_spec(20), alert(21), handshake(22),
899 application_data(23), (255)
900 } ContentType;
902 struct {
903 ContentType type;
904 ProtocolVersion version;
905 uint16 length;
906 opaque fragment[TLSPlaintext.length];
907 } TLSPlaintext;
909 type
910 The higher-level protocol used to process the enclosed fragment.
912 version
913 The version of the protocol being employed. This document
914 describes TLS Version 1.2, which uses the version { 3, 3 }. The
915 version value 3.3 is historical, deriving from the use of 3.1 for
916 TLS 1.0. (See Appendix A.1). Note that a client that supports
917 multiple versions of TLS may not know what version will be
918 employed before it receives ServerHello. See Appendix E for
922 Dierks & Rescorla Standards Track [Page 17]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
925 discussion about what record layer version number should be
926 employed for ClientHello.
928 length
929 The length (in bytes) of the following TLSPlaintext.fragment.
930 The length MUST not exceed 2^14.
932 fragment
933 The application data. This data is transparent and treated as an
934 independent block to be dealt with by the higher-level protocol
935 specified by the type field.
937 Implementations MUST not send zero-length fragments of Handshake,
938 Alert, or Change Cipher Spec content types. Zero-length fragments
939 of Application data MAY be sent as they are potentially useful as
940 a traffic analysis countermeasure.
942 Note: Data of different TLS Record layer content types MAY be
943 interleaved. Application data is generally of lower precedence
944 for transmission than other content types. However, records MUST
945 be delivered to the network in the same order as they are
946 protected by the record layer. Recipients MUST receive and
947 process interleaved application layer traffic during handshakes
948 subsequent to the first one on a connection.
951 6.2.2. Record Compression and Decompression
953 All records are compressed using the compression algorithm defined in
954 the current session state. There is always an active compression
955 algorithm; however, initially it is defined as
956 CompressionMethod.null. The compression algorithm translates a
957 TLSPlaintext structure into a TLSCompressed structure. Compression
958 functions are initialized with default state information whenever a
959 connection state is made active.
961 Compression must be lossless and may not increase the content length
962 by more than 1024 bytes. If the decompression function encounters a
963 TLSCompressed.fragment that would decompress to a length in excess of
964 2^14 bytes, it MUST report a fatal decompression failure error.
966 struct {
967 ContentType type; /* same as TLSPlaintext.type */
968 ProtocolVersion version;/* same as TLSPlaintext.version */
969 uint16 length;
970 opaque fragment[TLSCompressed.length];
971 } TLSCompressed;
976 Dierks & Rescorla Standards Track [Page 18]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
979 length
980 The length (in bytes) of the following TLSCompressed.fragment.
981 The length should not exceed 2^14 + 1024.
983 fragment
984 The compressed form of TLSPlaintext.fragment.
986 Note: A CompressionMethod.null operation is an identity operation; no
987 fields are altered.
989 Implementation note:
990 Decompression functions are responsible for ensuring that
991 messages cannot cause internal buffer overflows.
993 6.2.3. Record Payload Protection
995 The encryption and MAC functions translate a TLSCompressed structure
996 into a TLSCiphertext. The decryption functions reverse the process.
997 The MAC of the record also includes a sequence number so that
998 missing, extra, or repeated messages are detectable.
1000 struct {
1001 ContentType type;
1002 ProtocolVersion version;
1003 uint16 length;
1004 select (SecurityParameters.cipher_type) {
1005 case stream: GenericStreamCipher;
1006 case block: GenericBlockCipher;
1007 case aead: GenericAEADCipher;
1008 } fragment;
1009 } TLSCiphertext;
1011 type
1012 The type field is identical to TLSCompressed.type.
1014 version
1015 The version field is identical to TLSCompressed.version.
1017 length
1018 The length (in bytes) of the following TLSCiphertext.fragment.
1019 The length may not exceed 2^14 + 2048.
1021 fragment
1022 The encrypted form of TLSCompressed.fragment, with the MAC.
1024 6.2.3.1. Null or Standard Stream Cipher
1026 Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
1030 Dierks & Rescorla Standards Track [Page 19]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1033 convert TLSCompressed.fragment structures to and from stream
1034 TLSCiphertext.fragment structures.
1036 stream-ciphered struct {
1037 opaque content[TLSCompressed.length];
1038 opaque MAC[SecurityParameters.mac_length];
1039 } GenericStreamCipher;
1041 The MAC is generated as:
1043 HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
1044 TLSCompressed.version + TLSCompressed.length +
1045 TLSCompressed.fragment));
1047 where "+" denotes concatenation.
1049 seq_num
1050 The sequence number for this record.
1052 hash
1053 The hashing algorithm specified by
1054 SecurityParameters.mac_algorithm.
1056 Note that the MAC is computed before encryption. The stream cipher
1057 encrypts the entire block, including the MAC. For stream ciphers that
1058 do not use a synchronization vector (such as RC4), the stream cipher
1059 state from the end of one record is simply used on the subsequent
1060 packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
1061 consists of the identity operation (i.e., the data is not encrypted,
1062 and the MAC size is zero, implying that no MAC is used).
1063 TLSCiphertext.length is TLSCompressed.length plus
1064 SecurityParameters.mac_length.
1066 6.2.3.2. CBC Block Cipher
1068 For block ciphers (such as RC2, DES, or AES), the encryption and MAC
1069 functions convert TLSCompressed.fragment structures to and from block
1070 TLSCiphertext.fragment structures.
1072 block-ciphered struct {
1073 opaque IV[SecurityParameters.block_length];
1074 opaque content[TLSCompressed.length];
1075 opaque MAC[SecurityParameters.mac_length];
1076 uint8 padding[GenericBlockCipher.padding_length];
1077 uint8 padding_length;
1078 } GenericBlockCipher;
1080 The MAC is generated as described in Section 6.2.3.1.
1084 Dierks & Rescorla Standards Track [Page 20]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1087 IV
1088 TLS 1.2 uses an explicit IV in order to prevent the attacks
1089 described by [CBCATT]. The IV SHOULD be chosen at random and MUST
1090 be unpredictable. In order to decrypt, thereceiver decrypts the
1091 entire GenericBlockCipher structure and then discards the first
1092 cipher block, corresponding to the IV component.
1094 padding
1095 Padding that is added to force the length of the plaintext to be
1096 an integral multiple of the block cipher's block length. The
1097 padding MAY be any length up to 255 bytes, as long as it results
1098 in the TLSCiphertext.length being an integral multiple of the
1099 block length. Lengths longer than necessary might be desirable to
1100 frustrate attacks on a protocol based on analysis of the lengths
1101 of exchanged messages. Each uint8 in the padding data vector MUST
1102 be filled with the padding length value. The receiver MUST check
1103 this padding and SHOULD use the bad_record_mac alert to indicate
1104 padding errors.
1106 padding_length
1107 The padding length MUST be such that the total size of the
1108 GenericBlockCipher structure is a multiple of the cipher's block
1109 length. Legal values range from zero to 255, inclusive. This
1110 length specifies the length of the padding field exclusive of the
1111 padding_length field itself.
1113 The encrypted data length (TLSCiphertext.length) is one more than the
1114 sum of TLSCompressed.length, SecurityParameters.mac_length, and
1115 padding_length.
1117 Example: If the block length is 8 bytes, the content length
1118 (TLSCompressed.length) is 61 bytes, and the MAC length is 20
1119 bytes, then the length before padding is 82 bytes (this does
1120 not include the IV, which may or may not be encrypted, as
1121 discussed above). Thus, the padding length modulo 8 must be
1122 equal to 6 in order to make the total length an even multiple
1123 of 8 bytes (the block length). The padding length can be 6,
1124 14, 22, and so on, through 254. If the padding length were the
1125 minimum necessary, 6, the padding would be 6 bytes, each
1126 containing the value 6. Thus, the last 8 octets of the
1127 GenericBlockCipher before block encryption would be xx 06 06
1128 06 06 06 06 06, where xx is the last octet of the MAC.
1130 Note: With block ciphers in CBC mode (Cipher Block Chaining),
1131 it is critical that the entire plaintext of the record be known
1132 before any ciphertext is transmitted. Otherwise, it is possible
1133 for the attacker to mount the attack described in [CBCATT].
1138 Dierks & Rescorla Standards Track [Page 21]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1141 Implementation Note: Canvel et al. [CBCTIME] have demonstrated a timing
1142 attack on CBC padding based on the time required to compute the
1143 MAC. In order to defend against this attack, implementations MUST
1144 ensure that record processing time is essentially the same
1145 whether or not the padding is correct. In general, the best way
1146 to do this is to compute the MAC even if the padding is
1147 incorrect, and only then reject the packet. For instance, if the
1148 pad appears to be incorrect, the implementation might assume a
1149 zero-length pad and then compute the MAC. This leaves a small
1150 timing channel, since MAC performance depends to some extent on
1151 the size of the data fragment, but it is not believed to be large
1152 enough to be exploitable, due to the large block size of existing
1153 MACs and the small size of the timing signal.
1155 6.2.3.3. AEAD ciphers
1157 For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
1158 converts TLSCompressed.fragment structures to and from AEAD
1159 TLSCiphertext.fragment structures.
1161 aead-ciphered struct {
1162 opaque IV[SecurityParameters.iv_length];
1163 opaque aead_output[AEADEncrypted.length];
1164 } GenericAEADCipher;
1166 AEAD ciphers take as input a single key, a nonce, a plaintext, and
1167 "additional data" to be included in the authentication check, as
1168 described in Section 2.1 of [AEAD]. These inputs are as follows.
1170 The key is either the client_write_key or the server_write_key. The
1171 MAC key will be of length zero.
1173 The nonce supplied to the AEAD operations is determined by the IV in
1174 aead-ciphered struct. Each IV used in distinct invocations of the
1175 AEAD encryption operation MUST be distinct, for any fixed value of
1176 the key. Implementations SHOULD use the recommended nonce formation
1177 method of [AEAD] to generate IVs, and MAY use any other method that
1178 meets this requirement. The length of the IV depends on the AEAD
1179 cipher; that length MAY be zero. Note that in many cases it is
1180 appropriate to use the partially implicit nonce technique of S 3.2.1
1181 of AEAD, in which case the client_write_iv and server_write_iv should
1182 be used as the "fixed-common".
1184 The plaintext is the TLSCompressed.fragment.
1186 The additional authenticated data, which we denote as
1187 additional_data, is defined as follows:
1192 Dierks & Rescorla Standards Track [Page 22]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1195 additional_data = seq_num + TLSCompressed.type +
1196 TLSCompressed.version + TLSCompressed.length;
1198 The aead_output consists of the ciphertext output by the AEAD
1199 encryption operation. AEADEncrypted.length will generally be larger
1200 than TLSCompressed.length, but by an amount that varies with the AEAD
1201 cipher. Since the ciphers might incorporate padding, the amount of
1202 overhead could vary with different TLSCompressed.length values. Each
1203 AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
1204 Symbolically,
1206 AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
1207 additional_data)
1209 Where "+" denotes concatenation.
1212 In order to decrypt and verify, the cipher takes as input the key,
1213 IV, the "additional_data", and the AEADEncrypted value. The output is
1214 either the plaintext or an error indicating that the decryption
1215 failed. There is no separate integrity check. I.e.,
1217 TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted,
1218 TLSCiphertext.type + TLSCiphertext.version +
1219 TLSCiphertext.length);
1221 If the decryption fails, a fatal bad_record_mac alert MUST be
1222 generated.
1224 6.3. Key Calculation
1226 The Record Protocol requires an algorithm to generate keys, and MAC
1227 secrets from the security parameters provided by the handshake
1228 protocol.
1230 The master secret is hashed into a sequence of secure bytes, which
1231 are assigned to the MAC secrets and keys required by the current
1232 connection state (see Appendix A.6). CipherSpecs require a client
1233 write MAC secret, a server write MAC secret, a client write key, and
1234 a server write key, each of which is generated from the master secret
1235 in that order. Unused values are empty.
1237 When keys and MAC secrets are generated, the master secret is used as
1238 an entropy source.
1240 To generate the key material, compute
1242 key_block = PRF(SecurityParameters.master_secret,
1246 Dierks & Rescorla Standards Track [Page 23]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1249 "key expansion",
1250 SecurityParameters.server_random +
1251 SecurityParameters.client_random);
1253 until enough output has been generated. Then the key_block is
1254 partitioned as follows:
1256 client_write_MAC_secret[SecurityParameters.mac_key_length]
1257 server_write_MAC_secret[SecurityParameters.mac_key_length]
1258 client_write_key[SecurityParameters.enc_key_length]
1259 server_write_key[SecurityParameters.enc_key_length]
1262 Implementation note:
1263 The currently defined cipher suite which requires the most
1264 material is AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x
1265 32 byte keys and 2 x 20 byte MAC secrets, for a total 104 bytes
1266 of key material.
1268 7. The TLS Handshaking Protocols
1270 TLS has three subprotocols that are used to allow peers to agree
1271 upon security parameters for the record layer, to authenticate
1272 themselves, to instantiate negotiated security parameters, and to
1273 report error conditions to each other.
1275 The Handshake Protocol is responsible for negotiating a session,
1276 which consists of the following items:
1278 session identifier
1279 An arbitrary byte sequence chosen by the server to identify an
1280 active or resumable session state.
1282 peer certificate
1283 X509v3 [X509] certificate of the peer. This element of the
1284 state may be null.
1286 compression method
1287 The algorithm used to compress data prior to encryption.
1289 cipher spec
1290 Specifies the bulk data encryption algorithm (such as null,
1291 DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
1292 defines cryptographic attributes such as the hash_size. (See
1293 Appendix A.6 for formal definition,)
1295 master secret
1296 48-byte secret shared between the client and server.
1300 Dierks & Rescorla Standards Track [Page 24]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1303 is resumable
1304 A flag indicating whether the session can be used to initiate
1305 new connections.
1307 These items are then used to create security parameters for use by
1308 the Record Layer when protecting application data. Many connections
1309 can be instantiated using the same session through the resumption
1310 feature of the TLS Handshake Protocol.
1312 7.1. Change Cipher Spec Protocol
1314 The change cipher spec protocol exists to signal transitions in
1315 ciphering strategies. The protocol consists of a single message,
1316 which is encrypted and compressed under the current (not the pending)
1317 connection state. The message consists of a single byte of value 1.
1319 struct {
1320 enum { change_cipher_spec(1), (255) } type;
1321 } ChangeCipherSpec;
1323 The change cipher spec message is sent by both the client and the
1324 server to notify the receiving party that subsequent records will be
1325 protected under the newly negotiated CipherSpec and keys. Reception
1326 of this message causes the receiver to instruct the Record Layer to
1327 immediately copy the read pending state into the read current state.
1328 Immediately after sending this message, the sender MUST instruct the
1329 record layer to make the write pending state the write active state.
1330 (See Section 6.1.) The change cipher spec message is sent during the
1331 handshake after the security parameters have been agreed upon, but
1332 before the verifying finished message is sent (see Section 7.4.11
1334 Note: If a rehandshake occurs while data is flowing on a connection,
1335 the communicating parties may continue to send data using the old
1336 CipherSpec. However, once the ChangeCipherSpec has been sent, the new
1337 CipherSpec MUST be used. The first side to send the ChangeCipherSpec
1338 does not know that the other side has finished computing the new
1339 keying material (e.g., if it has to perform a time consuming public
1340 key operation). Thus, a small window of time, during which the
1341 recipient must buffer the data, MAY exist. In practice, with modern
1342 machines this interval is likely to be fairly short.
1344 7.2. Alert Protocol
1346 One of the content types supported by the TLS Record layer is the
1347 alert type. Alert messages convey the severity of the message and a
1348 description of the alert. Alert messages with a level of fatal result
1349 in the immediate termination of the connection. In this case, other
1350 connections corresponding to the session may continue, but the
1354 Dierks & Rescorla Standards Track [Page 25]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1357 session identifier MUST be invalidated, preventing the failed session
1358 from being used to establish new connections. Like other messages,
1359 alert messages are encrypted and compressed, as specified by the
1360 current connection state.
1362 enum { warning(1), fatal(2), (255) } AlertLevel;
1364 enum {
1365 close_notify(0),
1366 unexpected_message(10),
1367 bad_record_mac(20),
1368 decryption_failed_RESERVED(21),
1369 record_overflow(22),
1370 decompression_failure(30),
1371 handshake_failure(40),
1372 no_certificate_RESERVED(41),
1373 bad_certificate(42),
1374 unsupported_certificate(43),
1375 certificate_revoked(44),
1376 certificate_expired(45),
1377 certificate_unknown(46),
1378 illegal_parameter(47),
1379 unknown_ca(48),
1380 access_denied(49),
1381 decode_error(50),
1382 decrypt_error(51),
1383 export_restriction_RESERVED(60),
1384 protocol_version(70),
1385 insufficient_security(71),
1386 internal_error(80),
1387 user_canceled(90),
1388 no_renegotiation(100),
1389 unsupported_extension(110), /* new */
1390 (255)
1391 } AlertDescription;
1393 struct {
1394 AlertLevel level;
1395 AlertDescription description;
1396 } Alert;
1398 7.2.1. Closure Alerts
1400 The client and the server must share knowledge that the connection is
1401 ending in order to avoid a truncation attack. Either party may
1402 initiate the exchange of closing messages.
1404 close_notify
1408 Dierks & Rescorla Standards Track [Page 26]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1411 This message notifies the recipient that the sender will not send
1412 any more messages on this connection. Note that as of TLS 1.1,
1413 failure to properly close a connection no longer requires that a
1414 session not be resumed. This is a change from TLS 1.0 to conform
1415 with widespread implementation practice.
1417 Either party may initiate a close by sending a close_notify alert.
1418 Any data received after a closure alert is ignored.
1420 Unless some other fatal alert has been transmitted, each party is
1421 required to send a close_notify alert before closing the write side
1422 of the connection. The other party MUST respond with a close_notify
1423 alert of its own and close down the connection immediately,
1424 discarding any pending writes. It is not required for the initiator
1425 of the close to wait for the responding close_notify alert before
1426 closing the read side of the connection.
1428 If the application protocol using TLS provides that any data may be
1429 carried over the underlying transport after the TLS connection is
1430 closed, the TLS implementation must receive the responding
1431 close_notify alert before indicating to the application layer that
1432 the TLS connection has ended. If the application protocol will not
1433 transfer any additional data, but will only close the underlying
1434 transport connection, then the implementation MAY choose to close the
1435 transport without waiting for the responding close_notify. No part of
1436 this standard should be taken to dictate the manner in which a usage
1437 profile for TLS manages its data transport, including when
1438 connections are opened or closed.
1440 Note: It is assumed that closing a connection reliably delivers
1441 pending data before destroying the transport.
1443 7.2.2. Error Alerts
1445 Error handling in the TLS Handshake protocol is very simple. When an
1446 error is detected, the detecting party sends a message to the other
1447 party. Upon transmission or receipt of a fatal alert message, both
1448 parties immediately close the connection. Servers and clients MUST
1449 forget any session-identifiers, keys, and secrets associated with a
1450 failed connection. Thus, any connection terminated with a fatal alert
1451 MUST NOT be resumed. The following error alerts are defined:
1453 unexpected_message
1454 An inappropriate message was received. This alert is always fatal
1455 and should never be observed in communication between proper
1456 implementations.
1458 bad_record_mac
1462 Dierks & Rescorla Standards Track [Page 27]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1465 This alert is returned if a record is received with an incorrect
1466 MAC. This alert also MUST be returned if an alert is sent because
1467 a TLSCiphertext decrypted in an invalid way: either it wasn't an
1468 even multiple of the block length, or its padding values, when
1469 checked, weren't correct. This message is always fatal.
1471 decryption_failed_RESERVED
1472 This alert was used in some earlier versions of TLS, and may have
1473 permitted certain attacks against the CBC mode [CBCATT]. It MUST
1474 NOT be sent by compliant implementations.
1476 record_overflow
1477 A TLSCiphertext record was received that had a length more than
1478 2^14+2048 bytes, or a record decrypted to a TLSCompressed record
1479 with more than 2^14+1024 bytes. This message is always fatal.
1481 decompression_failure
1482 The decompression function received improper input (e.g., data
1483 that would expand to excessive length). This message is always
1484 fatal.
1486 handshake_failure
1487 Reception of a handshake_failure alert message indicates that the
1488 sender was unable to negotiate an acceptable set of security
1489 parameters given the options available. This is a fatal error.
1491 no_certificate_RESERVED
1492 This alert was used in SSLv3 but not any version of TLS. It MUST
1493 NOT be sent by compliant implementations.
1495 bad_certificate
1496 A certificate was corrupt, contained signatures that did not
1497 verify correctly, etc.
1499 unsupported_certificate
1500 A certificate was of an unsupported type.
1502 certificate_revoked
1503 A certificate was revoked by its signer.
1505 certificate_expired
1506 A certificate has expired or is not currently valid.
1508 certificate_unknown
1509 Some other (unspecified) issue arose in processing the
1510 certificate, rendering it unacceptable.
1512 illegal_parameter
1516 Dierks & Rescorla Standards Track [Page 28]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1519 A field in the handshake was out of range or inconsistent with
1520 other fields. This is always fatal.
1522 unknown_ca
1523 A valid certificate chain or partial chain was received, but the
1524 certificate was not accepted because the CA certificate could not
1525 be located or couldn't be matched with a known, trusted CA. This
1526 message is always fatal.
1528 access_denied
1529 A valid certificate was received, but when access control was
1530 applied, the sender decided not to proceed with negotiation.
1531 This message is always fatal.
1533 decode_error
1534 A message could not be decoded because some field was out of the
1535 specified range or the length of the message was incorrect. This
1536 message is always fatal.
1538 decrypt_error
1539 A handshake cryptographic operation failed, including being
1540 unable to correctly verify a signature, decrypt a key exchange,
1541 or validate a finished message.
1543 export_restriction_RESERVED
1544 This alert was used in some earlier versions of TLS. It MUST NOT
1545 be sent by compliant implementations.
1547 protocol_version
1548 The protocol version the client has attempted to negotiate is
1549 recognized but not supported. (For example, old protocol versions
1550 might be avoided for security reasons). This message is always
1551 fatal.
1553 insufficient_security
1554 Returned instead of handshake_failure when a negotiation has
1555 failed specifically because the server requires ciphers more
1556 secure than those supported by the client. This message is always
1557 fatal.
1559 internal_error
1560 An internal error unrelated to the peer or the correctness of the
1561 protocol (such as a memory allocation failure) makes it
1562 impossible to continue. This message is always fatal.
1564 user_canceled
1565 This handshake is being canceled for some reason unrelated to a
1566 protocol failure. If the user cancels an operation after the
1570 Dierks & Rescorla Standards Track [Page 29]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1573 handshake is complete, just closing the connection by sending a
1574 close_notify is more appropriate. This alert should be followed
1575 by a close_notify. This message is generally a warning.
1577 no_renegotiation
1578 Sent by the client in response to a hello request or by the
1579 server in response to a client hello after initial handshaking.
1580 Either of these would normally lead to renegotiation; when that
1581 is not appropriate, the recipient should respond with this alert.
1582 At that point, the original requester can decide whether to
1583 proceed with the connection. One case where this would be
1584 appropriate is where a server has spawned a process to satisfy a
1585 request; the process might receive security parameters (key
1586 length, authentication, etc.) at startup and it might be
1587 difficult to communicate changes to these parameters after that
1588 point. This message is always a warning.
1590 unsupported_extension
1591 sent by clients that receive an extended server hello containing
1592 an extension that they did not put in the corresponding client
1593 hello (see Section 2.3). This message is always fatal.
1595 For all errors where an alert level is not explicitly specified, the
1596 sending party MAY determine at its discretion whether this is a fatal
1597 error or not; if an alert with a level of warning is received, the
1598 receiving party MAY decide at its discretion whether to treat this as
1599 a fatal error or not. However, all messages which are transmitted
1600 with a level of fatal MUST be treated as fatal messages.
1602 New Alert values are assigned by IANA as described in Section 11.
1604 7.3. Handshake Protocol Overview
1606 The cryptographic parameters of the session state are produced by the
1607 TLS Handshake Protocol, which operates on top of the TLS Record
1608 Layer. When a TLS client and server first start communicating, they
1609 agree on a protocol version, select cryptographic algorithms,
1610 optionally authenticate each other, and use public-key encryption
1611 techniques to generate shared secrets.
1613 The TLS Handshake Protocol involves the following steps:
1615 - Exchange hello messages to agree on algorithms, exchange random
1616 values, and check for session resumption.
1618 - Exchange the necessary cryptographic parameters to allow the
1619 client and server to agree on a premaster secret.
1624 Dierks & Rescorla Standards Track [Page 30]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1627 - Exchange certificates and cryptographic information to allow the
1628 client and server to authenticate themselves.
1630 - Generate a master secret from the premaster secret and exchanged
1631 random values.
1633 - Provide security parameters to the record layer.
1635 - Allow the client and server to verify that their peer has
1636 calculated the same security parameters and that the handshake
1637 occurred without tampering by an attacker.
1639 Note that higher layers should not be overly reliant on whether TLS
1640 always negotiates the strongest possible connection between two
1641 peers. There are a number of ways in which a man in the middle
1642 attacker can attempt to make two entities drop down to the least
1643 secure method they support. The protocol has been designed to
1644 minimize this risk, but there are still attacks available: for
1645 example, an attacker could block access to the port a secure service
1646 runs on, or attempt to get the peers to negotiate an unauthenticated
1647 connection. The fundamental rule is that higher levels must be
1648 cognizant of what their security requirements are and never transmit
1649 information over a channel less secure than what they require. The
1650 TLS protocol is secure in that any cipher suite offers its promised
1651 level of security: if you negotiate 3DES with a 1024 bit RSA key
1652 exchange with a host whose certificate you have verified, you can
1653 expect to be that secure.
1655 These goals are achieved by the handshake protocol, which can be
1656 summarized as follows: The client sends a client hello message to
1657 which the server must respond with a server hello message, or else a
1658 fatal error will occur and the connection will fail. The client hello
1659 and server hello are used to establish security enhancement
1660 capabilities between client and server. The client hello and server
1661 hello establish the following attributes: Protocol Version, Session
1662 ID, Cipher Suite, and Compression Method. Additionally, two random
1663 values are generated and exchanged: ClientHello.random and
1664 ServerHello.random.
1666 The actual key exchange uses up to four messages: the server
1667 certificate, the server key exchange, the client certificate, and the
1668 client key exchange. New key exchange methods can be created by
1669 specifying a format for these messages and by defining the use of the
1670 messages to allow the client and server to agree upon a shared
1671 secret. This secret MUST be quite long; currently defined key
1672 exchange methods exchange secrets that range from 48 to 128 bytes in
1673 length.
1678 Dierks & Rescorla Standards Track [Page 31]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1681 Following the hello messages, the server will send its certificate,
1682 if it is to be authenticated. Additionally, a server key exchange
1683 message may be sent, if it is required (e.g., if their server has no
1684 certificate, or if its certificate is for signing only). If the
1685 server is authenticated, it may request a certificate from the
1686 client, if that is appropriate to the cipher suite selected. Next,
1687 the server will send the server hello done message, indicating that
1688 the hello-message phase of the handshake is complete. The server will
1689 then wait for a client response. If the server has sent a certificate
1690 request message, the client must send the certificate message. The
1691 client key exchange message is now sent, and the content of that
1692 message will depend on the public key algorithm selected between the
1693 client hello and the server hello. If the client has sent a
1694 certificate with signing ability, a digitally-signed certificate
1695 verify message is sent to explicitly verify possession of the private
1696 key in the certificate.
1698 At this point, a change cipher spec message is sent by the client,
1699 and the client copies the pending Cipher Spec into the current Cipher
1700 Spec. The client then immediately sends the finished message under
1701 the new algorithms, keys, and secrets. In response, the server will
1702 send its own change cipher spec message, transfer the pending to the
1703 current Cipher Spec, and send its finished message under the new
1732 Dierks & Rescorla Standards Track [Page 32]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1735 Cipher Spec. At this point, the handshake is complete, and the client
1736 and server may begin to exchange application layer data. (See flow
1737 chart below.) Application data MUST NOT be sent prior to the
1738 completion of the first handshake (before a cipher suite other
1739 TLS_NULL_WITH_NULL_NULL is established).
1741 Client Server
1743 ClientHello -------->
1744 ServerHello
1745 Certificate*
1746 CertificateStatus*
1747 ServerKeyExchange*
1748 CertificateRequest*
1749 <-------- ServerHelloDone
1750 Certificate*
1751 CertificateURL*
1752 ClientKeyExchange
1753 CertificateVerify*
1754 [ChangeCipherSpec]
1755 Finished -------->
1756 [ChangeCipherSpec]
1757 <-------- Finished
1758 Application Data <-------> Application Data
1760 Fig. 1. Message flow for a full handshake
1762 * Indicates optional or situation-dependent messages that are not
1763 always sent.
1765 Note: To help avoid pipeline stalls, ChangeCipherSpec is an
1766 independent TLS Protocol content type, and is not actually a TLS
1767 handshake message.
1769 When the client and server decide to resume a previous session or
1770 duplicate an existing session (instead of negotiating new security
1771 parameters), the message flow is as follows:
1773 The client sends a ClientHello using the Session ID of the session to
1774 be resumed. The server then checks its session cache for a match. If
1775 a match is found, and the server is willing to re-establish the
1776 connection under the specified session state, it will send a
1777 ServerHello with the same Session ID value. At this point, both
1778 client and server MUST send change cipher spec messages and proceed
1779 directly to finished messages. Once the re-establishment is complete,
1780 the client and server MAY begin to exchange application layer data.
1781 (See flow chart below.) If a Session ID match is not found, the
1782 server generates a new session ID and the TLS client and server
1786 Dierks & Rescorla Standards Track [Page 33]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1789 perform a full handshake.
1791 Client Server
1793 ClientHello -------->
1794 ServerHello
1795 [ChangeCipherSpec]
1796 <-------- Finished
1797 [ChangeCipherSpec]
1798 Finished -------->
1799 Application Data <-------> Application Data
1801 Fig. 2. Message flow for an abbreviated handshake
1803 The contents and significance of each message will be presented in
1804 detail in the following sections.
1806 7.4. Handshake Protocol
1808 The TLS Handshake Protocol is one of the defined higher-level clients
1809 of the TLS Record Protocol. This protocol is used to negotiate the
1810 secure attributes of a session. Handshake messages are supplied to
1811 the TLS Record Layer, where they are encapsulated within one or more
1812 TLSPlaintext structures, which are processed and transmitted as
1813 specified by the current active session state.
1815 enum {
1816 hello_request(0), client_hello(1), server_hello(2),
1817 certificate(11), server_key_exchange (12),
1818 certificate_request(13), server_hello_done(14),
1819 certificate_verify(15), client_key_exchange(16),
1820 finished(20)
1821 (255)
1822 } HandshakeType;
1824 struct {
1825 HandshakeType msg_type; /* handshake type */
1826 uint24 length; /* bytes in message */
1827 select (HandshakeType) {
1828 case hello_request: HelloRequest;
1829 case client_hello: ClientHello;
1830 case server_hello: ServerHello;
1831 case certificate: Certificate;
1832 case server_key_exchange: ServerKeyExchange;
1833 case certificate_request: CertificateRequest;
1834 case server_hello_done: ServerHelloDone;
1835 case certificate_verify: CertificateVerify;
1836 case client_key_exchange: ClientKeyExchange;
1840 Dierks & Rescorla Standards Track [Page 34]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1843 case finished: Finished;
1844 } body;
1845 } Handshake;
1847 The handshake protocol messages are presented below in the order they
1848 MUST be sent; sending handshake messages in an unexpected order
1849 results in a fatal error. Unneeded handshake messages can be omitted,
1850 however. Note one exception to the ordering: the Certificate message
1851 is used twice in the handshake (from server to client, then from
1852 client to server), but described only in its first position. The one
1853 message that is not bound by these ordering rules is the Hello
1854 Request message, which can be sent at any time, but which should be
1855 ignored by the client if it arrives in the middle of a handshake.
1857 New Handshake message types are assigned by IANA as described in
1858 Section 11.
1860 7.4.1. Hello Messages
1862 The hello phase messages are used to exchange security enhancement
1863 capabilities between the client and server. When a new session
1864 begins, the Record Layer's connection state encryption, hash, and
1865 compression algorithms are initialized to null. The current
1866 connection state is used for renegotiation messages.
1868 7.4.1.1. Hello Request
1870 When this message will be sent:
1871 The hello request message MAY be sent by the server at any time.
1873 Meaning of this message:
1874 Hello request is a simple notification that the client should
1875 begin the negotiation process anew by sending a client hello
1876 message when convenient. This message is not intended to
1877 establish which side is the client or server but merely to
1878 initiate a new negotiation. Servers SHOULD not send a
1879 HelloRequest immediately upon the client's initial connection.
1880 It is the client's job to send a ClientHello at that time.
1882 This message will be ignored by the client if the client is
1883 currently negotiating a session. This message may be ignored by
1884 the client if it does not wish to renegotiate a session, or the
1885 client may, if it wishes, respond with a no_renegotiation alert.
1886 Since handshake messages are intended to have transmission
1887 precedence over application data, it is expected that the
1888 negotiation will begin before no more than a few records are
1889 received from the client. If the server sends a hello request but
1890 does not receive a client hello in response, it may close the
1894 Dierks & Rescorla Standards Track [Page 35]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1897 connection with a fatal alert.
1899 After sending a hello request, servers SHOULD not repeat the request
1900 until the subsequent handshake negotiation is complete.
1902 Structure of this message:
1903 struct { } HelloRequest;
1905 Note: This message MUST NOT be included in the message hashes that are
1906 maintained throughout the handshake and used in the finished
1907 messages and the certificate verify message.
1909 7.4.1.2. Client Hello
1911 When this message will be sent:
1912 When a client first connects to a server it is required to send
1913 the client hello as its first message. The client can also send a
1914 client hello in response to a hello request or on its own
1915 initiative in order to renegotiate the security parameters in an
1916 existing connection.
1918 Structure of this message:
1919 The client hello message includes a random structure, which is
1920 used later in the protocol.
1922 struct {
1923 uint32 gmt_unix_time;
1924 opaque random_bytes[28];
1925 } Random;
1927 gmt_unix_time
1928 The current time and date in standard UNIX 32-bit format (seconds
1929 since the midnight starting Jan 1, 1970, GMT, ignoring leap
1930 seconds) according to the sender's internal clock. Clocks are not
1931 required to be set correctly by the basic TLS Protocol; higher-
1932 level or application protocols may define additional
1933 requirements.
1935 random_bytes
1936 28 bytes generated by a secure random number generator.
1938 The client hello message includes a variable-length session
1939 identifier. If not empty, the value identifies a session between the
1940 same client and server whose security parameters the client wishes to
1941 reuse. The session identifier MAY be from an earlier connection, this
1942 connection, or from another currently active connection. The second
1943 option is useful if the client only wishes to update the random
1944 structures and derived values of a connection, and the third option
1948 Dierks & Rescorla Standards Track [Page 36]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1951 makes it possible to establish several independent secure connections
1952 without repeating the full handshake protocol. These independent
1953 connections may occur sequentially or simultaneously; a SessionID
1954 becomes valid when the handshake negotiating it completes with the
1955 exchange of Finished messages and persists until it is removed due to
1956 aging or because a fatal error was encountered on a connection
1957 associated with the session. The actual contents of the SessionID are
1958 defined by the server.
1960 opaque SessionID<0..32>;
1962 Warning:
1963 Because the SessionID is transmitted without encryption or
1964 immediate MAC protection, servers MUST not place confidential
1965 information in session identifiers or let the contents of fake
1966 session identifiers cause any breach of security. (Note that the
1967 content of the handshake as a whole, including the SessionID, is
1968 protected by the Finished messages exchanged at the end of the
1969 handshake.)
1971 The CipherSuite list, passed from the client to the server in the
1972 client hello message, contains the combinations of cryptographic
1973 algorithms supported by the client in order of the client's
1974 preference (favorite choice first). Each CipherSuite defines a key
1975 exchange algorithm, a bulk encryption algorithm (including secret key
1976 length), a MAC algorithm, and a PRF. The server will select a cipher
1977 suite or, if no acceptable choices are presented, return a handshake
1978 failure alert and close the connection.
1980 uint8 CipherSuite[2]; /* Cryptographic suite selector */
1982 The client hello includes a list of compression algorithms supported
1983 by the client, ordered according to the client's preference.
1985 enum { null(0), (255) } CompressionMethod;
1987 struct {
1988 ProtocolVersion client_version;
1989 Random random;
1990 SessionID session_id;
1991 CipherSuite cipher_suites<2..2^16-1>;
1992 CompressionMethod compression_methods<1..2^8-1>;
1993 select (extensions_present) {
1994 case false:
1995 struct {};
1996 case true:
1997 Extension extensions<0..2^16-1>;
1998 }
2002 Dierks & Rescorla Standards Track [Page 37]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2005 } ClientHello;
2007 TLS allows extensions to follow the compression_methods field in an
2008 extensions block. The presence of extensions can be detected by
2009 determining whether there are bytes following the compression_methods
2010 at the end of the ClientHello. Note that this method of detecting
2011 optional data differs from the normal TLS method of having a
2012 variable-length field but is used for compatibility with TLS before
2013 extensions were defined.
2015 client_version
2016 The version of the TLS protocol by which the client wishes to
2017 communicate during this session. This SHOULD be the latest
2018 (highest valued) version supported by the client. For this
2019 version of the specification, the version will be 3.3 (See
2020 Appendix E for details about backward compatibility).
2022 random
2023 A client-generated random structure.
2025 session_id
2026 The ID of a session the client wishes to use for this connection.
2027 This field should be empty if no session_id is available, or it
2028 the client wishes to generate new security parameters.
2030 cipher_suites
2031 This is a list of the cryptographic options supported by the
2032 client, with the client's first preference first. If the
2033 session_id field is not empty (implying a session resumption
2034 request) this vector MUST include at least the cipher_suite from
2035 that session. Values are defined in Appendix A.5.
2037 compression_methods
2038 This is a list of the compression methods supported by the
2039 client, sorted by client preference. If the session_id field is
2040 not empty (implying a session resumption request) it MUST include
2041 the compression_method from that session. This vector MUST
2042 contain, and all implementations MUST support,
2043 CompressionMethod.null. Thus, a client and server will always be
2044 able to agree on a compression method.
2046 client_hello_extension_list
2047 Clients MAY request extended functionality from servers by
2048 sending data in the client_hello_extension_list. Here the new
2049 "client_hello_extension_list" field contains a list of
2050 extensions. The actual "Extension" format is defined in Section
2051 7.4.1.4.
2056 Dierks & Rescorla Standards Track [Page 38]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2059 In the event that a client requests additional functionality using
2060 extensions, and this functionality is not supplied by the server, the
2061 client MAY abort the handshake. A server that supports the
2062 extensions mechanism MUST accept only client hello messages in either
2063 the original (TLS 1.0/TLS 1.1) ClientHello or the extended
2064 ClientHello format defined in this document, and (as for all other
2065 messages) MUST check that the amount of data in the message precisely
2066 matches one of these formats; if not then it MUST send a fatal
2067 "decode_error" alert.
2069 After sending the client hello message, the client waits for a server
2070 hello message. Any other handshake message returned by the server
2071 except for a hello request is treated as a fatal error.
2074 7.4.1.3. Server Hello
2077 When this message will be sent:
2078 The server will send this message in response to a client hello
2079 message when it was able to find an acceptable set of algorithms.
2080 If it cannot find such a match, it will respond with a handshake
2081 failure alert.
2083 Structure of this message:
2084 struct {
2085 ProtocolVersion server_version;
2086 Random random;
2087 SessionID session_id;
2088 CipherSuite cipher_suite;
2089 CompressionMethod compression_method;
2090 select (extensions_present) {
2091 case false:
2092 struct {};
2093 case true:
2094 Extension extensions<0..2^16-1>;
2095 }
2096 } ServerHello;
2098 The presence of extensions can be detected by determining whether
2099 there are bytes following the compression_method field at the end of
2100 the ServerHello.
2102 server_version
2103 This field will contain the lower of that suggested by the client
2104 in the client hello and the highest supported by the server. For
2105 this version of the specification, the version is 3.2. (See
2106 Appendix E for details about backward compatibility.)
2110 Dierks & Rescorla Standards Track [Page 39]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2113 random
2114 This structure is generated by the server and MUST be
2115 independently generated from the ClientHello.random.
2117 session_id
2118 This is the identity of the session corresponding to this
2119 connection. If the ClientHello.session_id was non-empty, the
2120 server will look in its session cache for a match. If a match is
2121 found and the server is willing to establish the new connection
2122 using the specified session state, the server will respond with
2123 the same value as was supplied by the client. This indicates a
2124 resumed session and dictates that the parties must proceed
2125 directly to the finished messages. Otherwise this field will
2126 contain a different value identifying the new session. The server
2127 may return an empty session_id to indicate that the session will
2128 not be cached and therefore cannot be resumed. If a session is
2129 resumed, it must be resumed using the same cipher suite it was
2130 originally negotiated with. Note that there is no requirement
2131 that the server resume any session even if it had formerly
2132 provided a session_id. Client MUST be prepared to do a full
2133 negotiation -- including negotiating new cipher suites -- during
2134 any handshake.
2136 cipher_suite
2137 The single cipher suite selected by the server from the list in
2138 ClientHello.cipher_suites. For resumed sessions, this field is
2139 the value from the state of the session being resumed.
2141 compression_method
2142 The single compression algorithm selected by the server from the
2143 list in ClientHello.compression_methods. For resumed sessions
2144 this field is the value from the resumed session state.
2146 server_hello_extension_list
2147 A list of extensions. Note that only extensions offered by the
2148 client can appear in the server's list.
2150 7.4.1.4 Hello Extensions
2152 The extension format is:
2154 struct {
2155 ExtensionType extension_type;
2156 opaque extension_data<0..2^16-1>;
2157 } Extension;
2159 enum {
2160 cert_hash_types(TBD-BY-IANA), (65535)
2164 Dierks & Rescorla Standards Track [Page 40]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2167 } ExtensionType;
2170 Here:
2172 - "extension_type" identifies the particular extension type.
2174 - "extension_data" contains information specific to the particular
2175 extension type.
2177 The list of extension types, as defined in Section 2.3, is maintained
2178 by the Internet Assigned Numbers Authority (IANA). Thus an
2179 application needs to be made to the IANA in order to obtain a new
2180 extension type value. Since there are subtle (and not so subtle)
2181 interactions that may occur in this protocol between new features and
2182 existing features which may result in a significant reduction in
2183 overall security, new values SHALL be defined only through the IETF
2184 Consensus process specified in [IANA]. (This means that new
2185 assignments can be made only via RFCs approved by the IESG.) The
2186 initial set of extensions is defined in a companion document [TBD].
2188 The following considerations should be taken into account when
2189 designing new extensions:
2191 - Some cases where a server does not agree to an extension are
2192 error
2193 conditions, and some simply a refusal to support a particular
2194 feature. In general error alerts should be used for the former,
2195 and a field in the server extension response for the latter.
2197 - Extensions should as far as possible be designed to prevent any
2198 attack that forces use (or non-use) of a particular feature by
2199 manipulation of handshake messages. This principle should be
2200 followed regardless of whether the feature is believed to cause a
2201 security problem.
2203 Often the fact that the extension fields are included in the
2204 inputs to the Finished message hashes will be sufficient, but
2205 extreme care is needed when the extension changes the meaning of
2206 messages sent in the handshake phase. Designers and implementors
2207 should be aware of the fact that until the handshake has been
2208 authenticated, active attackers can modify messages and insert,
2209 remove, or replace extensions.
2211 - It would be technically possible to use extensions to change
2212 major aspects of the design of TLS; for example the design of
2213 cipher suite negotiation. This is not recommended; it would be
2214 more appropriate to define a new version of TLS - particularly
2218 Dierks & Rescorla Standards Track [Page 41]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2221 since the TLS handshake algorithms have specific protection
2222 against version rollback attacks based on the version number, and
2223 the possibility of version rollback should be a significant
2224 consideration in any major design change.
2226 7.4.1.4.1 Cert Hash Types
2228 The client MAY use the "cert_hash_types" to indicate to the
2229 server which hash functions may be used in the signature on the
2230 server's certificate. The "extension_data" field of this
2231 extension contains:
2233 enum{
2234 md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255)
2235 } HashType;
2237 struct {
2238 HashType types<255>;
2239 } CertHashTypes;
2241 These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384,
2242 and SHA-512 [SHA] respectively. The server MUST NOT send this
2243 extension.
2245 Clients SHOULD send this extension if they support any algorithm
2246 other than SHA-1. If this extension is not used, servers SHOULD
2247 assume that the client supports only SHA-1. Note: this is a change
2248 from TLS 1.1 where there are no explicit rules but as a practical
2249 matter one can assume that the peer supports MD5 and SHA-1.
2251 7.4.2. Server Certificate
2253 When this message will be sent:
2254 The server MUST send a certificate whenever the agreed-upon key
2255 exchange method uses certificates for authentication (this
2256 includes all key exchange methods defined in this document except
2257 DH_anon). This message will always immediately follow the server
2258 hello message.
2260 Meaning of this message:
2261 The certificate type MUST be appropriate for the selected cipher
2262 suite's key exchange algorithm, and is generally an X.509v3
2263 certificate. It MUST contain a key that matches the key exchange
2264 method, as follows. Unless otherwise specified, the signing
2265 algorithm for the certificate MUST be the same as the algorithm
2266 for the certificate key. Unless otherwise specified, the public
2267 key MAY be of any length.
2272 Dierks & Rescorla Standards Track [Page 42]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2275 Key Exchange Algorithm Certificate Key Type
2277 RSA RSA public key; the certificate MUST
2278 allow the key to be used for encryption.
2280 DHE_DSS DSS public key.
2282 DHE_RSA RSA public key that can be used for
2283 signing.
2285 DH_DSS Diffie-Hellman key. The algorithm used
2286 to sign the certificate MUST be DSS.
2288 DH_RSA Diffie-Hellman key. The algorithm used
2289 to sign the certificate MUST be RSA.
2291 All certificate profiles, and key and cryptographic formats are
2292 defined by the IETF PKIX working group [PKIX]. When a key usage
2293 extension is present, the digitalSignature bit MUST be set for the
2294 key to be eligible for signing, as described above, and the
2295 keyEncipherment bit MUST be present to allow encryption, as described
2296 above. The keyAgreement bit must be set on Diffie-Hellman
2297 certificates.
2299 As CipherSuites that specify new key exchange methods are specified
2300 for the TLS Protocol, they will imply certificate format and the
2301 required encoded keying information.
2303 Structure of this message:
2304 opaque ASN.1Cert<1..2^24-1>;
2306 struct {
2307 ASN.1Cert certificate_list<0..2^24-1>;
2308 } Certificate;
2310 certificate_list
2311 This is a sequence (chain) of X.509v3 certificates. The sender's
2312 certificate must come first in the list. Each following
2313 certificate must directly certify the one preceding it. Because
2314 certificate validation requires that root keys be distributed
2315 independently, the self-signed certificate that specifies the
2316 root certificate authority may optionally be omitted from the
2317 chain, under the assumption that the remote end must already
2318 possess it in order to validate it in any case.
2320 The same message type and structure will be used for the client's
2321 response to a certificate request message. Note that a client MAY
2322 send no certificates if it does not have an appropriate certificate
2326 Dierks & Rescorla Standards Track [Page 43]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2329 to send in response to the server's authentication request.
2331 Note: PKCS #7 [PKCS7] is not used as the format for the certificate
2332 vector because PKCS #6 [PKCS6] extended certificates are not
2333 used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making
2334 the task of parsing the list more difficult.
2336 7.4.3. Server Key Exchange Message
2338 When this message will be sent:
2339 This message will be sent immediately after the server
2340 certificate message (or the server hello message, if this is an
2341 anonymous negotiation).
2343 The server key exchange message is sent by the server only when
2344 the server certificate message (if sent) does not contain enough
2345 data to allow the client to exchange a premaster secret. This is
2346 true for the following key exchange methods:
2348 DHE_DSS
2349 DHE_RSA
2350 DH_anon
2352 It is not legal to send the server key exchange message for the
2353 following key exchange methods:
2355 RSA
2356 DH_DSS
2357 DH_RSA
2359 Meaning of this message:
2360 This message conveys cryptographic information to allow the
2361 client to communicate the premaster secret: a Diffie-Hellman
2362 public key with which the client can complete a key exchange
2363 (with the result being the premaster secret) or a public key for
2364 some other algorithm.
2366 As additional CipherSuites are defined for TLS that include new key
2367 exchange algorithms, the server key exchange message will be sent if
2368 and only if the certificate type associated with the key exchange
2369 algorithm does not provide enough information for the client to
2370 exchange a premaster secret.
2372 If the SignatureAlgorithm being used to sign the ServerKeyExchange
2373 message is DSA, the hash function used MUST be SHA-1. If the
2374 SignatureAlgorithm it must be the same hash function used in the
2375 signature of the server's certificate (found in the Certificate)
2376 message. This algorithm is denoted Hash below. Hash.length is the
2380 Dierks & Rescorla Standards Track [Page 44]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2383 length of the output of that algorithm.
2385 Structure of this message:
2386 enum { diffie_hellman } KeyExchangeAlgorithm;
2388 struct {
2389 opaque dh_p<1..2^16-1>;
2390 opaque dh_g<1..2^16-1>;
2391 opaque dh_Ys<1..2^16-1>;
2392 } ServerDHParams; /* Ephemeral DH parameters */
2394 dh_p
2395 The prime modulus used for the Diffie-Hellman operation.
2397 dh_g
2398 The generator used for the Diffie-Hellman operation.
2400 dh_Ys
2401 The server's Diffie-Hellman public value (g^X mod p).
2403 struct {
2404 select (KeyExchangeAlgorithm) {
2405 case diffie_hellman:
2406 ServerDHParams params;
2407 Signature signed_params;
2408 };
2409 } ServerKeyExchange;
2411 struct {
2412 select (KeyExchangeAlgorithm) {
2413 case diffie_hellman:
2414 ServerDHParams params;
2415 };
2416 } ServerParams;
2418 params
2419 The server's key exchange parameters.
2421 signed_params
2422 For non-anonymous key exchanges, a hash of the corresponding
2423 params value, with the signature appropriate to that hash
2424 applied.
2426 hash
2427 Hash(ClientHello.random + ServerHello.random + ServerParams)
2429 sha_hash
2430 SHA1(ClientHello.random + ServerHello.random + ServerParams)
2434 Dierks & Rescorla Standards Track [Page 45]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2437 enum { anonymous, rsa, dsa } SignatureAlgorithm;
2440 struct {
2441 select (SignatureAlgorithm) {
2442 case anonymous: struct { };
2443 case rsa:
2444 digitally-signed struct {
2445 opaque hash[Hash.length];
2446 };
2447 case dsa:
2448 digitally-signed struct {
2449 opaque sha_hash[20];
2450 };
2451 };
2452 };
2453 } Signature;
2455 7.4.4. Certificate Request
2457 When this message will be sent:
2458 A non-anonymous server can optionally request a certificate from
2459 the client, if appropriate for the selected cipher suite. This
2460 message, if sent, will immediately follow the Server Key Exchange
2461 message (if it is sent; otherwise, the Server Certificate
2462 message).
2464 Structure of this message:
2465 enum {
2466 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
2467 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
2468 fortezza_dms_RESERVED(20),
2469 (255)
2470 } ClientCertificateType;
2473 opaque DistinguishedName<1..2^16-1>;
2475 struct {
2476 ClientCertificateType certificate_types<1..2^8-1>;
2477 HashType certificate_hash<1..2^8-1>;
2478 DistinguishedName certificate_authorities<0..2^16-1>;
2479 } CertificateRequest;
2481 certificate_types
2482 This field is a list of the types of certificates requested,
2483 sorted in order of the server's preference.
2488 Dierks & Rescorla Standards Track [Page 46]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2491 certificate_types
2492 A list of the types of certificate types which the client may
2493 offer.
2494 rsa_sign a certificate containing an RSA key
2495 dss_sign a certificate containing a DSS key
2496 rsa_fixed_dh a certificate signed with RSA and containing
2497 a static DH key.
2498 dss_fixed_dh a certificate signed with DSS and containing
2499 a static DH key
2501 Certificate types rsa_sign and dss_sign SHOULD contain
2502 certificates signed with the same algorithm. However, this is
2503 not required. This is a holdover from TLS 1.0 and 1.1.
2506 certificate_hash
2507 A list of acceptable hash algorithms to be used in
2508 certificate signatures.
2510 certificate_authorities
2511 A list of the distinguished names of acceptable certificate
2512 authorities. These distinguished names may specify a desired
2513 distinguished name for a root CA or for a subordinate CA;
2514 thus, this message can be used both to describe known roots
2515 and a desired authorization space. If the
2516 certificate_authorities list is empty then the client MAY
2517 send any certificate of the appropriate
2518 ClientCertificateType, unless there is some external
2519 arrangement to the contrary.
2521 New ClientCertificateType values are assigned by IANA as described in
2522 Section 11.
2524 Note: Values listed as RESERVED may not be used. They were
2525 used in SSLv3.
2528 Note: DistinguishedName is derived from [X501]. DistinguishedNames are
2529 represented in DER-encoded format.
2531 Note: It is a fatal handshake_failure alert for an anonymous server to
2532 request client authentication.
2534 7.4.5 Server hello done
2536 When this message will be sent:
2537 The server hello done message is sent by the server to indicate
2538 the end of the server hello and associated messages. After
2542 Dierks & Rescorla Standards Track [Page 47]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2545 sending this message, the server will wait for a client response.
2547 Meaning of this message:
2548 This message means that the server is done sending messages to
2549 support the key exchange, and the client can proceed with its
2550 phase of the key exchange.
2552 Upon receipt of the server hello done message, the client SHOULD
2553 verify that the server provided a valid certificate, if required
2554 and check that the server hello parameters are acceptable.
2556 Structure of this message:
2557 struct { } ServerHelloDone;
2559 7.4.6. Client Certificate
2561 When this message will be sent:
2562 This is the first message the client can send after receiving a
2563 server hello done message. This message is only sent if the
2564 server requests a certificate. If no suitable certificate is
2565 available, the client SHOULD send a certificate message
2566 containing no certificates. That is, the certificate_list
2567 structure has a length of zero. If client authentication is
2568 required by the server for the handshake to continue, it may
2569 respond with a fatal handshake failure alert. Client certificates
2570 are sent using the Certificate structure defined in Section
2571 7.4.2.
2574 Note: When using a static Diffie-Hellman based key exchange method
2575 (DH_DSS or DH_RSA), if client authentication is requested, the
2576 Diffie-Hellman group and generator encoded in the client's
2577 certificate MUST match the server specified Diffie-Hellman
2578 parameters if the client's parameters are to be used for the key
2579 exchange.
2581 7.4.7. Client Key Exchange Message
2583 When this message will be sent:
2584 This message is always sent by the client. It MUST immediately
2585 follow the client certificate message, if it is sent. Otherwise
2586 it MUST be the first message sent by the client after it receives
2587 the server hello done message.
2589 Meaning of this message:
2590 With this message, the premaster secret is set, either though
2591 direct transmission of the RSA-encrypted secret, or by the
2592 transmission of Diffie-Hellman parameters that will allow each
2596 Dierks & Rescorla Standards Track [Page 48]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2599 side to agree upon the same premaster secret. When the key
2600 exchange method is DH_RSA or DH_DSS, client certification has
2601 been requested, and the client was able to respond with a
2602 certificate that contained a Diffie-Hellman public key whose
2603 parameters (group and generator) matched those specified by the
2604 server in its certificate, this message MUST not contain any
2605 data.
2607 Structure of this message:
2608 The choice of messages depends on which key exchange method has
2609 been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
2610 definition.
2612 struct {
2613 select (KeyExchangeAlgorithm) {
2614 case rsa: EncryptedPreMasterSecret;
2615 case diffie_hellman: ClientDiffieHellmanPublic;
2616 } exchange_keys;
2617 } ClientKeyExchange;
2619 7.4.7.1. RSA Encrypted Premaster Secret Message
2621 Meaning of this message:
2622 If RSA is being used for key agreement and authentication, the
2623 client generates a 48-byte premaster secret, encrypts it using
2624 the public key from the server's certificate and sends the result
2625 in an encrypted premaster secret message. This structure is a
2626 variant of the client key exchange message and is not a message
2627 in itself.
2629 Structure of this message:
2630 struct {
2631 ProtocolVersion client_version;
2632 opaque random[46];
2633 } PreMasterSecret;
2635 client_version
2636 The latest (newest) version supported by the client. This is
2637 used to detect version roll-back attacks. Upon receiving the
2638 premaster secret, the server SHOULD check that this value
2639 matches the value transmitted by the client in the client
2640 hello message.
2642 random
2643 46 securely-generated random bytes.
2645 struct {
2646 public-key-encrypted PreMasterSecret pre_master_secret;
2650 Dierks & Rescorla Standards Track [Page 49]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2653 } EncryptedPreMasterSecret;
2655 pre_master_secret
2656 This random value is generated by the client and is used to
2657 generate the master secret, as specified in Section 8.1.
2659 An attack discovered by Daniel Bleichenbacher [BLEI] can be used to
2660 attack a TLS server which is using PKCS#1 v 1.5 encoded RSA. The
2661 attack takes advantage of the fact that by failing in different ways,
2662 a TLS server can be coerced into revealing whether a particular
2663 message, when decrypted, is properly PKCS#1 v1.5 formatted or not.
2665 In order to avoid this vulnerability, implementations MUST treat
2666 incorrectly formatted messages in a manner indistinguishable from
2667 correctly formatted RSA blocks. Thus, when it receives an incorrectly
2668 formatted RSA block, a server should generate a random 48-byte value
2669 and proceed using it as the premaster secret. Thus, the server will
2670 act identically whether the received RSA block is correctly encoded
2671 or not.
2673 [PKCS1B] defines a newer version of PKCS#1 encoding that is more
2674 secure against the Bleichenbacher attack. However, for maximal
2675 compatibility with TLS 1.0, TLS 1.1 retains the original encoding. No
2676 variants of the Bleichenbacher attack are known to exist provided
2677 that the above recommendations are followed.
2679 Implementation Note: Public-key-encrypted data is represented as an
2680 opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
2681 PreMasterSecret in a ClientKeyExchange is preceded by two length
2682 bytes. These bytes are redundant in the case of RSA because the
2683 EncryptedPreMasterSecret is the only data in the ClientKeyExchange
2684 and its length can therefore be unambiguously determined. The SSLv3
2685 specification was not clear about the encoding of public-key-
2686 encrypted data, and therefore many SSLv3 implementations do not
2687 include the the length bytes, encoding the RSA encrypted data
2688 directly in the ClientKeyExchange message.
2690 This specification requires correct encoding of the
2691 EncryptedPreMasterSecret complete with length bytes. The resulting
2692 PDU is incompatible with many SSLv3 implementations. Implementors
2693 upgrading from SSLv3 MUST modify their implementations to generate
2694 and accept the correct encoding. Implementors who wish to be
2695 compatible with both SSLv3 and TLS should make their implementation's
2696 behavior dependent on the protocol version.
2698 Implementation Note: It is now known that remote timing-based attacks
2699 on SSL are possible, at least when the client and server are on the
2700 same LAN. Accordingly, implementations that use static RSA keys MUST
2704 Dierks & Rescorla Standards Track [Page 50]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2707 use RSA blinding or some other anti-timing technique, as described in
2708 [TIMING].
2710 Note: The version number in the PreMasterSecret MUST be the version
2711 offered by the client in the ClientHello.version, not the version
2712 negotiated for the connection. This feature is designed to prevent
2713 rollback attacks. Unfortunately, many implementations use the
2714 negotiated version instead and therefore checking the version number
2715 may lead to failure to interoperate with such incorrect client
2716 implementations. Client implementations MUST and Server
2717 implementations MAY check the version number. In practice, since the
2718 TLS handshake MACs prevent downgrade and no good attacks are known on
2719 those MACs, ambiguity is not considered a serious security risk.
2720 Note that if servers choose to to check the version number, they MUST
2721 randomize the PreMasterSecret in case of error, rather than generate
2722 an alert, in order to avoid variants on the Bleichenbacher attack.
2723 [KPR03]
2725 7.4.7.1. Client Diffie-Hellman Public Value
2727 Meaning of this message:
2728 This structure conveys the client's Diffie-Hellman public value
2729 (Yc) if it was not already included in the client's certificate.
2730 The encoding used for Yc is determined by the enumerated
2731 PublicValueEncoding. This structure is a variant of the client
2732 key exchange message, and not a message in itself.
2734 Structure of this message:
2735 enum { implicit, explicit } PublicValueEncoding;
2737 implicit
2738 If the client certificate already contains a suitable Diffie-
2739 Hellman key, then Yc is implicit and does not need to be sent
2740 again. In this case, the client key exchange message will be
2741 sent, but it MUST be empty.
2743 explicit
2744 Yc needs to be sent.
2746 struct {
2747 select (PublicValueEncoding) {
2748 case implicit: struct { };
2749 case explicit: opaque dh_Yc<1..2^16-1>;
2750 } dh_public;
2751 } ClientDiffieHellmanPublic;
2753 dh_Yc
2754 The client's Diffie-Hellman public value (Yc).
2758 Dierks & Rescorla Standards Track [Page 51]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2761 7.4.8. Certificate verify
2763 When this message will be sent:
2764 This message is used to provide explicit verification of a client
2765 certificate. This message is only sent following a client
2766 certificate that has signing capability (i.e. all certificates
2767 except those containing fixed Diffie-Hellman parameters). When
2768 sent, it MUST immediately follow the client key exchange message.
2770 Structure of this message:
2771 struct {
2772 Signature signature;
2773 } CertificateVerify;
2775 The Signature type is defined in 7.4.3. If the SignatureAlgorithm
2776 is DSA, then the sha_hash value must be used. If it is RSA,
2777 the same function (denoted Hash) must be used as was used to
2778 create the signature for the client's certificate.
2780 CertificateVerify.signature.hash
2781 Hash(handshake_messages);
2783 CertificateVerify.signature.sha_hash
2784 SHA(handshake_messages);
2786 Here handshake_messages refers to all handshake messages sent or
2787 received starting at client hello up to but not including this
2788 message, including the type and length fields of the handshake
2789 messages. This is the concatenation of all the Handshake structures
2790 as defined in 7.4 exchanged thus far.
2792 7.4.9. Finished
2794 When this message will be sent:
2795 A finished message is always sent immediately after a change
2796 cipher spec message to verify that the key exchange and
2797 authentication processes were successful. It is essential that a
2798 change cipher spec message be received between the other
2799 handshake messages and the Finished message.
2801 Meaning of this message:
2802 The finished message is the first protected with the just-
2803 negotiated algorithms, keys, and secrets. Recipients of finished
2804 messages MUST verify that the contents are correct. Once a side
2805 has sent its Finished message and received and validated the
2806 Finished message from its peer, it may begin to send and receive
2807 application data over the connection.
2812 Dierks & Rescorla Standards Track [Page 52]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2815 struct {
2816 opaque verify_data[12];
2817 } Finished;
2819 verify_data
2820 PRF(master_secret, finished_label, Hash(handshake_messages))[0..11];
2822 finished_label
2823 For Finished messages sent by the client, the string "client
2824 finished". For Finished messages sent by the server, the
2825 string "server finished".
2827 Hash denotes the negotiated hash used for the PRF. If a new
2828 PRF is defined, then this hash MUST be specified.
2830 handshake_messages
2831 All of the data from all messages in this handshake (not
2832 including any HelloRequest messages) up to but not including
2833 this message. This is only data visible at the handshake
2834 layer and does not include record layer headers. This is the
2835 concatenation of all the Handshake structures as defined in
2836 7.4, exchanged thus far.
2838 It is a fatal error if a finished message is not preceded by a change
2839 cipher spec message at the appropriate point in the handshake.
2841 The value handshake_messages includes all handshake messages starting
2842 at client hello up to, but not including, this finished message. This
2843 may be different from handshake_messages in Section 7.4.9 because it
2844 would include the certificate verify message (if sent). Also, the
2845 handshake_messages for the finished message sent by the client will
2846 be different from that for the finished message sent by the server,
2847 because the one that is sent second will include the prior one.
2849 Note: Change cipher spec messages, alerts and, any other record types
2850 are not handshake messages and are not included in the hash
2851 computations. Also, Hello Request messages are omitted from
2852 handshake hashes.
2854 8. Cryptographic Computations
2856 In order to begin connection protection, the TLS Record Protocol
2857 requires specification of a suite of algorithms, a master secret, and
2858 the client and server random values. The authentication, encryption,
2859 and MAC algorithms are determined by the cipher_suite selected by the
2860 server and revealed in the server hello message. The compression
2861 algorithm is negotiated in the hello messages, and the random values
2862 are exchanged in the hello messages. All that remains is to calculate
2866 Dierks & Rescorla Standards Track [Page 53]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2869 the master secret.
2871 8.1. Computing the Master Secret
2873 For all key exchange methods, the same algorithm is used to convert
2874 the pre_master_secret into the master_secret. The pre_master_secret
2875 should be deleted from memory once the master_secret has been
2876 computed.
2878 master_secret = PRF(pre_master_secret, "master secret",
2879 ClientHello.random + ServerHello.random)
2880 [0..47];
2882 The master secret is always exactly 48 bytes in length. The length of
2883 the premaster secret will vary depending on key exchange method.
2885 8.1.1. RSA
2887 When RSA is used for server authentication and key exchange, a
2888 48-byte pre_master_secret is generated by the client, encrypted under
2889 the server's public key, and sent to the server. The server uses its
2890 private key to decrypt the pre_master_secret. Both parties then
2891 convert the pre_master_secret into the master_secret, as specified
2892 above.
2894 8.1.2. Diffie-Hellman
2896 A conventional Diffie-Hellman computation is performed. The
2897 negotiated key (Z) is used as the pre_master_secret, and is converted
2898 into the master_secret, as specified above. Leading bytes of Z that
2899 contain all zero bits are stripped before it is used as the
2900 pre_master_secret.
2902 Note: Diffie-Hellman parameters are specified by the server and may
2903 be either ephemeral or contained within the server's certificate.
2905 9. Mandatory Cipher Suites
2907 In the absence of an application profile standard specifying
2908 otherwise, a TLS compliant application MUST implement the cipher
2909 suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
2911 10. Application Data Protocol
2913 Application data messages are carried by the Record Layer and are
2914 fragmented, compressed and encrypted based on the current connection
2915 state. The messages are treated as transparent data to the record
2916 layer.
2920 Dierks & Rescorla Standards Track [Page 54]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2923 11. Security Considerations
2925 Security issues are discussed throughoutthis memo, especially in
2926 Appendices D, E, and F.
2928 12. IANA Considerations
2930 This document uses several registries that were originally created in
2931 [RFC4346]. IANA is requested to update (has updated) these to
2932 reference this document. The registries and their allocation policies
2933 (unchanged from [RFC4346]) are listed below.
2935 o TLS ClientCertificateType Identifiers Registry: Future
2936 values in the range 0-63 (decimal) inclusive are assigned via
2937 Standards Action [RFC2434]. Values in the range 64-223
2938 (decimal) inclusive are assigned Specification Required
2939 [RFC2434]. Values from 224-255 (decimal) inclusive are
2940 reserved for Private Use [RFC2434].
2942 o TLS Cipher Suite Registry: Future values with the first byte
2943 in the range 0-191 (decimal) inclusive are assigned via
2944 Standards Action [RFC2434]. Values with the first byte in
2945 the range 192-254 (decimal) are assigned via Specification
2946 Required [RFC2434]. Values with the first byte 255 (decimal)
2947 are reserved for Private Use [RFC2434].
2949 o TLS ContentType Registry: Future values are allocated via
2950 Standards Action [RFC2434].
2952 o TLS Alert Registry: Future values are allocated via
2953 Standards Action [RFC2434].
2955 o TLS HandshakeType Registry: Future values are allocated via
2956 Standards Action [RFC2434].
2958 This document also uses a registry originally created in [RFC4366].
2959 IANA is requested to update (has updated) it to reference this
2960 document. The registry and its allocation policy (unchanged from
2961 [RFC4366]) is listed below:.
2963 o TLS ExtensionType Registry: Future values are allocated
2964 via IETF Consensus [RFC2434]
2966 In addition, this document defines one new registry to be maintained
2967 by IANA:
2969 o TLS HashType Registry: The registry will be initially
2970 populated with the values described in Section 7.4.1.4.7.
2974 Dierks & Rescorla Standards Track [Page 55]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
2977 Future values in the range 0-63 (decimal) inclusive are
2978 assigned via Standards Action [RFC2434]. Values in the
2979 range 64-223 (decimal) inclusive are assigned via
2980 Specification Required [RFC2434]. Values from 224-255
2981 (decimal) inclusive are reserved for Private Use [RFC2434].
2983 This document defines one new TLS extension, cert_hash_type, which is
2984 to be (has been) allocated value TBD-BY-IANA in the TLS ExtensionType
2985 registry.
2988 12.1 Extensions
2990 Section 11 describes a registry of ExtensionType values to be
2991 maintained by the IANA. ExtensionType values are to be assigned via
2992 IETF Consensus as defined in RFC 2434 [IANA]. The initial registry
2993 corresponds to the definition of "ExtensionType" in Section 2.3.
2995 The MIME type "application/pkix-pkipath" has been registered by the
2996 IANA with the following template:
2998 To: ietf-types@iana.org Subject: Registration of MIME media type
2999 application/pkix-pkipath
3001 MIME media type name: application
3002 MIME subtype name: pkix-pkipath
3004 Optional parameters: version (default value is "1")
3006 Encoding considerations:
3007 This MIME type is a DER encoding of the ASN.1 type PkiPath,
3008 defined as follows:
3009 PkiPath ::= SEQUENCE OF Certificate
3010 PkiPath is used to represent a certification path. Within the
3011 sequence, the order of certificates is such that the subject of
3012 the first certificate is the issuer of the second certificate,
3013 etc.
3015 This is identical to the definition published in [X509-4th-TC1];
3016 note that it is different from that in [X509-4th].
3018 All Certificates MUST conform to [PKIX]. (This should be
3019 interpreted as a requirement to encode only PKIX-conformant
3020 certificates using this type. It does not necessarily require
3021 that all certificates that are not strictly PKIX-conformant must
3022 be rejected by relying parties, although the security consequences
3023 of accepting any such certificates should be considered
3024 carefully.)
3028 Dierks & Rescorla Standards Track [Page 56]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3031 DER (as opposed to BER) encoding MUST be used. If this type is
3032 sent over a 7-bit transport, base64 encoding SHOULD be used.
3034 Security considerations:
3035 The security considerations of [X509-4th] and [PKIX] (or any
3036 updates to them) apply, as well as those of any protocol that uses
3037 this type (e.g., TLS).
3039 Note that this type only specifies a certificate chain that can be
3040 assessed for validity according to the relying party's existing
3041 configuration of trusted CAs; it is not intended to be used to
3042 specify any change to that configuration.
3044 Interoperability considerations:
3045 No specific interoperability problems are known with this type,
3046 but for recommendations relating to X.509 certificates in general,
3047 see [PKIX].
3049 Published specification: this memo, and [PKIX].
3051 Applications which use this media type: TLS. It may also be used by
3052 other protocols, or for general interchange of PKIX certificate
3054 Additional information:
3055 Magic number(s): DER-encoded ASN.1 can be easily recognized.
3056 Further parsing is required to distinguish from other ASN.1
3057 types.
3058 File extension(s): .pkipath
3059 Macintosh File Type Code(s): not specified
3061 Person & email address to contact for further information:
3062 Magnus Nystrom <magnus@rsasecurity.com>
3064 Intended usage: COMMON
3066 Change controller:
3067 IESG <iesg@ietf.org>
3082 Dierks & Rescorla Standards Track [Page 57]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3085 Appendix A. Protocol Constant Values
3087 This section describes protocol types and constants.
3089 A.1. Record Layer
3091 struct {
3092 uint8 major, minor;
3093 } ProtocolVersion;
3095 ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
3097 enum {
3098 change_cipher_spec(20), alert(21), handshake(22),
3099 application_data(23), (255)
3100 } ContentType;
3102 struct {
3103 ContentType type;
3104 ProtocolVersion version;
3105 uint16 length;
3106 opaque fragment[TLSPlaintext.length];
3107 } TLSPlaintext;
3109 struct {
3110 ContentType type;
3111 ProtocolVersion version;
3112 uint16 length;
3113 opaque fragment[TLSCompressed.length];
3114 } TLSCompressed;
3116 struct {
3117 ContentType type;
3118 ProtocolVersion version;
3119 uint16 length;
3120 select (SecurityParameters.cipher_type) {
3121 case stream: GenericStreamCipher;
3122 case block: GenericBlockCipher;
3123 case aead: GenericAEADCipher;
3124 } fragment;
3125 } TLSCiphertext;
3127 stream-ciphered struct {
3128 opaque content[TLSCompressed.length];
3129 opaque MAC[SecurityParameters.mac_length];
3130 } GenericStreamCipher;
3132 block-ciphered struct {
3136 Dierks & Rescorla Standards Track [Page 58]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3139 opaque IV[SecurityParameters.block_length];
3140 opaque content[TLSCompressed.length];
3141 opaque MAC[SecurityParameters.mac_length];
3142 uint8 padding[GenericBlockCipher.padding_length];
3143 uint8 padding_length;
3144 } GenericBlockCipher;
3146 aead-ciphered struct {
3147 opaque IV[SecurityParameters.iv_length];
3148 opaque aead_output[AEADEncrypted.length];
3149 } GenericAEADCipher;
3151 A.2. Change Cipher Specs Message
3153 struct {
3154 enum { change_cipher_spec(1), (255) } type;
3155 } ChangeCipherSpec;
3157 A.3. Alert Messages
3159 enum { warning(1), fatal(2), (255) } AlertLevel;
3161 enum {
3162 close_notify(0),
3163 unexpected_message(10),
3164 bad_record_mac(20),
3165 decryption_failed(21),
3166 record_overflow(22),
3167 decompression_failure(30),
3168 handshake_failure(40),
3169 no_certificate_RESERVED (41),
3170 bad_certificate(42),
3171 unsupported_certificate(43),
3172 certificate_revoked(44),
3173 certificate_expired(45),
3174 certificate_unknown(46),
3175 illegal_parameter(47),
3176 unknown_ca(48),
3177 access_denied(49),
3178 decode_error(50),
3179 decrypt_error(51),
3180 export_restriction_RESERVED(60),
3181 protocol_version(70),
3182 insufficient_security(71),
3183 internal_error(80),
3184 user_canceled(90),
3185 no_renegotiation(100),
3186 unsupported_extension(110), /* new */
3190 Dierks & Rescorla Standards Track [Page 59]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3193 (255)
3194 } AlertDescription;
3196 struct {
3197 AlertLevel level;
3198 AlertDescription description;
3199 } Alert;
3244 Dierks & Rescorla Standards Track [Page 60]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3247 A.4. Handshake Protocol
3249 enum {
3250 hello_request(0), client_hello(1), server_hello(2),
3251 certificate(11), server_key_exchange (12),
3252 certificate_request(13), server_hello_done(14),
3253 certificate_verify(15), client_key_exchange(16),
3254 finished(20)
3255 (255)
3256 } HandshakeType;
3258 struct {
3259 HandshakeType msg_type;
3260 uint24 length;
3261 select (HandshakeType) {
3262 case hello_request: HelloRequest;
3263 case client_hello: ClientHello;
3264 case server_hello: ServerHello;
3265 case certificate: Certificate;
3266 case server_key_exchange: ServerKeyExchange;
3267 case certificate_request: CertificateRequest;
3268 case server_hello_done: ServerHelloDone;
3269 case certificate_verify: CertificateVerify;
3270 case client_key_exchange: ClientKeyExchange;
3271 case finished: Finished;
3272 } body;
3273 } Handshake;
3275 A.4.1. Hello Messages
3277 struct { } HelloRequest;
3279 struct {
3280 uint32 gmt_unix_time;
3281 opaque random_bytes[28];
3282 } Random;
3284 opaque SessionID<0..32>;
3286 uint8 CipherSuite[2];
3288 enum { null(0), (255) } CompressionMethod;
3290 struct {
3291 ProtocolVersion client_version;
3292 Random random;
3293 SessionID session_id;
3294 CipherSuite cipher_suites<2..2^16-1>;
3298 Dierks & Rescorla Standards Track [Page 61]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3301 CompressionMethod compression_methods<1..2^8-1>;
3302 Extension client_hello_extension_list<0..2^16-1>;
3303 } ClientHello;
3305 struct {
3306 ProtocolVersion server_version;
3307 Random random;
3308 SessionID session_id;
3309 CipherSuite cipher_suite;
3310 CompressionMethod compression_method;
3311 } ServerHello;
3313 struct {
3314 ExtensionType extension_type;
3315 opaque extension_data<0..2^16-1>;
3316 } Extension;
3318 enum {
3319 cert_hash_types(TBD-BY-IANA), (65535)
3320 } ExtensionType;
3322 A.4.2. Server Authentication and Key Exchange Messages
3324 opaque ASN.1Cert<2^24-1>;
3326 struct {
3327 ASN.1Cert certificate_list<0..2^24-1>;
3328 } Certificate;
3330 struct {
3331 CertificateStatusType status_type;
3332 select (status_type) {
3333 case ocsp: OCSPResponse;
3334 } response;
3335 } CertificateStatus;
3337 opaque OCSPResponse<1..2^24-1>;
3339 enum { diffie_hellman } KeyExchangeAlgorithm;
3341 struct {
3342 opaque dh_p<1..2^16-1>;
3343 opaque dh_g<1..2^16-1>;
3344 opaque dh_Ys<1..2^16-1>;
3345 } ServerDHParams;
3347 struct {
3348 select (KeyExchangeAlgorithm) {
3352 Dierks & Rescorla Standards Track [Page 62]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3355 case diffie_hellman:
3356 ServerDHParams params;
3357 Signature signed_params;
3358 } ServerKeyExchange;
3360 enum { anonymous, rsa, dsa } SignatureAlgorithm;
3362 struct {
3363 select (KeyExchangeAlgorithm) {
3364 case diffie_hellman:
3365 ServerDHParams params;
3366 };
3367 } ServerParams;
3369 struct {
3370 select (SignatureAlgorithm) {
3371 case anonymous: struct { };
3372 case rsa:
3373 digitally-signed struct {
3374 opaque hash[Hash.length];
3375 };
3376 case dsa:
3377 digitally-signed struct {
3378 opaque sha_hash[20];
3379 };
3380 };
3381 };
3382 } Signature;
3384 enum {
3385 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
3386 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
3387 fortezza_dms_RESERVED(20),
3388 (255)
3389 } ClientCertificateType;
3391 opaque DistinguishedName<1..2^16-1>;
3393 struct {
3394 ClientCertificateType certificate_types<1..2^8-1>;
3395 DistinguishedName certificate_authorities<0..2^16-1>;
3396 } CertificateRequest;
3398 struct { } ServerHelloDone;
3400 A.4.3. Client Authentication and Key Exchange Messages
3402 struct {
3406 Dierks & Rescorla Standards Track [Page 63]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3409 select (KeyExchangeAlgorithm) {
3410 case rsa: EncryptedPreMasterSecret;
3411 case diffie_hellman: ClientDiffieHellmanPublic;
3412 } exchange_keys;
3413 } ClientKeyExchange;
3415 struct {
3416 ProtocolVersion client_version;
3417 opaque random[46];
3418 } PreMasterSecret;
3420 struct {
3421 public-key-encrypted PreMasterSecret pre_master_secret;
3422 } EncryptedPreMasterSecret;
3424 enum { implicit, explicit } PublicValueEncoding;
3426 struct {
3427 select (PublicValueEncoding) {
3428 case implicit: struct {};
3429 case explicit: opaque DH_Yc<1..2^16-1>;
3430 } dh_public;
3431 } ClientDiffieHellmanPublic;
3433 struct {
3434 Signature signature;
3435 } CertificateVerify;
3437 A.4.4. Handshake Finalization Message
3439 struct {
3440 opaque verify_data[12];
3441 } Finished;
3443 A.5. The CipherSuite
3445 The following values define the CipherSuite codes used in the client
3446 hello and server hello messages.
3448 A CipherSuite defines a cipher specification supported in TLS Version
3449 1.1.
3451 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
3452 TLS connection during the first handshake on that channel, but MUST
3453 not be negotiated, as it provides no more protection than an
3454 unsecured connection.
3456 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
3460 Dierks & Rescorla Standards Track [Page 64]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3463 The following CipherSuite definitions require that the server provide
3464 an RSA certificate that can be used for key exchange. The server may
3465 request either an RSA or a DSS signature-capable certificate in the
3466 certificate request message.
3468 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
3469 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
3470 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
3471 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
3472 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
3473 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
3474 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
3475 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F };
3476 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 };
3478 The following CipherSuite definitions are used for server-
3479 authenticated (and optionally client-authenticated) Diffie-Hellman.
3480 DH denotes cipher suites in which the server's certificate contains
3481 the Diffie-Hellman parameters signed by the certificate authority
3482 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
3483 parameters are signed by a DSS or RSA certificate, which has been
3484 signed by the CA. The signing algorithm used is specified after the
3485 DH or DHE parameter. The server can request an RSA or DSS signature-
3486 capable certificate from the client for client authentication or it
3487 may request a Diffie-Hellman certificate. Any Diffie-Hellman
3488 certificate provided by the client must use the parameters (group and
3489 generator) described by the server.
3491 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
3492 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
3493 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
3494 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
3495 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
3496 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
3497 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
3498 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
3499 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 };
3500 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 };
3501 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 };
3502 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 };
3503 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 };
3504 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 };
3505 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 };
3506 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 };
3508 The following cipher suites are used for completely anonymous Diffie-
3509 Hellman communications in which neither party is authenticated. Note
3510 that this mode is vulnerable to man-in-the-middle attacks. Using
3514 Dierks & Rescorla Standards Track [Page 65]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3517 this mode therefore is of limited use: These ciphersuites MUST NOT be
3518 used by TLS 1.2 implementations unless the application layer has
3519 specifically requested to allow anonymous key exchange. (Anonymous
3520 key exchange may sometimes be acceptable, for example, to support
3521 opportunistic encryption when no set-up for authentication is in
3522 place, or when TLS is used as part of more complex security protocols
3523 that have other means to ensure authentication.)
3525 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00, 0x18 };
3526 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00, 0x1A };
3527 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x1B };
3528 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 };
3529 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A };
3531 Note that using non-anonymous key exchange without actually verifying
3532 the key exchange is essentially equivalent to anonymous key exchange,
3533 and the same precautions apply. While non-anonymous key exchange
3534 will generally involve a higher computational and communicational
3535 cost than anonymous key exchange, it may be in the interest of
3536 interoperability not to disable non-anonymous key exchange when the
3537 application layer is allowing anonymous key exchange.
3539 When SSLv3 and TLS 1.0 were designed, the United States restricted
3540 the export of cryptographic software containing certain strong
3541 encryption algorithms. A series of cipher suites were designed to
3542 operate at reduced key lengths in order to comply with those
3543 regulations. Due to advances in computer performance, these
3544 algorithms are now unacceptably weak and export restrictions have
3545 since been loosened. TLS 1.2 implementations MUST NOT negotiate these
3546 cipher suites in TLS 1.2 mode. However, for backward compatibility
3547 they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
3548 only servers. TLS 1.2 clients MUST check that the server did not
3549 choose one of these cipher suites during the handshake. These
3550 ciphersuites are listed below for informational purposes and to
3551 reserve the numbers.
3553 CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
3554 CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
3555 CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
3556 CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
3557 CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
3558 CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
3559 CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
3560 CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
3561 CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
3563 The following cipher suites were defined in [TLSKRB] and are included
3564 here for completeness. See [TLSKRB] for details:
3568 Dierks & Rescorla Standards Track [Page 66]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3571 CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E };
3572 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
3573 CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
3574 CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
3575 CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
3576 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
3577 CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
3578 CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
3580 The following exportable cipher suites were defined in [TLSKRB] and
3581 are included here for completeness. TLS 1.2 implementations MUST NOT
3582 negotiate these cipher suites.
3584 CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26
3585 };
3586 CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27
3587 };
3588 CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28
3589 };
3590 CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29
3591 };
3592 CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A
3593 };
3594 CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B
3595 };
3598 New cipher suite values are assigned by IANA as described in Section
3599 11.
3601 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
3602 reserved to avoid collision with Fortezza-based cipher suites in SSL
3603 3.
3605 A.6. The Security Parameters
3607 These security parameters are determined by the TLS Handshake
3608 Protocol and provided as parameters to the TLS Record Layer in order
3609 to initialize a connection state. SecurityParameters includes:
3611 enum { null(0), (255) } CompressionMethod;
3613 enum { server, client } ConnectionEnd;
3615 enum { null, rc4, rc2, des, 3des, des40, aes, idea }
3616 BulkCipherAlgorithm;
3618 enum { stream, block } CipherType;
3622 Dierks & Rescorla Standards Track [Page 67]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3625 enum { null, md5, sha } MACAlgorithm;
3627 /* The algorithms specified in CompressionMethod,
3628 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
3630 struct {
3631 ConnectionEnd entity;
3632 BulkCipherAlgorithm bulk_cipher_algorithm;
3633 CipherType cipher_type;
3634 uint8 enc_key_length;
3635 uint8 block_length;
3636 uint8 iv_length;
3637 MACAlgorithm mac_algorithm;
3638 uint8 mac_length;
3639 uint8 mac_key_length;
3640 CompressionMethod compression_algorithm;
3641 opaque master_secret[48];
3642 opaque client_random[32];
3643 opaque server_random[32];
3644 } SecurityParameters;
3676 Dierks & Rescorla Standards Track [Page 68]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3679 Appendix B. Glossary
3681 Advanced Encryption Standard (AES)
3682 AES is a widely used symmetric encryption algorithm. AES is a
3683 block cipher with a 128, 192, or 256 bit keys and a 16 byte block
3684 size. [AES] TLS currently only supports the 128 and 256 bit key
3685 sizes.
3687 application protocol
3688 An application protocol is a protocol that normally layers
3689 directly on top of the transport layer (e.g., TCP/IP). Examples
3690 include HTTP, TELNET, FTP, and SMTP.
3692 asymmetric cipher
3693 See public key cryptography.
3695 authenticated encryption with additional data (AEAD)
3696 A symmetric encryption algorithm that simultaneously provides
3697 confidentiality and message integrity.
3699 authentication
3700 Authentication is the ability of one entity to determine the
3701 identity of another entity.
3703 block cipher
3704 A block cipher is an algorithm that operates on plaintext in
3705 groups of bits, called blocks. 64 bits is a common block size.
3707 bulk cipher
3708 A symmetric encryption algorithm used to encrypt large quantities
3709 of data.
3711 cipher block chaining (CBC)
3712 CBC is a mode in which every plaintext block encrypted with a
3713 block cipher is first exclusive-ORed with the previous ciphertext
3714 block (or, in the case of the first block, with the
3715 initialization vector). For decryption, every block is first
3716 decrypted, then exclusive-ORed with the previous ciphertext block
3717 (or IV).
3719 certificate
3720 As part of the X.509 protocol (a.k.a. ISO Authentication
3721 framework), certificates are assigned by a trusted Certificate
3722 Authority and provide a strong binding between a party's identity
3723 or some other attributes and its public key.
3725 client
3726 The application entity that initiates a TLS connection to a
3730 Dierks & Rescorla Standards Track [Page 69]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3733 server. This may or may not imply that the client initiated the
3734 underlying transport connection. The primary operational
3735 difference between the server and client is that the server is
3736 generally authenticated, while the client is only optionally
3737 authenticated.
3739 client write key
3740 The key used to encrypt data written by the client.
3742 client write MAC secret
3743 The secret data used to authenticate data written by the client.
3745 connection
3746 A connection is a transport (in the OSI layering model
3747 definition) that provides a suitable type of service. For TLS,
3748 such connections are peer-to-peer relationships. The connections
3749 are transient. Every connection is associated with one session.
3751 Data Encryption Standard
3752 DES is a very widely used symmetric encryption algorithm. DES is
3753 a block cipher with a 56 bit key and an 8 byte block size. Note
3754 that in TLS, for key generation purposes, DES is treated as
3755 having an 8 byte key length (64 bits), but it still only provides
3756 56 bits of protection. (The low bit of each key byte is presumed
3757 to be set to produce odd parity in that key byte.) DES can also
3758 be operated in a mode where three independent keys and three
3759 encryptions are used for each block of data; this uses 168 bits
3760 of key (24 bytes in the TLS key generation method) and provides
3761 the equivalent of 112 bits of security. [DES], [3DES]
3763 Digital Signature Standard (DSS)
3764 A standard for digital signing, including the Digital Signing
3765 Algorithm, approved by the National Institute of Standards and
3766 Technology, defined in NIST FIPS PUB 186, "Digital Signature
3767 Standard", published May, 1994 by the U.S. Dept. of Commerce.
3768 [DSS]
3770 digital signatures
3771 Digital signatures utilize public key cryptography and one-way
3772 hash functions to produce a signature of the data that can be
3773 authenticated, and is difficult to forge or repudiate.
3775 handshake
3776 An initial negotiation between client and server that establishes
3777 the parameters of their transactions.
3779 Initialization Vector (IV)
3780 When a block cipher is used in CBC mode, the initialization
3784 Dierks & Rescorla Standards Track [Page 70]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3787 vector is exclusive-ORed with the first plaintext block prior to
3788 encryption.
3790 IDEA
3791 A 64-bit block cipher designed by Xuejia Lai and James Massey.
3792 [IDEA]
3794 Message Authentication Code (MAC)
3795 A Message Authentication Code is a one-way hash computed from a
3796 message and some secret data. It is difficult to forge without
3797 knowing the secret data. Its purpose is to detect if the message
3798 has been altered.
3800 master secret
3801 Secure secret data used for generating encryption keys, MAC
3802 secrets, and IVs.
3804 MD5
3805 MD5 is a secure hashing function that converts an arbitrarily
3806 long data stream into a digest of fixed size (16 bytes). [MD5]
3808 public key cryptography
3809 A class of cryptographic techniques employing two-key ciphers.
3810 Messages encrypted with the public key can only be decrypted with
3811 the associated private key. Conversely, messages signed with the
3812 private key can be verified with the public key.
3814 one-way hash function
3815 A one-way transformation that converts an arbitrary amount of
3816 data into a fixed-length hash. It is computationally hard to
3817 reverse the transformation or to find collisions. MD5 and SHA are
3818 examples of one-way hash functions.
3820 RC2
3821 A block cipher developed by Ron Rivest at RSA Data Security, Inc.
3822 [RSADSI] described in [RC2].
3824 RC4
3825 A stream cipher invented by Ron Rivest. A compatible cipher is
3826 described in [SCH].
3828 RSA
3829 A very widely used public-key algorithm that can be used for
3830 either encryption or digital signing. [RSA]
3832 server
3833 The server is the application entity that responds to requests
3834 for connections from clients. See also under client.
3838 Dierks & Rescorla Standards Track [Page 71]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3841 session
3842 A TLS session is an association between a client and a server.
3843 Sessions are created by the handshake protocol. Sessions define a
3844 set of cryptographic security parameters that can be shared among
3845 multiple connections. Sessions are used to avoid the expensive
3846 negotiation of new security parameters for each connection.
3848 session identifier
3849 A session identifier is a value generated by a server that
3850 identifies a particular session.
3852 server write key
3853 The key used to encrypt data written by the server.
3855 server write MAC secret
3856 The secret data used to authenticate data written by the server.
3858 SHA
3859 The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
3860 produces a 20-byte output. Note that all references to SHA
3861 actually use the modified SHA-1 algorithm. [SHA]
3863 SSL
3864 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
3865 SSL Version 3.0
3867 stream cipher
3868 An encryption algorithm that converts a key into a
3869 cryptographically strong keystream, which is then exclusive-ORed
3870 with the plaintext.
3872 symmetric cipher
3873 See bulk cipher.
3875 Transport Layer Security (TLS)
3876 This protocol; also, the Transport Layer Security working group
3877 of the Internet Engineering Task Force (IETF). See "Comments" at
3878 the end of this document.
3892 Dierks & Rescorla Standards Track [Page 72]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3895 Appendix C. CipherSuite Definitions
3897 CipherSuite Key Cipher Hash
3898 Exchange
3900 TLS_NULL_WITH_NULL_NULL NULL NULL NULL
3901 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
3902 TLS_RSA_WITH_NULL_SHA RSA NULL SHA
3903 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
3904 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
3905 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
3906 TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
3907 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
3908 TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
3909 TLS_RSA_WITH_AES_256_SHA RSA AES_256_CBC SHA
3910 TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
3911 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
3912 TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
3913 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
3914 TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
3915 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
3916 TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
3917 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
3918 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
3919 TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA
3920 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
3921 TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA
3922 TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA
3923 TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA
3924 TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA
3925 TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA
3926 TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA
3927 TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA
3928 TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA
3929 TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA
3930 TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA
3932 Key
3933 Exchange
3934 Algorithm Description Key size limit
3936 DHE_DSS Ephemeral DH with DSS signatures None
3937 DHE_RSA Ephemeral DH with RSA signatures None
3938 DH_anon Anonymous DH, no signatures None
3939 DH_DSS DH with DSS-based certificates None
3940 DH_RSA DH with RSA-based certificates None
3941 RSA = none
3942 NULL No key exchange N/A
3946 Dierks & Rescorla Standards Track [Page 73]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
3949 RSA RSA key exchange None
3951 Key Expanded IV Block
3952 Cipher Type Material Key Material Size Size
3954 NULL Stream 0 0 0 N/A
3955 IDEA_CBC Block 16 16 8 8
3956 RC2_CBC_40 Block 5 16 8 8
3957 RC4_40 Stream 5 16 0 N/A
3958 RC4_128 Stream 16 16 0 N/A
3959 DES40_CBC Block 5 8 8 8
3960 DES_CBC Block 8 8 8 8
3961 3DES_EDE_CBC Block 24 24 8 8
3963 Type
3964 Indicates whether this is a stream cipher or a block cipher
3965 running in CBC mode.
3967 Key Material
3968 The number of bytes from the key_block that are used for
3969 generating the write keys.
3971 Expanded Key Material
3972 The number of bytes actually fed into the encryption algorithm.
3974 IV Size
3975 The amount of data needed to be generated for the initialization
3976 vector. Zero for stream ciphers; equal to the block size for
3977 block ciphers.
3979 Block Size
3980 The amount of data a block cipher enciphers in one chunk; a
3981 block cipher running in CBC mode can only encrypt an even
3982 multiple of its block size.
3984 Hash Hash Padding
3985 function Size Size
3986 NULL 0 0
3987 MD5 16 48
3988 SHA 20 40
4000 Dierks & Rescorla Standards Track [Page 74]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4003 Appendix D. Implementation Notes
4005 The TLS protocol cannot prevent many common security mistakes. This
4006 section provides several recommendations to assist implementors.
4008 D.1 Random Number Generation and Seeding
4010 TLS requires a cryptographically secure pseudorandom number generator
4011 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
4012 based on secure hash operations, most notably MD5 and/or SHA, are
4013 acceptable, but cannot provide more security than the size of the
4014 random number generator state. (For example, MD5-based PRNGs usually
4015 provide 128 bits of state.)
4017 To estimate the amount of seed material being produced, add the
4018 number of bits of unpredictable information in each seed byte. For
4019 example, keystroke timing values taken from a PC compatible's 18.2 Hz
4020 timer provide 1 or 2 secure bits each, even though the total size of
4021 the counter value is 16 bits or more. Seeding a 128-bit PRNG, one
4022 would thus require approximately 100 such timer values.
4024 [RANDOM] provides guidance on the generation of random values.
4026 D.2 Certificates and Authentication
4028 Implementations are responsible for verifying the integrity of
4029 certificates and should generally support certificate revocation
4030 messages. Certificates should always be verified to ensure proper
4031 signing by a trusted Certificate Authority (CA). The selection and
4032 addition of trusted CAs should be done very carefully. Users should
4033 be able to view information about the certificate and root CA.
4035 D.3 CipherSuites
4037 TLS supports a range of key sizes and security levels, including some
4038 that provide no or minimal security. A proper implementation will
4039 probably not support many cipher suites. For instance, anonymous
4040 Diffie-Hellman is strongly discouraged because it cannot prevent man-
4041 in-the-middle attacks. Applications should also enforce minimum and
4042 maximum key sizes. For example, certificate chains containing 512-bit
4043 RSA keys or signatures are not appropriate for high-security
4044 applications.
4054 Dierks & Rescorla Standards Track [Page 75]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4057 Appendix E. Backward Compatibility
4059 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
4061 Since there are various versions of TLS (1.0, 1.1, 1.2, and any
4062 future versions) and SSL (2.0 and 3.0), means are needed to negotiate
4063 the specific protocol version to use. The TLS protocol provides a
4064 built-in mechanism for version negotiation so as not to bother other
4065 protocol components with the complexities of version selection.
4067 TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
4068 compatible ClientHello messages; thus, supporting all of them is
4069 relatively easy. Similarly, servers can easily handle clients trying
4070 to use future versions of TLS as long as the ClientHello format
4071 remains compatible, and the client support the highest protocol
4072 version available in the server.
4074 A TLS 1.2 client who wishes to negotiate with such older servers will
4075 send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
4076 ClientHello.client_version. If the server does not support this
4077 version, it will respond with ServerHello containing an older version
4078 number. If the client agrees to use this version, the negotiation
4079 will proceed as appropriate for the negotiated protocol.
4081 If the version chosen by the server is not supported by the client
4082 (or not acceptable), the client MUST send a "protocol_version" alert
4083 message and close the connection.
4085 If a TLS server receives a ClientHello containing a version number
4086 greater than the highest version supported by the server, it MUST
4087 reply according to the highest version supported by the server.
4089 A TLS server can also receive a ClientHello containing version number
4090 smaller than the highest supported version. If the server wishes to
4091 negotiate with old clients, it will proceed as appropriate for the
4092 highest version supported by the server that is not greater than
4093 ClientHello.client_version. For example, if the server supports TLS
4094 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
4095 proceed with a TLS 1.0 ServerHello. If server supports (or is willing
4096 to use) only versions greater than client_version, it MUST send a
4097 "protocol_version" alert message and close the connection.
4099 Whenever a client already knows the highest protocol known to a
4100 server (for example, when resuming a session), it SHOULD initiate the
4101 connection in that native protocol.
4103 Note: some server implementations are known to implement version
4104 negotiation incorrectly. For example, there are buggy TLS 1.0 servers
4108 Dierks & Rescorla Standards Track [Page 76]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4111 that simply close the connection when the client offers a version
4112 newer than TLS 1.0. Also, it is known that some servers will refuse
4113 connection if any TLS extensions are included in ClientHello.
4114 Interoperability with such buggy servers is a complex topic beyond
4115 the scope of this document, and may require multiple connection
4116 attempts by the client.
4118 Earlier versions of the TLS specification were not fully clear on
4119 what the record layer version number (TLSPlaintext.version) should
4120 contain when sending ClientHello (i.e., before it is known which
4121 version of the protocol will be employed). Thus, TLS servers
4122 compliant with this specification MUST accept any value {03,XX} as
4123 the record layer version number for ClientHello.
4125 TLS clients that wish to negotiate with older servers MAY send any
4126 value {03,XX} as the record layer version number. Typical values
4127 would be {03,00}, the lowest version number supported by the client,
4128 and the value of ClientHello.client_version. No single value will
4129 guarantee interoperability with all old servers, but this is a
4130 complex topic beyond the scope of this document.
4132 E.2 Compatibility with SSL 2.0
4134 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
4135 version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
4136 contain the same version number as would be used for ordinary
4137 ClientHello, and MUST encode the supported TLS ciphersuites in the
4138 CIPHER-SPECS-DATA field as described below.
4140 Warning: The ability to send version 2.0 CLIENT-HELLO messages will be
4141 phased out with all due haste, since the newer ClientHello format
4142 provides better mechanisms for moving to newer versions and
4143 negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
4145 However, even TLS servers that do not support SSL 2.0 SHOULD accept
4146 version 2.0 CLIENT-HELLO messages. The message is presented below in
4147 sufficient detail for TLS server implementors; the true definition is
4148 still assumed to be [SSL2].
4150 For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
4151 way as a ClientHello with a "null" compression method and no
4152 extensions. Note that this message MUST be sent directly on the wire,
4153 not wrapped as a TLS record. For the purposes of calculating Finished
4154 and CertificateVerify, the msg_length field is not considered to be a
4155 part of the handshake message.
4157 uint8 V2CipherSpec[3];
4162 Dierks & Rescorla Standards Track [Page 77]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4165 struct {
4166 uint16 msg_length;
4167 uint8 msg_type;
4168 Version version;
4169 uint16 cipher_spec_length;
4170 uint16 session_id_length;
4171 uint16 challenge_length;
4172 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
4173 opaque session_id[V2ClientHello.session_id_length];
4174 opaque challenge[V2ClientHello.challenge_length;
4175 } V2ClientHello;
4177 msg_length
4178 The highest bit MUST be 1; the remaining bits contain the
4179 length of the following data in bytes.
4181 msg_type
4182 This field, in conjunction with the version field, identifies a
4183 version 2 client hello message. The value SHOULD be one (1).
4185 version
4186 Equal to ClientHello.client_version.
4188 cipher_spec_length
4189 This field is the total length of the field cipher_specs. It
4190 cannot be zero and MUST be a multiple of the V2CipherSpec length
4191 (3).
4193 session_id_length
4194 This field MUST have a value of zero. MUST be zero for a client
4195 that claims to support TLS 1.2.
4197 challenge_length
4198 The length in bytes of the client's challenge to the server to
4199 authenticate itself. Historically, permissible values are between
4200 16 and 32 bytes inclusive. When using the SSLv2 backward
4201 compatible handshake the client MUST use a 32-byte challenge.
4203 cipher_specs
4204 This is a list of all CipherSpecs the client is willing and able
4205 to use. In addition to the 2.0 cipher specs defined in [SSL2],
4206 this includes the TLS cipher suites normally sent in
4207 ClientHello.cipher_suites, each cipher suite prefixed by a zero
4208 byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as
4209 {0x00,0x00,0x0A}.
4211 session_id
4212 This field MUST be empty.
4216 Dierks & Rescorla Standards Track [Page 78]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4219 challenge
4220 Corresponds to ClientHello.random. If the challenge length is
4221 less than 32, the TLS server will pad the data with leading
4222 (note: not trailing) zero bytes to make it 32 bytes long.
4224 Note: Requests to resume a TLS session MUST use a TLS client hello.
4226 E.2. Avoiding Man-in-the-Middle Version Rollback
4228 When TLS clients fall back to Version 2.0 compatibility mode, they
4229 SHOULD use special PKCS #1 block formatting. This is done so that TLS
4230 servers will reject Version 2.0 sessions with TLS-capable clients.
4232 When TLS clients are in Version 2.0 compatibility mode, they set the
4233 right-hand (least-significant) 8 random bytes of the PKCS padding
4234 (not including the terminal null of the padding) for the RSA
4235 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
4236 to 0x03 (the other padding bytes are random). After decrypting the
4237 ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
4238 error if these eight padding bytes are 0x03. Version 2.0 servers
4239 receiving blocks padded in this manner will proceed normally.
4270 Dierks & Rescorla Standards Track [Page 79]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4273 Appendix F. Security Analysis
4275 The TLS protocol is designed to establish a secure connection between
4276 a client and a server communicating over an insecure channel. This
4277 document makes several traditional assumptions, including that
4278 attackers have substantial computational resources and cannot obtain
4279 secret information from sources outside the protocol. Attackers are
4280 assumed to have the ability to capture, modify, delete, replay, and
4281 otherwise tamper with messages sent over the communication channel.
4282 This appendix outlines how TLS has been designed to resist a variety
4283 of attacks.
4285 F.1. Handshake Protocol
4287 The handshake protocol is responsible for selecting a CipherSpec and
4288 generating a Master Secret, which together comprise the primary
4289 cryptographic parameters associated with a secure session. The
4290 handshake protocol can also optionally authenticate parties who have
4291 certificates signed by a trusted certificate authority.
4293 F.1.1. Authentication and Key Exchange
4295 TLS supports three authentication modes: authentication of both
4296 parties, server authentication with an unauthenticated client, and
4297 total anonymity. Whenever the server is authenticated, the channel is
4298 secure against man-in-the-middle attacks, but completely anonymous
4299 sessions are inherently vulnerable to such attacks. Anonymous
4300 servers cannot authenticate clients. If the server is authenticated,
4301 its certificate message must provide a valid certificate chain
4302 leading to an acceptable certificate authority. Similarly,
4303 authenticated clients must supply an acceptable certificate to the
4304 server. Each party is responsible for verifying that the other's
4305 certificate is valid and has not expired or been revoked.
4307 The general goal of the key exchange process is to create a
4308 pre_master_secret known to the communicating parties and not to
4309 attackers. The pre_master_secret will be used to generate the
4310 master_secret (see Section 8.1). The master_secret is required to
4311 generate the finished messages, encryption keys, and MAC secrets (see
4312 Sections 7.4.9 and 6.3). By sending a correct finished message,
4313 parties thus prove that they know the correct pre_master_secret.
4315 F.1.1.1. Anonymous Key Exchange
4317 Completely anonymous sessions can be established using RSA or Diffie-
4318 Hellman for key exchange. With anonymous RSA, the client encrypts a
4319 pre_master_secret with the server's uncertified public key extracted
4320 from the server key exchange message. The result is sent in a client
4324 Dierks & Rescorla Standards Track [Page 80]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4327 key exchange message. Since eavesdroppers do not know the server's
4328 private key, it will be infeasible for them to decode the
4329 pre_master_secret.
4331 Note: No anonymous RSA Cipher Suites are defined in this document.
4333 With Diffie-Hellman, the server's public parameters are contained in
4334 the server key exchange message and the client's are sent in the
4335 client key exchange message. Eavesdroppers who do not know the
4336 private values should not be able to find the Diffie-Hellman result
4337 (i.e. the pre_master_secret).
4339 Warning: Completely anonymous connections only provide protection
4340 against passive eavesdropping. Unless an independent tamper-
4341 proof channel is used to verify that the finished messages
4342 were not replaced by an attacker, server authentication is
4343 required in environments where active man-in-the-middle
4344 attacks are a concern.
4346 F.1.1.2. RSA Key Exchange and Authentication
4348 With RSA, key exchange and server authentication are combined. The
4349 public key is contained in the server's certificate. Note that
4350 compromise of the server's static RSA key results in a loss of
4351 confidentiality for all sessions protected under that static key. TLS
4352 users desiring Perfect Forward Secrecy should use DHE cipher suites.
4353 The damage done by exposure of a private key can be limited by
4354 changing one's private key (and certificate) frequently.
4356 After verifying the server's certificate, the client encrypts a
4357 pre_master_secret with the server's public key. By successfully
4358 decoding the pre_master_secret and producing a correct finished
4359 message, the server demonstrates that it knows the private key
4360 corresponding to the server certificate.
4362 When RSA is used for key exchange, clients are authenticated using
4363 the certificate verify message (see Section 7.4.9). The client signs
4364 a value derived from the master_secret and all preceding handshake
4365 messages. These handshake messages include the server certificate,
4366 which binds the signature to the server, and ServerHello.random,
4367 which binds the signature to the current handshake process.
4369 F.1.1.3. Diffie-Hellman Key Exchange with Authentication
4371 When Diffie-Hellman key exchange is used, the server can either
4372 supply a certificate containing fixed Diffie-Hellman parameters or
4373 use the server key exchange message to send a set of temporary
4374 Diffie-Hellman parameters signed with a DSS or RSA certificate.
4378 Dierks & Rescorla Standards Track [Page 81]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4381 Temporary parameters are hashed with the hello.random values before
4382 signing to ensure that attackers do not replay old parameters. In
4383 either case, the client can verify the certificate or signature to
4384 ensure that the parameters belong to the server.
4386 If the client has a certificate containing fixed Diffie-Hellman
4387 parameters, its certificate contains the information required to
4388 complete the key exchange. Note that in this case the client and
4389 server will generate the same Diffie-Hellman result (i.e.,
4390 pre_master_secret) every time they communicate. To prevent the
4391 pre_master_secret from staying in memory any longer than necessary,
4392 it should be converted into the master_secret as soon as possible.
4393 Client Diffie-Hellman parameters must be compatible with those
4394 supplied by the server for the key exchange to work.
4396 If the client has a standard DSS or RSA certificate or is
4397 unauthenticated, it sends a set of temporary parameters to the server
4398 in the client key exchange message, then optionally uses a
4399 certificate verify message to authenticate itself.
4401 If the same DH keypair is to be used for multiple handshakes, either
4402 because the client or server has a certificate containing a fixed DH
4403 keypair or because the server is reusing DH keys, care must be taken
4404 to prevent small subgroup attacks. Implementations SHOULD follow the
4405 guidelines found in [SUBGROUP].
4407 Small subgroup attacks are most easily avoided by using one of the
4408 DHE ciphersuites and generating a fresh DH private key (X) for each
4409 handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
4410 computed very quickly, therefore the performance cost is minimized.
4411 Additionally, using a fresh key for each handshake provides Perfect
4412 Forward Secrecy. Implementations SHOULD generate a new X for each
4413 handshake when using DHE ciphersuites.
4415 F.1.2. Version Rollback Attacks
4417 Because TLS includes substantial improvements over SSL Version 2.0,
4418 attackers may try to make TLS-capable clients and servers fall back
4419 to Version 2.0. This attack can occur if (and only if) two TLS-
4420 capable parties use an SSL 2.0 handshake.
4422 Although the solution using non-random PKCS #1 block type 2 message
4423 padding is inelegant, it provides a reasonably secure way for Version
4424 3.0 servers to detect the attack. This solution is not secure against
4425 attackers who can brute force the key and substitute a new ENCRYPTED-
4426 KEY-DATA message containing the same key (but with normal padding)
4427 before the application specified wait threshold has expired. Altering
4428 the padding of the least significant 8 bytes of the PKCS padding does
4432 Dierks & Rescorla Standards Track [Page 82]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4435 not impact security for the size of the signed hashes and RSA key
4436 lengths used in the protocol, since this is essentially equivalent to
4437 increasing the input block size by 8 bytes.
4439 F.1.3. Detecting Attacks Against the Handshake Protocol
4441 An attacker might try to influence the handshake exchange to make the
4442 parties select different encryption algorithms than they would
4443 normally chooses.
4445 For this attack, an attacker must actively change one or more
4446 handshake messages. If this occurs, the client and server will
4447 compute different values for the handshake message hashes. As a
4448 result, the parties will not accept each others' finished messages.
4449 Without the master_secret, the attacker cannot repair the finished
4450 messages, so the attack will be discovered.
4452 F.1.4. Resuming Sessions
4454 When a connection is established by resuming a session, new
4455 ClientHello.random and ServerHello.random values are hashed with the
4456 session's master_secret. Provided that the master_secret has not been
4457 compromised and that the secure hash operations used to produce the
4458 encryption keys and MAC secrets are secure, the connection should be
4459 secure and effectively independent from previous connections.
4460 Attackers cannot use known encryption keys or MAC secrets to
4461 compromise the master_secret without breaking the secure hash
4462 operations (which use both SHA and MD5).
4464 Sessions cannot be resumed unless both the client and server agree.
4465 If either party suspects that the session may have been compromised,
4466 or that certificates may have expired or been revoked, it should
4467 force a full handshake. An upper limit of 24 hours is suggested for
4468 session ID lifetimes, since an attacker who obtains a master_secret
4469 may be able to impersonate the compromised party until the
4470 corresponding session ID is retired. Applications that may be run in
4471 relatively insecure environments should not write session IDs to
4472 stable storage.
4474 F.1.5 Extensions
4476 Security considerations for the extension mechanism in general, and
4477 the design of new extensions, are described in the previous section.
4478 A security analysis of each of the extensions defined in this
4479 document is given below.
4481 In general, implementers should continue to monitor the state of the
4482 art, and address any weaknesses identified.
4486 Dierks & Rescorla Standards Track [Page 83]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4489 F.2. Protecting Application Data
4491 The master_secret is hashed with the ClientHello.random and
4492 ServerHello.random to produce unique data encryption keys and MAC
4493 secrets for each connection.
4495 Outgoing data is protected with a MAC before transmission. To prevent
4496 message replay or modification attacks, the MAC is computed from the
4497 MAC secret, the sequence number, the message length, the message
4498 contents, and two fixed character strings. The message type field is
4499 necessary to ensure that messages intended for one TLS Record Layer
4500 client are not redirected to another. The sequence number ensures
4501 that attempts to delete or reorder messages will be detected. Since
4502 sequence numbers are 64 bits long, they should never overflow.
4503 Messages from one party cannot be inserted into the other's output,
4504 since they use independent MAC secrets. Similarly, the server-write
4505 and client-write keys are independent, so stream cipher keys are used
4506 only once.
4508 If an attacker does break an encryption key, all messages encrypted
4509 with it can be read. Similarly, compromise of a MAC key can make
4510 message modification attacks possible. Because MACs are also
4511 encrypted, message-alteration attacks generally require breaking the
4512 encryption algorithm as well as the MAC.
4514 Note: MAC secrets may be larger than encryption keys, so messages can
4515 remain tamper resistant even if encryption keys are broken.
4517 F.3. Explicit IVs
4519 [CBCATT] describes a chosen plaintext attack on TLS that depends
4520 on knowing the IV for a record. Previous versions of TLS [TLS1.0]
4521 used the CBC residue of the previous record as the IV and
4522 therefore enabled this attack. This version uses an explicit IV
4523 in order to protect against this attack.
4525 F.4. Security of Composite Cipher Modes
4527 TLS secures transmitted application data via the use of symmetric
4528 encryption and authentication functions defined in the negotiated
4529 ciphersuite. The objective is to protect both the integrity and
4530 confidentiality of the transmitted data from malicious actions by
4531 active attackers in the network. It turns out that the order in
4532 which encryption and authentication functions are applied to the
4533 data plays an important role for achieving this goal [ENCAUTH].
4535 The most robust method, called encrypt-then-authenticate, first
4536 applies encryption to the data and then applies a MAC to the
4540 Dierks & Rescorla Standards Track [Page 84]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4543 ciphertext. This method ensures that the integrity and
4544 confidentiality goals are obtained with ANY pair of encryption
4545 and MAC functions, provided that the former is secure against
4546 chosen plaintext attacks and the MAC is secure against chosen-
4547 message attacks. TLS uses another method, called authenticate-
4548 then-encrypt, in which first a MAC is computed on the plaintext
4549 and then the concatenation of plaintext and MAC is encrypted.
4550 This method has been proven secure for CERTAIN combinations of
4551 encryption functions and MAC functions, but is not guaranteed to
4552 be secure in general. In particular, it has been shown that there
4553 exist perfectly secure encryption functions (secure even in the
4554 information-theoretic sense) that combined with any secure MAC
4555 function, fail to provide the confidentiality goal against an
4556 active attack. Therefore, new ciphersuites and operation modes
4557 adopted into TLS need to be analyzed under the authenticate-then-
4558 encrypt method to verify that they achieve the stated integrity
4559 and confidentiality goals.
4561 Currently, the security of the authenticate-then-encrypt method
4562 has been proven for some important cases. One is the case of
4563 stream ciphers in which a computationally unpredictable pad of
4564 the length of the message, plus the length of the MAC tag, is
4565 produced using a pseudo-random generator and this pad is xor-ed
4566 with the concatenation of plaintext and MAC tag. The other is
4567 the case of CBC mode using a secure block cipher. In this case,
4568 security can be shown if one applies one CBC encryption pass to
4569 the concatenation of plaintext and MAC and uses a new,
4570 independent, and unpredictable, IV for each new pair of plaintext
4571 and MAC. In previous versions of SSL, CBC mode was used properly
4572 EXCEPT that it used a predictable IV in the form of the last
4573 block of the previous ciphertext. This made TLS open to chosen
4574 plaintext attacks. This verson of the protocol is immune to
4575 those attacks. For exact details in the encryption modes proven
4576 secure see [ENCAUTH].
4578 F.5 Denial of Service
4580 TLS is susceptible to a number of denial of service (DoS) attacks.
4581 In particular, an attacker who initiates a large number of TCP
4582 connections can cause a server to consume large amounts of CPU doing
4583 RSA decryption. However, because TLS is generally used over TCP, it
4584 is difficult for the attacker to hide his point of origin if proper
4585 TCP SYN randomization is used [SEQNUM] by the TCP stack.
4587 Because TLS runs over TCP, it is also susceptible to a number of
4588 denial of service attacks on individual connections. In particular,
4589 attackers can forge RSTs, thereby terminating connections, or forge
4590 partial TLS records, thereby causing the connection to stall. These
4594 Dierks & Rescorla Standards Track [Page 85]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4597 attacks cannot in general be defended against by a TCP-using
4598 protocol. Implementors or users who are concerned with this class of
4599 attack should use IPsec AH [AH] or ESP [ESP].
4601 F.6. Final Notes
4603 For TLS to be able to provide a secure connection, both the client
4604 and server systems, keys, and applications must be secure. In
4605 addition, the implementation must be free of security errors.
4607 The system is only as strong as the weakest key exchange and
4608 authentication algorithm supported, and only trustworthy
4609 cryptographic functions should be used. Short public keys and
4610 anonymous servers should be used with great caution. Implementations
4611 and users must be careful when deciding which certificates and
4612 certificate authorities are acceptable; a dishonest certificate
4613 authority can do tremendous damage.
4648 Dierks & Rescorla Standards Track [Page 86]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4651 Security Considerations
4653 Security issues are discussed throughout this memo, especially in
4654 Appendices D, E, and F.
4657 Changes in This Version
4659 [RFC Editor: Please delete this]
4661 - Forbid decryption_failed [issue 5]
4663 - Fix CertHashTypes declaration [issue 20]
4665 - Fix client_version in 7.4.1.2 [issue 19]
4667 - Require Bleichenbacher and timing attack protection [issues 17
4668 and
4669 12].
4671 - Merged RFC-editor changes back in.
4673 - Editorial changes from NIST [issue 8]
4675 - Clarified the meaning of HelloRequest [issue 39]
4677 - Editorial nits from Peter Williams [issue 35]
4679 - Made maximum fragment size a MUST [issue 9]
4681 - Clarified that resumption is not mandatory and servers may
4682 refuse [issue 37]
4684 - Fixed identifier for cert_hash_types [issue 38]
4686 - Forbid sending unknown record types [issue 11]
4688 - Clarify that DH parameters and other integers are unsigned [issue
4689 28]
4691 - Clarify when a server Certificate is sent [isssue 29]
4693 - Prohibit zero-length fragments [issue 10]
4695 - Fix reference for DES/3DES [issue 18]
4697 - Clean up some notes on deprecated alerts [issue 6]
4702 Dierks & Rescorla Standards Track [Page 87]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4705 - Remove ephemeral RSA [issue 3]
4707 - Stripped out discussion of how to generate the IV and replaced it
4708 with a randomness/unpredictability requirement [issue 7]
4710 - Replaced the PKCS#1 text with references to PKCS#1 v2. This also
4711 includes DigestInfo encoding [issues 1 and 22]
4713 - Removed extension definitions and merged the ExtendedHello
4714 definitions [issues 31 and 32]
4716 - Replaced CipherSpec references with SecurityParameters references
4717 [issue 2]
4719 - Cleaned up IANA text [issues 33 and 34]
4721 - Cleaned up backward compatibility text [issue 25]
4723 Normative References
4724 [AES] National Institute of Standards and Technology,
4725 "Specification for the Advanced Encryption Standard (AES)"
4726 FIPS 197. November 26, 2001.
4728 [3DES] National Institute of Standards and Tecnology,
4729 "Recommendation for the Triple Data Encryption Algorithm
4730 (TDEA) Block Cipher", NIST Special Publication 800-67, May
4731 2004.
4733 [DES] National Institute of Standards and Technology, "Data
4734 Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
4736 [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National
4737 Institute of Standards and Technology, U.S. Department of
4738 Commerce, 2000.
4741 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
4742 Hashing for Message Authentication", RFC 2104, February
4743 1997.
4745 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
4746 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
4747 Protocol -- HTTP/1.1", RFC 2616, June 1999.
4749 [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
4750 Series in Information Processing, v. 1, Konstanz: Hartung-
4751 Gorre Verlag, 1992.
4756 Dierks & Rescorla Standards Track [Page 88]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4759 [IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
4760 "Internationalizing Domain Names in Applications (IDNA)",
4761 RFC 3490, March 2003.
4763 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
4764 April 1992.
4766 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
4767 Adams, "Internet X.509 Public Key Infrastructure: Online
4768 Certificate Status Protocol - OCSP", RFC 2560, June 1999.
4770 [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
4771 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
4772 3447, February 2003.
4774 [PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key
4775 Infrastructure - Operation Protocols: FTP and HTTP", RFC
4776 2585, May 1999.
4779 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
4780 Public Key Infrastructure: Part I: X.509 Certificate and CRL
4781 Profile", RFC 3280, April 2002.
4783 [RC2] Rivest, R., "A Description of the RC2(r) Encryption
4784 Algorithm", RFC 2268, March 1998.
4786 [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
4787 and Source Code in C, 2ed", Published by John Wiley & Sons,
4788 Inc. 1996.
4790 [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
4791 Institute of Standards and Technology, U.S. Department of
4792 Commerce., August 2001.
4794 [REQ] Bradner, S., "Key words for use in RFCs to Indicate
4795 Requirement Levels", BCP 14, RFC 2119, March 1997.
4797 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
4798 IANA Considerations Section in RFCs", BCP 25, RFC 2434,
4799 October 1998.
4801 [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
4802 for Transport Layer Security (TLS)", RFC 3268, June 2002.
4804 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
4805 Wright, T., "Transport Layer Security (TLS) Extensions", RFC
4806 3546, June 2003.
4810 Dierks & Rescorla Standards Track [Page 89]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4813 [TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
4814 Suites to Transport Layer Security (TLS)", RFC 2712, October
4815 1999.
4817 [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
4818 Resource Identifiers (URI): Generic Syntax", RFC 2396,
4819 August 1998.
4821 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
4822 RFC 3629, November 2003.
4824 [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001,
4825 "Information Systems - Open Systems Interconnection - The
4826 Directory: Public key and Attribute certificate
4827 frameworks."
4829 [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
4830 ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to
4831 ISO/IEC 9594:8:2001.
4833 Informative References
4835 [AEAD] Mcgrew, D., "Authenticated Encryption", July 2006, draft-
4836 mcgrew-auth-enc-00.txt.
4838 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
4839 4302, December 2005.
4841 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
4842 Protocols Based on RSA Encryption Standard PKCS #1" in
4843 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
4844 1-12, 1998.
4846 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
4847 Problems and Countermeasures",
4848 http://www.openssl.org/~bodo/tls-cbc.txt.
4850 [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
4851 http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
4853 [CCM] "NIST Special Publication 800-38C: The CCM Mode for
4854 Authentication and Confidentiality",
4855 http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.
4857 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
4858 for Protecting Communications (Or: How Secure is SSL?)",
4859 Crypto 2001.
4864 Dierks & Rescorla Standards Track [Page 90]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4867 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
4868 Payload (ESP)", RFC 4303, December 2005.
4870 [GCM] "NIST Special Publication 800-38C: The CCM Mode for
4871 Authentication and Confidentiality",
4872 http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.
4874 [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
4875 Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
4876 March 2003.
4878 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
4879 Standard," version 1.5, November 1993.
4881 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
4882 Standard," version 1.5, November 1993.
4884 [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
4885 Requirements for Security", BCP 106, RFC 4086, June 2005.
4887 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
4888 Obtaining Digital Signatures and Public-Key Cryptosystems,"
4889 Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
4890 120-126.
4892 [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
4893 RFC 1948, May 1996.
4895 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
4896 Corp., Feb 9, 1995.
4898 [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
4899 Netscape Communications Corp., Nov 18, 1996.
4901 [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
4902 Attacks on the Diffie-Hellman Key Agreement Method for
4903 S/MIME", RFC 2785, March 2000.
4905 [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
4906 September 1981.
4908 [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
4909 practical", USENIX Security Symposium 2003.
4911 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
4912 RFC 2246, January 1999.
4914 [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
4918 Dierks & Rescorla Standards Track [Page 91]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4921 1.1", RFC 4346, April, 2006.
4923 [X501] ITU-T Recommendation X.501: Information Technology - Open
4924 Systems Interconnection - The Directory: Models, 1993.
4926 [X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
4927 Open Systems Interconnection - "The Directory -
4928 Authentication Framework". 1988.
4930 [XDR] Srinivansan, R., Sun Microsystems, "XDR: External Data
4931 Representation Standard", RFC 1832, August 1995.
4934 Credits
4936 Working Group Chairs
4937 Eric Rescorla
4938 EMail: ekr@networkresonance.com
4940 Pasi Eronen
4941 pasi.eronen@nokia.com
4944 Editors
4946 Tim Dierks Eric Rescorla
4947 Independent Network Resonance, Inc.
4949 EMail: tim@dierks.org EMail: ekr@networkresonance.com
4953 Other contributors
4955 Christopher Allen (co-editor of TLS 1.0)
4956 Alacrity Ventures
4957 ChristopherA@AlacrityManagement.com
4959 Martin Abadi
4960 University of California, Santa Cruz
4961 abadi@cs.ucsc.edu
4963 Steven M. Bellovin
4964 Columbia University
4965 smb@cs.columbia.edu
4967 Simon Blake-Wilson
4968 BCI
4972 Dierks & Rescorla Standards Track [Page 92]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
4975 EMail: sblakewilson@bcisse.com
4977 Ran Canetti
4978 IBM
4979 canetti@watson.ibm.com
4981 Pete Chown
4982 Skygate Technology Ltd
4983 pc@skygate.co.uk
4985 Taher Elgamal
4986 taher@securify.com
4987 Securify
4989 Anil Gangolli
4990 anil@busybuddha.org
4992 Kipp Hickman
4994 David Hopwood
4995 Independent Consultant
4996 EMail: david.hopwood@blueyonder.co.uk
4998 Phil Karlton (co-author of SSLv3)
5000 Paul Kocher (co-author of SSLv3)
5001 Cryptography Research
5002 paul@cryptography.com
5004 Hugo Krawczyk
5005 Technion Israel Institute of Technology
5006 hugo@ee.technion.ac.il
5008 Jan Mikkelsen
5009 Transactionware
5010 EMail: janm@transactionware.com
5012 Magnus Nystrom
5013 RSA Security
5014 EMail: magnus@rsasecurity.com
5016 Robert Relyea
5017 Netscape Communications
5018 relyea@netscape.com
5020 Jim Roskind
5021 Netscape Communications
5022 jar@netscape.com
5026 Dierks & Rescorla Standards Track [Page 93]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
5029 Michael Sabin
5031 Dan Simon
5032 Microsoft, Inc.
5033 dansimon@microsoft.com
5035 Tom Weinstein
5037 Tim Wright
5038 Vodafone
5039 EMail: timothy.wright@vodafone.com
5041 Comments
5043 The discussion list for the IETF TLS working group is located at the
5044 e-mail address <tls@ietf.org>. Information on the group and
5045 information on how to subscribe to the list is at
5046 <https://www1.ietf.org/mailman/listinfo/tls>
5048 Archives of the list can be found at:
5049 <http://www.ietf.org/mail-archive/web/tls/current/index.html>
5080 Dierks & Rescorla Standards Track [Page 94]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
5083 Full Copyright Statement
5085 Copyright (C) The IETF Trust (2007).
5087 This document is subject to the rights, licenses and restrictions
5088 contained in BCP 78, and except as set forth therein, the authors
5089 retain all their rights.
5091 This document and the information contained herein are provided on an
5092 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5093 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
5094 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
5095 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
5096 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5097 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5100 Intellectual Property
5102 The IETF takes no position regarding the validity or scope of any
5103 Intellectual Property Rights or other rights that might be claimed to
5104 pertain to the implementation or use of the technology described in
5105 this document or the extent to which any license under such rights
5106 might or might not be available; nor does it represent that it has
5107 made any independent effort to identify any such rights. Information
5108 on the procedures with respect to rights in RFC documents can be
5109 found in BCP 78 and BCP 79.
5111 Copies of IPR disclosures made to the IETF Secretariat and any
5112 assurances of licenses to be made available, or the result of an
5113 attempt made to obtain a general license or permission for the use of
5114 such proprietary rights by implementers or users of this
5115 specification can be obtained from the IETF on-line IPR repository at
5116 http://www.ietf.org/ipr.
5118 The IETF invites any interested party to bring to its attention any
5119 copyrights, patents or patent applications, or other proprietary
5120 rights that may cover technology that may be required to implement
5121 this standard. Please address the information to the IETF at
5122 ietf-ipr@ietf.org.
5125 Acknowledgment
5127 Funding for the RFC Editor function is provided by the IETF
5128 Administrative Support Activity (IASA).
5134 Dierks & Rescorla Standards Track [Page 95]\fdraft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
5188 Dierks & Rescorla Standards Track [Page 96]\f