idnits 2.17.1 draft-mavrogiannopoulos-ssl-version3-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1455 has weird spacing: '...gnature y_sig...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 10, 2011) is 4701 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: Historic ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 279 -- Looks like a reference, but probably isn't: '1' on line 279 -- Looks like a reference, but probably isn't: '3' on line 2617 -- Looks like a reference, but probably isn't: '9' on line 311 -- Looks like a reference, but probably isn't: '2' on line 1959 -- Looks like a reference, but probably isn't: '4' on line 345 -- Looks like a reference, but probably isn't: '8' on line 346 -- Looks like a reference, but probably isn't: '10' on line 438 -- Looks like a reference, but probably isn't: '20' on line 2092 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 968, but not defined -- Looks like a reference, but probably isn't: '28' on line 1954 -- Looks like a reference, but probably isn't: '128' on line 2065 -- Looks like a reference, but probably isn't: '16' on line 2091 -- Looks like a reference, but probably isn't: '46' on line 2056 -- Looks like a reference, but probably isn't: '40' on line 2066 -- Looks like a reference, but probably isn't: '12' on line 2068 -- Looks like a reference, but probably isn't: '24' on line 2071 -- Looks like a reference, but probably isn't: '48' on line 2072 == Unused Reference: '3DES' is defined on line 1766, but no explicit reference was found in the text == Unused Reference: 'RFC0959' is defined on line 1780, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 1783, but no explicit reference was found in the text == Unused Reference: 'RFC1945' is defined on line 1786, but no explicit reference was found in the text == Unused Reference: 'RFC1319' is defined on line 1789, but no explicit reference was found in the text == Unused Reference: 'RFC0854' is defined on line 1798, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1804, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 1808, but no explicit reference was found in the text == Unused Reference: 'SCH' is defined on line 1826, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1319 (Obsoleted by RFC 6149) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1832 (Obsoleted by RFC 4506) Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Freier 3 Internet-Draft P. Karlton 4 Intended status: Historic Netscape communications 5 Expires: December 12, 2011 P. Kocher 6 Independent consultant 7 June 10, 2011 9 The SSL Protocol Version 3.0 10 draft-mavrogiannopoulos-ssl-version3-06 12 Abstract 14 This document specifies Version 3.0 of the Secure Sockets Layer (SSL 15 V3.0) protocol, a security protocol that provides communications 16 privacy over the Internet. The protocol allows client/server 17 applications to communicate in a way that is designed to prevent 18 eavesdropping, tampering, or message forgery. 20 Foreword 22 Although the SSL 3.0 protocol is a widely implemented protocol, a 23 pioneer in secure communications protocols, and the basis for TLS it 24 was never formally published by IETF, except in several expired 25 internet-drafts. This allowed no easy referencing to the protocol. 26 We believe a stable reference to the original document should exist 27 and for that reason, this document describes what is known as the 28 last published version of the SSL 3.0 protocol. That is the November 29 18, 1996 version of the protocol. 31 There were no changes to the original document other than trivial 32 editorial changes and the addition of a "Security considerations" 33 section. However portions of the original draft that no longer apply 34 were not included. Such are the "Patent statement" section, the 35 "Reserved ports assignment" section and the cipher-suite registrator 36 note in the "The CipherSuite" section. The "US export rules" 37 discussed in the document do not apply today but are kept intact to 38 provide context for decisions taken in protocol design. The "Goals 39 of This Document" section indicates the goals for adopters of SSL 40 3.0, not goals of the IETF. 42 The authors and editors were retained as in the original document. 43 The editor of this document is Nikos Mavrogiannopoulos 44 (nikos.mavrogiannopoulos@esat.kuleuven.be). The editor would like to 45 thank Dan Harkins, Linda Dunbar, Sean Turner, and Geoffrey Keating 46 for reviewing this document and providing helpful comments. 48 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on December 12, 2011. 64 Copyright Notice 66 Copyright (c) 2011 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 This document may contain material from IETF Documents or IETF 80 Contributions published or made publicly available before November 81 10, 2008. The person(s) controlling the copyright in some of this 82 material may not have granted the IETF Trust the right to allow 83 modifications of such material outside the IETF Standards Process. 84 Without obtaining an adequate license from the person(s) controlling 85 the copyright in such materials, this document may not be modified 86 outside the IETF Standards Process, and derivative works of it may 87 not be created outside the IETF Standards Process, except to format 88 it for publication as an RFC or to translate it into languages other 89 than English. 91 Table of Contents 93 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 94 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 95 3. Goals of this document . . . . . . . . . . . . . . . . . . . . 6 96 4. Presentation language . . . . . . . . . . . . . . . . . . . . 6 97 4.1. Basic block size . . . . . . . . . . . . . . . . . . . . . 6 98 4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 7 99 4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 7 100 4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 8 101 4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 8 102 4.6. Constructed types . . . . . . . . . . . . . . . . . . . . 9 103 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . . 9 104 4.7. Cryptographic attributes . . . . . . . . . . . . . . . . . 11 105 4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 11 106 5. SSL protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12 107 5.1. Session and connection states . . . . . . . . . . . . . . 12 108 5.2. Record layer . . . . . . . . . . . . . . . . . . . . . . . 13 109 5.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 14 110 5.2.2. Record compression and decompression . . . . . . . . . 14 111 5.2.3. Record payload protection and the CipherSpec . . . . . 15 112 5.3. Change cipher spec protocol . . . . . . . . . . . . . . . 18 113 5.4. Alert protocol . . . . . . . . . . . . . . . . . . . . . . 18 114 5.4.1. Closure alerts . . . . . . . . . . . . . . . . . . . . 19 115 5.4.2. Error alerts . . . . . . . . . . . . . . . . . . . . . 20 116 5.5. Handshake protocol overview . . . . . . . . . . . . . . . 21 117 5.6. Handshake protocol . . . . . . . . . . . . . . . . . . . . 23 118 5.6.1. Hello messages . . . . . . . . . . . . . . . . . . . . 24 119 5.6.2. Server certificate . . . . . . . . . . . . . . . . . . 28 120 5.6.3. Server key exchange message . . . . . . . . . . . . . 28 121 5.6.4. Certificate request . . . . . . . . . . . . . . . . . 30 122 5.6.5. Server hello done . . . . . . . . . . . . . . . . . . 31 123 5.6.6. Client certificate . . . . . . . . . . . . . . . . . . 31 124 5.6.7. Client key exchange message . . . . . . . . . . . . . 31 125 5.6.8. Certificate verify . . . . . . . . . . . . . . . . . . 34 126 5.6.9. Finished . . . . . . . . . . . . . . . . . . . . . . . 35 127 5.7. Application data protocol . . . . . . . . . . . . . . . . 35 128 6. Cryptographic computations . . . . . . . . . . . . . . . . . . 36 129 6.1. Asymmetric cryptographic computations . . . . . . . . . . 36 130 6.1.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 36 131 6.1.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . . 36 132 6.1.3. FORTEZZA . . . . . . . . . . . . . . . . . . . . . . . 37 133 6.2. Symmetric cryptographic calculations and the CipherSpec . 37 134 6.2.1. The master secret . . . . . . . . . . . . . . . . . . 37 135 6.2.2. Converting the master secret into keys and MAC 136 secrets . . . . . . . . . . . . . . . . . . . . . . . 37 137 7. Security considerations . . . . . . . . . . . . . . . . . . . 39 138 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 39 139 9. Informative References . . . . . . . . . . . . . . . . . . . . 40 140 Appendix A. Protocol constant values . . . . . . . . . . . . . . 41 141 A.1. Record layer . . . . . . . . . . . . . . . . . . . . . . . 41 142 A.2. Change cipher specs message . . . . . . . . . . . . . . . 43 143 A.3. Alert messages . . . . . . . . . . . . . . . . . . . . . . 43 144 A.4. Handshake protocol . . . . . . . . . . . . . . . . . . . . 43 145 A.4.1. Hello messages . . . . . . . . . . . . . . . . . . . . 44 146 A.4.2. Server authentication and key exchange messages . . . 45 147 A.5. Client authentication and key exchange messages . . . . . 47 148 A.5.1. Handshake finalization message . . . . . . . . . . . . 48 149 A.6. The CipherSuite . . . . . . . . . . . . . . . . . . . . . 48 150 A.7. The CipherSpec . . . . . . . . . . . . . . . . . . . . . . 49 151 Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . 50 152 Appendix C. CipherSuite definitions . . . . . . . . . . . . . . . 53 153 Appendix D. Implementation Notes . . . . . . . . . . . . . . . . 55 154 D.1. Temporary RSA keys . . . . . . . . . . . . . . . . . . . . 56 155 D.2. Random Number Generation and Seeding . . . . . . . . . . . 56 156 D.3. Certificates and authentication . . . . . . . . . . . . . 57 157 D.4. CipherSuites . . . . . . . . . . . . . . . . . . . . . . . 57 158 D.5. FORTEZZA . . . . . . . . . . . . . . . . . . . . . . . . . 57 159 D.5.1. Notes on use of FORTEZZA hardware . . . . . . . . . . 57 160 D.5.2. FORTEZZA Ciphersuites . . . . . . . . . . . . . . . . 58 161 D.5.3. FORTEZZA Session resumption . . . . . . . . . . . . . 58 162 Appendix E. Version 2.0 Backward Compatibility . . . . . . . . . 58 163 E.1. Version 2 client hello . . . . . . . . . . . . . . . . . . 59 164 E.2. Avoiding man-in-the-middle version rollback . . . . . . . 61 165 Appendix F. Security analysis . . . . . . . . . . . . . . . . . . 61 166 F.1. Handshake protocol . . . . . . . . . . . . . . . . . . . . 61 167 F.1.1. Authentication and key exchange . . . . . . . . . . . 61 168 F.1.2. Version rollback attacks . . . . . . . . . . . . . . . 64 169 F.1.3. Detecting attacks against the handshake protocol . . . 64 170 F.1.4. Resuming sessions . . . . . . . . . . . . . . . . . . 65 171 F.1.5. MD5 and SHA . . . . . . . . . . . . . . . . . . . . . 65 172 F.2. Protecting application data . . . . . . . . . . . . . . . 65 173 F.3. Final notes . . . . . . . . . . . . . . . . . . . . . . . 66 174 Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 66 175 G.1. Other contributors . . . . . . . . . . . . . . . . . . . . 66 176 G.2. Early reviewers . . . . . . . . . . . . . . . . . . . . . 67 178 1. Introduction 180 The primary goal of the SSL Protocol is to provide privacy and 181 reliability between two communicating applications. The protocol is 182 composed of two layers. At the lowest level, layered on top of some 183 reliable transport protocol (e.g., TCP[RFC0793]), is the SSL Record 184 Protocol. The SSL Record Protocol is used for encapsulation of 185 various higher level protocols. One such encapsulated protocol, the 186 SSL Handshake Protocol, allows the server and client to authenticate 187 each other and to negotiate an encryption algorithm and cryptographic 188 keys before the application protocol transmits or receives its first 189 byte of data. One advantage of SSL is that it is application 190 protocol independent. A higher level protocol can layer on top of 191 the SSL Protocol transparently. The SSL protocol provides connection 192 security that has three basic properties: 194 o The connection is private. Encryption is used after an initial 195 handshake to define a secret key. Symmetric cryptography is used 196 for data encryption (e.g., DES[DES], RC4[RSADSI], etc.) 198 o The peer's identity can be authenticated using asymmetric, or 199 public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.). 201 o The connection is reliable. Message transport includes a message 202 integrity check using a keyed MAC. Secure hash functions (e.g., 203 SHA, MD5, etc.) are used for MAC computations. 205 2. Goals 207 The goals of SSL Protocol v3.0, in order of their priority, are: 209 1. Cryptographic security 211 SSL should be used to establish a secure connection between 212 two parties. 214 2. Interoperability 216 Independent programmers should be able to develop applications 217 utilizing SSL 3.0 that will then be able to successfully 218 exchange cryptographic parameters without knowledge of one 219 another's code. 221 Note: It is not the case that all instances of SSL (even in 222 the same application domain) will be able to successfully 223 connect. For instance, if the server supports a particular 224 hardware token, and the client does not have access to such a 225 token, then the connection will not succeed. 227 3. Extensibility 229 SSL seeks to provide a framework into which new public key and 230 bulk encryption methods can be incorporated as necessary. 231 This will also accomplish two sub-goals: to prevent the need 232 to create a new protocol (and risking the introduction of 233 possible new weaknesses) and to avoid the need to implement an 234 entire new security library. 236 4. Relative efficiency 238 Cryptographic operations tend to be highly CPU intensive, 239 particularly public key operations. For this reason, the SSL 240 protocol has incorporated an optional session caching scheme 241 to reduce the number of connections that need to be 242 established from scratch. Additionally, care has been taken 243 to reduce network activity. 245 3. Goals of this document 247 The SSL Protocol Version 3.0 Specification is intended primarily for 248 readers who will be implementing the protocol and those doing 249 cryptographic analysis of it. The spec has been written with this in 250 mind, and it is intended to reflect the needs of those two groups. 251 For that reason, many of the algorithm-dependent data structures and 252 rules are included in the body of the text (as opposed to in an 253 Appendix), providing easier access to them. 255 This document is not intended to supply any details of service 256 definition nor interface definition, although it does cover select 257 areas of policy as they are required for the maintenance of solid 258 security. 260 4. Presentation language 262 This document deals with the formatting of data in an external 263 representation. The following very basic and somewhat casually 264 defined presentation syntax will be used. The syntax draws from 265 several sources in its structure. Although it resembles the 266 programming language "C" in its syntax and XDR [RFC1832] in both its 267 syntax and intent, it would be risky to draw too many parallels. The 268 purpose of this presentation language is to document SSL only, not to 269 have general application beyond that particular goal. 271 4.1. Basic block size 273 The representation of all data items is explicitly specified. The 274 basic data block size is one byte (i.e. 8 bits). Multiple byte data 275 items are concatenations of bytes, from left to right, from top to 276 bottom. From the bytestream a multi-byte item (a numeric in the 277 example) is formed (using C notation) by: 279 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ... 280 | byte[n-1]; 282 This byte ordering for multi-byte values is the commonplace network 283 byte order or big endian format. 285 4.2. Miscellaneous 287 Comments begin with "/*" and end with "*/". Optional components are 288 denoted by enclosing them in "[[ ]]" double brackets. Single byte 289 entities containing uninterpreted data are of type opaque. 291 4.3. Vectors 293 A vector (single dimensioned array) is a stream of homogeneous data 294 elements. The size of the vector may be specified at documentation 295 time or left unspecified until runtime. In either case the length 296 declares the number of bytes, not the number of elements, in the 297 vector. The syntax for specifying a new type T' that is a fixed 298 length vector of type T is 300 T T'[n]; 302 Here T' occupies n bytes in the data stream, where n is a multiple of 303 the size of T. The length of the vector is not included in the 304 encoded stream. 306 In the following example, Datum is defined to be three consecutive 307 bytes that the protocol does not interpret, while Data is three 308 consecutive Datum, consuming a total of nine bytes. 310 opaque Datum[3]; /* three uninterpreted bytes */ 311 Datum Data[9]; /* 3 consecutive 3 byte vectors */ 313 Variable length vectors are defined by specifying a subrange of legal 314 lengths, inclusively, using the notation . When 315 encoded, the actual length precedes the vector's contents in the byte 316 stream. The length will be in the form of a number consuming as many 317 bytes as required to hold the vector's specified maximum (ceiling) 318 length. A variable length vector with an actual length field of zero 319 is referred to as an empty vector. 321 T T'; 323 In the following example, mandatory is a vector that must contain 324 between 300 and 400 bytes of type opaque. It can never be empty. 325 The actual length field consumes two bytes, a uint16, sufficient to 326 represent the value 400 (see Section 4.4). On the other hand, longer 327 can represent up to 800 bytes of data, or 400 uint16 elements, and it 328 may be empty. Its encoding will include a two byte actual length 329 field prepended to the vector. 331 opaque mandatory<300..400>; 332 /* length field is 2 bytes, cannot be empty */ 333 uint16 longer<0..800>; 334 /* zero to 400 16-bit unsigned integers */ 336 4.4. Numbers 338 The basic numeric data type is an unsigned byte (uint8). All larger 339 numeric data types are formed from fixed length series of bytes 340 concatenated as described in Section 4.1 and are also unsigned. The 341 following numeric types are predefined. 343 uint8 uint16[2]; 344 uint8 uint24[3]; 345 uint8 uint32[4]; 346 uint8 uint64[8]; 348 4.5. Enumerateds 350 An additional sparse data type is available called enum. A field of 351 type enum can only assume the values declared in the definition. 352 Each definition is a different type. Only enumerateds of the same 353 type may be assigned or compared. Every element of an enumerated 354 must be assigned a value, as demonstrated in the following example. 355 Since the elements of the enumerated are not ordered, they can be 356 assigned any unique value, in any order. 358 enum { e1(v1), e2(v2), ... , en(vn), [[(n)]] } Te; 360 Enumerateds occupy as much space in the byte stream as would its 361 maximal defined ordinal value. The following definition would cause 362 one byte to be used to carry fields of type Color. 364 enum { red(3), blue(5), white(7) } Color; 366 One may optionally specify a value without its associated tag to 367 force the width definition without defining a superfluous element. 368 In the following example, Taste will consume two bytes in the data 369 stream but can only assume the values 1, 2 or 4. 371 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 373 The names of the elements of an enumeration are scoped within the 374 defined type. In the first example, a fully qualified reference to 375 the second element of the enumeration would be Color.blue. Such 376 qualification is not required if the target of the assignment is well 377 specified. 379 Color color = Color.blue; /* overspecified, legal */ 380 Color color = blue; /* correct, type implicit */ 382 For enumerateds that are never converted to external representation, 383 the numerical information may be omitted. 385 enum { low, medium, high } Amount; 387 4.6. Constructed types 389 Structure types may be constructed from primitive types for 390 convenience. Each specification declares a new, unique type. The 391 syntax for definition is much like that of C. 393 struct { 394 T1 f1; 395 T2 f2; 396 ... 397 Tn fn; 398 } [[T]]; 400 The fields within a structure may be qualified using the type's name 401 using a syntax much like that available for enumerateds. For 402 example, T.f2 refers to the second field of the previous declaration. 403 Structure definitions may be embedded. 405 4.6.1. Variants 407 Defined structures may have variants based on some knowledge that is 408 available within the environment. The selector must be an enumerated 409 type that defines the possible variants the structure defines. There 410 must be a case arm for every element of the enumeration declared in 411 the select. The body of the variant structure may be given a label 412 for reference. The mechanism by which the variant is selected at 413 runtime is not prescribed by the presentation language. 415 struct { 416 T1 f1; 417 T2 f2; 418 .... 419 Tn fn; 420 select (E) { 421 case e1: Te1; 422 case e2: Te2; 423 .... 424 case en: Ten; 425 } [[fv]]; 426 } [[Tv]]; 428 For example 430 enum { apple, orange } VariantTag; 431 struct { 432 uint16 number; 433 opaque string<0..10>; /* variable length */ 434 } V1; 436 struct { 437 uint32 number; 438 opaque string[10]; /* fixed length */ 439 } V2; 440 struct { 441 select (VariantTag) { /* value of selector is implicit */ 442 case apple: V1; /* VariantBody, tag = apple */ 443 case orange: V2; /* VariantBody, tag = orange */ 444 } variant_body; /* optional label on variant */ 445 } VariantRecord; 447 Variant structures may be qualified (narrowed) by specifying a value 448 for the selector prior to the type. For example, a 450 orange VariantRecord 452 is a narrowed type of a VariantRecord containing a variant_body of 453 type V2. 455 4.7. Cryptographic attributes 457 The four cryptographic operations digital signing, stream cipher 458 encryption, block cipher encryption, and public key encryption are 459 designated digitally-signed, stream-ciphered, block-ciphered, and 460 public-key-encrypted, respectively. A field's cryptographic 461 processing is specified by prepending an appropriate key word 462 designation before the field's type specification. Cryptographic 463 keys are implied by the current session state (see Section 5.1). 465 In digital signing, one-way hash functions are used as input for a 466 signing algorithm. In RSA signing, a 36-byte structure of two hashes 467 (one SHA and one MD5) is signed (encrypted with the private key). In 468 DSS, the 20 bytes of the SHA hash are run directly through the 469 Digital Signing Algorithm with no additional hashing. 471 In stream cipher encryption, the plaintext is exclusive-ORed with an 472 identical amount of output generated from a cryptographically-secure 473 keyed pseudorandom number generator. 475 In block cipher encryption, every block of plaintext encrypts to a 476 block of ciphertext. Because it is unlikely that the plaintext 477 (whatever data is to be sent) will break neatly into the necessary 478 block size (usually 64 bits), it is necessary to pad out the end of 479 short blocks with some regular pattern, usually all zeroes. 481 In public key encryption, one-way functions with secret "trapdoors" 482 are used to encrypt the outgoing data. Data encrypted with the 483 public key of a given key pair can only be decrypted with the private 484 key, and vice-versa. In the following example: 486 stream-ciphered struct { 487 uint8 field1; 488 uint8 field2; 489 digitally-signed opaque hash[20]; 490 } UserType; 492 The contents of hash are used as input for the signing algorithm, 493 then the entire structure is encrypted with a stream cipher. 495 4.8. Constants 497 Typed constants can be defined for purposes of specification by 498 declaring a symbol of the desired type and assigning values to it. 499 Under-specified types (opaque, variable length vectors, and 500 structures that contain opaque) cannot be assigned values. No fields 501 of a multi-element structure or vector may be elided. 503 For example, 504 struct { 505 uint8 f1; 506 uint8 f2; 507 } Example1; 509 Example1 ex1 = {1, 4};/* assigns f1 = 1, f2 = 4 */ 511 5. SSL protocol 513 SSL is a layered protocol. At each layer, messages may include 514 fields for length, description, and content. SSL takes messages to 515 be transmitted, fragments the data into manageable blocks, optionally 516 compresses the data, applies a MAC, encrypts, and transmits the 517 result. Received data is decrypted, verified, decompressed, and 518 reassembled, then delivered to higher level clients. 520 5.1. Session and connection states 522 An SSL session is stateful. It is the responsibility of the SSL 523 Handshake protocol to coordinate the states of the client and server, 524 thereby allowing the protocol state machines of each to operate 525 consistently, despite the fact that the state is not exactly 526 parallel. Logically the state is represented twice, once as the 527 current operating state, and (during the handshake protocol) again as 528 the pending state. Additionally, separate read and write states are 529 maintained. When the client or server receives a change cipher spec 530 message, it copies the pending read state into the current read 531 state. When the client or server sends a change cipher spec message, 532 it copies the pending write state into the current write state. When 533 the handshake negotiation is complete, the client and server exchange 534 change cipher spec messages (see Section 5.3), and they then 535 communicate using the newly agreed-upon cipher spec. 537 An SSL session may include multiple secure connections; in addition, 538 parties may have multiple simultaneous sessions. 540 The session state includes the following elements: 542 session identifier An arbitrary byte sequence chosen by the server 543 to identify an active or resumable session state. 545 peer certificate X509.v3[X509] certificate of the peer. This 546 element of the state may be null. 548 compression method The algorithm used to compress data prior to 549 encryption. 551 cipher spec Specifies the bulk data encryption algorithm (such as 552 null, DES, etc.) and a MAC algorithm (such as MD5 or SHA). It 553 also defines cryptographic attributes such as the hash_size. (See 554 Appendix A.7 for formal definition) 556 master secret 48-byte secret shared between the client and server. 558 is resumable A flag indicating whether the session can be used to 559 initiate new connections. 561 The connection state includes the following elements: 563 server and client random Byte sequences that are chosen by the 564 server and client for each connection. 566 server write MAC secret The secret used in MAC operations on data 567 written by the server 569 client write MAC secret The secret used in MAC operations on data 570 written by the client. 572 server write key The bulk cipher key for data encrypted by the 573 server and decrypted by the client. 575 client write key The bulk cipher key for data encrypted by the 576 client and decrypted by the server. 578 initialization vectors When a block cipher in CBC mode is used, an 579 initialization vector (IV) is maintained for each key. This field 580 is first initialized by the SSL handshake protocol. Thereafter 581 the final ciphertext block from each record is preserved for use 582 with the following record. 584 sequence numbers Each party maintains separate sequence numbers for 585 transmitted and received messages for each connection. When a 586 party sends or receives a change cipher spec message, the 587 appropriate sequence number is set to zero. Sequence numbers are 588 of type uint64 and may not exceed 2^64-1. 590 5.2. Record layer 592 The SSL Record Layer receives uninterpreted data from higher layers 593 in non-empty blocks of arbitrary size. 595 5.2.1. Fragmentation 597 The record layer fragments information blocks into SSLPlaintext 598 records of 2^14 bytes or less. Client message boundaries are not 599 preserved in the record layer (i.e., multiple client messages of the 600 same ContentType may be coalesced into a single SSLPlaintext record). 602 struct { 603 uint8 major, minor; 604 } ProtocolVersion; 606 enum { 607 change_cipher_spec(20), alert(21), handshake(22), 608 application_data(23), (255) 609 } ContentType; 611 struct { 612 ContentType type; 613 ProtocolVersion version; 614 uint16 length; 615 opaque fragment[SSLPlaintext.length]; 616 } SSLPlaintext; 618 type The higher level protocol used to process the enclosed 619 fragment. 621 version The version of protocol being employed. This document 622 describes SSL Version 3.0 (See Appendix A.1). 624 length The length (in bytes) of the following SSLPlaintext.fragment. 625 The length should not exceed 2^14. 627 fragment The application data. This data is transparent and treated 628 as an independent block to be dealt with by the higher level 629 protocol specified by the type field. 631 Note: Data of different SSL Record layer content types may be 632 interleaved. Application data is generally of lower precedence for 633 transmission than other content types. 635 5.2.2. Record compression and decompression 637 All records are compressed using the compression algorithm defined in 638 the current session state. There is always an active compression 639 algorithm, however initially it is defined as CompressionMethod.null. 640 The compression algorithm translates an SSLPlaintext structure into 641 an SSLCompressed structure. Compression functions erase their state 642 information whenever the CipherSpec is replaced. 644 Note: The CipherSpec is part of the session state described in 645 Section 5.1. References to fields of the CipherSpec are made 646 throughout this document using presentation syntax. A more complete 647 description of the CipherSpec is shown in Appendix A.7. 649 Compression must be lossless and may not increase the content length 650 by more than 1024 bytes. If the decompression function encounters an 651 SSLCompressed.fragment that would decompress to a length in excess of 652 2^14 bytes, it should issue a fatal decompression_failure alert 653 (Section 5.4.2). 655 struct { 656 ContentType type; /* same as SSLPlaintext.type */ 657 ProtocolVersion version;/* same as SSLPlaintext.version */ 658 uint16 length; 659 opaque fragment[SSLCompressed.length]; 660 } SSLCompressed; 662 length The length (in bytes) of the following 663 SSLCompressed.fragment. The length should not exceed 2^14 + 1024. 665 fragment The compressed form of SSLPlaintext.fragment. 667 Note: A CompressionMethod.null operation is an identity operation; no 668 fields are altered. (See Appendix A.4.1) 670 Implementation note: Decompression functions are responsible for 671 ensuring that messages cannot cause internal buffer overflows. 673 5.2.3. Record payload protection and the CipherSpec 675 All records are protected using the encryption and MAC algorithms 676 defined in the current CipherSpec. There is always an active 677 CipherSpec, however initially it is SSL_NULL_WITH_NULL_NULL, which 678 does not provide any security. 680 Once the handshake is complete, the two parties have shared secrets 681 which are used to encrypt records and compute keyed message 682 authentication codes (MACs) on their contents. The techniques used 683 to perform the encryption and MAC operations are defined by the 684 CipherSpec and constrained by CipherSpec.cipher_type. The encryption 685 and MAC functions translate an SSLCompressed structure into an 686 SSLCiphertext. The decryption functions reverse the process. 687 Transmissions also include a sequence number so that missing, 688 altered, or extra messages are detectable. 690 struct { 691 ContentType type; 692 ProtocolVersion version; 693 uint16 length; 694 select (CipherSpec.cipher_type) { 695 case stream: GenericStreamCipher; 696 case block: GenericBlockCipher; 697 } fragment; 698 } SSLCiphertext; 700 type The type field is identical to SSLCompressed.type. 702 version The version field is identical to SSLCompressed.version. 704 length The length (in bytes) of the following 705 SSLCiphertext.fragment. The length may not exceed 2^14 + 2048. 707 fragment The encrypted form of SSLCompressed.fragment, including the 708 MAC. 710 5.2.3.1. Null or standard stream cipher 712 Stream ciphers (including BulkCipherAlgorithm.null - see Appendix 713 A.7) convert SSLCompressed.fragment structures to and from stream 714 SSLCiphertext.fragment structures. 716 stream-ciphered struct { 717 opaque content[SSLCompressed.length]; 718 opaque MAC[CipherSpec.hash_size]; 719 } GenericStreamCipher; 721 The MAC is generated as: 723 hash(MAC_write_secret + pad_2 + 724 hash(MAC_write_secret + pad_1 + seq_num + 725 SSLCompressed.type + SSLCompressed.length + 726 SSLCompressed.fragment)); 728 where "+" denotes concatenation. 730 pad_1 The character 0x36 repeated 48 times for MD5 or 40 times for 731 SHA. 733 pad_2 The character 0x5c repeated 48 times for MD5 or 40 times for 734 SHA. 736 seq_num The sequence number for this message. 738 hash Hashing algorithm derived from the cipher suite. 740 Note that the MAC is computed before encryption. The stream cipher 741 encrypts the entire block, including the MAC. For stream ciphers 742 that do not use a synchronization vector (such as RC4), the stream 743 cipher state from the end of one record is simply used on the 744 subsequent packet. If the CipherSuite is SSL_NULL_WITH_NULL_NULL, 745 encryption consists of the identity operation (i.e., the data is not 746 encrypted and the MAC size is zero implying that no MAC is used). 747 SSLCiphertext.length is SSLCompressed.length plus 748 CipherSpec.hash_size. 750 5.2.3.2. CBC block cipher 752 For block ciphers (such as RC2 or DES), the encryption and MAC 753 functions convert SSLCompressed.fragment structures to and from block 754 SSLCiphertext.fragment structures. 756 block-ciphered struct { 757 opaque content[SSLCompressed.length]; 758 opaque MAC[CipherSpec.hash_size]; 759 uint8 padding[GenericBlockCipher.padding_length]; 760 uint8 padding_length; 761 } GenericBlockCipher; 763 The MAC is generated as described in Section 5.2.3.1. 765 padding Padding that is added to force the length of the plaintext 766 to be a multiple of the block cipher's block length. 768 padding_length The length of the padding must be less than the 769 cipher's block length and may be zero. The padding length should 770 be such that the total size of the GenericBlockCipher structure is 771 a multiple of the cipher's block length. 773 The encrypted data length (SSLCiphertext.length) is one more than the 774 sum of SSLCompressed.length, CipherSpec.hash_size, and 775 padding_length. 777 Note: With CBC block chaining the initialization vector (IV) for the 778 first record is provided by the handshake protocol. The IV for 779 subsequent records is the last ciphertext block from the previous 780 record. 782 5.3. Change cipher spec protocol 784 The change cipher spec protocol exists to signal transitions in 785 ciphering strategies. The protocol consists of a single message, 786 which is encrypted and compressed under the current (not the pending) 787 CipherSpec. The message consists of a single byte of value 1. 789 struct { 790 enum { change_cipher_spec(1), (255) } type; 791 } ChangeCipherSpec; 793 The change cipher spec message is sent by both the client and server 794 to notify the receiving party that subsequent records will be 795 protected under the just-negotiated CipherSpec and keys. Reception 796 of this message causes the receiver to copy the read pending state 797 into the read current state. The client sends a change cipher spec 798 message following handshake key exchange and certificate verify 799 messages (if any), and the server sends one after successfully 800 processing the key exchange message it received from the client. An 801 unexpected change cipher spec message should generate an 802 unexpected_message alert (Section 5.4.2). When resuming a previous 803 session, the change cipher spec message is sent after the hello 804 messages. 806 5.4. Alert protocol 808 One of the content types supported by the SSL Record layer is the 809 alert type. Alert messages convey the severity of the message and a 810 description of the alert. Alert messages with a level of fatal 811 result in the immediate termination of the connection. In this case, 812 other connections corresponding to the session may continue, but the 813 session identifier must be invalidated, preventing the failed session 814 from being used to establish new connections. Like other messages, 815 alert messages are encrypted and compressed, as specified by the 816 current connection state. 818 enum { warning(1), fatal(2), (255) } AlertLevel; 820 enum { 821 close_notify(0), 822 unexpected_message(10), 823 bad_record_mac(20), 824 decompression_failure(30), 825 handshake_failure(40), 826 no_certificate(41), 827 bad_certificate(42), 828 unsupported_certificate(43), 829 certificate_revoked(44), 830 certificate_expired(45), 831 certificate_unknown(46), 832 illegal_parameter (47) 833 (255) 834 } AlertDescription; 836 struct { 837 AlertLevel level; 838 AlertDescription description; 839 } Alert; 841 5.4.1. Closure alerts 843 The client and the server must share knowledge that the connection is 844 ending in order to avoid a truncation attack. Either party may 845 initiate the exchange of closing messages. 847 close_notify This message notifies the recipient that the sender 848 will not send any more messages on this connection. The session 849 becomes unresumable if any connection is terminated without proper 850 close_notify messages with level equal to warning. 852 Either party may initiate a close by sending a close_notify alert. 853 Any data received after a closure alert is ignored. 855 Each party is required to send a close_notify alert before closing 856 the write side of the connection. It is required that the other 857 party respond with a close_notify alert of its own and close down the 858 connection immediately, discarding any pending writes. It is not 859 required for the initiator of the close to wait for the responding 860 close_notify alert before closing the read side of the connection. 862 NB: It is assumed that closing a connection reliably delivers pending 863 data before destroying the transport. 865 5.4.2. Error alerts 867 Error handling in the SSL Handshake protocol is very simple. When an 868 error is detected, the detecting party sends a message to the other 869 party. Upon transmission or receipt of an fatal alert message, both 870 parties immediately close the connection. Servers and clients are 871 required to forget any session-identifiers, keys, and secrets 872 associated with a failed connection. The following error alerts are 873 defined: 875 unexpected_message An inappropriate message was received. This 876 alert is always fatal and should never be observed in 877 communication between proper implementations. 879 bad_record_mac This alert is returned if a record is received with 880 an incorrect MAC. This message is always fatal. 882 decompression_failure The decompression function received improper 883 input (e.g. data that would expand to excessive length). This 884 message is always fatal. 886 handshake_failure Reception of a handshake_failure alert message 887 indicates that the sender was unable to negotiate an acceptable 888 set of security parameters given the options available. This is a 889 fatal error. 891 no_certificate A no_certificate alert message may be sent in 892 response to a certification request if no appropriate certificate 893 is available. 895 bad_certificate A certificate was corrupt, contained signatures that 896 did not verify correctly, etc. 898 unsupported_certificate A certificate was of an unsupported type. 900 certificate_revoked A certificate was revoked by its signer. 902 certificate_expired A certificate has expired or is not currently 903 valid. 905 certificate_unknown Some other (unspecified) issue arose in 906 processing the certificate, rendering it unacceptable. 908 illegal_parameter A field in the handshake was out of range or 909 inconsistent with other fields. This is always fatal. 911 5.5. Handshake protocol overview 913 The cryptographic parameters of the session state are produced by the 914 SSL Handshake Protocol, which operates on top of the SSL Record 915 Layer. When a SSL client and server first start communicating, they 916 agree on a protocol version, select cryptographic algorithms, 917 optionally authenticate each other, and use public-key encryption 918 techniques to generate shared secrets. These processes are performed 919 in the handshake protocol, which can be summarized as follows: The 920 client sends a client hello message to which the server must respond 921 with a server hello message, or else a fatal error will occur and the 922 connection will fail. The client hello and server hello are used to 923 establish security enhancement capabilities between client and 924 server. The client hello and server hello establish the following 925 attributes: Protocol Version, Session ID, Cipher Suite, and 926 Compression Method. Additionally, two random values are generated 927 and exchanged: ClientHello.random and ServerHello.random. 929 Following the hello messages, the server will send its certificate, 930 if it is to be authenticated. Additionally, a server key exchange 931 message may be sent, if it is required (e.g. if their server has no 932 certificate, or if its certificate is for signing only). If the 933 server is authenticated, it may request a certificate from the 934 client, if that is appropriate to the cipher suite selected. Now the 935 server will send the server hello done message, indicating that the 936 hello-message phase of the handshake is complete. The server will 937 then wait for a client response. If the server has sent a 938 certificate request Message, the client must send either the 939 certificate message or a no_certificate alert. The client key 940 exchange message is now sent, and the content of that message will 941 depend on the public key algorithm selected between the client hello 942 and the server hello. If the client has sent a certificate with 943 signing ability, a digitally-signed certificate verify message is 944 sent to explicitly verify the certificate. 946 At this point, a change cipher spec message is sent by the client, 947 and the client copies the pending Cipher Spec into the current Cipher 948 Spec. The client then immediately sends the finished message under 949 the new algorithms, keys, and secrets. In response, the server will 950 send its own change cipher spec message, transfer the pending to the 951 current Cipher Spec, and send its finished message under the new 952 Cipher Spec. At this point, the handshake is complete and the client 953 and server may begin to exchange application layer data. (See flow 954 chart below.) 955 Client Server 957 ClientHello --------> 958 ServerHello 959 Certificate* 960 ServerKeyExchange* 961 CertificateRequest* 962 <-------- ServerHelloDone 963 Certificate* 964 ClientKeyExchange 965 CertificateVerify* 966 [ChangeCipherSpec] 967 Finished --------> 968 [ChangeCipherSpec] 969 <-------- Finished 970 Application Data <-------> Application Data 972 * Indicates optional or situation-dependent messages that are not 973 always sent. 975 Note: To help avoid pipeline stalls, ChangeCipherSpec is an 976 independent SSL Protocol content type, and is not actually an SSL 977 handshake message. 979 When the client and server decide to resume a previous session or 980 duplicate an existing session (instead of negotiating new security 981 parameters) the message flow is as follows: 983 The client sends a ClientHello using the Session ID of the session to 984 be resumed. The server then checks its session cache for a match. 985 If a match is found, and the server is willing to re-establish the 986 connection under the specified session state, it will send a 987 ServerHello with the same Session ID value. At this point, both 988 client and server must send change cipher spec messages and proceed 989 directly to finished messages. Once the re-establishment is 990 complete, the client and server may begin to exchange application 991 layer data. (See flow chart below.) If a Session ID match is not 992 found, the server generates a new session ID and the SSL client and 993 server perform a full handshake. 995 Client Server 997 ClientHello --------> 998 ServerHello 999 [change cipher spec] 1000 <-------- Finished 1001 change cipher spec 1002 Finished --------> 1003 Application Data <-------> Application Data 1005 The contents and significance of each message will be presented in 1006 detail in the following sections. 1008 5.6. Handshake protocol 1010 The SSL Handshake Protocol is one of the defined higher level clients 1011 of the SSL Record Protocol. This protocol is used to negotiate the 1012 secure attributes of a session. Handshake messages are supplied to 1013 the SSL Record Layer, where they are encapsulated within one or more 1014 SSLPlaintext structures, which are processed and transmitted as 1015 specified by the current active session state. 1017 enum { 1018 hello_request(0), client_hello(1), server_hello(2), 1019 certificate(11), server_key_exchange (12), 1020 certificate_request(13), server_hello_done(14), 1021 certificate_verify(15), client_key_exchange(16), 1022 finished(20), (255) 1023 } HandshakeType; 1025 struct { 1026 HandshakeType msg_type; /* handshake type */ 1027 uint24 length; /* bytes in message */ 1028 select (HandshakeType) { 1029 case hello_request: HelloRequest; 1030 case client_hello: ClientHello; 1031 case server_hello: ServerHello; 1032 case certificate: Certificate; 1033 case server_key_exchange: ServerKeyExchange; 1034 case certificate_request: CertificateRequest; 1035 case server_hello_done: ServerHelloDone; 1036 case certificate_verify: CertificateVerify; 1037 case client_key_exchange: ClientKeyExchange; 1038 case finished: Finished; 1039 } body; 1040 } Handshake; 1042 The handshake protocol messages are presented in the order they must 1043 be sent; sending handshake messages in an unexpected order results in 1044 a fatal error. 1046 5.6.1. Hello messages 1048 The hello phase messages are used to exchange security enhancement 1049 capabilities between the client and server. When a new session 1050 begins, the CipherSpec encryption, hash, and compression algorithms 1051 are initialized to null. The current CipherSpec is used for 1052 renegotiation messages. 1054 5.6.1.1. Hello request 1056 The hello request message may be sent by the server at any time, but 1057 will be ignored by the client if the handshake protocol is already 1058 underway. It is a simple notification that the client should begin 1059 the negotiation process anew by sending a client hello message when 1060 convenient. 1062 Note: Since handshake messages are intended to have transmission 1063 precedence over application data, it is expected that the negotiation 1064 begin in no more than one or two times the transmission time of a 1065 maximum length application data message. 1067 After sending a hello request, servers should not repeat the request 1068 until the subsequent handshake negotiation is complete. A client 1069 that receives a hello request while in a handshake negotiation state 1070 should simply ignore the message. 1072 The structure of a hello request message is as follows: 1074 struct { } HelloRequest; 1076 5.6.1.2. Client hello 1078 When a client first connects to a server it is required to send the 1079 client hello as its first message. The client can also send a client 1080 hello in response to a hello request or on its own initiative in 1081 order to renegotiate the security parameters in an existing 1082 connection. The client hello message includes a random structure, 1083 which is used later in the protocol. 1085 struct { 1086 uint32 gmt_unix_time; 1087 opaque random_bytes[28]; 1089 } Random; 1091 gmt_unix_time The current time and date in standard UNIX 32-bit 1092 format according to the sender's internal clock. Clocks are not 1093 required to be set correctly by the basic SSL Protocol; higher 1094 level or application protocols may define additional requirements. 1096 random_bytes 28 bytes generated by a secure random number generator. 1098 The client hello message includes a variable length session 1099 identifier. If not empty, the value identifies a session between the 1100 same client and server whose security parameters the client wishes to 1101 reuse. The session identifier may be from an earlier connection, 1102 this connection, or another currently active connection. The second 1103 option is useful if the client only wishes to update the random 1104 structures and derived values of a connection, while the third option 1105 makes it possible to establish several simultaneous independent 1106 secure connections without repeating the full handshake protocol. 1107 The actual contents of the SessionID are defined by the server. 1109 opaque SessionID<0..32>; 1111 Warning: Servers must not place confidential information in session 1112 identifiers or let the contents of fake session identifiers cause any 1113 breach of security. 1115 The CipherSuite list, passed from the client to the server in the 1116 client hello message, contains the combinations of cryptographic 1117 algorithms supported by the client in order of the client's 1118 preference (first choice first). Each CipherSuite defines both a key 1119 exchange algorithm and a CipherSpec. The server will select a cipher 1120 suite or, if no acceptable choices are presented, return a handshake 1121 failure alert and close the connection. 1123 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1125 The client hello includes a list of compression algorithms supported 1126 by the client, ordered according to the client's preference. If the 1127 server supports none of those specified by the client, the session 1128 must fail. 1130 enum { null(0), (255) } CompressionMethod; 1132 Issue: Which compression methods to support is under investigation. 1134 The structure of the client hello is as follows. 1136 struct { 1137 ProtocolVersion client_version; 1138 Random random; 1139 SessionID session_id; 1140 CipherSuite cipher_suites<2..2^16-1>; 1141 CompressionMethod compression_methods<1..2^8-1>; 1142 } ClientHello; 1144 client_version The version of the SSL protocol by which the client 1145 wishes to communicate during this session. This should be the 1146 most recent (highest valued) version supported by the client. For 1147 this version of the specification, the version will be 3.0 (See 1148 Appendix E for details about backward compatibility). 1150 random A client-generated random structure. 1152 session_id The ID of a session the client wishes to use for this 1153 connection. This field should be empty if no session_id is 1154 available or the client wishes to generate new security 1155 parameters. 1157 cipher_suites This is a list of the cryptographic options supported 1158 by the client, sorted with the client's first preference first. 1159 If the session_id field is not empty (implying a session 1160 resumption request) this vector must include at least the 1161 cipher_suite from that session. Values are defined in 1162 Appendix A.6. 1164 compression_methods This is a list of the compression methods 1165 supported by the client, sorted by client preference. If the 1166 session_id field is not empty (implying a session resumption 1167 request) this vector must include at least the compression_method 1168 from that session. All implementations must support 1169 CompressionMethod.null. 1171 After sending the client hello message, the client waits for a server 1172 hello message. Any other handshake message returned by the server 1173 except for a hello request is treated as a fatal error. 1175 Implementation note: Application data may not be sent before a 1176 finished message has been sent. Transmitted application data is 1177 known to be insecure until a valid finished message has been 1178 received. This absolute restriction is relaxed if there is a 1179 current, non-null encryption on this connection. 1181 Forward compatibility note: In the interests of forward 1182 compatibility, it is permitted for a client hello message to include 1183 extra data after the compression methods. This data must be included 1184 in the handshake hashes, but must otherwise be ignored. 1186 5.6.1.3. Server hello 1188 The server processes the client hello message and responds with 1189 either a handshake_failure alert or server hello message. 1191 struct { 1192 ProtocolVersion server_version; 1193 Random random; 1194 SessionID session_id; 1195 CipherSuite cipher_suite; 1196 CompressionMethod compression_method; 1197 } ServerHello; 1199 server_version This field will contain the lower of that suggested 1200 by the client in the client hello and the highest supported by the 1201 server. For this version of the specification, the version will 1202 be 3.0 (See Appendix E for details about backward compatibility). 1204 random This structure is generated by the server and must be 1205 different from (and independent of) ClientHello.random. 1207 session_id This is the identity of the session corresponding to this 1208 connection. If the ClientHello.session_id was non-empty, the 1209 server will look in its session cache for a match. If a match is 1210 found and the server is willing to establish the new connection 1211 using the specified session state, the server will respond with 1212 the same value as was supplied by the client. This indicates a 1213 resumed session and dictates that the parties must proceed 1214 directly to the finished messages. Otherwise this field will 1215 contain a different value identifying the new session. The server 1216 may return an empty session_id to indicate that the session will 1217 not be cached and therefore cannot be resumed. 1219 cipher_suite The single cipher suite selected by the server from the 1220 list in ClientHello.cipher_suites. For resumed sessions this 1221 field is the value from the state of the session being resumed. 1223 compression_method The single compression algorithm selected by the 1224 server from the list in ClientHello.compression_methods. For 1225 resumed sessions this field is the value from the resumed session 1226 state. 1228 5.6.2. Server certificate 1230 If the server is to be authenticated (which is generally the case), 1231 the server sends its certificate immediately following the server 1232 hello message. The certificate type must be appropriate for the 1233 selected cipher suite's key exchange algorithm, and is generally an 1234 X.509.v3 certificate (or a modified X.509 certificate in the case of 1235 FORTEZZA(tm) [FOR]). The same message type will be used for the 1236 client's response to a certificate request message. 1238 opaque ASN.1Cert<1..2^24-1>; 1239 struct { 1240 ASN.1Cert certificate_list<1..2^24-1>; 1241 } Certificate; 1243 certificate_list This is a sequence (chain) of X.509.v3 1244 certificates, ordered with the sender's certificate first followed 1245 by any certificate authority certificates proceeding sequentially 1246 upward. 1248 Note: PKCS #7 [PKCS7] is not used as the format for the certificate 1249 vector because PKCS #6 [PKCS6] extended certificates are not used. 1250 Also PKCS #7 defines a SET rather than a SEQUENCE, making the task of 1251 parsing the list more difficult. 1253 5.6.3. Server key exchange message 1255 The server key exchange message is sent by the server if it has no 1256 certificate, has a certificate only used for signing (e.g., DSS [DSS] 1257 certificates, signing-only RSA [RSA] certificates), or FORTEZZA KEA 1258 key exchange is used. This message is not used if the server 1259 certificate contains Diffie-Hellman [DH1] parameters. 1261 Note: According to current US export law, RSA moduli larger than 512 1262 bits may not be used for key exchange in software exported from the 1263 US. With this message, larger RSA keys may be used as signature-only 1264 certificates to sign temporary shorter RSA keys for key exchange. 1266 enum { rsa, diffie_hellman, fortezza_kea } 1267 KeyExchangeAlgorithm; 1269 struct { 1270 opaque rsa_modulus<1..2^16-1>; 1271 opaque rsa_exponent<1..2^16-1>; 1272 } ServerRSAParams; 1274 rsa_modulus The modulus of the server's temporary RSA key. 1276 rsa_exponent The public exponent of the server's temporary RSA key. 1278 struct { 1279 opaque dh_p<1..2^16-1>; 1280 opaque dh_g<1..2^16-1>; 1281 opaque dh_Ys<1..2^16-1>; 1282 } ServerDHParams; /* Ephemeral DH parameters */ 1284 dh_p The prime modulus used for the Diffie-Hellman operation. 1286 dh_g The generator used for the Diffie-Hellman operation. 1288 dh_Ys The server's Diffie-Hellman public value (gX mod p). 1290 struct { 1291 opaque r_s [128]; 1292 } ServerFortezzaParams; 1294 r_s Server random number for FORTEZZA KEA (Key Exchange Algorithm). 1296 struct { 1297 select (KeyExchangeAlgorithm) { 1298 case diffie_hellman: 1299 ServerDHParams params; 1300 Signature signed_params; 1301 case rsa: 1302 ServerRSAParams params; 1303 Signature signed_params; 1304 case fortezza_kea: 1305 ServerFortezzaParams params; 1306 }; 1307 } ServerKeyExchange; 1309 params The server's key exchange parameters. 1311 signed_params A hash of the corresponding params value, with the 1312 signature appropriate to that hash applied. 1314 md5_hash MD5(ClientHello.random + ServerHello.random + 1315 ServerParams); 1317 sha_hash SHA(ClientHello.random + ServerHello.random + 1318 ServerParams); 1320 enum { anonymous, rsa, dsa } SignatureAlgorithm; 1322 digitally-signed struct { 1323 select(SignatureAlgorithm) { 1324 case anonymous: struct { }; 1325 case rsa: 1326 opaque md5_hash[16]; 1327 opaque sha_hash[20]; 1328 case dsa: 1329 opaque sha_hash[20]; 1330 }; 1331 } Signature; 1333 5.6.4. Certificate request 1335 A non-anonymous server can optionally request a certificate from the 1336 client, if appropriate for the selected cipher suite. 1338 enum { 1339 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 1340 rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20), 1341 (255) 1342 } ClientCertificateType; 1344 opaque DistinguishedName<1..2^16-1>; 1346 struct { 1347 ClientCertificateType certificate_types<1..2^8-1>; 1348 DistinguishedName certificate_authorities<3..2^16-1>; 1349 } CertificateRequest; 1351 certificate_types This field is a list of the types of certificates 1352 requested, sorted in order of the server's preference. 1354 certificate_authorities A list of the distinguished names of 1355 acceptable certificate authorities. 1357 Note: DistinguishedName is derived from [X509]. 1359 Note: It is a fatal handshake_failure alert for an anonymous server 1360 to request client identification. 1362 5.6.5. Server hello done 1364 The server hello done message is sent by the server to indicate the 1365 end of the server hello and associated messages. After sending this 1366 message the server will wait for a client response. 1368 struct { } ServerHelloDone; 1370 Upon receipt of the server hello done message the client should 1371 verify that the server provided a valid certificate if required and 1372 check that the server hello parameters are acceptable. 1374 5.6.6. Client certificate 1376 This is the first message the client can send after receiving a 1377 server hello done message. This message is only sent if the server 1378 requests a certificate. If no suitable certificate is available, the 1379 client should send a no_certificate alert instead. This alert is 1380 only a warning, however the server may respond with a fatal handshake 1381 failure alert if client authentication is required. Client 1382 certificates are sent using the Certificate defined in Section 5.6.2. 1384 Note: Client Diffie-Hellman certificates must match the server 1385 specified Diffie-Hellman parameters. 1387 5.6.7. Client key exchange message 1389 The choice of messages depends on which public key algorithm(s) has 1390 (have) been selected. See Section 5.6.3 for the KeyExchangeAlgorithm 1391 definition. 1393 struct { 1394 select (KeyExchangeAlgorithm) { 1395 case rsa: EncryptedPreMasterSecret; 1396 case diffie_hellman: ClientDiffieHellmanPublic; 1397 case fortezza_kea: FortezzaKeys; 1398 } exchange_keys; 1399 } ClientKeyExchange; 1401 The information to select the appropriate record structure is in the 1402 pending session state (see Section 5.1). 1404 5.6.7.1. RSA encrypted premaster secret message 1406 If RSA is being used for key agreement and authentication, the client 1407 generates a 48-byte pre-master secret, encrypts it under the public 1408 key from the server's certificate or temporary RSA key from a server 1409 key exchange message, and sends the result in an encrypted premaster 1410 secret message. 1412 struct { 1413 ProtocolVersion client_version; 1414 opaque random[46]; 1415 } PreMasterSecret; 1417 client_version The latest (newest) version supported by the client. 1418 This is used to detect version roll-back attacks. 1420 random 46 securely-generated random bytes. 1422 struct { 1423 public-key-encrypted PreMasterSecret pre_master_secret; 1424 } EncryptedPreMasterSecret; 1426 pre_master_secret This random value is generated by the client and 1427 is used to generate the master secret, as specified in 1428 Section 6.1. 1430 5.6.7.2. FORTEZZA key exchange message 1432 Under FORTEZZA, the client derives a Token Encryption Key (TEK) using 1433 the FORTEZZA Key Exchange Algorithm (KEA). The client's KEA 1434 calculation uses the public key in the server's certificate along 1435 with private parameters in the client's token. The client sends 1436 public parameters needed for the server to generate the TEK, using 1437 its own private parameters. The client generates session keys, wraps 1438 them using the TEK, and sends the results to the server. The client 1439 generates IV's for the session keys and TEK and sends them also. The 1440 client generates a random 48-byte premaster secret, encrypts it using 1441 the TEK, and sends the result: 1443 struct { 1444 opaque y_c<0..128>; 1445 opaque r_c[128]; 1446 opaque y_signature[40]; 1447 opaque wrapped_client_write_key[12]; 1448 opaque wrapped_server_write_key[12]; 1449 opaque client_write_iv[24]; 1450 opaque server_write_iv[24]; 1451 opaque master_secret_iv[24]; 1452 block-ciphered opaque encrypted_pre_master_secret[48]; 1453 } FortezzaKeys; 1455 y_signature y_signature is the signature of the KEA public key, 1456 signed with the client's DSS private key. 1458 y_c The client's Yc value (public key) for the KEA calculation. If 1459 the client has sent a certificate, and its KEA public key is 1460 suitable, this value must be empty since the certificate already 1461 contains this value. If the client sent a certificate without a 1462 suitable public key, y_c is used and y_signature is the KEA public 1463 key signed with the client's DSS private key. For this value to 1464 be used, it must be between 64 and 128 bytes. 1466 r_c The client's Rc value for the KEA calculation. 1468 wrapped_client_write_key This is the client's write key, wrapped by 1469 the TEK. 1471 wrapped_server_write_key This is the server's write key, wrapped by 1472 the TEK. 1474 client_write_iv The IV for the client write key. 1476 server_write_iv The IV for the server write key. 1478 master_secret_iv This is the IV for the TEK used to encrypt the pre- 1479 master secret. 1481 pre_master_secret A random value, generated by the client and used 1482 to generate the master secret, as specified in Section 6.1. In 1483 the the above structure, it is encrypted using the TEK. 1485 5.6.7.3. Client Diffie-Hellman public value 1487 This structure conveys the client's Diffie-Hellman public value (Yc) 1488 if it was not already included in the client's certificate. The 1489 encoding used for Yc is determined by the enumerated 1490 PublicValueEncoding. 1492 enum { implicit, explicit } PublicValueEncoding; 1494 implicit If the client certificate already contains the public 1495 value, then it is implicit and Yc does not need to be sent again. 1497 explicit Yc needs to be sent. 1499 struct { 1500 select (PublicValueEncoding) { 1501 case implicit: struct { }; 1502 case explicit: opaque dh_Yc<1..2^16-1>; 1503 } dh_public; 1504 } ClientDiffieHellmanPublic; 1506 dh_Yc The client's Diffie-Hellman public value (Yc). 1508 5.6.8. Certificate verify 1510 This message is used to provide explicit verification of a client 1511 certificate. This message is only sent following any client 1512 certificate that has signing capability (i.e. all certificates except 1513 those containing fixed Diffie-Hellman parameters). 1515 struct { 1516 Signature signature; 1517 } CertificateVerify; 1519 CertificateVerify.signature.md5_hash 1520 MD5(master_secret + pad_2 + 1521 MD5(handshake_messages + master_secret + pad_1)); 1522 Certificate.signature.sha_hash 1523 SHA(master_secret + pad_2 + 1524 SHA(handshake_messages + master_secret + pad_1)); 1526 pad_1 This is identical to the pad_1 defined in section 5.2.3.1. 1528 pad_2 This is identical to the pad_2 defined in section 5.2.3.1. 1530 Here handshake_messages refers to all handshake messages starting at 1531 client hello up to but not including this message. 1533 5.6.9. Finished 1535 A finished message is always sent immediately after a change cipher 1536 specs message to verify that the key exchange and authentication 1537 processes were successful. The finished message is the first 1538 protected with the just-negotiated algorithms, keys, and secrets. No 1539 acknowledgment of the finished message is required; parties may begin 1540 sending encrypted data immediately after sending the finished 1541 message. Recipients of finished messages must verify that the 1542 contents are correct. 1544 enum { client(0x434C4E54), server(0x53525652) } Sender; 1546 struct { 1547 opaque md5_hash[16]; 1548 opaque sha_hash[20]; 1549 } Finished; 1551 md5_hash MD5(master_secret + pad2 + MD5(handshake_messages + Sender 1552 + master_secret + pad1)); 1554 sha_hash SHA(master_secret + pad2 + SHA(handshake_messages + Sender 1555 + master_secret + pad1)); 1557 handshake_messages All of the data from all handshake messages up to 1558 but not including this message. This is only data visible at the 1559 handshake layer and does not include record layer headers. 1561 It is a fatal error if a finished message is not preceeded by a 1562 change cipher spec message at the appropriate point in the handshake. 1564 The hash contained in finished messages sent by the server 1565 incorporate Sender.server; those sent by the client incorporate 1566 Sender.client. The value handshake_messages includes all handshake 1567 messages starting at client hello up to, but not including, this 1568 finished message. This may be different from handshake_messages in 1569 Section 5.6.8 because it would include the certificate verify message 1570 (if sent). 1572 Note: Change cipher spec messages are not handshake messages and are 1573 not included in the hash computations. 1575 5.7. Application data protocol 1577 Application data messages are carried by the Record Layer and are 1578 fragmented, compressed and encrypted based on the current connection 1579 state. The messages are treated as transparent data to the record 1580 layer. 1582 6. Cryptographic computations 1584 The key exchange, authentication, encryption, and MAC algorithms are 1585 determined by the cipher_suite selected by the server and revealed in 1586 the server hello message. 1588 6.1. Asymmetric cryptographic computations 1590 The asymmetric algorithms are used in the handshake protocol to 1591 authenticate parties and to generate shared keys and secrets. 1593 For Diffie-Hellman, RSA, and FORTEZZA, the same algorithm is used to 1594 convert the pre_master_secret into the master_secret. The 1595 pre_master_secret should be deleted from memory once the 1596 master_secret has been computed. 1598 master_secret = 1599 MD5(pre_master_secret + SHA('A' + pre_master_secret + 1600 ClientHello.random + ServerHello.random)) + 1601 MD5(pre_master_secret + SHA('BB' + pre_master_secret + 1602 ClientHello.random + ServerHello.random)) + 1603 MD5(pre_master_secret + SHA('CCC' + pre_master_secret + 1604 ClientHello.random + ServerHello.random)); 1606 6.1.1. RSA 1608 When RSA is used for server authentication and key exchange, a 48- 1609 byte pre_master_secret is generated by the client, encrypted under 1610 the server's public key, and sent to the server. The server uses its 1611 private key to decrypt the pre_master_secret. Both parties then 1612 convert the pre_master_secret into the master_secret, as specified 1613 above. 1615 RSA digital signatures are performed using PKCS #1 [PKCS1] block type 1616 1. RSA public key encryption is performed using PKCS #1 block type 1617 2. 1619 6.1.2. Diffie-Hellman 1621 A conventional Diffie-Hellman computation is performed. The 1622 negotiated key (Z) is used as the pre_master_secret, and is converted 1623 into the master_secret, as specified above. 1625 Note: Diffie-Hellman parameters are specified by the server, and may 1626 be either ephemeral or contained within the server's certificate. 1628 6.1.3. FORTEZZA 1630 A random 48-byte pre_master_secret is sent encrypted under the TEK 1631 and its IV. The server decrypts the pre_master_secret and converts 1632 it into a master_secret, as specified above. Bulk cipher keys and 1633 IVs for encryption are generated by the client's token and exchanged 1634 in the key exchange message; the master_secret is only used for MAC 1635 computations. 1637 6.2. Symmetric cryptographic calculations and the CipherSpec 1639 The technique used to encrypt and verify the integrity of SSL records 1640 is specified by the currently active CipherSpec. A typical example 1641 would be to encrypt data using DES and generate authentication codes 1642 using MD5. The encryption and MAC algorithms are set to 1643 SSL_NULL_WITH_NULL_NULL at the beginning of the SSL Handshake 1644 Protocol, indicating that no message authentication or encryption is 1645 performed. The handshake protocol is used to negotiate a more secure 1646 CipherSpec and to generate cryptographic keys. 1648 6.2.1. The master secret 1650 Before secure encryption or integrity verification can be performed 1651 on records, the client and server need to generate shared secret 1652 information known only to themselves. This value is a 48-byte 1653 quantity called the master secret. The master secret is used to 1654 generate keys and secrets for encryption and MAC computations. Some 1655 algorithms, such as FORTEZZA, may have their own procedure for 1656 generating encryption keys (the master secret is used only for MAC 1657 computations in FORTEZZA). 1659 6.2.2. Converting the master secret into keys and MAC secrets 1661 The master secret is hashed into a sequence of secure bytes, which 1662 are assigned to the MAC secrets, keys, and non-export IVs required by 1663 the current CipherSpec (see Appendix A.7). CipherSpecs require a 1664 client write MAC secret, a server write MAC secret, a client write 1665 key, a server write key, a client write IV, and a server write IV, 1666 which are generated from the master secret in that order. Unused 1667 values, such as FORTEZZA keys communicated in the KeyExchange 1668 message, are empty. The following inputs are available to the key 1669 definition process: 1671 opaque MasterSecret[48] 1672 ClientHello.random 1673 ServerHello.random 1675 When generating keys and MAC secrets, the master secret is used as an 1676 entropy source, and the random values provide unencrypted salt 1677 material and IVs for exportable ciphers. 1679 To generate the key material, compute 1681 key_block = 1682 MD5(master_secret + SHA(`A' + master_secret + 1683 ServerHello.random + 1684 ClientHello.random)) + 1685 MD5(master_secret + SHA(`BB' + master_secret + 1686 ServerHello.random + 1687 ClientHello.random)) + 1688 MD5(master_secret + SHA(`CCC' + master_secret + 1689 ServerHello.random + 1690 ClientHello.random)) + [...]; 1692 until enough output has been generated. Then the key_block is 1693 partitioned as follows. 1695 client_write_MAC_secret[CipherSpec.hash_size] 1696 server_write_MAC_secret[CipherSpec.hash_size] 1697 client_write_key[CipherSpec.key_material] 1698 server_write_key[CipherSpec.key_material] 1699 client_write_IV[CipherSpec.IV_size] /* non-export ciphers */ 1700 server_write_IV[CipherSpec.IV_size] /* non-export ciphers */ 1702 Any extra key_block material is discarded. 1704 Exportable encryption algorithms (for which CipherSpec.is_exportable 1705 is true) require additional processing as follows to derive their 1706 final write keys: 1708 final_client_write_key = MD5(client_write_key + 1709 ClientHello.random + 1710 ServerHello.random); 1711 final_server_write_key = MD5(server_write_key + 1712 ServerHello.random + 1713 ClientHello.random); 1715 Exportable encryption algorithms derive their IVs from the random 1716 messages: 1718 client_write_IV = MD5(ClientHello.random + ServerHello.random); 1719 server_write_IV = MD5(ServerHello.random + ClientHello.random); 1721 MD5 outputs are trimmed to the appropriate size by discarding the 1722 least-significant bytes. 1724 6.2.2.1. Export key generation example 1726 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for 1727 each of the two encryption keys and 16 bytes for each of the MAC 1728 keys, for a total of 42 bytes of key material. MD5 produces 16 bytes 1729 of output per call, so three calls to MD5 are required. The MD5 1730 outputs are concatenated into a 48-byte key_block with the first MD5 1731 call providing bytes zero through 15, the second providing bytes 16 1732 through 31, etc. The key_block is partitioned, and the write keys 1733 are salted because this is an exportable encryption algorithm. 1735 client_write_MAC_secret = key_block[0..15] 1736 server_write_MAC_secret = key_block[16..31] 1737 client_write_key = key_block[32..36] 1738 server_write_key = key_block[37..41] 1739 final_client_write_key = MD5(client_write_key + 1740 ClientHello.random + 1741 ServerHello.random)[0..15]; 1742 final_server_write_key = MD5(server_write_key + 1743 ServerHello.random + 1744 ClientHello.random)[0..15]; 1745 client_write_IV = MD5(ClientHello.random + 1746 ServerHello.random)[0..7]; 1747 server_write_IV = MD5(ServerHello.random + 1748 ClientHello.random)[0..7]; 1750 7. Security considerations 1752 See Appendix F. 1754 8. IANA considerations 1756 This document has no actions for IANA. 1758 9. Informative References 1760 [DH1] Diffie, W. and M. Hellman, "New Directions in 1761 Cryptography", IEEE Transactions on Information Theory V. 1762 IT-22, n. 6, pp. 74-84, June 1977. 1764 [SSL-2] Hickman, K., "The SSL Protocol", February 1995. 1766 [3DES] Tuchman, W., "Hellman Presents No Shortcut Solutions To 1767 DES", IEEE Spectrum, v. 16, n. 7, pp40-41. , July 1979. 1769 [DES] ANSI X3.106, "American National Standard for Information 1770 Systems-Data Link Encryption", American National Standards 1771 Institute , 1983. 1773 [DSS] NIST FIPS PUB 186, "Digital Signature Standard", National 1774 Institute of Standards and Technology, U.S. Department of 1775 Commerce , May 1994. 1777 [FOR] NSA X22, "FORTEZZA: Application Implementers Guide", 1778 Document # PD4002103-1.01 , April 1995. 1780 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 1781 STD 9, RFC 959, October 1985. 1783 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1784 September 1981. 1786 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1787 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1789 [RFC1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, 1790 April 1992. 1792 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1793 April 1992. 1795 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1796 RFC 793, September 1981. 1798 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 1799 Specification", STD 8, RFC 854, May 1983. 1801 [RFC1832] Srinivasan, R., "XDR: External Data Representation 1802 Standard", RFC 1832, August 1995. 1804 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1805 Hashing for Message Authentication", RFC 2104, 1806 February 1997. 1808 [IDEA] Lai, X., "On the Design and Security of Block Ciphers", 1809 ETH Series in Information Processing, v. 1, Konstanz: 1810 Hartung-Gorre Verlag , 1992. 1812 [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard 1813 version 1.5", November 1993. 1815 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate 1816 Syntax Standard version 1.5", November 1993. 1818 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message 1819 Syntax Standard version 1.5", November 1993. 1821 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 1822 Obtaining Digital Signatures and Public-Key 1823 Cryptosystems", Communications of the ACM v. 21, n. 2 pp. 1824 120-126., February 1978. 1826 [SCH] Schneier, B., "Applied Cryptography: Protocols, 1827 Algorithms, and Source Code in C", John Wiley & Sons , 1828 1994. 1830 [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard", May 1994. 1832 National Institute of Standards and Technology, U.S. 1833 Department of Commerce, DRAFT 1835 [X509] CCITT, "The Directory - Authentication Framework", 1836 Recommendation X.509 , 1988. 1838 [RSADSI] RSA Data Security, Inc., "Unpublished works". 1840 Appendix A. Protocol constant values 1842 This section describes protocol types and constants. 1844 A.1. Record layer 1845 struct { 1846 uint8 major, minor; 1847 } ProtocolVersion; 1849 ProtocolVersion version = { 3,0 }; 1851 enum { 1852 change_cipher_spec(20), alert(21), handshake(22), 1853 application_data(23), (255) 1854 } ContentType; 1856 struct { 1857 ContentType type; 1858 ProtocolVersion version; 1859 uint16 length; 1860 opaque fragment[SSLPlaintext.length]; 1861 } SSLPlaintext; 1863 struct { 1864 ContentType type; 1865 ProtocolVersion version; 1866 uint16 length; 1867 opaque fragment[SSLCompressed.length]; 1868 } SSLCompressed; 1870 struct { 1871 ContentType type; 1872 ProtocolVersion version; 1873 uint16 length; 1874 select (CipherSpec.cipher_type) { 1875 case stream: GenericStreamCipher; 1876 case block: GenericBlockCipher; 1877 } fragment; 1878 } SSLCiphertext; 1880 stream-ciphered struct { 1881 opaque content[SSLCompressed.length]; 1882 opaque MAC[CipherSpec.hash_size]; 1883 } GenericStreamCipher; 1885 block-ciphered struct { 1886 opaque content[SSLCompressed.length]; 1887 opaque MAC[CipherSpec.hash_size]; 1888 uint8 padding[GenericBlockCipher.padding_length]; 1889 uint8 padding_length; 1890 } GenericBlockCipher; 1892 A.2. Change cipher specs message 1894 struct { 1895 enum { change_cipher_spec(1), (255) } type; 1896 } ChangeCipherSpec; 1898 A.3. Alert messages 1900 enum { warning(1), fatal(2), (255) } AlertLevel; 1902 enum { 1903 close_notify(0), 1904 unexpected_message(10), 1905 bad_record_mac(20), 1906 decompression_failure(30), 1907 handshake_failure(40), 1908 no_certificate(41), 1909 bad_certificate(42), 1910 unsupported_certificate(43), 1911 certificate_revoked(44), 1912 certificate_expired(45), 1913 certificate_unknown(46), 1914 illegal_parameter (47), 1915 (255) 1916 } AlertDescription; 1918 struct { 1919 AlertLevel level; 1920 AlertDescription description; 1921 } Alert; 1923 A.4. Handshake protocol 1924 enum { 1925 hello_request(0), client_hello(1), server_hello(2), 1926 certificate(11), server_key_exchange (12), 1927 certificate_request(13), server_done(14), 1928 certificate_verify(15), client_key_exchange(16), 1929 finished(20), (255) 1930 } HandshakeType; 1932 struct { 1933 HandshakeType msg_type; 1934 uint24 length; 1935 select (HandshakeType) { 1936 case hello_request: HelloRequest; 1937 case client_hello: ClientHello; 1938 case server_hello: ServerHello; 1939 case certificate: Certificate; 1940 case server_key_exchange: ServerKeyExchange; 1941 case certificate_request: CertificateRequest; 1942 case server_done: ServerHelloDone; 1943 case certificate_verify: CertificateVerify; 1944 case client_key_exchange: ClientKeyExchange; 1945 case finished: Finished; 1946 } body; 1947 } Handshake; 1949 A.4.1. Hello messages 1950 struct { } HelloRequest; 1952 struct { 1953 uint32 gmt_unix_time; 1954 opaque random_bytes[28]; 1955 } Random; 1957 opaque SessionID<0..32>; 1959 uint8 CipherSuite[2]; 1961 enum { null(0), (255) } CompressionMethod; 1963 struct { 1964 ProtocolVersion client_version; 1965 Random random; 1966 SessionID session_id; 1967 CipherSuite cipher_suites<0..2^16-1>; 1968 CompressionMethod compression_methods<0..2^8-1>; 1969 } ClientHello; 1971 struct { 1972 ProtocolVersion server_version; 1973 Random random; 1974 SessionID session_id; 1975 CipherSuite cipher_suite; 1976 CompressionMethod compression_method; 1977 } ServerHello; 1979 A.4.2. Server authentication and key exchange messages 1981 opaque ASN.1Cert<2^24-1>; 1983 struct { 1984 ASN.1Cert certificate_list<1..2^24-1>; 1985 } Certificate; 1987 enum { rsa, diffie_hellman, fortezza_kea } KeyExchangeAlgorithm; 1989 struct { 1990 opaque RSA_modulus<1..2^16-1>; 1991 opaque RSA_exponent<1..2^16-1>; 1992 } ServerRSAParams; 1994 struct { 1995 opaque DH_p<1..2^16-1>; 1996 opaque DH_g<1..2^16-1>; 1997 opaque DH_Ys<1..2^16-1>; 1998 } ServerDHParams; 2000 struct { 2001 opaque r_s [128] 2002 } ServerFortezzaParams 2004 struct { 2005 select (KeyExchangeAlgorithm) { 2006 case diffie_hellman: 2007 ServerDHParams params; 2008 Signature signed_params; 2009 case rsa: 2010 ServerRSAParams params; 2011 Signature signed_params; 2012 case fortezza_kea: 2013 ServerFortezzaParams params; 2014 }; 2015 } ServerKeyExchange; 2017 enum { anonymous, rsa, dsa } SignatureAlgorithm; 2019 digitally-signed struct { 2020 select(SignatureAlgorithm) { 2021 case anonymous: struct { }; 2022 case rsa: 2023 opaque md5_hash[16]; 2024 opaque sha_hash[20]; 2025 case dsa: 2026 opaque sha_hash[20]; 2027 }; 2028 } Signature; 2030 enum { 2031 RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3), 2032 DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6), 2033 FORTEZZA_MISSI(20), (255) 2034 } CertificateType; 2036 opaque DistinguishedName<1..2^16-1>; 2038 struct { 2039 CertificateType certificate_types<1..2^8-1>; 2040 DistinguishedName certificate_authorities<3..2^16-1>; 2041 } CertificateRequest; 2042 struct { } ServerHelloDone; 2044 A.5. Client authentication and key exchange messages 2046 struct { 2047 select (KeyExchangeAlgorithm) { 2048 case rsa: EncryptedPreMasterSecret; 2049 case diffie_hellman: DiffieHellmanClientPublicValue; 2050 case fortezza_kea: FortezzaKeys; 2051 } exchange_keys; 2052 } ClientKeyExchange; 2054 struct { 2055 ProtocolVersion client_version; 2056 opaque random[46]; 2057 } PreMasterSecret; 2059 struct { 2060 public-key-encrypted PreMasterSecret pre_master_secret; 2061 } EncryptedPreMasterSecret; 2063 struct { 2064 opaque y_c<0..128>; 2065 opaque r_c[128]; 2066 opaque y_signature[40]; 2067 opaque wrapped_client_write_key[12]; 2068 opaque wrapped_server_write_key[12]; 2069 opaque client_write_iv[24]; 2070 opaque server_write_iv[24]; 2071 opaque master_secret_iv[24]; 2072 opaque encrypted_preMasterSecret[48]; 2073 } FortezzaKeys; 2075 enum { implicit, explicit } PublicValueEncoding; 2077 struct { 2078 select (PublicValueEncoding) { 2079 case implicit: struct {}; 2080 case explicit: opaque DH_Yc<1..2^16-1>; 2081 } dh_public; 2082 } ClientDiffieHellmanPublic; 2084 struct { 2085 Signature signature; 2086 } CertificateVerify; 2088 A.5.1. Handshake finalization message 2090 struct { 2091 opaque md5_hash[16]; 2092 opaque sha_hash[20]; 2093 } Finished; 2095 A.6. The CipherSuite 2097 The following values define the CipherSuite codes used in the client 2098 hello and server hello messages. 2100 A CipherSuite defines a cipher specifications supported in SSL 2101 Version 3.0. 2103 CipherSuite SSL_NULL_WITH_NULL_NULL = { 0x00,0x00 }; 2105 The following CipherSuite definitions require that the server provide 2106 an RSA certificate that can be used for key exchange. The server may 2107 request either an RSA or a DSS signature-capable certificate in the 2108 certificate request message. 2110 CipherSuite SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; 2111 CipherSuite SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 }; 2112 CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; 2113 CipherSuite SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; 2114 CipherSuite SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; 2115 CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; 2116 CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; 2117 CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; 2118 CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; 2119 CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; 2121 The following CipherSuite definitions are used for server- 2122 authenticated (and optionally client-authenticated) Diffie-Hellman. 2123 DH denotes cipher suites in which the server's certificate contains 2124 the Diffie-Hellman parameters signed by the certificate authority 2125 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman 2126 parameters are signed by a DSS or RSA certificate, which has been 2127 signed by the CA. The signing algorithm used is specified after the 2128 DH or DHE parameter. In all cases, the client must have the same 2129 type of certificate, and must use the Diffie-Hellman parameters 2130 chosen by the server. 2132 CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; 2133 CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; 2134 CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; 2135 CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; 2136 CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; 2137 CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; 2138 CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; 2139 CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; 2140 CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; 2141 CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; 2142 CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; 2143 CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; 2145 The following cipher suites are used for completely anonymous Diffie- 2146 Hellman communications in which neither party is authenticated. Note 2147 that this mode is vulnerable to man-in-the-middle attacks and is 2148 therefore strongly discouraged. 2150 CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; 2151 CipherSuite SSL_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; 2152 CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; 2153 CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; 2154 CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; 2156 The final cipher suites are for the FORTEZZA token. 2158 CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA = { 0X00,0X1C }; 2159 CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00,0x1D }; 2160 CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA = { 0x00,0x1E }; 2162 Note: All cipher suites whose first byte is 0xFF are considered 2163 private and can be used for defining local/experimental algorithms. 2164 Interoperability of such types is a local matter. 2166 A.7. The CipherSpec 2168 A cipher suite identifies a CipherSpec. These structures are part of 2169 the SSL session state. The CipherSpec includes: 2171 enum { stream, block } CipherType; 2173 enum { true, false } IsExportable; 2175 enum { null, rc4, rc2, des, 3des, des40, fortezza } 2176 BulkCipherAlgorithm; 2178 enum { null, md5, sha } MACAlgorithm; 2180 struct { 2181 BulkCipherAlgorithm bulk_cipher_algorithm; 2182 MACAlgorithm mac_algorithm; 2183 CipherType cipher_type; 2184 IsExportable is_exportable 2185 uint8 hash_size; 2186 uint8 key_material; 2187 uint8 IV_size; 2188 } CipherSpec; 2190 Appendix B. Glossary 2192 application protocol An application protocol is a protocol that 2193 normally layers directly on top of the transport layer (e.g., 2194 TCP/IP). Examples include HTTP, TELNET, FTP, and SMTP. 2196 asymetric cipher See public key cryptography. 2198 authentication Authentication is the ability of one entity to 2199 determine the identity of another entity. 2201 block cipher A block cipher is an algorithm that operates on 2202 plaintext in groups of bits, called blocks. 64 bits is a typical 2203 block size. 2205 bulk cipher A symmetric encryption algorithm used to encrypt large 2206 quantities of data. 2208 cipher block chaining Mode (CBC) CBC is a mode in which every 2209 plaintext block encrypted with the block cipher is first 2210 exclusive-ORed with the previous ciphertext block (or, in the case 2211 of the first block, with the initialization vector). 2213 certificate As part of the X.509 protocol (a.k.a. ISO 2214 Authentication framework), certificates are assigned by a trusted 2215 Certificate Authority and provide verification of a party's 2216 identity and may also supply its public key. 2218 client The application entity that initiates a connection to a 2219 server. 2221 client write key The key used to encrypt data written by the client. 2223 client write MAC secret The secret data used to authenticate data 2224 written by the client. 2226 connection A connection is a transport (in the OSI layering model 2227 definition) that provides a suitable type of service. For SSL, 2228 such connections are peer to peer relationships. The connections 2229 are transient. Every connection is associated with one session. 2231 Data Encryption Standard (DES) DES is a very widely used symmetric 2232 encryption algorithm. DES is a block cipher. 2234 Digital Signature Standard (DSS) A standard for digital signing, 2235 including the Digital Signing Algorithm, approved by the National 2236 Institute of Standards and Technology, defined in NIST FIPS PUB 2237 186, "Digital Signature Standard," published May, 1994 by the U.S. 2238 Dept. of Commerce. 2240 digital signatures Digital signatures utilize public key 2241 cryptography and one-way hash functions to produce a signature of 2242 the data that can be authenticated, and is difficult to forge or 2243 repudiate. 2245 FORTEZZA A PCMCIA card that provides both encryption and digital 2246 signing. 2248 handshake An initial negotiation between client and server that 2249 establishes the parameters of their transactions. 2251 Initialization Vector (IV) When a block cipher is used in CBC mode, 2252 the initialization vector is exclusive-ORed with the first 2253 plaintext block prior to encryption. 2255 IDEA A 64-bit block cipher designed by Xuejia Lai and James Massey. 2257 Message Authentication Code (MAC) A Message Authentication Code is a 2258 one-way hash computed from a message and some secret data. Its 2259 purpose is to detect if the message has been altered. 2261 master secret Secure secret data used for generating encryption 2262 keys, MAC secrets, and IVs. 2264 MD5 MD5 [RFC1321] is a secure hashing function that converts an 2265 arbitrarily long data stream into a digest of fixed size. 2267 public key cryptography A class of cryptographic techniques 2268 employing two-key ciphers. Messages encrypted with the public key 2269 can only be decrypted with the associated private key. 2270 Conversely, messages signed with the private key can be verified 2271 with the public key. 2273 one-way hash function A one-way transformation that converts an 2274 arbitrary amount of data into a fixed-length hash. It is 2275 computation- ally hard to reverse the transformation or to find 2276 collisions. MD5 and SHA are examples of one-way hash functions. 2278 RC2, RC4 Proprietary bulk ciphers from RSA Data Security, Inc. 2279 (There is no good reference to these as they are unpublished 2280 works; however, see [RSADSI]). RC2 is block cipher and RC4 is a 2281 stream cipher. 2283 RSA A very widely used public-key algorithm that can be used for 2284 either encryption or digital signing. 2286 salt Non-secret random data used to make export encryption keys 2287 resist precomputation attacks. 2289 server The server is the application entity that responds to 2290 requests for connections from clients. The server is passive, 2291 waiting for requests from clients. 2293 session A SSL session is an association between a client and a 2294 server. Sessions are created by the handshake protocol. Sessions 2295 define a set of cryptographic security parameters, which can be 2296 shared among multiple connections. Sessions are used to avoid the 2297 expensive negotiation of new security parameters for each 2298 connection. 2300 session identifier A session identifier is a value generated by a 2301 server that identifies a particular session. 2303 server write key The key used to encrypt data written by the server. 2305 server write MAC secret The secret data used to authenticate data 2306 written by the server. 2308 SHA The Secure Hash Algorithm is defined in FIPS PUB 180-1. It 2309 produces a 20-byte output [SHA]. 2311 stream cipher An encryption algorithm that converts a key into a 2312 cryptographically-strong keystream, which is then exclusive-ORed 2313 with the plaintext. 2315 symmetric cipher See bulk cipher. 2317 Appendix C. CipherSuite definitions 2319 CipherSuite Is Key Cipher Hash 2320 Exportable Exchange 2322 SSL_NULL_WITH_NULL_NULL * NULL NULL NULL 2323 SSL_RSA_WITH_NULL_MD5 * RSA NULL MD5 2324 SSL_RSA_WITH_NULL_SHA * RSA NULL SHA 2325 SSL_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 2326 SSL_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 2327 SSL_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA 2328 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 2329 SSL_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA 2330 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA 2331 SSL_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA 2332 SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA 2333 SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA 2334 SSL_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA 2335 SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA 2336 SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA 2337 SSL_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA 2338 SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA 2339 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA 2340 SSL_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA 2341 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA 2342 SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA 2343 SSL_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA 2344 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA 2345 SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 2346 SSL_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 2347 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA 2348 SSL_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA 2349 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA 2350 SSL_FORTEZZA_KEA_WITH_NULL_SHA FORTEZZA_KEA NULL SHA 2351 SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA FORTEZZA_KEA FORTEZZA_CBC SHA 2352 SSL_FORTEZZA_KEA_WITH_RC4_128_SHA FORTEZZA_KEA RC4_128 SHA 2353 +----------------+------------------------------+-------------------+ 2354 | Key Exchange | Description | Key size limit | 2355 | Algorithm | | | 2356 +----------------+------------------------------+-------------------+ 2357 | DHE_DSS | Ephemeral DH with DSS | None | 2358 | | signatures | | 2359 | DHE_DSS_EXPORT | Ephemeral DH with DSS | DH = 512 bits | 2360 | | signatures | | 2361 | DHE_RSA | Ephemeral DH with RSA | None | 2362 | | signatures | | 2363 | DHE_RSA_EXPORT | Ephemeral DH with RSA | DH = 512 bits, | 2364 | | signatures | RSA = none | 2365 | DH_anon | Anonymous DH, no signatures | None | 2366 | DH_anon_EXPORT | Anonymous DH, no signatures | DH = 512 bits | 2367 | DH_DSS | DH with DSS-based | None | 2368 | | certificates | | 2369 | DH_DSS_EXPORT | DH with DSS-based | DH = 512 bits | 2370 | | certificates | | 2371 | DH_RSA | DH with RSA-based | None | 2372 | | certificates | | 2373 | DH_RSA_EXPORT | DH with RSA-based | DH = 512 bits, | 2374 | | certificates | RSA = none | 2375 | FORTEZZA_KEA | FORTEZZA KEA. Details | N/A | 2376 | | unpublished | | 2377 | NULL | No key exchange | N/A | 2378 | RSA | RSA key exchange | None | 2379 | RSA_EXPORT | RSA key exchange | RSA = 512 bits | 2380 +----------------+------------------------------+-------------------+ 2382 Table 1 2384 Key size limit The key size limit gives the size of the largest 2385 public key that can be legally used for encryption in cipher 2386 suites that are exportable. 2388 +--------------+--------+-----+-------+-------+-------+------+------+ 2389 | Cipher | Cipher | IsE | Key | Exp. | Effec | IV | Bloc | 2390 | | Type | xpo | Mater | Key | tive | Size | k | 2391 | | | rta | ial | Mater | Key | | Size | 2392 | | | ble | | ial | Bits | | | 2393 +--------------+--------+-----+-------+-------+-------+------+------+ 2394 | NULL | Stream | * | 0 | 0 | 0 | 0 | N/A | 2395 | FORTEZZA_CBC | Block | | NA | 12 | 96 | 20 | 8 | 2396 | | | | (**) | (**) | (**) | (**) | | 2397 | IDEA_CBC | Block | | 16 | 16 | 128 | 8 | 8 | 2398 | RC2_CBC_40 | Block | * | 5 | 16 | 40 | 8 | 8 | 2399 | RC4_40 | Stream | * | 5 | 16 | 40 | 0 | N/A | 2400 | RC4_128 | Stream | | 16 | 16 | 128 | 0 | N/A | 2401 | DES40_CBC | Block | * | 5 | 8 | 40 | 8 | 8 | 2402 | DES_CBC | Block | | 8 | 8 | 56 | 8 | 8 | 2403 | 3DES_EDE_CBC | Block | | 24 | 24 | 168 | 8 | 8 | 2404 +--------------+--------+-----+-------+-------+-------+------+------+ 2406 * Indicates IsExportable is true. ** FORTEZZA uses its own key and IV 2407 generation algorithms. 2409 Table 2 2411 Key Material The number of bytes from the key_block that are used 2412 for generating the write keys. 2414 Expanded Key Material The number of bytes actually fed into the 2415 encryption algorithm. 2417 Effective Key Bits How much entropy material is in the key material 2418 being fed into the encryption routines. 2420 +---------------+-----------+--------------+ 2421 | Hash function | Hash Size | Padding Size | 2422 +---------------+-----------+--------------+ 2423 | NULL | 0 | 0 | 2424 | MD5 | 16 | 48 | 2425 | SHA | 20 | 40 | 2426 +---------------+-----------+--------------+ 2428 Table 3 2430 Appendix D. Implementation Notes 2432 The SSL protocol cannot prevent many common security mistakes. This 2433 section provides several recommendations to assist implementers. 2435 D.1. Temporary RSA keys 2437 US Export restrictions limit RSA keys used for encryption to 512 2438 bits, but do not place any limit on lengths of RSA keys used for 2439 signing operations. Certificates often need to be larger than 512 2440 bits, since 512-bit RSA keys are not secure enough for high-value 2441 transactions or for applications requiring long-term security. Some 2442 certificates are also designated signing-only, in which case they 2443 cannot be used for key exchange. 2445 When the public key in the certificate cannot be used for encryption, 2446 the server signs a temporary RSA key, which is then exchanged. In 2447 exportable applications, the temporary RSA key should be the maximum 2448 allowable length (i.e., 512 bits). Because 512-bit RSA keys are 2449 relatively insecure, they should be changed often. For typical 2450 electronic commerce applications, it is suggested that keys be 2451 changed daily or every 500 transactions, and more often if possible. 2452 Note that while it is acceptable to use the same temporary key for 2453 multiple transactions, it must be signed each time it is used. 2455 RSA key generation is a time-consuming process. In many cases, a 2456 low-priority process can be assigned the task of key generation. 2457 Whenever a new key is completed, the existing temporary key can be 2458 replaced with the new one. 2460 D.2. Random Number Generation and Seeding 2462 SSL requires a cryptographically-secure pseudorandom number generator 2463 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs 2464 based on secure hash operations, most notably MD5 and/or SHA, are 2465 acceptable, but cannot provide more security than the size of the 2466 random number generator state. (For example, MD5-based PRNGs usually 2467 provide 128 bits of state.) 2469 To estimate the amount of seed material being produced, add the 2470 number of bits of unpredictable information in each seed byte. For 2471 example, keystroke timing values taken from a PC- compatible's 18.2 2472 Hz timer provide 1 or 2 secure bits each, even though the total size 2473 of the counter value is 16 bits or more. To seed a 128-bit PRNG, one 2474 would thus require approximately 100 such timer values. 2476 Note: The seeding functions in RSAREF and versions of BSAFE prior to 2477 3.0 are order-independent. For example, if 1000 seed bits are 2478 supplied, one at a time, in 1000 separate calls to the seed function, 2479 the PRNG will end up in a state which depends only on the number of 0 2480 or 1 seed bits in the seed data (i.e., there are 1001 possible final 2481 states). Applications using BSAFE or RSAREF must take extra care to 2482 ensure proper seeding. 2484 D.3. Certificates and authentication 2486 Implementations are responsible for verifying the integrity of 2487 certificates and should generally support certificate revocation 2488 messages. Certificates should always be verified to ensure proper 2489 signing by a trusted Certificate Authority (CA). The selection and 2490 addition of trusted CAs should be done very carefully. Users should 2491 be able to view information about the certificate and root CA. 2493 D.4. CipherSuites 2495 SSL supports a range of key sizes and security levels, including some 2496 which provide no or minimal security. A proper implementation will 2497 probably not support many cipher suites. For example, 40-bit 2498 encryption is easily broken, so implementations requiring strong 2499 security should not allow 40-bit keys. Similarly, anonymous Diffie- 2500 Hellman is strongly discouraged because it cannot prevent man-in-the- 2501 middle attacks. Applications should also enforce minimum and maximum 2502 key sizes. For example, certificate chains containing 512-bit RSA 2503 keys or signatures are not appropriate for high-security 2504 applications. 2506 D.5. FORTEZZA 2508 This section describes implementation details for ciphersuites that 2509 make use of the FORTEZZA hardware encryption system. 2511 D.5.1. Notes on use of FORTEZZA hardware 2513 A complete explanation of all issues regarding the use of FORTEZZA 2514 hardware is outside the scope of this document. However, there are a 2515 few special requirements of SSL that deserve mention. 2517 Because SSL is a full duplex protocol, two crypto states must be 2518 maintained, one for reading and one for writing. There are also a 2519 number of circumstances which can result in the crypto state in the 2520 FORTEZZA card being lost. For these reasons, it's recommended that 2521 the current crypto state be saved after processing a record, and 2522 loaded before processing the next. 2524 After the client generates the TEK, it also generates two MEKs, for 2525 one for reading and one for writing. After generating each of these 2526 keys, the client must generate a corresponding IV and then save the 2527 crypto state. The client also uses the TEK to generate an IV and 2528 encrypt the premaster secret. All three IVs are sent to the server, 2529 along with the wrapped keys and the encrypted premaster secret in the 2530 client key exchange message. At this point, the TEK is no longer 2531 needed, and may be discarded. 2533 On the server side, the server uses the master IV and the TEK to 2534 decrypt the premaster secret. It also loads the wrapped MEKs into 2535 the card. The server loads both IVs to verify that the IVs match the 2536 keys. However, since the card is unable to encrypt after loading an 2537 IV, the server must generate a new IV for the server write key. This 2538 IV is discarded. 2540 When encrypting the first encrypted record (and only that record), 2541 the server adds 8 bytes of random data to the beginning of the 2542 fragment. These 8 bytes are discarded by the client after 2543 decryption. The purpose of this is to synchronize the state on the 2544 client and server resulting from the different IVs. 2546 D.5.2. FORTEZZA Ciphersuites 2548 5) FORTEZZA_NULL_WITH_NULL_SHA: Uses the full FORTEZZA key exchange, 2549 including sending server and client write keys and iv's. 2551 D.5.3. FORTEZZA Session resumption 2553 There are two possibilities for FORTEZZA session restart: 1) Never 2554 restart a FORTEZZA session. 2) Restart a session with the previously 2555 negotiated keys and iv's. 2557 Never restarting a FORTEZZA session: 2559 Clients who never restart FORTEZZA sessions should never send Session 2560 ID's which were previously used in a FORTEZZA session as part of the 2561 ClientHello. Servers who never restart FORTEZZA sessions should 2562 never send a previous session id on the ServerHello if the negotiated 2563 session is FORTEZZA. 2565 Restart a session: 2567 You cannot restart FORTEZZA on a session which has never done a 2568 complete FORTEZZA key exchange (That is you cannot restart FORTEZZA 2569 if the session was an RSA/RC4 session renegotiated for FORTEZZA). If 2570 you wish to restart a FORTEZZA session, you must save the MEKs and 2571 IVs from the initial key exchange for this session and reuse them for 2572 any new connections on that session. This is not recommended, but it 2573 is possible. 2575 Appendix E. Version 2.0 Backward Compatibility 2577 Version 3.0 clients that support Version 2.0 servers must send 2578 Version 2.0 client hello messages [SSL-2]. Version 3.0 servers 2579 should accept either client hello format. The only deviations from 2580 the Version 2.0 specification are the ability to specify a version 2581 with a value of three and the support for more ciphering types in the 2582 CipherSpec. 2584 Warning: The ability to send Version 2.0 client hello messages will 2585 be phased out with all due haste. Implementers should make every 2586 effort to move forward as quickly as possible. Version 3.0 provides 2587 better mechanisms for transitioning to newer versions. 2589 The following cipher specifications are carryovers from SSL Version 2590 2.0. These are assumed to use RSA for key exchange and 2591 authentication. 2593 V2CipherSpec SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; 2594 V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; 2595 V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; 2596 V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 2597 = { 0x04,0x00,0x80 }; 2598 V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; 2599 V2CipherSpec SSL_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; 2600 V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; 2602 Cipher specifications introduced in Version 3.0 can be included in 2603 Version 2.0 client hello messages using the syntax below. Any 2604 V2CipherSpec element with its first byte equal to zero will be 2605 ignored by Version 2.0 servers. Clients sending any of the above 2606 V2CipherSpecs should also include the Version 3.0 equivalent (see 2607 Appendix A.6): 2609 V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite }; 2611 E.1. Version 2 client hello 2613 The Version 2.0 client hello message is presented below using this 2614 document's presentation model. The true definition is still assumed 2615 to be the SSL Version 2.0 specification. 2617 uint8 V2CipherSpec[3]; 2619 struct { 2620 unit8 msg_type; 2621 Version version; 2622 uint16 cipher_spec_length; 2623 uint16 session_id_length; 2624 uint16 challenge_length; 2625 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; 2626 opaque session_id[V2ClientHello.session_id_length]; 2627 Random challenge; 2628 } V2ClientHello; 2630 session msg_type This field, in conjunction with the version field, 2631 identifies a version 2 client hello message. The value should 2632 equal one (1). 2634 version The highest version of the protocol supported by the client 2635 (equals ProtocolVersion.version, see Appendix A.1). 2637 cipher_spec_length This field is the total length of the field 2638 cipher_specs. It cannot be zero and must be a multiple of the 2639 V2CipherSpec length (3). 2641 session_id_length This field must have a value of either zero or 16. 2642 If zero, the client is creating a new session. If 16, the 2643 session_id field will contain the 16 bytes of session 2644 identification. 2646 challenge_length The length in bytes of the client's challenge to 2647 the server to authenticate itself. This value must be 32. 2649 cipher_specs This is a list of all CipherSpecs the client is willing 2650 and able to use. There must be at least one CipherSpec acceptable 2651 to the server. 2653 session_id If this field's length is not zero, it will contain the 2654 identification for a session that the client wishes to resume. 2656 challenge The client's challenge to the server for the server to 2657 identify itself is a (nearly) arbitrary length random. The 2658 Version 3.0 server will right justify the challenge data to become 2659 the ClientHello.random data (padded with leading zeroes, if 2660 necessary), as specified in this Version 3.0 protocol. If the 2661 length of the challenge is greater than 32 bytes, then only the 2662 last 32 bytes are used. It is legitimate (but not necessary) for 2663 a V3 server to reject a V2 ClientHello that has fewer than 16 2664 bytes of challenge data. 2666 Note: Requests to resume an SSL 3.0 session should use an SSL 3.0 2667 client hello. 2669 E.2. Avoiding man-in-the-middle version rollback 2671 When SSL Version 3.0 clients fall back to Version 2.0 compatibility 2672 mode, they use special PKCS #1 block formatting. This is done so 2673 that Version 3.0 servers will reject Version 2.0 sessions with 2674 Version 3.0-capable clients. 2676 When Version 3.0 clients are in Version 2.0 compatibility mode, they 2677 set the right-hand (least-significant) 8 random bytes of the PKCS 2678 padding (not including the terminal null of the padding) for the RSA 2679 encryption of the ENCRYPTED-KEY- DATA field of the CLIENT-MASTER-KEY 2680 to 0x03 (the other padding bytes are random). After decrypting the 2681 ENCRYPTED- KEY-DATA field, servers that support SSL 3.0 should issue 2682 an error if these eight padding bytes are 0x03. Version 2.0 servers 2683 receiving blocks padded in this manner will proceed normally. 2685 Appendix F. Security analysis 2687 The SSL protocol is designed to establish a secure connection between 2688 a client and a server communicating over an insecure channel. This 2689 document makes several traditional assumptions, including that 2690 attackers have substantial computational resources and cannot obtain 2691 secret information from sources outside the protocol. Attackers are 2692 assumed to have the ability to capture, modify, delete, replay, and 2693 otherwise tamper with messages sent over the communication channel. 2694 This appendix outlines how SSL has been designed to resist a variety 2695 of attacks. 2697 F.1. Handshake protocol 2699 The handshake protocol is responsible for selecting a CipherSpec and 2700 generating a MasterSecret, which together comprise the primary 2701 cryptographic parameters associated with a secure session. The 2702 handshake protocol can also optionally authenticate parties who have 2703 certificates signed by a trusted certificate authority. 2705 F.1.1. Authentication and key exchange 2707 SSL supports three authentication modes: authentication of both 2708 parties, server authentication with an unauthenticated client, and 2709 total anonymity. Whenever the server is authenticated, the channel 2710 should be secure against man-in- the-middle attacks, but completely 2711 anonymous sessions are inherently vulnerable to such attacks. 2713 Anonymous servers cannot authenticate clients, since the client 2714 signature in the certificate verify message may require a server 2715 certificate to bind the signature to a particular server. If the 2716 server is authenticated, its certificate message must provide a valid 2717 certificate chain leading to an acceptable certificate authority. 2718 Similarly, authenticated clients must supply an acceptable 2719 certificate to the server. Each party is responsible for verifying 2720 that the other's certificate is valid and has not expired or been 2721 revoked. 2723 The general goal of the key exchange process is to create a 2724 pre_master_secret known to the communicating parties and not to 2725 attackers. The pre_master_secret will be used to generate the 2726 master_secret (see Section 6.1). The master_secret is required to 2727 generate the finished messages, encryption keys, and MAC secrets (see 2728 Section 5.6.9 and Section 6.2.2). By sending a correct finished 2729 message, parties thus prove that they know the correct 2730 pre_master_secret. 2732 F.1.1.1. Anonymous key exchange 2734 Completely anonymous sessions can be established using RSA, Diffie- 2735 Hellman, or FORTEZZA for key exchange. With anonymous RSA, the 2736 client encrypts a pre_master_secret with the server's uncertified 2737 public key extracted from the server key exchange message. The 2738 result is sent in a client key exchange message. Since eavesdroppers 2739 do not know the server's private key, it will be infeasible for them 2740 to decode the pre_master_secret. 2742 With Diffie-Hellman or FORTEZZA, the server's public parameters are 2743 contained in the server key exchange message and the client's are 2744 sent in the client key exchange message. Eavesdroppers who do not 2745 know the private values should not be able to find the Diffie-Hellman 2746 result (i.e. the pre_master_secret) or the FORTEZZA token encryption 2747 key (TEK). 2749 Warning: Completely anonymous connections only provide protection 2750 against passive eavesdropping. Unless an independent tamper-proof 2751 channel is used to verify that the finished messages were not 2752 replaced by an attacker, server authentication is required in 2753 environments where active man-in-the-middle attacks are a concern. 2755 F.1.1.2. RSA key exchange and authentication 2757 With RSA, key exchange and server authentication are combined. The 2758 public key may be either contained in the server's certificate or may 2759 be a temporary RSA key sent in a server key exchange message. When 2760 temporary RSA keys are used, they are signed by the server's RSA or 2761 DSS certificate. The signature includes the current 2762 ClientHello.random, so old signatures and temporary keys cannot be 2763 replayed. Servers may use a single temporary RSA key for multiple 2764 negotiation sessions. 2766 Note: The temporary RSA key option is useful if servers need large 2767 certificates but must comply with government-imposed size limits on 2768 keys used for key exchange. 2770 After verifying the server's certificate, the client encrypts a 2771 pre_master_secret with the server's public key. By successfully 2772 decoding the pre_master_secret and producing a correct finished 2773 message, the server demonstrates that it knows the private key 2774 corresponding to the server certificate. 2776 When RSA is used for key exchange, clients are authenticated using 2777 the certificate verify message (see Section 5.6.8). The client signs 2778 a value derived from the master_secret and all preceding handshake 2779 messages. These handshake messages include the server certificate, 2780 which binds the signature to the server, and ServerHello.random, 2781 which binds the signature to the current handshake process. 2783 F.1.1.3. Diffie-Hellman key exchange with authentication 2785 When Diffie-Hellman key exchange is used, the server can either 2786 supply a certificate containing fixed Diffie-Hellman parameters or 2787 can use the server key exchange message to send a set of temporary 2788 Diffie-Hellman parameters signed with a DSS or RSA certificate. 2789 Temporary parameters are hashed with the hello.random values before 2790 signing to ensure that attackers do not replay old parameters. In 2791 either case, the client can verify the certificate or signature to 2792 ensure that the parameters belong to the server. 2794 If the client has a certificate containing fixed Diffie- Hellman 2795 parameters, its certificate contains the information required to 2796 complete the key exchange. Note that in this case the client and 2797 server will generate the same Diffie- Hellman result (i.e., 2798 pre_master_secret) every time they communicate. To prevent the 2799 pre_master_secret from staying in memory any longer than necessary, 2800 it should be converted into the master_secret as soon as possible. 2801 Client Diffie- Hellman parameters must be compatible with those 2802 supplied by the server for the key exchange to work. 2804 If the client has a standard DSS or RSA certificate or is 2805 unauthenticated, it sends a set of temporary parameters to the server 2806 in the client key exchange message, then optionally uses a 2807 certificate verify message to authenticate itself. 2809 F.1.1.4. FORTEZZA 2811 FORTEZZA's design is classified, but at the protocol level it is 2812 similar to Diffie-Hellman with fixed public values contained in 2813 certificates. The result of the key exchange process is the token 2814 encryption key (TEK), which is used to wrap data encryption keys, 2815 client write key, server write key, and master secret encryption key. 2816 The data encryption keys are not derived from the pre_master_secret 2817 because unwrapped keys are not accessible outside the token. The 2818 encrypted pre_master_secret is sent to the server in a client key 2819 exchange message. 2821 F.1.2. Version rollback attacks 2823 Because SSL Version 3.0 includes substantial improvements over SSL 2824 Version 2.0, attackers may try to make Version 3.0- capable clients 2825 and servers fall back to Version 2.0. This attack is occurring if 2826 (and only if) two Version 3.0-capable parties use an SSL 2.0 2827 handshake. 2829 Although the solution using non-random PKCS #1 block type 2 message 2830 padding is inelegant, it provides a reasonably secure way for Version 2831 3.0 servers to detect the attack. This solution is not secure 2832 against attackers who can brute force the key and substitute a new 2833 ENCRYPTED-KEY-DATA message containing the same key (but with normal 2834 padding) before the application specified wait threshold has expired. 2835 Parties concerned about attacks of this scale should not be using 40- 2836 bit encryption keys anyway. Altering the padding of the least- 2837 significant 8 bytes of the PKCS padding does not impact security, 2838 since this is essentially equivalent to increasing the input block 2839 size by 8 bytes. 2841 F.1.3. Detecting attacks against the handshake protocol 2843 An attacker might try to influence the handshake exchange to make the 2844 parties select different encryption algorithms than they would 2845 normally choose. Because many implementations will support 40-bit 2846 exportable encryption and some may even support null encryption or 2847 MAC algorithms, this attack is of particular concern. 2849 For this attack, an attacker must actively change one or more 2850 handshake messages. If this occurs, the client and server will 2851 compute different values for the handshake message hashes. As a 2852 result, the parties will not accept each others' finished messages. 2853 Without the master_secret, the attacker cannot repair the finished 2854 messages, so the attack will be discovered. 2856 F.1.4. Resuming sessions 2858 When a connection is established by resuming a session, new 2859 ClientHello.random and ServerHello.random values are hashed with the 2860 session's master_secret. Provided that the master_secret has not 2861 been compromised and that the secure hash operations used to produce 2862 the encryption keys and MAC secrets are secure, the connection should 2863 be secure and effectively independent from previous connections. 2864 Attackers cannot use known encryption keys or MAC secrets to 2865 compromise the master_secret without breaking the secure hash 2866 operations (which use both SHA and MD5). 2868 Sessions cannot be resumed unless both the client and server agree. 2869 If either party suspects that the session may have been compromised, 2870 or that certificates may have expired or been revoked, it should 2871 force a full handshake. An upper limit of 24 hours is suggested for 2872 session ID lifetimes, since an attacker who obtains a master_secret 2873 may be able to impersonate the compromised party until the 2874 corresponding session ID is retired. Applications that may be run in 2875 relatively insecure environments should not write session IDs to 2876 stable storage. 2878 F.1.5. MD5 and SHA 2880 SSL uses hash functions very conservatively. Where possible, both 2881 MD5 and SHA are used in tandem to ensure that non- catastrophic flaws 2882 in one algorithm will not break the overall protocol. 2884 F.2. Protecting application data 2886 The master_secret is hashed with the ClientHello.random and 2887 ServerHello.random to produce unique data encryption keys and MAC 2888 secrets for each connection. FORTEZZA encryption keys are generated 2889 by the token, and are not derived from the master_secret. 2891 Outgoing data is protected with a MAC before transmission. To 2892 prevent message replay or modification attacks, the MAC is computed 2893 from the MAC secret, the sequence number, the message length, the 2894 message contents, and two fixed character strings. The message type 2895 field is necessary to ensure that messages intended for one SSL 2896 Record Layer client are not redirected to another. The sequence 2897 number ensures that attempts to delete or reorder messages will be 2898 detected. Since sequence numbers are 64-bits long, they should never 2899 overflow. Messages from one party cannot be inserted into the 2900 other's output, since they use independent MAC secrets. Similarly, 2901 the server-write and client-write keys are independent so stream 2902 cipher keys are used only once. 2904 If an attacker does break an encryption key, all messages encrypted 2905 with it can be read. Similarly, compromise of a MAC key can make 2906 message modification attacks possible. Because MACs are also 2907 encrypted, message-alteration attacks generally require breaking the 2908 encryption algorithm as well as the MAC. 2910 Note: MAC secrets may be larger than encryption keys, so messages can 2911 remain tamper resistant even if encryption keys are broken. 2913 F.3. Final notes 2915 For SSL to be able to provide a secure connection, both the client 2916 and server systems, keys, and applications must be secure. In 2917 addition, the implementation must be free of security errors. 2919 The system is only as strong as the weakest key exchange and 2920 authentication algorithm supported, and only trustworthy 2921 cryptographic functions should be used. Short public keys, 40-bit 2922 bulk encryption keys, and anonymous servers should be used with great 2923 caution. Implementations and users must be careful when deciding 2924 which certificates and certificate authorities are acceptable; a 2925 dishonest certificate authority can do tremendous damage. 2927 Appendix G. Acknowledgements 2929 G.1. Other contributors 2931 Martin Abadi Robert Relyea 2932 Digital Equipment Corporation Netscape Communications 2933 ma@pa.dec.com relyea@netscape.com 2935 Taher Elgamal Jim Roskind 2936 Netscape Communications Netscape Communications 2937 elgamal@netscape.com jar@netscape.com 2939 Anil Gangolli Micheal J. Sabin, Ph. D. 2940 Netscape Communications Consulting Engineer 2941 gangolli@netscape.com msabin@netcom.com 2943 Kipp E.B. Hickman Tom Weinstein 2944 Netscape Communications Netscape Communications 2945 kipp@netscape.com tomw@netscape.com 2947 G.2. Early reviewers 2949 Robert Baldwin Clyde Monma 2950 RSA Data Security, Inc. Bellcore 2951 baldwin@rsa.com clyde@bellcore.com 2953 George Cox Eric Murray 2954 Intel Corporation ericm@lne.com 2955 cox@ibeam.jf.intel.com 2957 Cheri Dowell Avi Rubin 2958 Sun Microsystems Bellcore 2959 cheri@eng.sun.com rubin@bellcore.com 2961 Stuart Haber Don Stephenson 2962 Bellcore Sun Microsystems 2963 stuart@bellcore.com don.stephenson@eng.sun.com 2965 Burt Kaliski Joe Tardo 2966 RSA Data Security, Inc. General Magic 2967 burt@rsa.com tardo@genmagic.com 2969 Authors' Addresses 2971 Alan O. Freier 2972 Netscape communications 2974 Philip Karlton 2975 Netscape communications 2977 Paul C. Kocher 2978 Independent consultant