]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group T. Dierks | |
8 | Request for Comments: 2246 Certicom | |
9 | Category: Standards Track C. Allen | |
10 | Certicom | |
11 | January 1999 | |
12 | ||
13 | ||
14 | The TLS Protocol | |
15 | Version 1.0 | |
16 | ||
17 | Status of this Memo | |
18 | ||
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. | |
24 | ||
25 | Copyright Notice | |
26 | ||
27 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
28 | ||
29 | Abstract | |
30 | ||
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. | |
36 | ||
37 | Table of Contents | |
38 | ||
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 | |
55 | ||
56 | ||
57 | ||
58 | Dierks & Allen Standards Track [Page 1] | |
59 | \f | |
60 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
61 | ||
62 | ||
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 | |
111 | ||
112 | ||
113 | ||
114 | Dierks & Allen Standards Track [Page 2] | |
115 | \f | |
116 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
117 | ||
118 | ||
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 | |
145 | ||
146 | 1. Introduction | |
147 | ||
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: | |
155 | ||
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. | |
162 | ||
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 | |
167 | ||
168 | ||
169 | ||
170 | Dierks & Allen Standards Track [Page 3] | |
171 | \f | |
172 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
173 | ||
174 | ||
175 | this mode while another protocol is using the Record Protocol as | |
176 | a transport for negotiating security parameters. | |
177 | ||
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: | |
185 | ||
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. | |
190 | ||
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. | |
195 | ||
196 | - The negotiation is reliable: no attacker can modify the | |
197 | negotiation communication without being detected by the parties | |
198 | to the communication. | |
199 | ||
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. | |
207 | ||
208 | 2. Goals | |
209 | ||
210 | The goals of TLS Protocol, in order of their priority, are: | |
211 | ||
212 | 1. Cryptographic security: TLS should be used to establish a secure | |
213 | connection between two parties. | |
214 | ||
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. | |
219 | ||
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 | |
223 | ||
224 | ||
225 | ||
226 | Dierks & Allen Standards Track [Page 4] | |
227 | \f | |
228 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
229 | ||
230 | ||
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. | |
234 | ||
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. | |
241 | ||
242 | 3. Goals of this document | |
243 | ||
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. | |
256 | ||
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. | |
261 | ||
262 | 4. Presentation language | |
263 | ||
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. | |
272 | ||
273 | ||
274 | ||
275 | ||
276 | ||
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Dierks & Allen Standards Track [Page 5] | |
283 | \f | |
284 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
285 | ||
286 | ||
287 | 4.1. Basic block size | |
288 | ||
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: | |
294 | ||
295 | value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | | |
296 | ... | byte[n-1]; | |
297 | ||
298 | This byte ordering for multi-byte values is the commonplace network | |
299 | byte order or big endian format. | |
300 | ||
301 | 4.2. Miscellaneous | |
302 | ||
303 | Comments begin with "/*" and end with "*/". | |
304 | ||
305 | Optional components are denoted by enclosing them in "[[ ]]" double | |
306 | brackets. | |
307 | ||
308 | Single byte entities containing uninterpreted data are of type | |
309 | opaque. | |
310 | ||
311 | 4.3. Vectors | |
312 | ||
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 | |
319 | ||
320 | T T'[n]; | |
321 | ||
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. | |
325 | ||
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. | |
329 | ||
330 | opaque Datum[3]; /* three uninterpreted bytes */ | |
331 | Datum Data[9]; /* 3 consecutive 3 byte vectors */ | |
332 | ||
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Dierks & Allen Standards Track [Page 6] | |
339 | \f | |
340 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
341 | ||
342 | ||
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. | |
350 | ||
351 | T T'<floor..ceiling>; | |
352 | ||
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). | |
362 | ||
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 */ | |
367 | ||
368 | 4.4. Numbers | |
369 | ||
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. | |
374 | ||
375 | uint8 uint16[2]; | |
376 | uint8 uint24[3]; | |
377 | uint8 uint32[4]; | |
378 | uint8 uint64[8]; | |
379 | ||
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. | |
383 | ||
384 | 4.5. Enumerateds | |
385 | ||
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 | |
390 | ||
391 | ||
392 | ||
393 | ||
394 | Dierks & Allen Standards Track [Page 7] | |
395 | \f | |
396 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
397 | ||
398 | ||
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. | |
402 | ||
403 | enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; | |
404 | ||
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. | |
408 | ||
409 | enum { red(3), blue(5), white(7) } Color; | |
410 | ||
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. | |
415 | ||
416 | enum { sweet(1), sour(2), bitter(4), (32000) } Taste; | |
417 | ||
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. | |
423 | ||
424 | Color color = Color.blue; /* overspecified, legal */ | |
425 | Color color = blue; /* correct, type implicit */ | |
426 | ||
427 | For enumerateds that are never converted to external representation, | |
428 | the numerical information may be omitted. | |
429 | ||
430 | enum { low, medium, high } Amount; | |
431 | ||
432 | 4.6. Constructed types | |
433 | ||
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. | |
437 | ||
438 | struct { | |
439 | T1 f1; | |
440 | T2 f2; | |
441 | ... | |
442 | Tn fn; | |
443 | } [[T]]; | |
444 | ||
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | Dierks & Allen Standards Track [Page 8] | |
451 | \f | |
452 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
453 | ||
454 | ||
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. | |
459 | ||
460 | 4.6.1. Variants | |
461 | ||
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. | |
469 | ||
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]]; | |
482 | ||
483 | For example: | |
484 | ||
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; | |
500 | ||
501 | Variant structures may be qualified (narrowed) by specifying a value | |
502 | for the selector prior to the type. For example, a | |
503 | ||
504 | ||
505 | ||
506 | Dierks & Allen Standards Track [Page 9] | |
507 | \f | |
508 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
509 | ||
510 | ||
511 | orange VariantRecord | |
512 | ||
513 | is a narrowed type of a VariantRecord containing a variant_body of | |
514 | type V2. | |
515 | ||
516 | 4.7. Cryptographic attributes | |
517 | ||
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). | |
525 | ||
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. | |
530 | ||
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]. | |
534 | ||
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: | |
539 | ||
540 | Dss-Sig-Value ::= SEQUENCE { | |
541 | r INTEGER, | |
542 | s INTEGER | |
543 | } | |
544 | ||
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. | |
548 | ||
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. | |
553 | ||
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. | |
559 | ||
560 | ||
561 | ||
562 | Dierks & Allen Standards Track [Page 10] | |
563 | \f | |
564 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
565 | ||
566 | ||
567 | An RSA encrypted value is encoded with PKCS #1 block type 2 as | |
568 | described in [PKCS1]. | |
569 | ||
570 | In the following example: | |
571 | ||
572 | stream-ciphered struct { | |
573 | uint8 field1; | |
574 | uint8 field2; | |
575 | digitally-signed opaque hash[20]; | |
576 | } UserType; | |
577 | ||
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. | |
585 | ||
586 | 4.8. Constants | |
587 | ||
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. | |
593 | ||
594 | For example, | |
595 | ||
596 | struct { | |
597 | uint8 f1; | |
598 | uint8 f2; | |
599 | } Example1; | |
600 | ||
601 | Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ | |
602 | ||
603 | 5. HMAC and the pseudorandom function | |
604 | ||
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]. | |
610 | ||
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, | |
614 | ||
615 | ||
616 | ||
617 | ||
618 | Dierks & Allen Standards Track [Page 11] | |
619 | \f | |
620 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
621 | ||
622 | ||
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. | |
626 | ||
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. | |
631 | ||
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. | |
635 | ||
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: | |
639 | ||
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) + ... | |
643 | ||
644 | Where + indicates concatenation. | |
645 | ||
646 | A() is defined as: | |
647 | A(0) = seed | |
648 | A(i) = HMAC_hash(secret, A(i-1)) | |
649 | ||
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. | |
656 | ||
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. | |
661 | ||
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. | |
668 | ||
669 | L_S = length in bytes of secret; | |
670 | L_S1 = L_S2 = ceil(L_S / 2); | |
671 | ||
672 | ||
673 | ||
674 | Dierks & Allen Standards Track [Page 12] | |
675 | \f | |
676 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
677 | ||
678 | ||
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. | |
682 | ||
683 | The PRF is then defined as the result of mixing the two pseudorandom | |
684 | streams by exclusive-or'ing them together. | |
685 | ||
686 | PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR | |
687 | P_SHA-1(S2, label + seed); | |
688 | ||
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: | |
693 | ||
694 | 73 6C 69 74 68 79 20 74 6F 76 65 73 | |
695 | ||
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). | |
700 | ||
701 | 6. The TLS Record Protocol | |
702 | ||
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. | |
710 | ||
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. | |
724 | ||
725 | ||
726 | ||
727 | ||
728 | ||
729 | ||
730 | Dierks & Allen Standards Track [Page 13] | |
731 | \f | |
732 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
733 | ||
734 | ||
735 | 6.1. Connection states | |
736 | ||
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. | |
753 | ||
754 | The security parameters for a TLS Connection read and write state are | |
755 | set by providing the following values: | |
756 | ||
757 | connection end | |
758 | Whether this entity is considered the "client" or the "server" in | |
759 | this connection. | |
760 | ||
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. | |
767 | ||
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. | |
772 | ||
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. | |
777 | ||
778 | master secret | |
779 | A 48 byte secret shared between the two peers in the connection. | |
780 | ||
781 | client random | |
782 | A 32 byte value provided by the client. | |
783 | ||
784 | ||
785 | ||
786 | Dierks & Allen Standards Track [Page 14] | |
787 | \f | |
788 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
789 | ||
790 | ||
791 | server random | |
792 | A 32 byte value provided by the server. | |
793 | ||
794 | These parameters are defined in the presentation language as: | |
795 | ||
796 | enum { server, client } ConnectionEnd; | |
797 | ||
798 | enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm; | |
799 | ||
800 | enum { stream, block } CipherType; | |
801 | ||
802 | enum { true, false } IsExportable; | |
803 | ||
804 | enum { null, md5, sha } MACAlgorithm; | |
805 | ||
806 | enum { null(0), (255) } CompressionMethod; | |
807 | ||
808 | /* The algorithms specified in CompressionMethod, | |
809 | BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | |
810 | ||
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; | |
825 | ||
826 | The record layer will use the security parameters to generate the | |
827 | following six items: | |
828 | ||
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) | |
835 | ||
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. | |
839 | ||
840 | ||
841 | ||
842 | Dierks & Allen Standards Track [Page 15] | |
843 | \f | |
844 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
845 | ||
846 | ||
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: | |
852 | ||
853 | compression state | |
854 | The current state of the compression algorithm. | |
855 | ||
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. | |
865 | ||
866 | MAC secret | |
867 | The MAC secret for this connection as generated above. | |
868 | ||
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. | |
877 | ||
878 | 6.2. Record layer | |
879 | ||
880 | The TLS Record Layer receives uninterpreted data from higher layers | |
881 | in non-empty blocks of arbitrary size. | |
882 | ||
883 | 6.2.1. Fragmentation | |
884 | ||
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). | |
891 | ||
892 | struct { | |
893 | uint8 major, minor; | |
894 | } ProtocolVersion; | |
895 | ||
896 | ||
897 | ||
898 | Dierks & Allen Standards Track [Page 16] | |
899 | \f | |
900 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
901 | ||
902 | ||
903 | enum { | |
904 | change_cipher_spec(20), alert(21), handshake(22), | |
905 | application_data(23), (255) | |
906 | } ContentType; | |
907 | ||
908 | struct { | |
909 | ContentType type; | |
910 | ProtocolVersion version; | |
911 | uint16 length; | |
912 | opaque fragment[TLSPlaintext.length]; | |
913 | } TLSPlaintext; | |
914 | ||
915 | type | |
916 | The higher level protocol used to process the enclosed fragment. | |
917 | ||
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). | |
924 | ||
925 | length | |
926 | The length (in bytes) of the following TLSPlaintext.fragment. | |
927 | The length should not exceed 2^14. | |
928 | ||
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. | |
933 | ||
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. | |
937 | ||
938 | 6.2.2. Record compression and decompression | |
939 | ||
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. | |
947 | ||
948 | ||
949 | ||
950 | ||
951 | ||
952 | ||
953 | ||
954 | Dierks & Allen Standards Track [Page 17] | |
955 | \f | |
956 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
957 | ||
958 | ||
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. | |
963 | ||
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; | |
970 | ||
971 | length | |
972 | The length (in bytes) of the following TLSCompressed.fragment. | |
973 | The length should not exceed 2^14 + 1024. | |
974 | ||
975 | fragment | |
976 | The compressed form of TLSPlaintext.fragment. | |
977 | ||
978 | Note: A CompressionMethod.null operation is an identity operation; no | |
979 | fields are altered. | |
980 | ||
981 | Implementation note: | |
982 | Decompression functions are responsible for ensuring that | |
983 | messages cannot cause internal buffer overflows. | |
984 | ||
985 | 6.2.3. Record payload protection | |
986 | ||
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. | |
991 | ||
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; | |
1001 | ||
1002 | type | |
1003 | The type field is identical to TLSCompressed.type. | |
1004 | ||
1005 | version | |
1006 | The version field is identical to TLSCompressed.version. | |
1007 | ||
1008 | ||
1009 | ||
1010 | Dierks & Allen Standards Track [Page 18] | |
1011 | \f | |
1012 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1013 | ||
1014 | ||
1015 | length | |
1016 | The length (in bytes) of the following TLSCiphertext.fragment. | |
1017 | The length may not exceed 2^14 + 2048. | |
1018 | ||
1019 | fragment | |
1020 | The encrypted form of TLSCompressed.fragment, with the MAC. | |
1021 | ||
1022 | 6.2.3.1. Null or standard stream cipher | |
1023 | ||
1024 | Stream ciphers (including BulkCipherAlgorithm.null - see Appendix | |
1025 | A.6) convert TLSCompressed.fragment structures to and from stream | |
1026 | TLSCiphertext.fragment structures. | |
1027 | ||
1028 | stream-ciphered struct { | |
1029 | opaque content[TLSCompressed.length]; | |
1030 | opaque MAC[CipherSpec.hash_size]; | |
1031 | } GenericStreamCipher; | |
1032 | ||
1033 | The MAC is generated as: | |
1034 | ||
1035 | HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + | |
1036 | TLSCompressed.version + TLSCompressed.length + | |
1037 | TLSCompressed.fragment)); | |
1038 | ||
1039 | where "+" denotes concatenation. | |
1040 | ||
1041 | seq_num | |
1042 | The sequence number for this record. | |
1043 | ||
1044 | hash | |
1045 | The hashing algorithm specified by | |
1046 | SecurityParameters.mac_algorithm. | |
1047 | ||
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. | |
1057 | ||
1058 | 6.2.3.2. CBC block cipher | |
1059 | ||
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. | |
1063 | ||
1064 | ||
1065 | ||
1066 | Dierks & Allen Standards Track [Page 19] | |
1067 | \f | |
1068 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1069 | ||
1070 | ||
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; | |
1077 | ||
1078 | The MAC is generated as described in Section 6.2.3.1. | |
1079 | ||
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. | |
1089 | ||
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. | |
1096 | ||
1097 | The encrypted data length (TLSCiphertext.length) is one more than the | |
1098 | sum of TLSCompressed.length, CipherSpec.hash_size, and | |
1099 | padding_length. | |
1100 | ||
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. | |
1112 | ||
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. | |
1118 | ||
1119 | ||
1120 | ||
1121 | ||
1122 | Dierks & Allen Standards Track [Page 20] | |
1123 | \f | |
1124 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1125 | ||
1126 | ||
1127 | 6.3. Key calculation | |
1128 | ||
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. | |
1132 | ||
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. | |
1140 | ||
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. | |
1144 | ||
1145 | To generate the key material, compute | |
1146 | ||
1147 | key_block = PRF(SecurityParameters.master_secret, | |
1148 | "key expansion", | |
1149 | SecurityParameters.server_random + | |
1150 | SecurityParameters.client_random); | |
1151 | ||
1152 | until enough output has been generated. Then the key_block is | |
1153 | partitioned as follows: | |
1154 | ||
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] | |
1161 | ||
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. | |
1166 | ||
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. | |
1172 | ||
1173 | ||
1174 | ||
1175 | ||
1176 | ||
1177 | ||
1178 | Dierks & Allen Standards Track [Page 21] | |
1179 | \f | |
1180 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1181 | ||
1182 | ||
1183 | Exportable encryption algorithms (for which CipherSpec.is_exportable | |
1184 | is true) require additional processing as follows to derive their | |
1185 | final write keys: | |
1186 | ||
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); | |
1197 | ||
1198 | Exportable encryption algorithms derive their IVs solely from the | |
1199 | random values from the hello messages: | |
1200 | ||
1201 | iv_block = PRF("", "IV block", SecurityParameters.client_random + | |
1202 | SecurityParameters.server_random); | |
1203 | ||
1204 | The iv_block is partitioned into two initialization vectors as the | |
1205 | key_block was above: | |
1206 | ||
1207 | client_write_IV[SecurityParameters.IV_size] | |
1208 | server_write_IV[SecurityParameters.IV_size] | |
1209 | ||
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. | |
1213 | ||
1214 | 6.3.1. Export key generation example | |
1215 | ||
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. | |
1221 | ||
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] | |
1230 | ||
1231 | ||
1232 | ||
1233 | ||
1234 | Dierks & Allen Standards Track [Page 22] | |
1235 | \f | |
1236 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1237 | ||
1238 | ||
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] | |
1247 | ||
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] | |
1252 | ||
1253 | 7. The TLS Handshake Protocol | |
1254 | ||
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. | |
1259 | ||
1260 | The Handshake Protocol is responsible for negotiating a session, | |
1261 | which consists of the following items: | |
1262 | ||
1263 | session identifier | |
1264 | An arbitrary byte sequence chosen by the server to identify an | |
1265 | active or resumable session state. | |
1266 | ||
1267 | peer certificate | |
1268 | X509v3 [X509] certificate of the peer. This element of the state | |
1269 | may be null. | |
1270 | ||
1271 | compression method | |
1272 | The algorithm used to compress data prior to encryption. | |
1273 | ||
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) | |
1279 | ||
1280 | master secret | |
1281 | 48-byte secret shared between the client and server. | |
1282 | ||
1283 | is resumable | |
1284 | A flag indicating whether the session can be used to initiate new | |
1285 | connections. | |
1286 | ||
1287 | ||
1288 | ||
1289 | ||
1290 | Dierks & Allen Standards Track [Page 23] | |
1291 | \f | |
1292 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1293 | ||
1294 | ||
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. | |
1299 | ||
1300 | 7.1. Change cipher spec protocol | |
1301 | ||
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. | |
1306 | ||
1307 | struct { | |
1308 | enum { change_cipher_spec(1), (255) } type; | |
1309 | } ChangeCipherSpec; | |
1310 | ||
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). | |
1322 | ||
1323 | 7.2. Alert protocol | |
1324 | ||
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. | |
1334 | ||
1335 | enum { warning(1), fatal(2), (255) } AlertLevel; | |
1336 | ||
1337 | enum { | |
1338 | close_notify(0), | |
1339 | unexpected_message(10), | |
1340 | bad_record_mac(20), | |
1341 | decryption_failed(21), | |
1342 | record_overflow(22), | |
1343 | ||
1344 | ||
1345 | ||
1346 | Dierks & Allen Standards Track [Page 24] | |
1347 | \f | |
1348 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1349 | ||
1350 | ||
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; | |
1371 | ||
1372 | struct { | |
1373 | AlertLevel level; | |
1374 | AlertDescription description; | |
1375 | } Alert; | |
1376 | ||
1377 | 7.2.1. Closure alerts | |
1378 | ||
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. | |
1382 | ||
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. | |
1388 | ||
1389 | Either party may initiate a close by sending a close_notify alert. | |
1390 | Any data received after a closure alert is ignored. | |
1391 | ||
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. | |
1398 | ||
1399 | ||
1400 | ||
1401 | ||
1402 | Dierks & Allen Standards Track [Page 25] | |
1403 | \f | |
1404 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1405 | ||
1406 | ||
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. | |
1418 | ||
1419 | NB: It is assumed that closing a connection reliably delivers | |
1420 | pending data before destroying the transport. | |
1421 | ||
1422 | 7.2.2. Error alerts | |
1423 | ||
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: | |
1431 | ||
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. | |
1436 | ||
1437 | bad_record_mac | |
1438 | This alert is returned if a record is received with an incorrect | |
1439 | MAC. This message is always fatal. | |
1440 | ||
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. | |
1445 | ||
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. | |
1450 | ||
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. | |
1455 | ||
1456 | ||
1457 | ||
1458 | Dierks & Allen Standards Track [Page 26] | |
1459 | \f | |
1460 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1461 | ||
1462 | ||
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. | |
1467 | ||
1468 | bad_certificate | |
1469 | A certificate was corrupt, contained signatures that did not | |
1470 | verify correctly, etc. | |
1471 | ||
1472 | unsupported_certificate | |
1473 | A certificate was of an unsupported type. | |
1474 | ||
1475 | certificate_revoked | |
1476 | A certificate was revoked by its signer. | |
1477 | ||
1478 | certificate_expired | |
1479 | A certificate has expired or is not currently valid. | |
1480 | ||
1481 | certificate_unknown | |
1482 | Some other (unspecified) issue arose in processing the | |
1483 | certificate, rendering it unacceptable. | |
1484 | ||
1485 | illegal_parameter | |
1486 | A field in the handshake was out of range or inconsistent with | |
1487 | other fields. This is always fatal. | |
1488 | ||
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. | |
1494 | ||
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. | |
1499 | ||
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. | |
1504 | ||
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. | |
1509 | ||
1510 | ||
1511 | ||
1512 | ||
1513 | ||
1514 | Dierks & Allen Standards Track [Page 27] | |
1515 | \f | |
1516 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1517 | ||
1518 | ||
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. | |
1524 | ||
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. | |
1530 | ||
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. | |
1536 | ||
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. | |
1541 | ||
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. | |
1548 | ||
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. | |
1561 | ||
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 | |
1565 | ||
1566 | ||
1567 | ||
1568 | ||
1569 | ||
1570 | Dierks & Allen Standards Track [Page 28] | |
1571 | \f | |
1572 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1573 | ||
1574 | ||
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. | |
1578 | ||
1579 | 7.3. Handshake Protocol overview | |
1580 | ||
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. | |
1587 | ||
1588 | The TLS Handshake Protocol involves the following steps: | |
1589 | ||
1590 | - Exchange hello messages to agree on algorithms, exchange random | |
1591 | values, and check for session resumption. | |
1592 | ||
1593 | - Exchange the necessary cryptographic parameters to allow the | |
1594 | client and server to agree on a premaster secret. | |
1595 | ||
1596 | - Exchange certificates and cryptographic information to allow the | |
1597 | client and server to authenticate themselves. | |
1598 | ||
1599 | - Generate a master secret from the premaster secret and exchanged | |
1600 | random values. | |
1601 | ||
1602 | - Provide security parameters to the record layer. | |
1603 | ||
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. | |
1607 | ||
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. | |
1622 | ||
1623 | ||
1624 | ||
1625 | ||
1626 | Dierks & Allen Standards Track [Page 29] | |
1627 | \f | |
1628 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1629 | ||
1630 | ||
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. | |
1634 | ||
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. | |
1645 | ||
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. | |
1654 | ||
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. | |
1670 | ||
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 | |
1677 | ||
1678 | ||
1679 | ||
1680 | ||
1681 | ||
1682 | Dierks & Allen Standards Track [Page 30] | |
1683 | \f | |
1684 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1685 | ||
1686 | ||
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.) | |
1690 | ||
1691 | Client Server | |
1692 | ||
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 | |
1707 | ||
1708 | Fig. 1 - Message flow for a full handshake | |
1709 | ||
1710 | * Indicates optional or situation-dependent messages that are not | |
1711 | always sent. | |
1712 | ||
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. | |
1716 | ||
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: | |
1720 | ||
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. | |
1732 | ||
1733 | ||
1734 | ||
1735 | ||
1736 | ||
1737 | ||
1738 | Dierks & Allen Standards Track [Page 31] | |
1739 | \f | |
1740 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1741 | ||
1742 | ||
1743 | Client Server | |
1744 | ||
1745 | ClientHello --------> | |
1746 | ServerHello | |
1747 | [ChangeCipherSpec] | |
1748 | <-------- Finished | |
1749 | [ChangeCipherSpec] | |
1750 | Finished --------> | |
1751 | Application Data <-------> Application Data | |
1752 | ||
1753 | Fig. 2 - Message flow for an abbreviated handshake | |
1754 | ||
1755 | The contents and significance of each message will be presented in | |
1756 | detail in the following sections. | |
1757 | ||
1758 | 7.4. Handshake protocol | |
1759 | ||
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. | |
1766 | ||
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; | |
1774 | ||
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; | |
1791 | ||
1792 | ||
1793 | ||
1794 | Dierks & Allen Standards Track [Page 32] | |
1795 | \f | |
1796 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1797 | ||
1798 | ||
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. | |
1808 | ||
1809 | 7.4.1. Hello messages | |
1810 | ||
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. | |
1816 | ||
1817 | 7.4.1.1. Hello request | |
1818 | ||
1819 | When this message will be sent: | |
1820 | The hello request message may be sent by the server at any time. | |
1821 | ||
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. | |
1835 | ||
1836 | After sending a hello request, servers should not repeat the request | |
1837 | until the subsequent handshake negotiation is complete. | |
1838 | ||
1839 | Structure of this message: | |
1840 | struct { } HelloRequest; | |
1841 | ||
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. | |
1845 | ||
1846 | ||
1847 | ||
1848 | ||
1849 | ||
1850 | Dierks & Allen Standards Track [Page 33] | |
1851 | \f | |
1852 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1853 | ||
1854 | ||
1855 | 7.4.1.2. Client hello | |
1856 | ||
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. | |
1863 | ||
1864 | Structure of this message: | |
1865 | The client hello message includes a random structure, which is | |
1866 | used later in the protocol. | |
1867 | ||
1868 | struct { | |
1869 | uint32 gmt_unix_time; | |
1870 | opaque random_bytes[28]; | |
1871 | } Random; | |
1872 | ||
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. | |
1879 | ||
1880 | random_bytes | |
1881 | 28 bytes generated by a secure random number generator. | |
1882 | ||
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. | |
1898 | ||
1899 | opaque SessionID<0..32>; | |
1900 | ||
1901 | ||
1902 | ||
1903 | ||
1904 | ||
1905 | ||
1906 | Dierks & Allen Standards Track [Page 34] | |
1907 | \f | |
1908 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1909 | ||
1910 | ||
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.) | |
1919 | ||
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. | |
1928 | ||
1929 | uint8 CipherSuite[2]; /* Cryptographic suite selector */ | |
1930 | ||
1931 | The client hello includes a list of compression algorithms supported | |
1932 | by the client, ordered according to the client's preference. | |
1933 | ||
1934 | enum { null(0), (255) } CompressionMethod; | |
1935 | ||
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; | |
1943 | ||
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). | |
1950 | ||
1951 | random | |
1952 | A client-generated random structure. | |
1953 | ||
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. | |
1958 | ||
1959 | ||
1960 | ||
1961 | ||
1962 | Dierks & Allen Standards Track [Page 35] | |
1963 | \f | |
1964 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
1965 | ||
1966 | ||
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. | |
1973 | ||
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. | |
1982 | ||
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. | |
1986 | ||
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. | |
1995 | ||
1996 | 7.4.1.3. Server hello | |
1997 | ||
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. | |
2003 | ||
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; | |
2012 | ||
2013 | ||
2014 | ||
2015 | ||
2016 | ||
2017 | ||
2018 | Dierks & Allen Standards Track [Page 36] | |
2019 | \f | |
2020 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2021 | ||
2022 | ||
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). | |
2028 | ||
2029 | random | |
2030 | This structure is generated by the server and must be different | |
2031 | from (and independent of) ClientHello.random. | |
2032 | ||
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. | |
2047 | ||
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. | |
2052 | ||
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. | |
2057 | ||
2058 | 7.4.2. Server certificate | |
2059 | ||
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. | |
2064 | ||
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 | |
2070 | ||
2071 | ||
2072 | ||
2073 | ||
2074 | Dierks & Allen Standards Track [Page 37] | |
2075 | \f | |
2076 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2077 | ||
2078 | ||
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. | |
2082 | ||
2083 | Key Exchange Algorithm Certificate Key Type | |
2084 | ||
2085 | RSA RSA public key; the certificate must | |
2086 | allow the key to be used for encryption. | |
2087 | ||
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. | |
2093 | ||
2094 | DHE_DSS DSS public key. | |
2095 | ||
2096 | DHE_DSS_EXPORT DSS public key. | |
2097 | ||
2098 | DHE_RSA RSA public key which can be used for | |
2099 | signing. | |
2100 | ||
2101 | DHE_RSA_EXPORT RSA public key which can be used for | |
2102 | signing. | |
2103 | ||
2104 | DH_DSS Diffie-Hellman key. The algorithm used | |
2105 | to sign the certificate should be DSS. | |
2106 | ||
2107 | DH_RSA Diffie-Hellman key. The algorithm used | |
2108 | to sign the certificate should be RSA. | |
2109 | ||
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. | |
2116 | ||
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. | |
2120 | ||
2121 | Structure of this message: | |
2122 | opaque ASN.1Cert<1..2^24-1>; | |
2123 | ||
2124 | struct { | |
2125 | ASN.1Cert certificate_list<0..2^24-1>; | |
2126 | } Certificate; | |
2127 | ||
2128 | ||
2129 | ||
2130 | Dierks & Allen Standards Track [Page 38] | |
2131 | \f | |
2132 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2133 | ||
2134 | ||
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. | |
2144 | ||
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. | |
2149 | ||
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. | |
2154 | ||
2155 | 7.4.3. Server key exchange message | |
2156 | ||
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). | |
2161 | ||
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: | |
2166 | ||
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 | |
2174 | ||
2175 | It is not legal to send the server key exchange message for the | |
2176 | following key exchange methods: | |
2177 | ||
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 | |
2183 | ||
2184 | ||
2185 | ||
2186 | Dierks & Allen Standards Track [Page 39] | |
2187 | \f | |
2188 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2189 | ||
2190 | ||
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.) | |
2197 | ||
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. | |
2203 | ||
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. | |
2209 | ||
2210 | Structure of this message: | |
2211 | enum { rsa, diffie_hellman } KeyExchangeAlgorithm; | |
2212 | ||
2213 | struct { | |
2214 | opaque rsa_modulus<1..2^16-1>; | |
2215 | opaque rsa_exponent<1..2^16-1>; | |
2216 | } ServerRSAParams; | |
2217 | ||
2218 | rsa_modulus | |
2219 | The modulus of the server's temporary RSA key. | |
2220 | ||
2221 | rsa_exponent | |
2222 | The public exponent of the server's temporary RSA key. | |
2223 | ||
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 */ | |
2229 | ||
2230 | dh_p | |
2231 | The prime modulus used for the Diffie-Hellman operation. | |
2232 | ||
2233 | dh_g | |
2234 | The generator used for the Diffie-Hellman operation. | |
2235 | ||
2236 | dh_Ys | |
2237 | The server's Diffie-Hellman public value (g^X mod p). | |
2238 | ||
2239 | ||
2240 | ||
2241 | ||
2242 | Dierks & Allen Standards Track [Page 40] | |
2243 | \f | |
2244 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2245 | ||
2246 | ||
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; | |
2257 | ||
2258 | params | |
2259 | The server's key exchange parameters. | |
2260 | ||
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. | |
2265 | ||
2266 | md5_hash | |
2267 | MD5(ClientHello.random + ServerHello.random + ServerParams); | |
2268 | ||
2269 | sha_hash | |
2270 | SHA(ClientHello.random + ServerHello.random + ServerParams); | |
2271 | ||
2272 | enum { anonymous, rsa, dsa } SignatureAlgorithm; | |
2273 | ||
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; | |
2286 | ||
2287 | 7.4.4. Certificate request | |
2288 | ||
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). | |
2295 | ||
2296 | ||
2297 | ||
2298 | Dierks & Allen Standards Track [Page 41] | |
2299 | \f | |
2300 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2301 | ||
2302 | ||
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; | |
2308 | ||
2309 | opaque DistinguishedName<1..2^16-1>; | |
2310 | ||
2311 | struct { | |
2312 | ClientCertificateType certificate_types<1..2^8-1>; | |
2313 | DistinguishedName certificate_authorities<3..2^16-1>; | |
2314 | } CertificateRequest; | |
2315 | ||
2316 | certificate_types | |
2317 | This field is a list of the types of certificates requested, | |
2318 | sorted in order of the server's preference. | |
2319 | ||
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. | |
2326 | ||
2327 | Note: DistinguishedName is derived from [X509]. | |
2328 | ||
2329 | Note: It is a fatal handshake_failure alert for an anonymous server to | |
2330 | request client identification. | |
2331 | ||
2332 | 7.4.5. Server hello done | |
2333 | ||
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. | |
2338 | ||
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. | |
2343 | ||
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. | |
2347 | ||
2348 | Structure of this message: | |
2349 | struct { } ServerHelloDone; | |
2350 | ||
2351 | ||
2352 | ||
2353 | ||
2354 | Dierks & Allen Standards Track [Page 42] | |
2355 | \f | |
2356 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2357 | ||
2358 | ||
2359 | 7.4.6. Client certificate | |
2360 | ||
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. | |
2370 | ||
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. | |
2377 | ||
2378 | 7.4.7. Client key exchange message | |
2379 | ||
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. | |
2385 | ||
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. | |
2397 | ||
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. | |
2402 | ||
2403 | struct { | |
2404 | select (KeyExchangeAlgorithm) { | |
2405 | case rsa: EncryptedPreMasterSecret; | |
2406 | case diffie_hellman: ClientDiffieHellmanPublic; | |
2407 | ||
2408 | ||
2409 | ||
2410 | Dierks & Allen Standards Track [Page 43] | |
2411 | \f | |
2412 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2413 | ||
2414 | ||
2415 | } exchange_keys; | |
2416 | } ClientKeyExchange; | |
2417 | ||
2418 | 7.4.7.1. RSA encrypted premaster secret message | |
2419 | ||
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. | |
2428 | ||
2429 | Structure of this message: | |
2430 | struct { | |
2431 | ProtocolVersion client_version; | |
2432 | opaque random[46]; | |
2433 | } PreMasterSecret; | |
2434 | ||
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. | |
2441 | ||
2442 | random | |
2443 | 46 securely-generated random bytes. | |
2444 | ||
2445 | struct { | |
2446 | public-key-encrypted PreMasterSecret pre_master_secret; | |
2447 | } EncryptedPreMasterSecret; | |
2448 | ||
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. | |
2455 | ||
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. | |
2463 | ||
2464 | ||
2465 | ||
2466 | Dierks & Allen Standards Track [Page 44] | |
2467 | \f | |
2468 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2469 | ||
2470 | ||
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. | |
2474 | ||
2475 | 7.4.7.2. Client Diffie-Hellman public value | |
2476 | ||
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. | |
2483 | ||
2484 | Structure of this message: | |
2485 | enum { implicit, explicit } PublicValueEncoding; | |
2486 | ||
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. | |
2492 | ||
2493 | explicit | |
2494 | Yc needs to be sent. | |
2495 | ||
2496 | struct { | |
2497 | select (PublicValueEncoding) { | |
2498 | case implicit: struct { }; | |
2499 | case explicit: opaque dh_Yc<1..2^16-1>; | |
2500 | } dh_public; | |
2501 | } ClientDiffieHellmanPublic; | |
2502 | ||
2503 | dh_Yc | |
2504 | The client's Diffie-Hellman public value (Yc). | |
2505 | ||
2506 | 7.4.8. Certificate verify | |
2507 | ||
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. | |
2514 | ||
2515 | Structure of this message: | |
2516 | struct { | |
2517 | Signature signature; | |
2518 | } CertificateVerify; | |
2519 | ||
2520 | ||
2521 | ||
2522 | Dierks & Allen Standards Track [Page 45] | |
2523 | \f | |
2524 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2525 | ||
2526 | ||
2527 | The Signature type is defined in 7.4.3. | |
2528 | ||
2529 | CertificateVerify.signature.md5_hash | |
2530 | MD5(handshake_messages); | |
2531 | ||
2532 | Certificate.signature.sha_hash | |
2533 | SHA(handshake_messages); | |
2534 | ||
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. | |
2540 | ||
2541 | 7.4.9. Finished | |
2542 | ||
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. | |
2549 | ||
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. | |
2557 | ||
2558 | struct { | |
2559 | opaque verify_data[12]; | |
2560 | } Finished; | |
2561 | ||
2562 | verify_data | |
2563 | PRF(master_secret, finished_label, MD5(handshake_messages) + | |
2564 | SHA-1(handshake_messages)) [0..11]; | |
2565 | ||
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". | |
2570 | ||
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. | |
2575 | ||
2576 | ||
2577 | ||
2578 | Dierks & Allen Standards Track [Page 46] | |
2579 | \f | |
2580 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2581 | ||
2582 | ||
2583 | This is the concatenation of all the Handshake structures as | |
2584 | defined in 7.4 exchanged thus far. | |
2585 | ||
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. | |
2588 | ||
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. | |
2599 | ||
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. | |
2604 | ||
2605 | 8. Cryptographic computations | |
2606 | ||
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. | |
2615 | ||
2616 | 8.1. Computing the master secret | |
2617 | ||
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. | |
2622 | ||
2623 | master_secret = PRF(pre_master_secret, "master secret", | |
2624 | ClientHello.random + ServerHello.random) | |
2625 | [0..47]; | |
2626 | ||
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. | |
2629 | ||
2630 | ||
2631 | ||
2632 | ||
2633 | ||
2634 | Dierks & Allen Standards Track [Page 47] | |
2635 | \f | |
2636 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2637 | ||
2638 | ||
2639 | 8.1.1. RSA | |
2640 | ||
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. | |
2647 | ||
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. | |
2650 | ||
2651 | 8.1.2. Diffie-Hellman | |
2652 | ||
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. | |
2656 | ||
2657 | Note: Diffie-Hellman parameters are specified by the server, and may | |
2658 | be either ephemeral or contained within the server's certificate. | |
2659 | ||
2660 | 9. Mandatory Cipher Suites | |
2661 | ||
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. | |
2665 | ||
2666 | 10. Application data protocol | |
2667 | ||
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. | |
2672 | ||
2673 | ||
2674 | ||
2675 | ||
2676 | ||
2677 | ||
2678 | ||
2679 | ||
2680 | ||
2681 | ||
2682 | ||
2683 | ||
2684 | ||
2685 | ||
2686 | ||
2687 | ||
2688 | ||
2689 | ||
2690 | Dierks & Allen Standards Track [Page 48] | |
2691 | \f | |
2692 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2693 | ||
2694 | ||
2695 | A. Protocol constant values | |
2696 | ||
2697 | This section describes protocol types and constants. | |
2698 | ||
2699 | A.1. Record layer | |
2700 | ||
2701 | struct { | |
2702 | uint8 major, minor; | |
2703 | } ProtocolVersion; | |
2704 | ||
2705 | ProtocolVersion version = { 3, 1 }; /* TLS v1.0 */ | |
2706 | ||
2707 | enum { | |
2708 | change_cipher_spec(20), alert(21), handshake(22), | |
2709 | application_data(23), (255) | |
2710 | } ContentType; | |
2711 | ||
2712 | struct { | |
2713 | ContentType type; | |
2714 | ProtocolVersion version; | |
2715 | uint16 length; | |
2716 | opaque fragment[TLSPlaintext.length]; | |
2717 | } TLSPlaintext; | |
2718 | ||
2719 | struct { | |
2720 | ContentType type; | |
2721 | ProtocolVersion version; | |
2722 | uint16 length; | |
2723 | opaque fragment[TLSCompressed.length]; | |
2724 | } TLSCompressed; | |
2725 | ||
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; | |
2735 | ||
2736 | stream-ciphered struct { | |
2737 | opaque content[TLSCompressed.length]; | |
2738 | opaque MAC[CipherSpec.hash_size]; | |
2739 | } GenericStreamCipher; | |
2740 | ||
2741 | block-ciphered struct { | |
2742 | opaque content[TLSCompressed.length]; | |
2743 | ||
2744 | ||
2745 | ||
2746 | Dierks & Allen Standards Track [Page 49] | |
2747 | \f | |
2748 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2749 | ||
2750 | ||
2751 | opaque MAC[CipherSpec.hash_size]; | |
2752 | uint8 padding[GenericBlockCipher.padding_length]; | |
2753 | uint8 padding_length; | |
2754 | } GenericBlockCipher; | |
2755 | ||
2756 | A.2. Change cipher specs message | |
2757 | ||
2758 | struct { | |
2759 | enum { change_cipher_spec(1), (255) } type; | |
2760 | } ChangeCipherSpec; | |
2761 | ||
2762 | A.3. Alert messages | |
2763 | ||
2764 | enum { warning(1), fatal(2), (255) } AlertLevel; | |
2765 | ||
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; | |
2792 | ||
2793 | struct { | |
2794 | AlertLevel level; | |
2795 | AlertDescription description; | |
2796 | } Alert; | |
2797 | ||
2798 | ||
2799 | ||
2800 | ||
2801 | ||
2802 | Dierks & Allen Standards Track [Page 50] | |
2803 | \f | |
2804 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2805 | ||
2806 | ||
2807 | A.4. Handshake protocol | |
2808 | ||
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; | |
2816 | ||
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; | |
2833 | ||
2834 | A.4.1. Hello messages | |
2835 | ||
2836 | struct { } HelloRequest; | |
2837 | ||
2838 | struct { | |
2839 | uint32 gmt_unix_time; | |
2840 | opaque random_bytes[28]; | |
2841 | } Random; | |
2842 | ||
2843 | opaque SessionID<0..32>; | |
2844 | ||
2845 | uint8 CipherSuite[2]; | |
2846 | ||
2847 | enum { null(0), (255) } CompressionMethod; | |
2848 | ||
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>; | |
2855 | ||
2856 | ||
2857 | ||
2858 | Dierks & Allen Standards Track [Page 51] | |
2859 | \f | |
2860 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2861 | ||
2862 | ||
2863 | } ClientHello; | |
2864 | ||
2865 | struct { | |
2866 | ProtocolVersion server_version; | |
2867 | Random random; | |
2868 | SessionID session_id; | |
2869 | CipherSuite cipher_suite; | |
2870 | CompressionMethod compression_method; | |
2871 | } ServerHello; | |
2872 | ||
2873 | A.4.2. Server authentication and key exchange messages | |
2874 | ||
2875 | opaque ASN.1Cert<2^24-1>; | |
2876 | ||
2877 | struct { | |
2878 | ASN.1Cert certificate_list<1..2^24-1>; | |
2879 | } Certificate; | |
2880 | ||
2881 | enum { rsa, diffie_hellman } KeyExchangeAlgorithm; | |
2882 | ||
2883 | struct { | |
2884 | opaque RSA_modulus<1..2^16-1>; | |
2885 | opaque RSA_exponent<1..2^16-1>; | |
2886 | } ServerRSAParams; | |
2887 | ||
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; | |
2893 | ||
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; | |
2904 | ||
2905 | enum { anonymous, rsa, dsa } SignatureAlgorithm; | |
2906 | ||
2907 | select (SignatureAlgorithm) | |
2908 | { case anonymous: struct { }; | |
2909 | case rsa: | |
2910 | digitally-signed struct { | |
2911 | ||
2912 | ||
2913 | ||
2914 | Dierks & Allen Standards Track [Page 52] | |
2915 | \f | |
2916 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2917 | ||
2918 | ||
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; | |
2927 | ||
2928 | enum { | |
2929 | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | |
2930 | (255) | |
2931 | } ClientCertificateType; | |
2932 | ||
2933 | opaque DistinguishedName<1..2^16-1>; | |
2934 | ||
2935 | struct { | |
2936 | ClientCertificateType certificate_types<1..2^8-1>; | |
2937 | DistinguishedName certificate_authorities<3..2^16-1>; | |
2938 | } CertificateRequest; | |
2939 | ||
2940 | struct { } ServerHelloDone; | |
2941 | ||
2942 | A.4.3. Client authentication and key exchange messages | |
2943 | ||
2944 | struct { | |
2945 | select (KeyExchangeAlgorithm) { | |
2946 | case rsa: EncryptedPreMasterSecret; | |
2947 | case diffie_hellman: DiffieHellmanClientPublicValue; | |
2948 | } exchange_keys; | |
2949 | } ClientKeyExchange; | |
2950 | ||
2951 | struct { | |
2952 | ProtocolVersion client_version; | |
2953 | opaque random[46]; | |
2954 | ||
2955 | } PreMasterSecret; | |
2956 | ||
2957 | struct { | |
2958 | public-key-encrypted PreMasterSecret pre_master_secret; | |
2959 | } EncryptedPreMasterSecret; | |
2960 | ||
2961 | enum { implicit, explicit } PublicValueEncoding; | |
2962 | ||
2963 | struct { | |
2964 | select (PublicValueEncoding) { | |
2965 | case implicit: struct {}; | |
2966 | case explicit: opaque DH_Yc<1..2^16-1>; | |
2967 | ||
2968 | ||
2969 | ||
2970 | Dierks & Allen Standards Track [Page 53] | |
2971 | \f | |
2972 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
2973 | ||
2974 | ||
2975 | } dh_public; | |
2976 | } ClientDiffieHellmanPublic; | |
2977 | ||
2978 | struct { | |
2979 | Signature signature; | |
2980 | } CertificateVerify; | |
2981 | ||
2982 | A.4.4. Handshake finalization message | |
2983 | ||
2984 | struct { | |
2985 | opaque verify_data[12]; | |
2986 | } Finished; | |
2987 | ||
2988 | A.5. The CipherSuite | |
2989 | ||
2990 | The following values define the CipherSuite codes used in the client | |
2991 | hello and server hello messages. | |
2992 | ||
2993 | A CipherSuite defines a cipher specification supported in TLS Version | |
2994 | 1.0. | |
2995 | ||
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. | |
3000 | ||
3001 | CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; | |
3002 | ||
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. | |
3007 | ||
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 }; | |
3018 | ||
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 | |
3023 | ||
3024 | ||
3025 | ||
3026 | Dierks & Allen Standards Track [Page 54] | |
3027 | \f | |
3028 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3029 | ||
3030 | ||
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. | |
3039 | ||
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 }; | |
3052 | ||
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. | |
3057 | ||
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 }; | |
3063 | ||
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. | |
3067 | ||
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. | |
3078 | ||
3079 | ||
3080 | ||
3081 | ||
3082 | Dierks & Allen Standards Track [Page 55] | |
3083 | \f | |
3084 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3085 | ||
3086 | ||
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. | |
3090 | ||
3091 | A.6. The Security Parameters | |
3092 | ||
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: | |
3096 | ||
3097 | enum { null(0), (255) } CompressionMethod; | |
3098 | ||
3099 | enum { server, client } ConnectionEnd; | |
3100 | ||
3101 | enum { null, rc4, rc2, des, 3des, des40, idea } | |
3102 | BulkCipherAlgorithm; | |
3103 | ||
3104 | enum { stream, block } CipherType; | |
3105 | ||
3106 | enum { true, false } IsExportable; | |
3107 | ||
3108 | enum { null, md5, sha } MACAlgorithm; | |
3109 | ||
3110 | /* The algorithms specified in CompressionMethod, | |
3111 | BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | |
3112 | ||
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; | |
3127 | ||
3128 | ||
3129 | ||
3130 | ||
3131 | ||
3132 | ||
3133 | ||
3134 | ||
3135 | ||
3136 | ||
3137 | ||
3138 | Dierks & Allen Standards Track [Page 56] | |
3139 | \f | |
3140 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3141 | ||
3142 | ||
3143 | B. Glossary | |
3144 | ||
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. | |
3149 | ||
3150 | asymmetric cipher | |
3151 | See public key cryptography. | |
3152 | ||
3153 | authentication | |
3154 | Authentication is the ability of one entity to determine the | |
3155 | identity of another entity. | |
3156 | ||
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. | |
3160 | ||
3161 | bulk cipher | |
3162 | A symmetric encryption algorithm used to encrypt large quantities | |
3163 | of data. | |
3164 | ||
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). | |
3172 | ||
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. | |
3178 | ||
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. | |
3186 | ||
3187 | client write key | |
3188 | The key used to encrypt data written by the client. | |
3189 | ||
3190 | ||
3191 | ||
3192 | ||
3193 | ||
3194 | Dierks & Allen Standards Track [Page 57] | |
3195 | \f | |
3196 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3197 | ||
3198 | ||
3199 | client write MAC secret | |
3200 | The secret data used to authenticate data written by the client. | |
3201 | ||
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. | |
3207 | ||
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] | |
3219 | ||
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] | |
3226 | ||
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. | |
3231 | ||
3232 | handshake | |
3233 | An initial negotiation between client and server that establishes | |
3234 | the parameters of their transactions. | |
3235 | ||
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. | |
3240 | ||
3241 | IDEA | |
3242 | A 64-bit block cipher designed by Xuejia Lai and James Massey. | |
3243 | [IDEA] | |
3244 | ||
3245 | ||
3246 | ||
3247 | ||
3248 | ||
3249 | ||
3250 | Dierks & Allen Standards Track [Page 58] | |
3251 | \f | |
3252 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3253 | ||
3254 | ||
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. | |
3260 | ||
3261 | master secret | |
3262 | Secure secret data used for generating encryption keys, MAC | |
3263 | secrets, and IVs. | |
3264 | ||
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] | |
3268 | ||
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. | |
3274 | ||
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. | |
3280 | ||
3281 | RC2 | |
3282 | A block cipher developed by Ron Rivest at RSA Data Security, Inc. | |
3283 | [RSADSI] described in [RC2]. | |
3284 | ||
3285 | RC4 | |
3286 | A stream cipher licensed by RSA Data Security [RSADSI]. A | |
3287 | compatible cipher is described in [RC4]. | |
3288 | ||
3289 | RSA | |
3290 | A very widely used public-key algorithm that can be used for | |
3291 | either encryption or digital signing. [RSA] | |
3292 | ||
3293 | salt | |
3294 | Non-secret random data used to make export encryption keys resist | |
3295 | precomputation attacks. | |
3296 | ||
3297 | server | |
3298 | The server is the application entity that responds to requests | |
3299 | for connections from clients. See also under client. | |
3300 | ||
3301 | ||
3302 | ||
3303 | ||
3304 | ||
3305 | ||
3306 | Dierks & Allen Standards Track [Page 59] | |
3307 | \f | |
3308 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3309 | ||
3310 | ||
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. | |
3318 | ||
3319 | session identifier | |
3320 | A session identifier is a value generated by a server that | |
3321 | identifies a particular session. | |
3322 | ||
3323 | server write key | |
3324 | The key used to encrypt data written by the server. | |
3325 | ||
3326 | server write MAC secret | |
3327 | The secret data used to authenticate data written by the server. | |
3328 | ||
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] | |
3333 | ||
3334 | SSL | |
3335 | Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on | |
3336 | SSL Version 3.0 | |
3337 | ||
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. | |
3342 | ||
3343 | symmetric cipher | |
3344 | See bulk cipher. | |
3345 | ||
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. | |
3350 | ||
3351 | ||
3352 | ||
3353 | ||
3354 | ||
3355 | ||
3356 | ||
3357 | ||
3358 | ||
3359 | ||
3360 | ||
3361 | ||
3362 | Dierks & Allen Standards Track [Page 60] | |
3363 | \f | |
3364 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3365 | ||
3366 | ||
3367 | C. CipherSuite definitions | |
3368 | ||
3369 | CipherSuite Is Key Cipher Hash | |
3370 | Exportable Exchange | |
3371 | ||
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 | |
3400 | ||
3401 | ||
3402 | * Indicates IsExportable is True | |
3403 | ||
3404 | Key | |
3405 | Exchange | |
3406 | Algorithm Description Key size limit | |
3407 | ||
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 | |
3415 | ||
3416 | ||
3417 | ||
3418 | Dierks & Allen Standards Track [Page 61] | |
3419 | \f | |
3420 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3421 | ||
3422 | ||
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 | |
3431 | ||
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. | |
3436 | ||
3437 | Key Expanded Effective IV Block | |
3438 | Cipher Type Material Key Material Key Bits Size Size | |
3439 | ||
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 | |
3448 | ||
3449 | * Indicates IsExportable is true. | |
3450 | ||
3451 | Type | |
3452 | Indicates whether this is a stream cipher or a block cipher | |
3453 | running in CBC mode. | |
3454 | ||
3455 | Key Material | |
3456 | The number of bytes from the key_block that are used for | |
3457 | generating the write keys. | |
3458 | ||
3459 | Expanded Key Material | |
3460 | The number of bytes actually fed into the encryption algorithm | |
3461 | ||
3462 | Effective Key Bits | |
3463 | How much entropy material is in the key material being fed into | |
3464 | the encryption routines. | |
3465 | ||
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. | |
3470 | ||
3471 | ||
3472 | ||
3473 | ||
3474 | Dierks & Allen Standards Track [Page 62] | |
3475 | \f | |
3476 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3477 | ||
3478 | ||
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. | |
3483 | ||
3484 | Hash Hash Padding | |
3485 | function Size Size | |
3486 | NULL 0 0 | |
3487 | MD5 16 48 | |
3488 | SHA 20 40 | |
3489 | ||
3490 | ||
3491 | ||
3492 | ||
3493 | ||
3494 | ||
3495 | ||
3496 | ||
3497 | ||
3498 | ||
3499 | ||
3500 | ||
3501 | ||
3502 | ||
3503 | ||
3504 | ||
3505 | ||
3506 | ||
3507 | ||
3508 | ||
3509 | ||
3510 | ||
3511 | ||
3512 | ||
3513 | ||
3514 | ||
3515 | ||
3516 | ||
3517 | ||
3518 | ||
3519 | ||
3520 | ||
3521 | ||
3522 | ||
3523 | ||
3524 | ||
3525 | ||
3526 | ||
3527 | ||
3528 | ||
3529 | ||
3530 | Dierks & Allen Standards Track [Page 63] | |
3531 | \f | |
3532 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3533 | ||
3534 | ||
3535 | D. Implementation Notes | |
3536 | ||
3537 | The TLS protocol cannot prevent many common security mistakes. This | |
3538 | section provides several recommendations to assist implementors. | |
3539 | ||
3540 | D.1. Temporary RSA keys | |
3541 | ||
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. | |
3549 | ||
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. | |
3559 | ||
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. | |
3562 | ||
3563 | Whenever a new key is completed, the existing temporary key can be | |
3564 | replaced with the new one. | |
3565 | ||
3566 | D.2. Random Number Generation and Seeding | |
3567 | ||
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.) | |
3574 | ||
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. | |
3581 | ||
3582 | ||
3583 | ||
3584 | ||
3585 | ||
3586 | Dierks & Allen Standards Track [Page 64] | |
3587 | \f | |
3588 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3589 | ||
3590 | ||
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. | |
3602 | ||
3603 | D.3. Certificates and authentication | |
3604 | ||
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. | |
3611 | ||
3612 | D.4. CipherSuites | |
3613 | ||
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. | |
3624 | ||
3625 | ||
3626 | ||
3627 | ||
3628 | ||
3629 | ||
3630 | ||
3631 | ||
3632 | ||
3633 | ||
3634 | ||
3635 | ||
3636 | ||
3637 | ||
3638 | ||
3639 | ||
3640 | ||
3641 | ||
3642 | Dierks & Allen Standards Track [Page 65] | |
3643 | \f | |
3644 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3645 | ||
3646 | ||
3647 | E. Backward Compatibility With SSL | |
3648 | ||
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. | |
3656 | ||
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. | |
3665 | ||
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. | |
3671 | ||
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. | |
3675 | ||
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. | |
3682 | ||
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. | |
3687 | ||
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. | |
3691 | ||
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 }; | |
3695 | ||
3696 | ||
3697 | ||
3698 | Dierks & Allen Standards Track [Page 66] | |
3699 | \f | |
3700 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3701 | ||
3702 | ||
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 }; | |
3708 | ||
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): | |
3714 | ||
3715 | V2CipherSpec (see TLS name) = { 0x00, CipherSuite }; | |
3716 | ||
3717 | E.1. Version 2 client hello | |
3718 | ||
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. | |
3722 | ||
3723 | uint8 V2CipherSpec[3]; | |
3724 | ||
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; | |
3735 | ||
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). | |
3739 | ||
3740 | version | |
3741 | The highest version of the protocol supported by the client | |
3742 | (equals ProtocolVersion.version, see Appendix A.1). | |
3743 | ||
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). | |
3748 | ||
3749 | ||
3750 | ||
3751 | ||
3752 | ||
3753 | ||
3754 | Dierks & Allen Standards Track [Page 67] | |
3755 | \f | |
3756 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3757 | ||
3758 | ||
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. | |
3763 | ||
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. | |
3767 | ||
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. | |
3772 | ||
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. | |
3776 | ||
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. | |
3786 | ||
3787 | Note: Requests to resume a TLS session should use a TLS client hello. | |
3788 | ||
3789 | E.2. Avoiding man-in-the-middle version rollback | |
3790 | ||
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. | |
3794 | ||
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. | |
3803 | ||
3804 | ||
3805 | ||
3806 | ||
3807 | ||
3808 | ||
3809 | ||
3810 | Dierks & Allen Standards Track [Page 68] | |
3811 | \f | |
3812 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3813 | ||
3814 | ||
3815 | F. Security analysis | |
3816 | ||
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. | |
3826 | ||
3827 | F.1. Handshake protocol | |
3828 | ||
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. | |
3834 | ||
3835 | F.1.1. Authentication and key exchange | |
3836 | ||
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. | |
3848 | ||
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. | |
3857 | ||
3858 | F.1.1.1. Anonymous key exchange | |
3859 | ||
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 | |
3863 | ||
3864 | ||
3865 | ||
3866 | Dierks & Allen Standards Track [Page 69] | |
3867 | \f | |
3868 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3869 | ||
3870 | ||
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). | |
3876 | ||
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). | |
3882 | ||
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. | |
3889 | ||
3890 | F.1.1.2. RSA key exchange and authentication | |
3891 | ||
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. | |
3900 | ||
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. | |
3904 | ||
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. | |
3910 | ||
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. | |
3917 | ||
3918 | ||
3919 | ||
3920 | ||
3921 | ||
3922 | Dierks & Allen Standards Track [Page 70] | |
3923 | \f | |
3924 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3925 | ||
3926 | ||
3927 | F.1.1.3. Diffie-Hellman key exchange with authentication | |
3928 | ||
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. | |
3937 | ||
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. | |
3947 | ||
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. | |
3952 | ||
3953 | F.1.2. Version rollback attacks | |
3954 | ||
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. | |
3959 | ||
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. | |
3972 | ||
3973 | ||
3974 | ||
3975 | ||
3976 | ||
3977 | ||
3978 | Dierks & Allen Standards Track [Page 71] | |
3979 | \f | |
3980 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
3981 | ||
3982 | ||
3983 | F.1.3. Detecting attacks against the handshake protocol | |
3984 | ||
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. | |
3990 | ||
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. | |
3997 | ||
3998 | F.1.4. Resuming sessions | |
3999 | ||
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). | |
4009 | ||
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. | |
4019 | ||
4020 | F.1.5. MD5 and SHA | |
4021 | ||
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. | |
4025 | ||
4026 | F.2. Protecting application data | |
4027 | ||
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. | |
4031 | ||
4032 | ||
4033 | ||
4034 | Dierks & Allen Standards Track [Page 72] | |
4035 | \f | |
4036 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
4037 | ||
4038 | ||
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. | |
4051 | ||
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. | |
4057 | ||
4058 | Note: MAC secrets may be larger than encryption keys, so messages can | |
4059 | remain tamper resistant even if encryption keys are broken. | |
4060 | ||
4061 | F.3. Final notes | |
4062 | ||
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. | |
4066 | ||
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. | |
4074 | ||
4075 | ||
4076 | ||
4077 | ||
4078 | ||
4079 | ||
4080 | ||
4081 | ||
4082 | ||
4083 | ||
4084 | ||
4085 | ||
4086 | ||
4087 | ||
4088 | ||
4089 | ||
4090 | Dierks & Allen Standards Track [Page 73] | |
4091 | \f | |
4092 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
4093 | ||
4094 | ||
4095 | G. Patent Statement | |
4096 | ||
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. | |
4104 | ||
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: | |
4108 | ||
4109 | Cryptographic Communications System and Method ("RSA"), No. | |
4110 | 4,405,829 | |
4111 | ||
4112 | Netscape Communications Corporation has been issued the following | |
4113 | patent in the United States: | |
4114 | ||
4115 | Secure Socket Layer Application Program Apparatus And Method | |
4116 | ("SSL"), No. 5,657,390 | |
4117 | ||
4118 | Netscape Communications has issued the following statement: | |
4119 | ||
4120 | Intellectual Property Rights | |
4121 | ||
4122 | Secure Sockets Layer | |
4123 | ||
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: | |
4131 | ||
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. | |
4135 | ||
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. | |
4142 | ||
4143 | ||
4144 | ||
4145 | ||
4146 | Dierks & Allen Standards Track [Page 74] | |
4147 | \f | |
4148 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
4149 | ||
4150 | ||
4151 | What are "Patent Claims": | |
4152 | ||
4153 | Patent claims are claims in an issued foreign or domestic patent | |
4154 | that: | |
4155 | ||
4156 | 1) must be infringed in order to implement methods or build | |
4157 | products according to the IETF TLS specification; or | |
4158 | ||
4159 | 2) patent claims which require the elements of the SSL patent | |
4160 | claims and/or their equivalents to be infringed. | |
4161 | ||
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. | |
4170 | ||
4171 | Security Considerations | |
4172 | ||
4173 | Security issues are discussed throughout this memo. | |
4174 | ||
4175 | References | |
4176 | ||
4177 | [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," | |
4178 | IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. | |
4179 | ||
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. | |
4184 | ||
4185 | [DES] ANSI X3.106, "American National Standard for Information | |
4186 | Systems-Data Link Encryption," American National Standards | |
4187 | Institute, 1983. | |
4188 | ||
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. | |
4192 | ||
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. | |
4196 | ||
4197 | [FTP] Postel J., and J. Reynolds, "File Transfer Protocol", STD 9, | |
4198 | RFC 959, October 1985. | |
4199 | ||
4200 | ||
4201 | ||
4202 | Dierks & Allen Standards Track [Page 75] | |
4203 | \f | |
4204 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
4205 | ||
4206 | ||
4207 | [HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext | |
4208 | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | |
4209 | ||
4210 | [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |
4211 | Hashing for Message Authentication," RFC 2104, February | |
4212 | 1997. | |
4213 | ||
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. | |
4217 | ||
4218 | [MD2] Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319, | |
4219 | April 1992. | |
4220 | ||
4221 | [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, | |
4222 | April 1992. | |
4223 | ||
4224 | [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard," | |
4225 | version 1.5, November 1993. | |
4226 | ||
4227 | [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax | |
4228 | Standard," version 1.5, November 1993. | |
4229 | ||
4230 | [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax | |
4231 | Standard," version 1.5, November 1993. | |
4232 | ||
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. | |
4236 | ||
4237 | [RC2] Rivest, R., "A Description of the RC2(r) Encryption | |
4238 | Algorithm", RFC 2268, January 1998. | |
4239 | ||
4240 | [RC4] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption | |
4241 | Algorithm, Work in Progress. | |
4242 | ||
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. | |
4247 | ||
4248 | [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 | |
4249 | ||
4250 | [SCH] B. Schneier. Applied Cryptography: Protocols, Algorithms, | |
4251 | and Source Code in C, Published by John Wiley & Sons, Inc. | |
4252 | 1994. | |
4253 | ||
4254 | ||
4255 | ||
4256 | ||
4257 | ||
4258 | Dierks & Allen Standards Track [Page 76] | |
4259 | \f | |
4260 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
4261 | ||
4262 | ||
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. | |
4266 | ||
4267 | [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications | |
4268 | Corp., Feb 9, 1995. | |
4269 | ||
4270 | [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", | |
4271 | Netscape Communications Corp., Nov 18, 1996. | |
4272 | ||
4273 | [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, | |
4274 | September 1981. | |
4275 | ||
4276 | [TEL] Postel J., and J. Reynolds, "Telnet Protocol | |
4277 | Specifications", STD 8, RFC 854, May 1993. | |
4278 | ||
4279 | [TEL] Postel J., and J. Reynolds, "Telnet Option Specifications", | |
4280 | STD 8, RFC 855, May 1993. | |
4281 | ||
4282 | [X509] CCITT. Recommendation X.509: "The Directory - Authentication | |
4283 | Framework". 1988. | |
4284 | ||
4285 | [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External | |
4286 | Data Representation Standard, August 1995. | |
4287 | ||
4288 | Credits | |
4289 | ||
4290 | Win Treese | |
4291 | Open Market | |
4292 | ||
4293 | EMail: treese@openmarket.com | |
4294 | ||
4295 | ||
4296 | Editors | |
4297 | ||
4298 | Christopher Allen Tim Dierks | |
4299 | Certicom Certicom | |
4300 | ||
4301 | EMail: callen@certicom.com EMail: tdierks@certicom.com | |
4302 | ||
4303 | ||
4304 | Authors' Addresses | |
4305 | ||
4306 | Tim Dierks Philip L. Karlton | |
4307 | Certicom Netscape Communications | |
4308 | ||
4309 | EMail: tdierks@certicom.com | |
4310 | ||
4311 | ||
4312 | ||
4313 | ||
4314 | Dierks & Allen Standards Track [Page 77] | |
4315 | \f | |
4316 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
4317 | ||
4318 | ||
4319 | Alan O. Freier Paul C. Kocher | |
4320 | Netscape Communications Independent Consultant | |
4321 | ||
4322 | EMail: freier@netscape.com EMail: pck@netcom.com | |
4323 | ||
4324 | ||
4325 | Other contributors | |
4326 | ||
4327 | Martin Abadi Robert Relyea | |
4328 | Digital Equipment Corporation Netscape Communications | |
4329 | ||
4330 | EMail: ma@pa.dec.com EMail: relyea@netscape.com | |
4331 | ||
4332 | Ran Canetti Jim Roskind | |
4333 | IBM Watson Research Center Netscape Communications | |
4334 | ||
4335 | EMail: canetti@watson.ibm.com EMail: jar@netscape.com | |
4336 | ||
4337 | ||
4338 | Taher Elgamal Micheal J. Sabin, Ph. D. | |
4339 | Securify Consulting Engineer | |
4340 | ||
4341 | EMail: elgamal@securify.com EMail: msabin@netcom.com | |
4342 | ||
4343 | ||
4344 | Anil R. Gangolli Dan Simon | |
4345 | Structured Arts Computing Corp. Microsoft | |
4346 | ||
4347 | EMail: gangolli@structuredarts.com EMail: dansimon@microsoft.com | |
4348 | ||
4349 | ||
4350 | Kipp E.B. Hickman Tom Weinstein | |
4351 | Netscape Communications Netscape Communications | |
4352 | ||
4353 | EMail: kipp@netscape.com EMail: tomw@netscape.com | |
4354 | ||
4355 | ||
4356 | Hugo Krawczyk | |
4357 | IBM Watson Research Center | |
4358 | ||
4359 | EMail: hugo@watson.ibm.com | |
4360 | ||
4361 | Comments | |
4362 | ||
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/>. | |
4367 | ||
4368 | ||
4369 | ||
4370 | Dierks & Allen Standards Track [Page 78] | |
4371 | \f | |
4372 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
4373 | ||
4374 | ||
4375 | Archives of the list can be found at: | |
4376 | <http://www.imc.org/ietf-tls/mail-archive/> | |
4377 | ||
4378 | ||
4379 | ||
4380 | ||
4381 | ||
4382 | ||
4383 | ||
4384 | ||
4385 | ||
4386 | ||
4387 | ||
4388 | ||
4389 | ||
4390 | ||
4391 | ||
4392 | ||
4393 | ||
4394 | ||
4395 | ||
4396 | ||
4397 | ||
4398 | ||
4399 | ||
4400 | ||
4401 | ||
4402 | ||
4403 | ||
4404 | ||
4405 | ||
4406 | ||
4407 | ||
4408 | ||
4409 | ||
4410 | ||
4411 | ||
4412 | ||
4413 | ||
4414 | ||
4415 | ||
4416 | ||
4417 | ||
4418 | ||
4419 | ||
4420 | ||
4421 | ||
4422 | ||
4423 | ||
4424 | ||
4425 | ||
4426 | Dierks & Allen Standards Track [Page 79] | |
4427 | \f | |
4428 | RFC 2246 The TLS Protocol Version 1.0 January 1999 | |
4429 | ||
4430 | ||
4431 | Full Copyright Statement | |
4432 | ||
4433 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
4434 | ||
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. | |
4448 | ||
4449 | The limited permissions granted above are perpetual and will not be | |
4450 | revoked by the Internet Society or its successors or assigns. | |
4451 | ||
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. | |
4458 | ||
4459 | ||
4460 | ||
4461 | ||
4462 | ||
4463 | ||
4464 | ||
4465 | ||
4466 | ||
4467 | ||
4468 | ||
4469 | ||
4470 | ||
4471 | ||
4472 | ||
4473 | ||
4474 | ||
4475 | ||
4476 | ||
4477 | ||
4478 | ||
4479 | ||
4480 | ||
4481 | ||
4482 | Dierks & Allen Standards Track [Page 80] | |
4483 | \f |