| blob | 9a960d2057a74b3ccb0e59464375f3c19570dab5 |
7 Network Working Group T. Dierks
8 Request for Comments: 4346 Independent
9 Obsoletes: 2246 E. Rescorla
10 Category: Standards Track RTFM, Inc.
11 April 2006
14 The Transport Layer Security (TLS) Protocol
15 Version 1.1
17 Status of This Memo
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright Notice
27 Copyright (C) The Internet Society (2006).
29 Abstract
31 This document specifies Version 1.1 of the Transport Layer Security
32 (TLS) protocol. The TLS protocol provides communications security
33 over the Internet. The protocol allows client/server applications to
34 communicate in a way that is designed to prevent eavesdropping,
35 tampering, or message forgery.
58 Dierks & Rescorla Standards Track [Page 1]
59 \f
60 RFC 4346 The TLS Protocol April 2006
63 Table of Contents
65 1. Introduction ....................................................4
66 1.1. Differences from TLS 1.0 ...................................5
67 1.2. Requirements Terminology ...................................5
68 2. Goals ...........................................................5
69 3. Goals of This Document ..........................................6
70 4. Presentation Language ...........................................6
71 4.1. Basic Block Size ...........................................7
72 4.2. Miscellaneous ..............................................7
73 4.3. Vectors ....................................................7
74 4.4. Numbers ....................................................8
75 4.5. Enumerateds ................................................8
76 4.6. Constructed Types ..........................................9
77 4.6.1. Variants ...........................................10
78 4.7. Cryptographic Attributes ..................................11
79 4.8. Constants .................................................12
80 5. HMAC and the Pseudorandom Function .............................12
81 6. The TLS Record Protocol ........................................14
82 6.1. Connection States .........................................15
83 6.2. Record layer ..............................................17
84 6.2.1. Fragmentation ......................................17
85 6.2.2. Record Compression and Decompression ...............19
86 6.2.3. Record Payload Protection ..........................19
87 6.2.3.1. Null or Standard Stream Cipher ............20
88 6.2.3.2. CBC Block Cipher ..........................21
89 6.3. Key Calculation ...........................................24
90 7. The TLS Handshaking Protocols ..................................24
91 7.1. Change Cipher Spec Protocol ...............................25
92 7.2. Alert Protocol ............................................26
93 7.2.1. Closure Alerts .....................................27
94 7.2.2. Error Alerts .......................................28
95 7.3. Handshake Protocol Overview ...............................31
96 7.4. Handshake Protocol ........................................34
97 7.4.1. Hello Messages .....................................35
98 7.4.1.1. Hello request .............................35
99 7.4.1.2. Client Hello ..............................36
100 7.4.1.3. Server Hello ..............................39
101 7.4.2. Server Certificate .................................40
102 7.4.3. Server Key Exchange Message ........................42
103 7.4.4. Certificate request ................................44
104 7.4.5. Server Hello Done ..................................46
105 7.4.6. Client certificate .................................46
106 7.4.7. Client Key Exchange Message ........................47
107 7.4.7.1. RSA Encrypted Premaster Secret Message ....47
108 7.4.7.2. Client Diffie-Hellman Public Value ........50
109 7.4.8. Certificate verify .................................50
110 7.4.9. Finished ...........................................51
114 Dierks & Rescorla Standards Track [Page 2]
115 \f
116 RFC 4346 The TLS Protocol April 2006
119 8. Cryptographic Computations .....................................52
120 8.1. Computing the Master Secret ...............................52
121 8.1.1. RSA ................................................53
122 8.1.2. Diffie-Hellman .....................................53
123 9. Mandatory Cipher Suites ........................................53
124 10. Application Data Protocol .....................................53
125 11. Security Considerations .......................................53
126 12. IANA Considerations ...........................................54
127 A. Appendix - Protocol constant values ............................55
128 A.1. Record layer .........................................55
129 A.2. Change cipher specs message ..........................56
130 A.3. Alert messages .......................................56
131 A.4. Handshake protocol ...................................57
132 A.4.1. Hello messages .....................................57
133 A.4.2. Server authentication and key exchange messages ....58
134 A.4.3. Client authentication and key exchange messages ....59
135 A.4.4.Handshake finalization message ......................60
136 A.5. The CipherSuite ......................................60
137 A.6. The Security Parameters ..............................63
138 B. Appendix - Glossary ............................................64
139 C. Appendix - CipherSuite definitions .............................68
140 D. Appendix - Implementation Notes ................................69
141 D.1 Random Number Generation and Seeding ..................70
142 D.2 Certificates and authentication .......................70
143 D.3 CipherSuites ..........................................70
144 E. Appendix - Backward Compatibility With SSL .....................71
145 E.1. Version 2 client hello ...............................72
146 E.2. Avoiding man-in-the-middle version rollback ..........74
147 F. Appendix - Security analysis ...................................74
148 F.1. Handshake protocol ...................................74
149 F.1.1. Authentication and key exchange ....................74
150 F.1.1.1. Anonymous key exchange ...........................75
151 F.1.1.2. RSA key exchange and authentication ..............75
152 F.1.1.3. Diffie-Hellman key exchange with authentication ..76
153 F.1.2. Version rollback attacks ...........................77
154 F.1.3. Detecting attacks against the handshake protocol ...77
155 F.1.4. Resuming sessions ..................................78
156 F.1.5. MD5 and SHA ........................................78
157 F.2. Protecting application data ..........................78
158 F.3. Explicit IVs .........................................79
159 F.4 Security of Composite Cipher Modes ...................79
160 F.5 Denial of Service ....................................80
161 F.6. Final notes ..........................................80
162 Normative References ..............................................81
163 Informative References ............................................82
170 Dierks & Rescorla Standards Track [Page 3]
171 \f
172 RFC 4346 The TLS Protocol April 2006
175 1. Introduction
177 The primary goal of the TLS Protocol is to provide privacy and data
178 integrity between two communicating applications. The protocol is
179 composed of two layers: the TLS Record Protocol and the TLS Handshake
180 Protocol. At the lowest level, layered on top of some reliable
181 transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
182 TLS Record Protocol provides connection security that has two basic
183 properties:
185 - The connection is private. Symmetric cryptography is used for
186 data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for
187 this symmetric encryption are generated uniquely for each
188 connection and are based on a secret negotiated by another
189 protocol (such as the TLS Handshake Protocol). The Record
190 Protocol can also be used without encryption.
192 - The connection is reliable. Message transport includes a message
193 integrity check using a keyed MAC. Secure hash functions (e.g.,
194 SHA, MD5, etc.) are used for MAC computations. The Record
195 Protocol can operate without a MAC, but is generally only used in
196 this mode while another protocol is using the Record Protocol as a
197 transport for negotiating security parameters.
199 The TLS Record Protocol is used for encapsulation of various higher-
200 level protocols. One such encapsulated protocol, the TLS Handshake
201 Protocol, allows the server and client to authenticate each other and
202 to negotiate an encryption algorithm and cryptographic keys before
203 the application protocol transmits or receives its first byte of
204 data. The TLS Handshake Protocol provides connection security that
205 has three basic properties:
207 - The peer's identity can be authenticated using asymmetric, or
208 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
209 authentication can be made optional, but is generally required for
210 at least one of the peers.
212 - The negotiation of a shared secret is secure: the negotiated
213 secret is unavailable to eavesdroppers, and for any authenticated
214 connection the secret cannot be obtained, even by an attacker who
215 can place himself in the middle of the connection.
217 - The negotiation is reliable: no attacker can modify the
218 negotiation communication without being detected by the parties to
219 the communication.
221 One advantage of TLS is that it is application protocol independent.
222 Higher level protocols can layer on top of the TLS Protocol
226 Dierks & Rescorla Standards Track [Page 4]
227 \f
228 RFC 4346 The TLS Protocol April 2006
231 transparently. The TLS standard, however, does not specify how
232 protocols add security with TLS; the decisions on how to initiate TLS
233 handshaking and how to interpret the authentication certificates
234 exchanged are left to the judgment of the designers and implementors
235 of protocols that run on top of TLS.
237 1.1. Differences from TLS 1.0
239 This document is a revision of the TLS 1.0 [TLS1.0] protocol, and
240 contains some small security improvements, clarifications, and
241 editorial improvements. The major changes are:
243 - The implicit Initialization Vector (IV) is replaced with an
244 explicit IV to protect against CBC attacks [CBCATT].
246 - Handling of padding errors is changed to use the bad_record_mac
247 alert rather than the decryption_failed alert to protect against
248 CBC attacks.
250 - IANA registries are defined for protocol parameters.
252 - Premature closes no longer cause a session to be nonresumable.
254 - Additional informational notes were added for various new attacks
255 on TLS.
257 In addition, a number of minor clarifications and editorial
258 improvements were made.
260 1.2. Requirements Terminology
262 In this document, the keywords "MUST", "MUST NOT", "REQUIRED",
263 "SHOULD", "SHOULD NOT" and "MAY" are to be interpreted as described
264 in RFC 2119 [REQ].
266 2. Goals
268 The goals of TLS Protocol, in order of their priority, are as
269 follows:
271 1. Cryptographic security: TLS should be used to establish a secure
272 connection between two parties.
274 2. Interoperability: Independent programmers should be able to
275 develop applications utilizing TLS that can successfully exchange
276 cryptographic parameters without knowledge of one another's code.
282 Dierks & Rescorla Standards Track [Page 5]
283 \f
284 RFC 4346 The TLS Protocol April 2006
287 3. Extensibility: TLS seeks to provide a framework into which new
288 public key and bulk encryption methods can be incorporated as
289 necessary. This will also accomplish two sub-goals: preventing
290 the need to create a new protocol (and risking the introduction of
291 possible new weaknesses) and avoiding the need to implement an
292 entire new security library.
294 4. Relative efficiency: Cryptographic operations tend to be highly
295 CPU intensive, particularly public key operations. For this
296 reason, the TLS protocol has incorporated an optional session
297 caching scheme to reduce the number of connections that need to be
298 established from scratch. Additionally, care has been taken to
299 reduce network activity.
301 3. Goals of This Document
303 This document and the TLS protocol itself are based on the SSL 3.0
304 Protocol Specification as published by Netscape. The differences
305 between this protocol and SSL 3.0 are not dramatic, but they are
306 significant enough that TLS 1.1, TLS 1.0, and SSL 3.0 do not
307 interoperate (although each protocol incorporates a mechanism by
308 which an implementation can back down prior versions). This document
309 is intended primarily for readers who will be implementing the
310 protocol and for those doing cryptographic analysis of it. The
311 specification has been written with this in mind, and it is intended
312 to reflect the needs of those two groups. For that reason, many of
313 the algorithm-dependent data structures and rules are included in the
314 body of the text (as opposed to in an appendix), providing easier
315 access to them.
317 This document is not intended to supply any details of service
318 definition or of interface definition, although it does cover select
319 areas of policy as they are required for the maintenance of solid
320 security.
322 4. Presentation Language
324 This document deals with the formatting of data in an external
325 representation. The following very basic and somewhat casually
326 defined presentation syntax will be used. The syntax draws from
327 several sources in its structure. Although it resembles the
328 programming language "C" in its syntax and XDR [XDR] in both its
329 syntax and intent, it would be risky to draw too many parallels. The
330 purpose of this presentation language is to document TLS only; it has
331 no general application beyond that particular goal.
338 Dierks & Rescorla Standards Track [Page 6]
339 \f
340 RFC 4346 The TLS Protocol April 2006
343 4.1. Basic Block Size
345 The representation of all data items is explicitly specified. The
346 basic data block size is one byte (i.e., 8 bits). Multiple byte data
347 items are concatenations of bytes, from left to right, from top to
348 bottom. From the bytestream, a multi-byte item (a numeric in the
349 example) is formed (using C notation) by:
351 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
352 ... | byte[n-1];
354 This byte ordering for multi-byte values is the commonplace network
355 byte order or big endian format.
357 4.2. Miscellaneous
359 Comments begin with "/*" and end with "*/".
361 Optional components are denoted by enclosing them in "[[ ]]" double
362 brackets.
364 Single-byte entities containing uninterpreted data are of type
365 opaque.
367 4.3. Vectors
369 A vector (single dimensioned array) is a stream of homogeneous data
370 elements. The size of the vector may be specified at documentation
371 time or left unspecified until runtime. In either case, the length
372 declares the number of bytes, not the number of elements, in the
373 vector. The syntax for specifying a new type, T', that is a fixed-
374 length vector of type T is
376 T T'[n];
378 Here, T' occupies n bytes in the data stream, where n is a multiple
379 of the size of T. The length of the vector is not included in the
380 encoded stream.
382 In the following example, Datum is defined to be three consecutive
383 bytes that the protocol does not interpret, while Data is three
384 consecutive Datum, consuming a total of nine bytes.
386 opaque Datum[3]; /* three uninterpreted bytes */
387 Datum Data[9]; /* 3 consecutive 3 byte vectors */
389 Variable-length vectors are defined by specifying a subrange of legal
390 lengths, inclusively, using the notation <floor..ceiling>. When
394 Dierks & Rescorla Standards Track [Page 7]
395 \f
396 RFC 4346 The TLS Protocol April 2006
399 these are encoded, the actual length precedes the vector's contents
400 in the byte stream. The length will be in the form of a number
401 consuming as many bytes as required to hold the vector's specified
402 maximum (ceiling) length. A variable-length vector with an actual
403 length field of zero is referred to as an empty vector.
405 T T'<floor..ceiling>;
407 In the following example, mandatory is a vector that must contain
408 between 300 and 400 bytes of type opaque. It can never be empty.
409 The actual length field consumes two bytes, a uint16, sufficient to
410 represent the value 400 (see Section 4.4). On the other hand, longer
411 can represent up to 800 bytes of data, or 400 uint16 elements, and it
412 may be empty. Its encoding will include a two-byte actual length
413 field prepended to the vector. The length of an encoded vector must
414 be an even multiple of the length of a single element (for example, a
415 17-byte vector of uint16 would be illegal).
417 opaque mandatory<300..400>;
418 /* length field is 2 bytes, cannot be empty */
419 uint16 longer<0..800>;
420 /* zero to 400 16-bit unsigned integers */
422 4.4. Numbers
424 The basic numeric data type is an unsigned byte (uint8). All larger
425 numeric data types are formed from fixed-length series of bytes
426 concatenated as described in Section 4.1 and are also unsigned. The
427 following numeric types are predefined.
429 uint8 uint16[2];
430 uint8 uint24[3];
431 uint8 uint32[4];
432 uint8 uint64[8];
434 All values, here and elsewhere in the specification, are stored in
435 "network" or "big-endian" order; the uint32 represented by the hex
436 bytes 01 02 03 04 is equivalent to the decimal value 16909060.
438 4.5. Enumerateds
440 An additional sparse data type is available called enum. A field of
441 type enum can only assume the values declared in the definition.
442 Each definition is a different type. Only enumerateds of the same
443 type may be assigned or compared. Every element of an enumerated
444 must be assigned a value, as demonstrated in the following example.
445 Since the elements of the enumerated are not ordered, they can be
446 assigned any unique value, in any order.
450 Dierks & Rescorla Standards Track [Page 8]
451 \f
452 RFC 4346 The TLS Protocol April 2006
455 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
457 Enumerateds occupy as much space in the byte stream as would its
458 maximal defined ordinal value. The following definition would cause
459 one byte to be used to carry fields of type Color.
461 enum { red(3), blue(5), white(7) } Color;
463 One may optionally specify a value without its associated tag to
464 force the width definition without defining a superfluous element.
465 In the following example, Taste will consume two bytes in the data
466 stream but can only assume the values 1, 2, or 4.
468 enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
470 The names of the elements of an enumeration are scoped within the
471 defined type. In the first example, a fully qualified reference to
472 the second element of the enumeration would be Color.blue. Such
473 qualification is not required if the target of the assignment is well
474 specified.
476 Color color = Color.blue; /* overspecified, legal */
477 Color color = blue; /* correct, type implicit */
479 For enumerateds that are never converted to external representation,
480 the numerical information may be omitted.
482 enum { low, medium, high } Amount;
484 4.6. Constructed Types
486 Structure types may be constructed from primitive types for
487 convenience. Each specification declares a new, unique type. The
488 syntax for definition is much like that of C.
490 struct {
491 T1 f1;
492 T2 f2;
493 ...
494 Tn fn;
495 } [[T]];
497 The fields within a structure may be qualified using the type's name,
498 with a syntax much like that available for enumerateds. For example,
499 T.f2 refers to the second field of the previous declaration.
500 Structure definitions may be embedded.
506 Dierks & Rescorla Standards Track [Page 9]
507 \f
508 RFC 4346 The TLS Protocol April 2006
511 4.6.1. Variants
513 Defined structures may have variants based on some knowledge that is
514 available within the environment. The selector must be an enumerated
515 type that defines the possible variants the structure defines. There
516 must be a case arm for every element of the enumeration declared in
517 the select. The body of the variant structure may be given a label
518 for reference. The mechanism by which the variant is selected at
519 runtime is not prescribed by the presentation language.
521 struct {
522 T1 f1;
523 T2 f2;
524 ....
525 Tn fn;
526 select (E) {
527 case e1: Te1;
528 case e2: Te2;
529 ....
530 case en: Ten;
531 } [[fv]];
532 } [[Tv]];
534 For example:
536 enum { apple, orange } VariantTag;
537 struct {
538 uint16 number;
539 opaque string<0..10>; /* variable length */
540 } V1;
541 struct {
542 uint32 number;
543 opaque string[10]; /* fixed length */
544 } V2;
545 struct {
546 select (VariantTag) { /* value of selector is implicit */
547 case apple: V1; /* VariantBody, tag = apple */
548 case orange: V2; /* VariantBody, tag = orange */
549 } variant_body; /* optional label on variant */
550 } VariantRecord;
552 Variant structures may be qualified (narrowed) by specifying a value
553 for the selector prior to the type. For example, an
555 orange VariantRecord
557 is a narrowed type of a VariantRecord containing a variant_body of
558 type V2.
562 Dierks & Rescorla Standards Track [Page 10]
563 \f
564 RFC 4346 The TLS Protocol April 2006
567 4.7. Cryptographic Attributes
569 The four cryptographic operations digital signing, stream cipher
570 encryption, block cipher encryption, and public key encryption are
571 designated digitally-signed, stream-ciphered, block-ciphered, and
572 public-key-encrypted, respectively. A field's cryptographic
573 processing is specified by prepending an appropriate key word
574 designation before the field's type specification. Cryptographic
575 keys are implied by the current session state (see Section 6.1).
577 In digital signing, one-way hash functions are used as input for a
578 signing algorithm. A digitally-signed element is encoded as an
579 opaque vector <0..2^16-1>, where the length is specified by the
580 signing algorithm and key.
582 In RSA signing, a 36-byte structure of two hashes (one SHA and one
583 MD5) is signed (encrypted with the private key). It is encoded with
584 PKCS #1 block type 1, as described in [PKCS1A].
586 Note: The standard reference for PKCS#1 is now RFC 3447 [PKCS1B].
587 However, to minimize differences with TLS 1.0 text, we are
588 using the terminology of RFC 2313 [PKCS1A].
590 In DSS, the 20 bytes of the SHA hash are run directly through the
591 Digital Signing Algorithm with no additional hashing. This produces
592 two values, r and s. The DSS signature is an opaque vector, as
593 above, the contents of which are the DER encoding of:
595 Dss-Sig-Value ::= SEQUENCE {
596 r INTEGER,
597 s INTEGER
598 }
600 In stream cipher encryption, the plaintext is exclusive-ORed with an
601 identical amount of output generated from a cryptographically secure
602 keyed pseudorandom number generator.
604 In block cipher encryption, every block of plaintext encrypts to a
605 block of ciphertext. All block cipher encryption is done in CBC
606 (Cipher Block Chaining) mode, and all items that are block-ciphered
607 will be an exact multiple of the cipher block length.
609 In public key encryption, a public key algorithm is used to encrypt
610 data in such a way that it can be decrypted only with the matching
611 private key. A public-key-encrypted element is encoded as an opaque
612 vector <0..2^16-1>, where the length is specified by the signing
613 algorithm and key.
618 Dierks & Rescorla Standards Track [Page 11]
619 \f
620 RFC 4346 The TLS Protocol April 2006
623 An RSA-encrypted value is encoded with PKCS #1 block type 2, as
624 described in [PKCS1A].
626 In the following example,
628 stream-ciphered struct {
629 uint8 field1;
630 uint8 field2;
631 digitally-signed opaque hash[20];
632 } UserType;
634 the contents of hash are used as input for the signing algorithm, and
635 then the entire structure is encrypted with a stream cipher. The
636 length of this structure, in bytes, would be equal to two bytes for
637 field1 and field2, plus two bytes for the length of the signature,
638 plus the length of the output of the signing algorithm. This is
639 known because the algorithm and key used for the signing are known
640 prior to encoding or decoding this structure.
642 4.8. Constants
644 Typed constants can be defined for purposes of specification by
645 declaring a symbol of the desired type and assigning values to it.
646 Under-specified types (opaque, variable length vectors, and
647 structures that contain opaque) cannot be assigned values. No fields
648 of a multi-element structure or vector may be elided.
650 For example:
652 struct {
653 uint8 f1;
654 uint8 f2;
655 } Example1;
657 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
659 5. HMAC and the Pseudorandom Function
661 A number of operations in the TLS record and handshake layer require
662 a keyed MAC; this is a secure digest of some data protected by a
663 secret. Forging the MAC is infeasible without knowledge of the MAC
664 secret. The construction we use for this operation is known as HMAC,
665 and is described in [HMAC].
667 HMAC can be used with a variety of different hash algorithms. TLS
668 uses it in the handshake with two different algorithms, MD5 and SHA-
669 1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
670 data). Additional hash algorithms can be defined by cipher suites
674 Dierks & Rescorla Standards Track [Page 12]
675 \f
676 RFC 4346 The TLS Protocol April 2006
679 and used to protect record data, but MD5 and SHA-1 are hard coded
680 into the description of the handshaking for this version of the
681 protocol.
683 In addition, a construction is required to do expansion of secrets
684 into blocks of data for the purposes of key generation or validation.
685 This pseudo-random function (PRF) takes as input a secret, a seed,
686 and an identifying label and produces an output of arbitrary length.
688 In order to make the PRF as secure as possible, it uses two hash
689 algorithms in a way that should guarantee its security if either
690 algorithm remains secure.
692 First, we define a data expansion function, P_hash(secret, data) that
693 uses a single hash function to expand a secret and seed into an
694 arbitrary quantity of output:
696 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
697 HMAC_hash(secret, A(2) + seed) +
698 HMAC_hash(secret, A(3) + seed) + ...
700 Where + indicates concatenation.
702 A() is defined as:
704 A(0) = seed
705 A(i) = HMAC_hash(secret, A(i-1))
707 P_hash can be iterated as many times as is necessary to produce the
708 required quantity of data. For example, if P_SHA-1 is being used to
709 create 64 bytes of data, it will have to be iterated 4 times (through
710 A(4)), creating 80 bytes of output data; the last 16 bytes of the
711 final iteration will then be discarded, leaving 64 bytes of output
712 data.
714 TLS's PRF is created by splitting the secret into two halves and
715 using one half to generate data with P_MD5 and the other half to
716 generate data with P_SHA-1, then exclusive-ORing the outputs of these
717 two expansion functions together.
719 S1 and S2 are the two halves of the secret, and each is the same
720 length. S1 is taken from the first half of the secret, S2 from the
721 second half. Their length is created by rounding up the length of
722 the overall secret, divided by two; thus, if the original secret is
723 an odd number of bytes long, the last byte of S1 will be the same as
724 the first byte of S2.
730 Dierks & Rescorla Standards Track [Page 13]
731 \f
732 RFC 4346 The TLS Protocol April 2006
735 L_S = length in bytes of secret;
736 L_S1 = L_S2 = ceil(L_S / 2);
739 The secret is partitioned into two halves (with the possibility of
740 one shared byte) as described above, S1 taking the first L_S1 bytes,
741 and S2 the last L_S2 bytes.
743 The PRF is then defined as the result of mixing the two pseudorandom
744 streams by exclusive-ORing them together.
746 PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
747 P_SHA-1(S2, label + seed);
749 The label is an ASCII string. It should be included in the exact
750 form it is given without a length byte or trailing null character.
751 For example, the label "slithy toves" would be processed by hashing
752 the following bytes:
754 73 6C 69 74 68 79 20 74 6F 76 65 73
756 Note that because MD5 produces 16-byte outputs and SHA-1 produces
757 20-byte outputs, the boundaries of their internal iterations will not
758 be aligned. Generating an 80-byte output will require that P_MD5
759 iterate through A(5), while P_SHA-1 will only iterate through A(4).
761 6. The TLS Record Protocol
763 The TLS Record Protocol is a layered protocol. At each layer,
764 messages may include fields for length, description, and content.
765 The Record Protocol takes messages to be transmitted, fragments the
766 data into manageable blocks, optionally compresses the data, applies
767 a MAC, encrypts, and transmits the result. Received data is
768 decrypted, verified, decompressed, reassembled, and then delivered to
769 higher-level clients.
771 Four record protocol clients are described in this document: the
772 handshake protocol, the alert protocol, the change cipher spec
773 protocol, and the application data protocol. In order to allow
774 extension of the TLS protocol, additional record types can be
775 supported by the record protocol. Any new record types SHOULD
776 allocate type values immediately beyond the ContentType values for
777 the four record types described here (see Appendix A.1). All such
778 values must be defined by RFC 2434 Standards Action. See Section 11
779 for IANA Considerations for ContentType values.
781 If a TLS implementation receives a record type it does not
782 understand, it SHOULD just ignore it. Any protocol designed for use
786 Dierks & Rescorla Standards Track [Page 14]
787 \f
788 RFC 4346 The TLS Protocol April 2006
791 over TLS MUST be carefully designed to deal with all possible attacks
792 against it. Note that because the type and length of a record are
793 not protected by encryption, care SHOULD be taken to minimize the
794 value of traffic analysis of these values.
796 6.1. Connection States
798 A TLS connection state is the operating environment of the TLS Record
799 Protocol. It specifies a compression algorithm, and encryption
800 algorithm, and a MAC algorithm. In addition, the parameters for
801 these algorithms are known: the MAC secret and the bulk encryption
802 keys for the connection in both the read and the write directions.
803 Logically, there are always four connection states outstanding: the
804 current read and write states, and the pending read and write states.
805 All records are processed under the current read and write states.
806 The security parameters for the pending states can be set by the TLS
807 Handshake Protocol, and the Change Cipher Spec can selectively make
808 either of the pending states current, in which case the appropriate
809 current state is disposed of and replaced with the pending state; the
810 pending state is then reinitialized to an empty state. It is illegal
811 to make a state that has not been initialized with security
812 parameters a current state. The initial current state always
813 specifies that no encryption, compression, or MAC will be used.
815 The security parameters for a TLS Connection read and write state are
816 set by providing the following values:
818 connection end
819 Whether this entity is considered the "client" or the "server" in
820 this connection.
822 bulk encryption algorithm
823 An algorithm to be used for bulk encryption. This specification
824 includes the key size of this algorithm, how much of that key is
825 secret, whether it is a block or stream cipher, and the block size
826 of the cipher (if appropriate).
828 MAC algorithm
829 An algorithm to be used for message authentication. This
830 specification includes the size of the hash returned by the MAC
831 algorithm.
833 compression algorithm
834 An algorithm to be used for data compression. This specification
835 must include all information the algorithm requires compression.
837 master secret
838 A 48-byte secret shared between the two peers in the connection.
842 Dierks & Rescorla Standards Track [Page 15]
843 \f
844 RFC 4346 The TLS Protocol April 2006
847 client random
848 A 32-byte value provided by the client.
850 server random
851 A 32-byte value provided by the server.
853 These parameters are defined in the presentation language as:
855 enum { server, client } ConnectionEnd;
857 enum { null, rc4, rc2, des, 3des, des40, idea, aes }
858 BulkCipherAlgorithm;
860 enum { stream, block } CipherType;
862 enum { null, md5, sha } MACAlgorithm;
864 enum { null(0), (255) } CompressionMethod;
866 /* The algorithms specified in CompressionMethod,
867 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
869 struct {
870 ConnectionEnd entity;
871 BulkCipherAlgorithm bulk_cipher_algorithm;
872 CipherType cipher_type;
873 uint8 key_size;
874 uint8 key_material_length;
875 MACAlgorithm mac_algorithm;
876 uint8 hash_size;
877 CompressionMethod compression_algorithm;
878 opaque master_secret[48];
879 opaque client_random[32];
880 opaque server_random[32];
881 } SecurityParameters;
883 The record layer will use the security parameters to generate the
884 following four items:
886 client write MAC secret
887 server write MAC secret
888 client write key
889 server write key
891 The client write parameters are used by the server when receiving and
892 processing records and vice-versa. The algorithm used for generating
893 these items from the security parameters is described in Section 6.3.
898 Dierks & Rescorla Standards Track [Page 16]
899 \f
900 RFC 4346 The TLS Protocol April 2006
903 Once the security parameters have been set and the keys have been
904 generated, the connection states can be instantiated by making them
905 the current states. These current states MUST be updated for each
906 record processed. Each connection state includes the following
907 elements:
909 compression state
910 The current state of the compression algorithm.
912 cipher state
913 The current state of the encryption algorithm. This will consist
914 of the scheduled key for that connection. For stream ciphers,
915 this will also contain whatever state information is necessary to
916 allow the stream to continue to encrypt or decrypt data.
918 MAC secret
919 The MAC secret for this connection, as generated above.
921 sequence number
922 Each connection state contains a sequence number, which is
923 maintained separately for read and write states. The sequence
924 number MUST be set to zero whenever a connection state is made the
925 active state. Sequence numbers are of type uint64 and may not
926 exceed 2^64-1. Sequence numbers do not wrap. If a TLS
927 implementation would need to wrap a sequence number, it must
928 renegotiate instead. A sequence number is incremented after each
929 record: specifically, the first record transmitted under a
930 particular connection state MUST use sequence number 0.
932 6.2. Record layer
934 The TLS Record Layer receives uninterpreted data from higher layers
935 in non-empty blocks of arbitrary size.
937 6.2.1. Fragmentation
939 The record layer fragments information blocks into TLSPlaintext
940 records carrying data in chunks of 2^14 bytes or less. Client
941 message boundaries are not preserved in the record layer (i.e.,
942 multiple client messages of the same ContentType MAY be coalesced
943 into a single TLSPlaintext record, or a single message MAY be
944 fragmented across several records).
954 Dierks & Rescorla Standards Track [Page 17]
955 \f
956 RFC 4346 The TLS Protocol April 2006
959 struct {
960 uint8 major, minor;
961 } ProtocolVersion;
963 enum {
964 change_cipher_spec(20), alert(21), handshake(22),
965 application_data(23), (255)
966 } ContentType;
968 struct {
969 ContentType type;
970 ProtocolVersion version;
971 uint16 length;
972 opaque fragment[TLSPlaintext.length];
973 } TLSPlaintext;
975 type
976 The higher-level protocol used to process the enclosed fragment.
978 version
979 The version of the protocol being employed. This document
980 describes TLS Version 1.1, which uses the version { 3, 2 }. The
981 version value 3.2 is historical: TLS version 1.1 is a minor
982 modification to the TLS 1.0 protocol, which was itself a minor
983 modification to the SSL 3.0 protocol, which bears the version
984 value 3.0. (See Appendix A.1.)
986 length
987 The length (in bytes) of the following TLSPlaintext.fragment. The
988 length should not exceed 2^14.
990 fragment
991 The application data. This data is transparent and is treated as
992 an independent block to be dealt with by the higher-level protocol
993 specified by the type field.
995 Note: Data of different TLS Record layer content types MAY be
996 interleaved. Application data is generally of lower precedence for
997 transmission than other content types. However, records MUST be
998 delivered to the network in the same order as they are protected by
999 the record layer. Recipients MUST receive and process interleaved
1000 application layer traffic during handshakes subsequent to the first
1001 one on a connection.
1010 Dierks & Rescorla Standards Track [Page 18]
1011 \f
1012 RFC 4346 The TLS Protocol April 2006
1015 6.2.2. Record Compression and Decompression
1017 All records are compressed using the compression algorithm defined in
1018 the current session state. There is always an active compression
1019 algorithm; however, initially it is defined as
1020 CompressionMethod.null. The compression algorithm translates a
1021 TLSPlaintext structure into a TLSCompressed structure. Compression
1022 functions are initialized with default state information whenever a
1023 connection state is made active.
1025 Compression must be lossless and may not increase the content length
1026 by more than 1024 bytes. If the decompression function encounters a
1027 TLSCompressed.fragment that would decompress to a length in excess of
1028 2^14 bytes, it should report a fatal decompression failure error.
1030 struct {
1031 ContentType type; /* same as TLSPlaintext.type */
1032 ProtocolVersion version;/* same as TLSPlaintext.version */
1033 uint16 length;
1034 opaque fragment[TLSCompressed.length];
1035 } TLSCompressed;
1037 length
1038 The length (in bytes) of the following TLSCompressed.fragment.
1039 The length should not exceed 2^14 + 1024.
1041 fragment
1042 The compressed form of TLSPlaintext.fragment.
1044 Note: A CompressionMethod.null operation is an identity operation; no
1045 fields are altered.
1047 Implementation note: Decompression functions are responsible for
1048 ensuring that messages cannot cause internal
1049 buffer overflows.
1051 6.2.3. Record Payload Protection
1053 The encryption and MAC functions translate a TLSCompressed structure
1054 into a TLSCiphertext. The decryption functions reverse the process.
1055 The MAC of the record also includes a sequence number so that
1056 missing, extra, or repeated messages are detectable.
1066 Dierks & Rescorla Standards Track [Page 19]
1067 \f
1068 RFC 4346 The TLS Protocol April 2006
1071 struct {
1072 ContentType type;
1073 ProtocolVersion version;
1074 uint16 length;
1075 select (CipherSpec.cipher_type) {
1076 case stream: GenericStreamCipher;
1077 case block: GenericBlockCipher;
1078 } fragment;
1079 } TLSCiphertext;
1081 type
1082 The type field is identical to TLSCompressed.type.
1084 version
1085 The version field is identical to TLSCompressed.version.
1087 length
1088 The length (in bytes) of the following TLSCiphertext.fragment.
1089 The length may not exceed 2^14 + 2048.
1091 fragment
1092 The encrypted form of TLSCompressed.fragment, with the MAC.
1094 6.2.3.1. Null or Standard Stream Cipher
1096 Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
1097 convert TLSCompressed.fragment structures to and from stream
1098 TLSCiphertext.fragment structures.
1100 stream-ciphered struct {
1101 opaque content[TLSCompressed.length];
1102 opaque MAC[CipherSpec.hash_size];
1103 } GenericStreamCipher;
1105 The MAC is generated as:
1107 HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
1108 TLSCompressed.version + TLSCompressed.length +
1109 TLSCompressed.fragment));
1111 where "+" denotes concatenation.
1113 seq_num
1114 The sequence number for this record.
1116 hash
1117 The hashing algorithm specified by
1118 SecurityParameters.mac_algorithm.
1122 Dierks & Rescorla Standards Track [Page 20]
1123 \f
1124 RFC 4346 The TLS Protocol April 2006
1127 Note that the MAC is computed before encryption. The stream cipher
1128 encrypts the entire block, including the MAC. For stream ciphers
1129 that do not use a synchronization vector (such as RC4), the stream
1130 cipher state from the end of one record is simply used on the
1131 subsequent packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL,
1132 encryption consists of the identity operation (i.e., the data is not
1133 encrypted, and the MAC size is zero, implying that no MAC is used).
1134 TLSCiphertext.length is TLSCompressed.length plus
1135 CipherSpec.hash_size.
1137 6.2.3.2. CBC Block Cipher
1139 For block ciphers (such as RC2, DES, or AES), the encryption and MAC
1140 functions convert TLSCompressed.fragment structures to and from block
1141 TLSCiphertext.fragment structures.
1143 block-ciphered struct {
1144 opaque IV[CipherSpec.block_length];
1145 opaque content[TLSCompressed.length];
1146 opaque MAC[CipherSpec.hash_size];
1147 uint8 padding[GenericBlockCipher.padding_length];
1148 uint8 padding_length;
1149 } GenericBlockCipher;
1151 The MAC is generated as described in Section 6.2.3.1.
1153 IV
1154 Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
1155 IV in order to prevent the attacks described by [CBCATT]. We
1156 recommend the following equivalently strong procedures. For
1157 clarity we use the following notation.
1159 IV
1160 The transmitted value of the IV field in the GenericBlockCipher
1161 structure.
1163 CBC residue
1164 The last ciphertext block of the previous record.
1166 mask
1167 The actual value that the cipher XORs with the plaintext prior
1168 to encryption of the first cipher block of the record.
1170 In prior versions of TLS, there was no IV field and the CBC
1171 residue and mask were one and the same. See Sections 6.1,
1172 6.2.3.2, and 6.3, of [TLS1.0] for details of TLS 1.0 IV handling.
1178 Dierks & Rescorla Standards Track [Page 21]
1179 \f
1180 RFC 4346 The TLS Protocol April 2006
1183 One of the following two algorithms SHOULD be used to generate the
1184 per-record IV:
1186 (1) Generate a cryptographically strong random string R of length
1187 CipherSpec.block_length. Place R in the IV field. Set the
1188 mask to R. Thus, the first cipher block will be encrypted as
1189 E(R XOR Data).
1191 (2) Generate a cryptographically strong random number R of length
1192 CipherSpec.block_length and prepend it to the plaintext prior
1193 to encryption. In this case either:
1195 (a) The cipher may use a fixed mask such as zero.
1196 (b) The CBC residue from the previous record may be used as
1197 the mask. This preserves maximum code compatibility with
1198 TLS 1.0 and SSL 3. It also has the advantage that it does
1199 not require the ability to quickly reset the IV, which is
1200 known to be a problem on some systems.
1202 In either (2)(a) or (2)(b) the data (R || data) is fed into
1203 the encryption process. The first cipher block (containing
1204 E(mask XOR R) is placed in the IV field. The first block of
1205 content contains E(IV XOR data).
1207 The following alternative procedure MAY be used; however, it has
1208 not been demonstrated to be as cryptographically strong as the
1209 above procedures. The sender prepends a fixed block F to the
1210 plaintext (or, alternatively, a block generated with a weak PRNG).
1211 He then encrypts as in (2), above, using the CBC residue from the
1212 previous block as the mask for the prepended block. Note that in
1213 this case the mask for the first record transmitted by the
1214 application (the Finished) MUST be generated using a
1215 cryptographically strong PRNG.
1217 The decryption operation for all three alternatives is the same.
1218 The receiver decrypts the entire GenericBlockCipher structure and
1219 then discards the first cipher block, corresponding to the IV
1220 component.
1222 padding
1223 Padding that is added to force the length of the plaintext to be
1224 an integral multiple of the block cipher's block length. The
1225 padding MAY be any length up to 255 bytes, as long as it results
1226 in the TLSCiphertext.length being an integral multiple of the
1227 block length. Lengths longer than necessary might be desirable to
1228 frustrate attacks on a protocol that are based on analysis of the
1229 lengths of exchanged messages. Each uint8 in the padding data
1230 vector MUST be filled with the padding length value. The receiver
1234 Dierks & Rescorla Standards Track [Page 22]
1235 \f
1236 RFC 4346 The TLS Protocol April 2006
1239 MUST check this padding and SHOULD use the bad_record_mac alert to
1240 indicate padding errors.
1242 padding_length
1243 The padding length MUST be such that the total size of the
1244 GenericBlockCipher structure is a multiple of the cipher's block
1245 length. Legal values range from zero to 255, inclusive. This
1246 length specifies the length of the padding field exclusive of the
1247 padding_length field itself.
1249 The encrypted data length (TLSCiphertext.length) is one more than the
1250 sum of CipherSpec.block_length, TLSCompressed.length,
1251 CipherSpec.hash_size, and padding_length.
1253 Example: If the block length is 8 bytes, the content length
1254 (TLSCompressed.length) is 61 bytes, and the MAC length is 20
1255 bytes, then the length before padding is 82 bytes (this does
1256 not include the IV, which may or may not be encrypted, as
1257 discussed above). Thus, the padding length modulo 8 must be
1258 equal to 6 in order to make the total length an even
1259 multiple of 8 bytes (the block length). The padding length
1260 can be 6, 14, 22, and so on, through 254. If the padding
1261 length were the minimum necessary, 6, the padding would be 6
1262 bytes, each containing the value 6. Thus, the last 8 octets
1263 of the GenericBlockCipher before block encryption would be
1264 xx 06 06 06 06 06 06 06, where xx is the last octet of the
1265 MAC.
1267 Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
1268 critical that the entire plaintext of the record be known
1269 before any ciphertext is transmitted. Otherwise, it is
1270 possible for the attacker to mount the attack described in
1271 [CBCATT].
1273 Implementation Note: Canvel et al. [CBCTIME] have demonstrated a
1274 timing attack on CBC padding based on the time
1275 required to compute the MAC. In order to defend
1276 against this attack, implementations MUST ensure
1277 that record processing time is essentially the
1278 same whether or not the padding is correct. In
1279 general, the best way to do this is to compute
1280 the MAC even if the padding is incorrect, and
1281 only then reject the packet. For instance, if
1282 the pad appears to be incorrect, the
1283 implementation might assume a zero-length pad
1284 and then compute the MAC. This leaves a small
1285 timing channel, since MAC performance depends to
1286 some extent on the size of the data fragment,
1290 Dierks & Rescorla Standards Track [Page 23]
1291 \f
1292 RFC 4346 The TLS Protocol April 2006
1295 but it is not believed to be large enough to be
1296 exploitable, due to the large block size of
1297 existing MACs and the small size of the timing
1298 signal.
1300 6.3. Key Calculation
1302 The Record Protocol requires an algorithm to generate keys, and MAC
1303 secrets from the security parameters provided by the handshake
1304 protocol.
1306 The master secret is hashed into a sequence of secure bytes, which
1307 are assigned to the MAC secrets and keys required by the current
1308 connection state (see Appendix A.6). CipherSpecs require a client
1309 write MAC secret, a server write MAC secret, a client write key, and
1310 a server write key, each of which is generated from the master secret
1311 in that order. Unused values are empty.
1313 When keys and MAC secrets are generated, the master secret is used as
1314 an entropy source.
1316 To generate the key material, compute
1318 key_block = PRF(SecurityParameters.master_secret,
1319 "key expansion",
1320 SecurityParameters.server_random +
1321 SecurityParameters.client_random);
1323 until enough output has been generated. Then the key_block is
1324 partitioned as follows:
1326 client_write_MAC_secret[SecurityParameters.hash_size]
1327 server_write_MAC_secret[SecurityParameters.hash_size]
1328 client_write_key[SecurityParameters.key_material_length]
1329 server_write_key[SecurityParameters.key_material_length]
1331 Implementation note: The currently defined cipher suite that requires
1332 the most material is AES_256_CBC_SHA, defined in [TLSAES]. It
1333 requires 2 x 32 byte keys, 2 x 20 byte MAC secrets, and 2 x 16 byte
1334 Initialization Vectors, for a total of 136 bytes of key material.
1336 7. The TLS Handshaking Protocols
1338 TLS has three subprotocols that are used to allow peers to agree upon
1339 security parameters for the record layer, to authenticate themselves,
1340 to instantiate negotiated security parameters, and to report error
1341 conditions to each other.
1346 Dierks & Rescorla Standards Track [Page 24]
1347 \f
1348 RFC 4346 The TLS Protocol April 2006
1351 The Handshake Protocol is responsible for negotiating a session,
1352 which consists of the following items:
1354 session identifier
1355 An arbitrary byte sequence chosen by the server to identify an
1356 active or resumable session state.
1358 peer certificate
1359 X509v3 [X509] certificate of the peer. This element of the state
1360 may be null.
1362 compression method
1363 The algorithm used to compress data prior to encryption.
1365 cipher spec
1366 Specifies the bulk data encryption algorithm (such as null, DES,
1367 etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
1368 cryptographic attributes such as the hash_size. (See Appendix A.6
1369 for formal definition.)
1371 master secret
1372 48-byte secret shared between the client and server.
1374 is resumable
1375 A flag indicating whether the session can be used to initiate new
1376 connections.
1378 These items are then used to create security parameters for use by
1379 the Record Layer when protecting application data. Many connections
1380 can be instantiated using the same session through the resumption
1381 feature of the TLS Handshake Protocol.
1383 7.1. Change Cipher Spec Protocol
1385 The change cipher spec protocol exists to signal transitions in
1386 ciphering strategies. The protocol consists of a single message,
1387 which is encrypted and compressed under the current (not the pending)
1388 connection state. The message consists of a single byte of value 1.
1390 struct {
1391 enum { change_cipher_spec(1), (255) } type;
1392 } ChangeCipherSpec;
1394 The change cipher spec message is sent by both the client and the
1395 server to notify the receiving party that subsequent records will be
1396 protected under the newly negotiated CipherSpec and keys. Reception
1397 of this message causes the receiver to instruct the Record Layer to
1398 immediately copy the read pending state into the read current state.
1402 Dierks & Rescorla Standards Track [Page 25]
1403 \f
1404 RFC 4346 The TLS Protocol April 2006
1407 Immediately after sending this message, the sender MUST instruct the
1408 record layer to make the write pending state the write active state.
1409 (See Section 6.1.) The change cipher spec message is sent during the
1410 handshake after the security parameters have been agreed upon, but
1411 before the verifying finished message is sent (see Section 7.4.9).
1413 Note: If a rehandshake occurs while data is flowing on a connection,
1414 the communicating parties may continue to send data using the
1415 old CipherSpec. However, once the ChangeCipherSpec has been
1416 sent, the new CipherSpec MUST be used. The first side to send
1417 the ChangeCipherSpec does not know that the other side has
1418 finished computing the new keying material (e.g., if it has to
1419 perform a time consuming public key operation). Thus, a small
1420 window of time, during which the recipient must buffer the
1421 data, MAY exist. In practice, with modern machines this
1422 interval is likely to be fairly short.
1424 7.2. Alert Protocol
1426 One of the content types supported by the TLS Record layer is
1427 the alert type. Alert messages convey the severity of the
1428 message and a description of the alert. Alert messages with a
1429 level of fatal result in the immediate termination of the
1430 connection. In this case, other connections corresponding to
1431 the session may continue, but the session identifier MUST be
1432 invalidated, preventing the failed session from being used to
1433 establish new connections. Like other messages, alert messages
1434 are encrypted and compressed, as specified by the current
1435 connection state.
1437 enum { warning(1), fatal(2), (255) } AlertLevel;
1439 enum {
1440 close_notify(0),
1441 unexpected_message(10),
1442 bad_record_mac(20),
1443 decryption_failed(21),
1444 record_overflow(22),
1445 decompression_failure(30),
1446 handshake_failure(40),
1447 no_certificate_RESERVED (41),
1448 bad_certificate(42),
1449 unsupported_certificate(43),
1450 certificate_revoked(44),
1451 certificate_expired(45),
1452 certificate_unknown(46),
1453 illegal_parameter(47),
1454 unknown_ca(48),
1458 Dierks & Rescorla Standards Track [Page 26]
1459 \f
1460 RFC 4346 The TLS Protocol April 2006
1463 access_denied(49),
1464 decode_error(50),
1465 decrypt_error(51),
1466 export_restriction_RESERVED(60),
1467 protocol_version(70),
1468 insufficient_security(71),
1469 internal_error(80),
1470 user_canceled(90),
1471 no_renegotiation(100),
1472 (255)
1473 } AlertDescription;
1475 struct {
1476 AlertLevel level;
1477 AlertDescription description;
1478 } Alert;
1480 7.2.1. Closure Alerts
1482 The client and the server must share knowledge that the connection is
1483 ending in order to avoid a truncation attack. Either party may
1484 initiate the exchange of closing messages.
1486 close_notify
1487 This message notifies the recipient that the sender will not send
1488 any more messages on this connection. Note that as of TLS 1.1,
1489 failure to properly close a connection no longer requires that a
1490 session not be resumed. This is a change from TLS 1.0 to conform
1491 with widespread implementation practice.
1493 Either party may initiate a close by sending a close_notify alert.
1494 Any data received after a closure alert is ignored.
1496 Unless some other fatal alert has been transmitted, each party is
1497 required to send a close_notify alert before closing the write side
1498 of the connection. The other party MUST respond with a close_notify
1499 alert of its own and close down the connection immediately,
1500 discarding any pending writes. It is not required for the initiator
1501 of the close to wait for the responding close_notify alert before
1502 closing the read side of the connection.
1504 If the application protocol using TLS provides that any data may be
1505 carried over the underlying transport after the TLS connection is
1506 closed, the TLS implementation must receive the responding
1507 close_notify alert before indicating to the application layer that
1508 the TLS connection has ended. If the application protocol will not
1509 transfer any additional data, but will only close the underlying
1510 transport connection, then the implementation MAY choose to close the
1514 Dierks & Rescorla Standards Track [Page 27]
1515 \f
1516 RFC 4346 The TLS Protocol April 2006
1519 transport without waiting for the responding close_notify. No part
1520 of this standard should be taken to dictate the manner in which a
1521 usage profile for TLS manages its data transport, including when
1522 connections are opened or closed.
1524 Note: It is assumed that closing a connection reliably delivers
1525 pending data before destroying the transport.
1527 7.2.2. Error Alerts
1529 Error handling in the TLS Handshake protocol is very simple. When an
1530 error is detected, the detecting party sends a message to the other
1531 party. Upon transmission or receipt of a fatal alert message, both
1532 parties immediately close the connection. Servers and clients MUST
1533 forget any session-identifiers, keys, and secrets associated with a
1534 failed connection. Thus, any connection terminated with a fatal
1535 alert MUST NOT be resumed. The following error alerts are defined:
1537 unexpected_message
1538 An inappropriate message was received. This alert is always fatal
1539 and should never be observed in communication between proper
1540 implementations.
1542 bad_record_mac
1543 This alert is returned if a record is received with an incorrect
1544 MAC. This alert also MUST be returned if an alert is sent because
1545 a TLSCiphertext decrypted in an invalid way: either it wasn't an
1546 even multiple of the block length, or its padding values, when
1547 checked, weren't correct. This message is always fatal.
1549 decryption_failed
1550 This alert MAY be returned if a TLSCiphertext decrypted in an
1551 invalid way: either it wasn't an even multiple of the block
1552 length, or its padding values, when checked, weren't correct.
1553 This message is always fatal.
1555 Note: Differentiating between bad_record_mac and decryption_failed
1556 alerts may permit certain attacks against CBC mode as used in
1557 TLS [CBCATT]. It is preferable to uniformly use the
1558 bad_record_mac alert to hide the specific type of the error.
1560 record_overflow
1561 A TLSCiphertext record was received that had a length more than
1562 2^14+2048 bytes, or a record decrypted to a TLSCompressed
1563 record with more than 2^14+1024 bytes. This message is always
1564 fatal.
1570 Dierks & Rescorla Standards Track [Page 28]
1571 \f
1572 RFC 4346 The TLS Protocol April 2006
1575 decompression_failure
1576 The decompression function received improper input (e.g., data
1577 that would expand to excessive length). This message is always
1578 fatal.
1580 handshake_failure
1581 Reception of a handshake_failure alert message indicates that
1582 the sender was unable to negotiate an acceptable set of
1583 security parameters given the options available. This is a
1584 fatal error.
1586 no_certificate_RESERVED
1587 This alert was used in SSLv3 but not in TLS. It should not be
1588 sent by compliant implementations.
1590 bad_certificate
1591 A certificate was corrupt, contained signatures that did not
1592 verify correctly, etc.
1594 unsupported_certificate
1595 A certificate was of an unsupported type.
1597 certificate_revoked
1598 A certificate was revoked by its signer.
1600 certificate_expired
1601 A certificate has expired or is not currently valid.
1603 certificate_unknown
1604 Some other (unspecified) issue arose in processing the
1605 certificate, rendering it unacceptable.
1607 illegal_parameter
1608 A field in the handshake was out of range or inconsistent with
1609 other fields. This is always fatal.
1611 unknown_ca
1612 A valid certificate chain or partial chain was received, but
1613 the certificate was not accepted because the CA certificate
1614 could not be located or couldn't be matched with a known,
1615 trusted CA. This message is always fatal.
1617 access_denied
1618 A valid certificate was received, but when access control was
1619 applied, the sender decided not to proceed with negotiation.
1620 This message is always fatal.
1626 Dierks & Rescorla Standards Track [Page 29]
1627 \f
1628 RFC 4346 The TLS Protocol April 2006
1631 decode_error
1632 A message could not be decoded because some field was out of
1633 the specified range or the length of the message was incorrect.
1634 This message is always fatal.
1636 decrypt_error
1637 A handshake cryptographic operation failed, including being
1638 unable to correctly verify a signature, decrypt a key exchange,
1639 or validate a finished message.
1641 export_restriction_RESERVED
1642 This alert was used in TLS 1.0 but not TLS 1.1.
1644 protocol_version
1645 The protocol version the client has attempted to negotiate is
1646 recognized but not supported. (For example, old protocol
1647 versions might be avoided for security reasons). This message
1648 is always fatal.
1650 insufficient_security
1651 Returned instead of handshake_failure when a negotiation has
1652 failed specifically because the server requires ciphers more
1653 secure than those supported by the client. This message is
1654 always fatal.
1656 internal_error
1657 An internal error unrelated to the peer or the correctness of
1658 the protocol (such as a memory allocation failure) makes it
1659 impossible to continue. This message is always fatal.
1661 user_canceled
1662 This handshake is being canceled for some reason unrelated to a
1663 protocol failure. If the user cancels an operation after the
1664 handshake is complete, just closing the connection by sending a
1665 close_notify is more appropriate. This alert should be
1666 followed by a close_notify. This message is generally a
1667 warning.
1669 no_renegotiation
1670 Sent by the client in response to a hello request or by the
1671 server in response to a client hello after initial handshaking.
1672 Either of these would normally lead to renegotiation; when that
1673 is not appropriate, the recipient should respond with this
1674 alert. At that point, the original requester can decide
1675 whether to proceed with the connection. One case where this
1676 would be appropriate is where a server has spawned a process to
1677 satisfy a request; the process might receive security
1678 parameters (key length, authentication, etc.) at startup and it
1682 Dierks & Rescorla Standards Track [Page 30]
1683 \f
1684 RFC 4346 The TLS Protocol April 2006
1687 might be difficult to communicate changes to these parameters
1688 after that point. This message is always a warning.
1690 For all errors where an alert level is not explicitly specified, the
1691 sending party MAY determine at its discretion whether this is a fatal
1692 error or not; if an alert with a level of warning is received, the
1693 receiving party MAY decide at its discretion whether to treat this as
1694 a fatal error or not. However, all messages that are transmitted
1695 with a level of fatal MUST be treated as fatal messages.
1697 New alert values MUST be defined by RFC 2434 Standards Action. See
1698 Section 11 for IANA Considerations for alert values.
1700 7.3. Handshake Protocol Overview
1702 The cryptographic parameters of the session state are produced by the
1703 TLS Handshake Protocol, which operates on top of the TLS Record
1704 Layer. When a TLS client and server first start communicating, they
1705 agree on a protocol version, select cryptographic algorithms,
1706 optionally authenticate each other, and use public-key encryption
1707 techniques to generate shared secrets.
1709 The TLS Handshake Protocol involves the following steps:
1711 - Exchange hello messages to agree on algorithms, exchange random
1712 values, and check for session resumption.
1714 - Exchange the necessary cryptographic parameters to allow the
1715 client and server to agree on a premaster secret.
1717 - Exchange certificates and cryptographic information to allow the
1718 client and server to authenticate themselves.
1720 - Generate a master secret from the premaster secret and exchanged
1721 random values.
1723 - Provide security parameters to the record layer.
1725 - Allow the client and server to verify that their peer has
1726 calculated the same security parameters and that the handshake
1727 occurred without tampering by an attacker.
1729 Note that higher layers should not be overly reliant on whether TLS
1730 always negotiates the strongest possible connection between two
1731 peers. There are a number of ways in which a man-in-the-middle
1732 attacker can attempt to make two entities drop down to the least
1733 secure method they support. The protocol has been designed to
1734 minimize this risk, but there are still attacks available. For
1738 Dierks & Rescorla Standards Track [Page 31]
1739 \f
1740 RFC 4346 The TLS Protocol April 2006
1743 example, an attacker could block access to the port a secure service
1744 runs on, or attempt to get the peers to negotiate an unauthenticated
1745 connection. The fundamental rule is that higher levels must be
1746 cognizant of what their security requirements are and never transmit
1747 information over a channel less secure than what they require. The
1748 TLS protocol is secure in that any cipher suite offers its promised
1749 level of security: if you negotiate 3DES with a 1024 bit RSA key
1750 exchange with a host whose certificate you have verified, you can
1751 expect to be that secure.
1753 However, one SHOULD never send data over a link encrypted with 40-bit
1754 security unless one feels that data is worth no more than the effort
1755 required to break that encryption.
1757 These goals are achieved by the handshake protocol, which can be
1758 summarized as follows: The client sends a client hello message to
1759 which the server must respond with a server hello message, or else a
1760 fatal error will occur and the connection will fail. The client
1761 hello and server hello are used to establish security enhancement
1762 capabilities between client and server. The client hello and server
1763 hello establish the following attributes: Protocol Version, Session
1764 ID, Cipher Suite, and Compression Method. Additionally, two random
1765 values are generated and exchanged: ClientHello.random and
1766 ServerHello.random.
1768 The actual key exchange uses up to four messages: the server
1769 certificate, the server key exchange, the client certificate, and the
1770 client key exchange. New key exchange methods can be created by
1771 specifying a format for these messages and by defining the use of the
1772 messages to allow the client and server to agree upon a shared
1773 secret. This secret MUST be quite long; currently defined key
1774 exchange methods exchange secrets that range from 48 to 128 bytes in
1775 length.
1777 Following the hello messages, the server will send its certificate,
1778 if it is to be authenticated. Additionally, a server key exchange
1779 message may be sent, if it is required (e.g., if the server has no
1780 certificate, or if its certificate is for signing only). If the
1781 server is authenticated, it may request a certificate from the
1782 client, if that is appropriate to the cipher suite selected. Next,
1783 the server will send the server hello done message, indicating that
1784 the hello-message phase of the handshake is complete. The server
1785 will then wait for a client response. If the server has sent a
1786 certificate request message, the client must send the certificate
1787 message. The client key exchange message is now sent, and the
1788 content of that message will depend on the public key algorithm
1789 selected between the client hello and the server hello. If the
1790 client has sent a certificate with signing ability, a digitally-
1794 Dierks & Rescorla Standards Track [Page 32]
1795 \f
1796 RFC 4346 The TLS Protocol April 2006
1799 signed certificate verify message is sent to explicitly verify the
1800 certificate.
1803 At this point, a change cipher spec message is sent by the client,
1804 and the client copies the pending Cipher Spec into the current Cipher
1805 Spec. The client then immediately sends the finished message under
1806 the new algorithms, keys, and secrets. In response, the server will
1807 send its own change cipher spec message, transfer the pending to the
1808 current Cipher Spec, and send its finished message under the new
1809 Cipher Spec. At this point, the handshake is complete, and the
1810 client and server may begin to exchange application layer data. (See
1811 flow chart below.) Application data MUST NOT be sent prior to the
1812 completion of the first handshake (before a cipher suite other
1813 TLS_NULL_WITH_NULL_NULL is established).
1815 Client Server
1817 ClientHello -------->
1818 ServerHello
1819 Certificate*
1820 ServerKeyExchange*
1821 CertificateRequest*
1822 <-------- ServerHelloDone
1823 Certificate*
1824 ClientKeyExchange
1825 CertificateVerify*
1826 [ChangeCipherSpec]
1827 Finished -------->
1828 [ChangeCipherSpec]
1829 <-------- Finished
1830 Application Data <-------> Application Data
1832 Fig. 1. Message flow for a full handshake
1834 * Indicates optional or situation-dependent messages that are not
1835 always sent.
1837 Note: To help avoid pipeline stalls, ChangeCipherSpec is an
1838 independent TLS Protocol content type, and is not actually a
1839 TLS handshake message.
1841 When the client and server decide to resume a previous session or
1842 duplicate an existing session (instead of negotiating new security
1843 parameters), the message flow is as follows:
1845 The client sends a ClientHello using the Session ID of the session to
1846 be resumed. The server then checks its session cache for a match.
1850 Dierks & Rescorla Standards Track [Page 33]
1851 \f
1852 RFC 4346 The TLS Protocol April 2006
1855 If a match is found, and the server is willing to re-establish the
1856 connection under the specified session state, it will send a
1857 ServerHello with the same Session ID value. At this point, both
1858 client and server MUST send change cipher spec messages and proceed
1859 directly to finished messages. Once the re-establishment is
1860 complete, the client and server MAY begin to exchange application
1861 layer data. (See flow chart below.) If a Session ID match is not
1862 found, the server generates a new session ID and the TLS client and
1863 server perform a full handshake.
1865 Client Server
1867 ClientHello -------->
1868 ServerHello
1869 [ChangeCipherSpec]
1870 <-------- Finished
1871 [ChangeCipherSpec]
1872 Finished -------->
1873 Application Data <-------> Application Data
1875 Fig. 2. Message flow for an abbreviated handshake
1877 The contents and significance of each message will be presented in
1878 detail in the following sections.
1880 7.4. Handshake Protocol
1882 The TLS Handshake Protocol is one of the defined higher-level clients
1883 of the TLS Record Protocol. This protocol is used to negotiate the
1884 secure attributes of a session. Handshake messages are supplied to
1885 the TLS Record Layer, where they are encapsulated within one or more
1886 TLSPlaintext structures, which are processed and transmitted as
1887 specified by the current active session state.
1889 enum {
1890 hello_request(0), client_hello(1), server_hello(2),
1891 certificate(11), server_key_exchange (12),
1892 certificate_request(13), server_hello_done(14),
1893 certificate_verify(15), client_key_exchange(16),
1894 finished(20), (255)
1895 } HandshakeType;
1897 struct {
1898 HandshakeType msg_type; /* handshake type */
1899 uint24 length; /* bytes in message */
1900 select (HandshakeType) {
1901 case hello_request: HelloRequest;
1902 case client_hello: ClientHello;
1906 Dierks & Rescorla Standards Track [Page 34]
1907 \f
1908 RFC 4346 The TLS Protocol April 2006
1911 case server_hello: ServerHello;
1912 case certificate: Certificate;
1913 case server_key_exchange: ServerKeyExchange;
1914 case certificate_request: CertificateRequest;
1915 case server_hello_done: ServerHelloDone;
1916 case certificate_verify: CertificateVerify;
1917 case client_key_exchange: ClientKeyExchange;
1918 case finished: Finished;
1919 } body;
1920 } Handshake;
1922 The handshake protocol messages are presented below in the order they
1923 MUST be sent; sending handshake messages in an unexpected order
1924 results in a fatal error. Unneeded handshake messages can be
1925 omitted, however. Note one exception to the ordering: the
1926 Certificate message is used twice in the handshake (from server to
1927 client, then from client to server), but is described only in its
1928 first position. The one message that is not bound by these ordering
1929 rules is the Hello Request message, which can be sent at any time,
1930 but which should be ignored by the client if it arrives in the middle
1931 of a handshake.
1933 New Handshake message type values MUST be defined via RFC 2434
1934 Standards Action. See Section 11 for IANA Considerations for these
1935 values.
1937 7.4.1. Hello Messages
1939 The hello phase messages are used to exchange security enhancement
1940 capabilities between the client and server. When a new session
1941 begins, the Record Layer's connection state encryption, hash, and
1942 compression algorithms are initialized to null. The current
1943 connection state is used for renegotiation messages.
1945 7.4.1.1. Hello request
1947 When this message will be sent:
1949 The hello request message MAY be sent by the server at any time.
1951 Meaning of this message:
1953 Hello request is a simple notification that the client should
1954 begin the negotiation process anew by sending a client hello
1955 message when convenient. This message will be ignored by the
1956 client if the client is currently negotiating a session. This
1957 message may be ignored by the client if it does not wish to
1958 renegotiate a session, or the client may, if it wishes, respond
1962 Dierks & Rescorla Standards Track [Page 35]
1963 \f
1964 RFC 4346 The TLS Protocol April 2006
1967 with a no_renegotiation alert. Since handshake messages are
1968 intended to have transmission precedence over application data, it
1969 is expected that the negotiation will begin before no more than a
1970 few records are received from the client. If the server sends a
1971 hello request but does not receive a client hello in response, it
1972 may close the connection with a fatal alert.
1974 After sending a hello request, servers SHOULD not repeat the
1975 request until the subsequent handshake negotiation is complete.
1977 Structure of this message:
1979 struct { } HelloRequest;
1981 Note: This message MUST NOT be included in the message hashes that
1982 are maintained throughout the handshake and used in the
1983 finished messages and the certificate verify message.
1985 7.4.1.2. Client Hello
1987 When this message will be sent:
1989 When a client first connects to a server it is required to send
1990 the client hello as its first message. The client can also send a
1991 client hello in response to a hello request or on its own
1992 initiative in order to renegotiate the security parameters in an
1993 existing connection.
1995 Structure of this message:
1997 The client hello message includes a random structure, which is
1998 used later in the protocol.
2000 struct {
2001 uint32 gmt_unix_time;
2002 opaque random_bytes[28];
2003 } Random;
2005 gmt_unix_time The current time and date in standard UNIX 32-bit
2006 format (seconds since the midnight starting Jan 1, 1970, GMT,
2007 ignoring leap seconds) according to the sender's internal clock.
2008 Clocks are not required to be set correctly by the basic TLS
2009 Protocol; higher-level or application protocols may define
2010 additional requirements.
2012 random_bytes
2013 28 bytes generated by a secure random number generator.
2018 Dierks & Rescorla Standards Track [Page 36]
2019 \f
2020 RFC 4346 The TLS Protocol April 2006
2023 The client hello message includes a variable-length session
2024 identifier. If not empty, the value identifies a session between the
2025 same client and server whose security parameters the client wishes to
2026 reuse. The session identifier MAY be from an earlier connection,
2027 from this connection, or from another currently active connection.
2028 The second option is useful if the client only wishes to update the
2029 random structures and derived values of a connection, and the third
2030 option makes it possible to establish several independent secure
2031 connections without repeating the full handshake protocol. These
2032 independent connections may occur sequentially or simultaneously; a
2033 SessionID becomes valid when the handshake negotiating it completes
2034 with the exchange of Finished messages and persists until it is
2035 removed due to aging or because a fatal error was encountered on a
2036 connection associated with the session. The actual contents of the
2037 SessionID are defined by the server.
2039 opaque SessionID<0..32>;
2041 Warning: Because the SessionID is transmitted without encryption or
2042 immediate MAC protection, servers MUST not place
2043 confidential information in session identifiers or let the
2044 contents of fake session identifiers cause any breach of
2045 security. (Note that the content of the handshake as a
2046 whole, including the SessionID, is protected by the Finished
2047 messages exchanged at the end of the handshake.)
2049 The CipherSuite list, passed from the client to the server in the
2050 client hello message, contains the combinations of cryptographic
2051 algorithms supported by the client in order of the client's
2052 preference (favorite choice first). Each CipherSuite defines a key
2053 exchange algorithm, a bulk encryption algorithm (including secret key
2054 length), and a MAC algorithm. The server will select a cipher suite
2055 or, if no acceptable choices are presented, return a handshake
2056 failure alert and close the connection.
2058 uint8 CipherSuite[2]; /* Cryptographic suite selector */
2060 The client hello includes a list of compression algorithms supported
2061 by the client, ordered according to the client's preference.
2074 Dierks & Rescorla Standards Track [Page 37]
2075 \f
2076 RFC 4346 The TLS Protocol April 2006
2079 enum { null(0), (255) } CompressionMethod;
2081 struct {
2082 ProtocolVersion client_version;
2083 Random random;
2084 SessionID session_id;
2085 CipherSuite cipher_suites<2..2^16-1>;
2086 CompressionMethod compression_methods<1..2^8-1>;
2087 } ClientHello;
2089 client_version
2090 The version of the TLS protocol by which the client wishes to
2091 communicate during this session. This SHOULD be the latest
2092 (highest valued) version supported by the client. For this
2093 version of the specification, the version will be 3.2. (See
2094 Appendix E for details about backward compatibility.)
2096 random
2097 A client-generated random structure.
2099 session_id
2100 The ID of a session the client wishes to use for this connection.
2101 This field should be empty if no session_id is available or if the
2102 client wishes to generate new security parameters.
2104 cipher_suites
2105 This is a list of the cryptographic options supported by the
2106 client, with the client's first preference first. If the
2107 session_id field is not empty (implying a session resumption
2108 request) this vector MUST include at least the cipher_suite from
2109 that session. Values are defined in Appendix A.5.
2111 compression_methods
2112 This is a list of the compression methods supported by the client,
2113 sorted by client preference. If the session_id field is not empty
2114 (implying a session resumption request) it MUST include the
2115 compression_method from that session. This vector MUST contain,
2116 and all implementations MUST support, CompressionMethod.null.
2117 Thus, a client and server will always be able to agree on a
2118 compression method.
2120 After sending the client hello message, the client waits for a server
2121 hello message. Any other handshake message returned by the server
2122 except for a hello request is treated as a fatal error.
2124 Forward compatibility note: In the interests of forward
2125 compatibility, it is permitted that a client hello message include
2126 extra data after the compression methods. This data MUST be included
2130 Dierks & Rescorla Standards Track [Page 38]
2131 \f
2132 RFC 4346 The TLS Protocol April 2006
2135 in the handshake hashes, but must otherwise be ignored. This is the
2136 only handshake message for which this is legal; for all other
2137 messages, the amount of data in the message MUST match the
2138 description of the message precisely.
2140 Note: For the intended use of trailing data in the ClientHello,
2141 see RFC 3546 [TLSEXT].
2143 7.4.1.3. Server Hello
2145 The server will send this message in response to a client hello
2146 message when it was able to find an acceptable set of algorithms. If
2147 it cannot find such a match, it will respond with a handshake failure
2148 alert.
2150 Structure of this message:
2152 struct {
2153 ProtocolVersion server_version;
2154 Random random;
2155 SessionID session_id;
2156 CipherSuite cipher_suite;
2157 CompressionMethod compression_method;
2158 } ServerHello;
2160 server_version
2161 This field will contain the lower of that suggested by the client
2162 in the client hello and the highest supported by the server. For
2163 this version of the specification, the version is 3.2. (See
2164 Appendix E for details about backward compatibility.)
2166 random
2167 This structure is generated by the server and MUST be
2168 independently generated from the ClientHello.random.
2186 Dierks & Rescorla Standards Track [Page 39]
2187 \f
2188 RFC 4346 The TLS Protocol April 2006
2191 session_id
2192 This is the identity of the session corresponding to this
2193 connection. If the ClientHello.session_id was non-empty, the
2194 server will look in its session cache for a match. If a match is
2195 found and the server is willing to establish the new connection
2196 using the specified session state, the server will respond with
2197 the same value as was supplied by the client. This indicates a
2198 resumed session and dictates that the parties must proceed
2199 directly to the finished messages. Otherwise this field will
2200 contain a different value identifying the new session. The server
2201 may return an empty session_id to indicate that the session will
2202 not be cached and therefore cannot be resumed. If a session is
2203 resumed, it must be resumed using the same cipher suite it was
2204 originally negotiated with.
2206 cipher_suite
2207 The single cipher suite selected by the server from the list in
2208 ClientHello.cipher_suites. For resumed sessions, this field is
2209 the value from the state of the session being resumed.
2211 compression_method The single compression algorithm selected by the
2212 server from the list in ClientHello.compression_methods. For
2213 resumed sessions this field is the value from the resumed session
2214 state.
2216 7.4.2. Server Certificate
2218 When this message will be sent:
2220 The server MUST send a certificate whenever the agreed-upon key
2221 exchange method is not an anonymous one. This message will always
2222 immediately follow the server hello message.
2224 Meaning of this message:
2226 The certificate type MUST be appropriate for the selected cipher
2227 suite's key exchange algorithm, and is generally an X.509v3
2228 certificate. It MUST contain a key that matches the key exchange
2229 method, as follows. Unless otherwise specified, the signing
2230 algorithm for the certificate MUST be the same as the algorithm
2231 for the certificate key. Unless otherwise specified, the public
2232 key MAY be of any length.
2242 Dierks & Rescorla Standards Track [Page 40]
2243 \f
2244 RFC 4346 The TLS Protocol April 2006
2247 Key Exchange Algorithm Certificate Key Type
2249 RSA RSA public key; the certificate MUST
2250 allow the key to be used for encryption.
2252 DHE_DSS DSS public key.
2254 DHE_RSA RSA public key that can be used for
2255 signing.
2257 DH_DSS Diffie-Hellman key. The algorithm used
2258 to sign the certificate MUST be DSS.
2260 DH_RSA Diffie-Hellman key. The algorithm used
2261 to sign the certificate MUST be RSA.
2263 All certificate profiles and key and cryptographic formats are
2264 defined by the IETF PKIX working group [PKIX]. When a key usage
2265 extension is present, the digitalSignature bit MUST be set for the
2266 key to be eligible for signing, as described above, and the
2267 keyEncipherment bit MUST be present to allow encryption, as described
2268 above. The keyAgreement bit must be set on Diffie-Hellman
2269 certificates.
2271 As CipherSuites that specify new key exchange methods are specified
2272 for the TLS Protocol, they will imply certificate format and the
2273 required encoded keying information.
2275 Structure of this message:
2277 opaque ASN.1Cert<1..2^24-1>;
2279 struct {
2280 ASN.1Cert certificate_list<0..2^24-1>;
2281 } Certificate;
2283 certificate_list
2284 This is a sequence (chain) of X.509v3 certificates. The sender's
2285 certificate must come first in the list. Each following
2286 certificate must directly certify the one preceding it. Because
2287 certificate validation requires that root keys be distributed
2288 independently, the self-signed certificate that specifies the root
2289 certificate authority may optionally be omitted from the chain,
2290 under the assumption that the remote end must already possess it
2291 in order to validate it in any case.
2293 The same message type and structure will be used for the client's
2294 response to a certificate request message. Note that a client MAY
2298 Dierks & Rescorla Standards Track [Page 41]
2299 \f
2300 RFC 4346 The TLS Protocol April 2006
2303 send no certificates if it does not have an appropriate certificate
2304 to send in response to the server's authentication request.
2306 Note: PKCS #7 [PKCS7] is not used as the format for the
2307 certificate vector because PKCS #6 [PKCS6] extended
2308 certificates are not used. Also, PKCS #7 defines a SET rather
2309 than a SEQUENCE, making the task of parsing the list more
2310 difficult.
2312 7.4.3. Server Key Exchange Message
2314 When this message will be sent:
2316 This message will be sent immediately after the server certificate
2317 message (or the server hello message, if this is an anonymous
2318 negotiation).
2320 The server key exchange message is sent by the server only when
2321 the server certificate message (if sent) does not contain enough
2322 data to allow the client to exchange a premaster secret. This is
2323 true for the following key exchange methods:
2325 DHE_DSS
2326 DHE_RSA
2327 DH_anon
2329 It is not legal to send the server key exchange message for the
2330 following key exchange methods:
2332 RSA
2333 DH_DSS
2334 DH_RSA
2336 Meaning of this message:
2338 This message conveys cryptographic information to allow the client
2339 to communicate the premaster secret: either an RSA public key with
2340 which to encrypt the premaster secret, or a Diffie-Hellman public
2341 key with which the client can complete a key exchange (with the
2342 result being the premaster secret).
2344 As additional CipherSuites are defined for TLS that include new key
2345 exchange algorithms, the server key exchange message will be sent if
2346 and only if the certificate type associated with the key exchange
2347 algorithm does not provide enough information for the client to
2348 exchange a premaster secret.
2354 Dierks & Rescorla Standards Track [Page 42]
2355 \f
2356 RFC 4346 The TLS Protocol April 2006
2359 Structure of this message:
2361 enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
2363 struct {
2364 opaque rsa_modulus<1..2^16-1>;
2365 opaque rsa_exponent<1..2^16-1>;
2366 } ServerRSAParams;
2368 rsa_modulus
2369 The modulus of the server's temporary RSA key.
2371 rsa_exponent
2372 The public exponent of the server's temporary RSA key.
2374 struct {
2375 opaque dh_p<1..2^16-1>;
2376 opaque dh_g<1..2^16-1>;
2377 opaque dh_Ys<1..2^16-1>;
2378 } ServerDHParams; /* Ephemeral DH parameters */
2380 dh_p
2381 The prime modulus used for the Diffie-Hellman operation.
2383 dh_g
2384 The generator used for the Diffie-Hellman operation.
2386 dh_Ys
2387 The server's Diffie-Hellman public value (g^X mod p).
2389 struct {
2390 select (KeyExchangeAlgorithm) {
2391 case diffie_hellman:
2392 ServerDHParams params;
2393 Signature signed_params;
2394 case rsa:
2395 ServerRSAParams params;
2396 Signature signed_params;
2397 };
2398 } ServerKeyExchange;
2410 Dierks & Rescorla Standards Track [Page 43]
2411 \f
2412 RFC 4346 The TLS Protocol April 2006
2415 struct {
2416 select (KeyExchangeAlgorithm) {
2417 case diffie_hellman:
2418 ServerDHParams params;
2419 case rsa:
2420 ServerRSAParams params;
2421 };
2422 } ServerParams;
2424 params
2425 The server's key exchange parameters.
2427 signed_params
2428 For non-anonymous key exchanges, a hash of the corresponding
2429 params value, with the signature appropriate to that hash
2430 applied.
2432 md5_hash
2433 MD5(ClientHello.random + ServerHello.random + ServerParams);
2435 sha_hash
2436 SHA(ClientHello.random + ServerHello.random + ServerParams);
2438 enum { anonymous, rsa, dsa } SignatureAlgorithm;
2441 struct {
2442 select (SignatureAlgorithm) {
2443 case anonymous: struct { };
2444 case rsa:
2445 digitally-signed struct {
2446 opaque md5_hash[16];
2447 opaque sha_hash[20];
2448 };
2449 case dsa:
2450 digitally-signed struct {
2451 opaque sha_hash[20];
2452 };
2453 };
2454 };
2455 } Signature;
2457 7.4.4. Certificate request
2459 When this message will be sent:
2461 A non-anonymous server can optionally request a certificate from
2462 the client, if it is appropriate for the selected cipher suite.
2466 Dierks & Rescorla Standards Track [Page 44]
2467 \f
2468 RFC 4346 The TLS Protocol April 2006
2471 This message, if sent, will immediately follow the Server Key
2472 Exchange message (if it is sent; otherwise, the Server Certificate
2473 message).
2475 Structure of this message:
2477 enum {
2478 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
2479 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
2480 fortezza_dms_RESERVED(20),
2481 (255)
2483 } ClientCertificateType;
2485 opaque DistinguishedName<1..2^16-1>;
2487 struct {
2488 ClientCertificateType certificate_types<1..2^8-1>;
2489 DistinguishedName certificate_authorities<0..2^16-1>;
2490 } CertificateRequest;
2492 certificate_types
2493 This field is a list of the types of certificates requested,
2494 sorted in order of the server's preference.
2496 certificate_authorities
2497 A list of the distinguished names of acceptable certificate
2498 authorities. These distinguished names may specify a desired
2499 distinguished name for a root CA or for a subordinate CA; thus,
2500 this message can be used to describe both known roots and a
2501 desired authorization space. If the certificate_authorities
2502 list is empty then the client MAY send any certificate of the
2503 appropriate ClientCertificateType, unless there is some
2504 external arrangement to the contrary.
2506 ClientCertificateType values are divided into three groups:
2508 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
2509 reserved for IETF Standards Track protocols.
2511 2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
2512 inclusive are reserved for assignment for non-Standards Track
2513 methods.
2515 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
2516 inclusive are reserved for private use.
2522 Dierks & Rescorla Standards Track [Page 45]
2523 \f
2524 RFC 4346 The TLS Protocol April 2006
2527 Additional information describing the role of IANA in the allocation
2528 of ClientCertificateType code points is described in Section 11.
2530 Note: Values listed as RESERVED may not be used. They were used in
2531 SSLv3.
2533 Note: DistinguishedName is derived from [X501]. DistinguishedNames
2534 are represented in DER-encoded format.
2536 Note: It is a fatal handshake_failure alert for an anonymous server
2537 to request client authentication.
2539 7.4.5. Server Hello Done
2541 When this message will be sent:
2543 The server hello done message is sent by the server to indicate
2544 the end of the server hello and associated messages. After
2545 sending this message, the server will wait for a client response.
2547 Meaning of this message:
2549 This message means that the server is done sending messages to
2550 support the key exchange, and the client can proceed with its
2551 phase of the key exchange.
2553 Upon receipt of the server hello done message, the client SHOULD
2554 verify that the server provided a valid certificate, if required
2555 and check that the server hello parameters are acceptable.
2557 Structure of this message:
2559 struct { } ServerHelloDone;
2561 7.4.6. Client certificate
2563 When this message will be sent:
2565 This is the first message the client can send after receiving a
2566 server hello done message. This message is only sent if the
2567 server requests a certificate. If no suitable certificate is
2568 available, the client SHOULD send a certificate message containing
2569 no certificates. That is, the certificate_list structure has a
2570 length of zero. If client authentication is required by the
2571 server for the handshake to continue, it may respond with a fatal
2572 handshake failure alert. Client certificates are sent using the
2573 Certificate structure defined in Section 7.4.2.
2578 Dierks & Rescorla Standards Track [Page 46]
2579 \f
2580 RFC 4346 The TLS Protocol April 2006
2583 Note: When using a static Diffie-Hellman based key exchange method
2584 (DH_DSS or DH_RSA), if client authentication is requested, the
2585 Diffie-Hellman group and generator encoded in the client's
2586 certificate MUST match the server specified Diffie-Hellman
2587 parameters if the client's parameters are to be used for the key
2588 exchange.
2590 7.4.7. Client Key Exchange Message
2592 When this message will be sent:
2594 This message is always sent by the client. It MUST immediately
2595 follow the client certificate message, if it is sent. Otherwise
2596 it MUST be the first message sent by the client after it receives
2597 the server hello done message.
2599 Meaning of this message:
2601 With this message, the premaster secret is set, either though
2602 direct transmission of the RSA-encrypted secret or by the
2603 transmission of Diffie-Hellman parameters that will allow each
2604 side to agree upon the same premaster secret. When the key
2605 exchange method is DH_RSA or DH_DSS, client certification has been
2606 requested, and the client was able to respond with a certificate
2607 that contained a Diffie-Hellman public key whose parameters (group
2608 and generator) matched those specified by the server in its
2609 certificate, this message MUST not contain any data.
2611 Structure of this message:
2613 The choice of messages depends on which key exchange method has
2614 been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
2615 definition.
2617 struct {
2618 select (KeyExchangeAlgorithm) {
2619 case rsa: EncryptedPreMasterSecret;
2620 case diffie_hellman: ClientDiffieHellmanPublic;
2621 } exchange_keys;
2622 } ClientKeyExchange;
2624 7.4.7.1. RSA Encrypted Premaster Secret Message
2626 Meaning of this message:
2628 If RSA is being used for key agreement and authentication, the
2629 client generates a 48-byte premaster secret, encrypts it using the
2630 public key from the server's certificate or the temporary RSA key
2634 Dierks & Rescorla Standards Track [Page 47]
2635 \f
2636 RFC 4346 The TLS Protocol April 2006
2639 provided in a server key exchange message, and sends the result in
2640 an encrypted premaster secret message. This structure is a
2641 variant of the client key exchange message and is not a message in
2642 itself.
2644 Structure of this message:
2646 struct {
2647 ProtocolVersion client_version;
2648 opaque random[46];
2649 } PreMasterSecret;
2651 client_version The latest (newest) version supported by the
2652 client. This is used to detect version roll-back attacks.
2653 Upon receiving the premaster secret, the server SHOULD check
2654 that this value matches the value transmitted by the client in
2655 the client hello message.
2657 random
2658 46 securely-generated random bytes.
2660 struct {
2661 public-key-encrypted PreMasterSecret pre_master_secret;
2662 } EncryptedPreMasterSecret;
2664 pre_master_secret
2665 This random value is generated by the client and is used to
2666 generate the master secret, as specified in Section 8.1.
2668 Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be
2669 used to attack a TLS server that is using PKCS#1 v 1.5 encoded
2670 RSA. The attack takes advantage of the fact that, by failing
2671 in different ways, a TLS server can be coerced into revealing
2672 whether a particular message, when decrypted, is properly
2673 PKCS#1 v1.5 formatted or not.
2675 The best way to avoid vulnerability to this attack is to treat
2676 incorrectly formatted messages in a manner indistinguishable
2677 from correctly formatted RSA blocks. Thus, when a server
2678 receives an incorrectly formatted RSA block, it should generate
2679 a random 48-byte value and proceed using it as the premaster
2680 secret. Thus, the server will act identically whether the
2681 received RSA block is correctly encoded or not.
2683 [PKCS1B] defines a newer version of PKCS#1 encoding that is
2684 more secure against the Bleichenbacher attack. However, for
2685 maximal compatibility with TLS 1.0, TLS 1.1 retains the
2686 original encoding. No variants of the Bleichenbacher attack
2690 Dierks & Rescorla Standards Track [Page 48]
2691 \f
2692 RFC 4346 The TLS Protocol April 2006
2695 are known to exist provided that the above recommendations are
2696 followed.
2698 Implementation Note: Public-key-encrypted data is represented as an
2699 opaque vector <0..2^16-1> (see Section 4.7).
2700 Thus, the RSA-encrypted PreMasterSecret in a
2701 ClientKeyExchange is preceded by two length
2702 bytes. These bytes are redundant in the case of
2703 RSA because the EncryptedPreMasterSecret is the
2704 only data in the ClientKeyExchange and its
2705 length can therefore be unambiguously
2706 determined. The SSLv3 specification was not
2707 clear about the encoding of public-key-encrypted
2708 data, and therefore many SSLv3 implementations
2709 do not include the length bytes, encoding the
2710 RSA encrypted data directly in the
2711 ClientKeyExchange message.
2713 This specification requires correct encoding of
2714 the EncryptedPreMasterSecret complete with
2715 length bytes. The resulting PDU is incompatible
2716 with many SSLv3 implementations. Implementors
2717 upgrading from SSLv3 must modify their
2718 implementations to generate and accept the
2719 correct encoding. Implementors who wish to be
2720 compatible with both SSLv3 and TLS should make
2721 their implementation's behavior dependent on the
2722 protocol version.
2724 Implementation Note: It is now known that remote timing-based attacks
2725 on SSL are possible, at least when the client
2726 and server are on the same LAN. Accordingly,
2727 implementations that use static RSA keys SHOULD
2728 use RSA blinding or some other anti-timing
2729 technique, as described in [TIMING].
2731 Note: The version number in the PreMasterSecret MUST be the version
2732 offered by the client in the ClientHello, not the version
2733 negotiated for the connection. This feature is designed to
2734 prevent rollback attacks. Unfortunately, many implementations
2735 use the negotiated version instead, and therefore checking the
2736 version number may lead to failure to interoperate with such
2737 incorrect client implementations. Client implementations, MUST
2738 and Server implementations MAY, check the version number. In
2739 practice, since the TLS handshake MACs prevent downgrade and no
2740 good attacks are known on those MACs, ambiguity is not
2741 considered a serious security risk. Note that if servers
2742 choose to check the version number, they should randomize the
2746 Dierks & Rescorla Standards Track [Page 49]
2747 \f
2748 RFC 4346 The TLS Protocol April 2006
2751 PreMasterSecret in case of error, rather than generate an
2752 alert, in order to avoid variants on the Bleichenbacher attack.
2753 [KPR03]
2755 7.4.7.2. Client Diffie-Hellman Public Value
2757 Meaning of this message:
2759 This structure conveys the client's Diffie-Hellman public value
2760 (Yc) if it was not already included in the client's certificate.
2761 The encoding used for Yc is determined by the enumerated
2762 PublicValueEncoding. This structure is a variant of the client
2763 key exchange message and not a message in itself.
2765 Structure of this message:
2767 enum { implicit, explicit } PublicValueEncoding;
2769 implicit
2770 If the client certificate already contains a suitable Diffie-
2771 Hellman key, then Yc is implicit and does not need to be sent
2772 again. In this case, the client key exchange message will be
2773 sent, but it MUST be empty.
2775 explicit
2776 Yc needs to be sent.
2778 struct {
2779 select (PublicValueEncoding) {
2780 case implicit: struct { };
2781 case explicit: opaque dh_Yc<1..2^16-1>;
2782 } dh_public;
2783 } ClientDiffieHellmanPublic;
2785 dh_Yc
2786 The client's Diffie-Hellman public value (Yc).
2788 7.4.8. Certificate verify
2790 When this message will be sent:
2792 This message is used to provide explicit verification of a client
2793 certificate. This message is only sent following a client
2794 certificate that has signing capability (i.e., all certificates
2795 except those containing fixed Diffie-Hellman parameters). When
2796 sent, it MUST immediately follow the client key exchange message.
2802 Dierks & Rescorla Standards Track [Page 50]
2803 \f
2804 RFC 4346 The TLS Protocol April 2006
2807 Structure of this message:
2809 struct {
2810 Signature signature;
2811 } CertificateVerify;
2813 The Signature type is defined in 7.4.3.
2815 CertificateVerify.signature.md5_hash
2816 MD5(handshake_messages);
2818 CertificateVerify.signature.sha_hash
2819 SHA(handshake_messages);
2821 Here handshake_messages refers to all handshake messages sent or
2822 received starting at client hello up to but not including this
2823 message, including the type and length fields of the handshake
2824 messages. This is the concatenation of all the Handshake structures,
2825 as defined in 7.4, exchanged thus far.
2827 7.4.9. Finished
2829 When this message will be sent:
2831 A finished message is always sent immediately after a change
2832 cipher spec message to verify that the key exchange and
2833 authentication processes were successful. It is essential that a
2834 change cipher spec message be received between the other handshake
2835 messages and the Finished message.
2837 Meaning of this message:
2839 The finished message is the first protected with the just-
2840 negotiated algorithms, keys, and secrets. Recipients of finished
2841 messages MUST verify that the contents are correct. Once a side
2842 has sent its Finished message and received and validated the
2843 Finished message from its peer, it may begin to send and receive
2844 application data over the connection.
2846 struct {
2847 opaque verify_data[12];
2848 } Finished;
2850 verify_data
2851 PRF(master_secret, finished_label, MD5(handshake_messages) +
2852 SHA-1(handshake_messages)) [0..11];
2858 Dierks & Rescorla Standards Track [Page 51]
2859 \f
2860 RFC 4346 The TLS Protocol April 2006
2863 finished_label
2864 For Finished messages sent by the client, the string "client
2865 finished". For Finished messages sent by the server, the
2866 string "server finished".
2868 handshake_messages
2869 All of the data from all messages in this handshake (not
2870 including any HelloRequest messages) up to but not including
2871 this message. This is only data visible at the handshake
2872 layer and does not include record layer headers. This is the
2873 concatenation of all the Handshake structures, as defined in
2874 7.4, exchanged thus far.
2876 It is a fatal error if a finished message is not preceded by a change
2877 cipher spec message at the appropriate point in the handshake.
2879 The value handshake_messages includes all handshake messages starting
2880 at client hello up to, but not including, this finished message.
2881 This may be different from handshake_messages in Section 7.4.8
2882 because it would include the certificate verify message (if sent).
2883 Also, the handshake_messages for the finished message sent by the
2884 client will be different from that for the finished message sent by
2885 the server, because the one that is sent second will include the
2886 prior one.
2888 Note: Change cipher spec messages, alerts, and any other record types
2889 are not handshake messages and are not included in the hash
2890 computations. Also, Hello Request messages are omitted from
2891 handshake hashes.
2893 8. Cryptographic Computations
2895 In order to begin connection protection, the TLS Record Protocol
2896 requires specification of a suite of algorithms, a master secret, and
2897 the client and server random values. The authentication, encryption,
2898 and MAC algorithms are determined by the cipher_suite selected by the
2899 server and revealed in the server hello message. The compression
2900 algorithm is negotiated in the hello messages, and the random values
2901 are exchanged in the hello messages. All that remains is to
2902 calculate the master secret.
2904 8.1. Computing the Master Secret
2906 For all key exchange methods, the same algorithm is used to convert
2907 the pre_master_secret into the master_secret. The pre_master_secret
2908 should be deleted from memory once the master_secret has been
2909 computed.
2914 Dierks & Rescorla Standards Track [Page 52]
2915 \f
2916 RFC 4346 The TLS Protocol April 2006
2919 master_secret = PRF(pre_master_secret, "master secret",
2920 ClientHello.random + ServerHello.random)
2921 [0..47];
2923 The master secret is always exactly 48 bytes in length. The length
2924 of the premaster secret will vary depending on key exchange method.
2926 8.1.1. RSA
2928 When RSA is used for server authentication and key exchange, a 48-
2929 byte pre_master_secret is generated by the client, encrypted under
2930 the server's public key, and sent to the server. The server uses its
2931 private key to decrypt the pre_master_secret. Both parties then
2932 convert the pre_master_secret into the master_secret, as specified
2933 above.
2935 RSA digital signatures are performed using PKCS #1 [PKCS1] block type
2936 1. RSA public key encryption is performed using PKCS #1 block type 2.
2938 8.1.2. Diffie-Hellman
2940 A conventional Diffie-Hellman computation is performed. The
2941 negotiated key (Z) is used as the pre_master_secret, and is converted
2942 into the master_secret, as specified above. Leading bytes of Z that
2943 contain all zero bits are stripped before it is used as the
2944 pre_master_secret.
2946 Note: Diffie-Hellman parameters are specified by the server and may
2947 be either ephemeral or contained within the server's
2948 certificate.
2950 9. Mandatory Cipher Suites
2952 In the absence of an application profile standard specifying
2953 otherwise, a TLS compliant application MUST implement the cipher
2954 suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
2956 10. Application Data Protocol
2958 Application data messages are carried by the Record Layer and are
2959 fragmented, compressed, and encrypted based on the current connection
2960 state. The messages are treated as transparent data to the record
2961 layer.
2963 11. Security Considerations
2965 Security issues are discussed throughout this memo, especially in
2966 Appendices D, E, and F.
2970 Dierks & Rescorla Standards Track [Page 53]
2971 \f
2972 RFC 4346 The TLS Protocol April 2006
2975 12. IANA Considerations
2977 This document describes a number of new registries that have been
2978 created by IANA. We recommended that they be placed as individual
2979 registries items under a common TLS category.
2981 Section 7.4.3 describes a TLS ClientCertificateType Registry to be
2982 maintained by the IANA, defining a number of such code point
2983 identifiers. ClientCertificateType identifiers with values in the
2984 range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
2985 Action. Values from the range 64-223 (decimal) inclusive are
2986 assigned via [RFC2434] Specification Required. Identifier values
2987 from 224-255 (decimal) inclusive are reserved for RFC 2434 Private
2988 Use. The registry will initially be populated with the values in
2989 this document, Section 7.4.4.
2991 Section A.5 describes a TLS Cipher Suite Registry to be maintained by
2992 the IANA, and it defines a number of such cipher suite identifiers.
2993 Cipher suite values with the first byte in the range 0-191 (decimal)
2994 inclusive are assigned via RFC 2434 Standards Action. Values with
2995 the first byte in the range 192-254 (decimal) are assigned via RFC
2996 2434 Specification Required. Values with the first byte 255
2997 (decimal) are reserved for RFC 2434 Private Use. The registry will
2998 initially be populated with the values from Section A.5 of this
2999 document, [TLSAES], and from Section 3 of [TLSKRB].
3001 Section 6 requires that all ContentType values be defined by RFC 2434
3002 Standards Action. IANA has created a TLS ContentType registry,
3003 initially populated with values from Section 6.2.1 of this document.
3004 Future values MUST be allocated via Standards Action as described in
3005 [RFC2434].
3007 Section 7.2.2 requires that all Alert values be defined by RFC 2434
3008 Standards Action. IANA has created a TLS Alert registry, initially
3009 populated with values from Section 7.2 of this document and from
3010 Section 4 of [TLSEXT]. Future values MUST be allocated via Standards
3011 Action as described in [RFC2434].
3013 Section 7.4 requires that all HandshakeType values be defined by RFC
3014 2434 Standards Action. IANA has created a TLS HandshakeType
3015 registry, initially populated with values from Section 7.4 of this
3016 document and from Section 2.4 of [TLSEXT]. Future values MUST be
3017 allocated via Standards Action as described in [RFC2434].
3026 Dierks & Rescorla Standards Track [Page 54]
3027 \f
3028 RFC 4346 The TLS Protocol April 2006
3031 Appendix A. Protocol Constant Values
3033 This section describes protocol types and constants.
3035 A.1. Record Layer
3037 struct {
3038 uint8 major, minor;
3039 } ProtocolVersion;
3041 ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */
3043 enum {
3044 change_cipher_spec(20), alert(21), handshake(22),
3045 application_data(23), (255)
3046 } ContentType;
3048 struct {
3049 ContentType type;
3050 ProtocolVersion version;
3051 uint16 length;
3052 opaque fragment[TLSPlaintext.length];
3053 } TLSPlaintext;
3055 struct {
3056 ContentType type;
3057 ProtocolVersion version;
3058 uint16 length;
3059 opaque fragment[TLSCompressed.length];
3060 } TLSCompressed;
3062 struct {
3063 ContentType type;
3064 ProtocolVersion version;
3065 uint16 length;
3066 select (CipherSpec.cipher_type) {
3067 case stream: GenericStreamCipher;
3068 case block: GenericBlockCipher;
3069 } fragment;
3070 } TLSCiphertext;
3072 stream-ciphered struct {
3073 opaque content[TLSCompressed.length];
3074 opaque MAC[CipherSpec.hash_size];
3075 } GenericStreamCipher;
3077 block-ciphered struct {
3078 opaque IV[CipherSpec.block_length];
3082 Dierks & Rescorla Standards Track [Page 55]
3083 \f
3084 RFC 4346 The TLS Protocol April 2006
3087 opaque content[TLSCompressed.length];
3088 opaque MAC[CipherSpec.hash_size];
3089 uint8 padding[GenericBlockCipher.padding_length];
3090 uint8 padding_length;
3091 } GenericBlockCipher;
3093 A.2. Change Cipher Specs Message
3095 struct {
3096 enum { change_cipher_spec(1), (255) } type;
3097 } ChangeCipherSpec;
3099 A.3. Alert Messages
3101 enum { warning(1), fatal(2), (255) } AlertLevel;
3103 enum {
3104 close_notify(0),
3105 unexpected_message(10),
3106 bad_record_mac(20),
3107 decryption_failed(21),
3108 record_overflow(22),
3109 decompression_failure(30),
3110 handshake_failure(40),
3111 no_certificate_RESERVED (41),
3112 bad_certificate(42),
3113 unsupported_certificate(43),
3114 certificate_revoked(44),
3115 certificate_expired(45),
3116 certificate_unknown(46),
3117 illegal_parameter(47),
3118 unknown_ca(48),
3119 access_denied(49),
3120 decode_error(50),
3121 decrypt_error(51),
3122 export_restriction_RESERVED(60),
3123 protocol_version(70),
3124 insufficient_security(71),
3125 internal_error(80),
3126 user_canceled(90),
3127 no_renegotiation(100),
3128 (255)
3129 } AlertDescription;
3131 struct {
3132 AlertLevel level;
3133 AlertDescription description;
3134 } Alert;
3138 Dierks & Rescorla Standards Track [Page 56]
3139 \f
3140 RFC 4346 The TLS Protocol April 2006
3143 A.4. Handshake Protocol
3145 enum {
3146 hello_request(0), client_hello(1), server_hello(2),
3147 certificate(11), server_key_exchange (12),
3148 certificate_request(13), server_hello_done(14),
3149 certificate_verify(15), client_key_exchange(16),
3150 finished(20), (255)
3151 } HandshakeType;
3153 struct {
3154 HandshakeType msg_type;
3155 uint24 length;
3156 select (HandshakeType) {
3157 case hello_request: HelloRequest;
3158 case client_hello: ClientHello;
3159 case server_hello: ServerHello;
3160 case certificate: Certificate;
3161 case server_key_exchange: ServerKeyExchange;
3162 case certificate_request: CertificateRequest;
3163 case server_hello_done: ServerHelloDone;
3164 case certificate_verify: CertificateVerify;
3165 case client_key_exchange: ClientKeyExchange;
3166 case finished: Finished;
3167 } body;
3168 } Handshake;
3170 A.4.1. Hello messages
3172 struct { } HelloRequest;
3174 struct {
3175 uint32 gmt_unix_time;
3176 opaque random_bytes[28];
3177 } Random;
3179 opaque SessionID<0..32>;
3181 uint8 CipherSuite[2];
3183 enum { null(0), (255) } CompressionMethod;
3185 struct {
3186 ProtocolVersion client_version;
3187 Random random;
3188 SessionID session_id;
3189 CipherSuite cipher_suites<2..2^16-1>;
3190 CompressionMethod compression_methods<1..2^8-1>;
3194 Dierks & Rescorla Standards Track [Page 57]
3195 \f
3196 RFC 4346 The TLS Protocol April 2006
3199 } ClientHello;
3201 struct {
3202 ProtocolVersion server_version;
3203 Random random;
3204 SessionID session_id;
3205 CipherSuite cipher_suite;
3206 CompressionMethod compression_method;
3207 } ServerHello;
3209 A.4.2. Server Authentication and Key Exchange Messages
3211 opaque ASN.1Cert<2^24-1>;
3213 struct {
3214 ASN.1Cert certificate_list<0..2^24-1>;
3215 } Certificate;
3217 enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
3219 struct {
3220 opaque rsa_modulus<1..2^16-1>;
3221 opaque rsa_exponent<1..2^16-1>;
3222 } ServerRSAParams;
3224 struct {
3225 opaque dh_p<1..2^16-1>;
3226 opaque dh_g<1..2^16-1>;
3227 opaque dh_Ys<1..2^16-1>;
3228 } ServerDHParams;
3230 struct {
3231 select (KeyExchangeAlgorithm) {
3232 case diffie_hellman:
3233 ServerDHParams params;
3234 Signature signed_params;
3235 case rsa:
3236 ServerRSAParams params;
3237 Signature signed_params;
3238 };
3239 } ServerKeyExchange;
3241 enum { anonymous, rsa, dsa } SignatureAlgorithm;
3243 struct {
3244 select (KeyExchangeAlgorithm) {
3245 case diffie_hellman:
3246 ServerDHParams params;
3250 Dierks & Rescorla Standards Track [Page 58]
3251 \f
3252 RFC 4346 The TLS Protocol April 2006
3255 case rsa:
3256 ServerRSAParams params;
3257 };
3258 } ServerParams;
3260 struct {
3261 select (SignatureAlgorithm) {
3262 case anonymous: struct { };
3263 case rsa:
3264 digitally-signed struct {
3265 opaque md5_hash[16];
3266 opaque sha_hash[20];
3267 };
3268 case dsa:
3269 digitally-signed struct {
3270 opaque sha_hash[20];
3271 };
3272 };
3273 };
3274 } Signature;
3276 enum {
3277 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
3278 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
3279 fortezza_dms_RESERVED(20),
3280 (255)
3281 } ClientCertificateType;
3283 opaque DistinguishedName<1..2^16-1>;
3285 struct {
3286 ClientCertificateType certificate_types<1..2^8-1>;
3287 DistinguishedName certificate_authorities<0..2^16-1>;
3288 } CertificateRequest;
3290 struct { } ServerHelloDone;
3292 A.4.3. Client Authentication and Key Exchange Messages
3294 struct {
3295 select (KeyExchangeAlgorithm) {
3296 case rsa: EncryptedPreMasterSecret;
3297 case diffie_hellman: ClientDiffieHellmanPublic;
3298 } exchange_keys;
3299 } ClientKeyExchange;
3306 Dierks & Rescorla Standards Track [Page 59]
3307 \f
3308 RFC 4346 The TLS Protocol April 2006
3311 struct {
3312 ProtocolVersion client_version;
3313 opaque random[46];
3314 }
3315 PreMasterSecret;
3317 struct {
3318 public-key-encrypted PreMasterSecret pre_master_secret;
3319 } EncryptedPreMasterSecret;
3321 enum { implicit, explicit } PublicValueEncoding;
3323 struct {
3324 select (PublicValueEncoding) {
3325 case implicit: struct {};
3326 case explicit: opaque DH_Yc<1..2^16-1>;
3327 } dh_public;
3328 } ClientDiffieHellmanPublic;
3330 struct {
3331 Signature signature;
3332 } CertificateVerify;
3334 A.4.4. Handshake Finalization Message
3336 struct {
3337 opaque verify_data[12];
3338 } Finished;
3340 A.5. The CipherSuite
3342 The following values define the CipherSuite codes used in the client
3343 hello and server hello messages.
3345 A CipherSuite defines a cipher specification supported in TLS Version
3346 1.1.
3348 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
3349 TLS connection during the first handshake on that channel, but must
3350 not be negotiated, as it provides no more protection than an
3351 unsecured connection.
3353 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
3355 The following CipherSuite definitions require that the server provide
3356 an RSA certificate that can be used for key exchange. The server may
3357 request either an RSA or a DSS signature-capable certificate in the
3358 certificate request message.
3362 Dierks & Rescorla Standards Track [Page 60]
3363 \f
3364 RFC 4346 The TLS Protocol April 2006
3367 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
3368 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
3369 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
3370 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
3371 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
3372 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
3373 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
3375 The following CipherSuite definitions are used for server-
3376 authenticated (and optionally client-authenticated) Diffie-Hellman.
3377 DH denotes cipher suites in which the server's certificate contains
3378 the Diffie-Hellman parameters signed by the certificate authority
3379 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
3380 parameters are signed by a DSS or RSA certificate that has been
3381 signed by the CA. The signing algorithm used is specified after the
3382 DH or DHE parameter. The server can request an RSA or DSS
3383 signature-capable certificate from the client for client
3384 authentication or it may request a Diffie-Hellman certificate. Any
3385 Diffie-Hellman certificate provided by the client must use the
3386 parameters (group and generator) described by the server.
3388 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
3389 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
3390 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
3391 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
3392 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
3393 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
3394 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
3395 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
3397 The following cipher suites are used for completely anonymous
3398 Diffie-Hellman communications in which neither party is
3399 authenticated. Note that this mode is vulnerable to man-in-the-
3400 middle attacks and is therefore deprecated.
3402 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
3403 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
3404 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
3406 When SSLv3 and TLS 1.0 were designed, the United States restricted
3407 the export of cryptographic software containing certain strong
3408 encryption algorithms. A series of cipher suites were designed to
3409 operate at reduced key lengths in order to comply with those
3410 regulations. Due to advances in computer performance, these
3411 algorithms are now unacceptably weak, and export restrictions have
3412 since been loosened. TLS 1.1 implementations MUST NOT negotiate
3413 these cipher suites in TLS 1.1 mode. However, for backward
3414 compatibility they may be offered in the ClientHello for use with TLS
3418 Dierks & Rescorla Standards Track [Page 61]
3419 \f
3420 RFC 4346 The TLS Protocol April 2006
3423 1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the
3424 server did not choose one of these cipher suites during the
3425 handshake. These ciphersuites are listed below for informational
3426 purposes and to reserve the numbers.
3428 CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
3429 CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
3430 CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
3431 CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
3432 CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
3433 CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
3434 CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
3435 CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
3436 CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
3438 The following cipher suites were defined in [TLSKRB] and are included
3439 here for completeness. See [TLSKRB] for details:
3441 CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }:
3442 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
3443 CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
3444 CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
3445 CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
3446 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
3447 CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
3448 CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
3450 The following exportable cipher suites were defined in [TLSKRB] and
3451 are included here for completeness. TLS 1.1 implementations MUST NOT
3452 negotiate these cipher suites.
3454 CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26};
3455 CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27};
3456 CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28};
3457 CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29};
3458 CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A};
3459 CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B};
3462 The following cipher suites were defined in [TLSAES] and are included
3463 here for completeness. See [TLSAES] for details:
3465 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F };
3466 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 };
3467 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 };
3468 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 };
3469 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 };
3470 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 };
3474 Dierks & Rescorla Standards Track [Page 62]
3475 \f
3476 RFC 4346 The TLS Protocol April 2006
3479 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 };
3480 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 };
3481 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 };
3482 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 };
3483 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 };
3484 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A };
3486 The cipher suite space is divided into three regions:
3488 1. Cipher suite values with first byte 0x00 (zero) through decimal
3489 191 (0xBF) inclusive are reserved for the IETF Standards Track
3490 protocols.
3492 2. Cipher suite values with first byte decimal 192 (0xC0) through
3493 decimal 254 (0xFE) inclusive are reserved for assignment for
3494 non-Standards Track methods.
3496 3. Cipher suite values with first byte 0xFF are reserved for
3497 private use.
3499 Additional information describing the role of IANA in the allocation
3500 of cipher suite code points is described in Section 11.
3502 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
3503 reserved to avoid collision with Fortezza-based cipher suites
3504 in SSL 3.
3506 A.6. The Security Parameters
3508 These security parameters are determined by the TLS Handshake
3509 Protocol and provided as parameters to the TLS Record Layer in
3510 order to initialize a connection state. SecurityParameters
3511 includes:
3513 enum { null(0), (255) } CompressionMethod;
3515 enum { server, client } ConnectionEnd;
3517 enum { null, rc4, rc2, des, 3des, des40, aes, idea }
3518 BulkCipherAlgorithm;
3520 enum { stream, block } CipherType;
3522 enum { null, md5, sha } MACAlgorithm;
3524 /* The algorithms specified in CompressionMethod,
3525 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
3530 Dierks & Rescorla Standards Track [Page 63]
3531 \f
3532 RFC 4346 The TLS Protocol April 2006
3535 struct {
3536 ConnectionEnd entity;
3537 BulkCipherAlgorithm bulk_cipher_algorithm;
3538 CipherType cipher_type;
3539 uint8 key_size;
3540 uint8 key_material_length;
3541 MACAlgorithm mac_algorithm;
3542 uint8 hash_size;
3543 CompressionMethod compression_algorithm;
3544 opaque master_secret[48];
3545 opaque client_random[32];
3546 opaque server_random[32];
3547 } SecurityParameters;
3549 Appendix B. Glossary
3551 Advanced Encryption Standard (AES)
3552 AES is a widely used symmetric encryption algorithm. AES is a
3553 block cipher with a 128, 192, or 256 bit keys and a 16 byte block
3554 size. [AES] TLS currently only supports the 128 and 256 bit key
3555 sizes.
3557 application protocol
3558 An application protocol is a protocol that normally layers
3559 directly on top of the transport layer (e.g., TCP/IP). Examples
3560 include HTTP, TELNET, FTP, and SMTP.
3562 asymmetric cipher
3563 See public key cryptography.
3565 authentication
3566 Authentication is the ability of one entity to determine the
3567 identity of another entity.
3569 block cipher
3570 A block cipher is an algorithm that operates on plaintext in
3571 groups of bits, called blocks. 64 bits is a common block size.
3573 bulk cipher
3574 A symmetric encryption algorithm used to encrypt large quantities
3575 of data.
3577 cipher block chaining (CBC)
3578 CBC is a mode in which every plaintext block encrypted with a
3579 block cipher is first exclusive-ORed with the previous ciphertext
3580 block (or, in the case of the first block, with the initialization
3581 vector). For decryption, every block is first decrypted, then
3582 exclusive-ORed with the previous ciphertext block (or IV).
3586 Dierks & Rescorla Standards Track [Page 64]
3587 \f
3588 RFC 4346 The TLS Protocol April 2006
3591 certificate
3592 As part of the X.509 protocol (a.k.a. ISO Authentication
3593 framework), certificates are assigned by a trusted Certificate
3594 Authority and provide a strong binding between a party's identity
3595 or some other attributes and its public key.
3597 client
3598 The application entity that initiates a TLS connection to a
3599 server. This may or may not imply that the client initiated the
3600 underlying transport connection. The primary operational
3601 difference between the server and client is that the server is
3602 generally authenticated, while the client is only optionally
3603 authenticated.
3605 client write key
3606 The key used to encrypt data written by the client.
3608 client write MAC secret
3609 The secret data used to authenticate data written by the client.
3611 connection
3612 A connection is a transport (in the OSI layering model definition)
3613 that provides a suitable type of service. For TLS, such
3614 connections are peer-to-peer relationships. The connections are
3615 transient. Every connection is associated with one session.
3617 Data Encryption Standard
3618 DES is a very widely used symmetric encryption algorithm. DES is
3619 a block cipher with a 56 bit key and an 8 byte block size. Note
3620 that in TLS, for key generation purposes, DES is treated as having
3621 an 8 byte key length (64 bits), but it still only provides 56 bits
3622 of protection. (The low bit of each key byte is presumed to be
3623 set to produce odd parity in that key byte.) DES can also be
3624 operated in a mode where three independent keys and three
3625 encryptions are used for each block of data; this uses 168 bits of
3626 key (24 bytes in the TLS key generation method) and provides the
3627 equivalent of 112 bits of security. [DES], [3DES]
3629 Digital Signature Standard (DSS)
3630 A standard for digital signing, including the Digital Signing
3631 Algorithm, approved by the National Institute of Standards and
3632 Technology, defined in NIST FIPS PUB 186, "Digital Signature
3633 Standard," published May 1994 by the U.S. Dept. of Commerce.
3634 [DSS]
3642 Dierks & Rescorla Standards Track [Page 65]
3643 \f
3644 RFC 4346 The TLS Protocol April 2006
3647 digital signatures
3648 Digital signatures utilize public key cryptography and one-way
3649 hash functions to produce a signature of the data that can be
3650 authenticated, and is difficult to forge or repudiate.
3652 handshake
3653 An initial negotiation between client and server that establishes
3654 the parameters of their transactions.
3656 Initialization Vector (IV)
3657 When a block cipher is used in CBC mode, the initialization vector
3658 is exclusive-ORed with the first plaintext block prior to
3659 encryption.
3661 IDEA
3662 A 64-bit block cipher designed by Xuejia Lai and James Massey.
3663 [IDEA]
3665 Message Authentication Code (MAC)
3666 A Message Authentication Code is a one-way hash computed from a
3667 message and some secret data. It is difficult to forge without
3668 knowing the secret data. Its purpose is to detect if the message
3669 has been altered.
3671 master secret
3672 Secure secret data used for generating encryption keys, MAC
3673 secrets, and IVs.
3675 MD5
3676 MD5 is a secure hashing function that converts an arbitrarily long
3677 data stream into a digest of fixed size (16 bytes). [MD5]
3679 public key cryptography
3680 A class of cryptographic techniques employing two-key ciphers.
3681 Messages encrypted with the public key can only be decrypted with
3682 the associated private key. Conversely, messages signed with the
3683 private key can be verified with the public key.
3685 one-way hash function
3686 A one-way transformation that converts an arbitrary amount of data
3687 into a fixed-length hash. It is computationally hard to reverse
3688 the transformation or to find collisions. MD5 and SHA are
3689 examples of one-way hash functions.
3691 RC2
3692 A block cipher developed by Ron Rivest at RSA Data Security, Inc.
3693 [RSADSI] described in [RC2].
3698 Dierks & Rescorla Standards Track [Page 66]
3699 \f
3700 RFC 4346 The TLS Protocol April 2006
3703 RC4
3704 A stream cipher invented by Ron Rivest. A compatible cipher is
3705 described in [SCH].
3707 RSA
3708 A very widely used public-key algorithm that can be used for
3709 either encryption or digital signing. [RSA]
3711 server
3712 The server is the application entity that responds to requests for
3713 connections from clients. See also under client.
3715 session
3716 A TLS session is an association between a client and a server.
3717 Sessions are created by the handshake protocol. Sessions define a
3718 set of cryptographic security parameters that can be shared among
3719 multiple connections. Sessions are used to avoid the expensive
3720 negotiation of new security parameters for each connection.
3722 session identifier
3723 A session identifier is a value generated by a server that
3724 identifies a particular session.
3726 server write key
3727 The key used to encrypt data written by the server.
3729 server write MAC secret
3730 The secret data used to authenticate data written by the server.
3732 SHA
3733 The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
3734 produces a 20-byte output. Note that all references to SHA
3735 actually use the modified SHA-1 algorithm. [SHA]
3737 SSL
3738 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
3739 SSL Version 3.0
3741 stream cipher
3742 An encryption algorithm that converts a key into a
3743 cryptographically strong keystream, which is then exclusive-ORed
3744 with the plaintext.
3746 symmetric cipher
3747 See bulk cipher.
3754 Dierks & Rescorla Standards Track [Page 67]
3755 \f
3756 RFC 4346 The TLS Protocol April 2006
3759 Transport Layer Security (TLS)
3760 This protocol; also, the Transport Layer Security working group of
3761 the Internet Engineering Task Force (IETF). See "Comments" at the
3762 end of this document.
3764 Appendix C. CipherSuite Definitions
3766 CipherSuite Key Exchange Cipher Hash
3768 TLS_NULL_WITH_NULL_NULL NULL NULL NULL
3769 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
3770 TLS_RSA_WITH_NULL_SHA RSA NULL SHA
3771 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
3772 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
3773 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
3774 TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
3775 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
3776 TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
3777 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
3778 TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
3779 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
3780 TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
3781 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
3782 TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
3783 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
3784 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
3785 TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA
3786 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
3788 Key
3789 Exchange
3790 Algorithm Description Key size limit
3792 DHE_DSS Ephemeral DH with DSS signatures None
3793 DHE_RSA Ephemeral DH with RSA signatures None
3794 DH_anon Anonymous DH, no signatures None
3795 DH_DSS DH with DSS-based certificates None
3796 DH_RSA DH with RSA-based certificates None
3797 RSA = none
3798 NULL No key exchange N/A
3799 RSA RSA key exchange None
3810 Dierks & Rescorla Standards Track [Page 68]
3811 \f
3812 RFC 4346 The TLS Protocol April 2006
3815 Key Expanded IV Block
3816 Cipher Type Material Key Material Size Size
3818 NULL Stream 0 0 0 N/A
3819 IDEA_CBC Block 16 16 8 8
3820 RC2_CBC_40 Block 5 16 8 8
3821 RC4_40 Stream 5 16 0 N/A
3822 RC4_128 Stream 16 16 0 N/A
3823 DES40_CBC Block 5 8 8 8
3824 DES_CBC Block 8 8 8 8
3825 3DES_EDE_CBC Block 24 24 8 8
3827 Type
3828 Indicates whether this is a stream cipher or a block cipher
3829 running in CBC mode.
3831 Key Material
3832 The number of bytes from the key_block that are used for
3833 generating the write keys.
3835 Expanded Key Material
3836 The number of bytes actually fed into the encryption algorithm.
3838 IV Size
3839 The amount of data needed to be generated for the initialization
3840 vector. Zero for stream ciphers; equal to the block size for
3841 block ciphers.
3843 Block Size
3844 The amount of data a block cipher enciphers in one chunk; a block
3845 cipher running in CBC mode can only encrypt an even multiple of
3846 its block size.
3848 Hash Hash Padding
3849 function Size Size
3850 NULL 0 0
3851 MD5 16 48
3852 SHA 20 40
3854 Appendix D. Implementation Notes
3856 The TLS protocol cannot prevent many common security mistakes. This
3857 section provides several recommendations to assist implementors.
3866 Dierks & Rescorla Standards Track [Page 69]
3867 \f
3868 RFC 4346 The TLS Protocol April 2006
3871 D.1. Random Number Generation and Seeding
3873 TLS requires a cryptographically secure pseudorandom number generator
3874 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
3875 based on secure hash operations, most notably MD5 and/or SHA, are
3876 acceptable, but cannot provide more security than the size of the
3877 random number generator state. (For example, MD5-based PRNGs usually
3878 provide 128 bits of state.)
3880 To estimate the amount of seed material being produced, add the
3881 number of bits of unpredictable information in each seed byte. For
3882 example, keystroke timing values taken from a PC compatible's 18.2 Hz
3883 timer provide 1 or 2 secure bits each, even though the total size of
3884 the counter value is 16 bits or more. Seeding a 128-bit PRNG would
3885 thus require approximately 100 such timer values.
3887 [RANDOM] provides guidance on the generation of random values.
3889 D.2 Certificates and Authentication
3891 Implementations are responsible for verifying the integrity of
3892 certificates and should generally support certificate revocation
3893 messages. Certificates should always be verified to ensure proper
3894 signing by a trusted Certificate Authority (CA). The selection and
3895 addition of trusted CAs should be done very carefully. Users should
3896 be able to view information about the certificate and root CA.
3898 D.3 CipherSuites
3900 TLS supports a range of key sizes and security levels, including some
3901 that provide no or minimal security. A proper implementation will
3902 probably not support many cipher suites. For example, 40-bit
3903 encryption is easily broken, so implementations requiring strong
3904 security should not allow 40-bit keys. Similarly, anonymous Diffie-
3905 Hellman is strongly discouraged because it cannot prevent man-in-
3906 the-middle attacks. Applications should also enforce minimum and
3907 maximum key sizes. For example, certificate chains containing 512-
3908 bit RSA keys or signatures are not appropriate for high-security
3909 applications.
3922 Dierks & Rescorla Standards Track [Page 70]
3923 \f
3924 RFC 4346 The TLS Protocol April 2006
3927 Appendix E. Backward Compatibility with SSL
3929 For historical reasons and in order to avoid a profligate consumption
3930 of reserved port numbers, application protocols that are secured by
3931 TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
3932 connection port. For example, the https protocol (HTTP secured by
3933 SSL or TLS) uses port 443 regardless of which security protocol it is
3934 using. Thus, some mechanism must be determined to distinguish and
3935 negotiate among the various protocols.
3937 TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
3938 supporting both is easy. TLS clients who wish to negotiate with such
3939 older servers SHOULD send client hello messages using the SSL 3.0
3940 record format and client hello structure, sending {3, 2} for the
3941 version field to note that they support TLS 1.1. If the server
3942 supports only TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0
3943 server hello; if it supports TLS 1.1 it will respond with a TLS 1.1
3944 server hello. The negotiation then proceeds as appropriate for the
3945 negotiated protocol.
3947 Similarly, a TLS 1.1 server that wishes to interoperate with TLS 1.0
3948 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages and
3949 respond with a SSL 3.0 server hello if an SSL 3.0 client hello with a
3950 version field of {3, 0} is received, denoting that this client does
3951 not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a
3952 version field of {3, 1} is received, the server SHOULD respond with a
3953 TLS 1.0 hello with a version field of {3, 1}.
3955 Whenever a client already knows the highest protocol known to a
3956 server (for example, when resuming a session), it SHOULD initiate the
3957 connection in that native protocol.
3959 TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
3960 Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
3961 either client hello format if they wish to support SSL 2.0 clients on
3962 the same connection port. The only deviations from the Version 2.0
3963 specification are the ability to specify a version with a value of
3964 three and the support for more ciphering types in the CipherSpec.
3966 Warning: The ability to send Version 2.0 client hello messages will be
3967 phased out with all due haste. Implementors SHOULD make every
3968 effort to move forward as quickly as possible. Version 3.0
3969 provides better mechanisms for moving to newer versions.
3978 Dierks & Rescorla Standards Track [Page 71]
3979 \f
3980 RFC 4346 The TLS Protocol April 2006
3983 The following cipher specifications are carryovers from SSL
3984 Version 2.0. These are assumed to use RSA for key exchange and
3985 authentication.
3987 V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
3988 V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
3989 V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
3990 V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
3991 = { 0x04,0x00,0x80 };
3992 V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
3993 V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
3994 V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
3996 Cipher specifications native to TLS can be included in Version
3997 2.0 client hello messages using the syntax below. Any
3998 V2CipherSpec element with its first byte equal to zero will be
3999 ignored by Version 2.0 servers. Clients sending any of the above
4000 V2CipherSpecs SHOULD also include the TLS equivalent (see
4001 Appendix A.5):
4003 V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
4005 Note: TLS 1.1 clients may generate the SSLv2 EXPORT cipher suites in
4006 handshakes for backward compatibility but MUST NOT negotiate them
4007 in TLS 1.1 mode.
4009 E.1. Version 2 Client Hello
4011 The Version 2.0 client hello message is presented below using this
4012 document's presentation model. The true definition is still assumed
4013 to be the SSL Version 2.0 specification. Note that this message MUST
4014 be sent directly on the wire, not wrapped as an SSLv3 record
4016 uint8 V2CipherSpec[3];
4018 struct {
4019 uint16 msg_length;
4020 uint8 msg_type;
4021 Version version;
4022 uint16 cipher_spec_length;
4023 uint16 session_id_length;
4024 uint16 challenge_length;
4025 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
4026 opaque session_id[V2ClientHello.session_id_length];
4027 opaque challenge[V2ClientHello.challenge_length;
4028 } V2ClientHello;
4034 Dierks & Rescorla Standards Track [Page 72]
4035 \f
4036 RFC 4346 The TLS Protocol April 2006
4039 msg_length
4040 This field is the length of the following data in bytes. The high
4041 bit MUST be 1 and is not part of the length.
4043 msg_type
4044 This field, in conjunction with the version field, identifies a
4045 version 2 client hello message. The value SHOULD be one (1).
4047 version
4048 The highest version of the protocol supported by the client
4049 (equals ProtocolVersion.version; see Appendix A.1).
4051 cipher_spec_length
4052 This field is the total length of the field cipher_specs. It
4053 cannot be zero and MUST be a multiple of the V2CipherSpec length
4054 (3).
4056 session_id_length
4057 This field MUST have a value of zero.
4059 challenge_length
4060 The length in bytes of the client's challenge to the server to
4061 authenticate itself. When using the SSLv2 backward compatible
4062 handshake the client MUST use a 32-byte challenge.
4064 cipher_specs
4065 This is a list of all CipherSpecs the client is willing and able
4066 to use. There MUST be at least one CipherSpec acceptable to the
4067 server.
4069 session_id
4070 This field MUST be empty.
4072 challenge The client challenge to the server for the server to
4073 identify itself is a (nearly) arbitrary-length random. The TLS
4074 server will right-justify the challenge data to become the
4075 ClientHello.random data (padded with leading zeroes, if
4076 necessary), as specified in this protocol specification. If the
4077 length of the challenge is greater than 32 bytes, only the last 32
4078 bytes are used. It is legitimate (but not necessary) for a V3
4079 server to reject a V2 ClientHello that has fewer than 16 bytes of
4080 challenge data.
4082 Note: Requests to resume a TLS session MUST use a TLS client
4083 hello.
4090 Dierks & Rescorla Standards Track [Page 73]
4091 \f
4092 RFC 4346 The TLS Protocol April 2006
4095 E.2. Avoiding Man-in-the-Middle Version Rollback
4097 When TLS clients fall back to Version 2.0 compatibility mode, they
4098 SHOULD use special PKCS #1 block formatting. This is done so that
4099 TLS servers will reject Version 2.0 sessions with TLS-capable
4100 clients.
4102 When TLS clients are in Version 2.0 compatibility mode, they set the
4103 right-hand (least significant) 8 random bytes of the PKCS padding
4104 (not including the terminal null of the padding) for the RSA
4105 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
4106 to 0x03 (the other padding bytes are random). After decrypting the
4107 ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
4108 error if these eight padding bytes are 0x03. Version 2.0 servers
4109 receiving blocks padded in this manner will proceed normally.
4111 Appendix F. Security Analysis
4113 The TLS protocol is designed to establish a secure connection between
4114 a client and a server communicating over an insecure channel. This
4115 document makes several traditional assumptions, including that
4116 attackers have substantial computational resources and cannot obtain
4117 secret information from sources outside the protocol. Attackers are
4118 assumed to have the ability to capture, modify, delete, replay, and
4119 otherwise tamper with messages sent over the communication channel.
4120 This appendix outlines how TLS has been designed to resist a variety
4121 of attacks.
4123 F.1. Handshake Protocol
4125 The handshake protocol is responsible for selecting a CipherSpec and
4126 generating a Master Secret, which together comprise the primary
4127 cryptographic parameters associated with a secure session. The
4128 handshake protocol can also optionally authenticate parties who have
4129 certificates signed by a trusted certificate authority.
4131 F.1.1. Authentication and Key Exchange
4133 TLS supports three authentication modes: authentication of both
4134 parties, server authentication with an unauthenticated client, and
4135 total anonymity. Whenever the server is authenticated, the channel
4136 is secure against man-in-the-middle attacks, but completely anonymous
4137 sessions are inherently vulnerable to such attacks. Anonymous
4138 servers cannot authenticate clients. If the server is authenticated,
4139 its certificate message must provide a valid certificate chain
4140 leading to an acceptable certificate authority. Similarly,
4141 authenticated clients must supply an acceptable certificate to the
4146 Dierks & Rescorla Standards Track [Page 74]
4147 \f
4148 RFC 4346 The TLS Protocol April 2006
4151 server. Each party is responsible for verifying that the other's
4152 certificate is valid and has not expired or been revoked.
4154 The general goal of the key exchange process is to create a
4155 pre_master_secret known to the communicating parties and not to
4156 attackers. The pre_master_secret will be used to generate the
4157 master_secret (see Section 8.1). The master_secret is required to
4158 generate the finished messages, encryption keys, and MAC secrets (see
4159 Sections 7.4.8, 7.4.9, and 6.3). By sending a correct finished
4160 message, parties thus prove that they know the correct
4161 pre_master_secret.
4163 F.1.1.1. Anonymous Key Exchange
4165 Completely anonymous sessions can be established using RSA or Diffie-
4166 Hellman for key exchange. With anonymous RSA, the client encrypts a
4167 pre_master_secret with the server's uncertified public key extracted
4168 from the server key exchange message. The result is sent in a client
4169 key exchange message. Since eavesdroppers do not know the server's
4170 private key, it will be infeasible for them to decode the
4171 pre_master_secret.
4173 Note: No anonymous RSA Cipher Suites are defined in this document.
4175 With Diffie-Hellman, the server's public parameters are contained in
4176 the server key exchange message and the client's are sent in the
4177 client key exchange message. Eavesdroppers who do not know the
4178 private values should not be able to find the Diffie-Hellman result
4179 (i.e., the pre_master_secret).
4181 Warning: Completely anonymous connections only provide protection
4182 against passive eavesdropping. Unless an independent
4183 tamper-proof channel is used to verify that the finished
4184 messages were not replaced by an attacker, server
4185 authentication is required in environments where active
4186 man-in-the-middle attacks are a concern.
4188 F.1.1.2. RSA Key Exchange and Authentication
4190 With RSA, key exchange and server authentication are combined. The
4191 public key either may be contained in the server's certificate or may
4192 be a temporary RSA key sent in a server key exchange message. When
4193 temporary RSA keys are used, they are signed by the server's RSA
4194 certificate. The signature includes the current ClientHello.random,
4195 so old signatures and temporary keys cannot be replayed. Servers may
4196 use a single temporary RSA key for multiple negotiation sessions.
4198 Note: The temporary RSA key option is useful if servers need large
4202 Dierks & Rescorla Standards Track [Page 75]
4203 \f
4204 RFC 4346 The TLS Protocol April 2006
4207 certificates but must comply with government-imposed size
4208 limits on keys used for key exchange.
4210 Note that if ephemeral RSA is not used, compromise of the server's
4211 static RSA key results in a loss of confidentiality for all sessions
4212 protected under that static key. TLS users desiring Perfect Forward
4213 Secrecy should use DHE cipher suites. The damage done by exposure of
4214 a private key can be limited by changing one's private key (and
4215 certificate) frequently.
4217 After verifying the server's certificate, the client encrypts a
4218 pre_master_secret with the server's public key. By successfully
4219 decoding the pre_master_secret and producing a correct finished
4220 message, the server demonstrates that it knows the private key
4221 corresponding to the server certificate.
4223 When RSA is used for key exchange, clients are authenticated using
4224 the certificate verify message (see Section 7.4.8). The client signs
4225 a value derived from the master_secret and all preceding handshake
4226 messages. These handshake messages include the server certificate,
4227 which binds the signature to the server, and ServerHello.random,
4228 which binds the signature to the current handshake process.
4230 F.1.1.3. Diffie-Hellman Key Exchange with Authentication
4232 When Diffie-Hellman key exchange is used, the server can either
4233 supply a certificate containing fixed Diffie-Hellman parameters or
4234 use the server key exchange message to send a set of temporary
4235 Diffie-Hellman parameters signed with a DSS or RSA certificate.
4236 Temporary parameters are hashed with the hello.random values before
4237 signing to ensure that attackers do not replay old parameters. In
4238 either case, the client can verify the certificate or signature to
4239 ensure that the parameters belong to the server.
4241 If the client has a certificate containing fixed Diffie-Hellman
4242 parameters, its certificate contains the information required to
4243 complete the key exchange. Note that in this case the client and
4244 server will generate the same Diffie-Hellman result (i.e.,
4245 pre_master_secret) every time they communicate. To prevent the
4246 pre_master_secret from staying in memory any longer than necessary,
4247 it should be converted into the master_secret as soon as possible.
4248 Client Diffie-Hellman parameters must be compatible with those
4249 supplied by the server for the key exchange to work.
4251 If the client has a standard DSS or RSA certificate or is
4252 unauthenticated, it sends a set of temporary parameters to the server
4253 in the client key exchange message, then optionally uses a
4254 certificate verify message to authenticate itself.
4258 Dierks & Rescorla Standards Track [Page 76]
4259 \f
4260 RFC 4346 The TLS Protocol April 2006
4263 If the same DH keypair is to be used for multiple handshakes, either
4264 because the client or server has a certificate containing a fixed DH
4265 keypair or because the server is reusing DH keys, care must be taken
4266 to prevent small subgroup attacks. Implementations SHOULD follow the
4267 guidelines found in [SUBGROUP].
4269 Small subgroup attacks are most easily avoided by using one of the
4270 DHE ciphersuites and generating a fresh DH private key (X) for each
4271 handshake. If a suitable base (such as 2) is chosen, g^X mod p can
4272 be computed very quickly, therefore the performance cost is
4273 minimized. Additionally, using a fresh key for each handshake
4274 provides Perfect Forward Secrecy. Implementations SHOULD generate a
4275 new X for each handshake when using DHE ciphersuites.
4277 F.1.2. Version Rollback Attacks
4279 Because TLS includes substantial improvements over SSL Version 2.0,
4280 attackers may try to make TLS-capable clients and servers fall back
4281 to Version 2.0. This attack can occur if (and only if) two TLS-
4282 capable parties use an SSL 2.0 handshake.
4284 Although the solution using non-random PKCS #1 block type 2 message
4285 padding is inelegant, it provides a reasonably secure way for Version
4286 3.0 servers to detect the attack. This solution is not secure
4287 against attackers who can brute force the key and substitute a new
4288 ENCRYPTED-KEY-DATA message containing the same key (but with normal
4289 padding) before the application specified wait threshold has expired.
4290 Parties concerned about attacks of this scale should not use 40-bit
4291 encryption keys. Altering the padding of the least-significant 8
4292 bytes of the PKCS padding does not impact security for the size of
4293 the signed hashes and RSA key lengths used in the protocol, since
4294 this is essentially equivalent to increasing the input block size by
4295 8 bytes.
4297 F.1.3. Detecting Attacks against the Handshake Protocol
4299 An attacker might try to influence the handshake exchange to make the
4300 parties select different encryption algorithms than they would
4301 normally chooses.
4303 For this attack, an attacker must actively change one or more
4304 handshake messages. If this occurs, the client and server will
4305 compute different values for the handshake message hashes. As a
4306 result, the parties will not accept each others' finished messages.
4307 Without the master_secret, the attacker cannot repair the finished
4308 messages, so the attack will be discovered.
4314 Dierks & Rescorla Standards Track [Page 77]
4315 \f
4316 RFC 4346 The TLS Protocol April 2006
4319 F.1.4. Resuming Sessions
4321 When a connection is established by resuming a session, new
4322 ClientHello.random and ServerHello.random values are hashed with the
4323 session's master_secret. Provided that the master_secret has not
4324 been compromised and that the secure hash operations used to produce
4325 the encryption keys and MAC secrets are secure, the connection should
4326 be secure and effectively independent from previous connections.
4327 Attackers cannot use known encryption keys or MAC secrets to
4328 compromise the master_secret without breaking the secure hash
4329 operations (which use both SHA and MD5).
4331 Sessions cannot be resumed unless both the client and server agree.
4332 If either party suspects that the session may have been compromised,
4333 or that certificates may have expired or been revoked, it should
4334 force a full handshake. An upper limit of 24 hours is suggested for
4335 session ID lifetimes, since an attacker who obtains a master_secret
4336 may be able to impersonate the compromised party until the
4337 corresponding session ID is retired. Applications that may be run in
4338 relatively insecure environments should not write session IDs to
4339 stable storage.
4341 F.1.5. MD5 and SHA
4343 TLS uses hash functions very conservatively. Where possible, both
4344 MD5 and SHA are used in tandem to ensure that non-catastrophic flaws
4345 in one algorithm will not break the overall protocol.
4347 F.2. Protecting Application Data
4349 The master_secret is hashed with the ClientHello.random and
4350 ServerHello.random to produce unique data encryption keys and MAC
4351 secrets for each connection.
4353 Outgoing data is protected with a MAC before transmission. To
4354 prevent message replay or modification attacks, the MAC is computed
4355 from the MAC secret, the sequence number, the message length, the
4356 message contents, and two fixed character strings. The message type
4357 field is necessary to ensure that messages intended for one TLS
4358 Record Layer client are not redirected to another. The sequence
4359 number ensures that attempts to delete or reorder messages will be
4360 detected. Since sequence numbers are 64 bits long, they should never
4361 overflow. Messages from one party cannot be inserted into the
4362 other's output, since they use independent MAC secrets. Similarly,
4363 the server-write and client-write keys are independent, so stream
4364 cipher keys are used only once.
4370 Dierks & Rescorla Standards Track [Page 78]
4371 \f
4372 RFC 4346 The TLS Protocol April 2006
4375 If an attacker does break an encryption key, all messages encrypted
4376 with it can be read. Similarly, compromise of a MAC key can make
4377 message modification attacks possible. Because MACs are also
4378 encrypted, message-alteration attacks generally require breaking the
4379 encryption algorithm as well as the MAC.
4381 Note: MAC secrets may be larger than encryption keys, so messages can
4382 remain tamper resistant even if encryption keys are broken.
4384 F.3. Explicit IVs
4386 [CBCATT] describes a chosen plaintext attack on TLS that depends on
4387 knowing the IV for a record. Previous versions of TLS [TLS1.0] used
4388 the CBC residue of the previous record as the IV and therefore
4389 enabled this attack. This version uses an explicit IV in order to
4390 protect against this attack.
4392 F.4. Security of Composite Cipher Modes
4394 TLS secures transmitted application data via the use of symmetric
4395 encryption and authentication functions defined in the negotiated
4396 ciphersuite. The objective is to protect both the integrity and
4397 confidentiality of the transmitted data from malicious actions by
4398 active attackers in the network. It turns out that the order in
4399 which encryption and authentication functions are applied to the data
4400 plays an important role for achieving this goal [ENCAUTH].
4402 The most robust method, called encrypt-then-authenticate, first
4403 applies encryption to the data and then applies a MAC to the
4404 ciphertext. This method ensures that the integrity and
4405 confidentiality goals are obtained with ANY pair of encryption and
4406 MAC functions, provided that the former is secure against chosen
4407 plaintext attacks and that the MAC is secure against chosen-message
4408 attacks. TLS uses another method, called authenticate-then-encrypt,
4409 in which first a MAC is computed on the plaintext and then the
4410 concatenation of plaintext and MAC is encrypted. This method has
4411 been proven secure for CERTAIN combinations of encryption functions
4412 and MAC functions, but it is not guaranteed to be secure in general.
4413 In particular, it has been shown that there exist perfectly secure
4414 encryption functions (secure even in the information-theoretic sense)
4415 that combined with any secure MAC function, fail to provide the
4416 confidentiality goal against an active attack. Therefore, new
4417 ciphersuites and operation modes adopted into TLS need to be analyzed
4418 under the authenticate-then-encrypt method to verify that they
4419 achieve the stated integrity and confidentiality goals.
4426 Dierks & Rescorla Standards Track [Page 79]
4427 \f
4428 RFC 4346 The TLS Protocol April 2006
4431 Currently, the security of the authenticate-then-encrypt method has
4432 been proven for some important cases. One is the case of stream
4433 ciphers in which a computationally unpredictable pad of the length of
4434 the message, plus the length of the MAC tag, is produced using a
4435 pseudo-random generator and this pad is xor-ed with the concatenation
4436 of plaintext and MAC tag. The other is the case of CBC mode using a
4437 secure block cipher. In this case, security can be shown if one
4438 applies one CBC encryption pass to the concatenation of plaintext and
4439 MAC and uses a new, independent, and unpredictable IV for each new
4440 pair of plaintext and MAC. In previous versions of SSL, CBC mode was
4441 used properly EXCEPT that it used a predictable IV in the form of the
4442 last block of the previous ciphertext. This made TLS open to chosen
4443 plaintext attacks. This version of the protocol is immune to those
4444 attacks. For exact details in the encryption modes proven secure,
4445 see [ENCAUTH].
4447 F.5. Denial of Service
4449 TLS is susceptible to a number of denial of service (DoS) attacks.
4450 In particular, an attacker who initiates a large number of TCP
4451 connections can cause a server to consume large amounts of CPU doing
4452 RSA decryption. However, because TLS is generally used over TCP, it
4453 is difficult for the attacker to hide his point of origin if proper
4454 TCP SYN randomization is used [SEQNUM] by the TCP stack.
4456 Because TLS runs over TCP, it is also susceptible to a number of
4457 denial of service attacks on individual connections. In particular,
4458 attackers can forge RSTs, thereby terminating connections, or forge
4459 partial TLS records, thereby causing the connection to stall. These
4460 attacks cannot in general be defended against by a TCP-using
4461 protocol. Implementors or users who are concerned with this class of
4462 attack should use IPsec AH [AH-ESP] or ESP [AH-ESP].
4464 F.6. Final Notes
4466 For TLS to be able to provide a secure connection, both the client
4467 and server systems, keys, and applications must be secure. In
4468 addition, the implementation must be free of security errors.
4470 The system is only as strong as the weakest key exchange and
4471 authentication algorithm supported, and only trustworthy
4472 cryptographic functions should be used. Short public keys, 40-bit
4473 bulk encryption keys, and anonymous servers should be used with great
4474 caution. Implementations and users must be careful when deciding
4475 which certificates and certificate authorities are acceptable; a
4476 dishonest certificate authority can do tremendous damage.
4482 Dierks & Rescorla Standards Track [Page 80]
4483 \f
4484 RFC 4346 The TLS Protocol April 2006
4487 Normative References
4489 [AES] National Institute of Standards and Technology,
4490 "Specification for the Advanced Encryption Standard (AES)"
4491 FIPS 197. November 26, 2001.
4493 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To
4494 DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
4496 [DES] ANSI X3.106, "American National Standard for Information
4497 Systems-Data Link Encryption," American National Standards
4498 Institute, 1983.
4500 [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard,"
4501 National Institute of Standards and Technology, U.S.
4502 Department of Commerce, 2000.
4504 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
4505 Hashing for Message Authentication", RFC 2104, February
4506 1997.
4508 [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
4509 Series in Information Processing, v. 1, Konstanz:
4510 Hartung-Gorre Verlag, 1992.
4512 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321,
4513 April 1992.
4515 [PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
4516 RSA Cryptography Specifications Version 1.5", RFC 2313,
4517 March 1998.
4519 [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
4520 (PKCS) #1: RSA Cryptography Specifications Version 2.1",
4521 RFC 3447, February 2003.
4523 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
4524 X.509 Public Key Infrastructure Certificate and
4525 Certificate Revocation List (CRL) Profile", RFC 3280,
4526 April 2002.
4528 [RC2] Rivest, R., "A Description of the RC2(r) Encryption
4529 Algorithm", RFC 2268, March 1998.
4531 [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
4532 and Source Code in C, 2ed", Published by John Wiley &
4533 Sons, Inc. 1996.
4538 Dierks & Rescorla Standards Track [Page 81]
4539 \f
4540 RFC 4346 The TLS Protocol April 2006
4543 [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
4544 Institute of Standards and Technology, U.S. Department of
4545 Commerce., August 2001.
4547 [REQ] Bradner, S., "Key words for use in RFCs to Indicate
4548 Requirement Levels", BCP 14, RFC 2119, March 1997.
4550 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
4551 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
4552 October 1998.
4554 [TLSAES] Chown, P., "Advanced Encryption Standard (AES)
4555 Ciphersuites for Transport Layer Security (TLS)", RFC
4556 3268, June 2002.
4558 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
4559 and T. Wright, "Transport Layer Security (TLS)
4560 Extensions", RFC 3546, June 2003.
4562 [TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
4563 Suites to Transport Layer Security (TLS)", RFC 2712,
4564 October 1999.
4566 Informative References
4568 [AH-ESP] Kent, S., "IP Authentication Header", RFC 4302, December
4569 2005.
4571 Eastlake 3rd, D., "Cryptographic Algorithm Implementation
4572 Requirements for Encapsulating Security Payload (ESP) and
4573 Authentication Header (AH)", RFC 4305, December 2005.
4575 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
4576 Protocols Based on RSA Encryption Standard PKCS #1" in
4577 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462,
4578 pages: 1-12, 1998.
4580 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
4581 Problems and Countermeasures",
4582 http://www.openssl.org/~bodo/tls-cbc.txt.
4584 [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
4585 http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
4587 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
4588 for Protecting Communications (Or: How Secure is SSL?)",
4589 Crypto 2001.
4594 Dierks & Rescorla Standards Track [Page 82]
4595 \f
4596 RFC 4346 The TLS Protocol April 2006
4599 [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
4600 Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
4601 March 2003.
4603 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate
4604 Syntax Standard," version 1.5, November 1993.
4606 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message
4607 Syntax Standard," version 1.5, November 1993.
4609 [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
4610 "Randomness Requirements for Security", BCP 106, RFC 4086,
4611 June 2005.
4613 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
4614 Obtaining Digital Signatures and Public-Key
4615 Cryptosystems," Communications of the ACM, v. 21, n. 2,
4616 Feb 1978, pp. 120-126.
4618 [SEQNUM] Bellovin, S., "Defending Against Sequence Number Attacks",
4619 RFC 1948, May 1996.
4621 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
4622 Corp., Feb 9, 1995.
4624 [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0
4625 Protocol", Netscape Communications Corp., Nov 18, 1996.
4627 [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
4628 Attacks on the Diffie-Hellman Key Agreement Method for
4629 S/MIME", RFC 2785, March 2000.
4631 [TCP] Hellstrom, G. and P. Jones, "RTP Payload for Text
4632 Conversation", RFC 4103, June 2005.
4634 [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
4635 practical", USENIX Security Symposium 2003.
4637 [TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
4638 RFC 2246, January 1999.
4640 [X501] ITU-T Recommendation X.501: Information Technology - Open
4641 Systems Interconnection - The Directory: Models, 1993.
4643 [X509] ITU-T Recommendation X.509 (1997 E): Information
4644 Technology - Open Systems Interconnection - "The Directory
4645 - Authentication Framework". 1988.
4650 Dierks & Rescorla Standards Track [Page 83]
4651 \f
4652 RFC 4346 The TLS Protocol April 2006
4655 [XDR] Srinivasan, R., "XDR: External Data Representation
4656 Standard", RFC 1832, August 1995.
4658 Authors' Addresses
4660 Working Group Chairs
4662 Win Treese
4664 EMail: treese@acm.org
4667 Eric Rescorla
4669 EMail: ekr@rtfm.com
4671 Editors
4673 Tim Dierks
4674 Independent
4676 EMail: tim@dierks.org
4679 Eric Rescorla
4680 RTFM, Inc.
4682 EMail: ekr@rtfm.com
4684 Other Contributors
4686 Christopher Allen (co-editor of TLS 1.0)
4687 Alacrity Ventures
4688 EMail: ChristopherA@AlacrityManagement.com
4691 Martin Abadi
4692 University of California, Santa Cruz
4693 EMail: abadi@cs.ucsc.edu
4696 Ran Canetti
4697 IBM
4698 EMail: canetti@watson.ibm.com
4706 Dierks & Rescorla Standards Track [Page 84]
4707 \f
4708 RFC 4346 The TLS Protocol April 2006
4711 Taher Elgamal
4712 Securify
4713 EMail: taher@securify.com
4716 Anil Gangolli
4717 EMail: anil@busybuddha.org
4720 Kipp Hickman
4723 Phil Karlton (co-author of SSLv3)
4726 Paul Kocher (co-author of SSLv3)
4727 Cryptography Research
4728 EMail: paul@cryptography.com
4731 Hugo Krawczyk
4732 Technion Israel Institute of Technology
4733 EMail: hugo@ee.technion.ac.il
4736 Robert Relyea
4737 Netscape Communications
4738 EMail: relyea@netscape.com
4741 Jim Roskind
4742 Netscape Communications
4743 EMail: jar@netscape.com
4746 Michael Sabin
4749 Dan Simon
4750 Microsoft, Inc.
4751 EMail: dansimon@microsoft.com
4754 Tom Weinstein
4762 Dierks & Rescorla Standards Track [Page 85]
4763 \f
4764 RFC 4346 The TLS Protocol April 2006
4767 Comments
4769 The discussion list for the IETF TLS working group is located at the
4770 e-mail address <ietf-tls@lists.consensus.com>. Information on the
4771 group and information on how to subscribe to the list is at
4772 <http://lists.consensus.com/>.
4774 Archives of the list can be found at:
4775 <http://www.imc.org/ietf-tls/mail-archive/>
4818 Dierks & Rescorla Standards Track [Page 86]
4819 \f
4820 RFC 4346 The TLS Protocol April 2006
4823 Full Copyright Statement
4825 Copyright (C) The Internet Society (2006).
4827 This document is subject to the rights, licenses and restrictions
4828 contained in BCP 78, and except as set forth therein, the authors
4829 retain all their rights.
4831 This document and the information contained herein are provided on an
4832 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
4833 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
4834 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
4835 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
4836 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
4837 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
4839 Intellectual Property
4841 The IETF takes no position regarding the validity or scope of any
4842 Intellectual Property Rights or other rights that might be claimed to
4843 pertain to the implementation or use of the technology described in
4844 this document or the extent to which any license under such rights
4845 might or might not be available; nor does it represent that it has
4846 made any independent effort to identify any such rights. Information
4847 on the procedures with respect to rights in RFC documents can be
4848 found in BCP 78 and BCP 79.
4850 Copies of IPR disclosures made to the IETF Secretariat and any
4851 assurances of licenses to be made available, or the result of an
4852 attempt made to obtain a general license or permission for the use of
4853 such proprietary rights by implementers or users of this
4854 specification can be obtained from the IETF on-line IPR repository at
4855 http://www.ietf.org/ipr.
4857 The IETF invites any interested party to bring to its attention any
4858 copyrights, patents or patent applications, or other proprietary
4859 rights that may cover technology that may be required to implement
4860 this standard. Please address the information to the IETF at
4861 ietf-ipr@ietf.org.
4863 Acknowledgement
4865 Funding for the RFC Editor function is provided by the IETF
4866 Administrative Support Activity (IASA).
4874 Dierks & Rescorla Standards Track [Page 87]
4875 \f