idnits 2.17.1 draft-ietf-tls-ssl-version3-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-19) 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 2339 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 18, 1996) is 10014 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: 'RC4' is mentioned on line 159, but not defined -- Looks like a reference, but probably isn't: '0' on line 239 -- Looks like a reference, but probably isn't: '1' on line 239 -- Looks like a reference, but probably isn't: '3' on line 2569 -- Looks like a reference, but probably isn't: '9' on line 273 -- Looks like a reference, but probably isn't: '2' on line 1899 -- Looks like a reference, but probably isn't: '4' on line 307 -- Looks like a reference, but probably isn't: '8' on line 308 -- Looks like a reference, but probably isn't: '10' on line 400 -- Looks like a reference, but probably isn't: '20' on line 2033 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 951, but not defined -- Looks like a reference, but probably isn't: '28' on line 1894 -- Looks like a reference, but probably isn't: '128' on line 2005 -- Looks like a reference, but probably isn't: '16' on line 2032 -- Looks like a reference, but probably isn't: '46' on line 1996 -- Looks like a reference, but probably isn't: '40' on line 2006 -- Looks like a reference, but probably isn't: '12' on line 2008 -- Looks like a reference, but probably isn't: '24' on line 2011 -- Looks like a reference, but probably isn't: '48' on line 2012 == Missing Reference: 'IP' is mentioned on line 1772, but not defined -- Looks like a reference, but probably isn't: '7' on line 2214 == Missing Reference: 'SSL-2' is mentioned on line 2528, but not defined == Unused Reference: '3DES' is defined on line 2932, but no explicit reference was found in the text == Unused Reference: 'FTP' is defined on line 2946, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 2949, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 2952, but no explicit reference was found in the text == Unused Reference: 'KRAW' is defined on line 2956, but no explicit reference was found in the text == Unused Reference: 'MD2' is defined on line 2959, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 2962, but no explicit reference was found in the text == Unused Reference: 'SCH' is defined on line 2980, but no explicit reference was found in the text == Unused Reference: 'TEL' is defined on line 2990, but no explicit reference was found in the text -- 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. 'FOR' -- 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. 'SCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'X509' ** Obsolete normative reference: RFC 1832 (ref. 'XDR') (Obsoleted by RFC 4506) Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 37 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 Expire in six months Philip Karlton 4 Netscape Communications 5 Paul C. Kocher 6 Independent Consultant 7 November 18, 1996 9 The SSL Protocol 10 Version 3.0 12 14 Status of this memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet- Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or made obsolete by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as work in 25 progress. 27 To learn the current status of any Internet-Draft, please check the 28 1id-abstracts.txt listing contained in the Internet Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 31 Rim). 33 Abstract 35 This document specifies Version 3.0 of the Secure Sockets Layer 36 (SSL V3.0) protocol, a security protocol that provides 37 communications privacy over the Internet. The protocol allows 38 client/server applications to communicate in a way that is designed 39 to prevent eavesdropping, tampering, or message forgery. 41 Table of Contents 42 Status of this memo 1 43 Abstract 1 44 Table of Contents 2 45 1. Introduction 4 46 2. Goals 4 47 3. Goals of this document 5 48 4. Presentation language 5 49 4.1 Basic block size 5 50 4.2 Miscellaneous 6 51 4.3 Vectors 6 52 4.4 Numbers 7 53 4.5 Enumerateds 7 54 4.6 Constructed types 8 55 4.6.1 Variants 8 56 4.7 Cryptographic attributes 9 57 4.8 Constants 10 58 5. SSL protocol 10 59 5.1 Session and connection states 10 60 5.2 Record layer 12 61 5.2.1 Fragmentation 12 62 5.2.2 Record compression and decompression 13 63 5.2.3 Record payload protection and the CipherSpec 13 64 5.2.3.1 Null or standard stream cipher 14 65 5.2.3.2 CBC block cipher 15 66 5.3 Change cipher spec protocol 16 67 5.4 Alert protocol 16 68 5.4.1 Closure alerts 17 69 5.4.2 Error alerts 17 70 5.5 Handshake protocol overview 18 71 5.6 Handshake protocol 20 72 5.6.1 Hello messages 21 73 5.6.1.1 Hello request 21 74 5.6.1.2 Client hello 21 75 5.6.1.3 Server hello 24 76 5.6.2 Server certificate 25 77 5.6.3 Server key exchange message 25 78 5.6.4 Certificate request 27 79 5.6.5 Server hello done 27 80 5.6.6 Client certificate 28 81 5.6.7 Client key exchange message 28 82 5.6.7.1 RSA encrypted premaster secret message 28 83 5.6.7.2 FORTEZZA key exchange message 29 84 5.6.7.3 Client Diffie-Hellman public value 30 85 5.6.8 Certificate verify 30 86 5.6.9 Finished 31 87 5.7 Application data protocol 32 88 6. Cryptographic computations 32 89 6.1 Asymmetric cryptographic computations 32 90 6.1.1 RSA 32 91 6.1.2 Diffie-Hellman 33 92 6.1.3 FORTEZZA 33 93 6.2 Symmetric cryptographic calculations and the CipherSpec 33 94 6.2.1 The master secret 33 95 6.2.2 Converting the master secret into keys and MAC 33 96 6.2.2.1 Export key generation example 35 97 A. Protocol constant values 36 98 A.1 Reserved port assignments 36 99 A.1.1 Record layer 36 100 A.2 Change cipher specs message 37 101 A.3 Alert messages 37 102 A.4 Handshake protocol 37 103 A.4.1 Hello messages 38 104 A.4.2 Server authentication and key exchange messages 39 105 A.5 Client authentication and key exchange messages 40 106 A.5.1 Handshake finalization message 41 107 A.6 The CipherSuite 41 108 A.7 The CipherSpec 42 109 B. Glossary 44 110 C. CipherSuite definitions 47 111 D. Implementation Notes 49 112 D.1 Temporary RSA keys 49 113 D.2 Random Number Generation and Seeding 49 114 D.3 Certificates and authentication 50 115 D.4 CipherSuites 50 116 D.5 FORTEZZA 50 117 D.5.1 Notes on use of FORTEZZA hardware 50 118 D.5.2 FORTEZZA Ciphersuites 51 119 D.5.3 FORTEZZA Session resumption 51 120 E. Version 2.0 Backward Compatibility 52 121 E.1 Version 2 client hello 52 122 E.2 Avoiding man-in-the-middle version rollback 53 123 F. Security analysis 55 124 F.1 Handshake protocol 55 125 F.1.1 Authentication and key exchange 55 126 F.1.1.1 Anonymous key exchange 55 127 F.1.1.2 RSA key exchange and authentication 56 128 F.1.1.3 Diffie-Hellman key exchange with authentication 57 129 F.1.1.4 FORTEZZA 57 130 F.1.2 Version rollback attacks 57 131 F.1.3 Detecting attacks against the handshake protocol 58 132 F.1.4 Resuming sessions 58 133 F.1.5 MD5 and SHA 58 134 F.2 Protecting application data 59 135 F.3 Final notes 59 136 G. Patent Statement 60 137 References 61 138 Authors 62 140 1. Introduction 142 The primary goal of the SSL Protocol is to provide privacy and 143 reliability between two communicating applications. The protocol 144 is composed of two layers. At the lowest level, layered on top of 145 some reliable transport protocol (e.g., TCP[TCP]), is the SSL 146 Record Protocol. The SSL Record Protocol is used for encapsulation 147 of various higher level protocols. One such encapsulated protocol, 148 the SSL Handshake Protocol, allows the server and client to 149 authenticate each other and to negotiate an encryption algorithm 150 and cryptographic keys before the application protocol transmits or 151 receives its first byte of data. One advantage of SSL is that it 152 is application protocol independent. A higher level protocol can 153 layer on top of the SSL Protocol transparently. The SSL protocol 154 provides connection security that has three basic properties: 156 - The connection is private. Encryption is used after an 157 initial handshake to define a secret key. Symmetric 158 cryptography is used for data encryption (e.g., DES[DES], 159 RC4[RC4], etc.) 160 - The peer's identity can be authenticated using asymmetric, or 161 public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.). 162 - The connection is reliable. Message transport includes a 163 message integrity check using a keyed MAC. Secure hash 164 functions (e.g., SHA, MD5, etc.) are used for MAC 165 computations. 167 2. Goals 169 The goals of SSL Protocol v3.0, in order of their priority, 170 are: 171 1. Cryptographic security 172 SSL should be used to establish a secure 173 connection between two parties. 174 2. Interoperability 175 Independent programmers should be able to 176 develop applications utilizing SSL 3.0 that 177 will then be able to successfully exchange 178 cryptographic parameters without knowledge of 179 one another's code. 181 Note: It is not the case that all instances of SSL (even 182 in the same application domain) will be able to 183 successfully connect. For instance, if the server 184 supports a particular hardware token, and the client 185 does not have access to such a token, then the 186 connection will not succeed. 188 3. Extensibility SSL seeks to provide a framework into which new 189 public key and bulk encryption methods can be 190 incorporated as necessary. This will also 191 accomplish two sub-goals: to prevent the need 192 to create a new protocol (and risking the 193 introduction of possible new weaknesses) and to 194 avoid the need to implement an entire new 195 security library. 196 4. Relative efficiency 197 Cryptographic operations tend to be highly CPU 198 intensive, particularly public key operations. 199 For this reason, the SSL protocol has 200 incorporated an optional session caching scheme 201 to reduce the number of connections that need 202 to be established from scratch. Additionally, 203 care has been taken to reduce network activity. 205 3. Goals of this document 207 The SSL Protocol Version 3.0 Specification is intended primarily 208 for readers who will be implementing the protocol and those doing 209 cryptographic analysis of it. The spec has been written with this 210 in mind, and it is intended to reflect the needs of those two 211 groups. For that reason, many of the algorithm-dependent data 212 structures and rules are included in the body of the text (as 213 opposed to in an Appendix), providing easier access to them. 215 This document is not intended to supply any details of service 216 definition nor interface definition, although it does cover select 217 areas of policy as they are required for the maintenance of solid 218 security. 220 4. Presentation language 222 This document deals with the formatting of data in an external 223 representation. The following very basic and somewhat casually 224 defined presentation syntax will be used. The syntax draws from 225 several sources in its structure. Although it resembles the 226 programming language "C" in its syntax and XDR [XDR] in both its 227 syntax and intent, it would be risky to draw too many parallels. 228 The purpose of this presentation language is to document SSL only, 229 not to have general application beyond that particular goal. 231 4.1 Basic block size 233 The representation of all data items is explicitly specified. The 234 basic data block size is one byte (i.e. 8 bits). Multiple byte 235 data items are concatenations of bytes, from left to right, from 236 top to bottom. From the bytestream a multi-byte item (a numeric in 237 the example) is formed (using C notation) by: 239 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ... 240 | byte[n-1]; 242 This byte ordering for multi-byte values is the commonplace network 243 byte order or big endian format. 245 4.2 Miscellaneous 247 Comments begin with "/*" and end with "*/". 248 Optional components are denoted by enclosing them in "[[ ]]" double 249 brackets. 250 Single byte entities containing uninterpreted data are of type 251 opaque. 253 4.3 Vectors 255 A vector (single dimensioned array) is a stream of homogeneous data 256 elements. The size of the vector may be specified at documentation 257 time or left unspecified until runtime. In either case the length 258 declares the number of bytes, not the number of elements, in the 259 vector. The syntax for specifying a new type T' that is a fixed 260 length vector of type T is 262 T T'[n]; 264 Here T' occupies n bytes in the data stream, where n is a multiple 265 of the size of T. The length of the vector is not included in the 266 encoded stream. 268 In the following example, Datum is defined to be three consecutive 269 bytes that the protocol does not interpret, while Data is three 270 consecutive Datum, consuming a total of nine bytes. 272 opaque Datum[3]; /* three uninterpreted bytes */ 273 Datum Data[9]; /* 3 consecutive 3 byte vectors */ 275 Variable length vectors are defined by specifying a subrange of 276 legal lengths, inclusively, using the notation . 277 When encoded, the actual length precedes the vector's contents in 278 the byte stream. The length will be in the form of a number 279 consuming as many bytes as required to hold the vector's specified 280 maximum (ceiling) length. A variable length vector with an actual 281 length field of zero is referred to as an empty vector. 283 T T'; 285 In the following example, mandatory is a vector that must contain 286 between 300 and 400 bytes of type opaque. It can never be empty. 287 The actual length field consumes two bytes, a uint16, sufficient to 288 represent the value 400 (see Section 4.4). On the other hand, 289 longer can represent up to 800 bytes of data, or 400 uint16 290 elements, and it may be empty. Its encoding will include a two 291 byte actual length field prepended to the vector. 293 opaque mandatory<300..400>; 294 /* length field is 2 bytes, cannot be empty */ 295 uint16 longer<0..800>; 296 /* zero to 400 16-bit unsigned integers */ 298 4.4 Numbers 300 The basic numeric data type is an unsigned byte (uint8). All 301 larger numeric data types are formed from fixed length series of 302 bytes concatenated as described in Section 4.1 and are also 303 unsigned. The following numeric types are predefined. 305 uint8 uint16[2]; 306 uint8 uint24[3]; 307 uint8 uint32[4]; 308 uint8 uint64[8]; 310 4.5 Enumerateds 312 An additional sparse data type is available called enum. A field 313 of type enum can only assume the values declared in the definition. 314 Each definition is a different type. Only enumerateds of the same 315 type may be assigned or compared. Every element of an enumerated 316 must be assigned a value, as demonstrated in the following example. 317 Since the elements of the enumerated are not ordered, they can be 318 assigned any unique value, in any order. 320 enum { e1(v1), e2(v2), ... , en(vn), [[(n)]] } Te; 322 Enumerateds occupy as much space in the byte stream as would its 323 maximal defined ordinal value. The following definition would 324 cause one byte to be used to carry fields of type Color. 326 enum { red(3), blue(5), white(7) } Color; 328 One may optionally specify a value without its associated tag to 329 force the width definition without defining a superfluous element. 330 In the following example, Taste will consume two bytes in the data 331 stream but can only assume the values 1, 2 or 4. 333 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 335 The names of the elements of an enumeration are scoped within the 336 defined type. In the first example, a fully qualified reference to 337 the second element of the enumeration would be Color.blue. Such 338 qualification is not required if the target of the assignment is 339 well specified. 341 Color color = Color.blue; /* overspecified, legal */ 342 Color color = blue; /* correct, type implicit */ 344 For enumerateds that are never converted to external 345 representation, the numerical information may be omitted. 347 enum { low, medium, high } Amount; 349 4.6 Constructed types 351 Structure types may be constructed from primitive types for 352 convenience. Each specification declares a new, unique type. The 353 syntax for definition is much like that of C. 355 struct { 356 T1 f1; 357 T2 f2; 358 ... 359 Tn fn; 360 } [[T]]; 362 The fields within a structure may be qualified using the type's 363 name using a syntax much like that available for enumerateds. For 364 example, T.f2 refers to the second field of the previous 365 declaration. Structure definitions may be embedded. 367 4.6.1 Variants 369 Defined structures may have variants based on some knowledge that 370 is available within the environment. The selector must be an 371 enumerated type that defines the possible variants the structure 372 defines. There must be a case arm for every element of the 373 enumeration declared in the select. The body of the variant 374 structure may be given a label for reference. The mechanism by 375 which the variant is selected at runtime is not prescribed by the 376 presentation language. 378 struct { 379 T1 f1; 380 T2 f2; 381 .... 382 Tn fn; 383 select (E) { 384 case e1: Te1; 385 case e2: Te2; 386 .... 387 case en: Ten; 388 } [[fv]]; 389 } [[Tv]]; 391 For example 393 enum { apple, orange } VariantTag; 394 struct { 395 uint16 number; 396 opaque string<0..10>; /* variable length */ 397 } V1; 398 struct { 399 uint32 number; 400 opaque string[10]; /* fixed length */ 401 } V2; 402 struct { 403 select (VariantTag) { /* value of selector is implicit */ 404 case apple: V1; /* VariantBody, tag = apple */ 405 case orange: V2; /* VariantBody, tag = orange */ 406 } variant_body; /* optional label on variant */ 407 } VariantRecord; 409 Variant structures may be qualified (narrowed) by specifying a 410 value for the selector prior to the type. For example, a 412 orange VariantRecord 414 is a narrowed type of a VariantRecord containing a variant_body of 415 type V2. 417 4.7 Cryptographic attributes 419 The four cryptographic operations digital signing, stream cipher 420 encryption, block cipher encryption, and public key encryption are 421 designated digitally-signed, stream-ciphered, block-ciphered, and 422 public-key-encrypted, respectively. A field's cryptographic 423 processing is specified by prepending an appropriate key word 424 designation before the field's type specification. Cryptographic 425 keys are implied by the current session state (see Section 5.1). 427 In digital signing, one-way hash functions are used as input for a 428 signing algorithm. In RSA signing, a 36-byte structure of two 429 hashes (one SHA and one MD5) is signed (encrypted with the private 430 key). In DSS, the 20 bytes of the SHA hash are run directly 431 through the Digital Signing Algorithm with no additional hashing. 433 In stream cipher encryption, the plaintext is exclusive-ORed with 434 an identical amount of output generated from a 435 cryptographically-secure keyed pseudorandom number generator. 437 In block cipher encryption, every block of plaintext encrypts to a 438 block of ciphertext. Because it is unlikely that the plaintext 439 (whatever data is to be sent) will break neatly into the necessary 440 block size (usually 64 bits), it is necessary to pad out the end of 441 short blocks with some regular pattern, usually all zeroes. 443 In public key encryption, one-way functions with secret "trapdoors" 444 are used to encrypt the outgoing data. Data encrypted with the 445 public key of a given key pair can only be decrypted with the 446 private key, and vice-versa. In the following example: 448 stream-ciphered struct { 449 uint8 field1; 450 uint8 field2; 451 digitally-signed opaque hash[20]; 452 } UserType; 454 The contents of hash are used as input for the signing algorithm, 455 then the entire structure is encrypted with a stream cipher. 457 4.8 Constants 459 Typed constants can be defined for purposes of specification by 460 declaring a symbol of the desired type and assigning values to it. 461 Under-specified types (opaque, variable length vectors, and 462 structures that contain opaque) cannot be assigned values. No 463 fields of a multi-element structure or vector may be elided. 465 For example, 466 struct { 467 uint8 f1; 468 uint8 f2; 469 } Example1; 471 Example1 ex1 = {1, 4};/* assigns f1 = 1, f2 = 4 */ 473 5. SSL protocol 475 SSL is a layered protocol. At each layer, messages may include 476 fields for length, description, and content. SSL takes messages to 477 be transmitted, fragments the data into manageable blocks, 478 optionally compresses the data, applies a MAC, encrypts, and 479 transmits the result. Received data is decrypted, verified, 480 decompressed, and reassembled, then delivered to higher level 481 clients. 483 5.1 Session and connection states 485 An SSL session is stateful. It is the responsibility of the SSL 486 Handshake protocol to coordinate the states of the client and 487 server, thereby allowing the protocol state machines of each to 488 operate consistently, despite the fact that the state is not 489 exactly parallel. Logically the state is represented twice, once 490 as the current operating state, and (during the handshake protocol) 491 again as the pending state. Additionally, separate read and write 492 states are maintained. When the client or server receives a change 493 cipher spec message, it copies the pending read state into the 494 current read state. When the client or server sends a change 495 cipher spec message, it copies the pending write state into the 496 current write state. When the handshake negotiation is complete, 497 the client and server exchange change cipher spec messages (see 498 Section 5.3), and they then communicate using the newly agreed-upon 499 cipher spec. 501 An SSL session may include multiple secure connections; in 502 addition, parties may have multiple simultaneous sessions. 504 The session state includes the following elements: 506 session identifier 507 An arbitrary byte sequence chosen by the server 508 to identify an active or resumable session 509 state. 510 peer certificate X509.v3[X509] certificate of the peer. This 511 element of the state may be null. 512 compression method 513 The algorithm used to compress data prior to 514 encryption. 515 cipher spec Specifies the bulk data encryption algorithm 516 (such as null, DES, etc.) and a MAC algorithm 517 (such as MD5 or SHA). It also defines 518 cryptographic attributes such as the hash_size. 519 (See Appendix A.7 for formal definition) 520 master secret 48-byte secret shared between the client and 521 server. 522 is resumable A flag indicating whether the session can be 523 used to initiate new connections. 525 The connection state includes the following elements: 527 server and client random 528 Byte sequences that are chosen by the server 529 and client for each connection. 530 server write MAC secret 531 The secret used in MAC operations on data 532 written by the server 533 client write MAC secret 534 The secret used in MAC operations on data 535 written by the client. 536 server write key The bulk cipher key for data encrypted by the 537 server and decrypted by the client. 538 client write key The bulk cipher key for data encrypted by the 539 client and decrypted by the server. 540 initialization vectors 541 When a block cipher in CBC mode is used, an 542 initialization vector (IV) is maintained for 543 each key. This field is first initialized by 544 the SSL handshake protocol. Thereafter the 545 final ciphertext block from each record is 546 preserved for use with the following record. 547 sequence numbers Each party maintains separate sequence numbers 548 for transmitted and received messages for each 549 connection. When a party sends or receives a 550 change cipher spec message, the appropriate 551 sequence number is set to zero. Sequence 552 numbers are of type uint64 and may not exceed 553 2^64-1. 555 5.2 Record layer 557 The SSL Record Layer receives uninterpreted data from higher layers 558 in non-empty blocks of arbitrary size. 560 5.2.1 Fragmentation 562 The record layer fragments information blocks into SSLPlaintext 563 records of 2^14 bytes or less. Client message boundaries are not 564 preserved in the record layer (i.e., multiple client messages of 565 the same ContentType may be coalesced into a single SSLPlaintext 566 record). 568 struct { 569 uint8 major, minor; 570 } ProtocolVersion; 572 enum { 573 change_cipher_spec(20), alert(21), handshake(22), 574 application_data(23), (255) 575 } ContentType; 577 struct { 578 ContentType type; 579 ProtocolVersion version; 580 uint16 length; 581 opaque fragment[SSLPlaintext.length]; 582 } SSLPlaintext; 584 type The higher level protocol used to process the 585 enclosed fragment. 586 version The version of protocol being employed. This 587 document describes SSL Version 3.0 (See 588 Appendix A.1.1). 589 length The length (in bytes) of the following 590 SSLPlaintext.fragment. The length should not 591 exceed 2^14. 592 fragment The application data. This data is transparent 593 and treated as an independent block to be dealt 594 with by the higher level protocol specified by 595 the type field. 597 Note: Data of different SSL Record layer content types may 598 be interleaved. Application data is generally of 599 lower precedence for transmission than other content 600 types. 602 5.2.2 Record compression and decompression 604 All records are compressed using the compression algorithm defined 605 in the current session state. There is always an active 606 compression algorithm, however initially it is defined as 607 CompressionMethod.null. The compression algorithm translates an 608 SSLPlaintext structure into an SSLCompressed structure. 609 Compression functions erase their state information whenever the 610 CipherSpec is replaced. 612 Note: The CipherSpec is part of the session state 613 described in Section 5.1. References to fields of 614 the CipherSpec are made throughout this document 615 using presentation syntax. A more complete 616 description of the CipherSpec is shown in Appendix 617 A.7. 619 Compression must be lossless and may not increase the content 620 length by more than 1024 bytes. If the decompression function 621 encounters an SSLCompressed.fragment that would decompress to a 622 length in excess of 2^14 bytes, it should issue a fatal 623 decompression_failure alert (Section 5.4.2). 625 struct { 626 ContentType type; /* same as SSLPlaintext.type */ 627 ProtocolVersion version;/* same as SSLPlaintext.version */ 628 uint16 length; 629 opaque fragment[SSLCompressed.length]; 630 } SSLCompressed; 632 length The length (in bytes) of the following 633 SSLCompressed.fragment. The length 634 should not exceed 2^14 + 1024. 635 fragment The compressed form of 636 SSLPlaintext.fragment. 638 Note: A CompressionMethod.null operation is an identity 639 operation; no fields are altered. 640 (See Appendix A.4.1) 642 Implementation note: 643 Decompression functions are responsible for 644 ensuring that messages cannot cause internal buffer 645 overflows. 647 5.2.3 Record payload protection and the CipherSpec 649 All records are protected using the encryption and MAC algorithms 650 defined in the current CipherSpec. There is always an active 651 CipherSpec, however initially it is SSL_NULL_WITH_NULL_NULL, which 652 does not provide any security. 654 Once the handshake is complete, the two parties have shared secrets 655 which are used to encrypt records and compute keyed message 656 authentication codes (MACs) on their contents. The techniques used 657 to perform the encryption and MAC operations are defined by the 658 CipherSpec and constrained by CipherSpec.cipher_type. The 659 encryption and MAC functions translate an SSLCompressed structure 660 into an SSLCiphertext. The decryption functions reverse the 661 process. Transmissions also include a sequence number so that 662 missing, altered, or extra messages are detectable. 664 struct { 665 ContentType type; 666 ProtocolVersion version; 667 uint16 length; 668 select (CipherSpec.cipher_type) { 669 case stream: GenericStreamCipher; 670 case block: GenericBlockCipher; 671 } fragment; 672 } SSLCiphertext; 674 type The type field is identical to 675 SSLCompressed.type. 676 version The version field is identical to 677 SSLCompressed.version. 678 length The length (in bytes) of the following 679 SSLCiphertext.fragment. The length may 680 not exceed 2^14 + 2048. 681 fragment The encrypted form of 682 SSLCompressed.fragment, including the 683 MAC. 685 5.2.3.1 Null or standard stream cipher 687 Stream ciphers (including BulkCipherAlgorithm.null - see Appendix 688 A.7) convert SSLCompressed.fragment structures to and from stream 689 SSLCiphertext.fragment structures. 691 stream-ciphered struct { 692 opaque content[SSLCompressed.length]; 693 opaque MAC[CipherSpec.hash_size]; 694 } GenericStreamCipher; 696 The MAC is generated as: 698 hash(MAC_write_secret + pad_2 + 699 hash(MAC_write_secret + pad_1 + seq_num + 700 SSLCompressed.type + SSLCompressed.length + 701 SSLCompressed.fragment)); 703 where "+" denotes concatenation. 705 pad_1 The character 0x36 repeated 48 times for MD5 706 or 40 times for SHA. 707 pad_2 The character 0x5c repeated 48 times for MD5 708 or 40 times for SHA. 709 seq_num The sequence number for this message. 710 hash Hashing algorithm derived from the cipher 711 suite. 713 Note that the MAC is computed before encryption. The stream cipher 714 encrypts the entire block, including the MAC. For stream ciphers 715 that do not use a synchronization vector (such as RC4), the stream 716 cipher state from the end of one record is simply used on the 717 subsequent packet. If the CipherSuite is SSL_NULL_WITH_NULL_NULL, 718 encryption consists of the identity operation (i.e., the data is 719 not encrypted and the MAC size is zero implying that no MAC is 720 used). SSLCiphertext.length is SSLCompressed.length plus 721 CipherSpec.hash_size. 723 5.2.3.2 CBC block cipher 725 For block ciphers (such as RC2 or DES), the encryption and MAC 726 functions convert SSLCompressed.fragment structures to and from 727 block SSLCiphertext.fragment structures. 729 block-ciphered struct { 730 opaque content[SSLCompressed.length]; 731 opaque MAC[CipherSpec.hash_size]; 732 uint8 padding[GenericBlockCipher.padding_length]; 733 uint8 padding_length; 734 } GenericBlockCipher; 736 The MAC is generated as described in Section 5.2.3.1. 738 padding Padding that is added to force the length of 739 the plaintext to be a multiple of the block 740 cipher's block length. 741 padding_length The length of the padding must be less than the 742 cipher's block length and may be zero. The 743 padding length should be such that the total 744 size of the GenericBlockCipher structure is a 745 multiple of the cipher's block length. 747 The encrypted data length (SSLCiphertext.length) is one more than 748 the sum of SSLCompressed.length, CipherSpec.hash_size, and 749 padding_length. 751 Note: With CBC block chaining the initialization vector 752 (IV) for the first record is provided by the 753 handshake protocol. The IV for subsequent records 754 is the last ciphertext block from the previous 755 record. 757 5.3 Change cipher spec protocol 759 The change cipher spec protocol exists to signal transitions in 760 ciphering strategies. The protocol consists of a single message, 761 which is encrypted and compressed under the current (not the 762 pending) CipherSpec. The message consists of a single byte of 763 value 1. 765 struct { 766 enum { change_cipher_spec(1), (255) } type; 767 } ChangeCipherSpec; 769 The change cipher spec message is sent by both the client and 770 server to notify the receiving party that subsequent records will 771 be protected under the just-negotiated CipherSpec and keys. 772 Reception of this message causes the receiver to copy the read 773 pending state into the read current state. The client sends a 774 change cipher spec message following handshake key exchange and 775 certificate verify messages (if any), and the server sends one 776 after successfully processing the key exchange message it received 777 from the client. An unexpected change cipher spec message should 778 generate an unexpected_message alert (Section 5.4.2). When 779 resuming a previous session, the change cipher spec message is sent 780 after the hello messages. 782 5.4 Alert protocol 784 One of the content types supported by the SSL Record layer is the 785 alert type. Alert messages convey the severity of the message and 786 a description of the alert. Alert messages with a level of fatal 787 result in the immediate termination of the connection. In this 788 case, other connections corresponding to the session may continue, 789 but the session identifier must be invalidated, preventing the 790 failed session from being used to establish new connections. Like 791 other messages, alert messages are encrypted and compressed, as 792 specified by the current connection state. 794 enum { warning(1), fatal(2), (255) } AlertLevel; 796 enum { 797 close_notify(0), 798 unexpected_message(10), 799 bad_record_mac(20), 800 decompression_failure(30), 801 handshake_failure(40), 802 no_certificate(41), 803 bad_certificate(42), 804 unsupported_certificate(43), 805 certificate_revoked(44), 806 certificate_expired(45), 807 certificate_unknown(46), 808 illegal_parameter (47) 809 (255) 810 } AlertDescription; 812 struct { 813 AlertLevel level; 814 AlertDescription description; 815 } Alert; 817 5.4.1 Closure alerts 819 The client and the server must share knowledge that the connection 820 is ending in order to avoid a truncation attack. Either party may 821 initiate the exchange of closing messages. 823 close_notify This message notifies the recipient that the 824 sender will not send any more messages on this 825 connection. The session becomes unresumable if 826 any connection is terminated without proper 827 close_notify messages with level equal to 828 warning. 830 Either party may initiate a close by sending a close_notify alert. 831 Any data received after a closure alert is ignored. 833 Each party is required to send a close_notify alert before closing 834 the write side of the connection. It is required that the other 835 party respond with a close_notify alert of its own and close down 836 the connection immediately, discarding any pending writes. It is 837 not required for the initiator of the close to wait for the 838 responding close_notify alert before closing the read side of the 839 connection. 841 NB: It is assumed that closing a connection reliably delivers 842 pending data before destroying the transport. 844 5.4.2 Error alerts 846 Error handling in the SSL Handshake protocol is very simple. When 847 an error is detected, the detecting party sends a message to the 848 other party. Upon transmission or receipt of an fatal alert 849 message, both parties immediately close the connection. Servers 850 and clients are required to forget any session-identifiers, keys, 851 and secrets associated with a failed connection. The following 852 error alerts are defined: 854 unexpected_message 855 An inappropriate message was received. This 856 alert is always fatal and should never be 857 observed in communication between proper 858 implementations. 860 bad_record_mac This alert is returned if a record is received 861 with an incorrect MAC. This message is always 862 fatal. 863 decompression_failure 864 The decompression function received improper 865 input (e.g. data that would expand to excessive 866 length). This message is always fatal. 867 handshake_failure Reception of a handshake_failure alert message 868 indicates that the sender was unable to 869 negotiate an acceptable set of security 870 parameters given the options available. This 871 is a fatal error. 872 no_certificate A no_certificate alert message may be sent in 873 response to a certification request if no 874 appropriate certificate is available. 875 bad_certificate A certificate was corrupt, contained signatures 876 that did not verify correctly, etc. 877 unsupported_certificate 878 A certificate was of an unsupported type. 879 certificate_revoked 880 A certificate was revoked by its signer. 881 certificate_expired 882 A certificate has expired or is not currently 883 valid. 884 certificate_unknown 885 Some other (unspecified) issue arose in 886 processing the certificate, rendering it 887 unacceptable. 888 illegal_parameter A field in the handshake was out of range or 889 inconsistent with other fields. This is always 890 fatal. 892 5.5 Handshake protocol overview 894 The cryptographic parameters of the session state are produced by 895 the SSL Handshake Protocol, which operates on top of the SSL Record 896 Layer. When a SSL client and server first start communicating, 897 they agree on a protocol version, select cryptographic algorithms, 898 optionally authenticate each other, and use public-key encryption 899 techniques to generate shared secrets. These processes are 900 performed in the handshake protocol, which can be summarized as 901 follows: The client sends a client hello message to which the 902 server must respond with a server hello message, or else a fatal 903 error will occur and the connection will fail. The client hello 904 and server hello are used to establish security enhancement 905 capabilities between client and server. The client hello and 906 server hello establish the following attributes: Protocol Version, 907 Session ID, Cipher Suite, and Compression Method. Additionally, 908 two random values are generated and exchanged: ClientHello.random 909 and ServerHello.random. 911 Following the hello messages, the server will send its certificate, 912 if it is to be authenticated. Additionally, a server key exchange 913 message may be sent, if it is required (e.g. if their server has no 914 certificate, or if its certificate is for signing only). If the 915 server is authenticated, it may request a certificate from the 916 client, if that is appropriate to the cipher suite selected. Now 917 the server will send the server hello done message, indicating that 918 the hello-message phase of the handshake is complete. The server 919 will then wait for a client response. If the server has sent a 920 certificate request Message, the client must send either the 921 certificate message or a no_certificate alert. The client key 922 exchange message is now sent, and the content of that message will 923 depend on the public key algorithm selected between the client 924 hello and the server hello. If the client has sent a certificate 925 with signing ability, a digitally-signed certificate verify message 926 is sent to explicitly verify the certificate. 928 At this point, a change cipher spec message is sent by the client, 929 and the client copies the pending Cipher Spec into the current 930 Cipher Spec. The client then immediately sends the finished 931 message under the new algorithms, keys, and secrets. In response, 932 the server will send its own change cipher spec message, transfer 933 the pending to the current Cipher Spec, and send its finished 934 message under the new Cipher Spec. At this point, the handshake is 935 complete and the client and server may begin to exchange 936 application layer data. (See flow chart below.) 938 Client Server 940 ClientHello --------> 941 ServerHello 942 Certificate* 943 ServerKeyExchange* 944 CertificateRequest* 945 <-------- ServerHelloDone 946 Certificate* 947 ClientKeyExchange 948 CertificateVerify* 949 [ChangeCipherSpec] 950 Finished --------> 951 [ChangeCipherSpec] 952 <-------- Finished 953 Application Data <-------> Application Data 955 * Indicates optional or situation-dependent messages that are not 956 always sent. 958 Note: To help avoid pipeline stalls, ChangeCipherSpec is 959 an independent SSL Protocol content type, and is not 960 actually an SSL handshake message. 962 When the client and server decide to resume a previous session or 963 duplicate an existing session (instead of negotiating new security 964 parameters) the message flow is as follows: 966 The client sends a ClientHello using the Session ID of the session 967 to be resumed. The server then checks its session cache for a 968 match. If a match is found, and the server is willing to 969 re-establish the connection under the specified session state, it 970 will send a ServerHello with the same Session ID value. At this 971 point, both client and server must send change cipher spec messages 972 and proceed directly to finished messages. Once the 973 re-establishment is complete, the client and server may begin to 974 exchange application layer data. (See flow chart below.) If a 975 Session ID match is not found, the server generates a new session 976 ID and the SSL client and server perform a full handshake. 978 Client Server 980 ClientHello --------> 981 ServerHello 982 [change cipher spec] 983 <-------- Finished 984 change cipher spec 985 Finished --------> 986 Application Data <-------> Application Data 988 The contents and significance of each message will be presented in 989 detail in the following sections. 991 5.6 Handshake protocol 993 The SSL Handshake Protocol is one of the defined higher level 994 clients of the SSL Record Protocol. This protocol is used to 995 negotiate the secure attributes of a session. Handshake messages 996 are supplied to the SSL Record Layer, where they are encapsulated 997 within one or more SSLPlaintext structures, which are processed and 998 transmitted as specified by the current active session state. 1000 enum { 1001 hello_request(0), client_hello(1), server_hello(2), 1002 certificate(11), server_key_exchange (12), 1003 certificate_request(13), server_hello_done(14), 1004 certificate_verify(15), client_key_exchange(16), 1005 finished(20), (255) 1006 } HandshakeType; 1008 struct { 1009 HandshakeType msg_type; /* handshake type */ 1010 uint24 length; /* bytes in message */ 1011 select (HandshakeType) { 1012 case hello_request: HelloRequest; 1013 case client_hello: ClientHello; 1014 case server_hello: ServerHello; 1015 case certificate: Certificate; 1016 case server_key_exchange: ServerKeyExchange; 1017 case certificate_request: CertificateRequest; 1018 case server_hello_done: ServerHelloDone; 1019 case certificate_verify: CertificateVerify; 1020 case client_key_exchange: ClientKeyExchange; 1021 case finished: Finished; 1022 } body; 1023 } Handshake; 1025 The handshake protocol messages are presented in the order they 1026 must be sent; sending handshake messages in an unexpected order 1027 results in a fatal error. 1029 5.6.1 Hello messages 1031 The hello phase messages are used to exchange security enhancement 1032 capabilities between the client and server. When a new session 1033 begins, the CipherSpec encryption, hash, and compression algorithms 1034 are initialized to null. The current CipherSpec is used for 1035 renegotiation messages. 1037 5.6.1.1 Hello request 1039 The hello request message may be sent by the server at any time, 1040 but will be ignored by the client if the handshake protocol is 1041 already underway. It is a simple notification that the client 1042 should begin the negotiation process anew by sending a client hello 1043 message when convenient. 1045 Note: Since handshake messages are intended to have 1046 transmission precedence over application data, it is 1047 expected that the negotiation begin in no more than 1048 one or two times the transmission time of a maximum 1049 length application data message. 1051 After sending a hello request, servers should not repeat the 1052 request until the subsequent handshake negotiation is complete. A 1053 client that receives a hello request while in a handshake 1054 negotiation state should simply ignore the message. 1056 The structure of a hello request message is as follows: 1058 struct { } HelloRequest; 1060 5.6.1.2 Client hello 1062 When a client first connects to a server it is required to send the 1063 client hello as its first message. The client can also send a 1064 client hello in response to a hello request or on its own 1065 initiative in order to renegotiate the security parameters in an 1066 existing connection. The client hello message includes a random 1067 structure, which is used later in the protocol. 1069 struct { 1070 uint32 gmt_unix_time; 1071 opaque random_bytes[28]; 1072 } Random; 1074 gmt_unix_time The current time and date in standard UNIX 1075 32-bit format according to the sender's 1076 internal clock. Clocks are not required to be 1077 set correctly by the basic SSL Protocol; higher 1078 level or application protocols may define 1079 additional requirements. 1080 random_bytes 28 bytes generated by a secure random number 1081 generator. 1083 The client hello message includes a variable length session 1084 identifier. If not empty, the value identifies a session between 1085 the same client and server whose security parameters the client 1086 wishes to reuse. The session identifier may be from an earlier 1087 connection, this connection, or another currently active 1088 connection. The second option is useful if the client only wishes 1089 to update the random structures and derived values of a connection, 1090 while the third option makes it possible to establish several 1091 simultaneous independent secure connections without repeating the 1092 full handshake protocol. The actual contents of the SessionID are 1093 defined by the server. 1095 opaque SessionID<0..32>; 1097 Warning: Servers must not place confidential information in 1098 session identifiers or let the contents of fake 1099 session identifiers cause any breach of security. 1101 The CipherSuite list, passed from the client to the server in the 1102 client hello message, contains the combinations of cryptographic 1103 algorithms supported by the client in order of the client's 1104 preference (first choice first). Each CipherSuite defines both a 1105 key exchange algorithm and a CipherSpec. The server will select a 1106 cipher suite or, if no acceptable choices are presented, return a 1107 handshake failure alert and close the connection. 1109 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1111 The client hello includes a list of compression algorithms 1112 supported by the client, ordered according to the client's 1113 preference. If the server supports none of those specified by the 1114 client, the session must fail. 1116 enum { null(0), (255) } CompressionMethod; 1118 Issue: Which compression methods to support is under 1119 investigation. 1121 The structure of the client hello is as follows. 1122 struct { 1123 ProtocolVersion client_version; 1124 Random random; 1125 SessionID session_id; 1126 CipherSuite cipher_suites<2..2^16-1>; 1127 CompressionMethod compression_methods<1..2^8-1>; 1128 } ClientHello; 1130 client_version The version of the SSL protocol by which the 1131 client wishes to communicate during this 1132 session. This should be the most recent 1133 (highest valued) version supported by the 1134 client. For this version of the specification, 1135 the version will be 3.0 (See Appendix E for 1136 details about backward compatibility). 1137 random A client-generated random structure. 1138 session_id The ID of a session the client wishes to use 1139 for this connection. This field should be 1140 empty if no session_id is available or the 1141 client wishes to generate new security 1142 parameters. 1143 cipher_suites This is a list of the cryptographic options 1144 supported by the client, sorted with the 1145 client's first preference first. If the 1146 session_id field is not empty (implying a 1147 session resumption request) this vector must 1148 include at least the cipher_suite from that 1149 session. Values are defined in Appendix A.6. 1150 compression_methods 1151 This is a list of the compression methods 1152 supported by the client, sorted by client 1153 preference. If the session_id field is not 1154 empty (implying a session resumption request) 1155 this vector must include at least the 1156 compression_method from that session. All 1157 implementations must support 1158 CompressionMethod.null. 1160 After sending the client hello message, the client waits for a 1161 server hello message. Any other handshake message returned by the 1162 server except for a hello request is treated as a fatal error. 1164 Implementation note: 1165 Application data may not be sent before a finished 1166 message has been sent. Transmitted application data 1167 is known to be insecure until a valid finished 1168 message has been received. This absolute 1169 restriction is relaxed if there is a current, 1170 non-null encryption on this connection. 1172 Forward compatibility note: 1173 In the interests of forward compatibility, it is 1174 permitted for a client hello message to include 1175 extra data after the compression methods. This data 1176 must be included in the handshake hashes, but must 1177 otherwise be ignored. 1179 5.6.1.3 Server hello 1181 The server processes the client hello message and responds with 1182 either a handshake_failure alert or server hello message. 1184 struct { 1185 ProtocolVersion server_version; 1186 Random random; 1187 SessionID session_id; 1188 CipherSuite cipher_suite; 1189 CompressionMethod compression_method; 1190 } ServerHello; 1192 server_version This field will contain the lower of that 1193 suggested by the client in the client hello and 1194 the highest supported by the server. For this 1195 version of the specification, the version will 1196 be 3.0 (See Appendix E for details about 1197 backward compatibility). 1198 random This structure is generated by the server and 1199 must be different from (and independent of) 1200 ClientHello.random. 1201 session_id This is the identity of the session 1202 corresponding to this connection. If the 1203 ClientHello.session_id was non-empty, the 1204 server will look in its session cache for a 1205 match. If a match is found and the server is 1206 willing to establish the new connection using 1207 the specified session state, the server will 1208 respond with the same value as was supplied by 1209 the client. This indicates a resumed session 1210 and dictates that the parties must proceed 1211 directly to the finished messages. Otherwise 1212 this field will contain a different value 1213 identifying the new session. The server may 1214 return an empty session_id to indicate that the 1215 session will not be cached and therefore cannot 1216 be resumed. 1217 cipher_suite The single cipher suite selected by the server 1218 from the list in ClientHello.cipher_suites. 1219 For resumed sessions this field is the value 1220 from the state of the session being resumed. 1222 compression_method 1223 The single compression algorithm selected by 1224 the server from the list in 1225 ClientHello.compression_methods. For resumed 1226 sessions this field is the value from the 1227 resumed session state. 1229 5.6.2 Server certificate 1231 If the server is to be authenticated (which is generally the case), 1232 the server sends its certificate immediately following the server 1233 hello message. The certificate type must be appropriate for the 1234 selected cipher suite's key exchange algorithm, and is generally an 1235 X.509.v3 certificate (or a modified X.509 certificate in the case 1236 of FORTEZZA(tm) [FOR]). The same message type will be used for the 1237 client's response to a certificate request message. 1239 opaque ASN.1Cert<1..2^24-1>; 1240 struct { 1241 ASN.1Cert certificate_list<1..2^24-1>; 1242 } Certificate; 1244 certificate_list This is a sequence (chain) of X.509.v3 1245 certificates, ordered with the sender's 1246 certificate first followed by any certificate 1247 authority certificates proceeding sequentially 1248 upward. 1250 Note: PKCS #7 [PKCS7] is not used as the format for the 1251 certificate vector because PKCS #6 [PKCS6] extended 1252 certificates are not used. Also PKCS #7 defines a 1253 SET rather than a SEQUENCE, making the task of 1254 parsing the list more difficult. 1256 5.6.3 Server key exchange message 1258 The server key exchange message is sent by the server if it has no 1259 certificate, has a certificate only used for signing (e.g., DSS 1260 [DSS] certificates, signing-only RSA [RSA] certificates), or 1261 FORTEZZA KEA key exchange is used. This message is not used if the 1262 server certificate contains Diffie-Hellman [DH1] parameters. 1264 Note: According to current US export law, RSA moduli 1265 larger than 512 bits may not be used for key 1266 exchange in software exported from the US. With 1267 this message, larger RSA keys may be used as 1268 signature-only certificates to sign temporary 1269 shorter RSA keys for key exchange. 1271 enum { rsa, diffie_hellman, fortezza_kea } 1272 KeyExchangeAlgorithm; 1274 struct { 1275 opaque rsa_modulus<1..2^16-1>; 1276 opaque rsa_exponent<1..2^16-1>; 1277 } ServerRSAParams; 1279 rsa_modulus The modulus of the server's temporary RSA key. 1280 rsa_exponent The public exponent of the server's temporary 1281 RSA key. 1283 struct { 1284 opaque dh_p<1..2^16-1>; 1285 opaque dh_g<1..2^16-1>; 1286 opaque dh_Ys<1..2^16-1>; 1287 } ServerDHParams; /* Ephemeral DH parameters */ 1289 dh_p The prime modulus used for the Diffie-Hellman 1290 operation. 1291 dh_g The generator used for the Diffie-Hellman 1292 operation. 1293 dh_Ys The server's Diffie-Hellman public value 1294 (gX mod p). 1296 struct { 1297 opaque r_s [128]; 1298 } ServerFortezzaParams; 1300 r_s Server random number for FORTEZZA KEA (Key 1301 Exchange Algorithm). 1303 struct { 1304 select (KeyExchangeAlgorithm) { 1305 case diffie_hellman: 1306 ServerDHParams params; 1307 Signature signed_params; 1308 case rsa: 1309 ServerRSAParams params; 1310 Signature signed_params; 1311 case fortezza_kea: 1312 ServerFortezzaParams params; 1313 }; 1314 } ServerKeyExchange; 1316 params The server's key exchange parameters. 1317 signed_params A hash of the corresponding params value, with 1318 the signature appropriate to that hash applied. 1319 md5_hash MD5(ClientHello.random + ServerHello.random + 1320 ServerParams); 1321 sha_hash SHA(ClientHello.random + ServerHello.random + 1322 ServerParams); 1324 enum { anonymous, rsa, dsa } SignatureAlgorithm; 1325 digitally-signed struct { 1326 select(SignatureAlgorithm) { 1327 case anonymous: struct { }; 1328 case rsa: 1329 opaque md5_hash[16]; 1330 opaque sha_hash[20]; 1331 case dsa: 1332 opaque sha_hash[20]; 1333 }; 1334 } Signature; 1336 5.6.4 Certificate request 1338 A non-anonymous server can optionally request a certificate from 1339 the client, if appropriate for the selected cipher suite. 1341 enum { 1342 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 1343 rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20), 1344 (255) 1345 } ClientCertificateType; 1347 opaque DistinguishedName<1..2^16-1>; 1349 struct { 1350 ClientCertificateType certificate_types<1..2^8-1>; 1351 DistinguishedName certificate_authorities<3..2^16-1>; 1352 } CertificateRequest; 1354 certificate_types This field is a list of the types of 1355 certificates requested, sorted in order of the 1356 server's preference. 1357 certificate_authorities 1358 A list of the distinguished names of acceptable 1359 certificate authorities. 1361 Note: DistinguishedName is derived from [X509]. 1363 Note: It is a fatal handshake_failure alert for an 1364 anonymous server to request client identification. 1366 5.6.5 Server hello done 1368 The server hello done message is sent by the server to indicate the 1369 end of the server hello and associated messages. After sending 1370 this message the server will wait for a client response. 1372 struct { } ServerHelloDone; 1374 Upon receipt of the server hello done message the client should 1375 verify that the server provided a valid certificate if required and 1376 check that the server hello parameters are acceptable. 1378 5.6.6 Client certificate 1380 This is the first message the client can send after receiving a 1381 server hello done message. This message is only sent if the server 1382 requests a certificate. If no suitable certificate is available, 1383 the client should send a no_certificate alert instead. This alert 1384 is only a warning, however the server may respond with a fatal 1385 handshake failure alert if client authentication is required. 1386 Client certificates are sent using the Certificate defined in 1387 Section 5.6.2. 1389 Note: Client Diffie-Hellman certificates must match the 1390 server specified Diffie-Hellman parameters. 1392 5.6.7 Client key exchange message 1394 The choice of messages depends on which public key algorithm(s) has 1395 (have) been selected. See Section 5.6.3 for the 1396 KeyExchangeAlgorithm definition. 1398 struct { 1399 select (KeyExchangeAlgorithm) { 1400 case rsa: EncryptedPreMasterSecret; 1401 case diffie_hellman: ClientDiffieHellmanPublic; 1402 case fortezza_kea: FortezzaKeys; 1403 } exchange_keys; 1404 } ClientKeyExchange; 1406 The information to select the appropriate record structure is in 1407 the pending session state (see Section 5.1). 1409 5.6.7.1 RSA encrypted premaster secret message 1411 If RSA is being used for key agreement and authentication, the 1412 client generates a 48-byte pre-master secret, encrypts it under the 1413 public key from the server's certificate or temporary RSA key from 1414 a server key exchange message, and sends the result in an encrypted 1415 premaster secret message. 1417 struct { 1418 ProtocolVersion client_version; 1419 opaque random[46]; 1420 } PreMasterSecret; 1422 client_version The latest (newest) version supported by the 1423 client. This is used to detect version 1424 roll-back attacks. 1425 random 46 securely-generated random bytes. 1427 struct { 1428 public-key-encrypted PreMasterSecret pre_master_secret; 1429 } EncryptedPreMasterSecret; 1431 pre_master_secret This random value is generated by the client 1432 and is used to generate the master secret, as 1433 specified in Section 6.1. 1435 5.6.7.2 FORTEZZA key exchange message 1437 Under FORTEZZA, the client derives a Token Encryption Key (TEK) 1438 using the FORTEZZA Key Exchange Algorithm (KEA). The client's KEA 1439 calculation uses the public key in the server's certificate along 1440 with private parameters in the client's token. The client sends 1441 public parameters needed for the server to generate the TEK, using 1442 its own private parameters. The client generates session keys, 1443 wraps them using the TEK, and sends the results to the server. The 1444 client generates IV's for the session keys and TEK and sends them 1445 also. The client generates a random 48-byte premaster secret, 1446 encrypts it using the TEK, and sends the result: 1448 struct { 1449 opaque y_c<0..128>; 1450 opaque r_c[128]; 1451 opaque y_signature[40]; 1452 opaque wrapped_client_write_key[12]; 1453 opaque wrapped_server_write_key[12]; 1454 opaque client_write_iv[24]; 1455 opaque server_write_iv[24]; 1456 opaque master_secret_iv[24]; 1457 block-ciphered opaque encrypted_pre_master_secret[48]; 1458 } FortezzaKeys; 1460 y_signature y_signature is the signature of the KEA public 1461 key, signed with the client's DSS private key. 1462 y_c The client's Yc value (public key) for the KEA 1463 calculation. If the client has sent a 1464 certificate, and its KEA public key is 1465 suitable, this value must be empty since the 1466 certificate already contains this value. If 1467 the client sent a certificate without a 1468 suitable public key, y_c is used and 1469 y_signature is the KEA public key signed with 1470 the client's DSS private key. For this value 1471 to be used, it must be between 64 and 128 1472 bytes. 1473 r_c The client's Rc value for the KEA calculation. 1474 wrapped_client_write_key 1475 This is the client's write key, wrapped by the 1476 TEK. 1478 wrapped_server_write_key 1479 This is the server's write key, wrapped by the 1480 TEK. 1481 client_write_iv The IV for the client write key. 1482 server_write_iv The IV for the server write key. 1483 master_secret_iv This is the IV for the TEK used to encrypt the 1484 pre-master secret. 1485 pre_master_secret A random value, generated by the client and 1486 used to generate the master secret, as 1487 specified in Section 6.1. In the the above 1488 structure, it is encrypted using the TEK. 1490 5.6.7.3 Client Diffie-Hellman public value 1492 This structure conveys the client's Diffie-Hellman public value 1493 (Yc) if it was not already included in the client's certificate. 1494 The encoding used for Yc is determined by the enumerated 1495 PublicValueEncoding. 1497 enum { implicit, explicit } PublicValueEncoding; 1499 implicit If the client certificate already contains the 1500 public value, then it is implicit and Yc does 1501 not need to be sent again. 1502 explicit Yc needs to be sent. 1504 struct { 1505 select (PublicValueEncoding) { 1506 case implicit: struct { }; 1507 case explicit: opaque dh_Yc<1..2^16-1>; 1508 } dh_public; 1509 } ClientDiffieHellmanPublic; 1511 dh_Yc The client's Diffie-Hellman public value (Yc). 1513 5.6.8 Certificate verify 1515 This message is used to provide explicit verification of a client 1516 certificate. This message is only sent following any client 1517 certificate that has signing capability (i.e. all certificates 1518 except those containing fixed Diffie-Hellman parameters). 1520 struct { 1521 Signature signature; 1522 } CertificateVerify; 1524 CertificateVerify.signature.md5_hash 1525 MD5(master_secret + pad_2 + 1526 MD5(handshake_messages + master_secret + pad_1)); 1527 Certificate.signature.sha_hash 1528 SHA(master_secret + pad_2 + 1529 SHA(handshake_messages + master_secret + pad_1)); 1531 pad_1 This is identical to the pad_1 defined in 1532 section 5.2.3.1. 1533 pad_2 This is identical to the pad_2 defined in 1534 section 5.2.3.1. 1536 Here handshake_messages refers to all handshake messages starting 1537 at client hello up to but not including this message. 1539 5.6.9 Finished 1541 A finished message is always sent immediately after a change cipher 1542 specs message to verify that the key exchange and authentication 1543 processes were successful. The finished message is the first 1544 protected with the just-negotiated algorithms, keys, and secrets. 1545 No acknowledgment of the finished message is required; parties may 1546 begin sending encrypted data immediately after sending the finished 1547 message. Recipients of finished messages must verify that the 1548 contents are correct. 1550 enum { client(0x434C4E54), server(0x53525652) } Sender; 1552 struct { 1553 opaque md5_hash[16]; 1554 opaque sha_hash[20]; 1555 } Finished; 1557 md5_hash MD5(master_secret + pad2 + 1558 MD5(handshake_messages + Sender + 1559 master_secret + pad1)); 1560 sha_hash SHA(master_secret + pad2 + 1561 SHA(handshake_messages + Sender + 1562 master_secret + pad1)); 1564 handshake_messages All of the data from all handshake messages 1565 up to but not including this message. This 1566 is only data visible at the handshake layer 1567 and does not include record layer headers. 1569 It is a fatal error if a finished message is not preceeded by a 1570 change cipher spec message at the appropriate point in the 1571 handshake. 1573 The hash contained in finished messages sent by the server 1574 incorporate Sender.server; those sent by the client incorporate 1575 Sender.client. The value handshake_messages includes all handshake 1576 messages starting at client hello up to, but not including, this 1577 finished message. This may be different from handshake_messages in 1578 Section 5.6.8 because it would include the certificate verify 1579 message (if sent). 1581 Note: Change cipher spec messages are not handshake 1582 messages and are not included in the hash 1583 computations. 1585 5.7 Application data protocol 1587 Application data messages are carried by the Record Layer and are 1588 fragmented, compressed and encrypted based on the current 1589 connection state. The messages are treated as transparent data to 1590 the record layer. 1592 6. Cryptographic computations 1594 The key exchange, authentication, encryption, and MAC algorithms 1595 are determined by the cipher_suite selected by the server and 1596 revealed in the server hello message. 1598 6.1 Asymmetric cryptographic computations 1600 The asymmetric algorithms are used in the handshake protocol to 1601 authenticate parties and to generate shared keys and secrets. 1603 For Diffie-Hellman, RSA, and FORTEZZA, the same algorithm is used 1604 to convert the pre_master_secret into the master_secret. The 1605 pre_master_secret should be deleted from memory once the 1606 master_secret has been computed. 1608 master_secret = 1609 MD5(pre_master_secret + SHA('A' + pre_master_secret + 1610 ClientHello.random + ServerHello.random)) + 1611 MD5(pre_master_secret + SHA('BB' + pre_master_secret + 1612 ClientHello.random + ServerHello.random)) + 1613 MD5(pre_master_secret + SHA('CCC' + pre_master_secret + 1614 ClientHello.random + ServerHello.random)); 1616 6.1.1 RSA 1618 When RSA is used for server authentication and key exchange, a 1619 48-byte pre_master_secret is generated by the client, encrypted 1620 under the server's public key, and sent to the server. The server 1621 uses its private key to decrypt the pre_master_secret. Both 1622 parties then convert the pre_master_secret into the master_secret, 1623 as specified above. 1625 RSA digital signatures are performed using PKCS #1 [PKCS1] block 1626 type 1. RSA public key encryption is performed using PKCS #1 block 1627 type 2. 1629 6.1.2 Diffie-Hellman 1631 A conventional Diffie-Hellman computation is performed. The 1632 negotiated key (Z) is used as the pre_master_secret, and is 1633 converted into the master_secret, as specified above. 1635 Note: Diffie-Hellman parameters are specified by the 1636 server, and may be either ephemeral or contained 1637 within the server's certificate. 1639 6.1.3 FORTEZZA 1641 A random 48-byte pre_master_secret is sent encrypted under the TEK 1642 and its IV. The server decrypts the pre_master_secret and converts 1643 it into a master_secret, as specified above. Bulk cipher keys and 1644 IVs for encryption are generated by the client's token and 1645 exchanged in the key exchange message; the master_secret is only 1646 used for MAC computations. 1648 6.2 Symmetric cryptographic calculations and the CipherSpec 1650 The technique used to encrypt and verify the integrity of SSL 1651 records is specified by the currently active CipherSpec. A typical 1652 example would be to encrypt data using DES and generate 1653 authentication codes using MD5. The encryption and MAC algorithms 1654 are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL 1655 Handshake Protocol, indicating that no message authentication or 1656 encryption is performed. The handshake protocol is used to 1657 negotiate a more secure CipherSpec and to generate cryptographic 1658 keys. 1660 6.2.1 The master secret 1662 Before secure encryption or integrity verification can be performed 1663 on records, the client and server need to generate shared secret 1664 information known only to themselves. This value is a 48-byte 1665 quantity called the master secret. The master secret is used to 1666 generate keys and secrets for encryption and MAC computations. 1667 Some algorithms, such as FORTEZZA, may have their own procedure for 1668 generating encryption keys (the master secret is used only for MAC 1669 computations in FORTEZZA). 1671 6.2.2 Converting the master secret into keys and MAC secrets 1673 The master secret is hashed into a sequence of secure bytes, which 1674 are assigned to the MAC secrets, keys, and non-export IVs required 1675 by the current CipherSpec (see Appendix A.7). CipherSpecs require 1676 a client write MAC secret, a server write MAC secret, a client 1677 write key, a server write key, a client write IV, and a server 1678 write IV, which are generated from the master secret in that order. 1679 Unused values, such as FORTEZZA keys communicated in the 1680 KeyExchange message, are empty. The following inputs are available 1681 to the key definition process: 1683 opaque MasterSecret[48] 1684 ClientHello.random 1685 ServerHello.random 1687 When generating keys and MAC secrets, the master secret is used as 1688 an entropy source, and the random values provide unencrypted salt 1689 material and IVs for exportable ciphers. 1691 To generate the key material, compute 1693 key_block = 1694 MD5(master_secret + SHA(`A' + master_secret + 1695 ServerHello.random + 1696 ClientHello.random)) + 1697 MD5(master_secret + SHA(`BB' + master_secret + 1698 ServerHello.random + 1699 ClientHello.random)) + 1700 MD5(master_secret + SHA(`CCC' + master_secret + 1701 ServerHello.random + 1702 ClientHello.random)) + [...]; 1704 until enough output has been generated. Then the key_block is 1705 partitioned as follows. 1707 client_write_MAC_secret[CipherSpec.hash_size] 1708 server_write_MAC_secret[CipherSpec.hash_size] 1709 client_write_key[CipherSpec.key_material] 1710 server_write_key[CipherSpec.key_material] 1711 client_write_IV[CipherSpec.IV_size] /* non-export ciphers */ 1712 server_write_IV[CipherSpec.IV_size] /* non-export ciphers */ 1714 Any extra key_block material is discarded. 1716 Exportable encryption algorithms (for which 1717 CipherSpec.is_exportable is true) require additional processing as 1718 follows to derive their final write keys: 1720 final_client_write_key = MD5(client_write_key + 1721 ClientHello.random + 1722 ServerHello.random); 1723 final_server_write_key = MD5(server_write_key + 1724 ServerHello.random + 1725 ClientHello.random); 1727 Exportable encryption algorithms derive their IVs from the random 1728 messages: 1730 client_write_IV = MD5(ClientHello.random + ServerHello.random); 1731 server_write_IV = MD5(ServerHello.random + ClientHello.random); 1733 MD5 outputs are trimmed to the appropriate size by discarding the 1734 least-significant bytes. 1736 6.2.2.1 Export key generation example 1738 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for 1739 each of the two encryption keys and 16 bytes for each of the MAC 1740 keys, for a total of 42 bytes of key material. MD5 produces 16 1741 bytes of output per call, so three calls to MD5 are required. The 1742 MD5 outputs are concatenated into a 48-byte key_block with the 1743 first MD5 call providing bytes zero through 15, the second 1744 providing bytes 16 through 31, etc. The key_block is partitioned, 1745 and the write keys are salted because this is an exportable 1746 encryption algorithm. 1748 client_write_MAC_secret = key_block[0..15] 1749 server_write_MAC_secret = key_block[16..31] 1750 client_write_key = key_block[32..36] 1751 server_write_key = key_block[37..41] 1752 final_client_write_key = MD5(client_write_key + 1753 ClientHello.random + 1754 ServerHello.random)[0..15]; 1755 final_server_write_key = MD5(server_write_key + 1756 ServerHello.random + 1757 ClientHello.random)[0..15]; 1758 client_write_IV = MD5(ClientHello.random + 1759 ServerHello.random)[0..7]; 1760 server_write_IV = MD5(ServerHello.random + 1761 ClientHello.random)[0..7]; 1762 Appendix A 1764 A. Protocol constant values 1766 This section describes protocol types and constants. 1768 A.1 Reserved port assignments 1770 At the present time SSL is implemented using TCP/IP as the base 1771 networking technology. The IANA reserved the following Internet 1772 Protocol [IP] port numbers for use in conjunction with SSL. 1774 443 Reserved for use by Hypertext Transfer Protocol with 1775 SSL (https). 1776 465 Reserved (pending) for use by Simple Mail Transfer Protocol 1777 with SSL (ssmtp). 1778 563 Reserved (pending) for use by Network News Transfer 1779 Protocol (snntp). 1781 A.1.1 Record layer 1783 struct { 1784 uint8 major, minor; 1785 } ProtocolVersion; 1787 ProtocolVersion version = { 3,0 }; 1789 enum { 1790 change_cipher_spec(20), alert(21), handshake(22), 1791 application_data(23), (255) 1792 } ContentType; 1794 struct { 1795 ContentType type; 1796 ProtocolVersion version; 1797 uint16 length; 1798 opaque fragment[SSLPlaintext.length]; 1799 } SSLPlaintext; 1801 struct { 1802 ContentType type; 1803 ProtocolVersion version; 1804 uint16 length; 1805 opaque fragment[SSLCompressed.length]; 1806 } SSLCompressed; 1808 struct { 1809 ContentType type; 1810 ProtocolVersion version; 1811 uint16 length; 1812 select (CipherSpec.cipher_type) { 1813 case stream: GenericStreamCipher; 1814 case block: GenericBlockCipher; 1815 } fragment; 1816 } SSLCiphertext; 1818 stream-ciphered struct { 1819 opaque content[SSLCompressed.length]; 1820 opaque MAC[CipherSpec.hash_size]; 1821 } GenericStreamCipher; 1823 block-ciphered struct { 1824 opaque content[SSLCompressed.length]; 1825 opaque MAC[CipherSpec.hash_size]; 1826 uint8 padding[GenericBlockCipher.padding_length]; 1827 uint8 padding_length; 1828 } GenericBlockCipher; 1830 A.2 Change cipher specs message 1832 struct { 1833 enum { change_cipher_spec(1), (255) } type; 1834 } ChangeCipherSpec; 1836 A.3 Alert messages 1838 enum { warning(1), fatal(2), (255) } AlertLevel; 1840 enum { 1841 close_notify(0), 1842 unexpected_message(10), 1843 bad_record_mac(20), 1844 decompression_failure(30), 1845 handshake_failure(40), 1846 no_certificate(41), 1847 bad_certificate(42), 1848 unsupported_certificate(43), 1849 certificate_revoked(44), 1850 certificate_expired(45), 1851 certificate_unknown(46), 1852 illegal_parameter (47), 1853 (255) 1854 } AlertDescription; 1856 struct { 1857 AlertLevel level; 1858 AlertDescription description; 1859 } Alert; 1861 A.4 Handshake protocol 1863 enum { 1864 hello_request(0), client_hello(1), server_hello(2), 1865 certificate(11), server_key_exchange (12), 1866 certificate_request(13), server_done(14), 1867 certificate_verify(15), client_key_exchange(16), 1868 finished(20), (255) 1869 } HandshakeType; 1871 struct { 1872 HandshakeType msg_type; 1873 uint24 length; 1874 select (HandshakeType) { 1875 case hello_request: HelloRequest; 1876 case client_hello: ClientHello; 1877 case server_hello: ServerHello; 1878 case certificate: Certificate; 1879 case server_key_exchange: ServerKeyExchange; 1880 case certificate_request: CertificateRequest; 1881 case server_done: ServerHelloDone; 1882 case certificate_verify: CertificateVerify; 1883 case client_key_exchange: ClientKeyExchange; 1884 case finished: Finished; 1885 } body; 1886 } Handshake; 1888 A.4.1 Hello messages 1890 struct { } HelloRequest; 1892 struct { 1893 uint32 gmt_unix_time; 1894 opaque random_bytes[28]; 1895 } Random; 1897 opaque SessionID<0..32>; 1899 uint8 CipherSuite[2]; 1901 enum { null(0), (255) } CompressionMethod; 1903 struct { 1904 ProtocolVersion client_version; 1905 Random random; 1906 SessionID session_id; 1907 CipherSuite cipher_suites<0..2^16-1>; 1908 CompressionMethod compression_methods<0..2^8-1>; 1909 } ClientHello; 1911 struct { 1912 ProtocolVersion server_version; 1913 Random random; 1914 SessionID session_id; 1915 CipherSuite cipher_suite; 1916 CompressionMethod compression_method; 1917 } ServerHello; 1919 A.4.2 Server authentication and key exchange messages 1921 opaque ASN.1Cert<2^24-1>; 1923 struct { 1924 ASN.1Cert certificate_list<1..2^24-1>; 1925 } Certificate; 1927 enum { rsa, diffie_hellman, fortezza_kea } KeyExchangeAlgorithm; 1929 struct { 1930 opaque RSA_modulus<1..2^16-1>; 1931 opaque RSA_exponent<1..2^16-1>; 1932 } ServerRSAParams; 1934 struct { 1935 opaque DH_p<1..2^16-1>; 1936 opaque DH_g<1..2^16-1>; 1937 opaque DH_Ys<1..2^16-1>; 1938 } ServerDHParams; 1940 struct { 1941 opaque r_s [128] 1942 } ServerFortezzaParams 1944 struct { 1945 select (KeyExchangeAlgorithm) { 1946 case diffie_hellman: 1947 ServerDHParams params; 1948 Signature signed_params; 1949 case rsa: 1950 ServerRSAParams params; 1951 Signature signed_params; 1952 case fortezza_kea: 1953 ServerFortezzaParams params; 1954 }; 1955 } ServerKeyExchange; 1957 enum { anonymous, rsa, dsa } SignatureAlgorithm; 1959 digitally-signed struct { 1960 select(SignatureAlgorithm) { 1961 case anonymous: struct { }; 1962 case rsa: 1963 opaque md5_hash[16]; 1964 opaque sha_hash[20]; 1965 case dsa: 1966 opaque sha_hash[20]; 1967 }; 1968 } Signature; 1969 enum { 1970 RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3), 1971 DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6), 1972 FORTEZZA_MISSI(20), (255) 1973 } CertificateType; 1975 opaque DistinguishedName<1..2^16-1>; 1977 struct { 1978 CertificateType certificate_types<1..2^8-1>; 1979 DistinguishedName certificate_authorities<3..2^16-1>; 1980 } CertificateRequest; 1982 struct { } ServerHelloDone; 1984 A.5 Client authentication and key exchange messages 1986 struct { 1987 select (KeyExchangeAlgorithm) { 1988 case rsa: EncryptedPreMasterSecret; 1989 case diffie_hellman: DiffieHellmanClientPublicValue; 1990 case fortezza_kea: FortezzaKeys; 1991 } exchange_keys; 1992 } ClientKeyExchange; 1994 struct { 1995 ProtocolVersion client_version; 1996 opaque random[46]; 1997 } PreMasterSecret; 1999 struct { 2000 public-key-encrypted PreMasterSecret pre_master_secret; 2001 } EncryptedPreMasterSecret; 2003 struct { 2004 opaque y_c<0..128>; 2005 opaque r_c[128]; 2006 opaque y_signature[40]; 2007 opaque wrapped_client_write_key[12]; 2008 opaque wrapped_server_write_key[12]; 2009 opaque client_write_iv[24]; 2010 opaque server_write_iv[24]; 2011 opaque master_secret_iv[24]; 2012 opaque encrypted_preMasterSecret[48]; 2013 } FortezzaKeys; 2015 enum { implicit, explicit } PublicValueEncoding; 2017 struct { 2018 select (PublicValueEncoding) { 2019 case implicit: struct {}; 2020 case explicit: opaque DH_Yc<1..2^16-1>; 2022 } dh_public; 2023 } ClientDiffieHellmanPublic; 2025 struct { 2026 Signature signature; 2027 } CertificateVerify; 2029 A.5.1 Handshake finalization message 2031 struct { 2032 opaque md5_hash[16]; 2033 opaque sha_hash[20]; 2034 } Finished; 2036 A.6 The CipherSuite 2038 The following values define the CipherSuite codes used in the 2039 client hello and server hello messages. 2041 A CipherSuite defines a cipher specifications supported in SSL 2042 Version 3.0. 2044 CipherSuite SSL_NULL_WITH_NULL_NULL = { 0x00,0x00 }; 2046 The following CipherSuite definitions require that the server 2047 provide an RSA certificate that can be used for key exchange. The 2048 server may request either an RSA or a DSS signature-capable 2049 certificate in the certificate request message. 2051 CipherSuite SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; 2052 CipherSuite SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 }; 2053 CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; 2054 CipherSuite SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; 2055 CipherSuite SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; 2056 CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; 2057 CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; 2058 CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; 2059 CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; 2060 CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; 2062 The following CipherSuite definitions are used for 2063 server-authenticated (and optionally client-authenticated) 2064 Diffie-Hellman. DH denotes cipher suites in which the server's 2065 certificate contains the Diffie-Hellman parameters signed by the 2066 certificate authority (CA). DHE denotes ephemeral Diffie-Hellman, 2067 where the Diffie-Hellman parameters are signed by a DSS or RSA 2068 certificate, which has been signed by the CA. The signing 2069 algorithm used is specified after the DH or DHE parameter. In all 2070 cases, the client must have the same type of certificate, and must 2071 use the Diffie-Hellman parameters chosen by the server. 2073 CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; 2074 CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; 2075 CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; 2076 CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; 2077 CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; 2078 CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; 2079 CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; 2080 CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; 2081 CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; 2082 CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; 2083 CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; 2084 CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; 2086 The following cipher suites are used for completely anonymous 2087 Diffie-Hellman communications in which neither party is 2088 authenticated. Note that this mode is vulnerable to 2089 man-in-the-middle attacks and is therefore strongly discouraged. 2091 CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; 2092 CipherSuite SSL_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; 2093 CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; 2094 CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; 2095 CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; 2097 The final cipher suites are for the FORTEZZA token. 2099 CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA = { 0X00,0X1C }; 2100 CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00,0x1D }; 2101 CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA = { 0x00,0x1E }; 2103 Note: All cipher suites whose first byte is 0xFF are 2104 considered private and can be used for defining 2105 local/experimental algorithms. Interoperability of 2106 such types is a local matter. 2108 Note: Additional cipher suites will be considered for 2109 implementation only with submission of notarized 2110 letters from two independent entities. Netscape 2111 Communications Corp. will act as an interim 2112 registration office, until a public standards body 2113 assumes control of SSL. 2115 A.7 The CipherSpec 2117 A cipher suite identifies a CipherSpec. These structures are part 2118 of the SSL session state. The CipherSpec includes: 2120 enum { stream, block } CipherType; 2122 enum { true, false } IsExportable; 2123 enum { null, rc4, rc2, des, 3des, des40, fortezza } 2124 BulkCipherAlgorithm; 2126 enum { null, md5, sha } MACAlgorithm; 2128 struct { 2129 BulkCipherAlgorithm bulk_cipher_algorithm; 2130 MACAlgorithm mac_algorithm; 2131 CipherType cipher_type; 2132 IsExportable is_exportable 2133 uint8 hash_size; 2134 uint8 key_material; 2135 uint8 IV_size; 2136 } CipherSpec; 2137 Appendix B 2139 B. Glossary 2140 application protocol An application protocol is a protocol that 2141 normally layers directly on top of the 2142 transport layer (e.g., TCP/IP). Examples 2143 include HTTP, TELNET, FTP, and SMTP. 2144 asymmetric cipher See public key cryptography. 2145 authentication Authentication is the ability of one entity 2146 to determine the identity of another entity. 2147 block cipher A block cipher is an algorithm that operates 2148 on plaintext in groups of bits, called 2149 blocks. 64 bits is a typical block size. 2150 bulk cipher A symmetric encryption algorithm used to 2151 encrypt large quantities of data. 2152 cipher block chaining 2153 Mode (CBC) CBC is a mode in which every 2154 plaintext block encrypted with the block 2155 cipher is first exclusive-ORed with the 2156 previous ciphertext block (or, in the case 2157 of the first block, with the initialization 2158 vector). 2159 certificate As part of the X.509 protocol (a.k.a. ISO 2160 Authentication framework), certificates are 2161 assigned by a trusted Certificate Authority 2162 and provide verification of a party's 2163 identity and may also supply its public key. 2164 client The application entity that initiates a 2165 connection to a server. 2166 client write key The key used to encrypt data written by the 2167 client. 2168 client write MAC secret 2169 The secret data used to authenticate data 2170 written by the client. 2171 connection A connection is a transport (in the OSI 2172 layering model definition) that provides a 2173 suitable type of service. For SSL, such 2174 connections are peer to peer relationships. 2175 The connections are transient. Every 2176 connection is associated with one session. 2177 Data Encryption Standard 2178 (DES) DES is a very widely used symmetric 2179 encryption algorithm. DES is a block 2180 cipher. 2181 Digital Signature Standard 2182 (DSS) A standard for digital signing, 2183 including the Digital Signing Algorithm, 2184 approved by the National Institute of 2185 Standards and Technology, defined in NIST 2186 FIPS PUB 186, "Digital Signature Standard," 2187 published May, 1994 by the U.S. Dept. of 2188 Commerce. 2190 digital signatures Digital signatures utilize public key 2191 cryptography and one-way hash functions to 2192 produce a signature of the data that can be 2193 authenticated, and is difficult to forge or 2194 repudiate. 2195 FORTEZZA A PCMCIA card that provides both encryption 2196 and digital signing. 2197 handshake An initial negotiation between client and 2198 server that establishes the parameters of 2199 their transactions. 2200 Initialization Vector 2201 (IV) When a block cipher is used in CBC 2202 mode, the initialization vector is 2203 exclusive-ORed with the first plaintext 2204 block prior to encryption. 2205 IDEA A 64-bit block cipher designed by Xuejia Lai 2206 and James Massey. 2207 Message Authentication Code 2208 (MAC) A Message Authentication Code is a 2209 one-way hash computed from a message and 2210 some secret data. Its purpose is to detect 2211 if the message has been altered. 2212 master secret Secure secret data used for generating 2213 encryption keys, MAC secrets, and IVs. 2214 MD5 MD5 [7] is a secure hashing function that 2215 converts an arbitrarily long data stream 2216 into a digest of fixed size. 2217 public key cryptography 2218 A class of cryptographic techniques 2219 employing two-key ciphers. Messages 2220 encrypted with the public key can only be 2221 decrypted with the associated private key. 2222 Conversely, messages signed with the private 2223 key can be verified with the public key. 2224 one-way hash function 2225 A one-way transformation that converts an 2226 arbitrary amount of data into a fixed-length 2227 hash. It is computation- ally hard to 2228 reverse the transformation or to find 2229 collisions. MD5 and SHA are examples of 2230 one-way hash functions. 2231 RC2, RC4 Proprietary bulk ciphers from RSA Data 2232 Security, Inc. (There is no good reference 2233 to these as they are unpublished works; 2234 however, see [RSADSI]). RC2 is block cipher 2235 and RC4 is a stream cipher. 2236 RSA A very widely used public-key algorithm that 2237 can be used for either encryption or digital 2238 signing. 2239 salt Non-secret random data used to make export 2240 encryption keys resist precomputation 2241 attacks. 2243 server The server is the application entity that 2244 responds to requests for connections from 2245 clients. The server is passive, waiting for 2246 requests from clients. 2247 session A SSL session is an association between a 2248 client and a server. Sessions are created 2249 by the handshake protocol. Sessions define 2250 a set of cryptographic security parameters, 2251 which can be shared among multiple 2252 connections. Sessions are used to avoid the 2253 expensive negotiation of new security 2254 parameters for each connection. 2255 session identifier A session identifier is a value generated by 2256 a server that identifies a particular 2257 session. 2258 server write key The key used to encrypt data written by the 2259 server. 2260 server write MAC secret 2261 The secret data used to authenticate data 2262 written by the server. 2263 SHA The Secure Hash Algorithm is defined in FIPS 2264 PUB 180-1. It produces a 20-byte output 2265 [SHA]. 2266 stream cipher An encryption algorithm that converts a key 2267 into a cryptographically-strong keystream, 2268 which is then exclusive-ORed with the 2269 plaintext. 2270 symmetric cipher See bulk cipher. 2272 Appendix C 2274 C. CipherSuite definitions 2276 CipherSuite Is Key Cipher Hash 2277 Exportable Exchange 2279 SSL_NULL_WITH_NULL_NULL * NULL NULL NULL 2280 SSL_RSA_WITH_NULL_MD5 * RSA NULL MD5 2281 SSL_RSA_WITH_NULL_SHA * RSA NULL SHA 2282 SSL_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 2283 SSL_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 2284 SSL_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA 2285 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 2286 SSL_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA 2287 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA 2288 SSL_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA 2289 SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA 2290 SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA 2291 SSL_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA 2292 SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA 2293 SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA 2294 SSL_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA 2295 SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA 2296 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA 2297 SSL_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA 2298 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA 2299 SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA 2300 SSL_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA 2301 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA 2302 SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 2303 SSL_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 2304 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA 2305 SSL_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA 2306 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA 2307 SSL_FORTEZZA_KEA_WITH_NULL_SHA FORTEZZA_KEA NULL SHA 2308 SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA FORTEZZA_KEA FORTEZZA_CBC SHA 2309 SSL_FORTEZZA_KEA_WITH_RC4_128_SHA FORTEZZA_KEA RC4_128 SHA 2311 * Indicates IsExportable is True 2313 Key Description Key size limit 2314 Exchange 2315 Algorithm 2316 DHE_DSS Ephemeral DH with DSS signatures None 2317 DHE_DSS_EXPORT Ephemeral DH with DSS signatures DH = 512 bits 2318 DHE_RSA Ephemeral DH with RSA signatures None 2319 DHE_RSA_EXPORT Ephemeral DH with RSA signatures DH = 512 bits, 2320 RSA = none 2321 DH_anon Anonymous DH, no signatures None 2322 DH_anon_EXPORT Anonymous DH, no signatures DH = 512 bits 2323 DH_DSS DH with DSS-based certificates None 2324 DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits 2325 DH_RSA DH with RSA-based certificates None 2326 DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits, 2327 RSA = none 2328 FORTEZZA_KEA FORTEZZA KEA. Details unpublished N/A 2329 NULL No key exchange N/A 2330 RSA RSA key exchange None 2331 RSA_EXPORT RSA key exchange RSA = 512 bits 2333 Key size limit The key size limit gives the size of the 2334 largest public key that can be legally 2335 used for encryption in cipher suites that 2336 are exportable. 2338 Cipher Cipher IsExpo Key Exp. Effect IV Block 2339 Type rtable Material Key Mat ive Key Size Size 2340 erial Bits 2342 NULL Stream * 0 0 0 0 N/A 2343 FORTEZZA_CBC Block NA(**) 12(**) 96(**) 20(**) 8 2344 IDEA_CBC Block 16 16 128 8 8 2345 RC2_CBC_40 Block * 5 16 40 8 8 2346 RC4_40 Stream * 5 16 40 0 N/A 2347 RC4_128 Stream 16 16 128 0 N/A 2348 DES40_CBC Block * 5 8 40 8 8 2349 DES_CBC Block 8 8 56 8 8 2350 3DES_EDE_CBC Block 24 24 168 8 8 2352 * Indicates IsExportable is true. 2353 ** FORTEZZA uses its own key and IV generation algorithms. 2355 Key Material The number of bytes from the key_block that are 2356 used for generating the write keys. 2357 Expanded Key Material 2358 The number of bytes actually fed into the 2359 encryption algorithm. 2360 Effective Key Bits 2361 How much entropy material is in the key 2362 material being fed into the encryption 2363 routines. 2365 Hash Hash Size Padding 2366 function Size 2367 NULL 0 0 2368 MD5 16 48 2369 SHA 20 40 2370 Appendix D 2372 D. Implementation Notes 2374 The SSL protocol cannot prevent many common security mistakes. 2375 This section provides several recommendations to assist 2376 implementers. 2378 D.1 Temporary RSA keys 2380 US Export restrictions limit RSA keys used for encryption to 512 2381 bits, but do not place any limit on lengths of RSA keys used for 2382 signing operations. Certificates often need to be larger than 512 2383 bits, since 512-bit RSA keys are not secure enough for high-value 2384 transactions or for applications requiring long-term security. 2385 Some certificates are also designated signing-only, in which case 2386 they cannot be used for key exchange. 2388 When the public key in the certificate cannot be used for 2389 encryption, the server signs a temporary RSA key, which is then 2390 exchanged. In exportable applications, the temporary RSA key 2391 should be the maximum allowable length (i.e., 512 bits). Because 2392 512-bit RSA keys are relatively insecure, they should be changed 2393 often. For typical electronic commerce applications, it is 2394 suggested that keys be changed daily or every 500 transactions, and 2395 more often if possible. Note that while it is acceptable to use 2396 the same temporary key for multiple transactions, it must be signed 2397 each time it is used. 2399 RSA key generation is a time-consuming process. In many cases, a 2400 low-priority process can be assigned the task of key generation. 2401 Whenever a new key is completed, the existing temporary key can be 2402 replaced with the new one. 2404 D.2 Random Number Generation and Seeding 2406 SSL requires a cryptographically-secure pseudorandom number 2407 generator (PRNG). Care must be taken in designing and seeding 2408 PRNGs. PRNGs based on secure hash operations, most notably MD5 2409 and/or SHA, are acceptable, but cannot provide more security than 2410 the size of the random number generator state. (For example, 2411 MD5-based PRNGs usually provide 128 bits of state.) 2413 To estimate the amount of seed material being produced, add the 2414 number of bits of unpredictable information in each seed byte. For 2415 example, keystroke timing values taken from a PC- compatible's 18.2 2416 Hz timer provide 1 or 2 secure bits each, even though the total 2417 size of the counter value is 16 bits or more. To seed a 128-bit 2418 PRNG, one would thus require approximately 100 such timer values. 2420 Note: The seeding functions in RSAREF and versions of 2421 BSAFE prior to 3.0 are order-independent. For 2422 example, if 1000 seed bits are supplied, one at a 2423 time, in 1000 separate calls to the seed function, 2424 the PRNG will end up in a state which depends only 2425 on the number of 0 or 1 seed bits in the seed data 2426 (i.e., there are 1001 possible final states). 2427 Applications using BSAFE or RSAREF must take extra 2428 care to ensure proper seeding. 2430 D.3 Certificates and authentication 2432 Implementations are responsible for verifying the integrity of 2433 certificates and should generally support certificate revocation 2434 messages. Certificates should always be verified to ensure proper 2435 signing by a trusted Certificate Authority (CA). The selection and 2436 addition of trusted CAs should be done very carefully. Users 2437 should be able to view information about the certificate and root 2438 CA. 2440 D.4 CipherSuites 2442 SSL supports a range of key sizes and security levels, including 2443 some which provide no or minimal security. A proper implementation 2444 will probably not support many cipher suites. For example, 40-bit 2445 encryption is easily broken, so implementations requiring strong 2446 security should not allow 40-bit keys. Similarly, anonymous 2447 Diffie-Hellman is strongly discouraged because it cannot prevent 2448 man-in-the- middle attacks. Applications should also enforce 2449 minimum and maximum key sizes. For example, certificate chains 2450 containing 512-bit RSA keys or signatures are not appropriate for 2451 high-security applications. 2453 D.5 FORTEZZA 2455 This section describes implementation details for ciphersuites that 2456 make use of the FORTEZZA hardware encryption system. 2458 D.5.1 Notes on use of FORTEZZA hardware 2460 A complete explanation of all issues regarding the use of FORTEZZA 2461 hardware is outside the scope of this document. However, there are 2462 a few special requirements of SSL that deserve mention. 2464 Because SSL is a full duplex protocol, two crypto states must be 2465 maintained, one for reading and one for writing. There are also a 2466 number of circumstances which can result in the crypto state in the 2467 FORTEZZA card being lost. For these reasons, it's recommended that 2468 the current crypto state be saved after processing a record, and 2469 loaded before processing the next. 2471 After the client generates the TEK, it also generates two MEKs, 2472 for one for reading and one for writing. After generating each of 2473 these keys, the client must generate a corresponding IV and then 2474 save the crypto state. The client also uses the TEK to generate an 2475 IV and encrypt the premaster secret. All three IVs are sent to the 2476 server, along with the wrapped keys and the encrypted premaster 2477 secret in the client key exchange message. At this point, the TEK 2478 is no longer needed, and may be discarded. 2480 On the server side, the server uses the master IV and the TEK to 2481 decrypt the premaster secret. It also loads the wrapped MEKs into 2482 the card. The server loads both IVs to verify that the IVs match 2483 the keys. However, since the card is unable to encrypt after 2484 loading an IV, the server must generate a new IV for the server 2485 write key. This IV is discarded. 2487 When encrypting the first encrypted record (and only that record), 2488 the server adds 8 bytes of random data to the beginning of the 2489 fragment. These 8 bytes are discarded by the client after 2490 decryption. The purpose of this is to synchronize the state on the 2491 client and server resulting from the different IVs. 2493 D.5.2 FORTEZZA Ciphersuites 2495 5) FORTEZZA_NULL_WITH_NULL_SHA: 2496 Uses the full FORTEZZA key exchange, including sending server and 2497 client write keys and iv's. 2499 D.5.3 FORTEZZA Session resumption 2501 There are two possibilities for FORTEZZA session restart: 2502 1) Never restart a FORTEZZA session. 2503 2) Restart a session with the previously negotiated keys and iv's. 2505 Never restarting a FORTEZZA session: 2507 Clients who never restart FORTEZZA sessions should never send 2508 Session ID's which were previously used in a FORTEZZA session as 2509 part of the ClientHello. Servers who never restart FORTEZZA 2510 sessions should never send a previous session id on the 2511 ServerHello if the negotiated session is FORTEZZA. 2513 Restart a session: 2515 You cannot restart FORTEZZA on a session which has never done a 2516 complete FORTEZZA key exchange (That is you cannot restart FORTEZZA 2517 if the session was an RSA/RC4 session renegotiated for FORTEZZA). 2518 If you wish to restart a FORTEZZA session, you must save the MEKs 2519 and IVs from the initial key exchange for this session and reuse 2520 them for any new connections on that session. This is not 2521 recommended, but it is possible. 2523 Appendix E 2525 E. Version 2.0 Backward Compatibility 2527 Version 3.0 clients that support Version 2.0 servers must send 2528 Version 2.0 client hello messages [SSL-2]. Version 3.0 servers 2529 should accept either client hello format. The only deviations from 2530 the Version 2.0 specification are the ability to specify a version 2531 with a value of three and the support for more ciphering types in 2532 the CipherSpec. 2534 Warning: The ability to send Version 2.0 client hello 2535 messages will be phased out with all due haste. 2536 Implementers should make every effort to move 2537 forward as quickly as possible. Version 3.0 2538 provides better mechanisms for transitioning to 2539 newer versions. 2541 The following cipher specifications are carryovers from SSL Version 2542 2.0. These are assumed to use RSA for key exchange and 2543 authentication. 2545 V2CipherSpec SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; 2546 V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; 2547 V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; 2548 V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 2549 = { 0x04,0x00,0x80 }; 2550 V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; 2551 V2CipherSpec SSL_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; 2552 V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; 2554 Cipher specifications introduced in Version 3.0 can be included in 2555 Version 2.0 client hello messages using the syntax below. Any 2556 V2CipherSpec element with its first byte equal to zero will be 2557 ignored by Version 2.0 servers. Clients sending any of the above 2558 V2CipherSpecs should also include the Version 3.0 equivalent (see 2559 Appendix A.6): 2561 V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite }; 2563 E.1 Version 2 client hello 2565 The Version 2.0 client hello message is presented below using this 2566 document's presentation model. The true definition is still 2567 assumed to be the SSL Version 2.0 specification. 2569 uint8 V2CipherSpec[3]; 2571 struct { 2572 unit8 msg_type; 2573 Version version; 2574 uint16 cipher_spec_length; 2575 uint16 session_id_length; 2576 uint16 challenge_length; 2577 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; 2578 opaque session_id[V2ClientHello.session_id_length]; 2579 Random challenge; 2580 } V2ClientHello; 2582 msg_type This field, in conjunction with the version 2583 field, identifies a version 2 client hello 2584 message. The value should equal one (1). 2585 version The highest version of the protocol supported 2586 by the client (equals ProtocolVersion.version, 2587 see Appendix A.1.1). 2588 cipher_spec_length 2589 This field is the total length of the field 2590 cipher_specs. It cannot be zero and must be a 2591 multiple of the V2CipherSpec length (3). 2592 session_id_length This field must have a value of either zero or 2593 16. If zero, the client is creating a new 2594 session. If 16, the session_id field will 2595 contain the 16 bytes of session identification. 2596 challenge_length The length in bytes of the client's challenge 2597 to the server to authenticate itself. This 2598 value must be 32. 2599 cipher_specs This is a list of all CipherSpecs the client is 2600 willing and able to use. There must be at 2601 least one CipherSpec acceptable to the server. 2602 session_id If this field's length is not zero, it will 2603 contain the identification for a session that 2604 the client wishes to resume. 2605 challenge The client's challenge to the server for the 2606 server to identify itself is a (nearly) 2607 arbitrary length random. The Version 3.0 2608 server will right justify the challenge data to 2609 become the ClientHello.random data (padded with 2610 leading zeroes, if necessary), as specified in 2611 this Version 3.0 protocol. If the length of 2612 the challenge is greater than 32 bytes, then 2613 only the last 32 bytes are used. It is 2614 legitimate (but not necessary) for a V3 server 2615 to reject a V2 ClientHello that has fewer than 2616 16 bytes of challenge data. 2618 Note: Requests to resume an SSL 3.0 session should use an 2619 SSL 3.0 client hello. 2621 E.2 Avoiding man-in-the-middle version rollback 2623 When SSL Version 3.0 clients fall back to Version 2.0 compatibility 2624 mode, they use special PKCS #1 block formatting. This is done so 2625 that Version 3.0 servers will reject Version 2.0 sessions with 2626 Version 3.0-capable clients. 2628 When Version 3.0 clients are in Version 2.0 compatibility mode, 2629 they set the right-hand (least-significant) 8 random bytes of the 2630 PKCS padding (not including the terminal null of the padding) for 2631 the RSA encryption of the ENCRYPTED-KEY- DATA field of the 2632 CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random). 2633 After decrypting the ENCRYPTED- KEY-DATA field, servers that 2634 support SSL 3.0 should issue an error if these eight padding bytes 2635 are 0x03. Version 2.0 servers receiving blocks padded in this 2636 manner will proceed normally. 2638 Appendix F 2640 F. Security analysis 2642 The SSL protocol is designed to establish a secure connection 2643 between a client and a server communicating over an insecure 2644 channel. This document makes several traditional assumptions, 2645 including that attackers have substantial computational resources 2646 and cannot obtain secret information from sources outside the 2647 protocol. Attackers are assumed to have the ability to capture, 2648 modify, delete, replay, and otherwise tamper with messages sent 2649 over the communication channel. This appendix outlines how SSL has 2650 been designed to resist a variety of attacks. 2652 F.1 Handshake protocol 2654 The handshake protocol is responsible for selecting a CipherSpec 2655 and generating a MasterSecret, which together comprise the primary 2656 cryptographic parameters associated with a secure session. The 2657 handshake protocol can also optionally authenticate parties who 2658 have certificates signed by a trusted certificate authority. 2660 F.1.1 Authentication and key exchange 2662 SSL supports three authentication modes: authentication of both 2663 parties, server authentication with an unauthenticated client, and 2664 total anonymity. Whenever the server is authenticated, the channel 2665 should be secure against man-in- the-middle attacks, but completely 2666 anonymous sessions are inherently vulnerable to such attacks. 2667 Anonymous servers cannot authenticate clients, since the client 2668 signature in the certificate verify message may require a server 2669 certificate to bind the signature to a particular server. If the 2670 server is authenticated, its certificate message must provide a 2671 valid certificate chain leading to an acceptable certificate 2672 authority. Similarly, authenticated clients must supply an 2673 acceptable certificate to the server. Each party is responsible 2674 for verifying that the other's certificate is valid and has not 2675 expired or been revoked. 2677 The general goal of the key exchange process is to create a 2678 pre_master_secret known to the communicating parties and not to 2679 attackers. The pre_master_secret will be used to generate the 2680 master_secret (see Section 6.1). The master_secret is required to 2681 generate the finished messages, encryption keys, and MAC secrets 2682 (see Sections 5.6.9 and 6.2.2). By sending a correct finished 2683 message, parties thus prove that they know the correct 2684 pre_master_secret. 2686 F.1.1.1 Anonymous key exchange 2688 Completely anonymous sessions can be established using RSA, 2689 Diffie-Hellman, or FORTEZZA for key exchange. With anonymous RSA, 2690 the client encrypts a pre_master_secret with the server's 2691 uncertified public key extracted from the server key exchange 2692 message. The result is sent in a client key exchange message. 2693 Since eavesdroppers do not know the server's private key, it will 2694 be infeasible for them to decode the pre_master_secret. 2696 With Diffie-Hellman or FORTEZZA, the server's public parameters are 2697 contained in the server key exchange message and the client's are 2698 sent in the client key exchange message. Eavesdroppers who do not 2699 know the private values should not be able to find the 2700 Diffie-Hellman result (i.e. the pre_master_secret) or the FORTEZZA 2701 token encryption key (TEK). 2703 Warning: Completely anonymous connections only provide 2704 protection against passive eavesdropping. Unless an 2705 independent tamper-proof channel is used to verify 2706 that the finished messages were not replaced by an 2707 attacker, server authentication is required in 2708 environments where active man-in-the-middle attacks 2709 are a concern. 2711 F.1.1.2 RSA key exchange and authentication 2713 With RSA, key exchange and server authentication are combined. The 2714 public key may be either contained in the server's certificate or 2715 may be a temporary RSA key sent in a server key exchange message. 2716 When temporary RSA keys are used, they are signed by the server's 2717 RSA or DSS certificate. The signature includes the current 2718 ClientHello.random, so old signatures and temporary keys cannot be 2719 replayed. Servers may use a single temporary RSA key for multiple 2720 negotiation sessions. 2722 Note: The temporary RSA key option is useful if servers 2723 need large certificates but must comply with 2724 government-imposed size limits on keys used for key 2725 exchange. 2727 After verifying the server's certificate, the client encrypts a 2728 pre_master_secret with the server's public key. By successfully 2729 decoding the pre_master_secret and producing a correct finished 2730 message, the server demonstrates that it knows the private key 2731 corresponding to the server certificate. 2733 When RSA is used for key exchange, clients are authenticated using 2734 the certificate verify message (see Section 5.6.8). The client 2735 signs a value derived from the master_secret and all preceding 2736 handshake messages. These handshake messages include the server 2737 certificate, which binds the signature to the server, and 2738 ServerHello.random, which binds the signature to the current 2739 handshake process. 2741 F.1.1.3 Diffie-Hellman key exchange with authentication 2743 When Diffie-Hellman key exchange is used, the server can either 2744 supply a certificate containing fixed Diffie-Hellman parameters or 2745 can use the server key exchange message to send a set of temporary 2746 Diffie-Hellman parameters signed with a DSS or RSA certificate. 2747 Temporary parameters are hashed with the hello.random values before 2748 signing to ensure that attackers do not replay old parameters. In 2749 either case, the client can verify the certificate or signature to 2750 ensure that the parameters belong to the server. 2752 If the client has a certificate containing fixed Diffie- Hellman 2753 parameters, its certificate contains the information required to 2754 complete the key exchange. Note that in this case the client and 2755 server will generate the same Diffie- Hellman result (i.e., 2756 pre_master_secret) every time they communicate. To prevent the 2757 pre_master_secret from staying in memory any longer than necessary, 2758 it should be converted into the master_secret as soon as possible. 2759 Client Diffie- Hellman parameters must be compatible with those 2760 supplied by the server for the key exchange to work. 2762 If the client has a standard DSS or RSA certificate or is 2763 unauthenticated, it sends a set of temporary parameters to the 2764 server in the client key exchange message, then optionally uses a 2765 certificate verify message to authenticate itself. 2767 F.1.1.4 FORTEZZA 2769 FORTEZZA's design is classified, but at the protocol level it is 2770 similar to Diffie-Hellman with fixed public values contained in 2771 certificates. The result of the key exchange process is the token 2772 encryption key (TEK), which is used to wrap data encryption keys, 2773 client write key, server write key, and master secret encryption 2774 key. The data encryption keys are not derived from the 2775 pre_master_secret because unwrapped keys are not accessible outside 2776 the token. The encrypted pre_master_secret is sent to the server 2777 in a client key exchange message. 2779 F.1.2 Version rollback attacks 2781 Because SSL Version 3.0 includes substantial improvements over SSL 2782 Version 2.0, attackers may try to make Version 3.0- capable clients 2783 and servers fall back to Version 2.0. This attack is occurring if 2784 (and only if) two Version 3.0-capable parties use an SSL 2.0 2785 handshake. 2787 Although the solution using non-random PKCS #1 block type 2 message 2788 padding is inelegant, it provides a reasonably secure way for 2789 Version 3.0 servers to detect the attack. This solution is not 2790 secure against attackers who can brute force the key and substitute 2791 a new ENCRYPTED-KEY-DATA message containing the same key (but with 2792 normal padding) before the application specified wait threshold has 2793 expired. Parties concerned about attacks of this scale should not 2794 be using 40-bit encryption keys anyway. Altering the padding of 2795 the least-significant 8 bytes of the PKCS padding does not impact 2796 security, since this is essentially equivalent to increasing the 2797 input block size by 8 bytes. 2799 F.1.3 Detecting attacks against the handshake protocol 2801 An attacker might try to influence the handshake exchange to make 2802 the parties select different encryption algorithms than they would 2803 normally choose. Because many implementations will support 40-bit 2804 exportable encryption and some may even support null encryption or 2805 MAC algorithms, this attack is of particular concern. 2807 For this attack, an attacker must actively change one or more 2808 handshake messages. If this occurs, the client and server will 2809 compute different values for the handshake message hashes. As a 2810 result, the parties will not accept each others' finished messages. 2811 Without the master_secret, the attacker cannot repair the finished 2812 messages, so the attack will be discovered. 2814 F.1.4 Resuming sessions 2816 When a connection is established by resuming a session, new 2817 ClientHello.random and ServerHello.random values are hashed with 2818 the session's master_secret. Provided that the master_secret has 2819 not been compromised and that the secure hash operations used to 2820 produce the encryption keys and MAC secrets are secure, the 2821 connection should be secure and effectively independent from 2822 previous connections. Attackers cannot use known encryption keys 2823 or MAC secrets to compromise the master_secret without breaking the 2824 secure hash operations (which use both SHA and MD5). 2826 Sessions cannot be resumed unless both the client and server agree. 2827 If either party suspects that the session may have been 2828 compromised, or that certificates may have expired or been revoked, 2829 it should force a full handshake. An upper limit of 24 hours is 2830 suggested for session ID lifetimes, since an attacker who obtains a 2831 master_secret may be able to impersonate the compromised party 2832 until the corresponding session ID is retired. Applications that 2833 may be run in relatively insecure environments should not write 2834 session IDs to stable storage. 2836 F.1.5 MD5 and SHA 2838 SSL uses hash functions very conservatively. Where possible, both 2839 MD5 and SHA are used in tandem to ensure that non- catastrophic 2840 flaws in one algorithm will not break the overall protocol. 2842 F.2 Protecting application data 2844 The master_secret is hashed with the ClientHello.random and 2845 ServerHello.random to produce unique data encryption keys and MAC 2846 secrets for each connection. FORTEZZA encryption keys are 2847 generated by the token, and are not derived from the master_secret. 2849 Outgoing data is protected with a MAC before transmission. To 2850 prevent message replay or modification attacks, the MAC is computed 2851 from the MAC secret, the sequence number, the message length, the 2852 message contents, and two fixed character strings. The message 2853 type field is necessary to ensure that messages intended for one 2854 SSL Record Layer client are not redirected to another. The 2855 sequence number ensures that attempts to delete or reorder messages 2856 will be detected. Since sequence numbers are 64-bits long, they 2857 should never overflow. Messages from one party cannot be inserted 2858 into the other's output, since they use independent MAC secrets. 2859 Similarly, the server-write and client-write keys are independent 2860 so stream cipher keys are used only once. 2862 If an attacker does break an encryption key, all messages encrypted 2863 with it can be read. Similarly, compromise of a MAC key can make 2864 message modification attacks possible. Because MACs are also 2865 encrypted, message-alteration attacks generally require breaking 2866 the encryption algorithm as well as the MAC. 2868 Note: MAC secrets may be larger than encryption keys, so 2869 messages can remain tamper resistant even if 2870 encryption keys are broken. 2872 F.3 Final notes 2874 For SSL to be able to provide a secure connection, both the client 2875 and server systems, keys, and applications must be secure. In 2876 addition, the implementation must be free of security errors. 2878 The system is only as strong as the weakest key exchange and 2879 authentication algorithm supported, and only trustworthy 2880 cryptographic functions should be used. Short public keys, 40-bit 2881 bulk encryption keys, and anonymous servers should be used with 2882 great caution. Implementations and users must be careful when 2883 deciding which certificates and certificate authorities are 2884 acceptable; a dishonest certificate authority can do tremendous 2885 damage. 2887 Appendix G 2889 G. Patent Statement 2891 This version of the SSL protocol relies on the use of patented 2892 public key encryption technology for authentication and encryption. 2893 The Internet Standards Process as defined in RFC 1310 requires a 2894 written statement from the Patent holder that a license will be 2895 made available to applicants under reasonable terms and conditions 2896 prior to approving a specification as a Proposed, Draft or Internet 2897 Standard. The Massachusetts Institute of Technology has granted 2898 RSA Data Security, Inc., exclusive sub-licensing rights to the 2899 following patent issued in the United States: 2901 Cryptographic Communications System and Method ("RSA"), 2902 No. 4,405,829 2904 The Board of Trustees of the Leland Stanford Junior University have 2905 granted Caro-Kann Corporation, a wholly owned subsidiary 2906 corporation, exclusive sub-licensing rights to the following 2907 patents issued in the United States, and all of their corresponding 2908 foreign patents: 2910 Cryptographic Apparatus and Method ("Diffie-Hellman"), 2911 No. 4,200,770 2913 Public Key Cryptographic Apparatus and Method ("Hellman- 2914 Merkle"), No. 4,218,582 2916 The Internet Society, Internet Architecture Board, Internet 2917 Engineering Steering Group and the Corporation for National 2918 Research Initiatives take no position on the validity or scope of 2919 the patents and patent applications, nor on the appropriateness of 2920 the terms of the assurance. The Internet Society and other groups 2921 mentioned above have not made any determination as to any other 2922 intellectual property rights which may apply to the practice of 2923 this standard. Any further consideration of these matters is the 2924 user's own responsibility. 2926 References 2928 [DH1] W. Diffie and M. E. Hellman, "New Directions in 2929 Cryptography," IEEE Transactions on Information Theory, V. 2930 IT-22, n. 6, Jun 1977, pp. 74-84. 2932 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions 2933 To DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. 2935 [DES] ANSI X3.106, "American National Standard for 2936 Information Systems-Data Link Encryption," American National 2937 Standards Institute, 1983. 2939 [DSS] NIST FIPS PUB 186, "Digital Signature Standard," 2940 National Institute of Standards and Technology, U.S. 2941 Department of Commerce, 18 May 1994. 2943 [FOR] NSA X22, Document # PD4002103-1.01, "FORTEZZA: 2944 Application Implementers Guide," April 6, 1995. 2946 [FTP] J. Postel and J. Reynolds, RFC 959: File Transfer 2947 Protocol, October 1985. 2949 [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext 2950 Transfer Protocol -- HTTP/1.0, October, 1995. 2952 [IDEA] X. Lai, "On the Design and Security of Block 2953 Ciphers," ETH Series in Information Processing, v. 1, 2954 Konstanz: Hartung-Gorre Verlag, 1992. 2956 [KRAW] H. Krawczyk, IETF Draft: Keyed-MD5 for Message 2957 Authentication, November 1995. 2959 [MD2] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. 2960 April 1992. 2962 [MD5] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. 2963 April 1992. 2965 [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption 2966 Standard," version 1.5, November 1993. 2968 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate 2969 Syntax Standard," version 1.5, November 1993. 2971 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic 2972 Message Syntax Standard," version 1.5, November 1993. 2974 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for 2975 Obtaining Digital Signatures and Public-Key Cryptosystems," 2976 Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120- 2977 126. 2979 [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 2980 [SCH] B. Schneier. Applied Cryptography: Protocols, 2981 Algorithms, and Source Code in C, Published by John Wiley & 2982 Sons, Inc. 1994. 2984 [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National 2985 Institute of Standards and Technology, U.S. Department of 2986 Commerce, DRAFT, 31 May 1994. 2987 [TCP] ISI for DARPA, RFC 793: Transport Control Protocol, 2988 September 1981. 2990 [TEL] J. Postel and J. Reynolds, RFC 854/5, May, 1993. 2991 [X509] CCITT. Recommendation X.509: "The Directory - 2992 Authentication Framework". 1988. 2994 [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: 2995 External Data Representation Standard, August 1995. 2997 Authors 2999 Alan O. Freier Paul C. Kocher 3000 Netscape Communications Independent Consultant 3001 freier@netscape.com pck@netcom.com 3003 Philip L. Karlton 3004 Netscape Communications 3005 karlton@netscape.com 3007 Other contributors 3009 Martin Abadi Robert Relyea 3010 Digital Equipment Corporation Netscape Communications 3011 ma@pa.dec.com relyea@netscape.com 3013 Taher Elgamal Jim Roskind 3014 Netscape Communications Netscape Communications 3015 elgamal@netscape.com jar@netscape.com 3017 Anil Gangolli Micheal J. Sabin, Ph. D. 3018 Netscape Communications Consulting Engineer 3019 gangolli@netscape.com msabin@netcom.com 3021 Kipp E.B. Hickman Tom Weinstein 3022 Netscape Communications Netscape Communications 3023 kipp@netscape.com tomw@netscape.com 3025 Early reviewers 3027 Robert Baldwin Clyde Monma 3028 RSA Data Security, Inc. Bellcore 3029 baldwin@rsa.com clyde@bellcore.com 3031 George Cox Eric Murray 3032 Intel Corporation ericm@lne.com 3033 cox@ibeam.jf.intel.com 3035 Cheri Dowell Avi Rubin 3036 Sun Microsystems Bellcore 3037 cheri@eng.sun.com rubin@bellcore.com 3039 Stuart Haber Don Stephenson 3040 Bellcore Sun Microsystems 3041 stuart@bellcore.com don.stephenson@eng.sun.com 3043 Burt Kaliski Joe Tardo 3044 RSA Data Security, Inc. General Magic 3045 burt@rsa.com tardo@genmagic.com 3046 Send all written communication about this document to: 3047 Netscape Communications 3048 501 East Middlefield Rd. 3049 Mountain View, CA 94043 3050 Attn: Alan Freier