idnits 2.17.1 draft-ietf-tls-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2664 has weird spacing: '... Type rtab...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 26, 1996) is 10013 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TCP' is mentioned on line 3228, but not defined == Missing Reference: 'RC4' is mentioned on line 146, but not defined -- Looks like a reference, but probably isn't: '0' on line 269 -- Looks like a reference, but probably isn't: '1' on line 269 -- Looks like a reference, but probably isn't: '3' on line 2821 -- Looks like a reference, but probably isn't: '9' on line 305 -- Looks like a reference, but probably isn't: '2' on line 2214 -- Looks like a reference, but probably isn't: '4' on line 339 -- Looks like a reference, but probably isn't: '8' on line 340 -- Looks like a reference, but probably isn't: '10' on line 431 -- Looks like a reference, but probably isn't: '20' on line 2328 -- Looks like a reference, but probably isn't: '48' on line 2436 -- Looks like a reference, but probably isn't: '32' on line 2438 == Missing Reference: 'X509' is mentioned on line 1764, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1239, but not defined -- Looks like a reference, but probably isn't: '28' on line 2209 -- Looks like a reference, but probably isn't: '16' on line 2327 -- Looks like a reference, but probably isn't: '46' on line 2303 == Missing Reference: 'IP' is mentioned on line 2079, but not defined -- Looks like a reference, but probably isn't: '7' on line 2532 == Missing Reference: 'SSL-2' is mentioned on line 2781, but not defined == Unused Reference: 'DH1' is defined on line 3175, but no explicit reference was found in the text == Unused Reference: '3DES' is defined on line 3179, but no explicit reference was found in the text == Unused Reference: 'FTP' is defined on line 3190, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 3193, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 3196, but no explicit reference was found in the text == Unused Reference: 'KRAW' is defined on line 3200, but no explicit reference was found in the text == Unused Reference: 'MD2' is defined on line 3203, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 3206, but no explicit reference was found in the text == Unused Reference: 'TEL' is defined on line 3231, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL3' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH1' -- Possible downref: Non-RFC (?) normative reference: ref. '3DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDEA' -- Possible downref: Non-RFC (?) normative reference: ref. 'KRAW' ** Obsolete normative reference: RFC 1319 (ref. 'MD2') (Obsoleted by RFC 6149) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS6' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS7' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSADSI' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' ** Obsolete normative reference: RFC 1832 (ref. 'XDR') (Obsoleted by RFC 4506) Summary: 12 errors (**), 0 flaws (~~), 17 warnings (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Transport Layer Security Working Group Alan O. Freier 2 INTERNET-DRAFT Netscape Communications 3 Expires May 31, 1997 Philip Karlton 4 Netscape Communications 5 Paul C. Kocher 6 Independent Consultant 7 Tim Dierks 8 Consensus Development 9 November 26, 1996 11 The TLS Protocol 12 Version 1.0 14 16 Status of this memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet- Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or made obsolete by other 25 documents at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as work in progress. 28 To learn the current status of any Internet-Draft, please check the 29 1id-abstracts.txt listing contained in the Internet Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net 31 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 32 Rim). 34 Abstract 36 This document specifies Version 1.0 of the Transport Layer Security 37 (TLS) protocol, which is at this stage is strictly based on the 38 Secure Sockets Layer (SSL) version 3.0 protocol, and is to serve as 39 a basis for future discussions. The TLS protocol provides 40 communications privacy over the Internet. The protocol allows 41 client/server applications to communicate in a way that is designed 42 to prevent eavesdropping, tampering, or message forgery. 44 Table of Contents 45 Status of this memo 1 46 Abstract 1 47 Table of Contents 2 48 1. Introduction 4 49 2. Goals 4 50 3. Goals of this document 5 51 4. Presentation language 6 52 4.1 Basic block size 6 53 4.2 Miscellaneous 6 54 4.3 Vectors 6 55 4.4 Numbers 7 56 4.5 Enumerateds 7 57 4.6 Constructed types 8 58 4.6.1 Variants 9 59 4.7 Cryptographic attributes 10 60 4.8 Constants 11 61 5. The TLS Record Protocol 11 62 5.1 Connection states 11 63 5.2 Record layer 14 64 5.2.1 Fragmentation 14 65 5.2.2 Record compression and decompression 15 66 5.2.3 Record payload protection 16 67 5.2.3.1 Null or standard stream cipher 16 68 5.2.3.2 CBC block cipher 17 69 5.3 Key calculation 18 70 5.3.1 Export key generation example 19 71 6. The TLS Handshake Protocol 20 72 6.1 Change cipher spec protocol 21 73 6.2 Alert protocol 21 74 6.2.1 Closure alerts 22 75 6.2.2 Error alerts 22 76 6.3 Handshake protocol overview 23 77 6.4 Handshake protocol 26 78 6.4.1 Hello messages 27 79 6.4.1.1 Hello request 27 80 6.4.1.2 Client hello 28 81 6.4.1.3 Server hello 30 82 6.4.2 Server certificate 31 83 6.4.3 Server key exchange message 32 84 6.4.4 Certificate request 35 85 6.4.5 Server hello done 36 86 6.4.6 Client certificate 36 87 6.4.7 Client key exchange message 36 88 6.4.7.1 RSA encrypted premaster secret message 37 89 6.4.7.2 Client Diffie-Hellman public value 38 90 6.4.8 Certificate verify 38 91 6.4.9 Finished 39 92 7. Cryptographic computations 40 93 7.1 Computing the master secret 41 94 7.1.1 RSA 41 95 7.1.2 Diffie-Hellman 41 96 8. Application data protocol 41 97 A. Protocol constant values 42 98 A.1 Reserved port assignments 42 99 A.1.1 Record layer 42 100 A.2 Change cipher specs message 43 101 A.3 Alert messages 43 102 A.4 Handshake protocol 44 103 A.4.1 Hello messages 44 104 A.4.2 Server authentication and key exchange messages 45 105 A.5 Client authentication and key exchange messages 46 106 A.5.1 Handshake finalization message 47 107 A.6 The CipherSuite 47 108 A.7 The Security Parameters 48 109 B. Glossary 49 110 C. CipherSuite definitions 52 111 D. Implementation Notes 54 112 D.1 Temporary RSA keys 54 113 D.2 Random Number Generation and Seeding 55 114 D.3 Certificates and authentication 55 115 D.4 CipherSuites 55 116 E. Version 2.0 Backward Compatibility 56 117 E.1 Version 2 client hello 56 118 E.2 Avoiding man-in-the-middle version rollback 58 119 F. Security analysis 58 120 F.1 Handshake protocol 58 121 F.1.1 Authentication and key exchange 58 122 F.1.1.1 Anonymous key exchange 59 123 F.1.1.2 RSA key exchange and authentication 59 124 F.1.1.3 Diffie-Hellman key exchange with authentication 60 125 F.1.2 Version rollback attacks 60 126 F.1.3 Detecting attacks against the handshake protocol 61 127 F.1.4 Resuming sessions 61 128 F.1.5 MD5 and SHA 62 129 F.2 Protecting application data 62 130 F.3 Final notes 62 131 G. Patent Statement 63 132 References 63 133 Credits 65 135 1. Introduction 137 The primary goal of the TLS Protocol is to provide privacy and 138 reliability between two communicating applications. The protocol is 139 composed of two layers: the TLS Record Protocol and the TLS 140 Handshake Protocol. At the lowest level, layered on top of some 141 reliable transport protocol (e.g., TCP[TCP]), is the TLS Record 142 Protocol. The TLS Record Protocol provides connection security that 143 has two basic properties: 145 - The connection is private. Symmetric cryptography is used for 146 data encryption (e.g., DES[DES], RC4[RC4], etc.) The keys for 147 this symmetric encryption are generated uniquely for each 148 connection and are based on a secret negotiated by another 149 protocol (such as the TLS Handshake Protocol). The Record 150 Protocol can also be used with no encryption. 152 - The connection is reliable. Message transport includes a 153 message integrity check using a keyed MAC. Secure hash 154 functions (e.g., SHA, MD5, etc.) are used for MAC 155 computations. The Record Protocol can operate without a MAC, 156 but is generally only used in this mode while another protocol 157 is using the Record Protocol as a transport for negotiating 158 security parameters. 160 The TLS Record Protocol is used for encapsulation of various higher 161 level protocols. One such encapsulated protocol, the TLS Handshake 162 Protocol, allows the server and client to authenticate each other 163 and to negotiate an encryption algorithm and cryptographic keys 164 before the application protocol transmits or receives its first byte 165 of data. The TLS Handshake Protocol provides connection security 166 that has three basic properties: 168 - The peer's identity can be authenticated using asymmetric, or 169 public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.). 170 This authentication can be made optional, but is generally 171 required for at least one of the peers. 173 - The negotiation of a shared secret is secure: the negotiated 174 secret is unavailable to eavesdroppers, and for all 175 authenticated connections, cannot be obtained by an attacker 176 who can place himself in the middle of the connection. 178 - The negotiation is reliable: no attacker can modify the 179 negotiation communication without being detected by the peers. 181 One advantage of TLS is that it is application protocol independent. 182 A higher level protocol can layer on top of the TLS Protocol 183 transparently. 185 2. Goals 187 The goals of TLS Protocol, in order of their priority, are: 189 1. Cryptographic security 190 TLS should be used to establish a secure connection between 191 two parties. 193 2. Interoperability 194 Independent programmers should be able to develop applications 195 utilizing TLS that will then be able to successfully 196 exchange cryptographic parameters without knowledge of one 197 another's code. 199 Note: 200 It is not the case that all instances of TLS (even in the same 201 application domain) will be able to successfully connect. For 202 instance, if the server supports a particular hardware token, 203 and the client does not have access to such a token, then the 204 connection will not succeed. 206 3. Extensibility 207 TLS seeks to provide a framework into which new public key and 208 bulk encryption methods can be incorporated as necessary. This 209 will also accomplish two sub-goals: to prevent the need to 210 create a new protocol (and risking the introduction of 211 possible new weaknesses) and to avoid the need to implement an 212 entire new security library. 214 4. Relative efficiency 215 Cryptographic operations tend to be highly CPU intensive, 216 particularly public key operations. For this reason, the TLS 217 protocol has incorporated an optional session caching scheme 218 to reduce the number of connections that need to be 219 established from scratch. Additionally, care has been taken to 220 reduce network activity. 222 3. Goals of this document 224 This document describing the TLS Protocol Version 1.0 Specification 225 is strictly based on Secure Sockets Layer (SSL) Version 3.0 [SSL3], 226 incorporating only errata as well as several clarifications to the 227 SSL 3.0 draft, but will have no substantive changes to the "bits on 228 the wire" of the SSL 3.0 protocol. This draft will be the starting 229 point for future discussions, and from its base the TLS working 230 group will work together to agree on what changes need to be made. 232 Note that in all cases TLS has been substituted for the word SSL in 233 the presentation language examples. In no way is the presentation 234 language of this document any different then with SSL 3.0. This was 235 done this way to ease the transition to TLS. 237 This document is intended primarily for readers who will be 238 implementing the protocol and those doing cryptographic analysis of 239 it. The spec has been written with this in mind, and it is intended 240 to reflect the needs of those two groups. For that reason, many of 241 the algorithm-dependent data structures and rules are included in 242 the body of the text (as opposed to in an Appendix), providing 243 easier access to them. 245 This document is not intended to supply any details of service 246 definition nor interface definition, although it does cover select 247 areas of policy as they are required for the maintenance of solid 248 security. 250 4. Presentation language 252 This document deals with the formatting of data in an external 253 representation. The following very basic and somewhat casually 254 defined presentation syntax will be used. The syntax draws from 255 several sources in its structure. Although it resembles the 256 programming language "C" in its syntax and XDR [XDR] in both its 257 syntax and intent, it would be risky to draw too many parallels. The 258 purpose of this presentation language is to document TLS only, not 259 to have general application beyond that particular goal. 261 4.1 Basic block size 263 The representation of all data items is explicitly specified. The 264 basic data block size is one byte (i.e. 8 bits). Multiple byte data 265 items are concatenations of bytes, from left to right, from top to 266 bottom. From the bytestream a multi-byte item (a numeric in the 267 example) is formed (using C notation) by: 269 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ... 270 | byte[n-1]; 272 This byte ordering for multi-byte values is the commonplace network 273 byte order or big endian format. 275 4.2 Miscellaneous 277 Comments begin with "/*" and end with "*/". 279 Optional components are denoted by enclosing them in "[[ ]]" double 280 brackets. 282 Single byte entities containing uninterpreted data are of type 283 opaque. 285 4.3 Vectors 287 A vector (single dimensioned array) is a stream of homogeneous data 288 elements. The size of the vector may be specified at documentation 289 time or left unspecified until runtime. In either case the length 290 declares the number of bytes, not the number of elements, in the 291 vector. The syntax for specifying a new type T' that is a fixed 292 length vector of type T is 294 T T'[n]; 296 Here T' occupies n bytes in the data stream, where n is a multiple 297 of the size of T. The length of the vector is not included in the 298 encoded stream. 300 In the following example, Datum is defined to be three consecutive 301 bytes that the protocol does not interpret, while Data is three 302 consecutive Datum, consuming a total of nine bytes. 304 opaque Datum[3]; /* three uninterpreted bytes */ 305 Datum Data[9]; /* 3 consecutive 3 byte vectors */ 307 Variable length vectors are defined by specifying a subrange of 308 legal lengths, inclusively, using the notation . 309 When encoded, the actual length precedes the vector's contents in 310 the byte stream. The length will be in the form of a number 311 consuming as many bytes as required to hold the vector's specified 312 maximum (ceiling) length. A variable length vector with an actual 313 length field of zero is referred to as an empty vector. 315 T T'; 317 In the following example, mandatory is a vector that must contain 318 between 300 and 400 bytes of type opaque. It can never be empty. The 319 actual length field consumes two bytes, a uint16, sufficient to 320 represent the value 400 (see Section 4.4). On the other hand, longer 321 can represent up to 800 bytes of data, or 400 uint16 elements, and 322 it may be empty. Its encoding will include a two byte actual length 323 field prepended to the vector. 325 opaque mandatory<300..400>; 326 /* length field is 2 bytes, cannot be empty */ 327 uint16 longer<0..800>; 328 /* zero to 400 16-bit unsigned integers */ 330 4.4 Numbers 332 The basic numeric data type is an unsigned byte (uint8). All larger 333 numeric data types are formed from fixed length series of bytes 334 concatenated as described in Section 4.1 and are also unsigned. The 335 following numeric types are predefined. 337 uint8 uint16[2]; 338 uint8 uint24[3]; 339 uint8 uint32[4]; 340 uint8 uint64[8]; 342 4.5 Enumerateds 344 An additional sparse data type is available called enum. A field of 345 type enum can only assume the values declared in the definition. 346 Each definition is a different type. Only enumerateds of the same 347 type may be assigned or compared. Every element of an enumerated 348 must be assigned a value, as demonstrated in the following example. 349 Since the elements of the enumerated are not ordered, they can be 350 assigned any unique value, in any order. 352 enum { e1(v1), e2(v2), ... , en(vn), [[(n)]] } Te; 354 Enumerateds occupy as much space in the byte stream as would its 355 maximal defined ordinal value. The following definition would cause 356 one byte to be used to carry fields of type Color. 358 enum { red(3), blue(5), white(7) } Color; 360 One may optionally specify a value without its associated tag to 361 force the width definition without defining a superfluous element. 362 In the following example, Taste will consume two bytes in the data 363 stream but can only assume the values 1, 2 or 4. 365 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 367 The names of the elements of an enumeration are scoped within the 368 defined type. In the first example, a fully qualified reference to 369 the second element of the enumeration would be Color.blue. Such 370 qualification is not required if the target of the assignment is 371 well specified. 373 Color color = Color.blue; /* overspecified, legal */ 374 Color color = blue; /* correct, type implicit */ 376 For enumerateds that are never converted to external representation, 377 the numerical information may be omitted. 379 enum { low, medium, high } Amount; 381 4.6 Constructed types 383 Structure types may be constructed from primitive types for 384 convenience. Each specification declares a new, unique type. The 385 syntax for definition is much like that of C. 387 struct { 388 T1 f1; 389 T2 f2; 390 ... 391 Tn fn; 392 } [[T]]; 394 The fields within a structure may be qualified using the type's name 395 using a syntax much like that available for enumerateds. For 396 example, T.f2 refers to the second field of the previous 397 declaration. Structure definitions may be embedded. 399 4.6.1 Variants 401 Defined structures may have variants based on some knowledge that is 402 available within the environment. The selector must be an enumerated 403 type that defines the possible variants the structure defines. There 404 must be a case arm for every element of the enumeration declared in 405 the select. The body of the variant structure may be given a label 406 for reference. The mechanism by which the variant is selected at 407 runtime is not prescribed by the presentation language. 409 struct { 410 T1 f1; 411 T2 f2; 412 .... 413 Tn fn; 414 select (E) { 415 case e1: Te1; 416 case e2: Te2; 417 .... 418 case en: Ten; 419 } [[fv]]; 420 } [[Tv]]; 422 For example 424 enum { apple, orange } VariantTag; 425 struct { 426 uint16 number; 427 opaque string<0..10>; /* variable length */ 428 } V1; 429 struct { 430 uint32 number; 431 opaque string[10]; /* fixed length */ 432 } V2; 433 struct { 434 select (VariantTag) { /* value of selector is implicit */ 435 case apple: V1; /* VariantBody, tag = apple */ 436 case orange: V2; /* VariantBody, tag = orange */ 437 } variant_body; /* optional label on variant */ 438 } VariantRecord; 440 Variant structures may be qualified (narrowed) by specifying a value 441 for the selector prior to the type. For example, a 443 orange VariantRecord 445 is a narrowed type of a VariantRecord containing a variant_body of 446 type V2. 448 4.7 Cryptographic attributes 450 The four cryptographic operations digital signing, stream cipher 451 encryption, block cipher encryption, and public key encryption are 452 designated digitally-signed, stream-ciphered, block-ciphered, and 453 public-key-encrypted, respectively. A field's cryptographic 454 processing is specified by prepending an appropriate key word 455 designation before the field's type specification. Cryptographic 456 keys are implied by the current session state (see Section 5.1). 458 In digital signing, one-way hash functions are used as input for a 459 signing algorithm. In RSA signing, a 36-byte structure of two hashes 460 (one SHA and one MD5) is signed (encrypted with the private key). In 461 DSS, the 20 bytes of the SHA hash are run directly through the 462 Digital Signing Algorithm with no additional hashing. A 463 digitally-signed element is encoded as an opaque vector <0..2^16-1>, 464 where the length is specified by the signing algorithm and key. 466 In stream cipher encryption, the plaintext is exclusive-ORed with an 467 identical amount of output generated from a cryptographically-secure 468 keyed pseudorandom number generator. 470 In block cipher encryption, every block of plaintext encrypts to a 471 block of ciphertext. All block cipher encryption is done in CBC 472 (Cipher Block Chaining) mode, and all items which are block-ciphered 473 will be an exact multiple of the cipher block length. 475 In public key encryption, a public key algorithm is used to encrypt 476 data in such a way that it can be decrypted only with the matching 477 private key. A public-key-encrypted element is encoded as an opaque 478 vector <0..2^16-1>, where the length is specified by the signing 479 algorithm and key. 481 In the following example: 483 stream-ciphered struct { 484 uint8 field1; 485 uint8 field2; 486 digitally-signed opaque hash[20]; 487 } UserType; 489 The contents of hash are used as input for the signing algorithm, 490 then the entire structure is encrypted with a stream cipher. The 491 length of this structure, in bytes would be equal to 2 bytes for 492 field1 and field2, plus two bytes for the length of the signature, 493 plus the length of the output of the signing algorithm. This is 494 known due to the fact that the algorithm and key used for the 495 signing are known prior to encoding or decoding this structure. 497 4.8 Constants 499 Typed constants can be defined for purposes of specification by 500 declaring a symbol of the desired type and assigning values to it. 501 Under-specified types (opaque, variable length vectors, and 502 structures that contain opaque) cannot be assigned values. No fields 503 of a multi-element structure or vector may be elided. 505 For example, 507 struct { 508 uint8 f1; 509 uint8 f2; 510 } Example1; 512 Example1 513 ex1 = {1, 4};/* assigns f1 = 1, f2 = 4 */ 515 5. The TLS Record Protocol 517 The TLS Record Protocol is a layered protocol. At each layer, 518 messages may include fields for length, description, and content. 519 The Record Protocol takes messages to be transmitted, fragments the 520 data into manageable blocks, optionally compresses the data, applies 521 a MAC, encrypts, and transmits the result. Received data is 522 decrypted, verified, decompressed, and reassembled, then delivered 523 to higher level clients. 525 5.1 Connection states 527 An TLS connection state is the operating environment of the TLS 528 Record Protocol. It specifies a compression algorithm, encryption 529 algorithm, and MAC algorithm. In addition, the parameters for these 530 algorithms are known: the MAC secret and the bulk encryption keys 531 and IVs for the connection in both the read and the write 532 directions. Logically, there are always four connection states 533 outstanding: the current read and write states, and the pending read 534 and write states. All records are processed under the current read 535 and write states. The security parameters for the pending states can 536 be set by the TLS Handshake Protocol, and the Handshake Protocol can 537 selectively make either of the pending states current, in which case 538 the appropriate current state is disposed of and replaced with the 539 pending state; the pending state is then reinitialized to an empty 540 state. It is illegal to make a state which has not been initialized 541 with security parameters a current state (although those security 542 parameters may specify that no compression, encryption or MAC 543 algorithm is to be used). The initial current state always specifies 544 that no encryption, compression, or MAC will be used. 546 The security parameters for a TLS Connection read and write state 547 are set by providing the following values: 549 connection end 550 Whether this entity is considered the "client" or the "server" 551 in this connection. 553 bulk encryption algorithm 554 An algorithm to be used for bulk encryption. This 555 specification includes the key size of this algorithm, how 556 much of that key is secret, whether it is a block or stream 557 cipher, the block size of the cipher (if appropriate), and 558 whether it is considered an "export" cipher. 560 MAC algorithm 561 An algorithm to be used for message authentication. This 562 specification includes the size of the hash to be returned by 563 the MAC algorithm, and a pad size which is to be used when 564 whitening the hash. 566 compression algorithm 567 An algorithm to be used for data compression. This 568 specification must include all information the algorithm 569 requires to do compression. 571 master secret 572 A 48 byte secret shared between the two peers in the 573 connection. 575 client random 576 A 32 byte value provided by the client. 578 server random 579 A 32 byte value provided by the server. 581 These parameters are defined in the presentation language as: 583 enum { null(0), (255) } CompressionMethod; 585 enum { server, client } ConnectionEnd; 587 enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm; 589 enum { stream, block } CipherType; 591 enum { true, false } IsExportable; 593 enum { null, md5, sha } MACAlgorithm; 595 /* The algorithms specified in CompressionMethod, 596 BulkCipherAlgorithm, and MACAlgorithm may be added to. */ 597 struct { 598 ConnectionEnd entity; 599 BulkCipherAlgorithm bulk_cipher_algorithm; 600 CipherType cipher_type; 601 uint8 key_size; 602 uint8 key_material_length; 603 IsExportable is_exportable; 604 MACAlgorithm mac_algorithm; 605 uint8 hash_size; 606 uint8 whitener_length; 607 CompressionMethod compression_algorithm; 608 opaque master_secret[48]; 609 opaque client_random[32]; 610 opaque server_random[32]; 611 } SecurityParameters; 613 The record layer will use the security parameters to generate the 614 following six items: 616 client write MAC secret 617 server write MAC secret 618 client write key 619 server write key 620 client write IV (for block ciphers only) 621 server write IV (for block ciphers only) 623 The client write parameters are used by the server when receiving 624 and processing records and vice-versa. The algorithm used for 625 generating these items from the security parameters is described in 626 section 5.3. 628 Once the security parameters have been set and the keys have been 629 generated, the connection states can be instantiated by making them 630 the current states. These current states must be updated for each 631 record processed. Each connection state includes the following 632 elements: 634 compression state 635 The current state of the compression algorithm. 637 cipher state 638 The current state of the encryption algorithm. This will 639 consist of the scheduled key for that connection. In addition, 640 for block ciphers, this will initially contain the IV for that 641 connection state and be updated to contain the ciphertext of 642 the last block encrypted or decrypted as records are 643 processed. For stream ciphers, this will contain whatever the 644 necessary state information is to allow the stream to continue 645 to encrypt or decrypt data. 647 MAC secret 648 The MAC secret for this connection as generated above. 650 sequence number 651 Each connection state contains a sequence number, which is 652 maintained seperately for read and write states. The sequence 653 number must be set to zero whenever a connection state is made 654 the active state. Sequence numbers are of type uint64 and may 655 not exceed 2^64-1. A sequence number is incremented after each 656 record: specifically, the first record which is transmitted 657 under a particular connection state should use sequence number 658 0. 660 5.2 Record layer 662 The TLS Record Layer receives uninterpreted data from higher layers 663 in non-empty blocks of arbitrary size. 665 5.2.1 Fragmentation 667 The record layer fragments information blocks into TLSPlaintext 668 records of 2^14 bytes or less. Client message boundaries are not 669 preserved in the record layer (i.e., multiple client messages of the 670 same ContentType may be coalesced into a single TLSPlaintext record, 671 or may be fragmented across several records). 673 struct { 674 uint8 major, minor; 675 } ProtocolVersion; 677 enum { 678 change_cipher_spec(20), alert(21), handshake(22), 679 application_data(23), (255) 680 } ContentType; 682 struct { 683 ContentType type; 684 ProtocolVersion version; 685 uint16 length; 686 opaque fragment[TLSPlaintext.length]; 687 } TLSPlaintext; 689 type 690 The higher level protocol used to process the enclosed 691 fragment. 693 version 694 The version of the protocol being employed. This document 695 describes TLS Version 1.0, which uses the version { 3, 0 }, 696 as it is identical to SSL Version 3.0 (See Appendix A.1.1). 698 length 699 The length (in bytes) of the following TLSPlaintext.fragment. 700 The length should not exceed 2^14. 702 fragment 703 The application data. This data is transparent and treated as 704 an independent block to be dealt with by the higher level 705 protocol specified by the type field. 707 Note: 708 Data of different TLS Record layer content types may be 709 interleaved. Application data is generally of lower precedence 710 for transmission than other content types. 712 5.2.2 Record compression and decompression 714 All records are compressed using the compression algorithm defined 715 in the current session state. There is always an active compression 716 algorithm, however initially it is defined as 717 CompressionMethod.null. The compression algorithm translates an 718 TLSPlaintext structure into an TLSCompressed structure. Compression 719 functions are initialized with default state information whenever a 720 connection state is made active. 722 Compression must be lossless and may not increase the content length 723 by more than 1024 bytes. If the decompression function encounters an 724 TLSCompressed.fragment that would decompress to a length in excess 725 of 2^14 bytes, it should report a fatal decompression failure error. 727 struct { 728 ContentType type; /* same as TLSPlaintext.type */ 729 ProtocolVersion version;/* same as TLSPlaintext.version */ 730 uint16 length; 731 opaque fragment[TLSCompressed.length]; 732 } TLSCompressed; 734 length 735 The length (in bytes) of the following TLSCompressed.fragment. 736 The length should not exceed 2^14 + 1024. 738 fragment 739 The compressed form of TLSPlaintext.fragment. 741 Note: 742 A CompressionMethod.null operation is an identity operation; 743 no fields are altered. (See Appendix A.4.1) 745 Implementation note: 746 Decompression functions are responsible for ensuring that 747 messages cannot cause internal buffer overflows. 749 5.2.3 Record payload protection 751 The encryption and MAC functions translate an TLSCompressed 752 structure into an TLSCiphertext. The decryption functions reverse 753 the process. Transmissions also include a sequence number so that 754 missing, altered, or extra messages are detectable. 756 struct { 757 ContentType type; 758 ProtocolVersion version; 759 uint16 length; 760 select (CipherSpec.cipher_type) { 761 case stream: GenericStreamCipher; 762 case block: GenericBlockCipher; 763 } fragment; 764 } TLSCiphertext; 766 type 767 The type field is identical to TLSCompressed.type. 769 version 770 The version field is identical to TLSCompressed.version. 772 length 773 The length (in bytes) of the following TLSCiphertext.fragment. 774 The length may not exceed 2^14 + 2048. 776 fragment 777 The encrypted form of TLSCompressed.fragment, with the MAC. 779 5.2.3.1 Null or standard stream cipher 781 Stream ciphers (including BulkCipherAlgorithm.null - see Appendix 782 A.7) convert TLSCompressed.fragment structures to and from stream 783 TLSCiphertext.fragment structures. 785 stream-ciphered struct { 786 opaque content[TLSCompressed.length]; 787 opaque MAC[CipherSpec.hash_size]; 788 } GenericStreamCipher; 790 The MAC is generated as: 792 hash(MAC_write_secret + pad_2 + 793 hash(MAC_write_secret + pad_1 + seq_num + 794 TLSCompressed.type + TLSCompressed.length + 795 TLSCompressed.fragment)); 797 where "+" denotes concatenation. 799 pad_1 800 The character 0x36 repeated SecurityParameters.whitener_length 801 times. 803 pad_2 804 The character 0x5c repeated SecurityParameters.whitener_length 805 times. 807 seq_num 808 The sequence number for this record. 810 hash 811 The hashing algorithm specified by 812 SecurityParameters.mac_algorithm. 814 Note that the MAC is computed before encryption. The stream cipher 815 encrypts the entire block, including the MAC. For stream ciphers 816 that do not use a synchronization vector (such as RC4), the stream 817 cipher state from the end of one record is simply used on the 818 subsequent packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, 819 encryption consists of the identity operation (i.e., the data is not 820 encrypted and the MAC size is zero implying that no MAC is used). 821 TLSCiphertext.length is TLSCompressed.length plus 822 CipherSpec.hash_size. 824 5.2.3.2 CBC block cipher 826 For block ciphers (such as RC2 or DES), the encryption and MAC 827 functions convert TLSCompressed.fragment structures to and from 828 block TLSCiphertext.fragment structures. 830 block-ciphered struct { 831 opaque content[TLSCompressed.length]; 832 opaque MAC[CipherSpec.hash_size]; 833 uint8 padding[GenericBlockCipher.padding_length]; 834 uint8 padding_length; 835 } GenericBlockCipher; 837 The MAC is generated as described in Section 5.2.3.1. 839 padding 840 Padding that is added to force the length of the plaintext to 841 be a multiple of the block cipher's block length. 843 padding_length 844 The length of the padding must be less than the cipher's block 845 length and may be zero. The padding length should be such that 846 the total size of the GenericBlockCipher structure is a 847 multiple of the cipher's block length. 849 The encrypted data length (TLSCiphertext.length) is one more than 850 the sum of TLSCompressed.length, CipherSpec.hash_size, and 851 padding_length. 853 Note: 854 With CBC block chaining the initialization vector (IV) for the 855 first record is generated with the other keys and secrets when 856 the security parameters are set. The IV for subsequent records 857 is the last ciphertext block from the previous record. 859 5.3 Key calculation 861 The Record Protocol requires an algorithm to generate keys, IVs, and 862 MAC secrets from the security parameters provided by the handshake 863 protocol. 865 The master secret is hashed into a sequence of secure bytes, which 866 are assigned to the MAC secrets, keys, and non-export IVs required 867 by the current connection state (see Appendix A.7). CipherSpecs 868 require a client write MAC secret, a server write MAC secret, a 869 client write key, a server write key, a client write IV, and a 870 server write IV, which are generated from the master secret in that 871 order. Unused values are empty. 873 When generating keys and MAC secrets, the master secret is used as 874 an entropy source, and the random values provide unencrypted salt 875 material and IVs for exportable ciphers. 877 To generate the key material, compute 879 key_block = 880 MD5(master_secret + SHA('A' + SecurityParameters.master_secret + 881 SecurityParameters.server_random + 882 SecurityParameters.client_random)) + 883 MD5(master_secret + SHA('BB' + SecurityParameters.master_secret + 884 SecurityParameters.server_random + 885 SecurityParameters.client_random)) + 886 MD5(master_secret + SHA('CCC' + SecurityParameters.master_secret + 887 SecurityParameters.server_random + 888 SecurityParameters.client_random)) + [...]; 890 until enough output has been generated. Then the key_block is 891 partitioned as follows. 893 client_write_MAC_secret[SecurityParameters.hash_size] 894 server_write_MAC_secret[SecurityParameters.hash_size] 895 client_write_key[SecurityParameters.key_material] 896 server_write_key[SecurityParameters.key_material] 897 client_write_IV[SecurityParameters.IV_size] /* non-export ciphers */ 898 server_write_IV[SecurityParameters.IV_size] /* non-export ciphers */ 900 Any extra key_block material is discarded. 902 Implementation note: 903 The cipher spec which is defined in this document which 904 requires the most material is 3DES_EDE_CBC_SHA: it requires 2 905 x 24 byte keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, 906 for a total of 104 bytes of key material. This will require 907 iterating the key generation algorithm seven times, through 908 'GGGGGGG'. 910 Exportable encryption algorithms (for which CipherSpec.is_exportable 911 is true) require additional processing as follows to derive their 912 final write keys: 914 final_client_write_key = MD5(client_write_key + 915 SecurityParameters.client_random + 916 SecurityParameters.server_random); 917 final_server_write_key = MD5(server_write_key + 918 SecurityParameters.server_random + 919 SecurityParameters.client_random); 921 Note that this implies that exportable algorithms cannot have final 922 write keys larger than the output of MD5 (16 bytes). 924 Exportable encryption algorithms derive their IVs from the random 925 messages: 927 client_write_IV = MD5(SecurityParameters.client_random + 928 SecurityParameters.server_random); 929 server_write_IV = MD5(SecurityParameters.server_random + 930 SecurityParameters.client_random); 932 MD5 outputs are trimmed to the appropriate size by discarding the 933 trailing bytes. (The key or IV is taken from the first bytes of the 934 MD5 output.) 936 5.3.1 Export key generation example 938 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for 939 each of the two encryption keys and 16 bytes for each of the MAC 940 keys, for a total of 42 bytes of key material. MD5 produces 16 bytes 941 of output per call, so three calls to MD5 are required. The MD5 942 outputs are concatenated into a 48-byte key_block with the first MD5 943 call providing bytes zero through 15, the second providing bytes 16 944 through 31, etc. The key_block is partitioned, and the write keys 945 are salted because this is an exportable encryption algorithm. 947 client_write_MAC_secret = key_block[0..15] 948 server_write_MAC_secret = key_block[16..31] 949 client_write_key = key_block[32..36] 950 server_write_key = key_block[37..41] 951 final_client_write_key = MD5(client_write_key + 952 ClientHello.random + 953 ServerHello.random)[0..15]; 954 final_server_write_key = MD5(server_write_key + 955 ServerHello.random + 956 ClientHello.random)[0..15]; 957 client_write_IV = MD5(ClientHello.random + 958 ServerHello.random)[0..7]; 959 server_write_IV = MD5(ServerHello.random + 960 ClientHello.random)[0..7]; 962 6. The TLS Handshake Protocol 964 The TLS Handshake Protocol consists of a suite of three 965 sub-protocols which are used to allow peers to agree upon security 966 parameters for the record layer, authenticate themselves, 967 instantiate negotiated security parameters, and report error 968 conditions to each other. 970 The Handshake Protocol is responsible for negotiating a session, 971 which consists of the following items: 973 session identifier 974 An arbitrary byte sequence chosen by the server to identify an 975 active or resumable session state. 977 peer certificate 978 X509.v3[X509] certificate of the peer. This element of the 979 state may be null. 981 compression method 982 The algorithm used to compress data prior to encryption. 984 cipher spec 985 Specifies the bulk data encryption algorithm (such as null, 986 DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also 987 defines cryptographic attributes such as the hash_size. (See 988 Appendix A.7 for formal definition) 990 master secret 991 48-byte secret shared between the client and server. 993 is resumable 994 A flag indicating whether the session can be used to initiate 995 new connections. 997 These items are then used to create security parameters for use by 998 the Record Layer when protecting application data. Many connections 999 can be instantiated using the same session through the resumption 1000 feature of the TLS Handshake Protocol. 1002 6.1 Change cipher spec protocol 1004 The change cipher spec protocol exists to signal transitions in 1005 ciphering strategies. The protocol consists of a single message, 1006 which is encrypted and compressed under the current (not the 1007 pending) connection state. The message consists of a single byte of 1008 value 1. 1010 struct { 1011 enum { change_cipher_spec(1), (255) } type; 1012 } ChangeCipherSpec; 1014 The change cipher spec message is sent by both the client and server 1015 to notify the receiving party that subsequent records will be 1016 protected under the newly negotiated CipherSpec and keys. Reception 1017 of this message causes the receiver to instruct the Record Layer to 1018 immediately copy the read pending state into the read current state. 1019 Immediately after sending this message, the sender should instruct 1020 the record layer to make the write pending state the write active 1021 state. (See section 5.1.) The change cipher spec message is sent 1022 during the handshake after the security parameters have been agreed 1023 upon, but before the verifying finished message is sent (see section 1024 6.4.9). 1026 6.2 Alert protocol 1028 One of the content types supported by the TLS Record layer is the 1029 alert type. Alert messages convey the severity of the message and a 1030 description of the alert. Alert messages with a level of fatal 1031 result in the immediate termination of the connection. In this case, 1032 other connections corresponding to the session may continue, but the 1033 session identifier must be invalidated, preventing the failed 1034 session from being used to establish new connections. Like other 1035 messages, alert messages are encrypted and compressed, as specified 1036 by the current connection state. 1038 enum { warning(1), fatal(2), (255) } AlertLevel; 1040 enum { 1041 close_notify(0), 1042 unexpected_message(10), 1043 bad_record_mac(20), 1044 decompression_failure(30), 1045 handshake_failure(40), 1046 no_certificate(41), 1047 bad_certificate(42), 1048 unsupported_certificate(43), 1049 certificate_revoked(44), 1050 certificate_expired(45), 1051 certificate_unknown(46), 1052 illegal_parameter (47), 1053 (255) 1054 } AlertDescription; 1056 struct { 1057 AlertLevel level; 1058 AlertDescription description; 1059 } Alert; 1061 6.2.1 Closure alerts 1063 The client and the server must share knowledge that the connection 1064 is ending in order to avoid a truncation attack. Either party may 1065 initiate the exchange of closing messages. 1067 close_notify 1068 This message notifies the recipient that the sender will not 1069 send any more messages on this connection. The session becomes 1070 unresumable if any connection is terminated without proper 1071 close_notify messages with level equal to warning. 1073 Either party may initiate a close by sending a close_notify alert. 1074 Any data received after a closure alert is ignored. 1076 Each party is required to send a close_notify alert before closing 1077 the write side of the connection. It is required that the other 1078 party respond with a close_notify alert of its own and close down 1079 the connection immediately, discarding any pending writes. It is not 1080 required for the initiator of the close to wait for the responding 1081 close_notify alert before closing the read side of the connection. 1083 NB: 1084 It is assumed that closing a connection reliably delivers 1085 pending data before destroying the transport. 1087 6.2.2 Error alerts 1089 Error handling in the TLS Handshake protocol is very simple. When an 1090 error is detected, the detecting party sends a message to the other 1091 party. Upon transmission or receipt of an fatal alert message, both 1092 parties immediately close the connection. Servers and clients are 1093 required to forget any session-identifiers, keys, and secrets 1094 associated with a failed connection. The following error alerts are 1095 defined: 1097 unexpected_message 1098 An inappropriate message was received. This alert is always 1099 fatal and should never be observed in communication between 1100 proper implementations. 1102 bad_record_mac 1103 This alert is returned if a record is received with an 1104 incorrect MAC. This message is always fatal. 1106 decompression_failure 1107 The decompression function received improper input (e.g. data 1108 that would expand to excessive length). This message is always 1109 fatal. 1111 handshake_failure 1112 Reception of a handshake_failure alert message indicates that 1113 the sender was unable to negotiate an acceptable set of 1114 security parameters given the options available. This is a 1115 fatal error. 1117 no_certificate 1118 A no_certificate alert message may be sent in response to a 1119 certification request if no appropriate certificate is 1120 available. 1122 bad_certificate 1123 A certificate was corrupt, contained signatures that did not 1124 verify correctly, etc. 1126 unsupported_certificate 1127 A certificate was of an unsupported type. 1129 certificate_revoked 1130 A certificate was revoked by its signer. 1132 certificate_expired 1133 A certificate has expired or is not currently valid. 1135 certificate_unknown 1136 Some other (unspecified) issue arose in processing the 1137 certificate, rendering it unacceptable. 1139 illegal_parameter 1140 A field in the handshake was out of range or inconsistent with 1141 other fields. This is always fatal. 1143 For all errors where an alert level is not explicitly specified, the 1144 sending party may determine at its discretion whether this is a 1145 fatal error or not; if an alert with a level of warning is received, 1146 the receiving party may decide at its discretion whether to treat 1147 this as a fatal error or not. However, all messages which are 1148 transmitted with a level of fatal must be treated as fatal messages. 1150 6.3 Handshake Protocol overview 1152 The cryptographic parameters of the session state are produced by 1153 the TLS Handshake Protocol, which operates on top of the TLS Record 1154 Layer. When a TLS client and server first start communicating, they 1155 agree on a protocol version, select cryptographic algorithms, 1156 optionally authenticate each other, and use public-key encryption 1157 techniques to generate shared secrets. 1159 The TLS Handshake Protocol has three goals: 1161 - Exchange hello messages to agree on algorithms, exchange 1162 random values, and check for session resumption. 1164 - Exchange the necessary cryptographic parameters to allow 1165 the client and server to agree on a premaster secret. 1167 - Exchange certificates and cryptographic information to 1168 allow the client and server to authenticate themselves. 1170 - Generate a master secret from the premaster secret and 1171 exchanged random values. 1173 - Provide security paramers to the record layer. 1175 - Allow the client and server to verify that their peer has 1176 calculated the same security parameters and that the 1177 handshake occured without tampering by an attacker. 1179 These goals are achieved by the handshake protocol, which can be 1180 summarized as follows: The client sends a client hello message to 1181 which the server must respond with a server hello message, or else a 1182 fatal error will occur and the connection will fail. The client 1183 hello and server hello are used to establish security enhancement 1184 capabilities between client and server. The client hello and server 1185 hello establish the following attributes: Protocol Version, Session 1186 ID, Cipher Suite, and Compression Method. Additionally, two random 1187 values are generated and exchanged: ClientHello.random and 1188 ServerHello.random. 1190 The actual key exchange uses up to four messages: the server 1191 certificate, the server key exchange, the client certificate, and 1192 the client key exchange. New key exchange methods can be created by 1193 specifing a format for these messages and defining the use of the 1194 messages to allow the client and server to agree upon a shared 1195 secret. This secret should be quite long; currently defined key 1196 exchange methods exchange secrets which range from 48 to 128 bytes 1197 in length. 1199 Following the hello messages, the server will send its certificate, 1200 if it is to be authenticated. Additionally, a server key exchange 1201 message may be sent, if it is required (e.g. if their server has no 1202 certificate, or if its certificate is for signing only). If the 1203 server is authenticated, it may request a certificate from the 1204 client, if that is appropriate to the cipher suite selected. Now the 1205 server will send the server hello done message, indicating that the 1206 hello-message phase of the handshake is complete. The server will 1207 then wait for a client response. If the server has sent a 1208 certificate request Message, the client must send either the 1209 certificate message or a no_certificate alert. The client key 1210 exchange message is now sent, and the content of that message will 1211 depend on the public key algorithm selected between the client hello 1212 and the server hello. If the client has sent a certificate with 1213 signing ability, a digitally-signed certificate verify message is 1214 sent to explicitly verify the certificate. 1216 At this point, a change cipher spec message is sent by the client, 1217 and the client copies the pending Cipher Spec into the current 1218 Cipher Spec. The client then immediately sends the finished message 1219 under the new algorithms, keys, and secrets. In response, the server 1220 will send its own change cipher spec message, transfer the pending 1221 to the current Cipher Spec, and send its finished message under the 1222 new Cipher Spec. At this point, the handshake is complete and the 1223 client and server may begin to exchange application layer data. (See 1224 flow chart below.) 1226 Client Server 1228 ClientHello --------> 1229 ServerHello 1230 Certificate* 1231 ServerKeyExchange* 1232 CertificateRequest* 1233 <-------- ServerHelloDone 1234 Certificate* 1235 ClientKeyExchange 1236 CertificateVerify* 1237 [ChangeCipherSpec] 1238 Finished --------> 1239 [ChangeCipherSpec] 1240 <-------- Finished 1241 Application Data <-------> Application Data 1243 * Indicates optional or situation-dependent messages that are not 1244 always sent. 1246 Note: 1247 To help avoid pipeline stalls, ChangeCipherSpec is an 1248 independent TLS Protocol content type, and is not actually an 1249 TLS handshake message. 1251 When the client and server decide to resume a previous session or 1252 duplicate an existing session (instead of negotiating new security 1253 parameters) the message flow is as follows: 1255 The client sends a ClientHello using the Session ID of the session 1256 to be resumed. The server then checks its session cache for a match. 1257 If a match is found, and the server is willing to re-establish the 1258 connection under the specified session state, it will send a 1259 ServerHello with the same Session ID value. At this point, both 1260 client and server must send change cipher spec messages and proceed 1261 directly to finished messages. Once the re-establishment is 1262 complete, the client and server may begin to exchange application 1263 layer data. (See flow chart below.) If a Session ID match is not 1264 found, the server generates a new session ID and the TLS client and 1265 server perform a full handshake. 1267 Client Server 1269 ClientHello --------> 1270 ServerHello 1271 [change cipher spec] 1272 <-------- Finished 1273 change cipher spec 1274 Finished --------> 1275 Application Data <-------> Application Data 1277 The contents and significance of each message will be presented in 1278 detail in the following sections. 1280 6.4 Handshake protocol 1282 The TLS Handshake Protocol is one of the defined higher level 1283 clients of the TLS Record Protocol. This protocol is used to 1284 negotiate the secure attributes of a session. Handshake messages are 1285 supplied to the TLS Record Layer, where they are encapsulated within 1286 one or more TLSPlaintext structures, which are processed and 1287 transmitted as specified by the current active session state. 1289 enum { 1290 hello_request(0), client_hello(1), server_hello(2), 1291 certificate(11), server_key_exchange (12), 1292 certificate_request(13), server_hello_done(14), 1293 certificate_verify(15), client_key_exchange(16), 1294 finished(20), (255) 1295 } HandshakeType; 1297 struct { 1298 HandshakeType msg_type; /* handshake type */ 1299 uint24 length; /* bytes in message */ 1300 select (HandshakeType) { 1301 case hello_request: HelloRequest; 1302 case client_hello: ClientHello; 1303 case server_hello: ServerHello; 1304 case certificate: Certificate; 1305 case server_key_exchange: ServerKeyExchange; 1306 case certificate_request: CertificateRequest; 1307 case server_hello_done: ServerHelloDone; 1308 case certificate_verify: CertificateVerify; 1309 case client_key_exchange: ClientKeyExchange; 1310 case finished: Finished; 1311 } body; 1312 } Handshake; 1314 The handshake protocol messages are presented in the order they must 1315 be sent; sending handshake messages in an unexpected order results 1316 in a fatal error. 1318 6.4.1 Hello messages 1320 The hello phase messages are used to exchange security enhancement 1321 capabilities between the client and server. When a new session 1322 begins, the Record Layer's connection state encryption, hash, and 1323 compression algorithms are initialized to null. The current 1324 connection state is used for renegotiation messages. 1326 6.4.1.1 Hello request 1328 When this message will be sent: 1330 The hello request message may be sent by the server at any time. 1332 Meaning of this message: 1334 Hello request is a simple notification that the client should begin 1335 the negotiation process anew by sending a client hello message when 1336 convenient. This message will be ignored by the client if the client 1337 is currently negotiating a session. This message may be ignored by 1338 the client if it does not wish to renegotiate a session. Since 1339 handshake messages are intended to have transmission precedence over 1340 application data, it is expected that the negotiation will begin 1341 before no more than a few records are received from the client. If 1342 the server sends a hello request but does not recieve a client hello 1343 in response, it may close the connection with a fatal alert. 1345 After sending a hello request, servers should not repeat the request 1346 until the subsequent handshake negotiation is complete. 1348 Structure of this message: 1350 struct { } HelloRequest; 1352 Note: 1353 This message should never be included in the message hashes 1354 which are maintained throughout the handshake and used in the 1355 finished messages and the certificate verify message. 1357 6.4.1.2 Client hello 1359 When this message will be sent: 1361 When a client first connects to a server it is required to send the 1362 client hello as its first message. The client can also send a client 1363 hello in response to a hello request or on its own initiative in 1364 order to renegotiate the security parameters in an existing 1365 connection. 1367 Structure of this message: 1369 The client hello message includes a random structure, which is used 1370 later in the protocol. 1372 struct { 1373 uint32 gmt_unix_time; 1374 opaque random_bytes[28]; 1375 } Random; 1377 gmt_unix_time 1378 The current time and date in standard UNIX 32-bit format 1379 according to the sender's internal clock. Clocks are not 1380 required to be set correctly by the basic TLS Protocol; higher 1381 level or application protocols may define additional 1382 requirements. 1384 random_bytes 1385 28 bytes generated by a secure random number generator. 1387 The client hello message includes a variable length session 1388 identifier. If not empty, the value identifies a session between the 1389 same client and server whose security parameters the client wishes 1390 to reuse. The session identifier may be from an earlier connection, 1391 this connection, or another currently active connection. The second 1392 option is useful if the client only wishes to update the random 1393 structures and derived values of a connection, while the third 1394 option makes it possible to establish several simultaneous 1395 independent secure connections without repeating the full handshake 1396 protocol. The actual contents of the SessionID are defined by the 1397 server. 1399 opaque SessionID<0..32>; 1401 Warning: 1402 Servers must not place confidential information in session 1403 identifiers or let the contents of fake session identifiers 1404 cause any breach of security. 1406 The CipherSuite list, passed from the client to the server in the 1407 client hello message, contains the combinations of cryptographic 1408 algorithms supported by the client in order of the client's 1409 preference (first choice first). Each CipherSuite defines a key 1410 exchange algorithm, a bulk encryption algorithm (including secret 1411 key length) and a MAC algorithm. The server will select a cipher 1412 suite or, if no acceptable choices are presented, return a handshake 1413 failure alert and close the connection. 1415 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1417 The client hello includes a list of compression algorithms supported 1418 by the client, ordered according to the client's preference. 1420 Issue: 1421 Which compression methods to support is under investigation. 1423 enum { null(0), (255) } CompressionMethod; 1425 struct { 1426 ProtocolVersion client_version; 1427 Random random; 1428 SessionID session_id; 1429 CipherSuite cipher_suites<2..2^16-1>; 1430 CompressionMethod compression_methods<1..2^8-1>; 1431 } ClientHello; 1433 client_version 1434 The version of the TLS protocol by which the client wishes to 1435 communicate during this session. This should be the latest 1436 (highest valued) version supported by the client. For this 1437 version of the specification, the version will be 3.0 (See 1438 Appendix E for details about backward compatibility). 1440 random 1441 A client-generated random structure. 1443 session_id 1444 The ID of a session the client wishes to use for this 1445 connection. This field should be empty if no session_id is 1446 available or the client wishes to generate new security 1447 parameters. 1449 cipher_suites 1450 This is a list of the cryptographic options supported by the 1451 client, with the client's first preference first. If the 1452 session_id field is not empty (implying a session resumption 1453 request) this vector must include at least the cipher_suite 1454 from that session. Values are defined in Appendix A.6. 1456 compression_methods 1457 This is a list of the compression methods supported by the 1458 client, sorted by client preference. If the session_id field 1459 is not empty (implying a session resumption request) it 1460 must include the compression_method from that session. 1462 This vector must contain, and all implementations must 1463 support, CompressionMethod.null. Thus, a client and server 1464 will always be able to agree on a compression method. 1466 After sending the client hello message, the client waits for a 1467 server hello message. Any other handshake message returned by the 1468 server except for a hello request is treated as a fatal error. 1470 Forward compatibility note: 1471 In the interests of forward compatibility, it is permitted for 1472 a client hello message to include extra data after the 1473 compression methods. This data must be included in the 1474 handshake hashes, but must otherwise be ignored. This is the 1475 only handshake message for which this is legal; for all other 1476 messages, the amount of data in the message must match the 1477 description of the message precisely. 1479 6.4.1.3 Server hello 1481 When this message will be sent: 1483 The server will send this message in response to a client hello 1484 message when it was able to find an acceptable set of algorithms. If 1485 it cannot find such a match, it will respond with a handshake 1486 failure alert. 1488 Structure of this message: 1490 struct { 1491 ProtocolVersion server_version; 1492 Random random; 1493 SessionID session_id; 1494 CipherSuite cipher_suite; 1495 CompressionMethod compression_method; 1496 } ServerHello; 1498 server_version 1499 This field will contain the lower of that suggested by the 1500 client in the client hello and the highest supported by the 1501 server. For this version of the specification, the version is 1502 be 3.0 (See Appendix E for details about backward 1503 compatibility). 1505 random 1506 This structure is generated by the server and must be 1507 different from (and independent of) ClientHello.random. 1509 session_id 1510 This is the identity of the session corresponding to this 1511 connection. If the ClientHello.session_id was non-empty, the 1512 server will look in its session cache for a match. If a match 1513 is found and the server is willing to establish the new 1514 connection using the specified session state, the server will 1515 respond with the same value as was supplied by the client. This 1516 indicates a resumed session and dictates that the parties must 1517 proceed directly to the finished messages. Otherwise this field 1518 will contain a different value identifying the new session. The 1519 server may return an empty session_id to indicate that the 1520 session will not be cached and therefore cannot be resumed. 1522 cipher_suite 1523 The single cipher suite selected by the server from the list in 1524 ClientHello.cipher_suites. For resumed sessions this field is 1525 the value from the state of the session being resumed. 1527 compression_method 1528 The single compression algorithm selected by the server from 1529 the list in ClientHello.compression_methods. For resumed 1530 sessions this field is the value from the resumed session 1531 state. 1533 6.4.2 Server certificate 1535 When this message will be sent: 1537 The server must send a certificate whenever the agreed-upon key 1538 exchange method is not an anonymous one. This message will always 1539 immediately follow the server hello message. 1541 Meaning of this message: 1543 The certificate type must be appropriate for the selected cipher 1544 suite's key exchange algorithm, and is generally an X.509.v3 1545 certificate. It must contain a key which matches the key exchange 1546 method, as follows. Unless otherwise specified, the signing 1547 algorithm for the certificate must be the same as the algorithm for 1548 the certificate key. Unless otherwise specified, the public key may 1549 be of any length. 1551 Key Exchange Algorithm Certificate Key Type 1553 RSA RSA public key; the certificate must 1554 allow the key to be used for encryption. 1556 RSA_EXPORT RSA public key of length greater than 1557 512 bits which can be used for signing, 1558 or a key of 512 bits or shorter which 1559 Can be used for encryption or signing. 1561 DHE_DSS DSS public key. 1563 DHE_DSS_EXPORT DSS public key. 1565 DHE_RSA RSA public key which can be used for 1566 signing. 1568 DHE_RSA_EXPORT RSA public key which can be used for 1569 signing. 1571 DH_DSS Diffie-Hellman key. The algorithm used 1572 to sign the certificate should be DSS. 1574 DH_RSA Diffie-Hellman key. The algorithm used 1575 to sign the certificate should be RSA. 1577 As CipherSuites which specify new key exchange methods are specified 1578 for the TLS Protocol, they will imply certificate format and the 1579 required encoded keying information. 1581 Structure of this message: 1583 opaque ASN.1Cert<1..2^24-1>; 1584 struct { 1585 ASN.1Cert certificate_list<1..2^24-1>; 1586 } Certificate; 1588 certificate_list 1589 This is a sequence (chain) of X.509.v3 certificates, ordered 1590 with the sender's certificate first followed by any certificate 1591 authority certificates proceeding sequentially upward, with a 1592 self-signed certificate for the root CA coming last in the 1593 list. 1595 The same message type and structure will be used for the client's 1596 response to a certificate request message. 1598 Note: 1599 PKCS #7 [PKCS7] is not used as the format for the certificate 1600 vector because PKCS #6 [PKCS6] extended certificates are not 1601 used. Also PKCS #7 defines a SET rather than a SEQUENCE, making 1602 the task of parsing the list more difficult. 1604 6.4.3 Server key exchange message 1606 When this message will be sent: 1608 This message will be sent after the server certificate message (or 1609 the server hello message, if the server certificate is not sent), 1610 but before the server hello done message. The server key exchange 1611 message may be sent before or after this message. 1613 The server key exchange message is sent by the server only when the 1614 server certificate message (if sent) does not contain enough data to 1615 allow the client to exchange a premaster secret. This is true for 1616 the following key exchange methods: 1618 RSA_EXPORT (if the public key in the server certificate is 1619 longer than 512 bits) 1620 DHE_DSS 1621 DHE_DSS_EXPORT 1622 DHE_RSA 1623 DHE_RSA_EXPORT 1624 DH_anon 1626 It is not legal to send the server key exchange message for the 1627 following key exchange methods: 1629 RSA 1630 RSA_EXPORT (when the public key in the server certificate 1631 is less than or equal to 512 bits in length) 1632 DH_DSS 1633 DH_RSA 1635 Meaning of this message: 1637 This message conveys cryptographic information to allow the client 1638 to communicate the premaster secret: either an RSA public key to 1639 encrypt the premaster secret with, or a Diffie-Hellman public key 1640 with which the client can complete a key exchange (with the result 1641 being the premaster secret.) 1643 As additional CipherSuites are defined for TLS which include new key 1644 exchange algorithms, the server key exchange message will be sent if 1645 and only if the certificate type associated with the key exchange 1646 algorithm does not provide enough information for the client to 1647 exchange a premaster secret. 1649 Note: 1650 According to current US export law, RSA moduli larger than 512 1651 bits may not be used for key exchange in software exported 1652 from the US. With this message, the larger RSA keys encoded in 1653 certificates may be used to sign temporary shorter RSA keys 1654 for the RSA_EXPORT key exchange method. 1656 Structure of this message: 1658 enum { rsa, diffie_hellman } 1659 KeyExchangeAlgorithm; 1661 struct { 1662 opaque rsa_modulus<1..2^16-1>; 1663 opaque rsa_exponent<1..2^16-1>; 1664 } ServerRSAParams; 1666 rsa_modulus 1667 The modulus of the server's temporary RSA key. 1669 rsa_exponent 1670 The public exponent of the server's temporary RSA key. 1672 struct { 1673 opaque dh_p<1..2^16-1>; 1674 opaque dh_g<1..2^16-1>; 1675 opaque dh_Ys<1..2^16-1>; 1676 } ServerDHParams; /* Ephemeral DH parameters */ 1678 dh_p 1679 The prime modulus used for the Diffie-Hellman operation. 1681 dh_g 1682 The generator used for the Diffie-Hellman operation. 1684 dh_Ys 1685 The server's Diffie-Hellman public value (g^X mod p). 1687 struct { 1688 select (KeyExchangeAlgorithm) { 1689 case diffie_hellman: 1690 ServerDHParams params; 1691 Signature signed_params; 1692 case rsa: 1693 ServerRSAParams params; 1694 Signature signed_params; 1695 }; 1696 } ServerKeyExchange; 1698 params 1699 The server's key exchange parameters. 1701 signed_params 1702 For non-anonymous key exchanges, a hash of the corresponding 1703 params value, with the signature appropriate to that hash 1704 applied. 1706 md5_hash 1707 MD5(ClientHello.random + ServerHello.random + ServerParams); 1709 sha_hash 1710 SHA(ClientHello.random + ServerHello.random + ServerParams); 1712 enum { anonymous, rsa, dsa } SignatureAlgorithm; 1714 select (SignatureAlgorithm) 1715 { case anonymous: struct { }; 1716 case rsa: 1717 digitally-signed struct { 1718 opaque md5_hash[16]; 1719 opaque sha_hash[20]; 1720 }; 1722 case dsa: 1723 digitally-signed struct { 1724 opaque sha_hash[20]; 1725 }; 1726 } Signature; 1728 6.4.4 Certificate request 1730 When this message will be sent: 1732 A non-anonymous server can optionally request a certificate from the 1733 client, if appropriate for the selected cipher suite. 1735 This message may be sent between the server certificate message and 1736 the server hello done message. It may legally precede or follow the 1737 server key exchange message. It is sent at the discretion of the 1738 server, when legal. 1740 Structure of this message: 1742 enum { 1743 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 1744 rsa_ephemeral_dh(5), dss_ephemeral_dh(6), 1745 (255) 1746 } ClientCertificateType; 1748 opaque DistinguishedName<1..2^16-1>; 1750 struct { 1751 ClientCertificateType certificate_types<1..2^8-1>; 1752 DistinguishedName certificate_authorities<3..2^16-1>; 1753 } CertificateRequest; 1755 certificate_types 1756 This field is a list of the types of certificates requested, 1757 sorted in order of the server's preference. 1759 certificate_authorities 1760 A list of the distinguished names of acceptable certificate 1761 authorities. 1763 Note: 1764 DistinguishedName is derived from [X509]. 1766 Note: 1767 It is a fatal handshake_failure alert for an anonymous server 1768 to request client identification. 1770 6.4.5 Server hello done 1772 When this message will be sent: 1774 The server hello done message is sent by the server to indicate the 1775 end of the server hello and associated messages. After sending this 1776 message the server will wait for a client response. 1778 Meaning of this message: 1780 This message means that the server is done sending messages to 1781 support the key exchange, and the client can proceed with its phase 1782 of the key exchange. 1784 Upon receipt of the server hello done message the client should 1785 verify that the server provided a valid certificate if required and 1786 check that the server hello parameters are acceptable. 1788 Structure of this message: 1790 struct { } ServerHelloDone; 1792 6.4.6 Client certificate 1794 When this message will be sent: 1796 This is the first message the client can send after receiving a 1797 server hello done message. This message is only sent if the server 1798 requests a certificate. If no suitable certificate is available, the 1799 client should send a no_certificate alert instead. This alert is 1800 only a warning, however the server may respond with a fatal 1801 handshake failure alert if client authentication is required. Client 1802 certificates are sent using the Certificate structure defined in 1803 Section 5.6.2. 1805 Note: 1806 When using a static Diffie-Hellman based key exchange method 1807 (DH_DSS or DH_RSA), if client authentication is requested, the 1808 Diffie-Hellman group and generator encoded in the client's 1809 certificate must match the server specified Diffie-Hellman 1810 parameters if the client's parameters are to be used for the 1811 key exchange. 1813 6.4.7 Client key exchange message 1815 When this message will be sent: 1817 This message is always sent by the client. It will immediately 1818 follow the client certificate message, if it is sent, or the 1819 no_certificate alert, if a certificate was requested but an 1820 appropriate one was not available. Otherwise it will be the first 1821 message sent by the client after it receives the server hello done 1822 message. 1824 Meaning of this message: 1826 With this message, the premaster secret is set, either though direct 1827 transmisson of the RSA-encrypted secret, or by the transmission of 1828 Diffie-Hellman parameters which will allow each side to agree upon 1829 the same premaster secret. When the key exchange method is DH_RSA or 1830 DH_DSS, client certification has been requested, and the client was 1831 able to respond with a certificate which contained a Diffie-Hellman 1832 public key whose parameters (group and generator) matched those 1833 specified by the server in its certificate, this message will not 1834 contain any data. 1836 Structure of this message: 1838 The choice of messages depends on which key exchange method has been 1839 selected. See Section 6.4.3 for the KeyExchangeAlgorithm definition. 1841 struct { 1842 select (KeyExchangeAlgorithm) { 1843 case rsa: EncryptedPreMasterSecret; 1844 case diffie_hellman: ClientDiffieHellmanPublic; 1845 } exchange_keys; 1846 } ClientKeyExchange; 1848 6.4.7.1 RSA encrypted premaster secret message 1850 Meaning of this message: 1852 If RSA is being used for key agreement and authentication, the 1853 client generates a 48-byte premaster secret, encrypts it using the 1854 public key from the server's certificate or the temporary RSA key 1855 provided in a server key exchange message, and sends the result in 1856 an encrypted premaster secret message. This structure is a variant 1857 of the client key exchange message, not a message in itself. 1859 Structure of this message: 1861 struct { 1862 ProtocolVersion client_version; 1863 opaque random[46]; 1864 } PreMasterSecret; 1866 client_version 1867 The latest (newest) version supported by the client. This is 1868 used to detect version roll-back attacks. 1870 random 1871 46 securely-generated random bytes. 1873 struct { 1874 public-key-encrypted PreMasterSecret pre_master_secret; 1875 } EncryptedPreMasterSecret; 1877 pre_master_secret 1878 This random value is generated by the client and is used to 1879 generate the master secret, as specified in Section 7.1. 1881 6.4.7.2 Client Diffie-Hellman public value 1883 Meaning of this message: 1885 This structure conveys the client's Diffie-Hellman public value (Yc) 1886 if it was not already included in the client's certificate. The 1887 encoding used for Yc is determined by the enumerated 1888 PublicValueEncoding. This structure is a variant of the client key 1889 exchange message, not a message in itself. 1891 Structure of this message: 1893 enum { implicit, explicit } PublicValueEncoding; 1895 implicit 1896 If the client certificate already contains a suitable 1897 Diffie-Hellman key, then Yc is implicit and does not need to 1898 be sent again. 1900 explicit 1901 Yc needs to be sent. 1903 struct { 1904 select (PublicValueEncoding) { 1905 case implicit: struct { }; 1906 case explicit: opaque dh_Yc<1..2^16-1>; 1907 } dh_public; 1908 } ClientDiffieHellmanPublic; 1910 dh_Yc 1911 The client's Diffie-Hellman public value (Yc). 1913 6.4.8 Certificate verify 1915 When this message will be sent: 1917 This message is used to provide explicit verification of a client 1918 certificate. This message is only sent following a client 1919 certificate that has signing capability (i.e. all certificates 1920 except those containing fixed Diffie-Hellman parameters). When sent, 1921 it will immediately follow the client key exchange message. 1923 Structure of this message: 1925 struct { 1926 Signature signature; 1927 } CertificateVerify; 1929 The Signature type is defined in 6.4.3. 1931 CertificateVerify.signature.md5_hash 1932 MD5(master_secret + pad_2 + MD5(handshake_messages + 1933 master_secret + pad_1)); 1935 Certificate.signature.sha_hash 1936 SHA(master_secret + pad_2 + SHA(handshake_messages + 1937 master_secret + pad_1)); 1939 pad_1 1940 The character 0x36 repeated 48 times for MD5 or 40 times for SHA. 1942 pad_2 1943 The character 0x5c repeated 48 times for MD5 or 40 times for SHA. 1945 Here handshake_messages refers to all handshake messages sent or 1946 received starting at client hello up to but not including this 1947 message, including the type and length fields of the handshake 1948 messages. This is the concatenation of all the Handshake structures 1949 as defined in 6.4 exchanged thus far. 1951 6.4.9 Finished 1953 When this message will be sent: 1955 A finished message is always sent immediately after a change cipher 1956 spec message to verify that the key exchange and authentication 1957 processes were successful. It is essential that a change cipher spec 1958 message be received between the other handshake messages and the 1959 Finished message. 1961 Meaning of this message: 1963 The finished message is the first protected with the just-negotiated 1964 algorithms, keys, and secrets. No acknowledgment of the finished 1965 message is required; parties may begin sending encrypted data 1966 immediately after sending the finished message. Recipients of 1967 finished messages must verify that the contents are correct. 1969 enum { client(0x434C4E54), server(0x53525652) } Sender; 1970 struct { 1971 opaque md5_hash[16]; 1972 opaque sha_hash[20]; 1973 } Finished; 1975 md5_hash 1976 MD5(master_secret + pad2 + MD5(handshake_messages + Sender + 1977 master_secret + pad1)); 1979 sha_hash 1980 SHA(master_secret + pad2 + SHA(handshake_messages + Sender + 1981 master_secret + pad1)); 1983 handshake_messages 1984 All of the data from all handshake messages up to but not 1985 including this message. This is only data visible at the 1986 handshake layer and does not include record layer headers. 1987 This is the concatenation of all the Handshake structures as 1988 defined in 6.4 exchanged thus far. 1990 It is a fatal error if a finished message is not preceeded by a 1991 change cipher spec message at the appropriate point in the 1992 handshake. 1994 The hash contained in finished messages sent by the server 1995 incorporate Sender.server; those sent by the client incorporate 1996 Sender.client. The value handshake_messages includes all handshake 1997 messages starting at client hello up to, but not including, this 1998 finished message. This may be different from handshake_messages in 1999 Section 5.6.8 because it would include the certificate verify 2000 message (if sent). Also, the handshake_messages for the finished 2001 message sent by the client will be different from that for the 2002 finished message sent by the server, because the one which is sent 2003 second will include the prior one. 2005 Note: 2006 Change cipher spec messages are not handshake messages and are 2007 not included in the hash computations. 2009 7. Cryptographic computations 2011 In order to begin connection protection, the TLS Record Protocol 2012 requires specification of a suite of algorithms, a master secret, 2013 and the client and server random values. The authentication, 2014 encryption, and MAC algorithms are determined by the cipher_suite 2015 selected by the server and revealed in the server hello message. The 2016 compression algorithm is negotiated in the hello messages, and the 2017 random values are exchanged in the hello messages. All that remains 2018 is to calculate the master secret. 2020 7.1 Computing the master secret 2022 For all key exchange methods, the same algorithm is used to convert 2023 the pre_master_secret into the master_secret. The pre_master_secret 2024 should be deleted from memory once the master_secret has been 2025 computed. 2027 master_secret = 2028 MD5(pre_master_secret + SHA('A' + pre_master_secret + 2029 ClientHello.random + ServerHello.random)) + 2030 MD5(pre_master_secret + SHA('BB' + pre_master_secret + 2031 ClientHello.random + ServerHello.random)) + 2032 MD5(pre_master_secret + SHA('CCC' + pre_master_secret + 2033 ClientHello.random + ServerHello.random)); 2035 The master secret is always exactly 48 bytes in length. The length 2036 of the premaster secret will vary depending on key exchange method. 2038 7.1.1 RSA 2040 When RSA is used for server authentication and key exchange, a 2041 48-byte pre_master_secret is generated by the client, encrypted 2042 under the server's public key, and sent to the server. The server 2043 uses its private key to decrypt the pre_master_secret. Both parties 2044 then convert the pre_master_secret into the master_secret, as 2045 specified above. 2047 RSA digital signatures are performed using PKCS #1 [PKCS1] block 2048 type 1. RSA public key encryption is performed using PKCS #1 block 2049 type 2. 2051 7.1.2 Diffie-Hellman 2053 A conventional Diffie-Hellman computation is performed. The 2054 negotiated key (Z) is used as the pre_master_secret, and is 2055 converted into the master_secret, as specified above. 2057 Note: 2058 Diffie-Hellman parameters are specified by the server, and may 2059 be either ephemeral or contained within the server's 2060 certificate. 2062 8. Application data protocol 2064 Application data messages are carried by the Record Layer and are 2065 fragmented, compressed and encrypted based on the current connection 2066 state. The messages are treated as transparent data to the record 2067 layer. 2069 Appendix A 2071 A. Protocol constant values 2073 This section describes protocol types and constants. 2075 A.1 Reserved port assignments 2077 At the present time TLS is implemented using TCP/IP as the base 2078 networking technology. The IANA reserved the following Internet 2079 Protocol [IP] port numbers for use in conjunction with the SSL 3.0 2080 Protocol, which we presume will be used by TLS as well. 2082 443 Reserved for use by Hypertext Transfer Protocol with SSL (https) 2084 465 Reserved for use by Simple Mail Transfer Protocol with 2085 SSL (ssmtp). 2087 563 Reserved for use by Network News Transfer Protocol with SSL 2088 (snntp). 2090 636 Reserved for Light Directory Access Protocol with SSL (ssl-ldap) 2092 990 Reserved (pending) for File Transfer Protocol with SSL (ftps) 2094 995 Reserved for Post Office Protocol with SSL (spop3) 2096 A.1.1 Record layer 2098 struct { 2099 uint8 major, minor; 2100 } ProtocolVersion; 2102 ProtocolVersion version = { 3,0 }; 2104 enum { 2105 change_cipher_spec(20), alert(21), handshake(22), 2106 application_data(23), (255) 2107 } ContentType; 2109 struct { 2110 ContentType type; 2111 ProtocolVersion version; 2112 uint16 length; 2113 opaque fragment[TLSPlaintext.length]; 2114 } TLSPlaintext; 2116 struct { 2117 ContentType type; 2118 ProtocolVersion version; 2119 uint16 length; 2120 opaque fragment[TLSCompressed.length]; 2121 } TLSCompressed; 2123 struct { 2124 ContentType type; 2125 ProtocolVersion version; 2126 uint16 length; 2127 select (CipherSpec.cipher_type) { 2128 case stream: GenericStreamCipher; 2129 case block: GenericBlockCipher; 2130 } fragment; 2131 } TLSCiphertext; 2133 stream-ciphered struct { 2134 opaque content[TLSCompressed.length]; 2135 opaque MAC[CipherSpec.hash_size]; 2136 } GenericStreamCipher; 2138 block-ciphered struct { 2139 opaque content[TLSCompressed.length]; 2140 opaque MAC[CipherSpec.hash_size]; 2141 uint8 padding[GenericBlockCipher.padding_length]; 2142 uint8 padding_length; 2143 } GenericBlockCipher; 2145 A.2 Change cipher specs message 2147 struct { 2148 enum { change_cipher_spec(1), (255) } type; 2149 } ChangeCipherSpec; 2151 A.3 Alert messages 2153 enum { warning(1), fatal(2), (255) } AlertLevel; 2155 enum { 2156 close_notify(0), 2157 unexpected_message(10), 2158 bad_record_mac(20), 2159 decompression_failure(30), 2160 handshake_failure(40), 2161 no_certificate(41), 2162 bad_certificate(42), 2163 unsupported_certificate(43), 2164 certificate_revoked(44), 2165 certificate_expired(45), 2166 certificate_unknown(46), 2167 illegal_parameter (47), 2168 (255) 2169 } AlertDescription; 2171 struct { 2172 AlertLevel level; 2173 AlertDescription description; 2174 } Alert; 2176 A.4 Handshake protocol 2178 enum { 2179 hello_request(0), client_hello(1), server_hello(2), 2180 certificate(11), server_key_exchange (12), 2181 certificate_request(13), server_done(14), 2182 certificate_verify(15), client_key_exchange(16), 2183 finished(20), (255) 2184 } HandshakeType; 2186 struct { 2187 HandshakeType msg_type; 2188 uint24 length; 2189 select (HandshakeType) { 2190 case hello_request: HelloRequest; 2191 case client_hello: ClientHello; 2192 case server_hello: ServerHello; 2193 case certificate: Certificate; 2194 case server_key_exchange: ServerKeyExchange; 2195 case certificate_request: CertificateRequest; 2196 case server_done: ServerHelloDone; 2197 case certificate_verify: CertificateVerify; 2198 case client_key_exchange: ClientKeyExchange; 2199 case finished: Finished; 2200 } body; 2201 } Handshake; 2203 A.4.1 Hello messages 2205 struct { } HelloRequest; 2207 struct { 2208 uint32 gmt_unix_time; 2209 opaque random_bytes[28]; 2210 } Random; 2212 opaque SessionID<0..32>; 2214 uint8 CipherSuite[2]; 2216 enum { null(0), (255) } CompressionMethod; 2217 struct { 2218 ProtocolVersion client_version; 2219 Random random; 2220 SessionID session_id; 2221 CipherSuite cipher_suites<0..2^16-1>; 2222 CompressionMethod compression_methods<0..2^8-1>; 2223 } ClientHello; 2225 struct { 2226 ProtocolVersion server_version; 2227 Random random; 2228 SessionID session_id; 2229 CipherSuite cipher_suite; 2230 CompressionMethod compression_method; 2231 } ServerHello; 2233 A.4.2 Server authentication and key exchange messages 2235 opaque ASN.1Cert<2^24-1>; 2237 struct { 2238 ASN.1Cert certificate_list<1..2^24-1>; 2239 } Certificate; 2241 enum { rsa, diffie_hellman } KeyExchangeAlgorithm; 2243 struct { 2244 opaque RSA_modulus<1..2^16-1>; 2245 opaque RSA_exponent<1..2^16-1>; 2246 } ServerRSAParams; 2248 struct { 2249 opaque DH_p<1..2^16-1>; 2250 opaque DH_g<1..2^16-1>; 2251 opaque DH_Ys<1..2^16-1>; 2252 } ServerDHParams; 2254 struct { 2255 select (KeyExchangeAlgorithm) { 2256 case diffie_hellman: 2257 ServerDHParams params; 2258 Signature signed_params; 2259 case rsa: 2260 ServerRSAParams params; 2261 Signature signed_params; 2262 }; 2263 } ServerKeyExchange; 2265 enum { anonymous, rsa, dsa } SignatureAlgorithm; 2266 digitally-signed struct { 2267 select(SignatureAlgorithm) { 2268 case anonymous: struct { }; 2269 case rsa: 2270 opaque md5_hash[16]; 2271 opaque sha_hash[20]; 2272 case dsa: 2273 opaque sha_hash[20]; 2274 }; 2275 } Signature; 2277 enum { 2278 RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3), 2279 DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6), 2280 (255) 2281 } CertificateType; 2283 opaque DistinguishedName<1..2^16-1>; 2285 struct { 2286 CertificateType certificate_types<1..2^8-1>; 2287 DistinguishedName certificate_authorities<3..2^16-1>; 2288 } CertificateRequest; 2290 struct { } ServerHelloDone; 2292 A.5 Client authentication and key exchange messages 2294 struct { 2295 select (KeyExchangeAlgorithm) { 2296 case rsa: EncryptedPreMasterSecret; 2297 case diffie_hellman: DiffieHellmanClientPublicValue; 2298 } exchange_keys; 2299 } ClientKeyExchange; 2301 struct { 2302 ProtocolVersion client_version; 2303 opaque random[46]; 2304 } PreMasterSecret; 2306 struct { 2307 public-key-encrypted PreMasterSecret pre_master_secret; 2308 } EncryptedPreMasterSecret; 2310 enum { implicit, explicit } PublicValueEncoding; 2312 struct { 2313 select (PublicValueEncoding) { 2314 case implicit: struct {}; 2315 case explicit: opaque DH_Yc<1..2^16-1>; 2316 } dh_public; 2318 } ClientDiffieHellmanPublic; 2320 struct { 2321 Signature signature; 2322 } CertificateVerify; 2324 A.5.1 Handshake finalization message 2326 struct { 2327 opaque md5_hash[16]; 2328 opaque sha_hash[20]; 2329 } Finished; 2331 A.6 The CipherSuite 2333 The following values define the CipherSuite codes used in the client 2334 hello and server hello messages. 2336 A CipherSuite defines a cipher specifications supported in TLS 2337 Version 1.0. 2339 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; 2341 The following CipherSuite definitions require that the server 2342 provide an RSA certificate that can be used for key exchange. The 2343 server may request either an RSA or a DSS signature-capable 2344 certificate in the certificate request message. 2346 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; 2347 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; 2348 CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; 2349 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; 2350 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; 2351 CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; 2352 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; 2353 CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; 2354 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; 2355 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; 2357 The following CipherSuite definitions are used for 2358 server-authenticated (and optionally client-authenticated) 2359 Diffie-Hellman. DH denotes cipher suites in which the server's 2360 certificate contains the Diffie-Hellman parameters signed by the 2361 certificate authority (CA). DHE denotes ephemeral Diffie-Hellman, 2362 where the Diffie-Hellman parameters are signed by a DSS or RSA 2363 certificate, which has been signed by the CA. The signing algorithm 2364 used is specified after the DH or DHE parameter. In all cases, the 2365 client must have the same type of certificate, and must use the 2366 Diffie-Hellman parameters chosen by the server. 2368 CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; 2369 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; 2370 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; 2371 CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; 2372 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; 2373 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; 2374 CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; 2375 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; 2376 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; 2377 CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; 2378 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; 2379 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; 2381 The following cipher suites are used for completely anonymous 2382 Diffie-Hellman communications in which neither party is 2383 authenticated. Note that this mode is vulnerable to 2384 man-in-the-middle attacks and is therefore strongly discouraged. 2386 CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; 2387 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; 2388 CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; 2389 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; 2390 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; 2392 Note: 2393 All cipher suites whose first byte is 0xFF are considered 2394 private and can be used for defining local/experimental 2395 algorithms. Interoperability of such types is a local matter. 2397 Note: 2398 Additional cipher suites will be considered for implementation 2399 only with submission of notarized letters from two independent 2400 entities. Netscape Communications Corp. will act as an interim 2401 registration office, until a public standards body assumes 2402 control of TLS. 2404 A.7 The Security Parameters 2406 These security parameters are determined by the TLS Handshake 2407 Protocol and provided as parameters to the TLS Record Layer in order 2408 to initialize a connection state. SecurityParameters includes: 2410 enum { null(0), (255) } CompressionMethod; 2412 enum { server, client } ConnectionEnd; 2414 enum { null, rc4, rc2, des, 3des, des40 } 2415 BulkCipherAlgorithm; 2417 enum { stream, block } CipherType; 2418 enum { true, false } IsExportable; 2420 enum { null, md5, sha } MACAlgorithm; 2422 /* The algorithms specified in CompressionMethod, 2423 BulkCipherAlgorithm, and MACAlgorithm may be added to. */ 2425 struct { 2426 ConnectionEnd entity; 2427 BulkCipherAlgorithm bulk_cipher_algorithm; 2428 CipherType cipher_type; 2429 uint8 key_size; 2430 uint8 key_material_length; 2431 IsExportable is_exportable; 2432 MACAlgorithm mac_algorithm; 2433 uint8 hash_size; 2434 uint8 whitener_length; 2435 CompressionMethod compression_algorithm; 2436 opaque master_secret[48]; 2437 opaque client_random[32]; 2438 opaque server_random[32]; 2439 } SecurityParameters; 2441 Appendix B 2443 B. Glossary 2445 application protocol 2446 An application protocol is a protocol that normally layers 2447 directly on top of the transport layer (e.g., TCP/IP). 2448 Examples include HTTP, TELNET, FTP, and SMTP. 2450 asymmetric cipher 2451 See public key cryptography. 2453 authentication 2454 Authentication is the ability of one entity to determine the 2455 identity of another entity. 2457 block cipher 2458 A block cipher is an algorithm that operates on plaintext in 2459 groups of bits, called blocks. 64 bits is a typical block size. 2461 bulk cipher 2462 A symmetric encryption algorithm used to encrypt large 2463 quantities of data. 2465 cipher block chaining 2466 Mode (CBC) CBC is a mode in which every plaintext block 2467 encrypted with the block cipher is first exclusive-ORed with 2468 the previous ciphertext block (or, in the case of the first 2469 block, with the initialization vector). 2471 certificate 2472 As part of the X.509 protocol (a.k.a. ISO Authentication 2473 framework), certificates are assigned by a trusted Certificate 2474 Authority and provide verification of a party's identity and 2475 may also supply its public key. 2477 client 2478 The application entity that initiates a connection to a server 2480 client write key 2481 The key used to encrypt data written by the client. 2483 client write MAC secret 2484 The secret data used to authenticate data written by the 2485 client. 2487 connection 2488 A connection is a transport (in the OSI layering model 2489 definition) that provides a suitable type of service. For TLS, 2490 such connections are peer to peer relationships. The 2491 connections are transient. Every connection is associated with 2492 one session. 2494 Data Encryption Standard 2495 DES is a very widely used symmetric encryption algorithm. 2496 DES is a block cipher. (DES) 2498 Digital Signature Standard 2499 (DSS) A standard for digital signing, including the Digital 2500 Signing Algorithm, approved by the National Institute of 2501 Standards and Technology, defined in NIST FIPS PUB 186, 2502 "Digital Signature Standard," published May, 1994 by the U.S. 2503 Dept. of Commerce. 2505 digital signatures 2506 Digital signatures utilize public key cryptography and one-way 2507 hash functions to produce a signature of the data that can be 2508 authenticated, and is difficult to forge or repudiate. 2510 handshake 2511 An initial negotiation between client and server that 2512 establishes the parameters of their transactions. 2514 Initialization Vector 2515 (IV) When a block cipher is used in CBC mode, the 2516 initialization vector is exclusive-ORed with the first 2517 plaintext block prior to encryption. 2519 IDEA 2520 A 64-bit block cipher designed by Xuejia Lai and James Massey. 2522 Message Authentication Code 2523 (MAC) A Message Authentication Code is a one-way hash computed 2524 from a message and some secret data. Its purpose is to detect 2525 if the message has been altered. 2527 master secret 2528 Secure secret data used for generating encryption keys, MAC 2529 secrets, and IVs. 2531 MD5 2532 MD5 [7] is a secure hashing function that converts an 2533 arbitrarily long data stream into a digest of fixed size. 2535 public key cryptography 2536 A class of cryptographic techniques employing two-key ciphers. 2537 Messages encrypted with the public key can only be decrypted 2538 with the associated private key. Conversely, messages signed 2539 with the private key can be verified with the public key. 2541 one-way hash function 2542 A one-way transformation that converts an arbitrary amount of 2543 data into a fixed-length hash. It is computation- ally hard to 2544 reverse the transformation or to find collisions. MD5 and SHA 2545 are examples of one-way hash functions. 2547 RC2, RC4 2548 Proprietary bulk ciphers from RSA Data Security, Inc. (There 2549 is no good reference to these as they are unpublished works; 2550 however, see [RSADSI]). RC2 is block cipher and RC4 is a 2551 stream cipher. 2553 RSA 2554 A very widely used public-key algorithm that can be used for 2555 either encryption or digital signing. 2557 salt 2558 Non-secret random data used to make export encryption keys 2559 resist precomputation attacks. 2561 server 2562 The server is the application entity that responds to requests 2563 for connections from clients. The server is passive, waiting 2564 for requests from clients. 2566 session 2567 A TLS session is an association between a client and a server. 2568 Sessions are created by the handshake protocol. Sessions 2569 define a set of cryptographic security parameters, which can 2570 be shared among multiple connections. Sessions are used to 2571 avoid the expensive negotiation of new security parameters for 2572 each connection. 2574 session identifier 2575 A session identifier is a value generated by a server that 2576 identifies a particular session. 2578 server write key 2579 The key used to encrypt data written by the server. 2581 server write MAC secret 2582 The secret data used to authenticate data written by the 2583 server. 2585 SHA 2586 The Secure Hash Algorithm is defined in FIPS PUB 180-1. It 2587 produces a 20-byte output [SHA]. 2589 SSL 2590 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based 2591 on SSL Version 3.0 2593 stream cipher/ 2594 An encryption algorithm that converts a key into a 2595 cryptographically-strong keystream, which is then 2596 exclusive-ORed with the plaintext. 2598 symmetric cipher 2599 See bulk cipher. 2601 Appendix C 2603 C. CipherSuite definitions 2605 CipherSuite Is Key Cipher Hash 2606 Exportable Exchange 2608 TLS_NULL_WITH_NULL_NULL * NULL NULL NULL 2609 TLS_RSA_WITH_NULL_MD5 * RSA NULL MD5 2610 TLS_RSA_WITH_NULL_SHA * RSA NULL SHA 2611 TLS_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 2612 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 2613 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA 2614 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 2615 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA 2616 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA 2617 TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA 2618 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA 2619 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA 2620 TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA 2621 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA 2622 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA 2623 TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA 2624 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA 2625 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA 2626 TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA 2627 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA 2628 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA 2629 TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA 2630 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA 2631 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 2632 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 2633 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA 2634 TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA 2635 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA 2637 * Indicates IsExportable is True 2639 Key Description Key size limit 2640 Exchange 2641 Algorithm 2642 DHE_DSS Ephemeral DH with DSS signatures None 2643 DHE_DSS_EXPORT Ephemeral DH with DSS signatures DH = 512 bits 2644 DHE_RSA Ephemeral DH with RSA signatures None 2645 DHE_RSA_EXPORT Ephemeral DH with RSA signatures DH = 512 bits, 2646 RSA = none 2647 DH_anon Anonymous DH, no signatures None 2648 DH_anon_EXPORT Anonymous DH, no signatures DH = 512 bits 2649 DH_DSS DH with DSS-based certificates None 2650 DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits 2651 DH_RSA DH with RSA-based certificates None 2652 DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits, 2653 RSA = none 2654 NULL No key exchange N/A 2655 RSA RSA key exchange None 2656 RSA_EXPORT RSA key exchange RSA = 512 bits 2658 Key size limit 2659 The key size limit gives the size of the largest public key 2660 that can be legally used for encryption in cipher suites that 2661 are exportable. 2663 Cipher Cipher IsExpo Key Exp. Effect IV Block 2664 Type rtable Material Key Mat ive Key Size Size 2665 erial Bits 2667 NULL Stream * 0 0 0 0 N/A 2668 IDEA_CBC Block 16 16 128 8 8 2669 RC2_CBC_40 Block * 5 16 40 8 8 2670 RC4_40 Stream * 5 16 40 0 N/A 2671 RC4_128 Stream 16 16 128 0 N/A 2672 DES40_CBC Block * 5 8 40 8 8 2673 DES_CBC Block 8 8 56 8 8 2674 3DES_EDE_CBC Block 24 24 168 8 8 2676 * Indicates IsExportable is true. 2678 Key Material 2679 The number of bytes from the key_block that are used for 2680 generating the write keys. 2682 Expanded Key Material 2683 The number of bytes actually fed into the encryption algorithm 2685 Effective Key Bits 2686 How much entropy material is in the key material being fed 2687 into the encryption routines. 2689 Hash Hash Size Padding 2690 function Size 2691 NULL 0 0 2692 MD5 16 48 2693 SHA 20 40 2695 Appendix D 2697 D. Implementation Notes 2699 The TLS protocol cannot prevent many common security mistakes. This 2700 section provides several recommendations to assist implementers. 2702 D.1 Temporary RSA keys 2704 US Export restrictions limit RSA keys used for encryption to 512 2705 bits, but do not place any limit on lengths of RSA keys used for 2706 signing operations. Certificates often need to be larger than 512 2707 bits, since 512-bit RSA keys are not secure enough for high-value 2708 transactions or for applications requiring long-term security. Some 2709 certificates are also designated signing-only, in which case they 2710 cannot be used for key exchange. 2712 When the public key in the certificate cannot be used for 2713 encryption, the server signs a temporary RSA key, which is then 2714 exchanged. In exportable applications, the temporary RSA key should 2715 be the maximum allowable length (i.e., 512 bits). Because 512-bit 2716 RSA keys are relatively insecure, they should be changed often. For 2717 typical electronic commerce applications, it is suggested that keys 2718 be changed daily or every 500 transactions, and more often if 2719 possible. Note that while it is acceptable to use the same temporary 2720 key for multiple transactions, it must be signed each time it is 2721 used. 2723 RSA key generation is a time-consuming process. In many cases, a 2724 low-priority process can be assigned the task of key generation. 2726 Whenever a new key is completed, the existing temporary key can be 2727 replaced with the new one. 2729 D.2 Random Number Generation and Seeding 2731 TLS requires a cryptographically-secure pseudorandom number 2732 generator (PRNG). Care must be taken in designing and seeding PRNGs. 2733 PRNGs based on secure hash operations, most notably MD5 and/or SHA, 2734 are acceptable, but cannot provide more security than the size of 2735 the random number generator state. (For example, MD5-based PRNGs 2736 usually provide 128 bits of state.) 2738 To estimate the amount of seed material being produced, add the 2739 number of bits of unpredictable information in each seed byte. For 2740 example, keystroke timing values taken from a PC- compatible's 18.2 2741 Hz timer provide 1 or 2 secure bits each, even though the total size 2742 of the counter value is 16 bits or more. To seed a 128-bit PRNG, one 2743 would thus require approximately 100 such timer values. 2745 Note: 2746 The seeding functions in RSAREF and versions of BSAFE prior to 2747 3.0 are order-independent. For example, if 1000 seed bits are 2748 supplied, one at a time, in 1000 separate calls to the seed 2749 function, the PRNG will end up in a state which depends only 2750 on the number of 0 or 1 seed bits in the seed data (i.e., 2751 there are 1001 possible final states). Applications using 2752 BSAFE or RSAREF must take extra care to ensure proper seeding. 2754 D.3 Certificates and authentication 2756 Implementations are responsible for verifying the integrity of 2757 certificates and should generally support certificate revocation 2758 messages. Certificates should always be verified to ensure proper 2759 signing by a trusted Certificate Authority (CA). The selection and 2760 addition of trusted CAs should be done very carefully. Users should 2761 be able to view information about the certificate and root CA. 2763 D.4 CipherSuites 2765 TLS supports a range of key sizes and security levels, including 2766 some which provide no or minimal security. A proper implementation 2767 will probably not support many cipher suites. For example, 40-bit 2768 encryption is easily broken, so implementations requiring strong 2769 security should not allow 40-bit keys. Similarly, anonymous 2770 Diffie-Hellman is strongly discouraged because it cannot prevent 2771 man-in-the- middle attacks. Applications should also enforce minimum 2772 and maximum key sizes. For example, certificate chains containing 2773 512-bit RSA keys or signatures are not appropriate for high-security 2774 applications. 2776 Appendix E 2778 E. Version 2.0 Backward Compatibility 2780 Version 3.0 clients that support Version 2.0 servers must send 2781 Version 2.0 client hello messages [SSL-2]. Version 3.0 servers 2782 should accept either client hello format. The only deviations from 2783 the Version 2.0 specification are the ability to specify a version 2784 with a value of three and the support for more ciphering types in 2785 the CipherSpec. 2787 Warning: 2788 The ability to send Version 2.0 client hello messages will be 2789 phased out with all due haste. Implementers should make every 2790 effort to move forward as quickly as possible. Version 3.0 2791 provides better mechanisms for moving to newer versions. 2793 The following cipher specifications are carryovers from SSL Version 2794 2.0. These are assumed to use RSA for key exchange and 2795 authentication. 2797 V2CipherSpec SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; 2798 V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; 2799 V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; 2800 V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 2801 = { 0x04,0x00,0x80 }; 2802 V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; 2803 V2CipherSpec SSL_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; 2804 V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; 2806 Cipher specifications introduced in Version 3.0 can be included in 2807 Version 2.0 client hello messages using the syntax below. Any 2808 V2CipherSpec element with its first byte equal to zero will be 2809 ignored by Version 2.0 servers. Clients sending any of the above 2810 V2CipherSpecs should also include the Version 3.0 equivalent (see 2811 Appendix A.6): 2813 V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite }; 2815 E.1 Version 2 client hello 2817 The Version 2.0 client hello message is presented below using this 2818 document's presentation model. The true definition is still assumed 2819 to be the SSL Version 2.0 specification. 2821 uint8 V2CipherSpec[3]; 2823 struct { 2824 unit8 msg_type; 2825 Version version; 2826 uint16 cipher_spec_length; 2827 uint16 session_id_length; 2828 uint16 challenge_length; 2829 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; 2830 opaque session_id[V2ClientHello.session_id_length]; 2831 Random challenge; 2832 } V2ClientHello; 2834 msg_type 2835 This field, in conjunction with the version field, identifies 2836 a version 2 client hello message. The value should be one (1). 2838 version 2839 The highest version of the protocol supported by the client 2840 (equals ProtocolVersion.version, see Appendix A.1.1). 2842 cipher_spec_length 2843 This field is the total length of the field cipher_specs. It 2844 cannot be zero and must be a multiple of the V2CipherSpec 2845 length (3). 2847 session_id_length 2848 This field must have a value of either zero or 16. If zero, 2849 the client is creating a new session. If 16, the session_id 2850 field will contain the 16 bytes of session identification. 2852 challenge_length 2853 The length in bytes of the client's challenge to the server to 2854 authenticate itself. This value must be 32. 2856 cipher_specs 2857 This is a list of all CipherSpecs the client is willing and 2858 able to use. There must be at least one CipherSpec acceptable 2859 to the server. 2861 session_id 2862 If this field's length is not zero, it will contain the 2863 identification for a session that the client wishes to resume. 2865 challenge 2866 The client challenge to the server for the server to identify 2867 itself is a (nearly) arbitrary length random. The Version 3.0 2868 server will right justify the challenge data to become the 2869 ClientHello.random data (padded with leading zeroes, if 2870 necessary), as specified in this Version 3.0 protocol. If the 2871 length of the challenge is greater than 32 bytes, only the 2872 last 32 bytes are used. It is legitimate (but not necessary) 2873 for a V3 server to reject a V2 ClientHello that has fewer than 2874 16 bytes of challenge data. 2876 Note: 2877 Requests to resume an SSL 3.0 session should use an SSL 3.0 2878 client hello. 2880 E.2 Avoiding man-in-the-middle version rollback 2882 When SSL Version 3.0 clients fall back to Version 2.0 compatibility 2883 mode, they use special PKCS #1 block formatting. This is done so 2884 that Version 3.0 servers will reject Version 2.0 sessions with 2885 Version 3.0-capable clients. 2887 When Version 3.0 clients are in Version 2.0 compatibility mode, they 2888 set the right-hand (least-significant) 8 random bytes of the PKCS 2889 padding (not including the terminal null of the padding) for the RSA 2890 encryption of the ENCRYPTED-KEY- DATA field of the CLIENT-MASTER-KEY 2891 to 0x03 (the other padding bytes are random). After decrypting the 2892 ENCRYPTED- KEY-DATA field, servers that support TLS should issue 2893 an error if these eight padding bytes are 0x03. Version 2.0 servers 2894 receiving blocks padded in this manner will proceed normally. 2896 Appendix F 2898 F. Security analysis 2900 The TLS protocol is designed to establish a secure connection 2901 between a client and a server communicating over an insecure 2902 channel. This document makes several traditional assumptions, 2903 including that attackers have substantial computational resources 2904 and cannot obtain secret information from sources outside the 2905 protocol. Attackers are assumed to have the ability to capture, 2906 modify, delete, replay, and otherwise tamper with messages sent over 2907 the communication channel. This appendix outlines how TLS has been 2908 designed to resist a variety of attacks. 2910 F.1 Handshake protocol 2912 The handshake protocol is responsible for selecting a CipherSpec and 2913 generating a MasterSecret, which together comprise the primary 2914 cryptographic parameters associated with a secure session. The 2915 handshake protocol can also optionally authenticate parties who have 2916 certificates signed by a trusted certificate authority. 2918 F.1.1 Authentication and key exchange 2920 TLS supports three authentication modes: authentication of both 2921 parties, server authentication with an unauthenticated client, and 2922 total anonymity. Whenever the server is authenticated, the channel 2923 should be secure against man-in- the-middle attacks, but completely 2924 anonymous sessions are inherently vulnerable to such attacks. 2925 Anonymous servers cannot authenticate clients, since the client 2926 signature in the certificate verify message may require a server 2927 certificate to bind the signature to a particular server. If the 2928 server is authenticated, its certificate message must provide a 2929 valid certificate chain leading to an acceptable certificate 2930 authority. Similarly, authenticated clients must supply an 2931 acceptable certificate to the server. Each party is responsible for 2932 verifying that the other's certificate is valid and has not expired 2933 or been revoked. 2935 The general goal of the key exchange process is to create a 2936 pre_master_secret known to the communicating parties and not to 2937 attackers. The pre_master_secret will be used to generate the 2938 master_secret (see Section 6.1). The master_secret is required to 2939 generate the finished messages, encryption keys, and MAC secrets 2940 (see Sections 5.6.9 and 6.2.2). By sending a correct finished 2941 message, parties thus prove that they know the correct 2942 pre_master_secret. 2944 F.1.1.1 Anonymous key exchange 2946 Completely anonymous sessions can be established using RSA or 2947 Diffie-Hellman for key exchange. With anonymous RSA, the client 2948 encrypts a pre_master_secret with the server's uncertified public 2949 key extracted from the server key exchange message. The result is 2950 sent in a client key exchange message. Since eavesdroppers do not 2951 know the server's private key, it will be infeasible for them to 2952 decode the pre_master_secret. (Note that no anonymous RSA Cipher 2953 Suites are defined in this document). 2955 With Diffie-Hellman, the server's public parameters are contained in 2956 the server key exchange message and the client's are sent in the 2957 client key exchange message. Eavesdroppers who do not know the 2958 private values should not be able to find the Diffie-Hellman result 2959 (i.e. the pre_master_secret). 2961 Warning: 2962 Completely anonymous connections only provide protection 2963 against passive eavesdropping. Unless an independent 2964 tamper-proof channel is used to verify that the finished 2965 messages were not replaced by an attacker, server 2966 authentication is required in environments where active 2967 man-in-the-middle attacks are a concern. 2969 F.1.1.2 RSA key exchange and authentication 2971 With RSA, key exchange and server authentication are combined. The 2972 public key may be either contained in the server's certificate or 2973 may be a temporary RSA key sent in a server key exchange message. 2974 When temporary RSA keys are used, they are signed by the server's 2975 RSA or DSS certificate. The signature includes the current 2976 ClientHello.random, so old signatures and temporary keys cannot be 2977 replayed. Servers may use a single temporary RSA key for multiple 2978 negotiation sessions. 2980 Note: 2981 The temporary RSA key option is useful if servers need large 2982 certificates but must comply with government-imposed size 2983 limits on keys used for key exchange. 2985 After verifying the server's certificate, the client encrypts a 2986 pre_master_secret with the server's public key. By successfully 2987 decoding the pre_master_secret and producing a correct finished 2988 message, the server demonstrates that it knows the private key 2989 corresponding to the server certificate. 2991 When RSA is used for key exchange, clients are authenticated using 2992 the certificate verify message (see Section 5.6.8). The client signs 2993 a value derived from the master_secret and all preceding handshake 2994 messages. These handshake messages include the server certificate, 2995 which binds the signature to the server, and ServerHello.random, 2996 which binds the signature to the current handshake process. 2998 F.1.1.3 Diffie-Hellman key exchange with authentication 3000 When Diffie-Hellman key exchange is used, the server can either 3001 supply a certificate containing fixed Diffie-Hellman parameters or 3002 can use the server key exchange message to send a set of temporary 3003 Diffie-Hellman parameters signed with a DSS or RSA certificate. 3004 Temporary parameters are hashed with the hello.random values before 3005 signing to ensure that attackers do not replay old parameters. In 3006 either case, the client can verify the certificate or signature to 3007 ensure that the parameters belong to the server. 3009 If the client has a certificate containing fixed Diffie- Hellman 3010 parameters, its certificate contains the information required to 3011 complete the key exchange. Note that in this case the client and 3012 server will generate the same Diffie- Hellman result (i.e., 3013 pre_master_secret) every time they communicate. To prevent the 3014 pre_master_secret from staying in memory any longer than necessary, 3015 it should be converted into the master_secret as soon as possible. 3016 Client Diffie- Hellman parameters must be compatible with those 3017 supplied by the server for the key exchange to work. 3019 If the client has a standard DSS or RSA certificate or is 3020 unauthenticated, it sends a set of temporary parameters to the 3021 server in the client key exchange message, then optionally uses a 3022 certificate verify message to authenticate itself. 3024 F.1.2 Version rollback attacks 3026 Because TLS includes substantial improvements over SSL Version 2.0, 3027 attackers may try to make TLS-capable clients and servers fall back 3028 to Version 2.0. This attack can occur if (and only if) two 3029 TLS-capable parties use an SSL 2.0 handshake. 3031 Although the solution using non-random PKCS #1 block type 2 message 3032 padding is inelegant, it provides a reasonably secure way for 3033 Version 3.0 servers to detect the attack. This solution is not 3034 secure against attackers who can brute force the key and substitute 3035 a new ENCRYPTED-KEY-DATA message containing the same key (but with 3036 normal padding) before the application specified wait threshold has 3037 expired. Parties concerned about attacks of this scale should not be 3038 using 40-bit encryption keys anyway. Altering the padding of the 3039 least-significant 8 bytes of the PKCS padding does not impact 3040 security, since this is essentially equivalent to increasing the 3041 input block size by 8 bytes. 3043 F.1.3 Detecting attacks against the handshake protocol 3045 An attacker might try to influence the handshake exchange to make 3046 the parties select different encryption algorithms than they would 3047 normally choose. Because many implementations will support 40-bit 3048 exportable encryption and some may even support null encryption or 3049 MAC algorithms, this attack is of particular concern. 3051 For this attack, an attacker must actively change one or more 3052 handshake messages. If this occurs, the client and server will 3053 compute different values for the handshake message hashes. As a 3054 result, the parties will not accept each others' finished messages. 3055 Without the master_secret, the attacker cannot repair the finished 3056 messages, so the attack will be discovered. 3058 F.1.4 Resuming sessions 3060 When a connection is established by resuming a session, new 3061 ClientHello.random and ServerHello.random values are hashed with the 3062 session's master_secret. Provided that the master_secret has not 3063 been compromised and that the secure hash operations used to produce 3064 the encryption keys and MAC secrets are secure, the connection 3065 should be secure and effectively independent from previous 3066 connections. Attackers cannot use known encryption keys or MAC 3067 secrets to compromise the master_secret without breaking the secure 3068 hash operations (which use both SHA and MD5). 3070 Sessions cannot be resumed unless both the client and server agree. 3071 If either party suspects that the session may have been compromised, 3072 or that certificates may have expired or been revoked, it should 3073 force a full handshake. An upper limit of 24 hours is suggested for 3074 session ID lifetimes, since an attacker who obtains a master_secret 3075 may be able to impersonate the compromised party until the 3076 corresponding session ID is retired. Applications that may be run in 3077 relatively insecure environments should not write session IDs to 3078 stable storage. 3080 F.1.5 MD5 and SHA 3082 TLS uses hash functions very conservatively. Where possible, both 3083 MD5 and SHA are used in tandem to ensure that non- catastrophic 3084 flaws in one algorithm will not break the overall protocol. 3086 F.2 Protecting application data 3088 The master_secret is hashed with the ClientHello.random and 3089 ServerHello.random to produce unique data encryption keys and MAC 3090 secrets for each connection. 3092 Outgoing data is protected with a MAC before transmission. To 3093 prevent message replay or modification attacks, the MAC is computed 3094 from the MAC secret, the sequence number, the message length, the 3095 message contents, and two fixed character strings. The message type 3096 field is necessary to ensure that messages intended for one TLS 3097 Record Layer client are not redirected to another. The sequence 3098 number ensures that attempts to delete or reorder messages will be 3099 detected. Since sequence numbers are 64-bits long, they should never 3100 overflow. Messages from one party cannot be inserted into the 3101 other's output, since they use independent MAC secrets. Similarly, 3102 the server-write and client-write keys are independent so stream 3103 cipher keys are used only once. 3105 If an attacker does break an encryption key, all messages encrypted 3106 with it can be read. Similarly, compromise of a MAC key can make 3107 message modification attacks possible. Because MACs are also 3108 encrypted, message-alteration attacks generally require breaking the 3109 encryption algorithm as well as the MAC. 3111 Note: 3112 MAC secrets may be larger than encryption keys, so messages 3113 can remain tamper resistant even if encryption keys are broken. 3115 F.3 Final notes 3117 For TLS to be able to provide a secure connection, both the client 3118 and server systems, keys, and applications must be secure. In 3119 addition, the implementation must be free of security errors. 3121 The system is only as strong as the weakest key exchange and 3122 authentication algorithm supported, and only trustworthy 3123 cryptographic functions should be used. Short public keys, 40-bit 3124 bulk encryption keys, and anonymous servers should be used with 3125 great caution. Implementations and users must be careful when 3126 deciding which certificates and certificate authorities are 3127 acceptable; a dishonest certificate authority can do tremendous 3128 damage. 3130 Appendix G 3132 G. Patent Statement 3134 This version of the TLS protocol relies on the use of patented 3135 public key encryption technology for authentication and encryption. 3136 The Internet Standards Process as defined in RFC 1310 requires a 3137 written statement from the Patent holder that a license will be made 3138 available to applicants under reasonable terms and conditions prior 3139 to approving a specification as a Proposed, Draft or Internet 3140 Standard. The Massachusetts Institute of Technology has granted RSA 3141 Data Security, Inc., exclusive sub-licensing rights to the following 3142 patent issued in the United States: 3144 Cryptographic Communications System and Method ("RSA"), 3145 No. 4,405,829 3147 The Board of Trustees of the Leland Stanford Junior University have 3148 granted Caro-Kann Corporation, a wholly owned subsidiary 3149 corporation, exclusive sub-licensing rights to the following patents 3150 issued in the United States, and all of their corresponding foreign 3151 patents: 3153 Cryptographic Apparatus and Method ("Diffie-Hellman"), No. 3154 4,200,770 3156 Public Key Cryptographic Apparatus and Method 3157 ("Hellman-Merkle"), No. 4,218,582 3159 The Internet Society, Internet Architecture Board, Internet 3160 Engineering Steering Group and the Corporation for National Research 3161 Initiatives take no position on the validity or scope of the patents 3162 and patent applications, nor on the appropriateness of the terms of 3163 the assurance. The Internet Society and other groups mentioned above 3164 have not made any determination as to any other intellectual 3165 property rights which may apply to the practice of this standard. 3166 Any further consideration of these matters is the user's own 3167 responsibility. 3169 References 3171 [SSL3] Frier, Karton and Kocher, 3172 internet-draft-tls-ssl-version3-00.txt: "The SSL 3.0 Protocol", 3173 Nov 18 1996. 3175 [DH1] W. Diffie and M. E. Hellman, "New Directions in Cryptography," 3176 IEEE Transactions on Information Theory, V. IT-22, n. 6, Jun 1977, 3177 pp. 74-84. 3179 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," 3180 IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. 3182 [DES] ANSI X3.106, "American National Standard for Information 3183 Systems-Data Link Encryption," American National Standards 3184 Institute, 1983. 3186 [DSS] NIST FIPS PUB 186, "Digital Signature Standard," National 3187 Institute of Standards and Technology, U.S. Department of Commerce, 3188 18 May 1994. 3190 [FTP] J. Postel and J. Reynolds, RFC 959: File Transfer Protocol, 3191 October 1985. 3193 [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer 3194 Protocol -- HTTP/1.0, October, 1995. 3196 [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH 3197 Series in Information Processing, v. 1, Konstanz: Hartung-Gorre 3198 Verlag, 1992. 3200 [KRAW] H. Krawczyk, IETF Draft: Keyed-MD5 for Message 3201 Authentication, November 1995. 3203 [MD2] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 3204 1992. 3206 [MD5] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 3207 1992. 3209 [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard," 3210 version 1.5, November 1993. 3212 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax 3213 Standard," version 1.5, November 1993. 3215 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax 3216 Standard," version 1.5, November 1993. 3218 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for 3219 Obtaining Digital Signatures and Public-Key Cryptosystems," 3220 Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120- 126. 3222 [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 [SCH] B. 3223 Schneier. Applied Cryptography: Protocols, Algorithms, and Source 3224 Code in C, Published by John Wiley & Sons, Inc. 1994. 3226 [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National 3227 Institute of Standards and Technology, U.S. Department of Commerce, 3228 DRAFT, 31 May 1994. [TCP] ISI for DARPA, RFC 793: Transport Control 3229 Protocol, September 1981. 3231 [TEL] J. Postel and J. Reynolds, RFC 854/5, May, 1993. [X509] CCITT. 3232 Recommendation X.509: "The Directory - Authentication Framework". 3233 1988. 3235 [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data 3236 Representation Standard, August 1995. 3238 Working Group Chair 3240 Win Treese 3241 Open Market 3242 treeseopenmarket.com 3244 Editors 3246 Tim Dierks Christopher Allen 3247 Consensus Development Consensus Development 3248 timd@consensus.com christophera@consensus.com 3250 Authors 3252 Alan O. Freier Paul C. Kocher 3253 Netscape Communications Independent Consultant 3254 freier@netscape.com pck@netcom.com 3256 Philip L. Karlton Tim Dierks 3257 Netscape Communications Consensus Development 3258 karlton@netscape.com timd@consensus.com 3260 Other contributors 3262 Martin Abadi Robert Relyea 3263 Digital Equipment Corporation Netscape Communications 3264 ma@pa.dec.com relyea@netscape.com 3266 Taher Elgamal Jim Roskind 3267 Netscape Communications Netscape Communications 3268 elgamal@netscape.com jar@netscape.com 3270 Anil Gangolli Micheal J. Sabin, Ph. D. 3271 Netscape Communications Consulting Engineer 3272 gangolli@netscape.com msabin@netcom.com 3274 Kipp E.B. Hickman Tom Weinstein 3275 Netscape Communications Netscape Communications 3276 kipp@netscape.com tomw@netscape.com 3278 Early reviewers 3280 Robert Baldwin Clyde Monma 3281 RSA Data Security, Inc. Bellcore 3282 baldwin@rsa.com clyde@bellcore.com 3283 George Cox Eric Murray 3284 Intel Corporation ericm@lne.com 3285 cox@ibeam.jf.intel.com 3287 Cheri Dowell Avi Rubin 3288 Sun Microsystems Bellcore 3289 cheri@eng.sun.com rubin@bellcore.com 3291 Stuart Haber Don Stephenson 3292 Bellcore Sun Microsystems 3293 stuart@bellcore.com don.stephenson@eng.sun.com 3295 Burt Kaliski Joe Tardo 3296 RSA Data Security, Inc. General Magic 3297 burt@rsa.com tardo@genmagic.com 3299 Comments 3301 Comments on this draft should be sent to the editors, Tim 3302 Dierks and Christopher Allen 3303 , or to the IETF Transport Layer 3304 Security (TLS) Working Group. 3306 The discussion list for IETF-TLS is at IETF-TLS@W3.ORG. You 3307 subscribe and unsubscribe by sending to IETF-TLS-REQUEST@W3.ORG 3308 with subscribe or unsubscribe in the SUBJECT of the message. 3310 Archives of the list are at 3311