[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

                                   Netscape Communications Corporation

     Internet Draft                       December 1995 (Expires 6/96)

                               Alan O. Freier, Netscape Communications
                               Philip Karlton, Netscape Communications
                                Paul C. Kocher, Independent Consultant





                            SSL Version 3.0
                                12/5/95


     Abstract

         This  document  specifies Version 3.0 of the Secure  Sockets
         Layer (SSL V3.0) protocol, a security protocol that provides
         privacy over the Internet. The protocol allows client/server
         applications   to  communicate  in  a  way   that   prevents
         eavesdropping, tampering, or message forgery.



     Table of Contents


     1.      Status of this memo                                       3
     2.      Abstract                                                  3
     3.      Introduction                                              3
     4.      Presentation language                                     4
     4.1     Basic block size                                          4
     4.2     Miscellaneous                                             4
     4.3     Vectors                                                   4
     4.4     Numbers                                                   5
     4.5     Enumerateds                                               5
     4.6     Constructed types                                         6
     4.6.1   Variants                                                  7
     4.7     Cryptographic attributes                                  8
     4.8     Constants                                                 8
     5.      SSL protocol                                              8
     5.1     Session and connection states                             8
     5.2     Record layer                                             10
     5.2.1   Fragmentation                                            10
     5.2.2   Record compression and decompression                     11
     5.2.3   Record payload protection and the CipherSpec             12
     5.2.3.1 Null or standard stream cipher                           12
     5.2.3.2 CBC block cipher                                         13
     5.3     Change cipher spec protocol                              14

Freier, Karlton, Kocher                                        [ Page 1]
     5.4     Alert protocol                                           14
     5.4.1   Closure alerts                                           15
     5.4.2   Error alerts                                             15
     5.5     Handshake protocol overview                              16
     5.6     Handshake protocol                                       17
     5.6.1   Hello messages                                           18
     5.6.1.1 Hello request                                            18
     5.6.1.2 Client hello                                             19
     5.6.1.3 Server hello                                             21
     5.6.2   Server certificate                                       22
     5.6.3   Server key exchange message                              22
     5.6.4   Certificate request                                      24
     5.6.5   Server hello done                                        24
     5.6.6   Client certificate                                       25
     5.6.7   Client key exchange message                              25
     5.6.7.1 RSA encrypted premaster secret message                   25
     5.6.7.2 Fortezza key exchange message                            26
     5.6.7.3 Client Diffie-Hellman public value                       27
     5.6.8   Certificate verify                                       28
     5.6.9   Finished                                                 28
     5.7     Application data protocol                                29
     6.      Cryptographic computations                               29
     6.1     Asymmetric cryptographic computations                    29
     6.1.1   RSA                                                      29
     6.1.2   Diffie-Hellman                                           30
     6.1.3   Fortezza                                                 30
     6.2     Symmetric cryptographic calculations and the CipherSpec  30
     6.2.1   The master secret                                        30
     6.2.2   Converting master secret into keys and MAC secrets       30
     6.2.2.1 Export key generation example                            32
     A.      Protocol constant values                                 33
     A.1     Reserved port assignments                                33
     A.1.1   Record layer                                             33
     A.2     Change cipher specs message                              34
     A.3     Alert messages                                           34
     A.4     Handshake protocol                                       34
     A.4.1   Hello messages                                           35
     A.4.2   Server authentication and key exchange messages          35
     A.5     Client authentication and key exchange messages          37
     A.5.1   Handshake finalization message                           37
     A.6     The CipherSuite                                          38
     A.7     The CipherSpec                                           39
     B.      Glossary                                                 40
     C.      Version 2.0 Backward Compatibility                       41
     C.1     Version 2 client hello                                   42
     D.      Security analysis                                        44
     D.1     Handshake protocol                                       44
     D.1.1   Authentication and key exchange                          44
     D.1.1.1 Anonymous key exchange                                   45
     D.1.1.2 RSA key exchange and authentication                      45
     D.1.1.3 Diffie-Hellman key exchange with authentication          46
     D.1.1.4 Fortezza                                                 46
     D.1.2   Version rollback attacks                                 47
     D.1.3   Detecting attacks against the handshake protocol         47
     D.1.4   Resuming sessions                                        47
     D.1.5   MD5 and SHA                                              48
     D.2     Protecting application data                              48
     D.3     Final notes                                              49
     E.      Patent Statement                                         49

Freier, Karlton, Kocher                                       [ Page 2 ]
SSL 3.0                                                    December 1995


     1.   Status of this memo

     This  document  is  an  Internet-Draft. Internet-Drafts  are
     working  documents  of the Internet Engineering  Task  Force
     (IETF),  its areas, and its working groups. Note that  other
     groups  may  also distribute working documents as  Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a  maximum  of
     six months and may be updated, replaced, or made obsolete by
     other  documents  at  any time. It is inappropriate  to  use
     Internet-Drafts as reference material or to cite them  other
     than as work in progress.

     To  learn  the current status of any Internet-Draft,  please
     check   the  1id-abstracts.txt  listing  contained  in   the
     Internet  Drafts  Shadow Directories on ds.internic.net  (US
     East  Coast), nic.nordu.net (Europe), ftp.isi.edu  (US  West
     Coast), or munnari.oz.au (Pacific Rim).

     2.   Abstract

     This  document  specifies Version 3.0 of the Secure  Sockets
     Layer (SSL V3.0) protocol, a security protocol that provides
     privacy over the Internet. The protocol allows client/server
     applications   to  communicate  in  a  way   that   prevents
     eavesdropping, tampering, or message forgery.

     3.   Introduction

     The  goal  of  the  SSL Protocol is to provide  privacy  and
     reliability  between  two  communicating  applications.  The
     protocol  is  composed of two layers. At the  lowest  level,
     layered  on  top of some reliable transport protocol  (e.g.,
     TCP[TCP]),  is  the  SSL  Record Protocol.  The  SSL  Record
     Protocol  is used for encapsulation of various higher  level
     protocols. One such encapsulated protocol, the SSL Handshake
     Protocol, allows the server and client to authenticate  each
     other   and   to  negotiate  an  encryption  algorithm   and
     cryptographic keys before the application protocol transmits
     or  receives its first byte of data. The advantage of SSL is
     that  it is application protocol independent. A higher level
     protocol can layer on top of the SSL Protocol transparently.
     The SSL protocol provides connection security that has three
     basic properties:
     o The connection is private. Encryption  is  used  after  an
       initial  handshake  to  define  a  secret  key.  Symmetric
       cryptography is used for data encryption (e.g.,  DES[DES],
       RC4[RC4], etc.)
     o The  connection can be authenticated using  asymmetric, or
       public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.).
     o The connection is reliable. Message  transport  includes a
       message integrity check  using  a  keyed  MAC. Secure hash

Freier, Karlton, Kocher                                       [ Page 3 ]
SSL 3.0                                                    December 1995

       functions  (e.g.,  SHA,  MD5,  etc.)  are  used  for   MAC
       computations.

     4.   Presentation language

     This  document  deals  with the formatting  of  data  in  an
     external  representation.  The  following  very  basic   and
     somewhat casually defined presentation syntax will be  used.
     The  syntax  draws  from several sources in  its  structure.
     Although  it resembles the programming language 'C'  in  its
     syntax and XDR [XDR] in both its syntax and intent, it would
     be  risky  to draw too many parallels. The purpose  of  this
     presentation language is to document SSL only, not  to  have
     general application beyond that particular goal.

     4.1  Basic block size

     The   representation  of  all  data  items   is   explicitly
     specified.  The basic data block size is one  byte  (i.e.  8
     bits).  Multiple byte data items are concatenations  of  the
     bytes,  from  left  to right, from top to bottom.  From  the
     bytestream  a multi-byte item (a numeric in the example)  is
     formed (using C notation) by:

       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ...
       | byte[n-1];

     This  byte ordering for multi-byte values is the commonplace
     network byte order or big endian format.

     4.2  Miscellaneous

     Comments begin with /* and end with */.
     Optional  components  are  denoted  by  enclosing  them   in
     (italicized) [ ] brackets.

     Single  byte entities containing uninterpreted data  are  of
     type opaque.

     4.3  Vectors

     A   vector  (single  dimensioned  array)  is  a  stream   of
     homogeneous  data elements. The size of the  vector  may  be
     specified  at  documentation time or left unspecified  until
     runtime.  In either case the length declares the  number  of
     bytes, not the number of elements, in the vector.

     The  syntax  for specifying a new type T' that  is  a  fixed
     length vector of type T is

       T T'[n];

     Here  T' occupies  n bytes in the data  stream, where n is a
     multiple of the size of T. The length of the vector  is  not

Freier, Karlton, Kocher                                       [ Page 4 ]
SSL 3.0                                                    December 1995

     included in the encoded stream.

     In  the  following  example, Datum is defined  to  be  three
     consecutive  bytes  that the protocol  does  not  interpret,
     while Data is three consecutive Datum, consuming a total  of
     nine bytes.

       opaque Datum[3];      /* three uninterpreted bytes*/
       Datum Data[9];        /* 3 consecutive 3 byte vectors */

     Variable length vectors are defined by specifying a subrange
     of   legal   lengths,   inclusively,  using   the   notation
     <floor..ceiling>. When encoded, the actual  length  precedes
     the vector's contents in the byte stream. The length will be
     in  the form of a number consuming as many bytes as required
     to  hold the vector's specified maximum (ceiling) length.  A
     variable length vector with an actual length field  of  zero
     is referred to as an empty vector.

       T T'<floor..ceiling>;

     In  the  following example, mandatory is a vector that  must
     contain between 300 and 400 elements of type opaque. It  can
     never  be empty. The actual length field consumes two bytes,
     a uint16, sufficient to represent the value 400 (see Section
     4.4).  On  the other hand, longer can represent  up  to  800
     bytes  of data, or 400 uint16 elements, and it may be empty.
     Its  encoding  will include a two byte actual  length  field
     prepended to the vector.

       opaque mandatory<300..400>;   /* length field is 2 bytes,
                                         cannot be empty */
       uint16 longer<0..800>;        /* zero to 400 16-bit
                                        unsigned integers */

     4.4  Numbers

     The basic numeric data type is an unsigned byte (uint8). All
     larger  numeric  data  types are formed  from  fixed  length
     vectors  concatenated as described in Section  4.1  and  are
     also unsigned. The following numeric types are predefined.

       uint8 uint16[2];
       uint8 uint24[3];
       uint8 uint32[4];
       uint8 uint64[8];

     4.5  Enumerateds

     An  additional sparse data type is available called enum.  A
     field  of  type enum can only assume the values declared  in
     the  definition. Each definition is a different  type.  Only
     enumerateds  of the same type may be assigned  or  compared.
     Every element of an enumerated must be assigned a value,  as

Freier, Karlton, Kocher                                       [ Page 5 ]
SSL 3.0                                                    December 1995

     demonstrated in the following example. Since the elements of
     the  enumerated  are not ordered, they can be  assigned  any
     unique value, in any order.

       enum { e1(v1), e2(v2), ... , en(vn), [(n)] } Te;

     Enumerateds occupy as much space in the byte stream as would
     its  maximal defined ordinal value. The following definition
     would  cause  one byte to be used to carry  fields  of  type
     Color.

       enum { red(3), blue(5), white(7) } Color;

     One  may  optionally specify a value without its  associated
     tag  to  force  the  width  definition  without  defining  a
     superfluous  element. In the following example,  Taste  will
     consume two bytes in the data stream but can only assume the
     values 1, 2 or 4.

       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

     The  names  of  the  elements of an enumeration  are  scoped
     within  the  defined  type. In the example  above,  a  fully
     qualified reference to the second element of the enumeration
     would  be Color.blue. Such qualification is not required  if
     the target of the assignment is well specified.

       Color color = Color.blue;   /*overspecified, but legal*
       Color color = blue;         /*correct, type is implicit*/

     For   enumerateds  that  are  never  converted  to  external
     representation, the numerical information may be omitted.

       enum { low, medium, high } Amount;

     4.6  Constructed types

     Structure types may be constructed from primitive types  for
     convenience. Each specification declares a new, unique type.
     The syntax for definition is much like that of C.

       struct {
         T1 f1;
         T2 f2;
         ...
         Tn f3;
       } [T];

     The  fields  within a structure may be qualified  using  the
     type's  name  using  a syntax much like that  available  for
     enumerateds. For example, T.f2 refers to the second field of
     the  previous  declaration.  Structure  definitions  may  be
     embedded.


Freier, Karlton, Kocher                                       [ Page 6 ]
SSL 3.0                                                    December 1995

     4.6.1     Variants

     Defined structures may have variants based on some knowledge
     that  is available within the environment. The selector must
     be an enumerated type that defines the possible variants the
     structure  defines.  There must be  a  case  arm  for  every
     element of the enumeration declared in the select. The  body
     of the variant structure may be given a label for reference.
     The mechanism by which the variant is selected at runtime is
     not prescribed by the presentation language.

       struct {
         T1 f1;
         T2 f2;
             ....
         Tn fn;

         select (E) {
             case e1: Te1;
             case e2: Te2;
                 ....
             case en: Ten;
         } [fv];
       } [Tv];

     For example

       enum { apple, orange } VariantTag;

       struct {
         uint16 number;
         opaque string<0..10>;          /* variable length */
       } V1;

       struct {
         uint32 number;
         opaque string[10];             /* fixed length */
       } V2;

       struct {
         select (VariantTag) {
             case apple: V1;
             case orange: V2;
         } variant_body;
       } VariantRecord;

     Variant structures may be qualified (narrowed) by specifying
     a value for the selector prior to the type. For example, a

       orange VariantRecord

     is   a  narrowed  type  of  a  VariantRecord  containing   a
     variant_body of type V2.


Freier, Karlton, Kocher                                       [ Page 7 ]
SSL 3.0                                                    December 1995

     4.7  Cryptographic attributes

     The  four  cryptographic operations digital signing,  stream
     cipher  encryption, block cipher encryption, and public  key
     encryption are designated digitally-signed, stream-ciphered,
     block-ciphered,  and public-key-encrypted,  respectively.  A
     field's  cryptographic processing is specified by prepending
     an  appropriate key word designation before the field's type
     specification. Cryptographic keys are implied by the current
     session state (see Section 5.1).

     In the following example:
       stream-ciphered struct {
         uint8 field1;
         uint8 field2;
         digitally-signed opaque field3[20];
       } UserType;

     The contents of field3 are signed, then the entire structure
     is encrypted with a stream cipher.

     4.8  Constants

     Typed constants can be defined for purposes of specification
     by  declaring  a  symbol of the desired type  and  assigning
     values to it. Under-specified types (opaque, variable length
     vectors,  and  structures  that contain  opaque)  cannot  be
     assigned  values. No fields of a multi-element structure  or
     vector may be elided.

     For example,

       struct {
         uint8 f1;
         uint8 f2;
       } Example1;

       Example1 ex1 = {1, 4};          /*assigns f1 = 1, f2 = 4*/

     5.   SSL protocol

     SSL  is  a  layered  protocol. At each layer,  messages  may
     include  fields  for length, description, and  content.  SSL
     takes  messages to be transmitted, fragments the  data  into
     manageable blocks, optionally compresses the data, applies a
     MAC,  encrypts, and transmits the result. Received  data  is
     decrypted,  verified,  decompressed, and  reassembled,  then
     delivered to higher level clients.

     5.1  Session and connection states

     An  SSL session is stateful. It is the responsibility of the
     SSL  Handshake  protocol to coordinate  the  states  of  the
     client  and  server,  thereby allowing  the  protocol  state

Freier, Karlton, Kocher                                       [ Page 8 ]
SSL 3.0                                                    December 1995

     machines  of each to operate consistently, despite the  fact
     that  the state is not exactly parallel. Logically the state
     is  represented twice, once as the current operating  state,
     and  (during  the handshake protocol) again as  the  pending
     state.  When  the  handshake negotiation  is  complete,  the
     client and server exchange change cipher spec messages  (see
     Section 5.3). At that time, the pending state is copied into
     the  operating state. State information used only during the
     handshake protocol is not listed.

     An  SSL session may include multiple secure connections;  in
     addition, parties may have multiple simultaneous sessions.

     The session state includes the following elements:

       session identifier
                         An arbitrary byte sequence chosen by the
                         server to identify an active or resumable
                         session state.

       peer certificate  X509.v3[X509] certificate of  the  peer.
                         This element of the state may be null.

       compression method
                         The  algorithm  used  to  compress  data
                         prior to encryption.

       cipher spec       Specifies   the   bulk  data  encryption
                         algorithm (such as null, DES, etc.)  and
                         a MAC algorithm (such as MD5 or SHA). It
                         also  defines  cryptographic  attributes
                         such as the hash_size.

       master secret     48-byte secret shared between the client
                         and server.

       is resumable      A flag  indicating whether  the  session
                         can be used to initiate new connections.

     The connection state includes the following elements:

       server and client random
                        Byte sequences that  are  chosen  by  the
                        server and  client  for  each connection.

       server write MAC secret
                         The   secret  used   in   MAC operations
                         on  data  written   by   the server.

       client write MAC secret
                         The   secret  used   in   MAC operations
                         on  data  written   by   the client.

       server write key  The bulk  cipher key for data  encrypted

Freier, Karlton, Kocher                                       [ Page 9 ]
SSL 3.0                                                    December 1995

                         by  the  server  and  decrypted  by  the
                         client.

       client write key  The bulk  cipher key for data  encrypted
                         by  the  client  and  decrypted  by  the
                         server.

       initialization vectors
                         When a block cipher in CBC mode is used,
                         an   initialization   vector   (IV)   is
                         maintained for each key. This  field  is
                         first  initialized by the SSL  handshake
                         protocol.    Thereafter    the     final
                         ciphertext  block from  each  record  is
                         preserved  for  use with  the  following
                         record.

       sequence numbers  Each party  maintains separate  sequence
                         numbers  for  transmitted  and  received
                         messages  for  each connection.  When  a
                         party  sends or receives a change cipher
                         specs  message, the appropriate sequence
                         number  is set to zero. Sequence numbers
                         are  of  type uint64 and may not  exceed
                         2^64-1.

     5.2  Record layer

     The  SSL  Record  Layer  receives  uninterpreted  data  from
     clients in non-empty blocks of arbitrary size.

     5.2.1     Fragmentation

     The  record  layer fragments client blocks into SSLPlaintext
     records of 2^14 bytes or less. Client message boundaries  are
     not  preserved  in the record layer (i.e.,  multiple  client
     messages  of  the same ContentType may be coalesced  into  a
     single SSLPlaintext record).

       struct {
         uint8 major, minor;
       } ProtocolVersion;

       enum {
         change_cipher_spec(20), alert(21), handshake(22),
         application_data(23), (255)
       } ContentType;

       struct {
         ContentType type;
         ProtocolVersion version;
         uint16 length;
         opaque fragment[SSLPlaintext.length];
       } SSLPlaintext;

Freier, Karlton, Kocher                                      [ Page 10 ]
SSL 3.0                                                    December 1995


       type              The  higher  level  protocol   used   to
                         process the enclosed fragment.

       version           The version of protocol being  employed.
                         This document describes SSL Version  3.0
                         (See Appendix A.1.1).

       length            The length  (in bytes) of the  following
                         SSLPlaintext.fragment. The length should
                         not exceed 2^14.

       fragment          The  application  data.  This  data   is
                         transparent    and   treated    as    an
                         independent  block to be dealt  with  by
                         the  higher level protocol specified  by
                         the type field.

     Note:          Data  of  different SSL Record layer  content
                    types may be interleaved. Application data is
                    generally    of    lower    precedence    for
                    transmission than other content types.

     5.2.2     Record compression and decompression

     All  records are compressed using the compression  algorithm
     defined  in  the current session state. There is  always  an
     active  compression  algorithm,  however  initially  it   is
     defined as CompressionMethod.null. The compression algorithm
     translates  an  SSLPlaintext structure into an SSLCompressed
     structure.   Compression   functions   erase   their   state
     information whenever the CipherSpec is replaced.

     Note:          The  CipherSpec is part of the session  state
                    described  in  Section  5.1.  References   to
                    fields  of the CipherSpec are made throughout
                    this  document using presentation  syntax.  A
                    more  complete description of the  CipherSpec
                    is shown in Appendix A.7.

     Compression  must  be  lossless and  may  not  increase  the
     content length by more than 1024 bytes. If the decompression
     function  encounters  an SSLCompressed.fragment  that  would
     decompress  to  a length in excess of 2^14 bytes, it  should
     issue a fatal decompression_failure alert (Section 5.4.2).

       struct {
         ContentType type;
         ProtocolVersion version;
         uint16 length;
         opaque fragment[SSLCompressed.length];
       } SSLCompressed;

       length           The  length  (in bytes) of the  following

Freier, Karlton, Kocher                                      [ Page 11 ]
SSL 3.0                                                    December 1995

                        SSLCompressed.fragment.    The     length
                        should not exceed 2^14 + 1024.
       fragment         The        compressed       form       of
                        SSLPlaintext.fragment.

     Note:          A   CompressionMethod.null  operation  is  an
                    identity operation; no fields are altered.

     Implementation note:        Decompression   functions    are
                    responsible for ensuring that messages cannot
                    cause internal buffer overflows.

     5.2.3     Record payload protection and the CipherSpec

     All  records  are  protected using the  encryption  and  MAC
     algorithms  defined  in  the current  CipherSpec.  There  is
     always  an  active  CipherSpec,  however  initially  it   is
     SSL_NULL_WITH_NULL, which does not provide any security.

     Once  the handshake is complete, the two parties have shared
     secrets, which are used to encrypt records and compute keyed
     message  authenticity checks (MACs) on their  contents.  The
     techniques used to perform the encryption and MAC operations
     are   defined   by   the  CipherSpec  and   constrained   by
     CipherSpec.cipher_type.  The encryption  and  MAC  functions
     translate  an SSLCompressed structure into an SSLCiphertext.
     The decryption functions reverse the process.

       struct {
         ContentType type;
         ProtocolVersion version;
         uint16 length;
         select (CipherSpec.cipher_type) {
             case stream: GenericStreamCipher;
             case block: GenericBlockCipher;
         } fragment;
       } SSLCiphertext;


       type             The    type   field   is   identical   to
                        SSLCompressed.type.

       version          The   version   field  is  identical   to
                        SSLCompressed.version.

       length           The  length  (in bytes) of the  following
                        SSLCiphertext.fragment. The  length   may
                        not exceed 2^14 + 2048.

       fragment         The        encrypted       form        of
                        SSLCompressed.fragment,   including   the
                        MAC.

     5.2.3.1   Null or standard stream cipher

Freier, Karlton, Kocher                                      [ Page 12 ]
SSL 3.0                                                    December 1995


     Stream  ciphers (including BulkCipherAlgorithm.null) convert
     SSLCompressed.fragment  structures  to   and   from   stream
     SSLCiphertext.fragment structures.

       stream-ciphered struct {
           opaque content[SSLCompressed.length];
           opaque MAC[CipherSpec.hash_size];
       } GenericStreamCipher;

     The MAC is generated as:

       hash(MAC secret + hash
         MAC secret + write sequence number +
         SSLCompressed.type + SSLCompressed.length +
         SSLCompressed.fragment));

     where '+' denotes concatenation.

     Note  that the MAC is computed before encryption. The stream
     cipher  encrypts the entire block, including  the  MAC.  For
     stream  ciphers  that  do  not use a synchronization  vector
     (such  as RC4), the stream cipher state from the end of  one
     record  is  simply  used on the subsequent  packet.  If  the
     CipherSuite  is SSL_NULL_WITH_NULL, encryption  consists  of
     the  identity operation (i.e., the data is not encrypted and
     the  MAC  size  is  zero  implying that  no  MAC  is  used).
     SSLCiphertext.length     is    SSLCompressed.length     plus
     CipherSpec.hash_size.

     5.2.3.2   CBC block cipher

     For  block ciphers (such as RC2 or DES), the encryption  and
     MAC  functions convert SSLCompressed.fragment structures  to
     and from block SSLCiphertext.fragment structures.

       block-ciphered struct {
         opaque content[SSLCompressed.length];
         opaque MAC[CipherSpec.hash_size];
         uint8 padding[GenericBlockCipher.padding_length];
         uint8 padding_length;
       } GenericBlockCipher;

     The MAC is generated as described in Section 5.2.3.1.

       padding           Padding that  is  added  to  force   the
                         length of the plaintext to be a multiple
                         of the block cipher's block length.

       padding_length    The length of the padding must  be  less
                         than  the cipher's block length and  may
                         be  zero.  The padding length should  be
                         such   that  the  total  size   of   the
                         GenericBlockCipher   structure   is    a

Freier, Karlton, Kocher                                      [ Page 13 ]
SSL 3.0                                                    December 1995

                         multiple of the cipher's block length.

     The encrypted data length (SSLCiphertext.length) is one more
     than  the sum of SSLCompressed.length, CipherSpec.hash_size,
     and padding_length.

     Note:          With  CBC  block  chaining the initialization
                    vector  (IV) for the first record is provided
                    by   the  handshake  protocol.  The  IV   for
                    subsequent  records  is the  last  ciphertext
                    block from the previous record.

     5.3  Change cipher spec protocol

     The change cipher spec protocol exists to signal transitions
     in  ciphering strategies. The protocol consists of a  single
     message, which is encrypted and compressed under the current
     (not  the  pending) CipherSpec. The message  consists  of  a
     single byte of value 1.

       struct {
         enum { change_cipher_spec(1), (255) } type;
       } ChangeCipherSpec;

     The  change  cipher spec message is sent by both the  client
     and  server  to  notify the receiving party that  subsequent
     records   will   be   protected  under  the  just-negotiated
     CipherSpec  and keys. Reception of this message  causes  the
     receiver  to copy the pending state into the current  state.
     The  client  sends a change cipher spec message  immediately
     following  a  handshake key exchange and certificate  verify
     (if   any)   messages,  and  the  server  sends  one   after
     successfully processing the key exchange message it received
     from  the  client. An unexpected change cipher spec  message
     should generate an unexpected_message alert (Section 5.4.2).

     5.4  Alert protocol

     One  of the content types supported by the SSL Record  layer
     is the alert type. Alert messages convey the severity of the
     message and a description of the alert. Alert messages  with
     a  level of fatal result in the immediate termination of the
     connection. In this case, other connections corresponding to
     the session may continue, but the session identifier must be
     invalidated, preventing the failed session from  being  used
     to  establish  new connections. Like other  messages,  alert
     messages are encrypted and compressed, as specified  by  the
     current connection state.

       enum { warning(1), fatal(2), (255) } AlertLevel;

       enum {
         close_notify(0),
         unexpected_message(10),

Freier, Karlton, Kocher                                      [ Page 14 ]
SSL 3.0                                                    December 1995

         bad_record_mac(20),
         decompression_failure(30),
         handshake_failure(40), no_certificate(41),
             bad_certificate(42), unsupported_certificate(43),
             certificate_revoked(44), certificate_expired(45),
             certificate_unknown(46),
         (255)
       } AlertDescription;

       struct {
         AlertLevel level;
         AlertDescription description;
       } Alert;

     5.4.1     Closure alerts

     The  client  and  the server must share knowledge  that  the
     connection is ending in order to avoid a truncation  attack.
     Either party may initiate the exchange of closing messages.

       close_notify      This message notifies the recipient that
                         the   sender  will  not  send  any  more
                         messages on this connection. The session
                         becomes unresumable if any connection is
                         terminated  without proper  close_notify
                         messages with level equal to warning.

     5.4.2     Error alerts

     Error handling in the SSL Handshake protocol is very simple.
     When  an  error  is detected, the detecting  party  sends  a
     message to the other party. Upon transmission or receipt  of
     an   unrecoverable   error  alert  message,   both   parties
     immediately  close the connection. Servers and  clients  are
     required  to  forget  any  session-identifiers,  keys,   and
     secrets  associated with a failed connection. The  following
     error alerts are defined:

       unexpected_message
                         An  inappropriate  message was received.
                         This alert is always  fatal  and  should
                         never   be   observed  in  communication
                         between proper implementations.

       bad_record_mac    This alert  is returned if a  record  is
                         received  with  an incorrect  MAC.  This
                         message is always fatal.

       decompression_failure
                         The  decompression   function   received
                         improper  input  (e.g. data  that  would
                         expand   to   excessive  length).   This
                         message is always fatal.


Freier, Karlton, Kocher                                      [ Page 15 ]
SSL 3.0                                                    December 1995

       handshake_failure Reception of  a handshake_failure  alert
                         message  indicates that the  sender  was
                         unable to negotiate an acceptable set of
                         security  parameters given  the  options
                         available.  This is a fatal error.

       no_certificate    A no_certificate alert  message  may  be
                         sent  in  response  to  a  certification
                         request if no appropriate certificate is
                         available.

       bad_certificate   A  certificate  was  corrupt,  contained
                         signatures    that   did   not    verify
                         correctly, etc.

       unsupported_certificate
                         A  certificate  was   of  an unsupported
                         type.

       certificate_revoked
                         A certificate was revoked by its signer.

       certificate_expired
                         A certificate  has  expired  or  is  not
                         currently valid.

       certificate_unknown
                         Some  other  (unspecified)  issue  arose
                         in processing the certificate, rendering
                         it unacceptable.

     5.5  Handshake protocol overview

     The  cryptographic  parameters  of  the  session  state  are
     produced  by  the SSL Handshake Protocol, a  client  of  the
     Record   Layer.  When  a  client  and  server  first   start
     communicating,  they  agree on a  protocol  version,  select
     cryptographic   algorithms,  optionally  authenticate   each
     other,  and use public-key encryption techniques to generate
     shared  secrets.  These  processes  are  performed  in   the
     handshake  protocol,  which can  consist  of  the  following
     messages:

     Client                                                Server
       ClientHello           -------->

                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                             <--------            ServerHelloDone

       Certificate*
       ClientKeyExchange

Freier, Karlton, Kocher                                      [ Page 16 ]
SSL 3.0                                                    December 1995

       CertificateVerify*
       ChangeCipherSpec
       [Begin new CipherSpec]
       Finished              -------->

                                                 ChangeCipherSpec
                                           [Begin new CipherSpec]
                             <--------                   Finished

       Application Data      <------->           Application Data

     Notes:         Messages marked with an asterisk (*) are  not
                    always  sent. To help avoid pipeline  stalls,
                    ChangeCipherSpec   is  an   independent   SSL
                    Protocol content type, and is not actually an
                    SSL handshake message.

     When  the  client  and server decide to  resume  a  previous
     session  or  duplicate  an  existing  session  (instead   of
     negotiating new security parameters) the message flow is  as
     follows:

       Client                                              Server
       ClientHello           -------->

                                                      ServerHello
                                                 ChangeCipherSpec
                                              [Resume CipherSpec]
                             <--------                   Finished
       ChangeCipherSpec
       [Resume CipherSpec]
       Finished              -------->

       Application Data      <------->           Application Data

     The  contents  and  significance of  each  message  will  be
     presented in the subsequent sections.

     5.6  Handshake protocol

     The  SSL  Handshake  Protocol is one of the  defined  higher
     level  clients of the SSL Record Protocol. This protocol  is
     used  to  negotiate  the  secure attributes  of  a  session.
     Handshake  messages are supplied to the  SSL  Record  Layer,
     where  they are encapsulated within one or more SSLPlaintext
     structures, which are processed and transmitted as specified
     by the current active session state.

       enum {
         hello_request(0), client_hello(1), server_hello(2),
         certificate(11), server_key_exchange (12),
         certificate_request(13), server_done(14),
         certificate_verify(15), client_key_exchange(16),
         finished(20), (255)

Freier, Karlton, Kocher                                      [ Page 17 ]
SSL 3.0                                                    December 1995

       } HandshakeType;

       struct {
         HandshakeType msg_type;
         uint24 length;
         select (HandshakeType) {
             case hello_request: HelloRequest;
             case client_hello: ClientHello;
             case server_hello: ServerHello;
             case certificate: Certificate;
             case server_key_exchange: ServerKeyExchange;
             case certificate_request: CertificateRequest;
             case server_done: ServerHelloDone;
             case certificate_verify: CertificateVerify;
             case client_key_exchange: ClientKeyExchange;
             case finished: Finished;
         } body;
       } Handshake;

     The  handshake protocol messages are presented in the  order
     they  must  be  sent;  sending  handshake  messages  in   an
     unexpected order results in a fatal error.

     5.6.1     Hello messages

     The  hello  phase  messages are used  to  exchange  security
     enhancement capabilities between the client and server. When
     a  new session begins, the CipherSpec encryption, hash,  and
     compression algorithms are initialized to null. The  current
     CipherSpec is used for renegotiation messages.

     5.6.1.1   Hello request

     The  hello request message may be sent by the server at  any
     time,  but  will be ignored by the client if  the  handshake
     protocol  is  already underway. It is a simple  notification
     that the client should begin the negotiation process anew by
     sending a client hello message when convenient.

     Note:          Since handshake messages are intended to have
                    transmission   precedence  over   application
                    data,  it  is  expected that the  negotiation
                    begin  in  no more than one or two times  the
                    transmission   time  of  a   maximum   length
                    application data message.

     After sending a hello request, servers should not repeat the
     request  until  the  subsequent  handshake  negotiation   is
     complete. A client that receives a hello request while in  a
     handshake   negotiation  state  should  simply  ignore   the
     message.

     The structure of a hello request message is as follows:


Freier, Karlton, Kocher                                      [ Page 18 ]
SSL 3.0                                                    December 1995

       struct { } HelloRequest;

     5.6.1.2   Client hello

     When  a client first connects to a server it is required  to
     send  the client hello as its first message. The client  can
     also  send a client hello in response to a hello request  or
     on  its  own initiative in order to renegotiate the security
     parameters in an existing connection.
     The  client hello message includes a random structure, which
     is used later in the protocol.

       struct {
          uint32 gmt_unix_time;
          opaque random_bytes[28];
       } Random;

       gmt_unix_time     The current  time and date  in  standard
                         UNIX  32-bit  format  according  to  the
                         sender's internal clock. Clocks are  not
                         required  to  be  set correctly  by  the
                         basic  SSL  Protocol;  higher  level  or
                         application   protocols    may    define
                         additional requirements.

       random_bytes      28 bytes  generated by a  secure  random
                         number generator.

     The  client hello message includes a variable length session
     identifier.  If  not empty, the value identifies  a  session
     between the same client and server whose security parameters
     the  client  wishes to reuse. The session identifer  may  be
     from  an  earlier  connection, this connection,  or  another
     currently active connection. The second option is useful  if
     the  client only wishes to update the random structures  and
     derived values of a connection, while the third option makes
     it  possible  to establish several simultaneous  independent
     secure  connections  without repeating  the  full  handshake
     protocol.  The actual contents of the SessionID are  defined
     by the server.

       opaque SessionID<0..32>;

     Warning:       Servers    must    not   place   confidential
                    information in session identifers or let  the
                    contents of fake session identifers cause any
                    breach of security.

     The  CipherSuite list, passed from the client to the  server
     in  the  client hello message, contains the combinations  of
     cryptographic algorithms supported by the client in order of
     the   client's   preference  (first  choice   first).   Each
     CipherSuite  defines  both a key exchange  algorithm  and  a
     CipherSpec. The server will select a cipher suite or, if  no

Freier, Karlton, Kocher                                      [ Page 19 ]
SSL 3.0                                                    December 1995

     acceptable choices are presented, return a handshake failure
     alert and close the connection.

       uint8 CipherSuite[2]; /* Cryptographic suite selector */

     The  client  hello includes a list of compression algorithms
     supported  by the client, ordered according to the  client's
     preference.  If the server supports none of those  specified
     by the client, the session must fail.

       enum { null(0), (255) } CompressionMethod;

     Issue:         Compression  methods  to  support  is   under
                    investigation.

     The structure of the client hello is as follows.

       struct {
         ProtocolVersion client_version;
         Random random;
         SessionID session_id;
         CipherSuite cipher_suites<2..2^216-1>;
         CompressionMethod compression_methods<1..2^8-1>;
       } ClientHello;

       client_version    The version of the SSL protocol by which
                         the  client wishes to communicate during
                         this  session. This should be  the  most
                         recent    (highest    valued)    version
                         supported by the client (See Appendix  C
                         for      details     about      backward
                         compatibility).

       random            A client-generated random structure.

       session_id        The ID of a session the client wishes to
                         use  for  this  connection.  This  field
                         should  be  empty  if no  session_id  is
                         available   or  the  client  wishes   to
                         generate new security parameters.

       cipher_suites     This is  a  list  of  the  cryptographic
                         options supported by the client,  sorted
                         with   the   client's  first  preference
                         first.  If the session_id field  is  not
                         empty  (implying  a  session  resumption
                         request)  this  vector must  include  at
                         least   the   cipher_suite   from   that
                         session.  Values are defined in Appendix
                         A.6.

       compression_methods    This  is  a list of the compression
                         methods supported by the client,  sorted
                         by  client preference. If the session_id

Freier, Karlton, Kocher                                      [ Page 20 ]
SSL 3.0                                                    December 1995

                         field  is not empty (implying a  session
                         resumption  request)  this  vector  must
                         include  at least the compression_method
                         from  that  session. All implementations
                         must support CompressionMethod.null.

     After sending the client hello message, the client waits for
     a server hello message. Any other handshake message returned
     by  the  server except for a hello request is treated  as  a
     fatal error.

     Implementation note:      Application data may not  be  sent
                    before a finished message has been sent.  The
                    security of transmitted application  data  is
                    unknown  until a valid finished  message  has
                    been received.

     5.6.1.3   Server hello

     The  server processes the client hello message and  responds
     with  either  a  handshake_failure  alert  or  server  hello
     message.

       struct {
         ProtocolVersion server_version;
         Random random;
         SessionID session_id;
         CipherSuite cipher_suite;
         CompressionMethod compression_method;
       } ServerHello;

       server_version    This field  will contain  the  lower  of
                         that  suggested  by the  client  in  the
                         client  hello and the highest  supported
                         by  the server. For this version of  the
                         specification the version  will  be  3.0
                         (See   Appendix  C  for  details   about
                         backward compatibility).

       random            This  structure  is  generated  by   the
                         server  and must be different from  (and
                         independent of) ClientHello.random.

       session_id        This  is the  identity  of  the  session
                         corresponding to this connection. If the
                         ClientHello.session_id  was   non-empty,
                         the  server  will look  in  its  session
                         cache  for a match. If a match is  found
                         and  the  server is willing to establish
                         the  new  connection using the specified
                         session  state, the server will  respond
                         with  the same value as was supplied  by
                         the  client.  This indicates  a  resumed
                         session  and  dictates that the  parties

Freier, Karlton, Kocher                                      [ Page 21 ]
SSL 3.0                                                    December 1995

                         must  proceed  directly to the  finished
                         messages.  Otherwise  this  field   will
                         contain  a  different value  identifying
                         the  new  session,  or  the  server  may
                         return  an empty session_id to  indicate
                         that the session will not be cached  and
                         therefore cannot be resumed.

       cipher_suite      The single cipher suite selected by  the
                         server     from     the     list      in
                         ClientHello.cipher_suites.  For  resumed
                         sessions  this field is the  value  from
                         the state of the session being resumed.

       compression_method
                         The   single    compression    algorithm
                         selected by the server from the list  in
                         ClientHello.compression_methods.     For
                         resumed sessions this field is the value
                         from the resumed session state.

     5.6.2     Server certificate

     If the server is to be authenticated (which is generally the
     case),   the   server  sends  its  certificate   immediately
     following  the  server hello message. The  certificate  type
     must  be  appropriate for the selected  cipher  suite's  key
     agreement   algorithm,   and  is   generally   an   X.509.v3
     certificate (or a modified X.509 certificate in the case  of
     Fortezza [FOR]). The same message type will be used for  the
     client's response to a server certificate request.

       opaque ASN.1Cert<2^24-1>;

       struct {
         ASN.1Cert certificate_list<1..2^24-1>;
       } Certificate;

       certificate_list  This is  a  sequence (chain) of X.509.v3
                         certificates, ordered with the  sender's
                         certificate   first   and    the    root
                         certificate authority last.

     Note:          PKCS #7 [PKCS7] is not used as the format for
                    the   certificate  vector  because  PKCS   #6
                    [PKCS6]  extended certificates are not  used.
                    Also  PKCS  #7  defines a SET rather  than  a
                    SEQUENCE, making the task of parsing the list
                    more difficult.

     5.6.3     Server key exchange message

     The  ServerKeyExchange message is sent by the server  if  it
     has  no  certificate  or  has a certificate  only  used  for

Freier, Karlton, Kocher                                      [ Page 22 ]
SSL 3.0                                                    December 1995

     signing  (e.g.,  DSS  [DSS] certificates,  signing-only  RSA
     [RSA]  certificates) This message is not used if the  server
     certificate contains Diffie-Hellman [DH1] parameters.

     Note:          RSA  moduli larger than 512 bits may  not  be
                    used for key exchange in export software, but
                    with this message larger RSA keys may be used
                    as   signature-only  certificates   to   sign
                    temporary shorter RSA keys for key exchange.

       enum { anonymous, certified } ServerIdentity;

       enum { rsa, diffie_hellman, fortezza }
           KeyExchangeAlgorithm;

       struct {
         opaque rsa_modulus<1..2^16-1>;
         opaque rsa_exponent<1..2^16-1>;
       } ServerRSAParams;

       rsa_modulus       The modulus  of  the server's  temporary
                         RSA key.
       rsa_exponent      The  public  exponent  of  the  server's
                         temporary RSA key.

       struct {
         opaque dh_p<1..2^16-1>;
         opaque dh_g<1..2^16-1>;
         opaque dh_Ys<1..2^16-1>;
       } ServerDHParams;     /* Ephemeral DH parameters */

       dh_p              The prime  modulus used for the  Diffie-
                         Hellman operation.

       dh_g              The  generator  used  for  the   Diffie-
                         Hellman operation.

       dh_Ys             The server's Diffie-Hellman public value
                         (gX mod p).

       struct {
         select (KeyExchangeAlgorithm) {
             case diffie_hellman: ServerDHParams;
             case rsa: ServerRSAParams;
             case fortezza: struct { }; /*will not occur*/
         }
       } ServerParams;

       struct {
         ServerParams params;
         select (ServerIdentity) {
             case anonymous: struct { };
             case certified: digitally-signed struct {
                 opaque md5_hash[16];

Freier, Karlton, Kocher                                      [ Page 23 ]
SSL 3.0                                                    December 1995

                 opaque sha_hash[20];
             };
         };
       } ServerKeyExchange;

       params            The server's key exchange parameters.

       md5_hash          MD5(ClientHello.random +
                         ServerHello.random +
                              ServerParams);

       sha_hash          SHA(ClientHello.random +
                         ServerHello.random +
                              ServerParams);

     5.6.4     Certificate request

     A  non-anonymous server can optionally request a certificate
     from  the  client,  if appropriate for the  selected  cipher
     suite.

       opaque CertificateAuthority <0..2^24-1>;
       enum {
         rsa_sign(1), dss_sign(2), rsa_fixed_dh(3),
         dss_fixed_dh(4), rsa_ephemeral_dh(5),
         dss_ephemeral_dh(6), fortezza(20), (255)
       } ClientCertificateType;

       opaque DistinquishedName<1..2^8-1>;

       struct {
         ClientCertificateType certificate_types<1..2^8-1>;
         DistinquishedName certificate_authorities<3..2^16-1>;
       } CertificateRequest;

       certificate_types This field  is  a list of the  types  of
                         certificates requested, sorted in  order
                         of the server's preference.

       certificate_authortie
                         A list  of the distinguished  names
                         of acceptable certificate authorities.

     Note:          DistinquishedName is derived from [X509].

     Note:          It  is a fatal handshake_failure alert for an
                    anonymous    server   to    request    client
                    identification.

     5.6.5     Server hello done

     The  server  hello  done message is sent by  the  server  to
     indicate   the  end  of  the  server  hello  and  associated
     messages.  After sending this message the server  will  wait

Freier, Karlton, Kocher                                      [ Page 24 ]
SSL 3.0                                                    December 1995

     for a client response.

       struct { } ServerHelloDone;

     Upon  receipt  of the server hello done message  the  client
     should  verify that the server provided a valid  certificate
     if  required and check that the server hello parameters  are
     acceptable.

     5.6.6     Client certificate

     This  is  the  first  message  the  client  can  send  after
     receiving a server hello done message. This message is  only
     sent  if  the server requests a certificate. If no  suitable
     certificate is available, the client should send a no client
     certificate  alert instead. This error is  only  a  warning,
     however  the  server  may  respond with  a  fatal  handshake
     failure if client authentication is required.

     Client  certificates are sent using the Certificate  message
     type defined in Section 5.6.2.

     Note:          Client Diffie-Hellman certificates must match
                    the     server    specified    Diffie-Hellman
                    parameters.

     5.6.7     Client key exchange message

     The   choice  of  messages  depends  on  which  public   key
     algorithm(s) has (have) been selected. See Section 5.6.3 for
     the KeyExchangeAlgorithm.

     struct {
       select (KeyExchangeAlgorithm) {
           case rsa: EncryptedPreMasterSecret;
           case diffie_hellman: ClientDiffieHellmanPublic;
           case fortezza: FortezzaKeys;
         } exchange_keys;
       } ClientKeyExchange;

     The  information to select the appropriate record  structure
     is in the pending session state (see Section 5.1).

     5.6.7.1   RSA encrypted premaster secret message

     If  RSA  is being used for key agreement and authentication,
     the  client generates a 48-byte pre-master secret,  encrypts
     it  under  the  public key from the server's certificate  or
     temporary  RSA key from a server key exchange  message,  and
     sends the result in an encrypted premaster secret message.

       struct {
         ProtocolVersion client_version;
         opaque random[46];

Freier, Karlton, Kocher                                      [ Page 25 ]
SSL 3.0                                                    December 1995

       } PreMasterSecret;

       client_version    The latest (newest) version supported by
                         the  client.  This  is  used  to  detect
                         version roll-back attacks.

       random            46 securely-generated random bytes.

       struct {
         public-key-encrypted PreMasterSecret pre_master_secret;
       } EncryptedPreMasterSecret;

       pre_master_secret This random  value is generated  by  the
                         client  and  is  used  to  generate  the
                         master  secret, as specified in  Section
                         6.1.

     5.6.7.2   Fortezza key exchange message

     Under  Fortezza, the client derives a Token  Encryption  Key
     (TEK)  using the Key Exchange Algorithm (KEA). The  client's
     KEA   calculation  uses  the  public  key  in  the  server's
     certificate  along with private parameters in  the  client's
     token.  The  client sends public parameters needed  for  the
     server   to   generate  the  TEK,  using  its  own   private
     parameters.  The client generates session keys,  wraps  them
     using  the  TEK,  and sends the results to the  server.  The
     client  also generates a master secret key, wraps  it  using
     the  TEK,  and sends it to the server. The client  generates
     IV's  for  the session keys and master secret key and  sends
     them  also.  The  client generates a random  48-byte  master
     secret,  encrypts it using the master secret key, and  sends
     the result:

       struct {
         opaque y_c<0..128>;
           opaque r_c[128];
           opaque wrapped_client_write_key[12];
           opaque wrapped_server_write_key[12];
           opaque wrapped_master_secret_key[12];
           opaque client_write_iv[24];
           opaque server_write_iv[24];
           opaque master_secret_iv[24];
           EncryptedPreMasterSecret
         encrypted_pre_master_secret[48];
       } FortezzaKeys;

       y_c               The client's Yc value (public  key)  for
                         the  KEA calculation. If the client sent
                         a  certificate, this value must be empty
                         since  the certificate already  contains
                         this   value.  However,  for   anonymous
                         Fortezza,  this  value is  required  and
                         must   be  between  64  and  128  bytes,

Freier, Karlton, Kocher                                      [ Page 26 ]
SSL 3.0                                                    December 1995

                         inclusively.

       r_c               The  client's  Rc  value  for  the   KEA
                         calculation.

       wrapped_client_write_key
                         This  is the client's write key, wrapped
                         by the TEK.

       wrapped_server_write_key
                         This  is the server's write key, wrapped
                         by the TEK.

       wrapped_master_secret_key
                         This  is  the master secret key, wrapped
                         by  the  TEK. This key is only used  for
                         the encryption of the pre_master_secret.

       client_write_iv   This is the IV for the client write key.

       server_write_iv   This is the IV for the server write key.

       master_secret_iv  This  is  the  IV  for the master  secret
                         key.

       encrypted_pre_master_secret
                         This is a random value, generated by the
                         client,  and encrypted using the  master
                         secret  key. It is used to generate  the
                         master  secret, as specified in  Section
                         6.1.

     Note:          The  server's R value for KEA is the  integer
                    1. It is fixed and not sent in any message.

     5.6.7.3   Client Diffie-Hellman public value

     This  structure  conveys the client's Diffie-Hellman  public
     value  (Yc)  if it was not already included in the  client's
     certificate. The encoding used for Yc is determined  by  the
     enumerated PublicValueEncoding.

       enum { implicit, explicit } PublicValueEncoding;

       implicit          If  the   client   certificate   already
                         contains  the public value, then  it  is
                         implicit and Yc does not need to be sent
                         again.

       explicit         Yc needs to be sent.

       struct {
         select (PublicValueEncoding) {
             case implicit: struct { };

Freier, Karlton, Kocher                                      [ Page 27 ]
SSL 3.0                                                    December 1995

             case explicit: opaque dh_Yc<1..2^16-1>;
         } dh_public;
       } ClientDiffieHellmanPublic;

       dh_Yc             The client's Diffie-Hellman public value
                         (Yc).

     5.6.8     Certificate verify

     This  message is used to provide explicit verification of  a
     client certificate. This message is only sent following  any
     client  certificate  that has signing capability  (i.e.  all
     certificates  except  those containing fixed  Diffie-Hellman
     parameters).

       digitally-signed struct {
         opaque md5_hash[16];
         opaque sha_hash[20];
       } CertificateVerify;

       md5_hash          MD5(master_secret +
                         SHA(handshake_messages +
                              master_secret));

       sha_hash          SHA(master_secret +
                         MD5(handshake_messages +
                              master_secret));

     Here  handshake_messages refers to  all  handshake  messages
     starting  at  client  hello up to  but  not  including  this
     message.

     5.6.9     Finished

     A finished message is always sent immediately after a change
     cipher  specs  message to verify that the key  exchange  and
     authentication  processes  were  successful.  The   finished
     message  is  the  first protected with  the  just-negotiated
     algorithms,  keys,  and  secrets. No acknowledgment  of  the
     finished  message  is required; parties  may  begin  sending
     confidential  data  immediately after sending  the  finished
     message.  Recipients of finished messages must  verify  that
     the contents are correct.

       enum { client(0x434C4E54), server(0x53525652) } Sender;
       struct {
         opaque md5_hash[16];
         opaque sha_hash[20];
       } Finished;

       md5_hash          MD5(master_secret +
                         SHA(handshake_messages +
                              Sender + master_secret));


Freier, Karlton, Kocher                                      [ Page 28 ]
SSL 3.0                                                    December 1995

       sha_hash          SHA(master_secret +
                         MD5(handshake_messages +
                              Sender + master_secret));

     The  hash  containd in finished messages sent by the  server
     incorporate   Sender.server;  those  sent  by   the   client
     incoporate   Sender.client.  The  value   handshake_messages
     includes to all handshake messages starting at client  hello
     up  to but not including the finished messages. This may  be
     different  from handshake_messages in Section 5.6.8  because
     it would include the certificate verify message (if sent).

     Note:          Change cipher spec messages are not handshake
                    messages  and are not included  in  the  hash
                    computations.

     5.7  Application data protocol

     Application  data messages are carried by the  Record  layer
     and  are fragmented, compressed and encrypted based  on  the
     current  connection  state.  The  messages  are  treated  as
     transparent data to the record layer.

     6.   Cryptographic computations

     The   key  exchange,  authentication,  encryption,  and  MAC
     algorithms  are determined by the cipher_suite  selected  by
     the server and revealed in the server hello message.

     6.1  Asymmetric cryptographic computations

     The asymmetric algorithms are used in the handshake protocol
     to  authenticate  parties and to generate  shared  keys  and
     secrets.

     For Diffie-Hellman, RSA, and Fortezza, the same algorithm is
     used    to   convert   the   pre_master_secret   into    the
     master_secret. The pre_master_secret should be deleted  from
     memory once the master_secret has been computed.

       master_secret =
         MD5(pre_master_secret + SHA('A' + pre_master_secret +
             ClientHello.random + ServerHello.random)) +
         MD5(pre_master_secret + SHA('BB' + pre_master_secret +
             ClientHello.random + ServerHello.random)) +
         MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
             ClientHello.random + ServerHello.random));

     6.1.1     RSA

     When RSA is used for server authentication and key exchange,
     a  48-byte  pre_master_secret is generated  by  the  client,
     encrypted  under the server's public key, and  sent  to  the
     server.  The  server  uses its private key  to  decrypt  the

Freier, Karlton, Kocher                                      [ Page 29 ]
SSL 3.0                                                    December 1995

     pre_master_secret.   Both   parties   then    convert    the
     pre_master_secret  into  the  master_secret,  as   specified
     above.

     RSA  digital signatures are performed using PKCS #1  [PKCS1]
     block  type 1. RSA public key encryption is performed  using
     PKCS #1 block type 2.

     6.1.2     Diffie-Hellman

     A  conventional Diffie-Hellman computation is performed. The
     negotiated key (Z) is used as the pre_master_secret, and  is
     converted into the master_secret, as specified above.

     Note:          Diffie-Hellman  parameters are  specified  by
                    the  server,  and may be either ephemeral  or
                    contained within the server's certificate.

     6.1.3     Fortezza

     A  random 48-byte pre_master_secret is sent encrypted  under
     an  additional  key and an IV reserved for  this  task.  The
     server decrypts the pre_master_secret and converts it into a
     master_secret, as specified above. Bulk cipher keys and  IVs
     for  encryption  are  generated by the  client's  token  and
     exchanged in the key exchange message; the master_secret  is
     only used for MAC computations.

     6.2  Symmetric cryptographic calculations and the CipherSpec

     The  technique used to encrypt and verify the  integrity  of
     SSL records is specified by the currently active CipherSpec.
     A  typical  example would be to encrypt data using  DES  and
     generate authentication codes using MD5. The encryption  and
     MAC   algorithms  default  to  SSL_NULL_WITH_NULL   at   the
     beginning of the SSL Handshake Protocol, indicating that  no
     authentication  or  encryption is performed.  The  handshake
     protocol  is used to negotiate a more secure CipherSpec  and
     to generate cryptographic keys.

     6.2.1     The master secret

     Before  secure encryption or integrity verification  can  be
     performed on records, the client and server need to generate
     shared  secret  information known only to  themselves.  This
     value  is  a 48-byte quantity called the master secret.  The
     master  secret  is  used to generate keys  and  secrets  for
     encryption  and MAC computations. Some algorithms,  such  as
     Fortezza,  may  have  their  own  procedure  for  generating
     encryption  keys  (the master secret is used  only  for  MAC
     computations in Fortezza).

     6.2.2      Converting master secret into keys and MAC secrets


Freier, Karlton, Kocher                                      [ Page 30 ]
SSL 3.0                                                    December 1995

     The master secret is hashed into a sequence of secure bytes,
     which  are assigned to the MAC secrets, keys, and non-export
     IVs required by the current CipherSpec (see Appendix A.7).

     CipherSpecs  require  a client write MAC  secret,  a  server
     write MAC secret, a client write key, a server write key,  a
     client  write IV, and a server write IV, which are generated
     from the master secret in that order. Unused values, such as
     Fortezza  keys communicated in the KeyExchange message,  are
     empty.  The  following  inputs  are  available  to  the  key
     definition process:

         opaque MasterSecret[48]
         ClientHello.random
         ServerHello.random

     When  generating keys and MAC secrets, the master secret  is
     used  as  an  entropy source, and the random values  provide
     unencrypted salt material and IVs for exportable ciphers.
     To generate the key material, compute

       key_block =
         MD5(master_secret + SHA(master_secret +
       ServerHello.random +
             ClientHello.random + 'A')) +
         MD5(master_secret + SHA(master_secret +
       ServerHello.random +
             ClientHello.random + 'BB')) +
         MD5(master_secret + SHA(master_secret +
       ServerHello.random +
             ClientHello.random + 'CCC')) + [...];

     until  enough output has been generated. Then the  key_block
     is partitioned as follows.

       client_write_MAC_secret[CipherSpec.hash_size]
       server_write_MAC_secret[CipherSpec.hash_size]
       client_write_key[CipherSpec.key_size]
       server_write_key[CipherSPec.key_size]
       client_write_IV[CipherSpec.IV_size]
       server_write_IV[CipherSpec.IV_size]

     Any extra key_block material is discarded.

     Exportable     encryption     algorithms     (for      which
     CipherSpec.is_exportable   is   true)   require   additional
     processing as follows to derive their final write keys:

       final_client_write_key = MD5(client_write_key +
         ClientHello.random + ServerHello.random);
       final_server_write_key = MD5(server_write_key +
         ServerHello.random + ClientHello.random);

     Exportable encryption algorithms derive their IVs  from  the

Freier, Karlton, Kocher                                      [ Page 31 ]
SSL 3.0                                                    December 1995

     random messages:

       client_write_IV = MD5(ClientHello.random +
       ServerHello.random);
       server_write_IV = MD5(ServerHello.random +
       ClientHello.random);

     MD5   outputs  are  trimmed  to  the  appropriate  size   by
     discarding the least-significant bytes.

     6.2.2.1   Export key generation example

     SSL_RSA_WITH_RC2_40_MD5 requires five random bytes for  each
     of  the two encryption keys and 16 bytes for each of the MAC
     keys,  for a total of 42 bytes of key material. MD5 produces
     16  bytes  of  output per call, so three calls  to  MD5  are
     required.  The MD5 outputs are concatenated into  a  48-byte
     key_block  with  the  first MD5 call  providing  bytes  zero
     through  15, the second providing bytes 16 through 31,  etc.
     The  key_block is partitioned, and the write keys are salted
     because this is an exportable encryption algorithm.

       client_write_MAC_secret  = key_block[0..15]
       server_write_MAC_secret  = key_block[16..31]
       client_write_key      = key_block[32..36]
       server_write_key      = key_block[37..41]
       final_client_write_key = MD5 (client_write_key +
         ClientHello.random + ServerHello.random)[0..15];
       final_server_write_key = MD5 (server_write_key +
         ServerHello.random + ClientHello.random)[0..15];
       client_write_IV = MD5(ClientHello.random +
       ServerHello.random)0..7;
       server_write_IV = MD5(ServerHello.random +
       ClientHello.random)0..7;






















Freier, Karlton, Kocher                                      [ Page 32 ]
SSL 3.0                                                    December 1995


                              Appendix A

     A.   Protocol constant values

     This section describes protocol types and constants.

     A.1  Reserved port assignments

     At  the present time SSL is implemented using TCP/IP as  the
     base  networking technology. The IANA reserved the following
     Internet  Protocol [IP] port numbers for use in  conjunction
     with SSL.
       443  Reserved for use by Hypertext Transfer Protocol  with
            SSL (https).
       465  Reserved  (pending) for use by Simple  Mail  Transfer
            Protocol with SSL (ssmtp).
       563  Reserved  (pending) for use by Network News  Transfer
            Protocol (snntp).

     A.1.1     Record layer

       struct {
         uint8 major, minor;
       } ProtocolVersion;

       ProtocolVersion version = { 3,0 }; /*SSL version 3.0*/

       enum {
         change_cipher_spec(20), alert(21), handshake(22),
         application_data(23), (255)
       } ContentType;

       struct {
         ContentType type;
         ProtocolVersion version;
         uint16 length;
         opaque fragment[SSLPlaintext.length];
       } SSLPlaintext;

       struct {
         ContentType type
         ProtocolVersion version
         uint16 length;
         opaque fragment[SSLCompressed.length];
       } SSLCompressed;

       struct {
         ContentType type;
         ProtocolVersion version;
         uint16 length;
         select (CipherSpec.cipher_type) {
             case stream: GenericStreamCipher;

Freier, Karlton, Kocher                                      [ Page 33 ]
SSL 3.0                                                    December 1995

             case block: GenericBlockCipher;
         } fragment;
       } SSLCiphertext;

       stream-ciphered struct {
           opaque content[SSLCompressed.length];
           opaque MAC[CipherSpec.hash_size];
       } GenericStreamCipher;

       block-ciphered struct {
         opaque content[SSLCompressed.length];
         opaque MAC[CipherSpec.hash_size];
         uint8 padding[GenericBlockCipher.padding_length];
         uint8 padding_length;
       } GenericBlockCipher;

     A.2  Change cipher specs message

       struct {
         enum { change_cipher_spec(1), (255) } type;
       } ChangeCipherSpec;

     A.3  Alert messages

       enum { warning(1), fatal(2), (255) } AlertLevel;

       enum {
         close_notify(0),
         unexpected_message(10),
         bad_record_mac(20),
         decompression_failure(30),
         handshake_failure(40), no_certificate(41),
         bad_certificate(42), unsupported_certificate(43),
         certificate_revoked(44), certificate_expired(45),
         certificate_unknown(46), (255)
       } AlertDescription;

       struct {
         AlertLevel level;
         AlertDescription description;
       } Alert;

     A.4  Handshake protocol

       One of the content types predefined to be carried by the
       SSL Record Protocol is the Handshake Protocol.

       enum {
         hello_request(0), client_hello(1), server_hello(2),
         certificate(11), server_key_exchange (12),
         certificate_request(13), server_done(14), certificate_verify(15),
         client_key_exchange(16), finished(20), (255)
       } HandshakeType;


Freier, Karlton, Kocher                                      [ Page 34 ]
SSL 3.0                                                    December 1995

       struct {
         HandshakeType msg_type
         uint24 length
         select (HandshakeType) {
             case hello_request: HelloRequest;
             case client_hello: ClientHello;
             case server_hello: ServerHello;
             case certificate: Certificate;
             case server_key_exchange: ServerKeyExchange;
             case certificate_request: CertificateRequest;
             case server_done: ServerHelloDone;
             case certificate_verify: CertificateVerify;
             case client_key_exchange: ClientKeyExchange;
             case finished: Finished;
         } body;
       } Handshake;

     A.4.1     Hello messages

       struct { } HelloRequest;

       struct {
          uint32 gmt_unix_time;
          opaque random_bytes[2^8];
       } Random;

       opaque SessionID<0..32>;

       uint8 CipherSuite[2]; /* Cryptographic suite selector */

       enum { null(0), (255) } CompressionMethod;

       struct {
         ProtocolVersion client_version;
         Random random;
         SessionID session_id;
         CipherSuite cipher_suites<0..2^16-1>;
         CompressionMethod compression_methods<0..2^8-1>;
       } ClientHello;

       struct {
         ProtocolVersion server_version;
         Random random;
         SessionID session_id;
         CipherSuite cipher_suite;
         CompressionMethod compression_method;
       } ServerHello;

     A.4.2 Server authentication and key exchange messages

       opaque ASN.1Cert<2^24-1>;

       struct {
         ASN.1Cert certificate_list<1..2^24-1>;

Freier, Karlton, Kocher                                      [ Page 35 ]
SSL 3.0                                                    December 1995

       } Certificate;

       enum { anonymous, certified } ServerIdentity;

       enum { rsa, diffie_hellman, fortezza }
           KeyExchangeAlgorithm;

       struct {
         opaque RSA_modulus<1..2^16-1>;
         opaque RSA_exponent<1..2^16-1>;
       } ServerRSAParams;
       RSA_modulus       The modulus  of  the servers  temporary
                         RSA key.
       RSA_exponent      The  public  exponent  of  the  servers
                         temporary RSA key.
       struct {
         opaque DH_p<1..2^16-1>;
         opaque DH_g<1..2^16-1>;
         opaque DH_Ys<1..2^16-1>;
       } ServerDHParams;
       struct
         select (KeyExchangeAlgorithm) {
             case diffie_hellman: ServerDHParams;
             case rsa: ServerRSAParams;
             case fortezza: { }; /* illegal, will not occur */
         }
       } ServerParams;

       struct {
         ServerParams params;
         select (ServerIdentity) {
             case anonymous: empty;
             case certified: digitally-signed struct {
                 uint8 MD5_hash[16];
                 uint8 SHA_hash[20];
             };
         };
       } ServerKeyExchange;

       opaque CertificateAuthority <0..224-1>;

       enum {
         RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3),
         DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6)
         Fortezza(20), (255)
       } CertificateType;

       opaque DistinquishedName<1..2^8-1>;

       struct {
         CertificateType certificate_types<1..2^8-1>;
         DistinquishedName certificate_authorities<3..2^16-1>;
       } CertificateRequest;


Freier, Karlton, Kocher                                      [ Page 36 ]
SSL 3.0                                                    December 1995

       struct { } ServerHelloDone;

     A.5  Client authentication and key exchange messages

       struct {
         select (KeyExchangeAlgorithm) {
             case rsa: EncryptedPreMasterSecret;
             case diffie_hellman: DiffieHellmanClientPublicValue;
             case fortezza: FortezzaKeys;
         } exchange_keys;
       } ClientKeyExchange;

       struct {
         ProtocolVersion client_version;
         opaque random[46];
       } PreMasterSecret;

       struct {
         public-key-encrypted PreMasterSecret pre_master_secret;
       } EncryptedPreMasterSecret;

       struct {
         opaque y_c<0..128>;
         opaque r_c[128];
         opaque wrapped_client_write_key[12];
         opaque wrapped_server_write_key[12];
         opaque wrapped_master_secret_key[12];
         opaque client_write_iv[24];
         opaque server_write_iv[24];
         opaque master_secret_iv[24];
         opaque encrypted_preMasterSecret[48];
       } FortezzaKeys;

       enum { implicit, explicit } PublicValueEncoding;

       struct {
         select (PublicValueEncoding) {
             case implicit: struct {};
             case explicit: opaque DH_Yc<1..2^16-1>;
         } dh_public;
       } ClientDiffieHellmanPublic;

       digitally-signed struct {
         uint8 MD5_hash[16];
         uint8 SHA_hash[20];
       } CertificateVerify;

     A.5.1     Handshake finalization message

       struct {
         opaque md5_hash[16];
         opaque sha_hash[20];
       } Finished;


Freier, Karlton, Kocher                                      [ Page 37 ]
SSL 3.0                                                    December 1995

     A.6  The CipherSuite

     The following values define the CipherKind codes used in the
     client hello and server hello messages.

     A  CipherSuite defines a cipher specifications supported  in
     SSL Version 3.0.

       CipherSuite SSL_NULL_WITH_NULL_NULL  = { 0x00,0x00 };

     The  following  CipherSuite  definitions  require  that  the
     server  provide an RSA certificate that can be used for  key
     exchange.  The server may request either an  RSA  or  a  DSS
     signature-capable  certificate in  the  certificate  request
     message.

       CipherSuite SSL_RSA_WITH_NULL_MD5    =     { 0x00,0x01 };
       CipherSuite SSL_RSA_WITH_NULL_SHA    =     { 0x00,0x02 };
       CipherSuite SSL_RSA_WITH_RC4_40_MD5  =     { 0x01,0x01 };
       CipherSuite SSL_RSA_WITH_RC4_40_SHA  =     { 0x01,0x02 };
       CipherSuite SSL_RSA_WITH_RC4_128_MD5 =     { 0x01,0x03 };
       CipherSuite SSL_RSA_WITH_RC4_128_SHA =     { 0x01,0x04 };
       CipherSuite SSL_RSA_WITH_RC2_40_MD5  =     { 0x01,0x05 };
       CipherSuite SSL_RSA_WITH_RC2_40_SHA  =     { 0x01,0x06 };
       CipherSuite SSL_RSA_WITH_RC2_128_MD5 =     { 0x01,0x07 };
       CipherSuite SSL_RSA_WITH_RC2_128_SHA =     { 0x01,0x08 };
       CipherSuite SSL_RSA_WITH_IDEA_CBC_MD5=     { 0x01,0x09 };
       CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA=     { 0x01,0x0A };
       CipherSuite SSL_RSA_WITH_DES40_CBC_MD5=    { 0x01,0x0B };
       CipherSuite SSL_RSA_WITH_DES40_CBC_SHA=    { 0x01,0x0C };
       CipherSuite SSL_RSA_WITH_DES_CBC_MD5 =     { 0x01,0x0D };
       CipherSuite SSL_RSA_WITH_DES_CBC_SHA =     { 0x01,0x0E };
       CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_MD5= { 0x01,0x0F };
       CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA= { 0x01,0x10 };

     The  following CipherSuite definitions are used for  server-
     authenticated (and optionally client-authenticated)  Diffie-
     Hellman.  "DH" denotes cipher suites in which  the  servers
     certificate contains the Diffie-Hellman parameters signed by
     the certificate authority (CA). DHE denotes ephemeral Diffie-
     Hellman, where the Diffie-Hellman parameters are signed by a
     DSS or RSA certificate, which has been signed by the CA. The
     signing  algorithm used is specified after  the  DH  or  DHE
     parameter. In all cases, the client must have the same  type
     of  certificate, and must use the Diffie-Hellman  parameters
     chosen by the server.

       CipherSuite SSL_DH_DSS_WITH_DES40_CBC_SHA   =  { 0x02,0x01 };
       CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA     =  { 0x02,0x02 };
       CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA=  { 0x02,0x03 };
       CipherSuite SSL_DH_RSA_WITH_DES40_CBC_SHA   =  { 0x02,0x04 };
       CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA     =  { 0x02,0x05 };
       CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA=  { 0x02,0x06 };


Freier, Karlton, Kocher                                      [ Page 38 ]
SSL 3.0                                                    December 1995

       CipherSuite SSL_DHE_DSS_WITH_DES40_CBC_SHA   = { 0x03,0x01 };
       CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA     = { 0x03,0x02 };
       CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA= { 0x03,0x03 };
       CipherSuite SSL_DHE_RSA_WITH_DES40_CBC_SHA   = { 0x03,0x04 };
       CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA     = { 0x03,0x05 };
       CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA= { 0x03,0x06 };

     The   following  cipher  suites  are  used  for   completely
     anonymous  Diffie-Hellman communications  in  which  neither
     party is authenticated. Note that this mode is vulnerable to
     man-in-the-middle   attacks  and   is   therefore   strongly
     discouraged.

       CipherSuite SSL_DH_anon_WITH_RC4_40_MD5   = { 0x04,0x01 };
       CipherSuite SSL_DH_anon_WITH_RC4_40_SHA   = { 0x04,0x02 };
       CipherSuite SSL_DH_anon_WITH_RC4_128_MD5  = { 0x04,0x03 };
       CipherSuite SSL_DH_anon_WITH_RC4_128_SHA  = { 0x04,0x04 };
       CipherSuite SSL_DH_anon_WITH_RC2_40_MD5   = { 0x04,0x05 };
       CipherSuite SSL_DH_anon_WITH_RC2_40_SHA   = { 0x04,0x06 };
       CipherSuite SSL_DH_anon_WITH_RC2_128_MD5  = { 0x04,0x07 };
       CipherSuite SSL_DH_anon_WITH_RC2_128_SHA  = { 0x04,0x08 };
       CipherSuite SSL_DH_anon_WITH_IDEA_CBC_MD5 = { 0x04,0x09 };
       CipherSuite SSL_DH_anon_WITH_IDEA_CBC_SHA = { 0x04,0x0A };
       CipherSuite SSL_DH_anon_WITH_DES40_CBC_MD5= { 0x04,0x0B };
       CipherSuite SSL_DH_anon_WITH_DES40_CBC_SHA= { 0x04,0x0C };
       CipherSuite SSL_DH_anon_WITH_DES_CBC_MD5  = { 0x04,0x0D };
       CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA  = { 0x04,0x0E };
       CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_MD5={ 0x04,0x0F };
       CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA={ 0x04,0x10 };

     The final cipher suite is for the Fortezza token.

       CipherSuite SSL_FORTEZZA_WITH_FORTEZZA_CBC_SHA
           { 0x10,0x00 };

     Note:          Any cipher types whose first byte is 0xFF are
                    considered  private  and  can  be  used   for
                    defining    local/experimental    algorithms.
                    Interoperability  of such types  is  a  local
                    matter.

     A.7  The CipherSpec

     A  cipher  suite defines a CipherSpec. These structures  are
     part of the SSL session state. The CipherSpec includes:

       enum { stream, block } CipherType;

       enum { true, false } IsExportable;

       enum { null, rc4, rc2, des, 3des, des40, fortezza }
         BulkCipherAlgorithm;

       enum { null, md5, sha } MACAlgorithm;

Freier, Karlton, Kocher                                      [ Page 39 ]
SSL 3.0                                                    December 1995


       struct {
         BulkCipherAlgorithm bulk_cipher_algorithm;
         MACAlgorithm mac_algorithm;
         CipherType cipher_type;
         IsExportable is_exportable
         uint8 hash_size;
         uint8 key_size;
         uint8 IV_size;
         opaque IV[CipherSpec.IV_size];
       } CipherSpec;


                              Appendix B

     B.   Glossary
       application protocol
                         An  application  protocol  is a protocol
                         that normally layers  directly on top of
                         the  transport   layer  (e.g.,  TCP/IP).
                         Examples include HTTP,  TELNET, FTP, and
                         SMTP.
       asymmetric cipher See public key cryptography.
       authentication    Authentication is  the  ability  of  one
                         entity  to  determine  the  identity  of
                         another entity.
       bulk cipher       A symmetric encryption algorithm used to
                         encrypt large quantities of data.
       client            The application entity that initiates  a
                         connection to a server.
       client write key  The key used to encrypt data written  by
                         the client.
       client write MAC secret
                         The  secret  data   used to authenticate
                         data written by the client.
       connection        A connection is a transport (in the  OSI
                         layering model definition) that provides
                         a  suitable  type of service.  For  SSL,
                         such   connections  are  peer  to   peer
                         relationships.   The   connections   are
                         transient.    Every    connection     is
                         associated with one session.
       MAC               A Message Authentication Code (MAC) is a
                         one-way hash computed from a message and
                         some  secret  data. Its  purpose  is  to
                         detect if the message has been altered.
       master secret     Secure secret  data used for  generating
                         encryption keys, MAC secrets, and IVs.
       MD5               MD5 [7]  is  a  secure hashing  function
                         that  converts an arbitrarily long  data
                         stream into a digest of fixed size.
       public key cryptography
                         A   class   of  cryptographic techniques
                         employing    two-key   ciphers. Messages

Freier, Karlton, Kocher                                      [ Page 40 ]
SSL 3.0                                                    December 1995

                         encrypted with the public key  can  only
                         be decrypted with the associated private
                         key. Conversely,  messages  signed  with
                         the private key canbe verified with  the
                         public key.
       RC2, RC4          Proprietary bulk ciphers from  RSA  Data
                         Security,   Inc.  (There  is   no   good
                         reference   to   these   as   they   are
                         unpublished    works;    however,    see
                         [RSADSI]). RC2 is block cipher  and  RC4
                         is a stream cipher.
       salt              Non-secret random  data  used  to   make
                         export     encryption    keys     resist
                         precomputation attacks.
       secure hash function
                         A  one-way  transformation that converts
                         an arbitrary amount of data into a fixed
                         length hash. It is hard  to  reverse the
                         transformation or  to  find  collisions.
                         MD5 and SHA are examples  of secure hash
                         functions.
       server            The server  is  the  application  entity
                         that    responds   to    requests    for
                         connections from clients. The server  is
                         passive,   waiting  for  requests   from
                         clients.
       session           A SSL  session is an association between
                         a  client  and  a server.  Sessions  are
                         created   by  the  handshake   protocol.
                         Sessions  define a set of  cryptographic
                         security parameters, which can be shared
                         among multiple connections. Sessions are
                         used  to avoid the expensive negotiation
                         of  new  security  parameters  for  each
                         connection.
       session identifier
                         A   session  identifier   is   a   value
                         generated by a server that identifies  a
                         particular session.
       server write key  The key used to encrypt data written  by
                         the server.
       server write MAC secret
                         The secret  data   used  to authenticate
                         data written by the server.
       SHA               The Secure Hash Algorithm is defined  in
                         FIPS  PUB  180-1. It produces a  20-byte
                         output [SHA].
       symmetric cipher  See bulk cipher.

                               Appendix C

     C.   Version 2.0 Backward Compatibility

     Version  3.0  clients that support Version 2.0 servers  must

Freier, Karlton, Kocher                                      [ Page 41 ]
SSL 3.0                                                    December 1995

     send Version 2.0 client hello messages [SSL-2]. Version  3.0
     servers  should accept either client hello format. The  only
     deviations  from  the  Version  2.0  specification  are  the
     ability  to specify a version with a value of three and  the
     support for more ciphering types in the CipherSpec.

     Warning:       The  ability to send Version 2.0 client hello
                    messages  will  be phased out  with  all  due
                    haste.  Implementors should make every effort
                    to  move  forward  as  quickly  as  possible.
                    Version  3.0  provides better mechanisms  for
                    transitioning to newer versions.

     The  following cipher specifications are carryovers from SSL
     Version  2.0. These are assumed to use RSA for key  exchange
     and authentication.

       V2CipherSpec SSL_RC4_128_WITH_MD5 =
           { 0x01,0x00,0x80 };
       V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 =
           { 0x02,0x00,0x80 };
       V2CipherSpec SSL_RC2_128_CBC_WITH_MD5 =
           {  0x03,0x00,0x80 };
       V2CipherSpec SSL_RC2_128_CBC_EXPORT40_WITH_MD5 =
           { 0x04,0x00,0x80 };
       V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 =
           { 0x05,0x00,0x80 };
       V2CipherSpec SSL_DES_64_CBC_WITH_MD5 =
           { 0x06,0x00,0x40 };
       V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 =
           { 0x07,0x00,0xC0 };

     Cipher  specifications  introduced in  Version  3.0  can  be
     included  in  Version 2.0 client hello  messages  using  the
     syntax  below. Any V2CipherSpec element with its first  byte
     equal  to  zero  will  be ignored by  Version  2.0  servers.
     Clients  sending any of the above V2CipherSpecs should  also
     include the Version 3.0 equivalent (see Appendix A.6):

       V2CipherSpec (see Version 3.0 name) =
           { 0x00, CipherSuite };

     C.1  Version 2 client hello

     The  Version  2.0  client hello message is  presented  below
     using   this   documents  presentation  model.   The   true
     definition  is  still  assumed to be  the  SSL  Version  2.0
     specification.

       uint8 V2CipherSpec[3];

       struct {
         unit8 msg_type;
         Version version;

Freier, Karlton, Kocher                                      [ Page 42 ]
SSL 3.0                                                    December 1995

         uint16 cipher_spec_length;
         uint16 session_id_length;
         uint16 challenge_length;
         V2CipherSpec
         cipher_specs[V2ClientHello.cipher_spec_length];
         opaque session_id[V2ClientHello.session_id_length];
         Random challenge;
       } V2ClientHello;

       msg_type          This  field,  in  conjunction  with  the
                         version  field, identifies a  version  2
                         client  hello message. The value  should
                         equal one (1).

       version           The   highers   version   of    protocol
                         supported   by   the   client    (equals
                         ProtocolVersion.version,  see   Appendix
                         A.1.1).

       cipher_spec_length
                         This  field is  the total length  of the
                         field  cipher_specs. It  cannot  be zero
                         and  must  be  a  multiple  of  the
                         V2CipherSpec length (3).

       session_id_length This field  must have a value of  either
                         zero  or  16.  If zero,  the  client  is
                         creating  a  new  session.  If  16,  the
                         session_id  field will  contain  the  16
                         bytes of session identification.

       challenge_length  The length  in  bytes  of  the  clients
                         challenge  to the server to authenticate
                         itself. This value must be 32.

       cipher_specs      This is  a  list of all CipherSpecs  the
                         client  is willing and able to use.  The
                         CipherSpecs are given first. There  must
                         be at least one CipherSpec acceptable to
                         the server.

       session_id        If this  fields length is not zero,  it
                         will  contain the identification  for  a
                         session   that  the  client  wishes   to
                         resume.

       challenge         The clients  challenge  to  the  server
                         for  the server to identify itself.  The
                         Version   3.0   server  will   use   the
                         challenge data as the client random data
                         as   specified  in  this   Version   3.0
                         protocol.

     Note:          Requests to resume an SSL 3.0 session  should

Freier, Karlton, Kocher                                      [ Page 43 ]
SSL 3.0                                                    December 1995

                    use an SSL 3.0 client hello.

      C.2  Avoiding man-in-the-middle version rollback

     When  SSL  Version  3.0 clients fall  back  to  Version  2.0
     compatibility   mode,  they  use  special  PKCS   #7   block
     formatting.  This is done so that Version 3.0  servers  will
     reject   Version  2.0  sessions  with  Version   3.0-capable
     clients.

     When  Version  3.0 clients are in Version 2.0  compatibility
     mode, they set the right-hand (least-significant) 8 bytes of
     the  random  PKCS  padding for the  RSA  encryption  of  the
     ENCRYPTED-KEY-DATA  field of the CLIENT-MASTER-KEY  to  0x03
     (the  other padding bytes are random). After decrypting  the
     ENCRYPTED-KEY-DATA  field,  servers  that  support  SSL  3.0
     should issue an error if these eight padding bytes are 0x03.
     Version  2.0 servers receiving blocks padded in this  manner
     will proceed normally.

                              Appendix D

     D.   Security analysis

     The   SSL  protocol  is  designed  to  establish  a   secure
     connection between a client and a server communicating  over
     an insecure channel. This document makes several traditional
     assumptions,  including  that  attackers  have   substantial
     computational resources and cannot obtain secret information
     from sources outside the protocol. Attackers are assumed  to
     have  the  ability to capture, modify, delete,  replay,  and
     otherwise  tamper with messages sent over the  communication
     channel. This appendix outlines how SSL has been designed to
     resist a variety of attacks.

     D.1  Handshake protocol

     The  handshake  protocol  is  responsible  for  selecting  a
     CipherSpec  and  generating a MasterSecret,  which  together
     comprise  the  primary  cryptographic parameters  associated
     with  a  secure  session. The handshake  protocol  can  also
     optionally authenticate parties who have certificates signed
     by a trusted certificate authority.

     D.1.1     Authentication and key exchange

     SSL  supports three authentication modes: authentication  of
     both  parties, server authentication with an unauthenticated
     client,   and  total  anonymity.  Whenever  the  server   is
     authenticated, the channel should be secure against  man-in-
     the-middle  attacks, but completely anonymous  sessions  are
     inherently  vulnerable  to such attacks.  Anonymous  servers
     cannot  authenticate clients, since the client signature  in
     the   certificate  verify  message  may  require  a   server

Freier, Karlton, Kocher                                      [ Page 44 ]
SSL 3.0                                                    December 1995

     certificate to bind the signature to a particular server.

     If the server is authenticated, its certificate message must
     provide  a  valid certificate chain leading to an acceptable
     certificate authority. Similarly, authenticated clients must
     supply  an acceptable certificate to the server. Each  party
     is responsible for verifying that the others certificate is
     valid and has not expired or been revoked.

     The general goal of the key exchange process is to create  a
     pre_master_secret known to the communicating parties and not
     to attackers. The pre_master_secret will be used to generate
     the  master_secret (see Section 6.1). The  master_secret  is
     required to generate the finished messages, encryption keys,
     and MAC secrets (see Sections 5.6.9 and 6.2.2). By sending a
     correct finished message, parties thus prove that they  know
     the correct pre_master_secret.

     D.1.1.1   Anonymous key exchange

     Completely anonymous sessions can be established using  RSA,
     Diffie-Hellman, or Fortezza for key exchange.
     With  anonymous RSA, the client encrypts a pre_master_secret
     with the servers uncertified public key extracted from  the
     server  key exchange message. The result is sent in a client
     key  exchange message. Since eavesdroppers do not  know  the
     servers  private  key, it will be infeasible  for  them  to
     decode the pre_master_secret.

     With   Diffie-Hellman  or  Fortezza,  the  servers   public
     parameters are contained in the server key exchange  message
     and  the  clients  are  sent in  the  client  key  exchange
     message.  Eavesdroppers who do not know the  private  values
     should  not be able to find the Diffie-Hellman result  (i.e.
     the  pre_master_secret) or the Fortezza token encryption key
     (TEK).

     Warning:       Completely anonymous connections only provide
                    protection   against  passive  eavesdropping.
                    Unless an independent tamper-proof channel is
                    used  to  verify  that the finished  messages
                    were  not  replaced  by an  attacker,  server
                    authentication  is required  in  environments
                    where active man-in-the-middle attacks are  a
                    concern.

     D.1.1.2   RSA key exchange and authentication

     With  RSA,  key  exchange  and  server  authentication   are
     combined.  The  public key may be either  contained  in  the
     servers certificate or may be a temporary RSA key sent in a
     server  key  exchange message. When temporary RSA  keys  are
     used,   they  are  signed  by  the  servers  RSA   or   DSS
     certificate.    The   signature   includes    the    current

Freier, Karlton, Kocher                                      [ Page 45 ]
SSL 3.0                                                    December 1995

     ClientHello.random,  so old signatures  and  temporary  keys
     cannot  be replayed. Servers may use a single temporary  RSA
     key for multiple negotiation sessions.

     Note:          The  temporary RSA key option  is  useful  if
                    servers  need  large  certificates  but  must
                    comply with government-imposed size limits on
                    keys used for key exchange.

     After   verifying  the  servers  certificate,  the   client
     encrypts  a pre_master_secret with the servers public  key.
     By successfully decoding the pre_master_secret and producing
     a  correct finished message, the server demonstrates that it
     knows   the   private  key  corresponding  to   the   server
     certificate.

     When RSA is used for key exchange, clients are authenticated
     using  the  certificate verify message (see Section  5.6.8).
     The  client signs a value derived from the master_secret and
     all  preceding handshake messages. These handshake  messages
     include the server certificate, which binds the signature to
     the   server,  and  ServerHello.random,  which   binds   the
     signature to the current handshake process.

     D.1.1.3   Diffie-Hellman key exchange with authentication

     When  Diffie-Hellman key exchange is used,  the  server  can
     either  supply a certificate containing fixed Diffie-Hellman
     parameters  or  can use the client key exchange  message  to
     send  a  set  of temporary Diffie-Hellman parameters  signed
     with  a  DSS  or  RSA certificate. Temporary parameters  are
     hashed with the hello.random values before signing to ensure
     that attackers do not replay old parameters. In either case,
     the client can verify the certificate or signature to ensure
     that the parameters belong to the server.

     If  the  client  has a certificate containing fixed  Diffie-
     Hellman parameters, its certificate contains the information
     required  to  complete the key exchange. Note that  in  this
     case  the  client and server will generate the same  Diffie-
     Hellman  result  (i.e., pre_master_secret) every  time  they
     communicate.  To prevent the pre_master_secret from  staying
     in  memory any longer than necessary, it should be converted
     into  the master_secret as soon as possible. Client  Diffie-
     Hellman parameters must be compatible with those supplied by
     the server for the key exchange to work.

     If  the client has a standard DSS or RSA certificate  or  is
     unauthenticated, it sends a set of temporary  parameters  to
     the   server  in  the  client  key  exchange  message,  then
     optionally uses a certificate verify message to authenticate
     itself.

     D.1.1.4   Fortezza

Freier, Karlton, Kocher                                      [ Page 46 ]
SSL 3.0                                                    December 1995


     Fortezzas  design is classified, but at the protocol  level
     it  is  similar  to Diffie-Hellman with fixed public  values
     contained  in  certificates. The result of the key  exchange
     process is the token encryption key (TEK), which is used  to
     wrap  data  encryption keys, client write key, server  write
     key,  and  master secret encryption key. The data encryption
     keys  are  not  derived  from the pre_master_secret  because
     unwrapped  keys  are not accessable outside the  token.  The
     encrypted  pre_master_secret is sent  to  the  server  in  a
     client key exchange message.

     D.1.2     Version rollback attacks

     Because  SSL  Version 3.0 includes substantial  improvements
     over SSL Version 2.0, attackers may try to make Version 3.0-
     capable  clients and servers fall back to Version 2.0.  This
     attack is occurring if (and only if) two Version 3.0-capable
     parties use an SSL 2.0 handshake.

     Although the solution using non-random PKCS #1 block type  2
     message  padding  is  inelegant, it  provides  a  reasonably
     secure  way  for Version 3.0 servers to detect  the  attack.
     This  solution is not secure against attackers who can brute
     force  the  key  and  substitute  a  new  ENCRYPTED-KEY-DATA
     message  containing the same key (but with  normal  padding)
     before the application specified wait threshold has expired.
     Parties concerned about attacks of this scale should not  be
     using 40-bit encryption keys anyway. Altering the padding of
     the  least-significant 8 bytes of the PKCS padding does  not
     impact  security,  since this is essentially  equivalent  to
     increasing the input block size by 8 bytes.

     D.1.3     Detecting attacks against the handshake protocol

     An attacker might try to influence the handshake exchange to
     make the parties select different encryption algorithms than
     they  would  normally  choose. Because many  implementations
     will  support 40-bit exportable encryption and some may even
     support null encryption or MAC algorithms, this attack is of
     particular concern.

     For  this  attack, an attacker must actively change  one  or
     more  handshake  messages. If this occurs,  the  client  and
     server  will  compute  different values  for  the  handshake
     message  hashes.  As a result, the parties will  not  accept
     each  others  finished messages. Without the master_secret,
     the  attacker  cannot repair the finished messages,  so  the
     attack will be discovered.

     D.1.4     Resuming sessions

     When a connection is established by resuming a session,  new
     ClientHello.random and ServerHello.random values are  hashed

Freier, Karlton, Kocher                                      [ Page 47 ]
SSL 3.0                                                    December 1995

     with   the   sessions  master_secret.  Provided  that   the
     master_secret has not been compromised and that  the  secure
     hash operations used to produce the encryption keys and  MAC
     secrets  are  secure, the connection should  be  secure  and
     effectively independent from previous connections. Attackers
     cannot   use  known  encryption  keys  or  MAC  secrets   to
     compromise  the  master_secret without breaking  the  secure
     hash operations (which use both SHA and MD5).

     Sessions cannot be resumed unless both the client and server
     agree.  If either party suspects that the session  may  have
     been  compromised, or that certificates may have expired  or
     been  revoked,  it should force a full handshake.  An  upper
     limit  of  24  hours is suggested for session ID  lifetimes,
     since an attacker who obtains a master_secret may be able to
     impersonate  the  compromised party until the  corresponding
     session  ID  is  retired. Applications that may  be  run  in
     relatively  insecure environments should not  write  session
     IDs to stable storage.

     D.1.5     MD5 and SHA

     SSL uses hash functions very conservatively. Where possible,
     both  MD5  and  SHA are used in tandem to ensure  that  non-
     catastrophic  flaws  in one algorithm  will  not  break  the
     overall protocol.

     D.2  Protecting application data

     The  master_secret is hashed with the ClientHello.random and
     ServerHello.random  to produce unique data  encryption  keys
     and  MAC  secrets  for each connection. Fortezza  encryption
     keys  are  generated by the token, and are not derived  from
     the master_secret.

     Outgoing  data  is protected with a MAC before transmission.
     To  prevent message replay or modification attacks, the  MAC
     is  computed  from the MAC secret, the sequence number,  the
     message  type, the message length, and the message contents.
     The  message type field is necessary to ensure that messages
     intended  for one SSL Record Layer client are not redirected
     to  another.  The sequence number ensures that  attempts  to
     delete  or reorder messages will be detected. Since sequence
     numbers  are  64-bits  long,  they  should  never  overflow.
     Messages from one party cannot be inserted into the  others
     output,  since they use independent MAC secrets.  Similarly,
     the  server-write and client-write keys are  independent  so
     stream cipher keys are used only once.

     If  an  attacker does break an encryption key, all  messages
     encrypted  with it can be read. Similarly, compromise  of  a
     MAC  key  can  make  message modification attacks  possible.
     Because  MACs are also encrypted, message-alteration attacks
     generally require breaking the encryption algorithm as  well

Freier, Karlton, Kocher                                      [ Page 48 ]
SSL 3.0                                                    December 1995

     as the MAC.

     Note:          MAC  secrets  may  be larger than  encryption
                    keys, so messages can remain tamper resistant
                    even if encryption keys are broken.

     D.3  Final notes

     For  SSL to be able to provide a secure connection, both the
     client  and server systems, keys, and applications  must  be
     secure.  In  addition, the implementation must  be  free  of
     security errors.

     The system is only as strong as the weakest key exchange and
     authentication  algorithm supported,  and  only  trustworthy
     cryptographic functions should be used. Short  public  keys,
     40-bit bulk encryption keys, and anonymous servers should be
     used  with great caution. Implementations and users must  be
     careful  when  deciding which certificates  and  certificate
     authorities   are   acceptable;  a   dishonest   certificate
     authority can do tremendous damage.

                              Appendix E

     E.   Patent Statement

     This  version  of  the SSL protocol relies  on  the  use  of
     patented public key encryption technology for authentication
     and encryption. The Internet Standards Process as defined in
     RFC 1310 requires a written statement from the Patent holder
     that  a  license will be made available to applicants  under
     reasonable  terms  and  conditions  prior  to  approving   a
     specification as a Proposed, Draft or Internet Standard.

     The  Massachusetts Institute of Technology has  granted  RSA
     Data  Security, Inc., exclusive sub-licensing rights to  the
     following patent issued in the United States:

          Cryptographic Communications System and Method ("RSA"),
              No. 4,405,829

     The   Board  of  Trustees  of  the  Leland  Stanford  Junior
     University  have  granted Caro-Kann  Corporation,  a  wholly
     owned subsidiary corporation, exclusive sub-licensing rights
     to  the  following patents issued in the United States,  and
     all of their corresponding foreign patents:

           Cryptographic Apparatus and Method ("Diffie-Hellman"),
               No. 4,200,770
           Public Key Cryptographic Apparatus and Method ("Hellman-
               Merkle"), No. 4,218,582

     The  Internet Society, Internet Architecture Board, Internet
     Engineering Steering Group and the Corporation for  National

Freier, Karlton, Kocher                                      [ Page 49 ]
SSL 3.0                                                    December 1995

     Research  Initiatives take no position on  the  validity  or
     scope  of  the patents and patent applications, nor  on  the
     appropriateness of the terms of the assurance. The  Internet
     Society  and other groups mentioned above have not made  any
     determination  as to any other intellectual property  rights
     which  may  apply  to  the practice of  this  standard.  Any
     further  consideration of these matters is  the  users  own
     responsibility.
















































Freier, Karlton, Kocher                                      [ Page 50 ]
SSL 3.0                                                    December 1995



     References

     [DH1] W. Diffie and M. E. Hellman, "New Directons in
     Cryptography," IEEE Transactions on Information Theory, V.
     IT-22, n. 6, Jun 1977, pp. 74-84.

     [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions
     To DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.

     [DES] ANSI X3.106, "American National Standard for
     Information Systems-Data Link Encryption," American National
     Standards Institute, 1983.

     [DSS] NIST FIPS PUB XX, "Digital Signature Standard,"
     National Institute of Standards and Technology, U.S.
     Department of Commerce, DRAFT, 1 Feb 1993

     [FTP] J. Postel and J. Reynolds, RFC 959: File Transfer
     Protocol, October 1985.

     [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext
     Transfer Protocol -- HTTP/1.0, October, 1995.

     [IDEA] X. Lai, "On the Design and Security of Block
     Ciphers," ETH Series in Information Processing, v. 1,
     Konstanz: Hartung-Gorre Verlag, 1992.

     [FOR] NSA X22, Document # PD4002103-1.01, "Fortezza:
     Application Implementors Guide," April 6, 1995.

     [MD2] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm.
     April 1992.

     [MD5] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm.
     April 1992.

     [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption
     Standard," version 1.5, November 1993.

     [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate
     Syntax Standard," version 1.5, November 1993.

     [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic
     Message Syntax Standard," version 1.5, November 1993.

     [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
     Obtaining Digital Signatures and Public-Key Cryptosystems,"
     Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-
     126.

     [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782

Freier, Karlton, Kocher                                      [ Page 51 ]
SSL 3.0                                                    December 1995


     [SCH] B. Schneier. Applied Cryptography: Protocols,
     Algorithms, and Source Code in C, Published by John Wiley &
     Sons, Inc. 1994.

     [SHA] NIST FIPS PUB XX, "Secure Hash Standard," National
     Institute of Standards and Technology, U.S. Department of
     Commerce, DRAFT, 1 Feb 1993

     [TCP] ISI for DARPA, RFC 793: Transport Control Protocol,
     September 1981.

     [TEL] J. Postel and J. Reynolds, RFC 854/5, May, 1993.
     [X509] CCITT. Recommendation X.509: "The Directory -
     Authentication Framework". 1988.

     [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR:
     External Data Representation Standard, August 1995.



     Authors

     Alan O. Freier                Paul C. Kocher
     Netscape Communications       Independent Consultant
     501 East Middlefield Rd.      Box 8243
     Mountain View, CA 94043       Stanford, CA 94039
     freier@netscape.com           pck@netcom.com

     Philip L. Karlton
     Netscape Communications
     501 East Middlefield Rd.
     Mountain View, CA 94043
     karlton@netscape.com


     Other contributors
     Martin Abadi                  Kipp E.B. Hickman
     Digital Equipment Corporation Netscape Communications
     ma@pa.dec.com                 501 East Middlefield Rd.
                                   Mountain View, CA 94043
                                   kipp@netscape.com
     Taher Elgamal                 Jim Roskind
     Netscape Communications       Netscape Communications
     501 East Middlefield Rd.      501 East Middlefield Rd
     Mountain View, CA 94043       Mountain View, CA 94043
     elgamal@netscape.com          jar@netscape.com

     Anil Gangolli                 Micheal J. Sabin, Ph. D.
     Netscape Communications       Consulting Engineer
     501 East Middlefield Rd       833 Mango Ave.
     Mountain View, CA 94043       Sunnyvale, CA 94087
     gangolli@netscape.com         msabin@netcom.com


Freier, Karlton, Kocher                                      [ Page 52 ]
SSL 3.0                                                    December 1995


     Early reviewers

     Robert Baldwin                Eric Murray
     RSA Data Security, Inc.       ericm@lne.com
     baldwin@rsa.com
     George Cox                    Don Stephenson
     Intel Corporation             Sun Microsystems
     cox@ibeam.jf.intel.com        don.stephenson@eng.sun.com

     Cheri Dowell                  Joe Tardo
     Sun Microsystems              General Magic
     cheri@eng.sun.com             tardo@genmagic.com
     Burt Kaliski
     RSA Data Security, Inc.
     burt@rsa.com








































Freier, Karlton, Kocher                                      [ Page 53 ]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/