| blob | 2e838cf5d5e8b71d3f97c946c9d22903b35e4054 |
7 Network Working Group T. Dierks
8 Request for Comments: 2246 Certicom
9 Category: Standards Track C. Allen
10 Certicom
11 January 1999
14 The TLS Protocol
15 Version 1.0
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 (1999). All Rights Reserved.
29 Abstract
31 This document specifies Version 1.0 of the Transport Layer Security
32 (TLS) protocol. The TLS protocol provides communications privacy over
33 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.
37 Table of Contents
39 1. Introduction 3
40 2. Goals 4
41 3. Goals of this document 5
42 4. Presentation language 5
43 4.1. Basic block size 6
44 4.2. Miscellaneous 6
45 4.3. Vectors 6
46 4.4. Numbers 7
47 4.5. Enumerateds 7
48 4.6. Constructed types 8
49 4.6.1. Variants 9
50 4.7. Cryptographic attributes 10
51 4.8. Constants 11
52 5. HMAC and the pseudorandom function 11
53 6. The TLS Record Protocol 13
54 6.1. Connection states 14
58 Dierks & Allen Standards Track [Page 1]
59 \f
60 RFC 2246 The TLS Protocol Version 1.0 January 1999
63 6.2. Record layer 16
64 6.2.1. Fragmentation 16
65 6.2.2. Record compression and decompression 17
66 6.2.3. Record payload protection 18
67 6.2.3.1. Null or standard stream cipher 19
68 6.2.3.2. CBC block cipher 19
69 6.3. Key calculation 21
70 6.3.1. Export key generation example 22
71 7. The TLS Handshake Protocol 23
72 7.1. Change cipher spec protocol 24
73 7.2. Alert protocol 24
74 7.2.1. Closure alerts 25
75 7.2.2. Error alerts 26
76 7.3. Handshake Protocol overview 29
77 7.4. Handshake protocol 32
78 7.4.1. Hello messages 33
79 7.4.1.1. Hello request 33
80 7.4.1.2. Client hello 34
81 7.4.1.3. Server hello 36
82 7.4.2. Server certificate 37
83 7.4.3. Server key exchange message 39
84 7.4.4. Certificate request 41
85 7.4.5. Server hello done 42
86 7.4.6. Client certificate 43
87 7.4.7. Client key exchange message 43
88 7.4.7.1. RSA encrypted premaster secret message 44
89 7.4.7.2. Client Diffie-Hellman public value 45
90 7.4.8. Certificate verify 45
91 7.4.9. Finished 46
92 8. Cryptographic computations 47
93 8.1. Computing the master secret 47
94 8.1.1. RSA 48
95 8.1.2. Diffie-Hellman 48
96 9. Mandatory Cipher Suites 48
97 10. Application data protocol 48
98 A. Protocol constant values 49
99 A.1. Record layer 49
100 A.2. Change cipher specs message 50
101 A.3. Alert messages 50
102 A.4. Handshake protocol 51
103 A.4.1. Hello messages 51
104 A.4.2. Server authentication and key exchange messages 52
105 A.4.3. Client authentication and key exchange messages 53
106 A.4.4. Handshake finalization message 54
107 A.5. The CipherSuite 54
108 A.6. The Security Parameters 56
109 B. Glossary 57
110 C. CipherSuite definitions 61
114 Dierks & Allen Standards Track [Page 2]
115 \f
116 RFC 2246 The TLS Protocol Version 1.0 January 1999
119 D. Implementation Notes 64
120 D.1. Temporary RSA keys 64
121 D.2. Random Number Generation and Seeding 64
122 D.3. Certificates and authentication 65
123 D.4. CipherSuites 65
124 E. Backward Compatibility With SSL 66
125 E.1. Version 2 client hello 67
126 E.2. Avoiding man-in-the-middle version rollback 68
127 F. Security analysis 69
128 F.1. Handshake protocol 69
129 F.1.1. Authentication and key exchange 69
130 F.1.1.1. Anonymous key exchange 69
131 F.1.1.2. RSA key exchange and authentication 70
132 F.1.1.3. Diffie-Hellman key exchange with authentication 71
133 F.1.2. Version rollback attacks 71
134 F.1.3. Detecting attacks against the handshake protocol 72
135 F.1.4. Resuming sessions 72
136 F.1.5. MD5 and SHA 72
137 F.2. Protecting application data 72
138 F.3. Final notes 73
139 G. Patent Statement 74
140 Security Considerations 75
141 References 75
142 Credits 77
143 Comments 78
144 Full Copyright Statement 80
146 1. Introduction
148 The primary goal of the TLS Protocol is to provide privacy and data
149 integrity between two communicating applications. The protocol is
150 composed of two layers: the TLS Record Protocol and the TLS Handshake
151 Protocol. At the lowest level, layered on top of some reliable
152 transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
153 TLS Record Protocol provides connection security that has two basic
154 properties:
156 - The connection is private. Symmetric cryptography is used for
157 data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for
158 this symmetric encryption are generated uniquely for each
159 connection and are based on a secret negotiated by another
160 protocol (such as the TLS Handshake Protocol). The Record
161 Protocol can also be used without encryption.
163 - The connection is reliable. Message transport includes a message
164 integrity check using a keyed MAC. Secure hash functions (e.g.,
165 SHA, MD5, etc.) are used for MAC computations. The Record
166 Protocol can operate without a MAC, but is generally only used in
170 Dierks & Allen Standards Track [Page 3]
171 \f
172 RFC 2246 The TLS Protocol Version 1.0 January 1999
175 this mode while another protocol is using the Record Protocol as
176 a transport for negotiating security parameters.
178 The TLS Record Protocol is used for encapsulation of various higher
179 level protocols. One such encapsulated protocol, the TLS Handshake
180 Protocol, allows the server and client to authenticate each other and
181 to negotiate an encryption algorithm and cryptographic keys before
182 the application protocol transmits or receives its first byte of
183 data. The TLS Handshake Protocol provides connection security that
184 has three basic properties:
186 - The peer's identity can be authenticated using asymmetric, or
187 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
188 authentication can be made optional, but is generally required
189 for at least one of the peers.
191 - The negotiation of a shared secret is secure: the negotiated
192 secret is unavailable to eavesdroppers, and for any authenticated
193 connection the secret cannot be obtained, even by an attacker who
194 can place himself in the middle of the connection.
196 - The negotiation is reliable: no attacker can modify the
197 negotiation communication without being detected by the parties
198 to the communication.
200 One advantage of TLS is that it is application protocol independent.
201 Higher level protocols can layer on top of the TLS Protocol
202 transparently. The TLS standard, however, does not specify how
203 protocols add security with TLS; the decisions on how to initiate TLS
204 handshaking and how to interpret the authentication certificates
205 exchanged are left up to the judgment of the designers and
206 implementors of protocols which run on top of TLS.
208 2. Goals
210 The goals of TLS Protocol, in order of their priority, are:
212 1. Cryptographic security: TLS should be used to establish a secure
213 connection between two parties.
215 2. Interoperability: Independent programmers should be able to
216 develop applications utilizing TLS that will then be able to
217 successfully exchange cryptographic parameters without knowledge
218 of one another's code.
220 3. Extensibility: TLS seeks to provide a framework into which new
221 public key and bulk encryption methods can be incorporated as
222 necessary. This will also accomplish two sub-goals: to prevent
226 Dierks & Allen Standards Track [Page 4]
227 \f
228 RFC 2246 The TLS Protocol Version 1.0 January 1999
231 the need to create a new protocol (and risking the introduction
232 of possible new weaknesses) and to avoid the need to implement an
233 entire new security library.
235 4. Relative efficiency: Cryptographic operations tend to be highly
236 CPU intensive, particularly public key operations. For this
237 reason, the TLS protocol has incorporated an optional session
238 caching scheme to reduce the number of connections that need to
239 be established from scratch. Additionally, care has been taken to
240 reduce network activity.
242 3. Goals of this document
244 This document and the TLS protocol itself are based on the SSL 3.0
245 Protocol Specification as published by Netscape. The differences
246 between this protocol and SSL 3.0 are not dramatic, but they are
247 significant enough that TLS 1.0 and SSL 3.0 do not interoperate
248 (although TLS 1.0 does incorporate a mechanism by which a TLS
249 implementation can back down to SSL 3.0). This document is intended
250 primarily for readers who will be implementing the protocol and those
251 doing cryptographic analysis of it. The specification has been
252 written with this in mind, and it is intended to reflect the needs of
253 those two groups. For that reason, many of the algorithm-dependent
254 data structures and rules are included in the body of the text (as
255 opposed to in an appendix), providing easier access to them.
257 This document is not intended to supply any details of service
258 definition nor interface definition, although it does cover select
259 areas of policy as they are required for the maintenance of solid
260 security.
262 4. Presentation language
264 This document deals with the formatting of data in an external
265 representation. The following very basic and somewhat casually
266 defined presentation syntax will be used. The syntax draws from
267 several sources in its structure. Although it resembles the
268 programming language "C" in its syntax and XDR [XDR] in both its
269 syntax and intent, it would be risky to draw too many parallels. The
270 purpose of this presentation language is to document TLS only, not to
271 have general application beyond that particular goal.
282 Dierks & Allen Standards Track [Page 5]
283 \f
284 RFC 2246 The TLS Protocol Version 1.0 January 1999
287 4.1. Basic block size
289 The representation of all data items is explicitly specified. The
290 basic data block size is one byte (i.e. 8 bits). Multiple byte data
291 items are concatenations of bytes, from left to right, from top to
292 bottom. From the bytestream a multi-byte item (a numeric in the
293 example) is formed (using C notation) by:
295 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
296 ... | byte[n-1];
298 This byte ordering for multi-byte values is the commonplace network
299 byte order or big endian format.
301 4.2. Miscellaneous
303 Comments begin with "/*" and end with "*/".
305 Optional components are denoted by enclosing them in "[[ ]]" double
306 brackets.
308 Single byte entities containing uninterpreted data are of type
309 opaque.
311 4.3. Vectors
313 A vector (single dimensioned array) is a stream of homogeneous data
314 elements. The size of the vector may be specified at documentation
315 time or left unspecified until runtime. In either case the length
316 declares the number of bytes, not the number of elements, in the
317 vector. The syntax for specifying a new type T' that is a fixed
318 length vector of type T is
320 T T'[n];
322 Here T' occupies n bytes in the data stream, where n is a multiple of
323 the size of T. The length of the vector is not included in the
324 encoded stream.
326 In the following example, Datum is defined to be three consecutive
327 bytes that the protocol does not interpret, while Data is three
328 consecutive Datum, consuming a total of nine bytes.
330 opaque Datum[3]; /* three uninterpreted bytes */
331 Datum Data[9]; /* 3 consecutive 3 byte vectors */
338 Dierks & Allen Standards Track [Page 6]
339 \f
340 RFC 2246 The TLS Protocol Version 1.0 January 1999
343 Variable length vectors are defined by specifying a subrange of legal
344 lengths, inclusively, using the notation <floor..ceiling>. When
345 encoded, the actual length precedes the vector's contents in the byte
346 stream. The length will be in the form of a number consuming as many
347 bytes as required to hold the vector's specified maximum (ceiling)
348 length. A variable length vector with an actual length field of zero
349 is referred to as an empty vector.
351 T T'<floor..ceiling>;
353 In the following example, mandatory is a vector that must contain
354 between 300 and 400 bytes of type opaque. It can never be empty. The
355 actual length field consumes two bytes, a uint16, sufficient to
356 represent the value 400 (see Section 4.4). On the other hand, longer
357 can represent up to 800 bytes of data, or 400 uint16 elements, and it
358 may be empty. Its encoding will include a two byte actual length
359 field prepended to the vector. The length of an encoded vector must
360 be an even multiple of the length of a single element (for example, a
361 17 byte vector of uint16 would be illegal).
363 opaque mandatory<300..400>;
364 /* length field is 2 bytes, cannot be empty */
365 uint16 longer<0..800>;
366 /* zero to 400 16-bit unsigned integers */
368 4.4. Numbers
370 The basic numeric data type is an unsigned byte (uint8). All larger
371 numeric data types are formed from fixed length series of bytes
372 concatenated as described in Section 4.1 and are also unsigned. The
373 following numeric types are predefined.
375 uint8 uint16[2];
376 uint8 uint24[3];
377 uint8 uint32[4];
378 uint8 uint64[8];
380 All values, here and elsewhere in the specification, are stored in
381 "network" or "big-endian" order; the uint32 represented by the hex
382 bytes 01 02 03 04 is equivalent to the decimal value 16909060.
384 4.5. Enumerateds
386 An additional sparse data type is available called enum. A field of
387 type enum can only assume the values declared in the definition.
388 Each definition is a different type. Only enumerateds of the same
389 type may be assigned or compared. Every element of an enumerated must
394 Dierks & Allen Standards Track [Page 7]
395 \f
396 RFC 2246 The TLS Protocol Version 1.0 January 1999
399 be assigned a value, as demonstrated in the following example. Since
400 the elements of the enumerated are not ordered, they can be assigned
401 any unique value, in any order.
403 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
405 Enumerateds occupy as much space in the byte stream as would its
406 maximal defined ordinal value. The following definition would cause
407 one byte to be used to carry fields of type Color.
409 enum { red(3), blue(5), white(7) } Color;
411 One may optionally specify a value without its associated tag to
412 force the width definition without defining a superfluous element.
413 In the following example, Taste will consume two bytes in the data
414 stream but can only assume the values 1, 2 or 4.
416 enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
418 The names of the elements of an enumeration are scoped within the
419 defined type. In the first example, a fully qualified reference to
420 the second element of the enumeration would be Color.blue. Such
421 qualification is not required if the target of the assignment is well
422 specified.
424 Color color = Color.blue; /* overspecified, legal */
425 Color color = blue; /* correct, type implicit */
427 For enumerateds that are never converted to external representation,
428 the numerical information may be omitted.
430 enum { low, medium, high } Amount;
432 4.6. Constructed types
434 Structure types may be constructed from primitive types for
435 convenience. Each specification declares a new, unique type. The
436 syntax for definition is much like that of C.
438 struct {
439 T1 f1;
440 T2 f2;
441 ...
442 Tn fn;
443 } [[T]];
450 Dierks & Allen Standards Track [Page 8]
451 \f
452 RFC 2246 The TLS Protocol Version 1.0 January 1999
455 The fields within a structure may be qualified using the type's name
456 using a syntax much like that available for enumerateds. For example,
457 T.f2 refers to the second field of the previous declaration.
458 Structure definitions may be embedded.
460 4.6.1. Variants
462 Defined structures may have variants based on some knowledge that is
463 available within the environment. The selector must be an enumerated
464 type that defines the possible variants the structure defines. There
465 must be a case arm for every element of the enumeration declared in
466 the select. The body of the variant structure may be given a label
467 for reference. The mechanism by which the variant is selected at
468 runtime is not prescribed by the presentation language.
470 struct {
471 T1 f1;
472 T2 f2;
473 ....
474 Tn fn;
475 select (E) {
476 case e1: Te1;
477 case e2: Te2;
478 ....
479 case en: Ten;
480 } [[fv]];
481 } [[Tv]];
483 For example:
485 enum { apple, orange } VariantTag;
486 struct {
487 uint16 number;
488 opaque string<0..10>; /* variable length */
489 } V1;
490 struct {
491 uint32 number;
492 opaque string[10]; /* fixed length */
493 } V2;
494 struct {
495 select (VariantTag) { /* value of selector is implicit */
496 case apple: V1; /* VariantBody, tag = apple */
497 case orange: V2; /* VariantBody, tag = orange */
498 } variant_body; /* optional label on variant */
499 } VariantRecord;
501 Variant structures may be qualified (narrowed) by specifying a value
502 for the selector prior to the type. For example, a
506 Dierks & Allen Standards Track [Page 9]
507 \f
508 RFC 2246 The TLS Protocol Version 1.0 January 1999
511 orange VariantRecord
513 is a narrowed type of a VariantRecord containing a variant_body of
514 type V2.
516 4.7. Cryptographic attributes
518 The four cryptographic operations digital signing, stream cipher
519 encryption, block cipher encryption, and public key encryption are
520 designated digitally-signed, stream-ciphered, block-ciphered, and
521 public-key-encrypted, respectively. A field's cryptographic
522 processing is specified by prepending an appropriate key word
523 designation before the field's type specification. Cryptographic keys
524 are implied by the current session state (see Section 6.1).
526 In digital signing, one-way hash functions are used as input for a
527 signing algorithm. A digitally-signed element is encoded as an opaque
528 vector <0..2^16-1>, where the length is specified by the signing
529 algorithm and key.
531 In RSA signing, a 36-byte structure of two hashes (one SHA and one
532 MD5) is signed (encrypted with the private key). It is encoded with
533 PKCS #1 block type 0 or type 1 as described in [PKCS1].
535 In DSS, the 20 bytes of the SHA hash are run directly through the
536 Digital Signing Algorithm with no additional hashing. This produces
537 two values, r and s. The DSS signature is an opaque vector, as above,
538 the contents of which are the DER encoding of:
540 Dss-Sig-Value ::= SEQUENCE {
541 r INTEGER,
542 s INTEGER
543 }
545 In stream cipher encryption, the plaintext is exclusive-ORed with an
546 identical amount of output generated from a cryptographically-secure
547 keyed pseudorandom number generator.
549 In block cipher encryption, every block of plaintext encrypts to a
550 block of ciphertext. All block cipher encryption is done in CBC
551 (Cipher Block Chaining) mode, and all items which are block-ciphered
552 will be an exact multiple of the cipher block length.
554 In public key encryption, a public key algorithm is used to encrypt
555 data in such a way that it can be decrypted only with the matching
556 private key. A public-key-encrypted element is encoded as an opaque
557 vector <0..2^16-1>, where the length is specified by the signing
558 algorithm and key.
562 Dierks & Allen Standards Track [Page 10]
563 \f
564 RFC 2246 The TLS Protocol Version 1.0 January 1999
567 An RSA encrypted value is encoded with PKCS #1 block type 2 as
568 described in [PKCS1].
570 In the following example:
572 stream-ciphered struct {
573 uint8 field1;
574 uint8 field2;
575 digitally-signed opaque hash[20];
576 } UserType;
578 The contents of hash are used as input for the signing algorithm,
579 then the entire structure is encrypted with a stream cipher. The
580 length of this structure, in bytes would be equal to 2 bytes for
581 field1 and field2, plus two bytes for the length of the signature,
582 plus the length of the output of the signing algorithm. This is known
583 due to the fact that the algorithm and key used for the signing are
584 known prior to encoding or decoding this structure.
586 4.8. Constants
588 Typed constants can be defined for purposes of specification by
589 declaring a symbol of the desired type and assigning values to it.
590 Under-specified types (opaque, variable length vectors, and
591 structures that contain opaque) cannot be assigned values. No fields
592 of a multi-element structure or vector may be elided.
594 For example,
596 struct {
597 uint8 f1;
598 uint8 f2;
599 } Example1;
601 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
603 5. HMAC and the pseudorandom function
605 A number of operations in the TLS record and handshake layer required
606 a keyed MAC; this is a secure digest of some data protected by a
607 secret. Forging the MAC is infeasible without knowledge of the MAC
608 secret. The construction we use for this operation is known as HMAC,
609 described in [HMAC].
611 HMAC can be used with a variety of different hash algorithms. TLS
612 uses it in the handshake with two different algorithms: MD5 and SHA-
613 1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
618 Dierks & Allen Standards Track [Page 11]
619 \f
620 RFC 2246 The TLS Protocol Version 1.0 January 1999
623 data). Additional hash algorithms can be defined by cipher suites and
624 used to protect record data, but MD5 and SHA-1 are hard coded into
625 the description of the handshaking for this version of the protocol.
627 In addition, a construction is required to do expansion of secrets
628 into blocks of data for the purposes of key generation or validation.
629 This pseudo-random function (PRF) takes as input a secret, a seed,
630 and an identifying label and produces an output of arbitrary length.
632 In order to make the PRF as secure as possible, it uses two hash
633 algorithms in a way which should guarantee its security if either
634 algorithm remains secure.
636 First, we define a data expansion function, P_hash(secret, data)
637 which uses a single hash function to expand a secret and seed into an
638 arbitrary quantity of output:
640 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
641 HMAC_hash(secret, A(2) + seed) +
642 HMAC_hash(secret, A(3) + seed) + ...
644 Where + indicates concatenation.
646 A() is defined as:
647 A(0) = seed
648 A(i) = HMAC_hash(secret, A(i-1))
650 P_hash can be iterated as many times as is necessary to produce the
651 required quantity of data. For example, if P_SHA-1 was being used to
652 create 64 bytes of data, it would have to be iterated 4 times
653 (through A(4)), creating 80 bytes of output data; the last 16 bytes
654 of the final iteration would then be discarded, leaving 64 bytes of
655 output data.
657 TLS's PRF is created by splitting the secret into two halves and
658 using one half to generate data with P_MD5 and the other half to
659 generate data with P_SHA-1, then exclusive-or'ing the outputs of
660 these two expansion functions together.
662 S1 and S2 are the two halves of the secret and each is the same
663 length. S1 is taken from the first half of the secret, S2 from the
664 second half. Their length is created by rounding up the length of the
665 overall secret divided by two; thus, if the original secret is an odd
666 number of bytes long, the last byte of S1 will be the same as the
667 first byte of S2.
669 L_S = length in bytes of secret;
670 L_S1 = L_S2 = ceil(L_S / 2);
674 Dierks & Allen Standards Track [Page 12]
675 \f
676 RFC 2246 The TLS Protocol Version 1.0 January 1999
679 The secret is partitioned into two halves (with the possibility of
680 one shared byte) as described above, S1 taking the first L_S1 bytes
681 and S2 the last L_S2 bytes.
683 The PRF is then defined as the result of mixing the two pseudorandom
684 streams by exclusive-or'ing them together.
686 PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
687 P_SHA-1(S2, label + seed);
689 The label is an ASCII string. It should be included in the exact form
690 it is given without a length byte or trailing null character. For
691 example, the label "slithy toves" would be processed by hashing the
692 following bytes:
694 73 6C 69 74 68 79 20 74 6F 76 65 73
696 Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
697 byte outputs, the boundaries of their internal iterations will not be
698 aligned; to generate a 80 byte output will involve P_MD5 being
699 iterated through A(5), while P_SHA-1 will only iterate through A(4).
701 6. The TLS Record Protocol
703 The TLS Record Protocol is a layered protocol. At each layer,
704 messages may include fields for length, description, and content.
705 The Record Protocol takes messages to be transmitted, fragments the
706 data into manageable blocks, optionally compresses the data, applies
707 a MAC, encrypts, and transmits the result. Received data is
708 decrypted, verified, decompressed, and reassembled, then delivered to
709 higher level clients.
711 Four record protocol clients are described in this document: the
712 handshake protocol, the alert protocol, the change cipher spec
713 protocol, and the application data protocol. In order to allow
714 extension of the TLS protocol, additional record types can be
715 supported by the record protocol. Any new record types should
716 allocate type values immediately beyond the ContentType values for
717 the four record types described here (see Appendix A.2). If a TLS
718 implementation receives a record type it does not understand, it
719 should just ignore it. Any protocol designed for use over TLS must be
720 carefully designed to deal with all possible attacks against it.
721 Note that because the type and length of a record are not protected
722 by encryption, care should be take to minimize the value of traffic
723 analysis of these values.
730 Dierks & Allen Standards Track [Page 13]
731 \f
732 RFC 2246 The TLS Protocol Version 1.0 January 1999
735 6.1. Connection states
737 A TLS connection state is the operating environment of the TLS Record
738 Protocol. It specifies a compression algorithm, encryption algorithm,
739 and MAC algorithm. In addition, the parameters for these algorithms
740 are known: the MAC secret and the bulk encryption keys and IVs for
741 the connection in both the read and the write directions. Logically,
742 there are always four connection states outstanding: the current read
743 and write states, and the pending read and write states. All records
744 are processed under the current read and write states. The security
745 parameters for the pending states can be set by the TLS Handshake
746 Protocol, and the Handshake Protocol can selectively make either of
747 the pending states current, in which case the appropriate current
748 state is disposed of and replaced with the pending state; the pending
749 state is then reinitialized to an empty state. It is illegal to make
750 a state which has not been initialized with security parameters a
751 current state. The initial current state always specifies that no
752 encryption, compression, or MAC will be used.
754 The security parameters for a TLS Connection read and write state are
755 set by providing the following values:
757 connection end
758 Whether this entity is considered the "client" or the "server" in
759 this connection.
761 bulk encryption algorithm
762 An algorithm to be used for bulk encryption. This specification
763 includes the key size of this algorithm, how much of that key is
764 secret, whether it is a block or stream cipher, the block size of
765 the cipher (if appropriate), and whether it is considered an
766 "export" cipher.
768 MAC algorithm
769 An algorithm to be used for message authentication. This
770 specification includes the size of the hash which is returned by
771 the MAC algorithm.
773 compression algorithm
774 An algorithm to be used for data compression. This specification
775 must include all information the algorithm requires to do
776 compression.
778 master secret
779 A 48 byte secret shared between the two peers in the connection.
781 client random
782 A 32 byte value provided by the client.
786 Dierks & Allen Standards Track [Page 14]
787 \f
788 RFC 2246 The TLS Protocol Version 1.0 January 1999
791 server random
792 A 32 byte value provided by the server.
794 These parameters are defined in the presentation language as:
796 enum { server, client } ConnectionEnd;
798 enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
800 enum { stream, block } CipherType;
802 enum { true, false } IsExportable;
804 enum { null, md5, sha } MACAlgorithm;
806 enum { null(0), (255) } CompressionMethod;
808 /* The algorithms specified in CompressionMethod,
809 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
811 struct {
812 ConnectionEnd entity;
813 BulkCipherAlgorithm bulk_cipher_algorithm;
814 CipherType cipher_type;
815 uint8 key_size;
816 uint8 key_material_length;
817 IsExportable is_exportable;
818 MACAlgorithm mac_algorithm;
819 uint8 hash_size;
820 CompressionMethod compression_algorithm;
821 opaque master_secret[48];
822 opaque client_random[32];
823 opaque server_random[32];
824 } SecurityParameters;
826 The record layer will use the security parameters to generate the
827 following six items:
829 client write MAC secret
830 server write MAC secret
831 client write key
832 server write key
833 client write IV (for block ciphers only)
834 server write IV (for block ciphers only)
836 The client write parameters are used by the server when receiving and
837 processing records and vice-versa. The algorithm used for generating
838 these items from the security parameters is described in section 6.3.
842 Dierks & Allen Standards Track [Page 15]
843 \f
844 RFC 2246 The TLS Protocol Version 1.0 January 1999
847 Once the security parameters have been set and the keys have been
848 generated, the connection states can be instantiated by making them
849 the current states. These current states must be updated for each
850 record processed. Each connection state includes the following
851 elements:
853 compression state
854 The current state of the compression algorithm.
856 cipher state
857 The current state of the encryption algorithm. This will consist
858 of the scheduled key for that connection. In addition, for block
859 ciphers running in CBC mode (the only mode specified for TLS),
860 this will initially contain the IV for that connection state and
861 be updated to contain the ciphertext of the last block encrypted
862 or decrypted as records are processed. For stream ciphers, this
863 will contain whatever the necessary state information is to allow
864 the stream to continue to encrypt or decrypt data.
866 MAC secret
867 The MAC secret for this connection as generated above.
869 sequence number
870 Each connection state contains a sequence number, which is
871 maintained separately for read and write states. The sequence
872 number must be set to zero whenever a connection state is made
873 the active state. Sequence numbers are of type uint64 and may not
874 exceed 2^64-1. A sequence number is incremented after each
875 record: specifically, the first record which is transmitted under
876 a particular connection state should use sequence number 0.
878 6.2. Record layer
880 The TLS Record Layer receives uninterpreted data from higher layers
881 in non-empty blocks of arbitrary size.
883 6.2.1. Fragmentation
885 The record layer fragments information blocks into TLSPlaintext
886 records carrying data in chunks of 2^14 bytes or less. Client message
887 boundaries are not preserved in the record layer (i.e., multiple
888 client messages of the same ContentType may be coalesced into a
889 single TLSPlaintext record, or a single message may be fragmented
890 across several records).
892 struct {
893 uint8 major, minor;
894 } ProtocolVersion;
898 Dierks & Allen Standards Track [Page 16]
899 \f
900 RFC 2246 The TLS Protocol Version 1.0 January 1999
903 enum {
904 change_cipher_spec(20), alert(21), handshake(22),
905 application_data(23), (255)
906 } ContentType;
908 struct {
909 ContentType type;
910 ProtocolVersion version;
911 uint16 length;
912 opaque fragment[TLSPlaintext.length];
913 } TLSPlaintext;
915 type
916 The higher level protocol used to process the enclosed fragment.
918 version
919 The version of the protocol being employed. This document
920 describes TLS Version 1.0, which uses the version { 3, 1 }. The
921 version value 3.1 is historical: TLS version 1.0 is a minor
922 modification to the SSL 3.0 protocol, which bears the version
923 value 3.0. (See Appendix A.1).
925 length
926 The length (in bytes) of the following TLSPlaintext.fragment.
927 The length should not exceed 2^14.
929 fragment
930 The application data. This data is transparent and treated as an
931 independent block to be dealt with by the higher level protocol
932 specified by the type field.
934 Note: Data of different TLS Record layer content types may be
935 interleaved. Application data is generally of lower precedence
936 for transmission than other content types.
938 6.2.2. Record compression and decompression
940 All records are compressed using the compression algorithm defined in
941 the current session state. There is always an active compression
942 algorithm; however, initially it is defined as
943 CompressionMethod.null. The compression algorithm translates a
944 TLSPlaintext structure into a TLSCompressed structure. Compression
945 functions are initialized with default state information whenever a
946 connection state is made active.
954 Dierks & Allen Standards Track [Page 17]
955 \f
956 RFC 2246 The TLS Protocol Version 1.0 January 1999
959 Compression must be lossless and may not increase the content length
960 by more than 1024 bytes. If the decompression function encounters a
961 TLSCompressed.fragment that would decompress to a length in excess of
962 2^14 bytes, it should report a fatal decompression failure error.
964 struct {
965 ContentType type; /* same as TLSPlaintext.type */
966 ProtocolVersion version;/* same as TLSPlaintext.version */
967 uint16 length;
968 opaque fragment[TLSCompressed.length];
969 } TLSCompressed;
971 length
972 The length (in bytes) of the following TLSCompressed.fragment.
973 The length should not exceed 2^14 + 1024.
975 fragment
976 The compressed form of TLSPlaintext.fragment.
978 Note: A CompressionMethod.null operation is an identity operation; no
979 fields are altered.
981 Implementation note:
982 Decompression functions are responsible for ensuring that
983 messages cannot cause internal buffer overflows.
985 6.2.3. Record payload protection
987 The encryption and MAC functions translate a TLSCompressed structure
988 into a TLSCiphertext. The decryption functions reverse the process.
989 The MAC of the record also includes a sequence number so that
990 missing, extra or repeated messages are detectable.
992 struct {
993 ContentType type;
994 ProtocolVersion version;
995 uint16 length;
996 select (CipherSpec.cipher_type) {
997 case stream: GenericStreamCipher;
998 case block: GenericBlockCipher;
999 } fragment;
1000 } TLSCiphertext;
1002 type
1003 The type field is identical to TLSCompressed.type.
1005 version
1006 The version field is identical to TLSCompressed.version.
1010 Dierks & Allen Standards Track [Page 18]
1011 \f
1012 RFC 2246 The TLS Protocol Version 1.0 January 1999
1015 length
1016 The length (in bytes) of the following TLSCiphertext.fragment.
1017 The length may not exceed 2^14 + 2048.
1019 fragment
1020 The encrypted form of TLSCompressed.fragment, with the MAC.
1022 6.2.3.1. Null or standard stream cipher
1024 Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
1025 A.6) convert TLSCompressed.fragment structures to and from stream
1026 TLSCiphertext.fragment structures.
1028 stream-ciphered struct {
1029 opaque content[TLSCompressed.length];
1030 opaque MAC[CipherSpec.hash_size];
1031 } GenericStreamCipher;
1033 The MAC is generated as:
1035 HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
1036 TLSCompressed.version + TLSCompressed.length +
1037 TLSCompressed.fragment));
1039 where "+" denotes concatenation.
1041 seq_num
1042 The sequence number for this record.
1044 hash
1045 The hashing algorithm specified by
1046 SecurityParameters.mac_algorithm.
1048 Note that the MAC is computed before encryption. The stream cipher
1049 encrypts the entire block, including the MAC. For stream ciphers that
1050 do not use a synchronization vector (such as RC4), the stream cipher
1051 state from the end of one record is simply used on the subsequent
1052 packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
1053 consists of the identity operation (i.e., the data is not encrypted
1054 and the MAC size is zero implying that no MAC is used).
1055 TLSCiphertext.length is TLSCompressed.length plus
1056 CipherSpec.hash_size.
1058 6.2.3.2. CBC block cipher
1060 For block ciphers (such as RC2 or DES), the encryption and MAC
1061 functions convert TLSCompressed.fragment structures to and from block
1062 TLSCiphertext.fragment structures.
1066 Dierks & Allen Standards Track [Page 19]
1067 \f
1068 RFC 2246 The TLS Protocol Version 1.0 January 1999
1071 block-ciphered struct {
1072 opaque content[TLSCompressed.length];
1073 opaque MAC[CipherSpec.hash_size];
1074 uint8 padding[GenericBlockCipher.padding_length];
1075 uint8 padding_length;
1076 } GenericBlockCipher;
1078 The MAC is generated as described in Section 6.2.3.1.
1080 padding
1081 Padding that is added to force the length of the plaintext to be
1082 an integral multiple of the block cipher's block length. The
1083 padding may be any length up to 255 bytes long, as long as it
1084 results in the TLSCiphertext.length being an integral multiple of
1085 the block length. Lengths longer than necessary might be
1086 desirable to frustrate attacks on a protocol based on analysis of
1087 the lengths of exchanged messages. Each uint8 in the padding data
1088 vector must be filled with the padding length value.
1090 padding_length
1091 The padding length should be such that the total size of the
1092 GenericBlockCipher structure is a multiple of the cipher's block
1093 length. Legal values range from zero to 255, inclusive. This
1094 length specifies the length of the padding field exclusive of the
1095 padding_length field itself.
1097 The encrypted data length (TLSCiphertext.length) is one more than the
1098 sum of TLSCompressed.length, CipherSpec.hash_size, and
1099 padding_length.
1101 Example: If the block length is 8 bytes, the content length
1102 (TLSCompressed.length) is 61 bytes, and the MAC length is 20
1103 bytes, the length before padding is 82 bytes. Thus, the
1104 padding length modulo 8 must be equal to 6 in order to make
1105 the total length an even multiple of 8 bytes (the block
1106 length). The padding length can be 6, 14, 22, and so on,
1107 through 254. If the padding length were the minimum necessary,
1108 6, the padding would be 6 bytes, each containing the value 6.
1109 Thus, the last 8 octets of the GenericBlockCipher before block
1110 encryption would be xx 06 06 06 06 06 06 06, where xx is the
1111 last octet of the MAC.
1113 Note: With block ciphers in CBC mode (Cipher Block Chaining) the
1114 initialization vector (IV) for the first record is generated with
1115 the other keys and secrets when the security parameters are set.
1116 The IV for subsequent records is the last ciphertext block from
1117 the previous record.
1122 Dierks & Allen Standards Track [Page 20]
1123 \f
1124 RFC 2246 The TLS Protocol Version 1.0 January 1999
1127 6.3. Key calculation
1129 The Record Protocol requires an algorithm to generate keys, IVs, and
1130 MAC secrets from the security parameters provided by the handshake
1131 protocol.
1133 The master secret is hashed into a sequence of secure bytes, which
1134 are assigned to the MAC secrets, keys, and non-export IVs required by
1135 the current connection state (see Appendix A.6). CipherSpecs require
1136 a client write MAC secret, a server write MAC secret, a client write
1137 key, a server write key, a client write IV, and a server write IV,
1138 which are generated from the master secret in that order. Unused
1139 values are empty.
1141 When generating keys and MAC secrets, the master secret is used as an
1142 entropy source, and the random values provide unencrypted salt
1143 material and IVs for exportable ciphers.
1145 To generate the key material, compute
1147 key_block = PRF(SecurityParameters.master_secret,
1148 "key expansion",
1149 SecurityParameters.server_random +
1150 SecurityParameters.client_random);
1152 until enough output has been generated. Then the key_block is
1153 partitioned as follows:
1155 client_write_MAC_secret[SecurityParameters.hash_size]
1156 server_write_MAC_secret[SecurityParameters.hash_size]
1157 client_write_key[SecurityParameters.key_material_length]
1158 server_write_key[SecurityParameters.key_material_length]
1159 client_write_IV[SecurityParameters.IV_size]
1160 server_write_IV[SecurityParameters.IV_size]
1162 The client_write_IV and server_write_IV are only generated for non-
1163 export block ciphers. For exportable block ciphers, the
1164 initialization vectors are generated later, as described below. Any
1165 extra key_block material is discarded.
1167 Implementation note:
1168 The cipher spec which is defined in this document which requires
1169 the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte
1170 keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of
1171 104 bytes of key material.
1178 Dierks & Allen Standards Track [Page 21]
1179 \f
1180 RFC 2246 The TLS Protocol Version 1.0 January 1999
1183 Exportable encryption algorithms (for which CipherSpec.is_exportable
1184 is true) require additional processing as follows to derive their
1185 final write keys:
1187 final_client_write_key =
1188 PRF(SecurityParameters.client_write_key,
1189 "client write key",
1190 SecurityParameters.client_random +
1191 SecurityParameters.server_random);
1192 final_server_write_key =
1193 PRF(SecurityParameters.server_write_key,
1194 "server write key",
1195 SecurityParameters.client_random +
1196 SecurityParameters.server_random);
1198 Exportable encryption algorithms derive their IVs solely from the
1199 random values from the hello messages:
1201 iv_block = PRF("", "IV block", SecurityParameters.client_random +
1202 SecurityParameters.server_random);
1204 The iv_block is partitioned into two initialization vectors as the
1205 key_block was above:
1207 client_write_IV[SecurityParameters.IV_size]
1208 server_write_IV[SecurityParameters.IV_size]
1210 Note that the PRF is used without a secret in this case: this just
1211 means that the secret has a length of zero bytes and contributes
1212 nothing to the hashing in the PRF.
1214 6.3.1. Export key generation example
1216 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for
1217 each of the two encryption keys and 16 bytes for each of the MAC
1218 keys, for a total of 42 bytes of key material. The PRF output is
1219 stored in the key_block. The key_block is partitioned, and the write
1220 keys are salted because this is an exportable encryption algorithm.
1222 key_block = PRF(master_secret,
1223 "key expansion",
1224 server_random +
1225 client_random)[0..41]
1226 client_write_MAC_secret = key_block[0..15]
1227 server_write_MAC_secret = key_block[16..31]
1228 client_write_key = key_block[32..36]
1229 server_write_key = key_block[37..41]
1234 Dierks & Allen Standards Track [Page 22]
1235 \f
1236 RFC 2246 The TLS Protocol Version 1.0 January 1999
1239 final_client_write_key = PRF(client_write_key,
1240 "client write key",
1241 client_random +
1242 server_random)[0..15]
1243 final_server_write_key = PRF(server_write_key,
1244 "server write key",
1245 client_random +
1246 server_random)[0..15]
1248 iv_block = PRF("", "IV block", client_random +
1249 server_random)[0..15]
1250 client_write_IV = iv_block[0..7]
1251 server_write_IV = iv_block[8..15]
1253 7. The TLS Handshake Protocol
1255 The TLS Handshake Protocol consists of a suite of three sub-protocols
1256 which are used to allow peers to agree upon security parameters for
1257 the record layer, authenticate themselves, instantiate negotiated
1258 security parameters, and report error conditions to each other.
1260 The Handshake Protocol is responsible for negotiating a session,
1261 which consists of the following items:
1263 session identifier
1264 An arbitrary byte sequence chosen by the server to identify an
1265 active or resumable session state.
1267 peer certificate
1268 X509v3 [X509] certificate of the peer. This element of the state
1269 may be null.
1271 compression method
1272 The algorithm used to compress data prior to encryption.
1274 cipher spec
1275 Specifies the bulk data encryption algorithm (such as null, DES,
1276 etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
1277 cryptographic attributes such as the hash_size. (See Appendix A.6
1278 for formal definition)
1280 master secret
1281 48-byte secret shared between the client and server.
1283 is resumable
1284 A flag indicating whether the session can be used to initiate new
1285 connections.
1290 Dierks & Allen Standards Track [Page 23]
1291 \f
1292 RFC 2246 The TLS Protocol Version 1.0 January 1999
1295 These items are then used to create security parameters for use by
1296 the Record Layer when protecting application data. Many connections
1297 can be instantiated using the same session through the resumption
1298 feature of the TLS Handshake Protocol.
1300 7.1. Change cipher spec protocol
1302 The change cipher spec protocol exists to signal transitions in
1303 ciphering strategies. The protocol consists of a single message,
1304 which is encrypted and compressed under the current (not the pending)
1305 connection state. The message consists of a single byte of value 1.
1307 struct {
1308 enum { change_cipher_spec(1), (255) } type;
1309 } ChangeCipherSpec;
1311 The change cipher spec message is sent by both the client and server
1312 to notify the receiving party that subsequent records will be
1313 protected under the newly negotiated CipherSpec and keys. Reception
1314 of this message causes the receiver to instruct the Record Layer to
1315 immediately copy the read pending state into the read current state.
1316 Immediately after sending this message, the sender should instruct
1317 the record layer to make the write pending state the write active
1318 state. (See section 6.1.) The change cipher spec message is sent
1319 during the handshake after the security parameters have been agreed
1320 upon, but before the verifying finished message is sent (see section
1321 7.4.9).
1323 7.2. Alert protocol
1325 One of the content types supported by the TLS Record layer is the
1326 alert type. Alert messages convey the severity of the message and a
1327 description of the alert. Alert messages with a level of fatal result
1328 in the immediate termination of the connection. In this case, other
1329 connections corresponding to the session may continue, but the
1330 session identifier must be invalidated, preventing the failed session
1331 from being used to establish new connections. Like other messages,
1332 alert messages are encrypted and compressed, as specified by the
1333 current connection state.
1335 enum { warning(1), fatal(2), (255) } AlertLevel;
1337 enum {
1338 close_notify(0),
1339 unexpected_message(10),
1340 bad_record_mac(20),
1341 decryption_failed(21),
1342 record_overflow(22),
1346 Dierks & Allen Standards Track [Page 24]
1347 \f
1348 RFC 2246 The TLS Protocol Version 1.0 January 1999
1351 decompression_failure(30),
1352 handshake_failure(40),
1353 bad_certificate(42),
1354 unsupported_certificate(43),
1355 certificate_revoked(44),
1356 certificate_expired(45),
1357 certificate_unknown(46),
1358 illegal_parameter(47),
1359 unknown_ca(48),
1360 access_denied(49),
1361 decode_error(50),
1362 decrypt_error(51),
1363 export_restriction(60),
1364 protocol_version(70),
1365 insufficient_security(71),
1366 internal_error(80),
1367 user_canceled(90),
1368 no_renegotiation(100),
1369 (255)
1370 } AlertDescription;
1372 struct {
1373 AlertLevel level;
1374 AlertDescription description;
1375 } Alert;
1377 7.2.1. Closure alerts
1379 The client and the server must share knowledge that the connection is
1380 ending in order to avoid a truncation attack. Either party may
1381 initiate the exchange of closing messages.
1383 close_notify
1384 This message notifies the recipient that the sender will not send
1385 any more messages on this connection. The session becomes
1386 unresumable if any connection is terminated without proper
1387 close_notify messages with level equal to warning.
1389 Either party may initiate a close by sending a close_notify alert.
1390 Any data received after a closure alert is ignored.
1392 Each party is required to send a close_notify alert before closing
1393 the write side of the connection. It is required that the other party
1394 respond with a close_notify alert of its own and close down the
1395 connection immediately, discarding any pending writes. It is not
1396 required for the initiator of the close to wait for the responding
1397 close_notify alert before closing the read side of the connection.
1402 Dierks & Allen Standards Track [Page 25]
1403 \f
1404 RFC 2246 The TLS Protocol Version 1.0 January 1999
1407 If the application protocol using TLS provides that any data may be
1408 carried over the underlying transport after the TLS connection is
1409 closed, the TLS implementation must receive the responding
1410 close_notify alert before indicating to the application layer that
1411 the TLS connection has ended. If the application protocol will not
1412 transfer any additional data, but will only close the underlying
1413 transport connection, then the implementation may choose to close the
1414 transport without waiting for the responding close_notify. No part of
1415 this standard should be taken to dictate the manner in which a usage
1416 profile for TLS manages its data transport, including when
1417 connections are opened or closed.
1419 NB: It is assumed that closing a connection reliably delivers
1420 pending data before destroying the transport.
1422 7.2.2. Error alerts
1424 Error handling in the TLS Handshake protocol is very simple. When an
1425 error is detected, the detecting party sends a message to the other
1426 party. Upon transmission or receipt of an fatal alert message, both
1427 parties immediately close the connection. Servers and clients are
1428 required to forget any session-identifiers, keys, and secrets
1429 associated with a failed connection. The following error alerts are
1430 defined:
1432 unexpected_message
1433 An inappropriate message was received. This alert is always fatal
1434 and should never be observed in communication between proper
1435 implementations.
1437 bad_record_mac
1438 This alert is returned if a record is received with an incorrect
1439 MAC. This message is always fatal.
1441 decryption_failed
1442 A TLSCiphertext decrypted in an invalid way: either it wasn`t an
1443 even multiple of the block length or its padding values, when
1444 checked, weren`t correct. This message is always fatal.
1446 record_overflow
1447 A TLSCiphertext record was received which had a length more than
1448 2^14+2048 bytes, or a record decrypted to a TLSCompressed record
1449 with more than 2^14+1024 bytes. This message is always fatal.
1451 decompression_failure
1452 The decompression function received improper input (e.g. data
1453 that would expand to excessive length). This message is always
1454 fatal.
1458 Dierks & Allen Standards Track [Page 26]
1459 \f
1460 RFC 2246 The TLS Protocol Version 1.0 January 1999
1463 handshake_failure
1464 Reception of a handshake_failure alert message indicates that the
1465 sender was unable to negotiate an acceptable set of security
1466 parameters given the options available. This is a fatal error.
1468 bad_certificate
1469 A certificate was corrupt, contained signatures that did not
1470 verify correctly, etc.
1472 unsupported_certificate
1473 A certificate was of an unsupported type.
1475 certificate_revoked
1476 A certificate was revoked by its signer.
1478 certificate_expired
1479 A certificate has expired or is not currently valid.
1481 certificate_unknown
1482 Some other (unspecified) issue arose in processing the
1483 certificate, rendering it unacceptable.
1485 illegal_parameter
1486 A field in the handshake was out of range or inconsistent with
1487 other fields. This is always fatal.
1489 unknown_ca
1490 A valid certificate chain or partial chain was received, but the
1491 certificate was not accepted because the CA certificate could not
1492 be located or couldn`t be matched with a known, trusted CA. This
1493 message is always fatal.
1495 access_denied
1496 A valid certificate was received, but when access control was
1497 applied, the sender decided not to proceed with negotiation.
1498 This message is always fatal.
1500 decode_error
1501 A message could not be decoded because some field was out of the
1502 specified range or the length of the message was incorrect. This
1503 message is always fatal.
1505 decrypt_error
1506 A handshake cryptographic operation failed, including being
1507 unable to correctly verify a signature, decrypt a key exchange,
1508 or validate a finished message.
1514 Dierks & Allen Standards Track [Page 27]
1515 \f
1516 RFC 2246 The TLS Protocol Version 1.0 January 1999
1519 export_restriction
1520 A negotiation not in compliance with export restrictions was
1521 detected; for example, attempting to transfer a 1024 bit
1522 ephemeral RSA key for the RSA_EXPORT handshake method. This
1523 message is always fatal.
1525 protocol_version
1526 The protocol version the client has attempted to negotiate is
1527 recognized, but not supported. (For example, old protocol
1528 versions might be avoided for security reasons). This message is
1529 always fatal.
1531 insufficient_security
1532 Returned instead of handshake_failure when a negotiation has
1533 failed specifically because the server requires ciphers more
1534 secure than those supported by the client. This message is always
1535 fatal.
1537 internal_error
1538 An internal error unrelated to the peer or the correctness of the
1539 protocol makes it impossible to continue (such as a memory
1540 allocation failure). This message is always fatal.
1542 user_canceled
1543 This handshake is being canceled for some reason unrelated to a
1544 protocol failure. If the user cancels an operation after the
1545 handshake is complete, just closing the connection by sending a
1546 close_notify is more appropriate. This alert should be followed
1547 by a close_notify. This message is generally a warning.
1549 no_renegotiation
1550 Sent by the client in response to a hello request or by the
1551 server in response to a client hello after initial handshaking.
1552 Either of these would normally lead to renegotiation; when that
1553 is not appropriate, the recipient should respond with this alert;
1554 at that point, the original requester can decide whether to
1555 proceed with the connection. One case where this would be
1556 appropriate would be where a server has spawned a process to
1557 satisfy a request; the process might receive security parameters
1558 (key length, authentication, etc.) at startup and it might be
1559 difficult to communicate changes to these parameters after that
1560 point. This message is always a warning.
1562 For all errors where an alert level is not explicitly specified, the
1563 sending party may determine at its discretion whether this is a fatal
1564 error or not; if an alert with a level of warning is received, the
1570 Dierks & Allen Standards Track [Page 28]
1571 \f
1572 RFC 2246 The TLS Protocol Version 1.0 January 1999
1575 receiving party may decide at its discretion whether to treat this as
1576 a fatal error or not. However, all messages which are transmitted
1577 with a level of fatal must be treated as fatal messages.
1579 7.3. Handshake Protocol overview
1581 The cryptographic parameters of the session state are produced by the
1582 TLS Handshake Protocol, which operates on top of the TLS Record
1583 Layer. When a TLS client and server first start communicating, they
1584 agree on a protocol version, select cryptographic algorithms,
1585 optionally authenticate each other, and use public-key encryption
1586 techniques to generate shared secrets.
1588 The TLS Handshake Protocol involves the following steps:
1590 - Exchange hello messages to agree on algorithms, exchange random
1591 values, and check for session resumption.
1593 - Exchange the necessary cryptographic parameters to allow the
1594 client and server to agree on a premaster secret.
1596 - Exchange certificates and cryptographic information to allow the
1597 client and server to authenticate themselves.
1599 - Generate a master secret from the premaster secret and exchanged
1600 random values.
1602 - Provide security parameters to the record layer.
1604 - Allow the client and server to verify that their peer has
1605 calculated the same security parameters and that the handshake
1606 occurred without tampering by an attacker.
1608 Note that higher layers should not be overly reliant on TLS always
1609 negotiating the strongest possible connection between two peers:
1610 there are a number of ways a man in the middle attacker can attempt
1611 to make two entities drop down to the least secure method they
1612 support. The protocol has been designed to minimize this risk, but
1613 there are still attacks available: for example, an attacker could
1614 block access to the port a secure service runs on, or attempt to get
1615 the peers to negotiate an unauthenticated connection. The fundamental
1616 rule is that higher levels must be cognizant of what their security
1617 requirements are and never transmit information over a channel less
1618 secure than what they require. The TLS protocol is secure, in that
1619 any cipher suite offers its promised level of security: if you
1620 negotiate 3DES with a 1024 bit RSA key exchange with a host whose
1621 certificate you have verified, you can expect to be that secure.
1626 Dierks & Allen Standards Track [Page 29]
1627 \f
1628 RFC 2246 The TLS Protocol Version 1.0 January 1999
1631 However, you should never send data over a link encrypted with 40 bit
1632 security unless you feel that data is worth no more than the effort
1633 required to break that encryption.
1635 These goals are achieved by the handshake protocol, which can be
1636 summarized as follows: The client sends a client hello message to
1637 which the server must respond with a server hello message, or else a
1638 fatal error will occur and the connection will fail. The client hello
1639 and server hello are used to establish security enhancement
1640 capabilities between client and server. The client hello and server
1641 hello establish the following attributes: Protocol Version, Session
1642 ID, Cipher Suite, and Compression Method. Additionally, two random
1643 values are generated and exchanged: ClientHello.random and
1644 ServerHello.random.
1646 The actual key exchange uses up to four messages: the server
1647 certificate, the server key exchange, the client certificate, and the
1648 client key exchange. New key exchange methods can be created by
1649 specifying a format for these messages and defining the use of the
1650 messages to allow the client and server to agree upon a shared
1651 secret. This secret should be quite long; currently defined key
1652 exchange methods exchange secrets which range from 48 to 128 bytes in
1653 length.
1655 Following the hello messages, the server will send its certificate,
1656 if it is to be authenticated. Additionally, a server key exchange
1657 message may be sent, if it is required (e.g. if their server has no
1658 certificate, or if its certificate is for signing only). If the
1659 server is authenticated, it may request a certificate from the
1660 client, if that is appropriate to the cipher suite selected. Now the
1661 server will send the server hello done message, indicating that the
1662 hello-message phase of the handshake is complete. The server will
1663 then wait for a client response. If the server has sent a certificate
1664 request message, the client must send the certificate message. The
1665 client key exchange message is now sent, and the content of that
1666 message will depend on the public key algorithm selected between the
1667 client hello and the server hello. If the client has sent a
1668 certificate with signing ability, a digitally-signed certificate
1669 verify message is sent to explicitly verify the certificate.
1671 At this point, a change cipher spec message is sent by the client,
1672 and the client copies the pending Cipher Spec into the current Cipher
1673 Spec. The client then immediately sends the finished message under
1674 the new algorithms, keys, and secrets. In response, the server will
1675 send its own change cipher spec message, transfer the pending to the
1676 current Cipher Spec, and send its finished message under the new
1682 Dierks & Allen Standards Track [Page 30]
1683 \f
1684 RFC 2246 The TLS Protocol Version 1.0 January 1999
1687 Cipher Spec. At this point, the handshake is complete and the client
1688 and server may begin to exchange application layer data. (See flow
1689 chart below.)
1691 Client Server
1693 ClientHello -------->
1694 ServerHello
1695 Certificate*
1696 ServerKeyExchange*
1697 CertificateRequest*
1698 <-------- ServerHelloDone
1699 Certificate*
1700 ClientKeyExchange
1701 CertificateVerify*
1702 [ChangeCipherSpec]
1703 Finished -------->
1704 [ChangeCipherSpec]
1705 <-------- Finished
1706 Application Data <-------> Application Data
1708 Fig. 1 - Message flow for a full handshake
1710 * Indicates optional or situation-dependent messages that are not
1711 always sent.
1713 Note: To help avoid pipeline stalls, ChangeCipherSpec is an
1714 independent TLS Protocol content type, and is not actually a TLS
1715 handshake message.
1717 When the client and server decide to resume a previous session or
1718 duplicate an existing session (instead of negotiating new security
1719 parameters) the message flow is as follows:
1721 The client sends a ClientHello using the Session ID of the session to
1722 be resumed. The server then checks its session cache for a match. If
1723 a match is found, and the server is willing to re-establish the
1724 connection under the specified session state, it will send a
1725 ServerHello with the same Session ID value. At this point, both
1726 client and server must send change cipher spec messages and proceed
1727 directly to finished messages. Once the re-establishment is complete,
1728 the client and server may begin to exchange application layer data.
1729 (See flow chart below.) If a Session ID match is not found, the
1730 server generates a new session ID and the TLS client and server
1731 perform a full handshake.
1738 Dierks & Allen Standards Track [Page 31]
1739 \f
1740 RFC 2246 The TLS Protocol Version 1.0 January 1999
1743 Client Server
1745 ClientHello -------->
1746 ServerHello
1747 [ChangeCipherSpec]
1748 <-------- Finished
1749 [ChangeCipherSpec]
1750 Finished -------->
1751 Application Data <-------> Application Data
1753 Fig. 2 - Message flow for an abbreviated handshake
1755 The contents and significance of each message will be presented in
1756 detail in the following sections.
1758 7.4. Handshake protocol
1760 The TLS Handshake Protocol is one of the defined higher level clients
1761 of the TLS Record Protocol. This protocol is used to negotiate the
1762 secure attributes of a session. Handshake messages are supplied to
1763 the TLS Record Layer, where they are encapsulated within one or more
1764 TLSPlaintext structures, which are processed and transmitted as
1765 specified by the current active session state.
1767 enum {
1768 hello_request(0), client_hello(1), server_hello(2),
1769 certificate(11), server_key_exchange (12),
1770 certificate_request(13), server_hello_done(14),
1771 certificate_verify(15), client_key_exchange(16),
1772 finished(20), (255)
1773 } HandshakeType;
1775 struct {
1776 HandshakeType msg_type; /* handshake type */
1777 uint24 length; /* bytes in message */
1778 select (HandshakeType) {
1779 case hello_request: HelloRequest;
1780 case client_hello: ClientHello;
1781 case server_hello: ServerHello;
1782 case certificate: Certificate;
1783 case server_key_exchange: ServerKeyExchange;
1784 case certificate_request: CertificateRequest;
1785 case server_hello_done: ServerHelloDone;
1786 case certificate_verify: CertificateVerify;
1787 case client_key_exchange: ClientKeyExchange;
1788 case finished: Finished;
1789 } body;
1790 } Handshake;
1794 Dierks & Allen Standards Track [Page 32]
1795 \f
1796 RFC 2246 The TLS Protocol Version 1.0 January 1999
1799 The handshake protocol messages are presented below in the order they
1800 must be sent; sending handshake messages in an unexpected order
1801 results in a fatal error. Unneeded handshake messages can be omitted,
1802 however. Note one exception to the ordering: the Certificate message
1803 is used twice in the handshake (from server to client, then from
1804 client to server), but described only in its first position. The one
1805 message which is not bound by these ordering rules in the Hello
1806 Request message, which can be sent at any time, but which should be
1807 ignored by the client if it arrives in the middle of a handshake.
1809 7.4.1. Hello messages
1811 The hello phase messages are used to exchange security enhancement
1812 capabilities between the client and server. When a new session
1813 begins, the Record Layer's connection state encryption, hash, and
1814 compression algorithms are initialized to null. The current
1815 connection state is used for renegotiation messages.
1817 7.4.1.1. Hello request
1819 When this message will be sent:
1820 The hello request message may be sent by the server at any time.
1822 Meaning of this message:
1823 Hello request is a simple notification that the client should
1824 begin the negotiation process anew by sending a client hello
1825 message when convenient. This message will be ignored by the
1826 client if the client is currently negotiating a session. This
1827 message may be ignored by the client if it does not wish to
1828 renegotiate a session, or the client may, if it wishes, respond
1829 with a no_renegotiation alert. Since handshake messages are
1830 intended to have transmission precedence over application data,
1831 it is expected that the negotiation will begin before no more
1832 than a few records are received from the client. If the server
1833 sends a hello request but does not receive a client hello in
1834 response, it may close the connection with a fatal alert.
1836 After sending a hello request, servers should not repeat the request
1837 until the subsequent handshake negotiation is complete.
1839 Structure of this message:
1840 struct { } HelloRequest;
1842 Note: This message should never be included in the message hashes which
1843 are maintained throughout the handshake and used in the finished
1844 messages and the certificate verify message.
1850 Dierks & Allen Standards Track [Page 33]
1851 \f
1852 RFC 2246 The TLS Protocol Version 1.0 January 1999
1855 7.4.1.2. Client hello
1857 When this message will be sent:
1858 When a client first connects to a server it is required to send
1859 the client hello as its first message. The client can also send a
1860 client hello in response to a hello request or on its own
1861 initiative in order to renegotiate the security parameters in an
1862 existing connection.
1864 Structure of this message:
1865 The client hello message includes a random structure, which is
1866 used later in the protocol.
1868 struct {
1869 uint32 gmt_unix_time;
1870 opaque random_bytes[28];
1871 } Random;
1873 gmt_unix_time
1874 The current time and date in standard UNIX 32-bit format (seconds
1875 since the midnight starting Jan 1, 1970, GMT) according to the
1876 sender's internal clock. Clocks are not required to be set
1877 correctly by the basic TLS Protocol; higher level or application
1878 protocols may define additional requirements.
1880 random_bytes
1881 28 bytes generated by a secure random number generator.
1883 The client hello message includes a variable length session
1884 identifier. If not empty, the value identifies a session between the
1885 same client and server whose security parameters the client wishes to
1886 reuse. The session identifier may be from an earlier connection, this
1887 connection, or another currently active connection. The second option
1888 is useful if the client only wishes to update the random structures
1889 and derived values of a connection, while the third option makes it
1890 possible to establish several independent secure connections without
1891 repeating the full handshake protocol. These independent connections
1892 may occur sequentially or simultaneously; a SessionID becomes valid
1893 when the handshake negotiating it completes with the exchange of
1894 Finished messages and persists until removed due to aging or because
1895 a fatal error was encountered on a connection associated with the
1896 session. The actual contents of the SessionID are defined by the
1897 server.
1899 opaque SessionID<0..32>;
1906 Dierks & Allen Standards Track [Page 34]
1907 \f
1908 RFC 2246 The TLS Protocol Version 1.0 January 1999
1911 Warning:
1912 Because the SessionID is transmitted without encryption or
1913 immediate MAC protection, servers must not place confidential
1914 information in session identifiers or let the contents of fake
1915 session identifiers cause any breach of security. (Note that the
1916 content of the handshake as a whole, including the SessionID, is
1917 protected by the Finished messages exchanged at the end of the
1918 handshake.)
1920 The CipherSuite list, passed from the client to the server in the
1921 client hello message, contains the combinations of cryptographic
1922 algorithms supported by the client in order of the client's
1923 preference (favorite choice first). Each CipherSuite defines a key
1924 exchange algorithm, a bulk encryption algorithm (including secret key
1925 length) and a MAC algorithm. The server will select a cipher suite
1926 or, if no acceptable choices are presented, return a handshake
1927 failure alert and close the connection.
1929 uint8 CipherSuite[2]; /* Cryptographic suite selector */
1931 The client hello includes a list of compression algorithms supported
1932 by the client, ordered according to the client's preference.
1934 enum { null(0), (255) } CompressionMethod;
1936 struct {
1937 ProtocolVersion client_version;
1938 Random random;
1939 SessionID session_id;
1940 CipherSuite cipher_suites<2..2^16-1>;
1941 CompressionMethod compression_methods<1..2^8-1>;
1942 } ClientHello;
1944 client_version
1945 The version of the TLS protocol by which the client wishes to
1946 communicate during this session. This should be the latest
1947 (highest valued) version supported by the client. For this
1948 version of the specification, the version will be 3.1 (See
1949 Appendix E for details about backward compatibility).
1951 random
1952 A client-generated random structure.
1954 session_id
1955 The ID of a session the client wishes to use for this connection.
1956 This field should be empty if no session_id is available or the
1957 client wishes to generate new security parameters.
1962 Dierks & Allen Standards Track [Page 35]
1963 \f
1964 RFC 2246 The TLS Protocol Version 1.0 January 1999
1967 cipher_suites
1968 This is a list of the cryptographic options supported by the
1969 client, with the client's first preference first. If the
1970 session_id field is not empty (implying a session resumption
1971 request) this vector must include at least the cipher_suite from
1972 that session. Values are defined in Appendix A.5.
1974 compression_methods
1975 This is a list of the compression methods supported by the
1976 client, sorted by client preference. If the session_id field is
1977 not empty (implying a session resumption request) it must include
1978 the compression_method from that session. This vector must
1979 contain, and all implementations must support,
1980 CompressionMethod.null. Thus, a client and server will always be
1981 able to agree on a compression method.
1983 After sending the client hello message, the client waits for a server
1984 hello message. Any other handshake message returned by the server
1985 except for a hello request is treated as a fatal error.
1987 Forward compatibility note:
1988 In the interests of forward compatibility, it is permitted for a
1989 client hello message to include extra data after the compression
1990 methods. This data must be included in the handshake hashes, but
1991 must otherwise be ignored. This is the only handshake message for
1992 which this is legal; for all other messages, the amount of data
1993 in the message must match the description of the message
1994 precisely.
1996 7.4.1.3. Server hello
1998 When this message will be sent:
1999 The server will send this message in response to a client hello
2000 message when it was able to find an acceptable set of algorithms.
2001 If it cannot find such a match, it will respond with a handshake
2002 failure alert.
2004 Structure of this message:
2005 struct {
2006 ProtocolVersion server_version;
2007 Random random;
2008 SessionID session_id;
2009 CipherSuite cipher_suite;
2010 CompressionMethod compression_method;
2011 } ServerHello;
2018 Dierks & Allen Standards Track [Page 36]
2019 \f
2020 RFC 2246 The TLS Protocol Version 1.0 January 1999
2023 server_version
2024 This field will contain the lower of that suggested by the client
2025 in the client hello and the highest supported by the server. For
2026 this version of the specification, the version is 3.1 (See
2027 Appendix E for details about backward compatibility).
2029 random
2030 This structure is generated by the server and must be different
2031 from (and independent of) ClientHello.random.
2033 session_id
2034 This is the identity of the session corresponding to this
2035 connection. If the ClientHello.session_id was non-empty, the
2036 server will look in its session cache for a match. If a match is
2037 found and the server is willing to establish the new connection
2038 using the specified session state, the server will respond with
2039 the same value as was supplied by the client. This indicates a
2040 resumed session and dictates that the parties must proceed
2041 directly to the finished messages. Otherwise this field will
2042 contain a different value identifying the new session. The server
2043 may return an empty session_id to indicate that the session will
2044 not be cached and therefore cannot be resumed. If a session is
2045 resumed, it must be resumed using the same cipher suite it was
2046 originally negotiated with.
2048 cipher_suite
2049 The single cipher suite selected by the server from the list in
2050 ClientHello.cipher_suites. For resumed sessions this field is the
2051 value from the state of the session being resumed.
2053 compression_method
2054 The single compression algorithm selected by the server from the
2055 list in ClientHello.compression_methods. For resumed sessions
2056 this field is the value from the resumed session state.
2058 7.4.2. Server certificate
2060 When this message will be sent:
2061 The server must send a certificate whenever the agreed-upon key
2062 exchange method is not an anonymous one. This message will always
2063 immediately follow the server hello message.
2065 Meaning of this message:
2066 The certificate type must be appropriate for the selected cipher
2067 suite's key exchange algorithm, and is generally an X.509v3
2068 certificate. It must contain a key which matches the key exchange
2069 method, as follows. Unless otherwise specified, the signing
2074 Dierks & Allen Standards Track [Page 37]
2075 \f
2076 RFC 2246 The TLS Protocol Version 1.0 January 1999
2079 algorithm for the certificate must be the same as the algorithm
2080 for the certificate key. Unless otherwise specified, the public
2081 key may be of any length.
2083 Key Exchange Algorithm Certificate Key Type
2085 RSA RSA public key; the certificate must
2086 allow the key to be used for encryption.
2088 RSA_EXPORT RSA public key of length greater than
2089 512 bits which can be used for signing,
2090 or a key of 512 bits or shorter which
2091 can be used for either encryption or
2092 signing.
2094 DHE_DSS DSS public key.
2096 DHE_DSS_EXPORT DSS public key.
2098 DHE_RSA RSA public key which can be used for
2099 signing.
2101 DHE_RSA_EXPORT RSA public key which can be used for
2102 signing.
2104 DH_DSS Diffie-Hellman key. The algorithm used
2105 to sign the certificate should be DSS.
2107 DH_RSA Diffie-Hellman key. The algorithm used
2108 to sign the certificate should be RSA.
2110 All certificate profiles, key and cryptographic formats are defined
2111 by the IETF PKIX working group [PKIX]. When a key usage extension is
2112 present, the digitalSignature bit must be set for the key to be
2113 eligible for signing, as described above, and the keyEncipherment bit
2114 must be present to allow encryption, as described above. The
2115 keyAgreement bit must be set on Diffie-Hellman certificates.
2117 As CipherSuites which specify new key exchange methods are specified
2118 for the TLS Protocol, they will imply certificate format and the
2119 required encoded keying information.
2121 Structure of this message:
2122 opaque ASN.1Cert<1..2^24-1>;
2124 struct {
2125 ASN.1Cert certificate_list<0..2^24-1>;
2126 } Certificate;
2130 Dierks & Allen Standards Track [Page 38]
2131 \f
2132 RFC 2246 The TLS Protocol Version 1.0 January 1999
2135 certificate_list
2136 This is a sequence (chain) of X.509v3 certificates. The sender's
2137 certificate must come first in the list. Each following
2138 certificate must directly certify the one preceding it. Because
2139 certificate validation requires that root keys be distributed
2140 independently, the self-signed certificate which specifies the
2141 root certificate authority may optionally be omitted from the
2142 chain, under the assumption that the remote end must already
2143 possess it in order to validate it in any case.
2145 The same message type and structure will be used for the client's
2146 response to a certificate request message. Note that a client may
2147 send no certificates if it does not have an appropriate certificate
2148 to send in response to the server's authentication request.
2150 Note: PKCS #7 [PKCS7] is not used as the format for the certificate
2151 vector because PKCS #6 [PKCS6] extended certificates are not
2152 used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
2153 the task of parsing the list more difficult.
2155 7.4.3. Server key exchange message
2157 When this message will be sent:
2158 This message will be sent immediately after the server
2159 certificate message (or the server hello message, if this is an
2160 anonymous negotiation).
2162 The server key exchange message is sent by the server only when
2163 the server certificate message (if sent) does not contain enough
2164 data to allow the client to exchange a premaster secret. This is
2165 true for the following key exchange methods:
2167 RSA_EXPORT (if the public key in the server certificate is
2168 longer than 512 bits)
2169 DHE_DSS
2170 DHE_DSS_EXPORT
2171 DHE_RSA
2172 DHE_RSA_EXPORT
2173 DH_anon
2175 It is not legal to send the server key exchange message for the
2176 following key exchange methods:
2178 RSA
2179 RSA_EXPORT (when the public key in the server certificate is
2180 less than or equal to 512 bits in length)
2181 DH_DSS
2182 DH_RSA
2186 Dierks & Allen Standards Track [Page 39]
2187 \f
2188 RFC 2246 The TLS Protocol Version 1.0 January 1999
2191 Meaning of this message:
2192 This message conveys cryptographic information to allow the
2193 client to communicate the premaster secret: either an RSA public
2194 key to encrypt the premaster secret with, or a Diffie-Hellman
2195 public key with which the client can complete a key exchange
2196 (with the result being the premaster secret.)
2198 As additional CipherSuites are defined for TLS which include new key
2199 exchange algorithms, the server key exchange message will be sent if
2200 and only if the certificate type associated with the key exchange
2201 algorithm does not provide enough information for the client to
2202 exchange a premaster secret.
2204 Note: According to current US export law, RSA moduli larger than 512
2205 bits may not be used for key exchange in software exported from
2206 the US. With this message, the larger RSA keys encoded in
2207 certificates may be used to sign temporary shorter RSA keys for
2208 the RSA_EXPORT key exchange method.
2210 Structure of this message:
2211 enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
2213 struct {
2214 opaque rsa_modulus<1..2^16-1>;
2215 opaque rsa_exponent<1..2^16-1>;
2216 } ServerRSAParams;
2218 rsa_modulus
2219 The modulus of the server's temporary RSA key.
2221 rsa_exponent
2222 The public exponent of the server's temporary RSA key.
2224 struct {
2225 opaque dh_p<1..2^16-1>;
2226 opaque dh_g<1..2^16-1>;
2227 opaque dh_Ys<1..2^16-1>;
2228 } ServerDHParams; /* Ephemeral DH parameters */
2230 dh_p
2231 The prime modulus used for the Diffie-Hellman operation.
2233 dh_g
2234 The generator used for the Diffie-Hellman operation.
2236 dh_Ys
2237 The server's Diffie-Hellman public value (g^X mod p).
2242 Dierks & Allen Standards Track [Page 40]
2243 \f
2244 RFC 2246 The TLS Protocol Version 1.0 January 1999
2247 struct {
2248 select (KeyExchangeAlgorithm) {
2249 case diffie_hellman:
2250 ServerDHParams params;
2251 Signature signed_params;
2252 case rsa:
2253 ServerRSAParams params;
2254 Signature signed_params;
2255 };
2256 } ServerKeyExchange;
2258 params
2259 The server's key exchange parameters.
2261 signed_params
2262 For non-anonymous key exchanges, a hash of the corresponding
2263 params value, with the signature appropriate to that hash
2264 applied.
2266 md5_hash
2267 MD5(ClientHello.random + ServerHello.random + ServerParams);
2269 sha_hash
2270 SHA(ClientHello.random + ServerHello.random + ServerParams);
2272 enum { anonymous, rsa, dsa } SignatureAlgorithm;
2274 select (SignatureAlgorithm)
2275 { case anonymous: struct { };
2276 case rsa:
2277 digitally-signed struct {
2278 opaque md5_hash[16];
2279 opaque sha_hash[20];
2280 };
2281 case dsa:
2282 digitally-signed struct {
2283 opaque sha_hash[20];
2284 };
2285 } Signature;
2287 7.4.4. Certificate request
2289 When this message will be sent:
2290 A non-anonymous server can optionally request a certificate from
2291 the client, if appropriate for the selected cipher suite. This
2292 message, if sent, will immediately follow the Server Key Exchange
2293 message (if it is sent; otherwise, the Server Certificate
2294 message).
2298 Dierks & Allen Standards Track [Page 41]
2299 \f
2300 RFC 2246 The TLS Protocol Version 1.0 January 1999
2303 Structure of this message:
2304 enum {
2305 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
2306 (255)
2307 } ClientCertificateType;
2309 opaque DistinguishedName<1..2^16-1>;
2311 struct {
2312 ClientCertificateType certificate_types<1..2^8-1>;
2313 DistinguishedName certificate_authorities<3..2^16-1>;
2314 } CertificateRequest;
2316 certificate_types
2317 This field is a list of the types of certificates requested,
2318 sorted in order of the server's preference.
2320 certificate_authorities
2321 A list of the distinguished names of acceptable certificate
2322 authorities. These distinguished names may specify a desired
2323 distinguished name for a root CA or for a subordinate CA;
2324 thus, this message can be used both to describe known roots
2325 and a desired authorization space.
2327 Note: DistinguishedName is derived from [X509].
2329 Note: It is a fatal handshake_failure alert for an anonymous server to
2330 request client identification.
2332 7.4.5. Server hello done
2334 When this message will be sent:
2335 The server hello done message is sent by the server to indicate
2336 the end of the server hello and associated messages. After
2337 sending this message the server will wait for a client response.
2339 Meaning of this message:
2340 This message means that the server is done sending messages to
2341 support the key exchange, and the client can proceed with its
2342 phase of the key exchange.
2344 Upon receipt of the server hello done message the client should
2345 verify that the server provided a valid certificate if required
2346 and check that the server hello parameters are acceptable.
2348 Structure of this message:
2349 struct { } ServerHelloDone;
2354 Dierks & Allen Standards Track [Page 42]
2355 \f
2356 RFC 2246 The TLS Protocol Version 1.0 January 1999
2359 7.4.6. Client certificate
2361 When this message will be sent:
2362 This is the first message the client can send after receiving a
2363 server hello done message. This message is only sent if the
2364 server requests a certificate. If no suitable certificate is
2365 available, the client should send a certificate message
2366 containing no certificates. If client authentication is required
2367 by the server for the handshake to continue, it may respond with
2368 a fatal handshake failure alert. Client certificates are sent
2369 using the Certificate structure defined in Section 7.4.2.
2371 Note: When using a static Diffie-Hellman based key exchange method
2372 (DH_DSS or DH_RSA), if client authentication is requested, the
2373 Diffie-Hellman group and generator encoded in the client's
2374 certificate must match the server specified Diffie-Hellman
2375 parameters if the client's parameters are to be used for the key
2376 exchange.
2378 7.4.7. Client key exchange message
2380 When this message will be sent:
2381 This message is always sent by the client. It will immediately
2382 follow the client certificate message, if it is sent. Otherwise
2383 it will be the first message sent by the client after it receives
2384 the server hello done message.
2386 Meaning of this message:
2387 With this message, the premaster secret is set, either though
2388 direct transmission of the RSA-encrypted secret, or by the
2389 transmission of Diffie-Hellman parameters which will allow each
2390 side to agree upon the same premaster secret. When the key
2391 exchange method is DH_RSA or DH_DSS, client certification has
2392 been requested, and the client was able to respond with a
2393 certificate which contained a Diffie-Hellman public key whose
2394 parameters (group and generator) matched those specified by the
2395 server in its certificate, this message will not contain any
2396 data.
2398 Structure of this message:
2399 The choice of messages depends on which key exchange method has
2400 been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
2401 definition.
2403 struct {
2404 select (KeyExchangeAlgorithm) {
2405 case rsa: EncryptedPreMasterSecret;
2406 case diffie_hellman: ClientDiffieHellmanPublic;
2410 Dierks & Allen Standards Track [Page 43]
2411 \f
2412 RFC 2246 The TLS Protocol Version 1.0 January 1999
2415 } exchange_keys;
2416 } ClientKeyExchange;
2418 7.4.7.1. RSA encrypted premaster secret message
2420 Meaning of this message:
2421 If RSA is being used for key agreement and authentication, the
2422 client generates a 48-byte premaster secret, encrypts it using
2423 the public key from the server's certificate or the temporary RSA
2424 key provided in a server key exchange message, and sends the
2425 result in an encrypted premaster secret message. This structure
2426 is a variant of the client key exchange message, not a message in
2427 itself.
2429 Structure of this message:
2430 struct {
2431 ProtocolVersion client_version;
2432 opaque random[46];
2433 } PreMasterSecret;
2435 client_version
2436 The latest (newest) version supported by the client. This is
2437 used to detect version roll-back attacks. Upon receiving the
2438 premaster secret, the server should check that this value
2439 matches the value transmitted by the client in the client
2440 hello message.
2442 random
2443 46 securely-generated random bytes.
2445 struct {
2446 public-key-encrypted PreMasterSecret pre_master_secret;
2447 } EncryptedPreMasterSecret;
2449 Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
2450 to attack a TLS server which is using PKCS#1 encoded RSA. The
2451 attack takes advantage of the fact that by failing in different
2452 ways, a TLS server can be coerced into revealing whether a
2453 particular message, when decrypted, is properly PKCS#1 formatted
2454 or not.
2456 The best way to avoid vulnerability to this attack is to treat
2457 incorrectly formatted messages in a manner indistinguishable from
2458 correctly formatted RSA blocks. Thus, when it receives an
2459 incorrectly formatted RSA block, a server should generate a
2460 random 48-byte value and proceed using it as the premaster
2461 secret. Thus, the server will act identically whether the
2462 received RSA block is correctly encoded or not.
2466 Dierks & Allen Standards Track [Page 44]
2467 \f
2468 RFC 2246 The TLS Protocol Version 1.0 January 1999
2471 pre_master_secret
2472 This random value is generated by the client and is used to
2473 generate the master secret, as specified in Section 8.1.
2475 7.4.7.2. Client Diffie-Hellman public value
2477 Meaning of this message:
2478 This structure conveys the client's Diffie-Hellman public value
2479 (Yc) if it was not already included in the client's certificate.
2480 The encoding used for Yc is determined by the enumerated
2481 PublicValueEncoding. This structure is a variant of the client
2482 key exchange message, not a message in itself.
2484 Structure of this message:
2485 enum { implicit, explicit } PublicValueEncoding;
2487 implicit
2488 If the client certificate already contains a suitable
2489 Diffie-Hellman key, then Yc is implicit and does not need to
2490 be sent again. In this case, the Client Key Exchange message
2491 will be sent, but will be empty.
2493 explicit
2494 Yc needs to be sent.
2496 struct {
2497 select (PublicValueEncoding) {
2498 case implicit: struct { };
2499 case explicit: opaque dh_Yc<1..2^16-1>;
2500 } dh_public;
2501 } ClientDiffieHellmanPublic;
2503 dh_Yc
2504 The client's Diffie-Hellman public value (Yc).
2506 7.4.8. Certificate verify
2508 When this message will be sent:
2509 This message is used to provide explicit verification of a client
2510 certificate. This message is only sent following a client
2511 certificate that has signing capability (i.e. all certificates
2512 except those containing fixed Diffie-Hellman parameters). When
2513 sent, it will immediately follow the client key exchange message.
2515 Structure of this message:
2516 struct {
2517 Signature signature;
2518 } CertificateVerify;
2522 Dierks & Allen Standards Track [Page 45]
2523 \f
2524 RFC 2246 The TLS Protocol Version 1.0 January 1999
2527 The Signature type is defined in 7.4.3.
2529 CertificateVerify.signature.md5_hash
2530 MD5(handshake_messages);
2532 Certificate.signature.sha_hash
2533 SHA(handshake_messages);
2535 Here handshake_messages refers to all handshake messages sent or
2536 received starting at client hello up to but not including this
2537 message, including the type and length fields of the handshake
2538 messages. This is the concatenation of all the Handshake structures
2539 as defined in 7.4 exchanged thus far.
2541 7.4.9. Finished
2543 When this message will be sent:
2544 A finished message is always sent immediately after a change
2545 cipher spec message to verify that the key exchange and
2546 authentication processes were successful. It is essential that a
2547 change cipher spec message be received between the other
2548 handshake messages and the Finished message.
2550 Meaning of this message:
2551 The finished message is the first protected with the just-
2552 negotiated algorithms, keys, and secrets. Recipients of finished
2553 messages must verify that the contents are correct. Once a side
2554 has sent its Finished message and received and validated the
2555 Finished message from its peer, it may begin to send and receive
2556 application data over the connection.
2558 struct {
2559 opaque verify_data[12];
2560 } Finished;
2562 verify_data
2563 PRF(master_secret, finished_label, MD5(handshake_messages) +
2564 SHA-1(handshake_messages)) [0..11];
2566 finished_label
2567 For Finished messages sent by the client, the string "client
2568 finished". For Finished messages sent by the server, the
2569 string "server finished".
2571 handshake_messages
2572 All of the data from all handshake messages up to but not
2573 including this message. This is only data visible at the
2574 handshake layer and does not include record layer headers.
2578 Dierks & Allen Standards Track [Page 46]
2579 \f
2580 RFC 2246 The TLS Protocol Version 1.0 January 1999
2583 This is the concatenation of all the Handshake structures as
2584 defined in 7.4 exchanged thus far.
2586 It is a fatal error if a finished message is not preceded by a change
2587 cipher spec message at the appropriate point in the handshake.
2589 The hash contained in finished messages sent by the server
2590 incorporate Sender.server; those sent by the client incorporate
2591 Sender.client. The value handshake_messages includes all handshake
2592 messages starting at client hello up to, but not including, this
2593 finished message. This may be different from handshake_messages in
2594 Section 7.4.8 because it would include the certificate verify message
2595 (if sent). Also, the handshake_messages for the finished message sent
2596 by the client will be different from that for the finished message
2597 sent by the server, because the one which is sent second will include
2598 the prior one.
2600 Note: Change cipher spec messages, alerts and any other record types
2601 are not handshake messages and are not included in the hash
2602 computations. Also, Hello Request messages are omitted from
2603 handshake hashes.
2605 8. Cryptographic computations
2607 In order to begin connection protection, the TLS Record Protocol
2608 requires specification of a suite of algorithms, a master secret, and
2609 the client and server random values. The authentication, encryption,
2610 and MAC algorithms are determined by the cipher_suite selected by the
2611 server and revealed in the server hello message. The compression
2612 algorithm is negotiated in the hello messages, and the random values
2613 are exchanged in the hello messages. All that remains is to calculate
2614 the master secret.
2616 8.1. Computing the master secret
2618 For all key exchange methods, the same algorithm is used to convert
2619 the pre_master_secret into the master_secret. The pre_master_secret
2620 should be deleted from memory once the master_secret has been
2621 computed.
2623 master_secret = PRF(pre_master_secret, "master secret",
2624 ClientHello.random + ServerHello.random)
2625 [0..47];
2627 The master secret is always exactly 48 bytes in length. The length of
2628 the premaster secret will vary depending on key exchange method.
2634 Dierks & Allen Standards Track [Page 47]
2635 \f
2636 RFC 2246 The TLS Protocol Version 1.0 January 1999
2639 8.1.1. RSA
2641 When RSA is used for server authentication and key exchange, a 48-
2642 byte pre_master_secret is generated by the client, encrypted under
2643 the server's public key, and sent to the server. The server uses its
2644 private key to decrypt the pre_master_secret. Both parties then
2645 convert the pre_master_secret into the master_secret, as specified
2646 above.
2648 RSA digital signatures are performed using PKCS #1 [PKCS1] block type
2649 1. RSA public key encryption is performed using PKCS #1 block type 2.
2651 8.1.2. Diffie-Hellman
2653 A conventional Diffie-Hellman computation is performed. The
2654 negotiated key (Z) is used as the pre_master_secret, and is converted
2655 into the master_secret, as specified above.
2657 Note: Diffie-Hellman parameters are specified by the server, and may
2658 be either ephemeral or contained within the server's certificate.
2660 9. Mandatory Cipher Suites
2662 In the absence of an application profile standard specifying
2663 otherwise, a TLS compliant application MUST implement the cipher
2664 suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
2666 10. Application data protocol
2668 Application data messages are carried by the Record Layer and are
2669 fragmented, compressed and encrypted based on the current connection
2670 state. The messages are treated as transparent data to the record
2671 layer.
2690 Dierks & Allen Standards Track [Page 48]
2691 \f
2692 RFC 2246 The TLS Protocol Version 1.0 January 1999
2695 A. Protocol constant values
2697 This section describes protocol types and constants.
2699 A.1. Record layer
2701 struct {
2702 uint8 major, minor;
2703 } ProtocolVersion;
2705 ProtocolVersion version = { 3, 1 }; /* TLS v1.0 */
2707 enum {
2708 change_cipher_spec(20), alert(21), handshake(22),
2709 application_data(23), (255)
2710 } ContentType;
2712 struct {
2713 ContentType type;
2714 ProtocolVersion version;
2715 uint16 length;
2716 opaque fragment[TLSPlaintext.length];
2717 } TLSPlaintext;
2719 struct {
2720 ContentType type;
2721 ProtocolVersion version;
2722 uint16 length;
2723 opaque fragment[TLSCompressed.length];
2724 } TLSCompressed;
2726 struct {
2727 ContentType type;
2728 ProtocolVersion version;
2729 uint16 length;
2730 select (CipherSpec.cipher_type) {
2731 case stream: GenericStreamCipher;
2732 case block: GenericBlockCipher;
2733 } fragment;
2734 } TLSCiphertext;
2736 stream-ciphered struct {
2737 opaque content[TLSCompressed.length];
2738 opaque MAC[CipherSpec.hash_size];
2739 } GenericStreamCipher;
2741 block-ciphered struct {
2742 opaque content[TLSCompressed.length];
2746 Dierks & Allen Standards Track [Page 49]
2747 \f
2748 RFC 2246 The TLS Protocol Version 1.0 January 1999
2751 opaque MAC[CipherSpec.hash_size];
2752 uint8 padding[GenericBlockCipher.padding_length];
2753 uint8 padding_length;
2754 } GenericBlockCipher;
2756 A.2. Change cipher specs message
2758 struct {
2759 enum { change_cipher_spec(1), (255) } type;
2760 } ChangeCipherSpec;
2762 A.3. Alert messages
2764 enum { warning(1), fatal(2), (255) } AlertLevel;
2766 enum {
2767 close_notify(0),
2768 unexpected_message(10),
2769 bad_record_mac(20),
2770 decryption_failed(21),
2771 record_overflow(22),
2772 decompression_failure(30),
2773 handshake_failure(40),
2774 bad_certificate(42),
2775 unsupported_certificate(43),
2776 certificate_revoked(44),
2777 certificate_expired(45),
2778 certificate_unknown(46),
2779 illegal_parameter(47),
2780 unknown_ca(48),
2781 access_denied(49),
2782 decode_error(50),
2783 decrypt_error(51),
2784 export_restriction(60),
2785 protocol_version(70),
2786 insufficient_security(71),
2787 internal_error(80),
2788 user_canceled(90),
2789 no_renegotiation(100),
2790 (255)
2791 } AlertDescription;
2793 struct {
2794 AlertLevel level;
2795 AlertDescription description;
2796 } Alert;
2802 Dierks & Allen Standards Track [Page 50]
2803 \f
2804 RFC 2246 The TLS Protocol Version 1.0 January 1999
2807 A.4. Handshake protocol
2809 enum {
2810 hello_request(0), client_hello(1), server_hello(2),
2811 certificate(11), server_key_exchange (12),
2812 certificate_request(13), server_hello_done(14),
2813 certificate_verify(15), client_key_exchange(16),
2814 finished(20), (255)
2815 } HandshakeType;
2817 struct {
2818 HandshakeType msg_type;
2819 uint24 length;
2820 select (HandshakeType) {
2821 case hello_request: HelloRequest;
2822 case client_hello: ClientHello;
2823 case server_hello: ServerHello;
2824 case certificate: Certificate;
2825 case server_key_exchange: ServerKeyExchange;
2826 case certificate_request: CertificateRequest;
2827 case server_hello_done: ServerHelloDone;
2828 case certificate_verify: CertificateVerify;
2829 case client_key_exchange: ClientKeyExchange;
2830 case finished: Finished;
2831 } body;
2832 } Handshake;
2834 A.4.1. Hello messages
2836 struct { } HelloRequest;
2838 struct {
2839 uint32 gmt_unix_time;
2840 opaque random_bytes[28];
2841 } Random;
2843 opaque SessionID<0..32>;
2845 uint8 CipherSuite[2];
2847 enum { null(0), (255) } CompressionMethod;
2849 struct {
2850 ProtocolVersion client_version;
2851 Random random;
2852 SessionID session_id;
2853 CipherSuite cipher_suites<2..2^16-1>;
2854 CompressionMethod compression_methods<1..2^8-1>;
2858 Dierks & Allen Standards Track [Page 51]
2859 \f
2860 RFC 2246 The TLS Protocol Version 1.0 January 1999
2863 } ClientHello;
2865 struct {
2866 ProtocolVersion server_version;
2867 Random random;
2868 SessionID session_id;
2869 CipherSuite cipher_suite;
2870 CompressionMethod compression_method;
2871 } ServerHello;
2873 A.4.2. Server authentication and key exchange messages
2875 opaque ASN.1Cert<2^24-1>;
2877 struct {
2878 ASN.1Cert certificate_list<1..2^24-1>;
2879 } Certificate;
2881 enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
2883 struct {
2884 opaque RSA_modulus<1..2^16-1>;
2885 opaque RSA_exponent<1..2^16-1>;
2886 } ServerRSAParams;
2888 struct {
2889 opaque DH_p<1..2^16-1>;
2890 opaque DH_g<1..2^16-1>;
2891 opaque DH_Ys<1..2^16-1>;
2892 } ServerDHParams;
2894 struct {
2895 select (KeyExchangeAlgorithm) {
2896 case diffie_hellman:
2897 ServerDHParams params;
2898 Signature signed_params;
2899 case rsa:
2900 ServerRSAParams params;
2901 Signature signed_params;
2902 };
2903 } ServerKeyExchange;
2905 enum { anonymous, rsa, dsa } SignatureAlgorithm;
2907 select (SignatureAlgorithm)
2908 { case anonymous: struct { };
2909 case rsa:
2910 digitally-signed struct {
2914 Dierks & Allen Standards Track [Page 52]
2915 \f
2916 RFC 2246 The TLS Protocol Version 1.0 January 1999
2919 opaque md5_hash[16];
2920 opaque sha_hash[20];
2921 };
2922 case dsa:
2923 digitally-signed struct {
2924 opaque sha_hash[20];
2925 };
2926 } Signature;
2928 enum {
2929 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
2930 (255)
2931 } ClientCertificateType;
2933 opaque DistinguishedName<1..2^16-1>;
2935 struct {
2936 ClientCertificateType certificate_types<1..2^8-1>;
2937 DistinguishedName certificate_authorities<3..2^16-1>;
2938 } CertificateRequest;
2940 struct { } ServerHelloDone;
2942 A.4.3. Client authentication and key exchange messages
2944 struct {
2945 select (KeyExchangeAlgorithm) {
2946 case rsa: EncryptedPreMasterSecret;
2947 case diffie_hellman: DiffieHellmanClientPublicValue;
2948 } exchange_keys;
2949 } ClientKeyExchange;
2951 struct {
2952 ProtocolVersion client_version;
2953 opaque random[46];
2955 } PreMasterSecret;
2957 struct {
2958 public-key-encrypted PreMasterSecret pre_master_secret;
2959 } EncryptedPreMasterSecret;
2961 enum { implicit, explicit } PublicValueEncoding;
2963 struct {
2964 select (PublicValueEncoding) {
2965 case implicit: struct {};
2966 case explicit: opaque DH_Yc<1..2^16-1>;
2970 Dierks & Allen Standards Track [Page 53]
2971 \f
2972 RFC 2246 The TLS Protocol Version 1.0 January 1999
2975 } dh_public;
2976 } ClientDiffieHellmanPublic;
2978 struct {
2979 Signature signature;
2980 } CertificateVerify;
2982 A.4.4. Handshake finalization message
2984 struct {
2985 opaque verify_data[12];
2986 } Finished;
2988 A.5. The CipherSuite
2990 The following values define the CipherSuite codes used in the client
2991 hello and server hello messages.
2993 A CipherSuite defines a cipher specification supported in TLS Version
2994 1.0.
2996 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
2997 TLS connection during the first handshake on that channel, but must
2998 not be negotiated, as it provides no more protection than an
2999 unsecured connection.
3001 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
3003 The following CipherSuite definitions require that the server provide
3004 an RSA certificate that can be used for key exchange. The server may
3005 request either an RSA or a DSS signature-capable certificate in the
3006 certificate request message.
3008 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
3009 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
3010 CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
3011 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
3012 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
3013 CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
3014 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
3015 CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
3016 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
3017 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
3019 The following CipherSuite definitions are used for server-
3020 authenticated (and optionally client-authenticated) Diffie-Hellman.
3021 DH denotes cipher suites in which the server's certificate contains
3022 the Diffie-Hellman parameters signed by the certificate authority
3026 Dierks & Allen Standards Track [Page 54]
3027 \f
3028 RFC 2246 The TLS Protocol Version 1.0 January 1999
3031 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
3032 parameters are signed by a DSS or RSA certificate, which has been
3033 signed by the CA. The signing algorithm used is specified after the
3034 DH or DHE parameter. The server can request an RSA or DSS signature-
3035 capable certificate from the client for client authentication or it
3036 may request a Diffie-Hellman certificate. Any Diffie-Hellman
3037 certificate provided by the client must use the parameters (group and
3038 generator) described by the server.
3040 CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
3041 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
3042 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
3043 CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
3044 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
3045 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
3046 CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
3047 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
3048 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
3049 CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
3050 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
3051 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
3053 The following cipher suites are used for completely anonymous
3054 Diffie-Hellman communications in which neither party is
3055 authenticated. Note that this mode is vulnerable to man-in-the-middle
3056 attacks and is therefore deprecated.
3058 CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
3059 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
3060 CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
3061 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
3062 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
3064 Note: All cipher suites whose first byte is 0xFF are considered
3065 private and can be used for defining local/experimental
3066 algorithms. Interoperability of such types is a local matter.
3068 Note: Additional cipher suites can be registered by publishing an RFC
3069 which specifies the cipher suites, including the necessary TLS
3070 protocol information, including message encoding, premaster
3071 secret derivation, symmetric encryption and MAC calculation and
3072 appropriate reference information for the algorithms involved.
3073 The RFC editor's office may, at its discretion, choose to publish
3074 specifications for cipher suites which are not completely
3075 described (e.g., for classified algorithms) if it finds the
3076 specification to be of technical interest and completely
3077 specified.
3082 Dierks & Allen Standards Track [Page 55]
3083 \f
3084 RFC 2246 The TLS Protocol Version 1.0 January 1999
3087 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
3088 reserved to avoid collision with Fortezza-based cipher suites in
3089 SSL 3.
3091 A.6. The Security Parameters
3093 These security parameters are determined by the TLS Handshake
3094 Protocol and provided as parameters to the TLS Record Layer in order
3095 to initialize a connection state. SecurityParameters includes:
3097 enum { null(0), (255) } CompressionMethod;
3099 enum { server, client } ConnectionEnd;
3101 enum { null, rc4, rc2, des, 3des, des40, idea }
3102 BulkCipherAlgorithm;
3104 enum { stream, block } CipherType;
3106 enum { true, false } IsExportable;
3108 enum { null, md5, sha } MACAlgorithm;
3110 /* The algorithms specified in CompressionMethod,
3111 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
3113 struct {
3114 ConnectionEnd entity;
3115 BulkCipherAlgorithm bulk_cipher_algorithm;
3116 CipherType cipher_type;
3117 uint8 key_size;
3118 uint8 key_material_length;
3119 IsExportable is_exportable;
3120 MACAlgorithm mac_algorithm;
3121 uint8 hash_size;
3122 CompressionMethod compression_algorithm;
3123 opaque master_secret[48];
3124 opaque client_random[32];
3125 opaque server_random[32];
3126 } SecurityParameters;
3138 Dierks & Allen Standards Track [Page 56]
3139 \f
3140 RFC 2246 The TLS Protocol Version 1.0 January 1999
3143 B. Glossary
3145 application protocol
3146 An application protocol is a protocol that normally layers
3147 directly on top of the transport layer (e.g., TCP/IP). Examples
3148 include HTTP, TELNET, FTP, and SMTP.
3150 asymmetric cipher
3151 See public key cryptography.
3153 authentication
3154 Authentication is the ability of one entity to determine the
3155 identity of another entity.
3157 block cipher
3158 A block cipher is an algorithm that operates on plaintext in
3159 groups of bits, called blocks. 64 bits is a common block size.
3161 bulk cipher
3162 A symmetric encryption algorithm used to encrypt large quantities
3163 of data.
3165 cipher block chaining (CBC)
3166 CBC is a mode in which every plaintext block encrypted with a
3167 block cipher is first exclusive-ORed with the previous ciphertext
3168 block (or, in the case of the first block, with the
3169 initialization vector). For decryption, every block is first
3170 decrypted, then exclusive-ORed with the previous ciphertext block
3171 (or IV).
3173 certificate
3174 As part of the X.509 protocol (a.k.a. ISO Authentication
3175 framework), certificates are assigned by a trusted Certificate
3176 Authority and provide a strong binding between a party's identity
3177 or some other attributes and its public key.
3179 client
3180 The application entity that initiates a TLS connection to a
3181 server. This may or may not imply that the client initiated the
3182 underlying transport connection. The primary operational
3183 difference between the server and client is that the server is
3184 generally authenticated, while the client is only optionally
3185 authenticated.
3187 client write key
3188 The key used to encrypt data written by the client.
3194 Dierks & Allen Standards Track [Page 57]
3195 \f
3196 RFC 2246 The TLS Protocol Version 1.0 January 1999
3199 client write MAC secret
3200 The secret data used to authenticate data written by the client.
3202 connection
3203 A connection is a transport (in the OSI layering model
3204 definition) that provides a suitable type of service. For TLS,
3205 such connections are peer to peer relationships. The connections
3206 are transient. Every connection is associated with one session.
3208 Data Encryption Standard
3209 DES is a very widely used symmetric encryption algorithm. DES is
3210 a block cipher with a 56 bit key and an 8 byte block size. Note
3211 that in TLS, for key generation purposes, DES is treated as
3212 having an 8 byte key length (64 bits), but it still only provides
3213 56 bits of protection. (The low bit of each key byte is presumed
3214 to be set to produce odd parity in that key byte.) DES can also
3215 be operated in a mode where three independent keys and three
3216 encryptions are used for each block of data; this uses 168 bits
3217 of key (24 bytes in the TLS key generation method) and provides
3218 the equivalent of 112 bits of security. [DES], [3DES]
3220 Digital Signature Standard (DSS)
3221 A standard for digital signing, including the Digital Signing
3222 Algorithm, approved by the National Institute of Standards and
3223 Technology, defined in NIST FIPS PUB 186, "Digital Signature
3224 Standard," published May, 1994 by the U.S. Dept. of Commerce.
3225 [DSS]
3227 digital signatures
3228 Digital signatures utilize public key cryptography and one-way
3229 hash functions to produce a signature of the data that can be
3230 authenticated, and is difficult to forge or repudiate.
3232 handshake
3233 An initial negotiation between client and server that establishes
3234 the parameters of their transactions.
3236 Initialization Vector (IV)
3237 When a block cipher is used in CBC mode, the initialization
3238 vector is exclusive-ORed with the first plaintext block prior to
3239 encryption.
3241 IDEA
3242 A 64-bit block cipher designed by Xuejia Lai and James Massey.
3243 [IDEA]
3250 Dierks & Allen Standards Track [Page 58]
3251 \f
3252 RFC 2246 The TLS Protocol Version 1.0 January 1999
3255 Message Authentication Code (MAC)
3256 A Message Authentication Code is a one-way hash computed from a
3257 message and some secret data. It is difficult to forge without
3258 knowing the secret data. Its purpose is to detect if the message
3259 has been altered.
3261 master secret
3262 Secure secret data used for generating encryption keys, MAC
3263 secrets, and IVs.
3265 MD5
3266 MD5 is a secure hashing function that converts an arbitrarily
3267 long data stream into a digest of fixed size (16 bytes). [MD5]
3269 public key cryptography
3270 A class of cryptographic techniques employing two-key ciphers.
3271 Messages encrypted with the public key can only be decrypted with
3272 the associated private key. Conversely, messages signed with the
3273 private key can be verified with the public key.
3275 one-way hash function
3276 A one-way transformation that converts an arbitrary amount of
3277 data into a fixed-length hash. It is computationally hard to
3278 reverse the transformation or to find collisions. MD5 and SHA are
3279 examples of one-way hash functions.
3281 RC2
3282 A block cipher developed by Ron Rivest at RSA Data Security, Inc.
3283 [RSADSI] described in [RC2].
3285 RC4
3286 A stream cipher licensed by RSA Data Security [RSADSI]. A
3287 compatible cipher is described in [RC4].
3289 RSA
3290 A very widely used public-key algorithm that can be used for
3291 either encryption or digital signing. [RSA]
3293 salt
3294 Non-secret random data used to make export encryption keys resist
3295 precomputation attacks.
3297 server
3298 The server is the application entity that responds to requests
3299 for connections from clients. See also under client.
3306 Dierks & Allen Standards Track [Page 59]
3307 \f
3308 RFC 2246 The TLS Protocol Version 1.0 January 1999
3311 session
3312 A TLS session is an association between a client and a server.
3313 Sessions are created by the handshake protocol. Sessions define a
3314 set of cryptographic security parameters, which can be shared
3315 among multiple connections. Sessions are used to avoid the
3316 expensive negotiation of new security parameters for each
3317 connection.
3319 session identifier
3320 A session identifier is a value generated by a server that
3321 identifies a particular session.
3323 server write key
3324 The key used to encrypt data written by the server.
3326 server write MAC secret
3327 The secret data used to authenticate data written by the server.
3329 SHA
3330 The Secure Hash Algorithm is defined in FIPS PUB 180-1. It
3331 produces a 20-byte output. Note that all references to SHA
3332 actually use the modified SHA-1 algorithm. [SHA]
3334 SSL
3335 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
3336 SSL Version 3.0
3338 stream cipher
3339 An encryption algorithm that converts a key into a
3340 cryptographically-strong keystream, which is then exclusive-ORed
3341 with the plaintext.
3343 symmetric cipher
3344 See bulk cipher.
3346 Transport Layer Security (TLS)
3347 This protocol; also, the Transport Layer Security working group
3348 of the Internet Engineering Task Force (IETF). See "Comments" at
3349 the end of this document.
3362 Dierks & Allen Standards Track [Page 60]
3363 \f
3364 RFC 2246 The TLS Protocol Version 1.0 January 1999
3367 C. CipherSuite definitions
3369 CipherSuite Is Key Cipher Hash
3370 Exportable Exchange
3372 TLS_NULL_WITH_NULL_NULL * NULL NULL NULL
3373 TLS_RSA_WITH_NULL_MD5 * RSA NULL MD5
3374 TLS_RSA_WITH_NULL_SHA * RSA NULL SHA
3375 TLS_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5
3376 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
3377 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
3378 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5
3379 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
3380 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA
3381 TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
3382 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
3383 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA
3384 TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
3385 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
3386 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA
3387 TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
3388 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
3389 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA
3390 TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
3391 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
3392 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA
3393 TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
3394 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
3395 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5
3396 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
3397 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA
3398 TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA
3399 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
3402 * Indicates IsExportable is True
3404 Key
3405 Exchange
3406 Algorithm Description Key size limit
3408 DHE_DSS Ephemeral DH with DSS signatures None
3409 DHE_DSS_EXPORT Ephemeral DH with DSS signatures DH = 512 bits
3410 DHE_RSA Ephemeral DH with RSA signatures None
3411 DHE_RSA_EXPORT Ephemeral DH with RSA signatures DH = 512 bits,
3412 RSA = none
3413 DH_anon Anonymous DH, no signatures None
3414 DH_anon_EXPORT Anonymous DH, no signatures DH = 512 bits
3418 Dierks & Allen Standards Track [Page 61]
3419 \f
3420 RFC 2246 The TLS Protocol Version 1.0 January 1999
3423 DH_DSS DH with DSS-based certificates None
3424 DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits
3425 DH_RSA DH with RSA-based certificates None
3426 DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits,
3427 RSA = none
3428 NULL No key exchange N/A
3429 RSA RSA key exchange None
3430 RSA_EXPORT RSA key exchange RSA = 512 bits
3432 Key size limit
3433 The key size limit gives the size of the largest public key that
3434 can be legally used for encryption in cipher suites that are
3435 exportable.
3437 Key Expanded Effective IV Block
3438 Cipher Type Material Key Material Key Bits Size Size
3440 NULL * Stream 0 0 0 0 N/A
3441 IDEA_CBC Block 16 16 128 8 8
3442 RC2_CBC_40 * Block 5 16 40 8 8
3443 RC4_40 * Stream 5 16 40 0 N/A
3444 RC4_128 Stream 16 16 128 0 N/A
3445 DES40_CBC * Block 5 8 40 8 8
3446 DES_CBC Block 8 8 56 8 8
3447 3DES_EDE_CBC Block 24 24 168 8 8
3449 * Indicates IsExportable is true.
3451 Type
3452 Indicates whether this is a stream cipher or a block cipher
3453 running in CBC mode.
3455 Key Material
3456 The number of bytes from the key_block that are used for
3457 generating the write keys.
3459 Expanded Key Material
3460 The number of bytes actually fed into the encryption algorithm
3462 Effective Key Bits
3463 How much entropy material is in the key material being fed into
3464 the encryption routines.
3466 IV Size
3467 How much data needs to be generated for the initialization
3468 vector. Zero for stream ciphers; equal to the block size for
3469 block ciphers.
3474 Dierks & Allen Standards Track [Page 62]
3475 \f
3476 RFC 2246 The TLS Protocol Version 1.0 January 1999
3479 Block Size
3480 The amount of data a block cipher enciphers in one chunk; a
3481 block cipher running in CBC mode can only encrypt an even
3482 multiple of its block size.
3484 Hash Hash Padding
3485 function Size Size
3486 NULL 0 0
3487 MD5 16 48
3488 SHA 20 40
3530 Dierks & Allen Standards Track [Page 63]
3531 \f
3532 RFC 2246 The TLS Protocol Version 1.0 January 1999
3535 D. Implementation Notes
3537 The TLS protocol cannot prevent many common security mistakes. This
3538 section provides several recommendations to assist implementors.
3540 D.1. Temporary RSA keys
3542 US Export restrictions limit RSA keys used for encryption to 512
3543 bits, but do not place any limit on lengths of RSA keys used for
3544 signing operations. Certificates often need to be larger than 512
3545 bits, since 512-bit RSA keys are not secure enough for high-value
3546 transactions or for applications requiring long-term security. Some
3547 certificates are also designated signing-only, in which case they
3548 cannot be used for key exchange.
3550 When the public key in the certificate cannot be used for encryption,
3551 the server signs a temporary RSA key, which is then exchanged. In
3552 exportable applications, the temporary RSA key should be the maximum
3553 allowable length (i.e., 512 bits). Because 512-bit RSA keys are
3554 relatively insecure, they should be changed often. For typical
3555 electronic commerce applications, it is suggested that keys be
3556 changed daily or every 500 transactions, and more often if possible.
3557 Note that while it is acceptable to use the same temporary key for
3558 multiple transactions, it must be signed each time it is used.
3560 RSA key generation is a time-consuming process. In many cases, a
3561 low-priority process can be assigned the task of key generation.
3563 Whenever a new key is completed, the existing temporary key can be
3564 replaced with the new one.
3566 D.2. Random Number Generation and Seeding
3568 TLS requires a cryptographically-secure pseudorandom number generator
3569 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
3570 based on secure hash operations, most notably MD5 and/or SHA, are
3571 acceptable, but cannot provide more security than the size of the
3572 random number generator state. (For example, MD5-based PRNGs usually
3573 provide 128 bits of state.)
3575 To estimate the amount of seed material being produced, add the
3576 number of bits of unpredictable information in each seed byte. For
3577 example, keystroke timing values taken from a PC compatible's 18.2 Hz
3578 timer provide 1 or 2 secure bits each, even though the total size of
3579 the counter value is 16 bits or more. To seed a 128-bit PRNG, one
3580 would thus require approximately 100 such timer values.
3586 Dierks & Allen Standards Track [Page 64]
3587 \f
3588 RFC 2246 The TLS Protocol Version 1.0 January 1999
3591 Warning: The seeding functions in RSAREF and versions of BSAFE prior to
3592 3.0 are order-independent. For example, if 1000 seed bits are
3593 supplied, one at a time, in 1000 separate calls to the seed
3594 function, the PRNG will end up in a state which depends only
3595 on the number of 0 or 1 seed bits in the seed data (i.e.,
3596 there are 1001 possible final states). Applications using
3597 BSAFE or RSAREF must take extra care to ensure proper seeding.
3598 This may be accomplished by accumulating seed bits into a
3599 buffer and processing them all at once or by processing an
3600 incrementing counter with every seed bit; either method will
3601 reintroduce order dependence into the seeding process.
3603 D.3. Certificates and authentication
3605 Implementations are responsible for verifying the integrity of
3606 certificates and should generally support certificate revocation
3607 messages. Certificates should always be verified to ensure proper
3608 signing by a trusted Certificate Authority (CA). The selection and
3609 addition of trusted CAs should be done very carefully. Users should
3610 be able to view information about the certificate and root CA.
3612 D.4. CipherSuites
3614 TLS supports a range of key sizes and security levels, including some
3615 which provide no or minimal security. A proper implementation will
3616 probably not support many cipher suites. For example, 40-bit
3617 encryption is easily broken, so implementations requiring strong
3618 security should not allow 40-bit keys. Similarly, anonymous Diffie-
3619 Hellman is strongly discouraged because it cannot prevent man-in-
3620 the-middle attacks. Applications should also enforce minimum and
3621 maximum key sizes. For example, certificate chains containing 512-bit
3622 RSA keys or signatures are not appropriate for high-security
3623 applications.
3642 Dierks & Allen Standards Track [Page 65]
3643 \f
3644 RFC 2246 The TLS Protocol Version 1.0 January 1999
3647 E. Backward Compatibility With SSL
3649 For historical reasons and in order to avoid a profligate consumption
3650 of reserved port numbers, application protocols which are secured by
3651 TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
3652 connection port: for example, the https protocol (HTTP secured by SSL
3653 or TLS) uses port 443 regardless of which security protocol it is
3654 using. Thus, some mechanism must be determined to distinguish and
3655 negotiate among the various protocols.
3657 TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
3658 is easy. TLS clients who wish to negotiate with SSL 3.0 servers
3659 should send client hello messages using the SSL 3.0 record format and
3660 client hello structure, sending {3, 1} for the version field to note
3661 that they support TLS 1.0. If the server supports only SSL 3.0, it
3662 will respond with an SSL 3.0 server hello; if it supports TLS, with a
3663 TLS server hello. The negotiation then proceeds as appropriate for
3664 the negotiated protocol.
3666 Similarly, a TLS server which wishes to interoperate with SSL 3.0
3667 clients should accept SSL 3.0 client hello messages and respond with
3668 an SSL 3.0 server hello if an SSL 3.0 client hello is received which
3669 has a version field of {3, 0}, denoting that this client does not
3670 support TLS.
3672 Whenever a client already knows the highest protocol known to a
3673 server (for example, when resuming a session), it should initiate the
3674 connection in that native protocol.
3676 TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
3677 Version 2.0 client hello messages [SSL2]. TLS servers should accept
3678 either client hello format if they wish to support SSL 2.0 clients on
3679 the same connection port. The only deviations from the Version 2.0
3680 specification are the ability to specify a version with a value of
3681 three and the support for more ciphering types in the CipherSpec.
3683 Warning: The ability to send Version 2.0 client hello messages will be
3684 phased out with all due haste. Implementors should make every
3685 effort to move forward as quickly as possible. Version 3.0
3686 provides better mechanisms for moving to newer versions.
3688 The following cipher specifications are carryovers from SSL Version
3689 2.0. These are assumed to use RSA for key exchange and
3690 authentication.
3692 V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
3693 V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
3694 V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
3698 Dierks & Allen Standards Track [Page 66]
3699 \f
3700 RFC 2246 The TLS Protocol Version 1.0 January 1999
3703 V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
3704 = { 0x04,0x00,0x80 };
3705 V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
3706 V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
3707 V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
3709 Cipher specifications native to TLS can be included in Version 2.0
3710 client hello messages using the syntax below. Any V2CipherSpec
3711 element with its first byte equal to zero will be ignored by Version
3712 2.0 servers. Clients sending any of the above V2CipherSpecs should
3713 also include the TLS equivalent (see Appendix A.5):
3715 V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
3717 E.1. Version 2 client hello
3719 The Version 2.0 client hello message is presented below using this
3720 document's presentation model. The true definition is still assumed
3721 to be the SSL Version 2.0 specification.
3723 uint8 V2CipherSpec[3];
3725 struct {
3726 uint8 msg_type;
3727 Version version;
3728 uint16 cipher_spec_length;
3729 uint16 session_id_length;
3730 uint16 challenge_length;
3731 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
3732 opaque session_id[V2ClientHello.session_id_length];
3733 Random challenge;
3734 } V2ClientHello;
3736 msg_type
3737 This field, in conjunction with the version field, identifies a
3738 version 2 client hello message. The value should be one (1).
3740 version
3741 The highest version of the protocol supported by the client
3742 (equals ProtocolVersion.version, see Appendix A.1).
3744 cipher_spec_length
3745 This field is the total length of the field cipher_specs. It
3746 cannot be zero and must be a multiple of the V2CipherSpec length
3747 (3).
3754 Dierks & Allen Standards Track [Page 67]
3755 \f
3756 RFC 2246 The TLS Protocol Version 1.0 January 1999
3759 session_id_length
3760 This field must have a value of either zero or 16. If zero, the
3761 client is creating a new session. If 16, the session_id field
3762 will contain the 16 bytes of session identification.
3764 challenge_length
3765 The length in bytes of the client's challenge to the server to
3766 authenticate itself. This value must be 32.
3768 cipher_specs
3769 This is a list of all CipherSpecs the client is willing and able
3770 to use. There must be at least one CipherSpec acceptable to the
3771 server.
3773 session_id
3774 If this field's length is not zero, it will contain the
3775 identification for a session that the client wishes to resume.
3777 challenge
3778 The client challenge to the server for the server to identify
3779 itself is a (nearly) arbitrary length random. The TLS server will
3780 right justify the challenge data to become the ClientHello.random
3781 data (padded with leading zeroes, if necessary), as specified in
3782 this protocol specification. If the length of the challenge is
3783 greater than 32 bytes, only the last 32 bytes are used. It is
3784 legitimate (but not necessary) for a V3 server to reject a V2
3785 ClientHello that has fewer than 16 bytes of challenge data.
3787 Note: Requests to resume a TLS session should use a TLS client hello.
3789 E.2. Avoiding man-in-the-middle version rollback
3791 When TLS clients fall back to Version 2.0 compatibility mode, they
3792 should use special PKCS #1 block formatting. This is done so that TLS
3793 servers will reject Version 2.0 sessions with TLS-capable clients.
3795 When TLS clients are in Version 2.0 compatibility mode, they set the
3796 right-hand (least-significant) 8 random bytes of the PKCS padding
3797 (not including the terminal null of the padding) for the RSA
3798 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
3799 to 0x03 (the other padding bytes are random). After decrypting the
3800 ENCRYPTED-KEY-DATA field, servers that support TLS should issue an
3801 error if these eight padding bytes are 0x03. Version 2.0 servers
3802 receiving blocks padded in this manner will proceed normally.
3810 Dierks & Allen Standards Track [Page 68]
3811 \f
3812 RFC 2246 The TLS Protocol Version 1.0 January 1999
3815 F. Security analysis
3817 The TLS protocol is designed to establish a secure connection between
3818 a client and a server communicating over an insecure channel. This
3819 document makes several traditional assumptions, including that
3820 attackers have substantial computational resources and cannot obtain
3821 secret information from sources outside the protocol. Attackers are
3822 assumed to have the ability to capture, modify, delete, replay, and
3823 otherwise tamper with messages sent over the communication channel.
3824 This appendix outlines how TLS has been designed to resist a variety
3825 of attacks.
3827 F.1. Handshake protocol
3829 The handshake protocol is responsible for selecting a CipherSpec and
3830 generating a Master Secret, which together comprise the primary
3831 cryptographic parameters associated with a secure session. The
3832 handshake protocol can also optionally authenticate parties who have
3833 certificates signed by a trusted certificate authority.
3835 F.1.1. Authentication and key exchange
3837 TLS supports three authentication modes: authentication of both
3838 parties, server authentication with an unauthenticated client, and
3839 total anonymity. Whenever the server is authenticated, the channel is
3840 secure against man-in-the-middle attacks, but completely anonymous
3841 sessions are inherently vulnerable to such attacks. Anonymous
3842 servers cannot authenticate clients. If the server is authenticated,
3843 its certificate message must provide a valid certificate chain
3844 leading to an acceptable certificate authority. Similarly,
3845 authenticated clients must supply an acceptable certificate to the
3846 server. Each party is responsible for verifying that the other's
3847 certificate is valid and has not expired or been revoked.
3849 The general goal of the key exchange process is to create a
3850 pre_master_secret known to the communicating parties and not to
3851 attackers. The pre_master_secret will be used to generate the
3852 master_secret (see Section 8.1). The master_secret is required to
3853 generate the certificate verify and finished messages, encryption
3854 keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending
3855 a correct finished message, parties thus prove that they know the
3856 correct pre_master_secret.
3858 F.1.1.1. Anonymous key exchange
3860 Completely anonymous sessions can be established using RSA or
3861 Diffie-Hellman for key exchange. With anonymous RSA, the client
3862 encrypts a pre_master_secret with the server's uncertified public key
3866 Dierks & Allen Standards Track [Page 69]
3867 \f
3868 RFC 2246 The TLS Protocol Version 1.0 January 1999
3871 extracted from the server key exchange message. The result is sent in
3872 a client key exchange message. Since eavesdroppers do not know the
3873 server's private key, it will be infeasible for them to decode the
3874 pre_master_secret. (Note that no anonymous RSA Cipher Suites are
3875 defined in this document).
3877 With Diffie-Hellman, the server's public parameters are contained in
3878 the server key exchange message and the client's are sent in the
3879 client key exchange message. Eavesdroppers who do not know the
3880 private values should not be able to find the Diffie-Hellman result
3881 (i.e. the pre_master_secret).
3883 Warning: Completely anonymous connections only provide protection
3884 against passive eavesdropping. Unless an independent tamper-
3885 proof channel is used to verify that the finished messages
3886 were not replaced by an attacker, server authentication is
3887 required in environments where active man-in-the-middle
3888 attacks are a concern.
3890 F.1.1.2. RSA key exchange and authentication
3892 With RSA, key exchange and server authentication are combined. The
3893 public key may be either contained in the server's certificate or may
3894 be a temporary RSA key sent in a server key exchange message. When
3895 temporary RSA keys are used, they are signed by the server's RSA or
3896 DSS certificate. The signature includes the current
3897 ClientHello.random, so old signatures and temporary keys cannot be
3898 replayed. Servers may use a single temporary RSA key for multiple
3899 negotiation sessions.
3901 Note: The temporary RSA key option is useful if servers need large
3902 certificates but must comply with government-imposed size limits
3903 on keys used for key exchange.
3905 After verifying the server's certificate, the client encrypts a
3906 pre_master_secret with the server's public key. By successfully
3907 decoding the pre_master_secret and producing a correct finished
3908 message, the server demonstrates that it knows the private key
3909 corresponding to the server certificate.
3911 When RSA is used for key exchange, clients are authenticated using
3912 the certificate verify message (see Section 7.4.8). The client signs
3913 a value derived from the master_secret and all preceding handshake
3914 messages. These handshake messages include the server certificate,
3915 which binds the signature to the server, and ServerHello.random,
3916 which binds the signature to the current handshake process.
3922 Dierks & Allen Standards Track [Page 70]
3923 \f
3924 RFC 2246 The TLS Protocol Version 1.0 January 1999
3927 F.1.1.3. Diffie-Hellman key exchange with authentication
3929 When Diffie-Hellman key exchange is used, the server can either
3930 supply a certificate containing fixed Diffie-Hellman parameters or
3931 can use the server key exchange message to send a set of temporary
3932 Diffie-Hellman parameters signed with a DSS or RSA certificate.
3933 Temporary parameters are hashed with the hello.random values before
3934 signing to ensure that attackers do not replay old parameters. In
3935 either case, the client can verify the certificate or signature to
3936 ensure that the parameters belong to the server.
3938 If the client has a certificate containing fixed Diffie-Hellman
3939 parameters, its certificate contains the information required to
3940 complete the key exchange. Note that in this case the client and
3941 server will generate the same Diffie-Hellman result (i.e.,
3942 pre_master_secret) every time they communicate. To prevent the
3943 pre_master_secret from staying in memory any longer than necessary,
3944 it should be converted into the master_secret as soon as possible.
3945 Client Diffie-Hellman parameters must be compatible with those
3946 supplied by the server for the key exchange to work.
3948 If the client has a standard DSS or RSA certificate or is
3949 unauthenticated, it sends a set of temporary parameters to the server
3950 in the client key exchange message, then optionally uses a
3951 certificate verify message to authenticate itself.
3953 F.1.2. Version rollback attacks
3955 Because TLS includes substantial improvements over SSL Version 2.0,
3956 attackers may try to make TLS-capable clients and servers fall back
3957 to Version 2.0. This attack can occur if (and only if) two TLS-
3958 capable parties use an SSL 2.0 handshake.
3960 Although the solution using non-random PKCS #1 block type 2 message
3961 padding is inelegant, it provides a reasonably secure way for Version
3962 3.0 servers to detect the attack. This solution is not secure against
3963 attackers who can brute force the key and substitute a new
3964 ENCRYPTED-KEY-DATA message containing the same key (but with normal
3965 padding) before the application specified wait threshold has expired.
3966 Parties concerned about attacks of this scale should not be using
3967 40-bit encryption keys anyway. Altering the padding of the least-
3968 significant 8 bytes of the PKCS padding does not impact security for
3969 the size of the signed hashes and RSA key lengths used in the
3970 protocol, since this is essentially equivalent to increasing the
3971 input block size by 8 bytes.
3978 Dierks & Allen Standards Track [Page 71]
3979 \f
3980 RFC 2246 The TLS Protocol Version 1.0 January 1999
3983 F.1.3. Detecting attacks against the handshake protocol
3985 An attacker might try to influence the handshake exchange to make the
3986 parties select different encryption algorithms than they would
3987 normally choose. Because many implementations will support 40-bit
3988 exportable encryption and some may even support null encryption or
3989 MAC algorithms, this attack is of particular concern.
3991 For this attack, an attacker must actively change one or more
3992 handshake messages. If this occurs, the client and server will
3993 compute different values for the handshake message hashes. As a
3994 result, the parties will not accept each others' finished messages.
3995 Without the master_secret, the attacker cannot repair the finished
3996 messages, so the attack will be discovered.
3998 F.1.4. Resuming sessions
4000 When a connection is established by resuming a session, new
4001 ClientHello.random and ServerHello.random values are hashed with the
4002 session's master_secret. Provided that the master_secret has not been
4003 compromised and that the secure hash operations used to produce the
4004 encryption keys and MAC secrets are secure, the connection should be
4005 secure and effectively independent from previous connections.
4006 Attackers cannot use known encryption keys or MAC secrets to
4007 compromise the master_secret without breaking the secure hash
4008 operations (which use both SHA and MD5).
4010 Sessions cannot be resumed unless both the client and server agree.
4011 If either party suspects that the session may have been compromised,
4012 or that certificates may have expired or been revoked, it should
4013 force a full handshake. An upper limit of 24 hours is suggested for
4014 session ID lifetimes, since an attacker who obtains a master_secret
4015 may be able to impersonate the compromised party until the
4016 corresponding session ID is retired. Applications that may be run in
4017 relatively insecure environments should not write session IDs to
4018 stable storage.
4020 F.1.5. MD5 and SHA
4022 TLS uses hash functions very conservatively. Where possible, both MD5
4023 and SHA are used in tandem to ensure that non-catastrophic flaws in
4024 one algorithm will not break the overall protocol.
4026 F.2. Protecting application data
4028 The master_secret is hashed with the ClientHello.random and
4029 ServerHello.random to produce unique data encryption keys and MAC
4030 secrets for each connection.
4034 Dierks & Allen Standards Track [Page 72]
4035 \f
4036 RFC 2246 The TLS Protocol Version 1.0 January 1999
4039 Outgoing data is protected with a MAC before transmission. To prevent
4040 message replay or modification attacks, the MAC is computed from the
4041 MAC secret, the sequence number, the message length, the message
4042 contents, and two fixed character strings. The message type field is
4043 necessary to ensure that messages intended for one TLS Record Layer
4044 client are not redirected to another. The sequence number ensures
4045 that attempts to delete or reorder messages will be detected. Since
4046 sequence numbers are 64-bits long, they should never overflow.
4047 Messages from one party cannot be inserted into the other's output,
4048 since they use independent MAC secrets. Similarly, the server-write
4049 and client-write keys are independent so stream cipher keys are used
4050 only once.
4052 If an attacker does break an encryption key, all messages encrypted
4053 with it can be read. Similarly, compromise of a MAC key can make
4054 message modification attacks possible. Because MACs are also
4055 encrypted, message-alteration attacks generally require breaking the
4056 encryption algorithm as well as the MAC.
4058 Note: MAC secrets may be larger than encryption keys, so messages can
4059 remain tamper resistant even if encryption keys are broken.
4061 F.3. Final notes
4063 For TLS to be able to provide a secure connection, both the client
4064 and server systems, keys, and applications must be secure. In
4065 addition, the implementation must be free of security errors.
4067 The system is only as strong as the weakest key exchange and
4068 authentication algorithm supported, and only trustworthy
4069 cryptographic functions should be used. Short public keys, 40-bit
4070 bulk encryption keys, and anonymous servers should be used with great
4071 caution. Implementations and users must be careful when deciding
4072 which certificates and certificate authorities are acceptable; a
4073 dishonest certificate authority can do tremendous damage.
4090 Dierks & Allen Standards Track [Page 73]
4091 \f
4092 RFC 2246 The TLS Protocol Version 1.0 January 1999
4095 G. Patent Statement
4097 Some of the cryptographic algorithms proposed for use in this
4098 protocol have patent claims on them. In addition Netscape
4099 Communications Corporation has a patent claim on the Secure Sockets
4100 Layer (SSL) work that this standard is based on. The Internet
4101 Standards Process as defined in RFC 2026 requests that a statement be
4102 obtained from a Patent holder indicating that a license will be made
4103 available to applicants under reasonable terms and conditions.
4105 The Massachusetts Institute of Technology has granted RSA Data
4106 Security, Inc., exclusive sub-licensing rights to the following
4107 patent issued in the United States:
4109 Cryptographic Communications System and Method ("RSA"), No.
4110 4,405,829
4112 Netscape Communications Corporation has been issued the following
4113 patent in the United States:
4115 Secure Socket Layer Application Program Apparatus And Method
4116 ("SSL"), No. 5,657,390
4118 Netscape Communications has issued the following statement:
4120 Intellectual Property Rights
4122 Secure Sockets Layer
4124 The United States Patent and Trademark Office ("the PTO")
4125 recently issued U.S. Patent No. 5,657,390 ("the SSL Patent") to
4126 Netscape for inventions described as Secure Sockets Layers
4127 ("SSL"). The IETF is currently considering adopting SSL as a
4128 transport protocol with security features. Netscape encourages
4129 the royalty-free adoption and use of the SSL protocol upon the
4130 following terms and conditions:
4132 * If you already have a valid SSL Ref license today which
4133 includes source code from Netscape, an additional patent
4134 license under the SSL patent is not required.
4136 * If you don't have an SSL Ref license, you may have a royalty
4137 free license to build implementations covered by the SSL
4138 Patent Claims or the IETF TLS specification provided that you
4139 do not to assert any patent rights against Netscape or other
4140 companies for the implementation of SSL or the IETF TLS
4141 recommendation.
4146 Dierks & Allen Standards Track [Page 74]
4147 \f
4148 RFC 2246 The TLS Protocol Version 1.0 January 1999
4151 What are "Patent Claims":
4153 Patent claims are claims in an issued foreign or domestic patent
4154 that:
4156 1) must be infringed in order to implement methods or build
4157 products according to the IETF TLS specification; or
4159 2) patent claims which require the elements of the SSL patent
4160 claims and/or their equivalents to be infringed.
4162 The Internet Society, Internet Architecture Board, Internet
4163 Engineering Steering Group and the Corporation for National Research
4164 Initiatives take no position on the validity or scope of the patents
4165 and patent applications, nor on the appropriateness of the terms of
4166 the assurance. The Internet Society and other groups mentioned above
4167 have not made any determination as to any other intellectual property
4168 rights which may apply to the practice of this standard. Any further
4169 consideration of these matters is the user's own responsibility.
4171 Security Considerations
4173 Security issues are discussed throughout this memo.
4175 References
4177 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
4178 IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
4180 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
4181 Protocols Based on RSA Encryption Standard PKCS #1" in
4182 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
4183 1--12, 1998.
4185 [DES] ANSI X3.106, "American National Standard for Information
4186 Systems-Data Link Encryption," American National Standards
4187 Institute, 1983.
4189 [DH1] W. Diffie and M. E. Hellman, "New Directions in
4190 Cryptography," IEEE Transactions on Information Theory, V.
4191 IT-22, n. 6, Jun 1977, pp. 74-84.
4193 [DSS] NIST FIPS PUB 186, "Digital Signature Standard," National
4194 Institute of Standards and Technology, U.S. Department of
4195 Commerce, May 18, 1994.
4197 [FTP] Postel J., and J. Reynolds, "File Transfer Protocol", STD 9,
4198 RFC 959, October 1985.
4202 Dierks & Allen Standards Track [Page 75]
4203 \f
4204 RFC 2246 The TLS Protocol Version 1.0 January 1999
4207 [HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
4208 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
4210 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
4211 Hashing for Message Authentication," RFC 2104, February
4212 1997.
4214 [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
4215 Series in Information Processing, v. 1, Konstanz: Hartung-
4216 Gorre Verlag, 1992.
4218 [MD2] Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,
4219 April 1992.
4221 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
4222 April 1992.
4224 [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
4225 version 1.5, November 1993.
4227 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
4228 Standard," version 1.5, November 1993.
4230 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
4231 Standard," version 1.5, November 1993.
4233 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
4234 Public Key Infrastructure: Part I: X.509 Certificate and CRL
4235 Profile", RFC 2459, January 1999.
4237 [RC2] Rivest, R., "A Description of the RC2(r) Encryption
4238 Algorithm", RFC 2268, January 1998.
4240 [RC4] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption
4241 Algorithm, Work in Progress.
4243 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
4244 Obtaining Digital Signatures and Public-Key Cryptosystems,"
4245 Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-
4246 126.
4248 [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782
4250 [SCH] B. Schneier. Applied Cryptography: Protocols, Algorithms,
4251 and Source Code in C, Published by John Wiley & Sons, Inc.
4252 1994.
4258 Dierks & Allen Standards Track [Page 76]
4259 \f
4260 RFC 2246 The TLS Protocol Version 1.0 January 1999
4263 [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National
4264 Institute of Standards and Technology, U.S. Department of
4265 Commerce, Work in Progress, May 31, 1994.
4267 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
4268 Corp., Feb 9, 1995.
4270 [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
4271 Netscape Communications Corp., Nov 18, 1996.
4273 [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
4274 September 1981.
4276 [TEL] Postel J., and J. Reynolds, "Telnet Protocol
4277 Specifications", STD 8, RFC 854, May 1993.
4279 [TEL] Postel J., and J. Reynolds, "Telnet Option Specifications",
4280 STD 8, RFC 855, May 1993.
4282 [X509] CCITT. Recommendation X.509: "The Directory - Authentication
4283 Framework". 1988.
4285 [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External
4286 Data Representation Standard, August 1995.
4288 Credits
4290 Win Treese
4291 Open Market
4293 EMail: treese@openmarket.com
4296 Editors
4298 Christopher Allen Tim Dierks
4299 Certicom Certicom
4301 EMail: callen@certicom.com EMail: tdierks@certicom.com
4304 Authors' Addresses
4306 Tim Dierks Philip L. Karlton
4307 Certicom Netscape Communications
4309 EMail: tdierks@certicom.com
4314 Dierks & Allen Standards Track [Page 77]
4315 \f
4316 RFC 2246 The TLS Protocol Version 1.0 January 1999
4319 Alan O. Freier Paul C. Kocher
4320 Netscape Communications Independent Consultant
4322 EMail: freier@netscape.com EMail: pck@netcom.com
4325 Other contributors
4327 Martin Abadi Robert Relyea
4328 Digital Equipment Corporation Netscape Communications
4330 EMail: ma@pa.dec.com EMail: relyea@netscape.com
4332 Ran Canetti Jim Roskind
4333 IBM Watson Research Center Netscape Communications
4335 EMail: canetti@watson.ibm.com EMail: jar@netscape.com
4338 Taher Elgamal Micheal J. Sabin, Ph. D.
4339 Securify Consulting Engineer
4341 EMail: elgamal@securify.com EMail: msabin@netcom.com
4344 Anil R. Gangolli Dan Simon
4345 Structured Arts Computing Corp. Microsoft
4347 EMail: gangolli@structuredarts.com EMail: dansimon@microsoft.com
4350 Kipp E.B. Hickman Tom Weinstein
4351 Netscape Communications Netscape Communications
4353 EMail: kipp@netscape.com EMail: tomw@netscape.com
4356 Hugo Krawczyk
4357 IBM Watson Research Center
4359 EMail: hugo@watson.ibm.com
4361 Comments
4363 The discussion list for the IETF TLS working group is located at the
4364 e-mail address <ietf-tls@lists.consensus.com>. Information on the
4365 group and information on how to subscribe to the list is at
4366 <http://lists.consensus.com/>.
4370 Dierks & Allen Standards Track [Page 78]
4371 \f
4372 RFC 2246 The TLS Protocol Version 1.0 January 1999
4375 Archives of the list can be found at:
4376 <http://www.imc.org/ietf-tls/mail-archive/>
4426 Dierks & Allen Standards Track [Page 79]
4427 \f
4428 RFC 2246 The TLS Protocol Version 1.0 January 1999
4431 Full Copyright Statement
4433 Copyright (C) The Internet Society (1999). All Rights Reserved.
4435 This document and translations of it may be copied and furnished to
4436 others, and derivative works that comment on or otherwise explain it
4437 or assist in its implementation may be prepared, copied, published
4438 and distributed, in whole or in part, without restriction of any
4439 kind, provided that the above copyright notice and this paragraph are
4440 included on all such copies and derivative works. However, this
4441 document itself may not be modified in any way, such as by removing
4442 the copyright notice or references to the Internet Society or other
4443 Internet organizations, except as needed for the purpose of
4444 developing Internet standards in which case the procedures for
4445 copyrights defined in the Internet Standards process must be
4446 followed, or as required to translate it into languages other than
4447 English.
4449 The limited permissions granted above are perpetual and will not be
4450 revoked by the Internet Society or its successors or assigns.
4452 This document and the information contained herein is provided on an
4453 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
4454 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
4455 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
4456 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
4457 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
4482 Dierks & Allen Standards Track [Page 80]
4483 \f