| blob | 533df80818fdfbbd5a3e1daebe76ac32d50b482d |
1 Transport Layer Security Working Group Alan O. Freier
2 INTERNET-DRAFT Netscape Communications
3 Expire in six months Philip Karlton
4 Netscape Communications
5 Paul C. Kocher
6 Independent Consultant
7 November 18, 1996
18 The SSL Protocol
19 Version 3.0
22 <draft-freier-ssl-version3-02.txt>
30 Status of this memo
32 This document is an Internet-Draft. Internet-Drafts are working
33 documents of the Internet Engineering Task Force (IETF), its areas,
34 and its working groups. Note that other groups may also distribute
35 working documents as Internet- Drafts.
37 Internet-Drafts are draft documents valid for a maximum of six
38 months and may be updated, replaced, or made obsolete by other
39 documents at any time. It is inappropriate to use Internet-Drafts
40 as reference material or to cite them other than as work in
41 progress.
43 To learn the current status of any Internet-Draft, please check the
44 1id-abstracts.txt listing contained in the Internet Drafts Shadow
45 Directories on ds.internic.net (US East Coast), nic.nordu.net
46 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
47 Rim).
49 Abstract
51 This document specifies Version 3.0 of the Secure Sockets Layer
52 (SSL V3.0) protocol, a security protocol that provides
53 communications privacy over the Internet. The protocol allows
54 client/server applications to communicate in a way that is designed
55 to prevent eavesdropping, tampering, or message forgery.
58 Freier, Karlton, Kocher [Page 1]
59 .
61 INTERNET-DRAFT SSL 3.0 November 18, 1996
63 Table of Contents
64 Status of this memo 1
65 Abstract 1
66 Table of Contents 2
67 1. Introduction 4
68 2. Goals 4
69 3. Goals of this document 5
70 4. Presentation language 5
71 4.1 Basic block size 5
72 4.2 Miscellaneous 6
73 4.3 Vectors 6
74 4.4 Numbers 7
75 4.5 Enumerateds 7
76 4.6 Constructed types 8
77 4.6.1 Variants 8
78 4.7 Cryptographic attributes 9
79 4.8 Constants 10
80 5. SSL protocol 10
81 5.1 Session and connection states 10
82 5.2 Record layer 12
83 5.2.1 Fragmentation 12
84 5.2.2 Record compression and decompression 13
85 5.2.3 Record payload protection and the CipherSpec 13
86 5.2.3.1 Null or standard stream cipher 14
87 5.2.3.2 CBC block cipher 15
88 5.3 Change cipher spec protocol 16
89 5.4 Alert protocol 16
90 5.4.1 Closure alerts 17
91 5.4.2 Error alerts 17
92 5.5 Handshake protocol overview 18
93 5.6 Handshake protocol 20
94 5.6.1 Hello messages 21
95 5.6.1.1 Hello request 21
96 5.6.1.2 Client hello 21
97 5.6.1.3 Server hello 24
98 5.6.2 Server certificate 25
99 5.6.3 Server key exchange message 25
100 5.6.4 Certificate request 27
101 5.6.5 Server hello done 27
102 5.6.6 Client certificate 28
103 5.6.7 Client key exchange message 28
104 5.6.7.1 RSA encrypted premaster secret message 28
105 5.6.7.2 FORTEZZA key exchange message 29
106 5.6.7.3 Client Diffie-Hellman public value 30
107 5.6.8 Certificate verify 30
108 5.6.9 Finished 31
109 5.7 Application data protocol 32
110 6. Cryptographic computations 32
111 6.1 Asymmetric cryptographic computations 32
112 6.1.1 RSA 32
113 6.1.2 Diffie-Hellman 33
114 6.1.3 FORTEZZA 33
116 Freier, Karlton, Kocher [Page 2]
117 .
119 INTERNET-DRAFT SSL 3.0 November 18, 1996
121 6.2 Symmetric cryptographic calculations and the CipherSpec 33
122 6.2.1 The master secret 33
123 6.2.2 Converting the master secret into keys and MAC 33
124 6.2.2.1 Export key generation example 35
125 A. Protocol constant values 36
126 A.1 Reserved port assignments 36
127 A.1.1 Record layer 36
128 A.2 Change cipher specs message 37
129 A.3 Alert messages 37
130 A.4 Handshake protocol 37
131 A.4.1 Hello messages 38
132 A.4.2 Server authentication and key exchange messages 39
133 A.5 Client authentication and key exchange messages 40
134 A.5.1 Handshake finalization message 41
135 A.6 The CipherSuite 41
136 A.7 The CipherSpec 42
137 B. Glossary 44
138 C. CipherSuite definitions 47
139 D. Implementation Notes 49
140 D.1 Temporary RSA keys 49
141 D.2 Random Number Generation and Seeding 49
142 D.3 Certificates and authentication 50
143 D.4 CipherSuites 50
144 D.5 FORTEZZA 50
145 D.5.1 Notes on use of FORTEZZA hardware 50
146 D.5.2 FORTEZZA Ciphersuites 51
147 D.5.3 FORTEZZA Session resumption 51
148 E. Version 2.0 Backward Compatibility 52
149 E.1 Version 2 client hello 52
150 E.2 Avoiding man-in-the-middle version rollback 53
151 F. Security analysis 55
152 F.1 Handshake protocol 55
153 F.1.1 Authentication and key exchange 55
154 F.1.1.1 Anonymous key exchange 55
155 F.1.1.2 RSA key exchange and authentication 56
156 F.1.1.3 Diffie-Hellman key exchange with authentication 57
157 F.1.1.4 FORTEZZA 57
158 F.1.2 Version rollback attacks 57
159 F.1.3 Detecting attacks against the handshake protocol 58
160 F.1.4 Resuming sessions 58
161 F.1.5 MD5 and SHA 58
162 F.2 Protecting application data 59
163 F.3 Final notes 59
164 G. Patent Statement 60
165 References 61
166 Authors 62
174 Freier, Karlton, Kocher [Page 3]
175 .
177 INTERNET-DRAFT SSL 3.0 November 18, 1996
179 1. Introduction
181 The primary goal of the SSL Protocol is to provide privacy and
182 reliability between two communicating applications. The protocol
183 is composed of two layers. At the lowest level, layered on top of
184 some reliable transport protocol (e.g., TCP[TCP]), is the SSL
185 Record Protocol. The SSL Record Protocol is used for encapsulation
186 of various higher level protocols. One such encapsulated protocol,
187 the SSL Handshake Protocol, allows the server and client to
188 authenticate each other and to negotiate an encryption algorithm
189 and cryptographic keys before the application protocol transmits or
190 receives its first byte of data. One advantage of SSL is that it
191 is application protocol independent. A higher level protocol can
192 layer on top of the SSL Protocol transparently. The SSL protocol
193 provides connection security that has three basic properties:
195 - The connection is private. Encryption is used after an
196 initial handshake to define a secret key. Symmetric
197 cryptography is used for data encryption (e.g., DES[DES],
198 RC4[RC4], etc.)
199 - The peer's identity can be authenticated using asymmetric, or
200 public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.).
201 - The connection is reliable. Message transport includes a
202 message integrity check using a keyed MAC. Secure hash
203 functions (e.g., SHA, MD5, etc.) are used for MAC
204 computations.
206 2. Goals
208 The goals of SSL Protocol v3.0, in order of their priority,
209 are:
210 1. Cryptographic security
211 SSL should be used to establish a secure
212 connection between two parties.
213 2. Interoperability
214 Independent programmers should be able to
215 develop applications utilizing SSL 3.0 that
216 will then be able to successfully exchange
217 cryptographic parameters without knowledge of
218 one another's code.
220 Note: It is not the case that all instances of SSL (even
221 in the same application domain) will be able to
222 successfully connect. For instance, if the server
223 supports a particular hardware token, and the client
224 does not have access to such a token, then the
225 connection will not succeed.
227 3. Extensibility SSL seeks to provide a framework into which new
228 public key and bulk encryption methods can be
229 incorporated as necessary. This will also
230 accomplish two sub-goals: to prevent the need
232 Freier, Karlton, Kocher [Page 4]
233 .
235 INTERNET-DRAFT SSL 3.0 November 18, 1996
237 to create a new protocol (and risking the
238 introduction of possible new weaknesses) and to
239 avoid the need to implement an entire new
240 security library.
241 4. Relative efficiency
242 Cryptographic operations tend to be highly CPU
243 intensive, particularly public key operations.
244 For this reason, the SSL protocol has
245 incorporated an optional session caching scheme
246 to reduce the number of connections that need
247 to be established from scratch. Additionally,
248 care has been taken to reduce network activity.
250 3. Goals of this document
252 The SSL Protocol Version 3.0 Specification is intended primarily
253 for readers who will be implementing the protocol and those doing
254 cryptographic analysis of it. The spec has been written with this
255 in mind, and it is intended to reflect the needs of those two
256 groups. For that reason, many of the algorithm-dependent data
257 structures and rules are included in the body of the text (as
258 opposed to in an Appendix), providing easier access to them.
260 This document is not intended to supply any details of service
261 definition nor interface definition, although it does cover select
262 areas of policy as they are required for the maintenance of solid
263 security.
265 4. Presentation language
267 This document deals with the formatting of data in an external
268 representation. The following very basic and somewhat casually
269 defined presentation syntax will be used. The syntax draws from
270 several sources in its structure. Although it resembles the
271 programming language "C" in its syntax and XDR [XDR] in both its
272 syntax and intent, it would be risky to draw too many parallels.
273 The purpose of this presentation language is to document SSL only,
274 not to have general application beyond that particular goal.
276 4.1 Basic block size
278 The representation of all data items is explicitly specified. The
279 basic data block size is one byte (i.e. 8 bits). Multiple byte
280 data items are concatenations of bytes, from left to right, from
281 top to bottom. From the bytestream a multi-byte item (a numeric in
282 the example) is formed (using C notation) by:
284 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ...
285 | byte[n-1];
287 This byte ordering for multi-byte values is the commonplace network
288 byte order or big endian format.
290 Freier, Karlton, Kocher [Page 5]
291 .
293 INTERNET-DRAFT SSL 3.0 November 18, 1996
295 4.2 Miscellaneous
297 Comments begin with "/*" and end with "*/".
298 Optional components are denoted by enclosing them in "[[ ]]" double
299 brackets.
300 Single byte entities containing uninterpreted data are of type
301 opaque.
303 4.3 Vectors
305 A vector (single dimensioned array) is a stream of homogeneous data
306 elements. The size of the vector may be specified at documentation
307 time or left unspecified until runtime. In either case the length
308 declares the number of bytes, not the number of elements, in the
309 vector. The syntax for specifying a new type T' that is a fixed
310 length vector of type T is
312 T T'[n];
314 Here T' occupies n bytes in the data stream, where n is a multiple
315 of the size of T. The length of the vector is not included in the
316 encoded stream.
318 In the following example, Datum is defined to be three consecutive
319 bytes that the protocol does not interpret, while Data is three
320 consecutive Datum, consuming a total of nine bytes.
322 opaque Datum[3]; /* three uninterpreted bytes */
323 Datum Data[9]; /* 3 consecutive 3 byte vectors */
325 Variable length vectors are defined by specifying a subrange of
326 legal lengths, inclusively, using the notation <floor..ceiling>.
327 When encoded, the actual length precedes the vector's contents in
328 the byte stream. The length will be in the form of a number
329 consuming as many bytes as required to hold the vector's specified
330 maximum (ceiling) length. A variable length vector with an actual
331 length field of zero is referred to as an empty vector.
333 T T'<floor..ceiling>;
335 In the following example, mandatory is a vector that must contain
336 between 300 and 400 bytes of type opaque. It can never be empty.
337 The actual length field consumes two bytes, a uint16, sufficient to
338 represent the value 400 (see Section 4.4). On the other hand,
339 longer can represent up to 800 bytes of data, or 400 uint16
340 elements, and it may be empty. Its encoding will include a two
341 byte actual length field prepended to the vector.
343 opaque mandatory<300..400>;
344 /* length field is 2 bytes, cannot be empty */
345 uint16 longer<0..800>;
346 /* zero to 400 16-bit unsigned integers */
348 Freier, Karlton, Kocher [Page 6]
349 .
351 INTERNET-DRAFT SSL 3.0 November 18, 1996
353 4.4 Numbers
355 The basic numeric data type is an unsigned byte (uint8). All
356 larger numeric data types are formed from fixed length series of
357 bytes concatenated as described in Section 4.1 and are also
358 unsigned. The following numeric types are predefined.
360 uint8 uint16[2];
361 uint8 uint24[3];
362 uint8 uint32[4];
363 uint8 uint64[8];
365 4.5 Enumerateds
367 An additional sparse data type is available called enum. A field
368 of type enum can only assume the values declared in the definition.
369 Each definition is a different type. Only enumerateds of the same
370 type may be assigned or compared. Every element of an enumerated
371 must be assigned a value, as demonstrated in the following example.
372 Since the elements of the enumerated are not ordered, they can be
373 assigned any unique value, in any order.
375 enum { e1(v1), e2(v2), ... , en(vn), [[(n)]] } Te;
377 Enumerateds occupy as much space in the byte stream as would its
378 maximal defined ordinal value. The following definition would
379 cause one byte to be used to carry fields of type Color.
381 enum { red(3), blue(5), white(7) } Color;
383 One may optionally specify a value without its associated tag to
384 force the width definition without defining a superfluous element.
385 In the following example, Taste will consume two bytes in the data
386 stream but can only assume the values 1, 2 or 4.
388 enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
390 The names of the elements of an enumeration are scoped within the
391 defined type. In the first example, a fully qualified reference to
392 the second element of the enumeration would be Color.blue. Such
393 qualification is not required if the target of the assignment is
394 well specified.
396 Color color = Color.blue; /* overspecified, legal */
397 Color color = blue; /* correct, type implicit */
399 For enumerateds that are never converted to external
400 representation, the numerical information may be omitted.
402 enum { low, medium, high } Amount;
406 Freier, Karlton, Kocher [Page 7]
407 .
409 INTERNET-DRAFT SSL 3.0 November 18, 1996
411 4.6 Constructed types
413 Structure types may be constructed from primitive types for
414 convenience. Each specification declares a new, unique type. The
415 syntax for definition is much like that of C.
417 struct {
418 T1 f1;
419 T2 f2;
420 ...
421 Tn fn;
422 } [[T]];
424 The fields within a structure may be qualified using the type's
425 name using a syntax much like that available for enumerateds. For
426 example, T.f2 refers to the second field of the previous
427 declaration. Structure definitions may be embedded.
429 4.6.1 Variants
431 Defined structures may have variants based on some knowledge that
432 is available within the environment. The selector must be an
433 enumerated type that defines the possible variants the structure
434 defines. There must be a case arm for every element of the
435 enumeration declared in the select. The body of the variant
436 structure may be given a label for reference. The mechanism by
437 which the variant is selected at runtime is not prescribed by the
438 presentation language.
440 struct {
441 T1 f1;
442 T2 f2;
443 ....
444 Tn fn;
445 select (E) {
446 case e1: Te1;
447 case e2: Te2;
448 ....
449 case en: Ten;
450 } [[fv]];
451 } [[Tv]];
453 For example
455 enum { apple, orange } VariantTag;
456 struct {
457 uint16 number;
458 opaque string<0..10>; /* variable length */
459 } V1;
464 Freier, Karlton, Kocher [Page 8]
465 .
467 INTERNET-DRAFT SSL 3.0 November 18, 1996
469 struct {
470 uint32 number;
471 opaque string[10]; /* fixed length */
472 } V2;
473 struct {
474 select (VariantTag) { /* value of selector is implicit */
475 case apple: V1; /* VariantBody, tag = apple */
476 case orange: V2; /* VariantBody, tag = orange */
477 } variant_body; /* optional label on variant */
478 } VariantRecord;
480 Variant structures may be qualified (narrowed) by specifying a
481 value for the selector prior to the type. For example, a
483 orange VariantRecord
485 is a narrowed type of a VariantRecord containing a variant_body of
486 type V2.
488 4.7 Cryptographic attributes
490 The four cryptographic operations digital signing, stream cipher
491 encryption, block cipher encryption, and public key encryption are
492 designated digitally-signed, stream-ciphered, block-ciphered, and
493 public-key-encrypted, respectively. A field's cryptographic
494 processing is specified by prepending an appropriate key word
495 designation before the field's type specification. Cryptographic
496 keys are implied by the current session state (see Section 5.1).
498 In digital signing, one-way hash functions are used as input for a
499 signing algorithm. In RSA signing, a 36-byte structure of two
500 hashes (one SHA and one MD5) is signed (encrypted with the private
501 key). In DSS, the 20 bytes of the SHA hash are run directly
502 through the Digital Signing Algorithm with no additional hashing.
504 In stream cipher encryption, the plaintext is exclusive-ORed with
505 an identical amount of output generated from a
506 cryptographically-secure keyed pseudorandom number generator.
508 In block cipher encryption, every block of plaintext encrypts to a
509 block of ciphertext. Because it is unlikely that the plaintext
510 (whatever data is to be sent) will break neatly into the necessary
511 block size (usually 64 bits), it is necessary to pad out the end of
512 short blocks with some regular pattern, usually all zeroes.
514 In public key encryption, one-way functions with secret "trapdoors"
515 are used to encrypt the outgoing data. Data encrypted with the
516 public key of a given key pair can only be decrypted with the
517 private key, and vice-versa. In the following example:
522 Freier, Karlton, Kocher [Page 9]
523 .
525 INTERNET-DRAFT SSL 3.0 November 18, 1996
527 stream-ciphered struct {
528 uint8 field1;
529 uint8 field2;
530 digitally-signed opaque hash[20];
531 } UserType;
533 The contents of hash are used as input for the signing algorithm,
534 then the entire structure is encrypted with a stream cipher.
536 4.8 Constants
538 Typed constants can be defined for purposes of specification by
539 declaring a symbol of the desired type and assigning values to it.
540 Under-specified types (opaque, variable length vectors, and
541 structures that contain opaque) cannot be assigned values. No
542 fields of a multi-element structure or vector may be elided.
544 For example,
545 struct {
546 uint8 f1;
547 uint8 f2;
548 } Example1;
550 Example1 ex1 = {1, 4};/* assigns f1 = 1, f2 = 4 */
552 5. SSL protocol
554 SSL is a layered protocol. At each layer, messages may include
555 fields for length, description, and content. SSL takes messages to
556 be transmitted, fragments the data into manageable blocks,
557 optionally compresses the data, applies a MAC, encrypts, and
558 transmits the result. Received data is decrypted, verified,
559 decompressed, and reassembled, then delivered to higher level
560 clients.
562 5.1 Session and connection states
564 An SSL session is stateful. It is the responsibility of the SSL
565 Handshake protocol to coordinate the states of the client and
566 server, thereby allowing the protocol state machines of each to
567 operate consistently, despite the fact that the state is not
568 exactly parallel. Logically the state is represented twice, once
569 as the current operating state, and (during the handshake protocol)
570 again as the pending state. Additionally, separate read and write
571 states are maintained. When the client or server receives a change
572 cipher spec message, it copies the pending read state into the
573 current read state. When the client or server sends a change
574 cipher spec message, it copies the pending write state into the
575 current write state. When the handshake negotiation is complete,
576 the client and server exchange change cipher spec messages (see
577 Section 5.3), and they then communicate using the newly agreed-upon
578 cipher spec.
580 Freier, Karlton, Kocher [Page 10]
581 .
583 INTERNET-DRAFT SSL 3.0 November 18, 1996
585 An SSL session may include multiple secure connections; in
586 addition, parties may have multiple simultaneous sessions.
588 The session state includes the following elements:
590 session identifier
591 An arbitrary byte sequence chosen by the server
592 to identify an active or resumable session
593 state.
594 peer certificate X509.v3[X509] certificate of the peer. This
595 element of the state may be null.
596 compression method
597 The algorithm used to compress data prior to
598 encryption.
599 cipher spec Specifies the bulk data encryption algorithm
600 (such as null, DES, etc.) and a MAC algorithm
601 (such as MD5 or SHA). It also defines
602 cryptographic attributes such as the hash_size.
603 (See Appendix A.7 for formal definition)
604 master secret 48-byte secret shared between the client and
605 server.
606 is resumable A flag indicating whether the session can be
607 used to initiate new connections.
609 The connection state includes the following elements:
611 server and client random
612 Byte sequences that are chosen by the server
613 and client for each connection.
614 server write MAC secret
615 The secret used in MAC operations on data
616 written by the server
617 client write MAC secret
618 The secret used in MAC operations on data
619 written by the client.
620 server write key The bulk cipher key for data encrypted by the
621 server and decrypted by the client.
622 client write key The bulk cipher key for data encrypted by the
623 client and decrypted by the server.
624 initialization vectors
625 When a block cipher in CBC mode is used, an
626 initialization vector (IV) is maintained for
627 each key. This field is first initialized by
628 the SSL handshake protocol. Thereafter the
629 final ciphertext block from each record is
630 preserved for use with the following record.
631 sequence numbers Each party maintains separate sequence numbers
632 for transmitted and received messages for each
633 connection. When a party sends or receives a
634 change cipher spec message, the appropriate
635 sequence number is set to zero. Sequence
638 Freier, Karlton, Kocher [Page 11]
639 .
641 INTERNET-DRAFT SSL 3.0 November 18, 1996
643 numbers are of type uint64 and may not exceed
644 2^64-1.
646 5.2 Record layer
648 The SSL Record Layer receives uninterpreted data from higher layers
649 in non-empty blocks of arbitrary size.
651 5.2.1 Fragmentation
653 The record layer fragments information blocks into SSLPlaintext
654 records of 2^14 bytes or less. Client message boundaries are not
655 preserved in the record layer (i.e., multiple client messages of
656 the same ContentType may be coalesced into a single SSLPlaintext
657 record).
659 struct {
660 uint8 major, minor;
661 } ProtocolVersion;
663 enum {
664 change_cipher_spec(20), alert(21), handshake(22),
665 application_data(23), (255)
666 } ContentType;
668 struct {
669 ContentType type;
670 ProtocolVersion version;
671 uint16 length;
672 opaque fragment[SSLPlaintext.length];
673 } SSLPlaintext;
675 type The higher level protocol used to process the
676 enclosed fragment.
677 version The version of protocol being employed. This
678 document describes SSL Version 3.0 (See
679 Appendix A.1.1).
680 length The length (in bytes) of the following
681 SSLPlaintext.fragment. The length should not
682 exceed 2^14.
683 fragment The application data. This data is transparent
684 and treated as an independent block to be dealt
685 with by the higher level protocol specified by
686 the type field.
688 Note: Data of different SSL Record layer content types may
689 be interleaved. Application data is generally of
690 lower precedence for transmission than other content
691 types.
696 Freier, Karlton, Kocher [Page 12]
697 .
699 INTERNET-DRAFT SSL 3.0 November 18, 1996
701 5.2.2 Record compression and decompression
703 All records are compressed using the compression algorithm defined
704 in the current session state. There is always an active
705 compression algorithm, however initially it is defined as
706 CompressionMethod.null. The compression algorithm translates an
707 SSLPlaintext structure into an SSLCompressed structure.
708 Compression functions erase their state information whenever the
709 CipherSpec is replaced.
711 Note: The CipherSpec is part of the session state
712 described in Section 5.1. References to fields of
713 the CipherSpec are made throughout this document
714 using presentation syntax. A more complete
715 description of the CipherSpec is shown in Appendix
716 A.7.
718 Compression must be lossless and may not increase the content
719 length by more than 1024 bytes. If the decompression function
720 encounters an SSLCompressed.fragment that would decompress to a
721 length in excess of 2^14 bytes, it should issue a fatal
722 decompression_failure alert (Section 5.4.2).
724 struct {
725 ContentType type; /* same as SSLPlaintext.type */
726 ProtocolVersion version;/* same as SSLPlaintext.version */
727 uint16 length;
728 opaque fragment[SSLCompressed.length];
729 } SSLCompressed;
731 length The length (in bytes) of the following
732 SSLCompressed.fragment. The length
733 should not exceed 2^14 + 1024.
734 fragment The compressed form of
735 SSLPlaintext.fragment.
737 Note: A CompressionMethod.null operation is an identity
738 operation; no fields are altered.
739 (See Appendix A.4.1)
741 Implementation note:
742 Decompression functions are responsible for
743 ensuring that messages cannot cause internal buffer
744 overflows.
746 5.2.3 Record payload protection and the CipherSpec
748 All records are protected using the encryption and MAC algorithms
749 defined in the current CipherSpec. There is always an active
750 CipherSpec, however initially it is SSL_NULL_WITH_NULL_NULL, which
751 does not provide any security.
754 Freier, Karlton, Kocher [Page 13]
755 .
757 INTERNET-DRAFT SSL 3.0 November 18, 1996
759 Once the handshake is complete, the two parties have shared secrets
760 which are used to encrypt records and compute keyed message
761 authentication codes (MACs) on their contents. The techniques used
762 to perform the encryption and MAC operations are defined by the
763 CipherSpec and constrained by CipherSpec.cipher_type. The
764 encryption and MAC functions translate an SSLCompressed structure
765 into an SSLCiphertext. The decryption functions reverse the
766 process. Transmissions also include a sequence number so that
767 missing, altered, or extra messages are detectable.
769 struct {
770 ContentType type;
771 ProtocolVersion version;
772 uint16 length;
773 select (CipherSpec.cipher_type) {
774 case stream: GenericStreamCipher;
775 case block: GenericBlockCipher;
776 } fragment;
777 } SSLCiphertext;
779 type The type field is identical to
780 SSLCompressed.type.
781 version The version field is identical to
782 SSLCompressed.version.
783 length The length (in bytes) of the following
784 SSLCiphertext.fragment. The length may
785 not exceed 2^14 + 2048.
786 fragment The encrypted form of
787 SSLCompressed.fragment, including the
788 MAC.
790 5.2.3.1 Null or standard stream cipher
792 Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
793 A.7) convert SSLCompressed.fragment structures to and from stream
794 SSLCiphertext.fragment structures.
796 stream-ciphered struct {
797 opaque content[SSLCompressed.length];
798 opaque MAC[CipherSpec.hash_size];
799 } GenericStreamCipher;
801 The MAC is generated as:
803 hash(MAC_write_secret + pad_2 +
804 hash(MAC_write_secret + pad_1 + seq_num +
805 SSLCompressed.type + SSLCompressed.length +
806 SSLCompressed.fragment));
808 where "+" denotes concatenation.
812 Freier, Karlton, Kocher [Page 14]
813 .
815 INTERNET-DRAFT SSL 3.0 November 18, 1996
817 pad_1 The character 0x36 repeated 48 times for MD5
818 or 40 times for SHA.
819 pad_2 The character 0x5c repeated 48 times for MD5
820 or 40 times for SHA.
821 seq_num The sequence number for this message.
822 hash Hashing algorithm derived from the cipher
823 suite.
825 Note that the MAC is computed before encryption. The stream cipher
826 encrypts the entire block, including the MAC. For stream ciphers
827 that do not use a synchronization vector (such as RC4), the stream
828 cipher state from the end of one record is simply used on the
829 subsequent packet. If the CipherSuite is SSL_NULL_WITH_NULL_NULL,
830 encryption consists of the identity operation (i.e., the data is
831 not encrypted and the MAC size is zero implying that no MAC is
832 used). SSLCiphertext.length is SSLCompressed.length plus
833 CipherSpec.hash_size.
835 5.2.3.2 CBC block cipher
837 For block ciphers (such as RC2 or DES), the encryption and MAC
838 functions convert SSLCompressed.fragment structures to and from
839 block SSLCiphertext.fragment structures.
841 block-ciphered struct {
842 opaque content[SSLCompressed.length];
843 opaque MAC[CipherSpec.hash_size];
844 uint8 padding[GenericBlockCipher.padding_length];
845 uint8 padding_length;
846 } GenericBlockCipher;
848 The MAC is generated as described in Section 5.2.3.1.
850 padding Padding that is added to force the length of
851 the plaintext to be a multiple of the block
852 cipher's block length.
853 padding_length The length of the padding must be less than the
854 cipher's block length and may be zero. The
855 padding length should be such that the total
856 size of the GenericBlockCipher structure is a
857 multiple of the cipher's block length.
859 The encrypted data length (SSLCiphertext.length) is one more than
860 the sum of SSLCompressed.length, CipherSpec.hash_size, and
861 padding_length.
863 Note: With CBC block chaining the initialization vector
864 (IV) for the first record is provided by the
865 handshake protocol. The IV for subsequent records
866 is the last ciphertext block from the previous
867 record.
870 Freier, Karlton, Kocher [Page 15]
871 .
873 INTERNET-DRAFT SSL 3.0 November 18, 1996
875 5.3 Change cipher spec protocol
877 The change cipher spec protocol exists to signal transitions in
878 ciphering strategies. The protocol consists of a single message,
879 which is encrypted and compressed under the current (not the
880 pending) CipherSpec. The message consists of a single byte of
881 value 1.
883 struct {
884 enum { change_cipher_spec(1), (255) } type;
885 } ChangeCipherSpec;
887 The change cipher spec message is sent by both the client and
888 server to notify the receiving party that subsequent records will
889 be protected under the just-negotiated CipherSpec and keys.
890 Reception of this message causes the receiver to copy the read
891 pending state into the read current state. The client sends a
892 change cipher spec message following handshake key exchange and
893 certificate verify messages (if any), and the server sends one
894 after successfully processing the key exchange message it received
895 from the client. An unexpected change cipher spec message should
896 generate an unexpected_message alert (Section 5.4.2). When
897 resuming a previous session, the change cipher spec message is sent
898 after the hello messages.
900 5.4 Alert protocol
902 One of the content types supported by the SSL Record layer is the
903 alert type. Alert messages convey the severity of the message and
904 a description of the alert. Alert messages with a level of fatal
905 result in the immediate termination of the connection. In this
906 case, other connections corresponding to the session may continue,
907 but the session identifier must be invalidated, preventing the
908 failed session from being used to establish new connections. Like
909 other messages, alert messages are encrypted and compressed, as
910 specified by the current connection state.
912 enum { warning(1), fatal(2), (255) } AlertLevel;
914 enum {
915 close_notify(0),
916 unexpected_message(10),
917 bad_record_mac(20),
918 decompression_failure(30),
919 handshake_failure(40),
920 no_certificate(41),
921 bad_certificate(42),
922 unsupported_certificate(43),
923 certificate_revoked(44),
924 certificate_expired(45),
925 certificate_unknown(46),
928 Freier, Karlton, Kocher [Page 16]
929 .
931 INTERNET-DRAFT SSL 3.0 November 18, 1996
933 illegal_parameter (47)
934 (255)
935 } AlertDescription;
937 struct {
938 AlertLevel level;
939 AlertDescription description;
940 } Alert;
942 5.4.1 Closure alerts
944 The client and the server must share knowledge that the connection
945 is ending in order to avoid a truncation attack. Either party may
946 initiate the exchange of closing messages.
948 close_notify This message notifies the recipient that the
949 sender will not send any more messages on this
950 connection. The session becomes unresumable if
951 any connection is terminated without proper
952 close_notify messages with level equal to
953 warning.
955 Either party may initiate a close by sending a close_notify alert.
956 Any data received after a closure alert is ignored.
958 Each party is required to send a close_notify alert before closing
959 the write side of the connection. It is required that the other
960 party respond with a close_notify alert of its own and close down
961 the connection immediately, discarding any pending writes. It is
962 not required for the initiator of the close to wait for the
963 responding close_notify alert before closing the read side of the
964 connection.
966 NB: It is assumed that closing a connection reliably delivers
967 pending data before destroying the transport.
970 5.4.2 Error alerts
972 Error handling in the SSL Handshake protocol is very simple. When
973 an error is detected, the detecting party sends a message to the
974 other party. Upon transmission or receipt of an fatal alert
975 message, both parties immediately close the connection. Servers
976 and clients are required to forget any session-identifiers, keys,
977 and secrets associated with a failed connection. The following
978 error alerts are defined:
980 unexpected_message
981 An inappropriate message was received. This
982 alert is always fatal and should never be
983 observed in communication between proper
984 implementations.
986 Freier, Karlton, Kocher [Page 17]
987 .
989 INTERNET-DRAFT SSL 3.0 November 18, 1996
991 bad_record_mac This alert is returned if a record is received
992 with an incorrect MAC. This message is always
993 fatal.
994 decompression_failure
995 The decompression function received improper
996 input (e.g. data that would expand to excessive
997 length). This message is always fatal.
998 handshake_failure Reception of a handshake_failure alert message
999 indicates that the sender was unable to
1000 negotiate an acceptable set of security
1001 parameters given the options available. This
1002 is a fatal error.
1003 no_certificate A no_certificate alert message may be sent in
1004 response to a certification request if no
1005 appropriate certificate is available.
1006 bad_certificate A certificate was corrupt, contained signatures
1007 that did not verify correctly, etc.
1008 unsupported_certificate
1009 A certificate was of an unsupported type.
1010 certificate_revoked
1011 A certificate was revoked by its signer.
1012 certificate_expired
1013 A certificate has expired or is not currently
1014 valid.
1015 certificate_unknown
1016 Some other (unspecified) issue arose in
1017 processing the certificate, rendering it
1018 unacceptable.
1019 illegal_parameter A field in the handshake was out of range or
1020 inconsistent with other fields. This is always
1021 fatal.
1023 5.5 Handshake protocol overview
1025 The cryptographic parameters of the session state are produced by
1026 the SSL Handshake Protocol, which operates on top of the SSL Record
1027 Layer. When a SSL client and server first start communicating,
1028 they agree on a protocol version, select cryptographic algorithms,
1029 optionally authenticate each other, and use public-key encryption
1030 techniques to generate shared secrets. These processes are
1031 performed in the handshake protocol, which can be summarized as
1032 follows: The client sends a client hello message to which the
1033 server must respond with a server hello message, or else a fatal
1034 error will occur and the connection will fail. The client hello
1035 and server hello are used to establish security enhancement
1036 capabilities between client and server. The client hello and
1037 server hello establish the following attributes: Protocol Version,
1038 Session ID, Cipher Suite, and Compression Method. Additionally,
1039 two random values are generated and exchanged: ClientHello.random
1040 and ServerHello.random.
1044 Freier, Karlton, Kocher [Page 18]
1045 .
1047 INTERNET-DRAFT SSL 3.0 November 18, 1996
1049 Following the hello messages, the server will send its certificate,
1050 if it is to be authenticated. Additionally, a server key exchange
1051 message may be sent, if it is required (e.g. if their server has no
1052 certificate, or if its certificate is for signing only). If the
1053 server is authenticated, it may request a certificate from the
1054 client, if that is appropriate to the cipher suite selected. Now
1055 the server will send the server hello done message, indicating that
1056 the hello-message phase of the handshake is complete. The server
1057 will then wait for a client response. If the server has sent a
1058 certificate request Message, the client must send either the
1059 certificate message or a no_certificate alert. The client key
1060 exchange message is now sent, and the content of that message will
1061 depend on the public key algorithm selected between the client
1062 hello and the server hello. If the client has sent a certificate
1063 with signing ability, a digitally-signed certificate verify message
1064 is sent to explicitly verify the certificate.
1066 At this point, a change cipher spec message is sent by the client,
1067 and the client copies the pending Cipher Spec into the current
1068 Cipher Spec. The client then immediately sends the finished
1069 message under the new algorithms, keys, and secrets. In response,
1070 the server will send its own change cipher spec message, transfer
1071 the pending to the current Cipher Spec, and send its finished
1072 message under the new Cipher Spec. At this point, the handshake is
1073 complete and the client and server may begin to exchange
1074 application layer data. (See flow chart below.)
1076 Client Server
1078 ClientHello -------->
1079 ServerHello
1080 Certificate*
1081 ServerKeyExchange*
1082 CertificateRequest*
1083 <-------- ServerHelloDone
1084 Certificate*
1085 ClientKeyExchange
1086 CertificateVerify*
1087 [ChangeCipherSpec]
1088 Finished -------->
1089 [ChangeCipherSpec]
1090 <-------- Finished
1091 Application Data <-------> Application Data
1093 * Indicates optional or situation-dependent messages that are not
1094 always sent.
1096 Note: To help avoid pipeline stalls, ChangeCipherSpec is
1097 an independent SSL Protocol content type, and is not
1098 actually an SSL handshake message.
1102 Freier, Karlton, Kocher [Page 19]
1103 .
1105 INTERNET-DRAFT SSL 3.0 November 18, 1996
1107 When the client and server decide to resume a previous session or
1108 duplicate an existing session (instead of negotiating new security
1109 parameters) the message flow is as follows:
1111 The client sends a ClientHello using the Session ID of the session
1112 to be resumed. The server then checks its session cache for a
1113 match. If a match is found, and the server is willing to
1114 re-establish the connection under the specified session state, it
1115 will send a ServerHello with the same Session ID value. At this
1116 point, both client and server must send change cipher spec messages
1117 and proceed directly to finished messages. Once the
1118 re-establishment is complete, the client and server may begin to
1119 exchange application layer data. (See flow chart below.) If a
1120 Session ID match is not found, the server generates a new session
1121 ID and the SSL client and server perform a full handshake.
1123 Client Server
1125 ClientHello -------->
1126 ServerHello
1127 [change cipher spec]
1128 <-------- Finished
1129 change cipher spec
1130 Finished -------->
1131 Application Data <-------> Application Data
1133 The contents and significance of each message will be presented in
1134 detail in the following sections.
1136 5.6 Handshake protocol
1138 The SSL Handshake Protocol is one of the defined higher level
1139 clients of the SSL Record Protocol. This protocol is used to
1140 negotiate the secure attributes of a session. Handshake messages
1141 are supplied to the SSL Record Layer, where they are encapsulated
1142 within one or more SSLPlaintext structures, which are processed and
1143 transmitted as specified by the current active session state.
1145 enum {
1146 hello_request(0), client_hello(1), server_hello(2),
1147 certificate(11), server_key_exchange (12),
1148 certificate_request(13), server_hello_done(14),
1149 certificate_verify(15), client_key_exchange(16),
1150 finished(20), (255)
1151 } HandshakeType;
1153 struct {
1154 HandshakeType msg_type; /* handshake type */
1155 uint24 length; /* bytes in message */
1156 select (HandshakeType) {
1157 case hello_request: HelloRequest;
1158 case client_hello: ClientHello;
1160 Freier, Karlton, Kocher [Page 20]
1161 .
1163 INTERNET-DRAFT SSL 3.0 November 18, 1996
1165 case server_hello: ServerHello;
1166 case certificate: Certificate;
1167 case server_key_exchange: ServerKeyExchange;
1168 case certificate_request: CertificateRequest;
1169 case server_hello_done: ServerHelloDone;
1170 case certificate_verify: CertificateVerify;
1171 case client_key_exchange: ClientKeyExchange;
1172 case finished: Finished;
1173 } body;
1174 } Handshake;
1176 The handshake protocol messages are presented in the order they
1177 must be sent; sending handshake messages in an unexpected order
1178 results in a fatal error.
1180 5.6.1 Hello messages
1182 The hello phase messages are used to exchange security enhancement
1183 capabilities between the client and server. When a new session
1184 begins, the CipherSpec encryption, hash, and compression algorithms
1185 are initialized to null. The current CipherSpec is used for
1186 renegotiation messages.
1188 5.6.1.1 Hello request
1190 The hello request message may be sent by the server at any time,
1191 but will be ignored by the client if the handshake protocol is
1192 already underway. It is a simple notification that the client
1193 should begin the negotiation process anew by sending a client hello
1194 message when convenient.
1196 Note: Since handshake messages are intended to have
1197 transmission precedence over application data, it is
1198 expected that the negotiation begin in no more than
1199 one or two times the transmission time of a maximum
1200 length application data message.
1202 After sending a hello request, servers should not repeat the
1203 request until the subsequent handshake negotiation is complete. A
1204 client that receives a hello request while in a handshake
1205 negotiation state should simply ignore the message.
1207 The structure of a hello request message is as follows:
1209 struct { } HelloRequest;
1211 5.6.1.2 Client hello
1213 When a client first connects to a server it is required to send the
1214 client hello as its first message. The client can also send a
1215 client hello in response to a hello request or on its own
1216 initiative in order to renegotiate the security parameters in an
1218 Freier, Karlton, Kocher [Page 21]
1219 .
1221 INTERNET-DRAFT SSL 3.0 November 18, 1996
1223 existing connection. The client hello message includes a random
1224 structure, which is used later in the protocol.
1226 struct {
1227 uint32 gmt_unix_time;
1228 opaque random_bytes[28];
1229 } Random;
1231 gmt_unix_time The current time and date in standard UNIX
1232 32-bit format according to the sender's
1233 internal clock. Clocks are not required to be
1234 set correctly by the basic SSL Protocol; higher
1235 level or application protocols may define
1236 additional requirements.
1237 random_bytes 28 bytes generated by a secure random number
1238 generator.
1240 The client hello message includes a variable length session
1241 identifier. If not empty, the value identifies a session between
1242 the same client and server whose security parameters the client
1243 wishes to reuse. The session identifier may be from an earlier
1244 connection, this connection, or another currently active
1245 connection. The second option is useful if the client only wishes
1246 to update the random structures and derived values of a connection,
1247 while the third option makes it possible to establish several
1248 simultaneous independent secure connections without repeating the
1249 full handshake protocol. The actual contents of the SessionID are
1250 defined by the server.
1252 opaque SessionID<0..32>;
1254 Warning: Servers must not place confidential information in
1255 session identifiers or let the contents of fake
1256 session identifiers cause any breach of security.
1258 The CipherSuite list, passed from the client to the server in the
1259 client hello message, contains the combinations of cryptographic
1260 algorithms supported by the client in order of the client's
1261 preference (first choice first). Each CipherSuite defines both a
1262 key exchange algorithm and a CipherSpec. The server will select a
1263 cipher suite or, if no acceptable choices are presented, return a
1264 handshake failure alert and close the connection.
1266 uint8 CipherSuite[2]; /* Cryptographic suite selector */
1268 The client hello includes a list of compression algorithms
1269 supported by the client, ordered according to the client's
1270 preference. If the server supports none of those specified by the
1271 client, the session must fail.
1273 enum { null(0), (255) } CompressionMethod;
1276 Freier, Karlton, Kocher [Page 22]
1277 .
1279 INTERNET-DRAFT SSL 3.0 November 18, 1996
1281 Issue: Which compression methods to support is under
1282 investigation.
1284 The structure of the client hello is as follows.
1285 struct {
1286 ProtocolVersion client_version;
1287 Random random;
1288 SessionID session_id;
1289 CipherSuite cipher_suites<2..2^16-1>;
1290 CompressionMethod compression_methods<1..2^8-1>;
1291 } ClientHello;
1293 client_version The version of the SSL protocol by which the
1294 client wishes to communicate during this
1295 session. This should be the most recent
1296 (highest valued) version supported by the
1297 client. For this version of the specification,
1298 the version will be 3.0 (See Appendix E for
1299 details about backward compatibility).
1300 random A client-generated random structure.
1301 session_id The ID of a session the client wishes to use
1302 for this connection. This field should be
1303 empty if no session_id is available or the
1304 client wishes to generate new security
1305 parameters.
1306 cipher_suites This is a list of the cryptographic options
1307 supported by the client, sorted with the
1308 client's first preference first. If the
1309 session_id field is not empty (implying a
1310 session resumption request) this vector must
1311 include at least the cipher_suite from that
1312 session. Values are defined in Appendix A.6.
1313 compression_methods
1314 This is a list of the compression methods
1315 supported by the client, sorted by client
1316 preference. If the session_id field is not
1317 empty (implying a session resumption request)
1318 this vector must include at least the
1319 compression_method from that session. All
1320 implementations must support
1321 CompressionMethod.null.
1323 After sending the client hello message, the client waits for a
1324 server hello message. Any other handshake message returned by the
1325 server except for a hello request is treated as a fatal error.
1327 Implementation note:
1328 Application data may not be sent before a finished
1329 message has been sent. Transmitted application data
1330 is known to be insecure until a valid finished
1331 message has been received. This absolute
1334 Freier, Karlton, Kocher [Page 23]
1335 .
1337 INTERNET-DRAFT SSL 3.0 November 18, 1996
1339 restriction is relaxed if there is a current,
1340 non-null encryption on this connection.
1342 Forward compatibility note:
1343 In the interests of forward compatibility, it is
1344 permitted for a client hello message to include
1345 extra data after the compression methods. This data
1346 must be included in the handshake hashes, but must
1347 otherwise be ignored.
1349 5.6.1.3 Server hello
1351 The server processes the client hello message and responds with
1352 either a handshake_failure alert or server hello message.
1354 struct {
1355 ProtocolVersion server_version;
1356 Random random;
1357 SessionID session_id;
1358 CipherSuite cipher_suite;
1359 CompressionMethod compression_method;
1360 } ServerHello;
1362 server_version This field will contain the lower of that
1363 suggested by the client in the client hello and
1364 the highest supported by the server. For this
1365 version of the specification, the version will
1366 be 3.0 (See Appendix E for details about
1367 backward compatibility).
1368 random This structure is generated by the server and
1369 must be different from (and independent of)
1370 ClientHello.random.
1371 session_id This is the identity of the session
1372 corresponding to this connection. If the
1373 ClientHello.session_id was non-empty, the
1374 server will look in its session cache for a
1375 match. If a match is found and the server is
1376 willing to establish the new connection using
1377 the specified session state, the server will
1378 respond with the same value as was supplied by
1379 the client. This indicates a resumed session
1380 and dictates that the parties must proceed
1381 directly to the finished messages. Otherwise
1382 this field will contain a different value
1383 identifying the new session. The server may
1384 return an empty session_id to indicate that the
1385 session will not be cached and therefore cannot
1386 be resumed.
1387 cipher_suite The single cipher suite selected by the server
1388 from the list in ClientHello.cipher_suites.
1389 For resumed sessions this field is the value
1390 from the state of the session being resumed.
1392 Freier, Karlton, Kocher [Page 24]
1393 .
1395 INTERNET-DRAFT SSL 3.0 November 18, 1996
1397 compression_method
1398 The single compression algorithm selected by
1399 the server from the list in
1400 ClientHello.compression_methods. For resumed
1401 sessions this field is the value from the
1402 resumed session state.
1404 5.6.2 Server certificate
1406 If the server is to be authenticated (which is generally the case),
1407 the server sends its certificate immediately following the server
1408 hello message. The certificate type must be appropriate for the
1409 selected cipher suite's key exchange algorithm, and is generally an
1410 X.509.v3 certificate (or a modified X.509 certificate in the case
1411 of FORTEZZA(tm) [FOR]). The same message type will be used for the
1412 client's response to a certificate request message.
1414 opaque ASN.1Cert<1..2^24-1>;
1415 struct {
1416 ASN.1Cert certificate_list<1..2^24-1>;
1417 } Certificate;
1419 certificate_list This is a sequence (chain) of X.509.v3
1420 certificates, ordered with the sender's
1421 certificate first followed by any certificate
1422 authority certificates proceeding sequentially
1423 upward.
1425 Note: PKCS #7 [PKCS7] is not used as the format for the
1426 certificate vector because PKCS #6 [PKCS6] extended
1427 certificates are not used. Also PKCS #7 defines a
1428 SET rather than a SEQUENCE, making the task of
1429 parsing the list more difficult.
1431 5.6.3 Server key exchange message
1433 The server key exchange message is sent by the server if it has no
1434 certificate, has a certificate only used for signing (e.g., DSS
1435 [DSS] certificates, signing-only RSA [RSA] certificates), or
1436 FORTEZZA KEA key exchange is used. This message is not used if the
1437 server certificate contains Diffie-Hellman [DH1] parameters.
1439 Note: According to current US export law, RSA moduli
1440 larger than 512 bits may not be used for key
1441 exchange in software exported from the US. With
1442 this message, larger RSA keys may be used as
1443 signature-only certificates to sign temporary
1444 shorter RSA keys for key exchange.
1446 enum { rsa, diffie_hellman, fortezza_kea }
1447 KeyExchangeAlgorithm;
1450 Freier, Karlton, Kocher [Page 25]
1451 .
1453 INTERNET-DRAFT SSL 3.0 November 18, 1996
1455 struct {
1456 opaque rsa_modulus<1..2^16-1>;
1457 opaque rsa_exponent<1..2^16-1>;
1458 } ServerRSAParams;
1460 rsa_modulus The modulus of the server's temporary RSA key.
1461 rsa_exponent The public exponent of the server's temporary
1462 RSA key.
1464 struct {
1465 opaque dh_p<1..2^16-1>;
1466 opaque dh_g<1..2^16-1>;
1467 opaque dh_Ys<1..2^16-1>;
1468 } ServerDHParams; /* Ephemeral DH parameters */
1470 dh_p The prime modulus used for the Diffie-Hellman
1471 operation.
1472 dh_g The generator used for the Diffie-Hellman
1473 operation.
1474 dh_Ys The server's Diffie-Hellman public value
1475 (gX mod p).
1477 struct {
1478 opaque r_s [128];
1479 } ServerFortezzaParams;
1481 r_s Server random number for FORTEZZA KEA (Key
1482 Exchange Algorithm).
1484 struct {
1485 select (KeyExchangeAlgorithm) {
1486 case diffie_hellman:
1487 ServerDHParams params;
1488 Signature signed_params;
1489 case rsa:
1490 ServerRSAParams params;
1491 Signature signed_params;
1492 case fortezza_kea:
1493 ServerFortezzaParams params;
1494 };
1495 } ServerKeyExchange;
1497 params The server's key exchange parameters.
1498 signed_params A hash of the corresponding params value, with
1499 the signature appropriate to that hash applied.
1500 md5_hash MD5(ClientHello.random + ServerHello.random +
1501 ServerParams);
1502 sha_hash SHA(ClientHello.random + ServerHello.random +
1503 ServerParams);
1505 enum { anonymous, rsa, dsa } SignatureAlgorithm;
1508 Freier, Karlton, Kocher [Page 26]
1509 .
1511 INTERNET-DRAFT SSL 3.0 November 18, 1996
1513 digitally-signed struct {
1514 select(SignatureAlgorithm) {
1515 case anonymous: struct { };
1516 case rsa:
1517 opaque md5_hash[16];
1518 opaque sha_hash[20];
1519 case dsa:
1520 opaque sha_hash[20];
1521 };
1522 } Signature;
1525 5.6.4 Certificate request
1527 A non-anonymous server can optionally request a certificate from
1528 the client, if appropriate for the selected cipher suite.
1530 enum {
1531 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
1532 rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20),
1533 (255)
1534 } ClientCertificateType;
1536 opaque DistinguishedName<1..2^16-1>;
1538 struct {
1539 ClientCertificateType certificate_types<1..2^8-1>;
1540 DistinguishedName certificate_authorities<3..2^16-1>;
1541 } CertificateRequest;
1543 certificate_types This field is a list of the types of
1544 certificates requested, sorted in order of the
1545 server's preference.
1546 certificate_authorities
1547 A list of the distinguished names of acceptable
1548 certificate authorities.
1550 Note: DistinguishedName is derived from [X509].
1552 Note: It is a fatal handshake_failure alert for an
1553 anonymous server to request client identification.
1555 5.6.5 Server hello done
1557 The server hello done message is sent by the server to indicate the
1558 end of the server hello and associated messages. After sending
1559 this message the server will wait for a client response.
1561 struct { } ServerHelloDone;
1566 Freier, Karlton, Kocher [Page 27]
1567 .
1569 INTERNET-DRAFT SSL 3.0 November 18, 1996
1571 Upon receipt of the server hello done message the client should
1572 verify that the server provided a valid certificate if required and
1573 check that the server hello parameters are acceptable.
1575 5.6.6 Client certificate
1577 This is the first message the client can send after receiving a
1578 server hello done message. This message is only sent if the server
1579 requests a certificate. If no suitable certificate is available,
1580 the client should send a no_certificate alert instead. This alert
1581 is only a warning, however the server may respond with a fatal
1582 handshake failure alert if client authentication is required.
1583 Client certificates are sent using the Certificate defined in
1584 Section 5.6.2.
1586 Note: Client Diffie-Hellman certificates must match the
1587 server specified Diffie-Hellman parameters.
1589 5.6.7 Client key exchange message
1591 The choice of messages depends on which public key algorithm(s) has
1592 (have) been selected. See Section 5.6.3 for the
1593 KeyExchangeAlgorithm definition.
1595 struct {
1596 select (KeyExchangeAlgorithm) {
1597 case rsa: EncryptedPreMasterSecret;
1598 case diffie_hellman: ClientDiffieHellmanPublic;
1599 case fortezza_kea: FortezzaKeys;
1600 } exchange_keys;
1601 } ClientKeyExchange;
1603 The information to select the appropriate record structure is in
1604 the pending session state (see Section 5.1).
1606 5.6.7.1 RSA encrypted premaster secret message
1608 If RSA is being used for key agreement and authentication, the
1609 client generates a 48-byte pre-master secret, encrypts it under the
1610 public key from the server's certificate or temporary RSA key from
1611 a server key exchange message, and sends the result in an encrypted
1612 premaster secret message.
1614 struct {
1615 ProtocolVersion client_version;
1616 opaque random[46];
1617 } PreMasterSecret;
1619 client_version The latest (newest) version supported by the
1620 client. This is used to detect version
1621 roll-back attacks.
1622 random 46 securely-generated random bytes.
1624 Freier, Karlton, Kocher [Page 28]
1625 .
1627 INTERNET-DRAFT SSL 3.0 November 18, 1996
1629 struct {
1630 public-key-encrypted PreMasterSecret pre_master_secret;
1631 } EncryptedPreMasterSecret;
1633 pre_master_secret This random value is generated by the client
1634 and is used to generate the master secret, as
1635 specified in Section 6.1.
1637 5.6.7.2 FORTEZZA key exchange message
1639 Under FORTEZZA, the client derives a Token Encryption Key (TEK)
1640 using the FORTEZZA Key Exchange Algorithm (KEA). The client's KEA
1641 calculation uses the public key in the server's certificate along
1642 with private parameters in the client's token. The client sends
1643 public parameters needed for the server to generate the TEK, using
1644 its own private parameters. The client generates session keys,
1645 wraps them using the TEK, and sends the results to the server. The
1646 client generates IV's for the session keys and TEK and sends them
1647 also. The client generates a random 48-byte premaster secret,
1648 encrypts it using the TEK, and sends the result:
1650 struct {
1651 opaque y_c<0..128>;
1652 opaque r_c[128];
1653 opaque y_signature[40];
1654 opaque wrapped_client_write_key[12];
1655 opaque wrapped_server_write_key[12];
1656 opaque client_write_iv[24];
1657 opaque server_write_iv[24];
1658 opaque master_secret_iv[24];
1659 block-ciphered opaque encrypted_pre_master_secret[48];
1660 } FortezzaKeys;
1662 y_signature y_signature is the signature of the KEA public
1663 key, signed with the client's DSS private key.
1664 y_c The client's Yc value (public key) for the KEA
1665 calculation. If the client has sent a
1666 certificate, and its KEA public key is
1667 suitable, this value must be empty since the
1668 certificate already contains this value. If
1669 the client sent a certificate without a
1670 suitable public key, y_c is used and
1671 y_signature is the KEA public key signed with
1672 the client's DSS private key. For this value
1673 to be used, it must be between 64 and 128
1674 bytes.
1675 r_c The client's Rc value for the KEA calculation.
1676 wrapped_client_write_key
1677 This is the client's write key, wrapped by the
1678 TEK.
1682 Freier, Karlton, Kocher [Page 29]
1683 .
1685 INTERNET-DRAFT SSL 3.0 November 18, 1996
1687 wrapped_server_write_key
1688 This is the server's write key, wrapped by the
1689 TEK.
1690 client_write_iv The IV for the client write key.
1691 server_write_iv The IV for the server write key.
1692 master_secret_iv This is the IV for the TEK used to encrypt the
1693 pre-master secret.
1694 pre_master_secret A random value, generated by the client and
1695 used to generate the master secret, as
1696 specified in Section 6.1. In the the above
1697 structure, it is encrypted using the TEK.
1699 5.6.7.3 Client Diffie-Hellman public value
1701 This structure conveys the client's Diffie-Hellman public value
1702 (Yc) if it was not already included in the client's certificate.
1703 The encoding used for Yc is determined by the enumerated
1704 PublicValueEncoding.
1706 enum { implicit, explicit } PublicValueEncoding;
1708 implicit If the client certificate already contains the
1709 public value, then it is implicit and Yc does
1710 not need to be sent again.
1711 explicit Yc needs to be sent.
1713 struct {
1714 select (PublicValueEncoding) {
1715 case implicit: struct { };
1716 case explicit: opaque dh_Yc<1..2^16-1>;
1717 } dh_public;
1718 } ClientDiffieHellmanPublic;
1720 dh_Yc The client's Diffie-Hellman public value (Yc).
1722 5.6.8 Certificate verify
1724 This message is used to provide explicit verification of a client
1725 certificate. This message is only sent following any client
1726 certificate that has signing capability (i.e. all certificates
1727 except those containing fixed Diffie-Hellman parameters).
1729 struct {
1730 Signature signature;
1731 } CertificateVerify;
1733 CertificateVerify.signature.md5_hash
1734 MD5(master_secret + pad_2 +
1735 MD5(handshake_messages + master_secret + pad_1));
1736 Certificate.signature.sha_hash
1737 SHA(master_secret + pad_2 +
1738 SHA(handshake_messages + master_secret + pad_1));
1740 Freier, Karlton, Kocher [Page 30]
1741 .
1743 INTERNET-DRAFT SSL 3.0 November 18, 1996
1745 pad_1 This is identical to the pad_1 defined in
1746 section 5.2.3.1.
1747 pad_2 This is identical to the pad_2 defined in
1748 section 5.2.3.1.
1750 Here handshake_messages refers to all handshake messages starting
1751 at client hello up to but not including this message.
1753 5.6.9 Finished
1755 A finished message is always sent immediately after a change cipher
1756 specs message to verify that the key exchange and authentication
1757 processes were successful. The finished message is the first
1758 protected with the just-negotiated algorithms, keys, and secrets.
1759 No acknowledgment of the finished message is required; parties may
1760 begin sending encrypted data immediately after sending the finished
1761 message. Recipients of finished messages must verify that the
1762 contents are correct.
1764 enum { client(0x434C4E54), server(0x53525652) } Sender;
1766 struct {
1767 opaque md5_hash[16];
1768 opaque sha_hash[20];
1769 } Finished;
1771 md5_hash MD5(master_secret + pad2 +
1772 MD5(handshake_messages + Sender +
1773 master_secret + pad1));
1774 sha_hash SHA(master_secret + pad2 +
1775 SHA(handshake_messages + Sender +
1776 master_secret + pad1));
1778 handshake_messages All of the data from all handshake messages
1779 up to but not including this message. This
1780 is only data visible at the handshake layer
1781 and does not include record layer headers.
1783 It is a fatal error if a finished message is not preceeded by a
1784 change cipher spec message at the appropriate point in the
1785 handshake.
1787 The hash contained in finished messages sent by the server
1788 incorporate Sender.server; those sent by the client incorporate
1789 Sender.client. The value handshake_messages includes all handshake
1790 messages starting at client hello up to, but not including, this
1791 finished message. This may be different from handshake_messages in
1792 Section 5.6.8 because it would include the certificate verify
1793 message (if sent).
1798 Freier, Karlton, Kocher [Page 31]
1799 .
1801 INTERNET-DRAFT SSL 3.0 November 18, 1996
1803 Note: Change cipher spec messages are not handshake
1804 messages and are not included in the hash
1805 computations.
1807 5.7 Application data protocol
1809 Application data messages are carried by the Record Layer and are
1810 fragmented, compressed and encrypted based on the current
1811 connection state. The messages are treated as transparent data to
1812 the record layer.
1814 6. Cryptographic computations
1816 The key exchange, authentication, encryption, and MAC algorithms
1817 are determined by the cipher_suite selected by the server and
1818 revealed in the server hello message.
1820 6.1 Asymmetric cryptographic computations
1822 The asymmetric algorithms are used in the handshake protocol to
1823 authenticate parties and to generate shared keys and secrets.
1825 For Diffie-Hellman, RSA, and FORTEZZA, the same algorithm is used
1826 to convert the pre_master_secret into the master_secret. The
1827 pre_master_secret should be deleted from memory once the
1828 master_secret has been computed.
1830 master_secret =
1831 MD5(pre_master_secret + SHA('A' + pre_master_secret +
1832 ClientHello.random + ServerHello.random)) +
1833 MD5(pre_master_secret + SHA('BB' + pre_master_secret +
1834 ClientHello.random + ServerHello.random)) +
1835 MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
1836 ClientHello.random + ServerHello.random));
1838 6.1.1 RSA
1840 When RSA is used for server authentication and key exchange, a
1841 48-byte pre_master_secret is generated by the client, encrypted
1842 under the server's public key, and sent to the server. The server
1843 uses its private key to decrypt the pre_master_secret. Both
1844 parties then convert the pre_master_secret into the master_secret,
1845 as specified above.
1847 RSA digital signatures are performed using PKCS #1 [PKCS1] block
1848 type 1. RSA public key encryption is performed using PKCS #1 block
1849 type 2.
1856 Freier, Karlton, Kocher [Page 32]
1857 .
1859 INTERNET-DRAFT SSL 3.0 November 18, 1996
1861 6.1.2 Diffie-Hellman
1863 A conventional Diffie-Hellman computation is performed. The
1864 negotiated key (Z) is used as the pre_master_secret, and is
1865 converted into the master_secret, as specified above.
1867 Note: Diffie-Hellman parameters are specified by the
1868 server, and may be either ephemeral or contained
1869 within the server's certificate.
1871 6.1.3 FORTEZZA
1873 A random 48-byte pre_master_secret is sent encrypted under the TEK
1874 and its IV. The server decrypts the pre_master_secret and converts
1875 it into a master_secret, as specified above. Bulk cipher keys and
1876 IVs for encryption are generated by the client's token and
1877 exchanged in the key exchange message; the master_secret is only
1878 used for MAC computations.
1880 6.2 Symmetric cryptographic calculations and the CipherSpec
1882 The technique used to encrypt and verify the integrity of SSL
1883 records is specified by the currently active CipherSpec. A typical
1884 example would be to encrypt data using DES and generate
1885 authentication codes using MD5. The encryption and MAC algorithms
1886 are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL
1887 Handshake Protocol, indicating that no message authentication or
1888 encryption is performed. The handshake protocol is used to
1889 negotiate a more secure CipherSpec and to generate cryptographic
1890 keys.
1892 6.2.1 The master secret
1894 Before secure encryption or integrity verification can be performed
1895 on records, the client and server need to generate shared secret
1896 information known only to themselves. This value is a 48-byte
1897 quantity called the master secret. The master secret is used to
1898 generate keys and secrets for encryption and MAC computations.
1899 Some algorithms, such as FORTEZZA, may have their own procedure for
1900 generating encryption keys (the master secret is used only for MAC
1901 computations in FORTEZZA).
1903 6.2.2 Converting the master secret into keys and MAC secrets
1905 The master secret is hashed into a sequence of secure bytes, which
1906 are assigned to the MAC secrets, keys, and non-export IVs required
1907 by the current CipherSpec (see Appendix A.7). CipherSpecs require
1908 a client write MAC secret, a server write MAC secret, a client
1909 write key, a server write key, a client write IV, and a server
1910 write IV, which are generated from the master secret in that order.
1911 Unused values, such as FORTEZZA keys communicated in the
1914 Freier, Karlton, Kocher [Page 33]
1915 .
1917 INTERNET-DRAFT SSL 3.0 November 18, 1996
1919 KeyExchange message, are empty. The following inputs are available
1920 to the key definition process:
1922 opaque MasterSecret[48]
1923 ClientHello.random
1924 ServerHello.random
1926 When generating keys and MAC secrets, the master secret is used as
1927 an entropy source, and the random values provide unencrypted salt
1928 material and IVs for exportable ciphers.
1930 To generate the key material, compute
1932 key_block =
1933 MD5(master_secret + SHA(`A' + master_secret +
1934 ServerHello.random +
1935 ClientHello.random)) +
1936 MD5(master_secret + SHA(`BB' + master_secret +
1937 ServerHello.random +
1938 ClientHello.random)) +
1939 MD5(master_secret + SHA(`CCC' + master_secret +
1940 ServerHello.random +
1941 ClientHello.random)) + [...];
1943 until enough output has been generated. Then the key_block is
1944 partitioned as follows.
1946 client_write_MAC_secret[CipherSpec.hash_size]
1947 server_write_MAC_secret[CipherSpec.hash_size]
1948 client_write_key[CipherSpec.key_material]
1949 server_write_key[CipherSpec.key_material]
1950 client_write_IV[CipherSpec.IV_size] /* non-export ciphers */
1951 server_write_IV[CipherSpec.IV_size] /* non-export ciphers */
1953 Any extra key_block material is discarded.
1955 Exportable encryption algorithms (for which
1956 CipherSpec.is_exportable is true) require additional processing as
1957 follows to derive their final write keys:
1959 final_client_write_key = MD5(client_write_key +
1960 ClientHello.random +
1961 ServerHello.random);
1962 final_server_write_key = MD5(server_write_key +
1963 ServerHello.random +
1964 ClientHello.random);
1966 Exportable encryption algorithms derive their IVs from the random
1967 messages:
1969 client_write_IV = MD5(ClientHello.random + ServerHello.random);
1970 server_write_IV = MD5(ServerHello.random + ClientHello.random);
1972 Freier, Karlton, Kocher [Page 34]
1973 .
1975 INTERNET-DRAFT SSL 3.0 November 18, 1996
1977 MD5 outputs are trimmed to the appropriate size by discarding the
1978 least-significant bytes.
1980 6.2.2.1 Export key generation example
1982 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for
1983 each of the two encryption keys and 16 bytes for each of the MAC
1984 keys, for a total of 42 bytes of key material. MD5 produces 16
1985 bytes of output per call, so three calls to MD5 are required. The
1986 MD5 outputs are concatenated into a 48-byte key_block with the
1987 first MD5 call providing bytes zero through 15, the second
1988 providing bytes 16 through 31, etc. The key_block is partitioned,
1989 and the write keys are salted because this is an exportable
1990 encryption algorithm.
1992 client_write_MAC_secret = key_block[0..15]
1993 server_write_MAC_secret = key_block[16..31]
1994 client_write_key = key_block[32..36]
1995 server_write_key = key_block[37..41]
1996 final_client_write_key = MD5(client_write_key +
1997 ClientHello.random +
1998 ServerHello.random)[0..15];
1999 final_server_write_key = MD5(server_write_key +
2000 ServerHello.random +
2001 ClientHello.random)[0..15];
2002 client_write_IV = MD5(ClientHello.random +
2003 ServerHello.random)[0..7];
2004 server_write_IV = MD5(ServerHello.random +
2005 ClientHello.random)[0..7];
2030 Freier, Karlton, Kocher [Page 35]
2031 .
2033 INTERNET-DRAFT SSL 3.0 November 18, 1996
2035 Appendix A
2037 A. Protocol constant values
2039 This section describes protocol types and constants.
2041 A.1 Reserved port assignments
2043 At the present time SSL is implemented using TCP/IP as the base
2044 networking technology. The IANA reserved the following Internet
2045 Protocol [IP] port numbers for use in conjunction with SSL.
2047 443 Reserved for use by Hypertext Transfer Protocol with
2048 SSL (https).
2049 465 Reserved (pending) for use by Simple Mail Transfer Protocol
2050 with SSL (ssmtp).
2051 563 Reserved (pending) for use by Network News Transfer
2052 Protocol (snntp).
2054 A.1.1 Record layer
2056 struct {
2057 uint8 major, minor;
2058 } ProtocolVersion;
2060 ProtocolVersion version = { 3,0 };
2062 enum {
2063 change_cipher_spec(20), alert(21), handshake(22),
2064 application_data(23), (255)
2065 } ContentType;
2067 struct {
2068 ContentType type;
2069 ProtocolVersion version;
2070 uint16 length;
2071 opaque fragment[SSLPlaintext.length];
2072 } SSLPlaintext;
2074 struct {
2075 ContentType type;
2076 ProtocolVersion version;
2077 uint16 length;
2078 opaque fragment[SSLCompressed.length];
2079 } SSLCompressed;
2081 struct {
2082 ContentType type;
2083 ProtocolVersion version;
2084 uint16 length;
2085 select (CipherSpec.cipher_type) {
2086 case stream: GenericStreamCipher;
2088 Freier, Karlton, Kocher [Page 36]
2089 .
2091 INTERNET-DRAFT SSL 3.0 November 18, 1996
2093 case block: GenericBlockCipher;
2094 } fragment;
2095 } SSLCiphertext;
2097 stream-ciphered struct {
2098 opaque content[SSLCompressed.length];
2099 opaque MAC[CipherSpec.hash_size];
2100 } GenericStreamCipher;
2102 block-ciphered struct {
2103 opaque content[SSLCompressed.length];
2104 opaque MAC[CipherSpec.hash_size];
2105 uint8 padding[GenericBlockCipher.padding_length];
2106 uint8 padding_length;
2107 } GenericBlockCipher;
2109 A.2 Change cipher specs message
2111 struct {
2112 enum { change_cipher_spec(1), (255) } type;
2113 } ChangeCipherSpec;
2115 A.3 Alert messages
2117 enum { warning(1), fatal(2), (255) } AlertLevel;
2119 enum {
2120 close_notify(0),
2121 unexpected_message(10),
2122 bad_record_mac(20),
2123 decompression_failure(30),
2124 handshake_failure(40),
2125 no_certificate(41),
2126 bad_certificate(42),
2127 unsupported_certificate(43),
2128 certificate_revoked(44),
2129 certificate_expired(45),
2130 certificate_unknown(46),
2131 illegal_parameter (47),
2132 (255)
2133 } AlertDescription;
2135 struct {
2136 AlertLevel level;
2137 AlertDescription description;
2138 } Alert;
2140 A.4 Handshake protocol
2142 enum {
2143 hello_request(0), client_hello(1), server_hello(2),
2144 certificate(11), server_key_exchange (12),
2146 Freier, Karlton, Kocher [Page 37]
2147 .
2149 INTERNET-DRAFT SSL 3.0 November 18, 1996
2151 certificate_request(13), server_done(14),
2152 certificate_verify(15), client_key_exchange(16),
2153 finished(20), (255)
2154 } HandshakeType;
2156 struct {
2157 HandshakeType msg_type;
2158 uint24 length;
2159 select (HandshakeType) {
2160 case hello_request: HelloRequest;
2161 case client_hello: ClientHello;
2162 case server_hello: ServerHello;
2163 case certificate: Certificate;
2164 case server_key_exchange: ServerKeyExchange;
2165 case certificate_request: CertificateRequest;
2166 case server_done: ServerHelloDone;
2167 case certificate_verify: CertificateVerify;
2168 case client_key_exchange: ClientKeyExchange;
2169 case finished: Finished;
2170 } body;
2171 } Handshake;
2173 A.4.1 Hello messages
2175 struct { } HelloRequest;
2177 struct {
2178 uint32 gmt_unix_time;
2179 opaque random_bytes[28];
2180 } Random;
2182 opaque SessionID<0..32>;
2184 uint8 CipherSuite[2];
2186 enum { null(0), (255) } CompressionMethod;
2188 struct {
2189 ProtocolVersion client_version;
2190 Random random;
2191 SessionID session_id;
2192 CipherSuite cipher_suites<0..2^16-1>;
2193 CompressionMethod compression_methods<0..2^8-1>;
2194 } ClientHello;
2196 struct {
2197 ProtocolVersion server_version;
2198 Random random;
2199 SessionID session_id;
2200 CipherSuite cipher_suite;
2201 CompressionMethod compression_method;
2202 } ServerHello;
2204 Freier, Karlton, Kocher [Page 38]
2205 .
2207 INTERNET-DRAFT SSL 3.0 November 18, 1996
2209 A.4.2 Server authentication and key exchange messages
2211 opaque ASN.1Cert<2^24-1>;
2213 struct {
2214 ASN.1Cert certificate_list<1..2^24-1>;
2215 } Certificate;
2217 enum { rsa, diffie_hellman, fortezza_kea } KeyExchangeAlgorithm;
2219 struct {
2220 opaque RSA_modulus<1..2^16-1>;
2221 opaque RSA_exponent<1..2^16-1>;
2222 } ServerRSAParams;
2224 struct {
2225 opaque DH_p<1..2^16-1>;
2226 opaque DH_g<1..2^16-1>;
2227 opaque DH_Ys<1..2^16-1>;
2228 } ServerDHParams;
2230 struct {
2231 opaque r_s [128]
2232 } ServerFortezzaParams
2234 struct {
2235 select (KeyExchangeAlgorithm) {
2236 case diffie_hellman:
2237 ServerDHParams params;
2238 Signature signed_params;
2239 case rsa:
2240 ServerRSAParams params;
2241 Signature signed_params;
2242 case fortezza_kea:
2243 ServerFortezzaParams params;
2244 };
2245 } ServerKeyExchange;
2247 enum { anonymous, rsa, dsa } SignatureAlgorithm;
2249 digitally-signed struct {
2250 select(SignatureAlgorithm) {
2251 case anonymous: struct { };
2252 case rsa:
2253 opaque md5_hash[16];
2254 opaque sha_hash[20];
2255 case dsa:
2256 opaque sha_hash[20];
2257 };
2258 } Signature;
2262 Freier, Karlton, Kocher [Page 39]
2263 .
2265 INTERNET-DRAFT SSL 3.0 November 18, 1996
2267 enum {
2268 RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3),
2269 DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6),
2270 FORTEZZA_MISSI(20), (255)
2271 } CertificateType;
2273 opaque DistinguishedName<1..2^16-1>;
2275 struct {
2276 CertificateType certificate_types<1..2^8-1>;
2277 DistinguishedName certificate_authorities<3..2^16-1>;
2278 } CertificateRequest;
2280 struct { } ServerHelloDone;
2282 A.5 Client authentication and key exchange messages
2284 struct {
2285 select (KeyExchangeAlgorithm) {
2286 case rsa: EncryptedPreMasterSecret;
2287 case diffie_hellman: DiffieHellmanClientPublicValue;
2288 case fortezza_kea: FortezzaKeys;
2289 } exchange_keys;
2290 } ClientKeyExchange;
2292 struct {
2293 ProtocolVersion client_version;
2294 opaque random[46];
2295 } PreMasterSecret;
2297 struct {
2298 public-key-encrypted PreMasterSecret pre_master_secret;
2299 } EncryptedPreMasterSecret;
2301 struct {
2302 opaque y_c<0..128>;
2303 opaque r_c[128];
2304 opaque y_signature[40];
2305 opaque wrapped_client_write_key[12];
2306 opaque wrapped_server_write_key[12];
2307 opaque client_write_iv[24];
2308 opaque server_write_iv[24];
2309 opaque master_secret_iv[24];
2310 opaque encrypted_preMasterSecret[48];
2311 } FortezzaKeys;
2313 enum { implicit, explicit } PublicValueEncoding;
2315 struct {
2316 select (PublicValueEncoding) {
2317 case implicit: struct {};
2318 case explicit: opaque DH_Yc<1..2^16-1>;
2320 Freier, Karlton, Kocher [Page 40]
2321 .
2323 INTERNET-DRAFT SSL 3.0 November 18, 1996
2325 } dh_public;
2326 } ClientDiffieHellmanPublic;
2328 struct {
2329 Signature signature;
2330 } CertificateVerify;
2332 A.5.1 Handshake finalization message
2334 struct {
2335 opaque md5_hash[16];
2336 opaque sha_hash[20];
2337 } Finished;
2339 A.6 The CipherSuite
2341 The following values define the CipherSuite codes used in the
2342 client hello and server hello messages.
2344 A CipherSuite defines a cipher specifications supported in SSL
2345 Version 3.0.
2347 CipherSuite SSL_NULL_WITH_NULL_NULL = { 0x00,0x00 };
2349 The following CipherSuite definitions require that the server
2350 provide an RSA certificate that can be used for key exchange. The
2351 server may request either an RSA or a DSS signature-capable
2352 certificate in the certificate request message.
2354 CipherSuite SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
2355 CipherSuite SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 };
2356 CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
2357 CipherSuite SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
2358 CipherSuite SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
2359 CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
2360 CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
2361 CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
2362 CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
2363 CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
2365 The following CipherSuite definitions are used for
2366 server-authenticated (and optionally client-authenticated)
2367 Diffie-Hellman. DH denotes cipher suites in which the server's
2368 certificate contains the Diffie-Hellman parameters signed by the
2369 certificate authority (CA). DHE denotes ephemeral Diffie-Hellman,
2370 where the Diffie-Hellman parameters are signed by a DSS or RSA
2371 certificate, which has been signed by the CA. The signing
2372 algorithm used is specified after the DH or DHE parameter. In all
2373 cases, the client must have the same type of certificate, and must
2374 use the Diffie-Hellman parameters chosen by the server.
2378 Freier, Karlton, Kocher [Page 41]
2379 .
2381 INTERNET-DRAFT SSL 3.0 November 18, 1996
2383 CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
2384 CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
2385 CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
2386 CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
2387 CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
2388 CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
2389 CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
2390 CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
2391 CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
2392 CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
2393 CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
2394 CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
2396 The following cipher suites are used for completely anonymous
2397 Diffie-Hellman communications in which neither party is
2398 authenticated. Note that this mode is vulnerable to
2399 man-in-the-middle attacks and is therefore strongly discouraged.
2401 CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
2402 CipherSuite SSL_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
2403 CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
2404 CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
2405 CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
2407 The final cipher suites are for the FORTEZZA token.
2409 CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA = { 0X00,0X1C };
2410 CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00,0x1D };
2411 CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA = { 0x00,0x1E };
2413 Note: All cipher suites whose first byte is 0xFF are
2414 considered private and can be used for defining
2415 local/experimental algorithms. Interoperability of
2416 such types is a local matter.
2418 Note: Additional cipher suites will be considered for
2419 implementation only with submission of notarized
2420 letters from two independent entities. Netscape
2421 Communications Corp. will act as an interim
2422 registration office, until a public standards body
2423 assumes control of SSL.
2425 A.7 The CipherSpec
2427 A cipher suite identifies a CipherSpec. These structures are part
2428 of the SSL session state. The CipherSpec includes:
2430 enum { stream, block } CipherType;
2432 enum { true, false } IsExportable;
2436 Freier, Karlton, Kocher [Page 42]
2437 .
2439 INTERNET-DRAFT SSL 3.0 November 18, 1996
2441 enum { null, rc4, rc2, des, 3des, des40, fortezza }
2442 BulkCipherAlgorithm;
2444 enum { null, md5, sha } MACAlgorithm;
2446 struct {
2447 BulkCipherAlgorithm bulk_cipher_algorithm;
2448 MACAlgorithm mac_algorithm;
2449 CipherType cipher_type;
2450 IsExportable is_exportable
2451 uint8 hash_size;
2452 uint8 key_material;
2453 uint8 IV_size;
2454 } CipherSpec;
2494 Freier, Karlton, Kocher [Page 43]
2495 .
2497 INTERNET-DRAFT SSL 3.0 November 18, 1996
2499 Appendix B
2501 B. Glossary
2502 application protocol An application protocol is a protocol that
2503 normally layers directly on top of the
2504 transport layer (e.g., TCP/IP). Examples
2505 include HTTP, TELNET, FTP, and SMTP.
2506 asymmetric cipher See public key cryptography.
2507 authentication Authentication is the ability of one entity
2508 to determine the identity of another entity.
2509 block cipher A block cipher is an algorithm that operates
2510 on plaintext in groups of bits, called
2511 blocks. 64 bits is a typical block size.
2512 bulk cipher A symmetric encryption algorithm used to
2513 encrypt large quantities of data.
2514 cipher block chaining
2515 Mode (CBC) CBC is a mode in which every
2516 plaintext block encrypted with the block
2517 cipher is first exclusive-ORed with the
2518 previous ciphertext block (or, in the case
2519 of the first block, with the initialization
2520 vector).
2521 certificate As part of the X.509 protocol (a.k.a. ISO
2522 Authentication framework), certificates are
2523 assigned by a trusted Certificate Authority
2524 and provide verification of a party's
2525 identity and may also supply its public key.
2526 client The application entity that initiates a
2527 connection to a server.
2528 client write key The key used to encrypt data written by the
2529 client.
2530 client write MAC secret
2531 The secret data used to authenticate data
2532 written by the client.
2533 connection A connection is a transport (in the OSI
2534 layering model definition) that provides a
2535 suitable type of service. For SSL, such
2536 connections are peer to peer relationships.
2537 The connections are transient. Every
2538 connection is associated with one session.
2539 Data Encryption Standard
2540 (DES) DES is a very widely used symmetric
2541 encryption algorithm. DES is a block
2542 cipher.
2543 Digital Signature Standard
2544 (DSS) A standard for digital signing,
2545 including the Digital Signing Algorithm,
2546 approved by the National Institute of
2547 Standards and Technology, defined in NIST
2548 FIPS PUB 186, "Digital Signature Standard,"
2549 published May, 1994 by the U.S. Dept. of
2550 Commerce.
2552 Freier, Karlton, Kocher [Page 44]
2553 .
2555 INTERNET-DRAFT SSL 3.0 November 18, 1996
2557 digital signatures Digital signatures utilize public key
2558 cryptography and one-way hash functions to
2559 produce a signature of the data that can be
2560 authenticated, and is difficult to forge or
2561 repudiate.
2562 FORTEZZA A PCMCIA card that provides both encryption
2563 and digital signing.
2564 handshake An initial negotiation between client and
2565 server that establishes the parameters of
2566 their transactions.
2567 Initialization Vector
2568 (IV) When a block cipher is used in CBC
2569 mode, the initialization vector is
2570 exclusive-ORed with the first plaintext
2571 block prior to encryption.
2572 IDEA A 64-bit block cipher designed by Xuejia Lai
2573 and James Massey.
2574 Message Authentication Code
2575 (MAC) A Message Authentication Code is a
2576 one-way hash computed from a message and
2577 some secret data. Its purpose is to detect
2578 if the message has been altered.
2579 master secret Secure secret data used for generating
2580 encryption keys, MAC secrets, and IVs.
2581 MD5 MD5 [7] is a secure hashing function that
2582 converts an arbitrarily long data stream
2583 into a digest of fixed size.
2584 public key cryptography
2585 A class of cryptographic techniques
2586 employing two-key ciphers. Messages
2587 encrypted with the public key can only be
2588 decrypted with the associated private key.
2589 Conversely, messages signed with the private
2590 key can be verified with the public key.
2591 one-way hash function
2592 A one-way transformation that converts an
2593 arbitrary amount of data into a fixed-length
2594 hash. It is computation- ally hard to
2595 reverse the transformation or to find
2596 collisions. MD5 and SHA are examples of
2597 one-way hash functions.
2598 RC2, RC4 Proprietary bulk ciphers from RSA Data
2599 Security, Inc. (There is no good reference
2600 to these as they are unpublished works;
2601 however, see [RSADSI]). RC2 is block cipher
2602 and RC4 is a stream cipher.
2603 RSA A very widely used public-key algorithm that
2604 can be used for either encryption or digital
2605 signing.
2606 salt Non-secret random data used to make export
2607 encryption keys resist precomputation
2608 attacks.
2610 Freier, Karlton, Kocher [Page 45]
2611 .
2613 INTERNET-DRAFT SSL 3.0 November 18, 1996
2615 server The server is the application entity that
2616 responds to requests for connections from
2617 clients. The server is passive, waiting for
2618 requests from clients.
2619 session A SSL session is an association between a
2620 client and a server. Sessions are created
2621 by the handshake protocol. Sessions define
2622 a set of cryptographic security parameters,
2623 which can be shared among multiple
2624 connections. Sessions are used to avoid the
2625 expensive negotiation of new security
2626 parameters for each connection.
2627 session identifier A session identifier is a value generated by
2628 a server that identifies a particular
2629 session.
2630 server write key The key used to encrypt data written by the
2631 server.
2632 server write MAC secret
2633 The secret data used to authenticate data
2634 written by the server.
2635 SHA The Secure Hash Algorithm is defined in FIPS
2636 PUB 180-1. It produces a 20-byte output
2637 [SHA].
2638 stream cipher An encryption algorithm that converts a key
2639 into a cryptographically-strong keystream,
2640 which is then exclusive-ORed with the
2641 plaintext.
2642 symmetric cipher See bulk cipher.
2668 Freier, Karlton, Kocher [Page 46]
2669 .
2671 INTERNET-DRAFT SSL 3.0 November 18, 1996
2673 Appendix C
2675 C. CipherSuite definitions
2677 CipherSuite Is Key Cipher Hash
2678 Exportable Exchange
2680 SSL_NULL_WITH_NULL_NULL * NULL NULL NULL
2681 SSL_RSA_WITH_NULL_MD5 * RSA NULL MD5
2682 SSL_RSA_WITH_NULL_SHA * RSA NULL SHA
2683 SSL_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5
2684 SSL_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
2685 SSL_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
2686 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5
2687 SSL_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
2688 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA
2689 SSL_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
2690 SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
2691 SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA
2692 SSL_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
2693 SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
2694 SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA
2695 SSL_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
2696 SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
2697 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA
2698 SSL_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
2699 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
2700 SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA
2701 SSL_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
2702 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
2703 SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5
2704 SSL_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
2705 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA
2706 SSL_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA
2707 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
2708 SSL_FORTEZZA_KEA_WITH_NULL_SHA FORTEZZA_KEA NULL SHA
2709 SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA FORTEZZA_KEA FORTEZZA_CBC SHA
2710 SSL_FORTEZZA_KEA_WITH_RC4_128_SHA FORTEZZA_KEA RC4_128 SHA
2712 * Indicates IsExportable is True
2714 Key Description Key size limit
2715 Exchange
2716 Algorithm
2717 DHE_DSS Ephemeral DH with DSS signatures None
2718 DHE_DSS_EXPORT Ephemeral DH with DSS signatures DH = 512 bits
2719 DHE_RSA Ephemeral DH with RSA signatures None
2720 DHE_RSA_EXPORT Ephemeral DH with RSA signatures DH = 512 bits,
2721 RSA = none
2722 DH_anon Anonymous DH, no signatures None
2723 DH_anon_EXPORT Anonymous DH, no signatures DH = 512 bits
2724 DH_DSS DH with DSS-based certificates None
2726 Freier, Karlton, Kocher [Page 47]
2727 .
2729 INTERNET-DRAFT SSL 3.0 November 18, 1996
2731 DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits
2732 DH_RSA DH with RSA-based certificates None
2733 DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits,
2734 RSA = none
2735 FORTEZZA_KEA FORTEZZA KEA. Details unpublished N/A
2736 NULL No key exchange N/A
2737 RSA RSA key exchange None
2738 RSA_EXPORT RSA key exchange RSA = 512 bits
2740 Key size limit The key size limit gives the size of the
2741 largest public key that can be legally
2742 used for encryption in cipher suites that
2743 are exportable.
2745 Cipher Cipher IsExpo Key Exp. Effect IV Block
2746 Type rtable Material Key Mat ive Key Size Size
2747 erial Bits
2749 NULL Stream * 0 0 0 0 N/A
2750 FORTEZZA_CBC Block NA(**) 12(**) 96(**) 20(**) 8
2751 IDEA_CBC Block 16 16 128 8 8
2752 RC2_CBC_40 Block * 5 16 40 8 8
2753 RC4_40 Stream * 5 16 40 0 N/A
2754 RC4_128 Stream 16 16 128 0 N/A
2755 DES40_CBC Block * 5 8 40 8 8
2756 DES_CBC Block 8 8 56 8 8
2757 3DES_EDE_CBC Block 24 24 168 8 8
2759 * Indicates IsExportable is true.
2760 ** FORTEZZA uses its own key and IV generation algorithms.
2762 Key Material The number of bytes from the key_block that are
2763 used for generating the write keys.
2764 Expanded Key Material
2765 The number of bytes actually fed into the
2766 encryption algorithm.
2767 Effective Key Bits
2768 How much entropy material is in the key
2769 material being fed into the encryption
2770 routines.
2772 Hash Hash Size Padding
2773 function Size
2774 NULL 0 0
2775 MD5 16 48
2776 SHA 20 40
2784 Freier, Karlton, Kocher [Page 48]
2785 .
2787 INTERNET-DRAFT SSL 3.0 November 18, 1996
2789 Appendix D
2791 D. Implementation Notes
2793 The SSL protocol cannot prevent many common security mistakes.
2794 This section provides several recommendations to assist
2795 implementers.
2798 D.1 Temporary RSA keys
2800 US Export restrictions limit RSA keys used for encryption to 512
2801 bits, but do not place any limit on lengths of RSA keys used for
2802 signing operations. Certificates often need to be larger than 512
2803 bits, since 512-bit RSA keys are not secure enough for high-value
2804 transactions or for applications requiring long-term security.
2805 Some certificates are also designated signing-only, in which case
2806 they cannot be used for key exchange.
2808 When the public key in the certificate cannot be used for
2809 encryption, the server signs a temporary RSA key, which is then
2810 exchanged. In exportable applications, the temporary RSA key
2811 should be the maximum allowable length (i.e., 512 bits). Because
2812 512-bit RSA keys are relatively insecure, they should be changed
2813 often. For typical electronic commerce applications, it is
2814 suggested that keys be changed daily or every 500 transactions, and
2815 more often if possible. Note that while it is acceptable to use
2816 the same temporary key for multiple transactions, it must be signed
2817 each time it is used.
2819 RSA key generation is a time-consuming process. In many cases, a
2820 low-priority process can be assigned the task of key generation.
2821 Whenever a new key is completed, the existing temporary key can be
2822 replaced with the new one.
2824 D.2 Random Number Generation and Seeding
2826 SSL requires a cryptographically-secure pseudorandom number
2827 generator (PRNG). Care must be taken in designing and seeding
2828 PRNGs. PRNGs based on secure hash operations, most notably MD5
2829 and/or SHA, are acceptable, but cannot provide more security than
2830 the size of the random number generator state. (For example,
2831 MD5-based PRNGs usually provide 128 bits of state.)
2833 To estimate the amount of seed material being produced, add the
2834 number of bits of unpredictable information in each seed byte. For
2835 example, keystroke timing values taken from a PC- compatible's 18.2
2836 Hz timer provide 1 or 2 secure bits each, even though the total
2837 size of the counter value is 16 bits or more. To seed a 128-bit
2838 PRNG, one would thus require approximately 100 such timer values.
2842 Freier, Karlton, Kocher [Page 49]
2843 .
2845 INTERNET-DRAFT SSL 3.0 November 18, 1996
2847 Note: The seeding functions in RSAREF and versions of
2848 BSAFE prior to 3.0 are order-independent. For
2849 example, if 1000 seed bits are supplied, one at a
2850 time, in 1000 separate calls to the seed function,
2851 the PRNG will end up in a state which depends only
2852 on the number of 0 or 1 seed bits in the seed data
2853 (i.e., there are 1001 possible final states).
2854 Applications using BSAFE or RSAREF must take extra
2855 care to ensure proper seeding.
2857 D.3 Certificates and authentication
2859 Implementations are responsible for verifying the integrity of
2860 certificates and should generally support certificate revocation
2861 messages. Certificates should always be verified to ensure proper
2862 signing by a trusted Certificate Authority (CA). The selection and
2863 addition of trusted CAs should be done very carefully. Users
2864 should be able to view information about the certificate and root
2865 CA.
2867 D.4 CipherSuites
2869 SSL supports a range of key sizes and security levels, including
2870 some which provide no or minimal security. A proper implementation
2871 will probably not support many cipher suites. For example, 40-bit
2872 encryption is easily broken, so implementations requiring strong
2873 security should not allow 40-bit keys. Similarly, anonymous
2874 Diffie-Hellman is strongly discouraged because it cannot prevent
2875 man-in-the- middle attacks. Applications should also enforce
2876 minimum and maximum key sizes. For example, certificate chains
2877 containing 512-bit RSA keys or signatures are not appropriate for
2878 high-security applications.
2880 D.5 FORTEZZA
2882 This section describes implementation details for ciphersuites that
2883 make use of the FORTEZZA hardware encryption system.
2885 D.5.1 Notes on use of FORTEZZA hardware
2887 A complete explanation of all issues regarding the use of FORTEZZA
2888 hardware is outside the scope of this document. However, there are
2889 a few special requirements of SSL that deserve mention.
2891 Because SSL is a full duplex protocol, two crypto states must be
2892 maintained, one for reading and one for writing. There are also a
2893 number of circumstances which can result in the crypto state in the
2894 FORTEZZA card being lost. For these reasons, it's recommended that
2895 the current crypto state be saved after processing a record, and
2896 loaded before processing the next.
2900 Freier, Karlton, Kocher [Page 50]
2901 .
2903 INTERNET-DRAFT SSL 3.0 November 18, 1996
2905 After the client generates the TEK, it also generates two MEKs,
2906 for one for reading and one for writing. After generating each of
2907 these keys, the client must generate a corresponding IV and then
2908 save the crypto state. The client also uses the TEK to generate an
2909 IV and encrypt the premaster secret. All three IVs are sent to the
2910 server, along with the wrapped keys and the encrypted premaster
2911 secret in the client key exchange message. At this point, the TEK
2912 is no longer needed, and may be discarded.
2914 On the server side, the server uses the master IV and the TEK to
2915 decrypt the premaster secret. It also loads the wrapped MEKs into
2916 the card. The server loads both IVs to verify that the IVs match
2917 the keys. However, since the card is unable to encrypt after
2918 loading an IV, the server must generate a new IV for the server
2919 write key. This IV is discarded.
2921 When encrypting the first encrypted record (and only that record),
2922 the server adds 8 bytes of random data to the beginning of the
2923 fragment. These 8 bytes are discarded by the client after
2924 decryption. The purpose of this is to synchronize the state on the
2925 client and server resulting from the different IVs.
2927 D.5.2 FORTEZZA Ciphersuites
2929 5) FORTEZZA_NULL_WITH_NULL_SHA:
2930 Uses the full FORTEZZA key exchange, including sending server and
2931 client write keys and iv's.
2933 D.5.3 FORTEZZA Session resumption
2935 There are two possibilities for FORTEZZA session restart:
2936 1) Never restart a FORTEZZA session.
2937 2) Restart a session with the previously negotiated keys and iv's.
2939 Never restarting a FORTEZZA session:
2941 Clients who never restart FORTEZZA sessions should never send
2942 Session ID's which were previously used in a FORTEZZA session as
2943 part of the ClientHello. Servers who never restart FORTEZZA
2944 sessions should never send a previous session id on the
2945 ServerHello if the negotiated session is FORTEZZA.
2947 Restart a session:
2949 You cannot restart FORTEZZA on a session which has never done a
2950 complete FORTEZZA key exchange (That is you cannot restart FORTEZZA
2951 if the session was an RSA/RC4 session renegotiated for FORTEZZA).
2952 If you wish to restart a FORTEZZA session, you must save the MEKs
2953 and IVs from the initial key exchange for this session and reuse
2954 them for any new connections on that session. This is not
2955 recommended, but it is possible.
2958 Freier, Karlton, Kocher [Page 51]
2959 .
2961 INTERNET-DRAFT SSL 3.0 November 18, 1996
2963 Appendix E
2965 E. Version 2.0 Backward Compatibility
2967 Version 3.0 clients that support Version 2.0 servers must send
2968 Version 2.0 client hello messages [SSL-2]. Version 3.0 servers
2969 should accept either client hello format. The only deviations from
2970 the Version 2.0 specification are the ability to specify a version
2971 with a value of three and the support for more ciphering types in
2972 the CipherSpec.
2974 Warning: The ability to send Version 2.0 client hello
2975 messages will be phased out with all due haste.
2976 Implementers should make every effort to move
2977 forward as quickly as possible. Version 3.0
2978 provides better mechanisms for transitioning to
2979 newer versions.
2981 The following cipher specifications are carryovers from SSL Version
2982 2.0. These are assumed to use RSA for key exchange and
2983 authentication.
2985 V2CipherSpec SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
2986 V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
2987 V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
2988 V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
2989 = { 0x04,0x00,0x80 };
2990 V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
2991 V2CipherSpec SSL_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
2992 V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
2994 Cipher specifications introduced in Version 3.0 can be included in
2995 Version 2.0 client hello messages using the syntax below. Any
2996 V2CipherSpec element with its first byte equal to zero will be
2997 ignored by Version 2.0 servers. Clients sending any of the above
2998 V2CipherSpecs should also include the Version 3.0 equivalent (see
2999 Appendix A.6):
3001 V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite };
3003 E.1 Version 2 client hello
3005 The Version 2.0 client hello message is presented below using this
3006 document's presentation model. The true definition is still
3007 assumed to be the SSL Version 2.0 specification.
3009 uint8 V2CipherSpec[3];
3011 struct {
3012 unit8 msg_type;
3013 Version version;
3014 uint16 cipher_spec_length;
3016 Freier, Karlton, Kocher [Page 52]
3017 .
3019 INTERNET-DRAFT SSL 3.0 November 18, 1996
3021 uint16 session_id_length;
3022 uint16 challenge_length;
3023 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
3024 opaque session_id[V2ClientHello.session_id_length];
3025 Random challenge;
3026 } V2ClientHello;
3028 msg_type This field, in conjunction with the version
3029 field, identifies a version 2 client hello
3030 message. The value should equal one (1).
3031 version The highest version of the protocol supported
3032 by the client (equals ProtocolVersion.version,
3033 see Appendix A.1.1).
3034 cipher_spec_length
3035 This field is the total length of the field
3036 cipher_specs. It cannot be zero and must be a
3037 multiple of the V2CipherSpec length (3).
3038 session_id_length This field must have a value of either zero or
3039 16. If zero, the client is creating a new
3040 session. If 16, the session_id field will
3041 contain the 16 bytes of session identification.
3042 challenge_length The length in bytes of the client's challenge
3043 to the server to authenticate itself. This
3044 value must be 32.
3045 cipher_specs This is a list of all CipherSpecs the client is
3046 willing and able to use. There must be at
3047 least one CipherSpec acceptable to the server.
3048 session_id If this field's length is not zero, it will
3049 contain the identification for a session that
3050 the client wishes to resume.
3051 challenge The client's challenge to the server for the
3052 server to identify itself is a (nearly)
3053 arbitrary length random. The Version 3.0
3054 server will right justify the challenge data to
3055 become the ClientHello.random data (padded with
3056 leading zeroes, if necessary), as specified in
3057 this Version 3.0 protocol. If the length of
3058 the challenge is greater than 32 bytes, then
3059 only the last 32 bytes are used. It is
3060 legitimate (but not necessary) for a V3 server
3061 to reject a V2 ClientHello that has fewer than
3062 16 bytes of challenge data.
3064 Note: Requests to resume an SSL 3.0 session should use an
3065 SSL 3.0 client hello.
3067 E.2 Avoiding man-in-the-middle version rollback
3069 When SSL Version 3.0 clients fall back to Version 2.0 compatibility
3070 mode, they use special PKCS #1 block formatting. This is done so
3071 that Version 3.0 servers will reject Version 2.0 sessions with
3072 Version 3.0-capable clients.
3074 Freier, Karlton, Kocher [Page 53]
3075 .
3077 INTERNET-DRAFT SSL 3.0 November 18, 1996
3080 When Version 3.0 clients are in Version 2.0 compatibility mode,
3081 they set the right-hand (least-significant) 8 random bytes of the
3082 PKCS padding (not including the terminal null of the padding) for
3083 the RSA encryption of the ENCRYPTED-KEY- DATA field of the
3084 CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random).
3085 After decrypting the ENCRYPTED- KEY-DATA field, servers that
3086 support SSL 3.0 should issue an error if these eight padding bytes
3087 are 0x03. Version 2.0 servers receiving blocks padded in this
3088 manner will proceed normally.
3132 Freier, Karlton, Kocher [Page 54]
3133 .
3135 INTERNET-DRAFT SSL 3.0 November 18, 1996
3137 Appendix F
3139 F. Security analysis
3141 The SSL protocol is designed to establish a secure connection
3142 between a client and a server communicating over an insecure
3143 channel. This document makes several traditional assumptions,
3144 including that attackers have substantial computational resources
3145 and cannot obtain secret information from sources outside the
3146 protocol. Attackers are assumed to have the ability to capture,
3147 modify, delete, replay, and otherwise tamper with messages sent
3148 over the communication channel. This appendix outlines how SSL has
3149 been designed to resist a variety of attacks.
3151 F.1 Handshake protocol
3153 The handshake protocol is responsible for selecting a CipherSpec
3154 and generating a MasterSecret, which together comprise the primary
3155 cryptographic parameters associated with a secure session. The
3156 handshake protocol can also optionally authenticate parties who
3157 have certificates signed by a trusted certificate authority.
3159 F.1.1 Authentication and key exchange
3161 SSL supports three authentication modes: authentication of both
3162 parties, server authentication with an unauthenticated client, and
3163 total anonymity. Whenever the server is authenticated, the channel
3164 should be secure against man-in- the-middle attacks, but completely
3165 anonymous sessions are inherently vulnerable to such attacks.
3166 Anonymous servers cannot authenticate clients, since the client
3167 signature in the certificate verify message may require a server
3168 certificate to bind the signature to a particular server. If the
3169 server is authenticated, its certificate message must provide a
3170 valid certificate chain leading to an acceptable certificate
3171 authority. Similarly, authenticated clients must supply an
3172 acceptable certificate to the server. Each party is responsible
3173 for verifying that the other's certificate is valid and has not
3174 expired or been revoked.
3176 The general goal of the key exchange process is to create a
3177 pre_master_secret known to the communicating parties and not to
3178 attackers. The pre_master_secret will be used to generate the
3179 master_secret (see Section 6.1). The master_secret is required to
3180 generate the finished messages, encryption keys, and MAC secrets
3181 (see Sections 5.6.9 and 6.2.2). By sending a correct finished
3182 message, parties thus prove that they know the correct
3183 pre_master_secret.
3185 F.1.1.1 Anonymous key exchange
3187 Completely anonymous sessions can be established using RSA,
3188 Diffie-Hellman, or FORTEZZA for key exchange. With anonymous RSA,
3190 Freier, Karlton, Kocher [Page 55]
3191 .
3193 INTERNET-DRAFT SSL 3.0 November 18, 1996
3195 the client encrypts a pre_master_secret with the server's
3196 uncertified public key extracted from the server key exchange
3197 message. The result is sent in a client key exchange message.
3198 Since eavesdroppers do not know the server's private key, it will
3199 be infeasible for them to decode the pre_master_secret.
3201 With Diffie-Hellman or FORTEZZA, the server's public parameters are
3202 contained in the server key exchange message and the client's are
3203 sent in the client key exchange message. Eavesdroppers who do not
3204 know the private values should not be able to find the
3205 Diffie-Hellman result (i.e. the pre_master_secret) or the FORTEZZA
3206 token encryption key (TEK).
3208 Warning: Completely anonymous connections only provide
3209 protection against passive eavesdropping. Unless an
3210 independent tamper-proof channel is used to verify
3211 that the finished messages were not replaced by an
3212 attacker, server authentication is required in
3213 environments where active man-in-the-middle attacks
3214 are a concern.
3216 F.1.1.2 RSA key exchange and authentication
3218 With RSA, key exchange and server authentication are combined. The
3219 public key may be either contained in the server's certificate or
3220 may be a temporary RSA key sent in a server key exchange message.
3221 When temporary RSA keys are used, they are signed by the server's
3222 RSA or DSS certificate. The signature includes the current
3223 ClientHello.random, so old signatures and temporary keys cannot be
3224 replayed. Servers may use a single temporary RSA key for multiple
3225 negotiation sessions.
3227 Note: The temporary RSA key option is useful if servers
3228 need large certificates but must comply with
3229 government-imposed size limits on keys used for key
3230 exchange.
3232 After verifying the server's certificate, the client encrypts a
3233 pre_master_secret with the server's public key. By successfully
3234 decoding the pre_master_secret and producing a correct finished
3235 message, the server demonstrates that it knows the private key
3236 corresponding to the server certificate.
3238 When RSA is used for key exchange, clients are authenticated using
3239 the certificate verify message (see Section 5.6.8). The client
3240 signs a value derived from the master_secret and all preceding
3241 handshake messages. These handshake messages include the server
3242 certificate, which binds the signature to the server, and
3243 ServerHello.random, which binds the signature to the current
3244 handshake process.
3248 Freier, Karlton, Kocher [Page 56]
3249 .
3251 INTERNET-DRAFT SSL 3.0 November 18, 1996
3253 F.1.1.3 Diffie-Hellman key exchange with authentication
3255 When Diffie-Hellman key exchange is used, the server can either
3256 supply a certificate containing fixed Diffie-Hellman parameters or
3257 can use the server key exchange message to send a set of temporary
3258 Diffie-Hellman parameters signed with a DSS or RSA certificate.
3259 Temporary parameters are hashed with the hello.random values before
3260 signing to ensure that attackers do not replay old parameters. In
3261 either case, the client can verify the certificate or signature to
3262 ensure that the parameters belong to the server.
3264 If the client has a certificate containing fixed Diffie- Hellman
3265 parameters, its certificate contains the information required to
3266 complete the key exchange. Note that in this case the client and
3267 server will generate the same Diffie- Hellman result (i.e.,
3268 pre_master_secret) every time they communicate. To prevent the
3269 pre_master_secret from staying in memory any longer than necessary,
3270 it should be converted into the master_secret as soon as possible.
3271 Client Diffie- Hellman parameters must be compatible with those
3272 supplied by the server for the key exchange to work.
3274 If the client has a standard DSS or RSA certificate or is
3275 unauthenticated, it sends a set of temporary parameters to the
3276 server in the client key exchange message, then optionally uses a
3277 certificate verify message to authenticate itself.
3279 F.1.1.4 FORTEZZA
3281 FORTEZZA's design is classified, but at the protocol level it is
3282 similar to Diffie-Hellman with fixed public values contained in
3283 certificates. The result of the key exchange process is the token
3284 encryption key (TEK), which is used to wrap data encryption keys,
3285 client write key, server write key, and master secret encryption
3286 key. The data encryption keys are not derived from the
3287 pre_master_secret because unwrapped keys are not accessible outside
3288 the token. The encrypted pre_master_secret is sent to the server
3289 in a client key exchange message.
3291 F.1.2 Version rollback attacks
3293 Because SSL Version 3.0 includes substantial improvements over SSL
3294 Version 2.0, attackers may try to make Version 3.0- capable clients
3295 and servers fall back to Version 2.0. This attack is occurring if
3296 (and only if) two Version 3.0-capable parties use an SSL 2.0
3297 handshake.
3299 Although the solution using non-random PKCS #1 block type 2 message
3300 padding is inelegant, it provides a reasonably secure way for
3301 Version 3.0 servers to detect the attack. This solution is not
3302 secure against attackers who can brute force the key and substitute
3303 a new ENCRYPTED-KEY-DATA message containing the same key (but with
3304 normal padding) before the application specified wait threshold has
3306 Freier, Karlton, Kocher [Page 57]
3307 .
3309 INTERNET-DRAFT SSL 3.0 November 18, 1996
3311 expired. Parties concerned about attacks of this scale should not
3312 be using 40-bit encryption keys anyway. Altering the padding of
3313 the least-significant 8 bytes of the PKCS padding does not impact
3314 security, since this is essentially equivalent to increasing the
3315 input block size by 8 bytes.
3317 F.1.3 Detecting attacks against the handshake protocol
3319 An attacker might try to influence the handshake exchange to make
3320 the parties select different encryption algorithms than they would
3321 normally choose. Because many implementations will support 40-bit
3322 exportable encryption and some may even support null encryption or
3323 MAC algorithms, this attack is of particular concern.
3325 For this attack, an attacker must actively change one or more
3326 handshake messages. If this occurs, the client and server will
3327 compute different values for the handshake message hashes. As a
3328 result, the parties will not accept each others' finished messages.
3329 Without the master_secret, the attacker cannot repair the finished
3330 messages, so the attack will be discovered.
3332 F.1.4 Resuming sessions
3334 When a connection is established by resuming a session, new
3335 ClientHello.random and ServerHello.random values are hashed with
3336 the session's master_secret. Provided that the master_secret has
3337 not been compromised and that the secure hash operations used to
3338 produce the encryption keys and MAC secrets are secure, the
3339 connection should be secure and effectively independent from
3340 previous connections. Attackers cannot use known encryption keys
3341 or MAC secrets to compromise the master_secret without breaking the
3342 secure hash operations (which use both SHA and MD5).
3344 Sessions cannot be resumed unless both the client and server agree.
3345 If either party suspects that the session may have been
3346 compromised, or that certificates may have expired or been revoked,
3347 it should force a full handshake. An upper limit of 24 hours is
3348 suggested for session ID lifetimes, since an attacker who obtains a
3349 master_secret may be able to impersonate the compromised party
3350 until the corresponding session ID is retired. Applications that
3351 may be run in relatively insecure environments should not write
3352 session IDs to stable storage.
3354 F.1.5 MD5 and SHA
3356 SSL uses hash functions very conservatively. Where possible, both
3357 MD5 and SHA are used in tandem to ensure that non- catastrophic
3358 flaws in one algorithm will not break the overall protocol.
3364 Freier, Karlton, Kocher [Page 58]
3365 .
3367 INTERNET-DRAFT SSL 3.0 November 18, 1996
3369 F.2 Protecting application data
3371 The master_secret is hashed with the ClientHello.random and
3372 ServerHello.random to produce unique data encryption keys and MAC
3373 secrets for each connection. FORTEZZA encryption keys are
3374 generated by the token, and are not derived from the master_secret.
3376 Outgoing data is protected with a MAC before transmission. To
3377 prevent message replay or modification attacks, the MAC is computed
3378 from the MAC secret, the sequence number, the message length, the
3379 message contents, and two fixed character strings. The message
3380 type field is necessary to ensure that messages intended for one
3381 SSL Record Layer client are not redirected to another. The
3382 sequence number ensures that attempts to delete or reorder messages
3383 will be detected. Since sequence numbers are 64-bits long, they
3384 should never overflow. Messages from one party cannot be inserted
3385 into the other's output, since they use independent MAC secrets.
3386 Similarly, the server-write and client-write keys are independent
3387 so stream cipher keys are used only once.
3389 If an attacker does break an encryption key, all messages encrypted
3390 with it can be read. Similarly, compromise of a MAC key can make
3391 message modification attacks possible. Because MACs are also
3392 encrypted, message-alteration attacks generally require breaking
3393 the encryption algorithm as well as the MAC.
3395 Note: MAC secrets may be larger than encryption keys, so
3396 messages can remain tamper resistant even if
3397 encryption keys are broken.
3399 F.3 Final notes
3401 For SSL to be able to provide a secure connection, both the client
3402 and server systems, keys, and applications must be secure. In
3403 addition, the implementation must be free of security errors.
3405 The system is only as strong as the weakest key exchange and
3406 authentication algorithm supported, and only trustworthy
3407 cryptographic functions should be used. Short public keys, 40-bit
3408 bulk encryption keys, and anonymous servers should be used with
3409 great caution. Implementations and users must be careful when
3410 deciding which certificates and certificate authorities are
3411 acceptable; a dishonest certificate authority can do tremendous
3412 damage.
3422 Freier, Karlton, Kocher [Page 59]
3423 .
3425 INTERNET-DRAFT SSL 3.0 November 18, 1996
3427 Appendix G
3429 G. Patent Statement
3431 This version of the SSL protocol relies on the use of patented
3432 public key encryption technology for authentication and encryption.
3433 The Internet Standards Process as defined in RFC 1310 requires a
3434 written statement from the Patent holder that a license will be
3435 made available to applicants under reasonable terms and conditions
3436 prior to approving a specification as a Proposed, Draft or Internet
3437 Standard. The Massachusetts Institute of Technology has granted
3438 RSA Data Security, Inc., exclusive sub-licensing rights to the
3439 following patent issued in the United States:
3441 Cryptographic Communications System and Method ("RSA"),
3442 No. 4,405,829
3444 The Board of Trustees of the Leland Stanford Junior University have
3445 granted Caro-Kann Corporation, a wholly owned subsidiary
3446 corporation, exclusive sub-licensing rights to the following
3447 patents issued in the United States, and all of their corresponding
3448 foreign patents:
3450 Cryptographic Apparatus and Method ("Diffie-Hellman"),
3451 No. 4,200,770
3453 Public Key Cryptographic Apparatus and Method ("Hellman-
3454 Merkle"), No. 4,218,582
3456 The Internet Society, Internet Architecture Board, Internet
3457 Engineering Steering Group and the Corporation for National
3458 Research Initiatives take no position on the validity or scope of
3459 the patents and patent applications, nor on the appropriateness of
3460 the terms of the assurance. The Internet Society and other groups
3461 mentioned above have not made any determination as to any other
3462 intellectual property rights which may apply to the practice of
3463 this standard. Any further consideration of these matters is the
3464 user's own responsibility.
3480 Freier, Karlton, Kocher [Page 60]
3481 .
3483 INTERNET-DRAFT SSL 3.0 November 18, 1996
3485 References
3487 [DH1] W. Diffie and M. E. Hellman, "New Directions in
3488 Cryptography," IEEE Transactions on Information Theory, V.
3489 IT-22, n. 6, Jun 1977, pp. 74-84.
3491 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions
3492 To DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
3494 [DES] ANSI X3.106, "American National Standard for
3495 Information Systems-Data Link Encryption," American National
3496 Standards Institute, 1983.
3498 [DSS] NIST FIPS PUB 186, "Digital Signature Standard,"
3499 National Institute of Standards and Technology, U.S.
3500 Department of Commerce, 18 May 1994.
3502 [FOR] NSA X22, Document # PD4002103-1.01, "FORTEZZA:
3503 Application Implementers Guide," April 6, 1995.
3505 [FTP] J. Postel and J. Reynolds, RFC 959: File Transfer
3506 Protocol, October 1985.
3508 [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext
3509 Transfer Protocol -- HTTP/1.0, October, 1995.
3511 [IDEA] X. Lai, "On the Design and Security of Block
3512 Ciphers," ETH Series in Information Processing, v. 1,
3513 Konstanz: Hartung-Gorre Verlag, 1992.
3515 [KRAW] H. Krawczyk, IETF Draft: Keyed-MD5 for Message
3516 Authentication, November 1995.
3518 [MD2] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm.
3519 April 1992.
3521 [MD5] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm.
3522 April 1992.
3524 [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption
3525 Standard," version 1.5, November 1993.
3527 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate
3528 Syntax Standard," version 1.5, November 1993.
3530 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic
3531 Message Syntax Standard," version 1.5, November 1993.
3533 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
3534 Obtaining Digital Signatures and Public-Key Cryptosystems,"
3535 Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-
3536 126.
3538 Freier, Karlton, Kocher [Page 61]
3539 .
3541 INTERNET-DRAFT SSL 3.0 November 18, 1996
3543 [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782
3544 [SCH] B. Schneier. Applied Cryptography: Protocols,
3545 Algorithms, and Source Code in C, Published by John Wiley &
3546 Sons, Inc. 1994.
3548 [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National
3549 Institute of Standards and Technology, U.S. Department of
3550 Commerce, DRAFT, 31 May 1994.
3551 [TCP] ISI for DARPA, RFC 793: Transport Control Protocol,
3552 September 1981.
3554 [TEL] J. Postel and J. Reynolds, RFC 854/5, May, 1993.
3555 [X509] CCITT. Recommendation X.509: "The Directory -
3556 Authentication Framework". 1988.
3558 [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR:
3559 External Data Representation Standard, August 1995.
3596 Freier, Karlton, Kocher [Page 62]
3597 .
3599 INTERNET-DRAFT SSL 3.0 November 18, 1996
3601 Authors
3603 Alan O. Freier Paul C. Kocher
3604 Netscape Communications Independent Consultant
3605 freier@netscape.com pck@netcom.com
3607 Philip L. Karlton
3608 Netscape Communications
3609 karlton@netscape.com
3611 Other contributors
3613 Martin Abadi Robert Relyea
3614 Digital Equipment Corporation Netscape Communications
3615 ma@pa.dec.com relyea@netscape.com
3617 Taher Elgamal Jim Roskind
3618 Netscape Communications Netscape Communications
3619 elgamal@netscape.com jar@netscape.com
3621 Anil Gangolli Micheal J. Sabin, Ph. D.
3622 Netscape Communications Consulting Engineer
3623 gangolli@netscape.com msabin@netcom.com
3625 Kipp E.B. Hickman Tom Weinstein
3626 Netscape Communications Netscape Communications
3627 kipp@netscape.com tomw@netscape.com
3629 Early reviewers
3631 Robert Baldwin Clyde Monma
3632 RSA Data Security, Inc. Bellcore
3633 baldwin@rsa.com clyde@bellcore.com
3635 George Cox Eric Murray
3636 Intel Corporation ericm@lne.com
3637 cox@ibeam.jf.intel.com
3639 Cheri Dowell Avi Rubin
3640 Sun Microsystems Bellcore
3641 cheri@eng.sun.com rubin@bellcore.com
3643 Stuart Haber Don Stephenson
3644 Bellcore Sun Microsystems
3645 stuart@bellcore.com don.stephenson@eng.sun.com
3647 Burt Kaliski Joe Tardo
3648 RSA Data Security, Inc. General Magic
3649 burt@rsa.com tardo@genmagic.com
3654 Freier, Karlton, Kocher [Page 63]
3655 .
3657 INTERNET-DRAFT SSL 3.0 November 18, 1996
3659 Send all written communication about this document to:
3660 Netscape Communications
3661 466 Ellis Street
3662 Mountain View, CA 94043-4042
3663 Attn: Alan Freier
3712 Freier, Karlton, Kocher [Page 63]
3713 .